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 "
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.
This was first published in July 2002