Práticas de Segurança para Administradores de Redes Internet

Pr ticas de Seguranca para Administradores de Redes Internet a
NIC BR Security Ofce http://www.nbso.nic.br/ Vers o 1.2 a 16 de maio de 2003

Copyright c 2002, 2003 NBSO
Resumo ` Este documento e destinado a administradores de redes ligadas a Internet, incluindo provedores de acesso e de conte do. O seu prop sito e ser um guia com informacoes para congurar, administrar e operar estas u o redes de forma mais segura.
Sum rio a
1 Introducao 1.1 1.2 1.3 2 Organizacao do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Como Obter este Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nota de Copyright e Distribuicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 4 4 6 6 8 9 9 9 11 13 14 14
Polticas 2.1 2.2 Polticas de Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Polticas de Uso Aceit vel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a
Instalacao e Conguracao Segura de Sistemas 3.1 3.2 3.3 3.4 3.5 3.6 Preparacao da Instalacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estrat gias de Particionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Documentacao da Instalacao e Conguracao . . . . . . . . . . . . . . . . . . . . . . . . . . . Senhas de Administrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instalacao Mnima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Desativacao de Servicos N o Utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a
Praticas de Seguranca para Administradores de Redes Internet
2/46
3.7 3.8
Instalacao de Correcoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prevencao de Abuso de Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.1 3.8.2 Controle de Relay em Servidores SMTP . . . . . . . . . . . . . . . . . . . . . . . . . Controle de Acesso a Proxies Web . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15 15 15 16 17 17 17 17 18 18 18 18 19 19 19 20 20 21 22 22 23 23 24 24 24 25 25 26 26
Administracao e Operacao Segura de Redes e Sistemas 4.1 4.2 Educacao dos Usu rios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a Ajuste do Rel gio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.2.1 4.2.2 4.3 Sincronizacao de Rel gios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o Timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Equipes de Administradores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 4.3.2 4.3.3 Comunicacao Eciente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controle de Alteracoes na Conguracao . . . . . . . . . . . . . . . . . . . . . . . . . Uso de Contas Privilegiadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 4.4.2 4.4.3 Geracao de Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Armazenamento de Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoramento de Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 Limitacao de Transfer ncias de Zona . . . . . . . . . . . . . . . . . . . . . . . . . . e Separacao de Servidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Uso de Privil gios Mnimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Cuidado com Informacoes Sensveis no DNS . . . . . . . . . . . . . . . . . . . . . . DNS Reverso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6
Informacoes de Contato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 4.6.2 4.6.3 Enderecos Eletr nicos Padr o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o a Contato no DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contatos no WHOIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7 4.8
Eliminacao de Protocolos sem Criptograa . . . . . . . . . . . . . . . . . . . . . . . . . . . Cuidados com Redes Reservadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3/46
4.9
Polticas de Backup e Restauracao de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . .
27 28 29 31 31 32 33 33 36 36 36 37 38 38 39 40 40 41 43
4.10 Como Manter-se Informado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Precaucoes contra Engenharia Social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12 Uso Ecaz de Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12.1 A Escolha de um Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12.2 Localizacao dos Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12.3 Crit rios de Filtragem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 4.12.4 Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13 Redes Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.1 Poltica de Uso da Rede Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.2 Topologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.3 Criptograa e Autenticacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.4 Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.5 Protecao aos Clientes Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.6 Monitoracao da Rede Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Refer ncias Adicionais e A.1 URLs de Interesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 Livros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Indice Remissivo
4/46
Introducao
Este documento procura reunir um conjunto de boas pr ticas em conguracao, administracao e operacao a ` segura de redes conectadas a Internet. A implantacao destas pr ticas minimiza as chances de ocorrerem pro a blemas de seguranca e facilita a administracao das redes e recursos de forma segura. E importante frisar que este conjunto representa o mnimo indispens vel dentro de um grande universo de boas pr ticas de seguranca, a a o que equivale a dizer que a sua adocao e um bom comeco mas n o necessariamente e suciente em todas as a situacoes. As recomendacoes apresentadas s o eminentemente pr ticas e, tanto quanto possvel, independentes de a a plataforma de software e hardware. A maioria dos princpios aqui expostos e gen rica; a sua efetiva aplicacao e requer que um administrador determine como estes princpios podem ser implementados nas plataformas que ele utiliza. ` Este documento e dirigido ao pessoal t cnico de redes conectadas a Internet, especialmente aos adminise tradores de redes, sistemas e/ou seguranca, que s o os respons veis pelo planejamento, implementacao ou a a operacao de redes e sistemas. Tamb m podem se beneciar da sua leitura gerentes com conhecimento t cnico e e de redes.
1.1
Organizacao do Documento
O restante deste documento est organizado da seguinte maneira. A secao 2 apresenta polticas importantes a para respaldar e viabilizar os procedimentos t cnicos descritos nas secoes subseq entes. A secao 3 mostra como e u congurar sistemas e redes de forma mais segura. Na secao 4 s o discutidos m todos para se ter seguranca na a e administracao e operacao de redes e sistemas. O ap ndice A traz sugest es de material de consulta para quem e o queira obter conhecimentos mais aprofundados sobre algum dos temas abordados nas secoes de 2 a 4.
1.2
Como Obter este Documento
Este documento pode ser obtido em http://www.nbso.nic.br/docs/seg-adm-redes/. Como ele e periodicamente atualizado, certique-se de ter sempre a vers o mais recente. a No mesmo endereco tamb m est disponvel um checklist que resume as principais pr ticas apresentadas e a a neste documento, e que pode ser usado para o acompanhamento da sua implantacao. Caso voc tenha alguma sugest o para este documento ou encontre algum erro nele, entre em contato e a atrav s do endereco doc@nic.br. e
1.3
Nota de Copyright e Distribuicao
Este documento e Copyright c 2002, 2003 NBSO. Ele pode ser livremente copiado desde que sejam respeitadas as seguintes condicoes: 1. E permitido fazer e distribuir c pias inalteradas deste documento, completo ou em partes, contanto que o esta nota de copyright e distribuicao seja mantida em todas as c pias, e que a distribuicao n o tenha ns o a comerciais.
5/46
2. Se este documento for distribudo apenas em partes, instrucoes de como obt -lo por completo devem ser e includas. 3. E permitido o uso dos exemplos de documentos e de conguracao includos neste texto. Tal uso e completamente livre e n o est sujeito a nenhuma restricao. a a 4. E vedada a distribuicao de vers es modicadas deste documento, bem como a comercializacao de c pias, o o sem a permiss o expressa do NBSO. a Embora todos os cuidados tenham sido tomados na preparacao deste documento, o NBSO n o garante a a correcao absoluta das informacoes nele contidas, nem se responsabiliza por eventuais conseq encias que u possam advir do seu uso.
6/46
2
2.1
Polticas
Polticas de Seguranca
Uma poltica de seguranca e um instrumento importante para proteger a sua organizacao contra ameacas a ` seguranca da informacao que a ela pertence ou que est sob sua responsabilidade. Uma ameaca a seguranca a ` e compreendida neste contexto como a quebra de uma ou mais de suas tr s propriedades fundamentais (cone dencialidade, integridade e disponibilidade). A poltica de seguranca n o dene procedimentos especcos de manipulacao e protecao da informacao, a ` mas atribui direitos e responsabilidades as pessoas (usu rios, administradores de redes e sistemas, funcion rios, a a gerentes, etc.) que lidam com essa informacao. Desta forma, elas sabem quais as expectativas que podem ter e quais s o as suas atribuicoes em relacao a seguranca dos recursos computacionais com os quais trabalham. a ` ` Al m disso, a poltica de seguranca tamb m estipula as penalidades as quais est o sujeitos aqueles que a dese e a cumprem. Antes que a poltica de seguranca seja escrita, e necess rio denir a informacao a ser protegida. Usualmente, a isso e feito atrav s de uma an lise de riscos, que identica: e a recursos protegidos pela poltica; ameacas as quais estes recursos est o sujeitos; ` a vulnerabilidades que podem viabilizar a concretizacao destas ameacas, analisando-as individualmente. Uma poltica de seguranca deve cobrir os seguintes aspectos: aspectos preliminares: abrang ncia e escopo de atuacao da poltica; e denicoes fundamentais; normas e regulamentos aos quais a poltica est subordinada; a quem tem autoridade para sancionar, implementar e scalizar o cumprimento da poltica; meios de distribuicao da poltica; como e com que freq encia a poltica e revisada. u poltica de senhas: requisitos para formacao de senhas; perodo de validade das senhas; normas para protecao de senhas; reuso de senhas; senhas default. direitos e responsabilidades dos usu rios, tais como: a utilizacao de contas de acesso;
7/46
utilizacao de softwares e informacoes, incluindo quest es de instalacao, licenciamento e copyright; o protecao e uso de informacoes (sensveis ou n o), como senhas, dados de conguracao de sistemas a e dados condenciais da organizacao; uso aceit vel de recursos como email, news e p ginas Web; a a ` direito a privacidade, e condicoes nas quais esse direito pode ser violado pelo provedor dos recursos (a organizacao); uso de antivrus. direitos e responsabilidades do provedor dos recursos, como: backups; diretrizes para conguracao e instalacao de sistemas e equipamentos de rede; autoridade para conceder e revogar autorizacoes de acesso, conectar e desconectar sistemas e equi pamentos de rede, alocar e registrar enderecos e nomes de sistemas e equipamentos; monitoramento de sistemas e equipamentos de rede; normas de seguranca fsica. acoes previstas em caso de violacao da poltica: diretrizes para tratamento e resposta de incidentes de seguranca; penalidades cabveis. Cabe ressaltar que a lista de t picos acima n o e exaustiva nem tampouco se aplica a todos os casos. o a Cada organizacao possui um ambiente distinto e os seus pr prios requisitos de seguranca, e deve, portanto, o recomend vel, por exemplo, desenvolver uma poltica de seguranca que se molde a essas peculiaridades. E a que organizacoes que possuam uma rede wireless incorporem uma poltica especca para este tipo de rede ` (secao 4.13.1) a sua poltica de seguranca. Alguns fatores importantes para o sucesso de uma poltica de seguranca s o: a apoio por parte da administracao superior; a poltica deve ser ampla, cobrindo todos os aspectos que envolvem a seguranca dos recursos computaci onais e da informacao sob responsabilidade da organizacao; a poltica deve ser periodicamente atualizada de forma a reetir as mudancas na organizacao; deve haver um indivduo ou grupo respons vel por vericar se a poltica est sendo respeitada; a a todos os usu rios da organizacao devem tomar conhecimento da poltica e manifestar a sua concord ncia a a em submeter-se a ela antes de obter acesso aos recursos computacionais; a poltica deve estar disponvel em um local de f cil acesso aos usu rios, tal como a intranet da organiza a a cao. Dentre os itens acima, o apoio por parte da administracao superior e essencial. Se a poltica de seguranca n o for encampada pela administracao, ela rapidamente ser deixada de lado pelos demais seto a a ` res da organizacao. Al m disso, e importante que os seus membros d em o exemplo no que diz respeito a e e observ ncia da poltica de seguranca. a
8/46
Os seguintes fatores inuem negativamente na aceitacao de uma poltica de seguranca e podem lev -la ao a fracasso: a poltica n o deve ser demasiadamente detalhada ou restritiva; a o excesso de detalhes na poltica pode causar confus o ou diculdades na sua implementacao; a n o devem ser abertas excecoes para indivduos ou grupos; a a poltica n o deve estar atrelada a softwares e/ou hardwares especcos. a
2.2
Polticas de Uso Aceit vel a
A poltica de uso aceit vel (AUPAcceptable Use Policy) e o documento que dene como os recursos a computacionais da organizacao podem ser utilizados. Ela deve ser p blica e estar disponvel a todos os que u utilizam a infra-estrutura computacional da organizacao, sendo recomend vel que a autorizacao para uso dos a recursos seja condicionada a uma concord ncia expressa com os seus termos. a A AUP e geralmente parte integrante da poltica de seguranca global. Para muitas organizacoes, ela ser a composta pelos itens da poltica que afetam diretamente os usu rios de recursos computacionais, principalmente a os que denem seus direitos e responsabilidades. Por outro lado, organizacoes que oferecem acesso a usu rios externos (tais como provedores de acesso a ` Internet) devem denir uma poltica de uso aceit vel para esses usu rios que seja independente da AUP a qual a a est o sujeitos os seus usu rios internos. E importante que os usu rios externos tomem conhecimento dessa a a a poltica e saibam que o uso dos recursos est condicionado ao seu cumprimento. a
9/46
Instalacao e Conguracao Segura de Sistemas
Uma vez estabelecidas as polticas de seguranca apropriadas para a sua rede (conforme exposto na secao 2), a etapa seguinte deve ser a conguracao segura dos sistemas que estar o nessa rede. a Caso n o exista uma documentacao atualizada que detalhe a conguracao de alguns ou todos os sistemas a em uso na sua rede, e aconselh vel que estes sistemas sejam reinstalados observando-se as recomendacoes aqui a expostas, ou, pelo menos, que a sua conguracao seja revisada e a documentacao correspondente atualizada. ` IMPORTANTE: um sistema s dever ser conectado a Internet ap s os passos descritos nas secoes 3.1 a 3.8 o a o terem sido seguidos. A pressa em disponibilizar um sistema na Internet pode levar ao seu comprometimento.
3.1
Preparacao da Instalacao
A instalacao de um sistema deve ser feita com ele isolado do mundo externo. Para tanto, os seguintes princpios devem ser seguidos: planeje a instalacao, denindo itens como: o prop sito do sistema a ser instalado; o os servicos que este sistema disponibilizar ; a a conguracao de hardware da m quina; a como o disco ser particionado, etc. a providencie de antem o todos os manuais e mdias de instalacao que ser o utilizados; a a instale o sistema a partir de dispositivos de armazenamento locais (CD, ta ou disco), desconectado da rede; caso voc precise ligar o sistema em rede (para fazer download de atualizacoes, por exemplo), coloque-o e em uma rede isolada, acessvel apenas pela sua rede interna. Caso seja possvel, evite concentrar todos os servicos de rede em uma unica m quina, dividindo-os entre a v rios sistemas. Isto e desej vel pois aumenta a disponibilidade dos servicos na sua rede e reduz a extens o de a a a um eventual comprometimento a partir de um deles.
3.2
Estrat gias de Particionamento e
Conforme mencionado na secao 3.1, um dos aspectos que devem ser includos no planejamento da ins talacao e como ser feito o particionamento do(s) disco(s) do sistema. Embora isso dependa basicamente da a utilizacao pretendida para o sistema, existem alguns fatores que devem ser levados em consideracao no mo mento de decidir como o disco deve ser particionado. Um princpio b sico e dividir o disco em v rias particoes em vez de usar uma unica particao ocupando o a a disco inteiro. Isto e recomend vel por diversas raz es: a o
10/46
Um usu rio ou um programa mal-comportado pode lotar uma particao na qual tenha permiss o de escrita a a ( reas tempor rias e de armazenamento de logs s o suscetveis a este problema). Se os programas do a a a sistema estiverem em outra particao eles provavelmente n o ser o afetados, evitando que o sistema trave. a a Caso uma particao seja corrompida por alguma raz o, as outras particoes provavelmente n o ser o afe a a a tadas. Em alguns sistemas (notadamente sistemas Unix), e possvel denir algumas caractersticas individuais para cada particao. Por exemplo, algumas particoes podem ser usadas em modo read-only, o que e util para particoes que contenham bin rios que s o modicados com pouca freq encia. a a u Em alguns casos a exist ncia de v rias particoes permite m ltiplas operacoes de disco em paralelo e/ou o e a u uso de otimizacoes individuais para cada particao, o que pode aumentar signicativamente o desempenho do sistema. O uso de v rias particoes geralmente facilita o procedimento de backup do sistema, pois simplica a funcoes como: copiar particoes inteiras de uma s vez; o excluir particoes individuais do procedimento; fazer backups em intervalos diferentes para cada particao. As particoes especcas que devem ser criadas variam de sistema para sistema, n o existindo uma regra que a possa ser sempre seguida. Entretanto, recomenda-se avaliar a conveni ncia da criacao de particoes separadas e para as areas onde s o armazenados itens como: a programas do sistema operacional; dados dos usu rios; a logs; arquivos tempor rios; a las de envio e recepcao de emails (servidores SMTP); las de impress o (servidores de impress o); a a reposit rios de arquivos (servidores FTP); o p ginas Web (servidores HTTP). a Note que a lista acima n o e exaustiva, podendo existir outras areas do sistema que merecam uma particao a separada. Da mesma forma, existem itens dentre os acima que n o se aplicam a determinados casos. Consulte a a documentacao do seu sistema operacional para ver se ela cont m recomendacoes a respeito do particionamento e adequado dos discos. As particoes devem ser dimensionadas de acordo com os requisitos de cada sistema. Em muitos ca sos, o tamanho ocupado pelo sistema operacional e fornecido na sua documentacao, o que pode auxiliar na determinacao do tamanho de algumas particoes. Qualquer que seja a estrutura de particionamento escolhida, e recomend vel que voc tenha pelo menos a e um esboco dela por escrito antes de comecar a instalacao. Isto agiliza o processo de instalacao e reduz a probabilidade de que se faca uma determinada escolha sem que as suas conseq encias sejam adequadamente u previstas.
11/46
3.3
Documentacao da Instalacao e Conguracao
Uma medida importante para permitir uma r pida avaliacao da situacao de um sistema e a documentacao a de sua instalacao e conguracao. A id ia e ter uma esp cie de logbook (ou di rio de bordo), que detalhe os e e a componentes instalados no sistema e todas as modicacoes na sua conguracao global. Esse logbook pode ser particularmente util para determinar qual vers o de determinado pacote est instalada a a o. Muitas vezes um administrador precisa consultar diversas no sistema ou para reconstituir uma dada instalaca fontes e realizar v rias tentativas antes de instalar e/ou congurar corretamente um determinado pacote de a software. A exist ncia de um documento que relate quais os passos exatos que tiveram que ser seguidos para que e a instalacao/conguracao fosse bem sucedida permite que esse mesmo pacote possa ser instalado com correcao e rapidez em outro sistema ou ocasi o. Conforme ser visto na secao 4.3, a import ncia deste documento cresce a a a na medida em que a responsabilidade pela administracao dos sistemas seja compartilhada por diversas pessoas. O formato e o grau de sosticacao do logbook dependem de diversos fatores, e cada administrador deve determinar qual a melhor maneira de manter essas informacoes. Um simples arquivo texto pode revelar-se extremamente ecaz, como mostram os exemplos da gura 1. O que realmente importa e que esse documento esteja disponvel em caso de falha (acidental ou provocada) do sistema, e que ele contenha informacoes su cientes para que, a partir dele, seja possvel reconstituir a exata conguracao que o sistema possua antes da falha, sem que seja necess rio recorrer a backups.1 a E essencial que alteracoes na conguracao do sistema e de seus componentes estejam documentadas neste logbook. A entrada referente a estas alteracoes deve conter, no mnimo, os seguintes itens: data da modicacao; respons vel pela modicacao; a justicativa para a modicacao; descricao da modicacao. Deve ser possvel, ainda, reconstituir a situacao antes da mudanca na conguracao a partir dessa entrada. A gura 1 mostra um exemplo com algumas entradas do logbook de um servidor FTP. A primeira entrada registra a instalacao 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 caram ativas ap s a instalacao; o quais os usu rios criados (com seus respectivos UIDs e GIDs). a
1A
exist ncia do logbook n o diminui a import ncia dos backups, que ser o tratados na secao 4.9. e a a a
12/46
Logbook para vangogh.example.org (IP 192.0.2.24) ================================================ 26/Fev/2002 Responsvel: Joe a
Instalaco de vangogh.example.org, servidor FTP de example.org. Instalado o a sistema operacional GoodBSD verso 6.5. A instalaco foi feita usando a opco a a a custom do menu de instalaco. O disco foi particionado da seguinte maneira: a Filesystem /dev/wd0a /dev/wd0d /dev/wd0e Size 100M 3.0G 500M Mount point / /var /tmp | | | | Filesystem /dev/wd0f /dev/wd0g /dev/wd0h Size 2.0G 400M 4.0G Mount point /usr /home /home/ftp As portas
Uma lista dos pacotes instalados est em /usr/local/sysadm/pkg.inst. a abertas aps a instalaco so (netstat -a): o a a Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address tcp 0 0 *.ftp *.* tcp 0 0 *.ssh *.* udp 0 0 vangogh.example.org.ntp *.* udp 0 0 localhost.ntp *.* udp 0 0 *.ntp *.* udp 0 0 *.syslog *.*
(state) LISTEN LISTEN
Criados os usurios joe (UID=501), alice (UID=502), bob (UID=503) e caio a (UID=504). Cada usurio pertence ao seu prprio grupo (GID=UID) e joe, alice e a o bob pertencem tambm ao grupo wheel. e -----------------------------------------------------------------------01/Mar/2002 Responsvel: Alice a Instalado o foo-1.2.3, uma ferramenta para anlise de logs de FTP. Os fontes a esto em /usr/local/src/foo-1.2.3. Os comandos necessrios para a instalaco foram: a a a $ ./configure $ make # make install Para usar o programa, foi necessrio criar o usurio foo (UID=300,GID=100/users) a a e o diretrio /usr/local/share/foo (owner=foo, group=users), com permisses 0755. o o -----------------------------------------------------------------------03/Mar/2002 Responsvel: Bob a Criado o grupo foobar (GID=300), para os usurios do pacote foo. O diretrio a o /usr/local/share/foo teve seu grupo alterado de users para foobar e as permisses de 0755 para 0750. Modificaco necessria para que apenas usurios o a a a pertencentes ao grupo foobar tenham acesso aos programas do pacote foo. Os usurios alice, bob e caio foram adicionados ao grupo foobar. a -----------------------------------------------------------------------03/Mar/2002 Responsvel: Alice a Modificado o /etc/rc.local para carregar o daemon bard (usado pelo pacote foo) no boot. Um diff da modificaco est em /usr/local/sysadm/rc.local-bard.diff. a a
Figura 1: Exemplos de entradas no logbook
13/46
Ap s a instalacao inicial do sistema operacional, no dia 01/03 foi instalado um pacote chamado foo, vers o o a 1.2.3. A entrada correspondente no logbook descreve os passos que foram seguidos para compilar e instalar o pacote e para preparar o sistema para o seu uso (criacao de um usu rio e um diret rio, com suas respectivas a o informacoes). A terceira entrada registra algumas alteracoes que tiveram que ser feitas na conguracao do sistema pa ra que o pacote foo pudesse ser usado corretamente. Por sua vez, a ultima entrada do exemplo apresenta uma modicacao na inicializacao do sistema para carregar um daemon (software servidor) usado pelo paco te. Observe que ambas as entradas permitem que a situacao anterior do sistema (ou seja, a situacao antes das modicacoes descritas) seja restaurada, caso isso se revele necess rio ou desej vel. a a IMPORTANTE: o logbook de um sistema e um documento sensvel, pois cont m informacoes que podem e ser usadas para comprometer mais facilmente a seguranca deste sistema. Sendo assim, ele deve ser armazenado e manipulado com cuidado, de acordo com a poltica para documentos sensveis da sua organizacao.
3.4
Senhas de Administrador
Durante a instalacao de um sistema, em determinado momento ser solicitado que voc informe uma senha a e de administrador (root ou Administrator). Na maioria dos casos, e o pr prio programa de instalacao que o solicita a escolha da senha. Em outros casos, a senha de administrador deve ser denida ap s o primeiro boot o do sistema. Procure estabelecer esta senha t o cedo quanto possvel durante a instalacao do sistema. De prefer ncia, a e tenha uma senha j em mente quando comecar a instalacao. a Uma senha adequada e aquela f cil de ser lembrada e difcil de ser adivinhada. Ela deve respeitar, no a mnimo, os seguintes crit rios: e ter um comprimento mnimo de 8 caracteres; ser formada por letras, n meros e caracteres especiais; u n o ser derivada de seus dados pessoais, tais como nomes de membros da famlia (incluindo animais de a estimacao), n meros de telefone, placas de carros, n meros de documentos e datas; u u n o dever ser adivinhada por quem conheca suas prefer ncias pessoais (time para o qual torce, escritor, a e ator ou cantor favorito, nomes de livros, lmes ou m sicas, etc.); u n o estar presente em dicion rios (de portugu s ou de outros idiomas). a a e Uma sugest o para formar senhas que se encaixem nos requisitos acima e usar as primeiras ou ultimas letras a das palavras de uma frase, adicionando n meros e smbolos e trocando min sculas e mai sculas para dicultar u u u ataques baseados em forca bruta. Por exemplo, a partir das iniciais de the book is on the table obt m-se, e inicialmente, tbiott. A partir da, e possvel trocar a letra o por um 0 (zero) e o pen ltimo t por um u smbolo +, colocar algumas letras em mai sculo e acrescentar outras letras, chegando a tBi0+TbL, uma u senha bastante difcil de ser adivinhada ou obtida por forca bruta.2
2 Evidentemente
esta deixou de ser uma senha segura por constar neste documento.
14/46
3.5
Instalacao Mnima
Um sistema mais seguro comeca pela instalacao do mnimo possvel de pacotes e componentes, especial mente os que implementam servicos de rede. Este mnimo depende fundamentalmente do prop sito do sistema o em quest o e do ambiente de rede no qual ele est inserido. Por exemplo, em princpio um sistema dedicado a a a servir p ginas Web n o precisa de um software servidor SMTP, assim como uma estacao de trabalho n o a a a precisa de um servidor HTTP. A justicativa para esta recomendacao e bastante simples. E comum que servicos n o utilizados n o se a a jam monitorados por falhas de seguranca, o que aumenta a possibilidade de n o ser aplicada uma correcao a necess ria. A reducao no n mero de pacotes instalados diminui a chance de que o sistema possua uma vulnea u rabilidade que possa vir a ser explorada por um atacante. Muitas vezes, administradores preferem instalar componentes cujo prop sito ou funcionalidade desconheo cam por receio de que alguma coisa deixe de funcionar no sistema. Entretanto, a maioria dos sistemas atuais possui algum mecanismo de controle de depend ncias que avisa quando determinado componente precisa de e outro para funcionar. Em outras palavras, freq entemente e possvel deixar de instalar v rios componentes sem u a comprometer a funcionalidade do sistema. Consulte a documentacao do seu sistema ou o suporte t cnico do e seu fornecedor para saber se isto se aplica ao seu caso. Alguns programas de instalacao permitem que o administrador escolha entre uma instalacao tpica e uma personalizada (para experts). Quando possvel, opte pela personalizada, evitando instalar componentes cuja ` funcionalidade seja desconhecida ou que voc n o esteja certo quanto a sua necessidade. e a Em outros sistemas a instalacao se d em duas etapas, a instalacao do sistema base (sobre a qual o admi a nistrador tem mnimo ou nenhum controle) e a instalacao de pacotes ou componentes adicionais. Neste caso, instale o sistema base e selecione cuidadosamente quais os componentes extras que ser o adicionados ao sistea ma. Neste tipo de sistema, a desativacao de servicos n o utilizados (secao 3.6) e muito importante e deve ser a realizada com especial atencao.
3.6
Desativacao de Servicos N o Utilizados a
O passo seguinte a uma instalacao mnima e a desativacao de servicos (locais e, principalmente, de rede) que n o ser o imediatamente utilizados no sistema. A l gica por tr s desta recomendacao e a mesma por tr s a a o a a da instalacao mnima de pacotes: reduzir a exposicao do sistema a vulnerabilidades. Embora possa parecer que exista redund ncia entre este passo e o anterior, na pr tica surgem situacoes a a nas quais o administrador e forcado a instalar um pacote ou componente completo para poder utilizar um subconjunto das funcionalidades oferecidas por esse pacote. Al m disso, muitos programas de instalacao de e sistemas operacionais optam por maximizar a funcionalidade disponibilizada aos usu rios, e a conguracao a padr o do sistema traz ativados todos os servicos que foram instalados. Caso uma dessas situacoes ocorra, as a funcionalidades que n o ser o utilizadas dever o ser desativadas ou mesmo removidas do sistema. a a a Por exemplo, suponha que um pacote de servicos de impress o contenha tanto um cliente quanto um servi a dor de impress o remota. Se o sistema necessitar apenas do software cliente, o administrador deve desabilitar a a parte referente ao software servidor neste sistema. Caso n o seja possvel desativar servicos individualmente, uma alternativa e usar um ltro de pacotes para a bloquear as portas TCP/UDP usadas por esses servicos, impedindo que eles sejam acessados atrav s da rede. e Isto ser discutido em maiores detalhes na secao 4.12. a
15/46
IMPORTANTE: a desativacao de servicos e/ou a remocao de arquivos efetuadas nesta fase dever o ser a documentadas no logbook do sistema.
3.7
Instalacao de Correcoes
Depois de um sistema ter sido corretamente instalado e congurado, e necess rio vericar se n o existem a a correcoes (patches, xes, service packs) para vulnerabilidades conhecidas nos componentes instalados. A mai oria dos fornecedores de software libera correcoes para problemas de seguranca que sejam descobertos em um sistema, sem que se tenha de esperar pela sua pr xima vers o. Na maioria das vezes, estas correcoes est o o a a disponveis atrav s da Internet. Consulte seu fornecedor para saber como manter-se informado a respeito de e correcoes para o seu sistema e de que forma elas podem ser obtidas. ` Nem sempre todas as correcoes disponveis precisam ser instaladas. Restrinja-se aquelas que corrigem problemas em componentes que estejam efetivamente instalados no seu sistema. Em caso de d vida, recorra ao u suporte t cnico do seu fornecedor. A instalacao indiscriminada de atualizacoes pode enfraquecer a seguranca e do sistema ao inv s de fortalec -la. e e Registre no logbook a instalacao de correcoes. Mantenha em sua rede um reposit rio das atualizacoes que o j foram utilizadas, para facilitar a instalacao das mesmas em outros sistemas. a
IMPORTANTE: muitas vezes algumas conguracoes do sistema s o alteradas durante o processo de instala a
cao de correcoes. Sendo assim, e recomend vel que voc reveja a conguracao do seu sistema ap s instalar a e o uma correcao para certicar-se de que a instalacao n o tenha revertido eventuais modicacoes que voc tenha a e feito (especialmente aquelas destinadas a desativar servicos).
IMPORTANTE: a instalacao de correcoes deve ser realizada n o s como parte da instalacao inicial do a o sistema, mas tamb m durante o seu tempo de vida, a intervalos peri dicos ou sempre que surgirem vulnerabilie o dades que o afetem. A secao 4.10 traz algumas recomendacoes sobre como manter-se informado a respeito de novas vulnerabilidades que afetem os seus sistemas.
3.8 Prevencao de Abuso de Recursos

Existem alguns servicos que, se mal congurados, podem permitir que usu rios externos abusem dos re a cursos da sua rede, ainda que isso n o implique na ocorr ncia de uma invas o. Dois destes servicos s o o email a e a a e os proxies de Web. A conguracao incorreta destes servicos pode causar v rios efeitos indesej veis. Um deles e que recursos a a computacionais da organizacaoa comecar pelo link Internet, mas incluindo CPU, discos e mem ria dos o servidoress o consumidos por terceiros sem que eles paguem por esse uso. Em muitos casos, esses recursos a s o exauridos de forma que usu rios legtimos n o possam utilizar o servico. a a a Al m disso, servidores mal congurados s o muitas vezes usados para disseminar conte do ilegal, tal como e a u pornograa envolvendo criancas. Se um conte do deste tipo for encontrado em sistemas sob sua responsabili u dade, existe a possibilidade de que voc e/ou sua organizacao venham a ser legalmente implicados no caso. e 3.8.1 Controle de Relay em Servidores SMTP
Na sua conguracao padr o, muitos servidores SMTP v m com o relay aberto, permitindo que eles sejam a e usados para enviar mensagens de e para qualquer rede ou domnio, independente dos enderecos envolvidos
16/46
serem da sua rede ou n o. Estes servidores s o amplamente explorados para envio de SPAM. a a Al m das conseq encias j mencionadas, diversas redes bloqueiam a recepcao de mensagens a partir de e u a servidores que tenham sido ou estejam sendo usados para envio de SPAM, fazendo com que usu rios do servidor a com relay aberto n o possam enviar mensagens a usu rios dessas redes. H que se considerar tamb m que o a a a e uso de servidores SMTP de terceiros torna mais difcil a localizacao e identicacao dos spammers, diminuindo as chances de que eles sejam punidos por estes abusos. Para resolver este problema de relay aberto voc precisa congurar os seus servidores SMTP corretamente. e A conguracao adequada deve permitir apenas: envio de mensagens com endereco de origem local e endereco de destino local ou externo; recepcao de mensagens com endereco de origem local ou externo e endereco de destino local. Informacoes sobre como corrigir este problema para diferentes servidores SMTP est o disponveis em a http://www.mail-abuse.org/tsi/. Na maioria dos casos, e possvel fechar o relay mesmo quando a rede possui roaming users, usando me canismos como POP-before-SMTP e SMTP AUTH. Caso a sua rede necessite suportar usu rios deste tipo, a consulte a documentacao do seu servidor SMTP ou o seu fornecedor para saber como fechar o relay sem prejudicar a utilizacao do servico 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) tamb m podem ser abusados se n o forem tomadas as devidas precaucoes. e a Um proxy mal congurado pode ser usado por usu rios externos como um trampolim para acessar recura sos de forma an nima. Esta anonimidade pode ser usada para cometer crimes, tais como envio de mensagens o caluniosas, difamat rias ou ameacadoras e divulgacao de pornograa envolvendo criancas. o A conguracao correta para um proxy Web e aquela que libera o acesso somente aos enderecos IP de ` usu rios autorizados (pertencentes a sua rede). Consulte a documentacao do seu software ou o suporte t cnico a e do seu fornecedor para obter maiores informacoes sobre como congurar o controle de acesso no seu proxy.
17/46
4
4.1
Administracao e Operacao Segura de Redes e Sistemas

Educacao dos Usu rios a
Uma tarefa extremanente importante e que deve fazer parte do cotidiano de administradores de redes e a constante educacao dos usu rios. Sabe-se que grande parte dos problemas de seguranca s o originados na a a rede interna da organizacao e, muitas vezes, s o causados pelo desconhecimento de conceitos e procedimentos a b sicos de seguranca por parte dos usu rios. a a Um exemplo cl ssico deste problema e a m conguracao do programa de leitura de emails de um usu rio, a a a que faz com que qualquer arquivo anexado a uma mensagem seja automaticamente aberto ou executado, permitindo a instalacao de backdoors, cavalos de tr ia, disseminacao de vrus, etc. o O primeiro fator que contribui diretamente para o processo de educacao e o estabelecimento de polticas de seguranca e de uso aceit vel (secao 2) claras, sem ambiguidades, conhecidas e completamente entendidas a pelos usu rios da rede. a Outro fator importante e o estabelecimento de um canal de comunicacao, por exemplo, atrav s de listas de e emails, onde informacoes sobre quest es relevantes de seguranca s o frequentemente passadas para os usu rios o a a da rede. A descoberta de uma vulnerabilidade de seguranca que afeta o servidor Web da organizacao pode n o ser relevante para os usu rios, mas a noticacao da descoberta de um novo vrus, sua forma de infeccao e a a m todos de prevencao s o informacoes que devem ser conhecidas e aplicadas por todos os usu rios. e a a Muitas vezes e, principalmente, em grandes organizacoes, tarefas como a instalacao e conguracao do sistema operacional e softwares de um computador s o realizadas pelo pr prio usu rio. Da vem um dos a o a fatores de grande import ncia neste processo de educacao, pois a execucao de tais tarefas tem impacto direto a na seguranca das redes e sistemas de uma organizacao. Procurando cobrir os t picos necess rios para a educacao do usu rio, dentre outras quest es, foi desenvolo a a o vida a Cartilha de Seguranca para a Internet, que tem por nalidade sanar algumas d vidas comuns sobre u seguranca de computadores e redes e sobre o signicado de termos e conceitos amplamente utilizados na In ternet. Al m disso, a cartilha procura enumerar, explicar e fornecer um guia para uma s rie de procedimentos e e que visam aumentar a seguranca de um computador e de posturas que um usu rio pode adotar para garantir sua a seguranca na Internet. Este documento pode ser obtido em http://www.nbso.nic.br/docs/cartilha/.
4.2
Ajuste do Rel gio o
4.2.1 Sincronizacao de Rel gios o Os rel gios de todos os sistemas da sua rede (incluindo as estacoes de trabalho) dever o estar sincronizados, o a ou seja, dever o ter exatamente o mesmo hor rio. Para que isso aconteca, voc deve usar um protocolo de a a e sincronizacao de rel gios, tal como o NTP (Network Time Protocol). Este protocolo e o mais recomendado, o pois existem implementacoes dele para os mais variados sistemas operacionais, como pode ser visto em http: //www.ntp.org/. Para obter maior precis o no ajuste e para minimizar o tr fego desnecess rio na rede, sugere-se que a a a a sincronizacao via NTP seja implementada observando-se as seguintes recomendacoes:
18/46
1. Procure manter em sua rede um servidor NTP local. Esse servidor e quem ir realizar a sincronizacao a com um servidor externo. As demais m quinas da sua rede, por sua vez, ter o seus rel gios sincronizados a a o com o rel gio do servidor local. o 2. Muitos backbones disponibilizam um servidor NTP a seus clientes. Consulte o suporte t cnico do seu e backbone para vericar se ele oferece este servico e como voc pode fazer para utiliz -lo. e a
4.2.2
Timezone
Caso voc trabalhe com servidores Unix, ajuste o rel gio de hardware destes sistemas para a hora padr o de e o a Greenwich (GMT) e congure adequadamente o seu fuso hor rio (timezone) para que a hora local seja exibida a corretamente. O uso do timezone certo tamb m possibilita o ajuste automatizado do rel gio por conta do hor rio de ver o. e o a a Para que isso seja possvel, voc dever criar ou obter um arquivo de informacoes de timezone com as datas e a corretas de incio e m do hor rio de ver o. Para maiores informacoes, consulte a documentacao do comando a a zic.
4.3
Equipes de Administradores
Em muitas redes, a administracao de sistemas e uma responsabilidade dividida entre v rias pessoas. Nesses a casos, e necess rio estabelecer algumas regras para garantir a eci ncia do trabalho em equipe. a e
4.3.1
Comunicacao Eciente
Em primeiro lugar, e essencial que os diferentes administradores comuniquem-se de maneira eciente. Um ` bom modo de fazer isto e estabelecer listas de discuss o por email que sejam internas a sua organizacao. Esa tas listas podem ser usadas para, entre outros prop sitos, comunicar alteracoes na conguracao dos sistemas, o noticar os demais administradores a respeito de ocorr ncias relevantes e servir como mecanismo de acompae nhamento da divis o de tarefas. a A grande vantagem de usar listas de discuss o e que elas possibilitam a comunicacao entre os adminisa tradores mesmo que alguns trabalhem em diferentes turnos ou locais. O hist rico das listas pode servir para o documentar decis es tomadas e para atualizar um administrador que tenha passado algum tempo afastado de o suas atividades.
4.3.2
Controle de Alteracoes na Conguracao
A partir do momento em que v rias pessoas cam encarregadas da administracao de um sistema, torna-se a necess rio dispor de meios que possibilitem a identicacao de quem foi o respons vel por cada alteracao na sua a a conguracao. Isso permite resolver problemas de forma mais eciente, pois a pessoa que realizou determinada modicacao e a mais indicada para ajudar na resolucao de eventuais complicacoes dela decorrentes. Conforme mostrado na secao 3.3, o logbook pode auxiliar nessa tarefa. Para isso, e necess rio que em cada a entrada no logbook conste o nome da pessoa respons vel pelas modicacoes ali descritas. a
19/46
Uma forma mais automatizada de fazer isso e atrav s do uso de ferramentas de controle de vers o como e a o RCS (http://www.cs.purdue.edu/homes/trinkle/RCS/) e o CVS (http://www.cvshome.org). Essas ferramentas tamb m permitem manter um hist rico de arquivos de conguracao, de forma a possibilitar a e o recuperacao de antigas vers es desses arquivos. Recomenda-se que, sempre que possvel, este tipo de ferra o menta seja usado em sistemas que possuam m ltiplos administradores. u 4.3.3 Uso de Contas Privilegiadas Um problema que surge em sistemas com m ltiplos administradores e a diculdade de se manter um registro u do uso de contas privilegiadas, tais como root e Administrator. Sempre que possvel, estas contas n o devem ser usadas diretamente. Um administrador deve entrar no a sistema usando sua conta pessoal e a partir dela realizar suas tarefas, usando os privil gios mais elevados e apenas quando estritamente necess rio. Em sistemas Unix, isso e realizado atrav s do comando su. O su traz a e como benefcio adicional o fato de que o seu uso normalmente ca registrado nos logs do sistema, permitindo que se identique quem acessou a conta de root em um determinado perodo. O sudo (http://www.courtesan.com/sudo/) e uma ferramenta que permite que o administrador do sistema conceda a determinados usu rios a possibilidade de executar comandos predenidos como se eles fossem a root (ou outro usu rio), registrando nos logs do sistema a utilizacao desses comandos. O uso do sudo reduz a a necessidade de compartilhamento da senha de root, uma vez que os usu rios entram com sua pr pria senha a o para utilizar os comandos disponveis atrav s dele. Isso pode ser usado, por exemplo, quando existem contas e de operador que s o usadas para a realizacao de backups ou para invocar o procedimento de desligamento do a sistema. O sudo e extremamente congur vel, possibilitando, entre outros recursos, a denicao de grupos de usu a a rios, de comandos e de hosts e o uso de restricoes por host ou grupo de hosts (permitindo que o mesmo arquivo de conguracao seja usado em sistemas diferentes). IMPORTANTE: o uso de uma conta administrativa unica com senha compartilhada, que n o permita a determinar qual dos administradores acessou o sistema, deve ser evitado ao m ximo. a
4.4
Logs
Logs s o muito importantes para a administracao segura de sistemas, pois registram informacoes sobre o a seu funcionamento e sobre eventos por eles detectados. Muitas vezes, os logs s o o unico recurso que um a administrador possui para descobrir as causas de um problema ou comportamento an malo. o 4.4.1 Geracao de Logs Para que os logs de um sistema sejam uteis para um administrador, eles devem estar com o hor rio sina cronizado via NTP, ser t o detalhados quanto possvel, sem no entanto gerar dados em excesso. Informacoes a especialmente uteis s o aquelas relacionadas a eventos de rede, tais como conex es externas e registros de a o utilizacao de servicos (arquivos transferidos via FTP, acessos a p ginas Web, tentativas de login sem sucesso, a avisos de disco cheio, etc.). Para registrar estas informacoes, e necess rio congurar o sistema da maneira apropriada. A forma de fazer a isto geralmente varia para cada componente especco; consulte a documentacao para descobrir como habilitar o logging de informacoes no seu sistema e em softwares especcos como rewalls e servidores HTTP.
20/46
4.4.2
Armazenamento de Logs
Armazenamento on-line Os logs s o tradicionalmente armazenados em disco, no pr prio sistema onde s o gerados. Essa e a opcao a o a mais obvia, mas ela possui alguns riscos inerentes que devem ser compreendidos. ` O primeiro deles diz respeito a possibilidade dos logs serem destrudos durante uma invas o do sistema a (uma ocorr ncia bastante comum). Em alguns sistemas, isso pode ser contornado atrav s da instalacao de um e e loghost centralizado. ` Um loghost centralizado e um sistema dedicado a coleta e ao armazenamento de logs de outros sistemas em uma rede, servindo como um reposit rio redundante de logs. Via de regra, o loghost n o disponibiliza o a nenhum outro servico, nem mesmo acesso remoto para os administradores, para minimizar a possibilidade de que ele seja comprometido. Outra vantagem de loghosts centralizados e que eles facilitam a an lise dos logs e a correlacao de eventos ocorridos em sistemas distintos. Sempre que possvel, o uso de loghosts centralizados e fortemente recomendado. Um segundo risco e a possibilidade de um atacante usar o logging para executar um ataque de negacao de servico contra um determinado sistema, gerando eventos em excesso at que o disco onde s o armazenados e a os logs que cheio e o sistema trave em conseq encia disto. Conforme discutido na secao 3.2, o uso de uma u particao separada para armazenar os logs pode minimizar o impacto deste problema. Outro ponto que merece atencao e a rotacao autom tica de logs. Quando este recurso e utilizado, deve-se a garantir que os logs sejam movidos para o armazenamento off-line antes que eles sejam removidos do sistema pela rotacao, evitando assim a perda de registros. Alguns sistemas trazem a rotacao autom tica habilitada na a sua conguracao padr o; ao instalar um destes sistemas, verique se esta conguracao e compatvel com os a seus procedimentos de backup e armazenamento off-line de logs. Armazenamento off-line Evidentemente, os logs n o podem ser mantidos on-line por tempo indeterminado, pois acabam por consua mir muito espaco em disco. A melhor estrat gia para resolver esta quest o e transferir periodicamente os logs e a do disco para dispositivos de armazenamento off-line, tais como ta, CD-R ou DVD-R. E recomend vel gerar um checksum criptogr co (tal como MD5 ou SHA-1) dos logs que s o armazenados a a a off-line. Esse checksum deve ser mantido separado dos logs, para que possa ser usado para vericar a integridade destes caso eles venham a ser necess rios. a Os logs armazenados off-line devem ser mantidos por um certo perodo de tempo, pois podem vir a ser ne cess rios para ajudar na investigacao de incidentes de seguranca descobertos posteriormente. O Comit Gestor a e da Internet no Brasil recomenda que logs de conex es de usu rios de provedores de acesso estejam disponveis o a por pelo menos 3 anos (vide http://www.cg.org.br/acoes/desenvolvimento.htm). E aconselh vel que a os demais logs sejam mantidos no mnimo por 6 meses. E importante que os logs armazenados on-line sejam includos no procedimento de backup dos seus siste mas (backups s o tratados na secao 4.9). a 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, e importante que eles sejam monitorados com freq encia para permitir que eventuais problemas sejam u
21/46
rapidamente identicados. Existem algumas pr ticas recomend veis no que diz respeito ao monitoramento de logs: a a ` incorpore o h bito de inspecionar os logs a sua rotina de trabalho; a faca isso pelo menos uma vez por dia, mas tenha em mente que sistemas muito importantes ou que geram muita informacao podem precisar ter seus logs analisados com maior freq encia; u procure investigar as causas de qualquer registro que lhe pareca incorreto ou an malo, por mais insigni o cante que ele aparente ser; procure identicar o padr o de comportamento normal dos seus sistemas, para poder encontrar eventuais a anomalias com maior rapidez. Quando estiver analisando logs, voc deve certicar-se do timezone usado para registrar o hor rio dos e a eventos. Por exemplo, alguns softwares (como o Microsoft IIS, dependendo da conguracao adotada) registram eventos com a hora de Greenwich (GMT), e n o com a hora local. O desconhecimento do timezone em que a est o os logs pode facilmente invalidar uma an lise e lev -lo a conclus es equivocadas. a a a o ` A medida em que voc venha a adquirir pr tica com a an lise dos seus logs, voc poder escrever scripts ou e a a e a pequenos programas para auxili -lo nesta tarefa, automatizando assim parte do processo. Estes scripts s o uteis, a a por exemplo, para pr -processar os logs em busca de determinados conte dos, para eliminar conte do repetitivo e u u e para elaborar um resumo que pode ser enviado por email para o administrador do sistema. A eliminacao de padr es relacionados a eventos considerados normais pelo administrador e especialmente importante porque, o al m de reduzir o volume de logs a serem analisados, pode evidenciar alguma atividade incomum. e Uma outra opcao e utilizar ferramentas que permitam monitorar logs em tempo real, como por exemplo o e o swatch (http://swatch.sourceforge.net/). O swatch requer que voc especique um conjunto de padr es a serem monitorados e as acoes a serem tomadas quando um destes padr es e registrado nos logs. As acoes o podem ser de diversos tipos, como exibir a informacao registrada, noticar um determinado usu rio por email e a invocar um programa do sistema. A capacidade de execucao de comandos arbitr rios do swatch torna-o muito a atraente, pois permite, por exemplo, que sejam tomadas medidas como ltragem de um endereco IP que gere determinado log e envio de uma mensagem de alerta para um telefone celular. Existem tamb m v rias ferramentas que tem por objetivo processar diversos formatos conhecidos de logs e a e que podem ser bastante uteis para o administrador. Uma grande lista dessas ferramentas, bem como muita documentacao sobre monitoracao e an lise de logs est disponvel em http://www.loganalysis.org/. a a
4.5
DNS
O DNS (Domain Name System) e hoje um servico essencial para o funcionamento da Internet. Essa im ` port ncia, associada a natureza das informacoes que ele armazena, o tornam um dos alvos mais atraentes para a atacantes. Desse modo, uma conguracao adequada dos servidores DNS e crucial para aumentar a seguranca e colaborar para o bom funcionamento da rede. ` Servidores DNS expostos a Internet est o sujeitos a uma s rie de riscos, dentre os quais destacam-se: a e Vazamento de informacoes sensveis sobre a rede da organizacao atrav s de transfer ncias de zonas DNS. e e Essas informacoes podem ajudar um atacante a identicar os pontos fracos da rede e a escolher futuros alvos.
22/46
Ataques de envenenamento de cache (cache poisoning), que levam um servidor a armazenar informacoes forjadas. Tais informacoes podem ser usadas para comprometer a seguranca de clientes que facam con sultas a esse servidor. Comprometimento do servidor atrav s de vulnerabilidades no software de DNS, o que pode facilitar e outras quebras de seguranca no restante da rede da organizacao. Esta secao apresenta os principais mecanismos usados para eliminar ou minimizar estas ameacas, trazendo tamb m recomendacoes sobre a conguracao de DNS reverso. Informacoes mais detalhadas podem ser obtie das no documento Securing an Internet Name Server, do CERT/CC (disponvel em http://www.cert.org/ archive/pdf/dns.pdf) e nas refer ncias do ap ndice A. e e
4.5.1 Limitacao de Transfer ncias de Zona e Transfer ncias de zona s o usadas para que os servidores DNS escravos (secund rios) atualizem suas e a a informacoes sobre uma determinada zona DNS em relacao ao servidor mestre (prim rio) para essa zona. Res a tringir os enderecos que podem fazer transfer ncias de zona e uma importante medida para evitar que atacantes e obtenham informacoes detalhadas sobre a rede da organizacao, tais como enderecos de roteadores, servidores de correio eletr nico e outros servidores DNS. o As limitacoes de transfer ncias de zona devem ser aplicadas a todos os servidores com autoridade para um e domnio, independente de eles serem mestres ou escravos. Um equvoco comum e limitar as transfer ncias de e zona no servidor mestre e n o faz -lo nos servidores escravos. a e Preferencialmente, as transfer ncias de zona devem ser limitadas atrav s da conguracao de controles de e e acesso no software servidor DNS. No BIND, por exemplo, isso e feito no named.boot (BIND 4) ou named.conf (BIND 8 e 9). Consulte a documentacao do seu software ou o suporte t cnico do seu fornecedor para obter e informacoes sobre como limitar transfer ncias de zona da maneira mais apropriada. e IMPORTANTE: uma concepcao err nea, infelizmente bastante difundida, e a de que a limitacao de trans o fer ncias de zona deve ser feita ltrando o tr fego para a porta 53/TCP do servidor DNS. Como a porta 53/TCP e a tamb m e usada na resolucao de nomes, essa ltragem pode comprometer seriamente a funcionalidade do seu e servico de nomes.
4.5.2 Separacao de Servidores Servidores DNS possuem duas funcoes principais. A primeira delas e a de disponibilizar informacoes a respeito de zonas sobre as quais possuem autoridade (caso dos servidores mestres e escravos para uma deter minada zona). A segunda funcao e a de resolver nomes para clientes na sua rede (neste caso, o servidor e dito recursivo). Muitas vezes, o mesmo servidor desempenha ambas funcoes. Uma pr tica recomend vel e separar a funcao de servidor com autoridade (mestre ou escravo) da funcao a a de servidor recursivo. Isso minimiza a ec cia de ataques de envenenamento de cache DNS. Na pr tica, essa a a separacao signica 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 n o possuem autoridade sobre nenhuma a zona DNS.
23/46
A forma mais simples de se fazer essa separacao e congurar os servidores DNS com autoridade em m quinas distintas dos servidores DNS recursivos. Alguns softwares servidores DNS podem ser conguraa dos para permitir que essa separacao seja feita na mesma m quina; um exemplo e a vers o 9 do BIND, que a a implementa isso atrav s de vis es (views). e o
4.5.3
Uso de Privil gios Mnimos e
Os softwares servidores de DNS est o entre os alvos mais visados pelos atacantes, e j foram respons veis a a a por comprometimentos de seguranca no passado. Dessa forma, uma medida recomend vel e minimizar os a privil gios com os quais o software servidor DNS e executado. e Em ambientes Unix, muitas vezes e possvel executar o servidor DNS em uma jaula chroot(). Vers es o mais recentes do BIND permitem tamb m que ele seja executado com permiss es de um usu rio diferente de e o a root. Consulte a documentacao do seu software ou o suporte t cnico do seu fornecedor para ver se uma dessas e opcoes pode ser utilizada.
4.5.4
Cuidado com Informacoes Sensveis no DNS
O DNS oferece alguns tipos de registros de recursos que armazenam informacoes adicionais sobre os nomes de domnio, tais como HINFO, TXT e WKS. Estes registros n o s o necess rios para o funcionamento correto a a a da resolucao de nomes, sendo geralmente usados para facilitar a administracao e a manutencao da rede. Conforme e discutido em maiores detalhes na secao 4.11, informacoes sobre conguracao de sistemas na sua rede devem ser consideradas sensveis, pois podem ser usadas por um atacante para facilitar o compro metimento desses sistemas (ajudando-o a identicar m quinas com sistemas que possuam vulnerabilidades a conhecidas, por exemplo). Em vista disso, o mais prudente e evitar registrar esse tipo de informacao no DNS. Caso voc deseje usar estes tipos de registros para facilitar a administracao da rede, recomenda-se fortemene ` te que essas informacoes n o estejam disponveis para usu rios externos a sua rede. Isso pode ser conseguido a a usando-se servidores DNS inacessveis externamente ou, para o BIND 9, atrav s do uso adequado de vis es. e o Outro fator importante, e que requer a atencao do administrador, consiste no fato de que o DNS pode fornecer um registro que possibilite a obtencao da vers o do servico de DNS sendo executado, o que pode ser a usado para determinar a vulnerabilidade/suscetibilidade do servico a um dado ataque. Por exemplo, o BIND fornece esta informacao atrav s de consultas do tipo version.bind. e Portanto, e aconselh vel que o administrador verique se este tipo de registro pode ser fornecido por seu a servico de DNS e, ent o, congure-o levando em consideracao uma ou mais das seguintes medidas: a 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 especcos, como da m quina do administrador ou do pr prio servidor de DNS (localhost); a o altere o conte do da string enviada como resultado da consulta, para por exemplo uma string vazia (); u gere registros de eventos (logs) para todas as consultas desta natureza.
24/46
4.5.5
DNS Reverso
O uso mais freq ente do DNS e a traducao de nomes em enderecos IP. Entretanto, ele tamb m permite u e descobrir o nome associado a um determinado endereco IP. Isso e chamado DNS reverso, e possibilita a identicacao do domnio de origem de um endereco IP. Um DNS reverso mal congurado ou inexistente pode causar alguns transtornos. O primeiro deles e que 3 Em muitos sites negam o acesso a usu rios com enderecos sem DNS reverso ou com o reverso incorreto. a segundo lugar, erros na conguracao do DNS dep em contra a compet ncia t cnica da equipe de administracao o e e de redes respons vel pelo domnio, e isso pode vir a causar diculdades quando for necess rio interagir com a a equipes de outras redes. E recomend vel que voc mantenha atualizado o DNS reverso dos enderecos sob sua responsabilidade. Em a e ` alguns casos a administracao do DNS reverso dos seus blocos pode ser delegada a sua rede, enquanto em outros o seu provedor de backbone e quem e respons vel pelo DNS reverso dos seus enderecos. Entre em contato com a o seu provedor de backbone para obter informacoes sobre como atualizar o seu DNS reverso.
4.6
Informacoes de Contato
Existem na Internet alguns enderecos eletr nicos (emails) que s o usados para entrar em contato com o a ` administradores quando se deseja comunicar determinadas ocorr ncias relacionadas a seguranca de suas redes e extremamente importante que estas informacoes sejam v lidas e estejam sempre atualizadas, e sistemas. E a pois assim garante-se que estas comunicacoes ser o recebidas pela pessoa certa no menor espaco de tempo a ncias. Esta secao possvel, o que pode muitas vezes impedir um incidente de seguranca ou limitar as conseq e u mostra quais s o essas informacoes e como voc deve proceder para atualiz -las. a e a
4.6.1 Enderecos Eletr nicos Padr o o a e a A RFC 21424 dene uma s rie de emails padr o que devem existir em todas as redes e que podem ser usados para contatar os seus respons veis. Dentre os enderecos padr o, existem dois que est o relacionados a a a com seguranca: abuse e security. O endereco abuse e usado para reportar abusos de recursos na rede. O endereco security, por sua vez, e utilizado para comunicar incidentes e alertar sobre problemas de seguranca. Mensagens enviadas para estes enderecos dever o chegar at os respons veis por lidar com essas ocorr n a e a e cias. N o e necess rio criar usu rios com estes nomes, basta que sejam congurados aliases redirecionando as a a a mensagens enviadas a estes enderecos para os usu rios apropriados. a Cabe observar que muitas vezes estes enderecos n o s o usados da maneira mais apropriada, com abuse a a recebendo reclamacoes de incidentes de seguranca e security relatos de abusos, ou ambos os enderecos sendo usados na mesma noticacao. Sendo assim, e importante que sua rede possua ambos os enderecos e que eles sejam constantemente monitorados pela sua equipe de seguranca.
caso mais comum de incorrecao e quando existe um nome para resolver um dado IP mas este mesmo nome n o est registrado a a em nenhum DNS direto, ou ent o resolve para outro endereco IP. Um exemplo disso seria o endereco IP 192.0.2.34 resolver para a foo.example.org mas este nome resolver para o IP 192.0.2.76. 4 D. Crocker, Mailbox Names for Common Services, Roles and Functions, RFC 2142, Internet Mail Consortium, May 1997. Disponvel em http://www.ietf.org/rfc/rfc2142.txt.
3O
25/46
4.6.2
Contato no DNS
Cada domnio registrado em um servidor DNS possui uma s rie de par metros de conguracao no registro e a de SOA (Start of Authority). Um destes par metros e o email do respons vel pelo domnio, que muitas vezes a a tamb m e usado para comunicar problemas de seguranca envolvendo esse domnio. e Um exemplo de registro SOA para o domnio example.org pode ser visto na gura 2. Nesta gura, ns. example.org e o nome do servidor DNS prim rio e joe.example.org representa o endereco joe@example. a org, que seria o endereco de contato para o domnio example.org.
example.org. IN SOA ns.example.org. joe.example.org. ( 2002030101 ; serial (yyyymmddnn) 10800 ; refresh (3h) 3600 ; retry (1h) 6084800 ; expire (1 semana) 86400 ) ; TTL (1 dia)
Figura 2: Exemplo de registro SOA Mantenha esse endereco 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. N o se esqueca que o formato a e usu rio.domnio, e n o usu rio@domnio. a a a
4.6.3
Contatos no WHOIS
Cada domnio ou bloco de enderecos IP registrado possui uma lista de informacoes de contato que remetem ` as pessoas respons veis por estes domnios ou blocos. Geralmente existem tr s tipos de contatos: a e contato t cnico: respons vel t cnico pela administracao e operacao do domnio ou bloco; e a e contato administrativo: quem tem autoridade sobre o domnio ou bloco; contato de cobranca: quem recebe correspond ncias de cobranca das despesas de registro e manutencao e do domnio ou bloco. Os enderecos de email destes contatos devem estar sempre atualizados e ser v lidos. No caso do contato a t cnico, isso signica dizer que mensagens enviadas para este endereco devem ser recebidas por um adminise trador de redes respons vel pelo bloco ou domnio, e n o por pessoal administrativo ou jurdico da organizacao. a a Este contato e usado com muita freq encia para noticacao de incidentes de seguranca e outros problemas com u a infra-estrutura de rede envolvendo o domnio ou bloco. Estas informacoes de contato s o mantidas em uma base de dados chamada WHOIS. Esta base de dados e a normalmente gerenciada por entidades que registram domnios (informacoes sobre domnios) e por provedores de backbone (informacoes sobre enderecos IP). No Brasil, estas informacoes s o administradas e disponibili a zadas pelo Registro .br (http://registro.br). O procedimento de atualizacao dos contatos no WHOIS varia de acordo com a entidade de registro ou pro vedor de backbone. Entre em contato com a sua entidade de registro ou o seu provedor para obter informacoes detalhadas sobre como efetuar essa atualizacao. Para domnios registrados no Brasil, informacoes sobre como atualizar os contatos est o disponveis em http://registro.br/faq/faq2.html. a
26/46
4.7
Eliminacao de Protocolos sem Criptograa
Uma medida de seguranca muito importante na operacao de redes e a substituicao de protocolos onde n o haja autenticacao atrav s de senhas, ou onde senhas trafeguem em claro, por outros que corrijam estas a e deci ncias. A lista de protocolos cuja utilizacao deve ser evitada na medida do possvel inclui: e Telnet; FTP; POP3; IMAP; rlogin; rsh; rexec. A maioria dos protocolos citados pode ser substituda pelo SSH.5 Essa substituicao, al m de fazer com e que o tr fego entre cliente e servidor passe a ser criptografado, traz ainda outras vantagens, como protecao da a sess o contra ataques tipo man-in-the-middle e seq estro de conex es TCP. a u o Em relacao ao POP3, existem diversas possibilidades de substituicao: 1. Usar uma das variantes do protocolo (APOP, KPOP, RPOP) que tornam a autenticacao de usu rios mais a segura, pois eliminam o tr fego de senhas em claro. As desvantagens desta opcao s o que nem todos a a os clientes de email suportam estas variantes e o conte do dos emails (que pode conter informacoes u sensveis) n o e criptografado. a 2. Usar POP3 atrav s de um t nel SSH ou SSL. A primeira opcao e interessante quando o servidor POP3 e u e o servidor SSH residem na mesma m quina. Para a segunda, podem ser usadas ferramentas como a o stunnel (http://stunnel.mirt.net). Alguns clientes de email j suportam SSL diretamente, n o a a sendo necess rio o uso de t neis. a u 3. Usar uma solucao de Webmail sobre HTTPS (HTTP+SSL). Esta solucao tamb m e v lida para o IMAP. e a
4.8
Cuidados com Redes Reservadas
Existem alguns blocos de enderecos IP que s o reservados pelo IANA (Internet Assigned Numbers Au a thority) para prop sitos especcos. N o existe um documento unico que registre todos estes blocos; alguns o a est o documentados em RFCs, enquanto que outros s o considerados reservados por raz es de compatibilidade a a o hist rica. o a A RFC 33306 lista v rios blocos reservados pelo IANA. Uma lista dessas redes reservadas conhecidas e mostrada na tabela 1, juntamente com um breve coment rio sobre a nalidade de cada rede. a
5 Implementacoes 6 IANA,
de SSH para diversos sistemas operacionais est o disponveis em http://www.openssh.com. a Special-Use IPv4 Addresses, RFC 3330, September 2002. Disponvel em http://www.ietf.org/rfc/rfc3330.txt.
27/46
Rede 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 192.168.0.0/16 169.254.0.0/16 192.88.99.0/24 198.18.0.0/15 224.0.0.0/4 240.0.0.0/5
Coment rio a usada por sistemas antigos para broadcast loopback TEST-NET; usada para exemplos em documentacao usada em redes privadas (RFC 1918) usada em redes privadas (RFC 1918) usada em redes privadas (RFC 1918) usada para autoconguracao (est relacionada ao protocolo DHCP) a usada para 6to4 Relay Anycast (RFC 3068) usada para testes de desempenho de equipamentos de rede (RFC 2544) classe D classe E Tabela 1: Lista de redes reservadas pelo IANA
Outro ponto importante e que nem todo o espaco de enderecamento IPv4 est atualmente alocado. Uma a lista dessas redes n o alocadas, e portanto reservadas para o IANA, e mantida em http://www.iana.org/ a assignments/ipv4-address-space. Esta lista e frequentemente atualizada e e recomend vel que seja cona sultada regularmente. Enderecos n o alocados e pertencentes a blocos reservados n o devem ser propagados atrav s da Internet, a a e sendo recomendada a sua ltragem no permetro da sua rede, tanto para entrada quanto para sada. Caso voc possua redes privadas com IPs reservados, certique-se de que os enderecos utilizados sejam os e 7 (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16). especicados na RFC 1918 Enderecos reservados n o devem estar associados a nomes em servidores DNS p blicos. Se voc utiliz -los a u e a em redes privadas e quiser usar nomes para as m quinas, congure um servidor DNS privado ou utilize tabelas a de hosts (/etc/hosts ou C:\WINDOWS\HOSTS). Caso voc detecte um ataque proveniente de uma das redes da tabela 1 e estes enderecos estiverem sendo e ltrados no permetro, os pacotes correspondentes s podem ter partido de dentro da sua pr pria rede. A causa o o mais freq ente para isso e a exist ncia de erros de conguracao que fazem com que os enderecos reservados u e 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 e a entidade listada nos contatos de WHOIS para estes blocos).
4.9
Polticas de Backup e Restauracao de Sistemas
A import ncia dos backups na administracao de sistemas nunca pode ser minimizada. Sem eles, muitos a dados s o simplesmente irrecuper veis caso sejam perdidos devido a uma falha acidental ou a uma invas o. a a a Os backups devem fazer parte da rotina de operacao dos seus sistemas e seguir uma poltica determinada. O melhor e faz -los da forma mais automatizada possvel, de modo a reduzir o seu impacto sobre o trabalho e dos administradores e operadores de sistemas. A lista de itens cujo backup deve ser feito com freq encia inclui: u dados;
Rekhter et.al., Address Allocation for Private Internets, RFC 1918, February 1996. Disponvel em http://www.ietf.org/ rfc/rfc1918.txt.
7 Y.
28/46
arquivos de conguracao; logs. Um ponto que merece especial cuidado e o backup de bin rios (execut veis e bibliotecas), que geralmente a a deve ser evitado. Uma excecao a essa regra e uma c pia completa do sistema logo ap s a sua instalacao, o o antes que ele seja colocado em rede. Backups que incluem bin rios n o s o aconselh veis porque abrem a a a a a possibilidade de que eventuais Cavalos de Tr ia ou execut veis corrompidos sejam reinstalados na restauracao o a do sistema. Alguns cuidados devem ser tomados em relacao ao local onde s o guardados os backups: a o acesso ao local deve ser restrito, para evitar que pessoas n o autorizadas roubem ou destruam backups; a o local deve ser protegido contra agentes nocivos naturais (poeira, calor, umidade); se possvel, e aconselh vel que o local seja tamb m a prova de fogo. a e ` Os backups devem ser vericados logo ap s a sua geracao e, posteriormente, em intervalos regulares. Isto o possibilita a descoberta de defeitos em dispositivos e meios de armazenamento e pode evitar que dados sejam perdidos por problemas com backups que n o podem ser restaurados. a Algumas organizacoes providenciam meios para armazenar backups fora das suas instalacoes, como em cofres de bancos, por exemplo. Essa e uma boa maneira de garantir a disponibilidade dos backups em caso de problemas nas instalacoes. Entretanto, isso pode comprometer a condencialidade e integridade desses back ups. Uma possvel solucao e criptografar o backup e gerar um checksum (MD5 ou SHA-1, por exemplo) dele antes que seja entregue a pessoas de fora da organizacao. Uma vericacao do checksum antes da restauracao pode servir como prova de que o backup n o foi alterado desde que foi feito. a Quando for necess rio restaurar um sistema, isto deve ser feito com a m quina isolada da rede. Caso o a a sistema em quest o tenha sido comprometido, revise a sua conguracao ap s a restauracao para certicar-se de a o que n o tenha cado nenhuma porta de entrada previamente instalada pelo invasor. a
4.10
Como Manter-se Informado
Administradores envolvidos com a seguranca de redes e sistemas necessitam buscar informacoes de forma ` a se manterem atualizados em relacao a novas vulnerabilidades e correcoes de seguranca. Devido a sua natureza din mica, o principal meio de obtencao de tais informacoes e a pr pria Internet, atrav s de listas de discuss o a o e a por email e sites especializados. Os tipos mais indicados de listas de discuss o para um administrador incluem: a lista de an ncios de seguranca de fornecedores de software e hardware cujos produtos s o usados na sua u a rede; listas de administradores e/ou usu rios desses produtos; a lista de alertas de seguranca do CERT/CC.8
8 Veja
http://www.cert.org/contact_cert/certmaillist.html.
29/46
Destas, as listas de an ncios de seguranca de fornecedores e a lista de alertas do CERT/CC s o fortemente u a recomendadas a qualquer administrador. As listas destinadas a administradores e usu rios de produtos, por a sua vez, podem ajud -lo a conhecer melhor as ferramentas disponveis no seu ambiente computacional, muitas a vezes levando-o a descobrir formas mais ecientes de trabalhar com elas.9 Existem outras listas que s o indicadas para administradores que possuam alguma experi ncia e bons coa e nhecimentos de programacao. Essas listas costumam ter um alto tr fego e o conte do das suas discuss es a u o e bastante t cnico, muitas vezes envolvendo o uso de conceitos avancados. A principal (e tamb m a mais e e conhecida) destas listas e a Bugtraq.10 A Web tamb m oferece boas fontes de informacoes atualizadas na area de seguranca, tais como: e http://www.cert.org/advisories/; http://www.cert.org/current/current_activity.html; http://online.securityfocus.com/; http://www.incidents.org/. IMPORTANTE: e recomend vel que voc tome cuidado com a proced ncia de informacoes relacionadas a e e com seguranca, procurando se restringir a fontes con veis. Existem diversos relatos de informacoes proposi a talmente erradas terem sido divulgadas com o objetivo de abrir brechas na seguranca da rede daqueles que as tenham seguido.
4.11
Precaucoes contra Engenharia Social
e Engenharia social e a t cnica (ou arte) de aproveitar-se da boa f de pessoas para obter informacoes que e possibilitem ou facilitem o acesso aos recursos computacionais de uma organizacao por parte de usu rios n o a a autorizados. Dentre as informacoes procuradas destacam-se as seguintes: senhas de acesso; topologia da rede; enderecos IP em uso; nomes de hosts em uso; listas de usu rios; a tipos e vers es de sistemas operacionais usados; o tipos e vers es de servicos de rede usados; o dados sigilosos sobre produtos e processos da organizacao. Existem diversas formas de se efetuar um ataque de engenharia social, mas todas elas t m em comum a e caracterstica de usarem basicamente psicologia e perspic cia para atingir os seus prop sitos. Atualmente, as a o mais populares s o: a
9A 10 Veja
secao 4.11 mostra alguns cuidados que devem ser tomados por quem utiliza listas de discuss o por email. a http://online.securityfocus.com/.
30/46
usar telefone ou email para se fazer passar por uma pessoa (geralmente algu m da equipe de suporte e t cnico ou um superior da pessoa atacada) que precisa de determinadas informacoes para resolver um e suposto problema; aproveitar informacoes divulgadas em um f rum p blico da Internet (lista de discuss o por email, news o u a group, IRC) por um administrador ou usu rio que busca ajuda para resolver algum problema na rede; a enviar programas maliciosos ou instrucoes especialmente preparadas para um administrador ou usu rio, a com o objetivo de abrir brechas na seguranca da rede ou coletar o m ximo de informacoes possvel sobre a ela (esta t cnica e particularmente ecaz quando a pessoa pede auxlio em algum f rum de discuss o e o a pela Internet); navegar por websites ou reposit rios FTP em busca de informacoes uteismuitas vezes e possvel eno contrar descricoes detalhadas da infra-estrutura computacional e/ou documentos que, por descuido ou esquecimento, n o foram removidos do servidor. a A principal maneira de se prevenir contra estes ataques e orientando os usu rios (secao 4.1) e administraa dores de redes e sistemas sobre como agir nestas situacoes. A poltica de seguranca da organizacao (secao 2.1) desempenha um papel importante neste sentido, pois e nela que s o denidas as normas para protecao da a informacao na organizacao. Recomenda-se fortemente que os administradores tenham cuidado ao buscar ajuda em listas de discuss o e a outros f runs na Internet. Estes recursos podem ser valiosos na resolucao de problemas, mas tamb m podem o e ser usados por terceiros para coleta de informacoes. Procure reduzir a exposicao da sua rede em f runs p blicospor exemplo, use enderecos IP, nomes de o u hosts e usu rios hipot ticos, e tente n o revelar mais sobre a topologia da rede do que o estritamente necess rio a e a a para resolver um dado problema. Tome cuidado com orientacoes passadas por pessoas desconhecidas, e evite executar programas de origem obscura ou n o con veleles podem ser uma armadilha. a a
31/46
4.12 Uso Ecaz de Firewalls

Antes de apresentar t cnicas para aumentar a ec cia de rewalls, e importante denir o que um rewall e a e e o que ele n o e. Um rewall bem congurado e um instrumento importante para implantar a poltica a de seguranca da sua rede. Ele pode reduzir a informacao disponvel externamente sobre a sua rede, ou, em alguns casos, at mesmo barrar ataques a vulnerabilidades ainda n o divulgadas publicamente (e para as quais e a correcoes n o est o disponveis). a a Por outro lado, rewalls n o s o infalveis. A simples instalacao de um rewall n o garante que sua a a a rede esteja segura contra invasores. Um rewall n o pode ser a sua unica linha de defesa; ele e mais um a dentre os diversos mecanismos e procedimentos que aumentam a seguranca de uma rede. Outra limitacao dos rewalls e que eles protegem apenas contra ataques externos ao rewall, nada podendo fazer contra ataques que partem de dentro da rede por ele protegida. Esta secao apresenta apenas alguns aspectos importantes da utilizacao de rewalls. Maiores informacoes e e podem ser obtidas em http://www.interhack.net/pubs/fwfaq/ e nas refer ncias do ap ndice A.
4.12.1 A Escolha de um Firewall Existem diversas solucoes de rewall disponveis no mercado. A escolha de uma delas est atrelada a fatores a como custo, recursos desejados e exibilidade, mas um ponto essencial e a familiaridade com a plataforma operacional do rewall. A maioria dos rewalls est disponvel para um conjunto reduzido de plataformas a 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 experi ncia. Por exemplo, se voc utiliza basicamente servidores Unix, e e e aconselh vel que voc escolha um rewall que rode sobre a sua variante favorita de Unix, e n o um produto a e a que requeira Windows NT. Existem, basicamente, duas raz es para esta recomendacao. A primeira delas e que voc deve estar fao e miliarizado o suciente com o sistema onde o rewall ser executado para congur -lo de forma segura. A a a exist ncia de um rewall instalado em um sistema inseguro pode ser at mais perigosa do que a aus ncia do e e e rewall na rede. A segunda raz o e que os produtos tendem a seguir a losoa da plataforma onde rodam; por a exemplo, a maioria dos rewalls para Windows e congurada atrav s de menus e janelas, ao passo que muitos e rewalls para Unix s o congurados por meio de arquivos texto. a Outro fator importante consiste na escolha do tipo de rewall que ser implementado. Dentre os tipos atuala mente disponveis, destacam-se os ltros 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 integr veis ou fazerem parte do kernel de diversos sistemas operacionais. a Os ltros de pacotes normalmente analisam informacoes colhidas nos cabecalhos de cada pacote, tais como enderecos IP de origem e destino, protocolo utilizado, portas, e s o basicamente divididos em duas categorias: a os est ticos (stateless) e os din micos (stateful). a a Os ltros est ticos s o projetados para tomar decis es (como bloquear ou permitir) para cada pacote que a a o entra ou sai de uma rede, sem considerar o contexto em que cada pacote est inserido. Portanto, neste caso e a preciso estabelecer regras, de forma explcita, tanto para o tr fego que entra na rede quanto para o tr fego que a a sai (incluindo o tr fego de resposta a conex es iniciadas externamente). a o J os ltros din micos rastreiam e mant m o estado das conex es contidas no tr fego de rede, fazendo com a a e o a que cada pacote seja analisado dentro de um contexto (conex o que cont m o pacote). Este tipo de ltro de a e
32/46
pacotes normalmente apresenta um melhor desempenho e permite que os dois sentidos de tr fego (entrada e a sada) sejam considerados/tratados separadamente, uma vez que o tr fego de resposta e gerenciado automati a camente, simplicando assim o conjunto de regras a ser mantido e muitas vezes aumentando a qualidade da ltragem. Administradores experientes em Unix t m a disposicao diversas ferramentas de software livre que podem e ` ser usadas para implementar rewalls, conforme mostra a tabela 2. Estas ferramentas permitem construir rewalls ecientes a um custo relativamente baixo, uma vez que seus requisitos de hardware s o modestos. a Ferramenta
ipchains iptables ipfw pf iplter TIS Firewall Toolkit Squid
Plataforma Linux Linux FreeBSD OpenBSD v rios Unix a v rios Unix a v rios Unix a
Caracterstica ltro de pacotes (stateless) ltro de pacotes (stateful) ltro de pacotes (stateful) ltro de pacotes (stateful) ltro de pacotes (stateful) proxy para v rios protocolos a proxy Web/FTP
Tabela 2: Ferramentas de software livre para a construcao de rewalls
4.12.2
Localizacao dos Firewalls
A localizacao dos rewalls na rede depende normalmente da sua poltica de seguranca. Entretanto, existem ` algumas regras que se aplicam a grande maioria dos casos: Todo o tr fego deve passar pelo rewall. Um rewall s pode atuar sobre o tr fego que passa por ele. a o a A ec cia de um rewall pode ser severamente comprometida se existirem rotas alternativas para dentro a da rede (modems, por exemplo). Caso n o seja possvel eliminar todas esses caminhos, eles devem ser a documentados e fortemente vigiados atrav s de outros mecanismos de seguranca. e Tenha um ltro de pacotes no permetro da sua rede. Esse ltro pode estar localizado entre o seu roteador de borda e o interior da rede ou no pr prio roteador, se ele tiver esta capacidade e voc se sentir o e confort vel utilizando-o para esta tarefa. O ltro de pacotes de borda e importante para tarefas como a bloqueio global de alguns tipos de tr fego (vide secao 4.12.3) e bloqueio r pido de servicos durante a a a implantacao de correcoes ap s a descoberta de uma nova vulnerabilidade. o Coloque os servidores externos em uma DMZ. E recomend vel que voc coloque os seus servidores a e acessveis externamente (Web, FTP, correio eletr nico, etc.) em um segmento de rede separado e com o acesso altamente restrito, conhecido como DMZ (DeMilitarized Zone, ou zona desmilitarizada). A prin cipal import ncia disso e proteger a rede interna contra ataques provenientes dos servidores externos a uma precaucao 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 informacoes condenciais) e muito maior do que se ele estiver em uma rede isolada. Considere o uso de rewalls internos. Em alguns casos, e possvel identicar na rede interna grupos de sistemas que desempenham determinadas tarefas comuns, tais como desenvolvimento de software, webdesign e administracao nanceira. Nestes casos, recomenda-se o uso de rewalls internos para isolar estas sub-redes umas das outras, com o prop sito de aumentar a protecao dos sistemas internos e conter o a propagacao de ataques bem-sucedidos.
33/46
4.12.3
Crit rios de Filtragem e
Existem basicamente dois crit rios de ltragem que podem ser empregados em rewalls. O primeiro e o e de default deny, ou seja, todo o tr fego que n o for explicitamente permitido e bloqueado. O segundo, default a a allow, e o contr rio, ou seja, todo o tr fego que n o for explicitamente proibido e liberado. a a a A conguracao dos rewalls deve seguir a poltica de seguranca da rede. Se a poltica permitir, e reco mend vel adotar uma postura de default deny. Esta abordagem e, geralmente, mais segura, pois requer uma a intervencao explcita do administrador para liberar o tr fego desejado, o que minimiza o impacto de eventuais a erros de conguracao na seguranca da rede. Al m disso, ela tende a simplicar a conguracao dos rewalls. e No permetro da rede, pelo menos as seguintes categorias de tr fego devem ser ltradas: a tr fego de entrada (ingress ltering): pacotes com endereco de origem pertencente a uma rede reservada a (secao 4.8) ou a um dos blocos de enderecos da sua rede interna; tr fego de sada (egress ltering): pacotes com endereco de origem pertencente a uma rede reservada ou a que n o faca parte de um dos blocos de enderecos da rede interna. a Um aspecto que deve ser considerado com cuidado e a ltragem 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 informacoes sobre a rede e seus sistemas. Observe que muitos rewalls do tipo stateful permitem a passagem de mensagens ICMP de erro associadas a conex es estabelecidas, o que minimiza o o impacto da ltragem. O tr fego para a DMZ deve ser altamente controlado. As unicas conex es permitidas para os sistemas a o dentro da DMZ devem ser as relativas aos servicos p blicos (acessveis externamente). Conex es partindo u o da DMZ para a rede interna devem ser, na sua maioria, tratadas como conex es oriundas da rede externa, o aplicando-se a poltica de ltragem correspondente.
IMPORTANTE: a DMZ e a rede interna n o podem estar no mesmo segmento de rede (ligadas ao mesmo a
hub ou switch, por exemplo). E imprescindvel que estas redes estejam em segmentos de rede separados.
4.12.4
Exemplos
Diversas arquiteturas podem ser empregadas para a implantacao de rewalls em uma rede. A opcao por uma delas obedece a uma s rie de fatores, incluindo a estrutura l gica da rede a ser protegida, custo, funcionalidades e o pretendidas e requisitos tecnol gicos dos rewalls. o Esta secao apresenta duas destas arquiteturas. A intencao n o e cobrir todas as possibilidades de uso de a rewalls, mas fornecer exemplos de arquiteturas que funcionam e que podem eventualmente ser adotados (na sua forma original ou ap s passarem por adaptacoes) em situacoes reais. o A gura 3 mostra um exemplo simples de uso de rewall. Neste exemplo, o rewall possui tr s interfaces de e rede: uma para a rede externa, uma para a rede interna e outra para a DMZ. Por default, este rewall bloqueia tudo o que n o for explicitamente permitido (default deny). Al m disso, o rewall usado e do tipo stateful, a e que gera dinamicamente regras que permitam a entrada de respostas das conex es iniciadas na rede interna; o portanto, n o e preciso incluir na conguracao do rewall regras de entrada para estas respostas. a O tr fego liberado no exemplo da gura 3 e o seguinte: a
34/46
Internet
WWW
DMZ FW DNS
SMTP
Rede Interna
Figura 3: Um exemplo simples de rewall interface externa: sada: tudo com excecao de pacotes com enderecos de origem pertencentes a redes reservadas; pacotes com enderecos de origem n o pertencentes aos blocos da rede interna. a ` entrada: apenas os pacotes que obedecem as seguintes combinacoes de protocolo, endereco 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: sada: tudo; entrada: nada; interface da DMZ: sada: portas 25/TCP (SMTP), 53/UDP e 53/TCP (DNS) e 113 (IDENT); entrada: al m das mesmas regras de entrada da interface externa, tamb m e permitido o tr fego para e e a todos os servidores na com porta de destino 22/TCP (SSH) e endereco de origem na rede interna. A gura 4 ilustra o uso de rewalls em uma situacao mais complexa do que a anterior. Neste segundo exemplo, al m dos servidores externos na DMZ, h tamb m servidores na intranet e no setor nanceiro da e a e ` organizacao. Devido a import ncia das informacoes mantidas neste setor, a sua rede conta com a protecao a ` adicional de um rewall interno, cujo objetivo principal e evitar que usu rios com acesso a rede interna da a
35/46
Internet
WWW
DMZ FW DNS
Setor Financeiro SMTP WWW FW Intranet DNS
SMTP
Rede Interna
Figura 4: Um exemplo mais complexo de rewall organizacao (mas n o a rede do setor nanceiro) possam comprometer a integridade e/ou o sigilo dessas a ` informacoes. A conguracao do rewall externo neste segundo exemplo e quase id ntica ao primeiro. Entretanto, no e presente caso sup e-se que o servidor SMTP visvel externamente (o da DMZ) repassa as mensagens recebidas o para o servidor SMTP da intranet. Para que isso seja possvel, e necess rio mudar a regra de ltragem para a a interface interna, liberando o tr fego do servidor SMTP da DMZ para a porta 25/TCP do servidor SMTP da a intranet. A conguracao do rewall interno, por sua vez, e bastante simples. O servidor da rede do setor nanceiro permite apenas acesso via HTTPS para que os funcion rios da organizacao possam consultar seus contrachea ques; outros tipos de acesso n o s o permitidos. O tr fego liberado por este rewall e o seguinte: a a a interface externa (rede interna): sada: tudo; entrada: apenas pacotes para o servidor do setor nanceiro com porta de destino 443/TCP (HTTPS) e endereco de origem na rede interna; interface interna (rede do setor nanceiro): sada: tudo; entrada: tudo (a ltragem e feita na interface externa).
36/46
4.13 Redes Wireless

Redes wireless, tamb m conhecidas como IEEE 802.11, Wi-Fi ou WLANs, tornaram-se muito populares e nos ultimos tempos. Embora sejam muito convenientes, sua instalacao e operacao requerem atencao do ponto de vista de seguranca. Essa secao mostra alguns cuidados que devem ser tomados pelos administradores na instalacao e operacao segura destas redes.
4.13.1
Poltica de Uso da Rede Wireless
E muito importante que seja denida uma poltica de uso da rede wireless, que deve ser incorporada na poltica de seguranca da instituicao, discutida na secao 2. Esta poltica deve cobrir pelo menos os seguintes itens: denir quem est autorizado a instalar Access Points (APs) nas depend ncias da instituicao. A instalacao a e de APs por pessoal n o autorizado, sem as precaucoes listadas nas secoes 4.13.2 e 4.13.4, pode comproa meter seriamente a seguranca de toda rede; denir quem est autorizado a utilizar a rede wireless da instituicao; a prever as acoes a serem tomadas em caso de roubo ou perda de equipamentos wireless; denir que tipo de informacao pode transitar pela rede; descrever as conguracoes mnimas de seguranca para APs, clientes, etc.
4.13.2
Topologia
Dois fatores muito importantes devem ser considerados ao denir a topologia de uma rede wireless: o posicionamento do AP e a necessidade de isolar esta rede da rede interna da instituicao. Com relacao ao posicionamento do AP, dependendo da pot ncia de sua antena, uma rede wireless pode e ter um alcance que ultrapasse os limites geogr cos da instituicao, o que pode facilitar o uso e a escuta n o a a autorizadas. Esse vazamento de sinal e extremamente comum e deve servir de estmulo para o administrador implementar medidas como o uso de autenticacao e criptograa, discutidas na secao 4.13.3. Al m do uso de criptograa, um posicionamento cuidadoso dos APs (mais para o centro de um pr dio, longe e e importante notar que esse procedimento de janelas, etc.) pode minimizar o vazamento desnecess rio de sinal. E a deve ser encarado apenas como uma camada adicional de seguranca, uma vez que um atacante interessado em ` sua instituicao pode fazer uso de uma antena amplicadora de sinal e ter acesso a sua rede wireless mesmo a dist ncias maiores. a Com relacao ao isolamento da rede wireless da rede interna da instituicao deve-se ter em mente que as redes wireless jamais devem ser conectadas diretamente dentro de uma rede protegida por um rewall (devem ser consideradas untrusted). Colocar um AP diretamente em uma rede protegida por um rewall seria equivalente ` a instalacao de um modem dentro dessa rede, por exemplo.
37/46
Uma solucao de topologia pode ser colocar todos os APs em um segmento de rede pr prio e colocar um o rewall entre esse segmento e o resto da infra-estrutura de rede da instituicao. Al m de possibilitar o controle e de utilizacao, ainda prov uma boa possibilidade de integracao com VPNs. e Por m, e prefervel conectar um AP a um switch, n o a um hub. O tr fego de rede em um hub pode ser a a potencialmente enviado para toda a rede wireless e eventualmente ser interceptado por algum cliente. 4.13.3 Criptograa e Autenticacao
` ` Devido a facilidade com que uma rede wireless pode ser utilizada por pessoas n o autorizadas e a facilidade a com que se pode capturar o tr fego, e extremamente importante o uso de criptograa e de mecanismos de a autenticacao numa rede wireless. O padr o 802.11 originalmente suporta apenas dois tipos de autenticacao do cliente wireless: open authena tication e shared-key authentication. No primeiro modo o cliente precisa apenas fornecer o SSID (Service ` Set Identier) correto para juntar-se a rede. No modo shared-key authentication e preciso o conhecimento de uma chave WEP (Wired Equivalent Privacy) para que isso ocorra. E importante notar que essa autenticacao e do dispositivo wireless, e n o dos usu rios da rede. a a O padr o 802.11 dene o protocolo WEP como mecanismo para cifrar o tr fego entre os APs e os clientes a a wireless. Essa cifragem ocorre na camada de enlace e exige que todos os participantes compartilhem a mesma chave WEP est tica. O WEP possui diversas fragilidades, mas apesar disso seu uso e recomend vel e deve ser a a encarado como uma camada adicional de seguranca. Para aumentar a seguranca de sua rede wireless deve-se escolher o maior tamanho de chave WEP possvel, sendo essencial trocar as chaves WEP que venham nas conguracoes padr o dos equipamentos. O uso de a criptograa nas aplicacoes, como SSH e SSL, tamb m e recomend vel para minimizar os riscos de escuta n o e a a autorizada. Al m disso tamb m deve ser considerado o uso de criptograa no pr prio TCP/IP, como IPsec e o e e o uso de VPNs em geral. Salvo algumas extens es implementadas por alguns fabricantes, o protocolo 802.11 original apresenta alo guns problemas: fragilidade do protocolo WEP; problemas de gerenciamento das chaves WEP, que devem ser trocadas manualmente; falta de autenticacao dos usu rios da rede. a Existem v rias iniciativas para a criacao de novos padr es que aperfeicoem a seguranca do protocolo, sendo a o recomend vel que sejam utilizados assim que estiverem disponveis. Entre eles, pode-se citar: a IEEE 802.1x, que suporta autenticacao e distribuicao de chaves atrav s da consulta a um servidor de e autenticacao; WAP (Wi-Fi Protected Access), desenvolvido em conjunto pela Wi-Fi Alliance e IEEE, que prov algumas e melhorias criptogr cas, como o uso do protocolo TKIP (Temporal Key Integrity Protocol). Tamb m a e prov suporte para autenticacao de usu rios via 802.1x e EAP (Extensible Authentication Protocol); e a IEEE 802.11i, sendo desenvolvido pelo IEEE 802.11 Task Group i (TGi), que inclui uma nova vers o a de WEP utilizando AES (Advanced Encryption Standard), al m da denicao de um framework de e distribuicao de chaves.
38/46
4.13.4 Access Points Existem v rias quest es importantes que devem ser consideradas na escolha e conguracao de um AP: a o Consideracoes na escolha: na escolha de um modelo de AP e muito importante determinar quais recursos de criptograa e autenticacao s o suportados, conforme discutido na secao 4.13.3. Outro fator importan a te e saber se o AP possibilita upgrades de rmware, permitindo incorporar novos padr es e eventuais o correcoes lancadas pelo fabricante. Alteracao de conguracoes padr o: muitos modelos de APs v m com conguracoes de f brica que s o de a e a a conhecimento p blico, incluindo senhas default. E extremamente importante que todas as conguracoes u originais sejam mudadas pelo administrador antes de colocar o AP em producao, incluindo: senhas de administracao11 ; SSID; chaves WEP; SNMP communities.
IMPORTANTE: alguns APs possuem uma opcao de reset fsico que faz com que todas as conguracoes
de f brica sejam recarregadas. Nesses casos, e muito importante que o AP que em um local com acesso a fsico controlado. Modos de conguracao: a maioria dos APs permite v rios12 meios de conguracao: HTTP, SNMP, Telnet, a etc. Sempre que possvel, e importante desabilitar os que n o forem necess rios e optar por um modo de a a conguracao que n o seja pela pr pria rede wireless, mas sim pela rede cabeada ou ainda via conex o a o a serial. Isso minimiza as chances de que a sess o de conguracao com o AP seja capturada por algum a cliente wireless. Broadcast de SSID: uma recomendacao util e desabilitar o broadcast de SSID pelo AP. Embora seja uma medida simples, pode dicultar o uso de alguns programas populares de mapeamento de redes wireless. Filtragem por endereco MAC: alguns APs possuem o recurso de ltragem de clientes wireless por endereco MAC. Embora enderecos MAC possam ser forjados e muitas vezes n o seja pr tico manter uma lista a a de enderecos MAC dos clientes autorizados (e em alguns casos invi vel, como em confer ncias), o a e administrador pode considerar o uso desse recurso como uma camada adicional de seguranca do seu ambiente wireless. ` Uma ultima consideracao diz respeito a possibilidade de desligar o AP quando n o estiver sendo utilizado, a conforme especicado na sua poltica de uso.
4.13.5
Protecao aos Clientes Wireless
Como descrito na secao 4.1, a educacao dos usu rios e importante e eles tamb m devem receber orientacao a e sobre a utilizacao segura de redes wireless. Uma rede wireless deve ser considerada uma rede p blica e, portanto, mais suscetvel a ataques. Desse u modo, e recomend vel que os clientes dessa rede, tais como notebooks, PDAs, estacoes de trabalho, etc, passem a por um processo de instalacao e conguracao que vise o aumento de sua seguranca, incluindo:
11 dicas 12 inclusive
para a escolha de boas senhas podem ser obtidas na secao 3.4. alguns modos, como e o caso de TFTP, habilitados por alguns fabricantes sem serem documentados.
39/46
aplicacao de patches; uso de rewall pessoal; instalacao e atualizacao de antivrus; desligamento do compartilhamento de disco, impressora, etc.
4.13.6
Monitoracao da Rede Wireless
Da mesma forma que muitos administradores monitoram o seu ambiente de rede convencional (com o uso de IDSs, por exemplo), a monitoracao da rede wireless tamb m e importante. Essa monitoracao pode detectar: e clientes conectados em um dado instante (em hor rios improv veis ou simplesmente para acompanhaa a mento); instalacao de APs n o autorizados; a dispositivos que n o estejam usando WEP; a ataques contra os clientes wireless; acessos n o autorizados; a mudancas de enderecos MAC; mudancas de canal; DoS ou jamming.
40/46
A
A.1
Refer ncias Adicionais e

URLs de Interesse
A Case-Study in Best Practice for Operating System Management. http://www.sage-ie.org/slides/case_study/. P gina que cont m um estudo de caso sobre boas pr ticas no gerenciamento de sistemas opea e a racionais. Apresenta, de forma exemplicada, uma metodologia adotada para a instalacao, conguracao e administracao de sistemas operacionais em um grande ambiente de rede. Cartilha de Seguranca para Internet. http://www.nbso.nic.br/docs/cartilha/. P gina a partir da qual pode ser obtida a vers o mais recente do documento Cartilha de a a Seguranca para Internet, do gloss rio e checklist que o acompanham. Este documento tem a por nalidade sanar algumas d vidas comuns sobre seguranca de computadores e redes, e e u dirigido aos usu rios de redes e Internet. Recomenda-se que administradores de redes utilizem a os documentos que comp em a Cartilha no processo de educacao dos seus usu rios. o a CERT Security Improvement Modules: Security Knowledge in Practice. http://www.cert.org/ security-improvement/skip.html. Apresenta, de forma gr ca, os passos que est o envolvidos na obtencao de uma rede mais a a segura. Cont m uma grande quantidade de material que aborda de forma mais aprofundada e v rios dos assuntos discutidos neste documento. a 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 cont m informacoes detalhadas sobre seguranca em redes wireless, e incluindo um estudo de caso e um checklist no nal do documento. Pr ticas de Seguranca para Administradores de Redes Internet. http://www.nbso.nic.br/docs/ a seg-adm-redes/. P gina a partir da qual pode ser obtida a vers o mais recente deste documento e do checklist a a que o acompanha. Cont m tamb m um hist rico de revis es dos documentos. e e o o Security Links. http://www.nbso.nic.br/links/. Uma compilacao de URLs sobre diversos aspectos de administracao e seguranca de redes e sistemas, incluindo diversos apresentados neste documento, e que e atualizada periodicamente.
41/46
A.2
Livros
802.11 Wireless Networks: The Denitive Guide. Matthew Gast. OReilly, 2002. http://www.oreilly.com/catalog/802dot11/ Este livro e uma otima refer ncia sobre redes 802.11, embora n o seja focado exclusivamente e a em seguranca. Cobre as diferentes vers es do protocolo, suas peculiaridades, fatores que de o vem ser considerados ao denir a topologia da rede e quest es relacionadas com a monitoracao o e o uso seguro destas redes. Building Internet Firewalls, 2nd Edition. Elizabeth D. Zwicky, Simon Cooper e D. Brent Chapman. OReilly & Associates, 2000. http://www.oreilly.com/catalog/fire2/ Um dos melhores livros disponveis sobre rewalls, com muitas informacoes pr ticas sobre a 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 te ricos relacionados com seguranca. o Cont m captulos que discutem polticas de seguranca, uso de criptograa e implementacao e de sistemas de forma segura. De maior interesse para administradores de redes e a sess o a Practicum, onde e discutida a aplicacao de diversos conceitos de seguranca em situacoes reais. DNS and BIND, 4th Edition. Paul Albitz e Cricket Liu. OReilly & Associates, 2001. http://www.oreilly.com/catalog/dns4/ Este livro possui bastante informacao sobre o protocolo DNS e a sua principal implementacao, o BIND. A quarta edicao cont m um captulo sobre seguranca de servidores DNS. e 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 refer ncia sobre seguranca em Internet. Al m de apresentar uma grande secao sobre e e o estudo de Firewalls e VPNs, tamb m disp e de secoes que envolvem outros temas, como e o ferramentas e t cnicas utilizadas em ataques e na defesa de redes e sistemas de informacao, e an lise de problemas e pr ticas de seguranca em intranets, e implantacao de hosts forticados a a e de sistemas de deteccao de intrus o (IDSs). O livro possui diversos exemplos pr ticos, que a a reetem a experi ncia de seus autores. e Practical Unix and Internet Security, 3rd Edition. Simson Garnkel, Gene Spafford e Alan Schwartz. OReilly & Associates, 2003. http://www.oreilly.com/catalog/puis3/ Este livro e considerado refer ncia obrigat ria em seguranca de sistemas Unix. Esta nova e o edicao aborda as variantes de Unix mais populares e cobre quest es atuais relacionadas a o redes e seguranca de sistemas. O livro cont m informacoes sobre autenticacao, sistema de e arquivos, criptograa, wireless, rewalls, deteccao de intrus o, an lise forense, entre outras. a a
42/46
TCP/IP Illustrated, Volume 1: The Protocols. W. Richard Stevens. Addison-Wesley, 1994. A melhor obra disponvel sobre TCP/IP. O texto e claro e did tico, e numerosos exemplos a (usando tcpdump) ajudam a compreender o funcionamento dos protocolos na pr tica. a Unix System Administration Handbook, 3rd Edition. Evi Nemeth, Garth Snyder, Scott Seebass e Trent R. Hein. Prentice Hall, 2001. O cl ssico sobre administracao de sistemas Unix, recentemente atualizado. Traz explicacoes a claras e objetivas sobre como realizar, de forma eciente, as diferentes tarefas que competem a um administrador de sistemas Unix. Seguranca Nacional. Nelson Murilo de O. Runo. Novatec, 2001. http://www.segurancanacional.com.br/ Uma boa refer ncia sobre seguranca computacional em portugu s, com enfoque em aspectos e e pr ticos. a S rie OReilly sobre administracao de servicos de rede e sistemas operacionais especcos. e http://www.oreilly.com/ A editora OReilly e conhecida pela qualidade t cnica dos seus livros, que geralmente abore dam um assunto especco com bastante profundidade e com um enfoque bem pr tico. Exis a tem guias para servidores como Apache (Web) e Sendmail (SMTP), al m de diversos ttulos e sobre uso e administracao de sistemas operacionais (incluindo Unix, Linux e Windows). Windows 2000 Security. Roberta Bragg. New Riders Publishing, 2000. Este livro discute seguranca no Windows 2000, dando maior enfase aos aspectos pr ticos. Os a 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 seguranca de Windows NT, incluindo instalacao, conguracao, 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 seguranca. Cont m v rios e a exemplos extrados de polticas reais, que podem ser usados como guia para a formulacao de novas polticas.
43/46
Indice Remissivo
802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36, 40, 41 802.11i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 802.1x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 A abuso de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 conseq encias. . . . . . . . . . . . . . . . . . . . . . . . . . .15 u implicacoes legais . . . . . . . . . . . . . . . . . . . . . . . 15 administradores equipe . . . . . . . veja equipes de administradores Administrator . . . . . . . . . . . veja contas privilegiadas Alan Schwartz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 an lise de riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 a AUP . . . . . . . . . . . . . . . veja poltica de uso aceit vel a Aviel D. Rubin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 B backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2728 armazenamento . . . . . . . . . . . . . . . . . . . . . . . . . 28 bin rios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 a checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 itens importantes . . . . . . . . . . . . . . . . . . . . . . . . 27 logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 off-site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 particoes individuais . . . . . . . . . . . . . . . . . . . . . 10 polticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 restauracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 vericacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . veja DNS bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 C Cartilha de Seguranca para Internet . . . . . . . . . . . . 17 Charles B. Rutstein . . . . . . . . . . . . . . . . . . . . . . . . . . 42 conguracao controle de alteracoes . . . . . . . . . . . . . . . . . . . . 18 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2125 documentacao. . . . . . . . . . . . . . . . . . . . . . . . . . .11 proxy Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 revis o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 a servidores SMTP . . . . . . . . . . . . . . . . . . . . 15, 24 conta Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . 19 conta root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 contas privilegiadas . . . . . . . . . . . . . . . . . . . . . . . . . . 19 contatos . . . . . . . . . . . . . veja informacoes de contato correcoes de seguranca . . . . . . . . . . . . . . . . . . . . . . . 15 periodicidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 precaucoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 reposit rio local . . . . . . . . . . . . . . . . . . . . . . . . . 15 o Cricket Liu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 D D. Brent Chapman . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 di rio de bordo . . . . . . . . . . . . . . . . . . . . veja logbook a DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2124 cache poisoning . . . . . . . . . . . . . . . . . . . . . . . . . 22 contato no SOA . . . . . . . . . . . . . . . . . . . . . . . . . 25 exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 envenenamento de cache . . . . . . . . . . . . . . . . . 22 ltragem de tr fego . . . . . . . . . . . . . . . . . . . . . . 22 a HINFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 informacoes sensveis . . . . . . . . . . . . . . . . . . . . 23 jaula chroot() . . . . . . . . . . . . . . . . . . . . . . . . . 23 problemas de conguracao . . . . . . . . . . . . . . . 24 reverso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 atualizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 servidor com autoridade . . . . . . . . . . . . . . . . . . 22 servidor com privil gios mnimos . . . . . . . . . 23 e servidor privado . . . . . . . . . . . . . . . . . . . . . . . . . 27 servidor recursivo . . . . . . . . . . . . . . . . . . . . . . . 22 transfer ncia de zona . . . . . . . . . . . . . . . . . . . . 22 e TXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 vers o do servico . . . . . . . . . . . . . . . . . . . . . . . . 23 a version.bind . . . . . . . . . . . . . . . . . . . . . . . . . . 23 WKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 E educacao dos usu rios . . . . . . . . . . . . . . . . . . . . . . . 17 a egress ltering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Elizabeth D. Zwicky . . . . . . . . . . . . . . . . . . . . . . . . . 41 enderecos reservados . . . . . . . veja redes reservadas endereco reverso . . . . . . . . . . . . . . . . . . . . . . veja DNS enderecos eletr nicos padr o . veja informacoes de o a contato engenharia social . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 formas de ataque . . . . . . . . . . . . . . . . . . . . . . . . 29 prevencao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 equipes de administradores . . . . . . . . . . . . . . . . . . . 18 comunicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 contas privilegiadas . . . . . . . . . . . . . . . . . . . . . . 19
44/46
listas de discuss o . . . . . . . . . . . . . . . . . . . . . . . 18 a vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Evi Nemeth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 F ferramentas BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . veja DNS CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 rewalls de software livre . . . . . . . . . . . . . . . . 31 OpenSSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 RCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 stunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 sudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 swatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 rewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3135 crit rios de escolha . . . . . . . . . . . . . . . . . . . . . . 31 e crit rios de ltragem . . . . . . . . . . . . . . . . . . . . . 33 e default allow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 default deny . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32, 33 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 egress ltering . . . . . . . . . . . . . . . . . . . . . . . . . . 33 exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3335 ferramentas de software livre . . . . . . . . . . . . . 31 ltragem de permetro . . . . . . . . . . . . . . . . . . . 32 ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 ingress ltering . . . . . . . . . . . . . . . . . . . . . . . . . 33 internos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32, 34 limitacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 localizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 servicos n o utilizados . . . . . . . . . . . . . . . . . . . 14 a stateful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 stateless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 zona desmilitarizada . . . . . . . . . . . . . . . . . . . . . 32 xes . . . . . . . . . . . . . . . . . veja correcoes de seguranca FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 fuso hor rio . . . . . . . . . . . . . . . . . . . . . . . veja timezone a G Garth Snyder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Gene Spafford . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 gerenciamento de sistemas operacionais . . . . . . . 40 H hor rio de ver o . . . . . . . . . . . . . . . . . . . veja timezone a a I IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 ICMP ltragem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 informacoes de contato . . . . . . . . . . . . . . . . . . . . . . . 24 aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 endereco abuse . . . . . . . . . . . . . . . . . . . . . . . . . 24 endereco security . . . . . . . . . . . . . . . . . . . . . . 24 monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . 24 RFC 2142 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 SOA do DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 WHOIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 atualizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 tipos de contato . . . . . . . . . . . . . . . . . . . . . . . 25 ingress ltering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 instalacao de correcoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 de pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 desativacao de servicos . . . . . . . . . . . . . . . . . . 14 documentacao. . . . . . . . . . . . . . . . . . . . . . . . . . .11 mnima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 personalizada . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 preparacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 IPs reservados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 L listas de discuss o a alertas de seguranca . . . . . . . . . . . . . . . . . . . . . 28 Bugtraq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 cuidados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29, 30 internas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 para manter-se informado . . . . . . . . . . . . . . . . 28 logbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1113 cuidados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 formato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 informacoes essenciais . . . . . . . . . . . . . . . . . . . 11 uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14, 15, 18 logs armazenamento off-line . . . . . . . . . . . . . . . . . . 20 armazenamento on-line . . . . . . . . . . . . . . . . . . 20 riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 geracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 import ncia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 a integridade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 loghosts centralizados . . . . . . . . . . . . . . . . . . . . 20
45/46
monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . 20 eventos anormais . . . . . . . . . . . . . . . . . . . . . . 21 timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 perodo de armazenamento . . . . . . . . . . . . . . . 20 reducao de volume . . . . . . . . . . . . . . . . . . . . . . 21 rel gio sincronizado . . . . . . . . . . . . . . . . . . . . . 19 o rotacao autom tica . . . . . . . . . . . . . . . . . . . . . . 20 a M Matt Bishop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 N Nelson Murilo de O. Runo . . . . . . . . . . . . . . . . . . 42 NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 ajuste mais preciso . . . . . . . . . . . . . . . . . . . . . . 17 reducao de tr fego . . . . . . . . . . . . . . . . . . . . . . . 17 a servidor local . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 P particionamento de disco . . . . . . . . . . . . . . . . . . . . . . 9 vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 patches . . . . . . . . . . . . . . veja correcoes de seguranca Paul Albitz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 poltica an lise de riscos . . . . . . . . . . . . . . . . . . . . . . . . . . 6 a de backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 de seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 de senhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 de uso aceit vel . . . . . . . . . . . . . . . . . . . . . . . . . . 8 a de uso da rede wireless . . . . . . . . . . . . . . . . . . . 36 fatores de sucesso . . . . . . . . . . . . . . . . . . . . . . . . 7 inu ncias negativas . . . . . . . . . . . . . . . . . . . . . . 7 e POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 pornograa envolvendo criancas . . . . . . . . . . . . . . 15 protocolos sem criptograa . . . . . . . . . . . . . . . . . . . 26 proxy Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 formas de abuso . . . . . . . . . . . . . . . . . . . . . . . . . 16 R redes n o alocadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 a redes privadas (RFC 1918) . . . . . . . . . . . . . . . . . . . 27 redes reservadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 ltragem de enderecos . . . . . . . . . . . . . . . . . . . 26 lista atual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 RFC 3330 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 vazamento de enderecos . . . . . . . . . . . . . . . . . 27 redes sem o . . . . . . . . . . . . . . . . . . . . . . veja wireless refer ncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 e
Registro .br . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
relay aberto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 roaming users . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 rel gio o fuso hor rio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 a hor rio de ver o . . . . . . . . . . . . . . . . . . . . . . . . . 18 a a sincronizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 restauracao de backups . . . . . . . . . . . . . . . . . . . . . . . 28 rexec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 RFC 1918 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 RFC 2142 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 RFC 2544 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 RFC 3068 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 RFC 3330 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 rlogin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Roberta Bragg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 root . . . . . . . . . . . . . . . . . . . . veja contas privilegiadas rsh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 S SAGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Scott Barman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Scott Seebass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 senhas caractersticas desej veis . . . . . . . . . . . . . . . . . 13 a compartilhadas . . . . . . . . . . . . . . . . . . . . . . . . . . 19 de administrador . . . . . . . . . . . . . . . . . . . . . . . . 13 fortes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 mudanca de senhas default . . . . . . . . . . . . . . . 38 poltica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 service packs . . . . . . . . . veja correcoes de seguranca servicos desativacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 divis o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 a n o utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 a servidores de tempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2125, 27 SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15, 24 Simon Cooper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Simson Garnkel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 SPAM relay aberto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26, 37 vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26, 37 Steven M. Bellovin . . . . . . . . . . . . . . . . . . . . . . . . . . 41
46/46
su . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 T Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Trent R. Hein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 U usu rio a educacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Cartilha de Seguranca para Internet . . . . . 17 V vulnerabilidades correcoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 exposicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 W W. Richard Stevens . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Web proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 sites sobre seguranca . . . . . . . . . . . . . . . . . . . . 29 webmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 WHOIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . veja wireless Willian R. Cheswick . . . . . . . . . . . . . . . . . . . . . . . . . 41 wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3640 APs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 conguracao . . . . . . . . . . . . . . . . . . . . . . . . . . 38 uso de switch . . . . . . . . . . . . . . . . . . . . . . . . . 37 monitoracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 poltica de uso . . . . . . . . . . . . . . . . . . . . . . . . . . 36 segregacao da rede WLAN . . . . . . . . . . . . . . . 36 TKIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 topologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 vazamento de sinal . . . . . . . . . . . . . . . . . . . . . . 36 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 WEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Práticas de Segurança para Administradores de Redes Internet

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Práticas de Segurança para Administradores de Redes Internet

Caricato da

Copyright:

Formati disponibili

Pr ticas de Seguranca para Administradores de Redes Internet a

NIC BR Security Ofce http://www.nbso.nic.br/ Vers o 1.2 a 16 de maio de 2003

Polticas 2.1 2.2 Polticas de Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Polticas de Uso Aceit vel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a

Praticas de Seguranca para Administradores de Redes Internet

Eliminacao de Protocolos sem Criptograa . . . . . . . . . . . . . . . . . . . . . . . . . . . Cuidados com Redes Reservadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Praticas de Seguranca para Administradores de Redes Internet

Polticas de Backup e Restauracao de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . .

Praticas de Seguranca para Administradores de Redes Internet

Como Obter este Documento

Nota de Copyright e Distribuicao

Praticas de Seguranca para Administradores de Redes Internet

Praticas de Seguranca para Administradores de Redes Internet

Praticas de Seguranca para Administradores de Redes Internet

Praticas de Seguranca para Administradores de Redes Internet

Polticas de Uso Aceit vel a

Praticas de Seguranca para Administradores de Redes Internet

Instalacao e Conguracao Segura de Sistemas

Estrat gias de Particionamento e

Praticas de Seguranca para Administradores de Redes Internet

Praticas de Seguranca para Administradores de Redes Internet

Documentacao da Instalacao e Conguracao

Praticas de Seguranca para Administradores de Redes Internet

Logbook para vangogh.example.org (IP 192.0.2.24) ================================================ 26/Fev/2002 Responsvel: Joe a

(state) LISTEN LISTEN

Figura 1: Exemplos de entradas no logbook

Praticas de Seguranca para Administradores de Redes Internet

Praticas de Seguranca para Administradores de Redes Internet

Desativacao de Servicos N o Utilizados a

Praticas de Seguranca para Administradores de Redes Internet

3.8 Prevencao de Abuso de Recursos

Praticas de Seguranca para Administradores de Redes Internet

Praticas de Seguranca para Administradores de Redes Internet

Administracao e Operacao Segura de Redes e Sistemas

Ajuste do Rel gio o

Praticas de Seguranca para Administradores de Redes Internet

Controle de Alteracoes na Conguracao

Praticas de Seguranca para Administradores de Redes Internet

Praticas de Seguranca para Administradores de Redes Internet

Praticas de Seguranca para Administradores de Redes Internet

Praticas de Seguranca para Administradores de Redes Internet

Praticas de Seguranca para Administradores de Redes Internet

Uso de Privil gios Mnimos e

Cuidado com Informacoes Sensveis no DNS

Praticas de Seguranca para Administradores de Redes Internet

Praticas de Seguranca para Administradores de Redes Internet

Praticas de Seguranca para Administradores de Redes Internet

Eliminacao de Protocolos sem Criptograa

Cuidados com Redes Reservadas

Praticas de Seguranca para Administradores de Redes Internet

Polticas de Backup e Restauracao de Sistemas

Praticas de Seguranca para Administradores de Redes Internet

Como Manter-se Informado

Praticas de Seguranca para Administradores de Redes Internet

Precaucoes contra Engenharia Social

Praticas de Seguranca para Administradores de Redes Internet

Praticas de Seguranca para Administradores de Redes Internet

4.12 Uso Ecaz de Firewalls

Praticas de Seguranca para Administradores de Redes Internet

Tabela 2: Ferramentas de software livre para a construcao de rewalls

Localizacao dos Firewalls

Praticas de Seguranca para Administradores de Redes Internet

Crit rios de Filtragem e

Praticas de Seguranca para Administradores de Redes Internet

Praticas de Seguranca para Administradores de Redes Internet