I did it by hand and good ol fashioned trial and error

Please keep in mind that there are people coming from Windows firewalls. I am the one. I need a graphical pop-up window i.e. interactive firewall that asks me what to do each time a new type of connection happens, of course with "remember this" option. Any idea?
While a lot of firewalls exist in Windows, it's easy to find a good one, even for free. But here, I am confused, each distribution is using its own and then you come with hand option...

Arno-iptables-firewall deserves a mention home page http://rocky.eld.leidenuniv.nl/

There's a Slackware 11.0 package at
http://www.linuxpackages.net/search_...e=arn&ver=11.0

Wrote my own with the thanks of netfilter.org, read quite a few scripts, took out what I like to make my own script. I have also added a lot of my own code to it to make a lot of things more automatic rather than having to heavily modify each time it goes onto a new host, only have to adjust the rules depending on the services the host is going to run. Unfortunately I don't run any servers at the moment so I cannot link to it.

I wrote mine by hand after looking at online examples. Basically, it's:

accept all traffic on loopback
accept all outbound traffic
drop all inbound traffic except ssh, ntp, and established/related packets

Seems to work fine so far

Unless you're running an ntp server for the public, there's no need to explicitly open that port either - the est/rel rule will catch replies to your outgoing requests.

If you'd like to use the recent match to cut down on some of the ssh brute force attacks, this might be helpful - I tried to comment it well enough for someone to actually understand what they're doing rather than just blindly copying... http://rlworkman.net/conf/firewall/sshattacks

Also, if you'd like to have identd requests acknowledged when they're expected but dropped otherwise, see this link: http://rlworkman.net/howtos/irc-identd

I just wanna say that I find this post hilarious

Application-level "firewalls" (whether that's an appropriate term or not is debatable, but I'll not go into it here) are an entirely different breed of cat, so to speak. There's limited ability to filter by process owner with iptables, but it's not perfect. It has some valid uses, but access control IMHO is not generally one of them [1]. If you don't want an application sending packets out on the internet, don't install it. If you have users that you can't trust, remove their accounts. With all that said, there have been some attempts to create an application-level "firewall" for linux, but I can't recall any of the names at the moment - a search on freshmeat should be enlightening...

[1] There is at least one legitimate use of the owner match that comes to mind - only allow outgoing smtp traffic if the process sending it is owned by the mail user; this way, if apache (or some other service is rooted, it won't be allowed to send spam from your system). However, this is a stop-gap measure, and a far better solution is to either run other services chrooted and/or make sure you stay up to date with security patches for them.

There's really only one working packet filter on modern linux systems - netfilter (and the iptables userspace interface for it). All of the distribution-specific things are just wrappers and/or front-ends for iptables, and as you've seen, some are better than others. My advice is to learn the iptables syntax and configure it manually - the knowledge you gain is portable across distributions, and the knowledge you're forced to gain about TCP/IP in general is portable across operating systems.

This is a fantastic module I like using it as well, great for the webserver, helps to slow alot of those scripts down that like to hammer your site.

configured by hand

I've been using shorwall (www.shorewall.net) for a number of years. Shorewall is a text mode tool, not a gui. I think it offers a great flexibility for lots of different applications, while being substantially simpler than directly writing IPtables rules. Configuration is straight-forward, although requiring some knowledge of precisely what you want to do. (In this regard, I consider it "slackwarish".) I also think the documentation on shorewall is fantastic, giving a very clear description of what firewalling is about for systems ranging from one desktop to an enterprise.

I use firestarter for desktop and laptop. For the webserver, I use rules that I constructed and run them during bootup.

I want to move to a firewall startup script of my own one of these days...once I get some time from my month-old daughter.

Thanks! gilead for posting that awesome tutorial. I actually use Linux Firewalls by Steve Suehring and Robert Ziegler; ISBN 0672327716. Has pretty good info on setting up basic to advanced iptables firewall.

simple home made script with all the rules inside. (as rc. file)

I don't think he's talking about untrusted users. This kind of firewall is a really good idea and I predict we will see more support for this in the future as more and more apps are ported/built for *NIX.

Basically the winbloze firewalls protect you from an inside-job. If you don't like apps "phoning home" it's a good idea to do some checking with ethereal/wireshark/iptraf/etc. If not you have no idea what's being exposed by programs you run. For example how do you know that some app that does your finances (gnucash) is not connecting to the internet (it does).

In winbloze this kind of exposure in built-in to the "OS" which is why it's so important. We know that our kernel devs would never do anything like that and we trust them. But we also have thousands of 3rd party apps we build and use every day and how do we know what they're doing? It would be a lot easier (and safer) if there was an easy way to control all outbound traffic as well as we can control inbound traffic.

Right - he probably wasn't, but it seemed relevant at the time

It's certainly something that lots of users want, but I'm still undecided as to whether it's truly needed (aside from specialized environments perhaps).

Therein lies the problem. If I'm doing internet banking with GNUCash, I *want* it to connect to the internet, and if I'm not, I *don't* want it to connect to the internet. If the application is written properly, it won't connect to the internet unless I'm doing internet banking and/or unless it checks for updates automatically (whether it does or doesn't do that, I can't say - I don't use it). The point is this: if the app does things it shouldn't do, either don't use it, modify the source to fix it, or raise enough hell with the developers to have them fix it. Quite frankly, if an application is trying to send things to the internet when it shouldn't, it won't be installed on my system very long - there's simply no middle ground here IMHO. Having an application level firewall in place would constitute tacit acceptance of a 'phone-home' application, and that's not the impression I want to give to the developers of $APP.

And we're back to where we started...