Date: Wed, 04 Feb 2015 19:54:59 +0100
From: Johnny Billquist <bqt%update.uu.se@localhost>
To: 6bone%6bone.informatik.uni-leipzig.de@localhost,
Christos Zoulas <christos%astron.com@localhost>
Cc: current-users%netbsd.org@localhost
Subject: Re: DoS attack against TCP services
Are you *sure* the same connections stay around forever, or might it just be
that you get new ones at a higher rate than old ones go away?
Johnny
On 2015-02-04 19:44, 6bone%6bone.informatik.uni-leipzig.de@localhost wrote:
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 <christos%astron.com@localhost>
To: current-users%netbsd.org@localhost
Subject: Re: DoS attack against TCP services
In article
<Pine.NEB.4.64.1502041602460.812%6bone.informatik.uni-leipzig.de@localhost>,
<6bone%6bone.informatik.uni-leipzig.de@localhost> 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