Um ataque de Man-In-The-Middle (doravante será referenciado

Um ataque de Man-In-The-Middle (doravante será referenciado como
MITM) é alcançado quando o atacante “envenena” a tabela ARP de dois
dispositivos com o MAC Address da sua placa Ethernet. Uma vez que a tabela
foi envenenada de maneira correta os dispositivos infectados enviam todos os
seus pacotes para o atacante quando comunicando entre si. Isto coloca o
atacante no meio da comunicação entre os dois, por isso “Homem do meio (ManIn-The-Middle)”, permitindo assim a ele interceptar e monitorar a comunicação
entre os dispositivos.
Hardening Linux
Os sistemas Linux são conhecidos por sua segurança superior ao
Windows, vários serviços são utilizados para que esta segurança seja mantida,
no entanto não significa que estejam isentos ou completamente protegidos
contra ataques e invasores. Para que se eleve ainda mais a segurança é
necessário executar o processo de hardening, consistindo em checar e corrigir
pontos vulneráveis.
No ataque de Man-in-the-middle alguns serviços têm seus pontos
explorados, e estes são: DNS-BIND, Apache, FTP, Postfix e Dovecot. Abaixo há
métodos sobre como realizar no hardening no BIND, que pode ser considerado
talvez como um dos serviços primordiais, visto que trabalha com o DNS.
BIND
BIND ou “Berkeley Internet Name Domain” é um programa para
instalar e configurar o DNS sendo ele o principal software para tal fim. Ele é
oferecido pelo ISC, e tem como características oferecer uma plataforma robusta
e estável, de modo que pode ser utilizado inclusive por grandes companhias e
em larga escala. Por se tratar de uma parte fundamental da internet como um
todo os servidores DNS são alvos constantes de ataques por hackers,
spammers, crackers, phishers e etc.
O ataque de MITM utilizando o DNS não é muito utilizado, no entanto,
quando feito causa uma seríssima brecha na segurança. O atacante
primeiramente captura o tráfego da rede especificamente para solicitações de
DNS na porta 53, ao reunir a informação e analisa-la ele consegue identificar
todos os servidores DNS na rede. O ataque usa o ARP spoofing (envio de
pacotes ARP falsos) para confundir a máquina que solicita a requisição, assim
enviando requisições de DNS para a máquina do atacante ao invés do servidor
DNS real. Cada requisição de DNS contém uma identificação única afim de
mapeá-la para a resposta recebida. Para o ataque o pacote de resposta precisa
deste número, mas com um pacote falso.
Na teoria o ataque mostra-se muito simples, no entanto na prática ele é
bem complexo e demanda muito tempo, mas uma vez realizado o estrago pode
ser incalculável e o que pode ser feito depende unicamente da imaginação do
atacante, como por exemplo: o atacante pode redirecionar todas as requisições
web para todos os IPs dele, criando um site de phishing e roubando logins,
senhas de bancos, projetos de empresas. Outra maneira de realizar o ataque é
lotar o servidor DNS enviando um grande número de requisições e neste interim,
interceptar o tráfego, afim de enviar respostas falsas para os solicitantes.
Abaixo alguns exemplos de ataque:
1. Ataques de DoS – DoS ou Denial of Service consistem em afetar a
performance do servidor, lotando-o de requisições e comprometendo a
infraestrutura do servidor, visto que inúmeras atividades dependem da
performance do mesmo.
2. Ataques de rede – Tais ataques tem como base o próprio DNS. Pode-se
destacar o de Cache Poisoning, que consiste em enganar um servidor
DNS a fazer o cache de endereços IP incorretos e enviar seus usuários a
sites errados e perigosos. Vários outros serviços também estão sujeitos a
ataques. O acesso irrestrito às informações sobre o DNS pode e é
utilizado para construir novos tipos de ataques.
3. Intrusão de sistemas – O limite da segurança do DNS é o mesmo limite
do sistema operacional no qual o servidor está sendo executado. Caso
ocorra o ataque em outros serviços que estejam em execução na máquina
(FTP, E-mail, HTTP) o servidor será comprometido e logo, utilizado em
outros ataques e/ou tarefas maliciosas.
4. Bugs – O BIND não está isento de Bugs e várias vulnerabilidades foram
encontradas e corrigidas ao longo dos anos no serviço. O BIND 9 corrigiu
inúmeros destes problemas, no entanto não existem softwares perfeitos.
Algumas medidas
É primordial limitar o acesso às operações de rede, liberando permissões
apenas para usuários autorizados e restringir o acesso a todos que não estejam
cadastrados, inclusive, é necessário reforçar a segurança para que sites que
acessem o servidor vejam apenas os dados que eles precisam.
1 – Limitar o acesso
Durante a configuração do serviço usuários descuidados autorizam o
acesso de qualquer pessoa para a consulta de nomes. Caso não seja um
servidor público, como Google e Open DNS, que suportam a carga enorme e
são protegidos, há um problema de performance e DoS, estes servidores abertos
são alvos fáceis para usuários mal intencionados. Logo, se faz necessário alterar
algumas linhas no arquivo localizado em /etc/named.conf que é onde se localiza
as configurações do servidor, em suma o que deve ser feito é: restringir usuários
de fora da rede interna em fazer consultar recursivas no DNS, restringir usuários
de fora da rede interna de realizarem consultas contra lookups em cache no
BIND.
A versão do BIND utilizada no projeto foi a 9.8.2, assim, a execução dos
comandos deve ser:
allow-query-cache {localhost;localnets;};
allow-query-recursion {localhost;localnets;};
allow-query {localhost;localnets;};
Nota: localnets são as redes anexadas de maneira física ao servidor que
roda o BIND.
Uma nova opção de allow-query-cache permite controlar acesso a dados
já em cache com uma opção global, sendo desnecessário adicionar uma opção
em cada zona.
2 – Restringir transferência de zonas
O número de sites que podem transferir por completo o conteúdo das
zonas DNS deve ser restrito e limitado, estas transferências devem ser
realizadas apenas por servidores que precisam de fato, de uma cópia destas
zonas. Alterando “allow-transfer” é possível controlar isto.
allow-transfer {IP/IP; };
Ou é possível impedir a transferência setando como {none} em allowtransfer.
3- Eliminar quaisquer alterações automáticos.
Atualmente como maneira cômoda há os updates e correções
automáticas e dinâmicas que rodam sem que haja uma permissão manual do
administrador, de modo que evita a “perca” de tempo enquanto o processo é
realizado. No entanto, autorizar estas alterações automáticas torna o servidor
vulnerável, portanto afim de proteger o servidor se faz necessário eliminar estas
atualizações
4- Remoção de Logins e Usuários desnecessários
Se faz necessário que o administrador certifique-se que apenas e
somente apenas os usuários autorizados tenham acesso à rede. Proteger a
conta do administrador também é de suma importância, pois caso ela seja
comprometida TODA a rede estará em perigo.
5- Considerações sobre o servidor DNS



Separar fisicamente os servidores DNS do servidor externo.
Esconder a versão do BIND utilizada, de modo que se torne muito
mais difícil ao atacante saber o que fazer.
Configurar o servidor para permitir recursividade somente para
estações de seu domínio.
6- Adicionar Criptografia
Utilizar a criptografia no servidor com certeza aumenta a dificuldade, se
não torna impossível, o ataque (dependendo da habilidade do atacante).
Existem algumas soluções sendo que a que possui implementação mais
fácil é a TSIG.
Com a execução dos métodos o servidor DNS se torna mais
protegido, é imprescindível destacar que é impossível proteger 100% um
servidor, em algum momento alguém há de descobrir alguma brecha.
Ataques do Projeto
No ambiente simulado do projeto não se faz necessário a aplicação
de tantos métodos, considerando que há pouco tempo para a realização
de tudo de maneira decente, portanto foi utilizado apenas um método afim
de proteger a tabela ARP do Linux e do Windows, bem como proteger a
tabela CAM do Switch.
No Switch o método utilizado foi o de Sticky Mac Address de modo
que force o switch a identificar como válido apenas o primeiro MAC que
for recebido.
switchport mode access
A porta precisa estar em modo access.
switchport port-security
Ativa o port-security.
switchport port-security mac-address sticky
Define que a porta irá utilizar o sticky mac address.
Há também a possibilidade de configurar quantos endereços
válidos podem estar na porta:
switchport port-security maximum <número de MACs válidos>
Após isso é necessário definir qual a atitude a ser tomada caso
ocorra alguma violação:
switchport port-security violation <protect | restrict | shutdown>

Shutdown: Desabilita a porta e é necessário habilitá-la
manualmente depois.

Protect: Descarta os pacotes com endereços MAC de
origem desconhecidos até que o administrador remova,
manualmente uma quantidade de endereços para que a lista
caia para um número menor do que o número máximo
configurado.

Restrict: Faz o mesmo que o protect mas acrescenta o
contador Security Violation.
Após isso vamos às estações e reforçamos a segurança da tabela
ARP, para isso colocamos o endereço do roteador como estático, de
modo que o atacante não pode alterar o MAC da tabela ARP, para tal
utiliza-se o comando
arp –s gateway mac