#!/bin/blog

May 16, 2009

Debian VMware woes

Filed under: UNIX & Linux — Tags: , , , , — martin @ 8:28 am

Had some trouble with Debian in VMware Server 2.0: I/O was horribly slow, 100% IOwait when doing the simplest things, hdparm showing 11MB/s throughput.

This was fixed by shutting down the VM, changing the SCSI adapter from Buslogic to LSI logic and booting up again. hdparm is at 63MB/s now. The machine, which will be an SMTP mail exchanger, now scans 8 mails per second (Postfix before-queue filter via amavisd-new+ClamAV) in 10 concurrent sessions. Not bad at all.

Debian is by far the simplest choice for an SMTP content filter because it’s not neccessary to bring in any dependencies by hand. Cool. ­čÖé

Advertisements

January 25, 2008

Postfix 2.5.0

Filed under: Security — Tags: , , , — martin @ 7:22 am

Seit heute ist die Version 2.5.0 des Postfix-MTA verf├╝gbar. Das Feature, das mich am meisten interessiert, ist die M├Âglichkeit der Validierung von Serverzertifikaten anhand des Fingerprint.

Aus dem Changelog:

TLS (SSL) support was streamlined further, and provides a new
security level based on certificate fingerprints instead of CA
signatures.

Wo man vorher bei der Mailauslieferung ├╝ber Eintr├Ąge in tls_policy_maps gepr├╝ft hat, ob das gegnerische Zertifikat von einer bekannten CA signiert ist und auf einen Common Name aus einer bestimmten Domain ausgestellt ist:

example.com secure match=example.net

kann man nun auch selbstsignierte Zertifikate verwenden (oder Zertifikate, die von einer CA ausgestellt sind, mit deren Zertifizierungspolicy man nicht einverstanden ist) und den Fingerprint pr├╝fen:

example.com fingerprint
  match=3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1

Alle anderen Attribute des Zertifikats (insbesondere das Ablaufdatum) werden damit ignoriert.

Aus der Doku:

If certificate fingerprints are exchanged securely, this is the strongest, and least scalable security level. […] This may be feasible for an SMTP “VPN” connecting a small number of branch offices over the Internet, or for secure connections to a central mail hub. It works poorly if the remote SMTP server is managed by a third party, and its public certificate changes periodically without prior coordination with the verifying site.

Ich finde es wirklich ulkig, da├č hier von einem SMTP-VPN die Rede ist. Genau diesen treffenden Vergleich hat n├Ąmlich auch mal ein Kunde konstruiert, der im gro├čen Ma├čstab Secure Channel TLS einsetzt, um den Internet-Mailtraffic mit seinen Partnern abzusichern.

F├╝r die Verwendung im “Enterprise-Bereich” sollte die Pr├╝fung von Fingerprints aber in der Tat trotz des objektiv zu gewinnenden Sicherheitsvorteils genau auf den Pr├╝fstand gestellt werden. Schlampig arbeitende Gegenstellen mit Snake-Oil-Zertifikaten werden damit n├Ąmlich m├Âglicherweise erst recht zu weiterhin schlampiger Arbeit angehalten.

August 8, 2007

Applikations-VPN

Filed under: Security — Tags: , , , — martin @ 9:31 am

Aus einem Protokoll beim Kunden:

Der Mailverkehr zur Gegenstelle X wird mit Transport Layer Security (“Applikations-VPN”) verschl├╝sselt.

Ich bin hin- und hergerissen, ob ich diese vollkommen ungenaue Analogie einfach nur haarstr├Ąubend, oder einfach nur genial finden soll, aber tendiere zu letzterem.

March 10, 2007

Postfix 2.3: Abgehend Server-Zertifikate pr├╝fen

Filed under: Internet — Tags: , , , , — martin @ 10:59 pm

Ausgangslage: Ein Internet-Mailgateway unter Postfix 2.3 soll ganz normal Mail an beliebige Gegenstellen im Internet ausliefern. F├╝r bestimmte Zieldomains soll sichergestellt werden, da├č Mails dorthin ausschlie├člich TLS-verschl├╝sselt ├╝bertragen werden.

Hier die Basiskonfiguration f├╝r TLS, ein Auszug aus der main.cf:
# TLS grunds├Ątzlich deaktivieren, Aktivierung erfolgt dann fallweise.
smtp_tls_security_level = none
# Auch wenn wir selbst kein TLS machen, wollen wir loggen, wenn
# Gegenstellen TLS anbieten.
smtp_tls_note_starttls_offer = yes
# Apropos Log; standardm├Ą├čig loggt Postfix ├╝berhaupt keine Infos zu
# TLS-Transaktionen.
smtp_tls_loglevel = 1
# In dieser Map tragen wir die Gegenstellen ein, mit denen wir nur per
# TLS kommunizieren wollen.
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
# Und in diesem Verzeichnis sind die Zertifikate enthalten, von denen
# die Zertifikate der Gegenstellen signiert sein m├╝ssen, um als akzeptabel
# zu gelten.
smtp_tls_CApath = /etc/postfix/tls/cacerts.d

Zu beachten ist, da├č die im smtp_tls_CApath hinterlegten Zertifikate vor Verwendung gehasht werden m├╝ssen. Daf├╝r wird das Perl-Script c_rehash aus der OpenSSL-Distribution verwendet.

c_rehash `postconf -h smtp_tls_CApath`

(Falls der smtp-Client im chroot l├Ąuft, m├╝ssen die Zertifikate und die Links mit den Hashwerten dort ebenfalls vorhanden sein. Man kann das z.B. erreichen, indem man die Zertifikate in /var/spool/postfix/etc/postfix/tls/cacerts.d/ ablegt und das Verzeichnis dann per Symlink aus /etc/postfix/tls/ erreichbar macht. Oder man legt einen entsprechenden Kopierjob an. Der Fantasie des Lesers sind keine Grenzen gesetzt.)

Wie intensiv die Zertifikate bei abgehenden Verbindungen gepr├╝ft werden sollen, wird mittels smtp_tls_security_level festgelegt. Dar├╝berhinaus k├Ânnen in der ├╝ber smtp_tls_policy_maps referenzierten Datei /etc/postfix/tls_policy pro Zieldomain abweichende Policies definiert werden. Es lassen sich eine ganze Menge “Sicherheitsstufen” einstellen:

  • none: Es wird generell nicht verschl├╝sselt. Wenn der gegnerische Mailserver seine Verschl├╝sselungsbereitschaft anzeigt (STARTTLS im ESMTP-Greeting), wird dies ignoriert.
  • may: Wenn der gegenerische Mailserver STARTTLS anbietet, wird verschl├╝sselt, wenn nicht, dann nicht.
  • encrypt: Die Mail wird nur ├╝bertragen, wenn der gegnerische Mailserver STARTTLS anbietet und eine Verschl├╝sselung aufgebaut werden kann. Eine Pr├╝fung des Server-Zertifikats findet nicht statt. Selbstsignierte Zertifikate werden akzeptiert.
  • verify: Die Mail wird nur ├╝bertragen, wenn der gegnerische Server ein Zertifikat benutzt, das von einer CA ausgestellt wurde, deren Zertifikat im mit smtp_tls_CApath angegebenen Pfad enthalten ist.
  • secure: Die Mail wird nur ├╝bertragen, wenn der gegnerische Server ein Zertifikat benutzt, das von einer CA ausgestellt wurde, deren Zertifikat im mit smtp_tls_CApath angegebenen Pfad enthalten ist und bei dem der im Zertifikat eingetragene Common Name mit der Zieldomain ├╝bereinstimmt.

Als Default-Policy (smtp_tls_security_level) eignen sich ausschlie├člich “none” und “may”, denn mit “encrypt” und aufw├Ąrts wird man ein Gateway, das Mail ins Internet senden soll, nicht betreiben k├Ânnen. Ich habe mich im vorliegenden Fall f├╝r “none” entschieden, da ich in der von “may” gebotenen opportunistischen Verschl├╝sselung keinen Nutzen erkenne. Im Gegenteil: Opportunistische Verschl├╝sselung kostet mich nicht nur Rechenzeit, sondern es besteht potentiell die Gefahr, da├č Probleme bei der Kommunikation mit MTAs auftreten, bei denen TLS fehlerhaft konfiguriert und/oder implementiert ist.

Nun zu den Zielen, mit denen wir verschl├╝sselt kommunizieren wollen. Wenn man davon ausgeht, da├č keine Verschl├╝sselung besser ist als schlechte Verschl├╝sselung, kann man die Optionen “may” und “encrypt” in diesem Zusammenhang direkt vergessen:

  • Die opportunistische Verschl├╝sselung “may” bringt keinerlei Sicherheitsgewinn.
  • Kaum etwas anderes gilt f├╝r “encrypt”: F├╝r eine Gegenstelle Verschl├╝sselung zu erzwingen und dann jedes Zertifikat, egal ob abgelaufen oder selbstsigniert, zu akzeptieren, ist nur die Illusion von Sicherheit, gerade so, als w├╝rde man das routinem├Ą├čige Abklicken von SSL-Warnungen im WWW-Browser zum Standard erheben.

├ťbrig bleiben also “verify” und “secure”, von denen die letztere nat├╝rlich ganz besonders verlockend klingt und es auch ist:

  • Mit “verify” wird erzwungen, da├č Mail an eine Gegenstelle nur dann ausgeliefert wird, wenn deren Zertifikat von einer bekannten CA signiert wurde.
  • Mit “secure” wird nicht nur, wie bei “verify”, das Zertifikat ├╝berpr├╝ft, sondern es wird auch noch verlangt, da├č der Common Name des gegnerischen Zertifikats der Zieldomain entspricht. Alternativ kann auch eine Liste von Host- und Domainnamen angegeben werden, die als Common Names f├╝r die Zieldomain akzeptabel sind.

Hier also ein paar Beispiele f├╝r Eintr├Ąge in der tls_policy.

  • F├╝r die Domain binblog.de soll uns eine einfache ├ťberpr├╝fung des Zertifikats reichen:
    binblog.de verify

  • Die Mailexchanger der Domain example.com liegen alle in example.com (mx1.example.com und mx2.example.com), und wir wollen nur Zertifikate akzeptieren, die auf einen Hostnamen (Common Name) unter example.com ausgestellt sind:
    example.com secure

  • Der Mailexchanger der Domain scsy.de hat den Namen vortex.f00.net. In diesem Fall m├╝ssen wir, wenn wir den Common Name ├╝berpr├╝fen wollen, extra dazusagen, in welcher Domain er liegen bzw. welchen Namen er haben soll:
    scsy.de secure match=vortex.f00.net

Mit der in den letzten beiden Beispielen genannten “sicheren” ├ťberpr├╝fung von Zertifikaten stellen wir so weit wie m├Âglich sicher, da├č wir gegen DNS-Angriffe gesch├╝tzt sind: Wird uns ein gef├Ąlschter MX-Record untergeschoben, weigert sich Postfix, Mail an diesen auszuliefern. Wechselt die Domain den Besitzer und bekommt neue Mailexchanger, weigert sich Postfix ebenfalls, Mail dorthin auszuliefern, solange nicht entsprechende Konfigurations├Ąnderungen in der TLS Policy vorgenommen werden.

Wenn Postfix aufgrund einer Umstellung auf einer der Gegenseiten keine Mail ausliefern kann, werden die Mails ├╝brigens nicht gebounced, sondern im Rahmen der normalen Timeouts in der Queue behalten. Es bleibt also gen├╝gend Gelegenheit, auf ├ťberwachungen oder Useranrufe zu reagieren.

Diese gesamte Konfigurationsmethodik wurde von Postfix 2.2 zu Postfix 2.3 komplett ausgetauscht. Leider ist 2.3 bisher nur zu den wenigsten Distributionen durchgedrungen. Die Implementation in 2.3 ist aber so gelungen ausgefallen, da├č ich jedem, der sich auf diese Ebene begeben will, nur zum Upgrade raten kann.

Wer das alles viel zu ├╝berkandidelt findet: Die ├╝bern├Ąchste Postfix-Version, 2.5, wird voraussichtlich sogar die M├Âglichkeit haben, gezielt die Fingerprints von Zertifikaten pro Zieldomain anzugeben. Damit d├╝rfte dann wirklich das allerletzte DNS-Schlupfloch gestopft sein, und gleichzeitig k├Ânnen selbstsignierte Zertifikate verwendet werden.

Update am 21.3.: Hoffentlich werden hier jetzt keine Unwahrheiten mehr verbreitet. ­čśë

August 28, 2005

SMTP ├╝ber TLS testen

Filed under: Internet — Tags: , — martin @ 11:08 pm

-> http://www.pug.org/index.php/SMTP_%C3%BCber_TLS_testen

Wenn das gute alte Telnet auf Port 25(tm) einfach am Ende ist…

export CA=/etc/postfix/ssl/cacerts.pem
export CERT=/etc/postfix/ssl/signed-cert.pem
export KEY=/etc/postfix/ssl/key-nopasswd.pem

openssl s_client -starttls smtp -CAfile $CA -cert $CERT -key $KEY -connect mailhost:25

Blog at WordPress.com.