Tag Archives: VDS

und der Datenschutz bleibt wieder auf der Strecke

Posted on by

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

Posted on by

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,

 

Vorratsdatenspeicherung 2.0 so gut wie beschlossen

Posted on by

In diesen Tagen kann man nur eine eindeutige Stellungnahme zur Vorratsdatenspeicherung abgeben:

Die Vorratsdatenspeicherung ist eine reine Resourcenverschwendung bei …

  • … denen, die Sie planen,
  • … denen, die Sie beschliessen sollen,
  • … denen, die Sie durchführen sollen,
  • … denen, die Sie bekämpfen werden,
  • … denen, die Sie juristisch aufarbeiten werden.
  • Denn,
  • … die Vorratsdatenspeicherung ist mit dem trivialen(einfachen) Mittel eines VPNs auszuhebeln.

Damit sind nur die nicht geschützt, die „nichts zu verbergen haben“, denn sie sind zu Ignorant(durch Unwissenheit) um sich zu schützen.

Wer sich schützen möchte, kann zunächst mal Tor(Download) installieren und danach auf ein geeignetes VPN System umsteigen.

Update: die VDS 2.0 ist durch den Bundestag und damit nach Verkündung gültig. in 12 Monaten ab heute müssen alle Technischen Standards festgelegt sein und in weiteren 6 Monten muß es implementiert sein.

Zeit genug für Sie sich einen eigenen Server im Netz mit zwei IP und einem VPN zu zulegen. Natürlich können Sie das auch mieten, Das VPN sollte Ihre anderen Verschlüsselungsmaßnahmen nicht ersetzen, sondern zusätzlich genutzt werden.