PIBIC Programa Institucional de Bolsas de Iniciação Científica (CNPq-UFES) Processo Seletivo 2001-2002. Anexo 3 RELATÓRIO FINAL

Universidade Federal do Espírito Santo Pró-Reitoria de Pesquisa e Pós-Graduação Av. Fernando Ferrari, s/n Goiabeiras 29.060-900 Vitória, ES, Brasil Tel: +55 (27) 3352439 - Fax: +55 (27) 3352438 http://www.prppg.ufes.br - prppgsec@npd.ufes.br PIBIC Programa Institucional de Bolsas de Iniciação Científica (CNPq-UFES) Processo Seletivo 2001-2002 Anexo 3 RELATÓRIO FINAL Identificação. Grande Área CNPq: 3 Área CNPq: Engenharias Título do Projeto: Reconfiguração de redes corporativas sob ataque Pesquisador Responsável: Raul Henriques Cardoso Lopes (orientador) Sérgio Antônio Andrade de Freitas (co-orientador) Nome do Bolsista: Bruno Oliveira Silvestre

1. Introdução Com a expansão desordenada da Internet, houve um crescimento alarmante nas redes corporativas do número de tentativas de invasão, tanto das máquinas ligadas direta ou indiretamente à Internet. Seja apenas por mera diversão, seja para conseguir informações sigilosas, tais ataques representam uma ameaça real às corporações, pois causam danos materiais tais como: perda de dados armazenados, roubo de informações sigilosas ou, no mais das vezes, danos à imagens da organização. Alguns sistemas têm sido propostos para combater tais invasões, resumidamente eles fazem uso do seguinte procedimento: um programa automatizado chamado IDS (Sistema de Detecção de Intrusos) descobre que está sendo feita uma tentativa de invasão, então o administrador é avisado sobre o ataque, e é este quem vai tomar as devidas providências. Qual o problema com esta abordagem? O administrador não é uma máquina que fica 24 horas, 7 dias por semana, vendo se há uma invasão. Mesmo que ele ficasse, a partir de uma invasão, podem ser necessárias uma vasta gama de ações, por parte do administrado, para que a rede possa voltar ao estado operacional inicial. Esta reconfiguração pode demandar horas e ser muito detalhada. Facilmente se constata que o administrador, mesmo sabendo do ataque, vai ter que deixar a rede parada por um tempo demasiadamente longo, até que os serviços normais da corporação possam ser assumidos (via Internet). Isto traz grandes prejuízos. É justamente a automatização deste processo de planejamentos das ações necessárias para a reconfiguração de uma rede de computadores, o objetivo do trabalho de Iniciação Cientifica descrito neste relatório. Este trabalho de Iniciação Cientifica faz parte de um projeto maior, chamado projeto SEGURA, que visa desenvolver um sistema automatizado de detecção e reconfiguração automática de redes sob ataques, externos ou internos à corporação. O trabalho aqui descrito, parte do projeto SEGURA, visou estudar, elaborar e implementar um componente de decisão, que nada mais é do que um programa que permite a elaboração de planos, a partir da informação de que a rede está sob ataque e de quais serviços estão ativos. Com estas informações é possível elaborar um plano de ações que vai reconfigurar a rede, minimizando ou mesmo anulando os efeitos de um ataque (ou tentativa de ataque). No trabalho descrito a seguir, foi proposto um modelo para o componente de decisão, foi feito um estudo detalhado das relações de dependência entre serviços da rede (HTTP, SMTP, DNS, FTP e NFS) e implementado os programas de comunicação (em C++) e o núcleo de criação de planos de reconfiguração em Prolog.

2. Materiais e Métodos A primeira parte do trabalho foi realizar um estudo sobre os principais serviços existentes em uma rede de computadores. Esses serviços servem como porta de entrada para o atacante, que aproveitando de falhas existentes nos programas que provêem o serviço, toma o controle ou causa algum tipo de dano. Além desse estudo também foi montada uma interdependência entre eles e os clientes que os acessam. Essa relação entre diferentes serviços permite ter uma idéia do que é afetado durante um ataque a determinado serviço. O estudo pode ser visto com mais detalhes na subseção 2.1. Conhecido os serviços da rede, foi necessário descobrir como os ataques eram realizados. Através de pesquisas em livros sobre hackers e vulnerabilidades dos sistemas [17], pesquisas em páginas da Internet, listas de discussões, fóruns e revistas, foi possível identificar e classificar as formas de ataques utilizados. Percebeu-se que existe uma seqüência de passos básicos a serem seguidos antes que um ataque seja realizado. O processo se inicia com o levantamento do máximo de informações sobre as redes alvos: sistemas operacionais, serviços ativos, perfil dos usuários, etc. O passo seguinte é a procura por um serviço que possua um problema de segurança, e finalmente, utiliza-se ferramentas específicas para o ataque 1. Em um dos laboratórios do Departamento de Informática, foi reproduzido um ambiente com heterogeneidade de sistemas operacionais, serviços e plataformas, reproduzindo, minimamente, o funcionamento de uma grande organização. Nesse ambiente foram realizados testes de ataques com o objetivo de colocar em prática o que foi estudado e ter a oportunidade de: estabelecer as características dos ataques (através dos rastros deixados ou dos efeitos colaterais provocados nos sistemas); definir as ações a serem tomadas para que se possa evitar os ataques. Finalmente, de acordo com os objetivos do projeto, foi elaborado um modelo de um componente, que utiliza técnicas de inteligência artificial, para a automatização da defesa contra intrusões na rede. A descrição do componente é vista na seção 4. Um protótipo do modelo elaborado foi construído. Devido às características do componente (comunicação via rede, criptografia, processo de tomada de decisão, etc.), vários estudos adicionais foram realizados. O componente foi implementado em C++, mas devido as facilidade da linguagem Java para comunicação TCP/IP e a utilização de criptografia, vários teste foram feitos no intuito de tentar migrar tal linguagem. No apêndice B, é mostrada a interface do servidor e do cliente utilizada para a comunicação TCP/IP. No processo de tomada de decisão foi utilizada uma máquina de inferência abdutiva construída em Prolog, o Revise [16]. Ela utiliza uma notação própria que é apresentado no Apêndice A. Para entender o funcionamento do Revise foi necessário um estudo de lógica não monotônica [18] e de programação em lógica com a linguagem Prolog [15]. Depois de definidas as regras para que o Revise pudesse efetuar todo os cálculos para as ações a serem tomadas, foi necessário integrar o módulo em C++ de comunicação com o Revise. Para descrição das regras do Revise foi necessário um estudo detalhado das relações de dependência entre os serviços de uma rede. 1 Por motivos éticos e para evitar problemas de utilização de má fé do trabalho, os nomes de máquinas e os seus respectivos endereços de rede, citados neste trabalho, são fictícios.

2.1.Serviços da Rede Os serviços analisados foram os seguintes: DNS, NFS, FTP, SMTP e HTTP. A escolha desse conjunto de serviços se deve ao fato de eles serem os mais comumente encontrado nas redes de computadores das organizações. 2.2. DNS - Domain Name Server O DNS é um serviço que armazena em uma base de dados os nomes dos computadores de um domínio, seus respectivos IP's, informações sobre quais são os servidores de e-mail, o e-mail do responsável pelo domínio, apelidos das máquinas e algumas informações adicionais como o sistema operacional que está sendo executado no servidor DNS. O estudo realizado sobre o DNS mostrou uma dependência entre os servidores NFS, FTP, SMPT e HTTP, como mostrado na figura 2.1. Figura 2.1: Dependência entre servidores NFS, FTP, SMTP e HTTP e o servidor DNS Os servidores NFS e FTP utilizam o DNS para resolver o endereço dos clientes que pedem acesso como uma forma de autenticação. Servidores SMTP podem ser configurados para obter do servidor DNS do domínio de destino da mensagem qual a máquina responsável pelo recebimento de mensagens no domínio. Figura 2.2: Dependência dos clientes com o servidor DNS. O servidor HTTP pode utilizar o DNS para guardar no arquivo de log o endereço da máquina que requisitou conexão, mas esse tipo de ação não é fundamental para o funcionamento do serviço. Através de sua base de dados interna, o servidor DNS é capaz de efetuar a resolução de nomes e IP's, isto é, ele recebe pedidos sobre qual o IP, dado o nome da máquina, ou o processo inverso, qual o nome da máquina responsável por determinado número de IP. Os serviços da rede geralmente utilizam essa última forma de resolução como forma de autenticação ou quando necessitam exibir ao usuário informações de uma forma mais legível para o usuário. O uso do DNS permite a flexibilização na utilização e configuração da rede, visto que se toda a organização identifica as máquinas pelos seus nomes e todas as informações sobre os respectivos números de IP's são centralizadas no DNS, quando há a necessidade de reconfiguração ou remanejamento de serviços poucas alterações são realizadas. Por exemplo, caso uma máquina troque de IP (exceto o servidor DNS) ou o nome do servidor de e-mail do domínio, somente a base de dados do DNS necessita ser atualizada.

Cada servidor DNS é responsável por um domínio de máquina e pode delegar para outro servidor DNS a responsabilidade por um subdomínio gerando uma árvore hierarquia, assim toda requisição de resolução deve ser encaminhada ao servidor responsável por determinado domínio. Um exemplo de hierarquia de domínios, encontrado na Internet, é mostrado na figura 2.3. Figura 2.3: Exemplo de uma hierarquia de domínios. Memorizar o nome coerente de uma máquina, isto é, nomes que pertencem a um domínio conhecido como, por exemplo, nomes de cidades, é muito mais cômodo para os seres humanos do que o seu número de IP. Por isso quase todos os programas que trabalham em rede dão a opção ao usuário de informar o endereço da máquina no lugar do e-mail - endereço da máquina é o seu nome seguido do caminho completo do seu domínio até o topo da hierarquia, onde cada divisão de nível é separada pelo caractere., por exemplo, www.inf.ufes.br indica máquina com o nome www que pertence ao domínio inf, que é subdomínio de ufes, que por sua vez é subdomínio de br. 2.3. HTTP - HiperText Transport Protocol O HTTP é um protocolo de distribuição de conteúdo muito utilizado na Internet. Ele permite que os programas clientes tenham acesso às informações armazenadas em servidores remotos, tais como: documentos HTML (Hipertext Markup Language), textos, vídeos, imagens, animações, etc. Também é permitido ao cliente enviar informações ao servidor. A paralisação do servidor HTTP pode ter um impacto sobre os serviços FTP e HTTP, como mostrado na figura 2.4. O serviço FTP pode ter o serviço HTTP como uma interface de acesso. Para os usuários é bem mais simples e amigável ter acesso aos arquivos via navegador do que ter de decorar comandos ou utilizar programas específicos para acesso FTP, além disso, textos explicativos podem ser utilizados para orientar os usuários, como os passos a serem seguidos para a instalação do aplicativo. Figura 2.4: Dependência dos provedores de serviço com o servidor HTTP. Uma organização pode optar por ter dois ou mais servidores HTTP para distribuir a carga de acesso, colocando parte do conteúdo em cada servidor. O contexto geral de distribuição do conteúdo estará comprometido se um servidor não estiver funcionando corretamente, pois somente parte das informações estará disponível. Nesse caso fica caracterizada uma dependência lógica de funcionamento entre os servidores HTTP.

Na figura 2.5 pode-se observar que o único cliente dos serviços que estão sendo analisados que possui uma dependência com o HTTP é o seu próprio cliente http, que em sua grande maioria é um navegador de páginas HTML. Figura 2.5: Dependência dos clientes com o servidor HTTP. 2.4. NFS - Network File System Muitas organizações possuem máquinas dedicadas para uma distribuição centralizada de arquivos. Essas máquinas são conhecidas como servidores de arquivos. Os servidores aceitam requisições de leitura e escrita de arquivos dos clientes da rede. O Network File System (NFS) é um serviço de rede, que provê uma forma de tornar acessível um ou vários ramos da hierarquia de diretório de uma máquina, para que outras estações de trabalho da rede possam manipular os arquivos e diretórios. Inicialmente desenvolvida para sistemas UNIX, hoje já existem versões do NFS para vários tipos de sistemas operacionais. Figura 2.6: Dependência dos provedores de serviço com o servidor DNS Da análise do serviço NFS percebeu-se a ligação entre os servidores HTTP e SMTP, que se dá quando esses servidores buscam arquivos de configuração personalizados, e alguns outros arquivos, nos diretórios de trabalho dos usuários e esses diretórios estão sendo disponibilizados através do NFS (figura 2.6). Por exemplo, o servidor de HTTP Apache permite que os usuários disponibilizem conteúdo em seu diretório de trabalho. Se as áreas dos usuários estiverem sendo acessadas via NFS, o conteúdo não vai estar disponível para o servidor. Um raciocínio análogo pode ser feito a respeito do servidor de SMTP Sendmail (que vai ser melhor descrito na seção 2.6) que busca arquivos de configuração nas áreas de trabalho dos usuários. Da mesma forma que os servidores HTTP e SMTP, o cliente FTP pode estar dependente do servidor NFS. Quando o usuário efetua o login nesse serviço, ele é automaticamente enviado para o seu diretório de trabalho. A figura 2.7 ilustra as ligações com o servidor NFS. O cliente NFS tem por finalidade tornar o acesso remoto transparente para o usuário do computador. Para que os clientes tenham acesso aos arquivos, é feita uma requisição ao servidor que, dependendo das permissões do cliente, responde confirmando o pedido de acesso. A partir desse ponto a hierarquia de diretórios e arquivos requisitada pelo cliente é montada no seu sistema de arquivo, ou seja, os arquivos e diretórios remotos passam a fazer parte do sistema de arquivos local da máquina, mas sobre a gerência do cliente NFS junto com o auxilio do sistema operacional.

Figura 2.7: Ligação dos clientes com o servidor NFS Um exemplo da utilização do NFS é a disponibilização das áreas de trabalho dos usuários em toda a rede. Quando o usuário efetua o login, seu diretório de trabalho pode ser acessado via NFS. Caso o usuário vá trabalhar em outra máquina, novamente o seu diretório pode ser disponibilizado na nova máquina e nenhuma configuração adicional necessita ser realizada. 2.5. FTP - File Transfer Protocol É considerado o serviço mais conhecido para transferência de arquivos remotos. Como a NFS, o serviço de FTP é uma forma de compartilhamento de arquivos. Apesar de ele ser acessado diretamente pelo usuário, ele originalmente foi designado para ser utilizado por programas - vários softwares utilizam ele para a transferência de arquivos para atualização automatizada, sincronização de sistemas, etc. Ele possui um protocolo simples, o que ajuda na transferência de grande quantidade de dados e que abstrai a forma como os arquivos estão sendo armazenados remotamente. O FTP não utiliza nenhum mecanismo de criptografia, por isso, em certos casos, ele está sendo substituído pelo SFTP (Secure File Transfer Protocol). O servidor FTP, comumente, recebe requisições de seu cliente. Essa ligação é ilustrada na figuras 2.8. Figura 2.8: Ligação dos clientes dos serviços com o servidor FTP. Um servidor FTP pode ser configurado para prover acesso privativo, ou seja, somente os usuários cadastrados no sistema podem acessá-lo. Um acesso público pode ser utilizado para distribuição de arquivos com acesso irrestrito como ferramentas empregadas em toda organização, atualizações de sistemas, documentos, etc. Para acesso público geralmente são usados como nome de usuário: anonymous ou ftp. O protocolo FTP foi elaborado para utilizar duas conexões: uma para transmissão de comandos e outra para a transmissão efetiva dos arquivos. Os comandos são transferidos entre o cliente e o servidor utilizando as regras do protocolo Telnet 2 na conexão de controle. Esses comandos definem, entre outras coisas, os caracteres de controle, a porta para a transferência, etc. Todos os arquivos são transmitidos em uma conexão de dados. Depois de passar os parâmetros da transferência pelo canal de controle, uma conexão de dados é estabelecida entre o cliente FTP e o servidor para que o arquivo seja transferido (depois de estabelecida, a conexão pode ser utilizada para envio e recebimento simultâneo de arquivos). 2 O protocolo Telnet padroniza minimamente o formato dos dados a serem transmitidos e os caracteres de controle. Essa padronização permite a comunicação entre plataformas de software e hardware diferentes.

2.6. SMTP - Simple Mail Transfer Protocol O SMTP é o serviço que permite a troca de mensagens eletrônicas (e-mail) entre usuários. O protocolo SMTP define como dois usuários irão transmitir as suas mensagens. Da análise do serviço SMTP chegou-se as ligações mostradas nas figuras 2.9 e 2.10. Figura 2.9: Relação entre os provedores de serviço e o servidor SMTP. A relação de um servidor SMTP com outro se dá devido à necessidade de transferência de mensagens entre domínios diferentes. Dentre os clientes analisados, o único que interage com o servidor SMTP é o cliente SMTP, que é o responsável por enviar as mensagens dos usuários a um servidor, ou de servidor a servidor. Um servidor SMTP pode ser responsável apenas por um domínio fechado ou permitir a troca de mensagens entre domínios (o e-mail pode atravessar por diversos servidores até chegar naquele responsável pelo destinatário). Em domínios fechados o cliente se conecta com o servidor SMTP e despacha a mensagem. Se servidor reconhece o destinatário, a mensagem é colocada na caixa postal dele, caso o destinatário não exista um erro é reportado para o remetente. Na comunicação entre domínios, o servidor recebe a mensagem e a armazena. Quando possível ela é envia para o destinatário. Se não for possível despachar a mensagem para o destinatário no momento, ela fica armazenada no servidor para uma tentativa posterior. Depois de certo tempo, caso não seja possível entregar a mensagens esta é devolvida ao remetente ou apagada. Figura 2.10: Relação entre os clientes dos serviços com o servidor SMTP. Para descobrir qual o responsável pelo domínio do destinatário, o servidor SMTP realiza uma pesquisa no DNS daquele domínio e obtém o número de IP do SMTP destino, então processo de envio é iniciado. Quando o servidor SMTP recebe uma mensagem de outro servidor SMTP, ele verifica se existe o usuário no domínio. Se existir, a mensagem é recebida, caso contrário um erro de usuário desconhecido é reportado ao remetente da mensagem.

3. Resultados Como resultado do estudo e teste sobre ataques, elaborou-se um programa definido como Componente de Decisão eu permite a geração de um plano de ação/ações que deve ser executado quando a rede estiver sobre ataques. O Componente de Decisão, ao receber informações sobre um ataque vindo do Componente de Detecção, tem a finalidade de buscar formas de: - Impedir a concretização do ataque; - Interromper um ataque bem sucedido; - Retardar o avanço do ataque para que medidas maiores possam ser tomadas pela equipe de segurança. Figura 3.1: Modelo de blocos do Componente de Decisão De acordo com as características do ataque, são geradas propostas de mudanças na configuração da rede baseadas no conhecimento fornecido por intervenção humano, ou por aprendizagem própria que é obtida através dos ataques sofridos, tanto os que foram impedidos como os que foram bem sucedidos. A aprendizagem é o que torna o componente versátil, dando a ele a capacidade de se adaptar a novos tipos de ataque. Um modelo de blocos proposto para esse componente é visto na figura 3.1. O Gerencidor de Entrada/Saída tem como função estabelecer a comunicação dos demais módulos internos com o exterior: outro componente ou serviços que estão sendo utilizados na rede. Essa modularização permite uma uniformidade do acesso externo e um menor impacto no componente de decisão, caso seja necessário uma readaptação à forma de comunicação externa. O ponto mais importante do componente é a Base de Conhecimento (tema do projeto de pesquisa do aluno Arthur Cypriano Monteiro Costa, financiado pela PIBC). Nela são guardadas as informações para que sejam tomadas decisões tais como: reconhecimento do estado da rede, estabelecimento de contramedidas básicas aos ataques, aprendizado sobre características dos ataques, etc. Para evitar inconsistências na base de conhecimento devido ao acesso descontrolado o módulo Gerenciador de Acesso (seção 3.2) surge como uma interface de isolamento: todos os demais módulos, quando necessitam ler informações ou alterá-las na base, fazem seus pedidos ao Gerenciador de Acesso. Além da inconsistência, a adoção de uma camada gerenciadora evita que os demais módulos necessitem saber como a base está estruturada, tornando o acesso às informações mais fáceis. O Mapeador da Rede (seção 3.3) é responsável por manter na base de conhecimento o modelo atualizado da rede. Ele interage com os Componentes de Trabalho (em desenvolvimento como

proposta de projeto de graduação do curso de Ciência da Computação do aluno Rui Sant'Ana Junior), espalhados pelas estações, para a obtenção de informações ou pode se comunicar diretamente com os serviços. Qualquer mudança notada na rede é imediatamente reconhecida e atualizada na base de conhecimento. Quando o Componente de Detecção (em desenvolvimento como proposta de projeto de graduação do curso de Ciência da Computação do aluno Hélder Bergamin Pimentel Dias) reconhece um ataque ou uma tentativa de ataque, ele imediatamente envia as observações sobre o que está acontecendo para o Componente de Decisão. Essas informações são recebidas pelo Gerador de Planos (seção 3.4), que juntamente com as informações da base de conhecimento, irá definir as ações a serem tomadas para impedir o ataque. Ao conjunto de ações é denominado de plano e, dependendo do ataque, o Gerador de Planos poderia vir a preparar diversos planos alternativos equivalentes às contramedidas. O plano, proposto pelo Gerador, é encaminhado ao Simulador de Execução (seção 3.5) que irá testar sua viabilidade. Ele busca na base de conhecimento as informações sobre a rede e verifica se é possível efetuar as ações descritas no plano fazendo com que a rede continue funcionando normalmente. O Executor de Planos (seção 3.6) recebe do Simulador um plano viável e realiza todas as ações nele descritas. Após o término dessa tarefa, ele repassa todas as modificações executadas na rede para o modelo na base de conhecimento, mantendo-a atualizada. Como o Gerador de Planos, o Simulador de Execução e o Executor de Planos funcionam em seqüência, há a necessidade de se definir qual deles deve estar em funcionamento em um determinado instante. O canal de controle permite que esses módulos possam se interagir, definindo quando cada um deve estar ativo. O canal de controle também permite que o Executor de Planos informe ao Mapeador que todas as alterações que serão feitas, de acordo com o plano recebido, serão atualizadas na base, fazendo com que o Mapeador da Rede fique temporariamente em suspensão. 3.1. Gerenciador de Entrada e Saída Este módulo é responsável pela comunicação com o ambiente externo. Sua principal função é a de fornecer um meio para que os outros módulos possam interagir com os demais componentes da arquitetura de forma transparente e segura. O Gerenciador de E/S deve empregar um protocolo de comunicação criptografado, autenticado e certificado. A criptografia evitará que o atacante tenha acesso fácil aos dados trocados entre componentes, através do seqüestro dos pacotes que trafegam pela rede. Como esses dados possuem detalhes da própria rede e pedidos de reconfiguração dos serviços, eles serão de grande ajuda para que um atacante tenha sucesso. Mesmo com um protocolo criptografado é possível obter as informações através da intermediação da conversa de dois componentes. A intermediação é um processo em que o atacante se apresenta ao componente X, por exemplo, como sendo o componente Y, e para o componente Y como sendo X, tornado-se um atravessador. Quando um dos componentes trocar mensagem com outro, as informações serão enviadas para o atacante que as receberá, copiará o que lhe for relevante e as reencaminhará para o seu real destino [14]. Para evitar esse tipo de problema, é empregado o mecanismo de autenticação, com o qual é possível ter certeza de quem está enviando e quem está recebendo. 3.2. Gerenciador de Acesso O módulo Gerenciador de Acesso tem como funções: - Garantir um acesso ordenado e seguro às informações contidas na Base de Conhecimento; - Abstrair o acesso à Base de Conhecimento.

Praticamente todo o funcionamento do Componente de Decisão depende das informações contidas na Base de Conhecimento. Ela armazena o modelo da rede, as características de cada um dos ataques, as contramedidas para cada um e as variações dos ataques aprendidos. Se a base estiver inconsistente, as medidas geradas para combater um ataque podem ser inúteis. O Gerenciador de Acesso obriga que os demais módulos façam requisições de leitura ou alteração das informações a ele, assim é mantido o controle no acesso. A abstração da forma de acesso torna os demais módulos mais simples e, no caso de mudança na maneira de armazenamento das informações, o impacto no componente é minimizado. 3.3. Mapeador da Rede Figura 3.2: Modelo de blocos do Mapeador da Rede Mudanças de configurações na rede podem ocorrer devido a diversos fatores como, por exemplo, o emprego de novos serviços ou uma nova política de segurança. O Mapeador da Rede faz varreduras periódicas para determinar como está a rede. Ao perceber uma configuração diferente, a base de conhecimento deve ser imediatamente atualizada. O Monitor de Rede é o módulo responsável por fazer a interação com os serviços da rede e com o Componente de Trabalho a fim de obter informações sobre o estado atual da rede. As habilidades de obtenção direta de informações do Monitor são menores que as do Componente de Trabalho, que possui um conhecimento bem mais profundo sobre cada serviço que está ativo em cada máquina em que está instalado, pode facilmente ter acesso aos arquivos de configuração, obtendo informações mais detalhadas. O processo de obtenção das informações é controlado pelo Sincronizador. Ele é quem define quando as varreduras devem ser feitas e qual o tipo de informação deve ser buscada (portas ativas, servidores ativos, etc.). Quando o Monitor devolve o resultado da varredura, o Sincronizador deve comparar o que foi obtido com o que está na Base de Conhecimento. Se for notada alguma diferença entre o modelo da rede na base com o resultado da varredura, automaticamente o modelo é atualizado.

3.4. Gerador de Planos Figura 3.3: Modelo de blocos do Gerador de Planos Quando o Gerador de Planos recebe um aviso do Componente de Detecção de que uma tentativa de ataque foi localizada, ele gera planos de defesa numa tentativa de impedir que o atacante tenha sucesso. Esses planos consistem em alterações que devem ser realizadas nos serviços da rede ou ações que devem ser tomadas, por exemplo, remapear o serviço de FTP para porta 33 e enviar uma mensagem à equipe de segurança relatando o fato ocorrido. O Gerador busca na base de conhecimento as contramedidas para aquele tipo de ataque, o modelo da rede mantido pelo Mapeador e a lista das dependências entre serviços. A contramedida é a base de um plano. Ela é quem define o conjunto de ações a serem tomadas para impedir ou combater um ataque. Algumas vezes, um ataque pode possuir mais de uma contramedida, e, dessa forma, mais de um plano de defesa pode ser gerado. As contramedidas podem ser estáticas ou aprendidas. As estáticas são aquelas que foram definidas pela equipe de segurança, sendo inicialmente as únicas existentes. Com o passar do tempo, o próprio componente vai aprendendo com as tentativas ou invasões sofridas, adquirindo um conhecimento sobre quais medidas tiveram sucesso, quais são mais eficazes e quais não funcionam. Esse aprimoramento evita que planos sem efeitos sejam gerados, e garante que o restante dos planos tenha mais chances de resolver o problema. A lista de dependências entre os serviços da rede fornece o conhecimento de como uma mudança em um serviço pode atingir o funcionamento dos demais. É necessário gerar ações que façam com que os serviços dependentes possam continuar funcionando, isto é, ações que devem ser efetuadas para que o elo de dependência não seja quebrado. Todos os planos gerados são encaminhados para o Simulador de Execução para uma triagem. 3.5. Simulador de Execução De posse dos planos gerados pelo Gerador de Planos o Simulador de Execução deve eliminar os planos que contenham ações que não pudessem ser executadas na rede. As limitações impostas às ações podem ser devido a: - O programa responsável pelo serviço não suporta a reconfiguração sugerida; - É um serviço bem conhecido e de grande importância para a instituição. O Validador de Planos percorre todos os planos e as ações neles contidos, confrontando com o conhecimento contido na base para verificar se as alterações podem ser efetuadas. É verificado se o serviço pode atuar na nova configuração proposta (softwares que possuem configuração mais flexíveis) e qual é o grau de impacto nos serviços e programas dependentes. Também é verificado qual a importância do serviço para a instituição. Por exemplo, se a ação implica na

alteração da porta do servidor web da intranet de 80 para 8080, alguns navegadores podem não acessar as páginas 3. Figura 3.4: Modelo de blocos do Simulador de Execução Uma questão que deve ser contornada pelo Validador é a existência de ações, que se forem tratadas isoladamente, invalidam o plano por gerarem inconsistência. Mas, se essa ação for tratada em conjunto com alguma outra, elas se tornam consistente. Utilizando novamente o exemplo da troca de portas do servidor HTTP de 80 para 8080, imagine que dentre as ações existentes no plano uma delas é o envio de uma me-nsagem de aviso para os usuários descrevendo o ocorrido e informando sobre a nova configuração do servidor HTTP na porta 8080. Com isso, o usuário poderia continuar trabalhando normalmente. Depois da triagem, os planos selecionados são classificados pelo Ordenador de Planos. Os critérios de classificação podem ser variados e são definidos pela equipe de segurança, por exemplo, aqueles que provoquem menos alterações no estado atual da rede ou aqueles que utilizem configurações com menores chances de falha têm maior preferência. A priorização dos planos pode garantir uma maior eficiência no combate aos ataques. 3.6. Executor de Planos O Executor de Planos recebe um plano do Simulador e interage com o Componente de Trabalho enviando a ele pedidos de reconfiguração, ou qualquer outro tipo de ação necessária, e obtendo respostas de sucesso ou falha. De acordo com as ações contidas no plano, o Executor pode tentar fazer uma paralelização dos pedidos. Há ações que, necessariamente, devem ser executadas em série devido às dependências entre os serviços, mas ações independentes podem ser requisitadas em paralelo aos Componentes de Trabalho tornando o processo de reconfiguração mais rápido. Figura 3.5: Modelo de blocos do Executador de Planos Tão importante quanto fazer as ações é desfazê-las. Se a tentativa de executar uma das ações de um plano falhar, todas as ações desse plano que já foram realizadas necessitam de ser desfeitas para que a rede fique em um estado consistente, mesmo que esse estado seja o que está 3 Como as portas 80 e 8080 são comumente usadas pelos servidores HTTP, alguns navegadores procuram se conectar primeiro na porta 80, e caso a conexão não seja aceita, eles automaticamente tentam a porta 8080.

sofrendo ataque. Estados inconsistentes podem apresentar mais falhas a serem exploradas sem falar na paralisação de serviços. Quando um plano falha, o Executor deve comunicar-se com o Simulador de Planos e requisitar que outro plano seja enviado. Após o plano ter sido executado com sucesso o Executor de Planos altera o modelo da rede contido na Base de Conhecimento para que ele reflita as mudanças que foram aplicadas, evitando que haja um intervalo muito até que o Mapeador da Rede perceba as mudanças realizadas. Isso evitará o problema de inconsistência das informações armazenadas.

4. Conclusões O trabalho descrito neste relatório tem um forte impacto sobre o sistema SEGURA, pois é justamente o componente de decisão quem vai tomar as decisões com relação à reconfiguração da rede. O problema foi que este componente se mostrou maior de que inicialmente previsto, como pode ser visto pelo modelo proposto, o que acarretou a não implementação da proposta como um todo. Porém o trabalho já realizado com o estudo das dependências entre serviços e o modulo central de planejamento, implementado em Prolog, e utilizando inferência abdutiva, já fornece os planos necessários para o estágio atual do projeto. Outro ponto que também importante a ser destacado é que foi necessário estudar uma série de material para o trabalho: lógicas não-monotônicas, inferência abdutiva, tipos de invasões e Revise, o que demandou mais tempo do que esperado na fase de estudos. As perspectivas do componente de decisão, aqui proposto, são muito boas, pois de acordo com o que temos pesquisado, não existem sistemas de reconfiguração tão sofisticados quanto o que está sendo construído no projeto SEGURA pelo grupo de Segurança de Redes do Departamento de Informática, muito menos algo que se assemelha ao componente de decisão aqui proposto e implementado, sob a forma de protótipo, neste projeto de Iniciação Científica.

5. Bibliografia [1] A. C. Kakas, F. Toni e R. A. Kowalski. Abductive Logic Programming. Journal of Logic and Computation. 1993. [2] Andrew Tanenbaum. Computer Networks. Prentice Hall. 1996. [3] Andrew Tanenbaum. Sistemas Operacionais Modernos. Prentice Hall. 1995. [4] Anonymous. Maximum Linux Security. Sam.net, 2000. [5] Bruce Eckel, Thinking in C++ - Volume 1. 2000. [6] Bruce Eckel, Thinking in C++ - Volume 2. 2000. [7] Bruce Eckel, Thinking in Java. 2000. [8] Victorine Viviane Mizrahi. Treinamento em Linguagem C. 1990. [9] Luiz F. G. Soares; Guido Lemos; Sérgio Colcher. LANs, MANs e WANs: Redes ATM. 1995. [10] Martin, Didier. Profissional XML. 2001. [11] Normas RFC. Obtidas via Internet: http://www.rfcs.org. [12] Thomas Wadlow. Segurança de Redes: Projeto e gerenciamento de redes seguras. Editora Campus. 2001. [13] William Stallings. Practical Cryptography for Data Internetworks. IEEE Press, 1996. [14] Walmir Pereira de Amorim Junior. Criptografia e autenticação: um modelo utilizando RSA, SHA-1 e IDEA. Monografia de Projeto Final do Curso de Ciência da Computação, UFES. 2002. [15] The Sicstus s Prolog Manual. 1993. [16] José J. Alferes, Luís M. Pereira. Reasoning with Logic Programming. Springer Verlag. 1996. [17] Stuart McClune, Joel Scambray, George Kurtz. Hackers Expostos, 2ª edição. Makron do Brasil. 2001. [18] Gerhard Brewka, Jürgen Dix, Kurt Konolige. Nonmonotonic reasoning: an overview. CLSI publications. 1997.

Apêndice A Modelo Prolog - Representação da rede em lógica de primeira ordem: Prolog % model.pl service(1,http). Service(2,smtp). Service(3,dns). Service(4,ftp). Service(5,nfs). Service(6,nis). Host(240,maquina8, 192.168.0.240 ). status_host(240,up). Status_service(2,240,up). % HTTP port(2,240,80). Status_service(3,240,up). % SMTP port(3,240,25). Status_service(4,240,up). % FTP port(4,240,21). Status_service(5,240,up). % DNS port(5,240,53). Service_dep(2,240,5,240). % HTTP dp DNS service_dep(3,240,5,240). % SMTP dp DNS host(5,maquina2, 192.168.0.5 ). status_host(5,up). Status_service(6,5,up). % NIS host(16,maquina10, 192.168.0.16 ). status_host(16,up). Status_service(5,16,up). % FTP port(5,16,21). Status_service(7,16,up). % NFS port(7,16,2049). Service_dep(7,16,5,240). % NFS dp DNS - Regras utilizadas pelo Revise para a inferência abdutiva % rules.pl :-revisable(action(x)). :-revisable(deps(x,y,z)). :-revisable(holes(x,y)). false<obs(atack,serv,host), status_host(host,up), status_service(serv,host,up), not holes(serv,host). % ------------ DEPENDENCIAS ----------- false<holes(serv,host), service_dep(servd,hostd,serv,host), status_host(hostd,up), status_service(servd,hostd,up), not deps(servd,hostd,serv). false<deps(serv,host,_serv), service_dep(servd,hostd,serv,host), status_host(hostd,up), status_service(servd,hostd,up), not deps(servd,hostd,serv).

% ------------ ACOES ------------------ % NIS false<deps(6,host,serv), host(host,name,ip), not action([disable(nis,ip)]). false<holes(6,host), host(host,name,ip), not action([disable(nis,ip)]). % DNS false<holes(3,host), host(host,nome,ip), not action([disable(dns,ip)]). % NFS false<deps(5,host,serv), host(host,name,ip), not action([disable(nfs,ip)]), not action([change(port,nfs,ip)]). % HTTP false<deps(1,host,serv), host(host,name,ip), not action([disable(http,ip)]), not action([change(port,http,ip)]).

/******** tcpserver.h *********/ #ifndef TCPSERVER_H #define TCPSERVER_H #include "tcpconn.h" class TCPServer { int sockfd; bool actived; public: TCPServer(); ~TCPServer(); bool active(const int); void shutdown(); TCPConnection* get_connection(); ; #endif /******** tcpserver.cpp *********/ #include <sys/socket.h> #include <sys/types.h> #include <stdio.h> #include <unistd.h> #include <netinet/in.h> #include <malloc.h> #include "tcpserver.h" TCPServer::TCPServer() { actived = false; Apêndice B Interface em C++ Servidor Socket TCP/IP setsockopt(sockfd,sol_socket,so _REUSEADDR,&aux,sizeof(aux)); addr.sin_family = PF_INET; addr.sin_port = htons(port); addr.sin_addr.s_addr = INADDR_ANY; if( bind(sockfd,(struct sockaddr*) &addr,sizeof(addr)) < 0) { close(sockfd); return false; if( listen(sockfd,5) < 0) { close(sockfd); return false; actived = 1; return true; void TCPServer::shutdown() { if(actived) { close(sockfd); actived = false; TCPConnection* TCPServer::get_connection() { TCPConnection *conn; TCPServer::~TCPServer() { shutdown(); bool TCPServer::active(const int port) { struct sockaddr_in addr; int aux = 1; sockfd = socket(pf_inet,sock_stream,0); if(sockfd <= 0) { return false; if(!actived) { return NULL; conn = new TCPConnection(); conn->sockfd = accept(sockfd,null,null); if(conn->sockfd <= 0) { delete conn; return NULL; conn->connected = true; return conn; Cliente Socket TCP/IP /**** tcpconn.h *********/ #ifndef TCPCONNECTION_H #define TCPCONNECTION_H class TCPConnection { bool connected;

int sockfd; public: TCPConnection(); ~TCPConnection(); size_t tcp_read(char *buf,size_t len); size_t tcp_write(char *buf,size_t len); void disconnect(); bool connect_by_ip(char *ip,int port); friend class TCPServer; ; #endif /***** tcpconn.cpp *****/ #include <sys/socket.h> #include <sys/types.h> #include <netinet/in.h> #include <arpa/inet.h> #include <signal.h> #include <unistd.h> #include <string.h> struct sockaddr_in addr; disconnect(); sockfd = socket(pf_inet,sock_stream,0); if(sockfd < 0) { return false; addr.sin_family = PF_INET; addr.sin_port = htons(port); inet_aton(ip,&addr.sin_addr); if( connect(sockfd,(struct sockaddr*) &addr,sizeof(addr)) < 0) { close(sockfd); return false; connected = true; return true; #include "tcpconn.h" TCPConnection::TCPConnection() { connected = false; TCPConnection::~TCPConnection() { disconnect(); size_t TCPConnection::tcp_read(char *buf,size_t len) { if(!connected) { return 0; return (read(sockfd,buf,len)); void TCPConnection::disconnect() { if(connected) { close(sockfd); connected = false; bool TCPConnection::connect_by_ip(char *ip,int port) {