WHIFF – Wireless Intrustion Detection System

A project by Foundstone®, Inc.

and Carnegie Mellon University

Christopher R. Ameter • Russell A. Griffith • John K. Pickett

CMU Faculty Advisor: Chris Prosise, Foundstone Inc.
WHIFF

A Wireless Intrusion Detection System

Developed by Foundstone, Inc. and Carnegie Mellon University

This paper presents an overview of the Whiff Intrusion Detection System, which was developed during the
summer and fall of 2002 by a team of graduate students majoring in Information Security and Assurance at
Carnegie Mellon University. The project was a collaborative effort between Carnegie Mellon and
Foundstone, Inc. The experience and knowledge gained during this project will enhance and refine future
versions of Foundstone’s industry leading security software.

Whiff is a system that solves several current, real-world wireless security problems. Whiff identifies and
monitors wireless networks and devices, alerting administrators to exposures in real time. Whiff is
comprised of multiple listeners which monitor all wireless activity and report to a central correlation engine.
The correlation engine delivers to multiple users a complete asset inventory of wireless devices and access
points as well as a GPS map of signal propagation. The system integrates intrusion detection capabilities,
alerting administrators to wireless and traditional intrusion attempts, rogue access points, and rogue clients.

This document details Whiff’s features and functionality. We believe that the capabilities demonstrated in
Whiff will provide needed security solutions to organizations implementing wireless networks.
TABLE OF CONTENTS

Introduction 1

Scope and Objectives 2

Background 3

Solution 4

Detail 5

Conclusions 21

Resources 22
Introduction

During the spring of 2002, a team of Carnegie Mellon University graduate students majoring in Information
Security & Assurance became concerned about the lack of security on wireless networks. They perceived the
need for a wireless intrusion detection system that could keep administrators informed about what was
happening on their network. At about the same time, Foundstone, Inc. approached Carnegie Mellon with a
proposal to work together to develop such a system. Throughout the summer the Carnegie Mellon students
conducted studies of wireless networks and found many lacked the basic configurations necessary to provide
even minimal levels of security. In August development work began, and over the next four months the three-
member graduate team, assisted by a member of Foundstone, devoted 90 hours a week to the project.

Using standard methodologies developed by Carnegie Mellon and Foundstone, the team developed Whiff, a
wireless intrusion detection system that provides network administrators with constant security reports,
allowing them to make informed security decisions.

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 1

Scope and Objectives

This white paper focuses on the security features of Whiff. It describes the system’s purpose, how it works
(including collection methodologies, reporting mechanisms, and underlying security architecture), and how it
can be used to improve wireless network security. We also provide references for those who wish to read more
about the tools and technologies used.

This project is not intended to be the "silver bullet" that dramatically increases the state of security of wireless
networks. Identification of intruders is an important step toward that goal, but it is only one part of a larger
effort. The overall security of a system involves blending many technical components with sound policy to
create a total package.

Our goal is to provide administrators with an image of what is happening on their network. Armed with this
information, they will be able to make better decisions and take actions to improve network security.

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 2

Background: Problems with Wireless Network Security

In the early days of local area networks security was addressed by controlling physical access to facilities, and
insiders were the primary threat. With the advent of the Internet and the adoption of wide area networks,
administrators were forced to defend their network not only against those with physical access, but against the
larger community of people with Internet access or even just modems. Hackers began using automated scripts
to call phone numbers at random, searching for modems through which they could access networks. This
became known as “war dialing.” Still, attackers had to enter the network from a known point, such as a
telephone number or IP address, making them at least somewhat traceable.

In recent years an entirely new class of attacks has emerged. Proliferation of wireless technologies has enabled
attackers to enter networks, quite literally, out of thin air. Using simple, free software, a new generation of
hackers is able to locate wireless networks, eavesdrop on communications, and commandeer resources. The
practice of wandering around in search of wireless networks is referred to as “war driving,” which is a play on
the earlier modem discovery technique. With the proper antenna, the attack can come from as far as several
miles away. Thus detection and identification of the intruder presents unique challenges which render many
traditional intrusion detection techniques ineffective.

Compounding the problem is the fact that the 802.11b wireless Ethernet standard contains fundamental
security vulnerabilities. Recognizing that eavesdropping is an inherent problem in any wireless system because
of the inability to control the propagation of radio waves, the designers of the standard included WEP, the
wired equivalent privacy protocol, in 802.11b. WEP is a layer two security protocol that employs the RC4
encryption algorithm. While the algorithm itself is sound, the implementation is flawed, allowing WEP to be
broken in a matter of minutes. To a determined attacker, it is a mere inconvenience.

Traditional network security models rely heavily on perimeter protection. Administrators of wireless networks
must recognize, however, that many attacks originate behind these outer defenses. Much of the security must
therefore be handled at the host and application levels.

Solid host security and higher level encryption protocols such as IPSec address many of the vulnerabilities
introduced through the use of wireless networks. Still, if network administrators are to make informed security
decisions, implement sound policies, and deploy available security technology effectively, they must be able to
identify wireless assets, monitor network activity, and detect intruders.

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 3

Solution: WHIFF Wireless Intrusion Detection System

Whiff dynamically creates and reports a complete asset inventory of wireless devices, detects the presence of
rogue wireless clients or access points, detects wireless and traditional intrusion attempts, and alerts
administrators to exposures.

Alerts

Whiff includes one or more “listeners,” which continuously monitor all wireless activity in their vicinity and
report back to a central correlation engine. The listeners generate four classes of alerts:

• Rogue access points

• Rogue clients
• Traditional IDS alerts
• Wireless-specific alerts

Rogue Clients and Access Points

Rogue clients and access points are identified by detecting the presence of MAC addresses not included in a
“known good” list. The list of known access points is updated periodically by the correlation engine. Upon
detection of a rogue MAC address, the listener generates an alert, which it transmits to the correlation engine.
The engine filters all incoming alerts (removing duplicates), loads a record of the alerts into a database, and
notifies administrators via e-mail.

Traditional IDS Alerts

Traditional IDS alerting is facilitated through the use of Snort, an open source intrusion detection system.
Snort definitions may be customized and prioritized based on the needs of a specific environment. Traditional
IDS alerts are collected by each listener and periodically transmitted back to the correlation engine, where they
are sorted in a manner similar to that of the rogue MAC alerts and added to the database.

Wireless-Specific Alerts
Wireless-specific alerts are a function of the Kismet wireless sniffer, an open source program upon which much
of this project is based. Wireless-specific alerts are generated by conditions matching special signatures that
would arise only in a wireless network, such as the presence of a NetStumbler probe. Wireless-specific alerts
are handled in a batch fashion, just like traditional IDS alerts.

Web Interface

In addition to automated e-mail notifications, alerts may be viewed through a web interface on the correlation
engine. The web interface may also be used to update configuration files automatically distributed to the
listeners, view various statistics regarding the status of the network, configure administrator accounts, add
MAC addresses to the “known good” list, and view a propagation map displaying the wireless network
footprint. Communication with the web interface is secured through certificate-based authentication and SSL
encryption.

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 4

WHIFF in Detail

Architecture

The components of the Whiff system architecture were selected to provide the best possible functionality, given
a number of technical and financial constraints. These constraints included the need to limit the amount of
additional strain on the network and to make any machines and traffic added to the network as secure as
possible. While our goal was to achieve a technologically superior solution, we were also heedful of the need
to minimize hardware requirements and software expenditures.
The Whiff architecture comprises the following four modules, diagramed in Figure 1 (page 8):

• Listener
• Notification
• Correlation
• Interface

Listener
The listeners act as continuous collection points for wireless data. These machines passively monitor 802.11b
traffic within antenna range and report a variety of anomalies back to the correlation server.
Our listener implementation consists of standard PCs and laptops using either a Lucent Orinoco or Prism II
based wireless card, although almost any card capable of running in monitor mode would work. These
systems run a standard installation of Redhat Linux 8.0 and primarily use two excellent and freely available
software packages, Kismet and Snort. Access to open source was invaluable to the success of this project, as it
was necessary, for example, in the case of Kismet, to add some reporting features to the software.

Kismet operates by placing wireless cards in monitor mode and then continuously hopping between 802.11b
channels to gather data throughout the entire used 2.4GHz spectrum. Unlike standard packet sniffers, such as
TCPDump and Ethereal, Kismet is also able to monitor level II wireless traffic, including 802.11b management
frames and packets (Probe Request, Probe Response, Beacon Frame, etc.).

Kismet simultaneously records GPS data, which is later used by the interface module to produce signal
propagation maps. Theoretically, mobile listeners could be set up using any NMEA GPS or GPSD software
package. Because Whiff listeners are relatively stationary, however, and would likely be placed inside
buildings, usually out of satellite range, a GPS might not work. To deal with this limitation, we developed a
GPS simulator, GPSDork, which simulates the NMEA GPS signals at any given latitude and longitude.

To limit bandwidth usage, much of the initial processing is performed on the listeners, with only anomalies
and summary data reported to the next module, the correlation engine. The data collected by Kismet is
analyzed in real time to watch for a variety of suspicious activities, as described in the Alerts section above.
The TCP/IP traffic is then passed through Snort, a signature based IDS, to watch for any malicious activity on
the wireless network.

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 5

All of these actions are orchestrated through a series of Perl scripts, which ultimately transfer the processed
data to the correlation engine. For security reasons, the listeners do not allow any incoming connections, and
simply push the data back to the server at set intervals. System configuration files for the listeners may be
changed through the web-based interface module, which the listeners periodically inspect for changes and use
to update themselves as necessary. All communications with the listeners are authenticated and encrypted
through a certificate-based SSL connection. This is accomplished with cURL, using HTTP PUT commands to
a special uploads directory on the Apache web server.

Correlation
The correlation module receives data from the listener and processes it into a series of MySQL tables for use
by the interface module. If there are multiple listeners, the Perl scripts first compare all of the alerts and
eliminate duplicates. They also throttle the alerts to prevent excessive e-mail messages from being sent to the
administrator. (Related alerts in rapid succession are grouped into a single alert for notification.)

If a rogue client is detected, a correlation script determines if the client has associated itself with the network.
If the client has been assigned an IP number, the script launches an Nmap port scan and attempts to determine
the host operating system. This information, which may aid in tracking down the rogue host, is delivered to
the administrator as part of the alert notification and is also entered into the database.

A second benefit of the Nmap scan is that it serves as a “shot across the bow,” letting possible intruders know
they are being tracked. If an intruder were running a personal firewall, they would probably be notified that
they are being port-scanned, which might encourage them to look elsewhere.

The correlation script then uses GPSMap to build a propagation map from the GPS and wireless network data.
The display characteristics of this map are configurable in the interface, as shown in Figure 8.

Finally, the correlation scripts archive all of the data, ensuring that in the event of a major security incident,
administrators have full access to a detailed history. In the case of signature-based (Snort) alerts, the archive
includes any suspicious traffic in TCPDump format, which allows much more detailed analysis than the alert
description. In a production environment this data would probably be moved to offline backup media, as it is
not directly accessed again by Whiff.

Our correlation engine is implemented on a pc server running Redhat Linux 8.0 (minimum specifications in
Figure 1). The correlation, notification, and interface modules all reside on this machine, so there is significant
overlap in both scripts and system software. The primary software packages used for correlation and
notification are the MySQL relational database, the Apache Web Server, GPSMap, Nmap, and OpenSSL. All
are open source and freely available.

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 6

Notification
The notification and correlation modules are conceptually distinct but technically intertwined. The function of
the notification script is to gather alert data from the correlation processes and deliver it to an administrator in
real time. If the administrator does not care about real-time alerting, this module can easily be disabled, as all
of the alert information is also available in the web-based interface.

The notification module may be configured to enable or disable Nmap scans and can deliver messages to any
e-mail address or administrator list. Alert messages are simple and text based, so they display correctly on a
pager or wireless PDA. Administrator notification requires access to an SMTP mail gateway for delivery of e-
mailed alerts. We have not discussed implementation of an SMTP server in our architecture, as most
organizations have one in place or have access to one through their ISP. A sample e-mail alert is shown in
Figure 2 in the Features discussion below.

Interface
The interface module provides a web-based console to view alerts, IDS incidents, and rogue clients and access
points. It also provides a wide variety of detail views and allows administrators to tag or add comments to
alerts following investigation. They can also add rogue devices to the “known good” list. Access to this system
is secured by a certificate-based SSL connection, coupled with a username/password login.

This module, which resides on the same correlation server, dynamically generates Whiff views from the
MySQL database through a series of PHP scripts. These PHP scripts also make it easy to change data or
remote listener configurations from the administrator console. Configuration changes are saved to files on the
server, where they are read by the listeners during each reporting interval.

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 7

Figure 1 - Whiff Modules and Architecture

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 8

Features

In designing Whiff, our goal was a feature set that would not only enhance the overall security of networks,
but would also make the network administrator’s job a little easier. While this feature set is by no means
complete, we feel it includes appropriate functionality for an initial implementation.

Reporting
Like any other IDS, Whiff generates a great deal of data; one of the biggest design issues was how to best
present this data to users. We chose a web-based interface for its consummate lightness and portability, being
accessible from any browser. The Whiff homepage provides a single place for administrators to view up-to-
the-second wireless network activity, including the most recent alerts of each type, signal propagation, and
current status of each listener.

Figure 2 - Whiff Home Page

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 9

Rogue Access Points
As the cost of wireless access points falls and the desire for convenience and mobility climbs, so too does the
likelihood of one or more rogue access points appearing on a network. Rogue access points pose a serious
threat to the security of networks, as they are likely to be located behind the firewalls erected to keep intruders
out.

Whiff presents a partial list of rogue access point alerts on its homepage and a full list on the Rogue APs page,
both of which link to more detailed information. At the detail page administrators can add comments to an
alert and change its status to “in-progress” (being looked into) or “closed” (no longer displayed in the
interface). They can also add the MAC of the rogue access point to the “known good” list, which is then
pulled from the server by listeners during each reporting period.

Figure 3 - Rogue Access Point Detail

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 10

Rogue Clients (including OS Identification)
Wireless networks offer the advantage of allowing users to move freely around a facility while maintaining
network connectivity. While this convenience makes life easier for users, it also makes life easier for intruders,
who can gain access to the network simply through a handheld device, wireless card, and software freely
available on the Internet.

Whiff detects rogue clients and lists them on both the homepage and Rogue Client page. Clicking on an entry
in the list takes administrators to a detail page, which displays the rogue client’s IP address, operating system,
and open ports (captured through Nmap scanning).

Figure 4 - Rogue Client Detail

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 11

Traditional IDS (Snort-based)
Whiff employs the Kismet wireless sniffer, along with Snort, to provide traditional (layer 3) intrusion detection
support for wireless traffic. This is necessary because the IDS already in place on the wired network cannot be
relied upon to pick up all wireless attacks. In cases where wireless traffic does not touch the wired network—
for example, where a wireless client is attacking another wireless client on the same access point or where an
access point has been compromised and is being used against its client base—additional protection is required.

Similar to Whiff’s other reporting features, Snort-based alerts are presented in two places: the homepage and a
Snort Alert page. A unique feature, however, is that Snort-based alerts are sorted by priority level, with higher
priorities listed first. Detailed information necessary to determine what happened, when it occurred, and who
was involved can be viewed by clicking on any alert in the list. Among the detail available is attack signature
and class, source and destination IP address and port, and links to reference information. The actual data that
triggered the alert is, of course, archived for further analysis if required.

Figure 5 - Snort-Based Alert Detail

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 12

Wireless-specific (Kismet-based)
In addition to traditional signature-based alerts, Whiff uses the Kismet wireless sniffer to analyze wireless-
specific (802.11b), generally layer 2, traffic. This type of alert is generated by Kismet when it sees specific
frame signatures, including those of some popular wireless discovery tools such as NetStumbler and
Wellenreiter. These tools can be detected because their method of network discovery involves broadcasting
beacon frames, which anything listening, including Kismet, can hear. Whiff can also generate wireless-specific
alerts by scanning for vulnerability in access points caused by software that responds to broadcast queries by
echoing back administrative information.

These alerts are displayed along with the other alerts on the Whiff homepage and can also be viewed on the
Kismet Alerts page. By selecting an individual alert, administrators can view a description of the “attack,”
including the source MAC and, in some cases, IP address. As with other alert types, comments can be added
and status changed as each alert is handled.

Figure 6 - Kismet-Based Alert Detail

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 13

Network Status (APs and Clients)
In addition to the alert reporting described above, Whiff enables system administrators to view both access
point and client-specific information. The Access Point page displays the most recent access point data from
each listener, including MAC address, service set identifier (SSID), WEP usage, reporting listener, broadcast
channel, and manufacturer. Selecting the desired MAC address link displays details for that access point,
including a breakdown of packets seen and a list of associated clients (see Figure 7).

The packet breakdown can be used to monitor the state of the wireless network, determining under- or over-
used segments. Knowing which clients are associated with each access point is also useful in troubleshooting
and locating rogue clients.
From the access point detail page, additional detail can be viewed by selecting the desired client MAC.
Available client data includes configuration information similar to that provided for access point detail as well
as IP address and the means by which the client was identified.

Figure 7 - Whiff Access Point Detail

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 14

Graphical Signal Propagation
One of the security risks inherent in wireless networks is the propagation of wireless signals beyond the walls
of the organization. While it is difficult to determine with precision the reach of a wireless network, it is
possible to come up with an estimate based on network factors such as signal strength and GPS-based point
data.

Whiff uses the Gpsmap utility to generate a graphical representation of the wireless signal propagation. This
propagation map is displayed at a reduced scale on the homepage and at full size on the Signal Propagation
page.

Some of the Gpsmap provisions for displaying network propagation may be more accurate than others
depending on network-specific factors. For this reason, we’ve implemented a Propagation Configuration page
(see Figure 8), which allows system administrators to test and update default Gpsmap options.

Figure 8 - Whiff Propagation Configuration

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 15

Listener Status
Continuous reporting of activity from listeners is essential to Whiff performance. The homepage therefore
includes a display of the current status of each listener, including its name and a “Last Reported” timestamp.
Administrators can also access a full history of the listener’s reporting times to make sure it is functioning as
expected.

Notifications
In addition to providing alert reporting through the web interface, Whiff generates notification emails that
report details on the combined alerts from all listeners.

Real-Time
Occasionally system administrators may not have access to the web interface but still need to know what is
happening on their network. A real-time notification mechanism fills this need. Each Whiff listener sends real-
time alert data to the server, where the correlation engine refines the data, eliminating any redundant alerts
from overlapping listeners. Notification e-mails currently report all alerts except traditional IDS alerts
(see Figure 9).

Figure 9 - Whiff Notification Email

This is an automated intrusion notification.

WARNING: Unknown CLIENT detected!!

MAC: 00:02:2D:5D:24:00
AP: 00:60:1D:F2:05:00
IP: 128.2.69.000
OS:
Ports:

WARNING: Kismet alert detected!!

NetStumbler (3.23) probe deted from 00:02:2D:05:64:00

WARNING: Unknown ACCESS POINT detected!!

SSID: 00:05:3C:04:2C:00
MAC: 00:60:1D:23:C3:00

WARNING: Unknown CLIENT detected!!

MAC: 00:02:2D:0F:38:00
AP: 00:60:1D:F2:05:00
IP: 128.2.64.000
OS:
Ports:

This concludes this intrusion notification.

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 16

Centralized Administration
The majority of Whiff installations will be of a distributed nature with multiple listeners reporting back to a
single server. Manageability issues with this type of architecture make centralized administration a key system
requirement.

Whiff User
Whiff user administration is performed through the web interface, with user data, including hashed passwords,
stored in the user table of the database. As illustrated in Figure 10, administrators can add or remove users, or
update user information, such as changing the associated group.

Figure 10 - Whiff User Administration

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 17

Whiff Listener
Each Whiff listener has its own identity, defined through its configuration files. Whiff also provides a number
of configurable time-interval-based options, which can be tweaked during initial setup to suit specific network
needs. While configuration files, once set, generally remain fairly stable, the distributed nature of Whiff
suggested the need for an easy method of making changes. The system therefore includes a Listener
Configuration page, which allows administrators to modify all configuration file from a single interface.
Updated files are subsequently pulled from the server by the appropriate listener.

Figure 11 - Whiff Configuration Administration

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 18

Security

Whiff, a security tool for wireless networks, also incorporates features that enhance its own security.

• Certificate-based User Authentication

The wealth of information Whiff provides about the wireless network should not be available to just
anyone. The Whiff web server restricts access by performing user authentication based on client certificates
distributed only to valid parties.

• Certificate-based File Transfers

Whiff’s centralized listener configuration, data storage, and notifications require sensitive files to be
transferred between listeners and the server. Client certificates are used to authenticate listeners when they
attempt to connect to the server to pickup configuration updates or deliver network and alert data.

• Role-based Security
Whiff offers role-based security to ensure that users with different functions have access to only those
features they need to do their jobs. (Currently the database and user administrative roles have been
implemented.)

Possible Enhancements
A number of desirable features emerged during the development and testing of Whiff. Some of those that
didn’t make the cut for the first version include:

• Trend reporting
• Known-but-not-ours MAC list
• Extended client OS identification

Trend Reporting
The addition of trend reporting to the Whiff web interface would provide system administrators with the
ability to track activity on their wireless network over time. Examples of such activity include the number of
clients associated with any access point, occurrences of alerts, and overall wireless traffic. Tracking client
counts and wireless traffic in this way would enable system administrators to make informed decisions about
tuning and upgrading wireless networking equipment. It could also help administrators and security experts
better understand network attackers. The more known about the opponent, the greater the likelihood of
ultimately gaining victory--historical tracking is a step toward this goal.

Known But Not Ours MAC List

During the course of our testing we noticed that we were continually receiving rogue client alerts for access
points not on our test network. As wireless networks proliferate, overlapping wireless signals become more
likely, creating the problem of distinguishing one’s own network from one’s that of one’s neighbor.

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 19

This issue pertains to both access points and clients, and is currently being handled by adding the MAC
addresses of each to our “known good” list. As we quickly found out, this solution is less than optimal, as
the administrator may be flooded with rogue client alerts, each of which must be verified.

Our suggestion for a more workable solution is to add a list of “known but not ours” access point MAC
addresses. This would allow system administrators to verify only the whereabouts of rogue access points,
programmatically disregarding all clients associated with them.

Extended Client OS Identification

Whiff currently identifies rogue clients by validating clients on the network against a list of “known good”
MAC addresses maintained by the system administrator. This procedure, however, doesn’t provide a means of
identifying clients that may be spoofing the MAC of a known client. Such an attack may not be as unlikely as
it seems, given that it’'s trivial for attackers to sniff known MAC addresses out of the air and update their
wireless settings accordingly.

As discussed previously in this paper, Whiff supports limited Nmap scanning of rogue clients for the purpose
of identifying and reporting the open ports and operating system of the offending system. One way to
overcome this spoofing shortcoming is to perform more extensive client scanning, essentially maintaining
system status for each client. Scanning would take place at a specified interval, and the results would be
compared with historical data for the corresponding client, with alerts generated if “too much” has changed.
(Both scanning interval and change threshold would be configurable.)

All of this presupposes the resolution of a number of outstanding issues with extended client identification.
Work needs to be done, for example, on handling dual or multi-boot machines, retrieving system status for
machines with personal firewalls, and preventing scans from being picked up by IDSes.

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 20

Conclusion

Throughout the project, the extent of the problems with wireless network security became increasingly
obvious. During a half-hour “war drive” around Pittsburgh, the project team uncovered 484 wireless access
points; 364 of which were not even running WEP, and many with default configurations.

Even more frightening is the fact that while beta testing some of Whiff’s alerting features at home, one team
member was notified of an unknown client on his home network. Initially expecting a false positive, he
checked his access point logs and found that an intruder was indeed present. Upon being port scanned, the
intruder immediately disconnected from the network, never to be seen again.

Clearly there is an urgent need to gather information about what is happening on wireless networks. Whiff
provides a picture of the boundaries of a wireless network, the devices connected to it, and the traffic flowing
over it. While identification of attacks and vulnerabilities is only one part of an overall security plan, it is a
critical first step in the effort to improve wireless network security.

The experience and knowledge gained during this project will enhance and refine
future versions of Foundstone’s industry leading security software.

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 21

Resources

Kismet http://www.kismetwireless.net

MySQL http://mysql.com

Apache http://httpd.apache.org/

PHP http://www.php.net

O’Reilly Perl.com http://www.perl.com

cURL http://curl.haxx.se

Nmap http://www.insecure.org/Nmap/

Foundstone http://www.foundstone.com

Carnegie Mellon http://www.cmu.edu

Snort http://www.snort.org

Snax Orinoco patch http://airsnort.shmoo.com/orinocoinfo.html

GPSD http://www.pygps.org/gpsd/

www.foundstone.com © 2003 Foundstone, Inc. All Rights Reserved | 22