Port numbers are 16-bit unsigned numbers and can be broadly classified into three categories. Port 0-1023 is "well known ports", 1024 - 49151 are "registered ports" and 49152 - 65535 is "dynamic or private ports".
One problem with port scanning is that it is effortlessly logged by the services listening at the scanned ports. This is because they detect an incoming connection, but do not receive any data, thereby generating an application error log.
To scan UDP ports, an empty UDP datagram is sent to the port. If the port is listening, the services will send back an error message or ignore the incoming datagram. If the port is closed, the operating system send back "ICMP Port Unreachable" (Type 3) message.
Port scanning can be broadly classified into:
- Open scan
- Half-open scan
- Stealth scan
- Sweeps
- Misc
How does an attacker decide to use which scan? It depends on the information gathering during reconnaissance regarding the type of network topology, IDS and other logging feature present on the system.
Open Scan
Open scan / TCP connect scan also known as vanilla scan where a full connection is opened to the target system by a three-way TCP/IP handshake. Therefore, it is easiest to be detected and blocked on the network. However the information gathering using open scan is usually the most.
When the port is open, the client sends a SYN flag, the server replies a SYN+ACK flag, which is acknowledged back with an ACK flag by client. Once the handshaking is completed, the connection is terminated by the client. This confirm an open port.
When the port is closed or "not listening" the server response a RST+ACK flag, which is acknowledged back with an RST flag by client, and then the connection is closed.
The disadvantage of this scan technique is that the attacker cannot spoof his identity as spoofing would require sending a correct sequence number as well as setting the appropriate return flags to setup data connection. Moreover, most stately IDS and firewall detect and log this scan, exposing both the attempt and the attacker's IP. The advantage is fast accurate scan that require no additional privilege.
Half-Open Scan
In half-open scan, a complete TCP connection is not established. Instead as soon as the server acknowledge with a SYN+ACK response, the client tears down the connection by sending RST flag. This way, the attacker detect an open port and not establish full connection.
However, some sophisticated IDS and firewall can detect a SYN packet from the void and prevent such scan. Besides, this scan require attacker to make a customer IP packet which in turn requires access to SOCK_RAW (getprotbyname('raw') under most system) or /dev/bpf (Berkeley packet filter), /dev/nit (Sun network interface tap). This requires priviliege access.
Stealth Scan
Initially half open scans were considered stealth, however as IDS software evolved, these scan were easily logged. Now, stealth scan refers to the type of scan where packets are flagged with a particular set of flags other than SYN, or a combination of flags, no flag set, with all flag set, appearing as normal traffic, using fragmented packet or avoiding filtering devices by any other means. All these techniques resort to inverse mapping to determine open ports.
- SYN|ACK Scan
Client sends a SYN+ACK flag to the target. For a closed port, server will reply a RST response while an open port will not reply. This is because the TCP protocol requires a SYN flag to initiate the connection. This scan may generate certain amount of false positives. For instance, packets dropped by filtering devices, network traffic, timeouts etc can give a wrong inference of an open port while the port may or may not be open. However this is a fast scan that avoid three-way handshake.
- FIN Scan
Similar to SNY|ACK scan, instead a FIN flag is sent to the target. The closed ports are required to reply to the probe packet with RST, while open ports must ignore the packet in question (see RFC 793 pp 64). This scan attempt to exploit vulnerabilities in BSD code. Since most OS are based on BSD or derived from BSD, this was a scan that can return good result. However, most OS applied patches to correct the problem, still there remains a possibility that the attacker may come across one where these patches have not be applied.
- ACK Scan
This scan was first described by Uriel Maimon in this article "TCP Port Stealth Scanning". The scan take advantage of the IP routing function to deduce the state of the port from the TTL value. This is based on the fact that IP function is a routing function. Therefore TTL value will be decremented by on by an interface when the IP packet passes through it.
- NULL Scan
In NULL scan, the packet is sent without any flag set. This takes advantage of RFC 793 as the RFC does not specify how the system should respond. Most UNIX and UNIX related system respond with a RST (if the port is open) to close the connection. However, Microsoft's implementation does not abide with this standard and reacts differently to such scan. An attacker can use this to differentiate between a Windows machine and others by collaborating with other scan results. For example, if -sF, -sX or -sN scan shows all ports are closed, but a SYN (-sS) scan shows ports are opened, the attacker can infer that he is scanning a windows machine. This is not an exclusive property though, as this behavior is also shown by Cisco, BSDI, HP/UX, MVS and IRIX. Also note that the reserved bits (RES1, RES2) do not affect the result of any scan. Therefore this scan will work only with UNIX and related systems.
- Xmas Scan
In Xmas scan, all flags are set. All the available flags in the TCP header are set (ACK, FIN, RST, SYN, URG, PSH) to give the scan an ornamental look. This scan will work on UNIX and related systems and cause the kernel to drop the packet if the receiving port is open.
- TCP Fragmenting
This approach is evolved from the need to avoid false positive arising from other scans due to packet filtering device. For any transmission, a minimally allowable fragmented TCP header must contain a destination and source port for the first packet (8 octet, 64 bit), the initialized flags in the next, which allows the remote host to reassemble the packet upon receipt through an internet protocol module that identifies the fragmented packets by the field equivalent values of source, destination, protocol and identification.
The scan works by splitting the TCP header into small fragments and transmitting it over the network. However, there is a possibility that IP reassembly on the server-side may result in unpredictable and abnormal results - such as fragmentation of the data in the IP header. Some hosts may be incapable of parsing and reassembling the fragmented packets and thus may cause crashes, reboots or even network device monitoring dumps.
Some firewalls may have rulesets that block IP fragmentation queues in the kernel (like the CONFIG_IP_ALWAYS_DEFRAG option in the Linux kernel) - though this is not widely implemented due to the adverse affect on performance. Since several intrusion detection systems use signature-based mechanisms to signify scanning attempts based on IP and/or the TCP header, fragmentation is often able to evade this type of packet filtering and detection. There is a high possibility of causing network problems on the target network.
Sweep
This scan is discussed in previous post "Ping Sweep".
Miscellaneous- FTP bounce
This scan takes advantage of the FTP servers with read/write access. The advantage of this scan can be both anonymity and accessibility. Suppose the target network allows FTP data transfer from only its recognized partners. An attacker might discover a service business partner who has a FTP service running with a world-writable directory that any anonymous user can drop files into and read them back from. It could even be the ISP hosting services on its FTP server. The attacker, who has a FTP server and able to run in passive mode, logs in anonymously to the legitimate server and issues instructions for scanning or accessing the target server through a series of FTP commands. He may choose to make this into a batch file and execute it from the legitimate server to avoid detection.
If a connection is established as a means of active data transfer processing (DTP), the client knows a port is open, with a 150 and 226 response issued by the server. If the transfer fails a 425 error will be generated with a refused build data message. The PASV listener connection can be opened on any machine that grants a file write access to the attacker and used to bounce the scan attack for anonymity. It does not even have to be an FTP server, any utility that will listen on a known TCP port and read raw data from it into a file will do.
Often these scan are executed as batch files padded with junk so that the TCP windows are full and the connection stay alive long enough for the attacker to execute this commands. Fingerprinting the OS scan help determine the TCP window size and allow the attacker to pad this commands for further access accordingly.
This scan is hard to trace, permits access to local network and evades firewalls. However, most FTP servers have patched this vulnerability by adopting countermeasures such as preventing third party connection and disallowing listing of restricted ports. Another measure adopted has been restrict write access. - UDP scan
The disadvantage to the attacker is that UDP is a connectionless protocol and unlike TCP does not retransmit packet if they are lost or dropped on the network. Moreover, it is easily detected and unreliable (false positive). Linux kernel limit ICMP error message rates with destination unreachable set to 80 per 4 seconds, thereafter implmenting a 1/4 second penalty if the count is exceeded. This makes the scan slow and moreover the scan requires root access. However it avoids TCP based IDS and can scan non-TCP ports.
Ethical Hacker and Scanning ToolsThe most important is knowledge itself. The result of a scanner can be misleading if the ethical hacker does not have good knowledge of common vulnerabilities. Relying solely on the scanning tool to all threats is not practical as the author of the vulnerability check may have written it incorrectly. It is also likely that it was created in a controlled environment and might not work as well in the open.
Besides, performing exhaustive scan against the system in a large enterprise is usually not feasible due to network constraints, stability of the backbone and scanned systems. Another view point is that scanner does not have an internal view of the host audited and can miss critical misconfiguration that result in an insecure setup, but appear "secure" from the outside with automation.
