Limiting closed port RST response

Ian Smith smithi at
Wed May 2 11:03:23 UTC 2012

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 at>
 > > 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

#% 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)

 > > 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

More information about the freebsd-questions mailing list