## 4 DPI Applied to Honeynet Traffic and Attacks
### Description of the Architecture  
The traffic used to show the results corresponds to the months from August 2016 to December of 2016. Figure 3 depicts the architecture of the Honeynet and its active honeypots. \begin{table}
\begin{tabular}{c c} \hline \hline
**Flags Set** & **Response Interpretation** \\ \hline SYN & If a RST is received, the port is closed. \\ \hline ACK & If the target does not respond, the port is filtered by a firewall. If a RST is received, it is not filtered. \\ \hline FIN, URG \& PUSH \\ (Xmas Scan) & If the target does not respond, the port is open. If a RST is received, it is closed. \\ \hline No flags set & \\ \hline \hline \end{tabular}
\end{table} 
Table 4: TCP flags used to scan for open ports and their respective response interpretation. \begin{table}
\begin{tabular}{c c} \hline \hline
**Protocol** & **Description** \\ \hline Telnet & The Data field, that holds the actual sent message, may be searched for brute-force attacks, when an individual tries several different and unsuccessful credentials; and for botnets such as Mirai, when detecting the presence of keywords. \\ \hline FTP & The Request Command field shows, among others, the username and password used to connect to the server, allowing the detection of brute-force attacks. \\ \hline SMB & The Path and File fields shows, respectively, the path and name of the file the client wants to fetch from the Server Message Block (SMB) server. Specific content in these fields may provide evidence of malicious activity, such as W32.IRCBot. \\ \hline HTTP & The Request Uniform Resource Identifier (URI) field shows the URI the client wants to get, and the presence of some characters and/or keywords may provide evidence of the use of probe tools, like Nmap, or other malicious activities. \\ \hline NTP & The Request Code field specifies the operation requested by the client. Specific values in this field may be used in a DoS attack. \\ \hline HTTPS \& SSH & As these protocols are encrypted, their fields cannot be analyzed, but only their metadata, such as the packet’s source, time, etc. \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Application layer protocols and their respective possible headers’ analysis. Host IP 172.30.20.100 is set for test purposes. Basically, it is used to verify if the packets are being correctly captured and logged. Host IP 172.30.10.20 is the machine from where data is collected and pcap files are exported. Using TShark tool [68], pcap files are converted to csv format. Each line in the csv file represents a packet received or transmitted at the Honeynet and columns represents the fields of the analyzed protocols and layers (see Table 1 for details). After the conversion, the csv files are processed, indexed and visualized using the Elastic Stack [69], through which the analysis is performed and statistics generated. It is important to state that the CoC procedures and its principles (described in Section 2.5) were followed, creating copies of the evidence and documenting every investigation carried out. As noted in Figure 4, which presents sample lines of the csv file, the character ')' is used as a separator, because some fields, such as _telnet.data_ in the first line of the figure, contains the character ',' (default separator) and, for the purpose of keeping constant the number of columns in every line, the separator must be a character not commonly present in the analyzed fields. The first line also shows that packets originated in the Honeynet are not georeferenced, as the IP addresses of the honeypots are private.