530.htm

unix高级编程原吗

   增加特定主机路由。 <br>
  <br>
   测试中还确认，目标MAC不能是0xffffffffffff，目标IP不能是定向广播地址，源 <br>
   MAC不被检查(任意)。 <br>
  <br>
   假如异己主机发送了一个ARP请求包或者响应包，包中源IP地址等于自己的IP地址， <br>
   那么两台之中必有一台错误配置了IP地址。Net/3侦测到这个错误并向管理员报告。 <br>
   注意，只有ARP报文(无论是请求还是响应)才会更新ARP Cache，才有可能引发ARP <br>
   冲突等等，所以在伪造ICMP包时无须过多顾虑源MAC。IP报文本身永远都不会造成 <br>

   事实上的ARP欺骗、冲突、刷新效果。 <br>
  <br>
   ARP Cache总会过期，不会因为总在使用Arp Entry而不过期。可以这样验证，在 <br>
   98下pint -t，然后用NetXray设置过滤规则抓取ARP请求报文，总是在固定间隔上 <br>
   看到本机发出的ARP请求报文。ICMP增加上来的路由过期时限很长，比ARP欺骗危 <br>
   害大。 <br>
  <br>
3) 下面是一个演示报文，伪造成从网关192.168.0.1发往192.168.10.60的ICMP重定 <br>
   向报文，使得后者产生一条到202.99.11.161的特定主机路由192.168.8.90。 <br>
  <br>
00 10 FF 69 FF FF 00 50 04 BF 07 34 08 00 45 00 <br>
00 3C 5B 6E 00 00 80 01 53 C5 C0 A8 00 01 C0 A8 <br>
0A 3C 05 01 AF 8A C0 A8 08 5A 45 00 63 64 65 66 <br>
00 68 FF 01 51 E1 C0 A8 0A 3C CA 63 0B A1 75 76 <br>
77 61 62 63 64 65 66 67 68 69 <br>
  <br>
   把上述报文存入 redir1060.txt 文件中，以 root 身份执行如下命令： <br>
   ./linuxkiller -k redir1060.txt -w 5 -r 1000 <br>
  <br>
   测试过程中看到，如果在192.168.10.60上route delete 0.0.0.0、 <br>
   route delete 202.99.11.161，则不受ICMP重定向包的影响，这个结论很正常， <br>
   前面我们提到过，重定向包必须来自去往目标的当前路由，如果根本就没有合适 <br>

   的当前路由，重定向报文会被认为非法而丢弃。 <br>
  <br>
4) 如果是98，可以用如下注册表设置打开路由功能，98单网卡就可以提供路由功能： <br>
  <br>
REGEDIT4 <br>
  <br>
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP] <br>
"EnableRouting"="1" <br>
  <br>
5) 由于再三提及的原因，无法利用ICMP重定向报文凭空产生特定主机路由。同时被 <br>
   更改的特定主机路由本身也会被ICMP重定向报文更改。启动98路由功能后， <br>
   192.168.8.90会向192.168.10.60发送ICMP重定向报文，修正后者直接使用 <br>
   192.168.0.1。注意，掩码规则优先于特定主机路由。 <br>
  <br>
   必须明确理解路由优先级的概念。如果只有缺省路由，ICMP会导致增加特定主机 <br>
   路由。如果已经存在特定主机路由，无论它是如何产生的，仅仅会被ICMP修改， <br>
   而不是增加。 <br>
  <br>
6) 目前的测试环境使用的是交换式HUB，拓扑结构大致如下： <br>
  <br>
          --------------------------------------  <-- Smart Hub Or Switch <br>
          |              |                     | <br>

   192.168.10.60  192.168.8.90  ......  192.168.0.1 (sygate) <--> Internet <br>
   255.255.0.0    255.255.0.0           255.255.0.0 <br>
  <br>
   下面观察这样做了之后发生什么事情。从192.168.10.60上 <br>
   telnet 202.99.11.161 80，此时192.168.8.90转发了这个报文，转发过程中修改 <br>
   源MAC地址成000000111111(192.168.8.90的MAC地址)，源IP保持192.168.10.60。 <br>
   192.168.8.90在转发第一个发起TCP连接的SYN报文的同时会向192.168.10.60发送 <br>
   ICMP重定向报文(掩码规则下192.168.0.1更优化)，使得特定主机路由成为 <br>
   192.168.0.1。于是后续的192.168.10.60到202.99.11.161的报文都直接经过 <br>
   192.168.0.1，但是回来的报文始终是经过192.168.8.90的。这个现象很有意思。 <br>
   在192.168.8.90和192.168.10.60上抓包观察到的现象始终都是出报文直接经 <br>
   192.168.0.1，入报文经192.168.8.90转发而至。袁哥和ipxodi认为是sygate本身 <br>
   实现的问题，比如sygate没有使用标准ARP Cache，自己保留了MAC-IP对之类的信 <br>
   息提高效率；换成正规路由器，应该不是这种现象。现在很多单位局域网的拓扑 <br>
   类似，估计sygate、wingate等支持透明代理功能的软件都存在这样的问题，说不 <br>
   上是漏洞还是被非法利用，总之应该意识到该问题的存在，反正以前我是没有料 <br>
   到这个现象的存在。 <br>
  <br>
   我和ipxodi刚开始讨论这个问题的时候认为只能抓到出报文(特定主机路由)，而 <br>
   入报文因为掩码规则直接投递了。没料到实际测试中，192.168.8.90本身会发送 <br>
   ICMP重定向报文。可以想个办法让192.168.8.90的ICMP重定向报文不能发送出去， <br>
   比如个人防火墙、象袁哥那样修改VxD等等。 <br>

  <br>
   先不考虑个人防火墙的介入，在我们这种拓扑下，ICMP重定向带来的入报文经 <br>
   192.168.8.90的问题很严重。想想看，192.168.10.60上很快就恢复了正常的路由 <br>
   规则，ARP Cache与这个问题无关，也不表现什么异常，唯一算得上异常的是 <br>
   192.168.10.60的路由表中虽然已经有缺省路由192.168.0.1，但还是出现了特定 <br>
   主机路由192.168.0.1。没看过这篇文章的朋友，有几个会想到可能是出事了呢？ <br>
   由于入报文经过192.168.8.90，在这里起一个NetXray，不用写ARP欺骗程序、 <br>
   "合法"利用ICMP重定向功能和98的IP路由功能，异常现象最小化等等。这里无法 <br>
   抓取出报文，于是无法监听到诸如telnet口令之类服务方不回显的数据，参看后 <br>
   面的讨论。上述描述适合于交换机情形，如果你对子网内每个IP用程序发送ICMP <br>
   重定向报文，并开启本机路由功能，要比ARP欺骗容易实现得多，也持久得多。考 <br>
   虑DNS服务器位于子网外的拓扑，至少可以看到谁企图解析什么域名，算不算侵犯 <br>
   隐私呢，sigh。强烈反对监听，可为什么总在给别人提供监听的可能，也许又是 <br>
   一次矛盾选择吧。 <br>
  <br>
   像ARP欺骗，一是容易暴露，二是需要高频率刷新，三是一般需要编程实现。而 <br>
   ICMP重定向不容易暴露(考虑sygate的"特性")，不需要高频率刷新，如果经常使 <br>
   用根本就不需二次刷新，用NetXray发送一次重定向报文即可。无论如何，ICMP重 <br>
   定向报文是潜在的安全隐患，现在倾向于不使用它。IDS系统应该高度敏感ICMP重 <br>
   定向报文的出现，在局域网内存在支持IP转发功能主机的情况下，可能会出现非 <br>
   攻击性的ICMP重定向报文，不能一味告警，需要区分。 <br>
  <br>
  <br>
7) 在介入个人防火墙的情况下，192.168.10.60和202.99.11.161之间就完全经过 <br>
   192.168.8.90通信，无论出入报文。需要注意，98不适合做路由功能，效率很低、 <br>
   负载很高，再启动一个NetXray的话更要命，尤其我这次测试时98使用的是单网卡。 <br>
   上述技术仅仅限于理论研究以及纯DoS攻击，真正要做监听不实际。还有，此时 <br>
   192.168.10.60上特定主机路由192.168.8.90显得很刺眼，容易暴露。 <br>
  <br>
   NetXray和ConSeal PC FIREWALL的启动顺序必须留心，建议如果要做协议分析， <br>
   无论如何都先启动NetXray，尤其当出现异常现象的时候关闭二者，按照建议顺序 <br>
   重启动。 <br>
  <br>
8) 迄今为止，都是用微软操作系统测试，并没有测试Linux/Solaris/FreeBSD，这些 <br>
   系统的测试留待我写个libnet程序来完成，总是手工构造ICMP重定向报文太累了。 <br>
   微软操作系统在没有个人防火墙介入的情况下如何屏蔽ICMP重定向报文，尚不清 <br>
   楚，谁知道了就贴一下(注册表？)。 <br>
  <br>
9) 因为前面测试是手工构造完整物理帧，所以才涉及到MAC地址，事实上ICMP重定向 <br>
   报文与MAC地址无关，与源IP有关，但raw_socket上可以伪造任意源IP，至于数据 <br>
   区就不在话下了。什么意思？ICMP重定向攻击可以跨路由进行，在广域网上进行。 <br>
   局域网内攻击不但可以DoS还可以sniffer，广域网上就只能DoS了(想想为什么)。 <br>
   还好，我这次被人抓住写的也就是DoS工具，不想那么多啦。 <br>
  <br>
   既然是DoS，最终目的是不让目标活得舒坦。象98，就可以设置指向自身的病态路 <br>

   由，其他系统，至少可以设置一个不存在的间接路由。通过大量增加垃圾特定主 <br>
   机路由消耗内存空间、延长路由搜索时间。某些实现不好的操作系统，还可能被 <br>
   某些特殊重定向报文冻僵住。这些都会在我写完libnet测试程序之后验证一二。 <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="531.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>