Given a scenario, install and configure a basic firewall. This chapter describes types of firewalls, functionality, and different features offered on such devices. We go into more detail in our CompTIA Security+ course.
Types of Firewalls and Functionality
A firewall is a security device that filters traffic that is not allowed in the organization, while allowing legitimate traffic. Firewalls are positioned at the entry point in an organization or between critical network modules to create various security access policies. Most firewalls filter at Layer 4, based on the TCP or UDP port number. Some firewalls can function even at Layer 7, being application aware and filtering traffic based on this.
Many firewalls also can be configured to create encrypted tunnels between sites so that all the information between the firewalls is encrypted. Some firewalls can also proxy traffic to increase security, receiving requests from the users and forwarding them on the Internet.
Firewalls can function in two modes:
- Routed mode: functions like a Layer 3 device, with IP addresses on each interface and running routing protocols with other devices (optional; static routing is more often configured)
- Transparent mode: functions like a Layer 2 device, passing the traffic between interfaces transparently to the end-user
Software Firewalls
Software firewalls are applications installed on users’ PCs that offer a certain level of protection at the operating system level. These applications are not really used to protect an enterprise network. Many operating systems have built-in firewall services. They can be configured to block certain types of traffic from entering or leaving the workstation, usually based on the application type. An example of this type of firewall is shown in Figure 31.1 below:
Figure 31.1 – Windows Firewall
Hardware firewalls
Hardware firewalls are appliances that are usually installed in racks and that provide the same functionalities described above. The advantage of using hardware firewalls is that they offer increased performance, but the disadvantage is the high cost of these appliances.
Virtual Firewalls
Virtual firewalls are security contexts that are used to partition a physical firewall into multiple logical devices, each with its own configuration. This is similar to having multiple standalone firewalls but without having to buy separate devices. When defining security contexts on a device, the old configuration will be saved in the appropriate file and the new virtual firewalls will each have dedicated configuration files.
Security contexts are distinct and independent firewalls in the sense of having their own attributes, such as the following:
- Security policy
- Assigned interfaces
- NAT rules
- Access control lists
- Administrators
Each virtual firewall has a system configuration that can be modified through the administrator context, which is created automatically when you convert from single-mode to multi-mode. The administrator context is basically just like any other virtual firewall, with the exception that it is used to access the system and configure it. Typically in the design, VLANs will be linked to security contexts, and most firewalls allow for multiple VLANs to be assigned to a single security context.
Some of the things that are not usually supported by common virtual firewalls include:
- IPSec VPNs
- SSL VPNs
- Dynamic routing protocols
Another important concept when it comes to virtual firewall design involves resource classes. When configuring a security appliance, all resources are available to all security contexts, by default. This can be modified in the administrator context, which will allows you to create new contexts and to assign resources to each of them. These resources can be grouped into resource classes for easy management and they can be assigned security contexts through the administrator context.
Stateful Inspection and Packet Filtering
Firewalls can function in multiple modes. A legacy operating mode is stateless firewalling, also known as packet filtering. This technique involves configuring the firewall with rules to allow specific data in and keep specific data out of the network. The data going in and out has no relationship to each other, as the firewall is only opening ports on both sides or restricting access based on IP addresses.
Modern firewalls offer stateful packet inspection, meaning they understand and keep track of all the flows that pass through the device. They only allow traffic to flow between specific devices, for example, between different clients and a server. The way this functions is by recording the state of each connection (flows and sequence numbers) and automatically allowing the responses associated with that connection back. For example, you can configure a firewall to allow traffic to port 80. In this case you don’t have to specify any return traffic rules as these are automatically created by the firewall (internally) to allow the response from the Web servers back to the clients.
Firewall Rules
Firewalls usually block all traffic by default. To permit certain types of traffic, you can create a list of rules that reflects the firewall behavior. Firewalls generally operate using rules known as tuples, which are a grouping of variables:
- Source IP
- Destination IP
- Port number
- Application
- Packet size
- Time of day
For example, if you configure a rule to allow a specific source IP to communicate with a specific destination IP, the source IP and the destination IP form a tuple.
Firewall rules take a logical path, starting at the top of the list and going down. This behavior is similar to ACL functionality (described in Chapter 28), as the firewall starts with the first rule in the list when receiving a packet and goes down until the packet is matched against a rule. The first rule that matches the packet will dictate the action that will be taken and the rest of the list will not be consulted.
Considering the different types of parameters available, you can create more general and more specific rules. The recommendation is to place the more specific rules at the beginning of the list of firewall rules and the more general rules at the end. For example, a rule that permits Web traffic from IP 1.1.1.1 to IP 2.2.2.2 should be placed before a rule that denies all Web traffic to pass through the firewall. If a more general rule is placed before the specific one, the packet will match it and the firewall logic will never get to the more specific rule. Traffic that is not matched by any rule is dropped (i.e., “implicit deny” at the end of the list).
Active/Active Failover Firewalls
The active/active failover mechanism used on firewall devices leverages the virtual context feature. The best results are obtained when the two devices configured with active/active failover have an identical platform and operating system. The two firewalls must be connected with a failover state link and this can be accomplished in one of three ways:
- Single physical link: both the failover and stateful information are transmitted on this link
- Dual physical links: the failover information is exchanged on one interface and the stateful information (maintaining the TCP connection and translation rules) on another
- Dual redundant physical links: these act as a single logical link that carries both the failover and stateful information between the firewalls
Figure 31.2 – Active/Active Failover Firewall Deployment
Although you are using two devices that are identical, you have to leverage the security contexts feature. As depicted in Figure 31.2 above, this is accomplished by defining two security contexts on each firewall, which will accomplish the following functions:
- Context 1 is the active firewall for the left device (FW 1)
- Context 3 is the standby firewall for the left device (FW 1)
- Context 2 is the standby firewall for the right device (FW 2)
- Context 4 is the active firewall for the right device (FW 2)
This scenario gives you two virtual firewalls, with the physical devices partitioned into one active and one standby context. Contexts 1 and 3 in Figure 31.2 are logically grouped across the two physical devices, just like contexts 2 and 4 are. In many situations the security contexts feature will serve only as a mechanism to create active/active failover configurations, but on high-end devices you can use this functionality both for creating active/active topologies and assigning a set of VLANs to each virtual firewall.
Zone-Based Policy Firewalls
Zone-Based Policy Firewall (ZBW) functionality was introduced as an evolution from the traditional firewall implementation, which was an interface-based model (i.e., the ip inspect command was applied on an interface in the inbound or outbound direction). The limitations imposed by the traditional firewall implementation led to the development of the ZBW, which works by following these steps:
- Create security zones
- Place an interface or multiple interfaces into each security zone
- Create unidirectional zone pairs to define relationships between zones
- Apply a modular flexible and granular policy (using class maps, policy maps, and service policies) to the zone pairs
Figure 31.3 – Zone-Based Policy Firewall Example
Analyzing Figure 31.3 above, a few security zones (Trusted, Untrusted, and DMZ) were created and interfaces were placed into each zone (Gigabit0/0 in the Trusted Zone, Gigabit0/1 in the Untrusted Zone, and Gigabit 0/2 in the DMZ). After defining the zones and assigning interfaces, you can create unidirectional zone pairs to enforce policies for traffic passing through the three defined zones:
- Trusted Zone to DMZ
- DMZ to Trusted Zone
- Trusted Zone to Untrusted Zone
- Untrusted Zone to Trusted Zone
- DMZ to Untrusted Zone
- Untrusted Zone to DMZ
After the zone pairs are defined, you can apply different policies to them, and once you have the modular policies created and the zone pair relationships defined, you just have to place other interfaces into that zone and the policy applies to it automatically. Using ZBW removes the restriction of having just one ACL per interface per direction per protocol to provide security policies.
ZBW has some major advantages because it uses a modular configuration structure (similar to modular QoS), including:
- Modularity
- Flexibility
- Granularity
Network Address Translation
NAT operations and router configuration have already been described in Chapter 8. NAT is a mechanism that allows address conservation and at the same time increases the environment’s security level due to the fact that inside devices are not directly reachable from outside the network.
NAT Functionality
There are multiple ways to configure NAT on your router, depending on your particular requirements. To configure NAT, you need to tell the router which interfaces are on the inside and outside of your NAT network. You could actually swap internal addresses for a pool of NAT addresses, or, at the very least, a single NAT address, and perform NAT between two interfaces on your router.
NAT enables hosts on private networks to access resources on the Internet or other public networks. NAT is an IETF standard that enables a LAN to use one set of IP addresses for internal traffic, typically private address space as defined in RFC 1918, and another set of addresses for external traffic, typically publicly registered IP address space.
NAT converts the packet headers for incoming and outgoing traffic and keeps track of each session. Some NAT-specific terms include the following:
- Inside interface
- Inside local address
- Inside global address
- Outside interface
- Outside local address
- Outside global address
In NAT terminology, the inside interface is the border interface of the administrative domain controlled by the organization. This does not necessarily have to be the default gateway used by hosts that reside within the internal network.
The inside local address is the IP address of a host residing on the inside network. In most cases, the inside local address is an RFC 1918 address (i.e., non-routable, such as 10.x.x.x, 192.168.x.x, or 172.16.x.x to 172.31.x.x). This address is translated to the outside global address, which is typically an IP address from a publically assigned or registered pool. It is important to remember, however, that the inside local address could also be a public address.
The inside global address is the IP address of an internal host as it appears to the outside world. Once the inside IP address has been translated, it will appear as an inside global address to the Internet public or to any other external network or host.
The outside interface is the boundary for the administrative domain that is not controlled by the organization. In other words, the outside interface is connected to the external network, which may be the Internet or any other external network, such as a partner network, for example. Any hosts residing beyond the outside interface fall outside the local organization’s administration.
The outside local address is the IP address of an outside, or external, host as it appears to inside hosts. Finally, the outside global address is an address that is legal and can be used on the Internet. Both outside local addresses and outside global addresses are typically allocated from a globally routable address or network space.
To clarify these concepts further, Figure 31.4 below shows the use of the addresses in a session between two hosts; NAT is enabled on the intermediate gateway:
Figure 31.4 – NAT Inside and Outside Addresses
NAT Configuration
We will exemplify NAT configuration on a Cisco device. The following steps should be performed:
- Designate one or more interfaces as the internal (inside) interface(s) using the ip nat inside interface configuration command.
- Designate an interface(s) as the external (outside) interface using the ip nat outside interface configuration command.
- Configure an ACL that will match all traffic for translation. This can be a standard or an extended named or numbered ACL.
- Optionally, configure a pool of global addresses using the ip nat pool <name> <start-ip> <end-ip> [netmask <mask> | prefix-length <length>] global configuration command. This defines a pool of inside global addresses to which inside local addresses will be translated.
- Configure NAT globally using the ip nat inside source list <ACL> [interface|pool] <name> [overload] global configuration command.
The following output shows you how to configure basic NAT with Cisco IOS software. You can see that the configuration has used the description and remark keywords to help administrators more easily manage and troubleshoot their networks:
| Router(config)#interface FastEthernet0/0
Router(config-if)#description ‘Connected To The Internal LAN' Router(config-if)#ip address 10.5.5.1 255.255.255.248 Router(config-if)#ip nat inside Router(config-if)#exit Router(config)#interface Serial0/0 Router(config-if)#description ‘Connected To The ISP' Router(config-if)#ip address 150.1.1.1 255.255.255.248 Router(config-if)#ip nat outside Router(config-if)#exit Router(config)#access-list 100 remark ‘Translate Internal Addresses Only' Router(config)#access-list 100 permit ip 10.5.5.0 0.0.0.7 any Router(config)#ip nat pool INSIDE-POOL 150.1.1.3 150.1.1.6 prefix-length 24 Router(config)#ip nat inside source list 100 pool INSIDE-POOL |
Following this configuration, the show ip nat translations command can be used to verify that translations are actually taking place on the router, as illustrated below:
| Router#show ip nat translations
Pro Inside global Inside local Outside local Outside global icmp 150.1.1.4:4 10.5.5.1:4 200.1.1.1:4 200.1.1.1:4 icmp 150.1.1.3:1 10.5.5.2:1 200.1.1.1:1 200.1.1.1:1 tcp 150.1.1.5:159 10.5.5.3:159 200.1.1.1:23 200.1.1.1:23 |
There are actually three choices when it comes to configuring NAT on a router:
- Swap one internal address for one external address (Static NAT)
- Swap many internal addresses for two or more external addresses (Dynamic NAT)
- Swap many internal addresses for many external ports (Port Address Translation/Overloading)
Static NAT
This technique allows you to swap one specific address for another address when you have a Web server, for example, on the inside of your network. If you are using dynamic addressing, then there is no way routing will work because the inbound packet has no routing table entry.
We will consider an example for the IP pair listed below:
| Inside Addresses | Outside NAT Addresses |
| 192.168.1.1 | 200.1.1.1 |
| 192.168.2.1 | 200.1.1.2 |
The static NAT configuration would be as follows:
| Router(config)#interface f0/0
Router(config-if)#ip address 192.168.1.1 255.255.255.0 Router(config-if)#ip nat inside Router(config)#interface f0/1 Router(config-if)#ip address 192.168.2.1 255.255.255.0 Router(config-if)#ip nat inside Router(config)#interface s0/0 Router(config-if)#ip nat outside Router(config-if)#exit Router(config)#ip nat inside source static 192.168.1.1 200.1.1.1 Router(config)#ip nat inside source static 192.168.2.1 200.1.1.2 |
The ip nat inside and ip nat outside commands tell the router which are the inside NAT interfaces and which are the outside NAT interfaces. The ip nat inside source command defines the static translations, of which you could have as many as you wish as long as you paid for the public IP addresses.
Dynamic NAT or NAT Pool
You will often need to use a group, or pool, of routable addresses. One-to-one NAT mapping has its limitations, of course, expense and extensive lines of configuration on the router to name two. Dynamic NAT allows you to configure one or more groups of addresses to be used by internal hosts.
If you issued a show ip nat translations command on the router when the inside hosts have made outside connections, you would see a chart containing something like this:
| Inside Addresses | Outside NAT Addresses |
| 192.168.1.3 | 200.1.1.11 |
| 192.168.1.2 | 200.1.1.14 |
In the output below, you have internal addresses using a pool of addresses from 200.1.1.1 to 16. The configuration to achieve dynamic NAT is as follows:
| Router(config)#interface f0/0
Router(config-if)#ip nat inside Router(config)#interface s0/1 Router(config-if)#ip nat outside Router(config)#ip nat pool poolname 200.1.1.1 200.1.1.16 netmask 255.255.255.0 Router(config)#ip nat inside source list 1 pool poolname Router(config)#access-list 1 permit 192.168.1.0 0.0.0.255 |
The ACL is used to tell the router which addresses it can and cannot translate. The subnet mask is actually reversed and is called a wildcard mask, which was covered in Chapter 28. All NAT pools need a name, and in this example it is simply called “poolname.” The source list refers to the ACL.
NAT Overload/Port Address Translation
IP addresses are in short supply, and if you have hundreds or thousands of addresses that need to be routed, it could cost you a lot of money. In this instance, you can use NAT overload, also referred to as Port Address Translation (PAT). PAT cleverly allows a port number to be added to the IP address as a way of uniquely identifying it from another translation using the same IP address. There are over 65,000 ports available per IP address.
The show ip nat translations table this time would show the IP addresses and port numbers:
| Inside Addresses | Outside NAT Addresses (with Port Numbers) |
| 192.168.1.1 | 200.1.1.1:30922 |
| 192.168.2.1 | 200.1.1.2:30975 |
To configure PAT, you would carry out the exact same configuration as for dynamic NAT (or use the outside interface), but you would add the keyword [overload] to the end of the pool:
| Router(config)#interface f0/0
Router(config-if)#ip nat inside Router(config)#interface s0/1 Router(config-if)#ip nat outside Router(config)#ip nat pool poolname 200.1.1.1 200.1.1.1 netmask 255.255.255.0 Router(config)#ip nat inside source list 1 pool poolname overload Router(config)#access-list 1 permit 192.168.1.0 0.0.0.255 |
NAT Design Considerations
NAT and PAT are usually performed on firewalls or security appliances, which have some powerful tools to accomplish these tasks:
- Static NAT
- Dynamic NAT
- Identity NAT
- Policy NAT
A recommended best practice is to try to avoid using NAT on internal networks, except for situations in which NAT is required as a stop-gap measure during some mergers or migrations. NAT should not be performed between the Access Layer and the Distribution Layer or between the Distribution Layer and the Core Layer, as this will prevent address translation between OSPF areas, for example.
Organizations in merger processes usually use the same internal network addressing schemes and this can be managed with NAT overlapping techniques (also referred to as bidirectional NAT) that can be used to help translate between the two organizations when they have an overlapping internal IP addressing space that uses RFC 1918 addressing.
If you have internal servers or servers in the DMZ that are reached using translated addresses, it is a good practice to isolate these servers into their own address space and VLAN, possibly using private VLANs. NAT is often used to support content load balancing servers, which usually have to be isolated using source-NAT or destination-NAT.
NAT can also be used in the data center to support a management VLAN that is out-of-band from production traffic. NAT should also be implemented on devices that cannot route or cannot define a gateway for the management VLAN. This allows for smaller management VLANs, rather than a single large management VLAN that covers the entire data center.
In addition, large companies or Internet entities can exchange their summary routes and then they can translate with NAT blocks in the network. This will offer faster convergence but the downside is an increased troubleshooting process because of using NAT/PAT.
PAT is harder to troubleshoot because one or a few IP addresses are used to represent hundreds or maybe thousands of internal hosts, all using TCP and UDP ports to create logical sockets. This increases the complexity of the troubleshooting process because it is difficult to know which IP address is assigned to a particular host, as each host uses a shared IP address and a port number.
If the organization is connected to several different partners or vendors, each partner can be represented by a different NAT block, which can be translated to the organization.
DMZ
One of the most interesting and often misunderstood concepts in the Enterprise Edge module is the DMZ (Demilitarized Zone). In order to briefly explain this concept, we will provide an example, which is illustrated in Figure 31.5 below:
Figure 31.5 – DMZ Example
Suppose a company has a router that also acts as a firewall and connects to the Internet (outside) through the Serial0/0 interface. The Internet is an untrusted, public network because there is no control over it and it might be a place from which attacks to the network are generated. The router has another interface, FastEthernet0/0, that connects to the company’s inside network. The inside network is made up of workstations, servers, and other devices that are considered trusted because the company owns them and has full control over them.
| Note: An interesting thing is that, according to statistics, from a security perspective, the majority of attacks come from inside the network and they are initiated by angry employees, curious employees, or users that are not very technically trained and initiate attacks by mistake. Despite this consideration, for security design purposes, consider the inside network a trusted network. |
In addition to devices located on the Internet and on the inside network, you might have other resources, such as:
- The company Web server
- The company e-mail server
- An FTP server you want users to access from outside to make downloads
All of these devices and services can be organized on a separate interface (Serial0/1 in this example) that connects to a separate area called the DMZ. Notice that the DMZ is not on the inside of the network and the reason for this is because people from the outside are allowed to access resources in this area. From a security standpoint, the DMZ is in the middle of the inside and the outside area, as it is part of the company but it does not offer the security provided to the inside devices. The DMZ devices can be accessed by either inside users or outside users, but the outside users still cannot connect to the inside network, which enforces the security policies regarding critical and confidential resources.
Summary
A firewall is a security device that filters traffic that is not allowed in the organization, while allowing legitimate traffic. Firewalls are positioned at the entry point in an organization or between critical network modules to create various security access policies. Most firewalls filter at Layer 4, based on the TCP or UDP port number. Some firewalls can function even at Layer 7, being application aware and filtering traffic based on this.
Modern firewalls offer stateful packet inspection, meaning they understand and keep track of all the flows that pass through the device. It only allows traffic to flow between specific devices, for example, between different clients and a server. The way this functions is by recording the state of each connection (flows and sequence numbers) and automatically allowing the responses associated with that connection back.
Firewalls usually block all traffic, by default. To permit certain types of traffic, you can create a list of rules that reflects firewall behavior. Firewalls generally operate using rules known as tuples, which are a grouping of variables:
- Source IP
- Destination IP
- Port number
- Application
- Packet size
- Time of day
Network Address Translation is a mechanism that allows address conservation and at the same time increases the environment’s security level, as inside devices are not directly reachable from outside the network.
There are multiple ways to configure NAT on a router, depending on your particular requirements. To configure NAT, you need to tell the router which interfaces are on the inside and outside of the NAT network. This is because you could actually swap internal addresses for a pool of NAT addresses, or, at the very least, a single NAT address, and perform NAT between two interfaces on the router.
NAT enables hosts on private networks to access resources on the Internet or other public networks. NAT is an IETF standard that enables a LAN to use one set of IP addresses for internal traffic, typically private address space as defined in RFC 1918, and another set of addresses for external traffic, typically publicly registered IP address space.
You configure firewalls in our book 101 Labs – CompTIA Network+.
Read the Cisco firewalls page.
