Zu den am meisten verwendeten Schnittstellendateien gehört auch ifcfg-eth0, mit der die erste Ethernet Netzwerk-Schnittstellen-Karte im System, auch NIC genannt, gesteuert wird. In einem System mit mehreren NICs gibt es entsprechend mehrere ifcfg eth<X> Dateien (wobei <X> eine eindeutige Nummer ist, je nach der entsprechenden Schnittstelle). Da jedes Gerät über eine eigene Konfigurationsdatei verfügt, können Sie die Funktionalität jeder einzelnen Schnittstelle steuern.

Nachfolgend ist eine ifcfg-eth0-Beispielsdatei für ein System mit einer festen IP-Adresse:

DEVICE=eth0 BOOTPROTO=none ONBOOT=yes NETWORK=10.0.1.0 NETMASK=255.255.255.0 IPADDR=10.0.1.27 USERCTL=no

Die in einer Schnittstellen-Konfigurationsdatei benötigten Werte können sich auf der Basis von anderen Werten ändern. Die ifcfg-eth0-Datei für eine Schnittstelle mit DHCP sieht beispielsweise etwas anders aus, weil die IP-Information vom DHCP-Server zur Verfügung gestellt wird:

DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes

Sie können die Konfigurationsdateien für eine bestimmte Netzwerkschnittstelle aber auch manuell bearbeiten.

Folgend ist eine Liste mit konfigurierbaren Parametern für eine Konfigurationsdatei einer Ethernet-Schnittstelle:

Das folgende Beispiel zeigt die Datei ifcfg für eine Netzwerk-zu-Netzwerk IPsec-Verbindung für LAN A. Der eindeutige Name, mit dem die Verbindung in diesem Beispiel identifiziert wird ist ipsec1, weswegen die entsprechende Datei /etc/sysconfig/network-scripts/ifcfg-ipsec1 benannt wird.

TYPE=IPsec ONBOOT=yes IKE_METHOD=PSK SRCNET=192.168.1.0/24 DSTNET=192.168.2.0/24 DST=X.X.X.X

In diesem Beispiel ist X.X.X.X die öffentliche IP-Adresse des Ziel-IPsec-Routers.

Folgend ist eine Liste mit konfigurierbaren Parametern für eine IPsec-Schnittstelle:

Siehe /usr/share/doc/initscripts-<version-number>/sysconfig.txt (ersetze <version-number> mit der Version des installierten initscripts-Pakets) für Konfigurationsparameter, wenn manuelle Key-Verschlüsselung mit IPsec verwendet wird.

Der racoon IKEv1 Key-Management-Daemon überträgt und konfiguriert einen Parameter-Satz für IPSec. Es kann dabei "preshared" Keys, RSA-Signatures oder GSS-API verwenden. Wenn racoon dazu benutzt wird, automatisch Key-Verschlüsselungen zu bewerkstelligen, so sind folgende Optionen erforderlich:

Für weitere Informationen zu Verschlüsselungsalgorithmen, die für IPsec verfügbar sind, sehen Sie die setkey man-Seite. Für weitere Informationen zu racoon, sehen Sie racoon und die racoon.conf man-Seiten.

Red Hat Enterprise Linux erlaubt Administratoren, mehrere Netzwerk-Schnittstellen in einem einzelnen Kanal zu verbinden, indem die bonding Kernelmodule und eine spezielle Netzwerk-Schnitstelle, Channel-Bonding-Interface genannt, verwendet werden. Channel Bonding erlaubt es mehreren Netzwerk-Schnittstellen als eine zu arbeiten und gleichzeitig die Bandbreite zu erhöhen und Redundanz zu gewähren.

Um ein Channel-Bonding-Interface zu erstellen, erzeugen Sie eine Datei im Verzeichnis /etc/sysconfig/network-scripts/ mit dem Namen ifcfg-bond<N>, wobei Sie <N> mit der Nummer der Schnittstelle, z.B. 0, ersetzen.

Der Inhalt der Datei kann dem Typ der Schnittstelle entsprechen, die zusammengeführt wird, wie beispielsweise einer Ethernet-Schnittstelle. Der einzige Unterschied ist, dass die DEVICE=-Direktive auf bond<N> gesetzt werden muss, wobei <N> die Nummer der Schnittstelle ist.

Die Folgende ist ein Beispiel einer Channel-Bonding Konfigurationsdatei:

DEVICE=bond0 BONDING_OPTS="mode=1 miimon=500" BOOTPROTO=none ONBOOT=yes NETWORK=10.0.1.0 NETMASK=255.255.255.0 IPADDR=10.0.1.27 USERCTL=no

Nachdem das Channel-Bonding-Interface erzeugt wurde, müssen die zu verbindenden Netzwerk-Schnittstellen konfiguriert werden, indem die MASTER= und SLAVE=-Anweisungen zu deren Konfigurationsdateien hinzugefügt werden. Die Konfigurationdateien für jede der verbundenen Schnittstellen können fast identisch sein.

Wenn, zum Beispiel, zwei Ethernet-Schnittstellen verbunden werden, können beide, eth0 und eth1, wie im folgenden Beispiel aussehen:

DEVICE=eth<N> BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no

In diesem Beispiel steht <N> für die Nummer der Schnittstelle.

Zwei weniger verwendete Arten von Schnittstellen-Konfigurationsdateien sind Alias- und Clone Dateien.

Alias-Schnittstellen-Konfigurationsdateien, welche dazu benutzt werden, mehrere Adressen an eine einzige Schnittstelle zu verbinden, muss das ifcfg-<if-name>:<alias-value> Namensgebungsschema verwendet werden.

Eine ifcfg-eth0:0-Datei kann z.B. so konfiguriert werden, dass sie DEVICE=eth0:0 und eine statische IP-Adresse 10.0.0.2 spezifieren kann und somit als Alias einer bereits konfigurierten Ethernet-Schnittstelle dienen kann, um ihre IP- Informationen über DHCP in ifcfg-eth0 zu empfangen. An dieser Stelle ist das eth0-Gerät mit einer dynamischen IP-Adresse verknüpft, dieselbe physikalische Netzwerkkarte kann aber jederzeit über die feste 10.0.0.2 IP-Adresse Anfragen empfangen.

Bei der Namensgebung einer Clone-Schnittstellen-Konfigurationsdatei sollten folgende Konventionen eingehalten werden: ifcfg-<if-name>-<clone-name>. Während eine Alias-Datei mehrere Adressen an einer bestehenden Schnittstelle ermöglicht, wird eine Clone-Datei dazu benutzt, zusätzliche Optionen für eine Schnittstelle festzulegen. Zum Beispiel kann eine Standard-DHCP-Ethernet-Schnittstelle, eth0 genannt, ähnlich aussehen wie in diesem Beispiel:

DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp

Da USERCTL auf no eingestellt ist, können Benutzer, wenn nichts anderes angegeben wird, diese Schnittstelle nicht starten oder beenden. Um den Benutzern dies zu ermöglichen, erstellen Sie einen Clone durch Kopieren von ifcfg-eth0 nach ifcfg-eth0-user und fügen Sie folgende Zeile zu ifcfg-eth0-user hinzu:

USERCTL=yes

Wenn ein Benutzer mit dem Befehl /sbin/ifup eth0-user die eth0-Schnittstelle startet, werden die Konfigurationsoptionen von ifcfg-eth0 und ifcfg-eth0-user kombiniert. Dies ist zwar nur ein sehr einfaches Beispiel, diese Methode kann über für viele verschiedene Optionen und Schnittstellen verwendet werden.

Falls Sie sich via Dialup-Verbindung mit dem Internet verbinden, wird eine Konfigurationsdatei für diese Schnittstelle benötigt.

PPP-Schnittstellendateien werden nach dem folgenden Format benannt:

Die Konfigurationsdatei der PPP-Schnittstelle wird automatisch erzeugt, wenn Sie wvdial, Netzwerk-Administrationstool oder Kppp verwenden, um einen Dialup-Account zu erzeugen. Sie können diese Datei aber auch manuell erstellen und bearbeiten.

Folgend ist eine typische ifcfg-ppp0-Datei:

DEVICE=ppp0 NAME=test WVDIALSECT=test MODEMPORT=/dev/modem LINESPEED=115200 PAPNAME=test USERCTL=true ONBOOT=no PERSIST=no DEFROUTE=yes PEERDNS=yes DEMAND=no IDLETIMEOUT=600

Serial Line Internet Protocol (SLIP) ist eine weitere Dialup-Schnittstelle, wird im allgemeinen aber seltener verwendet. Ein typischer Name für die Schnittstellen-Konfigurationsdatei der SLIP-Dateien ist z.B. ifcfg-sl0.

Weitere Optionen, die in diesen Dateien verwendet werden können, sind:

Weitere übliche Schnittstellen-Konfigurationsdateien beinhalten Folgendes:

Im Internet kann ein FQDN eines Hosts in verschiedene Bereiche eingeteilt werden. Diese Bereiche werden in einer Hierarchie (ähnlich einem Baum) mit Hauptstamm, primären Abzweigungen, sekundären Abzweigungen usw. angeordnet. Betrachten Sie den folgenden FQDN:

bob.sales.example.com

Wenn Sie sehen möchten, wie ein FQDN aufgelöst wurde, um eine IP-Adresse für ein bestimmtes System zu finden, müssen Sie den Namen von rechts nach links lesen. Jede Ebene der Hierarchie ist durch Punkte (.) voneinander getrennt. In diesem Beispiel bestimmt com die Top-Level-Domain für diesen FQDN. Der domain-Name ist eine Subdomain von com mit sales als Subdomain von example. Ganz links im FQDN befindet sich der Hostname, bob, der einen bestimmten Computer identifiziert.

Mit Ausnahme des Hostnamens wird jeder Bereich als Zone bezeichnet, die einen bestimmten Namespace (Namensbereich) festlegt. Ein Namespace kontrolliert die Bezeichnung der Subdomains auf der linken Seite. In diesem Beispiel sind zwar nur zwei Subdomains angegeben, ein FQDN muss aber mindestens eine und kann viel mehr Subdomains enthalten, je nach der Organisation des Namespace.

Die Zonen werden mit Hilfe von Zone-Dateien in authorisierten Nameservern festgelegt. Die Zone-Dateien beschreiben den Namenspace der Zone, den für eine bestimmte Domain oder Subdomain zu verwendenden Mail-Server, uvm. Die Zone-Dateien sind auf primären Nameservern (auch Master-Nameserver genannt) gespeichert, die für Änderungen an Dateien maßgeblich sind, sowie auf sekundären Nameservern (auch Slave-Nameserver genannt), die ihre Zone-Dateien von den primären Nameservern erhalten. Jeder Nameserver kann gleichzeitig für unterschiedliche Zonen sowohl primärer als auch sekundärer Nameserver sein. Zugleich können sie auch für mehrere Zonen maßgeblich sein. Dies hängt alles von der Konfiguration des Nameservers ab.

Primäre Nameserver können auf vier verschiedene Arten konfiguriert sein:

Ein Nameserver kann einem oder mehreren dieser Typen zugehören. Zum Beispiel kann ein Nameserver für einige Zonen der Master und für andere Zonen der Slave sein und für andere ausschließlich Auflösungen weiterleiten.

BIND führt Namensauflösungsdienste mittels /usr/sbin/named Daemon durch. BIND enthält auch ein administratives Utility, /usr/sbin/rndc genannt. Mehr Information zu rndc kann unter Abschnitt 3.4, „Die Verwendung von rndc“ gefunden werden.

BIND speichert seine Konfigurationsdateien in den folgenden zwei Orten:

Die nächsten zwei Abschnitte behandeln die BIND Konfigurationsdateien in mehr Detail.

Die folgenden Typen von Statements werden häufig in /etc/named.conf verwendet:

acl <acl-name> { <match-element>; [<match-element>; ...] };

acl black-hats {     
        10.0.2.0/24;     192.168.0.0/24;  };  
        acl red-hats {     10.0.1.0/24;  };  
options {     
        blackhole { black-hats; };     
        allow-query { red-hats; };     
        allow-recursion { red-hats; };  
}

include "<file-name>"

options { <option>; [<option>; ...] }; 

zone <zone-name><zone-class> { <zone-options>; [<zone-options>; ...] };

zone "example.com" IN { type master; file "example.com.zone"; allow-update { none; }; };

zone "example.com" { type slave; file "example.com.zone"; masters { 192.168.0.1; }; };

Die Folgende ist eine Liste von weniger verwendeten Statement-Typen welche in named.conf verfügbar sind:

Die Folgende ist eine Liste gültiger, in named.conf verwendeter, Kommentar-Tags:

Anweisungen werden durch das vorangestellte Dollarzeichen $ identifiziert, das vor dem Namen der Anweisung üblicherweise im oberen Teil der Zone-Datei steht.

Folgende Anweisungen werden am häufigsten verwendet:

Die Hauptkomponente einer Zone-Datei sind deren Resource-Records.

Es gibt viele Typen von Resource-Records. Folgende werden am häufigsten verwendet:

Einzeln betrachtet könnten die Anweisungen und Resource-Records schwer zu verstehen sein. Sind beide in einer gemeinsamen Datei plaziert, wird es einfacher.

Im nächsten Beispiel ist eine sehr einfache Zone-Datei abgebildet.

$ORIGIN example.com. $TTL 86400 @ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day IN NS dns1.example.com. IN NS dns2.example.com. IN MX 10 mail.example.com. IN MX 20 mail2.example.com. dns1 IN A 10.0.1.1 dns2 IN A 10.0.1.2 server1 IN A 10.0.1.5 server2 IN A 10.0.1.6 ftp IN A 10.0.1.3 IN A 10.0.1.4 mail IN CNAME server1 mail2 IN CNAME server2 www IN CNAME server1

In diesem Beispiel werden Standard-Anweisungen und SOA-Werte verwendet. Die maßgeblichen Name-Server sind dabei als dns1.example.com und dns2.example.com eingestellt, die über A-Records verfügen, wodurch sie mit 10.0.1.1 bzw. 10.0.1.2 verbunden sind.

Die mit MX-Records konfigurierten E-Mail-Server verweisen auf server1 und server2 über CNAME- Records. Da die server1- und server2-Namen nicht mit einem Punkt enden (.), wird die $ORIGIN-Domain nach ihnen abgelegt, wobei sie zu server1.domain.com und server2.domain.com erweitert werden. Mit den dazugehörigen A-Resource-Records können dann ihre IP-Adressen bestimmt werden.

Die beliebten FTP- und Web-Dienste, die unter den standardmäßigen Namen ftp.domain.com und www.domain.com zur Verfügung stehen, verweisen auf Rechner, die entsprechende Dienste für die Namen bieten, die CNAME-Records verwenden.

Diese Zone-Datei würde mit einer zone-Anweisung in der named.conf-Datei in den Dienst übernommen, was dann so ähnlich aussieht wie:

zone "example.com" IN { type master; file "example.com.zone"; allow-update { none; }; };

Eine Zone-Datei für die Auflösung von Reverse-Namen wird verwendet, um eine IP-Adresse in ein bestimmtes Namespace in einem FQDN umzusetzen. Sie ähnelt einer standardmäßigen Zone-Datei, mit dem Unterschied, dass die PTR-Resource-Records zur Verknüpfung der IP-Adressen mit gültigen Domain-Namen verwendet werden.

Das folgende Beispiel zeigt das Layout eines PTR-Record:

<last-IP-digit> IN PTR <FQDN-of-system>

Die <last-IP-digit>ist die letzte Nummer in einer IP-Adresse, mit der auf die FQDN eines bestimmtenSystems hingewiesen wird.

Im folgenden Beispiel werden die IP-Adressen 10.0.1.1 bis 10.0.1.6 den korrespondierenden FQDN zugewiesen. Dies kann in /var/named/example.com.rr.zone lokalisiert werden.

$ORIGIN 1.0.10.in-addr.arpa. $TTL 86400 @ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day 1 IN PTR dns1.example.com. 2 IN PTR dns2.example.com. 5 IN PTR server1.example.com. 6 IN PTR server2.example.com. 3 IN PTR ftp.example.com. 4 IN PTR ftp.example.com.

Diese Zone-Datei würde mit einer zone-Anweisung in der named.conf-Datei in den Dienst übernommen, was dann so ähnlich aussieht wie:

zone "1.0.10.in-addr.arpa" IN { type master; file "example.com.rr.zone"; allow-update { none; }; };

Es gibt nur einen kleinen Unterschied zwischen diesem Beispiel und einer standardmäßigen zone-Direktive: der Name wird anders angegeben. Bitte beachten Sie, dass bei einer Zone für eine umgekehrte Auflösung die ersten drei Blöcke der IP-Adresse zum Umkehren benötigt werden und .in-addr.arpa danach angegeben ist. Dadurch kann ein einzelner Block von IP-Ziffern, der in der Zone-Datei zum umgekehrten Auflösen von Namen verwendet wird, richtig an diese Zone angefügt werden.

Um die Verbindung von rndczu Ihrem named-Dienst zu ermöglichen, muss eine controls-Anweisung in der /etc/named.conf-Datei des BIND-Servers vorhanden sein.

Das folgende Beispiel einer controls-Anweisung ermöglicht es Ihnen, rndc-Befehle vom lokalen Host auszuführen.

controls { inet 127.0.0.1 allow { localhost; } keys { <key-name>; }; };

Diese Anweisung weist named an, am standardmäßigen TCP-Port 953 nach Loopback-Adressen zu suchen und lässt rndc-Befehle zu, die vom lokalen Host ausgeführt werden, wenn der richtige Schlüssel angegeben wird. Der <key-name> bezieht sich auf die key-Direktive, die sich auch in der /etc/named.conf-Datei befindet. Im nächsten Beispiel wird eine key-Anweisung veranschaulicht.

key "<key-name>" { algorithm hmac-md5; secret "<key-value>"; };

In diesem Beispiel benutzt <key-value> einen HMAC-MD5-Algorithmus. Mit dem nachfolgenden Befehl können Sie Ihre eigenen Schlüssel unter Verwendung eines HMAC-MD5-Algorithmus erstellen:

dnssec-keygen -a hmac-md5 -b <bit-length> -n HOST <key-file-name>

Es empfiehlt sich, einen Schlüssel mit einer Größe von mindestens 256 Bit zu erstellen. Der Schlüssel, der im <key-value>-Bereich gespeichert werden sollte, kann in der Datei <key-file-name>, welche von diesem Befehl erzeugt wurde, gefunden werden.

include "/etc/rndc.key";

Die key-Anweisung ist die wichtigste in der Datei /etc/rndc.conf.

key "<key-name>" { algorithm hmac-md5; secret "<key-value>"; };

<key-name> und <key-value> sollten exakt mit den Einstellungen in /etc/named.conf übereinstimmen.

Um den Schlüsseln, welche in /etc/named.conf auf dem Ziel-Server angegeben sind, zu entsprechen, fügen Sie folgende Zeilen zu /etc/rndc.conf hinzu.

options { default-server localhost; default-key "<key-name>"; };

Diese Anweisung setzt den globalen Default-Schlüssel. Dierndc Konfigurationsdatei kann allerdings auch verschiedene Schlüssel für verschiedene Server verwenden, wie im folgenden Beispiel gezeigt:

server localhost { key "<key-name>"; };

Für weitere Informationen zur Datei /etc/rndc.conf, siehe die rndc.conf man-Seiten.

Ein rndc-Befehl sieht wie folgt aus:

rndc <options><command><command-options>

Wenn rndc auf einem korrekt konfigurierten lokalen Host ausgeführt wird, stehen Ihnen folgende Befehle zur Verfügung:

Gelegentlich werden Sie bestimmt auch die Standardeinstellungen in der /etc/rndc.conf-Datei übergehen wollen. Hierzu stehen Ihnen folgende Optionen zur Verfügung:

Zusätzliche Informationen zu diesen Optionen finden Sie auf der rndc-man-Seite

BIND unterstützt Incremental Zone Transfers (IXFR), bei denen Slave-Server nur die aktualisierten Teile einer Zone, die auf einem Master-Name-Server modifiziert wurden, herunterladen. Der standardmäßige Transfer-Process erfordert, dass auch bei der kleinsten Änderung die gesamte Zone an alle Slave-Name-Server übermittelt wird. Für sehr populäre Domains mit sehr großzügigen Zone-Dateien und vielen Slave-Name-Servern macht IXFR den Benachrichtigungs- und Update-Prozess weniger ressourcenintensiv.

Beachten Sie bitte, dass IXFR nur zur Verfügung steht, wenn Sie für Änderungen der Master-Zonen-Records dynamisch updaten verwenden. Wenn Sie Zone-Dateien manuell bearbeiten, um Änderungen durchzuführen, verwenden Sie AXFR. Weitere Informationen über das dynamische Updaten finden Sie im BIND 9 Administrator Reference Manual. Unter Abschnitt 3.7.1, „Installierte Dokumentation“ finden Sie mehr Informationen.

Durch Verwendung der view-Anweisung in named.conf, kann BIND verschiedene Informationen bereitstellen, abhängig von welchem Netzwerk eine Anforderung gestellt wurde.

Dies ist vor allem dann nützlich, wenn Sie nicht möchten, dass externe Clients einen bestimmten DNS-Dienst ausführen oder bestimmte Informationen sehen können, während Sie dies auf dem lokalen Netzwerk internen Clients ermöglichen.

Die view-Anweisung verwendet die match-clients-Option, um IP-Adressen oder ganze Netzwerke zu vergleichen und diesen spezielle Optionen und Zone-Daten zu geben.

BIND unterstützt eine Reihe verschiedener Methoden, um das Updaten von Zonen auf Master- oder Slave-Nameservern zu schützen:

Die Version 9 von BIND kann mit den A6 Zone-Records Name-Service für die IP-Version 6 (IPv6)-Umgebungen zur Verfügung stellen.

Wenn Ihre Netzwerkumgebung sowohl über Ipv4- als auch IPv6-Hosts verfügt, können Sie den lwresd Lightweight-Resolver-Daemon in Ihren Netzwerk-Clients verwenden. Dieser Daemon ist ein sehr effektiver Caching-Only-Name-Server, der die neuesten A6- und DNAME-Records versteht, die mit Ipv6 verwendet werden. Auf der lwresd-man-Seite finden Sie weitere Informationen hierzu.

BIND bietet eine Vielfalt an Dokumentation, die viele verschiedene Themen (mit jeweils individuellem Verzeichnis) abdeckt. Ersetzen Sie dazu <version-number> mit der auf Ihrem System installierten Version von bind.

Es gibt auch einige man-Seiten zu den verschiedenen Applikationen und Konfigurationsdateien die im Bezug zu BIND stehen. Einige der wichtigeren man-Seiten sind wie folgt aufgelistet.

Skrupellosen Computerbenutzern stehen eine Reihe von Tools zur Verfügung, um die Netzwerkkommunikation zu stören, abzufangen und umzuleiten und um auf diese Weise Zugriff auf Ihr System zu erhalten. Diese Gefahren können generell wie folgt klassifiziert werden:

Bei beiden Methoden werden möglicherweise wichtige und vertrauliche Informationen abgefangen. Wenn dies aus unlauteren Gründen erfolgt, können die Ergebnisse katastrophal sein.

Wenn SSH für Fernanmeldungen über eine Shell und für das Kopieren von Dateien verwendet wird, können diese Sicherheitsrisiken erheblich gemindert werden. Das ist darauf zurückzuführen, dass der SSH-Client und Server digitale Unterschriften verwenden, um gegenseitig ihre Identität zu prüfen. Außerdem sind alle Mitteilungen zwischen Client und Server verschlüsselt. Dabei nützen auch Versuche, sich als das eine oder andere System auszugeben, nichts, da der Schlüssel hierfür nur dem lokalen und dem entfernten System bekannt ist.

Die wichtigste Aufgabe der Transportschicht ist es, die sichere und verschlüsselte Kommunikation zwischen zwei Rechnern bei und nach der Authentifizierung zu gewährleisten. Die Transportschicht verwaltet zu diesem Zweck die Verschlüsselung und Entschlüsselung der Daten und sorgt dafür, dass die Datenpakete während des gesamten Übertragungsflusses geschützt sind. Weiterhin kann diese Schicht die Daten komprimieren und damit die Übertragungsgeschwindigkeit erheblich erhöhen.

Sobald ein Client über ein SSH-Protokoll mit einem Server in Verbindung tritt, erfolgen verschiedene wichtige Vorgänge, die dazu dienen, dass die beiden Systeme die Transportschicht korrekt aufbauen:

Während des Schlüsselaustauschs identifiziert sich der Server mit einem eindeutigen Host-Key. Falls der Client nie zuvor mit diesem speziellen Server kommuniziert hat, ist der Host-Key des Servers für den Client unbekannt und die Verbindung wird nicht hergestellt. OpenSSH löst dieses Problem, indem der Host-Key des Servers akzeptiert wird. Dies wird durchgeführt, nachdem der Benutzer benachrichtigt wurde und den neuen Host-Key sowohl akzeptiert, als auch verifiziert hat. Bei nachfolgenden Verbindungen wird der Host-Key des Servers anhand der gespeicherten Version auf dem Client überprüft, was das Vertrauen schafft, dass der Client tatsächlich mit dem vorgesehenen Server kommuniziert. Falls der Host-Key in der Zukunft nicht mehr übereinstimmt, muss der Benutzer die gespeicherte Version auf dem Client entfernen, bevor eine Verbindung hergestellt werden kann.

Das SSH-Protokoll wurde konzipiert, um mit fast allen Algorithmen oder Formaten für allgemeine Schlüssel verwendet werden zu können. Nachdem ein erster Schlüsselaustausch zwei Werte erstellt hat (einen Hash-Wert für den Austausch und einen gemeinsam genutzten, geheimen Wert), berechnen die beiden Systeme sofort neue Schlüssel und Algorithmen, um die Authentifizierung und die in der Folge über die Verbindung gesendeten Daten zu schützen.

Nachdem eine bestimmte Datenmenge mithilfe eines vorgegebenen Schlüssels und Algorithmus übertragen wurde (die genaue Menge hängt von der SSH-Implementation ab), erfolgt ein weiterer Schlüsselaustausch, der wiederum einen neuen Hash-Wert und einen neuen, gemeinsam genutzten, geheimen Wert generiert. Auch wenn eine unbefugte Person diese beiden Werte ermitteln sollte, müsste sie diese Information bei jedem neuen Schlüsselaustausch ermitteln, um die Verbindung zu überwachen.

Nachdem die Transportschicht einen sicheren Kanal geschaffen hat, in dem die Informationen zwischen den beiden Systemen übertragen werden, teilt der Server dem Client die verschiedenen unterstützten Authentifizierungsmethoden mit (beispielsweise eine private, verschlüsselte Signatur oder die Eingabe eines Passworts). Der Client wird anschließend versuchen, sich anhand einer der unterstützten Methoden gegenüber dem Server zu identifizieren.

SSH Server und Clients können konfiguriert werden, um verschiedene Arten der Authentifizierung zu ermöglichen. Diese Methode bietet daher jeder Seite das ideale Maß an Kontrolle. Der Server kann entscheiden, welche Verschlüsselungsmethoden er auf der Grundlage seines Sicherheitsmodells unterstützen möchte, und der Client kann festlegen, in welcher Reihenfolge er die verschiedenen verfügbaren Authentifizierungsmethoden verwendet.

Nach einer erfolgreichen Authentifzierung via SSH Transportschicht, werden mehrere Kanäle mit Hilfe der Technik Multiplexing^[4] geöffnet. Jeder dieser Kanäle verarbeitet die Datenübertragung für verschiedene Terminalsitzungen und für weitergeleitete X11-Sitzungen.

Sowohl Clients als auch Server können einen neuen Kanal erstellen, wobei jedem Kanal an jedem Ende eine unterschiedliche Nummer zugewiesen wird. Wenn eine Seite einen neuen Kanal öffnen möchte, wird die Nummer der entsprechenden Seite des Kanals mit der Anforderung übermittelt. Diese Information wird von der anderen Seite gespeichert und verwendet, um eine bestimmte Mitteilung an diesen Kanal weiterzuleiten. Ziel dabei ist zu vermeiden, dass sich verschiedene Arten von Sessionen beeinflussen und die Kanäle geschlossen werden können, ohne die primäre SSH-Verbindung zwischen den beiden Systemen zu unterbrechen.

Kanäle unterstützen auch die Datenflusskontrolle, was es ihnen ermöglicht, Daten geordnet zu senden und zu empfangen. Auf diese Weise werden Daten erst dann über den Kanal gesendet, wenn der Host-Rechner die Meldung erhält, dass der Kanal empfangsbereit ist.

Der Client und Server übertragen automatisch die Eigenschaften jedes Kanals, je nachdem, welche Art von Dienst der Client abruft und wie der Benutzer mit dem Netzwerk verbunden ist. Dadurch ergibt sich eine größere Flexibilität bei der Handhabung der verschiedenen Arten von Remote-Verbindungen ohne die Basis-Infrastruktur des Protokolls ändern zu müssen.

Für ein wirklich effektives SSH dürfen Sie keine unsicheren Verbindungsprotokolle wie Telnet und FTP verwenden. Andernfalls wird das Passwort eines Benutzers mit Hilfe von SSH für die eine Sitzung zwar geschützt, um dann später durch eine Anmeldung bei Telnet erfasst zu werden.

Einige Dienste sind zu deaktivieren:

Um unsichere Verbindungsmethoden auf dem System zu deaktivieren, verwenden Sie das Kommandozeilenprogramm chkconfig, das auf Ncurses basierende Programm /usr/sbin/ntsysv, oder die grafische Anwendung Tool zur Konfiguration von Diensten (system-config-services). Jede dieser Anwendungen erfordert Root-Zugriff.

Der Befehl ssh ist ein sicherer Ersatz für die Befehle rlogin, rsh und telnet. Mit diesem Befehl können Sie sich sowohl auf einem Remote-Rechner anmelden als auch auf diesem Rechner Befehle ausführen.

Die Verwendung des Befehls ssh für die Anmeldung auf einem Rechner ist vergleichbar mit dem Befehl telnet. Wenn Sie sich auf einem Remote-Rechner mit dem Namen penguin.example.net anmelden möchten, geben Sie am Shell-Prompt den folgenden Befehl ein:

ssh penguin.example.net

Wenn Sie sich das erste Mal mit dem Befehl ssh auf einem Remote-Rechner anmelden, erscheint folgende (oder eine ähnliche) Meldung:

The authenticity of host 'penguin.example.net' can't be established.
DSA key fingerprint is 94:68:3a:3a:bc:f3:9a:9b:01:5d:b3:07:38:e2:11:0c.
Are you sure you want to continue connecting (yes/no)?

Geben Sie yes ein, um fortzufahren. Der Server wird Ihrer Liste von bekannten Hosts (~/.ssh/known_hosts/) wie im Folgenden angegeben hinzugefügt:

Warning: Permanently added 'penguin.example.net' (RSA) to the list of known hosts.

Anschließend werden Sie aufgefordert, Ihr Passwort für den Remote-Rechner einzugeben. Nach der Eingabe des Passworts befinden Sie sich im Shell-Prompt des Remote-Rechners. Wenn Sie keinen Benutzernamen angeben, so wird der Benutzername, mit dem Sie auf dem lokalen Rechner angemeldet sind, an den Remote-Rechner weitergegeben. Mit dem folgenden Befehl können Sie einen anderen Benutzernamen festlegen:

ssh username@penguin.example.net

Sie können auch die Syntax ssh -l username penguin.example.net verwenden.

Mit dem Befehl ssh können Sie Befehle auf einem Remote-Rechner ausführen, ohne am Shell-Prompt angemeldet sein zu müssen. Die entsprechende Syntax ist ssh hostnamecommand. Wenn Sie zum Beispiel den Befehl ls /usr/share/doc auf dem Remote-Rechner penguin.example.net ausführen möchten, geben Sie am Shell-Prompt den folgenden Befehl ein:

ssh penguin.example.net ls /usr/share/doc

Nachdem Sie das korrekte Passwort eingegeben haben, wird der Inhalt des Verzeichnisses /usr/share/doc angezeigt, und Sie kehren zum Shell-Prompt zurück.

Der Befehl scp kann für die Übertragung von Dateien zwischen Computern über eine sichere, verschlüsselte Verbindung verwendet werden und ist vergleichbar mit dem Befehl rcp.

Die allgemeine Syntax für die Übertragung einer lokalen Datei zu einem Remote-System lautet wie folgt:

scp <localfile>username@tohostname:<remotefile>

Die Datei <localfile> legt den Source inklusive demPfad zur Datei fest, wie z.B. /var/log/maillog. Die Datei <remotefile> legt die Destination fest, was z.B. ein neuer Dateiname sein kann, wie /tmp/hostname-maillog. Für das Remote-System, wenn Sie kein vorangestelltes / haben, so ist der Pfad relativ zum Heimverzeichnis von username; typisch /home/username/.

Um die lokale Datei shadowman zum Heimverzeichnis Ihres Accounts auf penguin. example.net zu übermitteln, geben Sie Folgendes am Shell-Prompt ein (ersetzen Sie dabei username durch Ihren Benutzernamen):

scp shadowman username@penguin.example.net:shadowman

Die Datei shadowman wird somit an die Datei /home/username/shadowman des Rechners penguin.example.net übermittelt.

Die allgemeine Syntax für die Übermittlung von Remote-Dateien zu einem lokalen System lautet:

scp username@tohostname:<remotefile><newlocalfile>

Die Datei <remotefile> legt die Quelle inklusive Pfad fest und newlocalfile den Bestimmungsort und Pfad.

Viele Dateien können als Quelldateien festgelegt sein. Um zum Beispiel den Inhalt des Verzeichnisses /downloads an das Verzeichnis uploads des Remote-Rechners penguin.example.net zu übertragen, geben Sie Folgendes am Shell-Prompt ein:

scp downloads/* username@penguin.example.net:uploads/

Das Dienstprogramm sftp kann zum Öffnen einer sicheren, interaktiven FTP-Sitzung verwendet werden. Es gleicht ftp, mit dem Unterschied, dass es eine sichere, verschlüsselte Verbindung verwendet. Die allgemeine Syntax ist sftp username@hostname.com. Nach der Authentifizierung können Sie eine Reihe von Befehlen verwenden (ähnlich wie bei der Verwendung von FTP). In der man-Seite sftp finden Sie eine Liste dieser Befehle. Um die man-Seite lesen zu können, müssen Sie im Shell-Prompt den Befehlman sftp ausführen. Das Dienstprogramm sftp ist nur in den OpenSSH Versionen 2.5.0p1 und höher verfügbar.

Das Öffnen einer X11-Sitzung via einer SSH-Verbindung ist so einfach, wie das Verbinden mit dem SSH-Server selbst mit der Option -Y und das Ausführen eines X-Programms auf einem lokalen Rechner.

ssh -Y <user>@example.com

Wird ein X-Programm an einem Secure Shell Prompt ausgeführt, erstellen der SSH-Client und -Server einen neuen, verschlüsselten Kanal in der aktuellen SSH-Verbindung, und die Daten des X-Programms werden über diesen Kanal auf Ihren Client-Rechner gesendet.

Das Weiterleiten von X11 kann sehr nützlich sein. So kann das Weiterleiten von X11 beispielsweise dazu verwendet werden, eine sichere, interaktive Sitzung für Tool zur Druckerkonfiguration zu erstellen. Um dies durchzuführen, verwenden Sie ssh, um sich mit dem Server zu verbinden und tippen:

system-config-printer &

Nachdem Sie das Root-Passwort für den Server angegeben haben, erscheint das Tool zur Druckerkonfiguration und ermöglicht dem Remote-Benutzer, die Druckereinstellungen auf dem Remote-System sicher zu konfigurieren.

Mit SSH können Sie unsichere TCP/IP Protokolle via Port Forwarding sichern. Bei dieser Technik wird der SSH-Server zu einer verschlüsselten Verbindung zum SSH-Client.

Beim Port Forwarding wird ein lokaler Port auf einem Client zu einem remoten Port auf dem Server gemappt. Mit SSH können Sie jeden Port des Servers auf jeden Port des Clients übertragen; die Portnummern müssen hierfür nicht übereinstimmen.

Um einen TCP/IP Port Forwarding Kanal zu erstellen, der nach Verbindungen im lokalen Host sucht, verwenden Sie folgenden Befehl:

ssh -L local-port:remote-hostname:remote-portusername@hostname

Wenn Sie zum Beispiel Ihre E-Mails auf einem Server mit dem Namen mail.example.com mithilfe von POP3 über eine verschlüsselte Verbindung abrufen möchten, verwenden Sie folgenden Befehl:

ssh -L 1100:mail.example.com:110 mail.example.com

Nachdem der Port Forwarding Channel zwischen dem Client-Rechner und dem Mailserver eingerichtet wurde, können Sie einen POP3-Mail-Client anweisen, Port 1100 auf localhost für das Abrufen neuer E-Mails zu verwenden. Alle an Port 1100 gesendeten Anfragen werden auf diese Weise sicher an den Server mail.example.com weitergeleitet.

Wenn mail.example.com keinen SSH-Serverdaemon ausführt, Sie sich jedoch an einem anderen Rechner im gleichen Netzwerk anmelden können, können Sie dennoch SSH verwenden, um einen Teil der Verbindung zu sichern. Hierzu ist ein anderer Befehl notwendig:

ssh -L 1100:mail.example.com:110 other.example.com

In diesem Beispiel werden POP3-Anfragen von Port 1100 des Client-Rechners über die SSH-Verbindung auf Port 22 an den SSH-Server other.example.com weitergeleitet. Anschließend verbindet sich other.example.com mit Port 110 auf mail.example.com, so dass Sie neue E-Mails abrufen können. Beachten Sie, dass bei Verwendung dieser Methode lediglich die Verbindung zwischen dem Client-System und dem other.example.com-SSH-Server sicher ist.

Dies kann sehr nützlich sein, wenn Sie Informationen sicher über Netzwerk-Firewalls übertragen möchten. Wenn die Firewall so konfiguriert ist, dass SSH-Kommunikationen über den Standardport (22) erfolgen, die Übertragung über andere Ports jedoch gesperrt ist, ist eine Verbindung zwischen zwei Rechnern mit gesperrten Ports weiterhin möglich, indem die Meldungen über eine festgesetzte SSH-Verbindung zwischen diesen Rechnern übermittelt werden.

Wenn Sie nicht jedesmal Ihr Passwort eingeben möchten, wenn Sie die Befehle ssh, scp oder sftp verwenden, um sich mit einem Remote-Rechner zu verbinden, können Sie ein Authorisierungsschlüsselpaar erstellen.

Für jeden Benutzer müssen Schlüssel erstellt werden. Wenn Sie als Benutzer mit einem Remote-Rechner verbunden werden möchten, müssen Sie die Schlüssel gemäߟ den folgenden Schritten erstellen. Wenn Sie diese Schritte als root ausführen, können diese Schlü ssel auch nur von root verwendet werden.

Das Starten mit OpenSSH Version 3.0, ~/.ssh/authorized_keys2, ~/.ssh/known_hosts2 und /etc/ssh_known_hosts2 ist veraltet. SSH Protokoll 1 und 2 verwenden die Dateien ~/.ssh/authorized_keys, ~/.ssh/known_hosts und /etc/ssh/ssh_known_hosts.

Red Hat Enterprise Linux 5.2 uses SSH Protocol 2 and RSA keys by default.

The first step in configuring a DHCP server is to create the configuration file that stores the network information for the clients. Use this file to declare options and global options for client systems.

Die Konfigurationsdatei kann beliebige Leerzeichen oder Tabs sowie leere Zeilen für eine einfachere Formatierung enthalten. Die Schlüsselwörter beachten keine Groß- und Kleinschreibung und Zeilen, die mit einer Raute beginnen (#), gelten als Kommentare.

Derzeit sind zwei Modi der DNS-Aktualisierungen implementiert — der Ad-Hoc Aktualisierungsmodus und der Interim DHCP-DNS Interaktionsentwurf-Aktualisierungsmodus. Wenn diese beiden Schemata als Teil des IETF Standardprozess angenommen werden, erscheint ein dritter Modus — die standardmäßige DNS-Aktualisierungsmethode. Der DHCP-Server muss für den Gebrauch einer der beiden aktuellen Methoden konfiguriert werden. Version 3.0b2pl11 und ältere Versionen verwendeten den Ad-Hoc Modus, der inzwischen jedoch an Bedeutung verloren hat. Wenn Sie das gleiche Verhalten beibehalten möchten, fügen Sie am Anfang der Konfigurationsdatei die folgende Zeile hinzu:

ddns-update-style ad-hoc;

Um den empfohlenen Modus zu verwenden, fügen Sie am Anfang der Konfigurationsdatei die folgende Zeile hinzu:

ddns-update-style interim;

Auf der man-Seite dhcpd.conf finden Sie Details über die verschiedenen Methoden.

In der Konfigurationsdatei gibt es zwei Kategorien von Angaben:

Einige Parameter müssen mit dem Schlüsselwort Option gestartet werden und werden als Optionen bezeichnet. Mit diesen Optionen konfiguriert man DHCP-Optionen; während man mit Parametern nicht-optionale Werte konfiguriert oder das Verhalten des DHCP-Servers steuert.

Parameter (einschließlich Optionen), die vor einem Segment in geschweiften Klammern angegeben werden ({ }), gelten als globale Parameter. Die allgemeinen Parameter werden auf alle Segmente darunter angewandt.

Im Beispiel 5.1, „Subnet-Deklaration“ werden die Optionen routers, subnet-mask, domain-name, domain-name-servers und time-offset für alle darauffolgenden host Statement Deklarationen verwendet.

Zusätzlich können Sie ein subnet angeben. Sie müssen eine subnet Angabe für jedes Subnetz Ihres Netzwerks machen. Tun Sie dies nicht, kann der DHCP-Server nicht starten.

In unserem Beispiel gibt es für jeden DHCP-Client im Subnet allgemeine Optionen und einen Range. Die Zuweisung der IP-Adresse an die Clients erfolgt innerhalb des Range.

subnet 192.168.1.0 netmask 255.255.255.0 {
        option routers                  192.168.1.254;
        option subnet-mask              255.255.255.0;

        option domain-name              "example.com";
        option domain-name-servers       192.168.1.1;

        option time-offset              -18000;     # Eastern Standard Time

        range 192.168.1.10 192.168.1.100;
}

Alle Subnetze, die ein gemeinsames physisches Netzwerk verwenden, sollten in der Datei shared-network, wie in Beispiel 5.2, „Gemeinsam genutzte Netzwerk-Deklaration“ gezeigt, angegeben werden. Parameter, die in shared-network angegeben sind, aber nicht in der subnet Deklaration enthalten sind, werden als allgemeine Parameter betrachtet. Die Bezeichnung des shared-network sollte ein aussagekräftiger Titel für das Netzwerk sein, z.B. Test-Labor, wenn alle Subnetze innerhalb eines Test-Labors beschrieben werden sollen.

shared-network name {
    option domain-name              "test.redhat.com";
    option domain-name-servers      ns1.redhat.com, ns2.redhat.com;
    option routers                  192.168.0.254;
    more parameters for EXAMPLE shared-network
    subnet 192.168.1.0 netmask 255.255.252.0 {
        parameters for subnet
        range 192.168.1.1 192.168.1.254;
    }
    subnet 192.168.2.0 netmask 255.255.252.0 {
        parameters for subnet
        range 192.168.2.1 192.168.2.254;
    }
}

Wie in Beispiel 5.3, „Gruppen-Vereinbarung“ gezeigt, kann die Gruppen-Deklaration verwendet werden, um allgemeine Parameter für eine Gruppe von Vereinbarungen anzuwenden. Sie können gemeinsam genutzte Netzwerke, Subnets, Hosts oder andere Gruppen als Gruppe zusammenfassen.

group {
   option routers                  192.168.1.254;
   option subnet-mask              255.255.255.0;

   option domain-name              "example.com";
   option domain-name-servers       192.168.1.1;

   option time-offset              -18000;     # Eastern Standard Time

   host apex {
      option host-name "apex.example.com";
      hardware ethernet 00:A0:78:8E:9E:AA; 
      fixed-address 192.168.1.4;
   }

   host raleigh {
      option host-name "raleigh.example.com";
      hardware ethernet 00:A1:DD:74:C3:F2;
      fixed-address 192.168.1.6;
   }
}

Um einen DHCP-Server zu konfigurieren, der dynamische IP-Adressen in einem Subnetz an ein System vergibt, ändern Sie Beispiel 5.4, „Range-Parameter“ entsprechend Ihren Werten. Es bezeichnet die Standard-Lease-Dauer, die maximale Lease-Dauer und Netzwerk-Konfigurationswerte für die Clients. In diesem Beispiel wird die IP-Adresse in der range 192.168.1.10 und 192.168.1.100 Client-Systemen zugeordnet.

default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1, 192.168.1.2;
option domain-name "example.com";

subnet 192.168.1.0 netmask 255.255.255.0 {
   range 192.168.1.10 192.168.1.100;
}

Um einem Client anhand der MAC-Adresse der Netzwerkkarte eine IP-Adresse zuzuordnen, verwenden Sie den Parameter hardware ethernet, der in der host Deklaration enthalten ist. Wie in Beispiel 5.5, „Statische IP-Adresse, die DHCP verwendet“ gezeigt, legt die host apex Deklaration fest, dass die Netzwerkkarte mit der MAC-Adresse 00:A0:78:8E:9E:AA immer die IP-Adresse 192.168.1.4 zugewiesen bekommt.

Beachten Sie, dass Sie auch den optionalen Parameter host-name benutzen können, um einem Client einen Hostnamen zuzuordnen.

host apex {
   option host-name "apex.example.com";
   hardware ethernet 00:A0:78:8E:9E:AA; 
   fixed-address 192.168.1.4;
}

cp /usr/share/doc/dhcp-<version-number>/dhcpd.conf.sample /etc/dhcpd.conf

Eine vollständige Liste der Optionen und deren Anwendung finden Sie auf der dhcp-options man-Seite.

/var/lib/dhcp/dhcpd.leases die Lease-Datenbank des DHCP-Client. Diese Datei sollte nicht manuell geändert werden. In der Lease-Datenbank werden automatisch alle DHCP-Leasedaten aller zuletzt zugeordneten IP-Adressen gespeichert. Die Daten enthalten die Leasedauer, wem die IP-Adresse zugeordnet wurde sowie Anfangs- und Enddaten für die Lease und die MAC-Adresse der Netzwerkkarte, von der die Lease abgerufen wurde.

Alle Zeitangaben in der Lease-Datenbank sind Greenwich Mean Time (GMT) und nicht Ortszeit.

Die Lease-Datenbank wird von Zeit zu Zeit neu generiert, damit sie nicht zu groß wird. Zunächst werden alle bekannten Leases in einer temporären Lease-Datenbank gespeichert. Die Datei dhcpd.leases wird in dhcpd.leases~ umbenannt und die temporäre Lease-Datei wird unter dhcpd.leases gespeichert.

Der DHCP-Daemon könnte beendet werden oder das System abstürzen, nachdem die Lease-Datenbank in eine Backup-Datei umbenannt, die neue Datei jedoch noch nicht gespeichert wurde. In diesem Fall gibt es keine dhcpd.leases-Datei, die zum Starten erforderlich ist. Erstellen Sie keine neue Lease-Datei, wenn dies passiert. Wenn Sie dies tun, gehen alle alten Leases verloren, was zu Problemen führt. Sie sollten stattdessen die dhcpd. leases~ Backup-Datei in dhcpd.leases umbenennen und dann den Daemon starten.

Um den DHCP-Dienst zu starten, geben Sie den Befehl /sbin/service dhcpd start ein. Um den DHCP-Server anzuhalten, geben Sie den Befehl /sbin/service dhcpd stop ein.

Wenn mehrere Netzwerkschnittstellen in Ihrem System vorhanden sind, Sie aber möchten, dass der DHCP-Server nur auf einer Schnittstelle startet, können Sie den DHCP-Server entsprechend konfigurieren. Fügen Sie in der Datei /etc/sysconfig/dhcpd den Namen dieser Schnittstelle zu der Liste von DHCPDARGS hinzu:

# Befehlszeilenoptionen hier 
DHCPDARGS=eth0

Dies ist sinnvoll, wenn Sie einen Rechner mit Firewall und zwei Netzwerk-Karten haben. Eine der Netzwerk-Karten kann als DHCP-Client konfiguriert werden, um eine IP-Adresse aus dem Internet abzurufen. Die andere Netzwerkkarte kann als DHCP-Server für das interne Netzwerk hinter der Firewall benutzt werden, wodurch das System sicherer wird, da Benutzer über das Internet keine Verbindung zu dem Daemon aufnehmen können.

In /etc/sysconfig/dhcpd können noch andere Befehlszeilenoptionen festgelegt werden, wie zum Beispiel:

Mit dem DHCP Relay Agent (dhcrelay) können Sie DHCP- oder BOOTP-Anfragen des Subnets, die keinen DHCP-Server haben, auf einen oder mehrere DHCP-Server anderer Subnets übertragen.

Wenn ein DHCP-Client Daten anfragt, gibt der DHCP Relay Agent die Anfrage an die Liste der DHCP-Server weiter, die angegeben wurden, als der DHCP Relay Agent gestartet wurde. Wenn ein DHCP- Server antwortet, wird die Antwort als Broadcast oder Unicast auf das Netzwerk übertragen, das die ursprüngliche Anfrage gesendet hat.

Der DHCP Relay Agent wartet auf DHCP-Anfragen an allen Schnittstellen, es sei denn, die Schnittstellen werden in /etc/sysconfig/dhcrelay mit der Anweisung INTERFACES angegeben.

Um den DHCP Relay Agent zu starten, geben Sie den Befehl service dhcrelay start ein.

Angenommen, Sie verwalten ein Firmennetzwerk. Solche Netzwerke bestehen meistens aus Betriebssystemen, Applikationen, Servern, Netzwerküberwachung, Firewalls, Intrusion-Detection-Systemen und vielem mehr. Stellen Sie sich jetzt vor, Sie müssen dahingehend immer auf dem neuesten Stand sein. Durch die Komplexität heutiger Software und Netzwerkumgebungen sind Angriffe auf einen Rechner unter Ausnutzung eines Sicherheitslochs und Bugs eine Gewissheit. Mit allen Patches und Updates für ein gesamtes Netzwerk auf dem Laufenden zu sein, ist eine gewaltige Aufgabe innerhalb eines großen Unternehmens mit heterogenen Systemen.

Wenn Sie nun diese gewaltigen Anforderungen an das Wissen mit der Aufgabe, immer auf dem neuesten Stand zu sein, kombinieren, sind Vorfälle, Systemeinbrüche, Datenkorruption und Serviceunterbrechungen unvermeidbar.

Um den Nutzen dieser Sicherheitstechnologien zu erhöhen und dabei zu helfen, Systeme, Netzwerke und Daten zu schützen, sollten Sie sich in die Lage eines Crackers versetzen und die Sicherheit der Systeme durch das Suchen von Schwachstellen testen. Vorbeugende Schwachstellenanalysen für Ihre eigenen Systeme und Netzwerkressourcen können potentielle Problemstellen aufdecken, bevor ein Cracker diese zu seinem Vorteil ausnutzen kann.

Würden Sie zum Beispiel eine Schwachstellenanalyse für Ihr Haus durchführen, würden Sie wahrscheinlich prüfen, ob jede Tür geschlossen und auch abgeschlossen ist. Sie würden auch jedes Fenster prüfen und sicherstellen, dass diese richtig schließen und abgeschlossen werden können. Das gleiche Konzept gilt auch für Systeme, Netzwerke und elektronische Daten. Benutzer mit böswilligen Absichten sind die Diebe und Vandalen Ihrer Daten. Konzentrieren Sie sich auf deren Tools, Mentalität und Beweggründe, denn so können Sie schnell auf deren Taten reagieren.

Schwachstellenanalysen können in zwei Arten klassifiziert werden: von außen innen herumschnüffeln und innen herumschnüffeln.

Wenn Sie eine Schwachstellenanalyse von außen betrachtet durchführen, so versuchen Sie, Ihr System von außen zu kompromittieren. Wenn Sie Ihre Firma von extern betrachten, versetzen Sie sich in die Sichtweise eines Crackers. Sie sehen, was der Cracker sehen kann — öffentlich-weiterleitbare IP-Adressen, Systeme auf Ihrer DMZ, externe Schnittstellen Ihrer Firewall und vieles mehr. DMZ steht für "Demilitarized Zone", was einem Computer oder einem kleinen Subnetzwerk entspricht und welche sich zwischen einem internen, zuverlässigen Netzwerk befindet, wie z.B. einem gemeinschaftlichen privaten LAN und einem unzuverlässigen, externen Netzwerk, wie z.B. das öffentliche Internet. Üblicherweise beinhaltet die DMZ Geräte, die für den Internetverkehr zugänglich sind, wie z.B. Web(HTTP)-Server, FTP-Server, SMTP(E-Mail)-Server und DNS-Server.

Wenn Sie eine Schwachstellenanalyse von innen betrachtet durchführen, haben Sie den gewissen Vorteil, das Sie bereits intern sind, und Sie einen Status des vertrauens haben. Dies ist der Blickwinkel, den Sie und Ihre Kollegen haben, wenn Sie sich einmal im System angemeldet haben. Sie sehen Druckserver, Dateiserver, Datenbanken und andere Ressourcen.

Es gibt klare Unterscheidungen zwischen diesen beiden Arten der Schwachstellenanalyse. Als interner Mitarbeiter Ihres Unternehmens besitzen Sie höhere Privilegien; weit mehr als jeder Außenstehende. Entsprechend sind die Sicherheitsrichtlinien in den meisten Unternehmen nach wie vor so konfiguriert, externe Eindringlinge fernzuhalten. Es wird nur sehr wenig für die interne Sicherung des Unternehmens getan (z.B. Firewalls für Abteilungen, Zugangskontrollen auf Benutzerebene, Authentifizierungsvorgänge für interne Ressourcen und so weiter. Üblicherweise gibt es wesentlich mehr Ressourcen, wenn man sich intern umschaut, da die meisten Systeme in einem Unternehmen intern sind. Sobald Sie sich einmal außerhalb eines Unternehmens befinden, erhalten Sie sofort den Status vertrauensunwürdig zu sein. Die extern zugänglichen Systeme und Ressourcen sind für gewöhnlich wesentlich stärker eingeschränkt.

Betrachten Sie die Unterschiede zwischen Schwachstellenanalyse und Eindringungstests. Sehen Sie die Schwachstellenanalyse als ersten Schritt zu einem Eindringungstest an. Die Informationen aus der Schwachstellenanalyse werden im Test angewendet. Mit der Analyse wird nach Löchern und möglichen Schwachstellen im System gesucht, während der Eindringungstest die Ergebnisse in die Tat umsetzt.

Die Einschätzung der Netzwerk-Infrastruktur ist ein dynamischer Prozess. Das Durchführen der Analyse gibt einen Überblick über positive sowie negative Aspekte.

Sicherheits-Administratoren sind nur so gut wie die Tools, die diese benutzen, und das Wissen, das diese bewahren. Nehmen Sie eines der aktuell erhältlichen Analysetools und lassen Sie es über Ihr System laufen Dabei ist fast garantiert, dass einige Schwachstellen gefunden werden, die gar nicht existieren. Ob durch einen Programmfehler oder Benutzerfehler hervorgerugen, das Ergebnis ist das gleiche. Das Tool findet Schwachstellen, die gar nicht existieren, oder schlimmer noch, findet wirklich existierende Schwachstellen nicht.

Da wir nun den Unterschied zwischen Schwachstellenanalyse und Eindringungstest definiert haben, ist es ratsam, die Ergebnisse der Analyse sorgfältig zu prüfen, bevor Sie den Eindringungstest tatsächlich durchführen.

In der folgenden Liste werden einige der Vorteile einer Schwachstellenanalyse aufgezeigt.

Eine typische Analyse beginnt mit dem Einsatz eines Tools für das Sammeln von Informationen. Bei der Analyse des gesamten Netzwerks sollten Sie zuerst das Layout festlegen, um aktive Hosts zu identifizieren. Sobald diese gefunden wurden, sollten Sie jeden Host einzeln untersuchen. Das Untersuchen dieser Hosts bedarf weiterer Tools. Das Wissen, welche Tools für was verwendet werden, ist der wohl bedeutendste Schritt beim Aufdecken von Schwachstellen.

Wie bei jedem Aspekt des täglichen Lebens gibt es viele verschiedene Tools, die die gleiche Arbeit verrichten. Dies trifft auch auf Schwachstellenanalysen zu. Es gibt Tools, die speziell für Betriebssysteme, Applikationen oder Netzwerke (basierend auf Protokollen) eingesetzt werden können. Einige Tools sind kostenlos, andere wiederum nicht. Einige Tools sind intuitiv und benutzerfreundlich, andere eher kryptisch und schlecht dokumentiert oder besitzen Features, die andere Tools wiederum nicht haben.

Das Finden der richtigen Tools kann eine Herausforderung darstellen. Schlussendlich zählt die Erfahrung. Wenn möglich, richten Sie ein Testlabor ein und probieren soviele Tools aus wie nur möglich, und beachten Sie dabei die Stärken und Schwächen. Lesen Sie die README-Datei oder man-Seite zum Tool. Suchen Sie zusätzlich dazu im Internet nach weiteren Informationen wie Artikel, Schritt-für-Schritt-Anleitungen und Mailinglisten für ein Tool.

Die untenstehend beschriebenen Tools sind nur ein kleines Beispiel der erhältlichen Tools.

nmap foo.example.com

Starting nmap V. 3.50 ( www.insecure.org/nmap/ ) Interesting ports on localhost.localdomain (127.0.0.1): (The 1591 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 25/tcp open smtp 111/tcp open sunrpc 443/tcp open https 515/tcp open printer 950/tcp open oftep-rpc 6000/tcp open X11 Nmap run completed -- 1 IP address (1 host up) scanned in 71.825 seconds

Wenn Sie Pakete auf Ihrem System aktualisieren, ist es wichtig, das Update von einer vertrauenswürdigen Quelle herunterzuladen. Ein Angreifer kann leicht eine Version eines Paketes nachbauen (mit der gleichen Versionsnummer des Pakets, das theoretisch das Problem lösen sollte), jedoch mit einem anderen Sicherheitsrisiko im Paket, und dieses im Internet veröffentlichen. Falls dies geschieht, kann dieses Risiko durch Sicherheitsmaßnahmen wie das Abgleichen der Pakete gegen die ursprünglichen RPMs nicht aufgedeckt werden. Es ist daher wichtig, dass Sie RPMs nur von Quellen wie Red Hat Inc. herunterladen und die Signatur des Pakets prüfen, um dessen Integrität sicherzustellen.

Red Hat bietet zwei Möglichkeiten, um Informationen über Sicherheitsupdates zu erhalten:

rpm --import /mnt/cdrom/RPM-GPG-KEY

rpm -qa gpg-pubkey*

gpg-pubkey-db42a60e-37ea5438

rpm -qi gpg-pubkey-db42a60e-37ea5438

rpm -K /tmp/updates/*.rpm

rpm -Uvh /tmp/updates/*.rpm

rpm -ivh /tmp/updates/<kernel-package>

rpm -e <old-kernel-package>

TCP-Wrapper bieten Zugriffskontrolle für eine Reihe von Diensten. Die meisten modernen Netzwerkdienste, wie z.B. SSH, Telnet und FTP, verwenden TCP-Wrapper, die als Wachposten zwischen einer eingehenden Anfrage und dem angefragten Dienst stehen.

Die Vorteile von TCP-Wrappern werden noch erweitert, wenn diese zusammen mit xinetd, einem Super-Serverdienst, der zusätzliche Zugriffs-, Log-, Binding-, Umleitungs- und Ressourcenkontrolle bietet, verwendet werden.

In den folgenden Unterkapiteln wird davon ausgegangen, dass Sie ein grundlegendes Wissen über jedes Thema besitzen und sich auf spezielle Sicherheitsoptionen konzentrieren.

 220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Inappropriate use will result in your access privileges being removed. 

 vsftpd : ALL : banners /etc/banners/ 

 ALL : 206.182.68.0 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert 

 in.telnetd : ALL : severity emerg 

flags           = SENSOR

deny_time       = 30

disable         = no

Der portmap-Dienst ist ein dynamischer Port-Zuweisungs-Daemon für RPC-Dienste wie NIS und NFS. Er besitzt schwache Authentifizierungsmechanismen und hat die Fähigkeit, eine große Bandbreite an Ports für die von ihm kontrollierten Dienste zuzuweisen. Aus diesen Gründen ist portmap schwer zu sichern.

Wenn Sie RPC-Dienste ausführen, sollten Sie diese Grundregeln beachten.

iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 111 -j DROP
iptables -A INPUT -p tcp -s 127.0.0.1  --dport 111 -j ACCEPT

iptables -A INPUT -p udp -s! 192.168.0.0/24  --dport 111 -j DROP

Network Information Service (NIS) ist ein RPC-Dienst mit dem Namen ypserv, der zusammen mit portmap und anderen zugehörigen Diensten verwendet wird, um Informationen zu Benutzernamen, Passwörtern und anderen sensiblen Daten an jeden beliebigen Computer innerhalb dessen Domain weiterzugeben.

Ein NIS-Server besteht aus mehreren Applikationen, unter anderem:

Im Vergleich zu heutigen Standards ist NIS als eher unsicher einzustufen. Es besitzt keine Host-Authentifizierungsmechanismen und überträgt Informationen, einschließlich Passwort-Hashes, unverschlüsselt über das Netzwerk. Aus diesem Grund müssen Sie beim Einrichten eines Netzwerks mit NIS extreme Vorsicht walten lassen. Dadurch, dass die Standard-Konfiguration von NIS von Natur aus unsicher ist, wird die Angelegenheit noch weiter verkompliziert.

Es wird empfohlen, dass Sie, bevor Sie einen NIS-Server implementieren wollen, zuerst den portmap-Dienst wie im Abschnitt 9.1.2, „Portmap sichern“ beschrieben sichern und dann weitere Angelegenheiten wie Netzwerkplanung angehen.

ypcat -d <NIS_domain> -h <DNS_hostname> passwd

ypcat -d <NIS_domain> -h <DNS_hostname> shadow

255.255.255.0     192.168.0.0

YPSERV_ARGS="-p 834" YPXFRD_ARGS="-p 835"

iptables -A INPUT -p ALL -s! 192.168.0.0/24  --dport 834 -j DROP
iptables -A INPUT -p ALL -s! 192.168.0.0/24  --dport 835 -j DROP

Der Apache HTTP-Server ist einer der stabilsten und sichersten Dienste, die mit Red Hat Enterprise Linux ausgeliefert werden. Es gibt eine große Anzahl von Optionen und Methoden, um den Apache HTTP-Server zu sichern — zu viele, um sie hier im Detail zu beschreiben.

Systemadministratoren sollten folgende Konfigurationsoptionen mit äußerster Sorgfalt verwenden:

UserDir enabled
UserDir disabled root

chown root <directory_name>
chmod 755 <directory_name>

Das File Transport Protocol oder FTP ist ein älteres TCP-Protokoll, das zum Übertragen von Dateien über ein Netzwerk entwickelt wurde. Da alle Transaktionen mit dem Server, einschließlich der Benutzerauthentifizierung, unverschlüsselt ablaufen, wird es als ein unsicheres Protokoll betrachtet und sollte sorgfältig konfiguriert werden.

Red Hat Enterprise Linux bietet drei FTP-Server.

Die folgenden Sicherheitsrichtlinien gelten für das Einrichten des vsftpd-FTP-Dienstes.

ftpd_banner=<insert_greeting_here>

######### # Hello, all activity on ftp.example.com is logged. #########

banner_file=/etc/banners/ftp.msg

mkdir /var/ftp/pub/upload

chmod 730 /var/ftp/pub/upload

drwx-wx---    2 root     ftp          4096 Feb 13 20:05 upload

anon_upload_enable=YES

local_enable=NO

Sendmail ist ein Mail Transport Agent (MTA), der das Simple Mail Transport Protocol (SMTP) zur Übertragung elektronischer Nachrichten zwischen anderen MTAs und für das E-Mailen an Clients oder Delivery Agents einsetzt. Obwohl viele MTAs den Verkehr untereinander verschlüsseln können, tun dies viele nicht, so dass das Versenden von E-Mails über ein öffentliches Netzwerk als eine von Natur aus unsichere Form der Kommunikation betrachtet wird.

Es wird empfohlen, dass Sie sich mit den folgenden Angelegenheiten auseinandersetzen, wenn Sie die Implementierung eines Sendmail-Servers planen.