iptables sur le nœud de sortie tor

9

Je veux exécuter un routeur Tor ouvert .

Ma politique de sortie sera similaire à ReducedExitPolicy .

Mais je veux aussi empêcher le réseau tor d'abuser de mes ressources.

Cas que je veux empêcher les clients de faire via Tor:

  • Marteler un site avec de très nombreux paquets.
  • NetScans agressifs de blocs IP entiers

Cas que je ne veux PAS empêcher les clients de faire via Tor:

  • téléchargement de quelques centaines de fichiers image dans le cloud
  • ensemencer un torrent

Ma question est la suivante: cela peut-il être fait du tout et comment?

Ma première pensée a été un pare-feu (Linux / iptables ou * BSD / ipfw / pf) - mais cela sera probablement inutile en raison des propriétés inhérentes du routeur Onion.

Y a-t-il un développement d'équipe de projet en cours sur ce sujet?

Je demande également des conseils généraux sur la sécurisation des nœuds de sortie Tor.

Mise à jour (sept. 2012)

D'après des réponses utiles et d'autres recherches, je pense que cela ne peut pas être fait.

Le mieux que vous puissiez faire pour empêcher les utilisateurs d'abuser du nœud de sortie pour contribuer à DDOS est de détecter des paquets très fréquents dirigés vers une adresse IP.

Le seuil "très fréquent" dépend de la bande passante totale du nœud ... S'il est incorrect, il y aura des faux positifs, bloquant le trafic légitime des applications TCP en temps réel et le trafic provenant de très nombreux clients vers une destination.

Mise à jour (décembre 2014)

Mes prédictions étaient évidemment vraies - j'ai eu plusieurs plaintes d'abus de réseau de mon fournisseur d'accès Internet.

Pour éviter l'arrêt du service, j'ai dû utiliser l'ensemble de iptablesrègles suivant ( ONEWc'est une chaîne pour les paquets TCP SYN sortants (aka NEW):

Je ne suis pas sûr que cela suffira, mais voici:

-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
filiprem
la source

Réponses:

2

Garde en tête que:

  • Les clients de Tor changent de circuits virtuels toutes les 10 minutes environ selon ma compréhension actuelle. Cela signifie que l'IP source change autour de cette période. Il est peu probable que vous empêchiez tout comportement que vous jugez malveillant plus long que cette durée.

  • Notez que le fait que Tor ne proxy que le trafic TCP et pas tout autre protocole limite un peu les possibilités d'abus.

iptablespeut vous permettre de traiter les nouvelles connexions TCP sortantes différemment des connexions existantes. Tout ce qui est ESTABLISHED,RELATEDdevrait être ACCEPTEDou passer par une chaîne de "connexions TCP existantes", et le TCP sortant qui ne se fait pas attraper pourrait être limité en débit. Tout trafic Tor sortant devrait être soumis à cela.

Je crois qu'entre ce qui précède et l'utilisation de la "politique de sortie réduite" serait le meilleur que vous puissiez faire.

Idéalement, ne lancez rien d'autre sur votre boîtier Tor, sauf:

  • Vous aurez probablement au moins SSH en place, placez-le sur un port différent de 22.
  • Vous voudrez probablement exécuter un simple serveur Web pour afficher cette page . Une mini-httpdinstance chrootée devrait faire l'affaire. Ne pas utiliser inetd.

Ne lancez pas Tor sur une boîte utilisée pour autre chose. Assurez-vous d'avoir lu la section "Relais de sortie" de la FAQ juridique Tor et de bien comprendre ses implications. Lisez aussi et faites tout cela .

LawrenceC
la source
1

Il sera plus difficile que d'habitude de prévenir ces attaques car l'IP source n'est pas constante. Cependant, à ma connaissance, les itinéraires dans tor ne sont modifiés que toutes les quelques minutes environ.

Vous pouvez donc toujours déployer certaines des règles de limitation / filtrage standard mais avec un seuil plus élevé, car vous devez supposer qu'il existe un réseau entier derrière vos adresses IP source.

Vous pouvez filtrer:

  • paquets d'empreintes digitales / de numérisation défectueux ou typiques (mauvais indicateurs TCP / IP, XMAS, la plupart des types ICMP, etc.)
  • Paquets INVALIDES qui ne correspondent pas aux connexions en cours ou nouvelles (état -m)
  • NOUVELLES connexions commençant à un seuil assez élevé

Cependant, sachez que ces opérations sont généralement effectuées sur le trafic entrant. Vous ne savez pas quel type de protocoles vos «clients» exécuteront et vous pouvez les restreindre de manière qui peut être ennuyeuse / peu claire.

En outre, pour les nouveaux paquets (ou sans état) à limitation de débit, vous pouvez envisager un schéma plus complexe où les paquets rejetés (jamais DROP sauf s'il s'agit évidemment d'une attaque!) Sont randomisés. De cette façon, un utilisateur régulier peut simplement essayer de recharger et d'avoir de la chance, même si le taux global est actuellement à la limite, tandis qu'un scanner de port simultané ne pourra pas contourner votre limite de taux.

Demandez également sur les listes de diffusion Tor, vous n'êtes probablement pas le premier à avoir de telles pensées: https://lists.torproject.org/cgi-bin/mailman/listinfo

pepe
la source
1

Tout d'abord, je ne suggérerais pas iptables pour résoudre tout cela, vraiment un nœud de sortie idéal chargerait le trafic de balace à travers quelques tunnels VPN pour garder les yeux du FAI hors des paquets et de la vraie destination et / ou utiliser un proxy de mise en cache pour garder les demandes de répétition sortantes au contenu statique populaire au minimum ... tout en examinant ces options, voici un pansement pour les problèmes de plainte pour abus;

Sources d'informations utilisées

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/

Combiner les deux liens source en règles qui peuvent être utilisées pour frustrer les robots essayant d'utiliser votre nœud de sortie Tor pour l'analyse des ports. Notez que cela peut rendre les pirates utilisant votre nœud de sortie très mécontents car ces règles entraînent un blocage de 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

Exécutez ci-dessus avec bashpour avoir des magies préformées sur des variables avec des ,cammas c'est-à-dire;

user@host~# bash iptables_limit_tor.sh

Voici à nouveau cette liste de variables

_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"

Notez que vous souhaiterez peut-être également filtrer les nouvelles connexions sortantes pour les -m state NEW ! --syntypes de contacts amusants utilisés par certains robots pour trouver des serveurs exploitables.Voici un exemple de chaîne que vous pourriez avoir préfet les deux ci-dessus pour filtrer davantage ces bavardages malformés.

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

Cependant, la chaîne ci-dessus serait très restrictive car tout paquet correspondant verra son adresse IP interdite (peut-être changer -j out_temp_banpour -j DROPou -j REJECTpour tester) pendant autant de secondes choisies dans les règles de cette chaîne. Cet ensemble de règles peut également provoquer des échecs positifs lorsque des applications mal codées du côté client se reconnectent via un nouveau Tor cercut.

~~~~~

Logiciel à prendre en compte pour la poursuite du trafic. Découvrez firejailpour Linux, la source est sur Github et Source forge et les pages de manuel se trouvent sur l'ancienne page d'accueil, un sous-domaine wordpress, et DigitalOcean a un guide pour Nginx avec PHP et Firejail qui avec une petite modification pourrait vous donner beaucoup plus d'incitation à l'endroit où le réseau devrait être étranglé. Il existe d'autres outils tels que ceux KVMqui peuvent également être utilisés pour maintenir les services spiciffic dans les limites opérationnelles, alors magasinez pour trouver celui qui convient le mieux à votre système.

Encore une autre option serait d'exécuter fail2bande telle manière que lorsqu'un administrateur sys fou atteigne une connexion http ou ssl à votre IP qu'une règle soit ajoutée pour être supprimée-m state --state NEWconnexions à ceux qui demandent votre page d'avis de sortie. Si cela est combiné avec des limites de temps saines d'interdiction, le serveur distant peut faire une pause pendant que son administrateur système murmure à propos de la pollution des journaux ;-) Cependant, cela dépasse le cadre de cette réponse actuelle et dépend du logiciel que vous utilisez pour servir quitter les pages d'avis; indice à la fois nginx et apache serviront le premier bloc vhost ou serveur dans vos configurations si maintenant l'URL a été demandée. Si vous utilisez autre chose qu'apache ou nginx, vous voudrez consulter les pages de manuel, mais pour moi, c'était aussi simple que de configurer le premier vhost pour se connecter à un fichier différent et demander à fail2ban d'ajouter les IP de ce journal à une liste d'interdiction temporaire ; cela fonctionne également très bien pour interdire les bots sur les serveurs publics, car ils utilisent généralement une adresse IP et ne fournissent pas de demande de domaine, le serveur servant le piège à bot,

Je préfèrerais les twords exécutant une politique de sortie Tor restreinte (on dirait que vous avez géré cela), puis en poussant le trafic via les tunnels VPN, des points de crédit supplémentaires pour l'équilibrage de charge entre les tunnels multipules. Parce que cela perturberait moins le trafic du réseau Tor et garderait les yeux de votre FAI voilés sur le fait que vous exécutez un nœud de sortie ... à moins qu'ils ne veuillent admettre renifler et casser le trafic VPN. En effet, l'exécution de règles qui interdisent temporairement ou permettent à l'hôte distant de s'interdire automatiquement peut entraîner une violation de la confidentialité des clients de votre nœud, alors que pousser le trafic vers un VPN (ou quelques-uns) aiderait la confidentialité de votre client et garderait votre FAI d'être harcelé avec des demandes pour vos journaux de trafic réseau par tout gouvernement capable de fonctionner whois www.some.domain.

~~~~

Modifications / mises à jour

~~~~

J'ai fait un tour dans mes notes extencives et j'ai remonté les configurations pour les serveurs publics que j'utilise

Voici le fail2ban jail.localstansa

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

Et voici le apache-ipscan.conffichier de filtre

[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

Et voici le iptables-repeater.confdossier d' action

# 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

Remarque: le filtre ci-dessus a été modifié pour bloquer OUTPUTles actions de démarrage / arrêt, mais vous souhaiterez toujours ajouter les -p TCP -m state --state NEWconfigurations à chaque ligne pour que seules les nouvelles connexions sortantes soient bannies de l'adresse IP enregistrée.

La dernière consiste à mettre en place une configuration Apache vHost qui achemine ceux qui ne demandent pas de domaine vers un journal d'accès et d'erreur spécifique et de définir l'accès autorisé vs refusé de telle sorte qu'il génère toujours des erreurs, même le bouclage ne devrait pas pouvoir afficher la page sans erreurs de saut. . Le dernier mais non le moindre est de définir la page d'erreur pour Apache sur l'avis de sortie par défaut de Tor afin qu'elle soit servie au lieu de 503ou404messages fades. Ou si vous avez ajouté les lignes d'état aux actions iptables pour fail2ban, vous pouvez facilement pointer vers le même fichier journal utilisé par votre avis de sortie. Le résultat serait que votre serveur ne serait pas en mesure d'établir de nouvelles connexions avec l'IP du serveur qui a vérifié votre adresse IP, mais les connexions établies et associées seraient toujours autorisées, c'est-à-dire qu'elles pourraient toujours parcourir vos autres pages mais vous ne pourriez pas parcourir thiers .

S0AndS0
la source
Très bien accueilli, si vous avez apprécié le fait que je viens de pousser une grande somme de scripts / notes sur GitHub que vous voudrez peut-être regarder. J'ai commencé ce projet en privé il y a plus d'un an, mais maintenant que la santé est un problème, je l'ai rendu public pour le débogage et l'ajout de fonctionnalités au cas où je ne pourrais pas le terminer; cela et les actions sûres prises localement et globalement par d'autres m'ont poussé à prendre position pour faire de la vie privée un changement plus facile.
S0AndS0
J'ai écrit un autre projet et l'ai poussé vers GitHub . Cela vise à aider les administrateurs de serveur à protéger les journaux de leur serveur en utilisant le cryptage asymétrique GnuPG. Tant que votre nœud de sortie ou service caché ne détient pas la clé privée associée, le projet ci-dessus devrait empêcher les journaux précédents de divulguer les adresses IP des autres nœuds se connectant à votre propre nœud.
S0AndS0
0

La bande passante limitée du reste du réseau Tor résoudra ces problèmes pour vous. De plus, si vous êtes inquiet, exécutez simplement le relais, pas un nœud de sortie.

Richard Hum
la source
0

J'ai une meilleure solution: le serveur de cache Squid. Serveur de cache Squid disponible pour configurer la définition aclet vous denyou acceptchacun acl. Il est très intéressant que l'équipe de calmar définisse un ensemble de règles dans son wiki que votre question y trouve iptables,PFou que d'autres ne peuvent pas faire votre travail, car il suffit de travailler dans d'autres couches.

Golfe Persique
la source
Je ne vois aucun moyen sensé de combiner Squid (que je connais et que j'aime) avec Tor ...
filiprem
essayez avec Zebra route.
PersianGulf
Voulez-vous dire rediriger le trafic de sortie tor qui va au port 80, et le canaliser à travers Squid pour ajouter un certain contrôle? Cela ne résout qu'une petite partie du problème. La vraie cause est d'empêcher l'abus de Tor pour tout DDOS basé sur IP.
filiprem
Vous pouvez utiliser la conception de votre réseau en trois couches: 1. couche extérieure 2. couche de processus. 3. couche utilisateur / serveur ====> Cela entraînera une amélioration de votre sécurité.
PersianGulf