From owner-freebsd-security Fri Oct 2 03:49:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA02240 for freebsd-security-outgoing; Fri, 2 Oct 1998 03:49:27 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from hosting.doublesquare.com (hosting.doublesquare.com [195.5.128.151]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA02234; Fri, 2 Oct 1998 03:49:24 -0700 (PDT) (envelope-from ark@eltex.ru) From: ark@eltex.ru Received: from eltex.ru (eltex-spiiras.nw.ru [195.19.204.46] (may be forged)) by hosting.doublesquare.com (8.8.8/8.8.8) with ESMTP id OAA00965; Fri, 2 Oct 1998 14:48:24 +0400 (MSD) Received: from paranoid.eltex.spb.ru (root@border.eltex.ru [195.19.198.2]) by eltex.ru (8.8.8/8.8.8) with ESMTP id OAA08568; Fri, 2 Oct 1998 14:48:45 +0400 (MSD) Received: (from ark@localhost) by paranoid.eltex.spb.ru (8.8.8/8.7.3) id OAA21732; Fri, 2 Oct 1998 14:48:24 +0400 Date: Fri, 2 Oct 1998 14:48:24 +0400 Message-Id: <199810021048.OAA21732@paranoid.eltex.spb.ru> Organization: "Klingon Imperial Intelligence Service" Subject: Re: Firewall with 2 NIC and a NET class C To: andrew@squiz.co.nz Cc: ark@eltex.ru, agalindo@servidor.exsocom.com.mx, kim@tinker.com, freebsd-security@FreeBSD.ORG, questions@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----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