基于错误CRC的防火墙探测技术

==Phrack Inc.==

               Volume 0x0b, Issue 0x3c, Phile #0x0c of 0x10

|=----=[ Firewall spotting and networks analisys with a broken CRC ]=----=|
|=-----------------------------------------------------------------------=|
|=-----------------------------=[ Ed3f ]=--------------------------------=|
|=--------------=[ 翻译整理: TOo2y <TOo2y@safechina.net> ]=--------------=|

--[ 目录

  0 - 学习

  1 - 一些阻碍的东西

  2 - 技术分析

  3 - 你知道你是对的

  4 - 参考

--[ 0 - 学习
 
    包过滤防火墙的配置越来越让人感觉到“防火墙”这个词和非专业技术人员融洽相处的安全感。
我们可以看到在商业软件，嵌入式设备或开放源代码的操作系统中它们都是工作在第3级。然而对第4
级的支持却并不完全：它们过滤特定的端口号，TCP标记，SEQ序号，碎片，但是……

    第4级的校验和又如何呢？

    它们是否在分析标记或端口号之前核算TCP校验和呢？不！

    很多开发人员或许会认为这是多虑了，其他一部分则认为这些数据报会被目的操作系统的栈简单
的丢弃。的确这些都是对的，但是我们如何才能好好的利用这个“特性”呢？

    1) 防火墙返回探测数据报
    2) 破坏31337端口伪正经的探测
    3) 在网络中插入损坏的数据报

--[ 1 - 一些阻碍的东西

    一个完整的网络栈将会丢弃损坏的数据报，并不会返回任何信息。不管目标端口是关闭的，开放
的或任何情况……但是包过滤防火墙却没有如此的聪明，它们回对此做出回答。

    如果我们想确定在我们和目标主机之间是否有一个包过滤装置，首先我们必须判断这个包过滤装
置被配置为丢弃损坏了的数据报还是返回一个错误。在此我们发送一个有效的TCP数据报到一个应该
被过滤到的目标端口：

# telnet www.oracle.com 31337
Trying 148.87.9.44...
telnet: Unable to connect to remote host: Connection refused

    好的。目标主机自己或另一个包过滤装置返回了一个RST。下一步就是判断这个RST数据报是来自
目标主机或包过滤装置：

# hping -S -c 1 -p 31337 -b www.oracle.com
HPING www.oracle.com (rl0 148.87.9.44): S set, 40 headers + 0 data bytes
len=46 ip=148.87.9.44 flags=RA seq=0 ttl=23 id=52897 win=512 rtt=459.8 ms

    如果我们获得了一个应答报文，我们就知道有一个包过滤装置存在。如果我们没有得到一个应答
报文，那么猜想发送的那个数据报在到达目标主机前没有被过滤掉，而是被TCP栈丢弃了。

    另一种探测包过滤装置是否存在的技术是比较RST数据报和SYN数据报(直接来自目标主机)的生存
周期(TTL)。然而TTL技术在桥接网络中的所有包过滤装置中，或过滤装置没有递减TTL值而是直接在
目标主机前面被替换掉了时都会失败。前面描述过的CRC技术都可以在以上两种情况中用来探测包过滤
装置的存在。

    另外一个例子，我们使用UDP数据报：

# hping -2 -c 1 -p 53 -b www.redhat.com
HPING www.redhat.com (rl0 66.187.232.56): udp mode set, 28 headers + 0 data
ICMP Packet filtered from ip=63.146.1.74 name=UNKNOWN

    有一个区别数据报是来自目标主机或过滤装置的方法，我们可以利用操作系统指纹探测工具发送
防火墙数据报，不管目标主机或防火墙应答的数据报。试试 nmap -O。

    有兴趣吗？
    我为Nmap-3.1ALPHA4添加了两个新的扫描技术：
    -sZ BadTCP SYN秘密端口扫描
    -sV BadUDP 端口扫描

    注意-sZ选项来源于错误的-sS选项，而-sV则来自于-sU。BadTCP扫描使用FIN扫描引擎，因为
主机的默认行为是不会对此作出应答。BadUDP扫描则使用UDP扫描引擎因为主机的默认行为也是不会
做出应答。

    我希望Fyodor在将来的Nmap 4.00版本中能够许诺对目标端口当前状态的完整定义：

- 关闭
- 开放
- 端口被过滤掉了(没有应答)
- 存在防火墙(防火墙做出了应答)
  
    那么扫描记录如何对付这种新的扫描方式呢？它仍然认为这些是有效的数据报，所以它不会更改
配置选项以适应有效或无效的SYN数据报。

--[ 2 - 技术分析

    好了，那么像OpenBSD 3.2 这么好的系统中的包过滤装置是否会为每一个数据报计算校验和呢？
不，为了避免应答探测它们只需要核查那些需要做出应答的数据报的校验和。但是，应该引入一个发
现错误校验和的数据报并丢弃它的选项。

    一些工具给你提供了修改数据报为伪正经数据报的功能，像ettercat，并允许你的电脑将数据报
修改后直接发送到真实的目的主机。

    我们如何才能发现banner欺骗呢？

# echo "SSH-1.99" > /tmp/banner
# hping -S -c 1 -p 22 -E /tmp/banner -d 9 -b mybox

    如果你接收到一个SYN+ACK数据报，你就可以开始发誓……

    我们可以发现基于这种伪正经攻击的技术已经的到了发展。例如DSniff会核算TCP校验和，因为
它是工作在委托模式，但是ettercap使用的是非委托模式，所以它不需要核算校验和。

    那核算校验和是否是必须的呢？不，只有在你想要修改数据报或对接收到的数据报做出应答是才
需要这样做。因此如果你的程序只是简单的嗅探数据报，而不发送或修改它们那么你就会很安全。

    好的，如果你想安全的应答或修改数据报，那有没有什么解决办法呢？这儿有两种方法：

    1) 核算每个数据报的校验和，只有在正确的情况下才进行处理；修改或应答时使用有效的校验和。
    2) 为需要修改的数据报使用添加更新的网络校验和[RFC1411]；为你想要应答的数据报计算校验和。

    注意，添加的更新技术将会保持校验和的原样，以前是错的仍然是错的，以前是对的仍然是对的，
它比擦除后计算更快。

    好奇心：在数据报传输过程中它的校验和是无效的。因为它是基于最终目的主机IP地址的(在到达
目的地时，校验和才是正确的)。

    绝大多数入侵检测系统(IDS)会修改错误的校验和，但是它们不会记录这些数据报，因此管理员
就不能检查这些数据部分。

    另一种问题会在下面的情况中发生，如果网络地址翻译系统或装载平衡系统的代码是基于擦除的
校验和计算的。这时，如果入侵检测系统是在我们的主机与这种“无声”系统之间，那么就可以顺利
的通过它的检测。

    检查一种有趣的例子：

www.oracle.com:80
                       
Evil --[badSYN]--> Router --[badSYN]--> Load_Balancer --[SYN]--> WebServer
                |              |
                  NIDS1            NIDS2

    NIDS1会接收到一个TCP SYN无效校验和的数据报，如果它进行了相关配置，那么NIDS2就会接收
到一个修改过的有效的SYN数据报。因此WebServer就会给我们返回一个SYN+ACK的数据报，这样我们
就可以和WebServer进行通信了，但是却给NIDS1造成了很多的疑惑。如果你是安全管理员，在你发现
NIDS1和NIDS2的记录结果不相同时，你会怎么想呢？

    这种解决办法通常是添加的更新技术[RFC1411]。

--[ 3 - 你知道你是对的

awgn (31337 H4X0R)
raptor & nobody (LSD project)
batmaNAGA & ALORobin (ettercap authors)
JWK (OpenBSD addicted)
Daniel Hartmeier (Mr.Infinite Patience; OpenBSD PF main coder)
antirez (Hping author)
Fyodor (Nmap author)
Ed3f (15b27bed5e11fc0550d7923176dbaf81)

--[ 4 - 参考

[1] Hping           --->    http://www.hping.org
[2] Nmap           --->