Security Basics mailing list archives
Re: NAT external/Public IP
From: Ansgar -59cobalt- Wiechers <bugtraq () planetcobalt net>
Date: Tue, 6 Nov 2007 21:36:38 +0100
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
Current thread:
- Re: NAT external/Public IP Ansgar -59cobalt- Wiechers (Nov 04)
- Re: NAT external/Public IP PCSC Information Services (Nov 05)
- RE: NAT external/Public IP Craig Wright (Nov 05)
- Re: NAT external/Public IP PCSC Information Services (Nov 05)
- Re: NAT external/Public IP Michael Painter (Nov 07)
- RE: NAT external/Public IP Craig Wright (Nov 05)
- RE: NAT external/Public IP Dan Lynch (Nov 05)
- Re: NAT external/Public IP Ansgar -59cobalt- Wiechers (Nov 06)
- <Possible follow-ups>
- Re: NAT external/Public IP krymson (Nov 09)
- RE: NAT external/Public IP Nick Vaernhoej (Nov 09)
- RE: NAT external/Public IP Craig Wright (Nov 09)
- Message not available
- RE: NAT external/Public IP Craig Wright (Nov 15)
- RE: NAT external/Public IP Nick Vaernhoej (Nov 09)
- Re: NAT external/Public IP PCSC Information Services (Nov 05)