From owner-freebsd-ipfw Mon Jun 12 2:57:23 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from vidle.i.cz (vidle.i.cz [193.179.36.138]) by hub.freebsd.org (Postfix) with ESMTP id 1B86B37BF91 for ; Mon, 12 Jun 2000 02:57:20 -0700 (PDT) (envelope-from mm@i.cz) Received: from ns.i.cz (brana.i.cz [193.179.36.134]) by vidle.i.cz (Postfix) with ESMTP id 437C63070C for ; Mon, 12 Jun 2000 11:57:18 +0200 (CEST) Received: from woody.i.cz (woody.i.cz [192.168.18.29]) by ns.i.cz (Postfix) with ESMTP id A9BF536402 for ; Mon, 12 Jun 2000 11:57:17 +0200 (CEST) Content-Length: 2600 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 12 Jun 2000 11:57:17 +0200 (MET DST) Reply-To: mm@i.cz From: Martin Machacek To: freebsd-ipfw@FreeBSD.ORG Subject: Re: Hijacking DNS with ipfw Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 10-Jun-00 Andy Dills wrote: > On Sat, 10 Jun 2000, purpledreams.com system administrator wrote: > Well, to provide more input, I did this: > > I set up apache on this box, running on the standard port 80. I did a: > ipfw add 200 fwd 127.0.0.1,80 tcp from any to any 80 recv xl1 > > And guess what...it worked perfectly. So, I'm growing closer to assuming > this is a named issue. I'm considering trying out tinydns from bernstien, > to see what happens with that. It won't work! Why? The answer is in the code (as usually). Grep for IPFIREWALL_FORWARD in /usr/src/sys/netinet. You will find out that when kernel is compiled with IPFIREWALL_FORWARD and a packet is being redirected via ipfw fwd rule to a local address the only thing that happens is that the check for destination address being local is skipped. BUT only for TCP! The code that does it is in tcp_input.c around line 530 (CURRENT as of today). There is no equivalent counterpart for it in the udp_input function (or anywhere else as far I can see). As a result of that ipfw fwd rules can be used to redirect UDP packet to different next hop (other than the one that you'd look up in routing table) but cannot be used to redirect packets to localhost. It should be probably documented on the ipfw manpage. The reason for this assymetry comes from the difference between connection oriented transport (TCP) and connectionless datagram service (UDP). When sevicing TCP you have (on the server side) one socket for every client (returned from the accept call) and actually the socket structure is the place where the neccessary information about the original target address is being stored. So it can be put in source address field in reply packets. You have nothing like that for UDP. The other reason why ipfw fwd does not work for UDP is that the whole thing is more of a hack than a clean solution. Better (definitely cleaner) solution for redirecting packets working fine also for UDP is being offered by ipfilter. It is part of the base system (I believe since 3.0) and you can enable it by adding the IPFILTER option to kernel configuration and recompiling the kernel. It offers IP filtering sevices (configured via the ipf command - see man ipf) and IP NAT services (configured via ipnat command - man ipnat). It is somewhat harder to use from the programmers point of view (you need couple extra lines of code to get the original destination address) and I don't remember seeing any patch for named that would allow you to do what you want. So, you are on your own anyway ;-). Martin --- [PGP KeyID F3F409C4] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message