Why should I firewall servers?
serverfault.com
serverfault.com
But, once you have two machines, it makes far better sense to centralize access control in a single place. With two machines, it's simply good engineering. As your stable of machines grows, it's less a style point and more a necessity. It's hard to keep a group of machines in sync with a single policy, and virtually impossible to avoid mistakes and windows of vulnerability over the long run.
An attacker that truly wants to target your network can continuously profile your network, and is more likely to spot your mistakes than you are. A sensible way to approach network security is to assume that there's always someone who's willing put forth the effort to break in.
When a server is compromized then iptables on it won't help anymore, not even to detect that the server is compromized! Only a firewall running on a seperate piece of hardware helps.
A system should never be designed with the assumption that it will never be hacked: that is like planning for a life where you never get sick.
Can you really put "simple" in the same sentence as firewall? Vendors prevent that. Folks don't have time to maintain them.
Also - having policy for the network guaranteed at a single chokepoint (Usually a ruleset that generates firewall configuration, that is then pushed onto hundreds of firewalls) is a big win. One spot to audit.
With all that said - if you are a tiny 2-3 person shop, you can probably get by without Load Balancers, Firewalls, or heck, most infrastructure out there. Just throw it all on AWS/slicehost/linode and harden your hosts to do the right thing.
But, when you get big, and have hundreds (thousands?) of hosts, and are tempted to run them yourself, you will have firewalls, and loadbalancers. Many of them, in fact.
Check out Margrave (http://www.cs.brown.edu/~sk/Publications/Papers/Published/nb... ) for some of the interesting stuff around formalizing policy inspection.
They can detect and take action against denial of service attacks, port scans and probes for known vulnerabilities. They can manage incoming connections statefully.
They can block outgoing connections (big one there), including replies from the stack that give away information you don't want to give away.
They can also log what's going on.
Really, the ideal system only responds to the one port you're serving (and should stop that if you DOS or probe the system).
Suppose you have a standard database backed website. With his procedure the database would wind up on the internet, exploitable by anyone who knows of a security flaw in it. Under standard operating procedures you'd have a firewall which the web servers are accessible to, and a second firewall that allows the web servers to connect to the database but for nobody else to. Now if someone on the internet knows of a problem in your database software, it is not easily exploitable.
His point in my understanding is that you should harden your servers, firewalled or not, and to hardened hosts firewall doesn't add a lot of value anymore.
However, as far as computer security goes it is very far from an ideal world.
See ghshephard's comments about "Defense in Depth" above.
What I liked about his argument was that he was actively thinking about threats instead of applying a heuristic of "it's ok -- we have a firewall." With all this said (and asked), I'm no security expert.