linuxサーバーに対する攻撃について

質問者のmeganerです。jin255様、JULY様、ご回答頂きありがとうございます。

実は攻撃をうけたサーバーはメールサーバーとしても動いてます。（とはいっても受信者は私だけですが）
なるほどー。。ということはiptablesでlimitしてしまうと、攻撃中に他の接続も受け付けなくなってしまい、SynCookiesを有効にしても、攻撃中はシーケンス番号が付与されないため、ロスしたパケットの再送が出来なくなってしまう。

おはなしを聞く限り、メールサーバーとして動いていたとしても、synCookiesの有効が影響範囲が少ないかなと考えてしまいましたが、もしお二人のsynfloodへの対策等ございましたら教えて頂けますでしょうか。

とりあえず、SYN cookie を有効にするのは、悪くない対策だと思います。

回答で紹介したメールサーバとして使っているケースの問題にしても、送信元の MTA ソフトが、サーバから Greeting Message（接続直後に「220 mail.example.jp ....」とサーバ側から送ってくるメッセージ）を永遠に待つか、というと、一定の時間でタイムアウトして、結果、再送処理に回されるだけで済むケースが殆んどだと思います。

なので、SYN cookie を使ったあら、「ひょっとしたら、そのせいでメールの遅延が発生するかも」という覚悟はしておいて、あまりにひどければ、SYN cookie を無効にして、iptables での対策を検討する、というのでも良いと思います。

iptables で limit にするか hashlimit にするかは、回答にも書きましたが、送信元アドレス毎に見たときの頻度で考える必要があります。例えば、全体では 100 万／秒 の SYN パケットでも、100 万個の送信元アドレスから、１秒に１回しか送ってこないのであれば、hashlimit では引っ掛かりづらくなります。

limit にするのであれば、自分が管理用につなぐためのアドレスだけを除外して、

---------------------------------------------------------------------
iptables -A syn-flood -s 管理用のアドレス -j RETURN
iptables -A syn-flood -m limit --limit 1/s --limit-burst 4 -j RETURN
iptables -A syn-flood -j DROP
---------------------------------------------------------------------

といった具合に、した方が良いと思います（注：上記 iptables の設定は検証してません）。

私が適用している対策はSYN cookieです。
メールサービスで7年、8年運用していますが、
これに伴う影響や問い合わせは
今のところ受けたことがありません。
が、JULY様が仰るとおりの影響が気づかないところで
出ているかもしれません。

jin255様、JULY様、ご回答頂きありがとうございました。

今回、ファイアウォールには手を加えず、SynCookie対策で様子を見たいと思います。

効果の程を知るためにも、また攻撃が来ないか今からワクワクしてしまいますが、これまでip spoofingとsyn floodを組み合わせた攻撃が来た場合、どの様に対応すれば良いのだろう？と疑問に思っていましたが、今回の攻撃をきっかけとしてその部分が理解でき非常に勉強させていただきました。

この度は0ptsの質問なのに、丁寧にご回答頂きありがとうございました～

非常に細かい話で恐縮ですが....

IP spoofing は本来、IP アドレスの偽装ですが、偽装されているかどうかは、SYN flood を受ける側としては、あまり本質的じゃないです。

meganer さんが受けた SYN flood 攻撃はおそらく、多種の送信元アドレスを持つ SYN パケットを受けた、ということだと思いますが、確かに多種の送信元アドレスを作るのに、手っ取り早い方法が IP アドレスの偽装、という事になります。SYN パケットに対する SYN+ACK パケットは、その偽装された IP アドレスへ送られ、その IP アドレスに該当するホストがあっても、そのパケットは捨てられるので、決して ACK がサーバ側に届くことがなく、結果、SYN flood が成立します。

もうひとつの方法としては、ボットを利用する事が考えられます。この場合、必ずしも IP アドレスを偽装する必要はなく、攻撃対象からの SYN+ACK を無視するようにすれば、攻撃が成立します。

攻撃を受ける側にとっては、偽装されていたかどうか、ではなく、送信元 IP アドレスのが絞れるか否か、という事になります。

jin255 さん
-----------------------------------------------------
が、JULY様が仰るとおりの影響が気づかないところで
出ているかもしれません。
-----------------------------------------------------

まぁ、どの位の確率で 3way ハンドシェークのパケットがロスするか、という事もありますし、SMTP の場合は先に書いたとおり、再送に回って遅延が発生するだけで、実害と呼べるような問題は無いと思います。

強いて言うと、定期的に rsync を ssh 経由で行うような場合に、次のスケジュールまで同期されない、という事はあるかなぁ、と、先のコメントを書きながら考えていました。

一発でスパッと繋がらないケースがあったら、原因の一つに SYN cookie の可能性も頭の片隅に置いておく、という程度で構わないと思います。

まぁ、一発で繋がらないと大問題になるような、ミッション・クリティカルなシステムが無いとは言えませんが(^^;

JULY様
詳細なご説明有難うございます。
大変勉強になりました。
私も頂いた情報を後進に伝え、
今後のサービスの安定運用に活かしたいと思います。
有難うございました。

後日談です。

この後、自宅の別のwebサーバーが２夜連続応答しない事態がありapacheのログを調べたところ下記の記述がありました。

kernel: possible SYN flooding on port 80. Sending cookies.

sarコマンドで該当時間のログを調べるとスワップが発生し、ロードアベレージが数百に達しており、負荷によりapacheが応答出来ない状態だったのですが、取り敢えずリブート後にsyncookieを無効とし、その後状況は落ち着いています。

これまでそのWEBサーバーは２年程サービス断がなく、今回のアドバイスを機に念の為と設定してあったのですが
syncookieを有効にしてからたまたま２夜連続攻撃を受けたのかも知れませんし
またはsyncookieの判定で正常なリクエストが異常と判定されたのかも知れません
只、なぜ上記ログの後メモリが大量に消費され障害に繋がったのか、syncookieの動作の解説を見る限りここが納得できておりません。

FWでの対策も視野に対応を検討したいと思います。

以上ご報告です。

ご予算が許すのであればリソースを強化してみては如何でしょうか？

基本的にSYN cookieを有効にするのは有効だと思うのですが、
それに伴いWEBサーバでは弊害も出ているようですね。

下記URLに参考になるかどうか分かりませんが
同様の症状になった方のエントリがありました。
http://www.my-standard.co.jp/419.html

この方はSYN cookieを無効にせず、リソース（メモリ）拡張
及び、WEBサーバのチューニングで対応されたようです。

meganer様の仰るとおりFWでの対策も有効だと思いますので
現行のサーバとは別立てしたFWで余計なパケットを払い落とすことも
ご検討頂ければ幸甚です。

まさに同様の症状のURLありがとうございます！

ただ私の場合は、2夜連続したウチの1夜目にまずapacheのServerLimit、MaxClientの縮小措置（400→200）を行ってしまいました。メモリが足りなくなっているので、apacheでメモリを枯渇してしまう状況を防ごうと考えた次第ですが結果的に状況を変えることが出来ませんでした。

jin255様のアドバイス通り、やはり前段にFW、後段にWEBサーバーという構成で、FW側で余計なパケットをふるい落とし、SynCookieはそのまま、という構成の方が健全と感じましたのでそのようにしてみます。

でも何故synCookieが発動した途端に大量にメモリを消費してしまうのか、につきましては疑問が残ったままです。攻撃からリソース（メモリ）を守るために、シーケンス番号を覚えないんだと理解しましたが、もう少し勉強が必要そうです。

SYN Cookieが発動した途端に大量のメモリを消費してしまうのか、
という原因に関してははっきりとしたことは言えませんが、
（勉強不足で申し訳ないです。）参考になりそうなURLがありました。

※英文です。
http://www.symantec.com/connect/articles/hardening-tcpip-stack-syn-attacks
http://cr.yp.to/syncookies.html

SYN Cookieという仕様が少なくとも「リソースを消費する」ということ
みたいです。

要するに
========
クッキーの値は、システムによって生成された擬似乱数ではありませんが、代わりにハッシュ関数の結果です。送信元IP、送信元ポート、宛先IP、宛先ポートといくつかの秘密の値：このハッシュ結果は、のような情報から生成されます。 SYN攻撃中に、システムはCookieを使用してパケットを返信する、の代わりにSYNキューが満杯のときに接続を拒否することで応答を生成します。サーバはACKフラグがセット（スリーウェイハンドシェイクのプロセスの最終段階）でパケットを受信すると、それはクッキーを検証します。 SYNキューに対応するエントリが存在しないにもかかわらず、その値が正しい場合、それは、接続を作成します。その後、我々はそれが正当な接続であることと、送信元IPアドレスが偽造されていないことを知っている。
========
という様な処理を行う為、有効にした場合はその分リソースを消費すると
考えられます。

また、
========
SYN攻撃を受けて、我々は正当なクライアントへのアクセスを拒否することなく、ハーフオープン状態でより多くの接続をサポートするために、バックログキューを変更することができます。一部のオペレーティングシステムでは、バックログキューの値は非常に低いと、システムが攻撃を受けているときベンダーは、多くの場合、SYNキューを増やすことをお勧めします。

バックログキューのサイズを大きくすると、必要と着信要求のためのシステムがリザーブ追加のメモリリソースこと。システムがこの操作を行うのに十分なメモリをしていない場合は、システムパフォーマンスに影響を与えます。我々はまた、ApacheやIISなどのネットワークアプリケーションは、より多くの接続を受け入れることができることを確認する必要があります。
========
ともありますのでメモリは潤沢に用意しておいたほうが無難ということでしょうか。

疑問に対する返答になっているか、いささか不安ですが
ご参考頂ければ幸甚です。

jin255さん

ご丁寧にありがとうございます！

SynCookie自体がリソースを消費してしまう仕様なのですね。現状ですとメモリ不足により発動するたびにサーバーが落ちてしまうのが残念ですが、折を見てメモリ増設も検討したいところです。

その後サーバーは安定しています。

という事は、実は今回のWEBサーバーに関しては「攻撃」というよりは、SynCookie発動のトリガが厳しかったのかなと感じました。このSynCookie発動に関する詳細と
また、SYN攻撃を受けている際に「apache、IISなどのネットワークアプリケーションがより多くの接続を待ち受ける必要がある」という部分に関して、ackを返さないSYN攻撃がアプリケーション層の接続数に影響を与える部分に関して理解ができておらず勉強したいと思います。

根本的に勘違いしているのかもしれませんが、何か解ったことがありましたらご報告させていただきます。