Datenhaufen zu IT und Elektronik.

Schlagwort: Abuse

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

Wenn man ein System mit öffentlicher IP Adresse hat, klopfen irgendwelche Bots oder ein Script Kiddie direkt nach dem Einschalten die Dienste auf mögliche Schwachstellen, schwache Zugangsdaten oder default logins ab. Kennt wohl jeder…

Davor schützt gepatchte Software, Dienste möglichst unerreichbar machen oder ein IDS (Intrusion detaction system). Im einfachsten Fall ist dieses Fail2Ban.

Was tun, wenn Fail2Ban Brute Force Angriffe auf SSH oder Postfix (Mailserver) feststellt? Tjo, die Adresse an weiteren Versuchen hindern natürlich. OK, darum kümmert sich Fail2Ban… Am besten noch so, das Fail2Ban dieses seinen anderen Kisten ebenfalls mitteilt, dann wird diese IP es dort schon nicht mehr probieren können. Ebenfalls könnte es eine gute Idee sein, dieses Verhalten der IP Adresse irgendwo zu melden. Dienste wie AbuseIPDB lassen sich gut mit Fail2Ban verbinden. So können andere Admins auf der Welt direkt davon profitieren.

Könnte man nicht zusätzlich noch den ISP oder Hoster hinter der „bösen“ IP Adresse informieren? Meist ist es ja ein Root-Server oder VPS oder, oder… Vielleicht weiß der Admin ja noch nichts von seinem kompromittierten Glück?!? Ja kann man. Dazu sollte es im whois zur IP Adresse immer eine „abuse-mailbox“ also einen „abuse-contact“ geben.

Als kleines Beispiel:

➜  ~ whois 8.8.8.8|grep -i abuse
Comment:        All abuse reports MUST include: 
OrgAbuseHandle: IPADD5-ARIN
OrgAbuseName:   ipaddressing
OrgAbusePhone:  +1-877-453-8353 
OrgAbuseEmail:  ipaddressing@level3.com
OrgAbuseRef:    https://rdap.arin.net/registry/entity/IPADD5-ARIN
Comment:        Please note that the recommended way to file abuse complaints are located in the following links. 
Comment:        To report abuse and illegal activity: https://www.google.com/contact/
OrgAbuseHandle: ABUSE5250-ARIN
OrgAbuseName:   Abuse
OrgAbusePhone:  +1-650-253-0000 
OrgAbuseEmail:  network-abuse@google.com
OrgAbuseRef:    https://rdap.arin.net/registry/entity/ABUSE5250-ARIN

An diese Adresse kann man sich nun mit seinem Anliegen wenden. Damit der angeschriebene ~Admin~ etwas mit der Meldung anfangen kann sollte sie die folgenden Informationen enthalten:

– die IP Adresse des eigenen Systems.
– die IP Adresse von welcher die Störungen kommen/gekommen sind.
– Ein paar Zeilen aus dem Logfile um das Problem verständlich zu machen.
– Die Zeitzone des eigenen Systems, damit die Datums und Zeitangaben im Logfile sinnvoll nutzbar sind.
– Eine kurze Beschreibung, warum man dieses als Problem empfindet.

Da ein Hoster diesen Abuse natürlich an seinen Kunden weitergeben wird und dieser möglicherweise noch Fragen dazu haben könnte, hilft es, wenn man direkt erlaubt die Kontaktdaten weiter zu geben.

Leider findet sich die AbuseMailbox im whois nicht immer und vor allem nicht einheitlich. Gibt man sich nun die Mühe und sammelt alle nötigen Informationen zusammen, wird man nach dem Absender der eigentlichen AbuseMail oft enttäuscht. Denn der überwiegende Teil dieser E-Mails landet einfach beim Empfänger in /dev/null. Rückmeldungen bekommt man fast nie und oft hat es einfach überhaupt keinen Effekt. Klar hin und wieder hilft es jemandem… Hier und da schiebe ich selbst so einen Abuse an. Dabei möchte ich selbstredend so wenig wie möglich Arbeit in das Thema stecken.

Da mich Systeme wie Fail2Ban direkt mit dem jeweiligen whois zur IP Adresse informieren, brauche ich nur noch etwas, was mir die anderen Informationen einsammelt und am besten direkt abschickt. Dafür habe ich folgendes bash script geschrieben.

An dieses kann ich direkt beim Aufruf durch andere scripte oder durch mich die „böse“ IP Adresse und die E-Mail-Adresse der AbuseMailbox übergeben. Das script prüft dann ob es sich um eine brauchbare E-Mail-Adresse und IP handelt, sammel zum Beispiel für SSH Brute Force die nötigen Informationen aus dem auth.log, generiert mir dann meine AbuseMail und sendet diese nach einer Sichtkontrolle ab. Ich selbst bekomme diese E-Mail dann noch als BCC. Das script ist alt, stumpf und sehr einfach. Weil die Frage nach dem script kam, hier das script:

#!/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 <myfrom@address.com>" -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

Noch Fragen? Dann fragen!

Die vergessenen abuse und postmaster Adressen

Was oft übersehen wird, ist dass es für jede Domain die Adressen postmaster@domain.tld sowie abuse@domain.tld geben muss. E-Mails an diese Adressen müssen angenommen werden und sollten auch gelesen werden!

 

Geregelt ist dieses im RFC5321 und im RFC2142 (ich verlinke hier mal auf http://www.rfc-ignorant.org , die haben es schön bunt gemacht, das ist ja für viele so wichtig)!

 

Hat man nun technische Fragen zum Mailsystem einer Domain, oder technische Anmerkungen, dann sendet man eine E-Mail an: postmaster@domain.tld
Im schlechtesten Fall sollte dort ein Mensch sitzen welcher in der Lage ist, diese E-Mail an den „echten“ Administrator weiter zu leiten.

 

Jetzt kommen immer mal wieder ~Beschwerden~ bei mir an, weil E-Mails Externer an gehostete Domains abgewiesen werden. Also macht man sich auf die Suche nach dem Grund. Der eigentliche Absender hat diesen zwar mit einer 5xx Meldung zusammen bekommen…. Die Nachricht war aber leider auf Englisch und Fehlermeldungen – vor allem in englischer Sprache – werden gerne und schnell gelöscht! Hat man den Grund also gefunden, schreibt man den Grund an den „Beschwerdeführer“ und natürlich den Postmaster der Absenderdomain. Das die E-Mail abgewiesen wurde weil sie auf eine Blockliste steht, der R-DNS nicht stimmt, alles von einer dynamischen IP kommt usw. usw…. Sehr oft hat man dann 4 – 5 Sekunden nach dem Absenden der E-Mail auch schon eine Antwort: – Sorry, Postfach nicht gefunden. / – Mailbox voll.
Es hängt ja mal schnell zusammen 😛

 

Eine E-Mail an die Abuse Adresse schreibt man immer, wenn auf einen Missbrauch hingewiesen werden soll. Wird also die Domain zum verschleudern von Spam und Viren missbraucht oder ähnliches. Eine Abuse Adresse findet sich auch im Whois der meisten IP Adressen/Netze. Sie erfüllt hier den gleichen Auftrag. Man sollte denn noch folgendes beachten. Wird eine Domain als Absender einer Spam oder Virenmail missbraucht und dieses läuft nicht über den Mailserver der Domain… Dann sind die Verantwortlichen der Domain in gewissem Umfang machtlos. Zwar kann man versuchen sich gegen so etwas mit Techniken wie SPF zu schützten. Dieses muss denn noch beim Empfänger ausgewertet werden.

 

Nun reicht es nicht nur die beiden Adressen postmaster@domain.tld sowie abuse@domain.tld anzulegen. Sondern die Absender sollten diese Adressen erreichen können. Hat jemand also ein Problem damit E-Mails an unsere Domain zu schicken, da sie immer von irgendwelchen Filtern abgewiesen wird, dann versucht er ggf. sich an den Postmaster der Domain zu wenden. Wird diese E-Mail nun ebenfalls gefiltert – dann hat der Absender verloren?!?! So könnte den Postmaster ein Hinweis auf ein echtes Problem mit seinem Mailsystem nicht erreichen. Das wäre schlecht, diese Adressen sollten also unabhängig von den Filtern immer durchgelassen werden.

 

Dieses geht über Whitelisting des jeweiligen Empfängers im Postfix und AMaViS. Denn Postfix sowie AMaViS dürfen ihre Filter nicht auf E-Mails an diesen Empfänger anwenden.

 

Hier nun ein kleines Beispiel dazu:

Postfix access-Tables

Für eine einfache Konfiguration erstellt man am einfachsten die Datei recipient-access unter /etc/postfix, der Inhalt besteht dann aus den jeweiligen Empfängeradressen und der Information was damit gesehen soll.

$ cat /etc/postfix/recipient-access
#Empfänger
postmaster@kernel-error.de    OK
abuse@kernel-error.de        OK

OK ist dabei immer erlauben

REJECT lehnt immer mit einem Error 5xx ab
In der Version 2.0 von Postfix wurde dieses Thema komplett überarbeitet. Es gibt noch viele weitere Möglichkeiten der access-tables. Hier einfach mal RTFM oder fragen.

Damit Postfix am Ende mit den Daten etwas anfangen kann fehlt noch ein:

$ postmap /etc/postfix/recipient-access

 Als letzten Schritt weisst man nun Postfix an, diese Daten auch auszuwerten. Dabei ist die Stelle ganz wichtig! Warum? Ganz einfach… Postfix hat die Möglichkeit verschiedene Filter an verschiedenen Stellen des Ablaufes zu nutzen. Die Filter werden immer von oben nach unten abgearbeitet und sobald einer passt, greift auch dieser. Sehr ähnlich wie bei einer Firewall.

So lassen sich Prüfungen an folgenden Stellen konfigurieren:

smtpd_client_restictions
nach connect

smtpd_helo_restrictions
nach helo

smtpd_sender_restrictions
nach mail from

smtpd_recipient_restrictions
nach rcpt to

smtpd_data_restrictions
nach data

smtpd_end_of_data_restrictions
nach mailübertragung

Ein solches Vorgehen ergibt schnell einen Sinn, wenn man darüber nachdenkt, wie man Last von seinem Mailserver fernhalten kann. Erwartet man zum Beispiel im HELO einen fqdm, kann man dieses direkt nach dem HELO prüfen (smtpd_helo_restrictions) und die Verbindung ggf. ablehnen. Der Mailserver nimmt also nicht noch dem Absender, den Empfänger oder gar die ganze E-Mail entgegen, bevor die Verbindung zurückgesetzt wird. Für einfache Systeme reicht es meist seine Prüfungen nach der Übergabe des Empfängers (smtpd_recipient_restrictions) zu setzten. Erst ganz am Ende (smtpd_end_of_data_restrictions) zu prüfen halte ich für gefährlich. Zwar sollte dieses Vorgehen kleinere Mailsysteme nicht weiter stressen… Denn noch hat man ja schon die komplette E-Mail angenommen, bevor man etwas damit tut. Rechtlich sicherer wäre es die Nachricht abzulehnen, noch bevor sie ganz übertragen ist.

Ich trage daher soweit oben wie möglich meine Whitliste ein:

/etc/postfix/main.cf

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        check_recipient_access hash:/etc/postfix/recipient-access,
        ...........,

Nachdem Postfix die neuen Einstellungen übernommen hat, greifen alle nachfolgenden Filter nicht mehr auf alle Empfänger mit einem OK in der /etc/postfix/recipient-access.

AMaViS spam_lovers_maps

Postfix lässt nun zwar die E-Mails durch, AMaViS wird sie denn noch grillen. Es sei denn wir sagen AMaViS dass diese Empfänger Spam Liebhaber sind 🙂

Folgender Eintrag in /etc/amavis/conf.d/50-user erfüllt dieses:

@spam_lovers_maps = (
  [
        "postmaster\@kernel-error.de",
        "abuse\@kernel-error.de",
  ]
  );

 

AMaViS testet die E-Mail nun zwar noch immer, sie wird denn noch druchgewunken. Nun gibt es nicht nur Spam Liebhaber „spam_lovers_maps“ sondern auch Viren Liebhaber „virus_lovers_maps“ oder Liebhaber gesperrter/verdächtiger Dateianhänge „banned_files_lovers_maps„. Mir kommt nur gerade kein Grund in den Sinn, warum man dem Postmaster einen „verdächtigen“ Dateianhang oder gar einen Virus schicken sollte. Daher fische ich in der Regel diese E-Mails weiterhin raus. Nur Werbung lasse ich für diese beiden Adressen passieren. So sollten mich alle E-Mails an Postmaster oder Abuse erreichen. Selbst wenn sie von einem falschen Absender per Telnet über eine dynamische und gesperrte Adresse versucht mir Viagra zu verkaufen *schnief*.

© 2024 -=Kernel-Error=-

Theme von Anders NorénHoch ↑