Politicas Seguranca

www.projetoderedes.kit.
net
Polticas de Segurana
Neste documento h uma srie de referncias para polticas de segurana. Seguidamente, estas referncias
incluiro recomendaes para polticas especficas.
Introduo:
2.1 - O que uma poltica de segurana? Pr 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.
Pr exemplo, seus objetivos provavelmente sero muito diferentes dos que so definidos pr 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 pr conseguinte inseguras) quanto possvel. Se pr 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 pr 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 pr
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 pr 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
1
www.projetoderedes.kit.net
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. Pr exemplo,
uma AUP pode lista newsgroups USENET proibidos.
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 indivduos 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.
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 (pr exemplo, mensagens de conexo devem oferecer aviso
sobre o uso autorizado, e monitorao de linha, e no simplesmente "welcome".
2
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 (pr 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.
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 pr 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 determinadas para a sua existncia. Pr 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. Pr 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 refere 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.
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. Pr 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. Pr
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 pr 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 importante lembrar que
segurana to forte quanto a corrente em relao ao menor elo. Muitos dos
ataques conhecidos nos anos recentes tm sido feitos pr 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.
4
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. Pr 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 pr 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 abrindo-se
novas portas ao mundo interno. Servios providos pela mesma mquina podem interagir de modos
catastrficos, pr 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 pr 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.
5
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 transmitir pacotes adiante, ou transmiti-los de forma
errada. Isso pode ser feito devido a uma m configurao, a injeo de atualizao daninha de informao
de roteamento, 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 retransmitisse, ou gerar pacotes de erro, cada um tambm
repetido pelas outras estaes. Um ataque deste tipo bem feito pode sempre gerar uma exploso
exponencial de transmisses.
Um outro ataque o "spoofing". Neste caso, pacotes malficos 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 de protocolos
como RIP-2 e OSPF. Existem 3 nveis de proteo: senha textual, checksum criptografado e criptografia.
Senhas oferecem a mnima proteo contra intrusos que no tm acesso rede fsica. Tambm protegem
roteadores mal configurados (ou seja, roteadores 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 pr um intruso ou roteador
mal configurado. O melhor prover criptografia completa das seqncias, ou unicamente identificadas,
tabelas de roteamento. 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 "flooding" , 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 requerimentos de segurana, que vo variar
baseado no uso do servio. Pr 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 pr usurios da Internet, requer uma forte proteo, para impedir que se modifique o
banco de dados da Web pr pessoas externas rede.
Servios internos (usados pelos usurios do site) e servios externos (deliberadamente permitidos para
uso pr 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. Claro, h usualmente
6
firewalls conectando estes conjuntos. Um grande cuidado deve-se tomar a fim de garantir o
funcionamento correto da firewall.
H um grande interesse em se usar intranets na conexo 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. Ele pode
ser tanto pr FTP ou pr login guest (no autenticado). importante manter esses acessos isolados de
hosts e sistemas de arquivos que no devem ser vistos pr usurios externos. Outro cuidado especial diz
respeito ao acesso annimo com permisso de escrita. Um site deve ser legalmente responsvel pela
informao pr ele tornada pblica, portanto informaes colocadas pr 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 freqentemente usados, so os principais alvos de ataques. E um ataque em um
destes servios pode produzir um desastre alm das propores do servio bsico.
3.3 Firewalls
Uma das medidas de segurana mais amplamente empregada e publicada em uso na Internet um
"firewall". Firewalls tem sido determinados a reputao de 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 qualquer 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 (pr 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, pr exemplo, e outra parte, a Internet global, pr 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
7
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 (projetada para otimizar filtros, 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 de 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), para outros servios (pr exemplo, Telnet, FTP, etc.), servidores proxy podem ser usados para
permitir acesso aos recursos atravs do firewall de modo seguro.
Um servidor 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 ento iniciar a conexo atravs de um formato especfico.
Existem significantes benefcios de segurana 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. Pr
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 cujos nicos pontos de acesso esto na Internet.
Firewalls so pensados como uma maneira de manter intrusos do lado de fora, mas eles 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.
8
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: escreva uma vez, leia muitos (WORM) drives; 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 $10,000US e alcanam mais de $250,000US. Firewalls desenvolvidos pelo prprio
site podem ser construdos para quantias menores de capital. 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 significante habilidade e
conhecimento do TCP/IP. Isto no deveria ser tentado trivialmente pois a sensao de segurana
percebida pior ao longo da execuo 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.
O que e como funciona o principal dispositivo de segurana na Internet.
Segurana ainda o ponto mais discutido na Internet, mas, em grande parte dos casos, a discusso se
resume a problemas como violao de correspondncia e dificuldades para se enviar nmero de carto de
credito. medida que a maior parte das empresas conecta suas redes privadas grande rede, entretanto, a
questo fundamental passa a ser como impedir que usurios no autorizados ganhem acesso livre a dados
sensveis. O principal meio de proteger as redes privadas so os chamados firewalls.
Um firewall um sistema ou grupo de sistemas atravs do qual flui o trafego de dados entre duas redes
distintas de computadores, permitindo que se implemente uma poltica de segurana que determine o que
pode ou no passar de uma rede para outra. A aplicao mais comum de um firewall proteger uma rede
contra acesso dos inmeros usurios mal-intencionados (chamados crackers) que povoam a Internet.
Mais especificamente, o firewall um dispositivo de hardware dotado de duas placas de rede (uma ligada
a rede corporativa e a outra ligada Internet) rodando software especifico de analise e roteamento de
pacotes. Como todo pacote enviado de uma rede a outra passa obrigatoriamente pelo sistema, o firewall
tem a chance de analis-lo, determinar se ele representa algum risco e, se for o caso, descart-lo antes que
ele possa alcanar seu destino.
Os critrios utilizados para decidir se determinado pacote de dados oferece ou no risco fazem parte a
poltica de segurana praticada pela entidade proprietria do firewall. Existem firewalls que operam na
camada de rede analisando pacotes IP e outros que operam na camada de aplicao analisando os
dados dentro dos pacotes IP. Alguns firewalls so to restritos que deixam passar apenas mensagens de
correio, enquanto outros so bem permissivos. Como seria de se esperar, quanto mais diligente e rigoroso
for o firewall, mais difcil ser penetrar um ataque e mais facial ser investig-lo posteriormente.
9
Firewall no nvel de rede

Firewalls de rede se restringem ao nvel do IP, decidindo que pacotes devem passar e que pacotes devem
ser descartados com base nos dados constantes do cabealho do pacote informaes como endereo de
remetente, endereo de destinatrio e a porta IP utilizada. A porta um campo de dois bytes contendo um
nmero inteiro que indica a mquina destinatria qual o programa que deve manipular o pacote recebido
( o SMTP, protocolo de correio da Internet, pr exemplo, usa a porta 25).
At um roteador comum pode ser configurado para agir como um firewall de rede se bem que ser um
firewall simples, j que roteadores tradicionais no costumam ser muito sofisticados e freqentemente
no conseguem determinar de onde um pacote efetivamente veio ou que tipo de informao ele est
carregando. Um roteador comum, que se preocupa apenas em enviar os pacotes a seus destinatrios, pode
ser presa de alguns ataques clssicos, como o "IP spoofing".
Mquinas bem configuradas s concedem acesso a computadores conhecidos, em geral localizados numa
mesma rede privada. Assim, para obter acesso a uma maquina bem configurada, necessrio introduzi-la
a crer que a mquina do invasor de confiana um processo denominado spoofing. Para isso, o invasor
precisa descobrir o endereo legitimo de uma maquina da rede interna e enviar vitima pacotes que
apresentam tal endereo como origem. A vitima, crendo ser o atacante uma maquina de confiana,
responder enviando pacotes para o endereo do remetente.
Para o esquema funcionar, entretanto o cracker precisa tomar duas providencias. A primeira impedir que
a maquina legitima responda aos pacotes enviados pela vitima; em geral, isso feito garantindo-se que a
maquina legitima esteja fora do ar (pode-se efetuar o ataque num momento em que se saiba que a
maquina esta desligada, ou derrub-la de algum mtodo mais hostil).
A segunda garantir que o pacote seja ecoado para fora da rede interna. Em geral, o pacote apenas diz
para onde quer ir e os roteadores no caminho decidem qual a melhor rota a seguir. Desta forma, os
pacotes enviados pela vtima no seriam passados para a Internet, porque o endereo de destino (que
pertence a maquina que esta fora do ar) encontra-se dentro da rede interna. Para evitar isso, o invasor
recorre ao "source-routing", uma tcnica criada para testes e depurao que permite que a maquina que
inicia a comunicao (no caso, o invasor) especifique qual a rota a ser utilizada pr todos os pacotes de
uma determinada conexo, o que garante que os pacotes sejam ecoados da rede interna para a Internet.
Um firewall de rede sofisticado no se contenta em rotear os pacotes para seus destinos: ele mantm
informaes sobre o estado das conexes e sobre o contedo dos pacotes, o que lhe permite perceber que
um pacote cujo endereo de origem pertence a rede interna no pode provir da Internet. Se isto ocorre,
configura-se o spoofing e o firewall descarta o pacote e aciona o alarme. Similarmente, comunicaes
normais no devem gerar pedidos de source-routing, de modo que, se um tal pedido surge, o firewall deve
consider-lo um ataque e agir de acordo. Independente de sua sofisticao, firwalls de rede roteiam
trfego diretamente, o que os torna rpidos e transparentes mas os impede de analisar o contedo efetivo
dos pacotes trafegados e exige que as maquinas na rede interna tenham endereos IP vlidos (o que pode
ser um risco em si).
Firewall no nvel de aplicao

Firewalls de aplicao costumam ser computadores de uso geral que rodam programas especiais
chamados "proxy servers". Cada aplicao abilitada na configurao de firewall SMTP (correio), HTTP
(Web), FTP, Telnet etc. exige um proxy server especfico que supervisione a porta IP por onde passam
os pacotes referentes quela determinada aplicao.
Este tipo de firewall no permite trfego direto entre duas redes: toda comunicao requer o
estabelecimento de duas conexes, uma entre o remetente proxy e a outra entre o proxy e o destinatrio.
O proxy correlaciona a duas comunicaes atravs do nmero da sesso TCP (que est presente em todos
10
os pacotes) e ecoa os dados que vm da conexo x para a conexo y e vice-versa. O que importante
que todo pacote, antes de ser ecoado de uma conexo para a outra, analisado pelo proxy server um
programa para detectar abusos de segurana no protocolo utilizado naquela porta especfica - , que decide
se o pacote deve passar ou ser descartado. O resultado o firewall de aplicao consege detectar riscos
que um firewall de rede no teria como perceber, alcanando um nvel de segurana superior.
Um exemplo clssico do tipo de informao que um proxy pode filtrar o comando DEBUG do SMTP,
usado para solicitar a um servidor de correio que fornea certas informaes de controle e considerado
arriscado pela maior parte dos administradores de rede. Como no normal que esse tipo de comando
seja emitido durante uma troca de mensagens de correio, um bom proxy SMTP descartar o pacote como
o comando proibido, mudar o estado do firewall para "ataque em curso" e enviara uma mensagem (que
pode at seguir para um pager ou telefone celular) para o administrador, prevenindo-o do ocorrido.
Outro exemplo so proxies FTP, que podem vedar completamente o acesso de usurios externos s
maquinas da empresa ao mesmo tempo que permite que funcionrios copiem arquivos da Internet para a
rede interne (comando GET), mas no o contrrio (comando PUT). Todos esses exemplos esto ligados
ao funcionamento dos protocolos especficos de cada aplicao e no poderiam ser implementados em
firewalls de rede, que no so capazes de examinar o contedo dos pacote IP.
Firwalls de aplicao so bem menos transparentes do que firewalls e rede. Para comear, toda e qualquer
aplicao exige a existncia de um proxy; se o usurio precisa de uma aplicao para a qual no existe um
proxy rodando no firewall, no h o que fazer: a aplicao simplesmente no funcionar. Em um mundo
onde h novas aplicaes sendo lanadas todos os dias, este tende a ser um problema considervel, e o
resultado que os fornecedores sempre tm uma nova verso (esta suporta SSL, a prxima suportar Real
udio, a seguinte suportar SQL) de firewall no forno.
Quando necessrio usar uma aplicao para a qual o fornecedor do firewall no tem (nem ter) um
proxy especfico, a soluo a utilizao de um proxy genrico. Criar um proxy genrico simples: tratase to-somente de informar ao firewall que quaisquer pacote trafegando entre as maquinas x (internas) e
as maquina y (externas)que usem a porta z so confiveis e podem passar. Apesar de tais pacotes serem
roteados sem uma anlise cuidadosa (similar ao que faria um firewall de rede), trata-se de um
procedimento razoavelmente seguro, porque a comunicao no monitorada duplamente restrita: no
apenas ocorre numa nica porta IP, como s envolvem maquinas de confiana afinal, se o fornecedor
no fosse de confiana no seria contratado.
Como no permite comunicao direta entre o cliente e o servidor, o firewall de aplicao
consideravelmente menos transparente que o firewall de rede. necessrio que o programa cliente saiba
que deve estabelecer uma conexo com o proxy e determinar aes como "conecte-se ao servidor Web da
Mantel e recupere a pgina tal para mim". Quando o cliente sabe isso; como a maioria dos browsers
Web, basta configur-lo corretamente. Quando os clientes so poucos sofisticados e exigem conexes
diretas com o servidor (como comum com FTP e Telnet, pr exemplo), utiliza-se um artifcio: o usurio
se loga no proxy e este; m vez de solicitar nome e senha (como seria de esperar), solicita o nome do
servidor com o qual se deseja a conexo; a partir da, tudo funciona normalmente.
O firewall de aplicao oferece algumas vantagens sobre o firewall de rede. A primeira e mais importante
permitir um acompanhamento muito mais prximo e efetivo das comunicaes entre duas redes,
inclusive com logs e relatrios de auditoria. O fato de o DNS ser tambm um proxy server permite que os
nomes das maquinas internas sejam preservados e que um mesmo nome possa identificar duas maquinas
diferentes da origem de quem consulta, se um usurio interno ou externo.
Alm disso, como toda a comunicao ricocheteada pelo firewall, o mundo s precisa saber de um
nico endereo IP (o da porta externa do firewall), e os verdadeiros endereos das maquinas internas
podem ser protegidos, trazendo vrios benefcios. Para comear, o simples desconhecimento dos
endereos reais refora a segurana. Melhor ainda que isso permite o uso de faixas reservadas de
endereos que, pr conveno, no podem ser utilizadas na Internet. Neste caso, virtualmente
impossvel para o cracker enviar pacotes diretamente s maquinas da rede interna. E o uso de endereos
protegidos tambm possibilita a atribuio de mais endereos do que os concedidos originalmente pelo
provedor de acesso.
11
Na verdade, a discusso sobre qual o melhor firewall, se o de rede ou o de aplicao, no procede,

porque eles no representam solues mutuamente excludentes. Os melhores sistemas de firewall, como
seria de esperar, adotam ambas as abordagens, permitindo a definio de regras, controles e auditorias nos
dois nveis.
Alm do firewall
Infelizmente, no h firewall que consiga bloquear um ataque efetuado pr fora do firewall. Apesar de
isso ser bvio, a Internet parece deter o monoplio no que se refere a difundir o terror; de modo que h
muita gente que s v perigo na grande rede, deixando de lado os outros pontos onde, com freqncia, o
dano pode ser maior ou o risco mais provvel. So comuns os casos empresas que instalam firewalls de
primeira ao mesmo modems permitindo acesso discado sem senha. Isso eqivale a colocar tranca de ao
na portas da frente e abandonar as janelas destrancadas.
Um firewall no impede o vazamento de dados. O correio eletrnico de fato a forma mais simples de se
enviar dados para fora da empresa, mas tambm a forma mais perigosa, j que o trafego de correio pode
ser controlado e auditado. Um espio consciencioso preferir uma fita, um disquete (razo pelos quais h
quem defenda o banimento dos drives de disquete) ou um simples fax. E no existe aplice de seguro
contra estupidez: se um funcionrio fornecer sua senha de acesso a usurios no autorizados ou
desconhecidos, no h firewall que resolva.
Firewalls podem ser muito eficientes para reconhecer e neutralizar ataques efetuados da utilizao
maliciosa de caractersticas especficas dos protocolos de comunicao utilizados na rede, mas pouco
podem fazer contra ataques baseados em dados. Do ponto de vista do firewall, mensagens de correio ou
arquivos copiados para algum servidor no constituem ataque. O resultado que possvel que crackers
se valha de caractersticas (ou, mais comumente, falhas) de programas especficos para executar aes
nefastas. O caso mais notrio deste tipo de utilizao mal-intencionada foi o vrus da Internet, que se valia
de uma falha do sendmail (programa de envio de correio do Unix) e derrubou 6 mil maquinas em 1988.
Outros exemplos particularmente graves so os vrus e programas executveis pelos browsers (como
applets java ou controles activeX); ambos os casos so tratados pelos firewalls como dados e, em geral,
trafegam de uma rede a outra sem problema algum.
A maneira correta de combater vrus a tradicional, atravs da utilizao de programas rodando em
estaes e servidores de arquivos identificar e limpar arquivos contaminados logo depois sua gravao em
disco. Tambm j existem antivrus para servidores de correio capazes de analisar arquivos anexados a
mensagens de correio, detectando e removendo vrus antes mesmo que os destinatrios sejam notificados
de sua chegada. A preveno contra o cdigo executvel distribudo atravs da Web deve ser feita nos
programas que recebem e executam. Browsers como o Netscape e Internet Explorer tm opes de
configurao que permitem que tipos de objetos podem ser recebidos e em que condies podem ser
executados.
Apesar de haver no mercado excelentes solues para proteger redes privadas contra ataque de invasores
inescrupulosos, o firewall no pode ser encarado como soluo isolada para a questo de segurana na
comunicao com a Internet. H empresas que gastam pequenas fortunas para montar firewall
inexpugnveis mas no se preocupam em criar polticas de segurana coerentes e consistentes. Para ser
eficaz, o firewall deve ser parte de uma poltica global de segurana uma que seja realista o bastante
para identificar e prevenir os riscos efetivos (maquinas que contm dados mais confidenciais, pr
exemplo, no precisam de firewall: elas no devem estar ligadas Internet), mas que, pr outro lado, no
seja paranica a ponto de impedir as pessoas de trabalhar.
4. Servios e Procedimentos Seguros

12
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 de conceitos ao leitor.
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
Pr muitos anos, o mtodo prescrito para a autenticao de usurios tem passado pelo uso de senhas
padro reutilizveis. Originalmente, estas senhas eram usadas pr usurios em terminais 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 freqentemente transmitidas atravs
destas mesmas redes em texto claro, no ponto para 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 pacote os quais esto capturando as senhas de texto
claro.
Com o advento de tecnologias mais recentes, como senhas de uso nico (pr exemplo, S/Key), PGP, e
dispositivos de autenticao baseados em tokens, as pessoas esto usando strings tipo senhas como tokens
e identificadores numricos secretos. Se estes tokens e identificadores numricos secretos no forem
apropriadamente selecionados 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 de Tria (pr exemplo, telnet
e rlogin) e programas visualizadores de pacotes de rede. Estes programas capturam trios de nomes de
mquina, contas e senhas 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
(consequentemente o termo "reutilizvel") e 2) a senha passa atravs d rede em texto claro.
Foram desenvolvidas algumas tcnicas de autenticao que dirigem-se este problema. Entre estas
tcnicas esto tecnologias de desafio-resposta que provem senhas que so uma usadas uma s vez
(comumente chamadas de senhas de nica vez). H vrios produtos disponveis que sites deveriam
considerar o uso. 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 dois principais lanamentos do Kerberos, verso 4 e 5 que so, para propsitos prticos,
incompatveis.
13
Kerberos confia em um banco de dados de chaves simtricas, utilizando um centro de distribuio de

chaves (KDC) 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 uma marca de
tempo a 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. Pr 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 Numricos

Secretos
Quando da seleo de tokens secretos, deve-se preocupar-se em escolhe-los cuidadosamente. Como a
seleo de senhas, eles devem ser robustos contra esforos de fora bruta para adivinha-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 de passagem 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 usando-as. 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.
14
(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 senha boa na que esta 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 cola-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.
Enquanto no h resposta definitiva a este dilema, uma poltica de senhas deve dirigir a questo
diretamente e prover diretrizes para com que freqncia um usurio deve mudar a senha. Certamente,
uma mudana anual em sua senha no difcil para a maioria dos usurios, normalmente, 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 compromissada. Ainda, se a senha de uma conta privilegiada
compromissada, todas as senhas no sistema devem ser alteradas.
(5) Bloqueio de contas e senhas - Alguns sites acham til desabilitar contas depois de um nmero prdefinido de no sucedidas tentativas de autenticao. Se seu site decidir empregar este mecanismo,
recomendado que o mecanismo no avise a sim 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. Pr 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 pr possveis intrusos para identificar usernames e adivinhar suas senhas. recomendado que sites
considerem modificar o finger para restringir a informao exibida.
4.2 Confiana
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 no sistema pode acessar ou "enchergar" 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 ordenar facilmente o texto para uma forma legvel (texto claro). Ns recomendamos que
sites usem criptografia para prover confiana e proteger informao valiosa.
O uso de criptografia controlado s vezes pr regulamentos governamentais e de sites, portanto ns
encorajamos que os administradores tornem-se informados 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 acautelamos contra o uso casual do programa crypt do UNIX pr
ter sido achado facilmente quebrvel. Ns tambm encorajamos todos a levarem tempo para entender 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.
15
4.3 Integridade
Como um administrador, voc desejar ter certeza que informaes (pr 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 da 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, fundamentalmente, 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 proprietrio). 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 pr 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 Auditoria
Esta seo cobre os procedimentos para coletar os dados gerados pela atividade de rede, que podem ser
teis para analisar a segurana de uma rede e responder a incidentes de segurana.
16
4.5.1 O que coletar

Dados de auditoria deveriam incluir qualquer tentativa de obter um nvel de segurana diferente pr
qualquer pessoa, processo, ou outra entidade da rede. Isto inclui "login" e "logout", acesso de superusurio (ou o equivalente no-UNIX), gerao de tquete (para Kerberos, pr 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. Tambm no colete senhas incorretas, j
que elas diferem das senhas vlidas somente pr um caracter ou transposio.
4.5.2 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 (pr exemplo um CD-ROM ou uma unidade
de fita especialmente configurada), ou num dispositivo somente de escrita (pr 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, tambm 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 rastear uma 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. Tambm, 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 (pr 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 tambm a questo de tornar seguro o caminho entre o dispositivo que gera o registro e o que realmente
armazena o registro (pr 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 pr um simples e nico cabo pontoa-ponto. Como isto usualmente impraticvel, o caminho deveria passar pr 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.
17
4.5.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 pr um perodo mais curto
de tempo com somente os sumrios de dados sendo guardados em arquivos de longo prazo. Um grande
inconveniente deste ltimo mtodo envolve a resposta a incidentes. Freqentemente, um incidente j vem
ocorrendo pr 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.5.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. Pr 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.5.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 conseqncias 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 mantm dados de auditoria, ser ela responsvel pr 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 pr 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.6 Acesso
4.6.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 (pr exemplo portas fechadas abrindo).
18
Mantenha cpias originais e backup de programas e dados seguras. Alm de mant-los 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 tambm 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 (pr 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.6.2 Conexes de Rede "Walk-Up"

Pr 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. Pr 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
(pr 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.6.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 pr 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.6.4 Modems
4.6.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. Pr esta razo essencial manter um controle
apropriado dos modems.
No permite aos usurios instalar uma linha de modem sem uma autorizao apropriada. Isto inclui as
instalaes temporrias (pr exemplo, pendurar um modem em um aparelho de fax ou uma linha
telefnica durante a noite.
19
Tenha um registro de todas as suas linhas de modem e mantenha-o atualizado. Conduza verificaes
regulares (idealmente automatizadas) dos modems no autorizados no "site".
4.6.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 modems 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. Pr esta razo, voc deveria usar senhas "one-time" sempre que
possvel.
de grande utilidade ter um nico ponto de entrada para acessos discados (pr exemplo um nico grande
"pool" de modems) 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.6.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 algum 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.6.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 pr usurios autorizados. Elas variam somente pr 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. Tambm 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.6.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 freqentemente 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.
20
Exiba um "banner" curto, mas no oferea um nome "convidativo" (pr 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.6.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 partir de uma autenticada. O objetivo aqui evitar que chamadores usem seu "pool"
de modems 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 modems e linhas telefnicas sejam usadas para discagem de
entrada e de sada. Isto pode ser facilmente implementado se voc operar "pools" de modems separados
para discagem de entrada e discagem de sada.
4.6.4.7 Torne sua Programao de Modems a "Prova de Bala" tanto quanto o

Possvel
Certifique-se de que os modems no podem ser reprogramados enquanto estiverem em servio. No
mnimo, certifique-se que trs sinais de mais ("+++") no colocaro seus modems de discagem de entrada
em modo de comando !
Programe seus modems para "resetarem" sua configurao padro no incio de cada chamada. Esta
precauo proteger voc contra a reprogramao acidental de seus modems. "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 modems 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.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. Tambm, certifique-se de que voc ter acesso aos programas 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 pr longos perodos de tempo antes de serem notados.
Em tais casos, backups dos sistemas afetados esto tambm corrompidos.
21
5. Periodicamente verifique a correo e a complexo 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 pr
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 o quanto srio).
4. tratamento (o que deveria ser feito quando um incidente acontece).
* Notificao (quem deveria ser notificado sobre o incidente)
22
* 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 atravs de
"dry runs". Um grupo poderia considerar a contratao de um grupo-tigre 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 pr 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 ateno a 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 conscientes 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
23
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 (pr 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 interrupo dos 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 pr regulamentos governamentais sempre importante informar as partes
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 pr polticas locais e
regulamentos. Sites privados e do governo que lidem com material classificado tem regras especficas que
eles devem seguir.
As polticas escolhidas pr seu site sobre como reagir a incidentes ir moldar sua resposta Pr 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
24
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 pr 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 pr 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 encarregada 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, faltandolhes 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 pr 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 predefinidos, 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.
25
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 (pr 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 pr 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. Pr 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. No mnimo, 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 pr 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
pr 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 pr meses e tomar muito esforo.
Pr outro lado, o conselho legal de uma organizao pode aconselhar precauo extrema e sugerir que
atividades de rastreamento 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.
26
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 pr
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 pr coordenar incidentes de segurana de computador numa srie de sites e entidades
maiores. At mesmo acreditando-se que o incidente est contido dentro de um nico site, possvel que a
informao disponvel pr 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 grupos 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 pr tratar de incidentes de segurana para o site (ou
organizao). Se tal grupo criado, essencial que linhas de comunicao sejam abertas entre este grupo
e outros. Uma vez que um incidente ocorre, difcil abrir um dilogo confiante entres grupos, se no
havia nenhum antes.
27
5.2.4 Sites Afetados e Envolvidos

Se um incidente tem um impacto em outros sites, inform-los 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 pr sites distantes
e o grupo de resposta poder facilitar esse contato 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 site 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). Pr 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
tentando esclarecer 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 sensato, 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.
28
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 site 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 infeo 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).
29
(4) discrepncia 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 tentativas 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 pr este incidente?
(3) h informao delicada envolvida?
(4) qual o ponto de entrada do incidente (rede, linha telefnica , terminal 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, pr exemplo que o incidente
pode ter continuado pr meses ou anos antes de descoberta, e o suspeito pode ser um empregado do site,
30
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, pr 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 manuteno 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. Pr 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. Pr outro lado, pondo o
conhecimento crtico no domnio pblico (pr exemplo, pr 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.
31
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 multinacional. 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. Pr exemplo, administrador de um
sistema universitrio muito relaxado sobre tentativas para conectar o sistema pr 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 responsveis 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, pr 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 probem 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, pr exemplo, provvel que voc esquea uma poro significante de
informao voc obtm o que requer que voc 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 instituies 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)
32
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
pr 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 pr em perigo o procedimento legal pr manipulao imprpria de possvel evidncia.
Se apropriado, os passos seguintes podem ser levados.
1. regularmente (pr exemplo, diariamente) fazer cpias assinadas de seu logbook (como tambm mdias
que voc usa para registrar eventos de sistemas) para um administrador de documentos.
2. administrador deveria armazenar estas pginas copiadas em um seguro lugar (pr 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 (pr 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 progresso, 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, pr 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 infees 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 r-infetados
33
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 Prosseguimento
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 seguimento. Na fase de seguimento, o
sistema deveria ser monitorado com vistas aspectos que podem ter sido perdidos durante a fase de
cleanup. Seria prudente utilizar, como um comeo, algumas das ferramentas de gerenciamento.
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 ps morte. Exatamente o
que aconteceu, e quanto tempo? Como foi a performance do pessoal envolvido com o incidente? Que tipo
de informao foi necessria rapidamente para o pessoal, e como eles adquirir 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 pr razes legais.
Um relatrio de seguimento valioso pr 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.
34
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 re-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 ps morte melhorar toda 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 ps 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 proteger a sua prpria rede, mas outra assumir que deve proteger outras redes. Durante o
tratamento de um incidente, certas vulnerabilidade dos prprios sistemas e os sistemas de outros ficam
aparentes. bastante fcil e pode ser tentador rastrear os intrusos para localiz-los. Tenha em mente que
em certo momento possvel cruzar a linha e, com a melhor das intenes, comportar-se no melhor do
que o intruso.
A melhor regra a seguir no usar facilidades de sistemas remotos que no sejam pblicas. Isto
claramente exclui qualquer entrada em um sistema (usando um shell ou login remoto) que no seja
explicitamente permitido. Isto pode ser muito tentador depois que uma brecha de segurana descoberta;
um administrador de sistema pode ter os meios para, averiguar que danos podem ter sido feitos ao site
remoto. No faa! Ao invs, tente buscar o contato apropriado para o site afetado.
5.6.2 Poltica de boa vizinhana na Internet
Durante um incidente de segurana h duas escolhas que a pessoa pode fazer. Primeiro, um site pode
escolher observar o intruso na expectativa de pega0lo; ou, o site pode limpar o sistema depois do
incidente e manter o intruso fora dos sistemas. Esta uma deciso que deve ser tomada com muito
cuidado, pois poder haver conseqncias legais se voc optar pr deixar seu site aberto sabendo que um
intruso est usando-o como um ponto de lanamento para atacar outros sites. Sendo um "bom vizinho" na
Internet voc deveria tentar alertar outros sites que podem ter sidos impactados pelo intruso. Estes locais
afetados podem ser detectados aps uma reviso completa de seus arquivos de log.
5.6.2 Resposta administrativa para Incidentes
35
Quando um incidente de segurana envolve um usurio, a poltica de segurana do site deveria descrever
que ao ser tomada. A transgresso deve ser levada a srio, mas muito importante estar seguro sobre o
papel do usurio. O usurio era ingnuo? Poderia haver um engano atribuindo a quebra de segurana ao
usurio? Aplicar alguma penalidade administrativa assume que o usurio intencionalmente causou o
incidente e isto pode no ser apropriado para um usurio que simplesmente cometeu um engano. Pode ser
apropriado prever sanes adequadas a cada situao em sua poltica (pr exemplo, educao ou
repreenso a um usurio) alm para medidas mais duras para atos intencionais de intruso e abuso do
sistema.
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 pr 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 plos 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 plos colegas de classe.
(6) Verifique regularmente pr polticas e procedimentos complacentes. Esta auditoria deve ser feita
preferencialmente pr algum que no tenha participado da definio ou implementao destas
polticas ou procedimentos.
36

Politicas Seguranca

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Politicas Seguranca

Enviado por

Direitos autorais:

Formatos disponíveis

www.projetoderedes.kit.

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

2.1.1 - Definio de uma poltica de segurana

2.1.2 - Propsitos de um poltica de segurana

2.1.3 - Quem deve ser envolvido na formulao da poltica?

2.2 O que faz uma boa poltica de segurana?

2.3 - Mantendo a poltica flexvel

3.1.2 Separao de Servios

3.1.3 Bloquear tudo / Permitir tudo

3.1.4 Identificao das Reais Necessidades de Servios

3.2 Configurao de Servios e Rede

3.2.2 Proteo da Rede

3.2.3 Proteo dos Servios

Firewall no nvel de rede

Firewall no nvel de aplicao

Na verdade, a discusso sobre qual o melhor firewall, se o de rede ou o de aplicao, no procede,

4. Servios e Procedimentos Seguros

4.1.1 Senhas de uso nico

Kerberos confia em um banco de dados de chaves simtricas, utilizando um centro de distribuio de

4.1.3 Escolhendo e Protegendo Tokens e Indentificadores Numricos

4.1.4 Garantia da Senha

4.5.1 O que coletar

4.5.2 Processo de Coleta

4.5.3 Carga da Coleta

4.5.4 Manipulando e Preservando os Dados de Auditoria

4.5.5 Consideraes Legais

4.6.2 Conexes de Rede "Walk-Up"

4.6.3 Outras Tecnologias de Rede

4.6.4.2 Usurios de Discagem devem ser Autenticados

4.6.4.3 Capacidade de Chamada Reversa

4.6.4.4 Todos os Logins deveriam ser Registrados no Log

4.6.4.5 Escolha seu "Banner" de Abertura Cuidadosamente

4.6.4.6 Autenticao "Dial-Out"

4.6.4.7 Torne sua Programao de Modems a "Prova de Bala" tanto quanto o

4.7 Protegendo Backups

5. Periodicamente verifique a correo e a complexo de seus backups.

5. Tratamento de Incidentes de Segurana

5.1 Preparando e Planejando o Tratamento de Incidentes

5.2 Notificao e Pontos de Contato

5.2.2 Agncias de Investigao e de Execuo da Lei

5.2.3 Grupos de Tratamento de Incidentes de Segurana de

5.2.4 Sites Afetados e Envolvidos

5.2.5 Comunicaes internas

5.2.6 Relaes pblicas - "Press Releases"

5.3 Identificando um Incidente

5.3.2 Tipos e Escopo de Incidentes

5.3.3 Avaliando Dano e Extenso

5.4 Tratando um Incidente

5.4.1 Tipos de Notificao e Troca de Informao

5.4.2 Protegendo as Evidncias e Logs de Atividade

5.5 Resultado de um Incidente

5.6.2 Resposta administrativa para Incidentes

Você também pode gostar