首页 > 学技术 > 技术网文 > 网络安全 > 正文

[精华] a question about idle scan


来源 chinaunix.net 酷勤网整理

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 
 /* TH_SYN|TH_ACK is what the proxy will really be receiving from

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

  who can tell me why ?thanks



 ayazero 回复于:2005-08-07 22:50:36

这种扫描方式最早是在上大二的时候在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 回复于:2005-08-07 23:00:13

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

不知道我的解释是否清楚


 rootclown 回复于:2005-08-08 08:48:52

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 回复于:2005-08-08 09:20:42

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


 rootclown 回复于:2005-08-08 09:45:00

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 回复于:2005-08-08 10:03:17

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


 rootclown 回复于:2005-08-08 10:11:10

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) [color=darkblue]ack 0[/color] win 12953 



 ayazero 回复于:2005-08-08 10:21:39

实在不行看源代码吧


 rootclown 回复于:2005-08-08 11:15:25

the follow code is from nmap 3.81 

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



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

    }

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?


 oppenheimar 回复于:2005-08-09 01:07:06

如果中间系统不是一次增加IPID的话,这种扫面方式是有问题的。比如说openBSD使用随机的IPID,linux对于开启DF的包使用IPID0,而且不能保证这个过程中傀儡主机不和其他的主机交换数据报,因为IPID是全局性的。


 oppenheimar 回复于:2005-08-09 01:28:46

我大概知道楼主的意思了,是说第一步探测IPID的时候,使用的是SYN包而不是SYN/ACK包,我想不管怎么样,IPID探测的目的已经达到了。虽然不是完全依照idlescan的原理,但是目的达到了。就像不同的OS拥有不同的TCP/IP协议栈实践一样,所以可以通过fingerprinting技术达到探测OS的目的。
具体为什么作者要这么做,我想SYN实际上更加容易通过状态防火墙达到zonbie,但是不是这种情况也很难说。
要是bug的话,可以和作者联系一下。




原文链接:http://bbs.chinaunix.net/viewthread.php?tid=589871
转载请注明作者名及原文出处



收藏本页到: