View
213
Download
0
Category
Preview:
Citation preview
Trabalho elaborado por: Ricardo Nuno Mendão da Silva rnsilva@student.dei.uc.pt Jorge Miguel Morgado Henriques jmmh@student.dei.uc.pt
ContentsContents ........................................................................................................................................ 2
1. Introdução............................................................................................................................. 4
2. Objectivos.............................................................................................................................. 5
3. Activação da CA privada........................................................................................................ 5
3.1. Criação da chave de encriptação .................................................................................. 5
3.2. Criação do Certificate Signing Request (CSR) ............................................................... 6
3.3. Criação do Certificado “self signed”.............................................................................. 6
4. Obtenção de certificados x509.............................................................................................. 7
4.1. Criação da chave de encriptação .................................................................................. 8
4.2. Criação do Certificate Signing Request (CSR) ............................................................... 9
4.3. Criação do Certificado ................................................................................................... 9
5. Ficheiros de configuração ................................................................................................... 10
5.1. openssl.conf ................................................................................................................ 10
5.2. httpd.conf.................................................................................................................... 12
5.3. ssl.conf......................................................................................................................... 13
6. Testes .................................................................................................................................. 17
6.1. Área ssc05.dei.uc.pt .................................................................................................... 17
1.1.1. 6.1.1. Acesso válido. ............................................................................................ 17
6.1.2. Acesso de cliente sem autorização ou fora de tempo ........................................ 19
6.1.3. Acesso sem certificado.............................................................................................. 22
6.2. Área sec05.dei.uc.pt.................................................................................................... 23
6.2.1. Acesso com certificado emitido pela CA privada ................................................ 23
6.3. Área intra05.dei.uc.pt ................................................................................................. 26
6.3.1. Acesso a partir da rede 10.254.0.0/24 ................................................................ 26
6.3.2. Acesso com login e password.............................................................................. 26
6.4. Acesso com certificado revogado ............................................................................... 28
7. Funcionalidades não implementadas ................................................................................. 30
8. Conclusão ............................................................................................................................ 31
9. Bibliografia .......................................................................................................................... 32
1. Introdução
Com o desenvolvimento dos meios de comunicação, observa‐se uma convergência do uso destes, por parte de vários sectores sócio‐económicos, exigindo cada vez mais a garantia de um bom serviço, ou seja, fiável, eficaz e sobretudo seguro, permitindo que o utilizador final possa efectuar operações delicadas, por exemplo transacções financeiras, sem que corra o risco dessas transacções serem interceptadas por terceiros, tendo ainda a garantia de que está a efectuar a transacção com a entidade pretendida. Assim, foi desenvolvido o protocolo criptográfico SSL (Secure Sockets Layer) que permite garantir a privacidade e integridade dos dados, trocados entre duas entidades. Normalmente o ssl penas utiliza certificação do lado do servidor , garantindo assim ao utilizador que está ligado à entidade correcta, contudo pode também utilizar autenticação do lado do utilizador, fazendo com que este necessite de um certificado de autenticação, que pode ser fornecido por uma Autoridade de certificação conhecida, ou por uma Autoridade privada. Para a criação de uma Autoridade de certificados privada, pode ser usado o OpenSSL que é basicamente uma ferramenta de implementação do protocolo SSL. Com o OpenSSL é possível criar um certificado x509 self signed , criando então a Autoridade de Certificação privada, que pode funcionar como as Autoridades de Certificação oficiais, permitindo criar certificados para os utilizadores. O x509 é um standard que especifica vários padrões dos vários componentes intervenientes na comunicação segura, como por exemplo o formato das chaves e algoritmos. A Autoridade de Certificação para além de criar os certificados, pode também suspende‐los, ou seja, torna‐los inválidos antes do seu prazo de validade terminar.
Todo o processo de acesso seguro, corre obviamente sobre um servidor web comum, como por exemplo o apache. Para implementar as funcionalidades de segurança requeridas, o apache possuí um módulo chamado, mod_ssl , que permite efectuar as mais variadas configurações de restrição e requerimento de certificados para com os utilizadores, implementando assim o sistema de acesso remoto via ssl, neste caso através do protocolo https. Para além deste sistema de segurança através do mod_ssl o apache permite um outro modo de segurança, nomeadamente através da autenticação dos utilizadores através de um sistema de username e password, implementado pelo mod_auth, sendo claramente bastante inferior em segurança e flexibilidade quando comparado com o SSL.
Neste relatório irá constar um longo processo de descrição e testes das operações efectuadas para a criação de Autoridades de Certificação privadas, para a criação de certificados a utilizadores comuns e para a configuração de servidores de acesso seguro, com as mais variadas restrições.
2. Objectivos
Pretende‐se neste trabalho utilizar o OpenSSL para activação de uma Autoridade de Certificação privada, para posteriormente criar certificados e listas de revogação de certificados. Pretende‐se ainda que seja efectuada a configuração do apache para autenticação e autorização de acessos a zonas de documentos, segundo vários critérios de segurança.
3. Activação da CA privada
Neste ponto irão ser descritos os passos necessários para a criação de uma Autoridade de Certificação privada, sendo especificado cada parâmetro utilizado por comando. Cada um dos pontos seguintes, corresponde a um passo para a criação do certificado da Autoridade de Certificação.
Figura 1 – Criação de CA privada
3.1. Criação da chave de encriptação
Neste ponto irá ser descrito o comando utilizado para gerar a chave encriptada. Ver
Comando Openssl genrsa –out private/ca.key 1024
genrsa Define o tipo de algoritmo de encriptação para o
algoritmo RSA, desenvolvido por professores do MIT, nomeadamente Ron Rivest, Adi Shamir e Len Adleman.
‐out private/ca.key Define o ficheiro resultante e guarda‐o na directoria referida, neste caso na pasta “private”.
Parâmetros
1024 Número de bits de encriptação que compõem a chave.
3.2. Criação do Certificate Signing Request (CSR)
O CSR é um ficheiro que contém informação da entidade que solicita o certificado. Neste caso a própria “futura” Autoridade privada. Contém ainda a chave pública e informação do servidor onde está instalado. Não é mais que um certificado desencriptado.
3.3. Criação do Certificado “self signed”
Por fim, já com o CSR criado, basta encriptar este com a chave da própria entidade que o “pediu”, sendo a origem do termo “self signed”.
Comando openssl x509 -req -days 365 -in ca.csr -out certs/SSC\ CA.crt -signkey private/ca.key
Parâmetros X509 É um comando que permite mostrar, converter,
editar ou assinar certificados, sendo este último, o propósito da sua utilização neste caso.
Comando Openssl req –new –key private/ca.key –out ca.csr Parâmetros req Utilizado para processos de gestão do CSR. ‐new Flag que identifica o comando como criação de um
novo item. ‐key
private/ca.key Indica a chave da entidade que solicita o certificado.
‐out ca.csr Indica onde ficará o ficheiro resultante deste comando.
-req Opção que indica a entrada de um CSR, em vez da opção por defeito do x509 que é um certificado.
-days 365 Indica a validade do certificado. -in ca.csr Indica o CSR a encriptar. -out certs/SSC\ CA.crt
Indica qual o destino e o nome do ficheiro resultante da execução deste comando.
-signkey private/ca.key
Indica a chave que irá encriptar o CSR inserido na opção –in.
4. Obtenção de certificados x509
Neste ponto irá ser especificado como se processa a obtenção de certificados com o padrão x509 emitidos pela Autoridade de Certificação criada no ponto 3. Este processo pode ser comprovado imagem seguinte.
Figura 2 – Emissão de certificado para cliente
Neste trabalho gerou‐se uma chave rsa de 1024 bits para cada certificado emitido. O processo efectuado foi o mesmo que o descrito no ponto 3.1.. Emitiram‐se 4 certificados x509 baseados na referida CA, sendo que 3 foram atribuídos às três áreas de documentos pedidas, nomeadamente https://sec05.dei.uc.pt https://ssc05.dei.uc.pt e https://intra05.dei.uc.pt . O quarto certificado foi atribuído a um utilizador de teste.
Os sub‐pontos que se seguem foram idênticos para os 4 certificados emitidos, variando apenas os nomes dos ficheiros resultantes, entre sec05, ssc05 e intra05 respectivamente.
4.1. Criação da chave de encriptação
Comando Openssl genrsa –out private/sec05.key 1024 Parâmetros genrsa Define o tipo de algoritmo de encriptação para o
algoritmo RSA, desenvolvido por professores do MIT, nomeadamente Ron Rivest, Adi Shamir e Len Adleman.
‐out private/sec05.key
Define o ficheiro resultante e guarda‐o na directoria referida, neste caso na pasta “private”.
1024 Número de bits de encriptação que compõem a chave.
4.2. Criação do Certificate Signing Request (CSR)
Neste caso o CSR contém a informação da entidade “sec05”, sendo que no campo “Common Name” terá de ser introduzido o nome completo da área (FQDN), ou seja, sec05.dei.uc.pt. no caso do CN ser diferente do nome da área, um qualquer utilizador quando aceder a essa área irá receber uma mensagem de notificação, indicando possível tentativa de passagem por falsa identidade.
4.3. Criação do Certificado
Por fim, com o CSR criado, este terá de ser encriptado por uma Autoridade de Certificação, que neste caso é a “SSC CA” criada no ponto 3.
Comando openssl ca -in sec05.csr -cert certs/SSC\ CA.crt -keyfile private/ca.key -out newcerts/sec05.crt
ca Comando para assinar p, gerar
CRL (Listas de Certificados revogados ) e para manter uma base de dados sobre os certificados gerados.
-in sec05.csr Indica o CSR a encriptar. -certs certs/SSC\ CA.crt
Indica a Autoridade de Certificação que vai assinar o CSR.
Parâmetros
-keyfile private/ca.key
Indica a chave da CA privada.
Comando Openssl req –new –key private/sec05.key –out sec05.csr Parâmetros req Comando que cria e processa certificados no
formato PKCS#10. ‐new Flag que identifica o comando como criação de um
novo item. ‐key
private/sec05.keyIndica a chave da entidade que solicita o certificado.
‐out sec05.csr Indica onde ficará o ficheiro resultante deste comando.
-out newcerts/sec05.crt
Indica o ficheiro resultante de todo este processo, nomeadamente o requerido certificado.
5. Ficheiros de configuração
5.1. openssl.conf
No ficheiro openssl.conf, situado na directoria /etc/pki/tls, foi criada uma área à qual se chamou CA_modded. Esta nova área é igual à área por defeito, no que respeita a opções, contudo difere da mesma no aspecto dos directórios, apontando para os directórios utilizados nos testes, como se pode observar na figura 3.
Figura 3 – Excerto do openssl.conf
Ao modificar o parâmetro “dir” para /root/ssc, todos os ficheiros seguintes tomam este caminho como raíz. Na tabela seguinte irão ser explicados as entradas presentes na figura 3, que podem causar mais dúvidas.
certs Directório onde se encontra a CA
Crl_dir Directório onde se encontram os ficheiros correspondentes às listas de certificados revogados pela CA.
database Index.txt é o ficheiro que vai sendo actualizado contendo informação de todos os certificados criados e revogados pela CA.
Dentro da secção [req], procedeu‐se à alteração da sub‐secção [req_distinguished_name], onde se alteraram os valores por defeito, para os valores apresentados na figura 4, por forma a tornar mais fácil o preenchimento dos requisitos requeridos na criação de um novo CSR.
Figura 4 – Excerto [req] do ficheiro openssl.conf
Para além das duas secções referidas, este ficheiro não sofreu mais alterações, quando comparado com o original.
5.2. httpd.conf
No ficheiro de configuração do apache. httpd.conf, apenas foram adicionados VirtualHosts na secção 3, como se pode ver na figura 5.
Figura 5 – Secção 3 do ficheiro httpd.conf
Todos os VirtualHost são ipbased e todos escutam no mesmo porto, obrigando a existência de um NameVirtualHosts para evitar que o acesso a qualquer destino alojado neste servidor, seja redireccionado sempre para o primeiro VirtualHosts. Os três VirtualHosts definidos têm a estrutura idêntica e o objectivo das suas presenças neste ficheiro de configuração é apenas para que no caso do cliente aceder a qualquer uma destas áreas via http, seja redireccionado dentro da mesma área, para https. Assim, para cada área definiu‐se um VirtualHost com:
• Raíz da área.
• Nome completo da área.
• Ficheiro de registo de erros, definição de nível de alarme e tipo de registo.
• Zona de configuração referente à raíz da área com:
Comando de ligação do modo Rewrite
Opção para permitir seguir links.
Regra que permite efectuar o redireccionamento para a zona segura, acompanhada pela flag ‘R’, que força o redireccionamento e pela flag ‘L’, que aplicada a seguir à ‘R’ funciona como um travão parando qualquer comando de reescrita.
Como se pode observar na figura 5, no endereço https é indicado o porto, sendo que para aplicar o mod_ssl no apache, os VirtualHosts correspondentes têm de ser ipbased, logo esses VirtualHosts utilizados para ligações https, precisam de ser configurados em portos diferentes, pois caso contrário irão todos carregar o certificado do primeiro VirtualHost, sendo que esta solução é completamente transparente ao cliente.
No ficheiro ssl.conf irá ser apresentado o resultado deste redireccionamento.
5.3. ssl.conf
O ficheiro ssl.conf, ou seja, o ficheiro de configuração correspondente ao módulo que permite implementar o protocolo SSL no apache, não sofreu nenhuma alteração de base, sendo que apenas lhe foram adicionados VirtualHosts, para tratar os redireccionamentos efectuados pela configuração do ficheiro httpd.conf, ou os pedidos directos em https. Para cada VirtualHost foi configurado as restrições de acesso à respectiva área e adicionados os Listener aos novos portos, nomeadamente o porto 444 e 445. O porto 443 já estava adicionado, visto ser o porto utilizado por defeito nas ligações https. Na figura em baixo pode‐se observar a primeira alteração, correspondente aos virtualhosts.
Em cada virtualHost apresentado, pode‐se começar por verificar as primeiras entradas que são semelhantes às apresentadas no ficheiro httpd.conf, mudando, respectivamente, apenas a directoria e os nome dos ficheiros de log. Mais abaixo, entram as novidades, ou seja, a indicação de que aquele virtualhost utiliza uma ligação SSL, o tipo de cifras que suporta, o caminho do certificado emitido para aquele virtualhosts, a sua chave e o caminho para o ficheiro que contém a lista actualizada de certificados revogados. De notar que neste ponto confirma‐se a existência de um certificado para cada área, devidamente acessível com base na utilização de portos diferentes, tal como se irá comprovar nos testes efectuados no ponto 6 deste relatório.
Na figura que se segue, pode‐se observar a segunda adicção de comandos ao ficheiro ssl.conf, de forma a garantir a restrições requeridas para a área definida por cada virtualhost.
Figura 7 – Configuração para as restrições dos directórios, ficheiro ssl.conf
Como se pode observar, as condições de acesso são aplicadas directamente á directoria.
Na directoria da área sec05.dei.uc.pt utiliza‐se o comando “SSLVerifyClient require” para indicar que o cliente é obrigado a possuir um certificado para aceder à área, sendo este comando completado pelo seguinte, “SSLVerifyDepth 1”, que ao ter o nível 1, indica que esse certificado ou é o certificado self signed da CA, ou é um certificado directamente emitido por esta. No comando “SSLOptions”, a entrada +StrictRequire reforça a impossibilidade de acesso em caso de falha de validação.
Para a área ssc05.dei.uc.pt, utilizou‐se a mesma restrição que na área anterior, adicionando‐lhe ainda um filtro maior, através do comando “SSLRequire”. Neste comando, são adicionadas opções de restrição, utilizando um linguagem complexa resultante da mistura de Perl com C, garantindo o acesso apenas a clientes, cujo Common Name tivesse sido inserido manualmente pelo administrador do servidor, sendo que no caso demonstrado, apenas existe um utilizador com permissão, o utilizador “rnsilva”. O acesso é ainda restringido no tempo, através das variáveis TIME_WDAY e TIME_HOUR, que ainda dentro do comando SSLRequire, limitam o acesso aos dias úteis, das 8 às 17horas.
Por fim a última área, correspondente à área intra05.dei.uc.pt, que apenas permite o acesso sem qualquer tipo de autenticação a clientes residentes na rede 10.254.0.0/24, através do uso de comando específicos do mod_access, o order, o deny e o allow. Assim, obriga que os clientes de outras redes forneçam, pelo menos dados de autenticação válidos, login e password. Esta validação de login e password é o sistema de autenticação básico do apache,
implantado pelo mod_auth que fornece neste caso, os comandos AuthType (define o tipo de autenticação [basic|digest]), AuthName (Define a mensagem da janela de login), AuthUserFile (Define o ficheiro que contém os logins válidos) e Require (Define o tipo de validação, se por utilizador especifico, se por grupo ou se por qualquer individuo autenticado com êxito).
O comando “Satisfy any” é o responsável por esta flexibilidade entre o mod_access e o mod_auth, permitindo o acesso à área apenas com o sucesso de uma das condições. No caso do cliente possuir um certificado, também o pode utilizar opcionalmente para autenticação, sendo que neste caso deveria prescindir da autenticação via login o que não acontece, sendo este caso fundamentado nos pontos 6 e 7 deste relatório.
6. Testes
6.1. Área ssc05.dei.uc.pt
1.1.1. 6.1.1. Acesso válido. Neste ponto, vai‐se demonstrar o processamento de um acesso válido à área ssc05.dei.uc.pt.
O utilizador rnsilva possuí um certificado gerado pela CA e adicionou‐o ao seu browser, como se pode ver na figura 8.
Figura 8 – Certificado do cliente
Ao inserir o endereço no browser e clicar no ENTER,
Figura 9 – Inserção do endereço.
o cliente recebe uma janela de notificação, a questionar sobre a aceitação de ligação a uma área segura, cujo certificado foi emitido por uma CA desconhecida, como se pode observar na figura 10.
Figura 10 – Notificação de certificado emitido por autoridade desconhecida.
Ao clicar em OK o servidor vai efectuar o pedido do certificado do cliente rnsilva, resultante do comando SSLVerifyClient require. Caso o utilizador tenha o browser configurado para emitir o
seu certificado automaticamente, este processo ser‐lhe‐á transparente, caso contrário aparecerá a seguinte janela:
Figura 11 – Janela de solicitação de certificado.
Nesta janela o cliente poderá escolher o certificado a enviar.
Como o acesso foi efectuado pelo cliente rnsilva, que foi adicionado pelo administrador á lista dos utilizadores com acesso, com demonstrado na figura x e ainda, ocorreu a uma sexta‐feira às 16:22 da tarde, o cliente tem pleno acesso à área ssc05.dei.uc.pt.
Figura 12 – Excerto do ficheiro ssl.conf
6.1.2. Acesso de cliente sem autorização ou fora de tempo
Neste ponto vai‐se mostrar a tentativa de acesso de um cliente, que mesmo com certificado válido, não acede à área, pois o seu nome não consta da lista gerida pelo administrador. Para efectuar este teste, alterou‐se a lista de utilizadores autorizados e efectuou‐se o acesso à área. Na figura em baixo pode‐se observar a alteração efectuada.
Figura 13 ‐ Excerto do ficheiro ssl.conf modificado para teste
Como o utilizador “rnsilva” não consta da lista, logo não terá acesso à área, resultando no log de erros do servidor, a seguinte mensagem.
Esta mensagem refere que falhou uma condição requerida pelo comando SSLRequire, acontecendo o mesmo quando o utilizador, mesmo que autorizado pelo administrador e com certificado, tente aceder fora de horas ou fora dos dias úteis. Uma parte dessa condição é também demonstrada na figura de cima, visto que para conseguir efectuar um teste no dia corrente, foi necessário alterar o valor de “TIME_WDAY” de 5 para 6, englobando para além dos dias úteis, o sábado.
Mantendo o sábado como dia válido, alterou‐se a hora final, em “TIME_HOUR” de 17 para 12, e voltou‐se a adicionar o utilizador rnsilva à lista de permissões, como demonstra na figura em baixo.
Figura 14 ‐ Excerto do ficheiro ssl.conf modificado para teste
Ora, deste modo e visto que o teste decorre precisamente às 13:52, o acesso foi bloqueado e nova mensagem adicionada no ficheiro de log, demonstrado na figura seguinte.
Figura 15 – Ficheiro de log de erros da área ssc05
Por fim repuseram‐se os valores correctos,definidos pelo enunciado, e tentou‐se efectuar o acesso ao sábado, que falhando, levou novamente à análise do ficheiro de log de erros, onde mais uma vez foi adicionada uma linha de erro relativamente à falta de um requerimento do SSL.
Figura 16 ‐ Ficheiro de log de erros da área ssc05
De notar, que estes testes foram efectuados todos no mesmo dia e pela mesma altura, o que levou a realizar uma situação inversa de teste, ou seja, a alteração dos ficheiros de configuração, para garantir o funcionamento das restrições, nele inseridas. Com a ajuda dos ficheiros de log, é possível observar as datas precisas do teste.
6.1.3. Acesso sem certificado
O cliente introduz o endereço da área no seu browser e ao tentar aceder à área sem o certificado, o acesso é negado, ficando registado no log de erros a seguinte entrada.
Figura 18 ‐ Ficheiro de log de erros da área ssc05
O erro apresentado na imagem em cima, é igual para a tentativa de acesso a qualquer das áreas apresentadas neste relatório, que obrigam a que o cliente apresente um certificado emitido pela CA privada e este não o possuí.
6.2. Área sec05.dei.uc.pt
6.2.1. Acesso com certificado emitido pela CA privada
O utilizador rnsilva possuí um certificado gerado pela CA e adicionou‐o ao seu browser, como se pode ver na figura 19.
Figura 19 – Certificado do cliente.
Ao inserir o endereço no browser e clicar no ENTER, o cliente recebe uma janela de notificação, a questionar sobre a aceitação de ligação a uma área segura, cujo certificado foi emitido por uma CA desconhecida, como se pode observar na figura 20.
Figura 20 – Notificação de certificado desconhecido.
Ao clicar em OK o servidor vai efectuar o pedido do certificado do cliente rnsilva, resultante do comando SSLVerifyClient require. Caso o utilizador tenha o browser configurado para emitir o seu certificado automaticamente, este processo ser‐lhe‐á transparente, caso contrário aparecerá a seguinte janela:
Figura 21 – Janela de selecção de certificado do lado do cliente.
Nesta janela o cliente poderá escolher o certificado a enviar.
Ao clicar em OK terá acesso à área, pois o seu certificado foi directamente emitido pela CA privada.
Figura 17 – Página segura da área sec05
6.3. Área intra05.dei.uc.pt
6.3.1. Acesso a partir da rede 10.254.0.0/24
Com a tentativa de acesso a partir da rede 10.254.0.0/24, o cliente não necessita de qualquer tipo de autenticação, nem de certificado, sendo directamente redireccionado para a área segura. O código apresentado na figura em baixo é o responsável por essa acção.
Figura 22 – Página da zona segura de intra05.
6.3.2. Acesso com login e password
Quando o utilizador não se encontra na 10.254.0.0/24 e não apresenta certifcado, é lhe apresentada uma janela, para que este insira os seus dados de login, dados esses previamente adicionados pelo administrador , a um ficheiro especifico com o comando
htpasswd ‐c /var/www/passwd/passwords rnsilva ou
htpasswd /var/www/passwd/passwords rnsilva, caso o ficheiro já tenha sido criado.
Figura 23 – Ip fora da rede 10.254.0.0 e pedido de autenticação.
Ao introduzir as suas credenciais válidas, o utilizador tem então acesso à área.
Figura 24 – Entrada na zona segura de intra05 com sucesso.
Caso o utilizador insira as credenciais erradas, a janela de pedido dessas credenciais, teima sempre em voltar a aparecer, sendo a única opção do cliente que não tem credenciais, cancelar essa janela, aparecendo‐lhe a seguinte mensagem.
Figura 25 – Autorização negada a utilizador inválido.
Acompanhado com essa mensagem, fica registado no log de erro, o erro 401 que significa que existiu uma tentativa de acesso não autorizada, a uma zona que o exigia.
6.4. Acesso com certificado revogado
Para além de todas as restrições especificas por cada área, o servidor configurado, também verifica se os certificados que os clientes estão a tentar utilizar para aceder a cada área, não se encontram revogados. Para revogar um certificado o administrador utiliza os comandos demonstrados na figura seguinte:
Figura 26 – exemplo e comprovação da acção de revogação de um certificado.
Na figura, está demonstrado a verde o comando de revogação do certificado rnsilva.crt, a amarelo está o comando que gera o ficheiro com a lista dos certificados revogados e a vermelho o contéudo desse ficheiro.
Como na configuração do ficheiro ssl.conf, foi adicionada a linha :
SSLCARevocationFile /root/ssc/crl/upd1.crl, que faz com que o servidor quando recebe um certificado, verifica se este está na lista dos certificados revogados.
Como cenário de teste revogou‐se o certificado do utilizador rnsilva, sendo que quando este tentou aceder, posteriormente, à área sec05.dei.uc.pt (que apenas requer em certificado válido), esse acesso é negado e fica registado no log uma mensagem, como demonstra a seguinte figura.
Figura 27 – ficheiro log da área sec05.dei.uc.pt
7. Funcionalidades não implementadas
No desenvolvimento de trabalho ficaram três pontos por afinar, nomeadamente:
Revogações detectadas por directório e não por ficheiro.
Lista de clientes com acesso à ssc05.dei.uc.pt contida num ficheiro específico, em vez de ser inserido manualmente no ficheiro de configuração.
No acesso à área intra05.dei.uc.pt mesmo que o utilizador apresente certificado , terá sempre que inserir as credenciais de acesso.
Ora, em relação ao primeiro ponto, todo o processo estudado para implementar o sistema de analise das revogações através da directoria foi implementado, quando algum detalhe deverá estar a faltar, pois o sistema não funciona. Os passos seguidos foram:
• Criar o directório e colocar lá os ficheiros *.crl criados.
• Efectuar o link simbólico para cada um através do comando:
ln ‐s upd1.crl `openssl crl ‐hash ‐noout ‐in upd1.crl`.r0
ou com o makefile fornecido juntamente com o mod_ssl.
• Inserir o comando SSLCARevocationPath /root/ssc/crl/ no ficheiro de configuração.
No segundo ponto, tentou‐se efectuar a inserção dos utilizadores válidos num ficheiro, através de dois modos. Um utilizando a função file(“path”), definido na documentação do mod_ssl para o comando SSLRequire e o outro utilizando uma interacção com o mod_auth
tentando criar um sistema de autenticação apenas com o username. Contudo nenhuma destas tentativas se tornou solução, sendo que optou‐se por utilizar a solução implementada, que para o contexto de teste é viável, ao contrário de casos reais em que a lista de acessos permitidos seja de larga escala. Com certeza que existirá uma solução bem viável, mas que no contexto da realização deste trabalho, não foi encontrada.
No terceiro ponto, em que definido pelo enunciado, o acesso à zona intra05.dei.uc.pt, para utilizadores fora da rede 10.254.0.0/24, seria permitido consoante uma de duas hipóteses, a apresentação de um certificado válido ou a introdução de credenciais, username e password, caso não existi‐se um certificado válido. É entre estas duas hipóteses que o sistema implementado falha, pois nos testes realizados, mesmo que o utilizador apresente um certificado válido, o sistema pede‐lhe sempre as credenciais de login. Uma solução teoricamente possível seria a utilização do comando “Satify any” que tão bem funciona entre o mod_access e o mod_auth, mas que com o mod_ssl não mantém o mesmo nível. Deverá contudo existir uma condição que permita evitar que o cliente seja obrigado a inserir as credenciais, quando já emitiu um certificado válido.
8. Conclusão
Este trabalho consistia na emissão de certificados e configuração de servidores apache para acesso seguro, utilizando o mod_ssl. É uma área importante que actualmente permite restringir o acesso e possibilitar acções de grande importância, sobre uma rede aberta, como a internet.
Ao realizar este trabalho, o grupo, adquiriu variados conceitos dentro desta área e tomou noção e contacto com a configuração completamente manual que estes sistemas exigem. Deparou‐se também como uma vasta documentação, do apache e dos vários módulos, contudo existem pontos específicos pouco fundamentados e com poucos “How to’s”, como no caso do comando SSLRequire, que segundo a documentação parece ter enorme potencial, mas que com a sua difícil linguagem de configuração requer um conhecimento algo profundo e alguma prática, para dele retirar todo o proveito.
Assim, dá‐se por concluído este trabalho e fica‐se com o conhecimento destas ferramentas, ficando a base para uma futura evolução neste campo.
9. Bibliografia
[http06] http://httpd.apache.org/docs/2.0/mod/core.html
[mod_ssl06] http://httpd.apache.org/docs/2.0/mod/mod_ssl.html
[mod_auth06] http://httpd.apache.org/docs/2.0/mod/mod_auth.html
[mod_rewrite06] http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html
[mod_access06] http://httpd.apache.org/docs/2.0/mod/mod_access.html
[ssl06] http://modssl.org/docs/2.8/ssl_howto.html
[crl01] http://www.apacheweek.com/features/crl
[apache00] http://www.vanemery.com/Linux/Apache/apache‐SSL.html
Recommended