IP Tables, Firewalls, OpenVPN and the DI-524
Post date: Jul 25, 2011 12:18:20 AM
Tuesday, December 4, 2007, 11:41 AM
Posted by Administrator
Know ye therefore that they which are of faith, the same are the children of Abraham. And the scripture, foreseeing that God would justify the heathen through faith, preached before the gospel unto Abraham, saying, In these shall all nations be blessed. (Gal 3:7-8)
As a justified heathen, I say I am blessed to be one.
I have a network at home, about eight or so computers, but really three regular use ones and I don't care for stringing wire, and I have a wireless router, so making it work is important to me. Now it is possible, without too much trouble, to use an encrypted session (using WPI PKI not WEP, WEP is easily hacked, WPI is much safer) but that means that I have to have a long key handy whenever I want to log in, and hope that my particular card and OS support it. Typically Linux does support it, but I do try out various distributions from time to time and getting encryption working between different hardware can be tricky. There is a better alternative: introducing OpenVPN! (and you should hear a crowd cheering in your imagination at this point.)
OpenVPN is a way to tunnel all your traffic through a network connection, wireless or wired, and it works on Windows, Mac and most Linux, plus it is software so you don't have to do any special hardware work beyond the minimum. Essentially, it gives you a method of keeping your traffic secure without having to worry about special drivers.
I'm using it to let my wireless network be totally open (well, the admin of the router isn't but that's about it.) This means that I can connect to my wireless network without needing any passwords or encryption at all. It also means that anybody driving down my street or visiting the neighbors could too. I'm a friendly guy, and I do try to be helpful, but I'd rather not worry too terribly about what my Internet connection is being used for, so I'd rather that I was the only one allowed to use it. This is where a good firewall comes in. If the connection from the wireless network has to come in on VPN because the firewall blocks anything else, that means that VPN is now required.
Enough with the theory, the application was not bug-free. In fact, after much testing, I had found that I had no trouble using OpenVPN between machines on the wired network, but a whole heap of trouble when I tried to use it on the Wireless. Eventually, with a lot of testing and tracking packets, I was able to confirm that it seemed packets could come from the wireless, talk to the VPN, but then they couldn't come back across the wireless to the machine making the requests. It might be possible, but it is certainly not easy to change that behavior on the DI-524 D-Link wireless router I have.
So eventually, rather than trust the thing to manage my network, I just bypassed it by putting the OpenVPN (and Internet Gateway) server on the "LAN" side of the router. This means that now people connecting to the Wireless router can communicate directly with the OpenVPN server, without going through the standard router manipulation. It also meant I had to disable DHCP on the Wireless router since it couldn't make anything but itself the gateway and enable it on the interface that connected the OpenVPN server to the LAN side of the router. Not satisfied with that though, I set them both to be DHCP servers since the OpenVPN server seems to get precedence and just set them to assign non-conflicting ranges. Now it is possible to get on the Wireless even if the OpenVPN server isn't doing DHCP correctly, so it makes it possible to troubleshoot, but typically the OpenVPN server is doing fine.
Once I passed those hurdles, I have no trouble getting a wireless connection, and it does DHCP assignment as you'd hope, DNS assignment (and forwarding) and all that good stuff, but I still want to lock out the neighbors. Actually, I'm trying to lock out anybody that might be using it for anything illegal, but how well do you know your neighbors really, do you know their friends? So it is time for some healthy paranoia.
In with IP Tables. Here, I'm not really done. I've got something that works, but not as perfectly as I like so I'm going to refrain from passing on any advice on exactly how your firewall should look, suffice it to say that there are plenty of tools and manuals out there for you to consult, but I do have some other advice:
Freenx and Nomachine rock, try them. It's like VNC (remote computer management) but smoother and better. Nomachine is clear that their product is not the same as Freenx, but you can use them together so I do. I would recommend trying Nomachine first if you have the option, since I had some initial trouble getting documentation. I had to do some experimenting to find out exactly how to set everything up with FreeNX, but if you're comfortable with that sort of thing, it isn't too bad. Of course you don't really need a GUI interface for your server, but why not have one if it is easy and, as far as I've been able to tell, secure. Freenx and Nomachine have a good system set up, using public/private key based ssh tunneling.
Set up a simple "fix my router script" when working on your network remotely. For me, I have a script I call "insecurerouter.bash" which pretty much opens the system up to all traffic. I keep that machine pretty safe anyway, so it shouldn't be easy to compromise, but it does mean that anybody can connect to it or the Internet through it. I then set up an infinite looping script to check for the presence of a file every five minutes, and reset the router if it is there. Then I run another script on the connecting machine to remove it up to once a minute. One the router it looks like:
chown unprivuser:unprivuser /home/unprivuser/.routerreset
if [ -f /home/unprivuser/.routerreset ]
echo "RESET ROUTER AT `date`"|wall
echo "No reset at `date`"
and on the other machine I've got password-less ssh login set up (using encrypted keys and keyring to keep them in memory) and it has a screen session running with the command:
(while true;do date;ssh n 'rm -v ~/.routerreset';sleep 60;done) &
also inside a screen session. Sure, there is a little verbosity there that isn't really required, but sometimes it is nice to be able to check on what's happening, and screen has a very low overhead. Essentially, this means then when I'm testing a new firewall, if I manage to lock myself out, no more than five minutes later, I can log back in and try to figure out what went wrong. If you are building your own firewall, things will go wrong, and that leads to my next suggestion.
This one is about IP Tables, and while I don't feel qualified to preach on the proper usage (I'm not currently filtering OUTPUT) I do feel it is worth noting that it is MUCH easier to troubleshoot if you log every unidentified packet you drop. That means that you can check your logs when something doesn't work and see if it is due to your rules, and if you're hand-coding your rules like I am, that is a lifesaver.