Hi Bret, On Wed, 2003-08-27 at 11:06, Bret Comstock Waldow wrote: > On Wed, 2003-08-27 at 07:12, Paul Johnson wrote: [snip] > But please notice two things: > > 1) If I use one of those tools, it does something, sets up something. > What will it do? It's someone else's canned decisions about how to > implement the choices I select from what it offers. What do I end up > with? Are there any holes? How will I know if other choices I make > open up holes because I don't know how it's all coordinated? > > I'm working with a copy of Real World Linux Security, and the fellow > provides a complete firewall for SOHO, and then dissects it to show the > concerns and his choices. He also links it to adaptive firewall rules > to lock out attackers. > > And it's for Redhat, Mandrake, etc. I have to reconstruct it for Debian > to use it. So I need to know how to plumb it. > [snip]
Perhaps your frustration is better directed at the author of your Perl book for not fully explaining how all the plumbing is implemented on *your* system of choice. ;-) You might want to consider that there is some merit to the other firewall solutions out there. Not to dismiss the book or it's author, but the wide acceptance of these other OPEN SOURCE tools, subject to harsh critical review by security professionals, does give some comfort. Yet, you're right to be critical yourself so another approach for you to consider might be to start with an existing tool (any of shorewall, guarddog or Bastille, would be a good choice) and dissect it to learn how it works, including how it's rules are generated, are related to each other and invoked during boot-up, network interface start/stop and/or upon detection of some event. You should use the knowledge gleaned from that book (and others) to assess the various strengths and weaknesses of the rulesets, scripts, etc... and tune/tweak or reinvent the wheel as you envisage it should be. ;-) In short, don't use that text as a cookbook but learn the fundamentals and apply them to assess/tune an existing solution that best fits your needs. > > 2) [snip] > > My upset isn't appropriate here. I apologize. I think my questions are > appropriate, though. > > And I don't think leaving documentation like the above is very kind or > useful for newbies. If I'm to figure out how to solve the problem, I > need to know how, and leaving stress-inducing comments like that in > released code is a cop-out. If it's broke, provide a solution, or at > least a decent discussion of the issues involved, so I can work one out. A specific discussion on firewalls is perhaps better suited for a security-related mailing list or forum. Debian's "plumbing" is not that different from many other flavours of *nix so I'm sure you'll find any insights found there can be easily applied to your own circumstances. You might try the comp.security.firewalls news group. BTW, the author's note was not a cop-out; it was actually an insightful remark, albeit terse and presumptive of some sophistication on the part of the user. ...Murray BTW, my previous post should have indicated PRE-up and POST-down clauses on the iface statement for the ppp connection. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
