Why are Hacker's "Scanning" Ports?

Port scanning identifies "open doors" on a computer, and is very useful for understanding the nature of a network and the possible points of exploitation. When performing a port scan, there are many types of scans to choose from. Each type provides different information, and each has its strengths and weaknesses. You may have already heard the names of some types of scans (e.g. "SYN Scan" or "Connect Scan"), but how much do you really know about how these scans work? To help you gain a better understanding of port scanning in general,

[bi]I outlined the main types of scans here:[/bi]
[ul]
[li]TCP SYN Scan [/li]
This is the typical "modern" way of scanning a host for open TCP ports. It sends a TCP SYN packet to a port. A SYN packet is the first packet sent in a TCP connection. The purpose of this is to see if the remote host responds on this port without the requirement of initiating a full connection. It yields the same information without the overhead of a full connection, and offers a higher degree of control over the scan rate and content. It also offers the ability to differentiate between filtered and closed ports.

[li]TCP Connect Scan[/li]

This is the traditional way of looking for open ports. It involves using the native network API for a system to attempt to establish a connection with each port on the remote host. If the connection succeeds, the port is considered open. If it fails, the port is considered closed. This method is slower and more resource intensive than a SYN scan, but will work in diverse situations, and often is used as a fallback if no other type of scan is available.

[li]TCP FIN Scan[/li]
This scan type uses specially crafted TCP packets with a FIN flag set, instead of a SYN flag. This type of packet normally occurs when closing a connection. Sending this type of packet to a machine (that you havenÆt yet sent a corresponding SYN to) should result in a machine response of RST packet if the port is closed or nothing is the port is open. Unfortunately, many TCP/IP implementations are broken and do not follow standard RFC context. This means that this type of scan may not give correct results against certain types of hosts, such as Windows machines.

[li]TCP XMAS Scan [/li]
This type of scan is similar to the FIN and SYN scan, but instead of a SYN flag or a FIN flag, it uses a sequence of flags known as a "Christmas tree packet". This is a combination of FIN, URG, and PUSH flags on a packet to attempt to achieve the same results as a FIN scan. This may bypass certain detection mechanisms and firewalls that a normal FIN scan may not. Unfortunately, this has the same problems as a regular FIN scan and may often not give the correct results.

[li]TCP NULL Scan [/li]
Again, this type of scan is just a change in the flags on each packet sent to the remote host. In this case, all flags are dropped completely. This is not actually a legitimate packet as designed by the RFC, so some firewalls may drop this before it reaches the target machine. This is a somewhat ineffectual scan type, and is often used when no other type yields useful information.

[li]UDP Scan [/li]
This type of scan focuses on the UDP protocol. Unlike the TCP protocol, UDP requires no connection overhead. This makes the protocol a more lightweight protocol, but causes issues with scanning as there is no required response to a particular packet being sent, as in the case of SYN scanning. Typically, there is an ICMP message in response to a UDP packet sent to a closed port. Again, RFC issues with some IP stacks can forego this. Currently, research is being done to achieve a better success rate for this type of scanning and to improve its reliability.
[/ul]
As discussed, there are numerous ways to scan a remote system to find out which ports have services listening on them. This is helpful in a security context, as it attempts to provide information that you may not otherwise be able to get.