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

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

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

\begin{document}
\maketitle

\newpage
\tableofcontents

\newpage

\section{Introdução}

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

% NOTE(vasco): Eu acho que basta explicar o cenario e explicar como decidimos 
% implementar <- yeah agree, also esta introdução acho que é boa fala sobre o objetivo
% e o cenario, e porque é que o nosso cenario é como é. Não sei se a parte das razões de
%segurança devia estar nesta parte ou na conclusão como perpetiva futura e reflexão, mas aqui
%também não está mal.

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

Decidimos utilizar apenas três máquinas virtuais: o cliente (ou \textit{road warrior}),
a \textit{gateway} que utiliza OpenVPN e um servidor interno com OpenSSL e Apache. 
Isto simplifica a elaboração do projecto, mas por razões de segurança poderia querer
separar a máquina de OpenSSL de outras máquinas destinadas a serviços da rede interna,
pois esta contém o \textit{certificate authority} (CA). 

% Ambos o OpenVPN eo  servidor Apache utilizam 2FA,
% recebendo o utilizador, e uma password que é uma concatenação da palavra-passe do utilizador
% e de uma password temporária (TOTP) de 6 dígitos. O servidor de Apache implementa a mesma autenticação.

\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 & Rede Interna 10.60.0.0/24 \\
\end{tabular}

\section{Preparação Inicial}

\subsection{Criação de Certificados}

Os certificados utilizados foram auto-certificados por uma autoridade central que ``pertence''
à máquina de OpenSSL. Esta mesma faz a gestão da lista de revogação.

Todas as chaves foram criadas no mesmo computador, com as variáveis que estão
neste código. Aspetos importantes para mais tarde serão os parâmetros de Comon Name (CN)
pois servem para a validação do certificado ambos pelo OpenSSL e pelo browser.

Nós optamos por assumir que num cenário real, teríamos acesso físico às máquinas, por isso em vez 
de utilizar, por exemplo SCP ou FTP, escolhemos partilhar os ficheiros a partir da máquina host. No entanto, outra abordagem também estaria correta.

\begin{codeblock}[bash]{create\_all\_keys.sh}
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
openssl --genkey secret ta.key
\end{codeblock}

Como o CA foi criado ``\textit{in place}'', e não na sua pasta prédefinida, foi necessário utilizar 
um configuração própria para definir os ficheiros \textit{index.txt} e \textit{serial}.

\begin{codeblock}[bash]{cheese.cfg}
[ ca ]
default_ca = CA_default
[ CA_default ]
default_days = 365
database = index.txt
serial = serial
copy_extensions = copy
new_certs_dir = .
default_md = sha256
policy = policy_any
[ policy_any ]
commonName = supplied
\end{codeblock}

\subsection{Configuração geral}
Para evitar repetição e redundancia; e para garantir consistencia na elaboração do projeto criamos varios shell scripts, um destinado a cada maquina virtual.

Para configurar as VMs era preciso introduzir os mesmos comandos várias vezes, o que levava muitas vezes a erros de escrita,
ou a correr o mesmo comando várias vezes, por isso criamos vários 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 cenário 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 relógios de todas as VMs visto que elas estarem ligeiramente atrasadas nunca conseguíamos acertar na 
password do google-authenticator visto que utiliza o tempo local para calcular a sua chave.

\begin{codeblock}[bash]{VM\_CONFIG.sh}
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 sincronizacao de tempo
# se nao tiver sincronizado, o TOTP nao funciona
systemctl stop chronyd
ntpdate pool.ntp.org
systemctl start chronyd
\end{codeblock}


\section{VPN Gateway}

\subsection{Configuração da Máquina}

Como já foi dito anteriormente, cada máquina vem com um \textit{script}
que instala toda a configuração necessária.

Para que a gateway funcione como router entre a rede externa e a rede interna,
foi necessário ativar o \textit{IP forwarding} no kernel e configurar as regras
de \textit{iptables} para permitir o tráfego da VPN e realizar o mascaramento
de IP (NAT).

% NOTA(vasco): Não temos regras de DROP a packets
% talvez deviamos mudar isso nao sei <- não diz nada no enunciado ¯\_(ツ)_/¯
% também o trabalho não é sobre ip tables por isso it does make sense não fazer drop
%e utilizar as regras apenas para encaminhar corretamente.
% Colocar isso na conclusão tho

\begin{codeblock}[bash]{VM\_VPN\_GATEWAY.sh}
#!/bin/bash

# --- configuracao --- #
source VM_CONFIG.sh
yum install -y google-authenticator qrencode ntpsec

# --- forwarding --- #
if_fora="enp0s8"
ip_fora="193.136.212.1"
if_dentro="enp0s9"
ip_dentro="10.60.0.3"
mega_tunel="tun0"
ip_mega_tunel="10.8.0.0/24"

ifconfig $if_fora $ip_fora netmask 255.255.255.0
ifconfig $if_dentro $ip_dentro netmask 255.255.255.0

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf

iptables -I INPUT 1  -p udp --dport 1194 -j ACCEPT
iptables -I FORWARD 1 -i $mega_tunel -o $if_dentro -j ACCEPT
iptables -I FORWARD 1 -i $if_dentro -o $mega_tunel -j ACCEPT
iptables -I FORWARD 1 -i $mega_tunel -o $if_fora -j ACCEPT
iptables -I FORWARD 1 -i $if_fora -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s $ip_mega_tunel -o $if_fora -j MASQUERADE
iptables-save > /etc/sysconfig/iptables

# --- vpn server --- #
vpn_dir="/etc/openvpn/server"
cp ca/ta.key $vpn_dir 
cp ca/ca.crt $vpn_dir 
cp ca/vpn.key $vpn_dir 
cp ca/vpn.crt $vpn_dir 
cp ca/dh2048.pem $vpn_dir 
cp conf/vpn.conf $vpn_dir 
cp conf/ocsp-verify.sh $vpn_dir
cp conf/totp /etc/pam.d/

# --- utilizador --- #
id -u john &>/dev/null || useradd john
echo "password" | passwd --stdin john

openvpn --config /etc/openvpn/server/vpn.conf
\end{codeblock}

\subsection{Configuração do Serviço OpenVPN}


O servidor OpenVPN utiliza um certificado X.509 assinado pelo nosso \textit{Certificate Authority} (CA).
E faz uso de um script \texttt{oscp-verify.sh} para validar ou revogar os certificados através do servidor OCSP.

\begin{codeblock}{vpn.conf}
local 193.136.212.1
port 1194
proto udp
dev tun

verb 4

ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/vpn.crt
key /etc/openvpn/server/vpn.key
dh /etc/openvpn/server/dh2048.pem

topology subnet
server 10.8.0.0 255.255.255.0
push "route 10.60.0.0 255.255.255.0"

# ocsp and revocation
script-security 2
tls-verify /etc/openvpn/server/ocsp-verify.sh
# auth
cipher AES-256-GCM
auth SHA256

plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so totp
tls-auth /etc/openvpn/server/ta.key 0
\end{codeblock}

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

\begin{codeblock}{totp}
auth    required    pam_google_authenticator.so forward_pass
auth    required    pam_unix.so use_first_pass
account required    pam_unix.so
\end{codeblock}

Este script simplesmente comunica com o servidor OpenSSl
e verifica o resultado.

\begin{codeblock}{ocsp\_verify.sh}
#!/bin/bash
depth=$1
if [ "$depth" -eq 0 ]; then
    if [ -n "$tls_serial_0" ]; then
        # e preciso converter o serial para hexadecimal porque o openssl espera em hex
        hex_serial=$(printf '%x' "$tls_serial_0")
        status=$(openssl ocsp -issuer /etc/openvpn/server/ca.crt -serial "0x$hex_serial" -url http://10.60.0.1:8888 -CAfile /etc/openvpn/server/ca.crt 2>/dev/null)
        if echo "$status" | grep -q "good"; then
            exit 0 # sucesso
        fi
        exit 1 # revogado ou nao encontrado
    fi
    exit 1
fi
\end{codeblock}

\subsection{Erros}

Um dos erros que encontramos pelo caminho foi que o OpenSSL OCSP espera que o 
\textit{serial} esteja num formato diferente do que o esperado. Foi necessário
converter para hexadecimal primeiro.

Adicionalmente, devido às restrições de segurança do \textit{systemd},
tentamos desativar o \texttt{ProtectHome} no serviço do OpenVPN
para que o plugin PAM consiga ler os ficheiros de segredo do Google Authenticator
localizados nas diretorias \textit{home} dos utilizadores. Mas isto não 
foi suficiente, por isso acabamos por correr os serviços pela linha
de comandoos.

\subsection{Configurar o utilizador com TOTP}

Primeiro, na gateway, entramos como o utilizador desejado e obtemos a chave
do gerador de palavras passes temporárias. Ao inserir a chave no 
\texttt{google authenticator} podemos obter um código QR,  a nossa primeira
chave de 6 dígitos.

\begin{figure}[h]
    \centering
    \includegraphics[width=8em]{google-authenticator}
\end{figure}

\begin{codeblock}[bash]{}
su john
google-authenticator
\end{codeblock}

\section{VPN Client (Road Warrior)}

\subsection{Configuração da Máquina}
Para a configuração da Máquina, configuramos o edereço, o default gateway e adicionamos apache aos Hosts:

\begin{codeblock}{VM\_ROAD\_WARRIOR.sh}
#!/bin/bash

# --- configuracao --- #
source VM_CONFIG.sh
ifconfig enp0s8 193.136.212.10 netmask 255.255.255.0
route add default gw 193.136.212.1 

if ! grep -q "apache" /etc/hosts; then
    echo "10.60.0.1 apache" >> /etc/hosts
fi

# --- vpn client --- #
vpn_dir="/etc/openvpn/client/"
cp ca/ta.key $vpn_dir 
cp ca/ca.crt $vpn_dir 
cp ca/user.key $vpn_dir 
cp ca/user.crt $vpn_dir 
cp conf/client.conf $vpn_dir 

openvpn --config "${vpn_dir}/client.conf"
\end{codeblock}


% Esta configuração foi necessaria, porque sem edereço a VM não conseguia-se identificar na rede. Sem o default gateway
% os edereços desconhecidos seriam enviados para a porta da internet, e adicionamos apache aos Hosts para que fosse igual
% ao domain para não haver erros.
%(I dunno about this Apache part??) Also sinto que ainda precisa de mais um bocado.
Também foram movidos os certificados e chaves necessarias para as pastas do serviço openvpn, para que o Road Warrior
consiga comunicar e ser validado pela gateway.


\subsection{Configuração do Cliente OpenVPN}

O cliente encontra-se na rede externa (\texttt{193.136.212.10}) e liga-se à VPN
gateway na porta 1194. Para garantir a segurança, utilizamos autenticação mútua (os certificados X.509)
e um \textit{two factor authentication} (2FA) como palavras-passe temporárias, geradas através do
\textit{Google Authenticator}.

\begin{codeblock}{client.conf}
client
dev tun
proto udp
remote 193.136.212.1 1194
ca ca.crt
cert user.crt
key user.key
auth-user-pass
cipher AES-256-GCM
auth SHA256
\end{codeblock}

\subsection{Testes}
Para verificar que a autenticação foi corretamente implementada, inserimos a password de um utilizador sem os digitos do TOTP, e identificamos que utilizar somente a password não é suficiente para autenticar. Igualmente ao utilizar ambos a autenticação é bem sucedida. 

Para verificar que o tunel foi estabelecido, primeiro corremos na linha de comandos \texttt{ip a}. Observamos a existencia de uma nova interface tun0, ou seja o tunel foi corretamente establecido. Depois demos ping ao route e depois ao servidor interno, que resultou em pacotes devolvidos para ambos. 



% TODO: screenshots? dizer que erros exatos nos obtemos a cada etapa
% TODO: erros ortograficos lol 

Para verificar que o OCSP funciona correctamente, o cliente conectou ao servidor OpenVPN:
primeiro, sem o servidor OCSP a correr, uma segunda vez com ele a correr e com o certificado correcto
e uma terceira vez com um certificado revogado. Fizemos estes testes sabendo que o 
cliente e o servidor já estavam correctamente configurados.

Verificamos que, como é suposto: sem OCSP não é possivel autenticar; com OCSP e com certificado válido,
podemos autenticar; e com OCSP mas com certificado revogado, a autenticação falha.

\section{Servidor Apache e OCSP}
Para a configuração da ultima maquina, temos o OpenSSL e Apache no mesmo servidor, por isso temos de configurar
as pastas necessarias, os utilizadores do serviço, configurar os edereços e uma route:
\begin{codeblock}{VM\_OPENSSL\_APACHE.sh}
#!/bin/bash
# configuracao
source VM_CONFIG.sh

sudo yum install -y epel-release
sudo yum install -y openssl httpd mod_ssl mod_authnz_pam google-authenticator 
sudo yum install -y mod_session

# utilizador
id -u john &>/dev/null || useradd john
echo "password" | passwd --stdin john

if_dentro="enp0s8"
ip_dentro="10.60.0.1"
ifconfig $if_dentro $ip_dentro netmask 255.255.255.0

# route de volta para comunicar com o warrior
route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.60.0.3

cp conf/openssl.cnf /etc/pki/tls/

# copiar ca para esta VM
cp ca/index.txt $CA_DIR
cp ca/ca.crt $CA_DIR
cp ca/ca.key $CA_DIR
cp ca/serial $CA_DIR
cp ca/dh2048.pem $CA_DIR

# correr oscp
killall openssl 2>/dev/null
openssl ocsp -index $CA_DIR/index.txt -port 8888 -rsigner $CA_DIR/ca.crt -rkey $CA_DIR/ca.key -CA $CA_DIR/ca.crt -text &

# apache
mkdir -p /etc/httpd/ssl
cp ca/ca.crt /etc/httpd/ssl/
cp ca/apache.crt /etc/httpd/ssl/
cp ca/apache.key /etc/httpd/ssl/
cp conf/ssl.conf /etc/httpd/conf.d/ssl.conf
cp conf/httpd.conf /etc/httpd/conf/httpd.conf
cp conf/httpd-totp /etc/pam.d/httpd-totp

echo "LoadModule session_module modules/mod_session.so" > /etc/httpd/conf.modules.d/01-session.conf
echo "LoadModule session_cookie_module modules/mod_session_cookie.so" >> /etc/httpd/conf.modules.d/01-session.conf
echo "LoadModule auth_form_module modules/mod_auth_form.so" > /etc/httpd/conf.modules.d/01-auth_form.conf

cp -r www/* /var/www/html/
chown -R apache:apache /var/www/html/

httpd -X
\end{codeblock}

\subsection{Configuração da Máquina}

Como já referimos a Máquina tem ambos o serviço OpenSSL e Apache, por isso vai precisar de dois .conf files para
configurar-los. O httpd.conf tem as portas e modulos enquanto o ssl.conf tem a configuração da autenticação mútua, e o OCSP:
\begin{codeblock}{httpd.conf}
ServerRoot "/etc/httpd"

Include conf.modules.d/*.conf
LoadModule authnz_pam_module modules/mod_authnz_pam.so
LoadModule mpm_event_module modules/mod_mpm_event.so

User apache
Group apache

Listen 80
Listen 443

Include conf.d/*.conf

DocumentRoot "/var/www/html"
<Directory "/var/www/html">
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>
\end{codeblock}

\begin{codeblock}{ssl.conf}
<VirtualHost *:443>
    ServerName 10.60.0.1
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/httpd/ssl/apache.crt
    SSLCertificateKeyFile /etc/httpd/ssl/apache.key
    SSLCACertificateFile /etc/httpd/ssl/ca.crt

    # mutual authentication
    SSLVerifyClient require
    SSLVerifyDepth 1

    # ocsp validation
    SSLOCSPEnable on
    SSLOCSPDefaultResponder "http://10.60.0.1:8888"
    SSLOCSPOverrideResponder on
    SSLOCSPUseRequestNonce off

    # session management 
    Session On
    SessionCookieName session path=/;HttpOnly;Secure

    # proteger
    <Location "/">
        AuthType Form
        AuthName "Coimbra VPN"
        AuthFormProvider PAM
        AuthPAMService httpd-totp
        AuthFormLoginRequiredLocation "/login.html"
        Require valid-user
    </Location>

    # public login page
    <Location "/login.html">
        AuthType None
        Require all granted
    </Location>

    # login handler
    <Location "/dologin">
        SetHandler form-login-handler
        AuthType Form
        AuthName "Coimbra VPN"
        AuthFormProvider PAM
        AuthPAMService httpd-totp
        Require all granted
        AuthFormLoginSuccessLocation "/index.html"
        AuthFormLoginRequiredLocation "/login.html?error=1"
    </Location>

    # logout handler
    <Location "/logout">
        SetHandler form-logout-handler
        AuthFormLogoutLocation "/login.html?loggedout=1"
    </Location>

</VirtualHost>

# redirect para https
<VirtualHost *:80>
    ServerName 10.60.0.1
    Redirect permanent / https://10.60.0.1/
</VirtualHost>
\end{codeblock}

\subsubsection{Testes}
\begin{itemize}
    \item \textbf{Domínio:} Verificou-se que o acesso só é permitido utilizando o endereço correto, pois se for inserido outro dominio, não é direcionado para o site do Apache.
    \item \textbf{Redirecionamento HTTPS:} Ao testar quando colocamos http, e o dominio certo, era redirecionado para https.
    \item \textbf{Autenticação com o Certificado:} O acesso foi negado ao apresentar certificados inválidos ou ausentes no browser, devolvendo um erro com sobre não conseguir establecer connexão porque falta de certificado.
\end{itemize}

Para testar o OCSP, fizemos os seguintes paços:

\begin{enumerate}
    \item Estabelecer a ligação VPN e verificar a conectividade à rede interna.
    \item No diretório da autoridade de certificação (máquina \textit{host}), revogar o certificado do utilizador:
\begin{codeblock}[bash]{revoke.sh}
openssl ca -revoke user.crt -config cheese.cfg -keyfile ca.key -cert ca.crt
\end{codeblock}
    \item Atualizar o ficheiro \texttt{index.txt} no servidor OCSP e reiniciar o serviço para carregar o novo estado de revogação.
    \item Tentar estabelecer uma nova ligação VPN e verificar que a autenticação falha devido à resposta \texttt{revoked} do responder OCSP.
\end{enumerate}


\section{Teste Integrado}

Para validar, efetuámos um teste integrado englobando todos os requisitos:
\begin{enumerate}
    \item Começamos por iniciar todas as máquinas com os devidos \textit{scripts}.
    \item Na máquina \textit{Road Warrior}, iniciámos a ligação OpenVPN com o utilizador, a sua password e o \textit{token} TOTP.
    \item O \textit{Gateway} OpenVPN verifica as credenciais e verifica o certificado cliente contra o servidor OCSP.
    \item Antes de acedermos ao firefox, temos que verificar que já adicionámos a nossa a nossa CA e o certificado \texttt{p12}.
    \item Através do túnel VPN, acedemos agora ao endereço \texttt{https://apache.coimbra} no browser.
    \item O servidor Apache solicitou o certificado X.509 do utilizador e validou a sua autenticidade e estado de revogação no OCSP.
    \item Finalmente, o Apache apresentou a página de login, onde inserimos as credenciais e o código TOTP.
\end{enumerate}


\section{Conclusão}

Atingimos o objetivo deste trabalho: conseguimos configurar o túnel VPN,
o \textit{two-factor authentication} em múltiplos serviços, e conseguimos gerir o ciclo de vida dos
certificados emitidos através de uma CA própria e OCSP. Utilizar mais máquinas para simular um cenário
maior seria redundante e apenas exigiria a emissão de mais certificados, não acrescentando muito ao nível de aprendizagem. 

Aplicando conhecimentos de trabalhos anteriores,
poderíamos aplicar políticas mais restritas nas \textit{iptables} (ex: regras de DROP aos pacotes indesejados),
e implementar ferramentas como o Suricata para identificar possíveis anomalias e ataques aos serviços.

\end{document}
