APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed
RSS Feeds RSS Feeds











(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
->
-> The value of firewalls


The value of firewalls






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

Misconfiguration

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.

Software bug or exploit

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.

Theft of keys

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.

Probabilities

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 this page was useful to you, please help others find it:  





3 comments




More Articles by - Find me on Google+



Click here to add your comments
- no registration needed!




Tue May 10 18:43:47 2005: 485   ptb


The chance of your house burning down is say 1:50000 per year. The chance of being gunned down by a one-legged nun with a machine gun this year is maybe a ten billion to one or more chance. That is 200 000 times less likely. It makes sense to insure yourself against your house burning down, but it does not make sense to insure against being shot by one-legged nuns with machine guns.

You can safely let the latter insurance policy lapse.



Tue May 10 19:38:13 2005: 486   TonyLawrence

gravatar
That's the gentleman who doesn't believe in firewalls.. :-)



Tue May 10 22:55:12 2005: 487   TonyLawrence

gravatar
If the chance of losing my house is 1:50000 per year, it isn't likely to burn down in my lifetime, so it would seem that I am a fool to buy insurance unless it is very inexpensive.

But if the replacement cost is, oh, let's say $150,000 or so (after all, the lot doesn't burn and that's where a lot of its value is), and I don't have insurance, I'm in trouble. Suddenly I jump from owing a measly $40,000 as I do now to almost $200,000. That's a hefty chunk of money even at current low interest rates. I'd rather pay the few hundred dollars or so a year that insurance costs..

And I'd rather deploy this firewall as described above than get hacked because of one of the posited conditions. The cost is low, the potential for loss is very high.. it's a good bet.




Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments


If you want a picture to show with your comment, go get a Gravatar

Kerio Connect Mailserver

Kerio Samepage

Kerio Control Firewall

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here

Jump to Comments



Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

I am a Kerio reseller. Articles here related to Kerio products reflect my honest opinion, but I do have an obvious interest in selling those products also.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.

pavatar.jpg

This post tagged:

       - Security















My Troubleshooting E-Book will show you how to solve tough problems on Linux and Unix systems!


book graphic unix and linux troubleshooting guide



Buy Kerio from a dealer
who knows tech:
I sell and support

Kerio Connect Mail server, Control, Workspace and Operator licenses and subscription renewals



Click and enter your name and phone number to call me about Kerio® products right now (Flash required)