BND bekommt eigene VDS für 6 Monate ohne Beschränkungen

Wie einem Artikel von Heise zu entnehmen ist, hat der Bundesrat einem Gesetz zugestimmt, daß dem BND eine sechs monatige Vorratsdatenspeicherung aller Verbindung- und Standortdaten erlaubt. Der BND darf diese Daten nach eigenem Gutdünken durchsuchen, ohne daß es eine kontrollierende Instanz wie einen Richterbeschluß gibt. Die Daten dürfen sogar automatisch mit anderen Ländern getauscht werden.

Damit ist faktisch ein Überwachungsstaat geschaffen worden, der ohne rechtsstaatliche Kontrollen alle Daten erfassen kann und wird. Offiziell dürfen natürlich nur Ausländer überwacht werden, aber an Datenströmen steht so selten dran, daß sie nicht aus oder nach Deutschland kommen.

Damit sollte eine rote Linie für alle Bürger überschritten sein, die bisher nichts zu verstecken hatten, denn jetzt sind auch sie betroffen und können jederzeit zum Ziel von Ermittlungen werden, nur weil jemand einen Zahlendreher bei der Eingabe einer IP Adresse gemacht hat. Das war zwar vorher schon möglich, aber wurde zumindest noch von einem Richter abgesegnet.

Für uns Linuxnerds heißt es jetzt natürlich zu handeln. Großflächige Überwachung können wir mit großflächigem Einsatz von VPNs und allgemeiner Verschlüsselung bekämpfen, denn wenn der Preis zum Entschlüsseln aller Verbindungen zu hoch wird, kann sich das der BND oder auch die NSA schlicht nicht leisten. Wenn das ganze Internet verschlüsselt ist, kann man nur noch die Datenströme verfolgen und dekodieren, die einem wirklich wichtig sind. Daran ändern auch die viel beschworenen Quantencomputer nichts. Die Überwachung der Standortdaten kann man ganz leicht umgehen, schaltet das Handy einfach mal aus!

Deswegen gibt es hier im Blog demnächst die Neuauflage der Anleitungen zum Aufbau von VPNs, Anweisungen zu Kryptomessangern, Anleitungen zum Aufsetzen von sicheren PCs und Webserverdiensten. Zukünftig an der eigenen Kategorie „Secure The Web“ zu erkennen.

 

Diese Woche im Netz

Microsofts Office 360 User sind auf in 2016 noch anfällig für Macroattacken, und wie schon im letzten  Jahrtausend, muß das Opfer immernoch einen Knopf drücken um gehackt zu werden.
Vermutlich sind die Angriffe schon so alt, daß die Menschen bereits in Rente sind, die die Welle damals noch mitgemacht haben 🙂

Quelle: thehackernews.com

Wie ArsTechnica berichtet, könnte es in Russland bald zu einer weiteren Verschärfung der Internetüberwachung kommen. Das Szenario ist eine Megafette Vorratsdatenspeicherung 3.0, weil Inhalte für 6 Monate gespeichert werden sollen und Metadaten für 3 Jahre. Soviel Festplattenspeicherplatz hat dann nichtmal die NSA zur Verfügung  ( Das passende Video zum Thema ) 😉

Quelle: arstechnica.com

50% der Firmenchefs anfällig für Phisingattacken. Wer hätte gedacht, daß sich das Management für cleverer hält als das Fußvolk 😀

Quelle: v3.co.uk

Nächstes IoT-DDOS-Botnetz gefunden: 25.000+ IP Cams versklaved.

Quelle: thehackernews.com

Und wieder sind Medizinische Daten im Netz „verloren“ gegangen. Die Leute lernen einfach nicht dazu.

Quelle: theinquirer.net

4 US$ Smartphone kommt in Indien auf den Markt.

Quelle: AndroidCentral.com

Erster Autounfall mit Todesfolge bei Tesla wo der Autopilot gefahren ist.

Quelle: focus.de

SSH VPN mit den iproute2 Tools

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 müssen ö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.

 

und der Datenschutz bleibt wieder auf der Strecke

Wenn man diversen Presseveröffentlichungen glauben schenken darf, wird jetzt die nächste Big Data Anwendung gesetzlich verankert. Autonomes Autofahren erfordert, daß Autos sich gegenseitig erkennen und genau wie Menschen, sich an Regel und Absprachen halten.

Das an sich wäre noch kein Problem, wenn die Autokonzerne nicht gleich alles, was so ein Auto an Daten zu bieten hätte, haben wollten:

Wann, wo, wie ist der Wagen gefahren?
Gab es auf der Strecke Probleme ? Wie war das Wetter ?
usw.

Das sich damit Bewegungsprofile erstellen lassen, wird in der ganzen Diskussion weggeredet, schliesslich würde man das nur pseudorandomisiert erlauben. Damit gibt es natürlich jetzt zwei Schwachpunkte, „Pseudo“ meint „nicht echt“, eine Pseudorandomisierung ist eben kein Zufall. Dazu kommt, daß dies niemand überwachen wird und selbst wenn, wir sehen ja grade am Safe Harbor Abkommen, daß es dann doch mal wieder scheissegal ist, hauptsache man kann damit Geld verdienen und Geld verdeinen mit unseren Daten, daß wollen die Großkonzerne alle.

Wenn die Daten dann erstmal da sind, wird irgendein Politiker mit fragwürdiger Loyalität todsicher fordern, daß man ja darüber dann auch gleich die Maut eintreiben kann, schliesslich hätte dies Vorteile, weil als „Kunde“ dann KMgenau abgerechnet wird. Und was jetzt mit den Mautbrückendaten schon alles so getrieben wird, ist ja hinlänglich bekannt.

Kurzum.. die gute alte Alufolie wird dann auch im Motorblock notwendig werden, weil was man nicht rausfunken kann, das kann ein anderer auch nicht auswerten.Wie bei der Vorratsdatenspeicherung auch, liegt es wieder an jedem einzelnen sich zu schützen.

VDS: Schnell ein VPN aufsetzen

Die Vorratsdatenspeicherung kommt, mal wieder. Und mal wieder ist es Zeit etwas vorzustellen, daß Simple ist und den Zweck voll erfüllt.

Was wir brauchen

Einen Server im Netz auf dem wir Root werden können und der zwei IP Adressen aus zwei Netzwerken hat.
Einen Linux Rechner als Clienten. Mit Windows würde es auch gehen, allerdings ist es dort nicht ganz so leicht, wegen den nötigen Administratorberechtigungen.
Aktuelle Kernel auf dem Linuxrechnern.

Und so gehts

Auf allen mir bekannten Linuxrechnern ist SSH vorinstalliert…. Genau, wir bauen ein SSH-VPN 😉

SSH ist bekannt dafür, daß man einzelne PORTS in und aus einem Rechner tunneln kann. Das beschränkt sich meistens auf einen einzigen Port, aber SSH kann mehr. In einem früheren Beitrag hatte ich mal gezeigt, daß man UDP Pakete über TCP Tunnel schicken kann, um z.B. DNS in die Freiheit zu tunneln. SSH kann aber noch mehr, denn heute Tunneln wir ALLLES und das mit nur 5 Zeilen Bashcode!

Wir benötigen dazu zwei BASH Terminals, die nennen wir mal A und B. A wird einfach nur den SSH Befehl halten, der zum Server tunnelt. In B werden wir die Routen setzen. Danach brauchen wir B nicht mehr, leider blockt A, sonst würden wir nur eine Konsole brauchen.

Eines muß man noch erklären, ein Server routet Datenpakete i.d.R. in ein komplett fremdes Netzwerk, in dem er die IP Adresse des Interfaces benutzt, auf dem der Defaultrouter ( das Gateway ) erreicht werden kann.

Der SSH Server muß vorbereitet sein, einen Tunnel zu öffnen. Dazu in der /etc/ssh/sshd_config „PermitTunnel yes“ eintragen und den Dienst neustarten.

ABKÜFI:

IP.2.VPN.SERVER = zweite IP des Servers => darf nicht auf dem Defaultgatewayinterface liegen!
ALTE.ROUTER.IP = die bisherige IP des im LAN eingestellten Routers

Terminal A :

ssh -w5:5 root@IP.2.VPN.SERVER "ifconfig tun5 10.0.1.1 netmask 255.255.255.252;echo 1 > /proc/sys/net/ipv4/ip_forward ;iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE;sleep 10000000000000;" 

Damit bauen wir den Tunnel auf, sagen dem Zielserver, daß er ein Interface aus dem 10.0.1.0/30 Netz aufbauen soll. Dem Kernel des Servers sagen wir zusätzlich noch, daß wir ab sofort Datenpakete von einem Interface zu einem anderen Umleiten möchten, dies macht das Echo und zu guter letzt wird über den IPTABLES Befehl das IP Masquerading im NAT aktivert, ohne das hätten wir zwar die interne 10er IP Adresse im Netz und könnten Pakete raussenden, aber die Antworten würden uns nicht mehr erreichen. Damit der TCPIP Stack das auch wieder richtig zurückroutet, braucht man NAT.

Terminal B:

ifconfig tun5 10.0.1.2 netmask 255.255.255.252 
route add IP.2.VPN.SERVER gw ALTE.ROUTER.IP
route add default gw 10.0.1.1
route del default gw ALTE.ROUTER.IP

Nachdem der Tunnel steht, müssen wir diesen natürlich noch in ein Interface umwandeln, damit wir intern Datenpakete routen können. Es nutzt ja nichts einen Tunnel zu haben, ohne daß was durchgeht 🙂

Daher bauen wir zunächst genau wie auf dem Server das Tunnelinterface tun5 auf, was es mit der 5 auf sich hat erkläre ich später. Nun müssen wir erstmal dafür sorgen, daß der Server auch weiterhin erreichbar ist, denn die Daten dahin müssen weiterhin über den bisherigen Router laufen, also über die normale unverschlüsselte Verbindung. (route add IP.2.VPN.SERVER gw ALTE.ROUTER.IP).

Nun fügen wir das neue Default Gateway 10.0.1.1, daß ist die IP des Tunnels auf dem Serverausgang, hinzu. (route add default gw 10.0.1.1) .

Zu guter letzt noch den alten normalen Routerweg entfernen und die Daten fliessen nur noch über das neue verschlüsselte Defaultgateway. ( route del default gw ALTE.ROUTER.IP ).

Vorteile

Das wars schon. Überraschend einfach oder ? SSH hat einige Vorteile, die Keys können einfachst geändert werden. Man-in-the-Middle-Attacken können leicht erkannt werden. SSH Schlüssel können fast beliebig lang sein z.b. 4096/8192/16384 Bit Keys. SSH verfügt über diverse Chipers die frei genutzt werden können und es werden i.d.R. auf neueren SSH Versionen elliptische Kurven benutzt. PFS Verbindungen funktionieren ebenso und Updates von Client und Server sind bis in unabsehbare Zukunft gesichert und zu allem Überfluß ist das System auch noch betriebssystemunabhängig 🙂

Alle Macht der Fünf!

In den Beispielen oben haben wir Tunnel5 benutzt, daß ist aber nur einer von (beliebig) vielen. Man könnte genauso gut 0,1 oder 19 nehmen. Damit sich verschiedene User nicht in Gehege kommen, bekommt einfach jeder Nutzer seinen eigenen Schlüssel und eine eigene Tunnelnummer.

Mit der SSH Option „-w local:remote“ legen wir fest welche Tunnel IDs benutzt werden sollen für diese Connection.
trägt man bei dem das Gleiche ein, macht es die Sache in meinen Augen etwas einfacher, aber natürlich kann man sich auch was kompliziertes ausdenken 🙂  die Lokale ID sollte dann beim lokalen IFCONFIG Befehl auf dem Clienten benutzt werden.

Wichtig: Wenn man schon einen Tunnel aufgebaut hat, kann man nicht mehr die gleiche ID nehmen, ohne das Device auf dem Server zu entfernen. z.B. mit „ip link delete tun5“ . Das man das machen muß, merkt man daran, da SSH beim Login mitteilt, daß Channel 0 nicht autorisiert wäre einen Tunnel aufzubauen. Ansonsten schweigt sich SSH einfach mal aus!

Also vor der Aktion einfach normal auf dem Server einloggen und das Device explizit killen, wenn man Probleme hat.

Ich denke ja es ist unnötig zu wähnen, daß man auf beiden Maschinen ROOT sein muß, damit man Tunnel aufbauen kann. Der Vorteil ist dann, daß alle Benutzer des Pcs proftieren.

Probleme

Soweit keine, die sich nicht als Konsequenz von dem ohnehin ergeben, was wir hier gemacht haben.

Dadurch, daß die Defaultroutings geändert wurden, ist das System natürlich anfällig für Neustarts des Netzwerks, da dabei die Defaultrouten gesetzt werden. D.h. der NetworkManager der meisten Desktop Linuxe ist der natürliche Feind des SSH VPNS und sollte abgeschaltet werden, wenn die Sache dauerhaft sein soll. Auch das geblockte SSH Terminal wird ein Problem darstellen, wenn man mal ins Standby geht. Dies ist z.B. bei Laptops der Fall, wenn der Deckel zugeklappt wird. Die Methode eignet sich also z.b. immer dann, wenn man keine andere Option hat, oder es einfach mal schnell passieren muß.

Kleiner Bonus im LAN: gibt man das Laptop oder den Linux PC als Gateway für ein Windowssystem ein, nutzt der Windows Rechner den Kryptotunnel mit, natürlich nur AB dem Linuxrechner. Bis zum Linuxrechner ist alles unverschlüsselt. Bewegt man sich in einem fremden LAN ( Flughafen oder Freunde ) sollte jeder Rechner den Tunnel selbst aufbauen.

Ausdrücklich nicht geeignet ist diese Methode für Smartphones, was natürlich daran liegt, da es dort kein SSH gibt mit dem man das machen könnte. Hier empfiehlt sich ein IPSEC VPN mit L2TP Tunnel. Das konnte sogar schon Android 3.2 . Der IPSEC Tunnel ist aber eindeutig fehleranfälliger als der SSH Tunnel, dafür wird er vom Networkmanager kontrolliert, der auch nach dem Suspend-To-Disk aka. Standby das Netzwerk wieder einrichtet,