Two types of firewalls are predominantly used today: application proxies and packet-inspecting/filtering gateways . Application proxies are identified by their ability to read and process an entire packet to the Application level and make filtering decisions based on the actual application data, not just the packet header. Packet-inspecting/filtering gateways are generally not able to process a packet to the Application level to make a filtering decision. Instead, packet-inspecting/filtering gateways tend to process the data to the Network/Transport layer and make filtering decisions based on the protocol and port numbers contained in the packet header only. Many packet-inspecting/filtering gateways are becoming hybrids, offering some basic application-filtering capabilities for specific commonly used applications, such as HTTP/Web traffic. Much debate exists about which firewall system is better for which environment. However, regardless of the type of firewall you have, you can perform some common tasks to harden your firewall against compromise.
One of the nice things about firewalls is that because they are expressly designed for security, they often come fairly well hardened from the vendors. After all, if a firewall is going to spend the majority of its life under attack and threat, it doesn t make much sense to design it and not focus on hardening the system. So you might be thinking OK, great, so there isn t anything I need to do then. Well, that s not quite correct either. No matter how hard the vendors try to harden their systems out of the box, they really can t know what you specifically need. Software firewalls, although often well hardened by their vendors , have the unique issue of needing to rely on an underlying operating system to provide bootstrapping functionality. As a result, the underlying operating system of a software firewall often requires extensive hardening in addition to whatever hardening might be required for the firewall application itself. Even hardware firewalls, where the vendor controls every aspect of the firewall and operating system, have common issues and vulnerabilities that can be hardened in many environments. As a result, you can do a number of things to further harden your firewalls and protect them from being compromised. We are going to look at the following common tasks you can perform to further harden your hardware-based and software-based firewalls:
Hardening remote administration
Implementing authentication and authorization
Hardening the operating system
Hardening firewall services and protocols
Providing redundancy and fault tolerance
Hardening routing protocols
Remote administrating presents a unique quandary to a firewall administrator. On one hand, the best solution to hardening your firewall against remote administration exploits is to simply not allow any remote administration. On the other hand, not having remote administration capabilities can make an administrator s job much more difficult. Security is always a struggle between providing the best security and providing the required level of functionality. In environments that require remote administration, you can perform specific steps that can mitigate the risks involved with remote administration by providing secure remote administration functionality. In this section, we look at how to provide both options.
Most firewalls provide remote administration capabilities through the use of web-based (HTTP/HTTPS), Telnet, or SSH sessions, although Check Point uses a proprietary management console known as the Windows/X-Motif GUI client. To prevent remote administration exploits, simply turn the web-based, Telnet, and SSH services off. In the case of Check Point GUI clients , the most effective method of preventing remote administration is to not grant any hosts remote administration access through the use of a ruleset.
For example, with the Cisco PIX firewall, you can use the PIX Device Manager for web-based management. This access can be disabled by running the following command at the CLI:
firewall(config)# no http server enable
Likewise, if you want to disable Telnet and SSH access for a PIX firewall, you can run the following commands at the CLI for all IP addresses that have been granted Telnet or SSH access:
firewall(config)# no telnet <local_ip> [<mask>] [<if_name>] firewall(config)# no ssh <local_ip> [<mask>] [<if_name>]
The syntax < local ip > refers to the IP address of the remote management system. Make sure you run the preceding commands for every local IP address that has been granted access.
Because iptables is an open-source firewall solution, a number of open -source web-based management tools can be used for remote administration. However, most of them rely on Apache or a similar web server to be running on the Linux host that is running the firewall. Telnet and SSH access for iptables works in a similar fashion, relying on the underlying operating system or a third-party vendor to provide Telnet and SSH services. The actual service names will vary depending on the vendor that supplies the software. For example, the service that runs Apache is sometimes called httpd and other times is called apache. You can stop and prevent most services from running by entering the following commands at the CLI (you will need to be logged on as root to run these commands):
chkconfig 'service_name' off service 'service_name' stop
The first command prevents a service from running at startup. The second command stops the service. For more information regarding how to stop and start services on Linux, see Hardening Linux by John Terpstra.
Removing remote administration capabilities for Check Point is a little more tricky than it is for the PIX and iptables because Check Point uses HTTPS and SSH for certain configuration tasks and uses a proprietary GUI client for the majority of the actual ruleset and firewall administration tasks. You can turn off HTTPS server functionality by running the following command at the CLI:
[cpfirewall]# webui disable
Because SecurePlatform runs on a hardened version of the Linux operating system, you can disable the SSH service similar to how it is done for iptables. First, however, you must enter the expert mode at the CLI. The expert mode grants access to the underlying operating system on SecurePlatform:
[cpfirewall]# expert Enter expert password: <expertpassword> <enter> You are in expert mode now. [Expert@cpfirewall]# chkconfig sshd off
The Check Point Management Interface (CPMI) that enables remote GUI clients to connect cannot be turned off like Telnet and SSH can. However, you can prevent the Check Point firewall from accepting any GUI client connections by removing the permitted GUI client hosts using the cpconfig command from the CLI as follows :
[cpfirewall]# cpconfig This program will let you re-configure your VPN-1 & FireWall-1 configuration. Configuration Options: (1) Licenses (2) Administrators (3) GUI Clients ...... (12) Exit Enter your choice (1-12) :3
Here you would select option 3 (GUI Clients).
Configuring GUI Clients... GUI Clients are trusted hosts from which Administrators are allowed to log on to this SmartCenter Server using Windows/X-Motif GUI. you have selected the following hosts to be GUI Clients: 192.168.173.107 Do you want to modify this list (y/n) [y] ? y Do you want to [C]reate a new list, [A]dd or [D]elete one?: d Enter the host you wish to delete: 192.168.173.107 192.168.173.107 will be deleted. Are you sure? (y/n) [y] ? y 192.168.173.107 was deleted successfully! Configuration Options: (1) Licenses (2) Administrators (3) GUI Clients ...... (12) Exit Enter your choice (1-12) :3
Here again you would select option 3 (GUI Clients).
Configuring GUI Clients... ========================== GUI Clients are trusted hosts from which Administrators are allowed to log on to this SmartCenter Server using Windows/X-Motif GUI. No GUI Clients defined Do you want to add a GUI Client (y/n) [y] ?
You will need to remove all the GUI clients listed until the firewall specifies No GUI Clients defined.
So far we have looked at how to disable remote management access to harden your firewall. Now you are no doubt thinking, Yeah, that sounds great, but let s get back to the real world where I need to be able to remotely manage my firewall. Although disabling remote management access is indeed the best way to prevent a remote management exploit, the reality is that most of us need that remote management capability. The good news is that you can perform the following tasks to harden remote management access while still allowing yourself to take advantage of the benefits that remote management access provides:
Allow only secure remote management access, such as SSH, HTTPS, or the Check Point GUI client
Restrict remote management access only to permitted hosts.
If possible, require all remote management to occur over a management segment.
Implement authentication and authorization to control who can log on and what they can do when logged on.
One of the most common methods of providing remote access to firewalls is through the use of Telnet. As we all know, however, Telnet uses an unencrypted session for the transmission of data. As a result, if you use Telnet to manage your firewall, you are taking what should be one of your most secure devices and making it extremely insecure. How insecure ? Anyone with a packet sniffer can read everything that goes between your management system and the firewall, including every password you type. For example, using Ethereal, I can capture and play back a captured Telnet session by right-clicking any frame in the Telnet capture and selecting Follow TCP Stream. This gives me the following results:
As you can clearly see, the password is too easy to sniff. HTTP, being unencrypted just like Telnet, has the same vulnerabilities. Consequently, you should never use Telnet or HTTP to manage your firewalls. Turn it off, as referenced in the preceding examples.
If you need to remotely manage your firewalls, use either SSH for command-line access or HTTPS for web-based management ”both protocols encrypt the data being transmitted. In addition, you should restrict management access to specific interfaces and allow traffic from specified addresses only. For example, you might want to permit management traffic only on the inside interface of a firewall and only from your management system s IP address.
Enabling SSH management for the Cisco PIX is a three-step process. First, you must configure the hostname and domain name for the firewall. Second, you must configure an RSA key for the SSH server to use. Third, you grant access for specific hosts to connect to specific interfaces using SSH. This is accomplished by running the following commands at the CLI:
firewall(config)# hostname firewall firewall(config)# domain-name yourcompany.com firewall(config)# ca generate rsa key 1024 For <key_modulus_size> >= 1024, key generation could take up to several minutes. Please wait. Keypair generation process begin. ..Success. firewall(config)# ca save all firewall(config)# ssh <local_ip> [<mask>] [<if_name>]
You must run the command ca save all because RSA keys are not saved when you copy the running configuration to the startup configuration. If you do not run this command, when you reboot the PIX firewall, it will lose any unsaved RSA keys, thus preventing SSH connections from being established.
One nice thing about the Cisco PIX is that it only allows HTTPS access, so if you enable the HTTP server on it, you are only granting HTTPS access. This is a two-step process that includes first enabling the HTTP server and then granting specific IP addresses or networks access to the HTTP server service. These commands supersede any ACLs, so you don t need to explicitly permit this traffic via an ACL. This can be done by entering the following commands at the CLI:
firewall(config)# http server enable firewall(config)# http <local_ip> [<mask>] [<if_name>]
Because iptables relies on the underlying operating system to provide SSH and web server functionality, you will need to configure the relevant SSH or web server service in the operating system. In general, all services can be enabled at the CLI with the following commands:
chkconfig 'service_name' on service 'service_name' start
The first command configures the service to start automatically upon reboot. The second command causes the service to start running immediately.
Web management of iptables is a much more complex process in that it requires an extensive knowledge of Apache in order to properly implement it. Consequently, I advise against using web management of iptables, instead relying on SSH to perform command-line configuration. If you find yourself requiring web management, however, you need to configure Apache as follows:
Implement mod_SSL and OpenSSL to provide for HTTPS encryption. (See http://httpd.apache.org/docs-2.0/ssl/ for configuration examples.)
Implement authentication, requiring all connected users to authenticate prior to being permitted to perform any configuration functions. (See http://httpd.apache.org/docs-2.0/howto/auth.html for configuration examples.)
Configure iptables to allow HTTPS connections to the firewall system. For example, if you wanted to permit a management system at 192.168.1.100 to access the firewall at 192.168.1.1 on interface eth0, you would run the following command:
At the end of some code lines throughout this book, you ll see a right-pointing arrow (’). This signifies that the single-line command, which really should fall on one line, must break due to width limitations of the printed page.
iptables -A INPUT -I eth0 -p tcp -m tcp -s 192.168.1.100 d 192.168.1.1 --dport 443 --syn -j ACCEPT
Providing remote administrative capabilities for Check Point is similar to the Cisco PIX in that Check Point only allows SSH, HTTPS, and their proprietary GUI client. By default, SSH is enabled on the Check Point system, so no further configuration is required. Similarly, you can enable HTTPS by selecting to enable it during the installation or by running the following command at the CLI after installation:
[cpfirewall]# webui enable 443
Make sure you have configured your firewall rules to permit SSH or HTTPS access from the management systems you want to grant access to.
Configuring the GUI client for Check Point is a relatively straightforward process. By default, Check Point supports the use of the GUI client. You simply need to specify the management stations to be permitted. You can grant GUI client access by running the following commands at the CLI:
[cpfirewall]# cpconfig This program will let you re-configure your VPN-1 & FireWall-1 configuration. Configuration Options: (1) Licenses (2) Administrators (3) GUI Clients ...... (12) Exit Enter your choice (1-12) :3
Here you would select option 3 (GUI Clients).
Configuring GUI Clients... GUI Clients are trusted hosts from which Administrators are allowed to log on to this SmartCenter Server using Windows/X-Motif GUI. you have selected the following hosts to be GUI Clients: 192.168.173.107 Do you want to modify this list (y/n) [y] ? y Do you want to [C]reate a new list, [A]dd or [D]elete one?: a You can add GUI Clients using any of the following formats: 1. IP address. 2. Machine name. 3. "Any" - Any IP without restriction. 4. A range of addresses, for example 22.214.171.124-126.96.36.199 5. Wild cards - for example 1.2.3.* or *.checkpoint.com Enter GUI Client: 192.168.173.109 192.168.173.109 will be added as a GUI Client. Are you sure? (y/n) [y] ? y 192.168.173.109 was added successfully!
Regardless of the firewall you are running, when you decide to enable remote administration, you should follow these general recommendations:
Provide only secure remote administration. Do not allow native HTTP or Telnet connections.
Grant access only to specific administrative workstations.
If possible, require all remote administration to occur on a dedicated administration segment. If that is not possible, only allow remote administration to occur on trusted interfaces.
The next step in hardening the firewall is to allow only authorized users to connect to and manage the firewall. In addition, those users should only be able to perform the specific tasks they have been authorized to perform. This section is a subset of Authentication, Authorization, and Accounting (AAA), which covered in more detail, including providing configuration examples, in Chapter 9.
One of the biggest authentication flaws that occurs on a network is the use of common user accounts and passwords. People use the administrator account to log on to Windows, they use the root account to access Unix/Linux, they use telnet and enable or enable secret passwords for Cisco equipment, and they use the admin account for Check Point. The problem with this is that it removes all accountability from the system. Instead of using common accounts and passwords to access your firewall, you should create unique users for performing management tasks.
Generally, two methods are used to provide unique usernames and passwords for management tasks. The first method is to create unique local accounts on every firewall in your environment. The obvious flaw with this method is that it does not scale very well. However, if you are in a small environment, this method is still better than using common usernames and passwords and worth the effort to implement. The other method is to use an authentication server to validate the user s identity. The benefits to this type of system are centralized user account management and greater scalability. When a user needs to be added or deleted, you can do so at the authentication server instead of needing to make the changes on multiple firewalls. The two most widely used authentication servers available for use are RADIUS and TACACS/TACACS+.
Regardless of whether you choose to go with local users or centralized authentication through the use of authentication servers, you will want to ensure that you use a hard password policy for all the users, as specified in Chapter 2. One of the things I like most about Check Point is that it enforces a password policy that requires the user to use passwords that are not based on dictionary words so that they are more difficult to crack. At a minimum, you should require that all your users adhere to the following policy:
Do not allow the use of a password that is based on a dictionary word.
Require the use of letters , numbers, and special characters in the password.
Do not require passwords to be so complex or difficult that people have to write them down to remember them. At that point, you have defeated your entire password policy.
In concert with hardening authentication, hardening authorization is the process of specifying what tasks an authenticated user is authorized to perform. Authorization allows you to define different levels of access for your users, as opposed to simply having an all-or-nothing system where someone is either an administrator or isn t an administrator. For example, you may want to have certain users who need to be able to manage the security policy or the access lists on a firewall, but don t need to change IP addresses or update the software on the firewall. Authorization allows you to control who can do what on your firewall, thus further hardening your firewall against attack.
Logon banners should be implemented to set the appropriate expectations of privacy and acceptable use of the system, resources, data, and network access capabilities. Your logon banner should include a notice stating that the monitoring of users activities while they are using the system is authorized and permitted. Your logon banner should also include a warning that legal action may be taken should the monitoring reveal that any illegal activities or violations of the security policy have occurred.
It is important to include logon banners on your systems because the lack of logon banners can make the prosecution of violations much more difficult. In fact, in some legal cases defendants have been acquitted of charges of system tampering because there was no explicit notice that prohibited such activities. Other cases exist where companies have been taken to court for violating an individual s privacy because no notice was given acknowledging that the monitoring of users activities was occurring.
Your legal department should review your logon banners to ensure that they comply to the legal requirements of your state and jurisdiction, as well as to ensure that they are legally sound and without loopholes or flaws. A number of templates are available that you can use as the basis for your logon banner. My favorite, shown here, is located at the CERT website (http://www.cert.org/security-improvement/ implementations /i034.01.html):
This system is for the use of authorized users only. Individuals using this computer system without authority, or in excess of their authority, are subject to having all of their activities on this system monitored and recorded by system personnel. In the course of monitoring individuals improperly using this system, or in the course of system maintenance the activities of authorized users may also be monitored . Anyone using this system expressly consents to such monitoring and is advised that if such monitoring reveals possible evidence of criminal activity, system personnel may provide the evidence of such monitoring to law enforcement officials. Report suspected violations to the system security officer.
One of the drawbacks of using iptables, Check Point, Microsoft ISA Server, or any other firewall that does not run on top of a dedicated operating system is that you need to harden the underlying operating system in addition to hardening the actual firewall application. The sister publications to this book, Hardening Windows Systems by Roberta Bragg and Hardening Linux by John Terpstra, contain detailed hardening procedures for those operating systems. However, in general, you should approach hardening the operating system of any system that will function as a firewall from the following perspectives:
Disable any and all unnecessary services. If the service is not expressly required for the firewall to function, disable it.
Remove any and all unnecessary applications and registry entries. This may seem excessive; however, if your firewall doesn t need an application such as a calculator on it, you should remove it. Once again, unless the application is required for the firewall to function, remove it. Any applications left on the system could allow a hacker to use them to gain further control of the system. Although there may not be a root-level exploit for applications such as a calculator today, there could be one tomorrow. And that is what you are protecting against ”the unknown potential exploits of the future.
Restrict the file system, registry, and services permissions to be run only by authorized users. Any applications that can be executed by an unknown system can be used to exploit a back door. For example, a common way to gain administrative access is to run an application as the localsystem on Windows, thus gaining an unauthorized increase in privileges. Similarly, the default file system in Windows often grants the Everyone group permission to change and execute files. This access should be removed and replaced with much more restrictive NTFS settings.
When changing the default NTFS permissions, be very careful that you do not unintentionally remove system access to files that are required for operation. For example, preventing the system from being able to read ntoskrnl .exe is a bad thing.
Now that you have restricted management access, implement authentication and authorization, and hardened the underlying operating system where applicable , the last step is to harden your firewall s services and protocols. The philosophy here is the same through this book: turn off anything you don t need and harden that which you do need. For most appliance-based firewalls, there aren t a lot of unnecessary services that need to be addressed. Likewise, for most OS-based firewalls, once the OS has been hardened, there aren t a lot of services that need to be addressed. Therefore, in this section we will take a look at four common services/protocols used with many firewalls and consider how to harden them:
Simple Network Management Protocol (SNMP)
Network Time Protocol (NTP)
Trivial File Transfer Protocol (TFTP)
A common theme with all the services mentioned in the preceding list is the fact that they all use an unencrypted transmission method for the delivery of data. You will likely find that many of the network protocols and applications you may want to run on your firewall perform in this manner. In that case, the only viable alternative to securing the traffic is to encapsulate the original data in IPsec and use the encryption of IPsec to protect the data s integrity.
Configuring IPsec on the management station is outside of the scope of this book. However, you can find a good whitepaper for doing this for Microsoft servers at http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q252/7/35.ASP&NoWebContent=1. For further information about how to configure IPsec on Windows or Red Hat Linux systems, see Hardening Windows Systems by Roberta Bragg or Hardening Linux by John Terpstra.
Configuring the Cisco PIX to encapsulate the data in IPsec is a relatively straightforward process. The first step is to configure an access list that will be used to define which hosts require IPsec to communicate. This can be done at the CLI as follows:
firewall(config)# access-list secure permit ip interface inside. host 192.168.1.109
In this case, I configured the access list between the inside interface and the management station located at IP address 192.168.1.109. Next, you must configure the IPsec policy for the PIX, as follows:
firewall(config)# sysopt connection permit-ipsec firewall(config)# crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac firewall(config)# crypto map secure 30 ipsec-isakmp firewall(config)# crypto map secure 30 match address secure firewall(config)# crypto map secure 30 set peer 192.168.1.109 firewall(config)# crypto map secure 30 set transform-set ESP-3DES-SHA firewall(config)# crypto map secure interface inside firewall(config)# isakmp enable inside firewall(config)# isakmp key ******** address 192.168.1.109 netmask 255.255.255.255 firewall(config)# isakmp policy 10 authentication pre-share firewall(config)# isakmp policy 10 encryption 3des firewall(config)# isakmp policy 10 hash sha firewall(config)# isakmp policy 10 group 1 firewall(config)# isakmp policy 10 lifetime 28800
Once this has been done, the PIX will only communicate with the host at 192.168.1.109 via IPsec. This means that if that host is your SNMP, NTP, syslog, or TFTP server, the insecure data will be encapsulated with IPsec and securely transmitted between the firewall and remote host.iptables relies on the underlying operating system to provide IPsec functionality. Contact your operating system vendor regarding their specific IPsec offerings. Another option is to use FreeS/WAN for Linux (http://www.freeswan.org). FreeS /WAN configuration is covered in Hardening Linux by John Terpstra.
Check Point uses the Windows/X-Motif GUI to configure and manage IPsec/VPN connections. Configuring a VPN consists of defining the network to be protected, creating objects that specify the firewall and remote host, assigning the appropriate IPsec/IKE settings to the VPN community, and defining a rule to permit the traffic. The steps to configure IPsec between the firewall and a management station are as follows:
Create a network object for the interface IP address of the firewall by right-clicking Network Objects in the tree pane and selecting New Network.
Add a network to identify the IP address of the firewall. Configure an appropriate name and specify the network address as the IP address of the firewall interface you want to connect to. For the subnet mask, specify a full /32 mask (255.255.255.255). Click OK when you re finished.
Repeat step 2, creating a network to identify the IP address of the management station. Click OK when you re finished.
Add a new interoperable device by right-clicking Network Objects in the tree pane and selecting New Interoperable Device.
Configure the General Properties section with the appropriate name and IP address of the management station. Also, add an appropriate comment for future reference.
Configure the Topology section by clicking Add and entering the network information for the management station interface IP address. Click OK when you re finished.
This step is very important. Under the VPN Domain section, select Manually Defined and specify the network you created for the IP address of the management station in step 3. This will tell the firewall what traffic should be protected by IPsec/VPN. If you do not do this, the firewall will not properly encrypt/decrypt packets, even though it will allow the IPsec/VPN tunnel to be established. Once you are finished, click OK to close the Interoperable Device configuration pages.
Open the new object up again by double-clicking it in the tree pane. Select the VPN section and click Add. Select the appropriate VPN community and click OK. The object should appear similar to the following. Click OK to close the Interoperable Device configuration pages.
Right-click the firewall object and select Edit. Select the Topology section. In the VPN Domain section, select Manually Defined and select the firewall IP address network object you created in step 2.
Select the VPN section and click Add to specify the appropriate VPN community. This should match the community you specified in step 8. When you are finished configuring the firewall, click OK to close the firewall configuration pages.
Now it is time to configure the VPN community you specified earlier. In the right pane, select the padlock to bring up the VPN Community section. Locate the VPN community you specified earlier, right-click it, and select Edit.
Select the VPN Properties section and configure the IKE (Phase 1) and IPsec (Phase 2) settings appropriately for your environment. I recommend that you select 3DES and SHA1 for maximum security, as shown here:
Select the Advanced Properties section and configure the IKE (Phase 1) and IPsec (Phase 2) settings appropriately for your environment. These settings must exactly match on both IPsec/VPN endpoints.
Select the Shared Secret section. Highlight the peer and click Edit. Enter the shared secret value and click OK. The key will be hidden by asterisks on the configuration page for security reasons. Click OK when you re finished to close the VPN Community configuration screens.
The next step is to configure an access rule that permits the traffic and specifies that the traffic should be protected via IPsec/VPN. Press CTRL-ALT-T to add the rule to the top of the ruleset. For the source, add the firewall and the management station. For the destination, reverse the order by adding the management station and then the firewall. For the VPN section, right-click in the cell and select Edit Cell . Select the option Only Connections Encrypted in Specific VPN Communities and then click Add. Select the VPN community you specified previously and click OK.
For the service, leave the default setting of Any. Right-click in the Action cell and select Accept. In the Track cell, right-click and select Log. Right-click in the Install On cell, select Add Targets, and then specify the firewall. When completed, your rule should look something like rule 1:
The last step is to install the policy on the firewall. You can do this by selecting the Policy menu, selecting Install, and then specifying the target. Click OK.
When this is completed, you should be presented with the following screen:
The traffic between the firewall and the management station should be protected by IPsec at this point.
SNMP is a particularly problematic protocol because although it can provide significant benefits to your network, by design it is a highly insecure protocol, particularly SNMP versions 1 and 2. SNMP version 3 mitigates many of these security issues; however, it is a relatively new protocol and lacks widespread support from many vendors. Consequently, I am going to focus on hardening SNMP versions 1 and 2 in this chapter. SNMP version 3 will be covered in more detail in Chapter 10.
The problems with SNMP are well documented; however, the principal issues are that it uses a common authentication mechanism (known as community strings ) and transmits all data in an unencrypted fashion. If you do not need SNMP, then by far the best solution is to turn it off. For the Cisco PIX, SNMP is disabled by default and must be explicitly enabled. For Check Point SecurePlatform, you must explicitly install the SNMP add-on for SecurePlatform, located at http://www.checkpoint.com/techsupport/downloadsng/utilities.html#snmp_addon. For iptables, because it relies on the operating system to provide additional services, you must explicitly install SNMP on the operating system in order to have it available.
If you want to disable SNMP on a Cisco PIX firewall, you can do so by running the following command at the CLI:
firewall(config)# no snmp-server
For iptables, you can disable SNMP as you would any other service, as shown here:
chkconfig 'service_name' off service 'service_name' stop
For Check Point, you can disable SNMP by running the following commands at the expert CLI:
[Expert@cpfirewall]# snmp service disable Stopping snmpd: [ OK ]
If you decide that you need to use SNMP on your firewall, here are some steps to follow to harden the protocol:
Ensure that you are using good community strings. I once got into a discussion with a developer about whether SNMP community strings were passwords. Although the developer was technically correct that they are not passwords, practically speaking they are every bit as valuable as passwords and therefore should be protected accordingly . You should ensure that your community strings, at a minimum, meet the requirements of your password security policy.
Protect the integrity of the data. Because SNMP transmits the data in the clear, there is really only one viable option to protecting the data ”to encapsulate the SNMP communications within an IPsec tunnel. In fact, I recommend that all communications between the firewall and the management system be encapsulated in IPsec, just for good measure.
The final step to hardening SNMP is to only allow SNMP requests from specific hosts.
For the Cisco PIX, you can specify the hosts you want to allow to connect via SNMP by running the following command at the CLI:
firewall(config)# snmp-server host [if_name>] <local_ip>
For iptables, SNMP access is controlled by the use of the ruleset. In order to permit SNMP traffic, configure a rule that allows traffic from the management system to the firewall interface from which you want to perform SNMP administration (in this case, interface eth0):
iptables -A INPUT -I eth0 -p udp -m udp -s 192.168.1.100 -d 192.168.1.1 --dport 161 -j ACCEPT
For Check Point, SNMP access is controlled by the rulebase. In order to permit SNMP traffic, configure a rule that allows traffic from the management system to the firewall interface from which you want to perform SNMP administration, as shown here:
Network Time Protocol (NTP) is used to synchronize time between systems. It is particularly valuable on firewalls for use in the date/timestamping of log files. I strongly recommend the use of NTP because it not only makes troubleshooting easier but can be invaluable when trying to do forensics in terms of determining when something occurred. Like SNMP, however, NTP transmits data in an unencrypted fashion that makes it particularly vulnerable to man-in-the-middle attacks. In addition, until recently, NTP did not use any kind of authentication method. That is no longer the case, however. The current version of NTP supports authentication through the use of an MD5 hash and a pre-shared key. As a result, if you are going to use NTP on your firewall, you should always configure it to use authentication. In addition, like with SNMP, you should encapsulate NTP in IPsec to protect the data integrity. To configure NTP with authentication on the PIX, you can run the following commands at the CLI:
firewall(config)# ntp authenticate firewall(config)# ntp authentication-key 1 md5 authenticationkey firewall(config)# ntp trusted-key 1 firewall(config)# ntp server 192.168.1.109 key 1 source inside
iptables relies on the native operating system to provide NTP functionality. Because different OS vendors can implement NTP differently, you should contact your OS vendor for information about how to configure NTP with authentication for their OS. For Check Point, you can configure NTP at the CLI as follows:
[cpfirewall]# ntp MD5secret 5 192.168.1.109
This will configure the firewall to poll a server at 192.168.1.109 with an MD5 secret of MD5secret.
syslog is another protocol that was never designed for security. Like SNMP and NTP, syslog does not encrypt the data being transmitted. Unlike SNMP and NTP, though, there is no method for authenticating syslog connections. With that said, I firmly believe that syslog should be required when implementing any firewall. The reason for this is simple: syslog has the ability to show you everything that is happening on your firewall at any given time.
During the week I was writing this chapter, I walked into a customer location, installed and configured syslog in their environment, and isolated a routing problem and a VPN problem that they were unaware were the causes of some other issues, within minutes of having syslog configured and operational.
I cannot stress enough how valuable syslog is in managing and maintaining firewalls. However, we still have a problem with the fact that syslog is sending data in the clear. This presents a huge security risk because, for the same reasons that syslog is invaluable as a troubleshooting tool, it is equally invaluable for use by a hacker to gain all sorts of information about how the firewall is configured, what rulesets are in use, and so on. The good news is that we already know how to secure this traffic by encapsulating it in IPsec.
Because syslog utilizes a timestamp for all events, I recommend that you configure NTP prior to configuring syslog. This will ensure that all your logs contain accurate timestamps for forensic and troubleshooting usage. On the Cisco PIX firewall, you can configure syslog by running the following commands at the CLI:
firewall(config)# logging on firewall(config)# logging timestamp firewall(config)# logging host inside 192.168.1.109 firewall(config)# logging trap debugging
The last line configures what level of logging to syslog you want to perform. Logging at debug level causes the maximum amount of information to be logged. However, this can cause a significant amount of traffic to be logged as well as create a processor bottleneck, so you should be careful about setting the logging level to debug. The next highest level of logging is informational, and I recommend that you always log either at this level or debug if your equipment can handle the load.
Another option for syslog you should be aware of on the PIX firewall is the ability to log via TCP instead of UDP (the default for syslog). The benefit of using TCP instead of UDP is that if the PIX is for some reason unable to send events to the syslog server, it will stop accepting any traffic. The downside to this, obviously, is that the PIX will stop accepting any traffic. If your environment requires that if the PIX is for some reason unable to send syslog information it must stop passing traffic, then this is probably an acceptable risk. Other environments should seriously consider whether implementing this configuration will create a larger support issue than the security issue it addresses. If you want to configure the PIX to send syslog via TCP, you can run the following command at the CLI:
firewall(config)# logging host inside 192.168.1.109 tcp/1740
The port number must be between 1025 and 65535. In this case, I selected port 1740 as the port to use.
iptables relies on the underlying operating system for the configuration of syslog. Once the underlying operating system is configured to properly log to a remote host, you can configure iptables to log matching packets by specifying the LOG target extension. For example, if you wanted to log all HTTP packets, you would do that by entering the following command:
iptables -A INPUT -p tcp -m tcp --dport 80 --syn -j LOG
An unfortunate drawback of logging with iptables is that if you want to log packets you are rejecting, you must specify two rules. The first rule should be your logging rule. The second rule would be your reject rule.
Check Point uses a proprietary logging format and logging servers known as Enterprise Log Servers . Although it is possible to configure Check Point to send its logs to a syslog server via the Unix logger command, this generally requires extensive modification of the underlying operating system and I therefore advise against doing it. The biggest reason I advise against doing this is that the procedure is not documented very well by Check Point and really constitutes what is little more than a hack. Until Check Point decides to provide native syslog functionality, the only other supported option for syslog on Check Point is to implement a third-party log-monitoring solution such as NetIQ Security Manager for FireWall-1.
Trivial File Transfer Protocol (TFTP) is susceptible to all the vulnerabilities that syslog is, specifically, no authentication, no encryption, and the use of UDP as a transport protocol. Like syslog, TFTP should be encapsulated in IPsec to ensure data integrity. This is especially important with TFTP because it is often used to transmit configuration files to and from the firewall, allowing anyone with a packet sniffer to capture the TFTP traffic and gain the entire firewall configuration file in clear text. Also like syslog, TFTP traffic should only be allowed to a designated server. You can accomplish this on the Cisco PIX by running the following command at the CLI:
firewall(config)# tftp-server [<if_name>] <ip> <directory>
TFTP is not used with iptables. For Check Point, you manage what systems can act as a TFTP server by configuring the ruleset to permit TFTP traffic from the firewall to the TFTP server.
Today s companies realize that the Internet is a critical business resource that they cannot operate efficiently without. From e-mail, to VPNs, to extranet connections between business partners , to using the Internet as a research tool, the need for redundancy for Internet connectivity has become a requirement at many companies. By that same token, having redundancy with your firewall is an excellent method of hardening your system against hardware failures.
The Cisco PIX supports hardware redundancy on all models except the PIX 501 and PIX 506. Implementing redundancy is simply a matter of getting identical hardware and software in every way, obtaining the appropriate license, and then configuring the firewalls accordingly. The PIX supports two primary methods of configuring redundancy:
Failover via the use of a failover cable
The major difference between the two failover methods is that LAN-based failover supports stateful failover, thus allowing the replication of the following information between units:
TCP connection table, including timeout information
Port allocation table information for PAT
Translation table and status
Negotiated H.323 UDP ports
In addition, because the failover is LAN based, the 6- foot distance limitation on the use of a failover cable is no longer an issue. The drawback of LAN-based failover is that you can have delayed detection of peer power loss.
Configuring the PIX for failover is a relatively straightforward procedure, with the difference between failover methods being a couple of commands. To configure stateful failover (LAN based), run the following commands at the CLI on the primary PIX:
firewall(config)# nameif ethernet2 fo security20 firewall(config)# interface ethernet2 100full firewall(config)# ip address fo 192.168.2.1 255.255.255.0 firewall(config)# ip address outside 192.168.3.1 255.255.255.0 firewall(config)# ip address inside 192.168.4.1 255.255.255.0 firewall(config)# failover ip address fo 192.168.2.2 firewall(config)# failover lan unit primary firewall(config)# failover lan interface fo firewall(config)# failover lan key yourpresharekey firewall(config)# failover lan enable firewall(config)# failover
On the secondary PIX, you need to run the following commands, at minimum:
firewall(config)# nameif ethernet2 fo security20 firewall(config)# interface ethernet2 100full firewall(config)# ip address fo 192.168.1.1 255.255.255.0 firewall(config)# ip address outside 192.168.3.1 255.255.255.0 firewall(config)# ip address inside 192.168.4.1 255.255.255.0 firewall(config)# failover ip address fo 192.168.1.2 firewall(config)# failover lan unit secondary firewall(config)# failover lan interface fo firewall(config)# failover lan key yourpresharekey firewall(config)# failover lan enable firewall(config)# failover
If you re implementing LAN-based failover in a switched environment, ensure that you enable portfast on your switches to prevent them from taking up to 30 seconds to transition between listening to forwarding.
Configuring the PIX for nonstateful failover is a much simpler process, requiring only the failover command to be run on both firewalls.
iptables has no direct redundancy support; rather, because it is an application running on top of an operating system, it requires the operating system to be configured to support clustering in order to provide redundancy. Your operating system vendor can provide you with information regarding clustering solutions. For example, Red Hat has a cluster offering about which you can find more information at http://www.redhat.com/software/rha/cluster.
Check Point has an additional product that can be installed with FireWall-1 called ClusterXL. It provides not only high-availability cluster support to the firewall, but also load balancing of traffic between cluster nodes. The installation and configuration of ClusterXL is outside of the scope of this chapter; however, you can find the Check Point documentation that covers this information at http://www.checkpoint.com/products/accelerate/ clusterxl .html.
As networks have become more complex, the need for routing protocols to effectively define how data should be routed throughout a network has become a requirement. At the same time, firewalls are finding themselves more and more in environments where they need to be able to route between multiple networks. This is especially true when you consider the requirements of implementing a firewall between internal networks instead of in the traditional firewall role on the perimeter. This creates a potential problem however. Like many services and protocols, routing protocols have not always been designed with security in mind. Certain routing protocols (for example, RIP) are particularly vulnerable to attacks such as RIP spoofing. Hackers who are able to gain access to your routing tables have a map that shows them exactly how your network is laid out. Additionally, they can insert routes into your routing table and reroute traffic to a location of their choosing, or stop the flow of traffic completely as a denial of service (DoS). Obviously, the need to harden your routing protocols at your firewall is a critical business need.
As a general rule, I recommend that you only configure static routes on your firewalls. This ensures that your firewalls are not susceptible to poisoned updates and such.
The drawback, of course, is that maintaining static routes in an enterprise environment can be all but impossible to do. For the Cisco PIX firewall, entering static routes is a straightforward process that involves running the following command at the CLI:
firewall(config)# route <if_name> <foreign_ip> <mask>(<gateway> [<metric>]
The Cisco PIX cannot be used as a router between multiple networks on the same interface. This is due to the fact that the Cisco PIX will not route traffic back on an interface that it originated from. For example, if you have two internal networks connected to the same PIX interface and you have a host on network A attempting to connect to a host on network B, either host cannot use the PIX to route that data because the data originated on the same interface that the PIX needs to route it back on. However, if you have a request that originates from an external host, the PIX will route the data to either network because the packet originated on an interface different from the one it needs to exit from. If you need to route between multiple networks on the same interface, you must implement a router and configure your hosts to send the data to the router that will route the data accordingly.
Replace the variables with the corresponding information for your network. For example, if you wanted to add a route to the 192.168.100.0/24 network on your inside interface using a gateway of 192.168.1.254, you would enter the following:
firewall(config)# route inside 192.168.100.0 255.255.255.0 192.168.1.254
iptables relies on the operating system to provide routing information. On Red Hat Linux 9.0, you can add static routes by editing the /etc/rc.local file and adding route lines according to the syntax of the route command:
route add -net 192.168.100.0 netmask 255.255.255.0 gw 192.168.1.254 dev eth0
Check Point allows for the configuration of static routes via the expert CLI through the use of the route command:
[Expert@cpfirewall]# route add -net 192.168.100.0/24 gw 192.168.1.254 [Expert@cpfirewall]# route --save
Notice that the route command on Check Point requires the use of /prefix to define the subnet mask. Once you have added all the static routes, make sure that you run the last command to make the route changes persistent.
When it comes to hardening routing protocols on a firewall, you have three primary routing protocols to take into consideration:
Routing Information Protocol (RIP)
Open Shortest Path First (OSPF)
Border Gateway Protocol (BGP)
Regardless of the protocol you have to support, you should make sure there is some sort of encryption and authentication mechanism to ensure that the routing protocol data has not been compromised. Although many of them support some sort of authentication (generally utilizing an MD5 hash and pre-shared key), the routing data itself is generally not encrypted and not capable of being encrypted (unless you encapsulate it within IPsec). As a result, although authentication will protect your firewall from receiving routes from untrusted hosts, without encryption of the routing protocol you are still vulnerable to a hacker sniffing those packets off the wire and gaining access to your routing information, even if they can t hijack your routing protocols and make any changes. Because of these insecurities, you should not use routing protocols on untrusted networks such as your DMZ or external networks, except as required (for example, using BGP to connect to multiple upstream providers). Even in those required cases, you should never allow your internal routing tables to be transmitted across those untrusted networks.
Although I do not recommend using RIP because it has historically proven to be particularly vulnerable to attack, if you must use it on your Cisco PIX firewall, you should configure it to use MD5 authentication at the CLI, as follows:
firewall(config)# rip inside passive version 2 authentication md5 ripkey 2
This configures RIP version 2 on the inside interface in passive mode with an MD5 hash key of ripkey and a key ID of 2. The firewall will only exchange RIP routing information with other routers that exchange the appropriate hash and key ID.
As previously mentioned, iptables relies on the underlying operating system to provide routing protocol information and configuration. Check Point also relies on the underlying operating system to provide for routing protocol information and configuration. Although a number of different third-party routing daemons can be installed on these systems, because both ship with a version of Zebra, I am going to focus on how to configure Zebra to harden RIP.
Zebra uses a command set based on the Cisco IOS command set for configuration. The benefit to this is that the commands required for configuring RIP to use an MD5 hash for authentication are virtually identical to those you would use on a Cisco router. First, you must specify the key chain to use. Next, you must configure the interface to use RIP authentication and specify the key chain to be used for that interface. After that, you configure the RIP routing protocol to use RIP version 2 as well as specify what networks to use RIP with. Finally, you need to make sure you permit RIP traffic in your firewall access rules; otherwise , the firewall will prevent any RIP updates from occurring. You can configure Zebra by running the command vtysh at the CLI. You should be logged in as root on Linux/Unix or you should be in the Check Point expert mode to run the command. A sample configuration is shown here:
key chain rip2 key 2 key-string ripkey !-- This assigns a key chain name of rip2 with a rip key string !-- of "ripkey" interface eth0 ip rip authentication mode md5 ip rip authentication key-chain rip2 !-- This assigns the key chain of "rip2" and specifies to use an MD5 !-- hash instead of passing the actual key string. router rip network 192.168.1.0/24 network 192.168.2.0/24 !-- This configures RIP routing on the specified network. RIP version !-- 2 is the default version, and thus is not shown in the config
Make sure you save your configuration before exiting Zebra by running the command write memory to make the configuration changes persistent. This will cause the configuration to be saved in the file /etc/Zebra.conf.
Configuring OSPF for authentication follows the same basic principles as for RIP. You will configure a pre-shared key that is used for authentication and then use MD5 to create a hash that is exchanged between the systems. This ensures that only authenticated systems can communicate with and exchange routing information with each other.
For the Cisco PIX, you have a number of commands to run to configure OSPF to use MD5 authentication. In this example, we are configuring MD5 authentication with a pre-shared key of ospfkey and a network of 192.168.1.0. You would run the following commands using CLI:
firewall(config)# router ospf 10 firewall(config-router)# network 192.168.1.0 255.255.255.0 area 0 firewall(config-router)# area 0 authentication message-digest firewall(config-router)# routing interface inside firewall(config-routing)# ospf message-digest-key 1 md5 ospfkey
For iptables and Check Point, you can enable OSPF with MD5 authentication by running the command vtysh at the CLI and configuring Zebra as follows:
interface eth0 ip ospf message-digest-key 1 md5 ospfkey !-- This configures the interface to create an MD5 hash of the !-- pre-share key for authentication router ospf network 192.168.1.0/24 area 0 network 192.168.2.0/24 area 0 area 0 authentication message-digest !-- This configures the OSPF networks and specifies the OSPF area
Border Gateway Protocol (BGP) presents a unique problem as it relates to firewalls. Some firewalls, such as the Cisco PIX, do not support running BGP and therefore aren t relevant to this discussion. For iptables and Check Point running Zebra for BGP routing services, the problem is that Zebra does not support BGP authentication, even though it does support running BGP. Consequently, regardless of what BGP configuration options Zebra does support, I recommend that you do not run BGP with Zebra. So what can you do if you have to run BGP? I recommend that you implement routers in front of the firewalls, letting the routers handle the BGP functionality, and that you harden BGP on the routers accordingly. Hardening BGP on your routers is covered in Chapter 6. Once you have your routers configured for BGP, use either static routes or RIP/OSPF to communicate between the firewalls and the routers to exchange routing information.