惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

酷 壳 – CoolShell
酷 壳 – CoolShell
H
Hacker News: Front Page
P
Palo Alto Networks Blog
T
ThreatConnect
Apple Machine Learning Research
Apple Machine Learning Research
博客园_首页
T
True Tiger Recordings
P
Privacy & Cybersecurity Law Blog
B
Blog
IT之家
IT之家
Last Week in AI
Last Week in AI
F
Full Disclosure
Hacker News: Ask HN
Hacker News: Ask HN
C
Comments on: Blog
Microsoft Azure Blog
Microsoft Azure Blog
C
Cybersecurity and Infrastructure Security Agency CISA
Microsoft Security Blog
Microsoft Security Blog
博客园 - 【当耐特】
N
News and Events Feed by Topic
NISL@THU
NISL@THU
腾讯CDC
雷峰网
雷峰网
Security Latest
Security Latest
李成银的技术随笔
M
Microsoft Research Blog - Microsoft Research
L
LangChain Blog
L
Lohrmann on Cybersecurity
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
C
Check Point Blog
Y
Y Combinator Blog
Recent Announcements
Recent Announcements
博客园 - Franky
N
News | PayPal Newsroom
V
V2EX
A
About on SuperTechFans
The Register - Security
The Register - Security
月光博客
月光博客
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Google Online Security Blog
Google Online Security Blog
MyScale Blog
MyScale Blog
Cisco Talos Blog
Cisco Talos Blog
Vercel News
Vercel News
WordPress大学
WordPress大学
C
Cyber Attacks, Cyber Crime and Cyber Security
The Hacker News
The Hacker News
IntelliJ IDEA : IntelliJ IDEA – the Leading IDE for Professional Development in Java and Kotlin | The JetBrains Blog
IntelliJ IDEA : IntelliJ IDEA – the Leading IDE for Professional Development in Java and Kotlin | The JetBrains Blog
爱范儿
爱范儿
A
Arctic Wolf
L
LINUX DO - 最新话题
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More

博客园 - wyi23

Web2.0特征列表(收藏的) RSS2.0说明 RSS 2.0规范 - wyi23 - 博客园 用XMLHttpRequest和struts实现AJAX(转) Gmail 使用的AJAX技术研究(转贴) AJAX框架汇总 Ajax 网址备忘 Ajax介绍(转载) .NET 試題 什么是Ajax 在Windows SharePoint Service平台上构建协作式应用 SPS/WSS资源 检查本机是否被黑客利用为DDOS攻击的工具(转载) SYN Flood攻击的基本原理及防御 黑客是如何组织一次DDoS攻击的(转载) 对PE文件中若干存储信息的一些理解(转载) 海盗的难题(转载) .NET建模 关于开发系统后门软件的几点思路
DDoS攻击实例 - SYN Flood攻击(转载)
wyi23 · 2005-05-04 · via 博客园 - wyi23

作者:徐一丁
SYN-Flood是目前最流行的DDoS攻击手段,早先的DoS的手段在向分布式这一阶段发展的时候也经历了浪里淘沙的过程。SYN-Flood的攻击效果最好,应该是众黑客不约而同选择它的原因吧。那么我们一起来看看SYN-Flood的详细情况。

Syn Flood原理 - 三次握手

     Syn Flood利用了TCP/IP协议的固有漏洞。面向连接的TCP三次握手是Syn Flood存在的基础。

TCP连接的三次握手

    如图二,在第一步中,客户端向服务端提出连接请求。这时TCP SYN标志置位。客户端告诉服务端序列号区域合法,需要检查。客户端在TCP报头的序列号区中插入自己的ISN。服务端收到该TCP分段后,在第二步以自己的ISN回应(SYN标志置位),同时确认收到客户端的第一个TCP分段(ACK标志置位)。在第三步中,客户端确认收到服务端的ISN(ACK标志置位)。到此为止建立完整的TCP连接,开始全双工模式的数据传输过程。

Syn Flood攻击者不会完成三次握手

    假设一个用户向服务器发送了SYN报文后突然死机或掉线,那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成),这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接,这段时间的长度我们称为SYN Timeout,一般来说这个时间是分钟的数量级(大约为30秒-2分钟);一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题,但如果有一个恶意的攻击者大量模拟这种情况,服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接,即使是简单的保存并遍历也会消耗非常多的CPU时间和内存,何况还要不断对这个列表中的IP进行SYN+ACK的重试。实际上如果服务器的TCP/IP栈不够强大,最后的结果往往是堆栈溢出崩溃---即使服务器端的系统足够强大,服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之小),此时从正常客户的角度看来,服务器失去响应,这种情况我们称做:服务器端受到了SYN Flood攻击(SYN洪水攻击)。

    下面是我在实验室中模拟的一次Syn Flood攻击的实际过程

    这一个局域网环境,只有一台攻击机(PIII667/128/mandrake),被攻击的是一台Solaris 8.0 (spark)的主机,网络设备是Cisco的百兆交换机。这是在攻击并未进行之前,在Solaris上进行snoop的记录,snoop与tcpdump等网络监听工具一样,也是一个很好的网络抓包与分析的工具。可以看到攻击之前,目标主机上接到的基本上都是一些普通的网络包。

…
…
           ? -> (broadcast)  ETHER Type=886F (Unknown), size = 1510 bytes
           ? -> (broadcast)  ETHER Type=886F (Unknown), size = 1510 bytes
           ? -> (multicast)  ETHER Type=0000 (LLC/802.3), size = 52 bytes
           ? -> (broadcast)  ETHER Type=886F (Unknown), size = 1510 bytes
192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]
192.168.0.210 -> 192.168.0.255 NBT Datagram Service Type=17 Source=ROOTDC[20]
192.168.0.247 -> 192.168.0.255 NBT Datagram Service Type=17 Source=TSC[0]
           ? -> (broadcast)  ETHER Type=886F (Unknown), size = 1510 bytes
192.168.0.200 -> (broadcast)  ARP C Who is 192.168.0.102, 192.168.0.102 ?
           ? -> (broadcast)  ETHER Type=886F (Unknown), size = 1510 bytes
           ? -> (broadcast)  ETHER Type=886F (Unknown), size = 1510 bytes
192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]
192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]
192.168.0.210 -> 192.168.0.255 NBT Datagram Service Type=17 Source=ROOTDC[20]
           ? -> (multicast)  ETHER Type=0000 (LLC/802.3), size = 52 bytes
           ? -> (broadcast)  ETHER Type=886F (Unknown), size = 1510 bytes
           ? -> (broadcast)  ETHER Type=886F (Unknown), size = 1510 bytes
…
…

    接着,攻击机开始发包,DDoS开始了…,突然间sun主机上的snoop窗口开始飞速地翻屏,显示出接到数量巨大的Syn请求。这时的屏幕就好象是时速300公里的列车上的一扇车窗。这是在Syn Flood攻击时的snoop输出结果:

…
…
 127.0.0.178 -> lab183.lab.net AUTH C port=1352 
 127.0.0.178 -> lab183.lab.net TCP D=114 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=115 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net UUCP-PATH C port=1352 
 127.0.0.178 -> lab183.lab.net TCP D=118 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net NNTP C port=1352 
 127.0.0.178 -> lab183.lab.net TCP D=121 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=122 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=124 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=125 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=126 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=128 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=130 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=131 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=133 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=135 S=1352 Syn Seq=674711609 Len=0 Win=65535
…
…

    这时候内容完全不同了,再也收不到刚才那些正常的网络包,只有DDoS包。大家注意一下,这里所有的Syn Flood攻击包的源地址都是伪造的,给追查工作带来很大困难。这时在被攻击主机上积累了多少Syn的半连接呢?我们用netstat来看一下:

    # netstat -an | grep SYN

…
…
192.168.0.183.9      127.0.0.79.1801          0      0 24656      0 SYN_RCVD
192.168.0.183.13     127.0.0.79.1801          0      0 24656      0 SYN_RCVD
192.168.0.183.19     127.0.0.79.1801          0      0 24656      0 SYN_RCVD
192.168.0.183.21     127.0.0.79.1801          0      0 24656      0 SYN_RCVD
192.168.0.183.22     127.0.0.79.1801          0      0 24656      0 SYN_RCVD
192.168.0.183.23     127.0.0.79.1801          0      0 24656      0 SYN_RCVD
192.168.0.183.25     127.0.0.79.1801          0      0 24656      0 SYN_RCVD
192.168.0.183.37     127.0.0.79.1801          0      0 24656      0 SYN_RCVD
192.168.0.183.53     127.0.0.79.1801          0      0 24656      0 SYN_RCVD
…
…

其中SYN_RCVD表示当前未完成的TCP SYN队列,统计一下:
# netstat -an | grep SYN | wc -l
5273
# netstat -an | grep SYN | wc -l
5154
# netstat -an | grep SYN | wc -l
5267
…..

    共有五千多个Syn的半连接存储在内存中。这时候被攻击机已经不能响应新的服务请求了,系统运行非常慢,也无法ping通。

    这是在攻击发起后仅仅70秒钟左右时的情况。(T101)