#!/bin/awk -f
#
# findnat.awk
#
# Script to identify likely NAT devices using sFlow.
# Usage:
#   sflowtool | ./findnat.awk
# generates results of the form:
#   10.10.158.204 127 62216 002078142a2f
#   where:
#     10.10.158.204 is a likely NAT device
#     127 is the TTL seen in packets from the device
#     62216 is a source TCP port number seen a packet from the device
#     002078142a2f is the MAC address of the device
#
# Copyright (c) InMon Corp. 2003 ALL RIGHTS RESERVED

#
# Initialize constants
#

BEGIN {
  # Specify edge switches and subnets
  agents["10.10.49.1"] = "10.10.49.0/24";
  agents[" 10.10.67.1"] = "10.10.67.0/24";

  # Convert mask bits to mask address
  masks[0] = "0.0.0.0";
  masks[1] = "128.0.0.0";
  masks[2] = " 192.0.0.0";
  masks[3] = "224.0.0.0";
  masks[4] = "240.0.0.0";
  masks[5] = "248.0.0.0 ";
  masks[6] = "252.0.0.0";
  masks[7] = "254.0.0.0";
  masks[8] = "255.0.0.0";
  masks[9] = "255.128.0.0";
  masks[10] = "255.192.0.0";
  masks[11] = "255.224.0.0";
  masks[12] = "255.240.0.0";
  masks[13] = "255.248.0.0";
  masks[14] = "255.252.0.0";
  masks[15] = "255.254.0.0";
  masks[16] = "255.255.0.0";
  masks[17] = "255.255.128.0 ";
  masks[18] = "255.255.192.0";
  masks[19] = "255.255.224.0";
  masks[20] = "255.255.240.0 ";
  masks[21] = "255.255.248.0";
  masks[22] = "255.255.252.0";
  masks[23] = " 255.255.254.0";
  masks[24] = "255.255.255.0";
  masks[25] = "255.255.255.128";
  masks[26] = " 255.255.255.192";
  masks[27] = "255.255.255.224";
  masks[28] = "255.255.255.240";
  masks[29] = " 255.255.255.248";
  masks[30] = "255.255.255.252";
  masks[31] = "255.255.255.254";
  masks[32] = " 255.255.255.255";

  # Octet multipliers for converting IP addresses to integers
  b1 = 256;
  b2 = 256 * b1;
  b3 = 256 * b2;
}

#
# The following actions apply to each sFlow record
#

# The agent (switch) reporting this flow sample
/agent/  {agent = $2;}

# The source MAC address decoded from the flow sample
/srcMAC/ {mac = $2;}

# The source IP address decoded from the flow sample
/srcIP/  {src = $2;}

# The IP TTL decoded from the flow sample
/IPTTL/  {ttl = $2;}

# The TCP source port decoded from the flow sample
/TCPSrcPort/{
  port = $2;

  # The TCP port number is the last field we need, so perform the analysis 
  # Is this an edge switch?
  localSubnet = agents[agent];
  if(localSubnet) {

    # Is this a packet from a host on the subnet local to the agent?
    split(localSubnet, parts, "/");
    subnet = parts[1];
    bits = parts[2];
    mask = masks[bits];

    split(mask,parts,".");
    submask = parts[1] * b3 + parts[2] * b2 + parts[3] * b1 + parts[4];

    split(subnet,parts,".");
    subagt = and(parts[1] * b3 + parts[2] * b2 + parts[3] * b1 + parts[4], submask);

    split(src,parts,".");
    subaddr = and(parts[1] * b3 + parts[2] * b2 + parts[3] * b1 + parts[4], submask);

    if(subaddr == subagt) {
      # Is the TTL characteristic of an end host?
      if((ttl != 255) && (ttl != 1) && (ttl % 2)) {
        # A likely NAT device, have we reported on it before?
        if(!host[src]) {
           entry = src " " ttl " " port " " mac;
           print entry;
           host[src] = entry;
        }
      }
    }
  }
}

Now that we've described a system for classifying a NAT by its functionality and limitations, the next task is to examine a network endpoint to detect what kind of address translation is in effect, if any. NAT detection involves exchanging several probe packets with a remote "probe server" somewhere on the Internet (and clearly not behind NAT).

Not That Kind of Probe
The probe server is composed of 4 endpoints across 3 different IP addresses (whether by multihosting or coordinating between processes on separate host machines). The client endpoint initiates the NAT detection process by sending 2 request packets, and the server responds with 4 probes back to the apparent sender, as follows:

1. Request sent to Probe Server 1
1a. Probe Server 1 sends response
1b. Alternate Port sends probe
1c. Alternate Host sends probe 
2. Request sent to Probe Server 2
2a. Probe Server 2 sends response 

Because the Client Endpoint may or may not be behind NAT, each probe server sends its packets back at the "apparent" endpoint that originated the probe request. The client must wait to for the probes to arrive or time out, to determine the nature of its network connection.

Packet 1: Request to Probe Server 1
The initial packet tells the server to send 3 probes at the apparent address of the sender. If the Client Endpoint is behind NAT, this packet creates a mapping between it and Probe Server 1, so that some or all probe packets will may be forwarded.

Packet 1a: Probe Server 1 Response
This packet acknowledges the initial Probe Request, telling the client that the process has started and demonstrating that it is not offline or firewalled from the Internet. It also returns the "apparent address" of the client back to the client endpoint itself. Since Packet 1 has already created an outgoing mapping, all NAT configurations should forward this packet successfully.

Packet 1b: Alternate Port Probe
If the client receives this packet, then it knows that the NAT mapping for this endpoint forwards traffic from any port on the remote host. If the client NAT rejects the packet, then it's likely that the NAT will reject all unsolicited messages from remote hosts.

Packet 1c: Alternate Host Probe
If the client receives this packet, it should expect the NAT mapping for this endpoint to forward traffic from any host on the Internet. If the client NAT rejects the packet, then it's likely that the NAT will reject all unsolicited messages from remote hosts.

Packet 2: Request to Probe Server 2
The second request tells a different probe server to send only 1 probe, the response packet, back to the "apparent" endpoint that originated the request. If there is an intervening NAT, this packet will either expand the previous mapping to include the new remote host, or a new mapping will be created with a different apparent address or port.

Packet 2a: Probe Server 2 Response
This message returns the "apparent" address of the client back to the client endpoint itself. By comparing this address with that returned in Packet 1b, the endpoint can determine whether the NAT uses the same mapping consistently for the same endpoint, or creates a new one on the fly each time. 

Analyzing The Results
Before sending any probe requests, the client application assumes the most pessimistic view -- that it's either offline or blocked from Internet access. It then refines (improves) its opinion of the network limitations as response and probe packets are returned, up to a reasonable timeout period (say 5 seconds). This estimate is never lowered based on incoming data, as each response suggests additional features are supported -- or just confirms something it already knows.
Also note that this information only supplements what the operating system already knows -- if there are no active network interfaces, then the client application has a pretty good idea that the it is offline without sending any probes.

Receive no packets: Offline or blocked network
By default, the client application assumes that it is offline or blocked. If no response packets arrive within the reasonable timeout period, then this becomes the final determination.

Receive packet 1a or 2a: Restrictive network or better
When the client receives a response to its probe request, it assumes that the network is up and that the NAT (if any) will forward packets from remote hosts that already have an established mapping with the local endpoint. In addition, the client application saves the contents of this packet, which indicate the "apparent" network address that the remote host observed.

Receive packets 1a and 2a and (1a == 2a): Consistent network or better
If the client receives a response to the second request, it compares the "apparent" network address returned in each packet. If both servers report the same host and port for the local endpoint, then the client can assume that its address mapping is consistent.

Receive packet 1b and 2a and (1b == 2a): Protective network or better
If the client receives a packet from an unsolicited port on the probe server, it knows that the NAT allows incoming packets from any port on a remote host when a mapping already exists for that host.

Receive packet 1c: Permissive network or better
If the client receives a packet from a host where no previous mapping exists, it knows that the NAT is very permissive or has been configured to forward incoming packets on that port. Note that a NAT may be explicitly configured to allow packets on a single port (if the user knows which port your software uses), or it may simply forward all unknown packets to this host (often called a demilitarized zone) -- but there is no automatic way to tell the difference.

Receive packets 1a and 1c and (1a == local): Direct network
If the client knows that it is on a permissive network, it compares the apparent host address and port against the address and port on the local interface it is bound to. If they are identical, the client may assume it is directly connected to the Internet and that no NAT is present -- or is sufficiently camoflauged as to make no difference.

原文见：
http://www.codewhore.com/nat4.html 
QUOTE 
Detecting NAT Routers 
Thursday, April 24 2003 @ 08:35 AM CDT
Contributed by: opticfiber A great paper written by Peter Phaal explains the simple method used in his companies product, Sflow, to detect multiple host behind a NAT firewall. The secret, it would seem is simply monitoring of the TTL of out going packets and comparing them to a host know not to be using a NAT firewall.

Another method only touched upon by Phaal is passive OS finger printing, although this method is less reliable, an statistical analasys could determine if multiple operating systems were using the same network network device. If this were the case it would be reasonable to assume that that host was in fact a NAT device.

AT&T Labs has published a paper explaining how to count the number of devices behind a NAT device. The method AT&T uses, relies on the fact that most operating systems (excluding Linux and Free BSD) use IP header ID's as simple counters. By observing out of sequence header ID's, an analasys can calculate how many actual hosts are behind a NAT device.

Each of these methods can be easily defeated through better sterilization by the router itself. In the first example, if the TTL for each TCP packet was re-written by the router for each packet to the value of 128, the first method would no longer function. For the second method, sterilizing IP header information and stripping unneeded TCP flags would successfully undermine this scheme. For the last Method, counting hosts behind a router. Striping the fragmentation flag for syn packets, and setting the IP ID to '0', (like Linux and Free BSD both do) would make it impossible to count hosts behind a NAT router. 

终于让我找到了：
网络尖兵也是采用国外的技术啊。
看看这里吧：
http://www.sflow.org/detectNAT/

看图片，原理都是一样。 
QUOTE 
The NAT detection technique is based on two observations about the IP TTL (Time To Live) field.

Host operating systems have characteristic initial TTL values. This property of individual operating system implementations of TCP/IP is well known and can be used as part of a "fingerprint" to identify the operating system that a host is running merely by examining its traffic. The technique is well described in Passive OS Fingerprinting: Details and Techniques by Toby Miller. 
NAT devices or gateways decrement the TTL on packets that they forward. 
sFlow provides a stream of sampled packet headers captured at the two switches. These packet headers can be decoded and IP source addresses and TTL values can be extracted. 

Suppose all the hosts use the Windows operating system, each host would then generate IP packets with a TTL value of 128. Since the TTL value is decremented each time the packet traverses a router, a packet seen at the firewall from Host C would always have a TTL of 127. Similarly, a packet from Host C seen by the other switch (Switch 10.10.49.204) would also have a TTL of 127. However, the switch connecting Host C to the network (Switch 10.10.67.1) should always see a TTL of 128. The algorithm for detecting NAT routers relies on the observation that switches directly connected to a host, or in the same subnet as a host, will always see packets from the host with a TTL that is characteristic of the host operating system.

In this example the sFlow Analyzer would see a TTL of 127 when examining packets sampled by switch 10.10.49.1 that apparently originated from "host" 10.10.49.1. The TTL values in packets from Hosts A and B are decremented by the NAT router before they are passed to the switch, revealing the existence of the router.

The effectiveness of this algorithm is easily demonstrated using sFlow data from a production network.

这下我们可以破了"网络尖兵"了 
思科的NAT 检测的功能介绍：
http://www.cisco.com/en/US/products/sw/ios...0080110ae9.html 
一封信：
http://clug.chicago.il.us/mail-archive/Mar2001/0845.html 
QUOTE 
通用的被动式操作系统指纹扫描工具p0f
2004-07-18
类别：扫描器
主页：http://lcamtuf.coredump.cx/p0f.shtml

P0f v2是一个通用的被动式操作系统指纹扫描工具。p0f可以确认以下机器的操作系统：
- 连接到你机器的机器(SYN模式),
- 你要连接的机器(SYN+ACK模式),
- 你连不上的机器(RST+模式),
- 你可以监听通讯的那些机器 

P0f还有其他手段来检测或测量下面的东西：
- 防火墙的存在或伪装(对策略强制有用),
- 到远端系统的距离以及它启动的时间,
- 其他网络连接(DSL, OC3, avian carriers)以及他的ISP. 

所有这些甚至在扫描的设备位于一个主动包过滤防火墙后，这时候我们常用的扫描器束手无策的时候都可以完成。P0f不产生任何其他的网络流量：直接的或者间接的。没有name lookups、没有神秘的嗅探、没有ARIN查询，什么都没有！怎么做到的？很简单：魔法。在这儿你可以找到答案。

我在哪儿可以得到它？

点击这儿你可以得到p0f v2 (2.0.4)。如果你觉得自己够幸运，你可以试试最近的开发快照(2.0.5-b1)(如果你需要报告一个Bug或者提交一个新的特性请下载它试试)。如果你喜欢p0f，希望跟踪这个产品，建议你订阅位于Freshmeat的该项目。

Windows用户可以下载这个Kirby Kuehl制作的预编译的二进制版本。想在移动设备上使用的人可以在Kevin Currie的主页上下载ARM的移植版本。 

p0f的一些功能已经内建于OpenBSD中，谢谢Mike Frantzen(他的工作实际上启发了p0f V2的重写）。netfilter的Linux补丁在这儿。P0f可以允许在Linux、FreeBSD、NetBSD、OpenBSD、MacOS X、Solaris、AIX和Windows(已经其他一些有pcap或者pcap移植库的系统)上。

第三方的项目如p0f_db或p0f-stats提供了p0f输出更容易的存储和分析。
QUOTE 
There is a new application note < http://www.sflow.org/detectNAT/ > 
describing a technique for detecting unuathorised NAT devices using sFlow. 
NAT devices can be a security problem if they hide wireless access points. 
An uncontrolled wireless access point can allow unrestricted access to the 
network from a considerable distance. 

The following steps will let you configure Traffic Server to forward sFlow 
so you can use the script in the paper (provided you are monitoring switches 
using sFlow,XRMON or an sFlow probe): 

1. Use the Server->Forwarding option to forward sFlow from all agents in the 
network to localhost, port 7343 (Agent=0.0.0.0/0, Address=127.0.0.1 , 
Port=7343). 
2. Modify the findnat.awk script so that there is an "agents[agent]=subnet" 
line for each of your edge switches. 
3. Run the script using the command: sflowtool -p 7343 | ./findnat.awk 

Note: This technique will not work with NetFlow sources since they do not 
provide the IP TTL information needed for the analysis. 

---------------------- 
Peter Phaal 
InMon Corp. 

sFlow步入实用 

sFlow步入实用 

一项不太为人所知的实时网络监测标准，将为高速网络用户带来价值。 

尽管IETF的sFlow草案标准已经公布多年了，但还没有几家厂商实施它。专家和用户表示，随着一些企业中的网络传输流速度增加到千兆和万兆，sFlow将成为跟踪网络性能和提供网络安全的一种越来越重要的工具。 

2001年被IETF批准成为一项草案标准的sFlow是一种网络监测技术，它利用对整个网络上传送的局域网和广域网数据包流的随机采样，让用户详细、实时地掌握网络传输流的性能、趋势和问题。

网络监测功能一般是通过将网络探测器设备(如运行探测器软件的PC或专用设备)安装在网络的某一网段上采集数据实现的。探测器常常被插入到局域网交换机上的镜像端口中，即被配置为复制来自交换机上另一个端口的传输流的端口。探测器将只能够从镜像端口采集传输流数据。 

sFlow被部署在运行于网络中实际的交换机和路由器上的各个网络管理信息库中(MIB)中，MIB是基于硬件或基于软件的代理。sFlow支持者表示，这样做可以更全面地展示网络性能。监测发生在每台具有sFlow功能的交换机的每一个端口上，而不是只出现连接探测器的端口或网段上。 

sFlow MIB对流经端口的数据包随机采样，而不是捕获和记录交换机或路由器端口上的每一个数据包。这些叫做sFlow数据报的样本被转发给网络上的一台sFlow采集服务器。在这台服务器上，样本数据报利用一种算法进行处理，算法根据采样的数据建立网络传输流的完整模型。 

sFlow背后的技术是由交换机监测软件生产商InMon的工程师、HP以及Foundry Networks的开发人员联合开发的。将sFlow技术应用在局域网交换机中的厂商包括HP、Foundry和 Extreme Networks。HP OpenView、NetScout的nGenius Performance Manager 和InMon Traffic Server等产品中提供了对sFlow的软件支持。 

sFlow应用实例 

在佛罗里达州Tampa市的Moffit癌症中心中，具有sFlow功能的交换机被用于测量网络性能以及用作一种安全工具。该中心表示，"sFlow为其提供了网络中每一个端口的实时网络统计数据。有关传输流模式信息的详细程度非常高，详细到了协议和端口级。如果网络上有人做错了什么事，你可以跟踪他们，一直找到他们插入PC的地方。" 

Kingdon Capital Management是纽约一家小型对冲基金公司，该公司也计划使用sFlow。在其网络上传输着很多的实时数据，这种实时数据流基本是由平均价值为每笔1千万美元的交易构成的，他们希望sFlow能更好地了解网络性能的总体情况。了解更多的数据包和协议专有信息的能力将会对其有更大的帮助，它将使该公司可以得到比通常得到的信息更加详细的内容。 

安全功能 

一些专家表示，除了提供网络性能的实时快照外，sFlow还可被用作一种网络安全工具。检测作为网络地址翻译(NAT)设备的未经授权的网络设备就是一个例子。sFlow草案标准作者、InMon公司工程师Peter Phaal表示，这可能包括一台具有NAT功能的普通无线路由器。尽管连接到网络上的NAT设备也许看似合法的端点节点，但这些设备可能成为有线或无线用户的后门，提供对未经授权的连接访问。 

由于sFlow对来自网络中每一个端口的数据流进行采样，sFlow数据分析器可以通过比较交换机和NAT设备间的子网数据，识别网络中作为NAT设备的节点。 

可以击败网络尖兵了

Each of these methods can be easily defeated through better sterilization by the router itself. In the first example, if the TTL for each TCP packet was re-written by the router for each packet to the value of 128, the first method would no longer function. For the second method, sterilizing IP header information and stripping unneeded TCP flags would successfully undermine this scheme. For the last Method, counting hosts behind a router. Striping the fragmentation flag for syn packets, and setting the IP ID to '0', (like Linux and Free BSD both do) would make it impossible to count hosts behind a NAT router. 

在第一个例子，如果所有的tcp包通过iptables重新把TTL写为128，就可以破解掉了。
在第二种方法，清除IP头的信息和抽取掉不需要的TCP标记，也可以完美的破解掉
在第三种方法，剥离破碎的syn包的标记，设置IP的ID为"0"，也使它无法计算出在NAT后面的主机有多少台。

猜测认为网络尖兵只使用了比较TTL的技术，所以可以很容易的破解掉！！而如果是用cisco的接入设备的话，可能需要三者同时兼顾才行！

网络尖兵图示： 

附加图片

IP数据包的格式 

附加图片
又看了一篇文章：
http://www.dslreports.com/shownews/27754

QUOTE 
Re: Just use a tweak tool and up your TTL by 1?

This is NOT the TTL they are talking about, it's the ID portion of the the IP packet header.

Look at the following RFC &raquo;
www.faqs.org/rfcs/rfc791.html
which explains the IP packet. Page 8 has a diagram of the sections of the packet, and Page 10 talks about the identificaition section of the packet.

When a machine sends out packets, they put a number (somewhat random) into this section of the packet, and incrament it for each packet after that. This helps the reciever put the packets back into the proper order (this is needed because not all packets always take the same route, so some later packets can actually arrive before earlier packets, so they need something to identify what order then need to be reassembled in)

Mangling this CAN be done, but some higher end firewalls and Linux type NAT boxes, but they have to track it in a very percise order, to make sure that the packets ID numbers still make some sense.

This method of identifying multiple machines works by relaying on the fact that each machine will be sending out packets in order, but will be in different number ranges. I.E. if you see 9 packets, and 3 have IDs of 55,56,57, 3 have ID's of 1001, 1002, 1003, and 3 have ID's on 50000,50001,50002, you can sort of determine that there are 3 machines. It's a bit more complex then this, but this is an simplification.

--NetGeek
--

如果网络尖兵不只采用检测ttl的技术的话，在目前是没有办法破解掉的。 
QUOTE (anson @ Nov 8 2004, 09:27 AM)
感谢wsgtrsys为我们提供这么详尽的参考意见，但小弟水平有限，我想知道如何操作才能实现这些功能？用哪款软路由可以？谢谢！

例如：
通过iptables对HTTP协议进行内容过滤，发现头部有HTTP_VIA什么的就DROP掉。 

在coyote中试试加入这个命令：
CODE 
iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-inc 1
这个命令只是更改了TTL的值，将进入router的包的TTL值增加了1，所以从路由出来的数据包的TTL值会同进入前一样.
或者使用命令：

CODE 
iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-set 129

这样从router出来的包的TTL值全部都统一为128了。

其中eth0为你的内网卡。经测试以上命令都可以正常工作的 
Linux下的路由（NAT），主要采用iptables。
iptables采取nat或者IP MASQUERADE方法转换网络IP地址。
采取iptables的后果是：
所有的内部网络的连接经过转换到router后，全部变为高端口，即60000以上的高端口,因为它为了避免同常规的服务端口相冲突。这一点通过包检测很容易探测出来。所以目前是没有办法解决的。
内部网络产生的IP包通过router后，有一个固定在某一段的ID值，而这个值在内部网络中每一台电脑所产生的都不一样。而router 在默认状态下是不会改变这个值的。大家可以安装tcpdump，通过它抓包观察到。
AT&T Labs 公司就是通过这种方法去检测你的内网到底有多少台主机。
而怎样通过iptalbes改变其值，我也不知道怎么办？？？？

所以，就是难，只有写信向
http://www.netfilter.org
求援了？？？？ 
附图：
由tcpdump捕获的数据包的抓图，可以看出，从10.10.49.204这个router出去的连接全部为高端口 

附加图片

从下图可以看出从router出去的包的TTL值全部变为127，如果没有使用路由的值应当为128，同时可以看出，ID值主要两个段，一个是16xx,一个是4xxxx,由此可以推断出，NAT后面的主机应该为2台。 

附加图片

指纹方法学

有许多许多技术可以用来定义网络栈指纹。基本上，你只要找出操作
系统间的不同并写探测器查明它们。如果你合并足够这些，你可以非
常细致的区分它们。例如nmap可以可靠分辨出Solaris 2.4 和Solaris 2.5-2.51
以及Solaris 2.6。他能分辨Linux内核2.0.30到2.0.31-34或or 2.0.35。
这有一些技术：

FIN 探测器 -- 这里我们送一个FIN包（或任何其他包不带ACK 或SYN
标记）给一个打开的端口并等待回应。正确的RFC793行为是不
响应，但许多有问题的实现例如 MS Windows, BSDI, CISCO, 
HP/UX,MVS,和IRIX 发回一个RESET。许多现有工具利用这个技
术。

BOGUS 标记探测器 -- Queso 是我见过的第一个用这个聪明技术扫描
器。这个主意是设置一个未定义的TCP "标记"（64或128）在SYN
包的TCP头里。Linux机器到2.0.35之前在回应中保持这个标记。
我没有发现其他OS有这个错误。然而，一些操作系统象是复位
连接当它们得到一个SYN+ BOGUS包的时候。这一行为对辨识它
们有用。

TCP ISN 取样 -- 这个主意是找出当响应一个连接请求时由TCP 实现
所选择的初始化序列数式样。这可分为许多组例如传统的64K
（许多老UNIX机器），随机增量（新版本的Solaris, IRIX, FreeBSD,
Digital UNIX, Cray, 和许多其他的），真"随机"（Linux 2.0.*,
OpenVMS,新的AIX,等）。Windows 机器（和一些其他的）用一
个"时间相关"模型，每过一段时间ISN 就被加上一个小的固
定数。不用说，这几乎和老的64K 行为一样容易攻破。当然我
喜欢的技术是"常数"。机器总是使用确切同样的ISN 。我已
经在3Com的集线器（用0x803）和Apple LaserWriter打印机（
用0xC7001 ）上看到了。

你也可以通过例如计算其随机数的变化量，最大公约数，以及
序列数的其他函数和数之间的差异再进一步分组。

要知道ISN 的生成和安全息息相关。想了解更多情况，联络在
SDSC的"安全专家"Tsutome Shimmy Shimomura，问他所知道
的。Nmap是我所见到的第一个用它来辨识OS的程序。

不分段位 -- 许多操作系统开始在送出的一些包中设置IP的"Don't Fragment"
位。这带来多种性能上的好处（尽管它也可能是讨厌的 -- 这
就是nmap的分段扫描对Solaris机器无效的原因）。无论如何，
不是所有的OS都这样做而且另一些做的场合不同，所以通过注
意这个位我们甚至能收集目标OS的更多信息。在那两个程序中
没见过这个。

TCP 初始化窗口 -- 这只包括了检查返回包的窗口大小。较老的扫描
器简单地用一个非零窗口在RST包中来表示"BSD 4.4 族"。新
一些的如queso 和nmap则保持对窗口的精确跟踪因为它对于特定
OS基本是常数。这个测试事实上给出许多信息，因为有些可以被
唯一确定（例如，AIX 是所知唯一用0x3F25的）。在它们"完全
重写"的NT5 TCP 栈中，Microsoft 用的是0x402E。有趣的是，
这和OpenBSD 与FreeBSD 中所用的数字完全一样。

ACK 值 -- 尽管你会认为这个会完全标准，不同实现中一些情况下ACK
域的值是不同的。例如，如果你送了一个FIN|PSH|URG 到一个
关闭的TCP 端口。大多数实现会设置ACK 为你的初始序列数，
而Windows 和一些傻打印机会送给你序列数加1 。若你送一个
SYN|FIN|URG|PSH 到一个打开的端口，Windows 会非常古怪。
一些时候它送回序列号，但也有可能送回序列号加1， 甚至还
可能送回一个随机数。我们觉得奇怪，不知微软写的是些什么
代码。

ICMP 错误信息终结 -- 一些（聪明的）操作系统跟从RFC 1812的建
议限制各种错误信息的发送率。例如，Linux 内核（在net/ipv4/icmp.h）
限制目的不可达消息的生成每4 秒钟80个，违反导致一个1/4 
秒的处罚。测试的一种办法是发一串包到一些随机的高UDP 端
口并计数收到的不可达消息。没见过用它的，而且实际上我也
没有把它加进nmap（除了作为UDP 端口扫描用）。这个测试会
让OS辨识多花一些时间因为需要送一批包再等它们回来。而且
对付网络丢包会很痛苦。

ICMP 消息引用 -- RFC 规定ICMP错误消息可以引用一部分引起错误
的源消息。对一个端口不可达消息，几乎所有实现只送回IP请
求头外加8 字节。然而，Solaris 送回的稍多，而Linux 更多。
这使得nmap甚至在没有对方没有监听端口的情况下认出Linux 
和Solaris 主机。

ICMP 错误消息回应完整性 -- 我这个想法来自Theo De Raadt （OpenBSD
开发负责人）贴在comp.security.unix的文章。刚刚提到，机
器会把原始消息的一部分和端口不可达错误一起送回。然而一
些机器倾向于在初始化处理时用你的消息头作为"草稿纸"所
以再得到时会有些许的改动。例如，AIX 和BSDI送回一个IP"
全长"域在20字节处。一些 BSDI，FreeBSD，OpenBSD，ULTRIX，
和VAXen 改变了你送的IP ID 。因为TTL 改变而改变了检查和，
有些机器（AIX, FreeBSD, 等）送回错误的或0 检查和。总之，
nmap作9 种测试在ICMP错误上以分辨出这类细微差别。

服务类型 -- 对于ICMP端口不可达消息我察看送回包的服务类型(TOS)
值。几乎所有实现在这个ICMP错误里用0 除了Linux 用0xc0。
这不是标准的TOS 值，而是一个未使用优先域(AFAIK) 的一部
分。我不知道为什么如此，但如果他们改成0 我们还能够分辨
旧系统_而且_还能分辨出旧系统和新系统。

分段控制 -- 这是安全网络公司（现在由一帮在NAI 的Windows 用户
所拥有）的Thomas H. Ptacek喜爱的技术。它获益于事实即不
同实现经常以不同方式控制覆盖IP段。一些会用新的覆盖旧的
部分，另一些情况中旧的优先。有很多不同可能你可以用来决
定如何重组数据包。我没有加入这一特性因为没有简便的方式
发送IP分段（特别是，在Solaris 上是不允许的）。关于覆盖
段的更多信息，可以看IDS 的论文( www.secnet.com)

TCP 选项 -- 这简直是泄漏信息的金矿。它的好处在于：
1) 这通常是可选的(哈!) 所以并非所有实现都支持。
2) 若一个实现发出设置了选项的请求，目标通过设置它在回
应中表示支持。
3) 可以在一个数据包中设置而一次测试所有选项。

Nmap发送这些选项的几乎所有可能的包：

Window Scale=10; NOP; Max Segment Size = 265; Timestamp; End of Ops;

当你得到回应，看看那个选项被送回也就是被支持。一些操作
系统如最近的FreeBSD 机器支持上面所有的，而其他，如Linux 2.0.X
支持的则很少。最近的Linux 2.1.x 内核支持上面所有的。另
一方面，它们又有更易受攻击的TCP 序列生成方式。去看看。

即使几个操作系统支持同样的选项集，有时仍可以通过选项的
_值_分辨出它们。例如，如果送一个小的MSS值给Linux机器，
它会用那个MSS 生成一个回答给你。其他主机会给你不同的值。

甚至即使你得到同样的支持选项集和同样得值，你仍可以通过
选项提供的_顺序_和填充字进行辨识，例如Solaris返回'NNTNWME'
表示：

而Linux 2.2.122返回MENNTNW。同样的选项，同样的值，但不
同顺序！

没见过其他OS检测工具利用TCP 选项，但它非常有用。

因同样原因有其他几个有用的选项我会探测，象那些支持T/TCP
和选择性确认。

开发年代 -- 甚至使用上面所有测试，nmap仍不能从TCP 栈区分Win95，
WinNT，或Win98。这很令人惊讶，尤其是Win98 比Win95 晚出
现4 年。你可能想它们不得不从某些方面进行改善（象支持更
多的TCP 选项）这样我们可以检测到改变而分辨出它们。不幸
的是，不是这样的。NT的栈显然就是放在95里的蹩脚的东西。
而且到98也没加改动。

但别放弃希望，还有个办法。你可以简单的进行早期的Windows
DOS 攻击（Ping of Death, Winnuke, 等）而比当时的如Teardrop
和Land多做一些。就是在每个攻击之后，ping它们看是否垮
掉了。等到你最后crash 掉它们，你就能缩小的某一服务包
或补丁。

这个没加进nmap,尽管我承认它非常诱人 。

SYN洪水限度 -- 一些操作系统会停止新的连接尝试如果你送太多的
伪造SYN 给它（伪造包避免你的内核复位连接）。许多操作系
统只能处理8 个包。最近的Linux 内核（包括其他操作系统）
允许不同的方式如SYN cookie来防止这成为严重问题。所以你
可以试着从伪造地址发8 个包到目标打开的端口再尝试你还能
否建立连接以发现一些信息。这没在nmap中实现因为有人不喜
欢你用SYN 洪水，甚至你解释这只是想知道它运行的操作系统
也不能使他们平静。

http://ippersonality.sourceforge.net/
http://voodoo.somoslopeor.com/papers/nmap.html

QUOTE 
The Linux IP Personality patch adds to your Linux 2.4 kernel the ability to have different 'personalities' network wise, that is to change some characteristics of its network traffic, depending on different parameters (anything you can specify in an iptables rule: src/dst IP address, TCP or UDP port, etc.) 

The characteristics that can be changed are: 

TCP Initial Sequence Number (ISN) 
TCP initial window size 
TCP options (their types, values and order in the packet) 
IP ID numbers 
answers to some pathological TCP packets 
answers to some UDP packets 
They are deeply configurable. 

This patch relies on the wonderful framework created by Rusty Russel: netfilter. More precisely, the patch adds a new iptables target (in a kernel module) that can be used in the mangle table with a (patched) iptables. This target is very configurable. See the documentation section for more details on how it works. 

网络尖兵监测的是ip包的指纹特征，我查了国外很多资料，只有：
http://ippersonality.sourceforge.net/
提供的包可以重新定义所有包的特征，如：把linux下发出的包伪装为windows发出的包。使nmap也探测不出来，更不用说用网络尖兵了。
不过 http://ippersonality.sourceforge.net/这个项目好象在2年前已经停止了。
我用它提供的patch来进行编译的时候会报错。
所以目前用http://ippersonality.sourceforge.net/的解决办法是不可行了。

待我慢慢查查资料，或许大家可以帮帮我。
另外：网络尖兵最可能使用的技术就是探测IP包的ID 数值来判断NAT后面有多少台主机。而win系统产生的ID是根据系统时间产生而递增的。linux系统的ID值为0，openbsd系统的ID是随机的。 
大家再看看这一篇文章，可能对你有所启发
A practical approach for defeating Nmap OS-Fingerprinting
（一个战胜 Namp 对操作系统进行指纹识别的实用方法）

http://voodoo.somoslopeor.com/papers/nmap.html

大家可以到这个网站去看看它检测出你的系统是什么，上网类型是什么，用没用代理？
是否检测得正确？
网络尖兵就是使用这样的技术。

http://lcamtuf.coredump.cx/p0f-help/ 
查了这么多资料和网站，最后发现用linux实现的确有难度，用bsd 可以很容易的解决。所以这个话题我到此打住了，除非iptables有支持这些功能的模块放出来。。，，，这几天为这个花费了我不少时间和精力，太累了。
-----------------------
上面的文字是个转贴，实际上解决起来很简单。研究的案例子不多，不太清楚 其它地方是不是同样简单，反正在山东网通的限制中，可以用很简单的办法避开这种限制。现在这些无耻之徒抢钱都要抢疯了，怪不得山东网通被审计出来人均仅住房公积金方面就六千多块，其实他们交到6万也不奇怪