Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 Oct 1998 14:48:24 +0400
From:      ark@eltex.ru
To:        andrew@squiz.co.nz
Cc:        ark@eltex.ru, agalindo@servidor.exsocom.com.mx, kim@tinker.com, freebsd-security@FreeBSD.ORG, questions@FreeBSD.ORG
Subject:   Re: Firewall with 2 NIC and a NET class C
Message-ID:  <199810021048.OAA21732@paranoid.eltex.spb.ru>

next in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----

nuqneH,

..from my paper on NAT in firewall environment (yet unfinished):

[skip]

Static Bidirectional NAT (one-to-one)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

NATed internal IP address is bidirectionally mapped to external one,
passing all incoming and outgoing connections to/from internal machine -
it appears as virtual host in external network.

Connectivity viewpoint: Execllent. Every protocol will work except
ones that do send IP addresses in data stream.

Security viewpoint: Really Bad Thing, inacceptible in most cases.
Creating a bidirectional virtual channel to inside host is equal to
placing it as another dual-homed gateway being protected with packet
filtering only (most NAT boxes can do packet filtering as well). 
This will probably break any reasonable network security policy.

Dynamic Bidirectional NAT (many-to-many)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The same thing as described above, but external IP addresses are assigned
dynamically from address pool on the NAT box. Assigned address (NAT rule)
is created on connection request (outgoing packet to an external address)
and exists until the rule expires (due to inactivity or another reason)

Connectivity viewpoint: The same as above, except you can't place a public
server inside because NATed host has no fixed external IP address.

Security viewpoint: Much worse than most people think and even worse than
static NAT, because possible compromise affects not a single machine,
but a whole network that is NAT-allowed. It is common misconception that
hackers will not find NATed machines because addresses are hidden. They
will scan NAT pool and do that fast enough. After machine is compromised
it is easy to keep NAT rule active thus keeping the host exposed or to
spoof packets to cause other hosts to appear on the external side.

Dynamic "Unidirectional" NAT (many-to-one), possibly with port remapping
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

a.k.a. IP Masquerading. The word "unidirectional" is kept in quotes
because it does not (usually) mean that data stream is unidirectional;
that just means connection requests (except some special cases) are
passed one direction (inside to outside only) due to different nature
of the NAT rule, which includes not only real and mapped source 
(internal) IP, but also original and mapped port numbers and destination
IP and port number. Packets that do not match the rule are rejected.

Connectivity viewpoint: only protocols that use single client-to-server
connection should work. Most NAT implementations include some workarounds 
to bypass this limitation (which does not allow, say, active ftp to work) , 
usually based on some application level knowledge achieved by packet 
contents inspection.  There are some additional security issues with that 
technique (not to be discussed here).

Security viewpoint: not as good as it seems to be. If a host on the
protected network is compromised, it is relatively easy to expose it
to further attacks. Some techniques are shown below.

1) Attacks using inside-originated connection. 
The most obvious example of a protocol that gives full control to 
_server_ it connects to is X-Windows system. Speaking X11, the "server"
is a computer with display attached and "client" is any program that 
interacts with it using X protocol.
That means that all connections are client-originated (TCP sessions to
port 6000+display #) and will go out via NAT perfectly.

A real-life attack could look like this:

 A victim host behind NATing firewall is being exploited (does not
matter how does that happen: actively - say, attacking irc client
(remember that BitchX dgets() vulnerabilities), mail program or something
else - or passively (creating website with malicious page). An xterm
session is started from there to attacker's display - and - full shell
access is gained.

2) Attacks intended to create specific NAT rules.

 An attacker sends connection requests from desired IP addresses (after
compromising at least one internal machine) from service port to be exploited
to an attacker host. Then properly crafted backwards connection (with source
port that matches the rule which can be determined by analysing appeared packet
from the first step) will match the rule and can passed to the victim.
(Note: not all NAT implementations are vulnerable; it depends on how
connection setup is checked when creating the rules and what is allowed
in the estabilished connection packet stream)

[skip]

                                     _     _  _  _  _      _  _
 {::} {::} {::}  CU in Hell          _| o |_ | | _|| |   / _||_|   |_ |_ |_
 (##) (##) (##)        /Arkan#iD    |_  o  _||_| _||_| /   _|  | o |_||_||_|
 [||] [||] [||]            Do i believe in Bible? Hell,man,i've seen one!

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBNhSvdqH/mIJW9LeBAQESCgP9E5HJXAAICf01qbX/9M0dXIaRi6GNDF5Y
Qd1o5DONW5fzwPz7L7kfkT1U7dz2KtZrsECaM6G3/rtPGTlfVR6L0kAadYvxoZ67
XMyMDviqzEEqzxBZwQoi2RRRJ02u6hEBHybtT5RH0s+GtUgpRpuhhSs+crVfyXck
7Pd/YXN/EDE=
=ZEF7
-----END PGP SIGNATURE-----

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810021048.OAA21732>