Date: Fri, 2 Oct 1998 09:09:07 -0500 (CDT) From: Alejandro Galindo Chairez AGALINDO <agalindo@servidor.exsocom.com.mx> To: ark@eltex.ru Cc: andrew@squiz.co.nz, kim@tinker.com, freebsd-security@FreeBSD.ORG, questions@FreeBSD.ORG Subject: Re: Firewall with 2 NIC and a NET class C Message-ID: <Pine.BSF.3.96.981002090512.13300A-100000@servidor.exsocom.com.mx> In-Reply-To: <199810021048.OAA21732@paranoid.eltex.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
mmmm
i think all depend in the firewall rules, i will only permit the
pass of the DNS, HTTP and e-mail (no telnet, x11, etc), HTTP (80 only for
show the pages of my web server)
all other packets will be denied.
dos this cause a security problem? (may be only the http).
Saludos
Alejandro
On Fri, 2 Oct 1998 ark@eltex.ru wrote:
> -----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
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.981002090512.13300A-100000>