Port Scanner tools:
nmap angry IP scanner SuperScan
Port Scanning Methods:
The simplest port scans are ping scans. A ping is an Internet Control Message Protocol (ICMP) echo request – you are looking for any ICMP replies, which indicates that the target is alive. A ping scan is an automated blast of many ICMP echo requests to different targets to see who responds.
Administrators usually disable ping either on the firewall or on the router. It’s quick and easy to turn off this functionality and make it impossible to scout the network this way. However, ping is a good troubleshooting tool, and turning it off makes tracking down network problems a little more difficult.
One of the more common and popular port scanning techniques is the TCP Half-Open port scan, sometimes referred to as SYN scan. It’s a fast and sneaky scan that tries to find potential open ports on the target computer. This scan is fast because it never completes the full TCP 3 way-handshake. The scanner sends a SYN message and just notes the SYN-ACK responses. The scanner doesn’t complete the connection by sending the final ACK: it leaves the target hanging.
Any SYN-ACK responses are possible connections:
- An RST(reset) response means the port is closed, but there is a live computer here. (Blocked Port)
- No responses indicate SYN is filtered on the network. (Stealth Ports)
- Any SYN-ACK replies are a quick way cybercriminals can find the next potential target. (Open Port)
This port scanning technique is basically the same as the TCP Half-Open scan, but instead of leaving the target hanging, the port scanner completes the TCP connection.
It’s not as popular a technique as the TCP Half-Open. First, you have to send one more packet per scan, which increases the amount of noise you are making on the network.* Second, since you complete the connection with the target, you might trip an alarm that the Half-Open scan wouldn’t.
* Technical jargon: “Noisy” programs are programs that send large numbers of packets around the network. You might also hear them referred to as “chatty.”
Sometimes a hacker (whitehat or blackhat) wants to run a port scan that is even quieter and less obvious than the other kinds of scans. Thankfully, TCP includes some flags that allow you to do just that.
When you send a port scan with a packet and the FIN flag, you are sending the packet and not expecting a response. If you do get an RST you can assume that the port is closed. If you get nothing back that indicates the port is open. Firewalls are looking for SYN packets, so FIN packets slip through undetected.
The X-MAS scan sends a packet with the FIN, URG, and PUSH flags, and expects an RST or no response, just like the FIN scan. There isn’t much practical use for this scan, but it does make the packet resemble a Christmas tree, so there is that.
You can also send packets with no flags, called a NULL packet, and the response is either an RST or nothing.
The good thing – for the hacker – about these scans is that they don’t usually show up in logs. More recent Intrusion Detection Software (IDS) and of course WireShark will catch these scans. The bad news is that if the target is a Microsoft OS, you will only see closed ports – but if you do find an open port you can assume that it’s not a Windows machine. The biggest advantage of using these flags is that they can slip past the firewall, which makes the results more reliable.
TCP ACK Scan
TCP ACK Scan sends an ACK packet to the target port in order to determine whether the port is filtered or unfiltered. For unfiltered ports a RST reply packet will be sent for both open and closed ports. Filtered ports will result in either no response or an ICMP destination unreachable reply packet.
This approach is useful to get through stateless firewalls which block incoming connections by blocking incoming SYN packets, but allowing ACK packets to get through to allow internal hosts to communicate with the rest of the internet. TCP ACK will not work with stateful firewalls.
# Sending ACK packet to the target on port 80 0.425238 192.168.1.100 -> 220.127.116.11 TCP 63851 > www [ACK] Seq=0 Ack=0 Win=2048 Len=0 # We have received RST back meaning the port is unfiltered 0.459511 18.104.22.168 -> 192.168.1.100 TCP www > 63851 [RST] Seq=0 Len=0
# Sending ACK packet to the target on port 666 1.728128 192.168.1.100 -> 22.214.171.124 TCP 46985 > 666 [ACK] Seq=0 Ack=0 Win=4096 Len=0 # We have received no response so we try one more time and give up. 1.908035 192.168.1.100 -> 126.96.36.199 TCP 46986 > 666 [ACK] Seq=0 Ack=0 Win=3072 Len=0
NOTE: google.com is sending responses contrary to the expected RST packet for filtered ports (666) and no response for unfiltered ports (80) indicating the use of a stateful firewall.
TCP Window Scan
Originally introduced by Uriel Maimon, TCP Window Scan attempts to deduce whether the port is open or closed based on the Window Size and ttl returned by the target host.
- A positive window size serves as an indicator for an open port while a zero size window indicates a closed port.
- At the same time if the returning packet’s ttl is lower compared to the rest of the received RST packets the port is also likely to be open.
- Although this applies to the majority of machines on the internet, a small number of systems will actually return the reverse — zero for open ports and positive number for closed ports.
It was a lot harder to find systems which would identify open ports with positive window sizes; however, there were plenty of systems which returned RST for closed ports or no response at all indicating a filtered port.
# Sending ACK packet 0.101139 192.168.1.100 -> 192.168.1.104 TCP 33272 > www [ACK] Seq=0 Ack=0 Win=4096 Len=0 # Window size is 0 indicating a closed port 0.101222 192.168.1.104 -> 192.168.1.100 TCP www > 33272 [RST] Seq=0 Len=0
As suggested by Antirez in buqtraq, idle scan relies on the predictability of IPID sequence numbers. It works be continuously sampling the current IPID sequence number on a zombie system while forging packets from a zombie to an actual target.
Zombie systems can be chosen based on their low traffic and predictable IPID sequence numbers. The attack begins when a SYN packet is forged on behalf of a zombie system and sent to the port on a target system. When the target system receives a forged SYN packet it will reply with SYN/ACK to the zombie host. Since zombie host did not expect the incoming SYN/ACK packet, it will generate a RST packet back to the target host thus incrementing its IPID by one. On the other hand, if the port on the target host is closed a RST packet will be sent to the zombie host which will be quietly dropped and will not result in an increment.
At last we have to sample the zombie system once again to determine by how much IPID number was incremented while taking into account that our sample request will result in an additional IPID increase. In our final sample if the zombie’s IPID counter was incremented by two the target port is indeed open; however, if the IPID counter was incremented only by one the target port is closed.
Idlescan offers the ultimate solution in stealthy port scanning since no packets are transmitted between the scanner machine and the target. In addition to stealth capabilities, this technique allows for mapping of trusted machines useful in bypassing firewall rules.
In this packet trace we will use a local machine 192.168.1.104 as a zombie to scan google.com on port 80.
# First we send SYN/ACK multiple times to the zombie machine to confirm IPIDs are indeed predictable # in this case they are because for every response they increment by one (2330,2331,2332,2333) 0.454789 192.168.1.100 192.168.1.104 TCP 53007 > www [SYN, ACK] Seq=0 Ack=0 Win=3072 Len=0 MSS=1460 ID=15461 0.454911 192.168.1.104 192.168.1.100 TCP www > 53007 [RST] Seq=0 Len=0 ID=23330 0.486616 192.168.1.100 192.168.1.104 TCP 53008 > www [SYN, ACK] Seq=0 Ack=0 Win=1024 Len=0 MSS=1460 ID=39449 0.486702 192.168.1.104 192.168.1.100 TCP www > 53008 [RST] Seq=0 Len=0 ID=23331 0.522368 192.168.1.100 192.168.1.104 TCP 53009 > www [SYN, ACK] Seq=0 Ack=0 Win=2048 Len=0 MSS=1460 ID=17487 0.522449 192.168.1.104 192.168.1.100 TCP www > 53009 [RST] Seq=0 Len=0 ID=23332 0.554631 192.168.1.100 192.168.1.104 TCP 53010 > www [SYN, ACK] Seq=0 Ack=0 Win=4096 Len=0 MSS=1460 ID=25705 0.554718 192.168.1.104 192.168.1.100 TCP www > 53010 [RST] Seq=0 Len=0 ID=23333 # Next we forge a packet destined for the target host that appears to be coming from the # zombie machine. 1.082869 192.168.1.104 188.8.131.52 TCP www > www [SYN] Seq=0 Len=0 MSS=1460 ID=38548 # At the same time we will try to sample the current IPID on the zombie which is 2334 1.134610 192.168.1.100 192.168.1.104 TCP 53128 > www [SYN, ACK] Seq=0 Ack=0 Win=4096 Len=0 MSS=1460 ID=34914 1.134696 192.168.1.104 192.168.1.100 TCP www > 53128 [RST] Seq=0 Len=0 ID=23334 # Google.com is now responding to the zombie machine with TCP/ACK attempting to complete a three-way handshake 1.155557 184.108.40.206 192.168.1.104 TCP www > www [SYN, ACK] Seq=0 Ack=1 Win=8190 Len=0 MSS=1460 ID=8303 1.155656 220.127.116.11 192.168.1.104 TCP www > www [SYN, ACK] Seq=0 Ack=1 Win=8190 Len=0 MSS=1460 ID=8303 # Since zombie machine has never sent out the SYN request it responds with RST while # at the same time incrementing its counter by one. 1.155730 192.168.1.104 18.104.22.168 TCP www > www [RST] Seq=1 Len=0 ID=23335 1.155769 192.168.1.104 22.214.171.124 TCP www > www [RST] Seq=1 Len=0 ID=23335 # Once again we sample the current IPID on the zombie machine and determine that it is 2336 meaning that it was # incremented by 2 since our last recorded sample was 2334. This means that the zombie machine has responded # with RST to SYN/ACK coming from an open port on the target machine. 1.270610 192.168.1.100 192.168.1.104 TCP 53185 > www [SYN, ACK] Seq=0 Ack=0 Win=3072 Len=0 MSS=1460 ID=16667 1.270698 192.168.1.104 192.168.1.100 TCP www > 53185 [RST] Seq=0 Len=0 ID=23336
FTP Bounce Scan
FTP Bounce Scan relies on a weakness in FTP protocol which allows requests made to FTP servers to establish other FTP connections on behalf of the client. This allows ftp client to scan other hosts by first bouncing requests from a vulnerable FTP Server using PORT command. For ports on the vulnerable system that are open we will get “Transfer OK” response while for closed ports we will receive “Can’t open data connection” response. This is explained in detail in RFC959:
DATA PORT (PORT)
The argument is a HOST-PORT specification for the data port to be used in data connection. There are defaults for both the user and server data ports, and under normal circumstances this command and its reply are not needed. If this command is used, the argument is the concatenation of a 32-bit internet host address and a 16-bit TCP port address. This address information is broken into 8-bit fields and the value of each field is transmitted as a decimal number (in character string representation). The fields are separated by commas. A port command would be:
where h1 is the high order 8 bits of the internet host address.
In another situation a user might wish to transfer files between two hosts, neither of which is a local host. The user sets up control connections to the two servers and then arranges for a data connection between them. In this manner, control information is passed to the user-PI but data is transferred between the server data transfer processes.
This scanning approach is stealthy although it requires the presence of a vulnerable FTP Server.
In the example below the following machines will be used to simulate FTP Bounce Scan:
- 192.168.1.100 is the scanner
- 192.168.1.250 is a vulnerable FTP Server allowing proxy connections
- 192.168.1.1 is the target system
Below is a sample attack:
# Initial connection is established with a vulnerable FTP Server
0.066851 192.168.1.100 192.168.1.250 TCP 46625 > ftp [SYN] Seq=0 Len=0 MSS=1460 TSV=2166439 TSER=0 WS=2
0.067014 192.168.1.250 192.168.1.100 TCP ftp > 46625 [SYN, ACK] Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
0.067090 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=2166439 TSER=0
# We login into FTP server using anonymous account
0.069071 192.168.1.250 192.168.1.100 FTP Response: 220 Welcome to WinFtp Server.
0.069159 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=1 Ack=32 Win=5840 Len=0 TSV=2166439 TSER=97308
7.066605 192.168.1.100 192.168.1.250 FTP Request: USER anonymous
7.067807 192.168.1.250 192.168.1.100 FTP Response: 331 Password required for anonymous
7.067897 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=17 Ack=69 Win=5840 Len=0 TSV=2168189 TSER=97378
7.068426 192.168.1.100 192.168.1.250 FTP Request: PASS -wwwuser@
7.068577 192.168.1.250 192.168.1.100 FTP Response: 230 Logged on
7.106561 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=33 Ack=84 Win=5840 Len=0 TSV=2168199 TSER=97378
# Now we request a proxy connection to be made for us to the target 192.168.1.1 system
# on port 443 (1,187 translates to 256 + 187 = 443)
9.066781 192.168.1.100 192.168.1.250 FTP Request: PORT 192,168,1,1,1,187
9.068027 192.168.1.250 192.168.1.100 FTP Response: 200 Port command successful
9.068169 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=57 Ack=113 Win=5840 Len=0 TSV=2168689 TSER=97398
9.068700 192.168.1.100 192.168.1.250 FTP Request: LIST
# FTP Server is now attempting to establish a connection to the target system on port 443
9.070580 192.168.1.250 192.168.1.1 TCP 1249 > https [SYN] Seq=0 Len=0 MSS=1460
9.071345 192.168.1.1 192.168.1.250 TCP https > 1249 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
9.071380 192.168.1.250 192.168.1.1 TCP 1249 > https [ACK] Seq=1 Ack=1 Win=17520 Len=0
# Connection was successfully established so FTP attempts to communicate with the target system
9.071491 192.168.1.250 192.168.1.100 FTP Response: 150 Opening data channel for directory list.
9.071581 192.168.1.250 192.168.1.1 SSL Continuation Data
9.071618 192.168.1.250 192.168.1.1 TCP 1249 > https [FIN, ACK] Seq=137 Ack=1 Win=17520 Len=0
9.072143 192.168.1.1 192.168.1.250 TCP https > 1249 [ACK] Seq=1 Ack=137 Win=5840 Len=0
9.074239 192.168.1.1 192.168.1.250 TCP https > 1249 [RST, ACK] Seq=1 Ack=138 Win=5840 Len=0
9.110608 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=63 Ack=159 Win=5840 Len=0 TSV=2168700 TSER=97398
# FTP Server confirms to us that the port is indeed open with the Transfer ok response
9.110674 192.168.1.250 192.168.1.100 FTP Response: 226 Transfer ok
9.110759 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=63 Ack=176 Win=5840 Len=0 TSV=2168700 TSER=97399
# FTP Server is now attempting to establish a connection to the target system on port 442
9.118678 192.168.1.100 192.168.1.250 FTP Request: PORT 192,168,1,1,1,186
9.118953 192.168.1.250 192.168.1.100 FTP Response: 200 Port command successful
9.126485 192.168.1.100 192.168.1.250 FTP Request: LIST
# Connection to the target system failed because we have received RST response
9.127948 192.168.1.250 192.168.1.1 TCP 1250 > 442 [SYN] Seq=0 Len=0 MSS=1460
9.128427 192.168.1.1 192.168.1.250 TCP 442 > 1250 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
9.313303 192.168.1.250 192.168.1.100 TCP ftp > 46625 [ACK] Seq=205 Ack=93 Win=17428 Len=0 TSV=97401 TSER=2168703
9.641438 192.168.1.250 192.168.1.1 TCP 1250 > 442 [SYN] Seq=0 Len=0 MSS=1460
9.641925 192.168.1.1 192.168.1.250 TCP 442 > 1250 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
10.078939 192.168.1.250 192.168.1.1 TCP 1250 > 442 [SYN] Seq=0 Len=0 MSS=1460
10.079476 192.168.1.1 192.168.1.250 TCP 442 > 1250 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
# FTP Server lets us know that it couldn't establish the connection to the closed port
10.080471 192.168.1.250 192.168.1.100 FTP Response: 425 Can't open data connection.
10.118633 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=93 Ack=238 Win=5840 Len=0 TSV=2168952 TSER=97409
10.231082 192.168.1.100 192.168.1.250 TCP 46625 > ftp [FIN, ACK] Seq=93 Ack=238 Win=5840 Len=0 TSV=2168980 TSER=97409
10.231157 192.168.1.250 192.168.1.100 TCP ftp > 46625 [ACK] Seq=238 Ack=94 Win=17428 Len=0 TSV=97410 TSER=2168980
10.231944 192.168.1.250 192.168.1.100 TCP ftp > 46625 [FIN, ACK] Seq=238 Ack=94 Win=17428 Len=0 TSV=97410 TSER=2168980
10.232022 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=94 Ack=239 Win=5840 Len=0 TSV=2168980 TSER=97410
UDP is the other half of our “hallway” and some standard services – DNS, SNMP, DHCP for example – use UDP ports instead of TCP ports. When you run a UDP port scan, you send either an empty packet or a packet that has a different payload per port, depending on your use case.
The trick with a UDP scan is that you will only get a response if the port is closed, which means you might know that there is a computer there. Depending on which port responded you might know that it has DNS or SNMP running, but that’s pretty much it. No response means that either the port is open or it’s filtered, and you might have to run the scan more than once before you figure anything out about the target. You could be waiting a while to get a response that might never come.
One more logical use of a UDP scan is to send a DNS request to UDP port 53 and see if you get a DNS reply. If you do get a reply, you know that there is a DNS server on that computer. A UDP scan can be useful to scout for active services that way, and the nmap port scanner is preconfigured to send requests for many standard services.