[Postfixbuch-users] Fragen zu laufender Spam-Attacke

[Stefan Förster]

Hallo Andreas,

wie ich vermutet hatte: Ein telnet auf Deine Kiste zeigt, daß Postfix
keine freien smtpd-Dämonen kriegt. Ergo musst Du viel mehr Mail viel
schneller ablehnen. Aber eins nach dem anderen.

Das große Problem bei Dir ist, daß Du uns keine Logzeilen präsentierst
und auch sonst nicht wirklich nachzufroschen scheinst, wie das Problem
zu Stande kommt.

Du scheinst z.B. nur zwei amavisd-new-Prozesse zu betreiben, schreibst
aber weiter oben, daß die CPU meist idle ist - liegt es dann am RAM?
Wenn nein, hast Du versucht, mehr amavisd-new-Prozesse zu starten und
die Zahl in der Definition von "amavis" in der master.cf daran
anzupassen? Ich denke, daß würde am allerschnellsten helfen!

Ansonsten gehe ich mal davon aus, daß die Ressourcen Deines Systems
erschöpft sind:

* "Andreas v. Heydwolff" <listmail at sandpsych.at> wrote:
> Stefan Förster wrote:
> Unter http://andreas.heydwolff.de/public_html/postfix
> sind der output von postconf -n, die master.cf und meine

Eigentlich macht Uwe sowas immer, aber ich fange gleich mal mit dem
wichtigsten an:

smtpd_recipient_restrictions =
   reject_non_fqdn_sender
   reject_non_fqdn_recipient
   reject_unknown_sender_domain
   reject_unknown_recipient_domain
   permit_mynetworks,
   permit_sasl_authenticated
   reject_unauth_destination
   reject_unlisted_recipient
   reject_rbl_client zen.spamhaus.org=127.0.0.10
   reject_rbl_client zen.spamhaus.org=127.0.0.11
   reject_rbl_client zen.spamhaus.org=
   rbl_reply_maps = hash:/etc/postfix/rbl_reply_maps <- Paste-Fehler bei mir?!?
   reject_rbl_client dnsbl.njabl.org
   reject_invalid_hostname

Wenn wir das jetzt umstellen ohne es zu erweitern erhalten wir (ungetestet):

smtpd_recipient_restrictions =
   reject_invalid_helo_hostname     # reject_invalid_hostname ist etwas älter
   reject_non_fqdn_sender
   reject_non_fqdn_recipient
   reject_unlisted_sender
   reject_unlisted_recipient
   reject_unknown_sender_domain     # das kommt hier so früh, weil das auch unsere eigenen SASL-Nutzer betrifft
   reject_unknown_recipient_domain  # und das ebenso
   permit_sasl_authenticated
   permit_mynetworks
   reject_unauth_destination
   reject_rbl_client zen.spamhaus.org
   reject_rbl_client dnsbl.njabl.org

(immer schön auf die Spaces achten, wenn Du eine Zeile forsetzen
willst)
Jetzt brauchst Du aber noch eine "Keule", um noch mehr Mails zu
filtern - dazu verwenden wir den Stress-Modus:

smtpd_client_restrictions = ${stress?reject_unknown_client_hostname}
smtpd_delay_reject = ${stress?no}${stress:yes}
smtpd_hard_error_limit = ${stress?1}${stress:20} # <--- das hier ist ziemlich, äh, "zerstörerisch"
smtpd_timeout = ${stress?10}${stress:300}
unknown_client_reject_code = ${stress?421}${stress:450}
smtpd_client_connection_count_limit = ${stress?2}${stress:10} # davon ausgehend, daß Du 20 smtpds startest
unknown_address_reject_code = ${stress?421}${stress:554}

(Nicht vergessen, "-o smtpd_client_connection_count_limit=10 " aus der
master.cf rauszunehmen!)

Mehr geht erstmal nicht - es sein denn, Du lässt Dich auf Greylisting
ein:

aptitude install postgrey postfix-pcre

In die main.cf einzufügen:

smtpd_restriction_classes = greylisting
greylisting = check_policy_service inet:127.0.0.1:60000

Dann noch Datei http://www.incertum.net/~cite/postgrey.pcre nach
/etc/postfix herunterladen, z.B. mit

wget -O /etc/postfix/postgrey.pcre http://www.incertum.net/~cite/postgrey.pcre

und vor die erste "reject_rbl_client" einfügen:

  check_client_access pcre:${maps_dir}/postgrey.pcre

(immer schön auf die Spaces achten, wenn Du eine Zeile forsetzen
willst). Nach einem "postfix reload" lehnst Du jetzt meines Erachtens
nach so viele Mails ab, wie Du ohne weitere Umstellungen zu leisten in
der Lage bist. Du kannst noch "policyd-weight" installieren und direkt
unter die letzte Zeile, die ich schreib, noch einen AUfruf von
"check_policy_service inet:127.0.0.1:12525" einfügen, kannst dann aber
meines Erachtens nach die beiden "reject_rbl_client"-Zeilen
auskommentieren.

> virtual Tabelle einzusehen (da gibt es noch ein anderes Problem,
> "warning: do not list domain sandpsych.at in BOTH mydestination and
> virtual_alias_domains").

Ich hab's jetzt nicht getestet, aber eigentlich sollte es reichen,
die Zeile

sandpsych.at            anything

aus der virtual-Datei zu entfernen. Umschreiben geht mit
virtual_alias_maps immer, sofern die Domain einer anderen Adressklasse
angehört.

> $final_virus_destiny      = D_DISCARD;  # (data not lost, see virus
> quarantine)
> $final_banned_destiny     = D_BOUNCE;   # D_REJECT when front-end MTA
> ## $final_spam_destiny       = D_BOUNCE;
> $final_spam_destiny       = D_PASS;
> $final_bad_header_destiny = D_PASS;     # False-positive prone (for spam)

Wenn Du als smtpd_proxy_filter arbeitest, darfst Du
$final_spam_destiny ruhig auf D_REJECT setzen.

>> Du benötigst einen smtpd, der aus dem LAN heraus funktioniert?
>> Definiere einen in der master.cf und setze dort ein niedriges
>> Prozesslimit, da man im Normalfall aus dem LAN heraus ja nicht soviele
>> Mails wie von außen schicken wird.
> 
> Sollte ich noch einen als 10.0.1.10:10027 definieren, z.B.?

Ja, natürlich - und diesen dann in der mm_cfg.py mit "SMTPPORT =
10027" ansprechen.



Ciao
Stefan
-- 
Stefan Förster     http://www.incertum.net/     Public Key: 0xBBE2A9E9
FdI #247: Trace - Billiger Fortsetzungsroman. (Manfred Worm Schäfer)
Stefan Förster     http://www.incertum.net/     Public Key: 0xBBE2A9E9
25 Zeichen, daß Du erwachsen bist, Nummer fünf:
Du hörst Dein Lieblingslied in einem Aufzug.