> > > I think it might be important to point out here how Shorewall > > > handles/uses these files. I don't use Shorewall, so I can't really > > > shed light on it. But these config files are really only one side of > > > the mirror. > > Sorry, I HAVE ZERO INTEREST IN A GUI, UNLESS THE RESULTING RULESETS > ARE SIMILAR TO THOSE BUILT MANUALLY with a one-to-one correspondance > to iptables/netfilter.
FWIW, shorewall does not have a gui. It reads the script files and builds appropriate iptables rules and applies them. > I'm not looking for advice on building firewalls as a newbie. > I'm looking for somebody that knows IPTABLES/NETFILTER, preferable > on Gentoo, and is willing to share a little information. I'm in the > process of building a gentoo based firewall to compare the robustness > against OpenBSD + pf. The really funny thing is a year ago, this > list was full of persons that debunked OpenBSD's security supremacy. > Now all I'm getting is a lot of 'hot air' and 'bull-loney'. Why are > so many people scared to manage there own firewall rulesets directly? I know iptables/netfilter. I've worked through all of the online documentation, I've read iptables books, I've implemented firewalls using just iptables. Knowing all of that information, I still suggest using a tool to help manage iptables. The reason is this: iptables, like PF on openbsd, allows for fine-grained control over every aspect of the network traffic going in and out of the box. Most folks, however, have little need for such fine-grained control over their firewall. They want a simple set of rules that allow outgoing traffic and certain incoming traffic. They don't care about masquerading vs DNAT/SNAT, what to enable/disable on the ICMP packets, which ones to reject vs deny, etc. They don't need a detailed explanation of why the order of the addition of rules to the table impact network performance as well as whether a certain rule actually disables traffic that a later rule would actually allow. So why is it so necessary to get down and dirty with iptables when there are supporting tools that manage all of these details quite well. > Personally, > when the occasional hacker does manage to penetrate a managerie > of obsticles, I like to watch what they do, and learn. Besides the > end result is there is nothing in my networks that if destroyed, > cannot be rebuilt. Anything of treasure value is protected by > a 4 foot air_gap. I guess I see talented penetration specialists > more as kindred spirits, as opposed to evil interlopers. This FEAR > of managing your own iptables/netfilters rulesets is not healthly. > Who the F*** wants to live life afraid? Conquer your demons > face to face, unless there really is truth to what the OpenBSD community > says about linux, 'linux based security is bullshit'. Oh, come on. Using a tool to assist in rules maintenance hardly qualifies as being afraid. Using a tool to assist in rules maintenance means you have better things to do with your time than operate at such a low level. Per your idiom, we should throw out higher-level programming languages because they take us all away from knowing microcode and assembler. The tools exist because they are an aid, not a crutch. > OpenBSD + PF is a piece of cake. OpenBSD comes secure right > out of the box. If the gentoo experts that peruse this list > read this email, surely they can direct one to examples where > the details of secure rulesets exist? > Surely someone is confident enough in their > iptables/netfilter rulesets to publish them? Being a gentoo and/or linux expert does not qualify one as an iptables expert. Perhaps the same cannot be said about openbsd wrt pf, but that's not for me to say. If you think iptables should be so easy to pick up, then go pick it up and make it work for you - no one is stopping you from that task. > Maybe the linux security models are not up to the task? > SElinux etc....? They are up to the task, which is why linux is used a heck of a lot more than openbsd... > PF rulessets are quite elaborate, but easily discernable. Iptables, as well, can be quite elaborate. Discernable is another question entirely. If you know what you're doing, you can create a discernable set of rules using custom chains and appropriate ordering. Most often, though, what you'll see is the list of rules in some quasi order which is supposed to satisfy security and accessibility requirements, but hardly show up as being discernable. > If you have ruleset capabilities, then look at this example, > and tell me what's deficient with it? > http://www.linuxguruz.com/iptables/scripts/rc.DMZ.firewall.txt First of all the connection tracking rule is too far down in the INPUT chain; it should come close to the top to shorten the amount of rules an established connection would need to travel through before being accepted. Secondly there's no filtering of traffic headed outbound. Typically any windblows & ipp traffic should be blocked at the router, as well as some dhcp and dns traffic, as well as any specific service that you want to allow to internal services but deny to external services. > http://www.gentoo.org/doc/en/home-router-howto.xml > It is a bit shallow, but at least this author is > not scared of iptables/netfilter fundamentals. You are correct in that it is shallow. The author gives a 'perfect world' iptables script without looking at the bad packet handling and ip address spoofing at least partially addressed in the previous script. The biggest shortcoming in this document is that, although the author goes through great details on how to enable connection tracking support for netfilter within the kernel, none of the iptables rules the author provides support the use of connection tracking! And I don't think that either script handles incoming FTP connections well at all. > (Booo) <this is where the Gentooers mess their britches?> This has nothing to do with gentoo or any other linux distribution, it has everything to do with iptables and their complexities and nuances. > The really sad thing in this whole thread, is nobody > has even mentiond which (kernel) sources to use, what > to disable/enable and why. Is this some sort of deep secret > or is the gentoo community un_caring about those who > simply want to learn about iptables/netfilter in a 2.6 > kernel environment? Hell, if this list and the greater > gentoo community do not have this aggregated knowledge > then let's develop it and document it and share it. > This is how we, as the open_source community distinguish > ourselves from the Vulture and his menion_buzzards that inhabit > Redmond! First of all you didn't ask these questions, you asked for rules themselves. Second of all the questions above are not specific to gentoo (why you would think they are is beyond me), they apply generally to linux and therefore to all distributions. So, here goes: 1. The latest kernel is typically the best to use because it will contain the latest security patches. Stay away from 2.6.12.2 or 3 (I forget which one it is) because they have a problem where they will report invalid packet issues because of a patch that was applied to networking in general without being applied to the specific tcp layers. I've been using 2.6.13 and have been very happy with it. 2. For enabling, I'd go to the gentoo doco you referred to earlier. It covers the basic kernel options that you'll want to include support for. 3. It is not a deep dark secret, it is just beyond the typical needs of the gentoo/linux crowd. 4. The information is out there (http://www.tldp.org/HOWTO/HOWTO-INDEX/admin.html#ADMSECURITY) you just need to know where to look. > sincerely, from a dreamer and a looser, and an simpleton, I'd agree with the second and third adjectives. > (but, I'm not afraid of any stinking rule_set, are you?) Seriously James, it has nothing to do with being afraid of rulesets, it has to do with how much folks need to know to get their systems secure, which tends to be very simple rules for the average linux user. Linux offers many, many, many more options than what I think that PF allows for. Each kernel option regarding the target and match support has a fellow relationship in the iptables rules. Many folks don't understand or need to know for that matter how to set up MARK support or MAC address support, etc. Finding the folks that know and understand and can apply all of these things means you've wandered into the elite of linux security, not the general linux community. I don't know much about the BSDs, so I cannot judge what the average BSDer knows about PF. My guess is that they rely for the most part on the out of the box security and have little need to dig any further. The same kinds of things can be said about iptables; most folks can get away with the default DENY policies whilst enabling outbound and existing connection traffic. That's why, when folks post questions regarding how to set up their firewalls we all throw out tools for them to use to help set them up - they're looking for a general setup that provides the protection they need w/o interfering with the access they want to have. The tools, as aids, quickly allow them to do that. And we don't have to deal with the follow up questions like how to enable this service or redirect that service; using the tool as an aid simplifies the process in general. -- [email protected] mailing list
