TCP UDP 区别和SYN-FLOOD攻击
下面是各家的理论：TCP-有连接,所以握手过程会消耗资源,过程为可靠连接,不会丢失数据,适合大数据量交换&& UDP-非可靠连接,会丢包,没有校验,速度快,无须握手过程TCP---传输控制协议,提供的是面向连接、可靠的字节流服务。当客户和服务器彼此交换数据前，必须先在双方之间建立一个TCP连接，之后才能传输数据。TCP提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。 UDP---用户数据报协议，是一个简单的面向数据报的运输层协议。UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快。 用TCP还是UDP，那要看你的程序注重哪一个方面？可靠还是快速？从专业的角度说，TCP的可靠保证，是它的三次握手机制，这一机制保证校验了数据，保证了他的可靠性。而UDP就没有了，所以不可靠。不过UDP的速度是TCP比不了的，而且UDP的反应速度更快，QQ就是用UDP协议传输的，HTTP是用TCP协议传输的，不用我说什么，自己体验一下就能发现区别了。再有就是UDP和TCP的目的端口不一样（这句话好象是多余的），而且两个协议不在同一层，TCP在三层，UDP不是在四层就是七层。
DoS（Denial of Service拒绝服务）DDoS（Distributed Denial of Service分布式拒绝服务）1，SYN Flood利用的是TCP协议&&缺陷2，一个正常的TCP连接需要三次握手，首先客户端发送一个包含SYN标志的数据包，其后服务器返回一个SYN/ACK的应答包，表示客户端的请求被接受，最后客户端再返回一个确认包ACK，这样才完成TCP连接。3，在服务器端发送应答包后，如果客户端不发出确认，服务器会等待到超时。4，等待期间，这些，半连接，都保存在一个空间有限，的缓存队列中。5，如果大量的SYN包，发到服务器端后没有应答，就会使服务器端的TCP资源迅速耗尽。6，导致正常的连接不能进入，甚至会导致服务器的系统崩溃。
请各位遵纪守法并注意语言文明[精彩] 讨论一下如何防范SYN-FLOOD攻击的问题 - ChinaUnix.net
[精彩] 讨论一下如何防范SYN-FLOOD攻击的问题
http://www.chinaunix.net 作者:&&发表于： 13:56:23
有人说echo&1&&;&/proc/sys/net/ipv4/tcp_syncookies可以组织SYN-FLOOD攻击
还有人说，IPTABLES里设置-m&limit&n/s&--limit-burst&n可以限制并发流来阻止攻击
刚才在VMWARE里做了试验，用软件攻击自己的VMWARE里的APACHE
结果发现/proc/sys/net/ipv4/tcp_syncookies设置后无济于事
IPTABLES里做了限制，虽然能限制并发流，不至于让机器的网络瘫痪，但HTTP还是无法使用了，还是达到了“拒绝服务”的效果
很无奈……
我想了另一个解决SYN攻击的方法，但是需要SHELL编程
大家有没有什么高见？
& 回复于： 00:46:39
& 回复于： 01:23:15
没有哟，等你搞出了，拿你的成果哈
嚸嘿
& 回复于： 01:27:02
现在没有能很好抵御syn-flood的方式吧.
对层的概念仍然不很明朗,所以...
不管如何都会塞住带宽...以及路由的低效....
不熟悉,请指教........
& 回复于： 15:34:00
引用：原帖由&"双眼皮的猪"&发表：现在没有能很好抵御syn-flood的方式吧.
对层的概念仍然不很明朗,所以...
不管如何都会塞住带宽...以及路由的低效....
不熟悉,请指教........
DDOS是不能防御的，SYN-FLOOD属于DOS，可以防御的
& 回复于： 18:25:44
我见到比较好的方法是用防火墙
先由防火墙建立连接经过三次握手再传给服务器对付syn&flood
& 回复于： 19:34:32
“经过三次握手再传给服务器对付syn&flood”
再阐述一下？
：）
& 回复于： 21:06:32
引用：原帖由&"platinum"&发表：
DDOS是不能防御的，SYN-FLOOD属于DOS，可以防御的
谢谢指点:)
上次去北京买了本TCP/IP详解卷一,协议,结果在邯郸搞丢了.
郁闷ing..
这不,签到杭州了,就不去北京陪你玩啦,嘿嘿~
& 回复于： 23:10:08
引用：原帖由&"platinum"&发表：“经过三次握手再传给服务器对付syn&flood”
再阐述一下？
：）
呵呵,其实我也是不懂的,对协议了解不深刻.
一般的syn&flood&是大量的客户端去连接服务器.建立一次握手后就不再继续,于是服务器等待超时.
如果大量的sys连接的话就会造成服务器压力或者连接数满而达到目的.
可以用防火墙来先与客户端建立连接,达到三次握手的才传给服务器,减轻服务器压力.但必须好的防火墙啊,他本身就会成为弱点.
还有可以多服务器分时,由防火墙分别按算法发配请求.
& 回复于： 08:58:37
把你shell的思想说出来行不？
& 回复于： 09:09:31
安装防DDOS攻击软件
#&tar&-zxvf&mod_dosevasive.1.9.tar.gz
#&cd&mod_dosevasive
#&/usr/local/apache/bin/apxs&-iac&mod_dosevasive20.c
#&vim&/usr/local/apache/conf/httpd.conf
&IfModule&mod_dosevasive.c&;
DOSHashTableSize
3097
DOSPageCount
3
DOSSiteCount
50
DOSPageInterval
1
DOSSiteInterval
1
DOSBlockingPeriod
30
&/IfModule&;
& 回复于： 09:15:50
引用：原帖由&"llzqq"]&发表：
这个好象没什么作用，基于apache1的模块
& 回复于： 10:03:26
这个是&FOR&APACHE2的
& 回复于： 10:21:19
引用：原帖由&"haohaoo"]把你shell的思想说出来行不？&发表：
是这样的，当我们发现被DOS攻击以后怎么办呢？
如何确定是否被DOS攻击呢？
netstat&-an，查看ESTABLISHED数，然后禁掉该IP
SHELL思想也类似，写一个SHELL，让CROND每分钟运行一次
SHELL去检查ESTABLISHED数量，然后统计某ESTABLISHED数量最高的IP
然后向iptables里-I&INPUT一条-s&IP&--p&tcp&--dport&PORT&-j&DROP
也就是说，让防火墙具有自动更改规则的动态机制
这个想法可行吗？
& 回复于： 11:32:45
iptables&-A&FORWARD&-p&tcp&--syn&-m&limit&--limit&1/s&-j&ACCEPT&&应该是可以的。
& 回复于： 11:42:26
“SHELL去检查ESTABLISHED数量，然后统计某ESTABLISHED数量最高的IP&
然后向iptables里-I&INPUT一条-s&IP&--p&tcp&--dport&PORT&-j&DROP&”
不行把，每分钟都这样做，那不是很快屏蔽很多网站？？！！
& 回复于： 11:43:52
iptables&-A&INPUT&-m&state&--state&ESTABLISHED,RELATED&-j&ACCEPT
这句是有的，否则防火墙不允许其他人连接，我的默认规则是DROP，所以必须加这个，问题是已经加了，但不能防止SYN攻击
& 回复于： 14:52:34
引用：原帖由&"platinum"&发表：
是这样的，当我们发现被DOS攻击以后怎么办呢？
如何确定是否被DOS攻击呢？
netstat&-an，查看ESTABLISHED数，然后禁掉该IP
SHELL思想也类似，写一个SHELL，让CROND每分钟运行一次
SHELL去检查ESTABLISHED数量..........
ESTABLISHED数多少的时候就砍掉呢？
& 回复于： 15:35:13
我想，这是一个阀值问题，可以自己根据服务器的性能配置
同一个IP地址，超过20个ESTABLISHED，就应该可以封了吧，谁会同时连那么多！
& 回复于： 15:49:01
引用：原帖由&"platinum"&发表：我想，这是一个阀值问题，可以自己根据服务器的性能配置
同一个IP地址，超过20个ESTABLISHED，就应该可以封了吧，谁会同时连那么多！
假如用专线然后用的代理服务器上网呢？对外都是同一个ip吧……但是同事们上同一个网站的话，就是同一个ip。
& 回复于： 15:52:53
这个问题我也想到了
但是，一个单位的同事们会同时有20个人以上来访问吗？
何况HTTP协议不是一直ESTABLISHED的，读完网页就CLOSE
如果同一个IP有20个以上的ESTABLISHED，那肯定不正常
对吧：）
& 回复于： 23:18:43
purge觉得这是一个方法，思路的问题。以前看到过这样的讨论。
比如，可以这样：
做防火墙的机子收到客户端的SYN包时，直接转发给服务器；
然后，收到服务器回应的SYN/ACK包后，一方面将SYN/ACK包转发给客户端，不去管它；
另一方面以客户端的名义给服务器回送一个ACK包，完成TCP的三次握手；这样，可以使服务器完成连接状态。
当客户端真正的ACK包到达时，有数据则转发给服务器，否则丢弃该包。
理由是：服务器能承受连接状态要比半连接状态高得多，所以这种方法能有效地减轻对服务器的攻击。
没有实践过，但是这是一个思路。
& 回复于： 23:56:13
……
去翻翻TCP/IP的资料先
然后想想实现的方法
……
& 回复于： 00:05:03
引用：原帖由&"弱智"&发表：做防火墙的机子收到客户端的SYN包时，直接转发给服务器；&
然后，收到服务器回应的SYN/ACK包后，一方面将SYN/ACK包转发给客户端，不去管它；&
另一方面以客户端的名义给服务器回送一个ACK包，完成TCP的三次握手；这样，可以使服务器完成连接状态。&
当客户端真正的ACK包到达时，有数据则转发给服务器，否则丢弃该包。&
参见OpenBSD中pf的synproxy动作，例如：
pass&in&on&$ext_if&proto&tcp&from&any&to&$web_server&port&www&flags&S/SA&synproxy&state
& 回复于： 10:37:11
引用：原帖由&"弱智"&发表：purge觉得这是一个方法，思路的问题。以前看到过这样的讨论。
比如，可以这样：
做防火墙的机子收到客户端的SYN包时，直接转发给服务器；
然后，收到服务器回应的SYN/ACK包后，一方面将SYN/ACK包转发给客户..........
也不稳妥吧。
SYN半连接DOS，不是看消耗的资源多不多，而是到一定半连接数量时，服务器就不会接受SYN请求，这样来做到DOS，这个时候服务器资源占用的并不多。但你提出的完成握手，这样的话，系统很快可能达到进程/线程上限，整个系统的资源将有可能耗尽，比上一种情况更危险。
我是这么理解的&：）
& 回复于： 10:46:03
如果是正常的SYN是没办法的，因为，你总不能不让别人用吧？
如果是非正常的SYN，好象有办法吧？
& 回复于： 11:02:02
引用：原帖由&"弱智"&发表：purge觉得这是一个方法，思路的问题。以前看到过这样的讨论。
比如，可以这样：
做防火墙的机子收到客户端的SYN包时，直接转发给服务器；
然后，收到服务器回应的SYN/ACK包后，一方面将SYN/ACK包转发给客户..........
问题是，怎么实现。如果把所有的SYN包现交给firewall,firewall又如何判别哪个包是合法的，哪些是不合法的。如果firewall无法判别，那垮掉的虽然不是apache&server,但一定会使firewall，造成的损失更严重不是吗。
& 回复于： 13:11:42
如果不从根本上修改TCP协议,TCP的SYN_FLOOD根本无法预防!
参见:
http://bbs.chinaunix.net/forum/viewtopic.php?t=23116&highlight=JohnBull
现在在Liunx平台上可以考虑用SCTP取代TCP.
& 回复于： 14:18:27
对于syn攻击，有几种方法可以防御。
1、最有效的，增加带宽，做集群。
2、使用基于状态的防火墙，也就是以上各位说的三次握手。
3、从交换机上监听网络上的syn数据，当发送了syn包到服务器后，该地址一定时间内没有继续发送剩下的两个包。程序就冒充改ip和端口发送端开的IP包。
不能通过shell来解决，因为攻击者的IP和端口都是假冒的。
freebsd有非官方的解决方法，对dos有效，但是对ddos无法抵抗。
对于提供网络服务的话，我建议大家使用freebsd系统，毕竟是血统最纯正的unix系统，而且运算速度和网络响应速度比linux要高。
& 回复于： 14:54:58
我那天用的那个攻击软件，是用真IP进行攻击的，netstat&-an看到的是我的私网IP地址
另外“程序就冒充改ip和端口发送端开的IP包”这句不是很明白……
& 回复于： 10:30:48
引用：原帖由&"xichen"&发表：对于syn攻击，有几种方法可以防御。
1、最有效的，增加带宽，做集群。
2、使用基于状态的防火墙，也就是以上各位说的三次握手。
3、从交换机上监听网络上的syn数据，当发送了syn包到服务器后，该地址一定时间内没..........
别想了.
SCO公司大不大?APPLE公司大不大?MICROSOFT大不大?
那样的带宽和集群一样被DOS.所以增加带宽太被动了.
基于状态的防火墙也属骗人.参见我上面的引文.
交换机假冒握手更是掩耳盗铃的馊主意.殊不知一个进程可以同时打开的文件描述符有上限乎?你知道FreeBSD系统下的一个进程最多可以打开多少文件吗?那样不过是把第4层的DOS变成了第7层的DOS而已.
这一切的根本原因在于当初设计TCP/IP的时候,没有想到现在的网络环境这么复杂,没有预先充分地预防.
等SCTP取代了TCP后,这个问题就好多了.
& 回复于： 10:41:17
看来只能“改善”，不能“根治”，除非不用TCP
& 回复于： 11:11:03
引用：原帖由&"xichen"&发表：对于syn攻击，有几种方法可以防御。
1、最有效的，增加带宽，做集群。
2、使用基于状态的防火墙，也就是以上各位说的三次握手。
3、从交换机上监听网络上的syn数据，当发送了syn包到服务器后，该地址一定时间内没..........
以apache服务为例：
比较赞同这种说法的：
1.用硬件防火墙，（觉得这是最主要的手段）
2.用硬件均衡负载设备，如&Alton,load&director等；
3.apache集群；
4.限制apache服务的参数，最高CPULimit，和MemLimit，限制最长URL，限制最大bodyrequest。apache里面也做了不少能够防止DoS的工作的，大家见仁见智根据自己的机器配置进行配置。
从安全和性能之间取一个平衡。
& 回复于： 12:10:20
引用：原帖由&"platinum"&发表：我那天用的那个攻击软件，是用真IP进行攻击的，netstat&-an看到的是我的私网IP地址
另外“程序就冒充改ip和端口发送端开的IP包”这句不是很明白……
错字，是断开。现在好点的交换机都有监听端口，能听到交换机里面的所有传输数据。在这里保留这个交换机所有的syn包的状态，一般来说，三次握手的延时不会超过5秒，但是对于旧内核的linux，这个超时时间最长能达到大约5天。
那么可以在超过5秒还没有接收到后续的两个包的时候，可以发送RST（记不清楚是否是这个包了）包，来让被dos攻击的服务器认为客户端已经断开了连接，从而释放了这个连接。
当然ddos攻击是任何系统任何设备都无法抵挡的，我们能做的只是让系统尽量的抵御攻击。
还有，现在高手门已经通过将一个syn包分解为多个IP包的方式来穿越防火墙，这个包不会被普通防火墙所识别，但是却能在系统内核重组成一个完成的syn包来达到攻击目的。
关于源地址和端口号发生变化，这是一般dos工具都具备的，你可以参考网卡的RAW（混杂）工作模式。欣慰的是一般ISP的路由器都不允许不属于这个网段的IP包的通过。给我们查找攻击者带来方便，并从一定程度上阻碍了dos攻击
& 回复于： 13:10:29
引用：原帖由&"xichen"&发表：
那么可以在超过5秒还没有接收到后续的两个包的时候，可以发送RST（记不清楚是否是这个包了）包，来让被dos攻击的服务器认为客户端已经断开了连接，从而释放了这个连接。
RST没用的,应该FIN.
但这么做与SYN&COOKIE或者六次握手从效果上有什么本质区别呢?况且你还得要求交换机有SPAN口以及增加新设备.
引用：原帖由&"xichen"&发表：
还有，现在高手门已经通过将一个syn包分解为多个IP包的方式来穿越防火墙，这个包不会被普通防火墙所识别，但是却能在系统内核重组成一个完成的syn包来达到攻击目的。
这个方法也早就过时了,现在Linux防火墙能搞定这种攻击,不知FreeBSD\行否.
引用：原帖由&"xichen"&发表：
关于源地址和端口号发生变化，这是一般dos工具都具备的，你可以参考网卡的RAW（混杂）工作模式。欣慰的是一般ISP的路由器都不允许不属于这个网段的IP包的通过。给我们查找攻击者带来方便，并从一定程度上阻碍了dos攻击
网卡的混杂模式是作用于接收报文的时候,与发送无关.&而RAW是TCP/IP套接字的一种工作模式,与网卡无关.路由器也不能得知一个数据包里面的传输层会话在端系统上究竟是什么方式打开的.
我没有别的意思,只是想说TCP半连接洪水是没有办法的,不要再误导初学者了,凡声称在不修改TCP的情况下解决了SYN&FLOOD问题的软/硬件厂家都是骗子,跟大街上的一针根治牛皮癣广告一样.很多人片面强调DoS与DDoS的差异,其实二者技术本质没有差异!你提到的那些方法,都可以有针对性地进行反制.
& 回复于： 13:20:06
如果这样，网络中的服务不就没有任何安全可言了吗，想让谁OVER谁就OVER
& 回复于： 13:30:10
我想楼上的大哥说的有点问题，sco,&m$,&apple&是被DDoS攻击了吧？DoS还是有办法的吧？
& 回复于： 13:38:30
DOS有办法，DDOS没办法
我就是想知道DOS的解决办法，但现在有点搞不清DOS和DDOS的区别了……
& 回复于： 13:44:33
这个是没有办法彻底的防止的，这本身就是TCP协议的设计“缺陷”，只能通过变通的方法来提高系统抵御半开连接的能力。
& 回复于： 14:40:54
JohnBull可能有点误解我的意思了，RAW工作模式是我在描述如何用编程方法来实现假冒IP和端口。
路由器因为禁止了非本网段IP地址的通过，一个是容易查出攻击者，一个是使产生的syn包的数量减少了。
& 回复于： 15:18:13
其实，这就是利用了tcp/ip协议的漏洞，JohnBull兄说的没错。
purge的想法的确比较天真，在现有的条件下最好的办法也就是那么几种，
purge曾看到说甚至临时换ip，把web服务临时转到新的ip上去。
& 回复于： 17:05:24
最近正在学习此类东西，帮忙顶一下吧。
不过，我觉得SYN&Flood还是比较难防范的。
我测试过一个我自己的程序，我伪造SYN数据包发送到某个地址，均能接收到ACK回复。似乎这个问题，比较头痛的问题。。。。
& 回复于： 17:17:44
感觉这个问题很好，让我也学了不少东西。大家继续，我搬个凳子来学习……&:em02:
& 回复于： 18:21:08
连Whitehouse碰到这种情况也只能启动最高安全方案，拔网线。。。。。
& 回复于： 18:26:41
引用：原帖由&"fushuyong"]连Whitehouse碰到这种情况也只能启动最高安全方案，拔网线。。。。。&发表：
真的假的？
& 回复于： 11:39:09
引用：原帖由&"fushuyong"]连Whitehouse碰到这种情况也只能启动最高安全方案，拔网线。。。。。&发表：
& 回复于： 15:35:31
我想请教一下，我是学校的网管，看到各位前辈在此讨论不禁试了一下，下载了一个HGOD的软件，按照说明仅简单的一试服务器就不能响应服务了，如此这样，学生搞恶作具的心理更强，我乞不要哭死。
& 回复于： 17:39:43
hgod的攻击能力比较强，而且他对自己机器的cpu消耗率比较底。
& 回复于： 22:28:24
这本来就是TCP/IP协议设计上的缺陷，正如上面一个人说的，现在真的是想让哪个网站over，哪个就要over。只是看人的数量。不过绿盟的黑洞也确实很不错，原因就是修改了TCP/IP协议上的处理，优化的其中的算法。但如果不这么做，以一般的TCP/IP协议是绝对不可能防止syn_flood的。而且synflood越来越先进，以前还只是真实的IP在synflood，后来发展到假冒IP，然后到现在的随机IP，也就是所有syn_flood的连接没有一个重复的，而且全是假的，真可谓的“科技进步”。所以以前的那些防止synflood攻击的手法全都失效。唯一能解决的或许就是修改TCP/IP。但不知道状态检测到底如何，假如建立一个连接一般都是在那一瞬间，而防火墙就直接检查每个TCP/IP连接的状态，如果发现连接过程不完整就立刻阻断。
& 回复于： 12:01:06
不说别的我用的hgod就是用假ip攻击的，用netstate&-an&查看500多条假的，如果是恶意攻击，你可能无从查起，没办法!!!!
& 回复于： 12:15:23
我就晕～！
如此说来，sina、163、sohu等门户网站都可以在瞬间就完蛋？
& 回复于： 20:24:07
引用：原帖由&"platinum"&发表：我就晕～！
如此说来，sina、163、sohu等门户网站都可以在瞬间就完蛋？
9494！帮你顶吧！
& 回复于： 09:40:25
& 回复于： 10:32:12
这些大型网站，方法syn-flood应该还是有一套的，假如在一下收到十多条syn，而第三次握手没收到ack的话，你就被断了...
建议看看这里：
http://blog.csdn.net/lalphbet/archive//226298.aspx
& 回复于： 10:37:36
引用：原帖由&"platinum"&发表：我就晕～！
如此说来，sina、163、sohu等门户网站都可以在瞬间就完蛋？
这要看攻击者有多大的能力调动足够的带宽去攻击
以三大门户的现有带宽以及他们和上级ISP的关系
一次持续的攻击有可能被抓到
短暂的攻击也没什么意义
因此普通攻击者也不会贸然犯险
& 回复于： 14:56:55
正是，我记得上次白宫那档子事最后好象是通过更换IP来解决的？
& 回复于： 23:10:53
DOS是一种利用单机的攻击方式，而DDos（分布式拒绝服务）是一种基于DOS的特殊形式的拒绝服务攻击，和DOS比就是一个是多点，一个是单点
预防为主&&保证安全
1定期扫描：（安全漏洞）
2在骨干节点配置放火墙，防火墙本身能抵御DDOS攻击和其他一些攻击，在发现受攻击的时候，可以将攻击导向其他一些牺牲主机，保证真正的主机不受瘫痪
3用足够的机器承受黑客攻击，因为黑客在攻击你的同时，自己的能量也在逐渐消失，想想为什么GOOGLE&MICROSOFT&SINA为什么WEB都有集群结构或分布式DNS
4过滤不必要的服务和端口（一个原则是满足最基本需要）
5检查访问者的来源，可以把那个IP段或域禁止
6应该过滤所有私网地址&192.168.0.&&&&10.&&&&&172.16.
7限制SYN/ICMP流量&最好把PING关掉
& 回复于： 23:12:04
对了&忘了告诉各位一件事情&
安全问题是&ing形式&&不是ed形式
bestregard
& 回复于： 14:22:33
总的来说小型的服务器和网站还是没什么办法抵御的，只能做一些杯水车薪的事
& 回复于： 19:42:33
继续讨论，今天在也下载了DOS的软件，模拟了一下，攻击一开始PC上的LINUX马上就不响应了，攻击终止后服务器就恢复正常（系统和APACHE并没有死掉）
& 回复于： 20:34:45
引用：原帖由&llzqq&于&&19:42&发表
继续讨论，今天在也下载了DOS的软件，模拟了一下，攻击一开始PC上的LINUX马上就不响应了，攻击终止后服务器就恢复正常（系统和APACHE并没有死掉）&
是否开启了&syncookie&功能？
& 回复于： 23:01:20
这个问题比较好,也是比较古老的问题,大家高见,请继续!
由于没有实际经验,不作评论.
& 回复于： 12:34:50
其实目前用中间件来代替服务器，进行三次握手，可以达到很好的防DoS攻击的效果（syn&flooding），我说的是很好。所以现在我们都不关心Syn&Flooding了，新的CC又是头大的问题。
本来想自己写一个防Syn&flooding，但是不知道中间件应该如何来维护会话状态，想问老大要几句代码，他又让偶看Syn&cookies的实现代码，正在看当中……
& 回复于： 13:40:09
引用：原帖由&platinum&于&&20:34&发表
是否开启了&syncookie&功能？&
& 回复于： 14:28:57
不开更完蛋。。。。
开了会好点，但是防御效果也不怎么样
& 回复于： 20:13:30
100M局域网试验的，可能是发包速度太快了，服务器网卡来不急处理了
& 回复于： 20:46:03
有这个可能！
& 回复于： 07:01:06
看来DOS，DDOS对系统本身来说无能为力了。
& 回复于： 08:08:01
DoS/DDoS&攻击有两种途径
1、通过&TCP/IP&的半连接漏洞进行服务器性能消耗的攻击
2、通过大量发包强行占用网络带宽来实现拒绝服务
对于第一点是可以防的，但传统的系统做不到，需要修改&TCP/IP&协议栈的核心代码
& 回复于： 09:09:42
http://bbs.chinaunix.net/viewthread.php?tid=23116&extra=page%3D1
觉得这样解释原理
& 回复于： 09:26:49
/sbin/sysctl&-w&net.ipv4.conf.all.accept_source_route=0
/sbin/sysctl&-w&net.ipv4.conf.all.forwarding=0
/sbin/sysctl&-w&net.ipv4.conf.all.mc_forwarding=0
不知道这样有没有效果?
& 回复于： 13:28:26
占带宽是没有办法的，可是如果是半连接的syn&flooding，虽然是协议的弱点，也是可以防范的：
A（攻击者）-&B(中间件)-&C(服务器)
第一步：a-&c&:syn
第二步：b代替c回一个:ack/syn(这个时候，虽然是攻击包，可是服务器没有收到，所以并没有被攻击)
第三步：若收不到A的ack，则是一个攻击，不管它。若回来ack，则是一个非syn&flooking，这个时候：
1、对A来讲，三次握手已完成了；
2、对C来讲，还没有进行过连接呢；
所以：
1、B将ack改为syn给服务器C；服务器回一个syn/ack，B再回一个ack；OK，这样，A与C的三次握手完成了；
2、A的数据过来了，B将其直接交给C……
我没有代码，不知B如何来维护这个连接状态而使得B不会因此而被DoS……不过原理肯定是没有问题的
& 回复于： 13:41:27
第二步：b代替c回一个:ack/syn(这个时候，虽然是攻击包，可是服务器没有收到，所以并没有被攻击)
这样的话，a&还是收不到&b&的&syn/ack，b&自己会不会也&down&掉？
& 回复于： 14:02:04
引用：原帖由&platinum&于&&13:41&发表
第二步：b代替c回一个:ack/syn(这个时候，虽然是攻击包，可是服务器没有收到，所以并没有被攻击)
这样的话，a&还是收不到&b&的&syn/ack，b&自己会不会也&down&掉？&
应该是，“这样的话，B代替C回给A一个ack/syn，如果a没有第三次ack，B收不到，B自己会不会down掉吧？”
我最先想写这样程序，也是遇到这样的问题，也就是说，“B如何来维护一个连接状态”，就去问偶老大（因为他做出来了一个，原理也是他告诉偶的，而且在许许多多的实际环境中测试效果非常好），可惜他告诉我“还是先去看看linux&下syn&cookie的实现吧”……于是我这两天正在啃当中，希望元旦节之前能搞定它。
& 回复于： 14:08:50
恩，我就是想问这个&^_^
syncookie&的简单介绍我看过，不过还没看过代码
不知道上面这个思路和&syncookie&有什么根源上的区别没有？syncookie&其实也是这个原理（至少是类似）
& 回复于： 14:15:24
引用：原帖由&platinum&于&&14:08&发表
恩，我就是想问这个&^_^
syncookie&的简单介绍我看过，不过还没看过代码
不知道上面这个思路和&syncookie&有什么根源上的区别没有？syncookie&其实也是这个原理（至少是类似）&
现在对syncookie了解还比较少，也只看过些简介，不过和这个原理还是有点区别的。而且syncookie防御syn&flooding效果不太好。
我说的这种原理，市面上已经有很多成型的产品的，不过效果有好有坏，不知道性能是否就是取决于我的那个疑问，可恨没有代码呀……
ps:现在的CC攻击，是要完成三次握手的，这种方法是防御不了的。可以用同IP并发限制，只是这种方法，某些游戏网站，同一网吧或单位出来的连接太多，也是不太现实，于是只有拆应用层包，分析特征码了。哎，上帝要是赐给我一块超性能的板子就好了……
& 回复于： 15:26:21
对于&syn-proxy&的原理，确实需要多看一些资料，找一些代码看才知道
对于&CC&那样的合理性应用层攻击，恐怕只能深度拆包了，据说&NP&芯片有支持七层的，具体能支持到什么地步还不清楚
& 回复于： 18:11:57
试了X86，小规模应用还可以，可是流量一起来就……哎……
& 回复于： 18:12:40
能说说怎么实现的吗？
& 回复于： 07:32:22
昨天研究了一下（为此还装了一台openbsd-3.8）pf防火墙是怎样对付syn&flooding的，实现语句如下：
pass&in&proto&tcp&from&any&to&port&80&flags&S/SA&synproxy&state
我在100M局域网试验了一下，发现效果很不错，apache没有受到直接攻击，pf把syn&包截住了。
原理就像“独孤九贱”所说的，看来PF是个不错的防火墙。顺便说一句，单纯靠限制IP并发连接数对付SYN攻击没有任何效果，因为SYN包不能建立一个完整的连接状态（3次握手），而通常意义上IP并发连接是指完整的连接状态[&本帖最后由&llzqq&于&&07:37&编辑&]
& 回复于： 09:37:18
引用：原帖由&llzqq&于&&07:32&发表
我在100M局域网试验了一下，发现效果很不错，apache没有受到直接攻击，pf把syn&包截住了。
意思是服务器没有死机，没有出现高负载？
那服务还仍然能继续向别人提供吗？别人的&syn&还进的来吗？
& 回复于： 10:55:30
引用：原帖由&llzqq&于&&07:32&发表
昨天研究了一下（为此还装了一台openbsd-3.8）pf防火墙是怎样对付syn&flooding的，实现语句如下：
pass&in&proto&tcp&from&any&to&port&80&flags&S/SA&synproxy&state
我在100M局域网试验了一下，发现效&...&
用FREEBSD6.0&&PF虽然保护了服务器，但别的请求也进不来，而且速度非常慢，不知是不是兼容性的原因。
& 回复于： 20:28:14
又是讨论synflood，呵呵，搀一脚
确实现在的情况是想让谁死谁就得死，不过也不是全无办法，常用的办法前面几位也都谈到了，我说一下没谈到的。
synflood原理就是通过发送大量syn包给服务器导致服务器的半连接超出系统限制而达到拒绝服务的目的。
synflood本身也有区别，最原始的synflood都是使用攻击机器自身的ip进行攻击，所以从被攻击机器上看到有ip直接发送大量的包过来，直接封掉就能搞定攻击。但是改进以后的synflood可以通过raw&socket构建自身的syyn包发送，包头信息的大部分字段都可以伪造甚至全随机，例如随机源ip，这样发送给目标机器的结果就是目标机器看到有无数ip地址在向自己发送syn请求。这造成了一种分布式攻击（ddos）的假象，实际上可能攻击的机器就那一台（dos），当然多台机器同时synflood达到真正意义的ddos也是绝对可行的，并且威力更大。
防御的方法就目前来说，最有效的还是synproxy的机制，也就是用防火墙代理实现syn连接，具体后述。
我在这里首先要单独拿出来说的是一些特殊案例，实际上这些案例也非常常见。
前面讲通过raw&socket构建的包头可以绝大多数字段都可以自定义，实际上，除了目标ip和目标端口以外的所有tcp/ip包头字段都是可以按照自己要求订制的，但是目前现有的一些常用synflood工具并不一定都随机填充这些字段，可能是作者偷懒，也可能是为了节省cpu计算时间用来更快的产生syn包。例如前面有人提到的hgod这个东东，他就有一个非常显著的特征：ipid=256。按照tcp/ip实现，这个ipid字段应该是随机的，所以，我们就可以明显地把hgod发出的包与正常访问产生的包区分开，linux的iptables，freebsd的ipfw都可以针对ipid进行拒绝。这时我们就可以通过简单的退避手段（牺牲ipid=256的正常包）来保证绝大多数应用的正常。
不仅是hgod，还有很多知名工具或多或少的在发送的syn包中带有一定的特征，根据这些特征过滤掉攻击包，就能保证正常服务的运行，这种方法虽然有局限，但优点为没有任何状态检测机制，简单高效，基本上就是线路能承受多少流量就能防止多少流量的攻击，所以还是有其应用价值的。其实似乎现在国内也存在这种利用特征过滤原理的抗ddos产品，具体我就不多说了，有兴趣的自己tcpdump看看能不能找到攻击包特征。
另外值得讨论的就是synproxy/syncookie了，这也是目前证明比较有效的解决方法了，至于产品，绿盟就是最好的实现。
首先讲syncookie，这个可能不少人测试过了，原理现在网上的剖析文章也很多了，自己找，就不多说了，这种方法在攻击流量不大的情况下还是有非常不错的效果的，不过攻击流量一旦稍大，据我的经验，大于10Mbps的synflood，就基本上不起作用了，原因是syncookie的半连接队列也被充满了，这时可以通过调大队列长度的方法解决，参考net.ipv4.tcp_max_syn_backlog这个sysctl变量，默认1024，上限能调到多少我不知道，但是据我的经验，最好不要大于8192，再大的结果就是syncookie本身处理就会把你的cpu资源跑光，一样ddos了。按照我的应用体验来看，好的硬件+好网卡+调优的网络参数+syncookie能在20Mbps的synflood下保证服务正常，如果谁能达到更强的攻击容纳能力请指教一下。
再说synproxy，这个能免费用的也就是pf上的那个了吧，不过pf的synproxy实现不能算好，其算法写的并不足够优化，主要弱点就是在连接状态检测这里，大量虚假ip的syn包会导致大量state产生，大量state的添加、查找、删除足以把pf拖垮，所以效果也不怎么样，按我的经验在30Mbps下基本也就挂了。
pf的synproxy不行并不代表synproxy这种实现思路不行，只要算法足够优化，synproxy的效率还是可以达到令人满意的效果的，目前对算法的改进基本在接受到syn包这个地方，并不用象pf的实现那样接受到syn包就建立状态，可以直接返回synack，并丢弃syn包，在受到正常的第3次握手synack包后建立状态机制，这样就能大大增大此算法的效率，当然细节方面肯定还有一些考虑，目前市场上的抗ddos产品应该在算法上都有独到之处，处理好了之后的设备能足以防到100Mbps以上的synflood，上1000M级别的设备估计就是硬件能力的比拼了，目前我还没接触到，也就无权评论了。
总之思路就这么多，好的方法基本也就这些，想从iptables限制syn速率，甚至拿出apache的ddos模块来的做法就有点头痛医脚了，说的不对的地方，请指正。
& 回复于： 13:36:01
SYN&Flood攻击给互联网造成重大影响后，针对如何防御SYN&Flood攻击出现了几种比较有效的技术。
2.1&&&SYN－cookie技术
　　一般情况下，当服务器收到一个TCP&SYN报文后，马上为该连接请求分配缓冲区，然后返回一个SYN＋ACK报文，这时形成一个半连接。SYN&Flood正是利用了这一点，发送大量的伪造源地址的SYN连接请求，而不完成连接。这样就大量的消耗的服务器的资源。
　　SYN－cookie技术针对标准TCP连接建立过程资源分配上的这一缺陷，改变了资源分配的策略。当服务器收到一个SYN报文后，不立即分配缓冲区，而是利用连接的信息生成一个cookie，并将这个cookie作为将要返回的SYN＋ACK报文的初始序列号。当客户端返回一个ACK报文时，根据包头信息计算cookie，与返回的确认序列号（初始的序列号＋1）的前24位进行对比，如果相同，则是一个正常连接，然后，分配资源，建立连接。
　　该技术的巧妙之点在于避免了在连接信息未完全到达前进行资源分配，使SYN&Flood攻击的资源消耗失效。实现的关键之处在于cookie的计算。cookie的计算应该做到包含本次连接的状态信息，使攻击者不能伪造cookie。cookie的计算过程如下：
　　1）服务器收到一个SYN包后，计算一个消息摘要mac：
mac&=&MAC（A，k）；
MAC是密码学中的一个消息认证码函数，也就是满足某种安全性质的带密钥的hash函数，它能够提供cookie计算中需要的安全性。
A为客户和服务器双方的IP地址和端口号以及参数t的串联组合：
A&=&SOURCE_IP&||&SOURCE_PORT&||&DST_IP&||&DST_PORT&||&t
K为服务器独有的密钥；
时间参数t为32比特长的时间计数器，每64秒加1；
　　2）生成cookie：
cookie&=&mac（0:24）：表示取mac值的第0到24比特位；
　　3）设置将要返回的SYN+ACK报文的初始序列号，设置过程如下：
&&&&i.&&&&&&&&&&&&&&高24位用cookie代替；
&&&ii.&&&&&&&&&&&&&&接下来的3比特位用客户要求的最大报文长度MMS代替；
&&&iii.&&&&&&&&&&&&&&最后5比特位为t&mod&32。
　　客户端收到来自服务器SYN+ACK报文后，返回一个ACK报文，这个ACK报文将带一个cookie（确认号为服务器发送过来的SYN&ACK报文的初始序列号加1，所以不影响高24位），在服务器端重新计算cookie，与确认号的前24位比较，如果相同，则说明未被修改，连接合法，然后，服务器完成连接的建立过程。
　　SYN-cookie技术由于在连接建立过程中不需要在服务器端保存任何信息，实现了无状态的三次握手，从而有效的防御了SYN&Flood攻击。但是该方法也存在一些弱点。由于cookie的计算只涉及了包头的部分信心，在连接建立过程中不在服务器端保存任何信息，所以失去了协议的许多功能，比如，超时重传。此外，由于计算cookie有一定的运算量，增加了连接建立的延迟时间，因此，SYN-cookie技术不能作为高性能服务器的防御手段。通常采用动态资源分配机制，当分配了一定的资源后再采用cookie技术，Linux就是这样实现的。还有一个问题是，当我们避免了SYN&Flood攻击的同时，同时也提供了另一种拒绝服务攻击方式，攻击者发送大量的ACK报文，使服务器忙于计算验证。尽管如此，在预防SYN&Flood攻击方面，SYN-cookie技术仍然是一种有效的技术。
2.2&&地址状态监控的解决方法
　　地址状态监控的解决方法是利用监控工具对网络中的有关TCP连接的数据包进行监控，并对监听到的数据包进行处理。处理的主要依据是连接请求的源地址。
每个源地址都有一个状态与之对应，总共有四种状态：
初态：任何源地址刚开始的状态；
NEW状态：第一次出现或出现多次也不能断定存在的源地址的状态；
GOOD状态：断定存在的源地址所处的状态；
BAD状态：源地址不存在或不可达时所处的状态。
具体的动作和状态转换根据TCP头中的位码值决定：
　　1）监听到SYN包，如果源地址是第一次出现，则置该源地址的状态为NEW状态；如果是NEW状态或BAD状态；则将该包的RST位置1然后重新发出去，如果是GOOD状态不作任何处理。
　　2）监听到ACK或RST包，如果源地址的状态为NEW状态，则转为GOOD状态；如果是GOOD状态则不变；如果是BAD状态则转为NEW状态；如果是BAD状态则转为NEW状态。
　　3）监听到从服务器来的SYN&ACK报文（目的地址为addr），表明服务器已经为从addr发来的连接请求建立了一个半连接，为防止建立的半连接过多，向服务器发送一个ACK包，建立连接，同时，开始计时，如果超时，还未收到ACK报文，证明addr不可达，如果此时addr的状态为GOOD则转为NEW状态；如果addr的状态为NEW状态则转为BAD状态；如果为addr的状态为BAD状态则不变。
状态的转换图如图3所示：
body.clientHeight)this.width=body.clientHeight"&border=0&
初态&
GOOD&
NEW&
BAD&
ACK/RST&
SYN&
ACK/RST
&&
ACK包确认超时&
ACK/RST
&&
ACK包确认超时
下面分析一下基于地址状态监控的方法如何能够防御SYN&Flood攻击。&
　　1）对于一个伪造源地址的SYN报文，若源地址第一次出现，则源地址的状态为NEW状态，当监听到服务器的SYN+ACK报文，表明服务器已经为该源地址的连接请求建立了半连接。此时，监控程序代源地址发送一个ACK报文完成连接。这样，半连接队列中的半连接数不是很多。计时器开始计时，由于源地址是伪造的，所以不会收到ACK报文，超时后，监控程序发送RST数据包，服务器释放该连接，该源地址的状态转为BAD状态。之后，对于每一个来自该源地址的SYN报文，监控程序都会主动发送一个RST报文。
　　2）对于一个合法的SYN报文，若源地址第一次出现，则源地址的状态为NEW状态，服务器响应请求，发送SYN＋ACK报文，监控程序发送ACK报文，连接建立完毕。之后，来自客户端的ACK很快会到达，该源地址的状态转为GOOD状态。服务器可以很好的处理重复到达的ACK包。
从以上分析可以看出，基于监控的方法可以很好的防御SYN&Flood攻击，而不影响正常用户的连接。
　　3&&&小结
　　本文介绍了SYN&Flood攻击的基本原理，然后详细描述了两种比较有效和方便实施的防御方法：SYN-cookie技术和基于监控的源地址状态技术。SYN-cookie技术实现了无状态的握手，避免了SYN&Flood的资源消耗。基于监控的源地址状态技术能够对每一个连接服务器的IP地址的状态进行监控，主动采取措施避免SYN&Flood攻击的影响。这两种技术是目前所有的防御SYN&Flood攻击的最为成熟和可行的技术。
& 回复于： 21:03:57
主要是办连接队列没有满，满了就会使用cookies，&netfilter得状态检测机制和半廉洁队列还是算法不够优化！
& 回复于： 10:42:22
我想可不可以在syn&cookie前置一个对syn包速率监视器啊，当进入的syn包的速率达到一个阀值时才真正启动这个syncookies代理，否则就按常规的状态检测流程进行包的过滤。这个好像和绿盟的黑洞的思路很类似。呵呵，我也是昨天才看有关这个内容的，一点愚见不要见笑。
& 回复于： 10:58:33
这样的话，当可能发生拒绝服务攻击了才启用代理，毕竟一般被攻击的时候也不多嘛，在syn包到达速率在容忍范围内进行正常的检测，这样应该可以保证正常情况下免除代理带来的时间资源的消耗了。
& 回复于： 21:56:51
& 回复于： 00:39:45
:em11:[&本帖最后由&skipjack&于&&01:05&编辑&]
& 回复于： 01:28:25
引用：原帖由&platinum&于&&15:52&发表
这个问题我也想到了
但是，一个单位的同事们会同时有20个人以上来访问吗？
何况HTTP协议不是一直ESTABLISHED的，读完网页就CLOSE
如果同一个IP有20个以上的ESTABLISHED，那肯定不正常
对吧：）&
好像不成立&一个大网络若干个节点&把主页都设置为google或公司自己的竹叶&N多人同时开启IE&就把google给屏啦
& 回复于： 18:47:45
用硬件防火墙也许可以最大能量得抵挡DDOS攻击了，
听说用硬件防火墙要建立四次握手哦，，我也不是很明白，
是我原来公司的网络工程师说的，
结果我原来公司的那些硬件防火墙，可以抵挡30万包以上的DDOS攻击```
& 回复于： 00:33:11
引用：原帖由&JohnBull&于&&13:10&发表
RST没用的,应该FIN.
但这么做与SYN&COOKIE或者六次握手从效果上有什么本质区别呢?况且你还得要求交换机有SPAN口以及增加新设备.
这个方法也早就过时了,现在Linux防火墙能搞定这种攻击,不知FreeBSD\行否.
&...&
我赞同，我也认为DOS和DDOS本质是没什么区别的，
只是规模和范围的问题
& 回复于： 15:03:15
虽然说DOS和DDOS在本质上没什么区别，但是它们造成的后果却是不一样的。当量变累积到一定程度就会成为质变。可以解决DOS攻击的技术，在DDOS面前可能就会无能为力
& 回复于： 10:49:34
很早以前注意过这方面的anti-ddos&fw.
但是实际上修改了tcp&协议，增加&tcp握手的次数，或者作&syn-cookie&来防止fw后host被消耗掉不必要的资源。
单主机抵御ddos或者dos，前途不甚明朗吧
& 回复于： 15:59:26
顶一下&好像问题还没解决
& 回复于： 10:46:21
硬防来搞还是不错的1
& 回复于： 10:35:18
各位回答&的都很精彩&&&&:em11:
& 回复于： 11:02:32
&IfModule&mod_evasive20.c&
&&&&DOSHashTableSize&&&&3097
&&&&DOSPageCount&&&&&&&&2
&&&&DOSSiteCount&&&&&&&&50
&&&&DOSPageInterval&&&&&1
&&&&DOSSiteInterval&&&&&1
&&&&DOSBlockingPeriod&&&
&/IfModule&
我用这个挺管用的，甚至还防采集
& 回复于： 13:56:23
新版的iptables中的hashlimit和recent模块也能启到些作用，不过没有做过大强度的测试，大家有空可以试试。
原文链接：
转载请注明作者名及原文出处