Date: Wed, 2 May 2012 21:03:03 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Arthur Chance <freebsd@qeng-ho.org> Cc: freebsd-questions@freebsd.org Subject: Re: Limiting closed port RST response Message-ID: <20120502204037.L91148@sola.nimnet.asn.au> In-Reply-To: <4FA0FF9A.6010300@qeng-ho.org> References: <20120501120038.45BB71065772@hub.freebsd.org> <20120502043016.J91148@sola.nimnet.asn.au> <4FA0FF9A.6010300@qeng-ho.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 May 2012, Arthur Chance wrote: > On 05/01/12 20:01, Ian Smith wrote: > > In freebsd-questions Digest, Vol 413, Issue 4, Message: 7 > > On Tue, 01 May 2012 12:59:36 +0100 Arthur Chance<freebsd@qeng-ho.org> > > wrote: > > > > > Every once in a while the nightly periodic security checks tell me I've > > > got a kernel message > > > > > > Limiting closed port RST response from N to 200 packets/sec > > > > > > where N> 200. The problem is that it doesn't say which port was > > > involved. Is there any way to find that out so I can try tracking down > > > the problem? AFAICT tcpdump doesn't have a way saying "closed ports on > > > this machine" as a filter. > > > > % sysctl -ad | grep vain > > net.inet.tcp.log_in_vain: Log all incoming TCP segments to closed ports > > net.inet.udp.log_in_vain: Log all incoming UDP packets > > Thanks, that's what I need. There's another option you may want to consider, especially once you work out who or what's originating these. From an /etc/sysctl.conf: #% 9/8/6 net.inet.tcp.log_in_vain=1 net.inet.udp.log_in_vain=1 #% 7/10/8 # can't use this and respond to traceroutes # net.inet.udp.blackhole: Do not send port unreachables for refused connects # net.inet.udp.blackhole=1 # net.inet.tcp.blackhole: Do not send RST when dropping refused connections #% 14/4/10 was 1, still see some resets sent (see /sys/netinet/tcp_input.c) net.inet.tcp.blackhole=2 > > With sysctl net.inet.tcp.log_in_vain=1 you get a message per instance, > > likely aggregated into 'last message repeated N times' at those rates. I > > add ipfw rules for heavy hitters on particular ports&/or from > > particular hosts to cut both the noise and (albeit slight) load. > > This is on an internal LAN behind a firewall, so there isn't (I hope!) > anything external causing it. There's a motley bunch of hardware and software > sharing the LAN and I'd like to identify the source of the problem just for > my peace of mind. Good idea. There are a few reasons you may see inbound TCP connections you're not expecting, including general background noise from bots scanning everyone for everything, late responses from genuine outbound connection attempts, and bots hitting other sites using your forged IP address, so you get a bunch of SYN ACK packets out of the blue, most often from port 80 to some random (or particular) port. If using udp.log_in_vain=1 too, you'll see such as late responses from DNS servers (even from localhost) and assorted bot scans, and at times unsolicited responses from DNS servers from someone/s again forging your IP address in requests, possible on a large scale. These may look like attacks on your system, but you're just one of many forged addresses, the attack being on (what you see as) the source system, big in 2010. Happy hunting, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120502204037.L91148>