\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 cenario real, teriamos acesso fisico ás maquinas, por isso em vez de utilizar, por exemplo SCP ou FTP, escolhemos partilhar os ficheiros a partir da maquina host. No entanto outra abordagem também estaria correta. %John LIMBUS HIMSELF \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" Options Indexes FollowSymLinks AllowOverride None Require all granted \end{codeblock} \begin{codeblock}{ssl.conf} 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 AuthType Form AuthName "Coimbra VPN" AuthFormProvider PAM AuthPAMService httpd-totp AuthFormLoginRequiredLocation "/login.html" Require valid-user # public login page AuthType None Require all granted # login handler 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" # logout handler SetHandler form-logout-handler AuthFormLogoutLocation "/login.html?loggedout=1" # redirect para https ServerName 10.60.0.1 Redirect permanent / https://10.60.0.1/ \end{codeblock} \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} \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} \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 %Preciso de ver isso 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}