☰

予算内で Web サーバーへのセキュリティ脅威に対処する正しい方法

tag-icon • tag-icon nginx security vps postgresql ddos
予算内で Web サーバーへのセキュリティ脅威に対処する正しい方法

年次セキュリティ レビュー中に、今年初めに組織の Web サーバーに脅威が及んだ事件を思い出しました。組織のポリシーに関するもので、サイトを DDoS 攻撃すると脅迫されていました。幸い、何も悪いことは起こらず、脅しは空虚なものでした。しかし、CIO、CSO、CEO、ホスティング プロバイダーにすぐに通知し、対応を称賛されました。私たちの組織 (教育) の性質上、先制的な対応には地元の警察との調整を含め、多くの人が関与しました。

私たちの対応は空虚な脅しとしては十分でしたが、Web アプリに対する攻撃計画がいかに不十分であったかを実感しました。現在の設定は次のとおりです。

  • エンタープライズファイアウォールの背後にない Linode VPS (これには説明する価値のない長いストーリーがあります)
  • ローカル接続のみを許可する同じサーバー上のPostgreSQL DB
  • 現在、セキュリティを確保するためにベストプラクティスに従っているNginxサーバー[1]
  • 証明書認証に移行中のSSHアクセス
  • 最新のサーバー設定がすべて備わっており、最新バージョンのコードをプッシュしてデータベース設定を移行するだけでよいバックアップ VPS (現在はテスト サーバーとして使用されていますが、地理的冗長性オプションとしても想定されています)

私の質問は、DDoS攻撃からサーバーを保護するだけでなく、サーバーをロックダウンするために他にどのような手順を踏めばよいかということに集約されると思います。CloudflareビジネスDDoS 保護機能付きですが、常に必要なわけではなく、組織にとって 1 か月あたり 200 ドルは少々高額です。これは本当に必要なのでしょうか? 一時的な DDoS 保護を可能にするソリューションはありますか? ない場合、攻撃中/攻撃後に安定性を維持する最善の方法は何ですか? 最後に、攻撃が発生した場合に法執行機関を支援できるように、どのようなログ記録を実装する必要がありますか?

答え1

サーバーをロックダウンし、DDoS から保護するには、他にどのような手順を踏む必要がありますか?

  1. 使用されていないポートとプロトコルをファイアウォールで遮断します。適用可能であれば、信頼できる IP のみにアクセスを制限します。
  2. すべてのセキュリティパッチとアップデートをタイムリーに適用する
  3. 疑わしいアクティビティの急増を警告できるネットワークモニターを実装する

組織にとって月額 200 ドルは少々高額です。本当に必要なのでしょうか?

いいえ。価値が高まり、必須アイテムになるまではそうはなりません。

一時的な DDoS 保護を可能にするソリューションはありますか?

はい。DDoS サービスの実装に伴う複雑な問題を解決するために、かなりの先行投資が必要になる場合があります。 http://www.blacklotus.net/protect/emergency-ddos-protectionはそのようなオンデマンド サービスの 1 つです。

そうでない場合、攻撃中/攻撃後に安定性を維持するための最善の方法は何ですか?

ただ座って我慢するだけです。それが DDoS の本質です。IP をファイアウォールで遮断することもできますが、攻撃が実際に分散している場合は...それは水鉄砲で山火事と戦うようなものです。

最後に、攻撃が発生した場合に法執行機関を支援できるように、どのようなログ記録を実装する必要がありますか?

受信ソース IP とタイムスタンプ、およびその他の関連するフォレンジック データのログを維持します。たとえば、Web サーバーの場合は、ユーザー エージェント、要求されたリソースをログに記録します。1 秒あたりのパケット数や 1 秒あたりの要求数などのトラフィック レートが役立ちます。

DDoS は数学的分析に帰着します。誰かがあなたから金を巻き上げようとしている場合、彼らはあなたのビジネスを混乱させ、それを防ぐためにあなたに保護費を支払わせることができると賭けています。規模は要因であり、小規模な事業者を倒すのは簡単ですが、支払う金額は少なくて済みます。電子メールの脅威を受けた場合、最善の行動はそれを無視することです。DDoS 攻撃を開始して維持するには、かなりのボットネット リソースが必要です。彼らはスパマーのように全員を一斉に攻撃することはできません。彼らはおそらく、脅迫しやすいターゲットを探して、大規模なフィッシング攻撃を行っているだけです。DDoS の獣の性質上、被害者は高度なパケット フィルタリング防止スキームを展開するか、外部サービスと契約する予算がない限り、かなり無力です。

答え2

inetplumber さんの回答は素晴らしいです。

もう 1 つのオプションとして、アプリをスケールするように構成し、ユーザーに影響を与えずに大規模な攻撃に対処できるようにすることを付け加えておきます。たとえば、Amazon AWS に仮想プライベート クラウド (VPC) を設定し、PostgreSQL サーバーに VPC 内からのみアクセスできるようにします。ロード バランサー フロントエンドを設定して、複数のサーバー間で負荷を分散できます。

この方法の利点は、先行投資なしで、すぐに数百台 (またはそれ以上) のサーバーに拡張でき、(すでに構成済みの場合) 非常に迅速に拡張できるため、攻撃の標的になりにくくなることです。実際に攻撃を受けている時間帯にのみ、これらのサーバーに対して料金を支払う必要があります。攻撃を受けていないときは、1 台の Web サーバーと 1 台のデータベース サーバーに対してのみ料金を支払う必要があります。

難しいのはセットアップで、現在の構成よりも確かに多少複雑です。急速にスケールアップするためのセットアップには、さらに多くの作業が必要になります。しかし、計画するためにできることを探している場合 (特に、他の問題により、将来的にターゲットになる可能性があると考えている場合)、これがそれです。

答え3

サーバーをロックダウンし、DDoS から保護するには、他にどのような手順を踏む必要がありますか?

  1. ウェブアプリがインタラクティブではなく、コンテンツを表示するだけの場合: nginx + proxy-cache を短いキャッシュ時間 (通常は 1 ～ 5 分で十分) で使用します。これによりパフォーマンスが大幅に向上し、攻撃者はより多くのリソースを割り当てる必要が生じます。

  2. 不要なものをすべてフィルタリングする制限付きファイアウォールを設定する内外にINPUT/OUTPUT/FORWARD-Policy を DROP に設定し、すべての送信接続試行をログに記録するようにしてください (UPD ポート 53 を除く :)

  3. SSH を静的管理 IP に制限できない場合は、22222 などの代替の高ポートを使用してください。これにより、「hello mcfyl - someone in there」という大量のメッセージを防ぐことができます。

  4. さらに、ブルートフォース攻撃からSSHを保護するために、fail2ban/denyhostsを使用します。

  5. 管理者リソースがある場合: OSSECと軽量WAFを使用します(nginx用のnaxsiがあり、軽量でmod_securityほど面倒ではありません)が、そのようなインストールをセットアップして維持する人が必要になります。

  6. バックアップを実装し、スタンバイサーバーをバックアップターゲットとして使用する

  7. Web アプリケーション コードを最新の状態に保ってください。オープン ソース プロジェクトを使用する場合は、セキュリティ メーリング リストに登録してください。

  8. 脆弱性が多いことが知られているソフトウェアを避けるようにしてください

  9. admin-login や managament-webapps を使用する場合: それらのログインに対して基本認証 + SSL を確立します (自己署名証明書は OK)。

  10. 開発などのためにポートを開く代わりに、可能な場合はSSHトンネリングを使用します。

そうでない場合、攻撃中/攻撃後に安定性を維持するための最善の方法は何ですか？

  1. 冷静さを保つ
  2. そのような場合に備えて経験のある人が手元にいる
  3. 緊急時の計画を用意しておく

あなたがすでにやった最も重要なこと：それが起こる前にそれについて（そして可能な対策について）考えること。

関連情報