iptables no nó de saída tor


9

Eu quero executar um roteador Tor aberto .

Minha política de saída será semelhante a ReducedExitPolicy .

Mas também quero tornar difícil para a rede abusar de meus recursos.

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

  • Martelando um site com muitos pacotes.
  • Redes agressivas de blocos IP inteiros

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

  • fazendo upload de alguns hudreds de arquivos de imagem para a nuvem
  • semeando um torrent

Minha pergunta é: isso pode ser feito e como?

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

Existe algum desenvolvimento contínuo da equipe do projeto 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 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 no 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 originado de muitos clientes para um destino.

Atualização (dez 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 de saída (também conhecido como NOVO):

Não tenho certeza de que 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

Respostas:


2

Tenha em mente que:

  • Os clientes Tor alternam os circuitos virtuais a cada 10 minutos, segundo meu entendimento atual. Isso significa que o IP de origem está mudando nesse período. É improvável que você impeça qualquer comportamento que considere malicioso por mais tempo do que essa duração.

  • Observe que o fato de o Tor proxies apenas o tráfego TCP e nenhum 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 ESTABLISHED,RELATEDdeva ser ACCEPTEDou ser submetida a uma cadeia de "conexões TCP existentes" e o TCP de saída que não for pego por isso podem ter uma taxa limitada. Qualquer tráfego Tor de saída deve estar sujeito a isso.

Acredito que entre o exposto 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 SSH instalado, em uma porta diferente de 22.
  • Você provavelmente desejará executar um servidor da web simples para exibir esta página . Uma mini-httpdinstância chroot'ed deve funcionar. Não use inetd.

Não execute o Tor em uma caixa que esteja sendo usada para qualquer outra coisa. Certifique-se de ler a seção "Relés de saída" das Perguntas frequentes do Tor Legal e entender completamente suas implicações. Leia também e faça tudo isso .


1

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

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

Você pode filtrar:

  • pacotes de impressão digital / digitalização incorretos ou típicos (sinalizadores TCP / IP incorretos, XMAS, a maioria dos tipos de ICMP etc.)
  • Pacotes INVALID que não se ajustam a conexões contínuas ou novas (estado -m)
  • NOVAS conexões começando em um limite bastante alto

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

Além disso, para pacotes NEW (ou sem estado) com limite de taxa, convém considerar um esquema mais envolvido, em que os pacotes rejeitados (nunca DROP, a menos que seja obviamente um ataque!) São 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 poderá contornar seu limite de taxa.

Também pergunte nas listas de discussão do Tor, você provavelmente não é o primeiro a ter essas idéias: https://lists.torproject.org/cgi-bin/mailman/listinfo


1

Primeiramente, eu não sugeriria o iptables para resolver tudo isso, realmente um nó Tor de saída ideal carregaria tráfego balace através de alguns túneis VPN para manter os olhos do ISP longe dos pacotes e do destino verdadeiro e / ou utilizar o proxy de cache para manter solicitações repetidas de saída ao conteúdo estático popular ao mínimo ... enquanto olha para essas opções, aqui está um curativo para os 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/

Combinando os dois links de origem em regras que podem ser usadas para frustrar os bots tentando usar o nó de saída do Tor para a verificação de portas. Observe que isso pode deixar os hackers que usam o nó de saída muito insatisfeitos, pois essas regras causam um tempo de espera no 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

Corra acima bashpara ter magics pré-formados em variáveis ​​com ,cammas ie;

user@host~# bash iptables_limit_tor.sh

Aqui está essa 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 filtrar novas conexões de saída para -m state NEW ! --syntipos de negócios engraçados usados ​​por alguns bots para encontrar servidores exploráveis. Aqui está um exemplo de cadeia que você pode 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 seja 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 falsos positivos quando aplicativos mal codificados no final do cliente se reconectam através de um novo cercut do Tor.

~~~~~

Software a considerar para mais tráfego de modelagem Confira no firejailLinux, a fonte está no Github e no Source forge e as páginas de manual podem ser encontradas na home page antiga, um subdomínio wordpress, e o 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 reduzida. Existem outras ferramentas, como KVMtambém, que podem ser usadas para manter os serviços especiais dentro dos limites operacionais, para que você possa encontrar o que funciona melhor para o seu sistema.

Ainda outra opção seria executar fail2bande tal maneira que quando um administrador de sistema louco tenta uma conexão http ou ssl com o seu IP, uma regra é adicionada para descartar-m state --state NEWconexões com aqueles que solicitam sua página de aviso de saída. Isso, se combinado com limites sãos de proibição de banir, pode permitir uma interrupção 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 do software que você está usando para servir sair das páginas de aviso; dica nginx e apache servirão o primeiro bloco de vhost ou servidor em suas configurações se agora o URL foi solicitado. Se estiver usando algo diferente de apache ou nginx, você desejará 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 fail2ban adicione qualquer IP desse log a uma lista de proibição temporária. ; isso também funciona muito bem para banir bots em servidores públicos, porque eles geralmente usam um endereço IP e não fornecem resultados de solicitação de domínio no servidor servindo a armadilha de bots,

Eu usava twords executando uma política restrita de saída do Tor (parece que você já lidou com isso) e depois direcionava o tráfego através dos túneis da VPN, pontos de crédito extras para o balanceamento de carga entre os túneis de múltiplos polos. Porque isso causaria menos interrupções no tráfego da rede Tor e manteria os olhos do seu ISP nublados pelo fato de você estar executando um nó de saída ... a menos que eles desejem admitir que farejam e decifram seu tráfego VPN. Isso ocorre porque a execução de regras que proíbem temporariamente ou permitem que o host remoto se autopromova pode levar a uma violação da privacidade dos clientes do nó, pois o envio do tráfego para uma VPN (ou poucas) ajudaria a privacidade do cliente e manteria sua privacidade. O provedor de serviços de Internet seja perseguido por solicitações de seus logs de tráfego de rede por qualquer governo com capacidade de execução whois www.some.domain.

~~~~

Edições / Atualizações

~~~~

Fiz uma viagem pelas minhas notas extensivas e puxei as configurações para servidores públicos que eu uso

Aqui está o stansa jail.localfail2ban

[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 <phil@identityvector.com>
# 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 deseja adicionar as -p TCP -m state --state NEWconfigurações a cada linha para ter apenas novas conexões de saída banidas do endereço IP registrado.

Por último, é a configuração de uma configuração do Apache vHost que rouba aqueles que não solicitam um domínio para um log de acesso e erro específico e a configuração do acesso permitido vs negado, para que sempre erros, nem mesmo o loopback possa exibir a página sem exibir erros. . Por último, mas não menos importante, está configurando a página de erro do Apache para o aviso de saída padrão do Tor, para que isso seja exibido em vez de 503ou404mensagens sem graça. Ou, se você adicionou as linhas de estado às ações do iptables para fail2ban, basta apontar para o mesmo arquivo de log usado pelo aviso de saída. O resultado seria que seu servidor não seria capaz de fazer novas conexões com o IP do servidor que verificassem seu endereço IP, mas ainda seriam permitidas conexões estabelecidas e relacionadas, ou seja, elas ainda poderiam navegar em suas outras páginas, mas você não conseguiria navegar através delas. .


Muito bem-vindo, se você gostou, eu acabei de enviar uma grande quantidade de scripts / notas ao GitHub que você pode querer dar uma olhada. Eu iniciei esse projeto em particular há mais de um ano, mas agora que a saúde é um problema, eu o tornei público para depuração e adição de recursos, caso eu não consiga finalizá-lo; que e manter ações tomadas local e globalmente por outras pessoas me incentivaram a tomar uma posição para tornar a privacidade pessoal uma mudança mais fácil.
precisa saber é o seguinte

Escrevi outro projeto e o enviei ao GitHub . Isso visa ajudar os administradores de servidores a proteger os logs de seus servidores usando a criptografia assimétrica do GnuPG. Desde que seu nó de saída ou serviço oculto não mantenha a chave privada relacionada, o projeto acima deve impedir que os logs anteriores vazem os endereços IP de outros nós que se conectam ao seu próprio nó.
S0AndS0

0

A largura de banda limitada do restante da rede Tor resolverá esses problemas para você. Além disso, se você estiver preocupado, execute apenas retransmissão, não um nó de saída.


0

Eu tenho uma solução melhor: servidor de cache squid. Servidor de cache Squid disponível para configurar a definição acle você denyou acceptcada um acl. É muito interessante que a equipe do squid defina um conjunto de regras em seu wiki que sua pergunta encontrada iptables,PF ou outras pessoas não possam fazer seu trabalho, porque apenas trabalhe em outras camadas.


Eu não vejo qualquer maneira sensata de combinar Squid (que eu sei e como) com Tor ...
filiprem

tente com Zebra route.
precisa saber é o seguinte

Você quer dizer redirecionar para o tráfego de saída que vai para a porta 80 e canalizá-lo através do squid para adicionar algum controle? Isso resolve apenas uma pequena parte do problema. A causa real é impedir o abuso do Tor para qualquer DDOS baseado em IP.
Filiprem

Você pode usar o design de sua rede em três camadas: 1. camada externa 2. camada de processo. 3. camada usuário / servidor ====> Isso faz com que sua segurança seja aprimorada.
precisa saber é o seguinte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.