Реклама: |
It's an odd state of affairs when one decides it best to have the tun0
interface up, but not allow any data to be recieved from it. The more criteria the
firewall matches against, the tighter (or looser) the firewall can become. Maybe you want
data from tun0, but not from 192.168.0.0/16? This is the start of a powerful
firewall.
block in quick on tun0 from 192.168.0.0/16 to any
pass in all
Compare this to our previous rule:
block in quick from 192.168.0.0/16 to any
pass in all
The old way, all traffic from 192.168.0.0/16, regardless of interface, was completely
blocked. The new way, using on tun0 means that it's only blocked if it comes in
on the tun0 interface. If a packet arrived on the xl0 interface from
192.168.0.0/16, it would be passed.
At this point you can build a fairly extensive set of definitive addresses which are
passed or blocked. Since we've already started blocking private address space from
entering tun0, lets take care of the rest of it:
block in quick on tun0 from 192.168.0.0/16 to any
block in quick on tun0 from 172.16.0.0/12 to any
block in quick on tun0 from 10.0.0.0/8 to any
block in quick on tun0 from 127.0.0.0/8 to any
pass in all
You've already seen the first 3 blocks, but not the fourth. The fourth is a
largely wasted class-A network used for loopback. Much software communicates with itself
on 127.0.0.1 so blocking it from an external source is a good idea.
There's a very important principle in packet filtering which has only been alluded to
with the private network blocking and that is this: When you know there's certain types of
data that only comes from certain places, you setup the system to only allow that kind of
data from those places. In the case of the unroutable addresses, you know that nothing
from 10.0.0.0/8 should be arriving on tun0 because you have no way to reply to
it. It's an illegitimate packet. The same goes for the other unroutables as well as
127.0.0.0/8.
Many pieces of software do all their authentication based upon the packet's originating
IP address. When you have an internal network, say 20.20.20.0/24, you know that the only
traffic for that internal network is going to come off the local ethernet. Should a packet
from 20.20.20.0/24 arrive over a PPP dialup, it's perfectly reasonable to drop it on the
floor, or put it in a dark room for interrogation. It should by no means be allowed to get
to its final destination. You can accomplish this particularly easily with what you
already know of IPF. The new ruleset would be:
block in quick on tun0 from 192.168.0.0/16 to any
block in quick on tun0 from 172.16.0.0/12 to any
block in quick on tun0 from 10.0.0.0/8 to any
block in quick on tun0 from 127.0.0.0/8 to any
block in quick on tun0 from 20.20.20.0/24 to any
pass in all