CAPÍTULO 5 PROJETO DE SEGURANÇA

CAPÍTULO 5 PROJETO DE SEGURANÇA 5.1 INTRODUÇÃO Entende-se por projeto de segurança, no contexto desta dissertação, as especificações a serem adotadas, tanto para equipamentos como para programas, para obter o funcionamento conjunto de todos os componentes do sistema computacional visando segurança. 5.2 ESPECIFICAÇÕES PARA HARDWARE Internamente à organização, a distribuição lógica e física dos equipamentos e das redes deve ser tal que auxilie o projeto de segurança. Desta forma, propõe-se, para a mesma, a configuração que se segue: a) A formação de domínios, dentro da organização, que coincidam com as suas grandes divisões organizacionais; b) A definição de grupos de trabalho, internamente a cada domínio, que realizem tarefas comuns; c) Utilização do protocolo de comunicação TCP/IP, independentemente do sistema operacional e da plataforma sendo utilizada; d) A tecnologia de rede local a ser utilizada não é relevante para o projeto mas deve estar adequada às necessidades de comunicação de cada domínio da organização; e) Cada grupo de trabalho deve possuir uma máquina servidora para backup configurada de forma a realizar cópia incremental das áreas de trabalho das diversas estações e que não permita acesso remoto; f) Somente uma máquina em cada grupo de trabalho deve ter privilégio de comunicação para fora do mesmo; g) Uma máquina deve ser posta na entrada do grupo de trabalho para funcionar como uma espécie de gateway que filtre os pacotes que circulam na rede 69

interna deixando somente passar aqueles que se destinam à máquina privilegiada; h) A máquina de entrada pode executar um programa de correio eletrônico, para troca de mensagens interna à organização, contendo as caixas de correio dos usuários do grupo de trabalho que lhe é afeto; i) Cada domínio da organização terá um servidor de DNS primário para seu domínio que será secundário dos demais; j) As informações armazenadas em meio digital que tenham como objetivo ser comercializadas devem estar localizadas em um segmento de rede isolado dos demais domínios; k) Todo acesso aos serviços internos devem passar por um serviço de autenticação do usuário localizado em um segmento de rede isolado dos demais domínios; l) Todos os privilégios de acesso devem ser configurados em máquina especialmente dedicada a esta finalidade localizada em um segmento de rede isolado dos demais domínios; e, m) Toda a comunicação interna, entre domínios, deve ser feita através de um roteador. 5.3 HARDWARE PARA O PROJETO DE SEGURANÇA O projeto de segurança a ser adotado nesta dissertação contempla o uso de um firewall constituído de dois roteadores, com uma DMZ entre eles, e um gateway, com duas NIC, que atue como um proxy, quando necessário. Além desses elementos o acesso aos serviços internos é baseado em autenticação e autorização, através de senhas de acesso, e transmissão dos dados é realizada de forma cifrada. O acesso a serviços internos é feito através dos gateways e, somente, para usuários autenticados. Esta autenticação é obtida a partir do servidor de autenticação, sistema usado para comprovar a identidade do usuário e a máquina externa. 70

Uma vez autenticado o usuário passa a ter acesso aos serviços internos, mas quais? E o que ele pode fazer em cada um deles? Estas respostas são dadas por um segundo elemento do sistema computacional, o servidor de autorização. É ele o responsável por manter uma lista de permissões, autorizações e privilégios para usuários e máquinas que queiram acessar qualquer serviço interno. A configuração acima proposta encontra-se ilustrada na Figura 5.1. Rede Interna Servidores de Autenticação Servidores de Autorização Roteador Externo Gateways Rede Externa Roteador Interno Servidores de acesso público Fig. 5.1 Projeto Físico para as condições estabelecidas. Na configuração proposta na Figura 5.1 são observados os seguintes elementos: a) Roteador externo: responsável pelo filtro de todo e qualquer tráfego entre o interior e o exterior. Controla as rotas permitidas entre as diversas redes; b) Servidores de acesso público: responsáveis pelos servidores públicos da organização como correio eletrônico, transferência de arquivos, WWW e solução de nomes de domínio; c) Gateways: responsáveis por receber as solicitações que tenham origem no interior e cujo destino sejam o exterior e vice versa. Funcionam como proxies permitindo o uso de endereços IP privados, conforme Rekhter et al. (1999), para a rede interna. São configurados de forma a possuírem duas NIC, uma que se liga ao roteador externo e outra ao interno; 71

d) Roteador interno: responsável por controlar o tráfego de e para a rede interna somente deixando fluir aquele autorizado; e, e) Servidores de autenticação: responsáveis por autenticar os usuários internos e externos que solicitem acesso a um dos gateways; e, f) Servidores de autorização: são os responsáveis por manter atualizada as listas de permissões de acesso e os níveis em que esses acessos podem ser feitos. Como o objetivo desta dissertação é tratar apenas da transferência de dados, da estrutura anteriormente apresentada na Figura 5.1 somente será considerado um gateway e não será tratado do acesso aos servidores de acesso público. A configuração de hardware a ser considerado nesta dissertação encontra-se ilustrado na Figura 5.2. Roteador Externo Gateway para o serviço de transferência de arquivos Servidores internos de arquivos para transferência Servidores de Autenticação Servidores de Autorização Roteador Interno Usuário externo Fig. 5.2 Configuração de hardware a ser utilizada nesta dissertação. Para os atender critérios de segurança propostos somente as máquinas que pertencem à DMZ utilizam endereços IP públicos. Todas as demais máquinas usam endereços IP privados, por exemplo, atribuir um endereço IP de rede, classe C, 170.170.170.0, público, máscara 255.255.255.0, com nome de domínio rede.org.br, para as máquinas da DMZ e outro, privado, classe A, 10.0.0.0, máscara 255.0.0.0, para as máquinas das redes privadas. 72

5.4 ESPECIFICAÇÕES PARA SOFTWARE De posse dos elementos de hardware necessários para a configuração do projeto de segurança é necessário que os programas que neles irão rodar atendam, também, aos critérios de segurança estabelecidos na política de segurança adotada. Como, neste novo contexto, os serviços não funcionam mais de forma isolada, propõe-se, nestas especificações, um esquema de interação, através de software, entre os vários elementos de hardware componentes do sistema. Se acredita que, em termos de segurança, um único serviço, em uma única máquina, não é capaz de fornecer todos as características de segurança desejadas de um sistema computacional. Assim, todos os componentes individuais do sistema devem ser executados em máquinas independentes, preferencialmente em sub redes isoladas, separadas por firewall das demais, e este último configurado com filtragem de pacotes, mesmo entre sub redes locais. O que se pretende é que o serviço de transferência de arquivos, para esta dissertação, ou qualquer outro que o substitua, não seja o responsável por executar tarefas outras que não a sua tarefa fim. Assim, a máquina responsável por receber a requisição do cliente externo deve ser uma máquina específica cuja função básica é de estabelecer a conexão. Uma vez estabelecida a conexão ela não deve ser a responsável por autenticar ou autorizar o usuário. Ela deve, portanto, se comunicar outras máquinas que realizem estas tarefas. A máquina que recebe a requisição, além das tarefas anteriormente descritas, deve, quando iniciada a transferência de arquivos, atuar como um proxy mantendo somente seu endereço IP de conhecimento público escondendo todos os demais componentes da rede interna. Propõe-se, finalmente, que a interação entre os diversos componentes do projeto de segurança seja realizado conforme ilustrado na Figura 5.3. 73

Roteador Externo Filtragem de Pacotes Gateway 2, 4, 6, 10, 12, 14, 16, 20 Servidores 7, 9, 15, 18 Autenticação 3, 21 Autorização 8, 19 Roteador Interno Filtragem de Pacotes Usuário externo 1, 5, 11, 13, 17, 20 1 Usuário externo estabelece conexão 12 Recebe autenticação do usuário e a valida 2 Mensagem para Sistema Autenticador 13 Recebe autenticação do servidor e a valida 3 Verifica usuário no BD * 14 Confirma autenticação 4 Dados do Sistema Autenticador p/usuário 15 Transmite o arquivo solicitado 5 Executa validações 16 Passa a atuar como proxy 6 Valida usuário. Mensagem aos Servidores 17 Recebe dados 7 Solicitação acesso no Sistema Autorizador 18 Término. Informa Sistema Autorizador 8 Verifica usuário no BD * 19 Atualiza BD * com as tarefas executadas 9 Relação de arquivos p/máquina gateway 20 Termina conexão 10 Relação de arquivos para usuário 21 Atualiza BD * com a última conexão 11 Solicitação de arquivo e nova autenticação Fig. 5.3 Descrição, por passos, do relacionamento entre os vários elementos do sistema computacional. (BD * - Banco de Dados). A Figura 5.3, ilustra, através de passos, os vários relacionamentos existentes entre os elementos de hardware que compõe o projeto de segurança proposto a serem integrados através de software. Os seguintes sistemas podem ser caracterizados: a) Autenticador: pelos passos 1 a 7, 9 a 14 e 21; b) Autorizador: pelos passos 8 e 19; e, c) Transferência de arquivos: pelos passos 15 a 18 e 20. É possível a adequação deste esquema a outros serviços, que não o de transferência de arquivos, em razão da modularidade imposta aos programas implementados Internamente ao Sistema de Transferência de Dados são executadas as tarefas de compressão de dados e de criptografia. Elas foram implementadas como bibliotecas que podem ser substituídas, por outras, sem perda de funcionalidade. 74

Para esta dissertação tomou-se como prioritária a implementação do conjunto de rotinas que viabilizem o projeto de segurança proposto sem levar em consideração aspectos como otimização do código e parâmetros de segurança para execução das rotinas. Além disso, itens como gerenciadores de banco de dados, auxiliares no processo de integração do projeto de segurança, não foram implementados, pelo menos não na sua plenitude, já que fogem ao escopo desta dissertação. 5.4.1 PLATAFORMA E SISTEMA OPERACIONAL Em função da grande quantidade de máquinas do tipo Personal Computer (PC) hoje disponíveis no mercado e como o cliente, em potencial, desta organização é um usuário comum, tomou-se como plataforma a ser utilizada para o desenvolvimento dos programas os computadores pessoais. A decisão quanto ao sistema operacional a ser utilizado passou por um critério de seleção mais demorado. É fato que sistemas operacionais baseados no Windows 95, 98 ou NT detém parte considerável do mercado de sistemas operacionais não corporativos, hoje. A despeito dessa consideração o seu uso em sistemas computacionais que requeiram segurança, particularmente os servidores, é temeroso. Vários fatores que podem ser listados para ratificar esta afirmação como o desconhecimento do código do sistema operacional, o uso de threads dentro de um mesmo processo e a falta de recursos mais precisos para gerência de tempo. Assim, para o programa servidor, optou-se por se utilizar o sistema operacional Linux por ter distribuição gratuita, inclusive do código do sistema, e por estar se popularizando com relativa velocidade. A opção do sistema para o cliente é muito mais delicada do que a do servidor. Para uma aplicação comercial tomar-se-ia, com certeza, a decisão de se desenvolver o programa para o sistema Windows. No caso desta dissertação optou-se por utilizar o sistema Linux, uma vez mais. Todo o código desenvolvido foi testado nas versões Red Hat 5.1, 5.2 e Guarani 3.0 do sistema operacional Linux. 75

5.4.2 INICIALIZAÇÃO DOS SERVIÇOS Dentro das especificações a serem seguidas para o software a ser executado incluem-se as formas de inicialização dos programas servidores. De acordo com Stevens (1990) existem várias maneiras de se inicializar um processo, dentre elas: a) Durante a inicialização do sistema, inicializado pelo script /etc/rc que é executado por /etc/init; b) De forma periódica, se configurado no arquivo de sistema /usr/lib/crontab, que é executado pelo programa cron; c) Pela execução do comando at que agenda a execução de uma tarefa para alguma tempo posterior; e, d) A partir do terminal do usuário como uma tarefa em primeiro ou segundo plano. Como no caso em questão está sendo tratado, exclusivamente, de processos servidores. Eles, uma vez inicializados, devem possuir as seguintes características: a) Inicializados somente uma vez quando o sistema é iniciado; b) Seu tempo de vida é o tempo total de operação do sistema. Em condições normais sua operação não sofre interrupções; c) Gastar a maior parte do tempo aguardando que algum evento ocorra, momento em que realizam sua tarefa; e, d) Criar outros processos que tratam das requisições. Todos os programas servidores desenvolvidos para esta dissertação possuem as seguintes opções de inicialização: a) Pela digitação do seu nome na linha de comando do terminal e sua execução pode ser feita em primeiro ou segundo plano; ou, 76

b) Através do daemon processo executado em segundo plano sem estar associado a qualquer terminal que, ou aguarda que algum evento ocorra ou espera para realizar uma tarefa específica conhecido por inetd executado durante a inicialização do sistema. Este processo atua como um super servidor para serviços da Internet. As formas de inicialização a serem implementadas são melhor exemplificadas a partir das interações entre as diversas interações que ocorrem. Se o processo servidor for inicializado pelo daemon inetd os passos a serem executados encontram-se ilustrados na Figura 5.4. Usa a função select(). Aguarda conexão e estabelece parâmetros. inetd daemon fork() exec() Processo Pai. Recebe mensagem, cria processo filho e termina Processo servidor (pai) fork() Processo Filho. Cria novo socket e trata do serviço para o cliente Processo servidor (filho) Requisição para porta conhecida Primeira resposta Fig. 5.4 Processo cliente Atividades a serem executadas para a inicialização de um serviço através do daemon inetd. FONTE: Adaptada de Stevens (1990, p.517). Nesta situação o daemon inetd permanece aguardando pela requisição do usuário através da função select() já tendo criado, nessa altura do processamento, o socket apropriado para o protocolo de transporte sendo utilizado, feita a amarração do mesmo à porta especificada para o serviço e ao endereço IP, além de ter criado a fila de atendentes, se o protocolo de transporte for o TCP. Quando a requisição do cliente chega uma chamada à função accept() é executada para aceitar a conexão. Neste momento o daemon inetd cria um processo filho para tratar da requisição. O processo que criou o novo processo fecha o socket que está conectado e retorna a select() para aguardar nova conexão. 77

O processo criado fecha todos os descritores de arquivo que não seja o descritor de socket que ele está tratando e chama a função de sistema dup2() para duplicá-lo nos descritores de arquivo 0, 1 e 2. O socket original é então fechado. Desta forma os únicos descritores abertos no processo filho são os de números 0, 1 e 2. Neste ponto se o serviço sendo executado necessitar de autenticação é o momento de executá-la. É neste instante, também, que se atribui o grupo de processamento e o usuário do processo através de chamadas às funções setuid() e setgid(). Definidos esses parâmetros o processo filho executa uma chamada a exec(), que substitui o processo corrente pelo processo do serviço desejado, no caso da Figura 5.4 o processo servidor pai. Neste instante o processo servidor pai lê o datagrama à disposição do serviço, cria um novo processo filho, processo servidor filho, na Figura 5.4, e termina sua execução. Este último processo fecha os descritores de socket 0, 1 e 2, criados pelo daemon inetd, cria um novo, e passa a tratar do serviço a que o servidor se propõe. Se, por outro lado, a inicialização for feita pela linha de comando as interações que necessárias encontram-se ilustradas na Figura 5.5. Processo Pai. Recebe mensagem, cria processo filho e continua Processo servidor (pai) fork() Processo Filho. Cria novo socket e trata do serviço para o cliente Processo servidor (filho) Requisição para porta conhecida Primeira resposta Fig. 5.5 Processo cliente Atividades a serem executadas para a inicialização de um serviço através da linha de comando. FONTE: Adaptada de Stevens (1990, p. 517). A inicialização, através da linha de comando, para execução em primeiro plano não encontra maiores dificuldades necessitando apenas da chamada à rotina de sistema fork(). 78

Entretanto, para inicialização em segundo plano algumas das etapas, originalmente executadas pelo daemon inetd, devem ser codificadas. O processo servidor pai tem de executar os seguintes passos antes de iniciar o processamento do serviço propriamente dito, nesta forma de inicialização: a) Fechar todos os descritores de arquivo não necessários. Essa etapa diz respeito, particularmente, aos fluxos padrão de entrada, de saída e de erro, stdin, stdout e stderr, respectivamente. Isto é executado a partir do seguinte fragmento de código: #include <sys/param.h> for(i = 0; i < NOFILE; i++) close (i); b) Atribuir um diretório de trabalho. A área de trabalho associada ao processo é considerada aberta pelo kernel enquanto o mesmo estiver ativo. Desta forma o sistema de arquivos onde reside o diretório de trabalho não pode ser desmontado. Para efeito de segurança o diretório atribuído como de trabalho não deve conter nenhuma outra informação que não as necessárias à execução do processo e deve ser exclusivo do mesmo. É implementado com o código: chdir( /<diretório> ); c) Desfazer a máscara de criação de permissões para acesso a arquivos. Um processo herda esta máscara do seu pai. Desfazendo-a previne que qualquer arquivo criado pelo processo tenha seus bits de acesso modificados. O código para implementar é: umask(0); d) Trabalhar em segundo plano. Para evitar que um terminal fique amarrado ao processo em execução o processo executa um fork e o processo pai emite um exit() permitindo que o processo continue no processo filho. O código que o implementa é: if ( fork()!= 0) exit(0); /* Termina processo pai */ 79

if ( (fd = open( /dev/tty, O_RDWR)) >= 0) { ioctl(fd, TIOCNOTTY, (char *) 0);/* Perde controle*/ close(fd); /* Fecha terminal*/ } e) Desassociar o processo de grupos de processamento. Todo processo herda seu identificador do grupo de processamento do pai. Se permanecer ligado a algum grupo o processo fica suscetível aos sinais enviado a todos os processos do grupo. Para evitar esta condição ele é desassociado do grupo de processamento herdado bem como do seu próprio grupo de processamento. Para executar esta tarefa o processo faz com seu identificador de grupo de processamento seja igual ao seu identificador de processo fazendo com que o processo chamador seja um líder de um grupo de processamento em um novo grupo. A chamada que a implementa é: setpid (0, getpid()); f) Ignorar sinais de todos os terminais de entrada ou saída desassociando o processo do seu terminal de controle. O código que implementa é: #ifdef SIGTTOU /* Saída para terminal */ signal (SIGTTOU, SIG_IGN); #ifdef SIGTTIN /* Entrada para terminal */ signal (SIGTTIN, SIG_IGN); #ifdef SIGTSTP /* Código de parada no terminal */ signal (SIGTSTP, SIG_IGN); O processamento para inicialização em segundo plano é feita por dois processos. O primeiro somente é executado da primeira vez que o servidor é executado e até a criação do segundo, momento em que termina. O segundo, é o que está efetivamente ilustrado na Figura 5.5 como processo servidor pai. A partir deste momento quando chega uma requisição de um processo cliente ele cria um novo processo servidor filho que tratará do serviço propriamente dito enquanto que o pai retorna à condição de espera de novas requisições. 80

5.4.3 ARQUIVOS DE REGISTRO Todos os servidores a serem implementados devem permitir a opção de mais de um tipo de arquivo de registro. Os que se considera fundamentais para a operação do sistema são: a) Arquivo de debug. Serve para verificar os passos executados por cada uma das rotinas implementadas. Não deve ser uma opção de conhecimento geral e também não deve fazer parte da versão a ser utilizada publicamente. É muito útil para, no caso de inserção de novas rotinas ou modificações nas já existentes, verificar se seu funcionamento está de acordo com o esperado; b) Arquivo de trace. É onde se listam as operações de comunicação com o usuário e serve para verificar a consistência das mesmas. Difere do anterior por não fazer menção aos dados que são transferidos, tão somente à operação de comunicação em si; c) Arquivo de log. É onde se lista os usuários ativos naquele instante, a atividade que está sendo executada e a identificação do processo que está cuidando do processamento, dados de grande utilidade para o administrador de redes para verificação de tentativas de invasão do sistema. Este arquivo deve ser verificado por todos os processos que recebem uma conexão para verificar se determinado usuário já está com uma sessão ativa bloqueando, neste caso, acesso à criação do processo filho e terminando a execução. 5.4.4 PROTOCOLOS DE TRANSPORTE E PORTAS Foram usados dois protocolos de transporte: TCP e UDP. Para o estabelecimento da conexão entre o usuário e o gateway do serviço desejado e autenticação é utilizado o protocolo TCP, o que corresponde na Figura 5.3 aos Passos de 1 a 10. A partir desse instante o protocolo de transporte utilizado é o UDP. Define-se como sendo 71 a porta para o estabelecimento da conexão do cliente com o gateway do serviço desejado. No arquivo de serviços do Linux, /etc/services, esta porta 81

não está atribuído a nenhum outro serviço, em nenhum dos dois protocolos de transporte considerados para esta dissertação. Utiliza-se uma porta privilegiada para ser possível utilizar recursos que advém da situação privilegiada de root. Mesmo que uma porta não privilegiada fosse utilizada, em várias situações, como no acesso aos bancos de dados com dados dos usuários, privilégios deste nível seriam necessários o que teria de ser obtido elevando-se o privilégio do processo em execução. Como a idéia central da implementação executada nesta dissertação é a validação do projeto de segurança como um todo optou-se por, neste instante, por não implementar esta forma de trabalho. Ainda, as portas 72 e 73 são atribuídas para comunicação do gateway do serviço de transferência de dados com os servidores de autenticação e de autorização, respectivamente. Para todas as comunicações uma vez estabelecida a conexão é criado um novo processo, numa porta não privilegiada que irá tratar do processamento. Algumas portas, por facilidades de processamento, são não privilegiadas mas sua determinação segue uma regra pré estabelecida como, por exemplo, para a confirmação da autenticação e requisição do serviço, Passos 11 a 14 da Figura 5.3, a porta utilizada no gateway do serviço correspondente à soma de todos os caracteres do nome do usuário, transformados em inteiros, somados a 1024. 82