A couple of weeks ago Russ White wrote a Packet Pushers article called “Obscurity, Security, Reality“. His article was published later in the same day that I had published “The Truth About Security by Obscurity“. Obscurity, Security, Reality spawned quite a few comments. Several comments were mine and reflected the view that I have that all logical controls are based on some form of obscurity. It is our responsibility to understand the degree of obfuscation and implement complementing controls.
I wanted to expand on those comments and the dialog by asking two simple questions. The first question is this, “Is a simple PAT router a firewall?” The second question builds on the first and asks, “If a PAT router is not a firewall, does it hold any security value?” I’ve heard opinions that are all over the place on this one and I wanted to offer some clarification.
In this context, I want to be absolutely clear about what I’m talking about. For this discussion we will use a Cisco IOS based Router that is configured for dynamic PAT. It also has a static translation for TCP Port 80. The diagram above shows a web server that must be accessible from the Internet and we will assume there is outbound connectivity requirements for other hosts that are not shown. There is no firewall on the customer premise or managed by a service provider.
This design is not a recommendation or an endorsement. However, if you consult in the SMB space, you have walked into a new customer and seen a Netgear, Linksys or D-link. Otherwise, you are fairly new at consulting or haven’t worked with the very small customers. While this design is not a recommendation or an endorsement, it is the context for this conversation.
So the first question I posed was, “Is the PAT router a firewall?” Is the router blocking anything? If so, what criteria is it using to block or drop packets? If a packet arrived at the external interface destined to the private address of an internal host, would it be forwarded through? Many would probably think about the static PAT translation say that if its not for TCP port 80, it’s not going through.
I disagree with that logic and therefore do not consider a PAT router a firewall. Let’s assume that the server has an IP address of 192.168.1.2 and has a telnet daemon running. If an outsider could get a TCP segment destined to 192.168.1.2 on port 23 (routing RFC1918 through the public Internet), that router will happily forward it into the server. NAT and PAT are translation mechanisms, not blocking mechanisms. When there is a “miss” in the NAT table and there is no applicable dynamic NAT or PAT configuration, the packets will be forwarded unmodified.
The reason I specifically mentioned that I wanted to give an example of a Cisco IOS based router was that I’m fairly familiar with how they operate. The various other flavors of routers may or may not behave exactly the same way. The next reason that I wouldn’t classify this device is a firewall is that it doesn’t really qualify return traffic before passing it to the inside destination.
For example if something on the inside sends something outbound, it creates a translation. That translation can sometimes be used by any device on the outside to reach back to the originating host. This initial outbound traffic could be created by normal use, social engineering a user or malware. Once created, an outside attacker could send inbound traffic to the originating host.
Unlike what we typically see in modern firewalls, the PAT device will typically not look too deep into a packet either. For PAT purposes, it really just needs to look at the IP address, transport layer protocol and ports. It does this not for validation, but for purposes of translating and untranslating the packets. Modern firewalls look deeper in the transport layer headers for things like TCP flags and sequence numbers.
Hopefully everyone agrees with me that a PAT router is not a firewall. In that case let’s move on to the second question– “If a PAT router is not a firewall, does it hold any security value?” My response to that would require looking at this in the context of whether the network above would be more secure as shown or with public IP addresses on the internal hosts.
My position is that the diagram shown above is holistically more secure than if the internal hosts, including the web server, had public IP addresses. Again, this is assuming no firewall exists. Does this mean that an outsider can’t get unintended packets to an inside host? Absolutely not. There are three ways that I know of for an attacker to get malicious traffic to an internal host.
Methods for Getting Malicious Packets Through a PAT Device
- Using IP Source Routing
- Tunnel to the Upstream ISP Router, adding a route to the Customer’s RFC1918 address space, and utilizing the Tunnel
- Coerce an Inside Host to Send Traffic
Of these methods, the first two will typically only work when bi-directional connectivity is not required. Therefore, when those are used, it is typically a blind attack and typically won’t work easily with TCP. The reason this is true is because the return traffic will be translated and break the communication. With that being said, an attacker could intercept the translated packets and adjust accordingly. However, the implementation of these as well as massaging the traffic certainly increases the barrier to entry over over simply having public IP addresses.
The third option requires some other interaction to an internal host as a prerequisite. This could be accomplished through social engineering, phishing or some sort of malware. However, this too increases the barrier to entry over a host with a fully exposed public IP address.
Due to this increased barrier to entry, I do believe that this PAT router offers some security benefit. However, I want to make sure that I don’t overstate this point. I would still not be very comfortable with this network. Security requires us to look at the big picture and understand how things are implemented. The typical implementation of PAT removes public IP addresses from hosts.
While PAT raises the bar a bit when looking at this holistically, there are still many other concerns I would have. With this little apparent thought put into network security, I’d be asking myself if things like host and application hardening had been performed. At the end of the day many, if not most, exploits happen at the layers 7 or 8 (the applications or the people). In both of those cases, traditional firewalls and most other point products fail too. That still just means that we must look at the big picture and do our part to make things more difficult for attackers.