5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

SYN Flood●(2chの危機)

1 :七紙:02/02/11 10:33
今回の大規模なトラブルについてUnix板の考える対策はどうでしょう?


韓国攻撃の状況証拠

韓国掲示板(ここで2ちゃん攻撃が扇動されている)
http://bbs.korea.co.kr/cgi-bin/view.cgi?table=business&id=70050770&pos=0&page=1
↑の日本語訳
http://korea.hanmir.com/ktj.cgi?url=bbs.korea.co.kr%2Fcgi-bin%2Fview.cgi%3Ftable%3Dbusiness%26id%3D70050770%26pos%3D0%26page%3D1+&x=13&y=9
首相官邸も攻撃目標?
http://korea.hanmir.com/ktj.cgi?url=bbs.korea.co.kr%2Fcgi-bin%2Fview.cgi%3Ftable%3Dbusiness%26id%3D70050850%26pos%3D1%26page%3D1&x=17&y=13

夜勤が取っていたログ
http://mentai.2ch.net/test/read.cgi/accuse/1013274655/170-

649 :名無しさん@お腹いっぱい。:02/02/21 21:42
>>648
>UNIX系OSのAPIはシンプルで良いですね。
NT/2000/XPでも、includeするヘッダファイルの名前さえ変えれば、
コンソールアプリやネットワークアプリは結構動きますよ

650 : ◆L2oUNIXE :02/02/21 22:40
>>649
そういえばWin32のAPIはBSDを元に作られてたんですっけ。

というわけで、役に立ちそうなページを発見。
ttp://www.nakka.com/lib/inet/

651 :624:02/02/21 22:41
>>560
>  有意な差が見れなかったのが謎として残る(呼量が足りない?)

うん。呼量が足りてないというので合っていると思う。
これがもし linux-2.2 のデフォールト設定が相手だったら、
tcp_max_syn_backlog が 128 しかないので、SYN flood による障害が観測で
きてただろうけど。

以下、俺の理解なので、もし間違っていたら指摘してね。

・コネクション確率待ちキューのサイズ (Solaris なら tcp_conn_req_max_q0、
 BSD/OS, NetBSD の syncache なら net.inet.tcp.syn_cache_limit、
 FreeBSD の syncache なら net.inet.tcp.syncache.cache_limit、
 Linux なら tcp_max_syn_backlog) を、M とする。
・毎秒 N 個の SYN が到着するものとする。
 また、既に SYN flood 下にあり、恒常的に SYN を drop している状況下に
 あるものとする。
・クライアント・サーバー間の RTT を t 秒とする。

random drop 戦略の場合 (Solaris は、これじゃないかなあ)
SYN が 1 つ届いた時に、drop されないですむ確率は (M-1)/M。
コネクションが確立するまでの間に届く SYN の数は N * t。
従って drop されずにコネクションが確立する確率は、
((M-1)/M) ** (N * t)。
実際には、発呼側は SYN の再送を試みる。K回再送しても
コネクションを確立できない確率は、下記の通りとなる。
(1 - ( ((M-1)/M) ** (N * t) ) ) ** K
oldest drop 戦略の場合 (伝統的実装は こちら。syncache も これ。)
SYN がキューに留まっている時間は M/N 秒。
従って t <= M/N ならコネクションは確立するし、
t > M/N だと、確立できない。

続く…

652 :624:02/02/21 22:43
560の実験の場合、M==1024、N==1000。
問題は t なんだけど、うちの LAN (100BASE-T) で計測すると、TCP の 3way
handshake にかかる時間は、1ミリ秒よりずっと小さいのね。
で、たとえば t==500μ秒==0.0005秒くらいで計算すると
random drop の場合
  drop されない確率は 0.999512 くらい。つまり、2050回に一回ぐらいの
  確率で SYN の再送が起きる。
oldest drop の場合
  0.0005 ≦ 1.024 (== 1024/1000) なので、確実にコネクションは確立する。
というわけで、t==500μ秒で、1000 SYN/秒 だと、障害は観測できないと予想できる。

RTT=1秒くらい(ちょっと長いか?)の WAN 環境の場合で計算すると
random drop 戦略の場合
・M = 1024、N = 1000 SYN/秒で、コネクションを確立できる確率は 38%
 くらい。たとえ遅延が許容できたとしても、伝統的 TCP の実装だと
 再送間隔は 6秒、12秒、24秒 で 計4回なので、(1-0.38) ** 4 == 0.15...
 つまり、15% くらいの確率でコネクション確立に失敗する。
 失敗の確率を 1% まで落とそうとすると、M = 2600 程度まで増やす必要がある。
・RTT=1秒、10000 SYN/秒 で、失敗の確率を 1% に落とそうとすると、
 M = 26000 くらい必要。100000 SYN/秒 だと M = 260000 くらいになる。
oldest drop 戦略の場合
・1000 SYN/秒なら OK。1024 SYN/秒を越えると駄目。
・t <= M/N すなわち M >= t*N を維持する必要があり、かつ t==1秒 と仮定
 しているから、M >= N という設定にする必要がある。
・FreeBSD の場合デフォールトで M=15360、NetBSD だと M=10255 なので、
 N がこれくらいのオーダーを越えるようなら、M を増やした方が良い。
 (FreeBSD の場合、デフォールト通り syncookies が有効なままならば、
  この必要はないが。)

ふむむ、なんとなく oldest drop の方が、ちょっと良い感じ。
Solaris が本当に random drop なのかどうかは確認してないので、調べた
人がいたら報告希望。


653 :624:02/02/21 22:53
> ふむむ、なんとなく oldest drop の方が、ちょっと良い感じ。

あ、これはカーネル資源の消費だけ考えた場合の話ね。

oldest drop の場合、RTTが大きい(==遠いサイト)サイトは、SYN flood下
だと、どう頑張っても接続できない結果になるのに対し、random drop だと
そういう場合でも時々は接続できるので、random と oldest の どちらを
選択するかは結局、純粋にポリシーの問題。


654 :560:02/02/22 01:31
>>624
う 酔っぱなので半分くらいしか式の意味を実装レベルに落せてないが、
おおまかにはそんなもんなのね?

Internet上のwebサービスっていう側面を考えると、
伝送損失による到着率低減をもう少し見こんでもいいかなとは
思うものの・・・私の試験環境はちょっと劣悪だったかもね 認めます。
(バックログ:q0側 が1024コだから、毎秒20コ送ったとして50秒あれば
 陥落するかなと思ったのね。ちと考えが甘かったか)

ところで652の・の1つめはM=2600じゃなくてN=2600じゃないの?
(FIFOだから、うまいことベラディーの法則が効くとすると、
 呼量 < バックログが成り立つとは思うけど)

netstat-Iの結果は、同一セグメント上のsolaris7で打ったとき、
で1000/sec程度だった。
どぼーんを複数クライアントから実験しないと、
solarisを陥落できない、というのはうまく説明がついてるので、
説明は大筋あってると思われ。(精査してないから大筋、とします スマソ)
x2.6だから3クライアントからどぼーんやればイイっつーことか。

そこまでおおっぴらにできるかどうか不明だが・・・ちょっと頑張るわ。

655 :624:02/02/22 02:42
> ところで652の・の1つめはM=2600じゃなくてN=2600じゃないの?

いや、M=2600のつもり。
キューの長さが短いと、コネクション確立の確率(言いにくいから、
ここからはコネクション成功確率と書こう)が下がり、
キューの長さが長くなると、コネクション成功確率は上がるわけで、
RTT=1秒、M=1024の場合だと (100%-15%)=85% の成功確率しかないものを、
成功確率99%まで上げるにはどうするかを求めているわけだから、
当然必要なキューの長さは長くなる。

> x2.6だから3クライアントからどぼーんやればイイっつーことか。

いや、LANで試すなら、3クライアントぐらいじゃ症状は出ないと思う。
この成功確率38%(==再送も含めた場合の成功確率85%)っていうのは、
RTT=1秒とかなり長めの場合の話ね。
RTTが短くなれば短くなるほど成功確率は高くなり、SYN flood 障害が
観測できる可能性は減る。RTT=0.5ミリ秒のLAN環境で、成功確率を
90%まで下げるには、20万SYN/秒くらい必要になる。これは100BASE-T
では、そもそも実験すらできないんじゃないかな。

成功確率を下げるには、呼の回数を増やす以外に、RTTを増やすという
手もあって、こっちの方がたぶん簡単だと思う。

> そこまでおおっぴらにできるかどうか不明だが・・・ちょっと頑張るわ。

RTTが関係するのはクライアントとサーバー間だけで、SYN flood attack
をかける側のRTTは関係ないので、実行するのなら、サーバーと
同一LAN環境から SYN flood をかけて、遠方のクライアントからの
接続を試みるのがいいと思う。


656 :名無しさん@お腹いっぱい。:02/02/22 10:54
>>655
そういえば、某 ML で遅延を簡単に作り出せる箱とかが話題になって
いたけど、この手の実験にも便利に使えそうだね。

657 :名無しさん@お腹いっぱい。:02/02/22 12:12
サイトへの大量データ攻撃、自動検知し防御・慶大が新技術

 慶応義塾大学の松下温教授らは、インターネットのサイトに大量のデータを送りつけてサービスを不能
 にするサイバー攻撃を防ぐ技術を開発した。
 大量のデータが送られるのを自動的に検知して不正データをせき止め、被害を最小限に抑えるという。
 開発したのはネットワーク上で電話交換機の役割をする中継機器(ルーター)に組み込むプログラム。
 大量のデータが一定時間流れるなど、あらかじめ設定した不正とみなす条件をルーターが検出すると、
 データのあて先と種類などの属性をネットワークの管理コンピューター(サーバー)に送る。サーバーは
 ネット上の全ルーターに属性情報とデータ流入をせき止めるプログラムを送る。ルーターは不正なデータ
 だけをせき止め、通常のデータは通過させる。
 新技術は多数のコンピューターからいっせいにデータを送る大規模攻撃に対して特に威力を発揮する。
 これまではサイトが個別に侵入検知システムを設置していたが、大規模攻撃を防ぐのは難しかった。

 http://it.nikkei.co.jp/it/top/topCh.cfm?id=20020221eimi243121

とのことですが、IP偽装のSYN floodに対しては無力そうですね。

658 :名無しさん@お腹いっぱい。:02/02/22 13:16
>>657
Smurfとかには有効でしょう。

659 :名無しさん@お腹いっぱい。:02/02/22 20:17
>>636

> 1. 19日以前は2ch サーバの関係するカーネルのパラメタはデフォルト値が128の
>  まま放置されていたサーバがあったのではないか。
> tcp_max_syn_backlog 128
> これだけでかなり synflood への耐性が上がる。

これって、linux-2.2 までだと、まずいんじゃない?
linux/net/ipv4/tcp_ipv4.c:tcp_v4_search_req() を読めばわかるけど、
linux-2.2 系って、backlog の検索に linear search を使っているから、
backlog を長くすれば長くするだけ、カーネルのCPU負荷が上がってしまう。

syncookieの計算負荷なんて、たかだか定数コストだけど、linux-2.2 上での
backlog 検索の負荷は、651の用語で書くと O(M*N) だから、syncookie の計
算コストよりも、ずっとカーネルにかかるCPU負荷が大きい。

だから、linux-2.2 系で HTTPサーバーをやっているなら、tcp_max_syn_backlog
は増やさずに、さっさと syncookies にまかせた方がいいと思う。

linux-2.4 系は、ハッシュを使うように変わったから、こっちだと
tcp_max_syn_backlog を増やしてもいいけど。


660 :659:02/02/22 21:22
> syncookieの計算負荷なんて、たかだか定数コストだけど

あ、ちょっと間違えた。
次の行の O(M*N) で N を使っているから、この観点だと、
syncookieの計算負荷は O(N) でした。

もっとも結論は変わらないけど。
SYN flood 攻撃を受けてなくても tcp_max_syn_backlog が溢れてるのなら、
もちろん tcp_max_syn_backlog を増やす必要があるんだけど、
SYN flood 攻撃で溢れるような状況であれば、linux-2.2 だったら
tcp_max_syn_backlog は増やすべきじゃなくて syncookies に任せた方がいい。

なんか283と同じこと言っているだけだな。


661 :名無しさん@お腹いっぱい。:02/02/22 21:27
>>659
線型に計算量が増えるんなら O(N) だと思うが。

662 :661:02/02/22 21:27
うが、既に訂正された後だったかいな。

663 :軍事版住民:02/02/22 21:49
名前: 軍事版住民
E-mail:
内容:
あるFRASH見たのですが、8・25のとき2CHを救ってくれたのは
あなた方だったんですね、まだ2CH歴史も浅い私ですが、尊敬の意をこめてをこめて、

敬礼


664 :名無しさん@お腹いっぱい。:02/02/22 21:55
>>663
まだやるか?っつーかネタか?春蟲か?
 (おっ、はからずも俳句:季語入り)

665 :名無しさん@お腹いっぱい。:02/02/22 22:45
 あぁ、なんかあちこちに軍事板住人騙って煽りカキコ&コピペして、
他の板と軍事板を衝突させようと画策してるバカがいるみたい。
 それの新手でしょ。

 こういう人間SYN floodもdropできないもんかなぁディラックの海へ


666 :名無しさん@お腹いっぱい。:02/02/22 22:51
今だ!666ゲットォォォォ!!
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄       (´´
     ∧∧   )      (´⌒(´
  ⊂(゚Д゚⊂⌒`つ≡≡≡(´⌒;;;≡≡≡
        ̄ ̄  (´⌒(´⌒;;
      ズザーーーーーッ



667 :名無しさん@お腹いっぱい。:02/02/23 00:55
>>665
マクセルの悪魔どまりだからムリでしょう


668 : ◆L2oUNIXE :02/02/23 19:37
>>665
それを言ってしまえば、2t
ニュース速報板で、韓国の掲示板にサイバーテロ
予告をでっち上げ、瞬く間に2ちゃんねる中に広がった事件あったですね。
満州事変みたいなやつですな。アンチ韓国なN速厨の火を付けたと。

669 :名無しさん@お腹いっぱい。:02/02/23 19:39
>668
>アンチ韓国なN速厨の火を付けたと。
アンチ韓国なN速厨に火を付けたと。じゃない?

670 : ◆L2oUNIXE :02/02/23 19:39
ミスった。
ノートPCでカキコなのだが、タッチパネルを殺しておくべきですね。

671 :名無しさん@お腹いっぱい。:02/02/23 19:49
>670
不便だよねタッチパネル。

672 :名無しさん@お腹いっぱい。:02/03/10 07:39
>>671
BIOSメニューやコントロールパネルで無効に出来る機種だと
簡単に切れていいね

673 :age2ch.pl:02/03/10 08:34
>>1 itteyoshi

674 :名無しさん@お腹いっぱい。:02/03/20 23:08
韓国氏ね                

675 :名無しさん@お腹いっぱい。:02/03/22 01:58
へたれ  

676 :Dream ★:02/03/24 23:36
「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/l50
【2ちゃんねるビューア】 巡回機能の巻。Part3
http://pc.2ch.net/test/read.cgi/software/1016905060/l50

この二ヶ所でいま、対策なんかの話をやっています。
お力添えいただける方はお願いします。

677 :名無しさん@お腹いっぱい。:02/04/06 02:10
>42
(((( ;゚Д゚)))ガクガクブルブル

678 :名無しさん@お腹いっぱい。:02/04/06 02:11
うわっ誤爆してる…ウツダシノウ

679 :名無しさん@お腹いっぱい。:02/04/13 15:02
さげ

680 :名無しさん@お腹いっぱい。:02/08/21 02:31
 (( ∩ )) プルプルプル
  γ'⌒ヽ∧ ∧
   し'ゝつ( ゚Д゚)つ

681 :名無しさん@お腹いっぱい。:02/09/25 20:04
とりあえずsageとく

682 :FROM就職板:02/10/18 22:16
質問させていただきます。
ここの住民が2CHを救ったという話は本当ですか?

683 :名無しさん@Emacs:02/10/18 22:17
>>682 氏ね


684 :名無しさん@お腹いっぱい。:02/10/18 22:25
>>682
嘘です犬板の住民が救いました。

685 :名無しさん@Emacs:02/10/18 22:30
>>684
その通りです。
http://pc.2ch.net/linux/ へ行ってスレッド立ててください :)

686 :山崎渉:03/01/16 04:05
(^^)

687 :名無しさん@お腹いっぱい。:03/03/15 18:46
サムい

688 :山崎渉:03/04/17 12:18
(^^)

689 :山崎渉:03/04/20 06:10
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

690 :山崎渉:03/05/22 02:23
━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━―

691 :あぼーん:あぼーん
あぼーん

692 :山崎 渉:03/07/15 11:29

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

693 :あぼーん:あぼーん
あぼーん

694 :あぼーん:あぼーん
あぼーん

695 : :04/03/07 19:00
保守

696 :名無しさん@お腹いっぱい。:04/03/07 19:04
保守はsageでもできますよsage

697 :名無しさん@お腹いっぱい。:04/03/07 19:08
>>1の韓国2ch攻撃予告から
約二年後に攻撃があったな。すげえ偶然。

698 : :04/03/08 10:53
それは二回目の攻撃でしょ(F5団

184 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)