Date: Fri, 14 Mar 2003 11:14:20 -0500 From: "Tracy, John" <tracy@covenant.edu> To: "Mark Johnston" <mjohnston@skyweb.ca>, <danm@prime.gushi.org>, <isp@freebsd.org> Subject: RE: DNS Proxying based on source address Message-ID: <AB08C89FDA3A6246B59C84D1C8DBCCD82D6B2F@wycliffe.covenant.edu>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AB08C89FDA3A6246B59C84D1C8DBCCD82D6B2F>