Date: Mon, 12 Jun 2000 11:57:17 +0200 (MET DST) From: Martin Machacek <mm@i.cz> To: freebsd-ipfw@FreeBSD.ORG Subject: Re: Hijacking DNS with ipfw Message-ID: <XFMail.000612115717.mm@i.cz> In-Reply-To: <Pine.GSO.4.21.0006101335160.18010-100000@shell.xecu.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.000612115717.mm>