meine NC auf dem Raspberry PI lÀuft nun schon mehrere Monate sehr stabil. In den letzten Tagen hÀufen sich aber Mails von fail2ban in Bezug auf fehlerhafte Anmeldeversuche mit Sperrung. Nach Sichtung des Logs kann man schnell fehlerhafte Anmeldeversuche der User von potenziellen Angriffen trennen.
Ich wĂŒrde gern einige IP-Rang komplett von der Anmeldung ausschlieĂen wollen. Nach Recherchen hier im Forum habe ich aber nicht die passende Aussage ĂŒber eine Möglichkeit gefunden.
Wie kann ich gewĂŒnschte IP-Rangs komplett ĂŒber fail2ban dauerhaft sperren? Oder nutzt man dazu andere Tools?
danke fĂŒr den Tipp. An iptables hĂ€tte ich selber denken können. Dies wĂ€re sicherlich die schnellste Lösung.
iptables -I INPUT -s 84.3.0.0/16 -j DROP
Dies mĂŒsste ich eingeben.
UFW wĂ€re auch eine gute Möglichkeit ĂŒber das Web-GUI von NC zu arbeiten. Ich kenne UFW nicht. Wie wĂ€re die Administration nach Aktivierung von UFW im Web-GUI?
Soviel ich weiss gibt es keie Integration der UFW in das WebGUI von Nextcloud. UFW ist ein Kommandozeilen-Frontend fĂŒr Iptables, welches aber deutlich einfacher zu konfigurieren ist, als iptables direkt. Ob es dafĂŒr ein Web-UI gibt, weiss ich ehrlich gesagt nicht. Generell scheinen UIs fĂŒr Linux Firewalls irgendwie recht rar zu sein. Spontan kommt mir eigentlich nur Webmin in den Sinn, welches ein Modul fĂŒr die Konfiguration von iptables integriert hat. Dann gibt es noch Cockpit, welches aber soviel ich weiss nur firewalld unterstĂŒtzt.
Soweit ich jetzt recherchiert habe, kann man ĂŒber den MenĂŒpunkt UFW im NC WebAdminGUI nur rudimentĂ€re Funktionen von UFW ausfĂŒhren. Ich werde doch ĂŒber die Kommandozeile die iptables konfigurieren. Nach der Eingabe erhalte ich von iptables -S:
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -s 84.3.0.0/16 -j DROP
Ja via WebGUI kann man dort soviel ich weiss nur Ports öffnen und nicht bestimmte IPs oder IP-Ranges blocken. Solange es nicht aktiv ist, ist grundsÀztlich alles offen.
Jup sieht gut aus.
Möchte dazu aber noch sagen, dass ich kein Experte bin wenn es um iptables geht. Im Moment hast du aber nur eine Regel und solange du einfach weitere DROP-Regeln hinzufĂŒgst bleibt auch alles âeasyâ. Es kann aber sehr schnell, sehr komplex werden, wenn man viele Regeln hat.
Und ich weiss nicht wie sich das nachtrĂ€gliche Einschalten von UFW auf schon bestehende iptables Regeln auswirkt. GrundsĂ€tzlich werden Firewallregeln nach einer bestimmten Reihenfolge abgearbeitet. Wenn du die UFW aktivierst im WebGui von NCP werden alle eingehenden Verbindungen grundsĂ€tzlich geblockt. Es werden aber auch folgende Regeln gesetzt, wenn du die Ports freigibstâŠ
Das könnte dann evtl. den Zugriff fĂŒr die direkt in iptables gesperrten IP Ranges auf Port 22, 80 und 443 wieder erlauben, je nachdem in welcher Reihenfolge iptables die Regeln abarbeitet. Wenn du also vor hast irgendwann UFW zu nutzen, mach es lieber frĂŒher als spĂ€ter und verwalte die Blockregeln am besten auch auch damit. Ansonsten wird das ganze imho unnötig kompliziert.
EDIT:
Noch ein kleines aber nicht unwichtiges Detail, dass ich gestern vergessen habe:
Damit die Regeln, welche du via iptables-Befehl erstellt hast, einen Neustart ĂŒberleben, muss unter Ubuntu/Debian das Paket iptables-persitent installiert werden, und die Regeln mĂŒssen aktiv mit dem Befehl iptables-save > /etc/iptables/rules.v4 gespeichert werden.
Ich habe die Regel erstmal in die rc.local geschrieben, damit ĂŒbersteht diese den Neustart. Die Absicht ist, erstmal einige Zeit IP Rang hier zu sammeln. SpĂ€ter dann ein Script zu schreiben. Wenn Sie mit iptables -S ausgegeben wird, ist diese auch aktiv?
Hast Du noch eine Idee, bzw. gibt es eine Möglichkeit, mit âeinfachenâ Mitteln die Sicherheit von NC gegen externe Angriffe noch zu erhöhen?
Ich nehme mal an, dass deine Nextcloud hinter einem Router/Firewall/NAT lĂ€uft und du nur die Ports 80/443 weitergeleitet hast. Dann ist sie zumindest netzwerkmĂ€ssig gegen aussen, schonmal so weit wie möglich abgesichert. Mehr geht da nicht, wenn sie von aussen ohne VPN oder andere zusĂ€tliche Sicherheitsmassnahmen erreichbar sein soll. Allenfalls könnte man das Ganze noch hinter einen Reverse Proxy setzten. Dieser Aufwand lohnt sich aber imho nur, wenn man mehere Dienste bzw. GerĂ€te hosten will. Ansonsten hat NCP schon eine ziemlich gute Default-Konfiguration und es ist eigentlich nicht nötig noch weitere Sicherheitsmassnahmen auf dem System selbst zu ergreifen, solange du nicht noch weitere Dienste darauf hosten willst, was ich aber nicht emfehlen wĂŒrde, wenn du NCP nutzt. Weitere Sicherheitsmassnahmen wĂ€ren noch SSH nur mit Keys zu benutzen anstatt mit Passwort, solange du SSH aber nicht aus dem Internet erreichbar machst, ist das nicht âzwingendâ notwendig.
Anderseits kommen Bedrohungen halt in der Regel nicht nur von aussen. Wenn du alle deine GerĂ€te wie PCs, Laptops, Smartphones, Tablets, SmartTVs, Smarte Leuchtmittel usw⊠in einem flachen Netzwerk, sprich im gleichen Subnetz betreibst wie deine Nextcloud, besteht halt auch ein potentielles Risiko eines Angriffs von innen. Sprich irgend ein anderes GerĂ€t fĂ€ngt sich etwas ein oder macht eine TĂŒre auf, durch diese dann ein Angriff stattfinden kann. Deshalb wĂŒrde es imho eben schon Sinn machen UFW auf dem NCP-Server zu aktivieren und nur die nötigen Ports zu öffnen.
Ich bin da sogar noch weiter gegangen und betreibe meine verschiedenen GerĂ€te und Dienste in mehreren Subnetzen, und erlaube nur den allernötigsten Traffic zwischen diesen Subnetzten. Ob man soweit gehen möchte, hĂ€ngt natĂŒlich einerseits davon ab, wieviel Aufwand man bereit ist zu betreiben, und andererseits wie paranoid man ist UFW anschalten auf der NCP-Box kostet aber nichts und du kannst deine zusĂ€tzlichen Blockregeln auch damit hinzufĂŒgen.
Ich habe UFW nun aktiviert. Meine Regel aus der rc.local ist noch enthalten, wobei die Ausgabe von iptabeles -S erheblich lÀnger ist.
Ich betreibe die NC hinter einem Router und lasse den Domainnamen ĂŒber einen Provider darauf verweisen. Vor der NC hatte ich Jahre einen anderen Server aktiv und immer mit externen Angriffen zu tun. Die gleichen VerdĂ€chtigen kommen jetzt wieder
Mit fail2ban und UFW fĂŒhle ich mich schon sicherer. Ev. ziehe ich aber mit dem System territorial um und werde dann am neuen Standort die Sicherheit neu planen mĂŒssen. Segmentierung werde ich sicherlich nicht machen, denke im lokalen Netz alles im Griff zu haben.
Die Frage ist halt, ob die Regel noch greift bzw. vollstĂ€ndig greift. Wenn iptables zuerst die UFW-Regeln abarbeitet, und ich befĂŒrchte, dass es sich so verhĂ€lt, werden die geblockten IP-Adressen allenfalls wieder Zugriff haben. Allerdings nur noch auf Port 80 und 443 und nicht mehr auf alle Ports.
Spezifische Blockregeln mĂŒssen vor weniger spezifischen Allow Regeln stehen, ansonsten werden sie ignoriert.
Wenn am Anfang der Chain eine Regel steht, die von ĂŒberall her Zugriff auf einen bestimmten Port erlaubt, wirkt die Blockregel fĂŒr einen bestimmten IP-Bereich danach nicht mehr. Diese Blockregel muss vor der allgemeineren Allow-Regel stehen, damit sie wirkt. Ich hoffe ich habe mich halbwegs verstĂ€ndlich ausgedrĂŒckt
Jup sieht gut aus, soweit ich das beurteilen kann. Die Blockregel steht am Anfang der INPUT-Chain. Ich persönlich wĂŒrde, um unerwartete Wechselwirkungen auszuschliessen und der Einfachheit halber, die Blockregeln trotzdem auch mit UFW zu managen. Wenn es aber fĂŒr dich so funktioniert, ist alles gut
Den Zusatz âprotoâ brauchst du nur, wenn du das Protokoll spezifzieren möchtest. Mit deinem Beispiel wĂŒrdest du nur TCP-Verbindungen blocken, Ping (ICMP), UDP usw. wĂ€re immer noch erlaubt. Wenn du jeglichen Traffic von diesem IP-Range blocken möchtest, kannst du das âproto tcpâ einfach weglassen und der Befehl wĂŒrde dann folgendermassen ausschauen: ufw deny from 84.3.0.0/16
Die Wiki-Seite von Ubuntu gibt ĂŒbrigens einen netten Ăberblick ĂŒber UFW, leider nur in Englisch.
Und wenn du eine Blockregel wie in deinem Beispiel hinzufĂŒgen willst, aber schon allgemeinere ALLOW Regeln vorhanden sind, sollte die DENY-Regel wie bei iptables vor diesen ALLOW Regeln stehen. Sprich du solltest sie mit folgendem Befehl hinzufĂŒgen:
sudo ufw insert 1 deny from 84.3.0.0/16
Das fĂŒgt die Regel auf Position 1 der Chain ein und die bestehenden Regeln rutschen um eine Position herunter. Mit dem gleichen Befehl und der entsprechenden Nummer, kannst du auch neue Regeln zwischen schon bestehende Regeln einfĂŒgen.
Ich habe meine rc.local wieder bereinigt und die Regel ĂŒber ufw ĂŒbernommen. Sie steht jetzt an Stelle 1. In der Ăbersicht finde ich aber auch folgende Regel:
[ 8] 2049 ALLOW IN Anywhere [14] 2049 (v6) ALLOW IN Anywhere (v6)
Der Port sagt mir nichts. Gelöscht ist es schnell. Nach Recherchen wird 2049 aber von NC nicht genutzt.
Port 2049 ist reserviert fĂŒr NFS. Greifst du via NFS auf das Dateissystem deines Servers zu? Wenn nicht kannst du soviel ich weiss den NFS-Dienst im NCP-Admin Interface deaktivieren. Falls die Regel danach immer noch drinn sein sollte, kannst du sie mit sudo ufw delete 8 bzw. sudo ufw delete 14 löschen
bevor hier jemand an Mallorca denkt, nein ich bin beruflich noch weiter im SĂŒden am Atlantik. RegelmĂ€Ăig kontrolliere ich die NC und stelle jetzt fast tĂ€glich Warnungen fest:
Vor Wochen noch vereinzelt, nun tĂ€glich 1 - 3 mal. Die IP ist immer eine andere und somit lohnt es sich nicht per ufw diese zu blocken. Die Konstanz ist mehr der Name 8hYTSUFk, der unregelmĂ€Ăig bei den Stellen nur in der GroĂ- und Kleinschreibung variiert.
Sind davon auch weitere NC Beteiber betroffen und was kann man dagegen machen?
Ich kann dazu nur sagen, dass sobald ein Dienst im Internet steht, man mit Login Versuchen rechnen muss. Wenn du das komplett verhindern willst, musst du ein VPN fĂŒr den Zugriff von aussen nutzen.
Die IP in deinem Post gehört zu Digital Ocean. Ich nehme an, da hat sich ein angehnder Hobbyhacker einen VPS bei denen geholt und darauf mal ein paar Scripts und Tools installiert, mit denenen er sich nun Random in irgendwelche Dienste einzuloggen versucht.
Fail2ban macht das ja automatisch fĂŒr dich. Einfach die Bantime massiv erhöhen oder sogar auf unendlich einstellen bantime = -1. Dann hast du zumindest nicht mehrfach die gleiche IP in den Logs.
Du kannst natĂŒrlich auch ganze IP-Ranges und Regionen in UFW blocken, wenn es dich ruhiger schlafen lĂ€sst. Aber wie gesagt: Loginversuche 100% verhindern wirst du nicht können, solange ein Dienst direkt aus dem Internet erreichbar ist. Und solange es Login-Versuche bleiben, ist ja alles im grĂŒnen Bereich.
