423 lines
14 KiB
TeX
423 lines
14 KiB
TeX
\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
|
|
depth=$1
|
|
env >> /etc/openvpn/server/ocsp_env.log
|
|
if [ "$depth" -eq 0 ]; then
|
|
echo "Checking OCSP for serial=$tls_serial_0" >> /etc/openvpn/server/ocsp.log
|
|
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>>/etc/openvpn/server/ocsp.log)
|
|
echo "OCSP Status: $status" >> /etc/openvpn/server/ocsp.log
|
|
|
|
if echo "$status" | grep -q "revoked"; then
|
|
echo "Result: REVOKED" >> /etc/openvpn/server/ocsp.log
|
|
exit 1
|
|
fi
|
|
|
|
if echo "$status" | grep -q "good"; then
|
|
echo "Result: GOOD" >> /etc/openvpn/server/ocsp.log
|
|
exit 0
|
|
fi
|
|
|
|
echo "Result: UNKNOWN/ERROR" >> /etc/openvpn/server/ocsp.log
|
|
exit 1
|
|
else
|
|
echo "tls_serial_0 is empty!" >> /etc/openvpn/server/ocsp.log
|
|
exit 1
|
|
fi
|
|
fi
|
|
|
|
echo "ERROR: depth > 0" >> /etc/openvpn/server/ocsp.log
|
|
|
|
exit 0
|
|
\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}
|