深入解读防火墙-解读防火墙记录（8）

　　 
　　解读防火墙记录
　　“陈旧DNS”：客户端会向服务器发送DNS请求，这将花很长时间解析。当你的DNS服务器回应的时候，客户端可能已经忘记你并关闭了用于接受你回应的UDP端口。如果发现UDP端口值是53，大概就发生了这种情况。

这是怎么发生的？服务器可能在解析一个递归请求，但是它自己的包丢失了，所以它只能超时然后再试。当回到客户时，客户认为超时了。许多客户程序(尤其是Windows中的程序)自己做DNS解析。即它们自己建立SOCKET进行DNS解析。如果它们把要求交给操作系统，操作系统就会一直把端口开在那里。

　　“多重DNS回应”：另一种情况是客户收到对于一个请求的多重回应。收到一个回应，端口就关闭了，后序的回应无法达到。此外，一个Sun机器与同一个以太网中的多个NICs连接时，将为两个NICs分配相同的MAC地址，这样Sun机器每桢会收到两个拷贝，并发送多重回复。还有，一个编写的很糟糕的客户端程序(特别是那些吹嘘是多线程DNS解析但实际上线程不安全的程序)有时发送多重请求，收到第一个回应后关闭了Socket。但是，这也可能是DNS欺骗，攻击者既发送请求由发送回应，企图使解析缓存崩溃。

　　“NetBIOS解析”：如果Windows机器接收到ICMP包，看看UDP目标端口是否是137。如果是，那就是windows机器企图执行gethostbyaddr()函数，它将将会同时使用DNS和NetBIOS解析IP地址。DNS请求被发送到某处的DNS服务器，但NetBIOS直接发往目标机器。如果目标机器不支持NetBIOS，目标机器将发送ICMP unreachable。

　　“Traceroute”：大多数Traceroute程序(Windows中的Tracert.exe除外)向关闭的端口发送UDP包。这引起一系列的背靠背的ICMP Port Unreachable包发回来。因此你看到防火墙显示这样ICMP包，可能是防火墙后面的人在运行Traceroute。你也会看到TTL增加。

　　3) Type = 3, Code = 4 (Fragmentation Needed and Don‘t Fragment was Set)

　　这是由于路由器打算发送标记有(DF, 不允许片断)的IP报文引起的。为什么？IP和TCP都将报文分成片断。TCP在管理片断方面比IP有效得多。因此，饯堆趋向于找到“Path MTU”（路由最大传输单元）。在这个过程将发送这种ICMP包。

　　假设ALICE和BOB交谈。他们在同一个以太网上(max frame size = 1500 bytes)，但是中间有连接限制最大IP包为600 byte。这意味着所有发送的IP包都要由路由器切割成3个片断。因此在TCP层分割片断将更有效。TCP层将试图找到MTU(最大传输单元)。它将所有包设置DF位(Don‘t Fragment)，一旦这种包碰到不能传输如此大的包的路由器时路由器将发回ICMP错误信息。由此，TCP层能确定如何正确分割片断。

　　你也许应该允许这些包通过防火墙。否则，当小的包可以通过达到目的地建立连接，而大包会莫名其妙的丢失断线。通常的结果是，人们只能看到Web页仅显示一半。

　　路由最大传输单元的发现越来越整合到通讯中。如IPsec需要用到这个功能。

　　(三) Type = 4 (Source Quench)

　　这种包可能是当网络通讯超过极限时由路由器或目的主机发送的。但是当今的许多系统不生成这些包。原因是现在相信简单包丢失是网络阻塞的最后信号(因为包丢失的原因就是阻塞)。

　　现在source quenches的规则是(RFC 1122)：
　　 路由器不许生成它们
　　 主机可以生成它们
　　 主机不能随便生成它们
　　 防火墙应该丢弃它们

　　但是，主机遇到Source Quench仍然减慢通讯，因此这被用于DoS。防火墙应该过滤它们。如果怀疑发生DoS，包中的源地址是无意义的，因为IP地址肯定是虚构的。

　　已知某些SMTP服务器会发送Source Quench。

　　(四) Type = 8 (Echo aka PING)

　　这是ping请求包。有很多场合使用它们；它可能意味着某人扫描你机器的恶意企图，但它也可能是正常网络功能的一部分。参见Type = 0 (Echo Response)

　　很多网络管理扫描器会生成特定的ping包。包括ISS扫描器，WhatsUp监视器等。这在扫描器的有效载荷中可见。许多防火墙并不记录这些，因此你需要一些嗅探器捕捉它们或使用入侵检测系统(IDS)标记它们。

　　记住，阻挡ping进入并不意味着Hacker不能扫描你的网络。有许多方法可以代替。例如，TCP ACK扫描越来越流行。它们通常能穿透防火墙而引起目标系统不正常的反应。

　　发送到广播地址(如x.x.x.0或x.x.x.255)的ping可能在你的网络中用于smurf放大。

　　(五) Type = 11 (Time Exceeded In Transit)

　　这一般不会是Hacker或Cracker的攻击

　　1) Type = 11, Code = 0 (TTL Exceeded In Transit)

　　这可能有许多事情引起。如果有人从你的站点traceroute到Inte.net，你会看到许多来自路由器的TTL增加的包。这就是traceroute的工作原理：强迫路由器生成TTL增加的信息来发现路由器。

　　防火墙管理员看到这种情况的原因是Internet上发生路由循环。路由器Flapping(持续变换路由器)是一个常见的问题，常会导致循环。这意味着当一个IP包朝目的地前进时，这个包被一个路由器错误引导至一个它曾经通过的路由器。如果路由器在包经过的时候把TTL域减一，这个包只好循环运动。实际上当TTL值为0时它被丢弃。

　　造成这种情况的另一个原因是距离。许多机器(Windows)的默认TTL值是127或更低。路由器也常常会把TTL值减去大于1的值，以便反应诸如电话拨号或跨洋连接的慢速连接。因此，可能由于初始TTL值太小，而使站点无法到达。此外，一些Hacker/Cracker也会使用这种办法使站点无法到达。

　　2) Type = 11, Code = 1 (Fragment Reassembly Time Exceeded)

　　当发送分割成片断的IP报文时，发送者并不接收所有片断。通常，大多数TCP/IP通讯甚至不分割片断。你看到这种情况必定是采用了分割片断而且你和目的地之间有阻塞。

　　(六) Type = 12 (Parameter Problem)

　　这可能意味着一种进攻。有许多足印技术会生成这种包。（完）

原文转自：http://www.ltesting.net