\documentclass[11pt,a4paper]{article}
\usepackage[portuguese]{babel}
\usepackage[lining]{ebgaramond}
\usepackage{listings}
\usepackage{booktabs}

% \usepa

\lstdefinestyle{mystyle}{
    basicstyle=\ttfamily\footnotesize,
    breakatwhitespace=false,         
    breaklines=true,                 
    captionpos=b,                    
    keepspaces=true,                 
    numbers=left,                    
    numbersep=5pt,                  
    showspaces=false,                
    showstringspaces=false,
    showtabs=false,                  
    tabsize=2
}

\lstset{style=mystyle}

\setlength{\parindent}{0em}
\setlength{\parskip}{2ex}

\title{Practical Assignment \#2}
\author{
    João Neto -- 2023234004\\[1em]
    Vasco Alves -- 2022228207
}

\begin{document}
\maketitle
\tableofcontents
\newpage

\section{Introdução}

Este projecto tem como âmbito implementar, uma rede virtual privada (VPN) num cenário de road-warrior,
configurar two-factor authentication com os serviços OpenVPN e Apache, e gerir certificados X.509 utilizando OCSP.

O nosso cenario vai envolver três maquinas, o cliente (road warrior), a gateway que utiliza OpenVPN e um servidor interno com OpenSSL e Apache. O OpenVPN utiliza two-factor authentication, recebendo o utilizador, e uma password que é uma junção de uma fixa, e de uma gerada pelo plugin google-authenticator. O servidor de Apache implementa a mesma authenticação.

Temos então três máquinas virtuais:

\begin{tabular}{l l l}

   {\bf Nome} & {\bf Script} & {\bf Rede} \\\toprule
   Road Warrior & VM\_ROAD\_WARRIOR.sh & Rede Externa 193.168.0.0/24 \\
   VPN Gateway & VM\_OPENVPN\_GATEWAY.sh & Router \\
   OpenSSL / Apache & VM\_OPENSSL\_APACHE.sh & Reder Interna 10.60.0.0/24 \\
\end{tabular}

Os certificados utilizados foram certificados por uma autoridade central que não está no nosso cenario. A gestão da lista de revogação está a ser gerido pelo serviço OpenSSL que está na mesma maquina que o Apache. Num cenario real seria melhor dividir estes serviços por outras maquinas, mas os computadores que temos acesso estão limitados na quantidade de maquinas virtuais que consegue simular simultaniamente.







\section{Criação de certificados}
Criar chaves com 2048 bits.

Todas as chaves foram criadas no mesmo computador, com as variaveis que está neste codigo, aspetos importantes para mais tarde serão os parametros de CN que precisam de ser passados mais tarde para aceder ao Apache e ao gateway. Numa situação normal teriamos uma autoridade de certificação para enviar e no fundo gerir todos, mas para este cenario podemos inicializar as maquinas com as chaves, requests e certificados necessarios.

O codigo para gerar os certificados X.509: 
\begin{lstlisting}[language=bash]
cert_ca="/C=PT/ST=Coimbra/L=Coimbra/O=UC/CN=CoimbraVPN"
cert_vpn="/C=PT/ST=Coimbra/L=Coimbra/O=UC/CN=gateway"
cert_user="/C=PT/ST=Coimbra/L=Coimbra/O=UC/CN=warrior"
cert_apache="/C=PT/ST=Coimbra/L=Coimbra/O=UC/CN=apache.coimbra"

openssl genrsa -out "ca.key" 2048
openssl req -x509 -nodes -days 365 -key "ca.key" -out "ca.crt" -subj "$cert_ca"
openssl genrsa -out "vpn.key" 2048
openssl req -new -key "vpn.key" -out "vpn.csr" -subj "$cert_vpn"
openssl ca -batch -in "vpn.csr" -cert "ca.crt" -keyfile "ca.key" -out "vpn.crt" -config cheese.cfg
openssl dhparam -out "dh2048.pem" 2048
openvpn --genkey secret "ta.key"
openssl genrsa -out user.key
openssl req -new -key user.key -out user.csr -subj "$cert_user"
openssl ca -batch -in "user.csr" -cert "ca.crt" -keyfile "ca.key" -out "user.crt" -config cheese.cfg
openssl genrsa -out apache.key
openssl req -new -key apache.key -out apache.csr -subj "$cert_apache" -addext "subjectAltName = IP:10.60.0.1,DNS:apache"
openssl ca -batch -in "apache.csr" -cert "ca.crt" -keyfile "ca.key" -out "apache.crt" -config cheese.cfg
\end{lstlisting}

Porque é que precisamos de uma chave secreta?
Criar chave secreta.
\begin{lstlisting}[language=bash]
openssl --genkey secret ta.key
\end{lstlisting}
\section{Configuração geral}
Para configurar as VM's era preciso introduzir os mesmos comandos varias vezes, o que levava muitas vezes a erros de escrita, ou a correr o mesmo comando varias vezes, por isso criamos varios ficheiros .sh para conseguir facilitar o processo. A utilização de ficheiros .sh também vem com outros positivos pois facilita a testagem, e a recriação do cenario rapidamente.

No entanto para os serviços que configuramos, instalar, desativar e dar flush ás iptables não foi suficiente, tivemos que criar pastas e sincronizar os relogios de todas as VMs visto que elas estarem ligeiramente atrasadas nunca conseguiamos acertar na password do google-authenticator que utiliza o tempo local para calcular a sua chave.
\begin{lstlisting}[language=bash]
yum install -y epel-release
yum install -y openvpn iptables-services dhcp-client
systemctl stop firewalld
systemctl disable firewalld
systemctl mask firewalld
systemctl enable iptables
iptables -F

CA_DIR="/etc/pki/CA"
mkdir -p "${CA_DIR}/newcerts"
mkdir -p "${CA_DIR}/private"
touch "${CA_DIR}/index.txt"
cp ca/serial "${CA_DIR}/serial"

mkdir -p /etc/openvpn/server
mkdir -p /etc/openvpn/client

# NOTE(vasco): tive problemas com a sincronização de tempo
# se nao tiver sincronizado, o TOTP nao funciona
systemctl stop chronyd
ntpdate pool.ntp.org
systemctl start chronyd
\end{lstlisting}

\section{Configuração da \textit{Gateway} VPN}


\section{Configurar TOTP}



Foi criado o ficheiro \texttt{totp} com a configuração de autenticação a 
ser utilizada pelo plugin de PAM para o openvpn.

\begin{lstlisting}[language=bash]
plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so totp
\end{lstlisting}

\subsection{Aceder ao código}
Primeiro, na gateway, entramos como o utilizador desejado e obtemos a chave
do gerador de palavras passes temporarias. Ao inserir a chave no 
\texttt{google authenticator} podemos obter a nossa primeira chave de 6 digitos.

\begin{lstlisting}[language=bash]
su john
google-authenticator
\end{lstlisting}

\section{Revocation e OCSP}

\subsection{Testar OSCP via revoke}

\begin{enumerate}
    \item Conectar ao VPN e ver que funciona
    \item Na maquina host, nao nas vms, na repo mesmo.
    \item revogar o certificado via openssl -revoke user.crt -config cheese.cfg -keyfile ca.key -cert ca.crt
    \item Fechae OSCP e correr VM\_OPENSSL novamente (copiar index.txt e serial?)
    \item Tentar outra vez e ver que de facto falha 
\end{enumerate}



\section{Conclusion}
Conclusão!!!
Atingimos o objetivo deste trabalho, conseguimos configurar o VPN tunnel, o two-factor authentication e conseguimos criar e retirar acesso aos certificados que emitimos. Utilizar mais maquinas para simular um cenario maior seria redundante, teriamos que emitir mais certificados mas não iamos aprender muito mais. Para aprofundar (???)


\end{document}
Para tal, foi implementado um servidor e um cliente OpenVPN, certificados por uma autoriadade central (CA)
que em si é self-signed. Para além disto, foi implementado um sistema de autenticação de dois factores
através do plugin google-authenticator para o OpenVPN.

Existe ainda um servidor Apache e um servidro de OpenSSL OCSP. Para simpliflicar, a elaboração do 
projecto foram colocados na mesma maquina virtual, mas por razoes de seguranca poderia querer ter 
estes serviços separados. 

