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 ö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,

 

Vorratsdatenspeicherung 2.0 so gut wie beschlossen

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.

 

Die Vorratsdatenspeicherung umgehen

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.