Since it seems to be in question, I'd like to address third party stealth scanning in more detail as some folks might not be fully aware of it's capabilities. The basic technique goes as follows, our bad guy MAL wants to scan his target ADENA for an open TCP port 22. He doesn't want any record of his connecting, so he finds a 'quiet' (meaning little or no traffic going to or from) computer preferably on a dial-up or DSL, we'll call this machine PATSY. His plan is to get relative sequence numbers from PATSY while spoofing TCP SYN packets to ADENA's TCP port 22 with PATSY as the source address. If 22 is open ADENA will reply to PATSY and MAL will notice a spike in MAL relative sequence numbers. MAL is pretty clever, so he not only spoofs packets from PATSY but also a random mix of other spoofed source addresses. MAL gets his information and his IP never talks to ADENA. Using hping as an example: First find (a) PATSY, a nice Windows machine idling on a DSL line is the perfect mark. --------------------------------------------------------------------- [root@foo]# hping -r PATSY HPING PATSY (eth0 PATSY): NO FLAGS are set, 40 headers + 0 data bytes len=46 ip=PATSY flags=RA seq=0 ttl=128 id=63510 win=0 rtt=10.2 ms len=46 ip=PATSY flags=RA seq=1 ttl=128 id=+256 win=0 rtt=0.7 ms len=46 ip=PATSY flags=RA seq=2 ttl=128 id=+256 win=0 rtt=0.6 ms len=46 ip=PATSY flags=RA seq=3 ttl=128 id=+256 win=0 rtt=0.6 ms len=46 ip=PATSY flags=RA seq=4 ttl=128 id=+256 win=0 rtt=0.7 ms --------------------------------------------------------------------- You'll notice the 'id+=256' field indicates steady increments in sequence numbers (Viva la Windows). Now spoof the source address of the scan and watch relative sequence numbers 'id=+'. --------------------------------------------------------------------- [root@foo]# hping ADENA -a PATSY -S -p 22 --------------------------------------------------------------------- Nothing comes directly back because the source address is spoofed, but look at our session pinging PATSY. See the spike in the id field from 256 to 512? Port 22 is open on ADENA. No spike means closed a closed port. --------------------------------------------------------------------- len=46 ip=PATSY flags=RA seq=51 ttl=128 id=+256 win=0 rtt=0.7 ms len=46 ip=PATSY flags=RA seq=52 ttl=128 id=+256 win=0 rtt=0.7 ms -> len=46 ip=PATSY flags=RA seq=53 ttl=128 id=+512 win=0 rtt=0.7 ms <- -> len=46 ip=PATSY flags=RA seq=54 ttl=128 id=+512 win=0 rtt=0.7 ms <- -> len=46 ip=PATSY flags=RA seq=55 ttl=128 id=+512 win=0 rtt=0.7 ms <- -> len=46 ip=PATSY flags=RA seq=56 ttl=128 id=+512 win=0 rtt=0.7 ms <- len=46 ip=PATSY flags=RA seq=57 ttl=128 id=+256 win=0 rtt=0.7 ms --------------------------------------------------------------------- When you add the possibility that the machines are half a world apart, tracking becomes, well difficult even if you're an optimist. The bottom line is, the attacker might not be in the group of IPs you observe scanning you. For a more detailed treatment of this technique see: http://rr.sans.org/audit/hping2.php --Gideon On Mon, 7 Jan 2002, Paul M. Tiedemann wrote: /* A couple of words on spoofing should be mentioned. Spoofing is almost /* always associated with dos attacks because the very act of spoofing means /* that they will not be receiving any packets back to their real ip address. /* I know there are ways to use spoofing to obscure the scanning machine but /* usually one of the ip addresses is the offender. If you think the process /* through with port scanning it just doesn't make sense that the originating /* machine would not wish to receive any information about what ports are open /* on your machine. That being said I think that if you are actually being /* port scanned you will find that one of the ip addresses you will see is the /* originating machine. ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Tue Jan 08 2002 - 11:43:34 PST