Why should I firewall servers?
Solution 1:
Advantages of firewall:
- You can filter outbound traffic.
- Layer 7 firewalls (IPS) can protect against known application vulnerabilities.
- You can block a certain IP address range and/or port centrally rather than trying to ensure that there is no service listening on that port on each individual machine or denying access using TCP Wrappers.
- Firewalls can help if you have to deal with less security aware users/administrators as they would provide second line of defence. Without them one has to be absolutely sure that hosts are secure, which requires good security understanding from all administrators.
- Firewall logs would provide central logs and help in detecting vertical scans. Firewall logs can help in determining whether some user/client is trying to connect to same port of all your servers periodically. To do this without a firewall one would have to combine logs from various servers/hosts to get a centralized view.
- Firewalls also come with anti-spam / anti-virus modules which also add to protection.
- OS independent security. Based on host OS, different techniques / methods are required to make the host secure. For example, TCP Wrappers may not be available on Windows machines.
Above all this if you do not have firewall and system is compromised then how would you detect it? Trying to run some command 'ps', 'netstat', etc. on local system can't be trusted as those binaries can be replaced. 'nmap' from a remote system is not guaranteed protection as an attacker can ensure that root-kit accepts connections only from selected source IP address(es) at selected times.
Hardware firewalls help in such scenarios as it is extremely difficult to change firewall OS/files as compared to host OS/files.
Disadvantages of firewall:
- People feel that firewall will take care of security and do not update systems regularly and stop unwanted services.
- They cost. Sometimes yearly license fee needs to be paid. Especially if the firewall has anti-virus and anti-spam modules.
- Additional single point of failure. If all traffic passes through a firewall and the firewall fails then network would stop. We can have redundant firewalls, but then previous point on cost gets further amplified.
- Stateful tracking provides no value on public-facing systems that accept all incoming connections.
- Stateful firewalls are a massive bottleneck during a DDoS attack and are often the first thing to fail, because they attempt to hold state and inspect all incoming connections.
- Firewalls cannot see inside encrypted traffic. Since all traffic should be encrypted end-to-end, most firewalls add little value in front of public servers. Some next-generation firewalls can be given private keys to terminate TLS and see inside the traffic, however this increases the firewall's susceptibility to DDoS even more, and breaks the end-to-end security model of TLS.
- Operating systems and applications are patched against vulnerabilities much more quickly than firewalls. Firewall vendors often sit on known issues for years without patching, and patching a firewall cluster typically requires downtime for many services and outbound connections.
- Firewalls are far from perfect, and many are notoriously buggy. Firewalls are just software running on some form of operating system, perhaps with an extra ASIC or FPGA in addition to a (usually slow) CPU. Firewalls have bugs, but they seem to provide few tools to address them. Therefore firewalls add complexity and an additional source of hard-to-diagnose errors to an application stack.
Solution 2:
TCP Wrappers could be arguably called a host-based firewall implementation; you're filtering network traffic.
For the point on an attacker making outbound connections on an arbitrary port, a firewall would provide a means of controlling outgoing traffic as well; a properly configured firewall manages ingress and egress in a way which is appropriate to the risk related to the system.
On the point about how any TCP vulnerability isn't mitigated by a firewall, you're nt familiar with how firewalls work. Cisco has a whole bunch of rules available for download which identify packets constructed in a way that would cause particular operating systems problems. If you grab Snort and start running it with the right rule set, you will also get alerted on this kind of thing. And of course, Linux iptables can filter out malicious packets.
Basically, a firewall is proactive protection. The farther you get away from being proactive, the most likely that you'll find yourself in a situation where you're reacting to a problem rather than preventing the problem. Concentrating your protection at the border, as with a dedicated firewall, makes things easier to manage because you have a central choke point rather than duplicating rules everywhere.
But no single thing is necessarily a final solution. A good security solution generally is multi-layer, where you have a firewall at the border, TCP wrappers at the device, and probably some rules on internal routers as well. You should usually protect the network from the Internet, and protect the nodes from each other. This multi-layer approach isn't like drilling a hole through multiple sheets of plywood, it's more like putting up a pair of doors so an intruder has two locks to break instead of just one; this is called a man trap in physical security, and most every building has one for a reason. :)
Solution 3:
(You may want to read "Life without Firewalls")
Now: What about having a legacy system for which no patches get published anymore? What about not being able to apply the patches to N-machines at the time you need to do so, while at the same time you can apply them in fewer nodes in the network (firewalls)?
There's no point in debating the firewall's existence or need. What really matters is that you have to implement a security policy. To do so you will use whatever tools will implement it and help you manage, expand and evolve it. If firewalls are needed to do so, that's fine. If they are not needed that's fine too. What really matters is having a working and verifiable implementation of your security policy.
Solution 4:
Most of your explanations seem to refute a need for a firewall, but I don't see a con to having one, other than the small amount of time to set one up.
Few things are a "necessity" in a strict meaning of the word. Security is more about setting up all the blockades you can. The more work needed to break into your server means less chance of successful attack. You want to make it more work to break into your machines than somewhere else. Adding a firewall makes more work.
I think a key use is redundancy in security. Another plus of firewalls is you can simply drop attempts to connect to any port rather than responding to rejected requests - this will make nmapping a little more inconvenient for an attacker.
Most important to me on the practical note of your question is you can lock SSH, ICMP, and other internal services down to local subnets as well as rate limit incoming connections to help alleviate DOS attacks.
"The point of security isn't to defend yourself after a successful attack - that's already proven to be impossible - it's to keep the attackers out in the first place."
I disagree. Limiting damages can be just as important. (under this ideal why hash passwords? or stick your database software on a different server than your web applications?) I think the old saying "Don't stick all of your eggs in one basket" is applicable here.
Solution 5:
Should I firewall my server? Good question. It would seem that there is little point to slapping a firewall on top of a network stack that already rejects connection attempts to all but the handful of ports that are legitimately open. If there is a vulnerability in the OS that allows maliciously crafted packets to disrupt/exploit a host, would a firewall running on that same host prevent the exploit? Well, maybe ...
And that is probably the strongest reason to run a firewall on every host: A firewall might prevent a network stack vulnerability from being exploited. Is that a strong enough reason? I don't know, but I suppose one could say, "No one ever got fired for installing a firewall."
Another reason to run a firewall on a server is to decouple these two otherwise strongly correlated concerns:
- From where, and to what ports, do I accept connections on?
- Which services are running and listening for connections?
Without a firewall, the set of services running (along with the configurations for tcpwrappers and such) completely determines the set of ports the server will have open, and from whom connections will be accepted. A host-based firewall gives the admin additional flexibility to install and test new services in a controlled way before making them more widely available. If such flexibility is not required, then there is less reason to install a firewall on a server.
On a final note, there is one item not mentioned in your security checklist that I always add, and that is a host-based intrusion detection system (HIDS), such as AIDE or samhain. A good HIDS makes it extremely difficult for an intruder to make unwanted changes to the system and remain undetected. I believe all servers should be running some kind of HIDS.