From owner-freebsd-questions@FreeBSD.ORG Wed May 2 11:03:23 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3058106564A for ; Wed, 2 May 2012 11:03:23 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 174158FC15 for ; Wed, 2 May 2012 11:03:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q42B34PQ088153; Wed, 2 May 2012 21:03:04 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 2 May 2012 21:03:03 +1000 (EST) From: Ian Smith To: Arthur Chance In-Reply-To: <4FA0FF9A.6010300@qeng-ho.org> Message-ID: <20120502204037.L91148@sola.nimnet.asn.au> References: <20120501120038.45BB71065772@hub.freebsd.org> <20120502043016.J91148@sola.nimnet.asn.au> <4FA0FF9A.6010300@qeng-ho.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-questions@freebsd.org Subject: Re: Limiting closed port RST response X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 11:03:23 -0000 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 > > 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