長いチェーンでiptablesパフォーマンス

長いチェーンでiptablesパフォーマンス

iptablesの長いチェーンがパフォーマンスの問題を引き起こす可能性があるかどうか疑問に思います。ここで、長いチェーンは2,500を超える個々のIP禁止にすることができます。

私が心配しているのは、iptablesに関する私の限られた知識のために、サーバーが受信するすべてのパケットに対して2,500のルールがチェックされることです。


私のユースケースは次のとおりです。

私はIPがしないように私のサーバーを繰り返し検索するのを防ぐためにiptablesを使用しています(例えば、SSHログインに失敗するなど)。私は同様のPythonスクリプトを使用しています。失敗2禁止

最近では、これらの「攻撃」がますますスマートになり、速度が遅くなり始めました。 私は彼らがIP /ユーザー名のネストされたループをユーザー名/ IPに変更したと思われます。そのため、この問題を解決するために禁止措置を大幅に延長する必要がありました。私はこれについて非常に強硬な立場をとったので、彼らが2ヶ月の保護観察期間中に再試行した場合、私の新しい禁止期間は1年または2倍になります。

私はそのような禁止措置によって約2,500件の禁止措置が下されたという逸話的な証拠を発見しました。現在の新しいブロック率を適用すると、8,000人程度になります。ただし、サーバーが悪意のあるトラフィックをより正確にブロックし始めると、その割合は遅くなると予想されます。

ベストアンサー1

すべてのパケットが影響を受ける場合、合計2500のルールは膨大なCPU/帯域幅の努力になります。たとえば、10,000 個のパッケージを送信する場合、25,000,000 個のルールを分析するため、多くの作業が必要です。すべての着信トラフィック(確立されたトラフィックと関連トラフィックを除く)をブロックし、新しい接続が必要なサービスを開始する方がより正確で安全です。

IPブラックリストを追加するには、次のものを使用できます。IPセット単一のルールでこれらのリストを作成し、パフォーマンスに大きな影響を与えることなくルールを更新することもできます。たとえば、2200個の個々のIPをブロックしたい場合は、それらをリストに保存して単一のルールで確認することができ、CPU操作を大幅に節約できます。

おすすめ記事