{"id":627,"date":"2010-05-09T01:17:23","date_gmt":"2010-05-08T23:17:23","guid":{"rendered":"http:\/\/blog.benny-baumann.de\/?p=627"},"modified":"2010-05-10T00:17:45","modified_gmt":"2010-05-09T22:17:45","slug":"spam-und-seine-auswirkungen","status":"publish","type":"post","link":"https:\/\/blog.benny-baumann.de\/?p=627","title":{"rendered":"SPAM und seine Auswirkungen"},"content":{"rendered":"

Wir alle m\u00f6gen keinen Spam. Insbesondere mein Server nicht, wie ich die Tage durch eine Reihe seltsamer Ausf\u00e4lle feststellen musste. Obwohl mein Postfix an sich recht wenig Last erzeugte, stellte ich dennoch anhand der Live-Statistiken f\u00fcr meinen Bindgraph – und von den zahlreichen MX-Anfragen verwundert auch im zugeh\u00f6rigen Mailgraphen eine stark erh\u00f6hte Anzahl von abgelehnten Mails fest. Dachte ich zuerst noch an einen m\u00f6gliches Problem in der Konfiguration, weil sich ein solches durchaus bereits einmal in dieser Form ge\u00e4u\u00dfert hatte, zeigte ein kurzer Blick in die Logfiles nur eine durchscrollende Menge von „NOQUEUE: reject: Relay Access denied“-Meldungen.<\/p>\n

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\u00e4d dies Spammer durchaus ein, Schabernack mit dem System zu treiben.<\/p>\n

Also schauen wir einmal, was sich machen l\u00e4sst. Als erstes fiel mir beim Live-View der Logs auf, dass 20 Mails nahezu gleichzeitig \u00fcber eine Verbindung versendet werden sollten – ein mehr als typisches Verhalten von Spambots. Das „nahezu gleichzeitig“ sowie die 20 St\u00fcck je Verbindung erkl\u00e4ren sich dabei wie folgt:
\n1. Der Server erzwang keine Wartezeit nach einem Fehlercode
\n2. Nach 20 Fehlern je Verbindung wurde zwingend die Verbindung beendet<\/p>\n

Okay, da l\u00e4sst sich was drehen<\/a>:<\/p>\n

disable_vrfy_command = yes\r\nsmtpd_error_sleep_time = 5s\r\nsmtpd_soft_error_limit = 1\r\nsmtpd_hard_error_limit = 3\r\n<\/pre>\n
Mit dieser \u00c4nderung in der Konfig gestaltete sich das Betrachten der Logs schon einmal gem\u00fctlicher. Also das hei\u00dft, die Mail.log scrollte nun nur unwesentlich schneller wie die Apache-Logfile des Gesamtservers, die auf einer anderen Screen-Konsole ge\u00f6ffnet war. Zwischenzeitlich hatte ich zwar das Sleep nach Errors auf 15 Sekunden, da dies aber nur unn\u00f6tig viele Sockets offen hielt, hab ich mich f\u00fcr 5 Sekunden entschieden, was den gleichen Effekt erziehlt).<\/p>\n
W\u00e4re 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\u00fcssen nun Reverse-DNS und HELO-Name stimmen, sowie vollst\u00e4ndige UND korrekte FQDNs sein. Zus\u00e4tzlich werden FQDNs nun auch f\u00fcr die Sender- und Empf\u00e4nger-Mail-Adresse (Host-Anteil) erzwungen (Okay, wurden auch bereits vorher, aber hier kamen ein paar Pr\u00fcfungen hinzu).<\/p>\n
Somit gestaltet sich die Annahme einer Mails nun unter Einhaltung einer Reihe mehr Regeln als zuvor:<\/p>\n
smtpd_helo_required          = yes\r\n\r\nsmtpd_helo_restrictions      = permit_mynetworks,\r\n                               permit_sasl_authenticated,\r\n                               reject_invalid_hostname,\r\n                               reject_invalid_helo_hostname,\r\n                               reject_non_fqdn_helo_hostname\r\n\r\nsmtpd_sender_restrictions    = reject_non_fqdn_sender,\r\n                               reject_unknown_sender_domain,\r\n                               permit_mynetworks,\r\n                               permit_sasl_authenticated\r\n\r\nsmtpd_recipient_restrictions = permit_mynetworks,\r\n                               permit_sasl_authenticated,\r\n                               reject_invalid_hostname,\r\n                               reject_non_fqdn_hostname,\r\n                               reject_non_fqdn_sender,\r\n                               reject_non_fqdn_recipient,\r\n                               reject_unknown_sender_domain,\r\n                               reject_unknown_recipient_domain,\r\n                               reject_unauth_destination,\r\n                               reject_unlisted_recipient,\r\n                               reject_rbl_client virbl.dnsbl.bit.nl,\r\n                               reject_rbl_client zen.spamhaus.org,\r\n                               reject_rbl_client ix.dnsbl.manitu.net,\r\n                               check_policy_service inet:127.0.0.1:12525,\r\n                               check_policy_service inet:127.0.0.1:10023,\r\n                               permit\r\n\r\nsmtpd_data_restrictions      = reject_multi_recipient_bounce,\r\n                               reject_unauth_pipelining\r\n\r\nsmtpd_milters = inet:localhost:8891<\/pre>\n
Erw\u00e4hnenswert hieran sind vielleicht noch die beiden check_policy_service-Bedingungen. W\u00e4hrend auf Port 12525 SpamAssassin seine Arbeit verrichtet, werkelt auf Port 10023 ein Postgrey an der Filterung von Erstanfragen unbekannter Einlieferer.<\/p>\n
Was an dieser Konfiguration noch nicht so sch\u00f6n l\u00e4uft, 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:<\/p>\n
grep \" connect from \" \/var\/log\/mail.log|cut -d \" \" -f 9|sort|uniq -c|sort -rn|head -n 50<\/pre>\n
Und siehe da:<\/p>\n
   7576 92-247-221-57.spectrumnet.bg[92.247.221.57]\r\n   5670 wsip-98-189-9-75.oc.oc.cox.net[98.189.9.75]\r\n   5215 pool-108-9-46-156.tampfl.fios.verizon.net[108.9.46.156]\r\n   5164 pool-173-49-168-107.phlapa.fios.verizon.net[173.49.168.107]\r\n   4272 c-98-225-170-135.hsd1.pa.comcast.net[98.225.170.135]\r\n   3435 unknown[87.252.87.178]\r\n   3266 unknown[79.106.1.191]\r\n   2903 unknown[59.31.64.201]\r\n   2696 201.pool85-61-15.dynamic.orange.es[85.61.15.201]\r\n   2363 unknown[222.114.217.139]\r\n   2287 host173-094.cablenet.net.ar[200.50.173.94]\r\n   2063 host86-135-10-125.range86-135.btcentralplus.com[86.135.10.125]\r\n   2002 unknown[12.185.110.66]\r\n   1771 unknown[216.9.145.177]\r\n   1764 unknown[124.54.183.10]\r\n   1746 133.pool85-61-41.dynamic.orange.es[85.61.41.133]\r\n   1592 unknown[190.245.43.176]\r\n   1550 cpc1-jarr8-0-0-cust341.gate.cable.virginmedia.com[92.238.161.86]\r\n   1525 adsl-99-180-209-142.dsl.emhril.sbcglobal.net[99.180.209.142]\r\n   1493 unknown[118.223.222.22]\r\n   1421 110.Red-80-38-65.staticIP.rima-tde.net[80.38.65.110]\r\n   1372 unknown[109.188.47.17]\r\n   1329 unknown[122.180.77.102]\r\n   1272 41-133-127-209.dsl.mweb.co.za[41.133.127.209]\r\n   1248 189-68-166-28.dsl.telesp.net.br[189.68.166.28]\r\n   1148 unknown[114.143.206.181]\r\n   1146 cB34345C1.dhcp.bluecom.no[193.69.67.179]\r\n   1056 unknown[77.225.34.101]\r\n   1042 pool-96-252-208-232.tampfl.fios.verizon.net[96.252.208.232]\r\n   1031 205.pool85-61-37.dynamic.orange.es[85.61.37.205]\r\n    948 0020-107-27-72-DYNAMIC-dsl.cwjamaica.com[72.27.107.20]\r\n    925 surf83.net.rss.rogers.com[24.114.255.83]\r\n    889 unknown[203.252.184.26]\r\n    859 d47-104.icpnet.pl[77.65.47.104]\r\n    855 unknown[190.25.151.216]\r\n    813 unknown[89.122.253.225]\r\n    788 unknown[41.140.162.42]\r\n    772 1898764246.rec.megazon.com.br[189.87.64.246]\r\n    756 unknown[212.76.105.34]\r\n    751 unknown[186.28.196.119]\r\n    750 unknown[187.37.159.14]\r\n    717 unknown[199.176.226.129]\r\n    699 unknown[81.91.219.120]\r\n    694 pc-204-170-100-190.cm.vtr.net[190.100.170.204]\r\n    687 unknown[121.55.174.12]\r\n    680 201-25-37-46.paemt705.dsl.brasiltelecom.net.br[201.25.37.46]\r\n    665 unknown[187.35.177.215]\r\n    646 unknown[92.86.26.208]\r\n    640 unknown[125.129.229.48]\r\n    608 114-47-147-178.dynamic.hinet.net[114.47.147.178]<\/pre>\n
F\u00fcr die Relation: das sind die Top 50 der Verbindungen der letzten 7 Tage.<\/p>\n
Ach ja: Umso \u00e4rgerlicher 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 \u00e4rgerlicher ist es, wenn dieser nicht mal auf den direkten Hinweis an die im Whois gelistete Adresse f\u00fcr den technischen Kontakt reagiert.<\/p>\n
Basierend auf obiger Negativ-Liste wird es aber sicherlich die Tage noch eine Cronjob-basierte L\u00f6sung f\u00fcr einen IP-Blocklist-Filter<\/a> geben. Aber dazu sp\u00e4ter mehr – erstmal muss ich das am Server testen \ud83d\ude09<\/p>\n
Naja. Mal sehen, wann Mail als Medium wegen solcher Nervereien endlich ausstirbt! Zu w\u00fcnschen w\u00e4re es solangsam.<\/p>\n
Update:<\/strong> Nach einem doch etwas stressigeren Tag, noch eine kleine Erg\u00e4nzung zur aktuellen Konfiguration. Wie bereits oben angek\u00fcndigt, habe ich meinen Postfix nun so konfiguriert, dass ich gezielt IP-Adressen sperren kann. Grundlage daf\u00fcr bildet der erw\u00e4hnte Beitrag<\/a>. Zur Umsetzung habe ich im Verzeichnis \/etc\/postfix ein kleines Script blockip angelegt. Um die \u00dcbersicht der erzeugten Banliste etwas zu erh\u00f6hen und um einen Fehler beim Einf\u00fcgen der Eintr\u00e4ge (echo -e hat das -e mit in die Datei geschrieben) zu beheben, wurde aus der urspr\u00fcnglichen Fassung:<\/p>\n
#!\/bin\/sh\r\n\r\necho -e \"$1\\tREJECT\" >> \/etc\/postfix\/client_access\r\npostmap \/etc\/postfix\/client_access<\/pre>\n
folgendes Skript abge\u00e4ndert:<\/p>\n
#!\/bin\/sh\r\n\r\n\/bin\/echo -e \"$1\\tREJECT\" >> \/etc\/postfix\/client_access\r\n\/bin\/cat \/etc\/postfix\/client_access|\/usr\/bin\/sort -V|\/usr\/bin\/uniq > \/etc\/postfix\/client_access.new\r\n\/bin\/mv \/etc\/postfix\/client_access.new \/etc\/postfix\/client_access\r\npostmap \/etc\/postfix\/client_access<\/pre>\n
Die zus\u00e4tzliche Anweisung sort -V sorgt dabei daf\u00fcr, 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\u00e4hrend man in sie reinschreibt, ist der kleine Umweg \u00fcber mv n\u00f6tig. Jedem mit etwas Erfahrung mit der Bash d\u00fcrfte dieser Source daher nicht weiter schwer fallen. Bliebe noch zu erw\u00e4hnen, dass f\u00fcr den Workaround um das -e-Problem bei echo die Pfadangaben zus\u00e4tzlich erg\u00e4nzt wurden. Diese sind streng genommen nur bei echo n\u00f6tig, aber der \u00dcbersicht halber hab ich sie mal f\u00fcr alle Aufrufe erg\u00e4nzt.<\/p>\n
Da wir nun unsere IP-Blacklist haben, m\u00fcssen wir Postfix noch bescheid geben, dass wir sie auch nutzen wollen. Dies geht am einfachsten durch erg\u00e4nzen folgender Zeilen in der main.cf:<\/p>\n
smtpd_client_restrictions    = permit_mynetworks,\r\n                               permit_sasl_authenticated,\r\n                               check_client_access hash:\/etc\/postfix\/client_access,\r\n                               permit<\/pre>\n
Auch hier sollte man ggf. eine Reihe zus\u00e4tzlicher Erkl\u00e4rungen erg\u00e4nzen, da diese Konfiguration alleine recht gef\u00e4hrlich werden kann. Daher Schritt f\u00fcr Schritt: Die erste Zeile regelt, dass der Mailserver vertrauten Clients IMMER Zugang gew\u00e4hrt, auch wenn sie auf unserer Blacklist landen. Dies ist n\u00f6tig, um uns nicht aus Versehen selber auszusperren. Gefolgt wird dies durch die Erg\u00e4nzung, dass authentifizierte Clients auch IMMER Zugang erhalten. Somit kann man theoretisch ganze Client-Netze sperren, ohne legitime Nutzer des Mailservers, die sich ordnungsgem\u00e4\u00df anmelden auszusperren. An dritter Stelle folgt nun unsere soeben eingerichtete Blacklist. Da diese nur Sperr-Eintr\u00e4ge enth\u00e4lt, 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\u00fcrde man seinen Mailserver NUR mit diesen Einschr\u00e4nkungen fahren, h\u00e4tte man einen herrlichen OpenRelay, der sicherlich binnen k\u00fcrzester Zeit auf jeglichen DNSBLs st\u00fcnde. Daher sollte man dringenst beachten, auch f\u00fcrSender, Recipients und HELO-Kommandos restriktive Regeln festzulegen. die oben genannte Konfiguration darf dazu gerne als Ausgangspunkt dienen.<\/p>\n
Hat man diese Erg\u00e4nzungen in seiner main.cf get\u00e4tigt, muss Postfix noch mitgeteilt werden, dass die Konfiguration neu gelesen werden muss. Hierzu reicht ein einfaches<\/p>\n
\/etc\/init.d\/postfix reload<\/pre>\n
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\u00fcr das erg\u00e4nzen weiterer IPs zur Blacklist kein weiterer Reload des Postfix n\u00f6tig: \u00c4nderungen an der Hash-File werden automatisch bei der n\u00e4chsten Anfrage \u00fcbernommen.<\/p>\n
Somit reicht f\u00fcr das Eintragen einer neuen IP in die Blacklist ein einfacher Aufruf des Skriptes:<\/p>\n
\/etc\/postfix\/blockip 8.8.8.8<\/pre>\n
Auf meinem Server wurde die Liste der zu blockenden IPs bereits recht ausgiebig genutzt: Derzeit sind neben den oben erw\u00e4hnten Top 50 eine Reihe weiterer, aktiver Spam-IPs gesperrt, die noch nicht auf den \u00fcblichen DNSBLs auftauchen. Und die Liste wird wahrscheinlich immer etwas wachsen \ud83d\ude09<\/p>\n
\"Flattr<\/a><\/p>","protected":false},"excerpt":{"rendered":"
Wir alle m\u00f6gen keinen Spam. Insbesondere mein Server nicht, wie ich die Tage durch eine Reihe seltsamer Ausf\u00e4lle feststellen musste. Obwohl mein Postfix an sich recht wenig Last erzeugte, stellte ich dennoch anhand der Live-Statistiken f\u00fcr meinen Bindgraph – und von den zahlreichen MX-Anfragen verwundert auch im zugeh\u00f6rigen Mailgraphen eine stark erh\u00f6hte Anzahl von abgelehnten […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[4],"tags":[10,69,204,205,346],"class_list":["post-627","post","type-post","status-publish","format-standard","hentry","category-server","tag-debian","tag-internet","tag-postfix","tag-postgrey","tag-server"],"_links":{"self":[{"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/posts\/627","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=627"}],"version-history":[{"count":6,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/posts\/627\/revisions"}],"predecessor-version":[{"id":629,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/posts\/627\/revisions\/629"}],"wp:attachment":[{"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=627"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=627"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=627"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}