タグ付けされた質問 「security」

OpenSSLの「heartbleed」脆弱性（CVE-2014-0160）は、HTTPSを提供するWebサーバーに影響します。他のサービスもOpenSSLを使用します。これらのサービスは、ハートブリードのようなデータ漏洩に対しても脆弱ですか？ 私は特に考えています sshd 安全なSMTP、IMAPなど-dovecot、exim、postfix VPNサーバー-OpenVPNおよびフレンド 少なくとも私のシステムでは、これらはすべてOpenSSLライブラリにリンクされています。

65 security  openssl  heartbleed 

LocalSystem（NT AUTHORITY \ SYSTEM）アカウントにネットワークリソースへのアクセスをどのように許可しますか？ バックグラウンド ネットワークにアクセスすると、LocalSystemアカウントはネットワーク上のコンピューターとして機能します。 LocalSystemアカウント LocalSystemアカウントは、サービスコントロールマネージャーが使用する定義済みのローカルアカウントです。 ...そしてネットワーク上のコンピューターとして機能します。 または、同じことをもう一度言うと、LocalSystemアカウントはネットワーク上のコンピューターとして機能します。 ドメインメンバーであるコンピューターでLocalSystemアカウントでサービスを実行すると、そのサービスは、コンピューターアカウントまたはコンピューターアカウントがメンバーであるグループに許可されたネットワークアクセスをすべて持ちます。 共有フォルダーとファイルへの「コンピューター」アクセスをどのように許可しますか？ 注： 通常、コンピューターアカウントにはほとんど権限がなく、グループに属していません。 それでは、共有の1つへのコンピューターアクセスをどのように許可しますか。「全員」が既にアクセス権を持っていることを考慮して？ 注：ワークグループ | Account | Presents credentials | |----------------|----------------------| | LocalSystem | Machine$ | | LocalService | Anonymous | | NetworkService | Machine$ |

65 windows  security  authentication  local-system 

Googleの新しいパブリックDNSサービスに関するいくつかのメモを読んでいた： パフォーマンスの利点 セキュリティ上の利点 セキュリティのセクションでこの段落に気付きました： DNSSEC2プロトコルなど、DNSの脆弱性に対するシステム全体の標準的なソリューションが普遍的に実装されるまで、オープンDNSリゾルバーは、既知の脅威を軽減するためにいくつかの対策を個別に講じる必要があります。多くの手法が提案されています。IETF RFC 4542：ほとんどの概要については、偽造された回答に対するDNSの回復力を高める手段を参照してください。Google Public DNSでは、次のアプローチを実装しており、推奨しています。 リゾルバ自体への直接的なDoS攻撃から保護するためのマシンリソースのオーバープロビジョニング。IPアドレスは攻撃者が偽造するのは簡単なので、IPアドレスまたはサブネットに基づいてクエリをブロックすることは不可能です。そのような攻撃に対処する唯一の効果的な方法は、単純に負荷を吸収することです。 それは気のめいるような実現です。Stack Overflow / Server Fault / Super Userでも、あらゆる種類の禁止とブロックのベースとしてIPアドレスを頻繁に使用しています。 「才能のある」攻撃者が自分の望むIPアドレスを簡単に使用し、好きなだけユニークな偽のIPアドレスを合成できると考えるのは本当に怖いです！ だから私の質問： それは本当にその攻撃者が野生でのIPアドレスを偽造しやすいですか？ その場合、どのような軽減策が可能ですか？

65 security  domain-name-system  ip-address  spoofing 

最近、ワイルドカードSSL証明書を購入する必要があり（多くのサブドメインを保護する必要があるため）、最初にどこで購入するかを検索したときに、選択肢の数、マーケティングクレーム、価格帯に圧倒されました。リストを作成して、大部分の認証局（CA）がサイト全体に塗りつぶしているマーケティングの仕掛けが合格したことを確認できるようにしました。結局のところ、私の個人的な結論は、CAのWebサイトの価格と快適さだけが重要であるということです。 質問：価格と素晴らしいWebサイトに加えて、ワイルドカードSSL証明書を購入する場所を決定する際に検討する価値があるものはありますか？

63 ssl  certificate-authority  security  ssl-certificate 

Windows Server 2008上で実行されているExchange 2007サーバーがあります。クライアントは別のベンダーのメールサーバーを使用します。それらのセキュリティポリシーでは、強制TLSを使用する必要があります。これは最近まで正常に機能していました。 現在、Exchangeがメールをクライアントのサーバーに配信しようとすると、次のログが記録されます。 ourclient.comのトランスポート層セキュリティ（TLS）証明書の検証がステータス「UntrustedRoot」で失敗したため、コネクタ「デフォルトの外部メール」上のドメインセキュアドメイン「ourclient.com」へのセキュア接続を確立できませんでした。ourclient.comの管理者に連絡して問題を解決するか、ドメインセキュアリストからドメインを削除してください。 ourclient.comをTLSSendDomainSecureListから削除すると、日和見TLSを使用してメッセージが正常に配信されますが、これはせいぜい一時的な回避策です。 クライアントは、非常に大規模でセキュリティに敏感な国際企業です。弊社のIT担当者は、TLS証明書の変更を認識していないと主張しています。検証エラーをトラブルシューティングできるように、証明書を生成した機関を特定するように繰り返し求めましたが、これまでのところ、彼は答えを提供できませんでした。私が知っている限りでは、クライアントは有効なTLS証明書を社内の認証局からのものに置き換えることができました。 WebブラウザでリモートHTTPSサーバーの証明書に対してできるように、リモートSMTPサーバーのTLS証明書を手動で検査する方法を知っている人はいますか？誰が証明書を発行したかを判断し、その情報をExchangeサーバー上の信頼されたルート証明書のリストと比較すると非常に役立ちます。

63 windows-server-2008  security  exchange-2007  certificate  tls 

サーバー上で実行されている一連のWindowsサービスは、他のサービスを管理する1つのサービスを除いて、互いに独立した一連の自動化されたタスクを実行します。 サービスの1つが応答またはハングに失敗した場合、このサービスはサービスの再起動を試み、試行中に例外がスローされた場合、代わりにサポートチームにメールを送信して、サービスを自分で再起動できるようにします。 少し調べてみると、KB907460に記載されている回避策から、サービスが管理者権限を実行しているアカウントを与えるまで、いくつかの「解決策」に出会いました。 これらの方法のいずれにも慣れていません-Microsoftのナレッジベースの記事に記載されている最初の方法の結果を理解していませんが、サービスが実行されているアカウントへの管理者アクセスを絶対に与えたくありません。 ローカルセキュリティポリシーをざっと見てみましたが、アカウントがサービスとしてログオンできるかどうかを定義するポリシー以外は、サービスを参照しているように見えるものは他にありません。 これをServer 2003とServer 2008で実行しているので、アイデアや指針は喜んで受け取られます！ 明確化：特定のユーザーまたはグループにすべてのサービスを開始/停止/再起動する権限を付与したくありません-特定のユーザーまたはグループに特定のサービスのみでこれを実行する権限を付与できるようにします。 さらなる明確化：これらのアクセス許可を付与する必要があるサーバーはドメインに属していません-それらはファイルを受信し、それらを処理し、サードパーティに送信する2つのインターネット接続サーバーであり、いくつかのWebサイトを提供しています。 Active Directoryグループポリシーは使用できません。申し訳ありませんが、私はこれを明確にしませんでした。

61 windows  permissions  group-policy  security  windows-service 

私は、勤務している会社のクラウドベース（VPS）サーバーをいくつか管理しています。 サーバーは、LAMPスタックのビット/インバウンドデータ収集（rsync）を実行する最小限のUbuntuインストールです。データは大きいが、個人的、財務的、またはそのようなものではない（つまり、それほど面白くない） ここで明らかに、人々はファイアウォールなどの設定について永遠に尋ねています。 たとえば、サーバーを保護するために多くのアプローチを使用します（ただし、これらに限定されません） 非標準ポートのssh。パスワード入力なし、ログインなどの既知のIPからの既知のsshキーのみ https、および一般に既知のキー/ IPからのみの制限付きシェル（rssh） サーバーは最小限で、最新であり、定期的にパッチが適用されます rkhunter、cfengine、lynis denyhostsなどを監視に使用します UNIXシステム管理者の豊富な経験があります。私は自分のセットアップで何をしているかを知っていると確信しています。/ etcファイルを構成します。ファイアウォールのようなもの、iptablesなどをインストールする必要があると感じたことがありません。 VPSの物理的なセキュリティの問題については、しばらくの間脇に置いておきます。 Q？私が素朴であるか、fwが提供する増分保護がサーバーでの学習/インストールと追加の複雑さ（パッケージ、構成ファイル、可能なサポートなど）の努力に値するかどうかは判断できません。 これまで（木材に触れる）セキュリティに問題はありませんでしたが、満足しているわけでもありません。

59 security  firewall  configuration  vps 

ここで私たちの何人がシステム管理者タイプの人であるかは明らかですが、多くのシステムとアカウントにまたがる多くのパスワードがあります。優先度の低いものもあれば、発見されれば会社に深刻な害を及ぼす可能性のあるものもあります（権力を愛しているだけではありませんか？）。 シンプルで覚えやすいパスワードは受け入れられません。唯一のオプションは、複雑で覚えにくい（および入力しにくい）パスワードです。それでは、パスワードを追跡するために何を使用しますか？プログラムを使用してそれらを暗号化します（さらに別のパスワードが必要になります）か、人に紙片を預けるなど、それほど複雑でないことをしますか、それともそれらのオプションの中間ですか？

59 security  password 

キーを介してサーバーにアクセスするというアイデアが大好きです。そのためssh、ボックスに毎回パスワードを入力する必要がなく、ユーザーの（ロックではなくroot）パスワードをロックすることもpasswd -l usernameできるため、キーなしでログインすることはできません。 しかし、sudoコマンドのパスワードを入力する必要がある場合、これらはすべて壊れます。そのため、パスワードなしでログインできるように、パスワードなしでsudoセットアップしたいと思っています。 しかし、予期せぬ方法で私に逆火を起こすかもしれないという直感を持ち続けています。そのような設定に注意点はありますか？サーバー上のユーザーアカウントに対してこれを行うことを推奨/推奨しませんか？ 明確化 sudoここでは、サービスや管理スクリプトではなく、対話型ユーザーセッションでの使用について説明しています。 クラウドサーバーの使用について話している（したがって、マシンへの物理的なローカルアクセス権がなく、リモートでしかログインできない） sudoパスワードの再入力が不要なタイムアウトが設定されていることは知っています。しかし、私のコンサートは、実際にパスワードを物理的に入力するための余分な時間を無駄にすることではありません。しかし、私の考えは、パスワードをまったく処理する必要がないことでした。 暗記しなければならない場合、短すぎて安全にしたり再利用したりできない リモートアカウント用に長くて一意のパスワードを生成する場合、それをどこかに保存し（ローカルパスワードマネージャープログラムまたはクラウドサービス）、使用するたびに取得する必要がありますsudo。私はそれを避けたいと思いました。 そのため、この質問で、ある構成のリスク、注意事項、トレードオフを他の構成よりもよく理解したかったのです。 フォローアップ1 すべての回答ではsudo、個人ユーザーアカウントが侵害された場合、「簡単な」特権の昇格が可能になるため、パスワードレスは安全ではないと述べています。という事は承知しています。しかし、一方で、パスワードを使用すると、パスワードにすべての古典的なリスクが生じます（短すぎるまたは共通の文字列、異なるサービス間で繰り返されるなど）。しかし、パスワード認証を無効に/etc/ssh/sshd_configしてログイン用のキーが必要な場合は、入力しsudoやすいように単純なパスワードを使用できますか？それは有効な戦略ですか？ フォローアップ2 rootssh経由でログインするキーもある場合、誰かがコンピューターにアクセスしてキーを盗むと（OSのキーリングパスワードで保護されます！）、rootアカウントに直接アクセスできる可能性があります、sudoパスをバイパスします。その場合、rootアカウントにアクセスするためのポリシーは何ですか？

58 linux  security  password  sudo 

サーバーの侵害に関するこの質問を読んだ後、なぜ人々が検出/クリーンアップツールを使用して、またはシステムを侵害するために使用された穴を修正するだけで、侵害されたシステムを回復できると信じ続けているのか疑問に思い始めました。 ハッカーができるさまざまなルートキットテクノロジーやその他のすべてのことを考えると、ほとんどの専門家は、オペレーティングシステムを再インストールすることをお勧めします。 私は、なぜより多くの人々が軌道からシステムを脱いで核兵器にしないのか、より良いアイデアを得たいと思っています。 ここにいくつかのポイントがありますが、私は対処したいと思います。 フォーマット/再インストールがシステムをきれいにしない条件はありますか？ どのような条件下でシステムをクリーニングできると思いますか？また、いつ完全に再インストールする必要がありますか？ 完全な再インストールを行うことに反対する理由は何ですか？ 再インストールしないことを選択した場合、どの方法を使用して、クリーンアップを行い、さらなる損傷の再発を防止したと合理的に確信します。

58 hacking  security 

私のウェブサイトには、最近の訪問者のリストを表示する「隠し」ページがあります。この単一のPHPページへのリンクはまったく存在せず、理論的には私だけがその存在を知っています。1日に何度もチェックして、新しいヒットを確認します。 ただし、約1週間に1回、この非表示のページにある208.80.194。*アドレスからヒットを取得します（ヒット自体を記録します）。奇妙なことはこれです：この不思議な人/ボットはないではない訪問任意の私のサイト上の他のページを。PHPの公開ページではなく、訪問者を印刷するこの非表示ページのみ。これは常にシングルヒットであり、HTTP_REFERERは空白です。他のデータは常に Mozilla / 4.0（互換、MSIE 7.0、Windows NT 5.1、YPC 3.2.0、FunWebProducts、.NET CLR 1.1.4322、SpamBlockerUtility 4.8.4、yplus 5.1.04b） ...しかしMSIE 6.0、7の代わりに時々、その他のさまざまなプラグイン。ブラウザは、アドレスの最下位ビットと同様に、毎回異なります。 そして、それだけです。その1ページに1週間に1ヒット。この不思議な訪問者が他のページに触れていることは絶対にありません。 やってwhoisそのIPアドレスには、それがニューヨークエリアからだ、と「Websenseの」ISPから示されました。アドレスの最下位8ビットは異なりますが、それらは常に 208.80.194.0 / 24サブネットのものです。 Webサイトへのアクセスに使用するほとんどのコンピューターtracerouteから、サーバーへのアクセスには、IP 208.80。*の途中にルーターが含まれていません。そのため、あらゆる種類のHTTPスニッフィングが排除されると思います。 これはどのように、なぜ起こっているのですか？それは完全に良性のようですが、説明できず、少し気味が悪いです。

56 security  forensics 

特定のユーザーがそのアカウントのパスワードを知らなくても別のユーザーアカウントにsuできるようにしますが、他のユーザーアカウント（つまり、root）へのアクセスは許可しません。 たとえば、DBAのトムにoracleユーザーへのsuを許可しますが、tomcatユーザーまたはrootには許可しません。 これは/ etc / sudoersファイルでできると思います-可能ですか？もしそうなら、どのように？

53 linux  security  sudo 

CentOS 5.3システムでiptablesのセットアップがほぼ完了したと思います。これが私のスクリプトです... # Establish a clean slate iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT iptables -F # Flush all rules iptables -X # Delete all chains # Disable routing. Drop packets if they reach the end of the chain. iptables -P FORWARD DROP # Drop …

53 linux  security  firewall  iptables  icmp 

「S3バケットへのパブリックアクセスを一切許可しないことを強くお勧めします。」 Webサイトのホストに使用する1つのバケットに対して、非常にきめ細かいパブリックポリシー（s3：GetObject）を設定しました。Route53は、この目的でバケットのエイリアスを明示的にサポートしています。この警告は単に冗長ですか、それとも何か間違っていますか？

52 security  amazon-web-services  amazon-s3  amazon-route53 

Linuxシステムでのリモートサポート、トラブルシューティング、および/またはパフォーマンスチューニングを提供するという奇妙な要求を時々受けます。 大企業では、ベンダー/サプライヤーにリモートアクセスを提供するための手順が確立されていることがよくあり、それらに準拠する必要があるだけです。（良くても悪くても。） 一方、小さな会社や個人は、私を立ち上げるために何をする必要があるかを常に教えてくれるよう常に頼りにしています。通常、サーバーはインターネットに直接接続されており、既存のセキュリティ対策は、Linuxディストリビューションが何であれ、デフォルトで構成されています。 ほとんどの場合、ルートレベルのアクセスが必要になりますが、アクセスを設定する人はシステム管理者ではありません。ルートパスワードは必要ありません。また、自分のアクションが悪意のあるものではないと確信していますが、次のような合理的な簡単な指示を与える必要があります。 アカウントを設定し、資格情報を安全に交換します ルート（sudo）アクセスをセットアップする アカウントへのアクセスを制限する 監査証跡を提供する （はい、悪意のあるアクションを非表示にする管理者アクセス権を持っていると、クライアントに常に警告しますが、監査証跡の作成に非表示にして積極的に参加するものは何もないと仮定しましょう。） 以下の手順で何を改善できますか？ 私の現在の命令セット： アカウントを設定し、資格情報を安全に交換します パスワードハッシュを提供し、その暗号化されたパスワードでアカウントがセットアップされていることを確認します。そのため、クリアテキストパスワードを送信する必要はありません。パスワードを知っているのは私だけです。予測可能な脆弱なパスワード。 sudo useradd -p '$1$********' hbruijn 私は公開鍵SSH（クライアントごとに特定の鍵ペア）を提供し、彼らにその鍵で私のアカウントをセットアップするよう依頼します： sudo su - hbruijn mkdir -p ~/.ssh chmod 0700 ~/.ssh echo 'from="10.80.0.0/14,192.168.1.2" ssh-rsa AAAAB3NzaC1y***...***== hbruijn@serverfault' >> ~/.ssh/authorized_keys chmod 0600 ~/.ssh/authorized_keys ルート（sudo）アクセスをセットアップする クライアントにsudo sudoedit、お気に入りのエディターを使用して、または追加してsudoをセットアップし、以下に追加するよう依頼します/etc/sudoers。 hbruijn ALL=(ALL) ALL アカウントへのアクセスを制限する 通常、クライアントは引き続きパスワードベースのログインを許可/etc/ssh/sshd_configし、少なくともアカウントをSSHキーのみに制限するために、次の2行を追加するように依頼します。 Match user hbruijn …

51 linux  security  sudo  root  audit