Am Freitag, dem 17. Mai 2002, waren zahlreiche Mailserver im BelWü nur eingeschränkt funktionsfähig. Ein Problem auf TCP-Ebene wurde durch ungünstige Mailserver-Konfiguration verstärkt.

Betroffene Systeme

• Mailserver, insbesondere sendmail mit ungünstiger Konfiguration.

Auswirkung
Bei bestimmten Problemen auf Transportebene und Denial of Service-Angriffen reagieren Mailserver in ungünstiger Konfiguration in einer Weise, die einen Eingriff des Administrators erfordert (eventuell einen Systemneustart).

Beschreibung
Am Freitag, dem 17. Mai 2002, kam es BelWü-weit zu Störungen der Mail-Zustellung. Die Störung war nicht, wie zunächst vermutet, ein gezielter Angriff, denn SMTP-Verbindungen froren lediglich während der Übertragung der Nachricht ein. (Häufig geschah dies an der Stelle nach dem DATA-Kommando, an dem die andere Seite den Empfang der Nachricht bestätigen sollte. Dadurch wurden möglicherweise Nachrichten mehrfach übertragen, da die ersten Versuche keine Erfolgsmeldung der Gegenstelle lieferten.) Diese Störung führte dazu, daß zentrale Mailserver eine ungewöhnlich hohe Zahl von Verbindungen gleichzeitig handhaben mußten und daß auf diesen Systemen in der Folge typischerweise viele Mail-Server-Prozesse parallel liefen. Es ist daher wichtig (auch als Schutz vor gezielten Angriffen), daß die Prozesszahl beschränkt wird.

In sendmail wird in üblichen Konfigurationen versucht, eine System-Überlastung rechtzeitig zu erkennen. Die Erfahrung zeigt, daß Beschränkungen, die über den load average arbeiten, häufig nicht rechtzeitig greifen, und daß dadurch zu viele Server-Prozesse gestartet werden. Bei vielen Systemen führt dies zu einem Speicherengpaß, den der Kernel dadurch behebt, daß irgendwelche Prozesse beendet werden (also nicht unbedingt einer der zahlreichen Mail-Server-Prozesse). Dies führt wiederum dazu, daß das System nach dem Wegfall der Störung u.U. nicht weiterarbeitet wie davor, da essentielle Prozesse (wie z.B. syslogd) fehlen.

Generell sind Denial of Service-Attacken und Mail ein heikles Thema, da SMTP-Server-Implementierungen durch das Protokoll verpflichtet sind, unter Einsatz nicht vernachlässigbarer Ressourcen (insbesondere Zeit, während der Verbindungen gebunden sind) die Zustellung einer Nachricht sicherzustellen.

Feststellen der Verwundbarkeit
Das RUS-CERT führt auf Wunsch Lasttests für Mailserver an der Universität Stuttgart durch. Bitte wenden Sie sich dazu an CERT@Uni-Stuttgart.DE.

Gegenmaßnahmen
Im folgenden wird davon ausgegangen, daß der Mail-Server nicht über inetd gestartet wird, was ab einem gewissen Nachrichtenvolumen grundsätzlich empfehlenswert ist.

• Für sendmail: Setzen Sie den Parameter MaxDaemonChildren auf einen an Ihr System angepaßten Wert. Das System sollte mit einer entsprechenden Anzahl von sendmail-Prozessen problemlos klarkommen. (Für mäßig ausgelastete Mail-Relays ist ein Wert von 50 mehr als hinreichend; bei entsprechender Ausstattung mit Ressourcen wie Hauptspeicher kann auch ein höherer Wert gewählt werden.) In der m4-Konfiguration ist dazu folgende Zeile einzutragen:

  define(`confMAX_DAEMON_CHILDREN', `50')dnl
  

  Durch diese Einstellungen wird verhindert, daß eine Horde von sendmail-Prozessen den Mailserver als ganzes zum Absturz bringt; falls die Störung vorüber ist, wird der Mailserver wieder den normalen Betrieb aufnehmen.

  Ferner sollten die Timeout-Werte auf die in RFC 2821 genannten Minima gesetzt werden. Die Werte sind im einzelnen:

  • Timeout.rcpt=5m
  • Timeout.datainit=2m
  • Timeout.datablock=3m
  • Timeout.datafinal=10m
  • Timeout.command=5m
  • Timeout.quit=5s

  Die zugehörigen m4-Konfigurationseinstellungen sind:

  define(`confTO_RCPT', `5m')dnl
  define(`confTO_DATAINIT', `2m')dnl
  define(`confTO_DATABLOCK', `3m')dnl
  define(`confTO_DATAFINAL', `10m')dnl
  define(`confTO_COMMAND', `5m')dnl
  define(`confTO_QUIT', `5s')dnl
  

  Bei akuten Problemen kann diese noch weiter herabgesetzt werden, allerdings sollte diese Konfiguration nicht permanent betrieben werden, da vermehrt Dubletten auftreten können.

  Gegen gezielte DoS-Angriffe helfen diese Einstellungen natürlich nichts, aber es dauert keine Stunde mehr, bis der Mailserver nach Beendigung des Angriffes wieder verfügbar ist. (Die voreingestellten Timeout-Werte liegen teils bei einer Stunde.)

• Exim hat in der Voreinstellung bereits ein Prozeß-Limit von 20 für eingehende SMTP-Verbindungen gesetzt (Option smtp_accept_max). Die Timeouts sind ebenfalls auf die in RFC 2821 genannten Minimalwerte gesetzt.

  Allerdings ist es bei Exim ausgesprochen schwierig, die Zahl der Prozesse zu limitieren. Falls remote_max_parallel beispielsweise auf den Wert 10 gesetzt ist, können selbst bei dem Wert 20 für smtp_accept_max 200 Prozesse die Zustellung vornehmen, was dann problematisch wird, wenn hauptsächlich der Versand ausgehender Mail gestört ist.

• Bei qmail selbst gibt es keine detaillierten Einstellungsmöglichkeiten, was Prozeßlimits angeht. Durch die zentralisierte Queue-Verwaltung kann man jedoch die benötigten Ressourcen leicht ausrechnen (siehe Dokumentation). Falls qmail-smtpd über ucspi-tcp aufgerufen wird, ist ohne weitere Konfiguration bereits ein Prozeß-Limit von 40 gesetzt. Folgende Timeout-Parameter können jedoch herabgesetzt werden (bei weniger als den angegebenen Werten wird RFC 2821 verletzt):
  • timeoutremote: 600
  • timeoutsmtpd: 600

  qmail versucht bei den oben beschriebenen Transport-Problemen nicht, Nachrichten über einen Backup-MX zuzustellen, was hilfreich sein könnte, falls auf dem Weg zum Backup-MX die Probleme nicht auftreten.

• Postfix setzt von Haus aus ein Limit von 50 Prozessen (über die maxproc-Spalete in master.cf kann dies geändert werden). Die voreingestellten Timeout-Werte entsprechen denen, die in RFC 2821 als Minimum vorgeschrieben sind.

Hinweis
Die in diesem Text enthaltene Information wurde für die Mitglieder der Universität Stuttgart recherchiert und zusammengestellt. Die Universität Stuttgart übernimmt keinerlei Haftung für die Inhalte. Dieser Artikel darf ausschließlich in unveränderter Form und nur zusammen mit diesem Hinweis sowie dem folgenden Copyrightverweis veröffentlicht werden. Eine Veröffentlichung unter diesen Bedingungen an anderer Stelle ist ausdrücklich gestattet.

Copyright © 2022 RUS-CERT, Universität Stuttgart, https://cert.uni-stuttgart.de/