Please create an account to participate in the Slashdot moderation system


Forgot your password?
Book Reviews Books Media

Linux Firewalls 91

David Martinjak writes "Linux Firewalls, authored by Michael Rash and published by No Starch Press, covers five main topics: traditional packet filtering with iptables, port scan detection, snort rule translation, port knocking, and log visualization. At first I considered only skimming the chapters regarding iptables packet filtering. I have a good amount of experience with iptables, and have been running it for several years. Thankfully I decided to give the first chapter a good read. Right from the start, the book presented valuable information and pulled me in." Read on for the rest of David's review.
Linux Firewalls
author Michael Rash
pages 336
publisher No Starch Press
rating 9
reviewer David Martinjak
ISBN 1-59327-141-7
summary Linux Firewalls discusses the technical details of the iptables firewall and the Netfilter framework that are built into the Linux kernel.
The chapters about iptables packet filtering are crucial for any reader new to networking or firewall administration. Experienced users might pick up a tip or two, as well. Linux Firewalls contained a wealth of knowledge about packet structure in addition to a solid explanation of iptables usage. I was rather impressed by the variety of information presented in the early chapters. The book of course detailed the syntax and logistics of iptables, but also provided detailed examples of attacks at the network, transport, and application layers.

Packet filtering was followed by port scan detection. When I first started using GNU/Linux, one application in my toolbox was PortSentry. PortSentry was designed to counter-act port scans, and minimized the amount of information that could be discovered from a scan. I lost track of PortSentry for some reason, but was glad to have almost re-discovered it in a new form. PSAD is the Port Scan Attack Detector and was developed by the book's author, Michael Rash, along with contributions from the open source community.

PSAD was created as a lightweight network intrusion detection component. The book explained how PSAD can quickly react to port scans by analyzing iptables log entries; and effectively reduce the surface area exposed to the attacker. The differences between PSAD and PortSentry were also enumerated, which showed several advantages for using PSAD.

Linux Firewalls did a fantastic job of detailing how to install and configure PSAD. This seems to be par for the course with No Starch Press as each book I have read from them was meticulous with regards to installation and configuration specifics. Additionally, the topics of installing and configuring the book's other two main applications, fwsnort and fwknop, were also properly addressed.

I don't want to give away too much of the material in Linux Firewalls; so I will just say that the chapters on fwsnort, fwknop, and log visualization were all on par with the earlier sections of the book. The information did not let up at any point — there were useful examples and details throughout each chapter. Additionally, there was a good amount of consistency with regard to how the chapters progressed, and the type of information that was presented along the way. All together, Linux Firewalls was an impressive read.

There were no real disappointments with this book. The reading did get a bit tedious at times with regard to configuration specifics, but it was only due to the depth of helpful explanation. Had I been working with the applications while reading (instead of just reading), the content would have been much more relevant. In the end, however, the variety resulted in a rather impressive and enjoyable book. The coverage of psad, fwsnort, and fwknop were welcomed additions. Each of the central topics were thoroughly explained in an informative, yet engaging manner. Essentially, I did not want to stop reading.

The netfilter/iptables software is licensed under the GNU General Public License, and can be found at The psad, fwsnort, and fwknop applications are licensed under the GNU General Public License Version 2, and can be downloaded from

The publisher hosts a Web page which contains an online copy of the table of contents, portions of reviews, links to purchase the electronic and print versions of the book, and a sample chapter ("Chapter 10: Deploying fwsnort") in PDF format.

David Martinjak is a programmer, GNU/Linux addict, and the director of 2600 in Cincinnati, Ohio. He can be reached at

You can purchase Linux Firewalls from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Linux Firewalls

Comments Filter:
  • Good book (Score:1, Interesting)

    by PhotoJim ( 813785 )
    Sounds like a terrific book. I find firewalling and routing to be one of the least intuitive parts of networking so this book might be a good purchase for me.
    • Re: (Score:2, Insightful)

      I'm already a firewall admin, mostly iptables with a bit of CheckPoint/Nokia thrown in, this looks like it could be a good purchase. Thanks {:^)
  • I'm completely clueless about how Linux firewalls work. Is this suitable for noobies or is there an O'Reilly title out there for me?

  • iptables (Score:5, Funny)

    by caluml ( 551744 ) <slashdot@spamgoe ... minus poet> on Wednesday January 02, 2008 @04:50PM (#21886780) Homepage

    fw ~ # iptables -I INPUT -j DROP
    Connection timed out
    myhost $
    It's all the firewall I need! (Who here hasn't messed up iptables while remote, anyway?)
    • Re: (Score:1, Funny)

      by Anonymous Coward
      sheepish hand raise at the 'aw fuck' moment of a lifetime.
    • by drpimp ( 900837 )
      Yup been there done that.
      I issued the standard Homerism, "DOH". Why did I do that?

      Fortunately we have a KVM/IP device connected to my machine that saved a trip to the data center and two hours of traffic into LA during rush hour.
    • Hmm... I did that once, back in 2000 or 2001 somewhere.  Fortunately I had console access to the firewall at the time.

      The only question is, can anyone top:

      /var/www/tmp# rm -rf .*

      that was around the same time.

      There's something to be said for the school of hard-knocks way.  I'm not yet sure what it is, but someday I'll figgure it out.

      • And why did you hit me in the knee with candle sticks?
      • by caluml ( 551744 )
        I'm glad that GNU rm allows you to put -rf at the end of the command. It gives me slightly more time to think.
        rm ./* <quick pause> -rf <enter>
        And yes, I too used to use revert scripts on atd to recover in 5 mins - but I'm so l33t these days... :)
      • Yes.

        OS X lets you drag and drop files onto the terminal and it will automatically insert the file name. It's a nice mix between GUI and command line (rsync -a [drag folder] remotehost:dest)

        One day I tried deleting a ton of files doing rm -rf [drag folders]. Problem is I had too many and it truncated the input. I ended up doing a rm -rf or lots of files and /etc/

        That was fun.
      • I once did something slightly less damaging, but even so enough to give me an hours long headache. To put a long story short, let's say that having ALL files in your hard disk belonging to root.root is something you shouldn't wish to your worst enemy...
    • To mitigate that same problem, I wrapped my iptables shell script with a "sleep 30" and "iptables -F" commands. Live and learn, right? :-D
      • by weicco ( 645927 )

        Another good solution would be to add cron job to wipe out all the rules every 30 min or so. You get nice ~25 min to figure out "why the heck I did that" and possibly some time to explain to your boss why that fw isn't yet working. When you've finally got the rules right, remember to remove the cron job or you get more "nice" time to seek out for a new job ;)

      • You might have meta-moderated someone else's moderation that was identical to yours perhaps?
    • Re:iptables (Score:5, Funny)

      by Tmack ( 593755 ) on Wednesday January 02, 2008 @05:33PM (#21887238) Homepage Journal

      fw ~ # iptables -I INPUT -j DROP
      Connection timed out
      myhost $
      It's all the firewall I need! (Who here hasn't messed up iptables while remote, anyway?)

      Its more fun to mess it up on purpose []...


    • by dpilot ( 134227 )
      Try it on your mother's system from 600 miles away, and the only "console" is a cousin on the telephone typing at her machine, because your mom is too uncomfortable doing anything but a few basics on the computer, and pretty much forget an xterm.
      • by Lennie ( 16154 )
        There is a really simple solution for when you've been stupid, it's to not save any changes to disk/flash until you are sure it's right.

        Then atleast you can ask someone who is at the location to pull the plug and start it back up.
        • by dpilot ( 134227 )
          That particular problem was with the iptables line that opened a pinhole in the firewall so I could ssh in from my home. I'd set things up at her house, and couldn't test until I was home, again. It turned out to be a udev persistent naming problem. Her hard drive was failing (Thanks for the warning, SMART.) and I'd preinstalled a new one at my home. When I installed it in her system, eth0 turned into eth2. I fixed her firewall script so it all worked, but forgot about the script in another spot that o
          • by Lennie ( 16154 )
            Ofcourse it depends on the situation. :-)

            Sometimes there is no easy solution to prevent your self from shooting yourself in the foot.
    • Re: (Score:1, Informative)

      by Anonymous Coward
      That is why you have a script running that will revert the firewall settings within ten minutes if something messes up. I disabled the network interface to a server once and had to get someone to drive over to the datacentre and reboot it.

    • I call it the Geek equivalent to the walk of shame....gonna have to get up and go reboot it.
    • Hello, my name is Rich, and I have screwed up iptables And *why* is it you have that 'aw sh*t' moment nanoseconds AFTER you hit enter??? Could I get at least one BEFORE I screw something up really badly? Just once ?
  • OpenBSD PF Firewalls (Score:5, Informative)

    by Anonymous Coward on Wednesday January 02, 2008 @05:04PM (#21886962)
    No Starch Press also has a new book out on firewalling with PF. IMO, PF is better and much more intuitive when building rulesets than Linux firewalls.
    • I don't see it as intuitive at all . Even it's really prone to errors(made by the person creating the firewall) because of the "quick" options. I've seen some firewalls made with PF and the complex ones (above 30-40 rules that do different things) all had serious errors made by the person who made the firewall because he got "confused" and there were rulles that made almost all the firewall pointless. Also the thing that the last rule matching (except when using quick) makes designing complicate comparing t
    • by Homology ( 639438 ) on Wednesday January 02, 2008 @05:36PM (#21887256)

      No Starch Press also has a new book out on firewalling with PF. IMO, PF is better and much more intuitive when building rulesets than Linux firewalls.

      I've been using OpenBSD PF [] for years and is much better than iptables. There is also a nice, up-to-date User's Guide [] available as well.

      • by Anonymous Coward

        Yeah, when can we get OpenBSD PF on Linux? Seriously.

        I've been using PF on FreeBSD and IPF before that. I really think both are a lot simpler to understand than IPTables, which, quite frankly, is a disaster to administer.

    • by Penguinisto ( 415985 ) on Wednesday January 02, 2008 @07:44PM (#21888744) Journal
      I'd just like to chuck in a general agreement here. PF is hella flexible, and while "ipf -fa -F /etc/ipf.conf" is nowhere near as intuitive as "/etc/init.d/iptables reload", the ruleset syntax is IMHO superior by miles, and much easier for a newbie to grok. I lost count of how many times I was tempted to try to hunt down a pre-compiled binary for the thing in Linux.

      (somebody had to have ported the thing by now... if not, damn that'd be an idea...)


      • I think it's another case of using what you know. I'm a Linux/iptables guy, my boss is an OpenBSD/pf guy. I hate his BSD boxes, and I'm sure he fears my Linux just the same :) But we both get our things done, and at the end of the day that's all that matters.

        I personally think they're both clumsy tools, but that's probably because I've yet to find a simple GUI to work them. Yes, a GUI. I can work simple rules from the command line, but it would be nice to be able to visualize long chains full of jumps.
        • by Anonymous Coward
          Hate to break it to you, but if you want a gui, you should be involved in the firewall, period.
          • Hate to break it to you, but I'd like to take advantage of the usability improvements brought forth by modern computing. Just because I'm a CLI guru doesn't mean I should be excluded from clicky interfaces that don't require reading through 60 pages of shoddy online docs in order to throttle a port or route around a dead switch.
          • Hate to break it to you, but if you want a gui, you should[n't] be involved in the firewall, period.

            I take it you've never heard of Checkpoint?

            GUI vs. CLI aside, I have no kick against a GUI... I have no personal use for it, but some folks do. A layout showing what rules take priority and showing parent-child relationships sounds kinda cool. Not quite sure how you'd visualize things like NAT, but it would be interesting to find out.

            (BTW, I should've qualified my original post with ipf/FreeBSD, not pf/OpenBSD... IIRC they are close enough to be nearly identical in ruleset syntax, yes? )


        • by sgtrock ( 191182 )
          Heck, I'd be satisfied with a nice, simple curses interface! Why does everyone assume that if it's not CLI, it has to be a full blown GUI app?
    • Yes, The Book of PF [] finally started shipping in December.

      It would have been very nice to see a slashdot review, but for obvious reasons I can not contribute one myself :)

  • by Oriumpor ( 446718 ) on Wednesday January 02, 2008 @05:31PM (#21887220) Homepage Journal
    Why has this package (which was last updated over 4 years ago) according to the sf project page [] become a staple of perimiter defense in many reference books, but hasn't been updated in almost 5 years?

    I've used it where I thought it a good idea in the past, but if knowledge of it's existence is apparent to attackers, it becomes a tool for DoS (through spoofing.) Wouldn't a snort+netfilter IPS solution make more sense?
    • Re: (Score:2, Informative)

      by eipgam ( 945201 )
      There's no reason that age or frequency of update alone, without any other considerations, should prevent use of a piece of software.
      • Re: (Score:3, Insightful)

        by coryking ( 104614 ) *
        Actually, it is the first consideration I have. I don't use software whose development seems to be dead. The first thing I look at on a website is "Last Updated $NOW - (ONE YEAR)". If it hasn't been touched in a year, I keep right on movin'...

    • by SpaFF ( 18764 ) on Wednesday January 02, 2008 @05:44PM (#21887352) Homepage
      Uhm, if you read the article it appears that the author is advocating using psad (which is actively maintained) instead of portsentry.

    • Re: (Score:3, Insightful)

      Portsentry was made by Psionic. They were bought out [] by Cisco in 2002. So Cisco pretty much hired the main developer and that eventually killed the project. The code was open source but obviously a community never really formed around it other then people wondering what happened to it. I welcome the alternative, PSAD, and am planning on to give it a test drive...

    • Portsentry is dead, and while it was interesting several years ago, it has serious architectural problems that in my mind make it unsuitable for use as a security application when compared to something like psad. Here are the reasons why: []
  • Strange... (Score:3, Funny)

    by $RANDOMLUSER ( 804576 ) on Wednesday January 02, 2008 @05:36PM (#21887262)
    Most of my fireballs have involved Windows.
  • by Selanit ( 192811 ) on Wednesday January 02, 2008 @06:23PM (#21887784)

    The reviewer wrote:

    I don't want to give away too much of the material in Linux Firewalls; so I will just say ...

    I totally stopped reading right there. Jeez man, don't spoil the technical manual! The suspense is all I read for!


  • With any trojan or P2P app worth its salt able to use any port nowadays, and usually encryption, 80 and 443 tend to be the common targets. WTF is the point of filtering based on ports now? Nefarious apps got around this long ago, and it just annoys users of legitimate applications that use different ports.
    • Err... lots of services don't listen on ports 80 or 443, and some vendors (*cough*Microsoft*cough*) have had a historical nasty habit of letting their services listen on some obscure port by default without telling anyone (including the admin) about it until something nasty showed up (e.g. Slammer).

      Placing a fireewall in the right spot allows you to have some network services remain locally open without having to filter at the service itself based on addys or a netmask (esp. since some can't).

      Also, I'm

    • By running fwsnort [] (covered extensively in the Linux Firewalls book), iptables is endowed with true application layer matching capability for Snort rules, and this takes Linux firewalling far beyond port-based filtering. Many fwsnort iptables rules apply to port 80 for example, but only trigger when malicious data is sent at the application layer.
    • Considering that this book is targeted towards linux servers, port-based (and address-based) firewall rules are still really powerful.

      You basically want to only open up the ports that you're actively listening on (port 80 on a webserver) for input and block everything else. Also, you want to block outgoing ports for anything that you're not using for output.

      In my setup, I block everything going out except for LDAP and mysql, but I restrict those outgoing requests to the addresses of the ldap and mysql serve
  • I would say the book isn't extremely detailed about iptables. It does quite a good explaining different kind of attacks, but then doesn't really tell you how to prevent them. The second half (!) of the book discusses that log analyzer, which I personally find not very interesting.

The IQ of the group is the lowest IQ of a member of the group divided by the number of people in the group.