Home page logo

basics logo Security Basics mailing list archives

RE: NAT external/Public IP
From: "Craig Wright" <Craig.Wright () bdo com au>
Date: Tue, 6 Nov 2007 05:37:03 +1100

It is stated that, "the main contention is that private addresses are 
generally not considered routable on the public internet. I wouldn't hazard that 
the RFC is always strictly followed as there have been cases where I've seen 
private addresses being used (routed across a public interface)"

The issues is Should Not be Routed. First, they will not be blocked as a source on most routers, Next, it is amazing 
how often they are routed. I remember working for an ISP a long while back that was threatened to be disconnected from 
the Internet if they did not stop routing the 10.x range in their BGP tables (and this was an International ISP).

Further, finding source route paths over the Internet is not difficult. Thus it is possible to route "private" address 

Craig Wright GSE-Compliance

Craig Wright
Manager of Information Systems

Direct : +61 2 9286 5497
Craig.Wright () bdo com au
+61 417 683 914

BDO Kendalls (NSW)
Level 19, 2 Market Street Sydney NSW 2000
GPO BOX 2551 Sydney NSW 2001
Fax +61 2 9993 9497

Liability limited by a scheme approved under Professional Standards Legislation in respect of matters arising within 
those States and Territories of Australia where such legislation exists.

The information in this email and any attachments is confidential.  If you are not the named addressee you must not 
read, print, copy, distribute, or use in any way this transmission or any information it contains.  If you have 
received this message in error, please notify the sender by return email, destroy all copies and delete it from your 

Any views expressed in this message are those of the individual sender and not necessarily endorsed by BDO Kendalls.  
You may not rely on this message as advice unless subsequently confirmed by fax or letter signed by a Partner or 
Director of BDO Kendalls.  It is your responsibility to scan this communication and any files attached for computer 
viruses and other defects.  BDO Kendalls does not accept liability for any loss or damage however caused which may 
result from this communication or any files attached.  A full version of the BDO Kendalls disclaimer, and our Privacy 
statement, can be found on the BDO Kendalls website at http://www.bdo.com.au or by emailing administrator () bdo com au 

BDO Kendalls is a national association of separate partnerships and entities.


From: listbounce () securityfocus com on behalf of PCSC Information Services
Sent: Tue 6/11/2007 1:11 AM
To: Ansgar -59cobalt- Wiechers
Cc: security-basics () securityfocus com
Subject: Re: NAT external/Public IP

On 30-Oct-07, at 5:32 PM, Ansgar -59cobalt- Wiechers wrote:

On 2007-10-30 Security Incidents wrote:
On 30 October 2007 07:04 PM Ansgar -59cobalt- Wiechers wrote:
On 2007-10-30 Grant Donald wrote:
With PAT private IP addresses are hidden from the outside world.
This basically makes the job of hacking into a system more
difficult, because the original host's IP address and source port 

This is mere obscurity. It doesn't make a host any more or less
secure than it already is. Like I said before: either a host is
secure, then it doesn't matter if an attacker knows the address, or
it isn't secure, then you're "security" is based on the hope that an
attacker won't discover the host.

Depending on firewall capabilities (or lack of capabilities) ports
may need to be opened inbound for certain applications to work
(e.g.. ident & pptp). A horizontal scan of such a network could
produce a wealth of knowledge, if that network does not support 
address translation.

Ummm... wot? Why would you want to allow any inbound connections 
your LAN? And how would an attacker be able to scan your network 
the outside? For some obscure reason you seem to assume that using
public IP addresses in your LAN means that the firewall at the
perimeter magically allows access from WAN to LAN. This assumption 

Why not Security by Design plus Security by Obscurity?

Because when you have security you don't need obscurity. It will only
add to the system's complexity, which in turn may even *reduce* 
(due to increased risk of misconfiguration and such).

If the additional obscurity does not compromise the design, in any
way, then we may in-fact end up with better security.

No, because it's not reliable, and it doesn't add to security in the
first place.

Do you claim that you can make a host "secure"?

That depends on what you mean by "make a host secure". I do claim that
I'm able to identify security risks for a host, and define measures to
mitigate those risks in a reliable manner.

However, we're getting off the subject. I'm still waiting for 
someone to
explain how public addresses are any less secure than private 
To repeat myself: using public addresses for hosts in your LAN does
*not* mean that those hosts automatically are publicly accessible.

Ansgar, I think that the main contention is that private addresses are 
not considered routable on the public internet. I wouldn't hazard that 
the RFC
is always strictly followed as there have been cases where I've seen 
addresses being used (routed across a public interface)

Obscurity can also have two meanings, and I think that one can have 
without complexity (although I'd also agree that in many (most?) cases 
that this
isn't the defacto standard) You'll find that to obscure something may 
just mean
not reveal... which you'll agree can increase the complexity of 
requirements for
successful attacks and exploits. If you don't know what you're looking 
for because
it's been obscured, then you have increased the big O complexity in a 

It's true that obscurity in no way means security, and it would be 
dangerous to
carry on with that line of thinking for day to day operations. It 
might be better to
consider obscuring something as a 'nuance' to an already well 
considered defense
in depth security model.


Sean Swayze

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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]