Scanning Redux: TCP and UDP

So we wrap up the blog postings on scanning with TCP and UDP scans. Now again I stress that there are other types of scans out there, I just want to highlight some of them.

TCP

TCP stands for Transfer Control Protocol. This is the powerhouse of protocols, many applications ride this bad boy straight to your computer. Example-- this web page! Also your email clients and file transfer programs also use TCP. Why? Because TCP is reliable, it sets up a connection between two hosts... making sure both know what is going on (who is sending? who is receiving? did you receive that? Hey I received the packet, keep sending.. Oh fizzle sticks I never received this one packet, please resend! K, thx bai!) 

How does TCP do this? Well with the ever classic 3-way handshake. You can definitely check out the WIKI page for the official description. I liken the 3-way handshake to the best relationship ever, before speaking to his/her mate, the one partner will get the others attention (SYN), the other will then look at him/her to confirm they heard them (SYN-ACK), and then once he/she has their attention, will start to speak (ACK).

I am going to assume people understand TCP enough to go thru the scanning options, if not check out the documentation on there on the interwebs.I will post up from the SANS Cheat Sheet I talked about last post the TCP packet header. You can grab the whole cheat sheet here.

TCP Header

The Flag Byte of the TCP Header

TCP Syn Scan: This is when you start the 3 way handshake described earlier, except you never get past the 2nd step.  Nmap here shows the scanning machine sending a RST, cancelling the connection setup (else the port could be sitting there for while waiting for the ACK... what a waste!)

TCP Syn Scan - 192.168.0.10 responded with a SYN-ACK, we have an open port!

Let's take a closer look at the flag bit...

Flag Bits of a TCP SYN Packet

So for those who count in binary we see this byte is 00000010, which is decimal 2. Cool, so when that bit is 'flipped' (or switched to '1') what does that mean? Looking at the SANS cheat sheet, we see that the 'SYN' bit is set to the 2nd bit... or 00000010. Wait, that's what it says! It must mean the SYN flag is on! Hoorah!

So riddle this Mr./Miss Smarty Pants, what would a SYN-ACK flag bit be set to? Well lets go back to the sheet- it says the ACK flag is set on the 5th bit. So if we flipped both SYN and ACK on, it would be 00010010, which is what in decimal? Whip out those calculators or pencils! The answer is 18 in decimal, ah but we are in hex mode here- which is the power of 16! Whaa this is getting complicated! Here go here for an example. Ok so dividing by 16 ::hours pass:: so that gets us the hex value of 0x12! And just to prove it, here is the flag byte of a SYN-ACK packet.

Flag Bits of a TCP SYN-ACK  packet

TCP Connect Scan: This is exactly what is sounds like, the full 3 way handshake is done to determine open ports. This scan is slower than the TCP Syn scan (this makes sense, sometimes you have wait ages to get your partner to listen and then start to speak!), and now you have a full connection, it has a better chance of being logged somewhere on the victim network. Not good if you are going for stealth. However, if you are being hampered by firewalls, this could be the way to go, as many devices could be between you and your intended victim, hampering your results.

TCP Christmas Scan: Sounds festive right? This scan flips the FIN, PUSH, and URG flags ("lighting up like a Christmas tree").This is effective against Linux hosts but not Windows machines (remember how I said different OS respond to packets differently?) This is going off RFC 793, Page 65:

“if the [destination] port state is CLOSED .... an incoming segment not containing a RST causes a RST to be sent in response.”

 So these are a bit sneaky and can evade some firewalls and routers, but like I said, with Linux boxes only. Microsoft by default responds to these types of packets with a 'RST ACK' regardless of if its open or not.This is seen below, using the two hosts we used in the above example.

It was open on the other scan.... Bah humbug!

UDP

UDP is User Datagram Protocol. This is a connectionless protocol. Its like an assault on a port. There is no connection set up like TCP, and it doesn't care too much if some packets get dropped along the way. However, if you stream anything across the internets (like I am right now with internet radio), chances are pretty good you are using UDP.  DNS also uses UDP for name resolution, and DHCP is over UDP as well. Because there is no error checking or connection set up, packets move faster and sent to multiple hosts in a quicker fashion. Rock on UDP! 

UDP Scan: So as we said before there are many services that use UDP, such as DNS (which is a pretty juicy target!) This scan shows UDP port 124  responding back to our scanner with an ICMP unreachable sign, indicating the port is closed.

Sorry, we are closed!

This is what my nmap output is for that scan, and it is what is should be, port 124 is closed:

nmap result from nmap -sU scan

As people posted in the comments, there are tons of tools out there you can use. Nmap is just one of many. The key is to find the one you like and trust. Nping, which someone mentioned earlier, allows for much more fine tuning of your packets that you send out. p0f does passive host identification. All these other scans I have shown are active-- we are interacting in some way with the intended target. p0f simply listens to network traffic and based on the traffic it sees regarding the target determines the OS, which is the stealthiest you can get, as you are simply observing (well there is always a catch, still its pretty slick). And like Jon said... a new version is coming out!

I did not talk about the multiple states that nmap can report back to the user, a good explanation is here on their website. Heck, I recommend the whole reference guide.

Next we get onto the fingerprinting/version detection... well I may post my powershell script first. That will probably go on Pastebin. Like I said its no where near perfect and always looking for more ways to make scripting better, faster, and more kick ass (because lets face it... we are lazy and want something else to do the grunt work)