Wir alle mögen keinen Spam. Insbesondere mein Server nicht, wie ich die Tage durch eine Reihe seltsamer Ausfälle feststellen musste. Obwohl mein Postfix an sich recht wenig Last erzeugte, stellte ich dennoch anhand der Live-Statistiken für meinen Bindgraph – und von den zahlreichen MX-Anfragen verwundert auch im zugehörigen Mailgraphen eine stark erhöhte Anzahl von abgelehnten Mails fest. Dachte ich zuerst noch an einen mögliches Problem in der Konfiguration, weil sich ein solches durchaus bereits einmal in dieser Form geäußert hatte, zeigte ein kurzer Blick in die Logfiles nur eine durchscrollende Menge von „NOQUEUE: reject: Relay Access denied“-Meldungen.
Nun ist zwar nichts schlimmes daran, wenn ein Mailserver etwa 200 Mails je Minute bearbeiten soll – im Gegenteil zeugt es davon, dass die Konfig stimmt, wenn er dies kann, aber wenn der Server allzu schnell das Versenden von Mails hintereinander erlaubt, läd dies Spammer durchaus ein, Schabernack mit dem System zu treiben.
Also schauen wir einmal, was sich machen lässt. Als erstes fiel mir beim Live-View der Logs auf, dass 20 Mails nahezu gleichzeitig über eine Verbindung versendet werden sollten – ein mehr als typisches Verhalten von Spambots. Das „nahezu gleichzeitig“ sowie die 20 Stück je Verbindung erklären sich dabei wie folgt:
1. Der Server erzwang keine Wartezeit nach einem Fehlercode
2. Nach 20 Fehlern je Verbindung wurde zwingend die Verbindung beendet
Okay, da lässt sich was drehen:
disable_vrfy_command = yes
smtpd_error_sleep_time = 5s
smtpd_soft_error_limit = 1
smtpd_hard_error_limit = 3
Mit dieser Änderung in der Konfig gestaltete sich das Betrachten der Logs schon einmal gemütlicher. Also das heißt, die Mail.log scrollte nun nur unwesentlich schneller wie die Apache-Logfile des Gesamtservers, die auf einer anderen Screen-Konsole geöffnet war. Zwischenzeitlich hatte ich zwar das Sleep nach Errors auf 15 Sekunden, da dies aber nur unnötig viele Sockets offen hielt, hab ich mich für 5 Sekunden entschieden, was den gleichen Effekt erziehlt).
Wäre aber noch ein wenig was anderes zu tun: Erzwingen etwas restriktiverer Policies in Bezug auf die Entgegennahme von Mails. Reichten im Vorfeld auch teilweise noch unsaubere Konfigurationen der einliefernden Server vollkommen aus, müssen nun Reverse-DNS und HELO-Name stimmen, sowie vollständige UND korrekte FQDNs sein. Zusätzlich werden FQDNs nun auch für die Sender- und Empfänger-Mail-Adresse (Host-Anteil) erzwungen (Okay, wurden auch bereits vorher, aber hier kamen ein paar Prüfungen hinzu).
Somit gestaltet sich die Annahme einer Mails nun unter Einhaltung einer Reihe mehr Regeln als zuvor:
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_invalid_hostname,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname
smtpd_sender_restrictions = reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit_mynetworks,
permit_sasl_authenticated
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_destination,
reject_unlisted_recipient,
reject_rbl_client virbl.dnsbl.bit.nl,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client ix.dnsbl.manitu.net,
check_policy_service inet:127.0.0.1:12525,
check_policy_service inet:127.0.0.1:10023,
permit
smtpd_data_restrictions = reject_multi_recipient_bounce,
reject_unauth_pipelining
smtpd_milters = inet:localhost:8891
Erwähnenswert hieran sind vielleicht noch die beiden check_policy_service-Bedingungen. Während auf Port 12525 SpamAssassin seine Arbeit verrichtet, werkelt auf Port 10023 ein Postgrey an der Filterung von Erstanfragen unbekannter Einlieferer.
Was an dieser Konfiguration noch nicht so schön läuft, ist ein Problem, was aus der Error-Sleep-Zeit bei Fehlermeldungen resultiert: Es sammeln sich bei gewisser Last gerne eine Reihe von smtp-Prozessen an. Okay, schauen wir einmal, WIEVIELE:
grep " connect from " /var/log/mail.log|cut -d " " -f 9|sort|uniq -c|sort -rn|head -n 50
Und siehe da:
7576 92-247-221-57.spectrumnet.bg[92.247.221.57]
5670 wsip-98-189-9-75.oc.oc.cox.net[98.189.9.75]
5215 pool-108-9-46-156.tampfl.fios.verizon.net[108.9.46.156]
5164 pool-173-49-168-107.phlapa.fios.verizon.net[173.49.168.107]
4272 c-98-225-170-135.hsd1.pa.comcast.net[98.225.170.135]
3435 unknown[87.252.87.178]
3266 unknown[79.106.1.191]
2903 unknown[59.31.64.201]
2696 201.pool85-61-15.dynamic.orange.es[85.61.15.201]
2363 unknown[222.114.217.139]
2287 host173-094.cablenet.net.ar[200.50.173.94]
2063 host86-135-10-125.range86-135.btcentralplus.com[86.135.10.125]
2002 unknown[12.185.110.66]
1771 unknown[216.9.145.177]
1764 unknown[124.54.183.10]
1746 133.pool85-61-41.dynamic.orange.es[85.61.41.133]
1592 unknown[190.245.43.176]
1550 cpc1-jarr8-0-0-cust341.gate.cable.virginmedia.com[92.238.161.86]
1525 adsl-99-180-209-142.dsl.emhril.sbcglobal.net[99.180.209.142]
1493 unknown[118.223.222.22]
1421 110.Red-80-38-65.staticIP.rima-tde.net[80.38.65.110]
1372 unknown[109.188.47.17]
1329 unknown[122.180.77.102]
1272 41-133-127-209.dsl.mweb.co.za[41.133.127.209]
1248 189-68-166-28.dsl.telesp.net.br[189.68.166.28]
1148 unknown[114.143.206.181]
1146 cB34345C1.dhcp.bluecom.no[193.69.67.179]
1056 unknown[77.225.34.101]
1042 pool-96-252-208-232.tampfl.fios.verizon.net[96.252.208.232]
1031 205.pool85-61-37.dynamic.orange.es[85.61.37.205]
948 0020-107-27-72-DYNAMIC-dsl.cwjamaica.com[72.27.107.20]
925 surf83.net.rss.rogers.com[24.114.255.83]
889 unknown[203.252.184.26]
859 d47-104.icpnet.pl[77.65.47.104]
855 unknown[190.25.151.216]
813 unknown[89.122.253.225]
788 unknown[41.140.162.42]
772 1898764246.rec.megazon.com.br[189.87.64.246]
756 unknown[212.76.105.34]
751 unknown[186.28.196.119]
750 unknown[187.37.159.14]
717 unknown[199.176.226.129]
699 unknown[81.91.219.120]
694 pc-204-170-100-190.cm.vtr.net[190.100.170.204]
687 unknown[121.55.174.12]
680 201-25-37-46.paemt705.dsl.brasiltelecom.net.br[201.25.37.46]
665 unknown[187.35.177.215]
646 unknown[92.86.26.208]
640 unknown[125.129.229.48]
608 114-47-147-178.dynamic.hinet.net[114.47.147.178]
Für die Relation: das sind die Top 50 der Verbindungen der letzten 7 Tage.
Ach ja: Umso ärgerlicher ist es, wenn man einem Kunden sagen muss, dass man eine seiner dringend erwarteten Mails nicht entgegennehmen kann, weil der Absendende Provider zu doof ist, seine Server RFC-konform zu konfigurieren. Und NOCH ärgerlicher ist es, wenn dieser nicht mal auf den direkten Hinweis an die im Whois gelistete Adresse für den technischen Kontakt reagiert.
Basierend auf obiger Negativ-Liste wird es aber sicherlich die Tage noch eine Cronjob-basierte Lösung für einen IP-Blocklist-Filter geben. Aber dazu später mehr – erstmal muss ich das am Server testen 😉
Naja. Mal sehen, wann Mail als Medium wegen solcher Nervereien endlich ausstirbt! Zu wünschen wäre es solangsam.
Update: Nach einem doch etwas stressigeren Tag, noch eine kleine Ergänzung zur aktuellen Konfiguration. Wie bereits oben angekündigt, habe ich meinen Postfix nun so konfiguriert, dass ich gezielt IP-Adressen sperren kann. Grundlage dafür bildet der erwähnte Beitrag. Zur Umsetzung habe ich im Verzeichnis /etc/postfix ein kleines Script blockip angelegt. Um die Übersicht der erzeugten Banliste etwas zu erhöhen und um einen Fehler beim Einfügen der Einträge (echo -e hat das -e mit in die Datei geschrieben) zu beheben, wurde aus der ursprünglichen Fassung:
#!/bin/sh
echo -e "$1\tREJECT" >> /etc/postfix/client_access
postmap /etc/postfix/client_access
folgendes Skript abgeändert:
#!/bin/sh
/bin/echo -e "$1\tREJECT" >> /etc/postfix/client_access
/bin/cat /etc/postfix/client_access|/usr/bin/sort -V|/usr/bin/uniq > /etc/postfix/client_access.new
/bin/mv /etc/postfix/client_access.new /etc/postfix/client_access
postmap /etc/postfix/client_access
Die zusätzliche Anweisung sort -V sorgt dabei dafür, dass nach „Versionsnummern“ sortiert wird, was auch IP-Adressen extrem gut sortiert. Ferner wird mit uniq sichergestellt, dass jede IP nur einmal in der Liste auftaucht. Da man jedoch nicht gleichzeitig eine Datei cat-ten kann während man in sie reinschreibt, ist der kleine Umweg über mv nötig. Jedem mit etwas Erfahrung mit der Bash dürfte dieser Source daher nicht weiter schwer fallen. Bliebe noch zu erwähnen, dass für den Workaround um das -e-Problem bei echo die Pfadangaben zusätzlich ergänzt wurden. Diese sind streng genommen nur bei echo nötig, aber der Übersicht halber hab ich sie mal für alle Aufrufe ergänzt.
Da wir nun unsere IP-Blacklist haben, müssen wir Postfix noch bescheid geben, dass wir sie auch nutzen wollen. Dies geht am einfachsten durch ergänzen folgender Zeilen in der main.cf:
smtpd_client_restrictions = permit_mynetworks,
permit_sasl_authenticated,
check_client_access hash:/etc/postfix/client_access,
permit
Auch hier sollte man ggf. eine Reihe zusätzlicher Erklärungen ergänzen, da diese Konfiguration alleine recht gefährlich werden kann. Daher Schritt für Schritt: Die erste Zeile regelt, dass der Mailserver vertrauten Clients IMMER Zugang gewährt, auch wenn sie auf unserer Blacklist landen. Dies ist nötig, um uns nicht aus Versehen selber auszusperren. Gefolgt wird dies durch die Ergänzung, dass authentifizierte Clients auch IMMER Zugang erhalten. Somit kann man theoretisch ganze Client-Netze sperren, ohne legitime Nutzer des Mailservers, die sich ordnungsgemäß anmelden auszusperren. An dritter Stelle folgt nun unsere soeben eingerichtete Blacklist. Da diese nur Sperr-Einträge enthält, sollte der Default sein, dass Clients, die nicht auf dieser Liste stehen akzeptiert werden. Dies geschieht in Zeile 4. Und nun zur Warnung bzgl. dieser Konfiguration: Würde man seinen Mailserver NUR mit diesen Einschränkungen fahren, hätte man einen herrlichen OpenRelay, der sicherlich binnen kürzester Zeit auf jeglichen DNSBLs stünde. Daher sollte man dringenst beachten, auch fürSender, Recipients und HELO-Kommandos restriktive Regeln festzulegen. die oben genannte Konfiguration darf dazu gerne als Ausgangspunkt dienen.
Hat man diese Ergänzungen in seiner main.cf getätigt, muss Postfix noch mitgeteilt werden, dass die Konfiguration neu gelesen werden muss. Hierzu reicht ein einfaches
/etc/init.d/postfix reload
aus, nachdem man eine erste IP-Adresse in seiner Blacklist eingetragen hat und somit alle durch die Konfiguration referenzierten Dateien existieren. Ist die neue Konfiguration einmal aktiv, ist für das ergänzen weiterer IPs zur Blacklist kein weiterer Reload des Postfix nötig: Änderungen an der Hash-File werden automatisch bei der nächsten Anfrage übernommen.
Somit reicht für das Eintragen einer neuen IP in die Blacklist ein einfacher Aufruf des Skriptes:
/etc/postfix/blockip 8.8.8.8
Auf meinem Server wurde die Liste der zu blockenden IPs bereits recht ausgiebig genutzt: Derzeit sind neben den oben erwähnten Top 50 eine Reihe weiterer, aktiver Spam-IPs gesperrt, die noch nicht auf den üblichen DNSBLs auftauchen. Und die Liste wird wahrscheinlich immer etwas wachsen 😉
Interessant, deine Blacklist ist die über den DNS verfügbar? ^^
Kommentar by neo — 13.05.2010 @ 16:21:16
Nein, derzeit nicht. Wenn du aber ganz lieb fragst, könnte ich mich unter Umständen dazu hinreißen lassen, die via Bind-tauglich zu konvertieren. Derzeit gibt’s aber auf’m Server erstmal andere Prioritäten – das würde also etwas dauern.
Wichtiger ist eh der Aspekt bzgl. Verzögerung beim Antworten auf Fehler. Das hilft schon mal wesentlich besser gegen solche Bots, als einfach nur sie abzulehnen. Hat auch gegenüber ner Teergrube den großen Vorteil, dass man legitime Clients wesentlich weniger behindert.
Kommentar by BenBE — 13.05.2010 @ 16:42:18