In our implementation, we have adapted the snort IPS [46] to run on OpenWRT. While previous implementations have used snort to filter traffic between the wireless network and the external ethernet connection, our implementation disables the normal low-level wireless-to-wireless forwarding and uses ebtables and IPtables to redirect traffic through userland where it can be processed by snort.
As APs typically have limited computing resources, it may not be possible to have a fully fledged IPS running on them. Increasing their capabilities may also be prohibitively expensive. There are at least two possible options to address this problem. The first option is to use only a subset of the signatures, most likely signatures for attacks against vulnerabilities that may not be universally patched yet. The second option is to implement the IPS functionality in a centralized wireless controller, and have the APs forward all local traffic for inspection before retransmitting to the wireless medium.
The main advantage of using a wireless controller is that it provides flexibility for devoting more resources to traffic inspection. It is also consistent with industry trends towards cheap, "dumb" access points managed by a wireless switch. However, none of the wireless switches we are aware of provide any filtering capabilities for internal WLAN traffic such as wildfire worms. In our case, the additional wireless-to-wireless IPS functionality is implemented as a standalone wireless controller. This functionality can be retrofitted into wireless controllers or implemented as part of a secondary controller - protocols for AP to controller communication are being standardized, and thus interoperability is likely to be achievable.
For zero-day attacks for which there are no signatures, we rely on honeypot feeds from access points back to an analysis center. There, we use the Argos system [45], which uses dynamic taint analysis to trap the execution of remotely-injected code, for detection coupled with our custom signature generation system. Our system collects packet trace samples corresponding to the exploitation attempts detected by Argos and then uses a heuristic for generating network-level attack signatures in the form of simple patterns. The heuristic tries to identify a substring that is sufficiently large, sufficiently frequent in the attack samples and sufficiently infrequent in benign traffic. This last part is important for addressing concerns about false positives as well as attempts to manipulate signature generation for denial-of-service purposes. Our implementation uses a novel inverse indexing scheme on previously collected packet traces. While in our test setup these traces are maintained centrally at the threat center, it is conceivable that such testing can be performed at each site independently. These signatures are then installed on the AP or the wireless controller as snort sensor rules.
Filtering of internal WLAN traffic assumes that the worm does not tamper with the wireless device driver and firmware. If such tampering is possible, the attacker may spoof access point transmissions directly - for which tools are publicly available [9], and bypass filtering mechanisms applied to traffic relayed over the AP. The AP can detect attempts to impersonate it as long as it can pick up the messages sent by the attacker, but this leads immediately to another attack scenario: the attacker can hide his emissions from the AP by tuning the wifi radio power or using directional antennas so that the spoofed packets can reach the victim, but cannot reach the AP (or external detection device). We refer to this as the whisper attack. The attack seems difficult to engineer, as it requires both the low-level driver/firmware hacks of the basic 802.11 spoofing attack, as well as careful tuning of the radio. Unfortunately, newer chipsets provide improvements in power control, and it is likely that the attacker can easily find the "right" power setting to launch the attack by probing both the victim and the AP with different power settings, all controlled through the driver API. In some cases, the relative positions of AP, victim, and attacker may prevent this attack. In addition, not using an AP to relay frames limits the communication range. Using power control to evade the AP may limit the range even further, to the point where it may become impractical to perform whisper attacks in the context of the massive attacks we discussed.