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的话,可以和作者联系一下。
|