This chapter is from the book
This chapter is from the book
This chapter is from the book
Case Studies
This chapter presented several interesting aspects of how firewalls operate and how they can be deployed in networks. The introduction of this information needs to be reinforced with some real-world case studies that provide some answers to questions you might still have and clarify the important aspects of what has already been covered.
Case Study: To DMZ or Not to DMZ?
Carpathian Corporation has grown and is in need of increased security and additional capacity in the form of a new firewall; this time it wants to use a dedicated DMZ. If the Carpathian Corporation wants to continue with its proposed plan for self-hosting, it needs to consider the security-related issues relevant to the suggested DMZ solution. It is taking the right steps by asking what security ramifications should be addressed prior to making the purchase. The Carpathian IT staff needs to take a good look at the risk factors involved with providing for its own Internet services (web servers) and where the pitfalls might occur:
Question/Security Issue #1: Can Internet traffic travel to servers on the private network, or is there another solution?
Answer: The web and mail servers will be attached to the DMZ segment. They will not be dual homed or have conflicts of security in its implementation because they will be physically separated from inside hosts.
Question/Security Issue #2: How can the IT staff ensure that inbound network traffic will stay confined to the segment containing the web and mail servers?
Answer: The DMZ interface rule set will not allow external traffic to reach the private network, by nature of configured connectivity rules. This will keep the inbound Internet traffic confined to the DMZ segment only.
- Question/Security Issue #3: What measures can be taken to hide the private network from the inbound network traffic?
Answer: The DMZ interface will not have routes or dual-homed NIC cards that would normally enable this to occur.
The Carpathian IT staff is in the “If we self-host, we must use a DMZ” frame of mind. This frame of mind is correct, and that should be obvious at this point: Use a firewall with a DMZ interface—always!! A DMZ is another layer of security and defense for your network, as shown in Figure 7-4.
Figure 7-4 Firewall Deployment with Web Server in a DMZ
Cisco lists a variety of configuration settings when viewing their devices’ configuration files. Example 7-2 shows several configuration files for clarity purposes. To illustrate the case study, comments are made surrounding key configuration entries; however, not every command is discussed because that is beyond the scope of this book. You can find additional information at Cisco.com.
Example 7-2 Firewall with Self-Hosted Internal Web Server (No DMZ)
Cyberwall(config)# sh run : Saved ASA Version 8.5 ! hostname CyberWall domain-name CarpathianCorp.com enable password <ChangeMe> encrypted passwd <ChangeMe> encrypted names ! ! interface Vlan1 description SECURE INSIDE LAN [do not change]nameif INSIDEsecurity-level 100ip address 192.168.0.1 255.255.255.0 ! interface Vlan2 description OUTSIDE UPLINK TO SERVICE PROVIDER [do not change]nameif OUTSIDEsecurity-level 0ip address 209.164.3.2 255.255.255.0 ! interface Vlan3 description DMZ INTERFACE FOR INTERNET FACING SERVERS [alter with care]nameif DMZsecurity-level 50ip address 10.10.10.1 255.255.255.0 !!--- These commands name and set the security level for each vlan or interface, the ASA 5505 uses vlans to assign inside and outside whereas all other models have physical interfaces. Through these commands, the firewall knows which interface is considered untrusted (outside), trusted (inside) and DMZ. Notice the numeric values in this configuration example. Here we have the least secure interface outside assigned a security value of 0, as it should be. The inside interface is considered secure, so it has a value of 100, with the DMZ being somewhere in between at 50.! interface Ethernet0/0 description OUTSIDE INTERFACE [do not change] switchport access vlan 2 ! interface Ethernet0/1 description INTERFACE FOR THE DMZ WEB SERVER [do not change] switchport access vlan 3 ! interface Ethernet0/2 description RESERVED FOR INTERNAL HOST [alter with care] ! interface Ethernet0/3 description RESERVED FOR INTERNAL HOST [alter with care] ! interface Ethernet0/4 description RESERVED FOR INTERNAL HOST [alter with care] ! interface Ethernet0/5 description RESERVED FOR INTERNAL HOST [alter with care] ! interface Ethernet0/6 description RESERVED FOR INTERNAL HOST [alter with care] ! interface Ethernet0/7 description RESERVED FOR INTERNAL HOST [alter with care] !!--- An access list is created called "OUTSIDE" allowing WWW (http) traffic from anywhere on the Internet to the host at 10.10.10.212 (the web servers REAL IP address on the DMZ). Add additional lines to this access list as required if there is a email or DNS Server. This is the first step in creating a rule set that permits traffic into our network if it is destined for a specific IP Address.! access-list OUTSIDE extended permit tcp any host 10.10.10.212 eq www ! ! --- For purposes of this example we are not going to add anything else. Any additional entries needing to be placed in the access list must be specified here. If the server in question is not WWW, replace the occurrences of WWW with SMTP, DNS, POP3, or whatever else might be required, like the ability to ping the server from the Internet. ! logging enable logging timestamp ! <<<output omitted for brevity>>> !! --- The following NAT commands specify that any traffic originating inside from the ASA on the 192.168.0.0 /24 network will be NAT'd (via PAT because of the dynamic interface command) to the ASAs public IP address that is assigned to the OUTSIDE interface.! ! --- The ASA NAT rules changed completely the new way is to define the subnets you wish to NAT using object groups, the next four lines we have defined them as needed for the INSIDE corporate as well as the DMZ. ! object network OBJ_NAT_CORP description inside "corporate" subnet that must have internet access subnet 192.168.0.0 255.255.255.0 ! object network OBJ_NAT_DMZ description DMZ subnet that must have internet access subnet 10.10.10.0 255.255.255.0 ! ! --- Once the subnets are defined in an object group we assign the type of NAT we wish to perform as well as the direction. In the following examples we are permitting the INSIDE and DMZ subnets to access the Internet using PAT via the ASAs outside interface IP Address for both. This is shown in the command NAT (source interface, destination interface) dynamic interface. The dynamic keyword means PAT to the ASA. One of my favorite ways to check if this is working after configuring it open a web browser and go to www.ipchicken.com this website will tell you the public IP Address you are coming which should be the ASAs outside IP Address. Yes I know it's a goofy name but that's what makes it easy to remember plus it makes people smile when you tell them it. ! object network OBJ_NAT_CORP nat (INSIDE,OUTSIDE) dynamic interface ! object network OBJ_NAT_DMZ nat (DMZ,OUTSIDE) dynamic interface ! ! --- The last remaining NAT we must perform is for the Internet accessible Web server that is on our DMZ. Once again we create an object group but this time we specify a single host, which is the real IP address of the web server. ! object network OBJ_NAT_WEBSERVER description real ip address assigned on the web servers nic card host 10.10.10.212 ! ! --- Now that the object group is created identifying the servers real IP Address we assign a NAT in the same format as we previously did with the difference being after the direction (inside,outside) we define this as a STATIC NAT and give the public IP Address to use. In practice what will happen is as packets reach the ASA if they pass the access-list the ASA will check what their destination IP Address is. Should the destination address be 209.164.3.5 (web server public IP Address) the ASA will NAT those packets to the real IP Address of the server of 10.10.10.212 and forward them to the server on the DMZ. ! object network OBJ_NAT_WEBSERVER nat (INSIDE,OUTSIDE) static 209.164.3.5 ! ! access-group OUTSIDE in interface outside !! --- There is only one access list allowed per interface per direction (for example, inbound from the Internet on the outside interface) as we have shown here.! route outside 0.0.0.0 0.0.0.0 209.164.3.1 !!--- Set the default route to be via the WAN routers Ethernet interface! <<<output omitted for brevity>>> ! dhcpd dns 192.168.0.10 192.168.0.11 dhcpd domain mydomain.com dhcpd address 192.168.0.2-192.168.0.125 inside dhcpd enable inside ! <<<output omitted for brevity>>> ! ! --- The last major functionality of an ASA show in its configuration is that of the "inspects". Generally an inspect statement in the following section represents a protocol that the ASA will be taking extra steps on the packets the statement represents. For example many attacks are based on altering DNS replies so the ASA has been configured to inspect DNS packets to help protect your network. Two inspects that might be of importance to you are "inspect esmtp" and "inspect sip", depending on your email server configuration and version the presence of esmtp may cause user issues with emails, try removing it if this occurs. Regarding SIP when NATing a SIP connection to an internal voice gateway you will want this statement as it provides functionality that enables NAT to be done correctly and SIP to work, gotcha is it depends on the provider. Inspects are very helpful and can be adjusted to offer very granular security, please see www.cisco.com for more information. ! policy-map type inspect dns preset_dns_map parameters message-length maximum client auto message-length maximum 512 ! policy-map global_policy class inspection_default inspect dns preset_dns_map inspect ftp inspect h323 h225 inspect h323 ras inspect rsh inspect rtsp inspect esmtp inspect sqlnet inspect skinny inspect sunrpc inspect xdmcp inspect sip inspect netbios inspect tftp inspect icmp inspect icmp error inspect ip-options ! service-policy global_policy global prompt hostname context Cryptochecksum:88251e3c18c7d99dfa33f70b90228b63 : end Cyberwall(config)#