Network Address Translation
Your firewall’s number one job is to separate your private network from the Internet, and use that separation to keep the bad guys out. One firewall technology that helps to create this separation (and helps with the shortage of IP addresses) in Network Address Translation (NAT).
The main idea behind NAT is that most of the computers on your network should not be accessible from the Internet. One way to keep those computers from being Internet accessible is to assign them invalid IP addresses.
In a typical NAT deployment, the only valid IP address is assigned to the firewall, all of the machines protected by the firewall are assigned IP addresses that are valid only on the private network. When a PC on the private network needs to communicate with the outside world, the computer sends its request to the firewall. The firewall then places the request on behalf of the computer that actually made the request. When the response to the request comes back, the request arrives at the firewall, and then the firewall sends the response to the appropriate computer on the private network
For example, suppose that a user wanted to visit a Web site from a PC on the private network. The user would enter the site’s URL into their Web browser, and that would in turn get translated into an HTTP request. The request would go to the firewall, and then the firewall would use it’s own IP address to place the HTTP request on behalf of the user. When the request is answered, the response goes to the firewall, and the firewall passes the response back to the user who originally made the request.
Port filtering is the task that most people seem to think of when they think of firewalls. As you probably know, TCP/IP communications occur over ports. There are 65,535 separate TCP and another 65,535 UDP ports that can be used for communications.
The easiest way to understand the concept of a port is to think of it like a radio station. Think of TCP as FM radio and UDP as AM radio. In this illustration, a port would be the TCP/IP equivalent to a radio station.
Just as radio stations have a designated purpose, so do some TCP and UDP ports. One of the main reasons why we have firewalls and port filtering is because people can use ports for purposes that they are not intended. For example, in my corner of the world, 99.7 FM is my favorite classic heavy metal station. However, just because the station plays classic metal, they can technically play anything they want. There is nothing stopping a DJ from forgoing Judas Priest in favor of Brittney Spears. Ports work the same way. TCP port 21 is traditionally used for FTP. However, there is nothing stopping someone from trying to establish a Telnet session over the port, even though Telnet isn’t the port’s designated use.
A common hacking technique is to do a port scan against an IP address. A port scan is a technique that provides the hacker with a list of the ports that are open. Once the hacker has such a list, they will sometimes try to use protocols (such as Telnet) over ports that are normally used for other purposes as a way of gaining entry into the system.
This is where port filtering comes into play. Port filtering ensures that nothing can pass through an open port except for the protocol that the Administrator has chosen to allow. For example, if port filtering were applied to TCP port 21, then FTP communications would be allowed, but no other types of communications would be allowed over that port.
Port filtering can also deny access to a packet originating from an IP address that the administrator has chosen to block. Port filtering works by examining the packet’s header and looking at things such as the source address, destination address, port number, etc. The problem with port filtering is that a packet’s header can be spoofed. A sender can fake their IP address or just about anything else stored in the header.
To get around this problem, there is another type of filtering that some firewalls do called stateful packet inspections (also called dynamic packet filtering). I don’t want to get into all of the gory detail because stateful packet inspection is an advanced topic and I still have a lot of other things to talk about, but you should at least know that stateful packet inspections exist. They work by looking at the packet’s contents rather than the header. By examining what’s actually in the packet, the firewall is better able to tell whether or not the packet should be allowed to pass to the private network.
Another feature offered by most firewalls is a demilitarized zone (DMZ). While the name demilitarized zone might sound like some pretty serious stuff, a DMZ is actually nothing more than an area that is not under the firewall’s jurisdiction. Different firewalls implement DMZs in different ways. Some firewalls simply require you to enter the IP address of the machines that you want to place into the DMZ, other firewalls have a dedicated network port that you can use for any network devices that you want to place in the DMZ.
I personally recommend avoiding the use of DMZs if at all possible. The reason is because machines in the DMZ receive absolutely no protection from the firewall. The machine’s only defenses are the security features built into the operating system and whatever hardening you might have done on your own.
If you do have a compelling reason for using a DMZ, it’s very important that you plan your use of the DMZ carefully. If a machine placed within the DMZ has a connection to your private network, then it may be possible for a hacker to exploit that machine and use it as a way of going around your firewall to get into your network. As a general rule, machines within a DMZ shouldn’t have any network connections to anything other than the firewall’s DMZ port.
I already talked about how port filtering can be used to block the use of a protocol except to a specific IP address. The concept of port forwarding builds on this concept and is particularly useful in organizations that rely on NAT.
The basic idea behind port forwarding is simple. Imagine for a moment that your organization had a publicly accessible Web server that used the IP address 192.168.0.12 (this isn’t a valid public address, but let’s pretend that it is). If this were the only publicly accessible Web server within your organization, you would probably have created a packet filtering rule on your firewall that would block HTTP requests over port 80 to any address on your network except for 192.168.0.12. If someone sent an HTTP request to any other address, their browser would just display a message saying that the Web site can’t be found.
For that particular example, we pretended that the address 192.168.0.12 was publicly accessible. In reality though, this address is perfectly valid over a private network, but isn’t accessible from the Internet. Ideally, you would probably want to replace your Web server’s private address with a public address. This isn’t always an option though. Some ISPs will only issue a single public IP address, and if you only have one public IP address, then you almost don’t have a choice but to assign that address to your firewall.
Hopefully, you can see that this is a classic example of where NAT would be used. Since the company only has one valid IP address, it is assigned to the firewall, and the firewall uses NAT to facilitate communications between the machines on the private network and the Internet. There is a problem though. NAT is specifically designed to block all inbound communications except for those that arrive in response to a request that’s sent out by one of the machines on the private network, and we still have a Web server that we need to make publicly accessible.
This is where port forwarding comes into play. Port forwarding is basically a rule that tells the firewall that if a specific type of request comes in on a certain port, then the request should be forwarded to a designated machine on the private network. In this particular situation, we are trying to make a Web server publicly accessible. To accomplish this, you would create a port forwarding rule that redirects any HTTP request on TCP port 80 to 192.168.0.12. Once such a rule is in place, a person who wants to access your company’s Web site would open their Web browser and enter http://yourdomain.com. Upon doing so, their Web browser performs a DNS query to determine which IP address is associated with your domain name. The IP address referenced by the DNS server would have to be your company’s one valid IP address (the address that’s assigned to your firewall). The Web browser would then send the HTTP request to your public IP address, unaware that it is actually making the request of a firewall. The firewall receives the inbound request and then forwards it to your Web server.
In this article, I have attempted to explain the basics of how a firewall works. As I did, I have discussed several different features that are often built into firewalls.