Todos nós sabemos que nenhuma rede é inexpugnável, mesmo quando todas as boas práticas são seguidas e os dispositivos de segurança necessários estão instalados. Seja por alguma técnica ou método novo de ataque, ou por autoria ou conivência de pessoa interna, sempre existe a possibilidade de uma tentativa de invasão ser bem sucedida. Nesses casos, o que fazer?
Bem, antes de falar sobre o que fazer em uma situação de invasão é necessário pensar sobre o que deve ser feito antes. Sim, as atividades de resposta a emergências começam bem antes da invasão, e não tem a ver com as medidas aplicadas para preveni-la. Além de proteger sua rede, a empresa precisa também criar um plano e preparar-se para agir em caso de invasão. Se tudo der certo esse plano nunca sairá do papel, no entanto, se algo der errado a empresa irá se arrepender de não tê-lo feito. Abaixo estão listadas quatro medidas que julgo essenciais em qualquer plano, e que irão ajudar muito a controlar e reduzir os efeitos de uma invasão.
O ponto de partida é o estabelecimento de um time, idealmente composto de representantes das áreas de rede, servidores, sistemas aplicativos, negócios e segurança. Muitas vezes essas pessoas já são conhecidos por todos na empresa e possuem até uma relação pessoal, reduzindo a necessidade de formalização. Mas em empresas maiores é necessário formalizar um time, mantendo um pequeno cadastro com o nome e informações de contato. Já vi empresas perderem muito tempo apenas na tarefa de encontrar as pessoas chave que devem ser envolvidas. Uma empresa mais organizada teria também alguns procedimentos estabelecidos e o time treinado nesses procedimentos, além do time técnico com conhecimento mínimo de resposta a emergências, mesmo quando há contrato com um provedor externo, a fim de realizar as primeiras ações de reação ao ataque. É algo similar a uma brigada interna de incêndio, responsável pelo combate inicial ao fogo até a chegada dos bombeiros.
Em uma situação de emergência, uma das primeiras coisas que um especialista solicita é o mapa da rede, contendo não só diagramas atualizados de conexão física e lógica como serviços, protocolos e portas utilizadas, de preferência por servidor; além de regras de acesso configuradas em roteadores, firewalls, IPS e quaisquer outros dispositivos que permitam a definição de acesso. Sem esse mapa é quase impossível identificar o método usado em uma invasão e estabelecer medidas para conter ou rastrear o invasor. Manter este mapa atualizado é uma questão de prioridade e disciplina, porém é muito dificil depois de uma invasão correr atrás do prejuizo e tentar documentar a rede. O mapa também deverá ter a informação do nível de criticidade para o negócio da empresa de cada servidor ou grupo de servidores, além de outros dispositivos críticos de negócio.
Em relação aos serviços habilitados em um servidor, é essencial saber quais estavam habilitados antes da invasão. Não há muita valia listar os serviços disponiveis depois do servidor ter sido comprometido. Imaginem a situação de um servidor que possui apenas o serviço HTTP habilitado, e que ao ser invadido via porta 80 tem o serviço SSH habilitado pelo invasor para que este possa então controlá-lo remotamente. Uma avaliação do servidor após o ataque irá identificar o SSH como o serviço utilizado para a invasão, e assim este será desativado dando a falsa sensação de se ter bloqueado o acesso do hacker. No entanto, como a invasão ocorreu originalmente via HTTP, o invasor poderá novamente invadir via HTTP e reativar o SSH. Saber que antes da invasão só havia a porta HTTP ativada significa identificar corretamente como a invasão ocorreu e reagir eficientemente.
As ações em uma situação de ataque em andamento são distintas das ações de um ataque já realizado, porém em ambas fará uma grande diferença a existência de logs de aplicação, servidores e rede. E organizar um sistema de logs é também uma atividade prévia. Há dois elementos principais quando falamos de logs: sincronização de horários e centralização. A rastreabilidade de um ataque dependerá em muito da existência de logs em sistemas diferentes que possam ser correlacionados. Traços do ataque podem estar registrados nos logs de rede, dispositivos de segurança e nos servidores, e para correlacionar esses logs é indispensável que todos estejam compartilhando o mesmo horário. É uma tarefa hoje simples porém deixado de lado em muitas empresas. Centralizar logs é mais complexo, mas nem por isso deve ser negligenciado. A centralização evita que um invasor manipule, corrompa ou apague os logs; além de facilitar o trabalho de análise em uma eventual investigação. Hoje em dia há soluções de centralização que se encaixam bem em orçamentos de todos os tamanhos.
A quarta e última recomendação diz respeito a padronização. Padronização é bom em qualquer situação, já que reduz custos e complexidade, mas é muito importante na resposta a emergências. Um ambiente sem padronização significa um ambiente no qual a seleção e configuração de sistemas está descentralizada e até nas mãos dos usuários finais, e provavelmente não documentada, o que facilita em muito a ação de um hacker. Também ações de remediação são mais fáceis quando atingem todos os sistemas, e não apenas um ou outro. Imaginem uma empresa na qual os usuários e analistas tem liberdade para escolher o sistema operacional de suas máquinas, e na qual um hacker se estabeleceu dominando várias dessas máquinas. Mesmo o uso de Linux deve ser padronizado em distribuição e versão.
Para empresas que estão mais avançadas em sua preparação, eu também recomendo duas ações adicionais. A primeira é utilizar regularmente ferramentas de identificação de vulnerabilidades. Além de ser uma boa ação preventiva, saber quais são as vulnerabilidades de um sistema agiliza muito a identificação do método de ataque. Outra sugestão é o uso regular de ferramentas de análise de rede, como os analisadores de protocolo e detectores de anomalia. Essas ferramentas são de grande valia na hora de rastrear um invasor ou identificar a extensão de um ataque. Como exemplo, o detector de anomalias terá o mapa de todas as sessões de rede estabelecidas por um servidor, além de protocolos e portas usadas. Uma simples consulta às informações do detector de anomalias e à documentação da rede pode ser a diferença entre ter ou não a segurança da rede, sistemas e dados reabilitada.
