SEGURANÇA COMPUTACIONAL by ARL UFLA

Curso de Pós-Graduação “Lato Sensu” (Especialização) a Distância Administração em Redes Linux

SEGURANÇA COMPUTACIONAL

2a Edição

Joaquim Quinteiro Uchôa

Universidade Federal de Lavras – UFLA Fundação de Apoio ao Ensino, Pesquisa e Extensão – FAEPE Lavras – MG

PARCERIA UFLA – Universidade Federal de Lavras FAEPE – Fundação de Apoio ao Ensino, Pesquisa e Extensão REITOR Antônio Nazareno Guimarães Mendes VICE-REITOR Ricardo Pereira Reis DIRETOR DA EDITORA Marco Antônio Rezende Alvarenga PRÓ-REITOR DE PÓS-GRADUAÇÃO Joel Augusto Muniz PRÓ-REITOR ADJUNTO DE PÓS-GRADUAÇÃO “LATO SENSU” Marcelo Silva de Oliveira COORDENADORA DO CURSO Kátia Cilene Amaral Uchôa PRESIDENTE DO CONSELHO DELIBERATIVO DA FAEPE Edson Ampélio Pozza EDITORAÇÃO Grupo Ginux (http://www.ginux.ufla.br/) IMPRESSÃO Gráfica Universitária/UFLA Ficha Catalográfica preparada pela Divisão de Processos Técnicos da Biblioteca Central da UFLA Uchôa, Joaquim Quinteiro Segurança Computacional/ Joaquim Quinteiro Uchôa. - - 2.ed. Lavras: UFLA/FAEPE, 2005. 59 p. : il. - Curso de Pós-Graduação “Lato Sensu” (Especialização) a Distância: Administração em Redes Linux. Bibliografia. 1. Segurança Computacional. 2. Criptografia. 3. Detecção de Intrusos. 4. Firewall . 5. Gerenciamento de Usuários. I. Uchôa, J. Q. II. Universidade Federal de Lavras. III. Fundação de Apoio ao Ensino, Pesquisa e Extensão. IV. Título. CDD-005.8 -0001.6425 Nenhuma parte desta publicação pode ser reproduzida, por qualquer meio ou forma, sem a prévia autorização.

SUMÁRIO

1 Introdução

2 Conceitos Básicos 2.1 Comentários Iniciais . . . . . . . . . . . . . . . . 2.1.1 Políticas de Segurança e Políticas de Uso 2.2 Crime Virtual . . . . . . . . . . . . . . . . . . . . 2.3 Ataques Mais Comuns . . . . . . . . . . . . . . . 3 Uso de Criptografia 3.1 Conceitos Básicos . . . . . . . . . . . . . 3.2 Algoritmos Criptográficos . . . . . . . . . 3.3 Protocolos Criptográficos . . . . . . . . . 3.4 Criptografia e Segurança Computacional 4 Segurança por Controle de Acesso 4.1 Comentários Iniciais . . . . . . . . 4.2 Segurança Física e Backups . . . 4.3 O Uso de TCP-Wrappers . . . . . 4.4 Uso de Firewalls ou Proxies . . . . 4.5 Configuração Segura de Serviços

. . . . .

. . . . . . . . .

5 Administração Segura de Usuários 5.1 Uso do PAM (Pluggable Authentication Modules) 5.2 Protegendo Contas de Usuários . . . . . . . . . 5.3 Segurança no Sistema de Arquivos . . . . . . . . 5.4 Comentários Finais . . . . . . . . . . . . . . . . . 6 Prevenção e Detecção de Intrusos 6.1 Comentários Iniciais . . . . . . . . . . . . 6.2 Verificação dos Registros (Logs) . . . . . 6.3 Evitando Exploits . . . . . . . . . . . . . . 6.4 Uso de Ferramentas de Varredura . . . . 6.5 Verificadores de Integridade de Arquivos . 6.6 Detectores Ativos de Intrusão . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . .

9 9 10 12 13

. . . .

17 17 18 19 20

. . . . .

23 23 23 24 27 30

. . . .

33 33 38 39 42

. . . . . .

43 43 44 47 48 51 51

7 Conclusão

Referências Bibliográficas

LISTA DE FIGURAS

3.1 Processos Criptográficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Conceito de VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17 22

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8

Uso de TCP-Wrappers . . . . . . . . . . . . . . . Exemplo de Arquivo /etc/hosts.deny . . . . Exemplo de Arquivo /etc/hosts.allow . . . Exemplo de Arquivo /etc/xinetd.conf . . . Exemplo de Arquivo /etc/xinetd.d/finger Uso de Firewall . . . . . . . . . . . . . . . . . . . Trecho do Arquivo /etc/services . . . . . . . Exemplo de Configuração do iptables . . . . .

. . . . . . . .

25 26 26 27 27 28 29 30

5.1 5.2 5.3 5.4 5.5 5.6

Exemplo de Arquivo /etc/pam.d/su . . . . . . . . . . Exemplo de Arquivo /etc/pam.d/chsh . . . . . . . . Exemplo de Arquivo /etc/security/access.conf . Exemplo de Arquivo /etc/security/time.conf . . Exemplo de Arquivo /etc/security/limits.conf . Execução do Comando ulimit-a . . . . . . . . . . . .

. . . . . .

34 35 35 36 37 39

6.1 6.2 6.3 6.4 6.5 6.6

Exemplo de Uso do Comando last . . . . Exemplo de Uso do Comando lastlog . . Exemplo de Alerta do logwatch . . . . . . Vulnerabilidades Encontradas pelo SARA . Deltalhamento da Vulnerabilidade no SARA Exemplo de Registro do Snort . . . . . . .

. . . . . .

45 46 47 49 50 53

. . . . . .

. . . . . . . .

. . . . . .

. . . . . . . .

. . . . . .

. . . . . . . .

. . . . . .

LISTA DE TABELAS

3.1 Opções Mais Usadas do gpg . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1 Recursos Limitados pelo pam_limits . . . . . . . . . . . . . . . . . . . . . 5.2 Atributos de Arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37 41

1 INTRODUÇÃO

Este texto tem por principal objetivo instruir o seu leitor nos conceitos básicos relativos à segurança em redes de computadores, sob o enfoque do sistema operacional Linux. Esses conceitos incluem os passos básicos necessários à administração segura de um servidor Linux, mas não somente. Observe que ao processo de gerenciamento de um servidor, dá-se o nome de administração de serviços ou administração de redes, já abordados em (UCHÔA; SIMEONE; SICA, 2003). O administrador de redes moderno não pode relegar esse assunto a um segundo plano. Com a evolução das redes de computadores, o número de invasões tem crescido assustadoramente. Isso aumentou não somente a necessidade de segurança, como também a necessidade de privacidade por parte dos sistemas e dos usuários. Assim, existe uma grande necessidade do administrador estar em constante atualização quanto à utilização de procedimentos para aumentar o nível de segurança dos sistemas computacionais sob seu domínio. Como forma de subsidiar o leitor de uma fundamentação teórica sobre o assunto, o Capítulo 2 apresenta uma discussão sobre políticas de segurança e políticas de uso. Além disso, esse capítulo aborda as questões legais envolvendo segurança, incluíndo-se o conceito de crime virtual. Já o Capítulo 3 apresenta os conceitos básicos de criptografia, apresentando a diferenciação entre protocolo e algoritmo de criptografia. Utilizando-se técnicas criptográficas, esse capítulo mostra ainda como fazer transporte seguro de dados. Segurança por controle de acesso é abordada no Capítulo 4. Entre outras técnicas, esse capítulo orienta o leitor sobre o uso dos TCP-wrappers e firewall. Já técnicas de administração segura de usuários são vistas no Capítulo 5, incluíndo-se o uso do PAM, sudo e quotas em disco. Por sua vez, métodos de prevenção e detecção de intrusos são apresentados no Capítulo 6. Este texto foi escrito pensando em um usuário intermediário do sistema operacional Linux (ou equivalente). Ele foi produzido principalmente a partir da experiência adquirida pelos autores em administração de laboratórios e uso de diversos sistemas operacionais. Essa experiência em administração de sistemas foi enriquecida pela leitura de diversos materiais, destacando-se, principalmente: (NEMETH et al., 1995), (NEMETH et al., 2001), (STAN-

EDITORA - UFLA/FAEPE - Segurança Computacional

FIELD; SMITH, 2001), (WIRZENIUS; OJA; STAFFORD, 2001), (FRAMPTON, 1999), (MANN; MITCHELL, 2000), (ANONYMOUS, 2000), (KIRCH; DAWSON, 2000), (HATCH; LEE; KURTZ, 2002),

(SCHNEIER, 1996). A essas referências devem ser acrescidos vários Howtos1 disponibilizados pela The Linux Documentation Project 2 . Entre esses Howtos, destacam-se (FENZI, 2002), (BURGISS, 2002a) e (BURGISS, 2002b). É importante comentar que este texto é apenas uma apostila anterior, denominada “Segurança em Redes e Criptografia”, deste mesmo autor (UCHÔA, 2003). Joaquim Quinteiro Uchôa, autor deste texto, é licenciado em Matemática pela Universidade Federal de Mato Grosso (UFMT), com mestrado em Ciência da Computação pela Universidade Federal de São Carlos (UFSCar). Antes de adotar o Linux, em 1998, já havia trabalhado com Solaris, MS-DOS (lembram-se do CISNE?) e OS/2, passando, obviamente pelos Windows 2.0, Windows 3.1 (e 3.11) e Windows 95. Segundo amigos, ele já superou o trauma do uso desses três últimos SOs(?), apesar de ter desenvolvido aversão a alguns tipos de janelas. Foi o responsável pela instalação do primeiro laboratório baseado em Linux na UFLA e um dos maiores disseminadores desse sistema operacional na universidade. Professor da UFLA desde 1997, atua principalmente nas áreas de Teoria da Computação e Inteligência Artificial. O autor espera que a escrita desta obra contribua para disseminar ainda mais o uso de Linux no Brasil, bem como para um ambiente computacional mais seguro, desejando um bom aprendizado ao leitor.

1 Um

Howto é um pequeno guia que ensina um usuário a configurar um serviço ou fazer uma dada tarefa. Linux Documentation Project: http://www.tldp.org/. A tradução de parte dos documentos desse projeto podem ser encontrados em http://br.tldp.org/. 2 The

2 CONCEITOS BÁSICOS

2.1

COMENTÁRIOS INICIAIS

O que é segurança computacional? Esse termo é muito utilizado atualmente, mas sem uma consciência exata a que ele se refere. Isso ocorre principalmente porque esse conceito é relativo ao ambiente em que é utilizado. O que é seguro para uma instituição pode não o ser para outra. Assim, é preciso estar atento a qual siginificado o termo está sendo utilizado. Dada a relatividade do termo, é preciso refletir sobre quais itens devem ser levados em conta ao se abordar a questão da segurança computacional. Em geral, é possível destacar os seguintes elementos de um ambiente computacional, sob o ponto de vista da segurança: Confiança: é possível confiar na disponibilidade do sistema? os dados armazenados vão estar acessíveis quando forem necessários? os mecanismos de backups são suficientes para garantir que as informações armazenadas possam ser recuperadas com facilidade em caso de problemas? Integridade: os dados recuperados são confiáveis? como garantir que as informações não foram alteradas na fonte ou no tráfego de dados? como garantir que o que foi acessado é idêntico ao que foi armazenado? Confidencialidade: como certificar que os dados só podem ser acessados por quem de direito? como garantir a privacidade dos usuários e dos dados? como impedir a espionagem de informações? Essas questões irão chamar a necessidade do administrador estar refletindo: “o que é segurança computacional em meu ambiente”? A essa questão, logo virá outra, talvez de maior importância: qual o item mais importante para a segurança computacional: • firewalls? • backups? • anti-sniffers? • tunelamento e criptografia?

EDITORA - UFLA/FAEPE - Segurança Computacional

A resposta a essa pergunta é extremamente simples: o elemento mais importante para se garantir segurança em uma rede de computadores é o estabelecimento de uma política de segurança. Enquanto a instituição não define o que é mais importante para o estabelecimento da segurança computacional em seu ambiente, as atitudes são tomadas sem a devida consciência e sem garantir um mínimo desejável de segurança: Uma Política de Segurança incorpora os resultados de uma análise de risco em um plano que providencia procedimentos para gerenciar um ambiente computacional. Em particular, ela fornece ao administrador do sistema linhas operacionais para o ambiente, tais como regras para o gerenciamento de contas de usuários, procedimentos de instalação de sistemas ... (MANN; MITCHELL, 2000) Uma política de segurança é um conjunto de leis, regras e práticas que regulam como uma organização gerencia, protege e distribui suas informações e recursos. Um dado sistema é considerado seguro em relação a uma política de segurança, caso garanta o cumprimento das leis, regras e práticas definidas nessa política. (SOARES; LEMOS; COLCHER, 1995)

É a política de segurança que vai deixar claro o que deve ter acesso restrito e o que pode ser liberado sem problemas. É ela que define quais são os itens que precisam ser preservados, bem como quais são as pessoas que tem acesso a determinados recursos. Sem uma política de segurança clara, não se sabe o que vai se proteger, nem porque ou qual a melhor forma. Uma boa política de segurança irá definir, por exemplo, como será estabelecida a política de uso. Essa política de uso é responsável por deixar claro o que o usuário pode e não pode fazer com determinados recursos. Em geral, tal política é um documento a ser assinado pelo usuário em questão. 2.1.1

Políticas de Segurança e Políticas de Uso

É inútil elaborar uma política de segurança que sirva apenas de enfeite na parede. Assim, uma política de segurança deve possuir as seguintes características: • ser implementável através de procedimentos de administração de sistema, regras de uso, ou outros métodos apropriados; • ser reforçada com ferramentas de segurança e sanções; • definir claramente as áreas de responsabilidade para usuários e administradores do sistema.

Conceitos Básicos

Dessa maneira, atentando-se para essas diretrizes, é possível elaborar uma política de segurança válida para o ambiente em questão. Além disso, é imprescindível que a política de segurança atente-se para os seguintes itens: Segurança física: como os equipamentos da instituição em questão serão protegidos? Como garantir a integridade física dos dados? Como garantir que não haverá acesso físico a dados que deveriam estar protegidos? Esse item é mais importante do que se imagina: de nada adianta senhas de BIOS ou ultra-elaboradas, se qualquer funcionário recém demitido pode roubar o HD do servidor para vender ao concorrente. Segurança lógica: como garantir integridade lógica dos dados? Como os dados da instituição em questão serão protegidos? Como garantir que não haverá acesso lógico indevido a dados? Quais são os dados mais importantes? Os casos de invasões tem-se tornado cada vez mais freqüentes e é imprescindível estar atento a isso. Privacidade: o que fazer para proteger a privacidade dos usuários? A instituição irá proteger essa privacidade? Observe que a instituição deve estar atenta aos aspectos legais dessa questão. Legalidade de Software: como garantir um bom uso dos recursos, impedindo a pirataria? A responsabilidade pelos aplicativos instalados é de quem? da empresa? do usuário? Isso precisa estar claro. Em geral, quando se trata de segurança computacional deve-se adotar a política do menor privilégio, ou seja, liberar apenas os recursos necessários ao usuário. Observe que, em alguns ambientes, essa é uma questão altamente subjetiva. Mas deve-se sempre ter em mente que o que não é expressamente permitido deve ser proibido. Além disso, é imprescindível que o administrador pratique vigilância e perseverança, assumindo sempre que os mal-intencionados sabem mais que ele. Tenha em mente que a adoção de uma política de segurança irá, na maioria das vezes, implicar em perda de performance ou conveniência do usuário. Alguns serviços devem ser evitados e isso gera problemas para usuários mais inexperientes. Além disso, o tráfego criptografado ocupa maior largura de banda, diminuindo a velocidade de transmissão de dados. Assim, deve-se pesar os prós e contras de qualquer atitude envolvendo segurança antes de implementá-la. Em termos práticos, como é expressa a política de segurança? O leitor deve estar pensando em documentos impressos. Entretanto não se deve esquecer que a política não é apenas papel: ela envolve leis, regras e práticas. Dependendo do ambiente, é óbvio a necessidade de documentação, mas isso não é a única forma de criar uma política de segurança. Em geral, a política de segurança documentada da maior parte das instituições consiste das normas de uso dos recursos e uma política de uso. A política de uso é um documento que deixa claro o que o usuário pode e não pode fazer com os recursos dentro da

EDITORA - UFLA/FAEPE - Segurança Computacional

instituição. Para garantir validade jurídica desse documento, é imprescindível a sua validação pela assinatura do usuário ou em contrato coletivo de trabalho.

2.2

CRIME VIRTUAL

Outra questão fundamental que está relacionada à questão da segurança computacional é o conceito de crime virtual. Nesse sentido é imprescindível distinguir, ao menos em termos práticos, os conceitos de crime de computador e crime por computador. Essa distinção permite compreender melhor quais tipos de crime são cobertos pela lei e quais não o são. Assim, crime por computadores são os crimes tradicionais cometidos por meios computacionais. Dessa maneira, por exemplo, tipificam-se o roubo ou o assassinato por computador. O leitor atento pode estar um pouco assustado agora, imaginando como poderia ser possível um assassinato por computador, esquecendo-se que o assassino poderia invadir o sistema computacional de um hospital, por exemplo, e alterar a medicação de um paciente para doses fortes de substâncias a que ele tenha alergia. É comum, portanto, a ocorrência de crimes tradicionais efetuados por computador, sem que o autor desses crimes esteja atento ao fato de estar cometendo um crime já previsto na lei tradicional. O envio de determinados tipos de SPAMs, por exemplo, já está previsto na lei e pode render detenção de 3 meses a 1 ano de detenção ou multa, conforme o Art. 146 do Código Penal (BRASIL, 1940). Enviar e-mail com ameaça de agressão pode render pena de 1 a 6 meses de detenção ou multa, de acordo com o Art. 147. Assim, observe que apenas modificou-se o meio, o crime continua tipificado. De forma semelhante, são tipificados crimes de invasão de privacidade, envio de vírus de computador, pedofilia ou montagem de sites com receitas de bombas ou similares. Por outro lado, existem aqueles crimes que só existem no ambiente computacional, não existindo equivalente no ambiente não tecnológico: são os crimes de computador. Nesse contexto, por exemplo, o Brasil não tem uma legislação contra invasão de sites. Quando o invasor não faz uso de informações obtidas com essa invasão (o que poderia caracterizar espionagem industrial) ou não faz alterações dos dados (o que poderia caracterizar crime de dano, vandalismo ou pichação), fica difícil caracterizar a invasão como uma contravenção penal. Alguns países possuem legislação forte a esse respeito, como é o caso dos EUA e da China. No Brasil, paraíso dos invasores, essa discussão está apenas no início. Mesmo assim, o administrador que teve seus sistemas invadidos deve verificar os mecanismos legais a que pode recorrer de forma a punir os autores da façanha. Nesse contexto, inclusive, cabe chamar a atenção para os movimentos Hackers e Ciberativismo. Cabe também chamar a atenção para o fato que o termo hacker não costuma

Conceitos Básicos

ser utilizado com sentido negativo em meio tecnológico. Nesse ambiente, utiliza-se o termo cracker para os hackers que invadem sistemas com finalidades ilícitas. Na cultura geral, entretanto, o termo hacker é tomado de forma indistinta, geralmente com significado pejorativo para invasor. Para uma abordagem mais formal sobre essa discussão, ver (UCHÔA, 2003).

2.3

ATAQUES MAIS COMUNS

Como um servidor encontra-se geralmente acessível via internet e em tempo integral, ele é mais suscetível a ataques de todos os tipos e formas que uma estação de trabalho. Dependendo de sua configuração, entretanto, é possível torná-lo tão ou mais seguro que estações de trabalho com acesso mínimo à internet. Com a finalidade de melhor situar o leitor, segue-se uma relação dos principais tipos de ataque e termos correlatos: Footprinting: Por footprinting entende-se a tarefa de coletar informações sobre um sistema alvo. Essa coleta é feita por vias tradicionais e públicas, como uso do comando finger, leitura de páginas do site para obter dados interessantes, etc. Geralmente o invasor irá verificar quem é o responsável pela admnisitração do sistema, uma vez que invadida a conta desse usuário é possível obter dados mais significativos. Scanning: Um scanner é um utilitário que verifica vulnerabilidades. Pode ser um scanner de sistema, quando checa vulnerabilidades na máquina local (erros no /etc/passwd, permissão incorreta de arquivos, etc.), ou pode ser um scanner de rede, quando faz varredura de portas de redes, verificando quais estão abertas e, principalmente, quais estão mais vulneráveis. O objetivo principal desse tipo de ataque é descobrir falhas de segurança devido a bugs em serviços de rede ou ausência de proteção para serviços internos. Sniffers: Principalmente dentro de uma rede física, onde é facilitada, um ataque muito utilizado é a espionagem eletrônica, com o uso de sniffer. Um sniffer é um aplicativo que fica “escutando” todos os pacotes de dados que trafegam por uma dada placa de rede. É importante observar que, em várias topologias de rede, um pacote passa por várias placas entre a origem e o destino. Além disso, cabe observar que, para que interceptar mensagens destinadas à outras máquinas, a estação deve colocar sua interface de rede em “modo promíscuo”1 . Esse ataque objetiva principalmente a captura de senhas de usuários internos, uma vez que isso facilita ao invasor a entrada no sistema para detecção de vulnerabilidades. Outro objetivo desse ataque é a captura de informações confidenciais em trânsito na rede. 1 Por

“modo promíscuo” entende-se a configuração de uma interface de rede em que ela captura não apenas os pacotes de rede direcionados a ela, mas também os destinados a outras estações em um mesmo segmento de rede.

EDITORA - UFLA/FAEPE - Segurança Computacional

Spoofing: Por spoofing entende-se a tarefa de fazer uma máquina se passar por outra, forjando, por exemplo, pacotes IPs. Em geral, o usuário irá tentar bloquear o envio de pacotes de dados de uma máquina, tentando se passar por ela. Uma conexão SSH com um máquina usando spoof iria acusar o ataque do Man-In-The-Middle, já comentado em (UCHÔA; SIMEONE; SICA, 2003). Caso o administrador use transporte criptografado de dados e senhas e esteja atento às chaves utilizadas, esse ataque dificilmente irá comprometer a integridade dos dados e serviços. Denial of Service (DoS): Pouca atenção tinha sido dado aos ataques de negação de serviço até a derrubada de servidores importantes, como Amazon, Yahoo e mesmo UOL. Como pode ser subentendido, o DoS é um ataque que busca derrubar um serviço ou mesmo um servidor inteiro. Ultimamente tem sido utilizado do DDoS (Distributed DoS), onde um atacante utiliza várias máquinas “zumbis” para enviar inúmeras requisições, ao mesmo tempo e de forma sincronizada, a um dado servidor. Isso acaba por ou consumir grande parte da largura de banda de rede ou sobrecarregar um dado daemon, derrubando-o. Mais recentemente, pode-se comentar o caso do vírus do Apache, que fazia com que um dado servidor Web ficasse enviando grande quantidade de dados pela rede, conduzindo o tráfego de rede a uma lentidão insuportável. Código Malicioso: Código malicioso, como o nome já sugere, é um software criado com finalidades mal intencionadas. Nessa categoria incluem-se os códigos não autorizados (geralmente contidos dentro de um programa legítimo) que efetuam ações desconhecidas e não desejadas pelo usuário. Também são incluídos nessa categoria os programas legítimos que foram alterados para efetuar ações não desejadas pelo usuário. Outro tipo de código malicioso são aqueles que destroem dados sem a intenção do usuário. Alguns tipos de código maliciosos merecem destaque: • Cavalos de Tróia: Um cavalo de tróia, ou trojan horse ou apenas trojan é um programa de computador alterado com finalidades ilícitas. Por exemplo, um atacante poderia substituir o /bin/login para não só autenticar usuários, como também armazenar essas senhas em um arquivo oculto. • Vírus: Vírus são semelhantes a trojans, dado que efetua ação não desejada pelo usuário. Uma das diferenças reside no fato que o vírus, uma vez ativado, irá infectar outros arquivos locais. A grosso modo, vírus não podem infectar máquinas externas sem o auxílio de uma pessoa. • Vermes: Um verme é um programa que pode infectar tanto a máquina local, quanto máquinas remotas, geralmente utilizando falhas de protocolos, serviços ou aplicativos. Como observado por (HATCH; LEE; KURTZ, 2002), a maior parte dos programas perniciosos existentes são híbridos dessas três categorias. Como exemplo, tem-se o Melissa que era um cavalo de tróia (se passava por um e-mail que o usuário estivesse

Conceitos Básicos

esperando), um vírus (infectava todos os arquivos locais de processamento de texto) e um verme (usava uma falha do Outlook para se propagar a todos os usuários na agenda de endereços do usuário). Observe que, no senso comum, vírus e verme são geralmente tomados com um único significado, sendo usado apenas o termo “vírus”. Por exemplo, o vírus do Apache era, a bem da verdade, um verme (se propagava a outras máquinas usando o Apache), mas como não infectava outros arquivos no servidor, não poderia ser considerado necessariamente um vírus. Um tipo de trojan extremamente perigoso são os rootkits. Como o nome sugere, um rootkit é um aplicativo (ou um conjunto de aplicativos) com o objetivo de garantir poderes de root ao invasor. Geralmente consiste de aplicativos alterados a funcionar de forma especial pelo usuário ou versões alteradas do próprio kernel. Exploits: Exploits são programas criados para explorar falhas, advindas principalmente de bugs nos daemons de serviços. Entre as falhas mais exploradas, encontram-se buffer overflow, que consiste em estourar o buffer de entrada de um servidor, forçando-o a estourar sua memória, devolvendo um shell para o invasor. Ataques de Senhas: Esse tipo de ataque consiste em tentar descobrir a senha de um ou mais usuários por força bruta ou usando técnicas heurísticas. Em geral, o invasor tenta obter uma cópia das senhas e efetuar um ataque de dicionário: utilizando variações de palavras em uma dada lista (o dicionário), tenta-se confrontar a senha do usuário com essas variações até descobrir uma que permita o acesso. Uma observação final é que determinados ataques são a bem da verdade também ferramentas de segurança. Assim, por exemplo, um scanner pode ser utilizado para verificar em que pontos um sistema está vulnerável. Um programa de ataque de senha pode ser utilizado para checar se os usuários não estão utilizando senhas fáceis, o que facilitaria uma invasão. Além disso, alguns sistemas poderosos de detecção de intrusos são também sniffers. Sniffers também costumam ser utilizados para detectar problemas em uma rede.

EDITORA - UFLA/FAEPE - Seguranรงa Computacional

3 USO DE CRIPTOGRAFIA

3.1

CONCEITOS BÁSICOS

A rápida evolução das comunicações eletrônicas suscitou uma série de necessidades para que se evitassem problemas de espionagem. Entre essas necessidades, destaca-se o uso de sistemas criptográficos. Mesmo em ambientes de telefonia celular, por exemplo, o uso de criptografia é cada vez mais utilizado. Como definido em (SCHNEIER, 1996), a criptografia é a arte e ciência de manter mensagens seguras. Ela envolve dois processos: 1) criptografar (ou cifrar) uma mensagem M, transformando-a em um texto cifrado C e 2) posteriormente decifrar (ou decriptografar) C, obtendo novamente a mensagem M, como ilustrado na Figura 3.1 Mensagem (M)

Encriptação ou Cifragem

Texto Cifrado (C)

Decriptação ou Decifragem

Mensagem (M)

Figura 3.1: Processos Criptográficos

A criptografia possui estrita relação com a criptoanálise, arte e ciência de quebrar mensagens cifradas. O ramo da Matemática envolvendo criptografia e criptoanálise é chamado de criptologia. Como bem observado em (SCHNEIER, 1996), modernos criptológos precisam ter domínio em Matemática Teórica, uma vez que é sobre ela que se sustenta a criptologia atual. O uso da criptografia é antigo, sendo comuns o seu uso em guerras, mesmo desde o império romano. Esse uso era principalmente para manter a confidencialidade da mensagem, garantindo que apenas emissor e receptor pudessem interpretá-la. De certa maneira, a computação foi fortemente financiada durante a Segunda Guerra Mundial para invenção de dispositivos que pudessem decodificar as mensagens dos alemães. Desse esforço, inclusive, participou Alan Turing, um dos mais importantes teóricos da Computação e um dos pais da Inteligência Artificial.

EDITORA - UFLA/FAEPE - Segurança Computacional

Mas o uso da criptografia não se restringiu à confidencialidade. Cada vez mais novos usos da criptografia se fazem necessário, sendo essencial para o comércio eletrônico. Entre os usos da criptografia, além da confidencialidade, destacam-se (SCHNEIER, 1996): Autenticação: é importante para o receptor da mensagem ter certeza que o autor da mensagem é quem diz sê-lo; dessa maneira, um invasor não pode se passar por outra pessoa. Integridade: é essencial garantir que a mensagem não foi alterada durante seu trânsito; dessa maneira, um invasor não pode substituir uma mensagem legítima por uma falsa. Autoria: em determinadas mensagens, como o uso de dinheiro eletrônico, é essencial garantir que quem envia a mensagem não possa negar que tenha feito isso em um momento posterior ao envio.

3.2

ALGORITMOS CRIPTOGRÁFICOS

Um algoritmo criptográfico, também denominado cifra, é uma função matemática usada para criptografar ou decriptografar uma mensagem. Em geral, são utilizadas duas funções relacionadas, uma no processo de cifragem (E) e outra na decifragem (D) de uma mensagem M:

E(M) = C D(C) = M Às vezes, a única segurança de um algoritmo criptográfico reside em sua obscuridade, ou seja, o desconhecimento de seu teor por terceiros. Essa segurança é restrita e deve ser evitada para usos mais sérios da criptografia. O motivo é que técnicas não avançadas de criptoanálise e engenharia reversa podem quebrar facilmente essa segurança. Para evitar esse problema, a criptografia moderna faz o uso de chaves. Assim, utilizando-se uma chave K, o processo de cifragem e decifragem de uma mensagem torna-se:

EK (M) = C DK (C) = M Quando a chave utilizada na encriptação da mensagem é idêntica à utilizada na decriptação, diz-se que o algoritmo utiliza chaves privadas ou que é um algoritmo simétrico. Observe que isso exige que o receptor da mensagem conheça a chave utilizada pelo emissor. Isso pode complicar o processo criptográfico, uma vez que se a chave for descoberta por um invasor, a confiança na mensagem é perdida.

Uso de Criptografia

Entre os algoritmos simétricos mais conhecidos e utilizados merecem destaque o DES (Data Encryption Standard), o Blowfish e o IDEA (International Data Encryption Algorithm). O IDEA é patenteado, mas pode ser utilizado sem restrição para uso não-comercial, sendo utilizado no PGP. Já o DES e o Blowfish são algoritmos de domínio público. O DES é muito utilizado em uma versão alternativa que utiliza três chaves, o 3DES. O OpenSSH utiliza principalmente 3DES ou Blowfish para criptografar o trânsito de dados. Blowfish foi desenvolvido por Bruce Schneier, que descreve em detalhes esses e outros algoritmos simétricos em (SCHNEIER, 1996). Já nos algoritmos assimétricos, também chamados de algoritmos de chave pública, são utilizadas duas chaves: uma para criptografar e outra para decriptografar a mensagem. Graças a processos matemáticos, é possível escolher chaves de tal forma que o conhecimento de uma não signifique que a outra chave possa ser descoberta, ao menos em termos práticos. Assim, a chave para criptografar é posta em público sem nenhum problema e somente o possuidor da chave privada pode ler a mensagem. Outra forma de uso desse algoritmo é tornar a chave de decifragem pública e a chave de cifragem é mantida em segredo. Com isso, tem-se a garantia que somente aquela pessoa poderia ter criptografado determinada mensagem, o que corresponde a um processo de assinatura digital. Entre os algoritmos de chave pública, o mais conhecido é com certeza o RSA, que caiu em domínio público em setembro de 2000. Entre as alternativas mais conhecidas, encontram-se o ElGamal e o DSA, que são utilizados pelo GnuPG, um aplicativo para criptografia e assinatura digital de uso pessoal.

3.3

PROTOCOLOS CRIPTOGRÁFICOS

Um protocolo é uma série de passos, envolvendo duas ou mais partes, designado para a realização de uma tarefa (SCHNEIER, 1996). Um protocolo criptográfico é um protocolo que usa criptografia. Um protocolo criptográfico envolve o uso de algoritmos criptográficos, mas não se restringe a isso. Um protocolo pode envolver vários outros passos, como mecaniscos de contato entre emissor e receptor e troca de chaves. Um exemplo conhecido de protocolo criptográfico é o protocolo de rede SSL (Secure Socket Layer). Esse protocolo foi criado pela Netscape para disponibilização de sites protegidos, tendo seu uso estendido a outras àreas. É talvez o protocolo criptográfico mais utilizado atualmente. Uma implementação bastante conhecida do SSL no contexto do software livre, é a OpenSSL (http://www.openssl.org/). Essa biblioteca implementa as versões 2 e 3 do SSL, bem como a versão 1 do TLS (Transport Layer Security). O TLS é um protocolo criado recentemente para substituir o SSL, ampliando seu uso e funcionalidade, sendo descrito

EDITORA - UFLA/FAEPE - Segurança Computacional

em (DIERKS; ALLEN, 1999). O uso do SSL em serviços WEB é detalhado no Capítulo 5 de (UCHÔA; SIMEONE; SICA, 2003). Outro protocolo criptográfico muito utilizado no mundo UNIX é o SSH, utilizado para conexões remotas seguras. O SSH possui várias implementações, algumas comerciais. Entre as de código aberto, merece destaque a OpenSSH (http://www.openssh.org/). A OpenSSH permite a substituição do Telnet com vantagens, além de oferecer outros serviços, como o sFTP (Secure FTP), um FTP seguro. O uso da OpenSSH foi descrito no Capítulo 8 de (UCHÔA; SIMEONE; SICA, 2003). Os protocolos SSH e SSL funcionam de uma maneira parecida: inicialmente é feita uma conexão usando algoritmos de chave pública. Após isso, são trocadas chaves criadas aleatoriamente usando esses algoritmos. Após a troca dessas chaves, o tráfego é feito utilizando algoritmos de chave privada, uma vez que exigem menor esforço computacional.

3.4

CRIPTOGRAFIA E SEGURANÇA COMPUTACIONAL

A criptografia exerce papel essencial na segurança computacional. Isso porque ela pode auxiliar significativamente na garantia de confidencialidade e integridade de dados. No contexto do Linux, a criptografia pode ser utilizada de várias formas, desde o aspecto de uso pessoal até a implementação de VPNs (Virtual Private Networks - Redes Privadas Virtuais). No campo da criptografia pessoal, merece destaque o GnuPG (GNU Privacy Guard), uma versão aberta do PGP (Pretty Good Privacy). O GnuPG implementa mecanismos de cifragem de dados e assinaturas digitais, estando em conformidade com o padrão OpenPGP, descrito em (CALLAS et al., 1998). É importante ressaltar que o GnuPG implementa apenas algoritmos não patenteados, ao contrário do PGP. Isso garante a total liberdade do projeto. O GnuPG possui uso extremamente simples, sendo que a maioria dos clientes de email possuem integração direta com ele. O principal utilitário disponibilizado pelo GnuPG é o gpg, sendo que suas opções mais usadas são listadas na Tabela 3.1. Mais detalhes sobre o GnuPG podem ser encontrados na documentação do pacote, executando-se o comando “gpg -help” ou em (MOLLARD, 2002). Um uso importante da assinatura digital é a garantia de fonte de um dado aplicativo. Os gerenciadores de pacotes rpm ou deb possuem opções para conferir se o autor de um pacote é quem afirma ser. Isso é extremamente importante para garantir a integridade de um aplicativo sendo instalado, evitando que se instale trojans ou rootkits inocentemente. Em geral, as distribuições disponibilizam chaves públicas para conferir a autenticidade dos pacotes distribuídos por elas. Caso se pretenda criptografar não só um arquivo mas todo um diretório, então o uso de sistemas de arquivos criptografados pode ser uma ótima escolha. Existem vários pro-

Uso de Criptografia

Tabela 3.1: Opções Mais Usadas do gpg

Opção

Descrição

- -sign - -encrypt - -decrypt - -edit-key - -genkey - -list-key - -list-sigs - -sign-key - -import - -export - -armor

assina um arquivo criptografa dados descriptografa dados assina ou edita uma chave armazenada gera um novo par de chaves lista chaves armazenadas lista chaves e assinaturas armazenadas assina uma chave armazenada importa uma chave exporta uma chave força exportação de chaves em modo texto

jetos nessa filosofia, merecendo destaque o CFS, disponível em http://www.crypto. com/software, e o TCFS, disponível em http://www.tcfs.it/. Detalhes de uso desses aplicativos podem ser encontrados na documentação desses pacotes e em (MANN; MITCHELL, 2000). Quanto ao transporte de dados, a criptografia tem sido usada sob a forma de túneis criptográficos. São exemplos desses túneis os protocolos SSL e SSH. Vários serviços podem ser tunelados utilizando esses protocolos. A documentação do SGBD PostgreSQL (em especial o manual do administrador), por exemplo, apresenta exemplos de tunelamento usando SSL ou SSH. Um aplicativo extremamente útil no contexto de túneis criptográficos é o stunnel, disponível em http://stunnel.mirt.net/. O stunnel foi projetado para trabalhar como um túnel criptográfico usando SSL entre clientes e servidores de serviços padrões. Dessa maneira, o stunnel pode ser usado para adicionar funcionalidade SSL a aplicações comuns que sejam gerenciadas pelo inetd ou xinetd. É dessa maneira que costumam ser implementados IMAP e POP seguro em Linux. O conceito extremo de tunelamento criptográfico é utilizado pelas VPNs. Uma rede privada virtual consiste em um túnel criptográfico entre duas ou mais redes tendo o tráfego em ambiente público, como ilustrado na Figura 3.2. Nesse caso, praticamente quase todo o tráfego entre as duas redes é criptografado. Para se implementar uma VPN, várias alternativas são possíveis. É possível utilizarse apenas de PPP e SSH, como ilustrado em (WILSON, 1999). Mas também é possível utilizar-se do protocolo IPSec, implementado no FreeS/WAN (http://www.freeswan.

EDITORA - UFLA/FAEPE - Segurança Computacional

Túnel Criptográfico Internet

Figura 3.2: Conceito de VPN

org/). Nesse caso todo o tráfego IP entre duas redes é criptografado. Outra alternativa com a mesma filosofia do IPSec é o CIPE, disponível em http://sites.inka.de/sites/ bigred/devel/cipe.html. Consulte as páginas desses projetos para maiores detalhes.

4 SEGURANÇA POR CONTROLE DE ACESSO

4.1

COMENTÁRIOS INICIAIS

Até pouco tempo atrás, a segurança de redes era baseada principalmente em controle de acesso. Definir as permissões para cada usuário, estabelecer uma rede de confiança entre máquinas e usuários, usar serviços autenticados por senha eram atitudes que tornavam redes suficientemente seguras. Atualmente as redes de confiança já não garantem segurança, pois o tráfego nãocriptografado facilita a escuta de dados (sniffing), que tornou-se comum. Dessa forma, houve um crescente uso da criptografia, em especial o uso de túneis criptográficos, abordados no Capítulo 3. Entretanto, novos mecanismos de segurança por controle de acesso surgiram, com o objetivo de proteger não os dados em si, mas sim o servidor, evitando invasões. Incluem-se nesses novos mecanismos o desenvolvimento crescente de novas ferramentas de firewall, por exemplo. Dessa maneira, este capítulo aborda as principais técnicas e ferramentas para uma adequada segurança por controle de acesso.

4.2

SEGURANÇA FÍSICA E BACKUPS

Segurança física é muitas vezes menosprezada. Entretanto, ainda é um item essencial para um ambiente computacional. Afinal, de nada adianta um servidor estar utilizando mecanismos poderosos de firewall se um visitante qualquer pode roubar seu disco rígido ou mesmo o servidor inteiro. Assim, uma sala protegida é muito melhor que senhas de BIOS ou de boot loaders, como LILO ou GRUB. O motivo de não se confiar em senhas de BIOS ou de boot loaders é que esses mecanismos não impedem o acesso aos dados do servidor. Senhas de BIOS podem ser burladas com relativa facilidade ou mesmo apagadas. Por outro lado, é possível iniciar uma máquina a partir de outro dispositivo (um disquete, CD-ROM, outro disco rígido, etc.) e acessar os dados armazenados. Sistemas de arquivo criptografados dificultariam o acesso a esses

EDITORA - UFLA/FAEPE - Segurança Computacional

dados, mas são mais lentos que os tradicionais e ainda não encontram-se difundidos a contento. Outra questão importante nesse mesmo contexto é a necessidade de uma política efetiva de cópias de segurança. Sem backups periódicos, um sistema não atende aos critérios mínimos de disponibilidade dos dados. Em determinados ambientes, por exemplo, esse é um item extremamente crítico na administração de servidores. Projetos recentes têm inclusive surgido no contexto extremo de cópias de segurança. Cada vez mais surgem estratégias de “Alta Disponibilidade”, que consistem em mecanismos para fazer com que um dado serviço esteja online o maior tempo possível. Nesse caso, são utilizados servidores redundantes, sincronização de dados online, entre outras técnicas. Uma pergunta deve estar rondando a cabeça do leitor: qual a melhor ferramenta e estratégia de backup? A resposta clara e efetiva é: depende. Não existe uma ferramenta adequada a todas as situações e muito menos uma estratégia funcional para todas as instituições. Dessa maneira, o administrador terá que não só escolher a ferramenta, como também escolher o procedimento que será utilizado nesse processo. Para definir essa ferramenta e a estratégia, algumas perguntas devem ser respondida: quão importantes são os dados armazenados? a perda deles implicaria em quanto tempo de prejuízo para serem restaurados? As respostas a essas perguntas podem indicar claramente as necessidades, em termos de cópia de segurança, por parte da instituição.

4.3

O USO DE TCP-WRAPPERS

Vários daemons, ao invés de serem inicializados por seus próprios meios, são gerenciados pelo tcpd. Nesse caso, é possível filtrar os pacotes direcionados aos serviços oferecidos por esses daemons usando os TCP-Wrappers. Esses filtros consistem de duas frentes, como ilustrado na Figura 4.1: os arquivos /etc/hosts.allow e /etc/hosts.deny e a configuração do inetd ou do xinetd. O xinetd é um substituto poderoso do inetd. Dessa maneira, este texto não irá abordar o uso do inetd. É importante observar que nem todas as aplicações podem ser inicializadas via xinetd ou inetd. Além disso, algumas poucas aplicações que não são controladas por esses serviços, podem ser filtradas pelo uso dos arquivos hosts.allow e hosts.deny no diretório /etc/. Mas, em geral, utiliza-se esses arquivos apenas para essas aplicações. Com o xinetd, inclusive, é possível não utilizar esses arquivos para obter os mesmos resultados. Observe que, de certa forma, os serviços oferecidos pelos TCP-Wrappers equivalemse a um tipo de firewall. Entretanto, existe o fato de que esse firewall é restrito às aplicações com suporte à biblioteca libwrap. Ainda: em geral é possível obter os mesmos efeitos

Segurança por Controle de Acesso

Servidor

Clientes telnet

syslogd configuração do xinetd ou inetd

in.telnetd

finger

in.imapd imap

ftp rsync

xinetd ou inetd

tcpd

hosts.allow e hosts.deny

in.fingerd in.ftpd in.popd

Figura 4.1: Uso de TCP-Wrappers

obtidos com os TCP-Wrappers utilizando-se ferramentas de firewall integradas ao kernel, como iptables ou ipchains. Mesmo assim, seu uso é recomendado, por fornecer uma camada extra de proteção aos serviços. Como já comentados, os TCP-Wrappers são implementados pelo servidor tcpd. Eles controlam o acesso baseado em IP, estando, portanto, sujeitos a spoofing. O acesso a um cliente é feito da seguinte forma: 1. o acesso é garantido quando um par (serviço, cliente) casa uma entrada no arquivo /etc/hosts.allow; 2. o acesso é negado quando um par (serviço, cliente) casa uma entrada no arquivo /etc/hosts.deny; 3. caso não esteja permitido ou negado nos passos anteriores, o acesso é garantido. Dessa maneira, é possível filtrar efetivamente os serviços gerenciados via tcpd. Em geral, dada essa seqüência de passos adotada pelo tcpd, é costume negar todos os serviços no arquivo /etc/hosts.deny, como ilustra a Figura 4.2. Dessa forma somente obterão acesso aos serviços os clientes habilitados no arquivo /etc/hosts.allow, exemplificado na Figura 4.3. Uma observação a ser feita é que os dois arquivos são configurados de forma semelhante, usando a mesma sintaxe. Note que, na Figura 4.3, é possível habilitar uma mensagem inicial de login (um banner) para serviços habilitados aos TCP-Wrappers. Dessa maneira, de acordo com o exem-

EDITORA - UFLA/FAEPE - Segurança Computacional

# arquivo hosts.deny # nega-se tudo (ALL indica todos os serviços ou todos os clientes) ALL : ALL

Figura 4.2: Exemplo de Arquivo /etc/hosts.deny # arquivo hosts.allow # habilitando acesso ftp a determinadas redes in.ftpd: 192.168., 211.221.11.0/255.255.255.128, .meudominio.com # habilitanto finger a máquinas específicas in.fingerd: tom, jerry, frajola, pernalonga, patolino # habilitando acesso ftp, mas exibindo um banner antes in.ftpd: ALL: banners /etc/security/ftp.banner # habilita telnet, com exceção da máquina superman in.telnetd: ALL EXCEPT superman

Figura 4.3: Exemplo de Arquivo /etc/hosts.allow

plo dessa figura, é possível editar o arquivo /etc/security/ftp.banner para imprimir uma mensagem de alerta quando iniciar uma conexão FTP. O xinetd e o inetd podem ser entendidos como superservidores que chamam outros servidores através do tcpd. Assim, além dos arquivos /etc/hosts.allow e /etc/ hosts.deny, é possível efetuar filtragem de serviços na configuração desses superservidores. A configuração do xinetd é feita inicialmente no arquivo /etc/xinetd.conf, exemplificado na Figura 4.4. Em geral, como mostra a Figura 4.4, o arquivo /etc/xinetd.conf contém apenas as configurações padrões do xinetd (tipo de log, etc.) e uma diretiva para incluir os arquivos no diretório /etc/xinetd.d. Dessa maneira, para facilitar a configuração, cada serviço é configurado em um arquivo específico nesse diretório. A Figura 4.5 mostra um exemplo de serviço configurado dessa forma. No caso da Figura 4.5, é possível perceber o uso da diretiva only_from para limitar o acesso a determinados serviços para determinadas máquinas ou redes. Dessa maneira, estabelece-se mais uma barreira para impedir acesso não autorizado a determinados serviços.

Segurança por Controle de Acesso

# xinetd.conf # configurações padrões defaults { instances log_type log_on_success log_on_failure cps }

= = = = =

60 SYSLOG authpriv HOST PID HOST 25 30

# inclui configurações no diretório /etc/xinetd.d includedir /etc/xinetd.d

Figura 4.4: Exemplo de Arquivo /etc/xinetd.conf # /etc/xinetd.d/finger service finger { disable = no socket_type = stream wait = no # usuário com o qual o servidor é inicializado user = nobody server = /usr/sbin/in.fingerd # quais IPs podem conectar (todos iniciando com 192.168) # ou na rede 200.100.10.0/255.255.255.0 only_from = 192.168.0.0 200.100.10.0/255.255.255.0 }

Figura 4.5: Exemplo de Arquivo /etc/xinetd.d/finger

4.4

USO DE FIREWALLS OU PROXIES

Uma das formas mais conhecidos para implementar segurança por controle de acesso é o uso de firewall. Chega a se dar tamanha importância aos firewalls que é muito comum encontrar administradores que se esquecem dos outros elementos necessários a um ambi-

EDITORA - UFLA/FAEPE - SeguranĂ§a Computacional

ente seguro. Nesse sentido, ĂŠ importante alertar que um bom firewall tem grande potencial para a seguranĂ§a mas nĂŁo ĂŠ seu elemento Ăşnico e muito menos o mais importante. Em determinadas situaĂ§Ăľes, inclusive, seu uso pode nem ser necessĂĄrio. Existem vĂĄrias definiĂ§Ăľes possĂveis para o termo firewall. O conceito mais aceito, ilustrado na Figura 4.6 ĂŠ a de uma ferramenta de software ou hardware situada entre duas redes (uma interna e outra externa), responsĂĄvel por filtrar os pacotes, evitando o acesso externo a determinados serviĂ§os. Nesse sentido, pode-se dizer que os TCP-Wrappers constituemse num mini-firewall.

Rede Interna

Rede Externa

Firewall

Figura 4.6: Uso de Firewall

Outra questĂŁo importante nesse contexto ĂŠ o conceito de proxy. Um proxy ĂŠ um software que atua como ponto entre duas redes, controlando o trĂĄfego de acordo com seu conteĂşdo. Em geral, um proxy ĂŠ utilizado para servir como cache WWW ou FTP, mas pode ser utilizado para filtrar a rede, de forma que pode ser usado como firewall. Por outro lado, uma ferramenta de firewall pode ser configurada para funcionar como proxy. Isso ĂŠ o que acontece quando se utiliza o iptables ou o ipchains para fazer mascaramento de pacotes ou NAT, o que equivale a um proxy transparente. O proxy mais conhecido e utilizado ĂŠ o Squid. Para NAT, geralmente se utiliza o iptables. O iptables ĂŠ, inclusive, a ferramenta de firewall mais utilizada atualmente no Linux. Ele substitui o ipchains, acrescentando inĂşmeras funcionalidades. O uso do iptables foi ilustrado no CapĂtulo 3 de (UCHĂ&#x201D;A; SIMEONE; SICA, 2003). No site de desenvolvimento do iptables, http://www.netfilter.org/, podem ser encontrados excelentes tutoriais sobre seu uso, inclusive em bom portuguĂŞs. Em especial, recomenda-se a leitura de (RUSSEL, 2001).

Segurança por Controle de Acesso

Dado que já é considerado que o leitor tenha conhecimentos de uso do iptables, resta apenas abordar o seu uso como ferramenta de firewall. Nesse sentido, o administrador deve estar atento a quais portas de serviços ele irá permitir acesso. A política do menor privilégio é a recomendada: liberar apenas as portas essenciais. Um arquivo extremamente útil para o administrador é o /etc/services. Esse arquivo lista as portas padrões utilizadas pelos serviços mais comuns, bem como qual o protocolo utilizado, se TCP ou UDP. A Figura 4.7 mostra um trecho desse arquivo.

# Each line describes one service, and is of the form: # # service-name port/protocol [aliases ...] [# comment] tcpmux tcpmux rje rje echo echo discard discard systat systat daytime daytime qotd qotd msp msp chargen chargen

1/tcp 1/udp 5/tcp 5/udp 7/tcp 7/udp 9/tcp 9/udp 11/tcp 11/udp 13/tcp 13/udp 17/tcp 17/udp 18/tcp 18/udp 19/tcp 19/udp

# # # #

TCP port service multiplexer TCP port service multiplexer Remote Job Entry Remote Job Entry

sink null sink null users users

quote quote # message send protocol # message send protocol ttytst source ttytst source

Figura 4.7: Trecho do Arquivo /etc/services

Baseando-se em portas padrões apresentadas no arquivo /etc/services, a Figura 4.8 mostra um exemplo comentado de configuração salva pelo utilitário iptables-save. Essa configuração foi extraída de uma estação de trabalho. Para um servidor outras portas deveriam ser abertas. O administrador deverá fazer a configuração de acordo com a realidade local.

EDITORA - UFLA/FAEPE - Segurança Computacional

# Generated by iptables-save v1.2.5 on Sat Apr 19 17:01:10 2003 *filter # canal INPUT aceita tudo inicialmente :INPUT ACCEPT # aceita novas entradas, desde que relacionadas à uma conexão já estabelecida -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # aceita todas as conexões locais (internas à máquina) -A INPUT -s 127.0.0.1 -j ACCEPT # aceita todas as conexões da própria máquina (IP local = 192.168.0.50) -A INPUT -s 192.168.0.50 -j ACCEPT # aceita conexões ICMP (ping, etc.) da própria rede -A INPUT -s 192.168.0.0/255.255.255.0 -p icmp -m state --state NEW -j ACCEPT # aceita conexões SSH de qualquer lugar -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT # aceita comunicação gráfica via SSH de qualquer lugar -A INPUT -p tcp -m state --state NEW -m tcp --dport 6010 -j ACCEPT # nega qualquer outra entrada -A INPUT -j REJECT --reject-with icmp-port-unreachable # nega qualquer tentativa de usar o micro como roteador :FORWARD ACCEPT -A FORWARD -j REJECT --reject-with icmp-port-unreachable # aceita qualquer saída (isso deve ser modificado em servidores) :OUTPUT ACCEPT COMMIT # Completed on Sat Apr 19 17:01:10 2003

Figura 4.8: Exemplo de Configuração do iptables

4.5

CONFIGURAÇÃO SEGURA DE SERVIÇOS

Além do uso de técnicas de filtragem de pacotes, alguns aplicativos permitem configurações extras que tornam o seu uso mais seguro, tanto para o cliente como para o servidor. Uma primeira configuração a ser feita pelo administrador é verificar qual o usuário utilizado para inicializar o servidor. A inicialização de serviços sob a égide do superusuário deve ser evitada ao máximo possível. Em geral, versões mais recentes dos aplicativos já fazem isso automaticamente para o administrador. O uso de aplicativos que trafegam senhas em claro deve ser evitado ao máximo, pois estão sujeitos à escuta eletrônica (sniffers). Assim, o telnet deve ser substituído por SSH. Além disso, o uso do POP comum (não seguro) também deve ser substituído pelo POP seguro (não suportado por todos os clientes) por IMAP seguro (também não suportado por todos os clientes) ou por serviços de WebMail via HTTPS. O FTP não-anônimo também deve ser substituído pelo SFTP.

Segurança por Controle de Acesso

Observe que a adoção dessas medidas irá, na maioria das vezes, implicar em perda de performance ou conveniência do usuário. Ainda não existem muitos clientes gráficos com suporte ao SFTP. O uso de POP seguro também não é trivial, sendo que a maioria dos clientes de e-mail da Microsoft não suportam esse tipo de transporte de e-mail. O uso de WebMails é uma alternativa mais interessante, mas pode dificultar o uso por usuários iniciantes e tende a aumentar o tráfego na rede. Quanto aos serviços de e-mail, é necessário configurar os servidores para evitar o uso por qualquer estação. No sendmail, isso pode ser feito habilitando-se o uso do access_db e utilizando o arquivo /etc/mail/access para listar as estações que podem utilizar o servidor para envio de correio eletrônico. Além disso, é recomendável que seja configurado o tamanho máximo de arquivo a ser recebido ou enviado. O uso de NIS, por sua vez, deve ser totalmente evitado. Sugere-se a cópia de dados por meios criptográficos ou a substituição do NIS por LDAP (que suporta tunelamento por TLS, a partir de versões mais recentes - como o OpenLDAP 2). Um exemplo de uso do LDAP para autenticação de usuários pode ser encontrado em (DOMINGUES; SCHNEIDER; UCHÔA, 2001). Uma regra fundamental de segurança é usar sempre servidores atualizados ou seguros. Sempre que houver opção de escolha para um dado serviço, o servidor mais seguro deve ser escolhido. Assim, não se usa POP, mas POPS ou IMAP, ou mesmo Webmail sob HTTPS. Além disso, o administrador deve sempre verificar se não existem atualizações de segurança dos servidores e bibliotecas instalados. Além disso, deve-se sempre verificar a segurança dos servidores, utilizando-se ferramentas de verificação (como SARA, SATAN ou nessus). Essas ferramentas serão abordadas com mais detalhes no Capítulo 6. Um projeto muito interessante nesse sentido é o Bastille Linux, disponibilizado em (http://bastille-linux.sourceforge.net/). Ele tem por objetivo configurar uma máquina de forma a aumentar o seu nível de segurança. Para isso, ele altera configurações de sistema e de servidores, além de alterar as regras de firewall. Na opinião deste autor, o uso dessa ferramenta é desnecessário para o administrador experiente, que preferirá efetuar suas próprias configurações. Mesmo para esse usuário, e principalmente para usuários menos experientes, entretanto, pode ser uma ferramenta de grande auxílo. Uma recomendação final a ser feita é que serviços que não são usados devem ser desabilitados. Se os usuários não irão precisar de serviços internos de FTP, então o servidor FTP deverá estar desabilitado. Uma forma prática de listar os serviços habilitados é executar o comando # chkconfig - -list Esse comando irá informar, para cada initlevel, se um dado serviço está ou não habilitado.

EDITORA - UFLA/FAEPE - Seguranรงa Computacional

5 ADMINISTRAÇÃO SEGURA DE USUÁRIOS

5.1

USO DO PAM (PLUGGABLE AUTHENTICATION MODULES)

Boa parte das distribuições Linux (e mesmo outras variantes do UNIX) utilizam o PAM (Plugabble Authentication Module) para implementar a autenticação de usuários de forma altamente configurável, como visto em (SICA; UCHÔA, 2004). Isso permite que a autenticação possa atender às mais diversas necessidades de uma instituição qualquer. Utilizando o PAM, o administrador pode escolher o sistema de autenticação que mais lhe convier e não se preocupar em como as aplicações irão interpretar isso. O PAM permite ainda que se controle vários outros itens de usuários, entre eles: limites de recursos, uso de senha escondida (shadow), limite de acesso, shell restrito, etc. As configurações do PAM propriamente dito são efetuadas no diretório /etc/pam.d/. Recomenda-se a leitura de (SICA; UCHÔA, 2004) e (MORGAN, 2002) para maiores detalhes sobre o processo de configuração. Uma descrição mais formal do PAM pode ser encontrada em (MORGAN, 2001) e (SAMAR; SCHEMERS, 1995). Como o processo de autenticação do usuário é crucial para a segurança de um dado sistema, existem alguns módulos PAM1 que podem se utilizados para incrementar essa segurança. Entre eles merecem destaque: pam_limits, pam_listfile, pam_access, pam_time, pam_cracklib e pam_wheel. O módulo pam_cracklib, do tipo password é responsável por fazer uma checagem mínima de segurança e tamanho de uma senha sendo trocada. Ele utiliza a biblioteca CrackLib, uma versão resumida e em biblioteca do Crack, um programa para ataques de dicionários, o que será visto na Seção 5.2. Ao usar essa biblioteca, o pam_cracklib dificulta a escolha de senhas baseadas em senhas de dicionários. O módulo pam_cracklib permite ainda que se defina o tamanho mínimo de uma senha e incentivar, por mecanismos de crédito, o uso de maiúsculas e minúsculas, bem como símbolos e números. Consulte a documentação do PAM para detalhes de implementação e uso desse módulo. 1 Observe

que o termo “módulo PAM”, que seria traduzido como “módulo de módulos plugáveis de autenticação” é um produto do Departamento Organizacional de Redundância Repetida.

EDITORA - UFLA/FAEPE - Segurança Computacional

Com o uso do módulo pam_wheel, é possível limitar quem pode executar o comando su. Na Figura 5.1 é apresentado um exemplo de arquivo /etc/pam.d/su configurado para usar esse módulo. Nesse exemplo, é possível verificar que a configuração geral do comando su será copiada do arquivo /etc/pam.d/system-auth. As únicas exceções são os módulos pam_rootok e pam_wheel. Com o uso de pam_rootok, o usuário root pode usar o su sem necessidade de autenticação.

auth auth auth auth account password session

sufficient sufficient required required required required required

/lib/security/pam_rootok.so /lib/security/pam_wheel.so trust /lib/security/pam_wheel.so group=super /lib/security/pam_stack.so service=system-auth /lib/security/pam_stack.so service=system-auth /lib/security/pam_stack.so service=system-auth /lib/security/pam_stack.so service=system-auth

Figura 5.1: Exemplo de Arquivo /etc/pam.d/su

Utilizando-se a configuração apresentada na Figura 5.1, com o uso do pam_wheel, os usuários do grupo wheel podem usar o su sem necessidade de digitar a senha do usuário. Isso é possível pelo parâmetro trust utilizado. Observe que essa opção é altamente desrecomendada na grande maioria dos casos. Na sequência da Figura 5.1, caso o usuário não seja root ou esteja no grupo wheel, o PAM irá verificar se o usuário faz parte do grupo super. Em caso negativo, o acesso ao su será negado. Em caso positivo, será exigido a senha do usuário a que se pretende acessar. Uma forma semelhante de limitar esse acesso é utilizar o pam_listfile. Nesse caso, o pam_listfile foi criado para ser utilizado por qualquer programa com suporte ao PAM. Na Figura 5.2 é mostrado um exemplo de configuração do arquivo /etc/pam.d/ chsh para impedir que os usuários listados no arquivo /etc/security/nochsh possam utilizar o comando chsh. Com isso, é possível que o administrador possa escolher shells restritos para determinados usuários (como o rsh) e evitar que eles alterem esse shell para um outro qualquer. No caso da Figura 5.2, os parâmetros do módulo pam_listfile indicam como ele deve agir na autenticação do usuário. O parâmetro onerr especifica o que deve ser feito em caso de falha (erro de leitura do arquivo, etc.). Esse parâmetro pode receber os valores fail ou succeed. O parâmetro item, por sua vez, especifica o que está contido na lista. Ele pode receber os valores user e group, entre outros. O parâmetro file especifica onde está o arquivo com a lista. Já o parâmetro sense especifica se é para negar (deny) ou permitir (allow) acesso aos membros da lista.

Administração Segura de Usuários

auth auth

sufficient required

auth account password session

required required required required

/lib/security/pam_rootok.so /lib/security/pam_listfile.so onerr=fail \ item=user sense=deny file=/etc/security/nochsh /lib/security/pam_stack.so service=system-auth /lib/security/pam_stack.so service=system-auth /lib/security/pam_stack.so service=system-auth /lib/security/pam_stack.so service=system-auth

Figura 5.2: Exemplo de Arquivo /etc/pam.d/chsh

Outro módulo PAM de controle de acesso é o pam_access. Esse módulo, do tipo account permite a configuração de acesso por local. Assim, por exemplo, é possível restringir o acesso de usuários a partir de determinadas máquinas. Para isso, basta habilitar esse módulo na aplicação desejada e editar o arquivo /etc/security/access.conf, como exemplificado na Figura 5.3. # SINTAXE é dada por "permissão (+ permite, - nega) : usuários : origem" # pode-se usar LOCAL para acesso de console e ALL para todos. # EXCEPT indica exceção # Impedindo acesso de console, com exceção de algumas contas # observe que pode ser usado grupo ou usuário -:ALL EXCEPT wheel shutdown sync root:LOCAL # Impede acesso remoto do usuário root -:root:ALL EXCEPT LOCAL # usuário lennon só pode logar da rede beatles.com -:lennon:ALL EXCEPT .beatles.com # usuário harrison só pode logar da rede 110.220 -:harrison:ALL EXCEPT 110.220. # negando acesso a todos os outros usuários -:ALL:ALL Figura 5.3: Exemplo de Arquivo /etc/security/access.conf

Limitação de acesso por tempo é feito com o uso do módulo pam_time. Esse módulo, do tipo account, permite restringir o acesso de serviços PAM a uma faixa de horário

EDITORA - UFLA/FAEPE - Segurança Computacional

por usuários. Para tanto, é utilizado um arquivo de configuração, localizado em /etc/ security/time.conf, exemplificado na Figura 5.4. Consulte a documentação do PAM para maiores detalhes. # # # # # # # #

SINTAXE é dada por "serviços;terminais;usuários;tempo" tempo é dado por uma lista de dias/faixa horária Mo = segunda, Tu = terça, We = quarta, Th = quinta, Fr = sexta, Sa = sábado, Su = domingo, Wk = finais de semana Wd = segunda à sexta, Al = todos os dias Se o dia for repetido, então ele é desconfigurado Assim, AlMo significa todos os dias exceto segunda & = e lógico, | = ou lógico, ! = negação

# root acessa qualquer serviço a qualquer hora do terminal tty1 *;tty1;root;Al0000-2400 # paul e ringo só logam-se via login e login & ssh; *;paul|ringo;Al0800-1800

ssh das 8:00 às 18:00

# só aceita conexões ao servidor ftp nos finais de semana ftp;*;*;Wk0000-24000 Figura 5.4: Exemplo de Arquivo /etc/security/time.conf

O limite de uso de recursos via PAM é feito utilizando-se o módulo pam_limits. Esse módulo, do tipo session permite limite de uso dos recursos da máquina. A Tabela 5.1 apresenta os tipos de limites que são limitados com uso desse módulo. Utilizando as informações da Tabela 5.1, a Figura 5.5 apresenta um exemplo de configuração do módulo pam_limits. Essa configuração fica localizada no arquivo limits.conf no diretório /etc/security. Observe que o usuário root não é afetado pela maioria dos limites impostos pelo módulo pam_limits. Outra observação importante é que, como esse é um módulo de sessão, ele estipula o limite por sessão do usuário. Assim, uma configuração global deve levar em conta a configuração do recurso maxlogins Como pôde ser percebido nesta seção, o PAM é uma ferramenta poderosa para segurança de usuários. Além dos módulos aqui apresentados, módulos PAM adicionais podem ser utilizados para implementar outros controles e limites. Recomenda-se a leitura de (MORGAN, 2002) e (MORGAN, 2003) para maiores detalhes.

Administração Segura de Usuários

Tabela 5.1: Recursos Limitados pelo pam_limits

Recurso

Descrição

core data fsize memlock nofile rss stack cpu nproc as maxlogins priority locks

limita o tamanho (em KB) de arquivos core tamanho máximo de dados (em KB) tamanho máximo de arquivo (em KB) espaço máximo (em KB) de endereçamento de memória reservada número máximo de arquivos abertos tamanho máximo (em KB) de memória residente tamanho máximo (em KB) de pilha de memória tempo máximo (em minutos) de uso da CPU número máximo de processos limite de espaços de endereçamento número máximo de logins prioridade com a qual são rodadas as aplicações número máximo de arquivos aos quais é possível fazer lock

# SINTAXE é dada por "usuários terminais # tipo pode ser # hard (para limites rígidos) # soft (para limites leves) # grupo pode ser indicado por "@"

tipo

recurso

valor"

# limita arquivos core em tamanho 0 * hard core 0 # limita uso da memória em 10Mb * hard rss 10000 # limita número de processos para o grupo student @student soft nproc 30 @student hard nproc 60 # limita o número de logins do grupo student @student - maxlogins 4 Figura 5.5: Exemplo de Arquivo /etc/security/limits.conf

5.2

EDITORA - UFLA/FAEPE - Segurança Computacional

PROTEGENDO CONTAS DE USUÁRIOS

O superusuário é o administrador do sistema. O acesso de superusuário deve ser evitado sempre que possível. Nesse sentido, o aplicativo sudo permite que o acesso como superuário seja evitado, permitindo maior restrição em divulgar a senha do administrador em um ambiente onde existam várias pessoas administrando serviços de rede. Geralmente o aplicativo sudo é disponibilizado com a maioria das distribuições. Após a instalação, deve-se editar o arquivo /etc/sudoers, especificando quem pode utilizá-lo e com quais poderes. Esse arquivo é de fácil edição, possuindo vários exemplos comentados. Além disso as páginas de manual do sudo e do sudoers são bastante instrutivas, sendo recomendada a leitura desse material. Outra questão importante no que se refere ao gerenciamento seguro de usuários é garantir que as senhas de usuário estão protegidas e foram escolhidas de forma correta. Isso ocorre porque uma das estratégias de invasão utilizada pelos hackers é através da obtenção de acesso autorizado, utilizando a senha de um usuário comum do sistema. Uma vez obtido o acesso de um usuário, é muito mais fácil descobrir vulnerabilidades e falhas de segurança. Assim, é importante garantir que as senhas dos usuários trafeguem de forma segura e sejam escolhidas de forma segura. Para o primeiro ítem, o uso de tunelamento é recomendado. Para o segundo ítem, utiliza-se a tática do hacker : programas de quebra de senha para detectar senhas fracas. Essa quebra é baseada em dicionário de palavras. Dois aplicativos se destacam nessa tarefa: o John The Ripper e o Crack. É extramente recomendável que o administrador faça verificações periódicas, usando aplicativos tipo o John ou o Crack. Pode ser o caso, inclusive, de se bloquear o acesso de contas com senhas extremamente fáceis (sobrenome ou palavras simples). Obviamente, isso não descarta a necessidade de orientar os usuários para uma boa escolha de senhas, como já alertado em (SICA; UCHÔA, 2004). Outra observação importante é que é extremamente necessário fazer checagens periódicas no arquivo /etc/passwd, procurando entradas incorretas ou estranhas. Em geral, invasores costumam criar contas extras com poderes de root (com UID 0). Além disso, contas inativas devem ter acesso bloqueado ou até mesmo serem removidas do sistema. Também é essencial que se configure os limites de recursos aos usuários. Como já comentado no Capítulo 2, uma medida recomendada de segurança é a estratégia do menor privilégio: liberar ao usuário apenas aquilo que ele precisa para desempenhar suas atividades. Nesse caso, alguns limites precisam ser impostos ao usuário de forma automática. Alguns desses limites podem ser impostos via uso do PAM, como mostrado na Seção 5.1. Outros limites podem ser impostos de várias maneiras.

Administração Segura de Usuários

Um limite extremamente útil é o uso de quotas de usuário. Isso pode ajudar a manter os usuários menos vorazes em termos de uso de espaço em disco e limitar tentativas de invasão interna. O uso e configuração de quotas foi abordado em detalhes no Capítulo 6 de (SICA; UCHÔA, 2004). Consulte esse material, bem como (DOOREN, 2002) para mais detalhes. Uma outra forma de impôr limites é utilizar o comando interno ulimit do bash. Esse comando permite configurar vários limites de recursos de forma semelhante ao pam_limits. A única desvantagem desse comando é que ele é restrito ao bash. A Figura 5.6 mostra um exemplo de uso desse comando (a opção “-a” é usada para imprimir os limites atuais). A saída do comando é instrutiva, mostrando o que pode ser limitado com seu uso. # ulimit -a core file size (blocks, -c) data seg size (kbytes, -d) file size (blocks, -f) max locked memory (kbytes, -l) max memory size (kbytes, -m) open files (-n) pipe size (512 bytes, -p) stack size (kbytes, -s) cpu time (seconds, -t) max user processes (-u) virtual memory (kbytes, -v)

0 unlimited unlimited unlimited unlimited 1024 8 8192 unlimited 4095 unlimited

Figura 5.6: Execução do Comando ulimit-a

5.3

SEGURANÇA NO SISTEMA DE ARQUIVOS

A segurança dos usuários também passa por uma configuração adequada dos sistemas de arquivos. Várias opções de montagens de dispositivos, por exemplo, podem ser utilizadas para incrementar a segurança do sistema como um todo. Sobre montagem de dispositivos, recomenda-se a leitura de (SICA; UCHÔA, 2004). Em geral, as observações a serem feitas sobre montagens de dispositivos referem-se às opções de montagem nosuid, nodev e noexec. Como os dispositivos confiáveis são criados no diretório /dev/, somente a partição contendo esse diretório deve possuir permissão para criação e uso de arquivos de dispositivos. Todas as outras partições devem ser montadas com a opção nodev. Por motivos semelhantes, arquivos com SUID não devem

EDITORA - UFLA/FAEPE - Segurança Computacional

ser permitidos no diretório /tmp ou /home. Donde esses diretórios devem ser montados com a opção nosuid. Em diretórios onde não se pretende que sejam executados aplicativos (como o /tmp ou /home em algumas instituições), deve-se usar opção de montagem noexec. O diretório /var é outro candidato para essas opções de montagem. Entretanto, alguns gerenciadores de listas são instalados no /var ou no /home. Assim, é preciso estar atento e checar o sistema após essas modificações. Permissões também são outro ponto problemático. O administrador deve estar extremamente atento sobre quais aplicaçõs são executadas com permissões de administrador (com uso de SUID). Para encontrar todas as aplicações com SUID ou SGID no sistema basta executar o comando # find / -type f \( -perm 04000 -o -perm -02000 \) Após feita essa verificação, é necessário checar se os aplicativos realmente precisam de SUID/SGID e se não houve alteração inconveniente na lista retornada. Outro problema grave são os arquivos com permissão de escrita global, especialmente arquivos de sistema. Mas mesmo para arquivos comuns de usuários, esse tipo de permissão é totalmente inconveniente. Para localizar arquivos desse tipo, basta executar # find / -perm -2 !

-type l

Outra verificação a ser feita é a detecção de arquivos sem proprietário. Eles tanto podem ser “restos” de usuários excluídos do sistema, resultados de software mal instalado ou arquivos criados por um invasor. Assim, periodicamente deve-se executar o comando # find / \( -nouser -o -nogroup \) Ainda no que diz respeito à questão das permissões, pode ser interessante configurar a permissão padrão dos arquivos criados pelos usuários. Isso é feito com o uso do comando umask, cuja chamada pode ser inserida no /etc/profile. Uma chamada do tipo “umask 077” irá fazer com que os arquivos criados só possam ser lidos pelo usuário criador. O valor é calculado subtraindo-se a permissão desejada de 777. Assim, caso fosse interessante que os arquivos também pudessem ser lidos por outros membros do grupo, poderia ser usado a chamada “umask 027”. Outro recurso importante para segurança no sistema é o uso de atributos de arquivos. Isso é feito com o uso do comando chattr. Esse comando pode ser usado da seguinte forma: chattr [-RV] +-=[ASacdisju] arquivos

Administração Segura de Usuários

Quando chamado com a opçao “-V”, chattr irá imprimir informações extras sobre a ação sendo executada. Com a opção “-R”, ele irá atuar de forma recursiva, alterando dados de diretórios e seus conteúdos. Qualquer atributo seguinte a um sinal de “+” irá ser adicionado ao arquivo. Atributos seguintes a um sinal de “-” irão ser removidos do arquivo. Caso pretenda-se exatamente um determinado conjunto de atributos, então é utilizado o sinal “=”. Assim, para adicionar os atributos “a” e “c” e remover os atributos “i” e “j” do arquivo teste, executa-se o comando chattr +ac -ij teste Para se listar os atributos de um arquivo, basta-se executar o comando lsattr. Se chamado sem nenhum parâmetro em um diretório, ele irá informar os atributos de todos os arquivos aí contidos. Para saber o atributo de um conjunto de arquivos, basta chamá-lo na forma lsattr arquivos Os atributos são dependentes do sistema de arquivos. Assim, a Tabela 5.2 apresenta uma listagem dos atributos existentes ou previstos para uso no sistema de arquivos ext2. Nessa tabela, todos os atributos já encontram-se implementados nesse sistema de arquivos, no kernel 2.2, com exceção dos atributos “c”, “s” e “u”. Tabela 5.2: Atributos de Arquivos

Atributo

Descrição

A S a

não modificar data e hora que arquivo foi acessado (atime) atualização síncrona com o disco (não usa buffer) arquivo é aberto no modo append, ou seja somente pode receber novas informações em seu final arquivo é comprimido automaticamente pelo kernel arquivo não permite cópia de segurança usando dump arquivo não pode ser modificado nem removido – também não é possível fazer links não simbólicos para o arquivo o arquivo com esse atributo escreve todos os seus dados no journal antes de escrever no próprio arquivo – esse atributo só é válido para o ext3 deleção segura (arquivo é preenchido com zeros quando apagado) quando o arquivo é apagado, seu conteúdo é salvo e o arquivo pode ser recuperado com facilidade

c d i j s u

Alguns dos atributos da Tabela 5.2 só podem ser atribuídos pelo superusuário. São eles: “a” e “i”. Isso ocorre porque um arquivo com o atributo “i” não pode ser apagado nem

EDITORA - UFLA/FAEPE - Segurança Computacional

pelo usuário root. Antes de apagá-lo, é necessário remover o atributo do arquivo. Note que esses atributos, “a” e “i”, são os mais importantes do ponto de vista da segurança, junto com o atributo “s”. Como o atributo “s” pode não estar implementado na versão do kernel utilizada pelo usuário, pode-se lançar mão de outros mecanismos para deleção segura de arquivos. Deleção segura é extremamente recomendável ao apagar arquivos confidenciais. Uma alternativa viável é utilizar-se do srm, um utilitário que preenche o arquivo com o valor nulo (ASCII “0”) antes de apagá-lo. O srm pode ser obtido em seu site, http://srm.sourceforge. net. O RedHat também disponibiliza o shred. Consulte a página de manual desse comando para mais detalhes.

5.4

COMENTÁRIOS FINAIS

Este capítulo objetivou apresentar ao leitor um conjunto de técnicas práticas e eficientes para uma administração segura de usuários. Com o uso do PAM, dos utilitário find e sudo, é possível incrementar sensivelmente a segurança do sistema. Essas técnicas associadas ao processo de montagem segura de dispositivos e uso adequado de atributos de arquivos pode tornar um sistema altamente inconveniente para um processo de invasão. O administrador deve estar consciente que o usuário pode ser a porta de entrada para um hacker, facilitando a invasão. Daí sua preocupação em garantir a segurança dos mesmos. Outra preocupação do administrador é que vários casos de invasão provêm do interior da instituição, dos próprios usuários. Assim, o administrador deve limitar os recursos, adotando a política do menor privilégio, e periodicamente fazer checagem de segurança do sistema.

6 PREVENÇÃO E DETECÇÃO DE INTRUSOS

6.1

COMENTÁRIOS INICIAIS

Segurança total é ficção, e ficção de baixa qualidade. Vulnerabilidades são descobertas com freqüência e é possível falar com absoluta tranqüilidade que não existem servidores 99% seguros. O que se pode pretender é um servidor que ofereça tanta dificuldade que ele desestimule os invasores. Mas mesmo com esse nível de dificuldade, não é possível confiar cegamente no sistema. Dessa maneira, o administrador deve estar utilizando ferramentas de detecção e prevenção de intrusos para monitorar o sistema de sua responsabilidade. Dessa maneira, o administrador pode vir a ter condições de impedir que ataques em fase inicial consigam chegar a um nível indesejado de intrusão no sistema. Parte do serviço de prevenção de intrusos é feito com uma implementação de uma política de segurança adequada. Obviamente essa política deve estar baseada em serviços criptográficos, uma correta configuração de serviços e firewall, entre outros. Dessa maneira, a dificuldade gerada servirá como uma prevenção adequada de intrusos. Mas isso não é suficiente. O processo de detecção de intrusos envolve inúmeras estratégias. Geralmente são utilizados ferramentas IDS (Intrusion Detection System - Sistema de Detecção de Intrusos). É importante notar que esse termo pode ser usado de várias formas, de forma mais ampla ou mais restrita. Em sua forma mais restrita, refere-se apenas aos aplicativos capazes de alertar quando uma tentativa de invasão encontra-se em ação. Nesse sentido, constituem-se principalmente em programas de monitoramento de conexões de rede, como o Snort. Em uma visão mais ampla, utilizada neste trabalho, também são IDS as ferramentas utilizadas para monitorar a integridade do sistema. Nesse caso, também podem ser definidos claramente como IDS os verificadores de integridade de arquivos, como o AIDE ou o Tripwire: Técnicas de Detecção de Intrusos se aproximam bastante daquelas usadas em Firewalls e sistemas de Log, e o seu objetivo principal é reagir a uma invasão (ou suspeita de invasão) no menor intervalo de tempo possível. Isto pode ser

EDITORA - UFLA/FAEPE - Segurança Computacional

feito, por exemplo, monitorando-se continuamente o tráfego de rede, à procura de qualquer anomalia, ou então analisando-se continuamente as últimas entradas dos arquivos de log, à procura de ações suspeitas. (WEBER, 17 a 21 de julho de 2000)

Assim, antes de abordar os IDS propriamente dito, este capítulo introduz o leitor em outras técnicas importantes nesse processo, como a monitoração dos arquivos de registros e uso de ferramentas de varreduras. Essas técnicas irão auxiliar o administrador a descobrir e evitar vulnerabilidades, corrigindo-as antes de uma possível invasão.

6.2

VERIFICAÇÃO DOS REGISTROS (LOGS)

Uma invasão geralmente deixa rastros. Talvez, inclusive, seja possível dizer que, da mesma forma que não existe um sistema totalmente seguro, não existe uma invasão perfeita. Assim, a verificação periódica dos arquivos de registros pode evitar surpresas extremamente desagradáveis, ao mostrar a tentativa de invasão desde o seu início. Uma esclarecimento inicial é que, em um sistema medianamente seguro, uma invasão é um procedimento relativamente demorado. Assim, o leitor deve excluir de sua imaginação a imagem romântica de um hacker que consegue penetrar em um sistema em poucos minutos. A menos que o sistema seja uma peneira de vulnerabilidades, uma invasão irá exigir esforço e paciência do intruso, que terá que fazer inúmeras tentativas para conseguir seu intento. Caso haja uma verificação periódica dos logs, essa invasão pode ser bloqueada em seu início. Além disso os arquivos de registros podem indicar falhas em serviços, o que poderia comprometer não só a segurança, mas a qualidade do sistema. Outro motivo para a verificação periódica dos logs é a possibilidade de verificação de ações anormais no sistema, como logins fora do padrão ou tentativas de execução de aplicações restritas. Um acesso de um usuário fora do horário normal, por exemplo, pode indicar que um invasor esteja usando a conta do usuário para encobrir a invasão. Pode ser também que esse usuário esteja acessando fora do horário com finalidades ilícitas, ou seja: ele é o invasor. Não se deve esquecer que apesar do número de invasões externas estarem crescendo assustadoramente nos últimos anos, as invasões internas costumam causar, ainda, o maior prejuízo. Os arquivos de log são localizados geralmente no diretório /var/logs. Merecem especial atenção, sob o ponto de vista da segurança, quatro arquivos nesse diretório: messages, secure, wtmp e lastlog. O messages é um arquivo de registro genérico, com informações de login, uso do comando su, conexões SSH, entre outros. O arquivo secure armazena informações restritas à segurança do sistema, como uso do sudo e inicialização do servidor SSH.

Prevenção e Detecção de Intrusos

O arquivo wtmp não pode ser lido diretamente, pois armazena informações de login no formato binário. A leitura dos dados nesse arquivo é feito via comando last. O comando last exibe todas as conexões efetuadas no sistema, desde a data de início do arquivo. Na Figura 6.1 é apresentada uma forma de uso desse comando para filtrar os últimos logins do superusuário. A partir da saída do comando, é possível verificar de onde foi feita a conexão e o tempo de duração da mesma. # last | grep root root tty3 root tty2 root tty1

Sat Apr 19 16:40 - 17:48 Sat Apr 19 16:39 - 16:53 Thu Apr 10 15:10 - 15:11

(01:08) (00:13) (00:00)

Figura 6.1: Exemplo de Uso do Comando last

Já o arquivo lastlog, também binário, é utilizado pelo comando de mesmo nome, como ilustrado na Figura 6.2. Ele aponta, para cada usuário do sistema qual foi o último login efetuado. Isso pode ser útil para verificar se determinadas contas de sistema não estão sendo usadas de forma incorreta. Observando a Figura 6.2, é possível verificar que o comando lastlog informa de onde e quando foi o último login de cada usuário do sistema. Nesse sentido, é importante verificar se contas de sistema estão com acesso bloqueado no /etc/shadow, uma vez que ninguém irá fazer login direto nessas contas. Essa é a configuração padrão, mas isso deve ser verificado periodicamente. Ainda com respeito aos arquivos de registros, não podem ser esquecidos os arquivos de log do Apache, geralmente no diretório /var/log/httpd, e o arquivo de log do servidor de e-mail, o arquivo /var/log/maillog. Através de análises do maillog, é possível detectar quem são os usuários que mais recebem e enviam e-mail. Também é possível verificar de onde vem a maioria dos e-mails externos, facilitando o bloqueio a sites que permitem o envio de SPAM. É importante verificar que os registros são, em geral, configuráveis. Assim, é possível habilitar um nível extra de informações. Isso pode possuir duas forças contrárias: quanto mais informações, mais espaço é necessário em disco; além disso, determinadas informações extras podem ferir a privacidade dos usuários. Dessa maneira, o usuário precisa estar ciente que determinados tipos de monitoramento estão sendo efetuados na instituição, para evitar problemas legais. Um exemplo desse tipo de monitoramento: é possível configurar o iptables para armazenar informações de conexões. Dessa forma, é possível saber quem está acessando quem numa dada rede. Também é possível aumentar o nível de informações do servi-

EDITORA - UFLA/FAEPE - Segurança Computacional

# lastlog ==> lastlog Username root bin daemon lp sync shutdown halt mail operator nobody rpm ntp rpc xfs gdm rpcuser nfsnobody nscd ident radvd pcap massive mazzy apache

Port tty3

pts/16 pts/0

From

poseidon hades

Latest Sáb Abr **Never **Never **Never **Never **Never **Never **Never **Never **Never **Never **Never **Never **Never **Never **Never **Never **Never **Never **Never **Never Seg Abr Qui Abr **Never

19 16:40:06 -0300 2003 logged in** logged in** logged in** logged in** logged in** logged in** logged in** logged in** logged in** logged in** logged in** logged in** logged in** logged in** logged in** logged in** logged in** logged in** logged in** logged in** 21 19:14:29 -0300 2003 10 15:12:21 -0300 2003 logged in**

Figura 6.2: Exemplo de Uso do Comando lastlog

dor de e-mail, aumentando o nível de monitoração do envio e recebimento de mensagens eletrônicas. Outro tipo de monitoramento que pode ser feito é o uso de contabilidade de processos. Isso é feito com o uso do comando psacct, disponível na maioria das distribuições. Uma vez instalado o pacote, deve-se habilitar o serviço com o comando # accton /var/log/psacct Uma vez habilitada a contabilidade de processos, pode-se usar os comandos sa ou lastcomm para saber os últimos comandos emitidos pelos usuários. É importante observar

Prevenção e Detecção de Intrusos

que, se não claro na política de uso, esse tipo de monitoramento pode ser interpretado como ilegal e causar dores de cabeça ao administrador. Um utilitário extremamente útil no que se refere à monitoração de arquivos de registros é o logwatch, também disponível na maioria das distribuições. Em geral, já vem com um script executado diariamente para informar ao superusuário, por e-mail, sobre registros ligados à segurança do sistema, como ilustra a Figura 6.3. Nesse exemplo, o logwatch alerta para usos do sudo e conexões ssh do usuário root, além do uso do sendmail para envio de correio eletrônico. ---------------- Connections (secure-log) Begin ------------------**Unmatched Entries** sudo: joukim : TTY=pts/3 ; PWD=/home/joukim ; USER=root ; COMMAND=/etc/rc.d/init.d/sendmail restart ----------------- Connections (secure-log) End --------------------

--------------------- sendmail Begin -----------------------917 bytes transferred 1 messages sent ---------------------- sendmail End -------------------------

--------------------- SSHD Begin -----------------------Users logging in through sshd: root logged in from cpp (127.0.0.1) using password: 1 Times(s) ---------------------- SSHD End -------------------------

Figura 6.3: Exemplo de Alerta do logwatch

6.3

EVITANDO EXPLOITS

A maioria das invasões externas aproveitam-se de bugs nos daemons. Assim, utilizandose desses bugs, criam exploits para explorar essas falhas e tentar obter acesso ao sistema.

EDITORA - UFLA/FAEPE - Segurança Computacional

Quando bem sucedidos, os invasores conseguem um terminal de root à sua inteira disposição. Para evitar a ação dos exploits, duas ações são as mais eficazes: 1. Verificar com freqüência sites de segurança sobre anúncios de falhas em serviços. Em geral, as distribuições mantém páginas a esse respeito, mas esse tipo de informação também pode ser obtida na Freshmeat (http://www.freshmeat.net/), na CERT (http://www.cert.org/), no SANS Institute (http://www.sans.org/) ou na l0pht (http://www.l0pht.com/). 2. Atualizar os servidores periodicamente, tão logo sejam descobertas falhas de segurança e sejam disponibilizadas atualizações corrigindo esses bugs. É preciso chamar a atenção para o fato que a maioria das invasões ocorrem em máquinas há muito desatualizadas e com furos enormes de segurança. Assim, a constante vigilância é essencial para evitar esse tipo de problema.

6.4

USO DE FERRAMENTAS DE VARREDURA

Como já comentado neste texto, algumas ferramentas de segurança podem se transformar em ferramentas de invasão e vice-versa. Esse é o caso típico das ferramentas de varredura. Essas ferramentas tem o objetivo explícito de verificar um sistema em busca de falhas de segurança. Se utilizadas pelo administrador, pode auxiliá-lo a fechar as brechas encontradas em seu ambiente computacional. Os scanners, como também são conhecidas essas ferramentas, tanto podem investigar falhas locais como nos serviços de rede. Os mais conhecidos são o nessus, o TARA, o SARA, o SAINT e o SATAN, mas existem vários outros. É importante observar que mesmo ferramentas usuais, como o netstat ou o nmap podem ser utilizados com essa finalidade. O SATAN foi uma das primeiras ferramentas de varredura criadas, tendo influenciado o surgimento do SAINT e do SARA. Os três iniciam um navegador a partir do qual são vasculhados os serviços de rede de um dado servidor ou um conjunto de máquinas. O SATAN não é mantido mais atualmente, encontrando-se desatualizado. Assim, recomenda-se o uso do SARA e do nessus, uma vez que o SAINT é comercial, só liberando gratuitamente versões mais antigas. O SARA (Security Auditor’s Research Assistant) é desenvolvido pela Advanced Research Computing (http://www-arc.com/) e faz parte de um conjunto de programas para verificação de segurança. Entre eles, encontra-se o TARA, um utilitário para verificação local de segurança, comentado mais à frente. A Figura 6.4 mostra um exemplo de checagem de segurança efetuada pelo SARA, onde foram encontradas várias vulnerabilidades. O SARA pode ser executado para checar vulnerabilidades em uma única máquina ou em toda uma rede. Obviamente checagens locais conseguem coletar mais informa-

Prevenção e Detecção de Intrusos

Figura 6.4: Vulnerabilidades Encontradas pelo SARA

ções. Além de detectar as vulnerabilidades, o SARA detalha a vulnerabilidade encontrada, documentando-a e apresentando alternativas para correção dessa vulnerabilidade. A Figura 6.5 mostra um exemplo disso para a vulnerabilidade do Apache apresentada na Figura 6.4. O TARA é baseado num conjunto de scripts chamado Tiger, desenvolvido pelo campus A&M da Texas University. Depois da versão 2.2.4, em 1994, o desenvolvimento do Tiger foi interrompido. As páginas originais do projeto ainda podem ser encontradas em http://www.net.tamu.edu/network/tools/tiger.html. O TARA (Tiger Analytical Research Assistant) foi um dos esforços para manter o Tiger atualizado Mais recentemente, esses esforços foram unificados (apesar do TARA ainda ser atualizado independentemente) numa nova versão do Tiger, disponível em http://www. tigersecurity.org/. Observe que as versões do TARA ainda são mais estáveis que o Tiger, mas isso deve mudar num futuro próximo. Esses aplicativos fazem verificações locais, por exemplo, checagem de segurança nos arquivos de contas de usuários (passwd, shadow e group). O uso desses dois aplicativos é altamente recomendado.

EDITORA - UFLA/FAEPE - Segurança Computacional

Figura 6.5: Deltalhamento da Vulnerabilidade no SARA

Um outro aplicativo que não pode faltar nas ferramentas do administrador de redes é o nessus, também na mesma filosofia do SARA. A experiência da equipe do ARL é maior com o SARA, mas o nessus também é uma excelente escolha. A bem da verdade, dependendo do ambiente, recomenda-se o uso das duas ferramentas alternadamente. Observe que o uso desses aplicativos é extremamente simples não exigindo uma explanação maior neste texto. Mas o leitor já deve ter percebido que mesmo ferramentas de uso corriqueiro podem ser usado com o objetivo de varredura do sistema em busca de vulnerabilidades. O netstat, por exemplo, é utilizado para informar a situação da conexão de rede local. O nmap estende essa funcionalidade, permitindo efetuar varreduras em outras máquinas. Dessa maneira, esses dois aplicativos podem ser utilizados para checar as portas abertas em uma dada máquina, bem como as conexões de rede ativas. Com isso, é possível melhorar a arquitetura do firewall e detectar uso incorreto da rede local. Outro aplicativo na mesma filosofia do nmap é o ntop, disponível em http://www. ntop.org. O ntop, entre outros, pode ser utilizado para medida e monitoramento de

Prevenção e Detecção de Intrusos

tráfego. Se implementado em um gateway, pode ser usado para verificar o fluxo da rede, inclusive com gráficos estatísticos se utilizado através de sua interface WWW.

6.5

VERIFICADORES DE INTEGRIDADE DE ARQUIVOS

Uma questão crítica no que se refere à segurança é a garantia de confiança no sistema. Em geral, tão logo o invasor obtém acesso ao sistema, sua primeira providência é a de garantir continuidade desse acesso. Uma das estratégias utilizadas para isso é o uso de rootkits. Esses programas consistem em versões modificadas de aplicativos comuns ou mesmo do kernel. Mesmo sem o uso de rootkits, pode ocorrer do invasor instalar um novo aplicativo que lhe dê acesso privilegiado. Assim, o administrador deve verificar periodicamente a integridade dos arquivos instalados no sistema. Para isso, várias ferramentas podem ser utilizadas. Em geral, todas são baseadas em se fazer um checksum dos arquivos para posterior comparação. Se os arquivos forem alterados, o checksum do arquivo irá diferir daquele feito anteriormente. Como o único momento em que se pode “confiar” na máquina é o momento de sua instalação, esse deve ser o momento também de se criar o checksum inicial. Essa recomendação é independende do aplicativo utilizado para fazer essa checagem. Assim, tão logo tenha instalado o sistema os checksums iniciais devem ser criados. Não que isso não possa ser feito após a instalação, mas daí não haverá garantias de alteração do período de instalação até esse processo inicial. Entre os aplicativos utilizados para calcular checksums, talvez o mais usado seja o md5sum, disponível na maioria das distribuições. Entretanto, dependendo da complexidade do sistema, pode ser mais interessante utilizar-se do AIDE (http://www.cs.tut.fi/ ~rammer/aide.html) ou do Tripwire (http://www.tripwire.org/), dois aplicativos específicos para verificação de integridade de arquivos. Exemplos de instalação e uso desses dois últimos aplicativos podem ser obtidos em (VILELA, 2001). Merece ainda um especial destaque o chkrootkit, um kit de aplicativos para a detecção de rootkits instalados na máquina. Esse kit pode ser obtido em http://www. chkrootkit.org/ e contém a colaboração ativa de desenvolvedores brasileiros. Uma descrição detalhada do chkrootkit pode ser obtida em (MURILO; STEDING-JESSEN, 2001).

6.6

DETECTORES ATIVOS DE INTRUSÃO

Nesta seção o interesse recai sobre o processo de detecção de intrusão ativa. Esse processo refere-se principalmente ao uso de ferramentas que monitoram o sistema ou, principalmente, a rede, efetuando ações pré-estabelecidas tão logo algo estranho seja detectado. A filosofia, de certa forma, é extremamente simples, o IDS analisa continuamente

EDITORA - UFLA/FAEPE - Segurança Computacional

o sistema ou a rede e tão logo reconheça um padrão estranho, algum mecanismo de alerta ou de defesa é acionado, dependendo do caso. Nesse sentido, é possível dizer que sistemas IDS funcionam de forma semelhante aos sistemas anti-vírus ativos, que continuamente ficam analisando arquivos inseridos no computador ou que chegam via rede. Uma tentativa de invasão, assim como um vírus, pode ser detectada por um padrão. Não será de estranhar se, num futuro próximo, as empresas desenvolvedoras de anti-vírus acabem por inserir ferramentas IDS em seus produtos ou transformar seus produtos em IDS. Entre as ferramentas IDS mais conhecidos no contexto do Linux, merecem especial destaque: o Snort, o PortSentry e o Hostsentry. É interessante observar que existem inúmeros outros aplicativos nessa filosofia, inclusive alguns projetos de origem nacional podem ser descobertos na Freshmeat (http://www.freshmeat.net/), utilizando-se o termo de busca “Intrusion Detection System”. O autor deste trabalho, inclusive, encontra-se em estágio inicial de desenvolvimento de uma ferramenta IDS baseada em modelos biológicos. O Snort (http://www.snort.org/) é um dos IDS ativos mais utilizados em ambiente UNIX. Ele possui um arquivo de assinaturas bastante completo e exige pouco esforço computacional da máquina onde é instalado. O Snort é, a princípio, um sniffer que filtra pacotes a que tem acesso. Dessa maneira, qualquer tráfego estranho irá gerar uma ação do Snort. As ações do Snort podem ir desde alerta em terminal de root, envio de e-mails ou simples armazenamento em arquivo de registros. Essas ações podem ser configuradas, no arquivo /etc/snort.conf de acordo com o tipo de padrão detectado. Assim, padrões considerados mais perigosos irão gerar ações mais imediatas. A Figura 6.6 apresenta um exemplo de registro efetuado pelo Snort, mostrando o uso de scanner de segurança e um ataque ao servidor WWW. O Portsentry e Hostsentry fazem parte do Projeto Abacus, que ainda inclui o Logsentry, uma alternativa ao LogWatch, abordado na Seção 6.2. Esses aplicativos não possuem código aberto, mas podem ser distribuídos e utilizados gratuitamente. Nesse projeto, o Portsentry verifica as conexões de rede, enquanto o Hostsentry fica atento aos logins efetuados na máquina. Assim, ele emite alertas para logins em horários feitos em horários não costumeiros ou logins por usuário que não possuem freqüência de acesso ao servidor, podendo indicar uso dessa conta numa invasão. O Projeto Abacus era desenvolvido pela Psionic (http://www.psionic.com), que foi adquirida recentemente pela Cisco. Assim, não é possível obter os programas diretamente do site da Cisco (pelo menos até o momento de edição dessa apostila). Mas, esses programas podem ser obtidos em vários outros sites, como por exemplo a RPMFind (http://www.rpmfind.net).

Prevenção e Detecção de Intrusos

04/25-09:46:26.111024 [**] [1:1917:3] SCAN UPNP service discover attempt [**] [Classification: Detection of a Network Scan] [Priority: 3] {UDP} 192.168.150.147:1044 -> 239.255.255.250:1900 04/25-09:46:29.156434 [**] [1:1917:3] SCAN UPNP service discover attempt [**] [Classification: Detection of a Network Scan] [Priority: 3] {UDP} 192.168.150.147:1044 -> 239.255.255.250:1900 04/25-09:46:32.160706 [**] [1:1917:3] SCAN UPNP service discover attempt [**] [Classification: Detection of a Network Scan] [Priority: 3] {UDP} 192.168.150.147:1044 -> 239.255.255.250:1900 04/25-09:48:17.409438 [**] [1:1243:8] WEB-IIS ISAPI .ida attempt [**] [Classification: Web Application Attack] [Priority: 1] {TCP} 200.206.184.115:4567 -> 200.131.251.7:80 04/25-09:48:17.479919 [**] [1:1002:5] WEB-IIS cmd.exe access [**] [Classification: Web Application Attack] [Priority: 1] {TCP} 200.206.184.115:4567 -> 200.131.251.7:80

Figura 6.6: Exemplo de Registro do Snort

Ainda quanto à detecção de intrusos, merece especial atenção o LIDS (Linux Intrusion Detection System – Sistema de Detecção de Intrusos para Linux). Esse aplicativo consiste na verdade em um patch para o kernel adicionando novas funcionalidades ao Linux para detecção de intrusos. De certa maneira, essa abordagem pode ser a mais interessante para uma maior segurança. Entretanto possui a necessidade de recompilação do kernel, o que traz inconveniências para seu uso.

EDITORA - UFLA/FAEPE - Seguranรงa Computacional

7 CONCLUSÃO

Não existem soluções mágicas para segurança computacional, que deve ser entendida como um processo e não como um objetivo. Além disso a forma como esse conceito é utilizado depende do ambiente em questão, o que implica que cada instituição precisa definir sua própria política de segurança. Alguns procedimentos, entretanto, podem ser tidos como básicos e devem ser verificados com especial atenção: 1. tomar excessivo zelo e cuidado com o uso da conta do superusuário; 2. manter os aplicativos atualizados com relação às falhas de seguranças; 3. checar a origem de um aplicativo antes de instalá-lo; 4. cuidar para que os usuários escolham boas senhas; 5. evitar ao máximo disponibilizar aplicativos e serviços que requerem senhas em texto puro, como telnet ou POP simples; 6. usar serviços criptografados sempre que for trafegar dados importantes, usando SSL ou SSH, por exemplo; 7. configurar adequadamente a autenticação dos usuários, fazendo uso inteligente do PAM; 8. desabilitar serviços não utilizados; 9. configurar adequadamente o iptables para um firewall seguro para o sistema; 10. utilizar periodicamente ferramentas de verificação, bem como analisar os arquivos de registros; para checar a segurança do sistema; 11. manter um sistema adequado de backup; 12. garantir segurança física para os equipamentos, principalmente servidores.

EDITORA - UFLA/FAEPE - Segurança Computacional

Esses procedimentos, se implementados corretamente, não irão garantir um site 100% seguro, um caso para ficção científica. Mas dificultarão em muito a ação do invasor, desmotivando sua ação. Nesse sentido, o administrador deve estar atento para o fato que segurança computacional é uma filosofia de trabalho diário e não algo para se conseguir após uma seqüência de passos. Outro ponto importante que precisa ficar claro é que sistemas de firewall não representam a melhor parte das ações de segurança: muitas vezes a invasão é feita por um usuário legítimo do sistema, ou alguém utilizando sua conta. Um firewall, nesse caso, não seria de tão grande valia assim. Nesse sentido, o administrador precisa estar atento e implementando outras ações, como as listadas anteriormente, de forma a melhorar a segurança computacional das máquinas que é responsável.

REFERÊNCIAS BIBLIOGRÁFICAS

ANONYMOUS. Maximum Linux Security: A Hacker’s Guide to Protecting Your Linux Server and Workstation. Indianapolis: Sams, 2000. BRASIL. Decreto-Lei No. 2.848, de 7 de Dezembro de 1940: Código Penal. Diário Oficial da União, 31 dez. 1940. Disponível em: <http://www.presidencia.gov.br/ccivil 03/DecretoLei/Del2848.htm>. BURGISS, H. Security Quick-Start HOWTO for Linux, v.1.2, 2002-07-21. 2002. The Linux Documentation Project [WWW]. URL: http://www.ibiblio.org/pub/Linux/docs/ HOWTO/Security-Quickstart-HOWTO. BURGISS, H. Security Quick-Start HOWTO for Red Hat Linux, v.1.2, 2002-07-21. 2002. The Linux Documentation Project [WWW]. URL: http://www.ibiblio.org/pub/ Linux/docs/HOWTO/Security-Quickstart-Redhat-HOWTO. CALLAS, J.; DONNERHACKE, L.; FINNEY, H.; THAYER, R. OpenPGP Message Format. Internet Engineering Task Force (IETF), Novembro 1998. (Request for Comments: 2440). URL: http://www.ietf.org/. DIERKS, T.; ALLEN, C. The TLS protocol version 1.0. Internet Engineering Task Force (IETF), Janeiro 1999. (Request for Comments: 2246). URL: http://www.ietf.org/. DOMINGUES, M. A.; SCHNEIDER, B. de O.; UCHÔA, J. Q. Autenticação em sistemas Linux usando OpenLDAP. In: Semac2001 - XII Semana da Computação - IV Workshop em Linux, Internet e Aplicações. São José do Rio Preto: UNESP, 2001. URL: http://www.comp.ufla.br/~joukim/extensao/. DOOREN, R. van. Quota mini-HOWTO, v.03 April 2002. 2002. The Linux Documentation Project [WWW]. URL: http://www.ibiblio.org/pub/Linux/docs/HOWTO/mini/ Quota.

EDITORA - UFLA/FAEPE - Segurança Computacional

FENZI, K. Linux Security HOWTO, v.2.0, 11 June 2002. 2002. The Linux Documentation Project [WWW]. URL: http://www.ibiblio.org/pub/Linux/docs/HOWTO/ Security-HOWTO. FRAMPTON, S. Linux Administration Made Easy. [S.l.]: The Linux Documentation Project, 1999. URL: http://www.tldp.org/guides.html. HATCH, B.; LEE, J.; KURTZ, G. Hacker Expostos Linux: Segredos e Soluções para a Segurança do Linux. São Paulo: Makron-Books, 2002. KIRCH, O.; DAWSON, T. The Linux Network Administrator’s Guide; Version 1.1. 2. ed. [S.l.]: The Linux Documentation Project, 2000. URL: http://www.tldp.org/guides.html. MANN, S.; MITCHELL, E. L. Linux System Security: An Administrator’s Guide to Open Source Security Tools. New Jersey: Prentice-Hall, 2000. MOLLARD, M. F. v. GNU Privacy Guard (GnuPG) Mini Howto Version 0.1.3. The GNU Privacy Guard – GnuPG.org, 17 de Maio 2002. URL: http://www.gnupg.org/ [Uma tradução brasileira pode ser encontrada em http://www.cipsga.org/]. MORGAN, A. G. Pluggable Authentication Modules (PAM). Open-PAM working group, December 2001. (Internet Draft). URL: http://gandalf.neark.org/pub/linux/ libs/pam/pre/doc/current-draft.txt. MORGAN, A. G. The Linux PAM System Administrators’ Guide; Draft v0.76. [S.l.]: Linux-PAM, 2002. URL: http://www.us.kernel.org/pub/linux/libs/pam/. MORGAN, A. G. 2003. URL: http://www.kernel.org/pub/linux/libs/pam/. MURILO, N.; STEDING-JESSEN, K. Métodos para detecção local de rootkits e módulos de kernel maliciosos em sistemas Unix. In: Anais do 3. Simpósio Sobre Segurança em Informática – SSI 2001. São José dos Campos: CTA/ITA/IEC, 2001. p. 133–139. NEMETH, E.; SNYDER, G.; SEEBASS, S.; HEIN, T. R. UNIX System Administration Handbook. 2. ed. New Jersey: Prentice-Hall, 1995. NEMETH, E.; SNYDER, G.; SEEBASS, S.; HEIN, T. R. UNIX System Administration Handbook. 3. ed. New Jersey: Prentice-Hall, 2001. RUSSEL, R. Linux 2.4 Packet Filtering HOWTO, v.1.19, 2001/05/26. 2001. The Netfilter/Iptables Project [WWW]. URL: http://www.netfilter.org/. SAMAR, V.; SCHEMERS, R. Unified login with Pluggable Authentication Modules (PAM). Open Software Foundation, October 1995. (Request For Comments: 86.0). URL: http://gandalf.neark.org/pub/linux/libs/pam/pre/doc/rfc86.0.txt.gz.

Referências Bibliográficas

SCHNEIER, B. Applied Cryptography. New York: John Wisley, Inc., 1996. SICA, F. C.; UCHÔA, J. Q. Gerenciamento de Sistemas Linux. 2. ed. Lavras: UFLA/FAEPE, 2004. (Curso de Pós Graduação “Lato Sensu” (Especialização) a Distância em Administração em Redes Linux). SOARES, L. F. G.; LEMOS, G.; COLCHER, S. Redes de Computadores: das LANs, MANs e WANs às Redes ATM. 2. ed. Rio de Janeiro: Campus, 1995. STANFIELD, V.; SMITH, R. W. Linux System Administration. San Francisco: Sybex, 2001. (Craig Hunt Linux Library). UCHÔA, J. Q. Segurança em Redes e Criptografia. Lavras: UFLA/FAEPE, 2003. (Curso de Pós Graduação “Lato Sensu” (Especialização) a Distância em Administração em Redes Linux). UCHÔA, J. Q.; SIMEONE, L. E.; SICA, F. C. Administração de Redes Linux. Lavras: UFLA/FAEPE, 2003. (Curso de Pós Graduação “Lato Sensu” (Especialização) a Distância em Administração em Redes Linux). UCHÔA, K. C. A. Introdução à Cibercultura. 3. ed. Lavras: UFLA/FAEPE, 2003. (Curso de Pós Graduação “Lato Sensu” (Especialização) a Distância em Administração em Redes Linux). VILELA, A. V. Estudos de Técnicas de Prevenção e Detecção de Intrusos. [S.l.]: DCC/UFLA, 2001. (Monografias de Graduação DCC/UFLA). http:/www.comp.ufla. br/~joukim/extensao/intruso.pdf. WEBER, R. F. Segurança na internet. In: Anais da XIX JAI - Jornada de Atualização em Informática. Curitiba: PUCPR, 17 a 21 de julho de 2000. WILSON, M. D. VPN HOWTO Revision 2.0. The Linux Documentation Project, 30 de Maio 1999. URL: http://www.ibiblio.org/pub/Linux/docs/HOWTO/Module-HOWTO. WIRZENIUS, L.; OJA, J.; STAFFORD, S. The Linux System Administrator’s Guide; Version 0.7. [S.l.]: The Linux Documentation Project, 2001. URL: http://www.tldp.org/ guides.html.