3 ms·

Exhausting ports or generating a lot of TIME_WAIT states would also cause similar problems. How to protect against those ?

by bartwe 15y ago

bnoordhuis 15y ago
You'll be hard-pressed to exhaust all ports: modern operating systems track connections by source address + source port + target address + target port. I wouldn't be surprised if the TCP sequence number is also part of the mix. TIME_WAIT times can be tweaked with the net.ipv4.tcp_tw_recycle and net.ipv4.tcp_tw_reuse sysctls, on Linux systems anyway.
- cnlwsu 15y ago
  Exactly, you can only really exhaust the ports from the server address/port to your single host, which is effectively only DoSing your own access to the server. Ive seen over a million sockets in time_wait and it did not effect the servers. However if doing something like behind a single software load balancer then the number of ports available will be limited to the 65k connections since the source address/port and target address(the lb) are fixed.
- MostAwesomeDude 15y ago
  I seem to recall that there are five numbers involved: Source address, source port, target address, target port, and a fifth number. I want to say it's the file descriptor, but that just sounds wrong when I type it out.
- sophacles 15y ago
  Running out of ports is a poor way to put it, but it can be read as "Run the target machine out of fd (file descriptors)." In unixy systems there is a system parameter limiting the maximum number of file descriptors that can be open at one time (actually 2, per-proces and system-wide limits). These limits need to be turned up for big servers. The why is a pretty boring story: the number exists as a check against runaway processes or big jobs (e.g. busy servers) causing an I/O overload, so the numbers are set to a "reasonable value" by default. Of course the reasonable value is usually much lower than the system can handle, and at tuned for older common hardware.
ivank 15y ago
There are two ways to avoid getting TIME_WAIT states in the first place: 1. Convince the client to close the connection. The initiator of the close will be the one holding the TIME_WAIT socket (for ~2 minutes) 2. Send RSTs to clients that refuse to close. RST avoids creating a TIME_WAIT state. I think this is slightly more dangerous than a normal FIN close, because wandering duplicates could interfere with the next connection. From Python, you can close a TCP socket in a way that causes a RST to be sent: # Set SO_LINGER to 1,0 which, by convention, causes a # connection reset to be sent when close is called, # instead of the standard FIN shutdown sequence. self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack("ii", 1, 0)) (From the patches and branch in http://twistedmatrix.com/trac/ticket/78 http://twistedmatrix.com/trac/ticket/78)
deleted 15y ago
[deleted]

Exhausting ports or generating a lot of TIME_WAIT states would also cause similar problems. How to protect against those ?

by bartwe 15y ago

Exhausting ports or generating a lot of TIME_WAIT states would also cause similar problems. How to protect against those ?

bnoordhuis 15y ago

You'll be hard-pressed to exhaust all ports: modern operating systems track connections by source address + source port + target address + target port. I wouldn't be surprised if the TCP sequence number is also part of the mix. TIME_WAIT times can be tweaked with the net.ipv4.tcp_tw_recycle and net.ipv4.tcp_tw_reuse sysctls, on Linux systems anyway.

cnlwsu 15y ago
Exactly, you can only really exhaust the ports from the server address/port to your single host, which is effectively only DoSing your own access to the server. Ive seen over a million sockets in time_wait and it did not effect the servers. However if doing something like behind a single software load balancer then the number of ports available will be limited to the 65k connections since the source address/port and target address(the lb) are fixed.
MostAwesomeDude 15y ago
I seem to recall that there are five numbers involved: Source address, source port, target address, target port, and a fifth number. I want to say it's the file descriptor, but that just sounds wrong when I type it out.
sophacles 15y ago
Running out of ports is a poor way to put it, but it can be read as "Run the target machine out of fd (file descriptors)." In unixy systems there is a system parameter limiting the maximum number of file descriptors that can be open at one time (actually 2, per-proces and system-wide limits). These limits need to be turned up for big servers. The why is a pretty boring story: the number exists as a check against runaway processes or big jobs (e.g. busy servers) causing an I/O overload, so the numbers are set to a "reasonable value" by default. Of course the reasonable value is usually much lower than the system can handle, and at tuned for older common hardware.

ivank 15y ago

There are two ways to avoid getting TIME_WAIT states in the first place: 1. Convince the client to close the connection. The initiator of the close will be the one holding the TIME_WAIT socket (for ~2 minutes) 2. Send RSTs to clients that refuse to close. RST avoids creating a TIME_WAIT state. I think this is slightly more dangerous than a normal FIN close, because wandering duplicates could interfere with the next connection. From Python, you can close a TCP socket in a way that causes a RST to be sent: # Set SO_LINGER to 1,0 which, by convention, causes a # connection reset to be sent when close is called, # instead of the standard FIN shutdown sequence. self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack("ii", 1, 0)) (From the patches and branch in http://twistedmatrix.com/trac/ticket/78 http://twistedmatrix.com/trac/ticket/78)

deleted 15y ago

[deleted]