5. Filantropen og barnet
5.5. R EGULERING AV BEVEGELSENE
Esta subseção apresenta uma comparação onde foram dispostos os dados do OpenAFS, do NFS, do GFS e do HDFS.
O estudo de Adamov [4] apresenta uma comparação entre o HDFS e o GFS, apontando as diferenças a respeito de diversos critérios. Já Milicchio and Gehrke [19] procederam a uma comparação entre o OpenAFS e o NFS sob vários outros aspectos.
Tais estudos subsidiaram a comparação efetuada a seguir, ilustrada na Tabela 3.1:
23Terminologia recente, ligada à Segurança da Informação, que define a transferência não autorizada
Tabela 3.1: Tabela comparativa.
Disponibilidade Integridade Confidencialidade Cache
OpenAFS Por replicação GSS-API Kerberos No cliente
NFS Sem replicação GSS-API Kerberos Por delegação
GFS Por replicação Checksums Não publicada No cliente
HDFS Por replicação Checksums AES No cluster Da análise da tabela e da leitura dos tópicos apresentados, é possível verificar que para uma organização de médio porte que não apresente requisitos de análise de big data, necessitando tão somente de um sistema de compartilhamento de arquivos que ofereça condições de escalabilidade, o OpenAFS apresenta-se como solução viável, o que justifica a presente análise de segurança.
3.4
Considerações finais
Este capítulo apresentou o OpenAFS, evidenciando o detalhamento das características téc- nicas e particularidades do sistema, além de tratadas suas possibilidades e limitações. Especial atenção foi dada à parte dedicada à segurança do sistema, em que foram discuti- das as funções de autenticação, controle de acesso, backup e responsabilização. Tratar das especificidades de segurança do OpenAFS oferece as condições teóricas necessárias para o entendimento dos testes realizados a seguir.
Ao final, foi apresentado um sucinto estudo comparativo entre o OpenAFS e outros três SAD, de modo a identificar as diferenças entre eles e complementar a abordagem do presente estudo.
O capítulo que se segue fornecerá os resultados obtidos com os testes de segurança realizados com a simulação de operação de uma célula do OpenAFS.
Capítulo 4
Análise de segurança
Este capítulo apresenta a execução dos testes realizados com a finalidade de aferir a capacidade dos subsistemas do OpenAFS relacionadas à segurança, conforme planejado no decorrer dos Capítulos anteriores.
A análise de uma implementação do OpenAFS em um ambiente simulado é a parte final dos passos delineados na Subseção 1.4.3. De acordo com Gerhardt and Silveira [22], citados na introdução desta dissertação, a execução desta etapa é necessária para testar a hipótese proposta na Subseção 1.4.2.
A montagem do ambiente de testes utilizou a virtualização como ferramenta para simular a operação de uma máquina na função de cliente, bem como de uma célula típica do OpenAFS e da infraestrutura de autenticação do Kerberos. Este cenário compõe a arquitetura básica deste SAD, o que possibilita o monitoramento dos recursos dos entes envolvidos e a coleta de tráfego, necessário para a análise planejada.
Tal tráfego, depois de coletado, passará por uma análise circunstanciada, comparando- se os resultados obtidos com as características apresentadas na Subseção 3.2. A próxima Seção apresenta a arquitetura do ambiente simulado.
4.1
Arquitetura
Como foi tratado na Subseção 3.1.1, a arquitetura do OpenAFS é do tipo cliente-servidor, típica de Sistemas de Arquivos Distribuídos, sendo baseada em uma estrutura específica denominada célula.
Uma célula do OpenAFS é definida como sendo um conjunto de servidores e clientes gerenciados e operados por uma organização administrativamente independente. Em uma célula, ao menos uma das máquinas deve executar os processos do servidor de banco de dados e do servidor de arquivos.
Sendo esta a estrutura básica do OpenAFS, justifica-se utilizá-la como base para a realização dos diferentes testes propostos neste trabalho. Para tanto, foi implementado um cenário virtualizado do OpenAFS que possibilitou a ocorrência de tráfego de dados específico do sistema, conforme se observa na Figura 4.1, que ilustra sua arquitetura:
Figura 4.1: Arquitetura do cenário.
Como já comentado, o objetivo desta implementação é possibilitar a obtenção de tráfegos de rede para observação técnica. A análise de tais fluxos de dados possibilitará visualizar e mapear as características de segurança que o sistema oferece aos dados que gerencia. Esta análise faz parte dos objetivos desta dissertação e é parte crucial para a identificação das propriedades de segurança da informação do OpenAFS.
Cabe ressaltar, também, que esta proposta considera a presença de pelo menos um intruso passivo que tem capacidade de monitorar qualquer quantidade de nós do sistema, com os objetivos tanto de colher informações sensíveis (credenciais, por exemplo) quanto de obter dados armazenados por meio da remontagem de tráfego do OpenAFS durante a execução dos processos de replicação de volumes1.
4.1.1
Configurações
A apresentação dos detalhes da instalação e configuração geral do ambiente proposto para análise foge ao escopo deste trabalho. Todavia, é importante evidenciar que a montagem do cenário seguiu a documentação oficial do Projeto OpenAFS e do Projeto MIT Kerberos,
especialmente o “OpenAFS Administration Guide”2, o “OpenAFS Quick Start Guide for
UNIX”3 e o “The MIT Kerberos Administrator’s How-to Guide”4.
De maneira resumida, a montagem do ambiente foi realizada da seguinte forma: – Criação da máquina virtual5 “kerb”, com Sistema Operacional Debian GNU/Linux
9.7 (stretch) que executa, dentre outros, dois serviços críticos para o funcionamento do ambiente: a) o Kerberos 5 KDC (Key Distribution Center ), que verifica a identi- dade dos usuários e concede tickets que, em seguida, são convertidos em tokens para provar ao servidor a autenticidade do usuário; e b) O OpenNTPD, que implementa o protocolo NTP, responsável por sincronizar os relógios internos das máquinas da rede com o seu próprio, possibilitando a uniformidade dos clocks e permitindo o correto funcionamento da tecnologia de banco de dados distribuído do OpenAFS; – Criação da VM “afs1”, com Sistema Operacional Debian GNU/Linux 9.7 (stretch)
que executa o componente Servidor do OpenAFS versão 1.6.20 e todos os seus pro- cessos, tais como descritos na Subseção 3.1.1;
– Criação da VM “afs2”, com as mesmas características da VM “afs1” e que, em conjunto com ela, formam o domínio principal do OpenAFS, denominado célula, neste trabalho configurada como “unb.br”; e
– Criação da VM “client”, com Sistema Operacional Debian GNU/Linux 9.7 (stretch) que executa o componente Cliente do OpenAFS, usada para acessar os recursos do Servidor OpenAFS após autenticação no KDC.
Exposta a estrutura básica do ambiente de testes, são apresentados, a partir deste ponto, os detalhes de configuração afetos às características de segurança do sistema.
De acordo com o detalhado na Seção 3.2.1, o Kerberos oferece a possibilidade de criação de chave secreta compartilhada com diversos tipos de configurações, dentre os vários algoritmos possíveis, como é possível verificar na Tabela 4.1:
Tabela 4.1: Tipos de Criptografia do Kerberos.
Família Cifras Força
DES des-cbc-crc, des-cbc-md5, des-cbc-md4 Fraca
3DES ddes3-cbc-sha1 Forte
AES aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96 Forte
2http://docs.openafs.org/AdminGuide.pdf 3http://docs.openafs.org/QuickStartUnix.pdf
4http://web.mit.edu/kerberos/krb5-current/doc/admin/install.html
Ocorre que a versão padrão 1.6.20 do OpenAFS, utilizada neste trabalho e atualmente disponibilizada no repositório stable6 do Debian, ainda não está preparada para a uti-
lização de cifras AES, manipuladas pelo Kerberos 5. Em função desta limitação, há a necessidade de alterar as configurações padrão do Kerberos, de modo que este aceite pedidos de autenticação com chaves DES, relativamente mais fracas se comparadas com chaves AES.
Nenhum usuário se autentica com esta chave. Entretanto, ela é usada para criptografar os tickets que o KDC concede aos clientes do OpenAFS para apresentação aos processos do servidor de arquivos durante a autenticação mútua, como foi detalhado na Subseção 3.2.1.
A Figura 4.2 ilustra o processo de criação da chave secreta DES a ser utilizada para a célula do ambiente proposto:
Figura 4.2: Criação da chave simétrica no Kerberos para uso na célula do OpenAFS.
Desmembrando as partes da chave simétrica DES no modo CBC com checksum CRC- 32 gerada pelo Kerberos, é possível observar que a mesma possui as seguintes caracterís- ticas:
– DES: O Data Encryption Standard é um algoritmo de chave simétrica que utiliza chaves de tamanho 64 bits, dos quais 8 são usados para garantia de integridade. O tamanho efetivo das chaves é, portanto, de 56 bits;
– CBC: O módulo Cipher Block Chaining é utilizado para alterar o algoritmo DES, fazendo com que qual cada bloco de texto simples sofre uma operação de XOR-ed7 com o bloco de texto cifrado anterior antes da criptografia. Desta forma, dois blocos de texto simples idênticos criptografam dados de maneira diferente; e
– CRC: Acrônimo de Cyclic Redundancy Check, é utilizado como método de detecção de erros para fornecer garantia de integridade dos dados.
6Conjuntos de softwares armazenados em uma árvore de diretório especial que pode ser acessada por
clientes que baixam e instalam os pacotes disponibilizados. O repositório stable contém apenas as versões de softwares testadas e estáveis, sendo por este motivo o repositório mais indicado para instalação de servidores.
4.2
Execução de testes
Esta Seção apresenta a execução dos testes de segurança e os resultados obtidos em cada uma das características observadas, conforme planejado na Subseção 1.4.3.