Prticas de Segurana para Administradores de Redes Internet

Verso para Impresso (PDF) Verso 1.2 16 de maio de 2003 Copyright NBSO

Sumrio
1. Introduo o 1.1. Organizao do Documento o 1.2. Como Obter este Documento o 1.3. Nota de Copyright e Distribuio 2. Polticas o 2.1. Polticas de Segurana o 2.2. Polticas de Uso Aceitvel 3. Instalao e Configurao Segura de Sistemas o 3.1. Preparao da Instalao o 3.2. Estratgias de Particionamento o 3.3. Documentao da Instalao e Configurao o 3.4. Senhas de Administrador o 3.5. Instalao Mnima o 3.6. Desativao de Servios No Utilizados o 3.7. Instalao de Correes o 3.8. Preveno de Abuso de Recursos 3.8.1. Controle de Relay em Servidores SMTP 3.8.2. Controle de Acesso a Proxies Web 4. Administrao e Operao Segura de Redes e Sistemas o 4.1. Educao dos Usurios o 4.2. Ajuste do Relgio 4.2.1. Sincronizao de Relgios 4.2.2. Timezone o 4.3. Equipes de Administradores 4.3.1. Comunicao Eficiente 4.3.2. Controle de Alteraes na Configurao 4.3.3. Uso de Contas Privilegiadas o 4.4. Logs 4.4.1. Gerao de Logs 4.4.2. Armazenamento de Logs 4.4.3. Monitoramento de Logs o 4.5. DNS 4.5.1. Limitao de Transferncias de Zona 4.5.2. Separao de Servidores 4.5.3. Uso de Privilgios Mnimos 4.5.4. Cuidado com Informaes Sensveis no DNS 4.5.5. DNS Reverso o 4.6. Informaes de Contato 4.6.1. Endereos Eletrnicos Padro 4.6.2. Contato no DNS 4.6.3. Contatos no WHOIS o 4.7. Eliminao de Protocolos sem Criptografia o 4.8. Cuidados com Redes Reservadas o 4.9. Polticas de Backup e Restaurao de Sistemas o 4.10. Como Manter-se Informado o 4.11. Precaues contra Engenharia Social

4.12. Uso Eficaz de Firewalls 4.12.1. A Escolha de um Firewall 4.12.2. Localizao dos Firewalls 4.12.3. Critrios de Filtragem 4.12.4. Exemplos o 4.13. Redes Wireless 4.13.1. Poltica de Uso da Rede Wireless 4.13.2. Topologia 4.13.3. Criptografia e Autenticao 4.13.4. Access Points 4.13.5. Proteo aos Clientes Wireless 4.13.6. Monitorao da Rede Wireless A. Referncias Adicionais o A.1. URLs de Interesse o A.2. Livros o
[ Sumrio ]

1. Introduo
Este documento procura reunir um conjunto de boas prticas em configurao, administrao e operao segura de redes conectadas Internet. A implantao destas prticas minimiza as chances de ocorrerem problemas de segurana e facilita a administrao das redes e recursos de forma segura. importante frisar que este conjunto representa o mnimo indispensvel dentro de um grande universo de boas prticas de segurana, o que equivale a dizer que a sua adoo um bom comeo mas no necessariamente suficiente em todas as situaes. As recomendaes apresentadas so eminentemente prticas e, tanto quanto possvel, independentes de plataforma de software e hardware. A maioria dos princpios aqui expostos genrica; a sua efetiva aplicao requer que um administrador determine como estes princpios podem ser implementados nas plataformas que ele utiliza. Este documento dirigido ao pessoal tcnico de redes conectadas Internet, especialmente aos administradores de redes, sistemas e/ou segurana, que so os responsveis pelo planejamento, implementao ou operao de redes e sistemas. Tambm podem se beneficiar da sua leitura gerentes com conhecimento tcnico de redes.

1.1. Organizao do Documento

O restante deste documento est organizado da seguinte maneira. A seo 2 apresenta polticas importantes para respaldar e viabilizar os procedimentos tcnicos descritos nas sees subseqentes. A seo 3 mostra como configurar sistemas e redes de forma mais segura. Na seo 4 so discutidos mtodos para se ter segurana na administrao e operao de redes e sistemas. O apndice A traz sugestes de material de consulta para quem queira obter conhecimentos mais aprofundados sobre algum dos temas abordados nas sees de 2 a 4.

1.2. Como Obter este Documento

Este documento pode ser obtido em http://www.cert.br/docs/seg-adm-redes/. Como ele periodicamente atualizado, certifique-se de ter sempre a verso mais recente. No mesmo endereo tambm est disponvel um checklist que resume as principais prticas apresentadas neste documento, e que pode ser usado para o acompanhamento da sua implantao. Caso voc tenha alguma sugesto para este documento ou encontre algum erro nele, entre em contato atravs do endereo doc@nic.br.

1.3. Nota de Copyright e Distribuio

Este documento Copyright 2002, 2003 NBSO . Ele pode ser livremente copiado desde que sejam respeitadas as seguintes condies:

1.

permitido fazer e distribuir cpias inalteradas deste documento, completo ou em partes, contanto que esta nota de copyright e distribuio seja mantida em todas as cpias, e que a distribuio no tenha fins comerciais.

2. Se este documento for distribudo apenas em partes, instrues de como obt-lo por completo devem ser includas. 3. permitido o uso dos exemplos de documentos e de configurao includos neste texto. Tal uso completamente livre e no est sujeito a nenhuma restrio. 4. vedada a distribuio de verses modificadas deste documento, bem como a comercializao de cpias, sem a permisso expressa do NBSO. Embora todos os cuidados tenham sido tomados na preparao deste documento, o NBSO no garante a correo absoluta das informaes nele contidas, nem se responsabiliza por eventuais conseqncias que possam advir do seu uso.
[ Sumrio ]

2. Polticas 2.1. Polticas de Segurana

Uma poltica de segurana um instrumento importante para proteger a sua organizao contra ameaas segurana da informao que a ela pertence ou que est sob sua responsabilidade. Uma ameaa segurana compreendida neste contexto como a quebra de uma ou mais de suas trs propriedades fundamentais (confidencialidade, integridade e disponibilidade). A poltica de segurana no define procedimentos especficos de manipulao e proteo da informao, mas atribui direitos e responsabilidades s pessoas (usurios, administradores de redes e sistemas, funcionrios, gerentes, etc.) que lidam com essa informao. Desta forma, elas sabem quais as expectativas que podem ter e quais so as suas atribuies em relao segurana dos recursos computacionais com os quais trabalham. Alm disso, a poltica de segurana tambm estipula as penalidades s quais esto sujeitos aqueles que a descumprem. Antes que a poltica de segurana seja escrita, necessrio definir a informao a ser protegida. Usualmente, isso feito atravs de uma anlise de riscos, que identifica: recursos protegidos pela poltica; ameaas s quais estes recursos esto sujeitos; vulnerabilidades que podem viabilizar a concretizao destas ameaas, analisando-as individualmente. Uma poltica de segurana deve cobrir os seguintes aspectos: aspectos preliminares: o abrangncia e escopo de atuao da poltica; o definies fundamentais; o normas e regulamentos aos quais a poltica est subordinada; o quem tem autoridade para sancionar, implementar e fiscalizar o cumprimento da poltica; o meios de distribuio da poltica; o como e com que freqncia a poltica revisada. poltica de senhas: o o o o o requisitos para formao de senhas; perodo de validade das senhas; normas para proteo de senhas; reuso de senhas; senhas default.

direitos e responsabilidades dos usurios, tais como: o utilizao de contas de acesso; o utilizao de softwares e informaes, incluindo questes de instalao, licenciamento e copyright;

o proteo e uso de informaes (sensveis ou no), como senhas, dados de configurao de sistemas e dados confidenciais da organizao; o uso aceitvel de recursos como email, news e pginas Web; o direito privacidade, e condies nas quais esse direito pode ser violado pelo provedor dos recursos (a organizao); o uso de antivrus. direitos e responsabilidades do provedor dos recursos, como: o backups; o diretrizes para configurao e instalao de sistemas e equipamentos de rede; o autoridade para conceder e revogar autorizaes de acesso, conectar e desconectar sistemas e equipamentos de rede, alocar e registrar endereos e nomes de sistemas e equipamentos; o monitoramento de sistemas e equipamentos de rede; o normas de segurana fsica. aes previstas em caso de violao da poltica: o o diretrizes para tratamento e resposta de incidentes de segurana; penalidades cabveis.

Cabe ressaltar que a lista de tpicos acima no exaustiva nem tampouco se aplica a todos os casos. Cada organizao possui um ambiente distinto e os seus prprios requisitos de segurana, e deve, portanto, desenvolver uma poltica de segurana que se molde a essas peculiaridades. recomendvel, por exemplo, que organizaes que possuam uma rede wireless incorporem uma poltica especfica para este tipo de rede (seo 4.13.1) sua poltica de segurana. Alguns fatores importantes para o sucesso de uma poltica de segurana so: apoio por parte da administrao superior; a poltica deve ser ampla, cobrindo todos os aspectos que envolvem a segurana dos recursos computacionais e da informao sob responsabilidade da organizao; a poltica deve ser periodicamente atualizada de forma a refletir as mudanas na organizao; deve haver um indivduo ou grupo responsvel por verificar se a poltica est sendo respeitada; todos os usurios da organizao devem tomar conhecimento da poltica e manifestar a sua concordncia em submeter-se a ela antes de obter acesso aos recursos computacionais; a poltica deve estar disponvel em um local de fcil acesso aos usurios, tal como a intranet da organizao. Dentre os itens acima, o apoio por parte da administrao superior essencial. Se a poltica de segurana no for encampada pela administrao, ela rapidamente ser deixada de lado pelos demais setores da organizao. Alm disso, importante que os seus membros dem o exemplo no que diz respeito observncia da poltica de segurana. Os seguintes fatores influem negativamente na aceitao de uma poltica de segurana e podem lev-la ao fracasso: a poltica no deve ser demasiadamente detalhada ou restritiva; o excesso de detalhes na poltica pode causar confuso ou dificuldades na sua implementao; no devem ser abertas excees para indivduos ou grupos; a poltica no deve estar atrelada a softwares e/ou hardwares especficos.

2.2. Polticas de Uso Aceitvel

A poltica de uso aceitvel (AUP -- Acceptable Use Policy) o documento que define como os recursos computacionais da organizao podem ser utilizados. Ela deve ser pblica e estar disponvel a todos os que utilizam a infra-estrutura computacional da organizao, sendo recomendvel que a autorizao para uso dos recursos seja condicionada a uma concordncia expressa com os seus termos. A AUP geralmente parte integrante da poltica de segurana global. Para muitas organizaes, ela ser composta pelos itens da poltica que afetam diretamente os usurios de recursos computacionais, principalmente os que definem seus direitos e responsabilidades. Por outro lado, organizaes que oferecem acesso a usurios externos (tais como provedores de acesso Internet) devem definir uma poltica de uso aceitvel para esses usurios que seja independente da AUP qual esto sujeitos os seus usurios internos. importante que os usurios externos tomem conhecimento dessa poltica e saibam que o uso dos recursos est condicionado ao seu cumprimento.
[ Sumrio ]

3. Instalao e Configurao Segura de Sistemas

Uma vez estabelecidas as polticas de segurana apropriadas para a sua rede (conforme exposto na seo 2), a etapa seguinte deve ser a configurao segura dos sistemas que estaro nessa rede. Caso no exista uma documentao atualizada que detalhe a configurao de alguns ou todos os sistemas em uso na sua rede, aconselhvel que estes sistemas sejam reinstalados observando-se as recomendaes aqui expostas, ou, pelo menos, que a sua configurao seja revisada e a documentao correspondente atualizada. IMPORTANTE: um sistema s dever ser conectado Internet aps os passos descritos nas sees 3.1 a 3.8 terem sido seguidos. A pressa em disponibilizar um sistema na Internet pode levar ao seu comprometimento.

3.1. Preparao da Instalao

A instalao de um sistema deve ser feita com ele isolado do mundo externo. Para tanto, os seguintes princpios devem ser seguidos: planeje a instalao, definindo itens como: o o o o o propsito do sistema a ser instalado; os servios que este sistema disponibilizar; a configurao de hardware da mquina; como o disco ser particionado, etc.

providencie de antemo todos os manuais e mdias de instalao que sero utilizados; instale o sistema a partir de dispositivos de armazenamento locais (CD, fita ou disco), desconectado da rede; caso voc precise ligar o sistema em rede (para fazer download de atualizaes, por exemplo), coloque-o em uma rede isolada, acessvel apenas pela sua rede interna. Caso seja possvel, evite concentrar todos os servios de rede em uma nica mquina, dividindoos entre vrios sistemas. Isto desejvel pois aumenta a disponibilidade dos servios na sua rede e reduz a extenso de um eventual comprometimento a partir de um deles.

3.2. Estratgias de Particionamento

Conforme mencionado na seo 3.1, um dos aspectos que devem ser includos no planejamento da instalao como ser feito o particionamento do(s) disco(s) do sistema. Embora isso dependa basicamente da utilizao pretendida para o sistema, existem alguns fatores que devem ser levados em considerao no momento de decidir como o disco deve ser particionado. Um princpio bsico dividir o disco em vrias parties em vez de usar uma nica partio ocupando o disco inteiro. Isto recomendvel por diversas razes:

 Um usurio ou um programa mal-comportado pode lotar uma partio na qual tenha permisso de escrita (reas temporrias e de armazenamento de logs so suscetveis a este problema). Se os programas do sistema estiverem em outra partio eles provavelmente no sero afetados, evitando que o sistema trave. Caso uma partio seja corrompida por alguma razo, as outras parties provavelmente no sero afetadas. Em alguns sistemas (notadamente sistemas Unix), possvel definir algumas caractersticas individuais para cada partio. Por exemplo, algumas parties podem ser usadas em modo read-only, o que til para parties que contenham binrios que so modificados com pouca freqncia. Em alguns casos a existncia de vrias parties permite mltiplas operaes de disco em paralelo e/ou o uso de otimizaes individuais para cada partio, o que pode aumentar significativamente o desempenho do sistema. O uso de vrias parties geralmente facilita o procedimento de backup do sistema, pois simplifica funes como: o o o copiar parties inteiras de uma s vez; excluir parties individuais do procedimento; fazer backups em intervalos diferentes para cada partio.

As parties especficas que devem ser criadas variam de sistema para sistema, no existindo uma regra que possa ser sempre seguida. Entretanto, recomenda-se avaliar a convenincia da criao de parties separadas para as reas onde so armazenados itens como: programas do sistema operacional; dados dos usurios; logs; arquivos temporrios; filas de envio e recepo de emails (servidores SMTP); filas de impresso (servidores de impresso); repositrios de arquivos (servidores FTP); pginas Web (servidores HTTP).

Note que a lista acima no exaustiva, podendo existir outras reas do sistema que meream uma partio separada. Da mesma forma, existem itens dentre os acima que no se aplicam a determinados casos. Consulte a documentao do seu sistema operacional para ver se ela contm recomendaes a respeito do particionamento adequado dos discos. As parties devem ser dimensionadas de acordo com os requisitos de cada sistema. Em muitos casos, o tamanho ocupado pelo sistema operacional fornecido na sua documentao, o que pode auxiliar na determinao do tamanho de algumas parties. Qualquer que seja a estrutura de particionamento escolhida, recomendvel que voc tenha pelo menos um esboo dela por escrito antes de comear a instalao. Isto agiliza o processo de instalao e reduz a probabilidade de que se faa uma determinada escolha sem que as suas conseqncias sejam adequadamente previstas.

3.3. Documentao da Instalao e Configurao

Uma medida importante para permitir uma rpida avaliao da situao de um sistema a documentao de sua instalao e configurao. A idia ter uma espcie de logbook (ou "dirio de bordo"), que detalhe os componentes instalados no sistema e todas as modificaes na sua configurao global. Esse logbook pode ser particularmente til para determinar qual verso de determinado pacote est instalada no sistema ou para reconstituir uma dada instalao. Muitas vezes um administrador precisa consultar diversas fontes e realizar vrias tentativas antes de instalar e/ou configurar corretamente um determinado pacote de software. A existncia de um documento que relate quais os passos exatos que tiveram que ser seguidos para que a instalao/configurao fosse bem sucedida permite que esse mesmo pacote possa ser instalado com correo e rapidez em outro sistema ou ocasio. Conforme ser visto na seo 4.3, a importncia deste documento

cresce na medida em que a responsabilidade pela administrao dos sistemas seja compartilhada por diversas pessoas. O formato e o grau de sofisticao do logbook dependem de diversos fatores, e cada administrador deve determinar qual a melhor maneira de manter essas informaes. Um simples arquivo texto pode revelar-se extremamente eficaz, como mostram os exemplos da figura 1. O que realmente importa que esse documento esteja disponvel em caso de falha (acidental ou provocada) do sistema, e que ele contenha informaes suficientes para que, a partir dele, seja possvel reconstituir a exata configurao que o sistema possua antes da falha, sem que seja necessrio recorrer a backups.1 essencial que alteraes na configurao do sistema e de seus componentes estejam documentadas neste logbook. A entrada referente a estas alteraes deve conter, no mnimo, os seguintes itens: data da modificao; responsvel pela modificao; justificativa para a modificao; descrio da modificao. Deve ser possvel, ainda, reconstituir a situao antes da mudana na configurao a partir dessa entrada.

Figura 1: Exemplos de entradas no logbook A figura 1 mostra um exemplo com algumas entradas do logbook de um servidor FTP. A primeira entrada registra a instalao inicial do sistema, realizada no dia 26/02 por um administrador chamado "Joe", e descreve ainda: o sistema operacional utilizado; como ele foi instalado; como o disco foi particionado; onde pode ser encontrada a lista de pacotes instalados;

 quais as portas que ficaram ativas aps a instalao; quais os usurios criados (com seus respectivos UIDs e GIDs). Aps a instalao inicial do sistema operacional, no dia 01/03 foi instalado um pacote chamado foo, verso 1.2.3. A entrada correspondente nologbook descreve os passos que foram seguidos para compilar e instalar o pacote e para preparar o sistema para o seu uso (criao de um usurio e um diretrio, com suas respectivas informaes). A terceira entrada registra algumas alteraes que tiveram que ser feitas na configurao do sistema para que o pacote foo pudesse ser usado corretamente. Por sua vez, a ltima entrada do exemplo apresenta uma modificao na inicializao do sistema para carregar um daemon(software servidor) usado pelo pacote. Observe que ambas as entradas permitem que a situao anterior do sistema (ou seja, a situao antes das modificaes descritas) seja restaurada, caso isso se revele necessrio ou desejvel. IMPORTANTE: o logbook de um sistema um documento sensvel, pois contm informaes que podem ser usadas para comprometer mais facilmente a segurana deste sistema. Sendo assim, ele deve ser armazenado e manipulado com cuidado, de acordo com a poltica para documentos sensveis da sua organizao.

3.4. Senhas de Administrador

Durante a instalao de um sistema, em determinado momento ser solicitado que voc informe uma senha de administrador (root ouAdministrator). Na maioria dos casos, o prprio programa de instalao que solicita a escolha da senha. Em outros casos, a senha de administrador deve ser definida aps o primeiro boot do sistema. Procure estabelecer esta senha to cedo quanto possvel durante a instalao do sistema. De preferncia, tenha uma senha j em mente quando comear a instalao. Uma senha adequada aquela fcil de ser lembrada e difcil de ser adivinhada. Ela deve respeitar, no mnimo, os seguintes critrios: ter um comprimento mnimo de 8 caracteres; ser formada por letras, nmeros e caracteres especiais; no ser derivada de seus dados pessoais, tais como nomes de membros da famlia (incluindo animais de estimao), nmeros de telefone, placas de carros, nmeros de documentos e datas; no dever ser adivinhada por quem conhea suas preferncias pessoais (time para o qual torce, escritor, ator ou cantor favorito, nomes de livros, filmes ou msicas, etc.); no estar presente em dicionrios (de portugus ou de outros idiomas). Uma sugesto para formar senhas que se encaixem nos requisitos acima usar as primeiras ou ltimas letras das palavras de uma frase, adicionando nmeros e smbolos e trocando minsculas e maisculas para dificultar ataques baseados em fora bruta. Por exemplo, a partir das iniciais de "the book is on the table" obtm-se, inicialmente, "tbiott". A partir da, possvel trocar a letra "o" por um "0" (zero) e o penltimo "t" por um smbolo "+", colocar algumas letras em maisculo e acrescentar outras letras, chegando a "tBi0+TbL", uma senha bastante difcil de ser adivinhada ou obtida por fora bruta. 2

3.5. Instalao Mnima

Um sistema mais seguro comea pela instalao do mnimo possvel de pacotes e componentes, especialmente os que implementam servios de rede. Este mnimo depende fundamentalmente do propsito do sistema em questo e do ambiente de rede no qual ele est inserido. Por exemplo, em princpio um sistema dedicado a servir pginas Web no precisa de um software servidor SMTP, assim como uma estao de trabalho no precisa de um servidor HTTP. A justificativa para esta recomendao bastante simples. comum que servios no utilizados no sejam monitorados por falhas de segurana, o que aumenta a possibilidade de no ser aplicada uma correo necessria. A reduo no nmero de pacotes instalados diminui a chance de que o sistema possua uma vulnerabilidade que possa vir a ser explorada por um atacante. Muitas vezes, administradores preferem instalar componentes cujo propsito ou funcionalidade desconheam por receio de que alguma coisa deixe de funcionar no sistema. Entretanto, a

maioria dos sistemas atuais possui algum mecanismo de controle de dependncias que avisa quando determinado componente precisa de outro para funcionar. Em outras palavras, freqentemente possvel deixar de instalar vrios componentes sem comprometer a funcionalidade do sistema. Consulte a documentao do seu sistema ou o suporte tcnico do seu fornecedor para saber se isto se aplica ao seu caso. Alguns programas de instalao permitem que o administrador escolha entre uma instalao tpica e uma personalizada ("para experts"). Quando possvel, opte pela personalizada, evitando instalar componentes cuja funcionalidade seja desconhecida ou que voc no esteja certo quanto sua necessidade. Em outros sistemas a instalao se d em duas etapas, a instalao do sistema base (sobre a qual o administrador tem mnimo ou nenhum controle) e a instalao de pacotes ou componentes adicionais. Neste caso, instale o sistema base e selecione cuidadosamente quais os componentes extras que sero adicionados ao sistema. Neste tipo de sistema, a desativao de servios no utilizados (seo 3.6) muito importante e deve ser realizada com especial ateno.

3.6. Desativao de Servios No Utilizados

O passo seguinte a uma instalao mnima a desativao de servios (locais e, principalmente, de rede) que no sero imediatamente utilizados no sistema. A lgica por trs desta recomendao a mesma por trs da instalao mnima de pacotes: reduzir a exposio do sistema a vulnerabilidades. Embora possa parecer que exista redundncia entre este passo e o anterior, na prtica surgem situaes nas quais o administrador forado a instalar um pacote ou componente completo para poder utilizar um subconjunto das funcionalidades oferecidas por esse pacote. Alm disso, muitos programas de instalao de sistemas operacionais optam por maximizar a funcionalidade disponibilizada aos usurios, e a configurao padro do sistema traz ativados todos os servios que foram instalados. Caso uma dessas situaes ocorra, as funcionalidades que no sero utilizadas devero ser desativadas ou mesmo removidas do sistema. Por exemplo, suponha que um pacote de servios de impresso contenha tanto um cliente quanto um servidor de impresso remota. Se o sistema necessitar apenas do software cliente, o administrador deve desabilitar a parte referente ao software servidor neste sistema. Caso no seja possvel desativar servios individualmente, uma alternativa usar um filtro de pacotes para bloquear as portas TCP/UDP usadas por esses servios, impedindo que eles sejam acessados atravs da rede. Isto ser discutido em maiores detalhes na seo 4.12. IMPORTANTE: a desativao de servios e/ou a remoo de arquivos efetuadas nesta fase devero ser documentadas no logbook do sistema.

3.7. Instalao de Correes

Depois de um sistema ter sido corretamente instalado e configurado, necessrio verificar se no existem correes (patches, fixes, service packs) para vulnerabilidades conhecidas nos componentes instalados. A maioria dos fornecedores de software libera correes para problemas de segurana que sejam descobertos em um sistema, sem que se tenha de esperar pela sua prxima verso. Na maioria das vezes, estas correes esto disponveis atravs da Internet. Consulte seu fornecedor para saber como manter-se informado a respeito de correes para o seu sistema e de que forma elas podem ser obtidas. Nem sempre todas as correes disponveis precisam ser instaladas. Restrinja-se quelas que corrigem problemas em componentes que estejam efetivamente instalados no seu sistema. Em caso de dvida, recorra ao suporte tcnico do seu fornecedor. A instalao indiscriminada de atualizaes pode enfraquecer a segurana do sistema ao invs de fortalec-la. Registre no logbook a instalao de correes. Mantenha em sua rede um repositrio das atualizaes que j foram utilizadas, para facilitar a instalao das mesmas em outros sistemas. IMPORTANTE: muitas vezes algumas configuraes do sistema so alteradas durante o processo de instalao de correes. Sendo assim, recomendvel que voc reveja a configurao do seu sistema aps instalar uma correo para certificar-se de que a instalao no tenha revertido eventuais modificaes que voc tenha feito (especialmente aquelas destinadas a desativar servios).

IMPORTANTE: a instalao de correes deve ser realizada no s como parte da instalao inicial do sistema, mas tambm durante o seu tempo de vida, a intervalos peridicos ou sempre que surgirem vulnerabilidades que o afetem. A seo 4.10 traz algumas recomendaes sobre como manter-se informado a respeito de novas vulnerabilidades que afetem os seus sistemas.

3.8. Preveno de Abuso de Recursos

Existem alguns servios que, se mal configurados, podem permitir que usurios externos abusem dos recursos da sua rede, ainda que isso no implique na ocorrncia de uma invaso. Dois destes servios so o email e os proxies de Web. A configurao incorreta destes servios pode causar vrios efeitos indesejveis. Um deles que recursos computacionais da organizao -- a comear pelo link Internet, mas incluindo CPU, discos e memria dos servidores -- so consumidos por terceiros sem que eles paguem por esse uso. Em muitos casos, esses recursos so exauridos de forma que usurios legtimos no possam utilizar o servio. Alm disso, servidores mal configurados so muitas vezes usados para disseminar contedo ilegal, tal como pornografia envolvendo crianas. Se um contedo deste tipo for encontrado em sistemas sob sua responsabilidade, existe a possibilidade de que voc e/ou sua organizao venham a ser legalmente implicados no caso.

3.8.1. Controle de Relay em Servidores SMTP

Na sua configurao padro, muitos servidores SMTP vm com o relay aberto, permitindo que eles sejam usados para enviar mensagens de e para qualquer rede ou domnio, independente dos endereos envolvidos serem da sua rede ou no. Estes servidores so amplamente explorados para envio de SPAM. Alm das conseqncias j mencionadas, diversas redes bloqueiam a recepo de mensagens a partir de servidores que tenham sido ou estejam sendo usados para envio de SPAM, fazendo com que usurios do servidor com relay aberto no possam enviar mensagens a usurios dessas redes. H que se considerar tambm que o uso de servidores SMTP de terceiros torna mais difcil a localizao e identificao dosspammers, diminuindo as chances de que eles sejam punidos por estes abusos. Para resolver este problema de relay aberto voc precisa configurar os seus servidores SMTP corretamente. A configurao adequada deve permitir apenas: envio de mensagens com endereo de origem local e endereo de destino local ou externo; recepo de mensagens com endereo de origem local ou externo e endereo de destino local. Informaes sobre como corrigir este problema para diferentes servidores SMTP esto disponveis em http://www.mail-abuse.org/tsi/ . Na maioria dos casos, possvel fechar o relay mesmo quando a rede possui roaming users, usando mecanismos como POP-before-SMTP e SMTP AUTH. Caso a sua rede necessite suportar usurios deste tipo, consulte a documentao do seu servidor SMTP ou o seu fornecedor para saber como fechar o relay sem prejudicar a utilizao do servio por parte deles.

3.8.2. Controle de Acesso a Proxies Web

Assim como no caso dos servidores SMTP, softwares que fazem proxy de Web (tais como Squid, Wingate e Microsoft Proxy Server) tambm podem ser abusados se no forem tomadas as devidas precaues. Um proxy mal configurado pode ser usado por usurios externos como um "trampolim" para acessar recursos de forma annima. Esta anonimidade pode ser usada para cometer crimes, tais como envio de mensagens caluniosas, difamatrias ou ameaadoras e divulgao de pornografia envolvendo crianas. A configurao correta para um proxy Web aquela que libera o acesso somente aos endereos IP de usurios autorizados (pertencentes sua rede). Consulte a documentao do seu software ou o suporte tcnico do seu fornecedor para obter maiores informaes sobre como configurar o controle de acesso no seu proxy. [1] A existncia do logbook no diminui a importncia dos backups, que sero tratados na seo 4.9. [ voltar ] [2] Evidentemente esta deixou de ser uma senha segura por constar neste documento. [ voltar ]
[ Sumrio ]

4. Administrao e Operao Segura de Redes e Sistemas 4.1. Educao dos Usurios

Uma tarefa extremanente importante e que deve fazer parte do cotidiano de administradores de redes a constante educao dos usurios. Sabe-se que grande parte dos problemas de segurana so originados na rede interna da organizao e, muitas vezes, so causados pelo desconhecimento de conceitos e procedimentos bsicos de segurana por parte dos usurios. Um exemplo clssico deste problema a m configurao do programa de leitura de emails de um usurio, que faz com que qualquer arquivo anexado a uma mensagem seja automaticamente aberto ou executado, permitindo a instalao de backdoors, cavalos de tria, disseminao de vrus, etc. O primeiro fator que contribui diretamente para o processo de educao o estabelecimento de polticas de segurana e de uso aceitvel (seo 2) claras, sem ambiguidades, conhecidas e completamente entendidas pelos usurios da rede. Outro fator importante o estabelecimento de um canal de comunicao, por exemplo, atravs de listas de emails, onde informaes sobre questes relevantes de segurana so frequentemente passadas para os usurios da rede. A descoberta de uma vulnerabilidade de segurana que afeta o servidor Web da organizao pode no ser relevante para os usurios, mas a notificao da descoberta de um novo vrus, sua forma de infeco e mtodos de preveno so informaes que devem ser conhecidas e aplicadas por todos os usurios. Muitas vezes e, principalmente, em grandes organizaes, tarefas como a instalao e configurao do sistema operacional e softwares de um computador so realizadas pelo prprio usurio. Da vem um dos fatores de grande importncia neste processo de educao, pois a execuo de tais tarefas tem impacto direto na segurana das redes e sistemas de uma organizao. Procurando cobrir os tpicos necessrios para a educao do usurio, dentre outras questes, foi desenvolvida a "Cartilha de Segurana para a Internet", que tem por finalidade sanar algumas dvidas comuns sobre segurana de computadores e redes e sobre o significado de termos e conceitos amplamente utilizados na Internet. Alm disso, a cartilha procura enumerar, explicar e fornecer um guia para uma srie de procedimentos que visam aumentar a segurana de um computador e de posturas que um usurio pode adotar para garantir sua segurana na Internet. Este documento pode ser obtido em http://cartilha.cert.br/ .

4.2. Ajuste do Relgio 4.2.1. Sincronizao de Relgios

Os relgios de todos os sistemas da sua rede (incluindo as estaes de trabalho) devero estar sincronizados, ou seja, devero ter exatamente o mesmo horrio. Para que isso acontea, voc deve usar um protocolo de sincronizao de relgios, tal como o NTP (Network Time Protocol). Este protocolo o mais recomendado, pois existem implementaes dele para os mais variados sistemas operacionais, como pode ser visto em http://www.ntp.org/ . Para obter maior preciso no ajuste e para minimizar o trfego desnecessrio na rede, sugere-se que a sincronizao via NTP seja implementada observando-se as seguintes recomendaes: 1. Procure manter em sua rede um servidor NTP local. Esse servidor quem ir realizar a sincronizao com um servidor externo. As demais mquinas da sua rede, por sua vez, tero seus relgios sincronizados com o relgio do servidor local. 2. Muitos backbones disponibilizam um servidor NTP a seus clientes. Consulte o suporte tcnico do seu backbone para verificar se ele oferece este servio e como voc pode fazer para utiliz-lo.

4.2.2. Timezone
Caso voc trabalhe com servidores Unix, ajuste o relgio de hardware destes sistemas para a hora padro de Greenwich (GMT) e configure adequadamente o seu fuso horrio (timezone) para que a hora local seja exibida corretamente. O uso do timezone certo tambm possibilita o ajuste automatizado do relgio por conta do horrio de vero. Para que isso seja possvel, voc dever criar ou obter um arquivo de informaes de timezone com as datas corretas de incio e fim do horrio de vero. Para maiores informaes, consulte a documentao do comando zic.

4.3. Equipes de Administradores

Em muitas redes, a administrao de sistemas uma responsabilidade dividida entre vrias pessoas. Nesses casos, necessrio estabelecer algumas regras para garantir a eficincia do trabalho em equipe.

4.3.1. Comunicao Eficiente

Em primeiro lugar, essencial que os diferentes administradores comuniquem-se de maneira eficiente. Um bom modo de fazer isto estabelecer listas de discusso por email que sejam internas sua organizao. Estas listas podem ser usadas para, entre outros propsitos, comunicar alteraes na configurao dos sistemas, notificar os demais administradores a respeito de ocorrncias relevantes e servir como mecanismo de acompanhamento da diviso de tarefas. A grande vantagem de usar listas de discusso que elas possibilitam a comunicao entre os administradores mesmo que alguns trabalhem em diferentes turnos ou locais. O histrico das listas pode servir para documentar decises tomadas e para atualizar um administrador que tenha passado algum tempo afastado de suas atividades.

4.3.2. Controle de Alteraes na Configurao

A partir do momento em que vrias pessoas ficam encarregadas da administrao de um sistema, torna-se necessrio dispor de meios que possibilitem a identificao de quem foi o responsvel por cada alterao na sua configurao. Isso permite resolver problemas de forma mais eficiente, pois a pessoa que realizou determinada modificao a mais indicada para ajudar na resoluo de eventuais complicaes dela decorrentes. Conforme mostrado na seo 3.3, o logbook pode auxiliar nessa tarefa. Para isso, necessrio que em cada entrada no logbook conste o nome da pessoa responsvel pelas modificaes ali descritas. Uma forma mais automatizada de fazer isso atravs do uso de ferramentas de controle de verso como o RCS(http://www.cs.purdue.edu/homes/trinkle/RCS/ ) e o CVS (http://www.cvshome.org ). Essas ferramentas tambm permitem manter um histrico de arquivos de configurao, de forma a possibilitar a recuperao de antigas verses desses arquivos. Recomenda-se que, sempre que possvel, este tipo de ferramenta seja usado em sistemas que possuam mltiplos administradores.

4.3.3. Uso de Contas Privilegiadas

Um problema que surge em sistemas com mltiplos administradores a dificuldade de se manter um registro do uso de contas privilegiadas, tais como root e Administrator. Sempre que possvel, estas contas no devem ser usadas diretamente. Um administrador deve entrar no sistema usando sua conta pessoal e a partir dela realizar suas tarefas, usando os privilgios mais elevados apenas quando estritamente necessrio. Em sistemas Unix, isso realizado atravs do comando su. O su traz como benefcio adicional o fato de que o seu uso normalmente fica registrado nos logs do sistema, permitindo que se identifique quem acessou a conta de root em um determinado perodo. O sudo (http://www.courtesan.com/sudo/ ) uma ferramenta que permite que o administrador do sistema conceda a determinados usurios a possibilidade de executar comandos predefinidos como se eles fossem root (ou outro usurio), registrando nos logs do sistema a utilizao desses comandos. O uso do sudo reduz a necessidade de compartilhamento da senha de root, uma vez que os usurios entram com sua prpria senha para utilizar os comandos disponveis atravs dele. Isso pode ser usado, por exemplo, quando existem contas de operador que so usadas para a realizao de backups ou para invocar o procedimento de desligamento do sistema. O sudo extremamente configurvel, possibilitando, entre outros recursos, a definio de grupos de usurios, de comandos e de hosts e o uso de restries por host ou grupo de hosts (permitindo que o mesmo arquivo de configurao seja usado em sistemas diferentes). IMPORTANTE: o uso de uma conta administrativa nica com senha compartilhada, que no permita determinar qual dos administradores acessou o sistema, deve ser evitado ao mximo.

4.4. Logs
Logs so muito importantes para a administrao segura de sistemas, pois registram informaes sobre o seu funcionamento e sobre eventos por eles detectados. Muitas vezes, os logs so o nico recurso que um administrador possui para descobrir as causas de um problema ou comportamento anmalo.

4.4.1. Gerao de Logs

Para que os logs de um sistema sejam teis para um administrador, eles devem estar com o horrio sincronizado via NTP, ser to detalhados quanto possvel, sem no entanto gerar dados em excesso. Informaes especialmente teis so aquelas relacionadas a eventos de rede, tais como conexes externas e registros de utilizao de servios (arquivos transferidos via FTP, acessos a pginas Web, tentativas de login sem sucesso, avisos de disco cheio, etc.). Para registrar estas informaes, necessrio configurar o sistema da maneira apropriada. A forma de fazer isto geralmente varia para cada componente especfico; consulte a documentao para descobrir como habilitar o logging de informaes no seu sistema e em softwaresespecficos como firewalls e servidores HTTP.

4.4.2. Armazenamento de Logs

Armazenamento on-line Os logs so tradicionalmente armazenados em disco, no prprio sistema onde so gerados. Essa a opo mais bvia, mas ela possui alguns riscos inerentes que devem ser compreendidos. O primeiro deles diz respeito possibilidade dos logs serem destrudos durante uma invaso do sistema (uma ocorrncia bastante comum). Em alguns sistemas, isso pode ser contornado atravs da instalao de um loghost centralizado. Um loghost centralizado um sistema dedicado coleta e ao armazenamento de logs de outros sistemas em uma rede, servindo como um repositrio redundante de logs. Via de regra, o loghost no disponibiliza nenhum outro servio, nem mesmo acesso remoto para os administradores, para minimizar a possibilidade de que ele seja comprometido. Outra vantagem de loghosts centralizados que eles facilitam a anlise dos logs e correlao de eventos ocorridos em sistemas distintos. Sempre que possvel, o uso de loghosts centralizados fortemente recomendado. Um segundo risco a possibilidade de um atacante usar o logging para executar um ataque de negao de servio contra um determinado sistema, gerando eventos em excesso at que o disco onde so armazenados os logs fique cheio e o sistema trave em conseqncia disto. Conforme discutido na seo 3.2, o uso de uma partio separada para armazenar os logs pode minimizar o impacto deste problema. Outro ponto que merece ateno a rotao automtica de logs. Quando este recurso utilizado, deve-se garantir que os logs sejam movidos para o armazenamento off-line antes que eles sejam removidos do sistema pela rotao, evitando assim a perda de registros. Alguns sistemas trazem a rotao automtica habilitada na sua configurao padro; ao instalar um destes sistemas, verifique se esta configurao compatvel com os seus procedimentos de backup e armazenamento off-line de logs. Armazenamento off-line Evidentemente, os logs no podem ser mantidos on-line por tempo indeterminado, pois acabam por consumir muito espao em disco. A melhor estratgia para resolver esta questo transferir periodicamente os logs do disco para dispositivos de armazenamento off-line, tais como fita, CDR ou DVD-R. recomendvel gerar um checksum criptogrfico (tal como MD5 ou SHA-1) dos logs que so armazenados off-line. Esse checksum deve ser mantido separado dos logs, para que possa ser usado para verificar a integridade destes caso eles venham a ser necessrios. Os logs armazenados off-line devem ser mantidos por um certo perodo de tempo, pois podem vir a ser necessrios para ajudar na investigao de incidentes de segurana descobertos posteriormente. O Comit Gestor da Internet no Brasil recomenda que logs de conexes de usurios de provedores de acesso estejam disponveis por pelo menos 3 anos (vide http://www.cgi.br/acoes/desenvolvimento.htm ). aconselhvel que os demais logs sejam mantidos no mnimo por 6 meses. importante que os logs armazenados on-line sejam includos no procedimento de backup dos seus sistemas (backups so tratados na seo4.9).

4.4.3. Monitoramento de Logs

Os logs possibilitam o acompanhamento do que acontece com a sua rede e com os seus sistemas. Para tanto, importante que eles sejam monitorados com freqncia para permitir que eventuais problemas sejam rapidamente identificados. Existem algumas prticas recomendveis no que diz respeito ao monitoramento de logs: incorpore o hbito de inspecionar os logs sua rotina de trabalho; faa isso pelo menos uma vez por dia, mas tenha em mente que sistemas muito importantes ou que geram muita informao podem precisar ter seus logs analisados com maior freqncia; procure investigar as causas de qualquer registro que lhe parea incorreto ou anmalo, por mais insignificante que ele aparente ser; procure identificar o padro de comportamento normal dos seus sistemas, para poder encontrar eventuais anomalias com maior rapidez. Quando estiver analisando logs, voc deve certificar-se do timezone usado para registrar o horrio dos eventos. Por exemplo, alguns softwares(como o Microsoft IIS, dependendo da configurao adotada) registram eventos com a hora de Greenwich (GMT), e no com a hora local. O desconhecimento do timezone em que esto os logs pode facilmente invalidar uma anlise e lev-lo a concluses equivocadas. medida em que voc venha a adquirir prtica com a anlise dos seus logs, voc poder escrever scripts ou pequenos programas para auxili-lo nesta tarefa, automatizando assim parte do processo. Estes scripts so teis, por exemplo, para pr-processar os logs em busca de determinados contedos, para eliminar contedo repetitivo e para elaborar um resumo que pode ser enviado por email para o administrador do sistema. A eliminao de padres relacionados a eventos considerados normais pelo administrador especialmente importante porque, alm de reduzir o volume de logs a serem analisados, pode evidenciar alguma atividade incomum. Uma outra opo utilizar ferramentas que permitam monitorar logs em tempo real, como por exemplo o swatch(http://swatch.sourceforge.net/ ). O swatch requer que voc especifique um conjunto de padres a serem monitorados e as aes a serem tomadas quando um destes padres registrado nos logs. As aes podem ser de diversos tipos, como exibir a informao registrada, notificar um determinado usurio por email e invocar um programa do sistema. A capacidade de execuo de comandos arbitrrios do swatch torna-o muito atraente, pois permite, por exemplo, que sejam tomadas medidas como filtragem de um endereo IP que gere determinado log e envio de uma mensagem de alerta para um telefone celular. Existem tambm vrias ferramentas que tem por objetivo processar diversos formatos conhecidos de logs e que podem ser bastante teis para o administrador. Uma grande lista dessas ferramentas, bem como muita documentao sobre monitorao e anlise de logs est disponvel em http://www.loganalysis.org/ .

4.5. DNS
O DNS (Domain Name System) hoje um servio essencial para o funcionamento da Internet. Essa importncia, associada natureza das informaes que ele armazena, o tornam um dos alvos mais atraentes para atacantes. Desse modo, uma configurao adequada dos servidores DNS crucial para aumentar a segurana e colaborar para o bom funcionamento da rede. Servidores DNS expostos Internet esto sujeitos a uma srie de riscos, dentre os quais destacam-se: Vazamento de informaes sensveis sobre a rede da organizao atravs de transferncias de zonas DNS. Essas informaes podem ajudar um atacante a identificar os pontos fracos da rede e a escolher futuros alvos. Ataques de envenenamento de cache (cache poisoning), que levam um servidor a armazenar informaes forjadas. Tais informaes podem ser usadas para comprometer a segurana de clientes que faam consultas a esse servidor. Comprometimento do servidor atravs de vulnerabilidades no software de DNS, o que pode facilitar outras quebras de segurana no restante da rede da organizao. Esta seo apresenta os principais mecanismos usados para eliminar ou minimizar estas ameaas, trazendo tambm recomendaes sobre a configurao de DNS reverso. Informaes mais detalhadas podem ser obtidas no documento Securing an Internet Name Server, do CERT/CC (disponvel em http://www.cert.org/archive/pdf/dns.pdf ) e nas referncias do apndice A.

4.5.1. Limitao de Transferncias de Zona

Transferncias de zona so usadas para que os servidores DNS escravos (secundrios) atualizem suas informaes sobre uma determinada zona DNS em relao ao servidor mestre (primrio) para essa zona. Restringir os endereos que podem fazer transferncias de zona uma importante medida para evitar que atacantes obtenham informaes detalhadas sobre a rede da organizao, tais como endereos de roteadores, servidores de correio eletrnico e outros servidores DNS. As limitaes de transferncias de zona devem ser aplicadas a todos os servidores com autoridade para um domnio, independente de eles serem mestres ou escravos. Um equvoco comum limitar as transferncias de zona no servidor mestre e no faz-lo nos servidores escravos. Preferencialmente, as transferncias de zona devem ser limitadas atravs da configurao de controles de acesso no software servidor DNS. NoBIND, por exemplo, isso feito no named.boot (BIND 4) ou named.conf (BIND 8 e 9). Consulte a documentao do seu software ou o suporte tcnico do seu fornecedor para obter informaes sobre como limitar transferncias de zona da maneira mais apropriada. IMPORTANTE: uma concepo errnea, infelizmente bastante difundida, a de que a limitao de transferncias de zona deve ser feita filtrando o trfego para a porta 53/TCP do servidor DNS. Como a porta 53/TCP tambm usada na resoluo de nomes, essa filtragem pode comprometer seriamente a funcionalidade do seu servio de nomes.

4.5.2. Separao de Servidores

Servidores DNS possuem duas funes principais. A primeira delas a de disponibilizar informaes a respeito de zonas sobre as quais possuem autoridade (caso dos servidores mestres e escravos para uma determinada zona). A segunda funo a de resolver nomes para clientes na sua rede (neste caso, o servidor dito recursivo). Muitas vezes, o mesmo servidor desempenha ambas funes. Uma prtica recomendvel separar a funo de servidor com autoridade (mestre ou escravo) da funo de servidor recursivo. Isso minimiza a eficcia de ataques de envenenamento de cache DNS. Na prtica, essa separao significa que os servidores que possuem autoridade para uma ou mais zonas respondem somente a consultas relativas a essas zonas; por sua vez, os servidores recursivos no possuem autoridade sobre nenhuma zona DNS. A forma mais simples de se fazer essa separao configurar os servidores DNS com autoridade em mquinas distintas dos servidores DNS recursivos. Alguns softwares servidores DNS podem ser configurados para permitir que essa separao seja feita na mesma mquina; um exemplo a verso 9 do BIND, que implementa isso atravs de vises (views).

4.5.3. Uso de Privilgios Mnimos

Os softwares servidores de DNS esto entre os alvos mais visados pelos atacantes, e j foram responsveis por comprometimentos de segurana no passado. Dessa forma, uma medida recomendvel minimizar os privilgios com os quais o software servidor DNS executado. Em ambientes Unix, muitas vezes possvel executar o servidor DNS em uma jaula chroot(). Verses mais recentes do BIND permitem tambm que ele seja executado com permisses de um usurio diferente de root. Consulte a documentao do seu software ou o suporte tcnico do seu fornecedor para ver se uma dessas opes pode ser utilizada.

4.5.4. Cuidado com Informaes Sensveis no DNS

O DNS oferece alguns tipos de registros de recursos que armazenam informaes adicionais sobre os nomes de domnio, tais como HINFO, TXT e WKS. Estes registros no so necessrios para o funcionamento correto da resoluo de nomes, sendo geralmente usados para facilitar a administrao e a manuteno da rede. Conforme discutido em maiores detalhes na seo 4.11, informaes sobre configurao de sistemas na sua rede devem ser consideradas sensveis, pois podem ser usadas por um atacante para facilitar o comprometimento desses sistemas (ajudando-o a identificar mquinas

com sistemas que possuam vulnerabilidades conhecidas, por exemplo). Em vista disso, o mais prudente evitar registrar esse tipo de informao no DNS. Caso voc deseje usar estes tipos de registros para facilitar a administrao da rede, recomendase fortemente que essas informaes no estejam disponveis para usurios externos sua rede. Isso pode ser conseguido usando-se servidores DNS inacessveis externamente ou, para o BIND 9, atravs do uso adequado de vises. Outro fator importante, e que requer a ateno do administrador, consiste no fato de que o DNS pode fornecer um registro que possibilite a obteno da verso do servio de DNS sendo executado, o que pode ser usado para determinar a vulnerabilidade/suscetibilidade do servio a um dado ataque. Por exemplo, o BIND fornece esta informao atravs de consultas do tipo "version.bind". Portanto, aconselhvel que o administrador verifique se este tipo de registro pode ser fornecido por seu servio de DNS e, ento, configure-o levando em considerao uma ou mais das seguintes medidas: bloqueie toda e qualquer consulta desta natureza, originada na rede interna ou externa; permita que este tipo de consulta seja realizada apenas partindo da rede interna ou de IPs especficos, como da mquina do administrador ou do prprio servidor de DNS (localhost); altere o contedo da string enviada como resultado da consulta, para por exemplo uma string vazia (""); gere registros de eventos (logs) para todas as consultas desta natureza.

4.5.5. DNS Reverso

O uso mais freqente do DNS a traduo de nomes em endereos IP. Entretanto, ele tambm permite descobrir o nome associado a um determinado endereo IP. Isso chamado DNS reverso, e possibilita a identificao do domnio de origem de um endereo IP. Um DNS reverso mal configurado ou inexistente pode causar alguns transtornos. O primeiro deles que muitos sites negam o acesso a usurios com endereos sem DNS reverso ou com o reverso incorreto. 3 Em segundo lugar, erros na configurao do DNS depem contra a competncia tcnica da equipe de administrao de redes responsvel pelo domnio, e isso pode vir a causar dificuldades quando for necessrio interagir com equipes de outras redes. recomendvel que voc mantenha atualizado o DNS reverso dos endereos sob sua responsabilidade. Em alguns casos a administrao do DNS reverso dos seus blocos pode ser delegada sua rede, enquanto em outros o seu provedor de backbone quem responsvel pelo DNS reverso dos seus endereos. Entre em contato com o seu provedor de backbone para obter informaes sobre como atualizar o seu DNS reverso.

4.6. Informaes de Contato

Existem na Internet alguns endereos eletrnicos (emails) que so usados para entrar em contato com administradores quando se deseja comunicar determinadas ocorrncias relacionadas segurana de suas redes e sistemas. extremamente importante que estas informaessejam vlidas e estejam sempre atualizadas, pois assim garante-se que estas comunicaes sero recebidas pela pessoa certa no menor espao de tempo possvel, o que pode muitas vezes impedir um incidente de segurana ou limitar as conseqncias. Esta seo mostra quais so essas informaes e como voc deve proceder para atualiz-las.

4.6.1. Endereos Eletrnicos Padro

A RFC 21424 define uma srie de emails padro que devem existir em todas as redes e que podem ser usados para contatar os seus responsveis. Dentre os endereos padro, existem dois que esto relacionados com segurana: abuse e security. O endereo abuse usado para reportar abusos de recursos na rede. O endereo security, por sua vez, utilizado para comunicar incidentes e alertar sobre problemas de segurana. Mensagens enviadas para estes endereos devero chegar at os responsveis por lidar com essas ocorrncias. No necessrio criar usurios com estes nomes, basta que sejam

configurados aliases redirecionando as mensagens enviadas a estes endereos para os usurios apropriados. Cabe observar que muitas vezes estes endereos no so usados da maneira mais apropriada, com abuse recebendo reclamaes de incidentes de segurana e security relatos de abusos, ou ambos os endereos sendo usados na mesma notificao. Sendo assim, importante que sua rede possua ambos os endereos e que eles sejam constantemente monitorados pela sua equipe de segurana.

4.6.2. Contato no DNS

Cada domnio registrado em um servidor DNS possui uma srie de parmetros de configurao no registro de SOA (Start of Authority). Um destes parmetros o email do responsvel pelo domnio, que muitas vezes tambm usado para comunicar problemas de segurana envolvendo esse domnio. Um exemplo de registro SOA para o domnio example.org pode ser visto na figura 2. Nesta figura, ns.example.org o nome do servidor DNS primrio e joe.example.org representa o endereo joe@example.org, que seria o endereo de contato para o domnio example.org.

Figura 2: Exemplo de registro SOA Mantenha esse endereo do campo de SOA atualizado em todos os domnios sob sua responsabilidade, incluindo os de DNS reverso. Se preferir, use um alias em vez de um email real. No se esquea que o formato usurio.domnio, e no usurio@domnio.

4.6.3. Contatos no WHOIS

Cada domnio ou bloco de endereos IP registrado possui uma lista de informaes de contato que remetem s pessoas responsveis por estes domnios ou blocos. Geralmente existem trs tipos de contatos: contato tcnico: responsvel tcnico pela administrao e operao do domnio ou bloco; contato administrativo: quem tem autoridade sobre o domnio ou bloco; contato de cobrana: quem recebe correspondncias de cobrana das despesas de registro e manuteno do domnio ou bloco. Os endereos de email destes contatos devem estar sempre atualizados e ser vlidos. No caso do contato tcnico, isso significa dizer que mensagens enviadas para este endereo devem ser recebidas por um administrador de redes responsvel pelo bloco ou domnio, e no por pessoal administrativo ou jurdico da organizao. Este contato usado com muita freqncia para notificao de incidentes de segurana e outros problemas com a infra-estrutura de rede envolvendo o domnio ou bloco. Estas informaes de contato so mantidas em uma base de dados chamada WHOIS. Esta base de dados normalmente gerenciada por entidades que registram domnios (informaes sobre domnios) e por provedores de backbone (informaes sobre endereos IP). No Brasil, estas informaes so administradas e disponibilizadas pelo Registro .br (http://registro.br ). O procedimento de atualizao dos contatos no WHOIS varia de acordo com a entidade de registro ou provedor de backbone. Entre em contato com a sua entidade de registro ou o seu provedor para obter informaes detalhadas sobre como efetuar essa atualizao. Para domnios registrados no Brasil, informaes sobre como atualizar os contatos esto disponveis em http://registro.br/faq/faq2.html .

4.7. Eliminao de Protocolos sem Criptografia

Uma medida de segurana muito importante na operao de redes a substituio de protocolos onde no haja autenticao atravs de senhas, ou onde senhas trafeguem em claro, por outros que corrijam estas deficincias. A lista de protocolos cuja utilizao deve ser evitada na medida do possvel inclui: Telnet; FTP; POP3; IMAP; rlogin; rsh; rexec. A maioria dos protocolos citados pode ser substituda pelo SSH.5 Essa substituio, alm de fazer com que o trfego entre cliente e servidor passe a ser criptografado, traz ainda outras vantagens, como proteo da sesso contra ataques tipo man-in-the-middle e seqestro de conexes TCP. Em relao ao POP3, existem diversas possibilidades de substituio:

1.

Usar uma das variantes do protocolo (APOP, KPOP, RPOP) que tornam a autenticao de usurios mais segura, pois eliminam o trfego de senhas em claro. As desvantagens desta opo so que nem todos os clientes de email suportam estas variantes e o contedo dos emails (que pode conter informaes sensveis) no criptografado. 2. Usar POP3 atravs de um tnel SSH ou SSL. A primeira opo interessante quando o servidor POP3 e o servidor SSH residem na mesma mquina. Para a segunda, podem ser usadas ferramentas como o stunnel (http://stunnel.mirt.net ). Alguns clientes de emailj suportam SSL diretamente, no sendo necessrio o uso de tneis. 3. Usar uma soluo de Webmail sobre HTTPS (HTTP+SSL). Esta soluo tambm vlida para o IMAP.

4.8. Cuidados com Redes Reservadas

Existem alguns blocos de endereos IP que so reservados pelo IANA (Internet Assigned Numbers Authority) para propsitos especficos. No existe um documento nico que registre todos estes blocos; alguns esto documentados em RFCs, enquanto que outros so considerados reservados por razes de compatibilidade histrica. A RFC 33306 lista vrios blocos reservados pelo IANA. Uma lista dessas redes reservadas conhecidas mostrada na tabela 1, juntamente com um breve comentrio sobre a finalidade de cada rede. Tabela 1: Lista de redes reservadas pelo IANA Rede Comentrio usada por sistemas antigos para broadcast loopback TEST-NET; usada para exemplos em documentao usada em redes privadas (RFC 1918)

0.0.0.0/8 127.0.0.0/8 192.0.2.0/24 10.0.0.0/8

172.16.0.0/12 usada em redes privadas (RFC 1918) 192.168.0.0/16 usada em redes privadas (RFC 1918) 169.254.0.0/16 usada para autoconfigurao (est relacionada ao protocolo DHCP) 192.88.99.0/24 usada para 6to4 Relay Anycast (RFC 3068)

198.18.0.0/15 usada para testes de desempenho de equipamentos de rede (RFC 2544) 224.0.0.0/4 240.0.0.0/5
classe D classe E

Outro ponto importante que nem todo o espao de endereamento IPv4 est atualmente alocado. Uma lista dessas redes no alocadas, e portanto reservadas para o IANA, mantida em http://www.iana.org/assignments/ipv4-address-space . Esta lista frequentemente atualizada e recomendvel que seja consultada regularmente. Endereos no alocados e pertencentes a blocos reservados no devem ser propagados atravs da Internet, sendo recomendada a sua filtragem no permetro da sua rede, tanto para entrada quanto para sada. Caso voc possua redes privadas com IPs reservados, certifique-se de que os endereos utilizados sejam os especificados na RFC 19187(10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16). Endereos reservados no devem estar associados a nomes em servidores DNS pblicos. Se voc utiliz-los em redes privadas e quiser usar nomes para as mquinas, configure um servidor DNS privado ou utilize tabelas de hosts (/etc/hosts ou C:\WINDOWS\HOSTS). Caso voc detecte um ataque proveniente de uma das redes da tabela 1 e estes endereos estiverem sendo filtrados no permetro, os pacotes correspondentes s podem ter partido de dentro da sua prpria rede. A causa mais freqente para isso a existncia de erros de configurao que fazem com que os endereos reservados "vazem" de uma ou mais de suas redes privadas. Logo, deve-se procurar internamente a causa do problema em vez de tentar contactar o IANA (que a entidade listada nos contatos de WHOIS para estes blocos).

4.9. Polticas de Backup e Restaurao de Sistemas

A importncia dos backups na administrao de sistemas nunca pode ser minimizada. Sem eles, muitos dados so simplesmente irrecuperveis caso sejam perdidos devido a uma falha acidental ou a uma invaso. Os backups devem fazer parte da rotina de operao dos seus sistemas e seguir uma poltica determinada. O melhor faz-los da forma mais automatizada possvel, de modo a reduzir o seu impacto sobre o trabalho dos administradores e operadores de sistemas. A lista de itens cujo backup deve ser feito com freqncia inclui: dados; arquivos de configurao; logs. Um ponto que merece especial cuidado o backup de binrios (executveis e bibliotecas), que geralmente deve ser evitado. Uma exceo a essa regra uma cpia completa do sistema logo aps a sua instalao, antes que ele seja colocado em rede. Backups que incluem binrios no so aconselhveis porque abrem a possibilidade de que eventuais Cavalos de Tria ou executveis corrompidos sejam reinstalados na restaurao do sistema. Alguns cuidados devem ser tomados em relao ao local onde so guardados os backups: o acesso ao local deve ser restrito, para evitar que pessoas no autorizadas roubem ou destruam backups; o local deve ser protegido contra agentes nocivos naturais (poeira, calor, umidade); se possvel, aconselhvel que o local seja tambm prova de fogo. Os backups devem ser verificados logo aps a sua gerao e, posteriormente, em intervalos regulares. Isto possibilita a descoberta de defeitos em dispositivos e meios de armazenamento e pode evitar que dados sejam perdidos por problemas com backups que no podem ser restaurados. Algumas organizaes providenciam meios para armazenar backups fora das suas instalaes, como em cofres de bancos, por exemplo. Essa uma boa maneira de garantir a disponibilidade dos backups em caso de problemas nas instalaes. Entretanto, isso pode comprometer a confidencialidade e integridade desses backups. Uma possvel soluo criptografar o backup e gerar um checksum (MD5 ou SHA-1, por exemplo) dele antes que seja entregue a pessoas de fora da organizao. Uma verificao do checksum antes da restaurao pode servir como prova de que o backup no foi alterado desde que foi feito.

Quando for necessrio restaurar um sistema, isto deve ser feito com a mquina isolada da rede. Caso o sistema em questo tenha sido comprometido, revise a sua configurao aps a restaurao para certificar-se de que no tenha ficado nenhuma porta de entrada previamente instalada pelo invasor.

4.10. Como Manter-se Informado

Administradores envolvidos com a segurana de redes e sistemas necessitam buscar informaes de forma a se manterem atualizados em relao a novas vulnerabilidades e correes de segurana. Devido sua natureza dinmica, o principal meio de obteno de tais informaes a prpria Internet, atravs de listas de discusso por email e sites especializados. Os tipos mais indicados de listas de discusso para um administrador incluem: lista de anncios de segurana de fornecedores de software e hardware cujos produtos so usados na sua rede; listas de administradores e/ou usurios desses produtos; lista de alertas de segurana do CERT/CC.8 Destas, as listas de anncios de segurana de fornecedores e a lista de alertas do CERT/CC so fortemente recomendadas a qualquer administrador. As listas destinadas a administradores e usurios de produtos, por sua vez, podem ajud-lo a conhecer melhor as ferramentas disponveis no seu ambiente computacional, muitas vezes levando-o a descobrir formas mais eficientes de trabalhar com elas.9 Existem outras listas que so indicadas para administradores que possuam alguma experincia e bons conhecimentos de programao. Essas listas costumam ter um alto trfego e o contedo das suas discusses bastante tcnico, muitas vezes envolvendo o uso de conceitos avanados. A principal (e tambm a mais conhecida) destas listas a Bugtraq.10 A Web tambm oferece boas fontes de informaes atualizadas na rea de segurana, tais como: http://www.cert.org/advisories/ ; http://www.cert.org/current/current_activity.html ; http://online.securityfocus.com/ ; http://www.incidents.org/ . IMPORTANTE: recomendvel que voc tome cuidado com a procedncia de informaes relacionadas com segurana, procurando se restringir a fontes confiveis. Existem diversos relatos de informaes propositalmente erradas terem sido divulgadas com o objetivo de abrir brechas na segurana da rede daqueles que as tenham seguido.

4.11. Precaues contra Engenharia Social

Engenharia social a tcnica (ou arte) de aproveitar-se da boa f de pessoas para obter informaes que possibilitem ou facilitem o acesso aos recursos computacionais de uma organizao por parte de usurios no autorizados. Dentre as informaes procuradas destacam-se as seguintes: senhas de acesso; topologia da rede; endereos IP em uso; nomes de hosts em uso; listas de usurios; tipos e verses de sistemas operacionais usados; tipos e verses de servios de rede usados; dados sigilosos sobre produtos e processos da organizao.

Existem diversas formas de se efetuar um ataque de engenharia social, mas todas elas tm em comum a caracterstica de usarem basicamente psicologia e perspiccia para atingir os seus propsitos. Atualmente, as mais populares so:

 usar telefone ou email para se fazer passar por uma pessoa (geralmente algum da equipe de suporte tcnico ou um superior da pessoa atacada) que precisa de determinadas informaes para resolver um suposto problema; aproveitar informaes divulgadas em um frum pblico da Internet (lista de discusso por email, newsgroup, IRC) por um administrador ou usurio que busca ajuda para resolver algum problema na rede; enviar programas maliciosos ou instrues especialmente preparadas para um administrador ou usurio, com o objetivo de abrir brechas na segurana da rede ou coletar o mximo de informaes possvel sobre ela (esta tcnica particularmente eficaz quando a pessoa pede auxlio em algum frum de discusso pela Internet); navegar por websites ou repositrios FTP em busca de informaes teis -muitas vezes possvel encontrar descries detalhadas da infra-estrutura computacional e/ou documentos que, por descuido ou esquecimento, no foram removidos do servidor. A principal maneira de se prevenir contra estes ataques orientando os usurios (seo 4.1) e administradores de redes e sistemas sobre como agir nestas situaes. A poltica de segurana da organizao (seo 2.1) desempenha um papel importante neste sentido, pois nela que so definidas as normas para proteo da informao na organizao. Recomenda-se fortemente que os administradores tenham cuidado ao buscar ajuda em listas de discusso e outros fruns na Internet. Estes recursos podem ser valiosos na resoluo de problemas, mas tambm podem ser usados por terceiros para coleta de informaes. Procure reduzir a exposio da sua rede em fruns pblicos -- por exemplo, use endereos IP, nomes de hosts e usurios hipotticos, e tente no revelar mais sobre a topologia da rede do que o estritamente necessrio para resolver um dado problema. Tome cuidado com orientaes passadas por pessoas desconhecidas, e evite executar programas de origem obscura ou no confivel -- eles podem ser uma armadilha.

4.12. Uso Eficaz de Firewalls

Antes de apresentar tcnicas para aumentar a eficcia de firewalls, importante definir o que um firewall e o que ele no . Um firewall bem configurado um instrumento importante para implantar a poltica de segurana da sua rede. Ele pode reduzir a informao disponvel externamente sobre a sua rede, ou, em alguns casos, at mesmo barrar ataques a vulnerabilidades ainda no divulgadas publicamente (e para as quais correes no esto disponveis). Por outro lado, firewalls no so infalveis. A simples instalao de um firewall no garante que sua rede esteja segura contra invasores. Umfirewall no pode ser a sua nica linha de defesa; ele mais um dentre os diversos mecanismos e procedimentos que aumentam a segurana de uma rede. Outra limitao dos firewalls que eles protegem apenas contra ataques externos ao firewall, nada podendo fazer contra ataques que partem de dentro da rede por ele protegida. Esta seo apresenta apenas alguns aspectos importantes da utilizao de firewalls. Maiores informaes podem ser obtidas emhttp://www.interhack.net/pubs/fwfaq/ e nas referncias do apndice A.

4.12.1. A Escolha de um Firewall

Existem diversas solues de firewall disponveis no mercado. A escolha de uma delas est atrelada a fatores como custo, recursos desejados e flexibilidade, mas um ponto essencial a familiaridade com a plataforma operacional do firewall. A maioria dos firewalls est disponvel para um conjunto reduzido de plataformas operacionais, e a sua escolha deve se restringir a um dos produtos que roda sobre uma plataforma com a qual os administradores da rede tenham experincia. Por exemplo, se voc utiliza basicamente servidores Unix, aconselhvel que voc escolha um firewall que rode sobre a sua variante favorita de Unix, e no um produto que requeira Windows NT. Existem, basicamente, duas razes para esta recomendao. A primeira delas que voc deve estar familiarizado o suficiente com o sistema onde o firewall ser executado para configur-lo de forma segura. A existncia de um firewall instalado em um sistema inseguro pode ser at mais perigosa do que a ausncia do firewall na rede. A segunda razo que os produtos tendem a seguir a filosofia da plataforma onde rodam; por exemplo, a maioria dos firewalls para Windows configurada atravs de menus e janelas, ao passo que muitos firewalls para Unix so configurados por meio de arquivos texto.

Outro fator importante consiste na escolha do tipo de firewall que ser implementado. Dentre os tipos atualmente disponveis, destacam-se os filtros de pacotes, amplamente utilizados por terem baixo custo associado e por estarem normalmente integrados a dispositivos como roteadores ou alguns tipos de switches, ou por serem facilmente integrveis ou fazerem parte do kernel de diversos sistemas operacionais. Os filtros de pacotes normalmente analisam informaes colhidas nos cabealhos de cada pacote, tais como endereos IP de origem e destino, protocolo utilizado, portas, e so basicamente divididos em duas categorias: os estticos (stateless) e os dinmicos (stateful). Os filtros estticos so projetados para tomar decises (como bloquear ou permitir) para cada pacote que entra ou sai de uma rede, sem considerar o contexto em que cada pacote est inserido. Portanto, neste caso preciso estabelecer regras, de forma explcita, tanto para o trfego que entra na rede quanto para o trfego que sai (incluindo o trfego de resposta a conexes iniciadas externamente). J os filtros dinmicos rastreiam e mantm o estado das conexes contidas no trfego de rede, fazendo com que cada pacote seja analisado dentro de um contexto (conexo que contm o pacote). Este tipo de filtro de pacotes normalmente apresenta um melhor desempenho e permite que os dois sentidos de trfego (entrada e sada) sejam considerados/tratados separadamente, uma vez que o trfego de resposta gerenciado automaticamente, simplificando assim o conjunto de regras a ser mantido e muitas vezes aumentando a qualidade da filtragem. Administradores experientes em Unix tm disposio diversas ferramentas de software livre que podem ser usadas para implementar firewalls, conforme mostra a tabela 2. Estas ferramentas permitem construir firewalls eficientes a um custo relativamente baixo, uma vez que seus requisitos de hardware so modestos. Tabela 2: Ferramentas de software livre para a construo de firewalls Ferramenta Plataforma Linux Linux Caracterstica filtro de pacotes (stateless) filtro de pacotes (stateful)

ipchains iptables ipfw pf ipfilter Squid 4.12.2. Localizao dos Firewalls

FreeBSD filtro de pacotes (stateful) OpenBSD filtro de pacotes (stateful) vrios Unix filtro de pacotes (stateful)

TIS Firewall Toolkit vrios Unix proxy para vrios protocolos

vrios Unix proxy Web/FTP

A localizao dos firewalls na rede depende normalmente da sua poltica de segurana. Entretanto, existem algumas regras que se aplicam grande maioria dos casos: Todo o trfego deve passar pelo firewall. Um firewall s pode atuar sobre o trfego que passa por ele. A eficcia de um firewall pode ser severamente comprometida se existirem rotas alternativas para dentro da rede (modems, por exemplo). Caso no seja possvel eliminar todas esses caminhos, eles devem ser documentados e fortemente vigiados atravs de outros mecanismos de segurana. Tenha um filtro de pacotes no permetro da sua rede. Esse filtro pode estar localizado entre o seu roteador de borda e o interior da rede ou no prprio roteador, se ele tiver esta capacidade e voc se sentir confortvel utilizando-o para esta tarefa. O filtro de pacotes de borda importante para tarefas como bloqueio global de alguns tipos de trfego (vide seo 4.12.3) e bloqueio rpido de servios durante a implantao de correes aps a descoberta de uma nova vulnerabilidade. Coloque os servidores externos em uma DMZ. recomendvel que voc coloque os seus servidores acessveis externamente (Web, FTP, correio eletrnico, etc.) em um segmento de rede separado e com acesso altamente restrito, conhecido como

DMZ (DeMilitarized Zone, ou zona desmilitarizada). A principal importncia disso proteger a rede interna contra ataques provenientes dos servidores externos -- uma precauo contra a eventualidade de que um destes servidores seja comprometido. Por exemplo, suponha que um atacante invada o servidor Web e instale um sniffer na rede. Se este servidor Web estiver na rede interna, a probabilidade dele conseguir capturar dados importantes (tais como senhas ou informaes confidenciais) muito maior do que se ele estiver em uma rede isolada. Considere o uso de firewalls internos. Em alguns casos, possvel identificar na rede interna grupos de sistemas que desempenham determinadas tarefas comuns, tais como desenvolvimento de software, webdesign e administrao financeira. Nestes casos, recomenda-se o uso de firewalls internos para isolar estas sub-redes umas das outras, com o propsito de aumentar a proteo dos sistemas internos e conter a propagao de ataques bem-sucedidos.

4.12.3. Critrios de Filtragem

Existem basicamente dois critrios de filtragem que podem ser empregados em firewalls. O primeiro o de default deny, ou seja, todo o trfego que no for explicitamente permitido bloqueado. O segundo, default allow, o contrrio, ou seja, todo o trfego que no for explicitamente proibido liberado. A configurao dos firewalls deve seguir a poltica de segurana da rede. Se a poltica permitir, recomendvel adotar uma postura de default deny. Esta abordagem , geralmente, mais segura, pois requer uma interveno explcita do administrador para liberar o trfego desejado, o que minimiza o impacto de eventuais erros de configurao na segurana da rede. Alm disso, ela tende a simplificar a configurao dos firewalls. No permetro da rede, pelo menos as seguintes categorias de trfego devem ser filtradas: trfego de entrada (ingress filtering): pacotes com endereo de origem pertencente a uma rede reservada (seo 4.8) ou a um dos blocos de endereos da sua rede interna; trfego de sada (egress filtering): pacotes com endereo de origem pertencente a uma rede reservada ou que no faa parte de um dos blocos de endereos da rede interna. Um aspecto que deve ser considerado com cuidado a filtragem do protocolo ICMP. O bloqueio indiscriminado de ICMP pode prejudicar o funcionamento da rede. Por outro lado, o ICMP pode ser usado para revelar a um possvel atacante informaes sobre a rede e seus sistemas. Observe que muitos firewalls do tipo stateful permitem a passagem de mensagens ICMP de erro associadas a conexes estabelecidas, o que minimiza o impacto da filtragem. O trfego para a DMZ deve ser altamente controlado. As nicas conexes permitidas para os sistemas dentro da DMZ devem ser as relativas aos servios pblicos (acessveis externamente). Conexes partindo da DMZ para a rede interna devem ser, na sua maioria, tratadas como conexes oriundas da rede externa, aplicando-se a poltica de filtragem correspondente. IMPORTANTE: a DMZ e a rede interna no podem estar no mesmo segmento de rede (ligadas ao mesmo hub ou switch, por exemplo). imprescindvel que estas redes estejam em segmentos de rede separados.

4.12.4. Exemplos
Diversas arquiteturas podem ser empregadas para a implantao de firewalls em uma rede. A opo por uma delas obedece a uma srie de fatores, incluindo a estrutura lgica da rede a ser protegida, custo, funcionalidades pretendidas e requisitos tecnolgicos dos firewalls.

Figura 3: Um exemplo simples de firewall Esta seo apresenta duas destas arquiteturas. A inteno no cobrir todas as possibilidades de uso de firewalls, mas fornecer exemplos de arquiteturas que funcionam e que podem eventualmente ser adotados (na sua forma original ou aps passarem por adaptaes) em situaes reais. A figura 3 mostra um exemplo simples de uso de firewall. Neste exemplo, o firewall possui trs interfaces de rede: uma para a rede externa, uma para a rede interna e outra para a DMZ. Por default, este firewall bloqueia tudo o que no for explicitamente permitido (default deny). Alm disso, ofirewall usado do tipo stateful, que gera dinamicamente regras que permitam a entrada de respostas das conexes iniciadas na rede interna; portanto, no preciso incluir na configurao do firewall regras de entrada para estas respostas. O trfego liberado no exemplo da figura 3 o seguinte: interface externa: o sada: tudo com exceo de pacotes com endereos de origem pertencentes a redes reservadas; pacotes com endereos de origem no pertencentes aos blocos da rede interna. o entrada: apenas os pacotes que obedecem s seguintes combinaes de protocolo, endereo e porta de destino: 25/TCP para o servidor SMTP; 53/TCP e 53/UDP para o servidor DNS; 80/TCP para o servidor WWW.

interface interna: o o sada: tudo; entrada: nada;

interface da DMZ: o sada: portas 25/TCP (SMTP), 53/UDP e 53/TCP (DNS) e 113 (IDENT); o entrada: alm das mesmas regras de entrada da interface externa, tambm permitido o trfego para todos os servidores na com porta de destino 22/TCP (SSH) e endereo de origem na rede interna.

Figura 4: Um exemplo mais complexo de firewall A figura 4 ilustra o uso de firewalls em uma situao mais complexa do que a anterior. Neste segundo exemplo, alm dos servidores externos na DMZ, h tambm servidores na intranet e no setor financeiro da organizao. Devido importncia das informaes mantidas neste setor, a sua rede conta com a proteo adicional de um firewall interno, cujo objetivo principal evitar que usurios com acesso rede interna da organizao (mas no rede do setor financeiro) possam comprometer a integridade e/ou o sigilo dessas informaes. A configurao do firewall externo neste segundo exemplo quase idntica ao primeiro. Entretanto, no presente caso supe-se que o servidor SMTP visvel externamente (o da DMZ) repassa as mensagens recebidas para o servidor SMTP da intranet. Para que isso seja possvel, necessrio mudar a regra de filtragem para a interface interna, liberando o trfego do servidor SMTP da DMZ para a porta 25/TCP do servidor SMTP da intranet. A configurao do firewall interno, por sua vez, bastante simples. O servidor da rede do setor financeiro permite apenas acesso via HTTPS para que os funcionrios da organizao possam

consultar seus contracheques; outros tipos de acesso no so permitidos. O trfego liberado por este firewall o seguinte: interface externa (rede interna): o sada: tudo; o entrada: apenas pacotes para o servidor do setor financeiro com porta de destino 443/TCP (HTTPS) e endereo de origem na rede interna; interface interna (rede do setor financeiro): o o sada: tudo; entrada: tudo (a filtragem feita na interface externa).

4.13. Redes Wireless

Redes wireless, tambm conhecidas como IEEE 802.11, Wi-Fi ou WLANs, tornaram-se muito populares nos ltimos tempos. Embora sejam muito convenientes, sua instalao e operao requerem ateno do ponto de vista de segurana. Essa seo mostra alguns cuidados que devem ser tomados pelos administradores na instalao e operao segura destas redes.

4.13.1. Poltica de Uso da Rede Wireless

muito importante que seja definida uma poltica de uso da rede wireless, que deve ser incorporada na poltica de segurana da instituio, discutida na seo 2. Esta poltica deve cobrir pelo menos os seguintes itens: definir quem est autorizado a instalar Access Points (APs) nas dependncias da instituio. A instalao de APs por pessoal no autorizado, sem as precaues listadas nas sees 4.13.2 e 4.13.4, pode comprometer seriamente a segurana de toda rede; definir quem est autorizado a utilizar a rede wireless da instituio; prever as aes a serem tomadas em caso de roubo ou perda de equipamentos wireless; definir que tipo de informao pode transitar pela rede; descrever as configuraes mnimas de segurana para APs, clientes, etc.

4.13.2. Topologia

Dois fatores muito importantes devem ser considerados ao definir a topologia de uma rede wireless: o posicionamento do AP e a necessidade de isolar esta rede da rede interna da instituio. Com relao ao posicionamento do AP, dependendo da potncia de sua antena, uma rede wireless pode ter um alcance que ultrapasse os limites geogrficos da instituio, o que pode facilitar o uso e a escuta no autorizadas. Esse vazamento de sinal extremamente comum e deve servir de estmulo para o administrador implementar medidas como o uso de autenticao e criptografia, discutidas na seo 4.13.3. Alm do uso de criptografia, um posicionamento cuidadoso dos APs (mais para o centro de um prdio, longe de janelas, etc.) pode minimizar o vazamento desnecessrio de sinal. importante notar que esse procedimento deve ser encarado apenas como uma camada adicional de segurana, uma vez que um atacante interessado em sua instituio pode fazer uso de uma antena amplificadora de sinal e ter acesso sua rede wireless mesmo a distncias maiores. Com relao ao isolamento da rede wireless da rede interna da instituio deve-se ter em mente que as redes wireless jamais devem ser conectadas diretamente dentro de uma rede protegida por um firewall (devem ser consideradas "untrusted"). Colocar um AP diretamente em uma rede protegida por um firewall seria equivalente instalao de um modem dentro dessa rede, por exemplo. Uma soluo de topologia pode ser colocar todos os APs em um segmento de rede prprio e colocar um firewall entre esse segmento e o resto da infra-estrutura de rede da instituio. Alm de possibilitar o controle de utilizao, ainda prov uma boa possibilidade de integrao com VPNs.

Por fim, prefervel conectar um AP a um switch, no a um hub. O trfego de rede em um hub pode ser potencialmente enviado para toda a redewireless e eventualmente ser interceptado por algum cliente.

4.13.3. Criptografia e Autenticao

Devido facilidade com que uma rede wireless pode ser utilizada por pessoas no autorizadas e facilidade com que se pode capturar o trfego, extremamente importante o uso de criptografia e de mecanismos de autenticao numa rede wireless. O padro 802.11 originalmente suporta apenas dois tipos de autenticao do cliente wireless: "open authentication" e "shared-key authentication". No primeiro modo o cliente precisa apenas fornecer o SSID (Service Set Identifier) correto para juntar-se rede. No modo "shared-key authentication" preciso o conhecimento de uma chave WEP (Wired Equivalent Privacy) para que isso ocorra. importante notar que essa autenticao do dispositivo wireless, e no dos usurios da rede. O padro 802.11 define o protocolo WEP como mecanismo para cifrar o trfego entre os APs e os clientes wireless. Essa cifragem ocorre na camada de enlace e exige que todos os participantes compartilhem a mesma chave WEP esttica. O WEP possui diversas fragilidades, mas apesar disso seu uso recomendvel e deve ser encarado como uma camada adicional de segurana. Para aumentar a segurana de sua rede wireless deve-se escolher o maior tamanho de chave WEP possvel, sendo essencial trocar as chaves WEP que venham nas configuraes padro dos equipamentos. O uso de criptografia nas aplicaes, como SSH e SSL, tambm recomendvel para minimizar os riscos de escuta no autorizada. Alm disso tambm deve ser considerado o uso de criptografia no prprio TCP/IP, como IPsec e o uso de VPNs em geral. Salvo algumas extenses implementadas por alguns fabricantes, o protocolo 802.11 original apresenta alguns problemas: fragilidade do protocolo WEP; problemas de gerenciamento das chaves WEP, que devem ser trocadas manualmente; falta de autenticao dos usurios da rede. Existem vrias iniciativas para a criao de novos padres que aperfeioem a segurana do protocolo, sendo recomendvel que sejam utilizados assim que estiverem disponveis. Entre eles, pode-se citar: IEEE 802.1x, que suporta autenticao e distribuio de chaves atravs da consulta a um servidor de autenticao; WAP (Wi-Fi Protected Access), desenvolvido em conjunto pela Wi-Fi Alliance e IEEE, que prov algumas melhorias criptogrficas, como o uso do protocolo TKIP (Temporal Key Integrity Protocol). Tambm prov suporte para autenticao de usurios via 802.1x e EAP (Extensible Authentication Protocol); IEEE 802.11i, sendo desenvolvido pelo IEEE 802.11 Task Group i (TGi), que inclui uma nova verso de WEP utilizando AES (Advanced Encryption Standard), alm da definio de um framework de distribuio de chaves.

4.13.4. Access Points

Existem vrias questes importantes que devem ser consideradas na escolha e configurao de um AP: Consideraes na escolha: na escolha de um modelo de AP muito importante determinar quais recursos de criptografia e autenticao so suportados, conforme discutido na seo 4.13.3. Outro fator importante saber se o AP possibilita upgrades de firmware, permitindo incorporar novos padres e eventuais correes lanadas pelo fabricante. Alterao de configuraes padro: muitos modelos de APs vm com configuraes de fbrica que so de conhecimento pblico, incluindo senhas default. extremamente importante que todas as configuraes originais sejam mudadas pelo administrador antes de colocar o AP em produo, incluindo:

senhas de administrao11; SSID; chaves WEP; SNMP communities.

IMPORTANTE: alguns APs possuem uma opo de reset fsico que faz com que todas as configuraes de fbrica sejam recarregadas. Nesses casos, muito importante que o AP fique em um local com acesso fsico controlado. Modos de configurao: a maioria dos APs permite vrios12 meios de configurao: HTTP, SNMP, Telnet, etc. Sempre que possvel, importante desabilitar os que no forem necessrios e optar por um modo de configurao que no seja pela prpria rede wireless, mas sim pela rede cabeada ou ainda via conexo serial. Isso minimiza as chances de que a sesso de configurao com o AP seja capturada por algum cliente wireless. Broadcast de SSID: uma recomendao til desabilitar o broadcast de SSID pelo AP. Embora seja uma medida simples, pode dificultar o uso de alguns programas populares de mapeamento de redes wireless. Filtragem por endereo MAC: alguns APs possuem o recurso de filtragem de clientes wireless por endereo MAC. Embora endereos MAC possam ser forjados e muitas vezes no seja prtico manter uma lista de endereos MAC dos clientes autorizados (e em alguns casos invivel, como em conferncias), o administrador pode considerar o uso desse recurso como uma camada adicional de segurana do seu ambiente wireless. Uma ltima considerao diz respeito possibilidade de desligar o AP quando no estiver sendo utilizado, conforme especificado na sua poltica de uso.

4.13.5. Proteo aos Clientes Wireless

Como descrito na seo 4.1, a educao dos usurios importante e eles tambm devem receber orientao sobre a utilizao segura de redes wireless. Uma rede wireless deve ser considerada uma rede pblica e, portanto, mais suscetvel a ataques. Desse modo, recomendvel que os clientes dessa rede, tais como notebooks, PDAs, estaes de trabalho, etc, passem por um processo de instalao e configurao que vise o aumento de sua segurana, incluindo: aplicao de patches; uso de firewall pessoal; instalao e atualizao de antivrus; desligamento do compartilhamento de disco, impressora, etc.

4.13.6. Monitorao da Rede Wireless

Da mesma forma que muitos administradores monitoram o seu ambiente de rede convencional (com o uso de IDSs, por exemplo), a monitorao da rede wireless tambm importante. Essa monitorao pode detectar: clientes conectados em um dado instante (em horrios improvveis ou simplesmente para acompanhamento); instalao de APs no autorizados; dispositivos que no estejam usando WEP; ataques contra os clientes wireless; acessos no autorizados; mudanas de endereos MAC; mudanas de canal; DoS ou jamming. [3] O caso mais comum de incorreo quando existe um nome para resolver um dado IP mas este mesmo nome no est registrado em nenhum DNS direto, ou ento resolve para outro endereo IP. Um exemplo disso seria o endereo IP 192.0.2.34 resolver parafoo.example.org mas este nome resolver para o IP 192.0.2.76. [ voltar ] [4] D. Crocker, "Mailbox Names for Common Services, Roles and Functions", RFC 2142, Internet

Mail Consortium, May 1997. Disponvel emhttp://www.ietf.org/rfc/rfc2142.txt . [ voltar ] [5] Implementaes de SSH para diversos sistemas operacionais esto disponveis em http://www.openssh.com . [ voltar ] [6] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. Disponvel em http://www.ietf.org/rfc/rfc3330.txt . [ voltar ] [7] Y. Rekhter et.al., "Address Allocation for Private Internets", RFC 1918, February 1996. Disponvel em http://www.ietf.org/rfc/rfc1918.txt .[ voltar ] [8] Veja http://www.cert.org/contact_cert/certmaillist.html . [ voltar ] [9] A seo 4.11 mostra alguns cuidados que devem ser tomados por quem utiliza listas de discusso por email. [ voltar ] [10] Veja http://online.securityfocus.com/ . [ voltar ] [11] dicas para a escolha de boas senhas podem ser obtidas na seo 3.4. [ voltar ] [12] inclusive alguns modos, como o caso de TFTP, habilitados por alguns fabricantes sem serem documentados. [ voltar ]
[ Sumrio ]

A. Referncias Adicionais A.1. URLs de Interesse

"A Case-Study in Best Practice for Operating System Management". http://www.sage-ie.org/slides/case_study/ . Pgina que contm um estudo de caso sobre boas prticas no gerenciamento de sistemas operacionais. Apresenta, de forma exemplificada, uma metodologia adotada para a instalao, configurao e administrao de sistemas operacionais em um grande ambiente de rede. "Cartilha de Segurana para Internet". http://cartilha.cert.br/ .

Pgina a partir da qual pode ser obtida a verso mais recente do documento "Cartilha de Segurana para Internet", do glossrio echecklist que o acompanham. Este documento tem por finalidade sanar algumas dvidas comuns sobre segurana de computadores e redes, e dirigido aos usurios de redes e Internet. Recomenda-se que administradores de redes utilizem os documentos que compem a Cartilha no processo de educao dos seus usurios. "CERT Security Improvement Modules: Security Knowledge in Practice". http://www.cert.org/security-improvement/skip.html . Apresenta, de forma grfica, os passos que esto envolvidos na obteno de uma rede mais segura. Contm uma grande quantidade de material que aborda de forma mais aprofundada vrios dos assuntos discutidos neste documento. "NIST SP 800-48, Wireless Network Security 802.11, Bluetooth and Handheld Devices". http://csrc.nist.gov/publications/drafts/draft-sp800-48.pdf Documento do NIST que contm informaes detalhadas sobre segurana em redes wireless, incluindo um estudo de caso e umchecklist no final do documento. "Prticas de Segurana para Administradores de Redes Internet". http://www.cert.br/docs/seg-adm-redes/. Pgina a partir da qual pode ser obtida a verso mais recente deste documento e do checklist que o acompanha. Contm tambm um histrico de revises dos documentos. "Security Links". http://www.cert.br/links/.

Uma compilao de URLs sobre diversos aspectos de administrao e segurana de redes e sistemas, incluindo diversos apresentados neste documento, e que atualizada periodicamente.

A.2. Livros
802.11 Wireless Networks: The Definitive Guide. Matthew Gast. O'Reilly, 2002. http://www.oreilly.com/catalog/802dot11/ Este livro uma tima referncia sobre redes 802.11, embora no seja focado exclusivamente em segurana. Cobre as diferentes verses do protocolo, suas peculiaridades, fatores que devem ser considerados ao definir a topologia da rede e questes relacionadas com a monitorao e o uso seguro destas redes. Building Internet Firewalls, 2nd Edition. Elizabeth D. Zwicky, Simon Cooper e D. Brent Chapman. O'Reilly & Associates, 2000. http://www.oreilly.com/catalog/fire2/ Um dos melhores livros disponveis sobre firewalls, com muitas informaes prticas sobre como constru-los. Computer Security: Art and Science. Matt Bishop. Addison-Wesley, 2002. http://nob.cs.ucdavis.edu/book/ Livro que cobre de forma aprofundada os aspectos tericos relacionados com segurana. Contm captulos que discutem polticas de segurana, uso de criptografia e implementao de sistemas de forma segura. De maior interesse para administradores de redes a sesso "Practicum", onde discutida a aplicao de diversos conceitos de segurana em situaes reais. DNS and BIND, 4th Edition. Paul Albitz e Cricket Liu. O'Reilly & Associates, 2001. http://www.oreilly.com/catalog/dns4/ Este livro possui bastante informao sobre o protocolo DNS e a sua principal implementao, o BIND. A quarta edio contm um captulo sobre segurana de servidores DNS. Firewalls and Internet Security: Repelling the Wily Hacker, 2nd Edition. Willian R. Cheswick, Steven M. Bellovin e Aviel D. Rubin. Addison-Wesley, 2003. http://www.wilyhacker.com/ Excelente referncia sobre segurana em Internet. Alm de apresentar uma grande seo sobre o estudo de Firewalls e VPNs, tambm dispe de sees que envolvem outros temas, como ferramentas e tcnicas utilizadas em ataques e na defesa de redes e sistemas de informao, anlise de problemas e prticas de segurana em intranets, e implantao de hosts fortificados e de sistemas de deteco de intruso (IDSs). O livro possui diversos exemplos prticos, que refletem a experincia de seus autores. Practical Unix and Internet Security, 3rd Edition. Simson Garfinkel, Gene Spafford e Alan Schwartz. O'Reilly & Associates, 2003. http://www.oreilly.com/catalog/puis3/ Este livro considerado referncia obrigatria em segurana de sistemas Unix. Esta nova edio aborda as variantes de Unix mais populares e cobre questes atuais relacionadas a redes e segurana de sistemas. O livro contm informaes sobre autenticao, sistema de arquivos, criptografia, wireless, firewalls, deteco de intruso, anlise forense, entre outras.

 TCP/IP Illustrated, Volume 1: The Protocols. W. Richard Stevens. AddisonWesley, 1994. A melhor obra disponvel sobre TCP/IP. O texto claro e didtico, e numerosos exemplos (usando tcpdump) ajudam a compreender o funcionamento dos protocolos na prtica. Unix System Administration Handbook, 3rd Edition. Evi Nemeth, Garth Snyder, Scott Seebass e Trent R. Hein. Prentice Hall, 2001. O clssico sobre administrao de sistemas Unix, recentemente atualizado. Traz explicaes claras e objetivas sobre como realizar, de forma eficiente, as diferentes tarefas que competem a um administrador de sistemas Unix. Segurana Nacional. Nelson Murilo de O. Rufino. Novatec, 2001. http://www.segurancanacional.com.br/ Uma boa referncia sobre segurana computacional em portugus, com enfoque em aspectos prticos. Srie O'Reilly sobre administrao de servios de rede e sistemas operacionais especficos. http://www.oreilly.com/ A editora O'Reilly conhecida pela qualidade tcnica dos seus livros, que geralmente abordam um assunto especfico com bastante profundidade e com um enfoque bem prtico. Existem guias para servidores como Apache (Web) e Sendmail (SMTP), alm de diversos ttulos sobre uso e administrao de sistemas operacionais (incluindo Unix, Linux e Windows). Windows 2000 Security. Roberta Bragg. New Riders Publishing, 2000.

Este livro discute segurana no Windows 2000, dando maior nfase aos aspectos prticos. Os temas abordados incluem IPsec, Kerberos, Active Directory, RAS e RRAS. Windows NT Security: A Practical Guide to Securing Windows NT Servers & Workstations. Charles B. Rutstein. McGraw-Hill, 1997. Um bom livro sobre segurana de Windows NT, incluindo instalao, configurao, uso do Registry, logging, entre outros assuntos. Writing Information Security Policies. Scott Barman. New Riders Publishing, 2001. Este livro explica como escrever e implementar uma poltica de segurana. Contm vrios exemplos extrados de polticas reais, que podem ser usados como guia para a formulao de novas polticas.
[ Sumrio ] $Date: 2011/02/21 19:45:53 $