Raspi mit UFW absichern... Anfängerfrage

[SeniorY]

Hallo,

folgendes Setup:
Raspi hängt an der Fritzbox. Verwaltet wird über SSH (Debian Bullseye).
Installiert sind Pi Hole, Unbound und Wireguard VPN

Da der Raspi von aussen ansich ja nicht erreichbar ist und ich mich SSH Keys anmelde, sollte das ja ziemlich safe sein.
Für den VPN hab ich eine Portweiterleitung eingerichtet. Vielleicht lohnt sich hier eine Firewall.

Da zusätzliche Sicherheit nicht schaden kann, hab ich mal versucht den Raspi mit der UFW weiter abzusichern, bin mir aber nicht sicher, ob das so korrekt ist und würde da gern mal ein paar Augen drüber schauen lassen...

Folgende Befehle habe ich ausgeführt

sudo ufw allow 22
sudo ufw default deny incoming sudo ufw default allow outgoing

aus der Pi Hole Dokumentation:
sudo ufw allow 80/tcp sudo ufw allow 53/tcp sudo ufw allow 53/udp sudo ufw allow 67/tcp sudo ufw allow 67/udp

für unbound:
sudo ufw allow 5335/tcp

für Wireguard VPN (als Beispiel Portweiterleitung auf 1198)
sudo ufw allow out 1198/udp sudo ufw allow in 1198/udp

dann:
sudo ufw enable

Das scheint so weit zu funktionieren. Hab ich vielleicht noch etwas übersehen?

 

[GrumpyCat]

Da zusätzliche Sicherheit nicht schaden kann

Naja, wenn Du als "zusätzliche Dinge" dann Sachen machst, die Du nicht (ganz) verstehst, kann das durchaus schaden.

Zum Thema: wenn die Kiste eh nur per SSH erreichbar sein soll, brauchst Du auch keine anderen eingehenden Ports freigeben, also auch nicht Port 80 und Konsorten.

Ich persönlich würde mir UFW sparen und lieber per netstat -lp sicherstellen, dass keine unnötigen Dienste laufen. Fertig.

 

[Yuuri]

Da zusätzliche Sicherheit nicht schaden kann, hab ich mal versucht den Raspi mit der UFW weiter abzusichern, bin mir aber nicht sicher, ob das so korrekt ist und würde da gern mal ein paar Augen drüber schauen lassen...

Läufst du auch daheim mit ner Maske rum? Vor wem willst du dich absichern? Du "schützt" dich nur selbst im eigenen Netzwerk. Dein Router leitet bereits alles nicht weiter, was nicht freigegeben ist, weshalb willst du dann zusätzliche Ports sperren, wo sowieso kein Traffic rein kommt, außer von deinem eigenen Netzwerk?

 

[SeniorY]

habs kapiert. Tschuldigung, dass ich gefragt habe

 

[GrumpyCat]

Du "schützt" dich nur selbst im eigenen Netzwerk.

Es gibt haufenweise Angriffe, die von eigenen Rechnern ausgehen können. Dazu müssen sie noch nichtmal gehackt werden. Z.B. via CSRF kann jede Website, die Du besuchst, auch einfache HTTP-Anfragen an interne Rechner abschicken. So manche WLAN-Steckdose ließe sich so im Prinzip von jeder Website, die Du besuchst, steuern.

 

[Yuuri]

Tschuldigung, dass ich gefragt habe

Musst dich dafür nicht entschuldigen. So lange du es verstanden hast und nachvollziehen kannst, ist doch alles ok. War halt nur unnütze Arbeit deinerseits.

Es gibt haufenweise Angriffe, die von eigenen Rechnern ausgehen können.

Klar gibts die. Aber wenn es bereits im eigenen Netzwerk ist, hab ich ganz andere Probleme als nen Pi, der DNS auflöst. Und Geräte im eigenen Netzwerk haben sowieso Zugriff auf das Gerät. Sonst könntest du gar nicht mehr zugreifen. Außer du machst das über ein bestimmtes Terminal, welches nur Zugriff darauf hat. Das bringt dir halt bloß bei DNS nichts.

Z.B. via CSRF kann jede Website, die Du besuchst, auch einfache HTTP-Anfragen an interne Rechner abschicken.

Es ist aber die Anwendung angreifbar, nicht das Gerät. Es bringt also nichts, wenn er den Pi absichert, aber dann eine Anwendung drauf laufen lässt, die weiterhin angreifbar ist. Und da er die Anwendung nutzen will, muss der Port geöffnet werden, wodurch die Anwendung wieder angreifbar wird. Da hilft es nicht Ports o.ä. zu sperren. Da auch der Request von deinem PC ausgeht, hilft ihm auch keine Firewall etwas, da diese nicht unterscheiden kann, von wo der Request eigentlich ausgelöst wurde.

So manche WLAN-Steckdose ließe sich so im Prinzip von jeder Website, die Du besuchst, steuern.

Und das können sie weiterhin, so lange ich auch von meinem PC drauf zugreifen kann/will. Da hilft es nichts Ports zu sperren oder sonstige Tricks, denn der Request wird immer von deinem PC aus kommen und dieser wird wohl immer in der Whitelist irgendwo stehen, da du ja auch Zugriff haben willst.

CSRF ist hierbei ein komplett anderer Angriffsvektor, wo sich nur die Anwendung selbst schützen kann. SQL-Injections sind auch im eigenen Netzwerk möglich. Ist aber auch ein komplett anderer Fall und hat nichts mit der Firewall zu tun.

Mal spontan gefragt: Wie sähe deine Empfehlung für den TE aus, wenn du CSRF in Betracht ziehst?

 

[SeniorY]

wie sieht es denn mit der Portweiterleitung für den VPN aus? Auch da bringt UFW keine erhöhte Sicherheit? Hab da in dem Zusammenhang von Kill Switch gelesen, falls die VPN Verbindung abbricht oä.?

 

[GrumpyCat]

Es ist aber die Anwendung angreifbar, nicht das Gerät.

Ja klar. Ich wollte nur die Luft aus dem Argument von Dir lassen, dass man keine Sorge vor "von innen" kommenden Angriffen haben muss (also falls ich das richtig verstanden habe). Auch im LAN/intern sollten alle Rechner gesichert sein, am besten, indem man a) keine unnötigen Dienste laufenlässt, b) laufende Dienste sichert (also z.B. keine passwortlosen Samba-Shares benutzt und alles natürlich über verschlüsselte Verbindungen benutzt), c) alle Software aktuell hält.

Bei den WLAN-Steckdosen hilft es zum Beispiel, ein Passwort zu setzen.

Ergänzung (15. Oktober 2021)

wie sieht es denn mit der Portweiterleitung für den VPN aus? Auch da bringt UFW keine erhöhte Sicherheit?

Nö. Wenn Du einen Dienst installierst, der Port X braucht, und den dann in der Firewall freischaltest, was soll die Firewall dann an Sicherheit beitragen?

Zu Windows-Zeiten hat man das gerne gemacht, weil Windows früher haufenweise kaputte Dienste nach außen angeboten hat. Und statt das in Ordnung zu bringen, hat man halt in Form der Firewall Folie um das löchrige Sieb gemacht. Solche Hacks braucht man nicht mehr und hat man unter Linux nie gebraucht.

Hab da in dem Zusammenhang von Kill Switch gelesen, falls die VPN Verbindung abbricht oä.?

Leider keine Ahnung, was Du meinst. Stell mal die Frage genauer.

 

[Yuuri]

wie sieht es denn mit der Portweiterleitung für den VPN aus? Auch da bringt UFW keine erhöhte Sicherheit?

Der Port wird halt weitergeleitet und auf dem Pi läuft ein Dienst dafür. Die UFW ist lediglich ein Frontend für iptables. Und eine Firewall entscheidet nur, ob die Verbindung zugelassen wird oder nicht. Also entweder die Verbindung ist offen oder nicht, eine "erhöhte" Sicherheit gibts da nicht. An oder aus. Sicherheit bekommst du nur, wenn kein Daemon auf dem Port lauscht - aber dann brauchst du ergo auch keine Freigabe.

Hab da in dem Zusammenhang von Kill Switch gelesen, falls die VPN Verbindung abbricht oä.?

Sagt mir nix. Meinst du fail2ban? Damit kann man via iptables dynamisch auf Ereignisse reagieren und bspw. nach mehreren fehlerhaften Loginversuchen die Source IP für Zeitraum x bannen. Das macht aber wie gesagt nicht UFW, sondern ein externes Tool, welches mit iptables die Firewallregeln setzt (ist also Mittel zum Zweck).

Aber wieso Kill Switch beim Abbruch? Dann kommst du bei nem Disconnect nicht mehr rein, da der Port zu ist. Meinst du ggf. Port Knocking? Das braucht auch wieder ein externes Tool. Port Knocking ist aber auch mehr nur Security through Obscurity. Wenn du die Knock-Sequenz mitschneiden kannst, liegt der Daemon genauso frei. Und wenn der Knock-Daemon Probleme hat, kommst du gar nicht mehr rein.

Wenn der Daemon dahinter sicher ist, dann kannst du drauf los feuern wie du lustig bist. Kannst halt mit fail2ban bestimmte Policies umsetzen, dass nach x gescheiterten Logins eben die Source IP gebannt wird, damit du Bruteforcing im Keim erstickst, bspw. auch durch ne gestaffelte Sperrzeit.

• 3 fehlgeschlagene Logins = 5 Minuten Sperre
• 6 fehlgeschlagene Logins = 30 Minuten Sperre
• 10 fehlgeschlagene Logins = 60 Minuten Sperre
• usw.

Machen ordentliche Authentifizierungssysteme ja bereits so. Du kannst aber natürlich auch stumpf für drei fehlgeschlagene Logins 15 Minuten Sperre umsetzen. Das reicht als simples System natürlich auch bereits aus.

Port Knocking ist nicht mehr als ein Klopfzeichen wie im Mittelalter und verzögert höchstens den Einbruch. Ganz nette Idee, aber eigentlich sinnfrei (Security through Obscurity eben). Stell also lieber sicher, dass das Gebäude (der Pi) und das Schloss (der Daemon) einbruchsicher sind, dann kannst du klopfen wie du lustig bist und versuchen aufzubrechen bis dein Werkzeug kaputt geht - du kommst nicht rein. Das heißt eben Sicherheitsupdates für OS, Libs und Tools einspielen. Bei 0-Days hast du natürlich ein Problem, aber wie gesagt verzögert Port Knocking den Einbruch nur und hält ihn nicht auf.

Gleiches Schauspiel würdest du erhalten, wenn du ne Webseite o.ä. hast und in dieser die Zugriffe regelst. Intern kann das Tool genauso wie bspw. knockd die Verbindung von deiner externen IP aufs VPN zulassen (mittels iptables also nur die Verbindung deiner IP auf den Port erlauben). Aber dann musst du vor jedem möglichen Connect immer auf die Seite und den Zugriff whitelisten, genauso wie du bei Port Knocking immer einen bestimmten Prozess Folge leisten musst.

Ich wollte nur die Luft aus dem Argument von Dir lassen, dass man keine Sorge vor "von innen" kommenden Angriffen haben muss (also falls ich das richtig verstanden habe).

Der Angriff kommt aber nicht von "innen", sondern von außen und wird nur lokal relayed. Don't kill the messenger.

Bei den WLAN-Steckdosen hilft es zum Beispiel, ein Passwort zu setzen.

Wichtig ist, dass du eine aktive (authentifizierte) Session besitzt - ob das mittels Passwort oder sonstigem geschieht ist hierbei irrelevant. Und dann helfen nur bspw. CSRF Tokens in der Anwendung.

 

[SeniorY]

vielen Dank für die ausführliche Erklärung. Mir ist jetzt einiges klarer geworden.

Mit dem Kill Switch war ich wohl auch auf falscher Fährte, da es sich eher auf den Client bezieht und nicht auf den Server, der den VPN stellt…

https://www.codeproject.com/Articles/1266552/Create-a-VPN-killswitch-with-UFW