640000 rounds shadow benchmarking

So the requirement over here is, “use SHA512 for /etc/shadow, but with 640000 rounds instead of the default 5000, to slow down brute force attacks”. (Not sure why exactly 640000 though.)

Let’s confirm that this slows down brute force attacks. First create one pure 5000-round hash file, and one pure 640000-round hash file. Note how 640000 rounds hashing takes much longer at this stage already:

$ openssl rand -hex 2 | (time mkpasswd --method=sha512crypt --stdin) | tee shadow-sha512
$6$ZcZ6RoMB5pSad9Ca$alLttTrpP1BezuOued3JrVgv/0tq7mkI5jypP4cZ/smgWF30HuLmtAl.DExd23j3xPLCWc6zWF4eLNLGKLr77.

real    0m0.006s <--
user    0m0.000s
sys     0m0.003s

$ openssl rand -hex 2 | (time mkpasswd --rounds=640000 --method=sha512crypt --stdin) | tee shadow-sha512-640000rounds
$6$rounds=640000$ZBpVIbg3SKT.KerX$hTLaX/OVOWQol5UeVMq2pO1EI2L4nG4WWOIXPhmujq7EqxohLu/dQn3f.TSE8upaPmw/5y1nHrA24Kx2OfCzE/

real    0m0.284s <--
user    0m0.281s
sys     0m0.000s

In hashcat‘s nomenclature, SHA512 with its $6$ prefix is hash type 1800:

1800 | sha512crypt $6$, SHA512 (Unix)

Start cracking the 5000-round hash. --attack-mode 3 means “brute force”:

$ hashcat --status --attack-mode 3 --hash-type 1800 --increment shadow-sha512

The hash rate on this system’s GPU turns out to be about 90000 hashes per second, and finding the 4-character password generated by openssl rand -hex 2 succeeds in about 30 seconds.

Speed.#1.........:    90438 H/s (4.43ms) @ Accel:64 Loops:512 Thr:64 Vec:1

On to the 640000-rounds hash:

$ hashcat --status --attack-mode 3 --hash-type 1800 --increment shadow-sha512-640000rounds

After a very long time grinding the really short password increments, which it obviously isn’t optimized for, hashcat eventually ramps up to around 500 hashes per second.

I stopped the attempt after an hour when the system was approaching 50 degrees on the outer case.

systemd-Timer für Crontab-User

Ich bin wirklich dazu übergangen, mich komplett auf systemd-Timer statt Crontab-Einträge einzulassen, lediglich die Zeitangaben für kalendergebundene Events machen mir dauerhaft zu schaffen. Mir ist ein Rätsel, dass die allwissenden systemd-Entwickler darauf verzichtet haben, eine zusätzliche Konfigurationsmöglichkeit über die bekannten, selbsterklärenden und intuitiv verständlichen Crontab-Spezifikationen zu akzeptieren. Hier also eine Handvoll Beispiele:

WannCrontabOnCalendar
Täglich um Uhr45 13 * * *13:45:00
Alle 5 Minuten*/5 * * * **:00/5:00
Montags, Mittwoch, Donnerstag um Uhr14 9 * * 1,3,5Mon,Wed,Fri 09:14:00
Montag bis Freitag um Uhr0 4 * * 1-5Mon..Fri 04:00:00
Jeden Monatsersten um Uhr0 6 1 * **-*-1 06:00:00
Alle 5 Minuten von 06:00 – 17:55*/5 6-17 * * *06..17:00/5:00
⚠️ Achtung: In der Tabelle sind non-breakable Spaces enthalten. ⚠️
Die Werte sind somit nicht für copy&paste geeignet.

Zum Testen mit systemd-analyze wird die jeweilige Definition mit Anführungszeichen übergeben:

systemd-analyze calendar --iterations=10 'Mon,Wed,Fri 09:14:00'

In der Timer-Unit dürfen dann keine Anführungszeichen stehen, und nein, das ergibt überhaupt keinen Sinn.

[Unit]
Description=Ein kalenderbasierter Timer

[Timer]
OnCalendar=Mon,Wed,Fri 09:14:00

[Install]
WantedBy=timers.target

Alternativ, insbesondere bei hoher Ausführungsfrequenz oder bei Überschneidungsgefahr, benutze ich, wenn ich schon in systemd unterwegs bin, heute gern monotone Timer.

[Unit]
Description=Ein monotoner Timer

[Timer]
OnStartupSec=60
OnUnitInactiveSec=900

[Install]
WantedBy=timers.target

Versuche, hybride Timer mit Elementen aus beiden Timer-Typen zu konfigurieren, haben bei mir keine Fehlermeldungen produziert, aber der OnCalendar-Teil der Konfiguration wurde ignoriert. Das genaue Verhalten scheint nicht definiert zu sein.

WantedBy sollte bei Timern im Systemkontext auf timers.target lauten, da damit die NTP-Synchronisation vorm Start des Timer sichergestellt ist. Im Userkontext (Wallpaperchanger, Zeiterfassung, dies das) steht nur default.target zur Verfügung.


Inb4, warum überhaupt auf systemd-Timer statt crontab einlassen? Ganz einfach, weil systemd-Timer absolut narrensicher zu managen sind:

  • Du willst einen systemd-Timer verteilen/managen/paketieren? Kein Problem. Zwei Dateien nach /etc/systemd/system packen, systemctl daemon-reload, systemctl enable, fertig. Anders als in der Crontab musst du dir keine Meta-Syntax ausdenken, um zu identifizieren, ob der Eintrag schon da ist, und um ihn punktgenau löschen zu können.
  • Du willst einen vorinstallierten Timer anpassen? Ebenfalls kein Problem. Du legst ein Drop-In daneben, in dem du deine neue Timer-Spezifikation hinterlegst, etwa /etc/systemd/system/apt-daily.timer.d/local.conf als Drop-In für /lib/systemd/system/apt-daily.timer.

Grundlagen zu Timern finden sich etwa im Arch-Wiki oder bei Ubuntu Users.

10 Jahre Threema

Schon 2012 war WhatsApp enorm populär und bereits bei so manchem im Ungnade gefallen. Am 12. Dezember betrat dann Threema die Bühne, und ich war natürlich einer der Early Adopter.

Abends gab es eine Team-Weihnachtsfeier in dem Kundenprojekt, in dem ich damals arbeitete. Dort eskalierte die Peer Pressure dann irgendwie derart, dass ich mit 10 oder 20 valide gescannten Threema-Kontakten nach Hause kam. Das Projekt gibts nicht mehr, nicht mal mehr den Kunden von damals, aber die gescanneten Kontakte von damals sind immer noch da.

Threema krankt leider immer noch ein wenig daran, dass es keinen unabhängig von der App funktionsfähigen Desktop-Client gibt, so dass die App bei wirklich hohem Kommunikationsaufkommen etwas unkomfortabel wird. Backup und Restore der Threema-ID sind nach wie vor insofern etwas schwierig, wie man ein paar Handgriffe (PDF) investieren muss um sich auf den Ernstfall vorzubereiten. Ob dieser Aufwand in einem guten oder schlechten Verhältnis zum zu erwartenden Nutzen steht, bleibt jedem selbst überlassen. Meine ursprüngliche ID zumindest wurde bereits über mehrere Handys und Betriebssysteme migriert.

Andere Komfortfunktionen, wie etwa die fehlende Bindung an die Telefonnummer, fallen eindeutig zugunsten der Privatsphäre der Anwender aus. Wenn man möchte, funktioniert der Messenger bis heute anonym nur über die Threema-ID.

Threema gibts aktuell mit 50% Rabatt in den App Stores.

IBM RS/6000 von 1993

Von den Leuten, die uns “STRG”, “ENTF” und “EINFG” gebracht haben, ein Highlight, das sich leider nie durchgesetzt hat: Die GRDST-Taste.

Diese RS/6000 hat den Weg zu mir so um 2000 gefunden, als mein erster Vollzeit-Linuxjob noch ein paar Jahre entfernt war.

Damals kuschelte IBM etwas widerwillig mit Linux und hatte auf AIX 4.3.3 parallel zur Einführung von AIX 5L (das L sollte für die Nähe zu Linux stehen) RPM als additiven Paketmanager eingeführt. Die Liste der damals verfügbaren Pakete kann bei bullfreeware.com bewundert werden (hier ein lokaler Mirror). Ich habe zuletzt noch einige davon installiert, um das Tool zum Benchmarking übersetzen zu können.

Zur 7012 besitze ich auch noch das passende SCSI-CDROM mit der passenden obskuren Blockgröße. Installationsmedien sind aber keine mehr vorhanden. Die Demo-Installation mit User root und Password root muss also für immer halten. Außer AIX ist mir kein Betriebssystem bekannt, das auf dem System nutzbar wäre.

SSH fehlt, aber per Telnet über den wackeligen AUI-Transceiver mit 10 Megabit/s macht das System einen sehr guten und responsiven Eindruck, fast besser als heute manche VMware-Instanz. 😉

Die Towers of Hanoi aus dem BYTE Unix Benchmark führt die RS/6000 mit ca. 1050 Loops pro Sekunde aus. Ein halbwegs aktuelles Vergleichssystem mit Intel-CPU und 3,6 GHz kommt auf ca. 3200000 Loops pro Sekunde.

Divisionen in der folgenden Schleife macht die RS/6000 mit 16500/s (Perl 5.5 vorinstalliert) bzw. 14500/s (Perl 5.8 aus dem RPM); mein moderneres Vergleichssystem kommt auf knapp 7 Millionen/s.

perl -e '$o=time();$s=$o;while(10>$o-$s)
{rand()/(rand()+1);$i++;$n=time();if($n!=$o)
{printf"%i\n",$i;$i=0};$o=$n}'

Softwaretechnisch größtes Highlight dürfte das installierte Java 1.1.8 sein. IPv6 wird zur Konfiguration angeboten, funktioniert aber in dieser aus dem Jahr 1999 stammenden Implementation nicht wirklich zufriedenstellend.

Technische Daten: POWER1-Prozessor mit 50 MHz, 128 MB Arbeitsspeicher, 2 GB Festplatte. Produktionszeitraum 1993-1994. (Mirror vom Datenblatt)

(Dieser Beitrag stand 2014 schon mal an anderer Stelle. Die Benchmarks auf heutigen Systemen wurden aktualisiert und ein lokaler Mirror der Bullfreeware-Liste und des Datenblatts gesichert.)

Too good to #0006

“Sudo on demand” from TGT0003 considered more useful for downgrading privileges on the fly

#!/usr/bin/env bash

want_user=letsencrypt
am_user="$(id -un)"
printf "Running as: %s\n" "${am_user}"
if [[ "${want_user}" != "${am_user}" ]]
then
        printf "Re-executing with sudo.\n"
        exec sudo -u "${want_user}" "${0}"
fi
...

JSON export of all installed packages on Debian/Ubuntu

#!/bin/bash

function dpkg_json(){
    printf "{\n"
    format='"${Package}": { "Version": "${Version}", "Architecture": "${Architecture}", "Status": "${db:Status-Abbrev}" },\n'
    dpkg-query --show --showformat="${format}" | sed '$s/,$//'
    printf "}\n"
}

dpkg_json | jq .

Urlwatch for a new version of a package in the Ubuntu package pool

---
name: "Ubuntu Curtin package (waiting for apt-key fix)"
url: http://archive.ubuntu.com/ubuntu/pool/main/c/curtin/
filter:
  - xpath: //table//td[2]
  - html2text
  - grep: ^curtin.*\.deb$
---

Letsencrypt und DNS Round-Robin

Ich weiß jetzt wieder, wie ich Letsencrypt auf DNS Round-Robin mit zwei Servern aufgesetzt hatte und finde es auch mit einigen Jahren Abstand gar nicht mal so schrecklich.

Die Server kennen sich auf Port 80 unter ihrem Namen im Round-Robin und unter einem eigenen Rollennamen:

ServerName www.example.com
ServerAlias www-foo.example.com
ServerName www.example.com
ServerAlias www-bar.example.com

mod_rewrite auf Port 80 fängt zunächst mal alles ab, was nicht nach Letsencrypt aussieht und leitet nach HTTPS weiter; hier auf www-foo.example.com:

ServerName www.example.com
ServerAlias www-foo.example.com

RewriteEngine On

RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Was jetzt noch übrig bleibt, wird daraufhin geprüft, ob a) die angeforderte Challenge im Dateisystem nicht vorhanden ist und b) der Request an den Namen aus dem Round-Robin gestellt wurde (um endlose Proxy-Rekursionen zu verhindern). Falls die Challenge lokal nicht existiert, wird der Request per Reverse Proxy an einen nachgelagerten Server gestellt:

ServerName www.example.com
ServerAlias www-foo.example.com

RewriteEngine On

RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteCond %{HTTP_HOST} "www.example.com"
RewriteRule ^/(.*)$ http://www-bar.example.com%{REQUEST_URI} [P,QSA,L]

Mit 2 Servern ist klar, wo die Challenge zu holen ist. Bei 3 und mehr Servern würde ich eher nicht riskieren, in multiple Proxy-Weiterleitungen zu gehen, sondern mod_rewrite über RewriteMap aktiv ermitteln lassen, auf welchem der anderen Server die Challenge denn tatsächlich liegt.

Too good to #0005

Prioritizing own NTP servers for systemd-timesyncd

# cat /etc/systemd/timesyncd.conf.d/timesyncd-corporate.conf 
[Time]
NTP=ntp1.example.com ntp2.example.com ntp.ubuntu.com

Test if text is empty (even if it does contain a linebreak)

Good job by: https://unix.stackexchange.com/q/386499/2028

if ! grep -q '[^[:space:]]' "${file}"; then echo "Text is empty"; fi

Watch for changes in the Gnome registry

(To reproduce manual changes, for configuration management.)

dconf watch / # (Sorry, thats all)

Trigger Debian/Ubuntu unattended-upgrade

(For testing configuration changes)

rm /var/lib/apt/periodic/*
systemctl start apt-daily.service 
systemctl start apt-daily-upgrade.service 

And remember:

tail -f /var/log/unattended-upgrades/*log

Too good to #0004

systemd, the good parts: monotonic timers

When systemd makes you suffer because “run job every 10 minutes” is infinitely harder to specify than in crontab, remember there are monotonic timers in systemd that aren’t derived from wallclock time, or “Calendar Events” as they call it.

Run timer once 60 seconds after system startup, then every 10 minutes after the job finished:

# /etc/systemd/system/demo.timer
[Unit]
Description=demo monotonic timer

[Timer]
OnStartupSec=60
OnUnitInactiveSec=600

[Install]
WantedBy=timers.target    # When in a system session
# WantedBy=default.target # When in a user session (~/.config/systemd, systemctl --user etc.)

Python: Use tabulate to format output in columns

#!/usr/bin/env python3
from tabulate import tabulate

data = [
	[ 'foo', 'bar', 'baz' ],
	[ 'spam', 'eggs', 'bacon' ]
]

headers = ['Eine', '2', 'Whatever']

print(tabulate(data, headers=headers, tablefmt='simple'))

Output:

$ ./tab.py 
Eine    2     Whatever
------  ----  ----------
foo     bar   baz
spam    eggs  bacon

virsh/libvirt, automate key presses

(* Updated to sleep 5 seconds after each keypress.)

for key in R E I S U B; do virsh send-key "${domain}" KEY_LEFTALT KEY_SYSRQ KEY_${key}; sleep 5; done

Too good to #0003

Linux uptime in seconds, once and for all

awk '{printf "%i\n", $1}' /proc/uptime

“Sudo on demand”, re-exec shell script with sudo if not running as root

#!/usr/bin/env bash
printf "Running as: %s\n" "$(id -un)"
[[ ${EUID} -ne 0 ]] && printf "Re-executing with sudo.\n" && exec sudo "${0}"

See also TGT0006, this is just as useful for downgrading privileges on the fly.


“When was the last time apt-get on that Debian/Ubuntu machine installed package upgrades?”

  • Reliably answering this is a lot harder than it looks, subject of countless discussions and really does need to parse /var/log/apt/history.log, which is painful.
  • The script below maintains a file /var/log/apt/lastupgrade with the last upgrade’s time stamp, for further processing.
  • Does NOT track invocations of apt-get upgrade that did not lead to package upgrades.
  • Does NOT look behind logfile rotations, which should not be a problem because it’s closely hooked to dpkg.

/usr/sbin/apt-lastupgrade:

#!/bin/bash

while IFS=: read -r key value
do
	if [[ "${key}" == 'Start-Date' ]]
	then
		upgraded=0
	elif [[ "${key}" == 'Upgrade' ]]
	then
		upgraded=1
	elif [[ "${key}" == 'End-Date' ]]
	then
		if [[ ${upgraded} -eq 1 ]]
		then
			printf -v lastupgrade "%s" "${value}"
		fi
		upgraded=0
	fi
done < /var/log/apt/history.log

if [[ -v lastupgrade ]]
then
	tee /var/log/apt/lastupgrade <<-Here
	# Timestamp of last upgrade: ${lastupgrade}
	Here
	touch -d "${lastupgrade}" /var/log/apt/lastupgrade
fi

/etc/apt/apt.conf.d/90lastupgrade:

DPkg::Post-Invoke {"/usr/bin/systemd-run --on-active=60 /usr/sbin/apt-lastupgrade || /bin/true"};

Path of running shell script, dirname for locating config files, includes etc.

me_path="$(readlink -f "${0}")"
me_dir="$(dirname "${me_path}")"
me_base="$(basename "${me_path}")"

Too good to #0002

Show and update the comment in an SSH private key

ssh-keygen -l -f <keyfile> # show
ssh-keygen -c -f <keyfile> # change interactively
ssh-keygen -c -C <newcomment> -f <keyfile> # change and provide new

ssh-agent in Gitlab CI/CD

  • Define SSH_KEY as a “file” in Gitlab CI/CD variables and SSH_PASSPHRASE as a regular variable
  • If libcrypto errors on execution, make sure SSH_KEY has an additional line ending at the end
before_script:
  - DEBIAN_FRONTEND=noninteractive apt-get update -y
  - DEBIAN_FRONTEND=noninteractive apt-get install -y openssh-client

sftp_to_somewhere:
  stage: deploy
  script:
    - chmod 600 "$SSH_KEY"
    - eval $(ssh-agent)
    - ssh-add "$SSH_KEY" <<< "$SSH_PASSPHRASE"
    - ssh-add -l

Urlwatch, but with a local pop-up window on Linux, no additional infrastructure

Systemd user service:

# ~/.config/systemd/user/urlwatch-to-zenity.service
[Unit]
Description=urlwatch to zenity (service)

[Service]
Type=oneshot
ExecCondition=sh -c 'nmcli net co | grep full'
ExecCondition=sh -c 'urlwatch > %h/.cache/urlwatch.out'
ExecCondition=sh -c 'test -s %h/.cache/urlwatch.out'
ExecStart=sh -c 'zenity --title Urlwatch --text-info --width=600 --height=400 --filename=%h/.cache/urlwatch.out'

[Install]
WantedBy=default.target

Systemd timer:

# ~/.config/systemd/user/urlwatch-to-zenity.timer
[Unit]
Description=urlwatch to zenity (timer)

[Timer]
OnStartupSec=1h
OnUnitInactiveSec=2h

[Install]
WantedBy=default.target

cookiecount – Load a page and show the cookies it sets

$ ./cookiecount https://example.com
0 cookies received.

ps1_anon.bash – anonymize bash prompt, for screenshots and pastes

# Anonymize bash prompt for screenshots and pastes
# Source from or add to ~/.bashrc
function ps1_anon (){
	if [[ -v SAVED_PS1 ]] 
	then
		PS1="${SAVED_PS1}" 
		unset SAVED_PS1 
	else
		SAVED_PS1="${PS1}" 
		PS1='\$ '
	fi
}

Example:

[martin@idefix ~/devel/cookiecount(main=)]$ ps1_anon
$ ./cookiecount https://reddit.com --json | jq .cookiecount
7
$ ps1_anon
[martin@idefix ~/devel/cookiecount(main=)]$

What goes up, must come down. Ask any system administrator.