Chinaunix首页 | 论坛 | 博客
  • 博客访问: 187990
  • 博文数量: 23
  • 博客积分: 1475
  • 博客等级: 上尉
  • 技术积分: 278
  • 用 户 组: 普通用户
  • 注册时间: 2006-09-23 16:18
文章分类

全部博文(23)

文章存档

2014年(8)

2012年(2)

2010年(3)

2009年(6)

2008年(4)

我的朋友

分类: LINUX

2014-04-15 23:47:35

近期遇到几例服务器被SYN攻击的问题,今天详细分析一下SYN flood攻击的原理

简单回顾一下TCP/IP三次握手的过程

1. Host A 发送一个TCP SYNchronize 包到 Host B
2. Host B 收到 Host A的SYN
3. Host B 发送一个 SYNchronize-ACKnowledgement
4. Host A 接收到Host B的 SYN-ACK
5. Host A 发送ACKnowledge
6. Host B 接收到ACK
7.TCP socket 连接建立ESTABLISHED.

SYN flood(SYN洪水攻击)
在三次握手过程中,Host B发送SYN-ACK之后,收到Host A的ACK之前的TCP连接称为半连接(half-open connect).此时Host B处于SYN_RECV状态.当收到ACK后,Host B转入ESTABLISHED状态.
SYN攻击就是攻击端Host A在短时间内伪造大量不存在的伪IP地址,向Host B不断地发送SYN包,Host B回复确认包,并等待Host A的确认,由于源地址是不存在的,Host B需要不断的重发包直 至超时,这些伪造的SYN包将长时间占用未连接队列,正常的SYN请求被丢弃,目标系统运行缓慢,严重者引起网络堵塞甚至系统瘫痪。
SYN flood攻击是一种典型的DDos攻击。检测SYN攻击非常的方便,当你在服务器上看到大量的半连接状态时,特别是源IP地址是随机的,基本上可以断定这是一次SYN攻击.
我们模拟一次攻击:

在Host A上执行攻击程序,伪装源IP成8.8.8.8(google DNS),目标地址192.168.39.131的80端口

在Host B上netstat -an | grep  SYN_RECV可以看到产生大量SYN_RECV状态的连接

此时Host B收到包后连接为SYN_RECV状态,根据TCP/IP协议应该发送SYN_ACK回复给Host A,在Host B上使用tcpdump -i eth0 'tcp [13] & 2 =2'抓取,发现存在大量SYN_ACK状态的连接,
可惜源ip为伪装的地址,所以会超时重传。此时如有正常请求Host B的80端口,它的SYN包就会被Host B丢弃,因为半连接队列已经满了(耗尽内存以及CPU资源),从而达到攻击目的。

Linux kernel也提供了Syncookies 等机制来防止syn攻击,以下是具体修改的内核参数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# default = 5
      
 net.ipv4.tcp_syn_retries = 3
 # default = 5
 net.ipv4.tcp_synack_retries = 3
 # default = 1024
 net.ipv4.tcp_max_syn_backlog = 65536
 # default = 124928
 net.core.wmem_max = 8388608
 # default = 131071
 net.core.rmem_max = 8388608
 # default = 128
 net.core.somaxconn = 512
 # default = 20480
 net.core.optmem_max = 81920
 # default = 1
 net.ipv4.tcp_syncookies = 0

其中net.ipv4.tcp_synack_retries, net.ipv4.tcp_syncookies,

阅读(739) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~