61

I admin a handful of cloud-based (VPS) servers for the company I work for.

The servers are minimal ubuntu installs that run bits of LAMP stacks / inbound data collection (rsync). The data is large but not personal, financial or anything like that (ie not that interesting)

Clearly on here people are forever asking about configuring firewalls and such like.

I use a bunch of approaches to secure the servers, for example (but not restricted to)

  • ssh on non standard ports; no password typing, only known ssh keys from known ips for login etc
  • https, and restricted shells (rssh) generally only from known keys/ips
  • servers are minimal, up to date and patched regularly
  • use things like rkhunter, cfengine, lynis denyhosts etc for monitoring

I have extensive experience of unix sys admin. I'm confident I know what I'm doing in my setups. I configure /etc files. I have never felt a compelling need to install stuff like firewalls: iptables etc.

Put aside for a moment the issues of physical security of the VPS.

Q? I can't decide whether I am being naive or the incremental protection a fw might offer is worth the effort of learning / installing and the additional complexity (packages, config files, possible support etc) on the servers.

To date (touch wood) I've never had any problems with security but I am not complacent about it either.

Improve this question
3

8 Answers 8

Reset to default
91

I note that you've done a great job tying down several different daemons, and from what you've said I think it unlikely that you'll expose yourself to trouble through those services you have already secured. This still leaves you in a "everything is permitted except that which I have forbidden" state, and you can't get out of that state by hunting down daemon after daemon and securing them one by one.

A firewall configured to DENY ANY ANY by default moves you to a "everything is forbidden except that which is permitted" mode of operation, and I have found over many years that they're better.

Right now, given a legitimate user with a legitimate shell on your system, she could decide to run some local unprivileged daemon for proxying web requests for the internet, or start file sharing on port 4662, or accidentally open up a listener by using -g with ssh port tunneling, not understanding what it does; or a sendmail install could leave you running an MUA on port 587 which was improperly configured despite all the work you'd done on securing the MTA sendail on port 25; or a hundred and one things could happen that bypass your careful and thoughtful security simply because they weren't around when you were thinking carefully about what to forbid.

Do you see my point? At the moment, you've put a lot of effort into securing all the things you know about, and it sounds like they won't bite you. What may bite you is the things you don't know about, or that aren't even there, right now.

A firewall which defaults to DENY ANY ANY is the sysadmin way of saying that if something new comes along and opens up a network listener on this server, noone will be able to talk to it until I have given explicit permission.

Improve this answer
4
  • That's a very insightful answer, particularly the text about flipping from "everything is permitted..." to "everything is forbidden..." Your point is well made about local daemons as well. As is often the case - I am sure you will agree - the danger is often on the "inside"
    – Aitch
    Feb 8, 2011 at 13:12
  • 12
    (Aitch, if I may presume a little, your profile suggests that you're new on serverfault. The local etiquette is that when you're happy with an answer, you accept it, by clicking on the tick outline, if memory serves; that drives the reputation system. Of course, if you know this already, or you are waiting to see if other, better, answers turn up, then that is also very right and proper, and please ignore me. The community only asks that once you're fully satisfied with an answer to your question, you accept it.)
    – MadHatter
    Feb 8, 2011 at 13:30
  • +1 @MatHatter - good description of how firewalls can provide security by default, rather than choice.
    – Coops
    Feb 8, 2011 at 19:23
  • It's a calculated risk. At least on OpenBSD, enabling pf adds 35K lines of code in the kernel, which may have bugs. On the other hand, a default deny - and proper logging firewall - is the greatest IDS money can buy. Stop trying to use Snort to look for bad things: Any time any of your machines do something you didn't specifically allow, you should get notified.
    – Alex Holst
    Feb 8, 2011 at 21:06
15

Principle of Least Privilege. A firewall helps you get there. Principle of Defense in Depth. A firewall helps you get there, too. Any well-designed configuration explicitly relies on these two in one way or another.

Another thing is that your servers will most likely be commodity hardware, or hardware specific for handling server software running on top of a standard server OS (Unix, NT, Linux). That is, they do not have specialized hardware to handle and filter incoming traffic efficiently. Do you want your server to handle every single possible multicast, ICMP packet or port scan coming its way?

Most likely what you want is for your servers to physically handle requests to only some ports (80, 443, your ssl port, your typical oracle 1521 port, your rsync port, etc.) Yes, of course you set up software firewalls on your servers to listen to those ports only. But your NICs will still bear the brunt of unwanted traffic (be it malignant or normal in your organization.) If your NICs are getting hammered, so are the network paths going through your servers (and possibly between your servers and internals clients and connections to other internal servers and services.)

Not only do your NICs get hammered, your software firewall is also going to be engaged as it has to inspect every single packet or datagram it gets.

Firewalls on the other hand, specially those on the edges of subnets (or separating your subnets from the outside world) tend to be specialized hardware specifically built for handling that type of volume.

You can surround N number of servers with M number of firewalls (with N >> M). And you set your firewall hardware to dump anything that is not directed towards specific ports. Port scans, ICMPs and other crap are out. Then you fine-tune the software firewall in your servers according to their specific function.

Now you have just reduced (but not eliminated) the probability of a total blackout, reducing it to a partitioning of the network or partial failure at worst. And thus, you have increased your systems' ability to survive an attack or misconfiguration.

Not having a firewall because your servers have one is like feeling safe in having your seat belt on while driving at 120mph under zero visibility due to fog. It doesn't work that way.

Improve this answer
4

There are many attacks you could be succeptible to if you do not have a firewall that does some kind of packet level inspection:

Example is the Christmas Tree Packet

http://en.wikipedia.org/wiki/Christmas_tree_packet

DDOS attacks could be run against your system, a firewall (external maybe, before any of your servers) would stop / slow / kill traffic before it crippled your servers.

Just because you do not have financial, or personal data on the servers doesn't mean you won't get 'hurt'. I'm sure you pay for bandwidth, or CPU usage, or you have a metered rate. Imagine over the course of a night (while you are sleeping) someone runs up your meter (I have seen this happen with VOIP Switch providers, hit in the night for MILLIONS OF MINUTES of traffic, that they have to foot the bill for).

So be smart, use the protection if it is there, you are NOT PERFECT, neither is software. It is only secure until the next exploit is found. ;)

Improve this answer
2

You or someone else may make an error on your server setup one day, a firewall then gives you a 2nd chance of stopping someone getting in. We are not perfect, we make errors, and therefore a bit of "unneeded" insurance can be worthwhile.

(Try not to run your firewall on the same OS as your servers, as otherwise a single bug in the OS.... I consider all versions of Unix to be the same OS, as they have so much in common)

Improve this answer
1
  • Excellent, mixing up platforms (OS and hardware) is key.
    – DutchUncle
    Feb 9, 2011 at 0:02
1

If you can enforce a principle of least privilege w/o using a firewall you probably do not need it. From my point of view building a secure system without using a firewall requires more effort, and I am quite lazy. Why should I bother restricting TCP connections using other tools and probably many config files when I can separate privileges on a transport level using a single config.

Improve this answer
3
  • 1
    Good point about the single config, less room for error. I agree with being lazy wherever possible! cfengine does take out some of this complexity for me partly mitigating the issue of many config files ....but... it is only as good as the rules that are written of course. So you leave most config files at "default" (or near as) as a secondary barrier and have the firewall as (at least in a layer sense) the primary concern.
    – Aitch
    Feb 8, 2011 at 13:17
  • 2
    I first upvoted for PoLP, then downvoted for laziness. Firewalls are not tools to allow their owners to be sloppy. You should bother tightening your attack surface because if the attacker goes through the firewall (afterall you gotta have something open), they can just turn off iptables. Apply your laziness where it belongs: make the system as slop-free as possible, so you don't have to fix it for a long time.
    – Marcin
    Feb 8, 2011 at 18:25
  • @Marcin I mean that if someone wants to secure a system w/o using a firewall, he or she will have to create a comprehensive threat model first. Firewalls imply some kind of well-known and well-described threat model, so I don't have to build it from scratch for every host. Of course, if we talk about a military-grade security, there is no choice, a formal threat model should be built.
    – Alex
    Feb 8, 2011 at 18:42
1

A firewall also can intercept unwanted packets from reaching your servers. Instead of dealing with them at the individual server level you can deal with them at the firewall. You can keep all of this configuration activity on the single firewall instead of multiple servers.

For example, if an attacker has gained control of an external IP and is deluging your servers with unwanted packets and you wish to mitigate the effects it has on your servers ... you could either configure each of your affected servers to drop the malicious packets or simply make the change at your firewall and all of your servers are protected. Having the firewall has decreased your reaction time.

Improve this answer
1
  • Additionally, doing this is configuring a firewall anyway - it just happens to be on each server.
    – mfinni
    Feb 8, 2011 at 19:35
1

Firewalls are spicialized in traffic manipulation. They do it quick and have resources. And you dont waste server resources to filter traffic (disk io / proc time / etc). You shuld configure some security in server environment but all trafic inspection and virus scanning and so on should do specialized servers.

Improve this answer
-2

I would be concerned that if you ever do get hacked and don't have a firewall in place. The hackers could open other ports on your servers. Also, if a consultant is brought in to do some cleanup and auditing, the first thing they will say is, "WHAT?!?! You don't have a firewall!" Then you could be burned.

Improve this answer
2
  • -1 A bit sensationalist answer + not really being constructive.
    – Coops
    Feb 8, 2011 at 19:27
  • 2
    If the server is compromised, then a firewall isn't necessarily going to help when the bozo that has broken in simply disables it! *disclaimer, the question did mention using iptables, not a separate hardware firewall.
    – Bryan
    Feb 8, 2011 at 23:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .