is TCP port exhaustion real?

Question

How fast would one need to allocate ephemeral ports in order to get into the TCP port exhaustion condition?

I was told there are ~4k (older Windows), ~16k (newer Windows) or ~28k (RH Linux) ports available for the client requests. Now, is the pool of port numbers global or per remote IP address?

If they are global, since ports do not become reusable until after 240 (Windows) or 60 (RH Linux) seconds, one would need to allocate them at the rate of ~16/66/466 per sec correspondingly?

Is this correct?

In your experience, is this something I should be practically worried about?

found this: http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html — Andriy Volkov, Nov 29 '12 at 21:20
Yes, global, your numbers look generally correct. It can really happen. Note, on *nix systems there's usually a limit to the number of files/sockets a process can open (so that one process can't file/socket-bomb the whole computer) — Chris S, Nov 29 '12 at 21:21

user207421 · Answer 1 · 2014-07-10T03:27:03.003

6

DOS attacks apart, only with poorly written applications. The basic trick to avoiding TCP port exhaustion is connection pooling, for example HTTP keep-alive. This has several beneficial effects:

Fewer connections per unit of time.
The first close of a connection is usually done by the client, not the server. This moves the TIME_WAIT state from the server to the client, which is using far fewer sockets and ports and can therefore tolerate it much better.

edited Jul 10 '14 at 03:27

answered Nov 29 '12 at 20:37

user207421

990
5
16

1

Poorly written applications is what I'm married to :)) Thanks for your answer, but what I really am looking for is some hard math I can give to my boss to show how we are not vulnerable (or are, and when). – Andriy Volkov Nov 29 '12 at 20:52
1

You don't need math then really, you need monitoring. Start graphing your tcp port usage and give it to your boss. – Sirex Nov 29 '12 at 20:55
Poorly written applications are not the *only* cause of TCP port exhaustion -- it's still a fairly common DoS technique against small sites. – voretaq7 Nov 29 '12 at 21:21
@voretaq7 Agreed, edited. – user207421 Jul 10 '14 at 03:27
TCP port exhaustion is a simple attack for single server services; one public ip address can exhaust all available ports on a target server. Even with Idlensss detection it can bring down access to a system. Pooling doesn't help with this. – bond Jan 13 '16 at 18:03
You say that the client should close the connection. Should that not be the server? I thought that was why a lot of protocols had a quit/bye command so the client could tell the server to disconnect. – Anders Lindén Mar 29 '17 at 06:09
1

*one public ip address can exhaust all available ports on a target server*: @bond How can a server be exhausted of ports when they use a static port like port 80? – antak Jul 27 '17 at 07:46
1

I'm not sure what has happened on my Windows 10 machine, but recently when I develop a chat web app requesting updates from local apache server, at one point my entire network functionality breaks down with ERR_ADDRESS_IN_USE and similar errors for Chrome and MySQL server, and I cannot open any webpage at all, until I restart Apache. Netstat shows insane amounts of ports in TIME_WAIT. I did not have such issues on Windows 7. I guess, it's time to reinstall. But anyways, it proves that it is possible to exhaust all TCP ports if some app creates too many ports and leaves in TIME_WAIT state. – JustAMartin Oct 12 '17 at 14:31
@AndersLindén I meant what I said. The BYE command for example is typically a client-issued command. Not that any exit command is necessary: just close the socket. At the client. First. Then have the server react to the incoming close by closing. – user207421 Dec 21 '19 at 07:16

score 3 · Answer 2 · edited Nov 29 '12 at 21:20

Diito EJP and Sirex. Monitoring will give you a better understanding of where you stand. You can also tweak how long a socket is allowed to remain in a TIME_WAIT state. I've had to do this very thing on a system that talks to thousands of GPRS telemetry devices. They dial in, and consume ports like nobody's business. A more aggressive TIME_WAIT threshold has meant our (the) application is more stable.

There are some useful tools on MS Windows for monitoring port usage, e.g.: TCPView and ProcessExplorer (MS SysInternals). netstat -a can be slow when there are thousands of connections, so you can use netstat -an instead (this stops DNS resolution from occuring on the addresses). I can't vouch for Linux though....

is TCP port exhaustion real?

2 Answers2