A Distributed Vulnerability Detection System for WLANs

Guiomar Corral, Xavier Cadenas, Agustn Zaballos, M.Teresa Cadenas

Enginyeria i Arquitectura La Salle - Universitat Ramon Llull
Phone: 00 34 932902423 Fax: 00 34 93211100 - c/Quatre Camins 2, 08022 Barcelona, Spain
{guiomar, xcadenas, zaballos, mcadenas}@salleurl.edu
Abstract
The increasing popularity of wireless networks has
opened organizations up to new security threats and
many traditional countermeasures are ineffective in
dealing with them. Any networked system where
security or privacy protection of assets is valued needs
security experts to protect and control it. There exists a
need for an automated security system which helps
security analysts to focus on critical points. This paper
discusses the issues related to vulnerability assessment
in wireless networks and proposes a new distributed
system to analyze system interactivity, security
capability and vulnerability detection in wireless
networks. The design and implementation of this
distributed vulnerability detection system for WLANs is
also presented. This proposal is based on international
best practices for security, the Open Source Security
Testing Methodology Manual (OSSTMM). It is part of
a wider system for automating vulnerability detection
not only for wireless but for wired networks called
Consensus.
1. Introduction
The exponential growth of networking, including
wireless technologies, has lead to increased security
risks. Many of these risks are due to hacking, as well as
improper uses of network resources.
WLANs present unique security challenges because
they are vulnerable to specialized and particular
attacks. Many of these attacks exploit technology
weaknesses since 802.11 WLAN security is relatively
new. There are also many configuration weaknesses
since some companies are not using the whole security
features of WLANs on all their equipment. Finally,
there are policy weaknesses. When a company does not
have a clear policy on wireless usage, employees may
set up their own Access Points (AP), which is rarely
secure.
Wireless access can be a great threat to network
security. Most WLANs have few or no restrictions.
Once associated to an AP, an attacker can freely roam
an unsecured internal network and even compromise
wired network security. Compromising only one node
or introducing a malicious node may affect the
viability of the entire network [1].
A security policy must identify the wireless security
objectives of the organization, document resources to
be protected and identify network infrastructure with
current maps and inventories. An effective wireless
security policy works to ensure that network assets of
the organization are protected from unauthorized
access. Also, network security analysis must
coordinate different sources of information to support
effective security models [2]. In addition, sensors and
monitoring elements should be distributed on the
wireless network to manage and monitor it.
Anomaly detection techniques have been applied to
detect intrusion and vulnerabilities since 1980 [3]. The
design of a security monitoring surveillance system
needs the understanding of threats and attacks that can
be mounted against a system and how these threats
may manifest themselves in audit data [3]. Thus a
system to identify and report on threat information can
greatly enhance the security of a wireless network [1].
This is one of the reasons why performing periodically
security tests is so important. Testing is a basic security
tool necessary to assure enterprise security
requirements, not only on wired but also on wireless
networks. Also a company can correctly validate its
security implementation by analyzing the results and
discover how attackers can penetrate into its systems
and network.
Although information exists about testing networks,
there is no standard that regularizes the involved
procedures [4]. To have a reference in security testing,
we have referred the tests to the Open Source Security
Testing Methodology Manual (OSSTMM) [5]. This
manual outlines a global comprehension of the many
security issues to be checked to perform a valid
security test [6]. It also contains a specific
Proceedings of the First International Conference on Wireless Internet (WICON05)
0-7695-2382-X/05 $20.00 IEEE
methodology regarding to wireless network tests.
Although OSSTMM helps to reliably verify network
security, it can consume a great amount of hours due to
the exhaustive tests and the security knowledge needed
to test, gather and analyze results. Thus automation for
certain processes will help security experts [4].
This paper proposes a new Vulnerability Detection
System for wireless networks. It has a distributed
architecture and simplifies tests execution on wireless
networks based on the OSSTMM by automating the
different procedures. This proposal is part of a new
larger system, called Consensus, capable of detecting
vulnerabilities not only in wireless but also in wired
networks, using Intranet, DMZ and Internet sensors
[4]. Test information collected by wireless sensors will
be saved and showed to the security expert in different
views, offering a convenient system to detect security
problems and vulnerabilities in a wireless network.
Results show that this new system helps the security
analyst to optimize its work. This work is included in a
research project partially supported by Spanish Grant
FIT-360000-2004-81.
Our paper will proceed as follows. In section 2 we
provide background of security testing and discuss
related work on vulnerability detection and wireless
system security. In section 3 the new approach for an
automated vulnerability detection system called
Consensus is presented and its main goals and
requirements are described. In section 4 we present a
solution for automate security testing in wireless
networks. Results are shown in section 5. Finally we
discuss conclusions and further work in section 6.
2. Background and related work
Nowadays increasing numbers of organizations are
deploying wireless networks. Thus new architecture
and mechanisms to protect these networks are needed
as new security weaknesses and vulnerabilities have
arisen. Intrusion detection, audit and logging systems
often provide feedback data that cannot be effectively
analyzed due to the datas sheer volume and the insular
nature of the systems. The only way to neutralize this
threat is to develop an integrated suite of tools to reveal
weaknesses in enterprise security architectures,
correlate incidents, and model and visualize attacks [2].
A comprehensive network vulnerability analysis
must address wireless environment threats and
vulnerabilities, including identification of unauthorized
wireless APs and incorrectly configured clients. Client
security is important, because simply securing the AP
does not protect a wireless network. After weaknesses
of the APs are protected, attacking clients becomes the
easiest way to gain access to the network.
The basic element of network vulnerability analysis
is testing. A system or network test helps to identify
present vulnerabilities in order to eliminate them. It
also assists to guarantee that network assets are
protected from inappropriate access and it contributes
to ensure that security policy is correctly applied. Thus,
a complete test should include system, communication,
physical, personal, operational and administrative
security [7].
Regarding to test methodologies, a security test may
be considered an OSSTMM test if it is quantifiable,
consistent, repeatable and thorough. This fact allows an
objective comparison between two different security
OSSTMM tests [5].
Standard tools for monitoring wired networks and
ensuring their security examine only network or higher
abstraction layers based on the assumption that lower
layers are protected by the physical security of wires.
However, this assumption cannot be extrapolated to
wireless networks because of the broadcast nature of
such networks [8].
To determine a proper defensive perimeter, an
information summary about all wireless clients and
APs is needed, including not only the authorized but
also the rogue APs. But usually network security
experts have to find, learn and run many different tools
in order to look for diverse vulnerabilities and collect
all the information. Not only gathering information can
be a complex problem but also the storage of this
critical data and its future analysis. This is why we
propose a new automated system to analyze system
interactivity, security capability and also vulnerability
detection in wireless networks to help security experts.
The utility for such a system includes all industries
with wireless systems where security or privacy
protection of assets is valued. Currently, tools exist that
do wireless vulnerability scanning [9,10,11,12,13] but
different tools are needed to obtain all the vulnerability
information required for a reliable test and no
methodology is followed. On the other hand,
OSSTMM and ISO-17799 audits are becoming more
accepted as international testing standards. These facts
corroborate the need of a new vulnerability detection
system for WLANs that follows a security testing
methodology and automates the related processes in
order to alleviate security work with a simplified
administration. As wireless networks are usually part
of a corporate network, this wireless detection
technology should be integrated in a system capable of
detecting vulnerabilities in the entire network [4]. This
new system will be presented in the next sections,
paying special attention to the solution for wireless
networks.
Proceedings of the First International Conference on Wireless Internet (WICON05)
0-7695-2382-X/05 $20.00 IEEE
3. The Consensus Vulnerability Detection
System architecture
The main goal of the Consensus system is to
automate the security testing procedures in order to
reliably verify network security and detect network
vulnerabilities. It has been proved that this system
minimizes the amount of time needed to perform a
methodological security test [4].
Consensus has several interactive modules sharing a
similar design base to provide security operations for
vulnerability detection. The system is implemented
exclusively using open source products and utilities,
not only because of its significantly lower cost but also
due to its ease of customization. This is why Linux has
been chosen as base operating system with hardware
and environmental flexibility. Consensus system
architecture is shown in Figure 1.
Figure 1. System architecture of Consensus
The first module is the Base System that provides a
basic platform to have a safe system for the
environment standardization and also for security
management and patching. All the other modules are
developed upon this base, which runs a Linux Debian
kernel 2.6. This operating system has been modified
and adapted in order to provide for a stable,
configurable and efficient system in a small size.
The Management Module ensures standardized
updates and configuration changes from a single
platform and also controls the whole system and the
different sensors state. The Database Module is
responsible for securely saving all the data collected by
the different testing modules. Then, the Analysis
Module uses the information contained in this database
in order to generate security reports and present test
results to the security professional. Tests are performed
by the different testing modules: Internet, Intranet,
DMZ and Wireless modules. The Internet Sensor
provides a thorough security test of all Internet-visible
systems performed from the external network in order
to detect vulnerabilities from a non-privileged
environment. The Intranet Sensor provides tests to
verify internal network security, information leaks and
private network stability [14]. The DMZ Module
ensures the Demilitarized Zone testing, where different
network servers can be accessed not only from the
external network, but also from the internal. Finally,
the Wireless Module provides automatic test to verify
wireless network security and control whether this part
of the network compromises the whole network
security. This module is deeply described in the next
sections.
4. The Wireless Module
4.1. The Wireless Module architecture
The Wireless Module is responsible for testing the
existing wireless networks in a corporation, including
personal or local area networks located in the intranet.
All the data collected from any test will be saved in the
Database Module, in order to analyze them afterwards
to detect any possible vulnerability and solve it in the
wireless environment. The system is controlled by the
Management Module, which will signal the test
beginning and will specify the different test
parameters. In addition, the Wireless Module informs
the Management Module when the test is finished;
therefore the Management can get the results file and
save them in the database and the testing module can
delete all the information for security reasons.
Consequently, the Wireless Module only executes the
commands that the Management Module sends to it.
The Wireless Module has been developed upon the
Base Module; thus the operating system used in the
Wireless Module must be the same used in the Base:
Linux Debian. There is also a direct dependence
between the Wireless Module and the Database
Module. The previous knowledge of the significant
wireless testing data is necessary for an accurate
database design and it should also cover the procedures
involved to get these data. Therefore a results file
format has been previously defined for the system.
This module has focused on the wireless LAN
802.11, specifically on the 802.11b standard because
nowadays it is the most extended and it is the standard
implemented in our testbed. Then, the functionality
difference between a WLAN and a LAN is located at
the Physical and Link Layer of the OSI architecture.
This is why the Wireless Module will perform the
testing at the first and second layer to provide the
necessary information for the network layer. The tests
from the Network to the Application Layer will be
performed by the Intranet Module [14], because these
levels are identical in wired and wireless networks.
Proceedings of the First International Conference on Wireless Internet (WICON05)
0-7695-2382-X/05 $20.00 IEEE
Figure 2. IEEE 802.11 standard
In order to perform a wireless network test it is
necessary to be in its radio coverage. For that reason, a
previous study must be performed to locate
strategically points where the different wireless sensors
will be installed to cover the whole network coverage
area to scan.
Test methodology is another important design
component to consider. The chosen methodology will
have a great impact over the whole system. The
OSSTMM has been selected in terms of reference
because this manual outlines a global comprehension
of the security issues to be checked to perform a valid
security test [5]. The last version used for this module
is the OSSTMM Wireless 2.9.1. This methodology
leans on open-source programs and free-license tools
to test networks. This is why the Wireless Module and,
in fact, the Consensus, has been built using only open-
source software, with a significantly lower cost and its
ease of customization. Although the OSSTMM
Wireless includes a wide range of technologies and
applications, we will apply the methodology only in
the IEEE 802.11 standard, which is the most extended
in WLAN implementations.
4.2. The Wireless System specifications
The design and development of the Wireless System
has several requirements that must be taken into
account. They are not only hardware but also software
demands and they will force several design and
implementation decisions.
In order to perform any wireless test, a device with
a wireless card that supports monitor mode is essential
[8]. This especial mode enables packet capture without
being associated with a certain network and this fact
enables the device to sniffer any detected network.
Nowadays not all cards support this mode and very
specific drivers are required. They do not depend on
the manufacturer or the trademark but on the chip. The
chips that support this mode are Chipset PRISM and
also Chipset Hermes (Orinoco). Table 1 shows the
different cards that have been tested and can be placed
in monitor mode.
Regarding to software requirements, the OSSTMM
states the use of open-source code and utilities. Also,
the Wireless system needs to run over Linux Debian,
the operating system used by the Base system.
Moreover, the tools used to automate tests must be
open-source, so a particular study will be performed to
select the most suitable open-source and free-
distribution utilities. In order to automate tests, tools
with command-line are required. They do not need a
graphical user interface, because they will only interact
with the Management Module and no human
interaction will be required. The Wireless Module only
complies with the Management commands. Once the
test has been performed, the Wireless Module has to
format all the results in a file using a standard structure
known by the Management and itself. When the
Management Module obtains the results file, the
Wireless Module must delete all the files created it its
system for security reasons.
Table 1. Wireless cards with monitor mode
Card Chipset Driver
Monitor
Mode
Belkin 802.11b Prism2 Hostap_cs Yes
Lucent silver Orinoco Orinoco_cs Yes
3-Com
3CRWE154G72
Prism GT
(ISL3880)
Prism54-1.1 Yes
4.3. The Wireless System implementation
The Wireless Module is divided in four different
blocks. Its block diagram and the relationships between
every block are shown in Figure 3.
The Communications Block provides all the
mechanisms to communicate the Wireless Module with
the system Management Module. When the security
professional wants to perform a security test, the user
configures all the parameters using the web interface
provided by the Management Module. Then, this
module sends a configuration file to inform the sensor
of the different test parameters. A proprietary
communications protocol has been designed to control
the different testing modules and also send or receive
all the information related to the test [4]. This provides
a suitable and reliable communications protocol for the
whole system.
TX
RX
RESULTS
TESTING
Figure 3. Block diagram of the Wireless Module
Proceedings of the First International Conference on Wireless Internet (WICON05)
0-7695-2382-X/05 $20.00 IEEE
The Management Block controls the different
actions that the Wireless Module must perform. It only
accepts commands from the system Management
Module and verifies the received configuration file
before starting any test. It also checks the phase and
state of the different testing procedures in order to
notify any change to the Management Module. In
addition, this block informs when the test has finished
and deletes the results file for security reasons when
data has already been inserted into the system database.
The Testing Block is the core where all the different
tests are performed. This block follows the OSSTMM
Wireless 2.9.1. This version focuses on wireless
devices like IEEE 802.11, Bluetooth, IR, cordless and
so on. This methodology states different phases to
carry out in order to perform a valid security test. The
phases implemented by the Testing Block are the ones
that can be automated and applied to the IEEE
802.11b. These are Visibility Assessment,
Accessibility Testing, Circumvention Research, Access
Cracking and Survivability Testing. All these phases
and the tasks related to them will be explained in detail
in the next section.
The Results Block formats all the results obtained
from the tests. Results are introduced in an output
XML file that the Management Module will get to save
all the information in the database.
Figure 4. Flow diagram of the Wireless Module
Figure 4 shows the global flow diagram of the
Wireless Module, where the different states are
represented. First of all, the sensor module must be
installed and configured in a device that already
contains the Base Module. Then, all the
communications with the Management Module start
using predefined encrypted messages and the Wireless
Module remains waiting for a command to start a test.
When it receives this command and all the testing
configuration parameters, the module performs the test
following the different phases of the OSSTMM
methodology and generates an output file with all the
results. In addition, it informs to the Management that
the test has finished and comes back to the Waiting
state until it receives another test starting command.
Then, the Management Module obtains the output file
using a secure method with encryption and
authentication. This file contains confidential data so
its secure transmission and maintenance is especially
critical.
4.4. The Wireless Testing
According to the OSSTMM methodology, the
results that a security expert wants to obtain when
testing a wireless network are the following:
- Business needs, practices and policies evaluation. As
they depend on the corporation it is hard to automate.
- Physical perimeter evaluation: location of the APs,
channel usage, emitting power, SNR.
- Logical perimeter evaluation: ESSID, BSSID, IP
range and connectivity to other networks. It is
important to understand how an intrusion in the
wireless network can compromise the wired network.
- Access point evaluation: number of AP, beacon
frame status, information provided by APs.
- Address range and DHCP evaluation.
- Device configuration evaluation: passwords and
encryption. When WEP encryption is used, the key
should be obtained. It has been proved that WEP
encryption is weak because keys can be discovered
capturing enough frames [15].
- Device authentication evaluation: when MAC
authentication is used, authorized MAC addresses
should be obtained.
- General device configuration verification.
- Hardware and firmware evaluation.
The Testing state is divided in five phases:
Visibility assessment, Accessibility testing,
Circumvention research, Access cracking and Denial
of service. Its flow diagram is shown in Figure 5.
The Visibility assessment consists of performing a
complete inventory of all wireless devices on the
detected wireless networks. The configuration file sent
by the Management Module specifies the type of test to
perform, the time that sensors will spend capturing
traffic and the scope. A file for every detected network
will be created regarding this information and captured
frames. Every detected AP that was included in the
configuration file will be inserted in the In_scope file.
The Out_scope file includes the detected APs that
werent specified in the configuration file, which are
potential unauthorized APs. Finally, the No_scope file
includes the APs specified in the configuration file that
havent been detected, maybe due to an error in the
configuration file or maybe because the AP has been
turned off or it has been moved away. In this case,
these APs dont need to be tested.
The main goal of the Accessibility Testing phase is
to gather information about how easy is the access to
wireless networks. Therefore, this phase provides data
about the used channel, encryption, authentication, IP
range, SSID and DHCP. IEEE 802.11 standard
includes WEP to protect authorized users of a WLAN
Proceedings of the First International Conference on Wireless Internet (WICON05)
0-7695-2382-X/05 $20.00 IEEE
from casual eavesdropping but it has been proven
ineffective to encrypt data [15]. When using WEP, if
the system knows the WEP key it will try to decrypt
captured frames. If the key hasnt been given, the
system will find the key length and enough encrypted
packets to compromise the key in the Access Cracking
phase. Two results file are generated. The first one
contains accessibility information for every network
and the second one includes networks with an
unknown WEP key where data hasnt been obtained
yet.
Figure 5. Flow diagram of the Testing State
The Circumvention Research phase enumerates all
unauthorized devices, starting with the equipments of
the Out_scope file. This phase also checks MAC
spoofing [16]. Results file includes unauthorized
devices and also devices with an unregulated IEEE
MAC address. MAC addresses are not totally random
because the first three bytes are specific to each
manufacturer. By checking each MAC address against
such patterns, it would be possible to determine forged
addresses randomly generated by intruders [8]. One
important fact to consider is that the system can detect
external networks from surrounding buildings and they
will be considered unauthorized networks. One feasible
solution would consist of adding a GPS to exactly
locate the APs in order to find out if they are placed
inside the internal network perimeter.
The main goal of the Access Cracking phase is to
discover the WEP key; therefore this phase will need a
great amount of frames in order to compromise the
key, one million packets approximately. Results file
will include decrypted keys with data of the related
APs and the time spent to decode them.
The last phase performs denial of service (DoS)
attacks when security expert explicitly requires them.
DoS objectives must be clearly defined and DoS
attacks must be carefully planned as they can disable or
affect the whole network. This is an optional phase and
it returns the devices response to DoS attacks.
Several testing utilities have been analyzed in order
to select the most suitable procedure to automate
security testing and obtain the required data. These
tools must comply with several requirements: Linux-
based open-source tools with command line. The
selected utilities are shown in Table 2.
Table 2. Wireless utilities for testing
Tool Remarks
Sniffer
Kismet
2004.04.R1
Capture traffic in
WLANs
Wepcracker
Aircrack
v2.0
Decrypt WEP key.
1 Million captured
packets needed
DHCP Dhclient
Send DHCP requests
to learn about the
DHCP server
Authentication
type
No
No tools found to
discover the
authentication type
Unauthorized
devices search
No
Knowledge of the
network is needed
DoS Attacks Void1
Doesnt work with
certain drivers
A useful tool for wireless reconnaissance is Kismet
[10]. It is a passive tool because it transmits no data
while detecting wireless networks. Other sniffers like
Wellenreiter and Netstumbler have been also analyzed
but both have only graphical interface [11,12].
Several tools for WEP key decoding exist and they
are based on different WEP vulnerabilities [15]. When
enough frames have been collected from the network,
they can determine the WEP key of the network by
examining weak frames [8]. After testing different
group of packets with Airsnort, Wepcrack, Weplab and
Aircrack, the utility with better results has been the last
one. Airsnort was discarded because it only has
graphical interface.
Proceedings of the First International Conference on Wireless Internet (WICON05)
0-7695-2382-X/05 $20.00 IEEE
4.5. The Wireless communications
The communications protocol used by the Wireless
and Management modules has been specially designed
for this system and it is based on the 3-way handshake
and the IETF proposal called Intrusion Detection
Exchange Format (IDWG) [4].
The Management Module can send different
messages to the Wireless Module. A very important
message is the state request that the Management
Module sends to verify if the subsystem is disabled,
waiting for instructions, testing or has finished a test.
There is also a special message that the Management
Module can use to do an emergency stop of a test.
Also configuration and result files have to be
exchanged. When the management wants to start a test,
it sends a file with all the initial parameters. When the
Wireless Module has finished the test, it will inform the
Management System. Then, the management will get
the result file from the testing module. The protocol
used to exchange files is SCP (Secure CoPy), an open-
source Secure Shell FTP, useful to provide security
during the exchange process.
Figure 6. Message exchange
5. Results
Different vulnerability tests can be configured using
the management web console. This web interface has
been designed and implemented for the system.
Therefore, all the system can be managed and all the
tests can be controlled only using this web interface.
Figure 7. Management console test configuration
Some forms need to be fulfilled before running any
test like, for example, the IP range or SSID. These are
some of the parameters that the Management Module
will send to the Wireless Module before starting the
test and an example is shown in Figure 7.
The Analysis Module is responsible to process all
the information obtained from a wireless test. This
information is stored in the system database and the
user can choose specific data to include it in a certain
report. The Management Module will interact with the
Analysis Module in order to show the test results to the
security specialist. Information about the obtained
ESSIDs, MAC addresses and manufacturers, channels,
radio frequency, power, SNR, IP ranges, WEP keys
and other data useful for the security expert will be
shown in an intuitive view to help auditing a wireless
network and finding possible vulnerabilities, rogue
APs or unauthorized clients. See Figure 8.
Figure 8. Management console test results
The system has been tested on several wireless
networks and results have shown that this system
reduces the time a security specialist spends to perform
security vulnerability tests and gather information.
6. Conclusions and further work
This paper has presented a new approach for
automating a vulnerability detection system using the
OSSTMM methodology for wireless networks.
Vulnerability detection is a necessity in any system or
network because once threats are known, it is more
feasible to protect against them. Furthermore,
exceptional considerations must be taken with wireless
networks as they present unique security challenges,
completely different to wired networks. Many of these
attacks may exploit technology weaknesses but other
may profit from configuration weaknesses or errors.
Although several utilities exist to test and detect
vulnerabilities, there is no system which proposes a
distributed architecture and automates all the processes
needed to detect vulnerabilities on a wireless network.
Proceedings of the First International Conference on Wireless Internet (WICON05)
0-7695-2382-X/05 $20.00 IEEE
The modular design of this new proposal has been
analyzed, so it has been proved that its modularity will
help to integrate new modules whenever it is necessary
or a new technology comes out.
Finally, the whole system has been tested using
several scenarios in a security testbed, showing a
positive time and management improvement compared
to conventional testing. The automation of security
tests using a unique interface in order to perform
different types of tests and control the entire system
facilitates security work. It also optimizes the time
needed for gathering information to discover new
vulnerabilities on any wireless network.
Future work includes a more in-depth study on
wireless security to adapt the system to new threats and
new utilities. Also, the new security improvements of
IEEE 802.11i should be analyzed in order to include
them. The problem is that the actual version of the
OSSTMM does not consider yet this standard, but the
new release will contain it. Another milestone is
focused on the Analysis Module. Data analysis after
testing wireless networks can be improved using
different correlation techniques [17,18]. Also Artificial
Intelligence (AI) techniques can be applied to the
whole data set to learn from past experience, detect
new vulnerabilities and extract more conclusions [2,
19]. Our research group is also focused on Intelligent
Systems and we have previous work with AI in other
networking fields with excellent results [20].
7. Acknowledgements
We would like to thank Ministerio de Industria,
Turismo y Comercio for its support under grant number
FIT-360000-2004-81. We would also like to thank
Enginyeria i Arquitectura La Salle (Universitat Ramon
Llull) for their support to our research group in
Intelligent Systems (2002 SGR-00/55). We also wish
to thank Pete Herzog and ISECOM for their support to
this project with the OSSTMM.
8. References
[1] H. Yang, L. Xie, J. Sun, Intrusion detection for Wireless
Local Area Network, CCECE -CCGEI 2004, pp. 1949-1952
[2] J. Dawkins and J. Dale, A Systematic approach to Multi-
Stage Network Attack Analysis, Proceedings of the 2
nd
.
IEEE IWIA04, 0-7695-2117-7/04, 2004.
[3] J.P. Anderson, Computer Security Threat Monitoring
and Surveillance, Technical Report, James P. Anderson Co.,
Fort Washington, Pennsylvania, April 1980.
[4] G. Corral, A. Zaballos, X. Cadenas, and I. Serra, A
Distributed Security System for Vulnerability Testing, V
Jornadas de Ingeniera Telemtica 2005, submitted.
[5] P. Herzog, OSSTMM, www.isecom.org, October 2003.
[6] A. Zaballos, G. Corral, I. Serra and J. Abella, Testing
Network Security Using OPNET, OPNETWORK 2003,
USA, 2003.
[7] John Wack, Miles Tracy, Murugiah Souppaya, Guideline
on Network Security Testing, Recommendations of the NIST;
US Dept. Commerce (Computer Security Division), 2003.
[8] Y.Lim, T. Schmoyer, J. Levine, H. Owen, Wireless
Intrusion Detection and Response, Proc. of the 2003 IEEE
Workshop on Information Assurance, 2003, pp. 68-75.
[9]Aircrack,www.michiganwireless.org/tools/aircrack/, 2005.
[10] Kismet, http://www.kismetwireless.net/, Feb.2005.
[11] Stumbler, http://www.stumbler.net/, 2005.
[12] Wellenreiter, http://www.wellenreiter.net/, 2005.
[13] Airsnort, http://airsnort.shmoo.com/, 2005.
[14] G. Corral, A. Zaballos, X. Cadenas and A. Grane, A
Distributed Security System for an Intranet, 39
th
IEEE
International Carnahan Conference on Security Technology
ICCST 2005.
[15] S. Fluhrer, I. Mantin and A. Shamir, Weaknesses in the
Key Scheduling Algorithm of RC4.
[16] IEEE, http://standards.ieee.org/regauth/oui/oui.txt, 2005
[17] J. Haines, L. Rossey, R. Lippmann, R. Cunningham,
Extending the DARPA Off-Line Intrusion Detection
Evaluations, Proc. of DARPA Information Survivability
Conference & Exposition II, Volume: 1, 2001, pp. 35-45.
[18] P. Ning, Y. Cui, D. Reeves, Analyzing Intensive
Intrusion Alerts Via Correlation, Proc. of the 5
th
International Symposium on Recent Advances in Intrusion
Detection, LNCS 2516, Switzerland, 2002, pp. 74-94.
[19] M.Conner, C. Patel, M. Little, "Genetic
Algorithm/Artificial Life Evolution of Security Vulnerability
Agents," Army Research Laboratory Federal Laboratory 3rd
Annual Symposium on Advanced Telecommunications &
Information Distribution Research Program, February 1999.
[20] G. Corral, A. Zaballos, J. Camps, J. Garrell, Prediction
and control of short-term congestion in ATM networks using
Artificial Intelligence techniques, Proc. of the 1
st
. IEEE Int.
Conf. on Networking, LNCS 2094 Springer, France, 2001,
pp. 648-657.
Proceedings of the First International Conference on Wireless Internet (WICON05)
0-7695-2382-X/05 $20.00 IEEE