📄 534.htm
字号:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>CTerm非常精华下载</title>
</head>
<body bgcolor="#FFFFFF">
<table border="0" width="100%" cellspacing="0" cellpadding="0" height="577">
<tr><td width="32%" rowspan="3" height="123"><img src="DDl_back.jpg" width="300" height="129" alt="DDl_back.jpg"></td><td width="30%" background="DDl_back2.jpg" height="35"><p align="center"><a href="http://apue.dhs.org"><font face="黑体"><big><big>apue</big></big></font></a></td></tr>
<tr>
<td width="68%" background="DDl_back2.jpg" height="44"><big><big><font face="黑体"><p align="center"> ● UNIX网络编程 (BM: clown) </font></big></big></td></tr>
<tr>
<td width="68%" height="44" bgcolor="#000000"><font face="黑体"><big><big><p align="center"></big></big><a href="http://cterm.163.net"><img src="banner.gif" width="400" height="60" alt="banner.gif"border="0"></a></font></td>
</tr>
<tr><td width="100%" colspan="2" height="100" align="center" valign="top"><br><p align="center">[<a href="index.htm">回到开始</a>][<a href="519.htm">上一层</a>][<a href="535.htm">下一篇</a>]
<hr><p align="left"><small>发信人: scz (小四), 信区: Security <br>
标 题: libnet使用举例(9) <br>
发信站: 武汉白云黄鹤站 (Fri Aug 4 14:36:35 2000), 站内信件 <br>
<br>
日期：2000-08-03 23:08 <br>
<br>
今次以IGMP攻击为例继续介绍libnet库编程。IGMP补丁我没有用过，对于Pwin98来说， <br>
IGMP实在没有什么用途，可以考虑袁哥的这个办法： <br>
<br>
用ultraedit搜索6A 02 E8，修改成6A F2 E8。这里02对应IGMP协议，这样处理过后， <br>
F2才对应IGMP，所以呢，一般的针对标准IGMP协议的攻击就全部失效了，当然你也无 <br>
法正常使用IGMP协议。完全可以不用F2，换用其他值。 <br>
<br>
可能需要复习一点IP协议、IP分片的基础知识： <br>
<br>
1) tos应该只指定其中一个bit，同时指定几个是没有意义的。至于是不是允许的或 <br>
者说接收者如何处理这种报文依赖于具体实现，有可能出错。 <br>
2) IP分片和完整IP报文几乎拥有同样的IP头，id域对于每个分片都是一致的，这样 <br>
才能在重组的时候识别出来自同一IP报文的分片。flags占用了最高的3bit，按从 <br>
左到右表示从高到低，最左bit保留，应该置零，如果非零有什么后果不清楚；中 <br>
间bit置1表示不得对该IP报文分片，如果路由因为MTU缘故必须分片才能发送这种 <br>
不可分片IP报文的时候，就先废弃该IP报文然后用ICMP通知源主机废弃原因，如 <br>
果不是特殊需要不应该置1；最右bit置1表示该报文不是最后一个IP分片。 <br>
3) 完整单包IP报文的flags最右bit为零，同时fragment offset为零。第一个IP分片 <br>
的flags最右bit为1，同时fragment offset为零。最后一个IP分片的flags最右 <br>
bit为0，此时fragment offset必不为零。fragment offset与flags共用两个字节， <br>
前者占用了低13bit。fragment offset给出的偏移是相对完整IP报文数据区而言 <br>
的，以8bytes为单位。 <br>
4) 重组发生在最终目的主机上，中间路由不对分片重组。重组发生在所有分片到达 <br>
之后。一般最终目的主机在收到一个IP分片(不一定是第一个分片)的时候启动一 <br>
个定时器，如果超时而分片仍未到齐，则废弃具有相同id的所有已到达分片，意 <br>
味着丢失一个分片就丢失了完整IP报文，此时IP层本身不会负责重传，需要上层 <br>
协议自己意识到需要重传了。 <br>
<br>
可以想象，故意发送部分IP分片而不是全部，导致目标主机总是等待分片消耗占 <br>
用系统资源。某些分片风暴攻击就是这种原理。 <br>
<br>
5) IP分片的total_len给出的是这个IP分片的总长度，而不是完整IP报文总长度。 <br>
6) 使用UDP很容易导致IP分片，而很难强迫TCP发送一个需要进行分片的报文。 <br>
<br>
早期操作系统实现对IP分片的边界判断不够完善，总是存在这样那样的问题，经过近 <br>
年各种DoS攻击的研究、分析、对抗，已经日趋完善，很不容易找到关于分片边界处 <br>
理上的漏洞了。为什么要复习IP分片，下面介绍的一种IGMP攻击涉及到IP分片，不复 <br>
习一下，怕有些朋友看晕菜掉。 <br>
<br>
<br>
另外一个不太相关的问题，raw_socket可以发送IP分片，但是永远接收不到IP分片， <br>
内核在重组完成之前是不会给raw_socket一个IP分片的，记住这点很重要。可能有 <br>
些朋友看到利用raw_socket发送IP分片的源代码，而误以为IP分片对于收发 <br>
raw_socket都是可见的。 <br>
<br>
不打算重复IGMP的整个RFC，下面就IGMP协议的几个要点回顾一下： <br>
<br>
1) IGMP版本目前为1，类型只有两种，1表示组播路由器发出的查询，2表示组内主机 <br>
发出的响应。校验和是针对8字节的IGMP报文的。未用域必须清零。 <br>
2) 两个有效IGMP报文例子 <br>
<br>
IGMP响应(2) <br>
TTL = 1 <br>
所加入的组地址 <br>
目的IP = 组地址 <br>
源IP = 本机IP <br>
<br>
IGMP查询(1) <br>
TTL = 1 <br>
组地址 = 0 <br>
目的IP = 224.0.0.1 <br>
源IP = 组播路由器IP <br>
<br>
3) 主机上某个进程在本机某个接口上加入某个组时，如果前面没有本机其他进程加 <br>
入该组，则发送一个IGMP响应。本机会维护相关信息，直到所有本机进程退出该 <br>
组。 <br>
<br>
进程离开某个组时并不发送IGMP响应。当本机所有进程退出所有组后，如果有组 <br>
播路由器发送查询报文，本机不做IGMP响应。 <br>
<br>
组播路由器定时发送查询，这个查询报文的组地址固定为0，目标IP为224.0.0.1。 <br>
<br>
4) 224.0.0.0 - 239.255.255.255的D类地址属于组播地址。但是224.0.0.0不能用于 <br>
任何组。224.0.0.1表示局域网内所有拥有组播能力的主机、路由器，每个网络接 <br>
口初始化后如果拥有组播能力，会自动加入该组，即使没有本机进程明确加入该 <br>
组，不会因为加入该组而发送IGMP响应。组播地址可以作为目标IP出现，但不能 <br>
作为源IP出现。 <br>
<br>
224.0.0.0 - 224.0.0.255之间的组播地址如果出现在目标IP上，无论TTL多大， <br>
组播路由器也不会转发这种报文，这种报文只能出现在局域网内。显然这里包括 <br>
了224.0.0.1。 <br>
<br>
5) TTL为0的组播报文根本就无法出主机，为1表示组播报文只能在局域网内传送。如 <br>
果想被组播路由器转发出去，必须设置更大的TTL。 <br>
<br>
上述描述是W.Richard.Stevens对4.x BSD实现的描述，现在可能有变化。版本和类型 <br>
共用一个字节，版本占用高4bit，所以很多头文件里定义0x11、0x12这样的宏，至于 <br>
0x16、0x17，注释解释得比较清楚。 <br>
<br>
组内成员主机收到IGMP查询后，会在随机时间段内作出响应，因为组播导致组内其他 <br>
成员主机均收到响应，不仅仅是发出查询报文的主机，所以其余成员主机不再响应， <br>
避免了响应风暴。非组内成员主机可以发送查询报文，但它一定收不到相应的IGMP响 <br>
应。不是只有组播路由器才可以发送IGMP查询，其他IGMP查询报文的数据有所区别， <br>
比如目的IP不一定是224.0.0.1，可以是某个其他组播地址，组地址也不一定是0，可 <br>
以是某个确定的组地址。 <br>
<br>
libnet库中有如下函数原型： <br>
<br>
int libnet_build_igmp ( u_char type, u_char code, u_long ip, <br>
const u_char * payload, int payload_s, <br>
u_char * buf ); <br>
<br>
该函数用于构造IGMP报文，type取值在/usr/include/libnet/libnet-headers.h中有 <br>
如下宏定义： <br>
<br>
#define IGMP_MEMBERSHIP_QUERY 0x11 /* membership query */ <br>
#define IGMP_V1_MEMBERSHIP_REPORT 0x12 /* Ver. 1 membership report */ <br>
#define IGMP_V2_MEMBERSHIP_REPORT 0x16 /* Ver. 2 membership report */ <br>
#define IGMP_LEAVE_GROUP 0x17 /* Leave-group message */ <br>
<br>
这里0x17似乎意味着以后离开组需要发送IGMP报文通知大家，不清楚。0x16更让人迷 <br>
糊，既然是版本2的，就应该是0x26，不懂。反正我们不用它们，懒得深究。 <br>
<br>
形参code应该指定未用域的，那就只能是零了。形参ip指定D类组播地址，payload为 <br>
NULL，payload_s为零。形参buf需要指向一个已分配好的数据区，IGMP头从该指针开 <br>
始。 <br>
<br>
校验和计算套用libnet_do_checksum( packet, IPPROTO_IGMP, LIBNET_IGMP_H )函 <br>
数，当然，如果非正常IGMP报文，带了负载的话就需要调整参数值。 <br>
<br>
遗憾的是，此次攻击程序并没有真正利用上述函数，仅仅是IP头的部上层协议域指明 <br>
负载是IGMP报文。 <br>
<br>
下面将要介绍的这个IGMP攻击程序有很多地方异常： <br>
<br>
1) IP头部上层协议指明IP数据区出现IGMP报文，但是IP头部的目标地址不是组播地 <br>
址而是单播地址(也是被攻击的目标地址)，所以这样的报文能不能称做IGMP报文 <br>
值得推敲，是否作为IGMP报文被处理值得怀疑。 <br>
2) IGMP报文总共8字节，没有其他负载。但这个攻击程序有其他负载，并且负载很大， <br>
刻意制造了IP分片。攻击程序在发送IP分片的时候采用倒序，先发送最后一个分 <br>
片，最后发送第一个分片。这里采用raw_socket人为制造的异常分片，不是让IP <br>
协议栈自行分片，事实上在发送方始终没有出现过那个分片前的超大完整IP报文。 <br>
3) IGMP报文版本、类型、校验和、组地址全部为零，显然异常。 <br>
4) 如果以完整的一批IP分片为单位，原来的程序循环发送了两次。在测试过程感觉 <br>
还是依赖于发送速度和发送数量的，缺省使用两次，不是每次都攻击成功，这种 <br>
情况下重复攻击效果也不是很好。在程序中把循环次数调整成200，一次攻击就成 <br>
功，明显和攻击速度、报文数量有关。 <br>
<br>
源IP不要求等于目标IP，可以是任意伪造的源IP。目标IP地址并不是组播地址， <br>
对于只看到IP层的路由器来说，就是普通单播IP报文，并不会意识到正在路由一 <br>
个IGMP报文(如果这个报文能被称做IGMP报文的话)。以前有朋友说不能在广域网 <br>
上进行IGMP攻击，而又有一些朋友却说远程攻击奏效。据我这次分析，远程攻击 <br>
有些时候失效，并不是因为常规路由不转发组播报文，前面解释过了，路由看到 <br>
的是单播IP报文，而是因为分片丢失。这个攻击程序每次循环制造11个分片，远 <br>
程攻击不能保证11个分片都能按时到达目标IP进而重组。这样看来，还是重组后 <br>
巨大的异常IGMP报文带来麻烦。 <br>
<br>
总有朋友问这类DoS攻击原理何在，也总有朋友回答就是发送什么什么样的报文， <br>
感觉回答的只是表象，真正解释为什么蓝屏、为什么死机，需要用softice跟踪目 <br>
标主机对这种报文的处理过程。一个有效DoS报文本身说明不了问题，通过协议分 <br>
析软件抓取报文、通过阅读源代码分析报文都仅仅是搞清楚什么样的报文会导致 <br>
DoS，为什么这样的报文会导致DoS不是网络数据本身能给出答案的。前阵子那个 <br>
jot2.c，我只能知道那种类型的报文可能导致DoS，但为什么导致，不清楚，不分 <br>
析具体操作系统在这些协议处理上的实现，只看网络数据，能得到什么答案，隔 <br>
靴搔痒。不大喜欢别人用这种方式讨论这种问题，有夸夸其谈的嫌疑。也没有必 <br>
要过深了解这类DoS的真实原因，除非你有能力修改系统，象Linux那样能修理源 <br>
代码的另当别论。 <br>
<br>
这个攻击首先导致目标蓝屏，回车后IP栈基本废掉了，从远程无法ping通目标， <br>
需要重启动恢复。但没有导致死机，还可以做其他非网络工作。如果存在 <br>
softice，情况不大一样，我对此并不熟悉，不多描述。 <br>
<br>
个人觉得这个攻击完全可以远程进行，而且不要求源IP等于目标IP，机会很大。命令 <br>
行上指定伪造的源IP、攻击目标IP、IGMP报文数目(以一批分片为单位)。 <br>
<br>
<待续> <br>
<br>
-- <br>
<br>
<br>
也许有一天，他再从海上蓬蓬的雨点中升起， <br>
飞向西来，再形成一道江流，再冲倒两旁的石壁， <br>
再来寻夹岸的桃花。然而，我不敢说来生，也不敢信来生...... <br>
</small><hr>
<p align="center">[<a href="index.htm">回到开始</a>][<a href="519.htm">上一层</a>][<a href="535.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -