Implementing network defence using deception in a wireless honeypot Suen Yek School of Computer and Information Science Edith Cowan University [email protected]Abstract The advance of 802.11b wireless networking has been beset by inherent and in-built security problems. Network security tools that are freely available may intercept network transmissions readily and with stealth, making organisations highly vulnerable to attack. Deception is an essential element of effective security that has been used in networks to understand attack methods and intrusions. This paper seeks to explore the use of deception for wireless network defence through the deployment of a wireless honeypot. The honeypot demonstrated the outcome of deceptions used against common wireless network attacks. Keywords wireless honeypot, deception in depth, wireless network security INTRODUCTION Studies and statistics show companies do not implement adequate security measures for protection of wireless networked resources (Barnes et al., 2002; Nanda, 2002; Webb, 2002, 2003). Furthermore, the nature of existing 802.11 wireless networking protocols subject sensitive information in wireless networks to remote attacks that may not even be detectable. Results from a conventional wired honeypot experiment revealed deception to be a possible countermeasure to network threats generated by brute force attacks that utilised vulnerability scanners (Gupta, 2002; Yek & Valli, 2002). Deception may be expressed as a process of activities that defeat the perceptual structures of the target (Rue, 1994). In network security, the use of deception may be a proactive advantage to the victim as it is an adaptable defence resource, in addition to a valuable intelligence gathering tool (College of Aerospace Doctrine Research and Education, 1997; Gerwehr & Anderson, 2000; Gerwehr & Glenn, 2003). Deception techniques were utilised for testing wireless network security in the form of a wireless honeypot. The wireless capability that was adopted was the IEEE 802.11b standard; which at the time was the most commonly used protocol for broadband wireless (Schoeneck, 2003). A Linux Mandrake 9.0 machine was set up with a Prism 2.5 Chipset network card, and was installed with a HostAP driver. HostAP allowed the Linux machine to function as an access point (AP) through the network card. This allowed the utilisation of FakeAP software, which simulates wireless AP’s. Additionally, the deployment of the 802.11b wireless honeypot included the use of the Honeyd honeypot (Provos, 2004). A honeypot may be defined as a security resource that is used for detecting and monitoring attacker behaviour in a network (Spitzner, 2003; The Honeynet Project, 2004). Honeyd is a type of honeypot that uses TCP/IP based operating system (OS) fingerprints (Fyodor, 2003a) in combination with network infrastructure and network routing emulation. This gives the appearance of actual networks to an attacker. The Honeyd was the primary source for testing network attacks in the wireless honeypot. The intention of the wireless honeypot was to appear deceptively as a realistic network of wired and wireless integrated services for various OS platforms. The effectiveness of deceptions used on the wireless honeypot were evaluated from results gathered from the logfile/report outputs of four commonly used network attack tools: Kismet (Kershaw, 2003), Netstumbler (Milner, 2002), Network Mapper (NMAP) (Fyodor, 2003b) and Nessus (Deraison, 2003a). Kismet and Netstumbler are passive, 802.11b packet sniffing tools that were used to identify if a rogue AP existed. Both sniffing tools were used to enumerate data including the Service Set Identifier (SSID), which is the name of the network, frequency, and channel of an 802.11b broadcasting AP. Kismet may further identify cloaked SSIDs and detected IP addresses of the network. Netstumbler
Transcript
Implementing network defence using deception in a wireless honeypot
Suen Yek School of Computer and Information Science
Abstract The advance of 802.11b wireless networking has been beset by inherent and in-built security problems. Network security tools that are freely available may intercept network transmissions readily and with stealth, making organisations highly vulnerable to attack. Deception is an essential element of effective security that has been used in networks to understand attack methods and intrusions. This paper seeks to explore the use of deception for wireless network defence through the deployment of a wireless honeypot. The honeypot demonstrated the outcome of deceptions used against common wireless network attacks. Keywords wireless honeypot, deception in depth, wireless network security INTRODUCTION Studies and statistics show companies do not implement adequate security measures for protection of wireless networked resources (Barnes et al., 2002; Nanda, 2002; Webb, 2002, 2003). Furthermore, the nature of existing 802.11 wireless networking protocols subject sensitive information in wireless networks to remote attacks that may not even be detectable. Results from a conventional wired honeypot experiment revealed deception to be a possible countermeasure to network threats generated by brute force attacks that utilised vulnerability scanners (Gupta, 2002; Yek & Valli, 2002). Deception may be expressed as a process of activities that defeat the perceptual structures of the target (Rue, 1994). In network security, the use of deception may be a proactive advantage to the victim as it is an adaptable defence resource, in addition to a valuable intelligence gathering tool (College of Aerospace Doctrine Research and Education, 1997; Gerwehr & Anderson, 2000; Gerwehr & Glenn, 2003). Deception techniques were utilised for testing wireless network security in the form of a wireless honeypot. The wireless capability that was adopted was the IEEE 802.11b standard; which at the time was the most commonly used protocol for broadband wireless (Schoeneck, 2003). A Linux Mandrake 9.0 machine was set up with a Prism 2.5 Chipset network card, and was installed with a HostAP driver. HostAP allowed the Linux machine to function as an access point (AP) through the network card. This allowed the utilisation of FakeAP software, which simulates wireless AP’s. Additionally, the deployment of the 802.11b wireless honeypot included the use of the Honeyd honeypot (Provos, 2004). A honeypot may be defined as a security resource that is used for detecting and monitoring attacker behaviour in a network (Spitzner, 2003; The Honeynet Project, 2004). Honeyd is a type of honeypot that uses TCP/IP based operating system (OS) fingerprints (Fyodor, 2003a) in combination with network infrastructure and network routing emulation. This gives the appearance of actual networks to an attacker. The Honeyd was the primary source for testing network attacks in the wireless honeypot. The intention of the wireless honeypot was to appear deceptively as a realistic network of wired and wireless integrated services for various OS platforms. The effectiveness of deceptions used on the wireless honeypot were evaluated from results gathered from the logfile/report outputs of four commonly used network attack tools: Kismet (Kershaw, 2003), Netstumbler (Milner, 2002), Network Mapper (NMAP) (Fyodor, 2003b) and Nessus (Deraison, 2003a). Kismet and Netstumbler are passive, 802.11b packet sniffing tools that were used to identify if a rogue AP existed. Both sniffing tools were used to enumerate data including the Service Set Identifier (SSID), which is the name of the network, frequency, and channel of an 802.11b broadcasting AP. Kismet may further identify cloaked SSIDs and detected IP addresses of the network. Netstumbler
detected data including the MAC address and subsequent vendor from the first Hexadecimal digits of the AP’s MAC. Once the AP was detected by the sniffing tools, the Honeyd virtual networks were scanned using the attack tools NMAP and Nessus. NMAP is a TCP/IP based network scanner and may be used to scan IP blocks to enumerate data such as the OS platforms and potential services running on ports identified as open. Nessus is a security vulnerability scanner capable of stealth and brute force methods of scanning. The data the tool indicates if security warnings or vulnerabilities can be detected on selected services that are scanned and probed. A Nessus daemon (Nessusd) utilises NMAP scans for identifying OS platforms on IP addresses and tests the security of each and any selected port for known vulnerabilities. A Nessus client generates graphical reports that identify network weaknesses on a low to very high-risk level, security warnings, holes and vulnerabilities, as well as an advisory link describing the possible exploit found (Deraison, 2003b). This in turn provides significant OS exploit opportunities to a would-be attacker. METHOD The research involved constructing and deploying an integrated wired and wireless honeypot utilising Deception-in-Depth (DiD) concept of operation. DiD uses layered rings of varying deceptive strength to express a synergistic blend of deceptive measures which aim to strengthen defence (Gerwehr & Anderson, 2000). The central core embraces the most effective deception and as the rings progress outward, the strength of the deception abates. Hence, the peripheral is the most vulnerable of rings. Figure 1 demonstrates the logical implementation of the wireless honeypot using DiD.
FIGURE 1 - Applying the wireless honeypot to Deception-in-Depth Ring 3 - FakeAP The role of the deception on ring 3 was to produce an AP gateway for attackers to discover ingress to the Honeyd virtual networks. FakeAP is software that may be used to simulate one or many access points on a computer installed with an antenna and the HostAP driver. FakeAP changes configurable parameters that alter the behaviour and characteristics of an AP. These include the SSID, IP address, MAC address, frequency and channel used, and signal strength as the data contained in beaconed 802.11b packets. The wireless sniffing tools Kismet and Netstumbler may then be used to identify the presence of the rogue AP. All the AP related parameters that are broadcast by FakeAP indicates the data collected by the wireless sniffing tools. When an attacker is able to ascertain the IP address of the AP gateway, they may connect to the network via the gateway to identify network IP addresses that are really the Honeyd virtual networks. Subsequently, a would-be attacker could advance to the next level of deception. Ring 2 - Honeyd
Ring 1 HONEYPOT
ASSET
Ring 2 HONEYD
Ring 3 FAKEAP
HONEYD LOGS
SNORT IDS
The Honeyd was configured to appear as a wired network containing web servers and client workstations that were accessible to wireless services. Honeyd mimics legitimate services through direct manipulation of the network stack of a designated OS. This involves simulating connections made at the network level. These include TCP, IP, UDP, and ICMP. Honeyd was designed this way to combat popular network security scanning tools such as NMAP (Conry-Murray, 2001; Fratto, 2003; Noordergraaf, 2002). NMAP utilises TCP/IP handshakes at the network level to administer connections and enumerate network information such as the OS type and version, opened or blocked TCP/IP ports, in addition to active services. Thus, relayed packets from the network level can give substantive data about the victim/probed device that denotes consequent OS vulnerabilities and possible exploitive opportunities for an attacker. Each computer-system in the Honeyd virtual network emulated an OS “personality” (Provos, 2003), which is a precise match of an NMAP or Xprobe prescribed OS “signature.” The signatures are provided in an NMAP and Xprobe fingerprint file. The files enumerate the flag sequence of TCP/IP communication that is used to distinguish different OS platforms. Therefore, when NMAP scans Honeyd it should pick up the personality signature and recognise it, subsequently identifying the OS. NMAP fingerprints were tested in a wired environment in an earlier study (Valli, 2003) to determine which OS signatures could be identified over five different NMAP scan types. The successful OS signatures were then crosschecked in the NMAP fingerprint file used by Honeyd. This was done to determine which NMAP fingerprints Honeyd could use as OS platforms in its configuration that had a high likelihood of being remotely guessed by NMAP over the wireless medium. Figure 2 illustrates the logical configuration of the Honeyd virtual networks.
Figure 2 - Logical configuration of the Honeyd virtual networks
Ring 1 – Honeypot asset and Central Logging Structure (CLS) The honeypot itself was a Linux Mandrake 9.0 machine that administrated all the deceptive services that were required for the rings of DiD in the wireless honeypot. The honeypot defence encompassed the deceptions deployed through rings 2 and 3.
INTERNET
Novell Server10.3.1.18
FREE BSD Server10.3.1.16
AIX Server10.3.1.14
SOLARIS Server10.3.1.17
Win NT4 Web Server10.3.1.200
Win NT4AP Bridge
Workstation
Workstation
Workstation
Workstation
Workstation
Workstation
Workstation
Workstation
Workstation
Workstation
W in 98Workstation
Win 98Workstation
Router10.3.1.1
IDS
CISCO Hub/Switch10.3.1.12Wireless
Client
W irelessClient
A central logging structure encompassing the IDS SNORT (Caswell & Roesch, 2002) packet sniffer served in cooperation with the Honeyd logs to passively record all system traffic. The network data collected would be used to confirm network penetration through captured and dissected information that includes the source and destination: IP address, MAC address, TCP/IP ports and the protocols used, as well as any buffer outputs. ROUND 1 - RESULTS The testing for the effectiveness of deceptions used in the wireless honeypot was conducted in two rounds and in a closed laboratory. The first round was a baseline test to determine if the wireless honeypot could gather data through scans and subsequently, be attacked with the given honeypot configurations and architecture. This was also to confirm if FakeAP and Honeyd were able to run concurrently on the same machine. Ring 3 testing of FakeAP with Kismet and Netstumbler Round 1 of the testing involved FakeAP at the outer ring of the DiD of the wireless honeypot. The wireless sniffing tool Kismet was able to pick up the beaconed 802.11b packets from the rogue access point and gather data. The data was the SSID of the rogue AP as “WinNT AP”; the channel of the WinNT AP used, which was channel 4; and the IP address of the WinNT AP. Netstumbler was used to verify the data collected by Kismet. This included the detection of the SSID of the rogue AP as “WinNT AP”, in addition to the MAC address which matched the vendor as Cisco, and the channel of the WinNT AP as channel 4. On detection of the rogue AP and the IP of the wireless gateway, the broadcasting of 802.11b parameters by FakeAP was disabled. The deactivation of FakeAP did not affect the wireless connectivity of the attacking machine to the honeypot because the AP’s IP gateway was also configured as the gateway into the Honeyd virtual networks. FakeAP and Honeyd were tested separately to minimise confounding variables that may arise in the software that could affect reliability of the collected data. Ring 2 testing of Honeyd with NMAP Testing of the next ring encompassed stealth and brute force scans of the Honeyd virtual networks. The goal of the Round 1 testing on ring 2 was also a baseline test to investigate if the network-scanning tool NMAP could retrieve data on the ports and services belonging to OS’s in Honeyd. The network security tool Nessus would then be used to target probes to specific OS services. Five of the NMAP scan types were conducted, which were the SYN, FIN, UDP, NULL, and XMAS scan types on each IP address. The scans were performed three times on each IP address to test and check the reliability of results for each scan. It was found there were some software bugs in NMAP and Honeyd which created some inconsistencies, therefore, some NMAP scan types were conducted a fourth time for verification. The OS’s chosen for the Round 1 testing included a Cisco 3com Router, Cisco Hub/Switch, AIX Server, OpenBSD Server, Solaris Server, Novell Server, FreeBSD, Cisco Hub, Cisco Aironet AP, and the default OS was also a FreeBSD Server. Each OS was allocated a dedicated IP address, and the default OS assumed all unallocated IP’s in the network. Table 1 shows the results of the Round 1 NMAP scan tests. For each of the NMAP scan types conducted, a tick indicates if all three or four scans performed, resulted in correct OS guesses on all occasions. A cross indicates not all or no correct OS guesses on all of the scans performed. Some IP’s were allocated the same OS, and several of the IP’s with the default OS were scanned. This was to check if all the OS’s could be fingerprinted regardless of their IP. The IP addresses have been excluded from these results in all tables. Round 1 NMAP scan results showed that Honeyd was not effective in deceiving NMAP on all occasions. The SYN, FIN, and NULL scan types conducted by NMAP were more successful than UDP and XMAS scan types, for remotely guessing the OS’s on Honeyd. The Cisco 3com Router, AIX, and Novell servers were among the most deceptive signatures used by Honeyd that fooled NMAP. This data indicated a lack of successful deceptions in Honeyd and suggested that some of the OS signatures may have had errors and would require amendments for Round 2 of testing. These results showed a
contrast to the previous study of NMAP fingerprinting tests in the wired environment, as not all the same NMAP scans types worked over the wireless medium.
Computer and OS Platform SYN
FIN
UDP
XMAS
NULL
Cisco 3com Router ü ü ü x ü Cisco Hub/Switch ü ü x x x Default to FreeBSD x ü x x x AIX Server ü ü ü x ü FreeBSD x x x x ü OpenBSD Server ü ü x x ü Solaris Server x x x x x Novell Server ü ü ü x ü FreeBSD x ü x x ü Default to FreeBSD x ü x x ü Cisco Hub x x x x x Cisco Aironet AP x x x x x
TABLE 1 – Round 1 NMAP scan results
Ring 2 testing of Nessus Round 1 testing using Nessus aimed to determine if Nessus would be deceived by returning data such as the OS platform with a list of exploitable services. Three Nessus scans were conducted on each IP to ensure reliability. All three tests conducted on each of the OS’s returned the same results indicating the Nessus scans gave consistent results. Each Nessus scan generated a report that listed the TCP/IP ports opened and any related security warnings, vulnerabilities (security holes), and the level of the security threat posed (indicated as L, M or H; meaning low, medium or high). Table 2 shows the results from the Round 1 Nessus scans. Nessus was able to guess successfully all but two OS’s, Solaris, and the Cisco Aironet AP, which it determined as the default instead. These errors indicated that the Honeyd configuration file most likely had an error with the Solaris and Cisco Aironet personality signatures that would need correcting for Round 2 testing. The data Nessus did report where security holes, warnings, and vulnerabilities that applied to services run on each of the OS’s.
Number of warnings
Number of vulnerabilities Remote OS guess List of Ports
ROUND 1 RESULTS SUMMARY The overall results from ring 1 testing showed that the rogue access point could be sniffed and data on the AP could be identified by the wireless sniffing tools Kismet and Netstumbler. The data collected by the sniffing tools identified the existence of an AP by the SSID, IP address, MAC address, channel used, and a potential gateway to the Honeyd virtual network. Results from ring 2 testing showed that NMAP was able to enumerate some remote OS guesses from the Honeyd virtual networks. Nessus was able to give further OS security warnings, vulnerabilities and holes on services running on the scanned OS through brute forced probes. Consequently, Round 2 of the testing required further NMAP and Nessus probes on a reconfigured Honeyd network to investigate if the scanning tools would detect correct data on all the OS’s. ROUND 2 - RESULTS Honeyd was reconfigured to reflect a more realistic corporate wireless network incorporating routers, servers, and client machines presented in a structured layout. Corrections were made to the Honeyd configuration file to remove trivial signature errors and ensure that all the scripts were accurately matched to an NMAP prescribed signature. Figure 3 illustrates the revised Honeyd virtual networks in a logical configuration.
FIGURE 3 – Revised Honeyd logical implementation
Attacking Machine192.168.1.253
Honeypot with FakeAP192.168.1.99
Routerone10.1.1.1
Routertwo10.3.1.1
Hub/Switch10.2.1.1
Solaris Web Server10.2.1.5
Novell Web Server10.2.1.7
FreeBSD Web Server10.2.1.6
Linux Web Server10.2.1.2
OpenBSD Web Server10.2.1.4
AIX Web Server10.2.1.3
Cisco AP10.1.1.2
Windows 9 8client machine
W indows 9 8client machine
Windows 9 8client machine
Network Address 10.1.1.0
Network Address 10.2.1.0
Network Address 10.3.1.0
DMZ
The Linux Mandrake 9.0 machine was maintained as the honeypot installed with FakeAP and Honeyd. The gateway IP address of FakeAP, which was also the AP gateway to the Honeyd virtual networks, remained the same. The logical network topology of the Honeyd virtual networks encompassed three subnets separated by Routerone, a hub, and Routertwo. The first network utilised Routerone as the first route entry into the network and the network address was shared only with the Cisco Aironet AP. The second subnet was intended as a corporate Demilitarised Zone (DMZ) containing all the network servers. Six OS platforms were allocated to six IP address spaces in this network. A second linked route entry using a hub separated the OS platforms Linux, AIX, OpenBSD, Solaris, FreeBSD and Novell. These OS’s were chosen to represent a variety of platforms with testable vulnerabilities. The third subnet route entry was connected via Routertwo. This subnet encompassed a network of all the unallocated IP spaces that were assigned the default OS. All IP address spaces in the third subnet were allocated a default as Windows 98 machines. The aim was for the network to appear as an assembly of Windows 98 client machines that accessed the servers and services from the DMZ in addition to wireless connectivity. Ring 2 testing – NMAP The purpose of the Round 2 NMAP testing was to investigate if the reconfigured Honeyd could deceive NMAP. The data collected were the remote OS guesses using the same scan techniques. The same five NMAP scans types were conducted, however, for Round 2, five scans were performed instead of three to validate the final NMAP scan/test results. Table 3 shows the findings from the Round 2 NMAP scans.
Windows98 w/ Service Pack 1 x x x x x Network Address x x x x x Cisco Router/Switch with IOS 11.2 (Hub/switch)
ü ü x x x
Linux Kernel 2.4.0 – 2.4.18 (X86) ü ü ü ü x AIX v4.2 ü ü ü ü ü OpenBSD 2.7/SPARC or NFR IDS Appliance ( 12/10/00 )
x ü ü ü ü
Solaris 2.6 – 7 X86 x x x x x FreeBSD 2.2.1-STABLE ü x x x x Novell Netware 3.12 – 5.00 x ü ü ü ü Windows98 w/ Service Pack 1 x x x x x Network Address ü x x x x Cisco 726 Non-IOS Software release 4.1(2) or 766 ISDN router (Routertwo)
x ü x x x
Windows98 w/ Service Pack 1 x x x x x Windows98 w/ Service Pack 1 x x x x x
TABLE 3 – Round 2 NMAP scan results
Round 2 of the NMAP scans did not demonstrate an improvement of Honeyd deceptions. However, NMAP was able to successfully guess the Cisco Aironet on all scan attempts and across all five scan types conducted. This was a positive observation as this indicated a deception of wireless capability on
the network (Honeyd virtual network). Linux, AIX, and Novell were other OS’s that were able to fool NMAP in either all or most cases. An interesting software anomaly was found in the NMAP scans in that the network addresses were also scanned (on all scan types), although the network addresses were not specified to be scanned. As the network addresses were not allocated any instructions in the Honeyd configuration file (such as a request timed out message), the default OS was assigned by Honeyd. Another NMAP abnormality that became apparent was in the XMAS scan type where the network addresses were scanned in-between each selected scanned OS in the network. It was not known why the XMAS scan type did this, although it may have been attributable to a software error. Ring 2 testing – Nessus attacks For the Round 2 testing of the Nessus attacks, five scans were attempted on each OS in Honeyd. It was found that Nessus was not able to scan Routerone at all, or any of the default assigned OS’s. This included all the Windows 98 machines in the third network (excludes Routertwo), which occupied an extensively lengthy scan time and resulted in a Nessus Crash. Additionally, scans conducted on Routerone (3com Office Connect) stopped and closed at every attempt made. Consequently, the results shown in Table 4 exclude the OS platforms that Nessus would not scan. Each of the five scans performed on all the OS’s produced the same findings except for the fourth Nessus scan on Hub/switch (Cisco Router/Switch with IOS 11.2), which produced two security warnings. The other four scans performed on the same OS produced only one warning. In the Round 2 Nessus testing, this was the only irregular finding. This may have indicated a software error. Nessus was still able to guess the remote OS for the Cisco Routers, Linux, AIX, OpenBSD, Solaris, and Novell. Additionally, the data accumulated by Nessus was at least, one security vulnerability and/or vulnerability (hole) on each of the OS’s for a potential attacker to investigate further and exploit.
Number of warnings
Number of vulnerabilities Remote OS guess
List of Ports Opened L M H L M H
No OS guess 1 Cisco Router/Switch with IOS 11.2
telnet 23/tcp 1
Linux Kernel 2.4.0 - 2.5.20 http 80/tcp 1
AIX v4.2 ftp 21/tcp http 80/tcp 1
OpenBSD 2.7/SPARC or NFR IDS Appliance ( 12/10/00 )
http 80/tcp 1 1
Solaris 2.6 - 7 X86 http 80/tcp 2 1 No OS guess 1 Novell NetWare 3.12 - 5.00 http 80/tcp 1 1 Cisco 762 Non-IOS Software release 4.1(2) or 766 ISDN router
telnet 23/tcp 1 1 1
TABLE 4 – Nessus scan results
Nessus was not able to guess the FreeBSD allocated OS, as indicated in Table 4 as “No OS guess,” as it was probable that Nessus was unsure of the exact OS. However, a warning was still found from the Nessus probes performed on that OS. Below is the warning generated by the Nessus scan performed on the FreeBSD OS:
Warning found on port general/tcp
The remote host uses non-random IP IDs, that is, it is possible to predict the next value of the ip_id field of
the ip packets sent by this host. An attacker may use this feature to determine if the remote host sent a packet in reply to another request. This may be used for portscanning and other things. Solution : Contact your vendor for a patch Risk factor : Low Nessus ID : 10201
A naïve attacker would not usually differentiate between a real warning and a false positive. Therefore, it may not matter if the OS was undetectable. The deception is this instance was that the warning provided a misleading vulnerability of the potential OS. This would still be exploitable by an attacker searching the vulnerability on the World Wide Web to discover how it may be targeted. Example sites include CERT® Coordination Center, Bugtraq, Common Vulnerabilities and Exposures (CVE), and SecuriTeam vulnerability search engines and databases. CLS results The intended purpose of the CLS was to provide a supplementary method of data collection to triangulate and verify attacks made on the wireless honeypot. The CLS comprised of the Honeyd log files, which demonstrated themselves to be lacking in the richness of information given. The data from the Honeyd logs only indicated the TCP/IP ports had some activity, and did not give further information of the possible attacks being performed at the network level and did not provide sufficient data for further analysis. The SNORT log files verified the attacks achieved by Nessus. This was useful as it provided triangulated verification of the Nessus generated data reports of scans. This also aided the deceptions through the victim’s concealed knowledge of attacker activity. ROUND 2 RESULTS SUMMARY The overall results gathered from Round 2 testing focussed on NMAP and Nessus scans and probes. Honeyd was reconfigured to overcome suspected errors found in the Round 1, NMAP, and Nessus tests. However, from the data collected on the five NMAP scan types and Nessus generated reports for Round 2 testing, Honeyd did not demonstrate that it could deceive effectively on all accounts. Some possible reasons may be that both NMAP and Nessus revealed software abnormalities through performing additional scans that were not requested, and refusing to perform scans that were requested. However, NMAP was able to detect three OS’s across all the five scan types out of sixteen that were scanned, and they were AIX, OpenBSD, and the Cisco Aironet AP. This indicated that some of the Honeyd deceptions were successful in fooling NMAP. Nessus reported at least one security warning or vulnerability on all the OS’s that it could perform a complete scan. Honeyd was therefore only effective at deceiving Nessus nine out of the possible twelve scans. DISCUSSION OF RESULTS The deceptions for FakeAP resulted as effective countermeasures against the network attacks of the wireless sniffing tools Kismet and Netstumbler. The forensic data that was collected from the 802.11b sniffing tools indicated they were both misled into believing a rogue AP existed. This was done by FakeAP’s deceptive mimicry of a real AP. FakeAP may also be an effective network countermeasure as an attacker would consume time and resources while ‘sniffing’ the fake AP; and consequently, the attacker may become deterred from real assets. However, the deceptions employed by the Honeyd virtual networks were not effective, on every occasion, in deceiving the attack tools used. The deceptive countermeasures employed by Honeyd included faked OS’s, login-banners, services, and OS vulnerabilities. It was found that the NMAP scans were less successful at guessing the OS’s in Round 2 of the testing, than in Round 1. Even after correcting the Honeyd configuration file, not all the NMAP scans were able to successfully fingerprint and guess the OS’s. Moreover, the percentage of correct OS guesses achieved in the first Round of testing was higher at 43.6%, in comparison to the percentage of correct OS guesses achieved in the second Round of testing; which was 33.75%.
Figure 4 depicts a comparison of NMAP scan results for each scan type performed in Round 1 and Round 2 tests. The diagram identifies that the SYN scans showed approximately 50% successful scans over the two Rounds of testing. FIN and NULL scans were more successful in Round 1, than in Round 2. UDP scans were reasonably more successful in Round 1, and XMAS scans produced some successful guesses in Round 2, compared to none in Round 1.
FIGURE 4 - A comparison of NMAP scans performed The implications of these NMAP results indicated that in the experiment, NMAP could not reliably fingerprint the Honeyd OS’s across the five scan types, which showed little or no regularity in results. Subsequently, Honeyd was not consistent in deceiving the network-scanning tool NMAP. The NMAP OS fingerprints selected for Honeyd were previously tested against all five scan types in a wired environment. Each OS fingerprint was able to be successfully detected by the NMAP - SYN, FIN, XMAS, UPD and NULL scan types (Valli, 2003). However, the results showed that NMAP was not able to fingerprint successfully the OS’s in a wireless environment using the same five scan types. This may have been attributable to a number of factors. It may be possible that the network packet sequence and exchange over the wireless medium most likely caused the irregularity in NMAP scan results. Another possibility may be that the NMAP software may became unstable when it was used continuously for prolonged periods. Many of the NMAP scans were performed on up to 16 OS’s at a time, and scan types were executed consecutively. Additionally, the ratio of correct OS guesses in Round 1 testing was higher than that of Round 2 testing; and Round 2 consisted of 34 more scans. Thus, the increased amount of scanning performed may have initiated a software overload and produced erroneous packets. Therefore, NMAP’s inability to guess correctly each of the OS’s, may have been a carry-over effect on the Nessus scans. This is because Nessus also utilises NMAP OS fingerprinting to guess the remote OS in each scan, prior to Nessus performing the brute force probing for vulnerabilities on OS services. Figure 5 outlines the scan results of both the Nessus scans conducted. Nessus was able to guess correctly most of the OS platforms for all the scans it completed, for both Round 1 and Round 2 testing. Nessus also generated data on at least one security warning or vulnerability per OS it scanned completely. The majority of Nessus scans produced the correct OS, with security warnings or vulnerabilities. There were no more than two incorrect guesses at a time and only in Round 2 of the Nessus scans. This indicated that Honeyd was effective on most occasions, at deceiving Nessus; however, not in every case. Therefore, the results from NMAP scans and Nessus brute force attacks identified a possible anomaly in the way wireless network scanning may be conducted. It was concluded that
NMAP Comparison of Scan Results
0%10%
20%
30%
40%50%
60%
70%
80%
SYN FIN XMAS NULL UDP
Scan Type
Per
cen
tag
e o
f co
rrec
t g
ues
ses
Round 1
Round 2
FakeAP demonstrated an effective deception because the attack tools for FakeAP were designed to function over the wireless medium. Honeyd and the attacking tools NMAP and Nessus were primarily designed for TCP/IP connectivity over a wired medium. The high packet loss and unreliable time variations over wireless TCP (Gomez & Campbell, 2000; Stoica, 2001) infer a high likelihood of failed OS guesses by the attack tools used. The data results from the NMAP and Nessus scans support this possible deduction.
FIGURE 5 - A comparison of Nessus scans conducted CONCLUSION The observed levels of deceptions achieved were significant for understanding how wireless networks may improve security. The deployment and testing of the wireless honeypot gave insight into the way deception may be effective and ineffective in a wireless environment against common network attacks. FakeAP demonstrated itself to be a highly effective deceptive tool for countering wireless sniffing tools. The Honeyd deceptions demonstrated inconsistent results that indicated that network-attacking tools might not be effectively deceived presently, when used in a wireless environment. Based on the findings of this experiment, it may be deduced that the effectiveness of deceptions used in wireless network defence will need further investigation. Possible avenues for investigation include analysing the TCP/IP packet sequencing and transmissions sent over a wired medium and wireless medium for comparison and subsequent detection of where errors occur. This may be done by using tools such as Ethereal, TCPdump, or AirSNORT. This testing may determine if Honeyd, NMAP, or Nessus require reconfiguration to handle TCP/IP transmission over the 802.11b wireless medium. The wireless honeypot may be deployed in a ‘live’ environment to test FakeAP and Honeyd deceptions and allow live attackers to connect to, and probe the wireless network. Recorded logs of any activity may give further insight on wireless network attack methods and the use of deceptive countermeasures for organisational network defence. REFERENCE Barnes, C., Bautts, T., Lloyd, D., Ouellet, E., Posluns, J., & Zendzian, D. (2002). Hack proofing your
wireless network. USA: Syngress Publishing Inc. Caswell, B., & Roesch, M. (2002). Snort (Version 2.0.2) [Wireless packet sniffer]. College of Aerospace Doctrine Research and Education. (1997). Air and space power mentoring guide
(essays - volume 1): Principles of war. Retrieved 1 March, 2003, from http://www.cadre.maxwell.af.mil/ar/MENTOR/vol1/SEC06.PDF,
Conry-Murray, A. (2001). Network security's not-so-secret ingredients. Network Magazine, 16. Deraison, R. (2003a). Nessus (Version 2.0) [Network vulnerability scanner]. Deraison, R. (2003b). Nessus introduction. Retrieved 12 Oct, 2003, from
http://www.nessus.org/intro.html Fratto, M. (2003). NIP attacks in the bud. Retrieved 20 Oct, 2003, from
http://www.networkcomputing.com/1417/1417f26.html Fyodor. (2003a). Nmap Remote OS Detection. Retrieved 4 Sept, 2003, from
Gerwehr, S., & Anderson, R. (2000). Employing deception in INFOSEC. Retrieved 18 Feb, 2003, from http://www.cert.org/research/isw/isw2000/papers/26.pdf
Gerwehr, S., & Glenn, W. (2003). Unweaving the web: deception and adaptation in future operations. Santa Monica: RAND.
Gomez, J., & Campbell, A. T. (2000). A Channel Predictor for Wireless Packet Networks. Retrieved 10 Feb, 2004, from http://comet.ctr.columbia.edu/~campbell/papers/icme2000.pdf
Gupta, N. (2002, 28 & 29 November). Improving the effectiveness of deceptive honeynets through an empirical learning approach. Paper presented at the 3rd Australian Information Warfare & Security Conference, Perth, Western Australia.
Kershaw, M. (2003). Kismet (Version 3.0.1). Milner, M. (2002). Netstumbler (Version 0.3.30). Nanda, S. (2002). Wireless insecurity / how Johnny can hack your WEP protected 802.11b network!
Retrieved 15 Feb, 2003, from http://www.cs.dartmouth.edu/~snanda/presentations/Wireless_Soumendra_CS188.pdf
Noordergraaf, A. (2002). How Hackers Do It: Tricks, Tools, and Techniques. Retrieved 20 Oct, 2003, from http://www.sun.com/solutions/blueprints/0502/816-4816-10.pdf
Provos, N. (2003). Honeyd: a virtual honeypot daemon (extended abstract). Retrieved 28 March, 2003, from http://www.citi.umich.edu/u/provos/papers/honeyd-eabstract.pdf
Provos, N. (2004). Honeyd - Network Rhapsody for You. Retrieved 9 February, 2004, from www.citi.umich.edu/u/provos/honeyd/
Rue, L. (1994). By the grace of guile: the role of deception in natural history and human affairs. New York: Oxford University Press.
Schoeneck, R. (2003). Wireless Honeypot. Retrieved 18 Oct, 2003, from http://www.giac.org/practical/GSEC/Richard_Schoeneck_GSEC.pdf
Spitzner, L. (2003). Honeypots - tracking hackers. Boston: Pearson Education Inc. Stoica, I. (2001). CS 268: Lecture7 (Wireless TCP). Retrieved 10 February, 2004, from
www.cs.berkeley.edu/~istoica/cs268/notes/lecture7.pdf The Honeynet Project. (2004). Know your enemy: learning about security threats. Boston: Addison-
Wesley. Valli, C. (2003). Honeyd - a fingerprint artifice. Paper presented at the 1st Australian Computer,
Information and Network Forensics Conference, Scarborough, Western Australia. Webb, S. (2002, 28 & 29 November). Wireless insecurity - current issues with securing WLANs
utilising 802.11b technology. Paper presented at the 3rd Australian Information Warfare & Security Conference, Perth, Western Australia.
Webb, S. (2003). Identifying trends in 802.11b networks in Perth. Paper presented at the Australian Computer Network, Information & Forensics Conference, Perth.
Yek, S., & Valli, C. (2002, 28 & 29 November). If you go down to the Internet today - deceptive honeypots. Paper presented at the 3rd Australian Information Warfare & Security Conference, Perth, Western Australia.
