Ausführung von sicherheitsadministrativen Tätigkeiten

Beschreibung: Prüfungskandidaten sollten in der Lage sein, die Systemkonfiguration zu überprüfen, um die Sicherheit des Hosts in Übereinstimmung mit lokalen Sicherheitsrichtlinien sicherzustellen. Dieses Lernziel beinhaltet die Konfiguration von tcpwrappers, das Finden von Dateien mit gesetztem SUID/SGID-Bit, das Überprüfen von Softwarepaketen, das Setzen oder Ändern von Benutzerkennwörtern und des Ablaufs von Kennwörtern, das Aktualisieren von Programmdateien nach Empfehlung von CERT, Bugtraq und/oder Sicherheitswarnungen des Distributors. Ebenfalls enthalten ist ein grundsätzliches Wissen über ipchains und iptables.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

  • /proc/net/ip_fwchains
  • /proc/net/ip_fwnames
  • /proc/net/ip_masquerade
  • find
  • ipchains
  • passwd
  • socket
  • iptables

Bereits besprochene Techniken

Viele der hier verlangten Techniken sind an anderer Stelle dieses Study-Guides schon besprochen worden. Dazu zählen insbesondere

Diese Techniken werden hier nicht näher beschrieben, sondern als Wissen vorausgesetzt.

Auffinden von Programmen mit gesetztem SUID/SGID Bit

Programme, deren SUID-Bit oder SGID-Bit gesetzt sind, und die gleichzeitig als Eigentümer root haben, sind in dem Moment eine Sicherheitslücke, in dem es sich um Programme handelt, die einen Zugriff auf eine Shell ermöglichen. Viele Programme benützen dieses Feature um ganz gewöhnliche Aktionen vorzunehmen. Das klassische Beispiel ist das Programm passwd. Jeder normale User kann mit diesem Programm sein Passwort ändern. Die Datei, in der das verschlüsselte Passwort gespeichert wird (/etc/shadow) ist aber nicht für jeden User beschreibbar. So muß das Programm passwd das SUID-Bit gesetzt haben. Nur so kann es – unabhängig davon, wer es aufgerufen hat – die Datei verändern.

Um das ganze System nach Dateien zu durchsuchen, die dieses Bit (oder eines dieser Bits) gesetzt haben, benutzen wir den Befehl find. Mit der Suchoption -perm ist es möglich, Dateien zu suchen, die bestimmte Rechte gesetzt haben. Ein Zugriffsrecht von 4XXX bedeutet, daß das SUID-Bit gesetzt ist, ein 2XXX gibt an, daß das SGID-Bit gesetzt ist. Die Summe davon (6XXX) wären beide Bits gesetzt. Wenn dem angegebenen Zugriffsrecht ein Minuszeichen vorangeht, so ist gemeint, daß mindestens diese Rechte gesetzt sein müssen, es reicht also, nach 4111 oder gar 4000 zu suchen, wenn wir alle Programme mit SUID-Bit suchen.

  find / -perm -4000 -user root

sucht alle Dateien des gesamten Systems, die das SUID-Bit gesetzt haben und dem User root gehören. Das sind zunächst einmal überraschend viele Programme, es wäre also ratsam, die Ausgabe dieses Befehls direkt nach der Installation in eine Datei umzuleiten und regelmäßig den Befehl erneut aufzurufen und mit dieser Datei zu vergleichen.

Das entsprechende zum SGID-Bit wäre der Befehl

  find / -perm -2000 -group root

Die Angabe des Users wurde hier weggelassen, stattdessen suchen wir nach Dateien, die der Gruppe root zugehören. Ohne diese Angabe, würden alle Dateien mit gesetztem SGID-Bit angezeigt.

Grundlegendes zu Firewaltechniken

Der Begriff Firewall überspannt ein weites Feld an Missinterpretationen und falschen Vorstellungen. Es existieren verschiedenste Ansätze, die Sicherheit eines Netzes durch verschiedene Techniken zu verbessern, die alle diesen Namen für sich reklamieren. Die gesamte Thematik umfassend darzustellen würde den Rahmen dieses Kurses bei weitem sprengen, hier geht es nur um das grundlegende Verständnis von Paketfilterfirewalls unter Linux.

Die Firewalltechnik unter Linux basiert auf sogenannten Paketfilterregeln. Ein- und ausgehende Pakete können nach folgenden Kriterien durchgelassen oder abgewiesen werden:

  • Sender IP-Adresse
  • Empfänger IP-Adresse
  • Sender-Port
  • Empfänger-Port
  • SYN und ACK-Flag
  • Verwendete Netzwerkschnittstelle

Die Regeln werden mit einem kommandozeilenorientierten Programm formuliert und stehen dann im Kernelspeicher. Die eigentliche Firewall, also das Programm, das Pakete durchlässt oder abweist, ist kein separates Programm sondern der Kernel selbst.

Dieses Programm, zur Formulierung der Regeln hat zwischen der Kernel-Version 2.2 und 2.4 gewechselt. Das Standard-Programm bei Kerneln der 2.2 Reihe war ipchains. Es funktioniert unter gewissen Umständen auch noch bei neueren Kerneln. Seit der Version 2.4 existiert stattdessen das Programm iptables, das die selbe Aufgabe hat, sie aber etwas anders löst. Eine Grundkenntnis beider Programme wird für die LPI102 Prüfung vorausgesetzt.

Bevor jedoch die einzelnen Programme besprochen werden, noch etwas Theorie, die für das Verständnis beider Programme unabdingbar ist.

Prinzipielles zur TCP/IP Datenübertragung

Um eine Paketfilter-Firewall selbst aufzubauen sind fundierte Kenntnisse der TCP/IP Datenübertragung notwendig. Denn wir müssen ja verschiedenste Regeln formulieren, die sich auf die Datenpakete und deren Protokollheader beziehen. So soll hier nochmal kurz das wichtigste zum Thema Datenübertragung im IP-Netz dargestellt werden.

Der prinzipielle Ablauf einer Datenübertragung

Grundsätzlich müssen wir, angesichts des TCP/IP Schichtenmodells, unterscheiden, was eigentlich wie übertragen werden soll. Uns stehen im Prinzip drei Protokolle zur Verfügung, die vorkommen können: ICMP Das Internet Control Message Protocol arbeitet noch auf der Vermittlungsschicht und dient der Übertragung von Kontrollnachrichten von Rechner zu Rechner. Es benützt selbst keine Ports, aber es werden verschiedene ICMP Nachrichtentypen unterschieden, die in Firewallregeln wie Ports behandelt werden. Ein Beispiel ist Ping, dessen ausgehendes Format vom Typ 8 ist, während das Antwortpaket (pong) den Typ 0 hat. TCP Das Transmission Control Protocol ist das verbindungsorientierte Protokoll auf der Transportschicht. Es benutzt Portnummern, um die jeweiligen Anwendungen auf der obersten Schicht zu adressieren. TCP benutzt einen dreiteiligen Handshake, dessen Ablauf für die Firewallregeln noch Bedeutung haben wird. UDP Das User Datagram Protocol ist das verbindungslose Protokoll auf der Transportschicht. Auch dieses Protokoll benutzt Portnummern, es hat jedoch keinerlei Handshake, also auch keine Flags, die wir bei der Formulierung der Regeln nutzen könnten. Eine Datenübertragung besitzt – aus der Sicht der Firewall – zwei grundsätzlich unterschiedliche Abläufe. Entweder unser Rechner schickt eine Anfrage an einen Server eines anderen Rechners und bekommt Antwort von ihm, oder ein fremder Client schickt eine Anfrage an einen unserer Server und bekommt Antwort von uns.

Im Prinzip laufen alle Übertragungen nach dem gleichen Muster ab. Ein Client fängt mit einer Anfrage an einen Server an und der antwortet ihm. Dabei spielen die Portnummern eine große Rolle. Um einen Dienst auf einem anderen Rechner anzusprechen, muß der Client also die IP-Adresse des Servers und die Portnummer des gewünschten Dienstes kennen. Damit der Server ihm auch antworten kann, muß der Client auch seine eigene IP-Adresse angeben und eine Portnummer, auf der er selbst lauscht. Da der Client keine fest zugewiesene Portnummer besitzt, wählt er sich einfach eine beliebige Nummer aus dem Pool der unprivilegierten Portnummern (1024 bis 65535) aus.

Wir können also davon ausgehen, daß ein Paket mit einer Anfrage des Clients an den Server folgendes an Header-Information beinhaltet:

  • Die IP-Adresse des Servers
  • Die bekannte Portnummer des gewünschten Dienstes auf dem Server
  • Die IP-Adresse des Clients
  • Eine beliebige Portnummer zwischen 1023 und 65535, die sich der Client selbst gewählt hat.

Eine Ausnahme dieses Prinzips haben wir bei ICMP, dort hat der Sender selbst keinen Port bzw. keinen Pakettyp.

Handshake bei TCP

Bei der Verwendung von TCP als Protokoll gibt es eine weitere Besonderheit. Hier werden noch sogenannte Flags gesetzt, also Optionen, die besondere Steuerfunktionen haben. Eine Verbindung von Client zu Server beginnt bei TCP immer folgendermaßen:

Der Client schickt ein Paket mit folgender Header-Information an den Server:

Empfänger IP:Empfänger Port:Sender IP:Sender Port:Flags:
IP-Adresse des Servers z.B. 123.45.67.89Portnummer des gewünschten Dienstes z.B. 80Eigene IP-Adresse des Clients z.B. 111.22.33.44Zufällige Portnummer z.B. 12345SYN

Der Client setzt also das SYN-Flag, gleichbedeutend mit der Nachfrage nach einem Verbindungsaufbau (Synchronisation). Der Server schickt jetzt ein Paket zurück, das folgende Information beinhaltet:

Empfänger IP:Empfänger Port:Sender IP:Sender Port:Flags:
IP-Adresse des Clients-111.22.33.44Portnummer des Clients-12345IP-Adresse des Servers-123.45.67.89Portnummer des Server-Dienstes-80SYN und ACK

Der Server setzt also einerseits das ACK (Acknowledge) Flag um zu zeigen, daß er den Verbindungsaufbau gewährt und setzt zusätzlich nochmal das SYN-Flag um seinerseits die Verbindung anzufordern. Das nächste Paket des Clients enthält jetzt nur noch das ACK-Flag:

Empfänger IP:Empfänger Port:Sender IP:Sender Port:Flags:
IP-Adresse des Servers-123.45.67.89Portnummer des Server-Dienstes-80IP-Adresse des Clients-111.22.33.44Portnummer des Clients-12345ACK

Von diesem Moment an gilt die Verbindung als etabliert und alle weiteren Pakete haben jetzt grundsätzlich das ACK-Flag und niemals mehr das SYN-Flag gesetzt. Aus dieser Handshake-Methode heraus ist anhand der Flags grundsätzlich festzustellen, ob ein Paket eine Nachfrage eines Clients an einen Server darstellt oder nicht. Zusammengefasst kann man sagen, daß ein Paket immer dann eine Client-Nachfrage beinhaltet, wenn das SYN-Flag gesetzt und das ACK-Flag nicht gesetzt ist.

Diese fünf (TCP) bzw. vier (UDP) Kriterien stehen uns also für die Firewall zur Verfügung. Anhand dieser Eigenschaften müssen wir entscheiden, ob wir ein Paket durchlassen oder nicht.

Architektur der Firewall-Regelketten

Eine Linux-Paketfilter Firewall besteht aus sogenannten Regelketten (chains). Standardmäßig existieren drei solcher Ketten:

  • Die output-chain, die alle Pakete betrifft, die den Rechner verlassen
  • Die input-chain, die alle Pakete betrifft, die der Rechner empfängt
  • Die forward-chain, die alle Pakete betrifft, die der Rechner routen soll.

Alle drei Regelketten können unterschiedliche Grundeinstellungen haben, gemeinsam ist ihnen, daß sie eine Sammlung (Verkettung) von Regeln besitzen, die nacheinander abgearbeitet werden, solange bis eine Regel zutrifft oder das Ende der Kette erreicht wurde.

Es stehen drei Grundeinstellungen zur Verfügung:

  • ACCEPT – Ein Paket wird akzeptiert
  • DENY – Ein Paket wird wortlos abgewiesen
  • REJECT – Ein Paket wird mit Fehlermeldung abgewiesen.

Hat eine Kette die Grundeinstellung (Policy) ACCEPT, so bedeutet das, das grundsätzlich alles erlaubt ist, was nicht explizit verboten ist. Hat sie aber DENY oder REJECT als Grundeinstellung, so ist alles verboten, was nicht explizit erlaubt wurde.

Der zweite Fall ist mit Sicherheit die bessere Wahl, wenn es darum geht, ein System richtig abzusichern, auch wenn es zunächstmal mehr Arbeit bedeutet. Schematisch dargestellt könnte man die Grundeinstellung ACCEPT folgendermaßen darstellen:

Die DENY-Grundeinstellung hingegen sähe so aus:

Grundlagen von ipchains

Das Programm, mit dem die Linux-Paketfilterfirewall seine Regeln definiert, heisst bis zur Kernelversion 2.2 ipchains. Dieses Programm hat verschiedene Aufrufformen, die alle zu besprechen den Rahmen dieser Darstellung sprengen würde. Ich werde mich hier auf die notwendigen Formen beschränken, die den Umgang mit dem Programm klären.

ipchains formuliert Regeln, die dann direkt in den Speicher geschrieben werden. Das hat zur Folge, daß diese Regeln nach einem Neustart allesamt wieder verschwunden sind. Es empfielt sich also, die Regeln in Form eines Shellscripts zu formulieren.

Grundlegende Parameter von ipchains

Einer der folgenden Parameter muß immer der erste von ipchains sein. Diese Parameter schließen sich aus, es darf in einem Aufruf also immer nur einer der folgenden Parameter auftauchen: -ARegelkette … Eine Regel wird ans Ende der angegebenen Regelkette (input, output oder forward) angehängt. Wird keine Regelkette angegeben, so gilt die Regel für alle Regelketten. -IRegelkette … Eine Regel wird an den Anfang der angegebenen Regelkette (input, output oder forward) eingefügt. Wird keine Regelkette angegeben, so gilt die Regel für alle Regelketten. -FRegelkette Alle bestehenden Regeln der angegebenen Kette werden gelöscht. Die Grundeinstellung (Policy) bleibt jedoch erhalten. Wird keine Regelkette angegeben, so werden alle Regeln aller Regelketten gelöscht. -PRegelkette Policy Die angegebene Policy (DENY, REJECT oder ACCEPT) wird zur Grundeinstellung der genannten Regelkette.

Um Regeln zu definieren werden wir also mit ipchains -A arbeiten. Der Angabe der Kette folgen dann die entsprechenden Regelformulierungen.

Darstellungsart von Ports und Adressen

Wir werden bei jeder zu formulierenden Regel sowohl mit Portnummern, als auch mit IP-Adressen arbeiten müssen. Dabei stehen uns folgende Darstellungsmöglichkeiten zur Verfügung:

IP-Adressen können mit einer Maske versehen werden, die die signifikannten Bits der Adresse angibt. Diese Maske wird als Bitmaske realisiert und einfach mit einem Slash (/) hinten an die Adresse angehängt. Die Bedeutung ist einfach, die Adressangabe

  192.168.100.123/24

bedeutet, daß die ersten 24 Bit der Adressangabe mit der gefundenen Adresse übereinstimmen müssen, damit die Regel greift. In diesem Beispiel sind das also alle Adressen, die vorne 192.168.100 stehen haben. Eine Maske /32 bedeutet also, daß die Adresse exakt übereinstimmen muß, eine Maske /0 bedeutet, daß kein Bit übereinstimmen muß, also alle Adressen gemeint sind. Dafür ist auch die Abkürzung any/0 zulässig.

Ports werden als Nummern angegeben. Soll ein ganzer Bereich von gültigen Portnummern angegeben werden, so wird das in der Form

dargestellt.

Parameter zur Darstellung der Regeln

Nach der Angabe des Parameters -A (oder -I) und der gewünschten Kette folgen verschiedene Angaben, die alle erfüllt sein müssen, wenn die Regel zutreffen soll. Die wichtigsten Parameter sind: -i Interface Die Netzwerkschnittstelle für die die Regel gilt. Hier werden die symbolischen Schnittstellennamen wie eth0, eth1, ppp0, ippp0,.. eingesetzt. -p Protokoll Hier wird das vom Paket verwendete Protokoll angegeben, also icmp, tcp oder udp. -y Das SYN-Flag einer TCP-Nachricht muß gesetzt, das ACK-Flag darf nicht gesetzt sein. Das Paket ist also das erste eines Verbindungsaufbaues und kommt vom Client. ! -y Das ACK-Flag einer TCP-Nachricht muß gesetzt sein. Das heißt, das Paket ist entweder der zweite Teil des Verbindungsaufbaues oder, es ist ein Teil einer bestehenden Verbindung. Ist weder -y noch ! -y gesetzt, werden die TCP-Flags nicht überprüft. -s IP-Adresse [ Portnummer ] Absenderadresse (Source) des Paketes und optional die Absenderprtnummer. -d IP-Adresse [ Portnummer ] Empfängeradresse (Destination) des Paketes und optional der Empfängerport. -j Policy Policy dieser Regel. Gültige Policies sind ACCEPT, REJECT und DENY. In der forward-Chain ist auch die Policy MASQ für Masquerading zulässig.

Formulierung von Regeln

Für jede Art von Datenverbindung müssen wir mindestens zwei Regeln formulieren, eine für die input-chain und eine für die output-chain. In der Regel werden diese Formulierungen sich immer an den folgenden Aufbau halten:

  ipchains -A Regelkette -i Interface -p Protokoll \
           -s Absenderadresse Absenderport \
           -d Empfängeradresse Empfängerport -j Policy

In manchen Fällen wird dem Protokoll noch die Angabe ! -y folgen oder einzelne Ports werden weggelassen. Aber der grundsätzliche Aufbau hält sich immer an diese Struktur.

Aufbau eines eigenen Firewall-Scripts

Um ein komplettes Firewallscript zu schreiben fehlt uns hier der benötigte Rahmen, wir können aber die Regeln für die wichtigsten Dienste hier formulieren und alles weitere kann dann – sofern erwünscht – hinzugefügt werden.

Wir erstellen die Regeln am Besten in einem Shellscript, das wir dann jedesmal einfach aufrufen können, dann stellt sich gar nicht erst die Frage, wie einzelne Regeln gespeichert werden.

Das Script beginnt üblicherweise mit einem ganzen Satz von Variablendefinitionen, damit wir uns später leichter mit der Formulierung der Regeln tun:

  #!/bin/bash

  EXTERN_INTERFACE=eth0    # Unsere Netzschnittstelle
  LOOP_INTERFACE=lo        # Das Loopback Interface
  IPADDR=10.230.1.100      # Unsere IP-Adresse
  ANYWHERE=any/0           # Jede Adresse im Netz
  MYNET=10.230.1.0/24      # Unsere Netzadresse
  UNPRIVPORTS=1024:65535   # Die unprivilegierten Ports

Als nächstes löschen wir alle bestehenden Regeln. Falls wir das Script einmal mehrfach hintereinander starten kommt es so nicht zu Doppelregeln. Dadurch, daß wir keine Regelkette angeben, werden alle bestehenden Regelketten gelöscht.

  ipchains -F

Alle Ketten sind jetzt leer. Allerdings haben wir noch nicht die Grund-Policies gelöscht bzw. verändert. Sie bleiben auch nach dem Löschen vorhanden. Also stellen wir jetzt diese Policies ein, für jede Kette extra. Dazu stellt ipchains den Parameter -P (nicht verwechseln mit -p) zur Verfügung. Wir setzen alle drei Regelketten auf die Grundeinstellung DENY, also ist alles verboten, was nicht explizit erlaubt ist.

  ipchains -P input    DENY
  ipchains -P output   DENY
  ipchains -P forward  DENY

Ab hier ist jetzt also alles verboten. Es existieren keinerlei Regeln mehr, die Grundeinstellung ist DENY. Wir können uns ab diesem Moment nicht einmal mehr selbst anpingen.

Damit das Loopback-Interface wieder funktioniert erlauben wir in den nächsten beiden Regeln grundsätzlich alles auf diesem Interface.

  ipchains -A input  -i $LOOP_INTERFACE -j ACCEPT
  ipchains -A output -i $LOOP_INTERFACE -j ACCEPT

Jetzt erlauben wir alle ICMP-Pakete auf der Netzschnittstelle. Wir könnten zwar hier verschiedene Einschränkungen machen, aber das ist langwierig und kompliziert. Viele Programme benötigen ICMP-Nachrichten um z.B. eine Nichtverfügbarkeit oder ähnliche Fehlermeldungen zu übertragen.

  ipchains -A input -i $EXTERN_INTERFACE -p icmp -j ACCEPT
  ipchains -A output -i $EXTERN_INTERFACE -p icmp -j ACCEPT

Jetzt funktioniert wenigstens ein Ping schonmal wieder. Allerdings nur mit numerischen IP-Adressen. Denn wir haben noch keinerlei Zugriff auf Nameserver. DNS funktioniert in den meisten Fällen über UDP auf Port 53. Wir können jetzt die erste vollständige Regel anwenden, indem wir den Zugriff auf Nameserver freischalten. Da uns über Port 53 wenig Gefahr droht geben wir ihn für alle frei, nicht nur für einen bestimmten Nameserver. Falls das nicht gewünscht wöre, müsste der Eintrag $ANYWHERE durch die IP-Adresse des Nameservers ersetzt werden.

  ipchains -A output -i $EXTERN_INTERFACE -p udp\
           -s $IPADDR $UNPRIVPORTS \
           -d $ANYWHERE 53 -j ACCEPT

  ipchains -A input -i $EXTERN_INTERFACE -p udp\
           -s $ANYWHERE 53 \
           -d $IPADDR $UNPRIVPORTS -j ACCEPT

Jetzt können wir anfangen, die wichtigen Dienste einzeln zu erlauben. Zunächst einmal HTTP (TCP Port 80) und HTTP mit SSL (TCP Port 443) Wir erlauben nur Antworten eines Servers an uns.

  ipchains -A output -i $EXTERN_INTERFACE -p tcp\
           -s $IPADDR $UNPRIVPORTS \
           -d $ANYWHERE 80 -j ACCEPT

  ipchains -A input -i $EXTERN_INTERFACE -p tcp ! -y\
           -s $ANYWHERE 80 \
           -d $IPADDR $UNPRIVPORTS -j ACCEPT

  ipchains -A output -i $EXTERN_INTERFACE -p tcp\
           -s $IPADDR $UNPRIVPORTS \
           -d $ANYWHERE 443 -j ACCEPT

  ipchains -A input -i $EXTERN_INTERFACE -p tcp ! -y\
           -s $ANYWHERE 443 \
           -d $IPADDR $UNPRIVPORTS -j ACCEPT

Sind wir selbst auch Webserver, dann müssen wir auch Zugriffe fremder Clients auf unseren Server zulassen und unsere Antwortpakete an diese Clients. Das könnte mit der Einschränkung passieren, daß wir nur Clients aus dem lokalen Netz ($MYNET) akzeptieren.

  ipchains -A input -i $EXTERN_INTERFACE -p tcp\
           -s $MYNET $UNPRIVPORTS \
           -d $IPADDR 80 -j ACCEPT

  ipchains -A output -i $EXTERN_INTERFACE -p tcp ! -y\
           -s $IPADDR 80 \
           -d $MYNET $UNPRIVPORTS -j ACCEPT

Schwieriger wird es mit FTP. Hier existieren zwei Portnummern (20 und 21), eine für den FTP-Befehlskanal und eine für den Datenkanal. Zudem existieren zwei Modi, der sogenannte aktive Modus und der passive Modus, der von den meisten Browsern verwendet wird. Der Unterschied liegt darin, daß der passive Modus beim Datenkanalaufbau auf beiden Ports (Sender und Empfänger) unprivilegierte Portnummern verwendet. Wir brauchen also 6 Regeln um als Client an einen FTP Server zu kommen:

  • Anfrage des lokalen Clients beim fremden Server
  • Antwort des fremden Servers
  • Datenkanalaufbau durch den fremden Server (aktiv)
  • Antwort auf Datenkanalaufbau durch den lokalen Client (aktiv)
  • Datenkanalaufbau des Clients zum fremden Server (passiv)
  • Antwort des fremden Servers auf Datenkanalaufbau (passiv)

In der oben genannten Reihenfolge sieht das also folgendermaßen aus:

  ipchains -A output -i $EXTERN_INTERFACE -p tcp \
           -s $IPADDR $UNPRIVPORTS\
           -d $ANYWHERE 21 -j ACCEPT

  ipchains -A input -i $EXTERN_INTERFACE -p tcp ! -y \
           -s $ANYWHERE 21\
           -d $IPADDR $UNPRIVPORTS -j ACCEPT

  ipchains -A input -i $EXTERN_INTERFACE -p tcp\
           -s $ANYWHERE 20\
           -d $IPADDR $UNPRIVPORTS -j ACCEPT

  ipchains -A output -i $EXTERN_INTERFACE -p tcp ! -y\
           -s $IPADDR $UNPRIVPORTS\
           -d $ANYWHERE 20 -j ACCEPT

  ipchains -A output -i $EXTERN_INTERFACE -p tcp\
           -s $IPADDR $UNPRIVPORTS\
           -d $ANYWHERE $UNPRIVPORTS -j ACCEPT

  ipchains -A input -i $EXTERN_INTERFACE -p tcp ! -y\
           -s $ANYWHERE  $UNPRIVPORTS\
           -d $IPADDR $UNPRIVPORTS -j ACCEPT

Das Gleiche in umgekehrter Reihenfolge wäre dann für einen eigenen FTP-Server nötig.

Dabei belassen wir es einmal, die Grundzüge des Aufbaus der Firewallscripts sind damit eigentlich geklärt. Jedes verwendete Protokoll benötigt also einen Regelsatz, der sowohl die eingehenden, als auch die ausgehenden Pakete berücksichtigt.

Unsere Firewall schützt bisher natürlich nur uns selbst, Aber die Mechanismen sind natürlich auch bei einer Firewall mit zwei Netzwerkkarten im Grunde die selben.

Grundlagen von iptables

Der grundsätzliche Aufbau von iptables ist sehr ähnlich dem von ipchains. Nur werden die Regelketten jetzt in Tabellen verwaltet, die jeweils einzelne oder mehrere Regelketten enthalten können. Das sollte zu einer größeren Übersichtlichkeit führen.

Drei Standard-Tabellen stehen zur Verfügung: nat Diese Tabelle ist zuständig für das IP-Masquerading oder Network Address Translation (NAT). Datenpakete, die durch einen Rechner geroutet werden, passieren diese Tabelle nur einmal. Die Regeln dieser Tabelle werden nur auf das erste Paket eines Datenstroms angewandt. Wenn dieses Paket passieren darf, so werden alle weiteren Pakete des gleichen Datenstroms automatisch maskeriert, ohne daß die Regeln jedesmal überprüft werden. Die Tabelle enthält drei Regelketten (chains), PREROUTING, OUTPUT und POSTROUTING. mangle Diese Tabelle ist dazu gedacht, einzelne Elemente des Headers zu verändern. Beispiele wären die Veränderung der Felder TTL, TOS oder MARK. Sie hat zwei Regelketten, PREROUTING und OUTPUT. Die erstere wird verwendet, um Pakete zu verändern, in dem Moment, in dem sie die Firewall erreichen, die zweite verändert Pakete, die innerhalb der Firewall erzeugt werden, bevor die Routing-Entscheidungen anstehen. filter Diese Tabelle entspricht im Wesentlichen der Aufgabenstellung des alten ipchains. Hier werden die Firewall-Regeln erstellt. Die drei bekannten Regelketten INPUT, FORWARD und OUTPUT sind hier eingebaut.

Der Befehl iptables erhält die Information, welche Tabelle er bearbeiten soll durch den Parameter -t Tabelle. Wird diese Angabe weggelassen, so wird standardmäßig die Tabelle filter angenommen.

Die eigentliche Formulierung der Regeln selbst entspricht ziemlich genau der von ipchains.

Sicherheitswarnungen

In der Welt der Informatik gibt es zwei wesentliche Philosophien, wie mit Sicherheitslücken in Programmen umgegangen werden soll. Die eine geht davon aus, daß Sicherheitslücken am Besten geheim bleiben sollen und stillschweigend – etwa mit Hilfe eines Service-Packs – beseitigt werden sollten. Die typische Vertreterin dieser These ist die Firma Microsoft. Die zweite Philosophie geht genau andersherum vor. Ihre These ist, daß Sicherheitslücken sofort öffentlich gemacht werden müssen, um es den entsprechenden Systemverwaltern sofort zu ermöglichen, Maßnahmen zu ergreifen, die die Löcher schließen können. Linux-Software wird in der Regel mit dieser zweiten Philosophie arbeiten.

Es gibt zwei große Einrichtungen, die zentral solche Sicherheitslücken aufdecken und veröffentlichen: BUGTRAQ und CERT.

BUGTRAQ ist eine moderierte Mailingliste, die für die detailierte Diskussion und Veröffentlichung von Sicherheitsproblemen zuständig ist. Hier wird beschrieben, was Sicherheitslücken genau sind, wie herausgefunden wird, ob sie ein bestimmtes System betreffen und wie sie beseitigt werden können.

Um sich an dieser Mailingliste zu beteiligen – lesend oder schreibend – muß eine Mail an LISTSERV@SECURITYFOCUS.COM geschickt werden, die im Mailkörper – nicht in der Überschrift – die folgende Anweisung besitzt:

  SUBSCRIBE BUGTRAQ Nachname, Vorname

Man erhält anschließend eine Bestätigungsmail, die man beantworten muß. Sobald diese Antwort auf die Bestätigungsmail eingegangen ist, ist man Mitglied der Liste und erhält regelmäßig die Nachrichten über neu entdeckte Sicherheitslücken.

Auf der Webseite von www.securityfocus.com können die Archive der Mailingliste eingesehen werden.

Die zweite große Institution für die Veröffentlichung von Sicherheitslücken ist CERT. Auf der Webseite von www.cert.org werden regelmäßig neue Sicherheitslücken und Lösungen dazu veröffentlicht.

Weitere wichtige Adressen im Internet sind:

www.sans.org

Diese Informationsquellen sollten regelmäßig konsultiert werden, um über neue Sicherheitsprobleme informiert zu sein und auftretende Schlupflöcher zu schließen.

Das Programm socket

Das Programm socket(1) erlaubt es, auf beliebigen Ports entweder Client- oder Serversockets aufzubauen, deren Datenströme mit der Standardein- und -ausgabe verbunden werden. Dieses Programm kann dazu benutzt werden, bestimmte Ports des eigenen Rechners zu überprüfen, ob von außen dort noch Zugriffe möglich sind.

Selbst wenn alle möglichen Dienste, die von außen zugreifbar sind, geschlossen wurden, so existiert mit socket eine Möglichkeit, Angriffe von innen heraus zuzulassen. Das Programm sollte also mit Vorsicht benutzt werden und sicherheitshalber nicht für alle User zugänglich sein.

Ähnliche Beiträge

Das /proc-Dateisystem
rmdir - löscht Verzeichnisse
Serverinstallation

Schreibe einen Kommentar