Re: DoS attack against TCP services

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  I'd suggest capturing the output of netstat -An.  The first
column of that output should be the address of the socket associated with
each of the connections.  For each connection in time_wait state, you
should be able to perform an fstat |grep for the address in column 1 of the
netstat -An output.  This should tell you which process  or processes all
of these connections are tied to.
For example:

%netstat -An 
Active Internet connections
PCB      Proto Recv-Q Send-Q Local Address         Foreign Address       State
c6b9602c tcp        0      0 x.x.230.11.993     x.x.59.250.23892  ESTABL

%fstat |grep c6b9602c
buhrow imapd      26858    0* internet stream tcp c6b9602c x.x.230.11:993 <-> x.x.59.250:23892
buhrow imapd      26858    1* internet stream tcp c6b9602c x.x.230.11:993 <-> x.x.59.250:23892


	The bug could be as simple as the daemon that's responsible for these
connections failing to close the sockets once the connections terminate.
-thanks
-Brian

On Feb 4,  7:44pm, 6bone%6bone.informatik.uni-leipzig.de@localhost wrote:
} Subject: Re: DoS attack against TCP services
} 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
} >
>-- End of excerpt from 6bone%6bone.informatik.uni-leipzig.de@localhost