% !TEX encoding = IsoLatin

Iptables is a simple tool, present in Linux kernel, that allows to load some filtering rules with some simple commands.

According to Iptables \textit{man-page}\cite{iptables-project}, there some useful commands that allows to customize filtering rules and tables in the host:

\begin{itemize}
	\item \code{iptables -L [chain]}: list all rules in the selected chain. If no chain is selected, all chains are listed;
	
	\item \code{iptables -F [chain]}: flush the selected chain (all the chains in the table if none is given;
	
	\item \code{iptables -N chain}: create a new user-defined chain by the given name;
	
	\item \code{iptables -X chain}: delete the optional user-defined chain specified;
	
	\item \code{iptables -A chain rule-specification}: append one or more rules to the end of the selected chain;
	
	\item \code{iptables -D chain rule-specification/rulenum}: delete one or more rules from the selected chain;
	
	\item \code{iptables -I chain rulenum rule-specification}: insert one or more rules in the selected chain as the given rule number.
\end{itemize}

Therefore, it is necessary to perform a translation from a series of filtering rules to the list of necessary commands. A validity check is necessary to build correct commands without producing errors or malformed rules.

These commands needs to be executed directly on the host that will perform filtering actions.
In our work, we divided Iptables rule injection in two scenarios, according to the distribution/optimization process outcome.

\subsubsection{Physical hosts}
If a rule needs to be loaded into one of the OpenStack deployment hosts, we need to divide this scenario in two more cases.
These cases depends on which hosts the rule will be loaded compared to the host on which the tool is executed.

\begin{itemize}
	\item \textit{Local host}: if the filtering rules will be injected on the same physical host on which the tool is running, the Iptables commands can be launched locally.
	
	\item \textit{Remote host}: if the target host is a remote host, it necessary to open an SSH connection to that host and launch Iptables commands remotely.
\end{itemize}

For this reason we needed to implement two different rule injection mechanisms, the former based on a local command execution and the latter based on a SSH connection.

\subsubsection{Instances}
To inject rules on virtual machines is necessary to get SSH access to them. In cloud architectures, like OpenStack, it can be a problem, because an instance can be launched on a private virtual network, unreachable from the external networks.

OpenStack offers a web-console, allowing administrators to control virtual machines directly from the dashboard. This approach is extremely useful for a quick, intuitive and simple instance management. For our project, instead, this type of console access is not applicable to an automatic optimization tool, so it was necessary to find another way to get access to virtual machines console.

Exploring OpenStack internal architecture, it is possible to understand that the Network node is responsible of the connection between the instances and the ''external world''. In particular every virtual router in the deployment (if its routes are correctly configured) can reach every instance in the deployment, altough they are in private networks.

Every virtual router is represented as a Linux \textit{network namespace}. On namespaces, it is possible to launch commands in the same way as the ''normal'' command-line. We exploited this mechanism to get SSH access to the virtual machines from every host that runs the program. These commands can be only launched on the Network node because is the only node of the OpenStack deployment that has the access to the virtual routers of the topology.

This procedure is divided in two sub-cases depending on which host the tool is running:

\begin{itemize}
	\item \textit{Network node}: if the tool is running on the Network node the commands to get access to instances can be launched locally.
	
	\item \textit{Other nodes}: if the tool is not running on the Network node these commands need to be executed via SSH connection from the Network node.
\end{itemize}

Is important to notice that if a virtual machine has a ''floating IP'' exposed on the external network, rules can be injected directly on the instance. The procedure is the same previously described as ''Remote host'' rule injection.

\subsubsection{Requirements}

To guarantee security to SSH connection we imposed two constraints:

\begin{itemize}
	\item \textit{Administrator account}: every physical host or virtual machine must have an account, enabled to launch Iptables commands, to log in to from SSH connections;
	
	\item \textit{SSH Keys}: to guarantee secure connections all the instances and the physical hosts must have the SSH key of the host on which the tool is running, saved as ''authorized-keys''. In this way, password authentication is not required, improving connections security.
\end{itemize}
