IT-Blog von Sebastian van de Meer

Schlagwort: Abuse

Bash-Skript: Automatisiertes Erstellen von Abuse-E-Mails

Das Problem

Wer ein System mit öffentlicher IP betreibt, kennt das: Kaum ist der Server online, hämmern Bots und Script Kiddies auf SSH, Postfix und alles, was nach Dienst aussieht. Fail2Ban sperrt die Adressen, meldet sie an AbuseIPDB und verteilt die Sperren auf die anderen Kisten. So weit, so automatisch.

Screenshot der Konsolenausgabe vom Abuse Script.

Aber was ist mit dem Hoster oder ISP hinter der IP? Meistens steckt ein kompromittierter Root-Server oder VPS dahinter. Vielleicht weiß der Admin noch gar nichts davon. Im whois zur IP findet sich eine abuse-mailbox, an die man sich wenden kann.

➜  ~ whois 8.8.8.8|grep -i abuse
OrgAbuseEmail:  ipaddressing@level3.com
OrgAbuseEmail:  network-abuse@google.com

Ehrlich gesagt: Der Großteil dieser Abuse-Mails landet beim Empfänger in /dev/null. Rückmeldungen bekommt man fast nie, und oft hat es schlicht keinen Effekt. Hin und wieder hilft es aber jemandem. Deshalb schiebe ich ab und zu einen Abuse an, will dabei aber so wenig Arbeit wie moeglich reinstecken.

Abuse melden: Was gehört rein?

Damit der Empfänger etwas mit der Meldung anfangen kann, sollte sie folgende Informationen enthalten:

  • Die IP-Adresse des eigenen Systems.
  • Die IP-Adresse, von der die Angriffe kommen.
  • Ein paar Zeilen aus dem Logfile, die das Problem zeigen.
  • Die Zeitzone des eigenen Systems, damit die Zeitangaben im Log nutzbar sind.
  • Eine kurze Beschreibung des Problems.
  • Die Erlaubnis, die Kontaktdaten an den Kunden weiterzugeben.

Das Script

Da mich Fail2Ban direkt mit dem whois zur IP informiert, brauche ich nur noch etwas, das die restlichen Informationen einsammelt und die Mail generiert. Dafür habe ich folgendes Bash-Script geschrieben. Man übergibt die IP und die Abuse-Adresse, das Script validiert beides, sammelt die passenden Zeilen aus dem auth.log, baut die Mail zusammen und schickt sie nach einer Sichtkontrolle ab.

#!/usr/local/bin/bash

if [ "$1" == "-h" ] ; then
    printf "You can add abuse ip and mail on start or interactive by request."
    printf "Usage 1: abusemail.sh 1.2.3.4 example@example.org"
    printf "Usage 2: abusemail.sh"
    exit 0
fi

myip="1.2.3.4"
bcc="my@mail.com"


function validateMail()
 {
         local mail=$1
         local stat=1
         if [[ "$mail" =~ ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$ ]]; then
                stat=0
        fi
        return $stat
}

function validateIP()
 {
         local ip=$1
         local stat=1
         if [[ $ip =~ ^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$ ]]; then
                OIFS=$IFS
                IFS='.'
                ip=($ip)
                IFS=$OIFS
                [[ ${ip[0]} -le 255 && ${ip[1]} -le 255 \
                && ${ip[2]} -le 255 && ${ip[3]} -le 255 ]]
                stat=$?
        fi
        return $stat
}
clear
printf "\x1b[31;1;4mCreate und send abuse e-mail!\x1b[0m\n\n"
printf "Enter IP Address"

if [ "$1" == "" ] ; then
    read ip
else
    ip=$1
fi

validateIP $ip

if [[ $? -ne 0 ]];then
  printf "Invalid IP Address ($ip)"
  exit 1
else
  printf "$ip ==> \x1b[32;1;4mOK\x1b[0m\n\n"
fi
printf "\n"
printf "Enter Abuse E-Mail Address"

if [ "$1" == "" ] ; then
    read mail
else
    mail=$2
fi

validateMail $mail

if [[ $? -ne 0 ]];then
  printf "Invalid Abuse E-Mail Address ($mail)"
  exit 1
else
  printf "$mail  ==> \x1b[32;1;4mOK\x1b[0m"
fi

printf "Dear abuse team,\n\nI got some SSH connections from one of your IPv4 addresses. It seems to\nbe a bot or something....\n\nYes, you can forward this E-Mail with contact informations to your \ncustomer to solve this case, if necessary.\n\nMy timezone: Europe/Berlin\nMy IPv4: $myip\nYour IPv4: $ip\n\nSome log snippets:\n" > /tmp/abusemail
grep $ip /var/log/auth.log >> /tmp/abusemail
printf "\nBest regards\nSebastian van de Meer\n" >> /tmp/abusemail


printf "\n\n\n\x1b[31;1;4mCheck e-mail before sending!\x1b[0m\n\n"
printf "\x1b[32;1;4mRecipient:\x1b[0m $mail\n\n"
printf "\x1b[32;1;4mSubject:\x1b[0m Abuse against: $ip - Brute Force\n\n"
cat /tmp/abusemail
printf "\n\n"

while true
do
 printf "\x1b[33;1;4mSend Abuse Mail? [Y/n]\x1b[0m\n"
 read -r input

 case $input in
     [yY][eE][sS]|[yY])
 cat /tmp/abusemail | /usr/local/bin/mailx -s "Abuse against: $ip - Brute Force" -r "My Name " -b $bcc $mail
 printf "Abuse Mail is on it's way..."
 break
 ;;
     [nN][oO]|[nN])
 printf "Abuse Mail aborted"
 break
        ;;
     *)
 printf "Invalid input..."
 ;;
 esac
done

Das Script ist alt, stumpf und einfach. Es tut genau das, was es soll: Arbeit abnehmen bei einer Aufgabe, die sich meistens sowieso nicht lohnt. Wer das Thema automatisierter weitertreiben will, kann sich mal SSH-Bruteforce und AbuseIPDB anschauen. Dort geht es darum, wie Fail2Ban und AbuseIPDB zusammenspielen.

Fazit

Abuse-Mails sind undankbar. Die meisten verpuffen, manche helfen. Wer trotzdem ab und zu eine rausschicken will, ohne jedes Mal alles von Hand zusammenzusuchen, hat mit so einem Script zumindest den Aufwand minimiert.

Fragen? Einfach melden.

Die vergessenen abuse und postmaster Adressen

Für jede Domain, die E-Mail empfängt, muss es eine postmaster@ und eine abuse@ Adresse geben. E-Mails an diese Adressen müssen angenommen werden, und jemand sollte sie auch lesen. Geregelt ist das in RFC 5321 und RFC 2142.

Wofür die Adressen da sind

postmaster@domain.tld ist für technische Fragen zum Mailsystem. Wenn jemand Probleme hat, E-Mails an eine Domain zu schicken, wendet er sich an den Postmaster. Im schlechtesten Fall sitzt dort ein Mensch, der die Nachricht an den richtigen Admin weiterleiten kann.

abuse@domain.tld ist für Missbrauchsmeldungen. Wird die Domain zum Spam-Versand missbraucht, schreibt man an abuse. Eine Abuse-Adresse findet sich auch im WHOIS der meisten IP-Netze.

Warum das in der Praxis scheitert

Immer wieder kommen Beschwerden bei mir an, weil E-Mails an gehostete Domains abgewiesen werden. Also sucht man den Grund, findet ihn im Reject (Blockliste, fehlender Reverse-DNS, dynamische IP) und schreibt dem Postmaster der Absenderdomain. Vier Sekunden später kommt die Antwort: „Postfach nicht gefunden“ oder „Mailbox voll“.

Die Adressen existieren nicht, oder niemand liest sie. Das ist nicht nur ein Verstoß gegen die RFCs. Es macht die Fehlersuche für alle Beteiligten unmöglich.

Das eigentliche Problem: Filter

Selbst wenn die Adressen existieren, reicht das nicht. Wenn jemand Probleme hat, E-Mails an unsere Domain zu schicken, versucht er es über postmaster@. Wird diese E-Mail ebenfalls gefiltert, hat der Absender verloren. Ein Hinweis auf ein echtes Problem mit dem Mailsystem erreicht uns nicht.

Die Lösung: postmaster@ und abuse@ müssen an allen Filtern vorbei. Sowohl in Postfix als auch im Content-Filter.

Postfix: Empfänger whitelisten

In /etc/postfix/recipient-access die beiden Adressen mit OK eintragen:

# /etc/postfix/recipient-access
postmaster@kernel-error.de    OK
abuse@kernel-error.de         OK

Danach die Hash-Datei erzeugen:

postmap /etc/postfix/recipient-access

In /etc/postfix/main.cf muss check_recipient_access vor den Restrictions stehen. Die Reihenfolge ist entscheidend: Postfix arbeitet die Regeln von oben nach unten ab, die erste passende greift.

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        check_recipient_access hash:/etc/postfix/recipient-access,
        reject_rbl_client zen.spamhaus.org,
        ...

Alle nachfolgenden HELO-Checks und RBL-Prüfungen greifen jetzt nicht mehr auf E-Mails an postmaster@ und abuse@.

Wo im SMTP-Dialog prüfen?

Postfix bietet mehrere Stellen für Restrictions:

smtpd_client_restrictions — nach connect
smtpd_helo_restrictions — nach HELO/EHLO
smtpd_sender_restrictions — nach MAIL FROM
smtpd_recipient_restrictions — nach RCPT TO
smtpd_data_restrictions — nach DATA
smtpd_end_of_data_restrictions — nach der Übertragung

Je früher man ablehnt, desto weniger Ressourcen verbraucht man. Wer im HELO prüft, nimmt erst gar keinen Empfänger entgegen. Wer erst nach DATA prüft, hat die komplette E-Mail schon angenommen. Für die meisten Setups ist smtpd_recipient_restrictions der sinnvolle Kompromiss.

Content-Filter: Spam durchlassen

Postfix lässt die E-Mails an postmaster@ und abuse@ jetzt durch. Aber der Content-Filter dahinter wird sie trotzdem filtern, wenn man ihm nicht sagt, dass er sie in Ruhe lassen soll.

In rspamd geht das über eine settings.conf Regel, die bestimmte Empfänger vom Spam-Filtering ausnimmt. In AMaViS (falls noch im Einsatz) über @spam_lovers_maps in /etc/amavis/conf.d/50-user:

# AMaViS: /etc/amavis/conf.d/50-user
@spam_lovers_maps = (
  [
    "postmaster\@kernel-error.de",
    "abuse\@kernel-error.de",
  ]
);

Das bedeutet nicht, dass die E-Mail nicht geprüft wird. AMaViS testet weiterhin, lässt die Nachricht aber durch. Viren und verdächtige Anhänge filtere ich an dieser Stelle weiterhin. Nur Spam darf passieren. Denn wenn mir jemand über eine dynamische IP per Telnet eine Nachricht an postmaster@ schickt, soll sie ankommen.

Wer sich grundsätzlich gegen Spoofing absichern will: SPF hilft dabei, festzulegen, welche Server für eine Domain senden dürfen.

Fragen? Einfach melden.

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑