Hi Dave,
* Dave Nebinger <[EMAIL PROTECTED]>, Friday, September 9, 2005, 4:23:07 PM: >>> Dude, trying to use iptables directly was your first mistake. >> no, it wasn't. >> >> I have written some "small" example script >> http://forums.gentoo.org/viewtopic.php?p=377447 >> that (IMO) is quite modular... > Yes, Timo, it is quite modular and quite thorough. It represents a great > job at developing a general set of rules. > But I would raise the following issues: > 1. FTP support: You've allowed for the active ftp protocols on ports 20 & > 21, but what about passive? This traffic will usually be on the higher > ports (typically a range specified in the configuration for the ftp daemon). > I do believe that if the ftp daemon tries to open a passive connection > outbound it's going to get knocked off at the knees. If I open a ftp-connection from the inside to a ftp-server on the outside, it should get caught by the iptables-ftp-module and the RELATED rule. > 2. Measure the checks: The more checks that a packet goes through, the > longer it will take to travel through the iptables stack. Your script has a > lot of checks in it. Consider a pgp packet as it traverses all of the > chains etc. that you've specified. You're probably looking at 30+ checks at > least (although I haven't counted each individual check, but I'm confident > it is quite a large number). That's a significant number of hops and means > the packet is going to be hanging around on the box a lot longer than what > it really should. Yes, I have MANY checks. I have had no probleems while using this and some newer versions of this script. However this seems to bee a problem for users that get many small packets per time-unit... (think p2p here). As you state below, this is no universal solution, but was built to be easily reconfigurable. > 3. No detail on why the checks are ordered in the way they are (is there an > order?): As #2 indicates, the increased number of checks that a packet > needs to be pushed through means it will hang around on the box longer. > Therefore they should be ordered to give priority to either a) heavily used > ports or b) ports you want to have processed sooner rather than later. There was no reason ;-). see above > 4. No reason for accepting specific outbound traffic: I tend to prefer > allowing all outbound traffic and filter on those ports that shouldn't be > going outbound (i.e. dhcp responses, dns responses, ipp packets, windows > networking stuff, known trojan/virus ports). It greatly reduces the number > of checks outbound traffic needs to go through. I filter outbound for various reasons: generally, I like to know what happens on my internal network. You can catch misconfigured software some malware and some bad users with that. > Obviously to improve the throughput you'd have to alter the script to use > multiple ports on accept lines. Once you start doing that, though, you lose > the modularity that you've built into the script. You are probably right in that. > The point that needs to be made is that there is no 'one iptables script > fits all'. Each site, each box for that matter, has it's own set of > services and it's own usage criteria. To that end the iptables rules will > (should) always vary from box to box, whether it is a server, a desktop, a > gateway, or some combination of the three. Of course. > New users looking to get their boxen online grab scripts like this thinking > they are going to secure it for them, yet they don't understand the nuances > of the individual rules nor how they are grouped. How many folks that grab > the script are going to know what the teamspeak or pgp ports are for and > whether they need them or not? How many are going to know that they've > exposed their system to incoming teamspeak packets, whether they have > teamspeak or not? Even more: They are exposing their box to ALL packets on the teamspeak port. But IMO, it's easier to learn than some gui-things, you don't have to transfer it over network to your firewall-box (who has X on a firewall??? :-) ) and its easy to reconfigure. Thanks for the feedback. really. Timo -- gentoo-user@gentoo.org mailing list
