>>330
> "backlog"中のACK待ち行列は timeout前であっても破棄される可能性があり、
> "backlog"から（領域あふれで？）破棄されると"tcp_max_syn_backlog"から
> も破棄される。

ここまでは正しい。

> つまり、「クライアントからのACK到着がtimeout前であってもコネクション
> 確立失敗として扱いますよ」というのが動作原理だと読み取ったのですが。
> 違いますでしょうか？

そういう風にbacklogから破棄された場合でも、コネクションが確立できると
いうのがsyn cookiesのミソ。handshakeの3番目のACKが届いたが、そのACKに
対する確立待ちのコネクションがない場合の処理を読んでみるのがいいかもし
れん。それより、syn cookies の動作原理を探して読んでみる方が早いかも。

>>328 >>329
> だれか 327に説明してやってくれ

うーん、よく分からん。
xinetdをあの設定で動かした場合、WWWサーバーにはWWWクライアントのアドレス
として、xinetdを動かしているマシンのアドレスが見えてしまうと思うが…
というわけで、あの設定だけだと、proxy規制処理がうまく動かなくなるのでは？

>>331
> ところで、攻撃は本当にSYN floodなの？80以外のTCPサービスが有効だと
> いうのがどうにも解せないんやけど。
> #>156で指摘されてるね

2ch で、syn cookies の設定がされてなかったなら、syn flood だと考えてい
いと思う。Linux の tcp_max_syn_backlog は、ポートごと (socketごと) に
チェックしているので、syn flood を受けると backlog が溢れて、そのポー
トだけ接続できなくなるけど、他のポートは接続できる。つまり、観察されて
いる現象と同じになる。
tcp_max_syn_backlog を非常に大きく設定している場合には、こうじゃなくて
全ての TCP ポートに接続できなくなるけど、そういう特別な設定はしてなかった
んでしょ？