Zockertown: Nerten News

Ich weiß nicht, ob an dem dahinter liegenden Script Interesse besteht...

Einfach melden.

Durch die Analyse mit Matomo bin ich einem Pänomen auf die Spur gekommen.

Aus Gründen der email Problematik muss jede Domain, die auf unseren Server liegt, einen MX Eintrag haben.
Macht man dies nicht, gibt es Probleme mit einigen großen email Anbietern wie. z.B. gmx.

Nun habe ich vor Monaten meine eigenen Seiten mit der Search Console von Google untersucht.
Dabei fand ich sagenhaft viele Links, die natürlich erfolglos eine große Mange von Seiten auf der Subdomain mail.domain.de  (domain ist hier ein Platzhalter)
erreichen wollten.

Das klappt natürlich nicht und wird mit Fehlern von Google quittiert.
Ich habe lange gerätselt, welche Ursachen das haben könnte.
Denn nirgendwo auf meinen Seiten gibt es diese URLs.

Da kam mit Matomo mit dem Graphen Kanaltypen gerade recht. Man kann in der Auswertung sehen von wo die Zugriffe auf diese Phantom mail.domain.de herkommen.

So wie ich das sehe, scheint es Bots zu geben, die einfach probieren auf der mail subdomain Dinge zu erreichen, die auf anderen Domains durchaus — ohne mail subdomain — gültig sind.

Im Screenshot ist jetzt nur eine halbe Woche betrachtet.

Meine Gegenmassnahme:
Ich habe in ISPConfig eine Subdomain mail angelegt und ein permanenten Redirect auf die Domain weitergeleitet. Das führt nun einfach auf die Homepage und produziert keine Fehler mehr

Seit 2 Tagen ist dies nun aktiv und offenbar kommen keine neuen mail subdomain Zugriffe mehr.

Ich habe das auch auf den anderen betroffenen Domains so eingerichtet.

Da das Mailsystem selbst Port 80 und 443 nicht tangiert, gibt es naturgemäß damit auch keine Kollision.

Fazit:

Anfangs war ich von Matomo ja nicht so begeistert, da ich das System nun aber konsequent auf ausschliessliche Logfile Analyse basierend aufgesetzt habe und auch die Möglichkeiten der Anonymisierung nutze, konnte ich mich mit den Graphen näher beschäftigen und sagen, das ist wirklich nicht nutzlos und Overhead, sondern sehr nützlich, auch für Hobbyprojekte.

Ich möchte hier kurz ein neues Script vorstellen, welches gleich mehrere Ziele hat.

blockedspam.sh

(1) bietet eine Kurzinfo. DiscardedInbound bedeutet soviel wie "eMail Eingang verworfen". Das heißt also diese eMail wurde nicht an ein eMail Konto geliefert, sondern ignoriert.

Bei (2) werden die definierten Richtlinien ausgegeben. Die definierten Richtlinien sind  in der Admin Oberfläche von ISPConfig eingerichtet. Bei uns werden die X-Spam-Score Zeilen der hereinkommenden eMails durch Amavis modifiert. Das machen etliche eMail Anbieter auch.  Ganz wichtig war nun für mich, leicht zu erkennen, ob auch der Kill Level korrekt funktioniert. Also, ob der score dazu führt, dass die eMail verworfen wird, wenn der Wert hoch genug ist.

Bei (3) sind alle Treffer aus dem mail.log der laufenden Woche aufgelistet. Der Screenshot ist vom Dienstag Nachmittag, hat also nur eine Zeitspanne von reichlich 2,5 Tagen.

In der rechten Spalte ist die für den entsprechenden eMail Konto die ausgewählte Richtlinie.

Im erweiterten Teil findet ihr den Source Code von blockedspam.sh

Das hier ist keine Anleitung, sondern dient mir als Stütze, was ich gemacht habe.

Gmail möchte verstärkt die absendenen Mailserveradmins dazu bewegen, SPF zu verwenden. Andere große eMail Provider übrigens auch. Es kommt vereinzelnt zu solchen Einträgen im mail.log

said: 421-4.7.0 This message does not have authentication information or fails to pass 421-4.7.0 authentication checks. To best protect our users from spam, the 421-4.7.0 message has been blocked. Please visit 421-4.7.0  https://support.google.com/mail/answer/81126#authentication for more 421 4.7.0 information. e15-20nmnmnmxmxmnmn.517 - gsmtp (in reply to end of DATA command))

Eine sehr gute Erklärung ist hier bei it-zeugs.de zu finden.  Hier auch: blog.k-webs.ch 

Deshalb erspare ich mir eine Wiederholung.

Es gibt auch Kritik an SPF. Schön auf den Punkt gebracht hat es meiner Meinung nach  tec-bite.ch/warum-mag-google-meine-mails-nicht/

Links:

Einen gesetzen SPF TXT Record kann man hier  testen.

appmaildev.com/en/spf 

spf-record.de/spf-lookup/

www.kitterman.com/spf/validate.html

https://www.mailhardener.com/tools/spf-validator

mxtoolbox.com/SuperTool.aspx?action=spf

Oder zu Fuß:

Eine email per roundcube oder imap Mailclient an eine eigene  gmail.com Adresse senden.

Die empfangene email unter "mehr", im Original anzeigen. Dort die SPF Einträge untersuchen.

Oder auch so: 

dig -t txt zockertown.de +short
"v=spf1 +a +mx +ip4:xx.yy.zz +ip4:xx.rr.ff.fe -all"

Hinweis:

Unterschied -all und ~all

~all ist die entschärfte Variante

Sollte man die Einträge nicht mit einem Webtool o.ä. machen, sondern auf der Console, bitte daran denken, dass die Serial hochgezählt wird, es gibt sonst evtl. unschöne Nebeneffekte, wie ich erleben durfte.

Auf unserem Server werkelt ein postfix / Dovecot Gespann.

Die Konfiguration von Postfix ist über Jahre immer verfeinert worden.

Seit ein paar Jahren hatte ich ein zusammen gezimmertes Script, welches mir eine Übersicht über diese Thematik lieferte.

Häßlich, aber funktionell.

Gestern habe ich mich hingesetzt und das Script überarbeitet. Weg von einer notdürftigen Grafik und hin zu einer dedizierten Seite, die mehr Informationen bietet.

Nicht mehr ganz so häßlich und informativer.

Meine Spam Blocklisten sind:

http://rootgemeinschaft.de/geblockter-spam.html

Wenn jemand Interesse an dem Script hat, bitte melden, ich kann es auch hier im Blog zum Download bereit stellen.

Update: https://zockertown.de/s9y/index.php?serendipity[subpage]=downloadmanager&thiscat=7&file=62

Das Script muss etwas an die eigenen Verhältnisse angepasst werden. (Pfad zur Target Html Datei)

(Das Script ist ein Vorläufer.)

Yunohost habe ich mal ein paar Monate ausprobiert. Die Fülle von vorkonfigurierten Anwendung ist enorm, alleine mal ein Dutzend ausprobrieren zu können ist schon eine Wonne. 

An sich ist der Ansatz von Yunohost (You no Host?) einen exposed Host per dyn dns erreichbar zu haben, um sich einen ausgewachsenen Server zu sparen.

Ich betreibe mit Freunden einen Rootserver, so ist yunohost eigentlich nicht für mich interessant. Aber wie bereits geschrieben sind die installierbaren Plugins überwältigend. Zum Beispiel werde ich shaarli behalten.

Den exposed Host habe ich mittlerweile wieder entfernt, ist also nicht mehr aus dem Internet aufrufbar.

Ich brauche es einfach nicht.

Doch dieser Blog Artikel beschäftigt sich mit dem als plugin verfügbaren Pi-Hole. 

Yunohost habe ich auf einen ausgedienten Lenovo T200 Laptop installliert und die Einstellungen so verbogen, dass auch bei zugeklappten Deckel der Rechner läuft. Stromaufnahme ist ca. 11 Watt. Ungefähr das Doppelte eines Raspberry, dafür ist das Teil auch etwas flinker und hängt auch nicht von schnell sterbenden sd-cards ab :=)

Pi-Hole ist im wesentlichen ein DNS Server, der aufgerufene Seiten die bestimmten Kriterien genügenWerbung, als Hochrisiko eingestufte Webseiten, ..., blockiert.

Als wesentlichen Vorteile dieser Lösung gegenüber Addons für einzelne Browser sehe ich:

Netzwerkweiten Schutz
Pi-hole an einer Stelle und mein gesamtes Netzwerk ist geschützt. Also auch mein Smartphone, die Spiele Konsole, das smart-TV, u.a.

Dadurch, dass die Werbung gar nicht mehr geladen wird, ist die Performance beim Seitenaufbau besser, weil der Traffik geringer ist.

Damit der neue DNS Server auch benutzt wird, muß das der Fritz.box auch mitgeteilt werden. IP V6 ist auch zu empfehlen, einige Devices nutzen das im Heimat Netz, sonst sind die nicht mit geschützt und das wäre schade.

Die ip V6 Adresse, die in der Fritz.box eingetragen werden muß zeigt auf dem yunohost ip

ip -6 address show wls1
3: wls1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2003:xx:xxxx:xxx:xx:xxxx:xxxx:5616/64 scope global dynamic noprefixroute 
       valid_lft 7120sec preferred_lft 1268sec
    inet6 fe80::xxxx:xxxx:xxxx:xxx/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Wenn man in yunohost Pi-hole installiert, verlangt die Installationsroutine zwingend einen DNS Namen. Wenn man nach der Installation keinen exposed Host mehr benutzt möchte der via Dyn DNS angesprochen wird, kann man dies einfach umgehen in dem man auf seinem Rechner, mit dem man auf die Oberfläche von PI-Hole zugreifen möchte, einen Eintrag in /etc/hosts anlegt.

z.B. bei mir 

# lokale_IP_pihole (dns.fritzbox ist vom dhcp server der Fritzbox vergeben) 
#bed.ddns.net ist der dyn dns Name, der bei der Installation vergeben worden ist.
192.168.178.50 dns.fritz.box bed.ddns.net

Damit in den Statistiken die Clients besser identifiziert werden können, muss man Pi-Hole dazu bringen die Namen aufzulösen.

Deshalb muss in der Fritzbox in den Einstellungen die Ip-Adresse von Pi-Hole als Lokaler DNS Server eingetragen werden.

Finetuning war für die Xbox-One notwendig, die wollte (konnte) sich nicht mehr anmelden. 

Zusätzlich habe ich das live.login whitelisted.

Momentan ist das Setup noch in der Erprobungsphase.

Wenn ich etwas ändere/verbessere/optimere/... werde ich das hier ergänzen.

Seit Oktober 2018 habe ich auf meinem Server einen Dirty Hack am laufen.

Er sorgt dafür, dass die von den Usern als SPAM markierten emails als SPAM gelernt werden, um die Bayes Filter zu verbessern.

Meine Hoffnung war, dass dadurch die verbesserte Erkennung von Spam allen Usern zu Gute kommt.

Mittlerweile habe ich Buster und der hack funktioniert immer noch.

Deshalb hier meine Notizen:

Als root:
usermod -aG vmail amavis
chmod -R g+rx /var/vmail/

# Als amavis: su - amavis

# Voraussetzung: Debian Stretch, nach "der perfekte Server"

# Zustand VOR dem Lernen:
sa-learn -D --username=amavis --dump magic

# Anlernen HAM
find /var/vmail/*/* -type d -not -path "*.Spam*" -not -path "*.Junk*" -not -path "*.Trash*" -not -path "*new*" -not -path "*tmp*" -not -path "*.Sent*" -not -path "*.Archive*" -not -path "*Maildir/cur*" -not -path "*dovecot*" -not -path "*sieve*" -not -path "*quotausage*" -not -path "*courier*" -type d -exec /usr/bin/sa-learn --ham {} \;
# Anlernen SPAM
/usr/bin/find /var/vmail/*/*/Maildir/ -type d \( -iname "*Junk*" -o -iname "*spam*" \) -exec /usr/bin/sa-learn --spam {} \;

# Zustand NACH dem Lernen:
sa-learn -D --username=amavis --dump magic


#Als root: STRG-D
# Die Gruppe kann IMHO bleiben
chmod -R g-rx /var/vmail/

Das ganze habe ich in ein Script gepackt:

#!/bin/bash

#/usr/local/sbin/spamlern.sh 
# Einmal als Root 
#usermod -aG vmail amavis 
# in Root crontab 
#nice chmod -R g+rx /var/vmail/ 
# Anlernen HAM (funktioniert aber ohne, wie ich gemerkt habe) 
#find /var/vmail/*/* -type d -not -path "*.Spam*" -not -path "*.Junk*" -not -path "*.Trash*" -not -path "*new*" -not -path "*tmp*" -not -path "*.Sent*"$ 
# Anlernen SPAM 
nice /usr/bin/find /var/vmail/*/*/Maildir/ -type d \( -iname "*Junk*" -o -iname "*spam*" \) -exec /usr/bin/sa-learn --spam {} \; >/dev/null 
# Zustand NACH dem Lernen: #sa-learn --username=amavis --dump magic|grep 'n*am'|mailx -s 'sa-lern Status' root echo "$(date +'%Y-%m-%d')$(sa-learn --username=amavis --dump magic |grep nspam|cut -c18-30)" >>/var/log/spam-lern.log mailx -s 'sa-lern Status' root

#und als amavis User in die Crontab gepackt 6 5 * * 1,4  /usr/local/sbin/spamlern.sh

... und wo ist der "Dirty" Hack?

Hier

4 5 * * 1,4 nice chmod -R g+rx /var/vmail/ >/dev/null 2>&1
15 5 * * 1,4 nice chmod -R g-rx /var/vmail/ >/dev/null 2>&1

Ich erlaube damit meinem obigen Script für 11 Minuten, die Mailboxen nach Spam abzuklappern  

Update 27.02.2023:

Script ist nun im CVS und auch auf dem neuen rootserver aktiv, hatte ich vergessen.

Seit einiger Zeit beobachtete ich erneut eine Riesenlast auf dem Apache Server. Eine unserer Webseiten wurde massiv von http HEAD Anfragen überhäuft. 60000 http HEAD Requests. Die aufgerufene Seite ist immer - wie sollte es auch anders sein - ein Joomla plugin, nämlich plugin_googlemap2. Scheinbar ist das so ein SEO Ding, da das Plugin benutzt wird, um andere  Seiten aufzurufen. Interessiert mich ja nicht wirklich, ich möchte bloß den Traffic nicht, zumal es ruckzuck über 250 Requests die Sekunde sind und mein Monit (schon bei 150) den Load bemerkt und den Apache restartet. Funktioniert ja, nur wenn man gerade am surfen ist, ist das nicht lustig wenn die Verbindung alle paar Minuten zurück gesetzt wird. Die manuelle Holzhammermethode war anfangs war:

iptables -I INPUT -s 89.248.162.169 -j DROP

iptables -D INPUT -s 89.248.162.169 -j DROP

Funktioniert prächtig, nur nicht lange, denn wenige Stunden später kommt es von einer anderen IP. Ich versuchte es zuerst mit mod_evasive, über dieses apache plugin habe ich früher schon mal was geschrieben, doch diese Art von massiven Requests wurden davon nicht erfasst.

Zweite todsichere Methode wäre, das plugin googlemap2 einfach zu deinstallieren.

Wenn das nicht geht, muss man sich was anderes überlegen.

Nun ist ja die Frage, wer als Nutzer macht denn überhaupt HEAD Anfragen? Mir fällt niemand ein. Tools, die die Erreichbarkeit testen, kämen in Frage, die könnten aber genauso gut GET benutzen. Also war meine Idee, HEAD einfach zu verbieten. Die einzige Methode, die (bei mir) funktioniert, ist kein LIMIT Eintrag in der .htaccess des betreffenden Webs sondern eine RewriteRule.

RewriteEngine On
RewriteCond %{THE_REQUEST} !^(POST|GET)\ /.*\ HTTP/1\.1$ 
RewriteRule .* - [F]

Falls RewriteEngine On ohnehin bereits in der .htaccess drin ist, kann das entfallen. Ist bei Joomla Sites meist bereits auf on.

Nach dem reload des Webservers kann man allerdings weiterhin die Angriffe sehen, die werfen zwar nun einen Error 500 (Internal Server Error), aber den Trafic hat man immer noch, wenigstens können sie ihr Machwerk nicht erfolgreich zu Ende bringen.

89.248.162.169 - - [20/Feb/2016:09:01:37 +0100] "HEAD /plugins/system/plugin_googlemap2/plugin_googlemap2_proxy.php?url=web3.ekoloko.com HTTP/1.1" 500 224 "-" "Mozilla/5.0"

# apache-HEAD.conf
[INCLUDES]

[Definition]

failregex =  .*"HEAD.*$

ignoreregex =

# aus der jail.conf
[apache-HEAD]

enabled = true
port    = http,https
filter  = apache-HEAD
logpath = /var/www/*/log/access.log
bantime = 2880
# Ban attackers that try to use googlemaps insecurity

Nach massivem Missbrauch des eigenen Mailsystems überarbeitet man die Regeln und hofft nun wieder Ruhe zu haben.

Wenig später gehen Outlook Clients nicht (ja, ich kanns nicht ändern, ich habe ein paar outlook[lo|u]ser in meinem Bekanntenkreis)Das lag daran, das Outlook den Rechnernamen als Host im pop3 Sendedialog verwendet und ich nur fullqualified DNS Namen erlauben wollte.

Eigentlich war jetzt wieder alles gut. Nur Greylistiung (Postgrey) lief offenbar nicht.

Hat ziemlich gedauert, bis ich darauf kam mal mit postconf die Syntax zu checken und zu filtern, ob denn meine lokale Umleitung auf Port 60000 wirklich drin ist.

Was soll ich sagen? Nein! war nicht drin.

Ursache waren meine zahlreichen Optimierungsversuche, da kam irgendwann mal die smtpd_recipient_restrictions Zeile 2 mal vor und die untere Zeile war leider ohne die Postgrey Umleitung...

Also, Notiz an mich selbst: Wenn etwas nicht geht, was gehen sollte, systematisch vorgehen

Zum überprüfen vom Greylisting:

# Anmerkung: der Text muss genau dem Text entsprechen,der dem postgrey Daemon übergeben wurde
cat /var/log/mail.log |postgreyreport --nosingle_line --check_sender=mx,a  --separate_by_subnet=":==================\n" --greylist-text="This Mailserver is protected by greylisting. the temporary error message is going away after some time. Try later"

oder:

 cat /var/log/mail.log |postgreyreport  --greylist-text="This Mailserver is protected by greylisting. the temporary error message is going away after some time. Try later" --show_time

Achja, meine momentane Regel:

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf,  reject_rbl_client cbl.abuseat.org,reject_rbl_client dul.dnsbl.sorbs.net,reject_rbl_client ix.dnsbl.manitu.net, reject_unauth_destination,check_policy_service inet:127.0.0.1:60000

Update:

smtpd_recipient_restrictions = permit_mynetworks,
   permit_sasl_authenticated,
   check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf,
   reject_rbl_client pbl.spamhaus.org,
   reject_rbl_client cbl.abuseat.org, 
   reject_rbl_client dul.dnsbl.sorbs.net,
   reject_rbl_client ix.dnsbl.manitu.net,
   reject_unauth_destination,
   check_policy_service inet:127.0.0.1:8895,
   check_policy_service inet:127.0.0.1:60000


Mit dem Einzeiler:
 
grep 'blocked using' /var/log/mail.log|awk  '{a[$20]++;}END{for (i in a)print i, a[i];}'
 
Kann ich den Erfolg kontrollieren.
Momentaufnahme:
 
pbl.spamhaus.org; 135
cbl.abuseat.org; 92
ix.dnsbl.manitu.net; 24
 Noch ein Update:
 

Es ist schon traurig, da werden die Bandbreiten immer größer, man kann von zu Hause mit 100MBit ins Netz, nur wer hat davon am meisten?

Richtig, die Bot Netze mit ihrer unerschöpfliche Gier nach Bandbreite! Ich habe den heutigen Tag eigentlich nur damit zugebracht, mich mit Bilderklau, - auch so eine Seuche - und mit Referrer Spam auseinanderzusetzen.

Die allseits empfohlenen Rewrite Rules für Referrer Spam sind nicht so einfach automatisch umzusetzen und weil der Großteil der Spammer eh von dynamischen IPs kommen ist's auch eher sinnlos und kontraproduktiv. Was also tun?

2006 war mal im Linuxmagazin ein Bericht über ein neues Modul für den Apache. libapache2-mod-evasive. Das dient dazu DOS (denial of Service) Attacken automatisch zu blocken. Damals war es nicht ganz trivial das Modul auf einem Stable Debian Server zu installieren, heute genügt dazu ein schlankes apt-get install libapache2-mod-evasive und ein wenig fine tuning.

Das fine tuning beschreibe ich hier.

Man kann als fauler Admin auch einfach alles in Ruhe lassen, es funktioniert sofort. Denn das Modul wird durch die Installation automatisch enabled und hat funktionierende default Parameter.

Ob das Modul seine Arbeit tut, erfährt man durch einen Blick in /var/log/daemon.log und auch durch die Einträge in /tmp/dos-* .

Wo wir auch schon beim Thema Faul wären. Der Apache sollte temporäre Dateien nicht einfach in /tmp schreiben. Da lauern diverse Falle, die Angreifer leicht ausnutzen könnten. Beispielsweise ist hier ein Bericht dazu. Der engagierte Admin wird das also ändern wollen. Das ist ganz einfach. Zuerst eine neue Heimat suchen:

mkdir  /var/log/apache2/evasive
chown -R www-data:adm /var/log/apache2/evasive

Nun muß das dem Modul mitgeteilt werden: in /etc/apache2/mods-available/mod-evasive.load habe ich folgende Einträge drin:

Die Beispiel default Einträge habe ich zur Referenz auskommentiert darunter aufgeführt.

LoadModule evasive20_module /usr/lib/apache2/modules/mod_evasive20.so

  DOSHashTableSize 3097
  DOSPageCount 2
  DOSSiteCount 50
  DOSPageInterval 1.5
  DOSSiteInterval 1.5
  DOSBlockingPeriod 10
  DOSLogDir "/var/log/apache2/evasive"


#
# DOSHashTableSize    3097
# DOSPageCount        2
# DOSSiteCount        50
# DOSPageInterval     1
# DOSSiteInterval     1
# DOSBlockingPeriod   10
#

Kurze Erklärung der Parameter:

DOSHashTableSize: Die Größe der Hashtable, die für die einzelnen nodes benutzt wird. Könnte für einen ApacheServer mit starkem Verkehr erhöht werden. Es werden Primzahlen benutzt. Es wird immer auf die nächst höhere gerundet.

DOSPageCount: Schwellwert für die einzelnen Seiten pro DOSPageInterval , ab wann die Ip auf die Blacklist kommt.

DOSSiteCount: Schwellwert für alle von einem Client angeforderten Resourcen pro DOSPageInterval, ab wann die Ip auf die Blacklist kommt.

DOSPageInterval: Zeitraum, für die einzelnen Seiten, default 1 Sekunde

DOSSiteInterval: Zeitraum, für alle Aufrufe der Site, default 1 Sekunde

DOSBlockingPeriod: Zeitraum für die der Eintrag in der Blacklist steht, default 10 Sekunden, größer ist normalerweise nicht notwendig

DOSLogDir: Absoluter Pfad zum (existierenden) Directory für die Ablage der Blacklisteinträge.

Daneben gibt es noch die Möglichkeit einige IP-Adressen auf eine Whitelist zu setzen und weitere Einstellungen wie DOSEmailNotify, DOSSystemCommand
Dazu steht mehr in der Original Readme.

Der Autor des Modules hat im README (zless /usr/share/doc/libapache2-mod-evasive/README.gz) ausdrücklich darauf hingewiesen, das in der /etc/apache2/apache2.conf noch ein paar Einstellungen überprüft werden sollten. So muß KeepAlive auf On stehen und MaxRequestsPerChild darf nicht auf 0 sein,weil sonst die gespeicherten Blocks nicht gelöscht werden würden. Ich habe mal 20000 eingestellt, der Debian default für MaxRequestsPerChild ist 0. Der KeepAliveTimeout steht schon bei Debian auf 15, icch habe ihn so gelassen.

Zusammenfassung:

In  /etc/apache2/apache2.conf sollten folgende Einstellungen sein:

KeepAlive On

KeepAliveTimeout 15

MaxRequestsPerChild 20000

Nach den gemachten Änderungen kann man den Apache mit apache2ctl restart restarten.

Noch ein kleiner Hinweis zur DOSSiteCount. Das ist ein Wert, der empirisch auf seiner eigenen Seite ermittelt werden sollte, denn wer zum Beispiel in seinem Blog eine Ajax Live Search Funktion implementiert hat, dem könnte es bei menschlichen Besuchern durchaus passieren, das die Benutzer einen 403 Fehler kommen, obwohl sie ja keine Referrer Spam Automaten sind. Vor allem wenn die Besucher eine schnelle und vor allem kurze Anbindung haben. Wer also auf meiner Seite davon betroffen ist, sei es auch nur sproradisch, bitte melden, ich werde den Wert dann erhöhen. Meine Tests haben allerdings ergeben, das ich mit 50 auf der sicheren Seite bin. Mehr als 25 habe ich nicht in einer Sekunde festellen können

Erfolgskontrolle:  (alias ltr=ls -ltr)

~var/log/apache2/evasive]# ltr 
insgesamt 56K
-rw-r--r-- 1 www-data www-data 4 16. Dez 18:35 dos-84.132.23.200
-rw-r--r-- 1 www-data www-data 6 16. Dez 18:37 dos-91.40.41.216
-rw-r--r-- 1 www-data www-data 5 16. Dez 18:42 dos-77.21.23.66
-rw-r--r-- 1 www-data www-data 5 16. Dez 18:52 dos-77.185.40.188
-rw-r--r-- 1 www-data www-data 6 16. Dez 19:17 dos-77.10.150.190
-rw-r--r-- 1 www-data www-data 6 16. Dez 19:28 dos-95.89.50.13
-rw-r--r-- 1 www-data www-data 6 16. Dez 19:42 dos-194.246.122.11
-rw-r--r-- 1 www-data www-data 6 16. Dez 20:14 dos-91.186.46.168
-rw-r--r-- 1 www-data www-data 6 16. Dez 20:20 dos-31.17.63.12
-rw-r--r-- 1 www-data www-data 6 16. Dez 20:39 dos-79.235.241.62
-rw-r--r-- 1 www-data www-data 5 16. Dez 20:39 dos-188.100.5.129
-rw-r--r-- 1 www-data www-data 5 16. Dez 20:51 dos-87.158.41.156
-rw-r--r-- 1 www-data www-data 6 16. Dez 21:28 dos-93.223.51.108
-rw-r--r-- 1 www-data www-data 6 16. Dez 21:47 dos-77.10.0.219

Ich habe mir noch eine andere Art der Erfolgskontrolle überlegt.  Eigentlich müßte die Anzahl der 403 Fehler seit enablen von mod evasive dratisch angestiegen sein. Mal sehen.

 
# grep '12/Dec/' other_vhosts_access.log|cut -d' ' -f10|grep 403|wc -l
18

# grep '13/Dec/' other_vhosts_access.log|cut -d' ' -f10|grep 403|wc -l
30

# grep '14/Dec/' other_vhosts_access.log|cut -d' ' -f10|grep 403|wc -l
12

# grep '15/Dec/' other_vhosts_access.log|cut -d' ' -f10|grep 403|wc -l
24

#grep '17/Dec/' other_vhosts_access.log|cut -d' ' -f10|grep 403|wc -l
1152

 

Whow! und der Tag ist ja erst halb rum (16:50)

[Update 05.09.2011]: nach meiner Protestmail werde ich derzeit nicht mehr zitiert.

Dieser Beitrag ist also nur noch nachrichtlich.

In meinem Impressum weise ich ausdrücklich darauf hin, das ich keine kommerzielle Verwendung meiner Daten dulde.

Ich weise nicht extra darauf hin, das Daten in diesem Fall auch die Artikel sind, deshalb betone ich das hier extra: Ich widerspreche jeglicher kommerziellen Nutzung meiner Daten und Artikel. Ausnahmen gibt es nur nach vorheriger Kontaktaufnahme und einer ausdrücklichen Genehmigung durch mich.

Soweit das Vorwort, worum geht es?

Ich habe Samstag Nacht 3 Pingbacks erhalten, die von von meinem Blog als automatische Pingbacks erkannt und in den Status Moderiert und damit vorerst unsichtbar eingestuft wurden. Neugierig geworden habe ich mir diesen Content Wiederverwerter mal näher angesehen.

Diese Site www.my-tag.de  stellt also meinen Inhalt in Form einer Aggregatierung zur Verfügung. Die Seite finanziert sich selbst über Werbung. Sagt der Sitebetreiber. Damit ist das eine Site, die kommerzielle Interessen verfolgt und sich dafür den Inhalt aus diversen Blogs besorgt. Sofern man davon ausgeht, das dies so erfolgt, das man leicht den eigentlichen Urheber der Artikel identifizieren kann und man den Original Artikel ordentlich verlinkt, kann man von ethischen und moralischen Zweifeln geplagt sein, dennoch ist es soweit noch in Ordnung. Ich möchte es allerdings nicht und verwahre mich auch dagegen.

Was mich aber auf die Palme bringt, ist, das www.my-tag.de meinen Inhalt so aufbereitet und darstellt, das man als Leser über den wahren Urheber im Dunkeln gelassen wird. Meiner Meinung nach wird versucht einen anderen Urheber vorzutäuschen!

Links neben meinem Artikel Titel ist ein ziemlich großes Icon, auf dem Copyright steht. Der Link dazu führt aber nicht zu meinem Impressum, sondern zum Impressum von www.my-tag.de.

Dann wird, wie bei den Blogs üblich, nach dem Artikel, der nur als kurzer Anreißer zu lesen ist, der Autor genannt. Dort stehe aber wieder nicht ich, oder mein Blog, sondern ein gewisser ADMIN. Und wohin führt der hinterlegte Link? Nein nicht zu Zockertown.de, sondern zur sogenannten Artikelsammlung von ADMIN. Allesamt Artikel, die nicht auf eigenen Mist gewachsen sind. Im ersten Screenshot sieht man 3 Pingbacks, die beiden unteren beziehen sich auf den oben diskutierten Sachverhalt, der obere Pingback führt allerdings einen anderen Autor an, nämlich einen ANDERS DENKEN. Hier ist übrigens als Anreißer nur die apt-get install tomcat6 ... Zeile angegeben. Der angebliche Autorenlink führt aber auch wieder zu der Artikelsammlung auf www.my-tag.de.

Natürlich kann man auch auf die Artikelüberschrift klicken, wenn man denn überhaupt bemerkt, das es sich um einen Link handelt.

Mein Fazit: Die Site www.my-tag.de dient dazu, durch Präsentation möglichst vielen Textes und die starke Verwendung von Schlagwörtern im Ranking bei Google zu trumpfen und viel Werbeeinnahmen über Google AdSense zu generieren. Unter Fachleuten werden solche Seiten auch MFA (Made For Adsense) genannt. Ich bin nicht gefragt worden, ob ich meine Inhalte zur Verfügung stelle und ich lehne es grundsätzlich ab. Der Hinweis auf der Site, man möge doch bitte eine email senden, wenn man nicht mit der "Zitierung" seiner Beiträge einverstanden ist, halte ich für eine Zumutung und soll nur irgendwelchen rechtlichen Mindestanforderungen genügen.

Eine gewisse Anständigkeit setzt eine Anfrage im Vorfeld voraus.

Ps: ich habe noch weitere Screenshots zu dem Thema gemacht, will euch aber nicht langweilen, deshalb soll es nun genug sein.

Pps: Ich bin nicht der einzige, der sich über www.my-tag.de  beschwert. z.B.

http://www.fuxblog.de/2011/08/23/newsgrabber-und-trackback-spammer-my-tag/

http://www.crazytoast.de/trackback-pingback-spam-2-spammer-angeschrieben.html

Und auch hier, obwohl es nicht explizit um my-tag geht:

http://stadt-bremerhaven.de/in-eigener-sache-das-ding-mit-dem-content

Fail2ban ist eine Wissenschaft. (Artikel von 2010-02-21 19:00)

Naja, nicht wirklich. Aber die Regular Expression sind es. Einfache Dinge gehen mir mittlerweile gut von der Hand, aber die Lücken sind größer als die Wissensinseln. Wenn man sich allerdings den Wikipedia Artikel ansieht kann man schon zu den Schluß kommen, das es die Regex eine Wissenschaft sind. Für mich sind sie das auch. Anders ist es nicht zu erklären, das ich Stunden brauchte, bis ich den Ausdruck für pure-ftpd richtig erstellt hatte.

Doch wie testet man das eigentlich richtig? Dafür hat fail2ban das tool fail2ban-regex mitgeliefert

Der korrekte Aufruf erschließt sich nicht sofort. Der richtige Aufruf lautet:

fail2ban-regex logfile 'regexp'

pure-ftpd(?:\[\d+\])?: \(.+?@<HOST>\) \[WARNING\] %(__errmsg)s \[.+\]\s*$ 

Für sasl sieht es so aus

     : warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed: \w+

Update 27.8.2011:

weil die ewige Sucherei nach irgendwelchen lücken in Programmen, die ich gar nicht installiert habe, mich a) nervt und b) unnötig das error.log vollmüllt, habe ich nun mittlerweile dieses hier:

fail2ban-regex /tmp/v '[[]client (?P<host>\S*)[]] File does not exist: .*\.php'

Wo /tmp/v ein Ausschnitt eines Apachelogs ist, wo einige der Fehler gehäuft auftreten.

Der regexp Ausdruck in den ' '  ist exakt der Ausdruck, der in die Jail Datei in /etc/fail2ban/filter.d/ gehört.

Noch der Hinweis, das hinter dem regexp in der Datei kein space sein darf, es gehört sonst zum Ausdruck.

Happy Hacking!

So ganz verstehe ich es nicht, nein, besser, ich verstehe es überhaupt nicht.

Seit dieser Nacht empfange ich etliche sinnfreie Kommentare, die letzten 3 habe ich hier mal geknipst. Was soll das? Wer hat da was von?

Vorschläge, Erklärungen?

Also, wenn sich ein Verlinker die mühe gemacht hat und einen individuellen Text verfasst hat, um auf seine Seite zu verweisen, habe ich den Kommentar bisher meist drin gelassen.

Heute morgen hatte ich 4 Kommentare auf meinen letzten Beitrag, alle 4 waren Spam Kommentare, alle 4 nur kurze bla bla Sätze.

Leute, das ist mir zuviel. Ich habe die Captcha Grenze auf 0 Tage gesetzt, d.h. es ist nun immer notwendig, schade.

Nach einer erneuten Spam Attacke muß man entweder mit einer riesigen vollgestopften mailqueue leben, oder aber aufräumen. Damit reguläre mails nicht behindert werden, ist aufräumen angesagt.

Ich mache es immer damit:

mailq|grep 'web64@blah.xx'|cut -d' ' -f1|postsuper -d -

Das funktioniert, weil die Spammer immer eine  mailadresse des Servers als Absender verwenden, die es glücklicherweise gar nicht gibt:-)