~~~~~

Question

Ich möchte ein Open durchführenTorRouter.

Meine Ausstiegspolitik wird ähnlich sein wieReduzierteAustrittspolitik.

Ich möchte es dem Tor-Netzwerk aber auch schwer machen, meine Ressourcen zu missbrauchen.

Fälle, die ich Kunden nicht über Tor erlauben möchte:

• Eine Site mit sehr vielen Paketen überlasten.
• Aggressive Netscans ganzer IP-Blöcke

Fälle, die ich Clients NICHT über Tor verbieten möchte:

• Hochladen einiger hundert Bilddateien in die Cloud
• einen Torrent säen

Meine Frage ist nun: Ist das überhaupt möglich und wie?

Mein erster Gedanke war eine Firewall (Linux/iptables oder *BSD/ipfw/pf) – aber das wird aufgrund der inhärenten Eigenschaften des Onion-Routers wahrscheinlich nutzlos sein.

Gibt es zu diesem Thema laufende Entwicklungen beim Torproject-Team?

Außerdem bitte ich um allgemeine Hinweise zur Absicherung von Tor-Exit-Knoten.

Update (September 2012)

Aufgrund hilfreicher Antworten und einiger anderer Untersuchungen bin ich der Meinung, dass dies nicht möglich ist.

Das Beste, was Sie tun können, um zu verhindern, dass Benutzer den Exit-Knoten missbrauchen, um an DDOS teilzunehmen, ist, sehr häufige Pakete zu erkennen, die an eine IP gerichtet sind.

Der Schwellenwert „sehr häufig“ hängt von der gesamten Knotenbandbreite ab. Wenn dieser Wert falsch ist, kommt es zu Fehlalarmen, wodurch legitimer Datenverkehr von Echtzeit-TCP-Apps und Datenverkehr von sehr vielen Clients zu einem Ziel blockiert werden.

Update (Dezember 2014)

Meine Vorhersagen haben sich offensichtlich bewahrheitet – ich erhielt von meinem Internetprovider mehrere Beschwerden wegen Netzwerkmissbrauchs.

Um eine Dienstunterbrechung zu vermeiden, musste ich den folgenden Regelsatz anwenden iptables( ONEWist eine Kette für ausgehende TCP SYN-Pakete (auch bekannt als NEW):

Ich bin nicht sicher, ob es ausreicht, aber hier ist es:

-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

Answer 1

Denk daran, dass:

• Soweit ich weiß, wechseln Tor-Clients etwa alle 10 Minuten die virtuellen Schaltkreise. Das bedeutet, dass sich die Quell-IP in diesem Zeitrahmen ändert. Es ist unwahrscheinlich, dass Sie ein Verhalten, das Sie für böswillig halten, länger als diesen Zeitraum verhindern können.

• Beachten Sie, dass die Missbrauchsmöglichkeiten erheblich eingeschränkt sind, da Tor nur TCP-Verkehr und kein anderes Protokoll überträgt.

iptableskann Ihnen ermöglichen, neue ausgehende TCP-Verbindungen anders zu behandeln als bestehende. Alles, was dies ist, ESTABLISHED,RELATEDsollte ACCEPTEDdurch eine Kette „bestehender TCP-Verbindungen“ geleitet werden, und ausgehende TCP-Verbindungen, die davon nicht erfasst werden, könnten geschwindigkeitsbegrenzt werden. Für jeden ausgehenden Tor-Verkehr sollte dies gelten.

Ich glaube, dass das oben Genannte und die Anwendung der „Reduced Exit Policy“ das Beste ist, was Sie tun können.

Führen Sie auf Ihrer Tor-Box im Idealfall nichts anderes aus außer:

• Wahrscheinlich haben Sie zumindest SSH aktiv, verwenden Sie dafür aber einen anderen Port als 22.
• Sie möchten wahrscheinlich einen einfachen Webserver betreiben, umdiese Seite. Eine chroot- mini-httpdInstanz sollte genügen. Verwenden Sie nicht inetd.

Führen Sie Tor nicht auf einer Box aus, die für etwas anderes verwendet wird. Stellen Sie sicher, dass Sie den Abschnitt „Exit Relays“ gelesen habendie rechtlichen FAQ von Torund seine Auswirkungen vollständig verstehen.Lesen und tun Sie dies alles.

Answer 2

Es wird schwieriger als sonst, diese Angriffe zu verhindern, da die Quell-IP nicht konstant ist. Meines Wissens werden die Routen in Tor jedoch nur etwa alle paar Minuten geändert.

Sie könnten also weiterhin einige der Standardbeschränkungs-/Filterregeln einsetzen, allerdings mit einem höheren Schwellenwert, da Sie davon ausgehen müssen, dass sich hinter Ihren Quell-IPs ein ganzes Netzwerk verbirgt.

Sie können filtern:

• fehlerhafte oder typische Fingerprinting-/Scan-Pakete (fehlerhafte TCP/IP-Flags, XMAS, die meisten ICMP-Typen usw.)
• UNGÜLTIGE Pakete, die nicht zu bestehenden oder neuen Verbindungen passen (-m-Status)
• NEUE Verbindungen beginnen bei einer ziemlich hohen Hürde

Beachten Sie jedoch, dass solche Dinge normalerweise für eingehenden Datenverkehr gelten. Sie wissen nicht, welche Art von Protokollen Ihre „Kunden“ verwenden, und Sie können sie möglicherweise auf eine Weise einschränken, die ärgerlich/unklar sein kann.

Um die Rate NEUER (oder zustandsloser) Pakete zu begrenzen, sollten Sie auch ein komplexeres Schema in Betracht ziehen, bei dem die abgelehnten (niemals DROP-Pakete, es sei denn, es handelt sich offensichtlich um einen Angriff!) Pakete zufällig ausgewählt werden. Auf diese Weise kann ein normaler Benutzer einfach versuchen, auf „Neu laden“ zu klicken und Glück haben, obwohl die Gesamtrate derzeit am Limit ist, während ein gleichzeitiger Port-Scanner Ihre Ratenbegrenzung nicht umgehen kann.

Fragen Sie auch auf den Tor-Mailinglisten nach, Sie sind wahrscheinlich nicht der Erste, der solche Gedanken hat:https://lists.torproject.org/cgi-bin/mailman/listinfo

Answer 3

Zunächst einmal würde ich nicht empfehlen, iptables zu verwenden, um all dies zu lösen. Ein idealer Tor-Exit-Knoten würde den Verkehr über ein paar VPN-Tunnel verteilen, um die Augen des ISPs von den Paketen und dem wahren Ziel fernzuhalten, und/oder einen Caching-Proxy verwenden, um ausgehende Wiederholungsanfragen an beliebtestatischInhalt auf ein Minimum... während wir uns diese Optionen ansehen, hier ist einPflasterfür die Probleme mit Missbrauchsbeschwerden;

Verwendete Informationsquellen

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/

Kombinieren Sie die beiden Quelllinks zu Regeln, mit denen Sie Bots daran hindern können, Ihren Tor-Exit-Knoten zum Scannen von Ports zu verwenden. Beachten Sie, dass dies Hacker, die Ihren Exit-Knoten verwenden, sehr unglücklich machen kann, da diese Regeln zu Nmap-Hang-Times führen.

#!/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

Führen Sie es oben aus, um Magie auf Variablen mit Cammas bashauszuführen , d. h.;,

user@host~# bash iptables_limit_tor.sh

Hier ist noch einmal die Liste der Variablen

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

-m state NEW ! --synBeachten Sie, dass Sie neue ausgehende Verbindungen möglicherweise auch nach folgenden Arten filtern möchten :lustigWird von einigen Bots verwendet, um angreifbare Server zu finden. Hier ist eine Beispielkette, die Sie den beiden oben genannten voranstellen könnten, um solchen missgestalteten Chatter weiter zu filtern.

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

Die obige Kette wäre jedoch sehr restriktiv, da die IP jedes übereinstimmenden Pakets für die in den Regeln dieser Kette gewählte Anzahl von Sekunden gesperrt wird (vielleicht geändert -j out_temp_banin -j DROPoder -j REJECTzu Testzwecken). Dieser Regelsatz könnte auch zu Fehlalarmen führen, wenn schlecht codierte Apps auf der Clientseite über einen neuen Tor-Cert wieder eine Verbindung herstellen.

~~~~~

Software, die Sie zur weiteren Steuerung des Datenverkehrs in Betracht ziehen sollten. Schauen Sie sich firejailLinux an. Die Quelle befindet sich auf Github und Source Forge und die Manpages finden Sie auf der alten Homepage, einer WordPress-Subdomäne. DigitalOcean bietet einen Leitfaden für Nginx mit PHP und Firejail, der Ihnen mit einer kleinen Änderung viel mehr Aufschluss darüber geben könnte, wo das Netzwerk gedrosselt werden sollte. Es gibt KVMauch andere Tools wie, die verwendet werden können, um bestimmte Dienste innerhalb der Betriebsgrenzen zu halten, sodassGeschäftum diejenige zu finden, die am besten zu Ihrem System passt.

Eine weitere Option wäre, fail2banes so auszuführen, dass, wenn ein verrückter Systemadministrator versucht, eine HTTP- oder SSL-Verbindung zu Ihrer IP herzustellen, eine Regel hinzugefügt wird, um -m state --state NEWVerbindungen zu denen zu trennen, die Ihre Exit-Notice-Seite anfordern. In Kombination mit vernünftigen Zeitlimits für die Aufhebung der Sperre könnte dies dem Remote-Server eine Pause gönnen, während dessen Systemadministrator über die Protokollverschmutzung murrt ;-) Dies geht jedoch über den Rahmen dieser aktuellen Antwort hinaus und hängt davon ab, welche Software Sie zum Bereitstellen der Exit-Notice-Seiten verwenden; Hinweis: Sowohl Nginx als auch Apache stellen den ersten virtuellen Host oder Serverblock in Ihren Konfigurationen bereit, wenn keine URL angefordert wurde. Wenn Sie etwas anderes als Apache oder Nginx verwenden, sollten Sie die Manpages zu Rate ziehen, aber für mich war es so einfach, den ersten virtuellen Host so einzustellen, dass er in eine andere Datei protokolliert und fail2ban alle IPs aus diesem Protokoll zu einer temporären Sperrliste hinzufügt; Dies funktioniert auch hervorragend zum Sperren von Bots auf öffentlichen Servern, da diese normalerweise eine IP-Adresse verwenden und das Unterlassen einer Domänenanforderung dazu führt, dass der Server die Bot-Falle oder in diesem Fall eine Exit-Benachrichtigung ausgibt.

Ich würde dazu tendieren, eine eingeschränkte Tor-Exit-Richtlinie zu verwenden (sieht so aus, als ob Sie das im Griff haben) und dann den Verkehr durch VPN-Tunnel zu leiten, zusätzliche Punkte für die Lastverteilung zwischen mehreren Tunneln. Denn dies würde weniger Störungen im Tor-Netzwerkverkehr verursachen und Ihrem ISP die Augen vor der Tatsache verschließen, dass Sie einen Exit-Knoten betreiben ... es sei denn, er möchte zugeben, dass er Ihren VPN-Verkehr abhört und knackt. Dies liegt daran, dass die Ausführung von Regeln, die temporäre Sperren oder die Selbstsperrung von Remote-Hosts ermöglichen, zu einer Verletzung der Privatsphäre der Clients Ihres Knotens führen könnte, wohingegen die Weiterleitung des Verkehrs an ein VPN (oder mehrere) die Privatsphäre Ihres Clients schützen und verhindern würde, dass Ihr ISP mitAnfragenfür Ihre Netzwerkverkehrsprotokolle durch jede Regierung, die dazu in der Lage ist whois www.some.domain.

~~~~

Änderungen/Aktualisierungen

~~~~

Ich habe meine ausführlichen Notizen durchgesehen und die Konfigurationen der öffentlichen Server aufgerufen, die ich verwende

Hier ist die Fail2ban- jail.localStrophe

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

Und hier ist die apache-ipscan.confFilterdatei

[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

Und hier ist die iptables-repeater.confAktionsdatei

# 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

Beachten Sie, dass der obige Filter bearbeitet wurde, um OUTPUTdie Start-/Stopp-Aktionen zu blockieren. Sie möchten jedoch trotzdem -p TCP -m state --state NEWjeder Zeile die Konfigurationen hinzufügen, um nur neue ausgehende Verbindungen von der protokollierten IP-Adresse zu sperren.

Zuletzt muss eine Apache vHost-Konfiguration eingerichtet werden, die diejenigen, die keine Domäne anfordern, an ein bestimmtes Zugriffs- und Fehlerprotokoll weiterleitet, und der erlaubte bzw. verweigerte Zugriff muss so eingestellt werden, dass immer Fehler auftreten. Nicht einmal der Loopback sollte die Seite ohne Fehler aufrufen können. Zu guter Letzt muss die Fehlerseite für Apache auf die Standard-Exit-Benachrichtigung von Tor eingestellt werden, damit diese anstelle von nichtssagenden Nachrichten angezeigt wird 503. 404Oder wenn Sie die Statuszeilen zu den iptables-Aktionen für fail2ban hinzugefügt haben, können Sie einfach auf dieselbe Protokolldatei verweisen, die von Ihrer Exit-Benachrichtigung verwendet wird. Das Ergebnis wäre, dass Ihr Server keine neuen Verbindungen zur IP des Servers herstellen könnte, der Ihre IP-Adresse überprüft hat, aber bestehende und verwandte Verbindungen wären weiterhin zulässig, d. h. sie könnten weiterhin Ihre anderen Seiten durchsuchen, Sie jedoch nicht deren.

Answer 4

Ich habe eine bessere Lösung: Squid-Cache-Server. Squid-Cache-Server können konfiguriert aclund definiert denywerden . Es ist sehr interessant, dass das Squid-Team in seinem Wiki einen Satz von Regeln definiert, die Ihre Frage gefunden accepthabenaclDort iptables,PFoder andere können Ihre Arbeit nicht erledigen, weil sie einfach in anderen Ebenen arbeiten.