Re: We hit half-million: The Cidr Report

[Robert Drake <rdrake () direcpath com>]

On 5/1/2014 7:10 PM, Jean-Francois Mezei wrote:
> Pardon my ignorance here. But in a carrier-grade NAT implementation that
> serves say 5000 users, when happens when someone from the outside tries
> to connect to port 80 of the shared routable IP ?  you still need to
> have explicit port forwarding to specific LAN side hosts (like the web
> server) right ?
>
> Trying to be devil's advocate here: (and discussing only incoming calls)
That's the problem with your devil.  The first outgoing connection 
negates every protection you've assumed with one-to-many NAT.  What you 
really need is a policy that says explicitly what traffic is permitted 
in each direction.  established/new outbound is the problem in this 
scenario, not what internal addresses you use.

On a secure server LAN, the ideal configuration for outbound would only 
allow connections to update servers you control, and acknowledgement 
traffic for protocols you are allowing inbound.

> In a NAT setup for a company, wouldn't the concept be that you
> explicitely have to open a few ports to specific hosts ? (for instance
> 80 points to the web server LAN IP address) All the rest of the
> gazillion ports are blocked by default since the router doesn't know to
> which LAN host they should go.
>
> On the other hand, for a LAN with routable IPs, by default, all ports
> are routed to all computers, and security then depends on ACLs or other
> mechanisms to implement a firewall.
>
> Auditors probably prefer architecture where everything is blocked by
> default and you open specific ports compared to one where everything is
> open by default and you then add ACLs to implement security.
Blocked by default or allowed by default are just concepts on a 
firewall.  People make the mistake of thinking that allowed by default 
is the default, but that's only true of the underlying host OS, and only 
if that host OS isn't hardened.

Specifically, ip forwarding shouldn't be turned on until needed. Linux 
doesn't turn this on by default, so by default you don't permit routing 
no matter the source or destination IP addresses.

The mistake that everyone is making is they think with NAT, secure rules 
are easier to write so getting the firewall online for the first time is 
easier, and maintaining it is easier.  The problem with this statement 
is it's only true to a certain extent.  If you care about whatever 
you're securing at a PCI/SOX level then NAT bought you nothing.  You 
still need to write secure inbound and outbound rules.

If whatever you're securing doesn't have to be that tightly controlled 
then NAT buys you a little, but it comes with a glaring false sense of 
security.  I know at my office the IT department has dealt with several 
worm outbreaks that spread through email and then use the local LAN to 
send outbound port 25.  I had to block port 25 outbound for the 
corporate network when it became apparent that IT was using "NAT is a 
firewall" as their security methodology.


> (Not judging whether one is better, just trying to figure out why
> auditors might prefer NAT).
>
> Also, home routers have "NAT" which is really a combo of NAT with basic
> firewall, so if you don't have "NAT", they may equate this to not having
> a firewall.

Auditors prefer NAT because everyone in the world understands security 
and computers on different levels.  You don't know if you're getting an 
auditor that writes their own pen-test suites or just runs nessus and 
prints the results.  They may have been trained by someone who developed 
the "intuitive" logical understanding that NAT systems fail-closed so 
they're better for defense in depth.  The problem with this is, as 
stated above, it's not buying enough to be worth it and it causes a 
false sense of security.  They may have even reached this conclusion 
themselves and it's hard to convince someone their ideas are wrong.  
Honestly they aren't even wrong, they're just picking a battle that 
shouldn't mean as much as they think it does.

Ideally, your security group should have unit-tests or just a network 
monitoring process that nmaps from both directions.   On inbound there 
are PCI compliance auditors that will do this for you regularly so that 
you can be assured the protection is still there.

Outbound you need to be just as vigilant to make sure the rules are just 
as strict.  Ultimately, things like CGNAT are completely ineffective for 
security because the outbound rules have to be wide open so people can 
use it.