fail2ban – was machen wenn man sich selber ausgesperrt hat?

fail2ban ist ein tolles Werkzeug um ungebetene Gäste von seinem Server fern zu halten. Nach vordefinierten Regeln überwacht fail2ban in Echzeit die Logfiles nach verdächtigen Angriffsmustern. Nach einer frei definierbaren Anzahl an Fehlversuchen wird die verursachende IP-Adresse für eine ebenfalls frei definierbare Zeit durch iptables geblockt. Die häufigesten Angriffsversuche sind mit brute-force-Angriffen auf den ssh-Daemon Angriffe auf WordPress oder Postfix bzw. Dovecot, also das Mailsystem. Nun kann es vorkommen, dass man sich bzw. seine IP-Adresse unbeabsichtigt selber aussperrt. Das kann durch Schusseligkeit aber auch durch einen fehlkonfigurierten Email-Client oder ähnlichem vorkommen. fail2ban bzw. iptables macht keinen Unterschied zwischen den Diensten beim Sperren von IP-Adressen. Das hat nun den blöden Nebeneffekt, dass man für eine bestimmte Zeit keinen Zugriff mehr auf seinen Server hat.

Zunächst muss man seine eigene öffentliche IP-Adresse heraus bekommen. Da die meisten Menschen heutzutage über einen Router mit NAT im Internet sind entspricht die IP-Adresse im lokalen Netzwerk nicht seiner öffentlichen IP-Adresse. Die öffentliche IP-Adresse ist meist die internetseitige IP-Adresse des Routers. In der Shell kann man seine öffentliche IP-Adresse einfach ermitteln:

$ host myip.opendns.com resolver1.opendns.com | grep "myip.opendns.com has" | awk '{print $4}'
123.456.789.123

Weiterlesen

Durch fail2ban geblockte IPs an AbuseIPDB melden

 

Wenn man eine funktionierende Installation von fail2ban hat kann man die geblockten IP-Adressen an AbuseIPDB weiterleiten. AbuseIPDB sammelt bösartige IPs die auf verschiedenen Weise Server angreifen. Um IP-Adressen zu melden braucht man einen API-Schlüssel. Den erhält man dadurch das man sich bei AbuseIPDB einen Account erstellt und unter API einen Schlüssel erstellt. Der API-Schlüssel ist ein längerer hexadezimaler Wert.

Leider ist das Debian-10-Paket von fail2ban so alt, dass der API-Aufruf nicht mehr funktioniert. Zum Glück ist es nur eine Datei die aktualisiert werden muss. Dazu wechselt man in das Verzeichnis /etc/fail2ban/action.d/ und lädt mit:

wget https://raw.githubusercontent.com/fail2ban/fail2ban/master/config/action.d/abuseipdb.conf

die aktuelle Datei abuseipdb.conf in das korrekte Verzeichnis. Unten in dieser Datei wird auch in der untersten Zeile bei der Variablen abuseipdb_apikey der API-Schlüssel eingetragen.

Weiterlesen

IP-Blacklist aus dem Internet per Script an iptables übergeben

Schild Zugang für Unbefugte verboten

Angriffe eines Serverdienstes ist ein lästiges Übel für einen Serverbetreiber. Diese erfolgen vermutlich durch Scripte von gekaperten Servern. Bei einem sicher konfigurierten System können diese Angriffe keinen Schaden anrichten aber sie tauchen zu Haufen in der Serverlogs auf. Es gibt Listen im Internet wo solche lästigen IP-Adressen aufgeführt sind. Mir ist aufgefallen, dass unter https://www.redim.de eine recht brauchbare Liste, die täglich aktualisiert wird, existiert die normalerweise auch meine lästigsten Kandidaten enthalten. Nun wird dort vorgeschlagen die Liste in die .htaccess-Datei zu kopieren und darüber Websites zu schützen. Leider hat dies mehrere Nachteile.

  1. Nur Websites aber nicht andere Dienste wie Email, FTP oder SSH werden geschützt.
  2. Bei dem Betreiben von mehreren Websites muss diese Liste mehrfach eingepflegt werden.
  3. Die vorgeschlagene Variante über .htaccess muss händig aktualisiert werden oder man muss ein Script dafür schreiben.

Irgendwie hat mir das nicht wirklich zugesagt und Linux bringt mit iptables ja schon ein universelles Werkzeug mit um IP-Adressen zu blocken. Um Ports muss man sich da nicht kümmern da kaum zu erwarten ist, das von einer bösartigen IP-Adresse sinnvolle Anfragen kommen.

Mit diesen Überlegungen habe ich beschlossen ein Script zu schreiben was das alles automatisiert:

Weiterlesen

Der unbekannte Befehl – „umask“ der Maskierer

Symbolisiertes Terminal

umask führt eigentlich sehr zu unrecht ein Schattendasein auf den meisten Rechnern denn umask ist ein Sicherheitsfeature was die Rechteverwaltung des Filesystems bestimmt. umask bestimmt wo und wann welche Besitzer- bzw Gruppenrechte gesetzt werden.

Bekanntlich hat unter Linux/Unix jede Datei einen Besitzer und gehört zu einer Gruppe. Unter Debian ist häufig für einen Benutzer auch der Name als Gruppe gesetzt. So gehört der Benutzer max dann der Gruppe max an. Weitere Gruppen wie floppy oder cdrom oder games können folgen. Jeder Benutzer der weder der Besitzer einer Datei ist noch der Gruppe angehört der gehört im Rechtesystem zu other.

Die wichtigsten Rechte werden in jeweils drei Bit beschrieben:

$ ls -l .bashrc
-rw-r--r-- 1 max max 3667 Jul 10 18:00 .bashrc
$ ls -ld .
drwxr-xr-x 77 max max 12288 Aug 25 23:02 .

Dabei symbolisiert die Ausgabe rwxrwxrwx die Rechte für den Besitzer, Gruppe und other (also alle anderen) und dahinter dann den Besitzer und die Gruppe zu der die Datei oder das Verzeichnis (Verzeichnisse sind unter Linux/Unix eigentlich auch nur eine besondere Art Datei) gehört.

Weiterlesen

Prüfsummen SHA1, SHA256, MD5 überprüfen

Die Grafik aus dem Film „The Matrix“

Prüfsummen oder auch Checksummen als Hash codiert dienen oft um die Authentizität einer Datei, die man aus dem Internet herunterladen kann, zu gewährleisten. Die Gebräuchlichsten sind hier md5, SHA1 und SHA256. Die Abkürzungen stehen für kryptographische Verfahren. Allen ist gemeinsam, dass eine kleine Abweichung in einer Datei zu großen Unterschieden in den Hashwerten führt. Das folgende Beispiel zeigt das Verhalten exemplarisch:

$ echo "123456789" > testfile
$ md5sum testfile && sha1sum testfile && sha256sum testfile 
b2cfa4183267af678ea06c7407d4d6d8 testfile
179c94cf45c6e383baf52621687305204cef16f9 testfile
6d78392a5886177fe5b86e585a0b695a2bcd01a05504b3c4e38bc8eeb21e8326 testfile
$ echo "023456789" > testfile
$ md5sum testfile && sha1sum testfile && sha256sum testfile 
c159e1a7fa9951401680d5e6aead65e8 testfile
d61c99de943fb8a1c707d54612961304a001a0b8 testfile
0accf17861b34d7b06477da622ff4506458593496cedf107e5403e65b10b58bd testfile

Weiterlesen

Virenscanner und Co.

Biohazard-Symbol

Was taugen Virenscanner und sind die heute noch nötig? Eine uralte Glaubensfrage die unter Windows bei der überwiegenden Anzahl an Benutzern mit einem unbedingt nötig beantwortet wird. Erst einmal aber kurz einen Ausflug nach Linux. Da kann man die Frage klar mit jain beantworten. Ein Linux-Desktop braucht sicher keinen Virenscanner weil es praktisch keine Viren dafür gibt und die welche es gibt eben nicht wirklich am Rechtesystem vorbei kommen. Maximal der Account eines Benutzers kann betroffen sein aber nicht das komplette System. Hingegen bei Dienste auf einem Server wie Email oder Samba da diese oft auch mit Windows-Clients benutzt werden kann ein Virenscanner einen Sinn machen. Ich selber benutze Clamav für Samba-Freigaben und im MTA Postfix.

Unter Windows hingegen sind Viren, Würmer und andere Malware weit verbreitet. Daher ist der Markt für Viren- und Malware-Scanner fast unüberschaubar. Viele kommen dann noch mit einer ganzen Suit an Sicherheitsprogrammen daher.

Weiterlesen

Umfangreichere Virensignatur von Clamav mit clamav-unofficial-sigs

Biohazard-Symbol

Clamav ist ein Virenscanner unter einer freien Lizenz und ist OpenSource. Wie bei jedem Virenscanner ist die Virensignatur-Datei entscheidend für die Leistungsfähigkeit des Scanners. Die Leistungsfähigkeit von Clamav gilt gemeinhin als recht schlecht. Schuld daran ist die schlechte Virendefinitiondatei. Abhilfe schaffen hier alternative Virendefinitionsdateien. Diese kann man mit dem Script clamav-unoffical.sigs abrufen. In den Quellen von Debian befindet sich nur ein uraltes Paket was mehr Fehlermeldungen produziert als es nützt. Ich stelle hier nun die Installation vor.

Weiterlesen

kais-universum.de