ipfw subnetting

[Ian Smith]

On Mon, 21 May 2012 16:30:59 +0100, Paul Macdonald wrote:
 > On 21/05/2012 14:50, Ian Smith wrote:
 > > In freebsd-questions Digest, Vol 416, Issue 1, Message: 26
 > > On Mon, 21 May 2012 10:06:12 +0100 Paul Macdonald<paul at ifdnrg.com>  wrote:
 > > 
 > >   >  can anyone suggest what i'm doing wrong here.
 > >   >
 > >   >  Desired:    drop everything from 180.0.0.0 to 180.255.255.255
 > >   >
 > >   >  ipfw -q add 137 deny all from 180.0.0.0/8 to any
 > > 
 > > t23# ipfw -q add 137 deny all from 180.0.0.0/8 to any
 > > t23# ipfw show 137
 > > 00137    0       0 deny ip from 180.0.0.0/8 to any
 > > 
 > > So what doesn't work?  (apart from scattergun removal of small pieces of
 > > a whole lot of Asian countries, incl. Japan, Indonesia, Australia, .. :)

 > it was intended as a required temporary measure,
 > but even though it was listed in my ipfw list, i was/am still seeing traffic
 > coming in via addresses such as 180.248.x.x

Ok.  Coming in to what service/s?

 > A very open firewall test script is as follows:
 > 
 > 00010 allow ip from any to any via lo0
 > 00081 deny log ip from 180.0.0.0/8 to any
 > 00100 check-state
 > 00101 allow tcp from any to any established
 > 00102 allow ip from any to any out keep-state
 > 00103 allow icmp from any to any
 > 65535 deny ip from any to any
 > 
 > but i'm still seeing traffic from
 > 
 > 180.149.29.102

Banglalion Communications Ltd. WiMAX Operator. Bangladesh.

 > 180.234.116.61
 > 180.234.36.44
 > 180.234.237.119
 > 180.234.72.115

Augere Wireless Broadband Bangladesh Limited. (FWIW)

 > I must be doing something wrong!

If you're using just that order, denying 180/8 BEFORE the check-state, 
then incoming traffic from 180/8 not being dropped (and logged) at rule 
81 would represent a serious bug in ipfw, worthy of a PR.  But this 
may not be quite as it seems .. for example, even when dropped you'll 
see such packets from tcpdump, which are hooked before the firewall.

Where and how, past the firewall, are you detecting this traffic?  What 
sort of traffic?  Are you sure sysctl net.inet.ip.fw.enable=1 ? Seeing 
`ipfw show` over a period, even better `ipfw -t show` with timestamps, 
could convince us the firewall was actually otherwise working ..

In your later post to Michael you had that rule 137 AFTER check-state, 
which means that packets from 180/8 - in response to outbound requests 
by you (or your rootkit :) to those addresses - might indeed pass.

 > 00102 allow ip from any to any out keep-state

keep-state for 'ip' or 'all' traffic (rather than specifying tcp, udp or 
icmp) doesn't make much sense, and could have dangerous consequences of 
allowing any sort of return traffic from (say) 180/8 initiated from your 
end, but only if check-state were BEFORE you've denied 180/8 traffic.

Rather than show the script, please post results from ipfw show, and a 
few of the log entries of denied packets (with your addresses obscured 
if need be).  And some logging from where you're detecting those hosts?

cheers, Ian