Linux am Dienstag – Programm für den 7.3.2023

Linux am Dienstag dreht sich diesmal um UDP und DNS, und Gnome 44.

Linux am Dienstag – Programm für den 7.3.2023

am Dienstag, ab 19 Uhr haben wir u.a. im Programm:

  • Vortrag – Wat to Höllen is UDP? (Marius)
  • Vortrag – Fedora Testlauf Gnome 44
  • TMP – TPM 2.0 geknackt – Bios mit Schwachstellen
  • Krypto – 6 Milliarden Kapital von Binance abgezogen
  • Sicherheit – News Corp 2 Jahre von Hackern heimgesucht

und andere IT-Newsbeiträge aus aller Welt. Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .Hinweis: Die bisherigen Vorträge findet man unter https://linux-am-dienstag.de/archiv/ .

Android: FireFox und das WiFi-Tickling

Und auch heute wieder ein Beitrag aus der Kategorie „Niemals genauer hinschauen“ :

Wie im Beitrag gestern über Tastatureingaben, die an Suchmaschinen geschickt werden, habe ich auch heute wieder was aus meinem neuesten Projekt für Euch. Euer lieber Firefox bombardiert das Gateway mit scheinbar unsinnigen Paketen:

16:05:52.958119 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:52.973897 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:52.990415 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.018183 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.023820 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.040692 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.058932 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.075325 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.091926 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.108330 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.124708 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.141359 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0

In einem Bugreport an Firefox wird das genauer geschildert:

FireFox Android 5.1

FireFox Android 5.1

If you’re on wifi and an IPv4 DHCP network we will send 0 length UDP packets at port 4886 of your gateway at the default rate of 60hz for 400ms from the start of the transaction in an attempt to improve RTT during the critical early phases. I call this „tickle time“.

Nur so ganz stimmt das nicht, denn 1.0.0.0 gehört nicht meinem Router, sondern ist den Arpa-Laps zugeordnet und auch an sich eher nicht routbar, genau wie 10.0.0.1/8 und ähnliche private Netzwerke.

RTT steht dann für RoundTripTime und der Sinn des Ganzen ist, daß das Antwortverhalten vom WLAN Router verbessert wird, weil er sieht, daß da „massiv“ Pakete kommen und er die echten Pakete dann schneller routet, weil die ja wichtig sind.

Hier zu merken ist: Das macht nur Firefox so, ergo: sieht man son Traffic, weiß man, es ist ein Android Phone mit FireFox, der grade aktiv genutzt wird. Das wir das noch brauchen werden, werdet Ihr bald sehen 🙂

mehr dazu:  https://bugzilla.mozilla.org/show_bug.cgi?id=888268

UDP Traffic per SSH tunneln

SSH Tunnel sind eine gängige Methode um Traffic sicher von einer Maschine auf die andere umzuleiten, aber SSH kann nur TCP Traffic tunneln. Wie bekommt man jetzt UDP über SSH getunnelt ?

Die Antwort lautet : gar nicht! Man muß TCP Traffic draus machen 🙂

Als ersten Schritt öffnen wir mal den Tunnel:    (alle Befehle als Root ausführen versteht sich)

root# ssh -L 8080:localhost:8080 username@zielserver.de „sleep 10000“

Dies schiebt alle Daten die auf Port 8080 ankommen, an den Port 8080 des Zielserver. Der Einfachheit halber, belassen wir die Port auf Quell- und Zielsystem bei der gleichen Nummer, aber das kann man auch nach Bedarf anpassen.

Als erstes brauchen wir einen FIFO ( First In – First Out ) Speicher auf dem Zielserver. Damit kann man die Daten lesen und schreiben, was bei einer PIPE nicht geht.

root@Ziel# mkfifo /tmp/fifo

Nun leiten wir den UDP Traffic per nc von Port 8080 um :

root@Ziel# nc -l -p 8080 < /tmp/fifo | nc -u ip.des.dns.servers 53 > /tmp/fifo

Alles was wir auf Port 8080 lesen, geht über die PIP an den NC Befehl, der es an den DNS Server schickt. Seine Antwort geht über das FIFO File zurück zum „Server nc Befehl“ .

Das Gleiche, nur anders rum, brauchen wir auf dem lokalen Server:

root@local# mkfifo /tmp/fifo
root@local# nc -l -u -p 53 < /tmp/fifo | nc localhost 8080 > /tmp/fifo

Auf unserem lokalen Server binden wir uns an den Port 53 und schicken alles, was in dem FIFO File steht an den, der sich auf Port 53 verbunden hat, also z.b. der Befehl dig . Alles was von dig an den Port 53 gesendet wird, geht über die PIPE zum zweiten nc und der leitet das an den Startpunkt unseres Tunnels.

Entweder, man trägt jetzt 127.0.0.1 in die /etc/resolv.conf ein :

nameserver 127.0.0.1

oder man fragt mit dig 127.0.0.1 direkt ab:

dig @127.0.0.1 marius.bloggt-in-braunschweig.de

Das wars schon.