Sehr allgemein formuliert kümmert sich pd-admin recht wenig um Software die ansonsten am Server installiert ist. Ausnahme natürlich Dienste, die zum Beispiel bezüglich benututzter Ports oder so mit dem pd-admin Diensten konkurrieren.
Habe mal kurz quergelesen worum es bei tesseract geht, das sieht mir nicht danach aus dass es Probleme geben sollte.
Ehrlich gesagt wundert es mich, dass Du mit diesem Setup durchgekommen bist, ohne dass bei Dir rund um die Uhr das Telefon läutet. Also jedenfalls dann, wenn auf dem betroffenen Server schon einige Mailboxen laufen. Insbesondere Apple (inkl. iphone etc.) ist bei sowas extrem empfindlich. Wenn da der Hostname aus dem Dialog nicht mit dem Zerti zusammenpasst, hagelt es ständig Warnungen die sich in neueren ios Versionen nicht mehr dauerhaft abnicken lassen.
Unbeschadet dessen: Ich würd mal probieren was passiert, wenn Du ein Zerti verwendest dass beide Hostnamen mit drin hat. Dank letsencrypt kann man das ja recht leicht mal kostenlos antesten. Im Falle von certbot zum Beispiel einfach mal alle benötigten Hostnamen mit -d verfüttern.
Wenn das geht, wärst Du fein raus.
Vielleicht findet sich ja hier ein pd-admin Hoster, der seinerseits bei B&K ist? Wär ein Kompromiss.
vielen Dank für Dein Feedback. Meinst Du damit den Punkt Mail-Submission limitieren und Drosselintervall?
Aber der zieht doch lediglich wenn "Reines Email-Hosting" aktiviert ist.
Ja, den mein ich. Und nein, der zieht immer (Ausnahme wie gesagt Mails die per Script oder auf der Kommandozeile erstellt wurden). Gott sei Dank.
Deine Domains sind im Normfalfall außer Gefahr. Du bist zwar ziemlich sicher auf einem Berg voller Blacklists gelandet, aber diese blacklisten in aller Regel ja die IP und nicht die Domain. Stampf den Server ein und hol Dir einen neuen mit neuer IP. Ist zwar nicht besonders fair dem gegenüber, der als nächster diese IP bekommt, aber da mussten wir alle mal durch und Du bist die Sorge schneller los.
Für den sicheren Einsatz empfiehlt sich starke Kennwörter zu verwenden und fail2ban einzusetzen. Typo3 sollte immer aktuell gehalten werden.
Bei mir geht seit längerem kein Server mehr ohne fail2ban online. Damit kriegt man die Passwortattacken ganz gut in den Griff.
In deinem Fall wäre weiters zu klären, warum es kein vernünftiges Mail Limit gab. Normalerweise wird im Angebot ja festgelegt, wieviele Mails man in welchem Zeitraum verschicken darf. Diese Mechanismus verhindert meist Schlimmeres. UND er hat den Nachteil, dass er nicht für Mails zieht, die über Scripte eingeliefert wurden. Deswegen würde ich in Deinem Fall nochmal klären ob der ganze Mist nicht doch eher auf ein veraltetes Webscript zurückzuführen ist.
Owncloud... Ich würds mir nicht antun in Zeiten in denen man Nextcloud Instanzen bei allen möglichen Anbietern voll gewartet um ein paar Euro mieten kann. Wenn Du es dennoch machen willst, würde ich es auf einem eigenen Server machen.
Ja, der Thread hat sich etwas verlaufen.
Check mal mit df -i ob Deine Platte keine Inodes mehr hat. Soweit ich das mitbekommen habe, ist die Kiste ja aufgrund Deines Urlaubs oder so relativ lange in dem angegriffenen Zustand dahin gelaufen. Eine Theorie wäre, dass Dir so dermaßen viele Spams (zuzüglich Bounces darauf) eingliefert wurden, dass die Platte keine inodes mehr hat.
Um wieder zum Thema zu kommen, die neue Serverumgebung mit dem gehärteten Dovecot ist raus. DANKE an Herrn Bradler und sein Team.
Das "unable to append to Bounce message" hat zu 99% damit zu tun dass Deine Disk voll ist. Hat nichts mit der Lücke zu tun um die es hier geht.
Du musst dringend rausfinden warum Deine Festplatte so voll ist bzw. platz schaffen.
Wie meinst Du, Du wirst "zugeballert"?
Zudem: Wenn Du ein Update machst wegen dieser Sicherheitslücke, damit kannst noch warten. Die derzeitige SEU Version hat noch die betroffene Version drin.
Schwer für mich zu sagen, inwieweit wir betroffen sind. Workaround gibt es jedenfalls anscheinend keinen.
Sieht verdächtig danach aus als würde der Installer hier die CLI Version prüfen. Hast Du diese schon hochgestellt?
Herzlichen Dank für die schnelle Information!
https://www.heise.de/security/…rver-ProFTPD-4477624.html
Bin aber derzeit unsicher inwieweit ein typisches pd-admin Setup betroffen ist. Der Text im Bugtracker suggeriert dass es nur ausnutzbar ist wenn man Anonyme User zulässt - was bei uns ja nicht der Fall ist: http://bugs.proftpd.org/show_bug.cgi?id=4372
Ich konnte eben mehrere Dateien, die definitiv am Montag noch geblockt wurden, versenden. Gehe daher mal vorsichtig davon aus, dass das Thema vom Tisch ist und habe Clamav wieder aktiviert.
Cool! Wenngleich sich in meiner Gedankwelt die Hinweise schon verdichtet haben, dass es in Richtung des Zertis als Ursache geht, wär ich darauf nicht gekommen.
Wobei, jetzt wo Du es sagst, darauf muss man generell aufpassen. Manche Anbieter liefern die Zertifikatsdateien mit Windows Zeilenumbrüchen und wenn man diese dann auf Linux System spielt, kann genau so ein Quatsch rauskommen. Ich glaube zum Beispiel GoDaddy liefert bis heute eine der Dateien aus dem Zertifikatspaket mit Windows Zeilenumbrüchen aus, die zweite Datei nicht.
Oder vielleicht doch mal testweise ein Zerti besorgen das auf den eigentlichen Hostnamen aus dem SMTP Dialog (bfnet.bpaserver.net) lautet und das an dc-install verfüttern. Dann wieder testen ob von gmail was durchkommt. Dank letsencrypt kostet so ein Experiment ja nichts (ausser Zeit) und Du kannst dann das als Ursache zumindest ausschließen - bzw. sollte das Mail dann durchgehen, weißt Du dass das doch die Ursache ist.
Das scheint mir echt ne harte Nuss zu sein. Soweit fällt mir in der DNS/MX Konfiguration nichts auf. Über die Tatsache, dass das implementierte Zerti einen anderen Common Namen hat als sich der Server im SMTP Dialog meldet (und auf den der PTR Record lautet), kann man diskutieren. Ich würde es mitelfristig harmonisieren, vermute aber mal nicht dass es was mit Deinem Problem zu tun hat.
Das Zerti ist ja relativ jung, vielleicht kannst Du trotzdem mal überlegen, ob der Zeitpunkt ab dem es die Probleme gab (3-4 Tage auf oder ab, weil es ja immer etwas dauert bis es bemerkt wird) mit dem Zeitpunkt der Zerti Installation zusammenfallen könnte. Falls ja, wär es ein Hinweis. Vielleicht bricht Google den SMTP Dialog ja tatsächlich ab, wenn das Zerti nicht mit dem Hostnamen zusammenpasst. Wenn zu so einem frühen Zeitpunkt der SMTP Dialog von der Gegenstelle abgebrochen wird, wär es auch denkbar dass Du nichts schlüssiges im Log siehst.
Ansonsten haben wir das bald soweit durchanalysiert, dass bald nur mehr Routing/Firewall Probleme von Google zu Dir übrig bleiben. Das würde dann auch ebenfalls erklären warum Du so gar nichts im Log siehst.
Danke für die Hostnamen, aber mich würde mehr eine Domain interessieren, die definitiv nichts von gmail empfangen kann.
Macht es Sinn hier mal ein paar records zu posten oder andere Zusammenhänge darzustellen?
Ich kann zwar nichts versprechen, aber es kann vielleicht nicht schaden. Vielleicht fällt jemandem von uns was auf. Zumindest eine betroffene Domain wär nicht uninteressant, den MX Record dazu etc. können wir dann eh selbst abfragen.
Sumeragi , hast eine PN von mir
