Now the server has over 5000 TIME_WAIT connections.
netstat -a -n | grep TIME_WAIT
tcp 0 0 139.18.25.33.59256 198.6.1.83.53 TIME_WAIT
tcp 0 0 139.18.25.33.59257 77.222.50.250.53 TIME_WAIT
tcp 0 0 139.18.25.33.59258 193.232.128.6.53 TIME_WAIT
tcp 0 0 139.18.25.33.59259 78.104.145.37.53 TIME_WAIT
tcp 0 0 139.18.25.33.59260 192.5.6.30.53 TIME_WAIT
tcp 0 0 139.18.25.33.59261 192.41.162.30.53 TIME_WAIT
tcp 0 0 139.18.25.33.59262 192.35.51.30.53 TIME_WAIT
tcp 0 0 139.18.25.33.59263 192.43.172.30.53 TIME_WAIT
tcp 0 0 139.18.25.33.59264 202.12.27.33.53 TIME_WAIT
...
It seems to be a result of the named. lsof shows that the connections are
not owned by named. lsof doesn't show any of the TIME_WAIT connections. So
stopping and restarting named doesn't delete the connections.
Any more things that could be interessing for a problem report?
Regards
Uwe
On Wed, 4
Feb
2015, Christos Zoulas wrote:
Date: Wed, 4 Feb 2015 15:40:00 +0000 (UTC)
From: Christos Zoulas <[email protected]>
To: [email protected]
Subject: Re: DoS attack against TCP services
In article <[email protected]>,
<[email protected]> wrote:
Hello,
The problem occurred again. The kernel has over 3,000 connections in
TIME_WAIT state. The compounds are after an hour wait not disappeared.
There are more and more connections in the TIME_WAIT state. My settings
are:
net.inet.tcp.mslt.enable = 1
net.inet.tcp.mslt.loopback = 2
net.inet.tcp.mslt.local = 10
net.inet.tcp.mslt.remote = 60
net.inet.tcp.mslt.remote_threshold = 6
The last few times I have restarted the server in order to solve the
problem. Frequent reboots but very inconvenient for a server.
Does anyone have instructions what information I can still gather to post
a bug report? The statement "connections in the TIME_WAIT status are not
degraded" are probably not sufficient to find the problem.
Thank you for your efforts
Can you find what daemon/process is being connected to and from where?
christos
