~~~~~

~~~~~

Eu quero abrir umTorroteador.

Minha política de saída será semelhante aPolítica de saída reduzida.

Mas também quero dificultar o abuso dos meus recursos pela rede Tor.

Casos que quero evitar que os clientes façam via Tor:

  • Martelando um site com muitos pacotes.
  • Netscans agressivos de blocos IP inteiros

Casos que NÃO quero impedir que os clientes façam via Tor:

  • enviando algumas centenas de arquivos de imagem para a nuvem
  • semeando um torrent

Minha pergunta é: isso pode ser feito e como?

Meu primeiro pensamento foi algum firewall (Linux/iptables ou *BSD/ipfw/pf) - mas isso provavelmente será inútil devido às propriedades inerentes do roteador Onion.

Existe algum desenvolvimento contínuo da equipe do torproject sobre este tópico?

Também peço dicas gerais sobre como proteger os nós de saída do Tor.

Atualização (setembro de 2012)

A partir de respostas úteis e de algumas outras pesquisas, acho que isso não pode ser feito.

O melhor que você pode fazer para impedir que as pessoas abusem do nó de saída para contribuir com DDOS é detectar pacotes muito frequentes direcionados a um IP.

O limite "muito frequente" depende da largura de banda total do nó... Se estiver errado, haverá falsos positivos, bloqueando o tráfego legítimo de aplicativos TCP em tempo real e o tráfego proveniente de muitos clientes para um destino.

Atualização (dezembro de 2014)

Minhas previsões eram obviamente verdadeiras - recebi várias reclamações de abuso de rede do meu provedor de Internet.

Para evitar o desligamento do serviço, tive que empregar o seguinte conjunto de iptablesregras ( ONEWé uma cadeia para pacotes TCP SYN (também conhecidos como NOVOs):

Não tenho certeza se será suficiente, mas aqui está:

-A ONEW -o lo -j ACCEPT
-A ONEW -p udp --dport 53 -m limit --limit 2/sec --limit-burst 5 -j ACCEPT
-A ONEW -m hashlimit --hashlimit-upto 1/second --hashlimit-mode dstip --hashlimit-dstmask 24 --hashlimit-name ONEW -j ACCEPT
-A ONEW -m limit --limit 1/sec -j LOG --log-prefix "REJECTED: "
-A ONEW -j REJECT --reject-with icmp-admin-prohibited

Responder1

Tenha em mente que:

  • Os clientes Tor trocam de circuitos virtuais a cada 10 minutos ou mais, segundo meu entendimento atual. Isso significa que o IP de origem está mudando nesse período. É improvável que você evite qualquer comportamento que considere malicioso por mais tempo do que esse período.

  • Observe que o fato de o Tor apenas fazer proxy do tráfego TCP e não de qualquer outro protocolo limita bastante as possibilidades de abuso.

iptablespode permitir que você trate novas conexões TCP de saída de maneira diferente das existentes. Qualquer coisa que seja ESTABLISHED,RELATEDdeve ser ACCEPTEDou passar por uma cadeia de "conexões TCP existentes", e o TCP de saída que não for capturado por isso poderá ter taxa limitada. Qualquer tráfego de saída do Tor deve estar sujeito a isso.

Acredito que entre o que foi dito acima e o uso da "Política de Saída Reduzida" seria o melhor que você pode fazer.

Idealmente, não execute mais nada na sua caixa Tor, exceto:

  • Você provavelmente terá pelo menos o SSH ativado, coloque-o em uma porta diferente da 22.
  • Você provavelmente desejará executar um servidor web simples para exibiresta página. Uma mini-httpdinstância com chroot deve servir. Não use inetd.

Não execute o Tor em uma máquina que esteja sendo usada para qualquer outra coisa. Certifique-se de ter lido a seção "Relés de saída" doas Perguntas Frequentes Jurídicas do Tore compreender plenamente as suas implicações. Tambémleia e faça tudo isso.

Responder2

Será mais difícil do que o habitual evitar estes ataques, uma vez que o IP de origem não é constante. No entanto, que eu saiba, as rotas no tor só são alteradas a cada poucos minutos ou mais.

Portanto, você ainda pode implantar algumas das regras padrão de limitação/filtragem, mas com um limite mais alto, pois deve assumir que há uma rede inteira por trás dos seus IPs de origem.

Você pode filtrar:

  • pacotes de impressão digital/digitalização ruins ou típicos (sinalizadores TCP/IP ruins, XMAS, a maioria dos tipos de ICMP, etc.)
  • Pacotes INVÁLIDOS que não cabem em conexões novas ou em andamento (estado -m)
  • NOVAS conexões começando em um limite bastante alto

No entanto, esteja ciente de que essas coisas normalmente são feitas no tráfego de entrada. Você não sabe que tipo de protocolos seus "clientes" executarão e pode restringi-los de maneiras que podem ser irritantes/pouco claras.

Além disso, para pacotes NOVOS (ou sem estado) com limitação de taxa, você pode considerar algum esquema mais complexo, onde os pacotes rejeitados (nunca DROP, a menos que seja obviamente um ataque!) sejam randomizados. Dessa forma, um usuário comum pode apenas tentar recarregar e ter sorte, mesmo que a taxa geral esteja atualmente no limite, enquanto um scanner de porta simultâneo não será capaz de contornar seu limite de taxa.

Pergunte também nas listas de discussão do Tor, você provavelmente não é o primeiro a ter tais pensamentos:https://lists.torproject.org/cgi-bin/mailman/listinfo

Responder3

Em primeiro lugar, eu não sugeriria iptables para resolver tudo isso, realmente um nó Tor de saída ideal carregaria o tráfego de equilíbrio através de alguns túneis VPN para manter os olhos do ISP longe dos pacotes e do verdadeiro destino e/ou utilizar proxy de cache para manter solicitações repetidas de saída para popularestáticoconteúdo ao mínimo... enquanto analisa essas opções, aqui está umAtadurapelos problemas de reclamação de abuso;

Fontes de informação utilizadas

http://www.ossramblings.com/using_iptables_rate_limiting_to_prevent_portscans

http://blog.nintechnet.com/how-to-block-w00tw00t-at-isc-sans-dfind-and-other-web-vulnerability-scanners/

Combinar os dois links de origem em regras que podem ser usadas para frustrar os bots que tentam usar o nó de saída do Tor para verificação de portas. Observe que isso pode deixar os hackers que usam seu nó de saída muito insatisfeitos, pois essas regras causam tempo de espera do nmap.

#!/bin/bash
## Network interface used by Tor exit daemon
_tor_iface="eth1"
## Ports that Tor exit daemon binds to, maybe comma or space sepperated.
_tor_ports="9050,9051"
## Time to ban connections out in secconds, default equates to 10 minutes, same as default Tor cercut.
_ban_time="600"
## How long to monitor conections in seconds, default equates to 10 minutes.
_outgoing_tcp_update_seconds="600"
## How many new connections can be placed to a server in aloted update time limits. May nead to increes this depending on exit node usage and remote servers usages.
_outgoing_tcp_hitcount="8"
## How long to monitor connections for in minuets, default is 15 minutes but could be lessoned.
_outgoing_tcp_burst_minute="15"
## Hom many connections to accept untill un-matched
_outgoing_tcp_burst_limit="1000"

iptables -N out_temp_ban -m comment --comment "Make custom chain for tracking ban time limits" || exit 1
iptables -A out_temp_ban -m recent --set --name temp_tcp_ban -p TCP -j DROP -m comment --comment "Ban any TCP packet coming to this chain" || exit 1

iptables -N out_vuln_scan -m comment --comment "Make custom chain for mitigating port scans originating from ${_tor_iface}" || exit 1
for _tor_port in ${_tor_ports//,/ }; do
    iptables -A out_vuln_scan -p TCP -o ${_tor_iface} --sport ${_tor_port} -m recent --name temp_tcp_ban --update --seconds ${_ban_time} -j DROP -m comment --comment "Update ban time if IP address is found in temp_tcp_ban list" || exit 1
    iptables -A out_vuln_scan -p TCP -o ${_tor_iface} --sport ${_tor_port} -m state --state NEW -m recent --set -m comment --comment "Monitor number of new conncetions to ${_server_iface}" || exit 1
    iptables -A out_vuln_scan -p TCP -o ${_tor_iface} --sport ${_tor_port} -m state --state NEW -m recent --update --seconds 30 --hitcout 10 -j out_temp_ban -m comment --comment "Ban address when to many new connections are attempted on ${_tor_iface}" || exit 1
done
iptables -A out_vuln_scan -j RETURN -m comment --comment "Return un-matched packets for further processing" || exit 1

## Add rules to accept/allow outbound packets
iptables -N tor_out -m comment --comment "Make custom chain for allowing Tor exit node services" || exit 1
for _tor_port in ${_tor_ports//,/ }; do
    iptables -A tor_out -p TCP -o ${_tor_iface} --sport ${_tor_port} -m state --state NEW -m recent --set --name limit_${_tor_port} -m comment --comment "Track out-going tcp connections from port ${_tor_port}" || exit 1
    iptables -A tor_out -p TCP -o ${_tor_iface} --sport ${_tor_port} -m state --state NEW -m recent --update --seconds ${_outgoing_tcp_update_seconds:-60} --hitcount ${_outgoing_tcp_hitcount:-8} --rttl --name limit_${_tor_port} -j LOG --log-prefix "TCP flooding port ${_tor_port}" -m comment --comment "Log atempts to flood port ${_tor_port} from your server" || exit 1
    iptables -A tor_out -p TCP -o ${_tor_iface} --sport ${_tor_port} -m state --state NEW -m recent --update --seconds ${_outgoing_tcp_update_seconds:-60} --hitcount ${_outgoing_tcp_hitcount:-8} --rttl --name limit_${_tor_port} -j DROP -m comment --comment "Drop attempts to flood port ${_tor_port} from your server" || exit 1
    iptables -A tor_out -p TCP -o ${_tor_iface} --sport ${_tor_port} -m limit --limit ${_outgoing_tcp_burst_minute:-15}/minute --limit-burst ${_outgoing_tcp_burst_limit:-1000} -j ACCEPT -m comment --comment "Accept with conditions new connections from port ${_tor_port} from your server" || exit 1
done
iptables -A tor_out -j RETURN -m comment ---comment "Reurn un-matched packets for further filtering or default polices to take effect." || exit 1
## Activate jumps from default output chain to new custom filtering chains
iptables -A OUTPUT -p TCP -o ${_tor_iface} -j out_vuln_scan -m comment --comment "Jump outbound packets through vulnerability scaning mitigation" || exit 1
iptables -A OUTPUT -p TCP -o ${_tor_iface} -j tor_out -m comment --comment "Jump outbound packets through conditional acceptance" || exit 1

Execute acima para bashter mágicas pré-formadas em variáveis ​​com ,cammas, ou seja;

user@host~# bash iptables_limit_tor.sh

Aqui está aquela lista de variáveis ​​novamente

_tor_iface="eth1"
_tor_ports="9050,9051"
_ban_time="600"
_outgoing_tcp_update_seconds="600"
_outgoing_tcp_hitcount="8"
_outgoing_tcp_burst_minute="15"
_outgoing_tcp_burst_limit="1000"

Observe que você também pode querer filtrar novas conexões de saída para -m state NEW ! --syntipos deengraçadonegócio usado por alguns bots para encontrar servidores exploráveis ​​aqui está um exemplo de cadeia que você poderia ter como prefixo dos dois acima para filtrar ainda mais essas conversas malformadas

iptables -N out_bad_packets -m comment --comment "Make new chain for filtering malformed packets" || exit 1
iptables -A out_bad_packets -p TCP --fragment -j out_temp_ban -m comment --comment "Drop all fragmented packets" || exit 1
iptables -A out_bad_packets -p TCP -m state --state INVALID -j out_temp_ban -m comment --comment "Drop all invalid packets" || exit 1
iptables -A out_bad_packets -p TCP ! --syn -m state --state NEW -j out_temp_ban -m comment --comment "Drop new non-syn packets" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL NONE -j out_temp_ban -m comment --comment "Drop NULL scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL ALL -j out_temp_ban -m comment --comment "Drop XMAS scan"|| exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL FIN,URG,PSH -j out_temp_ban -m comment --comment "Drop stealth scan 1" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL SYN,RST,ACK,FIN,URG -j out_temp_ban -m comment --comment "Drop pscan 1"|| exit 1
iptables -A out_bad_packets -p TCP --tcp-flags SYN,FIN SYN,FIN -j out_temp_ban -m comment --comment "Drop pscan 2" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags FIN,RST FIN,RST -j out_temp_ban -m comment --comment "Drop pscan 3" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags SYN,RST SYN,RST -j out_temp_ban -m comment --comment "Drop SYN-RST scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ACK,URG URG -j out_temp_ban -m comment --comment "Drop URG scans" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL SYN,FIN -j out_temp_ban -m comment --comment "Drop SYNFIN scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL URG,PSH,FIN -j out_temp_ban -m comment --comment "Drop nmap Xmas scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL FIN -j out_temp_ban -m comment --comment "Drop FIN scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL URG,PSH,SYN,FIN -j out_temp_ban -m comment --comment "Drop nmap-id scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags RST RST -o ${_tor_iface} --sport ${_tor_port} -m limit --limit 2/second --limit-burst 3 -j out_temp_ban -m comment --comment "Mitigate Smurf attacks from excesive RST packets"
iptables -A out_bad_packets -p TCP --tcp-flags RST RST -o ${_tor_iface} --sport ${_tor_port} -m limit --limit 2/second --limit-burst 2 -j RETURN -m comment --comment "Ban Smurf attacks using excesive RST packets"
iptables -A out_bad_packets -j RETURN -m comment --comment "Return un-matched packets for further processing." || exit 1

No entanto, a cadeia acima seria muito restritiva, pois qualquer pacote correspondente terá o IP banido (talvez alterado -j out_temp_banpara -j DROPou -j REJECTpara teste) por quantos segundos forem escolhidos nas regras dessa cadeia. Esse conjunto de regras também pode causar falhas positivas quando aplicativos mal codificados no final do cliente se reconectam por meio de um novo cercut do Tor.

~~~~~

Software a ser considerado para moldar ainda mais o tráfego Confira firejailo Linux, a fonte está no Github e Source forge e as páginas de manual podem ser encontradas na página inicial antiga, um subdomínio do wordpress, e a DigitalOcean tem um guia para Nginx com PHP e Firejail que com uma pequena modificação, você poderá obter muito mais informações sobre onde a rede deve ser restringida. Existem outras ferramentas KVMque podem ser usadas para manter serviços específicos dentro dos limites operacionais, para quecomprardisponível para encontrar aquele que funciona melhor para o seu sistema.

Outra opção seria executar fail2bande forma que, quando um administrador de sistema maluco tentasse uma conexão http ou SSL com o seu IP, uma regra fosse adicionada para descartar -m state --state NEWconexões para aqueles que solicitam sua página de aviso de saída. Isso, se combinado com limites de tempo sensatos para não banir, pode permitir uma pausa no servidor remoto enquanto o administrador do sistema murmura sobre a poluição do log ;-) No entanto, isso está além do escopo desta resposta atual e depende de qual software você está usando para servir páginas de aviso de saída; dica que tanto o nginx quanto o apache servirão o primeiro vhost ou bloco de servidor em suas configurações se agora o URL for solicitado. Se estiver usando algo diferente de apache ou nginx, você vai querer consultar as páginas de manual, mas para mim foi tão simples quanto configurar o primeiro vhost para registrar em um arquivo diferente e fazer com que o fail2ban adicione quaisquer IPs desse log a uma lista de banimento temporário ; isso também funciona muito bem para banir bots em servidores públicos porque eles geralmente usam um endereço IP e não fornecer uma solicitação de domínio resulta no servidor servindo a armadilha de bot ou, neste caso, um aviso de saída.

Eu preferiria executar uma política de saída Tor restrita (parece que você já resolveu isso) e, em seguida, enviar o tráfego através de túneis VPN, pontos de crédito extras para balanceamento de carga entre vários túneis. Porque isso causaria menos interrupções no tráfego da rede Tor e manteria os olhos do seu ISP turvos para o fato de que você está executando um nó de saída... a menos que eles desejem admitir que farejaram e quebraram seu tráfego VPN. Isso ocorre porque a execução de regras que proíbem temporariamente ou permitem o autobanimento do host remoto pode levar a uma violação de privacidade dos clientes do seu nó, onde enviar o tráfego para uma VPN (ou algumas) ajudaria a privacidade do seu cliente e manteria seu ISP de ser perseguido comsolicitações depara seus registros de tráfego de rede por qualquer governo capaz de executar whois www.some.domain.

~~~~

Edições/atualizações

~~~~

Dei uma olhada em minhas extensas anotações e acessei as configurações dos servidores públicos que uso

Aqui está a jail.localversão do fail2ban

[apache-ipscan]
enabled  = true
port = http,https
filter = apache-ipscan
logpath = /var/log/apache*/*error_ip*
action = iptables-repeater[name=ipscan]
maxretry = 1

E aqui está o apache-ipscan.confarquivo de filtro

[DEFAULT]
_apache_error_msg = \[[^]]*\] \[\S*:error\] \[pid \d+\] \[client <HOST>(:\d{1,5})?\]
[Definition]
failregex = \[client <HOST>\] client denied by server .*(?i)/.*
#^<HOST>.*GET*.*(?!)/.*
#   ^%(_apache_error_msg)s (AH0\d+: )?client denied by server configuration: (uri )?.*$
#            ^%(_apache_error_msg)s script '\S+' not found or unable to stat(, referer: \S+)?\s*$
ignoreregex = 
# DEV Notes: 
# the web server only responds to clients with a valid Host: 
# header. anyone who tries using IP only will get shunted into 
# the dummy-error.log and get a client-denied message
#
# the second regex catches folks with otherwise valid CGI paths but no good Host: header
#
# Author: Paul Heinlein

E aqui está o iptables-repeater.confarquivo de ação

# Fail2Ban configuration file
#
# Author: Phil Hagen <[email protected]>
# Author: Cyril Jaquier
# Modified by Yaroslav Halchenko for multiport banning and Lukas Camenzind for persistent banning
# Modified by S0AndS0 to combine features of previous Authors and Modders
#
[Definition]
# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#
actionstart = iptables -N fail2ban-BADIPS-<name>
              iptables -A fail2ban-BADIPS-<name> -j RETURN
          iptables -I INPUT -j fail2ban-BADIPS-<name>
          ## Comment above line and uncomment bello line to use multiport and protocol in addition to named jails
          #iptables -I INPUT -p <protocol> -m multiport --dports <port> -j fail2ban-BADIPS-<name>
          # set up from the static file
          #cat /etc/fail2ban/ip.blocklist.<name> |grep -v ^\s*#|awk '{print $1}' | while read IP; do iptables -I fail2ban-BADIPS-<name> 1 -s $IP -j DROP; done
          cat /etc/fail2ban/ip.blocklist.<name> |grep -v ^\s*#|awk '{print $1}' | while read IP; do iptables -I fail2ban-BADIPS-<name> 1 -d $IP -j DROP; done
          ## Comment above line and uncomment bellow line to check if there are blacklist files to load before attempting to load them
          # if [ -f /etc/fail2ban/ip.blacklist.<name> ]; then cat /etc/fail2ban/ip.blacklist.<name> | grep -e <name>$ | cut -d "," -s -f 1 | while read IP; do iptables -I fail2ban-BADIPS-<name> 1 -s $IP -j DROP; done; fi
# Option:  actionstop
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
#
actionstop = iptables -D INPUT -p <protocol> -m multiport --dports <port> -j fail2ban-BADIPS-<name>
         iptables -F fail2ban-BADIPS-<name> 
         iptables -X fail2ban-BADIPS-<name>
# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
#actioncheck = iptables -n -L INPUT | grep -q fail2ban-BADIPS-<name>
actioncheck = iptables -n -L OUTPUT | grep -q fail2ban-BADIPS-<name>
# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
#
#actionban = if ! iptables -C fail2ban-BADIPS-<name> -s <ip> -j DROP; then iptables -I fail2ban-BADIPS-<name> 1 -s <ip> -j DROP; fi
actionban = if ! iptables -C fail2ban-BADIPS-<name> -d <ip> -j DROP; then iptables -I fail2ban-BADIPS-<name> 1 -d <ip> -j DROP; fi
# Add offenders to local blacklist, if not already there
        if ! grep -Fxq '<ip>,<name>' /etc/fail2ban/ip.blocklist.<name>; then echo "<ip>,<name> # fail2ban/$( date '+%%Y-%%m-%%d %%T' ): auto-add for BadIP offender" >> /etc/fail2ban/ip.blocklist.<name>; fi
# Report offenders to badips.com
#        wget -q -O /dev/null www.badips.com/add/<name>/<ip>
# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
#
#actionunban = iptables -D fail2ban-REPEAT-<name> -s <ip> -j DROP
actionunban = iptables -D fail2ban-REPEAT-<name> -d <ip> -j DROP
# Disabled clearing out entry from ip.blacklist (somehow happens after each stop of fail2ban)
#sed --in-place '/<ip>,<name>/d' /etc/fail2ban/ip.blacklist.<name>
[Init]
# Defaut name of the chain
# 
# Defaut name of the chain
name = BADIPS
# Option:  port
# Notes.:  specifies port to monitor
# Values:  [ NUM | STRING ]  Default:
# 
#port = ssh
# Option:  protocol
# Notes.:  internally used by config reader for interpolations.
# Values:  [ tcp | udp | icmp | all ] Default: tcp

Observe que o filtro acima foi editado para bloquear OUTPUTas ações de início/parada, mas você ainda desejará adicionar as -p TCP -m state --state NEWconfigurações a cada linha para que apenas novas conexões de saída sejam banidas do endereço IP registrado.

Por último, é configurar uma configuração do Apache vHost que encaminha aqueles que não solicitam um domínio para um acesso específico e log de erros e definir o acesso permitido ou negado de forma que sempre haja erros, nem mesmo o loopback seja capaz de puxar a página sem aparecer erros . Por último, mas não menos importante, está a configuração da página de erro do Apache para o aviso de saída padrão do Tor, para que seja veiculado em vez de 503mensagens 404insípidas. Ou se você adicionou as linhas de estado às ações do iptables para fail2ban, você pode facilmente apontar para o mesmo arquivo de log usado pelo seu aviso de saída. O resultado seria que o seu servidor não seria capaz de fazer novas conexões com o IP do servidor que verificou o seu endereço IP, mas as conexões estabelecidas e relacionadas ainda seriam permitidas, ou seja, eles ainda poderiam navegar em suas outras páginas, mas você não poderia navegar por elas. .

Responder4

Eu tenho uma solução melhor: servidor de cache squid. Servidor de cache Squid disponível para configurar acle definir você denyou acceptcada um acl. É muito interessante que a equipe do squid defina um conjunto de regras em seu wiki que sua pergunta encontrou iptables,PFou outros não conseguem fazer seu trabalho, pois apenas trabalham em outras camadas.

informação relacionada