Im Klinikum St. Marien wird das Ticketsystem seit 2005 in der EDV

Praktikumsbericht
Name:
Michael Schrüfer
Matrikel Nr.:
2667118
Unternehmen: Klinikum St. Marien Amberg
Michael Schrüfer
Matnr.: 2667118
Seite 1 von 38
Inhaltsverzeichnis
Abkürzungsverzeichnis .................................................................................................................. 3
1.
2.
3.
4.
5.
Einführung ............................................................................................................................. 4
1.1.
Das Klinikum St. Marien Amberg................................................................................... 4
1.2.
Die IT Abteilung des Klinikums St. Marien .................................................................... 5
Erweiterung OTRS Helpdesksystem ...................................................................................... 7
2.1.
OTRS .............................................................................................................................. 7
2.2.
Aufgabendefinition........................................................................................................ 8
2.3.
Analyse der Lösungsmöglichkeiten ............................................................................... 9
2.4.
Implementierung der Lösung ........................................................................................ 9
2.5.
Test und Übergabe ...................................................................................................... 11
Aktualisierung des Mailhubs zur Spam- und Virenabwehr ................................................. 12
3.1.
Ist-Analyse ................................................................................................................... 12
3.2.
Aufgabendefinition...................................................................................................... 13
3.3.
Implementierung und Konfiguration der Lösung ........................................................ 13
3.4.
Test und Inbetriebnahme ............................................................................................ 21
Erleichterung der Administration des Mailhubs ................................................................. 22
4.1.
Aufgabendefinition...................................................................................................... 22
4.2.
Analyse der am Markt existierende Lösungen ............................................................ 22
4.3.
Implementierung konsolenbasierte Skripte................................................................ 23
4.4.
Implementierung einer php-Administrationsmaske ................................................... 24
Sonstiges ............................................................................................................................. 28
5.1.
Netzwerkmanagement mit Cisco Prime...................................................................... 28
5.2.
Planung eines Oracle Real Applicantion Cluster (RAC) ............................................... 29
6.
Anhang ................................................................................................................................ 30
7.
Literaturverzeichnis ............................................................................................................. 38
Michael Schrüfer
Matnr.: 2667118
Seite 2 von 38
Abkürzungsverzeichnis
OTRS
SSH
LDAP
AD
DB
SOAP
MUA
MTA
MX
DMZ
DNS
NTP
NRPE
AMaViS
APT
SMTP
TCP
RBL
FQDN
POP3
IMAP
RAV
SNMP
RAC
ASM
Michael Schrüfer
Open Ticket Request System
Secure Shell Host
Lightweight Directory Access Protocol
Active Directory
Datenbank
Simple Object Access Protocol
Mail User Agent
Mail Transfer Agent
Mail Exchanger
Demilitarisierte Zone
Domain Name Service
Network Time Protocol
Nagios Remote Plugin Executor
A Mail Virus Scanner
Advanced Packaging Tool
Simple Mail Transfer Protocol
Transmission Control Protocol
Realtime Blackhole Lists
Fully Qualified Domain Name
Post Office Protocol Version 3
Internet Message Access Protocol
Recipient address verification
Simple Network Management Protokoll
Real Applicantion Cluster
Automatic Storage Manager
Matnr.: 2667118
Seite 3 von 38
1. Einführung
1.1. Das Klinikum St. Marien Amberg
Das Klinikum St. Marien Amberg wurde 1850 als „Marienspital zu Amberg“ gegründet. Das zu
Beginn mit 50 Betten ausgestattete Spital entwickelte sich in den vergangenen 162 Jahren zu
einem modernen Klinikum und nimmt eine zentrale Stellung in der Krankenversorgung der
Region ein. Das Haus der Versorgungsstufe 3 (Schwerpunktversorgung) beherbergt folgende
Fachabteilungen und Institute: Klinik für Innere Medizin I und II, Allgemein-, Visceral-, Thoraxund Gefäßchirurgie, Unfallchirurgie und Orthopädie, Neurochirurgie, Gynäkologie und
Geburtshilfe, Pädiatrie, Urologie, Geriatrie und Frührehabilitation ,Neurologie, Anästhesiologie
und operative Intensivmedizin, Strahlentherapie sowie das Institut für diagnostische und
interventionelle Radiologie. Durch verschiedene Zentren und die damit verbundene
interdisziplinäre Zusammenarbeit wird eine ganzheitliche Betreuung der Patienten
gewährleistet. Das Klinikum wird seit 2004 als Kommunalunternehmen (Anstalt des
öffentlichen Rechts der Stadt Amberg) betrieben. 2005 wurde das Gesundheitszentrum St.
Marien GmbH als 100 prozentige Tochtergesellschaft des Klinikums gegründet. Diese
Einrichtung ermöglicht dem Klinikum das Angebot einer ambulanten Versorgungsform in enger
Kooperation mit den bereits verfügbaren Ressourcen des Hauses, sowie mit niedergelassenen
Ärzten. Um eine möglichst hohe Qualität der Pflege sicherstellen zu können, betreibt das
Klinikum eine eigene Krankenpflegeschule, an der sich aktuell knapp 100 junge Menschen in
der Ausbildung befinden. Neben der pflegerischen Ausbildung ist das Klinikum in der Funktion
als akademisches Lehrkrankenhaus der Universität Erlangen-Nürnberg sowie der Universität
Regensburg auch für die ärztliche Ausbildung mitverantwortlich. Weitere Kooperationen, wie
z.B. mit der Hochschule Amberg-Weiden sichern dem Klinikum den Zugang zu neuen
Technologien und sollen dem prognostizierten Fachkräftemangel vorbeugen. Die Einhaltung
der durch den Gesetzgeber geforderten Qualitätssicherungsmaßnahmen bewies das Klinikum
dieses Jahr wiederholt durch die Zertifizierung durch die KTQ (Kooperation für Transparenz
und Qualität im Gesundheitswesen GmbH) mit einem überdurchschnittlich guten Ergebnis. Die
permanenten Veränderungen der vergangenen Jahre im Gesundheitssystem stellen auch für
ein Krankenhaus mittlerer Größe mit 574 Betten eine wirtschaftliche Herausforderung dar.
Eine genaue Planung und die Erfassung und Analyse medizinisch/wirtschaftlicher Kennzahlen
sind für den Erhalt jeder medizinischen Einrichtung unabdingbar. Im vergangenen
Geschäftsjahr wurden 26 000 stationäre und knapp 38 000 ambulante Fälle behandelt. Die
durchschnittliche Verweildauer sank im Vergleich zum Vorjahr um 0,07 Tage auf 6,89. Der
durchschnittliche Schweregrad (CMI) der Fälle lag bei 1,005. Eine im Trend der vergangenen
Jahre liegende Steigerung der Auslastung der Bettenkapazitäten von 83.45 führte zu diversen
zum Teil noch im Bau befindlichen Erweiterungsmaßnahmen. Trotz dieser, zu einem großen
Teil aus Eigenmitteln finanzierten Investitionen gelang es, ein zufriedenstellendes Ergebnis am
Ende des Geschäftsjahres auszuweisen. Dabei galt es auch die gestiegenen Personalkosten
durch eine Fallzahlsteigerung von 1,276 % auszugleichen. Mit knapp 1500 Beschäftigten stellt
das Klinikum den zweitgrößten Arbeitgeber der Region dar. Vertreten wird das Klinikum durch
den Vorstand Herrn Manfred Wendl. Dieser bildet zusammen mit Herrn Prof. Dr. Helmut
Wollschläger als ärztlicher Direktor, Herrn Hubert Graf als Verwaltungsleiter und Frau Kerstin
Wittmann als Pflegedirektorin das Leitungsgremium des Klinikums.
Michael Schrüfer
Matnr.: 2667118
Seite 4 von 38
1.2. Die IT Abteilung des Klinikums St. Marien
Die IT Abteilung als eine noch verhältnismäßig junge Abteilung des Klinikums stellt die gesamte
IT Infrastruktur als interner Dienstleister für das Klinikum zur Verfügung. Dabei ist eine immer
engere Verschmelzung der reinen IT-Systeme mit den medizinisch-technischen Geräten zu
beobachten. Dies führt zu einer engen Kooperation der IT mit anderen Abteilungen, wie z.B.
der Medizin- oder Elektrotechnik.
Als vor 25 Jahren das EDV Zeitalter im Klinikum begann, betreute der spätere EDV Leiter 2
Computer in der Verwaltung. Aus dieser Ein-Mann Abteilung ist zwischenzeitlich eine 15 Mann
starke Gruppe geworden, die über 700 Client-, 150 Server- und 100 verschiedenste
Softwaresysteme betreut. Die Aufgaben innerhalb der Abteilung gliedern sich in das Tagesund das Projektgeschäft. Das Tagesgeschäft umfasst die Client- und Anwenderbetreuung
sowie die Behebung von Problemen und die Wartungen an zentralen Systemen. Der
Arbeitsablauf für das Tagesgeschäft wird primär über ein Helpdesk System organisiert, in dem
Störmeldungen erfasst, verwaltet, abgearbeitet und ausgewertet werden. Im Projektgeschäft
werden zeitlich oder durch den Umfang begrenzte Aufgaben, z.B. die Einführung neuer
Softwaresysteme durchgeführt. Mitarbeiter werden davon für hierfür vom Tagesgeschäft
entsprechend freigestellt.
Wo aufgrund der Vielzahl verschiedener sehr spezialisierter Anwendungen kein entsprechend
tiefes Verständnis der Software bei den eigenen Mitarbeitern erreicht werden kann, wird der
Second-Level Support direkt an die Herstellerfirma outgesourced.
Neben der engen Zusammenarbeit mit den Herstellerfirmen verschiedenster SoftwareProdukte ist eine zunehmende Kooperation der EDV Abteilungen verschiedener medizinischer
Einrichtungen zu beobachten. Wird in der Presse über eine Zusammenarbeit zwischen
Krankenhäuser oder niedergelassenen Ärzten berichtet, so bildet die EDV Vernetzung in den
meisten Fällen die Grundlage und Basis des Daten- und Informationsaustausches. Während
sich Anforderungen früher auf die Übertragung von Bilddaten über Dicom o.ä. beschränkten,
haben sich heute bereits Einweiserportale oder Videokonferenzsysteme zur interdisziplinären
Zusammenarbeit etabliert.
Die im klinischen Umfeld eingesetzte Software muss hohe Anforderungen an Verfügbarkeit,
Sicherheit und Datenschutz erfüllen. Außerdem ist eine überdurchschnittlich hohe Flexibilität
bei der Einführung neuer Software notwendig. Neue Systeme müssen kostengünstig, zeitnah,
hochverfügbar bereit gestellt werden können. Um diese Anforderungen erfüllen zu können,
hat man sich vor 6 Jahren zur Virtualisierung der Bereiche Server, Netzwerk und
Speichersysteme entschieden. Kern der Netzwerkinfrastruktur und damit Basis des gesamten
Datenverkehrs bilden 2 redundante Catalyst 6500, die in einem Virtual Switch System (VSS)
1440-Verbund der Firma Cisco arbeiten. Im Storage Bereich stehen 2 redundante Storage
Server zur Verfügung. Als Hardware dahinter dienen je Storage Server 4 SX100 der Firma
Fujitsu als permanente Datenablage. Die einzelnen Shelfs wurden mit verschiedenen
Festplatten abhängig vom Anwendungszweck ausgestattet. Die Virtualisierungsschicht auf den
2 Storage Servern wurde mit der Software SANMelody der Firma DataCore realisiert. Diese
präsentiert die logischen Volumes über eine FibreChannel SAN Infrastruktur den Servern. In
Michael Schrüfer
Matnr.: 2667118
Seite 5 von 38
dem in der Öffentlichkeit wohl bekanntesten Virtualisierungsbereich - der Servervirtualiserung
- wird im Klinikum das Produkt der Firma VMWare eingesetzt. Die Version 5 der Software läuft
sowohl auf den ESX-Hosts, als auch am Virtual Center, welches für die Verwaltung der
verschiedenen Komponenten verantwortlich ist. Bei dem Umstieg auf die nächste
Hardwaregeneration der ESX Server sollen die bisher einzelnen Server (Fujitsu RX 600) aus
Kosten- und Verwaltungsgründen durch Blade Server ersetzt werden. Die Komponenten
wurden in allen Bereichen redundant ausgelegt, und physikalisch in 2 verschiedenen
Serverräumen in unterschiedlichen Brandabschnitten untergebracht. Um selbst im
Katastrophenfall Datenverlust zu vermeiden, werden Sicherungen in einem weiteren, dritten
Raum abgelegt. Vor 2 Jahren wurde im Klinikum ein flächendeckendes WLAN installiert. Neben
Datendiensten wird das WLAN hauptsächlich für die Telefonie genutzt. In Zukunft soll das
System außerdem zur Ortung von Patienten und Geräten dienen. Alle Bereiche des Netzwerks
wurden mit Komponenten der Firma Cisco ausgestattet.
Die im Klinikum eingesetzten Softwareprodukte lassen sich grob in Medizinische Software,
Verwaltungssoftware und Infrastruktursoftware einteilen. Eines der wichtigsten Systeme stellt
das Klinikum Information System (KIS), Micom Medicare der Firma Nexus da. In ihm wird der
gesamte Behandlungsworkflow, von der Aufnahme des Patienten, bis zur Leistungsabrechnung
abgebildet. Als nummernführendes System kann es als zentrale Patientendatenbank
verstanden werden. Alle medizinischen Subsysteme müssen relevante Daten über definierte
Schnittstellen (HL7) erhalten. Die Kommunikation zwischen dem KIS und den verschiedensten
Sub- und Spezialsystemen wird von hochverfügbar ausgelegten Schnittstellenservern
abgewickelt. Eines der umfangreichsten Subsysteme wird der Radiologie zur Verfügung
gestellt. Sowohl als Verwaltungssoftware (RIS) als auch als Bildspeicher kommen Produkte der
Firma Siemens (Syngo) zum Einsatz. Da in der Radiologie keine Bilder mehr „ausgedruckt“
werden, muss die Organisation und Ablage der Daten hohe Anforderungen an die
Datensicherheit erfüllen. Weitere spezialisierte Subsysteme finden sich in so gut wie jeder
Fachabteilung. Probleme mit denen sich aktuell wohl jede Klinik-IT befasst, sind einerseits die
fachabteilungsübergreifende Darstellung des Datenmaterials, andererseits die sichere
Archivierung der Daten. Im Verwaltungsbereich wird neben Medicare hauptsächlich SAP für
die Finanzbuchhaltung und Lagerverwaltung eingesetzt. Im medizinisch-administrativen
Bereich hat man sich anstelle des vom Funktionsumfang sehr breit aufgestellten SAP, für das
ausschließlich für den medizinischen Bereich entwickelte Nexus Medicare entschieden. Basis
des Infrastrukturbereichs bildet das Microsoft Active Directory. Alle Benutzer werden in dieser
zentralen Instanz gepflegt. Um Anwendern einen möglichst großen Komfort bei der
Anmeldung bieten zu können, wird bei der Einführung neuer Software auf die
Integrationsfähigkeit z.B. durch LDAP oder Kerberos geachtet. Sofern möglich, wird dabei auf
OpenSource Software zurückgegriffen. Diese bietet neben dem Kostenvorteil eine hohe
Flexibilität durch eigene Anpassungen.
Michael Schrüfer
Matnr.: 2667118
Seite 6 von 38
2. Erweiterung OTRS Helpdesksystem
2.1. OTRS
OTRS (Open Ticket Request System) ist ein webbasiertes Ticketsystem. Es beruht auf den
Programmiersprachen Perl sowie JavaScript und ist als Open Source Software frei verfügbar.
Die Unterstützung verschiedenster Servertechnologien macht OTRS in vielen Umgebungen
einsetzbar. So werden neben dem freien Datenbanksystem MySQL auch die Produkte der
kommerziellen Hersteller wie Oracle oder Microsoft als persistente Datenablage unterstützt.
Ebenso spielt es für OTRS keine Rolle, ob der Webserver unter Windows, Unix, Linux oder Mac
OS läuft.
Das System bietet je nach Aufgabenrolle (Problemmelder oder –bearbeiter) verschiedene
Bereiche an. Neben einem Modul für den Ticket-Bearbeiter (in OTRS als Agent bezeichnet),
existiert ein Kundenbereich über den der Anwender selbst Probleme melden und gemeldete
Probleme verwalten kann. Jede Problemmeldung wird von OTRS als ein Ticket mit eindeutiger
Identifikationsnummer gespeichert. Die verschiedenen Arbeits- und Aufgabenbereiche können
in OTRS mit sogenannten Queues abgebildet bzw. gegliedert werden. Jedes Ticket muss zu
jedem Zeitpunkt einer Queue zugewiesen sein. Einer Queue ist wiederum mindestens ein, in
der Regel jedoch mehrere Agents zugewiesen, die die für sie jeweils relevanten Tickets durch
Sperren aus der öffentlichen Queue entfernen und somit für die eigene Bearbeitung
markieren. Dadurch kann verhindert werden, dass sich 2 Bearbeiter um das gleiche Problem
kümmern. Weitere Funktionen, wie das Verschieben zwischen Queues und Bearbeitern oder
das Zusammenführen von Tickets, sorgen für eine flexible aber auch saubere Ticketverwaltung.
Wichtige Features zur Kommunikation mit dem Problemmelder sind Notizen und Antworten.
Notizen können sowohl für die interne Dokumentation zwischen den Bearbeitern als auch für
die externe Kommunikation mit dem Kunden genutzt werden. Über Antworten lässt sich ein
Dialog zwischen Bearbeiter und Problemmelder realisieren. Diese können vom Kunden über
die identischen Wege, wie die eigentliche Problemmeldung, an das Ticket angefügt, und dem
Bearbeiter zugestellt werden. Neben dem bereits erwähnten Customer Bereich existiert die
sehr unkomplizierte und schnelle Möglichkeit, Nachrichten per Mail an das Ticketsystem zu
senden. Da OTRS keine direkte SMTP Schnittstelle für den E-Mail Empfang bereit stellt, werden
eingehende Mails auf einem POP3 Server gesammelt, und von dort aus via Cron Job abgeholt.
Für die abgeholten Mails wird automatisch ein Ticket in der davor statisch oder dynamisch
konfigurierten Queue angelegt. Dies ermöglicht eine vollständige Aufzeichnung der gesamten
Agent-Kunden-Kommunikation. Wichtige Informationen sind so nicht mehr in persönlichen, für
andere nicht zugänglichen Outlook Postfächern, sondern zentral für alle einsehbar.
Insbesondere im Krankheits- oder Vertretungsfall können sich Kollegen so einen schnellen
Überblick über den bisherigen Ticketverlauf verschaffen. Um auch den Kunden über den Stand
seiner Problemmeldung auf dem Laufenden zu halten, werden z.B. beim Öffnen, Verschieben
und Schließen aktionsgetriggert „automatische Antworten“ an den Kunden per Mail versendet,
die ihn über den aktuellen Bearbeitungsstand informieren.
OTRS bietet eine Vielzahl vorimplementierter Möglichkeiten, um das System an die jeweilige
Umgebung anzupassen. Als eine der wichtigsten ist das Dynamic Field Feature zu nennen, mit
dessen Hilfe sich neue Felder, und somit weitere Informationen dem Ticket hinzufügen lassen.
Ebenso lassen sich Kundeninformationen erweitern, um für etwaige Rückfragen alle Daten
Michael Schrüfer
Matnr.: 2667118
Seite 7 von 38
direkt parat zu haben. Insgesamt bietet OTRS über 1400 Konfigurationsparameter, die für den
Regelbetrieb eine ausreichende Flexibilität zur Anpassung bereitstellen. Bei tiefergreifenden
Änderungen oder Erweiterungen kann der Quellcode direkt geändert werden, oder interne
Funktionen durch das Generic Interface von außen durch Eigenentwicklungen genutzt werden.
Im Klinikum St. Marien wird das Ticketsystem seit 2005 in der EDV Abteilung und in Teilen der
Öffentlichkeitsarbeit eingesetzt. Nach diversen Updates und Erweiterungen wird es aktuell in
der Version 3.1.8 betrieben. Die Basis des Systems bildet eine virtuelle Maschine mit dem
Betriebssystem Linux Debian 6.0.6. Sowohl der Apache Webserver zur Anzeige der Webseiten
als auch der MySQL Server zur Datenspeicherung wurden in den aktuellsten, vom
Betriebssystem-Repository bereitgestellten, Versionen installiert. Ebenso wurde ein SSH Server
für den komfortablen Zugriff auf das Betriebssystem eingerichtet. Alternativ dazu kann zur
Administration die direkte Konsole über den VCenter Client genutzt werden. Die OTRS
Installation sowie die nachfolgenden Updates wurden direkt aus den Quelldateien installiert,
um ein möglichst aktuelles System mit maximalem Funktionsumfang sowie bereits behobenen
Bugs zu erhalten.
Bei der Einführung des OTRS Systems hat man sich dazu entschlossen, eine zentrale Stelle zur
Annahme aller IT Probleme zu schaffen. 2 Mitarbeiter sind seither damit betraut, Anrufe und
Probleme der Anwender entgegenzunehmen, diese als Ticket im System zu erfassen, und
anschließend dem richtigen Bearbeiterkreis zuzustellen. Vorteil dieser Variante ist die hohe
Qualität der Problembeschreibung. Bei der Ticketannahme können Rückfragen gestellt
werden. Durch diesen Dialog entsteht eine sehr detaillierte Fehlerbeschreibung. In vielen
Fällen kann das Problem sogar direkt dadurch gelöst werden (Abbildung 2.1.a). Dazu wurden
sowohl das Kunden Interface als auch die E-Mail Kommunikation mit in die Lösung eingebaut.
Der Kunde wird über alle relevanten Schritte, vom Öffnen, über das Zuweisen und Bearbeiten
bis hin zum Schließen per Mail auf dem Laufenden gehalten. Genauso kann er im Webinterface
den aktuellen Status prüfen und eine Rückfrage zum Ticket stellen. Diese wird automatisch an
das Ticket angefügt, und so dem Bearbeiter zur Verfügung gestellt. Hierdurch wird ohne
zusätzlichen Aufwand ein komplettes Bearbeitungs- und Kommunikationsprotokoll zum Ticket
erstellt. Dies wird z.B. für spätere, ähnliche Fehler als FAQ genutzt. Die Authentifizierung am
System erfolgt sowohl für die Agents als auch für die Kunden über eine LDAP Schnittstelle
gegen das Active Directory des Klinikums.
2.2. Aufgabendefinition
Die vorhandene OTRS Infrastruktur soll für Störungen der Betriebstechnik mitbenutzt werden.
Dadurch erweitert sich nicht nur der Kreis der Bearbeiter, sondern auch das Klientel der
Problemmelder. Es kann nun nicht mehr davon ausgegangen werden, dass jeder
Problemmelder eine E-Mail Adresse und einen Active Directory Account besitzt. Dadurch
stehen die Schnittstellen zur Problemmeldung per Mail und dem im OTRS vorhandenem
Webinterface für diesen Zweck nicht zur Verfügung. Die Störannahme per Telefon, die in der
EDV Abteilung üblich ist, schied aus organisatorischen Gründen ebenfalls aus. Es musste eine
Möglichkeit geschaffen werden, möglichst einfach und schnell für jeden ohne
Authentifizierung Meldungen aufzugeben. Die Erweiterung soll auf den vorhandenen Mitteln
aufbauen, und Klinikums weit ohne Installationsaufwand auf jedem PC zur Verfügung stehen.
Michael Schrüfer
Matnr.: 2667118
Seite 8 von 38
2.3. Analyse der Lösungsmöglichkeiten
Um eine möglichst einheitliche Struktur zu erreichen und die bestmögliche Integration
umzusetzen, war der erste Gedanke, die vorhandenen Formulare und Dateien aus OTRS als
Basis zu verwenden und entsprechend anzupassen. Leider stellte sich relativ schnell heraus,
dass die im Quellcode enthaltenen konzeptionellen Vorgaben des Systems nicht unseren
Anforderungen entsprechen, und eine Anpassung mit einem unverhältnismäßig hohen
Aufwand verbunden gewesen wäre. Zudem ließen sich die Änderungen nicht transparent für
zukünftige Updates in das OTRS System integrieren.
Aufgrund dieser Erkenntnisse hat man sich dazu entschlossen, ein separates Interface zur
Eingabe der Störmeldungen zu entwickeln und über definierte Schnittstellen mit OTRS zu
verknüpfen. Zur Implementierung bot sich die Skriptsprache PHP, zum einen aufgrund der
vorhandenen Infrastruktur, zum anderen aufgrund der schnellen und flexiblen
Verbreitungsmöglichkeit an. Als die am einfachsten anzusprechende Schnittstelle bot sich
zunächst MySQL an. Die in das Formular eingegeben Daten sollten also direkt in die DB
gespeichert werden. Vorteil dieser Variante ist die wäre die weite Verbreitung und gute
Dokumentation der Lösung. Der Ansatz ist in diversen Büchern und Fachartikeln ausführlich
und gut beschrieben. Bereits bei den ersten Implementierungsversuchen wurde jedoch
festgestellt, dass die OTRS Datenbankarchitektur weitaus komplexer war als anfangs gedacht.
Dazu kam, dass Daten z.B. die Identifikationsnummer eines Tickets von einer OTRS-internen
Funktion generiert wird, und nicht „einfach nur hochgezählt wird“. Aufgrund dieser
Erfahrungen musste dieser Versuch abgebrochen werden, und ein anderer
Kommunikationsweg zum OTRS gesucht werden. Bei der Recherche im Internet stellte sich das
OTRS Generic Interface als geeignet dar. Es wird vom System selbst angeboten, um externen
Systemen Dritter Zugriff auf OTRS-interne Funktionen zu geben. Aufgrund der offenen und
standardisierten Schnittstellen entschloss man sich die PHP Anwendung kompatibel zum
Generic Interface aufzubauen.
2.4. Implementierung der Lösung
Da die Voraussetzungen an die Infrastruktur durch die vorhandene OTRS Installation bereits
erfüllt waren, beschränkten sich die Vorbereitungen auf die Einrichtung einer
Entwicklungsumgebung. Auf Grund der Größe des Projekts und der überschaubaren Anzahl an
Dateien wurde der Unix Editor VI(M) und Subversion zur Versionskontrolle ausgewählt. Vorteil
dieser schlanken Entwicklungsumgebung war die geringe Anpassungsarbeit auf dem Server. Es
war weder eine Grafische Oberfläche noch ein Samba Server zur Bereitstellung einer Windows
Freigabe notwendig.
Zur Eingabe der Daten zur Störmeldung wurde ein HTML Formular programmiert, welches die
relevanten Informationen vom Anwender abfragt. Die Datenvalidierung und Eingabe von
Pflichtfeldern konnten via Java Script realisiert werden. Sind alle benötigten Felder gefüllt, und
das Formular abgeschickt, werden die erfassten Daten an ein PHP Skript übergeben. Dieses
Skript übernimmt die eigentliche Arbeit. Es baut via HTTP/SOAP eine Verbindung zum OTRS
System auf, und legt ein neues Ticket mit den übergebenen Daten an. Die OTRS Schnittstelle
bietet 2 Betriebsmodi und setzt sich aus 4 Modulen zusammen. Das OTRS Generic Interface
kann als sogenannter Requester oder Provider betrieben werden. Als Reqester geht die
Kommunikation vom OTRS aus. Beim Provider agiert OTRS als Annahmestelle für Daten. Diese
Michael Schrüfer
Matnr.: 2667118
Seite 9 von 38
letztgenannte Schnittstelle wird vom PHP Skript angesprochen, um das Ticket anzulegen. Das
erste Modul, Network Transport, übernimmt die Kommunikation mit dem entfernten System.
Im Provider Modi erfolgt dies über das Skript nph-genericinterface.pl. Um dieses nutzen zu
können, muss ein „WebService Handler“ im OTRS angelegt werden (Abbildung 2.4.a). In
diesem werden die Einstellungen zur Kommunikation zwischen dem externen Service und
OTRS festgelegt. Als „Transport –Methode“ steht im „Provider-Modus“ lediglich HTTP::SOAP
zur Wahl. Die OTRS-Interne Funktion wird über einen sogenannten Controller definiert. Dieser
wird im erzeugten Webservice definiert und kann in der externen Applikation angesprochen
werden. In den weiteren Modulen wie z.B. dem Data Mapping zur Anpassung der
Datenstruktur waren keine Änderungen notwendig, da die Applikation nach den OTRS
Vorgaben entwickelt werden konnte. Damit war die Konfiguration des OTRS´s abgeschlossen.
Die Übergabe an das OTRS und die Rückmeldung an den Anwender umfasst 3 Schritte, die je in
einer Datei abgebildet werden. Das erste File stellt das HTML Formular zur Eingabe der Daten
bereit. Der Problemmelder muss in fest definierten Feldern Angaben zu seiner Person sowie
dem Problem hinterlegen. Dabei sind bestimmte Felder als Pflichtfelder auszufüllen. Da ohne
diese zwingend benötigten Daten die Verarbeitung nicht fortgesetzt, und kein Ticket in OTRS
angelegt werden darf, wird die Datenerfassung direkt auf der Eingabeseite durch eine
JavaSkript Funktion geprüft. Hierdurch werden fehlerhafte Daten erst gar nicht an ein
verarbeitendes Skript weitergegeben, sondern schon im ersten Schritt bei der Eingabe
abgefangen. Sind alle geforderten Daten eingegeben, erfolgt die Weiterleitung zur nächsten
Seite. In diesem Schritt findet als erstes eine primitive Datenvalidierung statt, die
gewährleistet, dass alle benötigten Daten erfolgreich übergeben wurden. Um den Zugriff auf
die Daten während der gesamten Laufzeit einer Sitzung sicherstellen zu können, werden diese
zunächst in entsprechenden Session Variablen abgelegt. Anschließend wird eine Instanz der
SOAP Client Klasse erzeugt. Diese ermöglicht den Zugriff auf den OTRS Webservice und damit
die Nutzung der internen Funktionen. Wichtigster Parameter im Konstruktor der SOAP Client
Klasse ist die URL zum Webservice im OTRS-Webverzeichnis. Diese setzt sich aus dem Pfad zum
Generic Interface und dem Namen des Webservices zusammen
('http://<servername>/otrs/nph-genericinterface.pl/Webservice/NewTicket'). Zurückgegeben
wird das Client Objekt, über das mit der Funktion __soapCall Funktionen des Webservices
genutzt werden können.
$soapClientObject = new SoapClient(null, array('location' => $url,
...
$ticketId = $soapClientObject->__soapCall(CreateMyTicket, TICKETDATEN
...
Wie im Code-Snipped zu sehen, wird der „__soapCall Funktion“ der Name der Operation sowie
die dazugehörigen Daten übergeben. Hierfür wurde im OTRS Webservice „NewTicket“ die
Operation „CreateMyTicket“ definiert, hinter der sich der OTRS Controller
„Ticket::TicketCreate“ verbirgt. Als zweiten Parameter werden der Funktion direkt die
Ticketdaten aus den Session-Variablen übergeben. Bei Erfolg gibt die Funktion die ID des neu
erstellten Tickets zurück. Diese wird ebenfalls in einer Session-Variable abgelegt. Im Fehlerfall
wird eine Exception „geworfen“ und die Verarbeitung abgebrochen. Um dem Problemmelder
die Ticketdaten sowie die ID seiner neu erstellten Meldung mitzuteilen, sollen alle erfassten
Daten gesammelt ausgegeben und auf Wunsch gedruckt werden können. Um ein doppeltes
Erstellen des Tickets bei bewusster oder unbewusster Aktualisierung (F5) der Seite zu
vermeiden, wird man nach dem erfolgreichen Erstellen des OTRS Tickets umgehend auf eine
Michael Schrüfer
Matnr.: 2667118
Seite 10 von 38
separate Ausgabeseite weitergeleitet. Hier werden die Daten wie gefordert inkl. Ticket-ID
ausgegeben. Der Ausdruck der Seite wird über die JavaScript Funktion
onClick="javascript:window.print()" realisiert. Der Problembearbeiter erhält keine
Kenntniss vom Vorgang der externen Ticketerstellung (Abbildung 2.4.b). Für ihn wird das Ticket
in der entsprechenden Queue wie jedes andere direkt im OTRS erstellte Telefon- oder E-Mail
Ticket angezeigt. Die OTRS Queue wird vom Problemmelder durch die Angabe eines
Problembereichs automatisch zugeordnet.
2.5. Test und Übergabe
Die funktionalen Tests wurden parallel zur Programmierung der einzelnen Methoden
durchgeführt. Abschließende Tests über den gesamten Workflow inkl. der Ticket-Bearbeitung
im OTRS erfolgten durch Mitarbeiter der EDV Abteilung. Da diese bereits mit dem OTRS
vertraut waren, konnten sie die korrekte Ticketerstellung prüfen, und den kompletten Prozess
beurteilen. Die Übergabe und Übernahme in den Produktivbetrieb erfolgte nach einer
Schulung des Bearbeiter-Personals der Betriebstechnik. Um den Workflow und die
Ticketbearbeitung zu optimieren, soll in naher Zukunft ein Test mit der Ticketverwaltung via
Smartphone erfolgen. Über eine existierende Android App kann von überall im Klinikum eine
Verbindung zum OTRS Datenbestand aufgebaut werden. Das Haus weit verfügbare WLAN soll
dabei die Grundlage der Datenkommunikation bilden.
Michael Schrüfer
Matnr.: 2667118
Seite 11 von 38
3. Aktualisierung des Mailhubs zur Spam- und Virenabwehr
Die Kommunikation via E-Mail wird heutzutage als selbstverständlich gesehen. Selbst
„Computer-Laien“ können kurzer Zeit und ohne Vorkenntnisse E-Mails senden und
empfangen. Ermöglicht wird dies insbesondere durch sehr einfach und bequem zu bedienende
Client Software (Mail User Agent - MUA). Leider bringt diese Bequemlichkeit auch einen
Nachteil mit sich. Den Anwendern fehlt oft das Hintergrundwissen zur E-Mail Kommunikation
und den zugrundeliegenden Protokollen. So wird das rein für Textnachrichten konzeptionierte
SMTP (Simple Mail Transfer Protokoll) heute oft als Protokoll zur Übertragung großer
Multimediadateien, zur Echtzeitkommunikation (Instand Messaging) oder zum Versand
formatierter HTML Dokumente missverstanden. Aussagen wie „der Empfang meiner E-Mail
muss garantiert werden und darf unter keinen Umständen verzögert oder von Dritten gelesen
werden“ belegen dieses mangelnde Wissen um die Funktionsweise und die Hintergründe der
E-Mail Kommunikation. So werden z.B. insbesondere Techniken zur Verzögerung von E-Mails
bewusst zur SPAM Bekämpfung eingesetzt. Vielen Anwendern, die sich von ein bis zwei „SPAM
Mails“ gestört fühlen, ist nicht bekannt, dass diese Mails über 95 % des weltweiten E-MailVerkehrs verursachen. Um diese Flut vom E-Mail Nutzer einzudämmen wurden diverse
Techniken entwickelt, auf die im weiteren Verlauf noch genauer eingegangen wird. In der
Praxis hat sich eine logische, sowie in vielen Fällen auch eine physikalische Trennung der
Aufgaben auf verschiedene Software- und Hardwarekomponenten etabliert. Während die
Benutzerpostfächer samt Zugriffsstruktur meist auf innerhalb des Firmen-Netzwerks liegenden
Groupware-/Mailservern zu finden sind, übernehmen sogenannte Mailhubs oder Mailrelays
die Kommunikation mit entfernten Mailservern (Abbildung 3.1.a). Da diese von der
„Außenwelt“ erreichbar sein müssen, findet man sie in der Regel in speziell gesicherten und
abgeschotteten Netzwerken, den demilitarisierten Zonen (DMZ). Dort sind sie sowohl für die
Annahme und Weiterleitung an den Postfachspeicher erwünschter, als auch im Besonderen für
die Zurückweisung unerwünschter E-Mails zuständig. Neben dem Empfang übernimmt ein
Mailhub auch die Weiterleitung der intern generierten E-Mails an die Mailserver der
Kommunikationspartner. Hierbei spielt das DNS (Domain Name Service) Protokoll eine
entscheidende Rolle. Über die in der DNS Zone definierten Mail Exchange Resource Records
wird der Transportweg einer Mail für eine bestimmte Domain festgelegt. Außerdem ist eine
korrekte DNS Konfiguration notwendig, um nicht selbst als SPAMer klassifiziert zu werden. Um
Entscheidungen zum Mailrouting schnell und zuverlässig treffen zu können, findet man in
vielen Setups direkt neben dem Mailhub einen DNS-Forwarder, der selbst keine Zonen
verwaltet, sondern Anfragen nur zwischenspeichert oder ggf. an externe DNS Server delegiert.
3.1. Ist-Analyse
Im Klinikum St. Marien ist die oben beschriebene Struktur weitgehend umgesetzt. Die Daten
und E-Mails der Benutzer werden innerhalb des Netzwerks auf einem Microsoft Exchange
Server vorgehalten und verwaltet. Für die Archivierung älterer, selten benötigter E-Mails steht
ein nachgelagertes Archiv bereit. Für den Zugriff auf die Postfächer steht den Anwendern
Microsoft Outlook als vollwertiger, sowie Outlook Webaccess als eingeschränkter Client intern
zur Verfügung. Ein Zugriff von Extern auf das Benutzerkonto ist aus Datenschutzgründen nicht
möglich.
Michael Schrüfer
Matnr.: 2667118
Seite 12 von 38
Zur Spambekämpfung wird ein Mailrelay in der DMZ betrieben, welches im Mailfluss logisch
vor dem Exchange Server angeordnet ist. Als Mailserversoftware kommt die aktuelle SendmailVersion, welche um zahlreiche Milter und Zusatzprogramme erweitert wurde, zum Einsatz. Als
Basis dient ein gehärtetes Linux Grundsystem. Um einen größtmöglichen Schutz vor Viren und
sonstiger Schadsoftware garantieren zu können, wurden sowohl auf dem Mailrelay, als auch
auf dem Exchange Server spezielle Virenscanner unterschiedlicher Hersteller installiert und
konfiguriert. Beide Dienste werden hochverfügbar über die hausweite, virtualisierte
Infrastruktur bereitgestellt.
3.2. Aufgabendefinition
Auch wenn Sendmail als Software für Mailsysteme immer noch sehr weit verbreitet ist, nimmt
dessen Bedeutung stetig ab. Dies liegt zum einen an der äußerst komplexen Konfiguration und
zum anderen an den regelmäßig bekannt werdenden Sicherheitslücken, die aufwendig
gepached werden müssen. Funktionen, die heute Mail Transfer Agents (MTA) von Haus aus
mitbringen, müssen bei Sendmail als Milter eingebunden werden. Dieses Konzept macht
Sendmail auf der einen Seite sehr flexibel, auf der anderen Seite aber auch sehr schwer zu
verwalten. Besonders schwierig gestaltet sich die Absicherung des Systems durch die
zahlreichen Verbindungen zu den externen Modulen und Programmen.
Um diese Nachteile zu beseitigen, soll das vorhandene System von einem modernen,
modularen System zur Spam- und Virenabwehr abgelöst werden. Das Nachfolgesystem soll
einfacher zu administrieren und zu konfigurieren sein. Dabei soll bei gleichbleibender SPAMund Virenerkennungsrate die Gesamtsicherheit des Systems erhöht werden. Auf Grund der
hohen Qualität und Verbreitung quelloffener Software in diesem Bereich soll auf
kommerzielle, kostenpflichtige Lösungen verzichtet werden. Um Ausfallzeiten zu vermeiden,
soll das neue System parallel zum bestehenden aufgebaut werden und dessen Infrastruktur
nutzen.
3.3. Implementierung und Konfiguration der Lösung
Durch die bereits bestehende virtualisierte Infrastruktur gestaltete sich die Einrichtung der
neuen „Hardware“ sehr einfach, schnell und kostengünstig. Logisch direkt neben dem aktiven
Mailhub wurde eine neue virtuelle Maschine angelegt und konfiguriert. Bei der Auswahl des
Betriebssystems fiel die Entscheidung auf die Linux Distribution Ubuntu 12.04 LTS.
Ausschlaggebend hierfür war zum einen das auf Linux Debian basierende Grundsystem, mit
dem die Administratoren vor Ort vertraut waren, zum anderen der lange Support-Zeitraum
von 5 Jahren, indem Updates und neue Pakete bereit gestellt werden. Die Installation des
Betriebssystems erfolgte zum Großteil nach Standardvorgaben. Dabei wurde die
Partitionierung so gewählt, dass eine volle Partition nicht zum Stillstand des Gesamtsystems
führen kann. Als Paketquelle erwiesen sich die Ubuntu-Quellen als ausreichend. Um ein
möglichst schlankes, stabiles und sicheres Grundsystem bereitzustellen, wurde als
Installationstyp ein Minimalsystem ohne grafische Benutzeroberfläche gewählt. Zur
Administration des Systems steht zum Zeitpunkt der Installation nur die VMWare Konsole und
nach Abschluss dieser ein SSH Server zum Remotezugriff zur Verfügung. Da ein direkter Zugriff
vom Internet aus auf diesen Server möglich ist, mussten spezielle Maßnahmen zur
Absicherung des Systems ergriffen werden. So wurde das Betriebssystem mit seinem Kernel
nach internen Vorgaben und Vorlagen gehärtet und unnötige Dienste deinstalliert. Des
Michael Schrüfer
Matnr.: 2667118
Seite 13 von 38
Weiteren wurde eine lokale Firewall zur Paketfilterung installiert und konfiguriert. Dabei
wurde auf das im Linux Kernel enthaltene IPTables Modul mit Stateful Packet Inspection
zurückgegriffen. Um Einbruchsversuche, Systemereignisse oder Logmeldungen der
Mailserversoftware zeitlich richtig ein- und zuordnen zu können, ist eine korrekte Systemzeit
insbesondere für sicherheitskritische Komponenten zwingend erforderlich. Zum Erreichen der
der Zeitsynchronisation wurde der Ubuntu NTP Client installiert und konfiguriert. Um optimal
mit der zugrundeliegenden VMWare Infrastruktur zusammenarbeiten zu können, war die
Installation der „VMWare Tools“ auf dem Gast-System notwendig. Da es im alltäglichen
Betrieb unmöglich ist, alle Systeme sowie deren Auslastung und Ereignisse im Blick zu haben,
wird im Klinikum die Monitoring Software Nagios eingesetzt. Diese prüft je nach Konfiguration
eines Hosts oder Services die Verfügbarkeit und Auslastung in regelmäßigen Zeitabständen.
Wie auch der alte Mailhub soll auch die Nachfolgeinstallation via Nagios überwacht werden.
Um die relevanten Informationen vom zu überwachenden Hosts abrufen zu können, muss der
Nagios-Server eine Verbindung zum entfernten System aufbauen, dort je nach Check ein
Programm ausführen, und dessen Rückgabewert interpretieren. Für diesen Zweck steht in den
Paketquellen das Programm NRPE (Nagios Remote Plugin Executor) zur Verfügung. Es öffnet
auf dem Zielsystem einen definierten Port, mit dem sich das Nagios-Serversystem verbinden
kann, und über das es Checks zur CPU Auslastung, RAM Belegung, Belegung der Partitionen
oder Verfügbarkeit einzelner Dienste und Anwendungen ausführen kann. Nach der Installation
der Mailserverdienste sollen diese Checks noch einmal überarbeitet und angepasst werden.
Dieser sehr detaillierte Systemstatus kann über ein Nagios Webinterface an zentraler Stelle
eingesehen und geprüft werden. Meldungen über Warnungen oder Fehler auf den
überwachten Systemen werden per Mail aktiv an den Administrator gesendet. Nach Abschluss
der Grundinstallation wurden die Firewall Systeme sowohl zum internen Netzwerk, als auch
zum Internet speziell nach den Anforderungen des E-Mail Systems angepasst. Grundbedingung
für die Funktionalität des neuen Systems ist die Erreichbarkeit des E-Mail-Dienstes in beide
Richtungen. Für den Versand muss der interne Exchange Server Mails an den Mailhub in der
DMZ zustellen können. Die Gegenrichtung wird primär für den Empfang von E-Mails benötigt.
Außerdem wurden weitere Freigaben zur Administration und Überwachung des Servers gemäß
bestehender Richtlinien eingerichtet. Die Regeln auf der Firewall Instanz zwischen Internet und
DMZ wurden vorbereitet, jedoch während der Test- und Installationsphase noch nicht
aktiviert. Lediglich der Zugriff auf Updates, Paketquellen, Zeitsynchronisation und entfernte
Testserver wurde ermöglicht. Um den Grundzustand des neuen Systems zu sichern, und im
Fehlerfall wiederherstellen zu können, wurde ein Snapshot der virtuellen Maschine angelegt.
Nach der Installation und Konfiguration dieser Basiskomponenten musste die Entscheidung
über die einzusetzende Mailserversoftware getroffen werden. Nach Recherchen in
einschlägiger Fachliteratur stellte sich der Mailserver Postfix als das auf die Anforderungen
passende Produkt heraus. Er bietet eine ähnliche, modulare Struktur wie der veraltete
Sendmail MTA, ermöglicht jedoch eine einfachere und komfortablere Konfiguration und
Administration. Außerdem konnten Protokolle und Features, die in Sendmail über die Jahre
aus Kompatibilitätsgründen mitgeschleift wurden, heutzutage allerdings keine Rolle mehr
spielen, bei Postfix von Entwicklungsbeginn an außen vor gelassen werden. Dies führt zu einer
kompakteren, kleineren und sichereren Installation, ohne die Flexibilität und Möglichkeiten
des Postfix-Systems einzugeschränken. Im Grundpaket nicht enthaltene Features können über
die modulare Struktur jederzeit eingebunden werden. Als eine für das neue Konzept besonders
Michael Schrüfer
Matnr.: 2667118
Seite 14 von 38
hervorzuhebende Partner-Komponente ist AMaViS zu nennen. Sie übernimmt einerseits die
Prüfung auf Viren und potentiell schädlicher Dateianhänge, sowie andererseits die
contentbasierte Spamprüfung. Dabei greift AMaViS auf bestehende Softwarepakete wie
Spamassassin oder ClamAV zurück. Neben ClamAV, der sich als freier Virenscanner auch im
professionellen Umfeld etabliert hat, bietet AMaViS Schnittstellen zu allen gängigen
Virenscannern. Auf die übrigen für die SPAM Bekämpfung relevanten Bestandteile der Lösung
wird im weiteren Verlauf genauer eingegangen.
Da die in den Paketquellen zur Verfügung gestellte Version alle benötigten Features enthielt,
konnte auf eine manuelle Übersetzung und Installation des Quellcodes verzichtet werden.
Durch die Verwendung des Paketverwaltungssystems „Advanced Packaging Tool“ (APT)
gestaltete sich die Installation neuer Bestehender sowie die Instandhaltung bestehender
Pakete einfacher. Neben der automatischen Auflösung von Paketabhängigkeiten während der
Installation erleichtert es insbesondere das Einspielen von Updates und neuen Versionen und
somit die Wartung der Softwareinstanz. Die Installation des Basis-Mailserverpakets „Postfix“
konnte zeitnah abgeschlossen werden, da die im Paket hinterlegten Standardangaben wie
Pfadangaben ohne manuelle Anpassung übernommen werden konnten. Die von der
Distribution vorgeschlagene Konfiguration wurde hingegen komplett verworfen und durch
eine eigene ersetzt, um ein perfekt an die Anforderungen angepasstes System zu aufzubauen.
Die Postfix Grundkonfiguration ist auf 2 Dateien aufgeteilt. Das Verhalten des Systems wird
durch entsprechende Variablenzuweisungen in der Datei „main.cf“ verwaltet. Zu Beginn sind
hier lediglich Angaben zum Mailsystem selber, wie z.B. der Hostname, das vertrauenswürdige
Netzwerk oder die eigene Domain enthalten. Im weiteren Verlauf werden insbesondere
Parameter zur Spambekämpfung diese Datei erweitern. Das zweite File dient zur
Konfiguration des Postfix-Masterprogramms (master). Es ist für die Überwachung, Steuerung
und Koordination der einzelnen Postfix-Komponenten zuständig und nimmt somit eine
zentrale Stellung im Postfix-System ein. Nach jedem Konfigurationsschritt wurde die korrekte
Funktionalität des Systems getestet. Bereits in diesem frühen Stadium erfolgten Tests zur
Erreichbarkeit des SMTP-Dienstes (TCP / 25) und zur Zustellung von Mails an zu Testzwecken
eingerichtete lokale Postfächer. Besonderes Augenmerk wurde dabei auf das zuverlässige
Blocken von E-Mails, die nicht an eigene Domains adressiert sind, gelegt. Auch wenn Postfix
selber Schutzmechanismen bereitstellt, um das Verhalten als sogenanntes Open Relay zu
verhindern, müssen insbesondere Parameter zur Freigabe bestimmter Funktionen genau
geprüft und anschließend getestet werden. Das Mailrouting, also die Weiterleitung und
Zustellung von E-Mails, wird im Internet grundsätzlich durch die Einrichtung von MX-Records in
den DNS Zonen definiert. Dieses Prinzip funktioniert bei einem Mailrelay nicht, da es nach
außen selbst als MX für die Zone konfiguriert ist. Es müssen demnach zusätzliche
Informationen auf dem Relay hinterlegt werden, anhand derer es entscheiden kann, wohin die
Mail endgültig zuzustellen ist. Um diese Entscheidungen treffen zu können, kennt Postfix das
Konzept der Lookup Tables. In diesen einfach aufgebauten, in Tabellenform gehaltenen
Textdateien wird in der linken „Spalte“ ein Wert definiert, für den die in der rechten „Spalte“
definierte Aktion ausgeführt wird. Um nun den Weg einer E-Mail festlegen zu können, muss
zunächst die Empfangsdomain als „relay_domain(s)“ dem Postfix System bekannt gemacht
werden. Andernfalls würde der SMTP-Daemon die Annahme der Mail verweigern. Im zweiten
Schritt ist der eigentliche Transportweg via „transport_maps“ festzulegen. Da beide
Michael Schrüfer
Matnr.: 2667118
Seite 15 von 38
Konfigurationsparameter dasselbe Textformat erwarten, können beide auf die gleiche, einzige
Datei zeigen, was die Wartung und Pflege vereinfacht.
transport_maps = hash:/etc/postfix/lookup/transport,
hash:/etc/postfix/lookup/relay_domains
relay_domains = hash:/etc/postfix/lookup/relay_domains
$ cat /etc/postfix/lookup/relay_domains
# Domain
Eigentliches Ziel (Groupware System)
mydomain.de
:[192.168.0.25]
mydomainXY.de
:[192.168.0.25]
mydomain2.de
:[192.168.0.111]
…
Die grundlegende Funktionalität des Mailhubs ist damit bereits sichergestellt. Mails werden
über das SMTP Protokoll entgegengenommen und anhand der Zieldomain an das im internen
Netzwerk befindliche Groupware System weitergeleitet. Die weiteren Konfigurationsarbeiten
dienen insbesondere zur SPAM- und Virenabwehr sowie zur Absicherung des Systems und der
E-Mail Kommunikation. Auch in diesen Bereichen bringt Postfix schon von Haus aus eine Fülle
an nützlicher Funktionen mit. Die Reihenfolge der nachfolgenden Prüfungen entspricht der
Abarbeitung dieser im Verlauf des SMTP Dialogs bei der Einlieferung einer E-Mail (Abbildung
3.3.a) . Dabei ist das Ziel, CPU-Intensive Prüfvorgänge wie Content Filtering so spät, und damit
so selten wie möglich, ausführen zu müssen. Durch sehr einfache und schnelle Tests soll der
größte Teil der SPAM Mails bereits beim Eintreffen abgelehnt oder verworfen werden. Die
erste, noch relativ junge - da erst mit der Postfix Version 2.8 eingeführte - Sammlung von
Checks greift diesen Ansatz auf, und versucht als eine Art Türsteher für Postfix einliefernde
Mailserver als Zombie oder Spambot zu enttarnen, bevor knappe Rechenressourcen
verschwendet werden. Ausschlaggebend für die Entwicklung dieser Werkzeuge war die
Erkenntnis, dass über 95 % des SPAM-Aufkommens durch Botnetze verursacht wird. Diese
bestehen aus gehackten Rechnern, die ohne Wissen des Anwenders zum SPAM Versand
missbraucht werden. Die auf den „Opfer-PCs“ installierte Schadsoftware ist darauf ausgelegt,
möglichst viele Mails in möglichst kurzer Zeit zu versenden. Da das SMTP Protokoll diesem
Ansatz nicht entspricht, haben sich Methoden etabliert, die das Verhalten des sendenden
Mailservers analysieren und danach ihre Entscheidung treffen. Als besonders effektiv hat sich
das Verzögern der Begrüßungsnachricht herausgestellt. Während ein richtig konfigurierter
einliefernder Mailserver auf die „Begrüßung“ durch den Mailserver wartet, nimmt ein
Spambot darauf keine Rücksicht, sondern versucht, die Nachricht sofort zuzustellen. Erkennt
Postfix diesen übereifrigen Zustellungsversuch, bricht es die Übertragung umgehend ab.
postfix/postscreen[12032]: PREGREET 16 after 0.88 from [x.x.x.x]:53687: helo wwwSrv004
postfix/postscreen[12032]: DISCONNECT [x.x.x.x]:53687
Gleich verhält sich Postfix, wenn durch Postscreen Verstöße gegen das SMTP Protokoll erkannt
werden. Als Verstoß wird dabei das Absenden unbekannter, nicht im Protokoll definierter
Befehle gewertet. Aus Sicht des zustellenden Mailservers bzw. des Bots wird die Verbindung
hart und permanent mit einem 5xx Fehlercode abgebrochen. Sobald jedoch die PostscreenMechanismen einmal erfolgreich und ohne Beanstandung durchlaufen wurden, wird das
Ergebnis zwischengespeichert, sodass bei nachfolgenden Verbindungsaufbauten die Prüfungen
kein zweites Mal durchlaufen werden müssen. Um Postscreen als Türsteher vor dem Postfix
SMTP Modul zu betreiben, müssen eingehende Anfragen auf Port 25 an Postscreen
weitergeleitet werden. Dazu wird lediglich das Modul smtpd durch postscreen in der master.cf
ersetzt. Nach einem Neustart des Postfix-Dienstes ist Postscreen nun die erste Anlaufstelle für
Michael Schrüfer
Matnr.: 2667118
Seite 16 von 38
eingehende SMTP Verbindungen. Da Postscreen die Postfix-Standard-Tests nur erweitert und
nicht ersetzt, mussten im nächsten Schritt die Postfix Mechanismen zur Abwehr
unerwünschter Mails konfiguriert werden. Zentrales Instrument dafür stellen die
smptd_restrictions dar. Für jeden Schritt im SMTP Dialog existiert eine entsprechende
Restriction, die die zum jeweiligen Zeitpunkt zur Verfügung stehenden Daten auswertet, und
definierte Aktionen ausführen kann. Direkt nach dem Connect auf Port 25 werden die
smtpd_client_restrictions durchlaufen. Da zu diesem Zeitpunkt lediglich die IP Adresse des
entfernten Systems zur Verfügung steht, kann diese als einziges Prüfkriterium verwendet
werden. smtpd_halo_restrictions und smtpd_sender_restrictions sind den
smtpd_client_restrictions nachgelagert, und bieten auf Grund dem Mehr an Informationen
erweiterte Filtermöglichkeiten. Da der Rechen- und Zeitaufwand zwischen den einzelnen
Schritten des SMTP Dialogs zu vernachlässigt werden kann, bot sich an, alle restrictions unter
den smtpd_receipient_restrictions zusammenzufassen. Diese werden nach Absetzen des „rcpt
to:<…>“ Kommandos durchlaufen. Neben der IP Adresse kann nun auch der HELO Namen des
Clients, die Absender- sowie Empfängeradresse zur Prüfung herangezogen werden. Die Checks
innerhalb des Abschnitts werden so lange durchlaufen, bis einer eindeutig OK oder REJECT als
Ergebnis liefert. Da die Reihenfolge der Regeln also eine Rolle spielt, wurden diese bewusst
den Anforderungen an Sicherheit, Flexibilität und Rechenzeit angepasst gewählt. Dabei sind
die grundlegenden Regelkonzepte permit_* und reject_* zu nennen. Eine permit_* - Regel
kann nur ein OK liefern und so z.B. zum Whitelisten angewendet werden. Das Blacklisten oder
manuelle Blocken von Clients wird über die reject_* Prüfungen realisiert. Diese liefern stets ein
REJECT bei Erfüllen der Prüfbedingung. Daraufhin wird die Kommunikation permanent mit
einem 5xx Fehler abgebrochen. Generell sind die permit_*- Checks bzw. das Whitelisting mit
größerer Sorgfalt und Abwägung einzusetzen, da sie unter Umständen Absendern
unerwünschter Massenmails Türen öffnen. So sollte z.B. eine Prüfung auf die Empfangsadresse
nie ein endgültiges OK liefern. Wohingegen die Freigabe einer einzelner, vertrauenswürdiger IP
Adresse durchaus Sinn macht und die Verarbeitung beschleunigt. Das im LAN stehende
Groupware-System erfüllt diese Vorgabe. Da die hausintern erstellten Mails als
vertrauenswürdig eingestuft werden können, kann auf eine tiefergehende, detaillierte und
damit auch zeitaufwendige Prüfung verzichtet werden. Allerdings sollen die Mails auch nicht
ganz ohne Prüfung „blind“ weitergleitet werden. Denn auch für interne Mail-Verfasser gibt es
keinen Grund, eine E-Mail an eine nicht existierende Empfangs-Domain zu senden. Neben
diesen eher statischen REJCT-/PERMIT-Checks haben sich in den vergangenen Jahren auch
dynamische, von externen Daten abhängige Prüfmechanismen etabliert. Dazu zählen
insbesondere die Realtime Blackhole Lists (RBL), die ihre Entscheidungen zur Filterung auf
Grund im DNS hinterlegten Informationen treffen. Der Anbieter einer Blackhole List pflegt
dafür eine spezielle Reverse Lookup Zone, die alle als SPAMer enttarnten Mailserver inklusive
Hostnamen enthält. Damit der prüfende Mailserver die Entscheidung „blocken oder nicht
blocken“ treffen kann, muss er selbst zunächst eine DNS Abfrage stellen. Liefert diese Abfrage
einen Hostnamen, so ist der Mailserver gelistet und als Ausgangspunkt für SPAM-Mails
eingestuft worden. Ist dies nicht der Fall, gibt der DNS Server ein <unknown> zurück. Die
Integration erfolgt direkt in den Abschnitt der smtp_receipient_restrictions durch das
Schlüsselwort reject_rbl_client und der Angabe des DNS Servers. Für den als vertrauenswürdig
eingestuften Mail-Verkehr werden diese Regeln bereits nicht mehr durchlaufen, da der Fall,
dass unser Groupware System mit priv. IP Adresse und internem FQDN (Fully Qualified Domain
Name) auf einer Blacklist steht, nicht eintreten wird, sodass man sich die Zeit zur Prüfung
Michael Schrüfer
Matnr.: 2667118
Seite 17 von 38
sparen kann. Da Postfix als Mailhub keine Informationen über existierende Postfächer besitzt,
muss er alle Mails an die Relay Domain annehmen. Erst bei der Weiterleitung an das
Groupware System wird festgestellt, ob das Postfach überhaupt existiert und die Mail einem
Anwender zugestellt werden kann. Dies bereitet kein Problem, so lange das Postfach auf dem
Groupware System existiert, da Postfix die Weiterleitung der Mail an das GroupwareSystem
erfolgreich quittiert bekommt. Existiert jedoch das Postfach nicht, wird die Weiterleitung mit
einem permanenten Fehler 5xx (user unknown) abgelehnt. Da Postfix die Zustellung
gegenüber dem einliefernden Mailserver bereits mit 2xx (erfolgreich) bestätigt hat, muss eine
Bounce Mail an den Absender gesendet werden, um Ihn über die fehlgeschlagene Zustellung
zu informieren. Dies ist allerdings äußerst problematisch, da so gut wie alle Absenderadressen
von SPAM gefälscht sind. Im besten Fall existiert die Absender-Adresse nicht, und die E-Mail
wird verworfen. Ist die Absenderadresse jedoch einem existierenden, fremden System
zugeordnet, wird dieses durch die Bounce Nachrichten unnötig belastet (Backscatter Problem).
Die selbstlernende Empfängerverifizierung behebt dieses Problem, indem es vor der
erfolgreichen Bestätigung an den einliefernden Mailserver die Existenz des Postfachs am
nachgelagerten Postfachspeicher prüft. Dies erfolgt durch eine einfache SMTP Abfrage an den
eigentlichen Zielserver. Bestätigt dieser die rctp to: <ADRESSE> Anfrage mit 2xx, ist
sichergestellt, dass das Postfach existiert und der Zielserver die Mail auch annehmen wird.
Wird die Abfrage mit einem Fehler zurückgewiesen, ist auch die eigentliche E-Mail nicht
zuzustellen und wird deswegen noch während des SMTP-Dialogs mit dem einliefernden
Mailserver abgelehnt. Neben der Empfängerverifizierung stellt Postfix auch eine
Absenderverifizierung zur Verfügung. Hier wird nicht die rcpt to:<>, sondern die mail from:<>
Adresse geprüft. Auf diese Verifizierung wurde jedoch bewusst verzichtet, da sie im Gegensatz
zur Empfängerverifizierung nicht immer zuverlässig funktioniert z.B. wenn die Abfrage durch
Greylisting am entfernten MTA zurückgehalten wird, und daher mehr Probleme verursacht, als
sie Vorteile bringt.
Übersteht die Kommunikation diesen Test, werden die bisher übermittelten Daten (Envelope),
wie IP Adresse oder Hostname des einliefernden MTA, sowie Absender- und Empfangsadresse
an 2 externe Dienste übergeben, deren Rückgabeergebnisse von Postfix ausgewertet und zur
Entscheidungsfindung herangezogen werden. Beide Dienste wurden daher lokal auf
demselben Server installiert. Als erstes wird dadurch der SMTP Dialog auf Plausibilität geprüft.
Einzelne Checks wie z.B. die korrekte Rückwärtsauflösung der IP Adresse und die
Übereinstimmung mit Host- und HALO-Namen werden gewichtet und zu einem
Gesamtresultat aufsummiert. Übersteigt der Wert eine definierte Grenze, wird die E-Mail als
SPAM bewertet und durch Postfix abgewiesen. Diese Funktionalität stellt der Daemon
„policyd-weight“ für Postfix zur Verfügung. Sowohl dieser, als auch der Greylisting Daemon
lauschen auf TCP Ports, die fest an die eigene Loopbackadresse gebunden und via
check_policy_service in Postfix integriert sind. Auch Greylisting ist ein sehr effektives
Werkzeug zur SPAM-Abwehr. Dieses Verfahren setzt ganz bewusst auf die zeitliche
Verzögerung einer E-Mail. Beim Eintreffen einer E-Mail wird das Triple aus Absender-IP,
Absender- sowie Empfangsadresse mit vorhandenen Einträgen einer kleinen Datenbank
abgeglichen. Ist der Eintrag noch nicht vorhanden, wird die Mail mit einem temporären 4xx
Fehler abgewiesen, und die 3 Angaben in der Datenbank hinterlegt. Jeder korrekt konfigurierte
einliefernde Mailserver besetzt eine Queue, in der die aktuell nicht zustellbaren Nachrichten
zwischengespeichert werden. Diese wird in regelmäßigen Abständen geprüft, und für die darin
Michael Schrüfer
Matnr.: 2667118
Seite 18 von 38
enthaltenen Mails ein erneuter Zustellungsversuch gestartet. Trifft die E-Mail nun ein zweites
Mal auf den Greylisting-Daemon, ist das Tripel in der Datenbank bekannt, und wird ohne
Beanstandung an die nächste Prüfinstanz weitergeleitet. Dieses Verfahren sortierte in den
vergangenen Jahren einen Großteil der unerwünschten Botschaften aus, da SPAMer keinen
Wert auf die zuverlässige Übermittlung einer Nachricht legen, und keine Queue pflegen.
Realisiert wird das Greylisting unter Postfix durch den aus MTA-Sicht ebenfalls externen Dienst
postgrey. Hervorzuheben ist, dass all diese Prüfungen noch vor der Übermittlung des
eigentlichen Inhalts der E-Mail stattfinden. Auf Grund der geringen zu analysierenden
Datenmenge können diese Schutzmechanismen sehr schnell und ohne lange Rechenzeit
durchgeführt werden. Dennoch sind sie so effektiv, dass ein Großteil unerwünschten Mails
ausgesondert wird. Erst nach positivem Durchlauf all dieser Checks kann vom Client das SMTP
DATA Kommando abgesetzt werden. Darauf folgt der eigentliche Inhalt der E-Mail. Dieser setzt
sich aus einem Header- und Bodyteil zusammen. Während die Daten im Header-Teil Angaben
zum Weg der E-Mail, zum Absender sowie zum Empfänger enthalten, ist im Body-Teil der vom
Sender verfasste Text inkl. angehängter Dateien zu finden. Insbesondere die Anhänge bergen
ein weiteres Problem. Da eine große Anzahl von E-Mails in kurzer Zeit an sehr viele Empfänger
versendet werden kann, wird das Kommunikationsmedium E-Mail immer wieder zur
Verbreitung von Viren und sonstiger Schadsoftware missbraucht. Damit diese Programme erst
gar nicht das interne Netzwerk erreichen, sollen sie schon an der ersten Kontaktstelle, dem
Mailhub in der DMZ eliminiert werden. Für diese Aufgabe bietet sich gerade im Postfix-Umfeld
die Software AMaViS (A Mail Virus Scanner) an, die neben einem Virenscanner auch den
mächtigen Spam-Filter SpamAssassin integriert. Wie auch die 2 bereits vorgestellten „Helfer“
policyd-weight und postgrey läuft AMaViS als Daemon und bindet sich per Default an TCP Port
10024. Die Integration in Postfix kann auf 2 Arten erfolgen. Zunächst die etwas veraltete
Möglichkeit „Post-Queue“ über die Postfix-Option „content_filter“, bei der Postfix die E-Mail
entgegennimmt, dem einliefernden MTA dies erfolgreich quittiert, zwischenspeichert, und
anschließend an AMaViS übergibt. Ein Problem entsteht bei dieser Variante dann, wenn der
Mail Scanner die E-Mail als „zu Blocken“ klassifiziert. Da die Kommunikation zwischen Postfix
und AMaViS über SMTP erfolgt, bricht AMaViS die Kommunikation in einem solchen Fall mit
einem permanenten 5xx-Fehler ab. Nun entsteht das gleiche Problem, wie bei der EmpfängerVerifizierung. Postfix befindet sich in einer Zwickmühle, denn einerseits hat es die Annahme
der E-Mail gegenüber dem entfernten, einliefernden Mailserver erfolgreich quittiert, und ihm
gegenüber die Nachricht akzeptiert, andererseits soll es die E-Mail laut Prüfung des Mail
Scanners verwerfen. Das daraufhin notwendige Senden der Bounce-Nachricht soll auf Grund
der bereits erwähnten Probleme vermieden werden. Auf Grund dieses Mangels wurde die
Integration nicht mit dem „Store and Forward“ Prinzip, sondern mit der Weitergabe der Mail
an AMaViS in „Echtzeit“, umgesetzt. Hierbei bleibt die SMTP Verbindung zwischen Postfix und
dem einliefernden MTA so lange offen, bis Postfix das Filter-Ergebnis von AMaViS
zurückbekommen hat. Dieses als Pre-Queue bezeichnetes Verfahren wird in Postfix über die
Option „smtpd_proxy_filter“ (smtpd_proxy_filter=localhost:10024) realisiert. Da die
gesamte Kommunikation zwischen Postfix und AMaViS über SMTP abgewickelt wird, benötigt
AMaViS einen Rückweg, um die Mail zurück an Postfix zu liefern. Würde AMaViS die Nachricht
wieder an den Standard Postfix SMTP-Port TCP 25 zustellen, würde sich eine Endlosschleife
ergeben. Deswegen muss Postfix noch einen 2ten SMTP Port öffnen, über die AMaViS die EMail wieder zurückliefern kann. Meist wird hier der TCP Port 10025 (localhost:10025 inet
… smtpd) verwendet, der nur vom Mailserver (bzw. AMaViS) aus angesprochen und nur für
Michael Schrüfer
Matnr.: 2667118
Seite 19 von 38
diesen einzigen Zweck bereitgestellt wird. Dabei wird sichergestellt, dass die oben erwähnten,
zu diesem Zeitpunkt bereits durchlaufenen smtp_receipient_restrictions-Checks kein 2tes Mal
abgearbeitet werden müssen. Wie auch bei den bisher vorgestellten Diensten, konnte die
AMaViS Installation durch die von der Distribution bereitgestellten Debian-Paketen erfolgen.
Dadurch konnten die benötigten Pakete und deren Abhängigkeiten automatisch aufgelöst und
mitinstalliert werden. Dazu zählt insbesondere SpamAssassin als Content-Scanner, ein
Virenscanner sowie Programme zum Entpacken der zu prüfenden Anhänge. Die eigentliche
Konfiguration des in Perl geschriebenen AMaViS Dienstes erfolgt durch Variablenzuweisung
innerhalb der AMaViS Konfigurationsdateien. Zunächst mussten die AMaViS
Grundfunktionalitäten Inhalt- und Virenfilterung aktiviert werden, bevor der installierte
Virenscanner in AMaViS bekannt gemacht und eingestellt werden konnte. Um den
konfigurierten Scanner ansprechen zu können, stellt AMaViS bereits vordefinierte
Schnittstellen zu den am weitesten verbreiteten Scannern bereit. Zur Prüfung des Inhalts einer
E-Mail greift AMaViS auf den bekannten Content-Filter SpamAssassin zurück. Dieser analysiert
die E-Mail durch verschiedenste Tests. Dabei wird das gleiche Konzept, wie bereits bei policydweight vorgestellt, angewendet. Jeder separat gewichtete Einzeltest wird auf den Inhalt
angewendet und ausgewertet. Die Summe der Werte der zutreffenden Tests wird als Score an
AMaViS zurückgeliefert. In AMaViS wird festgelegt, was mit der Mail bei entsprechendem
Score passieren soll. Neben dem unveränderten Weiterleiten, Verwerfen, Blocken oder
Zurückweisen mit Benachrichtigung (bouncen) einer Mail kann die Nachricht „getagged“
werden. In diesem Fall fügt AMaVis vor dem ursprünglichen Betreff einen zu definierenden
String ein. Aus dem Betreff „Termin kommende Woche“ wird so z.B. „ ***SPAM*** Termin
kommende Woche“. In diesem Setup hat man sich allerdings bewusst gegen das Markieren
von Mails entschieden. Sobald eine E-Mail als SPAM eingestuft wird, soll sie sauber abgelehnt
werden. Liegt der von Spamassassin ermittelte Score unter der definierten Grenze, wird sie
anstandslos zugestellt. Ein „dazwischen oder vielleicht“ verunsichert den Anwender mehr, als
es hilft. Auch die Funktion, den Absender über die Ablehnung zu informieren (bounce) sollte
wegen gefälschter Absenderadressen und der erwähnten Backscatter-Problematik nicht
verwendet werden. Neben der Inhalts- und Virenprüfung unterstützt AMaViS das Blocken
potentiell gefährlicher Dateianhänge wie .exe oder .msi Dateien. Der Dateityp wird dabei nicht
durch die Dateiendung, sondern durch das Tool „file“ ermittelt. Im Gegensatz zu den anderen
2 Prüfungen traf man die Entscheidung, die Empfänger der E-Mail über das Blocken zu
informieren. Die Option zur Benachrichtigung des Absenders bleibt jedoch auch bei geblockten
Anhängen deaktiviert. Wird ein Virus oder ein definierter Dateianhang erkannt, so wird immer
die gesamte Mail verworfen. Das Entfernen des u.U. schädlichen Anhangs wird nicht
unterstützt. Schlägt einer der genannten Prüfungen an, bricht AMaViS die SMTP
Kommunikation mit dem Postfix Prozess permanent mit 5xx-Fehlercode ab. Daraufhin beendet
Postfix den noch offen gehaltenen Dialog mit dem einliefernden MTA. So wird auch diese
Verbindung sauber getrennt, und das Senden einer problembehafteten Bounce Nachricht
entfällt. Wird hingegen keine Beanstandung gefunden, gibt AMaViS die Mail an den
Postfixservice auf dem separat eingerichteten Port zurück. Das Ergebnis der Tests hinterlegt
AMaViS im Header der E-Mail. Eingehende Mails auf diesem „Rückgabeport“ sind von der
SPAM- und Virenprüfung ausgeschlossen, und werden direkt weitergeleitet bzw. zugestellt.
Dies erfolgt an Hand der manuell konfigurierten Transport Map, in der die IP des Groupware
Systems für die entsprechende Ziel-Domain hinterlegt ist. Dort wird die Mail im
entsprechenden Benutzerpostfach abgelegt. Der Anwender kann nun über die verschiedenen
Michael Schrüfer
Matnr.: 2667118
Seite 20 von 38
Protokolle, wie POP3 oder IMAP auf die in der Datenbank abgelegten Nachrichten und
Informationen zugreifen. Für den Mailversand, ausgehend vom Groupware System wurde auf
diesem ebenfalls eine Transportregel eingerichtet, die alle Mails an den Mailhub zustellt.
3.4. Test und Inbetriebnahme
Als abschließende Prüfung wurde der gesamte Mailfluss getestet. Dabei wurde sowohl das
Weiterleiten, als auch das korrekte Blocken in verschiedenen Konstellationen überprüft.
Speziell präparierte E-Mails (EICAR Testvirus) wurden von AMaViS korrekt erkannt und
verworfen. Parallel dazu erfolgte die Überwachung und Analyse des Logfiles auf Fehler oder
Anomalien. Um die Aufgabe der Loganalyse und -auswertung komfortabel erledigen zu
können, wird die Datei einmal pro Tag von dem Tool pflogsumm durchsucht. Es sammelt u.a.
Informationen über die Anzahl der empfangenen sowie zugestellten E-Mails, sowie über Fehler
des Systems und stellt diese in einem übersichtlichen Bericht dem Administrator per Mail zur
Verfügung. Die Inbetriebnahme des Systems steht derzeit noch aus. In einer Übergangsphase
soll das neue System parallel zum alten betrieben werden. Dabei wird der Hostname des
neuen Systems mit einer Priorität von 20 als MX den entsprechenden DNS Zonen hinzugefügt.
Die alte Installation bleibt als MX mit einer Priorität von 10 am DNS Server bestehen. Nach
weiteren Tests soll die Sendmail-Instanz abgeschaltet werden. Für die einliefernden Systeme
erscheint danach die aktuelle Postfix-Installation als präferierter Mailserver, dem die Mails zur
endgültigen Zustellung übergeben werden.
Michael Schrüfer
Matnr.: 2667118
Seite 21 von 38
4. Erleichterung der Administration des Mailhubs
Ein Grund für die Ablösung des Sendmail-Mailhubs war die komplizierte Konfiguration und
aufwendige Wartung der veralteten Software. Die Situation konnte durch die Umstellung auf
Postfix/AMaViS bereits deutlich verbessert werden. Die Konfiguration des MTA (Mail Transfer
Agent) beschränkt sich auf 2 sehr gut dokumentierte Dateien. Das Verhalten zur Weiterleitung,
Umschreibung, Black- sowie Whitelisting kann durch sehr einfach strukturierte Lookup Tables
angepasst werden.
4.1. Aufgabendefinition
Trotz der Erleichterungen, die durch die Umstellung der Software erreicht wurden, stellt die
Verwaltung des Systems einige Administratoren vor Probleme. Insbesondere wenn die
Wartung nicht zum Alltagsgeschäft, sondern z.B. nur im Vertretungsfall übernommen werden
muss, erscheint die Konstellation und das Zusammenspiel der verschiedenen Komponenten
äußerst komplex. Dazu kommt die Vielzahl der, von Postfix zur Verfügung gestellten Tools,
insbesondere zur Verwaltung der Mail-Queues. Das richtige Programm für die jeweilige
Aufgabe zu finden und anzuwenden, gestaltet sich trotz Bedienungsanleitung oft schwierig.
Aus diesen Gründen sollen einfach strukturierte, dialogbasierte Skripte geschaffen werden,
über die man die wichtigsten Aufgaben, auch ohne tiefes Verständnis der Software erledigen
kann. Hauptaugenmerk soll dabei auf die Implementierung von Funktionen zur QueueVerwaltung und zum Notfallmanagement gelegt werden. Eine weitere
Administrationsschnittstelle soll die Pflege der Black- und Whitelists, sowie die Anzeige der
Logdateien erleichtern. Hierfür soll dem Administrator größtmöglicher Komfort geboten und
die Bedienung nach Möglichkeit ohne Kommandozeilenkenntnisse ermöglicht werden. Dabei
sollen die Erleichterungen unter keinen Umständen zu einer Beeinträchtigung der
Systemsicherheit führen. Diese hat immer an erster Stelle zu stehen, da das System direkt vom
Internet aus kontaktiert werden muss. Außerdem sollen, wie im gesamten bisherigen
Projektverlauf, keine Lizenzkosten entstehen. Präferiert wurde die Verwendung einer
bestehenden Lösung, die um einzelne, projektbezogene Aspekte erweitert werden kann.
4.2. Analyse der am Markt existierende Lösungen
Auf Grund der weiten Verbreitung der implementierten Postfix/AMaViS Lösung sollten
zunächst existierende Administrationsskritpe und –masken auf ihre Tauglichkeit geprüft
werden. Für die Administration eines Postfix-Mailservers mit einfacher und überschaubarer
Konfiguration waren diverse Lösungen schnell ausfindig gemacht. Diese basieren zu einem
großen Teil auf einer in Skriptsprachen wie Perl oder PHP geschriebenen Webschnittstelle.
Konfigurationsparameter und –informationen werden in der Regel in einer (MySQL)
Datenbank gespeichert. Bei Recherchen stellte sich das Webinterface „PostfixAdmin“ als die
am weitesten entwickelte, komfortabelste Lösung heraus. Es war allerdings schnell erkennbar,
dass die Funktionalität aller Web-Schnittstellen an den Anforderungen vorbeiging. So boten
diese zwar äußerst nützliche Möglichkeiten zur komfortablen Konfiguration eines Postfix
Mailservers mit lokalen Postfächern, mehreren Domains, Weiterleitungen usw. Leider fehlten
dafür aber grundlegende Fähigkeiten zur Verwaltung der Mailhub-spezifischen Funktionen.
Dazu bot keine der betrachteten Lösungen die Integration der verschiedenen Komponenten
und Programme wie Postscreen oder Postgrey unter einem einheitlichen Userinterface. Im
AMaViS Umfeld stellt sich die Situation besser dar. Das Web Frontend „WebAvis“ bot alle
Michael Schrüfer
Matnr.: 2667118
Seite 22 von 38
geforderten Funktionalitäten. Leider allerdings auch bedeutend mehr als nur diese, was die
Konfiguration entsprechend unübersichtlicher und auch riskanter für Fehler in der
Konfiguration macht. Das einzusetzende Interface soll lediglich Zugriff auf ausgewählte,
insbesondere für die Sicherheit des Systems unkritische Konfigurationsmöglichkeiten bieten,
sodass es ohne Gefahr auch von nicht explizit geschultem Personal bedient und verwendet
werden kann. Durch die Abschätzung des Aufwands zur Anpassung der existierenden Lösungen
wurde dieser Ansatz zu Gunsten einer Eigenentwicklung verworfen. Ähnlich verhielt es sich bei
den konsolenbasierten Skripten. Bis auf das Tool „qtop“ von Peer Heinlein zur Überwachung
der verschiedenen Queues, war kein Tool für die projektspezifische Umsetzung geeignet, ohne
nicht gleichzeitig die Komplexität übermäßig zu steigern.
4.3. Implementierung konsolenbasierte Skripte
Postfix bringt zur Verwaltung der Mailqueues und Lookup Tables von Haus aus diverse
Programme mit, die den gesamten benötigten Funktionsumfang abdecken. Nicht immer
einfach zu entscheiden ist allerdings, welches Programm, mit welchen Parametern für welche
Aufgabe aufzurufen ist. Hier sollen die Verwaltungsskripte ansetzen und einen Weg für die
Analyse und Lösung der am häufigsten auftretenden Probleme vorgeben. Um dem
Administrator einen möglichst einfachen Zugang zu den einzelnen Funktionen zu ermöglichen,
sind alle über den einzigen Befehl „mailadmin“ erreichbar. Die jeweilige Aktion wird durch
darauf folgende Argumente bestimmt. Bei fehlenden oder fehlerhaften Argumenten wird ein
Hilfetext mit den gültigen Argumenten ausgegeben(Abbildung 4.3.a). Da für einen Großteil der
zur Verfügung gestellten Methoden nur existierende Systemprogramme im Hintergrund
aufgerufen werden, stellte sich die Skriptsprache bash als die am geeignetste
Programmiersprache heraus. Während einfach zu implementierende und vom Code-Umfang
kleine Funktionen direkt in das Skript mailadmin aufgenommen wurden, wurden die
umfangreichen Methoden zur Queue- und LookupTable-Verwaltung in eigene Skripte
ausgelagert, die im Hauptskript (mailadmin) lediglich aufrufen werden. Um die Änderungen in
einem LookupTable für Postfix zu aktivieren, muss die Text- in eine Hashdatei gewandelt
werden. Bei vielen Änderungen in den verschiedenen Textfiles kann dies schnell
unübersichtlich werden, wodurch die Gefahr besteht, eine Datei zu vergessen. Das „Teil-“
Skript postall.sh sammelt die Pfade zu allen Textdateien, und führt auf jeder separat den
Befehl zum Erzeugen der Hash-Datei aus. Um sicherzustellen, dass Änderungen an den
Textdateien nach einem kompletten Neustart aller E-Mail Dienste übernommen werden, ist
das postall.sh Skript der Funktion zum koordinierten Neustart vorangestellt. Um einen
Überblick über aktive Dienste und die Verfügbarkeit dieser zu erhalten, existiert das Skript
mailstatus.sh. Dieses prüft die Verfügbarkeit der für den Mailfluss relevanten Dienste und gibt
den Status gesammelt aus. Dabei wird sowohl der Prozess als auch der Port, auf dem derselbe
lauscht abgefragt. Teile dieses Skripts werden auch für die im vorangegangenen Abschnitt
erwähnte Überwachung via Nagios eingesetzt. Um eine direkte Rückmeldung über den Erfolg
bzw. Misserfolg des Neustarts der Dienste zu erhalten, wird das mailstatus.sh Skript im
Anschluss daran automatisch ausgeführt. Eine wichtige Kenngröße für den Zustand des
Mailservers, die in diesem Zusammenhang mit ausgegeben wird, ist die Auslastung der
Mailqueues. Alle via SMTP eingehenden Nachrichten landen zunächst in der IncommingQueue. Diese fungiert als eine Art Wartezimmer vor der Active-Queue, die nur eine gewisse
Anzahl von Elementen zum gleichen Zeitpunkt zulässt, um den Postfix Prozess nicht zu
überlasten. Kann eine E-Mail aus der Active Queue nicht zugestellt werden, landet sie in der
Michael Schrüfer
Matnr.: 2667118
Seite 23 von 38
deferred Queue. In regelmäßigen Abständen werden diese nicht zustellbaren Nachrichten
wieder in die Active Queue verschoben, um so einen weiteren Versuch zu starten. Durch den
Parameter maximal_queue_lifetime wird die maximale Lebenszeit einer nicht zustellbaren
Nachricht bestimmt. Insbesondere eine hohe Anzahl von Elementen in der „deferred-Queue“
ist ein Indikator für einen Fehler am System. Auf Grund dieser zentralen Stellung und
vielfältiger Steuerungs- und Verwaltungsmöglichkeiten der Queue(s) wurden die
entsprechenden Funktionen in das eigeständiges bash-Skript „qadmin“ ausgelagert. Nach dem
Start des Programms werden dem Anwender die möglichen Aktionen aufgelistet (Abbildung
4.3.b). Diese lassen sich grob in 2 Gruppen teilen. Ein Teil bezieht sich auf das Queue-System
selbst und hat Einfluss auf alle Mails in der Queue. Dazu zählt u.a. das „Flushen“
(Zustellungsversuche wiederholen) oder das Restrukturieren der Queue. Der andere Teil der
Aktionen bezieht sich auf ein spezielles Element innerhalb der Queue. Jede Mail in der Queue
ist eindeutig über die Message ID identifizierbar. Durch die Angabe dieser ID kann eine E-Mail
explizit neu zugestellt, zurückgehalten, gelesen oder auch gelöscht werden. Im Programm
erfolgt die Eingabe der ID nach der Auswahl einer entsprechenden Aktion. Abschließend wird
der neue Zustand der Queue als Übersicht auf der Konsole ausgegeben. Aus dem gleichen
Kontext kann das von Peer Heinlein entwickelte Tool qtop1, welches eine dem Unix Tool top
ähnliche Übersicht über den aktuellen Queuestatus liefert, aufgerufen werden. Neben den, auf
die Eigenschaften eines Mailservers bezogenen Funktionen, wurde in dem Mailadmin-Skript
auch eine Methode zur Aktivierung und Überprüfung des Firewallstatus integriert. Eine lokal
installierte Firewall ist für die Sicherheit des Systems unabdingbar. Der, auf der OSI Schicht 3
und 4 angesiedelte Paketfilter erlaubt nur die zwingend notwendige Kommunikation, um die
benötigte Funktionalität zu ermöglichen.
4.4. Implementierung einer php-Administrationsmaske
Da insbesondere die täglichen Routinearbeiten auch ohne tiefe Kenntnisse über die Bedingung
der Linux Konsole erfolgen können sollen, musste eine weitere Schnittstelle insbesondere für
den Zugriff auf Konfigurationsdateien geschaffen werden. Dabei soll allerdings nicht das
Konsolentool 1:1 auf eine andere Plattform portiert werden. Vielmehr soll der
Funktionsumfang durch eine 2te Applikation erweitert werden. Um zu vermeiden, dass sich
über das für jedermann zu bedienende Interface kritische Fehler in das System einschleichen,
wurden lediglich für die Systemsicherheit unkritische Funktionen implementiert. Für eine
tiefergehende Konfiguration des Systems sollen bewusst detaillierte Systemkenntnisse
vorausgesetzt werden.
Um die Anzeige der Webseiten zu ermöglichen, war es erforderlich, diverse Softwarepakete
auf dem Serversystem nachzuinstallieren. Dazu zählt insbesondere der Apache Webserver mit
php-Unterstützung. Im Hinblick auf zukünftige Funktionen wurde vorab schon eine MySQL
Datenbank direkt auf dem Server installiert. In ihr sollen alle für das E-MailSystem relevanten
Log-Einträge gesammelt werden. Eine komfortable Ausgabe zur Analyse derselben wird als
PHP Seite realisiert. Die Entwicklung der Administrationsmasken musste direkt auf dem
Mailsystem erfolgen, da dessen Administration, zumindest in Teilen in ihnen abgebildet
werden soll. Da jedoch die Funktionalität des fertigen Postfix-Mailhubs nicht durch Fehler oder
Funktionstests beeinträchtigt werden sollte, wurde ein Klon der virtuellen Maschine erzeugt.
1
Peer Heinlein: Das Postfix Buch. Sichere Mailserver mit Linux – S. 451
Michael Schrüfer
Matnr.: 2667118
Seite 24 von 38
So stand das System mit dem kompletten Funktionsumfang des Mailservers als Kopie zur
Verfügung. Auf dieser konnte die Entwicklung und die Tests ohne Beeinträchtigung des
produktiven Systems erfolgen. Des Weiteren wurde vor jeder Änderung einer
Systemkonfiguration ein Snapshot der virtuellen Maschine angelegt. Durch diese Funktionalität
konnte auf einfache Art und Weise eine fehlerhafte Konfiguration zurückgenommen werden.
Vor der Programmierung wurde auf Grund des Umfangs des Projekts eine Ordnerstruktur zur
Ablage der einzelnen Dateien angelegt. Insbesondere zur Organisation und besseren Übersicht
über die PHP Klassen war diese Strukturierung notwendig (Abbildung 4.4.a). Da keine weitere
Webanwendung über diesen Webserver betrieben werden soll, wurden die Ordner direkt im
Stammverzeichnis (www-root) des Apache Servers erstellt. Unmittelbar in diesem Verzeichnis
befinden sich neben der Startseite des Projekts 24 für die Funktionalität des Systems wichtige
Konfigurationsdateien. Eine entscheidende Rolle spielt die Datei „common.php“. Sie wird in
jedem direkt ausgeführten PHP Skript eingebunden. Über diese Datei wird sichergestellt, dass
absolute Pfade, alle Klassen sowie Funktionen gefunden werden. Die dafür notwendigen
Informationen bezieht sie aus den folgenden Dateien. Das PHP Element „settings.php“ enthält
systemweit gültige Definitionen von Konstanten. Dazu zählt u.a. der Name des Projekts, der
auf jeder Seite als HTML Titel verwendet werden soll, sowie die Informationen zum Herstellen
der Datenbankverbindung. Um den Zugriff auf referenzierte Dateien sicherzustellen, wurden
die projektrelevanten Pfadangaben in der „path.php“ hinterlegt. Die Datei
„includeAllClasses.php“ enthält Pfadangaben zu allen im System vorhandenen Klassen. Da
auch sie in die common.php eingebunden ist, ist die Erstellung von Objekten in jeder PHPDatei möglich, ohne die Klasse separat in jeder Datei bekannt machen zu müssen. Nach dem
Einbinden der 3 Dateien wird in der common.php ein global verfügbares MySQL DatenbankObjekt erstellt. Man erspart sich dadurch die Programmierung des Datenbankzugriffs in jeder
einzelnen Datei, und kann auf das global verfügbare DB-Objekt zugreifen. Der
Funktionsumfang wurde auf 2 Bereiche aufgeteilt (Abbildung 4.4.b). Der eine sollte ohne
Authentifizierung für jedermann zugänglich sein, der andere nur nach erfolgreicher Anmeldung
am System. Da das Ändern der Konfiguration nur durch berechtigtes Personal erfolgen können
soll, müssen die entsprechenden Seiten vor unberechtigtem Zugriff geschützt werden. Die
Elemente des öffentlich erreichbaren Bereichs beschränken sich auf die Seite zur
Benutzeranmeldung. Diese Seite nimmt eine besondere Stellung im System ein, da sie die
einzige von „außen sichtbare“ ist. Die von ihr bereitgestellte Funktionalität der
Benutzerauthentifizierung definiert zum Großteil die Sicherheit des Gesamtsystems. Um hier
so wenig Angriffsfläche wie möglich zu bieten, ist das Formular zur Eingabe der
Benutzerinformationen das einzig aktiv zu bedienende Element auf dieser Seite. Im Quellcode
wird diese Aufgabe in der Klasse „Login“ realisiert. Sie enthält sowohl die Methode zur
Ausgabe des Anmeldeformulars als HTML Seite, als auch die Methode zur Prüfung der
übergebenen Login-Daten, bestehend aus Benutzername und Kennwort. Diese Daten werden
beim Login mit den in einer bestimmten MySQL Tabelle abgelegten Benutzerinformationen
abgeglichen. Da die Textfelder zur Eingabe von Benutzername und Kennwort zunächst
ungeschützt von jedermann verwendet werden können, sind besondere Vorkehrungen zu
treffen, um zu verhindern, dass schadhafter Code in die Anwendung oder zur MySQL
Datenbank durchgereicht wird. Die von PHP für den Zweck der sicheren Maskierung von
2
Stefan Reimers, Gunnar Thies: PHP 5.4 und MySQL 5.5 – S. 591
Michael Schrüfer
Matnr.: 2667118
Seite 25 von 38
Zeichen bereitgestellte Funktion „mysqli_real_escape_string()“, kommt hier nicht zum Einsatz.
Um die übergebenen Daten mit den in der Datenbank gespeicherten Informationen
abzugleichen, wird dem Select-Statement lediglich der erste Buchstabe des Logins übergeben.
Die Abfrage liefert Array mit der Kombination aus Benutzernamen und Kennwort für alle
Benutzerkonten mit den entsprechenden Anfangsbuchstaben zurück.
$firstChar = substr($_POST['login'],0,1);
$sql = "SELECT login,password FROM user WHERE login LIKE '".$firstChar."%'";
In einer darauf folgenden Schleife wird das zurückgegebene Feld durchlaufen, und mit den aus
dem Formular übergebenen Daten abgeglichen. Auf diese Weise ist sichergestellt, dass kein
schädlicher Code die Datenbank erreicht. Während der Benutzername ohne Anpassungen auf
Gleichheit geprüft werden kann, wird vom Passwort ein MD5 Hash-Wert erzeugt, und dieser
mit der aus der Datenbank erhaltenen Prüfsumme verglichen. Wurde eine passende
Kombination der Daten gefunden, wird die PHP Session gestartet, und u.a. der Benutzername
in einer Session-Variablen gespeichert. Direkt nach dem erfolgreichen Login erfolgt die
automatische Weiterleitung in den internen Bereich der Anwendung. Auf der ersten Seite
erhält der Administrator eine Übersicht über den Zustand des Systems, sowie über wichtige
Konfigurationsparameter. Die ausgegebenen Informationen werden im Hintergund von
statischen Funktionen der Klasse „Information“ gesammelt. Dazu wird auf im Betriebssystem
oder von Postfix bereitgestellte Programme zurückgegriffen. Dies wird zumeist über die PHP
Funktion „shell_exec(<Kommandozeilenbefehl>)“ realisiert, welche einen
Kommandozeilenbefehl ausführt, und dessen Konsolen-Ausgabe zurückgibt. Um die Sicherheit
des Systems gewährleisten zu können, wird der Webserverprozess unter einem Benutzer ohne
priviligierte Rechte ausgeführt. Da zur Ermittlung einiger Informationen root-Rechte benötigt
werden, mussten die Berechtigungen des Users „www-data“, unter dem der Apache-Prozess
läuft, erweitert werden. Für diesen Zweck stellt Linux das Programm „sudo“ zur Verfügung.
Mit diesem ist es u.a. möglich, als nicht-priviligierter Benutzer, Programme als root
auszuführen. Der folgende Ausschnitt aus der sudo-Konfigurationsdatei zeigt die Definition der
erlaubten Programme.
www-data ALL = NOPASSWD:/opt/mailadminWebApp/version.sh
Der Unix-Benutzer www-data darf nun ohne Passwortabfrage das Programm version.sh „mit
root-Rechten“ ausführen. Dem Aufruf des Programms aus dem PHP Skript heraus wird das
Kommando „sudo“ vorangestellt.
$ret['postfix'] = shell_exec("sudo /opt/mailadminWebApp/version.sh postfix");
Neben der Status-Übersicht bietet der interne Bereich die Möglichkeit der Pflege von Blackund Whitelists. Die meisten der während des SMTP Dialogs durchlaufenen Schritte (Prozesse)
bieten seperate und unabhängige Dateien zur Pflege individueller Listen an. So greift der Filter
Postscreen, der sich zu Beginn der SMTP Kommunikation befindet, auf andere Files im
Dateisystem zurück, als Amavis. Auch das Format und die Art der Information unterscheidet
sich je nach Prüfprozess. Während der Filter für Absender-Adressen eine Textdatei im
Pseudotabellenformat, bestehend aus 3 Spalten (Absenderadresse, Aktion, optional RejectGrund) erwartet, setzt der Greylisting Daemon Postgrey eine Textdatei mit einer Spalte, die
nur IP Adressen oder Hostnamen enthält, voraus. Für jedes zu unterstützende Format steht
eine seperate „Filehandler-Klasse“ zur Verfügung, die für das Auslesen, Bearbeiten und
Zurückschreiben des Dateiinhalts zuständig ist. Für jede Zeile einer Datei wird beim Auslesen
Michael Schrüfer
Matnr.: 2667118
Seite 26 von 38
durch den FileHandler eine Instanz der passenden „FileEntry“-Klasse erstellt, um die
ausgelesenen Informationen darin abzulegen, und komfortabel in einer Liste verwalten zu
können. Für die Anzeige und Bearbeitung der Daten existiert für jeden Black-/Whitelisting
Vorgang eine PHP Datei, die die jeweils benötigte FileHandler-Klasse instanziiert und den Pfad
zur Datei im Filesystem angibt.
$myFile = new System\dreiSpaltenFileHandler("/etc/postfix/lookup/access_sender");
Zusammengefasst wird also ein Schritt der Filterung durch 3 Elemente abgebildet. Die für den
Anwender der PHP Applikation sichtbare Datei z.B. accessSender.php, welche Einträge einer
Datei auflistet, die entsprechende FileHandler Klasse, die den Zugriff auf die im Dateisystem
gespeicherten Textdateien verwaltet, und der FileEntry Klasse, die eine Zeile darstellt, und
damit eine Regel im Filtersystem repräsentiert.
Neben der Funktion zum Zugriff auf Dateisystemelemente stellt die FileHandler Klasse auch die
Methoden zum Löschen bestehender, sowie zum Einfügen neuer Regeln bereit. Während die
Funktion zum Löschen existierender Regeln sehr einfach und ohne weitere Prüfung
angesprochen werden kann, ist der Einfügeoperation ein Filter vorgelagert. Dieser Filter ist
notwendig, um falsche Informationen in den Lookuptables und Konfigurationdateien zu
verhinden. So wird in der access_sender Lookup Table z.B. eine E-Mail Adresse oder ein
Domainname erwartet. Die Eingabe einer IP Adresse wäre nicht nur logisch falsch, sondern
würde unter Umständen sogar zu einer Fehlfunktion des Mailserversystems führen. Die in
einer Vererbungshierarchie implementierten konkreten Filter-Klassen stellen ihre PrüfFunktion über die Methode „checkInput“ bereit, die vor dem Aufruf der Einfüge-Operation die
einzufügenden Daten überprüft. Wie auch der Lösch- setzt sich der Einfüge-Mechanismus aus
3 Schritten zusammen. Zunächst wird das ensprechende File-Entry Element aus dem Array,
welches als Variable der FileHandler Instanz im Speicher gehalten wird, gelöscht bzw.
angehängt. Anschließend wird der gesamte Inhalt des Arrays durch die Methode
„writeToFile()“ in die entsprechende Textdatei auf dem Dateisystem geschrieben, bevor die
Änderungen entweder durch Aktualisieren einer HashDatei oder durch den Neustart eines
Prozesses aktiviert werden. Die insbesondere zum Neustart von Prozessen notwendigen
„priviligierten Rechte“ werden wie auf der Status-Seite bereits angewendet, durch „sudo“
erlangt. Neben dem Recht, Programme auszuführen, muss auch das Lesen und Schreiben der
Textdateien für den Eigentümer des Webserverprozesses (www-data) ermöglicht werden. Da
das von Linux standardmäßig zur Verfügung gestellte Rechtesystem keine ausreichend
detaillierte Rechtevergabe ermöglichte, wurde das Grundsystem um die Funktionalität von File
System Access Controll Lists erweitert. Hierdurch konnten dem www-data User explizit nur die
Rechte auf Dateien zugewiesen werden, die er für seine Arbeit benötigt.
# getfacl access_sender
…
user:www-data:rw…
Auf Basis dieser Architektur konnten die Masken zur Pflege der Black-/Whitelists für die
Filtermodule Postscreen, Client Access, Sender Access, Greylisting sowie Amavis ohne größere
Anpassungen erstellt werden.
Um im Fall einer fehlerhaft geblockten E-Mail den Whitelist-Eintrag an der richtigen Stelle im
Mailfluss setzen zu können, ist eine genaue Analyse der Logmeldungen notwendig. Postfix und
Michael Schrüfer
Matnr.: 2667118
Seite 27 von 38
seine Partnerkomponenten schreiben zu jeder verarbeiteten E-Mail, egal ob erfolgreich
zugestellt, oder auf Grund von Fehlern verworfen, Einträge in eine definierte Logdatei. Um den
Inhalt dieser komfortabel ausgeben und durchsuchen zu können, werden die Nachrichten
neben der Datei noch in die bereits vorhandene MySQL Datenbank geschrieben. Dazu wird
eine einfach strukturierte Tabelle angelegt. Das eingesetzte Linux-Log System syslog-ng,
welches eine Schnittstelle zu externen Programmen von Haus aus bereit stellt, musste lediglich
um die MySQL Datenbank als verfügbares Ziel erweitert werden. Damit nur für die MailKommunikation relevante Log-Ereignisse in die definierte Tabelle geschrieben werden, filtert
f_mail nur die Meldungen des Bereichs (facility) „mail“ aus dem gesamten log-Strom heraus.
filter f_mail { facility(mail) … };
destination d_mysql { program("/usr/bin/mysql --user=xxx --password=xxx app01 "
template("INSERT INTO logs (host, … '$MSG' );\n") template-escape(yes)); };
log { source(s_src); filter(f_mail); destination(d_mysql); };
Die nun in der Datenbank enthalteten Log-Meldungen können via SQL sehr einfach durchsucht
werden. Auch der Zugriff über das Webinterface auf die Logmeldungen lässt sich so wesentlich
komfortabler handhaben, als der Zugriff über reine textbasierte Logfiles. Die Umsetzung dieser
Funktionalität des Webinterfaces konnte insbesondere durch die globale Verfügbarkeit des
MySQL Objekts zügig umgesetzt werden. Die Ausgabe der Messages erfolgt seitenweise mit
maximal 100 Einträgen pro Seite. Die in die Seite integrierte Suchmaske erleichtet das Finden
von relevanten Logmeldungen. Dabei werden die gefundenen Textstellen farblich
hervorgehoben. Der Verlauf eines Zustellungsversuches lässt sich anhand der selben MessageID identifizieren. Da sich diese am Anfang jeder Logmeldung in einem definierten Format
befindet, wird diese bei jeder Anzeige über einen regulären Ausdruck erkannt, und mit einem
Hyperlink versehen. Dieser verweist auf die gleiche Seite, aktiviert jedoch einen Filter, um nur
die zu diesem Zustellungsversuch passenden Nachrichten anzuzeigen. Um ein Überlaufen der
Partition mit nicht mehr benötigten Log-Einträgen zu vermeiden, wird via Cron Job täglich ein
Skript ausgeführt, welches alte Nachrichten aus der Datenbank entfernt. Als letzte Funktion
des internen Bereichs wurde das Abmelden durch das „Zerstören“ der Session und das damit
verbundene Löschen aller Session Variablen implementiert.
5. Sonstiges
5.1. Netzwerkmanagement mit Cisco Prime
Das Netzwerk des Klinikums besteht zum überwiegenden Teil aus Komponenten der Firma
Cisco. Um eine möglichst detaillierte Überwachung dieser zu ermöglichen, wurde das auf die
Cisco-Geräte zugeschnittene Managementportal „Cisco Prime Infrastructure“ gewählt und
über eine Virtual Appliance in die vorhandene Infrastruktur integriert. Zudem ermöglicht die
Software eine einfache Konfiguration und Verwaltung der Komponenten. Dazu zählt
insbesondere die Sicherung und Revisionierung existierender Konfigurationsdateien, die im
Fehlerfall wiederhergestellt werden können. Damit die Appliance ihre Aufgaben erledigen
kann, und sich mit den Zielsystemen verbinden kann, sind auf dieser einige Anpassungen
notwendig. Maßgeblich ist hierbei der SNMP- und Telnet-Zugriff. Während SNMP lediglich zum
Auslesen von Informationen und Parametern verwendet wird, dient der Telnet-Login zur
Michael Schrüfer
Matnr.: 2667118
Seite 28 von 38
Konfiguration der Geräte. Dazu wird auf den Geräten eine neue SNMP Read Only Community
angelegt. Der Name dieser wurde komplex gewählt, da er als Authentifizierungsmechanismus
dient. In der Appliance ist anschließend das Gerät mit den definierten Parametern
hinzuzufügen.
Nach einer kurzen Inventarisierungsphase stehen die Monitoring- und
Managementfunktionaltiäten über ein Webinterfache zur Verfügung.
5.2. Planung eines Oracle Real Applicantion Cluster (RAC)
Eine zentrale Datenbank des Klinikums soll von einer single Instance Lösung auf eine
hochverfügbare Infrastruktur, bestehend aus 2 Datenbank-Knoten migriert werden. Da es sich
um eine Oracle Datenbank handelt, wird ein Real Application Aktiv/Aktiv Cluster (RAC)
installiert. Um den Mitgliedern dieses Application Clusters den Zugriff auf eine gemeinsame
Datenbasis zu ermöglichen, musste ein „Shared Storage“ für die 2 Knoten bereitgestellt
werden. Auf Grund der Erfahrungen im Bereich der Servervirtualisierung fiel die Entscheidung
auf die Storage-Virtualisierungsoftware der Firma DataCore. Diese ermöglichte den Aufbau
einer redundanten Storagestruktur, flexible Verwaltung der Speichereinheiten, sowie die
Bereitstellung logischer Datenträger via FibreChannel. Diese konnten auf den Oracle-Servern
eingebunden werden, durften jedoch nicht initialisiert und formatiert werden. Die Aufgabe des
Volume Managers wird in RAC Umgebungen ausschließlich vom Automatic Storage Manager
(ASM) übernommen. Diese von Oracle mitgelieferte Komponente stellt das Dateisystem für
datenbankinterne Dateien wie den Datafiles oder Redologs bereit. Die erweiterten ASMFunktionen wie Mirroring oder Stripping werden in diesem Setup nicht genutzt, da sie bereits
durch die dahinterliegende Storage-Infrastruktur abgedeckt sind. Das Multipathing wird über
DataCore Treiber aufgelöst, sodass jeweils nur eine Instatz des Storage für den ASM sichtbar
ist. Daneben initiiert der Treiber ein Umschwenken des aktiven Pfades im Fehlerfall. Die
Ausfallsicherheit und Lastenverteilung des Datenbankzugriffs wird über eine Verteilung der
Listener Prozesse auf die 2 Nodes realisiert. Den 3 eingerichteten Listenern ist je eine virtuelle
IP zugeordnet, die via DNS Round Robin von den Clients in rotierender Reihenfolge aufgelöst
wird. Fällt ein Mitglied des Clusters aus, werden die Listener Prozesse von einem noch aktiven
Knoten übernommen. Die Kommunikation der Rechner im Cluster untereinander erfolgt über
eine dedizierte Cluster Interconnect Verbindung, über die unter anderem das verteilte
Sperrmanagement organsiert und geregelt wird (Abbildung 5.2.a). Die konkrete Umsetzung
der Migration und der Konfiguration des Clusters ist in naher Zukunft geplant.
Michael Schrüfer
Matnr.: 2667118
Seite 29 von 38
6. Anhang
Abbildung 2.1.a (Verteilung der Tickets auf Queues/Bearbeiter)......................................................... 31
Abbildung 2.4.a (OTRS Einrichtung Genericinterface) .......................................................................... 31
Abbildung 2.4.b (Ablauf Ticket-Weitergabe)......................................................................................... 32
Abbildung 3.1.a (Integration des Mailhubs in die DMZ) ....................................................................... 33
Abbildung 3.3.a (Interner Verarbeitungsfluss)...................................................................................... 33
Abbildung 4.3.a (mailadmin Bash-Skript) .............................................................................................. 34
Abbildung 4.3.b (qadmin Bash Skript)................................................................................................... 34
Abbildung 4.4.a (Auszug aus Klassendiagramm der PHP Anwendung) ................................................ 35
Abbildung 4.4.b. (Organisation der Seiten) ........................................................................................... 36
Abbildung 5.2.a (RAC Infrastruktur) ...................................................................................................... 37
Michael Schrüfer
Matnr.: 2667118
Seite 30 von 38
Abbildung 2.1.a (Verteilung der Tickets auf Queues/Bearbeiter)
Abbildung 2.4.a (OTRS Einrichtung Genericinterface)
Michael Schrüfer
Matnr.: 2667118
Seite 31 von 38
Abbildung 2.4.b (Ablauf Ticket-Weitergabe)
eingabe.php – Erfassung der Daten
toOtrs.php Übergabe der Daten
an OTRS
Ansicht des Tickets im OTRS
ausgabe.php – Ausgabe der Daten zur Störmeldung
Michael Schrüfer
Matnr.: 2667118
Seite 32 von 38
Abbildung 3.1.a (Integration des Mailhubs in die DMZ)
DMZ
Internet
Mailhub
Intern
Exchange Server
Abbildung 3.3.a (Interner Verarbeitungsfluss)
Einliefernder Mailserver
SMTP
Postfix-Postscreen TCP :25
Postfix SMTP Daemon
- Client Access
- Halo Access
- Sender Access
- Receipient Access
RAV
RBL
TCP
policyd-weight :12525
TCP
Postgrey :10023
SMTP
AMaViS :10024
- RBL Score
- helo – Checks
- mail from: - Checks
- rcpt to: - Checks
RBL DNS Server
Greylisting
- Erster Versuch mit
4xx ablehnen
- Content Scan
(SpamAssassin)
- Viren Prüfung
(ClamAV)
SMTP
Postfix SMTP Daemon : 10025
SMTP
Groupware
Server
Michael Schrüfer
Matnr.: 2667118
Seite 33 von 38
Abbildung 4.3.a (mailadmin Bash-Skript)
Abbildung 4.3.b (qadmin Bash Skript)
Michael Schrüfer
Matnr.: 2667118
Seite 34 von 38
Abbildung 4.4.a (Auszug aus Klassendiagramm der PHP Anwendung)
System::FileEntry
System\Database::MySQL
System::DebugConsole
+MySQLiObj
+lastSQLQuery
+lastSQLStatus
+query()
+escapeString()
+makeArrayResult()
+doLog()
+handleAction()
+displayConsole()
+printCode()
System::1SpaltenEntry
System::3SpaltenEntry
+spalte1
+spalte1
+spalte2
+spalte3
System::2SpaltenEntry
+spalte1
+spalte2
System::myFileHandler
#content
#path
#lines
#log
+readFile()
+delLine()
+writeToFile()
+printContent()
+insertLine()
System::dreiSpaltenFileHandler
System::HTML
+printHead()
+printFoot()
+printArray()
System::einSpaltenFileHandler
System::HTMLIntern
System::zweiSpaltenFileHandler
Scripts::Login
System::Security
+printLoginForm()
+checkLoginData()
+checkMyLoginStatus()
+verifyPassword()
Scripts::InputFilter
System::Information
+getServerName()
+getWWWsw()
+getDiskUsage()
+getMemUsate()
+getQueueStatus()
+getSMTPInfo()
+getVersionInfo()
+getPostfixConfig()
System::HTMLExt
+printNav()
+printHeadLine()
+printAddNewLine1Spalte()
+printAddNewLine2Spalte()
+printAddNewLine3Spalte()
+printBody()
System::SessionHandler
+open()
+clase()
+read()
+write()
+destroy()
+gc()
+checkInput()
System::mySessionHandler
Scripts::myIPFilter
Michael Schrüfer
Scripts::myEMailFilter
Matnr.: 2667118
Seite 35 von 38
Abbildung 4.4.b. (Organisation der Seiten)
Index.php
Intern
status.php
accessPostscreen.php
accessClient.php
accessSender.php
greylistClient.php
amavisBlacklist.php
amavisWhitelist.php
logAna.php
Michael Schrüfer
Matnr.: 2667118
Seite 36 von 38
Abbildung 5.2.a (RAC Infrastruktur)
StorageServer1
StorageServer2
FC-Switch
FC-Switch
FC-Switch
FC-Switch
ASM Instanz1
ASM Instanz2
Interconnect
OracleNode1
OracleNode2
Listener
Pool
DNS RR
Klinikum Netzwerk
Michael Schrüfer
Matnr.: 2667118
Seite 37 von 38
7. Literaturverzeichnis
OTRS 3.1 - Developer Manual
OTRS 3.1 - Admin Manual
Peer Heinlein: Das Postfix Buch. Sichere Mailserver mit Linux
Ralf Hildebrandt, Patrick Ben Koetter: Postfix: Einrichtung, Betrieb und Wartung
Stefan Reimers, Gunnar Thies: PHP 5.4 und MySQL 5.5
Andrea Held, Mirko Hotzy, Lutz Fröhlich: Der Oracle DBA
Michael Schrüfer
Matnr.: 2667118
Seite 38 von 38