merge

relatorio/relatorio.tex

@@ -38,18 +38,27 @@
 
 \section{Introdução}
 
-Este projecto tem como âmbito implementar uma rede virtual privada (VPN) em um cenário de road-warrior,
-ou seja, onde o administrador de acesso da rede é o cliente ou tem acesso a ele.
+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.
 
-Para tal, foi implementado um servidor e um cliente OpenVPN, certificados por uma autoridade 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 \textit{google-authenticator} para o OpenVPN.
+% NOTE(vasco): Eu acho que basta explicar o cenario e explicar como decidimos 
+% implementar 
 
-Existe ainda um servidor Apache e um servidor de OpenSSL OCSP. Para simplificar, a elaboração do 
-projecto foram colocados na mesma maquina virtual, mas por razoes de seguranca poderia querer ter 
-estes serviços separados. 
+% 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.
 
-Temos então três máquinas virtuais:
+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}
 
@@ -59,15 +68,19 @@ Temos então três máquinas virtuais:
    OpenSSL / Apache & VM\_OPENSSL\_APACHE.sh & Rede Interna 10.60.0.0/24 \\
 \end{tabular}
 
-
-
 \section{Criação de certificados}
 
-Criar chaves com 2048 bits.
+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.
 
-Todos os certificados são criados de uma so vez e são depois copiados para as respetivas
-máquinas virtuais.
+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.
 
+O código para gerar os certificados X.509: 
 
 \begin{lstlisting}[language=bash]
 cert_ca="/C=PT/ST=Coimbra/L=Coimbra/O=UC/CN=CoimbraVPN"
@@ -90,6 +103,41 @@ openssl req -new -key apache.key -out apache.csr -subj "$cert_apache" -addext "s
 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 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 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 sincronizacao 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}
 
 \subsection{Configurar TOTP}
@@ -112,13 +160,13 @@ ProtectHome=false
 \end{lstlisting}
 
 Primeiro, na gateway, entramos como o utilizador desejado e obtemos a chave
-do gerador de palavras passes temporarias. Ao inserir a chave no 
+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 digitos.
+chave de 6 dígitos.
 
 \begin{figure}[h]
     \centering
-    \includegraphics{google-authenticator}
+    \includegraphics[width=8em]{google-authenticator}
 \end{figure}
 
 \begin{lstlisting}[language=bash]
@@ -151,9 +199,9 @@ iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o enp0s8 -j MASQUERADE
 \section{Configuração do Cliente (Road Warrior)}
 
 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, utiliza-mos autenticação mútua (os certificados X.509)
-e um \textit{two factor authentication} (2FA) como palavras-passe temporarias, geradas através do
- \textit{Google Authenticator}.
+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{lstlisting}[language=bash]
 client
@@ -175,7 +223,6 @@ da autoridade de certificação.
 
 \subsection{Revocation e OCSP}
 
-
 \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:
@@ -187,13 +234,15 @@ openssl ca -revoke user.crt -config cheese.cfg -keyfile ca.key -cert ca.crt
 \end{enumerate}
 
 
-
 \section{Conclusão}
 
-A implementação deste projeto permitiu consolidar conhecimentos sobre redes privadas virtuais e segurança em comunicações.
- A combinação de certificados digitais com autenticação de dois fatores (TOTP) garante uma robustez significativa contra
-  ataques de interceção e roubo de credenciais. 
-  
-  A integração do protocolo OCSP permite uma gestão dinâmica da confiança, possibilitando a revogação imediata de acesso a clientes comprometidos sem necessidade de redistribuição de listas de revogação (CRLs) volumosas. Em suma, o sistema cumpre os requisitos de confidencialidade, integridade e disponibilidade propostos.
+% 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}