UNIX 板からリンクが張られてたので見にきたんだけど…
(ふだんは、この板は見てない。)

>>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 は最悪の選択。