After doing a lot of analysis sessions on TCP connections there are some patterns that you see again in a trace every once in a while. And often it comes in handy to remember what the situation was and what the circumstances were that led to the trace showing what it did.
If you look closely you can see that the client (IP address 192.168.1.1) does a successful Three Way Handshake with the FTP server (IP address 10.0.0.1), but before it has a chance to send any useful commands the server tears the session down again in packet 4. So the question is: why does the server agree to a three way handshake, only to never allow the client to do anything with it? Lets take a look at the possible reasons:
- The clients ACK of the Three Way Handshake was somehow faulty, forcing a connection abort
- The FTP server had already too many connections open and refused a new one
- The FTP application on the server crashed right after the connection was accepted
- The server doesn’t like the IP address the client is coming from
So let’s take a closer look at each one.
The ACK of the Three Way Handshake may have been faulty
This theory sounds interesting, but it’s not very likely. First of all a TCP Three Way Handshake rarely fails at all, and I have never seen it fail this way. Calculating sequence and acknowledge numbers is no rocket science, at least for a computer (in my Wireshark classes it often seemed to be amazingly difficult for humans sometimes), so we can assume that there was no problem with that. In fact the sequence numbers in the trace shown above are all perfectly fine. And if they weren’t, the server would not send a nice “FIN” flag to tear down the session, but a fatal “RST” flag. So this is not it.
FTP connections limit reached
Maybe the server had a limit configured, and that limit of concurrent connections was already reached when the client connected? It’s a possible scenario, but usually servers send a FTP error code 412 “too many connections” when that happens. Much more polite, and the user even knows what is happening, and why the connection didn’t work. It will also keep him from trying again and again like a madman. So no, it’s not the connection limit, at least in this case. Next.
FTP application Crash
Could it be that right after the connection was established the FTP server application simply crashed? Well, no. First of all because other connection were still working at the same time instead of being disconnected the same way, which is additional info not seen in the trace but which you should always try to get in cases like this. And, more importantly, when an application crashes it releases (or is forced to release) the sockets it has in the operating system. And when that happens we will see a RST coming from the TCP stack, not a FIN. So no crash, either.
The Server doesn’t like the client IP
Maybe the server just doesn’t like the IP the client is coming from. But if that would be the case, why does it go through the whole TCP Three Way Handshake instead of simply refusing the SYN packet with a RST packet?
Well, the answer is that in this case the server really refused the client IP, but it wasn’t the TCP stack itself that decided to drop the connection. It was the FTP server application. Remember the OSI modell? ;-)
The FTP server application gets notified of the new connection only after the TCP stack has finalized the Three Way Handshake. So first there needs to be that handshake, and then the application learns that a new client is connected. Since the FTP server application in this case has a list of acceptable IP addresses that are allowed to connect it does a compare between the client IP and the whitelist. It realizes that the client is not on the list, so it terminates the connection as soon as possible. And that is the FIN that we see coming from the server – the socket is not abruptly closed like in an application crash (which would result in an RST packet) but “gently” with a FIN flag.
So, if you ever see a TCP connection behaving like this one you should find the administrator responsible for the application and tell him that he needs to find the configuration setting where the blacklist or whitelist is configured.
Happy new year, and happy packet reading!