There's a lot of discussion in infosec circles on the usefulness (or not) of traditional packet filtering firewalls against today's attacks. Those of us in the industry have long since known that for a firewall to detect modern attack vectors, they need to be application-aware in some way, as with web app firewalls, or proxy-based firewalls.
I also often argue that even traditional packet filtering is still relevant. Traditional packet filtering firewalls allow you to enforce the principal of least privilege at a network level. If systems on the public internet should never be able to route packets to your HR database, then well... enforce it with a firewall.
Ever tried to detect and respond to a so called "slow and low" attack or an APT that occurred over a sustained period of time, leveraging multiple attack vectors? Having an archive of firewall logs to mine from can make or break you.
These are just two examples of how a traditional firewall still has relevance.
With that said, for non-infosec people, there are still some fundamental misunderstandings out there. I read a blog post recently by the CEO of a small SaaS vendor who explained that their customers need have no fear about the privacy of their data, because there was a packet filtering firewall between the web servers and the database; even going so far to say that these firewalls are how he "sleeps well at night".
I wrote him a note pointing him to a report published earlier this year detailing web application attack methods and offered the following commentary. I'm reposting it here in the hopes that others with this misconception can learn about the risks and make better decisions to protect their customer's data.
As the browser became the default "client" software to access applications, ports 80 and 443 became the only ports needed to get access the crown jewels buried deep behind firewalls. Since your sample architecture would require those ports are open to the internet, the entire chain of firewalls behind it are irrelevant. An attacker only needs to access the web server and trick it to acting on his or her behalf.
But how? A single SQL injection vulnerability in the web application on your web server allows an attacker to submit queries that your packet filters, who are only aware of level 3 information, happily send straight to the database. This query that an attacker passes to the web server in a query string, or form submission, would pass through these firewalls as it would have appeared to originate from your own web server as well. The perspective of the attacker, from a normal firewall’s perspective, is your own web server; in your network. In your blog post, you are assuming that in order to attack those backend database servers, an attacker would have to actually compromise each server in the chain. Most attacks these days, as this report shows, happen at the application layer. Traditional firewalls still have relevance, but to stop the most prevalent attacks of the day that compromise customer data, they are rendered almost useless.
Then I offered to chat any time if I wasn't making sense or if he needed help rethinking the design.
Btw, he never responded. I wonder how well he's sleeping.