I've removed advertising from most of this site and will eventually clean up the few pages where it remains.
While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.
If you found something useful today, please consider a small donation.
You might find this surprising, but there is at least one person in the world who thinks firewalls are pointless. You can find a thread where this is discussed at Groups.google.com, but I don't recommend reading it: it is very long, and very repetitive.
If your immediate reaction is "That person must be an idiot", you are wrong. He's far from it, and his argument has some value. Let's look at that part first, and to keep things simple, we'll pretend you have one and only one service open to the web, and that service is ssh. All other ports are closed. If this represents our configuration, a firewall adds no value to it. How can it? All ports but ssh are closed; the firewall can't make them "more closed". The ssh port is open, so the firewall again can do nothing but pass it on through. In this narrow circumstance, the firewall is a useless appendage.
Well, that's not entirely true. It's true if our firewall only has the capability of passing or rejecting packets based on header data (source and destination parts, ip addresses, etc.). As that is the limit (or close to it) of many firewalls, hardware or software, the argument holds true.
If, however, we have a device capable of doing packet inspection, the firewall may have value because it can close the door against packets carrying certain data. This becomes possible because certain attacks have known payloads and their signature can be recognized. These are unusual situations, but not so unusual that this type of filtering isn't done; see Intrusion Prevention and Active Response for a good overview of this subject.
But even without that, this is a pretty simplistic scenario and probably doesn't reflect the real world. I have servers with ssh running on them, but I certainly don't want just anyone logging in. There are a number of configuration changes you can make to ssh to restrict logins (and many articles here on that subject). Let's specifically take the case of a branch office in some other state. If we need to allow ssh from there, an obvious security addition might be to use public key authentication. That could lock down ssh to only allow access if the public key generated by our remote office is used.
Before we go into this more, let's remind ourselves of what this doesn't protect us from. It doesn't protect us from someone breaking into the branch office physically or electronically and accessing our server. We can assume that we have some degree of physical security, and can assume that we don't have any deliberate electronic access to the remote office (they can log in to us over the internet, but no one is supposed to log in to them, or only we are allowed - using our public keys). But we never have 100% security no matter what we do. Keep that in mind always. All we are ever attempting is to increase our security - there will always be circumstances we cannot control.
But that's what we have done here. Our security is increased, because now at least joe from randomplace.com can't guess passwords and log in. He can't even login if he knows a password that would otherwise work; he needs the keys from our branch office. We have increased our security. Would a firewall (the non-packet-inspecting kind) add anything? No, of course not. The firewall is pointless. Or is it? The branch office is at a known ip - let's have the firewall only allow packets from that ip pass to our ssh daemon.
This is where the argument starts at the long thread referenced above. Our anti-firewall person still insists that the firewall adds no value. I'm going to list some circumstances where it will, but it's again important to remember that there still obviously are conditions where it will not. If someone breaks into our branch office, and logs in to the machine account with the public keys, he obviously has immediate access to our server. That truth has no bearing on the other conditions I'm about to state: we are talking about adding value, not about perfect protection. Remember also that although we've used ssh in this example, the conditions could apply to any daemon.
There are at least three circumstances where our added ip filtering can help us. These are:
Some daemons have incredibly complex configuration, and it can be very easy to make a mistake. It's also sometimes easy to misunderstand the needed configuration; Apache's position dependent "Order Allow,Deny" is a good example of that.
It's also easy to make editing mistakes. Just yesterday I accidentally deleted an important line from a shell script. I noticed it and fixed it immediately, but I might not have. We're all human, mistakes happen.
If we do accidentally enable ordinary passwords in our ssh setup, we've lost our public key protection. Now anyone with a password can log in, and password guessing is a game played for hours on end at every ssh server. However, if we have filtered to only allow our branch office ip to see ssh, the firewall has protected us.
Although we hope no such things exist in ssh, it's always possible that some method might exist that will bypass our configuration directive and revert to base logins. Again, remember that although we are using ssh and public key authentication as an example here, we could just as well be talking about any protocol and any authentication scheme. If a bug or exploit causes this error, our firewall will once again protect us.
It's possible for someone to obtain the key pair that we generated on our branch office machine. It might come from a stolen backup, a usb memory stick, or a careless email. If we don't have a firewall restricting this to the ip we expect to be using those keys, they can be used from anywhere in the world. Once again, the firewall protects us.
We should also note that the theft of keys from a backup, etc. isn't necessarily unlikely. It is if we are considering random attacks, but if we have something valuable to protect, and someone who wants to get to it, stealing backups isn't as far fetched as it otherwise would be.
Our anti-firewall person doesn't stop here. "OK", he says, "It's possible that a one-legged nun might attack you with a machine gun - do you worry about that?" (I'm not making precise quotes, by the way, this is just to give the flavor of what was discussed). "It's pointless to protect against things that have a negligible likelihood of ever happening!".
Well, that's not quite true, is it? In fact, we often protect ourselves from things we think have very little chance of happening. I insure my house against fire and other sorts of damage that are extremely unlikely to affect me. Why do I waste my money? Because although the odds are long, if I did have a fire, the cost to me would be extreme. I'm willing to pay the insurance cost because a fire would be disastrous - it would cost me too much. That's just the case with our server: while the theft of a backup or the existence of a bug or an accidental misconfiguration may be unlikely, the cost to me is very high if any of these things do happen. The cost of deploying the firewall is very low, so it makes sense to do it. And, as we noted, some daemons are more difficult to configure, which increases the chance of error, and if someone is actively targetting us, the use of exploits or stolen information is much more likely. The firewall adds protection.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Tony Lawrence © 2011-03-18 Tony Lawrence