From owner-freebsd-ipfw Sat Jun 10 9:44:28 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from mail2.rdc3.on.home.com (mail2.rdc3.on.home.com [24.2.9.41]) by hub.freebsd.org (Postfix) with ESMTP id 613C037BD36 for ; Sat, 10 Jun 2000 09:44:24 -0700 (PDT) (envelope-from super@purpledreams.com) Received: from purple ([24.114.51.163]) by mail2.rdc3.on.home.com (InterMail vM.4.01.02.00 201-229-116) with SMTP id <20000610164423.BLMI1114.mail2.rdc3.on.home.com@purple>; Sat, 10 Jun 2000 09:44:23 -0700 Message-ID: <001201bfd2fb$971c45e0$a3337218@purpledreams.com> From: "purpledreams.com system administrator" To: "Andy Dills" , Cc: References: Subject: Re: Hijacking DNS with ipfw Date: Sat, 10 Jun 2000 12:47:39 -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 From: "Andy Dills" Sent: Saturday, June 10, 2000 12:30 PM > What I don't really understand is how NAT would help in this situation. > What I need to do is re-write the destination address to a local ip upon > receipt of the packet, and upon reply, rewrite the source address to the > original destination address. > The problem is, AFAIK nat will not do that under any circumstances. I > tried this approach already: I think I understand where the confusion lies now. If I understand correctly : (from the natd man page, but the box I got this off is only 3.3-RELEASE, so there may have been some changes. YMMV) -redirect_port proto targetIP:targetPORT [aliasIP:]aliasPORT [re- moteIP[:remotePORT]] Redirect incoming connections arriving to given port to an- other host and port. Proto is either tcp or udp, targetIP is the desired target IP number, targetPORT is the desired tar- get PORT number, aliasPORT is the requested PORT number and aliasIP is the aliasing address. RemoteIP and remotePORT can be used to specify the connection more accurately if neces- sary. For example, the argument tcp inside1:telnet 6666 means that tcp packets destined for port 6666 on this machine will be sent to the telnet port on the inside1 machine. This is how natd describes port redirecting. this won't work for you because you don't know the IP address that the DNS request is going to: you only know that it's going to port 53. I think that you will still need natd or something similiar, as ipfw doesn't change the packets, and natd does, exactly as you describe above. The problem is how to make the redirection occur for _any_ connection attempt to port 53, instead of merely redirecting port 53 attempts to known IPs. From how I understand it, I would be extremely surprised if ipfw will do this independently : it _shouldn't_ be able to handle it, as sometimes you would need the functionality of redirecting without changing the source/destination info! In a former life :) I managed a Gauntlet firewall on NT. It had something called "transparent proxying" which would do what you intend (although it wouldn't do it for DNS : it treats DNS as a major security hole.) What it does is monitor (for example) any packets heading through on port 80 (as most people use transparent proxies for web access and little else) and manage the connection itself, transparently to the client. I don't think that natd supports this right now (maybe next weekend after I switch the aforementioned 3.3 box to 4.0 I will see more into this though.) Can someone please sanity check my explanation here? It makes sense to me, but I don't want to make anyone follow the wrong train of thought in figuring this out :) -- Dana Lacoste purpledreams.com sysadmin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message