SYN floodの対処法
■ このスレッドは過去ログ倉庫に格納されています
0001ひろゆき ◆L3IpNS4A
02/02/17 15:18ID:qO24E++FSYN floodに対処する方法ってないんでしょうか？
http://www.niksula.cs.hut.fi/~dforsber/synflood/result.html
ここのpatchはあててみたのですが、
効果がなかったようで、、、
0233_
02/02/19 03:02ID:???0235anonymous@ CBCba-52p140.ppp13.odn.ad.jp
02/02/19 03:03ID:nsK7UavW0236ななしさそ
02/02/19 03:03ID:???こんな時間に起きてる人そう違ないと思うけど・・・。
0238hogehoge@ RIFba-02p91.ppp13.odn.ad.jp
02/02/19 03:05ID:???３分以内に4096パケットくらい（デフォ設定ならたったの128)送信できればそれであぼーんです。
0239235
02/02/19 03:05ID:tAnyzYnLうちも問題ないっす。
もうアドレス変えたし
0240235
02/02/19 03:09ID:tAnyzYnL0242anonymous@ OFSfa-01p5-153.ppp11.odn.ad.jp
02/02/19 03:10ID:???aちょっと 全サーバ リブートしますー。
全部止まるよ。
だそうです。。
0243anonymous@ ntaich030212.adsl.ppp.infoweb.ne.jp
02/02/19 03:11ID:???http://kaba.2ch.net/test/read.cgi/accuse/1013478682/
754 名前：夜勤 ★ 投稿日：02/02/19 02:59 ID:???
aちょっと 全サーバ リブートしますー。
全部止まるよ。
757 名前：心得をよく読みましょう 投稿日：02/02/19 03:01 ID:afeaIjZ9
∀・)＜2～3分ぐらいですよね・・・
758 名前：夜勤 ★ 投稿日：02/02/19 03:02 ID:???
>>757
運がよければ、、
0244238
02/02/19 03:13ID:ap4/ciGPなんか、回線が埋る以外は、特に問題なさそうでしたねー。
FreeBSDのほうが、なんか繋がりやすかったと思います。
うちのLinuxは、loadがかなり上がったのが気になりましたが、
完全にアクセス不能になるよりはましかもです。
0245anonymous@ eAc1Abr031.tky.mesh.ad.jp
02/02/19 03:13ID:88TFt8so同意。認定のアタックなぞそうはできない…（w
0246CC p191.net217.tnc.ne.jpたん
02/02/19 03:16ID:???0247夜勤 ★
02/02/19 03:20ID:???0248235
02/02/19 03:21ID:tAnyzYnLルータにしているマシンでtcpdumpするまで、syn floodされてるとは思えなかったし。
>>245,246
まぁ、グローバルアドレス変えやすい環境だから安心して2chで公開実験できる (w
0249235
02/02/19 03:21ID:tAnyzYnL楽勝でできますが、マジですか?
0250238
02/02/19 03:21ID:ap4/ciGPできますよー。
ただ、誰かやるひと一人に限定したほうがいいかも・・・
DDoSになっちゃう・・・
0251夜勤 ★
02/02/19 03:22ID:???作業終わったら、実験してみようかと、、、
0253CC p191.net217.tnc.ne.jpたん
02/02/19 03:24ID:???0254238
02/02/19 03:24ID:ap4/ciGPきゃ～夜勤 ★さん、す・て・き。
0255夜勤 ★
02/02/19 03:25ID:???先に いろいろ作業して、全サーバリブートしてから
個別に。。。
0256つーか
02/02/19 03:26ID:???0257anonymous@ eAc1Abr031.tky.mesh.ad.jp
02/02/19 03:26ID:88TFt8so0258238
02/02/19 03:28ID:ap4/ciGP0260235
02/02/19 03:28ID:tAnyzYnL0261238
02/02/19 03:29ID:ap4/ciGP0262?
02/02/19 03:31ID:???これならnmapをループでまわしたほうがはるかに強力なんじゃ？
0263想像力なしさん
02/02/19 03:33ID:???くだらないけど、そこそこな勢いでsynパケット吐くし、
2chに特化されてるんで、作成者の目的にはけっこうぴったりなんでは？
変更された場合には、
①インデックスファイルのURL設定を変更（Iボタン）
②インデックスの再取得（Rボタン） で「target.txt」を再作成。
0267●
02/02/19 03:38ID:???全27鯖 (･∀･)ｲｲ 20鯖 （´・ω・`）ｼｮﾎﾞｰﾝ7鯖 ｱｯﾋｬｯﾋｬ!ヽ(ﾟ∀ﾟ)ﾉ ㌧㌦! ㌧㌦!
0268anonymous@ i233176.ppp.asahi-net.or.jp
02/02/19 03:38ID:???0269CC p191.net217.tnc.ne.jpたん
02/02/19 03:40ID:???ﾁｮｯﾄ心配･･
0270238
02/02/19 03:41ID:ap4/ciGP漏れもそう思った・・・
0271235
02/02/19 03:47ID:tAnyzYnL0272238
02/02/19 03:48ID:ap4/ciGP0275想像力なしさん
02/02/19 03:51ID:???けっこうまずいかも
0276CC p191.net217.tnc.ne.jpたん
02/02/19 03:51ID:???どうなの、夜勤たん!!
0277238
02/02/19 03:53ID:ap4/ciGPあなたでＯＫ
0279238
02/02/19 03:56ID:ap4/ciGP0280235
02/02/19 03:56ID:tAnyzYnL寝ます・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
0281夜勤 ★
02/02/19 03:56ID:???いつ作業が終わるかは、ちと解らないので
すまないですー
無理することもないので、その時にできる方がいらっしゃったら
お願いしますー
あしたの今ごろにも、もう一度やる予定ですので、
(今日 やってもやらなくても)
0282238
02/02/19 03:58ID:ap4/ciGPおやすみなさーい。
(2chでおやすみなさいなんて書いたの初めてだ・・・）
0283anonymous@ eAc1Abr031.tky.mesh.ad.jp
02/02/19 04:01ID:???0285CC p191.net217.tnc.ne.jpたん
02/02/19 04:03ID:???仕事に行くまでﾎﾞｰっと眺めてます･･えぇ･･･
0286ひろゆき ◆L3IpNS4A
02/02/19 04:03ID:Kq3S9ZHK0287´Д｀
02/02/19 04:04ID:???0288anonymous@ eAc1Abr031.tky.mesh.ad.jp
02/02/19 04:04ID:???ほいほい おやすみ～。
0289【ここまでのまとめ 1/2】
02/02/19 04:13ID:???ひ(略 はFWを導入(最終手段)せずに済ませる為の方策を
模索しているようだ｡
■現状で明らかになってるのは
1.サーバ負荷なのか回線負荷（帯域）なのかの切り分けがまだ。
2.サーバ負荷のなかでもプロトコルスタックの負荷（Kernel）なのか
Apacheの負荷（プロセス）なのかが明確でない。
（attack時にwww以外のサービスはちゃんと機能している？）
【2.についての簡単な説明】
サーバに到着した未確立セッションのキューが溢れることが
問題であるなら”tcp_max_syn_backlog”の問題となり、
tcpを使うサービスは麻痺状態になるはず
また、Apacheが受け付けた確立済みセッションが溢れることが
問題であるなら"ListenBacklog"の問題となる。
0290【ここまでのまとめ 2/2】
02/02/19 04:14ID:???【簡単な説明】
2ch鯖で採用しているLinuxには"SYN cookies"と言う機能があるが負荷が大きくハングアップの危険性も考えられる｡
FreeBSDには"SYN cache"というLinuxより洗練された機能があり、どうやらヨサゲだ（参考：>>137)。
これらは共に”tcp_max_syn_backlog”が溢れる事を防止するための追加新機能である。
・ひ(略 と夜勤さんによるテスト
1.FreeBSD-BOXをthe Internetと2ch鯖の間に入れてSYN cacheによる高負荷時の未確立セッションの破棄を行わせる[検討中]
2.確立済みセッションの待ち行列"ListenBacklog"の最大数をいじってみる
3.謎の公開攻撃実験を02/02/20に実施するかも｡
・有志によるテスト
1.SYN-cookiesを有効にした自鯖（Linux？）をD-bornでSYN-Flood攻撃を試みる｡
結果、帯域が真っ黒になったらしくサービス不能に陥る(リクエスト･タイムアウト発生)
2.”tcp_max_syn_backlog=1024”/"SYN-cookiesを有効"としたローカル鯖で実験
瞬断が発生したが10秒ほどで復帰（参考：>>228）
●帯域さえ充分であればLinux with SYN cookiesでも行けるかも。
但し、限界性能については要検証
0291２８８
02/02/19 04:37ID:???echo-reply
0293238
02/02/19 04:46ID:ap4/ciGPあとおながいしますー
ぐーーーZZzz..
0295夜勤 ★
02/02/19 04:54ID:???今日は 攻撃実験できそうにもないようです。
また 明日、ここに来ますので
お時間のある方はよろしくお願いしますー
0296想像力なしさん
02/02/19 04:56ID:???0297288
02/02/19 04:56ID:???ラジャー
その生き返らないってのが気になりますが（w
See you tonight.
0298CC p191.net217.tnc.ne.jpたん
02/02/19 04:56ID:???いちおう蛇足だけどハングアップの危険は負荷とは直接関係無しね。
0302anonymous@ p3063-ip02niho.hiroshima.ocn.ne.jp
02/02/19 11:32ID:5ZZijZ3W0303fefefe
02/02/19 12:22ID:xV2Tl9WL0304anonymous@ CBCnni-10S1p088.ppp12.odn.ad.jp
02/02/19 13:29ID:???URLキボーン
http://www24.big.or.jp/~faru/
２ｃｈ放浪日記
http://www7.plala.or.jp/hourou/
0309anonymous@ fw1.n2.bis-net.co.jp
02/02/19 16:16ID:???0311___
02/02/19 16:38ID:???買うだの買わないだのってあったから、
テストするならあげるよって意味で書いたのね。
的はずしだったらごめん。
0312anonymous@ sraihc.sra.co.jp
02/02/19 18:26ID:???(ふだんは、この板は見てない。)
>>290
syn cookies で、コネクション開設時にハングアップする可能性があるのは、
SMTP や SSH のようなプロトコルだけで、2ch のような HTTP の場合には
その危険はない。
また、「ハングアップする」というのは「クライアント側での、TCP接続が、
開設途中で刺さる」だけであって、クライアントのマシン全体が止まるわけ
じゃないし、サーバー側は何の問題もない (ハングアップもしないし、開設
途中のコネクションが残るわけでもない) ので注意。
もちろん syn cache があった方がサーバー側の CPU 負荷は軽いので、
syn cache はあった方がいい。
ただ、以下は私見だが、前提条件として、WWW server として Linux を利用す
るという点は動かせない、すなわち、もし選択肢が
1. syn flood 対策用 firewall として FreeBSD 4.5 以降のマシンを一台入れる
2. WWW server である Linux マシンで syn cookies を有効にする
の二つであれば、2. の方が良いと思う。
理由は、1. の場合、syn flood 対策の負荷が、FreeBSD で構築した firewall
マシン一台に、集中するから。たとえばもし FreeBSD が Linux よりも SYN の
処理にかかる負荷が 10 倍軽いとしても、 WWW サーバーが 20 台あれば、
1/10 * 20 == 2 で、結局、トータルな負荷は (各 WWW サーバー側で対策する
場合の) 2倍になってしまう。というわけで、負荷分散の観点から考えると、
syn flood 対策は、firewall でやるよりも、end point である WWW サーバー
側でやる方が向いている。もちろん、
3. WWW server を FreeBSD 4.5 以降のマシンに変更する
というのが可能ならば、これがベストだが。
>>28
UNIX板を見てるなら知っている筈だが、
Linux (昔から): syn cookies あり (上述の問題があるためデフォールトでオフ)
NetBSD (昔から): syn cache あり (デフォールトでオン)
FreeBSD (4.5 から): syn cache + syn cookies あり (デフォールトでオン)
OpenBSD: どちらもなし
なので、この問題に関しては、OpenBSD は最悪の選択。
031439
02/02/19 19:44ID:rKrqlxb4最初に FreeBSDでリバースプロキシを提案したものですが、
> 理由は、1. の場合、syn flood 対策の負荷が、FreeBSD で構築した firewall
> マシン一台に、集中するから。たとえばもし FreeBSD が Linux よりも SYN の
確かに1台だけでは対応できないと思います。
Linuxサーバ N台に1台という様に、
Linuxの前に設置するFreeBSD マシンは1台ではなく複数必要と考えます。
問題はその N がいくつかなんですけど。
N=5 ぐらいではないかと勝手に想像しています。
いま手元にある古いノートPCを FreeBSD 4.5Rにアップグレードして
実際にどのぐらいの性能か試してみようと思います。
0315テスト
02/02/19 19:47ID:???リバースプロキシが無くてもLinuxの鯖単体で十分対処できるよう
になったら、不要になったFreeBSDの鯖はどうするんだろう？
と言ってみるテスト。
0316どこかの誰か
02/02/19 19:47ID:???詳細の検討は過去ログを見て貰えば良いとして、
>>289-290 はざっくりの現状把握になれば良いかと｡
ところで遅ればせながらsrcを追っかけてみたのですが、
syncookies使用時にUNIX板で指摘が出ていた
1) syn floodを受けている状態で
2) syncookies発動=>timeout前に破棄される未確立セッションが発生
3) syn floodとtcpの再接続要求が殺到 => 2)に戻る
と言う状況は発生する懸念があると思いマス。
end userから見た場合、syncookiesが正常動作しているにも関わらず
㌧㌦として見えてしまうという状況ですね。これは要検証ではないかと。
また、>>312 については
> 1. syn flood 対策用 firewall として FreeBSD 4.5 以降のマシンを一台入れる
を実施したからといって2chサーバ 現状27台(virtual hostを含めると43台)を
全て1台のfirewallで賄わなければいけない訳ではなく、複数firewallを用意して
振り分けても良いと思われます。
このあたりは要求するサービスレベルと管理・運用コストの問題でしょうね。
まずはsyncookiesの高負荷時の挙動を確かめてみるのが先決かもしれません。
Linuxで対処できないとなれば、次の手を考える －FreeBSDの導入かもしれないし
ハコ型Firewallの導入かもしれないし－ と言う手順になるかと思います。
031739
02/02/19 19:49ID:rKrqlxb4FreeBSD鯖はいらなくなったら 2ch鯖としてつかうとよろし
0318_
02/02/19 20:04ID:???> いま手元にある古いノートPCを FreeBSD 4.5Rにアップグレードして
> 実際にどのぐらいの性能か試してみようと思います。
単独の結果よりも、Linux で syn cookies 発動中の場合との負荷の比が
知りたいなあ。
>>316
> 2) syncookies発動=>timeout前に破棄される未確立セッションが発生
> 3) syn floodとtcpの再接続要求が殺到 => 2)に戻る
> と言う状況は発生する懸念があると思いマス。
ん？ これは問題ないんじゃないの？
syn cookies 発動中なら、サーバー側が 3way handshake の 2番目の SYN ACK
さえ返していれば、あとはサーバー側で資源を解放したところで、handshake の
3番目の ACK がクライアントから届けば、コネクションは確立されるので。
それとも、SYN ACK さえ返さないって話？
> ㌧㌦として見えてしまうという状況ですね。これは要検証ではないかと。
この先頭2文字、UNIX上のWWWブラウザからだと読めないYO。
JIS外の文字はやめて～。
031939
02/02/19 20:09ID:rKrqlxb4>>単独の結果よりも、Linux で syn cookies 発動中の場合との負荷の比が
>>知りたいなあ。
スマソ、私の家には solaris はあっても Linux は無いのだ
とりあえず手元の環境でxinetdでリバースプロキシ試してみて、
方法教えるから誰かLinuxもある人試してみてくで
0320_
02/02/19 20:15ID:???もし OS の比較をしたいのなら、サーバー側ハードウェア、サーバー側のアプ
リケーションの設定、syn flood かける側のハードウェアおよびソフトウェア、
双方を繋ぐネットワーク、などなどの環境を合わせて、OS だけを変えて試さ
ないと意味ないよ。
というわけで、基本的には同一環境で OS だけを変えて試す必要あり。
032139
02/02/19 20:19ID:rKrqlxb4LinuxとFreeBSDでDialBootな人ためしてくらはい
032339
02/02/19 20:24ID:rKrqlxb4032439
02/02/19 20:32ID:rKrqlxb4のアドレス・ポートを定義します。複数のサーバにリダイレクトしたい時は
ifconifg でアドレスをaliasしておけば bind できます。
まず1つだけでためしてみませう
わらひは 家にある別なマシンに rain 仕込みます。
------
defaults
{
log_type = SYSLOG daemon notice
log_on_failure = HOST USERID ATTEMPT RECORD
log_on_success = PID HOST USERID EXIT DURATION
only_from = 0.0.0.0
}
service http
{
type = UNLISTED
socket_type = stream
protocol = tcp
port = 80
wait = no
user = nobody
groups = yes
redirect = 192.168.3.5 8080
}
0325anonymous@ i011040.ap.plala.or.jp
02/02/19 20:38ID:meJG4/4y昨日攻撃受けてるときに80以外の21,23,25は接続可能だった(>>226)んだが、指摘している現象かね。
ちょっとふに落ちん。攻撃受けてるときのnetstatｷﾎﾞﾝﾇ。つかIDS入れてないの?
昨日の本スレ中でのやり取りなのですが、
>>156 の指摘を受けて(>>156 >>159 >>162 >>166) >>169 と言う報告が
昨夜ありました。
>>170-171 という話もあったので、今回のDoS攻撃は
単なるSynFloodではないのではないか？（= 切り分け出来ていない？）というまとめに
してみましたです。
P.S.機種依存文字の件、失礼しました
0327_
02/02/19 20:54ID:???その方法だと、ソース・アドレスがxinetdを走らせているマシンのものに変わっ
てしまうので、proxy規制系の変更が必要になるのでは？
66では、「第2案だとproxy規制系の変更がいらない」とあるが、これは勘違いで
「第1案でも第2案でもproxy規制系の変更がいる」だと思われ。
もっとも、transparent proxyと併用すれば、(第1案、第2案とも) proxy 規制
系の変更なしに実施できるが、フリーなOSでの transparent proxyの利用に関
する資料ってあんまりみたことない。UNIX Magazine で、ちらっと見たことあ
るぐらいだし、その記事のやり方だとソースアドレスが変わっちゃうので
proxy規制の変更を避けるという目的には使えない。proxy規制の変更を避けた
いなら、カーネルだけではなく、アプリケーション側にも若干手を入れる必要
がある。変更量自体はわずかなんだけど、今の2chの運用状況を見る限り、
ここまでするのは、ちょっと荷が重い気がする。
proxy規制系に手を入れない、かつ、WWWサーバー側ではなくfirewallで対処す
るというのなら、商用firewall(の中で syn flood 対策面での性能の高い奴)を
入れるというほうが金はかかるが実現可能性は高いんじゃないか。
032839
02/02/19 21:03ID:rKrqlxb4>>327
プロキシ規制の件は xinetd.conf でも ipfwでも対応できるから
当面無視していいと思うぞ
032939
02/02/19 21:05ID:rKrqlxb4再度srcを追って見てるのですが、誤読があるかもしれないので
誤りがあれば指摘してください。（自分がヘボい事は自覚してます）
syncookiesが発動すると "tcp_max_syn_backlog"と同サイズの領域"backlog"を確保。
"backlog"中のACK待ち行列は timeout前であっても破棄される可能性があり、
"backlog"から（領域あふれで？）破棄されると"tcp_max_syn_backlog"からも破棄される。
つまり、「クライアントからのACK到着がtimeout前であってもコネクション確立失敗として
扱いますよ」というのが動作原理だと読み取ったのですが。違いますでしょうか？
# syncookies発動時はtimeout以外のルールでACK待ち行列から
破棄されうる と読み取ったのですが･･･
0331nobody
02/02/19 21:18ID:Y52jMZPrいうのがどうにも解せないんやけど。
#>156で指摘されてるね
もしかして、セッション確立させておいて、放置プレイということはない？
むかしAlteonのサイトで、TCPセッションが確立したあとにGETとかのHTTP
コマンドを発行せずに放置する攻撃を受けている、ていう書き込みがあった
んだけど、今回はそれではないの？
調子悪いときのnetstat -aがあればわかるのかな。
■ このスレッドは過去ログ倉庫に格納されています