ARP vs. neighbor

Ein Ethernet-Netzwerk ist ein Multipoint-Netz, das heisst, man kann als Teilnehmer (host) über einen Anschluss (port) viele Gegenstellen (nodes) erreichen und von ihnen erreicht werden. Im Ethernet Netzwerk wird mit sogenannten MAC (Media Access Control) Adressen gearbeitet, die fest in den Speicher einer Netzwerkkarte gebrannt werden (kann aber vom OS zur Laufzeit verändert werden. Diese haben eine Länge von 48-bit, aufgeschrieben üblicherweise in sechs jeweils 8-bit lange Hex-Zahlen unterteilt, manchmal auch in drei 16bit-Zahlen. Die ersten drei 8-bit Werte sind der OUI (Organizationally Unique Identifier) und davon lässt sich meistens der Hersteller einer Netzwerkkarte oder eines Gerätes ableiten. Dafür gibt es Webseiten, aber ich mag das Tool ouilookup. Unter Linux lässt es sich sehr easy installieren aus den Quellen.

Will man nun IP auf Ethernet-Netzwerken sprechen, braucht es eine Technik, um eine IP einer MAC-Adresse zuzuordnen. Das Protokoll dazu heisst in IPv4 ARP (Adress Resolution Protocol) und in IPv6 ND (Neighbor Discovery). Wenn man Netzwerkprobleme debuggen will, ist der erste Schritt eigentlich immer zu prüfen, ob ARP oder ND erfolgreich war. Unter Linux war seit ehedem das Tool arp dafür zuständig. Hier ein Beispiel:

root@linux:~# arp -n
Address            HWtype  HWaddress           Flags Mask    Iface
192.168.1.161      ether   e8:c5:7a:8d:e1:56   C             ens18
192.168.1.165      ether   bc:30:5b:f4:ad:cc   C             ens18
192.168.1.19       ether   00:26:0a:77:a7:c0   C             ens18
192.168.1.208      ether   00:0c:29:44:22:5c   C             ens18
192.168.1.196              (incomplete)                      ens18
192.168.1.3        ether   08:92:04:a6:12:92   C             ens18

Die erste Spalte zeigt die IP und die dritte die MAC Adresse, falls sie existiert. Steht da (incomplete), dann gibt es keine Verbindung. Die letzte zeigt den Ethernet-Port.

Aber oh Schreck! Auf neueren Linux-Installationen gibt es den Befehl nicht mehr. Unter Debian bekommt man ihn mit sudo apt-get install net-tools zurück. Aber es gibt das neue Tool ip, und das kann auch ARPs anzeigen. Aber weil es neu ist und nicht alt und weil es für IPv4 und IPv6 gebaut wurde, hat es die beiden Bezeichnungen zusammengefasst. Jetzt heisst es nicht mehr arp, sondern neighbour für beide. Und das ist ja eigentlich auch richtig so.

root@linux:~# ip neigh 
192.168.1.161 dev ens18 lladdr e8:c5:7a:8d:e1:56 STALE
192.168.1.165 dev ens18 lladdr bc:30:5b:f4:ad:cc STALE
192.168.1.19 dev ens18 lladdr 00:26:0a:77:a7:c0 DELAY
192.168.1.208 dev ens18 lladdr 00:0c:29:44:22:5c REACHABLE
192.168.1.196 dev ens18  FAILED
192.168.1.3 dev ens18 lladdr 08:92:04:a6:12:92 STALE

Und man bekommt sogar mehr Informationen über den Status. STALE bedeutet etwa, dass der Eintrag schon länger nicht mehr aktualisiert wurde. Was die alle bedeuten, steht in der man-page, die man mit folgendem Befehl lesen kann (und sollte): man ip-neighbour

ARP vs. neighbor

Default shell in macOS

Wer ein Gewohnheitstier wie ich ist, will nicht unbedingt von bash nach zsh wechseln, auch wenn es dafür bestimmt gute Gründe gibt. Immerhin hat Apple entschieden, dass wir mit zsh glücklich zu werden haben. Ausserdem lebe ich zwischen den Welten und auf meinen Linux-Installationen ist bash die voreingestellte Shell und es ist schön, dass Skripte auf beiden Plattformen meist ohne grosse Änderungen funktionieren.

Aber immerhin dürfen wir Apple-User noch zu bash wechseln. Ja, sogar zu vielen anderen Shells. Die Datei /etc/shells hält eine Liste an shells vor, die das OS unterstützt:

MyMac:~ eliyah$ cat /etc/shells
# List of acceptable shells for chpass(1).
# Ftpd will not allow users to connect who are not using
# one of these shells.

/bin/bash
/bin/csh
/bin/dash
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh

Und da ist sie noch, die gute alte bash shell. Wenn man also diese Shell nutzen will, die ich auch in allen Beispielen hier zu macOS nutze, dann geht das mit diesem einfachen Befehl:

chsh -s /bin/bash

Die aktuell genutzte Shell verrät die Variable $SHELL. Aber die ändert sich erst, wenn man nach dem oben genannten Befehl das Teminalfenster schliesst und neu öffnet:

MyMac:~ eliyah$ echo $SHELL
/bin/bash

Jetzt funktionieren alle Beispiele hier im Blog (hoffentlich) wie beschrieben, die Die Kategorie OS X haben. Aber in den meisten Fällen funktionieren sie wahrscheinlich auch mit zsh.

Default shell in macOS

Smokeping (und andere rrd) exportieren

Ja, es ist wahr, ich liebe Smokeping. Es ist ein Tool, das drei Dimensionen von Erreichbarkeit darstellt.
1. Latency (RTD, Round Trip Delay, wie lange braucht ein Paket hin und zurück zum Ziel)
2. Jitter (Wie hoch ist die Varianz der RTDs, eine hohe Varianz bedeutet, dass auf dem Weg ein Link sehr voll ist)
3. Packetloss (Wie viele Pakete gehen unwiderruflich verloren auf dem Weg. Über 1% bedeutet normalerweise ein übervoller Link und 100% ein fehlender)

Dafür versendet Smokeping alle 5 Minuten 20 ICMP-Pings an eine entfernte Adresse und speichert die Ergebnisse in rrd-Dateien. Es handelt sich um ein dateibasiertes Datenbankformat, das von vielen Traffic-Graphern und anderen genutzt wird.

Wenn man eine Smokeping-Installation von einem Server zum anderen umziehen will, kann man leider nicht einfach die rrd-Dateien kopieren. Man muss sie erst mit dem Tool rrdtool exportieren und wieder importieren. Und das geht so:

Die Dateien befinden sich im Ordner /var/lib/smokeping/[Ziel]/. Man wechselt in diesen Ordner mit cd und dann exportiert man alle Dateien in das xml-Format:

for FILE in *.rrd; do rrdtool dump $FILE > $FILE.xml; done

Die xml-Dateien kopiert man nun auf den neuen Server in den selben Pfad und konvertiert sie wieder zurück:

for FILE in $(ls *.xml); do rrdtool restore $FILE $(echo $FILE |sed s/.xml//g); done
rm *.xml
chown smokeping:smokeping *.rrd

Falls die Konfiguration für diese Ziele (/etc/smokeping/config.d/Targets) genau gleich ist auf beiden Servern, werden jetzt automatisch neue Grafiken generiert mit den importieren Daten! Nach etwa 10 Minuten kommen neue Ergebnisse hinzu!

Smokeping zu einem DNS Server von Google
Smokeping (und andere rrd) exportieren

Geleakte Passworte automatisch checken

Passworte aus Datenleaks werden in Passwortdatenbanken aufgenommen, um sie für Wordbook-Attacken zu nutzen. Aber nicht nur Hacker Pflegen diese Datenbanken, auch Securityanbieter. Viele Passwortmanager, vor allem die in Browsern, prüfen die in ihnen gespeicherten Passworte regelmäßig gegen solche Datenbanken.

Nach dem letzen Datenleak bei Twitter war mein Account auch betroffen, also hat mich Safari darauf hingewiesen. Damit dieser Check funktioniert, ohne das Passwort zu übertragen und damit selbst zu kompromittieren, wird ein Hash (Kryptographische Ableitung des Passworts, die man nicht zurück übersetzen kann) des Passworts erstellt und mit einer Datenbank bekannter Hashes verglichen. Wenn man also einen unbekannten Hash vergleicht, kann man keinen Rückschluss auf das eigentliche Passwort ziehen.

Aber auch das hat Probleme: Da man in diesem Bereich niemandem vertrauen darf, kann auch ein vollständiger Hash ein Problem sein. Wenn in Zukunft dieser Hash plötzlich bekannt wird, könnte der Anbieter des Checks nachvollziehen, wer dieses Passwort nutzt. Deswegen hat https://haveibeenpwned.com/Passwords eine Web-API erstellt, der man nur die ersten 5 Stellen des Hashes übermittelt und die dann alle bekannten Hashes zurück gibt, die damit beginnen ohne die ersten 5 Stellen. Diese Liste ist relativ kurz und man kann dann lokal die übermittelten Passwort-Hashes mit dem vollständigen Hash vergleichen und so verstehen, ob das Passwort kompromittiert wurde, ohne den gesamten Hash zu übermitteln und ohne die gesamte Hash-Datenbank (>10GB) jeden Tag herunterzuladen.

Das kann man natürlich automatisieren. Und das geht so:

#!/bin/bash
# create SHA from list of passwords and compare them to haveibeenpwned.com

# in macOS the command to create sha-hashes is different
if [ $(uname) == "Darwin" ]; then
        function sha1sum {
                shasum -a 1
        }
fi
for PAWD in $(cat passwords.txt); do
         PAWDSHA=$(echo -n $PAWD | sha1sum | awk '{print $1}')
         PWND=0
         curl -s https://api.pwnedpasswords.com/range/${PAWDSHA:0:5} | fgrep -i ${PAWDSHA:5} >/dev/null && PWND=1 
         if [ ${PWND} -eq 1 ]; then
              echo "$PAWD was pwnd"
         fi
done

Im Script ist passwords.txt die Datei mit Klartext-Passworten. Das ist natürlich keine gute Idee und dient hier nur als Beispiel, woher die Klartextpassworte kommen. Besser ist es, die Passworte als SHA direkt zu speichern und zu vergleichen. Der echo-Command wiederum sollte ersetzt werden durch ein Script oder eine Funktion, die den oder die Besitzer:in des Passworts informiert, dass das Passwort kompromittiert wurde.

Und so sieht das Script in Aktion aus!

Geleakte Passworte automatisch checken

Script zum Setzen der Linux Timezone

Es gibt dafür durchaus Pakete und Binaries, die das übernehmen, aber warum nicht selbst machen und ein wenig mit select spielen?

#!/bin/bash
# Simple script to set system TZ for any linux system
echo "Setting the TZ of this system:"
if [ "$EUID" -ne 0 ]; then
  echo "Please run as root"
  exit
fi
cd /usr/share/zoneinfo/posix
PS3="Select the Region: "
select WREG in $(find . -type d | sed "s/\.\///g" | fgrep -v ".") other; do
	if [ -z $WREG ]; then
		echo "Not changing TZ"
		break
	fi
	echo "Selected the Region: $WREG "
	PS3="Select the TZ: "
	if [ $WREG == "other" ]; then
		mapfile -t WREGLIST < <( find . -maxdepth 1 -not -type d | sed "s/\.\///g" )
		WREG=""
	else
		cd $WREG
		mapfile -t WREGLIST < <( find . -not -type d | sed "s/\.\///g" )
	fi
	select WREGTZ in ${WREGLIST[*]}; do
		if [ -z $WREGTZ ]; then
			echo "Not changing TZ"
		break
		fi
	echo "Selected the TZ: $WREGTZ "
	ln -s /usr/share/zoneinfo/$WREG/$WREGTZ /etc/localtime
	echo "Current date is: $(date)"
	break
	done
break
done
Script zum Setzen der Linux Timezone

Let’s encrypt!

Ich habe meine Seiten auf meinem Debian/Apache Webserver mit SSL verschlüsselt und dabei auf die kostenlose CA Let’s Encrypt! zurückgegriffen.

Es gibt viele Wege, wie man diese CA benutzen kann, aber der certbot ist echt der Hammer. So einfach geht es:

cd /usr/local/sbin
wget https://dl.eff.org/certbot-auto
chmod 750 certbot-auto
certbot-auto --apache

Danach wird man durch alle Schritte geführt und kann inerhalb kürzester Zeit funktionierende SSL Zertifikate nutzen, die sich vollautomatisch installieren.

Die Zertifikate sind zwar nur drei Monate gültig, aber mit certbot installierte Zertifikate lassen sich über diesen automatisch aktualisieren, so dass man sich nie wieder drum kümmern muss. Ein Eintrag wie dieser im Crontab von root reicht:

1 6,18 * * * /usr/local/sbin/certbot-auto renew --post-hook "apache2ctl restart" &>/dev/null

Lasst uns gemeinsam das Internet sicherer machen und „Let’s encrypt!

letsencrypt
https://eliyah.co.il/ ist SSL gesichert!

Let’s encrypt!

Alles so schön bunt hier!

Um in der Shell bunten Text auszugeben, kann man echo oder printf nutzen. Bei ersterem muss man die erweiterten Fähigkeiten mit -e aufrufen.

Hier ein Beispiel für farbigen Text mit fetten Buchstaben und normalen Buchstaben ohne Farbe:

echo -e "\e[1;31mRot\e[0m Normal \e[1;32mGruen \e[0m"

Das Ergebnis ist:

Rot Normal Gruen

Hier ein Beispiel für gelben Text blau hinterlegt und hunterstrichen:

echo -e "\e[4;44;33mGelb blau hinterlegt und unterstrichen\e[0m"

Das Ergebnis ist:

Gelb blau hinterlegt und unterstrichen

Zur Erklärung:

Mit \e[ leitet man die Farb und Formatierungscodes ein. Danach kommen in beliebiger reihenfolge Codes für Zeichen- und Hintergrundfarbe und Formatierung durch Semikolon unterteilt. Danach ein m zum Abschluss. Am Ende des Textes folgt noch ein \e[0m um alle Formatierungen wieder aufzuheben, da sonst aller nachfolgender Text, also auch die übliche Console, eingefärbt bleibt. Hier die Tabellen für die Farben und Formatierungen:

 

Farbe Zeichen Hintergrund
Schwarz 30 40
Rot 31 41
Grün 32 42
Gelb 33 43
Blau 34 44
Magenta 35 45
Cyan 36 46
Weiss 37 47

 

Code Formatierung
0 Normal, Aufheben von allem
1 Fett
2 Gedimmt
3 Kursiv
4 Unterstrichen
5 Blinkend (funktioniert nicht überall)
7 Farbumdrehung (einfach mal ausprobieren!)
8 Unsichtbar
9 Durchgestrichen
Alles so schön bunt hier!

Welche Prefixe liefert welches AS – Teil 3

In den Teilen 1 und 2 habe ich per whois und per IRRToolset nach Prefixen eines AS oder eines AS-Sets gesucht. Ich will diese Information nutzen, um automatische Filterlisten für einen bird Routeserver zu bauen. Ein Kollege hat mich mit der Nase auf bgpq3 gestupst. Man muss es zwar auch selbst kompilieren, aber ./configure; make; make install funktionierte anstandslos auf meinem Debian.

Das Programm wird weiter aktiv entwickelt, im Gegensatz zu dem IRRToolset, und es ist deutlich schneller. Hinter meiner DSL-Leitung braucht das IRRToolset für das Zusammensammeln aller Prefixe von dem befreundeten Provider TNG (AS-TNG) geschlagene 1 Minute und 8 Sekunden und das bgpq3 nur 2 Sekunden. Wir haben also einen Gewinner.

Der Routeserver läuft mit der Software bird. Auch wenn es nicht schwer ist, selbst aus einer Liste an Prefixen eine Access-Liste zusammenzubauen, so bietet bgpq3 doch die Möglichkeit neben IOS, Junos und sogar JSON eben auch bird Access-Listen direkt auszugeben. Das spart Arbeit. Und so sieht es dann aus:

# bgpq3 -b -l allnet  AS-LWL
allnet = [
    31.24.144.0/21,
    31.209.80.0/20,
    37.72.144.0/21,
    37.72.144.0/22,
    37.72.144.0/24,
    37.72.145.0/24,
    37.72.146.0/24,
    37.72.147.0/24,
    37.72.148.0/22,
    37.72.148.0/24,
    37.72.149.0/24,
    37.72.150.0/24,
    37.72.151.0/24,
    46.19.88.0/21,
    46.19.88.0/22,
    46.19.88.0/24,
    46.19.89.0/24,
    46.19.90.0/24,
    46.19.91.0/24,
    46.19.92.0/22,
    46.19.92.0/24,
    46.19.93.0/24,
    46.19.94.0/24,
    46.19.95.0/24,
    87.253.189.0/24,
    91.202.40.0/22,
    95.47.96.0/24,
    109.69.64.0/21,
    152.143.0.0/16,
    185.52.160.0/22,
    185.55.116.0/22,
    185.55.116.0/23,
    185.55.116.0/24,
    185.55.117.0/24,
    185.55.118.0/24,
    185.76.188.0/22,
    185.76.188.0/23,
    193.47.147.0/24,
    195.191.196.0/23
];
Welche Prefixe liefert welches AS – Teil 3

PDF kleiner machen

Wenn in einem PDF Bilder sind, dann oft in unmöglich hoher Auflösung und unkomprimiert, was in einem PDF resultiert, das so groß ist, dass kein Mailserver es mehr annimmt. Auf dem Mac kann man mit dem Programm „Preview“ (oder „Vorschau“ für alle, die auf Deutsch mit ihrem Computer kommunizieren) ein bestehendes PDF als PDF mit verkleinerter Größe exportieren. Aber das Ergebnis ist auch selten zufriedenstellend, denn das PDF ist dann zwar klein, aber die Bilder in bescheidener Qualität.

Besser macht es ghostscript. Da das nicht auf meinem Mac installiert ist, muss eben meine Ubuntu-Installation herhalten. Hier ist der Befehl:

gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook -dNOPAUSE -dQUIET -dBATCH -sOutputFile=output.pdf input.pdf

Mit dem Parameter -dPDFSETTINGS=/screen, kann man die Qualität beeinflussen. Folgende Presets versteht ghostscript:

  • -dPDFSETTINGS=/screen (Bildschirm, 72 dpi Bilder)
  • -dPDFSETTINGS=/ebook (niedrige Qualität, 150 dpi Bilder)
  • -dPDFSETTINGS=/printer (hohe Qualität, 300 dpi Bilder)
  • -dPDFSETTINGS=/prepress (hohe Qualität, farbtreu, 300 dpi Bilder)

Achtung! Bei dPDFSETTINGS=/printer wirft gs einen Fehler aus. Man muss noch ein -dUseCIEColor hinter -dPDFSETTINGS=/printer hängen, damit es klappt.

PDF kleiner machen