In network security, why do we care about knowing incomplete TCP handshake sessions? Is there a security implication behind this?
Answer: by intentionally sending the various parts of the 3 way handshake - sometimes in order, sometimes not & other times with additional flags set - an attacker can scan an IP and Port and determine if that particular port is open or closed.
We care about knowing that this is happening because they are all about an attacker gaining information on your network. However most of the time a log entry is not created for TCP communications until the handshake is completed - so if its interupted somewhere then a log may not be created and an attacker go unnoticed.
Explained: when scanning an IP range to map out a network, there are a number of different types of scans. They are different based on how they initialise the handshake - some dont even initialise it. The response provided by the target indicates if the port specified is open or closed, based on deductive reasoning.
Full Scan The scanner sends a standard SYN request with a port number. The type of response indicates whether the port is open. If a 'reset' request is received in response to the scan, the attacker knows the port is closed.
Half-Open Scan / Stealth Scan (see Vulnerability description at link)
The attacker sends the initial SYN and watches for a SYN/ACK request, however rather than sending the final ACK, sends a RST (reset) which interupts the connection part way. In this scan the information the device sends back is still used to decide if a port is open, but by terminating the connection part-way is avoiding a lot of logging that would make the attack obvious to an administrator.
Xmas Tree Scans
Attacker sends a FIN/URG/PUSH and waits to hear back. RST indicates a port closed, whereas receiving no information back indicates the port is open. Requires that the target machine is compliant with RFC 793 which eliminates Windows machines as possible targets.
Attacker simply sends a FIN to mimic terminating a connection. If the machine doesn't know how to respond and gives none, then the port is open. If the machine sends a RST/ACK then the port is closed. Again, doesn't work for Windows.
Attacker sends a TCP packet with NO FLAG, which is known as NULL. It's sending nothing at all. If no response is received then the port is open. If a RST/ACK is received then port is closed. This only works on Unix based systems.
Note: Above explanations are taken from the Ethical Hacking course on Pluralsight by Dale Meredith. I've provided small summaries. However because Pluralsight is behind a pay-wall I've provided URLs to other explanations of each scan.
All of the above scans can be automated over an IP range using tools such as Nmap. Some of them however are particularly noisy (Full Scan) and will make it very obvious someone is scanning the system. Either way, by using the TCP handshake in a way that it wasn't intended (most of the time) an attacker can work out open ports, and begin to work out where vulnerabilities in that system may be.
Many scanners which are used to detect open ports use incomplete or bad TCP handshakes. Sometimes they are also used in DDOS attacks, but if that were true you would have 100's to 1000's a second.
There are SYN scans,xmas scans, and more. They are doing forms of recon on your IP addresses.
I get scanned all the time, like 100+ a day.
There's a couple of possible answers to this - depending upon the context of your question:
- TCP is a connection oriented protocol, with 3 distinct parts (SYN, SYN/ACK, ACK).
a. One device sends a SYN packet to ask/infer if the receiving device is open for new connection. b. Once a receiving device receives a SYN packet from the client, it responds and returns a confirmation receipt known as a SYN/ACK packet to indicate it has successfully set up a connection capable of receiving additional packets. c. Finally, the originating device signals its acceptance of the SYN/ACK response and signals its intention to send more packets by sending an ACK packet.
If the two connected devices detect that some part of the handshake hasn't been completed an inference can be made about the status of the connection. For example if no SYN/ACK is received by the initiating device, it can be inferred that the receiving device failed in its effort to establish resources for a connection.
So basically both devices infer the connection hasn't been established correctly.
- Not only can the participating devices infer something from how the handshake progresses, 3rd party devices observing the handshake can too. For example, many Firewalls look for particular parts of the connection to know when two IP address have established a connection.
What happens when a single IP sends a number of SYN/ACK or ACK packets to IPs for which no SYN packet was first seen? This could be an attacker probing Firewall capability since a SYN/ACK packet is 'suppose' to follow a SYN packet.
Abuse of the normal handshake by sending unexpected packets suggests something out of the norm.
To answer you then: Analysis of incomplete TCP handshakes reveal much about what is going on over the network in non-normal situations between two hosts.
Because the incomplete TCP-handshake itself is an implication of the vulnerability in the protcol. It can then be exploated to trick a port to reveal information about itself.