Lidando com SIP DoS/DDoS no Asterisk
Enviado por Charles Alandt (charles·alandtΘgmail·com):
Sintomas foram: – Uso excessivo de banda de internet (100% usado) – Uso excessivo do hardware (100% CPU e 100% Memória) – O ataque era em diferentes horários, randomicos e dias aleatórios. O que dificulta bastante para detectar.
Com estes dois itens, já temos a situação de: – Qualidade da voz estava ruim, mas ruim mesmo. ..
Um simples IPTABLES não resolve o problema pois o ataque utiliza varias formas e portas diferentes. Então num DROP, no ip do iniciador do ataque não resolve. Pois ele troca de IP, e ninguem quer acordar no meio da noite para verificar qual será o novo IP do “nosso amigo”. Precisamos automatizar esta ferramenta.
Depois de ler os pacotes chegando na interface de rede, via tcpdump/wireshark, notei que todos utilizavam a seguinte tag no pacote SIP, User-Agent=friendly-scanner. Agora ficou simples, não ?
A seguinte linha no iptables, resolve: iptables -I INPUT -j DROP -p udp -dport 5060 -m string -string “friendly-scanner” -algo bm
Enquanto não trocarem a tag está tranquilo, mas, podemos pensar em ativar iptables com um ratelimit em conjunto com as tag de pacote INVITE, REGISTER e USER-AGENT. So o iptables com ratelimit não funcionou 100%, pois o ataque troca as portas de forma bem “inteligente”.
Segue links que ajudaram a resolver a situação: [blog.sipvicious.org/…], [jcs.org/…], [wiki.voicenetwork.ca/…].
Se alguem quiser os dump para analise, ainda tenho uma copia é so solicitar via email ou qualquer outra dúvida ou informação, segue meu contato : Charles Josiah Rusch Alandt, charles.alandt(a)gmail.com”
O fail2ban é mais prático porque atua na falha de autenticação, gerando a regra de Iptables necessária. Recomendo-o inclusive para outros serviços como ssh, imap, pop, etc… ;)
Bom dia, o fail2ban foi utilizado não conseguiu detectar.
@Charles: o fail2ban utiliza análise de logs para detectar o problema. Se ele não detectar por padrão, é só fazer a sua regra baseado na falha reportada pelos logs do asterisk (/var/log/asterisk/messages). Pode ser necessário aumentar a verbosidade do log, mas comigo sempre funcionou. ;)
Cara, estava com o verbose e debug no maximo e o fail2ban não detectou.
Eu li o fonte fail2ban e as strings que ele procurava, não estavam nos logs. Tentei escrever as minhas personalizadas, mas sem sucesso tb.Quando com sucesso, gerou muitos falsos-positivos.
Procurei em outros outros sites, mas para este tipo especifico de ataque todos tambem falaram que o fail2ban não funcionava. Se encontrar os links eu posto num comentário para vc apreciarem.
O que fiz para reduzir drasticamente esse tipo de ataque foi bloquear requisições de IPs de fora do Brasil. Não possuo contas sip sendo usadas fora do Brasil. Para quem tem o mesmo cenário, ajuda muito.
Boa noite, sobre blacklist, o pessoal do fail2ban esta trabalhando em manter uma lista, segue link:
http://www.infiltrated.net/blacklisted
t+
Segue comando legal para atualizar a lista e aplicar via iptables:
wget -qO – http://infiltrated.net/blacklisted |awk ‘!/#|[a-z]/&&/./{print “iptables -A INPUT -s ” $1 ” -j DROP” }’ | sh
Acho que a intenção deles não era fazer DoS, mas sim bruteforce para descobrir senhas do seu SIP.
Carlos, concordo contigo, que possa ser um bruteforce tentando um usuário e senha valido para realizar ligações.
Agora, este caso que tive em especifico, era DoS. Segundo foruns, listas de discussão internacional e pela características dos pacotes recebidos.
Mas tanto o bruteforce e Dos, são ataques que dependendo e dependendo da técnica utilizada, podem derrubar ou deixar inacessível links e servidores.