Gehackt?



Den Anfang werde ich nie finden,
weil es verschiedene wellen gab,
ganz am anfang lag es am offenen relay aber jetzt ka.

Die ersten Logs, gibt es wahrscheinlich garnicht!
Um das Problem zu beheben, den Anfang zu finden,
schon öfters neugestartet und postfix geleert.

Postfix ist immer wieder down,
ist lasse testweiße laufen!
 
Sorry, aber dafür habe ich grad kein Verständnis.
Wenn Du die Quelle finden möchtest, dann finde den Anfang.
Es reichen ja ein oder zwei Mails aus. Und wenn Du tatsächlich die Mail-Queue geleert hast, dann wird es neue Emails geben die einen Anfang haben.

Die Alternative ist, Du nimmst Dir einen Profi, der das Problem angeht. Schreib einfach mal im "Suche" und Du wirst jemanden finden, der Dir weiterhelfen kann.

huschi.
 
Du hast einfach blind aus mehreren HowTos für unterschiedliche Postfix-Versionen irgendetwas rauskopiert und daraus eine völlig verkorkste main.cf gebastelt. Das kann nicht gut gehen und führt dann zum Beispiel dazu, dass Du unter Anderem Deinem kompletten /24-Subnet das Relayen erlaubt hast.
Ich werde Dir nicht das Lesen abnehmen, denn so unverständlich ist die Postfix-Doku nun wirklich nicht und ich werde Dir dementsprechend auch Deine main.cf nicht korrigieren. Ich werde Dir lediglich nahelegen den Server komplett vom Netz zu nehmen und stattdessen vernünftigen Webspace zu nutzen. Du benötigst keinen Server!
 
Hallo, ich hänge mich mal dran weil es mich jetzt auch erwischt hat.
Der selbe Spammer mit selber IP. Er hat den ganzen Tag lang fleißig Facebook-ähnliche Mails an Hotmail und Yahoo Kunden verschickt um diese auf seine Webseite zu locken, sieht nicht direkt nach Phishing aus. Yahoo hatte gleich die Schotten dicht gemacht und nichts mehr angenommen.

Nachdem es bemerkt wurde (leider erst ein Tag später), natürlich sofort Postfix angehalten und Logs analysiert, die Quelle war recht schnell gefunden da durchgehend das selbe:

Nov 2 07:21:07 h0000 postfix/smtpd[1574]: DEF406CC0D7: client=unknown[92.48.121.159], sasl_method=LOGIN, sasl_username=web13p1

Dazu muss ich sagen es ist ein shared Web- und Mailhosting-Server, den ich schon allein aus diesen Gründen versuche möglichst abzusichern wo ich kann, ein offenes Relay kommt nicht in Frage, darauf habe ich von Anfang an geachtet. Der Kunde von web13 nutzt auch nur Mailhosting, daher entfällt die Möglichkeit das der Spammer den Weg über das Webhosting gefunden hat.

Der Verbindungsaufbau erfolgte also über SMTP mit dem Benutzernamen web13p1. Also zunächst einmal Passwort des Postfachs geändert, Queue geleert und Postfix gestartet. Da alle neuen Verbindungsversuche nun abgelehnt wurden und nichts neues in der Queue landet, ist der Spammer nun erst mal ausgesperrt. Kunde ist informiert.

Irgendwie muss der Spammer also an die Zugangsdaten für web13p1 gekommen sein. Entweder durch Bruteforce/Wordlist Attacke oder er kam über einen Trojaner oder sonstiges auf Kundenseite, der Server selbst ist clean.

Bruteforce/Wordlist konnte ich bisher noch nicht entdecken, aber die kann ja auch schon wer weiß wie lange zurück liegen, wäre aber Anhand größer Logs ins Auge gestochen.

Ich stecke ja auch nicht drin was die Kunden mit Ihren Zugangsdaten/PCs anstellen.

Meine Frage ist, wie kann ich so etwas zukünftig verhindern ohne das ich Kunden vergraule (Newsletter Versand soll möglich sein)?
 
Last edited by a moderator:
Hallo, gerne kannst du hier weiter schreiben :-)
Bei dir ist der gleiche Fehler aber du hast den Anfang gefunden?
Also über SMTP, da bist du dir sicher ?!
Demnach müsste das ja bei mir der gleiche Fehler gewesen sein?!
Ich bin inzwischen auf Debain umgestiegen, alle Passwörter geändert und noch mehr abgesichert, bisher hab ich ruhe! Aber das sollte ja nicht die Lösung sein :-(
 
Bei dir hat der Spammer den Account web2p1 benutzt, habe ich in deinem Auszug aus der active-queue gesehen, ob er bei dir aber über SMTP kam konnte ich nicht sehen da der connect/disconnect Teil gefehlt hat.

Der Anfang sah bei mir so aus:
Code: 
Nov  2 07:21:07 h0000 postfix/smtpd[1574]: warning: 92.48.121.159: hostname 92-48-121-159.static.as29550.net verification failed: Name or service not known
Nov  2 07:21:07 h0000 postfix/smtpd[1574]: connect from unknown[92.48.121.159]
Nov  2 07:21:07 h0000 postfix/smtpd[1574]: DEF406CC0D7: client=unknown[92.48.121.159], sasl_method=LOGIN, sasl_username=web13p1

In der 2. Zeile siehst du es eine externe SMTP-Verbindung sein muss, wäre diese über PHP, Shell etc. aufgebaut worden, würde da "connect from localhost[127.0.0.1]" stehen und es wären zeitgleich auch Access-Logs von Apache da, was bei mir nicht der Fall war.
 
Last edited by a moderator:
Cheef-Daniel said:
Meine Frage ist, wie kann ich so etwas zukünftig verhindern ohne das ich Kunden vergraule (Newsletter Versand soll möglich sein)?
Click to expand...

Bruteforce-Versuche könntet Du verhindern, indem Du Techniken wie fail2ban einsetzt und darauf achtest, dass die Kunden sichere Passwörter einsetzen. Für letzteres gibt es unterschiedliche Lösungen, die entweder direkt beim Ändern das Einhalten gewisser Mindeststandards durchsetzen, oder Du lässt Programme wie crack über die Benutzerdatenbank laufen und unterrichtest Benutzer mit schwachen Passworten.

Mit dem policyd kannst Du die Anzahl der Mails einschränken. Newsletter würde ich durch dedizierte Mailinglisten realisieren, die von der Limitierung nicht betroffen sein sollten, da nur jeweils eine Mail an die Mailingliste verschickt wird.
 
ich nutze jetzt denyhost und sichere somit erstmal ssh ab.
Kann ich damit auch FTP-Absichern oder muss ich denyhost durch fail2ban ersetzen?
 
Denyhost (als Programm) kenne ich nicht.

Fail2ban kannte ich bereits und setze es auch schon seit langem ein, dies sperrt normalerweise IPs aus wenn bestimmte Regeln in vorher definierten Logs greifen, zum sperren verwendet es je nach Einstellung etwa iptables oder die deny.host Datei.

Wie ich aber gerade festgestellt habe, griffen durch irgendein Update die Regeln für mein SMTP nicht mehr, dies habe ich gerade gefixt. Fail2Ban überwacht bei mir nun das Mail-System, Apache und FTP. SSH nicht, da es nur auf einem anderen Port mit Public-Key-Verfahren läuft, würde ich dir auch empfehlen, das Public-Key-Verfahren macht Bruteforce nutzlos.

Der Tip mit policyd ist gut, das werde ich mir ansehen, um dass Limitieren werde ich da wohl nicht rumkommen.
Aber das mit dem Newsletterversand habe ich nicht ganz verstanden, die Newsletter möchte ja nicht ich selbst verschicken, sondern eventuell meine Kunden über meinen Mailserver, das liegt ja nicht in meiner Hand wie die dann Ihren Newsletter verschicken.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top