Vor einiger Zeit habe ich gezeigt, wie man ein SSH VPN erstellt. Heute gibt es nun die verbesserte Version, die auch iproute2 Tools benutzt, die ifconfig & Co. abgelöst haben.
Es gelten die gleichen Regeln wie für den alten Beitrag. Als kleine Abweichung nutzen wir diesmal das tun0 Interface, aber das ist reine Kosmetik.
Vorbereitungen
Auf dem VPN Server muß der SSH Tunnel erlaubt sein. Dazu tragen wir „PermitTunnel yes“ in /etc/ssh/sshd_config ein und starten den sshd neu.
Auf dem Clienten
Als erstes öffnen wir den Tunnelverbinder und wie man an den neuen Optionen sehen kann, brauchen wir kein Sleep mehr, denn das macht SSH jetzt für uns von ganz alleine :
ssh -NTCf -w 0:0 root@2te.vpn.server.ip
auf dem VPN Server
ip link set tun0 up;
ip addr add 10.0.1.1/32 peer 10.0.1.2 dev tun0;
echo 1 > /proc/sys/net/ipv4/ip_forward ;iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE;
Da der SSH Befehl im Hintergrund anbleibt, können wir auf das Sleep verzichten und direkt zum Clienten wechseln.
Auf dem Clienten
ip link set tun0 up;
ip addr add 10.0.1.2/32 peer 10.0.1.1 dev tun0;
route add 2te.vpn.server.ip gw alte.gw.ip;
route del default gw alte.gw.ip;
route add default gw 10.0.1.1 dev tun0;
Das wars schon wieder, sofern Ihr keine Fehlermeldung bekommen habt. Wichtig ist die Reihenfolge der Aktionen, also daß SSH zuerst gestartet wird, damit das Tunnelinterface auf der Serverseite vorbereitet werden kann. Wenn man nach SSH z.b. „ip link delete tun0“ eingibt, war alles umsonst und es wird nicht funktionieren.
Update:
Falls ihr ein „Cannot find device „tun0““ bekommt, dann führt mal mit Rootrechten “ tunctl -t tun0 -n “ aus.
Obwohl es heute Mode ist, jedem noch so kleinen Securitybug einen eigenen Namen zugeben, verzichte ich mal drauf. Ich hatte ja einigen Wochen geschrieben, daß es eine FD Veröffentlichung geben wird. Nun, heute ist es soweit : )
Der Fehler ist endlich gefixt, auch wenn die Umstände komisch erscheinen werden. Der ganze Ablauf ist ohnehin merkwürdig, es gibt nicht mal eine CVE dazu. Fangen wir mal vorn an, am 18. November 2013 !
Mein Laptop hatte damals Fedora 18 mit einem Gnomedesktop drauf und wurde alle zwei Stunden aktualisiert, war also auf Stand. Das Laptop wurde nicht gebraucht und in den Suspend gebracht, als es dann wieder aufwachte, sah ich immer noch das Desktopfenster mit Inhalt, dann einige Sekunden später poppte der Screensaver auf und ich mußte mich einloggen. Ok. Man sieht den Bildschirm, obwohl man das nicht sollte, war jedenfalls meine Meinung. Ich probiert es nochmal, aber diesmal lief alles normal ab, der Screensaver sprang diesmal deutlich eher an und man sah nichts. Merkwürdig.
Sicherheitslücke: Informationdisclosure
Langer Rede kurzer Sinn, je nach Situation beim Abschalten des Laptops ins Disksuspend regiert es etwas anders beim Hochfahren. Ein Race zwischen den Prozessen findet statt und wenn der Screensaver das gewinnt, dann sieht man nichts, ansonsten dauert es lange und der Bildschirminhalt wird kurz sichtbar.
Am Mittwoch den 20. November habe ich dann ein Video gedreht auf dem man das sehen kann und einen Securitybugreport bei Fedora und Gnome erstellt. Nachdem die das Video gesehen hatten und nach der Hardware gefragt haben, lehnte man das Problem als irrelevant ab, weil die Hardware ja „nicht die schnellste“ wäre. Argumentieren, daß das Prinzip mit dem Screensaver ja wohl klar falsch abläuft und das vor dem Suspend gemacht werden muß, half nichts. Taube Ohren.
3 Jahre später
Letzten Dezember habe ich ein neues Laptop von der Firma bekommen. Mittlerweile gab es Fedora 23, man beachte 5 Versionen = 5*6 Monate später 😉 und der Bug sollte ja nicht mehr auftreten, weil I5 und SSD. Also … Deckel zu, warten, Deckel wieder hoch … und ????? BINGO.. der Desktopinhalt! Zwar nur für ein paar Augenblicke, also deutlich schneller weg als bei dem alten Laptop, aber da.
Der Bug war bei Fedoraim Tracker immer noch als ungelöst offen. Nun gab es keine Entschuldigung mehr, denn die HW ist schnell, ganz besonders beim Umgang mit Disksuspend. Da mir 3 Jahre als deutlich zu lange für so ein triviales Problem erschienen, habe ich einen FD Timer von 90 Tagen angesetzt, bis zu dem das Problem gefixt sein mußte.
Endlich gut, alles gut ?
Fast. Es wurde behoben, allerdings als Silentupdate, sprich, man hat es keinem erzählt. Nicht mal dem Bugreporter. Ich habe nur durch regelmäßiges ausprobieren bemerkt, daß es endlich behoben wurde.
Bleibt zu vermerken, nicht alle Sicherheitslücken werden sofort behoben, auch wenn durch so eine Informationslücke Inhalte vom Desktop in fremde Hände gelangen. Da könnten Bankdaten zusehen sein, Listen mit Namen von Menschen die nicht gefunden werden dürfen, der private Key vom Server .. tausend Dinge die man nicht sehen sollte, wenn keiner in der Nähe ist um es zu verhindern. Der Angreifer kann den Laptoprechner nach dem Test einfach wieder ins Suspend schicken und keiner merkt es.
Kleines Goodie am Ende ? Hier noch ein Gnome 3 Bug Desktop Hack den ich gemeldet hatte. Der wurde allerdings binnen einer Woche behoben, was bei dem Impact wohl auch kein Wunder ist.
Der Zentralbank von Bangladesh wurde knapp 1 Milliarde US Dollar geklaut, weil einfach mal automatische Anweisungen und Abbuchen der US FED durchgeführt werden, ohne das dies jemand prüft. 870 Mio. Dollar konnten zurück gebucht werden, bevor die Täter es verflüssigen konnten. Am Ende sind die Täter mit 80 Mio. davon gekommen. Der Coup wurde fast 8 Monate lang eingefädelt.
Der Lacher ist aber, daß der Finanzminister von Bangladesh das aus der Zeitung erfahren hat 😀