最近（しかし、これは繰り返し起こる質問でもあります）、ハッキングとセキュリティに関する3つの興味深いスレッドを見ました：

侵害されたサーバーに対処するにはどうすればよいですか？。
ハッキングされたサーバーがハッキングされた方法を見つける
ファイルのアクセス許可に関する質問

最後の1つは直接関連していませんが、Webサーバーの管理を台無しにするのがいかに簡単かを強調しています。

いくつかのことができるので、何か悪いことが起こる前に、攻撃の裏側の影響を制限し、悲しい場合にどのように対応するかについての良い慣行に関してあなたの提案が欲しいです。

サーバーとコードを保護するだけでなく、監査、ログ記録、および対策も重要です。

グッドプラクティスのリストはありますか、またはWebサーバーを継続的に分析するソフトウェアまたは専門家に頼ることを好みますか（またはまったくありませんか）。

はいの場合、リストとあなたのアイデア/意見を共有できますか？

更新

いくつかの良い興味深いフィードバックを受け取りました。

簡単なリストを用意したいので、ITセキュリティ管理者だけでなく、Web ファクトタムマスターにも役立ちます。

誰もが正しく正しい答えを出したとしても、現時点では、Robertが最も単純で明確で簡潔であり、sysadmin1138が最も完全で正確であるため、私はRobertを好みます。

しかし、ユーザーの視点と認識を誰も考慮していません。最初に考慮する必要があると思います。

ユーザーが自分のハッキングされたサイトにいつアクセスするか、ユーザーが賢明なデータを所有している場合はそれがはるかにわかります。データをどこに保存するかだけでなく、怒っているユーザーをどのように落ち着かせるかが問題になります。

データ、メディア、当局、競合他社はどうですか？

注目すべき大きな領域が2つあります。

1. 入りにくくする
2. 過去のポイント1に到達したイベントを冷静かつ効率的に処理するためのポリシーと手順を作成します。

入りにくくする

これは非常に複雑なトピックであり、その多くは、事後に発生したWTFを把握するのに十分な情報を確保することに焦点を当てています。簡単にするための抽象的な箇条書きのポイント：

• ログを保持する（セキュリティ情報イベント管理も参照）
  • 成功した場合と失敗した場合の両方で、できればソース情報をそのままにして、許可を試みます。
  • ファイアウォールアクセスログ（使用する場合、サーバーごとのファイアウォールを含める必要がある場合があります）。
  • Webサーバーのアクセスログ
  • データベースサーバー認証ログ
  • アプリケーション固有の使用ログ
  • 可能であれば、SIEMは不審なパターンに対してアラートをスローできます。
• 適切なアクセス制御を実施する
  • すべての場所で権利が正しく設定されていることを確認し、可能な場合は「怠lazな権利」（「みんなに読んでもらう」）を避けます。
  • 手順が実際に実行されていることを確認するためのACLの定期的な監査、および一時的なトラブルシューティング手順（「全員に読んでもらい、動作するかどうかを確認する」）は、トラブルシューティングの終了後に正しく削除されました。
  • すべてのファイアウォールパススルールールを正当化し、定期的に監査する必要があります。
  • ウェブサーバーのアクセス制御も、ウェブサーバーとファイルシステムの両方のACLで監査する必要があります。
• 変更管理を実施する
  • セキュリティ環境に対する変更は、複数の人が集中的に追跡およびレビューする必要があります。
  • このプロセスにはパッチを含める必要があります。
  • 共通のOSビルド（テンプレート）を使用すると、環境が簡素化され、変更の追跡と適用が容易になります。
• ゲストアカウントを無効にします。
• すべてのパスワードがデフォルトに設定されていないことを確認してください。
  • 市販のアプリケーションは、事前定義されたパスワードを使用してユーザーをセットアップする場合があります。それらを変更します。
  • 多くのITアプライアンスには、よく知られているユーザーとパスワードのペアが付属しています。年に1回だけログインする場合でも、これらを変更します。
• 最小限の特権を実践します。ユーザーに実際に必要なアクセス権を付与します。
  • 管理ユーザーの場合、2アカウントのセットアップが賢明です。電子メールやその他のオフィスタスクに使用される通常のアカウントと、昇格されたプライベート作業に使用される別のアカウント。VMを使用すると、これを簡単に使用できます。
  • 一般的な管理者/ルートアカウントの定期的な使用を奨励しないでください。誰が何をいつ実行したかを追跡するのは困難です。

誰かが入室したイベントを落ち着いて効率的に処理するためのポリシーと手順を作成する

セキュリティイベントポリシーは、すべての組織にとって必要不可欠です。これらのようなイベントに直面すると、人々は不合理になる傾向があるため、「頭を切り落としたまま走り回る」反応の段階を大幅に減らします。侵入は大きく、恐ろしい出来事です。侵入に恥をかくことは、そうでなければレベル管理のシステム管理者が誤った反応を開始する原因になります。

組織のすべてのレベルは、ポリシーを認識する必要があります。事件が大きければ大きいほど、上級管理職が何らかの形で関与する可能性が高くなり、物事を処理するための手順を設定することは、「助け」を高いところから防ぐのに大いに役立ちます。また、組織の残りの部分とやり取りするための中間管理の手順の形で、インシデント対応に直接関与する技術者をカバーするレベルも提供します。

理想的には、お使いの災害復旧の方針は、すでに特定のサービスがでDRポリシーキックの前に利用できない可能性がありどのくらい定義しました。イベントのこれらの種類は、これは、インシデントレスポンスを助けるある災害が。イベントがリカバリウィンドウを満たさないタイプの場合（例：ホットバックアップDRサイトが変更されたデータのリアルタイムフィードを取得し、侵入者は、DRサイトに複製される前にDRサイトに複製された大量のデータを削除したしたがって、コールドリカバリ手順を使用する必要があります）、その後、上級管理職がリスク評価協議に関与する必要があります。

インシデント対応計画のいくつかのコンポーネント：

• 侵害されたシステムと公開されたデータを特定します。
• 最終的な訴追のために法的証拠を保持する必要があるかどうかを早期に判断します。
  • 証拠を保持する場合は、絶対に必要でない限り、そのシステムについて何も触れないでください。ログインしないでください。ログファイルをふるいにかけないでください。行う。ありません。接する。
  • 証拠を保持する場合、侵害されたシステムはオンラインのままにしておく必要がありますが、認定されたコンピューターフォレンジックの専門家が証拠処理ルールと互換性のある方法でシステムを分析できるようになるまで切断します。
    • 侵害されたシステムの電源を切ると、データが汚染される可能性があります。
    • ストレージシステムでこの（個別のSANデバイス）が許可されている場合、切断する前に影響を受けるLUNのスナップショットを作成し、読み取り専用のフラグを立てます。
  • エビデンス処理ルールは複雑で、簡単に台無しになります。トレーニングを受けていない限り、実行しないでください。ほとんどの一般的なシステム管理者には、この種のトレーニングはありません。
  • 証拠が保持されている場合は、サービスの損失をハードウェア損失災害として扱い、新しいハードウェアで復旧手順を開始します。
• 災害の種類に関する事前設定ルールには、通知の種類が必要です。法律と規制は地域によって異なります。
  • 「暴露」と「実証済みの妥協」に関するルールは異なります。
  • 通知ルールでは、通信部門が関与する必要があります。
  • 必要な通知が十分に大きい場合、トップレベルの管理が関与する必要があります。
• DRデータを使用して、サービスをオンラインに戻すことがより高い優先度になる前に、「WTFが発生した」時間をどれだけ費やすことができるかを決定します。
  • サービス回復時間には、何が従属しているかを把握する作業が必要になる場合があります。その場合は、サービスが復元された後、影響を受けるデバイスのドライブイメージを解剖のために取得します（これは証拠コピーではなく、技術者がリバースエンジニアリングするためです）。
  • 混乱をクリーンアップするだけでなく、影響を受けるシステムの完全な再構築を含めるように、サービス回復タスクを計画します。
  • 場合によっては、サービスの復旧時間が非常に短いため、侵害が特定された直後にディスクイメージを取得する必要があり、法的証拠は保持されません。サービスが再構築されると、何が起こったのかを把握する作業を開始できます。
• ログファイルを調べて、攻撃者がどのように侵入したか、および攻撃者が一度行ったことに関連する情報を取得します。
• 変更されたファイルをふるいにかけて、どのように侵入したか、および侵入した後に何をしたかに関する情報を探します。
• ファイアウォールログを調べて、どこから来たのか、どこにデータを送信したのか、どのくらい送信されたのかについての情報を取得します。

妥協の前にポリシーと手順を設定し、妥協のイベントでそれらを実装する人々によく知られていることは、ただやるべきことです。それは、人々がまっすぐに考えないときに、誰にでも応答フレームワークを提供します。上層部の経営者は訴訟や刑事告発について大騒ぎする可能性がありますが、実際に訴訟をまとめることは費用のかかるプロセスであり、事前に怒りを抑えることができることを知っています。

また、これらの種類のイベントは、全体的な災害対応計画に組み込む必要があることにも注意してください。妥協は、「ハードウェア紛失」応答ポリシーをトリガーする可能性が非常に高く、また「データ損失」応答をトリガーする可能性が非常に高くなります。サービスの復旧時間を知ることは、サービス復旧に必要になる前に、セキュリティ対応チームが実際の侵害されたシステム（法的証拠を保持していない場合）に注ぐことができる時間を予測するのに役立ちます。

適切なヘルプデスク手順がどのように役立つか

ここで顧客の対処方法を検討する必要があります（これは、ヘルプデスクに連絡する内部および外部の両方の顧客に適用されます）。

まず、コミュニケーションが重要です。ユーザーはビジネスの混乱に腹を立て、侵入の一部として発生した可能性のある情報侵害の範囲/結果についても懸念する場合があります。これらの人々に情報を提供し続けることは、知識の共有が良いという観点から、そしておそらくあなたが聞く必要があることの1つはあなたがコントロールしているという少しわかりにくい観点から、彼らの怒りと懸念を管理するのに役立ちます状況。

ヘルプデスクとIT管理はこの時点で「傘」として機能し、作業を行う人々を保護して侵入の程度を判断し、その作業を中断する無数の問い合わせからサービスを復元する必要があります。

1. 現実的な更新を顧客に試みて投稿し、顧客と協力して、サービスをオンラインに戻す緊急性を判断します。顧客のニーズを認識することは重要ですが、同時に、顧客に実行不可能なスケジュールを指示することを許可しないでください。
2. ヘルプデスクチームは、情報の公開の有無を把握し、噂や憶測を助長してはなりません（また、組織が法的措置をとる、または直面する可能性のある行為を絶対に議論すべきではありません）。
3. ヘルプデスクが行うべきポジティブなことの1つは、侵入に関連するすべての呼び出しを記録することです。これは、侵入自体とそれに対処するために続いたプロセスの両方によって引き起こされる混乱の測定に役立ちます。侵入と緩和に時間と金銭的コストの両方をかけることは、将来の戦略を改良するのに非常に役立ち、明らかに法的措置に役立つことが明らかになります。ここでは、ITILインシデントと問題の記録が役立ちます。侵入自体と軽減策の両方を個別の問題として記録し、各発信者を一方または両方の問題のインシデントとして追跡できます。

展開標準がどのように役立つか

セットテンプレート（または少なくともチェックリスト）に展開することも、展開テンプレートのカスタマイズ/アップグレードに対する変更管理/管理の実践と共に役立ちます。さまざまなジョブを実行するサーバー（メールサーバーテンプレート、Webサーバーテンプレートなど）を説明する複数のテンプレートを作成できます。

テンプレートは、OSとアプリの両方で機能し、セキュリティだけでなく、使用するすべての設定が含まれている必要があり、人的エラーを可能な限り排除するために、手動（チェックリストなど）で適用するのではなく、スクリプト（テンプレートなど）であることが理想的です。

これはいくつかの方法で役立ちます。

• 侵入が発生した場合、より迅速に復元/再構築できます（脆弱性があることがわかっているため、このテンプレートから「そのまま」デプロイしないでください。ただし、「最後に確認された適切な構成」 「ライブデプロイメントの前にさらに強化する必要があります。また、適切にロックダウンされていることが確認できたら、デプロイメントテンプレートを更新することを忘れないでください）
• ハッキングされたサーバーを比較するための「ベースライン」を提供します
• そもそも侵入につながる可能性のある不必要なエラーを削減します
• セキュリティ（またはその他の理由）のためにパッチ/アップグレードまたは手順の変更が必要であることが明らかになった場合、変更が必要なシステムを簡単に確認でき、テストの作成が容易になるため、変更およびパッチ管理を支援します。変更が正しく適用されているかどうかを確認するなど）。
• すべてが可能な限り一貫性があり、賢明であれば、異常で疑わしいイベントをそれよりもさらに際立たせるのに役立ちます。

ほとんどのサーバーでは、ホストおよびネットワークファイアウォール、ウイルス対策/スパイウェア対策ソフトウェア、ネットワークIDS、およびホストIDSを使用して、ほとんどの防御を行っています。これには、最小権限、アンインストールされた必須ではないプログラム、更新などのすべての一般的なガイドラインが含まれます。そこから、Nagios、Cacti、SIEMソリューションなどの製品を使用して、さまざまなベースライニングとイベント発生時の通知を行います。HIDS（OSSEC）は、多くのSIEMタイプのロギングも実行します。基本的には可能な限りブロックすることを試みますが、何かが発生した場合は分析して相関させることができるように、中央でログに記録します。

本当に欲しいものは、次の3つの基本領域に分類できます。

1. 標準システム構成
2. システム/アプリケーションの監視
3. インシデント対応

情報（保証|セキュリティ）スタッフがいる場合は、間違いなく彼らに相談してください。多くの場合、インシデント対応は当該オフィスの唯一の範囲ですが、残りは影響を受けるすべての関係者の共同開発努力である必要があります。

自己ポンピングのリスクがあるため、関連する質問へのこの回答は、多くの有用なリソースのインデックスを作成する必要があります。LAMPサーバーを保護するためのヒント。

理想的には、サポートされるOSの数を最小限にし、ベースイメージを使用して各OSをビルドする必要があります。サーバーが提供するサービスを提供するために必要なだけ、ベースから逸脱する必要があります。逸脱は文書化する必要がありますが、PCI / HIPAA /などを満たす必要がある場合は必要になる場合があります。またはその他のコンプライアンス。この点で、展開および構成管理システムを使用すると非常に役立ちます。詳細は、OS、cobbler / puppet / Altiris / DeployStudio / SCCMなどに大きく依存します。

何らかの定期的なログレビューを必ず実行する必要があります。オプションを考えると、SIEMは非常に役立ちますが、購入価格とビルドコストの両方で高価になるという欠点もあります。ログ分析に関するコメントについては、ITセキュリティSEサイトからこの質問を確認してください。ログ分析をどのように処理しますか？ それでもこれが重すぎる場合は、LogWatchなどの一般的なツールでさえ、何が起こっているのかについて良いコンテキストを提供できます。ただし、重要なのは、ログを見るだけの時間をかけることです。これは、正常な動作を構成するものを知るのに役立ち、異常を認識することができます。

ログのレビューに加えて、サーバーの状態を監視することも重要です。計画されているかどうかにかかわらず、変更がいつ発生するかを知ることは非常に重要です。Tripwireなどのローカル監視ツールを使用すると、管理者に変更を警告できます。残念ながら、SIEMやIDSと同様に、チューニングや購入に費用がかかるという欠点があります。さらに、適切なチューニングを行わないと、アラートのしきい値が非常に高くなり、良いメッセージはノイズで失われ、役に立たなくなります。

適切なセキュリティ情報およびイベント管理（SIEM）ポリシーを導入することで、セキュリティの寿命を延ばすことができます。

私はセキュリティの専門家ではないので、主に彼らに任せます。しかし、最小特権のプリンシパルから始めると、ほとんど常に彼らの仕事が非常に簡単になります。ファイルのパーミッション、ランタイムユーザー、ファイアウォールルールなど：ヒーリング軟膏のようにこれを適用すると、セキュリティの多くの側面に適していますKISSのいずれか痛いことはありません。

ここで説明したソリューションのほとんどは、ホストおよびネットワークレベルで適用できますが、多くの場合、安全でないWebアプリケーションを忘れています。Webアプリケーションは、最も一般的に見過ごされているセキュリティホールです。Webアプリケーション経由で、攻撃者はデータベースまたはホストにアクセスできます。ファイアウォール、IDS、ファイアウォールはそれらに対してあなたを保護できません。OWASPは、トップ10の最も重大な脆弱性のリストを維持し、それらの修正を提供します。

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide