Firewall rules – some more work
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
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.
deny all
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:
- delete the rule
- 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.