nicht angemeldet
iptables-persistent und fail2ban
Hallo werte Selfgemeinde!
Ich hätte da mal die eine oder andere Frage, um einen Server mit Debian 7 (Wheezy) abzusichern.
Damit die Firewall-Regeln einen Neustart überleben, habe ich brav das Paket 'iptables-persistent' installiert und zusätzlich noch 'fail2ban'.
Erstes Problem, bzw. erste Frage:
Wenn ich jetzt manuell eine weitere Regel zu 'iptables' hinzufüge, und diese dann per 'iptables-save > /etc/iptables/rules.v4' abspeichere, dann packt er mir da aber auch alle von fail2ban erstellen Regeln mit rein.
Diese fügt fail2ban aber nach einem Neustart selbsttätig wieder ein, womit diese dann doppelt vorhanden wären. Und zum anderen würden ja dann ggf. längst überholte Regeln wieder aktiv.
Bis jetzt mache ich es immer so, dass ich nach dem Speichern alle Regeln von fail2ban "zu Fuß" wieder aus der Datei lösche. Aber das erscheint mir nicht unbedingt die ideale Lösung zu sein.
Gibt es eine elegantere/ einfachere Möglichkeit?
Oder sollte ich einfach "meine" Regeln direkt in die 'rules.vx' Dateien schreiben und auf 'iptables-save' verzichten?
Gruß Gunther
-
Tach!
Oder sollte ich einfach "meine" Regeln direkt in die 'rules.vx' Dateien schreiben und auf 'iptables-save' verzichten?
Bei Debian 6 und ein wenig mehr Netzwerkkonfiguration als nur Firewall-Regeln hab ich ein Shellscript geschrieben, das in der /etc.rc.local aufgerufen wird, und bei Bedarf angepasst werden kann. Damit entsteht immer eine definierte Situation ohne dem Zeug von Fail2ban. Der kann sich dann im weiteren Verlauf des Hochfahrens einhängen.
dedlfix.
-
Tach!
Danke für deine Antwort.
Oder sollte ich einfach "meine" Regeln direkt in die 'rules.vx' Dateien schreiben und auf 'iptables-save' verzichten?
Bei Debian 6 und ein wenig mehr Netzwerkkonfiguration als nur Firewall-Regeln hab ich ein Shellscript geschrieben, das in der /etc.rc.local aufgerufen wird, und bei Bedarf angepasst werden kann. Damit entsteht immer eine definierte Situation ohne dem Zeug von Fail2ban. Der kann sich dann im weiteren Verlauf des Hochfahrens einhängen.
Na ja, genau das soll 'iptables-persistent' ja machen, bzw. macht es ja auch.
Ich werde einfach die Regeln direkt in die beiden Dateien schreiben und gut ist.Ich hätte da aber noch eine andere Frage in dem Zusammenhang, die fail2ban betrifft.
Im Moment sperrt mir der Standard-Filter 'apache-overflows' u.a. auch den Googlebot regelmäßig aus.
Grund sind Requests à la: Invalid method in request \x16\x03\x01
Das "passiert" ja AFAIK wenn ein Request mit HTTPS an einen Nicht-HTTPS VH gerichtet wird. Ich hab' aber keine Ahnung, wie oder warum der Googlebot permanent auf solche Ideen kommt ...!?Irgendeinen Tipp, was ich sinnvollerweise tun könnte/ sollte?
Denn eigentlich möchte ich den Googlebot nicht aussperren. ;-)Besten Dank im Voraus!
Gruß Gunther
-
Mahlzeit,
Irgendeinen Tipp, was ich sinnvollerweise tun könnte/ sollte?
Denn eigentlich möchte ich den Googlebot nicht aussperren. ;-)Dafür gibt es extra die Option ignoreip. Steht sogar beschrieben in der Default-Config.
--
42-
Mahlzeit,
Irgendeinen Tipp, was ich sinnvollerweise tun könnte/ sollte?
Denn eigentlich möchte ich den Googlebot nicht aussperren. ;-)Dafür gibt es extra die Option ignoreip. Steht sogar beschrieben in der Default-Config.
Danke, die Einstellung ist mir durchaus bekannt im Gegensatz zu den möglichen IPs des Googlebots.
Vielleicht kannst du mir bitte sagen, ob der auch noch in einem anderen IP-Bereich als 66.249.64.0/20 (66.249.64.0 - 66.249.79.255) unterwegs ist?
Gruß Gunther
-
Hallo,
Denn eigentlich möchte ich den Googlebot nicht aussperren. ;-)
Dafür gibt es extra die Option ignoreip. Steht sogar beschrieben in der Default-Config.
Danke, die Einstellung ist mir durchaus bekannt im Gegensatz zu den möglichen IPs des Googlebots.
Vielleicht kannst du mir bitte sagen, ob der auch noch in einem anderen IP-Bereich als 66.249.64.0/20 (66.249.64.0 - 66.249.79.255) unterwegs ist?
mit Sicherheit - und wenn nicht diesen Monat, dann nächsten Monat oder übernächstes Jahr. Google ist zudem auch inkognito unterwegs, um zu prüfen, ob ein Suchmaschinenspammer (vulgo: SEO) den Index mit anderen Sachen beliefert als Otto Normalsurfer. Und davon ganz unabhängig sind Ausnahmeregeln für Google nur ein Rumdoktern an den Symptomen, keine Ursachenbeseitigung.
Kurzum: Der IP-Nummernfilter ist ein Griff ins Klo, damit brauchst du gar nicht erst anfangen.
Grund sind Requests à la: Invalid method in request \x16\x03\x01
Das "passiert" ja AFAIK wenn ein Request mit HTTPS an einen Nicht-HTTPS-VH gerichtet wird. > Ich hab' aber keine Ahnung, wie oder warum der Googlebot permanent auf solche Ideen kommt ...!?Da musst du aber ansetzen, denn das wäre die Ursache. Klopfe deine Konfiguration ab, hast du möglicherweise den Port 443 für den Webserver offen, aber kein SSL eingeschaltet (-> Port schließen)? Oder hast du SSL auf einem Webserver eingeschaltet, der auch virtuelle Hosts beliefert (-> Port 443 nur für SSL-Host freigeben, oder SSL und Port abschalten)?
Falls du bei dir keine Ursache findest, ist es halt so, dann ist jemand anderes verantwortlich und du brauchst dir keinen Kopf machen. Konfiguriere fail2ban so, dass es auf diese Fehler generell nicht reagiert, oder schmeiße fail2ban ganz raus, ist für so ziemlich alle Webserver eh überbewertet.
Du hast nichts davon, wenn du ständig nach den aktuellen IP-Adressen des Googlebots suchen musst und dir obendrein nicht einmal sicher sein kannst, dass du auch alle erwischt hast. Dann kannst du es dir auch einfacher machen und selbst die Protokolle des Webservers auswerten.Schönen Tag,
Hannes-
Hallo Hannes!
mit Sicherheit - und wenn nicht diesen Monat, dann nächsten Monat oder übernächstes Jahr. Google ist zudem auch inkognito unterwegs, um zu prüfen, ob ein Suchmaschinenspammer (vulgo: SEO) den Index mit anderen Sachen beliefert als Otto Normalsurfer. Und davon ganz unabhängig sind Ausnahmeregeln für Google nur ein Rumdoktern an den Symptomen, keine Ursachenbeseitigung.
Kurzum: Der IP-Nummernfilter ist ein Griff ins Klo, damit brauchst du gar nicht erst anfangen.
Da stimme ich dir zu! ;-)
Grund sind Requests à la: Invalid method in request \x16\x03\x01
Das "passiert" ja AFAIK wenn ein Request mit HTTPS an einen Nicht-HTTPS-VH gerichtet wird. > Ich hab' aber keine Ahnung, wie oder warum der Googlebot permanent auf solche Ideen kommt ...!?Da musst du aber ansetzen, denn das wäre die Ursache. Klopfe deine Konfiguration ab, hast du möglicherweise den Port 443 für den Webserver offen, aber kein SSL eingeschaltet (-> Port schließen)? Oder hast du SSL auf einem Webserver eingeschaltet, der auch virtuelle Hosts beliefert (-> Port 443 nur für SSL-Host freigeben, oder SSL und Port abschalten)?
Das war's ...!
Da hat sich doch so ein pauschaler Listen 443 Eintrag in meine Apache ports.conf gemogelt. Jetzt ist er auf die entsprechende IP beschränkt und gut ist.Falls du bei dir keine Ursache findest, ist es halt so, dann ist jemand anderes verantwortlich und du brauchst dir keinen Kopf machen. Konfiguriere fail2ban so, dass es auf diese Fehler generell nicht reagiert, oder schmeiße fail2ban ganz raus, ist für so ziemlich alle Webserver eh überbewertet.
Nö, das ist schon ganz praktisch ...!
Ich habe z.B. sehr viele Chinesen, die sich scheinbar brennend für meinen Server interessieren. Und es ist nur eine Frage der Zeit, bis auch noch die Russen kommen ...! ;-)
Da finde ich eine Variante, solche Leute automatisch auszusperren schon ganz praktisch.Gruß Gunther
-
-
-
-
Tach!
Bei Debian 6 und ein wenig mehr Netzwerkkonfiguration als nur Firewall-Regeln hab ich ein Shellscript geschrieben, das in der /etc.rc.local aufgerufen wird, und bei Bedarf angepasst werden kann. Damit entsteht immer eine definierte Situation ohne dem Zeug von Fail2ban. Der kann sich dann im weiteren Verlauf des Hochfahrens einhängen.
Na ja, genau das soll 'iptables-persistent' ja machen, bzw. macht es ja auch.
Deiner Beschreibung nach schreibt es beim Runterfahren alle aktuellen Einträge auf die Platte, also inklusive der Fail2bans. Mein Script hat ja (bezüglich der Firewall) nur die Regeln, die ich fest vergeben habe und nicht das was sonst noch so im Laufe der Uptime hinzukam, also auch nicht die vom Fail2ban hinzugefügten.
dedlfix.
-
Tach!
Na ja, genau das soll 'iptables-persistent' ja machen, bzw. macht es ja auch.
Deiner Beschreibung nach schreibt es beim Runterfahren alle aktuellen Einträge auf die Platte, also inklusive der Fail2bans. Mein Script hat ja (bezüglich der Firewall) nur die Regeln, die ich fest vergeben habe und nicht das was sonst noch so im Laufe der Uptime hinzukam, also auch nicht die vom Fail2ban hinzugefügten.
Nein, das ist dann ein Missverständnis gewesen. Ich hatte ja geschrieben:"... dann per 'iptables-save > /etc/iptables/rules.v4' abspeichere ...", und wollte eigentlich quasi nur eine Bestätigung meiner Annahme, dass das nicht der richtige Weg ist, sondern man/ ich die Regeln gleich in die beiden Dateien von 'iptables-persistent' schreiben muss (anstatt 'iptables-save' zu verwenden).
Denn die Regeln aus den Dateien werden beim (Neu)start automatisch wieder geladen.
Zusätzlich klinkt sich fail2ban (ebenfalls selbständig) wieder mit ein.Gruß Gunther
-
-
-