Possible Explanation for Recent Router Crash

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.

Dirk

 

My Site mainly Requires Web-Sockets.

The origins of HTTP were essentially ‘sessionless’. This meant that with a server always listening on Port 80, a client could request one URL at a time, in response to which the server would return the page in question directly to the client’s port number. This included the CGI-scripts’ FORM data. But as the early Internet evolved, Web-sites started to become ‘session-aware’. I explained this to my friends in the past as follows:

The client connects to the assigned port number 80 on the server, and requests a session, which causes the server to start listening on another port number, this forming a ‘session socket’. The one listening on port 80 was the ‘server socket’. The server’s session socket was dedicated to one client and to one session.

My friends did not acknowledge this description of how TCP works, I think mainly, because I did not use the right terminology. What I had referred to as a ‘session socket’, is officially termed a “Web-Socket” in the case of HTTP. It turns out that with an Apache server, many sub-processes can bear these Web-Sockets. They don’t exclusively exist in order to output Web-pages at a faster rate, in response to individual requests made by the clients, to the process still listening on port 80.

One fact to know about my site, is that for such purposes as viewing this blog, the use of Web-Sockets is required. In the case of certain other sections of my site, such as http://dirkmittler.homeip.net/GallIndex.htm, the use of Web-Sockets is not required, because those Web-pages exist mainly in a sessionless way – they can be fetched one at a time without error.

Certain proxy-servers will not allow a Web-Socket to get forwarded. These are logically also proxies which don’t allow SSL connections to be forwarded, because the encrypted SSL data is also sent via Web-Sockets or their equivalent. If you are connecting to the Internet via such a proxy, I’m afraid you won’t be able to navigate my blog correctly. I apologize for this, but there is little I can do about that. I think that you should still be able to fetch a single posting of mine, that comes up through a search engine.

Dirk

(Edit: ) This may also apply if you’re trying to connect to my IPv6 address, because my IPv6 is being provided by a Teredo proxy, which might have just assigned reduced privileges to my client:

Previous Post