まず、DoS 攻撃を防ぐためにできることは何もありません。
あなたにできることは、コードを分かりやすく (開発者)、アーキテクチャを堅牢にする (システム管理者) ことだけです。それは共同の努力です。
開発者は、DoS 攻撃だけでなく、仕事の一環としてリソースの使用を最小限に抑えるように努める必要があります。
開発者はキャッシュを使用してデータベースを保護する必要があります。すべてのリクエストで国のリストを参照する必要がある場合、データベースからそのリストを毎回リクエストするのは良い方法ではありません。
開発者は、不正なリクエストができるだけ早く失敗するようにする必要があります。例えば。口座番号が実際に存在することを確認するまでは、Countries リストを参照しないでください。
開発者は、セッションをメモリに保持するのではなく、各リクエストを個別に処理する REST などのアプローチを採用する必要があります。これにより、攻撃中にメモリ使用量が急上昇するのを防ぐことができます。メモリの問題やネットワークのフラッディングは避けたいものです。
開発者は、アプリケーションをスケーラブルにする必要があります。繰り返しますが、REST はここで役立ちます。なぜなら、メモリに何かを保存することに縛られていないからです。アプリケーションの 10 個のインスタンスを一度に実行し、それぞれがリクエストのサブセットを処理できる場合、DoS 攻撃にさらされる時間が長くなります (いずれにせよ、ユーザーによりスムーズな Web サイト エクスペリエンスが提供される可能性があります)。
システム管理者は、このスケーラビリティを管理するために、負荷分散、フェイルオーバーなどのフレームワークを提供する必要があります。また、インスタンスのハードウェアも管理します。また、必要に応じてインスタンスを自動的に追加するオプションを使用することもできます。つまり、サーバーの自動作成とデプロイが重要になります。物理ボックスではなく VM を使用すると、これに役立ちます。
システム管理者は、ファイアウォールとプロキシを設定して、攻撃が発生したときに、REAL トラフィックの通過を維持し、攻撃トラフィックを阻止できるようにすることができます。疑わしい IP 範囲でトラフィックをフィルタリングしたり、「疑わしい」リクエストをブロックしたり、トラフィック レベルを穏やかなフローに調整したりできます。
全体として、DoS は単なる「大量のトラフィック」と見なすことができます。アプリケーション コードとアーキテクチャが「通常のユーザー」からのトラフィックの増加に対応できない場合は、DoS 攻撃に関係なく、どうせ運命づけられています。Facebook が DoS の脅威にさらされたとき、誰かが「Facebook にとっては毎日が DDoS 攻撃です...」と指摘したことを覚えています。しかし、それは対処できるように開発され、構造化されています。