Contributed by dhartmei on from the wireless-warfare dept.
A new daemon, the new OpenBSD hostapd(8), will be included in the upcoming 3.8 release. The daemon helps to improve roaming and monitoring of OpenBSD-based wireless networks. A powerful feature, event rules, will introduce a new kind of proactive wireless monitoring. WLAN is a battle field, and hostapd helps to keep track of your systems, unwanted wireless visitors, and rogue accesspoints.Read on for some amazing (and possibly controversial) examples of how this new tool can be used. The OpenBSD hostapd(8) was initially implemented to support the Inter Access Point Protocol (IAPP), the IEEE 802.11f roaming standard for Wireless LANs. I initially developed it during the 21c3, a large annual hacker event in Germany, to improve roaming and station tracking in a network with about 40 OpenBSD-based accesspoints. Because its initial purpose was IAPP only, I intended to just call it "iappd". Admittedly, this was a stupid name. During the 3.7-current release cycle right before the c2k5 hackathon this daemon was imported into the OpenBSD tree. After a discussion with Theo, the name was changed to "hostapd" because we realised that it shouldn't be focussed on a single IEEE protocol; its real purpose being a "HostAP assist daemon" indeed.
hostapd can be used with a single accesspoint, e.g. using a box running ath(4) in hostap mode, or even an entire wireless network with several accesspoints. An accesspoint, typically equipped with a wired and a wireless interface, tracks the state of stations associated to it. Of course, the kernel-level hostap recognizes when a station joins the network but if the station moves away it just disappears for the AP. As a solution, hostapd, which is listening on the wireless interface and the kernel-level station states, will send out notifications to a multicast or broadcast address on the wired interface for every newly associated station. It also listens on the wired interface for messages from other hostapds, and an "ADD.notify" message for a station previously associated to itself instructs hostapd to clean up any resources for this station in the kernel.
Tracking and monitoring of station movements is possible as well. The hostapd messages will be sent immediatly after recent station associations and every listening hostapd will be able to log the movements in the entire wireless network. hostapd will turn into a passive monitoring daemon if the wireless interface is omitted and if it's listening to the wired "IAPP" interface only. This is a typical case for a wireless controller and monitoring server, connected to the same multicast group or in the same broadcast domain. hostapd is designed for highly decentralized and scalable wireless networks, regardless of how many accesspoints or monitors are actually interconnected. In contrast, most vendors of wireless network solutions are using CAPWAP- (Control And Provisioning of Wireless Access Points) based designs with a single, fragile, server controlling all the IEEE 802.11 wireless states for a bunch of dump WTPs (Wireless Termination Points) instead of real accesspoints.
The most interesting feature of hostapd is the implementation of so-called "Event Rules". During the c2k5, I started to work on a way to handle specific IEEE 802.11 traffic received on the wireless interface. Human-readable event rules in hostapd.conf(5) similar to rules in pf.conf(5), which emerged to be an OpenBSD-typical configuration style, can be used to trigger an action on specific events in the wireless network. Currently, there are five different actions available: frame, iapp radiotap, log, node, and resend. An example of such a rule is
hostap handle type management subtype beacon bssid !<my_hostaps> \ with log limit 2 secwhich locally logs beacon frames from unknown accesspoints, limited to every 2 seconds. Like pf, hostapd provides support for powerful and fast tables to match against multiple addresses in a single rule (based on hashed tables in OpenBSD 3.8, changed to red-black trees in 3.8-current). The previous example uses a table, based on the same syntax as in pf.conf. It has to be declared on top of hostapd.conf, like the following table which defines a list of MAC addresses (BSSIDs) of my accesspoints:
table <my_hostaps> { 00:02:6f:21:e0:e9, 00:90:4b:0d:fd:c8 }It's even possible to use address masks to match against the MAC address vendor part, e.g.
table <cizzco-eee> { 00:40:96:00:00:00 & ff:ff:ff:00:00:00 }and to use this table to trigger a specific action
hostapd handle type management subtype probe request from <cizzco-eee> with log
Furthermore, the frame action turns hostapd into a WIPS (Wireless Intrusion Prevention System), because I extended the bpf(4) interface with the ability to send raw IEEE 802.11 frames to the wireless network. This action can be used to affect the wireless management states of any stations or accesspoints in range. By exploiting the weakness of the IEEE 802.11 protocol, a former DoS attack turns into an useful countermeasure against rogue accesspoints in your wireless territory, e.g.
hostap handle type data bssid !<my_hostaps> \ with frame type management subtype deauth reason auth expire \ from &bssid to &from bssid &bssidwhich sends deauthentication frames to stations sending data frames in unofficial and "rogue" wireless networks.
Besides the log and frame actions, "iapp radiotap" sends the received and successfully matched IEEE 802.11 frame attached to a hostapd-specific message to the IAPP domain; "node" can be used to alter the kernel-level station table (i.e. remove specific associated stations); and "resend" simply re-injects the wireless frame. All the possible scenarios for using these and future actions are hard to determine, for example with "iapp radiotap" hostapd could act as a sensor for a WIDS (Wireless Intrusion Detection System), including radiotap headers with signal levels and all the relevant information for wireless location tracking.
Future work for hostapd is in progress, so expect some new features and improvements. A new "rate" keyword in 3.8-current extends the event rules with the ability to detect flooding against wireless networks - attacks like the void11 wireless DoS. The log action has been extended to print the actual rate if it has been specified. Thus, for the curious, the simple event rule to detect any flooding of non-beacon management frames will be
hostap handle skip type management subtype ! beacon \ with log rate 100 / 5 sec(The "log" action will be triggered if there are at least 100 management frames, except beacons, within at most 5 seconds.)
All in all, the term "Proactive Wireless Monitoring" has been chosen to describe the advanced abilities of hostapd. It is fully functional and ready-to-use in OpenBSD 3.8; future work will concentrate on extending the IEEE 802.11f IAPP roaming support and event rule matching and action capabilities. Finally, hostapd is small, simple, and designed to be secure with privilege separation, OpenBSD principles, and a clean and reviewed code base.
A dedicated tutorial about wireless support in OpenBSD, including lectures and details about hostapd, will be held on the EuroBSDCon 2005 in Basel (Switzerland) on November, 25th.
reyk
(Comments are closed)
By Anonymous Coward (84.44.186.202) on
By Anonymous Coward (69.70.207.240) on
By Anonymous Coward (211.30.156.85) on
Great work, either way.
Comments
By Anonymous Coward (81.56.211.110) X on
By David (82.58.169.196) on http://www.openbeer.it/
After being the "Cisco-killer" os, OpenBSD will now be the "AirDefense killer" too!
This is truly amazing
By Jon (212.43.240.148) on
Anyway, sad that OpenBSD doesn't suit most corporate wireless networks (I mean, anything with windows clients) for ... security concerns !
The lack of WPA / i802.11i support is a really showstopper.
IPsec isn't of use there, since we lack l2tp support (then making windows hosts using IPsec isn't very straithforwared), and since most consumers hardware AP provides WPA support only (not IPsec).
So when one need to connect his OpenBSD box to a cheap hardware AP, he usually end up using the damn WEP "security" protocol. And when one need to connect to an OpenBSD based AP, he only has the option to use WEP or IPsec.
For now I stick to Linux or FreeBSD for software based Access Points at work, since both supports WPA. And only use OpenBSD wired (allowing WEP on a WPA network is reducing security to WEP for everyone).
On a side note, WPA (client) support is being added to NetBSD-current. So for one time, OpenBSD may be the last (if ever) to support a widespread standard network security feature !
Comments
By marco (140.99.30.238) on
windows and ipsec is entirely possible (w/obsd aps) and not too hard to do at all (/me wishes for openbsd-quality documentation from redmond though...)
(posted from xp, over ipsec, through an obsd ap ... )
but alas, i must apologize ... you expect everything from a $50 AP
Comments
By buckwald=USA= (144.171.241.10) on
Comments
By Mike (71.253.14.243) on
Comments
By Anonymous Coward (134.58.253.130) on
Comments
By Anonymous Coward (84.186.49.252) on
In order to get an official IP address and to get into Internet, all users are required to run a Cisco IPsec client on their boxes where people have to install personal certificates being given out by the administration. Student authenticate with their certificates and are then given public IP addresses from the university IP network. Linux and other OS'es IPsec clients should work as well.
Of course, this is a special environment with closed membership but it's an example where WiFi security standards and so on are not even being used because another layer of security is put on top of that.
Comments
By Anonymous Coward (203.26.16.66) on
By Anonymous Coward (82.82.158.60) on
IEEE 802.11i the IEEE wireless security standard (based on WPA2).
Both "standards", IEEE 802.11i and WPA2, are some kind of "official standards" and so most people think that they are good and you have to support them. Indeed, they are an imrovement to WEP but they're also full of bugs, industrial design faults and layer bloat.
Comments
By Mike (130.49.131.29) on
By Erik Carlseen (68.6.193.220) on
That being said, 802.11i (WPA2, TKIP, and 802.1x with certificate-based EAP) is going to be the corporate standard unless somebody comes up with a really amazing new exploit that blows it out of the water. I understand that OpenBSD is written for its creators and anyone else's needs are secondary (and if we don't like it, we can grind out our own code), but if broad usefullness and acceptance is any sort of secondary goal, then these standards should be supported if possible.
By Anonymous Coward (203.26.16.66) on
Comments
By Anonymous Coward (203.26.16.66) on
By Mike (130.49.131.29) on
By Lars Hansson (203.65.245.7) on http://mono.blogsome.com/
It's better then WEP but that's not really the point. As WPA becomes more common it would be really nice if I could use my OpenBSD laptop with available wireless hotspots.
By m00 (212.113.164.105) on
By Anonymous Coward (82.94.251.206) on
firefox doesn't support activex. until it does it will be nothing more than hobbyist ... as far as active content is concerned. sure, there are many other alternatives that would provide active content, but they are not straightforward and not the corporate standard.
Comments
By Anonymous Coward (87.78.7.85) on
and activex suxx, so? ;) just because everyone does it, doesn't mean it's done right.
if you want vrrp sleep with cisco. and activex.. hope you don't have too bad nightmares with intenetexplorer.
Comments
By Fábio Olivé Leite (15.235.153.98) on
By Anonymous Coward (192.48.245.20) on
Comments
By Anonymous Coward (203.26.16.66) on
By Anonymous Coward (212.43.240.148) on
As I believe that OpenBSD (or any OS) isn't ready of every purpose, like doing Oracle clusters (and it's not a bad thing), I think OpenBSD isn't ready for modern wireless networks. Not a bad thing, a fact.
windows and ipsec is entirely possible (w/obsd aps) and not too hard to do at all
By "not straightforward" I meant that ms pushes for l2tp, and attempt to discourage tunnel mode. A consequence is that's the l2tp option is far manageable when you have many machines (eg. you can even ask your end users to do it themself, or send simple scripts...).
An other example: having a layer two tunnel is often requiered (for dhcp, for netbios ...) but windows doesn't come with a tap driver or other things that would help to go over IPsec. Meanwhile l2tp+IPsec and WPA/WPA2 manages layer 2 traffic even on windows.
you expect everything from a $50 AP
By becoming the standard on wifi devices, pushed by industry on every new wifi hardware, WPA2 became the way to connect securely all your braindead equipments (windows desktops, PDA, ...). Face it.
It's not only a matter of AP, but all wifi'ed equipments, that could be, these days, cheap or tiny devices, with only 802.11g and WPA in common.
Comments
By Anonymous Coward (204.209.209.129) on
There are better things than a windows standards. Microsoft never gets it right, why would this be any different.
By Anonymous Coward (203.26.16.66) on
By m0rf (68.104.17.51) on
or if you must have WPA, port the wpa code from netbsd (or write your own) and try and get it included in base.
Comments
By Jon (212.43.240.148) on
Comments
By Anonymous Coward (193.167.7.13) on
o cut code from other os
o Paste code to OpenBSD
o Compile mixed code.
o Fix a few bugs
o Compile again
That's it!
Comments
By Anonymous Coward (195.224.109.30) on
By m0rf (68.104.17.51) on
Maybe you should just use some other OS and wait for others to do the work its too hard for you to do.
Comments
By Anonymous Coward (137.92.97.111) on
Comments
By Anonymous Coward (204.209.209.129) on
Microsoft is dominant because of the standards that they force upon other people and that way they relay fully on microsoft. This is no different.
By Lars Hansson (203.65.245.7) on http://mono.blogsome.com/
and maybe McDonalds is dominant because it provides really good and healthy food.
Comments
By tedu (64.173.147.27) on
> and maybe McDonalds is dominant because it provides really good and
> healthy food.
no, it's dominant because it's convenient (easy to use).
Comments
By Lars Hansson (203.65.245.7) lars@unet.net.ph on http://mono.blogsome.com/
By Anonymous Coward (203.26.16.67) on
Comments
By Anonymous Coward (203.26.16.66) on
By Lars Hansson (203.65.245.7) on http://mono.blogsome.com/
Aha, so what you're really saying is that you want WPA but you dont want to contribute anything whatsoever and you expect someone else to do all the hard work for you for free.
Comments
By Jon (212.43.240.148) on
I said I need WPA, so I use the proper OS/tools.
The whole point wasn't to "have someone else to do it for free", but rather intended for the potentials users: despite great efforts (like this one, hostapd, or on last year devices specs lobbying call), despite that OpenBSD is great for most things, don't get fulled and don't expect it to be well fitted for most modern wifi networks / use cases.
The goal of such websites is information, right ?
Comments
By m0rf (68.104.17.51) on
if you're aiming for security with 802.11i, then you should be implementing EAP-TLS. This requires the same public key infrastructure as using IPSec over those connections.
Of course you could go with that other "corporate standard" and use PPTP, like Google.
Comments
By Anonymous Coward (203.26.16.66) on
By Anonymous Coward (66.113.128.10) on
By Anonymous Coward (81.57.42.108) on
Also: can we inject raw frames through a 802.11a/b/g interface while in monitor mode ?
Comments
By Erik Carlseen (68.6.193.220) on