KVM Hypervisor auf CentOS7

KVM ist eine Open-Source Hardware Virtualisierungssoftware, mit dieser Linux-basierte und Windows-basierte virtuelle Maschinen gleichzeitig ausgeführt werden können. KVM wird als Kernel-basierte Virtuelle Maschine bezeichnet und ist eine alternative zu VMware ESXi und Xen, dabei wird durch die Installation des KVM-Pakets das KVM-Modul in den aktuellen Kernel geladen und aus einer Linux-Maschine ein Hypervisor gebildet.

In diesem Beitrag wird gezeigt, wie ein KVM Hypervisor auf CentOS 7.x und RHEL 7.x installiert wird, um danach virtuelle Maschinen zu installieren.

INSTALLATION

Bevor man mit der KVM-Installation fortfährt, überprüft man ob die CPU des Systems die Hardware-Virtualisierung unterstützt. Dazu folgendes Command ausführen in der root Shell  

Es sollte in der Ausgabe das Wort vmx oder svm erscheinen, ansonsten unterstützt die CPU keine Virtualisierung. Möglicherweise lohnt sich ein gang in das System BIOS um die VT-x Boot Einstellung zu aktivieren.

Die KVM-Pakete und die zugehörigen Module werden installiert.

Der KVM Service kann nun aktiviert und gestartet werden.

Wir überprüfen ob die KVM Module auch wirklich gestartet wurden.

Falls eine Minimal CentOS 7 oder RHEL 7 Installation vorliegt, startet der virt-manager nicht, wir müssen also noch X-Window installieren.

Starte den Server neu und versuche dann, den virtual manager zu starten.

Bevor wir beginnen VMs zu deployen, erstellen wir zunächst ein Bridge Interface. Die Bridge-Schnittstelle ist erforderlich, wenn man zum Hypervisor von ausserhalb des Netzwerks auf virtuelle Maschinen zugreifen möchte. In unserem Beispiel heisst das Ethernet Interface ifcfg-eth0.

Bearbeite nun die Interface-Datei ifcfg-eth0 und trage folgendes ein:

Bearbeite die Bridge-Datei ifcfg-br0 und lege folgendes fest:

Starte den Netzwerkdienst neu um die Bridge zu aktivieren.

Überprüfe das Bridge Interface mit dem folgenden Befehl:

 Wer es lieber den Network-Manager machen lässt, der kann das Bridge Interface wie folgt erzeugen:

Virtuelle Maschinen können nun entweder über die Befehlszeile mit dem Befehl virt-install oder über das GUI virt-manager erzeugt werden.

Im GUI gehe hierzu auf die Option Datei und klicke auf New virtual Maschine.

Die virtuelle Maschine wird nun mit Hilfe des Wizard erzeugt.

Virtuelle Maschinen aus der Befehlszeile erstellen:

Aus dem virtual Manager werden die VMs hochgefahren und verwaltet, es wird der Status und die Systemlast angezeigt, ähnlich wie man es von vSphere kennt.

Abbildung: KVM virtual Manager

Weiter ist virt-manager aus Cygwin in Windows 10 ausführbar, hierzu muss Cygwin64 mit dem Xorg-Server und virt-manager installiert sein, mit dem virt-manager verbindet man zum KVM Hypervisor.

Abbildung: Cygwin virt-manager Verindung
Abbildung: Cygwin virt-manager

 

Master Browser Lookup

Die von Windows-Clients freigegebenen Ordner oder Drucker sollten in der Netzwerkumgebung der Clients erscheinen. Bleibt die Netzwerkumgebung leer, liegt es oft beim „Computer-Browser“ Service. Windows versucht, in der Netzwerkumgebung alle PCs eines Windows-Netzwerks anzuzeigen.

Zunächst muss sichergestellt werden, dass sein Windows-Netzwerk überhaupt richtig funktioniert. Die Windows-Dienste „Arbeitsstationsdienst“ und „Server“ müssen laufen und in den Eigenschaften der Netzwerkverbindung müssen die „Datei- und Druckerfreigabe“ sowie der „Client für Microsoft-Netzwerke“ aktiv sein, und TCP/IP über NetBIOS muss aktiviert sein. Zu beachten ist das Clients die nicht in einer Domäne sind, dabei in der selben Workgroup sind, wobei WORKGROUP und ARBEITSGRUPPE unterschiedliche Gruppen sind. Wenn das alles noch nicht zum erfolg führt, solle man den Computer im Netzwerk suchen, dieser zum Master Browser delegiert wurde.

Das NBTscan ist ein Programm zum Scannen von IP-Netzwerken für NetBIOS-Namensinformationen. Es sendet eine NetBIOS-Statusabfrage an jede Adresse im angegebenen Bereich und listet empfangene Informationen in für Menschen lesbarer Form auf. Für jeden antwortenten Host werden die IP-Adresse, der NetBIOS-Computername, der Benutzername und die MAC-Adresse des Computer angezeigt.

Um den Master Browser in einem lokalen Netzwerk zu ermitteln, kann folgender Inhalt in einer Batchdatei angelegt werden.

   Copy Paste in Batchdatei nbt.bat speichern und mit Übergabe des IP-Netzwerk in der Eingabeaufforderung als Administrator ausführen, das Programm nbtscan.exe und cygwin1.dll muss im selben Verzeichnis sein, oder der Pfad zum Programm muss sich in der Suchpfad Umgebung befinden.

 Download Quelle NBTScan

Oft hilft es dann wenn der PC dieser der Master Browser in seinem Netzwerk ist, neu zu starten, damit wird die Wahl zur Delegierung eines anderen Computer ausgelöst. Microsoft legt hier Prioritäten fest, durch regeln wird die Zuweisung (election) zum Master Browser erteilt. Administratoren möchten es nicht einfach Zufallsregeln überlassen, wer Master Browser sein soll, dazu öffnet man Regedit und geht zu folgendem Schlüssel.

   Bearbeitung des REG_SZ Schlüssel MaintainServerList und Festlegung auf FALSE oder TRUE, für deaktivieren oder aktivieren. Bei Windows XP und Server 2003 heisst der REG_SZ Schlüssel IsDomainMaster mit Wert FALSE / TRUE, und MaintainServerList mit dem Wert AUTO / NO / YES. Die Änderung tritt nicht sofort in kraft und kann bis zu 48 Minuten dauern.

Bei Linux ist die Samba Konfigurationsdatei smb.conf zuständig, in folgendem Beispiel wird ein Samba Server mit höchster Priorität zum Master Browser gewählt, geeignet in einem Netzwerk ohne Windows PDC. In Netzwerke in diesen sich ein Windows PDC befindet ist es nicht empfohlen.

 

Abbildung: Computer Browser Service Architecture

NBTStat ist ein Befehlszeilentool für die Problembehandlung von NetBIOS-Name über TCP/IP (NetBT) Auflösungsprobleme, es gehört zum Windows Standard. Es zeigt Protokollstatistiken und aktuelle TCP/IP-Verbindungen mit NetBT.

NetBIOS-Namentabellen Typ <00> wird in Hex ausgegeben.

<00> gibt die Domäne an zu der dieser Computer gehört
<03> Computernamen der dem Messenger-Dienst zugeordnet ist
<20> Computernamen der dem Server-Dienst zugeordnet ist
<1C> Internetgruppenname bei Domänencontroller registriert
<1B> Identifizieren eines Domain-Master-Browsername
<1E> Computer kann als Backup Browser in dieser Domäne dienen
<03> Benutzername aktuell an diesem Computer angemeldet
<1D> Identifizieren des Segment-Master-Browsers ohne Domäne

 

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 im Daemon-Modus laufen, um ein oder mehrere Systeme in einem bestimmten Intervall wiederholt abzufragen, 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. 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. Im hinblick auf IPv6 wäre NAT64 b.z.w. DNS64 ein wichtiges Feature, sobald es von FreeBSD unterstützt wird. 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: