List Info

Thread: Re: NAT external/Public IP




Re: NAT external/Public IP
user name
2007-11-06 14:36:38
On 2007-11-05 Dan Lynch wrote:
>> However, we're getting off the subject. I'm still
waiting for 
>> someone to explain how public addresses are any
less secure 
>> than private addresses.
>> To repeat myself: using public addresses for hosts
in your LAN does
>> *not* mean that those hosts automatically are
publicly accessible.
> 
> You ask two separate and quite distinct questions.
First, using
> private address ranges in your LAN, and providing PAT
services at the
> perimeter for egressing traffic does provide a security
benefit (I may
> be naïve of others). I also argue that the obscurity
function is a
> useful part of a holistic and multi-layered approach to
security.
> 
> -- Assuming the use of a firewall or other stateful
filter to perform
> the translation, PAT is a one-way function.
> While a firewall will allow _return_ traffic across a
PAT'ed
> connection, new connections inbound to the private
network host are
> not. For that either a static NAT plus a firewall rule
is required, or
> a rule plus the use of publicly routable internet host
addressing on
> private network hosts. (Or a really bad error in your
firewall config.
> :->  ) PAT is one layer of a multi-layered scheme to
protect private
> hosts from outside attack.

Same applies to a firewall rejecting inbound connections to
a LAN using
public IP addresses. No security bonus here.

> -- Obfuscation of internal network structure and
numbering schemes. 
> A private network using publicly routable internet host
addressing can
> be mapped from outside by a vigilant attacker by simply
logging the
> source IP addresses of packets leaving the network.

To do that the attacker would need to be able to sniff all
outbound
traffic. And even then he'd not be able to map the entire
network, but
merely those host that were sending packets while he was
sniffing. That
may allow some rudimentary mapping, but not more.

> Other details can be gleaned from header fields like
TTL or source
> port number, allowing rudimentary OS fingerprinting.

AFAIK PAT doesn't touch the packets' headers except for
source address
and source port (plus decreasing TTL and adjusting checksums
of course).
The only real advantage I can see here is that the attacker
can't easily
identify (and fingerprint) single hosts. However, since
we're assuming
he has access to the entire outbound traffic, he may still
be able to
map traffic back to single hosts and thus obtain some
information about
the operating system by analyzing the sniffed traffic later.
More
trouble for him, though.

> Information about IP address ranges can be valuable for
enumerating
> what hosts exist and of what type, and in what ranges.
PAT eliminates
> the disclosure of these details.

Agreed, some information disclosure may be prevented by
using PAT.
However, I consider that kind of disclosure a rather low
risk, because
it requires significant efforts for a (IMHO) mariginal
information gain.

Regards
Ansgar Wiechers
-- 
"All vulnerabilities deserve a public fear period prior
to patches
becoming available."
--Jason Coombs on Bugtraq

[1]

about | contact  Other archives ( Real Estate discussion Medical topics )