Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einleitung
TEIL I: Einstieg in Linux
2 Die Installation
3 Erste Schritte
4 Linux als Workstation für Einsteiger
TEIL II: Grundlagen
5 Kernel
6 Grundlagen aus Anwendersicht
TEIL III: Die Shell
7 Die Shell
8 Reguläre Ausdrücke
9 Konsolentools
10 Die Editoren
11 Shellskriptprogrammierung mit der bash
12 Die C-Shell
TEIL IV: System- & Netzwerkadministration
13 Benutzerverwaltung
14 Grundlegende Verwaltungsaufgaben
15 Netzwerkgrundlagen
16 Anwendersoftware für das Netzwerk
17 Netzwerkdienste
18 Mailserver unter Linux
19 LAMP & Co.
20 DNS-Server
21 Secure Shell
TEIL V: Die grafische Oberfläche
22 Die grafische Oberfläche
23 Window-Manager und Desktops
24 X11-Programme
25 Multimedia und Spiele
TEIL VI: Systeminterna
26 Prozesse und IPC
27 Bootstrap und Shutdown
28 Dateisysteme
29 Virtualisierung und Emulatoren
TEIL VII: Programmierung und Sicherheit
30 Softwareentwicklung
31 Crashkurs in C und Perl
32 Einführung in Computersicherheit
33 Netzwerksicherheit überwachen
TEIL VIII: Anhang
A Lösungen zu den einzelnen Aufgaben
B Kommandoreferenz
C X11-InputDevices
D MBR
E Buch-DVDs
F Glossar
G Literatur
Stichwort
Ihre Meinung?

Spacer
Linux von Johannes Plötner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
Rheinwerk Computing
1282 S., 5., aktualisierte Auflage 2012, geb., mit 2 DVDs
49,90 Euro, ISBN 978-3-8362-1822-1
Pfeil 32 Einführung in Computersicherheit
Pfeil 32.1 Sicherheitskonzepte
Pfeil 32.2 Unix und Sicherheit
Pfeil 32.2.1 Benutzer und Rechte
Pfeil 32.2.2 Logging
Pfeil 32.2.3 Netzwerkdienste
Pfeil 32.3 Grundlegende Absicherung
Pfeil 32.3.1 Nach der Installation
Pfeil 32.3.2 Ein einfaches Sicherheitskonzept
Pfeil 32.4 Backups und Datensicherungen
Pfeil 32.4.1 Backup-Strategien
Pfeil 32.4.2 Software
Pfeil 32.5 Updates
Pfeil 32.6 Firewalls
Pfeil 32.6.1 Grundlagen
Pfeil 32.6.2 Firewalling unter Linux: Netfilter/iptables
Pfeil 32.6.3 iptables im Detail
Pfeil 32.7 Proxyserver
Pfeil 32.7.1 Funktion
Pfeil 32.7.2 Einsatz
Pfeil 32.7.3 Beispiel: Squid unter Linux
Pfeil 32.8 Virtuelle private Netzwerke mit OpenVPN
Pfeil 32.8.1 Pre-shared Keys
Pfeil 32.8.2 Zertifikate mit OpenSSL
Pfeil 32.8.3 OpenVPN als Server einrichten
Pfeil 32.8.4 OpenVPN als Client
Pfeil 32.9 Verdeckte Kanäle und Anonymität
Pfeil 32.10 Mails verschlüsseln: PGP und S/MIME
Pfeil 32.10.1 PGP/GPG
Pfeil 32.10.2 S/MIME
Pfeil 32.11 Trojanische Pferde
Pfeil 32.12 Logging
Pfeil 32.13 Partitionierungen
Pfeil 32.14 Restricted Shells
Pfeil 32.15 Loadable Kernel Modules
Pfeil 32.16 chroot
Pfeil 32.17 Kernel-Erweiterungen und ProPolice
Pfeil 32.17.1 ProPolice
Pfeil 32.17.2 SELinux/SEBSD und AppArmor
Pfeil 32.17.3 Openwall (OWL)
Pfeil 32.17.4 grsecurity
Pfeil 32.17.5 PaX
Pfeil 32.18 Sichere Derivate und Distributionen
Pfeil 32.18.1 Trusted Solaris (jetzt Teil von Solaris)
Pfeil 32.18.2 OpenBSD
Pfeil 32.18.3 TrustedBSD
Pfeil 32.18.4 Hardened Gentoo
Pfeil 32.18.5 Openwall
Pfeil 32.18.6 Fedora Core
Pfeil 32.19 Zusammenfassung
Pfeil 32.20 Aufgaben

Rheinwerk Computing - Zum Seitenanfang

32.8 Virtuelle private Netzwerke mit OpenVPNZur nächsten Überschrift

Virtuelle private Netzwerke (kurz VPNs) haben innerhalb der letzten Jahre enorm an Bedeutung gewonnen. Im Folgenden geben wir Ihnen daher eine Einführung in diese Thematik.

Bei einem VPN handelt es sich um ein virtuelles Netzwerk innerhalb eines realen Netzwerks. Die Verbindungen und Systeme eines bestehenden Netzwerks werden dabei so verwendet, dass Sie innerhalb dieses Netzwerks noch ein weiteres aufbauen können. Die Netzwerkdaten eines VPN werden dabei innerhalb von Protokollen des bestehenden Netzwerks untergebracht. Diesen Vorgang bezeichnet man als Tunneling. VPNs werden oft verschlüsselt eingesetzt, um Daten, die geheim gehalten werden sollen und normalerweise nur über ein Firmennetzwerk transportiert werden sollen, über ein unsicheres Netz zu transportieren.

[zB]Ein Beispiel: Ein Mitarbeiter einer in Deutschland angesiedelten Firma führt zu Geschäftspartnern nach Schweden. Von dort aus möchte er eine sichere Videokonferenz zum heimischen Unternehmen aufbauen, die über das Internet eingerichtet werden soll. Dazu stellt der Mitarbeiter über eine entsprechende VPN-Software (also einen VPN-Client) auf seinem Notebook eine Verbindung zum VPN-Router (auch VPN-Gateway genannt) der Firma her. Beide Systeme können darauf konfiguriert sein, dass die Datenübertragung zwischen ihnen verschlüsselt und/oder authentifiziert wird. Der Mitarbeiter und die Firma können nun vertraulich konferieren.

Eine weitere häufig genutzte VPN-Software ist OpenVPN. Sie setzt nicht auf neue, eigene Protokolle und Schlüsselaustauschverfahren, sondern nutzt mit dem TLS/SSL-Protokoll ein bekanntes und lange getestetes Verfahren, um die Sicherheit einer Verbindung zu gewährleisten.

Dazu wird über TLS/SSL eine Verbindung zum Server aufgebaut, über die dann der gesamte Netzwerkverkehr getunnelt wird. Weder ein zwischengeschalteter Proxy noch NAT erzeugen dabei ein Problem. Besonders hervorzuheben ist, dass es Clients für alle gängigen Betriebssysteme gibt und ihre Konfiguration recht einfach ist.

Auf der Homepage von OpenVPN – www.openvpn.org – findet man Clients für alle wichtigen Betriebssysteme sowie eine ausführliche Dokumentation mit einfachen Beispielen. Außerdem finden sich in den meisten Linux-Distributionen bereits vorgefertigte Pakete für OpenVPN, so dass Sie die Software nicht einmal mehr von Hand installieren müssen.


Rheinwerk Computing - Zum Seitenanfang

32.8.1 Pre-shared KeysZur nächsten ÜberschriftZur vorigen Überschrift

Mit OpenVPN kann man die Authentifizierung auf zwei verschiedene Arten regeln: mit Zertifikaten oder mit Pre-shared Keys. Bei Letzteren handelt es sich um eine Art Passwort, das vor der Nutzung auf beiden VPN Endpunkten eingerichtet wurde. Diese Einrichtung ist zwar recht einfach – schließlich braucht man keine X.509-PKI-Infrastruktur für die Zertifikate einzurichten --, bietet aber nur begrenzte Möglichkeiten: Man kann so nur zwei Rechner miteinander verbinden und hat keine Perfect Forward Secrecy:

Ein Kryptosystem mit Perfect Forward Secrecy (PFS) stellt die Integrität auch dann noch sicher, wenn der Schlüssel nach der Kommunikation kompromittiert wird.

Da die Pre-shared Keys von OpenVPN diese Eigenschaft nicht besitzen, kann ein Angreifer nach Veröffentlichung der Schlüssel alle vergangenen Sitzungen entschlüsseln. [Fn. Zertifikate nach X.509 dagegen verwenden zur Laufzeit erstellte Sitzungsschlüssel und bieten daher PFS.]

Um einen Schlüssel in OpenVPN zu erstellen, reicht folgender Aufruf auf der Kommandozeile:

Listing 32.8 Key erstellen

$ openvpn --genkey --secret key.dat

Der erzeugte Schlüssel ist anschließend in der Datei key.dat gespeichert und muss auf »sicherem Weg« – beispielsweise mittels SSH – auf beide zu verbindenden Rechner verteilt werden. Anschließend kann man mit den folgenden kurzen Konfigurationsdateien einen VPN-Tunnel zwischen Client und Server aufbauen:

Listing 32.9 Konfiguration Server

dev tun
ifconfig 192.168.100.1 192.168.100.2
secret key.dat

Listing 32.10 Konfiguration Client

remote vpn.example.com
dev tun
ifconfig 192.168.100.2 192.168.100.1
secret key.dat

Anschließend kann man den Tunnel mittels openvpn --config Konfigurationsdatei starten. In unserem Beispiel haben die Bezeichnungen Server und Client nur Bedeutung in Bezug auf den Aufbau des Tunnels: Der OpenVPN-Server läuft im Hintergrund und wartet auf eine Verbindungsanfrage des OpenVPN-Clients. Dazu muss der Client natürlich wissen, wo er den Server finden kann: In unserem Beispiel ist der öffentliche Name des Servers vpn.example.com.

Nach dem Verbindungsaufbau sind beide Seiten allerdings gleichberechtigt und über die IPs 192.168.100.1 beziehungsweise 192.168.100.2 ansprechbar. Den Tunnel testen kann man somit über ein einfaches ping der Gegenstelle.

Sollte der Test fehlschlagen, so liegt es mit ziemlicher Sicherheit an den Einstellungen der Firewall an einem der Endpunkte. OpenVPN nutzt standardmäßig den UDP-Port 1194, dieser sollte also nicht geblockt werden. Auch ein zwischengeschaltetes NAT muss entsprechend konfiguriert werden, so dass die Pakete korrekt weitergeleitet werden.

Möchte man einer Seite nun Zugriff auf das Netz der Gegenstelle erlauben, so muss nur noch das Routing richtig aufgesetzt werden. Um zum Beispiel dem Client den Zugriff auf das 192.168.1.0/24-Netz des Servers zu geben, bauen Sie folgende Zeile in die Konfiguration des Clients ein:

Listing 32.11 Routing zum Server

route 192.168.1.0 255.255.255.0

Auf der Serverseite müssen Sie – sofern der OpenVPN-Server nicht der Standard-Gateway der Rechner im Netzwerk ist – noch die Route zum Client eintragen: Schließlich ist der Server der Gateway für den Client.


Rheinwerk Computing - Zum Seitenanfang

32.8.2 Zertifikate mit OpenSSLZur nächsten ÜberschriftZur vorigen Überschrift

Eine einfache PKI aufbauen

Das Beispiel mag zum Testen ausreichend sein, für ein professionelles Setup wird man die Authentifizierung jedoch über Zertifikate durchführen wollen. Diese sind vor allem vom sicheren HTTPS-Protokoll bekannt, werden jedoch auch hier in größerem Umfang eingesetzt. So verlangt OpenVPN eine ganze PKI (Public Key Infrastruktur), die aber recht einfach mit der OpenSSL-Suite erstellt und verwaltet werden kann.

Der einfachste Weg, Zertifikate komfortabel zu verwalten, ist openssl. Das Tool findet man in nahezu jeder Linux-Distribution – und hat damit alles, was man braucht, um eine komplette Zertifizierungsstelle einzurichten.

Ein Zertifikat ordnet einer Person oder einem Rechner einen öffentlichen Schlüssel zu. Eine Zertifizierungsstelle (CA, für englisch certification authority) beglaubigt diese Zuordnung durch ihre digitale Unterschrift.

Da das openssl-Programm selbst viele Parameter entgegennimmt, gibt es ein einfaches Skript, das die Benutzung vereinfacht und praktischerweise gleich mit OpenSSL verteilt wird. Das Skript heißt CA.sh und findet sich zum Beispiel unter /usr/lib/ssl/misc. Die wichtigsten Optionen des Skripts lauten wie folgt:

  • CA.sh -newca
    Mit diesem Parameter wird eine neue Zertifizierungsstelle erstellt. Als Ausgabe erhält man unter anderem das Zertifikat mit dem öffentlichen Schlüssel der CA. Als wichtigster Parameter wird ein Passwort abgefragt, mit dem man später neue (Client-)Zertifikate erstellen oder auch widerrufen kann.
  • CA.sh -newreq
    Mit diesem Aufruf erstellt man eine Zertifizierungsanfrage. Dies ist nichts weiter als ein Schlüsselpaar sowie einige Daten zum Besitzer – gültig wird dieses Zertifikat jedoch erst, wenn es im nächsten Schritt von der Zertifizierungsstelle unterschrieben wurde.
  • CA.sh -sign
    Das Unterschreiben des Requests geschieht mit dem Parameter -sign. Dabei wird man aufgefordert, das Passwort der Zertifizierungsstelle einzugeben. Erst dann ist das Unterschreiben erfolgreich.

Ist man mit den Default-Einstellungen des Skripts nicht zufrieden und möchte zum Beispiel die Gültigkeitsdauer der Zertifikate verlängern, so genügt ein Blick in das Skript selbst – viele Optionen können dank ausführlicher Kommentare leicht angepasst werden.


Rheinwerk Computing - Zum Seitenanfang

32.8.3 OpenVPN als Server einrichtenZur nächsten ÜberschriftZur vorigen Überschrift

Zertifikate eignen sich besonders für ein Roadwarrior-Setup, bei dem man mehreren externen Clients über einen zentralen VPN-Server den Zugriff auf das eigene Netz erlauben will – ein typisches Szenario, um Außendienstmitarbeitern den Zugriff auf die Firmen-IT zu gewähren.

Ein guter Ausgangspunkt für die Erstellung eines eigenen Setups ist die OpenVPN- Beispielkonfiguration. Dabei müssen Sie auf die folgenden Punkte achten:

  • port 1194
    Der Standard-Port von OpenVPN ist Port 1194/UDP. Eine Firewall sollte ihn also nicht blocken, sondern eventuell per NAT an den VPN-Server weiterleiten.
  • proto udp / proto tcp
    Man kann wählen, ob man das VPN über UDP oder TCP betreiben möchte. Aber Achtung: Wenn man TCP-Verbindungen über das VPN tunneln möchte – und das wird fast immer der Fall sein – sollte man das VPN über UDP betreiben. Eine »doppelte« Fluss- und Fehlerkontrolle kann zu unerwarteten Effekten wie deutlichen Geschwindigkeitseinbußen führen.
  • dev tun / dev tap
    Hier kann man die Art des Tunnels bestimmen. Die Option dev tun erzeugt einen gerouteten IP-Tunnel: Die Clients befinden sich in einem eigenen Netz und nutzen das VPN-Gateway als Zugang zum internen Netz. Dagegen erstellt die Option dev tap einen Ethernet-Tunnel. Die Clients treten also dem Netzwerk bei und können so auch Broadcast-Nachrichten empfangen. Der damit einhergehende Traffic lässt sich allerdings nur rechtfertigen, wenn spezielle (auf Broadcasts angewiesene) Protokolle einen tap-Tunnel notwendig machen. Andernfalls sollte in den meisten Fällen ein gerouteter Tunnel die richtige Wahl sein.
  • ca / cert / key
    Mit diesen Direktiven gibt man die vorher mit OpenSSL erstellten Zertifikate an. Wichtig ist das CA-Zertifikat, da sowohl Server als auch Client die Gültigkeit des jeweils anderen Zertifikats daran erkennen, ob es von der eigenen CA unterschrieben wurde. Das Zertifikat mit dem Schlüssel (key) ist geheim zu halten, alle anderen Daten sind öffentlich. Je nach Konfiguration muss beim Starten von OpenVPN eventuell ein Passwort angegeben werden, um den verschlüsselten Key laden zu können.
  • dh dh1024.pem
    Für den Schlüsselaustausch sind Diffie-Hellman-Parameter zuständig. [Fn. Diffie-Hellman bezeichnet ein nach seinen Erfindern benanntes kryptografisches Verfahren zum Schlüsselaustausch.] Es reicht aus, diese Parameter einmal mit folgendem Aufruf zu erstellen:

Listing 32.12 openssl dhparam

openssl dhparam -out dh1024.pem 1024
  • server 192.168.2.0 255.255.255.0
    Mit diesem Befehl legt man das Subnetz für alle VPNs fest. Natürlich ist dies nur für geroutete IP-Tunnel (dev tun) interessant. In diesem Beispiel erhalten alle VPN-Clients IPs aus dem Netz 192.168.2.0/24. Dieses Segment sollte in der bisherigen Infrastruktur noch nicht vorkommen!

Netze freigeben

  • push "route 192.168.2.0 255.255.255.0"
    Mit diesem Aufruf teilt man dem Client mit, dass er das Netz 192.168.2.0/24 hinter dem VPN-Gateway finden kann. Hier können auch mehrere Netzwerke weitergeleitet werden – selbst wenn sie nicht direkt mit dem VPN-Gateway verbunden sind. Zu beachten ist nur, dass alle Router auch das VPN-Gateway als Zugangspunkt zum VPN-Netz kennen. Andernfalls können die VPN-Clients zwar Daten ins Netzwerk senden, die Antwortpakete werden aber den Weg zurück nicht finden. [Fn. Natürlich tritt dieses Problem nicht auf, wenn man den VPN-Server gleich auf dem Standard-Gateway aufsetzt ;-)]
  • client-to-client
    Mit dieser Option kann man festlegen, dass sich verschiedene VPN-Clients auch gegenseitig »sehen«. Diese Option ist standardmäßig deaktiviert, somit »sehen« die Clients nur den Server (und eventuell die gerouteten Netze).

Installiert man OpenVPN als RPM- oder DEB-Paket unter Linux, so ist ein Init-Skript zum automatischen Starten des Servers schon beigefügt. [Fn. Unter Windows muss man den Dienst noch als automatisch startend in der Diensteverwaltung markieren.]


Rheinwerk Computing - Zum Seitenanfang

32.8.4 OpenVPN als ClientZur vorigen Überschrift

Das Setup des Clients entspricht im Wesentlichen der Serverkonfiguration. Es fallen viele (serverspezifische) Einstellungen weg, zu beachten ist – wieder ausgehend von der Beispielkonfiguration – nur Folgendes:

  • client
    Mit dieser Direktive legt man fest, dass dieser Rechner als Client agiert und sich damit wichtige Konfigurationseinstellungen vom Server holt.

VPN-Gateway

  • remote vpn-gateway.example.com 1194
    Hier gibt man Server und Port an. Das Protokoll ergibt sich aus der – bei der Serverkonfiguration identischen – proto-Direktive.
  • ca / cert / key
    Natürlich braucht auch der Client eigene Zertifikate. Das CA-Zertifikat muss dabei mit dem Server identisch sein, sonst schlägt die Authentifizierung fehl. Es ist ratsam, jedem Client ein eigenes Zertifikat zu geben – so gibt es beim Widerrufen eines Zertifikats keine Probleme. [Fn. Frühere Versionen von OpenVPN setzten sogar voraus, dass jeder Client ein eigenes Zertifikat besitzt. Heute ist es zwar möglich, ein Zertifikat für mehrere Clients zu benutzen, empfehlenswert ist dieses Vorgehen aber trotzdem nicht.]

Mit diesen einfachen Einstellungen ist das VPN fertig konfiguriert und damit einsatzbereit. Im Gegensatz zu komplizierten IPSec-Setups – die einem gerade bei unterschiedlichen Programmen auf unterschiedlichen Plattformen gern den letzten Nerv rauben – kann man auf diese Weise sehr einfach und kostenlos externe Windows-Clients über einen Linux-VPN-Server an das Firmennetzwerk anbinden. Natürlich sind auch andere Mischformen denkbar – und alle funktionieren. :-)



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Linux Handbuch






 Linux Handbuch


Zum Katalog: Linux Server






 Linux Server


Zum Katalog: Raspberry Pi






 Raspberry Pi


Zum Katalog: Ubuntu 14.04 LTS






 Ubuntu 14.04 LTS


Zum Katalog: Roboter bauen mit Arduino






 Roboter bauen
 mit Arduino


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2012
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de