New iptables configuration critique
I've been experimenting with this iptables software. I don't know how well i've prepared it but i've decided that its best to block everything and then slowly open things up. The box that this configuration is set up is on a server supplying DNS, DHCP, and samba really soon. Does this look like a good configuration?
Code:
[root@mun-175-25 ~]# iptables --list |
could you please post your actual iptables *script*?? :)
|
I'll have a better look at this after dinner, but to get you started:
1. Your FORWARD policy is set to ACCEPT, so there need not be those two rules already there, which are identical anyway. If you want only ESTABLISHED, RELATED connections forwarded, then set to policy DENY. 2. Ditto for OUTPUT chain. 3. I have other comments about the INPUT chain, but mostly it's that you have lots of duplicate rules appearing in various places on the chain (like the first INPUT rule is repeated near the bottom). I do admit though, that it is a little easier to actually see your intent with this view, rather than the script itself, I find, at least. But showing the script might help isolate where you created duplicate rules. Finally, if you have the idea of "closing everything down and then opening selected services up" no chain should be POLICY ACCEPT. |
Ok here's my detailed audit from top to bottom. (I've made a new post rather than edit in case you're subscribed.)
I want to stress that this is for a home-style installation. If you were a system administrator for a SOHO or something my answers would be quite different (more strict). FORWARD Make it POLICY ACCEPT and forget the rules (well, the one rule twice). You don't really need to manage forwarding that much, you can leave that to the firewalls of the respective computers on your LAN. That's what I do at least, since if you're not DNATting (port-forwarding) you don't really need to worry about attacks on your LAN from the outside. INPUT Honestly, I'd make a ruleset more like this (pay attention to the bold): Code:
Chain INPUT (policy DROP) When you make the script you'll have to change those two rules to "--match multiport --dport ssh,etc." I've also compressed some rules and re-ordered them, putting what I assume will be most important services at the top, since those will get matched and ACCEPTed without having to traverse the entire chain to get to them. That's why I clustered the LOGs at the end. OUTPUT If your chain is POLICY ACCEPT you don't need any of those accept rules. Unless you're super paranoid about trojans broadcasting things you don't really need to worry about OUTPUT. Now, if there are a few services you really want to block then just make DROP- or REJECT --with-icmp-host-unreachable them. in_tcp I like this: Code:
Chain in_tcp (1 references) Now, since you like to do a heck of a lot of logging, which is a good thing, I would seriously suggest you look at ULOG and `ulogd`daemon and log to a MySQL database instead of syslog. Looking through syslog for all this information is going to be hard, but with it all in a nice SQL DB it'll be a snap. I just spent the last few months writing a proprietary wireless authentication server with logging, and I use ULOG. HTH ;) |
Wow! This is a lot to take in very late at night. I'm going to look over these suggestions in the morning and get to work. One thing that I may have a problem with is locating the script. I entered everything through "iptables" commands and saving via the "service iptables save" command. I'm very much a newbie at this so if you could point me in the right direction so that I can expedite the replies tat would be great. Thank you both, win32sux and michaelsanford.
|
It's a lot to put out too, but I've spent the last 4 months working intensively with iptables. I'll try not to take that for granted :P
To get a script, you'll need to enter /usr/sbin/iptables-save > rules.sh The thing is, that won't get you a shell script you can run, it'll get you a file that looks like this Code:
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002 Code:
#!/bin/sh I've been listening to LQ PodCast and just watched Revolution OS (again, bought the DVD) so if you post the output of your iptables-save > saved.txt file I can convert it to a script for you. You can take it from there... (On a tangent, this gives me an idea for a GUN program...translating iptables-save-ed data into shell scripts. hmmm maybe I should finish my thesis first, eh) To give you an idea of a start up script, here is a very small snippint from one of mine: Code:
usr/sbin/iptables -t nat -F |
Alright! So I'm awake at... 9:28 on a Saturnday? How'd that happen. :p Anyway, the output i've recieved from the iptables save is below. I noticed how clean your code was. It would be VERY easy to deavtivate a port or service very easily using a "Bad Services" string like that.
Code:
# Generated by iptables-save v1.3.0 on Sat Jul 23 09:25:53 2005 |
This is now going to be a .sh executable file you need to chmod +x. I haven't re-ordered the rules as I suggested above, I'll leave that for you to do. Since these rules are all -A you can just change the order they appear in the script and that will change the order in which they're added.
You can also add your own variables like I did for service ports. You can either reference them by port number or service name (i.e., 22 and 'ssh' are synonyms, as defined in /etc/services). This isn't the most iron-clad firewall script ever, but it should do. Code:
#!/bin/sh |
Success...in the Future!!!
michaelsanford, I deeply appreciate what effort you have put forth to this small project of mine. I've been cleaning it up here and there but I believe that it will take a while before I will be able to completely perfect this art of security. I do believe it to be a very intriguing topic that I will be referring back to this thread for. As for those definitions that I love, I'm spending the rest of my shift at work on them. My experience in Java has paid off as I can appreciate reusability like that. Good luck on the parser too!:study:
Code:
#!/bin/sh I wanted to address some things that I didn't get the chance to at the beginning of the thread. 1. Forwarding: I had no clue the rules were repeated. :P Logically, it does make sense to leave the policy at ACCEPT and leave it alone after that. It's sole purpose is to forward, nothing else. Unless there's some fancy pre- and postrouting techniques someone wants to implement. 2. I couldn't operate my computer setting the INPUT policy to DROP. Essential programs like the BASH shell were crippled by its affects. Good thing I didn't save those settings. Of course there's always CTRL + SHIFT + ALT + F3 (and others). 3. Duplicates, missing targets, etc. are simply signs of a novice :) 4. "The RH-Firewall-1-INPUT" chain keeps reappearing out of the blue. I have no clue where it is coming from or how to stop it at this moment. I will probably have to locate the REAL iptables script to figure that out I suppose. |
Quick question. Why won't the chmod work?
Code:
chmod +x rules Code:
#!/bin/sh |
There's a tutorial for iptables at http://iptables-tutorial.frozentux.n...-tutorial.html
It answers a lot of your questions, esp about POLICY choices.. eg.. If there is an ACCEPT policy, why write ACCEPT rules? (your OUTPUT chain) The idea of scripting a set of rules works best when there is a reason to load rules in a particular order, rather than just getting them all in place quickly, or to add comments to the file. The netfilter team created iptables-save & iptables-restore to peform the quick dump and relad routines. iptables-restore uses the specific iptables-save dump format to reload the rules. It can add an extra field to the dump showing how many packets have passed through each rule. You can use this to gauge if rules can be re-ordered to place frequently hit rules earlier, making the tables faster, or if rules are having any effect even.. eg $IPTABLES -t nat -A POSTROUTING -m mark --mark 0x9 -j MASQUERADE $IPTABLES -t nat -A POSTROUTING -s 192.168.1.0/255.255.255.0 -o eth0 -j ACCEPT $IPTABLES -t nat -A POSTROUTING -o eth0 -j MASQUERADE Scripting would allow comments to be added about which interface is external, internal and dmz etc. And comments why 192.168.1.0/255.255.255.0 doesn't need to be MASQUERADED. I would suggest reading the tutorial carefully and starting with one of the well commented scripts at the end of the tutorial.. The RH-Firewall-1-INPUT chain comes from the RedHat Security Level setting. Set it to off. There may be a script in /etc/init.d called rc.firewall or similar as well.. Do chkconfig --list to see if it is active.. |
THANKS Perter_Robb! I've been looking at the recommended site for some time now and I can honestly say that I have learned a great deal from it. I'm still making my way through it though. It's a good thing that you explained how iptables save and restore work. According to the save that I posted some of the tables were neverr put to use. I didn't delete them but they are further down the list. As for the scripting I was interested in it and it just happened to be iptables that I was interested in at the time. I appreciate the extra help.
|
All times are GMT -5. The time now is 09:12 PM. |