ich würde gerne mal das Thema Nutzerblockaden auf der Haupt-Domain freifunk.net zur Diskussion stellen, denn ich finde die jetztige Konfiguration ehrlich gesagt etwas unpassend für eine Iniziative, welche sich für freies Netz einsetzt.
Ich bin üblicherweise immer über unser lokales Netz unterwegs, welches u.A. einen VPN-Exit (Mullvad) nutzt. Nun fand ich unterwegs einen Interessierten, der mehr erfahren wollte. Da er aus einem anderen Bundesland kam wollte ich „mal schnell“ auf der Communityliste nachschauen. Nope. Freifunk.net liefert nur „Forbidden - You do not have permission to access this document.“. Hm, OK, vielleicht grade was kaputt. Schnell nochmal über SSH vom heimischen Anschluss versucht: Gleiche Meldung. Immerhin kommte ich mich mit der DE-Karte behelfen und ihn an die lokale Community verweisen.
Das war letzte Woche. Da ich heute immer noch nicht auf freifunk.net zugreifen konnte und mir das dann doch seltsam vorkam habe ich nochmal genauer drüber geschaut. Für mich sieht das aktuell so aus:
Alle Verbindungen von Mullvad werden vollständig abgelehnt
Alle Verbindungen von Clients, die nicht nach Browser aussehen, werden ebenfalls abgelehnt
Betroffen ist ausschließlich die Startseite, Subdomains (Communities, Wiki, Forum, API, etc) funktionieren
Finde ich alles etwas unschön. Mullvad ist im Freifunk-Umfeld gefühlt noch recht verbreitet, das auszuschließen - und damit auch alle Clients, die in einer dieser FF-Communities eingebucht sind - klingt für mich nicht gerade nach einer sinnvollen Maßnahme. Interessanterweise läuft es wenn man Tor dazwischen schaltet.
Auch der User-Agent-Block ist in meinen Augen eher für „die guten Nutzer“ nervig als er gegen „die bösen Nutzer“ hilft. Wer Böses machen will setzt halt einen anderen UA. Auf der anderen Seite schauen Leute wie ich blöd aus der Wäsche, da der kurze Erreichbarkeitstest mit wget im Nirvana landet. Hätte man mal curl genutzt. Auch dürfte es recht sinnvolle und kaum verwerfliche Anwendungen dafür geben $dinge ohne Browser per Script von der Webseite abzugrasen, denn wofür sonst ist z.B. der RSS-Feed da? (freifunk.net).
Meine Bitte: Herrscht wirklich so ein Leidensdruck, dass die Sicherheit der Webseite nicht gewährleistet werden kann ohne Nutzergruppen auszuschließen? Gibt es eventuell andere Möglichkeiten, die weniger gestreut greifen?
In jedem Fall wäre es sehr hilfreich den Standardtext des Webservers bei der Blockade zu ersetzen und eine kurze Erklärung zu liefern, sodass ein Benutzer weiß was Sache ist und nicht tagelang davon ausgehen muss, dass die Seite wohl kaputt ist.
Ich denke das hat nichts mit den Betreibern von freifunk.net zu tun, sondern werden allgemeine Maßnahmen von Hosteurope sein um die Hosting Webserver zu schützen. Diese blocken vermehrt VPN und TOR Exits. Nervig sind schon die vielen Cloudflare Captchas die ein Freifunk Nutzer zu Gesicht bekommt, wenn er bestimmte Seiten aufrufen will. Diese Probleme können auch Früher oder Später bei Nutzern des Freifunk Rheinland Backbone auftreten, wenn auf deren Exit IPv4 Adressen zu viel Schabernack getrieben wird.
Solche Hoster sollen wir uns aber vorknöpfen und Ihnen die Auswirkungen verdeutlichen. Bzw. Mullvad darauf hinweisen das sie dort auf der Blacklist stehen und man diese Exit-IP zukünftig besser nicht mehr verwendet. Mehr als versuchen und dann ignoriert werden kann man nicht.
auf dem Server führen wir keine Zugriffslogs, deswegen müssen wir proaktiv agieren.
Wir nutzen ein Sicherheitsplugin, das u.a. 2 Sachen macht:
basierend auf einer Liste von hackrepair.com werden bestimmte Bots anhand ihrer User Agents ausgesperrt. Ich habe die Liste mal aktualisiert, für wget-Liebhaber: wget ist nicht mehr enthalten
wenn zuviele falsche Anmeldeversuche kommen, wir eine IP erstmal temporär gesperrt. Wiederholt sich das Spiel einige Male, wird die IP dauerhaft gesperrt. Hier zeigen sich die Nachteile zentralisierter Freifunknetze. Wenn ihr mir die IP-Netze von Mullvad sagt kann ich mal nachgucken und die IPs wieder freigeben.
Und noch was: nehmt den Server bitte nicht als Testziel für „Internet geht“, andere Communities hatten da schon Probleme, als der Server neulich mal umgezogen ist und dabei eine neue IP bekommen hat.
Hm - klingt ehrlich gesagt so sinnvoll wie MAC-Sperren… Wer $böse machen will setzt halt einen anderen. Zudem ist nicht jeder Bot automatisch schädlich.
Fair enough (auch wenn ich mich frage woher die Info kommt, wenn doch die IP nicht aufgezeichnet wird). Den Nachteil der - nennen wir es mal „Föderalität“ - kann man auch umdrehen: Würden alle Communities einen zentralen Exit nutzen ließe sich einfacher eine Ausnahme definieren. Oder man könnte freifunk.net über ein p2p-System dezentral hosten. ;). Spaß beiseite: Wäre schon, aber auf absehbare Zeit kaum vermittelbar, dafür herrscht noch zu viel FUD und Rechtsunsicherheit.
Aber b2t: Aktuell ist es die 46.165.208.203 und 185.65.134.81, die IPs wechseln allerdings dynamisch.
Trotzdem nochmal meine Frage: Könnte man die Fehlermeldung irgendwie aussagekräftiger gestalten, sodass Besucher die Möglichkeit sehen über kommerzielle Netze die Webseite erreichen zu können? Oder den Zugang in diesen Fällen zumindest mit einem CAPTCHA o.Ä. ermöglichen?
bei den Bots geht es darum, Scriptkiddies mit vorgefertigten Scripen oder Botnetze fernzuhalten. Unser Zielpublikum sind auch keine Bots, sondern Menschen mit ganz normalen Browsern.
Die IPs fallen im übrigen bei so einem Versuch in dem Moment einfach an und werden dann gesperrt, allerdings führen wir keine Access- oder Errorlogs, in denen die IP-Adressen später nachzulesen wären.