Artikel mit Tag spam
antispam blog s9y serendipity bayes blacklist mail postfix dd-wrt feed fun layout linux online rootserver rss server statistik theme update idioten frust krank apple combots imap inbox jabber konferenz lotus lotus notes mac newsletter notes on tour reminder security smtp sober thunderbird tipp viren web.de work alkohol centos dovecot entsorgung gentoo lvm netzwerk onvista raid samba schrott tor traffic usb
Gedanken zu Blog-Spamerkennung mittels bogofilter
Folgendes habe ich gerade im Serendipity Forum eingekippt - vielleicht interessiert es ja auch die Leser hier:Da Akismet und auch TypePad Antispam tlw. ein wenig viel wegfiltern - gerade Kommentare auf Deutsch - habe ich gestern ein wenig begonnen, mir über Alternativen Gedanken zu machen. Erst wollte ich Spamassassin zur Erkennung von Spam/Ham verwenden, bin dann aber bei bogofilter gelandet, da Spamassassin sehr viele Tests für Mailheader hat und diese auch erwartet (Received-Zeilen etc.).
Da bogofilter ein Bayes-basierter Filter ist, muss er erst lernen, was gut und was schlechte Kommentare sind. Dazu habe ich zwei Dinge getan:
Alle guten Kommentare je in eine Datei pro Kommentar geschrieben:
SELECT
author,url,body FROM serendipity_comments WHERE STATUS = 'approved';
Alle erkannten und abgelehnten Spamkommentare in je eine Datei pro Kommentar geschrieben:
SELECT
author,url,body FROM serendipity_spamblocklog WHERE
type = 'REJECTED';
In meinem Fall ergab das dann zwei Verzeichnisse, einmal "blogspam" mit fat 370.000 abgelehnten Spams und ein "blogham" Verzeichnis mit 700 guten Kommentaren und Trackbacks. Jede der Dateien hatte untereinander author, url und body stehen.
Jetzt zum lernen:
CODE:
loco@bigboy ~ $ bogofilter -v -H -n -B blogham/
# 6663 words, 696 messages
CODE:
loco@bigboy ~ $ bogofilter -v -H -s -B blogspam/
# 331002 words, 369836 messages
Wenn ich jetzt je einen neue Spamkommentar und einen erfundenen, aber validen sauberen Kommentar zur Prüfung durch den bogofilter jage, erkennt er das brav:
CODE:
loco@bigboy ~ $ bogofilter -v -H < test.blog
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.7
CODE:
loco@bigboy ~ $ bogofilter -v -H < test.blog
X-Bogosity: Spam, tests=bogofilter, spamicity=1.000000, version=1.1.7
Manuell tut das jetzt alles - aber wie verwende ich das in Serendipity? Ich bin SysAdmin, habe es überhaupt nicht mit der PHP Programmierung. Gäbe es denn Interessierte, die diesen Ansatz der Spamfilterung mittels Bayesfilter weiter verfolgen möchten und evtl. in ein Spamblock-Plugin giessen?
Kategorie: Technik
Typepad Antispam als Alternative zu Akismet in s9y *Update*
Um Blogspam zu bekämpfen, gibt es in der besten Blogsoftware der Welt das Spamblock Plugin. Dieses Plugin bietet u.a. die Integration von Akismet an. Akismet ist ein externer Dienstleister, der über eine API den Kommentar vor der Veröffentlichung prüft und eine Entscheidung über Spam oder nicht Spam trifft.Seit einiger Zeit bietet auch TypePad einen AntiSpam Service an - momentan noch im Beta Status, nativ unterstützt werden bisher Movable Type und Wordpress. Die API ist praktischerweise kompatibel zu Akismet, kann also sehr einfach auch in Serendipity integriert werden, mehr dazu gibt es weiter unten.
TypePad möchte den Dienst komplett kostenlos anbieten und schreibt dazu in der FAQ:
How much does TypePad AntiSpam cost?
TypePad Antispam is free, and will always be free, regardless of the number of comments your blog receives. We are strongly committed to spam-free blogs and vibrant, healthy conversations. Charging for the service based on the number of comments processed would mean that we would actually benefit from the behavior of spammers. We don't make money from spam!
Hierzu organisiert man sich bei TypePad einen API-Key. Dieser Key wird in der Plugin Verwaltung anstatt des Akismet API-Keys eingetragen. Anschliessend muss die Datei plugins/serendipity_event_spamblock/serendipity_event_spamblock.php editiert werden - dort einfach alle Vorkommen von "rest.akismet.com" durch "api.antispam.typepad.com" ersetzen.
Auf diesem Blog läuft diese Änderung seit einigen Stunden ohne Probleme - es wurde laut Log brav jeder Spam abgefangen. Ob man als Blogbetreiber möchte, daß jeder Kommentar quer durchs Netz geschickt wird muss jeder für sich selbst entscheiden.
Update: Und warum ist s9y die beste Blogsoftware der Welt? Weil im Spamblock Plugin die Auswahl zwischen Akismet und TypePad Antispam schwupps eingebaut wurde (im trunk und nightly builds zu finden).
DSBL is gone
Eine eigentlich immer unwichtiger werdende Blacklist, die DSBL stellt ihren Betrieb ein - also raus damit aus Postfix, policyd-weight und Konsorten.DSBL is GONE and highly unlikely to return. Please remove it from your mail server configuration.
Top 10 der Blogspam Nationen
Hier ein Snapshot der Spamnationen dieses kleinen Blogs seit dem 01.02.2007:
Top 10 der Blogspam Nationen
Spammer sind doof
Es ist schon schwer, ein Spamtool zu benutzen. So etwas kommt in letzter Zeit hier öfters an:%TO_CC_DEFAULT_HANDLER
Subject: %SUBJECT
Sender: "%FROM_NAME" <%FROM_EMAIL>
Mime-Version: 1.0
Content-Type: text/html
Date: %CURRENT_DATE_TIME
%MESSAGE_BODY
Spamstatistik
Bei den Arbeiten an der spamblocklog Tabelle meiner Serendipity Installation, die evtl. demnächst zum release eines Plugins zur Spam Statistik führen, habe ich ein wenig mit der GeoIP API für PHP gespielt, dabei kam z.B. die folgende interessante Statistik zur Herkunft der abgelehnten Kommentare bzw. Trackbacks heraus:2647 United States
1788 Korea, Republic of
1163 Ukraine
972 Norway
861 Austria
686 China
525 India
488 Japan
226 Germany
173 Russian Federation
164 Algeria
127 Mexico
Persönlich hätte ich China und Russland weiter oben auf der Liste erwartet, aber die breite Streuung der verschiedenen Länder (auch aus Syrien, Iran und Saudi-Arabien kommt Spam) deutet auch hier auf Botnetze hin, ähnlich wie bei Spam Mails.
Kategorie: Mail/Spam
Spam Bekämpfung mit policyd-weight
Da ich Andy gestern damit helfen konnte gibt es hier noch einen Eintrag zum momentan für mich am Besten mit Postfix funktionierenden Anti-Spam Tool: policyd-weight von Robert Felber.Ab Version 2.1 kann Postfix die Entscheidung, ob eine Mail angenommen wird, an einen externen policy daemon delegieren. Für den von mir eingesetzten policyd-weight ist nur der Inhalt dreier SMTP Kommandos interessant: HELO, MAIL FROM und RCPT TO. Mit diesen Werten checkt das Programm DNS Daten, inkonsistente HELO Strings und kann RBLs abfragen und bildet daraus einen gewichteten Score, um Mails bereits während des SMTP Dialogs abzulehnen. Das spart Bandbreite, schont die CPU durch weniger Scans mit Spamassassin o.ä. Tools auf dem Mailserver und erspart rejects für fälschlicherweise auf einer Blackliste geführten sauberen Host.
policyd-weight fragt momentan folgende RBLs ab
• njabl.org (using dynablock. and dnsbl. zones)
• spamcop.net (using bl. zone)
• spamhaus.org (using sbl-xbl. zone)
• dsbl.org (using list. zone)
• ix.dnsbl.manitu.net (RBL of a german zine)
• ordb.org (using relays. zone)
Erst wenn mehrere Kriterien wie gefälschtes HELO, Eintrag in zwei RBLs und falschen Nameserver Einträgen zutreffen wird die Mail abgelehnt.
Die Einrichtung ist einfach:
cd /usr/local/bin
wget http://www.policyd-weight.org/policyd-weight
chmod +x policyd-weight
wget http://www.policyd-weight.org/policyd-weight
chmod +x policyd-weight
Dann entweder ein eigenes Init Script bauen oder im Laufe des bootens vor postfix starten:
/usr/local/bin/policyd-weight
Damit postfix den externen policy daemon ansprechen kann, wird die /etc/postfix/main.cf angepasst:
smtpd_recipient_restrictions = reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unknown_sender_domain
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
check_client_access hash:/etc/postfix/policyd_weight_client_whitelist
check_recipient_access hash:/etc/postfix/recipient-access
check_policy_service inet:127.0.0.1:12525
reject_non_fqdn_recipient
reject_unknown_sender_domain
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
check_client_access hash:/etc/postfix/policyd_weight_client_whitelist
check_recipient_access hash:/etc/postfix/recipient-access
check_policy_service inet:127.0.0.1:12525
Nach einem
postfix reload
sollten die ersten Meldungen im konfigurierten Maillog auftauchen. Ein Beispiel für eine abgelehnte Mail sieht dann so aus:
Nov 22 22:41:27 bigboy postfix/policyd-weight[5362]: weighted check: IN_DYN_NJABL=3.25 IN_SBL_XBL_SPAMHAUS=4.35
NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 BAD_MX=15.96 BOGUS_MX=9.7 CL_IP_NE_HELO=9.1 RESOLVED_IP_IS_NOT_HELO=1.5 (check from: .reflectionsofart. - helo:
.localhost.) FROM_NOT_FAILED_HELO=10.6 <client=88.108.67.36> <helo=localhost> <from=rcpost.com@reflectionsofart.com> <to=peter@pommesbude.org>, rate:
51.46
Nov 22 22:41:27 bigboy postfix/policyd-weight[5362]: decided action=550 Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; MTA helo: localhost, MTA hostname: 88-108-67-36.dynamic.dsl.as9105.com[88.108.67.36] (helo/hostname mismatch)
Nov 22 22:41:27 bigboy postfix/policyd-weight[5362]: decided action=550 Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; MTA helo: localhost, MTA hostname: 88-108-67-36.dynamic.dsl.as9105.com[88.108.67.36] (helo/hostname mismatch)
Tipp: um das Verhalten von policyd-weight zu testen, kann der Aufruf in der main.cf mit vorgestelltem warn_if_reject eingebunden werden:
warn_if_reject check_policy_service inet:127.0.0.1:12525
Jetzt wird zwar im Logfile ein Eintrag geschrieben, die Mail passiert aber ungehindert.
Mir erspart der Einsatz eines solchen policy daemons jedenfalls massiv Spam, nur noch über Mailinglisten kommt hin- und wieder etwas rein.
Managing Port 25
Schon Anfang September nach dem 3. Deutschen Antispam Kongress in Köln wollte ich eigentlich ein paar Zeilen zu den Vorteilen des Submission Ports und Sperrung des Port 25 für Dialup IPs schreiben. Das hat mir die auch auf dem Kongress vortragende MAAWG jetzt abgenommen und eine Empfehlung zur Behandlung des Port 25 durch Dialup Provider veröffentlicht:Therefore, the MAAWG recommends the following set of Email
Transmission Best Practices for Internet and Email Service Providers:
1. Provide Email Submission services on port 587, as described in RFC 2476.
2. Require authentication for Email Submission, as described in RFC 2554.
3. Abstain from interfering with outbound connectivity to port 587.
4. Configure email client software to use port 587 and authentication for Email Submission.
5. Block access to port 25 from all hosts on your network, other than those that you explicitly authorize to perform SMTP relay functions. Such hosts will certainly include your own Email Submission servers and may also include the legitimate Email Submission servers of your responsible customers.
6. Block incoming traffic to your network from port 25. This prevents potential abuse from spammers using asymmetric routing and spoofing IP addresses on your network.
Das ganze Dokument gibt hieres als PDF. WEB.DE Freemail bietet diesen Submission Port übrigens schon seit geraumer Zeit an.
