七） IRC服务器在探测我
最流行的聊天方式之一是IRC。这种聊天程序的特点之一就是它能告诉你正在和你聊天的人的IP地址。聊天室的问题之一是：人们匿名登陆并四处闲逛，往往会遭遇跑题的评论、粗鲁的话语、被打断谈话、被服务器“冲洗”或被其它客户踢下线。
因此，服务器端和客户端都默认禁止在聊天室内使用匿名登陆。特别需要指出的是，当有人进入聊天室时要检查他们是否通过其它代理服务器连接。最常见的这种扫描是SOCKS。假设你来的那个地方支持SOCKS，那么你完全有可能有一台完全独立的机器，你试图通过明处的代理服务器隐藏你在暗处的真实身份。Undernet’s关于这方面的策略可参考http://help.undernet.org/proxyscan.
同时，crackers/hackers会试图扫描人们的机器以确定他们是否运行某种服务，可被他们用做跳板。同样，通过检查SOCKS，攻击者希望发现某人打开了SOCKS，例如一个家庭的个人用户SOCKS实现共享连接，但将其错误设置成Internet上所有用户都能通过它。
八） 什么是“重定向”端口
一种常见的技术是把一个端口重定向到另一个地址。例如默认的HTTP端口是80，许多人把他们重定向到令一个端口，如8080( 这样，如果你打算访问本文就得写成http://www.robertgraham.com:8080/pubs/firewall-seen.html )
实现重定向是为了让端口更难被发现，从而使Hacker更难攻击。因为Hacker不能对一个公认的默认端口进行攻击而必须进行端口扫描。
大多数端口重定向与原端口有相似之处。因此，大多数HTTP端口由80变化而来：81，88，8000，8080，8888。同样POP的端口原来在110，也常被重定向到1100。
也有不少情况是选取统计上有特别意义的数，象1234，23456，34567等。许多人有其它原因选择奇怪的数，42，69，666，31337。近来，越来越多的远程控制木马( Remote Access Trojans, RATs )采用相同的默认端口。如NetBus的默认端口是12345。
Blake R. Swopes指出使用重定向端口还有一个原因,在UNIX系统上,如果你想侦听1024以下的端口需要有root权限。如果你没有root权限而又想开web服务，你就需要将其安装在较高的端口。此外，一些ISP的防火墙将阻挡低端口的通讯，所以即使你拥有整个机器你还是得重定向端口。
九） 我还是不明白当某人试图连接我的某个端口时我该怎么办？
你可以使用Netcat建立一个侦听进程。例如，你想侦听1234端口：
NETCAT －L －p 1234
许多协议都会在连接开始的部分发送数据。当使用Netcat侦听某个端口时，你能想办法搞清在使用什么协议。如果幸运的话，你会发现是HTTP协议，它会为你提供大量信息，使你能追踪发生的事情。
“－L”参数是让Netcat持续侦听。正常情况下Netcat会接受一个连接，复制其内容，并退出。加上这个参数后，它可以持续运行以侦听多个连接。
ICMP
TCP和UDP能承载数据，但ICMP仅包含控制信息。因此，ICMP信息不能真正用于入侵其它机器。Hacker们使用ICMP通常是为了扫描网络，发动DoS攻击，重定向网络交通。(这个观点似乎不正确，可参考shotgun关于木马的文章，译者注)
一些防火墙将ICMP类型错误标记成端口。要记住，ICMP不象TCP或UDP有端口，但它确实含有两个域：类型(type)和代码(code)。而且这些域的作用和端口也完全不同，也许正因为有两个域所以防火墙常错误地标记了他们。更多关于ICMP的知识请参考Infosec Lexicon entry on ICMP。
关于ICMP类型/代码的含义的官方说明请参阅http://www.isi.edu/in-notes/iana/assignments/icmp-parameters。该文献描述官方含义，而本文描述Hacker的企图，详见下文。
类型 代码 名称 含义
0 * Echo replay 对ping的回应
3 * Destination Unreachable 主机或路由器返回信息：一些包未达到目的地
0 Net Unreachable 路由器配置错误或错误指定IP地址
1 Host Unreachable 最后一个路由器无法与主机进行ARP通讯
3 Port unreachable 服务器告诉客户端其试图联系的端口无进程侦听
4 Fragmentation Needed but DF set 重要：如果你在防火墙丢弃记录中发现这些包，你应该让他们通过否则你的客户端将发现TCP连接莫名其妙地断开
4 * Source Quench Internet阻塞
5 * Redirect 有人试图重定向你的默认路由器，可能Hacker试图对你进行“man-in-middle”的攻击，使你的机器通过他们的机器路由。
8 * Echo Request ping
9 * Router Advertisement hacker可能通过重定向你的默认的路由器DoS攻击你的Win9x 或Solaris。邻近的Hacker也可以发动man-in-the-middle的攻击
11 * Time Exceeded In Transit 因为超时包未达到目的地
0 TTL Exceeded 因为路由循环或由于运行traceroute，路由器将包丢弃
1 Fragment reassembly timeout 由于没有收到所有片断，主机将包丢弃
12 * Parameter Problem 发生某种不正常，可能遇到了攻击
(一) type=0 (Echo reply)
发送者在回应由你的地址发送的ping，可能是由于以下原因：
有人在ping那个人：防火墙后面有人在ping目标。
自动ping：许多程序为了不同目的使用ping，如测试联系对象是否在线，或测定反应时间。很可能是使用了类似VitalSign‘s Net.Medic的软件，它会发送不同大小的ping包以确定连接速度。
诱骗ping扫描：有人在利用你的IP地址进行ping扫描，所以你看到回应。
转变通讯信道：很多网络阻挡进入的ping(type=8)，但是允许ping回应(type=0)。因此，Hacker已经开始利用ping回应穿透防火墙。例如，针对internet站点的DdoS攻击，其命令可能被嵌入ping回应中，然后洪水般的回应将发向这些站点而其它Internet连接将被忽略。
(二) Type=3 (Destination Unreachable)
在无法到达的包中含有的代码(code)很重要
记住这可以用于击败“SYN洪水攻击”。即如果正在和你通讯的主机受到“SYN洪水攻击”，只要你禁止ping(type=3)进入，你就无法连接该主机。
有些情况下，你会收到来自你从未听说的主机的ping(type=3)包，这通常意味着“诱骗扫描”。攻击者使用很多源地址向目标发送一个伪造的包，其中有一个是真正的地址。Hacker的理论是：受害者不会费力从许多假地址中搜寻真正的地址。
解决这个问题的最好办法是：检查你看到的模式是否与“诱骗扫描”一致。比如，在ICMP包中的TCP或UDP头部分寻找交互的端口。
1) Type = 3, Code = 0 (Destination Net Unreachable)
无路由器或主机：即一个路由器对主机或客户说，：“我根本不知道在网络中如何路由！包括你正连接的主机”。这意味着不是客户选错了IP地址就是某处的路由表配置错误。记住，当你把自己UNIX机器上的路由表搞乱后你就会看到“无路由器或主机”的信息。这常发生在配置点对点连接的时候。
2) Type = 3, Code = 3 (Destination Port Unreachable)
这是当客户端试图连击一个并不存在的UDP端口时服务器发送的包。例如，如果你向161端口发送SNMP包，但机器并不支持SNMP服务，你就会收到ICMP Destination Port Unreachable包。
解码的方案
解决这个问题的第一件事是：检查包中的端口。你可能需要一个嗅探器，因为防火墙通常不会记录这种信息。这种方法基于ICMP原始包头包含IP和UDP头。以下是复制的一个ICMP unreachable包：
00 00 BA 5E BA 11 00 60 97 07 C0 FF 08 00 45 00
00 38 6F DF 00 00 80 01 B4 12 0A 00 01 0B 0A 00
01 C9 03 03 C2 D2 00 00 00 00 45 00 00 47 07 F0
00 00 80 11 1B E3 0A 00 01 C9 0A 00 01 0B 08 A7
79 19 00 33 B8 36
其中字节03 03是ICMP的类型和代码。最后8个字节是原始UDP头，解码如下：
08A7 UDP源端口 port=2215，可能是临时分配的，并不是很重要。
7919 UDP目标端口 port=31001，很重要，可能原来用户想连接31001端口的服务。
0033 UDP长度 length=51，这是原始UDP数据的长度，可能很重要。
B836 UDP校验和 checksum=0xB836，可能不重要。
你为什么会看到这些？
“诱骗UDP扫描”：有人在扫描向你发送ICMP的机器。他们伪造源地址，其中之一是你的IP地址。他们实际上伪造了许多不同的源地址使受害者无法确定谁是攻击者。如果你在短时间内收到大量来自同一地址的这种包，很有可能是上述情况。检查UDP源端口，它总在变化的话，很可能是Scenario。
“陈旧DNS”：客户端会向服务器发送DNS请求，这将花很长时间解析。当你的DNS服务器回应的时候，客户端可能已经忘记你并关闭了用于接受你回应的UDP端口。如果发现UDP端口值是53，大概就发生了这种情况。这是怎么发生的？服务器可能在解析一个递归请求，但是它自己的包丢失了，所以它只能超时然后再试。当回到客户时，客户认为超时了。许多客户程序(尤其是Windows中的程序)自己做DNS解析。即它们自己建立SOCKET进行DNS解析。如果它们把要求交给操作系统，操作系统就会一直把端口开在那里。
“多重DNS回应”：另一种情况是客户收到对于一个请求的多重回应。收到一个回应，端口就关闭了，后序的回应无法达到。此外，一个Sun机器与同一个以太网中的多个NICs连接时，将为两个NICs分配相同的MAC地址，这样Sun机器每桢会收到两个拷贝，并发送多重回复。还有，一个编写的很糟糕的客户端程序(特别是那些吹嘘是多线程DNS解析但实际上线程不安全的程序)有时发送多重请求，收到第一个回应后关闭了Socket。但是，
