Segurança Adm Redes

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

Copyright c 2002, 2003 NBSO
Resumo destinado a administradores de redes ligadas a ` Internet, incluindo provedores de acesso Este documento e ser um guia com informac es para congurar, administrar e operar estas e de conte udo. O seu prop osito e o redes de forma mais segura.
Sum ario
1 o Introduc a 1.1 1.2 1.3 2 o do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organizac a Como Obter este Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nota de Copyright e Distribuic a 4 4 4 4 6 6 8 9 9 9 11 13 14 14
Pol ticas 2.1 2.2 Pol ticas de Seguranc a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pol ticas de Uso Aceit avel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o e Congurac o Segura de Sistemas Instalac a a 3.1 3.2 3.3 3.4 3.5 3.6 o da Instalac o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparac a a Estrat egias de Particionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o da Instalac o e Congurac o . . . . . . . . . . . . . . . . . . . . . . . . . . . Documentac a a a Senhas de Administrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o M Instalac a nima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o de Servic Desativac a os N ao Utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Praticas de Seguranc a para Administradores de Redes Internet
2/46
3.7 3.8
o de Correc es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instalac a o o de Abuso de Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prevenc a 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
o e Operac o Segura de Redes e Sistemas Administrac a a 4.1 4.2 o dos Usu Educac a arios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ajuste do Rel ogio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 4.3 o de Rel Sincronizac a ogios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Equipes de Administradores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 4.3.2 4.3.3 o Eciente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comunicac a es na Congurac o . . . . . . . . . . . . . . . . . . . . . . . . . Controle de Alterac o a Uso de Contas Privilegiadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 4.4.2 4.4.3 o de Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gerac a Armazenamento de Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoramento de Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 o de Transfer Limitac a encias de Zona . . . . . . . . . . . . . . . . . . . . . . . . . . o de Servidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Separac a Uso de Privil egios M nimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . es Sens Cuidado com Informac o veis no DNS . . . . . . . . . . . . . . . . . . . . . . DNS Reverso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6
es de Contato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Informac o 4.6.1 4.6.2 4.6.3 Enderec os Eletr onicos Padr ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contato no DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contatos no WHOIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7 4.8
o de Protocolos sem Criptograa . . . . . . . . . . . . . . . . . . . . . . . . . . . Eliminac a Cuidados com Redes Reservadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3/46
4.9
o de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . Pol ticas de Backup e Restaurac a
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . es contra Engenharia Social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Precauc o 4.12 Uso Ecaz de Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12.1 A Escolha de um Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o dos Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12.2 Localizac a 4.12.3 Crit erios de Filtragem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12.4 Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13 Redes Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.1 Pol tica de Uso da Rede Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.2 Topologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.3 Criptograa e Autenticac a 4.13.4 Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o aos Clientes Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.5 Protec a o da Rede Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.6 Monitorac a A Refer encias Adicionais A.1 URLs de Interesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 Livros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Indice Remissivo
4/46
o Introduc a
o, administrac o e operac o Este documento procura reunir um conjunto de boas pr aticas em congurac a a a ` Internet. A implantac o destas pr segura de redes conectadas a a aticas minimiza as chances de ocorrerem pro importante frisar que o das redes e recursos de forma segura. E blemas de seguranc a e facilita a administrac a este conjunto representa o m nimo indispens avel dentro de um grande universo de boas pr aticas de seguranc a, o e um bom comec suciente em todas as o que equivale a dizer que a sua adoc a o mas n ao necessariamente e es. situac o es apresentadas s As recomendac o ao eminentemente pr aticas e, tanto quanto poss vel, independentes de gen o plataforma de software e hardware. A maioria dos princ pios aqui expostos e erica; a sua efetiva aplicac a requer que um administrador determine como estes princ pios podem ser implementados nas plataformas que ele utiliza. dirigido ao pessoal t ` Internet, especialmente aos adminisEste documento e ecnico de redes conectadas a o ou tradores de redes, sistemas e/ou seguranc a, que s ao os respons aveis pelo planejamento, implementac a o de redes e sistemas. Tamb operac a em podem se beneciar da sua leitura gerentes com conhecimento t ecnico de redes.
1.1
o do Documento Organizac a
o 2 apresenta pol ticas importantes O restante deste documento est a organizado da seguinte maneira. A sec a es subseq o 3 mostra como para respaldar e viabilizar os procedimentos t ecnicos descritos nas sec o uentes. A sec a o 4 s congurar sistemas e redes de forma mais segura. Na sec a ao discutidos m etodos para se ter seguranc a na o e operac o de redes e sistemas. O ap administrac a a endice A traz sugest oes de material de consulta para quem es de 2 a 4. queira obter conhecimentos mais aprofundados sobre algum dos temas abordados nas sec o
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 ao mais recente. No mesmo enderec o tamb em est a dispon vel um checklist que resume as principais pr aticas apresentadas o. neste documento, e que pode ser usado para o acompanhamento da sua implantac a Caso voc e tenha alguma sugest ao para este documento ou encontre algum erro nele, entre em contato atrav es do enderec o doc@nic.br.
1.3
o Nota de Copyright e Distribuic a
Copyright c 2002, 2003 NBSO. Ele pode ser livremente copiado desde que sejam Este documento e es: respeitadas as seguintes condic o permitido fazer e distribuir c 1. E opias inalteradas deste documento, completo ou em partes, contanto que o seja mantida em todas as c o n esta nota de copyright e distribuic a opias, e que a distribuic a ao tenha ns comerciais.
5/46
es de como obt 2. Se este documento for distribu do apenas em partes, instruc o e-lo por completo devem ser inclu das. permitido o uso dos exemplos de documentos e de congurac o inclu 3. E a dos neste texto. Tal uso e o. completamente livre e n ao est a sujeito a nenhuma restric a vedada a distribuic o de vers o de c 4. E a oes modicadas deste documento, bem como a comercializac a opias, sem a permiss ao expressa do NBSO. o deste documento, o NBSO n Embora todos os cuidados tenham sido tomados na preparac a ao garante o absoluta das informac es nele contidas, nem se responsabiliza por eventuais conseq ncias que a correc a o ue possam advir do seu uso.
6/46
2
2.1
Pol ticas
Pol ticas de Seguranc a
um instrumento importante para proteger a sua organizac o contra ameac ` Uma pol tica de seguranc a e a as a o que a ela pertence ou que est ` seguranc seguranc a da informac a a sob sua responsabilidade. Uma ameac a a a compreendida neste contexto como a quebra de uma ou mais de suas tr e es propriedades fundamentais (condencialidade, integridade e disponibilidade). o e protec o da informac o, A pol tica de seguranc a n ao dene procedimentos espec cos de manipulac a a a ` s pessoas (usu mas atribui direitos e responsabilidades a arios, administradores de redes e sistemas, funcion arios, o. Desta forma, elas sabem quais as expectativas que podem ter gerentes, etc.) que lidam com essa informac a es em relac o a ` seguranc e quais s ao as suas atribuic o a a dos recursos computacionais com os quais trabalham. ` s quais est Al em disso, a pol tica de seguranc a tamb em estipula as penalidades a ao sujeitos aqueles que a descumprem. necess o a ser protegida. Usualmente, Antes que a pol tica de seguranc a seja escrita, e ario denir a informac a feito atrav isso e es de uma an alise de riscos, que identica: recursos protegidos pela pol tica; ` s quais estes recursos est ameac as a ao sujeitos; o destas ameac vulnerabilidades que podem viabilizar a concretizac a as, analisando-as individualmente. Uma pol tica de seguranc a deve cobrir os seguintes aspectos: aspectos preliminares: o da pol abrang encia e escopo de atuac a tica; es fundamentais; denic o normas e regulamentos aos quais a pol tica est a subordinada; quem tem autoridade para sancionar, implementar e scalizar o cumprimento da pol tica; o da pol meios de distribuic a tica; ncia a pol revisada. como e com que freq ue tica e pol tica de senhas: o de senhas; requisitos para formac a per odo de validade das senhas; o de senhas; normas para protec a reuso de senhas; senhas default. direitos e responsabilidades dos usu arios, tais como: o de contas de acesso; utilizac a
7/46
o de softwares e informac es, incluindo quest o, licenciamento e copyright; utilizac a o oes de instalac a o e uso de informac es (sens o de sistemas protec a o veis ou n ao), como senhas, dados de congurac a o; e dados condenciais da organizac a uso aceit avel de recursos como email, news e p aginas Web; ` privacidade, e condic es nas quais esse direito pode ser violado pelo provedor dos recursos direito a o o); (a organizac a uso de antiv rus. direitos e responsabilidades do provedor dos recursos, como: backups; o e instalac o de sistemas e equipamentos de rede; diretrizes para congurac a a es de acesso, conectar e desconectar sistemas e equi autoridade para conceder e revogar autorizac o pamentos de rede, alocar e registrar enderec os e nomes de sistemas e equipamentos; monitoramento de sistemas e equipamentos de rede; normas de seguranc a f sica. es previstas em caso de violac o da pol ac o a tica: diretrizes para tratamento e resposta de incidentes de seguranc a; penalidades cab veis. exaustiva nem tampouco se aplica a todos os casos. Cabe ressaltar que a lista de t opicos acima n ao e o possui um ambiente distinto e os seus pr Cada organizac a oprios requisitos de seguranc a, e deve, portanto, desenvolver uma pol tica de seguranc a que se molde a essas peculiaridades. E recomend avel, por exemplo, es que possuam uma rede wireless incorporem uma pol que organizac o tica espec ca para este tipo de rede o 4.13.1) a ` sua pol (sec a tica de seguranc a. Alguns fatores importantes para o sucesso de uma pol tica de seguranc a s ao: o superior; apoio por parte da administrac a a pol tica deve ser ampla, cobrindo todos os aspectos que envolvem a seguranc a dos recursos computaci o sob responsabilidade da organizac o; onais e da informac a a o; a pol tica deve ser periodicamente atualizada de forma a reetir as mudanc as na organizac a deve haver um indiv duo ou grupo respons avel por vericar se a pol tica est a sendo respeitada; o devem tomar conhecimento da pol todos os usu arios da organizac a tica e manifestar a sua concord ancia em submeter-se a ela antes de obter acesso aos recursos computacionais; a pol tica deve estar dispon vel em um local de f acil acesso aos usu arios, tal como a intranet da organiza o. c a o superior e essencial. Se a pol Dentre os itens acima, o apoio por parte da administrac a tica de o, ela rapidamente ser seguranc a n ao for encampada pela administrac a a deixada de lado pelos demais seto o. Al importante que os seus membros d ` res da organizac a em disso, e eem o exemplo no que diz respeito a observ ancia da pol tica de seguranc a.
8/46
o de uma pol Os seguintes fatores inuem negativamente na aceitac a tica de seguranc a e podem lev a-la ao fracasso: a pol tica n ao deve ser demasiadamente detalhada ou restritiva; o; o excesso de detalhes na pol tica pode causar confus ao ou diculdades na sua implementac a es para indiv n ao devem ser abertas excec o duos ou grupos; a pol tica n ao deve estar atrelada a softwares e/ou hardwares espec cos.
2.2
Pol ticas de Uso Aceit avel
o documento que dene como os recursos A pol tica de uso aceit avel (AUPAcceptable Use Policy) e o podem ser utilizados. Ela deve ser p computacionais da organizac a ublica e estar dispon vel a todos os que o, sendo recomend o para uso dos utilizam a infra-estrutura computacional da organizac a avel que a autorizac a recursos seja condicionada a uma concord ancia expressa com os seus termos. geralmente parte integrante da pol es, ela ser A AUP e tica de seguranc a global. Para muitas organizac o a composta pelos itens da pol tica que afetam diretamente os usu arios de recursos computacionais, principalmente os que denem seus direitos e responsabilidades. es que oferecem acesso a usu Por outro lado, organizac o arios externos (tais como provedores de acesso ` qual Internet) devem denir uma pol tica de uso aceit avel para esses usu arios que seja independente da AUP a importante que os usu est ao sujeitos os seus usu arios internos. E arios externos tomem conhecimento dessa pol tica e saibam que o uso dos recursos est a condicionado ao seu cumprimento.
9/46
o e Congurac o Segura de Sistemas Instalac a a
o 2), Uma vez estabelecidas as pol ticas de seguranc a apropriadas para a sua rede (conforme exposto na sec a o segura dos sistemas que estar a etapa seguinte deve ser a congurac a ao nessa rede. o atualizada que detalhe a congurac o de alguns ou todos os sistemas Caso n ao exista uma documentac a a aconselh es aqui em uso na sua rede, e avel que estes sistemas sejam reinstalados observando-se as recomendac o o seja revisada e a documentac o correspondente atualizada. expostas, ou, pelo menos, que a sua congurac a a ` Internet ap es 3.1 a 3.8 IMPORTANTE: um sistema s o dever a ser conectado a os os passos descritos nas sec o terem sido seguidos. A pressa em disponibilizar um sistema na Internet pode levar ao seu comprometimento.
3.1
o da Instalac o Preparac a a
o de um sistema deve ser feita com ele isolado do mundo externo. Para tanto, os seguintes A instalac a princ pios devem ser seguidos: o, denindo itens como: planeje a instalac a o prop osito do sistema a ser instalado; os servic os que este sistema disponibilizar a; o de hardware da m a congurac a aquina; como o disco ser a particionado, etc. o que ser providencie de antem ao todos os manuais e m dias de instalac a ao utilizados; instale o sistema a partir de dispositivos de armazenamento locais (CD, ta ou disco), desconectado da rede; es, por exemplo), coloque-o caso voc e precise ligar o sistema em rede (para fazer download de atualizac o em uma rede isolada, acess vel apenas pela sua rede interna. nica m Caso seja poss vel, evite concentrar todos os servic os de rede em uma u aquina, dividindo-os entre desej v arios sistemas. Isto e avel pois aumenta a disponibilidade dos servic os na sua rede e reduz a extens ao de um eventual comprometimento a partir de um deles.
3.2
Estrat egias de Particionamento
o 3.1, um dos aspectos que devem ser inclu dos no planejamento da insConforme mencionado na sec a o e como ser talac a a feito o particionamento do(s) disco(s) do sistema. Embora isso dependa basicamente da o pretendida para o sistema, existem alguns fatores que devem ser levados em considerac o no moutilizac a a mento de decidir como o disco deve ser particionado. dividir o disco em v es em vez de usar uma u nica partic o ocupando o Um princ pio b asico e arias partic o a recomend disco inteiro. Isto e avel por diversas raz oes:
10/46
o na qual tenha permiss Um usu ario ou um programa mal-comportado pode lotar uma partic a ao de escrita ( areas tempor arias e de armazenamento de logs s ao suscet veis a este problema). Se os programas do o eles provavelmente n sistema estiverem em outra partic a ao ser ao afetados, evitando que o sistema trave. o seja corrompida por alguma raz es provavelmente n Caso uma partic a ao, as outras partic o ao ser ao afetadas. poss Em alguns sistemas (notadamente sistemas Unix), e vel denir algumas caracter sticas individuais o. Por exemplo, algumas partic es podem ser usadas em modo read-only, o que e u til para cada partic a o es que contenham bin ncia. para partic o arios que s ao modicados com pouca freq ue es permite m es de disco em paralelo e/ou o Em alguns casos a exist encia de v arias partic o ultiplas operac o es individuais para cada partic o, o que pode aumentar signicativamente o desempenho uso de otimizac o a do sistema. es geralmente facilita o procedimento de backup do sistema, pois simplica O uso de v arias partic o es como: func o es inteiras de uma s copiar partic o o vez; es individuais do procedimento; excluir partic o o. fazer backups em intervalos diferentes para cada partic a es espec As partic o cas que devem ser criadas variam de sistema para sistema, n ao existindo uma regra que o de partic es separadas possa ser sempre seguida. Entretanto, recomenda-se avaliar a conveni encia da criac a o reas onde s para as a ao armazenados itens como: programas do sistema operacional; dados dos usu arios; logs; arquivos tempor arios; o de emails (servidores SMTP); las de envio e recepc a las de impress ao (servidores de impress ao); reposit orios de arquivos (servidores FTP); p aginas Web (servidores HTTP). exaustiva, podendo existir outras a reas do sistema que merec o Note que a lista acima n ao e am uma partic a separada. Da mesma forma, existem itens dentre os acima que n ao se aplicam a determinados casos. Consulte a o do seu sistema operacional para ver se ela cont es a respeito do particionamento documentac a em recomendac o adequado dos discos. es devem ser dimensionadas de acordo com os requisitos de cada sistema. Em muitos caAs partic o fornecido na sua documentac o, o que pode auxiliar na sos, o tamanho ocupado pelo sistema operacional e a o do tamanho de algumas partic es. determinac a o recomend Qualquer que seja a estrutura de particionamento escolhida, e avel que voc e tenha pelo menos o. Isto agiliza o processo de instalac o e reduz a um esboc o dela por escrito antes de comec ar a instalac a a ncias sejam adequadamente probabilidade de que se fac a uma determinada escolha sem que as suas conseq ue previstas.
11/46
3.3
o da Instalac o e Congurac o Documentac a a a
o da situac o de um sistema e a documentac o Uma medida importante para permitir uma r apida avaliac a a a o e congurac o. A id ter uma esp de sua instalac a a eia e ecie de logbook (ou di ario de bordo), que detalhe os es na sua congurac o global. componentes instalados no sistema e todas as modicac o a til para determinar qual vers Esse logbook pode ser particularmente u ao de determinado pacote est a instalada no sistema ou para reconstituir uma dada instalac ao. Muitas vezes um administrador precisa consultar diversas fontes e realizar v arias tentativas antes de instalar e/ou congurar corretamente um determinado pacote de software. A exist encia de um documento que relate quais os passos exatos que tiveram que ser seguidos para que o/congurac o fosse bem sucedida permite que esse mesmo pacote possa ser instalado com correc o a instalac a a a o 4.3, a import e rapidez em outro sistema ou ocasi ao. Conforme ser a visto na sec a ancia deste documento cresce o dos sistemas seja compartilhada por diversas pessoas. na medida em que a responsabilidade pela administrac a o do logbook dependem de diversos fatores, e cada administrador deve O formato e o grau de sosticac a es. Um simples arquivo texto pode revelar-se determinar qual a melhor maneira de manter essas informac o que esse documento extremamente ecaz, como mostram os exemplos da gura 1. O que realmente importa e es suesteja dispon vel em caso de falha (acidental ou provocada) do sistema, e que ele contenha informac o o que o sistema possu cientes para que, a partir dele, seja poss vel reconstituir a exata congurac a a antes da falha, sem que seja necess ario recorrer a backups.1 essencial que alterac es na congurac o do sistema e de seus componentes estejam documentadas neste E o a es deve conter, no m logbook. A entrada referente a estas alterac o nimo, os seguintes itens: o; data da modicac a o; respons avel pela modicac a o; justicativa para a modicac a o da modicac o. descric a a o antes da mudanc o a partir dessa entrada. Deve ser poss vel, ainda, reconstituir a situac a a na congurac a A gura 1 mostra um exemplo com algumas entradas do logbook de um servidor FTP. A primeira entrada o inicial do sistema, realizada no dia 26/02 por um administrador chamado Joe, e descreve registra a instalac a ainda: o sistema operacional utilizado; como ele foi instalado; como o disco foi particionado; onde pode ser encontrada a lista de pacotes instalados; o; quais as portas que caram ativas ap os a instalac a quais os usu arios criados (com seus respectivos UIDs e GIDs).
1A
o 4.9. exist encia do logbook n ao diminui a import ancia dos backups, que ser ao tratados na sec a
12/46
Logbook para vangogh.example.org (IP 192.0.2.24) ================================================ 26/Fev/2002 Respons avel: Joe
Instalac ao de vangogh.example.org, servidor FTP de example.org. Instalado o sistema operacional GoodBSD vers ao 6.5. A instalac ao foi feita usando a opc ao custom do menu de instalac ao. O disco foi particionado da seguinte maneira: 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 a em /usr/local/sysadm/pkg.inst. abertas ap os a instalac ao s ao (netstat -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 usu arios joe (UID=501), alice (UID=502), bob (UID=503) e caio (UID=504). Cada usu ario pertence ao seu pr oprio grupo (GID=UID) e joe, alice e bob pertencem tamb em ao grupo wheel. -----------------------------------------------------------------------01/Mar/2002 Respons avel: Alice Instalado o foo-1.2.3, uma ferramenta para an alise de logs de FTP. Os fontes est ao em /usr/local/src/foo-1.2.3. Os comandos necess arios para a instalac ao foram: $ ./configure $ make # make install Para usar o programa, foi necess ario criar o usu ario foo (UID=300,GID=100/users) e o diret orio /usr/local/share/foo (owner=foo, group=users), com permiss oes 0755. -----------------------------------------------------------------------03/Mar/2002 Respons avel: Bob Criado o grupo foobar (GID=300), para os usu arios do pacote foo. O diret orio /usr/local/share/foo teve seu grupo alterado de users para foobar e as permiss oes de 0755 para 0750. Modificac ao necess aria para que apenas usu arios pertencentes ao grupo foobar tenham acesso aos programas do pacote foo. Os usu arios alice, bob e caio foram adicionados ao grupo foobar. -----------------------------------------------------------------------03/Mar/2002 Respons avel: Alice Modificado o /etc/rc.local para carregar o daemon bard (usado pelo pacote foo) no boot. Um diff da modificac ao est a em /usr/local/sysadm/rc.local-bard.diff.
Figura 1: Exemplos de entradas no logbook
13/46
o inicial do sistema operacional, no dia 01/03 foi instalado um pacote chamado foo, vers Ap os a instalac a ao 1.2.3. A entrada correspondente no logbook descreve os passos que foram seguidos para compilar e instalar o o de um usu pacote e para preparar o sistema para o seu uso (criac a ario e um diret orio, com suas respectivas es). informac o es que tiveram que ser feitas na congurac o do sistema paA terceira entrada registra algumas alterac o a ltima entrada do exemplo apresenta ra que o pacote foo pudesse ser usado corretamente. Por sua vez, a u o na inicializac o do sistema para carregar um daemon (software servidor) usado pelo pacouma modicac a a o anterior do sistema (ou seja, a situac o antes das te. Observe que ambas as entradas permitem que a situac a a es descritas) seja restaurada, caso isso se revele necess modicac o ario ou desej avel. um documento sens es que podem IMPORTANTE: o logbook de um sistema e vel, pois cont em informac o ser usadas para comprometer mais facilmente a seguranc a deste sistema. Sendo assim, ele deve ser armazenado o. e manipulado com cuidado, de acordo com a pol tica para documentos sens veis da sua organizac a
3.4
Senhas de Administrador
o de um sistema, em determinado momento ser Durante a instalac a a solicitado que voc e informe uma senha o pr o que de administrador (root ou Administrator). Na maioria dos casos, e oprio programa de instalac a solicita a escolha da senha. Em outros casos, a senha de administrador deve ser denida ap os o primeiro boot do sistema. o do sistema. De prefer Procure estabelecer esta senha t ao cedo quanto poss vel durante a instalac a encia, o. tenha uma senha j a em mente quando comec ar a instalac a aquela f Uma senha adequada e acil de ser lembrada e dif cil de ser adivinhada. Ela deve respeitar, no m nimo, os seguintes crit erios: ter um comprimento m nimo de 8 caracteres; ser formada por letras, n umeros e caracteres especiais; n ao ser derivada de seus dados pessoais, tais como nomes de membros da fam lia (incluindo animais de o), n estimac a umeros de telefone, placas de carros, n umeros de documentos e datas; n ao dever ser adivinhada por quem conhec a suas prefer encias pessoais (time para o qual torce, escritor, ator ou cantor favorito, nomes de livros, lmes ou m usicas, etc.); n ao estar presente em dicion arios (de portugu es ou de outros idiomas). usar as primeiras ou u ltimas letras Uma sugest ao para formar senhas que se encaixem nos requisitos acima e das palavras de uma frase, adicionando n umeros e s mbolos e trocando min usculas e mai usculas para dicultar ataques baseados em forc a bruta. Por exemplo, a partir das iniciais de the book is on the table obt em-se, poss inicialmente, tbiott. A partir da , e vel trocar a letra o por um 0 (zero) e o pen ultimo t por um s mbolo +, colocar algumas letras em mai usculo e acrescentar outras letras, chegando a tBi0+TbL, uma senha bastante dif cil de ser adivinhada ou obtida por forc a bruta.2
2 Evidentemente
esta deixou de ser uma senha segura por constar neste documento.
14/46
3.5
o M Instalac a nima
o do m Um sistema mais seguro comec a pela instalac a nimo poss vel de pacotes e componentes, especialmente os que implementam servic os de rede. Este m nimo depende fundamentalmente do prop osito do sistema em quest ao e do ambiente de rede no qual ele est a inserido. Por exemplo, em princ pio um sistema dedicado o de trabalho n a servir p aginas Web n ao precisa de um software servidor SMTP, assim como uma estac a ao precisa de um servidor HTTP. comum que servic o e bastante simples. E A justicativa para esta recomendac a os n ao utilizados n ao seo jam monitorados por falhas de seguranc a, o que aumenta a possibilidade de n ao ser aplicada uma correc a o no n necess aria. A reduc a umero de pacotes instalados diminui a chance de que o sistema possua uma vulnerabilidade que possa vir a ser explorada por um atacante. Muitas vezes, administradores preferem instalar componentes cujo prop osito ou funcionalidade desconhec am por receio de que alguma coisa deixe de funcionar no sistema. Entretanto, a maioria dos sistemas atuais possui algum mecanismo de controle de depend encias que avisa quando determinado componente precisa de poss outro para funcionar. Em outras palavras, freq uentemente e vel deixar de instalar v arios componentes sem o do seu sistema ou o suporte t comprometer a funcionalidade do sistema. Consulte a documentac a ecnico do seu fornecedor para saber se isto se aplica ao seu caso. o permitem que o administrador escolha entre uma instalac o t Alguns programas de instalac a a pica e uma personalizada (para experts). Quando poss vel, opte pela personalizada, evitando instalar componentes cuja ` sua necessidade. funcionalidade seja desconhecida ou que voc e n ao esteja certo quanto a o se d o do sistema base (sobre a qual o admiEm outros sistemas a instalac a a em duas etapas, a instalac a o de pacotes ou componentes adicionais. Neste caso, nistrador tem m nimo ou nenhum controle) e a instalac a instale o sistema base e selecione cuidadosamente quais os componentes extras que ser ao adicionados ao siste o de servic o 3.6) e muito importante e deve ser ma. Neste tipo de sistema, a desativac a os n ao utilizados (sec a o. realizada com especial atenc a
3.6
o de Servic Desativac a os N ao Utilizados
o m a desativac o de servic O passo seguinte a uma instalac a nima e a os (locais e, principalmente, de rede) o e a mesma por tr que n ao ser ao imediatamente utilizados no sistema. A l ogica por tr as desta recomendac a as o m o do sistema a vulnerabilidades. da instalac a nima de pacotes: reduzir a exposic a es Embora possa parecer que exista redund ancia entre este passo e o anterior, na pr atica surgem situac o forc nas quais o administrador e ado a instalar um pacote ou componente completo para poder utilizar um o de subconjunto das funcionalidades oferecidas por esse pacote. Al em disso, muitos programas de instalac a o sistemas operacionais optam por maximizar a funcionalidade disponibilizada aos usu arios, e a congurac a es ocorra, as padr ao do sistema traz ativados todos os servic os que foram instalados. Caso uma dessas situac o funcionalidades que n ao ser ao utilizadas dever ao ser desativadas ou mesmo removidas do sistema. Por exemplo, suponha que um pacote de servic os de impress ao contenha tanto um cliente quanto um servidor de impress ao remota. Se o sistema necessitar apenas do software cliente, o administrador deve desabilitar a parte referente ao software servidor neste sistema. usar um ltro de pacotes para Caso n ao seja poss vel desativar servic os individualmente, uma alternativa e bloquear as portas TCP/UDP usadas por esses servic os, impedindo que eles sejam acessados atrav es da rede. o 4.12. Isto ser a discutido em maiores detalhes na sec a
15/46
o de servic o de arquivos efetuadas nesta fase dever IMPORTANTE: a desativac a os e/ou a remoc a ao ser documentadas no logbook do sistema.
3.7
o de Correc es Instalac a o
necess Depois de um sistema ter sido corretamente instalado e congurado, e ario vericar se n ao existem es (patches, xes, service packs) para vulnerabilidades conhecidas nos componentes instalados. A maicorrec o es para problemas de seguranc oria dos fornecedores de software libera correc o a que sejam descobertos em um es est sistema, sem que se tenha de esperar pela sua pr oxima vers ao. Na maioria das vezes, estas correc o ao dispon veis atrav es da Internet. Consulte seu fornecedor para saber como manter-se informado a respeito de es para o seu sistema e de que forma elas podem ser obtidas. correc o es dispon ` quelas que corrigem Nem sempre todas as correc o veis precisam ser instaladas. Restrinja-se a problemas em componentes que estejam efetivamente instalados no seu sistema. Em caso de d uvida, recorra ao o indiscriminada de atualizac es pode enfraquecer a seguranc suporte t ecnico do seu fornecedor. A instalac a o a do sistema ao inv es de fortalec e-la. o de correc es. Mantenha em sua rede um reposit es que Registre no logbook a instalac a o orio das atualizac o o das mesmas em outros sistemas. j a foram utilizadas, para facilitar a instalac a es do sistema s IMPORTANTE: muitas vezes algumas congurac o ao alteradas durante o processo de instala o de correc es. Sendo assim, e recomend o do seu sistema ap c a o avel que voc e reveja a congurac a os instalar o para certicar-se de que a instalac o n es que voc uma correc a a ao tenha revertido eventuais modicac o e tenha feito (especialmente aquelas destinadas a desativar servic os). o de correc es deve ser realizada n o inicial do IMPORTANTE: a instalac a o ao s o como parte da instalac a sistema, mas tamb em durante o seu tempo de vida, a intervalos peri odicos ou sempre que surgirem vulnerabili o 4.10 traz algumas recomendac es sobre como manter-se informado a respeito de dades que o afetem. A sec a o novas vulnerabilidades que afetem os seus sistemas.
o de Abuso de Recursos 3.8 Prevenc a

Existem alguns servic os que, se mal congurados, podem permitir que usu arios externos abusem dos recursos da sua rede, ainda que isso n ao implique na ocorr encia de uma invas ao. Dois destes servic os s ao o email e os proxies de Web. o incorreta destes servic que recursos A congurac a os pode causar v arios efeitos indesej aveis. Um deles e oa comec computacionais da organizac a ar pelo link Internet, mas incluindo CPU, discos e mem oria dos servidoress ao consumidos por terceiros sem que eles paguem por esse uso. Em muitos casos, esses recursos s ao exauridos de forma que usu arios leg timos n ao possam utilizar o servic o. Al em disso, servidores mal congurados s ao muitas vezes usados para disseminar conte udo ilegal, tal como pornograa envolvendo crianc as. Se um conte udo deste tipo for encontrado em sistemas sob sua responsabili o venham a ser legalmente implicados no caso. dade, existe a possibilidade de que voc e e/ou sua organizac a 3.8.1 Controle de Relay em Servidores SMTP
o padr Na sua congurac a ao, muitos servidores SMTP v em com o relay aberto, permitindo que eles sejam usados para enviar mensagens de e para qualquer rede ou dom nio, independente dos enderec os envolvidos
16/46
serem da sua rede ou n ao. Estes servidores s ao amplamente explorados para envio de SPAM. ncias j o de mensagens a partir de Al em das conseq ue a mencionadas, diversas redes bloqueiam a recepc a servidores que tenham sido ou estejam sendo usados para envio de SPAM, fazendo com que usu arios do servidor com relay aberto n ao possam enviar mensagens a usu arios dessas redes. H a que se considerar tamb em que o o e identicac o dos spammers, diminuindo uso de servidores SMTP de terceiros torna mais dif cil a localizac a a as chances de que eles sejam punidos por estes abusos. Para resolver este problema de relay aberto voc e precisa congurar os seus servidores SMTP corretamente. o adequada deve permitir apenas: A congurac a envio de mensagens com enderec o de origem local e enderec o de destino local ou externo; o de mensagens com enderec recepc a o de origem local ou externo e enderec o de destino local. es sobre como corrigir este problema para diferentes servidores SMTP est Informac o ao dispon veis em http://www.mail-abuse.org/tsi/. poss Na maioria dos casos, e vel fechar o relay mesmo quando a rede possui roaming users, usando mecanismos como POP-before-SMTP e SMTP AUTH. Caso a sua rede necessite suportar usu arios deste tipo, o do seu servidor SMTP ou o seu fornecedor para saber como fechar o relay sem consulte a documentac a o do servic prejudicar a utilizac a o 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 es. e Microsoft Proxy Server) tamb em podem ser abusados se n ao forem tomadas as devidas precauc o Um proxy mal congurado pode ser usado por usu arios externos como um trampolim para acessar recursos de forma an onima. Esta anonimidade pode ser usada para cometer crimes, tais como envio de mensagens o de pornograa envolvendo crianc caluniosas, difamat orias ou ameac adoras e divulgac a as. o correta para um proxy Web e aquela que libera o acesso somente aos enderec A congurac a os IP de ` sua rede). Consulte a documentac o do seu software ou o suporte t usu arios autorizados (pertencentes a a ecnico es sobre como congurar o controle de acesso no seu proxy. do seu fornecedor para obter maiores informac o
17/46
4
4.1
o e Operac o Segura de Redes e Sistemas Administrac a a

o dos Usu Educac a arios
Uma tarefa extremanente importante e que deve fazer parte do cotidiano de administradores de redes e o dos usu a constante educac a arios. Sabe-se que grande parte dos problemas de seguranc a s ao originados na o e, muitas vezes, s rede interna da organizac a ao causados pelo desconhecimento de conceitos e procedimentos b asicos de seguranc a por parte dos usu arios. a m o do programa de leitura de emails de um usu Um exemplo cl assico deste problema e a congurac a ario, que faz com que qualquer arquivo anexado a uma mensagem seja automaticamente aberto ou executado, per o de backdoors, cavalos de tr o de v mitindo a instalac a oia, disseminac a rus, etc. o e o estabelecimento de pol O primeiro fator que contribui diretamente para o processo de educac a ticas o 2) claras, sem ambiguidades, conhecidas e completamente entendidas de seguranc a e de uso aceit avel (sec a pelos usu arios da rede. o estabelecimento de um canal de comunicac o, por exemplo, atrav Outro fator importante e a es de listas de es sobre quest emails, onde informac o oes relevantes de seguranc a s ao frequentemente passadas para os usu arios o pode da rede. A descoberta de uma vulnerabilidade de seguranc a que afeta o servidor Web da organizac a o da descoberta de um novo v o e n ao ser relevante para os usu arios, mas a noticac a rus, sua forma de infecc a o s es que devem ser conhecidas e aplicadas por todos os usu m etodos de prevenc a ao informac o arios. es, tarefas como a instalac o e congurac o do Muitas vezes e, principalmente, em grandes organizac o a a sistema operacional e softwares de um computador s ao realizadas pelo pr oprio usu ario. Da vem um dos o, pois a execuc o de tais tarefas tem impacto direto fatores de grande import ancia neste processo de educac a a o. na seguranc a das redes e sistemas de uma organizac a o do usu Procurando cobrir os t opicos necess arios para a educac a ario, dentre outras quest oes, foi desenvolvida a Cartilha de Seguranc a para a Internet, que tem por nalidade sanar algumas d uvidas comuns sobre seguranc a de computadores e redes e sobre o signicado de termos e conceitos amplamente utilizados na Internet. Al em disso, a cartilha procura enumerar, explicar e fornecer um guia para uma s erie de procedimentos que visam aumentar a seguranc a de um computador e de posturas que um usu ario pode adotar para garantir sua seguranc a na Internet. Este documento pode ser obtido em http://www.nbso.nic.br/docs/cartilha/.
4.2
Ajuste do Rel ogio
o de Rel 4.2.1 Sincronizac a ogios es de trabalho) dever Os rel ogios de todos os sistemas da sua rede (incluindo as estac o ao estar sincronizados, ou seja, dever ao ter exatamente o mesmo hor ario. Para que isso acontec a, voc e deve usar um protocolo de o de rel o mais recomendado, sincronizac a ogios, tal como o NTP (Network Time Protocol). Este protocolo e es dele para os mais variados sistemas operacionais, como pode ser visto em http: pois existem implementac o //www.ntp.org/. Para obter maior precis ao no ajuste e para minimizar o tr afego desnecess ario na rede, sugere-se que a o via NTP seja implementada observando-se as seguintes recomendac es: sincronizac a o
18/46
quem ir o 1. Procure manter em sua rede um servidor NTP local. Esse servidor e a realizar a sincronizac a com um servidor externo. As demais m aquinas da sua rede, por sua vez, ter ao seus rel ogios sincronizados com o rel ogio do servidor local. 2. Muitos backbones disponibilizam um servidor NTP a seus clientes. Consulte o suporte t ecnico do seu backbone para vericar se ele oferece este servic o e como voc e pode fazer para utiliz a-lo.
4.2.2
Timezone
Caso voc e trabalhe com servidores Unix, ajuste o rel ogio de hardware destes sistemas para a hora padr ao de Greenwich (GMT) e congure adequadamente o seu fuso hor ario (timezone) para que a hora local seja exibida corretamente. O uso do timezone certo tamb em possibilita o ajuste automatizado do rel ogio por conta do hor ario de ver ao. es de timezone com as datas Para que isso seja poss vel, voc e dever a criar ou obter um arquivo de informac o es, consulte a documentac o do comando corretas de in cio e m do hor ario de ver ao. Para maiores informac o a zic.
4.3
Equipes de Administradores
o de sistemas e uma responsabilidade dividida entre v Em muitas redes, a administrac a arias pessoas. Nesses necess casos, e ario estabelecer algumas regras para garantir a eci encia do trabalho em equipe.
4.3.1
o Eciente Comunicac a
essencial que os diferentes administradores comuniquem-se de maneira eciente. Um Em primeiro lugar, e estabelecer listas de discuss ` sua organizac o. Esbom modo de fazer isto e ao por email que sejam internas a a es na congurac o dos sistemas, tas listas podem ser usadas para, entre outros prop ositos, comunicar alterac o a noticar os demais administradores a respeito de ocorr encias relevantes e servir como mecanismo de acompanhamento da divis ao de tarefas. que elas possibilitam a comunicac o entre os adminisA grande vantagem de usar listas de discuss ao e a tradores mesmo que alguns trabalhem em diferentes turnos ou locais. O hist orico das listas pode servir para documentar decis oes tomadas e para atualizar um administrador que tenha passado algum tempo afastado de suas atividades.
4.3.2
es na Congurac o Controle de Alterac o a
o de um sistema, torna-se A partir do momento em que v arias pessoas cam encarregadas da administrac a o de quem foi o respons o na sua necess ario dispor de meios que possibilitem a identicac a avel por cada alterac a o. Isso permite resolver problemas de forma mais eciente, pois a pessoa que realizou determinada congurac a o e a mais indicada para ajudar na resoluc o de eventuais complicac es dela decorrentes. modicac a a o o 3.3, o logbook pode auxiliar nessa tarefa. Para isso, e necess Conforme mostrado na sec a ario que em cada es ali descritas. entrada no logbook conste o nome da pessoa respons avel pelas modicac o
19/46
atrav Uma forma mais automatizada de fazer isso e es do uso de ferramentas de controle de vers ao como o RCS (http://www.cs.purdue.edu/homes/trinkle/RCS/) e o CVS (http://www.cvshome.org). Es o, de forma a possibilitar a sas ferramentas tamb em permitem manter um hist orico de arquivos de congurac a o de antigas vers recuperac a oes desses arquivos. Recomenda-se que, sempre que poss vel, este tipo de ferramenta seja usado em sistemas que possuam m ultiplos administradores. 4.3.3 Uso de Contas Privilegiadas a diculdade de se manter um registro Um problema que surge em sistemas com m ultiplos administradores e do uso de contas privilegiadas, tais como root e Administrator. Sempre que poss vel, estas contas n ao devem ser usadas diretamente. Um administrador deve entrar no sistema usando sua conta pessoal e a partir dela realizar suas tarefas, usando os privil egios mais elevados realizado atrav apenas quando estritamente necess ario. Em sistemas Unix, isso e es do comando su. O su traz como benef cio 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 per odo. uma ferramenta que permite que o administrador do sisO sudo (http://www.courtesan.com/sudo/) e tema conceda a determinados usu arios a possibilidade de executar comandos predenidos como se eles fossem o desses comandos. O uso do sudo reduz root (ou outro usu ario), registrando nos logs do sistema a utilizac a a necessidade de compartilhamento da senha de root, uma vez que os usu arios entram com sua pr opria senha para utilizar os comandos dispon veis atrav es dele. Isso pode ser usado, por exemplo, quando existem contas o de backups ou para invocar o procedimento de desligamento do de operador que s ao usadas para a realizac a sistema. extremamente congur o de grupos de usu O sudo e avel, possibilitando, entre outros recursos, a denic a a es por host ou grupo de hosts (permitindo que o mesmo arquivo rios, de comandos e de hosts e o uso de restric o o seja usado em sistemas diferentes). de congurac a IMPORTANTE: o uso de uma conta administrativa unica com senha compartilhada, que n ao permita determinar qual dos administradores acessou o sistema, deve ser evitado ao m aximo.
4.4
Logs
o segura de sistemas, pois registram informac es sobre o Logs s ao muito importantes para a administrac a o nico recurso que um seu funcionamento e sobre eventos por eles detectados. Muitas vezes, os logs s ao o u administrador possui para descobrir as causas de um problema ou comportamento an omalo. o de Logs 4.4.1 Gerac a teis para um administrador, eles devem estar com o hor Para que os logs de um sistema sejam u ario sin es cronizado via NTP, ser t ao detalhados quanto poss vel, sem no entanto gerar dados em excesso. Informac o teis s especialmente u ao aquelas relacionadas a eventos de rede, tais como conex oes externas e registros de o de servic utilizac a os (arquivos transferidos via FTP, acessos a p aginas Web, tentativas de login sem sucesso, avisos de disco cheio, etc.). es, e necess Para registrar estas informac o ario congurar o sistema da maneira apropriada. A forma de fazer o para descobrir como habilitar isto geralmente varia para cada componente espec co; consulte a documentac a es no seu sistema e em softwares espec o logging de informac o cos como rewalls e servidores HTTP.
20/46
4.4.2
Armazenamento de Logs
Armazenamento on-line a opc o Os logs s ao tradicionalmente armazenados em disco, no pr oprio sistema onde s ao gerados. Essa e a bvia, mas ela possui alguns riscos inerentes que devem ser compreendidos. mais o ` possibilidade dos logs serem destru O primeiro deles diz respeito a dos durante uma invas ao do sistema o de um (uma ocorr encia bastante comum). Em alguns sistemas, isso pode ser contornado atrav es da instalac a loghost centralizado. um sistema dedicado a ` coleta e ao armazenamento de logs de outros sistemas Um loghost centralizado e em uma rede, servindo como um reposit orio redundante de logs. Via de regra, o loghost n ao disponibiliza nenhum outro servic o, nem mesmo acesso remoto para os administradores, para minimizar a possibilidade de que eles facilitam a an que ele seja comprometido. Outra vantagem de loghosts centralizados e alise dos logs e o de eventos ocorridos em sistemas distintos. Sempre que poss correlac a vel, o uso de loghosts centralizados fortemente recomendado. e a possibilidade de um atacante usar o logging para executar um ataque de negac o de Um segundo risco e a servic o contra um determinado sistema, gerando eventos em excesso at e que o disco onde s ao armazenados ncia disto. Conforme discutido na sec o 3.2, o uso de uma os logs que cheio e o sistema trave em conseq ue a o separada para armazenar os logs pode minimizar o impacto deste problema. partic a o e a rotac o autom utilizado, deve-se Outro ponto que merece atenc a a atica de logs. Quando este recurso e garantir que os logs sejam movidos para o armazenamento off-line antes que eles sejam removidos do sistema o, evitando assim a perda de registros. Alguns sistemas trazem a rotac o autom pela rotac a a atica habilitada na o padr o e compat sua congurac a ao; ao instalar um destes sistemas, verique se esta congurac a vel com os seus procedimentos de backup e armazenamento off-line de logs. Armazenamento off-line Evidentemente, os logs n ao podem ser mantidos on-line por tempo indeterminado, pois acabam por consu transferir periodicamente os logs mir muito espac o em disco. A melhor estrat egia para resolver esta quest ao e do disco para dispositivos de armazenamento off-line, tais como ta, CD-R ou DVD-R. recomend E avel gerar um checksum criptogr aco (tal como MD5 ou SHA-1) dos logs que s ao armazenados 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 arios. Os logs armazenados off-line devem ser mantidos por um certo per odo de tempo, pois podem vir a ser ne o de incidentes de seguranc cess arios para ajudar na investigac a a descobertos posteriormente. O Comit e Gestor da Internet no Brasil recomenda que logs de conex oes de usu arios de provedores de acesso estejam dispon veis aconselh por pelo menos 3 anos (vide http://www.cg.org.br/acoes/desenvolvimento.htm). E avel que os demais logs sejam mantidos no m nimo por 6 meses. importante que os logs armazenados on-line sejam inclu E dos no procedimento de backup dos seus siste o 4.9). mas (backups s ao tratados na sec 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 importante que eles sejam monitorados com freq ncia para permitir que eventuais problemas sejam tanto, e ue
21/46
rapidamente identicados. Existem algumas pr aticas recomend aveis no que diz respeito ao monitoramento de logs: ` sua rotina de trabalho; incorpore o h abito de inspecionar os logs a fac a isso pelo menos uma vez por dia, mas tenha em mente que sistemas muito importantes ou que geram o podem precisar ter seus logs analisados com maior freq ncia; muita informac a ue procure investigar as causas de qualquer registro que lhe parec a incorreto ou an omalo, por mais insignicante que ele aparente ser; procure identicar o padr ao de comportamento normal dos seus sistemas, para poder encontrar eventuais anomalias com maior rapidez. Quando estiver analisando logs, voc e deve certicar-se do timezone usado para registrar o hor ario dos o adotada) registram eventos. Por exemplo, alguns softwares (como o Microsoft IIS, dependendo da congurac a eventos com a hora de Greenwich (GMT), e n ao com a hora local. O desconhecimento do timezone em que est ao os logs pode facilmente invalidar uma an alise e lev a-lo a conclus oes equivocadas. ` medida em que voc A e venha a adquirir pr atica com a an alise dos seus logs, voc e poder a escrever scripts ou teis, pequenos programas para auxili a-lo nesta tarefa, automatizando assim parte do processo. Estes scripts s ao u por exemplo, para pr e-processar os logs em busca de determinados conte udos, para eliminar conte udo repetitivo o de e para elaborar um resumo que pode ser enviado por email para o administrador do sistema. A eliminac a especialmente importante porque, padr oes relacionados a eventos considerados normais pelo administrador e al em de reduzir o volume de logs a serem analisados, pode evidenciar alguma atividade incomum. o e utilizar ferramentas que permitam monitorar logs em tempo real, como por exemplo o Uma outra opc a e especique um conjunto de padr oes swatch (http://swatch.sourceforge.net/). O swatch requer que voc es a serem tomadas quando um destes padr registrado nos logs. As ac es a serem monitorados e as ac o oes e o o registrada, noticar um determinado usu podem ser de diversos tipos, como exibir a informac a ario por email e o de comandos arbitr invocar um programa do sistema. A capacidade de execuc a arios do swatch torna-o muito atraente, pois permite, por exemplo, que sejam tomadas medidas como ltragem de um enderec o IP que gere determinado log e envio de uma mensagem de alerta para um telefone celular. Existem tamb em v arias ferramentas que tem por objetivo processar diversos formatos conhecidos de logs teis para o administrador. Uma grande lista dessas ferramentas, bem como muita e que podem ser bastante u o sobre monitorac o e an documentac a a alise de logs est a dispon vel em http://www.loganalysis.org/.
4.5
DNS
hoje um servic O DNS (Domain Name System) e o essencial para o funcionamento da Internet. Essa im` natureza das informac es que ele armazena, o tornam um dos alvos mais atraentes para port ancia, associada a o o adequada dos servidores DNS e crucial para aumentar a seguranc atacantes. Desse modo, uma congurac a a e colaborar para o bom funcionamento da rede. ` Internet est Servidores DNS expostos a ao sujeitos a uma s erie de riscos, dentre os quais destacam-se: es sens o atrav Vazamento de informac o veis sobre a rede da organizac a es de transfer encias de zonas DNS. es podem ajudar um atacante a identicar os pontos fracos da rede e a escolher futuros Essas informac o alvos.
22/46
es Ataques de envenenamento de cache (cache poisoning), que levam um servidor a armazenar informac o es podem ser usadas para comprometer a seguranc forjadas. Tais informac o a de clientes que fac am consultas a esse servidor. Comprometimento do servidor atrav es de vulnerabilidades no software de DNS, o que pode facilitar o. outras quebras de seguranc a no restante da rede da organizac a o apresenta os principais mecanismos usados para eliminar ou minimizar estas ameac Esta sec a as, trazendo es sobre a congurac o de DNS reverso. Informac es mais detalhadas podem ser obtitamb em recomendac o a o das no documento Securing an Internet Name Server, do CERT/CC (dispon vel em http://www.cert.org/ archive/pdf/dns.pdf) e nas refer encias do ap endice A.
o de Transfer 4.5.1 Limitac a encias de Zona Transfer encias de zona s ao usadas para que os servidores DNS escravos (secund arios) atualizem suas es sobre uma determinada zona DNS em relac o ao servidor mestre (prim informac o a ario) para essa zona. Res uma importante medida para evitar que atacantes tringir os enderec os que podem fazer transfer encias de zona e es detalhadas sobre a rede da organizac o, tais como enderec obtenham informac o a os de roteadores, servidores de correio eletr onico e outros servidores DNS. es de transfer As limitac o encias de zona devem ser aplicadas a todos os servidores com autoridade para um limitar as transfer dom nio, independente de eles serem mestres ou escravos. Um equ voco comum e encias de zona no servidor mestre e n ao faz e-lo nos servidores escravos. o de controles de Preferencialmente, as transfer encias de zona devem ser limitadas atrav es da congurac a feito no named.boot (BIND 4) ou named.conf acesso no software servidor DNS. No BIND, por exemplo, isso e o do seu software ou o suporte t (BIND 8 e 9). Consulte a documentac a ecnico do seu fornecedor para obter es sobre como limitar transfer informac o encias de zona da maneira mais apropriada. o err a de que a limitac o de transIMPORTANTE: uma concepc a onea, infelizmente bastante difundida, e a fer encias de zona deve ser feita ltrando o tr afego para a porta 53/TCP do servidor DNS. Como a porta 53/TCP usada na resoluc o de nomes, essa ltragem pode comprometer seriamente a funcionalidade do seu tamb em e a servic o de nomes.
o de Servidores 4.5.2 Separac a es principais. A primeira delas e a de disponibilizar informac es a Servidores DNS possuem duas func o o respeito de zonas sobre as quais possuem autoridade (caso dos servidores mestres e escravos para uma detero e a de resolver nomes para clientes na sua rede (neste caso, o servidor e dito minada zona). A segunda func a es. recursivo). Muitas vezes, o mesmo servidor desempenha ambas func o separar a func o de servidor com autoridade (mestre ou escravo) da func o Uma pr atica recomend avel e a a de servidor recursivo. Isso minimiza a ec acia de ataques de envenenamento de cache DNS. Na pr atica, essa o signica que os servidores que possuem autoridade para uma ou mais zonas respondem somente a separac a consultas relativas a essas zonas; por sua vez, os servidores recursivos n ao possuem autoridade sobre nenhuma zona DNS.
23/46
o e congurar os servidores DNS com autoridade em A forma mais simples de se fazer essa separac a m aquinas distintas dos servidores DNS recursivos. Alguns softwares servidores DNS podem ser congura o seja feita na mesma m a vers dos para permitir que essa separac a aquina; um exemplo e ao 9 do BIND, que implementa isso atrav es de vis oes (views).
4.5.3
Uso de Privil egios M nimos
Os softwares servidores de DNS est ao entre os alvos mais visados pelos atacantes, e j a foram respons aveis minimizar os por comprometimentos de seguranc a no passado. Dessa forma, uma medida recomend avel e executado. privil egios com os quais o software servidor DNS e poss Em ambientes Unix, muitas vezes e vel executar o servidor DNS em uma jaula chroot(). Vers oes mais recentes do BIND permitem tamb em que ele seja executado com permiss oes de um usu ario diferente de o do seu software ou o suporte t root. Consulte a documentac a ecnico do seu fornecedor para ver se uma dessas es pode ser utilizada. opc o
4.5.4
es Sens Cuidado com Informac o veis no DNS
es adicionais sobre os nomes O DNS oferece alguns tipos de registros de recursos que armazenam informac o de dom nio, tais como HINFO, TXT e WKS. Estes registros n ao s ao necess arios para o funcionamento correto o de nomes, sendo geralmente usados para facilitar a administrac o e a manutenc o da rede. da resoluc a a a discutido em maiores detalhes na sec o 4.11, informac es sobre congurac o de sistemas na Conforme e a o a sua rede devem ser consideradas sens veis, pois podem ser usadas por um atacante para facilitar o comprometimento desses sistemas (ajudando-o a identicar m aquinas com sistemas que possuam vulnerabilidades evitar registrar esse tipo de informac o no DNS. conhecidas, por exemplo). Em vista disso, o mais prudente e a o da rede, recomenda-se fortemenCaso voc e deseje usar estes tipos de registros para facilitar a administrac a es n ` sua rede. Isso pode ser conseguido te que essas informac o ao estejam dispon veis para usu arios externos a usando-se servidores DNS inacess veis externamente ou, para o BIND 9, atrav es do uso adequado de vis oes. o do administrador, consiste no fato de que o DNS pode Outro fator importante, e que requer a atenc a o da vers fornecer um registro que possibilite a obtenc a ao do servic o de DNS sendo executado, o que pode ser usado para determinar a vulnerabilidade/suscetibilidade do servic o a um dado ataque. Por exemplo, o BIND o atrav fornece esta informac a es de consultas do tipo version.bind. aconselh Portanto, e avel que o administrador verique se este tipo de registro pode ser fornecido por seu o uma ou mais das seguintes medidas: servic o de DNS e, ent ao, congure-o levando em considerac 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 espec cos, como da m aquina do administrador ou do pr oprio servidor de DNS (localhost); altere o conte udo da string enviada como resultado da consulta, para por exemplo uma string vazia (); gere registros de eventos (logs) para todas as consultas desta natureza.
24/46
4.5.5
DNS Reverso
a traduc o de nomes em enderec O uso mais freq uente do DNS e a os IP. Entretanto, ele tamb em permite chamado DNS reverso, e possibilita a descobrir o nome associado a um determinado enderec o IP. Isso e o do dom identicac a nio de origem de um enderec o IP. que Um DNS reverso mal congurado ou inexistente pode causar alguns transtornos. O primeiro deles e 3 muitos sites negam o acesso a usu arios com enderec os sem DNS reverso ou com o reverso incorreto. Em o do DNS dep o segundo lugar, erros na congurac a oem contra a compet encia t ecnica da equipe de administrac a de redes respons avel pelo dom nio, e isso pode vir a causar diculdades quando for necess ario interagir com equipes de outras redes. recomend E avel que voc e mantenha atualizado o DNS reverso dos enderec os sob sua responsabilidade. Em o do DNS reverso dos seus blocos pode ser delegada a ` sua rede, enquanto em outros alguns casos a administrac a quem e respons o seu provedor de backbone e avel pelo DNS reverso dos seus enderec os. Entre em contato com es sobre como atualizar o seu DNS reverso. o seu provedor de backbone para obter informac o
4.6
es de Contato Informac o
Existem na Internet alguns enderec os eletr onicos (emails) que s ao usados para entrar em contato com ` seguranc administradores quando se deseja comunicar determinadas ocorr encias relacionadas a a de suas redes es sejam v e sistemas. E extremamente importante que estas informac o alidas e estejam sempre atualizadas, es ser pois assim garante-se que estas comunicac o ao recebidas pela pessoa certa no menor espac o de tempo o poss vel, o que pode muitas vezes impedir um incidente de seguranc a ou limitar as conseq uencias. Esta sec a es e como voc mostra quais s ao essas informac o e deve proceder para atualiz a-las.
4.6.1 Enderec os Eletr onicos Padr ao erie de emails padr ao que devem existir em todas as redes e que podem ser A RFC 21424 dene uma s usados para contatar os seus respons aveis. Dentre os enderec os padr ao, existem dois que est ao relacionados com seguranc a: abuse e security. usado para reportar abusos de recursos na rede. O enderec O enderec o abuse e o security, por sua vez, e utilizado para comunicar incidentes e alertar sobre problemas de seguranc a. Mensagens enviadas para estes enderec os dever ao chegar at e os respons aveis por lidar com essas ocorr en necess cias. N ao e ario criar usu arios com estes nomes, basta que sejam congurados aliases redirecionando as mensagens enviadas a estes enderec os para os usu arios apropriados. Cabe observar que muitas vezes estes enderec os n ao s ao usados da maneira mais apropriada, com abuse es de incidentes de seguranc recebendo reclamac o a e security relatos de abusos, ou ambos os enderec os sendo o. Sendo assim, e importante que sua rede possua ambos os enderec usados na mesma noticac a os e que eles sejam constantemente monitorados pela sua equipe de seguranc a.
o e quando existe um nome para resolver um dado IP mas este mesmo nome n caso mais comum de incorrec a ao est a registrado em nenhum DNS direto, ou ent ao resolve para outro enderec o IP. Um exemplo disso seria o enderec o IP 192.0.2.34 resolver para 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. Dispon vel em http://www.ietf.org/rfc/rfc2142.txt.
3O
25/46
4.6.2
Contato no DNS
o no registro Cada dom nio registrado em um servidor DNS possui uma s erie de par ametros de congurac a o email do respons de SOA (Start of Authority). Um destes par ametros e avel pelo dom nio, que muitas vezes usado para comunicar problemas de seguranc tamb em e a envolvendo esse dom nio. Um exemplo de registro SOA para o dom nio example.org pode ser visto na gura 2. Nesta gura, ns. o nome do servidor DNS prim example.org e ario e joe.example.org representa o enderec o joe@example. org, que seria o enderec o de contato para o dom nio 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 enderec o do campo de SOA atualizado em todos os dom nios sob sua responsabilidade, incluindo os de DNS reverso. Se preferir, use um alias em vez de um email real. N ao se esquec a que o formato usu e ario.dom nio, e n ao usu ario@dom nio.
4.6.3
Contatos no WHOIS
es de contato que remetem Cada dom nio ou bloco de enderec os IP registrado possui uma lista de informac o ` s pessoas respons a aveis por estes dom nios ou blocos. Geralmente existem tr es tipos de contatos: o e operac o do dom contato t ecnico: respons avel t ecnico pela administrac a a nio ou bloco; contato administrativo: quem tem autoridade sobre o dom nio ou bloco; o contato de cobranc a: quem recebe correspond encias de cobranc a das despesas de registro e manutenc a do dom nio ou bloco. Os enderec os de email destes contatos devem estar sempre atualizados e ser v alidos. No caso do contato t ecnico, isso signica dizer que mensagens enviadas para este enderec o devem ser recebidas por um adminis o. trador de redes respons avel pelo bloco ou dom nio, e n ao por pessoal administrativo ou jur dico da organizac a usado com muita freq ncia para noticac o de incidentes de seguranc Este contato e ue a a e outros problemas com a infra-estrutura de rede envolvendo o dom nio ou bloco. es de contato s Estas informac o ao mantidas em uma base de dados chamada WHOIS. Esta base de dados e es sobre dom normalmente gerenciada por entidades que registram dom nios (informac o nios) e por provedores es sobre enderec es s de backbone (informac o os IP). No Brasil, estas informac o ao administradas e disponibilizadas pelo Registro .br (http://registro.br). o dos contatos no WHOIS varia de acordo com a entidade de registro ou proO procedimento de atualizac a es vedor de backbone. Entre em contato com a sua entidade de registro ou o seu provedor para obter informac o o. Para dom es sobre como detalhadas sobre como efetuar essa atualizac a nios registrados no Brasil, informac o atualizar os contatos est ao dispon veis em http://registro.br/faq/faq2.html.
26/46
4.7
o de Protocolos sem Criptograa Eliminac a
o de redes e a substituic o de protocolos onde Uma medida de seguranc a muito importante na operac a a o atrav n ao haja autenticac a es de senhas, ou onde senhas trafeguem em claro, por outros que corrijam estas o deve ser evitada na medida do poss deci encias. A lista de protocolos cuja utilizac a vel inclui: Telnet; FTP; POP3; IMAP; rlogin; rsh; rexec. o, al A maioria dos protocolos citados pode ser substitu da pelo SSH.5 Essa substituic a em de fazer com o da que o tr afego entre cliente e servidor passe a ser criptografado, traz ainda outras vantagens, como protec a sess ao contra ataques tipo man-in-the-middle e seq uestro de conex oes TCP. o ao POP3, existem diversas possibilidades de substituic o: Em relac a a o de usu 1. Usar uma das variantes do protocolo (APOP, KPOP, RPOP) que tornam a autenticac a arios mais o s segura, pois eliminam o tr afego de senhas em claro. As desvantagens desta opc a ao que nem todos es os clientes de email suportam estas variantes e o conte udo dos emails (que pode conter informac o criptografado. sens veis) n ao e o e interessante quando o servidor POP3 2. Usar POP3 atrav es de um t unel SSH ou SSL. A primeira opc a e o servidor SSH residem na mesma m aquina. Para a segunda, podem ser usadas ferramentas como o stunnel (http://stunnel.mirt.net). Alguns clientes de email j a suportam SSL diretamente, n ao sendo necess ario o uso de t uneis. o de Webmail sobre HTTPS (HTTP+SSL). Esta soluc o tamb v 3. Usar uma soluc a a em e alida para o IMAP.
4.8
Cuidados com Redes Reservadas
Existem alguns blocos de enderec os IP que s ao reservados pelo IANA (Internet Assigned Numbers Au nico que registre todos estes blocos; alguns thority) para prop ositos espec cos. N ao existe um documento u est ao documentados em RFCs, enquanto que outros s ao considerados reservados por raz oes de compatibilidade hist orica. arios blocos reservados pelo IANA. Uma lista dessas redes reservadas conhecidas e A RFC 33306 lista v mostrada na tabela 1, juntamente com um breve coment ario sobre a nalidade de cada rede.
5 Implementac es o 6 IANA,
de SSH para diversos sistemas operacionais est ao dispon veis em http://www.openssh.com. Special-Use IPv4 Addresses, RFC 3330, September 2002. Dispon vel 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 ario usada por sistemas antigos para broadcast loopback o TEST-NET; usada para exemplos em documentac a usada em redes privadas (RFC 1918) usada em redes privadas (RFC 1918) usada em redes privadas (RFC 1918) o (est usada para autocongurac a a relacionada ao protocolo DHCP) 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
que nem todo o espac Outro ponto importante e o de enderec amento IPv4 est a atualmente alocado. Uma mantida em http://www.iana.org/ lista dessas redes n ao alocadas, e portanto reservadas para o IANA, e frequentemente atualizada e e recomend assignments/ipv4-address-space. Esta lista e avel que seja consultada regularmente. Enderec os n ao alocados e pertencentes a blocos reservados n ao devem ser propagados atrav es da Internet, sendo recomendada a sua ltragem no per metro da sua rede, tanto para entrada quanto para sa da. Caso voc e possua redes privadas com IPs reservados, certique-se de que os enderec os utilizados sejam os 7 especicados na RFC 1918 (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16). Enderec os reservados n ao devem estar associados a nomes em servidores DNS p ublicos. Se voc e utiliz a-los em redes privadas e quiser usar nomes para as m aquinas, congure um servidor DNS privado ou utilize tabelas de hosts (/etc/hosts ou C:\WINDOWS\HOSTS). Caso voc e detecte um ataque proveniente de uma das redes da tabela 1 e estes enderec os estiverem sendo ltrados no per metro, os pacotes correspondentes s o podem ter partido de dentro da sua pr opria rede. A causa a exist o que fazem com que os enderec mais freq uente para isso e encia de erros de congurac a os reservados vazem de uma ou mais de suas redes privadas. Logo, deve-se procurar internamente a causa do problema em a entidade listada nos contatos de WHOIS para estes blocos). vez de tentar contactar o IANA (que e
4.9
o de Sistemas Pol ticas de Backup e Restaurac a
o de sistemas nunca pode ser minimizada. Sem eles, muitos A import ancia dos backups na administrac a dados s ao simplesmente irrecuper aveis caso sejam perdidos devido a uma falha acidental ou a uma invas ao. o dos seus sistemas e seguir uma pol Os backups devem fazer parte da rotina de operac a tica determinada. faz O melhor e e-los da forma mais automatizada poss vel, de modo a reduzir o seu impacto sobre o trabalho dos administradores e operadores de sistemas. ncia inclui: A lista de itens cujo backup deve ser feito com freq ue dados;
Rekhter et.al., Address Allocation for Private Internets, RFC 1918, February 1996. Dispon vel em http://www.ietf.org/ rfc/rfc1918.txt.
7 Y.
28/46
o; arquivos de congurac a logs. o backup de bin Um ponto que merece especial cuidado e arios (execut aveis e bibliotecas), que geralmente o a essa regra e uma c o, deve ser evitado. Uma excec a opia completa do sistema logo ap os a sua instalac a antes que ele seja colocado em rede. Backups que incluem bin arios n ao s ao aconselh aveis porque abrem a o possibilidade de que eventuais Cavalos de Tr oia ou execut aveis corrompidos sejam reinstalados na restaurac a do sistema. o ao local onde s Alguns cuidados devem ser tomados em relac a ao guardados os backups: o acesso ao local deve ser restrito, para evitar que pessoas n ao autorizadas roubem ou destruam backups; o local deve ser protegido contra agentes nocivos naturais (poeira, calor, umidade); aconselh ` prova de fogo. se poss vel, e avel que o local seja tamb em a o e, posteriormente, em intervalos regulares. Isto Os backups devem ser vericados logo ap os a sua gerac a possibilita a descoberta de defeitos em dispositivos e meios de armazenamento e pode evitar que dados sejam perdidos por problemas com backups que n ao podem ser restaurados. es providenciam meios para armazenar backups fora das suas instalac es, como em Algumas organizac o o uma boa maneira de garantir a disponibilidade dos backups em caso de cofres de bancos, por exemplo. Essa e es. Entretanto, isso pode comprometer a condencialidade e integridade desses backproblemas nas instalac o o e criptografar o backup e gerar um checksum (MD5 ou SHA-1, por exemplo) dele ups. Uma poss vel soluc a o. Uma vericac o do checksum antes da restaurac o antes que seja entregue a pessoas de fora da organizac a a a pode servir como prova de que o backup n ao foi alterado desde que foi feito. Quando for necess ario restaurar um sistema, isto deve ser feito com a m aquina isolada da rede. Caso o o ap o para certicar-se de sistema em quest ao tenha sido comprometido, revise a sua congurac a os a restaurac a que n ao tenha cado nenhuma porta de entrada previamente instalada pelo invasor.
4.10
Como Manter-se Informado
es de forma Administradores envolvidos com a seguranc a de redes e sistemas necessitam buscar informac o o a novas vulnerabilidades e correc es de seguranc ` sua natureza a se manterem atualizados em relac a o a. Devido a o de tais informac es e a pr din amica, o principal meio de obtenc a o opria Internet, atrav es de listas de discuss ao por email e sites especializados. Os tipos mais indicados de listas de discuss ao para um administrador incluem: lista de an uncios de seguranc a de fornecedores de software e hardware cujos produtos s ao usados na sua rede; listas de administradores e/ou usu arios desses produtos; lista de alertas de seguranc a do CERT/CC.8
8 Veja
http://www.cert.org/contact_cert/certmaillist.html.
29/46
Destas, as listas de an uncios de seguranc a de fornecedores e a lista de alertas do CERT/CC s ao fortemente recomendadas a qualquer administrador. As listas destinadas a administradores e usu arios de produtos, por sua vez, podem ajud a-lo a conhecer melhor as ferramentas dispon veis no seu ambiente computacional, muitas vezes levando-o a descobrir formas mais ecientes de trabalhar com elas.9 Existem outras listas que s ao indicadas para administradores que possuam alguma experi encia e bons co o. Essas listas costumam ter um alto tr nhecimentos de programac a afego e o conte udo das suas discuss oes bastante t e ecnico, muitas vezes envolvendo o uso de conceitos avanc ados. A principal (e tamb em a mais a Bugtraq.10 conhecida) destas listas e es atualizadas na a rea de seguranc A Web tamb em oferece boas fontes de informac o a, tais como: http://www.cert.org/advisories/; http://www.cert.org/current/current_activity.html; http://online.securityfocus.com/; http://www.incidents.org/. recomend es relacionadas IMPORTANTE: e avel que voc e tome cuidado com a proced encia de informac o es proposicom seguranc a, procurando se restringir a fontes con aveis. Existem diversos relatos de informac o talmente erradas terem sido divulgadas com o objetivo de abrir brechas na seguranc a da rede daqueles que as tenham seguido.
4.11
es contra Engenharia Social Precauc o
a t es que Engenharia social e ecnica (ou arte) de aproveitar-se da boa f e de pessoas para obter informac o o por parte de usu possibilitem ou facilitem o acesso aos recursos computacionais de uma organizac a arios n ao es procuradas destacam-se as seguintes: autorizados. Dentre as informac o senhas de acesso; topologia da rede; enderec os IP em uso; nomes de hosts em uso; listas de usu arios; tipos e vers oes de sistemas operacionais usados; tipos e vers oes de servic os de rede usados; o. dados sigilosos sobre produtos e processos da organizac a Existem diversas formas de se efetuar um ataque de engenharia social, mas todas elas t em em comum a caracter stica de usarem basicamente psicologia e perspic acia para atingir os seus prop ositos. Atualmente, as mais populares s ao:
9A 10 Veja
o 4.11 mostra alguns cuidados que devem ser tomados por quem utiliza listas de discuss sec a ao por email. http://online.securityfocus.com/.
30/46
usar telefone ou email para se fazer passar por uma pessoa (geralmente algu em da equipe de suporte es para resolver um t ecnico ou um superior da pessoa atacada) que precisa de determinadas informac o suposto problema; es divulgadas em um f aproveitar informac o orum p ublico da Internet (lista de discuss ao por email, newsgroup, IRC) por um administrador ou usu ario que busca ajuda para resolver algum problema na rede; es especialmente preparadas para um administrador ou usu enviar programas maliciosos ou instruc o ario, es poss com o objetivo de abrir brechas na seguranc a da rede ou coletar o m aximo de informac o vel sobre particularmente ecaz quando a pessoa pede aux ela (esta t ecnica e lio em algum f orum de discuss ao pela Internet); es u teismuitas vezes e poss navegar por websites ou reposit orios FTP em busca de informac o vel en es detalhadas da infra-estrutura computacional e/ou documentos que, por descuido ou contrar descric o esquecimento, n ao foram removidos do servidor. orientando os usu o 4.1) e administraA principal maneira de se prevenir contra estes ataques e arios (sec a es. A pol o (sec o 2.1) dores de redes e sistemas sobre como agir nestas situac o tica de seguranc a da organizac a a nela que s o da desempenha um papel importante neste sentido, pois e ao denidas as normas para protec a o na organizac o. informac a a Recomenda-se fortemente que os administradores tenham cuidado ao buscar ajuda em listas de discuss ao e o de problemas, mas tamb outros f oruns na Internet. Estes recursos podem ser valiosos na resoluc a em podem es. ser usados por terceiros para coleta de informac o o da sua rede em f Procure reduzir a exposic a oruns p ublicospor exemplo, use enderec os IP, nomes de hosts e usu arios hipot eticos, e tente n ao revelar mais sobre a topologia da rede do que o estritamente necess ario es passadas por pessoas desconhecidas, e evite para resolver um dado problema. Tome cuidado com orientac o executar programas de origem obscura ou n ao con aveleles podem ser uma armadilha.
31/46
4.12 Uso Ecaz de Firewalls

importante denir o que um rewall Antes de apresentar t ecnicas para aumentar a ec acia de rewalls, e e o que ele n . Um rewall bem congurado e um instrumento importante para implantar a pol e ao e tica o dispon de seguranc a da sua rede. Ele pode reduzir a informac a vel externamente sobre a sua rede, ou, em alguns casos, at e mesmo barrar ataques a vulnerabilidades ainda n ao divulgadas publicamente (e para as quais es n correc o ao est ao dispon veis). o de um rewall n Por outro lado, rewalls n ao s ao infal veis. A simples instalac a ao garante que sua nica linha de defesa; ele e mais um rede esteja segura contra invasores. Um rewall n ao pode ser a sua u dentre os diversos mecanismos e procedimentos que aumentam a seguranc a de uma rede. o dos rewalls e que eles protegem apenas contra ataques externos ao rewall, nada podendo Outra limitac a fazer contra ataques que partem de dentro da rede por ele protegida. o apresenta apenas alguns aspectos importantes da utilizac o de rewalls. Maiores informac es Esta sec a a o encias do ap endice A. podem ser obtidas em http://www.interhack.net/pubs/fwfaq/ e nas refer
4.12.1 A Escolha de um Firewall es de rewall dispon Existem diversas soluc o veis no mercado. A escolha de uma delas est a atrelada a fatores a familiaridade com a plataforma como custo, recursos desejados e exibilidade, mas um ponto essencial e operacional do rewall. A maioria dos rewalls est a dispon vel para um conjunto reduzido de plataformas operacionais, e a sua escolha deve se restringir a um dos produtos que roda sobre uma plataforma com a qual os administradores da rede tenham experi encia. Por exemplo, se voc e utiliza basicamente servidores Unix, e aconselh avel que voc e escolha um rewall que rode sobre a sua variante favorita de Unix, e n ao um produto que requeira Windows NT. o. A primeira delas e que voc Existem, basicamente, duas raz oes para esta recomendac a e deve estar familiarizado o suciente com o sistema onde o rewall ser a executado para congur a-lo de forma segura. A exist encia de um rewall instalado em um sistema inseguro pode ser at e mais perigosa do que a aus encia do que os produtos tendem a seguir a losoa da plataforma onde rodam; por rewall na rede. A segunda raz ao e congurada atrav exemplo, a maioria dos rewalls para Windows e es de menus e janelas, ao passo que muitos rewalls para Unix s ao congurados por meio de arquivos texto. Outro fator importante consiste na escolha do tipo de rewall que ser a implementado. Dentre os tipos atualmente dispon veis, 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 aveis ou fazerem parte do kernel de diversos sistemas operacionais. es colhidas nos cabec Os ltros de pacotes normalmente analisam informac o alhos de cada pacote, tais como enderec os IP de origem e destino, protocolo utilizado, portas, e s ao basicamente divididos em duas categorias: os est aticos (stateless) e os din amicos (stateful). Os ltros est aticos s ao projetados para tomar decis oes (como bloquear ou permitir) para cada pacote que entra ou sai de uma rede, sem considerar o contexto em que cada pacote est a inserido. Portanto, neste caso e preciso estabelecer regras, de forma expl cita, tanto para o tr afego que entra na rede quanto para o tr afego que sai (incluindo o tr afego de resposta a conex oes iniciadas externamente). J a os ltros din amicos rastreiam e mant em o estado das conex oes contidas no tr afego de rede, fazendo com que cada pacote seja analisado dentro de um contexto (conex ao que cont em o pacote). Este tipo de ltro de
32/46
pacotes normalmente apresenta um melhor desempenho e permite que os dois sentidos de tr afego (entrada e gerenciado automatisa da) sejam considerados/tratados separadamente, uma vez que o tr afego de resposta e camente, simplicando assim o conjunto de regras a ser mantido e muitas vezes aumentando a qualidade da ltragem. ` disposic o diversas ferramentas de software livre que podem Administradores experientes em Unix t em a a 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 ao modestos. Ferramenta
ipchains iptables ipfw pf iplter TIS Firewall Toolkit Squid
Plataforma Linux Linux FreeBSD OpenBSD v arios Unix v arios Unix v arios Unix
Caracter stica ltro de pacotes (stateless) ltro de pacotes (stateful) ltro de pacotes (stateful) ltro de pacotes (stateful) ltro de pacotes (stateful) proxy para v arios protocolos proxy Web/FTP
o de rewalls Tabela 2: Ferramentas de software livre para a construc a
4.12.2
o dos Firewalls Localizac a
o dos rewalls na rede depende normalmente da sua pol A localizac a tica de seguranc a. Entretanto, existem ` grande maioria dos casos: algumas regras que se aplicam a Todo o tr afego deve passar pelo rewall. Um rewall s o pode atuar sobre o tr afego que passa por ele. A ec acia de um rewall pode ser severamente comprometida se existirem rotas alternativas para dentro da rede (modems, por exemplo). Caso n ao seja poss vel eliminar todas esses caminhos, eles devem ser documentados e fortemente vigiados atrav es de outros mecanismos de seguranc a. Tenha um ltro de pacotes no per metro da sua rede. Esse ltro pode estar localizado entre o seu roteador de borda e o interior da rede ou no pr oprio roteador, se ele tiver esta capacidade e voc e se sentir importante para tarefas como confort avel utilizando-o para esta tarefa. O ltro de pacotes de borda e o 4.12.3) e bloqueio r bloqueio global de alguns tipos de tr afego (vide sec a apido de servic os durante a o de correc es ap implantac a o os a descoberta de uma nova vulnerabilidade. recomend Coloque os servidores externos em uma DMZ. E avel que voc e coloque os seus servidores acess veis externamente (Web, FTP, correio eletr onico, etc.) em um segmento de rede separado e com acesso altamente restrito, conhecido como DMZ (DeMilitarized Zone, ou zona desmilitarizada). A prin proteger a rede interna contra ataques provenientes dos servidores externos cipal import ancia disso e o contra a eventualidade de que um destes servidores seja comprometido. Por exemplo, uma precauc a 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 es condenciais) e muito maior do que se ele estiver em uma rede isolada. informac o poss Considere o uso de rewalls internos. Em alguns casos, e vel identicar na rede interna grupos de sistemas que desempenham determinadas tarefas comuns, tais como desenvolvimento de software, o nanceira. Nestes casos, recomenda-se o uso de rewalls internos para isolar webdesign e administrac a o dos sistemas internos e conter estas sub-redes umas das outras, com o prop osito de aumentar a protec a o de ataques bem-sucedidos. a propagac a
33/46
4.12.3
Crit erios de Filtragem
o Existem basicamente dois crit erios de ltragem que podem ser empregados em rewalls. O primeiro e bloqueado. O segundo, default de default deny, ou seja, todo o tr afego que n ao for explicitamente permitido e o contr liberado. allow, e ario, ou seja, todo o tr afego que n ao for explicitamente proibido e o dos rewalls deve seguir a pol recoA congurac a tica de seguranc a da rede. Se a pol tica permitir, e , geralmente, mais segura, pois requer uma mend avel adotar uma postura de default deny. Esta abordagem e o expl intervenc a cita do administrador para liberar o tr afego desejado, o que minimiza o impacto de eventuais o na seguranc o dos rewalls. erros de congurac a a da rede. Al em disso, ela tende a simplicar a congurac a No per metro da rede, pelo menos as seguintes categorias de tr afego devem ser ltradas: tr afego de entrada (ingress ltering): pacotes com enderec o de origem pertencente a uma rede reservada o 4.8) ou a um dos blocos de enderec (sec a os da sua rede interna; tr afego de sa da (egress ltering): pacotes com enderec o de origem pertencente a uma rede reservada ou que n ao fac a parte de um dos blocos de enderec os da rede interna. a ltragem do protocolo ICMP. O bloqueio indisUm aspecto que deve ser considerado com cuidado e criminado de ICMP pode prejudicar o funcionamento da rede. Por outro lado, o ICMP pode ser usado para es sobre a rede e seus sistemas. Observe que muitos rewalls do tipo revelar a um poss vel atacante informac o stateful permitem a passagem de mensagens ICMP de erro associadas a conex oes estabelecidas, o que minimiza o impacto da ltragem. nicas conex O tr afego para a DMZ deve ser altamente controlado. As u oes permitidas para os sistemas dentro da DMZ devem ser as relativas aos servic os p ublicos (acess veis externamente). Conex oes partindo da DMZ para a rede interna devem ser, na sua maioria, tratadas como conex oes oriundas da rede externa, aplicando-se a pol tica de ltragem correspondente.
IMPORTANTE: a DMZ e a rede interna n ao podem estar no mesmo segmento de rede (ligadas ao mesmo
imprescind hub ou switch, por exemplo). E vel que estas redes estejam em segmentos de rede separados.
4.12.4
Exemplos
o de rewalls em uma rede. A opc o por uma Diversas arquiteturas podem ser empregadas para a implantac a a delas obedece a uma s erie de fatores, incluindo a estrutura l ogica da rede a ser protegida, custo, funcionalidades pretendidas e requisitos tecnol ogicos dos rewalls. o apresenta duas destas arquiteturas. A intenc o n cobrir todas as possibilidades de uso de Esta sec a a ao e rewalls, mas fornecer exemplos de arquiteturas que funcionam e que podem eventualmente ser adotados (na es) em situac es reais. sua forma original ou ap os passarem por adaptac o o A gura 3 mostra um exemplo simples de uso de rewall. Neste exemplo, o rewall possui tr es interfaces de rede: uma para a rede externa, uma para a rede interna e outra para a DMZ. Por default, este rewall bloqueia do tipo stateful, tudo o que n ao for explicitamente permitido (default deny). Al em disso, o rewall usado e que gera dinamicamente regras que permitam a entrada de respostas das conex oes iniciadas na rede interna; preciso incluir na congurac o do rewall regras de entrada para estas respostas. portanto, n ao e a o seguinte: O tr afego liberado no exemplo da gura 3 e
34/46
Internet
WWW
DMZ FW DNS
SMTP
Rede Interna
Figura 3: Um exemplo simples de rewall interface externa: o de sa da: tudo com excec a pacotes com enderec os de origem pertencentes a redes reservadas; pacotes com enderec os de origem n ao pertencentes aos blocos da rede interna. ` s seguintes combinac es de protocolo, enderec entrada: apenas os pacotes que obedecem a o o 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: sa da: tudo; entrada: nada; interface da DMZ: sa da: portas 25/TCP (SMTP), 53/UDP e 53/TCP (DNS) e 113 (IDENT); permitido o tr entrada: al em das mesmas regras de entrada da interface externa, tamb em e afego para todos os servidores na com porta de destino 22/TCP (SSH) e enderec o de origem na rede interna. o mais complexa do que a anterior. Neste segundo A gura 4 ilustra o uso de rewalls em uma situac a exemplo, al em dos servidores externos na DMZ, h a tamb em servidores na intranet e no setor nanceiro da o. Devido a ` import es mantidas neste setor, a sua rede conta com a protec o organizac a ancia das informac o a evitar que usu ` rede interna da adicional de um rewall interno, cujo objetivo principal e arios com acesso 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 o (mas n ` rede do setor nanceiro) possam comprometer a integridade e/ou o sigilo dessas organizac a ao a es. informac o o do rewall externo neste segundo exemplo e quase id A congurac a entica ao primeiro. Entretanto, no presente caso sup oe-se que o servidor SMTP vis vel externamente (o da DMZ) repassa as mensagens recebidas necess para o servidor SMTP da intranet. Para que isso seja poss vel, e ario mudar a regra de ltragem para a interface interna, liberando o tr afego do servidor SMTP da DMZ para a porta 25/TCP do servidor SMTP da intranet. o do rewall interno, por sua vez, e bastante simples. O servidor da rede do setor nanceiro A congurac a o possam consultar seus contrachepermite apenas acesso via HTTPS para que os funcion arios da organizac a o seguinte: ques; outros tipos de acesso n ao s ao permitidos. O tr afego liberado por este rewall e interface externa (rede interna): sa da: tudo; entrada: apenas pacotes para o servidor do setor nanceiro com porta de destino 443/TCP (HTTPS) e enderec o de origem na rede interna; interface interna (rede do setor nanceiro): sa da: tudo; feita na interface externa). entrada: tudo (a ltragem e
36/46
4.13 Redes Wireless

Redes wireless, tamb em conhecidas como IEEE 802.11, Wi-Fi ou WLANs, tornaram-se muito populares ltimos tempos. Embora sejam muito convenientes, sua instalac o e operac o requerem atenc o do ponto nos u a a a de vista de seguranc a. o mostra alguns cuidados que devem ser tomados pelos administradores na instalac o e operac o Essa sec a a a segura destas redes.
4.13.1
Pol tica de Uso da Rede Wireless
muito importante que seja denida uma pol E tica de uso da rede wireless, que deve ser incorporada na o, discutida na sec o 2. Esta pol pol tica de seguranc a da instituic a a tica deve cobrir pelo menos os seguintes itens: o. A instalac o denir quem est a autorizado a instalar Access Points (APs) nas depend encias da instituic a a es listadas nas sec es 4.13.2 e 4.13.4, pode comprode APs por pessoal n ao autorizado, sem as precauc o o meter seriamente a seguranc a de toda rede; o; denir quem est a autorizado a utilizar a rede wireless da instituic a es a serem tomadas em caso de roubo ou perda de equipamentos wireless; prever as ac o o pode transitar pela rede; denir que tipo de informac a es m descrever as congurac o nimas de seguranc a para APs, clientes, etc.
4.13.2
Topologia
Dois fatores muito importantes devem ser considerados ao denir a topologia de uma rede wireless: o o. posicionamento do AP e a necessidade de isolar esta rede da rede interna da instituic a o ao posicionamento do AP, dependendo da pot Com relac a encia de sua antena, uma rede wireless pode o, o que pode facilitar o uso e a escuta n ter um alcance que ultrapasse os limites geogr acos da instituic a ao extremamente comum e deve servir de est autorizadas. Esse vazamento de sinal e mulo para o administrador o e criptograa, discutidas na sec o 4.13.3. implementar medidas como o uso de autenticac a a Al em do uso de criptograa, um posicionamento cuidadoso dos APs (mais para o centro de um pr edio, longe de janelas, etc.) pode minimizar o vazamento desnecess ario de sinal. E importante notar que esse procedimento deve ser encarado apenas como uma camada adicional de seguranc a, uma vez que um atacante interessado em o pode fazer uso de uma antena amplicadora de sinal e ter acesso a ` sua rede wireless mesmo a sua instituic a dist ancias maiores. o ao isolamento da rede wireless da rede interna da instituic o deve-se ter em mente que as redes Com relac a a 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 ` instalac o de um modem dentro dessa rede, por exemplo. a a
37/46
o de topologia pode ser colocar todos os APs em um segmento de rede pr Uma soluc a oprio e colocar um o. Al rewall entre esse segmento e o resto da infra-estrutura de rede da instituic a em de possibilitar o controle o, ainda prov o com VPNs. de utilizac a e uma boa possibilidade de integrac a prefer Por m, e vel conectar um AP a um switch, n ao a um hub. O tr afego de rede em um hub pode ser potencialmente enviado para toda a rede wireless e eventualmente ser interceptado por algum cliente. 4.13.3 o Criptograa e Autenticac a
` facilidade com que uma rede wireless pode ser utilizada por pessoas n ` facilidade Devido a ao autorizadas e a extremamente importante o uso de criptograa e de mecanismos de com que se pode capturar o tr afego, e o numa rede wireless. autenticac a o do cliente wireless: open authenO padr ao 802.11 originalmente suporta apenas dois tipos de autenticac a tication e shared-key authentication. No primeiro modo o cliente precisa apenas fornecer o SSID (Service ` rede. No modo shared-key authentication e preciso o conhecimento de Set Identier) correto para juntar-se a importante notar que essa autenticac o e uma chave WEP (Wired Equivalent Privacy) para que isso ocorra. E a do dispositivo wireless, e n ao dos usu arios da rede. O padr ao 802.11 dene o protocolo WEP como mecanismo para cifrar o tr afego entre os APs e os clientes wireless. Essa cifragem ocorre na camada de enlace e exige que todos os participantes compartilhem a mesma recomend chave WEP est atica. O WEP possui diversas fragilidades, mas apesar disso seu uso e avel e deve ser encarado como uma camada adicional de seguranc a. Para aumentar a seguranc a de sua rede wireless deve-se escolher o maior tamanho de chave WEP poss vel, es padr sendo essencial trocar as chaves WEP que venham nas congurac o ao dos equipamentos. O uso de es, como SSH e SSL, tamb recomend criptograa nas aplicac o em e avel para minimizar os riscos de escuta n ao autorizada. Al em disso tamb em deve ser considerado o uso de criptograa no pr oprio TCP/IP, como IPsec e o uso de VPNs em geral. Salvo algumas extens oes implementadas por alguns fabricantes, o protocolo 802.11 original apresenta alguns problemas: fragilidade do protocolo WEP; problemas de gerenciamento das chaves WEP, que devem ser trocadas manualmente; o dos usu falta de autenticac a arios da rede. o de novos padr Existem v arias iniciativas para a criac a oes que aperfeic oem a seguranc a do protocolo, sendo recomend avel que sejam utilizados assim que estiverem dispon veis. Entre eles, pode-se citar: o e distribuic o de chaves atrav IEEE 802.1x, que suporta autenticac a a es da consulta a um servidor de o; autenticac a WAP (Wi-Fi Protected Access), desenvolvido em conjunto pela Wi-Fi Alliance e IEEE, que prov e algumas melhorias criptogr acas, como o uso do protocolo TKIP (Temporal Key Integrity Protocol). Tamb em o de usu prov e suporte para autenticac a arios via 802.1x e EAP (Extensible Authentication Protocol); IEEE 802.11i, sendo desenvolvido pelo IEEE 802.11 Task Group i (TGi), que inclui uma nova vers ao o de um framework de de WEP utilizando AES (Advanced Encryption Standard), al em da denic a o de chaves. distribuic a
38/46
4.13.4 Access Points o de um AP: Existem v arias quest oes importantes que devem ser consideradas na escolha e congurac a es na escolha: na escolha de um modelo de AP e muito importante determinar quais recursos de Considerac o o s o 4.13.3. Outro fator importancriptograa e autenticac a ao suportados, conforme discutido na sec a saber se o AP possibilita upgrades de rmware, permitindo incorporar novos padr te e oes e eventuais es lanc correc o adas pelo fabricante. o de congurac es padr es de f Alterac a o ao: muitos modelos de APs v em com congurac o abrica que s ao de extremamente importante que todas as congurac es conhecimento p ublico, incluindo senhas default. E o o, incluindo: originais sejam mudadas pelo administrador antes de colocar o AP em produc a o11 ; senhas de administrac a SSID; chaves WEP; SNMP communities. o de reset f es IMPORTANTE: alguns APs possuem uma opc a sico que faz com que todas as congurac o muito importante que o AP que em um local com acesso de f abrica sejam recarregadas. Nesses casos, e f sico controlado. o: a maioria dos APs permite v o: HTTP, SNMP, Telnet, Modos de congurac a arios12 meios de congurac a importante desabilitar os que n etc. Sempre que poss vel, e ao forem necess arios e optar por um modo de o que n congurac a ao seja pela pr opria rede wireless, mas sim pela rede cabeada ou ainda via conex ao o com o AP seja capturada por algum serial. Isso minimiza as chances de que a sess ao de congurac a cliente wireless. o u til e desabilitar o broadcast de SSID pelo AP. Embora seja uma Broadcast de SSID: uma recomendac a medida simples, pode dicultar o uso de alguns programas populares de mapeamento de redes wireless. Filtragem por enderec o MAC: alguns APs possuem o recurso de ltragem de clientes wireless por enderec o MAC. Embora enderec os MAC possam ser forjados e muitas vezes n ao seja pr atico manter uma lista de enderec os MAC dos clientes autorizados (e em alguns casos invi avel, como em confer encias), o administrador pode considerar o uso desse recurso como uma camada adicional de seguranc a do seu ambiente wireless. ltima considerac o diz respeito a ` possibilidade de desligar o AP quando n Uma u a ao estiver sendo utilizado, conforme especicado na sua pol tica de uso.
4.13.5
o aos Clientes Wireless Protec a
o 4.1, a educac o dos usu importante e eles tamb o Como descrito na sec a a arios e em devem receber orientac a o segura de redes wireless. sobre a utilizac a Uma rede wireless deve ser considerada uma rede p ublica e, portanto, mais suscet vel a ataques. Desse recomend es de trabalho, etc, passem modo, e avel que os clientes dessa rede, tais como notebooks, PDAs, estac o o e congurac o que vise o aumento de sua seguranc por um processo de instalac a a a, incluindo:
11 dicas 12 inclusive
o 3.4. para a escolha de boas senhas podem ser obtidas na sec a o caso de TFTP, habilitados por alguns fabricantes sem serem documentados. alguns modos, como e
39/46
o de patches; aplicac a uso de rewall pessoal; o e atualizac o de antiv instalac a a rus; desligamento do compartilhamento de disco, impressora, etc.
4.13.6
o da Rede Wireless Monitorac a
Da mesma forma que muitos administradores monitoram o seu ambiente de rede convencional (com o uso o da rede wireless tamb importante. Essa monitorac o pode detectar: de IDSs, por exemplo), a monitorac a em e a clientes conectados em um dado instante (em hor arios improv aveis ou simplesmente para acompanhamento); o de APs n instalac a ao autorizados; dispositivos que n ao estejam usando WEP; ataques contra os clientes wireless; acessos n ao autorizados; mudanc as de enderec os MAC; mudanc as de canal; DoS ou jamming.
40/46
A
A.1
Refer encias Adicionais

URLs de Interesse
A Case-Study in Best Practice for Operating System Management. http://www.sage-ie.org/slides/case_study/. P agina que cont em um estudo de caso sobre boas pr aticas no gerenciamento de sistemas ope o, racionais. Apresenta, de forma exemplicada, uma metodologia adotada para a instalac a o e administrac o de sistemas operacionais em um grande ambiente de rede. congurac a a Cartilha de Seguranc a para Internet. http://www.nbso.nic.br/docs/cartilha/. P agina a partir da qual pode ser obtida a vers ao mais recente do documento Cartilha de Seguranc a para Internet, do gloss ario e checklist que o acompanham. Este documento tem por nalidade sanar algumas d uvidas comuns sobre seguranc a de computadores e redes, e e dirigido aos usu arios de redes e Internet. Recomenda-se que administradores de redes utilizem o dos seus usu os documentos que comp oem a Cartilha no processo de educac a arios. CERT Security Improvement Modules: Security Knowledge in Practice. http://www.cert.org/ security-improvement/skip.html. o de uma rede mais Apresenta, de forma gr aca, os passos que est ao envolvidos na obtenc a segura. Cont em uma grande quantidade de material que aborda de forma mais aprofundada v arios dos assuntos discutidos neste documento. NIST SP 800-48, Wireless Network Security 802.11, Bluetooth and Handheld Devices. http://csrc. nist.gov/publications/drafts/draft-sp800-48.pdf es detalhadas sobre seguranc Documento do NIST que cont em informac o a em redes wireless, incluindo um estudo de caso e um checklist no nal do documento. Pr aticas de Seguranc a para Administradores de Redes Internet. http://www.nbso.nic.br/docs/ seg-adm-redes/. P agina a partir da qual pode ser obtida a vers ao mais recente deste documento e do checklist que o acompanha. Cont em tamb em um hist orico de revis oes dos documentos. Security Links. http://www.nbso.nic.br/links/. o de URLs sobre diversos aspectos de administrac o e seguranc Uma compilac a a a de redes e atualizada periodicamensistemas, incluindo diversos apresentados neste documento, e que e te.
41/46
A.2
Livros
802.11 Wireless Networks: The Denitive Guide. Matthew Gast. OReilly, 2002. http://www.oreilly.com/catalog/802dot11/ uma o tima refer Este livro e encia sobre redes 802.11, embora n ao seja focado exclusivamente em seguranc a. Cobre as diferentes vers oes do protocolo, suas peculiaridades, fatores que deo vem ser considerados ao denir a topologia da rede e quest oes relacionadas com a monitorac a 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/ es pr Um dos melhores livros dispon veis sobre rewalls, com muitas informac o aticas sobre como constru -los. Computer Security: Art and Science. Matt Bishop. Addison-Wesley, 2002. http://nob.cs.ucdavis.edu/book/ Livro que cobre de forma aprofundada os aspectos te oricos relacionados com seguranc a. o Cont em cap tulos que discutem pol ticas de seguranc a, uso de criptograa e implementac a a sess de sistemas de forma segura. De maior interesse para administradores de redes e ao discutida a aplicac o de diversos conceitos de seguranc es Practicum, onde e a a em situac o reais. DNS and BIND, 4th Edition. Paul Albitz e Cricket Liu. OReilly & Associates, 2001. http://www.oreilly.com/catalog/dns4/ o sobre o protocolo DNS e a sua principal implementac o, Este livro possui bastante informac a a o cont o BIND. A quarta edic a em um cap tulo sobre seguranc a de servidores DNS. Firewalls and Internet Security: Repelling the Wily Hacker, 2nd Edition. Willian R. Cheswick, Steven M. Bellovin e Aviel D. Rubin. Addison-Wesley, 2003. http://www.wilyhacker.com/ o sobre Excelente refer encia sobre seguranc a em Internet. Al em de apresentar uma grande sec a es que envolvem outros temas, como o estudo de Firewalls e VPNs, tamb em disp oe de sec o o, ferramentas e t ecnicas utilizadas em ataques e na defesa de redes e sistemas de informac a o de hosts forticados an alise de problemas e pr aticas de seguranc a em intranets, e implantac a o de intrus e de sistemas de detecc a ao (IDSs). O livro possui diversos exemplos pr aticos, que reetem a experi encia de seus autores. Practical Unix and Internet Security, 3rd Edition. Simson Garnkel, Gene Spafford e Alan Schwartz. OReilly & Associates, 2003. http://www.oreilly.com/catalog/puis3/ considerado refer Este livro e encia obrigat oria em seguranc a de sistemas Unix. Esta nova o aborda as variantes de Unix mais populares e cobre quest edic a oes atuais relacionadas a es sobre autenticac o, sistema de redes e seguranc a de sistemas. O livro cont em informac o a o de intrus arquivos, criptograa, wireless, rewalls, detecc a ao, an alise forense, entre outras.
42/46
TCP/IP Illustrated, Volume 1: The Protocols. W. Richard Stevens. Addison-Wesley, 1994. claro e did A melhor obra dispon vel sobre TCP/IP. O texto e atico, e numerosos exemplos (usando tcpdump) ajudam a compreender o funcionamento dos protocolos na pr atica. Unix System Administration Handbook, 3rd Edition. Evi Nemeth, Garth Snyder, Scott Seebass e Trent R. Hein. Prentice Hall, 2001. o de sistemas Unix, recentemente atualizado. Traz explicac es O cl assico sobre administrac a o claras e objetivas sobre como realizar, de forma eciente, as diferentes tarefas que competem a um administrador de sistemas Unix. Seguranc a Nacional. Nelson Murilo de O. Runo. Novatec, 2001. http://www.segurancanacional.com.br/ Uma boa refer encia sobre seguranc a computacional em portugu es, com enfoque em aspectos pr aticos. o de servic S erie OReilly sobre administrac a os de rede e sistemas operacionais espec cos. http://www.oreilly.com/ conhecida pela qualidade t A editora OReilly e ecnica dos seus livros, que geralmente abordam um assunto espec co com bastante profundidade e com um enfoque bem pr atico. Existem guias para servidores como Apache (Web) e Sendmail (SMTP), al em de diversos t tulos o de sistemas operacionais (incluindo Unix, Linux e Windows). sobre uso e administrac a Windows 2000 Security. Roberta Bragg. New Riders Publishing, 2000. nfase aos aspectos pr Este livro discute seguranc a no Windows 2000, dando maior e aticos. Os temas abordados incluem IPsec, Kerberos, Active Directory, RAS e RRAS. Windows NT Security: A Practical Guide to Securing Windows NT Servers & Workstations. Charles B. Rutstein. McGraw-Hill, 1997. o, congurac o, uso do Um bom livro sobre seguranc a de Windows NT, incluindo instalac a a Registry, logging, entre outros assuntos. Writing Information Security Policies. Scott Barman. New Riders Publishing, 2001. Este livro explica como escrever e implementar uma pol tica de seguranc a. Cont em v arios o de exemplos extra dos de pol ticas reais, que podem ser usados como guia para a formulac a novas pol ticas.
43/46
Indice Remissivo
802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36, 40, 41 802.11i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 802.1x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 A abuso de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 ncias. . . . . . . . . . . . . . . . . . . . . . . . . . .15 conseq ue es legais . . . . . . . . . . . . . . . . . . . . . . . 15 implicac o administradores equipe . . . . . . . veja equipes de administradores Administrator . . . . . . . . . . . veja contas privilegiadas Alan Schwartz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 an alise de riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 AUP . . . . . . . . . . . . . . . veja pol tica de uso aceit avel Aviel D. Rubin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 B backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2728 armazenamento . . . . . . . . . . . . . . . . . . . . . . . . . 28 bin arios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 itens importantes . . . . . . . . . . . . . . . . . . . . . . . . 27 logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 off-site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 es individuais . . . . . . . . . . . . . . . . . . . . . 10 partic o pol ticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 restaurac a o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 vericac a BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . veja DNS bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 C Cartilha de Seguranc a para Internet . . . . . . . . . . . . 17 Charles B. Rutstein . . . . . . . . . . . . . . . . . . . . . . . . . . 42 o congurac a es . . . . . . . . . . . . . . . . . . . . 18 controle de alterac o DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2125 o. . . . . . . . . . . . . . . . . . . . . . . . . . .11 documentac a proxy Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 revis ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 servidores SMTP . . . . . . . . . . . . . . . . . . . . 15, 24 conta Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . 19 conta root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 contas privilegiadas . . . . . . . . . . . . . . . . . . . . . . . . . . 19 es de contato contatos . . . . . . . . . . . . . veja informac o es de seguranc correc o a . . . . . . . . . . . . . . . . . . . . . . . 15 periodicidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 precauc o reposit orio local . . . . . . . . . . . . . . . . . . . . . . . . . 15 Cricket Liu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 D D. Brent Chapman . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 di ario de bordo . . . . . . . . . . . . . . . . . . . . veja logbook DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2124 cache poisoning . . . . . . . . . . . . . . . . . . . . . . . . . 22 contato no SOA . . . . . . . . . . . . . . . . . . . . . . . . . 25 exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 envenenamento de cache . . . . . . . . . . . . . . . . . 22 ltragem de tr afego . . . . . . . . . . . . . . . . . . . . . . 22 HINFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 es sens informac o veis . . . . . . . . . . . . . . . . . . . . 23 jaula chroot() . . . . . . . . . . . . . . . . . . . . . . . . . 23 o . . . . . . . . . . . . . . . 24 problemas de congurac a reverso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 o . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 atualizac a riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 servidor com autoridade . . . . . . . . . . . . . . . . . . 22 servidor com privil egios m nimos . . . . . . . . . 23 servidor privado . . . . . . . . . . . . . . . . . . . . . . . . . 27 servidor recursivo . . . . . . . . . . . . . . . . . . . . . . . 22 transfer encia de zona . . . . . . . . . . . . . . . . . . . . 22 TXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 vers ao do servic o . . . . . . . . . . . . . . . . . . . . . . . . 23 version.bind . . . . . . . . . . . . . . . . . . . . . . . . . . 23 WKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 E o dos usu educac a arios . . . . . . . . . . . . . . . . . . . . . . . 17 egress ltering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Elizabeth D. Zwicky . . . . . . . . . . . . . . . . . . . . . . . . . 41 enderec os reservados . . . . . . . veja redes reservadas enderec o reverso . . . . . . . . . . . . . . . . . . . . . . veja DNS es de enderec os eletr onicos padr ao . veja informac o contato engenharia social . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 formas de ataque . . . . . . . . . . . . . . . . . . . . . . . . 29 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 prevenc a equipes de administradores . . . . . . . . . . . . . . . . . . . 18 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 comunicac a contas privilegiadas . . . . . . . . . . . . . . . . . . . . . . 19
44/46
listas de discuss ao . . . . . . . . . . . . . . . . . . . . . . . 18 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 erios de escolha . . . . . . . . . . . . . . . . . . . . . . 31 crit erios de ltragem . . . . . . . . . . . . . . . . . . . . . 33 default allow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 default deny . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32, 33 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 egress ltering . . . . . . . . . . . . . . . . . . . . . . . . . . 33 exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3335 ferramentas de software livre . . . . . . . . . . . . . 31 ltragem de per metro . . . . . . . . . . . . . . . . . . . 32 ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 ingress ltering . . . . . . . . . . . . . . . . . . . . . . . . . 33 internos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32, 34 es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 limitac o o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 localizac a servic os n ao utilizados . . . . . . . . . . . . . . . . . . . 14 stateful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 stateless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 zona desmilitarizada . . . . . . . . . . . . . . . . . . . . . 32 es de seguranc xes . . . . . . . . . . . . . . . . . veja correc o a FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 fuso hor ario . . . . . . . . . . . . . . . . . . . . . . . veja timezone G Garth Snyder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Gene Spafford . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 gerenciamento de sistemas operacionais . . . . . . . 40 H hor ario de ver ao . . . . . . . . . . . . . . . . . . . veja timezone I IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 ICMP ltragem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 es de contato . . . . . . . . . . . . . . . . . . . . . . . 24 informac o aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 enderec o abuse . . . . . . . . . . . . . . . . . . . . . . . . . 24 enderec o security . . . . . . . . . . . . . . . . . . . . . . 24 monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . 24 RFC 2142 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 SOA do DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 WHOIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 o . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 atualizac a tipos de contato . . . . . . . . . . . . . . . . . . . . . . . 25 ingress ltering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 o instalac a es . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 de correc o de pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 o de servic desativac a os . . . . . . . . . . . . . . . . . . 14 o. . . . . . . . . . . . . . . . . . . . . . . . . . .11 documentac a m nima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 personalizada . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 preparac a IPs reservados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 L listas de discuss ao alertas de seguranc a . . . . . . . . . . . . . . . . . . . . . 28 Bugtraq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 cuidados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29, 30 internas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 para manter-se informado . . . . . . . . . . . . . . . . 28 logbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1113 cuidados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 formato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 es essenciais . . . . . . . . . . . . . . . . . . . 11 informac o uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14, 15, 18 logs armazenamento off-line . . . . . . . . . . . . . . . . . . 20 armazenamento on-line . . . . . . . . . . . . . . . . . . 20 riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 gerac a import ancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 integridade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 loghosts centralizados . . . . . . . . . . . . . . . . . . . . 20
45/46
monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . 20 eventos anormais . . . . . . . . . . . . . . . . . . . . . . 21 timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 per odo de armazenamento . . . . . . . . . . . . . . . 20 o de volume . . . . . . . . . . . . . . . . . . . . . . 21 reduc a rel ogio sincronizado . . . . . . . . . . . . . . . . . . . . . 19 o autom rotac a atica . . . . . . . . . . . . . . . . . . . . . . 20 M Matt Bishop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 N Nelson Murilo de O. Runo . . . . . . . . . . . . . . . . . . 42 NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 ajuste mais preciso . . . . . . . . . . . . . . . . . . . . . . 17 o de tr reduc a afego . . . . . . . . . . . . . . . . . . . . . . . 17 servidor local . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 P particionamento de disco . . . . . . . . . . . . . . . . . . . . . . 9 vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 es de seguranc patches . . . . . . . . . . . . . . veja correc o a Paul Albitz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 pol tica an alise de riscos . . . . . . . . . . . . . . . . . . . . . . . . . . 6 de backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 de seguranc a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 de senhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 de uso aceit avel . . . . . . . . . . . . . . . . . . . . . . . . . . 8 de uso da rede wireless . . . . . . . . . . . . . . . . . . . 36 fatores de sucesso . . . . . . . . . . . . . . . . . . . . . . . . 7 inu encias negativas . . . . . . . . . . . . . . . . . . . . . . 7 POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 pornograa envolvendo crianc as . . . . . . . . . . . . . . 15 protocolos sem criptograa . . . . . . . . . . . . . . . . . . . 26 proxy Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 formas de abuso . . . . . . . . . . . . . . . . . . . . . . . . . 16 R redes n ao alocadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 redes privadas (RFC 1918) . . . . . . . . . . . . . . . . . . . 27 redes reservadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 ltragem de enderec os . . . . . . . . . . . . . . . . . . . 26 lista atual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 RFC 3330 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 vazamento de enderec os . . . . . . . . . . . . . . . . . 27 redes sem o . . . . . . . . . . . . . . . . . . . . . . veja wireless refer encias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Registro .br . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
relay aberto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 roaming users . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 rel ogio fuso hor ario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 hor ario de ver ao . . . . . . . . . . . . . . . . . . . . . . . . . 18 o . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 sincronizac a timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 o de backups . . . . . . . . . . . . . . . . . . . . . . . 28 restaurac a 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 caracter sticas desej aveis . . . . . . . . . . . . . . . . . 13 compartilhadas . . . . . . . . . . . . . . . . . . . . . . . . . . 19 de administrador . . . . . . . . . . . . . . . . . . . . . . . . 13 fortes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 mudanc a de senhas default . . . . . . . . . . . . . . . 38 pol tica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 es de seguranc service packs . . . . . . . . . veja correc o a servic os o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 desativac a alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 divis ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 n ao utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 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 ario o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 educac a Cartilha de Seguranc a para Internet . . . . . 17 V vulnerabilidades es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 correc o o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 exposic a W W. Richard Stevens . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Web proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 sites sobre seguranc a . . . . . . . . . . . . . . . . . . . . 29 webmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 WHOIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . veja wireless Willian R. Cheswick . . . . . . . . . . . . . . . . . . . . . . . . . 41 wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3640 APs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 o . . . . . . . . . . . . . . . . . . . . . . . . . . 38 congurac a uso de switch . . . . . . . . . . . . . . . . . . . . . . . . . 37 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 monitorac a pol tica de uso . . . . . . . . . . . . . . . . . . . . . . . . . . 36 o da rede WLAN . . . . . . . . . . . . . . . 36 segregac a TKIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 topologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 vazamento de sinal . . . . . . . . . . . . . . . . . . . . . . 36 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 WEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Segurança Adm Redes

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Segurança Adm Redes

Enviado por

Direitos autorais:

Formatos disponíveis

Pr aticas de Seguranc a para Administradores de Redes Internet

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

Praticas de Seguranc a para Administradores de Redes Internet

o de Protocolos sem Criptograa . . . . . . . . . . . . . . . . . . . . . . . . . . . Eliminac a Cuidados com Redes Reservadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Praticas de Seguranc a para Administradores de Redes Internet

o de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . Pol ticas de Backup e Restaurac a

Praticas de Seguranc a para Administradores de Redes Internet

Como Obter este Documento

o Nota de Copyright e Distribuic a

Praticas de Seguranc a para Administradores de Redes Internet

Praticas de Seguranc a para Administradores de Redes Internet

Praticas de Seguranc a para Administradores de Redes Internet

Praticas de Seguranc a para Administradores de Redes Internet

Pol ticas de Uso Aceit avel

Praticas de Seguranc a para Administradores de Redes Internet

o e Congurac o Segura de Sistemas Instalac a a

Estrat egias de Particionamento

Praticas de Seguranc a para Administradores de Redes Internet

Praticas de Seguranc a para Administradores de Redes Internet

o da Instalac o e Congurac o Documentac a a a

Praticas de Seguranc a para Administradores de Redes Internet

(state) LISTEN LISTEN

Figura 1: Exemplos de entradas no logbook

Praticas de Seguranc a para Administradores de Redes Internet

Praticas de Seguranc a para Administradores de Redes Internet

o de Servic Desativac a os N ao Utilizados

Praticas de Seguranc a para Administradores de Redes Internet

o de Abuso de Recursos 3.8 Prevenc a

Praticas de Seguranc a para Administradores de Redes Internet

Praticas de Seguranc a para Administradores de Redes Internet

o e Operac o Segura de Redes e Sistemas Administrac a a

Ajuste do Rel ogio

Praticas de Seguranc a para Administradores de Redes Internet

es na Congurac o Controle de Alterac o a

Praticas de Seguranc a para Administradores de Redes Internet

Praticas de Seguranc a para Administradores de Redes Internet

Praticas de Seguranc a para Administradores de Redes Internet

Praticas de Seguranc a para Administradores de Redes Internet

Praticas de Seguranc a para Administradores de Redes Internet

Uso de Privil egios M nimos

es Sens Cuidado com Informac o veis no DNS

Praticas de Seguranc a para Administradores de Redes Internet

Praticas de Seguranc a para Administradores de Redes Internet

Praticas de Seguranc a para Administradores de Redes Internet

o de Protocolos sem Criptograa Eliminac a

Cuidados com Redes Reservadas

Praticas de Seguranc a para Administradores de Redes Internet

o de Sistemas Pol ticas de Backup e Restaurac a

Praticas de Seguranc a para Administradores de Redes Internet

Como Manter-se Informado

Praticas de Seguranc a para Administradores de Redes Internet

es contra Engenharia Social Precauc o

Praticas de Seguranc a para Administradores de Redes Internet

Praticas de Seguranc a para Administradores de Redes Internet

4.12 Uso Ecaz de Firewalls

Praticas de Seguranc a para Administradores de Redes Internet

o de rewalls Tabela 2: Ferramentas de software livre para a construc a

o dos Firewalls Localizac a

Praticas de Seguranc a para Administradores de Redes Internet

Crit erios de Filtragem

Praticas de Seguranc a para Administradores de Redes Internet

Praticas de Seguranc a para Administradores de Redes Internet

Setor Financeiro SMTP WWW FW Intranet DNS

Praticas de Seguranc a para Administradores de Redes Internet