[postfix-users] Schutz vor Mailflood
Hallo,
seit einiger Zeit lese ich hier nun mit und habe einige interessante Tipps umsetzen können. Mein Mailserver (postfix, amavis, dovecot) funktioniert soweit einwandfrei und ist gegen Spam und OpenRelay-Angriffe gewappnet. Eine Frage stellt sich mir als unerfahrener Postmaster: Wie kann ich meinen Server effektiv gegen Mailflood schützen? Im konkreten geht es hierbei um reguläre E-Mails, die durch die Filter hindurch kommen. Ich habe mir ein kleines böses PHP-Script gebaut, womit ich eine vorgebbare Anzahl an E-Mails mit festlegbaren Delay an eine Adresse senden kann. Jetzt könnte man doch sicherlich die eintreffenden E-Mails hashen und den Hash temporär abspeichern (Datenbank). Treffen dann neue E-Mails ein werden die Hashes verglichen und die überflüssigen Mails gelöscht. Soweit die Idee dazu. Ändert sich der Betreff oder die Nachricht (wenn auch nur geringfügig) wäre die Idee wieder hinfällig. Eine Alternative wäre doch ein Limit von bspw. 5 Mails pro 2 Sekunden pro E-Mailadresse zu setzen. Dann besteht aber die Gefahr, dass man erwünschte E-Mails ignoriert, wenn von anderer Stelle gerade eine Mailflut eintrifft.
Mal ganz davon abgesehen, ob oder wie die Ideen realisierbar wären: Gibt es einen sinnvollen Schutzmechanismus? Ist dies überhaupt üblich? Ziel ist es, sich vor aberwitzigen Scriptkiddies zu schützen, die eben besagte PHP-Scripte bauen, verwenden. Ich möchte nicht eines Tages aufwachen und 10000 Mails in meiner Inbox finden.
Mit freundlichen Grüßen Julian
* Julian Krämer email@juliankraemer.de:
Gibt es einen sinnvollen Schutzmechanismus? Ist dies überhaupt üblich? Ziel ist es, sich vor aberwitzigen Scriptkiddies zu schützen, die eben besagte PHP-Scripte bauen, verwenden. Ich möchte nicht eines Tages aufwachen und 10000 Mails in meiner Inbox finden.
10000 Mails über eine Dialup-Verbindung an einen einzelnen Empfänger loszuwerden ist gar nicht so einfach. Und wenn es keine Einwahlverbindung sondern ein fester Server ist, weiß man ja, was man danach erden kann.
Stefan
Zitat von Julian Krämer email@juliankraemer.de:
Hallo,
seit einiger Zeit lese ich hier nun mit und habe einige interessante Tipps umsetzen können. Mein Mailserver (postfix, amavis, dovecot) funktioniert soweit einwandfrei und ist gegen Spam und OpenRelay-Angriffe gewappnet. Eine Frage stellt sich mir als unerfahrener Postmaster: Wie kann ich meinen Server effektiv gegen Mailflood schützen? Im konkreten geht es hierbei um reguläre E-Mails, die durch die Filter hindurch kommen. Ich habe mir ein kleines böses PHP-Script gebaut, womit ich eine vorgebbare Anzahl an E-Mails mit festlegbaren Delay an eine Adresse senden kann. Jetzt könnte man doch sicherlich die eintreffenden E-Mails hashen und den Hash temporär abspeichern (Datenbank). Treffen dann neue E-Mails ein werden die Hashes verglichen und die überflüssigen Mails gelöscht. Soweit die Idee dazu. Ändert sich der Betreff oder die Nachricht (wenn auch nur geringfügig) wäre die Idee wieder hinfällig. Eine Alternative wäre doch ein Limit von bspw. 5 Mails pro 2 Sekunden pro E-Mailadresse zu setzen. Dann besteht aber die Gefahr, dass man erwünschte E-Mails ignoriert, wenn von anderer Stelle gerade eine Mailflut eintrifft.
Mal ganz davon abgesehen, ob oder wie die Ideen realisierbar wären: Gibt es einen sinnvollen Schutzmechanismus? Ist dies überhaupt üblich? Ziel ist es, sich vor aberwitzigen Scriptkiddies zu schützen, die eben besagte PHP-Scripte bauen, verwenden. Ich möchte nicht eines Tages aufwachen und 10000 Mails in meiner Inbox finden.
Das einzige was üblicherweise angewendet wird sind Quotas pro Mailbox. Alles andere ist sowieso nur begrenzt sinnvoll, da es genügend Mittel und Wege gibt die Mailbox zu füllen sei es mit verteilten Absende-Systemen oder Rate-Limited um Abwehrlimits zu umgehen. Lange Rede kurzer Sinn : Üblicherweise ist davon auszugehen das der "Angriff" zuviele Resourcen bindet und zuwenig Schaden anrichten kann. Es gibt deutlich effizientere DoS Attacken, da braucht man sich um eine gefüllte Mailbox keine allzu großen Sorgen machen.
Gruß
Andreas
Am 17.02.2010 um 23:15 schrieb lst_hoe02@kwsoft.de:
Zitat von Julian Krämer email@juliankraemer.de:
Hallo,
seit einiger Zeit lese ich hier nun mit und habe einige interessante Tipps umsetzen können. Mein Mailserver (postfix, amavis, dovecot) funktioniert soweit einwandfrei und ist gegen Spam und OpenRelay-Angriffe gewappnet. Eine Frage stellt sich mir als unerfahrener Postmaster: Wie kann ich meinen Server effektiv gegen Mailflood schützen? Im k onkreten geht es hierbei um reguläre E-Mails, die durch die Filter hindurch komm en. Ich habe mir ein kleines böses PHP-Script gebaut, womit ich eine v orgebbare Anzahl an E-Mails mit festlegbaren Delay an eine Adresse senden kann. Jetzt könnte man doch sicherlich die eintreffenden E-Mails hashen und den Hash temporär abspeichern (Datenbank). Treffen dann neue E-Mails ein we rden die Hashes verglichen und die überflüssigen Mails gelöscht. Soweit die Idee dazu. Ändert sich der Betreff oder die Nachricht (wenn auch nur geringfü gig) wäre die Idee wieder hinfällig. Eine Alternative wäre doch ein Limit von bspw. 5 Mails pro 2 Sekun den pro E-Mailadresse zu setzen. Dann besteht aber die Gefahr, dass man er wünschte E-Mails ignoriert, wenn von anderer Stelle gerade eine Mailflut eintrifft.
Mal ganz davon abgesehen, ob oder wie die Ideen realisierbar wären: Gibt es einen sinnvollen Schutzmechanismus? Ist dies überhaupt übl ich? Ziel ist es, sich vor aberwitzigen Scriptkiddies zu schützen, die eben besagte PHP-Scripte bauen, verwenden. Ich möchte nicht eines Tages aufwach en und 10000 Mails in meiner Inbox finden.
Das einzige was üblicherweise angewendet wird sind Quotas pro Mailbo x. Alles andere ist sowieso nur begrenzt sinnvoll, da es genügend Mi ttel und Wege gibt die Mailbox zu füllen sei es mit verteilten Absen de-Systemen oder Rate-Limited um Abwehrlimits zu umgehen. Lange Rede kurzer Sinn : Üblicherweise ist davon auszugehen das der "Angriff" zuviele Resourcen bindet und zuwenig Schaden anrichten kann. Es gibt deutlich effizientere DoS Attacken, da braucht man sich um eine gef üllte Mailbox keine allzu großen Sorgen machen.
Gruß
Andreas
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Hallo allerseits,
bis hierhin schon einmal besten Dank! Irgendwie hatte ich vermutet, dass man sich im Vorfeld gegen diese Art von Angriffen nur bedingt sinnvoll schützen kann. In der Manual bin ich auf den Parameter smtpd_client_connection_rate_limit gestoßen. In Verbindung mit Festlegung einer Zeitspanne (anvil_rate_time_unit) kann man damit vorgeben, wieviele Verbindungen innerhalb dieser Zeitspanne von einem Client aufgebaut werden dürfen. Das kommt doch meiner Absicht entgegen, denn wenn ich das Limit auf bspw. 2 Verbindungen pro Sekunde setze, ist eine Flood-Attacke in der Menge limitiert. Alternative könnte man die Nachrichten pro Zeiteinheit mit smtpd_client_message_rate_limit einstellen. Macht das Sinn? Gibt es Erfahrungswerte, die man dort einstellen kann?
Vielleicht noch ein paar Randnotizen: Es handelt sich um einen privaten Mailserver, der den Kopf für einige kleiner Projekte hinhalten muss. Mit den bereits erwähnten Script-Kiddie angriffen kann gerechnet werden, weshalb ich hier nach einer Lösung suche. Einen Schutz vor DoS- oder DDoS-Attacken ist erstmal nicht von Interesse, zumal es wohl keinen effektiven gibt.
Ein weiterer Schutz würde smtpd_recipient_limit bieten, womit ich festlege, wieviele Empfänger für eine Nachricht erlaubt sind. Verstehe ich es richtig, dass damit die maximale Anzahl an CCs bzw. BCCs gemeint ist?
Angenommen ich hätte mich mit den Werten verspekuliert und es kämen erwünschte E-Mails nicht mehr durch. Bekommt der Versender ein Feedback, wenn einer der drei erwähnten Limits greift?
Grüße Julian
On Behalf Of Julian Krämer
bis hierhin schon einmal besten Dank! Irgendwie hatte ich vermutet, dass man sich im Vorfeld gegen diese Art von Angriffen nur bedingt sinnvoll schützen kann. In der Manual bin ich auf den Parameter smtpd_client_connection_rate_limit gestoßen. In Verbindung mit Festlegung einer Zeitspanne (anvil_rate_time_unit) kann man damit vorgeben, wieviele Verbindungen innerhalb dieser Zeitspanne von einem Client aufgebaut werden dürfen. Das kommt doch meiner Absicht entgegen, denn wenn ich das Limit auf bspw. 2 Verbindungen pro Sekunde setze, ist eine Flood-Attacke in der Menge limitiert. Alternative könnte man die Nachrichten pro Zeiteinheit mit smtpd_client_message_rate_limit einstellen. Macht das Sinn? Gibt es Erfahrungswerte, die man dort einstellen kann?
Und bei 2 pro Sekunde verhinderst du doch nichts Wer alle sec eine Mail schickt kann dich auch fluten. Prüfe wie viele Einlieferungen pro Client du in der Minute bekommst. Setze einen sinnvollen Wert mit ein bisschen Puffer nach oben und beobachte ob gewünschte Mailserver an diese Grenzen kommen.
Vielleicht noch ein paar Randnotizen: Es handelt sich um einen privaten Mailserver, der den Kopf für einige kleiner Projekte hinhalten muss. Mit den bereits erwähnten Script-Kiddie angriffen kann gerechnet werden, weshalb ich hier nach einer Lösung suche. Einen Schutz vor DoS- oder DDoS-Attacken ist erstmal nicht von Interesse, zumal es wohl keinen effektiven gibt.
Solltest du wirklich mal geflutet werden kannst du evtl. mit fail2ban noch etwas machen indem du die Server die sich nicht an die Limits halten für einen Zeitraum X von der Auslieferung ausschließt.
Das ist effektiv.
Ein weiterer Schutz würde smtpd_recipient_limit bieten, womit ich festlege, wieviele Empfänger für eine Nachricht erlaubt sind. Verstehe ich es richtig, dass damit die maximale Anzahl an CCs bzw. BCCs gemeint ist?
Angenommen ich hätte mich mit den Werten verspekuliert und es kämen erwünschte E-Mails nicht mehr durch. Bekommt der Versender ein Feedback, wenn einer der drei erwähnten Limits greift?
Nö, richtige Mailserver versuchen es später noch mal. Alles andere würde ja keinen Sinn machen da auch mal ein Mailserver unter last für bestimmte Zeit nichts annehmen kann.
Soviel kannst du dich auf einem privaten gar nicht verspekulieren
Mit freundlichen Grüßen
Drießen
participants (5)
-
Alexander Frimmel -
Julian Krämer -
lst_hoe02＠kwsoft.de -
Stefan Foerster -
Uwe Driessen