想听听delphij解说一下FreeBSD在对synflood攻击方面的评价

站在岸上的鱼

我知道delphij是国内少有的几个FreeBSD维护者之一，对FreeBSD了解非常深入，所以向你请教一下，关于FreeBSD在抗synflood攻击的能力上有什么见解？或者FreeBSD在处理synflood攻击的一些机制，比如tcp blackhole以及udp blackhole等。谢谢。

站在岸上的鱼

当然了，其他了解的希望也能发表一下意见。

colddawn

blackhole根本不是用来防synflood的，并且这个机制也不是freebsd独有，连windows都实现了。

platinum

linux 下有个 syncookie 的功能，能缓解 dos 造成的伤害，但很有限
syncookie 严重违背了 TCP/IP 原理，因此也有一些副作用
不知道 blackhole 是咋意思，也希望有人能详细说一下，网上这方面的文章（能阐述原理的）不多

delphij

syncookie 严重违背了 TCP/IP 原理，因此也有一些副作用

请问syncookie违反了哪个TCP/IP原理(i.e. RFC?)

delphij

[quote]原帖由 "platinum"]不知道 blackhole 是咋意思，也希望有人能详细说一下，网上这方面的文章（能阐述原理的?.........[/quote 发表：


blackhole没啥特别，默认的对非开放端口的SYN响应是回应RST，开启blackhole之后直接丢弃SYN packet，不做任何回应。blackhole可以用以降低半开式端口扫描的可靠性并提高其成本。

platinum

原帖由 "delphij" 发表：


请问syncookie违反了哪个TCP/IP原理(i.e. RFC?)

syncookie 的原理是，收到 SYN 包并返回 SYN+ACK 包时，不立即分配数据区，而是根据这个 SYN 包计算出一个 cookie 值
在收到 ACK 包时，服务器再根据 cookie 值检查这个 ACK 包的合法性
如果合法，再分配专门的数据区进行处理未来的 TCP 连接，不过我想这种方法很耗费 CPU

至于是否真的违背 TCP/IP ，我没有查到资料，我只记得看过几次不同的资料都提及说有违背 TCP/IP 原理
刚才特意去查了一下，没有查到，只看到了那些说违背原理的贴子
http://www.linuxfans.org/nuke/modules.php?name=News&file=article&op=view&sid=2609
没查到具体提及是何 RFC

原帖由 "delphij" 发表：

blackhole没啥特别，默认的对非开放端口的SYN响应是回应RST，开启blackhole之后直接丢弃SYN packet，不做任何回应。blackhole可以用以降低半开式端口扫描的可靠性并提高其成本。

delphij 兄认为 blackhole 和 syncookie 哪个好呢？
如果二者结合使用可不可以？效果会不会更好？

benjiam

没有违法tcp/ip 协议吧  按协议卷一里说法 只是服务器本身在建立的连接前 对发过来的syn 信息多校验一次

delphij

据我所知没有(何时建立TCB在RFC里面没有明确定义)，我以为又有人发现了违反的实例呢 ^_^ syncookie确实吃一些CPU，所以FreeBSD的做法是只有SYN Cache充满的时候才去验证SYN Cookie(生成部分只要打开了就会生成，但接收时只有SYN Cache充满才验证)，以期达到提高性能的目的。

blackhole和syncookie是两个不同的概念，一个是防止扫描的，另一个是防止SYN Flood的，两者不能相互替代。对于多数服务器来说打开syncookie（默认）非常必要，打开blackhole有助于提高攻击者扫描的代价，但并不能显著地改善安全性。

platinum

绿盟的黑洞防火墙有一种功能，就是当 scan port 的时候，不管该 port 有没有服务，都返回一个有服务的结果
这个是如何实现的呢？

另外，IP 头里面有 TOS 标记，但我通过 sniffer 抓包，发现 telnet 没有置 TOS，而 ssh 在开始的时候设置了 0x10（最小延迟），但除此之外的其他内容又没有了 TOS，这是为什么？
IP 包内容如下

23:47:16.766572 172.25.39.254.ssh >; 172.25.39.1.1643: P 422788852:422788920( 68 ) ack 2534237975 win 8576 (DF) [tos 0x10]
0x0000   4510 006c 4d96 4000 8006 05b4 ac19 27fe        E..lM.@.......'.
0x0010   ac19 2701 0016 066b 1933 3ef4 970d 6717        ..'....k.3>;...g.
0x0020   5018 2180 aa32 0000 6fb0 1671 94cb 445f        P.!..2..o..q..D_
0x0030   1ad7 e442 236d a8cf 0fa3 ba07 b535 6868        ...B#m.......5hh
0x0040   cdc2 26f9 97c4 48d8 1682 48ed c4eb d54d        ..&...H...H....M
0x0050   f25b 6d1a 2451 287a 38ed 3e83 b127 3f43        .[m.$Q(z8.>;..'?C
0x0060   9611 bde1 d6f7 562f 28d2 40df                  ......V/(.@.
23:47:16.766709 172.25.39.1.1643 >; 172.25.39.254.ssh: . ack 68 win 16568 (DF)
0x0000   4500 0028 6f06 4000 8006 e497 ac19 2701        E..(o.@.......'.
0x0010   ac19 27fe 066b 0016 970d 6717 1933 3f38        ..'..k....g..3?8
0x0020   5010 40b8 6ad9 0000 2020 2020 2020             P.@.j.........
23:47:26.469277 172.25.39.1.1763 >; 61.48.85.86.ssh: S 3872826882:3872826882(0) win 16384 <mss 1460,nop,nop,sackOK>; (DF)
0x0000   4500 0030 6f11 4000 8006 2616 ac19 2701        E..0o.@...&...'.
0x0010   3d30 5556 06e3 0016 e6d6 a602 0000 0000        =0UV............
0x0020   7002 4000 49ac 0000 0204 05b4 0101 0402        p.@.I...........
23:47:26.478409 61.48.85.86.ssh >; 172.25.39.1.1763: S 280311705:280311705(0) ack 3872826883 win 5808 <mss 1412>; (DF)
0x0000   4500 002c 0000 4000 7806 9d2b 3d30 5556        E..,..@.x..+=0UV
0x0010   ac19 2701 0016 06e3 10b5 3799 e6d6 a603        ..'.......7.....
0x0020   6012 16b0 3fd4 0000 0204 0584                  `...?.......
23:47:26.478553 172.25.39.1.1763 >; 61.48.85.86.ssh: . ack 1 win 16944 (DF)
0x0000   4500 0028 6f12 4000 8006 261d ac19 2701        E..(o.@...&...'.
0x0010   3d30 5556 06e3 0016 e6d6 a603 10b5 379a        =0UV..........7.
0x0020   5010 4230 2be1 0000 2020 2020 2020             P.B0+.........
23:47:26.498090 61.48.85.86.ssh >; 172.25.39.1.1763: P 1:23(22) ack 1 win 5808 (DF)
0x0000   4500 003e e786 4000 7806 b592 3d30 5556        E..>;..@.x...=0UV
0x0010   ac19 2701 0016 06e3 10b5 379a e6d6 a603        ..'.......7.....
0x0020   5018 16b0 6b2d 0000 5353 482d 322e 302d        P...k-..SSH-2.0-
0x0030   4f70 656e 5353 485f 332e 3970 310a             OpenSSH_3.9p1.
23:47:26.498447 172.25.39.1.1763 >; 61.48.85.86.ssh: P 1:29(28) ack 23 win 16922 (DF)
0x0000   4500 0044 6f13 4000 8006 2600 ac19 2701        E..Do.@...&...'.
0x0010   3d30 5556 06e3 0016 e6d6 a603 10b5 37b0        =0UV..........7.
0x0020   5018 421a 37aa 0000 5353 482d 322e 302d        P.B.7...SSH-2.0-
0x0030   5075 5454 595f 5265 6c65 6173 655f 302e        PuTTY_Release_0.
0x0040   3538 0d0a                                      58..

前两步是与网关协商 NAT，然后是真正的出去
注意里面红色的内容，开始 TOS 是被设置了的，但然后就又没了，这个是 ssh 的结果


问题三：
看 TCP/IP 大全第一卷里面写道

现在大多数的 TCP/IP 实现都不支持 TOS 特性，但是自4.3BSD Reno以后的新版系统都对它进行了设置。另外，新的路由协议如O S P F和I S - I S都能根据这些字段的值进行路由决策。

设置和不设置 TOS 对网络性能到底会不会有影响呢？

请 dephij 兄继续赐教 ^_^