Perimeter Firewall Best Practices

Author: Martin Voelk
April 16, 2015

A lot of businesses have perimeter firewalls these days, which is a good thing. However, they must be configured appropriately to provide effective threat protection. Regardless whether you have a Cisco ASA, Juniper SRX, SonicWall, PaloAlto or any other vendor in there – a few best practices apply to them all. Here a 15 bullet point cheat sheet for Firewall Best Practice:

15 Best Practices for Firewalls

  • Software versions checked and up to date.
  • Configuration kept off-line, backed up, access to is limited.
  • Configuration is well-documented, commented.
  • Users and passwords configured and maintained (AAA) and Password encryption in use
  • Access restrictions imposed on Console, Aux, VTYs. Unneeded network servers and facilities disabled. Necessary network services configured correctly (e.g. DNS) Unused interfaces and VTYs shut down or disabled.
  • Risky interface services disabled.
  • Port and protocol needs of the network identified and checked. Access lists limit traffic to identified ports and protocols.
  • Rules block reserved and inappropriate addresses.
  • Static routes configured where necessary.
  • Routing protocols configured to use integrity mechanisms.
  • Logging enabled and log recipient hosts identified and configured.
  • Firewall’s time of day set accurately, maintained with NTP.
  • Logging set to include consistent time information.
  • Logs checked, reviewed, archived in accordance with local policy.
  • SNMP disabled or enabled with good community strings and ACLs. -> or SNMPv3
Share

April 2, 2015

Stateful firewalls are very common these days. In a nutshell all traffic initiated from the inside is allowed out and the return packets of a TCP session which has been initiated from the inside are allowed back in. Any other outbound to inbound communication needs an explicit rule on the firewall. So far, so good.

However, what happens if an attacker can compromise any open service on a server which is open at the Firewall? A classic here is port 80, as Web servers need to be accessible, right?

Here is a little case study from a recent Pentest. It was a relatively small company with an ASA 5505 perimeter firewall. Pretty much locked down from the outside except for port 80. No DMZ was in place but an in-house intranet portal was exposed on purpose to the outside world. That web server had a serious flaw and we were able to exploit it without much hassle. We have then uploaded the so-called mad leets script to the document root of that web server and then accessed the mad leets php file through a Web browser.

Mad Leets is an evil script as it allows control over the machine by moving all traffic through port 80.

What could have been done proactively to prevent such an attack? Well 2 things spring to mind.

  • Deep Packet inspection aka Web Application Firewall
  • Outbound connection filtering on the ASA

Many clients still struggle to understand that attacks are often tunnelled through legitimate open ports such as 80, 22, 110 etc. Only inspecting within the protocol may detect malicious behaviour. Of course port 80 must be open, but it’s vital to check what’s transmitted over that port.

Secondly, once an internal machine behind a stateful Firewall has been compromised by any means (remote exploit, social engineering USB stick etc.) the attack is usually stopped nowhere as the stateful Firewall will natively trust inside or DMZ hosts going out. We find that more than 90% of all Firewalls we assess don’t do outbound filtering at all. The reverse shell concept isn’t anything new but current architectures allow for those compromises unfortunately.

We strongly advice to inspect traffic with Web Application Firewalls and/or IPS systems and in addition run through potential what/if scenarios and how a compromised inside host could expose services to an attacker.

Share