Re: Extra files in DESTDIR with MKRUMP=no
On Thu, 29 Jan 2015 10:39:42 + (GMT) Robert Swindells wrote: > idler...@fastmail.fm wrote: > I also build with MKRUMP=no but have the following extra patch in my > local tree: > > Robert Swindells > > Index: tests/mi > === > RCS file: /cvsroot/src/distrib/sets/lists/tests/mi,v > retrieving revision 1.610 > diff -u -r1.610 mi > --- tests/mi14 Jan 2015 22:25:05 - 1.610 > +++ tests/mi29 Jan 2015 10:41:34 - > @@ -3146,7 +3146,7 @@ > ./usr/tests/net/in_cksum/t_in_cksumtests-net-tests atf > ./usr/tests/net/in_cksum/in_cksum tests-net-tests atf > ./usr/tests/net/mcast tests-net-tests > -./usr/tests/net/mcast/Atffile tests-net-tests > atf,rump > +./usr/tests/net/mcast/Atffile tests-net-tests atf > ./usr/tests/net/mcast/Kyuafile tests-net-tests > atf,rump,kyua > ./usr/tests/net/mcast/t_mcast tests-net-tests atf > ./usr/tests/net/mpls tests-net-tests I've now convinced myself that this is the correct (and not just the immediately convenient) fix. The t_mcast test has no dependence on rump that I can see, src/tests/net/Makefile clearly builds it even when MKRUMP=no (thus generating the corresponding Atffile), so the presence of the Atffile is not dependent on rump either. If you (Mr Swindells) are not intending to do so yourself, I'll file a PR (crediting you for the patch of course) so that this doesn't get forgotten about in the list archives. -- IDL
daily CVS update output
Updating src tree: U src/crypto/external/bsd/netpgp/dist/src/netpgpverify/1keypubring.gpg U src/crypto/external/bsd/netpgp/dist/src/netpgpverify/1keysecring.gpg U src/crypto/external/bsd/netpgp/dist/src/netpgpverify/1keytest.gpg.uu P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/Makefile.bsd P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/bzlib.c P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/bzlib_private.h P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/chk.sh U src/crypto/external/bsd/netpgp/dist/src/netpgpverify/digest-20121220.tgz U src/crypto/external/bsd/netpgp/dist/src/netpgpverify/joyent-pubring.gpg P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/libnetpgpverify.3 P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/libverify.c U src/crypto/external/bsd/netpgp/dist/src/netpgpverify/mkdist U src/crypto/external/bsd/netpgp/dist/src/netpgpverify/testit.sh P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/verify.h P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/zlib.c P src/external/mit/lua/dist/src/luaconf.h P src/lib/librumpuser/rumpuser_sp.c P src/sys/dev/pci/ixgbe/ixgbe.c P src/sys/dev/pci/ixgbe/ixgbe.h P src/sys/dev/pci/ixgbe/ixgbe_netbsd.c P src/sys/dev/usb/usbdevs P src/sys/dev/usb/usbdevs.h P src/sys/dev/usb/usbdevs_data.h P src/sys/kern/subr_prf.c P src/sys/kern/vfs_vnops.c P src/sys/rump/librump/rumpkern/Makefile.rumpkern Updating xsrc tree: Killing core files: Running the SUP scanner: SUP Scan for current starting at Thu Feb 5 03:04:55 2015 SUP Scan for current completed at Thu Feb 5 03:06:11 2015 SUP Scan for mirror starting at Thu Feb 5 03:06:11 2015 SUP Scan for mirror completed at Thu Feb 5 03:08:33 2015 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 48856724 Feb 5 03:20 ls-lRA.gz
Re: DoS attack against TCP services
dmesg reports in loger intervals: nd6_storelladdr: something odd happens I do not know if this is the cause for the TIME_WAIT connections or a consequence of TIME_WAIT connections. Regards Uwe On Wed, 4 Feb 2015, Martin Husemann wrote: Date: Wed, 4 Feb 2015 23:37:05 +0100 From: Martin Husemann To: Christos Zoulas Cc: 6b...@6bone.informatik.uni-leipzig.de, current-users@netbsd.org Subject: Re: DoS attack against TCP services On Wed, Feb 04, 2015 at 05:33:10PM -0500, Christos Zoulas wrote: Something timer related? Are there any clock events? One of the cores dead/lievlocked in softnet? Martin
Re: DoS attack against TCP services
6b...@6bone.informatik.uni-leipzig.de writes: >the process is the named (version: bind-9.10.1pl1). The outgoing >connections are normal. stopping the named do not remove the TIME_WAIT >connections. The TIME_WAIT entries aren't connected to a process anymore. That's normal behaviour. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: DoS attack against TCP services
On Wed, Feb 04, 2015 at 05:33:10PM -0500, Christos Zoulas wrote: > Something timer related? Are there any clock events? One of the cores dead/lievlocked in softnet? Martin
Re: DoS attack against TCP services
On Feb 4, 11:27pm, 6b...@6bone.informatik.uni-leipzig.de (6b...@6bone.informatik.uni-leipzig.de) wrote: -- Subject: Re: DoS attack against TCP services | Hello, | | I'm afraid I have chosen the wrong subject. After some testing, I found | that all tcp connections go in the TIME_WAIT state. This applies to | inbound connections and outbound connections. To me it looked like an | attack. But now I think it is a kernel error. | | After restarting the server a few weeks is stable. Any event brings the | server then to leave all tcp connections in the TIME_WAIT state. Something timer related? Are there any clock events? christos
Re: DoS attack against TCP services
Hello, I'm afraid I have chosen the wrong subject. After some testing, I found that all tcp connections go in the TIME_WAIT state. This applies to inbound connections and outbound connections. To me it looked like an attack. But now I think it is a kernel error. After restarting the server a few weeks is stable. Any event brings the server then to leave all tcp connections in the TIME_WAIT state. Regards Uwe
Re: DoS attack against TCP services
Hello, the process is the named (version: bind-9.10.1pl1). The outgoing connections are normal. stopping the named do not remove the TIME_WAIT connections. there existist also other TIME_WAIT connections (maybe from ssh probes) tcp0 0 139.18.25.33.22115.239.228.35.38653 TIME_WAIT Killing the sshd does not remove the connections. Regards Uwe On Wed, 4 Feb 2015, Brian Buhrow wrote: Date: Wed, 4 Feb 2015 12:02:33 -0800 From: Brian Buhrow To: Christos Zoulas , 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@NetBSD.org, buh...@nfbcal.org Subject: Re: DoS attack against TCP services Hello. The output from the sample netstat indicates that some process on the machine from which this output was taken is opening up a bunch of connections to remote sites on port 53. I think it would be interesting to know if all of these connections are generated from the same process or not. I'm pretty sure you can get this behavior if a process fails to close(2) a file descriptor after the connection has terminated. I wonder if there's some rogue process running on this machine that's been badly coded to give itself away by engaging in this bad behavior. Knowing nothing else, I'd be concerned about a potential security breech on this machine. -thanks -Brian
Re: DoS attack against TCP services
Hello. The output from the sample netstat indicates that some process on the machine from which this output was taken is opening up a bunch of connections to remote sites on port 53. I think it would be interesting to know if all of these connections are generated from the same process or not. I'm pretty sure you can get this behavior if a process fails to close(2) a file descriptor after the connection has terminated. I wonder if there's some rogue process running on this machine that's been badly coded to give itself away by engaging in this bad behavior. Knowing nothing else, I'd be concerned about a potential security breech on this machine. -thanks -Brian
Re: DoS attack against TCP services
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 tcp0 0 x.x.230.11.993 x.x.59.250.23892 ESTABL %fstat |grep c6b9602c buhrow imapd 268580* internet stream tcp c6b9602c x.x.230.11:993 <-> x.x.59.250:23892 buhrow imapd 268581* 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, 6b...@6bone.informatik.uni-leipzig.de wrote: } Subject: Re: DoS attack against TCP services } Now the server has over 5000 TIME_WAIT connections. } } netstat -a -n | grep TIME_WAIT } tcp0 0 139.18.25.33.59256 198.6.1.83.53 TIME_WAIT } tcp0 0 139.18.25.33.59257 77.222.50.250.53 TIME_WAIT } tcp0 0 139.18.25.33.59258 193.232.128.6.53 TIME_WAIT } tcp0 0 139.18.25.33.59259 78.104.145.37.53 TIME_WAIT } tcp0 0 139.18.25.33.59260 192.5.6.30.53 TIME_WAIT } tcp0 0 139.18.25.33.59261 192.41.162.30.53 TIME_WAIT } tcp0 0 139.18.25.33.59262 192.35.51.30.53TIME_WAIT } tcp0 0 139.18.25.33.59263 192.43.172.30.53 TIME_WAIT } tcp0 0 139.18.25.33.59264 202.12.27.33.53TIME_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 + (UTC) } > From: Christos Zoulas } > To: current-users@netbsd.org } > Subject: Re: DoS attack against TCP services } > } > In article , } > <6b...@6bone.informatik.uni-leipzig.de> 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 6b...@6bone.informatik.uni-leipzig.de
Re: DoS attack against TCP services
I picked out one connection: fe8678e73990 tcp0 0 139.18.25.33.58935199.254.60.1.53 TMWAIT But 'fstat -n | grep 73990' shows no result. lsof also shows no socket for this connection. Regards Uwe On Wed, 4 Feb 2015, Brian Buhrow wrote: Date: Wed, 4 Feb 2015 11:49:16 -0800 From: Brian Buhrow To: 6b...@6bone.informatik.uni-leipzig.de, Christos Zoulas Cc: current-users@NetBSD.org, buh...@nfbcal.org Subject: Re: DoS attack against TCP services 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 tcp0 0 x.x.230.11.993 x.x.59.250.23892 ESTABL %fstat |grep c6b9602c buhrow imapd 268580* internet stream tcp c6b9602c x.x.230.11:993 <-> x.x.59.250:23892 buhrow imapd 268581* 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, 6b...@6bone.informatik.uni-leipzig.de wrote: } Subject: Re: DoS attack against TCP services } Now the server has over 5000 TIME_WAIT connections. } } netstat -a -n | grep TIME_WAIT } tcp0 0 139.18.25.33.59256 198.6.1.83.53 TIME_WAIT } tcp0 0 139.18.25.33.59257 77.222.50.250.53 TIME_WAIT } tcp0 0 139.18.25.33.59258 193.232.128.6.53 TIME_WAIT } tcp0 0 139.18.25.33.59259 78.104.145.37.53 TIME_WAIT } tcp0 0 139.18.25.33.59260 192.5.6.30.53 TIME_WAIT } tcp0 0 139.18.25.33.59261 192.41.162.30.53 TIME_WAIT } tcp0 0 139.18.25.33.59262 192.35.51.30.53TIME_WAIT } tcp0 0 139.18.25.33.59263 192.43.172.30.53 TIME_WAIT } tcp0 0 139.18.25.33.59264 202.12.27.33.53TIME_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 + (UTC) } > From: Christos Zoulas } > To: current-users@netbsd.org } > Subject: Re: DoS attack against TCP services } > } > In article , } > <6b...@6bone.informatik.uni-leipzig.de> 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 6b...@6bone.informatik.uni-leipzig.de
Re: DoS attack against TCP services
On Feb 4, 7:44pm, 6b...@6bone.informatik.uni-leipzig.de (6b...@6bone.informatik.uni-leipzig.de) wrote: -- Subject: Re: DoS attack against TCP services | Now the server has over 5000 TIME_WAIT connections. | | netstat -a -n | grep TIME_WAIT | tcp0 0 139.18.25.33.59256 198.6.1.83.53 TIME_WAIT | tcp0 0 139.18.25.33.59257 77.222.50.250.53 TIME_WAIT | tcp0 0 139.18.25.33.59258 193.232.128.6.53 TIME_WAIT | tcp0 0 139.18.25.33.59259 78.104.145.37.53 TIME_WAIT | tcp0 0 139.18.25.33.59260 192.5.6.30.53 TIME_WAIT | tcp0 0 139.18.25.33.59261 192.41.162.30.53 TIME_WAIT | tcp0 0 139.18.25.33.59262 192.35.51.30.53TIME_WAIT | tcp0 0 139.18.25.33.59263 192.43.172.30.53 TIME_WAIT | tcp0 0 139.18.25.33.59264 202.12.27.33.53TIME_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? I'd start a tcpdump to record all traffic from your local machine going to port 53 on the appropriate interface... I'd also look at the open descriptors of the named process (although they should be closed at this time, since TIME_WAIT means closed on this side, and waiting for the 4 minutes to expire before killing the connection)... Also I'd record that information every minute or so to see how many connections are added and how many are going away. Perhaps there is some bug triggered in the tcp stack and somehow connections are not being GC'ed? christos
Re: DoS attack against TCP services
Yes, I am sure that the most TIME_WAIT connections stay forever. I cannot say for sure that no TIME_WAIT connection is removed. But I can say, that some example connections have been existing for more than 5 hours. Regards Uwe On Wed, 4 Feb 2015, Johnny Billquist wrote: Date: Wed, 04 Feb 2015 19:54:59 +0100 From: Johnny Billquist To: 6b...@6bone.informatik.uni-leipzig.de, Christos Zoulas Cc: current-users@netbsd.org 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, 6b...@6bone.informatik.uni-leipzig.de wrote: Now the server has over 5000 TIME_WAIT connections. netstat -a -n | grep TIME_WAIT tcp0 0 139.18.25.33.59256 198.6.1.83.53 TIME_WAIT tcp0 0 139.18.25.33.59257 77.222.50.250.53 TIME_WAIT tcp0 0 139.18.25.33.59258 193.232.128.6.53 TIME_WAIT tcp0 0 139.18.25.33.59259 78.104.145.37.53 TIME_WAIT tcp0 0 139.18.25.33.59260 192.5.6.30.53 TIME_WAIT tcp0 0 139.18.25.33.59261 192.41.162.30.53 TIME_WAIT tcp0 0 139.18.25.33.59262 192.35.51.30.53 TIME_WAIT tcp0 0 139.18.25.33.59263 192.43.172.30.53 TIME_WAIT tcp0 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 + (UTC) From: Christos Zoulas To: current-users@netbsd.org Subject: Re: DoS attack against TCP services In article , <6b...@6bone.informatik.uni-leipzig.de> 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
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, 6b...@6bone.informatik.uni-leipzig.de wrote: Now the server has over 5000 TIME_WAIT connections. netstat -a -n | grep TIME_WAIT tcp0 0 139.18.25.33.59256 198.6.1.83.53 TIME_WAIT tcp0 0 139.18.25.33.59257 77.222.50.250.53 TIME_WAIT tcp0 0 139.18.25.33.59258 193.232.128.6.53 TIME_WAIT tcp0 0 139.18.25.33.59259 78.104.145.37.53 TIME_WAIT tcp0 0 139.18.25.33.59260 192.5.6.30.53 TIME_WAIT tcp0 0 139.18.25.33.59261 192.41.162.30.53 TIME_WAIT tcp0 0 139.18.25.33.59262 192.35.51.30.53 TIME_WAIT tcp0 0 139.18.25.33.59263 192.43.172.30.53 TIME_WAIT tcp0 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 + (UTC) From: Christos Zoulas To: current-users@netbsd.org Subject: Re: DoS attack against TCP services In article , <6b...@6bone.informatik.uni-leipzig.de> 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
Re: DoS attack against TCP services
Now the server has over 5000 TIME_WAIT connections. netstat -a -n | grep TIME_WAIT tcp0 0 139.18.25.33.59256 198.6.1.83.53 TIME_WAIT tcp0 0 139.18.25.33.59257 77.222.50.250.53 TIME_WAIT tcp0 0 139.18.25.33.59258 193.232.128.6.53 TIME_WAIT tcp0 0 139.18.25.33.59259 78.104.145.37.53 TIME_WAIT tcp0 0 139.18.25.33.59260 192.5.6.30.53 TIME_WAIT tcp0 0 139.18.25.33.59261 192.41.162.30.53 TIME_WAIT tcp0 0 139.18.25.33.59262 192.35.51.30.53TIME_WAIT tcp0 0 139.18.25.33.59263 192.43.172.30.53 TIME_WAIT tcp0 0 139.18.25.33.59264 202.12.27.33.53TIME_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 + (UTC) From: Christos Zoulas To: current-users@netbsd.org Subject: Re: DoS attack against TCP services In article , <6b...@6bone.informatik.uni-leipzig.de> 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
Re: DoS attack against TCP services
In article , <6b...@6bone.informatik.uni-leipzig.de> 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
Re: blacklistd is now available for current (comments?)
In article <201502040803.t1483mjm021...@server.cornerstoneservice.ca>, John Nemeth wrote: > > PAM wouldn't have access to the socket, so no it wouldn't be >that easy to add. Also, PAM is primarily for things that do >interactive logins IMAP should really be using SASL. However, that >would probably have the same problem of not having access to the >socket. Well, not entirely true since PAM runs in the same process, but yes trying to deduce which is the correct file descriptor to use is not an exact science. christos
Re: DoS attack against TCP services
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 Regards Uwe On Mon, 19 Jan 2015, Michael van Elst wrote: Date: Mon, 19 Jan 2015 19:51:31 + (UTC) From: Michael van Elst To: current-users@netbsd.org Newsgroups: lists.netbsd.current-users Subject: Re: DoS attack against TCP services b...@update.uu.se (Johnny Billquist) writes: Timeout should not depend on distance, and should actually be (at least) 2*MSS, which would be something in the several minutes range. It's 2*msl but msl can be a bit variable net.inet.tcp.mslt.enable = 1 net.inet.tcp.mslt.loopback = 2 net.inet.tcp.mslt.local = 10 net.inet.tcp.mslt.remote = 60 If I understand this correctly, these msl values are in units of 500ms, so 2*msl is the same value in seconds. What is considered a local connection is a bit of magic and if you set net.inet.tcp.mslt.enable=0 then everything is treated as a remote connection. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
