Date: Fri, 14 Mar 2003 15:36:22 -0500 (EST) From: "Dan Mahoney, System Admin" <danm@prime.gushi.org> To: "Tracy, John" <tracy@covenant.edu> Cc: Mark Johnston <mjohnston@skyweb.ca>, <isp@freebsd.org> Subject: RE: DNS Proxying based on source address Message-ID: <20030314151419.R39684-100000@prime.gushi.org> In-Reply-To: <AB08C89FDA3A6246B59C84D1C8DBCCD82D6B2F@wycliffe.covenant.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Mar 2003, Tracy, John wrote: > 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. You could use the counters, you could also do periodic pings so if they shut down, they're logged out. You could even do periodic arpings so that you're sure people aren't jumping macs on you. It's all written in perl, which makes it easily extensible. The system you're talking about was the one I found designed by the people at southwestern university. Similar systems exist, just search for "netreg" in google and you'll be rewarded. -Dan > > 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 > > > > Dan Mahoney, System Admin wrote: > > > > > > 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) > > > > [much snipped] > > > > 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. > > > > > **big question** > > > > > > 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). > > > > 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. > > > > First off, please reread the paragraph of ipfw(8) starting with "fwd > > ipaddr[,port]", just for reference. > > > > I'd start with an ipfw rule like the following, on the gateway: > > > > ipfw add 65000 fwd $GATEWAY tcp from $INTERNAL to any > > > > 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. > > > > 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: > > > > ipfw add 64900 allow tcp from $REGISTERED_IP to any > > > > and so on. > > > > 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. > > > > Remember here that you haven't got any security; it's trivial to sniff> > > 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. > > > > Hope this is fairly clear - good luck with your setup. > > > > Mark > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-questions" in the body of the message > -- "If you aren't going to try something, then we might as well just be friends." "We can't have that now, can we?" -SK & Dan Mahoney, December 9, 1998 --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- 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?20030314151419.R39684-100000>