Wannabe Tutorials: Section 2 Part 1

Networking
, ,
1

I have talked to some people on IRC and have realized that my tutorials need some work. Thanks you for those who pointed out my errors and gave me suggestions. This tutorial, I hope, is better. Cheers.

Recon

As I stated in Section 1 Part 4 of my series, recon is probably the most important step of hacking. There are many techniques used, but in these tutorials I will only cover Scanners, specifically Port Scanners and Web Scanners.

By definition, Port Scanners are:

"Application designed to probe a server or hosts for open ports."

The results of a scan on a port usually is categorized in one of three categories:

  • Open or Accepted: Host sent a reply that indicates that a service is listening on a port.
  • Closed and/or Denied or Not Listening: Host sent a repy indicating that connections will be denied to the port.
  • Filtered, Dropped, or Blocked: No reply from host or a Firewall (other security measures) is in place.

In nmap there are many types of scans, but I’m only going to cover TCP, SYN, and UDP scans.

Types of Scans

The simplest port scanners use the operating system’s network functions. nmap calls this a connect scan. In other words, if a port is open then the OS completes a TCP three-way-handshake, but afterwards the connection is closed to avoid a DoS attack.

A TCP three-way-handshake is when each device sends a SYN and an ACK (also known as a SYN-SYN-ACK). In normal sequence of a connection establishment, a SYN is sent by one device (host a). Once the SYN is received by the other device, host b sends a SYN-ACK. The SYN-ACK is received by host a and then host a sends a ACK. Once host b receives an ACK the TCP socket connection is established. A quick diagram is:

host a ------ SYN ------> host b
host a <------ SYN-ACK ------ host b
host a ------ ACK ------> host b

In nmap, the connect scan is as follows:

$ nmap -sT (Ip)

The problem with TCP scanning is that it’s noisy because services may log a sender’s IP address or an Intrusion Detection System may raise an alarm.

Thus, a SYN scan is often preferred. A SYN scan is a bit different. As with the TCP scan, a SYN scan first sends a SYN, but instead of a SYN-ACK returned only a ACK is actually returned. A quick diagram is:

Client ------ SYN ------> Server
Client <------ ACK ------ Server

A SYN (TCP SYN) scan is done in nmap using:

nmap -sS (Ip)

The last scan type, UDP, is the trickiest. UDP is known as a connectionless protocol: when a packet is sent to a UDP port, that open port receives a packet, but the closed ports send a ICMP back. A quick diagram is:

Client ------- Packet ------> Server
Client <------ ICMP ------- Server

In nmap, a UDP (UDP-ICMP) scan can be performed with this command:

nmap -sU (Ip)

The UDP scan is the only scan type that can be inserted with another scan type, for example, SYN scan:

nmap -sS -sU (Ip)

Conclusion

Well, that’s it for this tutorial. I decided not to talk about the Web Scanners in this part because this tutorial was getting long, but I will have that tutorial up next. Please comment down below, as any suggestions are welcome, but please don’t flame me.

Cheers.

7 Likes
2

Really really really enjoyed this overview @Valentine, I can really see you’ve done some research, and learnt a lot, and therefore put effort into this.

I actually learnt a lot from this, my understanding actually was wrong, and you’ve put me right :slight_smile: I am so pleased you’ve done that. Also, I’ve never really 100% understood ICMP & UDP, but you’ve really improved my understanding with your simple explanations! Good job!

PS: I would recommend placing this in the networking tutorial category since it is a lot about networking, right?

2 Likes
3

In your diagram for the three way handshake, host a should have the arrow pointed towards host b, since it is returning ack.

host a -------------ACK------------> host b

1 Like
4

Whoopsie daisy. I can fix that. XD

5

I small note about SYN scans.

The server will always respond to a successful connection request with a SYN-ACK, it’s just the way TCP works. The reason the SYN scan works is because the attacker responds to a server with an RST packet, closing the connection before it’s actually established. This is why SYN scans are also known as half-open scans.

So, the diagram for a SYN scan would look like this…

host a ------SYN-----> host b
host a <---SYN-ACK---- host b
host a ------RST-----> host b
        Port is open

Otherwise, great write-up!

-Defalt

3 Likes
6

AFAIK no port scanner sends a RST packet during the scan. Only the SYN packet is sent. What happens is that, as we are not calling connect the TCP/IP stack in the kernel does not know about any connection going on and it responds to the unexpected SYN|ACK packet with a RST, as it does for any unexpected packet.

To verify this you can easily write a simple program that sends one single SYN packet. Launch your preferred sniffer and run it against an open port (otherwise you just get a RST packet from the remote machine). You will see a RST packet in your sniffer trace even when your program is not sending it.

Then you can drop any outgoing RST packet in your machine (with a firewall rule) and your scan will still work.

3 Likes
7

I used wikipedia so it could be wrong. Lmao. Sorry for the misshap.

8

It’s not that the attacker needs to send the packet, it’s that the victim needs to receive one. Due to TCP’s error checking/correction, if you did stop the outgoing RST packets, the victim will follow protocol and keep sending SYN-ACK packets until it gets a response or times out (if the port is open), this will effectively DoS the target, which is not the intended goal.

It doesn’t matter what the kernel thinks, the RST packet is sent so the victim machine doesn’t use up all it’s resources responding.

3 Likes
9

“A SYN packet is sent (as if we are going to open a connection), and the target host responds with a SYN+ACK, this indicates the port is listening, and an RST indicates a non- listener. The server process is never informed by the TCP layer because the connection did not complete.”

http://www.auditmypc.com/port-scanning.asp

I did a bit of research and this is what I found throughout the internet via google.

2 Likes
11

Where is this going?

12

To my knowledge, an RST flag is only sent in the event of an error, or in response to a socket close. RST stands for Reset, AKA Abort, quite like if you did a return 1 in a piece of C code, it would terminate the connection, although it isn’t the correct way to close it.

A FIN flag also exists; this is just like doing a return 0; it closes the connection stream, although is to communicate that no more data needs to be sent.

This is what Wikipedia mentions on TCP Reset Flags:

In a stream of packets of a TCP connection, each packet contains a TCP header. Each of these headers contains a bit known as the “reset” (RST) flag. In most packets this bit is set to 0 and has no effect; however, if this bit is set to 1, it indicates to the receiving computer that the computer should immediately stop using the TCP connection; it should not send any more packets using the connection’s identifying numbers, called ports, and discard any further packets it receives with headers indicating they belong to that connection. A TCP reset basically kills a TCP connection instantly.

When used as designed, this can be a useful tool. One common application is the scenario where a computer (computer A) crashes while a TCP connection is in progress. The computer on the other end (computer B) will continue to send TCP packets since it does not know that computer A has crashed. When computer A reboots, it will then receive packets from the old pre-crash connection. Computer A has no context for these packets and no way of knowing what to do with them, so it might send a TCP reset to computer B. This reset lets computer B know that the connection is no longer working. The user on computer B can now try another connection or take other action.

I think you may be referring to a TCP reset attack, which is, in essence, the opposite of what you’ve said: where you flood a machine with RST packets; and therefore kill any connection established, or any connection attempting to create itself.

2 Likes
13

Have we established a full answer yet? Does anybody agree with my explanation, or is @Defalt correct.

I’m glad we have a forum of discussion like this, and are able to have these discussions objectively.

2 Likes
14

Summing up:

  • In order to know the state of the port (Open|Close|Filtered) you do not need to send a RST packet. You will know the state when you get the first packet from the remote machine, independently of sending an extra RST or not.
  • If a SYN|ACK packet is received the port is OPEN
  • if a RST or an ICMP error message is received, the port is CLOSED
  • If nothing is received, the port is FILTERED
  • nmap does not send an RST packet as part of a SYN scan (just strace it).
  • Your sniffer will show an RST packet coming from the attacker machine, when scanning an Open Port. That packet is generated by the kernel in response to a SYN|ACK from the remote machine that is not associated to any on-going TCP connection.
  • Even when sending the RST packet is not really needed, it is a good practice to close the connection. This will happen automatically because of the previous point (the kernel will send the RST). In other words, sending a RST packet from the port scanner program is just redundant.
  • In a default Linux configuration, the SYN|ACK packet will be re-send up to 5 times with an increasing time-out, something like 1, 3, 6, 12, 24 seconds. This will happen if the RST packet is not sent to the target machine. In general, you will get 5 bursts of data that will be smaller than the original burst produced by the scanning itself… Because you will just get this packets back only from the open ports. The closed ones will not produce any re-send. If you can be DoSed by this you will also be DoS by the simple fact of running a scan. Nevertheless, not sending the RST packet is just dirty and a waste of resources more than a threat. And, as we have seen, it will only happen if you explicitly block them.
  • You really need to scan a big network with a lot of hosts up and a lot of open ports in each host to get something back that can be considered a DoS… (A SYN|ACK packet is 44 bytes long).

This is how it works for a Linux box. For other system it may be different. Based on what is said above you can try and report back if something works differently in your system.

4 Likes
15

Very nice! That has made me understand a hell of a lot more!!

So what about Sending a FIN packet? Is that used for an entirely different scenario as well?

16

Then FIN is the equivalent to the SYN flag for ordered disconnection. There is again a interchange of packets to ensure that whatever has been sent arrives to the destination. The wiki has a good general description https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_termination

A brief description of the use of FIN for port scanning can be found here:

2 Likes