Tuesday, 4 October 2011

NAT is secure, think again

Again and again I here how NAT is secure. Just the other day, in response to a post I made, it was argued that:
NATs are quite simple: an external point of access forwards data to an internal computer. This forwarding is governed by existing connections, rules set up based on protocol information or forwarded to a default host that takes care of manipulating and forwarding data to an inaccessible internal computer.

Again, to paraphrase Clausewitz, everything in security is very simple. But the simplest thing is difficult.
I have written on this topic in the past. What seems to be missed is that it is actually simple to setup connections through a NAT based device. This is known as shovelling a shell. Basically, NAT (or network address translation) is not a security mechanism, we just use it as such.

Right now, NAT provides some benefits from scanning worms and randomised attacks. The thing is, this is not how systems are being compromised any more. NAT does not stop Browser based attacks, malware, PDF exploits, flash based rebinding attacks… I could go on.

Home systems are one thing, NAT is still not going to do a great deal in the long run, but it is better than nothing. Just

However, SCADA systems are not adequately secured using NAT.

These are critical systems that are targeted and at high risk, at times the destruction of such a system can result in kinetic effects. You do not require a Stuxnet worm to break a system, only for fine control. Many groups simply desire anarchy and chaos and this the destruction of a system will suffice.
We cannot continue to call systems firewalled simply as they have a NAT device between them and the Internet.

What can we do?
For a start, limit outgoing access. Add extrusion filters and stop open access. You do not NEED the entire Internet.

Basically, you should do the following at a minimum (this is not a home user solution other than for the technically insane such as myself):

  • Limit all access to only selected ports.
  • Use DNS forwarders. Split-Split DNS is recommended for many reason. One is that it also stops many forms of exfiltration of data over these ports (though even then still not all).
  • Use a Web Proxy. This can be a simple forwarder with nothing but logging, but the addition of a simple forwarder will stop some exfiltration over the web (although SSL remains an issue for this).
  • Block all outgoing SMTP email sessions (other than to allowed servers). Why make it easy for the spammers?
  • Force client hosts to connect to servers and add control points.
Use a risk based approach to security. If you run a system that can result in high value losses or worse, the loss of life, then we need to ensure that we do more than simple NAT filtering.

IPv6 is a game changer
Soon (and some places have already moved to IPv6), we are going to no longer even have the rudimentary obscurity that NAT provided. IPv6 does not work with firewalls well as much as well try and fool ourselves into the misguided belief that it does and that we can maintain the crunchy shell approach we have loved to rely on for the past could decades.

Tunnelling at times already means that many organisations are connected to the IPv6 Internet through protocols such as Teredo without even knowing it. NAT does not actually do anything to stop this and many hosts are simply connected to the IPv6 internet already. The fortune is that we cannot expect to scan hosts randomly in the IPv6 world and again the protection is obscurity and not a real control.
If you run Windows 7 and you allow outgoing UDP, you are likely already connected to the IPv6 internet without any firewalling. This includes hosts hiding behind NAT. Tunnels remove NAT based controls.

The thing is, with IPv6, everything starts to be a part of the cloud!
Using routed IP addresses, tunnels and mobile IP means that we are all located internal, external and everywhere all of the time. The cloud is not something out there, it will be something INSIDE your network soon (if it is not already with tunnels).

Disease models…
There is a reason we call malicious code after disease terms, worms, virii, etc. They mirror many of the effects.

What we need to start to do when thinking about both cloud and IPv6 models is the creation of isolation and quarantine points.  Peer systems should not have to talk to peer systems and can be controlled at organisational choke points. In the coming weeks I will be providing a session to government. This will be recorded and in time made available freely online. I will post as this occurs.

In a disease control scenario, we set quarantine breakpoints and controls. We do not allow all systems to talk to all systems. With multicast groups and the Security Association Database in IPSec, we can actually do this in a manner that makes each system its own firewalled domain. Right now, this seems difficult to most people, but it does not need to be. So, keep reading and I will start to add processes in the coming weeks on how to achieve this within an organisation.

I will be talking more of this approach in the coming weeks.

About the Author:
Craig Wright is the VP of GICSR in Australia. He holds both the GSE, GSE-Malware and GSE-Compliance certifications from GIAC. He is a perpetual student with numerous post graduate degrees including an LLM specializing in international commercial law and ecommerce law, A Masters Degree in mathematical statistics from Newcastle as well as working on his 4th IT focused Masters degree (Masters in System Development) from Charles Sturt University where he lectures subjects in a Masters degree in digital forensics. He is writing his second doctorate, a PhD on the quantification of information system risk at CSU.

No comments: