Book Excerpt: Cisco Secure Internet Security Solutions - part 4
Cisco Secure Internet Security Solutions - Chapter 4
by Andrew Mason, Mark Newcomb
Cisco Secure PIX Firewall - Part 4The next configuration adds a DMZ and allows configuration of the PIX through something other than the console. The configuration also enables SNMP, a syslog server, and filter URLs.
Single DMZ Configuration
This configuration moves the FTP, Web, and e-mail servers to a DMZ. All traffic destined for these servers will not touch the LAN. When using a DMZ, it is critical that no connection between the LAN and the DMZ be maintained except through the PIX Firewall Connecting the LAN to the DMZ in any way except through the firewall defeats the purpose of the DMZ. Figure 4-7 shows that a third interface has been added to the PIX. This interface will be used as a DMZ.
The configuration will need a few changes from the previous one. Look through the following configuration. This section will discuss where changes have been made and the ramifications of those changes after the configuration. As before, the blank lines are for clarity.
hostname pixfirewall enable password enablepass encrypted passwd password encrypted nameif ethernet0 outside security0 nameif ethernet1 inside security100 nameif ethernet2 public security 50 interface ethernet0 auto interface ethernet1 auto interface ethernet2 auto ip address outside 192.168.1.1 255.255.255.0 ip address inside 172.30.1.2 255.255.255.252 ip address public 192.168.2.1 255.255.255.0 fixup protocol http 80 fixup protocol http 10120 fixup protocol http 10121 fixup protocol http 10122 fixup protocol http 10123 fixup protocol http 10124 fixup protocol http 10125 fixup protocol ftp 21 fixup protocol ftp 10126 fixup protocol ftp 10127 snmp-server community ourbigcompany snmp-server location Seattle snmp-server contact Mark Newcomb Andrew Mason snmp-server host inside 10.1.1.74 snmp-server enable traps logging on logging host 10.1.1.50 logging trap 7 logging facility 20 no logging console telnet 10.1.1.14 255.255.255.255 telnet 10.1.1.19 255.255.255.255 telnet 10.1.1.212 255.255.255.255 url-server (inside) host 10.1.1.51 timeout 30 url-server (inside) host 10.1.1.52 filter url http 0 0 0 0 global (outside) 1 192.168.1.50-192.168.1.253 255.255.255.0 global (outside) 1 192.168.1.254 255.255.255.0 nat (inside) 1 10.1.1.0 255.255.255.0 0 0 nat (inside) 1 10.2.1.0 255.255.255.0 0 0 nat (inside) 1 10.3.1.0 255.255.255.0 0 0 nat (public) 1 192.168.2.1 255.255.255.0 0 0 static (public, outside) 192.168.1.30 192.168.2.30 static (public, outside) 192.168.1.35 192.168.2.35 static (public, outside) 192.168.1.49 192.168.2.49 conduit permit tcp host 192.168.1.30 eq http any conduit permit tcp host 192.168.1.35 eq ftp any conduit permit tcp host 192.168.1.49 eq smtp any conduit permit tcp any eq sqlnet host 192.168.1.30 route outside 0 0 192.168.1.2 1 route inside 10.1.1.0 255.255.255.0 172.30.1.1 1 route inside 10.2.1.0 255.255.255.0 172.30.1.1 1 route inside 10.3.1.0 255.255.255.0 172.30.1.1 1 route public 192.168.2.0 255.255.255.0 192.168.2.1 arp timeout 7200 clear xlate write mem
The hostname command has been added as the first line in this configuration. This merely identifies the host when you Telnet in for configuration.
You add a new interface, name it public, and assign a security level of 50 with the following line:
nameif ethernet2 public security 50Because the security level of this interface is less than the inside and greater than the outside, some default behaviors come into play. By default, packets from the outside interface are not allowed into this network. Packets from the inside are, by default, allowed into this network.
You also changed the speeds for all of the interfaces. You are now using the keyword auto with the interface command. This allows the interface to connect in whatever form is most appropriate, based on the equipment to which it is connected. You added an IP address for the new network card and a subnet mask for the network.
Several fixup commands were entered. Some fixup commands appear in the configuration by default, others are added as needed. The fixup protocol commands allow changing, enabling, and disabling the use of a service or protocol through the PIX Firewall. The ports specified for each service are listened to by the PIX Firewall. The fixup protocol command causes the ASA to work on port numbers other than the defaults. The following fixup protocol commands are enabled by default:
fixup protocol ftp 21 fixup protocol http 80 fixup protocol smtp 25 fixup protocol h323 1720 fixup protocol rsh 514 fixup protocol sqlnet 1521You added the following lines regarding the HTTP protocol:
fixup protocol http 10120 fixup protocol http 10121 fixup protocol http 10122 fixup protocol http 10123 fixup protocol http 10124 fixup protocol http 10125These lines accomplish a very specific task. When HTTP traffic is seen by the PIX, it can now be on any of the previously listed ports. Before these lines were entered, the PIX would have seen what looked like HTTP traffic entering the PIX. Because the destination port was set to something other than the default of 80, that traffic would be denied. For example, if an outside user tried to connect to the Web server with the following URL, the user would be denied:
http://www.ourcompany.com:10121The reason for the denial is that the :10121 at the end of the URL specifies that the connection should be made on port 10121, rather than on the default port of 80. The Web developers have specific reasons for wanting to allow users to connect to these ports. The configuration allows the users to connect with these ports, and you still maintain the same safeguards regarding HTTP traffic that is true for port 80.
Similarly, the developers have specific reasons for wanting to change the defaults. The developers decided that users requiring FTP access should be able to gain access through the default port of 21 or ports 10126 and 10127. You have no idea why they want to do this, nor do you really care. What you care about is that you can open these ports to FTP traffic, and only FTP traffic, without compromising the network security. To accomplish this, you add the following lines:
fixup protocol ftp 21 fixup protocol ftp 10126 fixup protocol ftp 10127It should be noted that the fixup protocol command is global in nature. For example, when you told the PIX that port 10121 was part of the HTTP protocol, this applied to all interfaces. You cannot selectively cause port 10121 to be regarded as HTTP traffic on one interface, but not on another interface.
There might be times when it is necessary to disable one of the default fixup protocol commands. For example, if your company develops e-mail software and the PIX is used to separate the test network from the corporate network. In this case, you might want to allow more commands than HELLO, MAIL, RCPT, DATA, RSET, NOOP, and QUIT to travel through the PIX. In this case, using the no form of the fixup protocol command will disable the feature. An example of removing the Mailguard feature is as follows:
no fixup protocol smtp 25
You add SNMP to the PIX because you want to be informed when errors occur. You can browse the System and Interface groups of MIB-II. All SNMP values within the PIX Firewall are read-only (RO) and do not support browsing (SNMPget or SNMPwalk) of the Cisco syslog Management Information Base (MIB). Traps are sent to the SNMP server. In other words, SNMP can be used to monitor the PIX but not for configuring the PIX. The syntax for the commands is essentially the same as when working on a Cisco router. The following lines set the community string, the location, the contact, and the interface and IP address of the SNMP server. Because you have specified inside on the snmp-server host command, the PIX knows which interface to send SNMP traps out without the need for a specific route to this host.
snmp-server community ourbigcompany snmp-server location Seattle snmp-server contact Mark Newcomb Andrew Mason snmp-server host inside 10.1.1.74
The following logging commands allow you to use a syslog server for recording events. These commands are similar to those used on a Cisco router. The logging on command is used to specify that logging will occur. The logging host command is what actually starts the logging process on the host at 10.1.1.50. The logging trap command sets the level of logging to be recorded, which is all events with a level of 7. Finally, the no logging console command is used to prevent the log messages from appearing on the console. For this to work, the PIX must know how to find the host at 10.1.1.50. Ensure that a route to this host exists.
logging on logging host 10.1.1.50 logging trap 7 logging facility 20 no logging console
You added three lines to allow access to the PIX Firewall through Telnet in addition to the console port access. This is a major convenience and a major security risk. There are three reasons that we consider Telnet access a risk. The first is that Telnet limits access based on the IP address. It is very easy for a user to change the IP address on a computer, especially if the user is using an operating system such as Windows 95. This allows the possibility of a user gaining access where the user should not be able to gain access. The second concern regarding security is that, as hard as you may try to prevent it, you cannot always be sure that a user walking away from a desk will lock the terminal. Password-protected screensavers help minimize the issue, but they cannot completely resolve it. Because the PIX forms the corporations major defense from outside intrusion, it is critical that access is limited as much as possible. The third concern regarding Telnet access is a misunderstanding on how it should be configured. This third issue is covered in this section, after examining the commands entered.
telnet 10.1.1.14 255.255.255.255 telnet 10.1.1.19 255.255.255.255 telnet 10.1.1.212 255.255.255.255In the preceding lines, you specified a subnet mask of 32 bits for each of these IP addresses. Entering 255.255.255.255 is optional, because an IP address without a subnet mask is assumed to have a 32-bit mask associated with that address. The subnet mask used on the telnet command is the mask for those who should have access to the PIX, not the subnet mask for the network. Approximately 50 percent of the PIX Firewalls the authors of this book have examined have been incorrectly configured with the subnet mask of the LAN. In these cases, any user on the LAN can Telnet to the PIX Firewall. If one of these users is able to guess the password, the user can control the PIX. In the configuration section Dual DMZ with AAA Authentication later in this chapter, you will see how to use authentication, authorization, and accounting (AAA) services to ensure that unauthorized users cannot Telnet to the PIX Firewall.
You added URL filtering for monitoring, reporting, and restricting URL access. Cisco Systems and Websense, Inc. have formed a partnership for joint marketing and coordination of technical information on a product called Websense, which is used to control the sites that users are allowed to access. For example, web sites classified as employment or violent can be blocked. Instructions on ordering Websense are included in the documentation of every PIX Firewall.
The PIX Firewall configuration for enabling URL filtering is very simple. The following
three lines show the configuration. The first line tells the PIX to allow or block URL access
based on the information received from the Websense server on the inside interface at the
10.1.1.51 IP address. Should a response to a request not be received within the timeout
parameter of 30 seconds shown on this line, the next Websense server will be queried. The
default timeout is 5 seconds. The second line shows the failover Websense server, which is
also the Web server on the public interface. The third line defines that all HTTP requests
will be watched. Multiple filter commands can be combined to refine what is monitored.
The full syntax of the filter command will be shown after the command lines.
url-server (inside) host 10.1.1.51 timeout 30 url-server (public) host 192.168.2.30 filter url http 0 0 0 0The full syntax of the filter command is as follows:
filter [activex http url] | except local_ip local_mask foreign_ip foreign_mask [allow]The definitions of the parameters can be found in Table 4-1.
|activex||Blocks outbound ActiveX, Java applets, and other HTML object tags from outbound packets.|
|url||Filters URL data from moving through the PIX.|
|http||Filters HTTP URLs.|
|except||Creates an exception to a previously stated filter condition.|
|local_ip||The IP address before NAT (if any) is applied. Use 0 for all IP addresses.|
|local_mask||The subnet mask of the local IP. Use 0 if 0 is used for the IP address.|
|foreign_ip||The IP address of the lower security level host or network. Use 0 for all foreign IP addresses.|
|foreign_mask||The subnet mask of the foreign IP. Use 0 if the foreign IP is 0.|
|allow||When a server is unavailable, this lets outbound connections pass through the PIX without filtering.|
Additional Single-DMZ Configuration Considerations
The remaining changes to this configuration involve commands that were previously examined in this chapter. You added a new nat statement with the interface set as public to allow for translation of the public DMZ to global addresses. This eliminates the chance that anyone from the outside will see any traffic on the inside network. You can use NAT on all of the public hosts and add them to the common global pool. The command used is as follows:
nat (public) 1 192.168.2.1 255.255.255.0 0 0Next, you change the static NAT for the Web, FTP, and e-mail servers from the inside interface to the public interface. The new lines read:
static (public, outside) 192.168.1.30 192.168.2.30 static (public, outside) 192.168.1.35 192.168.2.35 static (public, outside) 192.168.1.49 192.168.2.49If you were using the previous configuration, you would have needed to remove the old static translations using the no form of the static command. You also added a new conduit statement. This statement allows any Oracle database traffic from the Web server on the public interface to enter into your inside LAN. The PIX Firewall uses port 1521 for SQL*Net. This is also the default port used by Oracle for SQL*Net, despite the fact that this value does not agree with Internet Assigned Numbers Authority (IANA) port assignments.
Because the Web server has a database running in the background, you need to allow traffic from this Web server to enter into the LAN and talk to the Oracle database servers. These tasks are accomplished with the following lines:
conduit permit tcp host 192.168.1.30 eq http any conduit permit tcp host 192.168.1.35 eq ftp any conduit permit tcp host 192.168.1.49 eq smtp any conduit permit tcp any eq sqlnet host 192.168.1.30You also added a few new route statements. You added routes for both the Seattle and Manchester networks as well as the public network. Finally, you made sure that the NAT changes would occur by issuing a clear xlate command and then writing the configuration.