fetchmail einrichten

fetchmail ist ein Dienstprogramm zum Abrufen und Weiterleiten von E-Mails; das Unix Urgestein holt E-Mails von entfernten Mailservern und leitet diese an das Zustellsystem weiter. Es können die Mails dann unter Verwendung normaler E-Mail-Benutzeragenten wie etwa mutt, elm oder Mail abgerufenen werden.

Das fetchmail-Dienstprogramm kann in einem Daemon-Modus laufen, um ein oder mehrere Systeme in einem bestimmten Intervall wiederholt abfragen, es werden E-Mails von Servern gesammelt die alle gängigen E-Mail-Abrufdienste unterstützen, wie POP3 und IMAP, auch unterstützt werden die ESMTP-ETRN-Erweiterung und die ODMR Protokolle.

In diesem Beitrag wird beschrieben wie fetchmail auf einem CentOS Smarthost mit Postfix eingesetzt werden kann. Die E-Mails von externen Mail-Dienstanbieter werden abgerufen und den Empfänger zum Postfach Server weitergeleitet dieser vom Smarthost E-Mails empfängt. Dabei sind bei den Mailkonten keine Weiterleitungen erforderlich, und die E-Mails werden durch den Smarthost ebenfalls auf Viren und SPAM untersucht, bevor diese dem Benutzer Postfach zugestellt werden.

Für die Installation auf CentOS 7 wird das Extras repository benötigt, falls nicht schon vorhanden.

Das fetchmail-Dienstprogramm kann aus dem CentOS Extras repository installiert werden.

Wir erstellen die Konfigurationsdatei fetchmail für den daemon unter /etc/sysconfig.

 Copy Paste /etc/sysconfig/fetchmail

Es wird der Daemon Init-Script erstellt, hier für ein CentOS Host auf diesem der Postfix MTA bereits läuft. Als root mit vi /etc/rc.d/init.d/fetchmaild

 Copy Paste /etc/rc.d/init.d/fetchmaild
Den Init-Script ausführbar machen.

Die globale fetchmailrc Recource Konfiguration für den Betrieb als Daemon erstellen.

 Copy Paste /etc/fetchmailrc

Für jeden Mailserver von diesem E-Mails abgerufen werden sollen wird eine poll Zeile erstellt. Es soll das externe Postfach von joe@foo.org beim POP3 Server mail.foo.org abgerufen werden und mit smtphost über den localhost über Postfix zum Postfach Server dem Benutzer joe.office@foo.com zugestellt werden. Damit die Protokollierung nicht in maillog statt findet, werden anstelle diese in fetchmail geloggt.

fetchmail bietet eine Reihe von syntaktischen Feinheiten, um fetchmailrc das Lesen von Dateien zu erleichtern. Zum Beispiel werden die Worte andwithhaswants, und options von fetchmail ignoriert, wie auch Satzzeichen. Während es möglich ist, Anmeldeinformationen für einen Server in einer Zeile anzugeben, werden häufige Konfigurationen über eine Reihe von verschiedenen Zeilen angegeben. fetchmail ist unempfindlich gegenüber Whitespace, außer wenn das Argument in Anführungs- und Schlusszeichen erfolgt.

Für die Poll-Anweisung gibt es mehrere Optionen (z.B. nofetchall (default), fetchall, keep, nokeep ). Die Bedeutungen ist wie folgt:

nofetchall : Nur neue Nachrichten abrufen (Standard). Wenn nichts anderes angegeben ist (z.B. fetchallkeep ), bedeutet dies nofetchall.
fetchall : Holt alle Nachrichten, ob gesehen oder nicht.
keep : Löscht keine Nachrichten auf dem Server.
nokeep : Löscht die gelesenen Nachrichten vom Server.

Die fetchmail Benutzer und Gruppe erstellen und die rechte setzen.

Der fetchmail daemon wird gestartet.

Nach Änderung der fetchmailrc-Konfiguration wird der systemd daemon neugestartet.

Überprüfen lässt sich die fetchmail Konversation zu Server mit folgendem Befehl:

Die Konfigurationsdatei fetchmailrc testen.

Den fetchmail Prozess überprüfen.

Die Ausgabe kann in etwa wie folgt aussehen:

Die fetchmail Protokollierung findet nun in der Datei fetchmail statt.

Die fetchmail man page gibt zahlreiche Informationen aus.

 

systemd-resolved

Ubuntu nutzt im Standard das resolvconf-Programm um die Konfiguration für die lokale DNS Auflösung vorzunehmen. Das resolvconf-Paket umfasst eine einfache Datenbank und eine Laufzeit zur dynamischen Änderung von Nameserver-Informationen. Normalerweise wird das Programm resolvconf über eine Netzwerkschnittstelle ausgeführt, um Routinen wie ifup, ifdown, NetworkManager, dhclient und pppd, oder lokale Nameserver wie dnsmasq zu pushen um die Nameserver-Informationen zu updaten.

Kommen auf einem Host statische IP Adressen und DNS Einträge zur Anwendung, sollte unter Ubuntu das resolvconf-Paket deaktiviert werden, damit nicht automatisch die DNS Konfiguration aus dem dnsmasq daemon vorgenommen wird, die Konfiguration die man in /etc/resolv.conf und /etc/network/interfaces editiert hat, werden sonst durch das resolvconf-Programm wieder überschrieben.

resolvconf deaktivieren

resolvconf aus boot level deaktivieren und das Programm beenden.

Den Network Manager anpassen mit default DNS.

Den Symlink resolv.conf unter /etc entfernen.

und eine neue resolv.conf Datei mit den Nameserver erstellen. in diesem Beispiel sind es die Google Public DNS.

In einem lokalen Netzwerk, oder einer ADS sollten die internen Nameserver genutzt werden.

Die resolv.conf Datei des systemd Konfigurationsprogramm löschen.

Änderung der Konfiguration ausführen.

Die Nameserver können auch in der Interface Konfiguration eingetragen werden.

Die Interface Bezeichnung (ens160) kann abweichen und muss der des jeweiligen Host entsprechen.

Die Datei /etc/resolv.conf sollte keineswegs fehlen.

Um die geänderte Netzwerk Konfiguration zu aktivieren muss diese in den Speicher eingelesen werden.

Troubleshooting

Viele Netzwerk Probleme beruhen auf fehlerhaften DNS oder falscher Konfiguration der resolver. In einem Heimnetzwerk gibt es oft keine internen DNS, dabei kann der Router oder die Firewall als Nameserver genutzt werden, wie beispielsweise die FRITZ!Box. Grundsätzlich sollte sichergestellt werden, das die eingesetzte Firewall über ein DNS Cache verfügt, bei semiprofessionellen Firewalls wie die FortiGate verfügt nicht jedes Modell über einen solchen Cache. Bei Open Source basierten Firewalls hingegen bieten die meisten über DNS forwarder oder dnsmasq als Cache.

Nach Änderungen der Nameserver bei Windows sollte der DNS Cache zurückgesetzt werden.   Eingabeaufforderung öffnen.

Bei Linux kann der DNS Cache zurückgesetzt werden, mit eines der folgenden commands, je nachdem welcher Dienst installiert ist.

Im Mac OS X   Terminal als root.

Ist kein interner DNS vorhanden, können die Nameserver des jeweiligen Internet Provider eingesetzt werden, bei Swisscom sind es folgende.

Beispiel einer Nameserver abfrage seines Providers unter Windows.

Beispiel Nameserver lookup query bei Linux.

Ein Ping -n1 löst Adressen zu Hostnamen auf mit Parameter -a und -4 für IPv4 Adresse.

 

pfSense vs OPNsense

OPNsense ist eine noch junge freie Firewall-Distribution auf Basis von FreeBSD das auch einige Enterprise-Features bietet. Die OPNsense Software erlaubt die Benutzung der freien Kryptobibliothek LibreSSL + OpenSSL und steht unter der FreeBSD-Lizenz und darf frei kopiert, verändert und verbreitet werden. OPNsense kann auf Festplatten, SSDs und CompactFlash-Karten installiert werden, sowie von Live CDs gestartet werden. OPNsense läuft auf einer Reihe von Embedded Systeme, gewöhnlichen Personal Computern und als virtuelle Maschine.

Typische Anwendungen sind Stateful Perimeter-Firewalls, Router, Wireless Access Points, DHCP-Server, DNS-Server und VPN-Endpunkte. Hierfür bietet OPNsense Eigenschaften, die oftmals nur von teuren kommerziellen Firewalls geboten werden. Mit Hilfe eines WebUI kann OPNsense übersichtlich konfiguriert werden und Updates sind komfortabel ausführbar, ohne dass genaue Kenntnisse des darunterliegenden FreeBSD Betriebssystems erforderlich sind.

Der Name ist vom Suffix des Namens seines Vorläufers pfSense und open abgeleitet und steht für: Open Source ergibt Sinn.

pfSense ist eine Firewall-Distribution auf der Basis des Betriebssystems FreeBSD und des Paketfilters pf.

Die Distribution ist ein Fork vom mittlerweile eingestellten Projekt m0n0wall und wurde 2004 ins Leben gerufen. m0n0wall ist eine Firewall-Distribution, damals auf Basis von FreeBSD-4 und ipfilter und zielte auf kleine Embedded-Systeme mit wenig Hardware-Ressourcen ab. Auf PCs läuft m0n0wall direkt von einer CD und speichert die Konfiguration in einer XML-Datei. Alternativ kann m0n0wall auch mit einer Flash-EEPROM CF-Karte laufen, wie mit dem ALIX Board von PC Engines, was ein zuverlässiger Betrieb als mit CD/Floppy- oder Festplatten ist. m0n0wall wird komplett über ein Web-Interface gesteuert und war das erste in PHP entwickelte Bootstrap verfahren. Das FreeBSD-4-Basissystem ist nicht über eine Konsole zugänglich.

pfSense und auch OPNsense als Fork und Nachfolger von m0n0wall unterstützten Multiprozessor/Multicore-Maschinen, SSH-Zugang mit direktem Shellzugriff, statt des IPFilters kommt pf zum Einsatz, und OPNsense nun mit PHP 7. Es können weitere Pakete wie Webproxy (Squid), IDS (Snort), SNMP Daemon, ClamAV (Antivirus) als Plugin installiert werden.

Abbildung: pfSense Dashboard

Beide Firewall-Distribution, OPNsense und pfSense unterscheiden sich nur unwesentlich voneinander, funktionell sind sie doch fast identisch, «bis jetzt noch». Bei pfSense und OPNsense wird strongSwan OpenSource IPsec-based VPN eingesetzt, mit IKEv1 und IKEv2 Unterstützung. m0n0wall nutzte den mittlerweile veralteten racoon Daemon welcher eher kritisch und instabil bei IPsec Site-to-Site war. Für die Anbindung von VPN Clients gibt es OpenVPN, dieses stabil und ausgereift ist, mittels LDAP können Active Directory Benutzer der Windows Domain über VPN authentifiziert werden. Das bereits von m0n0wall entwickelte Captive Portal bietet die Möglichkeit von Zugriffskontrollen, es wird Zugriff auf das Internet erst nach einer erfolgreichen Anmeldung freigegeben. Mittels Voucher kann man Gäste in seinem Netz für einen beschränkten Zeitraum Internetzugang gewähren. Nach Ablauf des Vouchers wird die Verbindung getrennt, damit muss das WLAN Passwort nicht an weitere Gäste weitergeben werden.

Abbildung: OPNsense Lobby Dashboard

Features
✓ QoS ✓ 2FA ✓ OpenVPN ✓ IPSec ✓ CARP ✓ Captive Portal ✓ Cache Proxy ✓ Webfilter ✓ IDPS ✓ Netflow, ✓ DNS forwarder mehr.

Die Zwei-Faktor-Authentifizierung auch bekannt als 2FA oder 2-Step Verification ist eine Authentifizierungsmethode, die zwei Komponenten benötigt, z. B. ein Pin/Passwort + ein Token. OPNsense bietet volle Unterstützung für die Zwei-Faktor-Authentifizierung (2FA). Mit dem TOTP Algorithmus, der ein einmaliges Passwort aus einem shared secret Schlüssel und der aktuellen Zeit berechnet. OPNsense unterstützt RFC 6238.

OPNsense und pfSense nutzt das Common Address Redundancy Protocol (CARP) für Hardware Failover. Zwei oder mehr Firewalls können als Failover-Gruppe konfiguriert werden. Wenn eine Schnittstelle auf dem Primär- das Primärsignal ausfällt, wird Sekundär aktiv. Beim Umschalten auf das Backup-Netzwerk bleiben die Verbindungen mit minimaler Unterbrechung für die Benutzer aktiv.

PfSense verwendet OpenSSL und war damit auch vom „Heartbleed bug“ betroffen, dieser Fehler trat kurz nach dem Veröffentlichen der Version 2.1.1 auf, weshalb am 10. April 2014 das Update zu 2.1.2 bereitgestellt wurde.

Fazit: 
Beide Firewall-Distribution, OPNsense und pfSense sind sich fast identisch, obwohl OPNsense angeblich jedoch nur rund 10% des pfSense Codes enthalten soll. Es wird sich daher zukünftig zeigen in welche Richtung beide gehen, möchte OPNsense nicht im Schatten von pfSense stehen, wird es andere Schritte wagen müssen, wünschenswert wäre beispielsweise eine Sandbox Funktion, auch nützlich wäre die Möglichkeit einen zentralen Log und Monitoring Server betreiben zu können. OPNsense zeigt sich mit übersichtlichen Menüs und ist ordentlich performant mit flüssigem Aufbau und einer Modernen Navigation, wie sie auch bei anderen Firewall Hersteller zu finden ist. Gut eignet sich pfSense sowohl auch OPNsense als Virtuelle Firewall in einem VMware ESXi Hypervisor oder unter KVM, zur Nutzung in einer IaaS (Infrastructure as a Service) Umgebung.


Referenz Links:

 

KiTTY Terminal Scripting

KiTTY ist ein Telnet- und SSH-Terminal Emulator für Windows. Die Software ist eine Alternative zu PuTTY und wurde als PuTTY-Clone/Fork entwickelt und ist auch als portable Version erhältlich. Des weiteren werden Raw, Rlogin, ADB, Cygterm und Serial Terminal ermöglicht. KiTTY ist im selben unauffälligen lock and feel gehalten wie PuTTY, bietet jedoch einige nützliche Erweiterungen.

Ein Feature von KiTTY ist der integrierte Editor, mit diesem beim entwickeln und Testen von Scripts die Arbeit im Terminal erleichtert wird, mit <Shift+F2> ruft man den Editor auf.

KiTTY Terminal mit mNotepad (Shift+F2) Editor

Die Code Zeilen aus dem mNotepad können zeilenweise oder als markierten Bereich mit der Option Send (F12) zum Terminal gesendet werden. Das Testen von Code Snippets in der Linux Shell kann so schnell und einfach ausgeführt werden.

Mit <Ctrl+Rechte Maustaste> erscheint das Kontext Menu mit den Optionen, so können Scripte über Send script file übertragen werden die im Terminal Shell ausgeführt werden. Die Option User Command bietet die Möglichkeit häufig verwendete Befehle auszuführen, die in der Registry gespeichert werden.

Falls vorhanden kann WinSCP aufgerufen werden, es wird direkt eine Verbindung zum Host aufgebaut, oder man wählt die Dateiübertragung über Send with pscp.

Wer die Sessions und Hosts Parameter nicht in der Registry verwalten möchte, dem bietet sich die Möglichkeit die Einstellungen in der Datei kitty.ini zu speichern.

Mit folgender Eingabe in der Eingabeaufforderung für die Verwaltung ohne Registry:

Hierdurch werden unter dem Programm Ordner 6 Unterordner angelegt, die Einstellungen werden in den Ordnern Commands, Folders, Launcher, Sessions, Sessions_Commands und SSHHostKeys abgelegt.

 

Nagios Monitoring mit Raspberry Pi

Nagios Open Source Monitoring für die Überwachung komplexer IT-Infrastrukturen. Nagios besteht aus einer Sammlung von Modulen zur Überwachung von Netzwerken, von Hosts und deren spezifischen Diensten, sowie ein Web-Interface um Abfragen der gesammelten Daten zu ermöglicht. Nagios steht unter der GNU GPL, ist also freie Software und läuft unter zahlreichen Unix-ähnlichen Betriebssystemen. Nagios ist wegen seiner großen Verbreitung auch im professionellen Einsatz ein Quasi-Standard geworden.

Nagios-Überwachung mit Raspberry Pi

Raspberry Pi mit seinem lüfterlosen Design, den minimalen Ausmaßen und seinem geringen Stromverbrauch eignet sich der Raspberry Pi als Einplatinencomputer hervorragend für einen Nagios-Monitoring-Server, der sich sogar selbst überwachen kann.

INSTALLATION

Die Installation von Nagios Core 4 auf dem Raspberry eigenen OS Raspbian, welches auf Debian basiert, ist unspektakulär. Hier in dieser Anleitung wird die Vorgehensweise für ein Raspberry Pi 3 Model B aufgezeigt, auf einer 32 GB microSD Card Typ Class 10, eine 16 GB microSD Card würde ebenfalls genügen.

Raspbian Terminal

Zur Bereitstellung von Raspbian auf einer microSD Card wird hier nicht näher eingegangen. Nach boot eines Raspbian Desktop Image, wird das LXTerminal auf dem Raspbian X-Desktop geöffnet und die root shell gestartet, bei Headless Betrieb kann mit VNCViewer eine VNC Session gestartet werden, mit der Anmeldung als Benutzer pi und dem default Passwort raspberry. Möchte man das Raspbian Minimal Image einsetzen, bietet sich die Authentifizierung über SSH zum Raspberry Pi an.

Raspbian VNCViewer

Nach der Anmeldung als User pi wollen wir root werden.

Zunächst werden alle benötigten Pakete als Voraussetzung aus dem Repository installiert.

Herunterladen und entpacken der Nagios Core 4 Source Pakete. Hier findet man das letzte Release, auf Github steht das Core Release sowie die Agenten und Plugins zur Verfügung.

Compilieren

Erstellen des Benutzer nagios und der Gruppe. Der Apache-Benutzer www-data wird auch der nagios-Gruppe hinzugefügt.

Die Binaries Installieren.

Das Installieren der Service-Daemon-Dateien und das konfigurieren für den Bootvorgang.

Installiert und konfiguriert die externe Befehlsdatei.

Nun werden die * SAMPLE * Konfigurationsdateien installiert. Diese sind erforderlich, da Nagios um zu starten einige Konfigurationsdateien benötigt.

Es werden die Apache-Webserver-Konfigurationsdateien installiert und die Apache-Einstellungen für Nagios konfiguriert.

Es muss Port 80 für den eingehenden Datenverkehr auf der lokalen Firewall zugelassen werden, damit die Webschnittstelle von Nagios Core erreicht werden kann.

Antworte mit ja, um die bestehenden Regeln zu speichern.

Es wird ein Apache-Benutzerkonto erstellt, damit es diesem ermöglicht wird sich bei Nagios anmelden zu können.

Der folgende Befehl erstellt ein Benutzerkonto namens nagiosadmin und es wird ein Passwort für das Konto erstellt, dieses Passwort jetzt sich merken.

Es muss der Apache Webserver neu gestartet werden.

Nun wird Nagios Core gestartet.

Nagios ist jetzt bereit und kann getestet werden.

Es kommt die Aufforderung sich mit Benutzernamen und Passwort anzumelden. Der Benutzername ist nagiosadmin (du hast ihn in einem vorherigen Schritt erstellt) und das Passwort ist das, was du zuvor angegeben hast.

Nach erfolgreicher Anmeldung erscheint die Nagios Core Web-Oberfläche. Herzlichen Glückwunsch, Du hast es geschafft.

Nagios Core ist nun installiert, zum Betrieb werden noch die Nagios Plugins benötigt. Es erscheint die Fehler Meldung: (No output on stdout) stderr: execvp(/usr/local/nagios/libexec/check_load .. das ist normal, in den folgenden Schritten werden die Standard Plugins installiert.

Plugin Installation

Zur Voraussetzung der Installation der Plugins werden folgende Pakete aus dem Repository installiert.

Die Source Pakete herunterladen und entpacken. Auf nagios-plugins.org sind die letzten Plugin Release.

Pakete compilieren und installieren.

Gehe zu einem Host- oder Service Objekt und „Re-schedule the next check“ im Menü Commands. Der Fehler der zuvor erschien, sollte nun verschwinden und die korrekte Ausgabe wird auf dem Bildschirm angezeigt.

Die Daemon Kommandos für start / stop / restart / status.

Nagios Konfiguration

Nachdem nun der Nagios Core Server betriebsbereit ist, geht es an das erstellen der Konfiguration der Host und Services die Überwacht werden sollen. Unter /usr/local/nagios/etc ist die Hauptkonfiguration nagios.cfg, hier werden mit cfg_file die Pfade zu den Konfigurationsdateien definiert, in einer Datei hosts.cfg können die zu überwachenden hosts eingetragen werden.

Soll es mehr strukturiert sein bietet sich die Möglichkeit die Host und Service Konfiguration in die Verzeichnisse printers, routers, servers, switches zu speichern, hierzu wird die Datei nagios.cfg editiert und die Kommentar Zeichen # (hash) entsprechend bei cfg_dir= entfernt.

Es werden die in den Verzeichnissen angelegten .cfg Dateien ausgelesen.

Beispiel für ein Mail und Webserver bei diesem IMAP und HTTPS überprüft wird.

Nach jeder Änderung wird der Nagios Server neu gestartet.

Ein blick in die Nagios-Log Datei kann sich lohnen.

Unter dem Verzeichnis objects findet man weitere Konfigurationsbeispiele für Linux, Windows, Printer Router und Switch.

nagios_check_dns
Beispiel: Nagios Service Konfiguration

Mit Remote Agenten wie NCPA können Active Checks auf Windows und Linux Hosts ausgeführt werden, über NRDP und NRPE sind Passive Checks möglich, die werte über CPU last, Memory Nutzung, Prozesse, User und Disk Nutzung geben.

Nagios Notification

In der Datei nagios.cfg und in der Datei objects/contacts.cfg wird als Email Empfänger bei email hier in diesem Beispiel root@localhost belassen.

In der Datei nagios.cfg bei admin_email.

Für die Nagios Email Notification wird hier Postfix als Mail Transport Agent verwendet. Dies wie folgt installiert und konfiguriert wird.

Während der Installation wird man zur Auswahl einer MailServer Konfiguration gefragt, hier wählen wir Internet Site.

Um das senden von Email später testen zu können, wird das Paket mailutils installiert.

Die Postfix Hauptkonfiguration main.cf wird angepasst.

Bei relayhost wird der MailServer eingetragen dieser von Raspberry Pi erlaubt Emails zu empfangen, ist das Raspberry hinter einer Firewall mit NAT, muss beim MailServer die öffentliche IP Adresse für den Empfang berechtigt werden.

Eine Email Adresse für root einrichten, dazu wird die Datei aliases editiert.

Es wird am ende eine gültige Email Adresse eingetragen, damit Mails von diesem Host zugestellt werden, hier als Beispiel ist es helpdesk@banana.org, der Doppelpunkt bei root: ist zwingend.

Die Änderungen in der Datei aliases müssen noch die Datei aliases.db erzeugen.

Auch die Postfix Konfiguration muss noch eingelesen und aktiviert werden.

jetzt den Email Versand von Raspberry Pi testen, dies lässt sich wie folgt ausführen.

Das Email sollte nun im Posteingang von helpdesk@banana.org ankommen sein.

Hier kann auch das Email Log-Protokoll weiter Aufschluss geben.

Gibt der Sendeversuch den status=bounced zurück, ist der Empfang auf dem Mailer noch nicht berechtigt. Bei Exchange muss die IP Adresse des Raspberry Pi beim Empfangsconnector im FrontendTransport unter Bereichsdefinition bei E-Mail von Servern mit diesen Remote-IP-Adressen empfangen, eingetragen sein. Für Postfix muss in main.cf eine smtpd_client_restrictions direktive existieren.

Die Datei client_access beinhaltet die IP Adresse des Raspberry Pi.

Die Postfix Datenbank muss noch generiert werden.

Werden die SMTP Anfragen vom Mailer akzeptiert, kann der Queue Prozess und die Zustellung erfolgen.

last but not least

Wenn das nun alles zu kompliziert ist, oder dir die erforderliche Zeit nicht zur Verfügung steht, dann kann die fertige Raspberry Pi Box hier bezogen werden.

Fully initialized and ready to rock!