Реклама:

info.krc.karelia.ru

win -:|:- koi -:|:- iso -:|:- dos -:|:- mac

Start -:|:- Проекты -:|:- О нас

Using IP Address and Interface Together


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