2005:234 CIV

M A S T E R ' S T H E S I S

Identifying Threats in aWireless Environment

Chris Viklund

Luleå University of Technology

MSc Programmes in Engineering

Department of Computer Science and Electrical EngineeringDivision of Computer Communication

2005:234 CIV - ISSN: 1402-1617 - ISRN: LTU-EX--05/234--SE

Identifying threats in a wireless environment

Chris Viklund

Luleå University of Technology Department of Computer Science and Electrical Engineering

Division of Computer Communication

i

Abstract Threats towards networks are a constant problem, given the rise and rapid growth of the Internet these have increased by magnitudes. In order to secure networks, patch management is a necessity as well as using firewalls and access control mechanisms. If a network-connected host is fully patched, could it still be subject to various break-in attempts, and if so, could they be detected? Having a complete view of the threats directed towards a network became realized in the birth of intrusion detection systems. By utilizing intrusion detection systems for monitoring network flows for malicious activity, system administrators can learn which attacks are destined towards their networks and thereby obtain a better view of the threat level directed towards them. The main goal of intrusion detection systems is to capture and log threats towards the networks, not necessarily prevent them from happening. This thesis has explored how an intrusion detection system can aid in detecting threats towards a wireless communication. Given the inherent problems that exist in wireless conversations regarding eavesdropping and badly implemented security (WEP); could any of the threats be identified by an intrusion detecting system? The answer is yes and no. It is impossible to detect eavesdropping of the wireless medium, but other attacks directed towards wireless products can be detected in most cases. Furthermore, the thesis setup a secure wireless communication utilizing a RADIUS server for authenticating clients and the TKIP encryption scheme for ensuring a stronger encryption than WEP. When monitoring a wireless communication with such characteristics, not much could be deducted given the security scheme, and most of the threats directed towards the test bed could be detected by the intrusion detection systems used.

i

Acknowledgements This master thesis is the final part in my Master of Science studies in computer science at Luleå University of Technology, Sweden. The thesis was conducted at Ericsson Microwave Systems in Gothenburg during the months of January to July year 2005. First of all, I would like to thank my supervisors Helena Sandström (LTU), Henrik Riomar, Anders Ripa and Bo Renman (Ericsson) for all their comments and support. Secondly, I would like to thank everybody else in general who has helped me with my thesis, either directly or in other ways.

ii

Table of Contents INTRODUCTION ...................................................................................................................................................................1

BACKGROUND ......................................................................................................................................................................1 OBJECTIVES ...........................................................................................................................................................................1 DELIMITATIONS ....................................................................................................................................................................1 DOCUMENT OUTLINE ...........................................................................................................................................................1

ABBREVIATIONS AND ACRONYMS................................................................................................................................2

HISTORICAL OVERVIEW ..................................................................................................................................................4

BACKGROUND......................................................................................................................................................................5 INTRUSION DETECTION SYSTEMS..........................................................................................................................................5

Threat detection................................................................................................................................................................6 Anomaly detection ...........................................................................................................................................................7 Signature detection ..........................................................................................................................................................7 Network-Based IDS .........................................................................................................................................................7 Host Based IDS ................................................................................................................................................................8 Stack Based IDS ...............................................................................................................................................................8 Bayesian IDS....................................................................................................................................................................9

INTRUSION PREVENTION SYSTEM ........................................................................................................................................9 NETWORK MONITORING ....................................................................................................................................................10

Port mirroring................................................................................................................................................................10 Network hubs .................................................................................................................................................................10 Network taps ..................................................................................................................................................................10

NETWORKS .........................................................................................................................................................................11 Ethernet..........................................................................................................................................................................11 WLAN............................................................................................................................................................................13

SECURITY TOOLS .................................................................................................................................................................20 Snort ..............................................................................................................................................................................20 Snort-wireless ................................................................................................................................................................20 Oinkmaster.....................................................................................................................................................................20 Kismet ............................................................................................................................................................................21 Airsnort..........................................................................................................................................................................21 Aircrack..........................................................................................................................................................................21 Arpwatch........................................................................................................................................................................21 Advanced Console for Intrusion Detection (ACID) ......................................................................................................21 FreeRADIUS .................................................................................................................................................................22 nmap ..............................................................................................................................................................................22 Ethereal ..........................................................................................................................................................................22 MySQL ..........................................................................................................................................................................22

THREATS .............................................................................................................................................................................23 WLAN attacks................................................................................................................................................................23 Sniffing traffic ................................................................................................................................................................23 Disassociating nodes from APs......................................................................................................................................23 Breaking WEP keys........................................................................................................................................................23 Dictionary attacks against WPA-PSK...........................................................................................................................24 Message integrity check denial of service.......................................................................................................................24 ARP attacks ...................................................................................................................................................................24 Denial of Service ............................................................................................................................................................24 Man in the Middle .........................................................................................................................................................25 MAC flooding ................................................................................................................................................................25

iii

SECURITY REQUIREMENTS...........................................................................................................................................26 SECURITY ENFORCEMENTS ..................................................................................................................................................26 ENCRYPTED TRAFFIC ..........................................................................................................................................................26 CERTIFICATES .....................................................................................................................................................................27 MAC FILTERING .................................................................................................................................................................27 DHCP (DYNAMIC HOST CONFIGURATION PROTOCOL) ..................................................................................................27 LOGGING ............................................................................................................................................................................28 EXTENSIBLE AUTHENTICATION PROTOCOL ......................................................................................................................28

TEST BED..............................................................................................................................................................................29 WIRELESS CLIENT ...............................................................................................................................................................30 SNORT SENSORS ..................................................................................................................................................................31 MYSQL DATABASE.............................................................................................................................................................33 THE FREERADIUS SERVER ................................................................................................................................................33 OPENSSL .............................................................................................................................................................................34 ACCESS POINT.....................................................................................................................................................................34 NMAP ..................................................................................................................................................................................35 KISMET................................................................................................................................................................................35 ARPWATCH .........................................................................................................................................................................35

METHOD AND RESULT ....................................................................................................................................................36 UNDERSTANDING THE NETWORK ......................................................................................................................................36

Access Point ...................................................................................................................................................................36 Kismet ............................................................................................................................................................................36 Ethereal ..........................................................................................................................................................................37 Snort ..............................................................................................................................................................................37 nmap ..............................................................................................................................................................................37

CONCLUSIONS....................................................................................................................................................................39

FUTURE WORK...................................................................................................................................................................42

REFERENCES ......................................................................................................................................................................43 APPENDIXES

APPENDIX A. SNORT.CONF…………………………………………………………………………………....1 APPENDIX B. RADIUSD.CONF……………………………………………………………………………...…3 APPENDIX C. EAP.CONF……………………………………………………………………………………….8 APPENDIX D. CLIENTS.CONF…………………………………………………………………………………9 APPENDIX E. OPENSSL SCRIPTS FOR GENERATING CERTIFICATES……………..............................10 APPENDIX F. CREATE_MYSQL………………………………………………………………………………12 APPENDIX G. WIFI.RULES…………………………………………………………………………………….15 APPENDIX H. NMAP SCAN OF THE FREERADIUS SERVER USING THE –SX FLAG………………..16 APPENDIX I. STRIPPED SNORT LOG FROM THE NMAP XMAS SCAN……………………………....17

Introduction

1

Introduction

Background Threats against networks have existed as long as the networks themselves. A threat being anything from eavesdropping or fraud attempts to classic cracking (not to be confused with hacking) or unauthorized use of resources. The list is long and the ways to prevent them are equally so. Examples of cracking are unauthorized use of computer resources, destroying or modifying data for own purpose, unleashing viruses or setting up backdoors on systems in order to gain future access. Phishing (attempting to fraudulently and deceptively acquire sensitive personal information by masquerading in official-looking messages as someone trustworthy with a real need for such information [31]) is another common issue to protect users and resources from.

Objectives This report attempts to describe the threats that exist towards wired networks, as well as wireless networks (and Access Points) in general, and offers a way to monitor and log such behavior and if possible actively circumvent them as well. The suggestions will be based upon the test bed that is described in this report as well as the requirements that are setup for it.

Delimitations The following delimitations have been set upon this report due to time limitations: • Even though a comparison of different scenarios and different configurations are interesting, only

one test bed will be evaluated. • Only one brand of intrusion detection systems (and wireless equivalents) will be tested, namely

snort. • Threats described in the report are limited to the ones explained or to ones directed towards

wireless network in general, if not otherwise explicitly stated.

Document outline Chapter background gives a brief background regarding the details of wired networks and the wireless 802.11 protocol used when communicating between wireless nodes. The chapter security requirements discusses what requirements are necessary for approving a security scheme to the network described in chapter test bed, in order for it to be considered «secure». Chapter test bed describes the test setup used for this experiment and chapter method and result evaluates the testing. Finally, the chapter conclusions, wraps up the report and suggests further improvements.

Abbreviations and acronyms

2

Abbreviations and acronyms AES Advanced Encryption Standard. ARP Address Resolution Protocol. A protocol used to translate IPv4 over Ethernet addresses

into physical addresses of network interfaces. BIDS Bayesian IDS. An IDS which learns to identify and classify packets by certain sets of

rules. DHCP Dynamic Host Configuration Protocol. DMZ Demilitarized Zone. A network area between an internal and external network deemed

neither safe nor “unsafe” (other placements do exist though). DDOS Distributed Denial of Service. Many compromised hosts simultaneously attack a target

host. DOS Denial of Service. An attack towards a system, rendering it unusable for its legitimate

users. EAP Extensible Authentication Protocol. GPL GNU General Public License. The license states that software released under this license

is free and anyone basing their work upon the source code must release the changes as well.

HIDS Host based IDS. An IDS that resides on a host in order to detect threats against it. ICMP Internet Control Message Protocol. Typically used for reporting errors in processing datagrams. IDS Intrusion Detection System. A system designed to detect intrusion attempts often by use

of known exploits towards bugs in programs or the operating system. IPS Intrusion Prevention System. A system designed to actively prevent intrusion, once it

detects that they are taking place. IPv4 Internet Protocol version 4. A protocol that provides best effort delivery of datagrams

over a network. IPv6 Internet Protocol version 6. The next generation of IP, designed to provide better

security by using encryption of the payload inside it, as well as other improvements over IPv4.

IV Initialization Vector for WEP uses the 24 first bits of each encrypted packet to let the receiver know how to decrypt it.

MAC Media Access Control. MIM Man in the Middle. An attack where an attacker places himself between two

participating nodes during a network transmission in order to listen to the conversation, alter it, or something similar.

MTU Maximum Transmission Units. The maximum size of datagrams sent through a network interface before the packet must be fragmented (split into smaller parts).

NIC Network Interface Card. A device that physically connects a node to a network. NIDS Network based IDS. An IDS that resides in a network in order to analyze the packets

passing though the network. SPX Sequenced Packet Exchange. An alternative to TCP that enables packets to be sent using

a resending mechanism if the packets fail to meet their destination. SSID Service Set Identifier. The name (or identifier) of a wireless access point. SSL Secure Sockets Layer. An application leveled encryption paradigm used for secure

communications in a network. TAP Test Access Port. A device which splits the incoming physical layer into a mirroring one

which enables a device to passively monitor the traffic passing through such a device. TCP Transmission Control Protocol. A protocol used for ensuring reliable communication

over a network.

Abbreviations and acronyms

3

TKIP Temporal Key Integrity Protocol. A security protocol replacement of WEP that utilizes

the same hardware as was built for WEP implemented devices. TLS Transport Layer Security UDP User Datagram Protocol. This is a lightweight alternative to TCP since it does not

provide reliability or ordering guarantees, thus is fast (and often used for multimedia). WEP Wired Equivalent Privacy. An encryption scheme used in wireless 802.11 networks to

encrypt the payloads of the traffic in order to keep it protected from casual eavesdropping.

WPA Wi-Fi Protected Access. A stronger encryption protocol used for encrypting packets in wireless communications, (an improvement over WEP).

WPA2 Wi-Fi Protected Access 2. Will be included in 802.11i as the new security scheme available for wireless communications.

Historical overview

4

Historical overview The development of intrusion detection systems (IDSs) began back in the 1980s [17]. A paper called, “Computer Security Threat Monitoring and Surveillance” written by James Anderson introduced the concept that audit trails contained vital information that could be valuable in tracking misuse and understanding user behavior. It was from this paper that the concept of detecting misuse and user patterns was born. In the year of 1983, Dr. Dorothy Denning and SRI, started a government project which aimed to analyze audit trails from the government mainframes and create usage profiles from them. The following year she helped design the first model for intrusion detection: the intrusion detection expert system. Later on she released the paper called “An Intrusion Detection Model”, which is referred to as the basis for most of the work in IDS that later followed. In 1984, SRI developed a way of tracking and analyzing authentication information from the users of ARPANET, (the network that later evolved into the Internet), which later was realized into the first functional IDS. Meanwhile in 1988 at the University of California, the Haystack project produced an IDS that analyzed audit data by comparing it to predefined patterns. The Project evolved into a Distributed IDS that tracked client machines as well as the servers, and opened the way for the development of host based intrusion detection systems. In the ‘90s, the concept of network IDSs emerged, mainly from David Todd Heberlein. He was the primary author and developer of the Network Security Monitor, (the first network IDS). The NSM was deployed at major government installations where it analyzed the network traffic. Together with the DIDS and haystack development team, the stack based intrusion detection idea was introduced. Later on commercial products of these realizations were offered and different vendors have since evolved them with improvements and enhancements to become the intrusion detection systems that are available today.

Background

5

Background Confidentiality, integrity and availability are the three cornerstones of information security. Confidentiality should ensure that information or resources are not subject to unauthorized access. Integrity states that information or resources are protected from alteration by any third party, and availability describes that information or resources shall be available to its intended users. Non-repudiation is also considered as an equal part from which information security is built upon. It states that given a transaction, no party can in the future claim they were not a part of the communication. It is a way of digitally time-stamping the transaction, so that it in the future can be validated if concern arises. This notion of information security applies as well during the exchange of information across a network in order for it to be considered secure. The nodes connected to a network that pass data back and forth are under a constant threat since their data is constantly subject to violations of the four bases of security. Being in a networking environment and having multiple nodes to supervise, the use for a tool that automatically monitors the traffic for violations of the concept is needed. Intrusion detection systems aim at helping an administrator to know what threats towards the network exist and in what shape they occur.

Intrusion detection systems Intrusion Detection Systems (IDS) or Intrusion Prevention Systems (IPS) are the two most common technologies for monitoring a network for violations of the security notion. The IDS is a common word for grouping a technology consisting of various representations into one classification. Intrusion detection systems are usually called different things depending on which type is deployed. If the IDS is placed on a host that is interesting to monitor it usually is referred to as a Host Based IDS (HIDS), and if it is a stand-alone node inside the network, it usually is called a Network Based IDS (NIDS). If the IDS is a mixture of these two it commonly is called a Hybrid or Stack based IDS. To blur the nomenclature just a tad, different ways to investigate the packets can be used as well. Anomaly detection tends to find anomalies in the traffic flow, indicating potential intrusions, whereas rule based detection is the other major way. Mixtures of the two kinds exist as well of course. Placement of the IDS When deploying an IDS into a network, one needs to think about what the IDS should do for the network and what the purpose of using one is. What traffic should it analyze and what should it do if it detects malicious packets in the network traffic. A network usually consists of a firewall faced towards the Internet and behind the firewall, a DMZ usually lies (see figure 1). Inside this DMZ, a web server and other publicly accessible services are located. After the DMZ, a new firewall comes and behind it resides the internal network. This motivation for dividing the network into different parts is reasoned by using a layered security.

Figure 1. A typical layout of a demilitarized zone.

Background

6

If a web server is compromised, the affect it might have on the internal network is a lot less when it is physically divided from it, and by such means keeping the damages to a minimum. The placement of the IDS has a big importance in the capturing of malicious packets. Placing one inside the private LAN behind a DMZ would only allow the IDS to capture potential damaging traffic already inside the network. While placing it in the DMZ, directly behind the outer firewall, would allow the IDS to monitor all traffic aimed towards the services running in it, as well as the node behind the next firewall inside the private network. Placing the IDS outside of the primary firewall would allow all traffic to be analyzed, and not just the packets that made it through the firewall. Since the firewall will drop packets according to certain rules [6], many attempts to exploit vulnerabilities in the network inside the firewall will be silently dropped (see figure 2).

This of course is good in the sense of security, but leaves the system administrator unaware of the attacks directed towards the inner network that are dropped. Depending solely on logs from an intrusion detection system inside the outer firewall would therefore only show attacks possible given some degree of filtering, but not the whole picture. Some reports [18] as a result motivate that there should reside an IDS outside of the network as well as inside the DMZ to gain a whole picture of the attacks directed towards the network. Of course, such a picture is flawed since not all attacks towards a network would end up damaging it, simply because not all networks contain all services possible. For instance, a Linux server would not be subject to threats towards a Microsoft Windows 2000 service, and thereby such packets could be dropped by the primary firewall without the system administrator ever knowing about such attempts to break the system had occurred.

Figure 2. An IDS/IPS equipped network. Threat detection Investigating the network traffic flow for threats is a cumbersome job, especially when the amount of traffic passing through is large. It usually requires a lot of time and training before the system analyzing the traffic can be considered functional. Analyses can be performed in two major ways; anomaly or signature based intrusion detection systems [23]. Mixture of anomaly and signature based IDSs, as well as other techniques do exist too.

Background

7

Anomaly detection Anomaly based intrusion detection [19] is a technique used to compare the current flow of a network towards a profile of the network's behavior over a period. Given a sufficient time frame, analyzing the traffic passing through a specific point in the network, the generated traffic can be analyzed and classified. Considering that the traffic flowing during this time was normal and not out of order, a fingerprint of the network data can then be compared to that data in the future and if anomalies are detected, chances are that an intrusion is ongoing or at the very least something suspicious is going on. The drawback with this method is the fact that defining «normal» traffic is near to impossible [20], unless it would be entirely static. For instance, the degree at which an anomaly scanner can handle dynamic changes in the network flow, that is, more connections than «normal» to a web server is very important. Changes might be constituted from a potential intrusion, or might be explained by coincidence, or any other likely reason. Yielding false positives is not something a system administrator wants. (A false positive occurs when the IDS falsely classifies a legitimate action as potentially harmful). Moreover this technique can be subject to small subtle changes by injecting legitimate (or malicious) packets into the network, and thereby raising the bar for what would be classified as normal traffic and hence invalidating the whole purpose of such an IDS scanning technique. Signature detection Signature (misuse) based detection is a static way of comparing incoming and outgoing traffic packets for common phrases, words [21] or protocol specific parameters that are deemed threatening, and in some way notify concerned parties about it (most likely the information is logged to a file or a database). Since data can be fragmented due to small MTUs (Maximum Transmission Units) [22], the specified keywords that the IDS looks for, might be sent over several packets, making it all the harder for the packet analyzer to catch the bogus word in question. Drawbacks with signature based intrusion detections are numerous [20]. They quantify all packets not deemed badly as implicitly good, which means that unless the signatures stored of bad keywords always are up to date, it is impossible for it to catch any zero day attacks, (exploits found in the wild before or simultaneously as patches for the affected software are released). In other words, this signature-based database must constantly be updated, as must all of the software running on the network being subject to possible security breaches [3]. Network-Based IDS The network based IDS is a node connected to a network that analyzes the raw data packets that pass through or beside it. Usually the IDS utilizes a network adapter in promiscuous mode that listens and analyzes the traffic in real time as it travels across the network. A first level filter is often applied to determine which traffic will be discarded or passed on to an attack recognition module. The performance is greatly benefited by this technique since non-malicious traffic is filtered out and sent on into the network. Of course, no system is perfect and spoofed (forged) packets can even cause more trouble since the system believes that the traffic is authentic and hence bypasses the security mechanisms, or it could drop more packets than desired in belief that they were bogus. The attack recognition module typically relies on one of three different methodologies to recognize the malicious traffic signatures; patterns, frequency or anomaly.

Background

8

The network-based IDS can detect packets that are malformed and spoofed and can thereby detect a standing (D)DOS attack and perhaps perform actions before a Host-based IDS would start to check all the different logs that it monitors. It can also check the contents of the packets and perform actions based upon that. An imminent problem of course appears if the traffic is encrypted; The IDS has no chance of determining what is sent or received. If the packets are fragmented, the IDS might need lots of buffering before being able to merge the packets together in order to determine the contents being sent or received. The NIDS performs real-time detection and given that an intruder manages to find a way in to the network, the knowledge gathered by the NIDS cannot later be removed by the intruder. Even if the intruder finds a way to erase logs, that the NIDS created from the intrusion (if it discovered it), the intrusion is determined (more or less) in real-time by the NIDS and that is not something that the intruder ever can alter. This is in contrast to the HIDS, which might check logs of different programs in order to investigate if an intrusion took place, or not. If the intruder managed to remove or alter these logs, the HIDS would never know that an intrusion had occurred. If the NIDS is placed outside the outer firewall in a DMZ, it could pick up attacks that the firewall might block. If the NIDS did not report on these attacks, an overall picture of the threats towards the network would then be incomplete. Finally, the NIDS is not operating system dependent; it can work in any networking environment as long as it is correctly configured for dealing with the characteristics of the hosts its supervising. Host Based IDS This approach audits system logs for specific changes or if special commands are executed on the system, the HIDS will be notified and can then decide whether or not the trigger was from a real threat or not. The HIDS will most likely compare changes (in owner, permission, size, name, etc of vital system files) to a database where it has stored approved copies of the files (or signatures) and based upon that can determine what to do. These checks can be done in real-time as well as periodically if so chosen. Of course, the HIDS can monitor specific network ports and other channels that data can use when entering the network. Given the HIDS specific characteristics, it more or less reacts to actions that already have taken place rather than being strictly real-time. Since the HIDS audits logs, it can determine if an attack or exploit actually was successful or not. This yields less false positive reports. The HIDS can also monitor user log on/off activities, USB hot plugging and other hardware modifications of the local or network-based computer. If accounts are deleted, modified, added or similar the HIDS will catch this and typically react in some way. If traffic is sent within encrypted protocol bodies, the HIDS will be able to read the data in plain text once it is decrypted by receiving party. In addition, it can monitor system critical components, which could be an indication of whether the system has been breached (or is about to be). Stack Based IDS The stack based IDS, is closely integrated into the TCP/IP stack of a node. This allows the IDS to analyze the packets as they traverse the network stack. Being that it is so tightly integrated, it can drop packets or perform any other desirable action before the operating system or the receiving program process the data [16]. Analysis of the packets can be done using either pattern matching in the packets (i.e. looking for specific words or terms), or can check flags in the packets (i.e. bits in the protocol headers), and other identification techniques. Since the stack based IDS to such a degree is coupled with the TCP/IP stack, if it determines that a packet is encrypted, it can wait for the receiving IP stack

Background

9

to decrypt it. This will of course only work if the node receiving the packet and the stack based IDS both reside on the same computer. Then it can perform any check it desires with full plain text control over the data. Stack based IDSs can determine attacks in real-time and respond in real-time as well (as opposed to the HIDS). Thanks to this integration, the combination of both a HIDS as well as a NIDS into stack-based IDS will give the best protection against evil packets entering or leaving the network. Furthermore, it can ensure that hosts connected to the network are not compromised from the inside by the users or by mistake. Bayesian IDS Bayesian IDSs are still rare and under heavy research. The goal of BIDSs is to try to minimize the amount of false positives that are reported from the IDS when analyzing traffic [7]. When the false positives become too many, the IDS becomes worthless since people will stop using it and will instead become dependent on other tools for intrusion detection (and prevention). To do this the Bayesian engine needs training, and this can become a large and time-consuming task. Bayesian filters work by classifying the content and adding weights to each token (or word). If the product of each token in a given length (a sentence for instance) becomes larger than a given threshold, the tokens can be classified accordingly and measures be taken. However, this is something that initially needs to be supervised by system administrators in order to teach the filter how to distinguish attacks from legitimate traffic. The filter could of course be trained to accept malicious traffic, given that it was unsupervised over a longer period.

Intrusion Prevention System Intrusion prevention differs in one major aspect from intrusion detection systems. After it has detected an attempted intrusion, (by means of some exploit of the system for instance), it tries to diminish the affect such an intrusion might have towards the system. If the attacking host sends some data, that the IPS deems as malicious or a threat towards a node inside the network behind it, it could send a TCP FIN or TCP RST packet back to the attacking host as well as the targeted host and by so, prevent an attack from taking place. Unfortunately, things are never as easy in life as they are in theory. IPSs are and should be used with utter most care. If the attacking user when attempting to break into a system receives RST or FIN packets, the user could probably draw the conclusion that the network in question is monitored by an IPS. This gives the attacker a vital part of information regarding the protected network. The attacker could use the IPS against the network the IPS was set out to protect if the IPS is not carefully configured. Some IPSs will on-the-fly block IP address from attacking hosts on the outer firewall protecting the network, without more thought to what address they in fact are blocking. If the attacker spoofs the source address of the attacking packets to be the DNS or gateway of the network under attack, the IPS would instead be performing a DOS attack towards the network, effectively preventing any traffic from reaching the Internet after the addresses being blocked [28].

Background

10

Network monitoring In order for an IDS or IPS to monitor network traffic, they need access to the packets destined towards the nodes inside the network as well as the nodes destined outside it. In other words, they have to be positioned so that they can capture both sides of a conversation. Since the IDS or IPS (network or stack-based) needs to listen to the network traffic in order to discover threats towards the network, traffic monitoring is essential. Investigating traffic offline works just as well of course, though they will not capture any ongoing attacks. Different techniques to monitor wired network traffic exist, though depending on the traffic load as well as the cost of analyzing it, some solutions work better than others. Hubs for instance will not work well in a busy network segment due to all the packet collisions that will occur. Equally, deploying network taps might be practical and desirable but cost more than switches do. Port mirroring Port mirroring or SPAN (Switch Port Analyzer) [16] is a way of analyzing network traffic entering and leaving a network. Using switches in a network, depending on the manufacturer of the product, some will have an extra port, which can be used for copying packets from all other ports to one single port, or multiple ones, for redundancy, if so chosen. Connecting a listening node into the mirroring port would thereby allow the node to listen to all traffic entering the switch. The node could therefore passively monitor all traffic. Unless the listening node is specially configured, it would be subject to attacks directed to broadcast address for instance. Packets with bad CRCs, over or undersized header stamps will be dropped and never reach the listening node, which might complicate the determination regarding if an attack is under way or not. Network hubs When a packet is sent from a computer connected to a port on a hub, the hub forwards the same packet to all the other ports in order to attempt to provide a best effort connection between the sending and receiving host. The hub does not know if the other ports are different networks connected together by the hub, nor does it know if the receiving host at all is connected to the hub. Problems with hubs are that the packets passing through it tend to collide and thereby need to be re-transmitted. Evidently, the speed and throughput of a fully connected hub degrades by the number of hosts sending data through it. If a listening sensor were to be placed on a port of the hub, and listening for incoming packets, it would pick up all the data being sent back and forth over the hub. Since the hub sends packets to all ports, monitoring a busy network segment would render the hub very busy and performance would be low due to all packet collisions. Network taps Network TAPs (Test Access Port) is a port that allows for passive monitoring of network traffic. TAPs can either be stand-alone devices or built into switches. The TAP gives the NIDS the ability to view both sides of a full duplex communication. Furthermore, it reduces the amount of packet losses due to the hardware complexity involved. The TAPs do not copy packets, as port mirroring would do, rather it

Background

11

copies data from level one in the OSI model. (In other words, it splits the incoming physical medium into two parts; one that is sent to the receiving end and the other one is sent to a (for instance) passive listening IDS. Security for the IDS can be enhanced, since the listening IDS does not need an IP address so it can't be specifically targeted in an attack.

Networks Different network technologies of course have different characteristics and therefore a short summary here is provided for the reader to familiarize with the most frequent used technologies and how they differ. These characteristics are important in understanding why and how the IDS detects the various malicious packets. Ethernet Ethernet is a technology described in the IEEE 802.3 standard [23]. It was first developed for networks in confined areas (such as office networks), but because of its popularity, it has become a popular network technology used in WANs (Wide Area Networks). Each node in this network is connected to a shared medium (from hereon, called link). Since one link is sufficient for connecting all the nodes together, only one NIC (Network Interface Card) is required for a node to connect to all other nodes. Each node is identified by the unique MAC (Media Access Control) address on its NIC and a protocol called ARP (Address Resolution Protocol) is used to exchange this information between the various nodes in the network. Higher protocols such as IP (Internet Protocol) or any other similar protocol, acts as an intermediate level between the lower level ARP and the higher level TCP (Transmission Control Protocol) or similar where the application specific protocols are found. Data sent over such a network can be either unencrypted (plain text) or encrypted by higher level encryptions (SSL (Secure Sockets Layer)) or by the stack in IPv6 (Internet Protocol version 6) implementations. Address Resolution Protocol A common misconception among users of switched networks is that packets traversing in such an environment cannot be sniffed (captured), which of course is not entirely true. In the most basic network design, using hubs, they will send traffic from one port to all others in hope that it will arrive at the right destination. If one of the listening nodes sets its NIC in promiscuous mode, it will capture all the traffic, even though the packets' destinations differ from the listening host. In a switched network, the packets (hopefully) only pass from a source to a destination without visiting the other listening nodes. Unfortunately, higher-level protocols such as IP rely on underlying ones (ARP) in order to function. ARP searches for a MAC address on a network segment given an IP address and returns it to the inquiring host in question. Then the sending node labels its packets with the newly discovered ARP address when sending to the destination, thus no other nodes on the network will receive the packets. Of course, there lies an inherent problem in the ARP protocol: when a node first boots, it will (most likely) have an empty ARP cache. After communicating with hosts on the local network, it will eventually start filling this cache with new entries in order to speed up the communication between it and the other hosts. The problem with ARP is that it doesn't require any authentication when updating its ARP table, thus it allows all the clients on the network to send it

Background

12

regular updates regarding new MAC addresses that are bounded to a specific IP address. This design flaw allows for attacks against a client being, DOS (Denial Of Service), MIM (Man In the Middle) or MAC flooding. In IPv6, the neighbor discovery protocol is used to determine which nodes are next to each node in question, when it builds a table of network address matches to IP addresses. It also suffers from attacks similar to the ones for ARP, but different approaches [11, 12] are proposed to deal with this shortcoming.

Background

13

WLAN In this report, a Wireless Local Area Network (WLAN) describes a network connected by any of the various IEEE 802.11 wireless technologies and is used as a common word to describe such a constitution. Other wireless communication technologies do exist (infrared, Bluetooth etc), but will not be covered here. In order to avoid having all wireless networks communicate on the same frequency, the concept of channels was added to the 802.11x networks. Depending on which country the wireless equipment resides in (different countries have different legislations regarding the use of the frequencies), different amount of channels will be available for the devices to use. In Sweden, 14 channels are available in the frequency domain of 2.400 to 2.4835 GHz for 802.11b and 802.11g equipment. A overview of the most common frames used in the 802.11 protocol will be presented and the security schemes available as well for 802.11 networks. 802.11x standards The family of 802.11 contains many specifications of wireless technologies. Not all of the existing (or proposed standards) will be discussed since they neither are relevant nor widely deployed as of the writing of this report. 802.11 This was the original draft for a WLAN technology and was introduced back in 1997. It suffered from somewhat slow connections, a mere maximum of two Mbps. 802.11 operated in the 2.4 GHz band and could use either frequency hopping spread spectrum (FHSS) or direct squared spread spectrum (DSSS), two different ways of transmitting signals from sender to receiver. Network equipment using this technology is obsolete today. 802.11a IEEE expanded the original 802.11 standard with the extension of 802.11a in July 1999 (at the same time as they wrote the 802.11b specification). 802.11a operates in the 5 GHz band and supports speeds of 6 to 54 Mbps. 6, 12, 18 and 24 Mbps are mandatory speeds that manufacturers of 802.11a equipment must support. Rather than using FHSS or DSSS, it uses orthogonal frequency division multiplexing (OFDM), which enables data to be encoded, on multiple parallel high-speed radio channels simultaneously, (which means faster connections and better utilization of bandwidth). 802.11b When talking about WLAN today, either this or the 802.11g standard is generally regarded. This is the most commonly used standard today, but is slowly being replaced by 802.11g. 802.11b works in 2.4 GHz frequency band and has a physical maximum speed of 11 Mbps. The throughput lays around 5.0 Mbps due to interference and other issues [24]. 802.11b extends DSSS from the original 802.11 specification and includes higher speeds, which makes 802.11b a faster technology than its predecessor ever was. It was made to be comparable with Ethernet in terms of speed.

Background

14

802.11g To overcome the shortcomings in the 802.11b standard in terms of speed, the proposed standard 802.11g arose, but not until 2002 - 2003. It was designed to utilize the best parts of 802.11a and 802.11b to be the new improved standard for wireless communication. It works in the same 2.4 GHz band as the 802.11b standard. From 802.11a, the 802.11g standard took the speed and it supports speeds up to 54 Mbps. To achieve the speeds 6, 12, 18 and 24 Mbps, 802.11g uses OFDM and for the speeds of 1, 2, 5.5 and 11 Mbps, it uses the same DSSS as implemented in 802.11b. Protocol overview Aside from using different physical implementations, all the 802.11 specifications share the same method for sending and receiving packets in the wireless network. 802.11 networks work in two major modes; Infrastructure and ad-hoc. Monitor mode (or radio frequency monitoring) is a special driver implementation and not a standardized mode. The infrastructure mode is the most common one, where nodes connect to an AP (Access Point). The AP in turn is usually connected to a wired network, acting as leverage point for the wireless client to gain access to another network (office network of the Internet). Ad-hoc is a decentralized mode where the wireless peers connect directly to each other, not utilizing any central peer (such as an AP) to communicate. Lastly, the monitor mode (not available on all wireless devices), sets the wireless NIC in a mode where it can monitor all wireless traffic in reach. This is equivalent to wired NICs in promiscuous mode connected to a HUB listening to the network traffic passing through. Inner-workings For simplicity, the frames that are passed between a client and an AP will be divided into three categories in order to shed some light on how they work; Management, control and data frames. Management frames There are eleven different management frames, which can be transmitted in the wireless media. All except one of them form pairs, where each message has a request and a response message. All of these frames are sent in clear text and are available for monitoring devices. Sender and receiver MAC addresses are available as well. If an AP uses MAC filtering it could be circumvented by using any of these MAC addresses in transmit (given that the MAC address came from a packet that in some way indicated success in association with the AP). Authentication frame If a wireless node wishes to encrypt the traffic between itself and the AP (to which it is connected), it must negotiate an encryption scheme to use. The authentication frame is sent to the AP with the identity of the sender. If the AP is using open system authentication (no encryption), the client node only sends one authentication frame, and the AP will respond with its own authentication frame indicating either acceptance or rejection. On the other hand, if the AP uses a shared key authentication,

Background

15

the wireless node sends an initial authentication frame and the AP responds by sending it a frame containing challenge text. The wireless node encrypts the frame using its encryption key and returns it to the AP. The AP then decrypts the received encrypted frame with its shared key and compares it to the challenge text it sent the wireless node in the first place. If they are the equal, the AP sends an authentication frame back to the client node indicating success. Deauthentication fame If a wireless node wishes to end a secure (or open system authentication) communication with an AP, it sends a deauthentication frame to the AP in order to terminate such a setup. Association request frame If a wireless node wishes to use an AP, it has to associate with it first. It does so by sending the AP an association frame containing its supported data rates and the SSID (name) of the AP. If the SSID matches the AP in question and other issues (such as MAC address) are deemed correct, the AP reserves memory and establishes an association id with the wireless node. Association response frame If the AP finds that the wireless node in question may associate with it, it responds with the data rates that it supports and the association id of the association procedure. When the wireless node receives this frame, it can start to use the AP to communicate with other nodes connected to the same AP, or a wired connection the AP might be hooked up to. Reassociation request frame If a wireless node roams away from its AP, and finds another one with a stronger beacon signal, it may choose to connect to the new AP instead. Before connecting to it though, a reassociation frame is sent to the new AP, which lets the previous AP know that it has taken over the communication and asks for it to forward any buffered packets it may have waiting to be sent to the wireless node in question. Reassociation response frame The AP sends the wireless node a reassociation frame indicating an acceptance or rejection of the required reassociation. If it is accepted, the frame will contain supported data rates as well as the association id. Disassociation frame If a wireless node wishes to terminate its connection to an AP, it sends a disassociation frame, so that the AP in question can relinquish any allocated memory for that connection and free the associated id with that wireless node.

Background

16

Beacon frame APs periodically broadcast (addressed to the MAC broadcast address) beacon frames to announce its presence, SSID and other parameters. Wireless nodes tend to listen for incoming beacon frames in order to find an AP to connect to. This is optional though, and not all APs broadcast this information Probe request frame A wireless node, which wishes to discover all APs in range, broadcasts a probe request frame and waits for probe responses. When these responses arrive, they are used by the node in order for it to identify possible APs it can connect to. It can also be used in order to gain more information about a specific AP in question. Probe response frame An AP will respond to the probe request with a frame containing supported data rates, and other information, such as signal strength. Announcement traffic indication message frame This kind of frame is sent between wireless nodes (or APs), when they want them to avoid entering power saving mode since buffered data is about to be sent their way. Control frames Control frames are transmitted between wireless nodes (clients as well as APs) in order to assist delivery of data frames. Many different control frames exist, but only three (RTS, CTS and ACK) will be presented here, for a full list of them all see section 7.2.1 in [4]. Acknowledgement (ACK) frame When a wireless node receives a data frame, it responds to the sending node by sending an acknowledgement frame indicating success in receiving it, if the transmitted data frame was found to lack any errors. If the sending node fails to receive an acknowledgement during a certain amount of time, it retransmits the data frame in question. Request to send (RTS) frame The RTC/CTS function is mandatory, but aims to reduce frame collisions when hidden wireless nodes are associated with the same AP. The RTS frame is sent from one wireless node to another at the first phase of a two-way handshake necessary before sending a data frame.

Background

17

Clear to send (CTS) frame The other wireless node responds to a RTF frame with the CTS frame in order for the first wireless node to send its data frame. Included in the CTS frame is a time value which causes all other stations (including the hidden ones), to hold of any communications for the time period specified, in order to avoid frame collisions when the first node wishes to send its data frame. A hidden node is one that can communicate with other ones, but can not physically “see” them. Node A in figure 3, can send and receive data from node B, even though it can not see that node. Node B is said to be “hidden” from A (and vice versa of course). Data frames The whole purpose of wireless communication is to provide means for sending and receiving data. The data frames in the wireless media carry packets from higher layers (such as web pages or anything else) and do not provide any data themselves. Security schemes 802.11, 802.11a and 802.11b all support two forms of encryption: open system or shared key authentication. The open system as its name states utilizes no encryption on the packets what so ever and all packets and their payloads are sent in clear text. In shared key authentication, the same predefined key is used on the AP as well as by the client, and the payloads of the packets are encrypted with an encryption routine called WEP (Wired Equivalent Privacy). Using WEP, a client would start by sending an authentication frame to the AP. The AP replies with 128 bytes of random data that the client will encrypt with the shared key, and then returns back to the AP. The AP will decrypt the encrypted data and compare it to the original data that it sent to the client, and if they equal each other, the AP knows that the client shares the same WEP key [25]. WEP was never designed as being a strong encryption around the network data in 802.11 packets; rather it was designed, as being a scheme that should obscure the data, and protect it from passive listeners. The idea was that it should offer the same level of protection as people using wired connections could be expected to have. This meant that one should be able to use it for everyday activities such as surfing on the web and reading e-mails, but when dealing with sensitive information, other encryption schemes were to be applied, just as anyone using a wired network would do as well. As stated in the documentation of the proposed 802.11 draft, it was designed to protect users of a wireless LAN from casual eavesdropping [4]. Nevertheless, it was later superseded by the WPA (Wi-Fi Protected Access [49]) encryption, which offers a better protection. WEP uses a twenty-four bit IV (Initialization Vector) in each packet to let the other party in the conversation know how to decrypt the packet (WEP being a symmetric algorithm, the same key is used to decrypt as well as encrypt the packets). Due to bad implementations of the WEP algorithm, the IVs will be more or less badly randomized and thereby facilitate the breaking of it.

Figure 3. Node A and node B are “hidden” from each other.

Background

18

The IEEE released 802.11, 802.11a and 802.11b, which all supported WEP as the primary way of encrypting packets. The Wi-Fi alliance (the organization that standardizes Wi-Fi equipment), felt that WEP was of limited use and decided to develop a better encryption, which they did and WPA was born. Later on, IEEE adapted WPA as a newer and better encryption scheme than the old WEP and all new products of 802.11a, 802.11b and 802.11g support WPA as well as WEP. WPA uses TKIP (Temporal Key Integrity Protocol) [26] as a wrapper around the existing WEP encryption. It uses the same encryption routines and engine as WEP does. This time around however, the key used for encryption is 128 bits long, which addresses the short key length that WEP utilized. WEP supports 128 bit keys, but due to the IVs that WEP uses, the maximum key-length ended up being only 104 bits (the IVs use 24 bits). Another important improvement over WEP is that TKIP changes the key used for encrypting each packet and hence the temporal part of the TKIP algorithm. The key is created by mixing a number of things including a base key, the MAC address of the transmitting station and the packet’s serial number. Every transmitted packet encrypted with TKIP has a unique 48-bit serial number that is incremented each time a new packet is transmitted and is used both as the Initialization Vector and part of the key. Using a sequence number as the key ensures that a different one is used for every packet which solves another problem of WEP, called “collision attacks,” which could occur if the same key was used for two different packets. When different keys are used there is no risk for collisions. The “Replay attacks” of WEP are also addressed with the use of serial numbers as initialization vectors. Repeating a sequence number that is 48 bits would take thousands of years, yielding no luck for replaying old packets since they will be detected and discarded as out of order. The final improvement that was implemented was the use of base keys in TKIP. Even if TKIP lacked such a feature it would still be considered more secure than WEP, but it would not have addressed the most important one; the constant reuse of a well-known key by everyone on the wireless LAN. In order to mitigate this, TKIP generates a base key, which then is mixed into the key used for each packet. Each time a wireless node associates with an AP, a new base key is generated. The base key is created from hashing a special secret with some random numbers (called nonces) that are generated by the AP and the wireless node as well as the MAC address from the two as well. When 802.1X authentication is used, the session secret is unique and securely transmitted to the wireless node by the authentication server; when using TKIP with PSK-mode, the session secret is the same for all participating parties and never changes – hence is vulnerable to dictionary attacks. Some wireless adapters also support the use of AES (Advanced Encryption Standard) as the encryption scheme when using WPA. Officially, 802.11 adapters do not support AES natively, but an upcoming standard, 802.11i will. These products will be future compatible though, and that is the motivation for the release of such software and hardware. The 802.11i adds further strength to the encryption schemes used when encrypting packets. AES supporting pass phrases up to 512 bits will be used in the protocol. Furthermore, 802.11i supports key caching, which helps fast re-connections for users who temporarily went offline, and pre-authentication which allows fast roaming [27] and is ideal for use with advanced applications such as Voice over IP. WPA2 (the name that the Wi-Fi alliance uses for products certified according to the 802.11i standard) is the next advance in encrypting wireless packets. While both WPA and WPA2 support using TKIP for encrypting the packets, WPA2 demands the use of AES, WPA leaves it optional [32]. The authentication part of WPA and WPA2 supports two modes PSK for personal use and EAP-TLS for enterprise mode. The enterprise mode of WPA and WPA2 after an update now contains five different ways of authenticating a node (which uses methods ranging from client side certificates to SIM cards).

Background

19

PSK (Pre-Shared Key) works the same way WEP did. The same shared-key is present at both the client as well as the AP, and challenge text is produced in order to verify that they are equal. EAP-TLS [13] used in enterprise mode needs a third party for authenticating the node, and often a RADIUS server is used. Basically, the AP forwards all authentication messages between the RADIUS server and the wireless client, letting the external server handle all the authentication parts, taking the burden away from the AP to provide such mechanisms, see figure 4.

1

1 Image is courtesy of The Linux Documentation Project (http://tldp.org)

Figure 4. A client must authenticate before gaining access to the network beyond the access point.

Background

20

Security tools In order to verify the security status of the test network (presented in chapter test bed), different tools will be used, and a short description of each is presented below. Attackers as well as system administrators can use these tools to gain knowledge regarding networks. It is usually considered as a good idea for system administrators to run publicly available security tools and exploits similar to the ones used by intrudes. Using such tools might reveal vulnerabilities, exploitable issues or other security weaknesses of the network in question and can be addressed before intruders exploit them. Security by obscurity is one way of protecting assets in a network from intrusions, but is generally regarded as a bad idea. Mainly because once the obscured asset becomes known, the security falls and is subject to known attacks towards the asset in question. Removing banners from servers (for instance Apache/2.0.52 (Gentoo/Linux)), would in one way hide it from obvious identification, but passive analyzers exist as well which do not actively need to inquirer each service for its banner in order to determine what it actually is. The list presented in this thesis is not a complete list of available tools, nor does it in any way imply that the tools chosen here are the best to use. They are simply used because the author found them suitable for the tasks undertaken. Other programs or operating systems could be used just as well for testing the security of a wireless network. Snort Snort is an open source NIDS [1, 41] that also works as an IPS. The main motivation for the use of snort in this thesis is because it is licensed under GPL (GNU General Public License) [33] and thereby free of cost to use and modify. Snort uses a rule-based engine to classify traffic as either bad or good. It also allows for anomaly detection of the network traffic. Rules in snort can easily be added and snort supports the possibility to on-the-fly update and configure firewalls depending on the traffic that hits it. TCP Reassembly is a part of the snort engine that buffers packets and rebuilds them when they are marked as fragmented in order to detect attacks spread over several packets. Snort-wireless This is a patch [42] to the official build of snort (it now works for the 2.3.3 build 14 release of snort – the latest stable release). Nevertheless, the functionality that this adds is tremendous. Snort in its default “way” hardly supports the concept of WLAN, and that is why the need for snort-wireless was written and added. It can dump packets (raw from the IP packets) and allows rules to be written which better deal with this specific kind of networking. For instance, it can sort out all beacon packets, packets that contain a specific WEP key or any other 802.11x protocol specific parameter. Oinkmaster In order for Snort to work optimally, the rules it uses for detection of the malicious packets, needs to regularly be updated and maintained. Oinkmaster [43] is a program that automatically downloads the latest rules from different places on the web and installs them in the system. Furthermore, it can deploy these rules over multiple sensors in the network that snort might use to collect data. The rules are not signed with PGP, but MD5 sums are available at snort’s homepage for the compressed rule archives.

Background

21

Of course, these MD5 sums do not really provide any special means of security. The sum can be altered during the network transfer or snort’s homepage could from a client’s perspective be DNS poisoned and replaced by a fake one offering a different MD5 sum than the original one had. Kismet Kismet [44] is a tool that works with 802.11 layer frames. It sniffs traffic and somewhat work as an IDS. Moreover, it can also scan all channels for APs and give statistical information regarding them (such as IP address connected to the AP, SSID, BSSID (Basic SSID is the SSID used in ad-hoc mode) and so forth). Kismet also warns if a node sends a SSID probe request to an AP without joining it, which could be a way of detecting which APs exist in the area around the node in question. Furthermore, Kismet has the ability to decrypt WEP packets on the fly if the key is presented to it and can if chosen create a FIFO queue, which snort can actively monitor in order to analyze encrypted packets for possibly malicious content. Airsnort Airsnort [45] is a tool used for listening at network packets in wireless networks and printing out the WEP key used in the transfers. Since WEP is proven weak, after a certain amount of re-used IVs are sent, Airsnort will need anything from 100.000 to 10.000.000 packets before it can show the key used. Aircrack In a package containing various programs, aircrack [46] and airosnort can be found. Airosnort collects all the data that it monitors, and dumps it into a file, which aircrack then uses in order to break the WEP key. Airodump also prints a neat list of all wireless nodes in transmit, which channel they are speaking on, what SSID and BSSID they have and if the traffic is encrypted or not. Arpwatch Arpwatch [47] maintains a database of Ethernet MAC address seen on the network, with their associated IP pairs and notifies if duplicates are found or changes to the local NIC are made. Some kernels have this functionality built-in as well as a module that can be dynamically loaded or unloaded as found chosen. Advanced Console for Intrusion Detection (ACID) In order to easily overview the collected alerts from snort sensors, a web-based tool called acid [51] is used. ACID breaks down the attacks into protocol, belonging, frequency and other statistical groupings. Using this tool helps a lot in understanding what attacks directed towards the network has been subject to as well as categorizing them in easy ways to grasp.

Background

22

FreeRADIUS FreeRADIUS is a server that accepts network connections from clients about to authenticate towards a network [48] and provides a way for the network to grant or decline them access. One major accomplishment that FreeRADIUS provides is that authentication of nodes connecting to the network is administrated centrally from one point. If users are added or deleted, and should have access to various services inside a network, it is sufficient to update the server instead of updating several places instead. nmap Nmap is a security tool [56] that scans a network and tries to determine what hosts are available (up and running), what services they are running (names and versions) and what operating systems they are using. Furthermore, nmap also determines what packet filter/firewalls are in use and lots of other characteristics. Once the hosts have been scanned, vulnerabilities available for them can then be downloaded from the Internet and executed in order to compromise them. Nmap can perform a range of different scans (see table 1). One of the characteristics of nmap scan packets, is that the TCP window size always takes upon one of the four values, 1024, 2048, 3072 or 4096, which makes it easier to discover these scans by an IDS (given that the nmap source is not recompiled of course). Table 1. Different scan types performed by nmap for mapping a remote host

Nmap scan Explanation -sF Stealth FIN (FIN bit set) -sN Null scan, uses no flags -sP Ping scan (finds any reachable machines) -sR RPC scan. SYN flag sent to RPC TCP ports. -sS TCP SYN stealth port scan -sT TCP connect() port scan -sU UDP port scan -sX Xmas scan, uses FIN, PUSH and URG flags

Ethereal When monitoring traffic, being wireless, wired or anything else, ethereal [52] is a handy tool for presenting the captured traffic in a logical and sensible way. Ethereal is coupled with numerous protocol dissectors, which show what the bytes of the captured packets are used for, and the parameters used. It can for instance follow TCP streams and show how the communication took place and allows strong filtering of the captured packets in order for the viewer to analyze only the interesting data and not everything that was captured. MySQL Mysql [50] is a GPLed database, which is free to download, change the functionality in and in any way use. The database is used for collecting all snort sensor logs in one central place.

Background

23

Threats The threats aimed against an AP will come in two shapes; Firstly the ones aimed at attacking the AP itself, or sniffing the packets entering and leaving the AP. Breaking the WEP key used in transmission, disassociation of clients with their APs and redirecting them to new APs might also be undertaken. Secondly, attempts gaining access to nodes inside the network behind the AP are at stake as well. This involves more “conventional” cracking towards the inner workings of the network. WLAN attacks Attacks towards the wireless medium need to be classified and dealt with in a different way than the wired equivalents, mainly because they work in different ways, and the attacks are often medium dependent. Sniffing traffic Packets sent in the plain air are more vulnerable of being captured by unauthorized users than in wired environments. Given the possibility that the user does not encrypt the packets with some algorithm, the packet will be readable and any sensitive data being sent or received is open for public disclosure. Therefore, sending or receiving data through a wireless NIC is a security risk to be considered. Disassociating nodes from APs Clients connected to APs send different messages in order to uphold the communication link. When a node wishes to be unassociated with an AP, it sends a disassociation packet to the AP in order for the AP to relinquish memory for that connection, and let it maintain an up to date list of current connections [24]. Since the disassociation packets are not authenticated, a malicious user could send these messages to an AP to keep a node from being associated with it, and thereby make it subject to a DOS attack. Breaking WEP keys Since the protocols used when communicating in 802.11 environments, must state which security protocol is used during transmit, a user listening to such a communication can easily detect what encryption scheme might be used. If the used scheme is WEP, breaking the key and decrypting the packet in order to view the contents is no harder than passively listening for packets a couple of minutes and then run a program that breaks it. If the communicating parties use a higher level of encryption, (IPSec or SSL) the contents will still be encrypted, which not necessarily means that the packets easily can be decrypted, even if the WEP key is found.

Background

24

Dictionary attacks against WPA-PSK Using WPA, the encryption scheme is magnitudes better than WEP. WPA uses the TKIP implementation so breaking the key is a lot harder than for WEP and requires brute forcing the packets with a dictionary attack. (Simply test every possibility of a password and see if the packets captured can be decrypted or not). Fortunately, the amount of packets gathered to break WPA is limited to just a couple. WPA has a four way handshaking procedure between the client and AP where the challenge text and other parameters are passed (source and destination MAC addresses), and if this handshake is captured, a brute force attack against it might be possible. Of course, in order to gain access to these packets, a malicious client can send disassociation packets to the AP in order for the client in question to become disconnected from it. It most likely will reconnect to the AP, and once again, the four-way handshake procedure will be passed back and forth, and can be captured by a monitoring client. Message integrity check denial of service During the four way handshake procedure of WPA, a parameter called MIC (Message Integrity Check, which is a replacement and improved version of IVs used in WEP), is created. The MIC is created from the source and destination MAC address and with these values present in each packet it is easy for the AP to detect forged (spoofed) packets. The MIC is created using a function called Michael, which uses a built-in protection against brute force attacks. If any attacks are directed towards the MIC, the AP will disconnect all of its clients for one minute and change the password. The tradeoff problem present is that only two invalid MICs during one minute are required in order to cause such a behavior from the AP. A wireless node could with no elegance, cause a DOS attack towards the AP and all of its clients by repeatedly sending packets with bogus MICs. ARP attacks As earlier described, ARP is the grease and magic which makes Ethernet work. Being such an important entity, it by definition is the cause of many different attacks. When sniffing wireless packets flying around in the air, the MAC address of the sender and the receiver are stamped into them. This lets an sniffing attacker learn the MAC address in the network and can thereby either perform any of the above mentioned attacks in order to capture interesting data, or it would allow the vicious user to gain access by defeating any MAC filtering in a firewall or an AP. Denial of Service A malicious user on a local network could broadcast ARP replies to all the nodes saying that the new MAC address of the default Internet router is some bogus unused address, thus rendering the network unusable since all traffic will be sent into the great bit bucket in the sky [34]. Of course the evil user could just as easily redirect all the traffic towards a legitimate MAC address thereby flooding that client's NIC with lots of garbage data destined for the Internet.

Background

25

Man in the Middle An attacker in a switched network, who wishes to sniff traffic between two nodes, could use a technique called MIM attack against the two nodes by exploiting the weaknesses in ARP. By sending packets to one node stating to be the designated target of that node and doing the same thing with the other endpoint, the attacker could make the traffic flow through his computer (by utilizing IP forwarding for instance) and thereby sniff all the packets without the sending and receiving host noticing this, unless they were using some ARP monitoring software to ensure the correctness of the ARP addresses in the cache. MAC flooding When switches become overloaded with packets, they often revert into acting as a simple hub in order to minimize the delays and dropping of the packets. When the switch acts like a hub, the packets are thereby once again available for sniffing by the other nodes on the network. In order for a switch to act like a hub, the switch's ARP cache must be flooded with millions of ARP replies (bogus or authentic) in order to fill them up. When the switch's ARP cache is full, it cannot find the right recipient's address and thereby broadcasts the packet in order to avoid dropping the packet. (This of course is highly vendor specific and does not apply to all switches).

Security requirements

26

Security requirements In order for a network to meet a desired level of security, the necessary requirements must be set to meet these criteria. The definition of a secure network is vague and hard to realize, but by setting bounds on an acceptable system, the realization might actually be possible. No network is ever more secure, than its number of flaws. In order to make a network 100 percent secure, it would need to be disconnected from the Internet and locked up inside a secure vault with no means of communication to it. Unfortunately, it would be hard to use. In general, all software contains flaws and bugs [29], and all the user or owner of a network can do in order to minimize the chance of being subject to attacks, is to choose a system that is as secure as possible and use other mechanisms in order to protect it from threats. Whenever security is imposed by regulations or by policies, the reason for its existence must be motivated. If security is enforced due to securing the network just for the heck of it, or because it really is needed, will ultimately reflect the way it is implemented. There is always a tradeoff between security and usability and neither can be said to be more important then the other. A 100 percent secure system that nobody can use is useless and no good to the users. On the other hand, designing a system that is very easy to use with no or few security mechanism used could easily be misused and be subject to intrusions. In the setup and testing of the proposed network in chapter test bed, a good balance between the two camps will be sought, but security will have the higher precedence in case of conflicting interests.

Security enforcements During the setup and testing of a network against various threats, various security enforcements will be used to some extent. The use of security schemes will depend on how they work with the underlying operating system as well as each other. In the rare case of non-interoperability between the various schemes, they will be weighted according to the following criteria; security schemes that require special hardware are deemed least important whereas software modifications and network configurations are rated highest. In order to deem a network and its connecting nodes as secure, not all of the mentioned schemes need to be applied in order for it to be considered so. The more layers of security that are used, the more secure the network might be. Of course using all methods available still does not ensure security in its most basic notation. Using bad or weak passwords, miss-configurations or other bad choices in the deployment may weaken the overall security by magnitudes. A major flaw in secure networking comes from system administrators’ belief that their network is secure because they have deployed security measures without understanding how or why they are needed and work. A false sense of security is dangerous and needs to be dealt with in order to minimize the chance of the network being subject to threats. Encrypted traffic The traffic flow between a client node and the network, to which it is connected, should be encrypted to ensure privacy. No matter what kind of traffic is being passed, it is crucial that the communication is encrypted in order to avoid eavesdropping. There are many different schemes available in order to encrypt traffic. The million-dollar question regarding which encryption to use boils down to what

Security requirements

27

hardware is used and how strong encryption is required. If the hardware is light such as in cellular phones, perhaps application encryption is the only option. In other cases, hardware may have built-in encryption that can do the calculations needed or a combination of the both can be used. Virtual Private Networks (VPNs), IPSec enforced in the IP-stack, WPA, SSL [30] or SSH, (Secure Shell) can therefore all independently (or cooperatively) be used given the node's configuration. WEP is questionable to use, given the insecurity of its implementation and design flaws. Certificates In an ad-hoc network environment, the need for new clients to authenticate towards a master server becomes vital, as more nodes are connected and the network grows. Instead of deploying the same shared key using WEP, WPA or WPA2 for all clients, a better solution exists namely, 802.1X. 802.1x is a standard developed by IEEE [5] that supports authentication of supplicants (wireless nodes) by an authenticator (for instance an authentication server). The standard names many ways of authentication, but digital certificates will be discussed here. If all clients create digital personal certificates and let the authentication server house a certificate authority (CA) on board, all clients can verify their identity by simply sending their certificate for authentication. The network traffic can still be encrypted by means of some shared key or by using EAP-TLS, but the wireless nodes without digital certificates will not be able to authenticate with the authentication server and hence are shut out by the AP for access to the network it is guarding. If a wireless node with a digital certificate came into wrong hands, the CA could simply invalidate the digital certificate and the rouge user would not be able to use the network. To secure the digital certificate handling another tad, the certificates could be accompanied by a password for unlocking them and thereby just having the certificate would not do any user any good – they would also need the password for it. Secondly, sending certificates lacking a password over a network could be sniffed and maliciously used. Hence the motivation for using certificates with strong passwords is a good idea. MAC filtering Even though MAC filtering in practice is worthless and limited in what it can do, it still serves a purpose. Given that a node uses a forged MAC address (that it in advance knows it permitted use of the AP) and tries to connect to an AP, the AP will stand chance less towards such an attack. However, if an IDS sensor is placed close to the AP, it might detect that duplicates of the same MAC address is being used and alert on this. On the other hand, any node which fails to change the MAC address will successfully be blocked by the AP until they change it to any accepted one or by other means circumvent such an access control list. DHCP (Dynamic Host Configuration Protocol) Nodes connected to the network will be handed an IP address when authenticated by it. Either the AP will forward IP addresses from the internal network’s own DHCP [28] server or it will serve as a DHCP server itself. Each node will be served an address from a pool of available IP addresses and typically after a certain amount of time the address usually is renewed or changed to a new one. Dynamic IP addresses are usually used when the network’s topology often changes, or when the amount of nodes, which can connect to the network, exceed the number of address available in the

Security requirements

28

network’s IP range. The number of address that are publicly available in the IPv4 network are scarce, and DHCP was one attempt to circumvent this shortcoming. NAT (Network Address Translation) or CIDR (Classless Interdomain Routing) are other techniques to perform the same task. NAT allows a local network to share one externally public IP address for all its communication, by letting a host translate all internal connections to the external ones. This way, the network only needs one public IP address. CIDR is a technique [2] where the network part of an IP address can be any number of bits long, rather than being constrained to 8, 16 or 24. A CIDRized network address has the dotted decimal form of a.b.c.d/x, where x is the number of leading bits that constitutes the network portion of the address. This means that networks do not need to be only A, B, or C class networks. Logging Figuring out which node was responsible for sending which packet in a network is important when analyzing intrusion attempts or otherwise maliciously deemed activities. Therefore, if the network uses a DHCP server for assigning IP address, each lease must be logged with the corresponding MAC address, in order for later location of the node in question. Typically, an IDS sensor in the network, would equally log any traffic if found potentially damaging in order to assist any forensic analysis later undertaken. Given the easiness it takes to change the MAC address of a NIC, nodes would have to be locked down (security-wise), in such a way that changing it would be impossible or at least very hard. Spoofed source or destination MAC addresses in IP packets may be hard to protect the network from, and given the fact that MAC addresses more or less constitute the very ground that Ethernet networks are built upon, this is an important issue to consider when securing the network. Extensible Authentication Protocol The need for authentication schemes in a PPP (Point-to-Point Protocol) network was added by EAP. EAP [9] allows a node to be authenticated by numerous ways including; token cards, one-time passwords, public key authentication using smart cards, certificates and other things. If the node allows for any of these external means for authentication (an USB memory stick containing a private key used for unlocking the node for instance), it would boost the level of security achieved by several notches. In wireless communications using EAP, the AP to which the client wishes to connect, authenticates the user by forwarding the credentials provided to a RADIUS (Remote Authentication Dial In User Service) [10] server. In the test network used, certificates will be used as the primary way of authentication towards the RADIUS server.

Test bed

29

Test bed During the tests and setup of the network used for testing, the operating systems Linux and Windows XP were used. There is no particular reason for this choice besides the author’s own taste and the number of programs available to use when testing networks, for the operating system Linux. Usage of any other operating system with the same or similar software should yield the same results nonetheless. The choice of Access Point is rather unimportant as well, but it must support WPA, RADIUS authentication, MAC filtering and DHCP. The network is comprised from five nodes each with different purposes and functions, see figure 5. Two snort sensors are used, one server is used for authentication, one contains a mysql database where all the alerts from snort are stored, and finally one is a client connecting to the AP. In order to minimize the need for more computers than necessary, some of the functionality has been combined on the same hosts. In a configuration and deployment in the “real word” of such a network, this would not be the case. In order to reduce the chances of hostile take over of any of the hosts, spreading the tasks over multiple nodes would reduce the chance of an successful take down of a node to a minimum. Regarding the layout of the network, it is obvious that it lacks both a firewall and a DMZ. Using a firewall in the test network would not have any purpose since no attempts to gain access to the network that a firewall could prevent would be attempted. Secondly, no DMZ is present simply because there was no time to set one up between firewalls, but one could consider the network itself to be a DMZ, behind a firewall in the local network. However, in a real world configuration the AP would be positioned inside a DMZ guarded by firewalls. Firewalls and intrusion detection or prevention systems are not mutually exclusive in a network environment. They should not replace each other and the reason is obvious; The firewall and the IDS/IPS has different roles to play in a network configuration. The firewall should block unauthorized connections from the Internet (for instance), while the IDS/IPS should detect potentially harmful traffic destined towards the services within the DMZ or the internal network. A firewall classifies traffic as either allowed or disallowed. Traffic destined to allowed ports are forwarded into the DMZ and LAN while traffic destined to unauthorized ports or coming from illegal IP addresses are dropped. Once the traffic matches the IP address/port specifications, from the firewall’s point of view the traffic is all okay. Needless to say, just because traffic makes it past the firewall does not imply that it does not contain a harmful payload. This is the reason for deploying an IDS. Since the IDS examines the contents of the packets as well as its characteristics (IP address, source and destination port, header flags etc), if data is found to be possibly dangerous, the IDS will somehow notice this and act upon it.

Figure 5. Overview of the test network.

Test bed

30

Therefore, the IDS and the firewall should co-exist and should be deployed as complements to each other, rather than competitors. The first node in the network is the Windows XP node, which plays the role of a client computer which connects to the AP, and uses a RADIUS server for authentication. The client can if it succeeds in authenticating, access the Internet through a local network beyond the AP. Logically it would be just as easy to use a Linux node in order to connect to the AP using WPA supplicant [38] (a user space daemon which provides the extra functionality of 802.11i) but for simplicity following the guide in [35], Windows XP was chosen. The two snort sensors are motivated as followed: One sensor monitors the wireless communications taking place and the second monitors the traffic that leaves the AP destined towards the LAN and the Internet. One major problem that arises when sniffing the wireless traffic is that all packets that leave the client and reach the AP are encrypted with TKIP using a 128-bit key. Breaking such a strong encryption in order to peek into the packets and see what they contain would be from a snort sensor’s view very interesting. Unfortunately, as of writing this report, no options in neither kismet, snort, ethereal nor any other tool exists that would make this possible. Fortunately though, given that the client and the AP setup an encrypted communications link, monitoring the packets that leave the AP destined towards the internal LAN will reveal any possible damaging packets. Therefore, a network administrator can presume that the network is checked for intrusions even though the traffic is partly encrypted. In order for the snort sensors to have their alert logs saved in one central place, a database is used where they are all collected. As of the writing of this thesis, snort-wireless and ACID do not work well together. The wireless packets that are captured and analyzed do not contain IP headers and therefore ACID does not present such alerts for the administrator viewing the overview presented by ACID. This is a known bug and will hopefully be fixed in a future release of snort-wireless. This means that the intrusion attempts are logged and available in the mysql database, but when using ACID to overview the threats, they will not be visible. Finally, the last node used in the setup is the one that contains the RADIUS server. This server has the responsibility of authenticating the wireless client that attempts to connect to the AP. The server also contains the CA, which is used by both the client as well as the server in order for them to mutually authenticate each other.

Wireless client The wireless client runs Windows XP as the operating system of choice with service pack 2 installed and all hotfixes available as of 2005-06-28. The client has two certificates installed as well. The first one is the CA, which is used to validate the genuinity of the server certificate that the RADIUS server sends them when they mutually authenticate each other. The second certificate is used when the client authenticates with the RADIUS server. If the certificate for some reason ever was revoked the RADIUS server would notice this when initiating the communication with the client and would not let it enter the network. When installing the personal certificate, a password is used for enforcing that no one maliciously uses it without permission, (or has knowledge of the password). Unfortunately, when using a personal certificate for authentication in Windows XP, the password that followed the certificate can not be used each time the certificate is used. A checkbox is provided when installing the certificate if a password

Test bed

31

should be presented to unlock it every time it is used (in order to make the certificate more secure), but this will not work when using EAP-TLS as a way of authentication in Windows XP. Furthermore, even though both the device driver of the wireless NIC used as well as the AP in question supported AES for encrypting the packets, Windows XP does not. It simply fails to work without any sensible information as to why, and so TKIP is used for encrypting the packets.

Snort sensors Snort version 2.3.3 is patched by snort wireless version 2.3.3-sgracia. The 2.3.3-sgracia patch adds one major advantage when analyzing wireless traffic from the original 2.3.3 release of snort; the support for using the keyword wifi in the rule files. Since snort works by classifying traffic according to certain criterions such as traffic being TCP, UDP and so on, using the wifi directive lets snort know that the packet should be matched to the specifications of a wireless one. In this way simply checking for a deauthentication packet is simple, see figure 6. alert wifi any -> any (msg:"Deauthentication"; stype:STYPE_DEAUTH;) Figure 6. Snort alert of a deauthentication packet. Alert is a classification of the detected issue and means that snort should not just merely log the problem but should perform any action defined in the alert directive as well. The first any in figure 6 means that any port is valid in order to match the rule, (note that this also includes port 0). The direction is specified by the arrow pointing to the right, indicating that the traffic flow should be from the left towards the right. Other valid directions include <> meaning both directions. Following is another any, which again means any port. In contrast to the rule in figure 7, which alerts on malicious http traffic destined towards a web client, a specific port as well as IP address is used when declaring the rule. The variable $HTTP_PORTS is declared in the snort configurations file and is set to 80. $HOME_NET and $EXTERNAL_NET are defined in the configuration file as well and are set to any and !any (not any – external net and home net usually are different, and hence the negation). alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"WEB-CLIENT JavaScript URL host spoofing attempt"; flow:to_client,established; content:"javascript|3A|//"; nocase; reference:bugtraq,5293; classtype:attempted-user; sid:1841; rev:5;) Figure 7. Snort alert of malicious data in a packet destined towards a web server. Snort-wireless also enriches the rules by adding the subtypes available in wireless communication. It also adds support for detecting rouge APs on the wireless medium, programs scanning for APs, de-authentication and authentication floods directed towards the AP and its wireless clients. The latter has not been tested even though a plethora of tools for generating such floods exist (the author was unable to successfully compile any of the available programs). Both of the snort nodes resided on the same computer. The host operating system was Debian Linux [55] with kernel 2.6.9hipl [54]. The reason for using the 2.6.9hipl kernel was due to the node being collaboratively used by the b2ncw project, which needed such a kernel. In order to utilize stable and development versions of the software used, various packages of Debian were mixed together in order to support a stable yet wide spectrum of applications used during the thesis. Debian sarge, sid and unstable were all used.

Test bed

32

In order for the wireless part of the snort-wireless patch to be included in the patched build of snort, the parameter --enable-wireless was issued during the configuration part of building snort. Furthermore, since the sensors were to log their reports to the mysql database, the command --with-mysql was also entered during the configuration. In addition, snort supports the writing of captured packets into a pcap file as used by ethereal. Given that this might come in handy during possible future forensic investigations, the source code for the latest stable build of ethereal was downloaded, so the snort configuration script could include ethereal’s header files when building snort. Finally, the mysql source code was downloaded as well in order for snort to utilize some of its include files which it needed in order for it to successfully compile for support for saving the logs to the database. Bundled with the snort-wireless patch were two other important files. Firstly, a new rules file called wifi.rules, which contains wireless specific rules that the new patch can utilize was installed into the system and entered in the snort configuration file for rules to use. This file contains lots of entries but not all of them are useful. Only the entries regarding, authentication, deauthentication and disassociation were used, the rest were commented out. Multiple entries on any of these entries in the alerts file indicate that either a client, if having severe issues with the wireless communication (bad certificate, network key, preferences or similar) or the traffic, is being subject to an attack in some way. Secondly, a newer snort.conf configuration file was installed. The new configuration file contains multiple entries used by the new wireless patch. First of, if the network has APs, they can be entered here in order for the analyzer to easier understand the traffic that it monitors. The channel that the AP uses can also be entered here in order for snort to avoid channel hopping in order to locate traffic. The configuration file also contains different ways for detecting various wireless DOS attacks. Disassociation, deauthentication and other similar floods can be classified by setting a threshold of allowed such packets, during a given time frame in order to detect such attacks. By default these are disabled in the configuration file and were kept so, since no programs for generating such packets were available for testing. See appendix A for a full listing of the snort configuration file. The wireless network interface, eth0, was set into monitor mode by issuing the command “iwconfig eth0 mode monitor”. The network device driver used was orinoco [53]. In order for a wireless NIC to be set in monitor mode, the running kernel must support Linux wireless extensions greater than 16 [39]. In this mode, the driver will not drop any packets not destined towards it, meaning that all traffic towards the AP can be sniffed and analyzed for potentially hostile traffic. The other node listens through promiscuous mode for all incoming traffic from a hub that it is connected to. The hub is also connected to the AP, which forwards all of the wireless traffic towards the LAN. Utilizing the hub, even though it may be considered bad from a perspective of speed and throughput, it is cheap and easy to use (and it was the only available hardware to utilize for the thesis tests). Both snort sensors report all malicious activity towards the mysql database running on the same host. Furthermore, the wireless snort sensor also stores the alerts in a log file in the directory of /var/log/snort/alerts. This makes it easier for the system administrator to analyze the threats presented from the wireless medium since they will not be shown in the ACID overview. One easy way to determine the contents of the alert file is by utilizing the rich script possibilities often available in most Linux distributions. For instance, periodically checking the contents, occurrences, or size of the log file could indicate that threats towards the wireless traffic, AP or both might be performed.

Test bed

33

Snort sensor one and two were run with the parameters described in figure 8. snort -i eth0 which interface to listen on -c /etc/snort/snort.conf where snort stores the configuration file -U use UTC time stamps -d dump the application layer Snort sensor two was run with the same parameters except is used –i eth1 to indicate which interface it should listen for the packets on. Figure 8. Command line parameters for the snort sensors.

MySQL database The mysql server version 1.0 was installed through Debian’s apt-get [40]. In order for snort to successfully store its values in the database, tables for the entries had to be made. Thankfully, creation of these already existed in various scripts that are shipped with snort, see appendix F. (Snort supports oracle and Microsoft SQL as well, but due to the nature and cost of those alternatives, mysql was used). Following the guides presented in [36, 37] the snort table was created, a mysql user called snort and the permissions needed for it to alter the tables was also set.

The FreeRADIUS server The RADIUS server is installed on the last host in the test network. It was downloaded and compiled from source code version 1.0.4 [48]. The configuration of the RADIUS server and the creation of the certificates used in order for the EAP-TLS connection to be setup were performed according to the guides in [35]. See appendix B for a full listing of the configurations. Two files that are shipped with FreeRADIUS had to be modified in order to make the setup work as intended. First off, the file eap.conf (see appendix C), was modified to let the server know how the inbound traffic would appear and what parameters specific to such a constitution would look like. In the section of EAP, the default scheme was set to TLS. In the TLS section, the CA file, the server certificate, the shared network key, the client key, and certificate were set. These are used by the RADIUS server in order for it to perform validations of the client’s certificate upon request from the client to authenticate. Unfortunately the password in the eap.conf file for unlocking the server’s certificate is saved in clear text, which from a security perspective leaves more to wish. Not even a hash is available as an alternative for saving it, but no other alternatives exist. Finally, the file clients.conf (see appendix D) was altered in order to set permission for the AP to communicate with the server. The IP address of the AP and the shared network key were entered in this file so that the AP and the server could encrypt and decrypt the packet using the same key. Security wise this is a bad design, saving passwords in clear text on a server. However, no alternatives exist to solve this problem, and the only thing that was done in order to secure the file as much as possible was to the set permissions of the file to read-only for user root. Neither group nor everyone can neither read, write nor execute the file. In the radius configuration file there is a section where an optional lower privileged user can be entered.

Test bed

34

When the RADIUS server first starts, it reads the configuration files, including the root-read-only files with the clear text passwords and then degrades itself to a lower privileged user. The reason is simply because, if the server becomes compromised or taken over in some way, the user rights that the attacker inherits from the running process lacks all fancy system administrator rights, and the damage than can be performed is limited to the user’s files.

Openssl In order to fully utilize the power of 802.1X authentication, certificates were needed and had to be created. Three certificates are needed in order for the setup to work optimally. Only two would be needed if a CA was available for usage, but creating a new CA for this test bed was easily done. First the CA is created. Its purpose is to sign the certificates that client and server use in order for them to mutually authenticate each other. Certificates can be created with or without passwords as well, but in this test setup they are created with passwords and all passwords are set to “whatever” in order to minimize the confusion a forgot password might cause. See appendix e for the creation of the different certificates. The CA certificate as well as the client certificate are then copied to the client in order for the client to authenticate towards the RADIUS server upon establishing a wireless connection. The server certificate is used by the RADIUS server (and the CA certificate as well) in order for it to authenticate itself towards the client. The motivation for this is quite simple. If a rouge AP was used in the same environment, and if the legitimate AP in some way was rendered inaccessible, upon authenticating to each other, the client would notice that the certificate that the server was using was not signed by the CA. Since the same CA is used to sign the server and the client certificates, the client would refuse to complete the authentication process and hence would not be tricked by a rouge AP to reveal its user credentials. Similarly, if a wireless client tries to connect to the AP with a bad certificate (one not signed by the CA), the RADIUS server will deny it further access to the LAN which it guards. Following the guidelines presented in [35] and using version 0.9.7g of openssl, the certificates were created.

Access point The choice of AP was very easy. The only one available for testing purposes was a Linksys WRT54G with firmware version 3.03.1. The access point was configured to use WPA-RADIUS and TKIP for encrypting the packets using the shared key (password) “whatever”. DHCP was achieved by configuring the AP to act as a DHCP server for its wireless clients. The AP in turn received an IP address from the LAN's DHCP server, which made it possible for the wireless nodes to communicate with the internal network. The channel was set to 13, for no special reason and traffic is allowed from both 802.11b as well as 802.11g adapters. MAC filtering is enforced, and two wireless nodes are the only ones allowed connecting to the AP, namely the two used by the wireless test client. Most APs have a name that the wireless clients can use to associate with it and in this test setup, the network name of the AP used is “HelloWorld”.

Test bed

35

nmap Nmap version 3.81 was downloaded and used for running XMAS attacks towards nodes in the test network. The purpose was to gain knowledge regarding the building blocks of the network as well as determining if the snort sensor could detect such information gatherings.

Kismet Kismet was run on an interface of a wireless node situated between the wireless client and the AP in question. Having its wireless NIC set in monitor mode, kismet was able to listen and analyze the packets passing back and forth in the air in a nearby location to it. Kismet was run using the standard configuration settings except, that suid was set to the current non-super user running the program and the capture source was set to orincoco, eth0, and any filename found chosen. 2005.06.R1 was downloaded and compiled from source used for monitoring the networks.

arpwatch Version 2.1a13 of arpwatch was installed on all hosts in order to protect them from arp poisoning.

Method and result

36

Method and result In order to test the security level of the access point and the network to which it is connected, several tests were conducted in order to gain as much information as possible regarding the network in question. Firstly, the node needs to be connected to an AP in order to gain access to the network beyond it. Secondly, once the node is connected to the AP, it will need to map the network behind it, in order to understand where it is connected and what other computers exist in the network.

Understanding the network In order to learn more about the AP and the wireless nodes connected to it as well as the network behind the AP, the attack patterns and information gathering will be conducted in the following way: With the perspective of an outsider who lacks specific knowledge regarding the network; attempts to gain such information will be done. If those attempts fail in some way, using knowledge about the network in question will be exploited in order to test the setup to its full extent. During the testing and monitoring of traffic between the Windows XP client and the AP, traffic had to be generated in order for the other application to find anything to work with. Classic surfing of the Internet as well as downloading large files were performed in order to fill the wireless medium with packets for all the sniffing applications. Access Point If the AP does not broadcast its SSID (Service Set Identifier), a node will either have to know it prior to connecting to it or it must discover it in some other way. One way to discover the SSID is to monitor all wireless (unencrypted) network traffic. Nodes connecting to an AP sometimes broadcast the SSID of the AP they are about to connect to. Passively monitoring the network traffic would then reveal the SSID of the AP, the node is about to connect to. If a node does not know the SSID of an AP, it will not be able to associate or connect to it. Kismet Running Kismet reveals all the APs in the surrounding area (broadcasting their SSID or not). The AP in question that our node should connect to actually broadcasts its SSID for simplicity and hence our target AP is found with the network name “HelloWorld”. Kismet further reveals that the connection between the AP and its client(s) is encrypted with WPA and TKIP. This means that breaking the network key used, would need to be performed by brute force and since it lacks all elegance would require a lot of time. What kismet can tell us is somewhat limited but at least the MAC address of the AP is shown. Sometimes Kismet is lucky and can determine the IP range of the AP by snapping up ARP packets in the wireless medium as well, but during the tests conducted none were found.

Method and result

37

Ethereal Since all the traffic is encrypted, not much is sent in clear text that ethereal can show. Using a filter rule that shows all packets destined towards and from the AP reduces the amount of packets quite a lot, but most of the packets that ethereal shows are beacon frames and association requests. By merely viewing the traffic that ethereal captures it is hard to understand that large amounts of data actually is being passed between the AP and the wireless client. Ethereal occasionally shows acknowledgement frames destined towards the AP which indicates that it has received data, but the data that it just received is not shown in ethereal. Unfortunately, the source MAC address of the acknowledgement packets is set to all zeros (00:00:00:00:00:00) indicating that the client is concealing its identity. Therefore it is hard to investigate what actually is being sent over the WLAN. If the client attempts to authenticate with the RADIUS server via the AP, the conversation packets for setting up an EAP-TLS connection are shown which lets a monitoring person know more specifically what encryption-routine and security scheme is being used. Given that the passively monitoring eavesdropper tries to determine as much information as possible, knowing if the wireless client and the AP are using a bad or good encryption scheme could be the difference between attempting to intrude the network or not. Snort The wireless snort sensor monitoring the wireless media detects all the different threats defined in the wifi.rules file, see appendix g. Currently authentication, deauthentication and disassociation packets trigger alerts since they can be part of a DOS attack towards the wireless communication or indication of other problems. During the tests of the network security, these packets were all identified by the snort sensor, when manually setting up and tearing down the wireless connection between the client and the AP. The second sensor did not show any alerts to the wireless traffic, but given that the client was authenticated by the RADIUS server and granted access to the inner network, all attempts made by it to map the network were discovered. nmap In order to help snort decode any packets that it might capture, encryption was not used on the wireless NIC. Running nmap (see figure 9) from a wireless network interface disconnected from the AP yielded no results. The first problem for the wireless NIC was that is lacked an association with the AP. nmap –sX –P0 –O 192.168.1.100 Figure 9. Nmap command line scan of the remote host 192.168.1.100 (the wireless client) Thus while the NIC was set in the wireless managed mode (which is the one used for clients connecting towards an AP), it just broadcasted a lot of probe requests and never transmitted any data. In the second attempt, the wireless NIC was set in ad-hoc mode, (which works without a central AP). This time, the NIC lacked an ARP mapping for the IP address 192.168.1.100, thereby failing to send data to the node in question. After manually adding the MAC address of the node and its IP address into an ARP entry for the wireless node, sending data the third time worked from the sending node’s point of view. The packets were sent out into the air, but unfortunately they never reached their destination. Furthermore, the wireless snort sensor did not capture any of these packets, thus failing to reveal any potentially

Method and result

38

damaging packets aimed towards the wireless infrastructure. Usage of the –P0 flag told nmap to not send an ICMP (Internet Control Message Protocol) ping request packet to the node first, in order to detect if it was up and running. Secondly, the –O flag was set in order for nmap to make a qualified guess regarding what operating system the host was running. It was running Linux, but nmap failed to determine this. Finally, the –sX flag was used by nmap in order for it to determine which services the remote host was running. Once the wireless client was authenticated by the RADIUS server and granted access to the inner network, running nmap scans of the intestines revealed exactly which services were available from the computers that were available when running the tests. Various tests were conducted to see if the snort sensors would react to the traffic. However, it managed to show that a vast number of ports were open, see appendix h. This scan was performed once the client was authenticated, but nonetheless conducted to see if the snort sensors would alert. Snort detected the xmas scan from nmap as shown in figure 10 and viewing the log alerts in ACID revealed the MAC and source IP address of the attacking host to be the same one as the wireless client. 07/13-14:55:26.954095 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:1 Figure 10. Snort log from a nmap xmas scan. These addresses were confirmed by viewing the DHCP lease file from the AP and the list of authenticated clients by the RADIUS server. These entries in the log files from snort were repeated over 1270 times, showing that nmap scanned port from 1 to 43188, (not all of the ports in-between were scanned, more likely nmap scanned ports used by well-known services). Summary All packets that contained the parameters, as set up in the snort wifi.rules file, were detected by the wireless snort sensor. The wired snort sensor monitoring the internal network detected the packets sent by the nmap program. Overall, the snort sensors detected all the threats destined towards the test bed that were sent by program trying to breach the security parameters.

Conclusions

39

Conclusions There were two goals with this thesis. First off, is it possible to secure a wireless network from eavesdropping in a scalable, easy and robust way? Secondly, given the nature of a wireless network with all its caveats and strengths could an IDS assist in detecting threats towards it? It is impossible to detect all threats towards a wireless as well as a wired network. For instance, passively monitoring a wireless network could be considered a threat, but it is impossible to detect such activities. On the other hand, the wireless snort sensor detected all active threats directed towards the wireless part of the test bed (and the AP in general). Consider a node containing the necessary certificate needed for authenticating towards the RADIUS server (as well as the shared network key), was subject to a hostile takeover. Furthermore, the malicious user might try and access the network to which the device is connected, possibly performing undesired activities. This is the main motivation for the inner IDS in the test bed, which is used for detecting users performing unauthorized tasks within the network. In order to detect these, anomaly detection as well as signature based IDSs could be used. Upon determining that an illegal user is present in the network, revoking the certificate (s)he is using and closing the connection between the user and the AP, the user would be cut off from the network. Securing the wireless network was performed in three steps. After these schemes were applied to the network it became as secure as possibly is in an 802.11 network today, but in the future when WPA2 becomes reality, it will become even better. Firstly, using TKIP encryption avoided the packets of being decrypted in roughly real-time (in comparison to WEP). Secondly, using a RADIUS server for authenticating the clients, even if the shared network key was compromised, no one could associate with the AP without legitimate certificates. Finally, using MAC address filtering and certificates for authentication, the possibility of a malicious user gaining unauthorized access to the resources of the AP and the network beyond it, are small and quite hard. The concept of RADIUS servers for authenticating users is a rather good idea. Removing this burden from the APs in order to provide the functionality yields a scalable solution. This means that newer and better schemes for securing the wireless communication can be derived without needing to upgrade or replace the AP, which in general means saving money (or time). While evaluating the test bed, stability problems with the FreeRADIUS server version 1.0.4 occurred. There were no problems authenticating the clients multiple times during the setup and tests, but when leaving the client, AP and RADIUS server unattended for a longer time, something in the authentication part messed things up and it crashed from a segmentation fault. Due to lack of time, no heavy investigation into the reasons for this problem have be performed, but given the popularity of this server the issues regarding its crash will most likely be addressed in a short future. The first encryption offered for wireless communication, WEP (disregarding open key), was weak in both design as well as implementation. Unfortunately, it did take some time until the WPA encryption scheme using either TKIP or AES saw its first daylights and became available as an alternative for encrypting the packets of the wireless communication. Coupled with such a good encryption scheme, using a RADIUS server for authenticating a wireless client gaining access to a network proves to be the best way today to enforce security. Since RADIUS servers and the 802.1X standard are so tightly integrated with each other, there are many ways to authenticate the user, which in turn means an overall better security scheme.

Conclusions

40

Given the weaknesses in the set up of a secure wireless communication between the client and the AP, Windows XP cannot be regarded the best of choice if security is the number one priority. Since the author did not try to use Linux, *BSD, Mac OS X or any other operating system for the client authenticating towards the AP, no statements regarding their security can be stated. Nonetheless, having certificates with accompanied passwords and still lacking the possibility to use them to their intended full extent is poor, and not in a security-wise way. The security requirements set up were influenced by the idea that if a host ever was compromised or physically overtaken, lacking the secret key to unlock the certificate would ensure that it would not fall into the wrong hands. This seems highly unlikely unless Microsoft release a patch that addresses this weakness. Using Linux as the operating system on the wireless client (instead of Windows XP), and by utilizing the wpa_supplicant software package more and stronger security schemes would be available to use. AES, TKIP as well as future WPA2 compatible solutions are available for encrypting the packets, when using the wpa_supplicant enhancement. Using better encryption routines makes it harder for eavesdroppers to decode the contents in real-time and makes the wireless traffic better protected. Regarding the issue of certificates and unlocking them with a password, such a support on the Linux platform has not been investigated. Although given the fact that both wpa_supplicant as well as the Linux operating system is available under the GPL license, modifying the source code to allow such a security fashion could be undertaken if it was deemed a necessity. In order to circumvent the failure of injecting packets from the wireless NIC to the other wireless node, several ideas could be tested. First of, setting the MAC address of the node in question to the broadcast address (FF:FF:FF:FF:FF:FF), could perhaps facilitate in making the packet actually arrive at its intended destination, or at least be monitored by the listening snort sensor. Secondly, the channel that the wireless NIC was sending its packets on might have been way off (unless it actually sent the same packet on every channel – which seems highly unlikely). Perhaps if the wireless NIC could send the packets on channel 13 instead, which was the channel used by both the AP and the wireless snort sensor, something more exciting might happen. The snort sensor was set in monitor mode, but if it was listening on all or just the one channel is unclear. In order to bring clarity into this issue, more research would need to be performed. Lastly, if the wireless NIC used the same encryption as the client and AP did (i.e. TKIP encrypted packets using the shared key “whatever”), would the node then respond to the packets? Snort is a flexible, easy to use and strong IDS. In this thesis, no other intrusion detection systems have been tested, and no other documentations or evaluations have been studied in order to perhaps find an even better IDS. This is not entirely true, since in the beginning of the thesis, searching the web for intrusion detection systems, a lot more products than snort existed, but being its nature of GPL and at the same time patchable by snort-wireless, it seemed to be exactly what I was looking for. There are numerous IDSs that can monitor wired networks, but the wireless IDSs seem to be quite few. Perhaps one reason for this is the fact that wireless networks are somewhat new to the IDS scene given the long history it has for creating ones for regular wired networks. Hopefully though, commercial as well as free alternatives will hopefully be released in a near future in order for corporate as well as home wireless networks to be monitored for malicious activity. Snort has a good reputation and being a GPL product, its success is more or less guaranteed to continue. Even though the IDS is free, having the newest rules available from the developers comes at a cost. However, one week after the rules are created, they become available for free download, subscription only.

Conclusions

41

The patch snort-wireless is a great add-on to snort. Given that it so easily can handle wireless traffic in contrast to the original snort, makes it a great tool for monitoring the wireless medium in chase for threats. Unfortunately, it fails to work with ACID due to the lack of IP headers, but hopefully this issue can be resolved in short and thereby ease the use of over viewing the alerts generated when using ACID. Another bad security hazard is configuration files with passwords saved in clear text. Even if the file is protected by access limitations, if a process running on the machine ever becomes compromised, the security is at once vanished. Knowing the password might even be a larger security breach than the compromised server ever was, given that it grants access to certificates or other places kept secret. Storing a hash in the password file would at least be the best option, given that the password needed to be saved (or chosen to be so), unless entering the password for every use was done instead. Regarding bayesian intrusion detection systems as of writing this thesis, they are still under heavy research. Given a normal HTTP connection, the amount of work required for a BIDS to classify each token in the parameters of the protocols used (Ethernet, IP, TCP, ICMP, HTTP), and weight them accordingly is one immense task. The BIDS would then have to classify and create tokens of the contents of each of the protocols as well (and add weights to them). In order for this to succeed, some clever techniques would need to be invented if the BIDS ever should gain popularity and be easy to use. But the main idea and goal behind self-learning IDSs is a great one. Perhaps in the next years to come, more research in the field will yield better recognition pattern modules and classifiers for the BIDS to use. As a final note, intrusion detection systems play an equally important role as the firewalls in network designs. Firewalls and IDSs do not work the same way and can therefore never replace each other. A network based IDS was evaluated in this thesis, but stack-based or host based IDSs could equally be evaluated or be complements to it in a future real-world deployment. Even in the field of IDSs, no single technique can be considered the “best one”; each one has its pros and cons. The same goes for classifications of the traffic (anomaly versus signature based). When considering the use of an IDS in the network design, depending on what it should do and the purpose of it, the best match for the task can most likely be found. If the network traffic should be monitored for malicious content, the NIDS could be considered the best choice. If the hosts on the network need to be further protected (given that they might use anti-virus software, spyware removers and perhaps a personal firewall), maybe the stack-based IDS is a better choice than the HIDS. The host based IDS could be used on servers in the DMZ for instance, where monitoring their status and systematically checking the logs could be done in order to check their integrity. But then again, there is nothing that states that all three can not be used at the same time, given their different roles in a network environment.

Future work

42

Future work

• Can packets be injected into the wireless network without the node being associated with the AP?

• Make wpa_supplicant work on a Linux workstation. • Test a more stable version of FreeRADIUS. • Find a way to decrypt the WPA encrypted packets to let snort analyze them in real time

before/at the same time as they meet the AP. • Use a network tap in order to protect the IDS. • Make the snort sensors reside on different hosts, as well as all the other running services. • Perform thorough tests of the network in order for flaws to be discovered. Furthermore, let

someone who lacks knowledge of the network do whatever the person finds suitable in order for him/her to be able to access the network behind the AP. Even try and DOS attack the traffic and see if snort can detect such activities.

• Is using an IPS an alternative? • Set thresholds of the network traffic and train snort to act upon that. • Test other IDSs in order to find the best one suitable for the intended purposes. • Try different test beds in order to evaluate the used IDS in order to determine its efficiency. • Can a HIDS or stack-based IDS perform equally good or better than a NIDS?

References

43

References [1] Cox & Greg (2004) Managing Security with Snort and IDS Tools. O'Reilly Media. ISBN 0-596-00661-6 [2] Kurose, F & Ross, K. (2001) Computer Networking. A Top-Down Approach Featuring the Internet. Addison Wesley Longman, Inc. ISBN: 0-201-47711-4 [3] Silberschatz, A. Galvin, P. & Gagne, G. (2003) Operating System Concepts, sixth edition, Windows XP update. John Wiley & Sons Inc. ISBN: 0-471-25060-0 [4] IEEE (1999). Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications 802.11-1999. [5] IEEE 2001. (2004) Port-Based Network Access Control. 802.1X-2001 [6] Sandström H. (2001) A survey of the Denial of Service Problem. Master thesis, Department of Computer Science and Electrical Engineering, Luleå University of Technology, Luleå, Sweden [7] Axelsson, S. (1999) The Base-Rate Fallacy and its Implications for the Difficulty of Intrusion Detection. Department of Computer Engineering, Chalmers University of Technology, Göteborg, Sweden. Proceedings of the 6th ACM Conference on Computer and Communications Security. [8] R. Droms. (Mars 1997) Dynamic Host Configuration Protocol. RFC 2131 [9] Blunk, L. & Vollbrecht, J. (1998) PPP Extensible Authentication Protocol (EAP). RFC 2284 [10] Rigney, C et al. (June 2000). Remote Authentication Dial In User Service (RADIUS). RFC 2865 [11] Arkko, J et al. (March 2005). RFC 3971 - SEcure Neighbor Discovery (SEND). RFC 3971 [12] Nikander, P et al. (May 2004). IPv6 Neighbor Discovery (ND) Trust Models and Threats. RFC 3756 [13] Aboba, B. & Simon, D. (1999) PPP EAP TLS Authentication Protocol. RFC 2716 [14] Cisco (2005-03-29) Internetworking Technologies Handbook, (chap. 7 Ethernet). [15] Liu, C. (2004) 802.11 Disassociation Denial of Service (DoS) attacks. DePaul University [16] Laing, B. (2000) How To Guide-Implementing a Network Based Intrusion Detection System [17] Innella P. (2001-11-16) The Evolution of Intrusion Detection Systems. http://www.securityfocus.com/infocus/1514 [18] Where's a good place to physically put a Snort sensor? (2005-03) http://www.snort.org/docs/faq/1Q05/node18.html [19] Kruegel, C & Vigna, G. (2003) Anomaly Detection of Web-based Attacks

References

44

[20] Carte, E. (2002-02-15). Intrusion Detection Systems. Cisco Press [21] Kazienko, P. and Dorosz, P. (2004-07-23) Intrusion Detection Systems (IDS) Part 2 - Classification; methods; techniques [22] Cisco (2004-10-20). IP Fragmentation and PMTUD. Document ID 25885 [23] Liston, K. (2003-06-12). SANS Intrusion Detection FAQ: Can you explain traffic analysis and and anomaly detection? [24] Mitchell, B. (2005-01-06). What is the Actual Speed of an 802.11b Wi-Fi Network? [25] Weatherspoon, S. (2003-06-16). Overview of IEEE 802.11b Security [26] Snyder, J. & Thayer, R. (2004-10-04). Explaining TKIP. Network World. [27] whatis.com (2004-08-06). 802.11i – a Whatis.com definition [28] lists.sans.org. (2000-10-27). [Dshield] Dynamic firewall response [29] Computer bug -Wikipedia, the free encyclopedia. (2005) http://en.wikipedia.org/wiki/Computer_bug [30] Patrick, R. (2003-10-28). What is the difference between SSH and SSL? http://www.rpatrick.com/tech/ssh-ssl/ [31] hacker: Definition and Much More From Answers.com (2005-06-11) http://www.answers.com [32] Ou, G. (2005-06-02). Understanding the updated WPA and WPA2 standards. http://blogs.zdnet.com/Ou/?p=67 [33] GNU (2005-06-07) GNU General Public License http://www.gnu.org/copyleft/gpl.html [34] faqs.org (2003-06-14) bit bucket http://www.faqs.org/docs/jargon/B/bit-bucket.html [35] Bauer, M. (2005 April – June). Securing WLANs with WPA and FreeRADIUS Part I, II and III http://www.linuxjournal.com [36] Neugebauer, F. (2002-09-08). Snort IDS with Mandrake 8.2 http://www.linux-tip.net/workshop/ids-snort/ids-snort.htm [37] exklusve (2003-08-27) Gentoo Forums :: View topic – complete guide to Snort, MySQL and Acid http://forums.gentoo.org/viewtopic.php?t=78718 [38] Malinen, J. (2005-06-26) Linux WPA Supplicant (IEEE 802.1X, WPA, WPA2, RSN, IEEE 802.11i) http://hostap.epitest.fi/wpa_supplicant/

References

45

[39] Tourrilhes, J. (1997-01-23) Wireless Extensions for Linux http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.Extensions.html [40] Silva, G. N. (2005-03). APT HOWTO. (Mars 2005) http://www.debian.org/doc/manuals/apt-howto/index.en.html [41] Snort – the de facto standard for intrusion detection/prevention. (2005) http://www.snort.org [42] Snort-Wireless. (2005-06-13) http://www.snort-wireless.org [43] Oinkmaster. (2005) http://oinkmaster.sourceforge.net [44] Kismet. (2005) http://www.kismetwireless.net [45] AirSnort Homepage. (2005-01-06) http://airsnort.shmoo.com [46] aircrack documentation (2005-05-30) http://www.cr0.net:8040/code/network/aircrack [47] Arpwatch. (2004-10-17) ftp://ftp.ee.lbl.gov/arpwatch.tar.gz [48] FreeRADIUS – building the perfect RADIUS server. (2005) http://www.freeradius.org [49] Wi-Fi Alliance index (2005) http://www.wifialliance.org [50] MySQL: The World’s Most Popular Open Source Database (2005) http://www.mysql.com [51] Analysis Console for Intrusion Databases (ACID) (2005-07-13) http://www.andrew.cmu.edu/user/rdanyliw/snort/snortacid.html [52] Ethereal: A Network Protocol Analyzer (2005-06-21) http://www.ethereal.com [53] Index of /people/dgibson/dldwd (2005-07-13) http://ozlabs.org/people/dgibson/dldwd/ [54] Komu, M. (2005-03-18) HIPL: HIP for Linux http://hipl.hiit.fi/hipl/ [55] Debian -- The Universal Operating System (2005-07-13) http://www.debian.org

References

46

[56] Nmap – Free Security Scanner For Network Exploration & Security Audits. (2005-04-12) http://www.insecure.org/nmap

Appendix A

1

Appendix A var HOME_NET any var EXTERNAL_NET !$HOME_NET var DNS_SERVERS $HOME_NET var SMTP_SERVERS $HOME_NET var HTTP_SERVERS $HOME_NET var SQL_SERVERS $HOME_NET var TELNET_SERVERS $HOME_NET var SNMP_SERVERS $HOME_NET var HTTP_PORTS 80 var SHELLCODE_PORTS !80 var ORACLE_PORTS 1521 var AIM_SERVERS [64.12.24.0/23,64.12.28.0/23,64.12.161.0/24,64.12.163.0/24,64.12.200.0/24,205.188.3.0/24,205.188.5.0/24,205.188.7.0/24,205.188.9.0/24,205.188.153.0/24,205.188.179.0/24,205.188.248.0/24] var RULE_PATH /etc/snort/rules preprocessor flow: stats_interval 0 hash 2 preprocessor frag2 preprocessor stream4: disable_evasion_alerts detect_scans preprocessor stream4_reassemble preprocessor http_inspect: global iis_unicode_map unicode.map 1252 preprocessor http_inspect_server: server default profile all ports { 80 8080 8180 } oversize_dir_length 500 preprocessor rpc_decode: 111 32771 preprocessor bo preprocessor telnet_decode preprocessor sfportscan: proto { all } memcap { 10000000 } sense_level { low } output log_tcpdump: tcpdump.log output database: log, mysql, user=snort password=snort dbname=snort host=172.26.125.183 include classification.config include reference.config config flowbits_size: 256 include $RULE_PATH/local.rules include $RULE_PATH/bad-traffic.rules include $RULE_PATH/exploit.rules include $RULE_PATH/scan.rules include $RULE_PATH/finger.rules include $RULE_PATH/ftp.rules include $RULE_PATH/telnet.rules include $RULE_PATH/rpc.rules include $RULE_PATH/rservices.rules include $RULE_PATH/dos.rules include $RULE_PATH/ddos.rules include $RULE_PATH/dns.rules include $RULE_PATH/tftp.rules

Appendix A

2

include $RULE_PATH/web-cgi.rules include $RULE_PATH/web-coldfusion.rules include $RULE_PATH/web-iis.rules include $RULE_PATH/web-frontpage.rules include $RULE_PATH/web-misc.rules include $RULE_PATH/web-client.rules include $RULE_PATH/web-php.rules include $RULE_PATH/sql.rules include $RULE_PATH/x11.rules include $RULE_PATH/icmp.rules include $RULE_PATH/netbios.rules include $RULE_PATH/misc.rules include $RULE_PATH/attack-responses.rules include $RULE_PATH/oracle.rules include $RULE_PATH/mysql.rules include $RULE_PATH/snmp.rules include $RULE_PATH/smtp.rules include $RULE_PATH/imap.rules include $RULE_PATH/pop2.rules include $RULE_PATH/pop3.rules include $RULE_PATH/nntp.rules include $RULE_PATH/other-ids.rules include $RULE_PATH/experimental.rules include threshold.conf

Appendix B

3

Appendix B prefix = /usr exec_prefix = /usr sysconfdir = /etc localstatedir = /var sbindir = ${exec_prefix}/sbin logdir = /var/log/freeradius raddbdir = /etc/freeradius radacctdir = ${logdir}/radacct confdir = ${raddbdir} run_dir = ${localstatedir}/run/freeradius log_file = ${logdir}/radius.log libdir = /usr/lib/freeradius pidfile = ${run_dir}/freeradius.pid #user = freerad #group = freerad max_request_time = 30 delete_blocked_requests = no cleanup_delay = 5 max_requests = 1024 bind_address = 192.168.1.3 port = 0 hostname_lookups = no allow_core_dumps = yes regular_expressions = yes extended_expressions = yes log_stripped_names = no log_auth = no log_auth_badpass = no log_auth_goodpass = no usercollide = no lower_user = no lower_pass = no nospace_user = no nospace_pass = no checkrad = ${sbindir}/checkrad security { max_attributes = 200 reject_delay = 0 status_server = no } proxy_requests = yes $INCLUDE ${confdir}/proxy.conf $INCLUDE ${confdir}/clients.conf snmp = no $INCLUDE ${confdir}/snmp.conf thread pool { start_servers = 5 max_servers = 32

Appendix B

4

min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 } modules { pap { encryption_scheme = crypt } chap { authtype = CHAP } pam { pam_auth = radiusd } unix { cache = no cache_reload = 600 shadow = /etc/shadow radwtmp = ${logdir}/radwtmp } $INCLUDE ${confdir}/eap.conf mschap { authtype = MS-CHAP use_mppe = yes require_encryption = yes require_strong = yes } ldap { server = "ldap.your.domain" basedn = "o=My Org,c=UA" filter = "(uid=%{Stripped-User-Name:-%{User-Name}})" start_tls = no access_attr = "dialupAccess" dictionary_mapping = ${raddbdir}/ldap.attrmap ldap_connections_number = 5 timeout = 4 timelimit = 3 net_timeout = 1 } realm IPASS { format = prefix delimiter = "/" ignore_default = no ignore_null = no } realm realmslash { format = prefix delimiter = "/" } realm suffix { format = suffix

Appendix B

5

delimiter = "@" ignore_default = no ignore_null = no } realm realmpercent { format = suffix delimiter = "%" ignore_default = no ignore_null = no } realm ntdomain { format = prefix delimiter = "\\" ignore_default = no ignore_null = no } checkval { item-name = Calling-Station-Id check-name = Calling-Station-Id data-type = string } preprocess { huntgroups = ${confdir}/huntgroups hints = ${confdir}/hints with_ascend_hack = no ascend_channels_per_line = 23 with_ntdomain_hack = no with_specialix_jetstream_hack = no with_cisco_vsa_hack = no } files { usersfile = ${confdir}/users acctusersfile = ${confdir}/acct_users compat = no } detail { detailfile = ${radacctdir}/%{Client-IP-Address}/detail-%Y%m%d detailperm = 0600 } acct_unique { key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port" } $INCLUDE ${confdir}/sql.conf radutmp { filename = ${logdir}/radutmp username = %{User-Name} case_sensitive = yes check_with_nas = yes perm = 0600 callerid = "yes" }

Appendix B

6

radutmp sradutmp { filename = ${logdir}/sradutmp perm = 0644 callerid = "no" } attr_filter { attrsfile = ${confdir}/attrs } counter daily { filename = ${raddbdir}/db.daily key = User-Name count-attribute = Acct-Session-Time reset = daily counter-name = Daily-Session-Time check-name = Max-Daily-Session allowed-servicetype = Framed-User cache-size = 5000 } always fail { rcode = fail } always reject { rcode = reject } always ok { rcode = ok simulcount = 0 mpp = no } expr { } digest { } exec { wait = yes input_pairs = request } exec echo { wait = yes program = "/bin/echo %{User-Name}" input_pairs = request output_pairs = reply } ippool main_pool { range-start = 192.168.1.1 range-stop = 192.168.3.254 netmask = 255.255.255.0 cache-size = 800 session-db = ${raddbdir}/db.ippool ip-index = ${raddbdir}/db.ipindex override = no

Appendix B

7

maximum-timeout = 0 } } instantiate { exec expr } authorize { preprocess files eap } authenticate { Auth-Type MS-CHAP { mschap } eap } preacct { preprocess acct_unique suffix files } accounting { detail unix radutmp acct_unique } session { radutmp } post-auth { } pre-proxy { } post-proxy { eap }

Appendix C

8

Appendix C eap { default_eap_type = tls timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no md5 { } leap { } gtc { auth_type = PAP } tls { private_key_password = whatever private_key_file = ${raddbdir}/certs/server_keycert.pem certificate_file = ${raddbdir}/certs/server_keycert.pem CA_file = ${raddbdir}/certs/cacert.pem dh_file = ${raddbdir}/certs/dh random_file = ${raddbdir}/certs/random fragment_size = 1024 include_length = yes } peap { default_eap_type = mschapv2 } mschapv2 { } }

Appendix D

9

Appendix D client 127.0.0.1 { secret = whatever shortname = localhost nastype = other } client 192.168.1.1/32 { secret = whatever shortname = "AccessPoint" } client 192.168.1.3 { secret = whatever shortname = "localhost" }

Appendix E

10

Appendix E First off, a certificate authority was created, and the file openssl.cnf was modified in order to reduce the extra burden of retyping the same entries manually for each certificate. In section [ CA_default] the value dir was changed to reflect the path where the CA was supposed to be saved. Furthermore, countryName_default, stateOrProvinceName_default and 0.organizationName_default were modified as well and set to, Sweden, Västra Götaland and Ericsson Microwave Systems AB. Whenever the script or openssl prompted for a password during the creation of the CA and the certificates, the password whatever was entered. To create the CA, the following command was issued /usr/ssl/misc/CA.sh -newca A special file called xpextensions was created that eases the installation of certificates on a Windows XP computer, since the certificate contains a value that lets Windows know what kind of certificate it is about to install. There are two entries in the file xpextensions, and one is for the client certificate and the other one is for the server certificate. [ xpclient_ext] extendedKeyUsage = 1.3.6.1.5.5.7.3.2 [ xpserver_ext] extendedKeyUsage = 1.3.6.1.5.5.7.3.1 To create the server certificate the following command was issued: openssl req –new –nodes –keyout server_key.pem -out server_req.pem –days 730 –config ./xpextensions The certificate is the signed by the CA, openssl ca -config ./openssl.cnf -policy policy_anything -out server_cert.pem -extensions xpserver_ext -extfile ./xpextensions -infiles ./server_req.pem The key and the certificate are then concatenated together into a single file and everything proceeding the line -----BEGIN CERTIFICATE----- was deleted. cat server_key.pem server_cert.pem > server_keycert.pem Next the client certificate was created, openssl req -new -keyout client_key.pem -out client_req.pem -days 730 -config ./openssl.cnf Next, the client certificate was signed, openssl ca -config ./openssl.cnf -policy policy_anything -out client_cert.pem -extensions xpclient_ext

Appendix E

11

-extfile ./xpextensions -infiles ./client_req.pem Since the client certificate was to be used on a Windows XP system, the certificate was converted into a different file format, openssl pkcs12 -export -in client_cert.pem -inkey client_key.pem -out client_cert.p12 -clcerts

Appendix F

12

Appendix F CREATE TABLE schema ( vseq INT UNSIGNED NOT NULL, ctime DATETIME NOT NULL, PRIMARY KEY (vseq)); INSERT INTO schema (vseq, ctime) VALUES ('106', now()); CREATE TABLE event ( sid INT UNSIGNED NOT NULL, cid INT UNSIGNED NOT NULL, signature INT UNSIGNED NOT NULL, timestamp DATETIME NOT NULL, PRIMARY KEY (sid,cid), INDEX sig (signature), INDEX time (timestamp)); CREATE TABLE signature ( sig_id INT UNSIGNED NOT NULL AUTO_INCREMENT, sig_name VARCHAR(255) NOT NULL, sig_class_id INT UNSIGNED NOT NULL, sig_priority INT UNSIGNED, sig_rev INT UNSIGNED, sig_sid INT UNSIGNED, PRIMARY KEY (sig_id), INDEX sign_idx (sig_name(20)), INDEX sig_class_id_idx (sig_class_id)); CREATE TABLE sig_reference (sig_id INT UNSIGNED NOT NULL, ref_seq INT UNSIGNED NOT NULL, ref_id INT UNSIGNED NOT NULL, PRIMARY KEY(sig_id, ref_seq)); CREATE TABLE reference ( ref_id INT UNSIGNED NOT NULL AUTO_INCREMENT, ref_system_id INT UNSIGNED NOT NULL, ref_tag TEXT NOT NULL, PRIMARY KEY (ref_id)); CREATE TABLE reference_system ( ref_system_id INT UNSIGNED NOT NULL AUTO_INCREMENT, ref_system_name VARCHAR(20), PRIMARY KEY (ref_system_id)); CREATE TABLE sig_class ( sig_class_id INT UNSIGNED NOT NULL AUTO_INCREMENT, sig_class_name VARCHAR(60) NOT NULL, PRIMARY KEY (sig_class_id), INDEX (sig_class_id), INDEX (sig_class_name)); CREATE TABLE sensor ( sid INT UNSIGNED NOT NULL AUTO_INCREMENT, hostname TEXT, interface TEXT,

Appendix F

13

filter TEXT, detail TINYINT, encoding TINYINT, last_cid INT UNSIGNED NOT NULL, PRIMARY KEY (sid)); CREATE TABLE iphdr ( sid INT UNSIGNED NOT NULL, cid INT UNSIGNED NOT NULL, ip_src INT UNSIGNED NOT NULL, ip_dst INT UNSIGNED NOT NULL, ip_ver TINYINT UNSIGNED, ip_hlen TINYINT UNSIGNED, ip_tos TINYINT UNSIGNED, ip_len SMALLINT UNSIGNED, ip_id SMALLINT UNSIGNED, ip_flags TINYINT UNSIGNED, ip_off SMALLINT UNSIGNED, ip_ttl TINYINT UNSIGNED, ip_proto TINYINT UNSIGNED NOT NULL, ip_csum SMALLINT UNSIGNED, PRIMARY KEY (sid,cid), INDEX ip_src (ip_src), INDEX ip_dst (ip_dst)); CREATE TABLE tcphdr( sid INT UNSIGNED NOT NULL, cid INT UNSIGNED NOT NULL, tcp_sport SMALLINT UNSIGNED NOT NULL, tcp_dport SMALLINT UNSIGNED NOT NULL, tcp_seq INT UNSIGNED, tcp_ack INT UNSIGNED, tcp_off TINYINT UNSIGNED, tcp_res TINYINT UNSIGNED, tcp_flags TINYINT UNSIGNED NOT NULL, tcp_win SMALLINT UNSIGNED, tcp_csum SMALLINT UNSIGNED, tcp_urp SMALLINT UNSIGNED, PRIMARY KEY (sid,cid), INDEX tcp_sport (tcp_sport), INDEX tcp_dport (tcp_dport), INDEX tcp_flags (tcp_flags)); CREATE TABLE udphdr( sid INT UNSIGNED NOT NULL, cid INT UNSIGNED NOT NULL, udp_sport SMALLINT UNSIGNED NOT NULL, udp_dport SMALLINT UNSIGNED NOT NULL, udp_len SMALLINT UNSIGNED, udp_csum SMALLINT UNSIGNED, PRIMARY KEY (sid,cid), INDEX udp_sport (udp_sport), INDEX udp_dport (udp_dport));

Appendix F

14

CREATE TABLE icmphdr( sid INT UNSIGNED NOT NULL, cid INT UNSIGNED NOT NULL, icmp_type TINYINT UNSIGNED NOT NULL, icmp_code TINYINT UNSIGNED NOT NULL, icmp_csum SMALLINT UNSIGNED, icmp_id SMALLINT UNSIGNED, icmp_seq SMALLINT UNSIGNED, PRIMARY KEY (sid,cid), INDEX icmp_type (icmp_type)); CREATE TABLE opt ( sid INT UNSIGNED NOT NULL, cid INT UNSIGNED NOT NULL, optid INT UNSIGNED NOT NULL, opt_proto TINYINT UNSIGNED NOT NULL, opt_code TINYINT UNSIGNED NOT NULL, opt_len SMALLINT, opt_data TEXT, PRIMARY KEY (sid,cid,optid)); CREATE TABLE data ( sid INT UNSIGNED NOT NULL, cid INT UNSIGNED NOT NULL, data_payload TEXT, PRIMARY KEY (sid,cid)); CREATE TABLE encoding(encoding_type TINYINT UNSIGNED NOT NULL, encoding_text TEXT NOT NULL, PRIMARY KEY (encoding_type)); INSERT INTO encoding (encoding_type, encoding_text) VALUES (0, 'hex'); INSERT INTO encoding (encoding_type, encoding_text) VALUES (1, 'base64'); INSERT INTO encoding (encoding_type, encoding_text) VALUES (2, 'ascii'); CREATE TABLE detail (detail_type TINYINT UNSIGNED NOT NULL, detail_text TEXT NOT NULL, PRIMARY KEY (detail_type)); INSERT INTO detail (detail_type, detail_text) VALUES (0, 'fast'); INSERT INTO detail (detail_type, detail_text) VALUES (1, 'full');

Appendix G

15

Appendix G alert wifi any -> any (msg:"Association Request"; stype:STYPE_ASSOCREQ;) alert wifi any -> any (msg:"Association Response"; stype:STYPE_ASSOCRESP;) alert wifi any -> any (msg:"Reassociation Request"; stype:STYPE_REASSOC_REQ;) alert wifi any -> any (msg:"Reassociation Response"; stype:STYPE_REASSOC_RESP;) alert wifi any -> any (msg:"Disassociation"; stype:STYPE_DISASSOC;) alert wifi any -> any (msg:"Authentication"; stype:STYPE_AUTH;) alert wifi any -> any (msg:"Deauthentication"; stype:STYPE_DEAUTH;) alert wifi any -> any (msg:"wep flag set"; wep:TRUE;)

Appendix H

16

Appendix H C:\temp\nmap-3.81>nmap -sX 192.168.1.3 -O Starting nmap 3.81 ( http://www.insecure.org/nmap ) at 2005-07-13 16:55 W. Europe Standard Time Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port Interesting ports on 192.168.1.3: (The 1655 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 21/tcp open|filtered ftp 22/tcp open|filtered ssh 80/tcp open|filtered http 111/tcp open|filtered rpcbind 833/tcp open|filtered unknown 839/tcp open|filtered unknown 2049/tcp open|filtered nfs 10000/tcp open|filtered snet-sensor-mgmt MAC Address: 00:02:B3:EE:1E:AA (Intel) Too many fingerprints match this host to give specific OS details Nmap finished: 1 IP address (1 host up) scanned in 12.027 seconds

Appendix I

17

Appendix I 07/13-14:55:26.850334 [**] [1:469:3] ICMP PING NMAP [**] [Classification: Attempted Information Leak] [Priority: 2] {ICMP} 192.168.1.100 -> 192.168.1.3 07/13-14:55:26.954095 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:636 07/13-14:55:26.954381 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:256 07/13-14:55:26.954772 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:443 07/13-14:55:26.954917 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:113 07/13-14:55:26.954944 [**] [122:1:0] (portscan) TCP Portscan [**] {PROTO255} 192.168.1.100 -> 192.168.1.3 07/13-14:55:26.955696 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:1723 07/13-14:55:26.955845 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:23 07/13-14:55:26.955995 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:22 07/13-14:55:26.956144 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:389 07/13-14:55:26.957889 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:80 07/13-14:55:26.958076 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:25 07/13-14:55:26.962582 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:554 07/13-14:55:26.962857 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:53 07/13-14:55:26.963250 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:3389 07/13-14:55:26.963431 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:21 07/13-14:55:26.964285 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:675 07/13-14:55:26.964430 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:397 07/13-14:55:26.964580 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:879 07/13-14:55:26.964729 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:6544 07/13-14:55:26.964877 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:13710 07/13-14:55:26.965508 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:828 07/13-14:55:26.965690 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:3456 07/13-14:55:26.965842 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:5555

Appendix I

18

07/13-14:55:26.965992 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:884 07/13-14:55:26.967758 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:1449 07/13-14:55:26.967908 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:1391 07/13-14:55:26.968056 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:289 07/13-14:55:26.972733 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:995 07/13-14:55:26.972913 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:1720 07/13-14:55:26.973078 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:5300 07/13-14:55:26.973337 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:918 07/13-14:55:26.973829 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:13722 07/13-14:55:26.973981 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:1008 07/13-14:55:26.974132 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:1430 07/13-14:55:26.975472 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:874 07/13-14:55:26.975590 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:1473 07/13-14:55:26.975774 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:1512 07/13-14:55:26.975885 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:535 07/13-14:55:26.976097 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:653 07/13-14:55:26.976209 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:15126 07/13-14:55:26.976405 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:1993 07/13-14:55:26.977156 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:299 07/13-14:55:26.977342 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:971 07/13-14:55:26.977475 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:757 07/13-14:55:26.977637 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:5000 07/13-14:55:26.977742 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:366 07/13-14:55:26.979813 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:665 07/13-14:55:26.979928 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.100:35476 -> 192.168.1.3:835