[Postfixbuch-users] Postfix Tuning - Rückmeldung an P. Heinlein
stepken
stepken at web.de
So Jan 13 18:31:02 CET 2008
André schrieb:
> danke für die schnelle Antwort.
>
> > Oder in welche Richtung denkst du da?
> Ich betreibe mehrere Webserver. Wegen steigender Anzahl der Nutzer, was
> auch sehr erwünscht ist, kommt es schon mal zu Engpässen was Performance
> angeht. Mein Postfix ist momentan so konfiguriert, dass er tatsächlich
> in Echtzeit Daten von MySQL holt. Da will ich dringend was tun.
> Außerdem habe ich schon mal hier in der Liste gelesen, dass Postfix bei
> einer unvernünftigen Konfiguration das System lahmlegen kann, z.B. wegen
> zu vieler Prozesse (Spam).
> Ich habe hier und da Tipps gelesen, aber nicht zusammenhängend. Da ich
> mich mit Postfix-Innenleben nicht auskenne, befürchte ich Fehlkonfiguration.
> Ich dachte, vielleicht gibt es irgendwo bereits eine fertige
> Tipps-Sammlung. Das ist alles.
>
> Schöne Grüße
> André
>
Es passieren immer witzige Dinge. So hat z.B. ein User 20 Accounts bei
Google, die mit Spam überflutet werden und der Mensch hat einfach die
Weiterleitung auf unseren Mailserver aktiviert. Folge: Von Google kamen
so viele Mails / Sekunde, dass Spamassassin völlig überlastet war. Bei
10 Mails / Sekunde kommt er noch klar, aber bei mehr als 15 /Sekunde
stieg die Last des Xeons auf über 30 an. Problem dabei: Ausgehende Mail
blieb liegen, weil auch die über SPAMASSASSIN laufen sollen, jedoch mit
niedrigerer Priorität, als die eingehenden (logisch!). Es sammelten sich
also so innerhalb von wenigen Minuten über 4000 Mails an, und Nagios
Alarm schlug dauernd an. Keine Mail ging mehr heraus, und das über Stunden.
Als Sysadmin steht man dann auf dem Schlauch: Keine der bei
http://www.postfix.org/TUNING_README.html angegebenen Limiter
funktionieren ausreichend, um ein solches Problem zu beheben.
Was ich wollte, was, dass ich ganz selektiv die Google Phalanx von
sendenden Servern herunterbremse, jedoch aus anderen Richtungen des
Internets ganz normal Mail mit normaler Geschwindigkeit annehme.
Ziel war, dass ich die meinen Mailserver überlastenden Server bremse,
aber nur diese. Ich will ein Mittel gegen DoS selektiv aus einer bzw.
mehreren Richtungen gleichzeitig. Wenn also jemand mir 2000000 Mails mit
Attachment je Sekunde schicken will, so soll ausschliesslich dieser
ausgebremst werden, aber nicht die anderen Mailserver.
Und dann war noch ein Problem mit Virtuellem Hosting mit
openvz/virtuozzo: Nicht alle in Linux möglichen Filter stehen darin zur
Verfügung, bzw. die Syntax der Firewallregeln (venet0:1 Interface) kann
man nicht auf Aliase anwenden. Ich habe dann folgendes Skript eingetippt:
#!/bin/bash
iptables -F
iptables -X smtpschutz
iptables -N smtpschutz
iptables -A INPUT -p tcp --dport 80 --syn -j smtpschutz
iptables -A smtpschutz -m limit --limit 10/second --limit-burst 20 -j RETURN
iptables -A smtpschutz -j LOG --log-prefix "IPTABLES: SMTP OVERLOAD "
iptables -A smtpschutz -j DROP
und Ruhe war im Karton. Ich habe dann das Burst - Limit noch ein wenig
feingetunt. Aber so lief das System sauber rund.
In Mode sind ja nun virtuelle Server z.B. bei Strato. Virtuozzo hat ein
gewaltiges Problem. Betreibe ich Apache, MySQL, Postfix ... gemeinsam in
einer VE, so graben sich Server-Dämonen gegenseitig die Performance ab,
insbesondere bei Skripten. Ich kenne keinen Server z.B. mit PHP, der
nicht innerhalb weniger Sekunden mit z.B. dem Benchmark-Toolkit ab oder
ab2 (liegt Apache bei) zu überlasten wäre. Normale PHP Ausgaben werden
normalerweise gecacht, jedoch bei http-post machen die meisten Skripte
einen Datenbank-Lookup. Und dann wird je TCP/IP-Verbindung ein PHP -
Interpreter, eine MySQL Connection .... gestartet. Und dann sind
Ruckzuck alle Resourcen verbraucht, die Kiste steht, bzw. entweder
Apache oder MySQL stürzen in der VE aus unerfindlichen Gründen ab.
Also habe ich den Apache Server gegen Überlastung mit demselben Trick
geschützt:
#!/bin/bash
iptables -F
iptables -X apacheschutz
iptables -N apacheschutz
iptables -A INPUT -p tcp --dport 80 --syn -j apacheschutz
iptables -A apacheschutz -m limit --limit 80/second --limit-burst 200 -j RETURN
iptables -A apacheschutz -j LOG --log-prefix "IPTABLES: HTTP OVERLOAD "
iptables -A apacheschutz -j DROP
Diese beiden Skripte hinterlassen in /var/log/messages leicht
differenzierbare Logeinträge, die man mit awk, sort, uniq, grep einfach
auswerten kann, um z.B. eine TOP-Ten - Liste der Verursachern einer
Überlastung zu eruieren.
Beim Apache Server hatte ich das recht schnell heraus. Ein Kunde hatte
einen virtuellen Server mit PHP4, MySQL und ganz viel Javascript laufen
(Siehe auch AJAX), sodass der Aufruf des Shops gleich 60-70!!!!
PHP-Skripte auf dem Server simultan startete mit dementsprechend vielen
MySQL Instanzen auch. Erinnerte mich an HTTP 1.0. Völlig krank. Auch das
Forum kippte dauernd ab, JAVA 1.5 - Gedöns.
Was habe ich gemacht? Obiges Skript gestartet, geschaut, wieviel der
Server verträgt, und dann die Parameter justiert. Und Ruhe war.
Einziges Problem, was ich dann noch hatte, sind die Alice DSL - Proxies.
Die hämmerten teilweise brutal auf meinen armen Apache mit seinem PHP4 ein.
Also muste ich prüfen, wie das alles hinter den Proxies ausschaut. Die
Anweisung DROP in der Firewall - Regel hat offensichtlich die Proxies
veranlasst, nach kurzer Zeit Seiten aus der Retorte auszuliefern. Nichts
auffälliges im Client. Die Seiten kamen sauber an, obwohl mein Server
die Schotten in Richtung Alice - DSL dicht gemacht hatte. Also kein
Problem.
Dasselbe mit Google. Die Mails von Google kommen noch an, aber schön
langsam, in für meinen Mailserver verdaulichen Raten.
Und wer dann noch mag, kann diese beiden Skripte noch kaskadieren, bzw.
ständig die Gesamtlast des Servers messen, die Dämonen bestimmen, die
sehr hoch belastet sind, und dann dynamisch die Bandbreitenlimiter hoch
und herunter regeln, sodass der Server an keiner Stelle irgendwo
überlastet ist, bzw. überlastbar ist. Aber das Skript behalte ich dann
für mich, es ist auch recht komplex. Schon mit obigen beiden Skripten
lassen sich fast alle DoS und DDoS Angriffe in den Griff bekommen.
Grüsse, Guido Stepken
Doku zu iptables:
http://netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-7.html
This module works like a "hysteresis door", as shown in the graph
below.
||
rate (pkt/s)
^ .---.
| / DoS \
| / \
Edge of DoS -|.....:.........\.......................
= (limit * | /: \
limit-burst) | / : \ .-.
| / : \ / \
| / : \ / \
End of DoS -|/....:..............:.../.......\..../.
= limit | : :`-' `--'
-------------+-----+--------------+------------------> time (s)
LOGIC => Match | Didn't Match | Match
Say we say match one packet per second with a five packet burst, but
packets start coming in at four per second, for three seconds, then
start again in another three seconds.
||
<--Flood 1--> <---Flood 2--->
Total ^ Line __-- YNNN
Packets| Rate __-- YNNN
| mum __-- YNNN
10 | Maxi __-- Y
| __-- Y
| __-- Y
| __-- YNNN
|- YNNN
5 | Y
| Y Key: Y -> Matched Rule
| Y N -> Didn't Match Rule
| Y
|Y
0 +--------------------------------------------------> Time (seconds)
0 1 2 3 4 5 6 7 8 9 10 11 12
You can see that the first five packets are allowed to exceed the
one packet per second, then the limiting kicks in. If there is a
pause, another burst is allowed but not past the maximum rate set by
the rule (1 packet per second after the burst is used).
Mehr Informationen über die Mailingliste Postfixbuch-users