From owner-freebsd-isp Fri Mar 14 8:14:27 2003 Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C939D37B404 for ; Fri, 14 Mar 2003 08:14:23 -0800 (PST) Received: from wycliffe.covenant.edu (zwingli.covenant.edu [66.255.16.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A110843FA3 for ; Fri, 14 Mar 2003 08:14:22 -0800 (PST) (envelope-from tracy@covenant.edu) Content-Class: urn:content-classes:message Subject: RE: DNS Proxying based on source address MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Mar 2003 11:14:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS Proxying based on source address Thread-Index: AcLqQKrvC/826C0KSSOlGuttVZUoYQAAz7Ug From: "Tracy, John" To: "Mark Johnston" , , Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org It would be nice to implement such a system with some sort of = expiring... such as ten minutes of inactivity or some variable like = that. Would you use the counters in IPFW somehow to count... or = something? We're trying to do just the same thing with a new wireless = LAN we're installing for students... IE students boot up, get an IP. No = matter what URL they try to access, they get a registration page to = which they must authenticate. Upon authenticating, their workstation is = allowed access out through the gateway (or IPFW box). Then, after some = period of inactivity, or a power off that registration is automatically = killed and to get back online, they must reauthenticate. There's a commercial product called BlueSocket which does this. It costs = $7500 for their basic box... but doesn't offer any real benefits over = the scenario above--and it's limited to 100 active registrations. -John > -----Original Message----- > From: Mark Johnston [SMTP:mjohnston@skyweb.ca] > Sent: Friday, March 14, 2003 10:50 AM > To: 'Dan Mahoney, System Admin' > Cc: questions@freebsd.org; isp@freebsd.org > Subject: Re: DNS Proxying based on source address >=20 > Dan Mahoney, System Admin wrote: > >=20 > > I'm doing a project where I want users on a wireless lan to be = routed > > to a single, wildcard A record, where they will be forced to input > > some registration information, and then allowed out into the real > > world. Some nice folks at southwestern university have already > > written a project that does this called "NetReg" but they are > > requiring a reboot of the client machine and changes to the DHCP = lease > > file. (which will be stopped and started while the client reboots) >=20 > [much snipped] >=20 > I'm assuming here that what you want is a system allowing people to > register and get access, but you don't want to have them change their = IP > address between when they first boot and when they go live. That > introduces a bit of complication to the matter - read on. >=20 > > **big question** > >=20 > > Would adding a second address to the loopback device to the system > > (and only having the rules fwd to those addresses) solve the = source-ip > > dilemma? (at least for the DNS, for the http the machine is still > > expecting a reply from some ip that is blocked). Is there any way = you > > all can think of to have the server return a page when the user = tries > > to access a site via IP (ala a transparent proxy). >=20 > It sounds like transparent "proxying" is exactly what you want. = Here's > my take on a solution for you - some parts of it I've tested for a > similar scheme, some parts are speculation. >=20 > First off, please reread the paragraph of ipfw(8) starting with "fwd > ipaddr[,port]", just for reference. >=20 > I'd start with an ipfw rule like the following, on the gateway: >=20 > ipfw add 65000 fwd $GATEWAY tcp from $INTERNAL to any >=20 > That grabs all incoming TCP traffic and redirects it to your own box. > This part I've tested before, in conjunction with Apache - any web > request, no matter the destination IP, will get a response from your > httpd. Other TCP traffic will hit your box and receive a RST or no > response, depending on your firewall rules. If you want to get fancy, > you can listen for other protocols and send custom messages. >=20 > Once you've got that rule into place, it's pretty straightforward to = add > rules to allow/NAT/whatever traffic on an IP-by-IP basis for hosts = that > you want to let out: >=20 > ipfw add 64900 allow tcp from $REGISTERED_IP to any >=20 > and so on. =20 >=20 > You can decide what you want to do for DNS; my testing used BIND 9's > views and ACLs to serve all requests from unregistered IPs with the = same > answer for any A query, but just leaving UDP wide open seems all right > to me. Even if people are able to look up names, they can't make any > TCP connections. >=20 > Remember here that you haven't got any security; it's trivial to = sniff>=20 > the network, find someone that has already registered, and take over > their IP. Not much you can do about that except implement a = tunnelling > protocol or do some tricks with ipfw2's layer 2 filtering (which still > doesn't help against the dedicated attacker that will change his or = her > MAC address.) For a basic registration-required scheme, though, it > seems pretty sound. >=20 > Hope this is fairly clear - good luck with your setup. >=20 > Mark >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message