Common Basic Port Scanning Techniques

Image

In the world of information security, port scanning is a vital part. Enterprises, organizations or regular users use port scans to probe systems for open ports and their respective services. If you think of a computer as a hallway of doors, port scanning can be compared with walking through the hallway looking for open doors. Penetration testers like myself use this information to find entry ways into the computer. Port scanning is part of the “active reconnaissance” phase, a vital part of any penetration test. I aim to explain to you a few of the basic concepts of port scanning.

PING SCAN

Ping Scans are used to sweep a whole network block or a single target to check to see if the target is alive. It sends an ICMP echo request to the target – if the response is an ICMP reply, then you know the target is alive.

However, it is increasingly becoming more common that ICMP pings are being blocked by firewalls and routers that you will likely have to resort to other methods to accurately tell if the target is alive.

TCP Half-Open

This is probably the most common type of port scan. This is a relatively quick scan that can potentially scan thousands of ports per second. It works this way because it does not complete the TCP handshake process. It simply sends a packet with the SYN flag set and waits for the SYN-ACK from the target and does not complete the connection.

When you initiate a TCP connection you first send a packet with the SYN (synchronize) flag set to the destination. The destination then acknowledges this synchronize request with a packet with the SYN-ACK (synchronize-acknowledge) flag set. Finally, the sender acknowledges that it got the SYN-ACK response packet by sending the destination a packet with the ACK flag set.

Now, a connection is established. By not sending the final ACK packet to the target after receiving a SYN-ACK, a connection is not established; however, you now know if the target/port is available and listening. If you receive a RST (reset) packet back from the target, then you know that the target is active; however, the port is closed. If no response is received and you know that the target is alive, then the port is considered filtered.

TCP CONNECT

This is essentially the same as the half-open scan above but instead, we finish the handshake process and establish a connection by sending the final ACK packet. This is a much slower means of port scanning as it takes more packets to finish.

UDP

UDP scans are most common to detect DNS, SNMP and DHCP services. UDP scans work by sending a packet, which is usually empty. This can be changed or even set to a random payload for each port. If the target responds with an ICMP unreachable error (type 3, code 3) packet, you know the port is considered closed.

If it responds with an ICMP unreachable error packet with other codes, the packet is considered filtered. If no response is received at all, the port is considered open or filtered. The reason why it might be filtered is that packet filters might be in use that are blocking the communication. Version enumeration could very well help in knowing if packet filters are involved.

The problem with using any communication with UDP is that it is unreliable – it has no way of creating an established connection or synchronizing the packets like TCP does. For this reason, UDP scans are typically slow. Because you are waiting for a packet that may never come, nor do you have any real way of telling if the packet even got there in the first place, you might have to send numerous packets then wait to make sure a port is considered open or filtered.

STEALTH SCANNING – NULL, FIN, X-MAS

These scan types are known as stealth scanning because you are crafting the packets flags in such a way that you are trying to induce some type of response from the target without actually going through the handshaking process and establishing a connection. The FIN scan sends a packet that would never occur in the real world. It sends a packet with the FIN flag set without first establishing a connection with the target.

If a RST (reset) packet is received back from the target due to the way the RFC is written, the port is considered closed. If no packet is received at all, the port is considered open. The X-MAS tree scan gets its name because it “lights up the packet light a Christmas tree.” It sets a TCP packet with URG, PUSH, FIN flags and fires it at the target. Again, if no packet is received, the port is considered open and if a RST packet is received, the port is considered closed.

NULL scans also send a packet that should never occur in the real world. It does not set any flags on the TCP packet and fires it at the target. Like above, a RST packet response means it's a closed port – no response is considered an open port. These scans are great because they are unlikely to appear in logs and are some of the most minimal port scanning techniques available.

The bad thing is, though, the way Microsoft implements the TCP/IP stack, all ports will be considered closed. However, if you DO receive an open port, you now know that the target is NOT running a Microsoft Operating System. As a conclusion, port scanning is one of the first steps in any vulnerability analysis or penetration test. Knowing which ports are open is the beginning of being able to actively communicate with the target.

One of the best port scanners available is www.nmap.org. Nmap is an incredibly powerful and versatile port scanner with its own scripting engine. I can’t stress enough how much nmap comes in handy and is used professionally. I hope you have found this information to be useful.  

Image

About the Author:

Tyler Wall is a security fanatic.  Employed as a Senior Security Engineer by day and born with a natural curiosity for anything and everything that spills over into everyday life by form of his many (mis)adventures. He holds numerous security certifications and degrees and describes himself a catalyst for positive change.

Editor’s Note: The opinions expressed in this and other guest author articles are solely those of the contributor and do not necessarily reflect those of Tripwire.