SYNFlood攻撃を回避する方法を教えてください！

SYNFlood攻撃を回避する方法を教えてください！

ネットワーク初心者です。

会社で運用しているサーバが先日アクセス不可になりました。
FWのログが得られなかったため、詳細は分からないのですが、おそらくSYNFlood
だったのでは？との結論に至っており、今後の対策を進めているところです。

その中で、(1)上記の結論が正しいのか、(2)打てる対策は他にないのか、について
何かアドバイスをいただければと思い、質問させていただきます。


サーバ構成としては、下記のようになっております。
FW　⇒　LB　⇒　WEB
事故以降に調査した結果、LB側でセッションがたまった状況になったためではと考
えています。（★）
根拠としては、(1)FW側のSYNFloodProtectionのThresholdの設定が200ppsだ
ったので、当時は大量にSYNパケットがLBに送られていた、(2)最大同時セッション
数についても、FW側が128でLB側が100となっており、LB自体がセッションを受け
入れられない状況だった、(3)FWのタイムアウト値が5分なのに対し、LBの無応答
タイムアウト値が61分となっていた、ことなどからです。

そこで、対策として下記の対応をしてます。
(1)FW側のSYNFloodProtectionのThresholdの設定を1ppsに変更
(2)同時セッション数についてもFWは256、LBを384に変更

しかしながら、(1)の設定でも１パケット／秒がLBに送られる事になりますので、
LBの無応答タイムアウト値をFWに合わせて変更できないと、無用なセッションが
滞留することには変わりがありません。

メーカーに確認すると、LBのタイムアウト値は61分固定で変更不可とのことで、
数値の根拠はブラウザ(IE5，6）のタイムアウトが60分だったから（IE7,8では
30秒になっていますが…）だそうです。

FWがタイムアウトになった際にRSTをLBに送信してくれれば問題ないのですが、
それも仕様上不可とのこと。

現状では、SYNパケットは1/sはLB側に送られる状況であり、万一攻撃を受けた
際は、そのセッションが滞留する事になります。LBのタイムアウト値61分から
算出すると、LBの同時接続数を3660に設定しておかないと、SYNFloodに対抗
できない事となり、その設定をしたとしても実際のところLBのサーバの性能上
受け切れるのか、また、WEBサーバ自身もさばき切れるのか、など現実味のあ
る対応とは思えません。

そこで、セッション監視スクリプトでも作ってLB側に設置し、最大同時接続数
に達した場合は、LBを強制再起動させるしかないのでは、と考えています。（★）

そこで質問なのが、上記★を付けた部分が正しいかどうか、という点です。

また、FW側がRSTを送信してくれないのは、一般的なFWの仕様なのか、たまた
ま利用しているFW（外部サービスです）の仕様の問題なのでしょうか？

何かご存じのことがあればご教授いただけると助かります。

どうぞよろしくお願いします。

No.4 ベストアンサー 回答者： nnori7142 回答日時： 2010/10/24 08:19

　追加補足（３）拝見しました。

解釈されている通りかと存じます。Unixサーバでのiptables記述でのTCPアクセス制限ですね。L3スイッチやL2スイッチ、ルーターでのQOS、VLAN等での帯域制限はレスポンスの低下効果がありますので、総合的な判断をしますと何とも言えませんが、レスポンスと可用性等も考えると、専用セキュリティ・ゲートウェイでの運用ですね。

この回答へのお礼

お礼が遅くなりました(^^ゞ
ご丁寧に何度も説明いただき、ありがとうございました。
大変勉強にもなりました！！
また質問することもあるかと思いますが、その折はまたよろしくお願いします。

お礼日時：2010/10/26 20:22

No.3 回答者： nnori7142 回答日時： 2010/10/23 20:12

　追加補足（２）拝見しました。

SYNFlood攻撃については、Apacheのサービス・インスタンスでのタイムアウト記述だけではなく、TCPレベルでの制限が必要になるのが私の解釈です。
　Unixサーバでしたら、サーバ側でも「net.ipv4.tcp_tw_recycle=1」、「net.ipv4.tcp_fin_timeout=**」での数値制限やiptables で SYN,RST,ACK SYN を時間/回数で制限する等でしょうか。
　SYNFlood攻撃だけではなく、付帯して攻撃手段になり得るのが、長時間に渡るオープン状態のコネクションを大量に発生させるConnection Flood攻撃や偽装したUDPパケットを大量に送りつけるUDPFlood攻撃も御座いますので、より上位のポイントからのトラフィック制御が必要となるのが、現状での通説ですね。
　

この回答への補足

丁寧に回答いただき、本当にありがとうございます♪

WebサーバはLinuxですが、サーバ側でtcpレベルの設定をしてやれば、
LBの問題を少しカバーできるという解釈で正しいでしょうか？

いずれにせよ、本格的な攻撃を受けたらおそらくはサービス自身は
どうしようもないと理解しているつもりです。
その点については、サーバがハングしてノットあれないような対策を
しておくことと、速やかに攻撃を把握して必要があればサーバを落と
す（？）などの対応の体制が必要なのかと考えています。

「上位のポイントからのトラフィック制御が必要となる」というのは
現状のFW－LB－Webの構成でいえば、FWの位置での制御が必要という
理解で正しいですよね？

初歩的な質問ばかりの繰り返しで申し訳ありませんが、もう少し
お付き合いいただけると助かります。

補足日時：2010/10/23 23:59

No.2 回答者： nnori7142 回答日時： 2010/10/23 09:43

　追加補足拝見しました。

SYNFlood攻撃に対する帯域制限については解釈している内容で合っているかと存じます。L3スイッチやL2スイッチの中にQOS機能での帯域制限を細かく設定できるタイプが御座います。
　それと、ファイアーウォール関連機器又は一般的なルーターは、不正パケットに対するコネクション・リセット機能は付いておりません。業務用セキュリティ・ゲートウェイや業務用ルーターの中にそういった機能が含まれているのみとなります。実際に業務用ルーターを利用で、ファイアーウォール機能に不足を感じているのであれば、既存ルーターの攻撃に対するQOSやVLAN設定にて帯域制限を設けていく形となります。

この回答への補足

丁寧に説明いただき、感謝感謝です！！
ありがとうございます！！！

結局、外部サービスを利用しているFWの種類を変えるかUTMにするか
しかない感じですね(^_^;)

ふと思いついたのですが、LB（ロードバランサ）の後ろにWebサーバ
がいるわけですが、Webサーバ側でもタイムアウト値の設定があるの
では？？？（まだ調べてません）と思いました。
ブラウザ（IE）のタイムアウト値は60分だそうですが、通常それほど
待つことってないと思います。
それは、たとえば中継サーバ（たとえばFW）のタイムアウトにより
セッションが遮断されるなどでブラウザのタイムアウト値よりはるか
に早くタイムアウト処理がされているのではと考えています。
上記と同じ考え方をすると、Webサーバのタイムアウト値が60分以下
であれば、そのタイムアウトになったらWebサーバ⇒LBにセッション
切断の信号が送られるのでは？？？つまり、結果としてLBにセッション
がたまる事はないのでは？？と思いました。
この考え方は正しいでしょうか？ちなみにWebサーバはApache2.2
（おそらく）です。

LB側の仕様の問題もあるかもしれませんので、その点はLB側のメーカ
に問い合わせてみようとは思いますが、もし上記に何かお気づきの点が
あれば教えていただけると嬉しいです。

どうぞよろしくお願いします。

補足日時：2010/10/23 19:05

No.1 回答者： nnori7142 回答日時： 2010/10/22 20:55

　お尋ねの件ですが、攻撃自体TCP/IP の本質的問題なので、防御は難しいですね。

　ファイアウォール製品の中には、SYN flood を自動検知して、一定時間以上確立されないままのハーフ・コネクションを強制的にリセットしてしまう機能を持つものもあります。
　専用のセキュリティ・ゲートウェイ機器の設置が望ましく、 対応機器としては、Yamaha製「SRT100」や大塚商会様のセキュリティ・ゲートウェイサービス（FortiGate、FireboxX e）等の利用が良いかと存じます。
　単純なルーターのみの環境ですと、SYN flood攻撃発生時にその通信のリセット機能は無いものが殆どです。Linuxサーバ等での対策で見ますと、カーネルコンパイル時に「CONFIG_SYN_COOKIES=y」、「/proc/sys/net/ipv4/tcp_syncookiesを1にする」、「コネクション確立時のウェイトタイムを短くする。」等が御座いますが、ウェイトタイム調整出来ない場合、ルータやスイッチによってSYNパケットの帯域制限を行うのが基本となります。

この回答への補足

回答ありがとうございます♪
要は、現在利用しているFWのサービス機能が足りない（タイムアウト時にRSTを送信しないため）ということでしょうか？
ものによってはFWでもRSTを送信するものがあるということでしょうか？
専用のセキュリティ・ゲートウェイ機器の設置とはFWとLBの間に設置すればよいのでしょうか？
回答だけ拝読して、まだ私の方で未調査のため、変な質問でしたら申し訳ありません。

「ウェイトタイム調整出来ない場合、ルータやスイッチによってSYNパケットの帯域制限を行うのが基本となります」
ということは、現状の設定（FW側で1セッション／としている）が現状できる最良の策であり、攻撃に備えるのであれば、LBの最大同時セッション数を3660にする、ということができうる対策ということで間違いないでしょうか。

自分の考えていることが正しいのかどうか、今一不安を覚えているので、ご回答いただければ嬉しいです。
よろしくお願いします。

補足日時：2010/10/23 08:26