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

  Uma tarefa extremanente importante e que deve fazer parte do cotidiano de administradores de redes é a constante educação dos usuários. Sabe-se que grande parte dos problemas de segurança são originados na rede interna da organização e, muitas vezes, são causados pelo desconhecimento de conceitos e procedimentos básicos de segurança por parte dos usuários. Um exemplo clássico deste problema é a má configuração do programa de leitura de emails de um usuário, que faz com que qualquer arquivo anexado a uma mensagem seja automaticamente aberto ou executado, permitindo a instalação de backdoors, cavalos de tróia, disseminação de vírus, etc.

  O primeiro fator que contribui diretamente para o processo de educação e o estabelecimento de políticas de segurança e de uso aceitável, claras, sem ambiguidades, conhecidas e completamente entendidas pelos usuarios da rede. Outro fator importante é o estabelecimento de um canal de comunicação, por exemplo, através de listas de emails, onde informações sobre questões relevantes de segurança são frequentemente passadas para os usuários da rede. A descoberta de uma vulnerabilidade de segurança que afeta o servidor Web da organização pode não ser relevante para os usuários, mas a notificação da descoberta de um novo vírus, sua forma de infeção e métodos de prevenção são informações que devem ser conhecidas e aplicadas por todos os usuários.

  Muitas vezes e, principalmente, em grandes organizações, tarefas como a instalação e configuração do sistema operacional e softwares de um computador são realizadas pelo próprio usuário. Daí vem um dos fatores de grande importância neste processo de educação, pois a execução de tais tarefas tem impacto direto na segurança das redes e sistemas de uma organização. Procurando cobrir os tópicos necessários para a educação do usuário, dentre outras questões, foi desenvolvida a “Cartilha de Segurança para a Internet”, que tem por finalidade sanar algumas dúvidas comuns sobre segurança de computadores e redes e sobre o significado de termos e conceitos amplamente utilizados na Internet. Além disso, a cartilha procura enumerar, explicar e fornecer um guia para uma série de procedimentos que visam aumentar a segurança de um computador e de posturas que um usuário pode adotar para garantir sua segurançaa na Internet. 

• Sincronização de relógios:

  Os relógios de todos os sistemas da sua rede (incluindo as estações de trabalho) deverão estar sincronizados, ou seja, deverão ter exatamente o mesmo horário. Para que isso aconteça, você deve usar um protocolo de sincronização de relógios, tal como o NTP (Network Time Protocol). Este protocolo é o mais recomendado, pois existem implementações dele para os mais variados sistemas operacionais.

  Para obter maior precisão no ajuste e para minimizar o tráfego desnecessário na rede, sugere-se que a sincronização via NTP seja implementada observando-se as seguintes recomendações:

• Procure manter em sua rede um servidor NTP local. Esse servidor é quem irá realizar a sincronização com um servidor externo. As demais máquinas da sua rede, por sua vez, terão seus relógios sincronizados com o relogio do servidor local.
• Muitos backbones disponibilizam um servidor NTP a seus clientes. Consulte o suporte técnico do seu backbone para verificar se ele oferece este serviço e como você pode fazer para utilizá-lo.

• Timezone:

  Caso você trabalhe com servidores Unix, ajuste o relógio de hardware destes sistemas para a hora padrão de Greenwich (GMT) e configure adequadamente o seu fuso horário (timezone) para que a hora local seja exibida corretamente. O uso do timezone certo também possibilita o ajuste automatizado do relógio por conta do horário de verão. Para que isso seja possível, você deverá criar ou obter um arquivo de informações de timezone com as datas corretas de início e fim do horário de verão. Para maiores informações, consulte a documentação do comando zic.

  Em muitas redes, a administração de sistemas é uma responsabilidade dividida entre várias pessoas. Nesses casos, e necessário estabelecer algumas regras para garantir a eficiência do trabalho em equipe.

• Comunição Eficiente: Em primeiro lugar, é essencial que os diferentes administradores comuniquem-se de maneira eficiente. Um bom modo de fazer isto, é estabelecer listas de discussão por email que sejam internas a sua organização. Estas listas podem ser usadas para, entre outros propósitos, comunicar alterações na configuração dos sistemas, notificar os demais administradores a respeito de ocorrências relevantes e servir como mecanismo de acompanhamento da divisao de tarefas. A grande vantagem de usar listas de discussão e que elas possibilitam a comunicação entre os administradores mesmo que alguns trabalhem em diferentes turnos ou locais. O histórico das listas pode servir para documentar decisões tomadas e para atualizar um administrador que tenha passado algum tempo afastado de suas atividades.

• Controle de Alterações na Configuração: A partir do momento em que várias pessoas ficam encarregadas da administração de um sistema, torna-se necessário dispor de meios que possibilitem a identificação de quem foi o responsável por cada alteração na sua configuração. Isso permite resolver problemas de forma mais eficiente, pois a pessoa que realizou determinada modificação e a mais indicada para ajudar na resolução de eventuais complicações dela decorrentes. 

  Uma forma mais automatizada de fazer isso e através do uso de ferramentas de controle de versão como o RCS e o CVS. Essas ferramentas também permitem manter um histórico de arquivos de configuração, de forma a possibilitar a recuperação de antigas versões desses arquivos. Recomenda-se que, sempre que possível, este tipo de ferramenta seja usado em sistemas que possuam múltiplos administradores.

  Um problema que surge em sistemas com multiplos administradores é a dificuldade de se manter um registro do uso de contas privilegiadas, tais como root e Administrator. Sempre que possível, estas contas não devem ser usadas diretamente. Um administrador deve entrar no sistema usando sua conta pessoal e a partir dela realizar suas tarefas, usando os privilégios mais elevados apenas quando estritamente necessário. Em sistemas Unix, isso é realizado através do comando su. O su traz como benefício adicional o fato de que o seu uso normalmente fica registrado nos logs do sistema, permitindo que se identifique quem acessou a conta de root em um determinado período.

  O sudo é uma ferramenta que permite que o administrador do sistema conceda a determinados usuários a possibilidade de executar comandos predefinidos como se eles fossem root (ou outro usuário), registrando nos logs do sistema a utilização desses comandos. O uso do sudo reduz a necessidade de compartilhamento da senha de root, uma vez que os usuários entram com sua própria senha para utilizar os comandos disponíveis através dele. Isso pode ser usado, por exemplo, quando existem contas de operador que são usadas para a realização de backups ou para invocar o procedimento de desligamento do sistema.

  Logs são muito importantes para a administração segura de sistemas, pois registram informações sobre o seu funcionamento e sobre eventos por eles detectados. Muitas vezes, os logs são o único recurso que um administrador possui para descobrir as causas de um problema ou comportamento anômalo.

• Geração de Logs:

  Para que os logs de um sistema sejam úteis para um administrador, eles devem estar com o horário sincronizado via NTP, ser tão detalhados quanto possível, sem no entanto gerar dados em excesso. Informações especialmente úteis são aquelas relacionadas a eventos de rede, tais como conexões externas e registros de utilização de serviços (arquivos transferidos via FTP, acessos a páginas Web, tentativas de login sem sucesso, avisos de disco cheio, etc.). Para registrar estas informações, é necessário configurar o sistema da maneira apropriada. A forma de fazer isto geralmente varia para cada componente específico.

• Armazenamento de Logs:

​​​​​​​  Armazenamento on-line: Os logs são tradicionalmente armazenados em disco, no próprio sistema onde são gerados. Essa é a opção mais obvia, mas ela possui alguns riscos inerentes que devem ser compreendidos. O primeiro deles, diz respeito a possibilidade dos logs serem destruídos durante uma invasão do sistema (uma ocorrência bastante comum). Em alguns sistemas, isso pode ser contornado através da instalação de um loghost centralizado. Um loghost centralizado é um sistema dedicado a coleta e ao armazenamento de logs de outros sistemas em uma rede, servindo como um repositório redundante de logs. Via de regra, o loghost não disponibiliza nenhum outro serviço, nem mesmo acesso remoto para os administradores, para minimizar a possibilidade de que ele seja comprometido. Outra vantagem de loghosts centralizados é que eles facilitam a análise dos logs e correlação de eventos ocorridos em sistemas distintos. Sempre que possível, o uso de loghosts centralizados e fortemente recomendado.

  Um segundo risco e a possibilidade de um atacante usar o logging para executar um ataque de negação de serviço contra um determinado sistema, gerando eventos em excesso até que o disco onde são armazenados os logs fique cheio e o sistema trave em consequência disto. O uso de uma partição separada para armazenar os logs pode minimizar o impacto deste problema. Outro ponto que merece atenção e a rotação automática de logs. Quando este recurso é utilizado, deve-se garantir que os logs sejam movidos para o armazenamento off-line, antes que eles sejam removidos do sistema pela rotação, evitando assim a perda de registros. Alguns sistemas trazem a rotação automática habilitada na sua configuração padrão; ao instalar um destes sistemas, verifique se esta configuração é compatível com os seus procedimentos de backup e armazenamento off-line de logs.

  Armazenamento off-line: Evidentemente, os logs não podem ser mantidos on-line por tempo indeterminado, pois acabam por consumir muito espaço em disco. A melhor estratégia para resolver esta questão e transferir periodicamente os logs do disco para dispositivos de armazenamento off-line, tais como fita, CD-R ou DVD-R. É recomendável gerar um checksum criptografico (tal como MD5 ou SHA-1) dos logs que são armazenados off-line. Esse checksum deve ser mantido separado dos logs, para que possa ser usado para verificar a integridade destes caso eles venham a ser necessários.

  Os logs armazenados off-line devem ser mantidos por um certo período de tempo, pois podem vir a ser necessários para ajudar na investigação de incidentes de segurança descobertos posteriormente. O Comitê Gestor da Internet no Brasil, recomenda que logs de conexões de usuários de provedores de acesso estejam disponíveis por pelo menos 3 anos. É aconselhável que os demais logs sejam mantidos no mínimo por 6 meses. É importante que os logs armazenados on-line, sejam incluídos no procedimento de backup dos seus sistemas.

• Monitoramento de Logs: 

  Os logs possibilitam o acompanhamento do que acontece com a sua rede e com os seus sistemas. Para tanto, é importante que eles sejam monitorados com frequência para permitir que eventuais problemas sejam rapidamente identificados. Existem algumas práticas recomendáveis, no que diz respeito ao monitoramento de logs:

• Incorpore o hábito de inspecionar os logs a sua rotina de trabalho;
• Faça isso pelo menos uma vez por dia, mas tenha em mente que sistemas muito importantes ou que geram muita informação podem precisar ter seus logs analisados com maior frequência;
• Procure investigar as causas de qualquer registro que lhe pareça incorreto ou anômalo, por mais insignificante que ele aparente ser;
• Procure identificar o padrão de comportamento normal dos seus sistemas, para poder encontrar eventuais anomalias com maior rapide.

  Quando estiver analisando logs, você deve certificar-se do timezone usado para registrar o horário dos eventos. Por exemplo, alguns softwares (como o Microsoft IIS, dependendo da configuração adotada) registram eventos com a hora de Greenwich (GMT), e não com a hora local. O desconhecimento do timezone em que estão os logs, pode facilmente invalidar uma análise e levá-lo a conclusões equivocadas. A medida em que você venha a adquirir prática com a análise dos seus  logs, você poderá escrever scripts ou pequenos programas para auxiliá-lo nesta tarefa, automatizando assim parte do processo. Estes scripts são úteis, por exemplo, para pré-processar os logs em busca de determinados conteúdos, para eliminar conteúdo repetitivo e para elaborar um resumo que pode ser enviado por email para o administrador do sistema. A eliminação de padrões relacionados a eventos considerados normais pelo administrador e especialmente importante porque, além de reduzir o volume de logs a serem analisados, pode evidenciar alguma atividade incomum.

  Uma outra opção é utilizar ferramentas que permitam monitorar logs em tempo real, como por exemplo o swatch. O swatch requer que você especifique um conjunto de padrões a serem monitorados e as ações a serem tomadas quando um destes padrões é registrado nos logs. As ações podem ser de diversos tipos, como exibir a informação registrada, notificar um determinado usuário por email e invocar um programa do sistema. A capacidade de execução de comandos arbitrários do swatch torna-o muito atraente, pois permite, por exemplo, que sejam tomadas medidas como filtragem de um endereço IP que gere determinado log e envio de uma mensagem de alerta para um telefone celular. Existem tambem várias ferramentas que tem por objetivo processar diversos formatos conhecidos de logs e que podem ser bastante úteis para o administrador. 

  O DNS (Domain Name System) é hoje um serviço essencial para o funcionamento da Internet. Essa importância, associada a natureza das informações que ele armazena, o tornam um dos alvos mais atraentes para atacantes. Desse modo, uma configuração adequada dos servidores DNS e crucial para aumentar a segurança e colaborar para o bom funcionamento da rede. Servidores DNS expostos a Internet estão sujeitos a uma série de riscos, dentre os quais destacam-se:

• Vazamento de informações sensíveis sobre a rede da organização através de transferências de zonas DNS. Essas informações podem ajudar um atacante a identificar os pontos fracos da rede e a escolher futuros alvos.
• Ataques de envenenamento de cache (cache poisoning), que levam um servidor a armazenar informações forjadas. Tais informações podem ser usadas para comprometer a segurança de clientes que façam consultas a esse servidor.
• Comprometimento do servidor através de vulnerabilidades no software de DNS, o que pode facilitar outras quebras de segurança no restante da rede da organização.

​​​​​​​  Transferências de zona são usadas para que os servidores DNS escravos (secundários) atualizem suas informações sobre uma determinada zona DNS em relação ao servidor mestre (primário) para essa zona. Restringir os endereços que podem fazer transferências de zona, é uma importante medida para evitar que atacantes obtenham informações detalhadas sobre a rede da organização, tais como endereços de roteadores, servidores de correio eletrônico e outros servidores DNS. As limitações de transferências de zona devem ser aplicadas a todos os servidores com autoridade para um domínio, independente de eles serem mestres ou escravos. Um equívoco comum e limitar as transferências de zona no servidor mestre e não fazê-lo nos servidores escravos.

  Preferencialmente, as transferências de zona devem ser limitadas através da configuração de controles de acesso no software servidor DNS. No BIND, por exemplo, isso é feito no named.boot (BIND 4) ou named.conf (BIND 8 e 9). 

  IMPORTANTE: Uma concepção errônea, infelizmente bastante difundida, é a de que a limitação de transferências de zona deve ser feita filtrando o tráfego para a porta 53/TCP do servidor DNS. Como a porta 53/TCP também é usada na resolução de nomes, essa filtragem pode comprometer seriamente a funcionalidade do seu serviço de nomes.

  Servidores DNS possuem duas funções principais. A primeira delas é a de disponibilizar informações a respeito de zonas sobre as quais possuem autoridade (caso dos servidores mestres e escravos para uma determinada zona). A segunda função é a de resolver nomes para clientes na sua rede (neste caso, o servidor é dito recursivo). Muitas vezes, o mesmo servidor desempenha ambas funções. Uma prática recomendável é separar a função de servidor com autoridade (mestre ou escravo) da função de servidor recursivo. Isso minimiza a eficácia de ataques de envenenamento de cache DNS. Na prática, essa separação significa que os servidores que possuem autoridade para uma ou mais zonas respondem somente a consultas relativas a essas zonas; por sua vez, os servidores recursivos nao possuem autoridade sobre nenhuma zona DNS.

  A forma mais simples de se fazer essa separação é configurar os servidores DNS com autoridade em máquinas distintas dos servidores DNS recursivos. Alguns softwares servidores DNS podem ser configurados para permitir que essa separação seja feita na mesma máquina; um exemplo é a versão 9 do BIND, que implementa isso através de visões (views).

  Os softwares servidores de DNS estão entre os alvos mais visados pelos atacantes, e já foram responsáveis por comprometimentos de segurança no passado. Dessa forma, uma medida recomendável é minimizar os privilégios com os quais o software servidor DNS e executado. Em ambientes Unix, muitas vezes é possível executar o servidor DNS em uma jaula chroot(). Versões mais recentes do BIND, permitem também que ele seja executado com permissões de um usuário diferente de root.

  O DNS oferece alguns tipos de registros de recursos que armazenam informações adicionais sobre os nomes de domínio, tais como HINFO, TXT e WKS. Estes registros nao são necessários para o funcionamento correto da resolução de nomes, sendo geralmente usados para facilitar a administração e a manutenção da rede. Informações sobre configuração de sistemas na sua rede devem ser consideradas sensíveis, pois podem ser usadas por um atacante para facilitar o comprometimento desses sistemas (ajudando-o a identificar máquinas com sistemas que possuam vulnerabilidades conhecidas, por exemplo). Em vista disso, o mais prudente e evitar registrar esse tipo de informação no DNS.

  Caso você deseje usar estes tipos de registros para facilitar a administração da rede, recomenda-se fortemente que essas informações não estejam disponíveis para usuários externos a sua rede. Isso pode ser conseguido usando-se servidores DNS inacessíveis externamente ou, para o BIND 9, através do uso adequado de visões. Outro fator importante, e que requer a atenção do administrador, consiste no fato de que o DNS pode fornecer um registro que possibilite a obtenção da versão do serviço de DNS sendo executado, o que pode ser usado para determinar a vulnerabilidade/suscetibilidade do serviço a um dado ataque. Por exemplo, o BIND fornece esta informação através de consultas do tipo “version.bind”.

  Portanto, é aconselhável que o administrador verifique se este tipo de registro pode ser fornecido por seu serviço de DNS e, então, configure-o levando em consideração uma ou mais das seguintes medidas:

• Bloqueie toda e qualquer consulta desta natureza, originada na rede interna ou externa;
• Permita que este tipo de consulta seja realizada apenas partindo da rede interna ou de IPs específicos, como da máquina do administrador ou do próprio servidor de DNS (localhost);
• Altere o conteúdo da string enviada como resultado da consulta, para por exemplo uma string vazia (“”);
• Gere registros de eventos (logs) para todas as consultas desta natureza.

  O uso mais frequente do DNS é a tradução de nomes em endereços IP. Entretanto, ele também permite descobrir o nome associado a um determinado endereço IP. Isso e chamado DNS reverso, e possibilita a identificação do domínio de origem de um endereço IP. Um DNS reverso mal configurado ou inexistente pode causar alguns transtornos. O primeiro deles é que muitos sites negam o acesso a usuários com endereços sem DNS reverso ou com o reverso incorreto. Em segundo lugar, erros na configuração do DNS depõem contra a competência técnica da equipe de administração de redes responsável pelo domínio, e isso pode vir a causar dificuldades quando for necessário interagir com equipes de outras redes. É recomendável, que você mantenha atualizado o DNS reverso dos endereços sob sua responsabilidade. Em alguns casos a administração do DNS reverso dos seus blocos pode ser delegada a sua rede, enquanto em outros o seu provedor de backbone é quem é responsável pelo DNS reverso dos seus endereços. Entre em contato com o seu provedor de backbone para obter informações sobre como atualizar o seu DNS reverso.

  Existem na Internet alguns endereços eletrônicos (emails) que são usados para entrar em contato com administradores, quando se deseja comunicar determinadas ocorrencias relacionadas a segurança de suas redes e sistemas. E extremamente importante que estas informações sejam válidas e estejam sempre atualizadas, pois assim garante-se que estas comunicações serão recebidas pela pessoa certa no menor espaço de tempo possível, o que pode muitas vezes impedir um incidente de segurança ou limitar as consequências. 

  A RFC 21424 define uma série de emails padrão que devem existir em todas as redes e que podem ser usados para contatar os seus responsáveis. Dentre os endereços padrão, existem dois que estão relacionados com segurança: abuse e security. O endereço abuse é usado para reportar abusos de recursos na rede. O endereço security, por sua vez, é utilizado para comunicar incidentes e alertar sobre problemas de segurança. Mensagens enviadas para estes endereços deverão chegar até os responsáveis por lidar com essas ocorrências. Não é necessário criar usuários com estes nomes, basta que sejam configurados aliases redirecionando as mensagens enviadas a estes endereços para os usuários apropriados. Cabe observar que muitas vezes estes endereços não são usados da maneira mais apropriada, com abuse recebendo reclamações de incidentes de segurança e security relatos de abusos, ou ambos os endereços sendo usados na mesma notificação. Sendo assim, é importante que sua rede possua ambos os endereços e que eles sejam constantemente monitorados pela sua equipe de segurança.

  Cada domínio registrado em um servidor DNS possui uma série de parâmetros de configuração no registro de SOA (Start of Authority). Um destes parâmetros é o  email do responsável pelo domínio, que muitas vezes também é usado para comunicar problemas de segurança envolvendo esse domínio. Um exemplo de registro SOA para o domínio example.org pode ser visto na figura . Nesta figura, ns. example.org é o nome do servidor DNS primário e joe.example.org representa o endereço joe@example. org, que seria o endereço de contato para o domínio example.org.

  Mantenha esse endereço do campo de SOA atualizado em todos os domínios sob sua responsabilidade, incluindo os de DNS reverso. Se preferir, use um aliás em vez de um email real. Nao se esqueça que o formato é usuario.domínio, e não usuario@domínio.

  Cada domínio ou bloco de endereços IP registrado, possui uma lista de informações de contato que remetem as pessoas responsáveis por estes domínios ou blocos. Geralmente existem três tipos de contatos:

• Contato técnico: Responsável técnico pela administração e operação do domínio ou bloco;
• Contato administrativo: Quem tem autoridade sobre o domínio ou bloco;
• Contato de cobrança: Quem recebe correspondências de cobrança das despesas de registro e manutenção do domínio ou bloco.

  Os endereços de email destes contatos, devem estar sempre atualizados e ser validos. No caso do contato técnico, isso significa dizer que mensagens enviadas para este endereço devem ser recebidas por um administrador de redes responsável pelo bloco ou domínio, e não por pessoal administrativo ou jurídico da organização. Este contato é usado com muita frequência para notificação de incidentes de segurança e outros problemas com a infra-estrutura de rede envolvendo o domínio ou bloco. Estas informações de contato são mantidas em uma base de dados chamada WHOIS. Esta base de dados é normalmente gerenciada por entidades que registram domínios (informações sobre domínios) e por provedores de backbone (informações sobre endereços IP). No Brasil, estas informações são administradas e disponibilizadas pelo Registro.br.

  O procedimento de atualização dos contatos no WHOIS, varia de acordo com a entidade de registro ou provedor de backbone. Entre em contato com a sua entidade de registro ou o seu provedor para obter informações detalhadas, sobre como efetuar essa atualização. 

  Uma medida de segurança muito importante na operação de redes é a substituição de protocolos, onde não haja autenticação através de senhas, ou onde senhas trafeguem em claro, por outros que corrijam estas deficiências. A lista de protocolos, cuja utilização deve ser evitada na medida do possível inclui:

• Telnet;
• FTP;
• POP3;
• IMAP;
• Rlogin;
• Rsh;
• Rexec.

  A maioria dos protocolos citados pode ser substituída pelo SSH. Essa substituição, além de fazer com que o tráfego entre cliente e servidor passe a ser criptografado, traz ainda outras vantagens, como proteção da sessão contra ataques tipo man-in-the-middle e sequestro de conexões TCP. Em relação ao POP3, existem diversas possibilidades de substituição:

1. Usar uma das variantes do protocolo (APOP, KPOP, RPOP), que tornam a autenticação de usuários mais segura, pois eliminam o tráfego de senhas em claro. As desvantagens desta opção são que nem todos os clientes de email suportam estas variantes e o conteúdo dos emails (que pode conter informações sensíveis) não é criptografado.
2. Usar POP3 através de um túnel SSH ou SSL. A primeira opção é interessante quando o servidor POP3 e o servidor SSH residem na mesma máquina. Para a segunda, podem ser usadas ferramentas como o stunnel. Alguns clientes de email ja suportam SSL diretamente, não sendo necessário o uso de túneis.
3. Usar uma solução de Webmail sobre HTTPS (HTTP+SSL). Esta solução também é válida para o IMAP.

  Existem alguns blocos de endereços IP que são reservados pelo IANA ( Internet Assigned Numbers Authority) para propósitos específicos. Não existe um documento único que registre todos estes blocos; alguns estão documentados em RFCs, enquanto que outros são considerados reservados por razões de compatibilidade histórica.

  A RFC 3330 lista vários blocos reservados pelo IANA. Uma lista dessas redes reservadas conhecidas é mostrada na tabela abaixo, juntamente com um breve comentário sobre a finalidade de cada rede.

  Outro ponto importante é que nem todo o espaço de endereçamento IPv4 está atualmente alocado. Uma lista dessas redes não alocadas, é portanto reservadas para o IANA, e mantida. Esta lista é frequentemente atualizada e é recomendável que seja consultada regularmente. Endereços não alocados e pertencentes a blocos reservados não devem ser propagados através da Internet, sendo recomendada a sua filtragem no perímetro da sua rede, tanto para entrada quanto para saída. Caso você possua redes privadas com IPs reservados, certifique-se de que os endereços utilizados sejam os especificados na RFC 19187 (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16).

  Endereços reservados não devem estar associados a nomes em servidores DNS públicos. Se você utilizá-los em redes privadas e quiser usar nomes para as máquinas, configure um servidor DNS privado ou utilize tabelas de hosts (/etc/hosts ou C:WINDOWSHOSTS). Caso você detecte um ataque proveniente de uma das redes da tabela e estes endereços estiverem sendo filtrados no perímetro, os pacotes correspondentes só podem ter partido de dentro da sua própria rede. A causa mais frequente para isso é a existência de erros de configuração que fazem com que os endereços reservados “vazem” de uma ou mais de suas redes privadas. Logo, deve-se procurar internamente a causa do problema em vez de tentar contactar o IANA (que e a entidade listada nos contatos de WHOIS para estes blocos).

  A importância dos backups na administração de sistemas nunca pode ser minimizada. Sem eles, muitos dados são simplesmente irrecuperáveis, caso sejam perdidos, devido a uma falha acidental ou a uma invasão. Os backups devem fazer parte da rotina de operação dos seus sistemas e seguir uma política determinada. O melhor e fazê-los da forma mais automatizada possível, de modo a reduzir o seu impacto sobre o trabalho dos administradores e operadores de sistemas. A lista de itens, cujo backup deve ser feito com frequência inclui:

• Dados;
• Arquivos de configuração;
• Logs.

  Um ponto que merece especial cuidado e o backup de binários (executáveis e bibliotecas), que geralmente deve ser evitado. Uma exceção a essa regra é uma cópia completa do sistema logo após a sua instalação, antes que ele seja colocado em rede. Backups que incluem binários não são aconselháveis, porque abrem a possibilidade de que eventuais Cavalos de Tróia ou executáveis corrompidos sejam reinstalados na restauração do sistema.

  Alguns cuidados devem ser tomados em relação ao local onde são guardados os backups:

• O acesso ao local deve ser restrito, para evitar que pessoas não autorizadas roubem ou destruam backups; 
• O local deve ser protegido contra agentes nocivos naturais (poeira, calor, umidade);
• Se possível, é aconselhável que o local seja também a prova de fogo.

  Os backups devem ser verificados logo após a sua geração e, posteriormente, em intervalos regulares. Isto possibilita a descoberta de defeitos em dispositivos e meios de armazenamento e pode evitar que dados sejam perdidos por problemas com backups que não podem ser restaurados. Algumas organizações providenciam meios para armazenar backups fora das suas instalações, como em cofres de bancos, por exemplo. Essa e uma boa maneira de garantir a disponibilidade dos backups em caso de problemas nas instalações. Entretanto, isso pode comprometer a confidencialidade e integridade desses backups. Uma possível solução é criptografar o backup e gerar um checksum (MD5 ou SHA-1, por exemplo) dele antes que seja entregue a pessoas de fora da organização. Uma verificação do checksum antes da restauração, pode servir como prova de que o backup não foi alterado desde que foi feito.

 Quando for necessário restaurar um sistema, isto deve ser feito com a máquina isolada da rede. Caso o sistema em questão tenha sido comprometido, revise a sua configuração após a restauração para certificar-se de que não tenha ficado nenhuma porta de entrada previamente instalada pelo invasor.

  Administradores envolvidos com a segurança de redes e sistemas necessitam buscar informações de forma a se manterem atualizados em relação a novas vulnerabilidades e correções de segurança. Devido a sua natureza dinâmica, o principal meio de obtenção de tais informações e a própria Internet, através de listas de discussão por email e sites especializados. Os tipos mais indicados de listas de discussão para um administrador incluem:

• Lista de anúncios de segurança de fornecedores de software e hardware, cujos produtos são usados na sua rede;
• Listas de administradores e/ou usuários desses produtos;
• Lista de alertas de segurança do CERT/CC.

  Destas, as listas de anúncios de segurança de fornecedores e a lista de alertas do CERT/CC são fortemente recomendadas a qualquer administrador. As listas destinadas a administradores e usuários de produtos, por sua vez, podem ajudá-lo a conhecer melhor as ferramentas disponíveis no seu ambiente computacional, muitas vezes levando-o a descobrir formas mais eficientes de trabalhar com elas. Existem outras listas que são indicadas para administradores que possuam alguma experiência e bons conhecimentos de programação. Essas listas costumam ter um alto tráfego e o conteúdo das suas discussões é bastante técnico, muitas vezes envolvendo o uso de conceitos avançados. A principal (e também a mais conhecida) destas listas é a Bugtraq. 

  IMPORTANTE: É recomendável que você tome cuidado com a procedência de informações relacionadas com segurança, procurando se restringir a fontes confiáveis. Existem diversos relatos de informações propositalmente erradas terem sido divulgadas com o objetivo de abrir brechas na segurança da rede daqueles que as tenham seguido.

  Engenharia social e a técnica (ou arte) de aproveitar-se da boa fé de pessoas para obter informações que possibilitem ou facilitem o acesso aos recursos computacionais de uma organização por parte de usuários não autorizados. Dentre as informações procuradas destacam-se as seguintes:

• Senhas de acesso;
• Topologia da rede;
• Endereços IP em uso;
• Nomes de hosts em uso;
• Listas de usuários;
• Tipos e versões de sistemas operacionais usados;
• Tipos e versões de serviços de rede usados;
• Dados sigilosos sobre produtos e processos da organização.

  Existem diversas formas de se efetuar um ataque de engenharia social, mas todas elas tem em comum a característica de usarem basicamente psicologia e perspicácia para atingir os seus propósitos. Atualmente, as mais populares sao:

• Usar telefone ou email para se fazer passar por uma pessoa (geralmente alguém da equipe de suporte técnico ou um superior da pessoa atacada) que precisa de determinadas informações para resolver um suposto problema;
• Aproveitar informações divulgadas em um fórum público da Internet (lista de discussão por email, newsgroup, IRC) por um administrador ou usuário que busca ajuda para resolver algum problema na rede;
• Enviar programas maliciosos ou instruções especialmente preparadas para um administrador ou usuário, com o objetivo de abrir brechas na segurança da rede ou coletar o máximo de informações possível sobre ela (esta técnica é particularmente eficaz, quando a pessoa pede auxílio em algum fórum de discussão pela Internet);
• Navegar por websites ou repositorios FTP em busca de informações úteis, muitas vezes é possível encontrar descrições detalhadas da infra-estrutura computacional e/ou documentos que, por descuido ou esquecimento, não foram removidos do servidor.

  A principal maneira de se prevenir contra estes ataques é orientando os usuários e administradores de redes e sistemas sobre como agir nestas situações. A política de segurança da organização desempenha um papel importante neste sentido, pois é nela que são definidas as normas para proteção da informação na organização.  Recomenda-se fortemente que os administradores tenham cuidado ao buscar ajuda em listas de discussão e outros fóruns na Internet. Estes recursos podem ser valiosos na resolução de problemas, mas também podem ser usados por terceiros para coleta de informações.

  Procure reduzir a exposição da sua rede em fóruns públicos — por exemplo, use endereços IP, nomes de hosts e usuários hipot éticos, e tente não revelar mais sobre a topologia da rede do que o estritamente necessário para resolver um dado problema. Tome cuidado com orientações passadas por pessoas desconhecidas, e evite executar programas de origem obscura ou não confiável—eles podem ser uma armadilha.

  Antes de apresentar técnicas para aumentar a eficácia de firewalls, é importante definir o que um firewall e é o que ele não é. Um firewall bem configurado é um instrumento importante para implantar a política de segurança da sua rede. Ele pode reduzir a informação disponível externamente sobre a sua rede, ou, em alguns casos, até mesmo barrar ataques a vulnerabilidades ainda não divulgadas publicamente (e para as quais correções não estão disponíveis). Por outro lado, firewalls não são infalíveis. A simples instalação de um firewall, não garante que sua rede esteja segura contra invasores. Um firewall não pode ser a sua única linha de defesa, ele é mais um dentre os diversos mecanismos e procedimentos que aumentam a segurança de uma rede. Outra limitação dos firewalls é que eles protegem apenas contra ataques externos ao firewall, nada podendo fazer contra ataques que partem de dentro da rede por ele protegida.

  Existem diversas soluções de firewall disponíveis no mercado. A escolha de uma delas esta atrelada a fatores como custo, recursos desejados e flexibilidade, mas um ponto essencial é a familiaridade com a plataforma operacional do firewall. A maioria dos firewalls está disponível para um conjunto reduzido de plataformas operacionais, e a sua escolha deve se restringir a um dos produtos que roda sobre uma plataforma com a qual os administradores da rede tenham experiência. Por exemplo, se você utiliza basicamente servidores Unix, é aconselhavel que você escolha um firewall que rode sobre a sua variante favorita de Unix, e não um produto que requeira Windows NT.

  Existem, basicamente, duas razões para esta recomendação. A primeira delas, é que você deve estar familiarizado o suficiente com o sistema onde o firewall será executado para configurá-lo de forma segura. A existência de um firewall instalado em um sistema inseguro, pode ser até mais perigosa do que a ausência do  firewall na rede. A segunda razão, é que os produtos tendem a seguir a filosofia da plataforma onde rodam; por exemplo, a maioria dos firewalls para Windows e configurada através de menus e janelas, ao passo que muitos firewalls para Unix são configurados por meio de arquivos texto.

  Outro fator importante, consiste na escolha do tipo de firewall que será implementado. Dentre os tipos atualmente disponíveis, destacam-se os filtros de pacotes, amplamente utilizados por terem baixo custo associado e por estarem normalmente integrados a dispositivos como roteadores ou alguns tipos de switches, ou por serem facilmente integráveis ou fazerem parte do kernel de diversos sistemas operacionais. Os filtros de pacotes normalmente analisam informações colhidas nos cabeçalhos de cada pacote, tais como endereços IP de origem e destino, protocolo utilizado, portas, e são basicamente divididos em duas categorias: os estáticos (stateless) e os dinâmicos (stateful). Os filtros estáticos são projetados para tomar decisões (como bloquear ou permitir) para cada pacote que entra ou sai de uma rede, sem considerar o contexto em que cada pacote esta inserido. Portanto, neste caso é preciso estabelecer regras, de forma explícita, tanto para o tráfego que entra na rede quanto para o tráfego que sai (incluindo o tráfego de resposta a conexões iniciadas externamente).

  Ja os filtros dinâmicos rastreiam e mantêm o estado das conexões contidas no tráfego de rede, fazendo com que cada pacote seja analisado dentro de um contexto (conexão que contém o pacote). Este tipo de filtro de pacotes, normalmente apresenta um melhor desempenho e permite que os dois sentidos de tráfego (entrada e saída) sejam considerados/tratados separadamente, uma vez que o tráfego de resposta é gerenciado automaticamente, simplificando assim o conjunto de regras a ser mantido e muitas vezes aumentando a qualidade da filtragem.

  Administradores experientes em Unix tem a disposição, diversas ferramentas de software livre que podem ser usadas para implementar firewalls, conforme mostra a tabela abaixo. Estas ferramentas permitem construir firewalls eficientes a um custo relativamente baixo, uma vez que seus requisitos de hardware são modestos.

• Localização dos Firewalls:

  A localização dos firewalls na rede, depende normalmente da sua política de segurança. Entretanto, existem algumas regras que se aplicam a grande maioria dos casos:

• Todo o tráfego deve passar pelo firewall. Um firewall só pode atuar sobre o tráfego que passa por ele. A eficácia de um firewall pode ser severamente comprometida se existirem rotas alternativas para dentro da rede (modems, por exemplo). Caso não seja possível eliminar todos esses caminhos, eles devem ser documentados e fortemente vigiados através de outros mecanismos de segurança.
• Tenha um filtro de pacotes no perímetro da sua rede. Esse filtro pode estar localizado entre o seu roteador de borda e o interior da rede ou no próprio roteador, se ele tiver esta capacidade e você se sentir confortável utilizando-o para esta tarefa. O filtro de pacotes de borda é importante para tarefas como bloqueio global de alguns tipos de tráfego e bloqueio rápido de serviços durante a implantação de correções após a descoberta de uma nova vulnerabilidade.
• Coloque os servidores externos em uma DMZ. É recomendável que você coloque os seus servidores acessíveis externamente (Web, FTP, correio eletronico, etc.) em um segmento de rede separado e com acesso altamente restrito, conhecido como DMZ (DeMilitarized Zone, ou zona desmilitarizada). A principal importância disso é proteger a rede interna contra ataques provenientes dos servidores externos — uma precaução contra a eventualidade de que um destes servidores seja comprometido. Por exemplo, suponha que um atacante invada o servidor Web e instale um sniffer na rede. Se este servidor Web estiver na rede interna, a probabilidade dele conseguir capturar dados importantes (tais como senhas ou informações confidenciais) é muito maior do que se ele estiver em uma rede isolada.
• Considere o uso de firewalls internos. Em alguns casos, e possível identificar na rede interna grupos de sistemas que desempenham determinadas tarefas comuns, tais como desenvolvimento de software, webdesign e administração financeira. Nestes casos, recomenda-se o uso de firewalls internos para isolar estas sub-redes umas das outras, com o propósito de aumentar a proteção dos sistemas internos e conter a propagação de ataques bem-sucedidos.

• Critérios de filtragem:

  Existem basicamente dois critérios de filtragem que podem ser empregados em firewalls. O primeiro é o de default deny, ou seja, todo o tráfego que não for explicitamente permitido e bloqueado. O segundo, default allow, é o contrário, ou seja, todo o tráfego que não for explicitamente proibido é liberado. A configuração dos firewalls, deve seguir a política de segurança da rede. Se a política permitir, é recomendável adotar uma postura de default deny. Esta abordagem é, geralmente, mais segura, pois requer uma intervenção explícita do administrador para liberar o tráfego desejado, o que minimiza o impacto de eventuais erros de configuração na segurança da rede. Além disso, ela tende a simplificar a configuração dos firewalls.

  No perímetro da rede, pelo menos as seguintes categorias de tráfego devem ser filtradas:

• Tráfego de entrada ( ingress filtering): pacotes com endereço de origem pertencente a uma rede reservada ou a um dos blocos de endereços da sua rede interna;
• Tráfego de saída (egress filtering): pacotes com endereço de origem pertencente a uma rede reservada ou que não faça parte de um dos blocos de endereços da rede interna.

  Um aspecto que deve ser considerado com cuidado e a filtragem do protocolo ICMP. O bloqueio indiscriminado de ICMP, pode prejudicar o funcionamento da rede. Por outro lado, o ICMP pode ser usado para revelar a um possível atacante informações sobre a rede e seus sistemas. Observe que muitos firewalls do tipo stateful, permitem a passagem de mensagens ICMP de erro associadas a conexões estabelecidas, o que minimiza o impacto da filtragem. O tráfego para a DMZ deve ser altamente controlado. As únicas conexões permitidas para os sistemas dentro da DMZ, devem ser as relativas aos serviços públicos (acessíveis externamente). Conexões partindo da DMZ para a rede interna devem ser, na sua maioria, tratadas como conexões oriundas da rede externa, aplicando-se a política de filtragem correspondente.

  IMPORTANTE: A DMZ e a rede interna não podem estar no mesmo segmento de rede (ligadas ao mesmo hub ou switch, por exemplo). É imprescindível que estas redes estejam em segmentos de rede separados.