Controlling Access to Wireless APs? 30
pvera asks: "A friend-of-a-friend-of-a-friend is thinking of offering wireless internet access at the medical conferences that he organizes. He already has people that can help him setting the access point itself and the connection to the internet, but he does not know how to control access. I am a T-mobile hot-spot subscriber, and my service uses some sort of proxy that does not allow me to surf thru their network unless I authenticate on a page that comes up regardless of what my home page is set to. Once I am authenticated then the proxy is transparent to me.
Here in Arlington, VA there is a company called iSurf networks that has the exact same setup as T-mobile, only they sell their service thru pre-paid cards. The cards are just like phone cards, your scratch a strip in the back to have access to the account id and the password. While you use the connection it shows a pop-up with a count-down display so you know how much time is left in your card. Does anyone know of a commercial or open source product that allows this functionality? Or of a company that provides an outsourced solution to do this?"
A look to the past (Score:1)
Re:A look to the past (Score:1, Offtopic)
but it's microwave... (Score:2)
(I know i know that was old pacemakers and the ap doesn't have enough power)
just picture it though
Re:but it's microwave... (Score:5, Interesting)
WFAA-TV in Dallas, TX, was one of the first TV stations in the country, if not the first, to turn on its HDTV transmitter. It did this back in 1998.
Dallas is also the home of Parkland Memorial Hospital, a giant hospital complex. Some of you may remember Parkland as the hospital where President Kennedy was pronounced after his assassination in 1963.
Parkland Hospital has a giant cardiac ICU, as one would expect of a giant hospital. In the cardiac ICU they use wireless telemetry systems to monitor patients' hearts. Instead of having a 12-lead EKG monitor by each patient's bed and sending nurses around to check them, they put the leads on each patient and then connect them to a little battery-powered wireless transmitter. The transmitter sends the signals back to the nurse's station where they can be observed by a human being more conveniently and safely.
So back in 1998, WFAA flipped the switch to turn on their HDTV transmitter. And every single wireless cardiac monitor in Parkland went bat-shit.
The long story made short, as it was explained to me, is that the company that made the wireless monitors was, either through negligence or some kind of honest mistake, using the wrong frequency. The frequency they were using was allocated by the FCC for digital television broadcasts. This wasn't a problem at the time, because there were no digital television broadcasts anywhere in the country. Until that day when WFAA turned on their transmitter.
Ever since hearing that story, I've been a little skeptical about the much-lauded wireless revolution. Imagine if you will that the FCC, some years from now, reallocates the 2.4 GHz band for some other use. All the gear that currently uses that band, from microwave ovens to cordless phones to Bluetooth gadgets to your laptop, these things aren't just going to disappear.
Oh, trouble's a'brewin'.
Re:but it's microwave... (Score:3, Interesting)
I suspect they weren't really using the wrong frequency, per-se, rather, their frequency was a harmonic of the HDTV signal, or vice-versa.
In keeping with the best practices of the regulatory state, some genius decided that Medical Devices are exempt from RF shielding requirements. And every radio geek knows that every transmitter also an antenna. So, you take a medical wireless radio transmitter, don't sheild the thing, then turn on a honkin' transmitter nearby, and everybody is surprised when things stop working. <whine>But it's FDA approved!</whine>
On the bright side, when cell phones first started becoming popular, the hospital where I worked did an audit. Net-net: don't get within 4 feet of a respirator when you're broadcasting, but everything else is pretty much OK.
might try... (Score:4, Informative)
NoCatAuth (Score:5, Informative)
Why make it dificult (Score:2, Interesting)
The IETF has been providing wireless service to conference participants for years now, wide open, you can use a key if you want to, but most people don't.
Encryption is necessary (Score:1)
Now the next issue is how to keep a new person from using this same IP address. You could watch for MAC address changes and remove the iptables rules if the MAC changes. That is one approach. Granted that this is a medical conference, I don't see anyone changing their network address or sniffing packets, but if their are somehow outsiders, you could sniff packets, change a MAC address and use the same IP address as the aforementioned authenticated user. Encryption is probably the way to go if you are genuinely concerned about access.
IPTables rules + Apache (Score:4, Informative)
When a machine joins the network and gets an IP address and attempts to hit a website, it will attempt to go through your firewall. You'll want to have this machine redirect the connection to a webserver on that machine that shows a "authenticate in some way, shape or form." Using whatever logic you want, it decides to allow this machine to go out the firewall unstopped. You could probably have this program write the IP address to a file or database or something.
Some other process picks up that there's a new machine that should be granted access, and it creates a new iptables rule to allow it unrestricted outbound access, thus bypassing the "redirect everyone to our 'authenticate' page".
Now the next issue is how to keep a new person from using this same IP address. You could watch for MAC address changes and remove the iptables rules if the MAC changes.
This is a bit hasty response - heading out the door.
Hotspot Authorization (Score:1)
www.mikrotik.com
DIY (Score:5, Informative)
The AP is hooked up to a FreeBSD box. The FreeBSD box runs NAT and DHCP. When the box sees a DHCP lease request from an unkown MAC, it gives the client an IP and puts the client in a "sandbox" network. This "sandbox" network redirects all IP packets to port 80 on the authentication server (two different ways to do this - either with dynamic ipfw rules, or directly through divert(4)). The authentication server asks for a username/password. Since you write this stuff yourself, you can integrate it with LDAP/Kerberos/flat files, etc. You can even get creative and set the password to something you print out on a receipt so the clients have to "buy" time from you, with the POS computers hooked up to the auth server, etc.
Once the client authenticates, you modify the ipfw rules that redirected packets to the local machine so that packets run through the normal NAT stuff. You can also set up a cron job to delete stale entries so people have to re-authenticate every now and then.
If you do this with ipfw, it's just a couple rules. I ran into some problems doing it this way, so I wrote a little C program that directly inspected packets and passed them along using FreeBSD's divert(4) interface. (I get paid to do these sort of things for people, so the code ain't mine to give away and it would be pretty useless anyway since there's a lot of coding and admin work involved in integrating it).
For real security, you'll need to pass all packets through such a custom program anyway, so you can inspect whether or not that particular IP (given from a DHCP lease) has authenticated recently. You'll also need an AP that passes along MAC addresses unmodified. I know Cisco Aironets allow you to do this, and I know Linksys APs don't (Linksys APs are based on a Lucent chip that's used in lots of other APs like the Apple Airport).
Note that someone with enough expertise can sniff the network, get a valid IP, DOS the real client, and then impersonate the already-authenticated MAC and IP. All systems which work in the way you described are vulnerable to this type of attack.
Not a whole lot you can do to fight this; however, a while back, some guy submitted a paper to Slashdot about how you can tell if someone is spoofing a MAC based on some peculiarities with how most 802.11b cards handle a sequence number in the 802.11 protocol. I'm guessing his paper is new enough that none of the people who sell these pre-built systems implemented his idea, but if you do your own, you're free to implement whatever you want. Note that using this is still not foolproof (search my posting history for an example of an attack against a system which would use this idea and for the link to the original article).
Basic conclusion: there is no bulletproof system which does what you need. If you implement it correctly (with an AP that passes along MACs unmolested in bridge mode), it makes it more difficult, and if you implement the anti-spoofing thing I mentioned, it just ups the bar even more, past the level of the script kiddies. Judge your security needs: such a wireless access system can be good enough if you ensure your confidential data is behind a real authentication system and is never sent over the wire clear-text. If you're worried about someone (someone capable) stealing 'net access from you, you should probably stay away from wireless.
You seem to be looking for a pre-built system that does this sort of thing. Although I'm sure someone is selling this sort of thing, it's probably not popular because there are so many variables involved with integrating it into your existing infrastructure (cabling, routing, authentication systems, etc). Generally, you would get a competent consultant to build something like this for you if you don't have the requisite programmers and networking gurus. If you want to avoid the consulting fees, pick up some Richard Stevens books to learn networking and programming, and start running -CURRENT to learn proper system administration :)
Have fun.
Re:DIY (Score:2)
I'm doing a similar thing. So far I find I probably have to resort to using the ipfw skipto feature (if they log in, a skipto rule is added for them, if they log out the skipto rule is removed)- that's because I want to use stateful rules and I want to abruptly disconnect existing connections of people who logout, without affecting other people.
I haven't figured out how to do it without using skipto (looks a lot messier), but if you can, I'd be interested. Always good to see other ways of doing things.
Re:DIY (Score:2)
OK, now that I look at it, I may have needed "sets" because there were actually two rules for each record. The first one which skipped over the redirect:
And the second one which put the packet through the regular NAT stuff:Now that I think of it, "sets" wouldn't really be necessary as long as you enable/disable the second rule first. Even if it did go wrong, it's just one or two lost packets in the time between the two rules being activated. Even this is unlikely since the user will probably be looking at the results of the authentication page at this time.If you use the divert(4) stuff, you don't need any dynamic rules at all - just pass all the packets into your divert socket and have the program look up the MAC and IP in a database or flat file. Seems somewhat more elegant.
Fun stuff.
Re:DIY (Score:2)
In my case the user must have an active HTTPS connection in order for the user rules to stay active (like a continuous slow download). The active connection could display announcements, status info, chat messages, ads, whatever. If the user disconnects, the webapp notices after a short period and the user's rules are removed. And poof no connection.
So DOSing the user won't help for long (squeeze in a few packets - IIRC ipfw stateful checks don't seem as rigorous as ipf's - the TCP seq nums aren't checked, but I can't use ipf for what I want to do). Trojaning the user, or working with the user will help. But in those cases the battle is mostly lost already.
The transient rules are in a different set from the main rules. On changes I actually intend to delete all the transient rules and re-add the valid ones using a temporary set, and then swap them in atomically with the active transient set.
This shouldn't affect the stateful rules since the transient rules are mainly skiptos. The skiptos skip to the relevant group of rules for a user class, no skipto you hit the deny or catch-all webserver.
The problem I find is - I'm pretty sure it'll work, but it starts to look very messy.
Building a firewall admin tool is not going to be fun if I do this. The proper way would be to abstract the rules from the actual ipfw stuff, but that would mean a lot less control.
Oh well... Your way doesn't look much cleaner either
Re:DIY (Score:2)
Very clever. HTTPS protects against man-in-the-middle attacks, so it will be very unlikely that someone could take over an existing connection for any extended period of time.
Keeping a browser window open might be annoying - not a big deal for us Unix folks (background wget or something), but your Windows users might complain. You might consider writing an optional Windows application that embeds MSIE via COM and stays in the systray. However, Win32 programming is hellish, and I wouldn't do it :)
If I ever do this again, I'll probably use that HTTPS idea as it's more elegant and more secure than what I came up with.
How do you tell if someone has logged out?
I had a little web page where people could explicitly log out. Of course, I didn't expect people to use that (and they didn't), so I would just time out sessions with a cron job. Nobody complained, but the more correct way would be to examine the rule's timestamp (ipfw -t list), something I didn't do.
Re:DIY (Score:2)
While it works with most browsers, people can write a Win32 client app or a java client app to wrap around it if they think it looks ugly. Don't need MSIE - just need HTTPS or HTTP if desperate
What you have to watch for is you probably have to regularly send data, if not your webapp might not detect the disconnect soon enough, or something (browser/server/network) might timeout prematurely. My webapp sends a null every X seconds or so (depends on how fast you want to detect timeout), if it has nothing to send, seems most browsers don't display nulls - that's where the implementation starts looking less elegant
I originally used this concept for an intranet chat web app. Works for most normal browsers - but need javascript enabled to force the chatlog to scroll downwards every sec or so. Instant messaging with 128 bit crypto
If people wanted it fancier someone could write a java applet to download the chatlog from webapp. The webapp could serve up the chatlog in XML/custom HTML to the java applet if necessary.
The same web chat app might work for phones, palm pcs etc (if you don't require HTTPS).
I personally preferred this approach to what some other people are doing, but I'm obviously biased
Re:DIY (Score:1)
I apoligize for not being the UNIX networking guru but what exactly does "running -CURRENT" mean?
Re:DIY (Score:2)
If you run -CURRENT, you'll run into lots of bugs, and writing good bug reports means delving into the code, so you end up reading lots of code and solving lots of adminny-type problems if you run -CURRENT. Not recommended for important servers, but fun to play with nonetheless. FreeBSD lets you decide precisely where to draw the line between rock-solid (-RELEASE) and bleeding-edge (-CURRENT).
The admin stuff is important because it often means avoiding writing lots of code; eg, you can avoid writing a couple thousand lines of code with a 15-line shell script. I often marvel at how some smart people don't know how to use the right tool for the right job (like spending days trying to do text manipulation in matlab, where the problem can be solved with ten lines of perl, or writing a complex network daemon from scratch, where the problem could be solved with a 100-line patch to an existing program they didn't know about). Saves weeks of time. Best way to learn the admin stuff is to run one of the BSDs (or Slackware) and avoid the hand-holding distros. With a BSD or Slackware system, you can rewrite all the machine's boot scripts in an afternoon (cutting out all the cruft you don't need), something which is nearly impossible with, say, Redhat, which has deep layers of abstraction you have to rip through before getting to what you need.
Example: I recently had to write a daemon did something whenever it noticed a new file in a certain directory. Well, this is pretty easy, since you only have to periodically look at the directory's modification time to see if you need to re-read it (open at start and fstat poll - this is the only efficient way to do it portably). You run into some subtle issues, however, as files may be added or deleted in between when you check the mod time and read the directory, and files may be added just after you check the directory (within the same second, so the mod time isn't changed). Writing the correct code to avoid these race conditions takes an hour or two. After having wriitten it, I was compiling the latest version of KDE or GNOME or something, which means tracking down dependent libraries manually, figuring out what they do, fixing any compilation problems, etc. I then learned about libfam, which is used by one of these things and does exactly what my code did. Had I been running one of the hand-holding distros, which automatically solves dependencies, I would have never learned about it.
one way, or the other... (Score:3, Informative)
Some ideas. (Score:2)
There is a company [fatport.com] that is doing this locally with excellent success.
Boils down to
I use this frequently when travelling and it works very very well
Their platform [fatport.com] is available commercially and the software is based on compact BSD [sourceforge.net].
new topic/icon (Score:2, Informative)
Sounds like... (Score:1)
The longer the timeframe you keep that same WEP the more useless it becomes.
Look at what Stockholmopen.net did (Score:2, Informative)
Basically, it's a system designed to offer a wide coverage by little means and cooperation.
Everything is at www.stockholmopen.net [stockholmopen.net] You can download the software here too.
use a vpn client (Score:2)