Beiträge von VeNoM

Scheint mir so als ob Greylisting nicht wirklich eingeschaltet ist auch wenn das in der Oberfläche als eingeschaltet steht. Leere Email-Adressen dürften so oder so nicht akzeptiert werden.
Existieren noch weitere Logeinträge?
Ich könnte mir z.B. Vorstellen, dass es ein Problem mit den Rechten gibt. Das heißt dass in der Oberfläche von PDAdmin zwar alle Schutzmaßnahmen auf Ein stehen, in Wirklichkeit diese aber durch falsche Zugriffsrechte in den einzelnen Scripten nicht eingeschaltet werden.

Danke für das Script.
@TBC
Da am Ende der Befehlskette chown durchgeführt wird, ist deine Vermutung mit den Rechten wohl damit bestätigt.

Hab noch oben editiert.

Ok, dann kann man das ausschließen. Im Moment weiß ich gerade auch noch nicht weiter . Vielleicht fällt mir später noch was dazu ein.

Nutzt Du nen Webmailer wie Sqirrelmail? Ich denke vielleicht an ein Loop back. Das hab ich mal so erlebt in Verbindung mit Squirrelmail.

Läuft Dein RDNS vom SMTP-Server korrekt? Routet das korrekt zurück?

Weil hier hat wohl jemand ähnliche Probleme wohl durch einen inkorrekten RDNS Eintrag.

http://stackoverflow.com/quest…n-and-email-going-to-spam

Vielleicht ein Ansatz bevor man schlimmes denkt. Wie sehen die Logs aus wenn Du eine Mail an Dich selbst schickst?

Das sollte aber nur der alias sein. Wie sieht der RFC-Header aus? Sorry wenn ich bohre aber es ist wichtig.
Ist das der echte Absender oder nur aufgesetzt?

Steht sonst nix weiteres im Log?

Das könnte sonst genauso gut aus einem Script wie zum Beispiel ein Kontaktformular stammen.

Hast Du den entsprechenden Logeintrag gefunden bei dem der Angreifer tatsächlich ein Postfach benutzt hat? Das wäre sehr wichtig zu wissen was da los war bzw welches Postfach und ob es wirklich ein "offenes" Postfach war und nicht irgendwas anderes.
Nachher sehen wir vielleicht den Wald vor lauter Bäumen nicht.

Da scheinen mir die Perlpakete zu fehlen. Ist das die Originale Config?

Moment, von welcher Seite aus durchgekommen?

Greylisting checkt eingehende Emails keine ausgehenden.

Der von Dir gepostete Log hat nichts mit Greylisting zu tun?!

Das ist ein Versuch an ein gültiges Postfach zum versenden von Mails zu kommen.

Auf jeden Fall solltest Du Fail2ban wieder auf den Mailserver ansetzen. Alternativ bzw zusätzlich könnte man auch noch auf Host deny setzen. Hat aber auch Nachteile.

Hi Eisenherz,
Ich sehe hier nicht dass Greylisting "überlistet" wurde. Greylisting bewirkt eigentlich nur, dass überprüft wird ob es sich beim Ahesender der Mail um einen Mailer handelt oder um ein Script welches Emails via vorgefertigten Listen (oder ähnliches) genau jeweils einmalig versendet.
Normalerweise versucht ein Mailserver die Email ein paarmal zu zustellen bis die Email entweder ankommt oder ein Zustelllimit erreicht wurde. Genau dies überprüft Greylisting indem die erste Mail abgelehnt wird und dann die zweite Email erwartet wird.

Hier liegt vermutlich eher etwas anderes vor.

Hi,
Hier steht eine Beschreibung dafür.

https://developers.google.com/speed/pagespeed/module/install

Müsste meiner Meinung nach allerdings an PDAdmin angepasst werden damit es läuft.

Wenn ich das richtig deute setzt der Zielserver noch sslv3 ein. Das würde ich annehmen da der Fehler beim "anrufen" (Hello) des Zielservers aufläuft. Du hast bei dir kein sslv3 eingesetzt also können sich die Dienste nicht verbinden.

Deshalb wird das abgelehnt. Alternative ist nur auf ein anderes Protokoll umzusteigen bzw auf SSL bei dieser Mail zu verzichten.

Sollte das umgekehrt sein (was ich nicht glaube), so empfehle ich dir das hier zu lesen und ergo sslv3 abzuschalten.

http://www.phpgangsta.de/sslv3-uralt-broeckelig-abschalten

Jau, aber der Log sieht auch nicht vollständig aus. Da fehlt meines Erachtens noch einiges.

Da das mit einem Script augenscheinlich flach fällt, müsstest Du Logeinträge finden bei dem Logindaten übermittelt werden. Sollte eigentlich im mail.log zu finden sein wenn ich mich nicht irre.

Welches Format nimmst Du bei den Partitionen? Ext3 oder Ext4?

Ich hab mit Ext4 ähnliche Probleme bei den Berechtigungen gehabt

Ich glaube die Frage hat sich erledigt. Siehe update der SE von gerade eben.

Meiner Meinung dürfte das unabhängig davon sein ob es sich jetzt um die servereigene Umgebung handelt oder um die SE.
Die SE ist bringt zwar die eigenen Pakete mit, trotzdem dürfte das aktuelle Problem auch hier zutreffen. Eine eigene Shell / Bash wird nicht mitgebracht und wenn doch wäre die Lücke dort sehr wahrscheinlich ebenso vorhanden.

Mich interessiert welche Tests (und Ergebnisse) Du durchgeführt hast, so dass Du weist oder vermutest, dass Systeme mit der SE nicht angreifbar oder betroffen sind.

So wie ich das lese gibts das Perlupdate ausschließlich für 64Bit Systeme. (Reihe 4)

Danke für die Info Herr Bradler.

Das klappte unter Debian 5 bei mir schon zeitweise nicht mehr. Liegt aber am System und nicht an PDAdmin. Einfach den kompletten Paketname hin schreiben und dann passts.