\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 intera,
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 CN
que precisam de ser passados mais tarde para aceder ao Apache e ao gateway.
Numa situação normal teríamos uma autoridade de certificação para enviar e
no fundo gerir todos, mas para este cenário podemos inicializar as máquinas
com as chaves, requests e certificados necessários.

\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 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/
systemctl enable --now openvpn-server@vpn.service
\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
# fonte: https://github.com/OpenVPN/openvpn/blob/master/contrib/OCSP_check/OCSP_check.sh

ocsp_url="http://10.60.0.1:8888"
issuer="/etc/openvpn/server/ca.crt"
nonce="-no_nonce"
verify="/etc/openvpn/server/ca.crt"
check_depth=0

cur_depth=$1
common_name=$2

if [ -z "$issuer" ] || [ ! -e "$issuer" ] || [ -z "$verify" ] || [ ! -e "$verify" ] || [ -z "$ocsp_url" ]; then
  exit 1
fi

if [ $check_depth -eq -1 ] || [ $cur_depth -eq $check_depth ]; then
  eval serial="\$tls_serial_${cur_depth}"

  if [ -n "$serial" ]; then
    status=$(openssl ocsp -issuer "$issuer" "$nonce" -CAfile "$verify" -url "$ocsp_url" -serial "${serial}" 2>&1)

    if [ $? -eq 0 ]; then
      if echo "$status" | grep -Eq "(error|fail)"; then
          exit 1
      fi
      
      if echo "$status" | grep -Eq "^${serial}: good" && echo "$status" | grep -Eq "^Response verify OK"; then
        exit 0
      fi
    fi
  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},
foi necessário 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.

\begin{codeblock}{override.conf}
[Service]
ProtectHome=false
\end{codeblock}

\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}
ads

\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}

% 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}

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

asd

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

O servidor interno (\texttt{10.60.0.1}) alberga o serviço Apache e o responder OCSP
da autoridade de certificação.

\subsubsection{Testes}

1. verificar que é necessário o dominio,

1. verificar que é necessário o https,

1. verificar que é necessário o certificado,


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

\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}

\subsubsection{Testes}

Podemos validar que o OCSP

1. verificar que recebe os certificados e responde

1. verificar que revocation funciona


\section{Teste Integrado}

verificamos coisas

\section{Conclusão}

% 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. Se fossemos aplicar o que fizemos no trabalho anterior
podiamos dar DROP aos pacotes que não nos interessa nesta cenario,
e implementar suricata para identificar possiveis ataques nos serviços.

%È estranho que para uma cadeira de cybersegurança nós implementamos
%pouca you know segurança.

% Para aprofundar (???) yeah

\end{document}