ハッキング防止、フォレンジック、監査および対策
最近（しかし、これは繰り返しの質問でもあります）、ハッキングとセキュリティに関する3つの興味深いスレッドを見ました。
侵害されたサーバーに対処するにはどうすればよいですか？ 。
ハッキングされたサーバーがどのようにハッキングされたかを見つける
ファイルパーミッションの質問
最後のものは直接関係していませんが、Webサーバーの管理を台無しにするのがいかに簡単かを強調しています。
できることがいくつかあるので、before何か悪いことが起こるので、私は欲しいです攻撃の裏側への影響を制限するためのグッドプラクティスと、悲しい場合にどのように対応するかについての提案があります。
サーバーとコードを保護するだけでなく、監査、ロギング、対策も重要です。
グッドプラクティスリストはありますか、それともWebサーバーを継続的に分析する（またはまったく分析しない）ソフトウェアまたは専門家に依存することを好みますか？
はいの場合、あなたのリストとあなたのアイデア/意見を共有できますか？
[〜＃〜]更新[〜＃〜]
私はいくつかの良い興味深いフィードバックを受け取りました。
簡単なリストが欲しいので、ITセキュリティ管理者だけでなくWebfactotumマスターにも便利です。
誰もが正しく正しい答えを出したとしても、現時点ではRobertの方が最もシンプルで明確で簡潔であり、sysadmin1138は、最も完全で正確です。
しかし、ユーザーの視点や認識を誰も考慮していません。最初に考慮しなければならないのはそれだと思います。
あなたがそれらについての賢明なデータを所有している場合、ユーザーが私のハッキングされたサイトにいつアクセスするかを考えるでしょう。データをどこに保存するかだけでなく、怒っているユーザーを落ち着かせる方法も重要です。
データ、メディア、当局、競合他社はどうですか？
焦点を当てるべき2つの大きな領域があります。
- 入りづらくなります。
- 誰かが過去のポイント1に陥った場合に、落ち着いて効率的に対処するためのポリシーと手順を作成します。
入りにくい
これは非常に複雑なトピックであり、その多くは、事後にWTFが発生したことを理解するのに十分な情報があることを確認することに焦点を当てています。簡単にするための抽象的な箇条書き：
- ログを保持します（セキュリティ情報イベント管理も参照）
- 成功と失敗の両方で、できればソース情報をそのままにして、承認を試みます。
- ファイアウォールアクセスログ（使用中の場合、これにはサーバーごとのファイアウォールを含める必要がある場合があります）。
- Webサーバーアクセスログ
- データベースサーバー認証ログ
- アプリケーション固有の使用ログ
- 可能であれば、SIEMは疑わしいパターンについてアラートをスローできます。
- 適切なアクセス制御を実施する
- 権利がどこでも正しく設定されていることを確認し、可能な場合は「怠惰な権利」（「すべての人に読んでもらう」）を避けてください。
- 手順が実際に実行されていることを確認するためのACLの定期的な監査、および一時的なトラブルシューティング手順（「全員に読んでもらい、それが機能するかどうかを確認する」）は、トラブルシューティングの終了後に正しく削除されました。
- すべてのファイアウォールパススルールールは正当化され、定期的に監査される必要があります。
- WebサーバーとファイルシステムのACLの両方で、Webサーバーのアクセス制御も監査する必要があります。
- 変更管理を実施する
- セキュリティ環境への変更は、複数の人が一元的に追跡および確認する必要があります。
- このプロセスにはパッチを含める必要があります。
- 共通のOSビルド（テンプレート）を使用すると、環境が簡素化され、変更の追跡と適用が容易になります。
- ゲストアカウントを無効にします。
- すべてのパスワードがデフォルトに設定されていないことを確認してください。
- 既製のアプリケーションは、事前定義されたパスワードを使用してユーザーをセットアップする場合があります。それらを変更します。
- 多くのITアプライアンスには、非常によく知られているユーザーとパスワードのペアが付属しています。 1年に1回しかログインしない場合でも、それらを変更してください。
- 最小特権を実践します。ユーザーに実際に必要なアクセス権を与えます。
- 管理者ユーザーの場合、2つのアカウントを設定するのが賢明です。 1つは電子メールやその他のオフィスタスクに使用される通常のアカウントで、もう1つは昇格されたプライベートの作業に使用されます。 VMを使用すると、これを簡単に使用できます。
- 一般的な管理者/ルートアカウントの定期的な使用を推奨しないでください。誰がいつ何をしていたかを追跡するのは困難です。
誰かが侵入したイベントを落ち着いて効率的に処理するためのポリシーと手順を作成する
セキュリティイベントポリシーは、すべての組織にとって必須です。このようなイベントに直面すると人々は不合理になる傾向があるため、応答の「頭を切り落として走り回る」フェーズを大幅に削減します。侵入は大きくて恐ろしい事件です。侵入に苦しむことの恥は、そうでなければレベルの高いシステム管理者が誤った反応を開始する原因となる可能性があります。
組織のすべてのレベルがポリシーを認識する必要があります。事件が大きければ大きいほど、上級管理職が何らかの形で関与する可能性が高くなり、物事を処理するための手順を設定することは、上からの「助け」をかわすのに大いに役立ちます。また、中間管理職が組織の他の部分とやり取りするための手順の形で、インシデント対応に直接関与する技術者に一定レベルのカバーを提供します。
理想的には、ディザスタリカバリポリシーは、DRポリシーが開始される前に特定のサービスが利用できない期間をすでに定義しています。これは、これらの種類のイベントare災害であるため、インシデント対応に役立ちます。イベントがリカバリウィンドウに対応しないタイプの場合（例：ホットバックアップDRサイトが変更されたデータのリアルタイムフィードを取得し、侵入者がDRサイトに複製される前に複製された一連のデータを削除したしたがって、コールドリカバリー手順を使用する必要があります）、その後、上級管理職がリスク評価の話し合いに参加する必要があります。
インシデント対応計画の一部のコンポーネント：
- 侵害されたシステムと公開されたデータを特定します。
- 最終的な起訴のために法的証拠を保持する必要があるかどうかを早期に判断します。
- 証拠を保持する場合絶対に必要な場合を除いて、そのシステムについては何も触れないでください。ログインしないでください。ログファイルをふるいにかけないでください。行う。そうではありません。接する。
- 証拠を保持する場合は、侵害されたシステムをそのままにしておく必要がありますオンラインしかし切断認定されたコンピュータフォレンジックの専門家が証拠と互換性のある方法でシステムを分析できるようになるまで取り扱い規則。
- 侵害されたシステムの電源を切ると、データが汚染される可能性があります。
- ストレージシステムでこれが許可されている場合（ディスクリートSANデバイス））、影響を受けるLUNを切断する前にスナップショットを作成し、読み取り専用のフラグを付けます。
- 証拠処理のルールは複雑で、簡単に台無しになります。あなたがそれらの訓練を受けていない限り、それをしないでください。ほとんどの一般的なシステム管理者は、この種のトレーニングを受けていません。
- 証拠が保持されている場合は、サービスの喪失をハードウェア喪失の災害として扱い、新しいハードウェアで回復手順を開始します。
- どのような災害について事前に設定されたルールには、どのような通知が必要です。法律と規制は地域によって異なります。
- 「暴露」と「証明された妥協」に関する規則は異なります。
- 通知ルールでは、コミュニケーション部門が関与する必要があります。
- 必要な通知が十分に大きい場合は、トップレベルの管理者が関与する必要があります。
- DRデータを使用して、サービスをオンラインに戻す前に「WTFが発生したばかり」の時間をどれだけ優先できるかを判断します。
- サービスの復旧時間には、何が劣後したのかを把握する作業が必要になる場合があります。その場合は、サービスが復元された後、影響を受けたデバイスのドライブイメージを撮影して解剖します（これは証拠となるコピーではなく、技術者がリバースエンジニアリングするためのものです）。
- 混乱をクリーンアップするだけでなく、影響を受けるシステムの完全な再構築を含むようにサービス回復タスクを計画します。
- 場合によっては、サービスの回復時間が非常に短いため、侵害が発生したことを特定した直後にディスクイメージを取得する必要があり、法的証拠は保持されません。サービスが再構築されると、何が起こったのかを把握する作業を開始できます。
- 攻撃者がどのように侵入したか、および攻撃者が一度に何をした可能性があるかに関する情報については、ログファイルをふるいにかけてください。
- 変更されたファイルをふるいにかけて、どのように侵入したか、および侵入後に何をしたかに関する情報を確認します。
- ファイアウォールログをふるいにかけて、どこから来たのか、どこにデータを送信したのか、どれだけのデータが送信されたのかを確認します。
ポリシーと手順を実施する前妥協案であり、妥協案が発生した場合にそれらを実装する人々によく知られていることは、実行する必要があることです。それは人々がまっすぐに考えない時に誰にでも応答フレームワークを提供します。上級管理職は訴訟や刑事告発について雷鳴やブームを起こす可能性がありますが、実際に訴訟をまとめるのは高価プロセスであり、事前に怒りを和らげるのに役立つことを知っています。
また、これらの種類のイベントは、全体的な災害対応計画に含める必要があることにも注意してください。侵害は、「ハードウェアの紛失」応答ポリシーをトリガーする可能性が非常に高く、「データ損失」応答もトリガーする可能性があります。サービスの復旧時間を知ることは、セキュリティ対応チームがサービスの復旧に必要になる前に、実際の侵害されたシステム（法的証拠を保持していない場合）に注ぐためにどれだけの時間を確保できるかを予測するのに役立ちます。
適切なヘルプデスク手順がどのように役立つか
ここでは、顧客がどのように扱われるかを検討する必要があります（これは、ヘルプデスクに連絡する内部および外部の顧客の両方に適用されます）。
まず第一に、コミュニケーションは重要です;ユーザーはビジネスの混乱に腹を立て、侵入の一部として発生した可能性のある情報侵害の範囲/結果についても懸念する可能性があります。これらの人々に情報を提供し続けることは、知識を共有することは良いという観点から、そしておそらく少しわかりにくい観点から、彼らが聞く必要があることの1つはあなたがあなたをコントロールしているという観点から、彼らの怒りと懸念を管理するのに役立ちます状況。
ヘルプデスクとIT管理者は、この時点で「傘」として機能する必要があり、侵入の程度を判断し、その作業を中断させる無数の問い合わせからサービスを復元するために、作業を行う人々を保護します。
- 現実的な更新を顧客に投稿してみて、顧客と協力して、サービスをオンラインに戻す緊急性を判断します。顧客のニーズを認識することは重要ですが、同時に、顧客が実行不可能なスケジュールをあなたに指示することを許可しないでください。
- ヘルプデスクチームが、公開できる情報と公開できない情報を把握し、噂や憶測を助長してはならないことを確認してください（また、組織がとるまたは直面する可能性のある法的措置を損なう可能性のあることについて話し合うべきではありません）。
- ヘルプデスクが行うべき1つの前向きなことは、侵入に関連するすべての呼び出しを記録することです。これは、侵入自体とそれに続くプロセスの両方によって引き起こされた混乱を測定するのに役立ちます。侵入と軽減に時間と経済的コストの両方をかけることは、将来の戦略を洗練するのに非常に役立つ可能性があり、明らかにあらゆる法的措置に役立つ可能性があります。 ITILインシデントと問題の記録 ここで役立ちます-侵入自体と軽減の両方を個別の問題として記録し、各発信者を一方または両方の問題のインシデントとして追跡できます。
展開標準がどのように役立つか
セットテンプレート（または少なくともチェックリスト）に展開することも、展開テンプレートのカスタマイズ/アップグレードに対する変更の制御/管理を実践するのに役立ちます。さまざまなジョブを実行するサーバーを説明するために、複数のテンプレートを使用できます（たとえば、メールサーバーテンプレート、Webサーバーテンプレートなど）。
テンプレートはOSとアプリの両方で機能し、セキュリティだけでなく、使用するすべての設定が含まれている必要があります。理想的には、手動で適用するのではなく、スクリプト化する必要があります（テンプレートなど）。チェックリスト）ヒューマンエラーを可能な限り排除します。
これは、いくつかの点で役立ちます。
- 侵入が発生した場合に、より迅速に復元/再構築できるようにします（このテンプレートから展開しないでください。 know脆弱ですが、さらに強化する必要がある「最後の既知の良好な構成」に戻ることができますライブデプロイメントの前...そして、適切にロックダウンされていることを確認したら、デプロイメントテンプレートを更新することを忘れないでください）
- ハッキングされたサーバーを比較するための「ベースライン」を提供します
- そもそも侵入につながる可能性のある不要なエラーを削減します
- セキュリティのためにパッチ/アップグレードまたは手順の変更が必要であることが明らかになった場合（またはその他の理由）、変更が必要なシステムを簡単に確認できるため、変更とパッチ管理に役立ちます。テストの作成も簡単になります。変更が正しく適用されているかどうかを確認するなど）。
- すべてが可能な限り一貫していて賢明である場合、それは異常で疑わしいイベントをさらに少し目立たせるのに役立ちます。
ほとんどのサーバーでは、防止の大部分をホストとネットワークファイアウォール、ウイルス対策/スパイウェアソフトウェア、ネットワークIDS、およびホストIDSに依存しています。これは、最小限のプライバシー、アンインストールされた必須ではないプログラム、更新などのすべての一般的なガイドラインとともに行われます。そこから、Nagios、Cacti、SIEMソリューションなどの製品を使用して、さまざまなベースライニングとイベント発生時の通知を行います。私たちのHIDS（OSSEC）は、多くのSIEMタイプのロギングも実行します。これは素晴らしいことです。基本的には可能な限りブロックを行うようにしていますが、何かが発生した場合に分析して相互に関連付けることができるように、一元的にログに記録します。
あなたが本当に欲しいものは3つの基本的な領域に分類できます：
- 標準システム構成
- システム/アプリケーションの監視
- インシデント対応
情報（保証|セキュリティ）スタッフがいる場合は、必ず彼らに相談してください。多くの場合、インシデント対応は当該オフィスの唯一の権限ですが、残りは影響を受けるすべての関係者間の共同開発努力である必要があります。
自己ポン引きのリスクがありますが、関連する質問へのこの回答は、多くの有用なリソースのインデックスを作成する必要があります。 LAMPサーバーを保護するためのヒント
理想的には、サポートされているOSの数を最小限に抑え、ベースイメージを使用して各OSを構築する必要があります。サーバーが提供するサービスを提供するために必要なだけ、ベースから逸脱する必要があります。逸脱は文書化する必要があります。または、PCI/HIPAAなどを満たす必要がある場合は必要になる場合があります。またはその他のコンプライアンス。展開および構成管理システムを使用すると、この点で大いに役立ちます。詳細は、OS、cobbler/puppet/Altiris/DeployStudio/SCCMなどに大きく依存します。
必ず何らかの定期的なログレビューを実行する必要があります。オプションを指定すると、SIEMは非常に役立つ可能性がありますが、購入価格と構築コストの両方で高価になるという欠点もあります。ログ分析に関するコメントについては、IT Security SEサイトからこの質問を確認してください。 ログ分析をどのように処理しますか？ これがまだ重すぎる場合は、LogWatchなどの一般的なツールでも適切なコンテキストを提供できます。どうしたの。ただし、重要なのは、時間をかけてログを確認することです。これにより、正常な動作の構成要素を理解し、異常を認識できるようになります。
ログの確認に加えて、サーバーの状態を監視することも重要です。計画されているかどうかにかかわらず、変更がいつ発生するかを知ることは非常に重要です。 Tripwire などのローカル監視ツールを利用すると、管理者に変更を警告できます。残念ながら、SIEMやIDSと同様に、調整や購入に費用がかかるという欠点があります。さらに、適切な調整を行わないと、アラートのしきい値が非常に高くなるため、適切なメッセージはノイズで失われ、役に立たなくなります。
適切な セキュリティ情報およびイベント管理 （SIEM）ポリシーを設定すると、セキュリティをより簡単にするのに大いに役立ちます。
ここで説明するソリューションのほとんどは、ホストおよびネットワークレベルで適用できますが、安全でないWebアプリケーションを忘れることがよくあります。 Webアプリケーションは、最も一般的に見過ごされているセキュリティホールです。 Webアプリケーションを介して、攻撃者はデータベースまたはホストにアクセスする可能性があります。ファイアウォール、IDS、ファイアウォールはそれらからあなたを保護することはできません。 OWASPは、最も重大な脆弱性のトップ10のリストを維持し、それらの修正を提供します。
私はセキュリティの専門家ではないので、主に彼らに任せています。ただし、 最小特権の原則 から始めると、ほとんどの場合、作業が大幅に簡単になります。これを癒しの軟膏のように適用すると、ファイルのアクセス許可、ランタイムユーザー、ファイアウォールルールなど、セキュリティの多くの側面でうまく機能します。 [〜＃〜] kiss [〜＃〜] どちらも傷つけることはありません。