Dave Nebinger <dnebinger <at> joat.com> writes:
> 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. got any scripts/ files to share? > Knowing all of that information, I still suggest using a tool to help manage > iptables. OK, after I learn raw iptables/netfilter. > 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. Well, I hack embedded systems, often with only a state_machine/executive/min_rtos with a custom IP stack. Being able to 'analyze code segments' and discern-learn, gives me a solid specification/understanding to write custom assembler/c code for micro's or DSPs. Just one reason. I have many, many more. Finding templates and scripts for robust IPtable/netfilter rules should not be like pulling teeth.... I'm not trying to oversimply or make demunitive comments about iptables/netfilter, I'm just surprised that someone of your caliber, has not served up iptables/netfilters in clear, discernable examples, exclusively specific to iptables/netfilters. Sure shorewall and other efforts are noble, for the majority of users, but, surely there are more folks with my sort of interests in iptables/netfilters. > 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. Um, in my opinion, the lowest level, is frequently referred to as foundation, and that lack of foundation is why many programmers do not succeed. They do not have a foundational understanding of kernel, processes and files. Iptables/netfilters are as important as the scheduler, if you are going to network anything with a 2.6 linux kernel. > Per your idiom, we should throw out higher-level programming languages > because they take us all away from knowing microcode and assembler. Beautiful comments. I could not have said it better. Java is useful, perl is OK, Bourne necessary, but the MASTERS of computer engineering do it in assembler. Ever heard of the smartest or most accomplished Computer Scientist in our lifetime? Knuth...... Nobody even comes close to his body of work. Not Plauger not anyone. He has virtually cataloged most know algorithms. Impressive work, all in assembler. Not all would agree with this assessement, but few, if they bother to look at his 'body of work' are anything but tolally in awe of this man and his works. You might want to peruse what he has to say about high level languages, including C and C++. YMMV. http://www-cs-faculty.stanford.edu/~knuth > The tools exist because they are an aid, not a crutch. tools are better once one has mastered the fundamentals. iptables/netfilters is fundamental to secure linux(embedded or workstation or server). > 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. Agreed. I was just looking to jump-start the process by exuming robust base-line files to begin the journey.... What are the author and title to those books you have refered to and which are based on 2.6 kernel technology? > They are up to the task, which is why linux is used a heck of a lot more > than openbsd... This is good. Get fired up. Let's publish some raw, robust iptable/netfilter scipts, and hack/penetration-test the crap out of the rulesets. That establishes a proven foundation upon which much confidence can be built. Surely, more folks other than Russell Coker, know how to do this, and have publish a few cook_books somewhere. If not, why? > 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. OK, where do I read/learn more? Do you have any books you recommend? > > 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. Excellent comments! http://www.gentoo.org/doc/en/home-router-howto.xml > 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. > 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. > 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. Ah, excellent comments and a very nice reference. 3 days of googling did not reveal such a site. There a lot of confuse folks and old 2.4 base documents, fragmented in how they address (if any) issues related to 2.6. In short, much is dated material. It'd sure be nice if there was a single document related to 2.6 based iptables/netfilters issues. Sure it'd have to be a 'live document' but it sure would be useful. I'm pretty much solely interested in 2.6 based linux technologies. 2.4 had so many problems, particularly from an embedded perspective. > > sincerely, from a dreamer and a looser, and an simpleton, > I'd agree with the second and third adjectives. (WHAM-O) Aw, that one felt good! > 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. Funny, I have never considered any Linux/BSD user to be average. To me they encompasse the hope and the future of computing..... Encouragement and knowledge sharing are our greatest tools. > 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. Now you teasing an embedded linux hack. ARP/MAC machinations are of extreme interest to me. > 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. Time to disseminate knowledge? > 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. Some do some don't much like linux. VXworks, pretty much the largest commercial embedded RTOS vendor in the world, built most of their kernel technology off of good ole BSD. Sure they re-wrote much of the code, but's it's pretty much a BSD derivative with slick marketing and lawyers up the ..... PF is a relatively recent thing, in the BSD timeline. > 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. OK, I understand. But from the beginning I have tried to emphasize iptables/netfilters, not out of ignorance, but out of finally having a few weeks to drill deeply, build my first (linux) firewall, and have confidence in iptables/netfilter with a 2.6 kernel. After that, maybe I'll find time to digest and use shorewall, or maybe I'll start trying to use gentoo to put iptables/netfilter on a MOT:coldfire or 7447 processor..... A book exclusively on iptables/netfilter/2.6 would be keen. Since I was not very interested in low level things in 2.4, for a variety of reasons, I find all of those documents that are incremental to iptables/netfilter/2.4 to be cumbersome at best. I'd really like a document/book on iptables/netfilter/2.6 that never mentions or references the 2.4 kernel. In my world, the 2.4 kernel based technologies are dead, burried and the their wake is 2.6's debutante' I need foundation, it's going to be painful, and I can hardly sit still on this. I can always revert to a trusty Obsd firewall if needed.... In the mean time, spending my days with 2.6 kernels and less-than-robust iptables/netfilters scripts is wonderful way to spend the day. A beautiful woman once asked why she married the mechanic out of all the numerous suitors beckoning to her. She replied "because he torn it up on the first night, and has been working on it ever since". I like to tear up low level code and put it back together, piece by piece, too. That's how I learn, and I find it throughly enjoyable. Thanks so very much for your clarity of prose and information. Sincerest Apologies if I offended you, or any others. I'v come to expect quite a lot from the Gentoo community. After all it is the very best OS and folks I have worked with over the years.... James -- gentoo-user@gentoo.org mailing list
