From owner-freebsd-security Fri Oct 2 07:02:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA00698 for freebsd-security-outgoing; Fri, 2 Oct 1998 07:02:35 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from servidor.exsocom.com.mx (servidor.exsocom.com.mx [200.34.46.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA00670; Fri, 2 Oct 1998 07:02:28 -0700 (PDT) (envelope-from agalindo@servidor.exsocom.com.mx) Received: from servidor.exsocom.com.mx (servidor.exsocom.com.mx [200.34.46.130]) by servidor.exsocom.com.mx (8.8.7/8.8.5) with SMTP id JAA13338; Fri, 2 Oct 1998 09:09:07 -0500 (CDT) Date: Fri, 2 Oct 1998 09:09:07 -0500 (CDT) From: Alejandro Galindo Chairez AGALINDO 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 In-Reply-To: <199810021048.OAA21732@paranoid.eltex.spb.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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-security" in the body of the message