Ich habe anhaltende Angriffe auf meinen Exim-Server. Ich versuche, die Versuche mit der folgenden ACL zu verzögern
deny condition = ${if and {\
{>{$rcpt_count}{10}}\
{<{$recipients_count}{${eval:$rcpt_count/2}}} }}
delay = 5s
message = Rejected for too many bad recipients
logwrite = REJECT [$sender_host_address]: bad recipient count high [${eval:$rcpt_count-$recipients_count}]
.endif
Das verzögert einmalig nach den ersten 10 Versuchen.
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:39 REJECT [212.164.218.15]: bad recipient count high [11]
2023-09-10 12:14:39 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Rejected for too many bad recipients
2023-09-10 12:14:39 REJECT [212.164.218.15]: bad recipient count high [12]
2023-09-10 12:14:39 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Rejected for too many bad recipients
Ich möchte stattdessen, dass jeder weitere Versuch verzögert wird. Wie kann ich das erreichen?
Antwort1
Ich bin auf dasselbe Problem/die gleiche Frage gestoßen und habe einige Nachforschungen und Tests angestellt.
Als erstes müssen Sie wissen, dass SMTP ursprünglich streng auf Befehl-Antwort basierte, was bedeutet, dass der Client genau einen Befehl an den Server senden kann und auf die Antwort warten muss, bevor er den nächsten senden kann. Da dieses Hin und Her jedes Mal eine ganze Weile mit Warten verbunden ist und somit Latenz erzeugt,RFC 2920später wurde "SMTP Pipelining" eingeführt. Damit kann ein Client mehrere Befehle in einem Batch an den Server senden, der sie verarbeitet und die Antworten zurücksendet. In Exim kann die Verfügbarkeit von "SMTP Pipelining" durch die pipelining_advertise_hostsOption gesteuert werden, die es standardmäßig für alle zulässt. Ich gehe davon aus, dass dies auch für Ihre Konfiguration der Fall ist.
Ich denke, in Ihrem Fall ist Folgendes passiert: Der Client (auch bekannt als Spammer), der sich mit Ihrem Exim-Server verbunden hat, erhielt die Information, dass er „SMTP Pipelining“ unterstützt, und schickte daraufhin einen Stapel von 100 RCPT TO:Befehlen. Ihr Server hat sie empfangen und mit der Verarbeitung begonnen, wobei er die acl_smtp_rcptACL für jeden Empfänger durchlief. Die ersten 10 Befehle gaben jeweils eine 550 Unrouteable addressAntwort zurück, wobei es 550sich um eineRFC5321-FehlercodeBedeutung, Requested action not takengefolgt von einem für Menschen lesbaren Grund. Dieser Grund kann in Exim mit der messageDirektive festgelegt werden und wird auch im Protokoll nach dem Doppelpunkt gedruckt. Der Client hat sie wahrscheinlich einfach ignoriert; er sucht schließlich nach gültigen Empfängern.
Bei der Verarbeitung des 11. Befehls/Empfängers wird die Bedingung Ihrer denyRegel als wahr ausgewertet und Exim verzögert (schläft) 5 Sekunden; dies ist die einzige Verzögerung, die Sie sehen. Danach sendet es die 550 Rejected for too many bad recipientsAntwort an den Client. Aufgrund des enthaltenen (bekannten) Grundes erkennt der Client, dass er die Grenze überschritten hat und es keine Chance mehr gibt, einen gültigen Empfänger zu finden; alle folgenden Befehle werden ebenfalls abgelehnt. Da es nichts mehr zu erwarten/gewinnen gibt, beendet er die Verbindung, ohne auf den Rest der Antworten zu warten (und wendet sich wahrscheinlich sofort seinem nächsten Opfer zu). Obwohl Ihr Server dies bemerkt (weil TCP verwendet wird), verarbeitet er den Befehlsstapel trotzdem weiter. Da die SMTP-Verbindung zum Client jedoch bereits beendet ist, hat eine weitere Verzögerung keinen Sinn; der einzige, den es verzögern würde, wäre sich selbst. Daher wird die Verzögerung ignoriert und Ihr Server führt die Befehle aus, bis der gesamte Stapel fertig ist.
Würde der Client die Verbindung nicht beenden, würde alles wie erwartet funktionieren: Die Verzögerung von 5 Sekunden würde für jeden Empfänger nach dem 10. angewendet.
Vorausgesetzt, das obige ist richtig, ist die beste Lösung, die mir einfällt, den Standardgrund/die Standardnachricht zu entfernen. Wenn der Server einfach weiterhin mit etwas wie antwortet 550 Unrouteable address, kann der Client nicht erkennen, dass er zu weit gegangen ist, und kann nicht aussteigen. Je nachdem, wie der Client arbeitet, kann es ausreichen, es in etwas anderes als den Standard zu ändern/umzuformulieren, damit es nicht speziell behandelt wird.
Alternativ können Sie „SMTP Pipelining“ in Ihrem Server mit der oben genannten Option deaktivieren. Der Client wird wahrscheinlich trotzdem abbrechen, nachdem er die 11. Antwort mit dem verräterischen Grund gesehen hat, und Ihr Server verzögert trotzdem nur einmal, aber zumindest werden die anderen 89 fehlgeschlagenen Empfänger nicht in Ihrem Protokoll angezeigt. Der offensichtliche Nachteil ist, dass Sie jeden Client „verlangsamen“, aber dies kann etwas erhöht werden, indem Sie „SMTP Pipelining“ nur für ausgewählte „bekanntermaßen gute“ Clients aktivieren.
Und nur als Randbemerkung: Die Verzögerung muss kein statischer Wert sein, sie kann auch ein Ausdruck sein. Dadurch ist es möglich, progressive Verzögerungen zu implementieren, bei denen jeder zusätzliche ungültige Empfänger sie verlängert. Die ausgezeichneteSpamfilter für Mail ExchangerHowTo hat hierfür ein Beispiel.