Re: NAT external/Public IP

[PCSC Information Services <info () pcsage biz>]

Hi Craig,

I agree totally, it is shocking to find that there isn't better  
routing control at the highest levels, and as such
I can see how NAT addresses in no way are inherently more secure than  
public addresses with this in mind. It then falls to the configuration  
of each system that is exposed to the public network as has already  
been mentioned.

In an ideal world we would see RFCs maintained network wide and our  
internetworking could be that much
more secure. Education and cooperation are key to success in that  
effort, however the transition to v6 will make much of this discussion  
moot shortly (?)

Best,

Sean Swayze

On 5-Nov-07, at 1:37 PM, Craig Wright wrote:

> Hello,
> 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 ranges.
>
> Regards,
> 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
> www.bdo.com.au
>
> 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 system.
>
> 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
> > > > > is
> > > > > unknown.
> > > >
> > > > 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
> > > > > port
> > > > > address translation.
> > > >
> > > > Ummm... wot? Why would you want to allow any inbound connections
> > > > into
> > > > your LAN? And how would an attacker be able to scan your network
> > > > from
> > > > 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
> > > > is
> > > > wrong.
> > >
> > > 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*
> > security
> > (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
> > addresses.
> > 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
> 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)
>
> Obscurity can also have two meanings, and I think that one can have
> obscurity
> 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
> significant
> way.
>
> 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.
>
> Best,
>
> Sean Swayze
>
>
>
> > Regards
> > Ansgar Wiechers
> > --
> > "All vulnerabilities deserve a public fear period prior to patches
> > becoming available."
> > --Jason Coombs on Bugtraq