Port Scanning Techniques: Comparing Accuracy and Overhead with Nmap, Schemes and Mind Maps of Network security

Download Port Scanning Techniques: Comparing Accuracy and Overhead with Nmap and more Schemes and Mind Maps Network security in PDF only on Docsity!

Dr Mahdi Aiash

4/24/

On Assessing the Impact of Ports

Scanning on the Target

Infrastructure

1. Introduction

A port scan is a method for determining which ports on a network are open. As ports on a computer are the place where information is sent and received, port scanning is analogous to knocking on doors to see if someone is home. Running a port scan on a network or server reveals which ports are open and listening (receiving information), as well as revealing the presence of security devices such as firewalls that are present between the sender and the target. This technique is known as fingerprinting. It is also valuable for testing network security and the strength of the system’s firewall. Due to this functionality, it is also a popular reconnaissance tool for attackers seeking a weak point of access to break into a computer.

Generally speaking, ports scanning probes a number of well-known ports (for TCP and UDP) by sending raw network packets to these ports, and based on the responses from these ports, it classifies ports in one of these states:

• Open or Accepted: The host sent a reply indicating that a service is listening on the port.
• Closed or Denied or Not Listening: The host sent a reply indicating that connections will be denied to the port.
• Filtered, Dropped or Blocked: There was no reply from the host.

2. Problem Definition

Fingerprinting and port scanning are the longest stage during pentesting engagements. The thoroughness and completeness of this stage is a key for the success of the vulnerability assessment and exploitation stages. Therefore, vendors have developed large number of port scanning tools (both commercial and open source). However, experienced pentesters might choose to deploy their own bespoke tool that suits their needs. It is important also to highlight that there are dozens of different types (techniques) of port scanning which are different from each other in the following ways:

• The way they parse the response of scanned ports, this effectivity affects the accuracy of the different scans.

Figure 1 Testbed

As shown in figure 1, a Linux firewall is placed between the internal and external network in order to protect the internal network and prevent unauthorised access from the Internet. This network is designed and built in a virtualised environment and is constructed close to a real enterprise network design. The attacker (scanner) machine located in the outside network will then run a python port scan script against the LAN network (192.168.1.0/24). Another computer (192.168.1.2) located in the target network will be closely monitoring the performance of the network without alerting the attacker that their actions are observed.

For the purpose of this project the LAN network will be monitored in two different occasions. In the first experiment a threshold is set as a base-line for acceptable level of network traffic, where in the second scenario a port scan attack will be launched against the target network while using the same base-line in the first scenario the impact will be measured and the gathered data will be analysed further. In experiment 2 of this project, the network design will remain the same but Nmap will be used to evaluate different scanning techniques.

3.1. Installation Phase

Both the attacker’s machine which run Kali-Linux OS and the target network machines were installed using VMware workstation Pro 12 and the network interfaces were configured according to the network design in figure 1.

3.1.1. Monitoring Software To monitor the LAN performance, the PRTG monitoring software is downloaded from the “www.paessler.com website to collect data and statistics from all the components in the network. After completing the installation of PRTG, the user interface opens up the standard browser and automatically starts discovering the network in the background as in Fig 2. Additionally, users can launch this software using the PRTG enterprise console which uses a native user interface.

3.1.2. Installing and Setting up Iptables firewall on Ubuntu Server:

Iptables is a Linux based firewall developed by Netfilter project (netfilter.org) and has been a pre-installed application in Linux kernels released after early 2001. Iptables are divided into two main components (userland administration program and kernel modules) where both the userland and the kernel are compiled. The latest releases of Linux distributions provide pre built-in kernels that have Iptables compiled in and does not require it to be installed as a separate feature. Many Netfilter subsystems such as packet filtering and connection tracking capabilities are included in the kernel source code and are enabled by default. It is very important to configure and compile Linux kernel appropriately as any misconfiguration error can lead to the Iptables firewall not functioning properly and risk the system becoming

Figure 2: PRTG

3.1.3. Installing and Setting up PSAD

PSAD is an application that runs on Linux hosts which monitors the Iptables log messages in order to detect, alert, and block a port scan or any other malicious activities that are taking place. Originally, PSAD started as part of the Bastille Linux project in the late 90s. Bastille Linux Project developers decided it was time to develop a network intrusion detection system (IDS). The idea of the team was to create something new and different from the existing IDS and that fits well with the Linux Firewall. As a result, the PSAD software was launched in 2001 to actively monitor and analyse the Iptables logs. For instance, in the event of TCP port scan, the PSAD is able to inspect the TCP flags and identify the type of the TCP scan e.g. SYN, XMAS, FIN, etc.). PSAD also makes use of many ICMP, UDP, and TCP signatures stored in the Snort IDS database to detect any suspicious traffic. For years, Firewalls have been the inline device to safeguard modern day networks and are usually positioned at the entry and exit point of the network. Due to some complexity in configuring firewall rules and the inability to block attacks at the higher level of the protocol stack, security experts have recommended that Firewalls should never be the only line of defence in any network. Therefore, combining Firewalls with PSAD will provide a strong security protection in any network.

PSAD is downloaded from the default repositories of Ubuntu. To obtain the PSAD program from Ubuntu’s Advanced Packaging Tool (APT) the command “sudo apt-get install PSAD” was issued. During the installation process several pieces of input are requested including the Postfix mail server (Fig 5) which is an e-mail address where any alerts generated will be sent to in the event of unusual activity within the network. The PSAD IDS will also allow the visualisation of the security status of the entire network which helps humans to recognise visual patterns than thousand lines of log messages.

Figure 4: Iptables LAN rules

The PSAD log analyser relies heavily on the Iptables policy configuration of that system. However, there are few necessary configurations needed in order PSAD to function properly.

All the PSAD daemons references are defined under the “ /etc/psad/psad.conf” main file which contains many configuration variables and controls the different aspect of how PSAD works. Since this is a large file, most of the configurations were not modified. The most important configuration variable are highlighted in Fig 6.

Figure 5: PSAD Installation

4. The Conducted Experiments:

After carefully configuring the network in the previous sections, different tests have been performed to inspect the impact of port scans on a network infrastructure. This section explains the conducted experiments and presents the results obtained. Two different experiment are conducted in this project. In the first experiment, an external scan has been performed in which the LAN network was scanned from the Internet (external network). Using PRTG network monitoring tool, the network was monitored for a period of around 20 minutes in three different occasions. Then the overall network performance is compared before and during the scan. In this scan we used a bespoke tool rather than relying on existing scanning tools. In the second experiment, the scan was conducted and different scanning techniques were performed using Nmap scanner. This experiment will assist a pen tester to choose the most efficient scanning technique in terms of performance and OS detection accuracy.

4.1. The First Experiment

In order to simulate an external attack or a black-box pentesting, we developed our own script that achieves:

• Ping Sweep: to discover live hosts in the LAN
• PortScanning: to identify open ports on the discovered, live hosts
• Banner Grabbing: After identifying the open ports, our script will fingerprint discovered service as to be able to find out any vulnerabilities specific to the discovered services. The goal of this scenario is to evaluate how a detected port scan can impact the overall network performance and increase latency. 4.1.1. Latency

In the Internet Protocol (IP) network Latency is defined to be the amount of time it takes for a packet to travel from a source to a destination, or the time it takes from a source to destination and back to the source, this is also known as Round Time Trip (RTT). There are numerous ways network latency can occur including queuing delay, TCP handshake delay, routing and switching delay. Common Internet applications such as FTP and HTTP utilize TCP to transfer data from server to client. Because the TCP is a core protocol of the TCP/IP protocol suite and uses the three-way handshake process prior exchanging data. This process can cause a total

packet loss to an already congested network by adding extra congestion. In this project latency is referred to as the amount of time it takes for a LAN network user to access and retrieve data from the external web and FTP servers. Multiple protocols were used including HTTP, FTP and ICMP to generate some traffic across the network in order to calculate the latency and response time of each protocol. 4.1.1.1. ICMP Latency: The ping utility uses the ICMP protocol to test connectivity between two IP hosts. Ping works by sending ICMP packet called echo-request to the IP host, and the host responds back with the echo-reply. The built-in ping utility in windows is used to ping the 192.168.1.155 host and to determine the RTT value. Multiple packets are sent before and during the scan. When the network is operational accordingly and no scan is taking place, a user on the 192.168.1.0/ network pings the 192.168.1.155 host (as the Gateway) and the result is recorded. The same step is repeated during the scan and the RTT value is recorded and compared to the value pre the scan. According to the results in in Figures 8 and 9, the RTT value was higher when the scan was taking place. The maximum response time before the scan is 3ms, while this value changes dramatically to a maximum of 146ms during the scan, which shows the significant impact of port scan attack in terms of performance when all the defence mechanisms are in place including Firewall and IDS/IPS

One of the advantages using PRTG tool is the ability to separate the performance of each protocol. According to figure 10, the maximum RTT time is 2.20 msec which indicates that the network performance is balanced and there are no unusual traffic patterns, otherwise an alarm should have been generated and sent to the admin if the thresholds set by the administrator were exceeded.

Figure 8: RTT value before the scan (^) Figure 9: RTT value during the scan

was taken when the port scan attack was scanning the network. In contrast to figure 13, the maximum loading time recorded was 39 msec. However, the results were different when the same user accessed the web server during the scan, where the maximum loading time was 63msec.

While the two results do not reflect a considerable delay, this could be ascribed to the fact that we established only one HTTP connection, if we are to simulate the case of a large number of HTTP connections (from the internal network), the delay will be considerably higher

4.1.1.3. FTP Latency

A file of 445672KB is downloaded from the FTP server in order to generate FTP traffic across the network and to examine its performance. From figure 14, the maximum response time to the FTP server is 4,208 msec. this value is expected to increase when the port scan test is performed. Figure 15 shows the FTP performance during the port scan. The same file is downloaded from the FTP server to generate some FTP traffic. Because the port scan was conducted, the response time from the FTP server reaches an all-time high of 13,757msec

Figure 12: HTTP response time pre the scan

Figure 13: HTTP response time during the scan

which is almost close to the packet being dropped. It also took longer to download the file from the FTP server compared to the pre scan time.

4.1.2. Analysing Iptables log file with PSAD

Reading log files can be challenging. PSAD is designed to analyse log messages and produce the scan results in a graphical way, which allows users to understand and analyse the source of the scan and its impact in terms of performance. Since PSAD interfaces with Gnuplot to deliver and produce a graph of number of scan packets. From figure 16, we can see how the port scan is impacting the performance levels of the network and ultimately this will cause unwanted delay.

Figure 14: FTP response time pre the scan

Figure 15: FTP response time during the scan

Figure16: analysing Iptables log file with PSAD

192.168.1.49 General Purpose Microsoft Windows Server 2012 16.03 97%

SYN Scan 192.16..1.44 Generalpurpose Microsoft Windows Win 7 25.41 97%

192.168.1.45 Generalpurpose Linux Ubuntu 3.14 15.13 95% 192.168.1.49 General purpose

Microsoft Windows Server 2012

16.48 96%

Fin Scan 192.168.1.44 General purpose

Microsoft Windows Win 7 51.81 95% 192.168.1.45 Generalpurpose Linux Ubuntu 2.4.20,2.6.14- 2.6.

99.17 93%

192.168.1.49 General purpose

Microsoft Windows Server 2012

46.44 96%

XMAS Scan 192.168.1.44 (^) General purpose

Microsoft Windows Win 7 55.95 96% 192.168.1.45 Generalpurpose Linux Ubuntu 2.4.20,2.6.14- 2.6.

99.09 93%

192.168.1.449 Generalpurpose Microsoft Windows Server 2012 15.61 95%

Quick Scan 192.168..1.44 General purpose

Microsoft Windows Win 7 14.90 94% 192.168.1.45 (^) General purpose

Linux 3.X 3.11-3.14 15.27 95% 192.168.1.49 Generalpurpose Microsoft Windows Server 2012 16.22 95%

Intense scan 192.168.1.44 Generalpurpose Microsoft Windows Win 7ultimate

75.69 97%

192.168.1.45 (^) General purpose

Linux 3.X 3.11-3.14 29.86 s 95% 192.168.1.49 Generalpurpose Microsoft Windows Server 2012 standard

80.77 s 98%

SlowComprehensive scan

192.168.1.44 (^) General purpose

Microsoft Windows (^) Win 7 ultimate6.

43.95 s 96%

192.168.1.45 Generalpurpose Linux Ubuntu 3.11-3.14 30.13 s 97% 192.168.1.49 General purpose

Microsoft Windows Server (^2012) standard

79.44 s 98%

4.2.2. Performance

According to Table 2, the scan duration, raw packets sent, and raw packets received were of various scan techniques were recorded. A total of 11 hosts were scanned ranging from 192.168.1.40 to 192.168.1.50. The goal of this experiment was to identify which scan type will have the lowest impact on the network. It was clear that number of raw packets sent and received had an influence on the level of performance in the network. The TCP connect scan had the least impact in relation to the overall performance and particularly the raw packets sent and received, because this type of scan does not require writing raw packets but alternately uses the connect () system call provided by the operating system. On the other hand, the TCP scan and intense scan have sent the highest raw packets of (1,683 MB).

Table 2: Different scan results Scan technique Target Ports toscan Scan date &Time Scanduration Discoveredhosts Raw-packets sent

Raw-packets received Full connect 192.168.1.40- 50 All ports() 27.08.1611:26 96.94s 8 Hosts 364B 196B SYN Scan 192.168.1.40- 50 All ports() 27.08.1611:29 63.74s 8 Hosts 1.683MB 1.37MB FIN Scan 192.168.1.40- 50 All ports() 27.08.1611:32 51.93s 8 Hosts 1.534MB 1.358MB XMAS Scan 192.168.1.40- 50 All ports() 27.08.1611:35 49.01s 8 Hosts 1.679MB 1.372MB ACK Scan 192.168.1.40- 50

All ports (*)

27.08. 11:

167.72.s 8 Hosts 1.534MB 1.363MB Null Scan 192.168.1.40- 50 All ports() 27.08.1611:46 57.8s 8 Hosts 1.539MB 1.358MB UDP Scan 192.168.1.40- 50 All ports() 27.08.1611:49 17675.36s 8 Hosts 4.437MB 6.91MB Quick Scan 192.168.1.40- 50 All ports() 27.08.1618:17 28.74s 8 Hosts 35.900KB 28.716KB Intense Scan 192.168.1.40- 50 All ports() 27.08.1618:23 57.98s 8 Hosts 1.683MB 1.376MB Slow comprehensiveScan

192.168.1.40- 50

All ports (*)

27.08. 19:

125.37s 8 Hosts 370.604KB 299.608KB

AggressiveScan 192.168.1.40- 50 All ports(*) 27.08.1619:45 186.78s 8 Hosts 1.324MB 1.391MB

Nmap scanning tool works fine with all scan types except the UDP scan. As illustrated in Figure 17, the UDP scan duration took very long to complete to the point where that scan was stopped before it finished scanning. It suggested that Nmap is not the right tool for UDP scan as it waits response from each port. If the target port does not respond, the Nmap retries a couple of times before moving on to the next port. This is due to the fact that open and filtered ports barely send any response which forces Nmap to timeout. Other scanners such

Fig 18: Slow Comprehensive Scan

Null Scan

Fig 19: Null Scan Intense scan

Fig 20: Intense Scan Quick scan

Fig 21: Quick Scan

4.2.4. HTTP Response Time (Highest impact)

During this experiment the scan with the highest impact on the network performance were captured and was concluded that the ACK scan and the aggressive scan seemed to add more overhead in the network than any other scan type. As could be seen in figures 22 and 23 respectively. The maximum response time in the ACK scan is 340 msec, while with aggressive scan the loading time slightly decreases to 204 msec compared to the ACKS scan. Aggressive scan ACK scan

Fig 22: Aggressive Scan. Fig 23: ACK Scan