Date: Sat, 10 Jun 2000 12:30:23 -0400 (EDT) From: Andy Dills <andy@xecu.net> To: cjclark@alum.mit.edu Cc: "purpledreams.com system administrator" <super@purpledreams.com>, freebsd-ipfw@FreeBSD.ORG Subject: Re: Hijacking DNS with ipfw Message-ID: <Pine.GSO.4.21.0006101204000.15576-100000@shell.xecu.net> In-Reply-To: <20000610002454.A13393@dialin-client.earthlink.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 10 Jun 2000, Crist J. Clark wrote: > > 3) I fwd it to the localhost:53, and the source address of the reply is > > set to 10.0.0.200, and the dest address is set to 10.0.0.1. > > OK, who would be doing this change of source address if there is > no NAT daemon? It isn't changing the source address, it's replying with a source address of the destination address of the original packet. At least, that's how I understand this sentence from the description: "If ipaddr is a local address, then on a packet entering the system from a remote host it will be diverted to port on the local machine, keeping the local address of the socket set to the original IP address the packet was destined for." 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'm running on instance of natd on 8668 already. According to the manpage for natd, -reverse is the closest approximation to what I'm trying to do) natd -p 8669 -alias_address <primary ip of inside card> -reverse ipfw add 10 divert 8669 udp from any to any 53 via xl1 ipfw add 11 fwd 127.0.0.1,53 udp from <ip from the natd command> to any 53 That's the only way I can think of to do this with nat, and that didn't work either. > > Am I incorrect? Maybe we'll have to wait for one of the ipfw developers to > > give some insight. > > My rule of thumb has always been to remember that ipfw(8) never > actually changes the contents of a packet, it just changes where it > gets piped to (except for some rare occasions). If any source address > changes were to be made in the response packets, it would have to be > named doing it, not ipfw(8). Ah, but that's the thing, I'm not suggesting it modifies the packets. I'm saying using fwd with a local address simulates the local machine being the dest ip address, and reply packets have a source address of the original dest ip and a dest ip of the original source. It doesn't actually rewrite anything, it 'emulates' the dest ip, just as you would if you were using squid. My theory is that named doesn't like answering requests for a dest IP it doesn't explicitly think it owns. That's basically what I'm trying to fine out. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.21.0006101204000.15576-100000>