Correct me if I'm wrong, but as I understand it, if a server program has a bug, a carefully constructed packet could take advantage of that bug to grant an intruder access to your computer (in the form of a virus, worm, etc). A firewall prevents this by closing the ports of the servers you don't need.

If you're sure that you don't have any servers running or if you're sure that any servers that you do have running are bug-free, then what is the harm of not having a firewall?

I'm not advocating against firewalls - I know most people will respond with "better safe than sorry" and that's the approach that I take too. I'm interested in it from a technical standpoint, why are they necessary?

Basically you are correct. If you aren't running something on that port, then there is nothing for a remote system to connect to. Conversely, if there is a remote exploit in a particular daemon, a firewall is not going to do anything to stop an attacker from connecting and exploiting that.

But that is only for inbound firewalls. A strong case could be made that an outbound firewall is perhaps even more important to run than inbound. For example, if there was an exploit that allowed an attacker to run code on your server, the first thing he might do would be to spawn a shell on netcat and point it back to himself. This would have your server connect out to his location and give him shell access, even if you were only allowing port 80 inbound. If you had been using an outbound firewall, you could have blocked this connection. Not that it would be impossible to disable the firewall if the attacker was already able to run code on your machine, but it will make things more difficult. Perhaps a better example would be if somehow a trojan or rogue program was running on your server.

Some people also swear by adaptive firewalls. If you are logging hundreds of connections a minute from an IP trying to DoS or brute force one of your daemons, then have the firewall automatically block that address for a period of time (or forever, if you were so inclined). Of course you do run a risk of blocking legitimate traffic, especially if a zombie machine was being used to route attacks through.

Getting into the more advanced configurations, iptables can also block many different scan types and known attack patterns before they even hit your daemons. This can go a long way to preventing an attack in the first place. Even if you aren't running an exploitable (yet) daemon, why let remote users scan your system? The real goal here is to block everything but legitimate traffic, even if there is no immediate danger from port scans and the like.

A properly-configured firewall will also help keep a successful attack from spreading further.

Only from this point of view, you are right. If all other ports are running nothing, or if what they are running is supposed to have unrestricted access, then it is not necessary.

In general, hardily you will have a single server in a network, or this server has unrestricted access for all services running on it.
The point here is having a firewall is convenient !

It is more convenient to have a centralized point to control access to your network than in each device in your network (and many devices don't have any network filtering features, like printers, switches, etc).
It is not only more convenient. It is more error-prone too.

And there are situations you need a firewall to have fine-control in one or more services.
For instance, you can use a firewall to allow/deny access based on the source (or even based on the time), not based on the service/port itself. For example, you can use a firewall to allow access to the ssh server (or all services to make it simple) only if the source is coming from your personal computer (in home, or at work) and deny from elsewhere; you can use a firewall to ensure the internal web server could be accessed only from internal network, not form outside; you can use a firewall to control the incoming rate of access to avoid a Denial of Service Attack; to block a single IP or an entire network used by bots.

And a regular firewall like netfilter can't help you if there is a bug in a service like ssh or http that could be exploited by sending to the server a well constructed packet, unless your firewall inspect the data part of the packet, not just the header.

cheers,

To answer this question, it might help to look at it in a broader context: Is any security measure necessary? Or are they all optional depending on the amount of risk we are willing to live with? If you're a security guard at a bank, do you need to wear a bulletproof vest in order to perform your duties?

Oh, if you insist...

...a carefully constructed packet, or, in some circumstances, a carelessly constructed packet...

It may well not grant the bad guy access, but it might crash you computer. Neither are desirable.

It wouldn't be a virus. To get a virus by the commonest means (this may no longer be the commonest means...I'm a bit out of touch with recent developments) you will have been hoodwinked into putting on your computer a code fragment that can do something malicious and further persuaded to execute it. The firewall won't do you any good in that it manages the flow of packets and connections and that has been good (you asked for something to be supplied and it has been supplied) and is only involved in the second phase if that involves some kind of assault on a port, which it probably doesn't.

It might be involved in the propagation of a worm, though.

...closing or controlling access to... So, you might have a rule that effectively says 'if this source address has tried this unsuccessfully more than 5 times in the last minute (or hour), just drop the connection', which would make brute force attacks harder. Or you might have a rule that says 'allow access to this port, but only from the internal network'.

.

Well, in principle. Nearly. But you aren't sure that you have no servers running

What about X? CUPS? dbus? acpi? dcop? nepomuk? gdm? hald? avahi? dns? and quite a few more.

Most people will have a selection of these -I'm guessing at least half a dozen- and the only way of eliminating them totally involves pulling the network cable and not running a GUI (plus other measures) and, if you go down that route, I think you'll find that pulling out the network cable was the step that gave you the most protection.

And you are not sure that any server is bug free. You may be sure, or thereabouts, that for some particular server there is no widely publicised exploit or that no one has suggested a mechanism by which an exploit was going to happen, but that is rather different.

And some things can be guaranteed to have bugs. (I'm using guaranteed here in the sense that if my local betting shop would take a bet from me, with my own money, on at least one bug being found in the service or application, I would place that bet. This isn't quite a guarantee, but its close.)

BIND. I'd bet on that having at least one bug, based on history. Anything ipv6. Any system that mixes ipv4 and ipv6 is probably worse still, as that probably hasn't been as well tested. kde4 (I think they were still clearing up bugs and adding features at 10,000 per month, so I think I'm safe there). Any gui (just too complex to be totally bug free). The Linux kernel (better than a couple of years ago and way better than some other systems....). And these are just the ones that come to mind as being pretty safe places for my money, as I'm not intending throwing it away.

And note that with some of this stuff, it might not be necessary for you to be running it for it to be used in an exploit against you. BIND could be used as part of a 'man-in-the-middle' exploit against you, even if you don't run BIND (although, that is not a perfect example, because the firewall may not help you against the man-in-the-middle part of the exploit).

And I have recently seen a security announcement about a SuSE bug in the tcp/ip stack. You won't be doing any networking without tcp/ip (it is probably theoretically possible to do some useful networking without tcp/ip, just for 99.999% of people, its not practical), whether you have what you call servers running, or not. I'm not sure yet whether this is an issue with an exploit or whether its just a theoretical shortcoming, but it goes to show that if any piece of software, even something very basic, is assumed to be without flaw, you are taking a risk.

That's probably a good decision!

The biggest problem is probably that people say 'I've got a firewall, therefore I'm safe' and that isn't the case, at all. There are still plenty of stupid things that you can do that a firewall won't protect you against, and there are plenty of people trying to trick you into doing stupid things.

Having layers of protection is a good thing; with layers of protection there can be a flaw in a single layer without it being exploitable.

To me this scenario implies that you're running a workstation or standalone server. It also implies that you're really sure that you don't have any services listening for connections.

I'd just add to the discussion that in an environment with multiple hosts to protect, a firewall at the perimeter is useful for 1) enforcing policy at a single point; 2) preventing unwanted/unexpected traffic from reaching the host systems altogether.

And remember that security works best in layers, where if one method fails, the other methods are still available.