De acordo com as Leis 12.965/2014 e 13.709/2018, que regulam o uso da Internet e o tratamento de dados pessoais no Brasil, ao me inscrever na newsletter do portal DICAS-L, autorizo o envio de notificações por e-mail ou outros meios e declaro estar ciente e concordar com seus Termos de Uso e Política de Privacidade.
Colaboração: Alexandro Silva
A rede TOR foi originalmente desenvolvida por pesquisadores da US Naval Research Laboratory e atualmente mantida pelo Electronic Frontier Foundation (EFF)[1], ela foi criada com o objetivo de ser uma rede destinada a prover comunicação anônima com a finalidade de proteger a privacidade dos usuários.
Entretanto, a rede TOR tem sido utilizada por atores maliciosos como vetor para diversos tipos de ataque[2] como:
Segundo a Cloudflare[6], 94% das requisições originadas dos exits nodes da rede TOR podem ser classificadas como maliciosas.
Os exit nodes da rede TOR são gateways de onde saem o tráfego para Internet, a arquitetura da rede dificulta a identificação de onde o tráfego foi originado. Vale resaltar que o tráfego de saída dos exit nodes não é encriptado, possibilitando a identificação ou captura de informações.
Fonte: SecurityFairs
O gráfico abaixo apresenta a localização geográfica dos exit nodes conforme dados apresentados pela Hacker Target.
Fonte: HackerTarget
O grande desafio é, como bloquear requisições originadas da rede TOR sem recursos para investir em serviços pagos como Cloudflare e segurança de borda NextGeneration?
Pense no cenário onde você tem um servidor hospendando uma aplicação exposta para Internet sem Web Application Firewall e apenas com os recursos do sistema operacional, esse cenário se torna bastante desafiador para mitigar requisições maliciosas originadas de redes tão complexas e dinâmicas como a rede TOR.
Com base neste cenário, realizei testes com o objetivo de identificar e bloquear requisições originadas de exit nodes usando apenas os recursos disponibilizados pelo sistema operacional Linux e serviços existentes.
Utilizarei a lista disponibilizada pelo site TORList como fonte para obter os IPs dos exit nodes, essa lista é atualizada a cada 30 min.
Neste primeiro teste obtive a lista dos IPs filtrando apenas os IPv4 e
criando regras de bloqueio na chain TOR_NODE
do Iptables. Para isso criei
um script que será executado a cada 40 min. Como referência usei um script
disponibilizado no site Security Online[7] adequando à minha necessidade.
#!/bin/bash RULE="DROP" CHAIN="TOR_NODE CMD=$(cat /home/jdoe/Reseach/TorBlock/full.tor | uniq | sort) if ! iptables -L TOR_NODE -n >/dev/null 2>&1 ; then iptables -N TOR_NODE >/dev/null 2>&1 iptables -A INPUT -p tcp -j TOR_NODE 2>&1 fi cd /home/jdoe/Research/TorBlock touch /home/jdoe/Research/TorBlock/full.tor wget -q -O - https://www.dan.me.uk/torlist/ > /home/jdoe/Research/TorBlock/full.tor sed -e '/^#/d' -e '/:/d' /home/jdoe/Research/TorBlock/full.tor iptables -F TOR $CMD for IP in $CMD; do let COUNT=COUNT+1 iptables -A TOR -s $IP -j DROP done
Saída do iptables
após a execução do script:
jdoe@ninahartley:~$ sudo iptables -L --line-numbers -n
Chain INPUT (policy DROP)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
3 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
4 TOR_NODE tcp -- 0.0.0.0/0 0.0.0.0/0
Chain TOR_NODE (1 references)
num target prot opt source destination
1 DROP all -- 100.12.87.114 0.0.0.0/0
2 DROP all -- 100.14.174.187 0.0.0.0/0
3 DROP all -- 100.34.61.24 0.0.0.0/0
4 DROP all -- 100.40.215.157 0.0.0.0/0
...
6400
Essa solução funciona, entretanto foram criadas 6400 (seis mil e quatrocentas)
regras de bloqueio na chain TOR_NODE
, isso pode impactar na performance do
servidor pois elas ficam armazenadas em memória.
O ipset
é um framework que atua em conjunto com o iptables
para a criação
e manutenção de listas de IPs, MACs e portas TCP/UDP.
Neste teste segui o mesmo príncipio da solução 1, só que utilizando o ipset
para auxiliar no amazenamento dos IPs.
#!/bin/bash URL="https://www.dan.me.uk/torlist/" CMD=$(cat /home/jdoe/Research/TorBlock/full.tor | uniq | sort) ipset create tor-nodes iphash touch /home/jdoe/Research/TorBlock/full.tor wget -q -O - https://www.dan.me.uk/torlist/ > /home/jdoe/Research/TorBlock/full.tor sed -e '/^#/d' -e '/:/d' /home/jdoe/Research/TorBlock/full.tor for IP in $CMD; do let COUNT=COUNT+1 ipset -q -A tor-nodes $IP iptables -A INPUT -m set --match-set tor-nodes src -j DROP done
Essa abordagem é bacana porém não funcionou corretamente comigo, mesmo com a regra criada foi possível acessar a aplicação via TOR. Entendo que posso ter errado na lógica =(, só que mesmo após vários testes os resultados não foram 100% efetivos.
É possível realizar o bloqueio diretamente no servidor Web Apache ou Nginx. Uma arqutetura interessante é por o Nginx como proxy reverso antes da aplicação, dessa forma a requisição não chegará ao backend reduzindo o consumo de recursos.
Para manter a lista atualizada crei um script que será executado a cada 40 min.
#!/bin/bash TMP=/tmp/torip.conf FINAL=/home/jdoe/Research/torip.conf URL=https://www.dan.me.uk/torlist/ curl $URL -o $TMP sed 's/^/Require not ip /' $TMP > $FINAL
#!/bin/bash TMP=/tmp/torip.conf FINAL=/home/jdoe/Research/torip.conf URL=https://www.dan.me.uk/torlist/ curl $URL -o $TMP sed -e 's/^/deny /' -e 's/$/;/' $TMP > $FINAL #No Nginx o serviço precisa ser recarregado a cada atualização systemctl reload nginx
No Apache, adicionei a seguinte entrada no arquivo apache2.conf
(Debian)
ou httpd.conf
(RedHat/CentOS)
<Location /> < RequireAll> Require all granted Include /home/jdoe/Reseach/torip.conf </RequireAll> </Location>
No Nginx adicionei os seguintes parâmetros no arquivo nginx.conf
include /home/jdoe/Reseach/torip.conf; location / { include /home/jdoe/Reseach/torip.conf; }
Bloqueio em funcionamento
Dentre as soluções testadas, o uso do Apache ou Nginx se mostrou o mais elegante entre as outras opções testadas.
Implementei em produção e está funcionando perfeitamente =).
[1] https://www.torproject.org/about/history/
[2] https://github.com/Attacks-on-Tor/Attacks-on-Tor
[3] https://www.securityweek.com/onionduke-apt-malware-distributed-malicious-tor-exit-node
[4] https://www.securityweek.com/new-lusypos-malware-uses-tor-cc-communications
[5] https://threatpost.com/shedding-new-light-on-tor-based-malware/104651/
[6] https://blog.cloudflare.com/the-trouble-with-tor/
[7] https://securityonline.info/block-tor-client-iptablesiptables-tor-transparent-proxy/
https://www.cisa.gov/uscert/ncas/alerts/aa20-183a
Alexandro Silva a.k.a. Alexos atua há mais de 10 anos como especialista em segurança de redes e sistemas Unix/Linux. Atualmente é líder do Blue Team em uma grande fintech e professor em cursos de graduação e pós-graduação, possui artigos publicados na BSDMag e H2HC Magazine, além de ser co-fundador da Nullbyte Security Conference e palestrante em eventos como Latinoware, FISL, BSidesSP, BHack, Vale Security Conference. (https://alexos.org)
This policy contains information about your privacy. By posting, you are declaring that you understand this policy:
This policy is subject to change at any time and without notice.
These terms and conditions contain rules about posting comments. By submitting a comment, you are declaring that you agree with these rules:
Failure to comply with these rules may result in being banned from submitting further comments.
These terms and conditions are subject to change at any time and without notice.
Comentários