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.

EVE Resourcecache aufräumen

Nach einem halben jahr Ressourcecaching von EVE kommt auf einiges an GB, die man nicht auf seiner Platte braucht. Um das los zu werden, muß man in das EVE installationsverzeichnis wechseln und „rescache.exe purge“ eingeben.  Bei mir hatte das 25 GB befreit.

Nautilus: FileChooser Verzeichnisse vor Dateien

Seit Fedora 21 hat Nautilus mal wieder im Dateiauswähler die Verzeichnis in den Dateien angezeigt, also alphabetisch sortiert. Das ist natürlich nicht schön.

Bei Fedora 23 gings mir endlich genug auf den Keks um eine Lösung zu finden :

  1. dconf-editor öffnen
  2. dem Pfad org.gnome.nautilus.preferences  folgen
  3. Die Option sort-directories-first  anhaken.

Das wars schon. Warum das wieder eine eigene Option ist und man das im Dateiauswähler anders machen muß als im normalen Fenster, wird immer ein Rätsel bleiben, genau wie die Frage, wieso die Entwickler von Nautilus uns die Megagroßen Icons auf dem Desktop aufzwingen, statt das bis auf 8×8 skalierbar zu machen, zumal es ja Vectoricons sind .

Joda Phising

Guten Morgen,
Ich möchte Sie über die Zahlung, die Sie hatten, um im Jahr 2015 zu produzieren erinnern.
Leider haben wir nicht erhalten. Wieder schicke ich Ihnen Rechnung.
Mit freundlichen Grüßen,
Leonie Stellmacher

Tja, was soll man dazu noch sagen 🙂 Logisch, daß wir die angehängte ZIP Datei nicht aufmachen, oder ? 😀

ADAC: Motorwelt testet Werbung als Honda Jazz

Der ADAC lernt offenbar nichts dazu, auch wenn das hauseigene Magazin eher selbstständig ist.

In der Januarausgabe der Motorwelt soll laut Inhaltsverzeichnis angeblich auf Seite 39 ein Test des neuen Honda Jazz zu lesen sein. Schlägt man die Seite auf, sieht man allerdings nur Werbung. Diese war offensichtlich wichtiger als der Test, denn im ganzen Magazin taucht der Bericht nicht auf 😀

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,

 

*SPAM* Frohes neues Jahr

Willkommen im Jahr 2016!

Wie wir auf dem 32C3 lernen konnten, wird erstmal alles schlimmer werden. Das fängt schon damit an, daß die „Frohes neues Jahr“-Wünsche per Email Hackversuche sein können. So eine Email ist uns heute morgen ins Netz gegangen:

Date: Fri, 01 Jan 2016 05:17:24 +0100
From: "Laura" <email@frohesneuesjahr2.xyz>
Reply-To: email@frohesneuesjahr2.xyz
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject:  Frohes neues Jahr ! :-)

Hallo

Frohes neues Jahr ! :-)

Grüße 
Vanessa L. 
	

Die URL sieh mehr als komisch aus. Da sie dynamische Parameter hat, ist es vermutlich ein Programm zum …

  • Verifizieren der Emailadresse
  • Analysieren der Browserheader
  • Teil eines Exploitkits

Wie immer: Nicht ansehen, gleich in die digitale Tonne hauen !

Frohes neues Jahr!

Kleines Update: Stand 10:02 Uhr Natürlich habe ich mir die URL angesehen und das Script scheint im Suff programmiert worden zu sein 😉 Der URL Parameter „image“ gibt vor, daß es ein „.jpg“ sein soll, aber zurück kommt ein GIF 🙂 Allerdings ohne Schadcode. Es handelt sich also nur um ein Verifikator Script.