Augusto C. Campos - brain@matrix.com.br
Nota: Este artigo é de minha autoria, e foi publicado inicialmente em duas edições (impressas) da Revista do Linux. Esta reprodução é autorizada pela Revista do Linux. As figuras foram retiradas intencionalmente.
Segurança de rede é uma preocupação que deve ser compartilhada por todos, inclusive pelo usuário final
Hoje em dia, uma conexão permanente à Internet está ao alcance de qualquer organização, e de praticamente qualquer indivíduo. Ao mesmo tempo, as conexões temporárias (discadas e similares) permitem níveis de serviço impensáveis há poucos anos.
Paralelamente a isso, muitos dos sistemas operacionais utilizados nos computadores conectados diretamente à rede continuam vindo com uma série de funcionalidades e facilidades pré-ativadas que não contribuem para a criação de um ambiente seguro. É bom lembrar que o projeto de segurança trabalha com a premissa de que a segurança e a conveniência (do ponto de vista do usuário final) são inversamente proporcionais.
Além desses fatores, há um terceiro que deve ser considerado. Hoje, comprar um computador e colocá-lo na rede está ao alcance de um público muito grande, que geralmente não vai contar com a ajuda de um profissional do ramo antes de conectar-se à rede de seu condomínio ou conjunto empresarial.
Diante disso, conclui-se que a segurança de rede é uma preocupação que deve ser compartilhada por todos, inclusive pelo usuário final. Por mais seguro que um sistema operacional seja, as atitudes de um administrador sem treinamento formal ou até mesmo informal podem transformá-lo em uma fortaleza de portas escancaradas, pronto para receber todo tipo de ataque e invasões.
Muitas das tarefas da administração segura de redes se resumem à pura e simples aplicação do bom senso ou senso comum. É lógico que se você armazena dados valiosos (ou que de alguma forma interessem a um potencial invasor), você terá que tomar maiores precauções de segurança. Mas isto não quer dizer que se você só armazena dados públicos, poderá se descuidar -- muitas invasões ocorrem por puro e simples "esporte", sem interesse em obter nenhum dado ou recurso da sua rede. E são essas as invasões que mais comumente resultam em perda grave de dados.
Contar com o apoio de um profissional da administração de redes é altamente desejável, mas realmente não está ao alcance de todos os usuários e organizações. Mas mesmo na ausência de um profissional, você deve procurar se informar (ei, você está lendo um artigo sobre segurança, e isto já é um ótimo começo!), e manter seu sistema sempre atualizado.
É justamente o bom senso que falta a alguns administradores de pequenas redes. A falta de preocupação com o valor das informações, e o foco no custo fazem, por exemplo, com que se "economizem" alguns reais na compra de um gravador de fita DAT que poderia ser usado para armazenar cópias diárias de todos os seus arquivos, um procedimento simples, facilmente automatizável (você só tem que trocar as fitas todos os dias, o sistema faz o resto sozinho), e com baixo custo de manutenção.
Na verdade, uma demonstração desta mesma falta de bom senso motivou o surgimento deste artigo. Uma pessoa encarregada da administração da rede de uma empresa percebeu que sua rede estava sendo invadida, e não soube o que fazer. Na sua ingenuidade e falta de informação, recorreu a uma lista de discussão da Internet, recebida por literalmente milhares de pessoas, e lançou: "Minha rede foi invadida, não sei como, que posso fazer?". Isto equivale a ir a uma praça no centro da cidade e gritar com um megafone: "Minha casa não é segura, e o endereço dela é tal, alguém pode me ajudar?" Claro que surgem pessoas interessadas em ajudar, mas também aparecerão outras que tentarão procurar a falha de segurança -- que agora sabem que existe --, e se aproveitar dela antes que seja descoberta. O resultado? A máquina da empresa foi formatada, não tinha cópia de segurança, e o dono deve ter lamentado não investir um pouco mais no treinamento de seus quadros técnicos.
Este artigo se preocupa em responder o que fazer quando sua rede for invadida, e também dá algumas dicas de prevenção, principalmente no que diz respeito às políticas de segurança. Grande parte do que vai ser visto aqui consta do Linux Security HOWTO (http://linuxdoc.org/HOWTO/Security-HOWTO.html), principalmente seus capítulos 9 e 10. Mas foi realizado um esforço de adaptação à realidade brasileira, e acrescentados alguns conselhos e comentários baseados em contatos com profissionais da área e na própria experiência do autor.
Por mais cuidado que você tenha tomado na configuração da segurança de seu sistema, cedo ou tarde é possível que você passe pela desagradável surpresa de verificar que alguém está tendo acesso a ele. Neste caso, a primeira providência a tomar é manter a calma: atitudes impensadas podem causar mais problemas do que o seu invasor poderia causar sozinho.
Detectar um comprometimento da segurança em curso pode ser uma situação muito tensa. A sua reação pode ter graves conseqüências.
Se uma pessoa invadiu a sua casa, escritório ou laboratório, trata-se de um ataque físico, que deve estar coberto em sua política de segurança. Você deve notificar as autoridades competentes. Em um laboratório, você pode ter encontrado alguém abrindo um gabinete ou tentando desligar um equipamento. Dependendo do seu grau de autoridade, você pode tentar convencê-lo a parar, ou chamar o encarregado da segurança.
Se você notou um usuário local tentando comprometer sua segurança, a primeira coisa a fazer é confirmar se ele é realmente quem você está pensando. Verifique de onde ele está se conectando: é o seu local usual de conexão? Não? Então use uma maneira não-eletrônica de entrar em contato. Por exemplo, telefone, ou vá até seu escritório ou casa, e converse pessoalmente. Se ele confirmar que estava conectado, você pode pedir a ele que explique o que estava fazendo, e solicitar que pare. Se ele não estava, tudo indica que o caso precisará de investigação adicional. Pesquise a fundo, e reúna informações antes de fazer qualquer acusação.
Se você notou uma invasão via rede, a primeira coisa a fazer (se for possível) é desconectar sua rede. Desconecte o cabo do modem ou da placa de rede, sem desabilitar previamente as conexões via software. Isto fará o possível atacante pensar que está enfrentando problemas de rede, e não lhe dará a certeza de já ter sido detectado. Caso você não possa desconectar a rede (se você tem um site que precisa ficar online, ou se você não tem acesso físico às suas máquinas), o próximo passo é usar uma ferramenta como os tcp_wrappers, ipfwadm ou o ipchains para negar acesso ao site de origem do invasor.
Se você não puder nem ao menos desabilitar as conexões vindas da origem do invasor, você terá que necessariamente travar a conta que ele está usando. Esta não é uma tarefa simples, você terá que considerar todos os arquivos .rhosts, acesso de FTP, e-mail, cron, e mesmo assim poderá não se livrar de algumas backdoors.
Após ter feito uma das operações acima (desconectar a rede, negar acesso do endereço de origem ou desabilitar completamente a conta comprometida), você precisará matar todos os processos do usuário e forçar o seu logoff.
Monitore atentamente sua rede nos próximos minutos, porque o invasor quase certamente tentará voltar, ou executará probes para tentar descobrir o que aconteceu. Talvez usando uma conta diferente. Ou até mesmo um endereço de origem completamente novo.
Então você detectou um comprometimento da segurança que já ocorreu, ou você o interrompeu enquanto ocorria, e impediu o acesso do invasor. E agora?
Se você tem como determinar (atenção, determinar não significa "dar um chute razoável") os meios utilizados pelo invasor para penetrar no seu sistema, você deve começar por tapar este furo. Por exemplo, talvez você tenha notado diversos acessos FTP no momento em que o invasor agiu. Neste caso, desabilite o serviço de FTP e verifique se há uma versão atualizada, ou documentação sobre problemas com a sua versão.
Verifique os logs do seu sistema, e faça uma visita aos seus sites de segurança preferidos (sim, você deve ter o hábito de visitar sites sobre segurança) para saber se há exploits conhecidos e aos quais você esteja vulnerável. Procure por todas as atualizações de segurança fornecidas pelo distribuidor do seu sistema operacional, ou por terceiros nos quais você julgue adequado confiar.
Se você não impedir o invasor de voltar, ele certamente o fará. Não apenas à mesma máquina, mas a outros pontos de sua rede. Parte do "procedimento padrão" de invasão é utilizar ferramentas (como packet sniffers e crackers) para obter acesso a outros pontos da mesma rede.
Após fechar corretamente a falha utilizada para a invasão (e outras que porventura estivessem abertas), a primeira coisa a fazer é levantar os danos. O que foi comprometido? Se você usa ferramentas no estilo do Tripwire, você pode lançar mão delas para realizar uma verificação de integridade -- isto deve ajudar a informar o que foi alterado. Caso contrário, você terá de verificar tudo manualmente.
Root kits
Os root kits são ferramentas relativamente fáceis de manejar e instalar, que qualquer invasor minimamente competente possui. O root kit serve basicamente para garantir que, uma vez obtido o acesso de usuário privilegiado na máquina invadida, esse acesso seja mantido. Isto é feito com uma série de táticas ao mesmo tempo criativas e discretas, como substituir o comando ps de forma que ele liste todos os processos, exceto o do próprio root kit e suas shells, alterar de maneira semelhante os comandos ls, netstat e outros, e embutir cavalos de tróia em servidores (como o inetd, por exemplo) para garantir portas de entrada sem necessidade de senhas e sem registrar nada nos logs. O root kit é uma grande razão para que você não possa confiar 100% em nenhuma de suas ferramentas de verificação após um ataque em que houve comprometimento do acesso privilegiado, e um ótimo argumento em favor da reinstalação total de um sistema comprometido.
Se você estiver utilizando um sistema fácil de configurar e manter, como a maior parte dos sistemas para uso doméstico e servidores de pequeno e médio porte (e.g. Linux, FreeBSD...), você pode até mesmo considerar fazer um backup completo, apagar todos os discos, reinstalar o sistema a partir da mídia original de instalação e em seguida voltar os backups dos seus arquivos de dados (note que isso não inclui os arquivos de programas, e nem os de configuração).
Lembre-se que isso lhe dá uma configuração completamente renovada, mas provavelmente contendo as mesmas falhas que permitiram que o atacante penetrasse pela primeira vez, portanto, refaça a etapa anterior, fechando todos os possíveis meios de acesso.
Checagem de integridade
Muitas dúvidas podem ser evitadas usando um programa de checagem de integridade como o tripwire, www.tripwire.org. Ele deve ser rodados todos os dias, e seu procedimento é bastante simples: ele percorre o seu sistema de arquivos, realizando checksums nos arquivos mais vitais do sistema, e em seguida comparando o resultado desses checksums com os resultados armazenados originalmente em uma base de dados. Lembre-se de gravar a base de dados em um local que o invasor não possa alterar (por exemplo, em um CD-ROM sempre montado, ou em um disquete protegido contra gravação e também sempre montado), caso contrário ele poderá virar o feitiço contra o feiticeiro.
A reinstalação é considerada como obrigatória para todos os casos em que o invasor chegou a obter acesso privilegiado (root ou administrador). Dependendo de suas políticas, você pode querer guardar as pistas ou provas, e neste caso pode valer a pena substituir o disco por um novo, e guardar o que foi comprometido pelo invasor.
Backup faz parte da política de segurança
Fazer backup regularmente pode ser a salvação da sua reputação, e é parte importante da política de segurança. Se o seu sistema for danificado ou comprometido, você poderá restaurá-lo a partir das cópias. Claro que esses dados podem ser do interesse dos invasores também, e eles a esta altura terão uma cópia de tudo -- mas ao menos você não ficará sem a sua cópia. Veremos mais sobre este assunto na segunda parte do artigo.
Ok, você impediu o acesso do invasor, recuperou seu sistema e refez a política de segurança. Mas não é só isso que você quer. Embora a maior parte dos invasores não chegue a responder pelos seus atos, você deve comunicar o ataque mesmo assim.
O primeiro passo é informar o ocorrido ao contato administrativo no provedor ou site de onde se originou o ataque detectado. Você pode descobrir esses dados usando o whois, ou acessando as bases de dados online da Internic (para sites norte-americanos) ou Fapesp (registro.br/, para sites brasileiros). Envie e-mail contendo os logs aplicáveis, datas, endereços e horários. Se você notou mais alguma característica que possa ajudar a detectar o intruso, inclua na mensagem. Seja educado. Coloque-se à disposição para trabalhar em conjunto na busca de soluções. Lembre-se de que o administrador do site de origem muito provavelmente não sabe que sua rede pode estar sendo usada com este tipo de propósito -- ele pode ter sido invadido também. Nesse caso, ele também passará pelo que você passou, e por sua vez irá contatar o administrador do site de origem, do ponto de vista dele.
Invasores bem preparados em geral usam uma cadeia de sistemas intermediários, alguns (ou muitos) dos quais podem nem ao menos saber que foram comprometidos. Tentar seguir a trilha desse tipo de ataque pode ser difícil, e então você percebe a falta que fazem profissionais de rede em muitos provedores de pequeno e médio porte. Mas ser educado e atencioso, mesmo com os amadores que precisarão que você explique a eles que aquele sistema operacional pelo qual eles pagaram uma pequena fortuna não é tão seguro como a propaganda dizia, pode ajudar em muito na sua tarefa.
Naturalmente você deverá também notificar qualquer entidade de segurança da qual seja membro, e os desenvolvedores ou proprietários de qualquer software no qual você tenha encontrado bugs que comprometam a segurança e para os quais ainda não exista correção. Mas veremos isto com detalhes na segunda parte deste artigo. Até o próximo mês!
Uma parte importante do processo de prevenção dos abusos na Internet é sempre reportar os fatos, e tomar providências adequadas para que eles não se repitam. Existem procedimentos estabelecidos (e com um razoável grau de sucesso) entre os provedores de maior porte, muitas vezes ignorados pelos administradores de redes menores conectadas à Internet. Para auxiliar neste assunto, contamos com a experiência de Rodrigo Albani Campos (camposr@matrix.com.br), responsável técnico pela segurança de um dos maiores provedores de acesso do Brasil e também grande advogado do uso de software livre (embora seja da facção FreeBSD).
|
Quadro - identificando o responsável por uma rede Usuários de sistemas Unix em geral (incluindo o Linux) têm à sua disposição o comando whois, que fornece esse tipo de informação de maneira simples. Veja um exemplo:
|
Já vimos o que fazer quando se detecta uma invasão no sistema. Entretanto, trabalho, dor de cabeça e cabelos brancos podem ser poupados se você preparar sua segurança adequadamente, antes mesmo de expor seu sistema ao acesso de usuários. Existem alguns pequenos truques e técnicas (ok, alguns nem tão pequenos assim) que podem facilitar sua tarefa de manter os intrusos do lado de fora, e até mesmo de voltar ao ar rapidamente após sofrer um ataque bem-sucedido.
Faça backups regularmente
Políticas de backup são complexas o suficiente a ponto de não as abordarmos neste documento (quem sabe em um próximo?), mas convém registrar algumas idéias sobre o assunto.
Se você tem 650 MB, ou menos, de dados para armazenar, que tal começar a gravar regularmente em CD-ROM? Eles são portáveis, relativamente resistentes (se bem acondicionados), confiáveis e não-regraváveis. Caso você realmente precise gravar grandes volumes de dados em fitas, lembre-se de protegê-las contra gravação antes de guardá-las, e de sempre verificar se estão corretamente gravadas, ainda que por amostragem. Lembre-se também de armazenar seus backups em local seguro, com cópias fora do seu laboratório.
Uma estratégia comum de backup utiliza 6 fitas - 4 para os dias da semana, uma para as sextas-feiras pares, e uma para as sextas-feiras ímpares. Execute um backup incremental todos os dias, e um completo nas sextas-feiras. Dê segurança aos diagnósticos do sistema
O syslog é uma ferramenta importantíssima para acompanhar o que se passa em qualquer sistema UNIX, e você deve fazer o máximo para garantir que os dados armazenados por ele sejam confiáveis. Um primeiro passo é fazer com que os seus arquivos (geralmente em /var/log) possam ser lidos e escritos apenas por usuários privilegiados; mas você pode avançar mais. Uma possibilidade é anexar uma impressora local de baixo custo ao seu sistema e configurar o syslog para imprimir nela uma segunda cópia das mensagens relacionadas à segurança. Nenhuma invasão via rede conseguirá apagar este registro... Outra possibilidade é utilizar o serviço de syslog via rede, gravando uma cópia dos seus logs em um servidor considerado como seguro (um servidor que não esteja diretamente exposto à Internet). Não é difícil configurar este serviço; leia o manual do syslog.conf para mais detalhes.
Além de gravar os logs, lembre-se de lê-los com atenção - e regularmente. A inspeção dos logs deve fazer parte da sua rotina, ou através de ferramentas de filtragem automática, bem configuradas. Dê especial atenção ao auth - Múltiplas falhas de login costumam estar associadas a tentativas de invasão.
Alterar os logs da máquina faz parte dos procedimentos-padrão de invasão. Portanto, se você notar que alguns dados gravados no log impresso, ou no syslog remoto, não constam no seu log local, fique alerta: é quase certo que você está com o seu acesso de superusuário comprometido. Se você não tem os logs impressos ou armazenados em um servidor remoto, pode ser mais difícil notar que eles estão sendo alterados. Em todo caso, comparar seus logs com os que estão gravados em sua fita de backup pode ajudar. E lembre-se: simplesmente não há desculpas para não ter um esquema regular de backups.
Aplique todas as atualizações de segurança
A grande maioria dos usuários de Linux instalam o sistema a partir de um CD-ROM. Os CD-ROMs não são caros e não é difícil obter novas cópias a cada mês, e manter o sistema sempre atualizado. Entretanto, isto está longe de ser o suficiente. Sempre que é descoberta uma nova falha de segurança, os programas e técnicas para tirar proveito desta falha (os chamados exploits) multiplicam-se a uma velocidade alucinante através da Internet.
De modo geral (embora não em 100% dos casos), a solução para o problema é divulgada quase que simultaneamente com o surgimento do respectivo exploit. A diferença básica aqui é: os possíveis invasores, incluindo tanto os garotos de 15 anos que acham divertido invadir e danificar sistemas quanto os profissionais que irão tentar obter cópias dos seus valiosos bancos de dados sem deixar nenhum vestígio, estão atentos ao surgimento de novos exploits, e provavelmente os testarão no seu sistema (de fato, eles utilizam parsers que testam rapidamente uma longa série de redes e domínios, mesmo que estes não sejam conhecidos ou divulgados). E você? Quanto tempo faz desde que você não lê todas as mensagens da Bugtraq, deixou de ir mais de uma vez ao dia no Security Focus e esqueceu de inscrever sua nova conta de e-mail na lista de anúncios de atualizações do seu fornecedor de sistema operacional?
Outras técnicas
Naturalmente, fazer backups, manter logs e estar bem informado e atualizado não são fatores suficientes para garantir a segurança do sistema. Eles foram citados aqui apenas porque são os alicerces sobre os quais se constrói um sistema seguro. Além daqui, você precisará seguir com outros guias, que lhe ensinarão as técnicas necessárias: construção de firewalls, segurança de servidores de artigos, criptografia, configuração de filesystem, configuração de usuários e senhas, e muito mais. Algumas sugestões de leitura são:
* Livros: UNIX System Administration Handbook (ed. Prentice Hall), Practical UNIX & Internet Security (ed. O'Reilly), Maximum Security: A Hacker's Guide to Protecting Your Internet Site and Network (SAMS). Existem vários outros livros sobre o assunto, alguns até mesmo em Português.
* HowTos: os seguintes HOWTOs estão disponíveis em linuxdoc.org: IPCHAINS-HOWTO, NET-3-4-HOWTO, Security-HOWTO, Firewall-HOWTO e vários outros. Grande parte das informações básicas sobre a configuração de segurança pode ser encontrada nestes textos. E todos os seus invasores potenciais já os leram...
* Outros sites: securityfocus.com, insecure.org, tripwire.org, www.nic.br, freshmeat.net/appindex/console/firewall%20and%20security.html, www.cerias.purdue.edu/coast/ids (este último contém links para softwares de detecção de invasões), www.linuxcare.com/viewpoints/view/04-04-00.epl (um plano de 12 passos para a segurança efetiva).
Revista do Linux - Digamos que eu seja o responsável por uma rede particular, por exemplo, de um escritório de advocacia, conectada à Internet através de um provedor comercial, e detectei - e bloqueei - uma invasão. A quem devo contatar?
Rodrigo - Bem, nesta situação em que você já sabe quem é o invasor e bloqueou o acesso do mesmo e/ou corrigiu a falha de segurança, os próximos passos são os seguintes:
1. Identificar o contato técnico responsável pelo domínio ou, na falta de DNS reverso para o IP do invasor, o contato técnico responsável por aquela rede. Isso pode ser feito de diversas maneiras - veja quadro.
2. Após a identificação, deve ser elaborado um e-mail com as
seguintes informações:
+ Natureza do ataque
+ Impacto do ataque
+ Os logs da invasão, que demonstram a origem da mesma
+ O TIMEZONE onde você se encontra (isso é essencial e é
geralmente esquecido!), pois sem essa informação o contato de
segurança do provedor não terá como confrontar os logs do
ataque com os seus registros de acesso, de forma a
identificar quem estava utilizando o serviço naquele momento.
Não esqueça de que este e-mail estará sendo enviado para pessoas que geralmente não têm culpa alguma do ataque, portanto, procure manter um tom cordial.
RdL - Quem deverá receber esse e-mail?
Rodrigo - Isso é descrito na RFC 2142 (ftp.isi.edu/in-notes/rfc2142.txt), que sugere os endereços de e-mail comuns para serviços, funções e cargos. O destino do mail deverá ser abuse@provedor.do.invasor.com.br, com cópias para os contatos previamente identificados no passo 1. Uma cópia adicional deve ser enviada para o endereço abuse@seu.provedor.com.br.
RdL - É necessário contatar algum órgão oficial de segurança?
Rodrigo - Inicialmente, não. Isso deve ser feito apenas nessas situações:
* Descaso dos contatos do provedor de acesso do invasor;
* Não existência da conta abuse no provedor de acesso do invasor;
* Reincidência da invasão ou da tentativa de invasão. Nesse caso, seu mail deve ser enviado para o "Security Officer" do Brasil, através do endereço nbso@nic.br. Mais detalhes podem ser encontrados na URL www.nic.br/nbso.html.
RdL - Imaginando uma situação análoga à de nossa primeira pergunta, mas onde o responsável pela rede não seja capaz de bloquear ou impedir a invasão sozinho, a quem ele deve contatar?
Rodrigo - Em primeiro lugar, ele deve analisar o impacto da invasão no seu ambiente, e considerar a possibilidade de desconectar a máquina da rede imediatamente. Um backup das informações também deve ser feito após a identificação da invasão, em uma mídia diferente daquela em que o backup é feito regularmente. Após tomar as cautelas acima, aí sim, deve-se notificar o contato de segurança de seu provedor, pelo e-mail abuse@seu.provedor.com.br, ou com o responsável técnico pelo seu servidor (a pessoa que o instalou para você, por exemplo), solicitando que seja feita uma análise de segurança em seu sistema, visto que você não foi capaz de identificar a origem da invasão ou a falha de segurança que permitiu a mesma. Adicionalmente, pode ser uma boa idéia verificar em listas de mail especializadas se ataques similares têm acontecido nas ultimas semanas em outras empresas. Infelizmente, no Brasil os sites e listas que oferecem informações sérias sobre isso são exceções. No mundo dos BSD Unix, eu posso recomendar a bsd-l@br-unix.org.
RdL - Que responsabilidade cabe ao provedor do qual estão partindo os ataques ou probes? E até que ponto ele é obrigado a apurar os fatos?
Rodrigo - Isso ainda não é muito claro, visto que a legislação ainda não trata dos crimes digitais especificamente, tendo de encaixar esse tipo de atividade em outras leis. De qualquer maneira, existe uma prática comum em todos os provedores sérios de tomar atitudes. Como já expliquei, caso haja descaso do provedor, o ideal é que se envie mail para o "security officer" para que ele tome uma atitude efetiva.
RdL - Que tipo de informação ele é obrigado a me fornecer, e como o administrador da rede invadida pode convencê-lo?
Rodrigo - O provedor de fato não tem nenhuma obrigação de lhe oferecer informações sobre o invasor, mesmo porque isso geralmente fere regras contratuais entre o provedor e seus clientes. No entanto ele tem a obrigação de tomar alguma atitude com o mesmo, desde uma simples notificação até o cancelamento de sua conta de acesso. Existem algumas "dicas" para convencer o provedor de tomar alguma atitude; note que isso só deve ser feito se houver um descaso do provedor:
* Mande mail novamente para o contato de segurança do provedor com cópia para o "security officer", e deixe claro no texto do seu mail que ele está indo com cópia para o nbso.
* Faça "barulho", mande mail para todos no provedor, como webmaster, abuse, security, adm, etc.
* Aja como um profissional; usar termos que façam você parecer um moleque só vai piorar as coisas.
* Forneça informações realmente relevantes, atenha-se ao incidente.
RdL - Na sua experiência, quais os ataques mais comuns no Brasil?
Rodrigo - Os ataques mais comuns, sem dúvida nenhuma, são os causados por ferramentas amplamente disponíveis na rede, como NetBus, DeepThroat, BackOrifice, etc. Esse tipo de incidente representa até 70% dos e-mails que chegam à caixa postal abuse@matrix.com.br, e geralmente apenas uma simples notificação basta para que o "cracker" deixe de utilizar essas ferramentas. Em segundo lugar vêm os port-scans, que aparecem com certa freqüência, os alvos preferidos são instituições; educacionais e sites conhecidos como os da NASA. Em terceiro lugar aparecem os incidentes mais sérios, que são invasões efetivas dos sistemas. Esses dois últimos são tomados por mim com mais atenção, e em alguns casos a conta do usuário é cancelada. Isso depende de um julgamento pessoal quanto à seriedade do caso.
RdL - Para finalizar, se você pudesse indicar um website único e uma única lista para o administrador de redes que quer ficar bem informado sobre falhas e atualizações, quais seriam? E quais os livros que você considera como leitura obrigatória?
Rodrigo - A lista e o site que eu recomendaria são ambos da Security Focus (também conhecida como bugtraq) - www.securityfocus.com. Os livros que eu considero essenciais na biblioteca do administrador de sistemas - preocupado com a segurança de sua rede - são o Practical Unix and Internet Security (ed. O'Reilly) e o Firewalls and Internet Security: Repelling the Wily Hacker (ed. Addison-Wesley). Ambos são livros conceituais, com regras que se aplicam a qualquer sistema. Não importa que sua rede tenha 10 máquinas ou 1000 máquinas, as informações contidas nesses livros são muito úteis.
O Arquivo Histórico do BR-Linux.org mantém no ar (sem alteração, exceto quanto à formatação) notícias, artigos e outros textos publicados originalmente no site na segunda metade da década de 1990 e na primeira década do século XXI, que contam parte considerável a história do Linux e do Open Source no Brasil. Exceto quando indicado em contrário, a autoria dos textos é de Augusto Campos, e os termos de uso podem ser consultados na capa do BR-Linux.org. Considerando seu caráter histórico, é provável que boa parte dos links estejam quebrados, e que as informações deste texto estejam desatualizadas.