chr.istoph, der Blog

Unser Vortag auf der #FrOSCon17 ist Online:

Wir waren fleißig und haben am vergangenen Wochenende, endlich nach 5 Jahren Arbeit, Tui Widgets veröffentlicht.

Für unseren Vortag: Tui Widgets: Ein Baukasten für Terminal-Anwendungen auf der #FrOSCon17 erstellen wir gerade die Präsentation und Doku.

Für eine Video Projekt habe ich ein Script das in einer Schleife ein Einminütiges Video erstellt und dieses danach verarbeitet. Damit man die Erstellung sauber beenden kann, habe ich beim Starten eine Datei angelegt und zum beenden wird diese Datei wieder gelöscht. In der schleife wird immer abgefragt ob diese noch Existiert:

#!/bin/bash
touch run
trap "rm run" 0 15
while [ -f run ]; do
  ffmpeg ...
  ./verarbeitung.sh &
done

So kann man das Skript sehr gut von „außen“ steuern. Ein weiteres Script zum verarbeiten, das sich ebenfalls in der schleife befindet, habe ich geforkt.

Nun habe ich das Script auf einen systemd Service umgestellt, bei dem ich auf zwei Probleme gestosen bin.
1. Systemd beendet das Script und alle hiervon aufgerufenen Programme ebenfalls mit Signal 15. Das bedeutet das, dass Video erstellen und verarbeiten umgehend unterbrochen werden.
2. Das „verarbeitung.sh“ Script ist eigentlich vollkommen unabhängig und es muss nicht auf dessen Beendigung gewartet werden.

Lösung:
Im SystemD Services habe ich den Kill Mode auf Mixed umgestellt. Das Sendet nur noch an eigentliche Script ein Signal 15. Hier tiggert dann der trap und löscht die Datei zum Beenden der Schleife.

[Service]
KillMode=mixed

Den fork habe ich mit mit systemd-run in eine eigene Unit verfrachtet. Somit kann die Verarbeitung abgeschlossen werden und SystemD kann den Dienst als beendet erklären.

systemd-run --unit "verarbeitung-$(date +%y%m%d-%H%M%S)" ./verarbeitung.sh

Einen debug modus für dhclient habe ich leider vergeblich gesucht. Es gab weder ein simulate noch ein oder „–dry-run“ womit ich eine Adressermittlung und was es genau machen würde. Da es sich bei den von dhclient aufgerufenen Scripten um Bash scripte handelt, habe ich diese kurzerhand umgeschrieben.

Unter /sbin/dhclient-script liegt das Script das das von dhclient nach erfolgreicher Adressermittlung aufgerufen wird. Hier habe ich alle aktiven iproute2 Kommandos gegen echo’s ersetzt und alle hooks endfernt. Im Beispiel eines Bridgeinterface für eine Freifunk Verbindung sah das so aus:

dhclient  -v br-ffac
Internet Systems Consortium DHCP Client 4.1-ESV-R4
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

  ip link set dev br-ffac up
Listening on LPF/br-ffac/fe:54:00:78:80:96
Sending on   LPF/br-ffac/fe:54:00:78:80:96
Sending on   Socket/fallback
DHCPREQUEST of 10.5.20.96 on br-ffac to 255.255.255.255 port 67
DHCPACK of 10.5.20.96 from 10.5.16.2
  ip -4 addr add 10.5.20.96/255.255.240.0 broadcast 10.5.31.255 dev br-ffac label br-ffac
  ip link set dev br-ffac mtu 1406
  ip -4 route add default via 10.5.16.2 dev br-ffac
bound to 10.5.20.96 -- renewal in 1367 seconds.

Das vollständig umgeschriebene dhclient-script das ich auf einen Ubuntu 12.04 angepasst habe, habe ich hier: (mehr …)

Ich habe im August 2014 bereits eine Lösung mit iptables und fail2ban geschrieben. Da diese aber zu viele „fals positiv“ produziert hat, habe ich mich noch einmal hingesetzt und eine sowohl auf Performance als auch ohne fail2ban optimierte Lösung gesucht.

Mein zweiter Ansatz geht so vor, dass zuerst alle post requests in eine eigene iptbatles chain gepackt werden. Anschließen werden die in der chain noch übrig bleibenden anfragen nach den Schlüsselwörtern wie wp-login.php oder xmlrpc.php untersucht und mit einem Counter von 3 versehen. Beim dritten versuch ein falsches Passwort anzugeben werden die IPs der Botts für 600sec gesperrt.

iptables -A INPUT -p tcp --dport 80 -m string --algo bm --string "POST " -j HTTPPOST

iptables -A HTTPPOST -m string --algo bm --string "/wp-login.php" -m state --state NEW,ESTABLISHED -m recent --set --name "wp-auth"
iptables -A HTTPPOST -m string --algo bm --string "/wp-login.php" -m state --state NEW,ESTABLISHED -m recent --update --seconds 600 --hitcount 3 --name "wp-auth" -j DROP

iptables -A HTTPPOST -m string --algo bm --string "/xmlrpc.php" -m state --state NEW,ESTABLISHED -m recent --set --name "wp-xmlrpc"
iptables -A HTTPPOST -m string --algo bm --string "/xmlrpc.php" -m state --state NEW,ESTABLISHED -m recent --update --seconds 600 --hitcount 3 --name "wp-xmlrpc" -j DROP

iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT -m comment --comment "HTTP"

UPDATE: Danke an Jens, die SSL Regeln für Port 443 können so natürlich nicht funktionieren und wurden entfernt.