# SDToW: A Slowloris Detecting Tool for WMNs
## 5 Results
### Experiment 3: Comparing SDToW with Snort  
After conducting the experiments mentioned above, we set up a new experiment comparing our tool with Snort. We chose Snort because it is a widespread tool with multiple functions to detect and block attacks. Additionally, the literature presents Snort as a tool to counter the Slowloris attack. Snort was initially created to be an open-source IDS and later become an IPS. It permits real-time protocol analyses and permits investigations concerning attack behavior. Snort also provides an extensive attack database providing many filters to detect attacks, i.e., fingerprint attacks, buffer overflow, DoS and port scans. Snort initially scans the pre-selected interfaces, acting like a sniffer. During this sniffer task, Snort can capture packets from the network using a passive capture or by inspecting pre-collected traffic. After collecting traffic data, it uses its decoder module on the collected packets. The decoder module inspects packets, searching for anomalies that differ from the default protocol behavior. Then it uses the pre-processor engine that provides in-depth attack analyses on the received traffic. After detecting an attack that matches its internal attack rules, Snort can provide two responses: an attack alert and an action based on the alert. The attack alert consists of generating logs detailing the traffic associated with the alert on the library rules. The action based on the alert provides prevention action during an attack--i.e., blocks an attack. Snort also permits the creation of new detection rules based on the predefined attack behavior. In this work, we used a Snort rule that verifies the number of ongoing connections for each network device. Therefore, whenever a device reached a maximum connection threshold, it would generate an alert and subsequently block the attacker. Figure 10 presents the Snort scenario gathering information from the incoming traffic. We placed Snort between the AP and the Web server. We designed this scenario to permit a fast attack response by Snort. Therefore, it can block the attacker whenever the malicious traffic matches the anti-Slowloris rule. Figure 9: The influence of the number of hops on the total blocking time. In this scenario, Snort blocks the attacker by its IP address instead of the MAC address as our tool does. The present scenario imposes Snort to block malicious traffic only by its IPs because it has no information regarding the attacker's MACs addresses. Only the APs that directly provide WiFi access to the clients identify their MAC address. Therefore, considering that Snort does not operate inside the APs, we set Snort to block only the attacker's IP. We set up a rule to block attackers with a specific number of ongoing connections to the Web server, thereby blocking whenever the number of connections from the same IP exceeded the specified number of ongoing connections. We compared Snort and our tool by measuring the processing consumption, memory consumption and false positive errors. By measuring the processing consumption and memory consumption, we analyzed both tools regarding their scalability. The amount of analyzed traffic data directly influences the scalability of the tools. After that, we measured the incidence of false positives affecting legitimate users. The wrong classification of legitimate users as attackers creates problems that can jeopardize the solution. That problem emerges when many legitimate clients are classified as attackers and are thus blocked. Firstly, to measure processing and memory consumption, we set up a scenario varying the number of clients: Figures 11 and 12. The first test uses only one client, and this client is the attacker. The subsequent tests present three and six clients, including among them one attacker client. Increasing the number of clients boosts the amount of traffic data and thus raises the resource consumption. In the experiment with six clients, our tool achieved 66.7% less processing consumption and 89.1% less memory consumption than Snort.