|Idle Scanning and related IPID
Almost four years ago, security researcher Antirez posted
an innovative new TCP port scanning technique. Idlescan, as it has become
known, allows for completely blind port scanning. Attackers can actually
scan a target without sending a single packet to the target from their
own IP address! Instead, a clever side-channel attack allows for the scan
to be bounced off a dumb "zombie" host. Intrusion detection system (IDS)
reports will finger the innocent zombie as the attacker. Besides being
extraordinarily stealthy, this scan type permits mapping out IP-based trust
relationships between machines.
I assumed that a problem of this magnitude would generate an immediate
response and patches from the OS vendors. Unfortunately, many have chosen
to ignore the problem for years. Apparently, they believe this is just
a "theoretical" issue which is not practical to exploit in the real world.
To refute that position, and increase the pressure on vendors to fix the
problem, I have released a robust Idlescan implementation in recent versions
of Nmap. This paper describes
the technique in detail and offers defenses that network administrators,
ISPs, and OS vendors can use to mitigate the vulnerability.
Note that Idle scanning is only one of the security risks posed
by predictable IPID sequence numbers. This paper describes several other
information gathering attacks made possible by this characteristic.
While Idle scanning is rather sophisticated as far as port scanning
methods go, one does not have to be a TCP/IP expert to understand it. You
only need to understand a few basic facts:
By combining these traits, it is possible to scan a target network while
forging your identity so that it looks like an innocent "zombie" machine
did the scanning. This technique is easiest to describe via a diagram.
In the picture below, an attacker, A, is scanning a Target
machine, while blaming the scan on some Zombie, Z. The boxes represent
machines, and the lines represent packets. Brief English descriptions of
the packets are printed on top of the lines, while actual TCP flags and
distinctive packet information is printed below them:
Most network servers listen on TCP ports, such as web servers on port 80
and mail servers on port 25. A port is considered "open" if an application
is listening on the port, otherwise it is closed.
One way to determine whether a port is open is to send a "SYN" (session
establishment) packet to the port. The target machine will send back a
"SYN|ACK" (session request acknowledgment) packet if the port is open,
and a "RST" (Reset) packet if the port is closed.
A machine which receives an unsolicited SYN|ACK packet will respond with
a RST. An unsolicited RST will be ignored.
Every IP packet on the Internet has a "fragment identification" number.
Many operating systems simply increment this number for every packet they
send. So probing for this number can tell an attacker how many packets
have been sent since the last probe.
As demonstrated by the diagram above, the target hosts responds differently
to the Zombie depending on port state. If the probed port is open, the
target sends a SYN|ACK to the Zombie. The Zombie does not expect this SYN|ACK,
so it sends a RST back. By sending the RST, the Zombie causes its IPID
sequence number to increment. The real attacker detects this in step 3.
If the port is closed, the target sends a RST to the Zombie. Zombies ignore
this unsolicited RST packet and do not increment their IPID sequence
The Idlescan techniques offer attackers many advantages over other
popular scan types such as SYN and FIN scans. This is why we recommend
defenses to help protect your network against this attack. Here are
some of the reasons attackers (or legitimate penetration testers) might
utilize this scan method:
Ultimate stealth scan -- There are many techniques people can use
to shield their identity when scanning. Examples include using decoys (nmap
-D) or half-open scanning (nmap -sS). But even these techniques require
an attacker to send some packets to the target from her
real IP address. Idlescan, on the other hand, is completely blind -- no
packets are sent to the target from the true source address.
One upshot of this is that intrusion detection (IDS) systems will
generally light up and send alerts claiming that the zombie machine
has launched a scan against them!
Defeating packet filtering firewalls/routers -- IP source address
filtering is a common security mechanism for limiting machines that may
connect to a sensitive host. For example, a company database server might
only allow connections from the public web server which accesses it. A
home user might only allow ssh (interactive login) connections from his
A more disturbing scenario occurs when some company bigwig demands
that network administrators open a firewall hole so he can access internal
network resources from his home IP address. This can happen when executives
are unwilling or unable to use secure VPN alternatives.
Idle scanning can frequently be used to map out these trust relationship.
The key factor is that Idlescan results list open ports from the zombie
host perspective. So a normal scan against the aforementioned database
server might show no ports open. But performing an Idlescan while using
the web server IP as the zombie could expose the trust relationship by
showing the database-related service ports open.
Mapping out these trust relationships can be very useful to attackers
for prioritizing targets. The web server discussed above may seem mundane
to an attacker until she
notices its special database access.
The first step is to find an appropriate zombie host. The host should
not have much traffic (hence the name Idle Scan) and should offer predictable
IPID values. Printers, Windows boxes, older Linux hosts, FreeBSD, and Mac
OS boxes generally work fine. The latest versions of Linux, Solaris, and
OpenBSD are immune as zombies, but any host can be a target of the scan.
One way to determine host vulnerability is to simply try an Nmap Idle scan.
Nmap will test the zombie and report whether it is reliable.
Performing these scans is quite easy. Simply provide a zombie hostname
to the -sI option and Nmap does the rest. Here is a quick example:
# nmap -P0 -p- -sI kiosk.adobe.com www.riaa.com
Starting nmap V. 3.10ALPHA3 ( www.insecure.org/nmap/ )
Idlescan using zombie kiosk.adobe.com (220.127.116.11:80); Class: Incremental
Interesting ports on 18.104.22.168:
(The 65522 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
25/tcp open smtp
80/tcp open http
111/tcp open sunrpc
135/tcp open loc-srv
443/tcp open https
1027/tcp open IIS
1030/tcp open iad1
2306/tcp open unknown
5631/tcp open pcanywheredata
7937/tcp open unknown
7938/tcp open unknown
36890/tcp open unknown
Nmap run completed -- 1 IP address (1 host up) scanned in 2594.472 seconds
From the scan above, we learn that the RIAA is not very security conscious
(note the open PC Anywhere, portmapper, and Legato nsrexec ports). Since
they apparently have no firewall, it is unlikely that they have an IDS.
But if they do, it will show 'kiosk.adobe.com' as the scan culprit. The
-P0 option prevents Nmap from sending an initial ping to the RIAA
machine. This slows the scan down (less timing info available), but ensures
that no packets are sent to the target from your real IP. The scan took
a long time because all 65535 TCP ports were scanned -- skip the "-p-"
option if you only want well known ports plus 1-1024. Be sure to find your
own zombies -- kiosk is not very reliable and is likely disappear or be
Fortunately, there are several defenses which can be deployed to prevent
most IPID-related attacks:
Internet Service Providers (ISPs)
Configure your firewalls/border routers to deny incoming packets with bogus
source addresses (eg. that appear to come from machines within your network,
reserved IPs like 10.X.X.X or 192.168.X.X, localhost IPs 127.X.X.X, etc.
Any good firewall guide should provide more detailed guidance on these
Stateful firewall rules can also help against these sorts of attacks --
make sure your firewall offers this feature and that it is enabled.
Try to run operating systems with less predictable IP ID sequences, such
as recent versions of OpenBSD, Solaris, or Linux. While these operating
systems are immune from becoming zombies with the current version of Nmap,
they may not stop all IPID-related attacks. Further investigation is needed.
Implement egress filtering to prevent spoofed packets from leaving your
network. This prevents your employees/students from launching some of these
The most important protection ISPs can offer is utilizing egress filtering
to prevent spoofed packets from leaving your networks. This prevents users
from executing many nasty attacks in addition to stopping Idle scanning.
Besides helping the Internet, egress filtering can save you from substantial
costs investigating IP spoofing attacks.
One good approach is to use connection or peer-specific IPID sequences.
Solaris does this, and it severely limits the information attackers can
glean about other connections. Linux 2.4 also uses peer-specific IPID values
(see net/ipv4/inetpeer.c). In addition, Linux 2.4 zeros the IPID fields
in packets with the DF (Don't Fragment) bit set. After all, IP defragmentation
is the only critical use of the ID field. Another approach (used by OpenBSD)
is to randomize the IPID sequence. This is difficult to get right -- be
sure the sequence does not repeat and that individual numbers will not
be used twice in a short period.
I was going to discuss implementation challenges of writing fast, accurate
Idle scanners. But very few of you are doing that, and those who are can
read the source code to Nmap
and other scanners. So I will only outline a few important points. This
section also includes some challenges encountered by tool users.
Performance -- Scanning one port at a time (as in the diagram above)
would be horrendously slow for thousands of ports. Nmap gets around this
by sending up to 100 probes in parallel. Normally, all ports will be closed
and the Zombie IPID will not increment. If Nmap finds that the IPID did
increment, it will narrow down on the open port(s) using a binary search
Non-idle hosts -- Idle scanning works by counting the number of
packets sent by a zombie and assuming those packets are responses to packets
originated by your target. Thus, extraneous packets sent by a non-idle
zombie cause significant confusion. Nmap tries to counter this problem
with probe retransmission and other techniques to detect false results.
For example, Nmap knows something is wrong if it probes 6 ports and the
IPID increases by 10 or 20. Nmap adjusts its timing and parallelism to
compensate for slightly active hosts or dropped packets when they are detected.
However, Nmap will not be reliable with any heavily active zombies. One
technique in dealing with highly active zombies is to send a large number
(dozens or hundreds) of probes to each port. This "brute force" technique
can hide a small amount of "white noise" traffic. Unfortunately, the cost
is significant bandwidth, slow scans, and the possibility of SYN flooding
your target. Thomas Olofsson demonstrated a tool for doing this at his
2001 Black Hat Briefings presentation. His (Powerpoint) presentation slides
are available here.
Egress filtering -- If you cannot spoof packets due to egress filtering
by your ISP, try a new ISP or (for advanced users) IP tunneling. You can
also try bouncing off another machine on your same network (less likely
to be filtered).
Unsuitable zombies -- Some hosts will not work as zombies due to
a clever operating system or substantial traffic. In most cases you can
simply use a different zombie.
|More fun with IPID prediction
While this paper focuses on utilizing predictable IPID sequences for
port scanning, there are many other devious ways to exploit this information.
Here is a brief list:
Traffic Analysis -- Sequential IPID numbers expose the number of
packets sent by a host over a given period. This can be used to estimate
web site traffic, determine when people log on, etc.
Host alias detection -- Sometimes a single host will have multiple
IP addresses or ethernet interfaces. You can often determine which IPs
match a given host by looking for similar IP ID sequence numbers.
Load balancer demultiplexing -- This is almost the reverse of the
technique above. Large sites often use load balancing equipment so that
a single address maps to a small farm of servers. By noting the IPID values,
you can often determine how many machines are behind the load balancer
and which one you are connected with. For example, the "id" fields in the
following hping2 execution make it pretty obvious that beta.search.microsoft.com
is handled by two machines behind a load balancer (22.214.171.124).
# hping2 -c 10 -i 1 -p 80 -S beta.search.microsoft.com.
HPING beta.search.microsoft.com. (eth0 126.96.36.199): S set, 40 headers + 0 data bytes
46 bytes from 188.8.131.52: flags=SA seq=0 ttl=56 id=57645 win=16616 rtt=21.2 ms
46 bytes from 184.108.40.206: flags=SA seq=1 ttl=56 id=57650 win=16616 rtt=21.4 ms
46 bytes from 220.127.116.11: flags=RA seq=2 ttl=56 id=18574 win=0 rtt=21.3 ms
46 bytes from 18.104.22.168: flags=RA seq=3 ttl=56 id=18587 win=0 rtt=21.1 ms
46 bytes from 22.214.171.124: flags=RA seq=4 ttl=56 id=18588 win=0 rtt=21.2 ms
46 bytes from 126.96.36.199: flags=SA seq=5 ttl=56 id=57741 win=16616 rtt=21.2 ms
46 bytes from 188.8.131.52: flags=RA seq=6 ttl=56 id=18589 win=0 rtt=21.2 ms
46 bytes from 184.108.40.206: flags=SA seq=7 ttl=56 id=57742 win=16616 rtt=21.7 ms
46 bytes from 220.127.116.11: flags=SA seq=8 ttl=56 id=57743 win=16616 rtt=21.6 ms
46 bytes from 18.104.22.168: flags=SA seq=9 ttl=56 id=57744 win=16616 rtt=21.3 ms
--- beta.search.microsoft.com. hping statistic ---
10 packets tramitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 21.1/21.3/21.7 ms
OS Detection -- As already discussed, operating systems differ wildly
in how they generate IP ID numbers. Nmap uses this information to help
determine what OS version a remote system is running. More details on this
technique are available here.
Firewall ruleset detection -- The IPID value can help map out firewall
rulesets. Here is a simple example:
This technique can be expanded in many ways -- I could (and may) write
a full paper describing them. Note that all the steps above can be performed
Probe for the IPID of a target machine behind the firewall
Send a ping packet "from" a host inside the firewall to that same target.
Probe for the IPID again. If it increased by 2 (one for the ping reply
and one for the 2nd IPID probe), your spoofed ping got through. Extraneous
traffic can interfere, but retesting can ensure accuracy.
Nmap, which now includes Idlescan, is available at http://www.insecure.org/nmap/
The basic IPID scan technique was invented by Antirez (Salvatore Sanfilippo).
His home page is at http://www.kyuzz.org/antirez/.
Antirez also developed the excellent Hping
tool, which is tremendously useful for low-level IPID testing.
a proof-of-concept IPID scanner and coined the name "idlescan" in 1999.
The URLs no longer work, but you can probably find his implementation via
Google or Packetstorm if you are interested.
Thomas Olofsson wrote and demonstrated an IPID scanning tool at the
2001 Black Hat Briefings. His (Powerpoint) presentation slides are available
and give a good overview of the basic technique. As mentioned earlier in
this paper, his tool may be preferable to Nmap in cases where the "Idle
zombie host" is not really Idle. Unfortunately, I do not have a working
URL for his tool.