Absichern von PiVPN @ Debian 10 @ proxmox

[nonharderware]

Hallo,

ich habe auf meinem Heimserver unter Proxmox mehrere VMs / Container laufen.
Habe mir dort auf einer Debian 10 VM PiVPN eingerichtet, damit ich unterwegs per wireguard nach Hause komme.

Diese VM ist natürlich von außen (portforwarding) für wireguard erreichbar.
Habe fail2ban (3 Versuche, lange bantime), unattended-upgrades und SSH (no root login) konfiguriert.

Was wäre noch an Maßnahmen zwecks Absicherung zu treffen?
Danke für eure Hilfe vorab!

[Mond]

Sicherheit ist ja nicht OK/NOK, sondern verläuft Stufenweise. Man kann natürlich noch mehr Maßnahmen ergreifen, aber das muss immer jeder für sich wissen und im Verhältnis stehen zu dem, was man sichert. Ich wäre damit zufrieden.

[konkretor]

So lange du nur den Wireguard Port nach außen hin offen hast gibts wenig zu "befürchten".

Der Rest hast du ja schon zugenagelt, würde halt den SSH Login nur über Schlüssel zu lassen.
Du kannst dir auch noch einrichten das du eine E-Mail geschickt bekommst sollte sich wer per SSH einloggen. SSH kannst auch begrenzen auf bestimmte IP Adressen.


Du kannst auch einen zweiten Faktor für den SSH Login einrichten.

[lumines]

Wenn du fail2ban benutzt, dann hast du wahrscheinlich Passwortauthentisierung für SSH an. Statt fail2ban solltest du wahrscheinlich besser auf Public-Key-Authentisierung umsteigen. Es ist einfacher zu handhaben, weil du Brute-Force-Angriffe so komplett ignorieren kannst und dadurch deine Konfiguration simpler wird.

Wie benutzt du unattended-upgrades? Wenn du die Updates zwar regelmäßig einspielst, aber die betroffenen Prozesse nicht neu startest, dann laufen die betroffenen Prozesse weiter mit den Sicherheitslücken. Eventuell kann man unattended-upgrades mit einem Neustart der Prozesse kombinieren, aber spätestens bei einem Kernel-Upgrade oder einem Upgrade der libc kommst du um einen Neustart nicht herum.

Ich würde die unattended-upgrades mit einem Reboot kombinieren. Z.B. könntest du einmal wöchentlich den Server nachts neu starten.

[nonharderware]

Thema Reboot:

Server werden bei mir immer nachts täglich rebootet.

[vanquish]

Je nachdem wie oft du das System "beäugst" würde ich unattended-upgrades auf security fixes beschränken. Wenn Du die empfohlenen oder gar alle Pakete automatisch aktualisierst kommt es früher oder später zu Problemen. Hängt aber davon ab wieviele Programme du tatsächlich konfigurierst und nutzt.

Fail2Ban ist zwar nett. Aber ich würde bevorzugt mindestens eine e-Mail für jeden erfolgreichen Shell-Login haben wollen (man weiss nie welche Sicherheitslücke, Fehlkonfiguration, Social-engineering gerade zuschlägt) und mit IPset alle gängigen "bösen" IPs von vornherein blocken (russisch und chinesisch) um die Logs (wenn man sie überhaupt liest) übersichtlich zu halten. Allerdings sollten sich die Angriffe in Grenzen halten. Der Server steht ja in keinem bekannten Rechenzentrum.
https://www.ipdeny.com/ipblocks/
Keine Angst entsprechende Skripts (nur ein paar Zeilen) findet man leicht über die WWW-Suche.
Mit DShield dem Netzwerk vorgeschaltet könnte man sogar "live" IP-blocking betreiben. Privat hier zu Hause habe ich IPset auf dem Router direkt laufen und blockiere cn, ir, iq und ru (src only).

SSH key auth ist zwar sicherer es kommt aber auf den Anwendungsfall an. Will man "schnell" von einem fremden Gerät auf den Server zugreifen hat man ein Problem (wenn man die Keys nicht mit sich führt). Sofern man den root Login nicht zulässt (was Standard sein sollte) muss der potentielle Angreifer den richtigen Benutzernamen und das richtige Passwort erraten. Was ausreichend ist, wenn man nicht gerade admin/1234567 benutzt.

[lumines]

Allerdings sollten sich die Angriffe in Grenzen halten. Der Server steht ja in keinem bekannten Rechenzentrum.

Die allermeisten Bots grasen einfach den gesamten IPv4-Adressraum ab.

SSH key auth ist zwar sicherer es kommt aber auf den Anwendungsfall an. Will man "schnell" von einem fremden Gerät auf den Server zugreifen hat man ein Problem (wenn man die Keys nicht mit sich führt).

Es gibt auch gute SSH-Clients für iOS und Android. Alle unterstützen auch Public-Key-Authentifizierung (jedenfalls kenne ich keinen ohne).

Wie managest du denn die Passwörter? Wenn du nur einen Rechner hast, dann lässt sich das vielleicht noch bewerkstelligen, aber der TE nutzt ja proxmox. Da wird nicht nur eine VM drauf laufen. Spätestens da wird eine Passwortauthentifizierung schon relativ unhandlich. Wenn einige der VMs vielleicht auch nur kurzlebig für z.B. kleinere Tests sind, dann hat man plötzlich ein Problem. Mit Public-Key-Autentifizierung ist das dagegen trivial. Man kopiert (vielleicht sogar einfach automatisch) alle seine Public-Keys entweder bei der Installation oder kurz danach auf den Server / VM und muss sich keine Gedanken mehr darüber machen.

[vanquish]

Die allermeisten Bots grasen einfach den gesamten IPv4-Adressraum ab.

Nun ich sehe schon einen Unterschied zwischen Rechenzentrum und zu Hause. Mein ISP filtert da einiges weg das ich auf meinem gemieteten VServer schon sehe. Und selbst dort gibt es Unterschiede. In der Vergangenheit hatte ich das "Vergnügen" kleinere, bei verschiedenen Anbietern gemietete, Root-Server zu warten. Die Ban-list auf den jeweiligen Servern war bei einigen um ein vielfaches höher oder eben auch niedriger.
Ich stelle mir das heutzutage sogar zielgerichteter vor als früher. In den privaten Netzen der großen ISP werden primär die Router der Endnutzer selbst angegriffen und zu Botnetzen umfunktioniert und nicht irgendein offener SSH Zugang hinter dem Router. Aber mangels Erfahrung kann ich dazu nichts mehr aktuelles beitragen.


Es gibt auch gute SSH-Clients für iOS und Android. Alle unterstützen auch Public-Key-Authentifizierung (jedenfalls kenne ich keinen ohne).

Wie managest du denn die Passwörter? Wenn du nur einen Rechner hast, dann lässt sich das vielleicht noch bewerkstelligen, aber der TE nutzt ja proxmox. Da wird nicht nur eine VM drauf laufen. Spätestens da wird eine Passwortauthentifizierung schon relativ unhandlich. Wenn einige der VMs vielleicht auch nur kurzlebig für z.B. kleinere Tests sind, dann hat man plötzlich ein Problem. Mit Public-Key-Autentifizierung ist das dagegen trivial. Man kopiert (vielleicht sogar einfach automatisch) alle seine Public-Keys entweder bei der Installation oder kurz danach auf den Server / VM und muss sich keine Gedanken mehr darüber machen.

Für das private Umfeld wäre mir das zu umständlich. Persönlich nutze ich Keepass (aes crypted + HW-Key-Token + password). Die DB kann ich in der Cloud speichern und jederzeit auf dem Smartphone abspeichern/abrufen und das Login/Passwort an jedem beliebigen Rechner nutzen. Den SSH-Key müsste ich erst kopieren um ihn auf einem produktiven System nutzen zu können. Unter Windows muss ich mir den SSH-Client (seit Win10) oder Putty erst installieren. Putty wiederum braucht kompatible Keys (also ein zweiter Key extra für Putty).

Im Firmenumfeld vor ~15 Jahren hatte man wen ein Key gewünscht war einen Key und generiertes Passwort. Aber verschiedene Admins. Was im Grunde nicht praktikabel war. Also paralell Login+PW. Heutzutage stelle ich mir das nicht leichter vor. Die Keys der Admins wie Lutschbonbons auf allen Server zu verteilen und ggf. löschen (wird bestimmt gemacht) halte ich für gefährlich. Login mit PW und regelmässiges ändern des PWs wird denke noch immer an der Tagesordnung sein. Vielleicht organisiert man das auch heute besser als früher und die Admins sind fixer auf bestimmte Systeme verteilt.

Im Grunde würde ich pers. ein SSH Auth mit einem Hardware Key Token bevorzugen. Aber die Nutzung ist noch immer zu umständlich und die Implementierung auf dem jeweiligen Systemen immer noch zu aufwendig. Unter Windows kann ich meinen Yubikey z. B. noch immer nicht für den Cloudlogin nutzen. Zuletzt vor ca. einem Jahr probiert.

Unter Linux nutze ich jetzt seit ca. einem Jahr meinen Yubikey zum Booten/entschlüsseln. Aber SSH Login mit HW Key ist mir pers. noch immer zu aufwendig zu installieren. Auch die Authentifizierung am Desktop System via PAM in Verbindung mit einem "Mischsystem" aus KDE und Gnome ist im Grunde "ekelhaft".

Die Keys sind zwar populär in Verbindung mit Accounts wie z. B. Github, Google, Steam, etc. Aber zu mehr reichts leider immer noch nicht. Mir kommt es so vor als ob das Ganze bei den "Authenticatern" stehen bleibt und der das Potential verschenkt wird.

[lumines]

Nun ich sehe schon einen Unterschied zwischen Rechenzentrum und zu Hause. Mein ISP filtert da einiges weg das ich auf meinem gemieteten VServer schon sehe. Und selbst dort gibt es Unterschiede. In der Vergangenheit hatte ich das "Vergnügen" kleinere, bei verschiedenen Anbietern gemietete, Root-Server zu warten. Die Ban-list auf den jeweiligen Servern war bei einigen um ein vielfaches höher oder eben auch niedriger.
Ich stelle mir das heutzutage sogar zielgerichteter vor als früher. In den privaten Netzen der großen ISP werden primär die Router der Endnutzer selbst angegriffen und zu Botnetzen umfunktioniert und nicht irgendein offener SSH Zugang hinter dem Router. Aber mangels Erfahrung kann ich dazu nichts mehr aktuelles beitragen.

Mein ISP filtert scheinbar weniger. Die Menge der Anfragen auf Port 22 auf meinen Severn und an meinem Heimanschluss sind vom Volumen her sehr ähnlich.

Den SSH-Key müsste ich erst kopieren um ihn auf einem produktiven System nutzen zu können.

Vielleicht verstehe ich dich hier auch falsch, aber meinst du mit "erst kopieren" den Private Key auf einen anderen Rechner zu kopieren? Das ist eigentlich nicht Sinn der Sache und negiert fast alle Sicherheits- und Komfortvorteile.

Man erzeugt eigentlich mindestens ein Schlüsselpaar pro Rechner (je nach Einsatzzweck kann es auch Sinn machen noch einmal pro Dienst ein Schlüsselpaar zu erstellen, aber das ist für private Nutzung eventuell zu aufwendig) und verteilt nur die Public Keys. Der Private Key sollte niemals den jeweiligen Rechner verlassen.

Im Firmenumfeld vor ~15 Jahren hatte man wen ein Key gewünscht war einen Key und generiertes Passwort. Aber verschiedene Admins. Was im Grunde nicht praktikabel war. Also paralell Login+PW.

Wenn es mehrere Admins gab, dann hätte jeder Admin ein Schlüsselpaar erzeugen müssen und die Public Keys wären entsprechend verteilt worden. Parallel dazu hätte es ein Konzept zum Rotieren der Schlüssel geben müssen.

Ich weiß, dass viele Unternehmen Public-Key-Authentifizierung nicht verstehen und deshalb oft etwas krude Lösungen benutzt werden, aber das sind ja keine Limitierungen der Technologie.

Heutzutage stelle ich mir das nicht leichter vor. Die Keys der Admins wie Lutschbonbons auf allen Server zu verteilen und ggf. löschen (wird bestimmt gemacht) halte ich für gefährlich. Login mit PW und regelmässiges ändern des PWs wird denke noch immer an der Tagesordnung sein. Vielleicht organisiert man das auch heute besser als früher und die Admins sind fixer auf bestimmte Systeme verteilt.

Public-Key-Authentifizierung ist praktisch die Voraussetzung für ein sinnvolles Konfigurationsmanagement, was man definitiv haben will. Und ja, natürlich muss man die Keys verteilen. Man kommt um ein Konzept zum Verteilen, Rotieren und Absichern der Keys nicht herum.

Im Grunde würde ich pers. ein SSH Auth mit einem Hardware Key Token bevorzugen. Aber die Nutzung ist noch immer zu umständlich und die Implementierung auf dem jeweiligen Systemen immer noch zu aufwendig. Unter Windows kann ich meinen Yubikey z. B. noch immer nicht für den Cloudlogin nutzen. Zuletzt vor ca. einem Jahr probiert.

Mach dir das Leben nicht unnötig kompliziert. Private Keys in Hardware zu generieren und zu lagern ist praktisch und bevorzuge ich auch, aber gerade wie hier im Thread für private Nutzung ist ein Schlüsselpaar pro Rechner (welches bitte nicht den Rechner verlässt) vollkommen ausreichend und sehr komfortabel. Man eröffnet sich damit auch die Möglichkeit Konfigurationsmanagement z.B. per Ansible zu nutzen. Selbst wenn man es nicht voll ausschöpft, kann es auch für kleine Tätigkeiten wie Updates ganz praktisch sein.

[vanquish]

Vielleicht verstehe ich dich hier auch falsch, aber meinst du mit "erst kopieren" den Private Key auf einen anderen Rechner zu kopieren? Das ist eigentlich nicht Sinn der Sache und negiert fast alle Sicherheits- und Komfortvorteile.

Man erzeugt eigentlich mindestens ein Schlüsselpaar pro Rechner (je nach Einsatzzweck kann es auch Sinn machen noch einmal pro Dienst ein Schlüsselpaar zu erstellen, aber das ist für private Nutzung eventuell zu aufwendig) und verteilt nur die Public Keys. Der Private Key sollte niemals den jeweiligen Rechner verlassen.

Naja, wenn ich von verschiedenen Systemen, die nicht oder nicht vollständig unter meiner Kontrolle stehen bzw. mir nicht gehören auf einen Server zugreifen will brauche ich meinen private Key ggf. auch auf diesem System. Dafür habe ich ja das Passwort das den Key wiederum verschlüsselt. Privat komme ich vielleich ein, zwei mal pro Jahr in die Verlegenheit über SSH kurz Nutzungsrechte anpassen zu müssen um Verwanden/Bekannten/Freunden Zugriff auf Dateien zu Hause zu gewähren.

Ich trauere noch immer ein wenig dem Login + Passwort nach. Das habe ich vor ca. drei Jahren zu Hause verbannt und muss jetzt mit den Keys leben.

Ich weiss nicht wie es heutzutage organisiert wird. Das war Schichtdienst. Das was kommt wird bearbeitet. Sprich ich muss von jedem Client auf das jeweilige System zugreifen können. Jetzt kann ich entweder alle meine Keys zu den authorized_keys auf dem Server hinzufügen oder ich nehme einen einzigen Key für alles. Letzteres ist einfacher. In jedem Fall habe ich einen riesen Aufwand wenn ich die Keys ändern muss. Ja dazu braucht es ein Konzept. Was es damals nicht gab.

Da war es einfacher den Key vom Server zu nehmen und dem Key den entsprechenden Dateinamen (Kundennummer) zu geben. Nat. ohne Passwort. :freak: Ich würde fast meinen, dass Login + Passwort noch immer an der Tagesordnung bzw. die bevorzugte Methode ist. Ich weiss es aber nicht.


Ich weiß, dass viele Unternehmen Public-Key-Authentifizierung nicht verstehen und deshalb oft etwas krude Lösungen benutzt werden, aber das sind ja keine Limitierungen der Technologie.

Da stimme ich zu. Habe ich damals auch nicht. ;D


Mach dir das Leben nicht unnötig kompliziert. Private Keys in Hardware zu generieren und zu lagern ist praktisch und bevorzuge ich auch, aber gerade wie hier im Thread für private Nutzung ist ein Schlüsselpaar pro Rechner (welches bitte nicht den Rechner verlässt) vollkommen ausreichend und sehr komfortabel. Man eröffnet sich damit auch die Möglichkeit Konfigurationsmanagement z.B. per Ansible zu nutzen. Selbst wenn man es nicht voll ausschöpft, kann es auch für kleine Tätigkeiten wie Updates ganz praktisch sein.

Ja da hast Du recht. Ich habe ca. 15 "Geräte" mit SSH Zugang einschl. Raspi, Router + ein paar Dinge in VM's zum basteln. Mir ist das zu aufwendig für jedes System die Keys zu pflegen. Ich habe nur drei Keypairs für alles. Ich gebe zu, dass ich mich mit dem Thema wieder etwas mehr auseinandersetzen müsste.

[lumines]

Naja, wenn ich von verschiedenen Systemen, die nicht oder nicht vollständig unter meiner Kontrolle stehen bzw. mir nicht gehören auf einen Server zugreifen will brauche ich meinen private Key ggf. auch auf diesem System.

Ich denke mal ab da hat man sicherheitstechnisch sowieso schon verloren.

Ich weiss nicht wie es heutzutage organisiert wird. Das war Schichtdienst. Das was kommt wird bearbeitet. Sprich ich muss von jedem Client auf das jeweilige System zugreifen können. Jetzt kann ich entweder alle meine Keys zu den authorized_keys auf dem Server hinzufügen oder ich nehme einen einzigen Key für alles. Letzteres ist einfacher. In jedem Fall habe ich einen riesen Aufwand wenn ich die Keys ändern muss. Ja dazu braucht es ein Konzept. Was es damals nicht gab.

Wie gesagt, heute (eigentlich schon seit Jahren) benutzt man irgendeine Form von Konfigurationsmanagement. Der Aufwand, Keys auszutauschen, sollte damit gegen null gehen. Oder eher: Es sollte nicht schwieriger sein als eine beliebige andere Änderung vorzunehmen.

Einige Systeme wie Ansible setzen direkt auf SSH und den entsprechenden Authentifizierungsmöglichkeiten auf, andere wie Puppet ziehen eine eigene PKI auf und kommunizieren mit den Hosts per HTTPS.

Da war es einfacher den Key vom Server zu nehmen und dem Key den entsprechenden Dateinamen (Kundennummer) zu geben. Nat. ohne Passwort. :freak: Ich würde fast meinen, dass Login + Passwort noch immer an der Tagesordnung bzw. die bevorzugte Methode ist. Ich weiss es aber nicht.

Sobald man den schweren Compliance-Hammer über dem Kopf schweben hat, wird Passwortauthentifizierung eigentlich nicht so gerne gesehen.

Ja da hast Du recht. Ich habe ca. 15 "Geräte" mit SSH Zugang einschl. Raspi, Router + ein paar Dinge in VM's zum basteln. Mir ist das zu aufwendig für jedes System die Keys zu pflegen. Ich habe nur drei Keypairs für alles. Ich gebe zu, dass ich mich mit dem Thema wieder etwas mehr auseinandersetzen müsste.

Na ja, die Low-Tech-Variante wäre wohl für jeden Rechner ein eigenes Schlüsselpaar zu erstellen, die Public Keys alle in einer Textdatei in einem Git-Repo zu sammeln und dort zusätzlich eine Liste aller deiner Geräte mit SSH-Zugang zu pflegen. Dann iterierst du einfach über die Liste und verteilst die Public-Keys auf jeden Host per rsync --delete, ssh-copy oder was auch immer. Wenn sich etwas ändert, entfernst oder fügst du einen Key hinzu und gleichst die authorized_keys erneut ab.

Die zweite Möglichkeit wäre eben so etwas wie Ansible zu nutzen, was im Grunde nichts anderes macht und eben nur ein paar weitere Konventionen einführt und das alles etwas deklarativer macht.

[vanquish]

Ich denke mal ab da hat man sicherheitstechnisch sowieso schon verloren.

Ja ich weiß. Heute wird das alles Remote gemacht oder die Workstations werden einfach gleich ganz ausgetauscht. "Früher" war das etwas anders beim Kunden vor Ort. Der Telefonsupport war da auch noch anders als heute wo der Supporter direkt auf die Rechner zugreift. :D

Die zweite Möglichkeit wäre eben so etwas wie Ansible zu nutzen, was im Grunde nichts anderes macht und eben nur ein paar weitere Konventionen einführt und das alles etwas deklarativer macht.

Ich werde mir das bei Gelegenheit auf jeden Fall einmal ansehen und versuchen umzusetzen. Vielen Dank für den Input.

[Clubbi]

Alternativ könntest du auch mal Lynis drüber laufen lassen:
https://github.com/CISOfy/Lynis