Tag Archives: VPN

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,

 

Die Vorratsdatenspeicherung umgehen

Posted on by

Fische schwimmen in Schulen, damit der einzelne Fisch für Raubfische unsichtbar wird. Vögel fliegen im Scharm, damit der einzelne Vogel für den Raubvogel im Schwarm untergeht und nicht gezielt rausgepickt werden kann. Einzelne Internetbenutzungen verschwimmen in der Masse der Netzwerkbenutzung …

Schön wars, denn die Zeiten sind „mal wieder“ vorbei. Die Bundesregierung führt mal wieder den Überwachungsstaat ein. Vermutlich hält das wieder genau so lange, bis das Bundesverfassunggericht die Fassung über den Unsinn verliert und den völlig unsinnigen Quatsch beendet. Bis dahin ist es an Ihnen, in der Masse unter zutauchen.

Wie funktioniert die Vorratsdatenspeicherung fürs Internet eigentlich ?

Zunächst müssen wir mal zwischen Internetprovidern und Zugangsprovidern unterscheiden. Internetprovider sind üblicherweise Anbieter von Webspace im Netz. Wie der Kunde ins Netz kommt, ist nicht ihr Problem. Zugangsprovider sind solche, die die Leitung von der Wohnung ins Rechenzentrum betreiben z.b. die Telekom.

Die VDS ( Vorratsdatenspeicherung ) wird nur den Zugangsprovider auferlegt. Die müssen jede Verbindung mit Zeit, Quelle und Ziel speichern. Der Inhalt ist egal. Und da beginnt für Sie jetzt schon eins der Probleme der VDS. Selbst wenn Sie Zugang zu den Daten hätten, Sie könnten sich damit von einem Verdacht nicht freisprechen. Warum nicht ? Wenn der Inhalt der Kommunikation nicht mitgespeichert wird, kann man  nicht sagen, welche Domain eine Email oder ein Webseitenaufruf erreichen sollte. Das liegt daran, daß auf einem Server tausende von Webaccounts und damit Domains betrieben werden können. Sie würden staunen, wie wenig Aufrüfe die normale Webseite am Tag hat, somit kann man viele davon auf einen Server packen. Haben wir so einen Server und speichern nur die Zielipadresse der Kommunikation zu diesem Server, kann man aus den Daten nicht ablesen welche, Domain/Webseite aufgerufen wurde.

Aus diesem Grund ist diese Form der Überwachung völlig nutzlos und zwar für beide Seiten. Der Überwacher kann nicht beweisen, daß Sie die Seiten des „Terrornetzes“ aufgerufen haben, und Sie nicht, daß Sie es nicht gemacht haben. Trotzdem müssen wir damit leben.

Die VDS heißt jetzt übrigens „Mindestdatenspeicherung“, weil es nicht so schlimm klingt. Die Speicherfrist liegt bei 10 Wochen, was auf das Ergebnis übrigens gar keinen Einfluß hat. Bei der Arbeitsgeschwindigkeit deutscher Ermittlungsbehörden, würden auch Jahre nicht ausreichen, mal ganz davon abgesehen, daß man die VDS leicht umgehen kann.

Wie man die VDS austrickst

Dazu gibt es jetzt eine einfache Methode und eine etwas teurere.

Die einfache Methode heißt „Tor“. Tor ist ein Netzwerk aus vielen hunderten Servern, die in den Netzwerkverkehr quer über die Welt verteilen und dabei den Eingangspunkt und den Ausgangspunkt der eigenen Kommunikation im Tornetz verschleiern, da er im Tornetz zufällig hin und her geleitet wird. Im praktischen Endergebnis kann man den Aufruf einer Webseite Ihrer IP nicht mehr zuordnen. Nachteil der Methode ist, daß theoretisch jemand den Datenstrom unterwegs manipulieren kann. Onlinebanking ohne erhöhte Sicherheitsvorkehrungen sollte man also nicht machen. Durch die ständig wechselnde IP dem Webserver gegenüber, kann es bei sicherheitskritischen Anwendungen wie Onlinebanking zu Problemen kommen, da der Webserver einen User nicht mehr sicher authentifizieren und gegen Cookiediebstahl absichern kann.

Die teurere Methode macht im Grunde das Gleiche, bleibt aber unter Ihrer Kontrolle. Dazu mieten Sie bei einem Internetprovider, wie meinem Arbeitgeber, einen Server mit VPN Software und zwei IP Adressen. Zu einer IP bauen Sie die VPN Verbindung auf, mit der anderen IP schickt der Server Ihre Verbindung ins Netz. Damit kann ein Überwacher in den Daten des Zugangsproviders keine Verbindung zu einem anderen Server mehr finden und Sie damit nicht fälschlicherweise beschuldigen.

Der praktische Nebeneffekt ist, daß wirklich Ihre gesamte Datenkommunikation zu Ihrem Server verschlüsselt ist. Sie können mit einem eigenen VPN auch direkt aus einem unsicheren Flughafen WLAN arbeiten, da zuerst alle Daten verschlüsselt an Ihren eigenen VPN Server geleitet werden. Ihre auf dem Laptop oder Handy installierte VPN Software sollte Ihnen zudem melden, falls jemand an Ihrer Kommunikation rumspielt oder versucht Sie auszuspionieren.
Wieviele Freunde und Verwandte Sie über Ihren eigenen Server mit einem VPN Zugang versehen, bleibt Ihnen überlassen. Im Zweifel gilt hier, je mehr Leute es sind, desto unwahrscheinlicher ist es, eine Verbindung Ihnen zuzuschreiben. Es könnte ja jeder der Benutzer gewesen sein. Zudem sind Sie nicht verpflichtet zu protokollieren, wann welcher Benutzer was gemacht hat. Sie sind ja kein Zugangsprovider.
Praktischerweise können Sie so gleich noch die eigene verschlüsselte private Cloudlösung benutzen, wo mit die ganzen Spione in den US Firmen außen vorbleiben. Auch Emailkommunikation können Sie über Ihren eigenen Server sicher abwickeln, sogar mit verschlüsselten Emails.
Achtung: Diese Anleitung erfolgt ohne Gewähr. Einfaches Copy&Paste wird Sie nicht weiterbringen. Sie müssen sich trotzdem selbst einen Überblick verschaffen, wie z.b. RSA Keys erzeugt werden.

Was braucht man um einen eigenen VPN Server aufzustellen ?

Zuerstmal einen eigenen Server im Internet, sonst macht das keinen Sinn und auf einem Webspace geht das i.d.R. nicht. Dann brauchen Sie viel Geduld, denn das Setup eines IPSEC Servers ist unter Linux nicht ganz trivial. Sie benötigen min. die vier Pakete : pptpd, ipsec,pluto und xl2tpd . IPSEC wird z.b. von OpenSwan oder LibreSwan zur Verfügung gestellt.

Hürde 1: /etc/pptpd.conf

PPTP ist eine extrem simples und heute unsicheres VPN Protokoll von Windows, welches bereits mit Windows XP funktioniert. Es hat den einzigen Vorteil, daß es mit Windows ohne weitere Zusatzsoftware funktioniert. Wenn Sie das nicht benötigen oder auch nur den Hauch von Sicherheit haben möchten und auch nur der VDS ein Schnäppchen schlagen wollen, dann, und auch nur dann, können Sie das einsetzen.
# TAG: speed
speed 115200
 
# TAG: option
# Die Vorgabedatei ist an dieser Stelle falsch. Unter SuSE-Linux 8.1 
# befindet sich die „options“-Datei des PPP-Servers unter diesem Pfad.
option /etc/ppp/options.demo
 
# TAG: debug
debug
 
# TAG: localip
# TAG: remoteip
# In diesem Beispiel werden 11 IP-Adressen (192.168.0.200 bis 192.168.0.210 )
# für PPTP-Verbindungen zur Verfügung gestellt. Ein PPTP-Client erhält also eine dieser Adressen.
# localip 192.168.0.234
remoteip 192.168.0.200-210
 
# TAG: ipxnets
# Für die meisten Anwendungen wird IPX wahrscheinlich nicht mehr benötigt. 
# Entsprechend ist es hier ausgeklammert
#ipxnets 00001000-00001FFF
 
# TAG: listen lokale ipaddresse
listen a.b.c.d 
 
# TAG: pidfile
pidfile /var/run/pptpd.pid
/etc/ppp/options.demo:
 
#debug
#debug dump 
lock
refuse-chap 
# Aktiviert die 128-bit Verschlüsselung. Verbindungen lassen sich nur verschlüsselt aufbauen
 
require-mppe 
require-mschap-v2
noipx
 
# Add an entry to this system’s ARP [Address Resolution Protocol]
# table with the IP address of the peer and the Ethernet address of this
# system. {proxyarp,noproxyarp}
proxyarp
 
# Specify which DNS Servers the incoming Win95 or WinNT Connection should use
# Two Servers can be remotely configured
ms-dns 8.8.8.8
Die IP 8.8.8.8 ist das Google DNS Cache und kann gegen den DNS Ihres Rechenzentrumsbetreibers ausgetauscht werden.
Weiter geht es mit der Xl2tpd Konfiguration:
/etc/xl2tpd/l2tp-secrets
# Secrets for authenticating l2tp tunnels
# us          them secret
# * marko      blah2
# zeus marko blah
# *         *          interop
 
* * HierkommtIhrTunnelPassworthin!
„* *“ meint, auf jede unserer IPs von jeder externen IP. Also einfach von überall auf der Welt wird das gleiche Passwort benutzt. Sie können aber für bestimmte IP Blöcke oder einzelne IPs eigene Passwörter verwenden. Damit kann man fein granulieren, wer Zugang bekommt und wer nicht.
Das L2TP ist erstmal nur für den sicheren Kanal zu Ihren VPN Server zuständig, es ist noch keine Authentifizierung oder Datenverschlüsselung erfolgt.
/etc/xl2tpd/xl2tpd.conf
[global]
listen-addr = a.b.c.d
debug tunnel = yes
 
[lns default]
ip range = 192.168.20.2-192.168.255.255
local ip = 192.168.20.1
assign ip = yes
require chap = yes
refuse pap = yes
require authentication = yes
name = OpenswanVPN
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
/etc/ppp/options.xl2tpd
ipcp-accept-local
ipcp-accept-remote
ms-dns  8.8.8.8
noccp
auth
crtscts
idle 1800
mtu 1410
mru 1410
nodefaultroute
debug
lock
proxyarp
connect-delay 5000

2. Hürde – IPSEC

 /etc/ipsec.conf
version 2.0 # conforms to second version of ipsec.conf specification
 
# basic configuration
config setup
plutodebug=“all“
plutostderrlog=  „/var/log/pluto.err“
# For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
protostack=netkey
nat_traversal=yes
# forceencaps=yes
virtual_private=%v4:10.0.0.0/8,%v4:174.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.0.0/24
oe=off
# Enable this if you see „failed to find any available worker“
# nhelpers=0
 
#You may put your configuration (.conf) file in the „/etc/ipsec.d/“
include /etc/ipsec.d/*.conf
/etc/ipsec.d/demo.conf
 
conn roadwarrior2
# dpdaction=clear
authby=secret
type=tunnel
# disablearrivalcheck=no 
        auto=add
        pfs=no  
rekey=no
    
left=%defaultroute
leftnexthop=a.b.c.d             z.b. 543.44.89.131
leftprotoport=17/1701
leftrsasigkey=HIER KOMMT IHR SERVER RSA KEY HIN
        leftsubnet=a.b.c.d./MASKE z.b.  53.44.89.128/25
 
right=%any
rightsubnet=vhost:%no,%priv   
rightprotoport=17/%any
 
# rightsubnet=192.168.0.0/24
# rightnexthop=192.168.0.254
        rightrsasigkey=HIER KOMMT IHR CLIENT RSA KEY HIN
Jetzt noch fix die Passwörter für die Benutzer und wir sind schon durch. DIE RSA Keys können zum Automatischen Aufbau der Verbindung benutzt werden, dies ist z.B. bei VPN Gateways im Büro wichtig, wo niemand über eine Desktopoberfläche einen Usernamen und Passwort eintippt.
/etc/ppp/chap-secrets
 
# Secrets for authentication using CHAP
# client server secret   IP addresses
 
demo          *       „823Ksmx83ejdkso3,389dmdasd“     *
Damit können Sie sich als User demo, mit dem Passwort „823…“ von überall aus einloggen. Wie man an den „*“ sehen kann, ist eine Feinjustierung nach Usernamen, Ziel und QuellIP möglich. Tragen Sie statt der * einfach die IP ein, für die das Passwort gelten soll. Sie können beliebig viele Zeilen mit Passwörtern eintragen.
Nun Starten die ganzen Dienste noch und verbinden sich mit Ihrem Android Handy zu Ihren VPN Server. Geben Sie als erstes die IP des VPN Servers ein, dann das Tunnelpasswort und danach Benutzernamen und Passwort.
Sind Sie jetzt vor dem Überwachungsstaat geschützt ?
Jein. Ihre Internetkommunikation ist erstmal sicher ( außer mit PPTP als VPN ) , Ihre Privatsspähre bleibt damit etwas gewahrt. Zur VDS gehört aber auch eine Totalüberwachung wer mit wem  telefoniert hat. Dagegen kann Sie das VPN nur schützen, wenn sie einen eigenen VOIP Dienst auf Ihrem Server installieren und nur noch darüber mit Leuten „telefonieren“. Gegen die anlasslose Überwachung Ihres Telefonanschlußes und des Mobiltelefons können Sie an dieser Stelle nichts machen, außer es nicht mehr zu benutzen.
Wenn Sie sich zu diesem Schritt genötigt sehen, schliessen Sie sich bitte einer der vielen Initiativen gegen die VDS an und klagen Sie in Karlsruhe gegen die VDS. Denn genau das ist die Folge eines Überwachungsstaates, daß man sachen nicht mehr macht, auch wenn Sie nicht kriminell sind. Privatsspähre und Massenüberwachung passen nicht zusammen. Die zweifelhaften Aussagen von Politikern um die VDS zu rechtfertigen, sind ohnehin schon mehrfach als knallharte Lügen in den normalen Medien enttarnt worden.
Kleines Beispiel: Sigmar Gabriel gibt immer gern Norwegen und Breivik als Rechtfertigung an, Fakt ist aber, die haben den auf der Insel in Flagrantie erwischt, völlig ohne VDS, die es damals in Norwegen eh nicht gab. Auch in Frankreich hatte die VDS keinen Einfluß, weil die Täter bereits unter Überwachung durch den Staatsschutz standen. Wieviel das genutzt hat, konnte man Live im Fernsehen miterleben.
Gegen Brieftauben, tote Briefkästen und Wäscheleinencodes von Terroristen hilft im Übrigen nur die gute alte analoge Polizeiarbeit. Echt Profiterroristen können sie so nicht aufhalten oder identifizieren. Die machen genau das gleiche wie Sie: die VDS umgehen. Es gibt noch ein ganzes Rudel anderer Methoden, wie man Kommunikation effektiv verschleiern kann. Aber das ist für Sie zu viel Aufwand.