3. Auditoria de Segurança de Redes e Sistemas Operacionais A seguir são apresentados os roteiros dos experimentos com as ferramentas de auditoria da segurança SAINT, Nessus, Sniffer e COPS. 3.1. SAINT 3.1.1. Objetivo Este capítulo trata da instalação e utilização de uma implementação de um scanner SAINT - The Security Administrator's Integrated Network Tool, com objetivo de permitir a avaliação e auditoria da segurança de rede. Neste capítulo o aluno será habilitado a: Entender o funcionamento de um scanner rede/host. Utilizar a ferramenta para avaliar e auditar a segurnaça de rede, identificando vulnerabilidades e encaminhando soluções. 3.1.2. Teoria Introdutória: O SAINT é uma versão atualizada da família do SATAN, Security Administrator Tool for Analyzing Networks. O SAINT é uma ferramenta criada para auxiliar os administradores de sistemas a identificar problemas comuns relativos a segurança da rede e colaborar na sua eliminação. A distribuição do software pode ser encontrada na Word Wide Digital Security Inc http://www.wwdsi.com, bem como uma documentação mais detalhada. O SAINT, implementa uma série de testes atualizados em adição aos testes realizados pelo SATAN, contudo, a teoria aqui exposta estará tratando das características do SATAN. O pacote consiste de um pequeno kernel que tem uma base de dados de regras e vários outros programas responsáveis por diferentes testes de validação de segurança. Cada um 1-36
destes programas pode gerar ao final de sua execução informações que são analisadas e repassadas ao usuário sob forma de hipertexto. A sistemática de funcionamento da ferramenta está baseada em informações obtidas pela rede, através das quais pode-se deduzir: - Fabricante (SUN, IBM, DEC, dentre outros; - A natureza do sistema que está rodando, servidores de arquivos, estações diskless, dentre outros; e - Os vários serviços disponibilizados, WWW, Gopher, anonymous FTP, dentre outros. A ferramenta identifica vários problemas, sem contudo tentar explorá-los. Todos os problemas por ele identificados já foram anteriormente notificados por órgãos de segurança, como o CERT, Computer Emergency Response Team, e CIAC, Computer Incident Advisory Capability, ou explorados na bibliografia sobre práticas de segurança. Tanto o sistema SATAN como o SAINT foram desenvolvidos, utilizando a linguagem C, scripts shell, PERL e o software Mosaic. 3.1.2.1. A Interface e Opções do Sistema O SATAN possui uma interface gráfica baseada em hipertexto, visualizada por navegadores como o Netscape Navigator. Esta interface é utilizada tanto para orientar o usuário através das opções de análise da rede quanto para exibir os resultados intermediários de suas pesquisas e as informações classificadas obtidas ao final dos testes. A interface é mantida por um servidor HTTP, disparado juntamente com o browser do cliente no momento da carga do sistema. O servidor está escrito em PERL e implementa alguns serviços básicos do protocolo HTTP. Através do cliente podem ser configuradas as diferentes opções a serem utilizadas pelo software SATAN. Dentre estas, encontram-se: - Nível de Ataque: define o grau com que os hosts serão analisados. Existem 3 níveis implementados: mínimo, normal e máximo. 2-36
- Proximidade: define até onde a rede será explorada. Alvos primários, ecolhidos explicitamente pelo usuário, tem proximidade 0, novos hosts descobertos durante a pesquisa dos alvos primários tem nível 1, e assim por diante. - Expansão de Subrede: define que para cada alvo primário, o SATAN testa todos os 256 possíveis endereços de outros hosts. O usuário deve especificar a rede ou host a ser pesquisado. A rede pode ser "varrida" por tipo ou grau de vulnerabilidade, ou pelo número de falhas encontradas. Para cada tipo de problema encontrado, o SATAN oferece um tutorial que explana o problema e qual será o seu impacto. O tutorial também explica o que pode ser feito a respeito do problema: corrigir um erro em um arquivo de configuração, instalar um patch, restringir o acesso, ou simplesmente desabilitar um serviço. Esta característica é de grande valor e serve como diferenciador entre esta ferramenta e outras. 3.1.2.2. Níveis de Pesquisa Como dito anteriormente, o SATAN permite uma escolha entre diversos níveis de pesquisa tanto para hosts como para subredes. Dependendo da escolha, um conjunto de testes diferenciados é executado sobre os alvos escolhidos, abaixo estão especificados alguns testes realizados em cada nível de ataque. Os níveis são cumulativos, ou seja, o nível máximo realiza todos os seus testes, além dos citados em normal e mínimo: - Mínimo DNS, RPC, showmount; - Normal tcpscan, portas conhecidas como WWW, Gopher e FTP, udpscan (53,177), finger, rusers, boot, Yellow Pages (NIS); - Máximo tcpscan (1-9999), udpscan (1-2050, 32767-33500), NFS, rsh, ypbind, xhost, FTP. No nível mínimo, o SATAN pesquisa o host alvo e estabelece as características gerais do sistema, se é um servidor de arquivos ou uma estação diskless. São coletadas informações sobre o RPC (Remote Procedure Call), criando-se uma lista de serviços RPC disponíveis. Esta lista de aplicações é armazenada em uma base de dados para ser utilizada posteriormente. Através do DNS (Domain Name System) são verificados o 3-36
nome e o endereço IP dos alvos escolhidos. Também são obtidas informações dos hosts para troca de e-mail, servidores de nomes para este domínio e registros HINFO. E finalmente, é realizado um teste com o comando showmount, com objetivo de verificar quais hosts montam partições no host alvo. No nível normal, são identificados o tipo de sistema (SUN, SGI, DEC, IBM, HP), versões e existência dos serviços de rede que são mais comumente oferecidos (rlogin, anonymous FTP, WWW, Gopher, e-mail). Estes dados são obtidos através de ferramentas do tipo scanner, uma para portas TCP e outra para portas UDP. No nível máximo, o SATAN procura identificar falhas relacionadas com o controle de acesso. Neste nível, o SATAN também procura identificar os usuários do sistema, isto se o daemon ruserd estiver ativo. Esta informação é obtida através da analise da saída do comando rpcinfo. Outra observação realizada sobre a saída do comando rpcinfo é a respeito do serviço bootparam, responsável por prover informações para o boot de estações diskless. Através deste serviço podem ser obtidas informações junto ao servidor NIS (Network Information Service), tais como: arquivos de configuração do servidor e seu arquivo de senhas. Neste nível também é testado o comando finger, para obter maiores informações sobre determinado usuário. Aqui também é feita uma pesquisa em todos os números possíveis de portas, tanto TCP como UDP. 3.1.2.3. Estrutura de Funcionamento O SATAN é composto de um kernel central, que implementa a parte mais geral do sistema, e por vários outros pequenos programas responsáveis por detalhes de implementação de serviços de rede e testes de vulnerabilidades. O kernel é composto pelos seguintes subsistemas: - Cripto-ignição: responsável pela geração de uma chave pseudo-randômica para validar a comunicação entre o cliente e o servidor HTTP. Este servidor é implementado pelo próprio SATAN, e possui apenas um subconjunto dos comandos definidos pelo protocolo; - Máquina de política: este subsistema determina quais hosts serão pesquisados e quais os níveis de teste são adequados para aqueles hosts. Isto 4-36
é realizado baseando-se no arquivo de configuração satan.cf, onde é definida a política para a análise de segurança a ser usada pelo SATAN; - Aquisição de alvos: dada uma lista de hosts, este subsistema gera uma lista de testes a serem utilizados para aqueles hosts; - Aquisição de dados: a partir da lista de testes gerada pelo subsistema de aquisição de alvos, este subsistema executa o conjunto de operações correspondente, e gera novos fatos, que servirão como entrada para a máquina de inferência; - Máquina de inferência: responsável por gerar uma nova lista de hosts, testes e fatos, baseada nos dados obtidos pelo sistema; e - Relatórios e análise: subsistema responsável pela tabulação dos dados na linguagem HTML, para ser repassados ao browser. É composto basicamente por scripts PERL, que lêem os arquivos de resultado dos testes e os formatam em textos HTML. O SATAN opera iniciando conexões para diferentes portas em computadores remotos, e então determina que tipo de informação cada porta retorna. Ele testa um grande número de vulnerabilidades, incluindo NFS (Network File System) e NIS (Network Information Service). 3.1.2.4. Arquivos de Regras Para que o sistema tenha condições de se adaptar, permitindo a identificação de novas falhas de segurança sem necessitar de maiores alterações no código já construído, são definidos os arquivos de regra. Esses arquivos possibilitam a implementação da verificação de uma nova falha pela inserção de uma nova regra no sistema e criação de um novo módulo (.satan) para avaliação das condições que definem a vulnerabilidade. Existem cinco arquivos de regras, abrangendo diferentes pontos de configuração, listados abaixo: - Hosttype: regras que reconhecem banners para diferentes aplicações, como telnetd, ftpd e sendmail. 5-36
- Drop: determina quais fatos devem ser ignorados durante a avaliação do sistema, como um CD-ROM exportado sem restrições de acesso. - Services: regras que classificam os hosts em função dos serviços por eles providos. Estas regras são responsáveis pela tradução dos registros de dados internos do SATAN em informações a serem mostradas nos relatórios para os usuários. - Todo: regras que especificam quais testes devem ser realizados e a ordem em que as ferramentas são disparadas. Como as regras são definidas por um script PERL, os dados obtidos por uma ferramenta podem servir como entrada de dados para outra, via uso de variáveis do script. - Trust: regras que classificam os hosts através da sua relação de confiança. Estas regras também são usadas para tradução das formas de armazenamento internas do SATAN para informações classificadas, compreensíveis pelo usuário. 3.1.2.5. Scripts de Teste O subsistema de aquisição de dados e a máquina de inferência baseiam-se em vários scripts processados pela aplicação SATAN para localizar e inferir sobre possíveis falhas na segurança. Estes scripts são construídos em linguagem PERL, e cada um é responsável por testar diferentes aplicações ou obter mais informações para o sistema de inferência, são eles: - boot.satan: através dele podem ser obtidas informações sobre o domínio de nomes do NIS. Usa o comando bootparam para obter informações de estações diskless que permitem o boot; - dns.satan: usa o servidor de nomes para tradução de nomes para endereços e vice-versa (nslookup). Novos alvos também são localizados através deste serviço; - finger.satan: é usado para obter informações junto ao daemon da máquina alvo sobre usuários conectados, incluindo a origem da conexão. Os hosts 6-36
aqui descobertos também podem ser usados para realimentar a lista de hosts do sistema; - ftp.satan: verifica se o serviço provê anonymous FTP (freqüentemente mal configurado), ou se o diretório raiz do serviço está aberto para escrita (permite a execução remota de comandos, via arquivos como.forward); - nfs-chk.satan: consulta o portmapper e aponta sistemas de arquivos que podem ser montados por programas não privilegiados; - rex.satan: procura pela existência do daemon rexd (execução remota de comandos); - rpc.satan: faz uma consulta ao portmapper através do comando rcpinfo p, para descobrir quais são as aplicações que usam RCP e que estão sendo usadas pela máquina alvo; - rsh.satan: verifica se o host destino confia no host a partir do qual SATAN está executando. Isto depende de arquivos de configuração como.rhosts e hosts.equiv; - rusers.satan: tenta obter nomes de usuários que estão logados na máquina, podendo também obter mais nomes de hosts para a sua lista de alvos; - showmount.satan: tenta obter informações sobre sistemas de arquivos exportados sem restrição de acesso; - tcpscan.satan: reporta os serviços TCP usados. Invoca a ferramenta tcp_scan; - tftp.satan: conecta o hosts tentando pegar o arquivo /etc/passwd. Se o serviço estiver mal configurado, o arquivo será obtido; - udpscan.satan: reporta os serviços UDP que estão sendo usados. Usa a ferramenta udp_scan; - xhost.satan: verifica o visualizador das aplicação X e analisa se ela está vulnerável a alguns tipos de ataque mais simples; 7-36
- yp-chk.satan: pesquisa o servidor NIS. Tenta encontrar arquivos de configuração acessíveis (p.e. o arquivo de senhas); e - ypbind.satan: tenta descobrir qual é o domínio de nomes do NIS, bem como qual é o seu servidor. 3.1.2.6. A Descoberta dos Alvos O primeiro passo para qualquer programa que faça uma análise de uma rede é descobrir quais são os componentes da rede. Ele se utiliza de ferramentas como nslookup, para consultas ao DNS, e fping, uma var iação do programa ping. Todo o subsistema de aquisição de alvos esta baseado principalmente no programa fping, que é usado para descobrir todos os hosts ativos na subrede onde o alvo primário foi definido. Fping é um variação realizada sobre o programa ping de maneira a aumentar a eficiência em relação ao seu antecessor, ele também se baseia no protocolo ICMP, enviando pedidos e aguardando suas respostas. A diferença entre as duas implementações é que fping aceita uma lista de nomes/endereços de hosts a serem verificados, na forma: fping HOST1, HOST2... HOSTn Ao invés de testar um host por vez, enviando um request e esperando pela respectiva resposta ou um timeout do destino, fping envia um pacote ping para HOST1, e vai para o próximo da lista, seguindo um escalonamento do tipo robin-round. Quando um host envia uma resposta, ela é anotada, e o nome do host deletado da lista de escalonamento. Se não houver uma resposta dentro de um limite de tempo previamente estabelecido e/ou dentro do limite estabelecido para uma nova tentativa, o host será considerado como unreachable. O SATAN passa para a aplicação fping uma lista de 256 hosts, independente da máscara usada pela rede. As tentativas são fixas, como se fosse uma rede de endereços classe C. Além do aumento na eficiência da pesquisa, uma outra vantagem pelo uso do fping é a possibilidade de se verificar hosts através de pontes e roteadores, o que não é conseguido com técnicas de inundação (pacotes de broadcast). 8-36
3.1.2.7. Subsistema de Aquisição de Dados Após a obtenção e validação de uma lista de hosts, o subsistema de aquisição de alvos repassa o controle ao subsistema de aquisição de dados, responsável por obter informações sobre um determinado host. Este subsistema visa obter informações sobre quais aplicações estão sendo executadas na máquina alvo, isto é realizado analisando todas as portas de um determinado host. Elas são analisadas a partir de duas ferramentas: TCP_SCAN e UDP_SCAN. Estas ferramentas procuram por todos os serviços disponibilizados pelo host para a rede. Uma vez estabelecida a conexão com o HOST:PORTA destino, o programa tenta obter durante um intervalo de tempo préestabelecido o banner da aplicação que está instalada naquele número de porta. Todas as informações obtidas são armazenadas na base de dados, para serem posteriormente apresentadas ao usuário, através do subsistema de análise e relato de dados. O SATAN permite especificar intervalos de portas a serem avaliadas de acordo com a intensidade do ataque, visando com isso aumentar o desempenho do sistema. Todo o processo de verificação das portas é realizado em paralelo. A verificação e validação das portas usadas pelo sistema é uma maneira de localizar em primeiro lugar quais os serviços são fornecidos por um determinado host, e assim identificar possíveis falhas no sistema, como encontrar um host que fornece serviços como tftpd e rexd, cuja simples existência já é potencialmente uma falha na segurança do sistema. Outra furo na segurança que pode ser localizada a partir deste método é a localização de programas não identificados, instalados em portas desconhecidas, isto é, nenhuma daquelas listadas na última RFC Assigned Numbers. Possivelmente, backdoors padrões usadas pela comunidade hacker, e devidamente documentadas na RFC Resource For Crackers.. 3.1.2.8. Relações de Confiança O software SATAN também permite obter relatórios quanto às relações de confiança. Ele permite gerar informações a respeito de uma subrede, relatando quais são os hosts considerados pela maioria como confiáveis. Um host considerado confiável possui privilégios como login sem a exigência de senhas (root ou usuários normais) e compartilhamento de dados (diretórios montados remotamente - NFS) das máquinas que confiam nele. 9-36
3.1.3. Implementação Prática 3.1.3.1. Instalação do Aplicativo Passo 1: O aluno deverá obter, a partir do servidor FTP indicado pelo instrutor (utilizar login anonymous), o arquivo saint-3.0.1.beta1.tar.gz que se encontra dentro no diretório saint, gravando-o no diretório /home/seguranca. Este arquivo deverá ser descompactado, procedimento este que resulta na criação de um subdiretório /home/seguranca/saint-3.0.1, contendo um conjunto de arquivos criados automaticamente. O comando para execução do processo de descompactação, a ser digitado no prompt do shell de comandos é: tar -xvzf saint-3.0.1.beta1.tar.gz - Observação 1: Feito o passo anterior, o aluno deverá entrar no diretório saint-3.0.1 criado e verificar os vários arquivos e diretórios criados com a extração e ler o arquivo README. Passo 2: A partir do diretório saint-3.0.1 criado, o aluno deverá executar o script de configuração da compilação, no prompt do shell, conforme a sintaxe a seguir:./configura Passo 3: Após a leitura completa dos arquivos da implementação o aluno deverá gerar o conjunto de arquivos executáveis a partir das rotinas que estão implementadas. Para tanto, o aluno deverá digitar de dentro do diretório saint-3.0.1 o seguinte comando no prompt: make 3.1.3.2. Execução Passo 7: Para a execução do aplicativo, o aluno poderá ter previlégios de um usuário comum. O SAINT trabalha com uma interface GUI, e por isso o comando dado a seguir no shell da máquina será para um ambiente gráfico. O comando a ser digitado é:./saint 10-36
Passo 8: A partir da interface Web, o primeiro passo seria criar uma data-base personalisada, definida no primeiro campo (Data Management), conforme a figura abaixo.. Figura 3.1-1 Data Management Saint Passo 9: A partir da interface Web, defina os host, no primeiro campo, aonde a varredura será realizada, fornecendo os seus endereços IP (Target Selection), conforme a figura abaixo. - Observação 2: Ainda o aluno deverá selecionar o nível de varredura máximo (heavy). Após estas configurações o aluno deverá clicar no botão Start Scan, para começar a fazer o escaneamento no host escolhido. 11-36
Figura 3.1-2 Target Selection Saint Passo 10: Após a etapa anterior, o SAINT fará uma varredura no host escolhido pelo aluno. A partir da finalização das coletas de informação, o aluno deverá clicar em Continue with Report and Analysis. 12-36
Figura 3.1-3 Saint Data Collection Saint Passo 11: A partir desta etapa, o aluno deverá escolher o modo de como estas informações coletadas no host deverão ser apresentadas em relatório, conforme a figura a seguir. Estas informações podem ser por vunerabilidades, por hosts e por relações de confiança. 13-36
Figura 3.1-4 Data Analysis Tabela of Contents Saint Passo 12: Para facilitar o manuseio da ferramenta, o aluno deverá escolher as informações do host escaneado por subrede (by subnet). A figura a seguir, ilustra todas as subredes já escaneadas, que são gravadas automaticamente nas data-base definidas em Data Management. 14-36
Figura 3.1-5 Data Analysis Host Tabelas Saint Passo 13: Posteriormente, o aluno deverá selecionar o host da subrede que foi escaneado. As informações pertinenetes de sistema do host, os serviços de rede instalados e as vulnerabilidades serão listadas conforme a figura a seguir. 15-36
Figura 3.1-6 Data Analysis Results Saint Passo 14: Neste caso, o aluno deverá escolher as principais vulnerabilidades apresentadas pelo host e tentar encontrar as possíveis soluções de acordo com o seu interesse, conforme é ilustrado na figura a seguir. Cabe lembrar que para cada host escaneado, situações adversas serão encontradas, servindo a figura de apenas um exemplo singular. 16-36
Figura 3.1-7 Vulnerability Solutions Saint 17-36
3.2. Nessus 3.2.1. Objetivo: Este capítulo trata da instalação e utilização de um aplicativo que tem função básica de escanear portas TCP/IP. Neste capítulo o aluno será habilitado a: Entender o funcionamento da ferramenta, como uma arquitetura baseada em cliente-servidor; Analisar os serviços TCP/IP mapeados pela ferramenta; e Verificar as principais vunerabilidades encontradas no experimento e suas respectivas possíveis soluções. 3.2.2. Teoria Introdutória: O Nessus é uma outra ferramenta de scanner, baseada em uma arquitetura clienteservidor, permitindo que os testes realizados a partir do servidor possam ser comandados e monitorados a partir de um host remoto, aonde estará instalado o cliente. Uma documentação mais detelhada poderá ser encontrada na página oficial do Nessus, http://www.nessus.org. Para a configuração no servidor, o usuário precisa ter previlégios no sistema, como root. O servidor pode ser usado para realizar buscas e gerar relatórios a partir de várias máquinas, aonde o software cliente estará instalado. O cliente consiste em uma interface GUI, sendo que os comandos para a sua utilização podem ser como privilégios de um usuário comum. O servidor deste scanner, nessusd, é composto de um pequeno kernel que coordena a inicialização de diversos testes implementados através de vários programas e/ou scripts desenvolvidos separadamente (plug-ins). O servidor implementa também um 18-36
mecanismo de autenticação de clientes baseado em criptografia assimétrica, associado com possibilidade de configuração de políticas (rules), relacionando os usuários com o conjunto de host/redes (alvos) nos quais eles podem executar os testes do scanner. A interface cliente em sistemas tipo UNIX, inclusive Linux, é baseada na biblioteca GTK para aplicações GUI em gerenciadores de janela X11. Também estão disponíveis clientes Win32 e Java TM. Outra característica do Nessus que merece destaque é a Smart Service Recognition. O Nessus não assume que os serviços em um host alvo estarão sendo executados necessariamente nas portas designadas pelo IANA (Internet Assigned Number Authority). Desse modo, ele é capaz de reconhecer serviços rodando em portas não convencionais (p.e. ftpd rodando na porta 31337 ou servidor web rodando na porta 8080). 3.2.3. Implementação Prática 3.2.3.1. Instalação do Aplicativo Passo 1: O aluno deverá obter, a partir do servidor FTP indicado pelo instrutor (utilizar login anonymous), o arquivo nessus.tar que se encontra dentro no diretório nessus, gravando-o no diretório /home/seguranca. Este arquivo deverá ser descompactado, procedimento este que resulta na criação de um subdiretório /home/seguranca/nessus, contendo um conjunto de arquivos criados automaticamente. O comando para execução do processo de descompactação, a ser digitado no prompt do shell de comandos é: tar -xvf nessus.tar - Observação 1: Feito o passo anterior, o aluno deverá entrar no diretório nessus criado e verificar os vários arquivos e diretórios criados com a extração e ler o arquivo README. Passo 2: A partir do diretório nessus criado, o aluno deverá executar o seguinte comando, no prompt do shell, conforme a sintaxe a seguir: tar -xvf lib.tar 19-36
- Observação 2: Cabe lembrar que esta fase de instalação do aplicativo vale para o servidor e para o cliente, ou seja, os mesmo procedimentos de instalação devem ser feitos em ambos. Passo 3: Como root, edite o arquivo /etc/ld.so.conf, para adicionar o caminho do subdiretório lib criado com o comando do passo anterior. (p.e. /root/nessus/lib) Passo 4: Em seguida, o aluno deverá executar o script /sbin/ldconfig. Este comando se faz necessário para a reativação das fontes ld, ou seja, para que as bibliotecas de ligação dinâmica sejam reativadas. 3.2.3.2. Execução Passo 5: Para a execução no servidor, o aluno deverá ter previlégios de root para criar um usuário com senha temporária na máquina local. O comando a ser digitado no prompt do linux é:./nessusd c nessusd.conf P USER,PASSWD Passo 6: A execução do serviço no servidor, daemon, é feita pelo seguinte comando:./nessusd c nessud.conf D Passo 7: Para a execução do cliente, o aluno poderá ter previlégios de um usuário comum. O Nessus trabalha com uma interface GUI, e por isso o comando dado a seguir no shell da máquina será para um ambiente gráfico. O comando a ser digitado é:./nessus - Observação 3: Apenas para evitar confusão de comandos, no lado do servidor o comando a ser dado./nessusd, enquanto que no lado cliente o comando é./nessus Passo 8: Para que o cliente possa estabelecer uma conexão segura com o servidor, será criada uma chave pública (Pass Phrase). - Observação 4: A chave pública que for gerada estará armazenada nos arquivos /etc/*nessus.keys e /etc/*nessus.ssr 20-36
Passo 9: Após estabelecida a conexão segura com o Servidor, o cliente ainda deverá abrir uma sessão no servidor, ou melhor se logar com as senhas de usuário que foram geradas no passo 5. A figura 1 mostra a configuração da nova sessão, com informações do IP do servidor, a porta para a sessão, o tipo de criptografia e as informações de login. Figura 3.2-1 Informações do Servidor Passo 10: Ainda no Nessus Setup, o aluno poderá escolher que tipos de plugins poderão ser abilitados, conforme ilustrado na figura 2. Para uma melhor verificação, todos eles devem ser selecionados e abilitados. 21-36
Figura 3.2-2 Tipos de Plug-ins - Nessus Passo 11: Na pasta Prefs., tem-se as configurações de acesso para alguns tipos de serviço, como ICMP, FTP, SMB, IMAP, POP2, POP3, dentre outros, confome ilustrado na figura a seguir. 22-36
Figura 3.2-3 Customização de determinados Serviços - Nessus Passo 12: A pasta Scan Options auxilia ao aluno a customizar o escaneamento em uma máquina. A primeira opção é quais as portas que estarão fazendo parte do range de escaneamento, logo após a quantidade de max threads e finalmente o caminho das fontes cgi. Em uma outra janela estarão listados os port scanner. A figura 4 ilustra detalhadamente estes recursos. 23-36
Figura 3.2-4 Nessus Setup Scan Options - Nessus Passo 13: Finalmente é na pasta Target Selection onde será determinado o IP do alvo. Ainda existe a possibilidade de optar por verificar uma DNS zone transfer, conforme é mostrado pela figura 5. Após a configuração do alvo, o aluno poderá começar o escaneamento através do botão Start the scan. - Observação 5: O botão Read File... facilita ao usuário abrir um arquivo que já tenha sido gravado em um dos escaneamentos, de forma que não será necessário a reavaliação do alvo. 24-36
Figura 3.2-5 Nessus Setup Target Selection - Nessus Passo 14: A pasta User é destinada as configurações pessoais do usuário, como o gerenciamento da chave, opções de troca de passphrase e de apagar a própria chave. Ainda pode personalizar usuários com regras específicas, conforme ilustrado na figura 6 a seguir. - Observação 6: A pasta Credits ilustra apenas informações pertinentes ao desenvolvimento do software como, versões, autores, datas, dentre outros. 25-36
Figura 3.2-6 Nessus Setup User - Nessus 3.2.3.3. Resultados Passo 15: Apóa a execução do Nessus para o escaneamento de portas de um específico alvo, o aluno deverá verificar no relatório as principais vunerabilidades encontradas e as possíveis soluções. Um exemplo deste relatório está ilustrado na figura 3.2-7 e 3.2-8. - Observação 6: O Nessus Report apresenta um sumário contendo as vunerabilidades encontradas. Para estas vunerabilidades, dependendo do nível de segurança o Nessus ilustra-as com tons de cores diferentes, sendo que os casos mais críticos em vermelho. (figura 3.2-7) - Observação 7: O Nessus Report também apresenta possíveis soluções para que estes problemas de segurança não venham mais a acontecer. Além de determinar o fator de risco para a segurança da máquina. (figura 3.2-8) 26-36
Figura 3.2-7 Nessus Report Summary - Nessus Figura 3.2-8 Nessus Report Security Holes - Nessus 27-36
3.3. Sniffer 3.3.1. Objetivo: Este capítulo trata da instalação e utilização de uma ferramenta responsável pela analisé de protocolos, verificando o acesso ao meio em uma rede Ethernet. Neste capítulo o aluno será habilitado a: Entender o funcionamento da ferramenta, como um analisador de protocolos; e Verificar as principais vunerabilidades encontradas no experimento e suas respectivas possíveis soluções. 3.3.2. Teoria Introdutória: Computadores em rede compartilham canais de comunicação. Isso é, obviamente, muito mais barato que passar um cabo para cada par de computadores e usar um switch (hub) pra comutar as conexões. Neste canais compartilhados, computadores podem receber informações enviadas a outros computadores. A ação de capturar informações destinadas a uma outra máquina é chamada sniffing. O padrão Ethernet envia um pacote para todas as máquinas em um mesmo segmento. O cabeçalho do pacote contem o endereço da máquina destino. Supõe-se que somente a máquina que tenha o endereço contido no pacote receba-o. Diz-se que um computador está em modo promíscuo quando o mesmo captura todos os pacotes, independentemente de serem ou não destinados a ele. Em um ambiente de rede normal, os nomes e as senhas dos usuários sao passadas atraves da rede em claro, ou seja, texto não criptografado. Não é dificil, portanto, um intruso utilizando uma máquina com interface de rede em modo promíscuo, obter qualquer senha, inclusive a do root, usando um sniffer. Portanto, um sniffer é um programa que torna um computador promíscuo na rede, tendo assim, um acesso completo a todos os pacotes de comunicação que passam pela rede 28-36
onde o computador está conectado, caso a comunicação da rede não seja feita com segurança. Há dois métodos principais para proteger a rede desses Sniffers: - Usando criptografia: a criptografia não vai impedir que os hackers tenham acesso à todos os pacotes da rede, mas vai impedir que ele leia as informações dos pacotes. - Usando a tecnologia de one-time password: S/key e outras tecnologias de one-time password, tornaram sem efeito a ação do sniffer, já que a cada conexão uma nova senha deve ser informada. O uso dessa tecnologia permite usar um canal inseguro, pois não existe uma reutilização de uma mesma senha... Essa tecnologia é baseada em desafio e resposta. O S/key está disponível na Área de Downloads. Para detectar um dispositivo sniffer que somente coleta dados e não responde a nenhuma solicitacao, é necessario o exame fisico de todas as conexões ethernet e a verificação individual das interfaces. Um sniffer, rodando em uma máquina, coloca a interface de rede em modo promíscuo com o intuito de capturar todos os pacotes de um determindado segmento. Na maioria dos sistemas Unix é possivel detectar uma interface promiscua. Note que é possivel usar um sniffer em modo não promíscuo, porem somente poderao ser capturados os pacotes enderecados para a máquina onde ele está rodando. O comando a seguir mostrará informações relativas a todas as interfaces de rede em cada máquina ifconfig -a A utilização do comando "ifconfig", requer que o dispositivo seja especificado. Uma maneira de saber o nome deste dispositivo é utilizar o comando a seguir que mostrará a seguinte saída: netstat -r 29-36