Practical IT: are your firewalls in the wrong place?

Rewind to the 1990s, and the firewall was an organisation’s main technical control for network security.

Firewalls were expensive, complicated and arcane. They sat right on the boundary between the dangerous public internet and your safe internal network.

The model was refined with the addition of the DMZ, or demilitarised zone. The DMZ was a buffer between your internal network and the internet in which you placed at-risk public-facing systems such as web and mail servers.

This model remains largely intact today, twenty years since the first commercial firewalls became available.

This is remarkable given that computer security pioneer Bill Cheswick pointed out the model’s fundamental weakness in 1990 by describing a firewall as “a sort of crunchy shell around a soft, chewy center.”

To its credit, the firewall has come a long way. Basic packet filtering capabilities are now de rigueur for anything with a network interface. Even smartphones can have their own software firewall.

Further up the value chain, UTMs are emerging as a popular and effective option for network security, providing sophisticated packet filtering, intrusion prevention, and a host of other features in a single box.

But perimeter controls, even with a segregated DMZ, are no longer enough. In many organisations, large and small, just mapping out the perimeter is an all-but-impossible job. (If you’re not convinced, please read my previous article on Handling Perimeter Expansion and Disintegration.)

The problem is a sword with two edges:

• The most popular (and useful) applications need access to the internet – exactly the ones you want to let through your firewall.
• These internet-enabled applications are the most popular starting point for cybercriminals – exactly the ones you want to block at your firewall.

In other words, you’ve just drilled a hole through your “crunchy shell” that lets crooks access the very applications they’d probably have attacked first even if you didn’t have a firewall.

Take a web application with a back-end database.

A standard architecture would probably place your web servers in the DMZ, and your back-end database on the internal corporate LAN. Traffic filtering would lock down the web servers so they could receive connections only from the outside, via the http and https ports (80 and 443), and make connections only to the inside, via the SQL port (e.g. 1433).

Unfortunately, this firewall configuration has two glaring problems. One, the ports required for your application to work are also the most vulnerable and interesting for an attacker. Two, it’s doing nothing to isolate the attacker from other servers in the DMZ.

Your DMZ probably consists of a lot more than your web application servers. For example, it may also host your email and DNS servers.

Sadly, as penetration testers will tell you, it’s often very easy to pivot between servers if there is no firewall between them. The result is that an attacker with access to one server in your DMZ, or worse still, your internal network, may quickly get into a lot of other systems.

You can boost your defences here by adding packet filtering between servers. There is usually little reason for servers that deliver unrelated applications to talk to each other. This is particularly true for risky services such as Windows RPC and RDP (Remote Desktop Protocol).

If you don’t need to send packets from server X to server Y, why give an attacker the opportunity to do so?

You can add yet another defensive layer by being smarter and more scrupulous about the traffic you allow. For example, you need to allow outsiders to connect to port 80 on your web application server inside your DMZ. But you don’t need to allow them to conduct just any sort of conversation on that port.

This is where protocol-aware protection technologies such as intrusion prevention systems (IPS), web application firewalls (WAF) and application control come into play.

Configuring “smart filtering” features of this sort is more complex than simply enabling or blocking network traffic by IP address or port number. Different protocols, and different applications using the same protocol, need different sorts of scrutiny. Set-and-forget, or a one-policy-fits-your-whole-network approach, isn’t going to serve you well.

But configuring, managing and adapting your smart filtering policies doesn’t have to be a burden, even though it’s not as easy as clicking accept or deny against a list of port numbers.

The trend toward feature consolidation onto a single appliance can help. Delivering packet filtering, intrusion prevention, web application protection, load balancing and more on a single box can bring serious savings: defence in depth doesn’t have to mean deeper pockets.

_{Firewall image from Shutterstock.}

Do you run a network at home, perhaps for friends and family, or even just for fun? How well protected are you?

Why not try our free Sophos UTM Home Edition?

You get a web application firewall, web and email filtering, IPS, VPN and more for up to 50 IP addresses.

Turn that spare PC into a full-on network security appliance!