Apostila Seguranca

Curso de Ps-Graduao Lato Sensu (Especializao) a Distncia Administrao em Redes Linux
SEGURANA COMPUTACIONAL
2a Edio
Joaquim Quinteiro Ucha
Universidade Federal de Lavras UFLA Fundao de Apoio ao Ensino, Pesquisa e Extenso FAEPE Lavras MG
PARCERIA UFLA Universidade Federal de Lavras FAEPE Fundao de Apoio ao Ensino, Pesquisa e Extenso REITOR Antnio Nazareno Guimares Mendes VICE-REITOR Ricardo Pereira Reis DIRETOR DA EDITORA Marco Antnio Rezende Alvarenga PR-REITOR DE PS-GRADUAO Joel Augusto Muniz PR-REITOR ADJUNTO DE PS-GRADUAO LATO SENSU Marcelo Silva de Oliveira COORDENADORA DO CURSO Ktia Cilene Amaral Ucha PRESIDENTE DO CONSELHO DELIBERATIVO DA FAEPE Edson Amplio Pozza EDITORAO Grupo Ginux (http://www.ginux.ufla.br/) IMPRESSO Grca Universitria/UFLA Ficha Catalogrca preparada pela Diviso de Processos Tcnicos da Biblioteca Central da UFLA Ucha, Joaquim Quinteiro Segurana Computacional/ Joaquim Quinteiro Ucha. - - 2.ed. Lavras: UFLA/FAEPE, 2005. 59 p. : il. - Curso de Ps-Graduao Lato Sensu (Especializao) a Distncia: Administrao em Redes Linux. Bibliograa. 1. Segurana Computacional. 2. Criptograa. 3. Deteco de Intrusos. 4. Firewall . 5. Gerenciamento de Usurios. I. Ucha, J. Q. II. Universidade Federal de Lavras. III. Fundao de Apoio ao Ensino, Pesquisa e Extenso. IV. Ttulo. CDD-005.8 -0001.6425 Nenhuma parte desta publicao pode ser reproduzida, por qualquer meio ou forma, sem a prvia autorizao.
SUMRIO
1 Introduo 2 Conceitos Bsicos 2.1 Comentrios Iniciais . . . . . . . . . . . . . . . . 2.1.1 Polticas de Segurana e Polticas de Uso 2.2 Crime Virtual . . . . . . . . . . . . . . . . . . . . 2.3 Ataques Mais Comuns . . . . . . . . . . . . . . . 3 Uso de Criptograa 3.1 Conceitos Bsicos . . . . . . . . . . . . . 3.2 Algoritmos Criptogrcos . . . . . . . . . 3.3 Protocolos Criptogrcos . . . . . . . . . 3.4 Criptograa e Segurana Computacional 4 Segurana por Controle de Acesso 4.1 Comentrios Iniciais . . . . . . . . 4.2 Segurana Fsica e Backups . . . 4.3 O Uso de TCP-Wrappers . . . . . 4.4 Uso de Firewalls ou Proxies . . . . 4.5 Congurao Segura de Servios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 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 55 57
5 Administrao Segura de Usurios 5.1 Uso do PAM (Pluggable Authentication Modules) 5.2 Protegendo Contas de Usurios . . . . . . . . . 5.3 Segurana no Sistema de Arquivos . . . . . . . . 5.4 Comentrios Finais . . . . . . . . . . . . . . . . . 6 Preveno e Deteco de Intrusos 6.1 Comentrios Iniciais . . . . . . . . . . . . 6.2 Vericao dos Registros (Logs) . . . . . 6.3 Evitando Exploits . . . . . . . . . . . . . . 6.4 Uso de Ferramentas de Varredura . . . . 6.5 Vericadores de Integridade de Arquivos . 6.6 Detectores Ativos de Intruso . . . . . . . 7 Concluso Referncias Bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . .
LISTA DE FIGURAS
3.1 Processos Criptogrcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Conceito de VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 5.1 5.2 5.3 5.4 5.5 5.6 6.1 6.2 6.3 6.4 6.5 6.6 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 Congurao do iptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17 22 25 26 26 27 27 28 29 30 34 35 35 36 37 39 45 46 47 49 50 53
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 . Execuo do Comando ulimit-a . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LISTA DE TABELAS
3.1 Opes Mais Usadas do gpg . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Recursos Limitados pelo pam_limits . . . . . . . . . . . . . . . . . . . . . 5.2 Atributos de Arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21 37 41
1
INTRODUO
Este texto tem por principal objetivo instruir o seu leitor nos conceitos bsicos relativos segurana em redes de computadores, sob o enfoque do sistema operacional Linux. Esses conceitos incluem os passos bsicos necessrios administrao segura de um servidor Linux, mas no somente. Observe que ao processo de gerenciamento de um servidor, d-se o nome de administrao de servios ou administrao de redes, j abordados em (UCHA; SIMEONE; SICA, 2003). O administrador de redes moderno no pode relegar esse assunto a um segundo plano. Com a evoluo das redes de computadores, o nmero de invases tem crescido assustadoramente. Isso aumentou no somente a necessidade de segurana, como tambm a necessidade de privacidade por parte dos sistemas e dos usurios. Assim, existe uma grande necessidade do administrador estar em constante atualizao quanto utilizao de procedimentos para aumentar o nvel de segurana dos sistemas computacionais sob seu domnio. Como forma de subsidiar o leitor de uma fundamentao terica sobre o assunto, o Captulo 2 apresenta uma discusso sobre polticas de segurana e polticas de uso. Alm disso, esse captulo aborda as questes legais envolvendo segurana, inclundo-se o conceito de crime virtual. J o Captulo 3 apresenta os conceitos bsicos de criptograa, apresentando a diferenciao entre protocolo e algoritmo de criptograa. Utilizando-se tcnicas criptogrcas, esse captulo mostra ainda como fazer transporte seguro de dados. Segurana por controle de acesso abordada no Captulo 4. Entre outras tcnicas, esse captulo orienta o leitor sobre o uso dos TCP-wrappers e rewall. J tcnicas de administrao segura de usurios so vistas no Captulo 5, inclundo-se o uso do PAM, sudo e quotas em disco. Por sua vez, mtodos de preveno e deteco de intrusos so apresentados no Captulo 6. Este texto foi escrito pensando em um usurio intermedirio do sistema operacional Linux (ou equivalente). Ele foi produzido principalmente a partir da experincia adquirida pelos autores em administrao de laboratrios e uso de diversos sistemas operacionais. Essa experincia em administrao de sistemas foi enriquecida pela leitura de diversos materiais, destacando-se, principalmente: (NEMETH et al., 1995), (NEMETH et al., 2001), (STAN-
EDITORA - UFLA/FAEPE - Segurana 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 referncias devem ser acrescidos vrios 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 Segurana em Redes e Criptograa, deste mesmo autor (UCHA, 2003). Joaquim Quinteiro Ucha, autor deste texto, licenciado em Matemtica pela Universidade Federal de Mato Grosso (UFMT), com mestrado em Cincia da Computao pela Universidade Federal de So 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 trs ltimos SOs(?), apesar de ter desenvolvido averso a alguns tipos de janelas. Foi o responsvel pela instalao do primeiro laboratrio 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 Computao e Inteligncia Articial. 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.
Howto um pequeno guia que ensina um usurio a congurar um servio ou fazer uma dada tarefa. Linux Documentation Project: http://www.tldp.org/. A traduo de parte dos documentos desse projeto podem ser encontrados em http://br.tldp.org/.
2 The
1 Um
2
CONCEITOS BSICOS
2.1 COMENTRIOS INICIAIS
O que segurana computacional ? Esse termo muito utilizado atualmente, mas sem uma conscincia exata a que ele se refere. Isso ocorre principalmente porque esse conceito relativo ao ambiente em que utilizado. O que seguro para uma instituio pode no o ser para outra. Assim, preciso estar atento a qual siginicado o termo est sendo utilizado. Dada a relatividade do termo, preciso reetir sobre quais itens devem ser levados em conta ao se abordar a questo da segurana computacional. Em geral, possvel destacar os seguintes elementos de um ambiente computacional, sob o ponto de vista da segurana: Conana: possvel conar na disponibilidade do sistema? os dados armazenados vo estar acessveis quando forem necessrios? os mecanismos de backups so sucientes para garantir que as informaes armazenadas possam ser recuperadas com facilidade em caso de problemas? Integridade: os dados recuperados so conveis? como garantir que as informaes no foram alteradas na fonte ou no trfego de dados? como garantir que o que foi acessado idntico ao que foi armazenado? Condencialidade: como certicar que os dados s podem ser acessados por quem de direito? como garantir a privacidade dos usurios e dos dados? como impedir a espionagem de informaes? Essas questes iro chamar a necessidade do administrador estar reetindo: o que segurana computacional em meu ambiente? A essa questo, logo vir outra, talvez de maior importncia: qual o item mais importante para a segurana computacional: rewalls? backups? anti-sniffers? tunelamento e criptograa?
10
A resposta a essa pergunta extremamente simples: o elemento mais importante para se garantir segurana em uma rede de computadores o estabelecimento de uma poltica de segurana. Enquanto a instituio no dene o que mais importante para o estabelecimento da segurana computacional em seu ambiente, as atitudes so tomadas sem a devida conscincia e sem garantir um mnimo desejvel de segurana:
Uma Poltica de Segurana incorpora os resultados de uma anlise 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 usurios, procedimentos de instalao de sistemas ... (MANN; MITCHELL, 2000) Uma poltica de segurana um conjunto de leis, regras e prticas que regulam como uma organizao gerencia, protege e distribui suas informaes e recursos. Um dado sistema considerado seguro em relao a uma poltica de segurana, caso garanta o cumprimento das leis, regras e prticas denidas nessa poltica. (SOARES; LEMOS; COLCHER, 1995)
a poltica de segurana que vai deixar claro o que deve ter acesso restrito e o que pode ser liberado sem problemas. ela que dene quais so os itens que precisam ser preservados, bem como quais so as pessoas que tem acesso a determinados recursos. Sem uma poltica de segurana clara, no se sabe o que vai se proteger, nem porque ou qual a melhor forma. Uma boa poltica de segurana ir denir, por exemplo, como ser estabelecida a poltica de uso. Essa poltica de uso responsvel por deixar claro o que o usurio pode e no pode fazer com determinados recursos. Em geral, tal poltica um documento a ser assinado pelo usurio em questo. 2.1.1 Polticas de Segurana e Polticas de Uso
intil elaborar uma poltica de segurana que sirva apenas de enfeite na parede. Assim, uma poltica de segurana deve possuir as seguintes caractersticas: ser implementvel atravs de procedimentos de administrao de sistema, regras de uso, ou outros mtodos apropriados; ser reforada com ferramentas de segurana e sanes; denir claramente as reas de responsabilidade para usurios e administradores do sistema.
Conceitos Bsicos
11
Dessa maneira, atentando-se para essas diretrizes, possvel elaborar uma poltica de segurana vlida para o ambiente em questo. Alm disso, imprescindvel que a poltica de segurana atente-se para os seguintes itens: Segurana fsica: como os equipamentos da instituio em questo sero protegidos? Como garantir a integridade fsica dos dados? Como garantir que no haver acesso fsico 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 funcionrio recm demitido pode roubar o HD do servidor para vender ao concorrente. Segurana lgica: como garantir integridade lgica dos dados? Como os dados da instituio em questo sero protegidos? Como garantir que no haver acesso lgico indevido a dados? Quais so os dados mais importantes? Os casos de invases tem-se tornado cada vez mais freqentes e imprescindvel estar atento a isso. Privacidade: o que fazer para proteger a privacidade dos usurios? A instituio ir proteger essa privacidade? Observe que a instituio deve estar atenta aos aspectos legais dessa questo. Legalidade de Software: como garantir um bom uso dos recursos, impedindo a pirataria? A responsabilidade pelos aplicativos instalados de quem? da empresa? do usurio? Isso precisa estar claro. Em geral, quando se trata de segurana computacional deve-se adotar a poltica do menor privilgio, ou seja, liberar apenas os recursos necessrios ao usurio. Observe que, em alguns ambientes, essa uma questo altamente subjetiva. Mas deve-se sempre ter em mente que o que no expressamente permitido deve ser proibido. Alm disso, imprescindvel que o administrador pratique vigilncia e perseverana, assumindo sempre que os mal-intencionados sabem mais que ele. Tenha em mente que a adoo de uma poltica de segurana ir, na maioria das vezes, implicar em perda de performance ou convenincia do usurio. Alguns servios devem ser evitados e isso gera problemas para usurios mais inexperientes. Alm disso, o trfego criptografado ocupa maior largura de banda, diminuindo a velocidade de transmisso de dados. Assim, deve-se pesar os prs e contras de qualquer atitude envolvendo segurana antes de implement-la. Em termos prticos, como expressa a poltica de segurana? O leitor deve estar pensando em documentos impressos. Entretanto no se deve esquecer que a poltica no apenas papel: ela envolve leis, regras e prticas. Dependendo do ambiente, bvio a necessidade de documentao, mas isso no a nica forma de criar uma poltica de segurana. Em geral, a poltica de segurana documentada da maior parte das instituies consiste das normas de uso dos recursos e uma poltica de uso. A poltica de uso um documento que deixa claro o que o usurio pode e no pode fazer com os recursos dentro da
12
instituio. Para garantir validade jurdica desse documento, imprescindvel a sua validao pela assinatura do usurio ou em contrato coletivo de trabalho.
2.2
CRIME VIRTUAL
Outra questo fundamental que est relacionada questo da segurana computacional o conceito de crime virtual. Nesse sentido imprescindvel distinguir, ao menos em termos prticos, os conceitos de crime de computador e crime por computador. Essa distino permite compreender melhor quais tipos de crime so cobertos pela lei e quais no o so. Assim, crime por computadores so os crimes tradicionais cometidos por meios computacionais. Dessa maneira, por exemplo, tipicam-se o roubo ou o assassinato por computador. O leitor atento pode estar um pouco assustado agora, imaginando como poderia ser possvel um assassinato por computador, esquecendo-se que o assassino poderia invadir o sistema computacional de um hospital, por exemplo, e alterar a medicao de um paciente para doses fortes de substncias a que ele tenha alergia. comum, portanto, a ocorrncia 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 deteno de 3 meses a 1 ano de deteno ou multa, conforme o Art. 146 do Cdigo Penal (BRASIL, 1940). Enviar e-mail com ameaa de agresso pode render pena de 1 a 6 meses de deteno ou multa, de acordo com o Art. 147. Assim, observe que apenas modicou-se o meio, o crime continua tipicado. De forma semelhante, so tipicados crimes de invaso de privacidade, envio de vrus de computador, pedolia ou montagem de sites com receitas de bombas ou similares. Por outro lado, existem aqueles crimes que s existem no ambiente computacional, no existindo equivalente no ambiente no tecnolgico: so os crimes de computador. Nesse contexto, por exemplo, o Brasil no tem uma legislao contra invaso de sites. Quando o invasor no faz uso de informaes obtidas com essa invaso (o que poderia caracterizar espionagem industrial) ou no faz alteraes dos dados (o que poderia caracterizar crime de dano, vandalismo ou pichao), ca difcil caracterizar a invaso como uma contraveno penal. Alguns pases possuem legislao forte a esse respeito, como o caso dos EUA e da China. No Brasil, paraso dos invasores, essa discusso est apenas no incio. Mesmo assim, o administrador que teve seus sistemas invadidos deve vericar os mecanismos legais a que pode recorrer de forma a punir os autores da faanha. Nesse contexto, inclusive, cabe chamar a ateno para os movimentos Hackers e Ciberativismo. Cabe tambm chamar a ateno para o fato que o termo hacker no costuma
Conceitos Bsicos
13
ser utilizado com sentido negativo em meio tecnolgico. Nesse ambiente, utiliza-se o termo cracker para os hackers que invadem sistemas com nalidades ilcitas. Na cultura geral, entretanto, o termo hacker tomado de forma indistinta, geralmente com signicado pejorativo para invasor. Para uma abordagem mais formal sobre essa discusso, ver (UCHA, 2003).
2.3
ATAQUES MAIS COMUNS
Como um servidor encontra-se geralmente acessvel via internet e em tempo integral, ele mais suscetvel a ataques de todos os tipos e formas que uma estao de trabalho. Dependendo de sua congurao, entretanto, possvel torn-lo to ou mais seguro que estaes de trabalho com acesso mnimo internet. Com a nalidade de melhor situar o leitor, segue-se uma relao dos principais tipos de ataque e termos correlatos: Footprinting: Por footprinting entende-se a tarefa de coletar informaes sobre um sistema alvo. Essa coleta feita por vias tradicionais e pblicas, como uso do comando finger, leitura de pginas do site para obter dados interessantes, etc. Geralmente o invasor ir vericar quem o responsvel pela admnisitrao do sistema, uma vez que invadida a conta desse usurio possvel obter dados mais signicativos. Scanning: Um scanner um utilitrio que verica vulnerabilidades. Pode ser um scanner de sistema, quando checa vulnerabilidades na mquina local (erros no /etc/passwd, permisso incorreta de arquivos, etc.), ou pode ser um scanner de rede, quando faz varredura de portas de redes, vericando quais esto abertas e, principalmente, quais esto mais vulnerveis. O objetivo principal desse tipo de ataque descobrir falhas de segurana devido a bugs em servios de rede ou ausncia de proteo para servios internos. Sniffers: Principalmente dentro de uma rede fsica, onde facilitada, um ataque muito utilizado a espionagem eletrnica, com o uso de sniffer. Um sniffer um aplicativo que ca escutando todos os pacotes de dados que trafegam por uma dada placa de rede. importante observar que, em vrias topologias de rede, um pacote passa por vrias placas entre a origem e o destino. Alm disso, cabe observar que, para que interceptar mensagens destinadas outras mquinas, a estao deve colocar sua interface de rede em modo promscuo1 . Esse ataque objetiva principalmente a captura de senhas de usurios internos, uma vez que isso facilita ao invasor a entrada no sistema para deteco de vulnerabilidades. Outro objetivo desse ataque a captura de informaes condenciais em trnsito na rede.
modo promscuo entende-se a congurao de uma interface de rede em que ela captura no apenas os pacotes de rede direcionados a ela, mas tambm os destinados a outras estaes em um mesmo segmento de rede.
1 Por
14
Spoong: Por spoong entende-se a tarefa de fazer uma mquina se passar por outra, forjando, por exemplo, pacotes IPs. Em geral, o usurio ir tentar bloquear o envio de pacotes de dados de uma mquina, tentando se passar por ela. Uma conexo SSH com um mquina usando spoof iria acusar o ataque do Man-In-The-Middle, j comentado em (UCHA; SIMEONE; SICA, 2003). Caso o administrador use transporte criptografado de dados e senhas e esteja atento s chaves utilizadas, esse ataque dicilmente ir comprometer a integridade dos dados e servios. Denial of Service (DoS): Pouca ateno tinha sido dado aos ataques de negao de servio at a derrubada de servidores importantes, como Amazon, Yahoo e mesmo UOL. Como pode ser subentendido, o DoS um ataque que busca derrubar um servio ou mesmo um servidor inteiro. Ultimamente tem sido utilizado do DDoS (Distributed DoS), onde um atacante utiliza vrias mquinas zumbis para enviar inmeras requisies, 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 vrus do Apache, que fazia com que um dado servidor Web casse enviando grande quantidade de dados pela rede, conduzindo o trfego de rede a uma lentido insuportvel. Cdigo Malicioso: Cdigo malicioso, como o nome j sugere, um software criado com nalidades mal intencionadas. Nessa categoria incluem-se os cdigos no autorizados (geralmente contidos dentro de um programa legtimo) que efetuam aes desconhecidas e no desejadas pelo usurio. Tambm so includos nessa categoria os programas legtimos que foram alterados para efetuar aes no desejadas pelo usurio. Outro tipo de cdigo malicioso so aqueles que destroem dados sem a inteno do usurio. Alguns tipos de cdigo maliciosos merecem destaque: Cavalos de Tria: Um cavalo de tria, ou trojan horse ou apenas trojan um programa de computador alterado com nalidades ilcitas. Por exemplo, um atacante poderia substituir o /bin/login para no s autenticar usurios, como tambm armazenar essas senhas em um arquivo oculto. Vrus: Vrus so semelhantes a trojans, dado que efetua ao no desejada pelo usurio. Uma das diferenas reside no fato que o vrus, uma vez ativado, ir infectar outros arquivos locais. A grosso modo, vrus no podem infectar mquinas externas sem o auxlio de uma pessoa. Vermes: Um verme um programa que pode infectar tanto a mquina local, quanto mquinas remotas, geralmente utilizando falhas de protocolos, servios ou aplicativos. Como observado por (HATCH; LEE; KURTZ, 2002), a maior parte dos programas perniciosos existentes so hbridos dessas trs categorias. Como exemplo, tem-se o Melissa que era um cavalo de tria (se passava por um e-mail que o usurio estivesse
Conceitos Bsicos
15
esperando), um vrus (infectava todos os arquivos locais de processamento de texto) e um verme (usava uma falha do Outlook para se propagar a todos os usurios na agenda de endereos do usurio). Observe que, no senso comum, vrus e verme so geralmente tomados com um nico signicado, sendo usado apenas o termo vrus. Por exemplo, o vrus do Apache era, a bem da verdade, um verme (se propagava a outras mquinas usando o Apache), mas como no infectava outros arquivos no servidor, no poderia ser considerado necessariamente um vrus. Um tipo de trojan extremamente perigoso so 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 usurio ou verses alteradas do prprio kernel. Exploits: Exploits so programas criados para explorar falhas, advindas principalmente de bugs nos daemons de servios. Entre as falhas mais exploradas, encontram-se buffer overow, que consiste em estourar o buffer de entrada de um servidor, forando-o a estourar sua memria, devolvendo um shell para o invasor. Ataques de Senhas: Esse tipo de ataque consiste em tentar descobrir a senha de um ou mais usurios por fora bruta ou usando tcnicas heursticas. Em geral, o invasor tenta obter uma cpia das senhas e efetuar um ataque de dicionrio: utilizando variaes de palavras em uma dada lista (o dicionrio), tenta-se confrontar a senha do usurio com essas variaes at descobrir uma que permita o acesso. Uma observao nal que determinados ataques so a bem da verdade tambm ferramentas de segurana. Assim, por exemplo, um scanner pode ser utilizado para vericar em que pontos um sistema est vulnervel. Um programa de ataque de senha pode ser utilizado para checar se os usurios no esto utilizando senhas fceis, o que facilitaria uma invaso. Alm disso, alguns sistemas poderosos de deteco de intrusos so tambm sniffers. Sniffers tambm costumam ser utilizados para detectar problemas em uma rede.
16
3
USO DE CRIPTOGRAFIA
3.1 CONCEITOS BSICOS
A rpida evoluo das comunicaes eletrnicas suscitou uma srie de necessidades para que se evitassem problemas de espionagem. Entre essas necessidades, destaca-se o uso de sistemas criptogrcos. Mesmo em ambientes de telefonia celular, por exemplo, o uso de criptograa cada vez mais utilizado. Como denido em (SCHNEIER, 1996), a criptograa a arte e cincia 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) Encriptao ou Cifragem Texto Cifrado (C) Decriptao ou Decifragem Mensagem (M)
Figura 3.1: Processos Criptogrcos
A criptograa possui estrita relao com a criptoanlise, arte e cincia de quebrar mensagens cifradas. O ramo da Matemtica envolvendo criptograa e criptoanlise chamado de criptologia. Como bem observado em (SCHNEIER, 1996), modernos criptolgos precisam ter domnio em Matemtica Terica, uma vez que sobre ela que se sustenta a criptologia atual. O uso da criptograa antigo, sendo comuns o seu uso em guerras, mesmo desde o imprio romano. Esse uso era principalmente para manter a condencialidade da mensagem, garantindo que apenas emissor e receptor pudessem interpret-la. De certa maneira, a computao foi fortemente nanciada durante a Segunda Guerra Mundial para inveno de dispositivos que pudessem decodicar as mensagens dos alemes. Desse esforo, inclusive, participou Alan Turing, um dos mais importantes tericos da Computao e um dos pais da Inteligncia Articial.
18
Mas o uso da criptograa no se restringiu condencialidade. Cada vez mais novos usos da criptograa se fazem necessrio, sendo essencial para o comrcio eletrnico. Entre os usos da criptograa, alm da condencialidade, destacam-se (SCHNEIER, 1996): Autenticao: importante para o receptor da mensagem ter certeza que o autor da mensagem quem diz s-lo; dessa maneira, um invasor no pode se passar por outra pessoa. Integridade: essencial garantir que a mensagem no foi alterada durante seu trnsito; dessa maneira, um invasor no pode substituir uma mensagem legtima por uma falsa. Autoria: em determinadas mensagens, como o uso de dinheiro eletrnico, essencial garantir que quem envia a mensagem no possa negar que tenha feito isso em um momento posterior ao envio.
3.2
ALGORITMOS CRIPTOGRFICOS
Um algoritmo criptogrco, tambm denominado cifra, uma funo matemtica usada para criptografar ou decriptografar uma mensagem. Em geral, so utilizadas duas funes 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 segurana de um algoritmo criptogrco reside em sua obscuridade, ou seja, o desconhecimento de seu teor por terceiros. Essa segurana restrita e deve ser evitada para usos mais srios da criptograa. O motivo que tcnicas no avanadas de criptoanlise e engenharia reversa podem quebrar facilmente essa segurana. Para evitar esse problema, a criptograa 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 encriptao da mensagem idntica utilizada na decriptao, diz-se que o algoritmo utiliza chaves privadas ou que um algoritmo simtrico. Observe que isso exige que o receptor da mensagem conhea a chave utilizada pelo emissor. Isso pode complicar o processo criptogrco, uma vez que se a chave for descoberta por um invasor, a conana na mensagem perdida.
Uso de Criptograa
19
Entre os algoritmos simtricos mais conhecidos e utilizados merecem destaque o DES (Data Encryption Standard), o Blowsh e o IDEA (International Data Encryption Algorithm). O IDEA patenteado, mas pode ser utilizado sem restrio para uso no-comercial, sendo utilizado no PGP. J o DES e o Blowsh so algoritmos de domnio pblico. O DES muito utilizado em uma verso alternativa que utiliza trs chaves, o 3DES. O OpenSSH utiliza principalmente 3DES ou Blowsh para criptografar o trnsito de dados. Blowsh foi desenvolvido por Bruce Schneier, que descreve em detalhes esses e outros algoritmos simtricos em (SCHNEIER, 1996). J nos algoritmos assimtricos, tambm chamados de algoritmos de chave pblica, so utilizadas duas chaves: uma para criptografar e outra para decriptografar a mensagem. Graas a processos matemticos, possvel escolher chaves de tal forma que o conhecimento de uma no signique que a outra chave possa ser descoberta, ao menos em termos prticos. Assim, a chave para criptografar posta em pblico 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 pblica 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 pblica, o mais conhecido com certeza o RSA, que caiu em domnio pblico em setembro de 2000. Entre as alternativas mais conhecidas, encontram-se o ElGamal e o DSA, que so utilizados pelo GnuPG, um aplicativo para criptograa e assinatura digital de uso pessoal.
3.3
PROTOCOLOS CRIPTOGRFICOS
Um protocolo uma srie de passos, envolvendo duas ou mais partes, designado para a realizao de uma tarefa (SCHNEIER, 1996). Um protocolo criptogrco um protocolo que usa criptograa. Um protocolo criptogrco envolve o uso de algoritmos criptogrcos, mas no se restringe a isso. Um protocolo pode envolver vrios outros passos, como mecaniscos de contato entre emissor e receptor e troca de chaves. Um exemplo conhecido de protocolo criptogrco o protocolo de rede SSL (Secure Socket Layer). Esse protocolo foi criado pela Netscape para disponibilizao de sites protegidos, tendo seu uso estendido a outras reas. talvez o protocolo criptogrco mais utilizado atualmente. Uma implementao bastante conhecida do SSL no contexto do software livre, a OpenSSL (http://www.openssl.org/). Essa biblioteca implementa as verses 2 e 3 do SSL, bem como a verso 1 do TLS (Transport Layer Security). O TLS um protocolo criado recentemente para substituir o SSL, ampliando seu uso e funcionalidade, sendo descrito
20
em (DIERKS; ALLEN, 1999). O uso do SSL em servios WEB detalhado no Captulo 5 de (UCHA; SIMEONE; SICA, 2003). Outro protocolo criptogrco muito utilizado no mundo UNIX o SSH, utilizado para conexes remotas seguras. O SSH possui vrias implementaes, algumas comerciais. Entre as de cdigo aberto, merece destaque a OpenSSH (http://www.openssh.org/). A OpenSSH permite a substituio do Telnet com vantagens, alm de oferecer outros servios, como o sFTP (Secure FTP), um FTP seguro. O uso da OpenSSH foi descrito no Captulo 8 de (UCHA; SIMEONE; SICA, 2003). Os protocolos SSH e SSL funcionam de uma maneira parecida: inicialmente feita uma conexo usando algoritmos de chave pblica. Aps isso, so trocadas chaves criadas aleatoriamente usando esses algoritmos. Aps a troca dessas chaves, o trfego feito utilizando algoritmos de chave privada, uma vez que exigem menor esforo computacional.
3.4
CRIPTOGRAFIA E SEGURANA COMPUTACIONAL
A criptograa exerce papel essencial na segurana computacional. Isso porque ela pode auxiliar signicativamente na garantia de condencialidade e integridade de dados. No contexto do Linux, a criptograa pode ser utilizada de vrias formas, desde o aspecto de uso pessoal at a implementao de VPNs (Virtual Private Networks - Redes Privadas Virtuais). No campo da criptograa pessoal, merece destaque o GnuPG (GNU Privacy Guard), uma verso aberta do PGP (Pretty Good Privacy). O GnuPG implementa mecanismos de cifragem de dados e assinaturas digitais, estando em conformidade com o padro OpenPGP, descrito em (CALLAS et al., 1998). importante ressaltar que o GnuPG implementa apenas algoritmos no patenteados, ao contrrio do PGP. Isso garante a total liberdade do projeto. O GnuPG possui uso extremamente simples, sendo que a maioria dos clientes de email possuem integrao direta com ele. O principal utilitrio disponibilizado pelo GnuPG o gpg, sendo que suas opes mais usadas so listadas na Tabela 3.1. Mais detalhes sobre o GnuPG podem ser encontrados na documentao 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 opes para conferir se o autor de um pacote quem arma ser. Isso extremamente importante para garantir a integridade de um aplicativo sendo instalado, evitando que se instale trojans ou rootkits inocentemente. Em geral, as distribuies disponibilizam chaves pblicas para conferir a autenticidade dos pacotes distribudos por elas. Caso se pretenda criptografar no s um arquivo mas todo um diretrio, ento o uso de sistemas de arquivos criptografados pode ser uma tima escolha. Existem vrios pro-
Uso de Criptograa
21
Tabela 3.1: Opes Mais Usadas do gpg
Opo - -sign - -encrypt - -decrypt - -edit-key - -genkey - -list-key - -list-sigs - -sign-key - -import - -export - -armor
Descrio 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 fora exportao de chaves em modo texto
jetos nessa losoa, merecendo destaque o CFS, disponvel em http://www.crypto. com/software, e o TCFS, disponvel em http://www.tcfs.it/. Detalhes de uso desses aplicativos podem ser encontrados na documentao desses pacotes e em (MANN; MITCHELL, 2000). Quanto ao transporte de dados, a criptograa tem sido usada sob a forma de tneis criptogrcos. So exemplos desses tneis os protocolos SSL e SSH. Vrios servios podem ser tunelados utilizando esses protocolos. A documentao 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 tneis criptogrcos o stunnel, disponvel em http://stunnel.mirt.net/. O stunnel foi projetado para trabalhar como um tnel criptogrco usando SSL entre clientes e servidores de servios padres. Dessa maneira, o stunnel pode ser usado para adicionar funcionalidade SSL a aplicaes 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 criptogrco utilizado pelas VPNs. Uma rede privada virtual consiste em um tnel criptogrco entre duas ou mais redes tendo o trfego em ambiente pblico, como ilustrado na Figura 3.2. Nesse caso, praticamente quase todo o trfego entre as duas redes criptografado. Para se implementar uma VPN, vrias alternativas so possveis. possvel utilizarse apenas de PPP e SSH, como ilustrado em (WILSON, 1999). Mas tambm possvel utilizar-se do protocolo IPSec, implementado no FreeS/WAN (http://www.freeswan.
22
Tnel Criptogrfico Internet
Figura 3.2: Conceito de VPN
org/). Nesse caso todo o trfego IP entre duas redes criptografado. Outra alternativa com a mesma losoa do IPSec o CIPE, disponvel em http://sites.inka.de/sites/ bigred/devel/cipe.html. Consulte as pginas desses projetos para maiores detalhes.
4
SEGURANA POR CONTROLE DE ACESSO
4.1
COMENTRIOS INICIAIS
At pouco tempo atrs, a segurana de redes era baseada principalmente em controle de acesso. Denir as permisses para cada usurio, estabelecer uma rede de conana entre mquinas e usurios, usar servios autenticados por senha eram atitudes que tornavam redes sucientemente seguras. Atualmente as redes de conana j no garantem segurana, pois o trfego nocriptografado facilita a escuta de dados (snifng ), que tornou-se comum. Dessa forma, houve um crescente uso da criptograa, em especial o uso de tneis criptogrcos, abordados no Captulo 3. Entretanto, novos mecanismos de segurana por controle de acesso surgiram, com o objetivo de proteger no os dados em si, mas sim o servidor, evitando invases. Incluem-se nesses novos mecanismos o desenvolvimento crescente de novas ferramentas de rewall, por exemplo. Dessa maneira, este captulo aborda as principais tcnicas e ferramentas para uma adequada segurana por controle de acesso.
4.2
SEGURANA FSICA E BACKUPS
Segurana fsica muitas vezes menosprezada. Entretanto, ainda um item essencial para um ambiente computacional. Anal, de nada adianta um servidor estar utilizando mecanismos poderosos de rewall se um visitante qualquer pode roubar seu disco rgido 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 no se conar em senhas de BIOS ou de boot loaders que esses mecanismos no impedem o acesso aos dados do servidor. Senhas de BIOS podem ser burladas com relativa facilidade ou mesmo apagadas. Por outro lado, possvel iniciar uma mquina a partir de outro dispositivo (um disquete, CD-ROM, outro disco rgido, etc.) e acessar os dados armazenados. Sistemas de arquivo criptografados dicultariam o acesso a esses
24
dados, mas so mais lentos que os tradicionais e ainda no encontram-se difundidos a contento. Outra questo importante nesse mesmo contexto a necessidade de uma poltica efetiva de cpias de segurana. Sem backups peridicos, um sistema no atende aos critrios mnimos de disponibilidade dos dados. Em determinados ambientes, por exemplo, esse um item extremamente crtico na administrao de servidores. Projetos recentes tm inclusive surgido no contexto extremo de cpias de segurana. Cada vez mais surgem estratgias de Alta Disponibilidade, que consistem em mecanismos para fazer com que um dado servio esteja online o maior tempo possvel. Nesse caso, so utilizados servidores redundantes, sincronizao de dados online, entre outras tcnicas. Uma pergunta deve estar rondando a cabea do leitor: qual a melhor ferramenta e estratgia de backup? A resposta clara e efetiva : depende. No existe uma ferramenta adequada a todas as situaes e muito menos uma estratgia funcional para todas as instituies. Dessa maneira, o administrador ter que no s escolher a ferramenta, como tambm escolher o procedimento que ser utilizado nesse processo. Para denir essa ferramenta e a estratgia, algumas perguntas devem ser respondida: quo importantes so os dados armazenados? a perda deles implicaria em quanto tempo de prejuzo para serem restaurados? As respostas a essas perguntas podem indicar claramente as necessidades, em termos de cpia de segurana, por parte da instituio.
4.3
O USO DE TCP-WRAPPERS
Vrios daemons, ao invs de serem inicializados por seus prprios meios, so gerenciados pelo tcpd. Nesse caso, possvel ltrar os pacotes direcionados aos servios oferecidos por esses daemons usando os TCP-Wrappers. Esses ltros consistem de duas frentes, como ilustrado na Figura 4.1: os arquivos /etc/hosts.allow e /etc/hosts.deny e a congurao do inetd ou do xinetd. O xinetd um substituto poderoso do inetd. Dessa maneira, este texto no ir abordar o uso do inetd. importante observar que nem todas as aplicaes podem ser inicializadas via xinetd ou inetd. Alm disso, algumas poucas aplicaes que no so controladas por esses servios, podem ser ltradas pelo uso dos arquivos hosts.allow e hosts.deny no diretrio /etc/. Mas, em geral, utiliza-se esses arquivos apenas para essas aplicaes. Com o xinetd, inclusive, possvel no utilizar esses arquivos para obter os mesmos resultados. Observe que, de certa forma, os servios oferecidos pelos TCP-Wrappers equivalemse a um tipo de rewall. Entretanto, existe o fato de que esse rewall restrito s aplicaes com suporte biblioteca libwrap. Ainda: em geral possvel obter os mesmos efeitos
Segurana por Controle de Acesso
25
Clientes
telnet
Servidor
syslogd configurao do xinetd ou inetd in.telnetd in.imapd imap xinetd ou inetd
finger
tcpd
in.fingerd in.ftpd in.popd
ftp rsync
hosts.allow e hosts.deny
Figura 4.1: Uso de TCP-Wrappers
obtidos com os TCP-Wrappers utilizando-se ferramentas de rewall integradas ao kernel, como iptables ou ipchains. Mesmo assim, seu uso recomendado, por fornecer uma camada extra de proteo aos servios. Como j comentados, os TCP-Wrappers so implementados pelo servidor tcpd. Eles controlam o acesso baseado em IP, estando, portanto, sujeitos a spoong. O acesso a um cliente feito da seguinte forma: 1. o acesso garantido quando um par (servio, cliente) casa uma entrada no arquivo /etc/hosts.allow; 2. o acesso negado quando um par (servio, cliente) casa uma entrada no arquivo /etc/hosts.deny; 3. caso no esteja permitido ou negado nos passos anteriores, o acesso garantido. Dessa maneira, possvel ltrar efetivamente os servios gerenciados via tcpd. Em geral, dada essa seqncia de passos adotada pelo tcpd, costume negar todos os servios no arquivo /etc/hosts.deny, como ilustra a Figura 4.2. Dessa forma somente obtero acesso aos servios os clientes habilitados no arquivo /etc/hosts.allow, exemplicado na Figura 4.3. Uma observao a ser feita que os dois arquivos so congurados de forma semelhante, usando a mesma sintaxe. Note que, na Figura 4.3, possvel habilitar uma mensagem inicial de login (um banner) para servios habilitados aos TCP-Wrappers. Dessa maneira, de acordo com o exem-
26
# arquivo hosts.deny # nega-se tudo (ALL indica todos os servios 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 mquinas especficas 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 exceo da mquina superman in.telnetd: ALL EXCEPT superman
Figura 4.3: Exemplo de Arquivo /etc/hosts.allow
plo dessa gura, possvel editar o arquivo /etc/security/ftp.banner para imprimir uma mensagem de alerta quando iniciar uma conexo FTP. O xinetd e o inetd podem ser entendidos como superservidores que chamam outros servidores atravs do tcpd. Assim, alm dos arquivos /etc/hosts.allow e /etc/ hosts.deny, possvel efetuar ltragem de servios na congurao desses superservidores. A congurao do xinetd feita inicialmente no arquivo /etc/xinetd.conf, exemplicado na Figura 4.4. Em geral, como mostra a Figura 4.4, o arquivo /etc/xinetd.conf contm apenas as conguraes padres do xinetd (tipo de log, etc.) e uma diretiva para incluir os arquivos no diretrio /etc/xinetd.d. Dessa maneira, para facilitar a congurao, cada servio congurado em um arquivo especco nesse diretrio. A Figura 4.5 mostra um exemplo de servio congurado dessa forma. No caso da Figura 4.5, possvel perceber o uso da diretiva only_from para limitar o acesso a determinados servios para determinadas mquinas ou redes. Dessa maneira, estabelece-se mais uma barreira para impedir acesso no autorizado a determinados servios.
27
# xinetd.conf # configuraes padres defaults { instances log_type log_on_success log_on_failure cps }
= = = = =
60 SYSLOG authpriv HOST PID HOST 25 30
# inclui configuraes no diretrio /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 # usurio 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 segurana por controle de acesso o uso de rewall. Chega a se dar tamanha importncia aos rewalls que muito comum encontrar administradores que se esquecem dos outros elementos necessrios a um ambi-
28
ente seguro. Nesse sentido, importante alertar que um bom rewall tem grande potencial para a segurana mas no seu elemento nico e muito menos o mais importante. Em determinadas situaes, inclusive, seu uso pode nem ser necessrio. Existem vrias denies possveis para o termo rewall. 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), responsvel por ltrar os pacotes, evitando o acesso externo a determinados servios. Nesse sentido, pode-se dizer que os TCP-Wrappers constituemse num mini-rewall.

Rede Externa Rede Interna
Firewall

Figura 4.6: Uso de Firewall
Outra questo importante nesse contexto o conceito de proxy. Um proxy um software que atua como ponto entre duas redes, controlando o trfego de acordo com seu contedo. Em geral, um proxy utilizado para servir como cache WWW ou FTP, mas pode ser utilizado para ltrar a rede, de forma que pode ser usado como rewall. Por outro lado, uma ferramenta de rewall pode ser congurada 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 rewall mais utilizada atualmente no Linux. Ele substitui o ipchains, acrescentando inmeras funcionalidades. O uso do iptables foi ilustrado no Captulo 3 de (UCHA; SIMEONE; SICA, 2003). No site de desenvolvimento do iptables, http://www.netfilter.org/, podem ser encontrados excelentes tutoriais sobre seu uso, inclusive em bom portugus. Em especial, recomenda-se a leitura de (RUSSEL, 2001).
29
Dado que j considerado que o leitor tenha conhecimentos de uso do iptables, resta apenas abordar o seu uso como ferramenta de rewall. Nesse sentido, o administrador deve estar atento a quais portas de servios ele ir permitir acesso. A poltica do menor privilgio a recomendada: liberar apenas as portas essenciais. Um arquivo extremamente til para o administrador o /etc/services. Esse arquivo lista as portas padres utilizadas pelos servios 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 padres apresentadas no arquivo /etc/services, a Figura 4.8 mostra um exemplo comentado de congurao salva pelo utilitrio iptables-save. Essa congurao foi extrada de uma estao de trabalho. Para um servidor outras portas deveriam ser abertas. O administrador dever fazer a congurao de acordo com a realidade local.
30
# 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 conexo j estabelecida -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # aceita todas as conexes locais (internas mquina) -A INPUT -s 127.0.0.1 -j ACCEPT # aceita todas as conexes da prpria mquina (IP local = 192.168.0.50) -A INPUT -s 192.168.0.50 -j ACCEPT # aceita conexes ICMP (ping, etc.) da prpria rede -A INPUT -s 192.168.0.0/255.255.255.0 -p icmp -m state --state NEW -j ACCEPT # aceita conexes SSH de qualquer lugar -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT # aceita comunicao grfica 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 sada (isso deve ser modificado em servidores) :OUTPUT ACCEPT COMMIT # Completed on Sat Apr 19 17:01:10 2003
Figura 4.8: Exemplo de Congurao do iptables
4.5
CONFIGURAO SEGURA DE SERVIOS
Alm do uso de tcnicas de ltragem de pacotes, alguns aplicativos permitem conguraes extras que tornam o seu uso mais seguro, tanto para o cliente como para o servidor. Uma primeira congurao a ser feita pelo administrador vericar qual o usurio utilizado para inicializar o servidor. A inicializao de servios sob a gide do superusurio deve ser evitada ao mximo possvel. Em geral, verses mais recentes dos aplicativos j fazem isso automaticamente para o administrador. O uso de aplicativos que trafegam senhas em claro deve ser evitado ao mximo, pois esto sujeitos escuta eletrnica (sniffers). Assim, o telnet deve ser substitudo por SSH. Alm disso, o uso do POP comum (no seguro) tambm deve ser substitudo pelo POP seguro (no suportado por todos os clientes) por IMAP seguro (tambm no suportado por todos os clientes) ou por servios de WebMail via HTTPS. O FTP no-annimo tambm deve ser substitudo pelo SFTP.
31
Observe que a adoo dessas medidas ir, na maioria das vezes, implicar em perda de performance ou convenincia do usurio. Ainda no existem muitos clientes grcos com suporte ao SFTP. O uso de POP seguro tambm no trivial, sendo que a maioria dos clientes de e-mail da Microsoft no suportam esse tipo de transporte de e-mail. O uso de WebMails uma alternativa mais interessante, mas pode dicultar o uso por usurios iniciantes e tende a aumentar o trfego na rede. Quanto aos servios de e-mail, necessrio congurar os servidores para evitar o uso por qualquer estao. No sendmail, isso pode ser feito habilitando-se o uso do access_db e utilizando o arquivo /etc/mail/access para listar as estaes que podem utilizar o servidor para envio de correio eletrnico. Alm disso, recomendvel que seja congurado o tamanho mximo de arquivo a ser recebido ou enviado. O uso de NIS, por sua vez, deve ser totalmente evitado. Sugere-se a cpia de dados por meios criptogrcos ou a substituio do NIS por LDAP (que suporta tunelamento por TLS, a partir de verses mais recentes - como o OpenLDAP 2). Um exemplo de uso do LDAP para autenticao de usurios pode ser encontrado em (DOMINGUES; SCHNEIDER; UCHA, 2001). Uma regra fundamental de segurana usar sempre servidores atualizados ou seguros. Sempre que houver opo de escolha para um dado servio, o servidor mais seguro deve ser escolhido. Assim, no se usa POP, mas POPS ou IMAP, ou mesmo Webmail sob HTTPS. Alm disso, o administrador deve sempre vericar se no existem atualizaes de segurana dos servidores e bibliotecas instalados. Alm disso, deve-se sempre vericar a segurana dos servidores, utilizando-se ferramentas de vericao (como SARA, SATAN ou nessus). Essas ferramentas sero abordadas com mais detalhes no Captulo 6. Um projeto muito interessante nesse sentido o Bastille Linux, disponibilizado em (http://bastille-linux.sourceforge.net/). Ele tem por objetivo congurar uma mquina de forma a aumentar o seu nvel de segurana. Para isso, ele altera conguraes de sistema e de servidores, alm de alterar as regras de rewall. Na opinio deste autor, o uso dessa ferramenta desnecessrio para o administrador experiente, que preferir efetuar suas prprias conguraes. Mesmo para esse usurio, e principalmente para usurios menos experientes, entretanto, pode ser uma ferramenta de grande auxlo. Uma recomendao nal a ser feita que servios que no so usados devem ser desabilitados. Se os usurios no iro precisar de servios internos de FTP, ento o servidor FTP dever estar desabilitado. Uma forma prtica de listar os servios habilitados executar o comando # chkconfig - -list Esse comando ir informar, para cada initlevel, se um dado servio est ou no habilitado.
32
5
ADMINISTRAO SEGURA DE USURIOS
5.1 USO DO PAM (PLUGGABLE AUTHENTICATION MODULES )
Boa parte das distribuies Linux (e mesmo outras variantes do UNIX) utilizam o PAM (Plugabble Authentication Module) para implementar a autenticao de usurios de forma altamente congurvel, como visto em (SICA; UCHA, 2004). Isso permite que a autenticao possa atender s mais diversas necessidades de uma instituio qualquer. Utilizando o PAM, o administrador pode escolher o sistema de autenticao que mais lhe convier e no se preocupar em como as aplicaes iro interpretar isso. O PAM permite ainda que se controle vrios outros itens de usurios, entre eles: limites de recursos, uso de senha escondida (shadow), limite de acesso, shell restrito, etc. As conguraes do PAM propriamente dito so efetuadas no diretrio /etc/pam.d/. Recomenda-se a leitura de (SICA; UCHA, 2004) e (MORGAN, 2002) para maiores detalhes sobre o processo de congurao. Uma descrio mais formal do PAM pode ser encontrada em (MORGAN, 2001) e (SAMAR; SCHEMERS, 1995). Como o processo de autenticao do usurio crucial para a segurana de um dado sistema, existem alguns mdulos PAM1 que podem se utilizados para incrementar essa segurana. Entre eles merecem destaque: pam_limits, pam_listfile, pam_access, pam_time, pam_cracklib e pam_wheel. O mdulo pam_cracklib, do tipo password responsvel por fazer uma checagem mnima de segurana e tamanho de uma senha sendo trocada. Ele utiliza a biblioteca CrackLib, uma verso resumida e em biblioteca do Crack, um programa para ataques de dicionrios, o que ser visto na Seo 5.2. Ao usar essa biblioteca, o pam_cracklib diculta a escolha de senhas baseadas em senhas de dicionrios. O mdulo pam_cracklib permite ainda que se dena o tamanho mnimo de uma senha e incentivar, por mecanismos de crdito, o uso de maisculas e minsculas, bem como smbolos e nmeros. Consulte a documentao do PAM para detalhes de implementao e uso desse mdulo.
que o termo mdulo PAM, que seria traduzido como mdulo de mdulos plugveis de autenticao um produto do Departamento Organizacional de Redundncia Repetida.
1 Observe
34
Com o uso do mdulo pam_wheel, possvel limitar quem pode executar o comando su. Na Figura 5.1 apresentado um exemplo de arquivo /etc/pam.d/su congurado para usar esse mdulo. Nesse exemplo, possvel vericar que a congurao geral do comando su ser copiada do arquivo /etc/pam.d/system-auth. As nicas excees so os mdulos pam_rootok e pam_wheel. Com o uso de pam_rootok, o usurio root pode usar o su sem necessidade de autenticao.
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 congurao apresentada na Figura 5.1, com o uso do pam_wheel, os usurios do grupo wheel podem usar o su sem necessidade de digitar a senha do usurio. Isso possvel pelo parmetro trust utilizado. Observe que essa opo altamente desrecomendada na grande maioria dos casos. Na sequncia da Figura 5.1, caso o usurio no seja root ou esteja no grupo wheel, o PAM ir vericar se o usurio faz parte do grupo super. Em caso negativo, o acesso ao su ser negado. Em caso positivo, ser exigido a senha do usurio 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 congurao do arquivo /etc/pam.d/ chsh para impedir que os usurios listados no arquivo /etc/security/nochsh possam utilizar o comando chsh. Com isso, possvel que o administrador possa escolher shells restritos para determinados usurios (como o rsh) e evitar que eles alterem esse shell para um outro qualquer. No caso da Figura 5.2, os parmetros do mdulo pam_listfile indicam como ele deve agir na autenticao do usurio. O parmetro onerr especica o que deve ser feito em caso de falha (erro de leitura do arquivo, etc.). Esse parmetro pode receber os valores fail ou succeed. O parmetro item, por sua vez, especica o que est contido na lista. Ele pode receber os valores user e group, entre outros. O parmetro file especica onde est o arquivo com a lista. J o parmetro sense especica se para negar (deny) ou permitir (allow) acesso aos membros da lista.
Administrao Segura de Usurios
35
auth auth auth account password session
sufficient required 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 mdulo PAM de controle de acesso o pam_access. Esse mdulo, do tipo account permite a congurao de acesso por local. Assim, por exemplo, possvel restringir o acesso de usurios a partir de determinadas mquinas. Para isso, basta habilitar esse mdulo na aplicao desejada e editar o arquivo /etc/security/access.conf, como exemplicado na Figura 5.3.
# SINTAXE dada por "permisso (+ permite, - nega) : usurios : origem" # pode-se usar LOCAL para acesso de console e ALL para todos. # EXCEPT indica exceo # Impedindo acesso de console, com exceo de algumas contas # observe que pode ser usado grupo ou usurio -:ALL EXCEPT wheel shutdown sync root:LOCAL # Impede acesso remoto do usurio root -:root:ALL EXCEPT LOCAL # usurio lennon s pode logar da rede beatles.com -:lennon:ALL EXCEPT .beatles.com # usurio harrison s pode logar da rede 110.220 -:harrison:ALL EXCEPT 110.220. # negando acesso a todos os outros usurios -:ALL:ALL Figura 5.3: Exemplo de Arquivo /etc/security/access.conf
Limitao de acesso por tempo feito com o uso do mdulo pam_time. Esse mdulo, do tipo account, permite restringir o acesso de servios PAM a uma faixa de horrio
36
por usurios. Para tanto, utilizado um arquivo de congurao, localizado em /etc/ security/time.conf, exemplicado na Figura 5.4. Consulte a documentao do PAM para maiores detalhes.
# # # # # # # # SINTAXE dada por "servios;terminais;usurios;tempo" tempo dado por uma lista de dias/faixa horria Mo = segunda, Tu = tera, We = quarta, Th = quinta, Fr = sexta, Sa = sbado, Su = domingo, Wk = finais de semana Wd = segunda sexta, Al = todos os dias Se o dia for repetido, ento ele desconfigurado Assim, AlMo significa todos os dias exceto segunda & = e lgico, | = ou lgico, ! = negao
# root acessa qualquer servio 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 conexes 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 mdulo pam_limits. Esse mdulo, do tipo session permite limite de uso dos recursos da mquina. A Tabela 5.1 apresenta os tipos de limites que so limitados com uso desse mdulo. Utilizando as informaes da Tabela 5.1, a Figura 5.5 apresenta um exemplo de congurao do mdulo pam_limits. Essa congurao ca localizada no arquivo limits.conf no diretrio /etc/security. Observe que o usurio root no afetado pela maioria dos limites impostos pelo mdulo pam_limits. Outra observao importante que, como esse um mdulo de sesso, ele estipula o limite por sesso do usurio. Assim, uma congurao global deve levar em conta a congurao do recurso maxlogins Como pde ser percebido nesta seo, o PAM uma ferramenta poderosa para segurana de usurios. Alm dos mdulos aqui apresentados, mdulos PAM adicionais podem ser utilizados para implementar outros controles e limites. Recomenda-se a leitura de (MORGAN, 2002) e (MORGAN, 2003) para maiores detalhes.
37
Tabela 5.1: Recursos Limitados pelo pam_limits
Recurso core data fsize memlock nofile rss stack cpu nproc as maxlogins priority locks
Descrio limita o tamanho (em KB) de arquivos core tamanho mximo de dados (em KB) tamanho mximo de arquivo (em KB) espao mximo (em KB) de endereamento de memria reservada nmero mximo de arquivos abertos tamanho mximo (em KB) de memria residente tamanho mximo (em KB) de pilha de memria tempo mximo (em minutos) de uso da CPU nmero mximo de processos limite de espaos de endereamento nmero mximo de logins prioridade com a qual so rodadas as aplicaes nmero mximo de arquivos aos quais possvel fazer lock
# SINTAXE dada por "usurios terminais # tipo pode ser # hard (para limites rgidos) # soft (para limites leves) # grupo pode ser indicado por "@" # limita arquivos core em tamanho 0 * hard core 0 # limita uso da memria em 10Mb * hard rss 10000
tipo
recurso
valor"
# limita nmero de processos para o grupo student @student soft nproc 30 @student hard nproc 60 # limita o nmero de logins do grupo student @student - maxlogins 4 Figura 5.5: Exemplo de Arquivo /etc/security/limits.conf
38
5.2
PROTEGENDO CONTAS DE USURIOS
O superusurio o administrador do sistema. O acesso de superusurio deve ser evitado sempre que possvel. Nesse sentido, o aplicativo sudo permite que o acesso como superurio seja evitado, permitindo maior restrio em divulgar a senha do administrador em um ambiente onde existam vrias pessoas administrando servios de rede. Geralmente o aplicativo sudo disponibilizado com a maioria das distribuies. Aps a instalao, deve-se editar o arquivo /etc/sudoers, especicando quem pode utiliz-lo e com quais poderes. Esse arquivo de fcil edio, possuindo vrios exemplos comentados. Alm disso as pginas de manual do sudo e do sudoers so bastante instrutivas, sendo recomendada a leitura desse material. Outra questo importante no que se refere ao gerenciamento seguro de usurios garantir que as senhas de usurio esto protegidas e foram escolhidas de forma correta. Isso ocorre porque uma das estratgias de invaso utilizada pelos hackers atravs da obteno de acesso autorizado, utilizando a senha de um usurio comum do sistema. Uma vez obtido o acesso de um usurio, muito mais fcil descobrir vulnerabilidades e falhas de segurana. Assim, importante garantir que as senhas dos usurios 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 ttica do hacker : programas de quebra de senha para detectar senhas fracas. Essa quebra baseada em dicionrio de palavras. Dois aplicativos se destacam nessa tarefa: o John The Ripper e o Crack. extramente recomendvel que o administrador faa vericaes peridicas, usando aplicativos tipo o John ou o Crack. Pode ser o caso, inclusive, de se bloquear o acesso de contas com senhas extremamente fceis (sobrenome ou palavras simples). Obviamente, isso no descarta a necessidade de orientar os usurios para uma boa escolha de senhas, como j alertado em (SICA; UCHA, 2004). Outra observao importante que extremamente necessrio fazer checagens peridicas no arquivo /etc/passwd, procurando entradas incorretas ou estranhas. Em geral, invasores costumam criar contas extras com poderes de root (com UID 0). Alm disso, contas inativas devem ter acesso bloqueado ou at mesmo serem removidas do sistema. Tambm essencial que se congure os limites de recursos aos usurios. Como j comentado no Captulo 2, uma medida recomendada de segurana a estratgia do menor privilgio: liberar ao usurio apenas aquilo que ele precisa para desempenhar suas atividades. Nesse caso, alguns limites precisam ser impostos ao usurio de forma automtica. Alguns desses limites podem ser impostos via uso do PAM, como mostrado na Seo 5.1. Outros limites podem ser impostos de vrias maneiras.
39
Um limite extremamente til o uso de quotas de usurio. Isso pode ajudar a manter os usurios menos vorazes em termos de uso de espao em disco e limitar tentativas de invaso interna. O uso e congurao de quotas foi abordado em detalhes no Captulo 6 de (SICA; UCHA, 2004). Consulte esse material, bem como (DOOREN, 2002) para mais detalhes. Uma outra forma de impr limites utilizar o comando interno ulimit do bash. Esse comando permite congurar vrios 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 opo -a usada para imprimir os limites atuais). A sada 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: Execuo do Comando ulimit-a
5.3
SEGURANA NO SISTEMA DE ARQUIVOS
A segurana dos usurios tambm passa por uma congurao adequada dos sistemas de arquivos. Vrias opes de montagens de dispositivos, por exemplo, podem ser utilizadas para incrementar a segurana do sistema como um todo. Sobre montagem de dispositivos, recomenda-se a leitura de (SICA; UCHA, 2004). Em geral, as observaes a serem feitas sobre montagens de dispositivos referem-se s opes de montagem nosuid, nodev e noexec. Como os dispositivos conveis so criados no diretrio /dev/, somente a partio contendo esse diretrio deve possuir permisso para criao e uso de arquivos de dispositivos. Todas as outras parties devem ser montadas com a opo nodev. Por motivos semelhantes, arquivos com SUID no devem
40
ser permitidos no diretrio /tmp ou /home. Donde esses diretrios devem ser montados com a opo nosuid. Em diretrios onde no se pretende que sejam executados aplicativos (como o /tmp ou /home em algumas instituies), deve-se usar opo de montagem noexec. O diretrio /var outro candidato para essas opes de montagem. Entretanto, alguns gerenciadores de listas so instalados no /var ou no /home. Assim, preciso estar atento e checar o sistema aps essas modicaes. Permisses tambm so outro ponto problemtico. O administrador deve estar extremamente atento sobre quais aplicas so executadas com permisses de administrador (com uso de SUID). Para encontrar todas as aplicaes com SUID ou SGID no sistema basta executar o comando # find / -type f \( -perm 04000 -o -perm -02000 \) Aps feita essa vericao, necessrio checar se os aplicativos realmente precisam de SUID/SGID e se no houve alterao inconveniente na lista retornada. Outro problema grave so os arquivos com permisso de escrita global, especialmente arquivos de sistema. Mas mesmo para arquivos comuns de usurios, esse tipo de permisso totalmente inconveniente. Para localizar arquivos desse tipo, basta executar # find / -perm -2 ! -type l
Outra vericao a ser feita a deteco de arquivos sem proprietrio. Eles tanto podem ser restos de usurios excludos 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 questo das permisses, pode ser interessante congurar a permisso padro dos arquivos criados pelos usurios. 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 usurio criador. O valor calculado subtraindo-se a permisso desejada de 777. Assim, caso fosse interessante que os arquivos tambm pudessem ser lidos por outros membros do grupo, poderia ser usado a chamada umask 027. Outro recurso importante para segurana 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
41
Quando chamado com a opao -V, chattr ir imprimir informaes extras sobre a ao sendo executada. Com a opo -R, ele ir atuar de forma recursiva, alterando dados de diretrios e seus contedos. Qualquer atributo seguinte a um sinal de + ir ser adicionado ao arquivo. Atributos seguintes a um sinal de - iro ser removidos do arquivo. Caso pretenda-se exatamente um determinado conjunto de atributos, ento 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 parmetro em um diretrio, 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 so 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 exceo dos atributos c, s e u.
Tabela 5.2: Atributos de Arquivos
Atributo A S a c d i j s u
Descrio no modicar data e hora que arquivo foi acessado (atime) atualizao sncrona com o disco (no usa buffer) arquivo aberto no modo append, ou seja somente pode receber novas informaes em seu nal arquivo comprimido automaticamente pelo kernel arquivo no permite cpia de segurana usando dump arquivo no pode ser modicado nem removido tambm no possvel fazer links no simblicos para o arquivo o arquivo com esse atributo escreve todos os seus dados no journal antes de escrever no prprio arquivo esse atributo s vlido para o ext3 deleo segura (arquivo preenchido com zeros quando apagado) quando o arquivo apagado, seu contedo salvo e o arquivo pode ser recuperado com facilidade
Alguns dos atributos da Tabela 5.2 s podem ser atribudos pelo superusurio. So eles: a e i. Isso ocorre porque um arquivo com o atributo i no pode ser apagado nem
42
pelo usurio root. Antes de apag-lo, necessrio remover o atributo do arquivo. Note que esses atributos, a e i, so os mais importantes do ponto de vista da segurana, junto com o atributo s. Como o atributo s pode no estar implementado na verso do kernel utilizada pelo usurio, pode-se lanar mo de outros mecanismos para deleo segura de arquivos. Deleo segura extremamente recomendvel ao apagar arquivos condenciais. Uma alternativa vivel utilizar-se do srm, um utilitrio 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 tambm disponibiliza o shred. Consulte a pgina de manual desse comando para mais detalhes.
5.4
COMENTRIOS FINAIS
Este captulo objetivou apresentar ao leitor um conjunto de tcnicas prticas e ecientes para uma administrao segura de usurios. Com o uso do PAM, dos utilitrio find e sudo, possvel incrementar sensivelmente a segurana do sistema. Essas tcnicas 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 invaso. O administrador deve estar consciente que o usurio pode ser a porta de entrada para um hacker, facilitando a invaso. Da sua preocupao em garantir a segurana dos mesmos. Outra preocupao do administrador que vrios casos de invaso provm do interior da instituio, dos prprios usurios. Assim, o administrador deve limitar os recursos, adotando a poltica do menor privilgio, e periodicamente fazer checagem de segurana do sistema.
6
PREVENO E DETECO DE INTRUSOS
6.1 COMENTRIOS INICIAIS
Segurana total co, e co de baixa qualidade. Vulnerabilidades so descobertas com freqncia e possvel falar com absoluta tranqilidade que no existem servidores 99% seguros. O que se pode pretender um servidor que oferea tanta diculdade que ele desestimule os invasores. Mas mesmo com esse nvel de diculdade, no possvel conar cegamente no sistema. Dessa maneira, o administrador deve estar utilizando ferramentas de deteco e preveno de intrusos para monitorar o sistema de sua responsabilidade. Dessa maneira, o administrador pode vir a ter condies de impedir que ataques em fase inicial consigam chegar a um nvel indesejado de intruso no sistema. Parte do servio de preveno de intrusos feito com uma implementao de uma poltica de segurana adequada. Obviamente essa poltica deve estar baseada em servios criptogrcos, uma correta congurao de servios e rewall, entre outros. Dessa maneira, a diculdade gerada servir como uma preveno adequada de intrusos. Mas isso no suciente. O processo de deteco de intrusos envolve inmeras estratgias. Geralmente so utilizados ferramentas IDS (Intrusion Detection System - Sistema de Deteco de Intrusos). importante notar que esse termo pode ser usado de vrias 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 invaso encontra-se em ao. Nesse sentido, constituem-se principalmente em programas de monitoramento de conexes de rede, como o Snort. Em uma viso mais ampla, utilizada neste trabalho, tambm so IDS as ferramentas utilizadas para monitorar a integridade do sistema. Nesse caso, tambm podem ser denidos claramente como IDS os vericadores de integridade de arquivos, como o AIDE ou o Tripwire:
Tcnicas de Deteco de Intrusos se aproximam bastante daquelas usadas em Firewalls e sistemas de Log, e o seu objetivo principal reagir a uma invaso (ou suspeita de invaso) no menor intervalo de tempo possvel. Isto pode ser
44
feito, por exemplo, monitorando-se continuamente o trfego de rede, procura de qualquer anomalia, ou ento analisando-se continuamente as ltimas entradas dos arquivos de log, procura de aes suspeitas. (WEBER, 17 a 21 de julho de 2000)
Assim, antes de abordar os IDS propriamente dito, este captulo introduz o leitor em outras tcnicas importantes nesse processo, como a monitorao dos arquivos de registros e uso de ferramentas de varreduras. Essas tcnicas iro auxiliar o administrador a descobrir e evitar vulnerabilidades, corrigindo-as antes de uma possvel invaso.
6.2
VERIFICAO DOS REGISTROS (LOGS )
Uma invaso geralmente deixa rastros. Talvez, inclusive, seja possvel dizer que, da mesma forma que no existe um sistema totalmente seguro, no existe uma invaso perfeita. Assim, a vericao peridica dos arquivos de registros pode evitar surpresas extremamente desagradveis, ao mostrar a tentativa de invaso desde o seu incio. Uma esclarecimento inicial que, em um sistema medianamente seguro, uma invaso um procedimento relativamente demorado. Assim, o leitor deve excluir de sua imaginao a imagem romntica de um hacker que consegue penetrar em um sistema em poucos minutos. A menos que o sistema seja uma peneira de vulnerabilidades, uma invaso ir exigir esforo e pacincia do intruso, que ter que fazer inmeras tentativas para conseguir seu intento. Caso haja uma vericao peridica dos logs, essa invaso pode ser bloqueada em seu incio. Alm disso os arquivos de registros podem indicar falhas em servios, o que poderia comprometer no s a segurana, mas a qualidade do sistema. Outro motivo para a vericao peridica dos logs a possibilidade de vericao de aes anormais no sistema, como logins fora do padro ou tentativas de execuo de aplicaes restritas. Um acesso de um usurio fora do horrio normal, por exemplo, pode indicar que um invasor esteja usando a conta do usurio para encobrir a invaso. Pode ser tambm que esse usurio esteja acessando fora do horrio com nalidades ilcitas, ou seja: ele o invasor. No se deve esquecer que apesar do nmero de invases externas estarem crescendo assustadoramente nos ltimos anos, as invases internas costumam causar, ainda, o maior prejuzo. Os arquivos de log so localizados geralmente no diretrio /var/logs. Merecem especial ateno, sob o ponto de vista da segurana, quatro arquivos nesse diretrio: messages, secure, wtmp e lastlog. O messages um arquivo de registro genrico, com informaes de login, uso do comando su, conexes SSH, entre outros. O arquivo secure armazena informaes restritas segurana do sistema, como uso do sudo e inicializao do servidor SSH.
Preveno e Deteco de Intrusos
45
O arquivo wtmp no pode ser lido diretamente, pois armazena informaes de login no formato binrio. A leitura dos dados nesse arquivo feito via comando last. O comando last exibe todas as conexes efetuadas no sistema, desde a data de incio do arquivo. Na Figura 6.1 apresentada uma forma de uso desse comando para ltrar os ltimos logins do superusurio. A partir da sada do comando, possvel vericar de onde foi feita a conexo e o tempo de durao 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 Figura 6.1: Exemplo de Uso do Comando last
(01:08) (00:13) (00:00)
J o arquivo lastlog, tambm binrio, utilizado pelo comando de mesmo nome, como ilustrado na Figura 6.2. Ele aponta, para cada usurio do sistema qual foi o ltimo login efetuado. Isso pode ser til para vericar se determinadas contas de sistema no esto sendo usadas de forma incorreta. Observando a Figura 6.2, possvel vericar que o comando lastlog informa de onde e quando foi o ltimo login de cada usurio do sistema. Nesse sentido, importante vericar se contas de sistema esto com acesso bloqueado no /etc/shadow, uma vez que ningum ir fazer login direto nessas contas. Essa a congurao padro, mas isso deve ser vericado periodicamente. Ainda com respeito aos arquivos de registros, no podem ser esquecidos os arquivos de log do Apache, geralmente no diretrio /var/log/httpd, e o arquivo de log do servidor de e-mail, o arquivo /var/log/maillog. Atravs de anlises do maillog, possvel detectar quem so os usurios que mais recebem e enviam e-mail. Tambm possvel vericar de onde vem a maioria dos e-mails externos, facilitando o bloqueio a sites que permitem o envio de SPAM. importante vericar que os registros so, em geral, congurveis. Assim, possvel habilitar um nvel extra de informaes. Isso pode possuir duas foras contrrias: quanto mais informaes, mais espao necessrio em disco; alm disso, determinadas informaes extras podem ferir a privacidade dos usurios. Dessa maneira, o usurio precisa estar ciente que determinados tipos de monitoramento esto sendo efetuados na instituio, para evitar problemas legais. Um exemplo desse tipo de monitoramento: possvel congurar o iptables para armazenar informaes de conexes. Dessa forma, possvel saber quem est acessando quem numa dada rede. Tambm possvel aumentar o nvel de informaes do servi-
46
# 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
From
pts/16 pts/0
poseidon hades
Latest Sb 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 nvel de monitorao do envio e recebimento de mensagens eletrnicas. Outro tipo de monitoramento que pode ser feito o uso de contabilidade de processos. Isso feito com o uso do comando psacct, disponvel na maioria das distribuies. Uma vez instalado o pacote, deve-se habilitar o servio 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 usurios. importante observar
47
que, se no claro na poltica de uso, esse tipo de monitoramento pode ser interpretado como ilegal e causar dores de cabea ao administrador. Um utilitrio extremamente til no que se refere monitorao de arquivos de registros o logwatch, tambm disponvel na maioria das distribuies. Em geral, j vem com um script executado diariamente para informar ao superusurio, por e-mail, sobre registros ligados segurana do sistema, como ilustra a Figura 6.3. Nesse exemplo, o logwatch alerta para usos do sudo e conexes ssh do usurio root, alm do uso do sendmail para envio de correio eletrnico.
---------------- 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 invases externas aproveitam-se de bugs nos daemons. Assim, utilizandose desses bugs, criam exploits para explorar essas falhas e tentar obter acesso ao sistema.
48
Quando bem sucedidos, os invasores conseguem um terminal de root sua inteira disposio. Para evitar a ao dos exploits, duas aes so as mais ecazes: 1. Vericar com freqncia sites de segurana sobre anncios de falhas em servios. Em geral, as distribuies mantm pginas a esse respeito, mas esse tipo de informao tambm 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, to logo sejam descobertas falhas de segurana e sejam disponibilizadas atualizaes corrigindo esses bugs. preciso chamar a ateno para o fato que a maioria das invases ocorrem em mquinas h muito desatualizadas e com furos enormes de segurana. Assim, a constante vigilncia essencial para evitar esse tipo de problema.
6.4
USO DE FERRAMENTAS DE VARREDURA
Como j comentado neste texto, algumas ferramentas de segurana podem se transformar em ferramentas de invaso e vice-versa. Esse o caso tpico das ferramentas de varredura. Essas ferramentas tem o objetivo explcito de vericar um sistema em busca de falhas de segurana. Se utilizadas pelo administrador, pode auxili-lo a fechar as brechas encontradas em seu ambiente computacional. Os scanners, como tambm so conhecidas essas ferramentas, tanto podem investigar falhas locais como nos servios de rede. Os mais conhecidos so o nessus, o TARA, o SARA, o SAINT e o SATAN, mas existem vrios outros. importante observar que mesmo ferramentas usuais, como o netstat ou o nmap podem ser utilizados com essa nalidade. O SATAN foi uma das primeiras ferramentas de varredura criadas, tendo inuenciado o surgimento do SAINT e do SARA. Os trs iniciam um navegador a partir do qual so vasculhados os servios de rede de um dado servidor ou um conjunto de mquinas. O SATAN no 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 verses mais antigas. O SARA (Security Auditors Research Assistant ) desenvolvido pela Advanced Research Computing (http://www-arc.com/) e faz parte de um conjunto de programas para vericao de segurana. Entre eles, encontra-se o TARA, um utilitrio para vericao local de segurana, comentado mais frente. A Figura 6.4 mostra um exemplo de checagem de segurana efetuada pelo SARA, onde foram encontradas vrias vulnerabilidades. O SARA pode ser executado para checar vulnerabilidades em uma nica mquina ou em toda uma rede. Obviamente checagens locais conseguem coletar mais informa-
49
Figura 6.4: Vulnerabilidades Encontradas pelo SARA
es. Alm de detectar as vulnerabilidades, o SARA detalha a vulnerabilidade encontrada, documentando-a e apresentando alternativas para correo 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 verso 2.2.4, em 1994, o desenvolvimento do Tiger foi interrompido. As pginas 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 esforos para manter o Tiger atualizado Mais recentemente, esses esforos foram unicados (apesar do TARA ainda ser atualizado independentemente) numa nova verso do Tiger, disponvel em http://www. tigersecurity.org/. Observe que as verses do TARA ainda so mais estveis que o Tiger, mas isso deve mudar num futuro prximo. Esses aplicativos fazem vericaes locais, por exemplo, checagem de segurana nos arquivos de contas de usurios (passwd, shadow e group). O uso desses dois aplicativos altamente recomendado.
50
Figura 6.5: Deltalhamento da Vulnerabilidade no SARA
Um outro aplicativo que no pode faltar nas ferramentas do administrador de redes o nessus, tambm na mesma losoa do SARA. A experincia da equipe do ARL maior com o SARA, mas o nessus tambm 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 no exigindo uma explanao 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 situao da conexo de rede local. O nmap estende essa funcionalidade, permitindo efetuar varreduras em outras mquinas. Dessa maneira, esses dois aplicativos podem ser utilizados para checar as portas abertas em uma dada mquina, bem como as conexes de rede ativas. Com isso, possvel melhorar a arquitetura do rewall e detectar uso incorreto da rede local. Outro aplicativo na mesma losoa do nmap o ntop, disponvel em http://www. ntop.org. O ntop, entre outros, pode ser utilizado para medida e monitoramento de
51
trfego. Se implementado em um gateway, pode ser usado para vericar o uxo da rede, inclusive com grcos estatsticos se utilizado atravs de sua interface WWW.
6.5
VERIFICADORES DE INTEGRIDADE DE ARQUIVOS
Uma questo crtica no que se refere segurana a garantia de conana no sistema. Em geral, to logo o invasor obtm acesso ao sistema, sua primeira providncia a de garantir continuidade desse acesso. Uma das estratgias utilizadas para isso o uso de rootkits. Esses programas consistem em verses modicadas 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 vericar periodicamente a integridade dos arquivos instalados no sistema. Para isso, vrias ferramentas podem ser utilizadas. Em geral, todas so baseadas em se fazer um checksum dos arquivos para posterior comparao. Se os arquivos forem alterados, o checksum do arquivo ir diferir daquele feito anteriormente. Como o nico momento em que se pode conar na mquina o momento de sua instalao, esse deve ser o momento tambm de se criar o checksum inicial. Essa recomendao independende do aplicativo utilizado para fazer essa checagem. Assim, to logo tenha instalado o sistema os checksums iniciais devem ser criados. No que isso no possa ser feito aps a instalao, mas da no haver garantias de alterao do perodo de instalao at esse processo inicial. Entre os aplicativos utilizados para calcular checksums, talvez o mais usado seja o md5sum, disponvel na maioria das distribuies. 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 especcos para vericao de integridade de arquivos. Exemplos de instalao 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 deteco de rootkits instalados na mquina. Esse kit pode ser obtido em http://www. chkrootkit.org/ e contm a colaborao ativa de desenvolvedores brasileiros. Uma descrio detalhada do chkrootkit pode ser obtida em (MURILO; STEDING-JESSEN, 2001).
6.6
DETECTORES ATIVOS DE INTRUSO
Nesta seo o interesse recai sobre o processo de deteco de intruso ativa. Esse processo refere-se principalmente ao uso de ferramentas que monitoram o sistema ou, principalmente, a rede, efetuando aes pr-estabelecidas to logo algo estranho seja detectado. A losoa, de certa forma, extremamente simples, o IDS analisa continuamente
52
o sistema ou a rede e to logo reconhea um padro estranho, algum mecanismo de alerta ou de defesa acionado, dependendo do caso. Nesse sentido, possvel dizer que sistemas IDS funcionam de forma semelhante aos sistemas anti-vrus ativos, que continuamente cam analisando arquivos inseridos no computador ou que chegam via rede. Uma tentativa de invaso, assim como um vrus, pode ser detectada por um padro. No ser de estranhar se, num futuro prximo, as empresas desenvolvedoras de anti-vrus 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 inmeros outros aplicativos nessa losoa, 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 estgio inicial de desenvolvimento de uma ferramenta IDS baseada em modelos biolgicos. 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 esforo computacional da mquina onde instalado. O Snort , a princpio, um sniffer que ltra pacotes a que tem acesso. Dessa maneira, qualquer trfego estranho ir gerar uma ao do Snort. As aes do Snort podem ir desde alerta em terminal de root, envio de e-mails ou simples armazenamento em arquivo de registros. Essas aes podem ser conguradas, no arquivo /etc/snort.conf de acordo com o tipo de padro detectado. Assim, padres considerados mais perigosos iro gerar aes mais imediatas. A Figura 6.6 apresenta um exemplo de registro efetuado pelo Snort, mostrando o uso de scanner de segurana 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 Seo 6.2. Esses aplicativos no possuem cdigo aberto, mas podem ser distribudos e utilizados gratuitamente. Nesse projeto, o Portsentry verica as conexes de rede, enquanto o Hostsentry ca atento aos logins efetuados na mquina. Assim, ele emite alertas para logins em horrios feitos em horrios no costumeiros ou logins por usurio que no possuem freqncia de acesso ao servidor, podendo indicar uso dessa conta numa invaso. O Projeto Abacus era desenvolvido pela Psionic (http://www.psionic.com), que foi adquirida recentemente pela Cisco. Assim, no possvel obter os programas diretamente do site da Cisco (pelo menos at o momento de edio dessa apostila). Mas, esses programas podem ser obtidos em vrios outros sites, como por exemplo a RPMFind (http://www.rpmfind.net).
53
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 deteco de intrusos, merece especial ateno o LIDS (Linux Intrusion Detection System Sistema de Deteco de Intrusos para Linux). Esse aplicativo consiste na verdade em um patch para o kernel adicionando novas funcionalidades ao Linux para deteco de intrusos. De certa maneira, essa abordagem pode ser a mais interessante para uma maior segurana. Entretanto possui a necessidade de recompilao do kernel, o que traz inconvenincias para seu uso.
54
7
CONCLUSO
No existem solues mgicas para segurana computacional, que deve ser entendida como um processo e no como um objetivo. Alm disso a forma como esse conceito utilizado depende do ambiente em questo, o que implica que cada instituio precisa denir sua prpria poltica de segurana. Alguns procedimentos, entretanto, podem ser tidos como bsicos e devem ser vericados com especial ateno: 1. tomar excessivo zelo e cuidado com o uso da conta do superusurio; 2. manter os aplicativos atualizados com relao s falhas de seguranas; 3. checar a origem de um aplicativo antes de instal-lo; 4. cuidar para que os usurios escolham boas senhas; 5. evitar ao mximo disponibilizar aplicativos e servios que requerem senhas em texto puro, como telnet ou POP simples; 6. usar servios criptografados sempre que for trafegar dados importantes, usando SSL ou SSH, por exemplo; 7. congurar adequadamente a autenticao dos usurios, fazendo uso inteligente do PAM; 8. desabilitar servios no utilizados; 9. congurar adequadamente o iptables para um rewall seguro para o sistema; 10. utilizar periodicamente ferramentas de vericao, bem como analisar os arquivos de registros; para checar a segurana do sistema; 11. manter um sistema adequado de backup; 12. garantir segurana fsica para os equipamentos, principalmente servidores.
56
Esses procedimentos, se implementados corretamente, no iro garantir um site 100% seguro, um caso para co cientca. Mas dicultaro em muito a ao do invasor, desmotivando sua ao. Nesse sentido, o administrador deve estar atento para o fato que segurana computacional uma losoa de trabalho dirio e no algo para se conseguir aps uma seqncia de passos. Outro ponto importante que precisa car claro que sistemas de rewall no representam a melhor parte das aes de segurana: muitas vezes a invaso feita por um usurio legtimo do sistema, ou algum utilizando sua conta. Um rewall, nesse caso, no seria de to grande valia assim. Nesse sentido, o administrador precisa estar atento e implementando outras aes, como as listadas anteriormente, de forma a melhorar a segurana computacional das mquinas que responsvel.
REFERNCIAS BIBLIOGRFICAS
ANONYMOUS. Maximum Linux Security: A Hackers Guide to Protecting Your Linux Server and Workstation. Indianapolis: Sams, 2000. BRASIL. Decreto-Lei No. 2.848, de 7 de Dezembro de 1940: Cdigo Penal. Dirio Ocial da Unio, 31 dez. 1940. Disponvel 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.; UCHA, J. Q. Autenticao em sistemas Linux usando OpenLDAP. In: Semac2001 - XII Semana da Computao - IV Workshop em Linux, Internet e Aplicaes. So 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.
58
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 Solues para a Segurana do Linux. So Paulo: Makron-Books, 2002. KIRCH, O.; DAWSON, T. The Linux Network Administrators 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 Administrators 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 traduo 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. Mtodos para deteco local de rootkits e mdulos de kernel maliciosos em sistemas Unix. In: Anais do 3. Simpsio Sobre Segurana em Informtica SSI 2001. So Jos dos Campos: CTA/ITA/IEC, 2001. p. 133139. 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 Netlter/Iptables Project [WWW]. URL: http://www.netfilter.org/. SAMAR, V.; SCHEMERS, R. Unied 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.
Referncias Bibliogrcas
59
SCHNEIER, B. Applied Cryptography. New York: John Wisley, Inc., 1996. SICA, F. C.; UCHA, J. Q. Gerenciamento de Sistemas Linux. 2. ed. Lavras: UFLA/FAEPE, 2004. (Curso de Ps Graduao Lato Sensu (Especializao) a Distncia em Administrao 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). UCHA, J. Q. Segurana em Redes e Criptograa. Lavras: UFLA/FAEPE, 2003. (Curso de Ps Graduao Lato Sensu (Especializao) a Distncia em Administrao em Redes Linux). UCHA, J. Q.; SIMEONE, L. E.; SICA, F. C. Administrao de Redes Linux. Lavras: UFLA/FAEPE, 2003. (Curso de Ps Graduao Lato Sensu (Especializao) a Distncia em Administrao em Redes Linux). UCHA, K. C. A. Introduo Cibercultura. 3. ed. Lavras: UFLA/FAEPE, 2003. (Curso de Ps Graduao Lato Sensu (Especializao) a Distncia em Administrao em Redes Linux). VILELA, A. V. Estudos de Tcnicas de Preveno e Deteco de Intrusos. [S.l.]: DCC/UFLA, 2001. (Monograas de Graduao DCC/UFLA). http:/www.comp.ufla. br/~joukim/extensao/intruso.pdf. WEBER, R. F. Segurana na internet. In: Anais da XIX JAI - Jornada de Atualizao em Informtica. 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 Administrators Guide; Version 0.7. [S.l.]: The Linux Documentation Project, 2001. URL: http://www.tldp.org/ guides.html.

Apostila Seguranca

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Apostila Seguranca

Caricato da

Copyright:

Formati disponibili

Curso de Ps-Graduao Lato Sensu (Especializao) a Distncia Administrao em Redes Linux

Joaquim Quinteiro Ucha

EDITORA - UFLA/FAEPE - Segurana Computacional

EDITORA - UFLA/FAEPE - Segurana Computacional

EDITORA - UFLA/FAEPE - Segurana Computacional

ATAQUES MAIS COMUNS

EDITORA - UFLA/FAEPE - Segurana Computacional

EDITORA - UFLA/FAEPE - Segurana Computacional

Figura 3.1: Processos Criptogrcos

EDITORA - UFLA/FAEPE - Segurana Computacional

EDITORA - UFLA/FAEPE - Segurana Computacional

CRIPTOGRAFIA E SEGURANA COMPUTACIONAL

Tabela 3.1: Opes Mais Usadas do gpg

EDITORA - UFLA/FAEPE - Segurana Computacional

Tnel Criptogrfico Internet

Figura 3.2: Conceito de VPN

SEGURANA FSICA E BACKUPS

EDITORA - UFLA/FAEPE - Segurana Computacional

Segurana por Controle de Acesso

in.fingerd in.ftpd in.popd

Figura 4.1: Uso de TCP-Wrappers

EDITORA - UFLA/FAEPE - Segurana Computacional

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

Segurana por Controle de Acesso

# xinetd.conf # configuraes padres defaults { instances log_type log_on_success log_on_failure cps }

60 SYSLOG authpriv HOST PID HOST 25 30

# inclui configuraes no diretrio /etc/xinetd.d includedir /etc/xinetd.d

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

USO DE FIREWALLS OU PROXIES

EDITORA - UFLA/FAEPE - Segurana Computacional

       

           

Figura 4.6: Uso de Firewall

Segurana por Controle de Acesso

sink null sink null users users

Figura 4.7: Trecho do Arquivo /etc/services

EDITORA - UFLA/FAEPE - Segurana Computacional

Figura 4.8: Exemplo de Congurao do iptables

CONFIGURAO SEGURA DE SERVIOS

Segurana por Controle de Acesso

EDITORA - UFLA/FAEPE - Segurana Computacional

EDITORA - UFLA/FAEPE - Segurana Computacional

auth auth auth auth account password session

sufficient sufficient required required required required required

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

Administrao Segura de Usurios

auth auth auth account password session

sufficient required required required required required

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

EDITORA - UFLA/FAEPE - Segurana Computacional

Administrao Segura de Usurios

Tabela 5.1: Recursos Limitados pelo pam_limits

EDITORA - UFLA/FAEPE - Segurana Computacional

PROTEGENDO CONTAS DE USURIOS

Administrao Segura de Usurios

0 unlimited unlimited unlimited unlimited 1024 8 8192 unlimited 4095 unlimited

Figura 5.6: Execuo do Comando ulimit-a

SEGURANA NO SISTEMA DE ARQUIVOS

EDITORA - UFLA/FAEPE - Segurana Computacional

Administrao Segura de Usurios

EDITORA - UFLA/FAEPE - Segurana Computacional

EDITORA - UFLA/FAEPE - Segurana Computacional

VERIFICAO DOS REGISTROS (LOGS )