Serverbased E-mail Security: Difference between revisions
m (→Weiterführende Links: Link auf ein sehr gutes Tutorial ergänzt) |
|||
(16 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
'''TODO:'''<br> |
|||
<ul> |
|||
<li>Einführung schreiben</li> |
|||
<li>Szenario Architektur</li> |
|||
<li>Mailserver Setup beschreiben</li> |
|||
<li>SMGW Setup beschreiben</li> |
|||
</ul> |
|||
<br> |
|||
= Zusammenfassung = |
= Zusammenfassung = |
||
Immer mehr kritische Geschäftsprozze werden über Email Kommunikation abgewickelt. Dabei werden vertrauliche Daten direkt oder aber immer mehr auch automatisiert zwischen Applikationen (z.B. SAP Mailkonnektor) ausgetauscht. Das dafür verwendete SMTP Protokoll bietet keine ausreichenden Sicherheitsmechanismen, so dass sich die beiden Verfahren S/MIME und OpenPGP etablieren konnten. Eine standardkonforme Nutzung dieser Verfahren setzt ein enormes Anwenderwissen und relativ komplexe Vorgänge auf den Systemen des Endanwenders voraus. Dadurch werden PKI Infrastrukuren und Emailsignaturen und -verschlüsselungen bisher nicht umfassend eingesetzt. Die serverbasierten Lösungen tragen mehr und mehr dazu bei die genannten Verfahren einer breiten Anwenderzahl zugänglich zu machen und lassen die Nutzung von PKI's, Trustcentern und Emailsicherheit deutlich aufleben. Zusätzlich zu einer Vereinfachung der Anwendung und Administration bietet eine zentrale Lösung die Möglichkeit der Umsetzung von Archivierungen, Viren/SPAM Prüfungen in verschlüsselten Emails, Organisationsweiter Schlüsselhinterlegung (gefordert in |
Immer mehr kritische Geschäftsprozze werden über Email Kommunikation abgewickelt. Dabei werden vertrauliche Daten direkt oder aber immer mehr auch automatisiert zwischen Applikationen (z.B. SAP Mailkonnektor) ausgetauscht. Das dafür verwendete SMTP Protokoll bietet keine ausreichenden Sicherheitsmechanismen, so dass sich die beiden Verfahren S/MIME und OpenPGP etablieren konnten. Eine standardkonforme Nutzung dieser Verfahren setzt ein enormes Anwenderwissen und relativ komplexe Vorgänge auf den Systemen des Endanwenders voraus. Dadurch werden PKI Infrastrukuren und Emailsignaturen und -verschlüsselungen bisher nicht umfassend eingesetzt. Die serverbasierten Lösungen tragen mehr und mehr dazu bei die genannten Verfahren einer breiten Anwenderzahl zugänglich zu machen und lassen die Nutzung von PKI's, Trustcentern und Emailsicherheit deutlich aufleben. Zusätzlich zu einer Vereinfachung der Anwendung und Administration bietet eine zentrale Lösung die Möglichkeit der Umsetzung von Archivierungen, Viren/SPAM Prüfungen in verschlüsselten Emails, Organisationsweiter Schlüsselhinterlegung (gefordert in BS 7799-2:2002 konformen Security Policy's), Anwendung globaler kontrollierbarer Regeln usw.. Da es bisher keine akzeptable freie OpenSource Implementierung gibt, wird hier der Aufbau eines Beispielszenarios auf Basis des SecureMail Gateways der Berliner Firma [http://www.zertificon.com Zertificon Solutions] durchgeführt. Vielen Dank für die Bereitstellung einer kostenfreien Lizenz! |
||
= |
= Einleitung = |
||
<div style="border:1px solid #000000;padding:10px;background-color:#F7F7F7"> |
|||
'''Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "[http://de.wikipedia.org/wiki/Wikipedia:GNU_Free_Documentation_License GNU Free Documentation License]".''' <!-- Dieser Passus muss hier rein, siehe "How to use this license" in der GFDL. --> |
|||
Lange Zeit wurden unter dem Begriff Emailsicherheit lediglich Viren/SPAM Filter verstanden oder allgemeiner Systeme zur Eliminierung ungewollter Emails bzw. Emailinhalte. Eine Erweiterung des schwer einzugrenzenden Begriffs stellt die Anwendung kryptografischer Verfahren, aus dem Gebiet der IT Sicherheit zur Realisierung verschiedener Schutzziele, auf die Emailkommunikation dar. Dafür sind 2 Verfahren sehr weit verbreitet S/MIME und OpenPGP, welche sich ähneln aber nicht zueinander kompatibel sind. Der Anwender muss sich (und alle seine Kommunikationspartner) daher für ein Verfahren entscheiden oder entsprechende Software auswählen, die beide "Welten" unterstützt. Mit Hilfe dieser Verfahren ist es möglich digitale Signaturen zu erzeugen zur Sicherstellung von Integrität, Authentisierung und Verbindlichkeit sowie den Inhalt zu verschlüsseln um Vertraulichkeit zu gewährleisten. |
|||
Übersetzung: ''Kopieren, Verbreiten und/oder Modifizieren ist unter den Bedingungen der GNU Free Documentation License, Version 1.2 oder einer späteren Version, veröffentlicht von der Free Software Foundation, erlaubt. Es gibt keine unveränderlichen Abschnitte, keinen vorderen Umschlagtext und keinen hinteren Umschlagtext. Eine Kopie des Lizenztextes ist unter dem Titel [http://de.wikipedia.org/wiki/Wikipedia:GNU_Free_Documentation_License GNU Free Documentation License] enthalten.'' |
|||
Diese beiden Anwendungen basieren auf einem hybriden Verfahren aus asymmetrischer und symmetrischer Kryptografie und erfordern daher eine entsprechende Verwaltung der in Zertifikate eingebetteten Schlüssel. Dabei muss zwischen öffentlichen Zertifikaten der Kommunikationspartner und den privaten internen Zertifikaten unterschieden werden. |
|||
</div> |
|||
Siehe auch: |
|||
<br> |
|||
* [http://de.wikipedia.org/wiki/E-Mail Wikipedia: E-Mail] |
|||
* [http://de.wikipedia.org/wiki/Computersicherheit Wikipedia: Sicherheit] |
|||
* [http://de.wikipedia.org/wiki/Spam Wikipedia: SPAM] |
|||
* [http://de.wikipedia.org/wiki/Computervirus Wikipedia: Viren] |
|||
* [http://de.wikipedia.org/wiki/Computerwurm Wikipedia: Würmer] |
|||
== S/Mime und PKI == |
|||
Die 1. Version dieses Dokumentes wurde von [[Ingo Kampe]] erstellt. |
|||
S/Mime basiert auf der Nutzung von X.509 Zertifikaten, die Bestandteil einer [[PKI]] sind. |
|||
<br> |
|||
Siehe auch: |
|||
= Einleitung = |
|||
* [http://de.wikipedia.org/wiki/S/MIME Wikipedia: S/MIME] |
|||
* [http://de.wikipedia.org/wiki/Public-Key-Infrastruktur Wikipedia: Public-Key-Infrastruktur] |
|||
== S/Mime und PKI == |
|||
== OpenPGP == |
== OpenPGP == |
||
OpenPGP nutzt selbsterzeugte Zertifikate, deren Echtheit über die Unterschriftenkette das sogenannte "Web of Trust" bestätigt wird. |
|||
Siehe auch: |
|||
* [http://de.wikipedia.org/wiki/OpenPGP Wikipedia: OpenPGP] |
|||
* [http://de.wikipedia.org/wiki/Web_of_trust Wikipedia: Web of Trust] |
|||
== Zertifikationsverwaltung == |
== Zertifikationsverwaltung == |
||
Die Zertifikate der Emailkommunikationspartner müssen den Anwendungen zur Verfügung stehen. Zusätzlich müssen alle Zertifikate im Pfad bis zu einer vertrauenswürdigen Wurzel ebenfalls zur Validierung bekannt sein. Das erfordert ein komplexes Zertifikatsmanagement. |
|||
=== Externe Kommunikationspartner === |
=== Externe Kommunikationspartner === |
||
Die öffentlichen Zertifikate der Kommunikationspartner sind größtenteils in Verzeichnisdiensten der Herausgeber (Trustcenter) frei verfügbar oder werden manuell vor einer verschlüsselten Kommunikation oder implizit eingebettet in Signaturen übermittelt. Aus diesen 3 Quellen muss die Anwendung Zertifikate entgegennehmen können und idealerweise lokal speichern. Die Schwierigkeit besteht hierbei in den unterschiedlichen Formaten und Protokollen sowie in der Vielzahl der verfügbaren Trustcenter. Ein zentraler Service stellt daher eine enorme Vereinfachung für den Endwanwender dar. Dieser fungiert als Speicher und Metasuchmaschine und kann sogar bei entsprechendem Vertrauensstatus die Validierung übernehmen. Diese zentralen Zertifikatsdienste werden über Webservices und/oder dem XKMS Protokoll in Anwendungen integriert. Ein Beispiel: [http://backbone.zertificon.com Backbone of Trust]. |
|||
=== Interne Private Zertifikate === |
=== Interne Private Zertifikate === |
||
Die internen Zertifikate mit den geheimen Schlüsseln sind sicherheitsrelevante Daten und müssen daher auf entsprechend geschützte Weise verwaltet werden. Dazu können Software PSE auf speziell gehärteten Serversystemen, Hardware Security Module (z.B. spezielle PCI Karten, SmartCards) oder auch remote PSE's mit zertifizierten geschlossen Blackboxsystemen genutzt werden. Für Firmen ist es möglich den Verwaltungsaufwand enorm zu verkleinern durch die Nutzung von Domainzertifikaten. Hierbei wird pro Emaildomain nur ein privates Zertifikat benutzt. |
|||
== Use Cases == |
== Use Cases == |
||
Es gibt viele konkrete Szenarien in denen Emailsicherheit empfehlenswert oder sogar geschäftskritsche Notwendigkeit ist. Für die spezielle Form der serverbasierten Variante wären folgende zu nennen: |
|||
*Viren/SPAM filtern in verschlüsselten Emails |
|||
= Beispielszenario = |
|||
*Digitale Signatur als Schutz vor Phishing |
|||
*Übermittlung kritischer Daten verschlüsselt per Mail (auch automatisiert und in großen Mengen) |
|||
*Durchsetzung zentraler Regeln zur Anwendung von Kryptografie (z.B. Verbot interner Verschlüsselung zur Informationsflusskontrolle) |
|||
= OSMS - OpenSecurityMailServer = |
|||
Im folgenden wird Schritt für Schritt der Aufbau eines aktuell modernen (möglichst) sicheren Mailservers auf Basis von OpenSuSE 10 beschrieben. Bei Verdopplung des hier beschriebenen Systems und entsprechender Konfigurationsanpassung auf eine 2. Domain und IP kann damit ein vollständiges Server2Server Mailroutingszenario abgebildet und getestet werden. Das Verhalten der verschiedenen Sicherheitskomponenten kann eindrucksvoll im Zusammenspiel beobachtet werden. Ebenfalls möglich ist der Nachbau dieses fullfeatured Mailservers auf entsprechender Zielhardware zu Performancemessungen. Das Setup basiert teilweise auf der [http://genco.gen.tc/postfix_virtual.php Beschreibung von Genco YILMAZ]. |
|||
== Aufbau Mailserver == |
== Aufbau Mailserver == |
||
Die Basiskomponenten des Systems sind: |
|||
== Einrichtung SecureMail Gateway == |
|||
* Betriebssystem: OpenSuSE 10 |
|||
== Anwendung und Testfälle == |
|||
* Datenbank: PostgreSQL |
|||
* MTA: Postfix 2.2 + SASL AUTH + TLS |
|||
* IMAP/POP: Courier IMAPs/POPs |
|||
* Webmail: Squirrelmail |
|||
* Security: SecureMail Gateway 2.3 von Zertificon Solutions (OpenSSL, GnuPG, Bouncycastle) |
|||
* Virenfilter: ClamAV über amavisd-new |
|||
* SpamFilter: SpamAssassin über amavisd-new |
|||
== Betriebssystem Setup == |
|||
* CD 1 oder DVD 1 einlegen und booten vom Medium |
|||
* Auswahl Bootscreen: <Installation> |
|||
* Language: Deutsch |
|||
* Medienpruefung: <Weiter> |
|||
* Lizenz: Ja + <Weiter> |
|||
* Uhr und Zeitzone: Europa + Deutschland + Lokale Zeit + <Weiter> |
|||
* Desktop: Andere + Textmodus + <Weiter> |
|||
* Installationseinstellungen: <Uebernehmen> |
|||
* Installation bestaetigen: <Installieren> |
|||
* nach reboot CD 5 einlegen falls zur Hand ansonsten: <Ueberspringen> + <Ignorieren> |
|||
=== Basiskonfiguration === |
|||
* root Passwort setzen |
|||
* Netzwerkkonfiguration: |
|||
** Aendern -> Firewall -> Erlaubte Dienste hinzufuegen fuer die externe Zone: |
|||
DHCP-Client (bei Bedarf), HTTPS,IMAPS,POP3S,SSH,Mailserver |
|||
** Aendern -> Netzwerkschnittstellen -> Bearbeiten: |
|||
Konfigurationsmethode, falls statische IP entsprechend eintragen |
|||
Hostname, Domain, Nameserver, Defaultroute entsprechend Umgebung eintragen |
|||
<Weiter>,<Weiter> |
|||
* Test der Internetverbindung: "Nein" <Weiter> |
|||
* Methode zur Benutzer-Authentifikation: Lokal (/etc/passwd) <Weiter> |
|||
* Neuer Benutzer: <Weiter>,<Ja> |
|||
* Hinweise zur Version: <Weiter> |
|||
* Hardwarekonfiguration: <Weiter> |
|||
* Installation abgeschlossen: <Beenden> |
|||
=== Remotezugang freischalten === |
|||
als root auf der Konsole anmelden: |
|||
vi /etc/ssh/sshd_config: |
|||
PermitRootLogin yes |
|||
/etc/init.d/sshd restart |
|||
Absofort kann die weitere Installation remote ueber eine SSH Sitzung durchgefuehrt werden! |
|||
== Installation aller Pakete und Onlineupdate == |
|||
(das Onlineupdate steht für OpenSuSE noch nicht zur Verfügung und muss hier noch ergänzt werden) |
|||
=== Installationsquelle fuer Netzinstallation hinzufuegen === |
|||
Hinweis: bei lokalem DVD oder CD Satz nicht notwendig! |
|||
1. yast starten als root user |
|||
2. Falls notwendig proxy einrichten unter Netzwerkdienste -> Proxy-Server: |
|||
(x) Aktivieren, z.B.: http://proxy.domain.loc:3128 |
|||
3. Software -> Installationsquelle wechseln -> Hinzufuegen: |
|||
http://download.opensuse.org/distribution/SL-OSS-current/inst-source |
|||
http://download.opensuse.org/distribution/SL-OSS-current/inst-source-java/ |
|||
<yes> |
|||
4. Mit <Auf> die neue Quelle in der Liste nach oben verschieben. |
|||
Jetzt koennen beliebige Pakete ohne Installationsmedien hinzugefuegt werden. |
|||
=== Notwendige Softwarepakete installieren === |
|||
System: |
|||
yast -i xntp wget findutils-locate |
|||
SecureMail: |
|||
yast -i postgresql postgresql-server patch sudo XFree86-libs libtool |
|||
Postfix: |
|||
yast -i postfix-postgresql postgresql-libs |
|||
Cyrus SASL Authentication for SMTPD: |
|||
yast -i mysql-shared postgresql-libs cyrus-sasl-sqlauxprop |
|||
Courier (and dependencies): |
|||
yast -i courier-authlib courier-imap expect fam libtool tcl fam-server |
|||
Squirrelmail (and dependencies): |
|||
yast -i apache2-prefork apache2 apache2-mod_auth_mysql apache2-mod_php5 php5-gettext php5-iconv \ |
|||
php5-mbstring php5-openssl ispell-american squirrelmail squirrelmail-plugins php5-pgsql |
|||
Content Filter: |
|||
yast -i amavisd-new spamassassin clamav clamav-db |
|||
oder alles zusammen mit: |
|||
yast -i xntp wget findutils-locate postgresql postgresql-server patch sudo XFree86-libs libtool \ |
|||
postfix-postgresql postgresql-libs mysql-shared cyrus-sasl-sqlauxprop courier-authlib courier-imap \ |
|||
expect fam tcl fam-server apache2-prefork apache2 apache2-mod_auth_mysql apache2-mod_php5 php5-gettext \ |
|||
php5-iconv php5-mbstring php5-openssl ispell-american squirrelmail squirrelmail-plugins amavisd-new \ |
|||
spamassassin clamav clamav-db php5-pgsql |
|||
Alle neuinstallierten Services in den Runleveln verlinken: |
|||
for d in saslauthd spamd freshclam clamd amavis ntp apache2 fam courier-authdaemon courier-imap-ssl courier-pop-ssl |
|||
do |
|||
chkconfig --add $d |
|||
done |
|||
Manuelles Hinzufuegen von phpPgAdmin: |
|||
cd /srv/www/htdocs/ && \ |
|||
wget http://mesh.dl.sourceforge.net/sourceforge/phppgadmin/phpPgAdmin-3.5.5.tar.bz2 && \ |
|||
tar xvjf phpPgAdmin-3.5.5.tar.bz2 && \ |
|||
rm phpPgAdmin-3.5.5.tar.bz2 |
|||
Das courier-authlib RPM muss neugebaut werden für die PostgreSQL Anbindung. Dazu können die SuSE Source Pakete genutzt werden. Hier sind meine nicht speziell gekennzeichneten oder versionierten RPMs für den Schnelltest und als Vorlage. Der Courier-IMAP Server unterstützt noch kein PostgreSQL, das kann mit folgenden Paketen nachinstalliert werden: |
|||
[https://www.informatik.hu-berlin.de/~kampe/OSMS/courier-authlib-0.57-2.i586.rpm Courier Authlib RPM mit PGSQL support] |
|||
[https://www.informatik.hu-berlin.de/~kampe/OSMS/courier-authlib-0.57-2.src.rpm Courier Authlib SRPM mit PGSQL support] |
|||
Selbermachen geht so: |
|||
* courier-authlib source RPM installieren (z.B. im yast suchen und dann Aktionen->Quellen installieren -> Weiter) |
|||
* Notwendige Pakete zum Kompilieren nachinstallieren: |
|||
yast -i postgresql-devel bison cvs flex gdbm-devel gettext-devel glibc-devel m4 ncurses-devel rcs strace \ |
|||
texinfo unzip zlib-devel autoconf automake gcc gcc-c++ libstdc++-devel openldap2-devel pam-devel |
|||
* Anpassen von /usr/src/packages/SPECS/courier-authlib.spec: |
|||
beim configure (Zeile 80) hinzufuegen: |
|||
--with-pgsql-libs=/usr/lib \ |
|||
--with-pgsql-includes=/usr/include/pgsql \ |
|||
--with-authpgsql \ |
|||
in der %files section (Zeile 150): |
|||
%{_libdir}/libauthpgsql.so.0* |
|||
* Neues RPM erzeugen: |
|||
rpmbuild -ba /usr/src/packages/SPECS/courier-authlib.spec |
|||
* Neues RPM installieren: |
|||
rpm --force -U /usr/src/packages/RPMS/i*86/courier-authlib-0.*.i*86.rpm |
|||
* Entfernen der devel Pakete: |
|||
rpm -e postgresql-devel bison cvs flex gdbm-devel gettext-devel glibc-devel m4 ncurses-devel rcs \ |
|||
strace texinfo unzip zlib-devel autoconf automake gcc gcc-c++ libstdc++-devel openldap2-devel \ |
|||
pam-devel pango gtk2 cairo autoconf texinfo atk libgcj cyrus-sasl-devel |
|||
=== SecureMail Gateway installieren === |
|||
Release auspacken: |
|||
tar xvzf smgw-2_3_0-gw-build0150-suse-i386.tar.gz |
|||
Anpassungen zur Installation auf OpenSuSE 10: |
|||
cd smgw-2_3_0-gw-build0150-suse-i386 |
|||
perl -pi -e 's/_IDS="SUSE LINUX Enterprise Server/_IDS="SUSE LINUX/;s/-eq 9/-ge 9/' install.sh |
|||
perl -pi -e 's/_VERSIONS=9/_VERSIONS="9\t10"/' install/makeenv |
|||
Installation starten: |
|||
./install.sh |
|||
Eingaben zur Installation: |
|||
Netzwerke zur Firewallkonfiguration aus denen auf das SMGW zugegriffen wird (SSH + WWW) z.B. |
|||
NETWORKS = 192.168.0.0/24 |
|||
Mailrouting (yes auswaehlen): |
|||
die 1. zu konfigurierende Domain auswaehlen z.B. |
|||
Domain name: company1.loc |
|||
Recipient domains: |
|||
Internal mail server: |
|||
External smartrelay: |
|||
Runlevel Links erstellen mit: |
|||
chkconfig --add smgw |
|||
== Konfiguration == |
|||
=== Zeitsynchronisation (NTP) === |
|||
Eine exakte Zeit ist fuer digitale Signaturen und Zertifikatsvalidierung zwingend notwendig. |
|||
vim /etc/ntp.conf |
|||
server ntp1.ptb.de |
|||
server ntps1-0.cs.tu-berlin.de |
|||
server ntp2.ptb.de |
|||
server ntps1-1.cs.tu-berlin.de |
|||
/etc/init.d/ntp restart |
|||
=== User/Gruppen === |
|||
groupadd -g 1001 vmail |
|||
useradd -g 1001 -u 1001 -d /home/vmail -m -c 'Virtual Mailsystem User' vmail |
|||
=== Datenbank Virtuelle Domain/User Konfiguration === |
|||
/etc/init.d/postgres start |
|||
Als Datenbank User weiterarbeiten: |
|||
su - postgres |
|||
Zugriffsrechte anpassen: |
|||
perl -pi -e 's/(.*?127\.0\.0\.1.*?)ident sameuser/$1md5/g' $PGDATA/pg_hba.conf |
|||
pg_ctl reload |
|||
Mail Datenbank erstellen: |
|||
psql -c "create user vmailuser with password 'changeIT' createdb createuser" template1 |
|||
psql -U vmailuser -h 127.0.0.1 -p 5432 -c "create database mail with encoding = 'unicode'" template1 |
|||
psql -U vmailuser -h 127.0.0.1 -p 5432 -d mail < [https://www.informatik.hu-berlin.de/~kampe/OSMS/create_tables.sql create_tables.sql] |
|||
Beispieldaten hinzufügen: |
|||
postgres@osms:~> psql -U vmailuser -h 127.0.0.1 -p 5432 -d mail -c "\ |
|||
INSERT INTO postfix_users (email,clear,name,homedir,maildir,quota) VALUES |
|||
('alice@company1.loc','alice','Alice','/home/vmail/','company1.loc/alice/Maildir/','10000000') ;" |
|||
Erstellen des Mailverzeichnisses fuer den neuen User: |
|||
osms:~ # su - vmail |
|||
vmail@osms:~> mkdir -p company1.loc/alice |
|||
vmail@osms:~> maildirmake company1.loc/alice/Maildir |
|||
vmail@osms:~> maildirmake -q 10000000S company1.loc/alice/Maildir |
|||
Einrichten von phpPgAdmin zur Pflege der MTA Daten: |
|||
osms:/srv/www/htdocs/phpPgAdmin # cp conf/config.inc.php-dist conf/config.inc.php |
|||
osms:/srv/www/htdocs/phpPgAdmin # vim conf/config.inc.php |
|||
$conf['servers'][0]['desc'] = 'Postfix/Courier Backend'; |
|||
$conf['servers'][0]['host'] = '127.0.0.1'; |
|||
$conf['servers'][0]['port'] = 5432; |
|||
$conf['servers'][0]['defaultdb'] = 'template1'; |
|||
$conf['servers'][0]['pg_dump_path'] = '/usr/bin/pg_dump'; |
|||
$conf['servers'][0]['pg_dumpall_path'] = '/usr/bin/pg_dumpall'; |
|||
/etc/init.d/apache2 restart |
|||
Anmelden ist dann ueber http://192.168.0.170/phpPgAdmin/ als vmailuser (pass: changeIT) moeglich. |
|||
Ueber die WebGUI koennen nun weitere User/Domains hinzugefuegt werden. In groesseren Installationen koennen natuerlich spezielle Mailverwaltugnen direkt auf das SQL Backend zugreifen. Eine Integration ist dadurch leicht moeglich, ebenso ein Verteilung der Daten auf mehrere MTA Instanzen. |
|||
=== Postfix === |
|||
==== TLS ==== |
|||
SMTPD Server SSL Zertifikat erzeugen. Fuer ein Produktivsystem sollte hier natuerlich eine echte CA genutzt werden. |
|||
osms:/etc/postfix # openssl req -x509 -newkey rsa:1024 -keyout postfix.pem -out postfix.pem -nodes -days 365 |
|||
Generating a 1024 bit RSA private key |
|||
----- |
|||
Country Name (2 letter code) [AU]:DE |
|||
State or Province Name (full name) [Some-State]:Berlin |
|||
Locality Name (eg, city) []:Berlin |
|||
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Company 1 |
|||
Organizational Unit Name (eg, section) []:Secure Emailadministration |
|||
Common Name (eg, YOUR name) []:osms.domain.loc |
|||
Email Address []: |
|||
Einstellungen in /etc/postfix/main.cf: |
|||
smtpd_use_tls = yes |
|||
smtpd_tls_cert_file = $config_directory/postfix.pem |
|||
smtpd_tls_key_file = $smtpd_tls_cert_file |
|||
smtpd_tls_auth_only = yes |
|||
==== SASL/SMTP AUTH ==== |
|||
Einstellungen in /etc/postfix/main.cf: |
|||
smtpd_sasl_auth_enable = yes |
|||
smtpd_sasl_security_options = noanonymous |
|||
smtpd_sasl_local_domain = $myhostname |
|||
broken_sasl_auth_clients = yes |
|||
smtpd_sasl_application_name = smtpd |
|||
osms:/etc/postfix # vim /usr/lib/sasl2/smtpd.conf |
|||
pwcheck_method: auxprop |
|||
auxprop_plugin: sql |
|||
mech_list: plain login |
|||
sql_engine: pgsql |
|||
sql_hostnames: localhost |
|||
sql_user: vmailuser |
|||
sql_passwd: changeIT |
|||
sql_database: mail |
|||
sql_select: select clear from postfix_users where email='%u@%r' and smtpaccess='Y' |
|||
==== Lookup Tables ==== |
|||
Die standardmäßig als normale Dateien zur Verfügung gestellten Map/Lookup Tabellen sind in die Datenbank verlagert worden, um weitere Applikationen darauf aufzusetzen und eine Verteilung in großen geclusterten Installationen zu gewährleisten. Die einzelnen Tabellen werden separat konfiguriert. |
|||
Postfix erfährt über die /etc/postfix/main.cf die Konfigurationsdateien: |
|||
check_client_access pgsql:/etc/postfix/pgsql-client.cf |
|||
check_sender_access pgsql:/etc/postfix/pgsql-sender.cf |
|||
check_recipient_access pgsql:/etc/postfix/pgsql-recipient.cf |
|||
alias_maps = pgsql:/etc/postfix/pgsql-aliases.cf |
|||
relocated_maps = pgsql:/etc/postfix/pgsql-relocated.cf |
|||
transport_maps = pgsql:/etc/postfix/pgsql-transport.cf |
|||
virtual_mailbox_domains = pgsql:/etc/postfix/pgsql-virtual-domains.cf |
|||
virtual_alias_maps = pgsql:/etc/postfix/pgsql-virtual.cf |
|||
virtual_mailbox_maps = pgsql:/etc/postfix/pgsql-virtual-maps.cf |
|||
virtual_uid_maps = pgsql:/etc/postfix/pgsql-virtual-uid.cf |
|||
virtual_gid_maps = pgsql:/etc/postfix/pgsql-virtual-gid.cf |
|||
Die einzelnen Dateien befinden sich in der archivierten [https://www.informatik.hu-berlin.de/~kampe/OSMS/postfix_config.tar.bz2 Postfix Konfiguration]. |
|||
==== Routing ==== |
|||
Das Mailrouting wird hauptsächlich durch die in der master.cf konfigurierten Services beeinflusst. |
|||
Folgende Grundideen sind hierbei umgesetzt: |
|||
[[Image:OSMSarch_pfrout.png|thumb|right|Postfix Routing Overview]] |
|||
* Separierung von innen und außen Bereich durch Port 25 SMTPD auf unterschiedlichen IP Adressen (im aktuellen Beispiel außen: 192.168.0.170 innen 192.168.0.171) |
|||
* auf beiden Eingängen ist TLS aktiv |
|||
* an der inneren Schnittstelle wird TLS erzwungen (für Clients die dies nicht unterstützen z.B. squirrelmail wird der separate smtps Port 465 geöffnet) |
|||
* SMTP AUTH ist am inneren Eingang Pflicht |
|||
* ein before-queue amavisd Filter führt adhoc Viren/SPAM checks durch, die zum REJECT der Mail führen können |
|||
* das SMGW sorgt für automatische Ver/Entschlüsselung, Signatur/Verifikation |
|||
* anschließend wird nochmals ein Viren/SPAM check durchgeführt (damit werden eingangs verschlüsselte Viren und auch SPAM gefiltert!) |
|||
Die main.cf und master.cf befinden sich in der archivierten [https://www.informatik.hu-berlin.de/~kampe/OSMS/postfix_config.tar.bz2 Postfix Konfiguration]. |
|||
=== Courier === |
|||
==== Auth ==== |
|||
Zur Authentifizierung wird das Paket courier-authlib benutzt und muss zur Anbindung an die |
|||
User Datenbank konfiguriert werden. |
|||
vim /etc/authlib/authdaemonrc: |
|||
authmodulelist="authpgsql authpam" |
|||
vim /etc/authlib/authpgsqlrc: |
|||
PGSQL_HOST localhost |
|||
PGSQL_PORT 5432 |
|||
PGSQL_USERNAME vmailuser |
|||
PGSQL_PASSWORD changeIT |
|||
PGSQL_DATABASE mail |
|||
PGSQL_USER_TABLE postfix_users |
|||
PGSQL_CRYPT_PWFIELD crypt |
|||
PGSQL_CLEAR_PWFIELD clear |
|||
PGSQL_UID_FIELD uid |
|||
PGSQL_GID_FIELD gid |
|||
PGSQL_LOGIN_FIELD email |
|||
PGSQL_HOME_FIELD homedir |
|||
PGSQL_NAME_FIELD name |
|||
PGSQL_MAILDIR_FIELD maildir |
|||
PGSQL_QUOTA_FIELD quota |
|||
PGSQL_AUXOPTIONS_FIELD 'disableimap=' || disableimap || ',disablepop3=' || disablepop3 || ', |
|||
disablewebmail=' || disablewebmail || ',sharedgroup=' || sharedgroup |
|||
PGSQL_WHERE_CLAUSE access='Y' |
|||
chmod 400 /etc/authlib/authpgsqlrc |
|||
/etc/init.d/courier-authdaemon restart |
|||
==== IMAP/POP ==== |
|||
Create SSL certs: |
|||
vim /etc/courier/pop3d.cnf: |
|||
[ req_dn ] |
|||
C=DE |
|||
ST=B |
|||
L=Berlin |
|||
O=Courier POP3 Server |
|||
OU=Automatically-generated POP3 SSL key |
|||
CN=localhost |
|||
emailAddress=postmaster@domain.loc |
|||
vim /etc/courier/imapd.cnf: |
|||
[ req_dn ] |
|||
C=DE |
|||
ST=B |
|||
L=Berlin |
|||
O=Courier IMAP Server |
|||
OU=Automatically-generated IMAP SSL key |
|||
CN=localhost |
|||
emailAddress=postmaster@domain.loc |
|||
Prozesse starten mit: |
|||
/etc/init.d/fam start |
|||
/etc/init.d/courier-pop-ssl start |
|||
/etc/init.d/courier-imap-ssl start |
|||
=== Squirrelmail Webmailer === |
|||
Die Konfiguration auf eigene Daten anpassen: |
|||
/srv/www/htdocs/squirrelmail/config/conf.pl |
|||
http://192.168.0.170/squirrelmail/ |
|||
Name: alice@company1.loc |
|||
Password: alice |
|||
=== Z1 SecureMail Gateway === |
|||
* Lizenz einspielen |
|||
* Relay IPs anpassen |
|||
* Policy einstellen |
|||
Der Anwendung liegt eine sehr gute Dokumentation bei. Entweder über die Weboberfläche unter "Documentation" oder im Dateisystem: ``/opt/tbone/doc/Z1_SMGW_03_System_Guide.pdf``. |
|||
== Anwendung und Testfälle == |
|||
= Fazit = |
= Fazit = |
||
Line 57: | Line 473: | ||
[http://www.zertificon.com/z1_secure_mail_gateway.php Z1 SecureMail Gateway]<br> |
[http://www.zertificon.com/z1_secure_mail_gateway.php Z1 SecureMail Gateway]<br> |
||
[http://www.teletrust.de Teletrust e.V. (inkl. ISIS-MTT Spezifikation)]<br> |
[http://www.teletrust.de Teletrust e.V. (inkl. ISIS-MTT Spezifikation)]<br> |
||
[http://workaround.org/articles/ispmail-sarge/index.shtml.de Tutorial: ISP-ähnlicher Email Service mit Debian-Sarge und Postfix 2.1]<br> |
|||
<br> |
|||
1. Autor: [[Ingo Kampe]] (Signierte Emails an kampe@...) |
Latest revision as of 22:20, 28 October 2005
Zusammenfassung
Immer mehr kritische Geschäftsprozze werden über Email Kommunikation abgewickelt. Dabei werden vertrauliche Daten direkt oder aber immer mehr auch automatisiert zwischen Applikationen (z.B. SAP Mailkonnektor) ausgetauscht. Das dafür verwendete SMTP Protokoll bietet keine ausreichenden Sicherheitsmechanismen, so dass sich die beiden Verfahren S/MIME und OpenPGP etablieren konnten. Eine standardkonforme Nutzung dieser Verfahren setzt ein enormes Anwenderwissen und relativ komplexe Vorgänge auf den Systemen des Endanwenders voraus. Dadurch werden PKI Infrastrukuren und Emailsignaturen und -verschlüsselungen bisher nicht umfassend eingesetzt. Die serverbasierten Lösungen tragen mehr und mehr dazu bei die genannten Verfahren einer breiten Anwenderzahl zugänglich zu machen und lassen die Nutzung von PKI's, Trustcentern und Emailsicherheit deutlich aufleben. Zusätzlich zu einer Vereinfachung der Anwendung und Administration bietet eine zentrale Lösung die Möglichkeit der Umsetzung von Archivierungen, Viren/SPAM Prüfungen in verschlüsselten Emails, Organisationsweiter Schlüsselhinterlegung (gefordert in BS 7799-2:2002 konformen Security Policy's), Anwendung globaler kontrollierbarer Regeln usw.. Da es bisher keine akzeptable freie OpenSource Implementierung gibt, wird hier der Aufbau eines Beispielszenarios auf Basis des SecureMail Gateways der Berliner Firma Zertificon Solutions durchgeführt. Vielen Dank für die Bereitstellung einer kostenfreien Lizenz!
Einleitung
Lange Zeit wurden unter dem Begriff Emailsicherheit lediglich Viren/SPAM Filter verstanden oder allgemeiner Systeme zur Eliminierung ungewollter Emails bzw. Emailinhalte. Eine Erweiterung des schwer einzugrenzenden Begriffs stellt die Anwendung kryptografischer Verfahren, aus dem Gebiet der IT Sicherheit zur Realisierung verschiedener Schutzziele, auf die Emailkommunikation dar. Dafür sind 2 Verfahren sehr weit verbreitet S/MIME und OpenPGP, welche sich ähneln aber nicht zueinander kompatibel sind. Der Anwender muss sich (und alle seine Kommunikationspartner) daher für ein Verfahren entscheiden oder entsprechende Software auswählen, die beide "Welten" unterstützt. Mit Hilfe dieser Verfahren ist es möglich digitale Signaturen zu erzeugen zur Sicherstellung von Integrität, Authentisierung und Verbindlichkeit sowie den Inhalt zu verschlüsseln um Vertraulichkeit zu gewährleisten. Diese beiden Anwendungen basieren auf einem hybriden Verfahren aus asymmetrischer und symmetrischer Kryptografie und erfordern daher eine entsprechende Verwaltung der in Zertifikate eingebetteten Schlüssel. Dabei muss zwischen öffentlichen Zertifikaten der Kommunikationspartner und den privaten internen Zertifikaten unterschieden werden.
Siehe auch:
S/Mime und PKI
S/Mime basiert auf der Nutzung von X.509 Zertifikaten, die Bestandteil einer PKI sind.
Siehe auch:
OpenPGP
OpenPGP nutzt selbsterzeugte Zertifikate, deren Echtheit über die Unterschriftenkette das sogenannte "Web of Trust" bestätigt wird.
Siehe auch:
Zertifikationsverwaltung
Die Zertifikate der Emailkommunikationspartner müssen den Anwendungen zur Verfügung stehen. Zusätzlich müssen alle Zertifikate im Pfad bis zu einer vertrauenswürdigen Wurzel ebenfalls zur Validierung bekannt sein. Das erfordert ein komplexes Zertifikatsmanagement.
Externe Kommunikationspartner
Die öffentlichen Zertifikate der Kommunikationspartner sind größtenteils in Verzeichnisdiensten der Herausgeber (Trustcenter) frei verfügbar oder werden manuell vor einer verschlüsselten Kommunikation oder implizit eingebettet in Signaturen übermittelt. Aus diesen 3 Quellen muss die Anwendung Zertifikate entgegennehmen können und idealerweise lokal speichern. Die Schwierigkeit besteht hierbei in den unterschiedlichen Formaten und Protokollen sowie in der Vielzahl der verfügbaren Trustcenter. Ein zentraler Service stellt daher eine enorme Vereinfachung für den Endwanwender dar. Dieser fungiert als Speicher und Metasuchmaschine und kann sogar bei entsprechendem Vertrauensstatus die Validierung übernehmen. Diese zentralen Zertifikatsdienste werden über Webservices und/oder dem XKMS Protokoll in Anwendungen integriert. Ein Beispiel: Backbone of Trust.
Interne Private Zertifikate
Die internen Zertifikate mit den geheimen Schlüsseln sind sicherheitsrelevante Daten und müssen daher auf entsprechend geschützte Weise verwaltet werden. Dazu können Software PSE auf speziell gehärteten Serversystemen, Hardware Security Module (z.B. spezielle PCI Karten, SmartCards) oder auch remote PSE's mit zertifizierten geschlossen Blackboxsystemen genutzt werden. Für Firmen ist es möglich den Verwaltungsaufwand enorm zu verkleinern durch die Nutzung von Domainzertifikaten. Hierbei wird pro Emaildomain nur ein privates Zertifikat benutzt.
Use Cases
Es gibt viele konkrete Szenarien in denen Emailsicherheit empfehlenswert oder sogar geschäftskritsche Notwendigkeit ist. Für die spezielle Form der serverbasierten Variante wären folgende zu nennen:
- Viren/SPAM filtern in verschlüsselten Emails
- Digitale Signatur als Schutz vor Phishing
- Übermittlung kritischer Daten verschlüsselt per Mail (auch automatisiert und in großen Mengen)
- Durchsetzung zentraler Regeln zur Anwendung von Kryptografie (z.B. Verbot interner Verschlüsselung zur Informationsflusskontrolle)
OSMS - OpenSecurityMailServer
Im folgenden wird Schritt für Schritt der Aufbau eines aktuell modernen (möglichst) sicheren Mailservers auf Basis von OpenSuSE 10 beschrieben. Bei Verdopplung des hier beschriebenen Systems und entsprechender Konfigurationsanpassung auf eine 2. Domain und IP kann damit ein vollständiges Server2Server Mailroutingszenario abgebildet und getestet werden. Das Verhalten der verschiedenen Sicherheitskomponenten kann eindrucksvoll im Zusammenspiel beobachtet werden. Ebenfalls möglich ist der Nachbau dieses fullfeatured Mailservers auf entsprechender Zielhardware zu Performancemessungen. Das Setup basiert teilweise auf der Beschreibung von Genco YILMAZ.
Aufbau Mailserver
Die Basiskomponenten des Systems sind:
- Betriebssystem: OpenSuSE 10
- Datenbank: PostgreSQL
- MTA: Postfix 2.2 + SASL AUTH + TLS
- IMAP/POP: Courier IMAPs/POPs
- Webmail: Squirrelmail
- Security: SecureMail Gateway 2.3 von Zertificon Solutions (OpenSSL, GnuPG, Bouncycastle)
- Virenfilter: ClamAV über amavisd-new
- SpamFilter: SpamAssassin über amavisd-new
Betriebssystem Setup
- CD 1 oder DVD 1 einlegen und booten vom Medium
- Auswahl Bootscreen: <Installation>
- Language: Deutsch
- Medienpruefung: <Weiter>
- Lizenz: Ja + <Weiter>
- Uhr und Zeitzone: Europa + Deutschland + Lokale Zeit + <Weiter>
- Desktop: Andere + Textmodus + <Weiter>
- Installationseinstellungen: <Uebernehmen>
- Installation bestaetigen: <Installieren>
- nach reboot CD 5 einlegen falls zur Hand ansonsten: <Ueberspringen> + <Ignorieren>
Basiskonfiguration
- root Passwort setzen
- Netzwerkkonfiguration:
- Aendern -> Firewall -> Erlaubte Dienste hinzufuegen fuer die externe Zone:
DHCP-Client (bei Bedarf), HTTPS,IMAPS,POP3S,SSH,Mailserver
- Aendern -> Netzwerkschnittstellen -> Bearbeiten:
Konfigurationsmethode, falls statische IP entsprechend eintragen Hostname, Domain, Nameserver, Defaultroute entsprechend Umgebung eintragen <Weiter>,<Weiter>
- Test der Internetverbindung: "Nein" <Weiter>
- Methode zur Benutzer-Authentifikation: Lokal (/etc/passwd) <Weiter>
- Neuer Benutzer: <Weiter>,<Ja>
- Hinweise zur Version: <Weiter>
- Hardwarekonfiguration: <Weiter>
- Installation abgeschlossen: <Beenden>
Remotezugang freischalten
als root auf der Konsole anmelden:
vi /etc/ssh/sshd_config: PermitRootLogin yes
/etc/init.d/sshd restart
Absofort kann die weitere Installation remote ueber eine SSH Sitzung durchgefuehrt werden!
Installation aller Pakete und Onlineupdate
(das Onlineupdate steht für OpenSuSE noch nicht zur Verfügung und muss hier noch ergänzt werden)
Installationsquelle fuer Netzinstallation hinzufuegen
Hinweis: bei lokalem DVD oder CD Satz nicht notwendig!
1. yast starten als root user 2. Falls notwendig proxy einrichten unter Netzwerkdienste -> Proxy-Server:
(x) Aktivieren, z.B.: http://proxy.domain.loc:3128
3. Software -> Installationsquelle wechseln -> Hinzufuegen:
http://download.opensuse.org/distribution/SL-OSS-current/inst-source http://download.opensuse.org/distribution/SL-OSS-current/inst-source-java/ <yes>
4. Mit <Auf> die neue Quelle in der Liste nach oben verschieben.
Jetzt koennen beliebige Pakete ohne Installationsmedien hinzugefuegt werden.
Notwendige Softwarepakete installieren
System:
yast -i xntp wget findutils-locate
SecureMail:
yast -i postgresql postgresql-server patch sudo XFree86-libs libtool
Postfix:
yast -i postfix-postgresql postgresql-libs
Cyrus SASL Authentication for SMTPD:
yast -i mysql-shared postgresql-libs cyrus-sasl-sqlauxprop
Courier (and dependencies):
yast -i courier-authlib courier-imap expect fam libtool tcl fam-server
Squirrelmail (and dependencies):
yast -i apache2-prefork apache2 apache2-mod_auth_mysql apache2-mod_php5 php5-gettext php5-iconv \ php5-mbstring php5-openssl ispell-american squirrelmail squirrelmail-plugins php5-pgsql
Content Filter:
yast -i amavisd-new spamassassin clamav clamav-db
oder alles zusammen mit:
yast -i xntp wget findutils-locate postgresql postgresql-server patch sudo XFree86-libs libtool \ postfix-postgresql postgresql-libs mysql-shared cyrus-sasl-sqlauxprop courier-authlib courier-imap \ expect fam tcl fam-server apache2-prefork apache2 apache2-mod_auth_mysql apache2-mod_php5 php5-gettext \ php5-iconv php5-mbstring php5-openssl ispell-american squirrelmail squirrelmail-plugins amavisd-new \ spamassassin clamav clamav-db php5-pgsql
Alle neuinstallierten Services in den Runleveln verlinken:
for d in saslauthd spamd freshclam clamd amavis ntp apache2 fam courier-authdaemon courier-imap-ssl courier-pop-ssl do chkconfig --add $d done
Manuelles Hinzufuegen von phpPgAdmin:
cd /srv/www/htdocs/ && \ wget http://mesh.dl.sourceforge.net/sourceforge/phppgadmin/phpPgAdmin-3.5.5.tar.bz2 && \ tar xvjf phpPgAdmin-3.5.5.tar.bz2 && \ rm phpPgAdmin-3.5.5.tar.bz2
Das courier-authlib RPM muss neugebaut werden für die PostgreSQL Anbindung. Dazu können die SuSE Source Pakete genutzt werden. Hier sind meine nicht speziell gekennzeichneten oder versionierten RPMs für den Schnelltest und als Vorlage. Der Courier-IMAP Server unterstützt noch kein PostgreSQL, das kann mit folgenden Paketen nachinstalliert werden:
Courier Authlib RPM mit PGSQL support Courier Authlib SRPM mit PGSQL support
Selbermachen geht so:
- courier-authlib source RPM installieren (z.B. im yast suchen und dann Aktionen->Quellen installieren -> Weiter)
- Notwendige Pakete zum Kompilieren nachinstallieren:
yast -i postgresql-devel bison cvs flex gdbm-devel gettext-devel glibc-devel m4 ncurses-devel rcs strace \ texinfo unzip zlib-devel autoconf automake gcc gcc-c++ libstdc++-devel openldap2-devel pam-devel
- Anpassen von /usr/src/packages/SPECS/courier-authlib.spec:
beim configure (Zeile 80) hinzufuegen: --with-pgsql-libs=/usr/lib \ --with-pgsql-includes=/usr/include/pgsql \ --with-authpgsql \ in der %files section (Zeile 150): %{_libdir}/libauthpgsql.so.0*
- Neues RPM erzeugen:
rpmbuild -ba /usr/src/packages/SPECS/courier-authlib.spec
- Neues RPM installieren:
rpm --force -U /usr/src/packages/RPMS/i*86/courier-authlib-0.*.i*86.rpm
- Entfernen der devel Pakete:
rpm -e postgresql-devel bison cvs flex gdbm-devel gettext-devel glibc-devel m4 ncurses-devel rcs \ strace texinfo unzip zlib-devel autoconf automake gcc gcc-c++ libstdc++-devel openldap2-devel \ pam-devel pango gtk2 cairo autoconf texinfo atk libgcj cyrus-sasl-devel
SecureMail Gateway installieren
Release auspacken:
tar xvzf smgw-2_3_0-gw-build0150-suse-i386.tar.gz
Anpassungen zur Installation auf OpenSuSE 10:
cd smgw-2_3_0-gw-build0150-suse-i386 perl -pi -e 's/_IDS="SUSE LINUX Enterprise Server/_IDS="SUSE LINUX/;s/-eq 9/-ge 9/' install.sh perl -pi -e 's/_VERSIONS=9/_VERSIONS="9\t10"/' install/makeenv
Installation starten:
./install.sh
Eingaben zur Installation: Netzwerke zur Firewallkonfiguration aus denen auf das SMGW zugegriffen wird (SSH + WWW) z.B.
NETWORKS = 192.168.0.0/24
Mailrouting (yes auswaehlen): die 1. zu konfigurierende Domain auswaehlen z.B.
Domain name: company1.loc Recipient domains: Internal mail server: External smartrelay:
Runlevel Links erstellen mit:
chkconfig --add smgw
Konfiguration
Zeitsynchronisation (NTP)
Eine exakte Zeit ist fuer digitale Signaturen und Zertifikatsvalidierung zwingend notwendig.
vim /etc/ntp.conf
server ntp1.ptb.de server ntps1-0.cs.tu-berlin.de server ntp2.ptb.de server ntps1-1.cs.tu-berlin.de
/etc/init.d/ntp restart
User/Gruppen
groupadd -g 1001 vmail useradd -g 1001 -u 1001 -d /home/vmail -m -c 'Virtual Mailsystem User' vmail
Datenbank Virtuelle Domain/User Konfiguration
/etc/init.d/postgres start
Als Datenbank User weiterarbeiten:
su - postgres
Zugriffsrechte anpassen:
perl -pi -e 's/(.*?127\.0\.0\.1.*?)ident sameuser/$1md5/g' $PGDATA/pg_hba.conf pg_ctl reload
Mail Datenbank erstellen:
psql -c "create user vmailuser with password 'changeIT' createdb createuser" template1 psql -U vmailuser -h 127.0.0.1 -p 5432 -c "create database mail with encoding = 'unicode'" template1 psql -U vmailuser -h 127.0.0.1 -p 5432 -d mail < create_tables.sql
Beispieldaten hinzufügen:
postgres@osms:~> psql -U vmailuser -h 127.0.0.1 -p 5432 -d mail -c "\ INSERT INTO postfix_users (email,clear,name,homedir,maildir,quota) VALUES ('alice@company1.loc','alice','Alice','/home/vmail/','company1.loc/alice/Maildir/','10000000') ;"
Erstellen des Mailverzeichnisses fuer den neuen User:
osms:~ # su - vmail vmail@osms:~> mkdir -p company1.loc/alice vmail@osms:~> maildirmake company1.loc/alice/Maildir vmail@osms:~> maildirmake -q 10000000S company1.loc/alice/Maildir
Einrichten von phpPgAdmin zur Pflege der MTA Daten:
osms:/srv/www/htdocs/phpPgAdmin # cp conf/config.inc.php-dist conf/config.inc.php osms:/srv/www/htdocs/phpPgAdmin # vim conf/config.inc.php
$conf['servers'][0]['desc'] = 'Postfix/Courier Backend'; $conf['servers'][0]['host'] = '127.0.0.1'; $conf['servers'][0]['port'] = 5432; $conf['servers'][0]['defaultdb'] = 'template1'; $conf['servers'][0]['pg_dump_path'] = '/usr/bin/pg_dump'; $conf['servers'][0]['pg_dumpall_path'] = '/usr/bin/pg_dumpall';
/etc/init.d/apache2 restart
Anmelden ist dann ueber http://192.168.0.170/phpPgAdmin/ als vmailuser (pass: changeIT) moeglich. Ueber die WebGUI koennen nun weitere User/Domains hinzugefuegt werden. In groesseren Installationen koennen natuerlich spezielle Mailverwaltugnen direkt auf das SQL Backend zugreifen. Eine Integration ist dadurch leicht moeglich, ebenso ein Verteilung der Daten auf mehrere MTA Instanzen.
Postfix
TLS
SMTPD Server SSL Zertifikat erzeugen. Fuer ein Produktivsystem sollte hier natuerlich eine echte CA genutzt werden.
osms:/etc/postfix # openssl req -x509 -newkey rsa:1024 -keyout postfix.pem -out postfix.pem -nodes -days 365 Generating a 1024 bit RSA private key ----- Country Name (2 letter code) [AU]:DE State or Province Name (full name) [Some-State]:Berlin Locality Name (eg, city) []:Berlin Organization Name (eg, company) [Internet Widgits Pty Ltd]:Company 1 Organizational Unit Name (eg, section) []:Secure Emailadministration Common Name (eg, YOUR name) []:osms.domain.loc Email Address []:
Einstellungen in /etc/postfix/main.cf:
smtpd_use_tls = yes smtpd_tls_cert_file = $config_directory/postfix.pem smtpd_tls_key_file = $smtpd_tls_cert_file smtpd_tls_auth_only = yes
SASL/SMTP AUTH
Einstellungen in /etc/postfix/main.cf:
smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous smtpd_sasl_local_domain = $myhostname broken_sasl_auth_clients = yes smtpd_sasl_application_name = smtpd
osms:/etc/postfix # vim /usr/lib/sasl2/smtpd.conf
pwcheck_method: auxprop auxprop_plugin: sql mech_list: plain login
sql_engine: pgsql sql_hostnames: localhost sql_user: vmailuser sql_passwd: changeIT sql_database: mail sql_select: select clear from postfix_users where email='%u@%r' and smtpaccess='Y'
Lookup Tables
Die standardmäßig als normale Dateien zur Verfügung gestellten Map/Lookup Tabellen sind in die Datenbank verlagert worden, um weitere Applikationen darauf aufzusetzen und eine Verteilung in großen geclusterten Installationen zu gewährleisten. Die einzelnen Tabellen werden separat konfiguriert.
Postfix erfährt über die /etc/postfix/main.cf die Konfigurationsdateien:
check_client_access pgsql:/etc/postfix/pgsql-client.cf check_sender_access pgsql:/etc/postfix/pgsql-sender.cf check_recipient_access pgsql:/etc/postfix/pgsql-recipient.cf alias_maps = pgsql:/etc/postfix/pgsql-aliases.cf relocated_maps = pgsql:/etc/postfix/pgsql-relocated.cf transport_maps = pgsql:/etc/postfix/pgsql-transport.cf virtual_mailbox_domains = pgsql:/etc/postfix/pgsql-virtual-domains.cf virtual_alias_maps = pgsql:/etc/postfix/pgsql-virtual.cf virtual_mailbox_maps = pgsql:/etc/postfix/pgsql-virtual-maps.cf virtual_uid_maps = pgsql:/etc/postfix/pgsql-virtual-uid.cf virtual_gid_maps = pgsql:/etc/postfix/pgsql-virtual-gid.cf
Die einzelnen Dateien befinden sich in der archivierten Postfix Konfiguration.
Routing
Das Mailrouting wird hauptsächlich durch die in der master.cf konfigurierten Services beeinflusst.
Folgende Grundideen sind hierbei umgesetzt:
- Separierung von innen und außen Bereich durch Port 25 SMTPD auf unterschiedlichen IP Adressen (im aktuellen Beispiel außen: 192.168.0.170 innen 192.168.0.171)
- auf beiden Eingängen ist TLS aktiv
- an der inneren Schnittstelle wird TLS erzwungen (für Clients die dies nicht unterstützen z.B. squirrelmail wird der separate smtps Port 465 geöffnet)
- SMTP AUTH ist am inneren Eingang Pflicht
- ein before-queue amavisd Filter führt adhoc Viren/SPAM checks durch, die zum REJECT der Mail führen können
- das SMGW sorgt für automatische Ver/Entschlüsselung, Signatur/Verifikation
- anschließend wird nochmals ein Viren/SPAM check durchgeführt (damit werden eingangs verschlüsselte Viren und auch SPAM gefiltert!)
Die main.cf und master.cf befinden sich in der archivierten Postfix Konfiguration.
Courier
Auth
Zur Authentifizierung wird das Paket courier-authlib benutzt und muss zur Anbindung an die User Datenbank konfiguriert werden.
vim /etc/authlib/authdaemonrc:
authmodulelist="authpgsql authpam"
vim /etc/authlib/authpgsqlrc:
PGSQL_HOST localhost PGSQL_PORT 5432 PGSQL_USERNAME vmailuser PGSQL_PASSWORD changeIT PGSQL_DATABASE mail PGSQL_USER_TABLE postfix_users PGSQL_CRYPT_PWFIELD crypt PGSQL_CLEAR_PWFIELD clear PGSQL_UID_FIELD uid PGSQL_GID_FIELD gid PGSQL_LOGIN_FIELD email PGSQL_HOME_FIELD homedir PGSQL_NAME_FIELD name PGSQL_MAILDIR_FIELD maildir PGSQL_QUOTA_FIELD quota PGSQL_AUXOPTIONS_FIELD 'disableimap=' || disableimap || ',disablepop3=' || disablepop3 || ', disablewebmail=' || disablewebmail || ',sharedgroup=' || sharedgroup PGSQL_WHERE_CLAUSE access='Y'
chmod 400 /etc/authlib/authpgsqlrc
/etc/init.d/courier-authdaemon restart
IMAP/POP
Create SSL certs: vim /etc/courier/pop3d.cnf:
[ req_dn ] C=DE ST=B L=Berlin O=Courier POP3 Server OU=Automatically-generated POP3 SSL key CN=localhost emailAddress=postmaster@domain.loc
vim /etc/courier/imapd.cnf:
[ req_dn ] C=DE ST=B L=Berlin O=Courier IMAP Server OU=Automatically-generated IMAP SSL key CN=localhost emailAddress=postmaster@domain.loc
Prozesse starten mit:
/etc/init.d/fam start /etc/init.d/courier-pop-ssl start /etc/init.d/courier-imap-ssl start
Squirrelmail Webmailer
Die Konfiguration auf eigene Daten anpassen:
/srv/www/htdocs/squirrelmail/config/conf.pl
http://192.168.0.170/squirrelmail/
Name: alice@company1.loc Password: alice
Z1 SecureMail Gateway
- Lizenz einspielen
- Relay IPs anpassen
- Policy einstellen
Der Anwendung liegt eine sehr gute Dokumentation bei. Entweder über die Weboberfläche unter "Documentation" oder im Dateisystem: ``/opt/tbone/doc/Z1_SMGW_03_System_Guide.pdf``.
Anwendung und Testfälle
Fazit
Weiterführende Links
Internet Mail Consortium: S/MIME and OpenPGP
Z1 SecureMail Gateway
Teletrust e.V. (inkl. ISIS-MTT Spezifikation)
Tutorial: ISP-ähnlicher Email Service mit Debian-Sarge und Postfix 2.1
1. Autor: Ingo Kampe (Signierte Emails an kampe@...)