Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Jun 2000 12:47:39 -0400
From:      "purpledreams.com system administrator" <super@purpledreams.com>
To:        "Andy Dills" <andy@xecu.net>, <cjclark@alum.mit.edu>
Cc:        <freebsd-ipfw@FreeBSD.ORG>
Subject:   Re: Hijacking DNS with ipfw
Message-ID:  <001201bfd2fb$971c45e0$a3337218@purpledreams.com>
References:  <Pine.GSO.4.21.0006101204000.15576-100000@shell.xecu.net>

next in thread | previous in thread | raw e-mail | index | archive | help
From: "Andy Dills" <andy@xecu.net>
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001201bfd2fb$971c45e0$a3337218>