(外部ネットワーク監視ではなく)サービス実装でDOSを検出および防止するためのベストプラクティスを探しています。このサービスは、ユーザー、グループ、および属性情報のクエリを処理します。
DOSの取り扱いに関するお気に入りの情報源は何ですか?
(外部ネットワーク監視ではなく)サービス実装でDOSを検出および防止するためのベストプラクティスを探しています。このサービスは、ユーザー、グループ、および属性情報のクエリを処理します。
DOSの取り扱いに関するお気に入りの情報源は何ですか?
DoS攻撃に対して何をするにしても、悪意のある要求や不要な要求を処理するために必要な負荷が実際に増加する可能性があるかどうかを考えてください。
Linuxを使用している場合は、次の記事を読む必要があります。
ルールベースのDoS攻撃防止シェルスクリプト(Linux Gazetteから)次のトピックがあります。
iptablesでブロックされたIPの数を適切に制限せずにこれを適用すると、未承諾の要求を処理するために必要なリソースが増えるため、DoS脆弱性が発生する可能性があります。そのリスクを軽減するには、ipsetを使用してiptablesのIPアドレスを照合します。
また、 iptablesを使用したssh辞書攻撃の防止についても読んでください。(ここで提案されているステートフルファイアウォールでiptablesを有効にしても、ほとんどのDoS攻撃を防ぐことはできませんが、RAMを無用な状態情報で汚染するDoS攻撃を実際に緩和する可能性があります。)
Linuxは初めてですか?WindowsからLinuxへのロードマップを読んでください:パート5。IBMのLinuxロギング。
幸運を!
これは私が非常に便利だと思ったテクニックです。
DoS 脆弱性を解決するための最初の試みとして、Gulzar が提案したアプローチを使用しました。これは基本的に、同じ IP アドレスから許可される呼び出しの数を制限することです。これは良いアプローチだと思いますが、残念ながら、私のコードはパフォーマンス テストに失敗しました。
パフォーマンス テスト グループにテストを変更してもらうことができなかったので (技術的な問題ではなく、政治的な問題です)、構成可能な間隔で許可される呼び出しの数を制限するように変更しました。通話の最大数と時間間隔の両方を構成可能にしました。また、制限を無効にする 0 または負の値を設定することもできました。
保護する必要のあるコードは、複数の製品で内部的に使用されています。そこで、各製品グループに QA およびパフォーマンス テスト スイートを実行してもらい、実際の DoS 攻撃を制限するためにできるだけ小さいデフォルト値を考え出しましたが、それでもすべてのテストに合格しました。
FWIW、時間間隔は 30 秒で、呼び出しの最大数は 100 でした。これは完全に満足のいくアプローチではありませんが、シンプルで実用的であり、企業のセキュリティ チームによって承認されました (別の政治的考慮事項)。