Grupo de Trabalho de Redes

B. Fraser

Request for Comments: 2196

FYI: 8

Editor
SEI/CMU

Obsoleto: 1244

Setembro 1997

Categoria: Informativo

Site Security Handbook

Estado deste Memorando
Este memorando tem como objetivo prover informaes para a
comunidade da Internet. No tem o objetivo de se tornar um padro para
a Internet. A distribuio deste memorando ilimitada.

Resumo
Este manual um guia para desenvolvimento de polticas de segurana
de computador e procedimentos para sites que tm seus sistemas na
Internet. O propsito deste manual proporcionar um guia prtico aos
administradores tentando tornar segura uma grande variedade de
informaes e servios. Os assuntos abordados incluem os contedos de
poltica e formao, tpicos tcnicos de segurana de redes, e, tambm,
reaes a incidentes de segurana.

ndice
1. Introduo
1.1 Propsito deste Trabalho
1.2 Pblico Alvo
1.3 Definies
1.4 Trabalho Relacionado
1.5 Guia Bsico
1.6 Taxa de risco

1. Introduo
Este documento um guia para administradores de sistemas e redes, o
qual explica como tratar assuntos de segurana dentro da comunidade de
Internet. Este foi elaborado com base no RFC 1244 atravs do trabalho
cooperativo de vrios autores. Os autores deste trabalho incluem: Jules P.
Aronson (aronson@nlm.nih.gov), Nevil Brownlee
(n.brownlee@auckland.ac.nz), Frank Byrum (byrum@norfolk.infi.net), Joao
Nuno Ferreira (ferreira@rccn.net), Barbara Fraser (byf@cert.org), Steve
Glass (glass@ftp.com), Erik Guttman (erik.guttman@eng.sun.com), Tom

Killalea (tomk@nwnet.net), Klaus- Peter Kossakowski

(kossakowski@cert.dfn.de), Lorna Leone (lorna@staff.singnet.com.sg),
Edward.P.Lewis (Edward.P.Lewis.1@gsfc.nasa.gov), Gary Malkin
(gmalkin@xylogics.com), Russ Mundy (mundy@tis.com), Philip J. Nesser
(pjnesser@martigny.ai.mit.edu), and Michael S. Ramsey
(msr@interpath.net).
Alm dos escritores identificados acima, vrios revisores proveram
valiosos comentrios. Estes revisores so: Eric Luiijf (luiijf@fel.tno.nl),
Marijke Kaat (marijke.kaat@sec.nl), Ray Plzak (plzak@nic.mil) and Han
Pronk (h.m.pronk@vka.nl).
Um obrigado especial vai para Joyce Reynolds, ISI, e Paul Holbrook, CICnet,
por suas idias, liderana, e esforo na criao da primeira verso deste
manual. E o que o grupo sinceramente espera que esta verso seja to
til a comunidade como a anterior.

1.1 Propsito deste Trabalho

Este manual um guia para implantao de polticas de segurana de
computadores e procedimentos para sites que tm seus sistemas na
Internet (porm, a informao provida tambm deve ser utilizada para
locais no ainda conectados a Internet). Este guia lista assuntos e fatores
que um site deve considerar quando implementa suas prprias polticas.
So feitas vrias recomendaes e prov discusses de reas pertinentes.
Este guia s uma estrutura para implementar polticas e procedimentos
de segurana. Na verdade, para ser ter um conjunto efetivo de polticas e
procedimentos, um site ter que tomar muitas decises, fazer acordos, e
ento comunicar e implementar estas polticas.

1.2 Pblico Alvo

O pblico alvo para este documento so administradores de sistemas e
redes, e tomadores de deciso (tipicamente gerentes mdios) nos sites.
Para brevidade, ns usaremos o termo " administrador " ao longo deste
documento para se referir a administradores de sistemas e redes.
Este documento no dirigido a programadores, mesmo que esses
estejam tentando criar programas ou sistemas seguros. O enfoque deste
documento est nas polticas e procedimentos que precisam ser usadas
para viabilizar as caractersticas tcnicas de segurana que um site deve
implementandar.
O pblico principal para este trabalho so locais que fazem parte da
comunidade Internet. Todavia, este documento poder ser til a qualquer
site que permita comunicao com outros sites. Como um guia geral para
polticas de segurana, este documento pode tambm ser til para sites
com sistemas isolados.

1.3 Definies

Para a finalidade deste guia, um " site " qualquer organizao que possui
computadores ou recursos de rede relacionados. Estes recursos podem
incluir computadores que os usurios usam, routers, servidores de
terminais, PCs, ou outros dispositivos que tm acesso Internet. Um site
pode ser um usurio final de servios Internet ou um provedor de servio.
Porm, a maioria do enfoque deste guia est nesses usurios finais de
servios de Internet. Ns assumimos que o site tem capacidade de
implementar polticas e procedimentos para si mesmo com o
consentimento e suporte dos que so os donos dos recursos. Ser
assumido que locais que so partes de organizaes maiores saibam
quando eles precisam consultar, colaborar, ou acatar recomendaes de
entidades maiores.
A " Internet " uma coleo de milhares de redes interligadas por um
conjunto de protocolos tcnicos que tornam isto possvel para usurios de
qualquer uma das redes se comunicar com, ou usar os servios localizado
em, quaisquer das outras redes (FYI4, RFC 1594).
O termo " administrador " usado para incluir todas as pessoas que so
responsvel para a operao do dia-a-dia do sistema e recursos da rede.
Podem ser vrios indivduos ou uma organizao.
O termo " administrador de segurana" usado para incluir todas as
pessoas que so responsveis pela segurana das informao e tecnologia
de informao. Em alguns sites esta funo pode ser combinada com a do
administrador (cima citado); a outros, esta ser uma posio separada.
O termo " tomador de deciso" se refere a essas pessoas em um site que
aprovam a poltica. Estes so freqentemente (mas no sempre) as
pessoas responsveis pelos recursos.

1.4 Trabalho Relacionado

O grupo de trabalho do Site Security Handbook esta trabalhando em um
Guia de Usurio para Segurana de Internet. Este prover um guia prtico
para usurios finais ajudando-os a proteger as suas informao e recursos.

1.5 Guia Bsico

Este guia foi escrito com o objetivo de proporcionar uma viso rpida de
desenvolvimento de um plano de segurana para seu site. A sugesto de
Fites, et. al. [Fites 1989] inclui os seguintes passos:
(1) Identifique o que voc est tentando proteger.
(2) Determine do que voc est tentando se proteger.
(3) Determine o quanto provvel so as ameaas.
(4) Implemente medidas as quais protegero seus recursos importantes de
maneira efetiva.
(5) Revise o processo continuamente e faa melhorias cada vez que uma
fraqueza for encontrada.

A maior parte deste documento enfocado em 4 itens acima, mas os

outros passos no podem ser evitados se um plano efetivo deve ser
estabelecido em seu site. Um velho axioma em segurana que o custo
de se proteger contra uma ameaa deve ser menor que o custo da
recuperao se a ameaa o atingir. Custo neste contexto significa incluir
perdas expressadas em moeda corrente real, reputao, confiana e
outras medidas menos bvias. Sem conhecimento razovel do que voc
est protegendo e o que so as ameaas provveis, seguir estas regras
poder ser difcil.

1.6 Taxa de risco

1.6.1 Discusso geral

Um das razes mais importantes de criar uma poltica de segurana de
computador assegurar que esforos dispendidos em segurana rendero
benefcios efetivos. Embora isto possa parecer bvio, possvel se
enganar sobre onde os esforos so necessrios. Como por exemplo,
existe muita publicidade sobre intrusos externos em sistemas de
computadores, mas a maioria das pesquisas de segurana de computador
mostram que, para a maioria das organizaes, a maior perda ocorre com
intrusos internos.
A anlise de risco envolve determinar o que voc precisa proteger, do que
voc precisa proteger, e como proteger. Este o processo de examinar
todos os riscos e ordena esses riscos por nvel de severidade. Este
processo envolve tomada de decises por custo-efetivos do que voc quer
proteger. Como mencionado acima, voc provavelmente no deve gastar
mais para proteger algo a menos que seja de fato importante.
Um tratamento completo de anlise de risco est fora do escopo deste
documento. [Fites 1989] e [Pfleeger 1989] proveram introdues para este
tpico. Entretanto, h dois elementos da anlise de risco que sero
brevemente abordados nas prximas duas sees:
(1) Identificando os recursos
(2) Identificando as ameaas
Para cada recurso, os objetivos bsicos de segurana so disponibilidade,
confiabilidade e integridade. Cada ameaa deve ser examinada de modo a
verificar como a ameaa pode afetar estas reas.

1.6.2 Identificando os Recursos

Um dos passos em uma anlise de risco identificar todas as coisas que
precisam ser protegidas. Algumas coisas so bvias, como informao
proprietrias, propriedade intelectual e todos os vrios componentes de
hardware; mas, alguns so negligenciados, tal como as pessoas que de
fato usam os sistemas. O ponto essencial listar todas as coisas que
podem ser afetadas por um problema de segurana.

Uma lista de categorias sugerida por Pfleeger [Pfleeger 1989]; segue

abaixo uma adaptao da lista:
(1) Hardware: CPUs, boards, teclados, terminais, estaes de trabalho,
computadores pessoais, impressoras, discos, drives, linhas de
comunicao, servidores de terminais, roteadores.
(2) Software: programas fonte, programas objeto, utilitrios, programas de
diagnstico, sistemas operacionais e programas de comunicao.
(3) Dados: durante execuo, armazenados on-line, arquivados off-line,
backups, logs de auditoria, bancos de dados e mdia de comunicao.
(4) Pessoas: usurios, administradores e suporte de hardware.
(5) Documentao: programas, hardware, sistemas, local, procedimentos
administrativos.
(6) Materiais: papel, formulrios, fitas e mdia magntica.

1.6.3 Identificando as Ameaas

Uma vez que os recursos a serem protegidos forem identificados,
necessrio identificar as ameaas a esses recursos. As ameaas podem
ser examinadas para determinar o potencial de perda existente. Isso ajuda
a considerar de que ameaas voc est tentando proteger seus recursos.
Seguem ameaas clssicas que deveriam ser consideradas. Dependendo
de seu local, haver ameaas mais especficas que devero ser
identificadas e endereadas.

(1) Acesso sem autorizao a informaes e/ou recursos

(2) Revelao de informao sem inteno e/ou sem autorizao
(3) Servio negado (Denial of Service)

2. Polticas de Segurana
Neste documento h uma srie de referncias para polticas de segurana.
Seguidamente, estas referncias incluiro recomendaes para polticas especficas.
O que uma poltica de segurana? Por que ter uma?
O que faz uma boa poltica de segurana?
Mantendo a poltica flexvel
Links Complementares
Introduo:
Texto sobre Segurana, Poltica e tica da Universidade de Stanford

2.1 - O que uma poltica de segurana? Por que ter uma?

As decises que voc como administrador toma ou deixa de tomar, relacionadas
segurana, iro determinar quo segura ou insegura a sua rede, quantas
funcionalidades ela ir oferecer, e qual ser a facilidade de utiliz-la. No entanto,
voc no consegue tomar boas decises sobre segurana, sem antes determinar
quais so as suas metas de segurana. At que voc determine quais sejam elas,
voc no poder fazer uso efetivo de qualquer coleo de ferramentas de segurana
pois voc simplesmente no saber o que checar e quais restries impor.
Por exemplo, seus objetivos provavelmente sero muito diferentes dos que so
definidos por um vendedor de produto. Os vendedores procuram deixar a
configurao e a operao de seus produtos o mais simplificado possvel, o que
implica que as configuraes default normalmente sero bastante to abertas (e por
conseguinte inseguras) quanto possvel. Se por uma lado isto torna o processo de
instalao de novos produtos mais simples, tambm deixa acessos abertos, para
qualquer usurio.
Seus objetivos devem ser determinados a partir das seguintes determinantes:
1. Servios oferecidos versus Segurana fornecida - Cada servio oferecido para
os usurios carrega seu prprios riscos de segurana. Para alguns servios, o
risco superior que o benefcio do mesmo, e o administrador deve optar por
eliminar o servio ao invs de tentar torn-lo menos inseguro.
2. Facilidade de uso versus Segurana - O sistema mais fcil de usar deveria
permitir acesso a qualquer usurio e no exigir senha, isto , no haveria
segurana. Solicitar senhas torna o sistema um pouco menos conveniente, mas
mais seguro. Requerer senhas "one-time" geradas por dispositivos, torna o
sistema ainda mais difcil de utilizar, mas bastante mais seguro.
3. Custo da segurana versus o Risco da perda - H muitos custos diferentes
para segurana: monetrio (o custo da aquisio de hardware e software como
firewalls, e geradores de senha "one-time"), performance (tempo cifragem e
decifragem), e facilidade de uso. H tambm muitos nveis de risco: perda de
privacidade (a leitura de uma informao por indivduos no autorizados),
perda de dados (corrupo ou deleo de informaes), e a perda de servios
(ocupar todo o espao disponvel em disco, impossibilidade de acesso rede).
Cada tipo de custo deve ser contra-balanado ao tipo de perda.
Seus objetivos devem ser comunicados a todos os usurios, pessoal operacional, e

gerentes atravs de um conjunto de regras de segurana, chamado de "poltica de

segurana". Ns utilizamos este termo ao invs de "poltica de segurana
computacional", uma vez que o escopo inclui todos os tipos de tecnologias de
informao e informaes armazenadas e manipuladas pela tecnologia.
2.1.1 - Definio de uma poltica de segurana
Uma poltica de segurana a expresso formal das regras pelas quais fornecido
acesso aos recursos tecnolgicos da empresa.
2.1.2 - Propsitos de um poltica de segurana
O principal propsito de uma poltica de segurana informar aos usurios, equipe
e gerentes, as suas obrigaes para a proteo da tecnologia e do acesso
informao. A poltica deve especificar os mecanismos atravs dos quais estes
requisitos podem ser alcanado. Outro propsito oferecer um ponto de referncia
a partir do qual se possa adquirir, configurar e auditar sistemas computacionais e
redes, para que sejam adequados aos requisitos propostos. Portanto, uma tentativa
de utilizar um conjunto de ferramentas de segurana na ausncia de pelo menos
uma poltica de segurana implcita no faz sentido.
Uma poltica de uso apropriado (Appropriate - ou Acceptable - Use Policy - AUP) pode
tambm ser parte de uma poltica de segurana. Ela deveria expressar o que os
usurios devem e no devem fazer em relao aos diversos componentes do
sistema, incluindo o tipo de trfego permitido nas redes. A AUP deve ser to
explcita quanto possvel para evitar ambiguidades ou maus entendimentos. Por
exemplo, uma AUP pode lista newsgroups USENET proibidos.
Texto sobre Privacidade e Segurana da Informao
2.1.3 - Quem deve ser envolvido na formulao da poltica?
Para que uma poltica de segurana se torne apropriada e efetiva, ela deve ter a
aceitao e o suporte de todos os nveis de empregados dentro da organizao.
especialmente importante que a gerncia corporativa suporte de forma completa o
processo da poltica de segurana, caso contrrio haver pouca chance que ela
tenha o impacto desejado. A seguinte lista de indivdulos deveria estar envolvida na
criao e reviso dos documentos da poltica de segurana:
O administrador de segurana do site
O pessoal tcnico de tecnologia da informao
Os Administradores de grandes grupos de usurios dentro da organizao
A equipe de reao a incidentes de segurana
Os Representantes de grupos de usurios afetados pela poltica de segurana
O Conselho Legal
A lista acima representativa para muitas organizaes que tem controle acionrio,
mas no necessariamente para todas. A idia trazer representaes dos membros,
gerentes com autoridade sobre o oramento e poltica, pessoal tcnico que saiba o
que pode e o que no pode ser suportado, e o conselho legal que conhea as
decorrncias legais das vrias polticas. Em algumas organizaes, pode ser
apropriado incluir pessoal de auditoria. Envolver este grupo importante se as
poltica resultante dever alcanar a maior aceitabilidade possvel. Tambm

importante mencionar que o papel do conselho legal ir variar de pas para pas.
Clique aqui para acessar informaes sobre o time de resposta a incidentes de
segurana da Universidade de Stanford

2.2 O que faz uma boa poltica de segurana?

As caractersticas de uma boa poltica de segurana so:
1. Ela deve ser implementvel atravs de procedimentos de administrao,
publicao das regras de uso aceitveis, ou outros mtodos apropriados.
2. Ela deve ser exigida com ferramentas de segurana, onde apropriado, e com
sanes onde a preveno efetiva no seja tecnicamente possvel.
3. Ela deve definir claramente as reas de responsabilidade para os usurios,
administradores e gerentes.
Os componentes de uma boa poltica de segurana incluem:
1. Guias para a compra de tecnologia computacional que especifiquem os
requisitos ou caractersticas que os produtos devem possuir.
2. Uma poltica de privacidade que defina expectativas razoveis de privacidade
relacionadas a aspectos como a monitorao de correio eletrnico, logs de
atividades, e acesso aos arquivos dos usurios.
3. Uma poltica de acesso que define os direitos e os privilgios para proteger a
organizao de danos, atravs da especificao de linhas de conduta dos
usurios, pessoal e gerentes. Ela deve oferecer linhas de condutas para
conexes externas, comunicao de dados, conexo de dispositivos a uma
rede, adio de novos softwares, etc. Tambm deve especificar quaisquer
mensagens de notificao requeridas (por exemplo, mensagens de conexo
devem oferecer aviso sobre o uso autorizado, e monitorao de linha, e no
simplesmente "welcome".
4. Uma poltica de contabilidade que defina as responsabilidades dos usurios.
Deve especificar a capacidade de auditoria, e oferecer a conduta no caso de
incidentes (por exemplo, o que fazer e a quem contactar se for detectada uma
possvel intromisso.
5. Uma poltica de autenticao que estabelea confiana atravs de uma poltica
de senhas efetiva, e atravs da linha de conduta para autenticao de acessos
remotos e o uso de dispositivos de autenticao.
.
Clique aqui para acessar a pgina de um dispositivo de autenticao:
The VASCO Data Security International Smart Card Reader System
.
6. Um documento de disponibilidade que define as expectativas dos usurios para
a disponibilidade de recursos. Ele deve enderear aspectos como redundncia
e recuperao, bem como especificar horrios de operao e de manuteno.
Ele tambm deve incluir informaes para contato para relatar falhas de
sistema e de rede.
7. Um sistema de tecnologia de informao e poltica de manuteno de rede que
descreva como tanto o pessoal de manuteno interno como externo devem
manipular e acessar a tecnologia. Um tpico importante a ser tratado aqui
como a manuteno remota permitida e como tal acesso controlado. Outra

rea para considerar aqui a terceirizao e como ele gerenciada.

8. Uma poltica de relatrio de violaes que indique quais os tipos de violaes
devem ser relatados e a quem estes relatos devem ser feitos. Uma atmosfera
de no ameaa e a possibilidade de denncias annimas ir resultar uma
grande probabilidade que uma violao seja relatada.
9. Suporte a informao que oferea aos usurios informaes para contato para
cada tipo de violao; linha de conduta sobre como gerenciar consultas
externas sobre um incidente de segurana, ou informao que seja considerada
confidencial ou proprietria; referncias cruzadas para procedimentos de
segurana e informaes relacionadas, tais como as polticas da companhia e
leis e regulamentaes governamentais.
Pode haver requisitos regulatrios que afetem alguns aspectos de sua poltica de
segurana (como a monitorao). Os criadores da poltica de segurana devem
considerar a busca de assistncia legal na criao da mesma. No mnimo, a poltica
deve ser revisada por um conselho legal.
Uma vez que a poltica tenha sido estabelecida ela deve ser claramente comunicada
aos usurios, pessoal e gerentes. Deve-se criar um documento que os usurios
assinem, dizendo que leram, entenderam e concordaram com a poltica
estabelecida. Esta uma parte importante do processo. Finalmente sua poltica
deve ser revisada regularmente para verificar se ela est suportando com sucesso
suas necessidades de segurana.

2.3 - Mantendo a poltica flexvel

No intuito de tornar a poltica vivel a longo prazo, necessrio bastante
flexibilidade baseada no conceito de segurana arquitetural. Uma poltica deve ser
largamente independente de hardware e softwares especficos. Os mecanismos para
a atualizao da poltica devem estar claros. Isto inclui o processo e as pessoas
envolvidas.
Tambm importante reconhecer que h expectativas para cada regra. Sempre que
possvel a poltica deve expressar quais expectativas foram determinadar para a sua
existncia. Por exemplo, sob que condies um administrador de sistema tem direito
a pesquisar nos arquivos do usurio. Tambm pode haver casos em que mltiplos
usurios tero acesso mesma userid. Por exemplo, em sistemas com um usurio
root, mltiplos administradores de sistema talvez conheam a senha e utilizem a
conta.
Outra considerao chamada a "Sndrome do Caminho de Lixo". Isto se refe a o
que pode acontecer ao um site se uma pessoa chave repentinamente no esteja
mais disponvel para sua funo (ficou doente ou deixou a companhia). Enquanto a
grande segurana reside na mnima disseminao de informao, o risco de perder
informao crtica cresce quando a informao no compartilhada. importante
determinar qual o peso ideal desta medida em seu site.

Links Complementares:
Poltica de Segurana da NASA para a Internet
Desenvolvimento da Poltica de Segurana

3.2.3.1 Servidores de Nomes (DNS e NIS(+))

A Internet usa o Domain Name System (DNS) para realizar resoluo de endereo
para nomes de host e rede. O Sistema de Informao de Rede (NIS) e NIS+ no so
usados na Internet, mas esto sujeitos aos mesmos riscos que o servidor DNS.
Resoluo nome-endereo crtica para a operao segura de qualquer rede. Um
atacante que pode controlar ou personificar um servidor DNS pode alterar o trfego
para subverter protees de segurana. Por exemplo, trfego normal pode ser
desviado para um sistema comprometido para ser monitorado; ou, usurios podem
ser enganados e fornecer segredos de autenticao. Uma organizao deveria criar
sites protegidos, bem conhecidos, para atuar como servidores de nomes secundrio
e proteger seu DNS mestre de ataques por bloqueio de servio usando roteadores
filtradores.
Tradicionalmente, DNS no tem nenhuma capacidade de segurana. Em
particular, a informao retornada de uma consulta no pode ser conferida para
verificar eventual modificao ou se ela originou-se do servidor de nome solicitado.
Trabalho tem sido feito para incorporar assinaturas digitais no protocolo que,
quando utilizado, permitir que a integridade da informao seja verificada
criptograficamente (veja RFC 2065).
3.2.3.2 Servidores de Senha/Chave (NIS(+) e KDC)
Servidores de senha e chave geralmente protegem suas informaes vitais (i.e.,
as senhas e chaves) com algoritmos de encriptao. Porm, mesmo uma senha
encriptada em uma nica via pode ser determinada por um ataque do dicionrio
(em que so encriptadas palavras comuns para ver se elas correspondem
encriptao armazenada). ento necessrio garantir que esses servidores no
sejam acessveis por hosts que no planejam us-los para o servio, e mesmo estes
hosts deveriam somente estar aptos a acessar o servio (i.e., servios gerais, tais
como Telnet e FTP, no deveriam ser permitidos por ningum alm dos
administradores).
3.2.3.3 Servidores de Autenticao/Proxy (SOCKS, FWTK)
Um servidor procurador fornece vrios aprimoramentos de segurana. Ele permite
aos sites concentrar servios atravs de um host especfico para permitir
monitorao, esconder a estrutura interna, etc. Esta concentrao dos servios cria
um alvo atraente para um intruso potencial. O tipo de proteo necessrio para um
servidor de procurao depende muito do protocolo em uso pelo proxy e os servios
sendo fornecidos atravs dele. A regra geral de limitar o acesso somente a estes
hosts que precisam dos servios, e limitar acesso para estes hosts somente para
aqueles servios, um bom ponto de partida.
3.2.3.4 Correio Eletrnico
Sistemas de correio eletrnico (email) foram, por um longo tempo, uma fonte
para intrusos arrombadores porque os protocolos de email esto entre os mais
antigos e os servios mais amplamente utilizados. Tambm, por sua natureza, um
servidor de email requer acesso ao mundo externo; a maioria dos servidores de
email aceitam entrada de qualquer origem. Um servidor de email geralmente
consiste de duas partes: um agente receptor/emissor e um agente de
processamento. Desde que email entregue a todos os usurios, e normalmente
privado, o agente de processamento tipicamente requer privilgios (root) do sistema
pra entregar o mail. A maioria das implementaes de email executam ambas

pores do servio, o que significa que o agente receptor tambm tem privilgios do
sistema. Isto abre vrios furos de segurana que este documento no descrever.
Existem algumas implementaes disponveis que permitem uma separao dos
dois agentes. Tais implementaes so geralmente consideradas mais seguras, mas
ainda exigem instalao cuidadosa para evitar a criao de um problema de
segurana.
3.2.3.5 World Wide Web (WWW)
A Web est crescendo exponencialmente em popularidade devido a sua facilidade
de uso e a poderosa habilidade de concentrar servios de informao. A maioria dos
servidores WWW aceitam algum tipo de direo e ao de pessoas acessando seus
servios. O exemplo mais comum enviar um pedido de um usurio remoto e
passar a informao fornecida para um programa executando no servidor para
processar o pedido. Alguns desses programas no so escritos com segurana em
mente e podem criar furos de segurana. Se um servidor Web est disponvel para a
comunidade Internet, especialmente importante que informaes confidenciais
no sejam colocadas no mesmo host que o servidor. De fato, recomendado que o
servidor tenha um host dedicado que no confivel pelos outros hosts internos.
Muitos sites podem querer colocar servio FTP com seu servio WWW. Mas isto
deveria ocorrer somente para servidores de ftp-annimo que apenas fornecem
informaes (ftp-get). Operao put no ftp-annimo, em combinao com WWW,
pode ser perigoso (por exemplo, elas poderiam resultar em modificaes para as
informaes que seu site est publicando para a rede) e eles mesmos fazem as
consideraes de segurana para cada servio diferente.
3.2.3.6 Transferncia de Arquivo (FTP, TFTP)
FTP e TFTP permitem aos usurios receber e enviar arquivos eletrnicos em modo
ponto-a-ponto. Porm, FTP requer autenticao, enquanto o TFP no necessita. Por
esta razo, TFTP deveria ser evitado tanto quanto possvel.
Servidores FTP configurados inadequadamente podem permiter podem permitir
aos intrusos copiar, substituir e apagar arquivos vontade, em qualquer lugar de
um host, ento muito importante configurar este servio corretamente. Acesso a
senhas encriptadas e dados proprietrios e a introduo de cavalos de Tria so
apenas alguns dos potenciais furos de segurana que podem ocorrer quando o
servio configurado incorretamente. Servidores FTP deveriam ter seu prprio host.
Alguns sites decidem colocar FTP com servidor Web, uma vez que os dois protocolos
compartilham consideraes de segurana comuns. Porm, na prtica no
recomendado, especialmente quando o servio FTP permite o depsito de arquivos
(veja seo em WWW acima). Como mencionado nos pargrafos de abertura da
seo 3.2.3, servios fornecidos internamente para seu site no deveriam ser
colocados com servios oferecidos externamente. Cada um deveria ter seu prprio
host.
TFTP no suporta o mesmo conjunto de funes que o FTP e no tem qualquer
segurana. Este servio deveria somente ser considerado para uso interno, e ento
ele deveria ser configurado de maneira restrita tal que o servidor tem acesso
somente a um conjunto pr-determinado de arquivos (ao invs de todos os os
arquivos com permisso de leitura para todos). Provavelmente o uso mais comum
do TFTP para downloading de arquivos de configurao para um roteador. TFTP
deveria residir em seu prprio host, e no deveria ser instalado em hosts suportado

FTP externo ou acesso Web.

3.2.3.7 NFS
O Servio de Arquivo de Rede (Network File System) permite aos hosts
compartilhar discos comuns. NFS freqentemente usado por hosts sem disco que
dependem de um servidor de disco para todas as suas necessidades de
armazenamento. Infelizmente, NFS no tem nenhuma segurana embutida. ento
necessrio que o servidor NFS seja acessvel somente pelos hosts que esto usandoo para servio. Isto obtido especificando para quais hosts o sistema de arquivos
est sendo exportado e de que modo (por exemplo, somente leitura, somente
escrita, etc.). Sistemas de arquivos no deveriam ser exportados para qualquer host
externo rede local, uma vez que isso ir necessitar que o servio NFS seja
acessvel externamente. Idealmente, o acesso externo ao servio NFS deveria ser
bloqueado por um firewall.
3.2.4 Protegendo a Proteo
surpreendente a freqencia com que um site negligenciar os cuidados mais
bvias na sua segurana deixando o prprio servidor de segurana aberto para
ataques. Baseado nas consideraes discutidas previamente deve estar claro que: o
servidor de segurana no deveria ser acessvel fora do site; deveria fornecer
mnimo acesso, exceto para a funo de autenticao, para usurios no site; e no
deveria ser localizado com quaisquer outros servidores. Alm disso, todo acesso ao
nodo, incluindo acesso ao prprio servio, deveria ser "anotado" (registrando em
logs) para fornecer um "rastro" em caso de uma quebra de segurana.
3.3 Firewalls
Uma das medidas de segurana mais amplamente empregada e publicada em
uso na Internet um "firewall". Firewalls tem recebido a reputao de serem uma
panacia geral para muitas, seno todas, questes de segurana da Internet. Eles
no so. Firewalls so apenas outra ferramenta em questo para segurana de
sistema. Eles fornecem um certo nvel de proteo e so, em geral, uma maneira de
implementar a poltica de segurana no nvel de rede. O nvel de segurana que um
firewall fornece pode variar tanto quanto o nvel de segurana em uma mquina
particular. Existe o tradicional "trade-off" entre segurana, facilidade de uso, custo,
complexidade, etc.
Um firewall um dos vrios mecanismos usados para controlar e observar o
acesso de e para uma rede com a finalidade de proteg-la. Um firewall atua como
um gateway atravs do qual todo o trfego de e para a rede ou sistemas protegidos
passa. Firewalls ajudam a colocar limitaes na quantidade e tipo de comunicao
que ocorre entre a rede protegida e a outra rede (por exemplo, a Internet, ou outra
parte da rede de um site).
Um firewall geralmente uma maneira de construir uma parede entre uma parte
de uma rede, uma rede interna de uma empresa, por exemplo, e outra parte, a
Internet global, por exemplo. A nica caracterstica sobre esta parede que
precisam existir maneiras para algum trfego com caractersticas particulares
passarem atravs de portas cuidadosamente monitoradas ("gateways"). A parte
difcil estabelecer o critrio pelo qual os pacotes so permitidos ou negados
acesso pelas portas. Livros escritos sobre firewall usam terminologia diferente para
descrever as vrias formas de firewalls. Isto pode ser confuso para administradores
de sistemas que no so familiares com firewalls. O ponto a observar aqui que no

existe nenhuma terminologia fixa para a descrio de firewalls.

Firewalls no so sempre, ou mesmo tipicamente, uma nica mquina.
Preferivelmente, firewalls so freqentemente uma combinao de roteadores,
segmentos de rede, e computadores host. Portanto, para o propsito desta
discusso, o termo "firewall" pode consistir em mais de um dispositivo fsico.
Firewalls so tipicamente construdos usando dois diferentes componentes,
roteadores de filtragem e servidores proxy.
Roteadores de filtragem so o componente mais fcil de conceituar em um
firewall. Um roteador move dados de um lado para outro entre duas (ou mais) redes
diferentes. Um roteador "normal" pega um pacote da rede A e encaminha-o para
seu destino na rede B. Um roteador de filtragem faz a mesma coisa mas decide no
apenas como rotear o pacote mas se deveria rotear o pacote. Isto feito instalando
uma srie de filtros pelos quais o roteador decide o que fazer com qualquer pacote
de dados.
Uma discusso referente a capacidades de uma marca particular de roteador,
executando uma verso de software especfica est fora do escopo deste
documento. Porm, quando avaliando um roteador para ser usado para filtragem de
pacotes , o seguinte critrio pode ser importante quando da implementao de uma
poltica de filtragem: endereo IP origem e destino, nmeros de porta TCP origem e
destino, estado do bit "ACK" no pacote TCP, nmeros de porta UDP origem e destino,
e direo do fluxo de pacotes (i.e., A->B ou B->A). Outra informao necessria para
construir um esquema de filtragem seguro se o roteador reordena instrues de
filtro (de modo a otimizar a filtragem, isto algumas vezes pode mudar o significado e
causar acesso no pretendido), e se possvel aplicar filtros para pacotes que
chegam e que saem em cada interface (se o roteador filtra somente pacotes que
saem ento o roteador externo aos seus filtros e pode ser mais vulnervel para
atacar). Alm do roteador ser vulnervel, esta distino entre aplicar filtros em
pacotes que chegam ou que saem especialmente relevante para roteadores com
mais de duas interfaces. Outras questes importantes so a capacidade de criar
filtros baseado nas opes do cabealho IP e o fragmento do estado do pacote.
Construir um bom filtro pode ser muito difcil e requer um bom entendimento do tipo
de servios (protocolos) que sero filtrados.
Para melhor segurana, os filtros geralmente restringem acesso entre as duas
redes conectadas a apenas um host, o bastion host. S possvel ter acesso para a
outra rede atravs deste bastion host. Como somente este host, em lugar de
algumas centenas de hosts, pode ser atacado, mais fcil manter um certo nvel de
segurana pois somente este host tem que ser muito cuidadosamente protegido.
Para tornar disponvel recursos para legitimar usurios atravs deste firewall,
servios tem que ser passados adiante pelo bastion host. Alguns servidores tem
esta capacidade embutida (como servidores DNS ou servidores SMTP), e para outros
servios (por exemplo, Telnet, FTP, etc.), servidores proxy podem ser usados para
permitir acesso aos recursos atravs do firewall de modo seguro.
Um servidore proxy um modo para concentrar servios de aplicao atravs de
uma nica mquina. Tipicamente existe uma nica mquina (o bastion host) que
atua como um servidor proxy para uma variedade de protocolos (Telnet, SMTP, TFP,
HTTP, etc.) mas podem existir computadores host individuais para cada servio. Ao
invs de conectar diretamente um servidor externo, o cliente conecta para o
servidor proxy que em troca inicia uma conexo para o servidor externo solicitado.
Dependendo do tipo de servidor proxy usado, possvel configurar clientes internos

para realizar este redirecionamento automaticamente, sem conhecimento para o

usurio, outros podem requerer que o usurio conecte diretamente para o servidor
proxy e entao iniciar a conexo atravs de um formato especfico.
Existem benefcios de segurana significantes que podem ser obtidos pelo uso de
servidores proxy. possvel adicionar listas de controle de acesso para protocolos,
exigir que usurios ou sistemas forneam algum nvel de autenticao antes do
acesso ser concedido. Servidores proxy mais espertos, algumas vezes chamados
Gateways da Camada de Aplicao, podem ser escritos de modo que entendam
protocolos especficos e podem ser configurados para bloquear somente subsees
do protocolo. Por exemplo, um Gateway de Aplicao para FTP pode reconhecer a
diferena entre o comando "put" e o comando "get"; uma organizao pode desejar
permitir aos usurios realizar "get" de arquivos da Internet, mas no permitir "put"
de arquivos internos no servidor remoto. Em contraste, um roteador de filtragem
poderia ou bloquear todo acesso ao FTP, ou no, mas no um subconjunto.
Servidores proxy tambm podem ser configurados para encriptar fluxos de dados
baseado em uma variedade de parmetros. Uma organizao pode usar esta
caracterstica para permitir conexes encriptadas entre duas localizaes
interligadas via Internet.
Firewalls so pensados como uma maneira de manter intrusos do lado de fora,
mas eles tambm so usados geralmente como uma maneira de legitimar usurios
em um site. Existem muitos exemplos onde um usurio vlido poderia precisar
acessar regularmente o site "home" durante viagens para apresentaes e
conferncias, etc. Acesso Internet geralmente disponvel mas pode ser atravs
de uma mquina ou rede no confivel. Um servidor proxy configurado
corretamente pode permitir os usurios corretos no site enquanto bloqueia acesso
para outros usurios.
O maior esforo atual em tcnicas de firewall encontrar uma combinao de um
par de roteadores de filtragem com um ou mais servidores proxy na rede entre os
dois roteadores. Esta configurao permite ao roteador externo bloquear qualquer
tentativa de usar a camada IP subjacente para quebrar a segurana (IP spoofing,
roteamento pela origem, fragmentos de pacotes), enquanto permite ao servidor
proxy tratar potenciais furos de segurana nos protocolo das camadas superiores. A
finalidade do roteador interno bloquear todo trfego exceto para o servidor proxy.
Se esta configurao implementada rigorosamente, pode ser obtido um alto nvel
de segurana.
Muitos firewalls fornecem capacidade de log que pode ser adequado para fazer
administrao mais conveniente da segurana da rede. A funo de log pode ser
centralizada e o sistema pode ser configurado para enviar alertas para condies
anormais. importante monitorar regularmente estes logs para qualquer sinal de
intruses ou tentativas de arrombamento. Desde que alguns intrusos tentaro
encobrir seus ataques pela edio dos logs, desejvel proteger esses logs. Uma
variedade de mtodos est disponvel, incluindo: discos (Write Once Read Many);
logs em papel; e logs centralizados atravs do utilitrio "syslog". Outra tcnica
usar um impressora serial falsa, mas ter uma porta serial conectada para uma
mquina isolada ou PC que mantm os logs.
Firewalls esto disponveis em uma ampla faixa de qualidade e intensidade.
Pacotes comerciais iniciam em aproximadamente U$10,000 e alcanam mais de
U$250,000. Firewalls desenvolvidos pelo prprio site podem ser construdos a menor

custo. Deve-se lembrar que a configurao correta de um firewall (comercial ou

"caseiro") requer uma significante habilidade e conhecimento do TCP/IP. Ambos os
tipos requerem manuteno regular, instalao de patches de softwares e
atualizaes, e monitorao regular. Quando realiza-se o oramento de um firewall,
estes custos adicionais deveriam ser considerados alm do custo dos elementos
fsicos do firewall.
Como um aparte, construir uma soluo "caseira" para um firewall requer
significativa habilidade e conhecimento do TCP/IP. Isto no deveria ser tentado
trivialmente pois a sensao de segurana (no preenchida apropriadamente) pior
a longo prazo do que saber que no existe nenhuma segurana. Como com todas as
medidas de segurana, importante decidir na ameaa, o valor do recurso a ser
protegido, e os custos para implementar segurana.
Uma nota final sobre firewalls. Eles podem ser uma grande ajuda quando
implementando segurana para um site e protegem contra uma grande variedade
de ataques. Mas importante ter em mente que eles so apenas uma parte da
soluo. Eles no podem proteger seu site contra todos os tipos de ataque.

3. Arquitetura
3.1 Objetivos
3.1.1 Planos de Segurana Completamente Definidos
Todos os sites devem definir um amplo plano de segurana, que deve ser de mais
alto nvel que as polticas discutidas no captulo 2, e deve ser projetado como um
framework de objetivos amplos nos quais polticas especficas se enquadraro.
importante ter esse framework de tal maneira que polticas individuais possam ser
consistentes dentro de todo o contexto da arquitetura de segurana do site. Por
exemplo, ter uma poltica forte em relao ao acesso pela Internet e ter baixas
restries no uso do modem inconsistente dentro de uma filosofia de fortes
restries no que diz respeito ao acesso externo.
Um plano de segurana deve definir: a lista de servios de rede que sero providos;
quais reas da organizao provero os servios; quem ter acesso aos servios;
como o acesso ser provido; quem administrar esses servios; etc.
O plano tambm deve indicar como incidentes sero tratados. Captulo 5 prov uma
discusso profunda neste tpico, mas importante que cada site defina classes de
incidentes e reaes correspondentes. Por exemplo, sites com firewalls devem setar
um nmero de tentativas de ataque suportado antes de tomar uma ao? Nveis de
ao devem ser definidos para todos os ataques e respostas. Sites com firewalls
devem determinar se uma simples tentativa de conexo a um host constitui um
incidente ou no. E em relao procura sistemtica de sistemas?
Para sites conectados Internet, o nmero significativo de incidentes relatados em
relao segurana pode se fazer esquecer dos incidentes internos rede. Da
mesma maneira, organizaes no conectadas Internet devem ter planos fortes e
bem definidos de poltica de segurana interna.

3.1.2 Separao de Servios

Existem muitos servios que um site deve prover para seus usurios, alguns dos
quais podem ser externos. H uma variedade de razes para isolar os servios em
hosts dedicados. H tambm razes de performance em muitos casos, e uma
discusso detalhada ser feita neste documento.
Os servios que um site deve prover tero, em muitos casos, nveis diferentes de
acesso e modelos de confiana. melhor colocar servios que so essenciais
segurana ou operao do site em mquinas dedicadas com acesso limitado do que
em uma mquina que prov servio(s) menos seguro(s), ou que requer acesso por
parte dos usurios, que podem acidentalmente burlar a segurana.
tambm relevante distinguir entre hosts que operam em diferentes modelos e
confiana (isto , todos os hosts da rede interna versus hosts da rede externa).
Alguns dos servios que so potencialmente separveis so discutidos na sesso
3.2.3. importante lembrar que segurana to forte quanto a corrente em
relao ao menor elo. Muitos dos ataques conhecidos nos anos recentes tm sido
feitos por explorao de vulnerabilidades nos sistemas de correio eletrnico. Os

intrusos no querem acesso ao correio eletrnico, mas usar as suas vulnerabilidades

para ganhar acesso a outros sistemas.
Se possvel, cada servio deve estar sendo executado em mquinas diferentes que
tm como o nico objetivo prover aquele servio. Assim, fica mais fcil isolar
intrusos e limitar falhas potenciais.

3.1.3 Bloquear tudo / Permitir tudo

Existem 2 filosofias diametricamente opostas que podem ser adotadas quando se
define um plano de segurana. Ambas as alternativas so modelos legtimos a se
adotar, e a escolha entre uma ou outra depende do site e suas necessidades de
segurana.
A primeira opo retirar todos os servios e ento habilit-los seletivamente,
considerando-os caso a caso. Isto pode ser feito no nvel de host ou rede, o mais
apropriado. Este modelo, referenciando como "bloquear tudo", geralmente mais
seguro do que o outro, descrito no prximo pargrafo. Porm, a configurao requer
mais trabalho e compreenso dos servios. Permitir somente servios conhecidos
para uma melhor anlise de um particular servio/protocolo e o projeto de um
mecanismo de segurana cabem no nvel de segurana do site.
O outro modelo, referenciado como "permitir tudo", mais fcil de implementar,
mas geralmente menos seguro que o outro. Simplesmente ligar todos os servios
(a nvel de host) e permitir a todos os protocolos que trafeguem na rede (a nvel de
roteador). Como os buracos de segurana ficam aparentes, eles so restritos aos
nveis de host e rede.
Cada um dos modelos pode ser aplicado a diferentes pores do site, dependendo
dos requerimentos das funcionalidades, do controle administrativo, da poltica de
segurana, etc. Por exemplo, a poltica pode ser usar "permitir tudo" quando se trata
de estaes de uso geral, mas "bloquear tudo" quando se trata de servidores de
informaes, como servidores de email. Da mesma forma, "permitir tudo" pode ser
empregado no trfego entre subredes internas, mas "bloquear tudo" pode ser
adotado na comunicao com a Internet.
Deve-se tomar cuidados quando se mistura as duas filosofias. Tomar cuidado
somente com usurios externos pode no ser a melhor filosofia, pois usurios
internos rede podem no ser confiveis. E a partir do momento que um usurio
externo entra na rede (passando por um firewall) ele tem acesso a tudo, pois no h
isolamento interno.

3.1.4 Identificao das Reais Necessidades de Servios

H uma grande variedade de servios que podem ser providos, tanto internamente
quanto na Internet. Gerenciar segurana , em muitos casos, gerenciar o acesso a
servios internos ao site e como o acesso interno a servios externos se dar.
Os servios tendem a se disseminar como ondas na Internet. Atravs dos anos
muitos sites criaram servidores de: FTP annimos, gopher, wais, WWW, etc,
seguindo a moda quando eles se tornaram populares, mas sem levar em conta a
necessidade real deles. Deve-se avaliar cada novo servio em relao sua
necessidade real, esquecendo-se do modismo.

 bom ter-se em mente que a complexidade de segurana pode crescer

exponencialmente com o nmero de servios providos. Roteadores-filtros precisam
ser modificados para suportar novos protocolos. Alguns protocolos so
inerentemente difceis de se filtrar seguramente (como RPC e UDP), assim abrindose novas portas ao mundo interno. Servios providos pela mesma mquina podem
interagir de modos catastrficos, por exemplo, FTP annimo com WWW permite que
um atacante coloque um arquivo na rea de FTP e faa com que o servidor HTTP o
execute.

3.2 Configurao de Servios e Rede

3.2.1 Proteo da Infra-estrutura
Muitos administradores de rede protegem bem seus hosts, mas poucos so os que
fazem a tarefa de proteger a rede. Existe razo para isso. Geralmente o objetivo so
dados de servidores, pois os atacantes no tiraro proveito atacando os dados da
rede, embora isso no desmerea a necessidade de sua proteo, pois um ataque
comum nos dados da rede a procura por senhas de logins alheios. Mas a proteo
da infra-estrutura tambm diz respeito gerncia de rede (SNMP), servios (DNS,
NFS, NTP, WWW, ...) e segurana propriamente dita (autenticao e restries de
acesso).
A infra-estrutura tambm pede proteo dos erros humanos. Quando um
administrador no configura bem um host, ele pode oferecer um mau servio. Isto
pode afetar somente os usurios daquele host, e ao menos que seja um servidor
primrio daquele servio, o nmero de usurios afetados ser limitado. Entretanto,
se um roteador est mal configurado, todos os usurios que usarem a rede sero
afetados.

3.2.2 Proteo da Rede

Existem muitos ataques nos quais as redes se tornam vulnerveis. O ataque clssico
o "denial of service". Neste caso, a rede levada a um estado no qual no
consegue mais transmitir dados de usurios legtimos. H duas maneiras de como
isso pode ser feito: atacando os roteadores e enchendo a rede com trfego
estranho. Note-se que o termo roteador usado para representar toda a classe de
equipamentos de interconexo, nos quais se incluem firewalls. servidores-proxy, etc.
Um ataque num roteador feito para impedi-lo de reencaminhar pacotes, ou
transmiti-los de forma errada. Isso pode ser feito devido a uma m configurao, a
injeo de atualizao de informao de roteamento expria, ou atravs de um
"flood atack" , ou seja, o roteador bombardeado com pacotes no roteveis,
fazendo sua performance decair. Um "flood atack" em uma rede similar em
relao a um roteador, exceto que os pacotes so broadcast. Um ataque ideal deste
tipo seria a injeo de um nico pacote que requeresse que todas as estaes o
retransmitissem, ou gerar pacotes de erro, cada um tambm repetido pelas outras
estaes. Um ataque deste tipo bem feito pode gerar uma exploso exponencial de
transmisses.
Um outro ataque o "spoofing". Neste caso, pacotes exprios com informaes
erradas sobre roteamento so enviados a um ou mais roteadores fazendo com que
eles roteem errado. Este ataque difere do primeiro somente no propsito do
roteamento. No ataque anterior, o objetivo era deixar o roteador inutilizvel, um

estado facilmente detectado pelos usurios da rede. No "spoofing" os pacotes so

enviados a algum host onde eles podem ser monitorados e depois reenviados a seu
destino correto, tendo seu contedo alterado ou no.
A soluo para a maioria desses casos proteger os pacotes de atualizao de
roteamento dos protocolos como RIP-2 e OSPF. Existem 3 nveis de proteo: senha
textual, checksum criptografado e criptografia. Senhas textuais oferecem proteo
mnima contra intrusos que no tm acesso rede fsica. Tambm protegem
roteadores mal configurados (ou seja, roteadores ainda no configurados e que no
deveriam rotear pacotes). A vantagem de senhas que elas tm um baixo
overhead, tanto em tempo de transmisso como de CPU. Checksums protegem
contra a injeo de pacotes daninhos, at mesmo se o intruso tem acesso rede
fsica. Combinado com um nmero de seqncia, ou outro identificador nico, o
checksum pode tambm detectar ataques de retransmisso, onde uma informao
mais antiga est sendo retransmitida, seja por um intruso ou roteador mal
configurado. O melhor prover criptografia completa, de atualizaes de
roteamento sequenciados ou univocamente identificados. Isso impede um intruso de
determinar a topologia da rede. A desvantagem da criptografia o overhead
envolvido no processamento.
Tanto RIP-2 (RFC 1723) como OSPF (RFC 1583) suportam senhas textuais nas suas
especificaes bsicas de projeto. E existem extenses para cada protocolo suportar
o algoritmo de criptografia MD5.
Infelizmente no h proteo adequada a um ataque por "flooding" ou contra um
host ou roteador que esteja inundando a rede , mas felizmente esse ataque bvio
quando ocorre e geralmente pode ser terminado de forma relativamente fcil.

3.2.3 Proteo dos Servios

Existem muitos tipos de servios e cada um tem seus prprios requisitos de
segurana, que vo variar dependendo do uso do servio. Por exemplo, um servio
que poderia ser usado dentro de um site (NFS) requer mecanismos de proteo
diferentes de outros servios usados externamente rede. Pode ser suficiente
proteger o servidor de acesso externo, mas um servidor WWW, que prov
documentos que devem ser vistos por usurios da Internet, requer uma forte
proteo, para impedir que se modifique o banco de dados da Web por pessoas
externas rede.
Servios internos (usados pelos usurios do site) e servios externos
(deliberadamente permitidos para uso por usurios da internet) tero, de uma
maneira geral, requerimentos de proteo diferentes dos j descritos. bom isolar
os servios internos em um conjunto de servidores diferente do conjunto de
servidores de servios externos, ou seja, bom no se deixar todos os servios no
mesmo(s) host(s). Na realidade, muitos sites vo alm e tm um conjunto de
subredes (ou at redes diferentes) que so acessveis de fora do site e outro
conjunto acessvel somente de dentro do site. Naturalmente h firewalls inter
conectando estes conjuntos. Um grande cuidado deve-se tomar a fim de garantir o
funcionamento correto da firewall.
H bastante interesse em se usar intranets para conectar com diferentes partes da
organizao (divises da companhia). Enquanto este documento diferencia rede
interna de rede externa (privada e pblica), sites com intranets devem estar atentos
que eles precisaro considerar 3 separaes e tomar aes apropriadas quando

projetando e oferecendo servios. Um servio provido a uma intranet no deve se

tornar pblico, nem completamente privado como um servio de uma sub-unidade
da organizao. Entretanto, o servio pode precisar de um suporte prprio,
separadamente tanto dos servios e rede internos e externos.
Uma forma de servio externo que merece uma ateno especial o acesso
annimo, ou guest (no autenticado). importante manter esses acessos isolados
de hosts e sistemas de arquivos que no devem ser vistos por usurios externos.
Outro cuidado especial diz respeito ao acesso annimo com permisso de escrita.
Um site deve ser legalmente responsvel pela informao por ele tornada pblica,
portanto informaes colocadas por annimos devem ser monitoradas.
Agora iremos considerar alguns dos mais populares servios: servidor de nomes,
servidor de senhas, servidor de proxy/autenticao, correio eletrnico, WWW,
transferncia de arquivos e NFS. Considerando que so os servios mais
frequentemente usados, so os pricipais alvos de ataques. E um ataque em um
destes servios pode produzir um desastre alm das intenses do servio em si.

4. Servios e Procedimentos Seguros

Este captulo guia o leitor atravs de uma srie de tpicos os quais deveriam ser
observados para tornar um site seguro. Cada seo aborda um servio ou uma
capacidade de segurana que pode ser necessria para proteger a informao e os
sistemas de um site. Os tpicos so apresentados em razovel alto-nvel para a
introduo do leitor aos conceitos.
Ao longo do captulo voc encontrar referncias significativas criptografia. Est
fora do escopo deste documento aprofundar-se em detalhes concernentes
criptografia, mas o leitor interessado pode obter mais informaes atravs de livros
e artigos listados na seo de referncia deste documento.
4.1 Autenticao
Por muitos anos, o mtodo prescrito para a autenticao de usurios tem passado
pelo uso de senhas padro reutilizveis. Originalmente, estas senhas eram usadas
por usurios em trminais para autenticarem-se em um computador central. Na
poca no existiam redes (interiormente ou externamente), sendo mnimo o risco de
revelao da senha de texto claro. Atualmente sistemas so conectados atravs de
redes locais, e estas redes locais so conectadas mais adiante e Internet. Usurios
esto se logando de toda parte o globo; suas senhas reutilizveis so
frequentemente transmitidas atravs destas mesmas redes em texto claro, de modo
que qualquer um (que esteja na escuta) possa capturar. E, sem dvida, o Centro de
Coordenao CERT* e outras equipes de reao esto vendo um grande nmero de
incidentes envolvendo visualizadores de pacotes (sniffers) os quais esto
capturando as senhas de texto claro.
Com o advento de tecnologias mais recentes, como senhas de uso nico (por
exemplo, S/Key), PGP, e dispositivos de autenticao baseados em tokens, as
pessoas esto usando strings tipo senhas como tokens e nmeros identificadores
pessoais secretos. Se estes tokens e identificadores pessoais numricos secretos
no forem apropriadamente selecinados e protegidos, a autenticao ser
facilmente subvertida.
4.1.1 Senhas de uso nico
Como mencionado acima, dado os atuais ambientes de rede, recomendado que
sites relacionados com a segurana e a integridade de seus sistemas e redes
considerem mudanas em relao s senha padro reutilizveis. Tem ocorrido
muitos incidentes envolvendo programas de rede que so tranformados em cavalos
Tria (por exemplo, telnet e rlogin) e programas visualizadores de pacotes de rede.
Estes programas capturam trios de nomes de mquina, conta e senha em texto
claro. Intrusos podem usar a informao capturada para acesso subseqente s
mquinas e contas. Isto possvel porque 1) a senha usada vrias vezes
(conseqentemente o termo "reutilizvel") e 2) a senha passa atravs da rede em
texto claro.
Foram desenvolvidas algumas tcnicas de autenticao orientadas este problema.
Entre estas tcnicas esto tecnologias de desafio-resposta que provem senhas que
so usadas uma s vez (comumente chamadas de senhas de nica vez). H vrios
produtos disponveis, a deciso de usar um produto responsabilidade de cada
organizao, e cada organizao deveria realizar sua prpria avaliao e seleo.
4.1.2 Kerberos

Kerberos um sistema de segurana de rede distribudo que prov autenticao

atravs de redes inseguras. Caso sejam requisitados pela aplicao, integridade e
criptografia tambm podem ser providos. Kerberos foi desenvolvido originalmente
no Instituto de Massachusetts de Tecnologia (MIT) nos anos oitenta. H duas
principais verses do Kerberos, verso 4 e 5 que so, para propsitos prticos,
incompatveis.
Kerberos usa um banco de dados de chaves simtricas, utilizando um centro de
distribuio de chaves (KDC - Key Distribution Center) que conhecido como o
servidor Kerberos. So concedido "ingressos" eletrnicos para usurios ou servios
(conhecidos como "principais") depois de apropriada comunicao com o KDC. Estes
ingressos so usados para autenticao entre principais. Todos os ingressos incluem
um selo de tempo o qual limita o perodo de tempo para o qual o ingresso vlido.
Portanto, os clientes e o servidor Kerberos devem possuir uma fonte de tempo
segura e estarem aptos manter o controle de tempo com preciso.
O lado prtico de Kerberos sua integrao com o nvel de aplicao. Aplicaes
tpicas como FTP, telnet, POP e NFS tm sido integradas com o sistema Kerberos. H
uma variedade de implementaes que possuem nveis variados de integrao. Por
favor veja o FAQ do Kerberos disponvel via http://www.ov.com/misc/krb-faq.html
para a mais recente informao.
4.1.3 Escolhendo e Protegendo Tokens e Indentificadores Pessoais Numricos
Secretos
Quando da seleo de tokens secretos, deve-se escolh-los cuidadosamente. Como
a seleo de senhas, eles devem ser robustos contra esforos de fora bruta para
adivinh-los. Isto , eles no devem ser palavras nicas em qualquer idioma,
qualquer acrnimo comum, industrial ou cultural, etc. Idealmente, eles devem ser
mais longos que curtos e consistir de frases que combinem letras minsculas e
maisculas, dgitos e outros caracteres.
Uma vez escolhida, a proteo destes tokens secretos muito importante. Alguns
so usados como identificadores numricos para dispositivos de hardware (como
cartes de token) e estes no devem ser escritos abaixo ou colocados em mesmo
local do dispositivo com os quais so associados. Outros, como uma chave do PGP,
devem ser protegidos de acesso no autorizado.
Uma ltima palavra neste assunto. Quando da utilizao de produtos de criptografia,
como PGP, tome cuidado em determinar o comprimento apropriado da chave e
assegurar que seus usurios estejam treinados para fazer igualmente. Como
avanos de tecnologia, o comprimento seguro mnimo de chave continua crescendo.
Tenha certeza de que seu site mantenha o mais recente conhecimento na
tecnologia de forma que voc possa assegurar que qualquer criptografia em uso
esteja provendo a proteo que voc acredita que ele realmente esteja.
4.1.4 Garantia da Senha
Enquanto a necessidade de eliminar o uso de senhas padro reutilizveis no pode
ser exagerada, reconhecido que algumas organizaes ainda podem estar usandoas. recomendado que estas organizaes mudem para o uso de uma melhor
tecnologia. Enquanto isso, ns temos o seguinte conselho para ajudar com a seleo
e manuteno de senhas tradicionais. Mas lembre-se, nenhuma destas medidas
prov proteo contra revelao devido a programas de visualizao de pacotes.

(1) A importncia de senhas robustas - Em muitos (se no a maioria) casos de

penetrao de sistema, o intruso precisa ganhar acesso uma conta no sistema.
Uma maneira em que esta meta tipicamente alcanada adivinhando a senha de
um usurio legtimo. Isto freqentemente realizado atravs da execuo de
programa automtico de quebra de senhas, o qual utiliza um dicionrio muito
grande contra o arquivo de senhas do sistema. O nico modo de resguardar-se
contra a descoberta de senhas desta maneira pela seleo cuidadosa de senhas
que no podem ser facilmente adivinhado (i.e., combinaes de nmeros, letras e
carter de pontuao). Senhas tambm devem ser to compridas quanto suportado
pelo sistema e toleradas pelo usurio.
(2) Troca de senhas padro - Muitos sistemas operacionais e programas de
aplicao so instalados com contas e senhas padro. Estas devem ser mudadas
imediatamente para algo que no possa ser adivinhado ou quebrado.
(3) Restringindo acesso ao arquivo de senhas - em particular, um site deseja
proteger a poro de senha codificada do arquivo para que os pretendentes a
intrusos no os tenham disponveis para a quebra. Uma tcnica efetiva usar
senhas de sombra onde o campo de senha do arquivo padro contm uma senha
boba ou falsa. O arquivo contendo as senhas legtimas protegido em outro lugar
do sistema.
(4) Envelhecimento de senhas - Quando e como expirar senhas ainda um assunto
de controvrsia entre a comunidade de segurana. Geralmente aceito que uma
senha no deve ser mantida uma vez que uma conta no se encontra mais em uso,
mas ardentemente debatido se um usurio deve ser forado a mudar uma boa
senha que est em uso ativo. Os argumentos para a troca de senhas relaciona-se
preveno do uso continuo de contas penetradas. Entretanto, a oposio reivindica
que mudanas de senha freqentes conduza usurios a escreverem suas senhas em
reas visveis (como col-las em um terminal) ou selecionarem senhas muito
simples as quais sejam fceis de adivinhar. Tambm deve ser declarado que um
intruso provavelmente usar uma senha capturada ou adivinhada mais cedo do que
tarde. Neste caso o envelhecimento da senha prov pequena ou nenhuma proteo,
pois ela estar ainda vlida no perodo em que o intruso estiver usando-a, isto ,
logo depois que a obtiver.
Enquanto no h resposta definitiva a este dilema, uma poltica de senhas deve
abordar a questo e prover diretrizes sobre com que freqncia um usurio deve
mudar a senha. Certamente, uma mudana anual em sua senha no difcil para a
maioria dos usurios e voc deve considerar esta requisio. recomendado que
senhas sejam mudadas pelo menos sempre que uma conta privilegiada seja
compromissada, exista uma mudana pessoal crtica (especialmente se for um
administrador!) ou quando uma conta seja comprometida. Ainda, se a senha de uma
conta privilegiada comprometida, todas as senhas no sistema devem ser
alteradas.
(5) Bloqueio de contas e senhas - Alguns sites acham til desabilitar contas depois
de um nmero pr-definido de no sucedidas tentativas de autenticao. Se seu site
decidir empregar este mecanismo, recomendado que o mecanismo no avise a si
mesmo. Depois de
desabilitar, at mesmo se a senha correta for apresentada, a mensagem exibida
deve permanecer como a de uma tentativa no sucedida de login. A implementao
deste mecanismo requerer que usurios legtimos contatem seus administradores

de sistema para pedir que sua conta seja reativada.

(6) Uma palavra sobre o finger daemon - O finger daemon exibe, como padro,
informao considervel do sistema e do usurio. Por exemplo, ele pode exibir uma
lista de todos os usurios que atualmente usam um sistema ou todo o contedos do
arquivo .plan de um usurio especfico. Esta informao pode ser usada por
possveis intrusos para identificar usernames e adivinhar suas senhas.
recomendado que sites considerem modificar o finger para restringir a informao
exibida.
4.2 Confidencialidade
Haver recursos de informao que seu site desejar proteger da revelao
entidades no autorizadas. Sistemas operacionais possuem freqentemente
mecanismos de proteo de arquivo embutidos que permitem um administrador
controlar quem pode acessar ou "ver" o contedo de um determinado arquivo. Um
modo mais forte de prover confiana atravs de criptografia. Criptografia
realizada misturando dados de forma que venha a ser muito difcil e consuma tempo
demasiado para que qualquer um que no um receptor ou proprietrio autorizado
possa obter o texto claro. Os receptores e autorizados e proprietrios da informao
possuiro as chaves de decriptao correspondentes as quais lhes permitem
decodificar facilmente o texto para uma forma legvel (texto claro). Ns
recomendamos que sites usem criptografia para prover confidencialidade e proteger
informao valiosa.
O uso de criptografia controlado s vezes por regulamentos governamentais e de
sites, portanto ns encorajamos que os administradores se informem sobre de leis
ou polticas que regulem seu uso antes de emprega-la. Est fora do escopo deste
documento discutir os vrios algoritmos e programas disponveis para este
propsito, mas ns advertimos contra o uso do programa crypt do UNIX por ter sido
facilmente quebrado. Ns tambm encorajamos todos a dispenderem tempo para
analisar a fora da criptografia em qualquer algoritmo/produto dado antes de us-lo.
A maioria dos produtos famosos bem-documentada na literatura, devendo ser esta
uma tarefa bastante fcil.
4.3 Integridade
Como um administrador, voc desejar ter certeza que informaes (por exemplo,
arquivos de sistema operacional, dados de companhia, etc.) no tenham sido
alteradas de uma maneira no autorizada. Isto significa que voc desejar prover
alguma garantia sobre a integridade da informao em seus sistemas. Um modo de
prover isto realizar um checksum do arquivo inalterado, armazenar o checksum de
maneira offline e periodicamente (ou quando desejado) conferir para ter certeza que
o checksum do arquivo online no tenha sido alterado (que indicaria a alterao dos
dados).
Alguns sistemas operacionais vm com programas de checksum, como o programa
sum do UNIX. Entretanto, estes podem no prover a proteo que voc precisa de
fato. Arquivos podem ser modificados arquivos de tal forma que o resultado do
programa sum do UNIX seja conservado! Assim, ns sugerimos a utilizao de um
forte programa de criptografia, como o programa de condenso de mensagem MD5
[ref], para produzir os checksums que voc usar para garantir a integridade.
H outras aplicaes onde a integridade precisar ser assegurada, como quando da
transmisso de um email entre duas entidades. Existem produtos disponveis os

quais podem prover esta capacidade. Uma vez que voc identificar esta capacidade
como sendo necessria, voc pode identificar tecnologias que provero isto.
4.4 Autorizao
Autorizao se refere ao processo de conceder privilgios para processos e, em
ltima anlise, para usurios. Isto difere daquela autenticao que o processo de
identificao de um usurio. Uma vez identificados (seguramente), os privilgios,
direitos, propriedade e aes permissveis do usurio so determinados atravs da
autorizao.
Listar explicitamente as atividades autorizadas de cada usurio (e processo de
usurio) com respeito a todos os recursos (objetos) impossvel em um sistema
razovel. Em um sistema real certas tcnicas so usadas para simplificar o processo
de conceder e verificar autorizaes.
Uma abordagem, popularizada em sistemas de UNIX, associar a cada objeto trs
classes de usurio: proprietrio, grupo e mundo. O proprietrio o criador do objeto
ou o usurio associado como proprietrio pelo super usurio. As permisses de
proprietrio (leitura, escrita e execuo) aplicam-se somente para o proprietrio. Um
grupo uma coleo de usurios que compartilham direitos de acesso sobre um
objeto. As permisses de grupo (leitura, escrita e execuo) aplicam-se a todos os
usurios no grupo (exceto o propritrio). O mundo refere-se a todos outros com
acesso ao sistema. As permisses de mundo (leitura, escrita e execuo) aplicam-se
a todos os usurios (menos o proprietrio e membros do grupo).
Outra abordagem associar a um objeto uma lista que explicitamente contm a
identidade de todos usurios permitidos (ou grupos). Esta uma Lista de Controle
de Acesso (ACL). A vantagem de ACLs que elas so
facilmente mantidas (uma lista central por objeto) e muito fcil verificar
visualmente quem tem acesso ao que. As desvantagens so os recursos extras
exigidos armazenar tais listas, como tambm o vasto nmero de listas requeridas
para sistemas grandes.

4.5 Acesso
4.5.1 Acesso Fsico
Restrinja o acesso fsico aos hosts, permitindo acesso somente a aquelas pessoas
que devem us-los. Hosts incluem terminais confiveis (ou seja, terminais que
permitem uso no autenticado tais como consoles do sistema, terminais de
operadores e terminais dedicados a tarefas especiais), e microcomputadores e
estaes de trabalho individuais, especialmente aqueles conectados a sua rede.
Certifique-se de que as reas de trabalho das pessoas se ajusta bem s restries de
acesso; caso contrrio elas encontraro maneiras de evitar sua segurana fsica (por
exemplo portas fechadas abrindo).
Mantenha cpias originais e backup de programas e dados seguras. Alm de mantlos em boas condies para fins de backup, eles devem ser protegidos contra furtos.
importante manter backups em uma localizao separada dos originais, no
somente em considerao a danos, mas tambem para proteger contra furtos.
Hosts portteis so um risco particular. Certifique-se que eles no causaro
problemas se um computador porttil de seu pessoal for roubado. Considere o
desenvolvimento de polticas para as espcies de dados que deveriam ser
permitidas residirem em discos de computadores portteis bem como a maneira
pela qual os dados deveriam ser protegidos (por exemplo criptografia) quando
estivessem em computadores portteis.
Outras reas onde o acesso fsico deveria ser restringido so os gabinetes de fiao
e elementos importantes de rede como servidores de arquivos, hosts servidores de
nomes e roteadores.

4.5.2 Conexes de Rede "Walk-Up"

Por conexes de rede "walk-up", nos referimos a pontos de conexo localizados a
fim de proporcionar uma maneira conveniente para usurios conectarem um host
porttil a sua rede.
Considere que voc precise fornecer este servio, tendo em mente que isto permite
a qualquer usurio conectar um host no autorizado a sua rede. Isto aumenta o
risco de ataques usando tcnicas tais como corrupo ("spoofing") de endereos IP,
espionagem ("sniffing") de pacotes, etc. A gerncia da instalao e os usurios
devem estimar os riscos envolvidos. Se voc decide fornecer conexes "walk-up",
planeje o servio cuidadosamente e defina precisamente onde voc ir fornec-lo a
fim de que voc possa assegurar a segurana de acesso fsico necessria.
Um host "walk-up" deveria ser autenticado antes que seja permitido ao usurio do
mesmo acessar recursos na sua rede. Como uma alternativa, pode ser possvel
controlar o acesso fsico. Por exemplo, se o servio destina-se a estudantes, voc
poderia fornecer tomadas de conexo "walk-up" somente nos laboratrios de
estudantes.
Se voc est fornecendo acesso "walk-up" para visitantes se conectarem de volta a
suas redes de origem (por exemplo para ler mail, etc) em sua facilidade, considere o
uso de uma sub-rede separada que no tem nenhuma conectividade com a rede
interna.

Fique de olho em qualquer rea que contem acesso no monitorado rede, tais
como escritrios vazios. Pode ser sensato desconectar tais reas no gabinete de
cabeamento, e considerar o uso de hubs seguros e monitoramento de tentativas de
conexo de hosts no autorizados.

4.5.3 Outras Tecnologias de Rede

Tecnologias consideradas aqui incluem X.25, RDSI, SMDS, DDS e Frame Relay.
Todas so fornecidas atravs de enlaces fsicos que passam por centrais telefnicas,
fornecendo o potencial para que estes sejam desviados. Os "crackers" esto
certamente interessados em comutaes telefnicas bem como em redes de dados
!
Com tecnologias comutadas, use circuitos virtuais permanentes (PVCs) ou grupos de
usurios fechados sempre que possvel. Tecnologias que fornecem autenticao
e/ou criptografia (tais como IPv6) esto evoluindo rapidamente; considere us-las
nos enlaces onde a segurana importante.

4.5.4 Modens
4.5.4.1 Linhas de Modem devem ser Gerenciadas
Ainda que elas forneam acesso conveniente a um local para todos seus usurios,
elas podem tambm fornecer um desvio efetivo dos firewalls do local. Por esta razo
essencial manter um controle apropriado dos modens.
No permite aos usurios instalar uma linha de modem sem uma autorizao
apropriada. Isto inclui as instalaes temporrias (por exemplo, pendurar um
modem em um aparelho de fax ou uma linha telefnica durante a noite.
Tenha um registro de todas as suas linhas de modem e mantenha-o atualizado.
Conduza verificaes regulares (idealmente automatizadas) dos modens no
autorizados no "site".
4.5.4.2 Usurios de Discagem devem ser Autenticados
A verificao do cdigo de usurio e da senha deveria ser completada antes que o
usurio possa ter acesso a qualquer coisa na sua rede. Consideraes normais sobre
segurana de senhas so particularmente importantes (veja a seo 4.1.1).
Lembre que linhas telefnicas podem ser escutadas clandestinamente, e que
muito fcil interceptar mensagens em telefones celulares. Os modens modernos de
alta velocidade usam tcnicas de modulao mais sofisticadas que tornam-nos mais
difceis de monitorar, mas prudente assumir que "hackers" sabem como escutar
escondidos suas linhas. Por esta razo, voc deveria usar senhas "one-time" sempre
que possvel.
de grande utilidade ter um nico ponto de entrada para acessos discados (por
exemplo um nico grande "pool" de modens) para que todos usurios sejam
autenticados da mesma forma. Os usurios iro eventualmente digitar
incorretamente uma senha. Estabelea um intervalo curto - digamos de dois
segundos - aps o primeiro e o segundo "login" falho, e force uma desconexo aps
o terceiro. Isto ir frear ataques de senha automatizados. No diga ao usurio se foi
o seu cdigo, a senha, ou ambos que estavam errados.

4.5.4.3 Capacidade de Chamada Reversa

Alguns servidores "dial-in" oferecem facilidades de chamada reversa (ou seja, o
usurio disca e autenticado, ento o sistema desconecta a chamada e chama de
volta no nmero especificado). A chamada reversa til porque se alguem estava
para adivinhar um cdigo e senha de usurio, desconectado e o sistema chama de
volta o usurio real cuja senha foi quebrada; chamadas aleatrias de um servidor
so suspeitas, quando muito. Isto significa que os usurios podem se logar somente
de um nico local (para onde o servidor est configurado para discar de volta), e
claro podem existir despesas associadas com a localizao da chamada reversa.
Este recurso deveria ser usado com cuidado; ele pode ser facilmente desviado. No
mnimo, certifique-se que a chamada de retorno nunca feita a partir do mesmo
modem que recebeu a chamada de entrada. Em geral, ainda que a chamada reversa
possa aumentar a segurana de modems, voc no deveria depender
exclusivamente dela.
4.5.4.4 Todos os Logins deveriam ser Registrados no Log
Todos os logins bem-sucedidos ou no deveriam ser registrados no log. Entretanto,
no guarde senhas corretas no log. Ao invs registre-as como uma simples tentativa
de login bem-sucedida. J a maioria das senhas so digitas incorretamente por
usurios autorizados. Elas variam somente por um nico caracter da senha real.
Alm disso se voc no puder manter tal log seguro, no as registre em hiptese
alguma.
Se a identificao da linha chamadora est disponvel, tome vantagem disso para
registrar o nmero chamador para cada tentativa de login. Seja sensvel as questes
de privacidade atingidas pela identificao da linha chamadora. Tambem esteja
ciente que a identificao da linha chamadora no deve ser considerada confivel
(j que intrusos tm sabido como arrombar comutaes telefnicas e "rotear"
nmeros de telefone ou fazer outras mudanas); use os dados para fins informativos
somente, no para autenticao.
4.5.4.5 Escolha seu "Banner" de Abertura Cuidadosamente
Muitos locais usam um "default" do sistema contido em um arquivo de mensagem
do dia para seu "banner" de abertura. Infelizmente, isto frequentemente inclui o tipo
de hardware e sistema operacional do host. Isto pode fornecer informaes valiosas
para um possvel intruso. Ao invs, cada local deveria criar seu prprio "banner" de
login especifico, tomando cuidado para somente incluir as informaes necessrias.
Exiba um "banner" curto, mas no oferea um nome "convidativo" (por exemplo
"Universidade XYZ", "Sistema de Registro de Estudantes"). Ao invs, fornea o nome
de seu local, uma advertncia curta de que as sesses podem ser monitoradas, e
um "prompt" de cdigo de usurio e senha. Verifique possveis questes legais
relacionadas ao texto que voc pe no "banner".
Para aplicaes de alta segurana considere o uso de uma senha "cega" (isto , no
d nenhuma resposta a uma chamada que chega at que o usurio tenha digitado
uma senha). Isto efetivamente simula um modem morto.
4.5.4.6 Autenticao "Dial-Out"

Usurios "dial-out" deveriam ser tambm autenticados, particularmente porque seu

local ter de pagar pelas despesas telefnicas.
Jamais permita discagem de sada a partir de uma chamada de entrada no
autenticada, e considere se voc ir permit-la a paritr de uma autenticada. O
objetivo aqui evitar que chamadores usem seu "pool" de modens como parte de
uma cadeia de "logins". Isto pode ser difcil de detectar, em especial se um "hacker"
estabelece um caminho atravs de muitos hosts em seu local.
No mnimo no permita que os mesmos modens e linhas telefnicas sejam usadas
para discagem de entrada e de sada. Isto pode ser facilmente implementado se
voc operar "pools" de modens separados para discagem de entrada e discagem de
sada.
4.5.4.7 Torne sua Programao de Modens a "Prova de Bala" tanto quanto
o Possvel
Certifique-se de que os modens no podem ser reprogramados enquanto estiverem
em servio. No mnimo, certifique-se que trs sinais de mais ("+++") no colocaro
seus modens de discagem de entrada em modo de comando !
Programe seus modens para "resetarem" sua configurao padro no incio de cada
chamada. Esta precauo proteger voc contra a reprogramao acidental de seus
modens. "Resetando-os" tanto no incio como no final de cada chamada ir
assegurar um nvel regularmente alto de confidencialidade que um novo chamador
no herdar da sesso do chamador prvio.
Verifique se seus modens encerram chamadas limpamente. Quando um usurio se
desloga de um servidor de acesso, verifique se o servidor desliga a linha telefnica
adequadamente. igualmente importante que o servidor force "logouts" sempre
que as sesses estiverem ativas e o usurio desliga inesperadamente.

4.6 Auditoria
Esta seo cobre os procedimentos para coletar os dados gerados pela atividade de
rede, que podem ser teis para analizar a segurana de uma rede e responder a
incidentes de segurana.

4.6.1 O que coletar

Dados de auditoria deveriam incluir qualquer tentativa de obter um nvel de
segurana diferente por qualquer pessoa, processo, ou outra entidade da rede. Isto
inclui "login" e "logout", acesso de super-usurio (ou o equivalente no-UNIX),
gerao de tquete (para Kerberos, por exemplo) e qualquer outra mudana de
acesso ou estado. especialmente importante notar o acesso "anonymous" ou
"guest" a servidores pblicos.
Os dados reais a coletar iro diferir para locais diferentes e para mudanas de
diferentes tipos de acesso dentro de um local. Em geral, as informaes que voc
quer coletar incluem: cdigo do usurio e nome do host para login e logout; direitos
de acessos prvios e novos; e um "timestamp". claro, h muito mais informaes
que poderiam ser coletadas, dependendo do que o sistema torna disponvel e
quanto espao est disponvel para armazenar aquelas informaes.
Uma nota muito importante: no colete senhas. Isto cria uma brecha potencialmente
enorme na segurana se os registros de auditoria forem inadequadamente
acessados. Tambem no colete senhas incorretas, j que elas diferem das senhas
vlidas somente por um caracter ou transposio.

Processo de Coleta
O processo de coleta deveria ser ordenado pelo host ou recurso sendo acessado.
Dependendo da importncia dos dados e a necessidade de t-los localmente em
instncias nas quais os servios esto sendo negados, os dados poderiam ser
guardados localmente ao recurso at que sejam necessrios ou serem transmitidos
para armazenamento aps cada evento.
H basicamente trs formas de armazenar registros de auditoria: em um arquivo de
leitura e escrita em um host, em um dispositivo do tipo escreva uma vez, leia vrias
(por exemplo um CD-ROM ou uma unidade de fita especialmente configurada), ou
num dispositivo somente de escrita (por exemplo uma impressora). Cada mtodo
tem suas vantagens e desvantagens.
O registro em um sistema de arquivos o que consome recursos menos
intensamente dentre os trs mtodos. Ele permite acesso instantneo aos registros
para anlise, o que pode ser importante se um ataque est em curso. Entretanto,
tambem o mtodo menos confivel. Se o host que efetua o registro foi
comprometido, o sistema de arquivos usualmente a primeira coisa onde ir; um
intruso poderia facilmente acobertar rastreios da intruso.
Coletar dados de auditoria em um dispositivo de escrita nica ligeiramente mais
trabalhoso de configurar que um simples arquivo, mas ele tem a significante
vantagem da segurana significativamente aumentada porque um intruso no
poderia alterar os dados indicadores de que uma invaso aconteceu. A desvantagem
deste mtodo a necessidade de manter um fornecimento de meio de
armazenamento e o custo desse meio. Tambem, os dados podem no estar

instantaneamente disponveis.
Registro em impressora til em sistemas onde registros ("logs") permanentes e
imediatos so necessrios. Um sistema de tempo real um exemplo disto, onde o
ponto exato de falha ou ataque deve ser registrado. Uma impressora laser, ou outro
dispositivo que buferiza dados (por exemplo um servidor de impresso) podem
sofrer de dados perdidos se os buffers contm os dados necessrios num instante
crtico. A desvantagem de, literalmente, trilhas de papel a necessidade de
vasculhar os registros a mo. H tambem a questo de tornar seguro o caminho
entre o dispositivo que gera o registro e o que realmente armazena o registro (por
exemplo um servidor de arquivos, uma unidade de fita/CD-ROM, uma impressora).
Se o caminho est comprometido, o registro pode ser parado ou adulterado ou
ambos. Em um mundo ideal, o dispositivo de registro estaria diretamente ligado por
um simples e nico cabo ponto-a-ponto. Como isto usualmente impraticvel, o
caminho deveria passar por um nmero mnimo de redes e roteadores. Mesmo que
os registros possam ser bloqueados, adulterao pode ser evitada com somas de
verificao criptogrficas (provavelmente no necessrio criptografar os registros
porque ees no deveriam conter informaes sensitivas em primeiro lugar.

4.6.3 Carga da Coleta

Coletar dados de auditoria pode resultar em um rpido acmulo de octetos, logo a
disponibilidade de armazenamento para estas informaes devem ser consideradas
desde cedo. Existem poucas maneiras de reduzir o espao de armazenamento
exigido. Primeiro, os dados podem ser compactados, usando um de muitos mtodos.
Ou, o espao exigido pode ser minimizado guardando dados por um perodo mais
curto de tempo com somente os sumrios de dados sendo guardados em arquivos
de longo prazo. Um grande inconviniente deste ltimo mtodo envolve a resposta a
incidentes. Frequentemente, um incidente j vem ocorrendo por algum perodo de
tempo, quando um local o percebe e comea a investigar. Neste momento muito
til ter disponveis registros de auditoria detalhados. Se estes so apenas sumrios,
pode no haver detalhes suficientes para tratar plenamente o incidente.

4.6.4 Manipulando e Preservando os Dados de Auditoria

Os dados de auditoria deveriam estar entre aqueles mais protegidos no local e nos
backups. Se um intruso ganhasse acesso aos registros de auditoria, no s os
dados, mas tambm os prprios sistemas correriam riscos.
Dados de auditoria podem tambm se tornar chaves para a investigao, apreenso
e acusao do autor de um incidente. Por esta razo, recomendvel buscar a
orientao da equipe jurdica ao decidir como os dados de auditoria devem ser
tratados. Isto deveria acontecer antes que um incidente ocorra.
Se um plano de manipulao de dados no for adequadamente definido antes de
um incidente, isso pode significar que no h como recorrer do resultado de um
evento, e isso pode criar responsabilidades resultantes do tratamento imprprio dos
dados.

4.6.5 Consideraes Legais

Devido ao contedo dos dados de auditoria, h um nmero de questes que surgem
que poderiam precisar da ateno da sua equipe jurdica. Se voc coleta e salva
dados de auditoria, voc precisa estar preparado para as consequncias resultantes

tanto da sua existncia como do seu contedo.

Uma rea diz respeito a privacidade dos indivduos. Em certas instncias, os dados
de auditoria podem conter informaes pessoais. A investigao nos dados, ainda
que para uma verificao de rotina da segurana do sistema, poderia representar
uma invaso de privacidade.
Uma segunda rea de preocupao envolve o conhecimento de comportamento
intrusivo proveniente de seu local. Se uma organizao mantem dados de auditoria,
ser ela responsvel por examin-los para investigar incidentes ? Se um host em
uma organizao usado como uma base de lanamento para um ataque contra
outra organizao, pode a segunda organizao usar os dados de auditoria da
primeira organizao para provar negligncia por parte da primeira ?
Pretende-se que os exemplos acima sejam compreensivos, mas eles deveriam
motivar sua organizao a considerar as questes legais envolvidas com dados de
auditoria.

4.7 Protegendo Backups

O procedimento de criar backups uma parte clssica de operar um sistema de
computao. Dentro do contexto deste documento, backups so tratados como
parte do plano global de segurana de um local. H muitos aspectos de backups que
so importantes neste contexto:
1. Certifique-se de que seu local est criando backups
2. Certifique-se de que seu local est usando armazenamento em separado para
os backups. A localizao deveria ser cuidadosamente selecionada tanto para a
sua segurana como para a sua disponibilidade.
3. Considere criptografar seus backups para proporcionar proteo adicional das
informaes uma vez que esto guardadas em separado. Entretanto, esteja
ciente de que voc precisar de um bom esquema de gerncia de chaves para
que voc possa recuperar os dados em qualquer ponto no futuro. Tambem,
certifique-se de que voc ter acesso aos programs de decodificao
necessrios no futuro quando voc precisar efetuar a decodificao.
4. No assuma sempre que seus backups esto bons. Tem havido muitos
exemplos de incidentes de segurana de computador que ocorreram por longos
perodos de tempo antes de serem notados. Em tais casos, backups dos
sistemas afetados esto tambm corrompidos.
5. Periodicamente verifique a correo e a compleo de seus backups.

5. Tratamento de Incidentes de Segurana

Este captulo do documento ser um guia a ser usado antes, durante, e depois de um incidente de
segurana de computador que acontea em host, rede, site, ou ambiente de multi-site. A filosofia de
operao no caso de uma brecha de segurana de computador reagir conforme um plano. Isto
verdade se a brecha o resultado de um ataque de intruso externo, dano no intencional, um
estudante testando algum programa novo para explorar uma vulnerabilidade de software, ou um
empregado enfadado. Cada um dos possveis tipos de eventos, como esses listados, deveriam ser
previstos com antecedncia por planos de contingncia adequados.
Segurana de computador tradicional, enquanto bastante importante no plano global de segurana do
site, normalmente presta pouca ateno em como agir de fato uma vez que um ataque ocorra. O
resultado que quando um ataque est ocorrendo, so tomadas muitas decises com pressa e podem
estar prejudicando a identificao da fonte do incidente, a coleta de evidncias para serem usadas em
esforos de prossecuo, preparar para a recuperao do sistema, e protegendo os dados valiosos
contidos no sistema.
Um dos mais importantes, mas freqentemente ignorados, benefcios paro tratamento eficiente do
incidente a economia. Quando ambos pessoal tcnico e administrativo respondem a um incidente, isto
requer recursos considerveis. Se treinados para lidar com incidentes eficazmente, menos tempo de
pessoal requerido quando um acontece.
Devido Internet a maioria dos incidentes no esto restritos a um nico local. Vulnerabilidade de
sistemas operacionais aplicam-se (em alguns casos) para vrios milhes de sistemas, e muitas
vulnerabilidades so exploradas dentro da prpria rede. Ento, vital que todos os sites com partes
envolvidas sejam informados o mais cedo possvel.
Outro benefcio relacionado a relaes pblicas. Notcias sobre incidentes de segurana de
computadores tendem a danificar a imagem de uma organizao entre os clientes atuais ou potenciais.
O tratamento eficiente de incidentes minimiza a exposio negativa.
Um benefcio final de tratamento incidente eficiente relacionado a assuntos legais. possvel que num
futuro prximo organizaes possam ser consideradas responsveis porque um de seus nodos foi usado
para lanar um ataque rede. Em uma situao semelhante, podem ser processadas as pessoas que
desenvolvem remendos ou workarounds, caso estes sejam ineficazes, resultando em comprometimento
dos sistemas, ou se danificam os mesmos. Sabendo sobre vulnerabilidades do sistema operacional e
padres de ataques, e tomando medidas apropriadas para se opor a estas ameaas potenciais, crtico
para evitar possveis problemas legais.
As sees neste captulo provem um esboo e ponto de partida para criar a poltica de seu site para
tratar incidentes de segurana. As sees so:
1. preparando e planejando (quais so as metas e objetivos no tratamento de um incidente).
2. notificao (quem deveria ser contactado no caso de um incidente).
* Os gerentes locais e pessoal
* Agncias investigativas e executoras da lei
* Grupos que tratam de incidentes de segurana de computador
* Locais afetados e envolvidos
* Comunicaes internas
* Relaes pblicas e imprensa
3. identificando um incidente ( um incidente e oquanto srio).
4. tratamento (o que deveria ser feito quando um incidente acontece).
* Notificao (quem deveria ser notificado sobre o incidente)
* Protegendo evidncias e logs de atividades (que registros deveriam ser mantidos de antes,
durante, e depois do incidente)

* Conteno (como o dano pode ser limitado)

* Erradicao (como eliminar as causas do incidente)
* Recuperao (como restabelecer servio e sistemas)
* Seqncia (que ao deveriam ser tomadas depois do incidente)
5. conseqncias (quais as implicaes de incidentes passados).
6. resposta administrativa para incidentes.
O resto deste captulo detalhar os assuntos envolvidos em cada dos tpicos importantes listados
acima, e prov alguma direo sobre o que deveria ser includo em uma poltica do site para tratar
incidentes.
5.1 Preparando e Planejando o Tratamento de Incidentes
Parte do tratamento de um incidente estar preparado para responder a um incidente antes dele
acontecer em primeiro lugar. Isto inclui estabelecer um nvel satisfatrio de protees como o explicado
nos captulos anteriores. Fazer isto ajudaria seu site a prevenir incidentes como tambm limitar dano
potencial resultante de incidentes. Proteo tambm inclui preparar diretrizes de tratamento de
incidentes como parte de um plano de contingncia para sua organizao ou site. Ter planos escritos
elimina muito da ambigidade que acontece durante um incidente, e conduzir a um conjunto mais
apropriado e completo de respostas. vitalmente importante testar o plano proposto antes de um
incidente acontecer atraves de "dry runs". Um grupo poderia considerar a contratao de um grupotigre at mesmo para agir em paralelo com o "dry runs" (Nota: um grupo-tigre um grupo de
especialistas que tentam penetrar a segurana de um sistema.)
1. Aprender a responder eficazmente a um incidente importante por um nmero de razes:
2. proteger os recursos que poderiam ser comprometidos
3. proteger os recursos que poderiam ser utilizados mais eficientemente se um incidente no
requeresse seus servios
4. seguir os regulamentos (do governo ou outros)
5. prevenir o uso de seus sistemas em ataques contra outros sistemas (que poderia implicar em
obrigaes legais)
6. minimizar o potencial para exposio negativa
Como em qualquer conjunto de procedimentos previamente planejados, deve ser dada a atenoa um
conjunto de objetivos para tratar incidentes. Estas metas tero prioridades diferentes dependendo do
site. Um conjunto especfico de objetivos pode ser identificado:
1. descobrir como aconteceu.
2. descobrir como evitar explorao adicional da mesma vulnerabilidade.
3. evitar a expanso e incidentes adicionais.
4. avaliar o impacto e dano do incidente.
5. recuperar-se do incidente.
6. atualizar polticas e procedimentos conforme necessrio.
7. descobrir quem fez isto (se apropriado e possvel).
Devido natureza do incidente, pode haver um conflito entre analisar a fonte original de um problema e
restabelecer sistemas e servios. Metas globais (como assegurar a integridade de sistemas crticos)
pode ser uma razo para no analisar um incidente. claro, esta uma deciso de administrao
importante; mas todas as partes envolvidas devem estar consientes que sem anlise pode o mesmo
incidente acontecer novamente.

Tambm importante priorizar as aes a ser tomadas durante um incidente com bastante
antecendncia antes do incidente acontecer. s vezes um incidente pode ser to complexo que
impossvel fazer tudo ao mesmo tempo para responder a ele; prioridades so essenciais. Embora
prioridades variem de instituio para instituio, as seguintes sugestes de prioridades podem servir
como ponto de partida para definir a resposta de sua organizao:
Prioridade 1 --proteja vida humana e segurana das pessoas; vida humana sempre tem precedncia
sobre outras consideraes.
Prioridade 2 -- proteger dados importantes. Previna explorao sistemas, redes ou locais importantes.
Informe sistemas, redes ou locais importantes que tenham sido afetados sobre invases acontecidas.
(Esteja atento aos regulamentos de seu site ou do governo)
Prioridade 3--proteja outros dados incluindo dados proprietrios, cientficos, administrativos e outros,
pois perda de dados cara em termos de recursos.Previna exploraes de outros sistemas, redes ou
locais e informe os sistemas, redes ou locais afetados sobre invases bem sucedidas.
Prioridade 4--previna dano para sistemas (por exemplo, perda ou alterao de arquivos de sistemas,
danos a unidades de disco, etc.). Danos em sistemas pode resultar em custo de recuperao alto.
Prioridade 5--minimize a interrupodos recursos de computao(inclusive processos). melhor em
muitos casos desligar um sistema ou desconecta-lo de uma rede que arriscar dano para dados ou
sistemas. Os sites tero que avaliar a melhor opo entre desligar e desconectar, manter o sistema
funcionando. Pode haver acordos de servios em lugares que podem requerer a manuteno dos
sistemas no ar mesmo com a possibilidade de danos adicionais. Porm, o dano e escopo de um
incidente podem ser to extensos que aqueles acordos de servio podem ter que ser ignorados.
Uma implicao importante para definir prioridades que uma vez que a vida humana e consideraes
de segurana nacionais foram previstas, geralmente mais importante salvar dados que software e
hardware. Embora indesejvel ter qualquer dano ou perda durante um incidente, sistemas podem ser
substitudos. Porm, a perda ou comprometimento de dados (especialmente classificados ou
proprietrios) normalmente no de forma alguma um resultado aceitvel.
Outra preocupao importante o efeito em outros, alm dos sistemas e redes onde o incidente
acontece. Dentro dos limites impostos por regulamentos governamentais sempre importante informar
as partess afetadas o mais cedo possvel. Devido s implicaes legais deste tpico, ele deveria ser
includo nos procedimentos planejados para evitar demoras adicionais e incertezas para os
administradores.
Qualquer plano para responder a incidentes de segurana deveria ser guiado por polticas locais e
regulamentos. Sites privados e do governo que lidem com material classificado tem regras especficas
que eles devem seguir.
As polticas escolhidas por seu site sobre como reagir a incidentes ir moldar sua resposta Por exemplo,
pode fazer pouco sentido criar mecanismos para monitorar e rastrear intrusos se o seu site no planeja
entrar em ao contra os intrusos caso eles sejam pegos. Outras organizaes podem ter polticas que
afetam seus planos. Companhias de telefone freqentemente liberam informaes sobre rastreamento
de telefones apenas para agncias responsveis pela execuo da lei.
Tratar incidentes pode ser tedioso e requerer qualquer nmero de tarefas rotineiras que poderiam ser
tratadas pelo pessoal de apoio. Para liberar o pessoal tcnico, til identificar pessoal de apoio que
ajudar com tarefas como: fotocopiar, passar fax, etc.
5.2 Notificao e Pontos de Contato
importante estabelecer contatos com vrias pessoas antes de um incidente real acontecer. Muitas
vezes, incidentes no so emergncias reais. Na realidade, com freqncia voc poder tratar as
atividades internamente. Porm, tambm haver muitas vezes quando outros fora de seu departamento
imediato precisaro ser includos no tratamento de incidentes. Estes contatos adicionais incluem os
gerentes locais e os administradores de sistemas, contatos administrativos para outros sites na Internet,
e vrias organizaes investigativas. Conhecendo estes contatos antes dos incidentes acontecerem
ajudar a fazer seu processo de tratamento de incidentes mais eficiente.
Para cada tipo de contato de comunicao, Pontos de Contato (POC) especficos deveriam ser definido.
Estes podem ser de natureza tcnica ou administrativa e podem incluir agncias legais ou investigativas
como tambm os provedores de servio e vendedores. Ao estabelecer estes contatos, importante
decidir quanta informao ser compartilhada com cada classe de contato. especialmente importante

definir, com antecedncia, que informao ser compartilhada com os usurios de um site, com o
pblico (inclusive a imprensa), e com outros sites.
Determinar estes assuntos especialmente importantes para a pessoa local responsvel por tratar o
incidente, j que essa pessoa responsvel pela notificao dos outros. Uma lista de contatos em cada
uma destas categorias representam uma economia de tempo importante para esta pessoa durante um
incidente. Pode ser bastante difcil achar uma pessoa apropriada durante um incidente quando muitos
eventos urgentes esto acontecendo. fortemente recomendado que os nmeros de telefone
pertinentes (tambm endereos de correio eletrnicos e nmeros de fax) sejam includos na poltica de
segurana do site. Os nomes e informaes de contato de todos os indivduos que estaro envolvidos
diretamente no tratamento de um incidente devem ser colocados no topo desta lista.
5.2.1 Gerentes locais e Pessoal
Quando um incidente est ocorrendo, uma questo importante decidir quem est encarregado de
coordenar a atividade dos diversos jogadores. Um dos maiores enganos que pode ser cometido ter
vrias pessoas cada qual trabalhando independentemente, mas no trabalhando junto. Isto s aumenta
a confuso do evento e provavelmente conduzir a esforo desperdiado ou ineficaz.
O nico POC pode ou no ser a pessoa responsvel por tratar o incidente. H dois papis distintos a
serem preenchidos quando se est decidindo quem ser POC e quem ser a pessoa encarregada do
incidente. A pessoa emcarregada do incidente tomar decises sobre a interpretao da poltica
aplicada ao evento. Em contraste, o POC deve coordenar os esforos de todas as partes envolvidas no
tratamento do evento.
O POC deve ser uma pessoa com percia tcnica para coordenar com sucesso os esforos dos gerentes
de sistemas e usurios envolvidos na monitorao e reao ao ataque. Cuidado deveria ser tomado ao
identificar quem ser esta pessoa. No deveria ser necessariamente a mesma pessoa que tem
responsabilidade administrativa pelos sistemas comprometidos uma vez que freqentemente tais
administradores tem conhecimento suficiente apenas para o uso dos computadores no dia-a-dia,
faltando-lhes conhecimento tcnico mais profundo.
Outra funo importante do POC manter contato com as autoridades legais competentes e outras
agncias externas para assegurar que o envolvimento multi-agncia. O nvel de envolvimento ser
determinado atravs de decises de administrao bem como por restries legais.
Um nico POC tambm deveria ser a nica pessoa encarregada de coletar evidncias, desde que como
regra geral, quanto mais pessoas tocam uma pea potencial de evidncia, o maior a possibilidade de
que esta seja inadmissvel no tribunal. Para assegurar que as evidncias sero aceitveis para a
comunidade legal, a coleta de evidncias deve ser feita seguindo-se procedimentos predefinedos, de
acordo com leis locais e regulamentos legais.
Um das tarefas mais crticas para o POC a coordenao de todos os processos pertinentes.
Responsabilidades podem ser distribudas sobre o site inteiro, envolvendo mltiplos departamentos ou
grupos independentes. Isto ir requerer um esforo bem coordenado para alcanar sucesso global. A
situao fica ainda mais complexa se mltiplos sites esto envolvidos. Quando isto acontece, raramente
um nico POC num site poder coordenar o tratamento do incidente inteiro adequadamente. Ao invs
disso, deveriam ser envolvidos grupos apropriados de resposta a incidentes.
O processo de tratamento de incidentes deveria prover alguns mecanismos de ampliao. Para definir
tal mecanismo, os sites precisaro criar um esquema de classificao interno para incidentes. Associado
a cada nvel de incidente estaro o POC e procedimentos apropriados. Conforme um incidente aumenta,
pode haver uma mudana do POC que precisar ser comunicada a todos os outros envolvidos no
tratamento do incidente. Quando uma mudana no POC acontece, o POC antigo deve fazer um resumo
para o POC novo sobre toda a informao background.
Finalmente, usurios tm que saber informar incidentes suspeitos. Os sites devem estabelecer
procedimentos de informe que iro funcionar durante e fora de horas de trabalho normais. "Help desks"
freqentemente so usadas para receber estes relatrios durante horas de trabalho normais, enquanto
beepers e telefones podem ser usados fora de hora.
5.2.2 Agncias de Investigao e de Execuo da Lei
No caso de um incidente que tem conseqncias legais, importante estabelecer contato com agncias
investigativas (por exemplo, o FBI e Servio Secreto nos E.U.A.) o mais cedo possvel. As autoridades
locais, escritrios de segurana locais, e departamento policial do campus tambm deveriam ser
informados conforme apropriado. Esta seo descreve muitos dos assuntos que sero confrontados,

mas reconhecido que cada organizao ter suas prprias leis e regulamentos locais e do governo
que tero impacto sobre como eles interagem com a execuo da lei e agncias investigativas. O ponto
mais importante que cada site precisa trabalhar estes assuntos.
Uma razo primria por determinar estes pontos de contato com antecedncia, antes de um incidente
que uma vez que um ataque maior est em progresso, h pouco tempo para chamar estas agncias
para determinar exatamente quem o ponto de contato correto. Outra razo que importante
cooperar com estas agncias de maneira a nutrir uma boa relao de trabalho, e a estar de acordo com
os procedimentos de trabalho destas agncias. Conhecer os procedimentos de funcionamento com
antecedncia, e as expectativas de seu ponto de contato um grande passo nesta direo. Por
exemplo, importante juntar evidncias que sero admissveis em qualquer procedimento legal
subseqente, e isto requer conhecimento anterior de como juntar tal evidncia. Uma razo final para
estabelecer contatos o mais cedo possvel que impossvel conhecer que agncia em particular
assumir a jurisdio em um dado incidente. Fazer contatos e achar os canais apropriados cedo faro a
resposta a um incidente transcorrer consideravelmente mais suavemente.
Se sua organizao ou site tem um conselho legal, voc precisa notificar esta entidade logo em seguida
que voc perceber que um incidente est ocorrendo. Nomnimo, seu conselho legal precisa estar
envolvido para proteger os interesses legais e financeiros de seu site ou organizao. Existem muitos
assuntos legais e prticos, alguns deles sendo:
(1) Se seu site ou organizao est disposta a arriscar publicidade ou exposio negativa para cooperar
com esforos de prossecuo legais.
(2) Obrigao "downstream"-se voc deixa um sistema comprometido como est para poder ser
monitorado e outro computador danificado porque o ataque se originou de seu sistema, seu site ou
organizao pode ser responsvel por danos incorridos.
(3) Distribuio de informao--se seu site ou organizao distribui informaes sobre um ataque no
qual outro site ou organizao pode ser envolvida ou a vulnerabilidade dm um produto isso pode afetar
a habilidade de comercializar aquele produto, seu site ou organizao pode ser novamente
responsabilizado por qualquer dano (incluindo dano de reputao).
(4) Obrigaes devido a monitorao--seu site ou organizao pode ser processada se usurios em seu
site ou em outro lugar descobrem que seu site est monitorando atividades das contas sem informar os
usurios.
Infelizmente, no h ainda nenhum precedente claro nas obrigaes ou responsabilidades de
organizaes envolvidas em um incidente de segurana ou quem poderia ser envolvido no apoio a um
esforo investigativo. Investigadores encorajaro freqentemente organizaes para ajudar a rastrear e
monitorar intrusos. Realmente, a maioria dos investigadores no pode procurar intruses de
computador sem apoio extenso das organizaes envolvidas. Porm, investigadores no podem prover
proteo contra reivindicaes de obrigao, e estes tipos de esforos podem se arrastar por meses e
tomar muito esforo.
Por outro lado, o conselho legal de uma organizao pode aconselhar precauo extrema e sugerir que
atividades de rastramento sejam detidas e um intruso mantido fora do sistema. Isto, em si mesmo,
pode no prover proteo de responsabilidades, e pode impedir os investigadores de identificar o
perpetrador.
O equilbrio entre apoiar atividade investigativa e limitar obrigao enganador. Voc precisar
considerar as sugestes de seu conselho legal e o dano que o intruso est causando (se algum) ao
tomar sua deciso sobre o que fazer durante qualquer incidente em particular.
Seu conselho legal tambm deveria ser envolvido em qualquer deciso para contactar agncias
investigativas quando um incidente acontece em seu site. A deciso para coordenar esforos com
agncias investigativas de seu site ou organizao. Envolver seu conselho legal tambm nutrir a
coordenao multi-nvel entre seu site e a agncia investigativa envolvida, o que resulta em uma
diviso eficiente de trabalho. Outro resultado que provvel que voc obtenha direcionamento que o
ajudar a evitar futuros enganos legais.
Finalmente, sua conselho legal deveria avaliar o procedimentos escritos de seu site para responder a
incidentes. essencial obter uma aprovao de uma perspectiva legal antes que voc de fato leve a
cabo estes procedimentos.
vital, quando lidando com agncias investigativas, verificar que a pessoa que chama pedindo
informao uma representante legtima da agncia em questo. Infelizmente, muitas pessoas bem

intencionadas tm vazado detalhes sensveis sobre incidentes sem perceber, permitido pessoas sem
autorizao nos sistemas, etc., porque um visitante disfarou-se como representante de uma agncia
governamental. (Nota: esta palavra de precauo na verdade se aplica a todos os contatos externos.)
Uma considerao semelhante envolve usar meios seguros de comunicao. Porque muitos atacantes
de rede podem desviar correio eletrnico facilmente, evite usar correio eletrnico para comunicar-se
com outras agncias (como bem com outros lidando com o incidente em questo). Linhas telefnicas
inseguras (os telefones normalmente usados no mundo empresarial) tambm so alvos freqentes para
escutas por intrusos de rede, logo tenha cuidado!
No h um conjunto estabelecido de regras para responder a um incidente quando o governo local
envolvido. Normalmente (nos E.U.A.), exceto atravs de ordem legal, nenhuma agncia pode o for-lo
a monitorar, desconectar da rede, evitar contato de telefone com os atacantes suspeitos, etc. Cada
organizao ter um conjunto de leis e regulamentos locais e nacionais aos quais devem ser aderidos
quando do tratamento de incidentes. recomendado que cada site esteja familiarizado com essas leis e
regulamentos, e identifique e conhea os contatos para agncias com jurisdio com antecedncia do
tratamento de um incidente.
5.2.3 Grupos de Tratamento de Incidentes de Segurana de Computadores
H atualmente vrios Grupos de Resposta a Incidentes de Segurana (CSIRTs) como o CERT
Coordination Center, o DFN-CERT alemo, e outros ao redor do globo. Esses grupos existem para muitas
agncias governamentais importantes e corporaes grandes. Se um desses grupos est disponvel,
notific-lo deveria ser de considerao primria durante as fases iniciais de um incidente. Estes times
so responsveis por coordenar incidentes de segurana de computador numa srie de de sites e
entidades maiores. At mesmo acreditando-se que o incidente est contido dentro de um nico site,
possvel que a informao disponvel por um grupo de resposta possa ajudar a solucionar o incidente
completamente.
Se determinado que a brecha aconteceu devido a uma falha no hardware do sistema ou software, o
vendedor (ou provedor) e um Grupos de Tratamento de Incidentes de Segurana de Computadores deve
ser notificado to logo possvel. Isto especialmente importante porque muitos outros sistemas so
vulnerveis, e este vendedor e gruopos de resposta podem ajudar a disseminar ajuda para outros locais
afetados.
Ao montar uma poltica de site para tratamento de incidente, pode ser desejvel criar um subgrupo,
semelhante aos que j existem, que ser responsvel por tratar de incidentes de segurana para o site
(ou organizao). Se tal grupo criado, essencial que linhas de comunicao sejam abertas entre este
gurpo e outros. Uma vez que um incidente ocorre, difcil abrir um dilogo confiante entres gurpos, se
no havia nenhum antes.
5.2.4 Sites Afetados e Envolvidos
Se um incidente tem um impacto em outros sites, informlos uma boa prtica. Pode ser bvio desde o
princpio que o incidente no limitado para o site local, ou isso pode s emergir depois de anlise
adicional.
Cada site pode escolher contatar outros sites diretamente ou passar a informao para um grupo de
resposta a incidentes apropriado. freqentemente difcil de achar o POC responsvel por sites
distantes e o grupo de resposta poder facilitar essecontato fazendo uso de j canais estabelecidos.
As questes legais e de obrigao que surgem de um incidente de segurana diferir de site para site.
importante definir uma poltica para o compartilhando e logging de informao sobre outros sites antes
que um incidente acontea.
Informao sobre pessoas especficas especialmente sensvel, e pode estar sujeito a leis de
privacidade. Para evitar problemas nesta rea, deveria ser apagada informao irrelevante e uma
declarao de como tratar a informao restante deveria ser includa. Uma declarao clara de como
esta informao ser usada essencial. Ningum que informa um aite sobre um incidente de segurana
quer ler sobre isto na imprensa pblica. Grupos de resposta a incidentes so valiosos neste sentido.
Quando eles passam informaes para POCs responsveis, eles podem proteger o anonimato da fonte
original. Mas, esteja atento que, em muitos casos, a anlise de logs e informaes em outros sites vai
revelar endereos de seu site .
Os problemas discutidos acima no deveriam ser considerados razes para no envolver outros sites.
De fato, as experincias de grupos existentes revelam que a maioria dos sites informados sobre
problemas de segurana nem mesmo haviam notado que seu site havia sido comprometido. Sem serem

informados a tempo, outros sites esto freqentemente impossibilitados entrar em ao contra intrusos.
5.2.5 Comunicaes internas
crucial durante um incidente grande, comunicar porque certas aes esto sendo tomadas, e como se
espera que os usurios (ou departamentos) se comportem. Em particular, deveria ser deixado muito
claro para os usurios o que lhes permitido dizer (e no dizer) para o mundo externo (incluindo outros
departamentos). Por exemplo, no seria bom para uma organizao se os usurios respondessem aos
clientes com algo como, " Eu lamento, os sistemas esto fora do ar, ns tivemos um intruso e ns
estamos tentand escalrecer as coisas". Seria muito melhor se ensinassem que eles respondessem com
uma declarao preparada como, " Lamento, nossos sistemas no esto disponveis, eles esto sendo
em manuteno para melhor servi-lo no futuro".
Comunicaes com os clientes e scios contratuais devem ser dirigidos de modo sennsato, mas
tambm sensvel. Uma pessoa pode se preparar para os assuntos principais preparando um cheklist.
Quando um incidente acontece, a lista pode ser usada com a adio de uma frase ou duas sobre as
circunstncias especficas do incidente.
Departamentos de relaes pblicos podem ser muito teis durante incidentes. Eles deveriam ser
envolvidos em todo o planejamento e podem prover respostas bem construdas para uso quando
contato de fora dos departamentos e organizaes so necessrios.
5.2.6 Relaes pblicas - "Press Releases"
Houve um tremendo crescimento na cobertura de mdia dedicada a incidentes de segurana de
computador nos Estados Unidos. Tal cobertura de imprensa est fadada a se estender a outros pases,
como a Internet continua crescendo e se expandindo internacionalmente. Leitores de pases onde tal
ateno da mdia ainda no aconteceu, podem aprender com as experincias dos E.U.A. e deveriam ser
avisados e preparado.
Um dos assuntos mais importantes a considerar quando, quem, e quanto liberar ao pblico em geral
pela imprensa. H muitos assuntos para considerar quando decidindo este ponto em particular. Primeiro
e antes de mais nada, se um escritrio de relaes pblicas existe para o site importante usar este
escritrio como ligao para a imprensa. O escritrio de relaes pblicas treinado no tipo e
formulao de informao a serem liberadas, e ajudar a assegurar que a imagem do site protegida
durante e depois do incidente (se possvel). Um escritrio de relaes pblicas tem a vantagem de que
voc pode se comunicar francamente com eles, e prov um pra-choque entre a ateno de imprensa
constante e a necessidade do POC para manter controle sobre o incidente.
Se um escritrio de relaes pblicas no est disponvel, a informao, lanado imprensa deve ser
considerada cuidadosamente. Se a informao sensvel, pode ser vantajoso s prover mnima
informao para a imprensa. bastante possvel que qualquer informao provida imprensa ser vista
depressa pelo perpetrador do incidente. Tambm note que enganar a imprensa pode sair pela culatra
freqentemente e pode causar mais dano que liberar informaes delicadas.
Enquanto difcil de determinar com antecedncia que nvel de detalhe prover imprensa, algumas
diretrizes para serem lembradas so:
(1) mantenha o nvel de detalhes tcnicos baixo. Informao detalhada sobre o incidente pode prover
bastante informao para outros lanarem ataques semelhantes em outros sites, ou at mesmo
danificar habilidade do sitel para processar a parte culpada uma vez que o evento terminou.
(2) Mantenha a especulao fora de declaraes de imprensa. Especulao sobre quem est causando o
incidente ou os motivos, est muito sujeita a erros e pode causar uma viso inflamada do incidente.
(3) Trabalhe com profissionais da lei para assegurar que a evidncia protegida. Se prossecuo for
envolvida, assegurar que a evidncia coletada no divulgada imprensa.
(4) Tente no ser forado a uma entrevista de imprensa antes de voc estar preparado. A imprensa
popular famosa pela "entrevista das 2 das manh", onde a esperana pegar o entrevistado
desprevenido e obter informao no disponvel em outras circunstncias.
(5) No permita que a ateno de imprensa diminua o tratamento do evento. Sempre se lembre que o
fechamento com sucesso de um incidente de importncia fundamental.
5.3 Identificando um Incidente

5.3.1 Real?
Esta fase envolve determinar se um problema realmente existe. Naturalmente muitos, se no a maioria,
dos sinais associados freqentemente com infeco de vrus, intruses de sistema, usurios maliciosos,
etc., simplesmente so anomalias tal como falhas de hardware ou comportamento de suspeito de
sistema/usurio. Para ajudar a identificar se realmente h um incidente, normalmente til obter e usar
qualquer software de deteco que possa estar disponvel. Informao de auditoria tambm
extremamente til, especialmente para determinar se h um ataque a rede. extremamente
importante obter um retrato instantneo do sistema assim que se suspeite que algo est errado. Muitos
incidentes levam uma cadeia dinmica de eventos a acontecer, e um retrato instantneo do sistema
inicial pode ser a mais valiosa ferramenta para identificar o problema e qualquer fonte de ataque.
Finalmente, importante comear um livro de log. Gravar eventos de sistemas , conversas de telefone,
timestamps, etc., pode conduzir a uma identificao mais rpida e sistemtica do problema, e a base
para fases subseqentes de tratamento de incidente.
H certas indicaes ou " sintomas " de um incidente que merecem ateno especial:
(1) Crashes de sistemas.
(2) Novas contas de usurio (a conta RUMPLESTILTSKIN foi criada inesperadamente), ou atividade alta
em uma conta previamente pouco usada.
(3) arquivos novos (normalmente com nomes de arquivo estranhos, como data.xx ou k ou .xx).
(4) discrepncias de contabilidade (em um sistema de UNIX pode voc notar a diminuio de um
arquivo de contabilidade chamado /usr/admin/lastlog, algo que o deveria muito desconfiado de que
pode haver um intruso).
(5) mudanas em tamanho ou data de arquivo (um usurio deveria desconfiar se .arquivos EXE em um
computador MS-DOS tenha inexplicavelmente aumentado mais de 1800 bytes).
(6) Tentativas de escrever em system (um gerente de sistema nota que um usurio privilegiado em um
sistema de VMS est tentando alterar RIGHTSLIST.DAT).
(7) modificao de dados ou apagamento (arquivos comeam a desaparecer).
(8) negao de servio (gerente de sistema e todos os outros usurios so impedidos de entrar num
sistema de UNIX, agora em modo de usurio nico).
(9) desempenho de sistema inexplicavelmente, baixo
(10) anomalias (GOTCHA " exibido no monitor ou h freqentes e inexplicveis "beeps ").
(11) sondas suspeitas (h numerosas tantativas de login sem sucesso de outro nodo).
(12) Browsing suspeito (algum se torna um usurio root em um sistema UNIX e acessa arquivos
arquivo aps arquivo em contas de muitos usurio.)
(13) inabilidade de um usurio para se logar devido a modificaes em sua conta.
De forma alguma esta lista completa; ns listamos apenas um certo nmero de indicadores comuns.
melhor colaborar com outro pessoal tcnico e de segurana de computador para tomar uma deciso
como um grupo sobre se um incidente est acontecendo.
5.3.2 Tipos e Escopo de Incidentes
Junto com a identificao do incidente, est a avaliao do mbito e impacto do problema. importante
identificar os limites do incidente corretamente para lidar efetivamente com ele e priorizar respostas.
Para identificar o escopo e impacto um conjunto de critrios deveria ser definido, o qual apropriado
para o site e para o tipo de conexes disponveis. Alguns dos pontos incluem:
(1) este um incidente multi-site?
(2) muitos computadores em seu site oram afetados por este incidente?

(3) h informao delicada envolvida?

(4) qual o ponto de entrada do incidente (rede, linha telefnica , trminal local, etc.)?
(5) a imprensa est envolvida?
(6) qual o dano potencial do incidente?
(7) qual o tempo calculado para encerrar o incidente?
(8) que recursos poderiam ser exigidos para tratar o incidente?
(9) h autoridades legais envolvidas?
5.3.3 Avaliando Dano e Extenso
A anlise do dano e extenso do incidente pode consumir muito tempo, mas deveria conduzir a alguma
idia sobre a natureza do incidente, e ajudar na investigao e prossecuo. Assim que a brecha tenha
acontecido, o sistema inteiro e todos seus componentes deveriam ser considerado suspeitos. Software
de sistema o alvo mais provvel. Preparao chave para poder descobrir todas as mudanas num
sistema possivelmente afetado. Isto inclui fazer checksum de todas os meios do vendedor usando um
algoritmo que resistente a falsificaes. (Veja sees 4.3)
Assumindo que meios de distribuio originais do vendedor esto disponveis, uma anlise de todos os
arquivos de sistemas deveria comear, e qualquer irregularidade deveria ser notada e deveria referida a
todas as partes envolvidas no tratamento do incidente. Pode ser muito difcil, em alguns casos, decidir
que meios de backup esto mostrando um estado de sistema correto. Considere, por exemplo que o
incidente pode ter continuado por meses ou anos antes de descoberta, e o suspeito pode ser um
empregado do site, ou que tenha conhecimento ntimo ou acesso aos sistemas. Em todos os casos, a
preparao antes do incidente determinar se a recuperao possvel.
Se o sistema suporta logs centralizados (a maioria o faz), volte para os logs e procure anormalidades.
Se contabilidade de processo e tempo de conexo estiver habilitada, procure padres de uso do
sistema. Numa menor extenso, o uso do disco pode jogar luz no incidente. Contabilidade pode prover
muita informao til em uma anlise de um incidente e prossecuo subseqente. Sua habilidade para
verificar todos os aspectos de um incidente especfico depende fortemente do sucesso desta anlise.
5.4 Tratando um Incidente
So necessrios certos passos durante o tratamento de um incidente. Em todas as atividades de
segurana relacionadas, o mais importante ponto ser feito que todos os sites deveriam ter polticas
no local.
Sem polticas e metas definidas, as atividades empreendidas permanecero sem enfoque. As metas
deveriam ser definidas com antecedncia pela administrao e com deliberao legal.
Um dos objetivos mais fundamentais restabelecer controle dos sistemas afetados e limitar o impacto
e dano. No pior caso, fechando o sistema, ou desconectando o sistema da rede, possa ser a nica
soluo prtica.
Como as atividades envolvidas so complexas, tente adquirir tanta ajuda quanto necessrio. Enquanto
tenta resolver o problema sozinho, danos reais podem acontecer devido a demoras ou a informaes
perdidas. A maioria administradores levam a descoberta de um intruso como um desafio pessoal.
Procedendo deste modo, outros objetivos como esboou em suas polticas locais sempre podem no ser
consideradas. Tentar pegar os intrusos pode ser uma prioridade muito baixa, se comparada a
integridade do sistema, por exemplo. Monitorar a atividade de um hacker til, mas pode no sido
considerado preo o risco para permitir o acesso continuado.
5.4.1 Tipos de Notificao e Troca de Informao
Quando voc confirmou que um incidente est acontecendo, o pessoal apropriado deve ser notificado.
Como esta notificao passada muito importante para manteno do evento sob controle ambos
pontos de vista, o tcnico e o emocional. As circunstncias devem ser descritas em tantos detalhes
quanto possvel para facilitar o pronto reconhecimento e entender o problema. Muito cuidado quando
determinar para quais grupos tcnicos a informao ser enviada durante a notificao.Por exemplo,

til passar este tipo de informao para um grupo de tratamento de incidentes pois eles podem lhe
ajudar com sugestes teis para erradicar as vulnerabilidades envolvidas em um incidente. Por outro
lado, pondo o conhecimento crtico no domnio pblico (por exemplo, por newsgroups de USENET ou
remetendo para listas) pode pr um nmero grande de sistemas potencialmente a risco de intruso.
nulo assumir que todos os administradores que lem um newsgroup particular tm acesso ao cdigo
fonte do sistema operacional, ou podem entender o bastante para fazer os passos adequados.
Em primeiro lugar, qualquer notificao para local ou pessoal de fora do site deve ser explcito. Isto
requer que qualquer declarao (seja isto uma mensagem de correio eletrnico, telefonema, fac-smile,
beeper, ou semaphone) provendo informao sobre o incidente seja clara, concisa, e completamente
qualificada. Quando voc est notificando outros que o ajudaro a tratar um evento, uma "tela de
fumaa" s dividir o esforo e criar confuso. Se uma diviso de trabalho sugerida, til prover
informaes para cada participante sobre o que est sendo realizado em outros esforos. Isto no s
reduzir duplicao de esforos, mas permite que as pessoas que trabalham em partes do problema
possam saber onde obter informaes pertinentes a parte deles no incidente.
Outra considerao importante quando comunicar sobre o incidente ser efetivo. Tentar esconder
aspectos do incidente provendo falsa ou incompleta informao no s podem evitar uma soluo com
sucesso para o incidente, mas pode at mesmo piorar a situao.
A escolha do idioma usado quando notificar as pessoas sobre o incidente pode ter um efeito profundo
no modo que informao recebida. Quando voc usa termos emocionais ou inflamatrios, voc eleva
o potencial para dano e resultados negativos do incidente. importante permanecer tranqilo ambos as
comunicaes escrita e falada.
Outra considerao que nem todas as pessoas falam o mesmo idioma.
Devido a este fato, podem surgir enganos e demora, especialmente se um incidente multi-nacional.
Em outras preocupaes internacionais inclua a diferena nas implicaes legais de um incidente de
segurana e diferenas culturais. Porm, diferenas culturais no s existem entre pases. Elas
igualmente existem dentro de pases, entre diferente grupos sociais ou de usurios. Por exemplo,
administrador de um sistema universitrio muito relaxado sobre tentativas para conectar o sistema
por telnet, mas provvel que o administrador de um sistema militar considere a mesma ao como
um possvel ataque.
Outro assunto associado com a escolha de idioma a notificao de pessoas no tcnicas ou de fora do
site. importante descrever o incidente com preciso sem gerar alarme imprprio ou confuso.
Enquanto mais difcil de descrever o incidente a uma conjunto de pessoas no-tcnicas,
freqentemente mais importante. Uma descrio no-tcnica pode ser requerida pela administrao de
nveis superiores, a imprensa, ou instituies responveis pela execuo de lei. A importncia destas
comunicaes no pode ser menosprezada e pode fazer a diferena entre a soluo do incidente
corretamente ou eleva-lo a algum nvel mais alto de dano.
Se um grupo de resposta a incidentes envolvido, poderia ser necessrio preencher um modelo para a
troca de informao. Embora isto possa parecer ser um fardo adicional e possa somar uma certa
demora, isto, ajuda o grupo para agir neste mnimo conjunto de informao. O grupo de resposta
poder responder a aspectos do incidente do qual o administrador local desavisado. Se a informao
dada para uma pessoa de fora ento, esta pessoa deveria ter um mnimo de informao contando o
seguinte:
1. timezone de logs,... em GMT ou hora local
2. informao sobre o sistema remoto, inclusive nomes de host, endereos IP e (talvez) IDs de
usurios
3. todas as entradas de log relevantes para o local distante
4. tipo de incidente (o que aconteceu, por que se voc deveria se preocupar)
Se informaes locais (i.e., IDs de usurios locais) so includas nas entradas de logs, ser
anteriormente necessrio a **sanitize** as entradas para evitar assuntos de isolamento. Em geral, toda
a informao que poderia ajudar um local distante solucionando um incidente deveria ser distribudas, a
menos que polticas locais proibem isto.
5.4.2 Protegendo as Evidncias e Logs de Atividade
Quando voc responde a um incidente, documente todos os detalhes relacionados ao incidente. Isto

prover valiosa informao para voc e outros como voc tentando desvendar o curso dos eventos.
Documentando todos os detalhes economizaro em ltima instncia, seu tempo. Se voc no
documenta todos os telefonemas importantes, por exemplo, provvel que voc esquea uma poro
significante de informao voc obtm o que requer que voce contacte a fonte de informao
novamente. Ao mesmo tempo, detalhes armazenados provero evidncias para esforos de
prossecuo e provero os movimentos naquela direo. A documentao de um incidente tambm lhe
ajudaro a executar uma taxa final de dano (algum da administrao, como tambm instities de
execuo de lei, podero querer saber), e prover a base para mais recentes fases do processo de
tratamento de incidentes:
erradicao, recuperao, e seqncia, "lies aprendidas".
Durante as fases iniciais de um incidente, freqentemente imprevisvel determinar se a prossecuo
vivel, assim voc deveria documentar como se voc pois est juntando evidncias para um caso de
tribunal. Um mnimo, voc dever registrar:
todos os eventos de sistemas (registros de auditoria)
todas as aes que voc fez (tempo usado)
todas as conversaes externas (inclusive a pessoa com quem voc falou, a data e tempo, e o
contedo da conversao)
O modo mais direto para manter documentao mantendo um livro de log. Isto lhe permite ter uma
centralizada e cronolgica fonte de informao quando voc precisar disto, em vez do requerer, chame
por folhas individuais de papel. Muitas destas informaes so evidncias potenciais em um tribunal de
lei. Assim, quando um procedimento legal uma possibilidade, a pessoa deveria seguir os
procedimentos preparados e evitar por em perigo o procedimento legal por manipulao imprpria de
possvel evidncia. Se apropriado, os passos seguintes podem ser levados.
1. regularmente (por exemplo, diariamente) fazer cpias assinadas de seu logbook (como tambm
mdias que voc usa para registrar eventos de sistemas) para um adminitrador de documentos.
2. adminitrador deveria armazenar estas pginas copiadas em um seguro lugar (por exemplo, uma
caixa forte).
3. quando voc submete informao para armazenamento, voc deve receba um recibo datado e
assinado pelo administrador do documento.
Fracasso para observar estes procedimentos pode resultar em invalidao de qualquer evidncia que
voc obtm em um tribunal de lei.
5.4.3 Reteno
O propsito de reteno limitar a extenso de um ataque. Uma parte essencial de reteno deciso
do que fazer (por exemplo, determinando desligar um sistema, desconectar da rede, monitorar
sistemas ou atividades de rede, set traps, incapacitar funes como transferncia de arquivo remotoss,
etc.).
s vezes esta deciso trivial; desligar o sistema se a informao secreta, importante, ou
proprietria. Tenha em mente que isso remove todo o acesso enquanto um incidente est em
prograsso, obviamente notifique todos os usurios, inclusive os usurios que alegaram problemas, que
os administradores esto atentos ao problema; isto pode ter um efeito danoso uma investigao. Em
alguns casos, prudente remover todo o acesso ou funcionalidade o mais cedo possvel, ento
restabelea operao normal em fases limitadas. Em outros casos, vale a pena arriscar algum dano
para o sistema, se manter o sistema poderiam habilitar voc identificar o intruso.
Esta fase deveria se desenvolver levando a cabo procedimentos predeterminados.
Sua organizao ou site devem, por exemplo, definir riscos aceitvel lidando com um incidente, e
deveria prescrever aes especficas e estratgias adequadas. Isto especialmente importante quando
uma deciso rpida necessria e no possvel contactar todas as partes envolvidas primeiro para
discutir a deciso. Na ausncia de procedimentos predefinidos, a pessoa no cargo do incidente no ter
freqentemente o poder para tomar decises de administrao difceis (como perder os resultados de
uma experincia cara desligando um sistema). Uma atividade final que deveria acontecer durante esta
fase de tratamento do incidente a notificao de autoridades apropriadas.

5.4.4 Erradicao
Uma vez que o incidente foi contido, tempo para erradicar a causa. Mas antes de erradicar a causa,
deveria ser tomado grande cuidado colecionar todas as informaes necessrias sobre os sistemas
comprometidos e a causa do incidente como elas sero provavelmente sero perdidas quando o
sistema for limpo.
Softwares podem estar disponveis para ajudar no processo de erradicao, como software de anti-vrus.
Se qualquer falso arquivos foram criados, devem ser apagados. No caso de infeces de vrus,
importante limpar e reformatar qualquer mdia que contm arquivos infetados. Finalmente, assegura
que todos os backups esto limpos. Muitos sistemas infetados com vrus ficam periodicamente rinfetados simplesmente porque as pessoas no erradicam o vrus do backup. Depois de erradicao,
deveria ser feito um novo backup.
Removendo todas as vulnerabilidades uma vez um incidente aconteceu difcil. A chave para remover
vulnerabilidades conhecimento e entendimento da brecha.
Pode ser necessrio voltar para as mdia de distribuio originais e r-customizar o sistema. Para
facilitar esta situao de pior caso, um registro do setup do sistema original e de cada mudana de
customizao deveria ser mantido. No caso de um ataque baseado na rede, importante instalar
remendos para cada vulnerabilidade de sistema operacional que foi explorado.
Como discutido na seo 5.4.2, um log de segurana pode ser muito valioso durante esta fase de
remover vulnerabilidade. Os logs que mostram como o incidente foi descoberto e foi contido pode ser
usado para ajudar depois a determinar qual a extenso do dano de um determinado incidente. O passos
podem ser usados no futuro para ter certeza que o problema no ir ocorrer. Idealmente, a pessoa
deveria automatizar e regularmente deveria aplicar o mesmo teste como foi usado para descobrir o
incidente de segurana.
Se uma vulnerabilidade particular isolada como explorada, o prximo passo achar um mecanismo
para proteger seu sistema. A segurana que remete listas e boletins seria um lugar bom para procurar
esta informao, e voc pode obter conselhos dos grupos de resposta a incidentes.
5.4.5 Recuperao
Uma vez que a causa de um incidente foi erradicada, a fase de recuperao define a prxima fase de
ao. A meta de recuperao retornar o sistema ao normal. Em geral, expondo servios na ordem de
demanda e com um mnimo de inconvenincia aos usurio a melhor prtica. Entenda que os
procedimentos de recuperao formais para o sistema extremamente importante e deveria ser
especfico para o site.
5.4.6 Acompanhamento
Uma vez que voc acredita que o sistema foi restabelecido a um " estado seguro ", ainda possvel que
buracos, e at mesmo armadilhas, podem estar espreitando o sistema. Uma das fases mais importantes
de respostas a incidentes tambm freqentemente omitida, a fase de acompanhamento. Na fase de
acompanhamento, o sistema deveria ser monitorado para itens que podem ter sido perdidos durante a
fase de limpeza. Seria prudente utilizar algumas das ferramentas mencionados captulo 7 como um
comeo.
Lembre-se, estas ferramentas no substituem uma monitorao continuada do sistema e boas prticas
de administrao de sistemas.
O elemento mais importante da fase de seguimento executar uma anlise de pos morte. Exatamente
o que aconteceu, em que momento? Como foi o desempenho do pessoal envolvido com o incidente?
Que tipo de informao foi necessria rapidamente para o pessoal, e como eles obtiveram aquela
informao o mais cedo possvel? O que faria o pessoal diferentemente da prxima vez?
Aps um incidente, prudente escrever um relatrio que descreve a sucesso exata de eventos: o
mtodo de descoberta, procedimento de correo, procedimento de monitorao, e um resumo da lio
aprendida.
Isto ajudar na compreenso clara do problema. Criando uma cronologia formal de eventos (inclusive
time stamps) tambm importante por razes legais.
Um relatrio de seguimento valioso por muitas razes. Prov uma referncias a serem usadas no caso
de outros incidentes semelhantes. Tambm importante para que, to depressa quanto possvel

obtenha-se uma estimativa da quantia monetria dos danos que o incidente causou. Esta estimativa
deve incluir custos associados com qualquer perda de software e arquivos(especialmente o valor de
dados proprietrio que podem ter sido descoberto), dano de hardware, e fora de trabalho usada para
restabelecer arquivos alterados, reconfigure sistemas afetados, e assim sucessivamente. Esta
estimativa pode se tornar a base para atividade de prossecuo subseqente. O relatrio tambm pode
ajudar justifique o esforo de segurana dos computadores de uma organizao para administrao.
5.5 Resultado de um Incidente
Aps um incidente, deveriam acontecer vrias aes. Estas aes podem ser resumidas nas seguintes:
1. um inventrio deveria ser feito dos recursos dos sistemas,(i.e., um exame cuidadoso deveria
determinar como o sistema foi afetado pelo incidente).
2. as lies aprendidas como resultado do incidente deveria ser includo em plano de segurana
revisado para impedir o incidente de r-acontecer.
3. uma anlise de risco nova deveria ser desenvolvida levando em conta o incidente.
4. uma investigao e prossecuo dos indivduos que causaram o incidente deveria comear, se
julgado desejvel.
Se um incidente est baseado em poltica pobre, e a menos que a poltica seja mudada, voc ento
sentenciado repetir o passado. Uma vez que um site se recuperou de um incidente deveriam ser
revisadas a poltica do site e os procedimentos para cercar mudanas para prevenir incidentes
semelhantes. At mesmo sem um incidente, seria prudente revisar polticas e procedimentos com uma
base regular. Revises so imperativas devido aos ambientes de computao variveis de hoje.
O propsito inteiro deste processo de pos morte melhorar tuda a segurana para proteger o site
contra ataques futuros. Como resultado de um incidente, um site ou organizao ganhar conhecimento
prtico da experincia. Uma meta concreta do pos morte desenvolver novos mtodos de proactive.
Outra faceta importante do resultado pode ser a educao do usurio final e administrador para
prevenir a nova ocorrncia do problema de segurana.
5.6 Responsabilidades
5.6.1 No cruzando a Linha
uma coisa para proteger a sua prpria rede, mas outra assumir que deveria proteger outras redes.
Durante o tratamento de um incidente, certas vulnerabilidades dos prprios sistemas e os sistemas de
outros ficam aparentes. bastante fcil e pode ser tentado a procurar os intrusos para localiza-los.
Persista em mente que isso em um certo ponto possvel cruzar a linha e, com a melhor das intenes,
no se torne melhor que o intruso.
A melhor regra quando vem a decoro no usar facilidades de locais distantes que no so pblicos.
Isto exclui qualquer entrada claramente sobre um sistema (como uma concha distante ou sesso de
login) que no permitido expressamente. Isto pode ser muito tentador depois de uma brecha de
segurana descoberta, um administrador de sistema pode ter os meios para fazer isto, averiguar que
danos pode estr danificando o site remoto. No fa

6. Atividades em andamento
Neste momento, seu site esperanosamente desenvolveu uma poltica completa de
segurana bem como os procedimentos para assistir na configurao e
gerenciamento da sua tecnologia no suporte destas polticas. Como seria bom se
voc pudesse sentar e relaxar neste momento j que voc concluiu com o trabalho
de segurana. Infelizmente isto no possvel. Os seus sistemas e redes no so
um ambiente esttico, ento voc ter que rever suas polticas e procedimentos nos
seus fundamentos. H um nmero de passos que voc pode seguir para ajuda-lo a
manter as mudanas sob controle de forma a poder tomar as aes
correspondentes. A seguir apresentado um conjunto inicial de passos ao qual voc
pode adicionar outros de forma a ajust-lo ao seu site.
(1) Assine as publicaes que so editadas por vrios times de resposta a
incidentes de segurana, como os Centros de Coordenao CERT, e atualize os
seus sistemas contra as ameaas que se aplicam tecnologia do seu site.
(2) Mantenha-se atualizado sobre os patches produzidos pelos vendedores do
seu equipamento e obtenha e instale os que se aplicam ao seu sistema.
(3) Mantenha sob vigilncia as configuraes do seu sistema para identificar
qualquer mudana que possa ter ocorrido e investigar anomalias.
(4) Revise todas as polticas de segurana e procedimentos anualmente (no
mnimo).
(5) Leia os mailing lists relevantes e USENET newsgroups para manter-se
atualizado das ltimas informaes compartilhadas pelos colegas de classe.
(6) Verifique regularmente por polticas e procedimentos complacentes. Esta
auditoria deve ser feita preferencialmente por algum que no tenha
participado da definio ou implementao destas polticas ou procedimentos.

Captulo 7 - Ferramentas e Endereos

Este captulo prov uma breve lista de tecnologias de segurana disponveis
publicamente que podem ser buscadas da Internet. Muitos dos itens descritos
abaixo sem dvida estaro ultrapassados ou obsoletos antes que este documento
seja publicado.
Algumas das ferramentas listadas so aplicaes tais como programas de usurio
final (clientes) e suas infraestruturas de sistemas de suporte (servidores). Outras
so ferramentas que um usurio em geral nunca ir ver ou precisar usar, mas talvez
sejam utilizadas pelas aplicaes, ou pelos administradores para resolver problemas
de segurana ou para previnir contra invasores.
Um triste fato que h muito poucas aplicaes disponveis conscientes a respeito
de segurana. A princpio, isto causado pela necessidade de uma infraestrutura de
segurana que deve primeiro ser inserida na maioria das aplicaes para que
operem com segurana. H um considervel esforo atualmente disposto a construir
esta infraestrutura para que as aplicaes possam tirar vantagens de comunicaes
seguras.
A maioria das ferramentas e aplicaes descritas abaixo podem ser encontradas em
um dos seguintes sites:
1. CERT Coordination Center
ftp://info.cert.org:/pub/tools
2. DFN-CERT
ftp://ftp.cert.dftp://info.cert.org:/pub/toolfn.de/pub/tools/
3. Computer Operations, Audit, and Security Tools (COAST)
coast.cs.purdue.edu:/pub/tools
importante notar que muitos sites, incluindo CERT e COAST encontram-se
espelhados pela Internet. Tenha o cuidado de usar um site espelhado "bem
conhecido" para buscar software, e de usar ferramentas de verificao (md5
checksums, etc.) para valid-los. Um cracker pode anunciar um software de
segurana que seja intencionalmente projetado para prover acesso a dados ou
sistemas.
Ferramentas e Links
COPS
What is Cops?
FTP Index
DES
Columbus Media Incorporated - Security
Drawbridge
Drawbridge

Newsgroup Message (alt.security)

Drawbridge FAQ
identd (not really a security tool)
Identd Notes
ISS
Internet Security Systems
ISS Security Library
FTP Index
Kerberos
Kerberos Takes Bite Out of Intruders
Kerberos - what is it and where did it come from?
logdaemon
FTP Index
APS logDaemon and Client Library
lsof
FTP Index
Newsgroup Message (comp.security.unix)
Software Porting & Archive Centre for HP-UX
MD5
Keyed MD5
PEM
OSISEC PEM
PEM Page
PGP
Pretty Good Privacy, Inc. Home Page
MIT distribution site for PGP
Columbus Media Incorporated - Security
Pretty Good Privacy
The International PGP Home Page
rpcbind/portmapper replacement
DFN-CERT Informationsbulletin
SATAN
SATAN-ism: Computer Security Probes Over the Internet
Security Administrator Tool for Analyzing Networks
sfingerd
DFN-CERT Informationsbulletin
FTP Index
S/KEY
Description of The S/KEY One-Time Password System
Technical Overview of S/KEY
Bellcore: Security Products: S/Key
smrsh
The HP-UX Porting and Archive Center
Task 435 - Documentation & Procedures
What is smrsh and where can I get it?
ssh
SSH (Secure Shell) FAQ - Frequently Asked Questions
SSH Newsgroup
swatch
SUNET's Index
FTP Index
TCP-Wrapper
CHAPTER 5 Network Security

TCP WRAPPERS
In The Public Domain - October 1994
tiger
FTP Index
Tripwire*
Tripwire Slide
FTP Index
TROJAN.PL
FTP Index

8. Mailing lists e outras fontes de informao

Seria impossvel listar todos os mailing lists e outras fontes de informao que
tratam de segurana. Entretanto, aqui apresentamos alguns endereos que podem
ser o ponto de incio para o leitor. Fontes de informaes mais especficas podem
ser encontradas atravs destas referncias.
(1) CERT (tm) Advisory Enviar mail para: cert-advisory-request@cert.org Corpo da
mensagem: subscribe cert O CERT advisory fornece informaes sobre como obter
patches ou detalhes sobre o que fazer a respeito de um problema de segurana. O
Centro de Coordenao CERT trabalha com os vendedores que produziram um
procedimento ou patch para um problema, e no publicam informaes de
vulnerabilidade at que tenham um procedimento ou patch disponvel. O CERT
advisory tambm divulga informaes sobre ataques que esto ocorrendo (ex: "CA91:18.Active.Internet.ftp.Attacks"). O CERT advisory tambm publicado em
USENET newsgroup: comp.security.announce Os arquivos do CERT advisory esto
disponveis no FTP anonymous : info.cert.org no diretrio /pub/cert_advisories.
(2) VRUS-L List Enviar mail para: listserv%lehiibm1.bitnet@mitvma.mit.edu Corpo
da mensagem: subscribe vrus-L FIRSTNAME LASTNAME VRUS-L uma lista de
mails moderada focada em vrus de computadores. Para mais informaes,
incluindo uma cpia das normas, veja o arquivo "vrus-l.README", disponvel para
anonymous FTP em cs.ucr.edu.
(3) Internet Firewalls Enviar mail para: majordomo@greatcircle.com Corpo da
mensagem: subscribe firewalls user@host Esta lista de mails um frum de
discusso destinada a administradores e implementadores de Firewalls.
USENET newsgroups
(1) comp.security.announce
Este newsgroup moderado e usado somente para distribuio do CERT advisory
(2) comp.security.misc
Este newsgroup um frum para discusso sobre segurana em computadores,
especialmente relacionados ao sistema operacional UNIX(r).
(3) alt.security
Este newgroup tambm um frum para discusso sobre segurana de
computadores, bem como outros assuntos como travas de carros e sistemas de
alarmes.
(4) comp.virus
Este newsgroup tambm moderado com foco em vrus de computadores. Para
mais informaes incluindo uma cpia das normas, veja o arquivo "virus-l.README",
disponvel via anonymous FTP em info.cert.org no diretrio /pub/virus-l.
(5) comp.risks
Este newgroup um frum moderado focado nos riscos das publicaes em
computadores e sistemas relacionados.
Pginas World-Wide Web
(1) http://www.first.org/
Computer Security Resource Clearinghouse. O foco principal desta pgina est nos

assuntos relacionados com segurana, vulnerabilidades e soluces. Ao mesmo

tempo, a Clearinghouse empenha-se para torna-se um ndice geral para segurana
em computadores em uma ampla gama de assuntos, incluindo riscos gerais,
privacidade, publicaes legais, vrus, confiabilidade, polticas, e treinamento.
(2) http://www.telstra.com.au/info/security.html
Este ndice de referncia contm uma lista de links para sites com informaes
sobre Redes e segurana de computadores. No h nenhuma convenincia implcita
para as ferramentas, tcnicas e documentos contidos neste arquivo. Muitos, seno
todos os itens funcionam bem, mas ns no garantimos que isto vai acontecer
sempre. Estas informaes so para uso na educao e somente legitimam o uso
para as tcnicas de segurana de computadores.
(3) http://www.alw.nih.gov/Security/security.html
Esta pgina possui informaes gerais sobre segurana de computadores. As
informaes so organizadas por origem e cada sesso organizada por tpico.
Mudanas recentes so mostradas na pgina What's New.
(4) http://csrc.ncsl.nist.gov
Este arquivo est armazenado no National Institute of Standards and Technology's
Computer Security Resource Clearinghouse e contm um nmero de notcias,
programas, e documentos relacionados com segurana de computadores. * CERT
eTripwire so registrados no U.S. Patent and Trademark Office.

RFC 2196
Site Security HandBook

1. Introduo
2. Polticas de Segurana
3. Arquitetura:
Parte 1 - Plano de segurana
Parte 2 - Proteo de servios
4. Servios de Segurana e Procedimentos:
4.1 Servios e procedimentos seguros
4.1 Autenticao
4.2 Confiana
4.3 Integridade
4.4 Autorizao
4.5 Acesso
4.6 Auditoria
4.7 Protegendo Backups
5. Tratamento de Incidentes de Segurana
6. Atividades em Andamento
7. Ferramentas e Endereos
8. Mailing list

Traduo elaborada durante o desenvolvimento da disciplina Gerncia de Redes no

Curso de Ps-Graduao Cincia da Computao - UFRGS. Trabalharam na traduo
os seguintes alunos:
Alexis Rockenbach (cap 2)
Ana Carolina Hermann (cap 5)
Fbio Ribas Ardeola (cap 1)
Gerson Battisti (cap 5)
Lara Vanusca Thoma Goulart (cap 3b)
Luis Roberto Ulbrich (cap 4a)
Luiz Gustavo Anflor Pereira (cap 3a)
Marcio D'Avila Scheibler (cap 4b)
Ricardo Dastis (cap 7)
Rogrio Sachett (cap 6 e 8)