Linux Firewalls

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 http://netfilter.org. The psad, fwsnort, and fwknop applications are licensed under the GNU General Public License Version 2, and can be downloaded from http://cipherdyne.org.

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 [e-mail].

You can purchase Linux Firewalls from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Good book

[PhotoJim]

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:

[Finallyjoined!!!]

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 {:^)

Sounds like an awesome book

[tjstork]

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?

Re:Sounds like an awesome book

[Anonymous Coward]

I agree. He should leave this forum in which firewall books are being discussed, and then search the internet for people's opinions about their favorite firewall books. Maybe he could find a forum somewhere in which firewall books are being discussed instead of wasting time in this forum where firewall books are being discussed.

Re:

[Curmudgeonlyoldbloke]

You could do worse than start here:

http://www.cse.msu.edu/~minutsil/iptables.html [msu.edu]

Re:

[stoolpigeon]

I'm a bit late with this - but just in case you check back - you might want to look at the Linux Networking Cookbook just out by O'Reilly. It has a much wider scope than just firewalls but does cover iptables and such. It's very hands on.

iptables

[caluml]

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:

[Anonymous Coward]

sheepish hand raise at the 'aw fuck' moment of a lifetime.

Re:iptables

[Anomolous Cowturd]

$ at now + 5 minutes
warning: commands will be executed using /bin/sh
> # put some undo commands here
> # get them right!
> ^D

$ # risky stuff here

then you can use atq and atrm to cancel the undo, assuming you didn't screw up.

Re:

[asamad]

screen is also your friend

screen 0
sleep 180 ; {undo stuff here}

screen 1
scary stuff here

Re:

[9InchRails]

Nice! Thanks!

Re:

[drpimp]

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.

Re:

[Kompressor]

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.

Kompressor

Re:

[Albert Sandberg]

In practice, that's the same thing, so you didn't top him :-)

I would suggest the time then I visited slashdot for the first time, that was a huge mistake ;-)

Re:

[PitaBred]

Depends on what $PWD is. .* will nuke your current location, rather than the system, which could be the difference between being employed and not ;)

Re:

[Kompressor]

Depends on what $PWD is. .* will nuke your current location, rather than the system, which could be the difference between being employed and not ;)

In my case, it recursed, and included .. as matching .*, which went up a directory, matched .., and eventually .. equated to /.

No, that's not quite right...

eventually .. equated to /

That's better.

[offtopic] Do you dance?

[empaler]

And why did you hit me in the knee with candle sticks?

Re:

[caluml]

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... :)

Re:

[0100010001010011]

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.

Re:

[alexgieg]

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...

Re:

[somersault]

Ack, you mean you turned Linux into Windows? Aieeeee!

Re:

[Kompressor]

To mitigate that same problem, I wrapped my iptables shell script with a "sleep 30" and "iptables -F" commands. Live and learn, right? :-D

Re:

[weicco]

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 ;)

OT: Your .sig

[dotgain]

You might have meta-moderated someone else's moderation that was identical to yours perhaps?

Re:iptables

[Tmack]

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 [ex-parrot.com]...

Tm

Re:

[dpilot]

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.

Re:

[Lennie]

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.

Re:

[dpilot]

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

Re:

[Lennie]

Ofcourse it depends on the situation. :-)

Sometimes there is no easy solution to prevent your self from shooting yourself in the foot.

Re:

[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.

Re:

[OnlineAlias]

I call it the Geek equivalent to the walk of shame....gonna have to get up and go reboot it.

Re:

[RockedMan40]

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

[Anonymous Coward]

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.

Re:

[aionica]

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

Re:

[Anomolous Cowturd]

How does it compare to filtergen + fgadm?

Re:OpenBSD PF Firewalls

[Homology]

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 [openbsd.org] for years and is much better than iptables. There is also a nice, up-to-date User's Guide [openbsd.org] available as well.

Re:OpenBSD PF Firewalls for Linux

[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.

Re:

[dartmongrel]

I personally use opensbd(I like its simplicity in many aspects) for ftp and httpd, but tend to stick to linux for desktop.
Even tho you got modded troll I want to ask you your reasons for thinking OpenBSD is better.

Re:OpenBSD PF Firewalls

[Penguinisto]

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...)

/P

Re:

[billcopc]

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.

Re:

[Anonymous Coward]

Hate to break it to you, but if you want a gui, you should be involved in the firewall, period.

Re:

[billcopc]

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.

Re:

[Penguinisto]

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? )

/P

Re:

[Penguinisto]

If your hand needs held, it shouldn't be holding the knife in surgery.

So by that logic: MRI's, CT scans, and Laproscopy cameras make a surgeon worthless?

Err, yeah.

/P

Re:

[sgtrock]

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?

Re:

[sgtrock]

Well, here's a couple of examples:

Lifelines [sourceforge.net]

BitTorrent-curses [cyberciti.biz]

:)

Re:

[badger.foo]

Yes, The Book of PF [nostarch.com] 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 :)

Re:

[Penguinisto]

*whoosh*...

/P

Portsentry a good idea?

[Oriumpor]

Why has this package (which was last updated over 4 years ago) according to the sf project page [sourceforge.net] 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:

[eipgam]

There's no reason that age or frequency of update alone, without any other considerations, should prevent use of a piece of software.

Re:

[coryking]

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'...

Re:Portsentry a good idea?

[SpaFF]

Uhm, if you read the article it appears that the author is advocating using psad (which is actively maintained) instead of portsentry.

Re:

[ajayrockrock]

Portsentry was made by Psionic. They were bought out [cisco.com] 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...

--Ajay

Re:

[michaelrash]

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: http://www.cipherdyne.org/psad/docs/faq.html#diff_portsentry [cipherdyne.org]

Strange...

[$RANDOMLUSER]

Most of my fireballs have involved Windows.

Re:

[Teisei]

Win-dows ? http://obligement.free.fr/images/windows_firewall.jpg [obligement.free.fr]

Re:

[u-235-sentinel]

Most of my fireballs have involved Windows.

Fireballs?

You were thinking chairs when you said that right? ;-)

OMG, Spoiler Alert!!1!!

[Selanit]

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!

^_^;

Does anybody still filter based on ports?

[jez9999]

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.

Re:

[Penguinisto]

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

Re:

[michaelrash]

By running fwsnort [cipherdyne.org] (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.

Re:

[MyDixieWrecked]

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

not impressed

[oglueck]

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.