The SecureScout Wi-Fi Security & Monitoring Framework

Michael is a principal software engineer at Infiniroute Networks. He can be reached at [email protected].

What with daily reports of new security breaches, securing a network sometimes feels like working with a sieve. Often, these breaches are made possible when new technologies are adopted without enough "baking time" to ensure that they are secure. This, hopefully, is a situation we are all trying to avoid.

A great example of this is Wi-Fi (or 802.11). With Wi-Fi access, LANs are free from the physical confines of the cat5 cable. While there are some powerful security features provided by the 802.11 protocol (http://grouper.ieee.org/groups/802/11/index.html), they are not enough. And frankly, I prefer the approach best expressed by H. Stanley Judd: "The ultimate security is your understanding of reality." And the reality is that the current 802.11 protocol has weaknesses that can be exploited. Some specific security concerns within the 802.11 protocol involve illicit recording of packets, unauthorized LAN use, and attacks aimed at the Wi-Fi network. The good news is that there are steps you can take to protect the security and integrity of your network before it's too late.

What elevates the level of concern for Wi-Fi is its ubiquity. Wi-Fi can be found everywhere in home and business environments. Regarding security, though, it's perhaps best that you take a pessimistic view and assume that, when using Wi-Fi, your data is being broadcast for any and all to receive.

In this article, I show how attacks can occur on your network, and present a security monitoring framework that supports observation and actions based on specific types of attacks. This framework uses an extensible, scalable design that can be used to monitor specific security weaknesses. Beyond monitoring, this framework can be extended to support decision making and notifications of activity patterns of interest. In "Probing Network Characteristics" (DDJ, June 2004), I described a framework called "PerfScout" that enabled network performance monitoring by supporting specific triggering, monitoring, and actions based on network events. I've reworked this framework to support security monitoring, with the specific intention of watching for illicit listening on a network, monitoring for specific types of attacks, and to provide a means to analyze and act on these types of attacks. Layer 2 (802.11) and Layer 3 (IP) are the networking layers of interest here. To clarify the intent of the framework, I rename PerfScout to the more appropriate, security conscious name "SecureScout." (The complete source for SecureScout is available electronically; see "Resource Center," page 5.)

Just What Could Someone Do Exactly?

What can intruders do if they attack your Wi-Fi network? For one, shutdown your 802.11 bridge or access point (your connection between the wired and wireless medium). Attacks of this nature abuse specific 802.11 control messages (for instance, association, authentication, and duration messaging). Control messages within 802.11 are unencrypted, making an attack easier. This type of attack can result in effectively shutting down traffic to an access point. Attacks of this nature can even be launched from a PocketPC.

Intruders can also capture your LAN packets without your permission or knowledge. Again, you might want to consider your 802.11 network as a radio broadcast of your LAN data. Passive security concerns can be partially mitigated by data encryption (which is an optional feature of the 802.11 specification) with two types of encryption supported—wired equivalent privacy (WEP) and Wi-Fi protected access (WPA). Alas, WEP does not live up to its name and can be easily cracked (affording little protection). The newer WPA encryption Standard also has weaknesses, although it has not been cracked yet. Even if you consider encryption to be secure, it only takes a guessed username/password to unlock encrypted data. And if snooping does occur, all packets transferred via 802.11 can be assumed to be available to the unauthorized third party. And that's bad.

SecureScout Details

Figure 1 illustrates SecureScout's layout. Specific implementations of Sources, Tools, and Actions are shown within their respective processing blocks. Processing blocks are connected through events that flow from left to right via message queues. Message queues are owned by manager objects within the Tools and Actions blocks. Messages received by a processing block are then dispatched to the appropriate child implementation. Sources can trigger explicit one-time tests or can schedule tests to be performed on regular intervals—this allows for scheduled monitoring of a network, or focusing on specific hosts when needed. Tools can passively listen for events as they occur or actively probe the network. Finally, Actions capture, interpret, and act on collected and historical data. The Source, Tool, and Action blocks are designed to exist within a single executable, in separate processes, or on separate machines—the only change required is the transport between processing blocks. Even distinct implementations within a processing block can exist on separate hosts.

Figure 2 is the SecureScout object model. Timer events are configured through the TimerSource or TestSource object. The TimerSource listens for timer requests that can specify the test type, interval (in seconds), and a specific host (or all hosts) to monitor. The object then registers this request within the MonitorScheduler object and generates Test objects (or events) at the specified interval (until a stop request message is received by TimerSource).

Listing One is the header for the Test and ResultBase classes. The Test and ResultBase object are independent but related through the TestType enum. The test type and target can be set through the Test object interface. Result objects are generated within the specific tools and dispatched upwards (wrapped by the Test object) and out to the Action block for interpretation. Each Tool defines its result object implementation by deriving from ResultBase. Specific Results are interpreted within the Action processing block.

Test objects are created for specific tests (as opposed to PerfScout where multiple tests were specified within a single test object). All tools are designed to operate concurrently where each manages its own worker threads and sockets needed for sending/receiving data. Tools can query for specific security characteristics of a specific host or for all hosts. A common data store, called Hosts, is provided for tools to access the current set of hosts identified on the network and the time they were last identified. This information is used to help generate active tests of the network (as well as providing support for reporting). Three tools are provided with SecureScout: HostsTool, RawSocksTool, and WifiTool. All Sources, Tools, and Actions operate within their own message queue with the manager's responsibility of feeding test events and processing results.

Listing Two contains the main dispatch loop for ToolManager. For each Test object received via the input queue, the Test is queued for the requested test via ::get_test() and dispatched to the appropriately registered tool implementation via a put into the implementations queue.

Actions support storage of data for reporting as well as decision making (as defined by the implementor). A simple decision-based action monitors a threshold of a specific event (see SentryAction). It is important to note that the parent classes (SourceBase, ToolBase, and ActionBase) provide a base to develop specific behaviors based on the security need of the network.

Listing Three shows the main dispatch loop of the ActionManager. Upon receiving a Test object in its queue, this test object is dispatched to all registered Action implementations via the STL for_each() method. The Test object is cloned for each Action implementation within the Dispatch::operator() method. The Action implementations are responsible for releasing the respective clone of the Test object. Access within the ::run() method is guarded by a mutex to prevent an action implementation from being unregistered while the ActionManager is dispatching Results for processing.

IP Layer Vulnerabilities and Strategies

Passive sniffing of network data is a concern in the IP layer. Packets are flying through the air sometimes with little to no encryption (or, even worse, guessed username/password). It might be a good idea to consider monitoring all connected hosts on your LAN. You should be concerned with hosts that you do not recognize or hosts that have raw sockets open on your network. Raw sockets can be bad in the sense that they capture all traffic on the network, not just packets destined for the specific host.

Identifying hosts on the network can be accomplished through a simple technique. The approach is to broadcast a simple icmp (ping) packet to the broadcast address of the LAN. The broadcast address is the inverse of the mask applied to the network:

broadcast address = (network address | ~mask)

All hosts should respond to the broadcast echo request with an echo reply (but, in fact, not all do). The HostsTool object, derived from ToolBase, is designed to actively query for responding hosts on the network, each response generates a new or updated entry in the Hosts object along with the time of last response. The responsibility of the HostsTool is to find systems that have joined the LAN and have listening sockets. Other techniques can be employed to identify hosts, such as passively monitoring traffic for source and destination IPs within the network.

The RawSocksTool, also derived from ToolBase, is the second tool that operates on the IP layer. This tool is designed to find raw sockets within the LAN. Raw sockets can be used to snoop all traffic on the LAN. Identifying raw sockets involves a bit of trickery in spoofing an ARP packet to use an incorrect MAC address; in this case, only a raw socket will respond to such a request. These requests have to be built up from the Layer 2 level (MAC) to incorrectly address the MAC address, but set the correct IP address. This probe works because all sockets except raw sockets filter our incorrect MAC address (no MAC filtering is applied on raw sockets). So, the ICMP packet continues to travel up the stack and generates an echo response—which is sent and received. A response (in this case, indicating a raw socket) may be cause for concern.

As a general policy, most programs do not need or require raw sockets and you can be sure that, if you receive any response of the sort, further investigation is needed—perhaps there is illicit packet snooping.

802.11 Vulnerabilities and Strategies

Layer 2 represents the direct host to host transport. For 802.11 wireless transmission, this usually involves communication between a host and an access point. Access points act as bridges between the wired and wireless world and also often contain a switch and WAN access. At the bridge, wireless packets may be converted to Ethernet (or some other Layer 2 protocol) to allow for propagation to the specified destination.

802.11 is complex. But with complexities come vulnerabilities. Granted, the problem 802.11 solves is much more difficult than a wired connection. But vulnerabilities exist and security concerns generally have to do with malicious hosts taking advantage of control messages within the 802.11 protocol. The goal of SecureScout at this layer is to monitor, identify specific types of attacks, and perform notification or other corrective actions.

Consider this hypothetical scenario: An intruder writes a Trojan horse virus that infects wireless hosts. The Wi-Fi card on this infected host searches for and attacks in-range networks. Obviously, the owner of the laptop has no knowledge of this and even doesn't have access to these networks. So, whenever this infected host is near an access point this access point could be taken down. The troubling aspect of this scenario is that it would be difficult to identify an infected host, as this host is not part of the network.

For instance, Figure 3 shows a simple example where a host attempts to associate with an access point. The host, or client, requests authentication access and, therefore, an authentication request to the access point. The access point sends an authentication acknowledgement upon successful authentication. This is followed by an association request. When the client receives an association acknowledgement, the client is allowed to start transmitting data. However, a malicious host could simply monitor for authentication requests and generate a simple spoofed deauthentication request following the association acknowledgement. The access point deassociates the client and shuts down access to the host, while the host transmits data to the access point. So, for every five packets (as in Figure 3) generated by the valid host and access point, only a single packet need be generated by the malicious host to terminate communication between the host and the access point.

Another related attack—the deauthentication attack—is slightly more sophisticated in that it requires the timing of the attack to occur after authentication and before association (see the timing of control messages in Figure 3). Data associated with both deauthentication and deassociation are collected by WifiTool, which has a listening socket and collects this data for reporting and analysis by the Action processing block.

Yet another weakness in the protocol arises where hosts can request a dedicated communication duration. This control message requires all other hosts to refrain from communication for the requested duration. The duration field is defined in microseconds and is 2 bytes in length, thereby allowing a reservation of 32 milliseconds. Each host in turn sets their Network Allocation Vector (NAV), which requires each host to count down to 0 before hosts can resume dispatching packets. A rogue host using this approach would be required to only transmit approximately 30 times per second to prevent access to the access point. This attack would greatly diminish the available bandwidth between all hosts and the access point.

The WifiTool object passively monitors deassociation, deauthentication, and duration control messages. This tool associates source MAC address to these events and time of occurrence. Upon receiving a test event source, all events since last offload are inserted into the Test object and pushed into the ToolManager completion queue contained within the ToolManager::CompleteTask object. The CompleteTask object has access to the Action queue and puts the Test object (containing the result) into the Action queue. Results are dispatched to each Action implementation within the action block (Listing Three). The control message table within WifiTool is now reset for a new monitoring cycle. WifiTool only requires a single listening socket that passively captures these specific messages. Obviously, a large number of these control messages within a short period could indicate an attack against the protocol. It may even be possible for the SentryAction object (Action implementation) to act on this data and shutdown access for the specific MAC address. Reacting to this data by the SentryAction requires designing frequency and thresholds for these control messages.

In all cases, data from tools are transported to the Action block for historical storage (StoreAction) and for interpretation where thresholds are set for specific attack types (SentryAction). Further work can be performed in the SentryAction for additional interpretation of types of attacks.

Conclusion

It certainly is possible to monitor for specific types of intrusions within your network, particularly through gaps in security exposed via 802.11. It may, at times seem a losing battle, but given the sensitive and valuable data that is now traversing wireless LANs, it is incumbent upon us to be aware of and to react to potential network penetrations.

DDJ

Listing One

/*******  Result  ********/
class ResultBase
{
public:
   /* Constructor and Destructor */
   ResultBase(TestType type) : result_time_(0) {;}
   virtual ~ResultBase() {;}
   /* cloning operation */
   virtual ResultBase*
   clone() const = 0;
   void
   set_result_time(unsigned long time) {result_time_ = time;}
   unsigned long
   get_result_time() const {return result_time_;}
private:
   unsigned long result_time_;
};
/******* Test ***********/
class Test
{
public:
public:
   /* Constructor and Destructor */
   Test(TestType type) : test_type_(type), target_(0) {;}
   ~Test();
   /* Copy Constructor */
   Test(const Test &test); //copy constructor
   /* Assignment operator */
   Test& operator=(const Test &test); //assignment operator
   /* Returns target host */
   unsigned long
   get_target() const {return target_;}
   /* Sets target host */
   void
   set_target(unsigned long target) {target_ = target;}
   /* */
   TestType
   get_test() const {return test_type_;}
   void
   set_result(const ResultBase *result);
   ResultBase*
private:
   TestType test_type_;    //type of test to perform
   unsigned long target_;  //target address, 0 means all
   ResultBase *result_;    //result to be returned to action
};

void
ToolManager::run()
{
   ToolBase *tool_base;
   cout << "ToolManager::StartTask::run(), starting..." << endl;
   while (true)
   {
      Test *test(get());
      if (test != NULL)
      {
         //find tool for test type
         tool_base = getTool(test->get_test());
         if (tool_base != NULL)
         {
            //dispatch to tool for processing
            tool_base->put(test);
         }
         else
         {
            //not found. delete.
            delete test;
         }
      }
      else
      {
         cout << "event is null..." << endl;
      }
   }
}

/** Dispatch support class. Definition/implementation for Test distribution */
class Dispatch : public unary_function < Test, void >
{
public:
   //constructor
   Dispatch(Test *test) : test_(test) {;}
   void operator() (ActionBase *action)
   {
      //put copy of test into each registered action
      action->put(new Test(*test_));
   }
private:
   Test *test_; //pointer of test to distribute
};
/** ActionManager::run(). Manager test dispatching thread **/
void
ActionManager::run()
{
  while (true)
   {
    GUARD(&mutex_);
    //block until new test and result are received
    auto_ptr<Test> test(get());
    if (test.get() != NULL)
     {
     //dispatches copy of results to each registered action
     for_each(action_coll_.begin(), action_coll_.end(), Dispatch(test.get()));
    }
  }
}