Protect your firewall and set embryonic limits

You've implemented a firewall with a good security policy to protect your production or corporate network, but...

do you know your security baseline? When was the last time you checked your firewall logs and updated your baseline to reflect the latest traffic volume to your servers? We continue our series from the "Profile of sophisticated hackers" article and direct our attention to protecting your firewall and setting embryonic limits in your static statements. Join me on a journey to explore and identify the security weak links in your network.

Why is it important to understand the latest traffic volume to your servers? Why allow unlimited connections in the firewall to your SMTP server, if your syslog server has never logged more than 100 simultaneous connections to the mail server? Why allow more connections in the firewall to your Outlook Web Access (OWA) server than configured OWA users? These are just two servers (out of many) that can benefit from an embryonic limit. Your PIX firewall policy should reflect the minimum connection requirements (with some room for growth) of your servers, where the value of "max_conns" and "em_limit' is NOT set to unlimited.

The firewall is your company's second level of defense against hackers on the Internet. Yet, most "out-of-the-box" firewall configurations support unlimited connections to your servers, and, for example, in the case of PIX firewall version 5.34, unlimited incomplete (embryonic) connections are supported by default. In other words, your servers are susceptible to a flood attack, unless you set an appropriate embryonic limit in your static entry for each server.

There is no "one-size-fits-all" setting when it comes to the maximum connections and/or embryonic limits in the firewall for your servers -- perhaps this explains why Cisco PIX defaults to unlimited for both settings. Administrators should extrapolate the information necessary to arrive at a conclusion from the firewall and server logs. If you haven't checked your firewall logs recently, now would be a good time to do so and begin to establish a security baseline and improve your firewall security policy.

If your PIX firewall policy accepts unlimited connections or has no embryonic limits defined for your servers, then you have found your first weak link. Below is a sample configuration file to improve the security of your firewall. Remember to make a backup of your firewall and test your security rules.

This is a partial sample file; it assumes you understand how to install an access list. Let's examine the sample firewall config:

! Sample PIX 5.34 firewall config
! See static entries below for maximum and embryonic limits
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password <PWD>encrypted
passwd <PWD> encrypted
hostname <HOSTNAME>
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060
no fixup protocol rtsp 554
names

! Access list for servers defined in static list below
access-list outside_in permit tcp any host <YOUR MAIL SERVER> eq smtp
access-list outside_in permit tcp any host <YOUR OWA SERVER> eq 443
access-list outside_in permit tcp any host <YOUR IIS SERVER> eq 80

no pager
logging on
logging timestamp
no logging standby
no logging console
no logging monitor
no logging buffered
logging trap informational
no logging history
logging facility 22
logging queue 512
logging host inside <SYSLOG>
interface ethernet0 100full
interface ethernet1 100full
mtu outside 1500
mtu inside 1500
ip address outside <INTERFACE> <MASK>
ip address inside <INTERFACE> <MASK>
ip verify reverse-path interface outside
ip audit info action alarm
ip audit attack action alarm
no failover
failover timeout 0:00:00
failover poll 15
failover ip address outside 0.0.0.0
failover ip address inside 0.0.0.0
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0 0 0

! Maximum connection is set to 100 and embryonic to 25 for SMTP & OWA servers
static (inside,outside) <Valid IP> <YOUR MAIL SERVER> netmask 255.255.255.255 100 25
static (inside,outside) <Valid IP> <YOUR OWA SERVER> netmask 255.255.255.255 100 25
static (inside,outside) <Valid IP> <YOUR IIS SERVER> netmask 255.255.255.255 1000 100

access-group outside_in in interface outside
route outside 0.0.0.0 0.0.0.0 <default gateway> 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 si
p 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
no sysopt route dnat
isakmp identity hostname
terminal width 80

It's been my experience that some of these basic steps have often been overlooked by experienced IT professionals. If you're serious about security, you must pay attention to details and leave no room for hackers.

In our next issue, we'll continue our series with configuration tips to improve your IIS security.

Please write to me and let me know if this article has brought to light any potential weak links in your network.

About the author:
Luis Medina is the author of "The Weakest Link Series," which offers network managers an opportunity to identify ongoing network security issues. Luis also answers security questions in SearchNetworkings Ask the Expert section. Submit a security question to Luis or view his previously answered Ask the Expert questions.