Re: NAT external/Public IP

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

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