Meta

Tag: SYN Packets

Just yesterday my router crashed, and I documented this event Here. At the time, the cause for that event did not seem obvious to me, but by now, I have a possible explanation in mind.

The fact should be understood, that with TCP protocol, there exist two basic types of packets: SYN Packets, and session-specific, Data Packets. For example, in the case of an HTTP server which is ‘always’ listening on Port 80, the actual packets which get sent to that port by browsers are likely to be SYN packets, which request a new session. The function of these packets to the client, are to request a dedicated Data Port on the server to be opened, so that the client and server can exchange data on this additional port. Such a port can then also correspond to one session.

A type of Web-attack is possible, in which a maximum possible number of SYN Packets is sent to Port 80 in this case, thus causing a huge number of session-ports to open on the server, for which the client may not even be arranging to have any kind of session. In fact, doing so not even requires that a bogus log-in attempt to any service be made, nor that a password be guessed at, for which reason such a situation may not get logged – as real hacking attempts – in any of the security logs the server keeps. So where, then is the danger of this to the server?

The situation can arise, that indeed thousands of session-ports, if not tens of thousands, have been opened on the server, all waiting for a new session.

The router mirrors all these ports on the WAN, and tries to map them back to a specific machine on the LAN, that they belong to. This is called Port-Triggering. Hence, if ?50,000? session-ports have been opened on the one server, on the LAN, the request exists implicitly to the router, to keep 50,000 ports open on the WAN as well.

The problem with this can be, that at some point the router runs out of memory to map that many ports. This can cause a router to crash, especially in the case of a domestic router, which is not really designed as solidly as commercial, big-time server-switches are designed.

The problem is less likely in my case, that the server runs out of resources, simply because mine is a 64-bit machine.

But in order to protect myself against such an attack, my server config files need to be such, that not only the speed of incoming SYN Packets is throttled, but also so that any session-ports close automatically, if they are idle for some period of time.

Presumably, the WAN ports will close again on the router, whenever the corresponding ports on the LAN-based server are closed.

While this might sound very far-fetched to some readers, I am aware that this type of an attack takes place often against my machine, coming from robots who-knows-where. I have ways of knowing this, that also display which IP addresses such things come from. But for the most part this does not spur me to start blocking an inordinate number of IP address ranges – arbitrarily, in a world where IP addresses often change. Instead, I focus on closing the vulnerability where I can, in the client keep-alive settings of various servers and applications, that all run on this host.

In general, my HTTP and HTTPS servers are configured correctly, by Debian package maintainers, to thwart such an attack. But I have discovered another service running on my host, and listening for incoming connections on the WAN, which was not configured to be bulletproof in this regard.

Quite possibly, one of those robots discovered the same vulnerability on September 10. If this did happen, it would adequately explain why the router crashed. As of now, that additional service running on my host, has a new configuration, designed to make my router less vulnerable.

If this explanation is true, then users may have experienced problems retrieving my URLs, earlier than 13h05 yesterday. If this was your experience, I apologize again.

If the router crashes again any time soon, then I will need to start looking for other explanations.