Linux – Cannot find device „tun0“

Ihr wollt z.B. mit SSH ein VPN und dazu einen Tunnel aufbauen, könnt aber nicht, weil Ihr diese Fehlermeldung bekommt: Cannot find device „tun0“ ? Ja, na dann auf ins neue Netstackventure!

Tunneldevice mit Linux nutzen

Ihr erinnert Euch noch an den Artikel: SSH VPN mit den iproute2 Tools ? Da haben wir ein SSH VPN aus dem Hut gezaubert und mußten dazu mit Tunneln arbeiten. Da hat sich einiges getan, deswegen müssen wir uns leider erneut damit befassen.

Schritt 1 und 2 sind klar, ein TUN Modul laden und Device erzeugen, aber was ist das…?? :

[root@backup ~]# modprobe tun
[root@backup ~]# ip link set tun0 up;
Cannot find device "tun0"

Cannot find device „tun0““ ist ein echter Kopfschmerzenerzeuger, weil so unnötig. Also das Modul „tun“ ist wie der Name nahelegt, für Tunneldevices zuständig. Es sollte eigentlich ein Tunneldevice tun0 erzeugen, tuts aber nicht und mit normalen Fedora Bordmitteln ist das auch nicht so einfach machbar.

Ihr braucht das Paket „tunctl“ ( dnf install tunctl ) und müßt Euch erstmal ein tundevice bauen:

tunctl -t tun0

Wie man sieht, ist das nicht schwer. Jetzt, wo das Gerät persistent gemacht wurde, seht Ihr an der Ausgabe von dem Befehl oben, klappt das dann auch mit dem „ip link set tun0 up“ und Ihr könnt der Anleitung aus SSH VPN mit den iproute2 Tools weiter folgen. Ihr müßt nur dran denken, daß Ihr das auch bei Euch auf dem Client PC macht und nicht nur auf dem Server.

Eine Bewertung, wieso das nicht mehr defaultmäßig bei Fedora dabei ist, verkneif ich mir, es wird merkwürdige Gründe haben 🙂

Wieso DoH nicht gut für die Privatsphäre des User ist.

Mozilla will ja ab sofort in den USA DoH als Testballon starten. Der Rest der Welt soll später folgen. Ziel der Aktion ist es, daß DNS Anfragen nicht mehr von DNS-Servern wie Bind beantwortet werden, sondern, daß Webserver die DNS Informationen für den anfragenden Clienten per HTTPS beantworten. Bleibt die Frage, was und woher tunnelt er die Daten?

„Wäre es nicht die Wirklichkeit, es wäre ein Bestseller“

Ganz kurz umrissen, wird Firefox per HTTPS  die Cloudflare DoH-Webserver fragen, die holen sich DNS Antworten dann vom Cloudflare DNS-Servern und der von den korrekten  DNS-Servern. In der Endstufe war geplant, daß die besuchten Webserver die DNS Anfragen selbst beantworten, so daß wieder eine dezentrale Struktur entsteht.

Mozilla möchte damit erreichen, daß DNS Anfragen nicht mehr im Klartext durchs Netz gehen, weil ein Angreifer die bisherige DNS Information mit einer MITM-Attacke angreifen kann ( Man-in-the-Middle ). Nobel, aber sollte DNSSEC nicht genau das Problem lösen?

Und wer sagt uns, daß Cloudflare die Daten nicht manipuliert? Millionen von DNS-Webanfragen  würden bei Cloudflare durchgehen und wären so leichteste Beute für einen, der nicht will, daß Domain X erreichbar ist, oder Inhalt Y hat.

Wer schützt uns vor Zensur?

Das DNS System, denn es gibt Millionen DNS Server und Caches aus denen ich mir die Informationen zu einer Domain ziehen kann, inklusive der Autoritären-DNS des Domaininhabers.

Wie jetzt, Eurer Provider blockt externe DNS und erlaubt Euch nur seine eigenen DNS-Caches zu benutzen?

Lest das hier: UDP Traffic per SSH tunneln

Und wie sieht es mit dem Datenschutz aus?

Firefox sendet jetzt private Informationen in einem Ausmaß an ein amerikanisches Unternehmen, daß daraus leicht Profile bilden kann, und der Datenschutz sieht zu? Glaube ich kaum.

Was wollte Mozilla doch gleich mit DoH schützen?

Die Privatsphäre, ach ja, kommen wir mal dazu. Korrekt ist, daß ein DNS Betreiber in den Logfiles, so er denn welche erstellt, nachsehen kann, welche IP welche Domain hat auflösen wollen. Cloudflare kann das auch, niemand hindert sie daran. D.b. für die Privatsphäre ist es mit Cloudflare als derzeit einzigem DoH Betreiber, noch schlechter bestellt, als jetzt.

Derzeit kann ich mir aussuchen, welchen der vielen DNS Server ich frage, oder ob ich mir vielleicht gleich selbst einen eigenen DNS Cache hinstelle, der nur für mich arbeitet. Mit DoH geht das nicht mehr, außer ich betreibe einen DoH Server. Mangels Masse, eher unrealistisch derzeit.

Wie man seine eigenen DNS Anfragen auf möglichst viele DNS Server verteilt um bei keinem der DNS Betreiber ein sinnvolles Profil zu hinterlassen, findet Ihr in diesem früheren Beitrag von mir : Linux – DNS-DeTracking mit nscd

Fazit

DoH ist derzeit die leibhaftige Vision einen dystopische Zukunft, in der alle User bei einem einzigen Anbieter sind, so wie in den Terranauten, alle beim Energiekonzern Energie beziehen, vom Lebensmittelkonzern ernährt werden und auch ansonsten von Monopolen beherrscht werden. DoH ist im jetzigen Zustand nur eins: nicht akzeptabel.

Eine (von vielen) Alternative

DNS-Anfragen per TLS manipulationssicher zu machen, ist ok. Aber, wozu eigentlich der HTTP Overhead? Reicht es nicht, wenn Bind einen TLS Port bereitstellen würde und der zuerst gefragt wird? Das hätte zur Folge, daß der Server durch den SNI im TLS auch domainbasierte Zertifikate benutzen kann, also auch beweisen könnte, daß er er ist und nicht ein MITM-Angreifer.

Zugegeben, der Overhead dabei wäre aufgrund der möglichen Schlüssellängen ziemlich heftig, aber dafür könnte man z.b. kleinere, mit dem Zertifikat des Domaininhabers signierte, DNS Zertifikate einsetzen. Lets Encrypt könnte das z.B. gleich mit erzeugen und ausliefern, wenn das Hauptzertifikat erzeugt wird.

DNS-Caches könnte man dann gleich daran erkennen, daß sie ein Zert anbieten, daß nicht zum Domainnamen paßt. Anhand der bekannten Root–Zertifikate könnte man auch gleich die Ketten verifizieren. Es ist etablierte Technik, es gibt etablierte Bibliotheken, systemische Schwachstellen sind bekannt, und durch die kürzeren Zerts wäre der Performanceeinbruch nicht so stark. Würde man zudem mehrere DNS Anfragen in einer TCP Sesssion durchführen, so denn sinnvoll möglich, würde der Overhead weiter sinken.

Es gibt also Methoden, die eine derzeit zentrale Instanz wie Cloudflare nicht benötigen, warum also  dann DoH durchziehen?  In einer dystopischen Zukunft wären die Gründe wie immer: Machtgeilheit, Geldgier und, daß eine Gruppe von wackeren Helden den Schurken in einem effektvollen Kampf schlagen kann.

In dem Sinn: „Avengers, Assemble!“

und gleich die nächste Timing Attacke auf Intel-CPUs: NetCAT

Niederländische Forscher der Vrije Universität in Amsterdam haben die Schwachstelle entdeckt. Vom Typ her eine Timing-Attacke, die man übers Netzwerk ausführen kann. .

NetCAT – Remote Attacke auf Intel CPUs dank DDIO

DDIO ( Data-Direct I/O ) gibt Netzwerkkarten und anderen Peripheriegeräten direkten Zugriff auf das CPU Cache. DDIO ist seit 2012 bei fast allen INTEL Server CPUs eingeschaltet, also eher schlecht für die Leistung, wenn man das abschaltet.

Die Lücke taugt zum Abgreifen von Tastatureingaben z.b. in SSH, weil man durch die Latenzunterschiede der Pakete vom Angreifer zum Server messen kann, welche Tasten gedrückt wurden. Schuld ist der Zustand der CPU-Caches, der in Abhängigkeit was man tut, eben schneller oder langsamer reagiert.

Wie auch schon bei Lauschangriffen auf Tastatureingaben, kann man aus den Abfolgen der Zeitunterschiede auf die Tasten rückschließen, weil es unterschiedlich lange dauert, mit dem Finger von A nach P zu kommen, als von A nach S.

Die Forscher haben zur Genauigkeit der Attacke über Netz folgendes zu sagen:

„Compared to a native local attacker, NetCAT’s attack from across the network only reduces the accuracy of the discovered keystrokes on average by 11.7% by discovering inter-arrival of SSH packets with a true positive rate of 85%.“

Meint: Das Netz macht es nur geringfügig ungenauer. Danke Intel!

Apros Intel, was sagen die dazu: „Pfff.. Klappt in der Realität wohl eher weniger, nicht so wichtig. Hier Forscher, ein kleines Dankeschön fürs Mitspielen.“

Gegenmaßnahmen

DDIO abschalten. Viel Spaß damit.

Oder man benutzt gleich Schlüssel zum SSH Login, dann ergibt sich das Problem gar nicht erst.

Quelle: https://thehackernews.com/2019/09/netcat-intel-side-channel.html

Schlag ins Gesicht der Spammafia – 281 verhaftet

Das US-Justizministerium hat eine gute Nachricht für alle spamgeplagten Mailboxbesitzer:

Justiznachrichten
Justizministerium
Büro für öffentliche Angelegenheiten
ZUR SOFORTIGEN FREIGABE
Dienstag, 10. September 2019

281 weltweit verhaftet in einer koordinierten internationalen Durchsetzungsaktion, die sich gegen Hunderte von Personen mit geschäftlichen E-Mail-Betrugsmethoden richtet.
74 mutmaßliche Betrüger in den Vereinigten Staaten verhaftet

Die Bundesbehörden gaben heute eine bedeutende koordinierte Anstrengung zur Störung von Business Email Compromise (BEC)-Programmen bekannt, die darauf abzielen, Banküberweisungen von Unternehmen und Privatpersonen, darunter viele ältere Menschen, abzufangen und zu entführen. Operation reWired, eine koordinierte Strafverfolgungsmaßnahme des U.S. Department of Justice, des U.S. Department of Homeland Security, des U.S. Department of the Treasury, des U.S. Postal Inspection Service und des U.S. Department of State, wurde über einen Zeitraum von vier Monaten durchgeführt, was zu 281 Verhaftungen in den Vereinigten Staaten und Übersee führte, darunter 167 in Nigeria, 18 in der Türkei und 15 in Ghana. Verhaftungen wurden auch in Frankreich, Italien, Japan, Kenia, Malaysia und dem Vereinigten Königreich (UK) vorgenommen. Die Operation führte auch zur Beschlagnahme von fast 3,7 Millionen Dollar.

Übersetzt mit www.DeepL.com/Translator

\o/ Strike \o/ Solche Nachrichten brauchen wir öfters 🙂

Quelle: https://www.justice.gov/opa/pr/281-arrested-worldwide-coordinated-international-enforcement-operation-targeting-hundreds

Willkommen im Club der TLS Verweigerer: Apache Foundation!

Nachdem ich die Admins von Mozilla dies Jahr endlich dazu bewegen konnte, für den Mailserver Ihres Bugtrackers TLS zu aktivieren, muß ich leider feststellen, daß eine der größten Organisationen im FOSS Bereich derbe ins Klo gegriffen hat:

Willkommen im Club der TLS-Verweigerer: Apache Foundation!

Eigentlich sagen Bilder ja mehr als tausend Worte, aber in dem Fall erfüllt eine einzige Logzeile den gleichen Zweck:

2019-09-09 12:20:07 H=hermes.apache.org (mail.apache.org) [207.244.88.153] F=<bugzilla@apache.org> rejected RCPT <empfänger@empfängerdomain.de>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.

Damit reiht sich die Apache Foundation erfolgreich in den Club der TLS-Verweigerer ein. Ich vermute, daß, da auch der Mozilla Bugtracker das gleiche Problem hatte, eine gemeinsame Programmbasis vorliegt, mit den gleichen schlechten Default Einstellungen! Da ich schlecht fragen kann, weil Emailantworten ja nicht ankommen, werden wir nie rausfinden woran das liegt 😉

Fest steht, daß gerade für einen Bugtracker, der ja „Security related Content“ transportiert, die TLS-Verweigerung ein klarer Sicherheitsbruch ist. Wünschen wir dem Verantwortlichen daher ein böses Erwachen.

Natürlich werde ich versuchen, Apache zum Besseren zu bekehren, aber erfahrungsgemäß sind Admins, die das nicht selbst merken oder es für kein Problem halten, schwer in die Realität zu überführen. Bei Mozilla hat es 2 Jahre gedauert 😉

Update: 22:19

Entschuldigt die Ausdrucksweise, aber „boar ist das hart!“ . Ich habe ja die Geschichten von den störischen OO Entwicklern nicht sooo richtig geglaubt, aber was da heute an dämlichen Antworten auf Bugreports kam, das haut dem Fass den Boden raus!

„Was für eine unfassbare Scheiße.:!!“

Ich melde da einen Segmentation Fault, der seit einigen Tagen auftritt und bekomme als Antwort: „Das liegt an Deiner Maschine.“ . Die „latest“ Version von OpenOffice ist 4.1.6 , die ist von September 2018, also rund 1 Jahr alt. Das der Rest der Welt da mal ein paar Updates eingespielt haben könnte und OO deswegen crashed, ist zwar primär richtig, aber sowas von arrogante Scheiße, daß man dem Herrn gern mal eins zwischen die Ohren geben will. „Es ist natürlich nicht unser uralt Code der da failed, es ist das Security Update auf Deinem Rechner, daß nicht mitspielt.“ Was denkt sich so ein Depp eigentlich?

Ticket Nummer zwei war dann zu dem fehlenden TLS im Mailserver, kam als Antwort „ist kein OOO Problem“. Was zum Geier ist ein OOO Problem? OpenOfficeOrganisation oder was? Das ist doch dem Reporter egal, ob das vom Apache Admin, oder vom Projektleiter gelöst wird, Fakt ist, daß die mit dem mangelnden TLS Support technisch in der Steinzeit leben. Das wurde Anfang der 90er Jahre des letzten Jahrtausends eingeführt, immerhin ist das fast !!! 30 !!! Jahre her! Echt unglaublich.

Aber diese Mentalität paßt natürlich zur „unser Code ist steinalt, deswegen ist der gut“ Antwort. Konsequent sind die ja dann irgendwie 😀

Es gibt nur eine Lösung

Da kann man nur eins empfehlen: dnf erase openoffice;dnf install libreoffice

Auch wenn ich LibreOffice nicht mag, da dort bei Präsentationen die Medien Einbindung nicht richtig funktioniert. Aber immerhin schicken die häufiger Updates raus.