GNU/Linux Netzwerk Management

Lehrinhalt

  • Betrieb eines Linux-Servers mit Internet- bzw. Intranet-Diensten
  • Grundlegende Konfiguration eines Servers als Web-, Mail-, DNS- und FTP-Server
  • Allgemeine Maßnahmen zur Steigerung der Sicherheit im Internet und/oder LAN
  • Einrichten einer einfachen Paketfilter-Firewall mit iptables
  • Betrieb eines Linux-Servers als Firewall
  • Vertrautheit mit möglichen Angriffsszenarien

Inhalte

Auch in diesem Kurs sind die vorgegebenen Inhalte eng eingeschraenkt, was es ermöglicht, sehr gut auf den speziellen Bedarf der Teilnehmer einzugehen. Moegliche Inhalte sind unter anderem:

  • Manuelle Netzwerkkonfiguration sowie Konfiguration mittels NetworkManager (nmcli)
  • nc (netcat)
  • Security/ network scanner: nmap (graphisches Frontend: zenmap), dsniff (Tools, um 'cleartext' Sicherheitsprobleme zu finden), hping, fragroute, tcpdump, lanmap (erstellt ein png Bild der erkannten Netzwerkressourcen)
  • IDSs (intrusion detection systems): chrootkit, snort (signature-based stateful IDS), psad (erkennt Portscans)
  • Integrity Monitors: tripwire, aide
  • Logfile Monitors: swatch (Simple Watcher), logwatch
  • Monitoring mit ntop (Port 3000), iptraf (interaktiver LAN Monitor), iptstate, ethstatus, sntop (überwacht, ob eine gegebene Liste von Systemen online ist), iftop (zeigt aktuelle Netzwerknutzung der Programme mit einem top-ähnlichen Interface) und bandwidthd (überwacht die Netzwerknutzung und erstellt html Dateien mit Bildern)
  • Firewall Konfiguration/ Masquarading mit iptables und shorewall
  • Packetanalyse mit wireshark (früher bekannt als Ethereal; bei Interesse: englischsprachiges Video zu fortgeschrittenen I/O Graphen)
  • nslookup (set type={A,ANY,MX,NS,SOA}...), dig, nmblookup, findsmb

Netzwerkkonfiguration von der Kommandozeile

Um dem Server eine statische IP zuzuweisen und die Netzwerk Interfaces in Ubuntu korrekt einzustellen, muss die Datei /etc/network/interfaces editiert werden. Eine statische Konfiguration koennte zum Beispiel so aussehen (Raute-Zeichen geben Kommentare oder optionale Inhalte an)

auto lo
iface lo inet loopback
  address 127.0.0.1
  netmask 255.0.0.0

# The primary network interface
auto eth0
iface eth0 inet static
  address     192.168.1.15
  netmask     255.255.255.0
  gateway     192.168.1.1
  # network   192.168.1.0
  # broadcast 192.168.1.255
  # hwaddress ether 94:C3:8F:7B:1E:BC
  # dns-nameservers 143.50.19.25 143.50.56.25
  # dns-search find-santa.eu


# Network layer virtual hosting
# auto eth0:0
# iface eth0:0 inet static
#   address     192.168.1.16
#   netmask     255.255.255.0
#   gateway     192.168.1.1

Nach dem Editieren der Datei können die neuen Inhalte mit folgendem Befehl ohne einen Neustart übernommen werden (vorsicht - bevor man die Einstellungen übernimmt, sollte man sicherstellen, dass die neue Konfiguration auch funktioniert, falls man nicht lokal an der Maschine arbeitet)

sudo /etc/init.d/networking restart

Die neue Netzwerkkonfiguration kann in Folge mit folgenden Tools ausgelesen und getestet werden

/sbin/ifconfig [-a]
/sbin/route [-n]
/sbin/ip route ls
ping
tracepath
arp

Weitere relevante Dateien sind sind
/etc/resolv.conf enthält die Nameserver
/etc/hosts hier kann man statisch Namen zu IP Adressen zuordnen
/etc/networks verbindet Netzwerknamen mit Netzwerknummern
/etc/nsswitch.conf[, /etc/host.conf] resolver configuration - legt mitunter die Reihenfolge der DNS Auflösung fest
/etc/services Liste bekannter Netzwerkdienste und ihrer Ports

Tools

netstat

Netstat ist ein nützliches Tool (eigentlich eine Kombination von mehreren Tools), um die Netzwerkkonfiguration zu überprüfen. Folgend ein paar sehr simple Anwendungsbeispiele
netstat -r hat den vergleichbaren Output wie route
netstat -i zeigt Statistiken für die einzelnen Interfaces an
netstat -ta zeigt aktive und wartende (listening) TCP Verbindungen
netstat -tan ditte, aber die IP Nummern werden nicht aufgelöst (schneller)
netstat -tln zeigt nur listening Ports
netstat -tlnp ditte, jedoch wird auch angegeben, welche Prozess auf welchen Port lauscht
netstat -ua zeigt aktive und wartende (listening) UDP Verbindungen
netstat -xa zeigt aktive und wartende (listening) Unix Sockets

nmap

Nmap ist ein universeller Sicherheits-/ Netzwerkscanner, der so vielseitig ist, dass er hier nur erwähnt sei und eigentlich einen eigenen Kurs verdient. Eine besonders simple Anwendung ist herauszufinden, welche Geräte in einem Subnetz aktiv sind (ein Ping scan). Für das lokale Netz 192.168.1.0/24 geht das mit

nmap -sP -v 192.168.1.0/24

Alternativ könnte das obige Subnetz auch mit 192.168.1.* angesprochen werden. Eine weitere einfache Anwendung ist herauszufinden, ob ein Server auf einem bestimmten Port aktiv ist. Um zum Beispiel herauszufinden, ob ein Server auf den IMAP port von mail.example.com lauscht, verwendet man

sudo nmap -PO -p 143 mail.example.com

Für einen schnellen Einstieg, empfiehlt sich das gelungene graphische Frontend "Zenmap", welches allerdings nicht über alle Möglichkeiten des Commandline-Tools nmap verfügt.

nmcli

Konfiguration des NetworkManager von der Kommandozeilen.

nmcli  [ OPTIONS ] OBJECT { COMMAND | help }

nmcli { nm | con | dev } { COMMAND | help }
nm     NetworkManager
       COMMAND := { status | permissions | enable | sleep | wifi | wwan | wimax }
con    Connections
       COMMAND := { list | status | up | down | delete }
dev    Devices
       COMMAND := { status | list | disconnect | wifi }

Häufiger verwendet man zum Beispiel

nmcli con status

um herauszufinden, welche Verbindungen derzeit bestehen. Der Status der Netzwerkadapter wird mittels

nmcli dev

angezeigt (das default Kommando von dev ist status).

pktstat

Pktstat zeigt die aktuellen Verbindungen auf einem Interface an (d.h. von wo mit welcher Geschwindigkeit Daten übertragen werden). Möchte man zum Beispiel die Verbindungen über das erste WLAN Interface geordnet nach Datentransfer (top mode) aufschlüsseln, reicht

sudo pktstat -i wlan0 -t

tcpdump

Tcpdump erlaubt es, den gesamten Netzwerk-Traffic auf einem Computer mitzuschneiden, um dadurch zum Beispiel Probleme in Webapplikationen zu diagnostizieren. Tcpdump erlaubt es insbesondere, Packete mitzuschneiden, auch wenn keinerlei graphische Benutzeroberfläche installiert ist, da es komplett von der Kommandozeile aus benützbar ist. Die mitgeschnittenen Packete können danach bequem mit Wireshark untersucht werden. Ein simples Beispiel, bei dem der Traffic aller Interfaces mitgeschnitten und in die Datei /full_dump.cap geschrieben wird, ist

tcpdump -i any -s 0 -w /full_dump.cap

Zu beachten ist, dass der obige Befehl am Besten durch

pkill -2 tcpdump

zu beenden ist, da sonst das letzte Paket abgeschnitten sein kann, was zu Fehlermeldungen in Wireshark führen würde.

Apache

Dieser Bereich beschäftigt sich eingehend mit der Konfiguration des Apache Webserves in der Version 2.2. Wer nur eine ganz kurze Installationsanleitung haben möchte, sollte besser im Bereich Apache 2 Webserver mit PHP 5 aus meinem Linux Administrationskurs nachlesen.

Die Übungsdateien vom Lehrbuch kannst du von http://examples.oreilly.com/apache3/ herunterladen. Ein paar etwas an die Version 2.2 des Servers angepasste im Kurs verwendete Konfigurationsbeispiele (jedoch ohne Kommentare) gibt es unter apache_2.2.tar. Die von mir zusammengestellten Minikonfigurationen funktionieren (mindestens) unter Ubuntu Server 7.04 ohne jegliche Änderungen, wenn die Übungsdateien des Buchs (site.xxx Verzeichnisse) in /var/www/book zu finden sind. Die vorhandenen Beispiele sind lediglich von demonstrativem Nutzen und sollten für den praktischen Gebrauch stark angepasst werden. Wie immer übernehme ich keinerlei Haftung für mögliche Konsequenzen aus der Benutzung meiner Beispiele. Insbesondere sollte auf keinen Fall das angegebene Beispiel zum Theme SSL in Kapitel 11 mit dem hier publizierten "privaten" Schlüssel verwendet werden.

Die zentrale Konfigurationsdatei des Webservers ist apache2.conf (in manchen Distributionen heißt die Datei httpd.conf), welche in Ubuntu 12.04 mit

sudo emacs /etc/apache2/apache2.conf

zu editieren ist.

Testen des Servers

Es mag trivial erscheinen, dass der Webserver mit einem Webbrowser zu testen ist. Da wir die Webseiten und die Einstellungen des Servers allerdings immer wieder ändern, kann es sein, dass der Browser nicht die aktuelle Version anzeigt. Daher empfiehlt es sich, falls einmal nicht das angezeigt wird, was man sich erwartet, den Browsercache etc. zu leeren. Es kann sogar hilfreich sein, den Cache (und unter Umständen auch die History) komplett zu deaktivieren. Ich persönlich gehe dabei so vor, zwei Browser zu verwenden - einen mit "normalen" Einstellungen, den anderen mit Einstellungen, die zum Testen optimiert sind. Es ist auch sehr nützlich, sich ein wenig mit wireshark auszukennen, um den Traffic zwischen Client und Server zu analysieren. Weiters kann es von Interesse sein, den Server mit Telnet zu testen

shell> telnet my.server.at 80
telnet> GET /1.txt HTTP/1.1
telnet> Host: my.virtualhost.at

die Telnet Eingabe ist durch zweifaches drücken der Eingabetaste zu beenden. Es ist auch interessant, andere HTTP Methoden wie zum Beispiel DELETE auszuprobieren. Ein weiteres nützliches Tool zum Testen des Server ist logresolve, dass die IP Adressen einer Logdatei in Computernamen umwandelt. Die simples Syntaxbeispiel ist

logresolve < access_log > access_log_resolved

Falls es Probleme gibt, kann am Client mit

sudo nmap -PO -p 180 my.server.at

gecheckt werden, ob eine Verbindung zum Server hergestellt werden kann und am Server mit

lsof -i :80

herausgefunden werden, ob andere Prozesse den relevanten Port nutzen bzw. überlasten.

Security (Hardening)

Ein paar grundlegende Sicherheitseinstellungen können durch editieren von

/etc/apache2/conf.d/security

vorgenommen werden. Ich empfehle dabei so wenig Informationen über den Server wie möglich preiszugeben, um potentiellen Angreifern die Reconnaissance zu erschweren. Dazu sollten folgende Einstellungen vorgenommen werden

ServerTokens Prod
ServerSignature Off

Zu beachten ist, das diese Einstellungen durch virtuelle Hosts (in sites-enabled) überschrieben werden können. Wichtig ist auch, dass solche Anpassungen für sich alleine ein System noch (lange) nicht sicher machen.

Direktiven

Folgend findest du die in den einzelnen Beispielen verwendeten Direktiven, wobei je Beispiel nur die neuen Direktiven aufgelistet sind. Beispiel 1 (Kapitel 2 im verwendeten Buch Apache - The Definitive Guide verwendet folgende Direktiven (das erste Wort in jeder Zeile bezeichnet die Direktive, der Rest die verwendeten Argumente dazu)

ServerRoot /etc/apache2/
User www-data
Group www-data
ErrorLog logs/error_log
LoadModule mime_module /usr/lib/apache2/modules/mod_mime.so
LoadModule autoindex_module /usr/lib/apache2/modules/mod_autoindex.so
TypesConfig .../mime.types
PIDFile .../httpd.pid
DocumentRoot subdirectory/of/serverroot
Listen [host:]portnumber

Virtual Hosts

Darauf aufbauend verwendet das nächste Kapitel folgende neue Direktiven (der dreistellige Code von ErrorDocument beschreibt den Grund des Fehlers, zB.: 404 bedeutet, dass das Dokument nicht gefunden wurde; hier findest du eine Liste von 57 Statuscodes; die darauffolgende Aktion kann ein auszugebender String oder ein Link zu einer anderen Webseite sein)

TransferLog logs/access_log
ErrorDocument <3-digit-code> <action>
LoadModule dir_module /usr/lib/apache2/modules/mod_dir.so
<IfModule mod_dir.c>
  DirectoryIndex index.html index.cgi index.pl index.php index.xhtml
</IfModule>
<VirtualHost host[:port]>
  ServerName www1.server.at
  ...
</VirtualHost>
<VirtualHost host2[:port]>
  ServerName www2.server.at
  ...
</VirtualHost>

Im obigen Beispiel verwenden wir "echte" virtuelle Hosts, das heisst, der Server muss über mehrere IP Adressen verfügen. Zum Glück ist dies in Linux nicht nur durch mehrere reale Netzwerkkarten zu erzielen, sondern auch durch die Definiton von mehreren virtuelle Interfaces (zum Beispiel eth0:0). Falls man jedoch auf einer einzigen IP Adresse mehrere virtuelle Hosts laufen lassen möchte, so geht das nach dem Muster in folgenden Beispiel

NameVirtualHost addr[:port]
<VirtualHost addr[:port]>
  ServerName www1.server.at
  ...
</VirtualHost>
<VirtualHost addr[:port]>
  ServerName www2.server.at
  ...
</VirtualHost>

Es ist auch möglich, trotz der Verwendung von NameVirtualHost zusätzlich noch IP basierte virtuelle Hosts zu verwenden, jedoch kann die direktive NameVirtualHost in jeder laufenden Instanz von Apache nur einmal verwendet werden. Logs kann man entweder global oder je virtual Host definieren. Ausser den beiden präsentierten Verfahren, kann man auch Port basiertes virtual Hosting verwenden. In diesem Fall ist es natürlich nötig, jeden verwendeten Port mit einer Listen direktive zu deklarieren.

Authentication, Authorization und Access Control

Authentifizierung ist jener Vorgang, in der du überprüfst, ob jemand der ist, der er vorgibt zu sein. Autorisierung ist jeder Vorgang, der jemandem erlaubt, die Informationen zu haben, die sie haben will bzw. dorthinzugehen, wo sie hin will. Unabhängig von Authentifizierung und Autorisierung gibt es noch Zugangskontrollen, die jede Art der Kontrolle des Zugriffs auf Ressourcen bezeichnen.

ServerAdmin me@my.mail.server
ScriptAlias /cgi-bin/ /var/www/book/cgi-bin/
LoadModule alias_module /usr/lib/apache2/modules/mod_alias.so
LoadModule authn_file_module /usr/lib/apache2/modules/mod_authn_file.so
LoadModule authz_user_module /usr/lib/apache2/modules/mod_authz_user.so
LoadModule authz_groupfile_module /usr/lib/apache2/modules/mod_authz_groupfile.so
LoadModule auth_basic_module /usr/lib/apache2/modules/mod_auth_basic.so
<Directory directory>
  AuthType Basic
  AuthName "auth-realm"
  AuthUserFile filename
  AuthGroupFile filename
  Require valid-user
</Directory>

Die Benutzer-/Passwortdatei, welche AuthUserFile als Argument übergeben wird, kann mit htpasswd erstellt und verwaltet werden (siehe htpasswd -h für weitere Informationen). Die Gruppendatei hat folgendes Format

group1: user1 [user2 ...]
group2: userX [userY ...]
...

Das Modul mod_auth_basic bietet zwar für einfache Konfigurationen einen gewissen Schutz, aufgrund mangelnder echter Verschlüsselung ist aber das Modul mod_auth_digest vorzuziehen. Alternativ kann man die Authentifizierung auch mit SSL verbinden. Die zusätzlich für mod_auth_digest nötigen direktiven sind (authn_file_module und authz_user_module sind nach wie vor nötig)

LoadModule auth_digest_module /usr/lib/apache2/modules/mod_auth_digest.so
<Directory directory>
  AuthType Digest
  AuthName auth-realm
  AuthDigestDomain URI [URI ...]
  AuthDigestProvider file
  AuthUserFile filename
  Require valid-user
</Directory>

Statt htpasswd verwendet man für die Digest Authentifizierung das Tool htdigest, um die Benutzer-/Passwortdatei zu verwalten. Unabhängig von den beiden obigen Verfahren kann auch nach der IP Adresse oder der Domain des Clients gefiltert werden. Dafür verwendet man folgende Direktiven

LoadModule authz_host_module /usr/lib/apache2/modules/mod_authz_host.so
<Directory directory>
        Order allow,deny
        Allow from 192.168.123
        Deny from all
</Directory>

Im vergleich zu der Methode, Authentifizierung durch die zentrale Apache Konfigurationsdatei zu erledigen, hat die Verwendung von .htaccess Dateien zwei große Vorteile: es muss der Server nicht neu gestartet werden, wenn die Konfiguration geändert wird und man braucht keinen Zugriff auf die Konfigurationsdatei. Dem stehen aber gravierende Einbusen bei der Performance des Servers (da die Datei bei jedem Zugriff auf eine Datei in deren Verzeichnis und jedem Parent-Verzeichnis bis einschlieslich dem Unix / Verzeichnis gelesen wird, unabhängig von der Verwendung von DocumentRoot und Serverroot) und bei unvorsichtiger Konfiguration grobe Sicherheitsprobleme (falls Einstellungen der zentralen Konfiguration überschrieben werden können, was per default erlaubt ist) gegenüber. Dennoch sollte man diesen in manchen Fällen nützlichen Mechanismus zumindest verstehen und damit ein wenig umgehen können. (Die für die Authetifizierung nötigen Module sind zu laden)

AccessFileName filename
<Directory directory>
  AllowOverride All|None|directive-type [directive-type ...]
</Directory>

Content Negotiation

Da internationale Webserver oft ihre Inhalte in mehreren Sprachen anbieten, gibt es auch Mechanismen, mit denen man mehrere Sprachen parallel am Server ablegen kann. Solche mehrsprachigen Dateien werden in der Regel in mehrere Dateien nach folgendem Muster unterteilt: index.html.de (für Deutsch), index.html.en (für Englisch), index.html.ko (für Koreanisch),...
Einige der für diesen Mechanismus nötigen Direktiven sind 

LoadModule negotiation_module /usr/lib/apache2/modules/mod_negotiation.so
AddCharset charset extension [extension ...]
AddLanguage MIME-lang extension
LanguagePriority MIME-lang MIME-lang ...
DefaultLanguage MIME-lang
MultiviewsMatch [Negotiated Only] [Handlers] [Filters] [Any]
Options +MultiViews

Ausser dem Mechanismus mit MultiViews gibt es auch den moderneren, aber komplizierteren Mechanismus der type-map.

Indexing

Wenn in einem Verzeichnis keine Indexdatei (index.{html,php,...}) vorhanden ist, so zeigt Apache, wenn das nötige Modul (mod_autoindex) geladen ist, eine Liste der im Verzeichnis befindlichen Dateien und Unterverzeichnisse an. Diese Liste kann unter Verwendung der Direktiven des Moduls mod_autoindex stark personifiziert werden (folgend nur ein Auszug der vorhandenen Direktiven)

LoadModule autoindex_module /usr/lib/apache2/modules/mod_autoindex.so
IndexOptions [+|-]option [[+|-]option ...]
AddDescription string file [file ...]
IndexIgnore file [file ...]
AddIconByType icon MIME-type [MIME-type ...]
AddIcon icon name [name] ...
DefaultIcon url-path
HeaderName filename
ReadmeName filename

In Ubuntu 7.04 sind die Icons von Apache 2 in /usr/share/apache2/icons zu finden. Eine aktuelle Liste von Optionen der IndexOptions Direktive für Apache 2.2 findest du auf der Seite mod_autoindex.html#indexoptions

Redirection

Das dynamische Verändern/ Anpassen von URLs erledigt Apache entweder mit seinen Alias und Redirect Direktiven des mod_alias oder mit dem viel mächtigeren mod_rewrite. Letzteres behandle ich im Kurs nicht, da es zu viel Zeit in Anspruch nimmt und einiges an Kenntnisse über regulären Ausdrücken erfordert. Ein paar der wichtigeren Alias und Redirect Direktiven sind

LoadModule alias_module /usr/lib/apache2/modules/mod_alias.so
ScriptAlias URL-path file-path|directory-path
Alias URL-path file-path|directory-path
Redirect [status] URL-path URL
LoadModule userdir_module /usr/lib/apache2/modules/mod_userdir.so
UserDir directory-filename

SSL

Zuerst muss openssl installiert werden ein Zertifikat erstellt und selbst signiert werden. Die zweite openssl Anweisung erstellt dabei einen privaten Schlüssel ohne Passwort, da man eventuell das Passwort nicht bei jedem Serverneustart eingeben möchte.

sudo bash
apt-get install openssl
cd /etc/ssl
openssl req -config openssl.cnf -new -out certs/mycert.csr
openssl rsa -in privkey.pem -out mykey.key
openssl x509 -in certs/mycert.csr -out mycert.cert -req -signkey mykey.key -days 365
mkdir /etc/apache2/ssl
mv mycert.cert /etc/apache2/ssl
mv mykey.key /etc/apache2/ssl
mv privkey.pem private/

In der Folge muss die Apache Konfigurationsdatei so geändert werden, dass SSL verwendet wird. Dazu sind folgende zwei Direktiven in die Konfiguration einzufügen

LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so
SSLRandomSeed startup builtin
SSLSessionCache None
Alle weiteren Einstellungen sind bei den virtuellen Hosts zu erledigen 
<VirtualHost *:443>
    ...
    SSLEngine On
    SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:!SSLv2:+EXP:+eNULL
    SSLCertificateFile ssl/mycert.cert
    SSLCertificateKeyFile ssl/mykey.key
</VirtualHost>

Um die Änderungen zu übernehmen ist nun noch der Server neu zu starten. Davor kann man die Konfigurationsdateien aber mit apache2ctl überprüfen

apache2ctl -t
sudo /etc/init.d/apache2 restart

Die verschlüsselte Verbindung sollte nun funktionieren. Um sich zum Server zu verbinden darf man nicht vergessen, dass nun "https" als Protokoll anzugeben ist, der Server einstweilen aber lediglich auf Port 80 aktiv ist (daher ist eine Verbindung vorerst nur mit https://my.linux.server:80/ möglich).

LDAP Konfiguration

Die folgenden Schritte erfordern einen konfigurierten LDAP Server, welcher von dem Apache Server aus zu erreichen ist (im gegebenen Beispiel ist das ldap.company.com). Falls das LDAP Modul in /etc/apache2/mods-enabled/ noch nicht aktiviert ist, so kann dies mittels

sudo a2enmod authnz_ldap

einfach erledigt werden. Daraufhin sind in /etc/apache2/sites-enabled/ in die gewünschte Konfigurationsdatei innerhalb der zu schützenden <Directory> oder <Location> Umgebung die folgenden Direktiven hinzuzufügen:

AuthType Basic
AuthName "Authorized staff only"
AuthBasicProvider ldap
AuthzLDAPAuthoritative on
AuthLDAPUrl ldap://ldap.company.com/ou=People,dc=company,dc=com?uid
Require ldap-user testuserA testuserB
Satisfy any

Um die Änderungen zu übernehmen ist Apache noch mit

sudo apache2ctl restart

neu zu starten. Weitere Informationen finden sich in der offiziellen mod_authnz_ldap Dokumentation von Apache.

Netfilter und IP Tables

Netfilter ist der ab Linux 2.4 im Kernel enthaltene Firewallcode und iptables das dazugehörige Interface im Userspace. Damit lassen sich sehr komplexe Firewalls inklusive NAT (Network Address Translation) erstellen (SNAT (Source NAT), DNAT (Destination NAT) und MASQUERADING (eine spezielle Form von SNAT) sind möglich). Mit den schier unendlichen Möglichkeiten dieser Firewall kommt leider auch eine gewisse Schwierigkeit bei der Konfiguration, die mehr als nur grundlegendes Verständnis von Firewalls voraussetzt. Um dem entgegenzuwirken gibt es eine große Anzahl an Frontends, die bei der Einrichtung der Firewall helfen sollen. Ein solches ist Firestarter, welches eine GTK basierte grafische Oberfläche bietet. Firestarter eigenet sich auch für die Verwendung durch relative Anfäger, ist jedoch allein wegen seines GTK Interfaces nicht mehr für Server zu verwenden. Ich persönlich würde Firestarter lediglich auf Clientmaschinen nach dem "Defense in Depth" Prinzip empfehlen.

sudo apt-get install firestarter

Ein herausragend mächtiges, jedoch dennoch den direkten Umgang mit iptables drastisch vereinfachtendes Tool ist shorewall (Shoreline Firewall). Dieses Frontend zeichnet sich durch eine exzellent dokumentierte Konfiguration mit reinen Textdateien aus, was den Einsatz auf Servern ermöglicht.

sudo apt-get install shorewall

Einen sehr kompakten Einstieg in eine simple Konfiguration (nur ein Interface) bietet standalone.htm (auf Englisch) von der Homepage des Projekts. Die im Kurs erstellte Konfiguration ist in apache_2.2.tar enthalten. Die für eine Grundkonfiguration zu verändernden Dateien sind (teilweise reicht es, die Vorlagen zu kopieren)

/etc/default/shorewall
/etc/shorewall/interfaces
/etc/shorewall/modules # copy /usr/share/doc/shorewall/default-config/modules
/etc/shorewall/policy  # no need to edit
/etc/shorewall/rules   # consider /usr/share/shorewall/macro.*
/etc/shorewall/zones   # no need to edit

Eine Defaultkonfiguration kann in

/usr/share/doc/shorewall/examples/

gefunden werden. Eine gute Hilfe sind auch die zahlreichen man-pages, welche wie gewohnt unter man shorewall* zu finden sind.

Eine Alternative zur Shoreline Firewall ist das grafische Programm Firewall Builder (http://www.fwbuilder.org, sudo apt-get install fwbuilder), welches es ermöglicht, auf einem Clientsystem eine komplexe Firewall für einen Server (oder jedes andere System) zu designen. Dies erfordert allerdings ähnlich wie bei der Shoreline Firewall bereits ein großes Fachwissen über Linux Firewalls. Der Vorteil den ich hier bei Shorewall sehe ist, dass man früher merkt, wenn man sich nicht genug auskennt. Firewall Builder kompiliert das erstellte Design in eine iptables Firewall, die man auf einem anderen Rechner einsetzten kann. Trotz all der schönen Tools rund um iptables, sollte man sich dennoch zumindest ein paar grundlegende Optionen von iptables verinnerlichen

# Lists the rules for chain (or for all chains if no chain is given)
iptables -L [chain] [-n]
# Flushes (deletes) all rules from chain (or from all chains if no chain is given)
iptables -F [chain]
# Deletes the user-defined chain, or all user-defined chains if none is given
iptables -X [chain]
# Sets a default policy for a chain
iptables -P chain ACCEPT | DROP
...

ufw - uncomplicated firewall

Eine mit Ubuntu Server 16.04 sehr empfehlenswerte Alternative zur Firewallkonfiguration ist ufw. Mit dem Packe kann die Firewall einfach konfiguriert und automatisch gestartet werden. Eine Beispielkonfiguration über die Shell ist

sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https
sudo ufw allow samba
sudo ufw default deny
sudo ufw logging on 
sudo ufw enable
sudo ufw status

DNS und BIND

Domain Name Service dient der Übersetzung von Domainnamen in IP Adressen und umgekehrt. Der Berkely Internet Name Domain, früher Berkely Internet Name Daemon (BIND) von Paul Vixie ist der wohl bekannteste und am weitesten verbreitete DNS Server. Leider erhielt er einen Teil seiner Bekanntheit auch durch die lange Liste seiner gravierenden Sicherheitsprobleme. Eine schlanke, einfachere und sichere Alternative ist der djbdns von D. J. Bernstein. Trotz der Vorteile des djbdns gehe ich hier nur auf BIND ein, da er wegen seiner großen Verbreitung meines Erachtens einfach wichtiger ist und da man viele der Sicherheitsprobleme mit einem chroot cage (hier nicht erklärt) minimieren kann. Zuerst muß der Server installiert werden

sudo apt-get install bind9

Die ausführbare Datei von BIND heisst named, also sollte man bei Eingabe von ps ax danach suchen. Die Konfiguration ist in /etc/bind zu erledigen und leider durchaus komplex. Folgend nur die Einträge, die ich in die in Ubuntu 7.04 enthaltenen Konfigurationsdateien gemacht habe, sowie zwei Dateien, die ich ergänzt habe. Die von mir erstellte fiktive Domain heisst gallia.at. Die Ergänzungen zu /etc/bind/named.conf

...
zone "gallia.at" {
        type master;
        file "/etc/bind/db.gallia.at";
};

zone "123.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.192.168.123";
};
...

Die Datenbank mit den DNS Einträgen /etc/bind/db.gallia.at

;
;               Hosts at my private network
;               /etc/bind/db.gallia.at
;               Origin is gallia.at
;
$TTL 3D
@       IN      SOA     server.gallia.at.       gerald.server.gallia.at. (
                     2007071400         ; serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
        IN      NS      server.gallia.at.

localhost. IN   A       127.0.0.1

; gallia.at ethernet
server  IN      A       192.168.123.50
; set up menhir as alias for server
menhir  IN      CNAME   server
www     IN      CNAME   server
ssh     IN      CNAME   server
www2    IN      A       192.168.123.60
online  IN      A       192.168.123.61
tragicomix IN   A       192.168.123.10
tragi   IN      CNAME   tragicomix
tragicomix-wl IN A      192.168.123.11
wl      IN      CNAME   tragicomix-wl

Und die Datenbank mit den Reverse Lookup Einträgen /etc/bind/db.192.168.123

;
;               Hosts at my private network
;               /etc/bind/db.192.168.123
;               Origin is gallia.at
;
$TTL 3D
@       IN      SOA     server.gallia.at.       gerald.server.gallia.at. (
                     2007071400         ; serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
        IN      NS      server.gallia.at.

10      IN      PTR     tragicomix.gallia.at
11      IN      PTR     tragicomix-wl.gallia.at
50      IN      PTR     server.gallia.at
60      IN      PTR     www2.gallia.at
61      IN      PTR     online.gallia.at

Nach einem Neustart des DNS Servers und Änderung der für die Namensauflösung verantwortlichen Datei /etc/resolv.conf

sudo /etc/init.d/bind9 restart
sudo emacs /etc/resolv.conf

können folgende Tools zum Testen der neuen Konfiguration verwendet werden

dig dns-name
nslookup dns-name | ip-address

SSH (Secure Shell)

Nach der Installation des OpenSSH clients und servers mit

sudo apt-get install ssh

kann mit

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

der Fingerprint des rsa Schlüssels angezeigt werden, um ihn zu Authentifizierungszwecken an potentielle Nutzer des Servers weiterzugeben. Will man sich die Passwortabfrage beim Login ersparen, so empfehle ich folgendes Shellskript: enable_ssh_quicklogin.sh. Verbindet man sich sehr häufig zu einem oder mehreren Servern, so kann man sich ein wenig Tipparbeit ersparen. Zuerst muss man dafür das Miniskript ssh-to.sh nach ~/bin/ kopieren (wenn ~/bin/ noch nicht existiert, so muss es natürlich vorher erstellt und $PATH hinzugefügt werden). Danach macht man es ausführbar und erstellt in ~/bin/ einen Link mit dem Namen jedes Servers zu ssh-to.sh

chmod u+x ~/bin/ssh-to.sh
ln -s ~/bin/ssh-to.sh ~/bin/$SERVERNAME

Sobald dies geschehen ist, kann man sich durch Tippen des Servernamens allein zu diesem verbinden.

SSH Tunneling

Mit SSH ist es möglich auch andere Dienste zu verschlüsseln. Das prinzipielle Vorgehen dabei ist einen sogenannten SSH Tunnel zwischen der eigenen Maschine und dem Zielcomputer aufzumachen. Dieser Tunnel öffnet auf dem eigenen Computer einen frei wählbaren Port und verbindet diesen mit dem Service am Zielcomputer. Verbindet man sich nun mit diesem Port auf dem eigenen Computer, so verbindet man sich eigentlich zum Zielsystem - nur verschlüsselt. In Realität sind die Zielsysteme meist hinter einer Firewall versteckt, doch auch das ist kein Problem für einen Tunnel. Gehen wir von folgendem Szenario aus:
Wir wollen den eigenen Computer (localhost) über einen Gateway (gateway) zu einem Zielserver (target) verbinden (Port forwarding). Auf target läuft ein intener Webserver (Port 80), auf den wir zugreifen wollen. Ein ssh User-Account ist lediglich auf gateway notwendig.

ssh tunnel 
ssh gateway -L 1080:target:80 -f -N

wobei -L den Tunnel konfiguriert (legt fest, welcher lokale port über den Tunnel auf welchen Zielcomputer und welchen Port auf diesem verbinden soll), -f bedeutet, dass ssh im Hintergrund laufen soll und -N auf das Ausführen von Befehlen auf dem Zielcomputer verzichtet. Möchte man sich verschlüsselt zu einem Service direkt auf dem Gateway Computer verbinden, so ist lediglich der Hostname des Gateways auch als Ziel anzugeben

ssh gateway -L 1080:gateway:80 -f -N

Um den Tunnel nicht nur einmal zu starten, sondern gleich in der Konfiguration des SSH clients zu verewigen, erweitern wir ~/.ssh/config mit folgendem Eintrag

Host target-http-tunnel
  HostName gateway # name or ip of gateway host
  User username # your username on the gateway
  Compression yes
  CompressionLevel 9
  Localforward 1080 target:80

Der Name nach Host (hier: target-http-tunnel) ist frei wählbar. Es wäre zwar möglich, den Tunnel mit dem Kommando ssh target-http-tunnel zu öffnen, jedoch würden wir einen normale ssh shell bekommen bei derem Schließen auch der Tunnel geschlossen wird. In der Regel ist es also besser, den Tunnel mit

ssh -f -N target-http-tunnel

aufzumachen, wobei -f ssh im Hintergrund ausführt und -N auf das Ausführen eines Kommandos verzichtet (was natürlich nur in Verbindung mit Tunneln sinnvoll ist). Sobald der Tunnel gestartet ist, können wir unseren Webbrowser öffnen und durch Eingabe von http://localhost:1080 die Webseiten des Zielservers anzeigen. Für andere Tunnelanwendungen kann es sinnvoll sein, den Tunnel automatisch nach der letzten Verbindung zu schließen. Dies geht am einfachsten, indem man ihn mit foldendem Kommando öffnet

ssh -f any-tunnel sleep 15

Hier haben wir die Option -N durch das Kommando sleep 15 ersetzt. Nach ausführen der obigen Zeile haben wir also 15 Sekunden Zeit, eine Verbindung herzustellen, die danach auch automatisch offen gehalten wird. Schliessen wir die Verbindung, wird auch der Tunnel geschlossen.

Es ist auch möglich, mit einer einzigen ssh Verbindung gleichzeitig mehrere Tunnel zu öffenen. So können zum Beispiel Tunnel zu einem Firmeninternen CVS Server, einem internen Webserver, einem VNC Server und einem internen SSH Server geöffnet werden. Die dafür notwendige Konfiguration ist

Host open-tunnels
  HostName gateway.company.com
  User username # your username on the gateway
  Compression yes
  CompressionLevel 9
  ForwardX11 yes
  Localforward 2022 target:22
  Localforward 25900 target:5900
  Localforward 2080 internal-webserver.company.com:80
  Localforward 20000 cvs.company.com:22

Damit die Verbindung zum CVS Server funktioniert, muss zusätzlich noch folgende Sektion in ~/.ssh/config vorhanden sein:

Host internalcvs
  HostName localhost
  Port 20000

Darüber hinaus müssen auch die Systemvariablen CVSROOT und CVS_RSH an die neuen Einstellungen angepasst werden. Dazu sind folgende Einträge in ~/.bashrc zu machen (der Benutzername und der Pfad am CVS Server sind an die eigenen Werte anzupassen):

export CVSROOT=:ext:username@internalcvs:/var/cvs/cvsroot
export CVS_RSH=ssh

Links

Hier folgt eine (unsortierte) Aufstellung einiger der im Kurs gezeigten Webseiten.

Link kurze Beschreibung
http://httpd.apache.org/docs/2.2/ Apache 2.2 Dokumentation (in mehreren Sprachen inkl. Deutsch)
http://www.oreilly.com/catalog/apache3/ Homepage des im Kurs verwendeten Lehrbuchs "Apache: The Definitive Guide" (englische Version)
http://www.oreilly.com/catalog/linag3/ Homepage des im Kurs verwendeten Lehrbuchs "Linux Network Management" (englische Version)
http://www.automatisch.cc/software.html Liste freier text-mode Software

Copyright © 2009-2023 Gerald Senarclens de Grancy
Das Anfertigen von Kopien, deren Verwendung und Verteilung sind erlaubt und erwünscht, solange dieses Copyrightstatement in allen Kopien angefügt bleibt.
Die vorliegende Dokumentation wurde ausschließlich in meiner Freizeit als Service für ehemalige Seminarteilnehmer erstellt. Daher wird sie lediglich so wie sie ist zur Verfügung gestellt, ohne jegliche vertragliche oder gesetzliche Gewährleistung und ohne den Anspruch auf Korrektheit oder für irgendeinen Zweck geeignet zu sein.

Haftungsausschluss: Da ich keinerlei Einfluss auf den Inhalt der Seiten, zu denen ich von meiner Homepage linke, habe, übernehme ich auch keinerlei Haftung für diese Seiten.

[Valid XHTML 1.1!]