RE: NAT external/Public IP

Strictly speaking for address translation only, and not ACLs or firewall
rules, I believe that PAT does make a host more secure, not because it
obscures a host's native IP address, but because it is a one-way
function. PAT is dynamically created. As the client host initiates a new
connection, a new port is opened at the translating device. That port is
closed when the connection is torn down. Just as a server cannot exploit
a client's dynamically opened ephemeral port for a new connection, new
connections cannot be made through a PAT back to a client host.

A one-to-one NAT on the other hand _can_ (not must) allow connections to
be established in both directions.

I think it's this distinction that led to the PCI requirement under
discussion.

- Dan


P.S. - That said, a firewall performing address translation services
(PAT or NAT) for a population of clients should regardless have a rule
blocking inbound access just for good measure.

P.P.S. - Please correct me if I'm wrong, but I believe inbound
connections into your LAN from your primary MTA to your internal mail
server is how most internet email gets delivered to internal users.

Dan Lynch, CISSP
Information Technology Analyst
County of Placer
Auburn, CA


-----Original Message-----
From: listbounce@xxxxxxxxxxxxxxxxx
[mailto:listbounce@xxxxxxxxxxxxxxxxx] On Behalf Of Ansgar
-59cobalt- Wiechers
Sent: Tuesday, October 30, 2007 10:04 AM
To: security-basics@xxxxxxxxxxxxxxxxx
Subject: Re: NAT external/Public IP

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.

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


Relevant Pages

  • Re: [fw-wiz] websiite log transfers from exposed to internal nets :
    ... Let's start out by dividing our network into two regions - the ... 'more secure' side and the 'less secure' side. ... let's consider the possible effect of a security compromise ... also assume that any host on the less secure network is easier to ...
    (Firewall-Wizards)
  • Re: Cisco PIX STATIC Entries Fail To Work
    ... Not using PAT in this scenario. ... specify just a host in the static translation. ...
    (comp.security.firewalls)
  • re:On OTP style authentication... criticism please
    ... > problem of getting out of synch with the host system. ... equally as secure. ... we have to make sure that the general public trusts the system; ... Offline storage shouldn't be too bad. ...
    (sci.crypt)
  • Re: SSL and FP Forms
    ... FrontPage Resources, WebCircle, MS KB Quick Links, etc. ... If I buy my own SSL certificate and the host applies ... doesn't that make the complete site secure creating ...
    (microsoft.public.frontpage.client)
  • Re: PIX licencing question
    ... of available license. ... If you are using nat/global then when an internal host wants ... An internal host will have an active translation to the outside if it ...
    (comp.dcom.sys.cisco)