ラボには 4 台のマシンでテストセットアップがあります。
- 古い P4 マシン 2 台 (t1、t2)
- 1 Xeon 5420 DP 2.5 GHz 8 GB RAM (t3) Intel e1000
- 1 Xeon 5420 DP 2.5 GHz 8 GB RAM (t4) Intel e1000
過去数か月間に多数の syn-flood 攻撃を受けたため、Linux ファイアウォールのパフォーマンスをテストします。すべてのマシンは Ubuntu 12.04 64 ビットで動作します。t1、t2、t3 は 1GB/s スイッチを介して相互接続され、t4 は追加のインターフェイスを介して t3 に接続されます。つまり、t3 はファイアウォールをシミュレートし、t4 はターゲット、t1、t2 はパケット ストームを生成する攻撃者の役割を担います (192.168.4.199 は t4 です)。
hping3 -I eth1 --rand-source --syn --flood 192.168.4.199 -p 80
t4 は、ゲートウェイとの混乱や t4 のパフォーマンスの問題などを避けるために、すべての着信パケットをドロップします。私は iptraf でパケット統計を監視します。ファイアウォール (t3) を次のように構成しました。
- ストック 3.2.0-31-generic #50-Ubuntu SMP カーネル
- rhash_entries=33554432 をカーネルパラメータとして
sysctl は次のようになります。
net.ipv4.ip_forward = 1 net.ipv4.route.gc_elasticity = 2 net.ipv4.route.gc_timeout = 1 net.ipv4.route.gc_interval = 5 net.ipv4.route.gc_min_interval_ms = 500 net.ipv4.route.gc_thresh = 2000000 net.ipv4.route.max_size = 20000000
(t1+t2 が可能な限り多くのパケットを送信しているときに t3 を実行し続けるように、多くの調整を行いました)。
この努力の結果は少々奇妙なものになりました。
- t1+t2 はそれぞれ約 200k パケット/秒を送信できます。t4 は最良の場合でも合計で約 200k パケットしか送信できないため、パケットの半分が失われます。
- t3 は、パケットが流れているにもかかわらず、コンソールではほとんど使用できません (ソフト IRQ の数が多い)
- ルート キャッシュ ガベージ コレクターは予測不可能であり、デフォルト設定では非常に少ないパケット/秒 (<50k パケット/秒) で圧倒されます。
- ステートフルiptablesルールを有効にすると、t4に到着するパケットレートが約100kパケット/秒に低下し、実質的にパケットの75%以上が失われます。
そして、これが私の主な懸念事項ですが、2 台の古い P4 マシンが可能な限り多くのパケットを送信するため、ネット上のほぼすべての人がこれを実行できるはずです。
それで、私の質問は次のとおりです。構成またはテスト設定で重要なポイントを見落としていませんか? 特に smp システムでファイアウォール システムを構築するための代替手段はありますか?
答え1
ルーティング キャッシュのないカーネル 3.6 以降に移行することをお勧めします。これで問題の一部は解決するはずです。
答え2
T3 のログ設定はどうなっていますか? ドロップされたパケットがすべてログに記録されている場合は、ディスク I/O が原因である可能性があります。
これはテスト環境なので、T3 ログをオフにしてテストを試すことができます。