TCP SYN Scanning

The purpose of this post is to dissect what a TCP SYN scan is by digging into the TCP protocol. The notion of TCP SYN scans have been around for many years. It is something that a network engineer should understand. Countermeasures can be deployed against this type of attack enmasse although reconnaissance missions can be harder to detect.

Dig deeper

Standard TCP handshake

A TCP connection established against a remote device would adhere to the following process. Being three phased, the first would be the source sends a TCP packet with the SYN flag set.

SYN flag in TCP flags field

The second phase would be the remote site responding with a TCP packet with the SYN and ACK flags set. That is if the correct port is open and the service is running.

SYN ACK flags set in TCP Flags field

The third phase is the source sending a TCP packet with the ACK flag on. The connection is now open.

ACK flag set in TCP Flag field

In the second phase, if the port is closed and the service is not running, a TCP packet with the RST flag set is sent back.

Reset flat set in TCP Flag field

Note – My example has assumed TCP ack numbers, sequence numbers are all in corresponding order – Oh there is so much magic you can weave with packet manipulation

So what is a TCP SYN scan?

Known by many names, SYN-scanning, or Half Open scanning is where the full TCP connection is never made. SYN-scanning sends the first packet only, the one marked with the SYN flag. It waits for either a RST, ACK or SYN,ACK response. If a RST,ACK response comes in there is nothing is running on the port and issues a RST. If a SYN,ACK response is received, a service is known to be running on the port.

The benefit of TCP SYN scanning is the fact that most logging applications do not look to log TCP RST by default. They generally create a log entry in the application/device/server when the final ACK comes from the client device. Due to the fact that this ACK never comes but a RST, it can go unnoticed if a scan is taken place.

NMAP command

Understanding what you are typing into nmap and programs like it define the difference between someone who knows what they are doing and a script kiddy pushing buttons. Being someone who knows what the are doing, you clear understand how a command affects a scan or a sweep, including how it modifies or manipulates packets.

The command in nmap is simple and the results effective.

nmap -sS 192.168.15.1

Very easy. This will perform a scan across the specified device. Remember that this can be combined with a range and the wildcard * can be used on any octet.

Now being on OSX, I have had to apply super user privileges to the scan so sudo is required before the nmap statement. The output we get very quickly identifies services running. I have enabled some services for demonstration purposes. If this was a security audit you may get some comments regarding the use of http.

Now I like the feature of nmap where you can scan the top 10 protocols used. This is information Fydor, creator of nmap, has collected from nmap submissions.

dreamspike:~ pandom_$ sudo nmap -top-ports 25 -sS 192.168.15.1

So it will focus on all of the top 25 ports listed in that version of nmap you use. You can see how you can add cumulative arguments to achieve very targeted results. If you think this is cool it is only the beginning.

Protection?

Firewall systems understand the state of TCP connections. The also have the ability to reject stealth scan packets like what we have done above. Proxy and Stateful Packet Inspection beat these attacks. It would be advised that if you do notice oddities or to watch the logs and track down the machine. Many attacks or reconnaissance missions have been performed behind enemy lines.

Remember that there are devices and options designed to detect this. A simple IDS will note the number of RSTs coming from a host. If setup, it will email an administrator and information could be logged or captured.

Disclaimer

Performing a nmap TCP SYN Scans against devices that are not yours or that you do not have explicit written permission to test could be illegal in your or the devices country/ies. I (Anthony Burke, networkinferno.net) will not be held accountable or liable for any damages that occur.

3 thoughts on “TCP SYN Scanning”

Welcome. Once you get the basics down and learn Junos you will be able to make routing instances. Then you will be able to create some good topologies to do all routing protocols on and more. I plan to do Sophos and UTM, VPN, to just name a few.