Re: Idle scan and predictible ip id

["uzy" <uzy () isecurelabs com>]

Paul Johnston writes: 

> Hi, 
>
> I'm auditing a host that has incremental ip ids. However, I am unable to
> use it as a zombie for an idle scan "cannot be used because it has not
> returned any of our probes". This box does have one open port, but it
> only shows up with connect/syn scan - ack scan shows everything
> filtered. I guess this means it's protected by some kind of stateful
> firewall, and this completely scuppers idle scan. 
>
> My question is: does this firewall mitigate all the risks associated
> with predictible ip ids? 
>
> Thanks, 
>
> Paul

Paul Johnston writes: 

> Hi, 
>
> I'm auditing a host that has incremental ip ids. However, I am unable to
> use it as a zombie for an idle scan "cannot be used because it has not
> returned any of our probes". This box does have one open port, but it
> only shows up with connect/syn scan - ack scan shows everything
> filtered. I guess this means it's protected by some kind of stateful
> firewall, and this completely scuppers idle scan. 
>
> My question is: does this firewall mitigate all the risks associated
> with predictible ip ids? 
>
> Thanks, 
>
> Paul

Hi Paul, 

A manual idle scan (using hping for exemple) is still possible if you send 
SYN packets (or even ICMP echo request if the firewall accept them) to 
retreive the IPID from this host. 

What you won't be able to do if the firewall is stateful and drops SYN/ACK 
is to scan an external host (on the Internet) using this zombie because the 
answers of the scanned host will be dropped by the stateful inspection 
module of the firewall. 

BUT, and that could be interesting, you can scan an INTERNAL host (with a 
public address) if the firewall doesn't check for IP Spoofing. The only 
situation where this is usefull, is when you have two DMZ and rules that 
allow communication between a source machine on DMZ1 (your zombie host that 
you can reach - let's say a reverse proxy) and the destination on DMZ2 (the 
server that you can't directly reach - let's say the protected server). 

I know that servers protected by a reverse-proxy shouldn't have a public 
address, but life is full of unexpected surprises... 

Hoping this was of any interest for you,
Regards,
uZy
http://www.thehackademy.net 


---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help () insecure org . List archive: http://seclists.org