# SDToW: A Slowloris Detecting Tool for WMNs
## 4 SDToW
### SDToW Modules  
After identifying the Slowloris-type malicious behavior, our tool initiates countermeasures to block the malicious traffic. Therefore, it performs the attack identification using a node to analyze the traffic log, here called Concentrator. The correct attack identification prevents legitimate users from being affected by restrictive measures, thereby generating fewer false positives. Figure 5 presents the three modules, described below:  
* CM: collection module (CM), which acts in the Web server.
* AFM: analysis and filtering module (AFM), which works in a different node called Concentrator.
* BM: blocking module (BM), which acts in the access points.  
Figure 6 presents the collection module (CM) flowchart working on the Web server. Initially, the CM collects traffic logs from HTTP requests. After that, it collects the traffic for five seconds. We choose to collect for 5 s because it was enough to collect relevant traffic information without delaying too much to send the traffic list to the Concentrator. In previous tests, a number between 5 and 7 s did not produce a relevant delay. Additionally, it provided enough time to detect and stop the attack before it depletes the server resources. It is essential to mention that this traffic collection occurs continuously. Therefore, at every 5 s, a new traffic list is created and sent to the Concentrator. After that, it creates a traffic log using the tool Tshark. We set Tshark to convert the received traffic to a pcap extension. Subsequently, CM removes irrelevant information concerning HTTP connections and creates the traffic list. Next, CM sends the traffic list to the Concentrator.  
Figure 4: Tracers from the Slowloris attack after applying the filters.  
Figure 5: SDToW architecture.  
1 Blacklist file
2 begin
3\(TL\longleftarrow\)TrafficList
4\(Line\longleftarrow\)Pointer to the first \(TL\) element /*EoFistheendofTL
5 whileLine\(\
eq\)EoFdo
6 ifLine contains\"GET\"AND\"ReassembledPDU\"then
7 ifLine containsPacktsize\(==\)296 then
8 Extract the \"Source IP\"
9 Insert \"Source IP\" on the Blacklist
10
11 end if
12
13 end if
14
15 end if
16 ifBlacklist\(\
eq\)emptythen
17 sendBlacklist to the APs
18
19 end if
20
21 end if
22
23 end if
24
25 end if
26
27 ifBlacklist\(\
eq\)emptythen
28 sendBlacklist to the APs
29  
Protocol). DHCP may designate an IP once leased to an attacker to a new user. Therefore, if our tool performs the block based on IP address, it could perform a denial of service for legitimate users.  
```
1 Block attacker IP begin
2\(BL\longleftarrow\) Traffic List
3\(Line\longleftarrow\) Pointer to the first \(BL\) element
4\(ARPIP\longleftarrow\) list of all ARP table IPs and MACs /* EoF is the end of BL */
5 while\(Line\
eq EoF\)do
6 if\(ARPIP\) contains any IP from \(BL\)then
7 Extract the corresponding MAC from \(ARPIP\)
8 Block the MAC
9 end if
10
11 end while
12
13 end while
```  
**Algorithm 2**Blocking module (BM)  
All the WMN nodes contain the blocking module. Therefore, when the AFM sends the blacklist, it is stored on all WMN nodes. Storing the blacklist on each WMN node permits that it compares its new ARP table whenever a new client connects to the AP. Therefore, if a blocked attacker moves from one AP to another, it will be blocked. Comparing its new ARP table with the blacklist, the current AP will block the attacker by its MAC.  
Our tool excludes addresses from the blacklist after a configured period. In our experiments, we maintain the address for 72 h. Whenever a previously blocked attacker tries to access the network during the blocking period, our tool doubles the exclusion period. Network administrators can change this period according to their policy.