a question about idle scan

rootclown

the original paper about idle scanhttp://www.insecure.org/nmap/idlescan.html


    the paper sail that the first step is to send SYN|ACK to the proxy,but when I use this tech to scan a host,using tcpdump to capture the packet,I found that the packet contain SYN only instead of SYN|ACK

04:26:30.257825 IP (tos 0x0, ttl  41, id 54588, offset 0, flags [none], length: 40) 202.4.147.188.33625 >; 202.4.*.*.80: S [tcp sum ok] 2366248689:2366248689(0) ack 0 win 12953
      
04:26:30.258366 IP (tos 0x0, ttl  56, id 12958, offset 0, flags [none], length: 40) 202.4.*.*.80 >; 202.4.147.188.33625: R [tcp sum ok] 0:0(0) win 16384
      
04:26:30.290153 IP (tos 0x0, ttl  45, id 46585, offset 0, flags [none], length: 40) 202.4.147.188.33626 >; 202.4.*.*.80: S [tcp sum ok] 2366248690:2366248690(0) ack 0 win 12953
      
04:26:30.290435 IP (tos 0x0, ttl  56, id 12959, offset 0, flags [none], length: 40) 202.4.*.*.80 >; 202.4.147.188.33626: R [tcp sum ok] 0:0(0) win 16384

    port 80 on host 202.4.*.* is open and have little flow
  why he send RST back to me since the port is open?
    why not use SYN|ACK ?the code idle_scan.cc
have the following

1. /* TH_SYN|TH_ACK is what the proxy will really be receiving from
   
2.        the target, and is more likely to get through firewalls.  But
   
3.        TH_SYN allows us to get a nonzero ACK back so we can associate
   
4.        a response with the exact request for timing purposes.  So I
   
5.        think I'll use TH_SYN, although it is a tough call. */
   
6.     /* We can't use decoys 'cause that would screw up the IPIDs */
   
7.     send_tcp_raw(proxy->;rawsd, proxy->;host.v4sourceip(),
   
8.                  proxy->;host.v4hostip(), o.ttl,
   
9.                  o.magic_port + probes_sent + 1, proxy->;probe_port,
   
10.                  sequence_base + probes_sent + 1, 0, TH_SYN|TH_ACK,
    
11.                  ack, NULL, 0, NULL, 0);
    

复制代码

  who can tell me why ?thanks

ayazero

这种扫描方式最早是在上大二的时候在hping2自带的文档中发现的，很早以前的技术了

找一台中间傀儡主机（事先测试过，能正常回应TCP请求，对外无数据传输），向其发送一个SYN包，它回复一个SYN|ACK包，得到一个IPID序列号，记录这个IPID的值，正常情况下操作系统在主动发送数据包时会对IPID递增，于是：

nmap向目标发送一个SYN包，其源地址是傀儡主机的IP地址，如果被探测的目标端口开放的话，目标主机会向傀儡主机发送一个SYN|ACK包以完成TCP三次握手，此时傀儡主机收到SYN|ACK包发现不是自己的包，因为TCP序列号不对，所以向目标主机发送一个RST包重置TCP连接，因为发送了RST，所以他的IPID=原来的IPID+1，这时nmap再向傀儡主机发送SYN|ACK包，傀儡主机回应RST包，得到他的IPID=原来的IPID+2，证明目标端口是开放的

如果目标主机的被探测端口不开放，那么在nmap向目标主机发送源地址是傀儡主机IP的SYN包后会向傀儡主机发送RST包，傀儡主机就不会再主动向外发包，这样nmap向傀儡主机发送SYN|ACK包后得到RST回复的IPID=IPID+1，证明端口是关闭的

所以从上得知，这不是一种准确的扫描方式

ayazero

不过这可以在扫描过程中隐藏自己的IP

不知道我的解释是否清楚

rootclown

thank you.
202.4.147.188 is my ip address
202.4.*.* is the proxy used to scan the target
the proxy's port 80 is open,but why not he send me SYN|ACK in response to my SYN?

clown:/home/clown# nmap -p 80 202.4.*.*

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-08-08 16:43 CST
Interesting ports on 202.4.*.*:
PORT   STATE SERVICE
80/tcp open  http

Nmap finished: 1 IP address (1 host up) scanned in 0.177 seconds

I think it should use SYN|ACK to get RST for proxy's ipid

ayazero

你发送的第二个SYN包的源地址是虚假的（想想synflood），是Zombie的IP，所以他会回应Zombie而不是你，然后Zombie回应他RST

rootclown

I mean in the first step when we want to get the zombie's ipid, we send him the SYN(in this example to port 80),the port is open ,why he response whit RST? I think he should send me SYN|ACK
  202.4.147.188 is me and 202.4.*.* is the zombie

ayazero

因为第一次发送的不是SYN而是SYN|ACK

rootclown

but tcpdump show ack is 0

04:26:30.257825 IP (tos 0x0, ttl  41, id 54588, offset 0, flags [none], length: 40) 202.4.147.188.33625 >; 202.4.*.*.80: S [tcp sum ok] 2366248689:2366248689(0) ack 0 win 12953

ayazero

实在不行看源代码吧

rootclown

the follow code is from nmap 3.81

1. 
   
2. /* TH_SYN|TH_ACK is what the proxy will really be receiving from
   
3.        the target, and is more likely to get through firewalls.  But
   
4.        TH_SYN allows us to get a nonzero ACK back so we can associate
   
5.        a response with the exact request for timing purposes.  So I
   
6.        think I'll use TH_SYN, although it is a tough call. */
   
7.     /* We can't use decoys 'cause that would screw up the IPIDs */
   
8.     send_tcp_raw(proxy->;rawsd, proxy->;host.v4sourceip(),
   
9.                  proxy->;host.v4hostip(), o.ttl,
   
10.                  o.magic_port + probes_sent + 1, proxy->;probe_port,
    
11.                  sequence_base + probes_sent + 1, 0, TH_SYN|TH_ACK,
    
12.                  ack, NULL, 0, NULL, 0);
    

复制代码

1. 
   
2. /* OK, through experimentation I have found that some hosts *cough*
   
3.    Solaris APPEAR to use simple IPID incrementing, but in reality they
   
4.    assign a new IPID base to each host which connects with them.  This
   
5.    is actually a good idea on several fronts, but it totally
   
6.    frustrates our efforts (which rely on side-channel IPID info
   
7.    leaking to different hosts).  The good news is that we can easily
   
8.    detect the problem by sending some spoofed packets "from" the first
   
9.    target to the zombie and then probing to verify that the proxy IPID
   
10.    changed.  This will also catch the case where the Nmap user is
    
11.    behind an egress filter or other measure that prevents this sort of
    
12.    sp00fery */
    
13.   if (first_target) {
    
14.     for (probes_sent = 0; probes_sent < 4; probes_sent++) {
    
15.       if (probes_sent) usleep(50000);
    
16.       send_tcp_raw(proxy->;rawsd, first_target, proxy->;host.v4hostip(),
    
17.                    o.ttl, o.magic_port, proxy->;probe_port,
    
18.                    sequence_base + probes_sent + 1, 0, TH_SYN|TH_ACK,
    
19.                    ack, NULL, 0, NULL, 0);
    
20. 
    
21.     }
    

复制代码

both use SYN|ACK ,but in reality tcpdump get no ack

this is for zombie's ipid

202.4.147.188.604 82 >; zombie.80: S [tcp sum ok] 569687024:569687024(0) ack 0 win 44661

this is for the second part of the code

04:07:15.924296 IP (tos 0x0, ttl  48, id 19443, offset 0, flags [none], length: 40)        target.60481 >; zombie: S [tcp sum ok] 569687024:569687024(0) ack 0 win 44661

  is this a bug?