Recomendações

Implementar filtros de ingresso à rede para restringir tráfego forjado: ao permitir que a rede local possa apenas originar tráfego com endereços IP de origem pertencentes ao seu próprio range, e proibir tráfego originado por IPs de origem inválidos, fora do range, os problemas de spoofing podem ser eliminados.

Em resumo, se o endereço de origem do pacote for válido, pertencer ao próprio range, encaminhar apropriadamente o pacote. Se o endereço de origem do pacote for qualquer outro, descartar o pacote. Os administradores de rede devem ainda guardar logs dos pacotes descartados, pois isto pode servir como base para monitorar atividades suspeitas.

Maiores informações: https://tools.ietf.org/html/bcp38

Um incidente de segurança é um evento relevante, no qual a política de segurança de um sistema é desrespeitada ou violada. Se a coleta de provas for feita corretamente, elas serão muito mais úteis na identificação do atacante, e há mais chances de serem admissíveis em caso de um processo criminal.

Esta BCP tem por objetivo expor orientações básicas aos administradores de sistemas, sobre o que deve ser feito, caso decida-se fazer coleta e proteção de informações relacionadas a uma intrusão, bem como auxiliar na elaboração de documentação de procedimentos de tratamento a incidentes de segurança.

Recomendações

• • Siga as Políticas de Segurança definidas para o seu sistema ou instituição, e interaja com a equipe de tratamento de incidentes, bem como com as forças policiais, caso seja necessário;
• • Registre uma imagem mais precisa possível do estado do sistema;
• • Mantenha anotações detalhadas, incluindo datas e horários. Anotações e cópias impressas devem ser datadas e assinadas;
• • Observe a diferença entre o relógio do sistema e o UTC. Para cada registro de horário fornecido, indique se o horário utilizado foi UTC ou hora local;
• • Esteja preparado caso necessite testemunhar judicialmente, anotando detalhadamente todas as ações tomadas, bem como as datas e horários;
• • Evite fazer alterações em dados que você esteja coletando, por exemplo. Não altere datas e horários de acesso à arquivos ou diretórios;
• • Remova meios externos de acesso à mudanças;
• • Na dúvida entre coletar ou analisar, colete primeiro e analise depois;
• • Os procedimentos definidos pela política de resposta à incidentes de segurança devem ser testados a fim de garantir a viabilidade de sua execução, e se possível automatizados, a fim de garantir agilidade e precisão na hora em que forem necessários;
• • Para cada dispositivo, os procedimentos de coleta devem ser feitos passo a passo. Caso a quantidade de dispositivos seja muito grande, distribua o trabalho entre os membros da sua equipe de modo a acelerar as atividades;
• • Faça uma cópia da mídia do sistema a nível de bit, caso seja necessário fazer análise forense.

Ordem de volatilidade

Ao fazer coleta de informações, você deve começar do meio mais volátil para o menos volátil. Exemplo de ordem de volatilidade de um sistema típico:

1. 1. Registradores, cache;
2. 2. Tabela de roteamento, cache ARP, tabela de processos, estatísticas de kernel, memória;
3. 3. Sistema de arquivos temporário;
4. 4. Dados de login remoto e monitoramento que sejam relevantes ao sistema em questão;
5. 5. Configuração física, topologia de rede;
6. 6. Mídia arquivável.

Procedimentos que devem ser evitados

Para evitar destruir evidências inadvertidamente, alguns cuidados devem ser observados:

1. 1. Não desligue o sistema até que você tenha completado a coleta de provas. Muitas informações podem ser perdidas e o atacante pode ter alterado scripts e serviços de inicialização para destruir provas;
2. 2. Não confie em programas do sistema. Rode os programas de coleta de provas através de mídia protegida;
3. 3. Não rode programas que modificam horário de acesso de todos os arquivos do sistema (ex: tar, xcopy);
4. 4. Ao remover conexões externas, note que simplesmente desconectando ou filtrando o sistema da rede, pode disparar gatilhos, que detectam a ausência de conexão e apagam provas.

Considerações de privacidade

• • Respeite as diretrizes e políticas de privacidade da sua instituição, bem como a legislação vigente. Garanta que as informações coletadas juntamente com as provas que você está procurando não estejam disponíveis para qualquer pessoa que normalmente não teria acesso a elas. Isto inclui acesso a arquivos de logs (que podem revelar padrões de comportamento de usuários), bem como arquivos de dados pessoais;
• • Não invada a privacidade de pessoas sem fortes justificativas. Não colete informações de área que você normamente não tem motivos para acessar (como arquivos de informações pessoais) a menos que haja indícios suficientes de que há, de fato, um incidente;
• • Certifique-se estar de acordo com procedimentos estabelecidos na sua instituição ao escolher os passos a tomar para a coleta de provas de um incidente;

Considerações legais

Provas computacionais devem ser:

• • Admissíveis: Devem estar de acordo com a legislação vigente para que possam ser utilizadas judicialmente;
• • Autênticas: Deve ser possível associar positivamente o material probatório ao incidente;
• • Completas: Devem contar toda a história e não apenas uma perspectiva particular;
• • Confiáveis: Não deve haver nada sobre a forma como as provas foram coletadas e manipuladas, que possa causar dúvidas sobre sua autenticidade e veracidade;
• • Críveis: Devem ser prontamente críveis e compreensíveis por um tribunal.

O procedimento de coleta

Os métodos de coleta adotados devem ser o mais detalhados possível. Da mesma forma que os Procedimentos de Tratamento de Incidentes de Segurança, eles não devem ser ambíguos, e elaborados de forma a reduzir a necessidade de tomada de decisões durante o processo de execução. Eles devem ainda ser transparentes e reprodutíveis. Tanto você pode ser solicitado a reproduzí-los futuramente, quanto terceiros devem ser capazes de testá-los.

Passos de coleta

• • Identifique onde estão as provas, listando quais sistemas estão envolvidos no incidente e dos quais serão coletadas informações;
• • Estabeleça o que é passível de ser relevante e admissível. Na dúvida, é melhor coletar muito do que não coletar o suficiente;
• • Para cada sistema, estabeleça a ordem de volatilidade;
• • Remova a possibilidade de acesso externo à mudanças;
• • Seguindo a ordem de volatilidade, utilize ferramentas recomendadas para a coleta de provas;
• • Registre o grau de desvio do relógio do sistema;
• • Questione se há algo mais que possa ser coletado como prova, durante o processo de coleta;
• • Documente cada passo;
• • Faça anotações sobre as pessoas envolvidas, quem estava presente, o que elas fizeram, o que observaram e suas reações;
• • Quando for possível, considere a gerar checksums e assinar digitalmente as provas, pois isto pode auxiliar a sua preservação. Ao fazê-lo, não altere as provas.
• • As provas devem ser rigorosamente protegidas. Além disso, a cadeia de custódia deve ser claramente documentada.

Cadeia de custódia

Você deve ser capaz de descrever claramente como foi encontrada as prova, como ela foi tratada e tudo o que aconteceu com ela. As seguintes informações devem ser documentadas:

• • Onde, quando e por quem a prova foi descoberta e coletada;
• • Onde, quando e por quem a prova foi manipulada e examinada;
• • Quem tinha custódia da prova, durante qual período e como ela foi armazenada;
• • Quando a prova passou para a custódia de outra pessoa, quando e como a transferência ocorreu (incluir números de rastreamento, etc).

Armazenamento

Se possível, mídias comumente utilizadas devem ser selecionadas para armazenamento. O acesso à prova deve ser extremamente restrito, e claramente documentado. Deve ser possível detectar acessos não autorizados.

Ferramentas recomendadas

Você deve ter os programas necessários para a coleta de provas e análise forense em mídias somente-leitura (por ex, CD). Você deve ter este kit de ferramentas, para cada sistema operacional que você gerencia, já preparado antecipadamente para caso venha a necessitar utilizá-lo. Estas ferramentas devem incluir os seguintes itens:

• • Um programa para examinar processos. Ex: ps;
• • Programas para examinar o estado do sistema. Ex: showrev, ifconfig, netstat, arp;
• • Um programa para fazer cópias bit a bit. Ex: dd, SafeBack;
• • Programas para geração de checksums e assinaturas. Ex: sha1sum, dd, SafeBack ou pgp com checksum habilitado;
• • Programas para gerar e examinar imagens de core. Ex: gcore, gdb;
• • Scripts para automatizar a coleta de provas. Ex: The Coroner´s Toolkit.

Maiores informações: https://tools.ietf.org/html/bcp55

Recomendações

A principal recomendação é utilizar os meios providos pela implementação escolhida (BIND, PowerDNS, etc) para fornecer serviço de resolução recursiva de nomes apenas para as redes pretendidas. Por padrão, servidores de nomes não devem oferecer serviço recursivo para redes externas.

Recomendações para autorização de clientes

• • Autorização baseada em endereço IP: Use o endereço IP de origem das consultas DNS e filtre-as através de uma Lista de Controle de Acesso (ACL), de modo a atender apenas aos clientes pretendidos;
• • Seleção baseada na interface de origem: Use a interface de origem da consulta como um diferenciador para selecionar quais clientes devem receber serviço;
• • Para usuários móveis, use um servidor de nomes cache, rodando no dispositivo móvel, ou utilize uma VPN para um servidor confiável;
• • Em servidores que não necessitem prover serviço recursivo, como servidores que são apenas autoritativos, a recursão deve ser completamente desabilitada. Em geral, é uma boa idéia manter os serviços autoritativos e recursivos separados, até por questões práticas;
• • Mesmo com todas estas recomendações, administradores de rede devem também considerar a implementação de filtros de ingresso (BCP 38) em roteadores, para prevenir o uso de endereços falsos (spoofing).

Maiores informações: https://tools.ietf.org/html/bcp140

Devido ao esgotamento do IPv4 e a grande utilização de técnicas de compartilhamento de endereços IP (ex: NAT), esta BCP recomenda que sejam armazenados em servidores conectados diretamente à Internet, juntamente com o endereço IP de origem, dados como número de porta e registro de data e hora (timestamp) precisos.

Recomendações

É recomendado como melhor prática que servidores conectados diretamente à Internet, como por exemplo servidores de e-mail, servidores web, ao armazenar logs de endereços IP de origem de tráfego de entrada, também armazenem:

• • O número da porta de origem;
• • O timestamp com precisão de segundos ou mais, de uma fonte de tempo rastreável (Ex: NTP). Preferencialmente deve estar em UTC, ao invés de hora local com UTC-offset ou timezone;
• • O protocolo de transporte utilizado (usualmente TCP ou UDP) e o número da porta de destino, quando o servidor de aplicação estiver configurado para utilizar múltiplos transportes e múltiplas portas.

Em uma estrutura com compartilhamento de endereços, a ausência destas informações de portas e timestamp preciso, pode dificultar a identificação sem ambiguidades de clientes em casos de investigações por abusos ou ameaças à segurança pública. Além disso, também deve-se considerar medidas de segurança adequadas para proteger os logs armazenados no servidor. A proteção dos logs é crítica em investigações de incidentes, pois caso logs sejam adulterados, evidências podem ser perdidas.

Mesmo que a utilização de técnicas de compartilhamento não esteja prevista para IPv6, as recomendações acima se aplicam tanto para IPv4 quanto IPv6, ainda que seja por motivos de consistência e simplificação de código. Estas recomendações também se aplicam a outros dispositivos, como balanceadores de carga, que estejam armazenando logs de conexões de entrada para outros servidores.

Maiores informações: https://tools.ietf.org/html/bcp162

O BGP - Border Gateway Protocol, é um protocolo utilizado na Internet para fazer a troca de informações de roteamento entre diferentes domínios de rede. O BGP não inclui diretamente mecanismos que controlem se as rotas trocadas estão em conformidade com as várias diretrizes definidas pela comunidade da Internet.

Esta BCP visa descrever as principais medidas para proteger as sessões BGP, como TTL (Time to Live), TCP-AO (TCP Authentication Option) e filtros de plano de controle. Descreve também medidas para melhor controlar o fluxo de informações de roteamento, utilizando filtros de prefixos e sua automatização, filtros de caminho de AS (Autonomous System), route flap dampening, e limpeza de comunidades BGP.

Recomendações

---

• Proteção do roteador BGP

• Melhores práticas recomendadas para proteção de sessões TCP utilizadas pelo BGP

• Filtro de Prefixos

• Filtro de AS path

• • Aceitar de clientes apenas AS pertencentes a eles ou de terceiros com autorização para trafegar através deles;
• • Não se deve aceitar prefixos com números de AS privado nos updates;
• • Não se deve aceitar prefixos quando o primeiro número de AS no caminho não pertence ao peer, a menos que o vizinho seja um route server BGP;
• • Não se deve aceitar o próprio número de AS nos updates.

Maiores informações: https://tools.ietf.org/html/bcp194

O escudo-DHCPv6 é um mecanismo utilizado para proteger hosts conectados a redes comutadas contra servidores DHCPv6 não autorizados, da mesma forma como já existe implementação para servidores DHCPv4.

O dispositivo de camada 2 filtra as mensagens de servidores DHCPv6 direcionadas a clientes DHCPv6 de acordo com diferentes critérios. O mais básico critério de filtro é que mensagens originadas por um servidor DHCPv6 são descartadas pelo dispositivo de camada 2, a menos que elas sejam recebidas em portas específicas do dispositivo, previamente definidas, nas quais um servidor DHCPv6 real ou um relay esteja, de fato, conectado. É importante destacar que esta abordagem protege apenas contra ataques baseados em DHCPv6 direcionados a hosts, não protegendo contra ataques direcionados aos servidores DHCPv6.

O dispositivo de camada 2 deve ser configurado de modo a especificar as portas de camada 2 que tem permissão para receber pacotes de DHCPv6 e repassá-los para clientes. As portas que não tem permissão para encaminhar os pacotes DHCPv6, devem aplicar filtros para descartar os pacotes, sendo recomendado também manter logs de descartes.

Caso o escudo-DHCPv6 esteja sendo implantado em um cenário com vários switches em cascata, as portas de alimentação precisam estar habilitadas para receber mensagens de servidor DHCPv6. Nesse caso, os dispositivos irão confiar nas instâncias superiores para fazer a filtragem adequadamente, pois não terão como distinguir quais mensagens DHCP da porta de alimentação são válidas.

Maiores informações: https://tools.ietf.org/html/bcp199