Best Practices

Best Practices

This section looks into some of the best practices for PIX Firewall when deployed to the production network, including:

Protecting the PIX Firewall Itself

The PIX firewall protecting your network should be secured by itself. Following are some of the recommendations for securing the firewall that is protecting your network from the hostile environment:

  • Physical security As the firewall is one of the most critical network devices in your network, proper action should be taken to protect it from a hacker's physical access. Having console access can help the hackers to change the policy, which can cause severe harm to the network. It is recommended that you turn off the password recovery ability on the PIX with Version 7.0.

  • Link bandwidth policing Under no circumstances should you allow more traffic to flow to a PIX firewall interface than it can handle. This can happen when your network or ISP is affected with a virus such as code red, and so on. So, proper QoS needs to be configured to police the bandwidth on both upstream and downstream routers. Though PIX Firewall has a good mechanism for protecting against DoS attacks, the mechanism is for protecting internal network resources, not for the PIX from DoS. Therefore, an effective method to implement QoS on upstream and downstream routers is to police bandwidth.

  • Secure access for management purposes There are multiple ways to allow access for managing the PIX Firewall. Among them, Telnet is the only one that is not secured. Arguably, the console is not secured either if it is connected via reverse Telnet. So, for remote management, it is best to configure SSH instead of Telnet on the PIX firewall.

  • Access control and password Be sure to configure access control for the Console port before providing access for managing the PIX. In a non-AAA environment, use passwd, and enable password commands. If AAA is configured on the PIX, be sure to apply AAA for connections. SSH with AAA is highly recommended for device management.

  • Regular monitoring by an IPS device Though PIX has IPS capacity, it is very limited. IPS devices such as the sensor or IDSM blade could be useful for analyzing the exploitation. In the absence of an IPS monitoring device, you might rely on PIX syslog to analyze the traffic, which is not a very effective solution in a large network due to the amount of syslog.

  • Syslog monitoring if IPS is absent In the absence of IPS devices, syslog may be used to monitor the traffic coming in or going out of your network. However, while configuring the syslog, you might need to pay extra attention to the level of detail you want to configure to collect syslog. If you leave the debug-level logging on, that might cause slow performance, because of the amount of CPU cycles it uses. Move messages you want to see to lower levels, instead of raising logging levels and capturing messages you do not want to see.