Das kennen wir von der Fritze wa, jetzt darf man mehr als normal machen.
Also, was wollen wir machen ?
Wir haben eine Situation im Netzwerk, wo unser DSL ausgefallen ist, wir via LTE eine Ausfallsicherheit eingerichtet haben, aber nun wegen der vom Provider vergebenen „privaten“ IP-Adresse nicht mehr via DynDNS ins Netzwerk kommen.
Jetzt gehen wir mal als erstes zum Chef und lassen uns ca. 20€ im Monat für einen dedizierten Rootserver bei einem deutschen Hoster genehmigen.
Ab 20€ bekommt man einen kleinen Server, ob die Leistung für Dich ausreichend ist, musst Du selber entscheiden. Generell ist bei einem VPN-Server die Frage eher nach der Anbindung ans Netz, nicht nach der CPU-Leistung oder der Festplattengröße/geschwindigkeit. Für die angesagten 20€ gibt es in der Regel „nur“ 100Mbit, eine Gigabit Anbindung kostet extra. Ob Du das brauchst hängt ganz von Deinen Anwendungen und den Geschwindigkeiten Deiner angebundenen Clients ab.
Dann buchen wir den, spielen dort wieder unser Debian10 auf, sichern ihn ab und richten dort einen openvpnServer ein. Das alles können wir ja schon. Im Zweifel springen wir hier einfach wieder zum Anfang zurück und fangen beim Einrichten eines Gateways an. Das mit der CD können wir natürlich vergessen, das initiale Einspielen eines Betriebssystems erledigt der Hoster für uns nach unserer Auswahl. Und Debian10 sollte zur Auswahl stehen….
Und was soll das bringen?
Nun, dieser Server hat eine feste IP-Adresse und ist sowohl via DSL, als auch via LTE einfach erreichbar. Und schon ist unser Büro für das HomeOffice erreichbar, auch wenn DSL ausfällt. Denn HomeOffice verbindet sich jetzt mit dem neuen Server und wird von dort ins Büro geroutet. Und Büro ist sowieso immer mit dem neuen Server verbunden.
Aber fangen wir das mal ganz von vorne an, wieder mit einem netten Plan:
Das ist jetzt eine vereinfachte Darstellung unserer Situation, unser gateway.erstes.netz checkt regelmässig die Verfügbarkeit des DSL am „plaste.router“ und schaltet bei DSL Ausfall auf den „plasteLTE.router“ um.
Dabei stellt jetzt gateway.erstes.netz keinen openvpn-Server mehr bereit, sondern verbindet sich als openvpn-Client mit unserem neuen Server im Internet. Und damit spielt es keine Rolle mehr ob die DSL- oder die LTE-Anbindung aktiv ist.
Auf der anderen Seite verbindet sich auch der Home.Office Rechner als openvpn-Client mit dem Server.
Es liegt nun alleine an der Serverkonfiguration wer und was erreichbar ist.
Um das ganze in seiner Komplexität mit allen Regeln und Routen zu veranschaulichen, blasen wir das Beispiel mal gleich ein bisschen auf:
Wir machen aus unserem erstes.netz unsere Zentrale ( zen ), dort laufen alle Serverdienste für den Büroalltag.
Dazu machen wir zwei Filialen auf, Filiale1 ( fi1 ) und Filiale2 (fi2 ), beide sind ebenfalls dauerhaft mit dem Server verbunden.
Drei Home.Office ( ho1, ho2, ho3 ) Mitarbeiter haben von uns einen abgesicherten ( extra AdministratorKonto/verschlüsselte Festplatte ) Laptop mit VPN-Zugang bekommen und wählen sich bei Bedarf ein. Alle Drei haben individuelle Zugangsberechtigungen.
Und jetzt wird ganz schnell klar, wann ohne Plan wirklich nix mehr geht:
Was jetzt?
Ist das überhaupt noch zeitgemäß? Heutzutage muss doch alles in die Cloud!
Tja, wieder Deine Entscheidung. Ich denke, die Frage nach der Cloud sollte sich jeder stellen der mehr als einen „Serverraum“ betreibt. Dabei ist aber nicht nur der Kostenfaktor infrage zu stellen, auch alle Sicherheitsaspekte müssen berücksichtigt werden.
Und das alles soll und kann hier kein Thema sein.
Wir haben angefangen unser privates Heim abzusichern und wollen nun einen zweiten Standort via LTE einbinden. Das Beispiel hier wird trotzdem aufgeblasen, auch wenn es vielleicht nicht mehr zeitgemäß ist. Also;
Ohne eine Liste der vergebenen IP-Adressbereiche verliert man ganz schnell den Überblick und jede Chance eine saubere Routingtabelle hinzubekommen. Was fällt als erstes auf?
SSHKnock
OK, das meinte ich zwar nicht, aber ja!
Meine Antzwort wäre jetzt…Jeder Adressbereich darf nur einmal vorkommen!
Aber ok, SSHKnock.
Unser neuer Server ist direkt mit dem Internet verbunden und es würde nicht lange dauern, und die Honks würden entdecken das dort ein SSH Zugang auf Loginversuche wartet. Natürlich haben wir unseren SSH-Zugang mit SSH-key und fail2ban abgesichert, trotzdem wird es bald nerven, wenn fail2ban alle 10 Minuten eine neue Sperre melden wird.
Genau hierfür gibt uns shorewall diese nette Funktion SSHKnock.
Nur nach einem Klopfzeichen macht uns unser Server dann den SSH-Zugang auf. Dabei legen wir das Klopfzeichen UND den SSH-Port auf einen nur uns bekannten Port. Damit ist ganz schnell Ruhe im Karton.
Aber fangen wir hier nochmal von vorne an:
DIE WICHTIGEN PUNKTE UM EINEN SERVER SICHER IM NETZ ZU BETREIBEN!
1. Updates werden zeitnah eingespielt
2. Updates werden zeitnah eingespielt
3. Updates werden zeitnah eingespielt
4. Wir haben den SSH-Zugang mit einem guten SSH-Schlüssel abgesichert
5. Dieser SSH-Schlüssel liegt auf einem sicheren Rechner auf dem nur die autorisierten Administratoren Zugang haben
6. Der SSH-Port ist von Port 22 (Standard) auf einen anderen Port geändert worden. ( Hier im Beispiel auf Port 549 – damit sähe eine Anmeldung jetzt:
ssh -p 549 root@[vpnserver]
so aus )
7. Shorewall ist installiert und blockiert zunächst mal alles ausser Port 549/tcp
8. Es ist völlig klar: Wenn dieser Rechner gehackt wird, ist der Hacker direkt im gesamten Büronetz, soweit die Gateways in Zentrale/Filialen das zulassen.
Dann mal los:
Fangen wir mit SSHKnock an:
Die nötigen Aussagen finden wir diesmal direkt bei shorewall.net:
https://shorewall.org/PortKnocking.html
Wobei ich dann gleich zum Standardport 22 anmerken darf: Es ist halt sehr ungewöhnlich, einen Server im Netz ohne SSH-Zugang zu haben. Meist sind es kleine Roboter die den bösen Jungs die Arbeit abnehmen und unentwegt das Internet auf neue Opfer durchforsten. Finden die jetzt unseren neuen Server und dort ist kein SSH-Zugang auf Port 22, liegt die Vermutung nahe:
Der ist woanders oder hinter einem Klopfzeichen. Da das von Shorewall mitgebrachte Script recht simpel auf einen einfachen Ping auf einen Port reagiert, ist es auch recht simpel, ein Programm zu schreiben, das einfach jeden Port mit gehöriger Pause einmal anpingt und danach jeweils schaut ob Port 22 dann offen ist.
Gehen wir direkt auf einen beliebigen anderen freien Port, sieht die Sache gleich ganz anders aus.
Schauen wir uns das an:
/etc/ssh/sshd_config
Port 549 #AddressFamily any ListenAddress 85.xx.xx.xx unsere öffentliche IP-Adresse des VPN-Servers
Damit lauscht SSH nach einem Restart nur noch auf Port 549 auf der Schnittstelle mit der IP 85.xx
Um jetzt Shorewall das Portklopfen beizuzbringen wechseln wir zu
/etc/shorewall
und legen dort folgende Dateien an:
nano action.SSHKnock
und befüllen mit:
?begin perl
use Shorewall::Config;
use Shorewall::Chains;
my $chainref = get_action_chain;
my ( $level, $tag ) = get_action_logging;
if ( $level ) {
log_rule_limit( $level,
$chainref,
'SSHKnock',
'ACCEPT',
'',
$tag,
'add',
'-p tcp --dport 549 -m recent --rcheck --name SSH ' );
log_rule_limit( $level,
$chainref,
'SSHKnock',
'DROP',
'',
$tag,
'add',
'-p tcp ! --dport 549 ' );
}
add_rule( $chainref, '-p tcp --dport 549 -m recent --rcheck --seconds 60 --name SSH -j ACCEPT' );
add_rule( $chainref, '-p tcp --dport 11599 -m recent --name SSH --remove -j DROP' );
add_rule( $chainref, '-p tcp --dport 11600 -m recent --name SSH --set -j DROP' );
add_rule( $chainref, '-p tcp --dport 11601 -m recent --name SSH --remove -j DROP' );
1;
?end perl
Ich gehe jetzt mal nicht auf die Unterschiede zur Doku bei shorewall.net ein, Probier einfach mal beide Varianten und suche nach einer Lösung wenn Shorewall nicht startet. Wenn Du dazu keine Lust hast, nimm einfach die Lösung oben.
Was passiert hier jetzt?
Hier wird eine Regel geschrieben, die besagt:
Öffne Port 549 für 60 Sekunden wenn zuvor ein Ping ( echo request icmp ) auf Port 11600 eingeht.
Geht zuvor oder danach ein Ping auf den Ports 11599 oder 11601 ein, dann schliesse Port 549 sofort, bzw. öffne erst garnicht.
Ich würde jetzt auch den von Shorewall angegebenen Port 11600 ändern, klar oder? Also z.B. 27688, 27689, 27690.
Der böse Junge im Netz, der vermutet Du hast einen Portknock installiert, wird in 100 von 100 Fällen zuerst Port 11600 abklopfen….
Damit das auch alles so von Shorewall übernommen wird braucht es noch eine Datei
nano actions
und dort steht dann bitte nur eine einzige Zeile mit
SSHKnock
Dann kommt in die Datei
nano rules
folgende Zeilen:
# SSH Access to the Server
#
#ACCEPT net fw tcp 549
SSHKnock net fw tcp 549,11599,11600,11601
Shorewall neustarten und dann schauen ob es läuft wie gewünscht. D.h. wir versuchen in einem zweiten Fenster ( die aktuelle Sitzung wird nicht geschlossen! Wir wollen uns ja nicht aussperren ) den normalen Login via
ssh -p 549 root@[vpnserverIP]
und sollten so nicht mehr reinkommen.
Also wiederholen wir das mit einem vorgesetzten Ping auf Port 11600:
(dabei verwende ich nmap, ein Portscanner, universell verfügbar. Es ginge auch netcat oder anderes, nur ping selber kann keine speziellen Ports anpingen, keine Ahnung wieso, also)
nmap -Pn -p 11600 [vpnserverIP]
Nun sollte Port 549 für 60 Sekunden offen sein:
ssh -p 549 root@[vpnserverIP]
Und? Drin? Super, dann machen wir uns dazu ein kleines Script:
nano ~/.ssh2vpnserver.sh
#!/bin/bash
nmap -Pn -p 11600 [vpnserverIP]
ssh -p 549 root@[vpnserverIP]
noch ein
chmod +x ~/.ssh2vpnserver.sh
und der Aufruf von:
./.ssh2vpnserver.sh
im Homeverzeichnis verbindet uns in einem Rutsch mit unserem Server.
Dabei ist klar, daß Port 11600 und 549 auch auf unserer lokalen Firewall rausdürfen müssen?
OK. Dann gehen wir weiter zu
/etc/openvpn
und stellen
next > alles auf Anfang