From owner-freebsd-ipfw Fri Jun 9 22: 1: 1 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from mail1.rdc3.on.home.com (mail1.rdc3.on.home.com [24.2.9.40]) by hub.freebsd.org (Postfix) with ESMTP id A7BDC37B6ED for ; Fri, 9 Jun 2000 22:00:57 -0700 (PDT) (envelope-from super@purpledreams.com) Received: from purple ([24.114.51.163]) by mail1.rdc3.on.home.com (InterMail vM.4.01.02.00 201-229-116) with SMTP id <20000610050057.HEXV416.mail1.rdc3.on.home.com@purple>; Fri, 9 Jun 2000 22:00:57 -0700 Message-ID: <003301bfd299$61e21920$a3337218@purpledreams.com> From: "purpledreams.com system administrator" To: "Andy Dills" Cc: References: Subject: Re: Hijacking DNS with ipfw Date: Sat, 10 Jun 2000 01:04:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG But if all you do is redirect the packet to a different port, without NAT, then the result will not be forwarded back correctly. i.e. : 1 - 10.11.12.13 (host) sends DNS to 10.11.13.2 2 - 10.11.12.1 (ipfw gateway) redirects to 127.0.0.1 3 - local DNS answers request, sends results back to 10.11.12.13 without NAT, the packet from number 3 will have a destination of 10.11.12.13 and a source of 10.11.12.1, not 10.11.13.2, and therefore the host making the query won't properly process the packet. NAT would change the source and destination info on the packets (as opposed to merely re-routing them), making them route correctly. all this is, of course, assuming i understand it correctly. it all comes down to the query host receiving the result correctly, not specifically a routing issue at all..... -- dana lacoste purpledreams.com sysadmin FreeBSD since 1997 ----- Original Message ----- From: "Andy Dills" To: "Cy Schubert - ITSD Open Systems Group" Cc: Sent: Friday, June 09, 2000 9:46 PM Subject: Re: Hijacking DNS with ipfw > On Fri, 9 Jun 2000, Cy Schubert - ITSD Open Systems Group wrote: > > > > I had thought that this rule would cut it: > > > > > > ipfw add 10 fwd 127.0.0.1,53 udp from any to any 53 recv xl1 > > > > > > But that just doesn't work. I'm assuming it's because maybe named gets > > > confused because fwd rules preserve the dest IP (as fwd rules are intended > > > to be used in transparent cacheing). > > > > > > Does anybody have a suggestion on how to approach this? > > > > This just changes the next hop a packet would take to its final > > destination. You'll need to use NAT to do what you want. > > That is correct and incorrect. In my experience and according to the man > page, if the "next hop" is an address on the box in question, it is dumped > into the specified port such that the reply packets have a source address > of the dest addr of the original packet. I'm not forwarding the packet to > another host, I'm forwarding it to localhost so that the DNS server can > handle it. > > Regarding NAT, I am using NAT. However, I'm not interested in DNS packets > leaving my network, as many customers will have DNS servers in private IP > space. So, while I'm doing NAT for everything else, I need to hijack dns > to dump it to the local named. I'm positive this is possible, I'm just not > sure how to do it :> > > Thanks, > Andy > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > Andy Dills 301-682-9972 > Xecunet, LLC www.xecu.net > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > Dialup * Webhosting * E-Commerce * High-Speed Access > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message