Re: NAT external/Public IP

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.

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

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

> 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.

-- 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. Other details can be gleaned from header fields
like TTL or source port number, allowing rudimentary OS
fingerprinting. 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.

But even though address translation obscures information
that an attacker might leverage, obscurity is not security.
Security is not the purpose of address translation, and it
should not be relied upon as such. But that's not an
argument against its use. The privacy function of PAT does
not improve the security of a host, but it does reduce the
surface area open to attack, and that's valuable in the
overall scheme of things.

Secondly, you say "using public addresses for hosts in
your LAN does *not* mean that those hosts automatically are
publicly accessible." You are quite correct, but I'm
not certain that's a position anyone argued.

The original statement (made by Grant Donald) you responded
to was this:
> > 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.

The poster may be confusing static one-to-one NAT with
egress-oriented PAT. An attacker can identify NAT'ed mail
servers with a TCP port 25 connect sweep across your public
address face. That's useful knowledge, but available
elsewhere (DNS MX records, for example), and an inherent
part of offering public services like an internet mail
server for your domain. It's also not mitigated by use of
PAT, as PAT does not allow anonymous inbound connections - a
function required for the service offered.

Then again, he may mean something completely different 
:->  

Best regards,

- Dan

Dan Lynch, CISSP
Information Technology Analyst
County of Placer

(530) 889-4222