esp-firewall/ESPFirewall/lib/Firewall/docs/firewall/firewall.tex

\section{Firewall}

\subsection{Software Firewall}

A software firewall is inspecting data that goes in and out of the device. It has to be installed on each device in the network. Therefore, can only protect one device at a time. Looking at already existing solutions for linux and other operating systems, rules and settings can be identified that need to be implemented for this firewall.

\subsection{UFW (Uncomplicated Firewall)}

To see how a firewall works, UFW was analyzed. A look at the table provides following information:

\begin{figure}[H]
    \begin{center} 
        \includegraphics[width=0.6\textwidth]{ufw}
        \caption{UFW}
        \label{fig:UFW}
    \end{center}
\end{figure}

A destination port on the device, the action of the firewall and the IP-Address from where the request originated can be setup. Also the protocol that the rule applies to, can be chosen with TCP or UDP.

\newpage

\subsection{Parameter}

After analyzing existing solutions following firewall parameters were implemented:

\lstset{style=c++}
\begin{lstlisting}
    typedef enum firewall_targets : uint8_t
    {
        TARGET_REJECT = 0,
        TARGET_DROP = 1,
        TARGET_ACCEPT = 2,
    } firewall_target_t;

    typedef enum firewall_protocols : uint8_t
    {
        PROTOCOL_TCP = 0,
        PROTOCOL_UDP = 1,
        PROTOCOL_ALL = 255,
    } firewall_protocol_t;

    static const uint8_t IPV4ADDRESS_LENGTH = 16;
    typedef struct firewall_rules
    {
        uint8_t key;
        char ip[IPV4ADDRESS_LENGTH];
        uint32_t port_from;
        uint32_t port_to;
        firewall_protocol_t protocol;
        firewall_target_t target;
        struct firewall_rules *next;
    } firewall_rule_t;
\end{lstlisting}

A port can be a maximum of 65565, therefore cannot be of type \verb|uint16_t| but \verb|uint32_t|. Target as well as protocol are enums for the available options. To block a range of ports, there is a \verb|port_from| and \verb|port_to|. The firewall will store all the rules as linked list to dynamically add and remove rules.

\subsection{WiFi Events}

To intercept network packages there is a need to somehow get notified when a new package arrived that needs to be analyzed. Based on the firewall rules, it can pass, gets dropped or rejected.

Available ESP32 WiFi Events can be seen in figure \ref*{fig:WiFi Events}. None of those events support reading incoming packages.

\begin{figure}[H]
    \begin{center} 
        \includegraphics[height=0.9\textheight]{wifi-events}
        \caption{WiFi Events}
        \label{fig:WiFi Events}
    \end{center}
\end{figure}

\cite[cf.][]{espressif-wifi}

\subsection{WiFi Buffer Usage}

Looking at the usage of the DMA buffer (Figure \ref{fig:WiFi Buffer}) of the driver we can see where we have to check for received packages.

\begin{figure}[H]
    \begin{center} 
        \includegraphics[width=0.8\textwidth]{wifi-buffer}
        \caption{WiFi Buffer}
        \label{fig:WiFi Buffer}
    \end{center}
\end{figure}

\cite[cf.][]{espressif-wifi}

\subsection{Wi-Fi Sniffer Mode}

Esp32 can be setup in a ``sniffer mode''. Following packets can be dumped to the application:

\begin{list}{-}{}
    \item 802.11 Management frame.
    \item 802.11 Data frame, including MPDU, AMPDU, and AMSDU.
    \item 802.11 MIMO frame, for MIMO frame, the sniffer only dumps the length of the frame.
    \item 802.11 Control frame.
    \item 802.11 CRC error frame.
\end{list}

The same can be done with the esp8266 as described in this article: 

\href{https://carvesystems.com/news/writing-a-simple-esp8266-based-sniffer/}{https://carvesystems.com/news/writing-a-simple-esp8266-based-sniffer/}

\subsection{Benchmark}