Security by accident, or security by design?

Filed Under: Apple, Malware, Mobile

Close-up of cables

I can't imagine blaming anyone other than the author for last week's iPhone virus outbreak. The virus wasn't an accident -- the self-confessed creator wrote and disseminated the virus quite deliberately.

However, the virus only infects apostate iPhones whose owners have removed Apple's restrictive software cocoon -- so-called jailbroken devices. Additionally, the virus only infects iPhones which have not been properly secured after liberation. So there are many who blame the virus on the the jailbreakers, claiming they brought the problem on themselves.

And a few observers have even blamed the virus author's mobile phone operator, claiming that the company should have been using Network Address Translation (NAT) on its 3G network as a security measure which would have prevented the virus.

This is a curious argument, and it begs two questions: what is NAT, and what security purpose, if any, is is supposed to serve?

You can read about traditional NAT, which was first codified as RFC1631 in 1994, in RFC3022, published in 2001. NAT's primary objective was to make 32-bit IP numbers go further, in order to buy us time to update to IPv6. (Given that IPv6 adoption is still very limited, 15 years later, NAT has obviously achieved this goal.)

The basic idea is simple: take a single, public IP number issued by your ISP, and assign this number to a router at your network edge. Give all the PCs inside your network a range of non-unique, private IP numbers, and let the router translate all outbound packets so they appear to come from the network address of the router itself. Similarly, let the router translate and redirect all reply packets to the network address of the originating PC. And there you have it: Network Address Translation.

One side-effect of this behaviour is that inbound connection requests must be aimed at the router, since it has your network's only public-facing IP number. Until you instruct the router which inbound requests should be forwarded to which internal servers, inbound connections can't be accepted -- the router simply doesn't know where to send them.

So, as RFC3022 points out, "traditional NAT can be viewed as providing a privacy mechanism, as sessions are uni-directional from private hosts and the actual addresses of the private hosts are not visible to external hosts." In other words, by default, NAT limits the extent to which your network structure is visible to outsiders, and prevents outsiders from connecting into your network.

However, it is a large -- and, in my opinion, unwarranted -- leap of faith to consider NAT to be a security measure. Indeed, the original RFC authors seem to agree, warning that "unfortunately, NAT reduces the number of options for providing security." In particular, NAT makes it much more difficult to track troublesome behaviour back to source -- including security violations -- since the IP address of any offending host is masked by the NATting router.

In short, NAT is a necessary evil in contemporary networking, since we don't have enough IPv4 addresses for every device on the internet. Used responsibly, NAT can increase your resilience to external attack, because of its systematic resistance to unwanted inbound connections. But it is a snake-oil substitute for a proper network security regimen. It was designed to help the internet stretch further, not to make it more secure.

In particular, the PCs inside a NATted network enjoy no protection from each other because of NAT. Even if NAT helps to stop a virus like Conficker from sneaking into your LAN through your router, it won't stop the virus from wandering around inside your LAN if it gets in via other means. Indeed, when Conficker was widespread earlier this year, most organisational outbreaks I dealt with seem to have entered quietly on infected USB keys, and then spread liberally across the intranet -- whether the network was NATted or not.

Remember: security doesn't happen by accident.

(Nor do viruses, so don't try to shift the blame away from the people who create them in the first place.)

Image source: NJV's Flickr photostream (Creative Commons)

, , , , ,

You might like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog