Wer sicher gehen möchte nicht vom Wohl und Wehe der Betrieber abhängig zu sein und diesen seine intimsten Daten nicht anvertrauen möchte der kommt um des Betreiben eigener Infrakstruktur nicht herum. Ist das bei Web oder Fileservern noch eher trivial , so erfordert die Implementierung eines eigenen Mailservers schon einiges an Wissen und Verständnis. V-Server sind mittlerweile darart günstig daß sich ein eigener Mailserver im RZ im Vergleich zu einem kostenpflichtigen Postfach nicht nur schnell rechnet , er ermöglicht auch individuelle Konfigurationen wie Spamfilter-Regeln- Sortierung über Sieve, Black und Greylisting, verwalten des Email-Verkehrs für mehrere Domänen usw.
War früher sendmail als MTA der Platzhirsch und seine Konfiguration die Feuertaufe für Mailserver-Admins, so ist der inzwischen hoffnungslos veraltete MTA durch postfix und exim ersetzt worden. Als MDA hat sich Dovecot durchgesetzt. Musste man früher mühsam jede einzelne Komponente einzeln installieren und konfigurieren, so bieten sich heute komplette Mailserver Pakete wie modoboa und mailcow zum ausrollen an. Ich entschied mich für modoboa, da es alles bietet was ich benötige und keinen apache2 für sein Admin Frontend benötigt , weil es mit nginx arbeitet, und als Database postgres verwendet, wobei auch mysql und mariadb benutzt werden können. Amavis kümmert sich um möglche viren, DKIM überprüft die Herkunft der mails und DMARC legt fest was wie behandelt wird, das nicht 100% koscher zu sein scheint. Automx emöglicht die Administration über eine Weboberfläche.
Als Betriebssystem habe ich mich für Debian 9 entschieden, der modoboa-installer wird von Debian10 und Centos8 noch nicht unterstützt. Eine sehr gute und ausführliche Anleitung gibt es von Tomas Leistner: https://thomas-leister.de/mailserver-unter-ubuntu-16.04/ Die modoboa instalation mit Debian 9 wird hier sehr gut erklärt: https://goneuland.de/modoboa-mailserver-unter-debian-9-stretch-schnell-und-einfach-installieren/ Bei längeren Dateinamen sollte die config im http Block von NGINX etwa so aussehen http { ## # Basic Settings ## sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; # server_tokens off; server_names_hash_bucket_size 64; # server_name_in_redirect off; include /etc/nginx/mime.types; default_type application/octet-stream; ## # SSL Settings ## da es sonst eine Fehlermeldung wegen des server_names_hash_bucket_size 32 gibt. Wer mehrere Domains verwalten möchte trägt die entsprechend in die MX Records ein. Eine Konfiguration in postfix oder dovecot ist nicht nötig.
Monitoring gehört zu den wohl unbeliebtesten Tätigkeiten eines Systemadmins. Wer schonmal stundenlang in diversten logfiles nach der Fehlerursache eine nicht korrekt startenden Dienstes gesucht hat weis wovon ich rede. Schön wenn der Admin dann ein gutes Werkzeug zur Übrwerwachung seiner Hosts hat und da geht die Qual der Wahl auch schon los. Monitoring tolols gibt es wie Sand am mehr. Von einfachen wie MRTG bis zu hochkomplexen wie Nagios und Icinga in Kombination mit IDS Systemen wie Surricata. Wie bei allen tools muss man sich vorher überlegen was man monitoren möchte und wie. Ich habe mich für die Lösung prometheus und grafana entschieden. Gründe dafür waren u.a.
Skalierbarkeit Moderne IT-Architekturen unterscheiden sich von Lösungen der Vergangenheit meist fundamental dadurch, daß sie sich beliebig erweitern, also in die Breite skalieren lassen. Sie sind deutlich flexibler als ihre althergebrachten Kollegen: Oft laufen sie nicht mehr auf echtem Blech, sondern in virtuellen Maschinen in Clouds.
MAT Monitoring, Alerting und Trending Ein zeitgemäßes Monitoring muß dem Admin verlässliche Daten dazu liefern, wann die Erweiterung des Setups (virtuell oder physisch) notwendig ist. Monitoring, Alerting und Trending unterscheiden sich allerdings grundlegend in der Art der Datenerhebung. Monitoring soll überwachen ob ein bestimmeter Dienst läuft und wenn nicht ggf. Alarm schlagen (Alerting). Beim Trending interessiert hingegen, ob ein Kriterium wie “CPU-Nutzung" oder "RAM-Verbrauch" über eine definierte Periode so hoch ist, daß das Skalieren der Plattform notwendig wird. Anders als bei Nagios stehen hier sog. Zeitreihen oder Time Series Databases im Vordergrund. Über ein entsprechendes Query lässt sich aus einer solchen Datenbank sofort herausfinden, wie sich beispielsweise die CPU-Nutzung über einen Zeitraum entwickelt hat. Die Zeitreihen-Datenbank gibt direkt die entsprechende Zeitreihe aus, statt Einzelwerte anzuzeigen, die dann ein anderes Programm in Relation setzen muss.
Visualisierung hier kommt grafana ins Spiel. Grafana stellt einen Server zur Verfügung, mit dem Zeitreihen von Zahlenwerten graphisch dargestellt und manipuliert werden können. Das Anlegen sog. Dashboards und die Gestaltung der Achsen (Minimum. Maximum) ist mittels einer Weboberfläche im Browswer möglich. Zusätzlich existieren verschiedene Paneltypen, die neben dem klassischen Chart (Line / Bar / Point) auch Pie Charts oder Tabellen beinhalten.
Eine eigene Firewall für mein LAN wollte ich schon immer haben. Eine Kaufappliance schied dabei schon aus Kostengründen aus und Elektronik.Schrott musste ich auch nicht mehr haben . Natürlich tut es auch ein alter PC mit 2 Netzwerkkarten , doch ist das angesichts der aktuellen Strompreise keine wirklich sinnvolle Lösung auf Dauer. Also habe ich mir eine 1HE 19” Appliance besorgt mit 512MB RAM und 1,6 GHZ AMD Prozessor. Bei der Auswahl der Firewall stiess ich auf 2 Alternativen:
Den Klassiker pfsense und den Fork openSense. ich habe mich für den Klassiker entschieden , das dieser von einer größeren Community entwickelt und maintained wird.
und pfsense bringt ein snort-basiertes IDS gleich mit . Das pf.sense image kann auf einen USB Stick installiert, und die Firewall von diesem gebootet werden.
Nach der Installation kann pfSense bequem über einen Webbrowser konfiguriert werden. Wichtig: Die Konfiguration erfolgt über die LAN-Seite der Firewall, stellen Sie deshalb sicher, daß Sie auf das LAN-Interface Zugriff haben.