Hack über SMTP?

[velo]

Eigentlich ist es einem Freund passiert, dessen rootserver wurde, so glaubt er, über SMTP gehackt, wobei auch noch aus einer chroot jail ausgebrochen wurde.

Das macht mir nun auch Angst. So frage ich euch, ob ihr ein tool etc kennt, um SMTP zu schützen?

Generell könnte ich mir vorstellen, dass es so was wie einen "Saubermacher" der Anfragen geben könnte. Also etwas, das zb im xinetd liegt und die Mailzustellungen von unkonformen Inhalten säubert. Snort kann das vielleicht (?), aber das soll recht auslastend sein.

[Joe User]

So frage ich euch, ob ihr ein tool etc kennt, um SMTP zu schützen?

Ja: Brain und Paketmanager/Compiler...

[Roger Wilco]

SMTP ist ein Protokoll. Man kann nur einen MTA kompromittieren, der SMTP spricht.
Davon abgesehen sollten MTAs so implementiert sein, dass sie nicht durch ungültige (oder vielleicht zu lange -> Buffer Overflow) Eingaben aus dem Tritt gebracht werden können.

[velo]

Ja: Brain und Paketmanager/Compiler...

Oh ich bin wieder unter Insidern. Wenn man etwas im Ubuntu-Forum war, kann einem so eine kalte Dusche "Freundlichkeit" vielleicht gut tun.

Danke, aber dein Beitrag brachte leider keinen Erfolg. Habe ich brain mehrmails neukompiliert und installiert.

Was SMTP ist, ist klar. Aber was gemeint war ist ja angekommen. Mir ist klar, was ein MTA so alles von sich aus können müßte. Aber wenn alle Programme immer alles so super machen würden und so fehlerlos währen, gäbe es ja kaum Sicherheitstools wie snort. Deswegen frage ich ja, ob es ein tool gibt, das man davor schalten kann und dass sich nur um die Sicherheit bei emails kümmert, bzw was man sonst so empfehlen kann.

[Joe User]

Wenn wir Dir helfen sollen -> Read my sig!

Pauschallösungen gibt es nicht...

[flo]

Du möchtest SMTP absichern - das ist ja an und für sich ganz löblich, sagst aber weder dazu, welche Software Du laufen lassen möchtest noch welche Dir lieb wäre. Klar ist für Dich anscheinend nur, daß Snort sicher sein könnte!?

Du solltest erst einmal davon ausgehen, was Deine Kiste nach dem sicher-machen noch können sollte - es gibt auf dem Markt hunderte von Mailprogrammen, die teilweise unterschiedlichste "Dialekte" sprechen und in Ihrem SMTP massig Eigenheiten haben, so daß ich eine Filterung des - ziemlich wichtigen - Port 25 durch ein Programm für bl...sinnig halte. (Den Verwendungszweck "Rootserver" angenommen - hast Du ein Rechenzentrum mit schöner Application-Level-Firewall gilt das natürlich nicht.) Die immensen Logfiles, die ein default- oder unkonfigurierter Snort Dir produzieren würde, liest Du wahrscheinlich eh nicht, also kannst Du Dir den gleich sparen und bei Deinem Sicherheitskonzept die Schwächen (?) Deines MTA ausbügeln bzw. auf neue Lücken ASAP reagieren.

Nimm den MTA Deiner Wahl, frage die "üblichen Verdächtigen" schon im HELO ab nutze, RBLs und danach kommen Virenscanner und Spamfilter dran. Danach datest Du Dein System noch schön up und hältst das auch so, während Du nebenbei noch einschlägige Fachliteratur zum Thema IT-Sicherheit liest - mindestens natürlich die ComputerBild. :evil:

flo.

[lord_pinhead]

während Du nebenbei noch einschlägige Fachliteratur zum Thema IT-Sicherheit liest - mindestens natürlich die ComputerBild. :evil:
flo.

Fachliteratur ComputerBild? Ich dachte da kommt jetzt sowas wie Linux Magazin, iX oder C´t
;)
@velo
Was nutzte den dein Freund für eine Software? Und vor allem, wie kommt er drauf das seine Kiste über den MTA gerootet wurde, ich denke nicht das wenn da jemand erfolgreich war, das dein Freund noch irgendwelche Logs hätte darüber. Rätselraten is vielleicht lustig auf nen Kindergeburtstag, aber auch nur dort ;)

[velo]

Postfix denke ich. Aber ich will ja keine Lösung zu der Software, sondern Gedanken, wie man so was generell verhindern kann. Ausser die Software aktuell zu halten bzw zu konfigurieren.

[duergner]

Per Firewall den Port 25 blocken. :twisted:

Ein paar sinnvolle Tipps hast du oben schon bekommen, und wenn der Server nicht gerade ausschließlich als Mailserver agiert, würde ich sagen, is die Wahrscheinlichkeit, dass jemand das System über den MTA kompromitiert sehr gering wenn das System sauber konfiguriert und up-to-date ist.

[Roger Wilco]

Postfix denke ich. Aber ich will ja keine Lösung zu der Software, sondern Gedanken, wie man so was generell verhindern kann. Ausser die Software aktuell zu halten bzw zu konfigurieren.

Lass den MTA in einem eigenen Kontext laufen. Virtualisierungslösungen gibt es für Linux mittlerweile wie Sand am Meer...

Generelle Gedanken, wie man so etwas verhindern kann: Software einsetzen, die von sicherheitsbewussten Leute programmiert wurde.

[nyxus]

Postfix denke ich.

Lass den MTA in einem eigenen Kontext laufen. Virtualisierungslösungen gibt es für Linux mittlerweile wie Sand am Meer...

Im aktuellen Linux-Magazin übrigens ein Hauptthema. Ã?ber sowas denke ich auch schon länger nach, jedem Dienst sein "eigener" Server-Kontext. Bisher war mir das aber noch zu aufwendig. Aber zu Hause mache ich das unter VMWare auch schon.

Generelle Gedanken, wie man so etwas verhindern kann: Software einsetzen, die von sicherheitsbewussten Leute programmiert wurde.

Würde ich Postfix jetzt mal tendentiell für halten ...

[flo]

Würde ich Postfix jetzt mal tendentiell für halten ...

Ich kann mich auch beim besten Willen an keinen Exploit von Postfix erinnern - fetchmail, amavis und alle anderen kleinen Dinge des leichten Lebens dann umso mehr - liegt wohl daran, daß der MTA in erster Linie dafür da ist, Mails nicht zu bearbeiten, sondern an andere Programme weiterzureichen.

flo.

[lord_pinhead]

Postfix ist auch so aufgeteilt in die verschiedenen Deamons, da wird es schon alleine deswegen schwer einen funktionierenden Exploit dafür zu schreiben. Sendmail war da ja schon ganz anders :)

@Nyxus
Das Heft hab ich mir gestern deswegen mal geholt, bin nur noch nicht dazu gekommen den Bericht zu lesen.

@Velo
Postfix hört sich doch ganz gut an, wenn du den Rest des Systems anständig Up-to-date ist und richtig konfiguriert ist das so gut wie unmöglich den MTA zu übernehmen, vor allem Postfix. Er sollte lieber an einer anderen Stelle bei seiner Forensik suchen.