Portas de Amplificação DDoS e Botnets

Introdução

Para contextualizar nosso artigo precisamos entender basicamente que: amplificação é quando perguntamos algo para algum serviço (porta) e a resposta retornada, é maior que o tamanho da pergunta. Tendo isso em mente, existem alguns serviços abertos na Internet com essa característica e são explorados para realizarem o que conhecemos como Ataques de DDoS (Distributed Denial of Service). Sabem aqueles ataques que costumam derrubar nossa Operação de Internet, causando indisponibilidade de acesso para nossos assinantes? São esses serviços mal configurados e abertos na Internet, que munem fortemente os cibercriminosos, que usam esses serviços abertos como ferramentas para esse propósito. Não se engane se você acha que na sua Rede, não possa existir esses serviços abertos e que ninguém estaria usando-os para executar esses ataques. Estamos acostumados a sempre reclamar de ataques recebidos, mas você já parou para pensar que você pode estar sendo usado como vetor de ataque e com isso, inconscientemente, atacando alguém na Internet? Tirando o fato da imperícia de quem configurou erradamente o serviço, deixando-o vulnerável, exposto e suscetível a ser explorado, essa pessoa é tanto vítima quanto você.

Consequências

Quando somos usados como vetor de ataque, nossa Rede se torna instável, nossos clientes reclamam de lentidão no acesso à Internet, nosso Call Center fica atarefado com solicitações que provavelmente eles não conseguirão identificar a causa raiz do problema. Como resultado teremos um aumento da insatisfação dos nossos clientes e muitos cancelamentos (churn). Para evitarmos todos esses males, resolvi escrever esse artigo dando dicas e explicando maneiras de fixarmos esses problemas.

Quanto às Botnets, existem sistemas que foram comprometidos e podem estar sendo explorados para alguma atividade ilícita e que também poderá prejudicar a sua Operação de Internet. Esses casos também precisam ser tratados.

Portas de Amplificação e de Botnets mais conhecidas

Porta	Descrição
DNS (53/udp)	Servidores de DNS Recursivos abertos para o mundo. Não podemos confundir com o serviço de DNS Autoritativo (53/UDP/TCP), este precisa estar aberto à consultas dos domínios de sua autoridade.
SNMP (161/udp)	Simple Network Management Protocol ou como costumo brincar dizendo que o significado seria: Security is Not My Problem. Este serviço é muito usado para monitorarmos nossos ativos de Redes e Servidores.
NTP (123/udp)	Network Time Protocol é um serviço bastante importante para mantermos nossos sistemas com data e hora corretos.
SSDP (1900/udp)	Simple Service Discovery Protocol.
PORTMAP (111/udp)	Daemon que atribui portas dinamicamente para serviços RPC (Remote Procedure Call) como NIS (Network Information Service) e o NFS (Network File System) comumente usados em sistemas Unix Like.
NETBIOS (137/udp)	Network Basic Input/Output System, faz parte dos serviços de compartilhamento de Redes baseadas em Microsoft Windows.
UBNT (10001/udp)	Serviço de Device Discovery habilitado nos equipamentos da Ubiquiti.
MDNS (5353/udp)	Multicast DNS.
LDAP (389/udp)	Serviço Lightweight Directory Access Protocol.
CHARGEN (19/udp)	Character Generator Protocol, é um protocolo usado para fins de teste, depuração e medição. Esse serviço gera datagramas contendo um número aleatório de caracteres entre 0 e 252, sempre que requisitado.
QOTD (17/udp)	Quote Of The Day outro serviço de teste e medição.
MEMCACHED (11211/udp)	Serviço de cache para aceleração de aplicativos Web.
WS-DISCOVERY (3702/udp)	Web Services Dynamic Discovery Protocol, é um protocolo de descoberta multicast para localizar serviços em uma Rede local.
TFTP (69/udp)	Trivial File Transfer Protocol, é um protocolo bastante utilizado por ativos de redes para por exemplo, transferir uma atualização de firmware.
CoAP (5683/udp)	Constrained Application Protocol, é um protocolo de comunicação usado por dispositivos de Internet que possuem pouco recurso de hardware.
SLP (427/udp)	Service Location Protocol, é um protocolo que permite computadores e outros dispositivos encontrarem serviços em uma rede local sem a necessidade de configuração prévia.
ARMS (3283/udp)	Apple Remote Management Service, serviço utilizado pela Apple para prover acesso remoto e gerenciamento de dispositivos rodando MacOS.
DHCPDiscover (37810/udp)	Dynamic Host Configuration Protocol Discover, protocolo utilizado para gerenciar equipamentos DVR.
MT4145 (4145/tcp)	Serviço de SOCKS habilitado na porta 4145/tcp, normalmente visto em equipamentos Mikrotiks comprometidos e abusados por Botnet.
MT5678 (5678/tcp)	Serviço de SOCKS4 habilitado na porta 5678/tcp, visto em Mikrotiks comprometidos e sendo abusados pela Meris Botnet .

Como saber se temos Portas de Amplificação DDoS e de Botnets em nossa Rede?

Primeiramente saiba que existem entidades que se preocupam com a segurança da Internet e que tem como objetivo extinguir a exposição desses serviços de amplificação da Internet. Uma entidade que podemos citar é o ShadowServer e a outra já conhecemos muito bem, que é o nosso valoroso CERT.br. Uma maneira bem fácil e simples de sermos reportados sobre esses problemas de segurança, é mantendo nosso Contato de Segurança atualizado no Registro.br. Mostrarei abaixo em telas de exemplo o quanto isso é fácil. Você precisará de ter a credencial de acesso do seu ASN no Registro.br e já ter criado um ID com seus dados e e-mail, que será usado pelo CERT.br para enviar as notificações de incidentes.

O que vem depois

Após acertar seu contato de segurança, você começará a receber e-mails do CERT.br e de outros ASNs sempre que houver algum incidente de segurança envolvendo o seu ASN e notificações sobre as portas de amplificação/botnets, abertas em sua Rede, inclusive com cada e-mail referente a qual porta está aberta, com o esclarecimento técnico sobre os riscos e instruções de como testar e checar se o problema foi resolvido. Perceba que agora você não estará mais cego quanto aos problemas de segurança que sua Rede vem sofrendo e tenha certeza de que quanto mais limpa ela estiver, mais qualidade de serviço estará entregando ao seu cliente, diminuindo a quantidade de chamados em seu Call Center e consequentemente diminuindo seu churn.

Um exemplo de e-mail que você receberá para cada serviço aberto:

Até aqui te expliquei sobre o problema, o que ele pode causar ao seu negócio e te mostrei como passar a enxergá-los. Mas como tratá-los?

Tratando a causa raiz

Como alguns devem ter percebido, nessa nossa relação de portas de amplificação existem portas que se forem bloqueadas te causarão dor de cabeça e muitas reclamações. Vou citar apenas como exemplo: DNS, SNMP e NTP. Três serviços que se você não tiver cuidado, poderá impactar seus assinantes. Temos que entender que podemos ter 2 tipos de clientes: o residencial e o corporativo. O cliente residencial é mais simples de se resolver porque provavelmente ele não terá um servidor DNS rodando em sua residência, nem um SNMP e tão pouco um servidor NTP, porém o serviço de NTP não pode simplesmente ser bloqueado devido sua natureza de funcionamento e necessidade dos dispositivos, na residência, de manterem-se com a data e horário corretos.

Já o cliente corporativo pode possuir todos esses serviços rodando e nesse caso faz-se necessário um maior entendimento junto ao cliente. O que quero dizer com isso é que para ambos os casos, você precisa elaborar um Plano de Ação para tratar cada caso, buscando sempre o resultado mais eficaz e sem causar indisponibilidade para seu cliente. O que vou propor nesse artigo são duas das formas de se tratar o problema, mas precisamos ter bom senso na hora da decisão e termos certeza de como implementar a solução tecnicamente.

A informação contendo os IPs da nossa Rede que estão com as Portas de Amplificação abertas já temos em mãos, agora precisamos tratá-la. Tenho 2 propostas em mente:

• Identificar os clientes com as falhas de segurança e contatá-los um a um, explicar sobre o problema, o que isso pode afetá-los e ajudá-los a resolver a situação. Essa seria a maneira mais correta, uma boa prática, porque implica em melhorar a cultura de segurança, fazendo todos entenderem sobre os riscos envolvidos e aumentando o senso de cuidado. Em contra partida é uma ação muito trabalhosa e dependendo da quantidade de clientes pode ser muito demorada.
• Aplicar filtros e controles de acordo com o perfil do cliente. Para se ter um resultado mais rápido e efetivo podemos aplicar filtros em nossos BNGs, bloqueando as Portas de Amplificação sempre no sentido Internet para o cliente, mas com alguns cuidados que citarei ainda. Observando sempre os casos de clientes corporativos e que podem necessitar de um tratamento separado.

Estratégia de bloqueio das Portas de Amplificação/Botnet

Faremos o bloqueio de todas as Portas de Amplificação citadas na tabela desse artigo, sempre no sentido Internet para o cliente. Isso é muito importante! O serviço NTP terá um tratamento diferenciado porque não podemos apenas bloquear o serviço, precisaremos fazer um rate-limit e uma condição especial para que seja feito o drop dos pacotes. Como a quantidade de vendors é grande e cada Provedor escolhe o melhor para a sua Operação, trouxe aqui como exemplo regras para Mikrotik RouterOS, basta entender a lógica como vou explicar e procurar fazer o mesmo em seu equipamento, seja de qual fabricante for. Escolhi este vendor como exemplo pois além de ser muito utilizado no mercado, devido ao seu custo x benefício, será mais fácil de explicar o funcionamento. Entendendo como funciona, você pode implementar no seu Cisco, Huawei, Juniper, etc.

As regras de bloqueio no RouterOS

/ip firewall raw
add action=drop chain=prerouting comment="# BLOQUEIA NTP DE ORIGEM NAO NTP" dst-port=123 in-interface=!all-ppp protocol=udp src-port=!123
add action=drop chain=prerouting comment="# DROP ABUSO NTP" limit=!2M,2M:bit protocol=udp src-port=123
add action=drop chain=prerouting comment="# DROP PORTAS UDP DE AMPLIFICACAO" dst-port=53,161,1900,111,137,10001,5353,389 in-interface=!all-ppp protocol=udp
add action=drop chain=prerouting comment="# DROP PORTAS UDP DE AMPLIFICACAO" dst-port=19,17,11211,3702,69,5683,3283,37810 in-interface=!all-ppp protocol=udp
add action=drop chain=prerouting comment="# DROP PORTAS TCP BOTNET" dst-port=4145,5678 in-interface=!all-ppp protocol=tcp tcp-flags=syn

Estamos fazendo os bloqueios na tabela raw por ocupar menos processamento do sistema e sabemos o quanto isso é importante no RouterOS. Essas regras estão sendo aplicadas em um BNG concentrador PPPoE onde:

• Na primeira linha ADD estamos bloqueando qualquer pacote entrando por qualquer interface que não seja PPP, ou seja, que viria da Internet sentido o cliente, que está atrás de uma interface do tipo PPP. Ainda analisando esse filtro, somente entraria nessa regra se a porta origem do pacote não for a 123/udp e com destino a porta 123/udp. Temos que concordar que se um dispositivo do cliente solicitar um sincronismo com algum servidor NTP na Internet, este responderá através da porta 123/udp. Não deve chegar para o cliente uma resposta com origem diferente da porta 123/udp. Por que isso? Algumas implementações do serviço NTP disparam requisições com porta origem 123 ao invés de uma porta origem >= 1024.
• Na segunda linha ADD estamos fazendo um rate-limit de até 2Mbps para qualquer pacote com a porta origem 123/udp e para qualquer destino. Para evitar que a exploração da vulnerabilidade do serviço cause excesso de tráfego na conexão.
• A terceira linha ADD bloqueamos o restante das portas udp de amplificação mas com a seguinte condição: pacotes que entrem por qualquer interface que não seja PPP, novamente definindo o sentido Internet para o cliente e que as portas de destino sejam a nossa lista restante de portas de amplificação.
• Por último no quarto ADD, bloqueamos as portas TCP de Botnet 4145 e 5678, de pacotes que entrem por qualquer interface que não seja do tipo PPP, com destino elas mas com uma condição do pacote estar setado com a tcp flag SYN, que indica um pedido de início de conexão. Se tem alguém na Internet tentando se conectar nessas portas TCP e o sistema por trás for um RouterOS, algo não está bem.

Checando se o problema foi resolvido

Após aplicarmos os filtros, checaremos se os IPs estão com as portas de amplificação fechadas e para isso fiz um shell script em bash, que usa alguns pacotes para validarmos o serviço. Como sempre estou usando para os nossos artigos a distribuição Debian GNU/Linux. Procure separar um ambiente para instalar esses pacotes e servir como base de testes. O ideal é que esteja de fora na Internet e sem qualquer bloqueio de Operadoras para esses testes poderem funcionar. Para usar o rpcinfo precisaremos do pacote rpcbind instalado, que após a instalação levantará o serviço rpc (111/udp) e na sequência iremos desabilitá-lo.

# apt install nmap bind9-host bind9-dnsutils bsdextrautils netcat snmp samba-common-bin rpcbind ntp ldap-utils curl

# systemctl stop rpcbind.service
# systemctl stop rpcbind.socket
# systemctl disable rpcbind.service
# systemctl disable rpcbind.socket

O script dei o nome de amplicacao.sh mas fica ao seu critério chamá-lo como quiser. Ele se encontra aqui no Github: https://github.com/gondimcodes/amplificacao

Para usar é bem simples. No exemplo abaixo fiz um cheque no 8.8.8.8:

Se você quiser checar apenas um serviço se está aberto, podemos fornecer após o IP, o nome do serviço queremos testar seguindo essa lista de opções:

• netbios
• rpc
• arms
• tftp
• dns
• mdns
• ssdp
• snmp
• ntp
• ldap
• ubnt
• chargen
• qotd
• memcached
• ws-discovery
• coap
• mt4145
• mt5678
• dhcpdiscover

Para fazer o teste de apenas um serviço, só observar o exemplo abaixo:

Conclusão

Agora que sabemos o que são as Portas de Amplificação DDoS, os riscos para a nossa Operação de Internet, sabemos como ter visibilidade do problema e como checar e tratar esse problema; você ainda vai continuar deixando isso te afetar ou vamos dar aquele UP! na sua Operação e entregar mais qualidade de serviço para seus assinantes?

Autor: Marcelo Gondim