The FreeBSD Diary

The FreeBSD Diary (TM)

Providing practical examples since 1998

If you buy from Amazon USA, please support us by using this link.
[ HOME | TOPICS | INDEX | WEB RESOURCES | BOOKS | CONTRIBUTE | SEARCH | FEEDBACK | FAQ | FORUMS ]
Firewall rules - some more work 23 October 1998
Need more help on this topic? Click here
This article has no comments
Show me similar articles
see also Firewalls / ipfw - protect your subnet

I think I still have more work to do on my firewall rules.  Here are the areas which need work:

  • $fwcmd add deny all from any to 192.168.0.0:255.255.0.0 via ${oif}
  • IRC setup - the existing rule set doesn't allow new IRC connections.

In order to get IRC working, I have the following rules in place:

allow tcp from any to any setup

I will work on these problems in the order listed above.  Short cuts to the topics are listed below.

IRC Connections | Deny all

I'm using ipfw to determine what is missing.  I've added rules which allow traffic in certain ranges.  Then I usedthe accounting feature of ipfw to see where that traffic is occuring.  It's tedious.  I imagine I could be  tcpdump.   But I don't have the bpfilter stuff created for that.  I think I'd need to recompile my kernel to do that.  And I don't feel like doing that right now. 

Here's part of the output from "ipfw show":

02210         71       3124 allow tcp from any to any 0-1000
02211         78       8909 allow udp from any to any 0-1000
02220          0          0 allow tcp from any to any 1000-2000
02220          0          0 allow udp from any to any 1000-2000
02230          0          0 allow tcp from any to any 2000-3000
02230          0          0 allow udp from any to any 2000-3000
02240          0          0 allow tcp from any to any 3000-4000
02240          0          0 allow udp from any to any 3000-4000
02250          0          0 allow tcp from any to any 4000-5000
02250         26       4341 allow udp from any to any 4000-5000

As you can see, I'm getting traffic in the 0-1000, and 4000-5000 ranges.  It's a matter of refining the ports to see which ones are being used.  Now I'm sure tcpdump would be useful here.  BTW: I've just started compiling my kernel.

My next step was the following set of rules:

02201          0          0 allow tcp from any to any 0-100
02202         10        440 allow tcp from any to any 100-200
02203          0          0 allow tcp from any to any 200-300
02204          0          0 allow tcp from any to any 300-400
02205          0          0 allow tcp from any to any 400-500
02206          0          0 allow tcp from any to any 500-600
02207          0          0 allow tcp from any to any 600-700
02208          0          0 allow tcp from any to any 700-800
02209          0          0 allow tcp from any to any 800-900
02210          0          0 allow tcp from any to any 900-1000

You can see now that it's all within the 100-200 range.  So now I create a set of rules from 100-200.  And so on.  Eventually I found that it was port 110 which was being used.  If you check in /etc/services, you'll see that this is the Post Office Protocol (POP).  Silly me.  My mail client was going out and checking for mail at my ISP.  That's what I've been tracking.  Not IRC.

Some time later...
After about an hour of adding rules and checking the traffic, I suddenly realised something.  I added a new rule, removed all the others, and tried again.  This one solved all the problems I was having.  Here it is:
# allow all local traffic
$fwcmd add allow all from ${inet}:${imask} to ${inet}:${imask}

Pretty simple.  The problem was that I wasn't allowing local traffic.  And the above allows local traffic to go anywhere.  I have now removed the allow tcp from any to any setup rule mentioned above.

The default rule set within /etc/rc.firewall contains the following rule to comply with RFC 1918:

$fwcmd add deny all from any to 192.168.0.0:255.255.0.0 via ${oif}

However, with natd divert, this causes a problem (at least with -stable as of 1988/08/28).  When a packet goes through natd, it gets reinjected at the start of the rules.  Then the rules are seeing a packet from the outside with a destination within RFC 1918 space (ie within 192.168.*.*).

There are two known solutions:

  1. delete the rule
  2. upgrade to -current

#1 above is not very good.  #2 is the best option at present.  I took a third option, which is not recommended but does do some good.  I moved the modified rule to be above the natd divert.

After a bit of thought, I've concluded that the above solution will be sufficient for me.  I believe my ISP has sufficient filtering on their routers to prevent such attacks event reaching me.

I have also been told that IP Filter doesn't have this problem.  I may just investigate that option.


Need more help on this topic? Click here
This article has no comments
Show me similar articles