We hit half-million: The Cidr Report
rdrake at direcpath.com
Thu May 1 23:46:05 UTC 2014
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
More information about the NANOG