Korrekt, es matcht bei jedem Login. Das nehme ich aber bei 10 Versuchen innerhalb 600 Sekunden in Kauf.
Die Tipps unter https://codex.wordpress.org/Brute_Force_Attacks sind gut, aber auch hier das Problem dass ich nicht direkt von mir betreute Hostingkunden diese Maßnahmen schwer aufdrängen kann.
Dieses wp-fail2ban Plugin ist mir bei meiner Recherche auch untergekommen. Aber auch hier wieder das selbe Problem wie beim "Wordfence" Plugin (das ich wie gesagt sehr empfehlen kann): Ich hab nicht unter Kontrolle, ob die Kunden die nicht direkt von mir betreut werden, das auch installieren.
Daher wollte ich einen Ansatz bauen, der ohne Wordpress Plugin auskommt und daher direkt auf die access_log los geht.
Die Angriffe auf Wordpress Installationen begannen mich immer mehr zu nerven. Wenn ich selbst mit wordpress was mache, installiere ich stets "Wordfence", das macht einen ganz guten Job. Aber bei nicht direkt betreuten Kunden hab ich das natürlich nicht unter Kontrolle. Daher hab ich mir mit fail2ban was gebaut und zwar wie folgt (Ziel waren die Angriffe auf das login sowie auf die xmlrpc zu minimieren):
File: /etc/fail2ban/jail.d/wordpress.conf
File: /etc/fail2ban/filter.d/wordpress.conf
Arbeitet bis jetzt ganz gut und blockt permanent irgendwen.
Freu mich über eure Meinungen bzw. vielleicht hilft es mal jemand.
Sehr sehr viele dubiose Zugriffe kommen leider von dort. Ein Umstand der mich immer davon abgehalten hat mir bei denen ein Produkt zu holen oder auch nur näher anzusehen.
Aber vielleicht schickt ihr ein paar Log Schnippsel an deren Abuse Abteilung? https://www.digitalocean.com/company/contact/#abuse
Ein heißer Kandidat wäre hier vielleicht die Datei /service/qmail-smtpSd/run ?
Diese liest anscheinend das Limit aus der Datei /var/qmail/control/concurrencyincoming in die Variable MAXSMTPD. Ich würde diese mal testweise durch einen händischen, höheren Wert ersetzen.
Dürfte trotzdem nicht zu so einer Fehlermeldung führen. Ich hatte schon 100.000 und mehr Mails in der Queue, das bringt qmail (verzögerte Zustellungen natürlich jetzt mal abgesehen) eigentlich nicht aus der Ruhe.
Okay, ich konnte es inzwischen weiter eingrenzen. Ich habe mich geirrt als ich den Kunden ferngewartet habe. Es war kein Outlook 2016, sondern 2013.
In einem Outlook 2016 funktioniert alles perfekt. Ebenfalls in einem Outlook 2010 das ich hier noch rumstehen hatte.
Ein Gespräch mit einem befreundeten IT Techniker im Clientbereich ergab dass Outlook 2013 anscheinend bei IMAP extra buggy ist, was auch mit Updates nie wirklich behoben wurde.
Hallo,
Generell ist mir ja nicht unbekannt dass Outlook ja nie wirklich der Vorzeige Client für IMAP war. Gerade eben hatte ich aber ein sehr frustrierendes Erlebnis mit einem Outlook 2016...
Imap Konto eingerichtet, INBOX als Stammordner eingetragen, soweit auf den ersten Blick alles gut. Dann einen Ordner angelegt. Auch gut, wurde tatsächlich am Server auch angelegt (kontrolliert am Filesystem und per Roundcube). Nun wollte ich einen Unterordner erstellen. Sah soweit gut aus, aber am Server wurde der nicht angelegt. Auch Mails, die in diesen Unterordner reinkopiert wurden, waren nirgends im Maildir des Users zu finden. Muss daher davon ausgehen dass Outlook den Unterordner lokal verspeichert hat, obwohl ich explizit in der Ordnerstruktur den übergeordneten IMAP Ordner ausgewählt habe.
Hat hier vielleicht jemand etwas mehr Erfahrungen mit IMAP auf Outlook und vielleicht ein paar Best Practice Tipps?
Interessant... Danke für die Info.
Im Normalfalls geht es mit pdadmin Boardmitteln (spamfilter der domain aufgedreht, greylisting aktivieren) einigermaßen. Ich selbst kann verstehen, dass hier seitens der pdadmin Standardumgebung nicht noch mehr Filtermechanismen integriert wird, weil es natürlich die Gefahr von false positives und den gesamten Supportaufwand erhöht.
Ein externer Dienstleister kann hier darüber hinaus noch gute Dienste liefern. Wir sind ganz zufrieden mit EuropeanMX. Einzig dass deren Pakete den Traffic miteinbeziehen finde ich nicht so toll, wird aber durch deren Fair Use Policy und dass sie hier nicht auf jedem MB herumreiten wieder ganz gut wett gemacht.
Perfekt, Dankeschön! Spielt es eine Rolle ob die Zeile vor oder nach der bereits enthaltenen Zeile (greylist Skripte wenn ich nicht irre) eingefügt wird?
Nein, das ist es ziemlich sicher nicht. In der rcpthosts stehen ja die Domains für die der Server Mails annimmt. Ich möchte aber das ein Server für die IP eines anderen Servers Smarthost sein kann. Ärgert mich grad, weil ich hab das vor ein paar Jahren ein paar Mal gemacht und nun finde ich meine Notizen nicht mehr. Könnte aber sein dass mir die ohnehin nichts bringen würden, weil ich das vielleicht damals noch über Freigabe der IP in der smtp-oplock Geschichte gemacht habe, diese gibt es ja in der Form nicht mehr.
Obwohl schon öfter gemacht (leider schon ein paar Jahre her) finde ich grade nicht mehr raus wie ich das machen muss.
Möchte einer IP das Relayen über meinen Server erlauben. Erinnere mich, dass ich da einen RELAYCLIENT EIntrag wo machen musste, glaub ich.
Kann mir hier jemand helfen?
Das ist kein pd-admin/Serverumgebungsproblem. Da geht es um den logrotate Job vom System selbst. Ich würde mal alle syslog*gz Files weg moven und schauen ob sich logrotate dann die nächsten Tage fängt.
Ansonsten würde Ich mal rumgooglen, anscheinend ist das ein Problem das auf Debian und Verwandten öfter mal vorkommt (siehe zb. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734688 ).
Generell senkt das Ändern des Ports (auf einen eher exotischen) das "Grundrauschen" schon ganz massiv. Das seh ich auch im Alltag recht einfach, Centos zb. hat das login ja so konfiguriert dass es die fehlgeschlagenen Logins anzeigt nach einem erfolgreichen Login. Da steht bei einem Server mit Port 22 schnell mal was von mehreren Tausend. Bei Servern mit Alternativport meistens gar nichts. Das fällt mir seit Jahren so auf. Also dürfte es mit dem Portscannen nicht so weit her sein bei den Robotern.
Also ja, gebe Dir recht, ganz allgemein kann man über den Sicherheitsgewinn des Portwechsels durchaus streiten. Aber es bringt in jedem Fall schonmal viel weniger Login bzw. Auth Prozesse. Also ich fühl mich defnitiv wohler damit.
...liest sich besser, und wird von Suchmaschinen auch "bevorzugt" bzw. werden nicht-Suchmaschinenfreundliche-Links "abgestraft".
Das ist, zumindest zu einem sehr großen Anteil, ein Mythos der von Google selbst immer wieder im Laufe der Jahre klar gestellt wurde: https://webmasters.googleblog.…-urls-vs-static-urls.html
Darum gefällt mir, dass Wolflab in seinem Hilfe-Artikel primär von "benutzerfreundlichen URLs" spricht und nicht von "suchmaschinenfreundlichen URLs".
Also SEO muss aus meiner Sicht nicht die Hauptmotivation für solch eine Umstellung sein.
Ich hoffe BTW dass die Konfiguration der SSL/TLS Maildienste mal vereinfacht oder über die Weboberfläche gelöst wird. Ich such mir jedes mal wieder einen Ast ab nach dem dc-install Script 
Ich hatte glaube ich mal einen vergleichbaren Fehler weil die betroffene Domain einen ipv6 (AAAA) Eintrag hatte.
Letsencrypt versuchte daraufhin offenbar die Verifizierungsdatei über ipv6 abzuholen, was aus für dieses Thema nicht relevanten Gründen nicht funktioniert hat.
Kannst Du derlei Gründe ausschließen?
Eigentlich haben wir Deine Frage hier schon behandelt, bilde ich mir ein:
Ja, mich fasziniert es auch manchmal, wenn ich mein Registrierungsdatum sehe. Unfassbar wie die Zeit vergeht.
