This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Das Firewall-Buch Grundlagen, Aufbau und Betrieb sicherer Netzwerke mit Linux
Alle in diesem Buch enthaltenen Programme, Darstellungen und Informationen wurden nach bestem Wissen erstellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund ist das in dem vorliegenden Buch enthaltene ProgrammMaterial mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autoren und die SuSE GmbH übernehmen infolgedessen keine Verantwortung und werden keine daraus folgende Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieses Programm-Materials, oder Teilen davon, oder durch Rechtsverletzungen Dritter entsteht. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann verwendet werden dürften. Alle Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt und sind möglicherweise eingetragene Warenzeichen. Die SuSE GmbH richtet sich im Wesentlichen nach den Schreibweisen der Hersteller. Andere hier genannte Produkte können Warenzeichen des jeweiligen Herstellers sein. Dieses Werk ist urheberrechtlich geschützt. Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Druck, Fotokopie, Microfilm oder einem anderen Verfahren), auch nicht für Zwecke der Unterrichtsgestaltung, reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden.
Die Deutsche Bibliothek – CIP-Einheitsaufnahme Barth, Wolfgang: Das Firewall-Buch : Grundlagen, Aufbau und Betrieb sicherer Netzwerke mit Linux / Wolfgang Barth. – Nürnberg : SuSE-Press, 2001 ISBN 3-934678-40-8
D Unterschiede zwischen iptables und ipchains D.1 Paket-Routing: Unterschiede
.
.
.
D.2 Änderungen von ipchains auf iptables
445 .
.
.
.
446
.
.
.
.
449
E Informationsquelle Internet
453
E.1 SuSE-Linux
.
.
.
.
.
.
.
.
.
.
453
E.2 Security-Links
.
.
.
.
.
.
.
.
.
.
454
E.2.1
Allgemeine Security-Links
.
.
.
.
.
.
454
E.2.2
Linux Security-Links
.
.
.
.
.
.
.
455
E.2.3
Intrusion Detection
.
.
.
.
.
.
.
455
.
.
.
.
.
.
.
.
455
E.3 Verschiedenes
.
.
E.3.1
Linux Online
.
.
.
.
.
.
.
.
455
E.3.2
Linux und ISDN
.
.
.
.
.
.
.
.
456
XI
Inhaltsverzeichnis
XII
Kapitel 1 Ziel dieses Buches Dieses Buch beschäftigt sich mit dem Bau eines Firewalls mit frei (hier im Sinne von „kostenlos“) verfügbaren Mitteln aus dem Internet. Betriebssystem-Plattform ist das ebenfalls frei verfügbare, im Source-Code erhältliche und gut dokumentierte Unix-Derivat Linux. Ziel dieses Buches ist, für Sicherheitsfragen zu sensibilisieren, Firewalls als Bestandteil von Sicherheitsinfrastrukturen kennenzulernen und die Funktionsweise von Firewalls zu verstehen. Darüber hinaus sollten Sie nach der Lektüre in der Lage sein, eine eigene Sicherheitspolitik zu definieren und einen dazu passenden Firewall mit freien Werkzeugen aufzubauen und zu betreiben. Das Thema „Selbstbau“ bei Firewalls wird heftig diskutiert. Zum einen wird die Auffassung vertreten, daß bei „Open-Source“- oder „Public-Domain“-Programmen niemand die Verantwortung für Programmfehler trage und die Herkunft der eingesetzten Software oft zweifelhaft sei (zum Beispiel [Poh98]). Andere halten dagegen, daß bei kommerziellen Systemen niemand außer dem Hersteller die Funktionalität und Anfälligkeit des gekauften Firewalls kenne. Ein kommerzieller Firewall kostet zudem Geld und kommt daher kaum für private Anwendungen in Betracht. Bei hohen Ansprüchen an eine sichere Umgebung übersteigt der Aufwand für die Realisierung eines kommerziellen Systems zudem leicht den Aufwand für den Selbstbau ([DBC96]). Die Entscheidung „kaufen oder selbst bauen“ kann Ihnen niemand abnehmen. Der Autor ist jedoch der festen Überzeugung, daß Sie eine sachgerechte Entscheidung erst dann treffen können, wenn Sie sich intensiv mit dem befaßt haben, was sich hinter dem kurzen Stichwort „Firewall“ verbirgt. Im übrigen läßt sich der Aufwand, den ein Selbstbau mit sich bringt, ohnehin am besten abschätzen, indem man es einfach einmal versucht: learning by doing. Um überprüfen zu können, ob ein Firewall Ihren Anforderungen genügt, müssen Sie zunächst diese Anforderungen definieren. Auch dabei hilft Ihnen dieses
1
1 Ziel dieses Buches
Buch. Ein Kapitel widmet sich ausschließlich dem Thema „Sicherheitspolitik“. Wenn Sie Ihre Anforderungen klar bestimmt haben, müssen Sie zudem einschätzen können, ob ein Firewall (sei dieser nun kommerziell oder nicht) diese Anforderungen auch erfüllt. Hier ist ein vertieftes Verständnis für die Funktionalität von Firewalls unbedingt notwendig. Wenn Sie sich am Ende dieses Buches dennoch für ein kommerzielles Firewallsystem entscheiden, dann auch, weil Ihnen dieses Buch eine Fülle von Informationen an die Hand gibt, die eine solche Entscheidung erleichtern. Damit wäre dann auch ein Ziel dieses Buches erreicht: „Firewalls verstehen lernen“. Wenn Sie sich aber intensiv mit den vorgestellten Varianten auseinandergesetzt und diese in der Praxis umgesetzt haben, werden Sie vermutlich feststellen, daß das entworfene System Ihren Sicherheitsansprüchen genügt und damit die zusätzliche Auseinandersetzung mit kommerziellen Systemen überflüssig sein dürfte. Möglicherweise gehören Sie jedoch zu der Gruppe von Anwendern, die beim Einsatz freier (nun im Sinne von frei verfügbar und einsetzbar) Software aus dem Internet ein „ungutes Gefühl“ hat. Hier sei daher eine Lanze für freie Software gebrochen: Freie Software ist im Quellcode erhältlich und wird in der Regel von einer großen Schar freiwilliger Entwickler gepflegt. Die Verfügbarkeit des Quellcodes führt dazu, daß Fehler schneller erkannt und behoben werden als bei kommerziellen Systemen, und die rasche Fehlerbeseitigung gerade bei sicherheitsrelevanter Software ist allemal besser als das Totschweigen kaum bekannter Bugs. Auch wenn sich kommerzielle Hersteller immer häufiger bemühen, Öffentlichkeit in Bezug auf vorhandene Probleme herzustellen, und eine Fülle von Patches liefern, ist das keine Garantie dafür, daß Sicherheitslücken nicht wochen- oder monatelang in Hackerkreisen kursieren, bevor das Problem überhaupt entdeckt wird. Bei freier Verfügbarkeit des Quellcodes ist die Wahrscheinlichkeit unentdeckter Lücken wesentlich geringer. Über mangelnden Support kann sich bei freier Software ebenfalls niemand beklagen. Es ist durchaus üblich, daß für freie Software innerhalb weniger Stunden oder Tage ein Patch verfügbar ist (einschließlich Problemlösungen im Linux-Kernel für neue Angriffsvarianten), während bei kommerziellen Systemen weitaus mehr Zeit vergeht; kommerzieller Support ist zudem kostenpflichtig. Das „Bundesamt für Sicherheit in der Informationstechnik“ (BSI) empfiehlt daher auch, freie Software in die Überlegungen bei der Auswahl sicherheitskritischer Software mit einzubeziehen, und nennt vor allem die Möglichkeit der eigenen Source-Code Validierung als Vorteil (http://www.bsi.de/literat/doc/fuhrberg.htm). An anderer Stelle wird dort auch die freie Verfügbarkeit von Source-Code als Qualitätsmerkmal bezeichnet (http://www.bsi.bund.de/bsi-cert/webserv.htm).
2
1 Ziel dieses Buches
Natürlich gibt es auch Argumente für den Einsatz kommerzieller Werkzeuge. Wenn Sie ganz spezielle Anforderungen haben, kann es sein, daß diese nur ein kommerzieller Firewall erfüllt. Hersteller von Firewalls investieren viel Geld und Zeit in erweiterte Sicherheitsmechanismen. Diese Ressourcen stehen der Entwickler-Gemeinde freier Software nicht immer zur Verfügung. Mit freier Software können Sie vielleicht 90 % bis 95 % der denkbaren Mechanismen implementieren, aber wenn Sie auf die übrigen 5 % bis 10 % angewiesen sind, benötigen Sie doch kommerzielle Bausteine. Diese Überlegungen eröffnen einen dritten möglichen Weg: die Kombination aus freien und kommerziellen Elementen. So kann es sein, daß Sie auf ein Problem stoßen, das sich mit einer solchen Kombination am besten lösen läßt, und sei es, daß Sie beim Einsatz eines kommerziellen Firewalls nicht mit diesem exakt erfaßbare Sicherheitsrisken durch zusätzliche – vor- oder nachgeschaltete – freie Software minimieren. Zunächst müssen Sie für den Selbstbau eines Firewalls nicht viele Voraussetzungen mitbringen. Wenn Sie über eine Linux-Installation verfügen und damit auch Ihren Internetanschluß realisieren, können Sie einige Verfahren direkt umsetzen. Sie sollten es sogar. Wenn Sie eine komplexere Firewallstruktur einsetzen wollen (oder müssen), aber bisher wenig Erfahrung mit der Realisierung gesammelt haben, sollten Sie dieses Buch Schritt für Schritt durcharbeiten und dabei auch die praktischen Lösungsbeispiele der Reihe nach implementieren, um Übung mit den eingesetzten Verfahren zu bekommen. Dann fällt es Ihnen auch leichter, abseits der vorgeschlagenen Lösungen eigene Varianten zu entwickeln, die optimal auf Ihren Bedarf zugeschnitten sind.
Der Aufbau dieses Buches Zunächst werden Sie im Kapitel „Wozu braucht man Firewalls?“ in die Thematik eingeführt. Sie werden erfahren, daß ein Firewall in erster Linie ein Konzept, weniger ein Stück Hardware ist, auch wenn es manchmal so aussieht. Wozu ein Firewall dient – und was er nicht leisten kann – wird hier beschrieben. Das Kapitel „Security Policy“ macht Sie mit den Grundkonzepten der IT-Sicherheit vertraut und bietet Ihnen Handwerkszeug, um eine eigene Sicherheitspolitik festzulegen, denn schließlich möchten Sie Daten und Computersysteme schützen. Haben Sie erst einmal Ihre Sicherheitspolitik umrissen, können Sie einen Firewall gezielt als Bestandteil Ihrer IT-Sicherheit einsetzen. Anschließend führt ein Kapitel in die „Grundlagen des Firewalldesigns“ ein. Sie lernen die Bausteine von Firewalls, verschiedene Firewallkonzepte und damit eine Vielzahl neuer Begriffe kennen.
3
1 Ziel dieses Buches
Im Kapitel „Paketfilterung und Network Address Translation“ geht es bereits in die Praxis: mit Bordmitteln von Linux auf einer sehr tiefen Ebene, nämlich im Kernel selbst (dies ist außerordentlich wichtig für ein stabiles und sicheres System), lassen sich alle Anforderungen an einen Paketfilter abdecken. Network Address Translation, im Linux-Bereich ist eher die Untermenge „Masquerading“ bekannt, wird ebenfalls beschrieben. Zu einem Firewall gehören neben Paketfiltern auch Application-Level-Gateways, die sich mit sogenannten „Proxies“ realisieren lassen. Die wichtigsten freien Proxies aus dem Internet werden hier vorgestellt. Bevor es an den eigentlichen Aufbau geht, noch ein paar Überlegungen zu den häufigsten Anwendungen im Kapitel „Internetdienste und Firewalls“. Sie finden dort einige gängige Vorschläge, wie Sie verschiedene Anwendungen mit Ihrem Firewall umsetzen können. Nach so vielen Grundlageninformationen wird es Zeit für praktische Lösungsbeispiele. In den beiden Kapiteln „Firewalls bauen“ finden Sie verschiedene Abschnitte: zunächst den einfachen Fall eines direkt mit dem Internet verbundenen Rechners, auf dem einige grundlegende Security-Regeln umgesetzt werden. Darauf aufbauend, beschäftigt sich der zweite Abschnitt mit einem Router mit Firewallfunktion, der ein lokales Netz mit dem Internet verbindet. Im zweiten Teil dieses Abschnitts wird der Router über eine zweite Netzwerkkarte erweitert, um ein Grenznetz zu implementieren. Der dritte Abschnitt ist dann ein klassischer, zweistufiger Firewall mit einem echten Grenznetz zwischen zwei Routern: schon etwas anspruchsvoll und aufwendig, aber sehr modular anwendbar. Den Abschluß bildet dann ein Ausblick auf Hochsicherheitsanforderungen. Wenn Sie es bis dahin geschafft haben, haben Sie sich ganz bestimmt eine Atempause verdient. Allerdings sollten Sie sich damit noch nicht zufrieden geben: Einen Firewall zu implementieren ist eine Sache, ihn zu betreiben, zu warten und zu überwachen eine andere, mindestens ebenso wichtige. Darauf geht ausführlich das Kapitel „Maintenance: Firewalls installieren, betreiben, überwachen“ ein. Linz, im Februar 2001
4
Wolfgang Barth
Kapitel 2 Wozu braucht man Firewalls? 2.1 Der Begriff „Firewall“ Das englische Wort „Firewall“ läßt sich mit „Brandschutzmauer“ übersetzen. Dieses Bild ist treffend, aber auch wiederum nicht ganz. Eine Brandschutzmauer soll das Übergreifen eines Brandes von einem Bereich (z. B. einem Gebäudeteil) auf einen angrenzenden verhindern. Aufgabe einer Brandschutzmauer ist es also, nichts hindurch zu lassen. Andererseits hat eine Brandschutzmauer manchmal auch Löcher (in Form von Brandschutztüren zum Beispiel). Die Löcher in einer Brandschutzmauer lassen den Verkehr solange ungehindert passieren, bis ein Gefahrenfall (Brand) eintritt. Dann schließen die Türen hermetisch ab. Der hundertprozentige Schutz vor den Gefahren aus dem Internet ist nur gegeben, wenn gar keine Verbindung besteht. Es gibt viele Firmen, die sich den Aufwand zum Betreiben eines Firewalls gar nicht leisten können. Die Lösung kann dann mitunter sein, sogenannte Standalone-PCs aufzustellen, die zwar eine Verbindung zum Internet, aber keine Verbindung zum internen Netzwerk haben. Datentransfer von und zu diesen PCs (z. B. über Disketten) ist streng verboten. Manchmal ist das praktikabel – effektiv und kostengünstig ist es allemal. Wenn Sie die absolut sichere Brandschutzmauer suchen, dann benötigen Sie also keinen Firewall, sondern nur eine Schere für Ihre bisherige Internetanbindung. Was also ist ein Firewall genau? Sie möchten Daten mit anderen austauschen, egal, ob über Internet oder Extranet. Gleichzeitig soll aber auch sichergestellt werden, daß nur die geforderten Anwendungen und der damit verbundene Datenaustausch realisiert werden. Andere Daten sollen keinesfalls in das eigene Netzwerk gelangen oder dieses verlassen. In diesem Sinne ist ein Firewall eher vergleichbar mit einer Pforte mit strenger Zugangskontrolle (und eben weniger mit einer Brandschutzmauer). Ein Firewall trennt einen öffentlichen Bereich von einem privaten Bereich des Netzwerks ab.
5
2 Wozu braucht man Firewalls?
Der Einsatz eines Firewalls bedeutet bedingte Durchlässigkeit. Dort, wo Durchgangsverkehr gestattet ist, öffnet man ein Loch in der Brandschutzmauer und postiert einen Pförtner. Dort, wo kein Durchgang notwendig ist, mauert man die Brandschutzmauer zu, benötigt dann aber auch keinen Pförtner bzw. keinen Firewall. Der Pförtner – um im Bild zu bleiben – kontrolliert die Passanten nach definierten Kriterien. In Hochsicherheitsbereichen nicht nur die Person selbst, sondern auch Inhalte von Aktentaschen, Kofferräumen. Möglicherweise untersucht er sogar auf Strahlung. Üblicherweise assoziiert man mit einer Pforte eher die Einlaßkontrolle, aber auch die umgekehrte Richtung kann kontrolliert werden, in einigen Umgebungen muß sie das sogar. Ein Firewall ist ein Konzept für die Verbindung zwischen einem öffentlichen und einem nicht-öffentlichen Bereich. Ein Firewall kann nur aus einem einzigen Stück Hardware bestehen, muß es aber nicht. Der Begriff Firewall kann auch eine ganze Infrastruktur mit mehreren Servern, Routern und anderen Komponenten beschreiben.
2.2 Was ein Firewall kann . . . Ein Firewall kontrolliert eine Passage zwischen dem öffentlichen und dem nichtöffentlichem Teil eines Netzwerks und registriert den Verkehr zwischen diesen: ❏ Durchsetzen von Sicherheitsbestimmungen: Eine Firma kann ihren Mitarbei-
tern per Anordnung verbieten, bestimmte Daten aus dem Firmengebäude mit nach Hause zu nehmen. Einige mögen sich auch daran halten. . . Daß sich möglichst viele daran halten ist nur zu erreichen, indem die Anordnung auch kontrolliert wird. Der Firewall ist hier der Pförter bzw. die Radarfalle. Er kann verhindern, daß Daten über das Netzwerk (E-Mail, FTP oder ähnliches) nach draußen gelangen. Er kann natürlich nur solche Sicherheitsbestimmungen durchsetzen, die sich auf den Einsatzbereich eines Firewalls, das Netzwerk, beziehen. ❏ Protokollierung: Ein Firewall protokolliert auch den laufenden Datenverkehr.
So lassen sich später Vorgänge nachvollziehen und beurteilen. Bei einem Einbruch in einem Wohnhaus hilft die Spurensicherung bei der Beurteilung. Ist tatsächlich eingebrochen worden oder wurde es nur erfolglos versucht? Es folgt eine Bestandsaufnahme, ob evtl. etwas fehlt. Mit Daten ist das wesentlich schwieriger. Ob Daten gelöscht wurden, ist schon weitaus schwieriger auszumachen, ob ggf. Daten kopiert wurden, kann ohne Spurensicherung am Firewall überhaupt nicht beurteilt werden. Vielleicht wurden auch Datenbestände manipuliert. Aussagekräftige Proto-
6
2.3 . . . und was ein Firewall nicht kann
kolle helfen sehr bei der Frage, nach welchen Schäden man eigentlich suchen soll.
2.3 . . . und was ein Firewall nicht kann Ein Firewall erfüllt nicht all Ihre Sicherheitsanforderungen, er ist nur ein Baustein dazu. Ein Firewall hat auch Grenzen: ❏ Ein Firewall schützt nur Verbindungen, die über ihn laufen: Am Beispiel der
Pforte ist das leicht zu verstehen. Wenn Ihr Hochsicherheitstrakt noch einen Hintereingang hat, ist die Zugangssicherheit nur so hoch, wie die schwächere der beiden Pforten. Es nützt Ihnen gar nichts, den Haupteingang immer sicherer zu machen, wenn Sie nicht in gleichem Maße den Hintereingang sichern. Es muß auch nicht immer eine Türe sein: ein Fenster ist ebenfalls ein Sicherheitsrisiko. Mit anderen Worten: Der beste Firewall schützt Sie nur auf dem vorgegebenen Weg vor Datenmißbrauch. Wenn Sie aber gleichzeitig zulassen, daß Mitarbeiter unkontrolliert Modems benutzen dürfen, Disketten oder andere Datenträger mit nach Hause nehmen können, hilft Ihnen der Firewall an dieser Stelle nicht weiter. Sie müssen zusätzliche Maßnahmen ergreifen. ❏ Angriffe von innen: Ein Firewall wird ja nur implementiert, wenn ein ge-
wisser Datenverkehr zugelassen werden soll, in der Regel von innen nach außen. Das bedeutet, daß es sogenannte erlaubte Verbindungen gibt. Wenn sich nun jemand diese erlaubten Kanäle zunutze macht, kann der Firewall umgangen werden. Gerade die steigende Sicherheit von Firewalls führt zu neuen Angriffsszenarien: trojanische Pferde setzen sich im internen Netzwerk fest und nutzen die geringe Restdurchlässigkeit eines Firewalls, um ihn zu umgehen. Sie müssen zusätzlich zum Firewall Maßnahmen ergreifen, die solche Attacken vermeiden, erkennen und abstellen helfen. ❏ Untreue Mitarbeiter: Ein Firewall schützt nicht allein vor Mitarbeitern, die be-
wußt versuchen, Kontrollmechanismen zu umgehen. Erlaubte Verbindungen können mit einigem Aufwand auch zum Datenexport mißbraucht werden. Wenn eine Verbindung prinzipiell erlaubt ist, kann ein Firewall bestenfalls protokollieren. Sie brauchen andere Mechanismen (z. B. eine Dienstanweisung, Zugangsbeschränkungen intern), die zusammen mit den Protokollen zu einem wirksamen Schutz führen (Androhung von Sanktionen). ❏ Hacker im eigenen Netzwerk: Der Firewall trennt den internen vom öffentli-
chen Bereich ab. Sitzt der Angreifer bereits im internen Netzwerk (ein Mitarbeiter etwa), schützt er Sie nicht vor Angriffen auf im Netzwerk erreichbare Rechner. Sie benötigen zusätzlich zum Firewall weitere Mechanismen, die Angriffe transparent machen können (und Anordnungen wie etwa Dienst-
7
2 Wozu braucht man Firewalls?
anweisungen, die es Ihnen erlauben, aus festgestellten Attacken auch Konsequenzen ziehen zu können). Und Sie kommen trotz des Firewalls nicht umhin, gefährdete Rechner zusätzlich zu härten (d. h., Rechner gegen Attacken unempfindlicher zu machen). Möglicherweise kommen Sie auch zu dem Schluß, daß Sie Ihr internes Netzwerk in verschiedene Bereiche aufteilen, die zusätzlich durch Firewalls voneinander getrennt werden.
2.4 Grundwerte der IT-Sicherheit Wenn Sie an einer gesichterten Pforte um Einlaß bitten, werden Sie automatisch nach verschiedenen Kriterien überprüft. Zunächst hat jemand entschieden, daß es schützenswerte Güter im Unternehmen gibt. Im Gegensatz zu öffentlichen Bereichen, zu denen jedermann ungehindert Zutritt hat, gibt es hier eine Grenze. Die Frage lautet: Was, warum und wovor soll etwas geschützt werden? Defniert werden zu schützende Werte; diese heißen im Bereich der IT-Sicherheit: Vertraulichkeit, Verfügbarkeit und Integrität. Die Entscheidung, etwas schützen zu wollen, ist bereits Teil einer Sicherheitspolitik. Sicherheitspolitik umfaßt das gesamte Spektrum von der Entscheidung, etwas zu schützen, bis zur einzelnen Anweisung, wie das geschehen soll. Das Thema Sicherheitspolitik ist Gegenstand des Kapitels 3.
2.4.1
Vertraulichkeit
Vertraulichkeit ist wohl der Begriff, an den man beim Stichwort IT-Sicherheit am ehesten denkt. Vertraulichkeit bedeutet, daß Daten nicht in unbefugte Hände geraten dürfen. Beispiele für vertrauliche Daten: ❏ Personenbezogene Daten: Schutz dieser Daten wird unter dem Stichwort „Da-
tenschutz“ zusammengefaßt. Eine Verletzung des Datenschutzgeheimnisses kann ganz unterschiedliche Auswirkungen haben: Verlust des Ansehens einer Person, wirtschaftliche Schäden, weil z. B. jemand aufgrund von bekanntgewordenen medizinischen Daten nirgends mehr eingestellt wird etc. Allen gemeinsam ist, daß der Verlust der Vertraulichkeit personenbezogener Daten fast immer der Person schadet, zu der diese Daten gehören. Der allgemein gebrauchte Begriff „Datenschutz“ in seiner gesetzlich geregelten Form zielt immer auf den Schutz von personenbezogenen Daten ab. ❏ Betriebsgeheimnisse: Betriebliche Geheimnisse können für eine Firma einen
erheblichen Wert darstellen. Erfindungen sichern mitunter einen Technologievorsprung von mehreren Jahren, manchmal hängt das Überleben eines Unternehmens davon ab. Aber auch einfachere Interna, wie zum Beispiel
8
2.4 Grundwerte der IT-Sicherheit
die Angebotslage für ein Großprojekt, können das Geschäftsergebnis erheblich beeinflussen. Ein in falsche Hände geratenes Angebotsfax ermöglicht es der Konkurrenz, durch Unterbieten zum Zuge zu kommen. ❏ Zugangsmechanismen: Informationen über Sicherheitsstrukturen (über den
Firewall etwa) oder gar User-Kennungen und Passwörter erleichtern einen Angriff von außen erheblich oder ermöglichen ihn sogar erst.
2.4.2
Verfügbarkeit
Wie verfügbar sind Ihre Systeme und Ihre Daten? Verfügbar sind Daten und Dienste dann, wenn Sie innerhalb einer zuvor festgelegten Zeitspanne (zum Beispiel Bürozeit, 5x8 h, 7x24 h etc.) im Bedarfsfalle ohne Einschränkung ordnungsgemäß erreichbar sind. Einige Beispiele für Verfügbarkeiten bzw. Einschränkungen: ❏ Plattformverfügbarkeit: Vielleicht kennen Sie den Begriff „High Availabili-
ty“ und das Gefecht unter Anbietern um die höchste Verfügbarkeit: 99 %, 99,5 %, 99,99 % usw. Diese Zahlen beziehen sich meist auf streng vorgegebene Hardwarekonfigurationen und bezeichnen das Verhältnis der Verfügbarkeit in Bezug zu ungeplanten Ausfallzeiten. ❏ Netzwerkverfügbarkeit: Der Server steht im Nachbargebäude, draußen im Hof
beschädigt ein Bagger bei Erdarbeiten das Glasfaserkabel. Mangels BackupLeitung über einen anderen Weg oder redundanter Systeme stehen die Daten am Arbeitsplatz nicht zur Verfügung. ❏ Höhere Gewalt: Im Rechnerraum bricht ein Brand aus oder ein in der Decke
verlaufendes Wasserrohr wird undicht. Die komplette Hardware muß ersetzt werden. Möglicherweise stehen Daten für mehrere Tage oder Wochen nicht zur Verfügung. ❏ Sabotage: Verschiedene bekannte Angriffsmechanismen über das Internet
versuchen erst gar nicht, in ein System einzudringen, sondern es einfach außer Gefecht zu setzen. Diese Angriffsart nennt man auch „Denial of Service“. Dies können direkte Angriffe sein, aber z. B. auch ein Trojanisches Pferd. Vor einiger Zeit legte ein solches die komplette Infrastruktur eines amerikanischen Providers für mehr als 18 Stunden lahm. Kundenproteste und Schadensersatzforderungen waren die Folge.
2.4.3
Integrität
Als Frage formuliert: Sind Ihre Daten und Ihre Systeme noch das, was sie vorgeben zu sein? Sind sie korrekt, unverändert?
9
2 Wozu braucht man Firewalls?
❏ Systemintegrität: Ein Eindringling in ein Rechnersystem erlangt über eine Si-
cherheitslücke Administratorrechte und legt sich selbst einen Account an, mit dem er selbst nach Schließen der Sicherheitslücke weiterhin Zugang zum System hat. Protokolldateien, die Spuren des Angriffs aufgezeichnet haben, werden manipuliert (d. h. die Spuren des Angriffs verwischt). ❏ Datenintegrität: Ein Virus macht sich im System breit und ersetzt z. B. einen
bestimmten String durch einen anderen (zum Beispiel „Kreditor“ durch „Debitor“). Solange Sie den Virus nicht kennen, wissen Sie auch nicht, welchen Schaden er anrichtet. Makroviren für Office-Applikationen lassen sich mit wenig Aufwand von weniger wohl gesinnten Zeitgenossen sehr einfach in Viren umbauen, die zum Beispiel in einer Tabellenkalkulation willkürlich und zufällig einzelne Feldinhalte ändern.
2.5 Zusammenfassung Ein Firewall ist ein Element in einem umfassenden Sicherheitskonzept zwischen öffentlichem und nicht-öffentlichen Bereich eines Netzwerks. Er hat die Aufgabe der Zugangskontrolle und Zugangsprotokollierung. Er kann (muß aber nicht) aus Hard- und Software bestehen. Er ist zwar ein wichtiger Baustein innerhalb dieses Konzepts, muß aber durch weitere Maßnahmen im Rahmen einer Sicherheitspolitik ergänzt werden.
10
Kapitel 3 Security Policy Der Begriff „Sicherheit“ umfaßt auch den Aspekt „Schutz“. Man möchte sich vor etwas schützen, vor einer konkreten Bedrohung oder vor etwas Unbekanntem. Wer an seiner Wohnungstüre ein einfaches Sicherheitsschloß gegen ein aufbohrsicheres High-Tech-Schloß austauscht und zusätzlich Riegel und Ketten anbringt, hat für sich entschieden, daß die bisherigen Sicherungen ungenügend waren. Er hat – im Privatbereich sehr viel öfter unbewußt denn bewußt – ein Gefährdungspotential ausgemacht, den momentanen Sicherheitsstand beurteilt und festgelegt, daß dieser nicht ausreicht, um dann Maßnahmen zu ergreifen, die die Diskrepanz zwischen Schutzbedarf und vorhandener Sicherheit beseitigen. Ausgehend von einem Sicherheitsbedürfnis („überdurchschnittlich“), wird eine Sicherheitspolitik festgelegt („die Haustüre muß Gelegenheitseinbrecher am Eindringen gänzlich hindern; die Türe muß sich zur Entgegennahme kleiner Gegenstände öffnen lassen, ohne gleich Zutritt zur Wohnung zu gewähren“), die in ein Sicherheitskonzept mündet („Austausch der Haustüre, des Schlosses etc.“). Und genau dies tut auch eine IT-Sicherheitspolitik . Einige Begriffe seien zunächst erläutert: Die Sicherheitspolitik ist – vereinfacht gesagt – das, was das Management verabschiedet. Auf Managementebene spielt es keine Rolle, welche technischen Feinheiten zum Tragen kommen. Dort geht es um grundsätzliche Entscheidungen wie zum Beispiel, ob E-Mail in das Internet beliebig versendet werden darf oder nur eingeschränkt (keine privaten E-Mails, keine Attachments etc.), ob der Zugang zum World Wide Web freizügig gehandhabt wird oder ob Einschränkungen nach bestimmten Kriterien vorzunehmen sind („dienstliche Nutzung“, Ausschluß von Sex, Crime, Rassismus etc.). Das Sicherheitskonzept enthält dann die Ausführungsbestimmungen, technische Einzelheiten, aber auch Verantwortlichkeiten, Notfallpläne, Schulungsmaßnahmen etc., alles, was zur konkreten Umsetzung notwendig ist.
11
3 Security Policy
Der Begriff Security Policy wird hier als Oberbegriff verstanden, der Sicherheitspolitik und Sicherheitskonzept umfaßt. Während die Sicherheitspolitik noch einfach und überschaubar bleibt, unterliegt das Sicherheitskonzept selbst einem ständigen Entwicklungsprozeß. Wenn sich im laufenden Betrieb herausstellt, daß die getroffenen Maßnahmen nicht zu dem Ziel führen, das die Sicherheitspolitik festgeschrieben hat, müssen Anpassungen vorgenommen werden. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) spricht hier auch von einem ständigen Sicherheitsprozeß ([BSI99]).
3.1 Security Policy und Firewalls Unter den Begriff IT-Sicherheit wird alles zusammengefaßt, was auch nur entfernt mit diesem Thema zu tun hat. Soweit will diese Darstellung nicht gehen. In diesem Buch geht es um Firewalls. Firewalls sind Bestandteil einer Security Policy, sie bilden gewissermaßen die Haustüre ab. Daß es daneben aber auch noch andere Möglichkeiten gibt, in das Haus einzudringen und wieder hinaus zu gelangen, muß hier außer Acht gelassen werden. In diesem Buch beschränkt sich das Thema Security Policy auf den Bereich der Sicherheit, der mit der Netzwerkanbindung an unsichere Netze (wie zum Beispiel das Internet) zu tun hat. Die anderen möglichen Sicherheitslücken sind natürlich ebenfalls zu berücksichtigen. Eine sehr gute Informationsquelle und praxisorientierte Anleitung für das gesamte Thema IT-Sicherheit ist das IT-Grundschutzhandbuch des BSI ([BSI99]). Auch die Homepage des BSI bietet eine Fülle sicherheitsrelevanter Informationen: http://www.bsi.de/ Dort finden sich auch Studien zum Thema Internetsicherheit, Intrusion Detection und vieles mehr. Die Erstellung und Umsetzung einer Security Policy ist ein sehr schwieriges Geschäft. Zum einen fließen die gegebenen Rahmenbedingungen mit ein, dann ist die Festlegung der Ziele – wie der Begriff „Sicherheitspolitik“ bereits verrät – eine politische Entscheidung. Es kann daher kein allgemein gültiges Sicherheitskonzept geben. Was man aber aufzeigen kann, sind Elemente, die in einer Security Policy enthalten sein sollten. Dazu hilft die Darstellung aktueller Gefährdungspotentiale. Manche Probleme sind so bizarr, daß man sie ohne Kenntnis entsprechender Attacken auch nicht im Sicherheitskonzept berücksichtigen kann.
3.2 Gefährdungpotentiale Gefährdungspotentiale kann man klassifizieren nach den genannten Grundwerten der IT-Sicherheit: Verfügbarkeit, Vertraulichkeit, Integrität. Eine Reihe von Ge-
12
3.2 Gefährdungpotentiale
fährdungen bezieht sich meist auf mehr als nur einen Grundwert. Daher eine etwas differenziertere Einteilung: „externe, aktive Angriffe“, „interne, aktive Angriffe“ und „autonome Einheiten“. Mit „aktiv“ ist hier ein vorsätzlicher, kontrolliert durchgeführter Angriff gemeint, in Abgrenzung zu autonomen Angriffen, die vom Urheber nicht mehr kontrollierbar sind und sich selbständig machen.
3.2.1
Externe, aktive Angriffe
Hier sind alle Gefährdungspotentiale gemeint, die durch aktives (vorsätzliches) Handeln einer Person verursacht werden und deren Ursprung außerhalb des eigenen Netzwerkes liegt. ❏ Fälschung von Information: Durch Manipulationen von Webseiten wird der
Ruf des Betreibers der Website geschädigt. Nutzer der Website werden falsch unterrichtet. Links werden manipuliert, um Surfer auf eine falsche Seite zu locken, die ein Skript ausführt, das wiederum Daten vom lokalen Rechner herunter lädt. Fälschung von Daten in Datenbanken führt zu unerwünschtem Verhalten: Lieferungen erfolgen an die falsche Adresse, Überweisungen landen auf falschen Konten etc. Änderung von DNS-Daten auf DNS-Servern führt eine große Zahl von Internet-Nutzern zu falschen Systemen, ein Teil des Internet ist dadurch für einige Zeit nicht erreichbar. ❏ Diebstahl von Daten: Das bekannteste und zugleich eines der größten Ärger-
nisse ist der Diebstahl von Kreditkartendaten. Die Daten werden entweder vom Cracker direkt mißbraucht, oder die Daten werden gegen teures Geld weiterverkauft. Kundendaten sogenannter Accounting-Server erlauben es der Konkurrenz, gezielt den vorhandenen Kundenkreis anzugehen und Kunden abzuwerben. Bei fragwürdigen Angeboten können Kundendaten auch zur Erpressung des betroffenen Kunden mißbraucht werden. Daten werden über Sicherheitslücken von Browsern vom lokalen PC abgezogen. Zugangsdaten zum Beispiel für Internet-Zugänge oder OnlineBanking werden mißbraucht. ❏ Denial of Service: Gezielte Angriffe auf die Sicherheitslücken eines Server-
Dienstes können diesen zum Absturz bringen. Auch normale Abfragen eines Serverdienstes können mit einer künstlich hohen Abfragerate den Dienst außer Kraft setzen, insbesondere dann, wenn die Antwort sehr viel Rechenzeit in Anspruch nimmt. Attacken auf Lücken im Betriebssystem können einen ganzen Host blockieren oder gar zum Absturz bringen. Ein Beispiel für das Blockieren eines Host ist SYN Flooding, bei dem so viele halb offene Verbindungen erzeugt
13
3 Security Policy
werden, bis die Tabelle für die Annahme von Verbindungen überläuft und keine weiteren Verbindungen mehr zuläßt. Auch die Netzwerkverbindung kann angegriffen werden. Werden Routingtabellen manipuliert, erreichen Netzwerkpakete ihr Ziel nicht mehr. Bestehende Netzwerkverbindungen können mit Nachrichten für einen Verbindungsabbruch unter bestimmten Umständen „abgeschossen“ werden. ❏ Überflutung mit überflüssiger Information: Bestimmte Angriffe zielen darauf
ab, daß sich der Angegriffene und ein Dritter mit sinnlosen Netzwerkpaketen zuschütten. Smurf ist eine solche Angriffsvariante, die einen PingBroadcast-Sturm erzeugt. Allerdings ist der Absender dabei gespooft, das heißt, ein dritter, Unbeteiligter wird mit dem Broadcaststurm bombardiert. Sowohl beim Angegriffenen als auch bei dem Dritten kann das Netzwerk überlastet werden. Ebenfalls für den Betroffenen sehr unangenehm sind Szenarien, in denen ein Betroffener oder auch eine Mailingliste als Mitglied in vielen hundert anderen Mailinglisten eingetragen wird. Das Postfach des Betroffenen ist dann in der Regel nicht mehr nutzbar. Auch denkbar ist eine Mailüberflutung durch Werbemails. Bei manchen Providern ist der Platz für das Postfach nach wie vor beschränkt. Ist das Postfach voll, werden weitere Mails in der Regel verworfen (der Absender bekommt zwar eine Nachricht, für den Empfänger ist die Mail zunächst aber einmal verloren). ❏ Distributed Denial of Service (DDoS): Verteilte DoS-Angriffe basieren in der
Regel auf dem Zuschütten mit sinnlosen Netzwerkpaketen (auch die an sich sinnvolle Abfrage einer Website kann als sinnlos angesehen werden, wenn sie in extrem kurzen Intervallen durchgeführt wird, mit dem Ziel, den Server zu überlasten). Auf die Überflutung mit sinnlosen Paketen wurde bereits eingegangen. Aber solche verteilte Angriffe benötigen auch eine Vielzahl von Rechnern, die gemeinsam diesen Angriff durchführen. Die Installation eines entsprechenden Daemon für solche DDoS-Angriffe ist ebenfalls ein aktiver Angriff. ❏ Rootkits: Mit dem Einbruch in einen Rechner und der Installation von Server-
Diensten, etwa für DDoS, geht in der Regel auch die Installation von Rootkits einher. Rootkits sind Programme, die normale Systemprogramme wie netstat, ps, ls, inetd usw. ersetzen, um sich selbst oder andere Programme oder Directories, die ein Hacker benutzt, vor der Entdeckung zu schützen. Einige Programme wie inetd enthalten dann eine Backdoor, eine Hintertüre, die es dem Angreifer jederzeit ermöglicht, zurückzukommen und den Rechner für eigene Zwecke zu mißbrauchen. Die Gefahr liegt vor allem darin, daß der Rechner für weitere Angriffe benutzt wird. Für den Angegriffenen sieht es dann so aus, als käme der Angriff vom kompromittierten Host. Der eigentliche Angreifer verwischt so
14
3.2 Gefährdungpotentiale
nicht nur seine Spur, sondern bringt auch den Betreiber des kompromittierten Host in Mißkredit.
3.2.2
Interne, aktive Angriffe
Externe Angriffe sind meist sehr spektakulär, wenn sie denn bekannt werden. Interne Angriffe dagegen verlaufen lautloser, nicht nur, weil man sie oft unter Verschluß hält, wenn sie denn überhaupt entdeckt werden. Man sollte interne Angriffe nicht unterschätzen. Einerseits steht dem Angreifer die ganze Palette an Tools und Exploits zur Verfügung, andererseits sind die Sicherheitsvorkehrungen im lokalen Netz selten so streng wie im Firewallbereich, nicht zuletzt deshalb, weil man auch intern Dienste einsetzt oder einsetzen muß, die für den Firewallbereich erst gar nicht in Frage kommen (Portmapper, NFS, NIS, X Window System etc.). Ein interner Angreifer verfügt zudem über mehr oder weniger gute „Ortskenntnisse“, die ein gezieltes Suchen nach Betriebsgeheimnissen oder ein Stören des Betriebes einfach machen. Während ein externer Angreifer im Trüben herumstochert und manchmal mit Brute-Force Suchmethoden so herumpoltert wie ein Elefant im Porzellanladen (so daß er auffallen muß), fällt der interne Angreifer selten auf. Zu den Szenarien des externen Angriffs kommen weitere hinzu. ❏ Ausspähen von Daten: In internen Netzwerken werden wichtige Informatio-
nen immer noch selten verschlüsselt übertragen. Für einen Sniffer ist es in der Regel ein leichtes, Passwörter oder andere wichtige Informationen mitzuschneiden, um diese dann später mißbräuchlich zu verwenden. Passwörter sind in internen Netzwerken oft der einzige Schutz vor unbefugtem Zugriff. Wie schwer es ist, eine Person auszumachen, die sich ordnungsgemäß eingeloggt hat und die das Passwort aber eigentlich nicht besitzen darf, kann man sich leicht ausmalen. Beim Ausspähen von Daten im Netzwerk spielt immer die Möglichkeit des Netzwerkzugangs eine Rolle. Selbst völlig abgesicherte Workstations nützen wenig, wenn anderweitig ein Zugang zum Netzwerk hergestellt werden kann, etwa durch nicht belegte, aber im Netzwerk eingebundene Netzwerkdosen oder frei zugängliche Netzwerkschränke. ❏ Diebstahl von Daten und Verbindungen: Nicht immer spielt der Passwortbe-
sitz beim Diebstahl von Daten eine Rolle. Manchmal sind es auch Sicherheitslücken im Betriebssystem oder Eigenheiten in den Zugangsmechanismen, die den Zugang zu Daten einfach machen. Unter Windows (95, 98) existiert zum Beispiel eine Sicherheitslücke, die – wenn der entsprechende Patch nicht eingespielt ist – für den Zugang zu Laufwerksfreigaben auf Share-Ebene, die nur einen Buchstaben lang sind, auch nur den ersten Buch-
15
3 Security Policy
staben des Passwortes prüft. Ein entsprechender Exploit hat dann ein sehr leichtes Spiel. Aber auch mit anderen Betriebssystemen muß man auf der Hut sein: Verbindungen wie z. B. Telnet, die sich zur Identifikation des Host ausschließlich auf IP-Adressen verlassen, sind leicht zu entführen. Für die „feindliche Übernahme“ einer Telnet-Session gibt es fertige Programme. Nicht auszumalen, wenn trotz aller Sicherheitsmaßnahmen eine Telnet-Session eines eingeloggten Admins entführt wird, der sich vor seinem Urlaub nicht ausgeloggt hat (kommt immer wieder vor!). ❏ Veränderung von Zugriffsrechten: Ein interner Angreifer muß nicht unbedingt
Backdoors, Rootkits oder anderes Getier installieren, um sich den Zugang zum System für die Zukunft offen zu halten. Meist besteht ja ein Zugang, nur eben nicht mit den gewünschten Zugriffsrechten. Der Eintrag in eine zusätzliche Gruppe, die Lese- oder Schreibberechtigung dort zu verändern, wo sie vorher nicht existierte, genügt oft schon und ist sehr viel unauffälliger als ein direkter Angriffsversuch. ❏ Fälschen von Protokollen: Zugriffe werden auch im internen Netzwerk proto-
kolliert, oft geht es gar nicht nur darum, unbefugten Zugriff festzustellen, sondern auch, wer wann wo Zugriff hatte. Solche Informationen wieder zu löschen kann ebenfalls die Absicht eines internen Angreifers sein, der nur normalen Zugang zu den Daten hatte. Etwa dann, wenn Daten verändert wurden und niemand wissen soll, wer es war. ❏ Versehentliches Löschen: Auch wenn dies weder vorsätzlich geschieht noch
als „Angriff“ zu werten ist: der überaus größte Teil von Datenverlusten durch interne Anwender ist nicht beabsichtigtes, aber befugtes Löschen von Daten. Trotz aller Angriffsszenarien darf man diesen Tatbestand nicht aus den Augen lassen und muß ihn beim Sicherheitskonzept entsprechend berücksichtigen.
3.2.3
Autonome Einheiten
Angriffe durch autonome Einheiten nehmen im Internet immer mehr zu. Autonome Einheiten sind Programme, die sich mit oder ohne User-Interaktion selbständig und in der Regel unkontrolliert verbreiten. Fast nie hat der Urheber der autonomen Einheit Einfluß auf den Gesamtschaden, den eine solche anrichtet. ❏ Viren: Viren befallen ausführbaren Code, um sich bei dessen Ausführung
selbst fortzupflanzen. Nicht immer ist der ausführbare Code ein Binary; Skriptsprachen und makrofähige Applikationsformate tun ihr Übriges (nicht nur Textverarbeitungs- oder Tabellenkalkulationsprogramme sind davon betroffen, auch andere Dateiformate können ausführbare Makros enthalten, zum Beispiel Postscript).
16
3.2 Gefährdungpotentiale
Hinzu kommen noch Besonderheiten von Architekturen: beim PC wird der Bootsektor als ausführbarer Code behandelt. Bis E-Mail auf jedem Desktop Einzug hielt und Makroviren die „Alten“ zurückdrängten, war die Verbreitung über Bootsektoren einer Diskette die häufigste Infektionsart. Ob ein Virus gutartig (nur sich selbst verbreitet) oder bösartig ist, hängt allein vom Urheber ab. Manche Viren sind zwar wenig zerstörerisch, aber hochinfektiös, so daß eine vollständige Entfernung viele Stunden Arbeit und jede Menge Nerven kostet. Wie ein biologischer Virus kann ein Computervirus nicht selbständig existieren, sondern braucht für die Ausführung immer ein Wirtsprogramm. ❏ Würmer: Vor den ersten Viren schlug der Internet-Wurm zu (02. November
1998), ein Programm, das Sicherheitslücken in Berkeley Unix-Systemen ausnutzte (sendmail, fingerd). Der Wurm hat sich über das Netzwerk verteilt und auf den Rechnern selbst repliziert, bis der Host durch die Unzahl an laufenden Wurm-Prozessen in die Knie ging. Eine ausführliche Information zum Internet-Wurm, auch Morris-Wurm genannt, findet sich in RFC 1135. Ein Wurm ist im Unterschied zu einem Virus ein eigenständiges Programm, das ohne Wirt lauffähig ist und sich völlig selbständig verbreitet. ❏ Trojaner: Wie das hölzerne Pferd aus der griechischen Sage geben sogenann-
te „Trojaner“ vor, etwas zu sein, was sie nicht sind. Der Anwender führt ein Programm aus, welches augenscheinlich auch das tut, was es soll. Das vielleicht heimlich beim Start eines Spielprogramms aus eventuell unsauberer Quelle zusätzlich ein weiteres Programm mitgestartet wird, von dem der Anwender aber nichts mitbekommt, etwa eine Backdoor wie BackOrifice, macht den Trojaner aus. Leider gibt es Bausätze, mit denen man fast jedes Programm in einen Trojaner verwandeln kann. Für Windows-Executables gibt es fertige Toolkits, aber auch unter Unix kann bereits das eigentliche Programm vor dem Download durch eine entsprechende trojanische Version ausgetauscht worden sein. Werden vom Distributor Checksummen oder andere Verifizierungsmöglichkeiten angeboten, sollte man bei Downloads aus dem Internet unbedingt Gebrauch davon machen. ❏ E-Mail-Viechereien: Autonome Einheiten nehmen immer ausgefallenere For-
men an, und die Grenzen zwischen den drei oben genannten Kategorien verschwinden langsam. Sehr häufige Formen sind E-Mail-Würmer, die sich virenartig verhalten oder auch gleich einen eingebauten Trojaner mitliefern. Der MIME-Standard macht es bei E-Mails möglich, nahezu jedes Dateiformat weiter zu verarbeiten oder auszuführen. Sehr oft spielt die Benutzeraktion noch eine wichtige Rolle, d. h., ein Attachment muß erst mit der zugehörigen Anwendung geöffnet werden, bevor ein Wurm sich entfalten kann. Zu einer traurigen Berühmtheit ist hier Outlook von Microsoft gelangt. Sehr viele E-Mail-Scripting-Würmer benutzen dessen Adreßbuch, um sich selbst
17
3 Security Policy
an alle weiteren Kontakte im Adreßbuch zu versenden. Das Traurige daran: Man bekommt den Wurm von Bekannten, die den Empfänger deswegen auch im Adreßbuch haben. Damit ein E-Mail-Wurm solch eine zerstörerische Wirkung entfalten kann wie „Melissa“ und der „Loveletter“-Virus, sind drei Dinge nötig: ein sehr weit verbreiteter E-Mail-Client, ein automatisch auslesbares Adreßbuch und unbedarfte Anwender, die ohne Nachdenken jedes x-beliebige Attachment öffnen. Punkt eins und drei werden bei der oft hitzig geführten Debatte über das für und wieder bestimmter E-Mail-Clients gerne übersehen, denn dafür ist nämlich der Anwender selbst verantwortlich (für Punkt zwei gibt es für Microsofts Outlook inzwischen Patches). Inzwischen gibt es auch ein Angriffsszenario über den freien E-Mail-Client PegasusMail. Manche E-Mail-Würmer kann man als Administrator nur als nervtötend bezeichnen. Wenn auf einem befallenen Windows-System jede, aber auch wirklich jede DLL befallen wird oder Dateien von allen erreichbaren Laufwerken brutal gelöscht werden, dann kann das viele Stunden Arbeit und jede Menge Nerven kosten. ❏ Netzwerk-Würmer: Würmer, deren Haupttransport-Medium das Netzwerk
ist, sind nicht ganz so verbreitet wie E-Mail-Würmer, aber ebenfalls auf dem Vormarsch. Unter Ausnutzung von Sicherheitslücken nisten sich diese im System ein und versuchen ihrerseits, andere Rechner zu finden, die dieselbe Sicherheitslücke aufweisen, um diese ebenfalls zu infizieren. Einige verbreitete Netzwerk-Würmer nutzen primitive Sicherheitslücken auf Fileebene, etwa ein unter Windows 95 auf Share-Ebene ohne Passwort freigegebenes Laufwerk. Nichts und niemand hindert aber Black-Hats daran (die Hacker mit bösen Absichten, im Gegensatz zu White-Hats, Hacker, die nur gute Absichten haben), bekannte Exploits für gebräuchliche Unix-Programme (rpc.statd, bind, sendmail, wuftpd etc.) mit Würmern zu kombinieren. So ein Wurm mit einem Exploit gegen ein so weit verbreitetes Programm wie bind könnte innerhalb von Tagen eine verheerende Wirkung erzielen. ❏ Krieg der Trojaner: Der Cyber-War ist nicht mehr fern, wenn sich Würmer
mit eingebautem Trojaner und Virus gegenseitig bekämpfen. Inzwischen gibt es einen Wurm, der wie sein Vorgänger ein Programm installiert, das unbenutzte Rechenzeit einem bestimmten Host zugänglich macht. Findet der Wurm seine Vorgängerversion, tauscht er die entsprechenden Konfigurationsfiles aus, damit die Rechenzeit nun einem anderen Internethost zur Verfügung steht.
18
3.3 Sicherheitspolitik
3.3 Sicherheitspolitik Politische Aussagen sind in erster Linie eine Absichtserklärung, also eine Aussage darüber, was man beabsichtigt zu tun. Mit der Sicherheitspolitik ist es wie in der richtigen Politik: Es ist gar nicht so einfach, das, was man beabsichtigt, auch so zu formulieren, daß es auch andere verstehen. Verstrickt man sich zu sehr in Details, fließen Elemente mit ein, mit denen sich eigentlich erst die Ausführungsbestimmungen befassen sollen (Sicherheitskonzept). Sind die Absichtserklärungen zu allgemein, läßt sich damit alles oder nichts sagen, es fehlt dann die Verbindlichkeit bei der Umsetzung. Man muß sich also bei der Formulierung der Sicherheitspolitik immer auch überlegen, ob die Formulierung nicht zu viel Interpretationsspielraum läßt. Das kann auch ein Regelprozeß sein, bei dem derjenige, der die Sicherheitspolitik formuliert, sich ansieht, was damit gemacht wird. Weicht die Umsetzung zu weit von der gedachten Richtung ab, kann eingegriffen werden. Allerdings sollte das in einer Reformulierung der Sicherheitspolitik münden. Man sollte unbedingt dabei vermeiden, daß technische Elemente der Umsetzung in die Formulierung der Sicherheitspolitik einfließen. Um dieses doch sehr abstrakte Thema anschaulicher zu machen, sollen nun einige Beispiele für Sicherheitsziele vorgestellt werden. Dabei wird von einem lokalen Netzwerk mit Anbindung an das Internet ausgegangen.
3.3.1
Sicherheitsziele
Begonnen werden soll mit einer noch unstrukturierten Liste von Grobzielen. Diese könnte folgendes umfassen: ❏ Unser Netzwerk soll sicher sein: Gleich zu Beginn ein Sicherheitsziel, das man
so nicht formulieren sollte. Zwar möchte jeder, daß das Netzwerk, für das er verantwortlich ist, auch sicher ist. Aber dieses Sicherheitsziel läßt fast beliebig freie Interpretationen zu. Was dabei herauskommt, hängt ganz von den Vorstellungen desjenigen ab, der das Sicherheitskonzept erstellt, nicht von demjenigen, der das Ziel formuliert. ❏ Alles, was nicht ausdrücklich verboten ist, ist erlaubt, bzw.
Alles, was nicht ausdrücklich erlaubt ist, ist verboten: Sogenannte „Default Policies“: Regeln, die sich auf all das beziehen, was nicht ausdrücklich geregelt ist. Man kann viele Regeln und Sicherheitsziele aufstellen, es wird aber immer Lücken geben, die von den aufgestellten Regeln nicht erfaßt werden. Im Grunde ist eine Default Policy zwar schon eine Ausführungsbestimmung, bleibt jedoch primär eine politische Entscheidung. Deshalb sollte diese Ent-
19
3 Security Policy
scheidung auch von demjenigen getroffen werden, der die Sicherheitsziele formuliert. Eine Default Policy kann auch zeitlich beschränkt sein (zum Beispiel bei neuen Situationen, bis eine endgültige Entscheidung gefallen ist) oder nur Teilbereiche umfassen (zum Beispiel zulässige Webseiten, siehe unten). Eine negative Default Policy bietet mehr Sicherheit und „verwöhnt“ die Anwender nicht zu sehr (es ist einfach, Anwendern etwas zu erlauben, was bislang verboten war, aber weitaus schwieriger, Anwendern etwas zu verbieten, was diesen bis dahin gestattet war). Für Teilbereiche hängt die Default Policy eher davon ab, wie das generelle Sicherheitsziel aussieht. Beschränkt das Sicherheitsziel einige wenige Aspekte mit expliziter Nennung, wird die Default Policy dazu eher offen sein (erst einmal erlauben). ❏ Bestmöglicher, zentraler Schutz der Anwender beim Surfen am Arbeitsplatz: Die-
ses Sicherheitsziel impliziert bereits, was der Anwender darf, nämlich das Web vom Arbeitsplatz aus nutzen. Damit ist der Anwender direkt den Gefahren ausgesetzt, die sich über eine erlaubte Verbindung für Webanwendungen ergeben. Es gibt viele Möglichkeiten, damit umzugehen, vom Personal Firewall für jeden Rechner über Virenscanner bis hin zu lokaler Konfiguration der Webbrowser auf jedem Rechner, mit dem Verbot von Java- und Scripting-Funktionalitäten. Das Sicherheitsziel fordert hier aber einen zentralen Schutz beim Surfen. Damit ist dann auch beabsichtigt, daß weniger jeder Arbeitsplatz abgesichert wird, sondern der Schutz an einer zentralen Stelle erfolgt. Filter und Proxies können Scripting- und Java-Elemente filtern, so daß nicht ständig neu auftauchende Sicherheitslücken an den Browsern gefixt werden müssen. „Bestmöglicher Schutz“ beinhaltet aber auch, daß der Schutz Vorrang hat vor den Funktionalitäten der Webseite. Benötigt eine Webseite unbedingt Scripting-Elemente, dann hat der Anwender hier im Zweifelsfalle eben keinen Nutzen (weil die gefilterte Webseite anschließend möglicherweise gar nicht mehr funktioniert). ❏ Schutz des eigenen Netzwerks nach dem Stand der Technik: Dieses Sicherheitsziel
bietet bewußt Interpretationsfreiheit, da es implizit eine regelmäßige Überprüfung des Sicherheitskonzeptes auch auf die Weiterentwicklung von Gefahren und technischen Möglichkeiten hin fordert. Die Bandbreite der möglichen Lösungen ist gar nicht so groß, wie es auf den ersten Blick scheinen mag. Wer fünf Experten befragt, erhält zwar fünf verschiedene Antworten. Abhängig von einer konkreten Aufgabenstellung werden aber alle fünf Antworten einen Satz gleicher Elemente enthalten. Und diese kann man dann als Mindestforderung verstehen. Bei sehr vertraulichen Daten kann man heute sagen, daß ein einfacher Paketfilter lange nicht mehr ausreicht. Und während früher ein Webserver rela-
20
3.3 Sicherheitspolitik
tiv unbeaufsichtigt betrieben wurde, zeigt sich in letzter Zeit zunehmend, daß ein Bugfix den anderen jagt und rasch reagiert werden muß, sei es auf technischer Ebene (Einsatz eines wesentlich weniger anfälligen Webservers) oder auf organisatorischer Ebene (Freistellung eines Administrators, der hauptamtlich für ein laufendes Bugfixing zuständig ist). Als Stand der Technik kann auch gelten, jeden Arbeitsplatz mit einem Virenscanner auszustatten und schon bei kleineren Firmennetzwerken ein Intrusion Detection System zu betreiben. Ein Firewall für die Internet-Anbindung ist ein Muß. Stand der Technik heißt ganz allgemein, daß für existierende Gefährdungspotentiale marktübliche Lösungen verfügbar sind und mit vertretbarem Aufwand implementiert werden können. Umgekehrt: Wenn ein Unternehmen durch eine bekannte Gefahr Schaden in Höhe von mehreren 100.000 DM davontragen kann, eine Abwehr aber für wenige 1.000 DM erhältlich ist bei geringem Aufwand für den Unterhalt, dann waren die Sicherheitsmaßnahmen nicht auf dem Stand der Technik. ❏ Erlaube dem Anwender nur Web und FTP-Verbindungen: Implizit heißt das:
alles andere ist verboten. Streng genommen ist das nicht unmittelbar ein Sicherheitsziel, sondern eine Default Policy. Es ist aber eine politische Entscheidung, keine direkte Ausführungsbestimmung. Man könnte auch anders sagen: „Aus Sicherheitsgründen sollen nur die unbedingt notwendigen Dienste genutzt werden können, alles andere ist zu untersagen. Die benötigen Dienste sind Web und FTP.“ Dieses Sicherheitsziel könnte auch zum Beispiel erweitert werden um: „Die FTP-Nutzung ist eingeschränkt auf Fälle, die ein ausdrückliches dienstliches Interesse nachweisen können“. ❏ Zugang zum Internet ausschließlich indirekt über einen zentralen Punkt: Hinter-
gedanke bei diesem Sicherheitsziel ist natürlich, daß man einen zentralen Punkt auch gut kontrollieren kann. Von großer Bedeutung ist das gerade dann, wenn neue, große Gefährdungsmöglichkeiten auftauchen und schnell reagiert werden muß. Ausschließlich indirekt bedeutet den Einsatz von Proxies. Ob applikationsspezifische oder generische Proxies (siehe Abschnitt 6), bleibt hier offen, das ist dann Sache des Sicherheitskonzeptes. Aber eine direkte Punkt-zu-Punkt-Verbindung etwa eines lokalen Webbrowsers auf einem Arbeitsplatz zu einem beliebigen Server im Internet ist so untersagt. ❏ Generell keine Verbindung zwischen Internet und lokalem Netzwerk: Der sicher-
ste Firewall ist nun einmal keine Verbindung zwischen internem Netzwerk und Internet. Es kann durchaus Situationen geben, wo dies aufgrund hoher Sicherheitsanforderungen erforderlich ist.
21
3 Security Policy
Man kann dann mit Standalone-PCs arbeiten, die zwar Zugang zum Internet haben, aber keine Verbindung zum internen Netzwerk. Statt vieler Standalone-PCs mit direktem Zugang (z. B. via ISDN) zum Internet kann man auch ein zweites Netzwerk implementieren, an das die SurfPCs angeschlossen sind und das unter anderem auch über einen einfachen Firewall abgesichert ist und eben keine Verbindung zum internen Netzwerk hat. Dabei wird man aber in der Regel kaum auf E-Mail vom Arbeitsplatz aus verzichten können. Abhilfe kann hier ein Mailtransport schaffen, der nicht über das Netzwerk läuft, etwa UUCP über eine Telefonleitung oder eine direkte serielle Verbindung. ❏ Verhinderung von Schäden durch autonome Einheiten: Würmer und Viren kön-
nen einen beträchtlichen Schaden anrichten, daher sollte auch die Sicherheitspolitik Ziele zu diesem Thema formulieren. Dieses Sicherheitsziel ist relativ offen und überläßt es den Technikern, geeignete Lösungen zu finden. Natürlich spielt auch hier wieder der Stand der Technik, also die Machbarkeit und Verfügbarkeit von Lösungsansätzen mit hinein. Es ist leicht einzusehen, daß ein Sicherheitskonzept gerade hier nicht nur aus technischen Ansätzen besteht, sondern auch organisatorische Maßnahmen enthalten muß. Es muß festgelegt werden, was zu tun ist, wenn der „Worst Case“ eintritt. Benutzer müssen über das Verhalten von Viren, Würmern und Trojanern aufgeklärt werden, insbesondere E-Mail-Würmer erfordern nach wie vor immer noch eine Benutzer-Interaktion, sind also ohne Mithilfe unbedarfter Benutzer immer noch unselbständig. ❏ Zentraler Schutz vor autonomen Einheiten: Zentraler Schutz ist ein sehr schwie-
riger Ansatz bei autonomen Einheiten, da diese ja nicht zentral „angreifen“, sondern beliebig jeden Arbeitsplatz. Zentral kontrolliert werden können Server und die Zugangswege. Bei E-Mail ist das einfach realisierbar, weil alle E-Mails immer über einen Mailserver laufen müssen, und ein- bzw. ausgehende E-Mails in der Regel denselben Weg nehmen (solange es keine Hintertüren gibt). Ein zentraler Mechanismus kann dort ansetzen. Intrusion Detection Systeme können im Netzwerk die Ausbreitung von Netzwerk-Würmern (auch von E-Mail-Würmern) erkennen und warnen. ❏ Verbiete alle anstößigen, sittenwidrigen oder gar kriminellen Webinhalte: Im be-
ruflichen Alltag sind Webinhalte bestimmter Kategorien unerwünscht (Sex, Crime, Rassimus etc.). Manche Inhalte erfüllen sogar Straftatbestände (etwa Kinderpornographie). Jeder, der Zugang zum Internet ermöglicht, tut gut daran, hier Vorkehrungen zu treffen. Diese können, müssen aber nicht technischer Natur sein. Ein Verbot kann auch etwa im Rahmen eines Arbeitsvertrages über Zusatzerklärungen ausgesprochen werden. In der Regel sollten aber auch technisch mögliche Vorkehrungen getroffen werden.
22
3.3 Sicherheitspolitik
❏ Erlaube nur Webinhalte mit dienstlichen Aspekten: Gegenüber dem Verbot eini-
ger Inhalte, für die es dazu noch fertige Werkzeuge gibt, ist diese Forderung kaum zu erfüllen. Man muß sich vor Augen halten, was das im Endeffekt bedeutet: eine Liste zu pflegen, die täglich, stündlich und manchmal auch minütlich zu überprüfen ist. ❏ Schütze interne Anwender vor Werbe-E-Mails und E-Mails mit schädlichem Inhalt:
Eine vernünftige Mailserverkonfiguration schützt bereits vor vielem Werbemüll (SPAM, siehe Abschnitt 7.1.1). Darüber hinaus kann man auch gezielt gegen Werbemails vorgehen. E-Mails mit schädlichem Inhalt abzuwehren führt unter Umständen wieder zu einem Interessenkonflikt. Virenscanner im Maildatenstrom erfassen oft nur bekannte Dinge. Unbekannte Gefahren lassen sich abwehren, indem man Attachments mit bestimmten Endungen und HTML-Mails mit bestimmten Schlüsselwörter erst gar nicht zuläßt. Wird aber zum Beispiel eine .exe-Datei (Windows) nicht durchgelassen, heißt das für die beteiligten Partner, sich abzusprechen und die Datei umzubenennen. Mancher Anwender kann auf solch eine Maßnahme verärgert reagieren. Es bleibt daher auch eine politische Entscheidung, wieviel Umstand dem Anwender zuzumuten ist, wenn technische Maßnahmen die bisher gewohnte Arbeit einschränken. ❏ Erlaube private E-Mails in geringem Umfang: In vielen Unternehmen ist der
Versand privater E-Mails gestattet, manchmal mit Einschränkungen wie „darf den betrieblichen Ablauf nicht stören“ oder „in geringem Umfange“. Die Frage, wie das anschließend zu kontrollieren ist, ist eine Aufgabenstellung für das Sicherheitskonzept. Sind die Sicherheitsziele formuliert, müssen sie in ein Sicherheitskonzept eingearbeitet werden. Ein wichtiger Punkt darf bei Sicherheitspolitik und Sicherheitskonzept nicht aus den Augen gelassen werden: Sicherheit bringt Einschränkungen und Kontrolle mit sich. Je nach Situation gibt es Personen oder Gremien, die bei der Einschränkung von Rechten mitzureden haben, etwa der Betriebsrat. Kontrolle/Protokollierung kann auch der Mitsprache unterliegen, auf jeden Fall spielt hier der Datenschutz eine Rolle. Es empfiehlt sich generell, schon bei der Formulierung von Sicherheitszielen Mitspracheberechtigte zu informieren und ggf. zu beteiligen. Bei der Umsetzung in ein Sicherheitskonzept gibt es oft mehrere Wege, dasselbe Ziel zu erreichen. Ist ein Weg datenschutzrechtlich weniger bedenklich, aber dennoch gleichwertig, so sollte dieser vorgezogen werden. Alles andere würde bedeuten, den Ärger mit dem Datenschutz bereits im Konzept festzuschreiben.
23
3 Security Policy
3.4 Sicherheitskonzept Ein Sicherheitskonzept enthält die konkreten Ausführungsbestimmungen. Neben der Ausarbeitung von Sicherheitszielen enthält ein Sicherheitskonzept auch generische Elemente, die sich, unabhängig von den Sicherheitszielen, so oder ähnlich in jedem Sicherheitskonzept wiederfinden. Wir gliedern das Sicherheitskonzept hier in die vier Bereiche Organisation bzw. übergreifende Aspekte, Infrastruktur, IT-Systeme und Netzwerke. Aus Platzgründen kann hier nur schematisch auf die Grundelemente eines Sicherheitskonzepts eingegangen werden. Allen Lesern, die sich intensiv mit der Erstellung eines Sicherheitskonzeptes und dessen Umsetzung beschäftigen, sei das IT-Grundschutzhandbuch des Bundesamtes für Sicherheit in der Informationstechnik, BSI ([BSI99]), unbedingt empfohlen. Das IT-Grundschutzhandbuch ist auf der Homepage des BSI auch online verfügbar: http://www.bsi.de/
3.4.1
Organisatorisches
Unter diesem Oberbegriff fassen wir alles zusammen, was mit Zuständigkeiten/Verantwortlichkeiten, Regelungen, Anweisungen und allgemein mit dem Prozeß der Umsetzung von IT-Sicherheit an sich zu tun hat. ❏ Definition der Verantwortlichkeiten: Sicherheitsziele, die Erstellung und an-
schließende Umsetzung des Sicherheitskonzeptes wird von realen Personen durchgeführt. Jemand muß diese Schritte leiten und koordinieren. Es ist deshalb sinnvoll, zunächsten einen IT-Sicherheitsbeauftragten zu bestimmen, der den gesamten Prozeß initiiert. Ob der IT-Sicherheitsbeauftragte später allein zuständig bleibt, oder ob Teilaspekte der Verantwortlichkeit später auf andere übertragen werden, hängt vom Umfang der geplanten Sicherheitsmaßnahmen ab. Sind mehrere Personen für den Sicherheitsprozeß verantwortlich, ist in jedem Falle festzuhalten, wer wie eingebunden ist. ❏ Festlegung von Zugangsberechtigungen, Gruppen, Einzelpersonen : Zugangs-
berechtigungen spielen in der IT-Sicherheit eine große Rolle. Mit einem Zugang für Personen, die diesen eigentlich nicht benötigen, kann am wenigsten passieren, wenn dieser gar nicht existiert. Das gilt nicht nur für Accounts im Netzwerk oder Möglichkeiten in einer Anwendungssoftware, sondern ganz allgemein, also auch für Schlüssel zu besonders gesicherten Räumen. Mit dem Grundsatz „Soviel wie nötig, aber so wenig wie möglich“ hat man eine praktikable Deny Default Policy. Zunächst alles verbieten, und nur dann stückweise freigeben, was auch tatsächlich benötigt wird.
24
3.4 Sicherheitskonzept
Dabei tun sich zwei generelle Problemfelder auf: Setzt man dieses Prinzip für jede Person einzeln um, verliert man irgendwann den Überblick, und das Zugangskonzept wird nicht mehr pflegbar. Besser ist es, Zugangsberechtigungen generell in Gruppen einzuteilen und gruppenweise Vorgaben zu machen. Das zweite Problemfeld ist die Aktualität: Personen kommen und gehen, Zuordnungen und Aufgabenstellungen ändern sich. Ein vergessener Account eines Mitarbeiters, der längst nicht mehr existiert, kann von einem Eindringling unter Umständen monatelang genutzt werden, ohne daß es auffällt. Ein Berechtigungskonzept braucht daher auch Mechanismen, die für eine regelmäßige Aktualisierung sorgen. ❏ Regelungen und Anweisungen: Zur Umsetzung des Sicherheitskonzeptes müs-
sen Maßnahmen schriftlich fixiert und den Betroffenen, meist den Nutzern, aber auch Administratoren und anderen Beteiligten mitgeteilt werden. Manchmal ist es auch erforderlich, solche Anweisungen zum Bestandteil einer Nutzungsordnung oder sogar des Arbeitsvertrages werden zu lassen, um bei Verstößen entsprechend vorgehen zu können. ❏ Sicherungskonzepte: Kompromittierte Systeme erfordern in der Regel eine
vollständige Restaurierung von einer Sicherung, manchmal aber auch eine vollständige Neuinstallation. Eine Datensicherung sollte einem schriftlich fixierten Konzept folgen, das man anhand von Anforderungen wie „bis zu welchem Tag zurück soll eine vollständige Wiederherstellung möglich sein“, „soll eine Langzeitarchivierung bestimmter Daten erfolgen“ (etwa Logfiles, die mögliche Kompromittierungen besser datieren helfen) erstellt. Nur wenn genau festgelegt ist, was wo wann gesichert wird, lassen sich die geforderten Daten in überschaubarer Zeit rekonstruieren. ❏ Notfallpläne: Im Fall der Fälle (eines Einbruchs, der Löschung von Daten
oder ähnlich kritischer Ereignisse) hat man selten Zeit zu überlegen, was zu tun ist, und der Hauptverantwortliche ist bestimmt gerade im Urlaub . . . Man tut gut daran, im Voraus zu planen, bei welchem sicherheitskritischen Ereignis wie zu reagieren ist, wer zu informieren ist, welche Maßnahmen eingeleitet werden sollen. Wichtig sind dabei auch die Kommunikationsmittel. Wird in einen Firewall eingebrochen, kann man sich nicht mehr unbedingt auf eine Kommunikation via E-Mail verlassen. Möglicherweise ist der Eindringling noch aktiv und fängt die E-Mail ab oder wird zumindest vorgewarnt. Telefon und Fax tun hier dann bessere Dienste. Ein einfaches Beispiel für einen sicherheitskritischen Vorfall ist eine wurmverseuchte E-Mail, die trotz aller Sicherheitsvorkehrungen durchgerutscht ist und einige Rechner infiziert hat. Was ist jetzt zu tun? Wer muß informiert werden?
25
3 Security Policy
❏ Schulungsmaßnahmen, Informationsmittel: In der IT-Sicherheit hat viel mit Auf-
klärung und Wissen über die Zusammenhänge zu tun. Solange Anwender nicht wissen, was alles passieren kann, wenn man in E-Mails Attachments blind öffnet, werden sie es immer wieder tun. Und in sicherheitskritischen Bereichen soll es immer noch Tastaturen geben, unter denen Zugangskennung und Passwort stehen. Ein Sicherheitskonzept ist immer nur so stark wie das schwächste Glied. Regelungen für die IT-Nutzung, Anweisungen und auch aktuelle Informationen über neue Maßnahmen oder auch Sicherheitsvorfälle müssen für den Endbenutzer leicht zugänglich sein. Nur dann besteht die Chance, daß diese Information auch immer wieder einmal gelesen wird und in den Köpfen präsent ist. Hand aufs Herz: Wer weiß genau, wozu er datenschutzrechtlich in seinem Arbeitsvertrag verpflichtet wurde, wenn dieser älter als ein Jahr ist? Empfehlung: Wird regelmäßig Gebrauch von internen Informationsmedien gemacht, etwa aktuelle Nachrichten über den Betrieb oder die Organisation, dann sollte man dort auch immer wieder Sicherheitsthemen einflechten und gleichzeitig auf die allgemein verfügbaren Sicherheitsinformationen (etwa im Intranet) verweisen. ❏ Kontrollmaßnahmen: Zu den organisatorischen Maßnahmen gehört auch die
Kontrolle, ob das Sicherheitskonzept Anwendung findet und – vereinfacht gesagt – ob es funktioniert. Stellt man Abweichungen in der Praxis zum festgelegten Konzept fest, muß man prüfen, ob das Sicherheitskonzept gegebenenfalls angepaßt werden muß.
3.4.2
Infrastruktur
Zur Infrastruktur zählen räumliche und physikalische Gegebenheiten, etwa die Arbeitsräume, deren Lage, Gefährdung durch Brand, Wasser, Blitzschlag, die Stromversorgung an sich und die physikalische Verkabelung. Die meisten Dinge gehören in ein allgemeines IT-Sicherheitskonzept. Aus der Sicht der Netzwerksicherheit bleibt hier nur die physikalische Verkabelung. ❏ Abhören von kritischen Netzwerkbereichen: Die meisten lokalen Netze basieren
auf Ethernet, einem Shared Medium. Mehrere Netzwerkteilnehmer in einer sogenannten Collision Domain nutzen gemeinsam einen Netzwerkabschnitt, und jede Station in diesem Netzwerkabschnitt sieht prinzipiell den gesamten Netzwerkverkehr. Zwar findet man immer häufiger durch Switches und Router segmentierte Netzwerkbereiche, aber auch dort lassen sich Netzwerkbereiche finden, die wesentlich kritischere Informationen übertragen als andere Netzwerkabschnitte.
26
3.4 Sicherheitskonzept
Gelingt es einem Angreifer, physikalischen Zugang zu einem kritischen und an sich sonst vielleicht nicht zugänglichen Netzwerk zu verschaffen, kann er dort den Datenverkehr mitschneiden und auswerten. Werden zum Beispiel Passwörter im Klartext übertragen, könnten diese mitgeschnitten und später auch von anderen, besser zugänglichen Stellen aus mißbräuchlich verwendet werden. Der Zugang zu zentralen Netzwerkschränken ist deshalb fast ebenso kritisch wie ein Administratorpasswort. ❏ Manipulation der Netzwerkverkabelung: Ein Sicherheitskonzept im Netzwerk-
bereich basiert auf einer bestimmten Anordnung von Sicherheitselementen, wie zum Beispiel dem Standort des Firewalls, der Aufstellung von Servern in einer „entmilitarisierten Zone“ (DMZ, siehe auch Abschnitt 4.4.1) etc. Eventuell gelingt es einem Angreifer, durch Manipulation der Netzwerkverkabelung (Veränderung von Wegeführungen, physikalischen Schaltungen etc.), diese Anordnung zu verändern und Sicherheitsmaßnahmen zu umgehen. Auch unter diesem Gesichtspunkt ist ein zentraler Netzwerkschrank ein sehr sicherheitskritisches Element, dessen Zugang stark reglementiert werden sollte.
3.4.3
Einzelne Systeme
Sicherheit beginnt nicht erst beim Firewall, sondern bei jedem einzelnen System. Eine Workstation oder ein Server, der zwar aus dem Netzwerk heraus erreichbar ist, aber kritische Dienste erst gar nicht oder nur eingeschränkt anbietet, ist weitaus weniger verwundbar als ein 08/15-System, das mit allen bekannten Sicherheitslücken daher kommt und sogar ungeübten Script-Kiddies den Einbruch erleichtert. Aber auch der Zugang ohne Netzwerk an der Konsole bietet eine Eintrittspforte für lokale Anwender, über die man sich Zugang wiederum nicht nur lokal, sondern zum gesamten Netz verschaffen kann. ❏ Restriktive Handhabung der Zugriffsberechtigungen: Der allererste Ansatz ist
die Kontrolle des Zugangs zum System. Leicht erratbare oder nicht vorhandene Passwörter machen es Angreifern zu leicht. Ist ein Angreifer erst einmal auf einem System, kann er sich verschiedener Exploits bedienen, die nicht remote (über das Netzwerk), sondern nur lokal ausführbar sind (in der Regel mit dem Ziel, privilegierte Rechte wie z. B. root zu erlangen). ❏ Installation nur von benötigten Programmen: Bei der Installation sollte man al-
les nicht Benötigte weglassen. Jedes unbenutzte Programm bringt eventuell
27
3 Security Policy
eigene Sicherheitslücken mit und bindet unnötige Aufmerksamkeit, was die Absicherung bei neu entdeckten Lücken angeht (siehe auch Abschnitt 10.1). ❏ Entfernen aller überflüssigen Dienste: Oft werden Programme in Paketen ge-
bündelt installiert. Man kann dann die nicht gewünschten Dienste immer noch per Hand entfernen. ❏ Sonstige Härtungsmaßnahmen: Lokale Rechner lassen sich zusätzlich absi-
chern. Bei Linux-Systemen kann man auch lokale Paketfilterregeln implementieren, um nur die Kommunikation des Systems mit dem Netzwerk zuzulassen, die auch benötigt wird. Ein Server im DMZ hat dabei Bedarf an wesentlich strengeren Filterungen als eine normale Workstation im Netzwerk. Für Windows-Systeme mit erhöhtem Sicherheitsbedarf lassen sich analog sogenannte „Personal Firewalls“ einsetzen. Zu den durch das Internet besonders gefährdeten Windows-Systemen gehört zum Beispiel auch die Windows-Workstation eines Administrators. Unverzichtbar generell bei Windows-Systemen sind Virenscanner. ❏ Regelmäßige Updates bei Sicherheitsproblemen: Die Welt der Software ist nicht
vollkommen, deshalb tauchen auch immer wieder neue Bugs auf. Diese Bugs werden in der Regel umgehend veröffentlicht. Einerseits ist das zwar eine Hilfe für den Administrator, andererseits entsteht dadurch auch ein gewisser Zugzwang. Durch die Veröffentlichung ist man gezwungen, die mögliche Lücke zu stopfen. Ein Sicherheitskonzept sollte deshalb ein Verfahren enthalten, welche Updates wie durchgeführt werden. ❏ Sicherheitsaudits: Last, but not least ist eine regelmäßige Überprüfung der
Systemsicherheit sinnvoll. Es ergeben sich immer wieder neue Erkenntnisse über mögliche Sicherheitslücken, zum Teil auch aus der laufenden Beschäftigung mit der Thematik. Systeme, die seit längerer Zeit laufen, entsprechen meist nicht mehr dem aktuellen Konzept für die Systemsicherheit und müssen gegebenenfalls nachgebessert werden. Es ist deshalb sinnvoll, regelmäßige Überprüfungen vorzusehen. Für Linux-Systeme wird die Absicherung einzelner Systeme in Abschnitt 8.1 ausführlicher beschrieben. Kriterien für die Installation von Linux-Systemen finden sich in Abschnitt 10.1, weitere Informationen zu regelmäßigen Updates in Abschnitt 10.1.4.
3.4.4
Netzwerke
Vernetzt man einzelne Systeme, entstehen dadurch neue Gefährdungspotentiale. Genau das ist auch das zentrale Thema dieses Buches.
28
3.4 Sicherheitskonzept
Grundlage und Voraussetzung für eine effektive Sicherheitsplanung ist die genaue Kenntnis der eigenen Netzwerkstruktur. Alle gezielten Maßnahmen zur Verbesserung der Netzwerksicherheit bauen darauf auf. Stimmt die angenommene Netzwerkstruktur nicht mehr mit der Realität überein, ergeben sich daraus neue Gefährdungspotentiale, die um so gefährlicher sein können, weil sie möglicherweise lange Zeit unentdeckt bleiben. ❏ Erstellung eines Netzwerkplanes: Das A und O der Netzwerksicherheit ist ei-
ne Bestandsaufnahme in Form einer Dokumentation über die existierende Netzwerkstruktur. Dazu gehören neben der Netzwerkverkabelung, den aktiven Netzwerkkomponenten, allen Servern und Clients auch PeripherieGeräte wie Printboxen, Drucker etc., eben alles, was an das Netzwerk angeschlossen ist. Hinzu kommen Netzwerkverbindungen, die nach draußen führen, etwa die Internet-Anbindung, aber auch Netzwerkverbindungen zu Außenstellen, Partnern oder Telearbeitern. Um potentielle „Hintertüren“ mit einzuschließen, müssen auch alle Verbindungen dokumentiert werden, die eventuell über ISDN- oder ModemLeitungen geführt werden könnten. ❏ Festlegung von sicherheitskritischen Zonen: Nicht nur in größeren Netzwerken
gibt es Zonen, die aus sicherheitstechnischer Sicht unterschiedlich kritisch bewertet werden. Ein DMZ im Firewallbereich ist ein Netzwerkabschnitt, der wesentlich mehr Aufmerksamkeit benötigt als das Netzwerk interner Endbenutzer. Es kann auch ein besonders abgesicherter Netzwerkabschnitt mit brisanten, internen Informationen sein, zu dem auch interne Personen nur stark eingeschränkt Zugang haben. Insbesondere ist allen Außenverbindungen besondere Aufmerksamkeit zu widmen. ❏ Festlegung von Sicherheitsmaßnahmen und ihren Orten: Ist man sich über die
Netzwerkstruktur und ihre Empfindlichkeit (oder auch Attraktivität) gegenüber potentiellen Angreifern im Klaren, sind die Maßnahmen festzulegen, die getroffen werden müssen. Soll ein internes Netzwerk mit dem Internet verbunden werden, muß ein Firewall implementiert werden. Gehen mögliche Gefahren von internen Benutzern aus, sind Überwachungssysteme wie Intrusion Detection auch intern erforderlich. Arbeitsplätze mit ISDN-Außenverbindungen können in ein speziell überwachtes Netzwerk eingebunden werden usw. In manchen Fällen kann es auch notwendig sein, Außenanbindungen und eine Internetverbindung strikt zu verbieten. Dann sollten auch Möglichkeiten geschaffen werden, um Anwender auf eine andere Art und Weise Internet-Dienste zur Verfügung zu stellen, etwa Standalone-PCs oder ein spezielles Surf-Internet mit eigens dafür eingerichteten Workstations.
29
3 Security Policy
In das Sicherheitskonzept gehören auch ergänzende Maßnahmen, die dem Anwender die starken Einschränkungen erläutern und ihn aufklären, wie er bestimmte Dienste nutzen kann. ❏ Firewall: Hauptelement einer sicheren Internet-Anbindung ist sicher immer
ein Firewall. Je nach Sicherheitsanforderung kann vom einfachen Paketfilter bis zum mehrstufigen Firewall mit kaskardierten DMZs vieles realisiert werden. Falls beim Proxy-Einsatz veränderte Verfahren notwendig werden, müssen diese schon bei den Installationsrichtlinien der Clients beziehungsweise bei der Information der Anwender berücksichtigt werden. Kapitel 4.4 beschreibt einige Prinzipien des Firewallbaus. Informationen zu Proxies finden sich in Abschnitt 4.3 und Kapitel 6. Welche Gefahrenpotentiale welche Dienste mit sich bringen, wird in Kapitel 7 beschrieben, die Konstruktion von Firewalls in Kapitel 8. ❏ Lokale Maßnahmen: Neben der Absicherung von Übergängen zwischen in-
ternen und externen Netzwerkabschnitten (Firewall) dienen lokale Maßnahmen zur weiteren Verbesserung der Netzwerksicherheit. Dazu gehört insbesondere die gezielte Überwachung einzelner kritischer Zonen oder auch des gesamten Netzwerks durch Intrusion Detection Systeme. Strukturelle Maßnahmen, etwa die Segmentierung des lokalen Netzwerks durch Switches oder gar Router (direkt abhörbar ist der Netzwerkverkehr nur innerhalb einer Collision Domain) begrenzen bestimmte Angriffsvarianten auf kleine Zonen. Verschlüsselungsmaßnahmen, wie die Verschlüsselung von Verbindungen auf Netzwerkebene (z. B. IPSEC) für kritische Bereiche oder der Einsatz von Anwendungen mit Verschlüsselung (Secure Shell oder Anwendungen via Secure Socket Layer, SSL) sind ebenfalls ratsam, wo Zugangsdaten wie Passwörter im Netzwerk übertragen werden. ❏ Aktive Komponenten: Immer mehr läßt sich die Konfiguration von Netzwerk-
verbindungen per Software steuern. Meist sind es die aktiven Netzwerkkomponenten, die sich programmieren lassen. Damit läßt sich bei unbefugtem Zugang auch viel Schaden anrichten. Neben einer vollständigen Sabotage läßt sich oft auch die wohldokumentierte Netzwerktopologie umkonfigurieren. Möglicherweise funktioniert dann das mit viel Aufwand installierte Sicherheitskonzept nicht mehr. Im Sicherheitskonzept ist deshalb die Möglichkeit eines Angriffs auf solche zentralen Stellen im Netzwerk zu berücksichtigen. Als Minimalforderung ist eine Dokumentation über die Möglichkeiten der Umprogrammierung von aktiven Komponenten anzufertigen. In kritischen Bereichen kann es auch sinnvoll sein, auf weniger Bedienkomfort wert zu legen und einfache Komponenten so einzusetzen, daß die Topologie in erster Linie über die physikalische Kabelführung erzwungen wird.
30
3.5 Zusammenfassung
3.5 Zusammenfassung Sicherheit ist ein abstrakter Begriff. Was man darunter versteht bzw. wieviel Sicherheit tatsächlich verlangt wird, legt die Sicherheitspolitik in Form von Sicherheitszielen fest. Die Festlegung von Sicherheitszielen beschreibt in erster Linie politische Absichten, unter anderem auch, was Anwender dürfen, oder was nicht. Das Sicherheitskonzept legt dann konkrete Maßnahmen fest, wie die Sicherheitsziele umgesetzt werden sollen. Hier können nur Grundelemente eines Sicherheitskonzeptes beschrieben werden. Auf die Bewertung von Sicherheitsbedürfnissen oder Maßnahmen, die nicht direkt mit „Netzwerksicherheit“, dem Thema diese Buches, zu tun haben, kann nicht eingegangen werden. An dieser Stelle sei noch einmal auf das IT-Grundschutzhandbuch des Bundesamtes für Sicherheit in der Informationstechnik (BSI) ([BSI99]) verwiesen: http://www.bsi.de/
31
3 Security Policy
32
Kapitel 4 Grundlagen des Firewalldesigns Bisher standen politische und strategische Überlegungen zum Einsatz eines Firewalls im Vordergrund. Dieses Kapitel beschreibt nun die Grundbausteine von Firewalls und stellt einige konzeptionelle Überlegungen dazu an. Firewalls sind abhängig von dem zugrunde liegenden Protokoll. Das bedeutet, daß bei einem Protokollwechsel zwar dieselben strategischen Überlegungen und Ideen gelten, aber die eigentliche Implementierung und die Konzepte dazu nicht so ohne weiteres übertragen werden können. Das ist nur möglich, wenn das neue Protokoll auch dieselben Grundeigenschaften besitzt. Ohne darauf näher einzugehen, sollten Sie sich nur merken, daß die im weiteren Verlauf vorgestellten Konzepte und Lösungsmöglichkeiten eng verknüpft sind mit der dem Internet zugrundeliegenden Protokollfamilie TCP/IP. In Umgebungen mit anderen Protokollen, wie z. B. Novell (SPX/IPX) oder Decnet, bestehen wahrscheinlich ganz andere Gefährdungspotentiale, so daß auch die Lösungswege andere als die hier vorgestellten Firewalls sein können. Mit den Eigenschaften der TCP/IP-Protokollfamilie beschäftigt sich der erste Abschnitt in diesem Kapitel. Danach werden die eigentlichen Elemente von Firewalls vorgestellt: Paketfilter und Proxies (Abschnitte 4.2 und 4.3). Geeignete Anordungen der Grundbausteine, Proxy und Paketfilter finden Sie dann im Abschnitt 4.4. Zusammen mit einer passenden Sicherheitspolitik dürfen diese dann auch endlich den Namen Firewall tragen. Der letzte Abschnitt beschäftigt sich mit dem sogenannten „privaten Adreßraum“, der aus einer Not heraus geboren wurde: die verfügbaren IP-Adressen wurden knapp und ein Kollaps des Internet drohte. Deshalb mußten neue Ideen her, die man in Form von „privaten Adressen“ heute nicht nur bei Privatanwendern und kleineren Firmen findet, sondern immer mehr auch in großen Organisationen.
33
4 Grundlagen des Firewalldesigns
4.1 TCP/IP – Netzwerkprotokoll für das Internet Für das Internet war eine gemeinsame Sprache notwendig: Nur ein einheitliches Protokoll stellt sicher, daß alle angeschlossenen Rechner miteinander kommunizieren können. Bevor das Internet-Protokoll IP mit all seinen Bestandteilen näher beschrieben wird, lohnt es sich, den Begriff Netzwerkprotokoll näher zu betrachten. Netzwerkprotokolle decken das gesamte Spektrum zwischen dem physikalischen Medium und den Anwendungen ab. Um Netzwerkprotokolle besser beschreiben zu können, hat die ISO ein Referenzmodell geschaffen. Damit beschäftigt sich der nächste Abschnitt. Anschließend folgt ein kurzer Ausflug in die historische Entwicklung des Internet-Protokolls, bevor dieses dann ausführlicher behandelt wird.
4.1.1
Das OSI-Referenzmodell
Um eine einheitliche Sprache und eine Referenzstruktur für die Interoperabilität unterschiedlicher Netzwerkprotokolle zu schaffen, wurde von der ISO das sogenannte OSI-Referenzmodell definiert (OSI: „Open System Interconnection“). Das OSI-Referenzmodell (siehe Abbildung 4.1) besteht aus sieben Schichten, die die Verbindung zwischen der eigentlichen Anwendung auf dem Computer und dem physikalischen Stück Draht (salopp gesprochen) herstellt, der mehrere Computer miteinander verbindet.
Abbildung 4.1: OSI-Referenzmodell
34
4.1 TCP/IP – Netzwerkprotokoll für das Internet
Die einzelnen Schichten des OSI-Modells: ❏ Physical Layer: stellt das Interface zum physikalischen Übertragungsmedi-
um dar (elektrisch, optisch, mechanisch). Hier wird definiert, was ein Bit ist. Der auf dieser Ebene übertragene Bitstrom ist völlig unstrukturiert. ❏ Data Link Layer: konvertiert den Bitstrom in einzelne Frames. Es finden eine
physikalische Sender/Empfängerkennung (Adressierung) und eine Fehlerkorrektur statt. ❏ Network Layer: Zuordnung zwischen physikalischen und logischen Adres-
sen. Im Network Layer wird die logische Verbindung aufgebaut, bei nichtlokalem Datenverkehr für entsprechendes Routing gesorgt. Durcheinander geratene Pakete werden wieder sortiert. ❏ Transport Layer: stellt eine Punkt-zu-Punkt-Verbindung der beteiligten Dien-
ste her. Gleichzeitig ist diese Schicht die Trennung zwischen der Übertragung und der Anwendung. Im Transport Layer findet ggf. ein Umpacken der Pakete statt: beim Versand werden zu große Datenströme in kleine Pakete zerlegt, beim Empfang werden die einzelnen Datenpakete wieder zu einem vollständigen Datenstrom zusammengesetzt. Die darüberliegenden Schichten bekommen nichts mehr von den Paketeigenschaften des Netzwerks mit. ❏ Session Layer: Verbindung zwischen den eigentlichen Prozessen. Damit ist
der Session Layer bereits Teil der Applikation und hat nichts mehr direkt mit dem lokalen Netzwerk zu tun. Hier finden z. B. Auf- und Abbau einer Sitzung und Sicherheitskontrollen statt. ❏ Presentation Layer: hier werden die Daten interpretiert und in geeigneter
Weise dem Application Layer zur Verfügung gestellt. Hauptanwendung ist die Konvertierung zwischen unterschiedlichen Daten-Darstellungsformaten (ASCII – EBCDIC, Big Endian – Little Endian). High-Level Kryptographie ist ebenfalls hier angesiedelt. ❏ Application Layer: hier werden die Schnittstellen für Hard- und Software-
unabhängige Programmierung zur Verfügung gestellt. Ein Problem, das das OSI-Modell mit sich bringt, ist die relativ späte Verabschiedung. Protokolle wie TCP/IP gab es schon vorher und brachten ihr eigenes Schichtenmodell mit. Nach dem Erscheinen des OSI-Modells war es meist nicht mehr möglich, die bereits existierenden Protokolle anzupassen. Für eine Erklärung der Funktionalität bietet sich aber das OSI-Modell trotzdem an, auch wenn in Feinheiten keine exakte 1:1-Zuordnung möglich ist. Die ISO hat dem OSI-Modell entsprechend selbst viele Protokolle definiert und verabschiedet. Im Internet selbst finden diese aber aufgrund ihrer Komplexität keine Verbreitung. TCP/IP war eben bereits verbreitet, relativ einfach und gut genug.
35
4 Grundlagen des Firewalldesigns
4.1.2
Historische Entwicklung
Das heute im Internet verwendete Protokoll trägt auch dessen Namen: IP steht ganz einfach für „Internetprotokoll“. Die Ursprünge des Internet sind bereits 1962 zu finden. Damals erteilten amerikanische Militärs den Auftrag, ein Netzwerk zu schaffen, das einen Atomkrieg überstehen würde. Konkret: auch bei Zerstörung von mehreren hundert Knoten im Netzwerk sollte dieses die volle Funktionsfähigkeit behalten. Ein zu dieser Zeit ungeheurer Gedanke, da existente Netzwerke zentralistisch organisiert waren und ohne eine einsatzfähige zentrale Steuerung nicht funktionsfähig waren. Informationen zum Ergebnis dieser Studie finden Sie unter: http://www.rand.org/publications/electronic/ Die Studie wurde von Paul Baran durchgeführt, damals Mitarbeiter der Rand Corporation. Die Grundideen: Zerlegung der Daten in einzelne Pakete in ein Standardformat, Store-and-Forward in den einzelnen Netzwerkknoten und ein beliebig vermaschtes Netzwerk, in dem die Netzwerkknoten aufgrund aktueller Information den weiteren Weg des Pakets selbst, d. h. autonom und ohne zentrale Instanz treffen. Nach einigen Verzögerungen wurde in 1969 das erste paketvermittelnde Netzwerk in Betrieb genommen : das ARPANET (Advanced Research Projects Agency NETwork) verband 1969 vier Forschungseinrichtungen. Bis 1975 hatte das ARPANET Einsatzreife erreicht und wurde von der US-Regierung übernommen. Die Kontrolle bekam damals die Defense Communication Agency. Das Protokoll TCP selbst wurde zwar schon 1974 erfunden, die eigentliche Entwicklung der TCP/IP-Protokollfamilie fand aber erst nach 1975 statt. Im Jahre 1983 wurde das ARPANET geteilt. Es hatte bereits eine beachtliche Größe erreicht, und die Militärs wollten eine Trennung zwischem einem militärischen Teil (MILNET) und einem zivilen Teil (weiterhin ARPANET). Im gleichen Jahr wurde auch TCP/IP zum Military Standard (MIL STD). Alle angeschlossenen Rechner sollten auf das neue Protokoll wechseln. Das ARPANET, das formal 1990 abgeschafft wurde, ist der Urvater des Internet. Definiert man „das Internet“ als den Zusammenschluß aller Netze auf der Basis von IP, existiert das Internet in seiner heutigen Form bereits seit 1983, da es nach der Trennung in MILNET und ARPANET beide Netze verband. Da die Entwicklung und anfängliche Verwendung auf die Initiative der US-amerikanischen Militärs zurückgeht, spricht man auch von der DoD-Protokollfamilie (Departement of Defense).
36
4.1 TCP/IP – Netzwerkprotokoll für das Internet
4.1.3
DoD-Protokollfamilie (TCP/IP)
Die DoD-Protokollfamilie kennt gegenüber dem OSI-Modell nur vier Schichten: ❏ Network Access Layer: diese Schicht faßt den Physical Layer (1) und den Data
Link Layer (2) aus dem OSI-Modell zusammen. ❏ Internet Layer: entspricht dem OSI-Network Layer (3). ❏ Host-to-Host Transport Layer: entspricht dem OSI-Transport Layer (4). ❏ Application Layer: faßt die applikationsbezogenen OSI-Schichten (5-7) zu-
sammen. Verschiedene Programme setzen direkt auf den Transport Layer auf und unterscheiden die OSI-Ebenen 5-7 nicht. Als ein Beispiel für die Funktionalitäten der Schichten 5-7 kann das Network File System (NFS) dienen: die Schnittstellen werden im Application Layer definiert, auf der Ebene des Presentation Layer kommt XDR zu Einsatz, ein Mechanismus, der Datenformate unabhängig von der physikalischen Darstellung definiert und damit genau die Funktion des OSI Presentation Layer erfüllt. Auf der Ebene des Session Layer kommt der Remote Procedure Call (RPC) zum Einsatz, mit dem netzwerkweit die Verbindung zwischen zwei Prozessen hergestellt werden kann. Eine Übersicht über die DoD-Familie und die Zuordnung zum OSI-Layer gibt Abbildung 4.2. Wer in die Komponenten von TCP/IP (wirklich) tief einsteigen möchte, dem sei [Ste94] empfohlen. Dort sind die Protokolle bis ins Detail dargestellt und mit vielen Graphiken verständlich aufbereitet.
Abbildung 4.2: OSI-/DoD-Modell im Vergleich
37
4 Grundlagen des Firewalldesigns
4.1.4
Firewallsysteme und OSI-Ebenen
Von welchen Ebenen ist nun ein Firewallsystem betroffen? OSI-Ebene 2 (Data Link Layer) ist die Ebene des lokalen Netzwerks, zum Beispiel Ethernet oder Token Ring. Ein Firewallsystem kommt auf dieser Ebene nur mit Rechnern in Kontakt, die direkt angeschlossen sind. Dazu gehört auch zum Beispiel die ISDNVerbindung zum Provider. Ein Angriff aus dem Internet auf dieser Ebene ist nicht möglich. Die OSI-Ebene 2 spielt bei Firewalls nur eine Rolle innerhalb von lokalen Netzwerken. OSI-Ebene 3 (Network Layer) und 4 (Transport Layer) sind das eigentliche Kerngeschäft von Firewalls, insbesondere von Paketfiltern (Abschnitt 4.2). Dazu kommen Proxies (Abschnitt 4.3), die auch von den Ebenen 3 und 4 berührt werden, aber die vor allem auf Anwendungsebene arbeiten. Die Zuordnung zu den einzelnen OSI-Anwendungsebenen spielt allerdings keine zentrale Rolle, daher wird hier auch nicht näher darauf eingegangen. Im weiteren konzentrieren wir uns auf die OSI-Ebenen 3 (Network Layer) und 4 (Transport-Layer) und gehen auf Eigenschaften der dort vertretenen Protokolle näher ein.
4.1.5
IP
Hauptaufgabe des IP-Protokolls (obwohl das „P“ in der Abkürzung für „Protocol“ steht, hat sich der Terminus „IP-Protokoll“ eingebürgert) ist die logische Adressierung. Jedes Paket enthält eine logische Absenderadresse und eine logische Empfängeradresse. Eine weitere wichtige Aufgabe des IP-Protokolls ist die Fragmentierung. Jedes Netzwerk hat eine maximale Größe für die übertragenen Pakete, die sogenannte „Maximum Transfer Unit“ (MTU) . Erhält der Network Layer ein Datagramm, das größer ist als die MTU, wird es in mehrere Fragmente zerlegt. Die Fragmente sind jeweils eigenständige Teilpakete, die erst am Ziel wieder zusammengesetzt werden müssen. Einziger Unterschied: geht ein Fragment eines Datagramms verloren, muß das gesamte Datagramm (und nicht nur das einzelne Fragment) neu gesendet werden. Für die darüber liegende Ebene ist die Fragmentierung völlig transparent. IP ist die unterste Schicht, die bei der Übertragung über Router hinweg erhalten bleibt. Router entfernen die darunter liegenden Schichten und adressieren das Paket für die OSI-Ebene 2 neu. Der IP-Header ist in Abbildung 4.3 dargestellt. Er besitzt unter anderem folgende Felder: ❏ Version: Die aktuelle Protokollversion ist 4.
38
4.1 TCP/IP – Netzwerkprotokoll für das Internet
Abbildung 4.3: IP-Header
❏ Header Length: Länge des Header in 32-Bit-Wörtern. Ohne Optionen ist die
Headerlänge immer 20 Bytes, also steht dort meist eine 5. Ist der Wert ungleich 5, bedeutet das ein Vorhandensein von Optionen. ❏ Type Of Service (TOS): TOS ist die Quality of Service-Implementierung auf
TCP/IP-Ebene (und schon viel älter als die aktuelle Diskussion). Mit diesem Flag kann gesteuert werden, ob ein Paket vorrangig behandelt wird, um bestimmte Qualitäten zu erreichen (z. B. maximaler Datendurchsatz bei Datenübertragung, kürzeste Reaktionszeiten bei interaktiven Anwendungen etc.). ❏ Total Length: Gesamtlänge des Pakets ❏ Identification: eindeutige Nummer des Paketes ❏ Fragmentation: eingangs schon erwähnt, setzt in jedem Netzwerk die MTU
eine obere Grenze für die mögliche Größe eines Datenpakets. Das IP-Protokoll nimmt automatisch eine Fragmentierung vor, wenn das IP-Datagramm größer werden sollte als die vorgegebene MTU. Die Flags (3-Bit) geben an, ob das Paket fragmentiert werden darf bzw. ob es sich um eine Fragment handelt. Wenn es sich um ein Fragment handelt, weist der Fragment Offset aus, wo das Fragment in das originale IP-Datagramm einzufügen ist. Eine Fragmentierung kann auch unterwegs im Netzwerk von jedem Router vorgenommen werden. ❏ Time To Live (TTL): Laufzeitangabe. Bei jedem Router wird der TTL-Zähler
um 1 erniedrigt. Erreicht der Zähler 0, wird das Paket nicht weitergeleitet, sondern eine Fehlermeldung gesendet. TTL soll Endlosschleifen ver-
39
4 Grundlagen des Firewalldesigns
hindern, kann aber auch für spezielle Zwecke „mißbraucht“ werden. Das Programm traceroute sendet das erste Paket mit TTL gleich 0, um den nächstliegenden Router aus der Fehlermeldung zu erfahren, dann wird der Wert um 1 erhöht und derselbe Versuch noch einmal gestartet. Auf diese Weise erfährt traceroute die einzelnen Knoten auf dem Weg zum Zielhost, die sonst nicht sichtbar wären. ❏ Protocol: welches Protokoll in dem IP-Paket transportiert wird: TCP, UDP,
ICMP, IGMP, OSPF. ❏ Checksum: Header-Checksumme. IP verfügt über keine Checksumme der
Daten, diese Aufgabe übernehmen die transportierten Protokolle. ❏ Source IP Address: die IP-Adresse des Absenders ❏ Destination IP Address: die IP-Adresse des Empfängers ❏ Options: Das IP-Protokoll verfügt über einige Optionen, die heute nur noch
selten benutzt werden. Dazu gehören Sicherheitsmaßnahmen für den militärischen Bereich, oder, eher bekannt, Source Routing Options, die Einfluß auf die vom IP-Datagramm zurückgelegte Wegstrecke nehmen sollen. Als Firewallbetreiber tut man gut daran, IP-Datagramme mit Source Routing Options zu verwerfen, da diese sonst unter Umständen an vorhandenen Sicherheitsmaßnahmen vorbeimogeln könnten. ❏ Data: Der eigentliche Datenbereich des IP-Datagramms, der die Nutzinfor-
mation trägt (zum Beispiel bei TCP den TCP-Header und TCP-Daten). Das IP-Protokoll verfügt über die Möglichkeit des „Source Routing“. Damit ist gemeint, daß der Absender den genauen Pfad angibt, den das Paket nehmen soll. Im einen oder anderen Fall vielleicht eine nützliche Sache, hat Source Routing aber einen eher anrüchigen Charakter, da es sich für Einbruchszwecke gut mißbrauchen läßt. Um zu verhindern, daß ein potentieller Eindringling Sicherheitsmaßnahmen unterläuft, sollte Source Routing innerhalb von Firewallumgebungen generell unterbunden werden.
4.1.6
TCP
TCP arbeitet zuverlässig und verbindungsorientiert. Die Daten werden als ununterbrochener Datenstrom zur Verfügung gestellt. Die Eigenschaften von TCP: ❏ Verbindungsorientiert: TCP baut eine Verbindung zur Gegenstelle explizit
auf. Wird die Verbindung nicht mehr benötigt, wird die Verbindung ebenso explizit wieder abgebaut. Ein Datentransfer ohne Verbindungsaufbau ist nicht möglich. ❏ Segmentierung: TCP zerlegt Datenströme selbständig in eigene Segmente.
Die beteiligten Partner verständigen sich beim Verbindungsaufbau auf die
40
4.1 TCP/IP – Netzwerkprotokoll für das Internet
Maximum Segment Size (MSS) . Dieser Vorgang hat nichts mit der Fragmentierung auf IP-Ebene zu tun. Optimalerweise ist die MSS so groß wie die kleinste MTU auf der gesamten Strecke, um Fragmentierung zu vermeiden. ❏ zuverlässig bedeutet, daß das Protokoll TCP (im Gegensatz zu vielen anderen
Protokollen) selbst sicherstellt, daß die Daten auch tatsächlich ankommen. Wird ein Segment gesendet, muß der Empfänger innerhalb eines Timeouts eine Bestätigung über den Empfang des Segments zurücksenden. Läuft der Timeout ohne Bestätigung ab, wird das Segment erneut versendet. Ferner enthält TCP eine Checksumme über Header und Daten. Ist ein Segment defekt, wird keine Bestätigung versandt und auf das erneute Eintreffen des Segments gewartet. Stimmt die Reihenfolge der Segmente nicht, sortiert TCP diese, trifft ein Segment doppelt ein, wird das Duplikat verworfen. ❏ ununterbrochener Datenstrom: Die darüber liegenden Schichten auf Empfän-
gerseite erhalten einen ununterbrochenen Datenstrom, der keine Informationen mehr über die Stückelung auf Senderseite enthält. Enthält zum Beispiel das erste Segment 200 Bytes, das zweite 1024 Bytes, das dritte 568 Bytes, ist davon auf Empfängerseite nichts mehr feststellbar. TCP kümmert sich ferner um eine Datenflußkontrolle. Läuft auf Empfängerseite der Buffer voll, teilt der Empfänger dem Sender mit, daß nichts mehr gesendet werden soll. Ports/Sockets Das TCP-Protokoll besitzt eine weitere Sender-Empfängeradressierung, die sogenannte Portnummer. Während die IP-Adressierung für die Zustellung zum richtigen Host sorgt, dient die Portadressierung der Auswahl des richtigen Dienstes. Am besten läßt sich das an einem Beispiel veranschaulichen:
Abbildung 4.4: Port-Adressierung
41
4 Grundlagen des Firewalldesigns
Ein Client möchte eine Telnet-Verbindung zum Server aufbauen (siehe Abbildung 4.4). Auf Serverseite ist dem Dienst Telnet der Port 23 zugeordnet. Der Client baut jetzt eine Verbindung auf, die auf IP-Ebene die Server-IP-Adresse, und auf TCP-Ebene den Server-TCP-Port enthält. Auf Serverseite lauscht ein Telnet-Daemon auf Port 23 und wartet auf eingehende Verbindungen. Der Client selbst könnte auch einen Telnet-Daemon laufen haben. Auf dem Client dürfen die Sende-Port-Adresse und eine potentielle Empfänger-Port-Adresse für den eigenen Telnet-Daemon nicht identisch sein, andernfalls ist bei eingehenden Paketen nicht mehr zuzuordnen, ob es sich um eine Antwort des Servers oder eine fremde Telnetanfrage handelt. Für TCP gibt es deshalb einige Spielregeln: ❏ Der Serverport ist eindeutig festgelegt. Für Telnet ist das der Port 23. Wel-
cher Port zu welchem Dienst gehört, legt RFC 1340 fest. Unter Unix findet man die Ports in der Datei /etc/services. Einen Auszug der wichtigsten Ports finden Sie auch im Abschnitt A.6. ❏ Der Client verwendet einen anderen, freien Quellport. ❏ Ports bis 1023 sind sogenannte „privilegierte Ports“. Unter Unix können
sie nur unter root-Rechten verwendet werden. Die meisten Serverports werden unter root-Rechten geöffnet. Deshalb liegen auch viele Serverports unterhalb von 1023. Das ist aber nicht zwingend notwendig. Es müssen nur alle betroffenen Clients wissen, auf welchem Port am Server ein Dienst angesprochen werden kann (zum Beispiel via /etc/hosts. Die Kombination aus IP-Adresse und Port bezeichnet man als Socket. Verbindungsauf- und -abbau TCP ist ein verbindungsorientiertes Protokoll mit gezieltem Verbindungsauf- und -abbau. Die Signalisierung des jeweiligen Zustands erfolgt über einige Flags: ❏ SYN (Synchronisation): signalisiert den Verbindungsaufbau ❏ ACK (Acknowledgement): bestehende Verbindung ❏ FIN: Sender beendet die Datenübertragung
Den Ablauf zeigt Abbildung 4.5. Zunächst sendet der Client eine Anfrage an den Server in Form eines TCP-Segments mit gesetztem SYN-Flag. Der Server antwortet mit einem zweiten Segment, bei dem sowohl SYN- als auch ACK-Flag gesetzt sind. Dieses Segment wird wiederum vom Client bestätigt, in dem er ein weiteres Segment sendet, bei dem jetzt das SYN-Flag gelöscht und nur noch das ACK-Flag gesetzt ist. Den ganzen Vorgang nennt man auch „Three Way Handshake“. Während der Datenübertragung haben alle Segmente ein gesetztes ACK-Flag.
42
4.1 TCP/IP – Netzwerkprotokoll für das Internet
Abbildung 4.5: TCP-Verbindungsauf- und -abbau mit SYN- und FIN-Flag
Zur Beendigung der Datenübertragung erfolgt ein zweiseitiges Schließen der Verbindung. Normalerweise sendet der Client ein Segment mit gesetztem FINFlag. Der Server bestätigt dies. Damit ist die Senderichtung Client-Server geschlossen. Anschließend sendet der Server dem Client ein Segment mit gesetztem FIN-Flag, und der Client bestätigt dies. Erst dann ist die Verbindung gänzlich geschlossen. Über den Verbindungsaufbau und die SYN-Flag-Signalisierung ist eindeutig feststellbar, wer die Verbindung wohin aufbaut. Von dieser Eigenschaft wird in Firewallumgebungen von Paketfiltern rege Gebrauch gemacht, da sich so gezielt TCP-Verbindungen erlauben lassen. Zum Beispiel kann man relativ einfach eine ausgehende Telnetverbindung erlauben, eingehende Telnet-Versuche aber strikt untersagen. Dabei werden einfach Pakete, die im TCP-Header ausschließlich das SYN-Flag gesetzt haben (erstes Paket für einen Verbindungsaufbau), über Filterregeln nur hinaus, nicht aber herein gelassen. Den Zustand von TCP-Verbindungen kann man sich mit netstat -an ansehen. Die folgende Beispielausgabe wurde um die Spalten Recv-Q und Send-Q gekürzt:
43
4 Grundlagen des Firewalldesigns
Active Internet connections Proto Local Address tcp 149.225.97.165:1533 tcp 149.225.133.184:1554 tcp 149.225.133.184:1563 tcp 149.225.133.184:1569
(servers and established) Foreign Address State 161.69.2.149:80 FIN_WAIT1 192.76.144.56:110 TIME_WAIT 193.99.144.71:80 CLOSE 193.99.144.71:80 ESTABLISHED
ESTABLISHED ist eine Verbindung nach dem Three Way Handshake, CLOSE ist eine bereits vollständig geschlossene Verbindung, FIN_WAIT1 bedeutet, der Client hat ein aktives Schließen initiiert (sendet ein FIN-Paket an den Server), TIME_WAIT ist der Zustand für eine bestimmte Zeit, nach dem der Client das Acknowledge auf ein FIN-Paket erhalten hat.
4.1.7
UDP
UDP ist ein einfaches, verbindungsloses und Datagramm-orientiertes Protokoll des Transport Layer. Jede Operation der darüberliegenden Schichten produziert exakt ein UDP-Datagramm. UDP kennt die streamorientierten Mechanismen von TCP nicht. Sind die UDP-Datagramme zu groß, kommt es zu einer Fragmentierung auf der IP-Ebene. Die Anwendung selbst muß also eine Idee davon haben, wie groß die MTU ist, um gegebenenfalls Fragmentierung zu vermeiden. UDP ist außerdem unzuverlässig. Unzuverlässig heißt, daß sich das Transportprotokoll UDP erst gar nicht darum kümmert, ob die Datagramme ankommen oder nicht. Hier liegt es ebenfalls an der Applikation, sich darum zu kümmern, ob alle Pakete ankommen, ob die Reihenfolge stimmt und ob doppelte Pakete vorhanden sind. Wie TCP berechnet UDP eine Checksumme über Header und Daten, was auch erforderlich ist, da das IP-Protokoll nicht über eine Daten-Checksumme verfügt. Macht der Empfänger ein defektes Paket aus, verschwindet dieses allerdings auf der Ebene des Transport Layer sang- und klanglos. Weder wird der Absender verständigt, noch beim Empfänger die darüber liegende Ebene. Bei UDP muß die Applikation selbst das Fehlen des Paketes feststellen und es erneut anfordern. UDP besitzt wie TCP Portnummern mit vergleichbaren Eigenschaften. Wichtig ist, daß UDP und TCP einen getrennten Adreßraum für ihre Portnummern besitzen, d. h., Port 23/udp ist ein anderer Port als Port 23/tcp. Möglich ist das, weil bereits im IP-Header zwischen TCP und UDP unterschieden wird und deshalb bereits im Network Layer protokollabhängig zugestellt werden kann. Bei UDP ist die Server-Client-Beziehung je nach Dienst nicht immer eindeutig. Es gibt Dienste, die wie bei TCP typische Client-Server Port-Paare bilden, es gibt aber auch Dienste, wo Server und Client ein und denselben Port benutzen.
44
4.2 Paketfilterung
Bei all diesen Einschränkungen fragt man sich, wo denn der Vorteil von UDP gegenüber TCP liegt. TCP besitzt zweifellos einen wesentlich größeren Protokolloverhead. Insbesondere die Bestätigung jedes einzelnen Paketes verbraucht Ressourcen. Dienste, bei denen es eher auf eine schnelle Übertragung ankommt, ziehen UDP vor. Ein Beispiel ist ntp, das Network Time Protokoll. Für Firewalls ist die Verbindungslosigkeit, d. h. das Fehlen eines Zustands der Verbindung schwieriger zu handhaben. Da nicht festgestellt werden kann, ob eine Verbindung noch besteht, muß ein Firewall ein Fenster für den gewünschten UDP-Verkehr immer noch eine Zeitlang offen halten und einen Timeout abwarten.
4.1.8
ICMP
ICMP wird oft als Bestandteil des Network Layer angesehen, wird aber wie UDP und TCP über IP-Pakete versendet. Der Name „Internet Control Message Protocol“ beschreibt die Aufgabe des Protokolls. In jedem Netzwerk können Fehler oder andere, unvorhergesehene Zustände auftreten. Dann besteht die Notwendigkeit, entsprechende Nachrichten zu verschicken. Das erledigt dann das ICMP. Die versendeten Nachrichten betreffen entweder Fehlerzustände von IPDatagrammen oder von TCP/UDP-Datagrammen. ICMP besitzt wie TCP und UDP eine Checksumme, die über das gesamte Datagramm geht. Es gibt keine gesicherte Verbindung, sondern nur einzelne Nachrichten. Anstelle von Ports besitzt ICMP Nachrichtentypen, die den Inhalt der Nachricht beschreiben. ICMP-Nachrichten enthalten im Datenteil den Header und die ersten 8 Bytes aus dem Paket, das die Fehlermeldung ausgelöst hat, um dem Absender die Zuordnung der Nachricht zur besseren Fehlererkennung zu ermöglichen. Ein Beispiel für die Anwendung von ICMP ist das Programm ping. ping ist ein Programm, das eine ICMP-Nachricht vom Typ echo request an einen Host sendet, die dieser mit einem ICMP-Nachrichtentyp echo reply beantwortet. Man kann damit feststellen, ob ein Host erreichbar ist (manche ping-Programme sagen dann einfach „host is alive“), und dazu einige Messungen (Antwortzeiten, Entfernung in Hops) durchführen. Die einzelnen Nachrichtentypen finden Sie im Abschnitt A.4.
4.2 Paketfilterung Ein Paketfilter (siehe Abbildung 4.6) sitzt zwischen zwei logischen oder physikalischen Netzwerken. Er überwacht und kontrolliert den Netzwerkverkehr, indem er jedes Paket analysiert und dann eine Entscheidung über dieses Paket trifft:
45
4 Grundlagen des Firewalldesigns
Abbildung 4.6: Einsatz eines Paketfilter
Durchlassen (ACCEPT) oder Verweigern. Im Falle des Verweigerns kann das Paket verworfen (DROP) oder mit einer entsprechenden Meldung zurückgewiesen werden (REJECT). Das Paket bleibt weitgehend unverändert. Ein Paketfilter kann auf verschiedenen Ebenen von Netzwerkprotokollen agieren. Ein Ethernet Switch in der Funktionalität einer Multiportbridge entscheidet in der Regel auf der Ebene 2 des OSI-Modells (Data Link Layer), ob ein Paket an einem bestimmten Port durchgelassen wird oder nicht. Dabei können sowohl eingehende als auch ausgehende Pakete betrachtet werden. Bei eingehenden Paketen können bei entsprechender Konfiguration nur „erlaubte“ Sender freigeschaltet werden (Sicherheitsmerkmal), bei ausgehenden Paketen werden nur Pakete durchgelassen, die auch an den am betreffenden Port erreichbaren Rechner adressiert sind (Reduktion der Netzlast). Ein Paketfilter auf der Ebene 2 funktioniert nur, wenn auf beiden Seiten des Filters dieselbe Netzwerktechnologie eingesetzt wird, z. B. Ethernet. Beim Wechsel zwischen verschiedenen Netzwerktechnologien (z. B. von Ethernet nach PPP via ISDN) gehen die Header der Ebene 2 verloren. In der Regel kommt ein Firewall aber dort zum Einsatz, wo unterschiedliche Netzwerke verbunden werden oder zumindest Routingfunktionalität benötigt wird. Wir beschränken uns deshalb bei den Paketfiltern auf solche mit Routingfunktionalität, d. h., die Pakete werden erst ab Ebene 3 (Network Layer) untersucht. Gegen direkte Angriffe auf Ebene 2 muß sich der Paketfilter dennoch schützen. Neben den Informationen aus dem Header der untersuchten Pakete kann auch die Information, über welche Netzwerkinterfaces das Paket läuft, zur Entscheidung des Paketfilters mit herangezogen werden. Verschiedene Angriffsszenarien basieren darauf, dem Paketfilter eine gefälschte Absenderadresse aus dem in-
46
4.2 Paketfilterung
ternen (vertrauenswürdigen) Netz unterzuschieben. Die Fähigkeit, Filterregeln für einzelne Netzwerkinterfaces setzen zu können, ist daher eine wichtige Eigenschaft eines Paketfilters.
4.2.1
Statische Paketfilterung
Herkömmliche Paketfilterung nennt man auch statische Paketfilterung, da diese zustandslos arbeitet. Zustandslos heißt, die Filterregeln sind unabhängig von bisher eingetroffenen, vorangegangenen Paketen. Auf jedes Paket wird immer wieder derselbe Satz an Filterregeln angewandt. Beispiel: Eine ausgehende Telnetverbindung ist erlaubt. Telnetverbindungen finden über TCP statt, d. h., es gibt einen gezielten Verbindungsaufbau. Das erste ausgehende Paket trägt das SYN-Flag gesetzt, alle eintreffenden Pakete haben das ACK-Flag gesetzt. Die Verbindung an sich ist schon zustandsorientiert, da eine bestimmte Abfolge in der Kommunikation vorgeschrieben ist. Die Paketfilterung dagegen nicht: ❏ Jedes ausgehende Paket wird nur daraufhin überprüft, ob der Zielport 23 ist
und der Quellport größer als 1024. ❏ Jedes eingehende Paket muß das ACK-Flag gesetzt haben, vom Port 23 kom-
men und einen Port größer 1024 ansprechen.
4.2.2
Dynamische Paketfilterung
Im Gegensatz zur statischen Paketfilterung ist die dynamische Paketfilterung zustandsabhängig. In unserem Beispiel mit Telnet könnte das so aussehen: ❏ Der Paketfilter erlaubt zunächst nur ausgehende Pakete mit Quellports über
1024 zum Zielport 23 bei gleichzeitig gesetztem SYN-Flag. Ausgehende Pakete ohne gesetztes SYN (mit ACK etwa) sind nicht erlaubt, eingehende Pakete vollständig untersagt. ❏ Beim Verbindungsaufbau (ausgehendes Paket mit SYN-Flag) merkt sich der
Paketfilter den Zustand und gleichzeitig auch den Quellport, zum Beispiel 1099. ❏ Ausgehende Pakete sind jetzt vom Quellport 1099 zum Zielport 23 erlaubt,
eingehende Pakete vom Quellport 23 zum Zielport 1099, bei beiden Richtungen muß jeweils das ACK-Flag gesetzt sein. ❏ Beim Verbindungsabbau löscht der Paketfilter wieder die Filterregeln, so
daß wieder nur ausgehende, initiierende Verbindungen mit gesetztem SYNFlag erlaubt sind und eingehende Verbindungen vollständig untersagt.
47
4 Grundlagen des Firewalldesigns
Eine häufige Anwendung von dynamischen Paketfiltern findet man bei UDPVerbindungen. Da es bei UDP keinen Zustand in der Verbindung gibt, läßt sich mit statischen Paketfiltern nicht unterscheiden, ob bei von außen eintreffenden Paketen die Initiierung der Verbindung ursprünglich von innen ausging (und damit erwünscht ist), oder ob es sich um eine Initiierung von außen handelt (die vermieden werden soll). Ein dynamischer Paketfilter hilft hier weiter: ❏ Zunächst ist von außen keine Verbindung erlaubt. ❏ Werden von innen Pakete nach außen versandt, setzt der dynamische Pa-
ketfilter eine Filterregel, die es erlaubt, Anwortpakete von außen an die ursprüngliche Sendeadresse/den ursprünglichen Sendeport zu schicken. Andere Ziele (Adresse, Port) bleiben für Pakete von außen nach innen verschlossen. ❏ Da es bei UDP keinen Verbindungsabbau gibt, muß die Verbindung eine
Zeitlang offen bleiben. Nach einem gesetzten Timeout (kein Paket, passend zur gesetzten Filterregel, passiert mehr den Paketfilter) wird die Filterregel wieder gelöscht. Ein dynamischer Paketfilter bleibt aber ein Paketfilter, d. h., er entscheidet nach Routinginformationen, also nach Wegstrecken, nicht nach den Inhalten der Pakete. Es gibt zwar bei einigen kommerziellen Firewallsystemen noch Erweiterungen in Richtung auf benutzerorientierte Paketfilterung, die zusätzliche Benutzerauthentifikation vorsehen. Hier verwischen dann aber die Grenzen zwischen Paketfiltern und Proxies, die im nachfolgenden vorgestellt werden. Nachteil einer dynamischen Paketfilterung ist eine sehr schwierige Skalierbarkeit. Ohne aufwendige Maßnahmen kann man die dynamische Paketfilterung nicht auf mehrere Rechner verteilen, da normalerweise ein zweiter Paketfilter nichts über den Zustand des ersten Paketfilters weiß. Dynamische Paketfilterung über den Linuxkernel ist mit Einführung der Kernelversion 2.4 erstmals möglich (ohne auf aufgesetzte Produkte näher einzugehen).
4.3 Proxy-Systeme Ist aus Sicherheitsgründen eine direkte Verbindung eines Arbeitsplatzrechners zum Internet nicht erwünscht, muß die gewünschte Verbindung von einem anderen Host aus hergestellt werden. Eine Lösung könnte sein, einen zentralen Rechner aufzustellen, der Verbindung zum Internet hat und auf dem sich die User einloggen können. Die User müßten dann die Internetverbindung von diesem Host aus durchführen. Möglicherweise haben aber dann sehr viele User
48
4.3 Proxy-Systeme
Zugang zu einem Host, der auch vom Internet aus direkt erreichbar ist. Je mehr aktive User ein Host hat, desto weniger kann man unterscheiden, ob sich ein User ordnungsgemäß eingeloggt hat, oder ob sich ggf. ein Eindringling vom Internet aus Zugang verschafft hat. Eine andere Lösung ist ein sogenannter Proxy. Die deutsche Übersetzung „Stellvertreter“ beschreibt dessen Funktionalität schon sehr genau. Der Arbeitsplatzrechner ohne Internetzugang baut die Verbindung zu einem Host auf, der Internetzugang hat. Er teilt diesem seinen Verbindungswunsch mit. Der Stellvertreter überprüft gegebenenfalls die Anfrage und leitet sie an den Internetserver weiter. Für den User ist wichtig dabei, daß er auf dem Proxy keinen Account benötigt und die Verbindung von seinem Arbeitsplatzrechner aus durchführen kann. Für den Internetserver sieht die Verbindung so aus, als ob der Stellvertreter die Verbindung aufgebaut hätte. Für den Client sieht die Verbindung so aus, als hätte er die Verbindung direkt zum Internetserver aufgebaut. In 4.7 ist diese Dreiecksbeziehung schematisch dargestellt. Anders als ein Paketfilter sieht der Proxy auch den Inhalt der Verbindung, die übertragenen Kommandos und Daten. Ein Proxy, der für einen speziellen Internetdienst geschrieben wurde, kann einer Verbindung wesentlich mehr Informationen entnehmen als ein Paketfilter. Ein Mail-Proxy oder ein FTP-Proxy kennt zum Beispiel die Kommandos des zugrunde liegenden Dienstes und kann einzelne Befehle erlauben oder ablehnen. Ein solcher Mail-Proxy ist zum Beispiel smap, der auf die bei älteren Versionen von sendmail so gefürchteten SMTPKommandos wie wiz, debug und kill erst gar nicht reagiert (mehr zum Thema Mail im Abschnitt 7.1.1.
Abbildung 4.7: Wirkungsweise eines Proxy (Stellvertreters)
49
4 Grundlagen des Firewalldesigns
Man kann mehrere Arten von Proxies unterscheiden: ❏ Implizite Proxies: Manche Internetdienste besitzen von Hause aus Proxy-
Funktionalität. Dazu gehören alle Store-and-Forward-Dienste wie zum Beispiel SMTP. Aber auch ein DNS-Server oder ein HTTP-Server sind implizite Proxies. ❏ Veränderte Verfahren: Ein Benutzer meldet sich beim Proxy an und führt erst
über einen zweiten Schritt den eigentlichen Verbindungsaufbau durch, d. h., der Benutzer muß sein Anmeldeverhalten dem Proxy entsprechend verändern. Steht die Verbindung einmal, läuft die Verbindung scheinbar wie gewohnt zwischem dem Arbeitsplatzrechner und dem Internet-Server. Der Vorteil dabei ist, daß am Arbeitsplatz die bisher gewohnte Software eingesetzt werden kann, nachteilig ist vielleicht, daß der User erst die neuen Abläufe kennenlernen und sich umstellen muß. ❏ Veränderte Clients: Mit modifizierten Clients kann eine Verbindung über
einen Proxy so ablaufen, als gäbe es eine direkte Verbindung zum InternetServer. Die Kommunikation mit dem Proxy bleibt dem User vollständig verborgen. Neuere Clientsoftware wie zum Beispiel Web-Browser haben solche angepaßten Kommunikationsmöglichkeiten bereits eingebaut. Von manchen Internetprovidern wird entsprechende Zugangssoftware bereits so ausgeliefert, daß der Benutzer gar nicht merkt, daß die Verbindung über einen Proxy läuft. Für ältere Software, die im Source-Code vorliegt, gibt es Bibliotheken wie SOCKS (6.2), die eine nachträgliche Proxytauglichkeit herstellen können. Application Level Gateway und Circuit Level Gateway In der Literatur findet man für Proxies auch die Begriffe „Application Level Gateway“ oder „Circuit Level Gateway“. Mit dem Application Level Gateway wird in der Regel ein Proxy beschrieben, der ausschließlich für einen Internetdienst konstruiert wurde. Circuit Level Gateway soll einen generischen Proxy für eine Reihe von Internetdiensten bezeichnen, die sich alle ähnlich verhalten und identisch über einen Proxy geführt werden können. Aber auch manche Application Level Proxies besitzen generische Eigenschaften, so daß sie mit kleinen Änderungen am Source Code auch als generische Proxies funktionieren könnten. Die Begriffe „Application Level Gateway“ und „Circuit Level Gateway“ sind etwas schwerfällig und eher verwirrend als hilfreich, deshalb soll in diesem Buch zwischen „generischen“ Proxies (diensteunabhängig, kennen die übertragenen Inhalte nicht) und „applikationsspezifischen“ Proxies (kennen die dienstespezifischen Protokolle und können Entscheidungen aufgrund der übertragenene Inhalte treffen) gesprochen werden.
50
4.4 Firewallumgebungen
Proxies erfüllen nur ihren Zweck, wenn man sie nicht umgehen kann. Um zu verhindern, daß dies geschieht, muß man zusätzliche Maßnahmen wie Paketfilter und/oder „Dual Homed Hosts“ implementieren. Was es damit und anderen Maßnahmen auf sich hat, folgt im nächsten Abschnitt. Proxies sind hostbasiert, deshalb muß der Host, auf dem sich der Proxy befindet, in jedem Falle abgesichert sein (siehe auch Abschnitt 8.1).
4.4 Firewallumgebungen Proxies und Paketfilter bilden die funktionalen Grundbausteine eines Firewalls. Alle weiteren, hier vorgestellten Mechanismen sind spezielle Anordnungen, wie Proxies und Paketfilter eingesetzt werden können. Die Grundfunktionen sind und bleiben aber Paketfilter und Proxies. Paketfilter routen die Pakete nach bestimmten Regeln, erfüllen also immer auch die Funktion eines Routers. Um deutlich herauszustellen, daß es sich hier immer um Router mit Paketfilterfunktion handelt, verwenden wir nachfolgend den Begriff Filter.
4.4.1
Entmilitarisierte Zone: das Grenznetz
Eine „entmilitarisierte Zone“ (englisch: Demilitarized Zone, DMZ) bezeichnet ein eigenes Subnetz, das zwischen dem Internet und dem zu schützenden Netzwerk liegt. Ein solches Grenznetz ist der ideale Ort für Dienste, die zum Beispiel vom Internet aus erreichbar sein sollen, ohne daß Benutzern solcher Dienste gleich Zugriff auf das zu schützende Netzwerk zu gewähren ist. Das Grenznetz ist ebenfalls gut geeignet für die Ansiedlung von Proxies, um zum Beispiel kontrollierten Zugriff aus dem privaten Netzwerkbereich auf das Internet zuzulassen. In Abbildung 4.8 wird ein Grenznetz schematisch dargestellt. Eine ebenfalls in der Literatur gebräuchliche Bezeichnung ist „Screened Subnet“. Ein Grenznetz verfügt über einen äußeren Filter, der das Grenznetz vom Internet trennt, und einen inneren Filter, der wiederum den Übergang zum lokalen Netzwerk darstellt. Die Aufteilung auf zwei Router macht gegenüber einem einfachen Paketfilter nur dann Sinn, wenn auf den beiden Routern unterschiedliche Filterregeln zum Einsatz kommen. Das wiederum funktioniert nur, wenn sich innerhalb des Grenznetzes ein weiterer Host befindet, der weitere Routing- oder Proxy-Funktionalitäten übernimmt.
51
4 Grundlagen des Firewalldesigns
Abbildung 4.8: Die Entmilitarisierte Zone: Grenznetz
4.4.2
Bastion Hosts
Ein Server, der im Grenznetz angesiedelt ist und dort Internetdienste anbietet, wird oft auch als „Bastion Host“ bezeichnet. In einer solchen Konfiguration hat der äußere Filter die Aufgabe, ausschließlich Pakete von und zum Bastion Host durchzulassen, alle anderen Wege werden versperrt. Damit ist dann der Bastion Host für einen Eindringling das vorrangige Angriffsziel. Der Begriff „Bastion“ steht für eine mittelalterliche Trutzburg, die nur über eine Zugbrücke (äußerer Filter) erreichbar ist und über besonders starke Mauern verfügt, um Angriffen möglichst lange standzuhalten. Wie in diesem Bild ist der Bastion Host gegen externe Angriffe stark zu machen, zu „härten“. In der Praxis bedeutet das, daß der Bastion Host in sich gesichert werden muß, um möglichst wenig Angriffsfläche zu bieten. In bezug auf Betriebssystempatches und -versionen, die erkannte Bugs möglichst schnell beheben sollen, sollte der Bastion Host immer auf dem neuesten Stand sein. Alle nicht benötigten Dienste sind abzustellen, alle anderen so abzusichern, daß ein Mißbrauch ausgeschlossen werden kann. Der Bastion Host darf sich nicht ausschließlich auf ein fehlerfreies Funktionieren der Filter verlassen. Die Einbindung eines Bastion Host zeigt Abbildung 4.9. Der äußere Filter ist dabei so konfiguriert, daß er nur Pakete von und zum Bastion Host zuläßt. Der innere Filter läßt ebenfalls nur Pakete von und zum Bastion Host zu. Jegliche Verbindung zwischen dem lokalen Netzwerk und dem Internet muß so über den
52
4.4 Firewallumgebungen
Abbildung 4.9: Einsatz eines Bastion Host im Grenznetz
Bastion Host laufen. Auf dem Bastion Host kann jetzt ein Proxy installiert werden. Die Vorteile dieser Konfiguration liegen in der Flexibilität. Internetdienste, die über einen Proxy eingesetzt werden sollen, können kombiniert werden mit Internetdiensten, die ohne Proxy aus dem lokalen Netzwerk Zugriff auf das Internet haben sollen. Während zum Beispiel Web-Zugriffe aus dem lokalen Netzwerk ausschließlich über einen Proxy auf dem Bastion Host möglich sein sollen, könnte man Secure Shell Logins vom lokalen Netzwerk heraus zu Servern im Internet auch parallel dazu direkt erlauben. Ebenfalls wäre es denkbar, weitere Proxies/Internetdienste nicht auf dem vorhandenen Bastion Host, sondern auf weiteren, zusätzlichen Bastion Hosts anzubieten. Der Konfiguration der Filter kommt hier größte Bedeutung zu. Eine Fehlkonfiguration kann dazu führen, daß die eingesetzten Proxies umgangen werden und dadurch Sicherheitslücken entstehen. Einen Bastion Host, der nur über ein Netzwerk-Interface verfügt, über das sowohl der Verkehr zum lokalen Netzwerk als auch der Verkehr zum Internet erfolgt, nennt man auch „Single Homed Host“ . In Abbildung 4.9 ist der Bastion Host in genau einem Netzwerk „zu Hause“. Aufgrund der Flexibilität ist der Bastion Host als Single Homed Host im Grenznetz eine sehr häufig anzutreffende Firewall-Konfiguration.
53
4 Grundlagen des Firewalldesigns
4.4.3
Dual Homed Hosts
Die im vorangegangenen Abschnitt gezeigte Anordnung läßt sich noch etwas abändern: das Grenznetz wird aufgetrennt, der Bastion Host bekommt zwei Netzwerk-Interfaces und wird in den Weg zwischen äußeren und inneren Filter geschaltet. Eine solche Dual Homed Host-Konfiguration zeigt Abbildung 4.10. Wenn man jetzt auf dem Bastion Host dafür sorgt, daß jegliches Routing ganz abgeschaltet wird, sind Verbindungen nur noch ausschließlich über Proxies möglich. In dieser Anordnung erhält man die größtmögliche Sicherheit, allerdings auch die größtmöglichen Einschränkungen bei der Internetnutzung. Für alle Dienste, die erlaubt sein sollen, ist ein Proxy notwendig. Nicht alle Internetdienste sind Proxy-fähig. talk ist zum Beispiel zu kompliziert, um den Dienst über einen Proxy vernünftig abzubilden. Mit etwas mehr Aufwand an Hardware ist die Verteilung verschiedener Proxies auf mehrere Dual Homed Hosts möglich. Diese Rechner müssen dann parallel geschaltet werden. Das ist zwar sehr aufwendig, kann aber in bestimmten Fällen durchaus sinnvoll sein, etwa wenn ein sehr hohes Datenaufkommen zu bewältigen ist. Bricht ein Bastion Host mit einem Dienst unter der Last zusammen, bleiben die anderen Bastion Hosts davon unberührt.
Abbildung 4.10: Einsatz eines Bastion Host als Dual Homed Host
54
4.5 Private IP-Adressen
4.5 Private IP-Adressen Während es in größeren Organisationen häufig offiziell registrierte IP-Adressen gibt (man spricht auch von „Public Networks“), trifft man immer häufiger auf sogenannte private Netzwerkadressen („Private Networks“). Private Netzwerkadressen können von jedermann frei ohne vorherige Registrierung verwendet werden. IP-Adressen aus diesem Bereich werden im Internet nicht weitergeleitet. Die privaten Adreßbereiche wurden eingeführt, da der Adreßraum knapp wurde und absehbar war, daß nicht mehr jedem Rechner eine eigene, eindeutige IP-Adresse zugeordnet werden konnte. Es gibt zwei Request For Comments (RFC), mit dem Ziel, dem Mangel an IP-Adressen abzuhelfen. Der eine beschreibt die Einführung der Private Networks (RFC 1597), der andere definiert die Erweiterung des IP-Adreßraumes von 4 Byte auf 16 Byte (RFC 2460); diese IP-Version wird allgemein auch IPv6 genannt. Auf IPv6 wird hier allerdings nicht näher eingegangen. Welche Netzwerkbereiche in RFC 1597 für private Nutzung definiert wurden, zeigt Tabelle 4.1. Private IP-Adreßbereiche kann man nicht direkt mit dem Internet koppeln: TCP/IP-Verkehr ist immer eine bidirektionale Angelegenheit, private Ziel-Adressen werden aber verworfen, d. h., eine solche Adresse wird von Internet-Providern schlichtweg ignoriert. Versucht man also, aus einem privaten Netzwerk heraus einen Host im Internet zu erreichen, kommen die Pakete dort bestimmungsgemäß an (die Internet-Adresse ist ja eine gültige IP-Adresse), aber die Antwortpakete besitzen eine private Ziel-Adresse und landen im Nirwana. Man benötigt also trotz freier IP-Adressenwahl im internen Bereich wenigstens eine offizielle IP-Adresse, um am Internet teilnehmen zu können. Wegen der Knappheit an verfügbaren IP-Adressen vergeben viele Provider bei Wählzugängen solche offiziellen Adressen dynamisch aus einem Pool heraus. Man hat dann bei jedem Einwählvorgang möglicherweise eine andere Nummer. Es gibt mehrere Möglichkeiten, Private Networks an das Internet anzuschließen. Eine Verbindung wird nur von dem Host aufgebaut, der eine offiziell registrierte IP-Adresse besitzt, und alle internen Rechner nehmen nur direkte Verbindung
mit dem Host auf, der diese offizielle Adresse besitzt und alle Anfragen übersetzt. Das ist das Einsatzgebiet eines herkömmlichen Proxy. Eine Variante davon ist der transparente Proxy , der die Verbindungen der Clients abfängt und umleitet. Oder die ausgehenden Pakete werden so angepaßt, daß als Absender die offizielle IP-Adresse eingesetzt wird: Masquerading. Sowohl Masquerading als auch transparente Proxies benötigen einen Mechanismus, der sich „Network Address Translation“ nennt. Dazu mehr im Abschnitt 4.6.
4.5.1
Herkömmliche Proxies
Ein herkömmlicher Proxy (im Unterschied zu transparenten Proxies) läuft direkt auf dem Firewall (oder auch auf einem Host im Firewall, falls der Firewall aus mehr als nur einem Rechner besteht). Wenn der Host, auf dem der Proxy läuft, selbst über eine gültige IP-Adresse verfügt, sind keine besonderen Maßnahmen (wie zum Beispiel Network Address Translation) für die Anbindung eines privaten Netzwerks notwendig. Der Client baut nur Verbindungen zum Proxy auf, der im internen Netzwerk auch über eine interne Netzwerkadresse verfügt, der Proxy unterhält selbst die Verbindung zum Server im Internet (siehe auch Abschnitt 4.3). Vorteile eines herkömmlichen Proxy (Dual Homed oder Firewall in einem Host): ❏ DNS muß lokal nicht konfiguriert werden, sondern nur für den Proxy zur
Verfügung stehen. ❏ Es ist nur eine begrenzte Anzahl offizieller IP-Adressen nötig.
Nachteile des herkömmlichen Proxy: ❏ Die Clients müssen Proxy-tauglich sein und entsprechend konfiguriert wer-
den. ❏ Internetverbindungen sind nur möglich, wenn für die gewünschten Dienste
auch ein Proxy zur Verfügung steht. ❏ Für jeden eingesetzen Host im Firewall bis zum Proxy ist eine eigene IP-
Adresse notwendig (z. B. DMZ mit zwei Filtern und einem Bastion Host: mindestens 2 IP-Adressen). Herkömmliche Proxies sind also nur einsetzbar, wenn eine ausreichende Anzahl von offiziellen IP-Adressen vorhanden ist.
4.6 Network Address Translation „Network Address Translation“, kurz NAT, bedeutet nichts anderes als die Manipulation von IP-Source- und IP-Destination-Adresse. Da NAT auch überall dort zum Einsatz kommt, wo Netzwerke an das Internet angeschlossen werden, trifft man in den Einsatzbereichen von Firewalls fast immer auch auf NAT.
56
4.6 Network Address Translation
Gründe für den Einsatz von NAT sind unterschiedlich: oft reichen die offiziell registrierten IP-Adressen nicht aus, um alle Rechner an das Internet anzuschließen, oder bei Dial-In-Verbindungen wird überhaupt nur eine einzige offizielle IP-Adresse vom Provider zur Verfügung gestellt. Ein anderer Grund könnte Load Balancing sein, bei dem man eintreffende Verbindungen auf unterschiedliche Rechner verteilen möchte. Oder ein transparenter Proxy, bei dem die IPVerbindung abgefangen und auf einen lokalen Port umgebogen wird.
4.6.1
IP-Masquerading
„Masquerading“ ist der Begriff, der sich in der Linux-Welt eingebürgert hat. Etwas allgemeiner ist der Begriff „Network Address Translation“ (NAT), der auch außerhalb der IP-Welt den Vorgang beschreibt: den Austausch von NetzwerkAdressen. Mit den Begriffen NAT und Masquerading muß man etwas aufpassen: mit Kernel 2.4 ist Masquerading jetzt Source Network Address Translation (SNAT), und Masquerading ist dann ein Spezialfall von SNAT für dynamische IPAdressen. Da es hier aber nicht um eine spezielle Kernelimplementierung geht, sondern um das prinzipielle Verfahren, behalten wir den Begriff Masquerading bei. Die exakte technische Unterscheidung folgt dann im Abschnitt 5.3. Abbildung 4.11 zeigt ein Beispiel für eine Anbindung eines privaten Netzwerks (hier 192.168.1.0/255.255.255.0) über eine Wählverbindung an das Internet.
Abbildung 4.11: Anbindung eines privaten Netzwerkes an das Internet
57
4 Grundlagen des Firewalldesigns
Der Client-Browser versucht vom Client aus eine direkte Verbindung zum Server aufzubauen. Als Default Gateway ist der Firewall eingetragen. Würde jetzt die private IP-Adresse des Absenders in das Internet weitergeleitet, würde ein Paket zwar beim Server ankommen. Das Antwortpaket dagegen ist an eine private Adresse gerichtet, und diese werden vom Provider ignoriert. Es kommt nichts zurück. Ist der Firewall so eingestellt, daß er auf alle Pakete mit internen Adressen, die in das Internet wollen, Masquerading durchführt, ersetzt er die Absenderadresse durch seine eigene IP-Adresse. Er maskiert (= verdeckt) sozusagen den Absender. Wenn vom Server aus dem Internet jetzt Pakete zurückkommen, muß der Firewall wissen, daß diese nicht für ihn selbst sind, sondern an den ursprünglichen Client weitergeleitet werden müssen. Dazu muß sich der Firewall in eine Tabelle die durchgeführten Ersetzungen schreiben. Für den Server sieht die Verbindung so aus, als käme diese direkt vom Firewall. Von der Anwesenheit des lokalen Host bemerkt er nichts. Vorteile von Masquerading: ❏ Es wird nur eine offizielle IP-Adresse benötigt. ❏ Das interne Netzwerk wird versteckt. Von außen sind nur die Verbindungen
möglich, die von innen geöffnet wurden. Es wird keine Information über die interne Netzwerkstruktur von außen sichtbar. ❏ Am Client sind keine Änderungen notwendig. Für ihn ist die Verbindung
völlig transparent. Nachteile von Masquerading: ❏ Verbindungen von außen nach innen sind nur eingeschränkt möglich. ❏ Nicht alle Dienste sind 100 % Masquerading-tauglich. Auf dem Firewall
müssen dann spezielle Module nachhelfen (z. B. ping, FTP, IRC), vor allem dann, wenn ein besonderer Rückkanal vom Server geöffnet wird. ❏ DNS muß im lokalen Netzwerk konfiguriert sein.
Wie Masquerading mit Linux eingerichtet werden kann, wird im Abschnitt 5.3.2 beschrieben.
4.6.2
Transparente Proxies
Ein transparenter Proxy ist zunächst einmal ein ganz normaler Proxy. Der Unterschied: der Client weiß nichts von seiner Existenz, er versucht, eine ganz normale Verbindung zum Server aufzubauen. Ein transparenter Proxy fängt einfach die Verbindung, die der Client zum Server aufbaut, am Firewall ab und leitet diese lokal auf den Proxy um. Im Gegensatz zu anderen Proxies ist weder ein verän-
58
4.6 Network Address Translation
dertes Verfahren noch ein entsprechend konfigurierter, Proxy-tauglicher Client erforderlich. Beispiel: Am Firewall ist ein Proxy installiert, der auf dem Port 8080 lauscht. Ein Client versucht, zu unserem Internetserver eine Verbindung aufzubauen mit Zielport 80. Der Firewall leitet jetzt auf Kernelebene die Verbindung um auf den lokalen Port 8080. Der lokale Proxy muß allerdings für transparente Dienste tauglich sein, da jetzt die Zieladresse des Pakets der eigentliche Internetserver ist, während bei herkömmlichen Proxies die IP-Zieladresse die des Proxy ist (die IPAdresse des Servers wird dann im Datenbereich übertragen). Vorteile eines transparenten Proxy: ❏ Keine Änderung am Client notwendig. ❏ Ohne Änderung am Client kann zwischen (transparentem) Proxy und Mas-
querading gewechselt werden, auch diensteabhängig. Nachteile eines transparenten Proxy: ❏ DNS muß im lokalen Netzwerk trotz Proxy konfiguriert sein. ❏ Proxy muß für transparente Benutzung geeignet sein. ❏ Für jeden Dienst ist ein Proxy erforderlich.
4.6.3
Load Balancing
Unter „Load Balancing“ versteht man die Verteilung einer bestimmten Netzwerklast auf mehrere Rechner. Bekannt geworden ist Load Balancing im Internet unter anderem durch sogenannte Server-Farmen, vor allem für Webserver, wo große eCommerce-Anbieter aus Gründen der Performance und der Ausfallsicherheit viele identische Webserver einsetzen. Der Internet-Nutzer wird dann jeweils auf den Host weitergeleitet, der die beste Performance bietet (am wenigsten ausgelastet ist, oder nahe am Einwahlpunkt des Anwenders steht). Load Balancing kann aber auch anders aussehen: hinter einer IP-Adresse können, abhängig vom gewünschten Dienst (= Port), unterschiedliche Server stehen, auf die dann der eingehende Datenverkehr verteilt wird. Linux bietet eine einfache Möglichkeit, denn hier können einzelne Verbindungen der Reihe nach auf unterschiedliche Rechner verteilt werden. Man spricht hier eher von „Load Sharing“, da eine Verteilung abhängig von der zur Zeit aktiven Last nicht möglich ist.
59
4 Grundlagen des Firewalldesigns
4.7 Zusammenfassung Das Internet ist das Netz der Netze, das aus dem Zusammenschluß aller Einzelnetze entsteht. Gemeinsame Basis für die Kommunikation ist das InternetProtokoll, kurz IP. IP ist ein Protokoll des Network Layer (Ebene 3 im OSI-Modell). Zu TCP/IP gehören weitere Protokolle in der Transportschicht (Ebene 4 im OSIModell). Firewalls sind ein Gesamtkonzept, welches das Zusammenspiel von Paketfiltern und Proxies regelt. Ein Firewall muß nicht unbedingt aus einem einzigen Host oder einem einzigen Stück Hardware bestehen. Im Firewall beschränken Paketfilter den Netzwerkverkehr auf OSI-Ebene 3 und 4, während Proxies zum Teil auch auf Anwendungsebene unter Kenntnis der Anwendungsprotokolle operieren. Mit der Anbindung an das Internet und damit auch mit der Firewall-Thematik verbunden ist Network Address Translation (NAT). Ein immer wiederkehrendes Problem ist der begrenzte IP-Adreßraum – es stehen fast immer zu wenig IPAdressen zur Verfügung – und dadurch bedingt der Einsatz von privaten Netzwerkadressen. Neben Masquerading können mit NAT aber auch andere Anforderungen wie Load Sharing und Transparent Proxying abgedeckt werden.
60
Kapitel 5 Paketfilterung und Network Address Translation Die klassische Paketfilterung entscheidet über den Verbleib der Pakete, verändert jedoch nicht deren Inhalte. Mitunter setzen Paketfilter fragmentierte Pakete wieder zusammen, doch auch hier ändert sich der Inhalt nicht. Network Address Translation (NAT) – der Name sagt es ja schon – verändert dagegen Adressen. Im Linux Kernel sind jedoch Network Address Translation und Paketfilterung sehr nahe beieinander implementiert und werden auch mit denselben Werkzeugen konfiguriert. Die Paketfilterung unter Linux erfolgt bereits im Kernel selbst. Im Vergleich zu Softwarepaketen, die oberhalb des Kernel arbeiten und als eigenständige Prozesse laufen, die ihrerseits wiederum mit dem Kernel kommunizieren müssen, ist das von Vorteil. Einem potentiellen Angreifer bieten sich dadurch weniger Möglichkeiten zur Manipulation. Firewallsoftware, die oberhalb der Betriebssystemebene als normales Programm läuft, kann noch so sicher implementiert sein. Wenn das Betriebssystem selbst bereits Mängel und Sicherheitslücken aufweist, bleibt es angreifbar. Ein Nachteil ist sicherlich, daß eine in den Kernel integrierte Lösung schwerlich auf andere Betriebssysteme portiert werden kann. Um mit Linux Pakete filtern zu können, benötigt man zwei Dinge: ❏ Einen entsprechend vorbereiteten Kernel, der neben der Firewall-Unterstüt-
zung auch andere Sicherheitsfeatures und Routing unterstützen soll. ❏ Ein Werkzeug, mit dem man die Regeln für die Paketfilterung auf Kernel-
ebene setzen und bearbeiten kann. Gerade wegen der Kernelnähe muß man für jede Kernelversion das richtige Werkzeug wählen: iptables für Kernel 2.4, ipchains für Kernel 2.2, und ipfwadm für Kernel 2.0.
61
5 Paketfilterung und Network Address Translation
Die Codebasis in Kernelversion 2.4 wurde gründlich überholt und „ausgemistet“. Zwar werden die Mechanismen von ipchains und ipfwadm durch ladbare Module auch noch in Kernel 2.4 unterstützt, wegen des besseren Konzeptes und der Zukunftssicherheit werden wir hier jedoch nur auf Kernel 2.4 und damit iptables eingehen. Die unterschiedlichen Mechanismen dürfen auf keinen Fall miteinander gemischt werden. Wer mit iptables arbeitet, darf nicht das Modul für ipchains laden.
5.1 Kernel vorbereiten Um von den Filterfähigkeiten des Kernel Gebrauch machen zu können, müssen die zum Firewalling gehörenden Teile einkompiliert sein. Mit # make menuconfig
kann die Kernelkonfiguration verändert werden. Neben der generellen Netzwerk-Unterstützung unter General setup werden folgende Einstellungen aus dem Menü Networking options benötigt: <*> Packet socket [*] Network packet filtering (replaces ipchains) [*] Network packet filtering debugging (NEW) ... [*] TCP/IP networking ... [*] IP: TCP syncookie support (disabled per default) IP: Netfilter Configuration --->
Das Submenu Netfilter Configuration faßt alle für die Netfilter-Architektur möglichen Parameter zusammen. <M> <M> <M> <M> <M> <M> <M> <M> <M> <M> <M> <M> <M> <M>
62
Connection tracking (required for masq/NAT) (NEW) FTP protocol support (NEW) IP tables support (required for filtering/masq/NAT) (NEW) limit match support (NEW) MAC address match support (NEW) netfilter MARK match support (NEW) Multiple port match support (NEW) TOS match support (NEW) Connection state match support (NEW) Packet filtering (NEW) REJECT target support (NEW) Full NAT (NEW) MASQUERADE target support (NEW) REDIRECT target support (NEW)
5.1 Kernel vorbereiten
<M> Packet mangling (NEW) <M> TOS target support (NEW) <M> MARK target support (NEW) <M> LOG target support (NEW) < > ipchains (2.2-style) support (NEW) < > ipfwadm (2.0-style) support (NEW)
Die einzelnen Einstellungen werden in /usr/src/linux/Documentation/Configure.help näher beschrieben. Diese zu jedem Eintrag entsprechende Hilfe erhält man auch im Konfigurationsmenü über die Auswahl Help. Die wesentlichen Einstellungen daraus sind: ❏ Network packet filtering
Schaltet grundsätzlich das Netfilter Framework ein. Ist nötig, sobald der Rechner als Paketfilter arbeiten soll oder NAT durchgeführt werden muß. ❏ IP: TCP syncookie support
ist eine Abwehrmaßnahme gegen SYN flooding, eine Denial-of-Service-Attacke. Auf dem äußeren Router/Filter unbedingt verwenden. Allerdings muß der SYN-Cookie Support nach dem Booten aktiviert werden: echo "1" > /proc/sys/net/ipv4/tcp_syncookies ❏ IP tables support (required for filtering/masq/NAT)
Der eigentliche Kern der Paket-Manipulation im Kernel 2.4. Darunter finden sich eine Reihe von Funktionalitäten als einzelne Module implementiert. Im Gegensatz zu früheren Kernels sind auch schon nichttriviale Targets wie REJECT, MASQUERADE und REDIRECT sowie Logging in eigene Module ausgelagert worden. Das hält den eigentlichen Kernelcode klein und übersichtlich und erleichtert die Erweiterung. Unter dem Punkt IP tables support werden sich bei Weiterentwicklung des Kernel sicher immer wieder Veränderungen ergeben. ❏ Connection tracking (required for masq/NAT)
In einer eigenen Tabelle werden ausgehende Pakete und Verbindungen gelistet, um eingehende Pakete besser einer bestehenden Verbindung zuordnen zu können. Das ermöglicht erst NAT, erlaubt aber auch eine dynamische Paketfilterung (Modul Connection state match support). Bereits während der Entwicklung des 2.2er Kernel wurden verschiedene, zunächst einkompilierte Flags in das /proc-Filesystem aufgenommen und können nun während der Laufzeit des Kernel konfiguriert werden. Da viele dieser Einstellungen nicht direkt unter den Oberbegriff „Paketfilter“ fallen, aber dennoch unterstützend auf einem Firewall eingesetzt werden können und auch sollen,
63
5 Paketfilterung und Network Address Translation
sind die Optionen zur Runtime-Konfiguration im Anhang B gesondert zusammengefaßt.
5.2 Paketfilterung mit iptables Der Kernel arbeitet in der Paketfiltertabelle mit Listen von Regeln. Diese Listen bezeichnet man als „Firewall Chain“, oder auch nur einfach „Chain“. Eine Firewall Chain ist ein zusammengehörender Satz von Regeln, die nacheinander abgearbeitet werden. Im folgenden soll für den englischen Begriff „Chain“ die Bezeichnung „Regelkette“ verwendet werden. Permanent (d. h. bereits beim Systemstart) vorhanden sind drei Regelketten: die INPUT Chain, die FORWARD Chain und die OUTPUT Chain, vorausgesetzt, Firewalling ist in den Kernel einkompiliert. Wie Glieder in einer Kette können Filterregeln jederzeit in eine Regelkette eingefügt oder aus dieser entfernt werden. Mit dem Tool iptables ist es auch möglich, zur leichteren Verwaltung und besseren Lesbarkeit eigene Regelketten zu erstellen und zu bearbeiten. Wenn ein Paket über ein Interface hereinkommt (das kann eine Ethernetkarte, aber auch jedes andere Interface wie ISDN oder das Loopback-Interface sein), durchläuft es einen vorgezeichneten Weg, der aus mehreren Regelketten und einigen weiteren Schritten besteht (siehe Abschnitt 5.2.1). In jeder Regelkette werden die einzelnen Regeln der Reihe nach abgearbeitet und geprüft, ob eine Regel auf das aktuelle Paket zutrifft oder nicht. Trifft eine Regel auf das Paket zu, wird – vereinfacht gesagt – das Paket akzeptiert oder abgelehnt. An dieser Stelle wird dann die jeweilige Kette verlassen, es sei denn, die Regel dient ausschließlich der Protokollierung. Deshalb ist die Reihenfolge bei der realen Implementierung von Regelketten äußerst wichtig: trifft eine allgemeinere Regel bereits weiter oben in der Kette zu, kommt eine möglicherweise speziell für einen besonderen Fall gedachte Regel gar nicht mehr zur Anwendung.
5.2.1
Ablaufdiagramm des Linux-Kernelfilters
Der Kernel untersucht zunächst das eingehende Paket auf die Zieladresse, um zu entscheiden, wohin das Paket geliefert werden soll (Routing Decision, siehe Abbildung 5.1). Ist es für den lokalen Host bestimmt, wird das Paket an die INPUT Chain weitergeleitet. Wenn das Paket dort durchgelassen wird, landet es bei einem lokalen Prozeß. Ist das Paket nicht für den lokalen Rechner bestimmt, wird das Paket unter zwei Bedingungen an die FORWARD Chain weitergereicht: der Kernel muß prinzipiell Forwarding eingeschaltet haben, und der Kernel muß wissen, wie das Paket geroutet werden soll (zum Paket passender Eintrag in der Routing Tabelle). Treffen
64
5.2 Paketfilterung mit iptables
Abbildung 5.1: Grundschema der Firewall-Regelketten (Firewall Chains) im Kernel 2.4
beide Bedingungen zu, geht das Paket in die FORWARD Chain, und wird es dort durchgelassen, verläßt das Paket wieder den Rechner. Trifft mindestens eine der beiden Bedingungen nicht zu, wird das Paket einfach verworfen. Natürlich kann der Rechner auch selbst Pakete versenden. Diese werden in der OUTPUT Chain geprüft und – falls Prüfung bestanden – direkt an das OutputInterface weitergereicht. Gegenüber der Verwendung von ipchains hat sich Forwarding auch für den Anwender deutlich vereinfacht (die anderen Verbesserungen sind nicht ganz so transparent). Für ein Forwarding wird jetzt nur noch die FORWARD Chain durchlaufen, vorher waren alle drei permanenten Regelketten betroffen. Damit verringert sich die Anzahl der notwendigen Regeln für eine bidirektionale Verbindung von sechs auf zwei. Filterregeln lassen sich ganz grob in drei Bestandteile zerlegen: ❏ die Grundoperation, also Einfügen einer Regel, Regelketten anlegen und lö-
schen etc. ❏ Matching-Optionen entscheiden, ob die Regel überhaupt auf ein Paket zutrifft
oder nicht. Und schließlich ❏ Targets, die beschreiben, was mit einem Paket geschehen soll, wenn die Regel
schließlich zutrifft.
5.2.2
Grundoperationen für Filterregeln
❏ iptables -A chain rule ...
fügt eine Filterregel am Ende der Regelkette ein (Append) ❏ iptables -D chain rule ...
löscht die passende Filterregel (Delete)
65
5 Paketfilterung und Network Address Translation
❏ iptables -D chain position
löscht die Regel an Position position (Delete) ❏ iptables -R chain position rule ...
ersetzt die Regel an Position position mit der neuen Regel (Replace) ❏ iptables -I chain position rule ...
fügt die Regel an Position position ein (Insert) ❏ iptables -F [chain]
löscht alle Regeln aus der Regelkette chain (Flush) ❏ iptables -P chain
ändert die Default Policy der Regelkette (Policy) ❏ iptables -L [chain]
zeigt alle Regeln der ausgewählten Regelkette (List) ❏ iptables -Z [chain]
löscht alle Zähler der Regelkette (Zero) ❏ iptables -E old-chain-name new-chain-name
benennt eine Regelkette um (Exchange)
5.2.3
Matching-Optionen für Filterregeln
Matching-Optionen geben an, ob die Regel auf ein Paket zutrifft oder nicht. Protokolle iptables -A chain -p proto ... Mögliche Angaben für proto sind TCP, UDP, ICMP. Groß-/Kleinschreibung spielt hier keine Rolle. Es kann auch die Protokollnummer angegeben werden. Diese Nummern sind allerdings wenig bekannt, so daß sich aus Gründen der Lesbarkeit empfiehlt, TCP/UDP/ICMP auszuschreiben. Beispiel: iptables -A INPUT -p TCP ...
Quell-/Zieladresse iptables -A chain [-s source-ip] [-d destination-ip] beschränkt die Filterregel auf die angegebenen Quell-/Zieladressen. Mögliche Angaben für source-ip/destination-ip sind: ❏ Full Name: www.example.com
66
5.2 Paketfilterung mit iptables
❏ IP-Adresse: 127.0.0.1 ❏ Gruppe von IP-Adressen (short): 192.168.1.0/24 ❏ Gruppe von IP-Adressen (full): 192.168.1.0/255.255.255.0 ❏ Spezialfall beliebige IP-Adresse: 0/0. Normalerweise kann man die IP-
Adresse auch weglassen. Beispiel: iptables -A INPUT -s 192.168.1.2 -d 192.168.5.3 ...
Auswahl von Interfaces iptables -A INPUT [-i in-iface] iptables -A FORWARD [-i in-iface] [-o out-iface] iptables -A OUTPUT [-o out-iface] in-iface/out-iface kann jedes Interface sein. Im Augenblick existierende Interfaces können mit ifconfig abgefragt werden. Eingehende Pakete besitzen nur ein Input-Interface, ausgehende ausschließlich ein Output-Interface. Mit anderen Worten: eine Regel mit -o trifft in einer Input-Chain nie zu. Generell können auch Interfaces angegeben werden, die noch gar nicht existieren, sondern später konfiguriert werden. Das ist insbesondere für nichtpermanente Verbindungen über ISDN oder Modems wichtig. So können schon beim Systemstart Filterregeln gesetzt werden, obwohl das Interface erst viel später initialisiert wird. Ebenfalls sehr hilfreich ist die Möglichkeit, eine Filterregel gleich für eine ganze Gruppe von Interfaces zu setzen. Die Option -i ippp+ trifft auf alle Interfaces zu, die mit dem String ippp beginnen. Beispiele: iptables -A INPUT -i ippp+ ... iptables -A OUTPUT -o eth0 ...
Die Möglichkeit, Filterregeln an ein bestimmtes Interface binden zu können, ist bei Firewalls besonders wichtig. Während sich fast alles andere auf Paketinhalte bezieht (und diese kommen von „außen“ und können gefälscht sein), ist die Angabe von Interfaces unabhängig von Paketen und deshalb nicht von falschen Paketinhalten beeinflußbar. Man sollte diese Möglichkeit unbedingt in Anspruch nehmen.
67
5 Paketfilterung und Network Address Translation
Fragmentierung IP-Pakete können während des Transports von den übertragenden Netzwerkknoten (Router) zerlegt (fragmentiert) werden (siehe AbschnittA.5). Da die Information über die Pakete im ersten Fragment zu finden ist (IP-Header + TCP/UDP/ICMP-Header), trifft keine Filterregel auf die nachfolgenden Fragmente zu, die Angaben wie Protokolle und Ports enthält (nur IP-Header vorhanden). Mit iptables -A chain -f ... läßt sich angeben, ob eine Filterregel nur auf das zweite bis letzte Paket zutreffen soll. Die Angabe von Ports (TCP/UDP) oder Typ/Code (ICMP) sowie die Angabe des SYN-Flags ist dabei nicht erlaubt. Beispiel: iptables -A INPUT -f -s 192.168.1.2 ...
Fehlerhafte Pakete, die zu kurz für eine ordnungsgemäße Erkennung sind, werden ebenfalls vom Kernel als Fragmente behandelt. Normalerweise werden aber solche Pakete, bei denen der TCP/UDP/ICMP-Header nur teilweise vorhanden ist, künstlich erzeugt. Negation Viele Optionen für Filterregeln lassen sich auch negieren: ❏ iptables -A chain -s ! source-ip
trifft auf alle Pakete zu, die nicht von der Adresse source-ip kommen. ❏ iptables -A chain -d ! destination-ip
alle Adressen außer Bestimmungsort destination-ip ❏ iptables -A chain -p ! proto
alle Protokolle außer Protokoll proto ❏ iptables -A chain -i ! iface
alle Interfaces außer Interface iface ❏ iptables -A chain ! -f
trifft nur auf das erste Fragment zu Erweiterungen zu iptables Das Konzept um iptables ist erweiterbar. Konkret bedeutet dies, daß nur ganz wenige Optionen (die bisher aufgezeigten) unmittelbar in iptables implementiert sind. Alle weiteren Features finden sich in Erweiterungen. Solche Erweiterungen bestehen aus zwei Teilen: zum einen wird der Kernel um zusätzliche Mo-
68
5.2 Paketfilterung mit iptables
dule erweitert, zum anderen muß auch iptables diese Module steuern können, dazu gibt es dann entsprechende Shared Libraries. Ziel – neben einer einfacheren Wartbarkeit des Codes – ist natürlich auch, daß Erweiterungen nicht nur von den Autoren des Netfilter Framework, sondern auch von anderen Programmierern beigesteuert werden können. Der Maintainer der Netfilter-Architektur, Rusty Russell, hat das als Grundkonzept von Open Source ausgemacht: die Arbeit, die man selbst machen müßte, auf andere zu verlagern. Um mit iptables vernünftig arbeiten zu können, wird ein Standardsatz an Erweiterungen mitgeliefert. Es gibt zwei Klassen von Erweiterungen: sogenannte Matches, die die Filterregel weiter spezifizieren und prüfen, ob ein Paket zutrifft, oder Targets. Hier geht es zunächst nur um Matching-Regeln, Targets (und Target-Erweiterungen) werden später in einem eigenen Abschnitt behandelt. Erweiterungen enthalten meistens eine eigene Hilfefunktion, die man erhält, wenn man die Erweiterung explizit lädt. Beispiel: iptables -m tcp -help iptables -j REJECT -help Dabei wird -m für Matches benötigt, -j bei Targets. TCP-Erweiterung iptables -p tcp ... lädt automatisch die TCP-Erweiterung. Anders als bei früheren Filtermöglichkeiten können jetzt auch gezielt spezielle Bereiche des TCP-Header wie Flags und TCP-Optionen abgefragt werden. Dabei sind folgende Angaben möglich: ❏ iptables -p tcp --source-port [!] port ❏ iptables -p tcp --sport [!] port
Spezifiziert den Quellport. Mögliche Angaben für den Port sind: ➢ Einzelner Port mit Namen: www (siehe /etc/services) ➢ Einzelner Port numerisch: 1023 ➢ Portbereich: ’6000:6010’ ➢ Spezialfälle: ’:1023’, ’6000:’. Fehlt eine Portangabe, wird für den
unteren 0 bzw. für den oberen 65535 angenommen. Beispiel: iptables -A INPUT -p TCP --sport 25 iptables -A OUTPUT -p TCP --sport 1024:
Im Gegensatz zu ipfwadm in der Kernelserie 2.0.x kann hier je Filterregel immer nur ein Port oder ein Bereich angegeben werden. Sollen mehrere Ports oder Bereiche angegeben werden, kann die multiport-Erweiterung verwendet werden (siehe weiter unten).
69
5 Paketfilterung und Network Address Translation
❏ iptables -p tcp --destination-port [!] port ❏ iptables -p tcp --dport [!] port
Angabe des Zielports. Andernfalls gelten die gleichen Regeln für die PortSpezifikation wie bei --source-port. ❏ iptables -p tcp --tcp-flags [!] mask setflags
Eine sehr mächtige TCP-Erweiterung, mit der man alle TCP-Flags einzeln prüfen kann. Meistens ist man nur an der Einstellung bestimmter Flags interessiert, und die übrigen Flags sollen unbeachtet bleiben. Um das gezielt abfragen zu können, wird zunächst eine Auswahl mask an Flags angegeben, die geprüft werden sollen. Alle anderen Flags werden komplett ignoriert. Ein zweiter Bereich spezifiziert daraus die Flags, die gesetzt sein müssen. Neben den eigentlichen TCP-Flags (SYN, FIN, RST, PSH, ACK, URG) kann auch ALL oder NONE angegeben werden. Beispiel: iptables -A INPUT -p TCP --tcp-flags SYN,ACK SYN ...
prüft, ob das ACK-Flag vorhanden ist bei gelöschtem SYN-Flag (offene TCPVerbindung ab dem dritten Paket beim Three-Way-Handshake), iptables -A INPUT -p TCP --tcp-flags ALL NONE ...
prüft, ob alle Flags gelöscht sind. Normalerweise kommt das nicht vor und muß künstlich erzeugt werden (NULL-Scan). ❏ iptables -p tcp [!] --syn
Beschreibt das erste Paket eines TCP-Verbindungsaufbaus, mit der Option --tcp-flags ausgedrückt würde das so aussehen: iptables -A INPUT -p TCP --tcp-flags SYN,RST,ACK SYN ... ❏ iptables -p tcp --tcp-option [!] option-number
Die Regel trifft zu, wenn das Paket eine TCP-Option mit option-number gesetzt hat. TCP-Optionen beginnen mit einer 1 Byte langen Kennung. Für diese Prüfung muß das Paket den vollständigen TCP-Header enthalten. UDP-Erweiterung iptables -p udp ... lädt analog die UDP-Erweiterung. Vorerst sind nur die Angabe von Source- und Destination-Port möglich: ❏ iptables -p udp --source-port [!] port ❏ iptables -p udp --sport [!] port ❏ iptables -p udp --destination-port [!] port ❏ iptables -p udp --dport [!] port
Für die Angabe des Portbereiches gilt dasselbe wie für die TCP-Erweiterung.
70
5.2 Paketfilterung mit iptables
Multiport-Erweiterung iptables -p tcp|udp -m multiport ... Will man mehrere einzelne Ports in einem nicht zusammenhängenden Bereich angeben, kann man die Multiport-Erweiterung einsetzen, um die Restriktionen der TCP- und UDP-Erweiterung zu umgehen. Da es dabei um Ports geht, ist die Erweiterung nur im Zusammenhang mit den Protokollen TCP und UDP möglich. Zur Angabe der Ports gibt es folgende Optionen: ❏ iptables ... -m multiport --source-port port[,port]
Ein oder mehrere Quellports, durch Kommata getrennt. ❏ iptables ... -m multiport --destination-port port[,port]
Ein oder mehrere Zielports, durch Kommata getrennt. ❏ iptables ... -m multiport --port port,[port]
Quell- und Zielport müssen hier identisch sein und gleichzeitig einem Port aus der angegebenen Liste entsprechen, dann trifft dieser Match zu. Die Portliste ist derzeit auf 15 Ports beschränkt. Beispiel: iptables -A FORWARD -p tcp -m multiport -i eth0 -o eth1 \ --destination-port smtp,www,ssh -j ACCEPT
ICMP-Erweiterungen iptables -p icmp ... ICMP besitzt keine Ports wie TCP oder UDP. ICMP-Nachrichten enthalten je 1 Byte type und code (siehe auch Abschnitt A.4). Während bei ipchains und ipfwadm ICMP-Typ und -Code noch als Pseudo-Source- bzw. -Destination-Port angegeben werden konnte, gibt es jetzt eine eigene Option, die bisher auch die einzige ist: ❏ iptables -p icmp --icmp-type [!] icmpspec
Der Wert icmpspec kann numerisch oder als Name angegeben werden. Numerische Angaben werden in der Form ’type/code’ spezifiziert, eine Liste der Namen erhält man mit iptables -p icmp --help. Beispiel: iptables -A INPUT -p ICMP --icmp-type 8/0 ... iptables -A INPUT -p ICMP --icmp-type echo-request ...
Beide Regeln sind identisch und beziehen sich auf eine Ping-Anfrage. Hier eine kurze Übersicht über die gängigen ICMP-Typen, eine Auflistung aller ICMP-Typen findet sich im Anhang A.4 in der Tabelle A.1:
71
5 Paketfilterung und Network Address Translation
Tabelle 5.1: Gängige ICMP-Typen
Type
Bedeutung
code != 0?
0 3 4 5 8 11
echo reply (Antwort auf Ping) destination unreachable source quench redirect echo request (Ping-Anfrage) time exceeded
nein ja nein ja nein nein
Kontrolle des Verbindungszustandes iptables -m state ... ermöglicht es, den Zustand von Verbindungen zu kontrollieren. Dabei werden Daten ausgewertet, die das Connection-Tracking-Modul sammelt. Dieses Modul wird außerdem noch bei NAT benötigt. ❏ iptables -m state --state [!] list-of-states
Eine Liste von Zuständen kann aus einem einzelnen Zustand oder einer Komma-separierten Aufzählung von Zuständen bestehen. iptables kennt folgende Zustände: ➢ NEW Das Paket initiert eine Verbindung, bei TCP identisch mit der Option --syn. ➢ ESTABLISHED Ein Paket, das zu einer bestehenden Verbindung gehört. Das ist mächtiger, als es sich zunächst anhört. Bei früheren Filterregeln mußte zum Beispiel bei ausgehenden TCP-Verbindungen die Rückrichtung zu allen höheren Ports offengehalten werden, da nicht vorhersagbar war, welchen Port der Client als Source-Port benutzt. Über das Connection-Tracking-Modul dagegen werden ausgehende Verbindungen in einer Tabelle geführt, d. h., das Netfilter Framework weiß, welche Verbindungen von welchen Clients mit welchen Ports gerade offen sind. ➢ RELATED Pakete, die in Beziehung zu einer offenen Verbindung stehen, aber nicht direkt zur Verbindung gehören. Dazu zählen Protokolle, die mehrere Kanäle benötigen wie FTP, oder auch Fehlernachrichten über ICMP. Außer bei ICMP ist dazu jedoch immer noch ein spezielles Modul nötig, das die Eigenheiten des verwendeten Protokolls kennt. Für FTP
72
5.2 Paketfilterung mit iptables
gibt es ein eigenes Zusatzmodul zum Connection-Tracking-Modul , das auch installiert sein muß. ➢ INVALID Alle Pakete, die nicht einem der vorher genannten Zustände zugeordnet werden können. Da bei Connection Tracking mit Kerneltabellen gearbeitet wird, kann es bei hoher Last auch zu einem Überlauf kommen. ICMP-Pakete, die nicht zuzuordnen sind, fallen ebenfalls darunter. Generell sollte man solche Pakete verwerfen. Beispiel: iptables -A OUTPUT -m state --state NEW ... iptables -A INPUT -m state --state RELATED,ESTABLISHED ...
Mit der Zustandskontrolle ist eine dynamische Paketfilterung möglich, die weit über die Möglichkeiten einer statischen Paketfilterung hinausgeht. Während man mit der einen oder anderen Einschränkung von ipchains oder ipfwadm leben kann, wäre die dynamische Paketfilterung auf jeden Fall ein Grund, auf die Netfilter-Architektur umzustellen. MAC-Erweiterungen iptables -m mac ... Ursprünglich ist diese Erweiterung wie die nachfolgenden zu Demonstrationszwecken geschrieben worden, kann aber in lokalen Netzwerken durchaus eingesetzt werden. ❏ iptables -m mac --mac-source [!] mac-addr
läßt die Angabe einer Ethernet-Source-Adresse zu: iptables -A INPUT -m mac --mac-source 00:50:BA:C4:28:B4 ...
Begrenzung der Matching-Rate iptables -m limit ... Normalerweise wird jedes Paket, auf das eine Filterregel zutrifft, verarbeitet, d. h., das entsprechende Target wird ausgeführt. Es gibt aber einige Fälle, wo man das Ausführen des Target mengen- und zeitmäßig gerne beschränken würde, etwa beim Logging oder als Abwehr gegen Denial-of-Service-Attacken (die sich in der Regel durch eine Flut von ähnlichen Paketen in sehr kurzer Zeit auszeichnen). Ein ganz einfaches Beispiel ist: iptables -A chain -m limit -j LOG
„Logge alle Pakete in einer bestimmten Regelkette.“ Dabei werden implizit die Default-Einstellungen verwendet, die man auch explizit angegeben kann:
73
5 Paketfilterung und Network Address Translation
❏ iptables -m limit --limit rate
Gibt die Rate der Pakete an, die im Mittelwert nicht überschritten werden darf. rate ist eine Zahl, optional gefolgt von einer Zeiteinheit: 3/second, 3/minute, 1/hour, 12/day. Defaultzeiteinheit ist /second, d. h., --limit 5 ist identisch mit --limit 5/s (alle Zeiteinheiten können auch abgekürzt werden). Default ist 3/hour. ❏ iptables -m limit --limit-burst number
Wird diese maximale Burst-Anzahl überschritten, wird das obige Limit aktiv. Default ist 5. Mit den Defaultwerten 3/hour und Burstlimit 5 kann man sich das so vorstellen: zunächst werden die ersten 5 Pakete abgearbeitet (Burst). Danach wird nur alle 20 Minuten (3/hour) je ein Paket abgearbeitet. Solange weitere Pakete eintreffen, wird das immer weiter fortgesetzt. Und wann wird so ein Limit wieder gelöscht? Die Formel heißt limit * limit-burst, also mit den Defaulteinstellungen 20 min * 5 = 100 min. Trifft 100 Minuten lang kein Paket mehr ein, auf das die Regel zutrifft, wird das Limit wieder vollständig zurückgesetzt. Damit kann man nicht nur Logging stark begrenzen, sondern auch Portscanner ausbremsen oder eine Syn-Flood-Protection durchführen: iptables -A chain -p tcp --syn -m limit --limit 5/s ...
Syn-Flood-Protection läßt sich aber auch mit anderen Mitteln vermeiden: im Kernel gibt es dazu die Parameter tcp_syncookies, tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow, siehe dazu auch /usr/src/linux/Documentation/networking/ip-sysctl.txt. Owner-Prüfung iptables -m owner ... Diese Erweiterung bezieht sich ausschließlich auf ausgehende Pakete in der OUTPUT Chain. Dabei werden nur Pakete erfaßt, die auch im Userspace erstellt wurden. Pakete wie ICMP-Antworten, die der Kernel automatisch generiert, besitzen kein Ownership, auf solche Pakete wird daher eine Regel mit -m owner nie zutreffen. Folgende Optionen sind im Owner-Modul möglich: ❏ iptables -m owner --uid-owner userid
trifft zu, wenn das Paket von einem Prozeß generiert wird, der diese effektive User-ID besitzt (numerisch, kein Name). ❏ iptables -m owner --gid-owner groupid
dito mit der effektiven Group-ID.
74
5.2 Paketfilterung mit iptables
❏ iptables -m owner --pid-owner processid
Prozeß-ID des paketerstellenden Prozesses. ❏ iptables -m owner --sid-owner sessionid
Angabe der Session-Group, die zu dem paketerstellenden Prozeß gehört. Beispiel: iptables -A OUTPUT -p tcp -m owner --uid-owner 201 ...
unclean-Erweiterungen iptables -m unclean ... Ursprünglich aus Kompatibilität zur Kernelversion 2.2 gedacht (im Kernel 2.2 wurde ein Paket erst auf Konsistenz geprüft, bevor es überhaupt angenommen wurde), hat diese Modul nur noch Demo-Charakter für Programmierer. Es führt zwar einen Gesundheitscheck auf das eingehende Paket durch, wird aber sicherheitstechnisch nicht gepflegt und soll im Normalfall deswegen auch nicht verwendet werden. Die Gefahr, daß mehr Sicherheitslücken eingeschleppt als verhindert werden, ist beim jetzigen Stand der Entwicklung zu groß.
5.2.4
Targets – Was soll die Filterregel bewirken?
Bis jetzt wurde nur ausgeführt, ob eine Regel zutrifft oder nicht. Was mit dem Paket geschehen soll, wenn eine Regel zutrifft, bestimmen Targets, die in diesem Abschnitt beschrieben werden. Die allgemeine Syntax lautet iptables -A chain ...
-j target
Dabei steht -j für „jump-to“. Das Ziel einer Filterregel wird als Target bezeichnet, ein Begriff, der der Einfachheit halber hier beibehalten werden soll. Man unterscheidet drei Klassen von Targets: Builtin-Targets, userdefinierte Regelketten und Erweiterungen. Weiter oben wurde bereits angedeutet, daß neben Erweiterungen zum Matching auf diesem Weg auch neue Targets zur Verfügung gestellt werden, was die Flexibilität der Netfilter-Architektur ungemein vergrößert. Builtin-Targets Es existieren zunächst zwei triviale Targets: ❏ ACCEPT
Das Paket wird ganz einfach durchgelassen. Beispiel:
75
5 Paketfilterung und Network Address Translation
iptables -A OUTPUT -p tcp --syn -j ACCEPT ❏ DROP
Das Paket wird verworfen, der Absender wird darüber im Unklaren gelassen. Das ist eigentlich nicht besonders fein, aber macht bei Firewalls mitunter durchaus Sinn, um Angreifern weniger Informationen, sprich Angriffsfläche zu bieten und ein mögliches Ausspähen zu erschweren. Beispiel: iptables -A INPUT -p tcp --syn -j DROP
Moderne Portscanner wie Nmap werten allerdings das Ausbleiben einer im Standard definierten Antwort auf ein Paket als Information und gewinnen so eine Aussage darüber, ob ein Zielhost gegebenenfalls hinter einem Firewall liegt. Daneben gibt es noch zwei weitere Builtin-Targets für ganz bestimmte Zwecke: ❏ RETURN
Das Target sorgt dafür, daß alle weiteren Regeln einer Regelkette übersprungen werden und weiter verfahren wird, wie es normalerweise am Ende einer Regelkette wäre: ein RETURN in einer Builtin-Regelkette (INPUT, FORWARD, OUTPUT) sorgt dafür, daß die Default Policy ausgeführt wird, ein RETURN in einer userdefinierten Regelkette verläßt diese sofort und kehrt zum Ausgangsort zurück (zu userdefinierten Regelketten siehe weiter unten). Beispiel: iptables -A userdef -p tcp --source 192.168.1.13 -j RETURN ❏ QUEUE
Das Target wurde eingeführt, um Pakete abzufangen und an eine normale Applikation weiterleiten zu können. Ein Paket wird aus dem Kernelbereich an den Userspace überführt. Das ist Voraussetzung, wenn man Applikationen schreiben will, die Pakete behandeln sollen, die normalerweise nur der Kernel bearbeitet. Benötigt wird aber auch noch eine Applikation, die speziell daraufhin programmiert wurde, und ein Mechanismus, der die Pakete zwischen Kernel und Userspace verschieben kann. Dieser Mechanismus wird in Form eines Modules ip_queue mit dem Kernel mitgeliefert. Beispiel: iptables -A INPUT -p udp --sport 12345 -j QUEUE
Userdefinierte Regelketten Bevor man userdefinierte Regelketten als Target verwenden kann, müssen diese erst einmal angelegt werden: iptables -N chain
76
5.2 Paketfilterung mit iptables
erzeugt eine neue Regelkette mit dem Namen chain. Die Namen können dabei bis zu 31 Zeichen lang werden (ipchains: 8 Zeichen). iptables -X [chain] löscht die Regelkette mit dem Namen chain. Verzichtet man auf die Angabe einer Regelkette, werden alle vom Anwender definierten Regelketten gelöscht. Regelketten können nur gelöscht werden, wenn diese keine Filterregeln mehr enthalten und wenn es keine Filterregel an anderer Stelle mehr gibt, die als Target auf diese Regelkette zeigt. Beispiel: Löschen aller Filterregeln und -ketten: iptables -F iptables -X
Damit spart man sich die Auflistung aller selbst definierten Regelketten, allerdings werden so auch alle Filterregeln in den vordefinierten Regelketten gelöscht. Nützlich ist dies zum Beispiel in einem Skript, das alle Filterregeln neu initialisiert. Verwendung von userdefinierten Regelketten Prinzipiell kann man natürlich alle Filterregeln in die drei permanenten Regelketten stellen. Zum einen wird das mit zunehmender Anzahl von Filterregeln unübersichtlich. Zum anderen muß jedes Paket alle Filterregeln durchlaufen, bis eine passende gefunden wird. Und: bei mehreren, zusammengehörenden Filterregeln muß eine bestimmte Bedingung wie das Interface in jeder Regel einzeln angegeben werden. Beispiel: Es sollen generell nur ausgehende Verbindungen erlaubt sein mit Ausnahme von zwei Subnetzen, die zu befreundeten Firmen gehören und über eigene Interfaces kommen. Als eingehende Verbindungen werden erlaubt: smtp, pop3, imap und rsync. rsync ist ein intelligenterer Ersatz für rcp und besitzt inbesondere die Eigenschaft, Files oder Verzeichnisse upzudaten und nur die Daten zu übertragen, die sich auch tatsächlich verändert haben. rsync läßt sich auch als Daemon aufsetzen, der wie bei ftp einen anonymen Zugriff über TCP über den Port 873 erlaubt. Darauf zielt das Beispiel hier ab. Das erste Subnetz soll 172.17.96.0/255.255.254.0 sein, das zweite Subnetz ist 192.168.9.0/255.255.255.0. Die eigene IP-Adresse ist 192.168.12.2: iptables -A -d iptables -A -d iptables -A
Wenn man nun die Filterregeln gruppiert und in selbst definierte Regelketten steckt, die nur unter bestimmten Bedingungen angesprungen werden, verringert man die Laufzeit. Die Filterregeln in einer selbst definierten Regelkette können dann auch einfacher ausfallen, wenn diese Regelkette nur angesprungen wird, falls eine gemeinsame Bedingung schon erfüllt ist. Man kann nun eine etwas weniger eingeschränkte Regelkette definieren, die nur angesprungen wird, wenn die Bedingungen „Interface“ und „befreundetes Subnetz“ erfüllt sind: iptables -N friendly_in iptables -A -d iptables -A -d iptables -A -d iptables -A -d
Die selbst definierte Regelkette friendly_in wird jetzt nur noch angesprungen, wenn der Absender und das Interface stimmen: iptables -A INPUT -s 172.17.96.0/23 -i ippp11 -j friendly_in iptables -A INPUT -s 192.168.9.0/24 -i ippp12 -j friendly_in
Rechnerisch hat man sich zwar nur eine Filterregel (jetzt sind es 7 statt 8) gespart. Aber: stimmt der Absender nicht, werden nur noch 2 statt 8 Regeln durchlaufen. Nicht zu unterschätzen ist die größere Transparenz. Daß zwei Subnetze identisch behandelt werden, ist in der ersten Version gar nicht so einfach zu erkennen. In der zweiten Version sieht man das mit einem Blick. Läßt sich in einer userdefinierten Regelkette keine Regel finden, die auf ein Paket zutrifft, kehrt Regelkette wieder zur aufrufenden Regelkette zurück und setzt dort mit der Abarbeitung der nächsten Filterregel fort.
78
5.2 Paketfilterung mit iptables
Target als Erweiterungen Das Konzept, aufwendigere Targets als Erweiterungen implementieren zu können, eröffnet neue Möglichkeiten: noch im Kernel 2.2 hätten Anpassungen bei vorhandenen Targets einen tiefgehenden Eingriff in den Kernelcode dargestellt. Jetzt lassen sich solche Targets auch von Programmierern bewältigen, die nicht direkt an der Kernelentwicklung beteiligt sind. Man kann also davon ausgehen, daß sich im weiteren Verlauf der Linux-Entwicklung noch vieles tun wird. In der Default-Distribution der Netfilter-Architektur werden für die Paketfilterung zwei Target-Erweiterungen mitgeliefert: ein Modul für Logging, und REJECT als Alternative zu DROP. Logging iptables ...
-j LOG
Während bei ipchains und ipfwadm das Logging ganz einfach bei einer Filterregel mit der Option -l angegeben werden konnte, ist diese Möglichkeit bei iptables nicht mehr vorhanden. Logging ist jetzt ein eigenes Target, was zwar für einfache Zwecke relativ umständlich scheint, aber gerade für nichttriviale Anwendungen eine wesentlich größere Flexibilität bietet. Wichtig: das Target LOG ist nicht-exclusiv. Trifft ein Paket auf eine Filterregel zu, dann wird das Target LOG ausgeführt, aber die Bearbeitung des Pakets endet hier nicht wie bei den anderen Targets, sondern wird fortgeführt, das heißt, die Regelkette wird hier nicht an dieser Stelle verlassen, sondern es wird mit der Prüfung der nächsten Filterregel fortgefahren. Das Target LOG kennt folgende Optionen, mit denen sich der Output beeinflussen läßt: -j LOG --log-level <syslog-prio> Der Loglevel beeinflußt die Warnstufe, mit der der Syslog die Information protokolliert. Als Wert einsetzbar sind die Warnstufen aus Syslog, die dort „Priority“ heißen (siehe man 5 syslog.conf).
❏ iptables ...
iptables -A INPUT -p ICMP -j LOG --log-level info
Was zur Zeit fehlt ist die Möglichkeit, Einfluß auf die Syslog-Facility zu nehmen. Die Implementierung einer Option --log-facility ist sicher nur eine Frage der Zeit. -j LOG --log-prefix <string> Erlaubt die Angabe eines Textes, der im Logfile wieder erscheint. Man kann damit gezielt Logeinträge mit Zusatzinformation versehen, um spätere Auswertungen zu erleichtern. Der Text darf bis zu 29 Zeichen lang sein.
-j LOG --log-tcp-sequence Protokolliert die TCP-Sequence-Nummer mit. Da einige Angriffe auf einer (meist erratenen) Kenntnis der TCP-Sequence-Nummer basieren, gibt sich Linux alle Mühe, möglichst gute Zufallsfolgen zu verwenden, die man nicht erraten kann. Man schafft man hier ein mögliches Sicherheitsloch, wenn das Logfile, in dem die Sequenzen stehen, allgemein lesbar ist. Also Vorsicht im Umgang mit dieser Option.
❏ iptables ...
-j LOG --log-tcp-options Enthält der TCP-Header Optionen (wie zum Beispiel die MSS), dann werden diese hier ausgegeben.
❏ iptables ...
-j LOG --log-ip-options Protokolliert Optionen des IP-Headers, so vorhanden.
❏ iptables ...
Um protokollieren zu können, ob ein Paket zum Beispiel angenommen oder abgelehnt wurde, legt man sich am besten eine eigene Regelkette an: iptables -N my_drop iptables -A my_drop -j LOG --log-prefix DROP iptables -A my_drop -j DROP
Ein Paket, das abgelehnt und dabei protokolliert werden soll, bekommt jetzt in der Filterregel statt -j DROP ein -j my_drop. Besonders nützlich ist die Kombination des Targets LOG mit der Matching-Erweiterung Limit. Das obige Beispiel könnte dann so aussehen: iptables -N my_drop iptables -A my_drop -p -j iptables -A my_drop -p -j iptables -A my_drop -j
! ICMP -m limit \ LOG --log-prefix DROP ICMP -m limit --limit 1/hour --burst 3 \ LOG --log-prefix DROP_ICMP DROP
Reject iptables ...
-j REJECT
Während ein DROP ein Paket einfach sang- und klanglos verschwinden läßt, bietet das Target REJECT die Möglichkeit, den Sender über eine ICMP-Fehlernachricht (normalerweise „Port Unreachable“) zu informieren. Ansonsten ist REJECT identisch mit DROP.
80
5.2 Paketfilterung mit iptables
In RFC-1122 werden einige Fälle aufgezählt, in denen keine ICMP-Fehlernachricht versandt werden darf. In folgenden Fällen wird das Paket einfach verworfen, und REJECT ist identisch mit DROP: ❏ Eine ICMP-Nachricht unbekannten Typs trifft ein. Paket wird verworfen. ❏ Eine ICMP-Fehlernachricht trifft ein. Würde eine ICMP-Fehlernachricht auf
eine ICMP-Fehlernachricht hin erzeugt werden, käme es zu einer Endlosschleife. ❏ Ein Paket ist an eine IP-Broadcast- oder Multicast-Adresse adressiert (ver-
hindert Broadcast-Sturm). ❏ Ein Paket wurde an eine Link-Layer Broadcast-Adresse versandt (zum Bei-
spiel Ethernet-Broadcast, verhindert ebenfalls einen Broadcast-Sturm). ❏ Ein Paket besteht aus einem Fragment, das nicht den Beginn eines Data-
grams darstellt. ❏ Ein Paket enthält als Source-Adresse keinen einfachen Host: Null-Adresse,
Loopback-Adresse, Multicast- oder Broadcast-Adresse, oder Class-E-Adresse. Im Gegensatz zu früheren Implementierungen kann man bei dem Target REJECT nun auch andere ICMP-Errorcodes angeben: -j REJECT --reject-with Mögliche Werte für sind: ➢ icmp-net-unreachable
❏ iptables ...
➢ icmp-host-unreachable ➢ icmp-port-unreachable (Default-Wert) ➢ icmp-proto-unreachable ➢ icmp-net-prohibited ➢ icmp-host-prohibited ➢ icmp-echo-reply: ist nur erlaubt, wenn sich die Filterregel auf ein
ICMP-Ping-Paket bezieht. Man kann damit erreichen, das eingehende Pings auf das interne Netzwerk generell vom Firewall beantwortet werden. ➢ tcp-reset: ein Verbindungsversuch via TCP an einen nicht belegten
Port wird normalerweise mit einen TCP-Reset (RST-Flag) beantwortet, nicht mit einer ICMP-Fehlernachricht. Genau für diesen Zweck ist tcp-reset gedacht. Erlaubt ist es allerdings nur in der INPUT-Chain.
81
5 Paketfilterung und Network Address Translation
5.2.5
Default Policy
iptables -P chain DROP In einer Filterkette kann es durchaus vorkommen, daß keine der aufgestellten Regeln zutrifft. Dann wird das Paket nach einer Voreinstellung, der sogenannten Default Policy, behandelt. Solche Voreinstellungen erleichtern die Umsetzung der eigenen Sicherheitspolitik (siehe Kapitel 3). In den meisten Fällen wird man nur wenige Verbindungen erlauben, die dann in einzelnen Filterregeln gezielt gesetzt werden, den Rest über die Default Policy wird man verbieten. -P steht für „Policy“. Während es bei den Filterregeln auf die Position ankommt, in der diese sich in der Kette befinden, wird die Default Policy immer zuletzt ausgeführt, nachdem alle anderen Regeln abgearbeitet wurden. Man kann sich das zunutze machen und bereits zu Beginn eine (ablehnende) Default Policy setzen, bevor andere Regeln spezifiziert werden: iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP
Während des Ablaufes eines Firewallscriptes, das die Filterregeln erst nach und nach zusammensetzt, kann es zu ungewollten Sicherheitslücken kommen. Um das zu vermeiden, gibt es zwei Strategien: entweder sorgt man dafür, daß das Firewallscript bereits zu einem Zeitpunkt läuft, zu dem das Netzwerk noch nicht aktiv ist, oder – besser – man fügt in jede permanente Regelkette Filterregeln an erster Stelle ein, die alles verbieten und die dann am Ende des Skriptes – nachdem alle Regeln stehen – wieder gelöscht werden: iptables -I INPUT 1 -j DROP iptables -P FORWARD 1 -j DROP iptables -P OUTPUT 1 -j DROP [... alle Filterregeln] iptables -D INPUT -j DROP iptables -D FORWARD -j DROP iptables -D OUTPUT -j DROP
Im Beispiel machen wir davon Gebrauch, daß man beim Löschen statt der Position auch die exakte Spezifikation der Filterregel angeben kann. Eine Default Policy läßt sich nur in den drei permanenten Regelketten INPUT, FORWARD und OUTPUT setzen.
82
5.2 Paketfilterung mit iptables
Userdefinierte Regelketten kennen keine Default Policy, stattdessen wird die Bearbeitung der Pakete dort fortgesetzt, von wo aus die userdefinierte Regelkette aufgerufen wurde.
5.2.6
Regelketten anzeigen, entleeren, überwachen
Regelketten entleeren iptables -F [chain] löscht alle Filterregeln der genannten Kette (F = Flush). Wird keine Regelkette angegeben, werden alle vorhandenen Filterregeln gelöscht. Die Default Policy bleibt allerdings erhalten. Setzt man vorher die Default Policy für alle permanenten Regelketten auf DROP, bleibt keine Tür für Angreifer offen, allerdings ist dann der Rechner nicht mehr aus dem Netzwerk erreichbar. Alle Filterregeln anzeigen iptables -L [chain] zeigt alle Filterregeln der genannten Kette (L = List). Läßt man die Angabe der Filterkette weg, werden alle Regelketten mit ihren Regeln angezeigt, auch die leeren Regelketten. Ein Beispiel (die Ausgabe wurde bei \ für das Drucklayout wieder umbrochen): Chain INPUT (policy ACCEPT) target prot opt source destination LOG tcp -- pc01 anywhere tcp dpt:telnet \ flags:SYN/SYN,RST,ACK LOG level warning REJECT tcp -- pc01 anywhere tcp dpt:telnet \ flags:SYN/SYN,RST,ACK reject-with icmp-port-unreachable Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
In der Ausgabe bezeichnen dpt den Destination Port, bei den Flags ist zu beachten, daß hier im Gegensatz zur Regelspezifikation zuerst das gesuchte Flag, danach die Suchmaske genannt werden. In der FORWARD- bzw. der OUTPUTChain existiert nur die Default Policy.
83
5 Paketfilterung und Network Address Translation
Zählen von Paketen Filterregeln, die kein Target enthalten, wirken sich nur auf einen Byte- und PaketZähler aus. Da ohne Target die Regelkette weiter abgearbeitet wird, bleiben solche Filterregeln ohne Auswirkung auf den Verbleib des Paketes. Es wird also nur gezählt. Will man die gezählten Pakete ausgeben lassen, schaltet man beim Listing zusätzlich die Option -v ein: iptables -L [chain] -v Im folgenden noch einmal das obige Beispiel, allerdings diesmal mit -L INPUT -n -v ausgegeben (Zeilenumbruch für das Drucklayout wieder durch \ gekennzeichnet): Chain INPUT (policy ACCEPT 2432 packets, 152434 bytes) pkts bytes target prot opt in out source destination 4 240 LOG tcp -- * * 192.168.1.9 0.0.0.0/0 \ tcp dpt:23 flags:0x0216/0x022 LOG flags 0 level 4 4 240 REJECT tcp -- * * 192.168.1.9 0.0.0.0/0 \ tcp dpt:23 flags:0x0216/0x022 reject-with \ icmp-port-unreachable
Die TCP-Flags sind in der numerischen Ausgabe ziemlich unverständlich, der Rest ist aber selbsterklärend. Die numerische Ausgabe mit der Option -n verhindert auch gleich einen DNS-Lookup, da keine Namen aufgelöst werden müssen. Macht man von Zählern Gebrauch, benötigt man auch eine Möglichkeit, diese wieder zurückzusetzen: iptables -Z [chain] Benötigt man den Zählerstand exakt zum Zeitpunkt der Löschung, kann man die Optionen -L und -Z kombinieren: iptables -L -Z [chain] -v Im Gegensatz zu ipchains geht das jetzt auch für einzelne Filterketten.
5.2.7
Weitere Variationen von Filterregeln
Bis jetzt haben wir uns nur in der Standard-Tabelle des Netfilter Framework filter bewegt. Bisher wurden keine Pakete verändert. Neben dieser Tabelle verfügt das Netfilter Framework noch über weitere Tabellen: mangle und nat. Mit den Möglichkeiten der Tabelle nat setzt sich der Abschnitt 5.3 (Network Address Translation) auseinander. Die beiden im folgenden beschriebenen Möglichkeiten, Pakete zu maskieren und Type-of-Service zu manipulieren, benötigen die Tabelle mangle, weil sie den Inhalt der Pakete verändern:
84
5.2 Paketfilterung mit iptables
iptables -t mangle -A chain ... Dabei ist die Tabelle mangle nur erforderlich, wenn die Pakete verändert werden (via Targets), bei reinen Matchingrules dagegen nicht. Jede Tabelle hat ihre eigenen Chains, daher muß in jedem Falle immer zuerst die Tabelle spezifiziert werden (Default: -t filter). Die Tabelle mangle besitzt die vordefinierten Chains PREROUTING und OUTPUT. Zur Positionierung der Chain PREROUTING siehe Abschnitt 5.3. Pakete markieren iptables -t mangle ...
-j MARK
Pakete lassen sich mit einem 32-Bit Wert (unsigned) markieren, um sie später einer speziellen Behandlung zu unterziehen. Dazu benötigt man ein Target, das diese Marke setzen kann, und eine Matching-Erweiterung, die die gesetzte Marke auch wieder auswerten kann. iptables -t mangle ...
-j MARK --set-mark <mark>
setzt eine Marke. Um das Paket anschließend auswerten zu können, wird die Matching-Extension mark benutzt: iptables -A chain -m mark --mark <mark>[/<mask>] wertet eine gegebenenfalls vorhandene Marke eines Pakets aus. Dabei muß entweder exakt die Marke <mark> angegeben werden, oder man spezifiziert dazu eine Maske, dann werden nur die Bits ausgewertet, die von der Maske umfaßt werden. Beispiel: iptables -t mangle -A PREROUTING -p ICMP -j MARK --set-mark 20 ... iptables -A INPUT -p ICMP -m mark --mark 20 -j LOG
Type of Service (TOS) iptables -t mangle ...
-j TOS
Die TOS-Flags im IP-Header erlauben, die einzelnen Pakete nach ihrer Verwendung zu qualifizieren. In diesem Zusammenhang taucht auf der Begriff „Quality of Service“ auf, der dann allerdings nicht rein auf das IP-Protokoll fixiert ist. TOS kennt vier Flags: ❏ Minimize delay:
0x10
❏ Maximize troughput: ❏ Maximize reliability:
0x08 0x04
85
5 Paketfilterung und Network Address Translation
❏ Minimize monetary cost:
0x02
TOS-Flags werden ähnlich dem Markieren von Paketen über die Tabelle mangle und ein spezielles Target gesetzt: iptables -t mangle ...
-j TOS --set-tos
Welche Werte man dabei setzen kann, erhält man mit iptables -j TOS -h. Die TOS-Flags können über eine Matching-Extension ebenfalls wieder abgefragt werden: iptables -A chain -m tos --tos Die Werte sind identisch mit denen des Target TOS und können analog mit iptables -m tos -h abgefragt werden. Ein Beispiel für die Verwendung von TOS: iptables -t mangle -A PREROUTING -p TCP --dport 23 \ -j TOS --set-tos 16 ... iptables -A INPUT -p ICMP -m tos --tos 16 -j LOG
Der Wert 16 entspricht Minimize-Delay (hier bei Telnet-Verbindungen).
5.2.8
Filterregeln testen
Nach so vielen Möglichkeiten, Filterregeln zu definieren und anzuwenden, möchte man vielleicht auch einmal den erstellten Regelsatz testen. iptables wird es erlauben, den Durchlauf eines Paketes durch eine Filterkette zu simulieren: iptables -C chain ... -C steht für Check. Zum Zeitpunkt der Drucklegung war allerdings -C noch nicht implementiert, so daß hier nur ein Blick in die aktuelle Dokumentation emfohlen werden kann (man iptables).
5.2.9
Filterregeln sichern/restaurieren
iptables-save iptables-save [-c] [-t table] > rules.txt sichert die vorhandene Konfiguration in einem File rules.txt. Entweder sichert man unter Angabe einer bestimmten Tabelle, oder es werden alle Tabellen gesichert. Die Option -c sorgt dafür, daß gleichzeitig alle Paket- und ByteCounter mitprotokolliert werden.
86
5.3 Network Address Translation
iptables-restore iptables-restore [-c] [-n] < rules.txt restauriert die gesicherten Regeln wieder. Mit der Option -n (noflush) werden beim Zurücksichern die vorhandenen Regeln nicht gelöscht (Default: Löschen der bereits vorhandenen Regeln beim Rücksichern). Hinweis: Wegen des frühen Entwicklungsstadiums von iptables-save und iptables-restore können sich noch Abweichungen in der Syntax ergeben, siehe dazu auch man iptables-save.
5.3 Network Address Translation Network Address Translation, kurz NAT, hat die Manipulation der IP-Adressen zum Ziel, die das IP-Datagram mit sich führt. Auch wenn Paketfilterung und NAT immer wieder in Zusammenhang gebracht werden: beide sind voneinander völlig unabhängig. Im Kernel spiegelt sich das in zwei voneinander völlig unabhängigen Tabellen wider: filter ist die Tabelle für die Paketfilterung, nat ist die Tabelle, über die Network Address Translation abgebildet wird. In einer perfekten Welt benötigt man kein NAT, sagt der Autor des „Linux 2.4 NAT HOWTO“, Rusty Russell (gleichzeitig Maintainer des Netfilter-Codes in Kernel 2.4). Die Welt ist aber leider nicht perfekt. Auf die Gründe, NAT zu verwenden, wurde schon im Abschnitt 4.6 eingegangen. In diesem Abschnitt geht es um die technischen Details, Begriffe und Möglichkeiten, die der Kernel 2.4 bietet. Prinzipiell unterschiedet man zwei Arten von NAT: ❏ Source-NAT:
„Source Network Address Translation“ (SNAT) ändert die Quelladresse eines Pakets, das heißt, der Ursprung des Pakets wird verborgen. Source-NAT wird erst am Ende des Routing durchgeführt, unmittelbar bevor das Paket über das Interface auf das Netzwerk entlassen wird. Für die Paketfilterung bedeutet dies, daß die Filterregeln sich nicht um Source-NAT kümmern müssen, sondern so tun, als würde die Verbindung ohne NAT zustande kommen (zum Beispiel auch mit internen, privaten IP-Adressen). Masquerading ist ein Spezialfall von Source-NAT (siehe weiter unten). ❏ Destination-NAT:
„Destination Network Address Translation“ (DNAT) verändert die Zieladresse eines Pakets, der Bestimmungsort ändert sich. DNAT wird direkt am eingehenden Paket vorgenommen, vor jeder Routingentscheidung.
87
5 Paketfilterung und Network Address Translation
Die Paketfilterregeln sind dabei ebenfalls auf den tatsächlichen Sender und Empfänger abzustellen (als würde kein NAT durchgeführt). DNAT findet man bei Port Forwarding, Load Sharing und Transparent Proxying.
5.3.1
Einsatz von NAT: Schema
iptables -t nat -A chain <matches> -j NAT wird wieder durch das Allround-Werkzeug iptables initialisiert. Dabei muß immer die Tabelle nat angewählt werden. Ob SNAT oder DNAT durchgeführt wird, legt das Target fest. Für unterschiedliche Zwecke gibt es unterschiedliche Targets. SNAT und DNAT besitzen jeweils getrennte Regelketten, die passend zum gewünschten NAT ausgewählt werden müssen. Auf welche Pakete NAT angewandt wird, selektiert der Matching-Bereich. Hier sind fast alle Matching-Optionen anwendbar, wie bei der Paketfilterung aufgezeigt. Ausnahmen sind solche, die keinen Sinn ergeben, zum Beispiel die Matching-Erweiterung state. NAT wird inititalisiert beim Verbindungsaufbau, den Rest erledigt das Connection-Tracking-Modul weitgehend automatisch. Es macht also keinen Sinn, NAT nur auf bereits bestehende Verbindungen anwenden zu wollen. Die gebräuchlichen Matching-Optionen sind Source- und Destination-Adresse, bei TCP und UDP auch Source- und Destination-Port, oder auch Input- und Output-Interface (allerdings nur dort, wo es auch Sinn macht). Bei nicht zulässigen Optionen (zum Beispiel Input-Interface in der Filterkette POSTROUTING für SNAT) liefert der Aufruf von iptables einen Fehler zurück. Ablaufdiagramm NAT kennt drei vordefinierte Regelketten: PREROUTING, POSTROUTING und OUTPUT. In Abbildung 5.2 sind diese Regelketten in das bereits bekannte Ablaufdiagramm der Paketfilterung eingefügt. Zwar sind Paketfilterung und NAT unabhängig voneinander (auch die Regelkette OUTPUT hier ist nicht identisch mit der der Paketfilterung), aber die Reihenfolge, in der ein Paket die einzelnen Regelwerke durchläuft, spielt schon eine Rolle für die Konstruktion der Filterregeln des Paketfilters. Die Regelkette PREROUTING kommt bei DNAT zum Zuge und wird durchlaufen, sofort nachdem das Paket eingetroffen ist. Erst danach wird die RoutingEntscheidung ausgeführt. OUTPUT ist nur ein Spezialfall: auch ein lokaler Prozeß könnte ein Paket erzeugen, dessen Zieladresse manipuliert werden soll, zum Beispiel wenn ein norma-
88
5.3 Network Address Translation
Abbildung 5.2: Network Address Translation in Kernel 2.4
lerweise ausgehendes Paket wieder zurück an einen lokalen Prozeß umgeleitet wird. POSTROUTING schließlich ist die Regelkette für alle SNAT Anwendungen und wird erst durchlaufen, kurz bevor das Paket in das Netzwerk entlassen wird.
5.3.2
Source-NAT
iptables -t nat -A POSTROUTING ...
-j SNAT ...
Das Target SNAT ist nur in der POSTROUTING-Regelkette gültig. Als Interfaceangabe ist das Output-Interface -o zulässig. SNAT kennt bisher nur eine Option: ❏ -j SNAT --to-source [- ist die Adresse, die als Source-Adresse eingesetzt werden soll. Dabei kann eine einzelne IP-Adresse, ein Bereich, oder bei den Protokollen TCP und UDP auch ein Port angegeben werden. Eine Standard-Anwendung von SNAT ist das folgende Beispiel: iptables -t nat -A POSTROUTING -o eth1 \ -j SNAT --to-source 172.16.1.1
Oder – etwas ungewöhnlicher – die alternierende Angabe mehrerer Source-IPAdressen bei unterschiedlichen Verbindungen: iptables -t nat -A POSTROUTING -o eth1 \ -j SNAT --to-source 172.16.1.1-172.17.16.4
89
5 Paketfilterung und Network Address Translation
Masquerading iptables -t nat -A POSTROUTING ...
-j MASQUERADE
Das Target MASQUERADE ist ein Spezialfall von SNAT und speziell entwickelt für dynamische IP-Adressen. MASQUERADE übernimmt automatisch die jeweilige IPAdresse des Output-Interface als Source-IP-Adresse. Interfaces mit dynamischen IP-Adressen (meist Dial-In-Interfaces wie ppp0) bekommen bei jedem Verbindungsaufbau eine neue IP-Adresse zugewiesen. Das bringt ziemliche Probleme mit den noch bestehenden Verbindungen. Im Normalfall bleiben diese in einem undefinierten, nicht geschlossenen Zustand. Mit dem Target MASQUERADE werden diese Verbindungen einfach vergessen. Das ist so erwünscht, da ausgehende Pakete vom Kernel entsprechend auf die neue IP-Adresse umgesetzt werden und keine offenen, nicht existenten Verbindungen übrigbleiben (Merke: eine offene TCP-Verbindung muß nicht notwendigerweise Datenpakete austauschen). Die Fähigkeit des Kernel, mit dynamischen IP-Adressen umzugehen, kann mit folgendem Befehl aktiviert werden: echo 1 > /proc/sys/net/ipv4/ip_dynaddr
Nähere Informationen hierzu in /usr/src/linux/Documentation/networking/ip_dynaddr.txt. Einfaches Masquerading aktiviert man mit (dabei muß natürlich Forwarding aktiviert sein): iptables -t nat -A POSTROUTING -o ippp0
-j MASQUERADE
Das Target MASQUERADE kennt eine Option, die man aber nur in Ausnahmefällen braucht: ❏ -j MASQUERADE --to-ports <port>[-<port>]
Damit kann man angeben, welche Source-Ports eingesetzt werden sollen. Gültig ist diese Option nur mit den Protokollen TCP und UDP.
5.3.3
Destination-NAT
iptables -t nat -A PREROUTING ...
-j DNAT ...
Destination-NAT wird in der Regelkette PREROUTING oder in wenigen Fällen in der Regelkette OUTPUT durchgeführt. Als Matching-Option ist die Angabe des Input-Interface -i möglich. Zur Spezifizierung der neuen Destination-Adresse gibt es folgende Option:
90
5.3 Network Address Translation
❏ -j DNAT --to-destination [- ist analog zu SNAT die Adresse, die als Destination-Adresse eingesetzt werden soll. Dabei kann eine einzelne IP-Adresse, ein Bereich, oder bei den Protokollen TCP und UDP auch ein Port angegeben werden. Eine Anwendung von DNAT könnte folgendes Szenario sein: man hat nur eine offizielle IP-Adresse, möchte aber keinen Web- oder E-Mailserver auf dem Firewallhost aufsetzen, sondern hat hinter dem Firewallhost für beide Dienste auch noch zwei verschiedene Hosts: iptables -t -j iptables -t -j
dabei wird eine eingehende Verbindung, die an den Port 80 adressiert ist, an einen bestimmten Webserver weitergereicht, eine eingehende SMTP-Verbindung dagegen an einen anderen Host. Eine andere Anwendung ist Port-Forwarding, dabei wird auch der Zielport eines Pakets umgeschrieben, etwa weil die Verbindung auf einen transparenten Proxy umdirigiert werden soll: iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 \ -j DNAT --to-destination 172.16.1.1:3128
Und schließlich und endlich ein Beispiel für Load Sharing: iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 \ -j DNAT --to-destination 172.16.1.1-172.16.1.4
Hier werden die eingehenden Verbindungen eine nach der anderen auf die Hosts 1 bis 4 verteilt, abhängig von der zuletzt geöffneten Verbindung. Wichtig: Bei Load Sharing muß natürlich der angebotene Dienst auf allen 4 Hosts identisch sein. Redirection iptables -t nat -A PREROUTING ...
-j REDIRECT
Redirection ist ein Spezialfall von Destination-NAT: die Destination-Adresse wird immer durch die IP-Adresse des Input-Interface ersetzt. REDIRECT kennt daher nur eine Port-Option: ❏ -j REDIRECT --to-ports <port>[-<port>]]
Damit kann man angeben, welche Destination-Ports eingesetzt werden sollen. Gültig ist diese Option nur mit den Protokollen TCP und UDP.
91
5 Paketfilterung und Network Address Translation
Beispiel für Redirection: iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 \ -j REDIRECT --to-port 3128
5.4 Zusammenfassung Mit dem Netfilter Framework enthält der Linux-Kernel ein mächtiges Werkzeug, das es erlaubt, Netzwerkpakete zu filtern oder zu manipulieren. Das Administrationswerkzeug für den Anwender ist dabei das Programm iptables. Welche Pakete ausgewählt werden, bestimmen sogenannte Matching-Optionen, die entscheiden, ob die Filterregel auf ein Paket zutrifft oder nicht. Was dann mit dem Paket geschieht, legt das Target fest. Die Netfilter-Architektur ist modular angelegt und erlaubt eine einfache Erweiterung in den Matching-Optionen und den Targets. Damit ist „Netfilter“ ein Baukasten, der noch viele Erweiterungen erwarten läßt. Über Netfilter werden Paketfilterung und Network Address Translation abgebildet. Beide sind voneinander völlig unabhängig, was sich auch in den verwendeten Kerneltabellen zeigt. Paketfilterung benutzt die Tabelle filter, NAT die Tabelle nat. Für spezielle Manipulationen an den Netzwerkpaketen wie Typeof-Service oder Markierung von Paketen gibt es eine zusätzliche Tabelle mangle. Gegenüber früheren Kernelversionen bringt Kernel 2.4 mit Netfilter einen großen Fortschritt durch hohe Flexibilität, sauberere Codebasis und einfachere Regeln durch ein neues, viel einfacheres Ablaufdiagramm. Das macht sich auch beim Anwender durch einfachere Regeln bemerkbar, und einfachere Regeln sind besser verständlich, und damit auch weniger fehleranfällig.
92
Kapitel 6 Proxies Neben der Paketfilterung stellen Proxies einen wichtigen Bestandteil von Firewalls dar. Proxies nehmen als Stellvertreter des eigentlichen Client die Verbindung zum Internet-Server auf (siehe auch Abschnitt 4.3). Aber auch der umgekehrte Weg ist möglich und realisierbar: ein Proxy kann eine eingehende Verbindung zu einem Server kontrollieren und schützen. Ein Anwendungsbeispiel hierfür ist der weiter unten beschriebene FTP-Proxy der SuSE Proxy-Suite. Der Übersicht halber eine Zusammenfassung der wichtigsten Begriffe und Verfahren: ❏ Implizite Proxies. Internetdienste, deren Server bereits über eine eingebau-
te Proxy-Funktionalität verfügen und die deshalb keinen speziellen Proxy benötigen. Standardbeispiel hierfür ist SMTP, da Mail auf dem Store-andForward-Prinzip beruht. Implizite Proxies sollen in diesem Kapitel nicht behandelt werden. ❏ Veränderte Verfahren. Proxies, die eine Änderung der Benutzeraktionen erfor-
dern. Damit können dann zwar alle bisherigen Clientprogramme eingesetzt werden, aber die Anwender müssen über die geänderten Verfahren aufgeklärt werden. Beispiel hierfür ist der FTP-Proxy der SuSE Proxy-Suite bei ausgehenden Verbindungen. ❏ Veränderte Clients. Durch eine Anpassung in der Client-Software wird auto-
matisch der Proxy verwendet, das Vorgehen ist für den Benutzer transparent. Nachteilig ist eben, daß die Software auf dieses Verfahren angepaßt werden muß. Beispiel hierfür ist SOCKS, bestehend aus Libraries für den Client und einem eigenen SOCKS-Proxy-Server, die weiter unten beschrieben werden. ❏ Transparente Proxies. Sie sind für den Benutzer transparent und benötigen
auch kein geändertes Verfahren. Allerdings eignen sie sich nicht für jeden
93
6 Proxies
Anwendungsfall. Ein solcher Anwendungfall ist zum Beispiel der Schutz des eigenen FTP-Servers. Nach außen hin ist nur der transparente Proxy sichtbar, der auch von den Benutzern (auch aus dem Internet) angesprochen wird. Als Filter schützt er den FTP-Server, in dem er mögliche gefährliche Kommandos erst gar nicht zuläßt (SuSE FTP-Proxy, Abschnitt 6.1). ❏ Generische Proxies. Können den übertragenen Inhalt nicht bewerten, weil sie
die einzelnen Anwendungsprotokolle nicht kennen. ❏ Applikationsspezifische Proxies. Sie werden speziell für eine Anwendung pro-
grammiert und kennen deren Protokolldetails. So läßt sich der Funktionsumfang einer Anwendung einschränken: ein FTP-Proxy könnte zum Beispiel verhindern, daß der Befehl delete in bestimmten Verzeichnissen ausgeführt wird. Proxies kontra Paketfilterung Ein applikationsspezifischer Proxy bietet wesentlich mehr Möglichkeiten als eine Paketfilterung, da sich dieser mit dem Protokoll des Dienstes, also dem übertragenen Inhalt auseinandersetzt. Eine Steuerung über Paketfilterung ist auf Adressen, Ports und bei TCP auf die Auswahl der Richtung der Verbindung beschränkt. Wo liegt nun der Zusatznutzen bei generischen Proxies, die ja ebenfalls keine Kenntnis über das verwendete Protokoll haben? ❏ Keine direkte Verbindung zwischen Client und Server. Mit Proxies kann die
direkte Kommunikation zwischen Server und Client unterbunden werden. Ein Firewall, der ausschließlich Paketfilterung einsetzt, muß erlaubte Verbindungen von jedem Client aus zum Server im Internet zulassen. Werden Proxies – auch generische – eingesetzt, kann die Kommunikation ausschließlich auf Verbindungen zwischen Clients und Proxy und zwischen Proxy und dem Internet beschränkt werden. Bei privaten Netzwerken kann Network Address Translation nur in eine Richtung (ausgehende Verbindung) arbeiten. Ein Proxy dagegen kann auch eingehende Annehmen und die Verbindung an einen Server im privaten Adreßraum weiterreichen. ❏ Benutzerauthentifikation. Ein Paketfilter kennt keine Benutzer, ein Proxy kann
– je nach verwendetem Verfahren – schon nach Benutzern unterscheiden und bestimmten Benutzern mehr Rechte einräumen als anderen. Bei „geändertem Verfahren“ kann ein Benutzer zusätzlich nach einem Passwort gefragt werden, bei „geänderten Clients“, etwa beim Einsatz des SOCKSVerfahrens, kann eine Authentifikation des Benutzers über das in RFC 931 beschriebene Verfahren (identd) durchgeführt werden. ❏ Inhaltliche Kontrolle und Protokollierung. Benutzerbezogene Protokollierung
ist bei Paketfiltern nicht möglich, bei Proxies schon. Inhaltliche Kontrolle
94
6.1 SuSE Proxy Suite: ftp-proxy
trifft, wie schon oben beschrieben, nur auf applikationsbezogene Proxies, nicht aber auf generische Proxies zu. Es ist leicht einzusehen, daß generische Proxies bei einem Standalone-Host mit Internetanbindung keinen Zusatznutzen bringen (sondern nur Mehrarbeit durch die notwendige Konfiguration).
6.1 SuSE Proxy Suite: ftp-proxy FTP ist durch die Verwendung von zwei gleichzeitigen Verbindungen (Control und Data, siehe auch Abschnitt 7.1.6) ein im Firewall-Bereich nicht gerade einfaches Protokoll. Generell sind eingehende Verbindungen zu den Clients aus Sicherheitsgründen in jedem Falle zu verbieten. Damit kommt für die Datenübertragung mit FTP nur noch „passives“ FTP in Frage. Das bedeutet aber, daß der Client für eine direkte Kommunikation eine TCP-Verbindung von einem unprivilegierten Port zu einem externen, ebenfalls unprivilegierten Port öffnen können muß. Zwar läßt sich damit verhindern, daß aus dem Internet heraus sich jemand diese Öffnung im Firewall zunutze macht, da der Verbindungsaufbau noch immer „von innen“ kommen muß. Aber auf der Clientseite lassen sich jetzt (fast) beliebige Verbindungen ins Internet öffnen. Es gibt eine Reihe von Trojanern, die eine solche Verbindungscharakteristik aufweisen. Da bei passivem FTP die Ports nicht vorhersagbar sind, muß man, wenn man keine Paketfilterung mit „statefull inspection“ (erst ab Kernel 2.4 mit netfilter) möchte, alle höheren Ports freischalten und bliebt anfällig für Trojaner, die von innen heraus eine Verbindung aufbauen. Ein weiteres Problem von FTP ist die Anfälligkeit der existierenden Implementierungen von FTP-Servern. Immer wieder tauchen neue (und manchmal auch alte) Exploits auf. Der ftp-proxy aus der SuSE Proxy Suite ist von der Konzeption her eher ein Proxy, der bei eingehenden Verbindungen (Inbound) in erster Linie vor Angriffen auf den eigenen FTP-Server schützt, hat aber auch die Möglichkeit, über eine Variable AllowMagicUser ausgehende Verbindungen (Outbound) zu bedienen. Allerdings sollte man zum derzeitigen Zeitpunkt den Proxy auf demselben Server nur unidirektional verwenden. Erlaubt man ausgehende Verbindungen von Rechnern aus dem Internet, kann der Server als Relay mißbraucht werden. Bei rein ausgehenden Verbindungen kann man den Zugriff über den TCP-WrapperMechanismus auf eigene Hosts begrenzen.
95
6 Proxies
Abbildung 6.1: FTP-Server mit Proxy (Inbound)
6.1.1
Inbound-Connections
Bei dem folgenden Beispiel schützt der Proxy den eigenen FTP-Server bei eingehenden Verbindungen. Wir gehen dabei von einer Konfiguration wie in Abbildung 6.1 aus. Das Beispiel ist angelehnt an das bei SuSE mitgelieferte Konfigurationsfile /etc/proxy-suite/ftp-proxy.conf. [-Global-] AllowMagicUser # # # #
no
Where to redirect incoming FTP traffic. This destination will be used if a client has not set its own target. WARNING: ftp-proxy will refuse to run if this directive is not set.
DestinationAddress
ftp.my.domain
# (Local) port range for all connections to the server. The # default is to let the proxy select any ephemeral port. DestinationMinPort DestinationMaxPort
42900 42999
# This is the port corresponding to DestinationAddress. It
96
6.1 SuSE Proxy Suite: ftp-proxy
# defaults to 21, the standard FTP port. DestinationPort # # # #
1088
Specify the FTP transfer mode to be used from the proxy to the server. TransferMode can be active, passive, or client. The default is "client" which means to use the same as the client.
DestinationTransferMode
passive
# If given, change GID to give up root privileges. In POSIX # environments this changes all group ID’s. Group
nogroup
# # # # #
Set to listen on a specific interface (0.0.0.0 means all and is also the default). Address can be given as dotted decimal IP address or DNS host name.
# # # # # #
Determine where to send logging information. If the value starts with a ’/’ it is assumed to be a file. If it starts with a ’|’ it is assumed to be a program which will be popen()-ed. Anything else is assumed to be a facility for syslog(). See ftp-proxy.conf(5) and the "SYSLOG" file for severity handling.
# Maximum number of concurrent clients if running as daemon. # MaxClients 64 # # # #
This message (or rather the contents of a file with this name) will be issued when MaxClients is exceeded, each line prefixed with "421-". If no such file exists, only the MaxClientsString below will be displayed.
MaxClientsMessage
/etc/proxy-suite/ftp-maxclients.txt
# The following entries select a port range for client DTP
97
6 Proxies
# ports in passive mode, i.e. when the client sends a PASV. # If no port range is given, no bind is performed, in which # case the proxy lets the machine select an ephemeral port. PassiveMinDataPort PassiveMaxDataPort
41000 41999
# Write an ASCII file with the Program ID if given. Only valid # if running as daemon, in which case the daemon itself uses it. PidFile
/var/run/ftp-proxy.pid
# Port to listen on (for the SERVER-PI). Default is "ftp". # Can be given as TCP service name or as a plain number. Port # # # # # #
ftp
The following flag specifies the action when a PORT command is received while a PASV listening socket is outstanding. The RFC is not really clear about the "correct" behaviour, but since most existing implementations seem to reset the listener, we do the same by default. Nevertheless they all may be ... inaccurate.
PortResetsPasv yes # # # #
Shall we allow data connections only from the same host where the control connection originated from? Default is yes. If you say no here, the proxy is able to take part in so called third party server to server transfers.
SameAddress
yes
# If given, chroot() to this directory after initializing. Only # valid for inetd mode or forked clients. The daemon will stay. ServerRoot
/var/ftp-proxy/rundir
# Determine whether to run as daemon or in inetd mode. This can # be overridden by -d/-i command line switch. Default is inetd. ServerType
standalone
# Shall we use the TCP Wrapper Library when running as daemon?
98
6.1 SuSE Proxy Suite: ftp-proxy
# # # #
"on", "yes", "true" or a non-zero number means yes, anything else no. Default no. Only applicable when running as daemon. Note that TCP Wrapper support must be compiled in for this to work.
TCPWrapper
yes
# # # # #
If a client has no activity for this many seconds, it is regarded to be dead and the connection will be terminated. Default is 900 seconds, i.e. 15 minutes.
# # # # # #
If the proxy server needs to advertise itself (in outgoing responses like answers to PASV commands) with a different address than it actually has, the following option can be used. Relevant e.g. when using a NAT device in the path.
TimeOut
900
TranslatedAddress
0.0.0.0
# If given, change UID to give up root privileges. In POSIX # environments this changes all user ID’s. User
ftpproxy
# List of FTP commands that will be allowed from a client. # All commands not on this list will be rejected. If no list # exists, then all commands will be allowed. ValidCommands
This file will be presented to all clients immediately after the connection has been established. Each line is prefixed with "220-". The whole message is followed by a standard "220 FTP server () ready" or whatever has been substituted with WelcomeString below. Escape sequences (like %h for hostname; see ftp-proxy.conf(5)) are active.
WelcomeMessage
/etc/proxy-suite/ftp-welcome.txt
❏ [-Global-]
Der ftp-proxy kennt Kontexte. Ein Kontext bezieht sich auf den Namen eines Userlogins und beginnt mit []. Alle Angaben vor dem er-
99
6 Proxies
sten Login sind globale Angaben im Kontext [-Global-] (die Bindestriche unterscheiden den globalen Kontext von einem möglichen User „global“). Nicht alle Konfigurationsparameter können in globalen und userabhängigen Kontexten verwendet werden (siehe man 5 ftp-proxy.conf). ❏ AllowMagicUser no
Untersagt die Benutzung des Proxy für ausgehende FTP-Verbindungen. Der Parameter AllowMagicUser yes sollte nur verwendet werden, wenn sichergestellt ist, daß ausschließlich vertrauenswürdige User Zugriff haben, etwa durch einen eigenen Proxy-Server, der ausschließlich Clients aus dem internen Netzwerk heraus den Zugriff gewährt. ❏ DestinationAddress ftp.my.domain
Proxy FTP-Server. Der eigentliche FTP-Server, an den der Proxy die Anfragen weiterleitet, sofern der User keine eigene Serverangaben gemacht hat ( MagicUser). Die Angabe ist im globalen Kontext aus Sicherheitsgründen zwingend erforderlich. Da die Variable auch im userabhängigen Kontext gesetzt werden kann, ist es möglich, die Weiterleitung userabhängig auf verschiedene FTP-Server zu verteilen. Als Angabe sind sowohl der FQDN (Full Qualified Domain Name) des Server als auch dessen IP-Adresse möglich. Auch wenn die IP-Adresse eine höhere Sicherheit bietet, kann die Angabe eines FQDN sinnvoll sein, weil FTP-Server wie proftpd virtuelle Konfigurationen möglich machen, die sich eben durch den Namen und nicht durch die IP-Adresse unterscheiden. ❏ DestinationPort 1088
FTP-Server. Der Port, unter dem der eigentliche FTP-Server angeProxy sprochen wird. Default ist der Standard-Port 21. Laufen der Proxy und der FTP-Server auf demselben Host, wird normalerweise der Proxy den Port 21 benutzen, und der FTP-Server muß auf einen anderen Port aufgesetzt werden, wie in unserem Beispiel Port 1088. ❏ DestinationMaxPort 42999
DestinationMinPort 42900 FTP-Server. Der Bereich von Source-Ports, den der Proxy für VerProxy bindungen zum FTP-Server benutzen soll. Ohne Proxy ist der Source-Port, den die Clients für Verbindungen nutzen, kaum beeinflußbar. Mit dem Proxy hat man die Möglichkeit, den Paketfilterbereich zwischen Proxy und FTP-Server sehr viel stärker einzuschränken. ❏ PassiveMaxDataPort 41999
PassiveMinDataPort 41000 Client Proxy. Hier geht es um den Bereich, mit dem die Clients den Proxy für den Datentransfer ansprechen können. Bei passivem Datentransfer teilt
100
6.1 SuSE Proxy Suite: ftp-proxy
der Server dem Client mit, welchen Port er für die Data-Connection verwenden kann (siehe auch Abbildung 7.8). Für aktive Verbindungen gibt es ähnliche Konfigurationsvariable, wir wollen aber nur passive Verbindungen verwenden. ❏ DestinationTransferMode passive
Proxy FTP-Server. Methode für den Datentransfer zwischen Proxy und Server. Die Methode zwischen Client und Proxy kann nicht gewählt werden. Ist dort eine Einschränkung erwünscht, muß das mit Paketfilterung erreicht werden. ❏ Listen 0.0.0.0
Client Proxy. Die IP-Adresse, auf die der Proxy antworten soll. Nur von Belang, wenn der Server, auf dem der Proxy läuft, mehrere (auch virtuelle) Netzwerkinterfaces und damit mehr als eine IP-Adresse benutzt. Default ist 0.0.0.0, d. h., der Proxy reagiert auf jede Anfrage. ❏ Port ftp
Proxy. Der Port, unter dem der Proxy erreichbar ist. Da der Proxy Client nach außen hin als der FTP-Server auftritt, ist das in den allermeisten Fällen der FTP-Default-Port 21. ❏ ServerType standalone
Der Proxy kann als Standalone-Server oder über den inetd gestartet werden. Dazu mehr im nächsten Abschnitt. ❏ User ftpproxy ❏ Group nogroup
Beim Start als Standalone-Server muß festgelegt werden, unter welcher User/Gruppen-Kombination der Dienst gestartet werden soll. Aus Sicherheitsgründen darf das nie root sein. Am besten, man verwendet als User einen eigenen User, der ausschließlich für diesen Zweck angelegt wird (in userem Beispiel ftpproxy). ❏ LogDestination /var/log/ftp-proxy.log
Angabe zum Logfile. Neben normalen Files (beginnend mit „/“) können auch Kommandos (beginnend mit dem Pipe-Zeichen „|“) oder syslog verwendet werden (z. B. daemon). ❏ MaxClients 64
Server Proxy. Einschränkung der maximalen Client-Verbindungen zum Proxy. Sollte in jedem Falle abhängig von der Leistungsfähigkeit des FTPServers gesetzt werden, um Möglichkeiten von Denial-of-Service-Angriffe durch ganz normale FTP-Verbindungen zu unterbinden. ❏ MaxClientsMessage /etc/proxy-suite/ftp-maxclients.txt
Nachricht, die gesendet wird, wenn die maximale Anzahl von zulässigen Verbindungen ausgeschöpft ist. Vor jede Zeile wird ein ’421-’ gesetzt.
101
6 Proxies
❏ PidFile /var/run/ftp-proxy.pid
Enthält die aktuelle PID des Prozesses. ❏ PortResetsPasv yes
Client Proxy. Ist ein passiver Port nach einer Client-Anfrage geöffnet und wartet auf den Verbindungsaufbau und trifft in der Zwischenzeit eine erneute Anfrage des Client auf einer passiven Verbindung ein, dann wird der offene, wartende Port geschlossen. Dies ist sinnvoll, weil vermutlich etwas schiefgegangen ist, ist aber konfigurierbar, weil der dazugehörige RFC das erforderliche Verhalten nicht eindeutig spezifiziert. Sollte im Normalfall immer auf yes stehen. ❏ SameAddress yes
Client Proxy. Mit dem FTP-Protokoll ist es möglich, daß ein Client eine direkte Verbindung zwischen zwei FTP-Servern initiiert und sich selbst dann am Datenverkehr nicht beteiligt. In letzter Zeit sind immer wieder DoS-Angriffe bekannt geworden, die sich diese Eigenschaft zu nutze machen und zwei FTP-Server sinnlos miteinander beschäftigen (Stichwort FTPPORT-Attacken). Der Wert yes stellt sicher, daß der Datentransfer nur zu dem Client, der auch die ursprüngliche Verbindung aufgebaut hat, durchgeführt werden kann. Für anonyme User darf dieser Wert niemals auf no gesetzt werden. ❏ ServerRoot /var/ftp-proxy/rundir
Chroot-Umgebung, in der der ftp-proxy aus Sicherheitsgründen wechselt. Dort liegen nur die unbedingt notwendigen Programme und Files. Ist der ftp-proxy einmal mit Chroot in diese Umgebung gewechselt, kann er dort nicht mehr „ausbrechen“, das heißt, er kann auf keine Files außerhalb dieser Umgebung mehr zugreifen. ❏ TCPWrapper yes
Ist diese Variable gesetzt, verwendet der ftp-proxy die TCP-WrapperFunktionen im Standalone-Modus. Wird der ftp-proxy über den InetDaemon gestartet, dann verwendet man den tcpd. ❏ TimeOut 900
Proxy. Nach diesem Timeout wird eine Verbindung zwischen CliClient ent und Proxy getrennt, wenn so lange keine Daten mehr übertragen wurden. ❏ TranslatedAddress 0.0.0.0
Die Adresse, die der Proxy als Antwort auf ein PASV-Kommando liefert. Normalerweise ist das die eigene IP-Adresse des Servers, auf dem der Proxy läuft (0.0.0.0). In manchen Fällen ist es aber notwendig, eine andere Adresse angeben zu können, etwa wenn Network Address Translation verwendet wird oder der Proxy-Server dynamische IP-Adressen zugewiesen
102
6.1 SuSE Proxy Suite: ftp-proxy
bekommt. Für diesen Zweck kann die IP-Adresse nicht nur als FQDN oder IP-Adresse angegeben werden, sondern auch von einem File gelesen werden (Beispiel: TranslatedAddress /var/run/dyn-ip). ❏ WelcomeMessage /etc/proxy-suite/ftp-welcome.txt
Grußnachricht beim Verbindungsaufbau. Dort sollte man allgemeine Infos über den FTP-Dienst ablegen, z. B. daß alle Verbindungen geloggt werden etc. ❏ ValidCommands USER, PASS, ABOR, PASV, MODE, QUIT, SYST
Mit ValidCommands lassen sich die FTP-Kommandos, die der Client an den Server richten kann, sehr stark einschränken. Denkbar wäre, im globalen Kontext die Kommandos auf das absolut notwendige Minimum zu beschränken, und nur bei den userspezifischen Kontexten mehr zu erlauben. Dabei müssen auf jeden Fall die Kommandos, die für die Verbindungssteuerung benötigt werden, erlaubt sein: ➢ USER, PASS: User und Passwort für die Verbindung. ➢ ABOR: Abbruch der gerade laufenden Übertragung. ➢ PASV: Anfordern einer passiven Datenübertragung. ➢ MODE: Wechsel zwischen Binär- und Text-Übertragungsmodus. ➢ QUIT: Beenden der Session. Die wichtigsten Kommandos für die Datenübertragung sind: ➢ LIST: Ausgabe des Inhaltsverzeichnisses (FTP-Befehl dir). ➢ RETR: „Retrieve“, holen von Daten (FTP-Befehl get). ➢ STOR: „Store“, ablegen von Daten (FTP-Befehl put). Weitere Informationen zu den einzelnen FTP-Kommandos finden sich in RFC 959. Besonders interessant ist, daß sich auch die Parameter zu den FTP-Kommandos einschränken lassen. Verwendet werden hier Regular Expressions nach dem Posix-Standard 1003.2. Beispiele: ➢ ’CWD=^[a-zA-Z0-9]{1,128}$’ Erlaubt nur ein Argument, daß aus Buchstaben und Zahlen besteht und zwischen 1 und 128 Zeichen lang ist. Directory-Angaben, die zum Beispiel aus „.“ oder „-“ bestehen, sind nicht erlaubt. ➢ ’QUIT=^$’ Beim Kommando QUIT sind keine Parameter erlaubt.
6.1.2
Startarten für den ftp-proxy
Den ftp-proxy kann man als Standalone-Daemon starten oder über den inetd. Beim Start über den netd wird für jede Verbindung ein eigener Prozess gestartet, der sich aber beim Ende der Verbindung selbständig wieder beendet.
103
6 Proxies
Bei beiden Startarten sollte man aus Sicherheitsgründen einen nicht-privilegierten User verwenden, der ausschließlich für diesen Zweck benutzt wird. In unserem Beispiel verwenden wir den User ftpproxy in der Gruppe nogroup. Auch wenn beim Start über den inetd der User über das Konfigurationsfile /etc/inetd.conf angegeben wird, empfiehlt es sich, immer die Konfigurationsdirektiven User und Group in der ftp-proxy-Konfiguration mit anzugeben. Beim Start über den inetd sieht die entsprechende Zeile in /etc/inetd.conf so aus: ftp stream tcp nowait ftpproxy /usr/sbin/ftp-proxy -i
Für den Start als Daemon benötigt man für /sbin/init.d/rc*.d ein StartupSkript. Unter SuSE kann man in /sbin/init.d das Template skeleton nach ftp-proxy umkopieren und editieren. Mit /usr/sbin/ftp-proxy -d sollte der Aufruf explizit im Daemon-Modus erfolgen. Dazu wird in den Subdirectories der „normalen“ Runlevel ein Symlink benötigt: ln -s /sbin/init.d/ftp-proxy /sbin/init.d/rc2.d/S50ftp-proxy ln -s /sbin/init.d/ftp-proxy /sbin/init.d/rc2.d/K50ftp-proxy
Läuft der Server mit dem Proxy auch unter X (Runlevel 3), muß dasselbe für das Subdirectory rc3.d wiederholt werden (für weitere Infos zu einem Startupscript siehe auch Abschnitt 10.5.3).
6.1.3
Outbound-Connections
Um Outbound-Connections über den ftp-proxy zu ermöglichen, muß die Konfigurationsdirektive AllowMagicUser yes gesetzt werden. Damit der Proxy nicht von außerhalb für anonyme FTP-Zugriffe durch Dritte mißbraucht werden kann, muß auf jeden Fall sichergestellt werden, daß nur autorisierte Benutzer zugreifen können, etwa auf einem getrennten Host mit entsprechender Paketfilterung. Der Anwender, der über den ftp-proxy in das Internet möchte, verbindet zunächst mit einem FTP-Client zum Proxy-Host, bei der User-Abfrage werden dann User und Host in der Form <user>@host.domain eingegeben: % ftp proxyhost Trying 127.0.0.1... Connected to proxyhost. 220 Welcome to bastion. Name (proxyhost:wob): [email protected]
Das Verfahren funktioniert allerdings nur mit Clients, die eine explizite Eingabe des Users ermöglichen. Die Proxy-Konfiguration eines Browsers wie Netscape funktioniert nicht, da dort ein spezielles Protokoll verwendet wird. Eine Lösung
104
6.1 SuSE Proxy Suite: ftp-proxy
wäre, in der Userangabe das Zeichen @ durch % zu ersetzen, dann wäre eine URL wie die folgende erfolgreich: ftp://<user>%ftp.suse.com@proxyhost/
Netscape reicht hier den String vor dem @ als User an den proxyhost weiter.
6.1.4
Transparenter FTP-Proxy
Neuere Ausgaben von ftp-proxy beherrschen inzwischen einen transparenten Modus. Auf einem Linux-Router, über den ausgehende FTP-Verbindungen laufen (Dual Homed Bastion Host), fängt man mit Hilfe des Linux-Kernel und Network Address Translation ab (der Kernel muß entsprechend konfiguriert sein). Mit iptables lassen sich ausgehende Pakete, die an einen bestimmten Zielport gerichtet sind, abfangen und auf einen lokalen Port umleiten, auf dem der ftp-proxy dann lauschen kann. Wenn unser Dual Homed Bastion Host die IP-Adresse 192.168.1.1 hat, dann sieht die Filterregel so aus: iptables -t nat -A PREROUTING -i eth0 -p tcp \ --dport 21 -j REDIRECT --to-port 1088
Das Programm ftp-proxy erkennt im transparenten Proxy-Mode (Direktive AllowTransProxy yes), daß eine Verbindung eine entfernte Zieladresse hat, und behandelt diese entsprechend. Transparentes Proxying bietet einige Vorteile gegenüber der Methode des veränderten Userverfahrens: ❏ Für den Endbenutzer ist die Methode transparent, das heißt, die Anwender
können arbeiten wie bisher. ❏ Alle bisher verwendeten Clients sind ebenso einsatzfähig.
Die Nachteile sollten auch nicht verschwiegen werden: ❏ Der FTP-Datenverkehr muß über den Host, auf dem der Proxy läuft, gerou-
tet werden. Das ist nur bei einem Dual Homed Bastion Host der Fall. Single Homed Bastion Host kommen hierfür nicht in Frage. ❏ Durch den REDIRECT (das Abfangen eines Ports) funktioniert das nur für
den Standard-Port, nicht aber für beliebige Zielports. Transparentes Proxying sollte nur für Outbound Connections verwendet werden.
105
6 Proxies
6.2 SOCKS SOCKS ist ein Protokoll für Netzwerkzugriffe von Clients auf Server über einen SOCKS-Server, ohne daß die Clients direkte Verbindungen zum Server benutzen (siehe Abbildung 6.2). Der Client kontaktiert den SOCKS-Server und teilt ihm über das SOCKS-Protokoll mit, welche Verbindung er wünscht; der SOCKSServer baut dann seinerseits die Verbindung zum Zielserver auf und stellt die Verbindung her. Der Client hat dabei immer nur eine Verbindung zum SOCKSServer, der Zielserver ebenfalls. Proxies, die via SOCKS implementiert sind, arbeiten immer als generische Proxies, das heißt, sie können Entscheidungen immer nur auf der Ebene des Transport Layers treffen (mit Ausnahme zusätzlicher Userauthentifikation). Entscheidungen über den Inhalt der Pakete sind nicht möglich, da die anwendungsspezifischen Mechanismen dem generischen Proxy nicht bekannt sind. Das Protokoll ist dabei zwischen der Anwendungsschicht und der Transportschicht angesiedelt. Für den Verbindungsaufbau über Sockets verwendet ein normaler Client die entsprechenden Funktionen aus der C-Library, wie etwa connect und bind (siehe auch man 2 socket). Mit der SOCKS-Library werden einfach die für die Netzwerk-Kommunikation benötigten Routinen ausgetauscht. Damit ist zwar eine Anpassung der Clients notwendig, diese ist aber – da im wesentli-
Abbildung 6.2: SOCKS-Layer: Aus Applikationssicht stellt der Client eine Verbindung mit dem eigentlichen Server dar, das bilden auch die SOCKS-Routinen (hier im Beispiel Rconnect) ab. Der SOCKS-Layer fängt den connect-Aufruf aber ab und leitet ihn auf den SOCKS-Proxy-Server um, der seinerseits eine Verbindung zum Zielserver herstellt.
106
6.2 SOCKS
chen nicht weiter in die Anwendungslogik eingegriffen werden muß – sehr einfach durchführbar (siehe auch Abbildung 6.2). Die erste frei verfügbare Implementierung kam von einer Tochter von NEC USA Inc., die heute unter Networking Systems Laboratory (NWSL) firmiert. Der erste offene Standard, das „SOCKS V4 protocol“ , wurde über die Implementierung von NEC definiert. Die Weiterentwicklung Version 5 wurde über RFCs standardisiert: ❏ RFC1928: die Basis für SOCKS V5 ❏ RFC1929: Username/Password Authentication for SOCKS V5 ❏ RFC1961: GSS-API (Generic Security Service Application Programming In-
terface).
6.2.1
SOCKS V4 im Vergleich zu SOCKS V5
SOCKS V4 als erstes verfügbares Protokoll arbeitet ausschließlich auf TCP-Basis. Entscheidungen werden über den TCP-Header getroffen (Source-IP und -Port, Destination-IP und -Port). Die einzige mögliche Userauthentifikation ist über Ident (RFC1413). In der ursprünglichen Version mußte der Client selbst für die Namensauflösung von Hostnamen via DNS sorgen. Die Internetgemeinde hat später eine Erweiterung für SOCKS 4 definiert, die es dem Client ermöglicht, dem SOCKS-Server einen nicht aufgelösten Namen mitzuteilen und den DNS-Lookup vom SOCKSServer durchführen zu lassen. Mit SOCKS V5 wurden neben der Standardisierung Erweiterungen zu SOCKS V4 definiert, die eine Reihe von Unzulänglichkeiten von SOCKS V4 beheben sollen: ❏ Authentication Method Negotiation
Der Server teilt dem Client mit, welche Authentifikationsmethode er wünscht. Kann der Client keine der möglichen Methoden verwenden und sich nicht authentifizieren, wird die Verbindung unterbrochen. Gegenüber einem einfachen generischen Proxy kann hier zusätzlich eine UserIdentifizierung stattfinden. ❏ Address Resolution Proxy
Mit SOCKS V5 ist die DNS-Namensauflösung im Protokoll definiert, das heißt, der SOCKS-Server muß gleichzeitig als DNS-Proxy agieren können. ❏ UDP Proxy
UDP ist nun im Protokoll enthalten, allerdings gibt es Unterschiede zu TCP: da UDP ein verbindungsloses Protokoll ist, beschreibt der Proxy-Circuit nur Endpunkte einer Verbindung für Senden und Empfangen von Daten. An-
107
6 Proxies
sonsten werden die Anwendungsdaten einschließlich der Destination-Adresse eingekapselt. ❏ Generic Security Service Application Programming Interface
Das GSS-API ermöglicht starke Authentifikation und die Möglichkeit, Virtual Private Networks (VPN) über SOCKS zu implementieren.
6.2.2
Implementierungen von SOCKS
Bis jetzt sprachen wir nur vom SOCKS-Protokoll. Um damit aber arbeiten zu können, ist auch eine konkrete Implementierung erforderlich. Neben dem SOCKS Package von NEC (www.socks.nec.com) gibt es auch eine freie Implementierung von SOCKS V5 von Inferno Nettverk A/S mit der Bezeichnung „Dante“ (www.inet.no/dante). Seit Version 7.0 ist Dante in SuSE Linux enthalten, deshalb wird dieses Paket im folgenden näher beschrieben. Dante unterstützt derzeit (v1.1.2) folgende Standards: ❏ SOCKS Protokoll Version 4 ❏ RFC1928: Allerdings ohne den GSS-API Teil. ❏ RFC1929: Username/Password Authentication for SOCKS V5. ❏ msproxy: eine Erweiterung, die es ermöglicht, Unix-Clients über einen MS-
Proxy-Server zu verwenden. Einschränkung: nur TCP, keine User-Authentifikation. Nach den Angaben von Inferno Nettverk kann es bei der Benutzung von Unix-Clients unter manchen Umständen zu einem Crash des MSProxy-Servers kommen.
6.2.3
Dante SOCKS-Server
Die zentrale Konfigurationsdatei ist /etc/sockd.conf. Die Konfiguration kann grob unterteilt werden in die Abschnitte Servereinstellungen, Regeln für die Verbindung zwischen Client und SOCKS-Server und Regeln für die Verbindung zwischen Client und dem eigentlichen Zielserver. Zunächst der Abschnitt für die Servereinstellungen: # # :/etc/sockd.conf # # The recommended order is: # Serversettings: # logoutput # internal # external
108
6.2 SOCKS
# method # users # compatibility # extension # connecttimeout # iotimeout # srchost # # the server will log both via syslog, to stdout and to # /var/log/lotsoflogs #logoutput: syslog stdout /var/log/lotsoflogs logoutput: stderr # The server will bind to the address 10.1.1.1, port 1080 # and will only accept connections going to that address. internal: 10.1.1.1 port = 1080 # all outgoing connections from the server will use # the ipaddress 192.168.1.1 external: 192.168.1.1 # # # # #
list over acceptable methods, order of preference. A method not set here will never be selected. If the method field is not set in a rule, the current global method is filled in for that rule.
method: username rfc931 none # when doing something that can require privilege, it # will use the userid "sockd". user.privileged: sockd # when running as usual, it will use the unprivileged # userid of "sockd". user.notprivileged: sockd # If you compiled with libwrap support, what userid # should it use when executing your libwrap commands?
109
6 Proxies
user.libwrap: libwrap # # # # # # #
when a client connection comes in the socksserver will try to use the same port as the client is using, when the socksserver goes out on the clients behalf (external: ipaddress). If this option is set, Dante will try to do it for reserved ports aswell. This will usually require user.privileged to be set to "root".
compatibility: sameport # how many seconds can pass from when a client connects # til it has sent us it’s request? Adjust according # to your network performance and methods supported. # on a lan, this should be enough if method is "none". connecttimeout: 30 # # # #
how many seconds can the client and it’s peer idle without sending any data before we dump it? Unless you disable tcp keep-alive for some reason, it’s probably best to set this to 0, which is "forever".
iotimeout: 0 # or perhaps 86400, for a day. # do you want to accept connections from addresses without # dns info? what about addresses having a mismatch in dnsinfo? srchost: nounknown nomismatch
Die Servereinstellungen im einzelnen: ❏ logoutput
Erlaubte Werte sind stdout, stderr, syslog. Beginnt ein Wert mit /, wird ein Plain File angenommen. Der Wert syslog kann ergänzt werden um die Facility, unter der die Protokolle erzeugt werden sollen, etwa syslog/daemon. Kombinationen sind möglich, dabei werden die einzelnen Einträge mit einem Space getrennt. ❏ internal
Die Adresse, auf die der Proxy reagiert. Das ist die Netzwerkadresse des Interface, über die die Clients den Proxy ansprechen. Anfragen, die an eine andere IP-Adresse gerichtet werden, werden ignoriert.
110
6.2 SOCKS
❏ external
Der Proxy baut nach einer Clientanfrage seine eigene Verbindung zum Zielhost auf. external ist die IP-Adresse, die der Proxy als Absender angibt. ❏ method
Die Authentifikationsmethode für den Client. Unterstützte Werte sind hier user-name, rfc931 und none. Diese Angabe ist der Default für alle Regeln, falls in der betreffenden Regel keine eigene method angegeben wurde. ❏ user.privileged
Username für privilegierte Operationen, in unserem Beispiel ist das ebenfalls ein unprivilegierter User. Das bietet eine höhere Sicherheit, allerdings können dann keine Aktionen ausgeführt werden, die einen privilegierten User erfordern. ❏ user.notprivileged
Der Username für die meisten Operationen, die ohne besondere Rechte ausgeführt werden sollen. ❏ user.libwrap
Der User, der libwrap-Befehle ausführen soll. ❏ compatibility
Mit dem Wert sameport verwendet der Proxy denselben Port, den der Client ebenfalls verwendet. Da das auch für eventuell benutzte privilegierte Ports gilt, kann es in bestimmten Fällen zu Problemen kommen. Normalerweise sollte trotzdem sameport verwendet werden. Privilegierte Ports, die ein Client als Source-Port benutzt, kommen nur in wenigen Fällen vor. Bei der Secure-Shell läßt sich zum Beispiel explizit ein unprivilegierter SourcePort erzwingen. Falls es trotzdem Probleme gibt, kann man den Wert reuseaddr verwenden. Laut Manpage ist der Grund, warum es dann funktioniert, nicht bekannt, deshalb sollte man diese Option nur verwenden, wenn man genau weiß, was man tut. ❏ srchost
Der Parameter kennt zwei Werte: nomismatch verhindert den Verbindungsaufbau, wenn die IP-Adresse im DNS nicht mit dem Hostnamen übereinstimmt, nounknown verhindert Verbindungen, wenn der Host nicht im DNS eingetragen ist. ❏ connecttimeout
Ist der Wert 0, wartet der Proxy ohne zeitliche Beschränkung auf die Anfrage nach dem Verbindungsaufbau. Ist ein positiver Wert eingetragen, wird die Verbindung nach dem Timeout gekappt, wenn kein Request erfolgt. Dabei muß man die Authentifikationsmethoden berücksichtigen: Ist none erlaubt, muß sich der Client nicht authentifizieren und der erste Request kann schnell folgen. Setzt man aber rfc931 an die erste Stelle, kann
111
6 Proxies
es passieren, daß erst der Timeout der Ident-Abfrage ablaufen muß bei Clients, die das nicht unterstützen. Die benötigte Zeit wird ebenfalls beeinflußt durch die Netzwerkanbindung. Im LAN (10/100 MBit) genügt ein Wert zwischen 30 und 60 Sekunden, bei Verbindungen über ISDN oder Modem sollte der Timeout größer sein. Gegebenfalls muß man etwas experimentieren. ❏ iotimeout
Nach diesem Wert in Sekunden wird die Verbindung abgebaut, wenn keine Daten mehr übertragen werden. 0 steht für keinen Verbindungsabbruch. Das kann je nach Anwendungszweck erwünscht oder unerwünscht sein. Wie schon erwähnt, gibt es für die Regeln zwei verschiedene Klassen. Man unterscheidet zwischen Regeln, die dem Client den Verbindungsaufbau zum SOCKSServer erlauben (oder verbieten), und Regeln, die anschließend entscheiden, welche Verbindungen erlaubt sind, nachdem sich der Client erfolgreich mit dem SOCKS-Server verbunden hat. Es werden also bei jeder Verbindung immer beide Regelklassen nacheinander angewandt. Zunächst einmal die Client-Regeln, die bestimmen, ob der Verbindungsaufbau zum Proxy erlaubt ist. Diese Regeln beginnen mit dem Schlüsselwort client. In unserem Beispiel befinden sich unsere Clients im Netzwerkbereich 10.0.0.0/8. client pass { from: 10.0.0.0/8 port 1-65535 to: 0.0.0.0/0 method: rfc931 # match all idented users # that also are in passwordfile }
Hier sind alle Clients zugelassen, die sich im eigenen Netzwerk befinden und die über eine Ident-Abfrage einen User ausweisen, der auf dem SOCKS-Server im Password-File bekannt ist. Schlägt die Ident-Abfrage fehl oder ist der User nicht im Password-File, wird die Verbindung abgewiesen. ❏ client
gibt an, daß es sich um eine Client-Regel handelt, pass bedeutet – wie das Wort schon vermuten läßt –, daß die angegebenen Pakete passieren dürfen. ❏ from
bezeichnet die Client-Adresse ❏ to
steht im Zusammenhang mit Client-Regeln für die Adresse des Proxy-Servers.
112
6.2 SOCKS
❏ port
der Portbereich kann auf verschiedene Weisen angegeben werden: neben den Zeichen >, >=, =, !=, < und <= versteht der Parser auch neq, eq, ge usw. client block { from: 0.0.0.0/0 to: 0.0.0.0/0 log: connect error }
Jede weitere Verbindung wird abgelehnt. Das ist der Default, aber über eine eigene Regel kann man Details, etwa was geloggt wird, selbst definieren. Weitere Werte für das Schlüsselwort log siehe man 5 sockd.conf. Die weiteren Regeln beginnen ohne das Schlüsselwort client und bezeichnen daher die eigentlichen Verbindungsregeln. block { from: 0.0.0.0/0 to: 127.0.0.0/8 log: connect error }
Verbindungen zu den loopback-Adressen werden generell untersagt. Normalerweise kann von außen niemand auf diese Adressen zugreifen, aber man kann ja nie wissen. to bezeichnet jetzt die Zieladresse des Servers, from ist nach wie vor die Client-Adresse. block { from: 0.0.0.0/0 to: 172.16.0.0/12 libwrap: finger @%a log: connect error }
Verbindungen in den Netzwerkbereich 172.16.x.x bis 172.31.x.x werden hier unterbunden. Gleichzeitig führt die Zeile mit dem Schlüsselwort libwrap einen Finger-Befehl aus. block { from: 0.0.0.0/0 to: 0.0.0.0/0 command: bind log: connect error }
Alle Bind-Versuche werden unterbunden. Um zu verstehen, was damit gemeint ist, muß man sich etwas mit der Socket-Programmierung auseinandersetzen. Mit der Routine socket (man 2 socket) wird ein neuer Socket erzeugt, über den eine Kommunikation im Netzwerk abgewickelt werden kann. Um diesen Socket dann auch zu benutzen, muß die Verbindung aufgebaut werden. Der Client be-
113
6 Proxies
nutzt dann dazu die Routine connect (man 2 connect). Für die Client-Seite ist das genug. Ein Serverdienst aber, der auf eingehende Verbindungen wartet, muß den unbenannten Socket an einen Namensraum binden, bevor er mit den Routinen listen und accept auf eingehende Verbindungen reagieren kann. Dazu dient die Routine bind. In diesem Sinne ist auch die Zeile command: bind
zu verstehen. Mit der Regel wird unterbunden, daß ein Client ein bind durchführt und damit einen Socket für eingehende Verbindungen öffnet. Das kann zum Beispiel der Fall bei aktivem FTP-Datentransfer sein. Bei aktiven FTP-Verbindungen öffnet der Client einen eigenen Socket und teilt dies dem FTP-Server mit, der wiederum dann eine Verbindung zu diesem Socket des Client aufbaut. bind ist also verbunden mit dem eigenmächtigen Öffnen für eingehende Verbindungen durch den Client. In der Regel kann das ganz unterbunden werden, für FTP gibt es die Möglichkeit des passiven Transfers. Dort baut der Client sowohl die FTP als auch die FTP-Data-Verbindung von sich aus auf, ein bind ist also nicht nötig. In der Übersicht hier die möglichen Werte für command: ❏ bind
Wie beschrieben, der Versuch eines Client, einen eigenen Socket zu schaffen, um auf eingehende Verbindungen zu warten. ❏ bindreply
Das Gegenstück zu bind. Wenn ein ausgehender bind erlaubt ist, muß gleichzeitig auch ein eingehender bindreply erlaubt sein. In der Regel geschieht dies mit from: 0.0.0.0/0. ❏ connect
Der normale Verbindungsaufbau eines Client. ❏ udpassociate ❏ udpreply
UDP-Verbindungen lassen sich nicht so einfach beschreiben wie TCP-Verbindungen. Es gibt keine Verbindungsauf- und -abbau wie bei TCP. Mit udpassociate werden Pakete erfaßt, die eine UDP-Verbindung starten, mit udpreply alle Pakete, die als Antwort auf eine UDP-Anfrage folgen könnten. Die folgende Regel erlaubt eingehende Replies. Wenn ein Client die Erlaubnis hat, einen Bind durchzuführen, macht es Sinn, die Antwort darauf auch von beliebigen Hosts zu erlauben.
Im folgenden ein Beispiel für einen Verbindungsaufbau, bei dem sich der User authentifizieren muß: pass { from: 10.0.0.0/8 to: .example.com port = http log: connect error method: username } # block any other http connects to the example.com domain. block { from: 0.0.0.0/0 to: .example.com port = http log: connect error }
Kann sich der User nicht authentifizieren oder kommt die Verbindungsanfrage nicht aus dem Netzwerk 10.0.0.0/8, dann wird die Verbindung abgelehnt. Um internen Clients alles zu erlauben, kann man folgende Regel verwenden (ob das immer erwünscht ist, hängt von dem Einsatzzweck des Proxy ab): #pass { # from: 10.0.0.0/8 to: 0.0.0.0/0 # protocol: tcp udp #}
Hier wird auch von der Möglichkeit Gebrauch gemacht, die Regel in Abhängigkeit vom Protokoll zu definieren. Man sollte sich allerdings immer überlegen, ob es nicht besser ist, command zu verwenden, weil man damit viel feiner steuern kann. Und last but not least, die Ausputzerregel, die alle anderen Verbindungen sperrt. Zwar ist das wieder der Default, aber mit einer eigenen Regel hat man auch die Möglichkeit, Details selbst zu steuern, etwa die Protokollierung: block { from: 0.0.0.0/0 to: 0.0.0.0/0 log: connect error }
115
6 Proxies
Weitere Informationen zu den Konfigurationsmöglichkeiten finden sich mit man 5 sockd.conf bzw. in dem mitgelieferten /etc/sockd.conf.
6.2.4
Clients mit SOCKS (Socksifying)
Aktuelle Browser wie Netscape haben einen Builtin-Socks-Support, können also auch ohne Anpassung mit einem SOCKS-Server zusammen arbeiten. Aber verschiedene Programme sind nicht von vornherein SOCKS-fähig. Um einen bisher nicht „socksifizierten“ (von nun an ohne Anführungszeichen) Client SOCKS-fähig zu machen, gibt es zwei Wege: zum einen kann man einen dynamisch gelinkten Client dazu bewegen, vor allen anderen Libraries eine SOCKS-Library zu laden, die die Netzwerkaufrufe abfängt und socksifiziert. Der zweite Weg ist, das Programm neu zu übersetzen. Der erste Weg ist der bequemste, wenn er möglich ist. Man muß nur dafür sorgen, daß beim Clientstart die Library libdsocks.so geladen wird. Der Vorteil liegt klar auf der Hand: weder muß der Source-Code geändert werden, noch muß das Programm neu übersetzt werden. Technisch gesehen setzt man über die Environment-Variable LD_PRELOAD die Socks-Library vor den eigentlichen Netzwerkcalls. Um dem Anwender es so einfach wie möglich zu machen, wird bei Dante ein fertiges Skript /usr/bin/socksify mitgeliefert. Der Aufruf des entsprechenden Client ist dann denkbar einfach: % socksify ftp
Clients, die mit Set-UID oder Set-GID laufen, ignorieren allerdings diesen Mechanismus. Um eine Neukompilation kommt man dabei leider nicht herum. Bei einer Neukompilation gibt es wiederum zwei Varianten: dynamisch gelinkte Programme lassen sich in der Regel mit der Dante-SOCKS-Library einfach neu übersetzen. Eine Source-Code-Anpassung ist dabei nicht erforderlich. Statisch gelinkte Programme erfordern eine Änderung im Source-Code. So müssen die Original-Socket-Routinen ersetzt werden durch die SOCKS-Routinen. Entsprechende Anleitung findet man in der Source-Distribution von Dante. Während man bei einem Client mit Builtin-SOCKS-Support eine Konfigurationsmöglichkeit aus dem Programm heraus angeboten bekommt, benötigt man bei socksifizierten Clients einen anderen Weg, um ihnen den SOCKS-Server mitzuteilen. Das erledigt die SOCKS-Library, die auf ein Konfigurationsfile zurückgreift (/etc/socks.conf). Es handelt sich hierbei um die Konfiguration der Clients, nicht des Server, das heißt, zum einen muß diese Konfiguration bei allen in Frage kommenden Hosts installiert sein, von denen aus über den SOCKS-Server Verbindungen aufgebaut
116
6.2 SOCKS
werden sollen, und es müssen darin die lokalen Gegebenheiten der Netzwerkumgebung des Client berücksichtigt sein. Es ist zum Beispiel wenig sinnvoll, wenn der Client einen im selben Netzwerk befindlichen Server über den Proxy abfragt, bzw. wenn er statt eines vielleicht vorhandenen lokalen Nameserver ebenfalls immer über den Proxy geht. Das Konfigurationsfile besteht wieder aus zwei Abschnitten: einige allgemeine Einstellungen, anschließend die einzelnen Routinginformationen, welche Klasse von Paketen den Proxy benutzen soll, und welche nicht. # # # # # # # # # # # # # # # #
:/etc/socks.conf recommended order is: misc settings: [debug] [logoutput] [resolveprotocol] routes: route from to via [command] [extension] [protocol] [proxyprotocol]
#debug: 1
# uncomment to enable debugging
#logoutput: stdout
# users usually don’t want to be # bothered with that.
# What protocol should be used for resolving hostnames? # It’s important to set this right. resolveprotocol: udp #resolveprotocol: tcp
# default
# # #resolveprotocol: fake # # #
set this if your socksserver only supports socksv4. set this if your clients can’t access nameserver, neither directly nor proxied via socks.
Bei logoutput sind dieselben Werte möglich wie bei der Serverkonfiguration. Normalerweise irritiert der Output eher die Anwender, eine bessere Alternati-
117
6 Proxies
ve wäre es, Syslog zu verwenden und den Output auf einen zentralen SyslogServer umzuleiten, um eine zentrale und gegebenenfalls automatische Auswertung zu ermöglichen. Standard-Protokoll für DNS-Resolve-Anfragen ist in den meisten Fällen UDP, auf die anderen Möglichkeiten sollte man nur ausweichen, wenn noch ein Proxy ins Spiel kommt, der UDP nicht beherrscht (etwa der MSPROXY). Nun folgen die einzelnen Routen. Man kann eventuell von der Möglichkeit Gebrauch machen, auch lokale Verbindungen über den Proxy zu routen. Allerdings sollte man dann dafür sorgen, daß – wenn möglich – Anfragen an den lokalen Nameserver aus Performance-Gründen direkt zugelassen werden. Allerdings muß dabei die lokale Nameserver-Konfiguration beachtet werden (löst der lokale Nameserver auch externe Anfragen auf oder muß dafür ein weiterer Nameserver konsultiert werden?). Unser lokaler Nameserver besitzt die IP-Adresse 10.1.1.1: route { from: 0.0.0.0/0 to: 10.1.1.1/32 port = domain via: direct }
Ohne lokalen Nameserver entfällt die Anfrage, der Proxy übernimmt die Namensauflösung vollständig. route { from: 0.0.0.0/0 to: 127.0.0.0/8 via: direct command: connect udpassociate # everything but bind, # bind confuses us. }
Verbindungen zum lokalen Interface (Loopback Adresse) sollen direkt erfolgen, der Umweg über den Proxy macht auch keinen Sinn. route { from: 0.0.0.0/0
to: 10.0.0.0/8
via: direct
}
Alle Verbindungen vom Client zum lokalen Netzwerk sollen in dieser Konfiguration ebenfalls direkt erfolgen. Hat man aus irgendwelchen Gründen auch noch einen MS-PROXY-Server, dann kann dieser ebenfalls mitbenutzt werden. Anwender desselben bezeichnet die mitgelieferte Beispielkonfiguration als „arme Seelen“. #route { # from: 0.0.0.0/0 to: 0.0.0.0/0 via: 10.1.1.1 port = 1745 # protocol: tcp # server supports tcp # proxyprotocol: msproxy_v2 # server runs msproxy_v2 #}
118
6.3 TIS Firewall Toolkit
Alle weiteren Verbindungen sollen über den SOCKS-Server 10.1.1.2 laufen. Vorsicht: man sollte hier immer die IP-Adresse angeben, außer man ist sich ganz sicher, daß eine Namensauflösung durch eine vorhergehende Regel bereits erlaubt und erfolgt ist. Anderfalls produziert man eine Endlosschleife. route { from: 0.0.0.0/0 to: 0.0.0.0/0 via: 10.1.1.2 port = 1080 protocol: tcp udp # server supports tcp and udp. proxyprotocol: socks_v4 socks_v5 # server supports socks v4 and v5. method: none # we are willing to authenticate # via method "none", not "username". }
Erlaubte Proxy-Protokolle sind sowohl SOCKS V4 als auch V5, eine Authentifizierung der User soll nicht erfolgen. Hier muß man sich die Logik genau überlegen: in der Clientkonfiguration ist die Authentifizierung diejenige, die der Client dem Server anbietet. In der Serverkonfiguration stehen die Authentifizierungsmethoden, die der Server durchgehen läßt. Ist die Schnittmenge aus ClientMethode und Server-Methode gleich Null, kommt es zu keiner Verbindung. route { from: 0.0.0.0/0 to: . via: 10.1.1.1 port = 1080 protocol: tcp udp # server supports tcp and udp. proxyprotocol: socks_v4 socks_v5 # server supports socks v4 and v5. method: none #username # we are willing to authenticate # via method "none", not "username". }
Das ist dieselbe Regel noch einmal, mit dem einzigen Unterschied, daß als Zielangabe keine IP-Adresse, sondern ein Hostname erlaubt ist. Das ist wichtig bei Clients, die den Hostnamen nicht selbst auflösen können, etwa weil kein lokaler Nameserver zur Verfügung steht. Im mitgelieferten Konfigurationsfile wird darauf hingewiesen, daß es durchaus einen Unterschied macht, in welcher Reihenfolge die beiden Regeln stehen. Man sollte immer zuerst die IP-basierte Regel setzen, dann die Regel mit (nicht aufgelösten) Hostnamen.
6.3 TIS Firewall Toolkit Das Firewall Toolkit (FWTK) von Trusted Information Systems (TIS, gehört jetzt zu Network Associates, siehe auch www.tis.com), ist ein frei verfügbares, aber nicht lizenzfreies Paket, bestehend aus mehreren Application-Proxies und einem generischen Proxy. Nicht lizenzfrei heißt, es gibt durchaus eine restriktive Li-
119
6 Proxies
zenz, die die Weiterverbreitung des Pakets stark einschränkt. Zwar kann das Paket durchaus kostenlos auch im kommerziellen Umfeld eingesetzt werden, aber immer nur ausschließlich für eigene, interne Zwecke. Das Lizenzierungsverfahren ist etwas eigenwillig: man liest sich auf der Homepage www.tis.com die Lizenz durch und sendet dann eine Mail an eine dort angegebene Adresse, in der man bestätigt, daß man mit den Lizenzbestimmungen einverstanden ist. Als Antwort darauf erhält man eine Mail mit einer FTPAdresse, unter der man den Source-Code findet. Diese FTP-Adresse wechselt regelmäßig, man muß innerhalb von 12 Stunden den Source-Code laden. Die Lizenzbestimmung enthält auch die Aussage, daß man auf keinen Fall diese Location an Dritte weitergibt – der Hersteller will so sicherstellen, daß alle Nutzer das Registrierungsverfahren durchlaufen. Es gibt Vorbehalte gegen den Einsatz des FWTK. Neben der restriktiven Lizenz werden schlechte Pflege und einige Sicherheitsprobleme, u. a. mit langen Dateinamen, genannt. Trotz all dieser Umstände hat das Paket seine Daseinsberechtigung als vielleicht ältestes, relativ vollständiges Application-Proxy-Paket. Es ist weit verbreitet, findet sich in wichtigen Publikationen (zum Beispiel auch dem Linux Firewall-HOWTO) und es gibt eine Mailingliste, in der fleißig über Konfigurationsprobleme, Anwendungsmöglichkeiten etc. diskutiert wird. Nicht unerwähnt bleiben sollte die kommerzielle Variante des TIS-FWTK’s: der „Gauntlet Internet Firewall“. . Es handelt sich um eine Weiterentwicklung und Erweiterung aus dem FWTK heraus. Da in diesem Buch keine kommerziellen Firewalls behandelt werden, sei für weitere Informationen auf die Homepage des Herstellers verwiesen www.tis.com.
6.3.1
Bestandteile des TIS-FWTK
Die Komponenten des FWTK im einzelnen: ❏ Netacl
Netacl ist ein TCP-Wrapper. Gegenüber anderen TCP-Wrappern (der bekannteste ist wohl tcpd von Wietse Venema) fügt sich Netacl in das Gesamtkonzept des FWTK ein. Er kann so zum Beispiel abhängig vom Zugriff entweder den einen Dienst wie Telnet direkt erlauben oder alternativ den dazugehörigen Proxy starten. Darüber hinaus verfügt Netacl über die Möglichkeit, einen Dienst in einer Chroot-Umgebung zu starten. ❏ Telnet-Gateway ❏ FTP-Gateway ❏ Rlogin-Gateway
120
6.3 TIS Firewall Toolkit
❏ HTTP-Gateway ❏ X-Gateway
Application-Gateways, die auf den jeweiligen Dienst zugeschnitten sind. ❏ SMTP-Gateway
Ein Application-Gateway für SMTP, das auf dem Store-and-Forward Prinzip besteht. Es arbeitet als vorgeschalteter SMTP-Daemon, der eingehende Mails entgegennimmt und zwischenspeichert. Hauptzweck ist es, einen Sendmail-Daemon, der immer wieder neuen Angriffsvarianten ausgesetzt ist, zu schützen, in dem man ein möglichst kleines, überschaubares Programm mit einem sehr begrenzten Befehlssatz dazwischen schiebt und den eigentlichen Sendmail generell vor Zugriffen von außen schützt. Der Daemon, der die Mails entgegen nimmt, muß auch nicht unter rootRechten laufen, daß erledigt ein zweiter Daemon, der allerdings ebenfalls wie der Sendmail keinen Außenkontakt hat, sondern nur die eingegangenen Mails in Form von Files aus einem Verzeichnis liest. ❏ Plug-Gateway
Hinter dieser Bezeichnung steckt ein generischer Proxy, deshalb kann man auch das TIS-FWTK als „vollständig“ bezeichnen, weil man damit weitere Dienste abdecken kann, für die kein applikationsspezifischer Proxy mitgeliefert wird. Die zentrale Konfigurationsdatei ist netperm-table, wir gehen hier davon aus, daß sich die Datei in /etc befindet und die Proxies in /usr/sbin. Hier ein einfaches Konfigurationsbeispiel für Telnet: # # /etc/netperm-table # netacl-in.telnetd: permit-hosts 192.168.1.2 \ -exec /usr/sbin/in.telnetd netacl-in.telnetd: permit-hosts * -exec /usr/sbin/tn-gw # tn-gw: timeout 90 tn-gw: permit-hosts 192.168.1.* -passok -xok
Die dazugehörige Zeile in /etc/inetd.conf sieht dann so aus: telnet stream tcp nowait root /usr/sbin/netacl telnetd
Abhängig von der Client-IP-Adresse ist wird ein direkter Zugriff auf den TelnetDaemon erlaubt, oder der Client wird auf den Proxy geleitet. In der ProxyKonfiguration entscheidet sich dann, ob überhaupt ein Zugriff möglich ist. Hier ist nur der Zugriff aus dem internen Netzwerk 192.168.1.0/24 möglich, andere Clients werden abgelehnt.
121
6 Proxies
Das TIS-FWTK wird aufgrund der restriktiven Verteilungspolitik der Linux-Distributoren nicht weiter unterstützt. Hier sollte nur grundsätzlich aufgezeigt werden, wie das TIS-FWTK funktioniert. Weitere Informationen dazu finden sich auf der Homepage von TIS (www.tis.com) und natürlich im Source-Package, vor dessen Laden man sich notwendigerweise auch genauer mit der Lizenzpolititk auseinandersetzen muß. Ferner sei auf die Mailingliste ([email protected]) verwiesen. Angaben dazu finden sich ebenfalls auf der Homepage von TIS.
6.4 Ausblick HTTP und Proxies Bei vielen Diensten reicht in vielen Fällen ein generischer Proxy für ausgehende Verbindungen aus. Bei HTTP verbindet man aber in der Regel verschiedene Forderungen mit dem Begriff Proxy: ❏ Caching von Websiten
Lokales Zwischenspeichern häufig benutzter Webseiten beschleunigt das Lesen und reduziert den Datentransfer aus dem Internet. ❏ Authentifikation von Anwendern
Klassifizierung der User, meist mit entsprechender Protokollierung verbunden. ❏ Schutz des eigenen Netzwerks vor Eindringlingen
Ein Proxy ermöglicht – wie in diesem Kapitel beschrieben –, eine stärkere Entkopplung von lokalem und externen Netzwerk auf Netzwerkebene. ❏ Filtern von Webseiten mit unerwünschtem Inhalt
Inhalte mit kriminellen, pornographischen, extremistischen und rassistischen Inhalten sollen gefiltert werden, aber manchmal auch Positivlisten für ausschließlich erlaubte Seiten zur (dienstlichen) Benutzung gelten. ❏ Filtern von Tags mit Gefährdungspotential
Immer häufiger tauchen Angriffsvarianten auf, die über Inhalte direkt den Client bzw. dessen Sicherheitslücken attackieren (meist Skripting-Tags, manchmal auch Exoten wie Bufferoverflow durch Kommentare in Bildern). Für das Caching von Webseiten ist Squid (www.squid-cache.org) wohl inzwischen ein weit verbreiteter Standard geworden. Als Proxy erlaubt Squid auch die Trennung von internem und externem Netzwerk, außerdem verfügt Squid über eine rudimentäre Authentifizierung. Als Ergänzung zu Squid kann dann SquidGuard (www.squidguard.org) verwendet werden, um flexibel Webseiten mit unerwünschtem Inhalt zu filtern, bzw. die Anwender zu authentifizieren. Was aber auch die Kombination aus Squid und SquidGuard nicht leistet, ist die Filterung von gefährlichen Inhalten.
122
6.4 Ausblick
Als Alternative zum http-gw aus dem TIS-FWTK kann man auch auf httpf zurückgreifen (http://httpf.source-forge.net/). httpf filtert ausschließlich Inhalte (Content-Filtering), wobei das Konzept verfolgt wird, daß alle MIMETypen außer text/html explizit erlaubt werden müssen. Ein weiteres interessantes Projekt ist Muffin muffin.doit.org, ein HTTP-ProxyServer mit Filtermöglichkeiten und Remote-Administrierbarkeit, vollständig geschrieben in Java. Ob man soweit gehen will, alle „aktiven“ Inhalte abzuschalten (ActiveX, Java, Javascript), muß im Einzelfall entschieden werden, damit geht dann auch Funktionalität verloren, was die Anwender nicht immer danken. Auf der anderen Seite läßt sich damit in größeren Netzwerken verhindern, daß eine ganze Mannschaft von Systemadministratoren täglich den neuesten Patches für Browser nachjagt und installiert. Ressource Internet Bei der Vielzahl an Neuerscheinungen ist es unmöglich, auch nur einen kleinen Abriß aller Proxies zu geben, die zur Zeit verfügbar sind. Wer sich tiefer mit der Materie befaßt, wird des öfteren auch mal stöbern gehen und neue Dinge ausprobieren. Gute Einstiegspunkte sind ❏ freshmeat.net: Kategorie Daemon/Proxy ❏ www.security-focus.com: unter Tools nach Proxy oder ähnlichen Stich-
wörtern suchen ❏ www.white-hats.com: eigene Tool-Zusammenstellung ❏ www.linuxportal.com
123
6 Proxies
124
Kapitel 7 Internetdienste und Firewalls Jeder Firewall hat im Gegensatz zu einer vollständigen Abschottung des privaten Netzwerks die Aufgabe, bestimmte erwünschte Dienste zu gestatten. Wieviele oder wie wenige, legt die Sicherheitspolitik fest. Um bei der technischen Implementierung des Firewalls Feinheiten berücksichtigen zu können, ist es sinnvoll, sich mit den Besonderheiten der einzelnen Internetdienste vertraut zu machen. Manche besitzen eine implizite Proxy-Eigenschaft (SMTP), andere sind in vielen Fällen auch gut ohne Proxy verwendbar (SSH), wieder andere sind wesentlich aufwendiger (FTP) oder für Firewalls völlig ungeeignet (NFS). Im folgenden wird auf die wichtigsten Internetdienste, ihre Charakteristik und ihr Zusammenspiel mit Firewalls eingegangen. Während die Charakteristik schon Aufschluß über die Filterung auf einem Standalone-Host gibt, orientiert sich die Darstellung für Firewallumgebungen dabei an einem Firewall mit Grenznetz, um größtmögliche Sicherheit mit den in diesem Buch vorgestellten Mitteln zu bieten. Bei einfacheren Firewallkonzepten ist eine entsprechende Anpassung erforderlich. Praktische Beispiele für Zwischenvarianten finden sich im Kapitel über den Firewallbau 8. Als Ergänzung kann der Host, der den Dienst anbietet, sich selbst vor Eindringlingen schützen. Bei einfacheren Firewalls mit niedriger Sicherheitsstufe ist das ein Muß, aber auch beim Einsatz eines komplexeren Firewalls sollte sich der einzelne Host, der den gewünschten Dienst anbietet, nicht auf die Unfehlbarkeit des Firewalls verlassen. Der Abschnitt 7.2 am Ende dieses Kapitels beschäftigt sich mit den Startmechanismen und dazu gehörigen Sicherheitsaspekten. Eine zusätzliche Möglichkeit, einzelne Hosts zu sichern, ist die lokale Paketfilterung. Jeder Linux-Host besitzt über den Kernel quasi einen eingebauten Paketfilter (siehe Abschnitt 5).
125
7 Internetdienste und Firewalls
7.1 Häufig benutzte Internetdienste 7.1.1
E-Mail: SMTP/POP3
Der wohl elementarste Dienst im Internet ist Electronic Mail („E-Mail“ oder auch einfach „Mail“). Hier taucht eine Vielzahl von Fachbegriffen auf, deshalb sollen einige Grundzüge des Electronic Mailing kurz dargestellt werden. Im Internet wird eine Mail im Push-Verfahren („schieben“) von Server zu Server weitergereicht. Es gab zunächst keinen Mechanismus, der ein Pollverfahren zuließ („holen“, nach dem Motto: „schau mal nach, ob Mail da ist“). Ein Pollverfahren wurde zwar später entwickelt, wird aber ausschließlich von Clients eingesetzt und ist unter Servern nach wie vor nicht üblich. Erhält ein Server eine Mail, wird diese von ihm angenommen und zwischengespeichert. Dann trifft er eine Entscheidung über die weitere Zustellung und nimmt diese vor. Das Programm, das diese Funktionalität auf dem Mailserver zur Verfügung stellt, wird auch als „Mail Transport Agent“ (MTA) bezeichnet. Der MTA eines Internet-Mailserver muß im Prinzip beliebig von außen erreichbar sein. Der wohl häufigste im Internet eingesetzte MTA ist sendmail. Andere MTAs sind MMDF, PMDF, smail, qmail und postfix. Stellt der MTA fest, daß die Mail lokal zugestellt werden soll, übergibt er die Mail dem Mail Delivery Agent (MDA) . Der MDA handelt lokale Gegebenheiten wie Aliases und .forward-Mechanismen ab. Manche MDAs sind externe Programme und hochgradig programmierbar (procmail zum Beispiel), andere sind bereits funktional in das Programm integriert, das den MTA stellt (bei smail zum Beispiel). Der dritte Agent im Bunde ist der „Mail User Agent“ (MUA); er dient dazu – wie der Name schon sagt –, dem lokalen User Zugriff auf seine Mail zu ermögichen. Eine schematische Übersicht über das Zusammenwirken von MTA, MDA und MUA gibt Abbildung 7.1. Mail Transport Agents reichen sich die Mail über das Protokoll SMTP weiter. SMTP ist ein sehr einfaches Protokoll, das nur eine Handvoll von Kommandos versteht und über keine eingebauten Sicherheitsmechanismen verfügt. Sicherheitsproblematik bei Mail Da die meisten MTAs unter root-Rechten laufen, stellen MTAs auch ein beliebtes Angriffsziel dar. Kann der MTA von außen mißbraucht werden, erhält der Angreifer root-Privilegien. Folgende Arten von Angriffen sind denkbar:
126
7.1 Häufig benutzte Internetdienste
Abbildung 7.1: Mailzustellung: Zusammenwirken von MTA, MDA und MUA
❏ Angriffe über SMTP-Befehle.
Ältere Versionen von sendmail ermöglichen über einige Befehle das Ausführen von Shellkommandos oder Programmaufrufen. Insbesondere die Befehle debug, wiz und kill sollten nicht erlaubt sein. Da solche Angriffe auf Sicherheitsmängeln in den MTAs basieren, kann man ihnen begegnen, indem man immer die aktuellste Version des verwendeten MTAs einsetzt. Gerade bei sendmail gehört das ständige Patchen zum Alltag. Hinweise auf gerade aktuelle Sicherheitslücken findet man über die Internet-Quellen, auf die im Anhang E verwiesen wird. ❏ Angriffe über Dateninhalte.
Dabei ist zu unterscheiden, ob der MTA bzw. der MDA oder der Mailclient des Endanwenders (MUA) angegriffen werden soll. Angriffe auf den MTA oder MDA basieren auf Mechanismen in der Implementierung, die es zulassen, daß Textinhalte der Mail interpretiert werden. Solche Angriffe lassen sich in der Regel über Bugfixes/Updates des MTA/MDA vermeiden. Wesentlich schwieriger in den Griff zu bekommen sind Angriffe auf die Mailclients. Der wohl populärste Angriff 1999 war „Melissa“, der sich die Programmierbarkeit von Microsoftclients zunutze machte und wahllos Mails an die 50 nächsten User aus den verfügbaren Adreßbüchern schickte (Schneeballsystem). Hier helfen nur Virenscanner, die entweder im Mailstrom oder auf dem Arbeitsplatz des Anwenders solche Viren erkennen, melden und vernichten. ❏ Relay-Mißbrauch.
Damit bezeichnet man das Versenden von E-Mails von fremden Mailservern aus. Solche werden als Relay mißbraucht, um den eigentlichen Absender unerkannt zu lassen. Zu welchem Zweck? Im Internet hat in letzter Zeit sogenannte UCE (Unsolicited Commercial E-Mail), besser bekannt unter dem Begriff „Spam“ (nach dem gleichnamigen Dosenfleisch, das überwiegend in Großbritannien und USA verkauft wird) stark zugenommen. Bei solchen
127
7 Internetdienste und Firewalls
Werbemails ist der Absender stark daran interessiert, nicht erkannt zu werden, um nicht mit Mailbomben verärgerter Anwender zugeschüttet oder anderweitig haftbar gemacht werden zu können. Da einfach gefälschte Absenderadressen mit etwas Aufwand identifiziert werden können, versuchen Spammer, ihre Mails von einem normalen, sonst unbescholtenen Mailserver aus abzusenden. So eine Mail kommt dann von einem normalen, real existierenden Mailhost mit dessen Senderadresse. Die Eigentümer des mißbrauchten Mailservers bekommen in der Regel erst dann etwas mit, wenn sich belästigte Internetuser über Spam bei einem Administrator beschweren. Der Mißbrauch an sich wird erst durch das Protokoll SMTP ermöglicht. SMTP läßt keine Authentifizierung zu, d. h. theoretisch könnte jeder über einen x-beliebigen Mailhost im Internet Mails unter falscher Kennung versenden. Zwar haben in der Praxis fast alle MTAs Mechanismen eingebaut, die bei eingehender SMTP-Mail versuchen, die Existenz der Absendeadresse zu verfizieren und ggf. die Mail zu verwerfen. Das geschieht allerdings nicht automatisch, sondern ist Konfigurationssache. Trotz der Verfügbarkeit von Sicherheitsmechanismen, die solchen Mißbrauch verhindern sollen, gibt es immer noch viel zu viele Mailhosts im Internet, die kaum etwas für ihre Sicherheit tun. Neben der Gefahr, entweder fälschlicherweise als Absender mit Mailbomben zugeschüttet zu werden und sich den Ärger von betroffenen Anwendern zuzuziehen, kann man damit auch auf eine sogenannte Black List geraten. Viele Internetprovider verweigern den Transport von Mails, die als Absender eine Adresse enthalten, die auf einer solchen Black List steht. Damit ist jeglicher Versand von Mails ins Internet unmöglich. ❏ Angriffe über Datenmenge.
Ein solcher Angriff zielt nicht darauf ab, in das System einzudringen, sondern es funktionsunfähig zu machen (Denial of Service Attacke), indem es mit einer Unzahl von Mails überflutet wird. Je nach Abhängigkeit von funktionierenden Mailverbindungen kann dadurch ein enormer Schaden entstehen, wenn ein zentraler Mailserver für Stunden oder Tage nicht bestimmungsgemäß funktioniert. Typische Vertreter sind Mailbomben (mehrere 100 bis 1000-faches Zusenden derselben Mail) oder List-Linking (Eintragen eines Anwenders in mehrere hundert Mailinglisten, die ein hohes Datenaufkommen je Tag haben). Postoffice beim Provider In kleinen Umgebungen oder bei Standalone-Rechnern liegt das aus dem Internet erreichbare Postoffice beim Provider, d. h., Ihre E-Mail-Adresse wird beim Provider als lokale Adresse behandelt (statt diese an einen anderen Mailserver
128
7.1 Häufig benutzte Internetdienste
Abbildung 7.2: SMTP-Kommunikationsprofil
weiterzuleiten). Damit wird die Mail nicht über SMTP automatisch zugestellt, sondern muß gesondert abgeholt werden (siehe Abschnitt über POP3). Beim Versenden ist es im Grunde einerlei, woher die Mail kommt, sofern bestimmte Spielregeln beim Setzen der Mailheader eingehalten werden. Ein ReplyTo sollte korrekt ankommen, und die From-Adresse sollte eine im Internet gültige sein, andernfalls kann es passieren, daß Mailserver, die sich vor Spam schützen wollen, eine solche Mail zurückweisen. Im Gegensatz zur Windows-Welt gibt es unter Linux (und anderen Unixen) immer einen MTA, so daß der Client (MUA) selten direkt die Mails an den ProviderMailserver sendet. Sind mehrere Rechner im Netz, kann man einen Host so konfigurieren, daß der Versand in das Internet über einen solchen Rechner erfolgt. Die Firewallkonfiguration beschränkt sich hier auf eine reine Paketfilterung, die ausschließlich ausgehende SMTP-Verbindungen zum Internet-Provider zuläßt (siehe Abbildung 7.2). ❏ Konfiguration des Paketfilters
internes Netz Adresse Port Mailhost
Verbindungsaufbau
1023
externes Netz Adresse Port Mailserver Prov.
25
Protokoll TCP
Für die Abholung von Mails wird häufig POP3 eingesetzt, das im folgenden Abschnitt behandelt wird. Post Office Protocol (POP3) Das „Post Office Protocol“ POP wurde in erster Linie für PC-Clients entwickelt, die anders als Mailserver nicht ständig erreichbar sind, weil diese regelmäßig abgeschaltet werden. Statt mit SMTP die Mail an den Client zu senden, holt sich der User mit einem Mail User Agent (MUA) die Mail aktiv beim Server ab. Nebeneffekt: die Mail kann von überall dort abgeholt werden, wo der User gerade
129
7 Internetdienste und Firewalls
arbeitet. Die Zustellung ist nicht mehr an einen Host gebunden. Die gängigste Variante ist POP3 („Post Office Protocol Version 3“). POP bringt ein Sicherheitsproblem mit sich: weder Passwörter noch Inhalte werden verschlüsselt übertragen, sondern sind im Klartext lesbar. KPOP, eine Variante mit Kerberos (Verschlüsselung mit Einmalpasswörtern) unterstützen nur wenige Clients, und Kerberos ist in den meisten Fällen serverseitig gar nicht verfügbar. Aufgrund der Mängel mit den Klartextpasswörtern eignet sich POP nicht für Verbindungen von oder in das Internet. Wenn nun das Postoffice beim Provider liegt, hat man oft keine andere Möglichkeit, als sich die Mails über POP3 abzuholen (über Programme wie fetchmail etwa, die die Mail über POP3 holen und dann in das lokale Postfach abstellen). Wie sicher die Verbindung tatsächlich ist, hängt von den jeweiligen Gegebenheiten ab. Hat man sein Postfach bei dem Provider, der die Internetverbindung stellt, und verfügt dieser über ein eigenes Netzwerk, in das man sich direkt einwählt, dann wird zwar immer noch das Klartextpasswort übertragen, aber eben nur über eine Telefonleitung. Die Wahrscheinlichkeit, daß der Datenaustausch dann über offene Teile des Internet erfolgt, ist recht gering. Bei manchen Providern erfolgt die Identifizierung über die Zugangsdaten zum Einwählknoten, als POP3Passwort wird dann nur ein Dummy-Passwort verwendet. Da das Passwort in diesem Falle nicht zur Authentifikation benutzt wird, stellt die Klartextübertragung auch kein Problem dar. Sehr unsicher sind auf jeden Fall die weit verbreiteten kostenlosen Internetaccounts, die Mailpostfächer und andere Leistungen anbieten, ohne über eine eigene Infrastruktur im Netzwerkbereich zu verfügen. Die Kommunikation läuft dann meist offen über das Internet. Die einzige Möglichkeit ist dann nur noch, die Kommunikation zu Verschlüsseln (etwa SSL oder in seltenen Fällen auch mit einem SSH-Tunnel). ❏ Konfiguration des Paketfilters
internes Netz Adresse Port Mailhost
1023
Verbindungsaufbau
externes Netz Adresse Port Mailserver Prov.
110
Protokoll TCP
Weitere Möglichkeiten zur Abholung von E-Mail Neben POP taucht immer häufiger IMAP auf. IMAP verfolgt dabei einen ganz anderen Zweck: im Gegensatz zu POP, wo die Mail komplett abgeholt werden soll, ist IMAP dafür konstruiert, die Mails generell auf dem Server zu belassen und dort zu lesen. Das macht vor allem bei internen Mailservern Sinn. Für die Bereitstellung von Mails auf Servern des Internetproviders unterscheidet sich
130
7.1 Häufig benutzte Internetdienste
IMAP nicht wesentlich von POP, da zwar einige zusätzliche Features zur Verfügung gestellt werden, die Mail aber doch nicht beim Internet-Provider am Server verbleibt, sondern abgeholt und dort gelöscht wird. Unter Sicherheitsaspekten ist IMAP genauso kritisch zu sehen wie POP. Firewall mit eigenem Mailserver Innerhalb einer Firewallumgebung bietet es sich an, die Mailanbindung nach draußen funktional zu trennen von dem eigentlichen internen Postoffice, das den Usern das Empfangen und Versenden von Mails ermöglicht. Der externe Mailserver kann auf dem Bastion Host installiert werden. Abbildung 7.3 zeigt solch eine Anordnung mit internem und externem Mailserver (SMTP-Gateway). Der externe Mailserver hat dabei folgende Aufgaben: ❏ Schutz vor Angriffen über SMTP-Befehle.
Auf dem SMTP-Gateway müssen Maßnahmen ergriffen werden, um befehlsgesteuerte Angriffe zu unterbinden. Der SMTP-Daemon, der die SMTPBefehle und die Daten annimmt, sollte möglichst nicht unter root-Rechten laufen. Entweder setzt man einen MTA ein, der bereits unter Sicherheitsaspekten konstruiert wurde (qmail, postfix), oder man verwendet einen siche-
Abbildung 7.3: SMTP-Server im Firewall
131
7 Internetdienste und Firewalls
ren Proxy wie smap. smap ist Bestandteil des TIS Firewall Toolkits FWTK (siehe Abschnitt 6.3; dort wird auch auf die lizenzrechtliche Situation von FWTK hingewiesen). Das Prinzip von smap ist einfach: ein Daemon, der nur die nötigsten Befehle von SMTP versteht und unter völlig unprivilegierten Rechten läuft, nimmt die Daten entgegen und speichert diese in Files zwischen. Ein weiterer Prozeß liest regelmäßig das Verzeichnis aus und leitet vorhandene Mails an den eigentlichen MTA weiter. Nachteilig ist vielleicht, daß die Entwicklung von smap aktuellen MTAs hinterher läuft. Während auf ESMTP (Extended SMTP) noch am ehesten verzichtet werden kann, gehen die UCE-Features (UCE = Unsolicited Commercial E-Mails) gegen Spam verloren, da die Mail in der Regel erst angenommen wird, bevor über deren weiteren Verbleib entschieden werden kann. ❏ Schutz vor Relay-Mißbrauch.
Mailserver, die sich selbst nicht vor Mißbrauch schützen, stellen für die anderen Anwender im Internet eine potentielle Gefahr dar. Da von solchen ungeschützten Mailservern leicht Spam/UCE versendet werden kann, ist solch ein Host vergleichbar mit einem Patienten, der unter einer hochinfektiösen Krankheit leidet. Eine weitere Ausbreitung verhindert man am besten durch Isolation. Internetprovider wehren sich zu recht gegen solche Infektionsherde. Ein Mailserver, der Relay-Mißbrauch zuläßt, riskiert einen Ausschluß aus dem Internet über sogenannte schwarze Listen (Black Lists). ❏ Proxy-Funktion.
Mail aus dem Internet wird zwischengespeichert, bevor sie weitergereicht wird. Mail aus dem internen Netz wird ebenfalls zwischengespeichert. Filterregeln auf den beiden Routern sorgen dafür, daß eine direkte SMTP-Verbindung nur zwischen dem Internet und dem SMTP-Gateway bzw. nur zwischen dem internen Mailserver und dem SMTP-Gateway möglich ist. ❏ Adressenpflege.
Wenn keine Informationen über interne Mailserver weiter gegeben werden sollen (es können ja auch mehrere sein), kann das SMTP-Gateway die Absenderadressen anpassen. [email protected] könnte durch die Mailadresse [email protected] ersetzt werden. Wenn intern mehrere Mailserver im Einsatz sind, sollte einer der internen Mailserver die userabhängige Weiterleitung an den für den User zuständigen Mailserver übernehmen, um zu vermeiden, daß Aliases auf dem SMTP-Gateway eingerichtet werden müssen. ❏ Keine Informationen über User oder das interne Netzwerk.
Die einzige funktionale Aufgabe des SMTP-Gateways ist die Relay-Funktion zwischen dem Internet und dem internen Netzwerk. Dazu benötigt das
132
7.1 Häufig benutzte Internetdienste
SMTP-Gateway keinerlei Informationen über die im internen Netzwerk vorhanden User wie Aliases oder ähnliches. Ein potentieller Angreifer kann deshalb über das SMTP-Gateway alleine keine Informationen über User gewinnen. ❏ Schutz vor Angriffen über Datenmenge.
Das ist wohl der schwierigste Part. In der Regel erfolgen solche Angriffe mit gefälschten, teils ungültigen Absenderadressen. Durch die Validierung der Absenderadresse läßt sich vielleicht schon einiges beim Verbindungsaufbau abweisen, ohne die Mails alle entgegen zu nehmen. Bei gültigen Senderadressen wird es schon schwieriger. Man könnte zum Beispiel versuchen, identische Mails an eine großen Anzahl verschiedener Anwender oder viele identische Mails an denselben Anwender herauszufiltern. Manchmal bleibt aber nur, nach einem erfolgten Angriff den Absender für Wiederholungen zu sperren. Die Aufgaben des internen Mailservers: ❏ Anwender-Postoffice.
Der interne Mailserver empfängt die Mails vom SMTP-Gateway und stellt diese den Anwendern bereit. Umgekehrt senden die Anwender ihre Mail an den internen Mailserver. ❏ POP-Server.
Bei POP-Verbindungen werden die Passwörter in der Regel im Klartext übertragen. Mailclients (MUA), die auf POP aufbauen, dürfen ihre Verbindungen ausschließlich im lokalen Netzwerk aufbauen, um die Übertragung von Passwörtern in das Grenznetz zu vermeiden. Außerdem werden von verschiedenen POP3-Servern immer wieder Sicherheitslücken bekannt. ❏ IMAP-Server.
Auch IMAP-Server gehören in das lokale Netzwerk. Über Paketfilterung am internen Router lassen sich sehr effektiv alle unerwünschten Verbindungen einzelner Clients zum SMTP-Gateway oder zu externen Hosts unterbinden. ❏ Konfiguration des Paketfilters am inneren Router
internes Netz Adresse Port SMTP intern SMTP intern
1023 25
Verbindungsaufbau
Grenznetz Adresse Port SMTP Gateway SMTP Gateway
25 1023
Proto TCP TCP
133
7 Internetdienste und Firewalls
❏ Konfiguration des Paketfilters am äußeren Router
Grenznetz Adresse Port SMTP-Gateway SMTP-Gateway
1023 25
Verbindungsaufbau
externes Netz Adresse Port ANY ANY
25 1023
Protokoll TCP TCP
❏ Konfiguration SMTP intern: ➢ Erlaubt ausschließlich internen Clients und dem SMTP-Gateway eine
SMTP-Verbindung. ➢ Relaying vollständig verbieten bzw. nur erlauben, wenn der Absender in der eigenen Domäne sitzt. ➢ Annahme aller Mails, die für die Domäne bzw. für den internen Mailserver gedacht sind. ❏ Konfiguration des SMTP-Gateway: ➢ Relaying nur für Mails mit der eigenen Domäne als Absender oder als ➢ ➢ ➢ ➢
➢
7.1.2
Empfänger. Weiterleitung der Mails an die eigene Domäne an den internen Mailserver. Überprüfung auf Spam/UCE anhand von Realtime Black Lists (RBL). Überprüfung, ob der Sender auch einen gültigen Eintrag im DNS hat (MX-Record) Überprüfung der Mailheader auf bekannte, unerwünschte Zeitgenossen (manche Viren, Hoaxes oder Spam-Generatoren lassen sich durch bestimmte Headereinträge verifizieren). Der von außen erreichbare SMTP-Daemon darf auf keinen Fall unter root-Rechten laufen!
Domain Name Service (DNS)
Die Kommunikation im Internet findet über IP (OSI-Ebene 3) statt. Absender und Empfänger kodieren ihre postalische Adresse, die IP-Adresse im bekannten, numerischen Format N.N.N.N. In den meisten Fällen kennt man aber gar nicht die IP-Adresse eines Internet-Host, sondern nur seinen Domain-Namen wie host.mydomain.com – vergleichbar dem Telefonieren: man kennt den Namen des Gesprächspartners, wählen (und ggf. nachschauen) muß man jedoch die Telefonnummer. Die einfachste Variante des Adreßbuches ist auf jedem Rechner in Form einer Datei installiert: /etc/hosts. Die „brute force“-Methode wäre nun (um im Bild zu bleiben): man drückt jedem Benutzer ein vollständiges „Telefonbuch“ des gesamten Internet in die Hand. Die elegantere Methode: man hat lokal einige wichtige Adressen zwischengespeichert, andernfalls ruft man die Auskunft an.
134
7.1 Häufig benutzte Internetdienste
Der Domain Name Service ist die Telefonauskunft des Internet. Die drei Grundfunktionen dabei sind: ❏ Auflösung eines Domainnamens in eine IP-Adresse ❏ Auflösung einer IP-Adresse in einen Domainnamen ❏ Auflösung eines virtuellen Namens in real erreichbare Host für Mailexchange
(sogenannte MX-Records). Dazu gibt es noch einige andere Informationen, die DNS zur Verfügung stellt, die hier aber keine Rolle spielen. Fast alle Unix-Varianten haben die Implementierung der Berkeley University of California übernommen: „Berkeley Internet Name Domain“ (BIND). Der Domain Name Service (DNS) unterscheidet sich etwas von anderen Internetdiensten: er ist ein Hilfsdienst, der von fast allen anderen Internet-Diensten benutzt wird. Mit SMTP versendet man Mails, mit Telnet hat man Zugriff auf fremde Hosts, und alle benutzen DNS, um die vom User angegebenen Namen in eine IP-Adresse umzusetzen. Die meisten Internetdienste werden über Clientprogramme direkt vom Anwender benutzt, während DNS fast ausschließlich von anderen Internetdiensten, selten vom Anwender direkt benutzt wird. Wie funktioniert DNS? Clients benutzen eine fest einkompilierte Library-Funktion, den sogenannten Resolver, der ihnen die Arbeit der Namensauflösung abnimmt. Möchte ein WWW-Client eine Verbindung zum Host www.linux.org aufnehmen, sucht der Resolver nach der zugehörigen Information, meist zuerst in der Datei /etc/hosts, falls vorhanden in YP/NIS, schließlich fragt er einen verfügbaren Domain Name Server (DNS-Lookup). Welchen Server er befragt, ist konfigurierbar: die Datei /etc/resolv.conf enthält ein bis drei Einträge wie: nameserver 193.101.111.20
Welche Datenbanken der Client (hosts, YP/NIS, DNS) in welcher Reihenfolge befragt, ist ebenfalls konfigurierbar. Dazu dient die Datei /etc/nsswitch.conf: hosts: networks:
files dns files dns
files steht bei hosts für /etc/hosts, diese Datei wird zuerst befragt; falls keine Antwort gefunden wird, wird DNS befragt. YP/NIS wird in diesem Beispiel nicht benutzt. Der Server liefert entweder eine Antwort oder einen Fehler zurück. Der Resolver übernimmt die Interpretation der Antwort und gibt die Information an die Programme zurück, die die Anfrage gestellt haben. Bei BIND, der wohl häufigsten Implementierung von DNS im Unix-Umfeld, überläßt der Resolver fast die ganze Arbeit dem nächsten Nameserver. Diese Art der
135
7 Internetdienste und Firewalls
Anfrage nennt man auch „Rekursion“ . Bei der rekursiven Anfrage erwartet der Client eine endgültige Antwort, das heißt, der lokale Nameserver muß sich solange bei anderen Nameservern durchfragen, bis er entweder auf die richtige Antwort gestoßen ist oder feststellen muß, daß es die gewünschte Information gar nicht gibt. Darüber hinaus gibt es die „Iteration“, die überwiegend zwischen Servern eingesetzt wird. Bei der Interation liefert ein Server die bestmögliche Antwort zurück, die dem Endergebnis am nächsten kommt und die er im eigenen Cache vorhält. Der Fragesteller muß die Antwort auswerten und immer wieder erneut Fragen stellen, bis er die gewünschte Information erhält (Rekursion: ursprünglicher Fragesteller stellt nur eine Frage). Den kompletten Funktionsumfang des Domain Name Service zu beschreiben würde den Rahmen dieses Buches sprengen. In [AL99] ist DNS ausführlich beschrieben. Eigenschaften von DNS im Überblick ❏ Der Client stellt die Anfrage nach einer Namensauflösung über den Resol-
ver an einen Nameserver, dessen IP-Adresse zum Zeitpunkt der Abfrage feststeht. Es gibt mehrere Möglichkeiten, bei denen sich die Nameserver-IPAdresse ändert: zum einen verfügt DHCP über eine Möglichkeit, dem Client auf Anfrage eine Nameserver-Adresse mitzuteilen (meist beim Bootvorgang, aber nicht notwendigerweise). Zum anderen gibt es Provider, die mit dynamischen Nameserver-IP-Adressen (IP-Nameserver ist abhängig vom Einwahlpunkt) arbeiten. Dann muß dem Client das nach dem Einwählvorgang mitgeteilt werden (z. B. durch Patchen von /etc/resolv.conf). ❏ Der Server ermittelt bei Rekursion die richtige Antwort selbst, bei Interation
die bestmögliche, derzeit bekannte Antwort und liefert diese an den Client zurück. Im Fehlerfalle eine entsprechende Fehlernachricht. ❏ Weiß der Server die richtige Antwort nicht, befragt er bei Rekursion weitere
Nameserver, um die richtige Antwort zu ermitteln. ❏ Im Fehlerfalle befragt der Client einen weiteren bekannten Nameserver, so-
fern mehrere konfiguriert sind. ❏ Welche Nameserver der Client (Resolver) befragt, ist vorhersagbar, welche
weiteren Nameserver ein Nameserver befragt, dagegen nicht (abhängig von der vom Resolver gestellten Frage und den gecachten Daten). DNS-Spoofing Die meisten Internetdienste werden über Domainnamen benutzt, IP-Adressen verwendet man im Alltag nur ganz selten. Die Konsequenz ist, daß so gut wie
136
7.1 Häufig benutzte Internetdienste
immer der Domainname in eine IP-Adresse aufgelöst werden muß, erst dann ist die Kommunikation über IP möglich. Damit ist aber die korrekte Namensauflösung kritisch. Gelingt es einem Angreifer, dem Client an dieser Stelle eine falsche IP-Adresse „unterzujubeln“, baut der Client – absolut nichts ahnend – die Verbindung zum falschen Server auf. Die Verbindung wurde entführt. Man bezeichnet das als DNS-Spoofing. Eine Form von DNS-Spoofing ist, den Nameserver mit falschen Informationen zu versorgen. Daten, die der Nameserver erhält, speichert dieser in der Regel einige Zeit zwischen. Bei älteren BIND-Implementierungen war es möglich, einfach dem Nameserver ungefragt Informationen zu senden, die dieser ungeprüft abspeicherte. Bei neueren Implementierungen ist das inzwischen abgestellt. Allerdings wäre auch denkbar, daß der Nameserver die falsche Information erst bekommt, wenn er danach gefragt hat, etwa indem die Verbindung zwischen dem Nameserver und einem weiteren abgefangen und falsche Information zurückübermittelt wird. Eine weitere Form von DNS-Spoofing ist das Abfangen der Verbindung zwischen Client und Nameserver. Der Angreifer muß hier den konfigurierten Nameserver lahmlegen und unter dessen IP-Adresse weiterarbeiten. Genaugenommen ist das IP-Spoofing der DNS-Verbindung, aber gespooft wird ja nicht direkt die eigentliche Verbindung, sondern dem Client werden über IP-Spoofing falsche DNS-Daten untergeschoben. Insofern kann man auch von DNS-Spoofing sprechen. Diese Variante funktioniert normalerweise nur in dem Netzwerksegment zwischen Client und Nameserver. Wenn ein lokaler Nameserver vorhanden ist, kann so ein Angriff nur aus dem lokalen Netz heraus stattfinden. Preisgabe interner Informationen Arbeitet das interne Netzwerk mit DNS, existiert zwangsweise auch ein Nameserver, der den Clients die Informationen zur Verfügung stellt. Ohne weiteren Schutz gibt der Server seine Informationen an jeden Fragenden preis. Während DNS-Lookups zumindest die exakte Kenntnis eines Hostnamens oder einer IPAdresse voraussetzen, bietet ein Zone-Transfer die Möglichkeit, die vollständige, vorhandene Information abzufragen. So wie ein internes Telefonbuch aus vielen Gründen oft nicht nach außen preisgegeben werden darf, enthält ein interner Nameserver sehr viele Informationen über die innere Struktur des Netzwerks. Einem potentiellen Angreifer fällt ein Eindringen viel leichter, wenn er über solche Informationen verfügt. Manchmal enthalten auch die Namen bereits weitere Informationen über die eingesetzte Plattform, wie „linux01“ oder „hpux21“. Ein Name wie „mailgate“ signalisiert, daß es sich um einen zentralen Mailserver handelt. Dort ist dann zumindest der SMTP-Port erreichbar.
137
7 Internetdienste und Firewalls
DNS in Firewallumgebungen: Kommunikationsprofile Zu unterscheiden sind zwei Netzwerkumgebungen: kleine Netzwerke ohne eigenen Nameserver (auch keinen sekundären) und Netzwerke mit eigenem Nameserver. Ohne Nameserver muß nur dafür gesorgt werden, daß außer mit dem externen, bekannten Nameserver keine weitere DNS-Kommunikation stattfinden kann. Bei Netzwerken mit Nameservern muß man unterscheiden zwischen sekundären und primären Nameservern. Doch zunächst sehen wir uns die beteiligten Protokolle und Ports bei DNS an. Abbildung 7.4 zeigt den Ablauf einer Client-Resolverabfrage an einen Server. Der Client startet die Abfrage zunächst über UDP. Kommt es zu Übertragungsproblemen oder sind die Pakete größer als 512 Bytes, dann greift der Client auf eine TCP-Kommunikation zurück. In manchen Implementierungen kommerzieller Unixe (z. B. IBM/AIX) wird für die DNS-Auflösung ausschließlich TCP eingesetzt. Die Beteiligung von UDP ist in Firewallumgebungen wegen eines fehlenden gezielten Verbindungsaufbaus weniger erwünscht und macht die Handhabung von DNS etwas komplexer als bei reinen TCP-Diensten. In einer Umgebung ohne eigenen Nameserver (kleines Netzwerk oder einzelner Host) werden die Clients über die Datei resolv.conf direkt an einen externen
Abbildung 7.4: Die DNS-Abfrage von Clients an einen Nameserver läuft zunächst via UDP. Bei Verbindungsproblemen oder bei Paketen größer als 512 Bytes wird die Verbindung über TCP aufgebaut.
138
7.1 Häufig benutzte Internetdienste
Nameserver verwiesen. Im IP-Chains-HOWTO ([Rus99]) wird empfohlen, unter solchen Ausgangsvoraussetzungen ausschließlich ausgehende TCP-Anfragen zuzulassen. Kleinere Timeouts nimmt man damit allerdings in Kauf, da trotzdem immer zuerst mit UDP angefragt wird. Werden lokal Nameserver eingesetzt, kommen zwei weitere Kommunikationsprofile ins Spiel: die Anfrage eines Server an einen weiteren Server, weil er selbst eine an ihn gerichtete Anfrage nicht auflösen kann, und der Zone-Transfer, mit dem Nameserver untereinander größere Datenbestände eines bestimmten Bereichs (die Zone) replizieren. Abbildung 7.5 zeigt die Kommunikationsprofile. Die Anfrage eines Nameserver an einen weiteren Nameserver läuft wie bei der Client-Server-Abfrage ebenfalls zunächst über UDP. Allerdings wird üblicherweise der Port 53 nicht nur als Ziel-, sondern auch als Quellport benutzt. Seit BIND8 ist das Standardverhalten allerdings anders: wie bei einem echten Client benutzt ein Nameserver bei einer UDP-Anfrage ebenfalls Quellports größer als
Abbildung 7.5: Die DNS-Abfrage eines Nameserver an einen weiteren Nameserver läuft zunächst ebenfalls via UDP, allerdings wird meist Port 53 auch als Quellport benutzt; bei Verbindungsproblemen oder bei Paketen größer als 512 Bytes wird die Verbindung über TCP aufgebaut. Zonetransfers laufen ausschließlich über TCP.
139
7 Internetdienste und Firewalls
1023. Bei der Implementierung eines Paketfilters muß das berücksichtigt werden. Entweder erlaubt man beide Varianten im Paketfilter, oder man konfiguriert BIND8 so, daß er sich wie bisher verhält ([AL99]). Eine vor allem für sekundäre Nameserver typische Kommunikation ist der ZoneTransfer, der ausschließlich über TCP verläuft. Wie die Abbildung 7.5 zeigt, verläuft die Kommunikation über TCP und benutzt denselben Zielport wie bei normalen Nameserveranfragen. Sekundäre Nameserver In manchen Umgebungen wird lokal ein sekundärer Nameserver eingesetzt, während der primäre Nameserver beim Provider steht. Der Firewall kann wie in einer Umgebung ohne eigenen Nameserver so konfiguriert werden, daß ausgehende TCP-Anfragen zugelassen und alle anderen Verbindungen untersagt werden. Zusätzlich kann die ausgehende Kommunikation ausschließlich auf den sekundären Nameserver beschränkt werden. Da der primäre Nameserver in den Verantwortungsbereich des Providers fällt, kann man höchstens noch den lokalen Nameserver anweisen, nichtlokale Anfragen zu ignorieren. Das macht durchaus Sinn, denn einige DoS-Attacken machen sich zu nutze, daß Anfrage-Pakete kleiner sind als Antwortpakete, d. h. sich ein Nameserver auch „tot-antworten“ kann. ❏ Konfiguration des Paketfilters
internes Netz Adresse Port sekundärer NS
1023
Verbindungsaufbau
externes Netz Adresse Port primärer NS
53
Protokoll TCP
❏ Konfiguration BIND8: der Nameserver nimmt ausschließlich lokale Anfra-
gen an (Beispiel: lokales Netzwerk ist 192.168.2.0/255.255.255.0): options { allow-query {192.168.2/24; 127.0.0.1; }; };
Primärer Nameserver in der Firewallumgebung Ein primärer Nameserver im eigenen Netzwerk enthält in der Regel Informationen über das gesamte lokale Netz. Wie oben bereits erwähnt, ist es nicht unbedingt erwünscht, diese Informationen nach draußen zu geben. Die Standardlösung in Firewallumgebungen ist, den Nameserver aufzusplitten in einen internen und einen externen DNS-Server (siehe Abbildung 7.6).
140
7.1 Häufig benutzte Internetdienste
Abbildung 7.6: Externer und interner Nameserver
Der externe Nameserver stellt nur die unbedingt nötigen Informationen aus dem lokalen Netzwerk zur Verfügung, zum Beispiel FTP-Server, Mailserver und MXRecords, WWW-Server. Alle anderen Informationen bleiben ausschließlich dem internen Nameserver vorbehalten. Der interne Nameserver wird angewiesen, ausschließlich Anfragen von internen Hosts zu verarbeiten. Zone-Transfers sollten auf beiden Nameservern generell verboten werden. Clients, die Verbindungen in das Internet aufbauen möchten, befragen ausschließlich den internen Nameserver. Dieser muß sich wiederum die Information über Internet-Hosts vom externen Nameserver besorgen. Dazu wird der interne Nameserver über eine forwarders-Direktive angewiesen, nicht auflösbare Anfragen an den externen Nameserver weiterzuleiten 1 . ❏ Konfiguration des Paketfilters am inneren Router
internes Netz Adresse Port DNS intern
1023
Verbindungsaufbau
Grenznetz Adresse Port DNS extern
53
Protokoll TCP
1 Für
kleinere Netzwerke funktioniert das sehr gut, bei komplexeren Netzen, insbesondere mit mehreren Subdomains müssen dabei einige besondere Spielregeln beachtet werden. Hier sei nochmals das Buch [AL99] empfohlen, wo die Autoren auch auf solche Besonderheiten eingehen
141
7 Internetdienste und Firewalls
❏ Konfiguration des Paketfilters am äußeren Router
Grenznetz Adresse Port DNS extern DNS extern DNS extern
53 1023 53
Verbindungsaufbau
externes Netz Adresse Port ANY ANY ANY
53 53 1023
Protokoll UDP TCP TCP
❏ Interner Nameserver (BIND8): nimmt ausschließlich lokale Anfragen an
Die Direktive forward only bedeutet, daß sich der Nameserver und ganz auf seinen Forwarder verläßt. Er versucht nicht, andere Nameserver zu erreichen, kontaktiert also auch keine root-Nameserver. ❏ Externer Nameserver (BIND8): verbietet rekursive Anfragen. Damit lassen
sich einige häufige Spoofing-Attacken vermeiden. Allerdings beantwortet der Nameserver im Grenznetz dann keine Anfragen von Clients (Resolvern) mehr. options { recursion no; };
7.1.3
Terminal-Session: Telnet
„Telnet“ ist sowohl der Name für ein Anwendungsprotokoll als auch für einen entsprechenden Applikationsclient. Der Anwender erhält auf einem fernen Rechner eine Shell wie bei einem lokalem Terminal. Das Protokoll basiert auf TCP und benutzt den Port 23. Das Programm telnet erlaubt es auch, andere Ports als 23 zu benutzen, um damit andere TCP-Verbindungen zu simulieren. Zur Fehlersuche ist das manchmal ganz nützlich, aber es geht hier um das Protokoll Telnet und dessen Eignung für eine Firewallumgebung, nicht um die Applikation als solche. Mit dem zugrunde liegenen TCP-Protokoll läßt sich der Verbindungsaufbau und damit die Richtung des Login eindeutig festlegen. Damit eignet sich das Protokoll gut für einen Paketfilter.
142
7.1 Häufig benutzte Internetdienste
❏ Konfiguration des Paketfilters für ausgehende Telnet-Verbindungen
internes Netz Adresse Port lokales Netzwerk
Verbindungsaufbau
1023
externes Netz Adresse Port ANY
23
Protokoll TCP
Sicherheitsproblematik bei Telnet Gegen den offenen Einsatz im Internet oder allgemein wenig geschützten Netzwerken gib es eine Reihe von Bedenken: ❏ Klartext-Übertragung.
Der gesamte Text einer Telnet-Session – und damit auch das Passwort – wird im Klartext übertragen und ist damit für alle lesbar. Sofern die Gegenseite keine Mechanismen wie Einmal-Passwörter verwendet, ist die Sicherheit im Internet gleich null. ❏ Spoofing-Gefahr.
Während einer bestehenden Verbindung bietet Telnet überhaupt keine Sicherheit gegen eine Entführung der Verbindung. Gelingt es einem Angreifer, eine bestehende Telnet-Session zu entführen, kann er die Sitzung unter dem Account der bestehenden Session fortführen und benötigt dazu noch nicht einmal eine Zugangskennung. Man sollte gar nicht erst auf die Idee kommen, wenigstens für die ersten Schritte eines entfernten Rechners Telnet zur Administration und zum Setup zu verwenden. Übernimmt ein Angreifer eine Session mit Administratorrechten, kann man den entfernten Rechner im Prinzip gleich neu installieren . . . ❏ Symmetrie.
Aus den ersten beiden Punkten läßt sich eindeutig ableiten, daß aus Sicherheitsgründen von außen auf keinen Fall eine Telnet-Verbindung in das interne Netzwerk erlaubt sein soll. Warum sollte dann eine andere Internet-Site uns von außen Zugang via Telnet erlauben? Wenn diese den Sicherheitsaspekt ernst nimmt, wird sie uns das auch nicht erlauben. Es gibt im Internet fertige Tools, mit denen man nicht nur den kompletten TelnetVerkehr abhören, sondern gleich die vollständige Telnet-Session übernehmen kann, als hätte man sich selbst eingeloggt (Hijacking). In [ano00] findet sich eine Reihe praktischer Beispiele. Aufgrund der Verfügbarkeit solcher Tools und der einfachen Anwendbarkeit muß sich auch jeder Netzwerkadministrator in seinem eigenen Netzwerk überlegen, ob er generell – oder wenigstens für besonders zu sichernde Rechner – auf andere Loginmechanismen ausweicht, die einen wesentlich höheren Sicherheitsstandard als Telnet aufweisen (z. B. ssh).
143
7 Internetdienste und Firewalls
Telnet in Firewallumgebungen Wegen der Gefahr von Spoofing/Hijacking ganzer Telnet-Sessions bzw. der Gefahr von Sniffing von Passwörtern sollte Telnet in Firewallumgebungen nicht eingesetzt werden.
7.1.4
r-Kommandos
Zu den sogenannten „r-Kommandos“ („r“ steht für „remote“) gehören folgende: ❏ rlogin:
erlaubt ähnlich Telnet einen Login auf einem entfernten Rechner. Im Unterschied zu Telnet wurde rlogin zunächst ausschließlich für die UnixWelt entwickelt, deshalb ist das Protokoll etwas einfacher als das von Telnet, welches von vorneherein für eine heterogene Rechnerlandschaft konstruiert wurde und deshalb auch über Mechanismen verfügt, die jeweiligen Fähigkeiten des Partners auszuhandeln (Negotiation). Neben der passwortlosen Autorisierung (siehe nächster Abschnitt) verfügt rlogin über die Möglichkeit des Login mit Username und Passwort. ❏ rsh:
Mit rsh können auf dem Zielrechner Shell-Kommandos so ausgeführt werden, als ob man dort auch vollständig eingeloggt wäre. Das Besondere an rsh und den nachfolgenden Kommandos ist, daß dazu keine Autorisierung über Passwort erforderlich ist (siehe dazu nächster Abschnitt). ❏ rcp:
ist weiterer Client für den rshd. rcp kopiert in erster Linie Daten zwischen dem lokalen und dem entfernten Rechner wie ein normales cp zwischen Verzeichnissen. Die Besonderheit: rcp kann auch zwischen zwei entfernten Rechnern kopieren. Tatsächlich erfolgt der Datentransport zwischen den beiden entfernten Rechnern, ohne daß der lokale Rechner, der das Kommando absetzt, mit dem Datentransfer belastet wird: rcp alpha:/etc/services beta:/tmp/. ❏ rdump, rrestore:
Wie der Name schon sagt, handelt es sich um die remote-fähigen Versionen von dump und restore. dump ist das bei kommerziellen Unixen übliche Backup-Programm, restore das Programm, mit dem man die Daten (auch interaktiv über eine einfache Menuesteuerung) wieder herstellen kann. Ein Dump eines Filesystems enthält Informationen über den Aufbau desselben, ist also höchst filesystemspezifisch. Unter Linux haben die Programme dump und restore deshalb auch keine große Bedeutung, dasselbe trifft auch auf die r-Versionen zu. Backups unter Linux werden herkömmlich mit
144
7.1 Häufig benutzte Internetdienste
Werkzeugen durchgeführt, die ein tar-Format erzeugen (das geht z. B. auch mit cpio!). ❏ rdist:
ist für die Verteilung von Daten im Netzwerk, insbesondere für den 1:1Abgleich von Verzeichnissen und Konfigurationsfiles entwickelt worden. rdist ist ein sehr mächtiges Tool. Man kann damit auch ein Image einer Festplatte auf Filebasis erzeugen, sozusagen eine kalte Spiegelung. Mit der Verfügbarkeit von rsync sollte man aber besser rsync einsetzen und auf rdist verzichten. ❏ rexec:
gehört nicht ganz in die Familie der r-Kommandos. Im Gegensatz zu ihnen verlangt es immer eine Autorisierung über Username und Passwort. Es ist also nicht ganz so unsicher wie die anderen r-Kommandos, die eine passwortlose Autorisierung erlauben. Allerdings benutzt es ebenfalls beliebige Client-Ports unterhalb von 1023, deshalb hat rexec zum Teil dieselben Probleme in Firewallumgebungen wie die „richtigen“ r-Kommandos. Das seltsame an rexec ist, daß es auf fast allen Unix-Plattformen verfügbar und aktiviert ist, obwohl es kaum Clients für diesen Dienst gibt. Benutzt wird manchmal rexec von Windows-Clients aus, die keine rsh verwenden können, etwa zum Starten eines xterm. X-Win32, ein X-Server für den Windows-PC (kommerziell), benutzt unter anderem rexec. Das Kommando rlogin verwendet als Serverport Port 513/TCP, rexec den Serverport 512/TCP, die anderen Clients verwenden den Serverport 514/TCP, das ist gleichbedeutend mit der Verwendung desselben Serverdaemons. Es handelt sich also nur um verschiedene Clients für denselben Server, meist in.rshd. Passwortlose Autorisierung der r-Kommandos Die r-Kommandos besitzen eine auf Konfigurationsfiles und IP-Source-Adressen basierte Autorisierung. Die Konfigurationsfiles auf dem Server sind: ❏ /etc/hosts.equiv
Alle Rechner, die hier eingetragen sind, werden als vertrauenswürdig behandelt. D. h., alle User, die sich von diesen Rechnern aus unter dem gleichen Accountnamen einloggen, werden ohne weitere Autorisierung zugelassen. Dahinter steht die einfache Annahme, daß sich ein User, der sich von einem anderen Rechner aus einloggt, bereits am anderen Rechner autorisiert hat. Wegen der Gefahr von Spoofing (siehe unten) ist diese Datei ein riesiges Sicherheitsloch. Empfehlung: die Datei vollständig entfernen.
145
7 Internetdienste und Firewalls
❏ ˜/.rhosts
Ist ein Rechnername nicht in /etc/hosts.equiv enthalten, wird im Homeverzeichnis des Users die Datei .rhosts überprüft. Dort sind Einträge in der Form hostname username
enthalten. Wird die Anfrage von „hostname“ aus und vom User „username“ ausgeführt, gewährt der Dienst passwortfreien Zutritt. Die passwortlose Autorisierung via .rhosts läßt sich sowohl beim rshd als auch beim rlogind abschalten (zumindest bei neueren Versionen). Allerdings bleibt dann für den rshd nur noch die hosts.equiv-basierte Autorisierung, die noch unsicherer ist. Steht diese nicht zur Verfügung, sind bei Abschaltung von .rhosts die rshd-basierten Dienste wertlos, weil sie keine Passwort-Autorisierung ermöglichen. rlogin ist dann wenigstens noch über die normale User/Passwort-Kombination zu gebrauchen, allerdings unterscheidet sich der Dienst dann kaum noch von Telnet (bis auf die Client-Ports unter 1023). Sicherheitsproblematik der r-Kommandos ❏ Clients verwenden Portnummern unter 1023:
Allen Clients ist gemeinsam, daß sie beliebige Portnummern unter 1023 verwenden. Das verbietet den Einsatz in Firewallumgebungen, da ein Paketfilter den Verbindungsaufbau zu beliebigen privilegierten Ports offenhalten muß. Außerdem bedeutet das auch, daß die Clients unter root-Rechten laufen müssen, also das s-Bit auf den Owner root gesetzt ist. Das macht die Programme wiederum interessant für Attacken wie Buffer Overflows etc. ❏ Autorisierung aufgrund von File-Informationen und IP-Adressen
Der größte Schwachpunkt von r-Kommandos ist, daß diese sich bei der Autorisierung auf IP-Source-Adressen verlassen. Die Source-Adresse könnte aber auch gespooft sein, d. h., einem Angreifer genügt es zu wissen, für welche Host- und User-Kombinationen keine Passwort-Autorisierung erforderlich ist. Und schon „ist er drin“. ❏ Passwortübertragung im Klartext:
Verlangt rlogin ein Passwort, wird dieses im Klartext übertragen. Das ist auch bei rexec der Fall. Damit ergeben sich dieselben Sicherheitsprobleme wie bei Telnet. r-Kommandos in Firewallumgebungen? – Nein! Die Autorisierung bei den r-Kommandos ist mehr als schwach. Wegen der Gefahr von Spoofing von Source-Adressen und der damit verbundenen leichten
146
7.1 Häufig benutzte Internetdienste
Möglichkeit zum Eindringen haben die r-Kommandos in Firewallumgebungen nichts zu suchen. Auch in lokalen Netzen ist zu überlegen, wie weit man die r-Kommandos zuläßt. Sie sind immerhin in Unix-Umgebungen sehr bequem. Man sollte wenigstens /etc/hosts.equiv entfernen und sich nur auf die rhosts-Autorisierung verlassen. Dann erhält allerdings die Zugriffsmöglichkeit auf das File einen großen Stellenwert. Neuere rlogind/rshd verweigern die passwortlose Autorisierung, wenn die Gefahr besteht, daß jemand unautorisiert das File ändern könnte, z. B. wenn das Homeverzeichnis für andere als den User (group, others) schreibbar ist (nicht blind darauf verlassen, testen!).
7.1.5
Secure Shell: sicherer Ersatz für rsh/telnet
Bis jetzt wurden Login-Möglichkeiten aufgezeigt, die man aufgrund ihrer Angreifbarkeit besser in Firewallumgebungen nicht einsetzt. Ein sicherer Ersatz muß also her. Welche Anforderungen sind nun an eine sichere Verbindung zu stellen? Die Verbindung sollte abhörsicher sein, d. h., sowohl die Autorisierung als auch die gesamte Datenverbindung sollte verschlüsselt sein. Dabei sollten die Verschlüsselungsmechanismen „unknackbar“, d. h. mit heute zur Verfügung stehenden Mitteln auch auf die nächsten 1000 Jahre nicht zu entschlüsseln sein. Eine sichere Autorisierung wäre, wenn mit Public Key-Mechanismen gearbeitet wird, weil dabei niemals ein Originalschlüssel zu übertragen ist. Aber das alleine genügt noch nicht. In der Anfangszeit verschlüsselter Verbindungen kam es hin und wieder vor, daß sich der Client zwar mit dem Server auf eine abhörsichere Verbindung geeinigt hat, aber leider der Server nicht der Server war, an den der Client geglaubt hatte sich zu wenden. Mit anderen Worten: nicht nur der Client muß sich wie bei den meisten Systemen gegenüber dem Server identifizieren, sondern auch der Server dem Client gegenüber, um fehlgeleitete Verbindung schon im Stadium des Verbindungsaufbaus zu verhindern. Ein solches Tool ist die „Secure Shell“ (SSH). Die wichtigsten Eigenschaften im Überblick: ❏ Starke Authentifikation des Server
Die Secure Shell kann bekannte Hosts über ein Public-Key-Verfahren identifizieren („known hosts“). Das Verfahren basiert auf einer RSA-Verschlüsselung. Vor dem ersten Verbindungsaufbau kann man den Public Key des Server dem Client bekannt machen. Während des Verbindungsaufbaus überprüft zunächst der Client, ob es sich um den richtigen Host handelt. Wenn etwas nicht stimmt, erfolgt eine deutliche Warnung auf dem Bildschirm. Erst wenn diese Identifikation über den RSA-Schlüssel korrekt erfolgt ist,
147
7 Internetdienste und Firewalls
beginnt sich der Client zu authentifizieren. Ein Spoofing der Verbindung ist somit ausgeschlossen. ❏ Sichere Authentifikation der User
Nach der Serveridentifizierung gibt es mehrere Varianten der Authentifikation des Client: ➢ .rhosts oder /etc/hosts.equiv ➢ RSA basierte Hostauthentifikation ➢ RSA basierte Authentifikation ➢ via Passwort Die Authentifikation erfolgt in jedem Falle verschlüsselt und nicht abhörbar. ❏ Verschlüsselung der gesamten Übertragung
ist wichtig, nicht nur, weil keine Daten ausspioniert werden können, sondern weil sie auch gegen Hijacking der Verbindung nach erfolgtem Login schützt. Für die Verschlüsselung stehen eine Reihe von Algorithmen zur Verfügung (die teilweise auch verschiedenen Patenten unterliegen), aus denen ausgewählt werden kann. ❏ Spezialmodus zur sicheren X11-Übertragung
Die Secure Shell hat eigens für die recht unsichere X11-Datenverbindung einen eigenen Tunneling-Modus, der es erlaubt, X11-Verbindungen mit Secure-Shell-Bordmitteln sicher und verschlüsselt über unsichere Wege zu übertragen, ohne daß dazu neue Mechnismen eingeführt oder X11-Programme abgeändert werden müssen. Das bezieht Cookies und die Variable DISPLAY mit ein. ❏ Tunnelung von TCP/IP-Verbindungen
Ein generisches Interface, mit dem man beliebige TCP/IP-Verbindungen zwischen zwei Rechner tunneln kann. ❏ Komprimierung der Übertragung
Die Daten können während der Übertragung komprimiert werden, um geringe Bandbreite (z. B. die Wählverbindung oder die langsame Standleitung in das Internet) besser ausnutzen zu können. Heutzutage verfügen die beteiligten Rechner über genügend Rechenleistung, so daß die Komprimierung kaum Rechenzeit kostet. Überdies erfolgt die Komprimierung transparent, d. h., der Endanwender bekommt nichts davon mit und muß sich demzufolge um nichts kümmern. ❏ Sichere Dateiübertragung mit scp
Wie ssh das Pendant zu rsh ist, ist scp das sichere Pendant zu rcp. scp funktioniert genauso einfach und bequem wie rcp, aber es ist wesentlich sicherer. Die automatische Komprimierung tut ein übriges, um scp in der Gunst des Benutzers weiter nach oben zu bringen.
148
7.1 Häufig benutzte Internetdienste
❏ Ähnlichkeit mit rsh und rcp
garantiert leichte Einarbeitung. Die meisten Benutzer haben bereits Erfahrungen mit rlogin, rsh und rcp und müssen sich nicht umgewöhnen. Die benutzerseitig erforderliche Konfiguration beschränkt sich auf wenige Handgriffe. ❏ Flexible Konfigurierbarkeit
Die Secure Shell ist sehr flexibel konfigurierbar. Neben zwei serverseitigen Konfigurationsdateien für den Server sshd und den Client ssh hat jeder einzelne Benutzer noch die Möglichkeit, selbst Clientoptions einer Datei $HOME/.ssh/config zu setzen. So kann man z. B. für lokale Hosts im vertrauten Netz den Parameter StrictHostKeyChecking auf ask setzen und auf Komprimierung verzichten, während man für Host im Internet Komprimierung einschaltet und StrictHostKeyChecking auf yes setzt (der Parameter entscheidet darüber, ob die Verbindung bei unbekannten Hosts sofort abgebrochen oder nachgefragt werden soll; siehe auch man ssh). SSH-Verbindungscharakteristik Bei der Konfiguration von Paketfiltern ist zu beachten, daß die Secure Shell normalerweise als Clientport einen privilegierten Port 1023 verwendet, normalerweise von 1023 abwärts den nächsten freien. Zu beachten ist auch, daß jede SSH-Verbindung einen solchen Port benutzt, d. h., wenn parallel zu einem Secure Shell Login noch zwei Kopiervorgänge via scp laufen, dann werden drei solcher Ports benötigt. Der Paketfilter muß deshalb einen kleinen Bereich dazu freihalten. Da die Secure Shell TCP verwendet, läßt sich auch der Verbindungsaufbau gut kontrollieren.
Die Secure Shell besitzt auch einen Modus, der als Clientport unprivilegierte Ports benutzt (Parameter -P). Allerdings ist dann nur die Passwort-Authentifikation erlaubt, die RSA-Authentifikationen sind dann nicht möglich. ❏ Konfiguration des Paketfilters für ausgehende SSH-Verbindungen
internes Netz Adresse Port lok. Netzwerk
Verbindungsaufbau
1000-1023
externes Netz Adresse Port ANY
22
Protokoll TCP
❏ für unprivilegierte Ports muß der Portbereich 1000-1023 durch den Be-
reich 1024-65535 ersetzt werden.
149
7 Internetdienste und Firewalls
Sicherheitproblematik der Secure Shell ❏ .rhosts oder /etc/hosts.equiv-basierte Authentifikation
Zwar bietet die Secure Shell bei diesem Verfahren eine höhere Sicherheit als rlogin, weil Name und IP-Adresse des Client-Host vom Server vorwärts und rückwärts geprüft werden („double reverse check“). Spoofing ist deshalb nicht so einfach wie bei rlogin, aber nicht prinzipiell unmöglich. Die User-Authentifikation fällt bei diesem Verfahren völlig weg, und von welchem Host sich eingeloggt werden darf, hängt nur an einem File. ❏ Buffer overflows, Verwundbarkeit des Servers
Aufgrund der großen Beliebtheit der Secure Shell hat diese nicht nur einen hohen Verbreitungsgrad, sondern sie unterliegt auch intensiven Untersuchungen auf mögliche Verwundbarkeit – nicht nur aufgrund von Sicherheitsaspekten; auch Hacker versuchen sich noch nicht entdeckte Sicherheitslücken zunutze zu machen. Das hat zwei Konsequenzen: Die Secure Shell ist zum einen eines der am besten getesteten Programme im Internet und auch eines der sichersten, aber nur in der jeweils aktuellsten Fassung. Zum zweiten sind die Sicherheitsmängel älterer Versionen bestens bekannt und in der Regel genügend Exploits verfügbar. Mit anderen Worten: unbedingt immer die aktuellste Version vorhalten und einschlägige Mailinglisten und Diskussionsforen regelmäßig besuchen, um sich über den aktuellen Stand zu informieren. Ein erst kürzlich veröffentlichter Exploit betraf einen Buffer Overflow in der kommerziellen SSH-Variante, die mit RSAREF übersetzt wurde. Versionen, die ohne RSAREF übersetzt sind, sind davon nicht betroffen (ssh -V). ❏ Fehlkonfiguration
Kein sicherer Server ist vor einer Fehlbedienung gefeit. So erlaubt die Secure Shell die Remote Shell rsh als Fallbackmode, wenn der gewünschte Server keinen ssh-Dienst anbietet. Damit geht auch die Sicherheit der Secure Shell verloren. FallBackToRsh steht in der Defaultkonfiguration auf yes. Abschalten! Wer die Secure Shell selbst übersetzt, hat auch die Möglichkeit, als Verschlüsselung none einzukompilieren. Damit sind SSH-Verbindungen möglich, die nicht verschlüsseln. Auf keinen Fall mit dieser Option übersetzen. ❏ Fehlbedienung
Trifft die Secure Shell beim Verbindungsaufbau auf einen Server, den sie eigentlich schon kennt, aber der RSA-Schlüssel paßt nicht: Vorsicht, es könnte sich um eine gespoofte Verbindung handeln. Wenn StrictHostKeyChecking ask ist, wird eine deutliche Warnung angezeigt, aber trotzdem kann der User weitermachen. Gegen solch eine Fehlbedienung yes in der Serverkonfiguist dann nur ein StrictHostKeyChecking ration möglich, allerdings verhindert das auch den Verbindungsaufbau zu
150
7.1 Häufig benutzte Internetdienste
bisher nicht benutzten Hosts. Wenn also der Systemadministrator die Datei mit den Public Keys aller bekannten Hosts nicht regelmäßig pflegt, ist Ärger mit den Anwendern vorprogrammiert. Einsatz der Secure Shell in Firewallumgebungen Als Telnet-Ersatz ist die Secure Shell in jedem Falle geeignet. Aufgrund der Sicherheitsmechanismen sind keine speziellen Konfigurationen in Firewallumgebungen notwendig, solange nur ausgehende Verbindungen zugelassen werden. Zur Paketfilterung siehe die Charakteristik weiter oben. Vielleicht kommt jemand auf die Idee, in der demilitarisierten Zone auf dem Bastion Host SSHLogins einzurichten, um ausgehende SSH-Verbindungen auf User am Bastion Host einzuschränken. Das sollte man auf keinen Fall tun, solange der Bastion Host noch weitere Dienste anbietet. Jeder unnötige User auf einem Bastion Host reduziert prinzipiell die Sicherheit, weil dort mehr als notwendig Aktivitäten überwacht werden müssen. Irgendwann ist nicht mehr zwischen normalen Useraktionen und Einbruchsversuchen zu unterscheiden, und damit geht ein großes Stück Sicherheit verloren. Als an sich sicheres Werkzeug ist die Secure Shell das Logintool der Wahl für die Fernwartung von Firewalls. Allerdings sollte man sie so restriktiv wie möglich konfigurieren und die Sicherheitsproblematik grundsätzlich im Auge behalten. Die SSH-Verbindung ist nur so sicher, wie der Host selbst. Die nachfolgenden Hinweise gelten in erster Linie für den Einsatz der Secure Shell auf den am Firewall beteiligten Host selbst. Wenn sich eingehende Secure Shell-Verbindungen nicht vermeiden lassen, sollte man sich ebenfalls überlegen, ob man diese Accounts so restriktiv wie möglich behandelt. ❏ Falls neue Exploits bekannt werden
Grundsätzlich umgehend so schnell wie möglich prüfen, ob die eigene Installation dafür anfällig ist. Wenn ja, muß zunächst einmal davon ausgegangen werden, daß der Host möglicherweise schon komprimittiert wurde. Den Host unbedingt nach Unregelmäßigkeiten und ausgetauschen Binaries absuchen. Es ist dringend ratsam, solche Suche unter Zuhilfenahme von Tools wie tripwire durchzuführen (siehe Abschnitt 10.4.2). Falls tatsächlich ein Eindringen feststellbar ist, Hinweise in Abschnitt 10.8 beachten. ❏ X11- und Port-Forwarding abschalten
Für eine einfache Firewallwartung werden selten X11 oder auch andere Ports benötigt. Im Zusammenhang mit X11 gibt es eine regelmäßige Diskussion im Internet, ob ssh hier anfällig ist oder nicht. ❏ Explizite User über AllowGroups oder AllowUsers angeben
Zugelassene User explizit eintragen oder über eine eigens dazu definierte Gruppe konfigurieren. Darauf achten, daß alle zugelassenen User eine
151
7 Internetdienste und Firewalls
richtige Shell besitzen (vor einiger Zeit wurde ein Exploit veröffentlicht, der darauf basiert, daß es User ohne richtige Shell gibt, z. B. /bin/false oder ähnliches. Solche User dürfen auf keinen Fall vom sshd zugelassen werden. ❏ Explizite Hosts eintragen: HostsAllow
Wenn möglich, kann zusätzlich die Anzahl der Hosts, von denen eine Verbindung zum Firewall erlaubt ist, eingeschränkt werden. Sind Verbindungen aus dem Internet zum Firewall erlaubt, dann ist dieser Parameter ein Muß. ❏ Authentifikationsmechanismen einschränken
SSH auf Firewalls sollte man nur über die RSA-Autorisierung erreichen, also IgnoreRhosts = yes RhostsAuthentication = no RhostsRSAAuthentication = no PasswordAuthentication = no PermitRootLogin = no
Bei PermitRootLogin = no muß man sich als normaler User einloggen und über su gehen, was zusätzlich geloggt wird.
yes Damit werden die Permissions von Homeverzeichnis und den rhosts-Files geprüft, bevor der User sich einloggt. Ein Muß, sobald aus irgendwelchen Gründen mit .rhosts/.shosts gearbeitet wird.
❏ StrictModes
Zusätzlich empfiehlt es sich, für den Client ssh die Option StrictHostKeyyes und FallBackToRsh no zu setzen. Checking
Lizenzrechtliches Die Secure Shell ssh ist nicht frei, d. h., sie unterliegt Lizenzbestimmungen. Bis zur Version ssh-1.2.2x gibt es die „SSH (Secure Shell) Non-Commercial License (Version 1, May 27th, 1996)“. Darin wird beschrieben, welchen Einschränkungen das Programm unterliegt. Einige Stichpunkte (keine Übersetzung; für juristische Fragen bitte selbst die Lizenz einsehen): ❏ Einzelpersonen und Non-Profit-Organisationen dürfen das Programm frei
verwenden. ❏ Kommerzielle Organisationen dürfen SSH verwenden, solange es nicht Be-
standteil eines Produktes oder Systemes ist, das verkauft wird. ❏ Ein Provider etwa darf die SSH installieren und seinen Kunden zur Benut-
zung anbieten. Soweit ist die Nutzung frei. Betreibt der Provider allerdings aktiv den Einsatz der SSH und bietet solch eine sichere Verbindung auch noch als Mehrwertdienst an, ist eine kommerzielle Lizenz erforderlich.
152
7.1 Häufig benutzte Internetdienste
❏ Ein Berater darf bei seinem Kunden als Dienstleistung vor Ort die Secure
Shell installieren, damit der Kunde die Secure Shell benutzen kann. Setzt jedoch das vom Berater installierte System die Secure Shell als installierte Komponente voraus, ist wiederum eine kommerzielle Lizenz erforderlich. Fazit: Es kommt darauf an. . . Wenn also bei einer Fernwartung der Kunde vom Anbieter verlangt, eine sichere Verbindung zu nutzen, und die SSH vorschlägt, ist die Verwendung frei. Schreibt der Anbieter hingegen die SSH zwingend vor, weil diese in irgendwelchen Skripten des ausgelieferten Systems benötigt wird, ist sie nicht frei. SSH in der Version 1.2.2x setzt als Protokollversion 1.5 ein. Inzwischen ist das Protokoll weiterentwickelt worden (Version 2.0). Die dazugehörigen SSH-Versionen ab 2.x sind nur noch kommerzielle Versionen. Aus diesem Grunde gibt es eine freie Entwicklung der Secure Shell: ÖpenSSH“. OpenSSH soll kompatibel zur SSH bleiben, aber ausschließlich auf freiem Code basieren. Die meisten Distributionen bieten bei der Installation schon wahlweise ssh oder openssh an. Wer OpenSSH selbst übersetzen will, wird schnell feststellen, daß das deutlich aufwendiger ist als die ursprüngliche SSH, da unter anderem SSL verwendet wird, was nicht im Code-Baum von OpenSSH enthalten ist, sondern getrennt installiert werden muß.
7.1.6
File Transfer Protocol (FTP)
Das File Transfer Protocol (FTP) wurde entwickelt, um den Datenaustausch zwischen Rechnern zu ermöglichen, ohne gleich Remote Usern Zugang zum System zu gewähren. Auch heute noch ist FTP der Dateitransfermechanismus schlechthin, und viele Server im Internet gewähren unbekannten Usern „anonymen“ Zugang zu dort bereitgestellten Daten, ohne gleich einen Login auf dem Server einräumen zu müssen. Es ist offensichtlich, daß FTP den Löwenanteil zur Verbreitung von Open Source beigetragen hat. Wie bei anderen Internet-Diensten ist der Name Programm: FTP ist nicht nur ein Protokoll, sondern fast immer auch der Name des Standard-Client, der bei allen Unix-Varianten mitgeliefert wird. Um verschiedene Sicherheitsprobleme und manche komplexe Firewallkonstruktion, die in Zusammenhang mit FTP erscheint, besser verstehen zu können, sehen wir uns zunächst die Charakteristik des File Transfer Protocol näher an. Anders als einfache Internetdienste besteht eine FTP-Session aus mehr als einer TCP-Verbindung. Man unterscheidet zwischen der Control Connection und einer oder mehrerer Data Connections. Zunächst öffnet der Client eine Control Connection, d. h., er verbindet via TCP zum Serverport 21. Soweit handelt es sich um eine ganz normale TCP-Verbindung (siehe Abbildung 7.7).
153
7 Internetdienste und Firewalls
Abbildung 7.7: FTP Session: Control Connection/aktive Data Connection
Bei der Data Connection unterscheidet man zwei prinzipiell verschiedene Arten: die ursprüngliche Datenverbindung, auch als „aktive Datenverbindung“ bezeichnet, und die passive Datenverbindung. Die Attribute „aktiv“ und „passiv“ bezeichnen das Serververhalten, die Datenverbindung betreffend. Wenn im iolgenden von „aktivem“ oder „passivem“ FTP gesprochen wird, ist damit FTP mit der entsprechenden Datenverbindung gemeint. Im ursprünglichen Verfahren baut der Server aktiv die Verbindung zum Client auf (Abbildung 7.7). Über die Control Connection bekommt der Server den Port mitgeteilt, den der Client für den Datentransfer geöffnet hält. Benutzt wird dazu das FTP-Kommando PORT. Danach kontaktiert der Server in einer eigenen Verbindung den Client von sich aus, eben „aktiv“. Für die nachfolgende Sicherheitsdiskussion ist festzuhalten, daß eingehende TCP-Verbindungen zu nicht vorhersagbaren höheren Ports möglich sein müssen. ❏ Konfiguration des Paketfilters für ausgehende FTP-Verbindungen, aktiv:
internes Netz Adresse Port lokales Netzwerk lokales Netzwerk
1023 1023
Verbindungsaufbau
externes Netz Adresse Port ANY ANY
21 20
Protokoll TCP TCP
Die eingehende FTP-Daten-Verbindung bei aktivem FTP erfordert zusätzliche technische Maßnahmen, wenn Masquerading eingesetzt wird. Da für den Daten-
154
7.1 Häufig benutzte Internetdienste
Abbildung 7.8: FTP Session: Passive Data Connection
kanal keine ausgehende Verbindung geöffnet ist, weiß der Server nicht, wohin er die Verbindung aufbauen soll. Das muß von dem Host abgefangen werden, der Masquerading durchführt. Unter Linux gibt es dazu einige Kernelmodule (auch für FTP), die dazu speziell einkompiliert werden müssen. Die passive Data Connection sieht vor, daß der Client über die Control Connection dem Server mitteilt, daß er eine passive Verbindung für den Datenaustausch wünscht (FTP-Kommando PASV). Wenn der Server dies unterstützt, öffnet dieser einen weiteren Port, teilt dem Client dies in der Antwort auf die PASV-Anfrage mit und wartet ( passiv) auf den Verbindungsaufbau für die Data Connection (Abbildung 7.8).
Die Charakteristik ist noch einmal in der nachfolgenden Tabelle zusammengefaßt. ❏ Konfiguration des Paketfilters für ausgehende FTP-Verbindungen, passiv:
internes Netz Adresse Port lok. Netzwerk lok. Netzwerk
1023 1023
Verbindungsaufbau
externes Netz Adresse Port ANY ANY
21 1023
Protokoll TCP TCP
Der RFC 959, der das FTP-Kommando PASV beschreibt, stammt aus dem Oktober 1985. Mit anderen Worten: es sollte eigentlich keine FTP-Server mehr geben, die dieses Kommando nicht unterstützen. Insbesondere ist der passive Mo-
155
7 Internetdienste und Firewalls
dus der Standard-Modus in allen heute gängigen Webbrowsern. Für eine Firewallumgebung ist das entsprechend zu berücksichtigen. Sicherheitsproblematik bei FTP Es gibt zwei Arten von Sicherheitsproblemen bei FTP: solche, die die TCP-Verbindungen betreffen, und fehlerhafte bzw. fehlerhaft konfigurierte Programme. FTP-Verbindung Aktives FTP bedeutet eingehende Verbindungen. Wenn man sich die Verbindungscharakteristik für aktives FTP oben ansieht, ist ein eingehender Verbindungsaufbau an einen höheren Zielport des Client notwendig. Genau das sollte man unter allen Umständen vermeiden. Damit ließen sich von einem Angreifer Verbindungen nach innen aufbauen, bei entsprechender Filterung immerhin noch zu Ports größer als 1023. Sofern nicht zusätzlich abgesichert, könnte man also Verbindungen zu NFS, zu X, oder auch zu möglicherweise installierten Backdoors aufbauen. Ports jenseits von 1023 sind unprivilegiert, d. h., jeder User könnte dort sein eigenes Programm laufen lassen und auf eingehende Verbindungen warten. Es gibt drei Möglichkeiten, mit dem Problem der aktiven FTP-Verbindung umzugehen: ❏ Proxy einsetzen.
Ein Proxy bietet die Möglichkeit, eingehende Verbindungen auf einen einzigen Host einzuschränken, nämlich auf den, der die Proxy-Verbindung installiert hat. Damit muß man nicht mehr unkontrollierte, von außen zu öffnende Verbindungen fürchten, weil sich ein einziger Host viel besser kontrollieren läßt. Idealerweise bietet der Host außer Proxy-Diensten keine weiteren, um möglichst wenig Angriffsfläche zu bieten. Vor einigen Jahren gab es noch viele Probleme mit den passiven FTP-Verbindungen, die Standardlösung älterer Literatur schlug deshalb immer die Kombination aktive Verbindung plus Proxy vor (deswegen ist ein Proxy noch lange nicht veraltet; nur der Einsatz von Proxies, um Probleme mit aktiven Verbindungen zu umgehen, ist überholt). ❏ Passive FTP-Verbindung verwenden.
Bei der passiven FTP-Datenverbindung wird statt der eingehenden eine ausgehende TCP-Verbindung verwendet. Damit entfällt die offene Türe einer eingehenden Verbindung. Bei Webbrowsern ist die passive FTP-Verbindung ohnehin der Standard-Modus. Es spricht also alles dafür, aktives FTP vollständig zu verbieten und ausschließlich passives FTP zuzulassen.
156
7.1 Häufig benutzte Internetdienste
❏ Dynamischer Paketfilter.
Dynamische Paketfilter besitzen die Möglichkeit, bei aktiven FTP-Verbindungen das übertragene PORT-Kommando des Client auszuwerten und entsprechend eine eingehende Verbindung zu erlauben (dynamischer Paketfilter, oder auch „Stateful Inspection“ genannt). Die eingehende Verbindung ist dann eingeschränkt auf den FTP-Server mit Port 20 (Source) und auf den initiierenden Client mit dem im PORT-Kommando angegebenen Destination Port. Natürlich sind auch Kombinationen möglich. Wo ohnehin ein Proxy installiert ist, etwa um einen FTP-Server, auf den vom Internet aus zugegriffen werden kann, gegen Attacken zu schützen, kann und sollte der Proxy zusätzlich zur passiven Verbindung genutzt werden. Die interne Verbindung zwischen Client und Proxy ist dann unkritisch, aber nach außen sollte der Proxy trotzdem nur passive Verbindungen nutzen, um den Firewall entsprechend sichern zu können. Fehlerhafte und falsch konfigurierte Programme In den nun folgenden Problembeschreibungen geht es um Sicherheitsmängel, die existieren können, wenn man selbst einen FTP-Server betreibt, d. h. selbst FTP-Dienste im Internet anbietet. Ein FTP-Server stellt Dateien zur Verfügung, ggf. nimmt er auch Dateien aus dem Internet an. Dazu benötigt er ein Programm, einen FTP-Daemon, der Bugs enthalten kann. Und er muß entsprechend seinem Einsatz konfiguriert werden. ❏ Dateizugriffsrechte
Ein FTP-Server stellt Dateien anderen Usern zur Verfügung. Sehr oft gibt es dazu auch noch den „anonymous“-Account, mit dem unbekannte Benutzer ohne Autorisierung Dateien lesen können. Auf die vergebenen Zugriffsrechte ist deshalb peinlichst zu achten, andernfalls könnten unbefugte Benutzer, die sich normal angemeldet haben, Daten verschaffen, zu denen sie eigentlich nicht berechtigt sind. Aber nicht nur die Zugriffsrechte auf Daten sind wichtig. FTP erlaubt eine Reihe von Kommandos wie mkdir, chmod, put. Damit lassen sich Daten auf den FTP-Server laden und Zugriffsrechte setzen, z. B. Programme laden und ausführbar machen. ❏ Bugs: Buffer Overflow
Immer wieder werden Exploits der am häufigsten im Internet eingesetzten FTP-Server bekannt. Exploits setzen an vorhandenen Programmierfehlern an und versuchen in der Regel, an eine Shell auf dem jeweiligen Server zu gelangen oder einen weiteren Exploit vorzubereiten, der schließlich und endlich an diese Shell gelangt (ein Exploit ist ein Programm, das speziell dazu geschrieben wurde, eine bekannte Sicherheitslücke zu testen und natürlich auch auszunutzen).
157
7 Internetdienste und Firewalls
Hier ist es ganz wichtig, sich regelmäßig über aufgedeckte Sicherheitslücken zu informieren und Lücken umgehend wieder zu schließen. Exploits sind meist bei der Bekanntgabe eines Bugs bereits im Umlauf, manchmal dauert es nur wenige Tage, bis ein Update für den FTP-Server verfügbar ist (bei Open Source Produkten geht das in der Regel schneller als bei kommerziellen Produkten, eine Ausnahme sind vielleicht die Hersteller von kommerziellen Firewalls, die ja schließlich ihr Geld mit gut gesicherten Systemen verdienen). Leider gibt es im Internet oft auch Monate und Jahre, nachdem der Bugfix verfügbar ist, noch FTP-Server, die anfällig für alte Exploits sind. Hier sind die Systemadministratoren gefragt, sich regelmäßig zu informieren. ❏ FTP-Bounce Attacke
Bei einer aktiven Verbindung teilt der Client mit, zu welchem Port der FTPServer die Verbindung aufbauen soll. Diese Info enthält nicht nur die reine Portnummer, sondern die gesamte Socket-Adresse (IP-Adresse plus Portnummer). Ein Bösewicht kann das ausnutzen und den FTP-Server an eine dritte Adresse weiterleiten. Man kann damit zwei Server gegenseitig beschäftigen oder auch den fehlgeleiteten Server als indirekten Scanner verwenden. Bei passivem FTP entfällt diese Möglichkeit, ansonsten lassen inzwischen gefixte FTP-Server eine Konfigurationsmöglichkeit zu, die nur PORT-Kommandos mit einer IP-Adresse des Client zulassen. ❏ SITE_EXEC Bug von wuftpd
Der Bug ist etwas in die Jahre gekommen und bezieht sich ausschließlich auf wuftpd. Mit einer Telnet-Verbindung auf Port 21 und anschließender Eingabe des Befehls SITE_EXEC bekam man direkten Shellzugang zum Server. Auch wenn man solche Server heute kaum noch findet: es zeigt, daß sich so mancher Programmierer vor nicht allzulanger Zeit kaum Gedanken über möglichen Mißbrauch des Internet gemacht hat. Die DEBUG-Option von älteren Sendmails, die beliebige Shellbefehle ausgeführt hat, ist das wohl bekannteste Beispiel einer offen einprogrammierten Backdoor. Es sollte auch eine Warnung sein, nicht jeden allerneuesten Junk sofort zu installieren und auszuprobieren, sondern sich eher auf altbewährte, gut analysierte und offen diskutierte Open Source Software zu verlassen. Solche Hintertüren (die ursprünglich gar nicht in der Absicht einer Hintertür programmiert wurden) werden in diesem Bereich schneller bekannt und diskutiert. ❏ Mißbrauch für WAREZ
WAREZ ist gestohlene Ware, Diebesgut. Im Falle eines FTP-Servers ist damit Raubgut gemeint, daß sich elektronisch verbreiten läßt, also Software oder andere Dateien (z. B. Musikstücke, Videofilme, etc.). Schlecht gesicherte FTP-Server, auf denen man ungeprüft Dateien ablegen kann, geraten immer in die Gefahr, als Zwischenlager für WAREZ mißbraucht zu werden.
158
7.1 Häufig benutzte Internetdienste
Das ist insofern kritisch zu betrachten, als dies auch strafrechtlich relevant werden kann. Wer den Datenaustausch von Raubware fördert, muß erst einmal beweisen, daß er nicht durch technische Maßnahmen den Mißbrauch hätte verhindern können. Und da es technisch möglich ist, macht man sich in der Regel strafbar. Verzeichnisse, in denen Schreiben erlaubt sein soll, sollten nicht lesbar sein. Einige Befehle in schreibbaren Verzeichnissen sollte man zumindest für anonyme User ganz unterbinden: mkdir, chmod, delete, am besten auch noch die Kommandos, mit denen man dort Dateien holen kann get, mget. Man sollte sich auf keinen Fall nur auf die Dateizugriffsrechte verlassen. Legt man ein Unterverzeichnis in einem nicht lesbaren Verzeichnis an, kann dieses wiederum selbst lesbar sein. Es ist allemal besser, die Konfigurationsmöglichkeiten des FTP-Server zu nutzen und in kritischen Bereichen nur die unbedingt notwendigen Kommandos zuzulassen. ❏ Allgemeine Konfigurationsprobleme
Jeder FTP-Server bringt etwas andere Konfigurationsmöglichkeiten mit sich. Außerdem werden immer wieder neue Sicherheitslücken entdeckt. Deshalb lesen Sie unbedingt die Dokumentation Ihres FTP-Server aufmerksam und vollständig. Verfolgen Sie unbedingt Weiterentwicklungen des FTP-Server und die oft begleitende Sicherheitsdiskussion zu dem Produkt, damit bei Bekanntwerden von Exploits umgehend ein Update oder Workaround eingerichtet werden kann. Bei jedem Update sollte auch überprüft werden, ob sich Konfigurationsparameter geändert haben. Neue Mechanismen bringen oft Einschränkungen, und ein Kompatibilitäts-Modus zur Vorgängerversion kann auch mal deutlich unsicherer sein als die Vorgängerversion selbst. Also auch bei Updates die Dokumentation so aufmerksam lesen wie bei einer Neuinstallation. Ein besonderes Augenmerk ist auf die Useraccounts zu richten. Meist wird im FTP-Verzeichnis eine Kopie der /etc/passwd verwendet. Sehr beliebt ist das Kopieren der /etc/passwd in das FTP-Verzeichnis. Überprüfen Sie dort, ob nur die tatsächlich benötigten User enthalten sind. Systemuser und andere Accounts unbedingt löschen, da diese Datei für FTP-User lesbar ist. Am sichersten ist es, wenn normale User für den FTP-Server andere Passwörter verwenden als für Unix-Accounts. Eine weitere Einschränkungsmöglichkeit ist die Datei /etc/ftpuser. Jeder User, der dort auftaucht, erhält keinen Zugriff. Am besten generiert man diese Datei aus der /etc/passwd und entfernt nur die User, die auch wirklich Zugriff haben sollen. ❏ Klartextpasswörter
FTP überträgt wie Telnet und andere Internetdienste das Passwort im Klartext. Man muß also damit rechnen, daß eingehende Verbindungen im Internet gesnifft und die Passwörter abgefangen werden können. Man soll-
159
7 Internetdienste und Firewalls
te daher über den normalen FTP-Dienst keine vertraulichen Informationen zur Verfügung stellen, auch dann nicht, wenn der Account durch ein gutes Passwort geschützt ist. FTP-Server in Firewallumgebungen Wegen des oben beschriebenen Gefährdungspotentiales empfiehlt es sich, einen allgemein zugänglichen FTP-Server ausschließlich in der demilitarisierten Zone DMZ aufzustellen und diesen zusätzlich mit einem Proxy abzusichern. Abbildung 7.9 zeigt solch eine Konfiguration. Der Proxy sollte sowohl eingehende als auch ausgehende FTP-Verbindungen sichern. Der externe FTP-Server sollte von internen Benutzern ausschließlich für Daten verwendet werden, die auch mit dem Internet/Externen ausgetauscht werden. Daten, die ausschließlich innerhalb des lokalen Netzwerks bleiben sollen, haben auf dem externen FTP-Server nichts zu suchen! Eine weitere Variante wäre ein interner FTP-Server mit einem gesonderten Bereich, in dem interne User Daten für Externe ablegen können. Dieser Bereich könnte dann regelmäßig auf den externen Server gespiegelt werden (etwa mit rsync via ssh). Interne Benutzer müßten dann keinen schreibenden Zugriff auf
Abbildung 7.9: FTP-Verwendung im Firewall: FTP-Server mit Proxy im DMZ
160
7.1 Häufig benutzte Internetdienste
den externen FTP-Server erhalten. Ob solch eine Maßnahme sinnvoll ist, hängt davon ab, ob Sie aus Sicherheitsgründen prinzipiell internen Usern keinen schreibenden Zugriff auf den externen FTP-Server geben wollen, oder ob Sie etwa die ins Internet zu stellenden Daten noch einmal vor der Bereitstellung kontrollieren wollen. Bei dem zweiten Grund ist natürlich zu überprüfen, ob Kontrollmechanismen für die User akzeptabel sind (es könnte natürlich auch eine Unternehmensanweisung sein), und ob die Überprüfungen überhaupt den gewünschten Zweck erreichen. Da der externe FTP-Server immer einbruchsgefährdet ist, sollte in Erwägung gezogen werden, den FTP-Server auf einen eigenen, ausschließlich für FTP-Zwecke zur Verfügung gestellten Rechner zu installieren. Kritische Dienste wie E-Mail und DNS sollten sich nicht auf demselben Rechner befinden. Der externe FTP-Server mit vorgeschaltetem Proxy hat folgende Aufgaben: ❏ Schutz des internen Netzwerks bei eingehenden Verbindungen. Die wohl wich-
tigste Aufgabe eines externen FTP-Server ist, nur dedizierte Dienste (ausschließlich FTP) in einem gesonderten Bereich zur Verfügung zu stellen, wo im Einbruchsfalle kein allzu großer Schaden angerichtet werden kann und in jedem Falle jegliche Berührung mit dem internen Netzwerk vermieden wird. ❏ Schutz des internen Netzwerks bei ausgehenden Verbindungen.
Mit der Installation eines Proxy können alle internen Clients so konfiguriert werden, daß diese ausschließlich Verbindung zu dem Proxy aufnehmen. D. h., interner und externer Router können entsprechend stark filtern und müssen nicht ausgehende Verbindungen von Clients zu beliebigen Servern im Internet zulassen. ❏ Schutz des FTP-Server bei eingehenden Verbindungen.
Ein Proxy wie z. B. der ftp-proxy aus der SuSE Proxy-Suite verfügt über verschiedene Möglichkeiten, den FTP-Zugriff zu beschränken. So ist etwa eine autorisierungsabhängige Konfiguration der zugelassenen Befehle möglich. ❏ Restriktion der Möglichkeiten der User.
Vielleicht wollen Sie nicht, daß Ihre Anwender Daten aus dem Firmennetz auf beliebige Server in das Internet kopieren? Mit der zunehmenden Verbreitung von Trojanern wäre es auch denkbar, daß sich Trojaner einer FTP-Verbindung bedienen, um interne Informationen unbemerkt hinauszuschmuggeln. Ein Proxy mit Protokollier- und Einschränkungsmöglichkeiten der Befehle kann hier zusätzliche Hürden aufbauen. Einschränkende Maßnahmen sind bei Anwendern eigentlich immer unbeliebt, aber es wird immer wieder Gründe geben, die restriktive Maßnahmen erforderlich machen.
161
7 Internetdienste und Firewalls
❏ Ggf. SSL-Fähigkeit herstellen.
Inzwischen gibt es eine Reihe von Clients, die FTP über eine SSL-Verbindung herstellen können und damit zusätzlichen Schutz bieten. SSL-Unterstützung ist bei den gängigen FTP-Servern oft noch nicht vorhanden. Ein SSL-fähiger Proxy (wie der ftp-proxy von SuSE) kann hier Abhilfe schaffen. In einer Firewallumgebung mit DMZ und FTP-Proxy, bei dem sowohl der gesamte ausgehende als auch der eingehende FTP-Verkehr über den Proxy läuft, sieht die Filterung des FTP-Protokolls dann so aus: ❏ Konfiguration des Paketfilters am inneren Router für ausgehende FTP-Ver-
bindungen, passiv: internes Netz Adresse Port lok. Netzwerk lok. Netzwerk
Verbindungsaufbau
1023 1023
Grenznetz Adresse Port FTP-Proxy FTP-Proxy
Protokoll
21 1023
TCP TCP
❏ Konfiguration des Paketfilters am äußeren Router für ausgehende FTP-Ver-
bindungen, passiv: Grenznetz Adresse Port
FTP-Proxy FTP-Proxy
1023 1023
Verbindungsaufbau
externes Netz Adresse Port ANY ANY
21 1023
Protokoll TCP TCP
❏ Konfiguration des Paketfilters am äußeren Router für eingehende FTP-Ver-
bindungen, passiv: Grenznetz Adresse Port FTP-Proxy FTP-Proxy
21 1023
Verbindungsaufbau
externes Netz Adresse Port ANY ANY
1023 1023
Protokoll TCP TCP
❏ Den eigentlichen FTP-Server konfiguriert man am besten so, daß er nicht
auf dem Standard-Port 21 lauscht. Dann kann man den Proxy auf den Standard-Port 21 konfigurieren, d. h., ein normaler Verbindungsaufbau zum FTP-Server erreicht dann immer den Proxy. ❏ Wenn
jede Kontaktaufnahme nun ausschließlich über den Proxy erfolgt, kann der Zugriff auf den FTP-Server auf Verbindungen, die vom Proxy ausgehen, eingeschränkt werden.
Zum Abschluß sei nochmal erwähnt, daß zur Konfiguration des FTP-Server unbedingt die volle Aufmerksamkeit erforderlich ist. Zugriffsrechte, Useraccounts, aktualisierte Versionen sind – wie schon oben unter „Sicherheitsproblematik“ be-
162
7.1 Häufig benutzte Internetdienste
schrieben – unbedingt im Auge zu behalten und aktuelle, gerade bekannt gewordene Sicherheitslücken sind umgehend zu schließen. Sollen Dateien im Internet über sicherere Wege ausgetauscht werden, so ist FTP via SSL eine Möglichkeit, die wegen der verbreiteten Webbrowser fast immer funktioniert. Aber es gibt auch Alternativen: die Secure Shell ssh erlaubt auch eine sehr sichere Datenübertragung, ferner läßt sich die Secure Shell auch mit rsync kombinieren, ein Tool, das für den Datenabgleich (Mirroring) zweier Verzeichnisse in Bezug auf Optimierung der zu übertragenden Daten unschlagbar ist.
7.1.7
World Wide Web: HTTP
Was wäre das Internet, das World Wide Web ohne HTTP? Auch wenn die Leser dieses Buches sicher wissen, was damit gemeint ist, beinhaltet der Eingangssatz fast die ganze Bandbreite des Begriffsmixes, der im Zusammenhang mit Internet/World Wide Web benutzt wird. „Internet“ ist der Zusammenschluß von Netzwerken auf TCP/IP-Basis. Mit dem Begriff „World Wide Web“ wird eine Sammlung von Anwendungen zusammengefaßt, die meisten Anwender verbinden damit aber in erster Linie die Benutzung ihres Browsers zusammen mit HTTP. HTTP wiederum ist ein Protokoll, das mehr kann als nur HTML-Seiten übertragen. Das Protokoll HTTP wurde ursprünglich entwickelt, um wissenschaftliche Arbeiten allgemeinzugänglich in das Internet zu stellen. Die Entwicklung begann am CERN in Genf. Man hatte dabei das Rad nicht völlig neu erfunden, denn es gab schon eine textbasierte Anwendung, die das Prinzip des Hyperlink – verschiedene Dokumente am Ursprungsort belassen, aber eine für den Benutzer völlig transparente Schnittstelle anbieten – kannte: Gopher. HTTP überträgt zunächst einmal ausschließlich ASCII-Text. Der eigentliche Inhalt ist eine Auszeichnungssprache – in der Anfangsphase nur HTML (Hypertext Markup Language) – und ein Client, der die übertragenen Informationen einfach bedienbar darstellt, der sogenannte Browser. Das, was das Web heute ausmacht, ist eine Vielzahl von Erweiterungen wie Skriptsprachen oder Programme, die Server- oder Client-seitig ausgeführt werden können. Und mit den MIME-Formaten ist nahezu jede Anwendung bis hin zu Musik und Video möglich. Spätestens jetzt wird jeder, der sich mit Computersicherheit befaßt, hellhörig. Ausführbarer Code auf beiden Seiten bedeutet auch mögliche Sicherheitsprobleme sowohl auf Server- als auch auf Client-Seite. Dazu später mehr.
163
7 Internetdienste und Firewalls
Zunächst einmal zum Übertragungsprotokoll und dessen Charakteristik. Eine Verbindung im Web basiert auf einem „Uniform Resource Locator“, kurz URL. Die Syntax eines Uniform Resource Locator ist: <protocol>://:<port>/path
Hier beschreiben wir den Uniform Resource Locator nur soweit, wie es für das HTTP-Protokoll nötig und nützlich ist. Wer sich für tiefergehende Details interessiert, sei auf die einschlägigen RFCs verwiesen (RFC 1738, RFC 1808, RFC 2368 und andere). Ein Beispiel: http://www.suse.de:80/de/ ❏ protocol
Welche Protokolle unterstützt werden, hängt vom Client ab. Häufige Protokolle sind http, ftp, news, file, mailto, aber auch gopher, wais, oder neuere wie ldap. Beschrieben werden diese URLs in RFC 1738, RFC 1808, RFC 2368 und weiteren RFCs. Dabei sind nicht alle echte Protokolle. mailto veranlaßt den Browser zum Aufruf eines Mailclient, file dient zum Öffnen eines lokalen File. Der Clou solcher Pseudo-Protokolle ist, daß sich verschiedenste Funktionalitäten über ein einziges Web-Dokument per Mausklick starten lassen. Ein mailto enthält in der Regel alle notwendigen Angaben des Empfängers, so daß sich der Anwender nur noch um den Text kümmern muß. ❏ host
ist der FQDN (Full Qualified Domain Name), also der Name inclusive Domain-Angabe, so wie er im DNS auch aufgelöst werden kann. ❏ port
Ein Dienst oder Protokoll assoziert immer einen Standardport. Bei HTTP ist das Port 80, bei LDAP Port 389 usw. Die URL-Syntax erlaubt durch die explizite Angabe von Portnummern eine Abweichung vom Standard. In der Anfangszeit von Web, Browsern und HTTP war es weit verbreitet, daß Webserver ihre Dienste unter anderen Ports zur Verfügung stellten (beliebt ist immer noch Port 8080), vor allem unprivilegierte Ports, die auf Unixmaschinen auch von normalen Usern benutzt werden können. Mit der Verbreitung von Sicherungsmaßnahmen im Internet wie Firewalls hat die Nutzung von Nichtstandardports stark abgenommen, da nur kontrolliert werden kann, was man auch kennt, wurde bei HTTP Port 80 automatisch zum kleinsten gemeinsamen Nenner, der einzige Port, von dem ein Betreiber eines Webserver ausgehen kann, daß jeder Anwender darauf Zugriff hat (zu SSL-Verbindungen kommen wir im nächsten Abschnitt). Wird der mit dem Protokoll assoziierte Port verwendet, wird die Port-Angabe weggelassen.
164
7.1 Häufig benutzte Internetdienste
❏ path
Der Pfad, unter dem man die gewünschte Seite erreichen kann. Dabei ist in der Regel der Pfad ein relativer Pfad, d. h. die Root „/“ ist im Dateibaum dort, wo der Webserver seine Dokument-Root sieht. Die Charakteristik einer HTTP-Verbindung ist relativ einfach: eine TCP-Verbindung zum Port 80. Allerdings muß man sich die Besonderheiten des HTTPProtokolls auf inhaltlicher Ebene näher ansehen. Bei HTTP/0.9 und HTTP/1.0 ist das Standardverhalten des Webserver, nach jeder Dokumentübertragung die Verbindung wieder zu schließen. Bei einer Webseite mit vielen Icons bedeutete das, daß 20mal und mehr immer wieder eine TCP-Verbindung zum Server aufgebaut werden mußte. Bei HTTP/1.0 konnte dann der Client bei jeder angeforderten Seite dem Server mitteilen, daß er die Verbindung nicht schließen soll, um Overhead zu vermeiden. Mit dem inzwischen üblichen HTTP/1.1 bleibt die einmal aufgebaute TCP-Verbindung bestehen, bis der Client dem Server mitteilt, daß er die Verbindung schließen kann, oder der Server ein Timeout erreicht und die Verbindung von sich aus schließt. Für Webseiten, für die sehr viele Einzeldokumente übertragen werden müssen, ist das klar ein Vorteil. Auf der anderen Seite kommt es jetzt sehr auf die Qualität des Browser an, ob er zum Beispiel beim Wechseln auf einen neuen Link die TCP-Verbindung zum Server vorher von sich aus beendet. In der Regel ist es nicht ungewöhnlich, daß ein Client mehrere TCP-Verbindungen zu ein und demselben Webserver hat, wovon ein Teil offen, ein Teil auf die endgültige Beendigung wartet (TIMEOUT, FIN_WAIT, CLOSE). ❏ Konfiguration des Paketfilters für ausgehende HTTP-Verbindungen:
internes Netz Adresse Port lokales Netzwerk
Verbindungsaufbau
1023
externes Netz Adresse Port ANY
80
Protokoll TCP
Sicherheitsproblematik bei HTTP Gefährdungen, die im Zusammenhang mit HTTP auftreten, lassen sich in zwei Klassen einteilen, abhängig davon, wer gefährdet ist: zum einen der Serverbetrieb, zum anderen der Anwender mit seinem Client. Serverseitige Sicherheitsproblematik ❏ Testkonfigurationen
Webserver wie Apache bringen eine Reihe von Test-Skripten mit, die mitinstalliert werden und voll funktionsfähig sind. Diese Skripten liefern Informationen über die Serverkonfiguration frei Haus.
165
7 Internetdienste und Firewalls
Einem potentiellen Angreifer liefern diese Skripten einen Fundus an Informationen. Sind Exploits gegen die vorgefundene Installation bekannt, ist der Rest für einen Angreifer oft nur ein Kinderspiel. ❏ Zugriffsrechte
Unachtsame Konfiguration der Zugriffsrechte kann dazu führen, daß eigentlich vertrauliche Informationen in unbefugte Hände gelangen. Das kann ein ungeschütztes Verzeichnis sein, das bei der Konfiguration übersehen wurde, ein Symlink, wo eigentlich keiner sein sollte, den der Webserver dann auch noch verfolgt, oder eine Fehlkonfiguration bei der Authentifikation für geschützte Seiten. Werden Zugriffsrechte hostabhängig mit Namen vergeben, könnte sich ein Angreifer über geeignetes DNS-Spoofing hineinmogeln. Und nicht zuletzt kann eine einfache Passwortauthentifikation abgehört und mißbraucht werden. ❏ Ausführbare Skripte
Ausführbare Skripte oder CGI-Programme, die vom Webserver ausgeführt werden, sind immer ein Problem. Während Well-Known-Source-Code bei Bekanntwerden von Sicherheitslücken in der Regel rasch nachgebessert wird, sind CGI-Programme oft selbst erstellt und je nach dem, von wem sie stammen, manchmal schlecht, manchmal auch gar nicht gegen Angriffe geschützt. In den meisten Fällen besteht das Problem darin, daß Benutzereingaben von den CGI-Programmen nur unzureichend geprüft werden und durch eine geschickte Eingabe das CGI-Programm zu unerwünschten Aktionen veranlaßt wird. ❏ Server-Side Includes
sind eigentlich keine richtigen CGI-Programme, sondern eher HTML-Seiten, die aber Inline-Script-Code enthalten. An sich sind sie genauso gut oder schlecht wie CGI-Programme, das Problem liegt ebenfalls in der Kontrollierbarkeit des Code. ❏ HTTP-Befehle
Neben den „normalen“ Befehlen get und post gibt es auch noch gefährliche Befehle: put und delete. Mit put kann eine Webseite auf dem Server abgelegt, mit delete eine Seite gelöscht werden. Beide sind in der Regel per Konfiguration untersagt. Wäre put erlaubt, könnte ein Angreifer ein Skript mit unerwünschtem Code plazieren. ❏ Von FTP und HTTP gemeinsam genutze Verzeichnisse
Können Verzeichnisse, auf die der Webserver zugreift, via FTP benutzt, d. h. dort Daten abgelegt werden, steht der Manipulation Tür und Tor offen. Ein Angreifer könnte zum Beispiel ein PHP3-Skript schreiben, welches meistens auch von normalen Dokumentverzeichnissen aus ausführbar ist. Ein geeignetes Skript nimmt dann Benutzereingaben an und führt diese als Shellcode aus.
166
7.1 Häufig benutzte Internetdienste
❏ Nicht-HTTP-Dienste
haben zunächst nicht direkt mit HTTP etwas zu tun. Aber ein Webserver läuft immer auf einem realen Betriebssystem, und dieses verfügt immer über weitere Dienste, die manipuliert werden könnten, um einen Angriff auf einen Webserver vorzubereiten. Nicht benötigte Internet-Dienste sollten auf jeden Fall deaktiviert, benötigte abgesichert werden (Abschnitte 7.3, 8.1). So wie die oben beschriebene Problematik mit FTP und HTTP in gemeinsamen Verzeichnissen könnten auch andere Dienste genutzt werden, zur Vorbereitung eines Angriffs Daten in die HTTP-Verzeichnisse kopieren. Man kann es nicht oft genugt betonen: alles, was nicht unbedingt zum Betrieb eines Webserver benötigt wird, hat dort nichts zu suchen. ❏ Denial of Service-Attacken
Einige Distributed Denial of Service machten Schlagzeilen, weil sie die Webseiten großer Internetanbieter lahmlegten. Über eine verteilte Infrastruktur von Clients wurde eine ungeheure Anzahl normaler Anfragen an den Webserver gerichtet. Die Clients befanden sich ausschließlich auf Rechnern im Internet, in die vorher eingebrochen wurde, um dort entsprechende Tools zu installieren. Das fatale an solchen Attacken ist, daß diese zunächst wie ganz normale Anfragen aussehen, also einfach nur den offiziellen Dienst in Anspruch nehmen. ❏ Bufferoverflows, Programmierfehler
Überlange Eingabestrings, ungewöhnliche Zeichen oder bestimmte Zeichenkombinationen können den Webserver veranlassen, geschützte Informationen preiszugeben. Manchmal werden wie im Falle des „Internet Information Server“ von Microsoft auch von einem Programmierer „Hintertüren“ eingebaut. Unabhängig, ob bewußt eingebaut oder einfach nur eine unachtsame Programmierung: nach Bekanntwerden der Sicherheitsmängel muß der Webserver unverzüglich auf den neuesten Stand gebracht werden. Exploits sind zu diesem Zeitpunkt in der Regel schon im Umlauf, es ist also nur eine Frage der Zeit, bis irgendein Script-Kiddy den vorhandenen Webserver auch auf das Vorhandensein des Bug testet. Clientseitige Sicherheitsproblematik ❏ Java
Java wurde prinzipiell unter Sicherheitsaspekten auch für Anwendungen im Web entwickelt, bei der die Quelle möglicherweise auch unsicher ist. Dazu verfügt Java über eine Sandbox, in der in einer geschlossenen Umgebung ein unsicheres Programm ausgeführt werden kann, ohne daß irgendein Zugriff auf Daten des gesamten Rechners möglich sind. Über verschiedene Vertrauensabstufungen kann man dann einigen zertifizierten Anwendungen mehr Recht als anderen einräumen.
167
7 Internetdienste und Firewalls
Java ist prinzipiell sicher. Unsicher ist aber möglicherweise die Implementierung im Client/Browser. Setzt man jeweils die neueste Version eines Browser ein und reagiert man bei Bekanntwerden von Sicherheitslücken umgehend, kann Java durchaus benutzt werden. Das Problem liegt eher beim unbedarften User, der trotz einer Warnung, daß unsicherer Code ausgeführt werden soll und Zugriff auf heikle Daten oder Programme beansprucht, statt auf Abbrechen auf OK klickt und weitermacht. . . ❏ Scripting: ActiveX, JavaScript
Mit Angriffsszenarien, die über ActiveX und JavaScript gefahren werden, kann man inzwischen ganze Bücher füllen. Dabei kann unter Umständen beliebig gefährlicher Code automatisch ausgeführt werden – Daten stehlen, Würmer einschleusen, Festplatte formatieren usw. Bei beiden Mechanismen gibt es leider kein 100%tiges Sicherheitskonzept wie die Sandbox bei Java. Von beiden geht eine relativ große Gefahr aus, vor allem da Code ungefragt ausgeführt werden kann. Leider funktionieren viele Websites oft nicht mehr ohne JavaScript vernünftig, weil JavaScript bei einfachen Dingen wie Buttonsteuerung sehr komfortable Möglichkeiten bietet. Trotzdem: im Normalfalle abschalten und nur bei Bedarf benutzen. ❏ Malicious Code, Mißbrauch von Tags
In HTML-Text kann direkt ein bösartiges Skript eingebaut sein, oder trickreicher: der Anwender wird von einer bekannten, aber leicht manipulierten Webseite umgeleitet auf eine Hackerseite, die nichts Gutes im Schilde führt. Theoretisch gefährlicher ist der Code, der automatisch ausgeführt wird und auch via E-Mail übermittelt werden kann (viele E-Mail-Clients, ob in den Browser integriert oder nicht, unterstützen HTML-Formatierungen). Gutmütige Benutzer sind aber nicht weniger sicherheitskritisch, wenn nach einer Umleitung z. B. eine ähnliche Webseite präsentiert wird und persönliche Angaben preisgegeben werden. Das CERT-Advisory CA-2000-02 (http://www.cert.org/) beschreibt eine Sammlung möglicher Mechanismen. Wichtige Daten sollten ausschließlich einer verschlüsselten Verbindung via SSL anvertraut werden. ❏ Bufferoverflows der Browser
Kein Programm ist gegen Programmierfehler gefeit. Wie bei Servern können ungewöhnliche Eingaben (z. B. überlange URLs oder eine Kombination bestimmter Zeichen) zu einem Absturz oder zur Preisgabe sicherheitskritischer Informationen führen. Dagegen hilft nur das aufmerksame Mitverfolgen aktueller Sicherheitsdiskussionen (z. B. über einschlägige Mailinglisten) und das Einspielen von Patches oder Updates, sobald Probleme bekannt geworden sind.
168
7.1 Häufig benutzte Internetdienste
❏ MIME-Attacken
MIME an sich ist eine großartige Erfindung. Beliebige Daten können einfach übertragen und mit der dazugehörigen Anwendung ausgeführt werden. Browser und andere Clients sind oft so eingestellt, daß bestimmte MIMETypen automatisch eine dazugehörige Anwendung starten. „Bösartige“ Daten können eine Anwendung veranlassen, unerwünschte Dinge zu tun. Angefangen von Makroviren in Office-Applikationen über bösartige Executables bis hin zu Exoten (auch in Postscript gibt es eine Möglichkeit, Makros auszuführen, wenn der Interpreter dies unterstützt). Der Anwender ist hier in der Regel meist mitschuldig. Wenn der Browser abfragt, ob eine Anwendung abgespeichert oder ausgeführt werden soll, insbesondere wenn diese auch noch aus nicht sicherer Quelle stammt, und der Anwender dennoch „Ausführen“ drückt. . . ❏ Download von Trojanern, Viren, Würmern
Via HTTP kann man auch Dateien herunterladen, wenn der Server das anbietet. FTP ist dann nicht mehr notwendig. Mit anderen Worten: eine einfache HTTP-Verbindung erlaubt auch Downloads. Nur über Paketfilterung ist das nicht zu steuern. Damit hat jeder Anwender auch die Möglichkeit, Trojaner, Viren, Würmer und anderes Getier auf seinen Rechner zu laden, diesen zu infizieren und ggf. in eine lokales Netzwerk einzuschleusen. Dieser Punkt ist zwar nicht unbedingt HTTP-spezifisch, aber hier besonders zu beachten, da ein Browser in der Bedienung einfacher ist als andere Tools, und durch die Systematik von Hyperlinks man eigentlich nur mitbekommt, von wo die Daten eigentlich geladen werden, wenn man auch darauf achtet. HTTP in einer Firewallumgebung Für die Konfiguration in einer Firewallumgebung sollte man bei HTTP unterscheiden in Clientnutzung aus dem internen Netz heraus und dem Bereitstellen eines Serverdienstes. Wie bei FTP empfiehlt es sich auch bei HTTP-Diensten zu unterscheiden zwischen internen Daten und Daten, die im Internet bereitgestellt werden sollen. Der interne Server benutzt vielleicht auch noch Zugangsberechtigungen, um Abteilungen oder Personen unterschiedliche Rechte einzuräumen. Authentifikationsdaten und andere sensible Daten haben in der Demilitarisierten Zone nichts zu suchen. Der interne Webserver sollte auf keinen Fall von Rechnern aus der DMZ oder aus dem Internet erreichbar sein, also nur auf Anfragen aus dem internen Netzwerk antworten.
169
7 Internetdienste und Firewalls
Abbildung 7.10: Anordung für HTTP-Proxy
Für das Surfen lokaler Anwender im Internet sollte nach Möglichkeit ein Proxy eingerichtet werden, der die Kontrolle über die Inhalte (Scripting, Download etc.) zuläßt. Der Webserver im DMZ selbst muß nicht unbedingt durch einen Proxy geschützt werden – eine sichere Konfiguration vorausgesetzt. Der Upload von Daten läßt sich über die Konfiguration verbieten, so daß dort nur Daten liegen, die man selbst abgelegt hat. Und gegen Bugs in selbst implementierten CGI-Skripten hilft nur saubere Programmierung, keine Proxy. Abbildung 7.10 zeigt eine Anordung von Webserver und Proxy in einer Firewallumgebung. Ein praktischer Tip: auf dem internen Webserver läßt sich ein Bereich einrichten, auf dem die Webseiten für das Internet entwickelt und bereitgestellt werden. So können von internen Anwendern die Internet-Webseiten gelesen und getestet werden, bevor diese ins Internet gehen. Mittels Secure Shell und Rsync können die Daten dann sicher auf den externen Webserver übertragen (gespiegelt) werden. Dabei ist nur darauf zu achten, daß die Seiten sich unterhalb eines fiktiven
170
7.1 Häufig benutzte Internetdienste
Root-Verzeichnisses referenzieren, d. h. keine Hypertextlinks mit absoluten Links verwendet werden (bis auf eventuelle Querverweise in das Internet direkt). Die Aufgaben des Proxy im DMZ sind: ❏ Schutz des internen Netzwerks
Wenn die Clients über einen Proxy auf das Internet zugreifen, kann der Paketfilter so konfiguriert werden, daß er ausschließlich HTTP-Zugriffe vom Proxy aus in das Internet zuläßt bzw. Clientzugriffe aus dem internen Netzwerk nur zum Proxy erlaubt. ❏ Schutz vor Malicious Code
Je nach Ausführung des Proxy kann er vor der Ausführung von Scriptingsprachen oder unerwünschten Links schützen. Manche Proxys wie http-gw aus dem FWTK-Toolkit haben die Möglichkeit, die Verwendung von Skriptsprachen clientabhängig zu steuern, um älteren Browsern die Ausführung von Skripten zu untersagen. ❏ Einschränkung der Möglichkeiten der User
Möglicherweise verbietet die Security Policy den Download von bestimmten Daten oder den Besuch einschlägiger Seiten, weil in einem Unternehmen das Surfen nur zu dienstlichen Zwecken erlaubt ist. Ein Proxy bietet u. U. die Möglichkeit, Inhalte zu filtern (auch bekannt unter dem Stichwort „Content Filtering“). ❏ Zwischenspeicherung von Webseiten
Der eigentliche Zweck, für den Proxies ursprünglich entwickelt wurden, war die Beschleunigung des Web durch Zwischenspeicherung häufig abgefragter Daten. Wenn mehrere User nacheinander ein und dasselbe Dokument ansehen, wird es bei der Verwendung eines Proxy (die korrekte Bezeichnung ist in diesem Sinne eigentlich Cache) nur einmal in den Cache geladen und steht bei weiteren Zugriffen sofort zur Verfügung. Gerade bei langsamen Internetanbindungen oder einer größeren Anzahl von Usern bringt ein Cache deutliche Geschwindigkeitsvorteile und entlastet die Leitung in das Internet für andere Zwecke. Solch ein cachender Proxy ist zum Beispiel Squid. Die Paketfilterregeln sind für eine Firewallumgebung mit DMZ und HTTP-Proxy, bei dem der gesamte ausgehende HTTP-Verkehr über den Proxy läuft, der eingehende HTTP-Verkehr landet dagegen direkt auf dem Web-Server: ❏ Konfiguration des Paketfilters am inneren Router für ausgehende HTTP-
Verbindungen: internes Netz Adresse Port lok. Netz
1023
Verbindungsaufbau
Grenznetz Adresse Port HTTP-Proxy
proxy
Protokoll TCP
171
7 Internetdienste und Firewalls
❏
proxy ist der Port, auf dem der Proxy läuft. Das kann auch Port 80 sein, Squid läuft in der Regel auf Port 3128.
❏ Konfiguration des Paketfilters am äußeren Router für ausgehende HTTP-
Verbindungen: Grenznetz Adresse Port HTTP-Proxy
Verbindungsaufbau
externes Netz Adresse Port
1023
ANY
80
Protokoll TCP
❏ Konfiguration des Paketfilters am äußeren Router für eingehende HTTP-
Verbindungen zum Webserver im DMZ: Grenznetz Adresse Port HTTP-Server
7.1.8
Verbindungsaufbau
80
externes Netz Adresse Port ANY
1023
Protokoll TCP
HTTP via SSL/TLS
HTTP besitzt weder Verschlüsselungmechanismen noch Authentifikationsmethoden, die nach einem Verbindungsaufbau fortwährend überprüfen, ob der Gegenüber immer noch derselbe Partner ist wie zum Zeitpunkt der Autorisierung. Von der ursprünglichen Idee her, wissenschaftliche Dokumente einer möglichst breiten Öffentlichkeit ohne jegliche Geheimnistuerei zur Verfügung zustellen, machen Kryptographie und andere Sicherheitsmechanismen wenig Sinn. Aber im Zuge der Kommerzialisierung des Internet entstand mehr und mehr Bedarf, zwar die Infrastruktur zu teilen (das Internet), aber weniger die Inhalte. Insbesondere kritische Daten wie Kreditkarteninformationen (Stichwort „eCommerce“) sollten mit einfachem HTTP nie übertragen werden. Um die Sicherheitslücken von HTTP zu beheben, entwickelte Netscape den „Secure Socket Layer“ (SSL). Daneben gibt es noch den Begriff „Transport Layer Security“ (TLS). TLS ist als Weiterentwicklung zu verstehen. Wer von SSL/TLS spricht, meint in der Regel drei Protokollversionen: SSLv2, SSLv3 und TLSv1. Weitere Infos zu TLS finden sich unter http://www.ietf.org/html.charters/tls-charters.html SSL/TLS verwendet zur Authentifikation Public-Key-Methoden. Danach wird ein geheimer Schlüssel ausgetauscht, der zur Verschlüsselung der eigentlichen Sitzung dient (symmetrische Verschlüsselung aus Performance-Gründen). Während der Sitzung wird zusätzlich über weitere Methoden überprüft, ob die Sitzung vielleicht abgefangen wurde (MD5, SHA). Der interessanteste Part ist sicher die Authentifikation. Bei Public-Key-Mechanismen benötigt der Anwender den Public Key des Server, um dessen Identi-
172
7.1 Häufig benutzte Internetdienste
tät sicherstellen zu können. Nun gibt es aber eine fast unendliche Anzahl von Webservern im Internet, und niemand wäre in der Lage, deren Public Keys vorhalten zu können. Kritisch beim Akzeptieren eines Public Key ist der Weg, über den er kommt. Eine praktische und einfache Lösung ist das Zertifikat. Sogenannte Certificate Authority (kurz CA) signiert den Public Key des Webserver mit einem eigenen Private Key. Beim Verbindungsaufbau sendet der Webserver sein Zertifikat mit (den von der CA zertifizierten Public Key). Der Client muß nur noch überprüfen, ob er den Public Key der CA kennt und akzeptiert (genaugenommen ist es kein Public Key der CA, sondern ein selbstsigniertes Zertifikat, das den Public Key der CA enthält). Kennt der Client, in der Regel ist das der Browser, das CA-Zertifikat nicht, ist der Anwender gefragt: er kann es akzeptieren oder ablehnen. Zertifikate und CAs können auch selbst erstellt werden. Ein sehr gutes Handbuch auf der Basis von OpenSSL ist beim DFN-CERT zu finden: http://www.pca.dfn.de/dfnpca/certify/ssl/handbuch Sicherheitsproblematik bei SSL Auch bei SSL gibt es eine Reihe von Gefährdungen: ❏ Unsichere Schlüsselgenerierung
Nach der Autorisierung wird ein Sitzungsschlüssel generiert. Eine frühere Implementierung von Netscape generierte Sitzungsschlüssel, die erratbar waren. Mit einem erratenen Sitzungsschlüssel kann die Verbindung abgehört werden. ❏ Implementierungsfehler beim Umgang mit Zertifikaten
Bei einigen Netscape-Versionen bis einschließlich 4.72 ist die Überprüfung der Zertifkate unsicher. Netscape prüfte nach erfolgreichem Verbindungsaufbau dann nur noch die IP-Nummer des Server, nicht den Hostnamen. Zusammen mit einer gleichzeitigen DNS-Spoofing-Attacke könnte ein Angreifer eine aufgebaute Sitzung übernehmen. (CERT Advisory CA-2000-05). ❏ Zu kurze Schlüssellängen
US-Gesetze verhinderten bis Anfang 2000 den Export von starker Verschlüsselung. In den ersten Implementierungen war SSL auf 40 Bit lange Sitzungsschlüssel begrenzt, die später auf 56 Bit ausgedehnt wurde. Mit fortschreitender Rechenleistung und das Rechnen in verteilten Netzen ist ein BruteForce-Angriff auf solche kurzen Schlüssel möglich. Nach der Freigabe stärkerer Verschlüsselung sollte man auf jeden Fall aktuelle Browser mit mindestens 128-Bit-Verschlüsselung einsetzen.
173
7 Internetdienste und Firewalls
❏ Unachtsame Benutzeraktionen
Wenn ein Anwender die Webseite von www.e-bank.com besuchen möchte, hat ein Angreifer drei Möglichkeiten, die Verbindung umzulenken und dem Anwender falsche Zertifikate unterzuschieben: ➢ Der Hacker erstellt eigenes Zertifikat mit eigener CA Der Benutzer bekommt in diesem Falle die Warnung, daß der Browser die CA-Behörde nicht kennt. Klickt er auf „akzeptieren“, landet das falsche Zertifikat im Browser. ➢ Der Hacker verwendet ein abgelaufenes und gestohlenes Zertifikat Der Anwender wird gewarnt, daß das Zertifikat abgelaufen ist. Meist sind abgelaufene Zertifikate nicht so streng gesichert, weil man damit ja nichts mehr anstellen kann. Trotzdem hat der Benutzer die Möglichkeit, im Browser das abgelaufene Zertifikat zu akzeptieren. ➢ Der Hacker verwendet ein Zertifikat einer anderen Webseite In diesem Falle wird der Browser vermutlich die Verwendung des Zertifikats ablehnen. Es bleiben zwei Fälle, in denen ein unachtsamer Benutzer einem Angreifer selbst die Türe öffnet. Implementierungsspezifische Probleme werden in der Regel umgehend behoben und sind meist in neueren Versionen nicht mehr enthalten. Die Beispiele zeigen aber, das sie trotz sicherer Mechanismen hin und wieder vorkommen. Der Systemadministrator muß unbedingt auf aktuelle Exploits reagieren (Einspielen von Patches, Softwareupdates etc.). Darüber hinaus gelten natürlich für SSL/TLS dieselben Gefährdungspotentiale, die sich auf die Inhalte beziehen. SSL/TLS schützt nur vor Abhören oder Spoofing, nicht vor Malicious Code, Scripting-Attacken oder Browser-Sicherheitslücken. SSL/TLS in einer Firewallumgebung SSL/TLS ist als Ergänzungsprotokoll zu HTTP eigentlich nicht ohne HTTP vorstellbar. Wegen der engen Verknüpfung der beiden Protokolle und der ähnlichen Anwendung sollten die Konfigurationen für HTTP und SSL/TLS identisch sein. Deshalb hier noch einmal die Filterregeln zusammen mit HTTP. Bei Einsatz eines Proxy von HTTP sollte die SSL/TLS-Verbindung ebenfalls über den Proxy geführt werden, um die Möglichkeit der Filterung auch bei SSL zu erhalten. Im Gegensatz zu HTTP-Daten können SSL-Daten aber nicht gecacht werden, sondern werden vom Proxy nur weitergeleitet (forwarding). ❏ Konfiguration des Paketfilters am inneren Router für ausgehende HTTP/-
SSL/TLS-Verbindungen:
174
7.1 Häufig benutzte Internetdienste
internes Netz Adresse Port lok. Netz ❏
proxy 3128).
Verbindungsaufbau
1023
Grenznetz Adresse Port HTTP-Proxy
Protokoll
proxy
TCP
ist der Port, auf dem der Proxy läuft (bei Squid in der Regel Port
❏ Konfiguration des Paketfilters am äußeren Router für ausgehende HTTP/-
SSL/TLS-Verbindungen: Grenznetz Adresse Port HTTP-Proxy HTTP-Proxy
Verbindungsaufbau
1023 1023
externes Netz Adresse Port ANY ANY
80 443
Protokoll TCP TCP
❏ Konfiguration des Paketfilters am äußeren Router für eingehende HTTP/-
SSL/TLS-Verbindungen zum Webserver im DMZ: Grenznetz Adresse Port HTTP-Server HTTP-Server
7.1.9
80 443
Verbindungsaufbau
externes Netz Adresse Port ANY ANY
1023 1023
Protokoll TCP TCP
ping und weitere ICMP-Messages
Mit dem Programm ping lassen sich Netzwerkverbindungen testen. ping erzeugt eine ICMP-Message vom Typ echo-request (numerischer Wert: 8) und wartet auf entsprechende Antworten vom Typ echo-reply (numerischer Wert: 0, alle ICMP-Typen werden in Abschnitt A.4 aufgezählt). Neben der Information, ob ein Host im Netzwerk erreichbar ist, lassen sich aus der Ausgabe von ping auch weitere Informationen wie Laufzeiten entnehmen. Hier soll nicht näher auf die Features von ping eingegangen werden, von Interesse sind nur die Paketfiltereigenschaften des verwendeten ICMP-Protokolls. Weitergehende Informationen zu ping liefert [Ste94]. ICMP hat keinen Absender- oder Zielport, sondern nur einen Nachrichtentyp. Ausgehender Ping ping ist als Hilfsmittel zum Testen von Netzwerkverbindungen äußerst nützlich, deshalb ist es fast immer sinnvoll, ausgehenden Ping zu erlauben. Eventuell schränkt man ausgehende Pings auf einige wenige sendende Hosts ein, die Netzwerkadministratoren zur Kontrolle der Anbindung zu externen Netzen wie Internet benutzen.
175
7 Internetdienste und Firewalls
❏ Ausgehender Ping:
interne Adresse lokaler Host lokaler Host
Richtung
externe Adresse ANY ANY
ICMP-Message Typ Code 8 0
Aktion
-
ALLOW ALLOW
Eingehender Ping Eingehende Pings können nützliche Informationen liefern, wenn die Verbindung zum Internet-Provider einmal nicht klappt oder es Probleme mit dem Verbindungsaufbau zu einem Host gibt, der von außen erreichbar sein soll. Allerdings könnte auch ein potentieller Angreifer Informationen über verfügbare, aber nach außen hin nicht unbedingt bekannte Hosts sammeln. Generell empfiehlt es sich, eingehende Pings einzuschränken: zum einen kann man dafür sorgen, daß nur der Host, der mit dem externen Netz verbunden ist, von außen via Ping erreichbar ist, zum zweiten lassen die Hosts, auf die geantwortet werden soll, ebenfalls einschränken, etwa auf das lokale Netzwerk des Internet-Providers. Berücksichtigen sollte man dabei auch, daß Hosts, die von außen erreichbar sein sollen (Webserver, FTP-Server, Mailserver), aus diesem Grunde auch im DNS eingetragen und damit von ihrer IP-Adresse her bekannt sind (ebenso der Dienst, den diese mindestens anbieten – aus der Namensgebung heraus erkennbar). Erlaubt man Ping zu diesen Rechnern, sollte man aber mit DoS-Attacken rechnen: Sicherheitslücken müssen sofort geschlossen werden, wenn sie bekannt werden (ein Beispiel für eine DoS-Attacke mittels Ping ist Ping-of-Death, d. h., es werden ungewöhnlich große Ping-Pakete versandt; bei einigen fehlerhaften Implementationen führte das zum Absturz des Rechners). Im Linux-Kernel kann man außerdem die Antwortrate für echo reply Pakete begrenzen (siehe Anhang A.4). ❏ Eingehender Ping:
externe Adresse Provider-Net Provider-Net ANY ANY ANY
ICMP-Message Typ Code 8 0 8 0 8
-
Aktion ALLOW ALLOW ALLOW ALLOW DENY
7.1 Häufig benutzte Internetdienste
Weitere ICMP-Messages ICMP-Nachrichten lassen sich unterscheiden in Queries und Fehlernachrichten. Queries stellen ein Frage-Antwort-Spiel dar, als Beispiel dienen echo request und echo reply für den Ping-Mechanismus. Weitere Queries sind die Typen 9,10 (router advertisement, router solicitation), 13,14 (timestamp request, timestamp reply), 15,16 (information request, information reply), 17,18 (address mask request, address mask reply). Generell sollte man auf ICMP Queries mit Ausnahme von echo request und echo reply ganz verzichten. Fehlernachrichten werden nur in eine Richtung versandt und enthalten mitunter nützliche Information, könnten aber auch genauso gut gefälscht sein und Angriffe unterstützen oder vorbereiten. Gebräuchliche ICMP-Messages nun im Überblick: ❏ destination unreachable (3):
Hier gibt es eine ganze Reihe von Codes (siehe Anhang A.4). Von Interesse sind u. a. die Codes 0 (network unreachable), 1 (host unreachable), 3 (port unreachable) und 4 (fragmentation needed). Nachrichten mit Code 0, 1 und 4 werden von Routern auf dem Übertragungsweg generiert und haben mit Routing zu tun, Code 3 (port unreachable) dagegen von einem Zielhost. Bei einfachen Anbindungen, d. h. entweder wird ein Host direkt an ein externes Netz angebunden (Standalone-PC) oder hinter einem Firewall existiert nur ein flaches, nicht tiefer strukturiertes Netzwerk, können ausgehende Routing-Fehlermeldungen (0, 1, 4) eigentlich nur vom direkt angeschlossenen Host/Router stammen. Man kann sie aus dem internen Netz heraus blockieren. Eingehende Routing-Fehlermeldungen sind einerseits sehr hilfreich, weil die Applikation (z. B. der Browser) direkt abbrechen kann, statt auf einen Timeout zu warten. Andererseits wird in der Regel die Verbindung von der Applikation abgebrochen, wenn eine destination unreachableMessage eingeht. Und das läßt sich wiederum prima für DoS-Attacken mißbrauchen. Geht man davon aus, daß eingehende Routing-Fehlermeldungen nur selten auftreten, kann man diese Pakete ganz unterbinden. Sinnvoll sind Routing-Fehlermeldungen, wenn diese von einem äußeren Router generiert werden und an das interne Netz gerichtet sind, vor allem dann, wenn die Extern-Anbindung über eine Wählleitung durchgeführt wird. destination unreachable-Nachrichten mit Code 3 werden von einem Host generiert, wenn dieser auf einem UDP-Port angesprochen wird, der keinen Dienst zur Verfügung stellt. Und solche Nachrichten sollten ausgehend ebenfalls unterbunden werden. Warum? Weil es sich als verdeck-
177
7 Internetdienste und Firewalls
ter Ping mißbrauchen läßt. Vorausgesetzt, der Firewall erlaubt eingehende UDP-Pakete in irgendeiner Form. Ein existierender Rechner antwortet mit einem port unreachable, wenn an diesem Port kein UDP-Dienst zur Verfügung steht. interne Adresse internes Netz internes Netz internes Netz äußerer Router äußerer Router
Richtung
externe Adresse
ICMP-Message Typ Code
ANY äußerer Router ANY ANY ANY
3 3 3 3 3
alle alle alle 0,1,4 alle
Aktion DENY ALLOW DENY ALLOW DENY
❏ source quench (4):
Ein Empfänger kann den Absender bremsen, wenn die eingehenden Pakete zu schnell ankommen und nicht in dieser Geschwindigkeit verarbeitet werden können. Erstens liegt hier die Betonung auf kann, d. h., der Empfänger muß diese Pakete nicht unbedingt versenden, zweitens schreiben neuere Router-RFCs vor, daß Router niemals source quench-Nachrichten versenden sollen. source quench-Messages erlauben leider auch DoS-Attacken. Sendet ein Angreifer massiv source quench-Nachrichten an einen Host, z. B. an den äußeren Router, kann er dessen Kommunikation empfindlich stören. Vorschlag deshalb: ausgehende source quench-Nachrichten vom äußeren Router erlauben, alle anderen verbieten. interne Adresse äußerer Router internes Netz internes Netz
Richtung
externe Adresse ANY ANY ANY
ICMP-Message Typ Code 4 4 4
Aktion ALLOW DENY DENY
❏ redirect (5):
Ein redirect an einen Router führt dazu, daß dieser normalerweise seine Routing-Einträge ändert und der Nachricht entsprechend anpaßt. Angreifer machen sich dies häufig zunutze und versuchen, darüber RoutingTabellen zu manipulieren und Einfluß auf den Weg der Pakete zu nehmen. Am besten verzichtet man ganz darauf. Ursprünglich war die redirectNachricht dazu gedacht, daß Hosts nach dem Start nur minimale RoutingInformationen besitzen und den Rest über solche Nachrichten lernen. Wegen der Sicherheitsproblematik sollte man alle beteiligten Hosts mit korrekten statischen Routen versehen.
178
7.1 Häufig benutzte Internetdienste
interne Adresse
Richtung
ANY
externe Adresse
ANY
ICMP-Message Typ Code
Aktion DENY
5
❏ time exceeded (11):
Wird generiert, wenn der TTL-Zähler bei 0 angelangt ist (siehe Abschnitt 4.1). In der Regel bedeutet das, daß das Paket in einer Schleife hängt. Andererseits wird der TTL-Zähler auch vom Programm traceroute benutzt. traceroute sendet UDP-Pakete an einen hohen UDP-Port (typisch 30000) mit von Paket zu Paket um 1 erhöhten TTL-Zähler aus und ermittelt aus den eingehenden ICMP-Messages mit time exceeded bzw. port unreachable die tatsächliche Route. Man sollte daher ausgehende time exceeded-Messages auf den äußeren Router begrenzen. Eingehende time exceeded-Messages kann man erlauben, allerdings macht es durchaus Sinn, diese auf einige wenige Hosts zu beschränken (etwa Webserver und solche, die von den Systemadministratoren benutzt werden).
interne Adresse äußerer Router internes Netz äußerer Router Adminhosts ANY
Richtung
externe Adresse ANY ANY ANY ANY ANY
ICMP-Message Typ Code 11 11 11 11 11
Aktion ALLOW DENY ALLOW ALLOW DENY
❏ parameter problem (12):
Signalisiert ein Problem mit dem IP Header (Code = 0) oder eine benötigte Angabe im Header fehlt (Code = 1). Sollte zumindest zum äußeren Router in beide Richtungen erlaubt werden (kann aber auch für innere Hosts freigegeben werden): interne Adresse äußerer Router äußerer Router
Richtung
externe Adresse ANY ANY
ICMP-Message Typ Code 12 12
Aktion ALLOW ALLOW
Unterstützende Maßnahmen im Linux-Kernel Der Linux-Kernel enthält einige zusätzliche Möglichkeiten, um mißbräuchliche Verwendung von ICMP-Messages einzuschränken. Die Parameter finden sich unter /proc/sys/net/ipv4/icmp_* und sind im Anhang B näher beschrieben.
179
7 Internetdienste und Firewalls
7.1.10
Usenet-News: NNTP
Usenet-News ist einer der ältesten Dienste im Internet. Vor der Verbreitung von HTTP und Hyperlinks waren die Usenet-News das Informationsmedium im Internet schlechthin. Durch die explosionsartige Verbreitung des World Wide Web sind die Usenet-News etwas aus dem Rampenlicht gerückt. Zusätzliche Konkurrenz bieten unzählige Mailinglisten, die ihre Informationen direkt via E-Mail an die Abonnenten senden. News werden im Internet über das Network News Transfer Protocol (NNTP) verbreitet. Die Informationen werden überwiegend im Pull-Verfahren verteilt, d. h., Clients und Server holen sich die Informationen von Servern ab. Alle Anwender, die einen News-Server gemeinsam verwenden, greifen auf dieselben Daten zu. Der Client merkt sich, welche Gruppen gelesen werden sollen und welche Artikel bereits gelesen wurden. Der Server räumt in regelmäßigen Abständen auf (Expire), d. h., News, die ein bestimmtes (konfiguriertes) Alter überschritten haben, werden wieder gelöscht. Die Datenmengen, die täglich neu verteilt werden, werden bei einem kompletten Newsfeed (alle vorhandenen Gruppen aus dem Internet) in Gigabyte gerechnet; pro Tag, wohlgemerkt. NNTP wird über den Port 119 via TCP angeboten. Server wie Clients, die sich selbst mit News versorgen, benutzen denselben Port. ❏ Charakteristik von NNTP:
internes Netz Adresse Port Client
1023
Verbindungsaufbau
externes Netz Adresse Port NNTP-Server
119
Protokoll TCP
Gefährdungspotential von NNTP NNTP ist ein sehr einfaches Protokoll. Bisher gibt es keine bekannten Angriffe, die sich das Protokoll selbst zunutze machen. Bekannt wurden dagegen datengesteuerte Angriffe: ❏ Automatische Newsverwaltung
News beinhalten die Möglichkeit, automatisch Gruppen anzulegen und zu löschen. Ist diese Möglichkeit konfiguriert, kann ein Angreifer über Nacht tausende von Gruppen einrichten. Auch wenn dann ggf. keine Daten kommen und keine Platten überlaufen, ist das ärgerlich für die Benutzer, deren News-Client in der Regel alle neuen Gruppen anzeigt und der User immer diese Gruppen abbestellen muß (unsubscribe). Mit Aufwand verbunden, aber sicherer ist in jedem Falle, Gruppen nicht automatisch anlegen oder entfernen zu lassen. Neue Gruppen müssen dann von Hand eingetragen werden.
180
7.1 Häufig benutzte Internetdienste
❏ Formatierte Nachrichten
Während früher News ausschließlich in reinem ASCII-Format verbreitet wurden, gibt es inzwischen auch viele Clients, die HTML-Formatierung und MIME-Formate unterstützen. Damit gelten für News dieselben Gefährdungspotentiale wie für HTTP-Clients, mit dem Unterschied, daß Newslesen immer eine Offline-Angelegenheit ist, während bei HTTP immer eine Online-Verbindung existiert. Es hängt von den Möglichkeiten des Client ab, ob hier eine Gefährdung besteht. Der Netscape Messenger kann prinzipiell Javascript aus Mails und News heraus ausführen, allerdings ist dieses Feature abstellbar. Gegen ein Attachment, das abgespeichert und danach ausgeführt wird, hilft bei News nur die Aufklärung der Anwender. Ein reiner ASCII-Client dagegen ist so gut wie immun gegen „gefährliche Inhalte“. NNTP in Firewallumgebungen Da von vielen Providern News angeboten wird, und im Prinzip jeder in öffentliche Newsgroups posten kann, ist es nicht erforderlich, einen öffentlichen Newsserver zu betreiben. Man kann diesen Service getrost den Providern überlassen, die in der Regel sowieso über die besseren Anbindungen und größeren Kapazitäten verfügen. Ferner ist zu überlegen, ob überhaupt ein eigener Newsserver betrieben werden soll. Man kann Client-seitig ebenfalls auf die Dienste der Provider zurückgreifen und muß sich nicht mit dem Verwaltungsaufwand eines Newsserver herumschlagen. Einen eigenen Newsserver – wenn auch nur für eigene User – zu betreiben bedeutet, daß auf jeden Fall die Übertragungs- und Speicherkapazitäten für das täglich bezogene Newsaufkommen vorhanden sein müssen. Ein Zwischenweg ist ebenfalls denkbar: Man kann einige wenige, häufig genutzte Newsgroups auf einem lokalen Newsserver zur Verfügung stellen, und gleichzeitig die Nutzung von NNTP zum Provider erlauben. Allerdings ist man dann auf Newsclients angewiesen, die mehrere Newsserver parallel benutzen können. Für die Firewallumgebung kommen deshalb zwei Szenarien in Frage: zum einen die direkte Benutzung des Newsserver beim Provider, zum anderen die Einrichtung einer eigenen Newsserver-Infrastruktur, um teilweise oder vollständig News lokal lesen zu können. Direkte Benutzung des Newsserver beim Provider Der Fall ist relativ einfach: Es muß lediglich die Benutzung von Port 119 der lokalen Clients zum Newsserver des Providers zugelassen werden. Eine inhaltliche Filterung ist allerdings nicht möglich.
181
7 Internetdienste und Firewalls
❏ Newslesen beim Provider:
internes Netz Adresse Port lok. Netzwerk
1023
Verbindungsaufbau
externes Netz Adresse Port NNTP-Serv.
119
Protokoll TCP
Eigener Newsserver Ein Grund für einen eigenen, internen Newsserver könnte sein, daß lokale Gruppen betrieben werden sollen, die für das Internet nicht sichtbar sein sollen. Ein anderer Grund könnte sein, die Flut an News für lokale Anwender einzuschränken und die zu lesenden Newsgroups zu selektieren. Usenet-News als Offline-Kommunikationsmedium bringen die Proxy-Fähigkeit gleich mit. Den Newsserver, der mit der Außenwelt kommuniziert, stellt man am besten in die demilitarisierte Zone (siehe Abbildung 7.11). Ob man neben dem externen Newsserver in der DMZ noch einen weiteren, internen Newsserver betreibt, hängt von dem gewünschten Sicherheitsgrad ab. Solange keine eigenen, lokalen Newsgroups betrieben werden, spricht nichts gegen eine direkte Benutzung des externen Newsserver. Ein weiterer Punkt, den es gut zu überlegen gilt, sind die benötigten Ressourcen, um die gewünschten News auch lokal vorhalten zu können. Es macht si-
Abbildung 7.11: NNTP-Serverkonfiguration in einer Firewallumgebung
182
7.1 Häufig benutzte Internetdienste
cher wenig Sinn, externe, öffentliche News auf dem externen und dem internen Newsserver gleichzeitig vorzuhalten. Wenn auf dem externen Newsserver noch andere Dienste betrieben werden, muß auf jeden Fall dafür gesorgt werden, daß die Usenet-News auf eigenen Partitionen gelagert werden, damit ein Überlaufen der Newsverzeichnisse nicht zum Ausfall anderer Dienste führt. Folgendes Entscheidungsraster kann bei den Überlegungen helfen: ❏ Keine lokalen Newsgroups
Nur den externen Newsserver betreiben und den Clients erlauben, per NNTP dort zuzugreifen. ❏ Zusätzlich lokale Newsgroups betreiben
Externe News wie ohne lokale Newsgroups auf dem externen Newsserver lesen, für die lokalen, internen News einen eigenen, internen Newsserver aufsetzen, der dann allerdings keinen Kontakt zur Außenwelt hat und ausschließlich für interne News (und andere interne Anwendungen) benutzt wird. Zur Paketfilterung: ❏ Konfiguration des Paketfilters am inneren Router für ausgehende NNTP-
Verbindungen: internes Netz Adresse Port lokales Netz
1023
Verbindungsaufbau
Grenznetz Adresse Port ext. NNTPServer
Protokoll
119
TCP
❏ Konfiguration des Paketfilters am äußeren Router für ausgehende NNTP-
Verbindungen: Grenznetz Adresse Port externer NNTP-Server
7.1.11
1023
Verbindungsaufbau
externes Netz Adresse Port NNTP-Server Provider
119
Protokoll TCP
Zeitsynchronisierung im Netzwerk: NTP
Das „Network Time Protocol“ (NTP) ist an sich eine faszinierende Sache: ein Rechner im Internet kann über tausende von Kilometern hinweg auf einen NTP-Server zugreifen, der von einer Atomuhr gesteuert wird, und seine eigene Zeit auf eine Genauigkeit von weniger als 100 Millisekunden kalibrieren – trotz realer Laufzeit der Signale im Internet. Der dazugehörige Daemon Xntpd besitzt eine Reihe nützlicher Eigenschaften. So kann er mehrere Zeitgeber gleichzeitig auswerten, unsinnige Informationen (z. B.
183
7 Internetdienste und Firewalls
falsche, stark abweichende Zeitsignale) verwerfen und die Rechnerzeit langsam ohne Sprünge an die eigentliche Normalzeit heranführen. Dazu bremst er die Systemuhr vorsichtig aus oder beschleunigt diese etwas. NTP basiert rein auf UDP und verwendet niemals TCP. ❏ Charakteristik von NTP:
internes Netz Adresse Port NTP-Client NTP-Client
Verbindungsaufbau
123 1023
externes Netz Adresse Port NTP-Server NTP-Server
123 123
Protokoll UDP UDP
Normalerweise verwendet der NTP-Client (der lokale Xntp-Daemon oder auch Clientprogramme wie ntpdate) als Source-Port 123, also denselben Port, den der Serverdienst auch benutzt. ntpdate verfügt über Kommandozeilenoptionen, mit denen auch unprivilegierte Ports als Sourceport verwendet werden können. Gefährdungspotential von NTP NTP dient ausschließlich der Zeitgebung, d. h., Gefährdungspotentiale ergeben sich aus möglichen Angriffen, die auf der Manipulation der Zeit beruhen. Das sind überwiegend Replay-Attacken, die eine gültige Verbindung aufzeichen und ein zweites Mal abspielen, um Sicherheitsmechanismen zu überlisten. Kerberos zum Beispiel beruht auf zeitabhängigen Tickets. Ein weiterer nicht unkritischer Punkt sind genaue Timestamps in den Logfiles. Gelingt es einem Angreifer, die Zeit zu manipulieren, sind die Zeitangaben in den Logfiles wertlos und erschweren Auswertungen ungemein. Insbesondere bei Meldungen an Intrusion Response Teams oder bei strafrechtlich relevanten Tatbeständen sind genaue Zeitmarken unerläßlich, da nur so Informationen über einen Einbruch von verschiedenen Stellen korrekt zusammengeführt werden können (z. B. die Logfiles der Provider über die Vergabe von dynamischen IP-Adressen mit den Logfiles von stattgefundenen Einbrüchen). NTP in Firewallumgebungen Innerhalb einer Firewallumgebung vertraut man ab besten auf einen eigenen Zeitgeber und verzichtet auf NTP-Daten, die man über das Internet beziehen könnte. In Europa gibt es Möglichkeiten, ohne NTP und Internet-Anbindung zu einer quasi-atomgenauen Zeit zu kommen: zum einen ist das der DCF77-Sender in Braunschweig, über den in Europa viele Uhren exakt gestellt werden, zum ande-
184
7.1 Häufig benutzte Internetdienste
ren gibt es die sehr viel weniger verbreitete Möglichkeit über GPS (Global Positioning System – dient zwar in erster Linie zur exakten Ortsbestimmung, liefert aber auch eine sehr genaue Zeit mit). Dazu benötigt man einen entsprechenden Empfänger und ein Stück Software, das die Zeit auswertet. Die ideale Kombination für „Selbstversorger“ ist eine DCF77-Uhr, die von Xntpd, dem NTP-Daemon, unterstützt wird. Aktuell ist Xntpd in der Version 4. Ab Version 4.0.99f sind auch Probleme gefixt, die vorher einfache RAW-DCF77-Empfänger zusammen mit den aktuellen Linux-Kernel gemacht hatten. Wer Spaß am basteln hat, bekommt einen RAW-DCF77Empfänger bereits für unter 50,- DM, allerdings ist eine serielle Schnittstelle Voraussetzung und etwas Experimentierfreude beim Suchen nach der optimalen Konfiguration notwendig. Wer nicht experimentieren möchte, bekommt einen DCF77-Empfänger mit stabilisiertem Empfang und eigener Hardware-Uhr incl. Linuxtreiber für ein paar hundert Mark. Die optimale Konfiguration ist ein DCF77-Empfänger für die DMZ, und ein weiterer für das interne Netzwerk. Beide Router sollten NTP vollständig blockieren. Wenn Sie darauf angewiesen sind, doch eine genaue Funkzeit aus dem Internet zu beziehen, achten Sie darauf, daß Sie mindestens drei NTP-Server benutzen, die Sie explizit konfigurieren. NTP-Broadcasts sind Tabu, ansonsten sollten Sie unter keinen Umständen NTP-Daten aus dem Internet in das interne Netzwerk lassen.
7.1.12
Finger
Der Service „Finger“ dient dazu, Login-Informationen über User preiszugeben, wie Loginzeiten, Shell des Users, von wo aus sich User eingeloggt haben, wer wann zum letzten Male Mail gelesen hat, Homedirectory des Users, Name usw. Kurz: für einen potentiellen Angreifer eine wahre Fundgrube an Informationen. Nicht zu unterschätzen dabei ist der Wert der Information für einen Hacker, der erfährt, von welchen anderen Rechnern im Netzwerk aus sich welche User auf dem Zielrechner einloggen können. Gelangt er nicht direkt zum Ziel, versucht er es auf Umwege über vielleicht weniger sicherere Rechner. Je mehr Rechner bei diesem Spiel beteiligt sind, desto größer ist die Wahrscheinlichkeit, daß der Angreifer irgendwann irgendwo Erfolg hat. In der Literatur findet man immer wieder die Hinweise, man könnte Finger durch eine sichere Variante ersetzen, oder auf Anfrage nur die Telefonnummer und E-Mail-Adresse des Administrators preisgeben. In einer vernetzten, heterogenene Welt hat Finger eigentlich überhaupt keinen Nutzen mehr. Empfehlung: komplett abschalten, d. h. alle Rechner so installieren, daß diese erst gar nicht auf Finger-Anfragen reagieren.
185
7 Internetdienste und Firewalls
Anfragen nach Finger von außen sollte man auf jeden Fall überwachen, aber die Überwachung ist Gegenstand von Kapitel 10.
7.1.13
RPC-Kandidaten: NFS, NIS/YP
NFS und NIS/YP sind eigentlich ganz verschiedene Dienste, verwenden jedoch denselben Basismechanismus RPC. Damit treten bei beiden Diensten auch dieselben – durch RPC betroffene – Anfälligkeiten auf. RPC verwendet ein sogenanntes Portmapping, um den möglichen Adreßraum für Anwendungen zu erweitern. RPC-Anwendungen haben eine 4 Byte lange RPC-Servicenummer, damit können 4.294.967.296 verschiedene Anwendungen eindeutig registriert werden, während auf der Ebene des Ports von TCP/UDP nur 2 Byte große Portnummern, also 65.536 Möglichkeiten existieren. RPC verfügt über einen sogenannten Portmapper, der einer Anwendung, die sich bei ihm registriert, dynamisch eine TCP- oder UDP-Portnummer (je nach Anwendung) zuordnet. Damit ist nicht vorhersagbar, welche Anwendung welche Portnummer benutzt. Für einen Paketfilter ist eine vernünftige Filterung erst gar nicht möglich. Hinzu kommt, daß gerade NFS und NIS das UDP-Protokoll verwenden. In der Regel werden Sie über den Firewall hinweg bis auf wenige Ausnahmen gar kein UDP zulassen. Die Unbestimmtheit der verwendeten Ports bei RPC-Diensten macht eine Freischaltung im Firewall zur Unmöglichkeit. Gefährdungspotential von NFS und NIS/YP NFS-Sicherheitsprobleme ❏ Host-Authentifikation über IP-Adressen
IP-Spoofing sehr einfach möglich. ❏ Benutzer-Authentifikation vom Client vorgegeben
Das grundlegende Übel bei NFS. Der Client selbst gibt vor, welcher Benutzer Zugriff hat. Auch wenn teilweise der Benutzer root auf den Benutzer nobody gemappt wird: root auf einem Rechner kann jeden Benutzer annehmen, die Identifizierung erfolgt über die User-ID. Wer weiß, wonach er sucht, kann unter der richtigen User-ID alle via NFS freigegebenen Daten lesen oder manipulieren. ❏ Zugriffsrechte des Clients werden nicht bei jedem Zugriff neu geprüft
Da für bestehende Verbindungen jeglicher Zugriffsschutz fehlt, können vorhandene Verbindungen ebenfalls leicht entführt werden (Man-in-the-middleAttacken).
186
7.1 Häufig benutzte Internetdienste
Sicherheitsprobleme bei NIS/YP ❏ Einziger Zugangscode: NIS-Domänenname
Um an alle Informationen zu gelangen, die im NIS abgelegt sind, wird nur der NIS-Domänenname benötigt. Oft läßt sich dieser leicht erraten oder anderweitig beschaffen. Alle Informationen, die NIS bietet, liegen dann offen vor. Selbst die verschlüsselten Passwörter, die auf Einzelsystemen inzwischen in der Regel in einem Shadow-System vorliegen und nur für einige wenige Programme lesbar sind, treten über NIS wieder offen zu tage. Passwort-Attacken sind bei schwachen Passwörtern mittels einer Unzahl von verfügbaren Programmen über Wörterbücher leider sehr oft erfolgreich. ❏ Unzureichender Schutz der NIS-Clients
NIS vertraut in der Grundkonfiguration jedem NIS-Server, der sich als solcher über Broadcasts meldet. Zwar läßt sich NIS so konfigurieren, daß es nur bestimmten Hosts vertraut, aber erstens ist das nicht immer eingestellt, und zweitens basiert die Server-Authentifikation ausschließlich auf einer IPAdresse. Einem Angreifer könnte es so gelingen, den eigentlichen NIS-Server über einen DoS-Angriff mundtot zu machen und den YP-Clients falsche NISInformationen unterzuschieben. An dieser Stelle soll nicht verschwiegen werden, daß es neuere Implementierungen auf der Basis von SecureRPC gibt; bei NIS heißt der Nachfolger NIS+. SecureRPC ist wesentlich schwieriger zu implementieren, hinzu kommt eine Reihe von Inkompatibilitätsproblemen zwischen verschiedenen Plattformen, nicht zuletzt aus lizenzrechtlichen Gründen herrührt. Auch für Linux existieren wenigstens NIS+-Client-Implementierungen; wer sich aber einmal näher mit NIS+ auseinandersetzt, wird schnell feststellen, daß sich nur für eine Firewallumgebung der Aufwand nicht lohnt und es einfacher ist, darauf zu verzichten. NFS, NIS/YP in Firewallumgebungen Wegen der unzähligen Sicherheitsprobleme sollte weder NFS noch NIS/YP in Firewallumgebungen eingesetzt werden. Da der Zielport bei NFS in der Regel Port 2049 ist und der Verbindungsaufbau über UDP oder TCP erfolgen kann, kann das u. U. mit erlaubten Diensten kollidieren. Wird aus irgendwelchen Gründen innerhalb des Firewalls doch NFS eingesetzt (wenn auch nicht explizit nach draußen freigeschaltet), sollte man zusätzlich eine Filterregel einfügen, die eingehende NFS-Verbindungen explizit blockt und protokolliert. Dazu mehr im Kapitel 8.
187
7 Internetdienste und Firewalls
7.1.14
X Window System
Das X Window System wurde entwickelt, um die graphische Ausgabe einer Anwendung von der eigentlichen Programmausführung zu trennen. Zwischen Ausgabe und Anwendung kann das Netzwerk liegen, so daß man auf einem Rechner eine Anwendung starten kann, die graphische Oberfläche des Programms aber von irgendeiner anderen Stelle im Netzwerk aus beobachten und bedienen kann. Im Prinzip eine geniale Erfindung. Die Ports der X-Server liegen zwischen 6000 (für den ersten X-Server, den Standard-Server also) und Port 6063 (den 64. X-Server, falls soviele Server laufen sollen). ❏ Charakteristik einer ausgehenden X-Window-Verbindung:
internes Netz Adresse Port Client
1023
Verbindungsaufbau
externes Netz Adresse Port X-Server
6000
Protokoll TCP
Sicherheitsproblematik bei X Unter dem Gesichtspunkt der Sicherheit ist X ein sehr problematisches System, weil es an sich nur wenige Sicherheitsmechanismen mitbringt. Das Ausgabegerät hat einen sogenannten X-Server, der die graphische Ausgabe übernimmt. Der Zugriff auf diesen X-Server ist – je nach Mechnismus – meist gar nicht oder nur schwach geschützt. Und es gibt keine Unterschiede zwischen verschiedenen Ausgaben/Fenstern. Entweder jemand hat Zugriff zum X-Server, dann kann er alles Mitlesen bis hin zu Passwort-Eingaben, oder man hat gar keinen Zugriff. Neuere Implementierungen verfügen in der Regel zwar über einen halbwegs passablen Autorisierungsmechanismus, das sogenannte Magic Cookie, eine 128 Bit lange Zufallszahl, diese wird aber in einem File .Xauthority im Homeverzeichnis des Users abgelegt, ist also auch nur so sicher, wie die Files und die Permissions in diesem Verzeichnis. X Window System in Firewallumgebungen Alles in allem sollte auf den Einsatz von X in Firewallumgebungen gänzlich verzichtet werden. Wer über den Firewall hinweg auf X angewiesen ist, benutzt besser die in der Secure Shell eingebaute Möglichkeit, das X-Protokoll zu tunneln. Dabei profitiert man gleichzeitig von allen Features der Secure Shell, insbesondere Verschlüsselung der Daten und Schutz vor Spoofing bzw. Hijacking der Verbindung.
188
7.2 Internetdienste starten
Dummerweise liegen die Serverports im unprivilegierten Bereich. In der Regel werden eingehende TCP-Pakete zu unprivilegierten Ports durchgelassen, insofern muß man unbedingt darauf achten, daß kein eingehender Verbindungsaufbau zu unprivilegierten Ports erlaubt ist, d. h. eingehende Pakete zu unprivilegierten Ports immer das ACK-Flag gesetzt haben. Um ganz sicher zu gehen, kann man eingehende TCP-Pakete mit gesetztem SYNFlag zu den Ports 6000-6063 ganz blockieren (und protokollieren). Dazu mehr im Kapitel 8.
7.2 Internetdienste starten Internetdienste werden über einen festgelegten TCP- oder UDP-Port angesprochen (außer ICMP-basierten Nachrichten). Wird ein solcher Port auf einem Host angesprochen, muß ein entsprechender Dienst aktiviert sein. Unter Unix gibt es hierfür zwei grundlegende Mechanismen:
7.2.1
Start als permanenter Daemon
Der Internetdienst läuft selbst als permanenter Daemon. Ein Daemon ist – kurz gesagt – ein Prozess, der mit einem Ohr an dem zugehörigen Port lauscht und darauf wartet, daß dort eine Anfrage eingeht. Erfolgt eine Anfrage, wird diese beantwortet. Ein Daemon beendet sich normalerweise nicht selbst, sondern muß angehalten werden (z. B. beim Herunterfahren des Rechners). Der Start eines Daemon erfolgt beim Booten über die jeweiligen Bootprozeduren. Unter Linux kommt der System-V-Init zum Einsatz. Beispiel für den Start des Mailer-Daemon postfix als Daemon unter Linux: ❏ Über den init-Prozeß wird nach einigen grundlegenden Boot-Vorbereitun-
gen beim Start in den Runlevel 2 das Verzeichnis /sbin/init.d/rc2.d nach Startskripten (beginnend mit S) gesucht und diese ausgeführt. ❏ Für postfix findet die Bootprozedur das Skript S20postfix. S20post-
fix ist ein Symlink auf /sbin/init.d/postfix. Das Skript wird mit dem Parameter start aufgerufen: /sbin/init.d/rc2.d/S20postfix start ❏ Verschiedene Linux-Distributionen (u. a. SuSE Linux) und kommerzielle Un-
ixe (z. B. Compaq True Unix) prüfen in dem aufgerufenen Skript erst ab, ob auch dazugehörige Variable gesetzt sind. Bei SuSE Linux muß in der Datei /etc/rc.config START_POSTFIX "yes" gesetzt sein. Andernfalls wird beim Booten das Skript nicht weiter ausgeführt und postfix nicht gestartet.
189
7 Internetdienste und Firewalls
❏ Gegebenenfalls werden in dem Skript noch weitere Dinge überprüft und
vorbereitet. Sind alle Aktionen erfolgreich beendet, wird der Daemon gestartet. ❏ Der Daemon läuft nun solange, bis er von außen beendet wird. Beim Her-
unterfahren des Systems geschieht das mit dem Aufruf: /sbin/init.d/rc2.d/K20postfix stop
Der Haupt-Daemon master von postfix startet wiederum selbst einige Prozesse, die ebenfalls permanent laufen. Andere als permanente Daemons gestartete Prozesse wie Samba (smbd) oder Apache starten ebenfalls weitere Prozesse, die dann vom Haupt-Daemon kontrolliert werden.
7.2.2
Start über den inetd-Daemon
Eine Reihe von Internetdiensten werden nur gelegentlich benötigt. Jeder laufende Daemon benötigt aber verschiedene Ressourcen wie Swap, Prozeßtabellen etc. In den 80er Jahren wurde ein Programm entwickelt, das anstelle vieler Daemons die benötigten Ports überwacht und Dienste nur dann startet, wenn diese auch tatsächlich benötigt (angefragt) werden: der Inet-Daemon inetd. Beispiel für den Start eines Dienstes über den inetd: ❏ Ein Dienst wird am Host angefragt. ❏ Der zugehörige Port wird vom inetd überwacht. Auf die Anfrage hin star-
tet der inetd den zugehörigen Internetdienst. ❏ Während der Ausführung hat die Kontrolle über die Verbindung der Inter-
netdienst. ❏ Nach dem Ende der Verbindung beendet sich auch der zugehörige Inter-
netdienst. ❏ Trifft eine weitere Anfrage (auch während einer bestehenden Verbindung,
etwa von einem anderen Rechner) ein, startet der inetd einen weiteren Prozeß des Internetdienstes. Der inetd entnimmt die Information, welche Ports er überwachen soll, aus einer Konfigurationsdatei: /etc/inetd.conf: # See "man 8 inetd" for more information. # <service_name> <sock_type> <proto> <user> <server_path> <args> # echo
Die Felder im einzelnen: ❏ service name: Der Name des Dienstes (/etc/services) ❏ socket type: stream bei TCP, dgram bei UDP. ❏ protocol type: TCP/UDP ❏ flags: wait bedeutet, der Server bearbeitet auch alle folgenden Anfra-
gen, bei nowait wird für jede weitere Anfrage/Verbindung ein eigener Prozeß gestartet. Beim verbindungslosen UDP wird daher meist wait benutzt, während beim verbindungsorientierten TCP eher nowait benutzt wird. Was wie verwendet wird, hängt letzten Endes von der Implementierung ab, man muß also die Dokumentation bemühen. ❏ user: Unter diesem User wird der Prozeß gestartet, wenn eine Verbin-
dungsanfrage kommt. Viele Dienste laufen unter root-Rechten und sind daher unter Sicherheitsaspekten kritisch. Fehler in den Programmen können dazu führen, daß sich ein Eindringling root-Rechte verschafft. ❏ server path: Das ausführbare Programm des Internetdienstes mit vol-
ler Pfad-Angabe. Wenn hier internal steht, wird kein eigenes Programm gestartet, sondern der Dienst direkt vom inetd ausgeführt (alle trivialen Dienste wie time, echo etc.). ❏ arguments: Das erste Argument ist immer der Name, unter dem das Pro-
gramm in den Prozeßtabellen erscheint, alle weiteren Argumente werden an das aufgerufene Programm übergeben. Möglicherweise ist die Anzahl der übergebbaren Argumente bzw. die Länge des Argumentstrings recht klein.
7.3 Internetdienste abschalten Internetdienste sollten abgeschaltet werden, wenn sie nicht unbedingt benötigt werden. Werden sie benötigt, dann sollte man sie auf jeden Fall kontrollieren (siehe 7.4).
7.3.1
Start über /sbin/init.d
Als Daemon gestartete Dienste lassen sich über mehrere Stufen hinweg dauerhaft abschalten:
191
7 Internetdienste und Firewalls
❏ Startvariable setzen: bei SuSE Linux und anderen Linux-Distributionen/-
Unixen kann in /etc/rc.config die zugehörige Variable so gesetzt werden, daß der Dienst nicht mehr automatisch beim Booten startet (meist: = no"). ❏ Symlink im entsprechenden Runlevel entfernen: Im Beispiel mit postfix
müssen folgende Symlinks entfernt werden: /sbin/init.d/rc2.d/S20postfix /sbin/init.d/rc2.d/K20postfix /sbin/init.d/rc3.d/S20postfix /sbin/init.d/rc3.d/K20postfix ❏ Entfernen der ausführbaren Programme: Zusätzlich zum Entfernen der Sym-
links kann man die ausführbaren Programme löschen/entfernen, um zu verhindern, daß jemand, der irgendwie doch Zugang zum Host erlangt hat, den unerwünschten Dienst startet und für weitergehende Einbruchsversuche benutzt. Dazu sollte man dann auch die Startscripts in /sbin/init.d löschen. ❏ Entfernen des installierten Paketes: falls der nicht benötigte Dienst in einem
eigenen Paket installiert ist, ist die sauberste Lösung, das komplette Paket vollständig zu entfernen (Beispiel: inn). Das geht nicht mit Diensten, die Teile eines zusammenfassenden Paketes sind. SuSE Linux: ➢ nkita und nkitb enthalten sehr viele verschiedene Dienste. file zeigt, zu welchem Paket ein File gehört ➢ rpm -qvf
➢ rpm -qvl
paketname noch enthalten sind)
7.3.2
zeigt an, welche Files in dem Paket sonst
Start über inetd
❏ Vergleichbar mit der Startvariable bei permanent laufenden Daemons ist die
Deaktivierung in der Konfiguration des inetd. Man kann die entsprechende Zeile auskommentieren oder löschen. Anschließend muß dem inetd mitgeteilt werden, daß sich die Konfiguration geändert hat: kill -HUP ‘cat /var/run/inetd.pid‘ ❏ Zusätzlich zur Deaktivierung können natürlich wie bei permanenten Dae-
mons die ausführbaren Programme gelöscht oder Pakete ganz entfernt werden. ❏ Anstatt den Dienst in /etc/inetd.conf zu deaktivieren, kann man mit
dem tcpwrapper auch eine Falle stellen und eine Alarmierung (etwa via E-Mail) auslösen. Für einen potentiellen Angreifer ist der Dienst zunächst scheinbar vorhanden, funktioniert aber nicht richtig (siehe 7.4).
192
7.4 Internetdienste kontrollieren
7.4 Internetdienste kontrollieren Prinzipiell gibt es zwei Verfahren, die benötigten Internetdienste zu kontrollieren: ❏ Auf der Ebene des Inet-Daemon: Hier geschieht die Kontrolle zwischen der
Dienstanfrage und dem Starten des dazugehörigen Prozesses. Sehr weit verbreitet ist der tcpwrapper, auch tcpd genannt, von Wietse Venema. Die Kontrollmöglichkeiten über den tcpd gehen weiter als viele Paketfilter. Diese Kontrollmöglichkeit ist allerdings auf den lokalen Host beschränkt. Eine vergleichbare Kontrollmöglichkeit bietet der xinetd, der gleich den gesamten inetd ersetzt. Die Konfigurationsmöglichkeiten sind in etwa wie die Kombination aus inetd/tcpd plus einige weitere Goodies (wie z. B. zeitbeschränkte Zugriffe). Das Konfigurationsfile ist allerdings inkompatibel mit dem inetd, deshalb ist der xinetd wohl auch nicht besonders verbreitet. ❏ Ein Firewall zwischen dem eigenen Host und dem Internet. Der Vorteil ist
sicher, daß ein Firewall das gesamte Netzwerk schützt, der Nachteil ist allerdings, daß die Konfiguration meist aufwendiger und die Protokollierung nicht ganz so einfach wie beim tcpwrapper ist. Wrapper oder Firewall sollten keine Entweder/Oder-Frage sein, sondern beide Technologien ergänzen sich hervorragend. Abgesehen von dem zusätzlichen Aufwand der Konfiguration von zwei Technologien, gewinnt man an Sicherheit, weil man nicht ausschließlich auf die Zuverlässigkeit einer einzigen Technologie angewiesen ist.
7.4.1
Der tcpwrapper
In der Konfigurationsdatei des inetd, /etc/inetd.conf, wird statt des auszuführenden Programms das Programm /usr/sbin/tcpd ausgeführt. Das Programm arbeitet die beiden Konfigurationsdateien /etc/hosts.allow und /etc/hosts.deny ab: ❏ /etc/hosts.allow: ist dort die gesuchte Kombination aus Host/Dienst
vorhanden, wird die Verbindung erlaubt. ❏ /etc/hosts.deny: ist dort die gesuchte Kombination aus Host/Dienst
vorhanden, ist die Verbindung verboten. ❏ In allen anderen Fällen ist die Verbindung erlaubt.
Die Syntax für die beiden Konfigurationsfiles ist: ❏ Liste_der_Daemons : Liste_der_Client_Hosts [: Shell-Kommando]
193
7 Internetdienste und Firewalls
Beispiel: ❏ /etc/inetd.conf: telnet stream tcp
nowait
root
/usr/sbin/tcpd
in.telnetd
Der ursprüngliche Aufruf des telnetd wird ersetzt durch den tcpd. ❏ /etc/hosts.allow: ALL: LOCAL EXCEPT gate.localdomain
Alle Dienste sind erlaubt, sofern diese von lokalen Rechnern kommen, mit Ausnahme von gate.localdomain. ❏ /etc/hosts.deny: ALL: ALL: (/some/where/safe_finger -l @%h | \ /usr/bin/mailx -s "ZUGRIFF via %d von %c" root) &
Da die Regel auf alle Kombinationen aus Diensten und Clients zutrifft, wird das Shell Kommando immer dann ausgeführt, wenn die nachgefragte Kombination nicht schon in /etc/hosts.allow vorhanden ist. In dem Beispiel wird mit einer Finger-Abfrage am Client nachgesehen, wer dort eingeloggt ist, und die Information an root weitergemailt. Der ursprünglich verlangte Dienst wird nicht ausgeführt, da die Bedingung Dienst/Client in /etc/deny zutrifft. Tips zur Konfiguration des tcpd: ❏ Der Dienst in den Konfigurationsfiles muß in der Schreibweise identisch
sein mit dem aufzurufenden Programm (Argument in /etc/inetd.conf, /etc/hosts.{allow, deny}). Eine Reihe von Daemons hat eine vom eigentlichen Namen etwas abweichende Schreibweise: z. B. heißt der telnetd oft in.telnetd. ❏ Immer alle nicht erlaubten Verbindungen in der Datei /etc/hosts.deny
mit ALL: ALL abfangen. ❏ Client-Angabe: auch wenn es die Schlüsselwörter LOCAL, KNOWN, PARANOID
gibt, ist es meist übersichtlicher, den Netzwerkbereich anzugeben, z. B. 192.168.3.0/255.255.255.0. ❏ Das Schlüsselwort EXCEPT erlaubt Ausnahmen: ALL EXCEPT in.fingerd: .... in.fingerd: ALL EXCEPT some.host
Die Manpages host_access(5), tcpd(8) und [GS96] enthalten eine ausführliche Beschreibung.
194
Kapitel 8 Firewalls bauen – einzelner Rechner Zunächst beschäftigen wir uns mit der Absicherung eines einzelnen Linux-Hosts. Dieser Abschnitt ist von zentraler Bedeutung, da jeder Host in exponierter Lage gefährdet ist, sei es der Standalone-Rechner zu Hause, der Linux-Router oder Bastion-Host im Firewall. Die hier aufgezeigten Grundregeln sollten auf alle Hosts angewendet werden, die im Kontakt mit dem Internet sind. Es macht durchaus Sinn, die Anwendung auch auf solche Rechner auszudehnen, die sich zwar hinter dem Firewall in einer gesicherten Zone befinden, die aber durch spezielle Firewall-Regeln in einer besonderen Lage sind: z. B. der interne Mailserver in einem lokalen Netzwerk, der als einziger Verbindung mit dem äußeren Mailserver im Grenznetz aufbauen darf. Der zweite Abschnitt ergänzt dann den vorangegangenen um Paketfilterregeln, die dazu dienen, einen einzelnen Rechner, der direkt mit dem Internet verbunden ist, gegen Angriffe aus dem Internet abzusichern bzw. solche Versuche zu protokollieren. Die weiteren Abschnitte bauen dann Stück für Stück aufeinander auf. Dabei werden die häufigsten Firewall-Kombinationen vorgestellt. Sicher gibt es auch noch weitere, darüber hinausgehende Variationen, aber das würde den Rahmen dieses Buches sprengen. Wer sich mit den hier vorgestellten Bausteinen vertraut gemacht hat, ist dann auch in der Lage, sich mit weiterführender Literatur tiefer in die Thematik einzuarbeiten und einen Firewall auf eigene, spezielle Belange hin zu konstruieren.
8.1 Absicherung eines einzelnen Rechners Für Interaktion mit Benutzern bietet ein Rechner verschiedene Netzwerkdienste an. Lokal oder über einige Netzwerkdienste kann sich ein Benutzer direkt in
195
8 Firewalls bauen – einzelner Rechner
das System einzuloggen. Und ein Benutzer, der bereits eingeloggt ist, kann über mehrere Mechanismen ggf. root-Rechte erlangen. Die Absicherung eines einzelnen Rechner besteht daher aus folgenden Komponenten: ❏ Entfernen aller unötigen Dienste ❏ Absichern der verbliebenen Dienste, ➢ etwa durch Konfigurationsparameter, ➢ zusätzliche Sicherheitsmechanismen wie tcpd, ➢ und natürlich umgehende Updates bei bekanntgeworden Sicherheits-
lücken. ❏ Restriktive Benutzerverwaltung
8.1.1
Benutzerverwaltung/Login
Unabhängig, ob Arbeitsplatzrechner, Bastion Host oder Router: bei allen Rechnern hängt die Sicherheit davon ab, ob ein Eindringling Zugang zum Rechner zunächst als normaler User und später dann als Superuser erhalten kann. Solange einem Angreifer nur Netzwerkdienste zur Verfügung stehen, kann er nur Schwachstellen dieser Dienste ausnutzen. Er wird für einen Einbruchsversuch viel Zeit und viele Versuche benötigen, die sich vermutlich ausreichend in den Logfiles niederschlagen und leichter entdeckt werden können. Ist ein potentieller Angreifer erst einmal im System, wird er versuchen, rootRechte zu erlangen. Die Aktivitäten eines „normalen“ Users werden nur an wenigen Stellen geloggt, und meistens erregt ein „normaler“ User auch keine Aufmerksamkeit, d. h., er kann sich fast frei bewegen und in Ruhe nach möglichen Schwachstellen suchen. Eine Reihe von Exploits (das sind Programme oder Verfahrensanleitungen, um bekannte Sicherheitslücken auszunutzen), basieren auf bereits eingeloggten Usern. Mit zunehmender Angriffsfläche ( Verwundbarkeit) des Hosts steigt aber auch die Wahrscheinlichkeit für einen potentiellen Angreifer, erfolgreich zu sein.
Dem Punkt Login ist also besondere Aufmerksamkeit zu widmen. Folgende Regeln sollten dabei berücksichtigt werden: ❏ Nur die Logins gewähren, die auch wirklich nötig sind. Bei einem Arbeitsplatz-
rechner muß ein Benutzer sich einloggen können. Auf einem Netzwerkserver benötigt ein User möglicherweise noch einen Eintrag in der Datei /etc/passwd, aber nicht unbedingt eine aktive Shell. Auf Routern sollte außer Administratoren niemand Zugriff haben. Für den Arbeitsplatzrechner heißt das: überflüssige User entfernen. Fertigen Sie sich eine Sicherheitskopie an, falls Sie später Pakete nachinstallieren, die möglicherweise einen der gerade entfernten User benötigen.
196
8.1 Absicherung eines einzelnen Rechners
❏ Sichere Passwörter verwenden. Die User, die noch Zugang auf dem System
haben, müssen Passwörter benutzen, die sich nicht leicht erraten lassen. Wenn Sie der einzige User auf dem System sind, wählen Sie ein kompliziertes Passwort mit Groß-/Kleinschreibung, Sonderzeichen und/oder Zahlen. Ansonsten läßt sich ein sicheres Passwort auch erzwingen, in dem man /bin/passwd durch ein anderes Programm ersetzt, das eine ähnliche Prüfung wie Passwort-Cracker aufsetzt passwd+, npasswd. ❏ PAM - Pluggable Authentication Modules. PAM wird von RedHat seit einiger
Zeit und von SuSE seit Version 6.2 eingesetzt. Man kann über diese Authentication Modules auch andere Authentifikationsmechanismen als die gewohnten Unix-Passwörter einsetzen. PAM bietet eine Fülle von Konfigurationsmöglichkeiten und ist deshalb unter Sicherheitsaspekten kritisch zu betrachten. Wo viel konfiguriert und justiert werden kann, kann auch viel falsch gemacht werden. PAM kann allerdings auch dazu benutzt werden, sichere Passwörter zu erzwingen. Mit dem Modul pam_cracklib kann die Überprüfung der Passwörter gegen ein Wörterbuch vorgenommen werden. ❏ Den Superuser-Account nur für administrative Zwecke nutzen. Auch wenn Sie
zu Hause auf Ihrem Rechner der Einzige sind, der diesen benutzt: verwenden Sie für normale Zwecke einen nichtprivilegierten User. Viele Viren zum Beispiel unter den Microsoft-Betriebssystemen führen Operationen durch, zu denen sie eigentlich besondere Zugriffsrechte benötigen sollten. Daß solche unter DOS/Windows fehlen, hat die hohe Verbreitung von Viren erst ermöglicht. ❏ Passwort-Shadowing benutzen. Aktuelle Linux-Distributionen wie die SuSE-
Distribution verwenden das Shadow Passwort System, bei dem die Datei /etc/passwd, die für jeden lesbar sein muß, keine Passwörter mehr enthält. Diese stehen dann verschlüsselt in einer Datei /etc/shadow, die keinesfalls für alle lesbar sein darf (korrekte Zugriffsrechte: user=root, group=shadow, perms=640) ❏ rlogin verbieten. Eine Möglichkeit, sich ohne Passwort am Loginprogramm
vorbei auf einem Rechner einzuloggen bietet rlogin. Dabei gibt die Datei $HOME/.rhosts an, welche User von denjenigen Rechnern, die dort eingetragen sind, sich ohne entsprechend gültiges Passwort von dort aus einloggen können. Entweder kontrollieren Sie streng diese Datei und achten darauf, daß diese immer schreibgeschützt ist, oder Sie entfernen den Dienst ganz von Ihrem Rechner (siehe nächster Abschnitt). ❏ hosts.equiv entfernen. Mit der Datei hosts.equiv wird allen Rechnern,
die dort eingetragen sind, eine Vertrauensstellung eingeräumt. Alle r-Kommandos von diesen Rechnern aus benötigen dann kein Passwort. Ein „+“ be-
197
8 Firewalls bauen – einzelner Rechner
deutet „alle Rechner“ und schaltet damit jegliche Authentifikation ab. Wegen des großen Sicherheitsrisikos gehört die Datei entfernt. ❏ Nicht entfernbare Logins abschalten. Wenn Sie sich nicht sicher sind, ob ein Ac-
count vielleicht doch gebraucht wird, können Sie diesen abschalten. Dazu trägt man am besten im Passwort-Feld von /etc/shadow statt dem Passwort den String ’*’ oder ’!’ (ohne die Hochkommata) ein. Die Shell ersetzt man durch ein ungefährliches Programm wie /bin/false. Falls /bin/false ein Shell-Skript ist, kann es durch folgenden C-Code ersetzt werden: main () {return (1)}
Zusätzlich kann man das Home-Verzeichnis des Accounts auf /dev/null setzen.
8.1.2
Unnötige Dienste abschalten
Dienste können als Standalone-Daemons über die Boot-Skripte oder über den Inet-Daemon gestartet werden (siehe dazu Abschnitt 7.2). Darüber hinaus besteht noch die Möglichkeit, Daemons direkt via /etc/inittab zu starten. Das wird zwar selten genutzt (einige kommerzielle Unixe starten z. B. von dort aus ihren X-Server), wenn aber mal die Herkunft eines Dienstes nicht nachvollziehbar ist, sollte man durchaus dort auch mal nachsehen. Man kann ja nie wissen ... inetd Häufig findet man über den Inet-Daemon folgende Dienste konfiguriert: ftp stream tcp nowait root telnet stream tcp nowait root
/usr/sbin/tcpd wu.ftpd -a /usr/sbin/tcpd in.telnetd
Alle diese Einträge stellen Netzwerkdienste zu Verfügung, um von außen auf den lokalen Rechner zuzugreifen. Man kann sie prinzipiell alle abschalten.
198
8.1 Absicherung eines einzelnen Rechners
Leere Unix/etc/inetd.conf-Datei Müssen in /etc/inetd.conf überhaupt Einträge enthalten sein? Bei normalen Internet-Accounts ist das so gut wie nie der Fall. Der Rechner holt sich seine E-Mails in der Regel via POP3 (IMAP), sendet E-Mails via SMTP, ansonsten greift man via Webbrowser auf verschiedene Internetdienste zu. Die eigene Webseite liegt auf einem Server beim Provider, der die benötigten Serverdienste für andere zur Verfügung stellt. In diesen Szenarios kommen lokal nur Clients zum Einsatz, die auf dem eigenen Rechner keine Serverdienste benötigen. Gleiches gilt auch für reine Paketfilter in einem Firewall, die selbst keine Dienste anbieten. Auch bei Bastion-Hosts lohnt es sich, genauer hinzusehen: der Webserver oder Proxy läuft als Daemon, MTA’s wie sendmail oder postfix ebenfalls. Käme vielleicht noch ein Dienst zur Wartung des Hosts via Netzwerk in Frage: telnet ist anfällig für Hijacking-Attacken, also höchstens im lokalen Netzwerk einsetzbar, rlogin prinzipiell unsicher, bleibt als sichere Alternative nur ein Dienst wie ssh – und dieser Dienst wird als Daemon gestartet. Es gibt also sehr viele Fälle, in denen die Datei /etc/inetd.conf leer bleiben kann. Bleibt aber die Konfigurationsdatei des Inet-Daemons leer, ist es noch besser, den Inet-Daemon erst gar nicht zu starten. Permanente Daemons Über den init-Daemon (Konfigurationsdatei: /etc/inittab) werden alle permanenten Dienste über die rc-Startup-Skripte gestartet. Man hat mehrere Möglichkeiten, deren Start zu verhindern: ❏ Dienste, die einzeln installierbar sind, nicht installieren, wenn diese nicht
benötigt werden. Beispiele: Samba, Hylafax, SNMP. ❏ Verschiedene Dienste lassen sich in /etc/rc.config über eine Start-Va-
riable konfigurieren. Gerade bei den Netzwerk-Grundpaketen sind nicht alle Dienste einzeln deinstallierbar. Bei SuSE Linux kann man mit fgrep START_ /etc/rc.config
eine Liste der konfigurierbaren Dienste erhalten. Vorteil dabei ist, daß man ohne große Installationsarbeiten den Start von Diensten konfigurieren kann. Nachteilig ist, daß die Startskripte natürlich fehlerfrei die gesetzten Variablen auswerten können müssen. ❏ Die sichere Variante: Bei Diensten, die sich nicht einzeln deinstallieren las-
sen (etwa NFS und der Portmapper sind im Netzwerkgrundpaket enthalten), kann man die rc-Startup-Skripte in /sbin/init.d entfernen, dazu in den Unterverzeichnissen /sbin/init.d/rc?.d die symbolischen Links.
199
8 Firewalls bauen – einzelner Rechner
Darüber hinaus kann man die dazu gehörigen Binaries löschen. Durch die rpm-Pakete läßt sich der Ausgangszustand jederzeit wieder restaurieren: man re-installiert das Paket einfach (Achtung: ggf. Konfigurationsdateien sichern). Tabelle 8.1: rc-Startup-Skripte aus /sbin/init.d
rc-Skript
Bemerkung
at apache boot.setup cron dhcp firewall i4l_hardware i4l inetd inn kbd kerneld lpd named network nfs nfsserver nscd postfix random route routed rwhod scanlogd serial smb snmpd sshd syslog xntpd ypserv ypclient
abschalten Webserver: falls lokal eingesetzt notwendig notwendig nicht nötig SuSE-Firewall-Mechanismus bei ISDN-Nutzung ISDN-Nutzung notwendig News System: ggf. abschalten Keyboard-Treiber: notwendig notwendig Drucksystem, notwendig, falls Drucker vorhanden nur, wenn Nameserver aufgesetzt werden soll notwendig Nur bei NFS-Nutzung nur, wenn nfs im Einsatz, sonst abschalten Cache-Daemon für Name Service, kann abgeschaltet werden Mailsystem (sendmail-Ersatz): notwendig nützlich notwendig, setzt statische Routen nicht notwendig, abschalten abschalten nützlich zur Erkennung von einigen Portscans nur, falls Modem initialisiert werden soll Samba: abschalten nicht notwendig, abschalten nur erforderlich, wenn via sshd von außen eingeloggt wird System-Logging, sollte vorhanden sein auf Standalone-Rechnern selten im Einsatz nur, wenn yp im Einsatz, sonst abschalten nur, wenn yp im Einsatz, sonst abschalten
200
8.1 Absicherung eines einzelnen Rechners
Einige Startup-Skripte aus einer Beispielinstallation (Verzeichnis /sbin/init.d) zeigt Tabelle 8.1. Die Auflistung erhebt keinen Anspruch auf Vollständigkeit. Je nach Konfiguration sind abweichend davon andere Dienste im Einsatz. Welches Skript zu welchem Paket gehört, kann man sehr einfach mit folgendem Befehl herausfinden: rpm -qvf /sbin/init.d/<script>
8.1.3
Sichere Konfiguration verbleibender Dienste
In diesem Abschnitt geht es vorwiegend um die Absicherung von passiven Hosts (Hosts ohne Serverdienste wie Single-Host, Router/Paketfilter, etc.). Bei aktiven Hosts (z. B. Bastion Host im DMZ mit Serverdiensten) ist die Konfiguration den Erfordernissen anzupassen. Ein äußerer Mailserver im DMZ muß natürlich E-Mails via SMTP auch annehmen können – was man bei einem reinen Paketfilter besser ganz unterbindet. E-Mail Unter Linux/Unix nutzt man meist die Möglichkeit, E-Mails jederzeit an einen lokalen MTA zu versenden, der die E-Mails dann beim nächsten Verbindungsaufbau an den Provider weitergibt. Ohne lokalen MTA wäre wie unter Windows ein E-Mail-Client mit offline-Funktionalität erforderlich, der zu sendende E-Mails solange in einer Warteschlange hält, bis er zum Versand der E-Mails – dann direkt an den Provider – aufgefordert wird. Die Frage beim E-Mail-Versand ist, ob sich das Senden von E-Mails via SMTP trennen läßt vom E-Mail-Empfang im Netzwerk. Wird lokal E-Mail versandt, kann der smtp-Port nur abgeschaltet werden, wenn der Versand lokal ohne den smtp-Port funktioniert. ❏ postfix
bedient sich hier eines Maildrop-Verzeichnisses, d. h. beim Versand von E-Mails lokal wird zwar von Mailclients wie mutt, elm, pine, etc. ein sendmail-Befehl aufgerufen, die E-Mails werden aber dann direkt in ein physikalisches Verzeichnis geschrieben, von wo aus postfix die E-Mails weiterverarbeitet. In der Datei /etc/postfix/master.cf kann man die Zeile smtp
inet
n
-
y
-
-
smtpd
einfach auskommentieren und postfix neu starten. ❏ smail verwendet auch zum lokalen Versand den smtp-Port, d. h. smail-
Anwender haben hier das Nachsehen und müssen dafür sorgen, daß der smtp-Port über Firewall-Regeln nicht von außen erreichbar ist.
201
8 Firewalls bauen – einzelner Rechner
8.1.4
Kontrolle über offene Ports
Welche Dienste bleiben den nun übrig? Waren die Bemühungen nun erfolgreich, oder hat man irgend etwas übersehen? Unabhängig vom Startmechanismus können Dienste nur über Netzwerk angesprochen werden, wenn auf einem Port ein entsprechendes Programm auf Anfragen wartet. Kontrollieren kann man offene Ports mit netstat -a
Beispiel: Proto Recv-Q Send-Q Local Address Foreign Address State tcp 1 0 149.225.46.168:1303 130.230.4.50:www-http CLOSE_WAIT tcp
0
0 149.225.46.168:1291 128.10.252.72:ftp
tcp
0
0 *:389
*:*
ESTABLISHED LISTEN
tcp
0
0 *:snpp
*:*
LISTEN
tcp
0
0 *:4557
*:*
LISTEN
tcp
0
0 *:hylafax
*:*
LISTEN
tcp
0
0 *:6000
*:*
LISTEN
tcp
0
0 *:1024
*:*
LISTEN
tcp
0
0 *:auth
*:*
LISTEN
tcp
0
0 *:ssh
*:*
LISTEN
tcp
0
0 *:smtp
*:*
LISTEN
tcp
0
0 *:printer
*:*
LISTEN
tcp
0
0 *:nntp
*:*
LISTEN
tcp
0
0 *:rsync
*:*
LISTEN
tcp tcp
0 0
0 *:netbios-ssn 0 *:pop3
*:* *:*
LISTEN LISTEN
In dem Beispiel warten alle mit LISTEN gekennzeichneten Ports auf beliebige, eingehende Verbindungen. Port 6000 und 1024 stammen von kdm, Port 4557 und hylafax von Hylafax, Port auth wird vom ident-Daemon benutzt (ein nützlicher Dienst). Für einen einzelnen Rechner in jedem Falle zu hinterfragen sind folgende Dienste: snpp, rsync (soll wirklich ein rsync-Daemon für anonyme Zugriffe laufen?), pop3 (wird lokal die E-Mail wirklich via POP3 abgeholt? Viele einfache Unix-Clients greifen direkt auf /var/spool/mail zu), netbios-* (wer greift von Windows aus auf den lokalen Rechner zu?), 389 (ldap-Server, wird dieser überhaupt benutzt?). Wie findet man nun die zum offenen Port gehörigen Prozesse heraus? netstat bietet eine Möglichkeit an (hat aber Probleme mit Ports, auf die gleich mehrere Prozesse zugreifen): netstat -ap
Eine Alternative bietet das Programm fuser, das eine ganz hübsche Übersicht ermöglicht. Allerdings muß man zuerst die offenen Ports heraussuchen. Außer-
202
8.2 Einzelner Rechner mit direktem Internetzugang
dem ist für Ports explizit der Namespace (file, tcp, udp) anzugeben, da per Defaulteinstellung eine Datei-Angabe erwartet wird. Die Beispielfrage „Welche Prozesse benutzen Port 1024 und Port 6000 via tcp?“: fuser -n tcp -u -v 1024 6000
liefert: 1024/tcp
6000/tcp
USER root root root root
PID 567 581 832 572
ACCESS f.... f.... f.... f....
COMMAND kdm kdm xconsole X
Details zu Optionen und ACCESS-Flags siehe man fuser.
8.2 Einzelner Rechner mit direktem Internetzugang Ein Firewall für den Hausgebrauch? Während der Arbeiten an diesem Buch habe ich natürlich auch verschiedenste Firewall-Konfigurationen getestet und bin damit ins Internet hinein. Trotz dynamisch vergebener IP-Adresse durch meinen Provider dauerte es manchmal keine zwei Minuten, bis der erste „Angriff“ erfolgte, meist ein Scan nach irgendwelchen „Backdoors“ wie SubSeven, Netbus oder BackOrifice. Viele dieser Backdoors sind Windows-Programme, d. h. Linux ist prinzipiell immun dagegen. Und bei geeigneter Paketfilterung sind solche Scans harmlos. Trotzdem ist es erschreckend, das anscheinend automatisiert gescannt wird, und auch Hosts aufgespürt werden, die nur kurze Zeit online sind. Auch wenn dies ein Linux-Buch ist – man stelle sich einen Windows-Benutzer vor: mal ein Spiel wie Moorhuhn von einem Freund ausprobiert. Das Spiel stammte leider aus einer unsicheren Quelle, installiert beim ersten Aufruf eine Backdoor (z. B. SubSeven), beim Surfen im Internet kommt nach kurzer Zeit ein Connect von draußen, und der Eindringling ist in der Lage, den gesamten Rechner zu manipulieren, Passwörter mitzulauschen oder Zugangsdaten zum Provider und Online-Banking-Daten auszuhorchen. Ein leider nur zu realistisches Szenario. Für Linux und einige andere Unix-Systeme (Solaris z. B.) existieren sogenannte Rootkits, die wichtige Systemprogramme ersetzen und eben auch sogenannte „Backdoors“ offen halten. Deshalb heißt es auch als Linux-Benutzer die Augen offen zu halten und immer ein Augenmerk auf die Sicherheit der eingesetzten Rechner zu werfen. Doch wieder zum Firewall für den Hausgebrauch. Ein „Firewall“ im Sinne dieses Buches ist ein Konzept, und als solches kann der „Firewall“ auch Bestandteil ein und desselben Rechners sein – dann natürlich nicht mit der gleichen Sicherheits-
203
8 Firewalls bauen – einzelner Rechner
Abbildung 8.1: Rechner mit direktem Internet-Zugang
stufe wie ein aufwendiger Firewall, der sich physikalisch aus mehreren Computern oder Spezialhardware zusammensetzt. Aber das ist für den Hausgebrauch auch gar nicht notwendig. Ein in den Arbeitsplatzrechner integrierter Firewall basiert auf Zugangsbeschränkungen, abgeschalteten Diensten und Paketfilterung. Proxies machen wenig Sinn, da deren Aufgabe in erster Linie die restriktive Kontrolle eines Dienstes ist. Als Endanwender bietet man erst gar keine direkten Dienste an; und auf die Idee, sich selbst beim Zugriff in das Internet inhaltlich einzuschränken, kommt wohl so schnell auch niemand. In unserem Beispiel (Abbildung 8.1) ist der Rechner mit dem Internet über eine ISDN-Wähleitung verknüpft. In der Regel ist damit auch eine dynamische IPAdresse verbunden, und die macht Firewalling in einigen Punkten komplizierter als eine feste Verbindung zum Internet mit fester IP-Adresse.
8.2.1
Überflüssige Dienste abschalten
Wir gehen davon aus, daß der Standalone-Host ausschließlich als Client, etwa zum Surfen im Internet eingesetzt wird, also keine eigenen Dienste anbietet. Wie in den vorangegangenen Abschnitten aufgezeigt, kann die Konfigurationsdatei des Inet-Daemons /etc/inetd.conf leer bleiben. Dann sollte man den Inet-Daemon erst gar nicht starten. Verbleiben doch einige Dienste in der Konfigurationsdatei, sollte man nach Änderungen an /etc/inetd.conf den InetDaemon auf jeden Fall anweisen, seine Konfigurationsdatei neu einzulesen: /sbin/init.d/inetd reload
führt ein kill -HUP durch. Permanente Daemons werden über die Datei /etc/rc.config gesteuert. Der Befehl
204
8.2 Einzelner Rechner mit direktem Internetzugang
fgrep START_ /etc/rc.config | grep yes
zeigt an, welche Dienste bei einem Systemstart automatisch mitgestartet werden. Die Ausgabe könnte so oder anders aussehen, nachfolgend hier nur ein kommentiertes Beispiel als Anhaltspunkt: START_LOOPBACK="yes" START_INETD="yes" START_KERNELD="yes" START_PORTMAP="yes" START_HTTPD="yes" START_AT="yes" START_LPD="yes" START_SSHD="yes" START_ISAPNP="yes" START_SCANLOGD="yes" START_NSCD="yes" START_POSTFIX="yes" START_IDENTD="yes"
Dazu einige Bemerkungen: ❏ START_INETD:
sollte auf „no“ gesetzt werden, wenn /etc/inetd.conf keine Einträge enthält. ❏ START_PORTMAP:
wird der Portmapper wirklich benötigt? Bei einem Standalone-Host kommt normalerweise weder YP noch NFS zum Einsatz. Auf „no“ setzen. ❏ START_HTTPD:
wer lokal nur einige Manuals liest, kann diese oft auch direkt über Dateizugriffe lesen. ❏ START_AT:
wird selten gebraucht, abschalten. ❏ START_LPD:
der typische Standalone-Rechner zu Hause hat fast immer einen lokalen Drucker. Wer den klassischen lpd benutzt (unter SuSE: lprold), sollte dafür sorgen, daß Zugriffe von außen über den Paketfilter geblockt werden. ❏ START_SSHD:
ssh ist normalerweise eine gute Sache, aber wird auf dem Standalone-Rechner wirklich ein Login von extern benötigt? Normalerweise ist der Dienst für den Hausgebrauch nicht notwendig, da der Endnutzer sowieso direkt vor der Konsole sitzt.
205
8 Firewalls bauen – einzelner Rechner
❏ START_ISAPNP:
Ein typisches Beispiel dafür, das nicht alles, was mit START_ beginnt, auch etwas mit einem Daemon zu tun hat. Im Zweifelsfalle am besten selbst nachsehen: fgrep START_XXX /sbin/init.d/*
liefert das Skript, das die Variable auswertet. ❏ START_SCANLOGD:
Auf jeden Fall aktivieren. Das Programm scanlogd dient zur Erkennung von Scans, die mehrere Ports in kurzer Zeit nacheinander scannen. Zwar erkennt scanlogd nicht alle Arten von Scans, aber umgekehrt ist ein von scanlogd erkannter Scan immer ein Alarmzeichen. ❏ START_NSCD:
Der Nameservice-Caching-Daemon speichert Dinge zwischen, die typischerweise auch über YP/NIS zur Verfügung gestellt werden, wie z. B. passwd, group und hosts (konfigurierbar via /etc/nsswitch.conf). Wird auf einem Standalone-Host nicht benötigt. ❏ START_POSTFIX:
Mail Transport Agent, unter Sicherheitsaspekten immer eine gute Wahl. ❏ START_IDENTD:
abschalten. Die Filterregeln weiter unten sehen vor, keine ident-Anfragen durchzulassen, also kann man auch gleich auf den Dienst verzichten. Soweit der kleine Auszug. Im Einzelfalle kommt man aber nicht umhin, sich die rc.config-Mechanismen genau anzusehen. Je nach Distribution gibt es außer /etc/rc.config auch noch ein /etc/rc.config.d-Verzeichnis mit weiteren Konfigurationsdateien. Außerdem muß nicht notwendigerweise die Suche nach START_ ausreichend sein. Bei cron z. B. wird der Start über den Eintrag CRON yes gestartet.
Nach dem großen Aufräumen, am besten nach einem Neustart, kann man sich noch einmal die Prozessliste und die Liste offener Ports ansehen. Mit ps auxww
kann man sich die Prozessliste ansehen und erhält in der Regel auch einen vollständigen Pfad der einzelnen Programme. Hat man den Pfad auf diese Art oder anderweitig herausgefunden, kann man mit rpm -qvf
herausfinden, zu welchem Paket das Programm gehört, und mit rpm -qvl <paket>
206
8.2 Einzelner Rechner mit direktem Internetzugang
läßt sich auch herausfinden, welches Startup-Skript in /sbin/init.d das Programm startet. In dem Skript läßt sich dann feststellen, wie der Dienst gestartet wird. Verbleibende Dienste konfigurieren Sind alle überflüssigen Dienste abgeschaltet, sollten die übrigen so konfiguriert werden, daß sie nur die notwendigen Dinge tun. Wie weiter oben beschrieben, trifft das beim Standalone-Host in erster Linie auf den MTA zu. Meist wird die E-Mail über POP3 geholt, d. h. man kann ganz auf den Mailempfang via SMTP verzichten. Sendet der Provider trotzdem die E-Mails via SMTP, kommen diese normalerweise von einem einzigen Host, und man sollte SMTP-Emfang auf den Mailhub des Providers beschränken.
8.2.2
Paketfilterung mit fester IP-Adresse
Nachdem der Rechner nun keine unnötigen Angriffsflächen mehr bieten sollte, folgt der eigentliche Kern des Firewalling: die Filterung von Paketen. Im folgenden werden einzelne, aber wesentliche Fragmente eines möglichen Initialisierungskriptes aufgezeigt und ausführlicher besprochen. Danach folgt dann ein vollständiges Skript. In diesem Abschnitt wird davon ausgegangen, daß eine feste IP-Adresse zur Verfügung steht. Auch wenn das für viele Homesurfer unrealistisch erscheint: das Grundprinzip läßt sich daran gut erklären, und die Variante mit dynamischer IP-Adresse stellt dann nur eine Erweiterung dar. Wir gehen anschließend noch darauf ein. Vorarbeiten: Variable setzen Zunächst werden einige Variable gesetzt, die das Skript handlicher machen. Man sollte prinzipell alle sich wiederholenden Konstanten, insbesondere IP-Adressen und Portnummern als Variable setzen. Ein einziger Zahlenverdreher in einem komplexeren Skript kann in stunden- bzw. tagelange, frustrierende Fehlersuche ausarten. Als Shell verwendet der Autor die tcsh, wer aber lieber eine andere Shell benutzt, wird auch kein größeren Schwierigkeiten haben, dies umzusetzen. In den Beispielen wird ❏ für surfer als IP-Adresse 192.0.81.17 benutzt, ❏ die IP-Adresse des Nameservers ist 192.0.84.1.
207
8 Firewalls bauen – einzelner Rechner
Die Adreßbereiche sind fiktiv, d. h. zur Zeit nicht vergeben. Die Daten sind in jedem Falle durch reale, vom Provider vorgegebene Adressen zu ersetzen. Der Zugang erfolgt über eine ISDN-Wählleitung mittels syncppp (siehe Abbildung 8.1), das dazugehörige Interface mit Internetzugang ist ippp0. Die Konfiguration des ISDN-Zuganges ist nicht Gegenstand dieses Buches, dazu sei auf die entsprechende Dokumentation der Linux-Distributoren und einschlägige FAQ’s verwiesen (siehe auch E.3.2) und [Kri00]. #!/bin/tcsh # Firewall-Skript für
surfer
# ---------------------------------------------------------# PART I: Variablen set IPTABLES = /usr/sbin/iptables # ---------------------------------------------------------# special ports set p_high
= 1024:65535
# unprivileged ports
set p_ssh
= 1000:1023
# common ssh source ports
# ---------------------------------------------------------# interfaces set IF
= ippp0
# ---------------------------------------------------------# ip hosts set surfer
= 192.0.81.17
set ns
= 192.0.84.1
# example # example
set mail
= 192.0.84.3
# example
set FRIEND
= 192.0.84.0/255.255.255.0 # example
Für die Filterregeln werden wir einige Ports bzw. Port-Bereiche immer wieder benötigen. Die meisten Ports sind bereits in /etc/services definiert und können auch in der dort benutzten Schreibweise für iptables verwendet werden.
208
8.2 Einzelner Rechner mit direktem Internetzugang
Kernel-Runtime-Parameter Der Linux-Kernel enthält einige Features, die zur Laufzeit konfigurierbar sind. Einige davon müssen allerdings mit einkompiliert werden (z. B. tcp_syncookies, sie dazu auch Abschnitt 5). # ---------------------------------------------------------# PART II: Grundkonfiguration: absichern # ---------------------------------------------------------# dynamische Kernelparameter setzen echo "0" > /proc/sys/net/ipv4/ip_forward echo "1" > /proc/sys/net/ipv4/tcp_syncookies echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses echo "5" > /proc/sys/net/ipv4/icmp_destunreach_rate echo "5" > /proc/sys/net/ipv4/icmp_echoreply_rate echo "5" > /proc/sys/net/ipv4/icmp_paramprob_rate echo "10" > /proc/sys/net/ipv4/icmp_timeexceed_rate echo "1" > /proc/sys/net/ipv4/conf/$IF/rp_filter echo "0" > /proc/sys/net/ipv4/conf/$IF/accept_redirects echo "0" > /proc/sys/net/ipv4/conf/$IF/accept_source_route echo "0" > /proc/sys/net/ipv4/conf/$IF/bootp_relay echo "1" > /proc/sys/net/ipv4/conf/$IF/log_martians
Die einzelnen Runtime-Parameter sind im Anhang B näher beschrieben. Außerdem findet sich eine Dokumentation im Kernel-Source-Baum in folgender Datei: /usr/src/linux/Documentation/networking/ip-sysctl.txt. Bis auf wenige Ausnahmen kann man die Runtime-Parameter auf jedem Host in einem lokalen Netz verwenden, um grobem Unfug vorzubeugen. Ausnahmen dabei sind: ❏ ip_forward:
normale Rechner im lokalen Netzwerk routen nicht. ❏ tcp_syncookies:
ob das lokale Netzwerk halbwegs sicher ist, oder dort auch Hacker zu erwarten sind, muß im Einzelfall entschieden werden. In sicheren Netzwerken muß tcp_syncookies nicht unbedingt gesetzt werden. ❏ conf/$IF/rp_filter:
dient zur Verhinderung von Spoofing. Macht bei einem Rechner in einem lokalen Netzwerk mit nur einem Netzwerkinterface wenig Sinn.
209
8 Firewalls bauen – einzelner Rechner
Ansonsten ist noch anzumerken, daß ein Teil der Parameter Interface-abhängig gesetzt wird (conf/ interface ), dazu gibt es auch noch die Options-Verzeichnisse conf/all und conf/default. Änderungen in conf/all gelten für alle Interfaces, Änderungen in dem Interface-abhängigen Verzeichnis nur für das jeweilige Interface. Das Verzeichnis conf/default legt die Defaultwerte fest. Die Einträge im Default-Verzeichnis sollte man nicht ändern.
Achtung: wird ein Interface ganz gelöscht und neu gestartet, gehen die Interfaceabhängigen Einstellungen verloren (zum Beispiel bei ippp0: isdnctrl delif ippp0). Ein Herunterfahren dagegen ist unschädlich (ifconfig ippp0 down). Default-Policy Die Pakete durchlaufen die jeweilige Filterkette von oben nach unten. Findet sich eine Regel, die auf das durchlaufende Paket zutrifft, dann wird die Filterkette an dieser Stelle verlassen (bis auf rein protokollierende Regeln). Es kann aber auch passieren, daß sich keine Filterregel findet, die auf das Paket zutrifft. Dann entscheidet die „Default Policy“. In einer Welt voller Trojaner, Backdoors und automatischer Security-Scanner kann es eigentlich nur ein Prinzip geben: alles, was nicht explizit erlaubt ist, ist per Default verboten: # ---------------------------------------------------------# Default Policy und flush $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT DROP $IPTABLES -F
# flush aller chains
Ergänzend löschen wir alle vorhandenen Regeln. Das stellt sicher, daß nur die Regeln, die wir aufgestellt haben, auch aktiv sind. Darüber hinaus kann man das Skript vor allem beim Test mehrfach starten, ohne daß es zu unerwünschten Nebeneffekten kommt. Spoof Protection Der rp_filter-Mechanismus kann nur aufgrund der vorhandenen Netzwerkinterfaces abschätzen, ob ein Paket gespooft ist oder nicht. Es gibt darüber hinaus zwar noch einen höheren Level für rp_filter, der ist aber nur Experten zu empfehlen, die genau wissen, was sie tun (Dokumentation: /usr/src/linux/Documentation/networking/ip-sysctl.txt).
210
8.2 Einzelner Rechner mit direktem Internetzugang
Auf Paketfilter-Ebene kann man ebenfalls Filterregeln zur Abwehr von Spoofingattacken setzen. In unserem Fall eines Standalone-Hosts kann man nur von gespooften Paketen ausgehen, wenn eingehende Pakete die Source-IP-Adresse des eigenen Interface besitzen. Zwar wird genau dieser Fall auch vom rp_filterMechanismus abgefangen, aber aus didaktischen Gründen (bei den nachfolgenden Firewall-Konstellationen sind zusätzliche Spoofing-Filterregeln auf jeden Fall nützlich) nehmen wir bereits jetzt eine Spoofing-Filterregel mit auf. # ---------------------------------------------------------# spoof protection $IPTABLES -A INPUT -s $surfer -i $IF -j DROP
Eine Anti-Spoofing-Filterregel hat den Vorteil, daß sie gezielt protokollieren kann, d. h. spätere Auswertemechanismen wie logsurfer darauf aufbauen und Warnungen generieren können. Lokale Prozesse wieder freischalten Die Paketfilterung über iptables schlägt auch bei lokalen Prozessen zu (siehe Abbildung 5.1). Die Default Policy oben verhindert im Augenblick, daß ein lokaler Prozess zu einem zweiten lokalen Prozess eine Verbindung aufbauen kann. Deshalb müssen Filterregeln gesetzt werden, die lokalen Prozessen wieder die Kommunikation erlauben. Lokale Prozesse kommunizieren ausschließlich über das Interface lo. # ---------------------------------------------------------# lokale Prozesse $IPTABLES -A OUTPUT -o lo -j ACCEPT $IPTABLES -A INPUT
-i lo -j ACCEPT
Logging: userdefinierte Regelkette Sehr oft möchte man Pakete protokollieren, die abgelehnt werden. Gegenüber früheren Kernelversionen geht das mit Kernel 2.4 nicht mehr durch ein einfaches Flag beim Administrationstool (iptables). In Abschnitt 5.2.4 wurde bereits aufgezeigt, wie man über eine userdefinierte Regelkette abgelehnte Pakete protokollieren kann. # ---------------------------------------------------------# PART III: endgültige Filterregeln # ----------------------------------------------------------
211
8 Firewalls bauen – einzelner Rechner
# ---------------------------------------------------------# DROP & LOG Chain $IPTABLES -N my_drop $IPTABLES -A my_drop -p ICMP -j LOG --log-prefix "DROP-ICMP " $IPTABLES -A my_drop -p UDP
-j LOG --log-prefix "DROP-UDP "
$IPTABLES -A my_drop -p TCP
-j LOG --log-prefix "DROP-TCP "
$IPTABLES -A my_drop -j DROP
Wir machen von der Möglichkeit Gebrauch, unterschiedliche Prefixe für die LogEinträge anzugeben. Genaugenommen ist die Unterscheidung nach einzelnen Protokollen im Text überflüssig, da dieses gesondert protokolliert wird. Das Beispiel soll aber zeigen, daß man auch in einer Logging-Regelkette noch nach bestimmten, für das jeweilige Einsatzgebiet interessanten Kriterien differenziert protokollieren kann. Filterregeln für ICMP # ---------------------------------------------------------# ICMP # ping: 8 und 0, ausgehend $IPTABLES -A OUTPUT -p ICMP --icmp-type echo-request -j ACCEPT $IPTABLES -A INPUT
-p ICMP --icmp-type echo-reply -j ACCEPT
$IPTABLES -A INPUT
-p ICMP --icmp-type echo-request -j my_drop
Ausgehendes Ping wird erlaubt, eingehendes Ping verboten. Zur Erinnerung: echo-request ist das anfragende, echo-reply die darauf antwortende ICMPNachricht. # source quench (4) $IPTABLES -A OUTPUT -p ICMP --icmp-type source-quench -j ACCEPT $IPTABLES -A INPUT
-p ICMP --icmp-type source-quench -j my_drop
Source-Quench ist an sich nicht besonders kritisch, aber es könnte trotzdem jemand mal auf die Idee kommen, darüber einen DoS-Angriff durchzuführen. Da Source-Quench aber ein „Kann“ ist, kein „Muß“, und Router nach aktuellen RFC’s sowieso keine Source-Quench-Pakete versenden sollen, sperren wir eingehende Source-Quenches, ausgehende aber lassen wir zu.
212
8.2 Einzelner Rechner mit direktem Internetzugang
# time exceeded (11) $IPTABLES -A OUTPUT -p ICMP --icmp-type time-exceeded -j ACCEPT $IPTABLES -A INPUT
-p ICMP --icmp-type time-exceeded -j ACCEPT
# parameter problem (12) $IPTABLES -A OUTPUT -p ICMP --icmp-type parameter-problem -j ACCEPT $IPTABLES -A INPUT
-p ICMP --icmp-type parameter-problem -j ACCEPT
Beide unkritisch, aber sinnvoll. Deshalb freigeschaltet. # destination unreachable (3) $IPTABLES -A OUTPUT -p ICMP --icmp-type fragmentation-needed -j ACCEPT $IPTABLES -A OUTPUT -p ICMP --icmp-type port-unreachable -j ACCEPT $IPTABLES -A INPUT -p ICMP --icmp-type fragmentation-needed -j ACCEPT $IPTABLES -A INPUT -p ICMP --icmp-type destination-unreachable -j ACCEPT
ICMP-Messages vom Typ fragmentation needed sollten unbedingt durchgelassen werden. Wenn Fragmentierung erforderlich wird und diese Nachricht blockiert ist, kann es zu deutlichen Performance-Einbrüchen bei der Datenübertragung kommen. Ausgehende port unreachable-Nachrichten lassen wir an dieser Stelle entgegen den Ausführungen im Abschnitt 7.1.9 nach außen zu. Über die Filterregeln wird sichergestellt, das keine beliebigen Ports von außen über UDP ansprechbar sind. Weiter unten fügen wir eine REJECT-Regel ein, und diese sendet eine ICMP-Nachricht mit port unreachable. REJECT funktioniert also nur, wenn die entsprechende ICMP-Nachricht auch ausgehend durchgelassen wird. Bei Firewall-Konstrukten mit IP-Forwarding muß auf jeden Fall aber darauf geachtet werden, daß port unreachable-Nachrichten von drinnen nach draußen nicht weitergeleitet werden, ansonsten läßt sich diese Tatsache ggf. von Portscannern auf UDP-Basis ausnutzen. Filterregeln für DNS # ---------------------------------------------------------# DNS $IPTABLES -A OUTPUT -p UDP --sport $p_high \ -d $ns --dport domain -j ACCEPT
Da wir keinen eigenen Nameserver einsetzen, müssen auf Grund der Eigenschaften von DNS (siehe Abschnitt 7.1.2) sowohl ausgehende UDP- als auch TCPVerbindungen zum Port 53 zugelassen werden. Allerdings kann man die Destination-IP auf die verwendeten Nameserver einschränken. Vom Resolver eines Client werden sowieso nur die Nameserver direkt angesprochen, die in der Datei /etc/resolv.conf konfiguriert sind. SMTP, POP3 # ---------------------------------------------------------# SMTP, POP3 $IPTABLES -A OUTPUT -p TCP --sport $p_high \ -d $mail --dport smtp -j ACCEPT $IPTABLES -A INPUT
Der Mailserver wird vom Provider festgelegt, die Regeln sind daher recht einfach. Es kann auch sein, daß für E-Mail-Versand via SMTP und den Empfang via POP3 unterschiedliche Hosts verwendet werden. Dann ist die entsprechende IP-Adresse abzuändern. Für das Abholen von E-Mails via IMAP ist einfach der Port pop3 durch imap4 zu ersetzen. Bei verschlüseltenen IMAP- oder (seltener) POP3-Verbindungen via SSL muß dann ebenfalls als Port derjenige eingesetzt werden, der vom Provider vorgegeben wird. Wird die E-Mail vom Provider via SMTP zugestellt, muß die Regel für POP3 ersetzt werden. Zustellung vom Provider durch SMTP beinhaltet in der Regel
214
8.2 Einzelner Rechner mit direktem Internetzugang
aber einen eigenen, sauber konfigurierten Mailhost. Für Endanwender ist das aber eher die Ausnahme. # ---------------------------------------------------------# {\email}empfang via SMTP $IPTABLES -A INPUT
Ermöglicht ausgehende Verbindungen zu beliebigen Webservern (DestinationPort 80). Als zusätzlichen Schutz wird ein eingehender Verbindungsaufbau vom Source-Port 80 mit ! --syn verhindert, ansonsten könnte ein gewiefter Angreifer einen Verbindungsaufbau von außen versuchen, in dem er einen Source-Port 80 vorgibt und einen Port 1023 anspricht.
Filterregeln für SSL Wer A sagt, muß auch B sagen: über Port 80 werden nur die Standard-Verbindungen von HTTP in ihrer ursprünglichen Form abgewickelt. In E-CommerceUmgebungen gehört die verschlüsselte Variante über den Secure Socket Layer SSL inzwischen zum Alltag. Um auch solche Angebote nutzen zu können, muß zum Port 80 (http) auch der Port 443 (https) freigeschaltet werden: # ---------------------------------------------------------# HTTP via SSL $IPTABLES -A OUTPUT -p TCP --sport $p_high \ --dport https -j ACCEPT
Warum hier einen REJECT, statt DROP? Viele Dienste wie FTP-Server versuchen bei einem Verbindungsaufbau die Identität des Users festzustellen und stellen daher ihrerseits eine Anfrage an den identd. Bleibt die Anfrage unbeantwortet, dann geben die meisten Dienste erst nach mehreren Versuchen auf. Ein REJECT sagt dem Dienst, das die Anfrage vergeblich ist. Der Verbindungsaufbau geht mit einem REJECT auf die identd-Abfrage um ein Vielfaches schneller. Ausgehende identd-Abfragen wären nur notwendig, wenn wir selbst einen Server-Dienst anbieten, was aber in diesem Beispiel nicht der Fall ist. Filterung von FTP-Verbindungen, passives FTP-DATA # ---------------------------------------------------------# ftp, out, control connection $IPTABLES -A OUTPUT -p TCP --sport $p_high \ --dport ftp -j ACCEPT $IPTABLES -A INPUT
Ausgehende FTP-Verbindungen, die sogenannte control connection, werden zum Serverport 21 aufgebaut. Soweit ist FTP eine ganz normale TCP-Verbindung. Die Datenübertragung erfolgt dagegen über eine 2. Verbindung, die sogenannte data connection. Wie in Abschnitt 7.1.6 bereits beschrieben, ziehen wir hier die passive Variante vor, die keinen Verbindungsaufbau von extern erfordert. Charakteristisch für die passive Daten-Verbindung ist, daß der Serverport, der vom Client angesprochen wird, ein zufälliger unprivilegierter Port ist. Für den Hausgebrauch haben wir jetzt Regeln für die wichtigsten Internet-Dienste konfiguriert. Vielleicht nicht so häufig im Einsatz, aber trotzdem sehr nützlich sind die Secure Shell und NTP. Filterregeln für SSH Für sichere Remote-Logins unverzichtbar geworden ist die Secure Shell SSH. Man sollte im Internet auf Telnet generell verzichten (auf r*-Kommandos sowieso) und die Secure Shell einsetzen. Näheres zur Secure Shell im Abschnitt 7.1.5 bzw. im Anhang C. Anmerkung: man sollte die nachfolgenden Regeln (wie eigentlich alle anderen auch) nur dann konfigurieren, wenn man sie auch wirklich benutzt. Solange die Secure Shell nicht benötigt wird, sollten die Regeln deaktiviert bleiben (z. B. im Startup-Skript auskommentieren): # ---------------------------------------------------------# ssh $IPTABLES -A OUTPUT -p TCP -d $FRIEND --dport ssh \ --sport $p_ssh -j ACCEPT $IPTABLES -A INPUT
$FRIEND ist hier ein befreundetes Netzwerk (in unserem Beispiel der Provider, es könnte aber auch z. B. die Universität, der Arbeitgeber etc. sein). Man sollte sich durchaus die Mühe machen, den Zielkreis auf die wirklich benutzten IPAdressen einzuschränken, in der Regel sind diese ja bekannt. In der Standardeinstellung benutzt die Secure Shell als Source-Port den ersten freien Port unter 1024, beginnend also mit 1023 abwärts. Man sollte mehr als nur eine Handvoll Ports freigegeben, da jede Verbindung via Secure Shell einen Port benutzt, z. B. neben der eigentlichen ssh auch jeder parallel dazu laufende scp-Prozess. In unserem Beispiel ist $p_ssh der Bereich 1000:1023. An sich spricht nichts dagegen, SSH explizit mit unprivilegierten Source-Ports zu verwenden. Anstelle von $p_ssh wäre dann in der Filterregel $p_high zu
217
8 Firewalls bauen – einzelner Rechner
verwenden. Allerdings ist dann die Autorisierung via rhosts bzw. rsahosts nicht zulässig, und der User muß explizit die Verwendung der unprivilegierten Ports angeben. In unserem Beispiel eines Standalone-Hosts beschränkt sich das auf ganz wenige User. Filterregeln für xntp # ---------------------------------------------------------# xntp $IPTABLES -A OUTPUT -p UDP --sport ntp --dport ntp -j ACCEPT $IPTABLES -A INPUT
-p UDP --dport ntp --sport ntp -j ACCEPT
Die wenigsten haben zu Hause eine Funkuhr am Rechner, das bleibt in der Regel umfangreicheren Netzwerken vorbehalten. Es ist auch gar nicht notwendig. Man kann sich aus dem Internet via NTP mit exakter Zeit versorgen. Wählverbindungen bedeuten normalerweise, daß man nur zeitweise Internet-Anbindung hat. Damit kann man den xntp-Daemon nicht einsetzen. Denn regelmäßiges Pollen von Zeitservern würde zu ständigem automatischem Verbindungsaufbau führen. Für einmalige Zeitabfragen kann man ntpdate verwenden, das in den xntpPaketen enthalten ist. NTP dient auch wie eine UDP-Verbindung mit identischem Source- und Ziel-Port. Anders als vielleicht sonst in der Literatur dargestellt, verwendet ntpdate – obwohl es ein typisches Client-Programm ist – als Source-Port den Port 123 (ntp), und keinen Port größer als 1023. ntpdate verwendet als Source-Port unprivilegierte Source-Ports nur, wenn man es dazu explizit überredet (Option -u oder auch bei -d). Man könnte zum Beispiel bei jedem Verbindungsaufbau über das Skript ip-up jedesmal ein ntpdate ausführen: ntpdate <server1> <server2> <server3> ...
Sich auf einen einzigen Server zu verlassen kann gefährlich sein, theoretisch könnte die IP-Adresse gespooft sein und auf einen Rechner mit falscher Zeit umgelenkt sein. Werden mehrere Server gleichzeitig angegeben, reduziert sich das Risiko stark, da die xntp-Programme Algorithmen enthalten, die mit aus der Reihe tanzenden Zeitservern entsprechend umgehen. Aufräumen # ---------------------------------------------------------# Ausputzer: Rest sperren, loggen
218
8.2 Einzelner Rechner mit direktem Internetzugang
$IPTABLES -A INPUT
-j my_drop
$IPTABLES -A FORWARD -j my_drop $IPTABLES -A OUTPUT -j REJECT
Warum hier nochmal DROP bzw. REJECT auf alles? Ganz einfach. In der Default Policy gibt es zum einen keine Möglichkeit, Logging einzuschalten. Zum zweiten ist es sinnvoll, die Default-Policy so früh wie möglich zu setzen, um im Falle eines unbemerkten Fehlers im Skript trotzdem Sicherheit walten zu lassen. Zum dritten eröffnet so ein Nachspann die Möglichkeit größerer Flexibilität. Hier wird zum Beispiel REJECT statt DROP in der OUTPUT-Chain gesetzt. In der Regel sind das Pakete, die vom eigenen Rechner stammen. Und dem eigenen Webbrowser sagt ein REJECT, daß er gar nicht weiter zu warten oder es zu versuchen braucht. In unserem Fall des Standalone-Hosts ist der REJECT zumindest für die OUTPUT-Chain die bessere Wahl. Für eine spätere Anbindung eines Netzwerks an das Internet können hier auch noch gezielt für verschiedene Interfaces unterschiedliche Kombinationen gesetzt werden. Das fertige Skript im Zusammenhang Wir lassen hierbei erst einmal NTP und die Secure Shell weg. Der Empfang von E-Mail findet via POP3 statt. #!/bin/tcsh # Firewallscript für
surfer
# ---------------------------------------------------------# PART I: Variablen set IPTABLES = /usr/sbin/iptables # ---------------------------------------------------------# special ports set p_high
= 1024:65535
# unprivileged ports
set p_ssh
= 1000:1023
# common ssh source ports
# ---------------------------------------------------------# interfaces set IF
= ippp0
# ---------------------------------------------------------# ip hosts set surfer
# ---------------------------------------------------------# spoof protection $IPTABLES -A INPUT -s $surfer -i $IF -j DROP # ---------------------------------------------------------# lokale Prozesse $IPTABLES -A OUTPUT -o lo -j ACCEPT $IPTABLES -A INPUT
220
-i lo -j ACCEPT
8.2 Einzelner Rechner mit direktem Internetzugang
# ---------------------------------------------------------# PART III: endgültige Filterregeln # ---------------------------------------------------------# ---------------------------------------------------------# DROP & LOG Chain $IPTABLES -N my_drop $IPTABLES -A my_drop -p ICMP -j LOG --log-prefix "DROP-ICMP " $IPTABLES -A my_drop -p UDP
-j LOG --log-prefix "DROP-UDP "
$IPTABLES -A my_drop -p TCP
-j LOG --log-prefix "DROP-TCP "
$IPTABLES -A my_drop -j DROP # ---------------------------------------------------------# ICMP # ping: 8 und 0, ausgehend $IPTABLES -A OUTPUT -p ICMP --icmp-type echo-request -j ACCEPT $IPTABLES -A INPUT
-p ICMP --icmp-type echo-reply -j ACCEPT
$IPTABLES -A INPUT
-p ICMP --icmp-type echo-request -j my_drop
# source quench (4) $IPTABLES -A OUTPUT -p ICMP --icmp-type source-quench -j ACCEPT $IPTABLES -A INPUT
-p ICMP --icmp-type source-quench -j my_drop
# time exceeded (11) $IPTABLES -A OUTPUT -p ICMP --icmp-type time-exceeded -j ACCEPT $IPTABLES -A INPUT
-p ICMP --icmp-type time-exceeded -j ACCEPT
# parameter problem (12) $IPTABLES -A OUTPUT -p ICMP --icmp-type parameter-problem -j ACCEPT $IPTABLES -A INPUT
# ---------------------------------------------------------# Ausputzer: Rest sperren, loggen $IPTABLES -A INPUT
-j my_drop
$IPTABLES -A FORWARD -j my_drop $IPTABLES -A OUTPUT -j REJECT
8.2.3
Skript starten und gesetzte Regeln protokollieren
Test des Skriptes Ganz wichtig ist es zunächst einmal, das Skript vor dem ersten Einsatz zu testen. Einfache Tippfehler könnten dazu führen, daß das Skript nicht vollständig durchläuft sondern vorher abbricht. Wird das Skript später automatisch über die rc-Startup-Skripte gestartet, fällt ein eventueller Fehler meist nicht auf. Deshalb:
223
8 Firewalls bauen – einzelner Rechner
nach jeder Änderung das Skript einmal von Hand starten und die Ausgabe aufmerksam beobachten. Für die spätere automatische Ausführung beim Start empfiehlt es sich, zusätzliche Ausgaben am Anfang und am Ende des Skriptes einzubauen: echo "setting firewall rules for surfer ..." ... echo "done (firewall rules active)"
Der eigentliche Funktionstest des Skriptes kann ganz pragmatisch ausfallen: da es sich um einen Standalone-Host handelt, vor dem wir auch gerade sitzen, bleibt in erster Linie zu testen, ob die Filterregeln die normalerweise benötigten ausgehenden Verbindungen auch zulassen. Für das erste genügt es, sich einen Dump der Filterregeln via iptables-save anzusehen und auf grobe Fehler zu prüfen. Dann kann man einfach eine Verbindung in das Internet aufbauen und die Logfiles beobachten. Bei dem obigen Skript werden alle DROPs protokolliert und tauchen mit einer entsprechender Meldung im Logfile auf. Difizilere Testmethoden wie der Trockenversand von selbst definierten Paketen sehen wir uns später an (dry run, d. h. mittels iptables -C werden die einzelnen Filterketten geprüft, aber keine tatsächlichen Pakete versandt, es kommt auch zu keinem Eintrag in die Logfiles). Automatischer Start des Skriptes beim Booten Es empfiehlt sich, einen sicheren Platz für das Firewall-Skript zu suchen: Für die Startup-Skripte ist das Verzeichnis /sbin/init.d zuständig. Allerdings kann das Verzeichnis schon mal bei einem Betriebssystem-Update „aufgeräumt“ werden. Ich ziehe es vor, Firewall-Skripte in einem Verzeichnis /root/fw abzulegen. Nennen wir unser erstes Firewall-Skript surfer1. Die symbolischen Links für den Startup sähen dann so aus: ln -s /root/fw/surfer1 /sbin/init.d/rc2.d/S04fw_surfer ln -s /root/fw/surfer1 /sbin/init.d/rc3.d/S04fw_surfer
In den Runleveln 2 und 3, in denen das Netzwerk aktiv ist, müssen auch die Filterregeln gesetzt sein. Den Aufwand, das Skript mit start|stop-Mechanismen auszustatten, schenken wir uns. Alle Regeln löschen Es kann beim Experimentieren mit Filterregeln auch mal notwendig werden, alle Filterregeln wieder zu löschen. Jedesmal den Rechner neu zu starten, ist zu auf-
224
8.2 Einzelner Rechner mit direktem Internetzugang
wendig und gar nicht notwendig: hier ein Skript, mit dem man alle Filterregeln löschen kann: #!/bin/tcsh # Skript: /root/fw/clear_all_rules # --------------------------------------------set IPTABLES = /usr/sbin/iptables # --------------------------------------------# Default Policy rücksetzen $IPTABLES -P INPUT ACCEPT $IPTABLES -P FORWARD ACCEPT $IPTABLES -P OUTPUT ACCEPT # --------------------------------------------# Flush aller Chains, Löschen aller User-Chains $IPTABLES -F $IPTABLES -X exit 0
iptables -F ohne weitere Angabe löscht alle Filterregeln in allen existierenden Ketten. Das ist ganz nützlich, wenn man (wie wir später) selbst einige eigene Filterketten definiert hat. Das Löschen aller selbst definierten Filterketten mit iptables -X geht nämlich nur, wenn die selbst definierten Filterketten keine einzige Regel mehr enthalten und zusätzlich keine der drei Standard-Filterketten mehr auf eine solche selbst definierte Filterkette verweist. Filterregeln protokollieren: iptables -vL Um sich die nun gesetzten Regeln näher ansehen zu können, kann man das Programm iptables-save oder den Aufruf iptables -L verwenden. Wir sehen uns die Ausgaben mit iptables -L näher an: iptables -vL
Wir verwenden die Option -v, um die Interfaces mit auszugeben. Zunächst folgt die Darstellung der INPUT-Chain, dabei wurde die Ausgaben zur besseren Darstellung etwas verändert: die ersten beiden Spalten enthalten bei -v Packetund Byte-Counter, die wir hier weglassen. Für das Drucklayout wurden eini-
225
8 Firewalls bauen – einzelner Rechner
ge Zeilen umbrochen und einige Wörter gekürzt (source wurde durch src, destination durch dest und anywhere durch any ersetzt): Chain INPUT (policy DROP 0 packets, 0 bytes) target prot opt in out src dest DROP
all
--
ippp0 any 192.168.1.10
ACCEPT
all
--
lo
ACCEPT
tcp
--
any
any 192.168.1.0/24 any tcp spts:1000:1023 dpt:ssh
ACCEPT
icmp --
any
any any
any icmp echo-reply
my_drop icmp --
any
any any
any icmp echo-request
my_drop icmp --
any
any any
any icmp source-quench
ACCEPT
icmp --
any
any any
any icmp time-exceeded
ACCEPT
icmp --
any
any any
any icmp parameter-problem
ACCEPT
icmp --
any
any any
any icmp fragmentation-needed
ACCEPT
icmp --
any
any any
any icmp destination-unreachable
ACCEPT
udp
--
any
any 192.0.84.1 any udp spt:domain dpts:1024:65535
ACCEPT
tcp
--
any
any 192.0.84.1 any tcp spt:domain dpts:1024:65535 \
Die gesetzen Regeln der OUTPUT-Chain sehen so aus: Chain OUTPUT (policy DROP 0 packets, 0 bytes) target prot opt in out src dest ACCEPT
all
--
any
lo
ACCEPT
tcp
--
any
any any 192.168.1.0/24 tcp spt:ssh \
any any dpts:1000:1023 flags:!SYN,RST,ACK/SYN
226
8.2 Einzelner Rechner mit direktem Internetzugang
ACCEPT
icmp --
any
any any any icmp echo-request
ACCEPT
icmp --
any
any any any icmp source-quench
ACCEPT
icmp --
any
any any any icmp time-exceeded
ACCEPT
icmp --
any
any any any icmp parameter-problem
ACCEPT
icmp --
any
any any any icmp fragmentation-needed
ACCEPT
icmp --
any
any any any icmp port-unreachable
ACCEPT
udp
--
any
any any 192.0.84.1 udp spts:1024:65535 dpt:domain
ACCEPT
tcp
--
any
any any 192.0.84.1 tcp spts:1024:65535 dpt:domain
ACCEPT
tcp
--
any
any any 192.0.84.3 tcp spts:1024:65535 dpt:smtp
ACCEPT
tcp
--
any
any any 192.0.84.3 tcp spts:1024:65535 dpt:pop3
ACCEPT
tcp
--
any
any any any
tcp spts:1024:65535 dpt:http
ACCEPT
tcp
--
any
any any any
tcp spts:1024:65535 dpt:https
ACCEPT
tcp
--
any
any any any
tcp spts:1024:65535 dpt:ftp
ACCEPT tcp my_drop all
---
any any
any any any any any any
tcp spts:1024:65535 dpts:1024:65535
Nun die Darstellung der FORWARD-Chain, die in unserem Falle logischerweise so gut wie leer ist, da wir nur mit einem einzigen Host in das Internet wollen: Chain FORWARD (policy DROP 0 packets, 0 bytes) target prot opt in out src dest my_drop all -- any any any any
Und schließlich unsere userdefinierte Regelkette für Logging und DROP: Chain my_drop (10 references) target prot opt in out src dest LOG
icmp --
any
any any any LOG level warning prefix ‘DROP-ICMP ’
LOG
udp
--
any
any any any LOG level warning prefix ‘DROP-UDP ’
LOG DROP
tcp all
---
any any
any any any LOG level warning prefix ‘DROP-TCP ’ any any any
8.2.4
Auswertung der Protokolle
Um unseren Paketfilter bei der Arbeit beobachten zu können, muß man natürlich auch wissen, wohin die ganzen Protokolle geschrieben werden. Der Paketfilter protokolliert über den Syslog-Mechanismus mit der Facility kern.info. Eine normale Konfiguration des Syslog-Daemons vorausgesetzt, finden wir diese Meldungen in /var/log/messages wieder (z. B. ein grep "kernel: mmessages liefert unter anderem die Einträge des Paketfilters). Der Übersichtlichkeit halber empfiehlt es sich aber, die Ausgaben für kern.info in einer eigene Datei zu protokollieren. Dazu erhält die Datei /etc/syslog.conf folgenden zusätzlichen Eintrag: kern.info
/var/log/kern.info
227
8 Firewalls bauen – einzelner Rechner
Achtung: der Leerraum dazwischen darf nur mit Tabulatoren aufgefüllt werden, keine Leerzeichen verwenden! Anschließend ist der Syslog-Daemon neu zu starten: /sbin/init.d/syslog restart
Danach muß in /var/log die Datei kern.info auftauchen. Bei Distributionen wie SuSE werden die Logfiles regelmäßig „aufgeräumt“, um ein Überlaufen der Festplatte zu vermeiden. Soll das neue Logfile dort mit einbezogen werden, muß man sich mit dem Mechanismus vertraut machen. Bei SuSE ist dafür das Konfigurationsfile /etc/logfiles verantwortlich, für unser neues Logfile ist dort eine zusätzliche Zeile einzufügen. /var/log/kern.info
+8192k
640
root.root
Sehen wir uns nun einige Beispiele für gefilterte Pakete an. Eingehender Ping Oct 21 19:56:10 surfer kernel: DROP-ICMP IN=eth0 OUT= MAC=00:00:e8:c1:c1:ee:00:50:ba:c1:21:be:08:00 SRC=192.0.81.13 DST=192.0.81.17 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=13678 PROTO=ICMP TYPE=8 CODE=0 ID=51987 SEQ=0 Oct 21 19:56:11 surfer kernel: DROP-ICMP IN=eth0 OUT= MAC=00:00:e8:c1:c1:ee:00:50:ba:c1:21:be:08:00 SRC=192.0.81.13 DST=192.0.81.17 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=13680 PROTO=ICMP TYPE=8 CODE=0 ID=51987 SEQ=1
Der Eintrag beginnt immer mit dem Zeitstempel. Normalerweise erfolgt die Ausgabe eines solchen Eintrages auf einer einzigen Zeile. Zur besseren Lesbarkeit wurden hier bei den Beispielen die Zeilen umbrochen. Im folgenden sind die einzelnen Bestandteile etwas ausführlicher dargestellt: ❏ Oct 21 19:56:10
Der Zeitstempel. ❏ surfer
Die Ausgabe des erzeugenden Rechners (es könnte ja auch ein Eintrag von einem Host sein, der seine Ausgaben remote protokollieren läßt). ❏ kernel:
Hier steht normalerweise der die Meldung verursachende Prozess inclusive Prozess-ID (pid). In unserem Falle ist das der Kernel, und der besitzt keine eigene Prozess-ID. ❏ DROP-ICMP
Die Angabe stammt aus unserer Filterregel: --log-prefix "DROP-ICMP". Läßt man das Leerzeichen am Ende weg, wird der Text ohne Zwischenraum
228
8.2 Einzelner Rechner mit direktem Internetzugang
direkt an das Input-Interface gesetzt. Das hier ist der einzige Hinweis darauf, daß es sich um einen DROP handelt. Man tut gut daran, vom Prefix regen Gebrauch zu machen und sich dabei eine einheitliche Systematik zuzulegen. Die Art, ob und wie man ein Prefix definiert, muß natürlich später auch bei der Logfile-Auswertung berücksichtigt werden. Läßt man das Prefix weg, fehlt dieser Eintrag (oder er sieht entsprechend anders aus). ❏ IN=eth0 OUT=
Input und Output-Interface. Es handelt sich um ein eingehendes Paket (INPUT-Chain oder von der INPUT-Chain aus getriggert), deshalb ist nur das Input-Interface gesetzt. Bei ausgehenden Paketen (OUTPUT-Chain) wäre nur das Output-Interface, bei gerouteten Paketen beide gesetzt. ❏ MAC=00:00:e8:c1:c1:ee:00:50:ba:c1:21:be:08:00
Die Ethernet-HW-Adresse. Die ersten sechs Bytes (00:00:e8:c1:c1:ee) sind die Ethernet-HW-Adresse des eigenen Interface, die nächsten sechs Bytes (00:50:ba:c1:21:be) stellen die Adresse des Absenders dar. ❏ SRC=192.0.81.13 DST=192.0.81.17
Die Source- und Ziel-IP-Adresse. ❏ LEN=84
ist die Länge des Paketes in Bytes, also 84 Bytes lang. ❏ TOS=0x00
Type of Service Feld. ❏ PREC=0x00 ❏ TTL=64
Der Wert des TTL-Zählers (Time To Live). Bei Traceroute-Paketen (siehe unten) wird der Wert explizit für jedes Paket gesetzt, ansonsten bekommt der Zähler beim Start den für das Betriebssystem üblichen Wert mit (Linux 64, Windows 128). Bei jedem Durchqueren eines Routers wird das Paket um 1 reduziert, um Endlosschleifen zu vermeiden. Allerdings läßt sich das Paket auch zur Intrusion Detection interpretieren: Erhält man ein eingehendes Paket von einem unbekannten Rechner mit einer bestimmten TTL, kann man versuchen, ob die unbekannte IP-Adresse sich anpingen läßt. Falls dies möglich ist, zeigt der Ping die TTL des eingehenden Paketes an; und die muß logischerweise identisch mit der vorher protokollierten TTL sein. Gibt es Abweichungen, war das ursprüngliche Paket mit Sicherheit gespooft.
❏ ID=13678
Identification Feld des IP-Headers.
229
8 Firewalls bauen – einzelner Rechner
❏ PROTO=ICMP
Angabe des Protokolls. Bis hierher beziehen sich die Angaben auf den IPHeader, alle folgenden Angaben sind protokollspezifisch. ❏ TYPE=8 CODE=0
ICMP-Typ und -Code. Hier 8/0, also ICMP Echo Request. ❏ ID=51987
Identifier bei ICMP Echo Request/Reply. Das Programm Ping setzt hier bei jeder Serie immer dieselbe Zahl ein, um antwortende Pakete zuordnen zu können. Laufen mehrere Ping-Programme gleichzeitig, tragen die Pakete unterschiedlicher Prozesse auch unterschiedliche Identifiers. ❏ SEQ=0
Zähler bei ICMP Echo Request. Wird vom Programm Ping bei jedem ausgesendeten Paket hochgezählt, um die Pakete einzeln identifizieren zu können. Verlorengegangene Pakete können so genau erfaßt werden. Eingehender http Oct 22 12:40:26 surfer kernel: DROP-TCP IN=eth0 OUT= MAC=00:00:e8:c1:c1:ee:00:50:ba:c1:21:be:08:00 SRC=192.0.81.13 DST=192.0.81.17 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=5118 DF PROTO=TCP SPT=1029 DPT=80 WINDOW=32120 RES=0x00 SYN URGP=0
Das Protokoll ist TCP, der Source- und Zielport (SPT/DPT) sind 1029 bzw. 80: der Rechner mit der IP-Adresse 192.0.81.13 hat versucht, einen bei uns lokal installierten Webserver anzusprechen. Das Paket wurde abgelehnt, was ausschließlich durch das Log-Prefix "DROP-TCP" sichtbar wird. Wir hatten explizit eingehende http-Verbindungen untersagt. Nach dem Ziel-Port folgen weitere Einträge des TCP-Headers: die Window Size und die TCP-Flags. RES= zeigt die reservierten Flags an (6 Bits). Das Paket hat das SYN-Flag gesetzt und signalisiert damit einen Verbindungsaufbau (siehe Abschnitt 4.1.6, Abbildung 4.5). Das URG-Flag ist nicht gesetzt, damit ist auch der Urgent-Pointer nicht gültig. Traceroute Oct 22 12:57:16 surfer kernel: DROP-UDP IN=eth0 OUT= MAC=00:00:e8:c1:c1:ee:00:50:ba:c1:21:be:08:00 SRC=192.0.81.13 DST=192.0.81.17 LEN=40 TOS=0x00 PREC=0x00 TTL=1 ID=5276 PROTO=UDP SPT=35135 DPT=33435 LEN=20 Oct 22 12:57:19 surfer kernel: DROP-UDP IN=eth0 OUT=
Ein einzelnes Paket aus einem Traceroute-Verlauf mutet zunächst einmal seltsam an: Source- und Empfänger-Port sind sehr hohe, unprivilegierte Ports. Es handelt sich um UDP-Pakete mit sehr niedriger TTL. Erst der Gesamtverlauf zeigt, daß es sich um Traceroute handelt. Traceroute sendet in der Regel 3 UDP-Pakete mit der selben TTL aus, dann erhöht es die TTL um 1. Dabei wird bei jedem einzelnen Paket der Zielport um 1 erhöht. Abgelehnt wurde das Paket durch die Catch-All-Regel am Ende des Skriptes. Ein Beispiel aus Alltag Und hier noch ein Beispiel aus dem täglichen Leben, ein echtes Logfile mit echten Daten (62.157.28.99 ist hier die dynamische IP-Adresse des lokalen Rechners pc02): Oct 22 13:09:55 pc02 kernel: DROP-TCP IN=ippp0 OUT= MAC= SRC=149.225.131.192 DST=62.157.28.99 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=5820 DF PROTO=TCP SPT=1034 DPT=27374 WINDOW=32120 RES=0x00 SYN URGP=0 Oct 22 13:09:58 pc02 kernel: DROP-TCP IN=ippp0 OUT= MAC= SRC=149.225.131.192 DST=62.157.28.99 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=5825 DF PROTO=TCP SPT=1034 DPT=27374 WINDOW=32120 RES=0x00 SYN URGP=0
Hier hat jemand nach einem trojanischen Pferd gesucht. Port 27374 wird als Backdoor von SubSeven in der Version 2.1 benutzt. Bis jetzt ist der Trojaner nur für Windows verfügbar, außerdem hat ja der Paketfilter den Scan einfach abgefangen.
231
8 Firewalls bauen – einzelner Rechner
Vor Überinterpretationen sei an dieser Stelle hier schon einmal gewarnt. In dem nachfolgenden Abschnitt wird eine Konfiguration mit dynamischer IP-Adresse beschrieben. Internet-Zugänge mit dynamischer IP-Adresse haben die Eigenschaft, daß bei jedem Verbindungsaufbau die IP-Adresse neu zugewiesen wird. Eigentlich ganz banal, aber man muß es trotzdem einmal zu Ende denken: das gleiche gilt natürlich auch für andere Teilnehmer im Netz. Es kommt durchaus vor, daß eine IP-Verbindung noch offen ist, die Verbindung aber wegen eines gesetzten Timeouts abgebaut wird. Solange nur ein Paket nach draußen geht, macht das nichts. Über eine Kerneleigenschaft wird die IP-Absende-Adresse nach dem Verbindungsaufbau umgeschrieben. Aber ein Paket vom anderen Ende der Verbindung weiß davon nichts. Wird die IP-Adresse inzwischen neu vergeben, erhält der neue Teilnehmer Pakete, die ursprünglich für jemand anderen gedacht waren. Mit anderen Worten: wer bei einer dynamisch zugewiesenen IP-Adresse nach dem Verbindungsaufbau seltsame eingehende Pakete sieht, der muß sich diese genau ansehen. Nicht alles ist für uns bestimmt, und schon gar nicht alles kommt einem Scan oder einer Angriffsvorbereitung gleich.
8.2.5
Dynamische IP-Adressen
Das Problem mit den dynamischen IP-Adressen ist, daß man erst beim Verbindungsaufbau die gültige lokale IP-Adresse übermittelt bekommt. Man kann deshalb keine Filterregeln vorher setzen, die sich auf diese lokale IP-Adresse beziehen. Bis zur Kernelversion 2.2 war das ein ein Problem, da man in vielen Regeln nur dann eine eindeutige Aussage über den Verlauf des Paketes machen konnte, wenn man auch die eigene IP-Adresse eingesetzt hat. Mit dem NetfilterFramework kann bereits über die Kombination Regelkette und Interface eine eindeutige Aussage gemacht werden: iptables -A INPUT -i ippp0 ... iptables -A OUTPUT -o ippp0 ...
bezeichnet ein eingehendes/ausgehendes Paket, das für den lokalen Rechner bestimmt ist, unter Einschränkung des Interface. Wenn man sich die bisherigen Regeln näher ansieht, stellt man fest, daß dort nur eine einzige Regel die eigene IP-Adresse enthält: # ---------------------------------------------------------# spoof protection $IPTABLES -A INPUT -s $surfer -i $IF -j DROP
232
8.2 Einzelner Rechner mit direktem Internetzugang
Spoof-Protection führt aber bereits der rp_filter-Mechanismus durch. Wir benötigen diese Regel also nicht unbedingt und verzichten hier darauf. Ein weiterer, wichtiger Punkt, den man bei dynamischer IP-Adresse nicht aus den Augen lassen sollte: die IP-Adresse für das eigene Interface ändert sich mit jedem Verbindungsaufbau. Das klingt trival, ist es aber nicht. Ein ausgehendes Paket bekommt zunächst einmal die IP-Adresse des Interface als Source-Adresse. Das ist vor dem Verbindungsaufbau die IP-Adresse, die das Interface bei der letzten Verbindung zugewiesen bekam. Mit dem neuen Verbindungsaufbau ändert sich die IP-Adresse aber in den meisten Fällen, so daß dieses Paket nicht einfach beantwortet werden kann, weil die Adresse inzwischen anderweitig oder gar nicht vergeben wurde, und der Provider entsprechend die Routing-Einträge geändert hat. Umschreiben der IP-Source-Adresse Der Kernel kennt eine Option, mit der die IP-Adresse vor dem Verlassen des Interface noch einmal umgeschrieben wird: echo 1 > /proc/sys/net/ipv4/ip_dynaddr
Diese Option ist beim Booten nicht aktiv und muß erst initialisiert werden. Bei SuSE gibt es dazu eine Variable IP_DYNIP=yes in /etc/rc.config, die gesetzt sein muß. Weitere Informationen dieser Option in /usr/src/linux/Documentation/networking/ip_dynaddr.txt Offene TCP-Verbindungen Das Umschreiben der Source-IP-Adresse im IP-Datagramm gilt aber nur für Pakete, nicht für Verbindungen. Bei TCP kommt es durchaus vor, daß Verbindungen über längere Zeit „offen“ bleiben, ohne daß Pakete ausgetauscht werden. Kommt es jetzt zu einem Abbau und anschließendem Wiederaufbau der Verbindung, verliert der lokale Rechner die Hohheit über die bisherige IP-Adresse. Diese aber ist auf der Gegenseite der TCP-Verbindung in einer Tabelle gespeichert. Meldet sich der lokale Rechner jetzt mit weiteren Paketen, verweigert die andere Seite die Pakete, da es zu dieser Source-Adresse keine offene Verbindung gibt. Man kann also über einen Verbindungsab- und aufbau keine offenen Telnet- oder ssh-Sessions retten. Weniger offensichtlich, aber manchmal genauso ärgerlich, sind noch offene HTTP-Verbindungen, weil Browser und Server sich über das HTTP-Protokoll auf einen Modus ohne neuen Verbindungsaufbau geeinigt haben. Der Browser versucht dann, mit einer noch offenen Verbindung weiter zu arbeiten, und das geht schief.
233
8 Firewalls bauen – einzelner Rechner
Die Timeouts müssen also bei dynamischer IP-Adreßvergabe so gelegt sein, daß ein Verbindungsabbau immer möglich ist. Dynamische Serveradressen Mit der Vergabe einer dynamischen IP-Adresse sind Provider teilweise dazu übergegangen, auch vom IP-Adreßbereich abhängige, unterschiedliche NameserverAdressen zuzuordnen. Dynamische Nameserver-Adressen sind problematisch, weil man die IP-Adresse braucht, um überhaupt zu anderen Hosts eine Namensauflösung durchführen zu können. Andere Dienste kann man dagegen über den Namen ansprechen. Gerade bei Name- und Mailserver wäre es aber zweckmäßig, die Verbindung ausschließlich auf die Server des Providers einzuschränken, um wirklich nur die erwünschten Verbindungen zu vertrauenswürdigen Servern zuzulassen. Gerade DNS mit dem UDP-Protokoll macht es schwer, eine Verbindungsrichtung zuzuordnen. Eine Filterregel läßt sich aber für solche dynamischen Dienste erst gezielt festlegen, wenn die Verbindung bereits steht. Andererseits muß es auch ohne diese Regel für ein betroffenes Paket möglich sein, diese Verbindung anzustoßen. Verbietet man offline generell jedes ausgehende Paket zu einem Nameserver, wird die Verbindung nicht aufgebaut, und der Service kann den Namen nicht auflösen, um den Dienst zu starten. Die Katze beißt sich hier in den eigenen Schwanz. Aus dem Dilemma führen verschiedene Wege: ❏ Feste IP-Adresse für Nameserver:
Fast alle Provider bieten für Clients, die mit dynamischen Nameserver-IP’s nicht umgehen können (oder wollen), eine statische Adresse an. Unter Umständen führt das zu deutlich längeren Antwortzeiten im Nameservice, aber beim Einsatz von Firewalling ist dieser Weg durchaus gerechtfertigt. ❏ Feste IP-Adresse für Mailserver:
In der Regel liegen die eingehenden E-Mails immer auf dem selben Server, und ausgehende E-Mails kann man meist immer an den selben SMTP-Server senden, solange dieser online ist. Adressen für Mailserver ändern sich selten, so daß man durchaus einmal manuell die IP-Adressen ermitteln und dann fest eintragen kann. Man sollte dann hin und wieder kontrollieren, ob alles noch funktioniert und gegebenenfalls die Filterregeln korrigieren. ❏ Feste IP-Adreßbereich für Mailserver:
Bei großen Providern gibt es oft ein ganzes Subnetz, das für Maildienste reserviert ist. In diesem Fall kann man SMTP und POP3 für das Subnetz öffnen. Man muß hier die (etwas) geringere Sicherheit gegen eine einfachere Konfigurierbareit abwägen.
234
8.2 Einzelner Rechner mit direktem Internetzugang
❏ Dynamische IP-Adresse für Nameserver/Mailserver:
Da die IP-Adressen erst nach dem Verbindungsaufbau feststehen, muß man für zwei Dinge sorgen: zum einen muß ein ausgehendes Paket an den betroffenen Dienst auch die Möglichkeit haben, in Unkenntnis der IP-Adresse einen Verbindungsaufbau auszulösen. Zum zweiten kann die eigentliche Filterregel erst gesetzt werden, wenn die Verbindung bereits steht. Eine eventuelle offenere Regel sollte dann überdeckt oder dadurch ersetzt werden. Das kann man durch eine Trennung der Skripte in ein Basis-Skript, welches immer beim Systemstart initialisiert wird, und in ein online-Skript, was beim Verbindungsaufbau nach dem Zuweisen der IP-Adresse ausgeführt wird, erreichen. Zunächst gehen wir von dem einfachen Fall aus: Nameserver und Mailserver haben eine feste IP-Adresse. Wir könnten jetzt einfach aus dem bisherigen Skript die zusätzliche Spoofing-Regel entfernen und das Skript einfach weiterverwenden. Das ist auch in Ordnung und funktioniert. Wir können aber auch von der Möglichkeit Gebrauch machen, daß iptables in der Lage ist, abhängig vom Verbindungszustand zu entscheiden (Stateful Inspection): so entsteht ein dynamischer Paketfilter. Skript mit Stateful Inspection Da wir auf dem Standalone-Host keine Serverdienste anbieten (nicht nur der dynamischen IP-Adresse wegen), sondern nur ausgehende Verbindungen erlauben, können wir den Paketfilter so konfigurieren, daß eingehende Pakete grundsätzlich zu einer bestehenden Verbindung gehören müssen: # ---------------------------------------------------------# Rückkanal: eingehende Pakete zu einer bestehenden Verbindung $IPTABLES -A INPUT
-m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT
-m state --state NEW,INVALID -j my_drop
Eingehende Pakete, die einen Verbindungsaufbau signalisieren oder nicht zugeordnet werden können, lehnen wir ganz ab. Zu berücksichtigen ist auch, daß ausgehende Verbindungen, die wir erlauben wollen, nicht nur aus einem Verbindungsaufbau, sondern auch aus weiteren Paketen bestehen. Daher werden generell ausgehende Pakete zugelassen, die zu einer bereits bestehenden Verbindung gehören. Jetzt müssen wir nur noch dafür sorgen, daß erwünschte ausgehende Verbindungen auch initialisiert werden können. Am Beispiel von DNS kann man sehen, daß
235
8 Firewalls bauen – einzelner Rechner
hier auch Verbindungszustände von UDP mit abgedeckt sind. Eine Möglichkeit, die ein statische Paketfilter wegen der Eigenschaften von UDP erst gar nicht zuläßt: # ---------------------------------------------------------# DNS set NS = ( ip-addr-ns1 ip-addr-ns2 ) foreach ns ( $NS ) $IPTABLES -A OUTPUT -p UDP --sport $p_high -d $ns --dport domain \ -m state --state NEW -j ACCEPT $IPTABLES -A OUTPUT -p TCP --sport $p_high -d $ns --dport domain \ -m state --state NEW -j ACCEPT end
Normalerweise steht mehr als nur ein Nameserver zur Verfügung. Das läßt sich mit einer einfachen foreach-Schleife erledigen. Äußerst sinnvoll ist Stateful Inspection auch beim FTP-Protokoll: # ---------------------------------------------------------# ftp, out, control connection $IPTABLES -A OUTPUT -p TCP --sport $p_high --dport ftp \ -m state --state NEW -j ACCEPT
Die zweite Regel, die für passives FTP einen ausgehenden Verbindungsaufbau von unprivilegierten Ports zu unprivilegierten Ports fordert, entfällt. Gerade Trojaner machen sich zunutze, daß oft für FTP solche ausgehenden Verbindungen auf den höheren Ports fast beliebig erlaubt sind. Bei einem statischen Paketfilter ist ein FTP-Proxy die einzige Möglichkeit, diese Sicherheitslücke zu schließen. Hier das vollständige Skript am Stück. Dabei wurden die globalen Stateful Inspection-Regeln sehr weit oben gesetzt, das heißt, noch vor den ICMP-Filterregeln. So können ICMP-Nachrichten, wir eigentlich verbieten wollen, die aber zu einer bestimmten Verbindung gehören (RELATED) doch durchgelassen werden. Ein eingehender ICMP Source Quench darf also passieren, wenn er zu einer bestehenden Verbindung gehört, nicht aber, wenn ein Angreifer darüber eine Denial-of-Service-Attacke versucht. #!/bin/tcsh # Firewall-Skript für
surfer
# ---------------------------------------------------------# PART I: Variablen
236
8.2 Einzelner Rechner mit direktem Internetzugang
set IPTABLES = /usr/sbin/iptables # ---------------------------------------------------------# special ports set p_high
= 1024:65535
# unprivileged ports
set p_ssh
= 1000:1023
# common ssh source ports
# ---------------------------------------------------------# interfaces set IF
= ippp0
# ---------------------------------------------------------# ip hosts # Beispiel, hier die vom Provider genannten Nameserver eintragen. set NS
= ( 193.101.111.20 212.185.248.84 194.25.2.129 )
# Beispiel, hier den vom Provider genannten Mailserver eintragen. set mail
# Default Policy und flush $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT DROP $IPTABLES -F
# flush aller chains
$IPTABLES -X
# delete all userdefined chains
# ---------------------------------------------------------# lokale Prozesse $IPTABLES -A OUTPUT -o lo -j ACCEPT $IPTABLES -A INPUT
-i lo -j ACCEPT
# ---------------------------------------------------------# PART III: endgültige Filterregeln # ---------------------------------------------------------# ---------------------------------------------------------# DROP & LOG Chain $IPTABLES -N my_drop $IPTABLES -A my_drop -p ICMP -j LOG --log-prefix "DROP-ICMP " $IPTABLES -A my_drop -p UDP
-j LOG --log-prefix "DROP-UDP "
$IPTABLES -A my_drop -p TCP
-j LOG --log-prefix "DROP-TCP "
$IPTABLES -A my_drop -j DROP # ---------------------------------------------------------# Rückkanal: eingehende Pakete zu einer bestehenden Verbindung $IPTABLES -A INPUT
-m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT
-m state --state NEW,INVALID -j my_drop
# ---------------------------------------------------------# ICMP # ping: 8 und 0, ausgehend $IPTABLES -A OUTPUT -p ICMP --icmp-type echo-request -j ACCEPT $IPTABLES -A INPUT
-p ICMP --icmp-type echo-reply -j ACCEPT
$IPTABLES -A INPUT
-p ICMP --icmp-type echo-request -j my_drop
238
8.2 Einzelner Rechner mit direktem Internetzugang
# source quench (4) $IPTABLES -A OUTPUT -p ICMP --icmp-type source-quench -j ACCEPT $IPTABLES -A INPUT
-p ICMP --icmp-type source-quench -j my_drop
# time exceeded (11) $IPTABLES -A OUTPUT -p ICMP --icmp-type time-exceeded -j ACCEPT $IPTABLES -A INPUT
-p ICMP --icmp-type time-exceeded -j ACCEPT
# parameter problem (12) $IPTABLES -A OUTPUT -p ICMP --icmp-type parameter-problem -j ACCEPT $IPTABLES -A INPUT
-p ICMP --icmp-type parameter-problem -j ACCEPT
# destination unreachable (3) $IPTABLES -A OUTPUT -p ICMP --icmp-type fragmentation-needed -j ACCEPT $IPTABLES -A OUTPUT -p ICMP --icmp-type port-unreachable -j ACCEPT $IPTABLES -A INPUT -p ICMP --icmp-type fragmentation-needed -j ACCEPT $IPTABLES -A INPUT -p ICMP --icmp-type destination-unreachable -j ACCEPT # ---------------------------------------------------------# DNS foreach ns ( $NS ) $IPTABLES -A OUTPUT -p UDP --sport $p_high -d $ns --dport domain \ -m state --state NEW -j ACCEPT $IPTABLES -A OUTPUT -p TCP --sport $p_high -d $ns --dport domain \ -m state --state NEW -j ACCEPT end # ---------------------------------------------------------# SMTP, POP3 $IPTABLES -A OUTPUT -p TCP --sport $p_high -d $mail --dport smtp \ -m state --state NEW -j ACCEPT $IPTABLES -A OUTPUT -p TCP --sport $p_high -d $mail --dport pop3 \ -m state --state NEW -j ACCEPT # ---------------------------------------------------------# HTTP
239
8 Firewalls bauen – einzelner Rechner
$IPTABLES -A OUTPUT -p TCP --sport $p_high --dport http \ -m state --state NEW -j ACCEPT # ---------------------------------------------------------# HTTP via SSL $IPTABLES -A OUTPUT -p TCP --sport $p_high --dport https \ -m state --state NEW -j ACCEPT # ---------------------------------------------------------# ident: reject $IPTABLES -A INPUT -p TCP --dport auth --syn -j REJECT # ---------------------------------------------------------# ftp, out, control connection $IPTABLES -A OUTPUT -p TCP --sport $p_high --dport ftp \ -m state --state NEW -j ACCEPT # ---------------------------------------------------------# Ausputzer: Rest sperren, loggen $IPTABLES -A INPUT
-j my_drop
$IPTABLES -A FORWARD -j my_drop $IPTABLES -A OUTPUT -j REJECT
8.2.6
Variante für dynamische Filterregeln
Dynamische IP-Adressen auf der Client-Seite lassen sich durch die einfache Struktur des Netfilter-Frameworks gut handhaben: INPUT- und OUTPUT-Chain sind eindeutig dem lokalen Rechner zugeordnet. Man kann die Regeln unabhängig von der gerade aktuellen Interface-IP-Adresse gestalten. Ändern sich dagegen dynamisch die IP-Adressen angesprochener Server – wie im letzten Abschnitt schon erwähnt, kommt das bei zumindest bei DNS durchaus vor – muß man anders vorgehen. Die Filterregeln diesbezüglich können erst nach Aufbau der Verbindung gesetzt werden, und müssen nach dem Abbau der Verbindung wieder gelöscht werden.
240
8.2 Einzelner Rechner mit direktem Internetzugang
Grundprinzip Das Grundprinzip ist einfach: wir verwenden das bisherige Skript als BasisSkript weiter und legen eigens dazu eine neue Regelkette ippp0-dyn-out an, die ausschließlich für „dynamische“ Filterregeln benutzt wird. Wir können uns dabei auf ausgehende Verbindungen beschränken, da eingehende über die globale Stateful Inspection-Regel generell erlaubt werden. Es ist zweckmäßig, solche userdefinierten Regelketten mit dem Interface zu verknüpfen. Steht das zweite Interface für einen weiteren Provider, können damit auch andere Voreinstellungen erforderlich werden (z. B. einen dynamischen Web-Proxy oder ähnliches). Wir entfernen aus dem Basis-Skript einfach alle Filterregeln, die nun eine dynamische IP-Adresse enthalten sollen, etwa der Verbindungsaufbau für DNS. Alles andere bleibt beim alten; das Skript kann wie bisher beim Systemstart ausgeführt werden. Am Ende des Skriptes fügen wir eine Regel ein, die alle noch verbliebenen Pakete (Pakete, auf die bisher keine Filterregel zutraf) in die neue Regelkette umleitet, wenn sie für das Interface ippp0 bestimmt sind. Die neue Regelkette ist zunächst einmal leer, es passiert also dort nichts. #... (bisheriges Skript, aber mit gelöschten DNS-Regeln) # ---------------------------------------------------------# Userdefinierte Chains für dynamische Server-IP’s via ippp0 $IPTABLES -N ippp0-dyn-out # ---------------------------------------------------------# Interface-bezogene Targets $IPTABLES -A OUTPUT -o ippp0 -j ippp0-dyn-out # Trigger-Regel $IPTABLES -A OUTPUT -o ippp0 -m state --state NEW -j ACCEPT # ---------------------------------------------------------# Ausputzer: Rest sperren, loggen $IPTABLES -A INPUT -j my_drop $IPTABLES -A FORWARD -j my_drop $IPTABLES -A OUTPUT -j REJECT
241
8 Firewalls bauen – einzelner Rechner
Nach der Filterregel mit Verweis auf ippp0-dyn-out wurde noch eine TriggerRegel eingefügt. Die Trigger-Regel sorgt dafür, daß eine DNS-Anfrage überhaupt erst eine Verbindung auslösen kann und damit der Rechner auch die Chance erhält, „dynamische“ Filterregeln zu setzen. Man kann natürlich die Trigger-Regel auch gleich von vorneherein auf Dienste einschränken, die bei den dynamischen Filterregeln später gesetzt werden sollen, damit nicht beliebige Dienste einen eventuell unnötigen und unerwünschten Verbindungsaufbau antriggern. Dynamisches Filter-Skript für Interface ippp0 Der Trick bei der Trennung in ein Basis-Skript und ein dynamisches FilterregelSkript: mit dem Verbindungsaufbau setzen wir nach Ermittlung der gewünschten IP-Adressen in der userdefinierten Regelkette ippp0-dyn-out die „dynamischen“ Filterregeln und zum Schluß eine Catch-All-Regel, die alle verbliebenen Pakete über das Device ippp0 abfängt und verwirft: #!/bin/tcsh # ---------------------------------------------------------# ippp0-dynamic.script # ---------------------------------------------------------set IPTABLES = /usr/sbin/iptables # ---------------------------------------------------------# special ports set p_high
= 1024:65535
# unprivileged ports
set IPs
= ( $argv[1-] )
# ---------------------------------------------------------# DNS: dynamische Regeln foreach ns ( $IPs ) $IPTABLES -A ippp0-dyn-out -p -d -m $IPTABLES -A ippp0-dyn-out -p -d -m end
242
UDP --sport $p_high \ $ns --dport domain \ state --state NEW -j ACCEPT TCP --sport $p_high \ $ns --dport domain \ state --state NEW -j ACCEPT
8.2 Einzelner Rechner mit direktem Internetzugang
# ---------------------------------------------------------# Catch-All-Rule: $IPTABLES -A ippp0-dyn-out -j my_drop # end-of-script
Die Catch-All-Regel überdeckt die Trigger-Regel im Basis-Skript, wenn die Verbindung aufgebaut wurde. Und nach dem Verbindungsabbau muß man nur dafür sorgen, daß alle Regeln in der userdefinierten Regelkette ippp0-dyn-out wieder gelöscht werden, was mit iptables -X ippp0-dyn-out
sehr einfach möglich ist. Die IP-Adressen übergeben wir einfach als Argumente auf der Kommandozeile beim Aufruf unseres Skriptes. Uns fehlen nun zum Einsatz noch zwei Dinge: ❏ zum einen muß die gewünschte IP-Adresse ermittelt werden, ❏ zum anderen muß das dynamische Skript so plaziert werden, das es bei je-
dem Verbindungsaufbau, und zwar erst nach der Ermittlung der IP-Adressen, ausgeführt wird. Zunächst die Startmöglichkeit. Bei PPP ist dafür das Skript /etc/ppp/ip-up verantwortlich. Dort suchen wir nach dem Text „case "$BASENAMEïn“: case "$BASENAME" in ip-up) /sbin/route add default gw $REMOTEIP dev $INTERFACE ... /root/fw/ippp0-dynamic.script ... ;;
In dem Case-Statement mit ip-up können wir dann unser Skript aufrufen. Das Skript befindet sich im Beispiel im Verzeichnis /root/fw/., wir übergeben die gewünschten IP-Adressen als Argumente. Hinweis: Bei neueren SuSE-Versionen wird am Ende der Abfrage ip-up ein lokales Skript /etc/ppp/ip-up.local ausgeführt. Man fügt den Aufruf am besten dort ein. Wie erhält man die IP-Adressen? Falls man die lokale IP-Adresse benötigt, steht einem die Variable LOCALIP zur Verfügung. Für unser Beispiel brauchen wir aber die dynamischen IP-Adressen der Nameserver. Diese übermittelt der IPPPDaemon, wenn in der Konfigurationsdatei /etc/ppp/options.ippp0 die Variable ms-get-dns gesetzt ist. in diesem Fall stehen die Variablen $MS_DNS1 und $MS_DNS2 zur Verfügung. Der Aufruf unseres dynamischen Skriptes sieht dann so aus:
243
8 Firewalls bauen – einzelner Rechner
/root/fw/ippp0-dynamic.script $MS_DNS1 $MS_DNS2
Beim PPP-Daemon heißt die Konfigurationsvariable usepeerdns, die IP-Adressen sind dann in den Variablen $DNS1 und $DNS2 enthalten. Noch ein Hinweis zu DNS: das Setzen der korrekten Regeln ist nur die halbe Miete. Der lokale Host kann aus den dynamischen Nameserver-IPs nur Nutzen ziehen, wenn diese in der Datei /etc/resolv.conf auch eingetragen werden. Der IPPP-Daemon erzeugt bei Verwendung von ms-get-dns eine Beispieldatei mit dem gleichen Namen, aber im PPP-Verzeichnis: /etc/ppp/resolv.conf. Deren Daten müssen nach /etc/resolv.conf übernommen werden. Bei SuSE erledigt das das Skript ip-up gleich mit. Mit dem Verbindungsabbau sieht das ähnlich aus, hierfür ist /etc/ppp/ip-down zuständig (ip-down ist nur ein Symlink auf ip-up, es handelt sich um dasselbe Skript): case "$BASENAME" in ip-down) /sbin/route add default gw $REMOTEIP dev $INTERFACE ... /usr/sbin/iptables -X ippp0-dyn-out ;;
Natürlich kann man auch ein Skript erstellen und einfügen, anstatt dort direkt den Befehl iptables auszuführen. Die bisher vorgestellten Skripte sind leicht erweiterbar und anpaßbar, so daß sicher jeder für die Internet-Anbindung seines Rechners eine sichere Anbindung auch bei abweichenden Anforderungen realisieren kann. Im nächsten Abschnitt beschäftigen wir uns mit der Anbindung über einen paketfilternden Linux-Router. Zu dem bisher kennengelernten kommen dann Forwarding und Masquerading/NAT hinzu.
244
Kapitel 9 Firewalls bauen – Netzwerk 9.1 Internetzugang über Router/Paketfilter Wenn mehr als ein Rechner an das Internet anzubinden ist, gibt es verschiedene Möglichkeiten. Eher unüblich, aber durchaus denkbar wäre es, jeden Rechner mit einer ISDN-Möglichkeit zu versehen. Auf jedem Rechner wären dann die bisherigen Skripte anwendbar, und die Rechner wären auch geschützt. Davon sollte man aber absehen. Aus Sicherheitsgründen sollte es nur eine Verbindung zum Internet geben, die sich einfacher administrieren und überwachen läßt und auch einfacher ersetzbar ist. Wer sich bis hier durch das Buch gearbeitet hat, wird leicht einsehen, daß es ein Unding ist, fünf, oder zehn, oder noch mehr Rechner auf diese Art und Weise mit dem Internet zu verbinden. Alles, was für einen Standalone-Host gilt, ist nun auf jeden einzelnen Rechner anzuwenden. Dazu kommt die mehrfache Arbeit für die Überwachung der Sicherheitsmechanismen (siehe Kapitel 10). Anstatt viele Hosts ein bißchen zu überwachen, konzentriert man seine ganze Aufmerksamkeit besser auf eine einzige Stelle. Diese eine Stelle ist im einfachsten Fall ein Paketfilter, der das interne Netzwerk mit dem Internet verbindet, wie in Abbildung 9.1 dargestellt. Wir gehen dabei von folgenden Anforderungen aus: ❏ „gate“ ist ein reiner Paketfilter, das heißt, es werden dort keine eigenen Dien-
ste angeboten. ❏ Die Anbindung von „gate“ erfolgt über ISDN mit dynamischer IP-Adresse. ❏ Zur Fernwartung sollen Logins von dem internen Netzwerk aus via ssh
möglich sein. ❏ Zusätzlich soll aus dem internen Netzwerk heraus eine Verbindung via ssh
zu einem „befreundeten“ Netzwerk möglich sein.
245
9 Firewalls bauen – Netzwerk
Abbildung 9.1: Paketfilter
❏ „gate“ soll bestimmte Syslog-Nachrichten an einen internen Host weitersen-
den. ❏ Für die Nameserver stehen statische IP-Adressen zur Verfügung.
Für die Paketfilterung bedeutet das, daß zwischen Verbindungen von und zu „gate“ und zwischen durchgereichten Verbindungen (Forwarding) unterschieden wird. Sehen wir uns die einzelnen Bestandteile eines Filter-Skriptes näher an. # ---------------------------------------------------------# interfaces set EXT = ippp0 set INT = eth0 set IF
= ( $EXT $INT )
# ---------------------------------------------------------# ip hosts set NS
= 192.168.1.0/255.255.255.0 # example = 192.0.84.0/255.255.255.0
246
9.1 Internetzugang über Router/Paketfilter
Unser Paketfilter unterscheidet ein internes ($INT) und ein externes ($EXT) Interface. Die IP-Adressen für Nameserver und Mailhost hier im Beispiel sind reale Adressen (UUNET), diese sind durch die vom eigenen Provider vorgegebenen IP-Adressen zu ersetzen. Als internes Netzwerk verwenden wir ein Private Network. Der Host, der die Syslog-Daten des Paketfilters entgegennehmen soll, hat die IP-Adresse 192.168.1.9. Des weiteren ist 192.0.84.0 die IP-Adresse des befreundeten Netzwerkes, in das wir uns über das Internet via ssh einloggen wollen. Beim Setzen der dynamischen Kernelparameter ist zu berücksichtigen, daß es jetzt mehrere Interfaces gibt: foreach echo echo echo echo echo end
Hier sei noch einmal darauf hingewiesen, daß beim Löschen eines Interface (etwa isdnctrl delif ippp0) die Interface-abhängigen Einstellungen verloren gehen. Will man ein Interface vorübergehend abschalten, kann man ifconfig ippp0 down verwenden. Für Einstellungen, die für alle Interfaces gleich sein sollen, kann man auch die Variablen im Unterverzeichnis all benutzen: echo echo echo echo echo
Die Änderungen wirken sich dann auf alle Interfaces aus. Als nächstes sind die Default Policies und das Leeren aller Regelketten an der Reihe: # ---------------------------------------------------------# Default Policy und flush $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT DROP $IPTABLES -F $IPTABLES -t nat -F $IPTABLES -X
# # # #
flush aller chains (Tabelle filter) flush aller chains (Tabelle nat) delete all userdefined chains (Tabelle filter)
247
9 Firewalls bauen – Netzwerk
Zu dem bisherigen kommt jetzt die Tabelle nat für Network Address Translation. Zur Erinnerung: ein Aufruf von iptables ohne die Option -t
bezieht sich immer nur auf die Tabelle filter. Benutzt man die anderen Tabellen, muß auch beim Löschen daran gedacht werden. In den Anforderungen an den Paketfilter haben wir die Fernwartung via ssh genannt. Im Gegensatz zum Standalone-Host, vor dem man in der Regel selbst sitzt, steht ein Paketfilter, der das lokale Netzwerk mit dem Internet verbinden soll, nicht unbedingt am eigenen Arbeitsplatz. Ein sicherer Remote-Zugang ist deshalb zweckmäßig: # ---------------------------------------------------------# ssh fuer Fernwartung $IPTABLES -A INPUT -i $INT -s $INTERN \ -p TCP --sport $p_ssh --dport ssh \ -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -o $INT -d $INTERN \ -p TCP --dport $p_ssh --sport ssh \ -m state --state ESTABLISHED,RELATED -j ACCEPT
Wir konfigurieren die Filterregeln hier vollständig (ein- und ausgehend), weil diese später im Skript möglichst weit oben eingefügt werden sollen. Beim Experimentieren mit dem Paketfilter und auch später bei dessen Administrieren kann auch mal ein Fehler auftreten, der verhindert, daß das Skript vollständig ausgeführt wird. Die Default-Policy verhindert im ungünstigsten Falle jeden Netzwerkverkehr. Ist die ssh-Filterregel aber schon gesetzt, bevor das Skript abbricht, kann man den Fehler auch remote wieder beheben. Interessant ist noch die Kombination aus INPUT-Chain und Input-Interface: -A INPUT -i $INT legt eindeutig fest, woher das Paket kommt (nämlich vom lokalen Netzwerk zum lokalen Rechner), und -A OUTPUT -o $INT legt ebenso eindeutig fest, wohin das Paket geht (vom lokalen Rechner zum lokalen Netzwerk), und das vollständig ohne Angabe einer IP-Adresse des lokalen Rechners (bei Kernel 2.2 noch hätte man mit IP-Adressen arbeiten müssen, um unterscheiden zu können, ob es sich um Pakete für den lokalen Rechner oder um Forwarding-Verbindungen handelt, z. B. Destination IP = lokale IP bei eingehenden Verbindungen zum lokalen Rechner). Wenn hier trotzdem eine IP-Adresse angegeben wird (Source IP bei eingehenden Paketen), dann aus dem Grund, um
248
9.1 Internetzugang über Router/Paketfilter
die Herkunft der Verbindung weiter einschränken zu können (gegebenenfalls auch auf einen einzigen Rechner, von dem aus administriert werden darf). Nun folgen die für alle Verbindungen gültigen Grundregeln. Wir sorgen zunächst dafür, daß alle ausgehenden Pakete als Source-Adresse die IP-Adresse des dynamischen Interface haben (Masquerading): # ========================================================== # PART IV: Masquerading, generell bestehende Verbindungen # ========================================================== # ---------------------------------------------------------# MASQUERADING $IPTABLES -t nat -A POSTROUTING -o $EXT -j MASQUERADE echo "1" > /proc/sys/net/ipv4/ip_forward echo "1" > /proc/sys/net/ipv4/ip_dynaddr
# wieder einschalten
Alle Pakete, die den Rechner über das externe Interface verlassen, werden maskiert. Um die Rückrichtung muß man sich keine Gedanken machen. Das Modul für Connection Tracking (ip_conntrack), daß für NAT benötigt wird, erledigt das automatisch. Zusätzlich schalten wir Forwarding wieder ein. Die schon bekannten Filterregeln für bereits bestehende Verbindungen werden um Forwarding-Regeln erweitert: # ---------------------------------------------------------# ausgehende Pakete bei bereits aufgebauter Verbindung $IPTABLES -A OUTPUT \ -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i $INT -o $EXT \ -m state --state ESTABLISHED,RELATED -j ACCEPT # ---------------------------------------------------------# Rückkanal: eingehende Pakete zu einer bestehenden Verbindung $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT -m state --state NEW,INVALID -j my_drop $IPTABLES -A FORWARD -i $EXT -o $INT \ -m state --state ESTABLISHED,RELATED -j ACCEPT
249
9 Firewalls bauen – Netzwerk
$IPTABLES -A FORWARD -i $EXT -o $INT \ -m state --state NEW,INVALID -j my_drop
Während bei Verbindungen von und zum lokalen Rechner die Richtung schon über die INPUT- bzw. OUTPUT-Chain festgelegt ist, ist bei der FORWARD-Chain die Angabe von Input- und Output-Device erforderlich: $IPTABLES -A FORWARD -i $INT -o $EXT ... $IPTABLES -A FORWARD -i $EXT -o $INT ...
Aus der Sicht des lokalen Netzwerkes ist die erste Regel für ausgehende, die zweite für eingehende Verbindungen gültig. Der Rest des Skriptes besteht aus den erlaubten Verbindungen, unterteilt in Verbindungen für den lokalen Host (von und zum Paketfilter) und gerouteten Verbindungen über den Paketfilter hinweg. Da wir bereits Regeln für existierende Verbindungen erstellt haben, bleibt nur noch, den Verbindungsaufbau (State = NEW) zu erlauben: # ========================================================== # PART V: Filterregeln für lokale Dienste # ========================================================== # ---------------------------------------------------------# ICMP $IPTABLES -A OUTPUT -p ICMP --icmp-type echo-request -j ACCEPT # ---------------------------------------------------------# SYSLOG $IPTABLES -A OUTPUT -o $INT -m state --state NEW \ -p UDP --sport syslog -d $loghost --dport syslog \ -j ACCEPT
Ausgehendes Ping ist erlaubt, sowohl in das interne Netzwerk, wie auch in das Internet (keine Angabe eines Device). Da Ping ein Frage-Antwort-Spiel ist, wird der „ICMP Echo Request“ vom Connection Tracking Module als Verbindungsaufbau gewertet, wobei „eine Verbindung“ nur aus einem einzigen „Echo Request“ und dem dazu gehörigen „Echo Reply“ besteht. Für die gewünschte Protokollierung von Syslog auf einem internen Host dient die zweite Regel, die allerdings stark eingeschränkt ist (Interface, Destination IP, Destination Port, Protokoll UDP).
250
9.1 Internetzugang über Router/Paketfilter
Eingehende ssh-Verbindungen wurden schon weiter oben konfiguriert, weitere Dienste von und zum lokalen Rechner lassen wir nicht zu. Es bleiben die Forwarding-Regeln, die den eigentlichen Paketfilter (Router) ausmachen. # ========================================================== # PART VI: Filterregeln für Forwarding # ========================================================== # ---------------------------------------------------------# ICMP $IPTABLES -A FORWARD -o $EXT -p ICMP --icmp-type echo-request \ -j ACCEPT
„ICMP Echo Request“ erlauben wir aus dem internen Netzwerk heraus. Die Richtungsangabe ist hier nur noch durch die Chain FORWARD und das OutputInterface -o $EXT festgelegt. Wenn ippp0 das einzige ISDN-Interface und eth0 das einzige lokale Interface ist, genügt das. Die Angabe einer Source-IP kann man ebenfalls unterlassen, wenn es zum lokalen Netzwerk keine weiteren Verbindungen gibt. Schon ein einziges, drittes Interface (etwa ippp1 zu einem zweiten Provider) macht es notwendig, die Regel weiter einzuschränken. Die obige Regel würde prinzipiell ein Forwarding eines „ICMP Echo Request“ von ippp1 nach ippp0 erlauben. Ob das Sinn macht, sei dahingestellt. Beim Firewalling geht es eher darum, nur die erwünschten Verbindungen zuzulassen und alle anderen zu verbieten, unabhängig davon, ob ein erlaubtes Paket eine sinnvolle Verbindung aufbauen kann oder nicht. Wer mehrere externe Interfaces hat und/oder nicht sicherstellen kann, ob es zum internen Netzwerk noch weitere Außenanbindungen gibt (in größeren Netzwerken kann es durchaus einmal zu „Hintertüren“ – ob bewußt oder unbewußt – kommen), muß die Regeln etwas stärker formulieren: $IPTABLES -A FORWARD -i $EXT -o $INT -s $INTERN ...
Unsere Regeln basieren aber auf einer ganz einfachen Konstellation (siehe Abbildung 9.1). # ---------------------------------------------------------# DNS foreach ns ( $NS ) $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p UDP --sport $p_high -d $ns --dport domain \ -j ACCEPT
251
9 Firewalls bauen – Netzwerk
$IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high -d $ns --dport domain \ -j ACCEPT end
An den bisher bekannten Regeln ändert sich wenig. Wo vorher die OUTPUTChain stand, steht jetzt die FORWARD-Chain zusammen mit dem Output-Interface. Wer hier die DNS-Regeln für den lokalen Host vermißt: der Paketfilter benötigt nicht unbedingt einen Nameserver. Die wichtigen IP-Adressen – vor allem aus dem lokalen Netzwerk – kann man in die Datei /etc/hosts eintragen. Um zu verhindern, daß generell DNS auf dem Paketfilter verwendet wird, kann man in der Datei /etc/nsswitch.conf alle Zeilen wie hosts: networks:
files dns files dns
editieren und den Eintrag dns entfernen. Ein leeres /etc/resolv.conf hat denselben Effekt, allerdings muß man aufpassen, daß die verwendete Distribution (wie z. B. SuSE 7.x) nicht über das Startup-Skript /etc/ppp/ip-up eine /etc/resolv.conf neu anlegt. # ---------------------------------------------------------# SMTP, POP3 $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high -d $mail --dport smtp \ -j ACCEPT $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high -d $mail --dport pop3 \ -j ACCEPT
Die Regeln zu SMTP und POP3 sind nach dem bereits bekannten Schema aufgebaut. Ergänzend sei noch darauf hingewiesen, daß auch Situationen denkbar wären, in denen SMTP- und POP3-Server durchaus verschiedene Hosts sein können, oder, wenn verschiedene User im Netzwerk Postfächer bei verschiedenen Diensteanbietern haben (z. B. sogenannte Freemailer), können natürlich je Dienst auch Verbindungen zu mehreren Hosts erforderlich werden. Zu den anderen Diensten HTTP, HTTP/SSL, Ident und FTP muß nun nicht mehr viel gesagt werden: # ---------------------------------------------------------# HTTP $IPTABLES -A FORWARD -o $EXT -m state --state NEW \
252
9.1 Internetzugang über Router/Paketfilter
-p TCP --sport $p_high --dport http \ -j ACCEPT # ---------------------------------------------------------# HTTP via SSL $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high --dport https \ -j ACCEPT # ---------------------------------------------------------# ident: reject $IPTABLES -A FORWARD -i $EXT \ -p TCP --dport auth --syn -j REJECT # ---------------------------------------------------------# ftp, out, control connection $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high --dport ftp \ -j ACCEPT # ftp, out, passive data connection $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high --dport $p_high \ -j ACCEPT
Zum Schluß noch eine Regel, die eine ssh-Verbindung zu einem „befreundetem“ Netzwerk erlaubt: # ---------------------------------------------------------# SSH $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_ssh --dport ssh \ -d $FRIENDs -j ACCEPT
$IPTABLES -A INPUT -j my_drop $IPTABLES -A FORWARD -j my_drop $IPTABLES -A OUTPUT -j my_drop
Zur leichteren Orientierung nun noch einmal das gesamte Skript am Stück, nicht geschnitten: #!/bin/tcsh # Firewall-Skript für gate # ========================================================== # PART I: Variablen # ========================================================== set IPTABLES = /usr/sbin/iptables # ---------------------------------------------------------# special ports set p_high set p_ssh
= 1024:65535 = 1000:1023
# unprivileged ports # common ssh source ports
# ---------------------------------------------------------# interfaces set EXT = ippp0 set INT = eth0 set IF
= ( $EXT $INT )
# ---------------------------------------------------------# ip hosts set NS
# ---------------------------------------------------------# ausgehende Pakete bei bereits aufgebauter Verbindung $IPTABLES -A OUTPUT \ -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i $INT -o $EXT \ -m state --state ESTABLISHED,RELATED -j ACCEPT # ---------------------------------------------------------# Rückkanal: eingehende Pakete zu einer bestehenden Verbindung $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT -m state --state NEW,INVALID -j my_drop $IPTABLES -A FORWARD -i $EXT -o $INT \
256
9.1 Internetzugang über Router/Paketfilter
-m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i $EXT -o $INT \ -m state --state NEW,INVALID -j my_drop # ========================================================== # PART V: Filterregeln für lokale Dienste # ========================================================== # ---------------------------------------------------------# ICMP $IPTABLES -A OUTPUT -p ICMP --icmp-type echo-request -j ACCEPT # ---------------------------------------------------------# SYSLOG $IPTABLES -A OUTPUT -o $INT -m state --state NEW \ -p UDP --sport syslog -d $loghost --dport syslog \ -j ACCEPT # ========================================================== # PART VI: Filterregeln für Forwarding # ========================================================== # ---------------------------------------------------------# ICMP $IPTABLES -A FORWARD -o $EXT -p ICMP --icmp-type echo-request \ -j ACCEPT # ---------------------------------------------------------# DNS foreach ns ( $NS ) $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p UDP --sport $p_high -d $ns --dport domain \ -j ACCEPT $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high -d $ns --dport domain \ -j ACCEPT end
257
9 Firewalls bauen – Netzwerk
# ---------------------------------------------------------# SMTP, POP3 $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high -d $mail --dport smtp \ -j ACCEPT $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high -d $mail --dport pop3 \ -j ACCEPT # ---------------------------------------------------------# HTTP $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high --dport http \ -j ACCEPT # ---------------------------------------------------------# HTTP via SSL $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high --dport https \ -j ACCEPT # ---------------------------------------------------------# ident: reject $IPTABLES -A FORWARD -i $EXT \ -p TCP --dport auth --syn -j REJECT # ---------------------------------------------------------# ftp, out, control connection $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high --dport ftp \ -j ACCEPT # ftp, out, passive data connection $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high --dport $p_high \ -j ACCEPT
258
9.2 Einfacher Firewall
# ---------------------------------------------------------# SSH $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_ssh --dport ssh \ -d $FRIENDs -j ACCEPT
# ---------------------------------------------------------# Ausputzer: Rest sperren, loggen $IPTABLES -A INPUT -j my_drop $IPTABLES -A FORWARD -j my_drop $IPTABLES -A OUTPUT -j my_drop
9.2 Einfacher Firewall Betrachten wir noch einmal die Abbildung 4.9, einen „klassischen“ Firewall aus zwei Paketfiltern und einer Demilitarized Zone (DMZ). Legt man gedanklich die beiden Paketfilter in eine Box zusammen, behält dabei aber das DMZ bei, erhält man einen „collapsed“ Firewall. Der Begriff „collapsed“ ist hier aus der Netzwerktechnik entliehen. Dort stellt ein „collapsed backbone“ ein Backbone dar, das in einem einzigen Schrank zusammengefaßt wird (meist sogar in einer einzigen, leistungsfähigen Netzwerkkomponente). Im Bereich der Firewall-Technologie stellt die „collapsed“-Variante einen einfachen Firewall dar, der sich etwas leichter administrieren und überwachen läßt als sein „großer“ Bruder mit zwei Paketfiltern und einem DMZ dazwischen. Außerdem ist dazu auch weniger Hardware erforderlich. Abbildung 9.2 zeigt so einen „collapsed“ Firewall. Der bisherige Paketfilter bekommt ein weiteres Netzwerkinterface für das DMZ (eth1). Man kann mit dem „collapsed“ Firewall alle Konfigurationen abdecken, die man auch mit einem Firewall aus zwei Paketfiltern, einem DMZ, und einem oder mehreren Single-Homed Bastion Hosts umsetzen möchte. Für die weitere Diskussion gehen wir im folgenden von einer Arbeitsteilung aus: der „collapsed“ Paketfilter „fire“ übernimmt die Paketfilterung (sonst nichts), ein oder mehrere SingleHomed Bastion Hosts im DMZ stellen Proxy-Dienste zur Verfügung. Was man dabei aber nicht aus den Augen lassen sollte, ist die Tatsache, daß der „collapsed“ Firewall empfindlicher auf Konfigurationsfehler reagiert. Bei der klassischen Variante schützt bei Ausfall der Filterung auf einem der beiden Paketfilter immer noch der zweite Paketfilter. Fällt die Filterung auf dem „collapsed“
259
9 Firewalls bauen – Netzwerk
Abbildung 9.2: Einfacher Firewall in einem Rechner („collapsed“ Firewall)
Firewall aus, gibt es kein Netz und keinen doppelten Boden mehr. Beim Arbeiten an der Konfiguration muß man dementsprechend umsichtig vorgehen. Die gedankliche Zusammenlegung der beiden Paketfilter ist nur eine Möglichkeit. Man könnte noch einen Schritt weitergehen und alles – inclusive der ProxyDienste – in einer einzigen Box integrieren. Man kann. Ob man es aber auch tun soll, ist eine andere Frage. Eine Box, die nicht nur Paketfilterung durchführt, sondern gleichzeitig auch Dienste vorhält, bietet schon wieder eine größere Angriffsfläche als ein reiner Paketfilter. Aus der Sicht des Systemadministrators ist die Trennung zwischen Paketfilterung und Bastion Hosts flexibler. Es können nach Bedarf ein oder mehrere Bastion Hosts aufgestellt und getrennt gepflegt werden. Im folgenden gehen wir von einer Konfiguration, wie in Abbildung 9.2 dargestellt, mit folgenden Anforderungen aus: ❏ „fire“ ist ein reiner Paketfilter ❏ Die Anbindung erfolgt wieder über ISDN mit dynamischer IP-Adresse. ❏ Generell sollen alle Dienste indirekt, d. h. über Proxy-Mechanismen abge-
wickelt werden. ❏ E-Mail wird über einen Mailserver (z. B. dem Bastion Host) im DMZ zur
Verfügung gestellt. Er holt die E-Mails via POP3 beim Provider ab und ver-
260
9.2 Einfacher Firewall
sendet selbst via SMTP. Das interne Netzwerk kommuniziert nur mit dem Mailserver. ❏ Auf dem Bastion Host kommt SOCKS als Proxy zum Einsatz. ❏ Es soll kein eigener DNS-Server eingesetzt werden: entweder sollen die
Nameserver des Internet-Providers erreichbar sein, oder ein Caching-OnlyNameserver wird verwendet. ❏ Zur Fernwartung sollten alle Systeme im Firewall via ssh erreichbar sein. ❏ Alle Systeme im Firewall sollen Syslog-Nachrichten an einen internen Host
senden können. Diese Konfiguration kann als generischer Baukasten verwendet werden. Sie ist noch überschaubar, um auf sicherem Terrain Erfahrungen mit dem Firewall zu sammeln, kann aber bei Bedarf auch weiter ausgebaut werden. Statt SOCKS kann für HTTP auf dem Bastion Host ein echter HTTP-Caching-Proxy (z. B. Squid) zum Einsatz kommen. Mit Proxies, die mit „Transparentem Proxying“ umgehen können, kann man auch Clients einsetzen, die Probleme mit SOCKS haben. Ein applikationsspezifischer Proxy kann natürlich noch wesentlich mehr als ein generischer. Ausführlicher wird darauf im Kapitel 6 eingegangen. DNS-Handling Zurück zur vorgestellten Ausgangskonfiguration. Dort ist mit einem „entweder/oder“ schon angedeutet, das es für DNS keine in jedem Falle eindeutig richtige Lösung gibt. Wir haben 3 Möglichkeiten: ❏ Namensauflösung via SOCKS
Der Client kann die Namensauflösung via SOCKS durchführen. Zum einen kann SOCKS die Nameserver-Anfragen weiterreichen wie (fast) jeden anderen Dienst. Dazu kann man bei Dante SOCKS folgende Zeile Client-seitig in der /etc/socks.conf konfigurieren: resolveprotocol: udp # default
Voraussetzung dafür ist, daß der Client auch über die Nameserver Bescheid weiß, also /etc/resolv.conf korrekt konfiguriert ist. Kann der Client auf keine Art und Weise eine Namensauflösung durchführen, bietet Dante SOCKS eine Möglichkeit an, mit der der SOCKS-Server selbst die Namensauflösung übernimmt. Der Client übermittelt dann nur den Namen, keine IP-Adresse: resolveprotocol: fake # set this if your clients can’t # access nameserver, neither # directly nor proxied via socks.
261
9 Firewalls bauen – Netzwerk
❏ Direkter Zugriff auf den Nameserver des Providers
Die einfachste Möglichkeit ist natürlich, einfach alle Nameserveranfragen statt via SOCKS direkt an den Nameserver des Providers zu leiten. Notwendig kann das zum Beispiel werden, wenn ein Client trotz SOCKS-Konfiguration eigenmächtig den Nameserver sucht, aber kein eigener Nameserver zur Verfügung steht. In der Konfigurationsdatei socks.conf am Client sieht das dann so aus (für den Nameserver 193.101.111.10 aus den Beispielen, muß auf jeden Fall auf die eigenen Verhältnisse angepaßt werden): route { from: 192.168.1.0/24 to: 193.101.111.0/24 port = domain via: direct }
Die Filterung am Paketfilter muß dann natürlich so konfiguriert sein, daß entsprechende Anfragen durchgelassen werden. ❏ Eigener Nameserver „Caching only“
Aufwendiger, aber eine saubere Lösung ist die Installation eines eigenen Nameservers. Normalerweise genügt ein einfacher Nameserver, der ausschließlich als lokaler Cache arbeitet. Nameserveranfragen von bereits gecachten Daten führen dann zu keinem Verbindungsaufbau. Die wesentlichen Optionen, die den Nameserver (hier Bind8) zu einem Caching-Only Nameserver machen, sind: options { forwarders { 193.101.111.10; 193.101.111.20; }; forward only; };
Im Bind-Jargon spricht man auch von einem Forward-Only-Nameserver, da ein Forward-Only Nameserver durchaus auch gleichzeitig ein Primary Nameserver sein kann, wenn er autorisierte Daten vorhält. Wir verwenden Caching-Only hier für einen Nameserver, dessen Aufgabe es in erster Linie ist, als Proxy DNS-Anfragen zu beantworten und für Rückfragen ausschließlich auf die Nameserver des Providers zuzugreifen, unabhängig davon, ob der Nameserver noch ein paar lokale Daten autorisiert zur Verfügung stellt oder nicht.
9.2.1
Paketfilterung
Für die Paketfilterung haben wir es mit ganz unterschiedlichen Sätzen an Filterregeln zu tun. Sehen wir uns Abbildung 9.3 an, dort sind die verschiedenen Sätze von Filterregeln skizziert: 1. Regeln für den Zugang zum Paketfilter selbst (Fernwartung, Syslog).
262
9.2 Einfacher Firewall
Abbildung 9.3: Paketfilterung für den „collapsed“ Firewall
2. Forwarding von internem Netzwerk in das DMZ (Fernwartung, Syslog, Proxy). 3. Forwarding vom DMZ in das Internet (Proxy). 4. Forwarding für den direkten Zugang vom internen Netzwerk zum Internet (z. B. DNS). Wir fassen diese 4 Gruppen auch in unserem Skript zusammen. Zunächst führen wir eine weitere Variable für den Port des später eingesetzten SOCKS-Server ein, dazu kommt ein zusätzliches Netzwerkinterface. Unser Paketfilter „fire“ hat nun Verbindung zu 3 Netzwerken: „Intern“, „DMZ“, und „Extern“. # ---------------------------------------------------------# special ports set p_high set p_ssh set p_socks
= 1024:65535 = 1000:1023 = 1080
# unprivileged ports # common ssh source ports # Socks Server Port
# ---------------------------------------------------------# interfaces set EXT = ippp0 set INT = eth0 set DMZ = eth1 set IF
= ( $INT $DMZ $EXT )
263
9 Firewalls bauen – Netzwerk
Die dynamischen, Interface-abhängigen Kernelparameter sind jetzt für drei Interfaces zu setzen. Setzt man sowieso immer alle gleich, dann kann man auch die Parameter im Unterverzeichnis all verwenden. Das Skript läßt sich dafür so weiterverwenden, wenn man set IF = all setzt: foreach echo echo echo echo echo end
Default Policy, Flushing und die Regeln für das Interface lo sind gegenüber dem letzten Abschnitt unverändert. Es folgt wie beim letzten Mal eine vorgezogene Regel für die Fernwartung via ssh. Die Regel gehört zwar zu dem Satz 1 (internes Netzwerk Paketfilter „fire“), wir wollen sie aber wieder so früh wie möglich einfügen, damit der Zugang via ssh zum Paketfilter vielleicht schon konfiguriert ist, wenn später im Skript ein Fehler auftritt, der zu einem Verbindungsabbruch führt.
Die userdefinierte Regelkette für Drop & Log und die Masquerading-Regel werden wieder unverändert übernommen. Nun folgen die Regeln gruppiert nach den verschiedenen Verbindungen, wie in Abbildung 9.3 skizziert. Gegenüber unseren früheren Skripten führen wir einige Änderungen durch. Zum einen sind für jeden der vier Sätze unterschiedliche Regeln für den Rückkanal erforderlich, zum anderen legen wir die Regel „bereits aufgebaute Verbindung, ausgehendes Paket“ mit der Regel für den Verbindungsaufbau des gewünschten Dienstes zusammen. Aus $IPTABLES -A INPUT ... -m state --state NEW -j ACCEPT
wird nun
264
9.2 Einfacher Firewall
$IPTABLES -A INPUT ... -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
Filterung Intern – Paketfilter „fire“ Die Regeln für den lokalen Zugang zum Paketfilter „fire“ sind im Prinzip bereits bekannt: # ========================================================== # PART V: Filterregeln für lokale Dienste # ========================================================== # ---------------------------------------------------------# Rückkanal: eingehende Pakete zu einer bestehenden Verbindung $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT -m state --state NEW,INVALID -j my_drop # ---------------------------------------------------------# ICMP $IPTABLES -A OUTPUT -p ICMP --icmp-type echo-request -j ACCEPT # ---------------------------------------------------------# SYSLOG $IPTABLES -A OUTPUT -o $INT -p UDP \ -m state --state NEW,ESTABLISHED,RELATED \ --sport syslog -d $loghost --dport syslog -j ACCEPT
Die Festlegung, von wo nach wo eine Verbindung verläuft, liefert für die drei übrigen Sätze wieder die Kombination aus FORWARD-Chain, Input- und OutputInterface: $IPTABLES -A FORWARD -i $INT -o $DMZ ... # hin $IPTABLES -A FORWARD -i $DMZ -o $INT ... # zurück
Filterung Intern – DMZ # ========================================================== # PART VI: Forwarding: Intern --> DMZ # ========================================================== # ---------------------------------------------------------# Rückkanal: eingehende Pakete zu einer bestehenden Verbindung
265
9 Firewalls bauen – Netzwerk
$IPTABLES -A FORWARD -i $DMZ -o $INT \ -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i $DMZ -o $INT \ -m state --state NEW,INVALID -j my_drop # ---------------------------------------------------------# ICMP $IPTABLES -A FORWARD -i $INT -o $DMZ \ -p ICMP --icmp-type echo-request -j ACCEPT
Der Rückkanal aus dem DMZ bedarf keiner besonderen Erläuterung, ein Ping in das eigene DMZ ist ganz nützlich. Jetzt kommt die Gretchenfrage: was ist mit der Namensauflösung? Wir behandeln zunächst die Situation, in der kein eigener Nameserver zur Verfügung steht. Die DNS-Abfragen erfolgen dann entweder über das SOCKS-Protokoll, oder direkt nach draußen, wenn es gar nicht anders geht. DNS-Verbindungen in das DMZ hinein sind so nicht erforderlich. # ---------------------------------------------------------# SOCKS $IPTABLES -A FORWARD -i $INT -o $DMZ \ -m state --state NEW,ESTABLISHED,RELATED \ -p TCP --sport $p_high --dport $p_socks -j ACCEPT $IPTABLES -A FORWARD -i $INT -o $DMZ \ -m state --state NEW,ESTABLISHED,RELATED \ -p UDP --sport $p_high --dport $p_high -j ACCEPT
Die erste Regel zum Port $p_socks$ erlaubt generelle SOCKS-Verbindungen in das DMZ. Die zweite Regel ist notwendig, wenn für SOCKS als resolveprotocol UDP verwendet wird. Beide Regeln kann man natürlich auch ausschließlich auf den SOCKS-Server einschränken. Hier kann jeder beliebige SOCKS-Server im DMZ erreicht werden. Es bleiben Dienste mit eigenem „Proxy“ im DMZ. In unserer Konfiguration ist das E-Mail (SMTP und POP3). Auf dem Proxy-Server befindet sich gleichzeitig ein Mailserver, der die E-Mails für interne Clients via POP3 zur Verfügung stellt und E-Mails via SMTP vom Client entgegennimmt und nach draußen zum Mailserver des Providers weiterleitet:
266
9.2 Einfacher Firewall
# ---------------------------------------------------------# SMTP, POP3 $IPTABLES -A -m -p -j
Eine weitere Abwägung ist, ob man Ident-Abfragen zulassen will oder nicht. Wer den SOCKS-Server so konfiguriert hat, daß er keine User-Autorisierung durchführt (in kleineren Umgebungen kann man durchaus darauf verzichten), benötigt keine Ident-Lookups. Auch andere Proxies können mitunter so konfiguriert werden, daß keine Ident-Lookups durchgeführt werden (z. B. ftp-proxy von SuSE). Außerdem ist zu beachten, daß Ident-Abfragen in der Regel nur mit UnixSystemen funktionieren. Windows-Rechner haben defaultmäßig keinen IdentDaemon und beantworten solche Anfragen nicht. Zu beachten ist bei Ident-Abfragen, daß diese vom Server initiiert werden, nicht vom Client. Die Richtung ist also entgegengesetzt. # # # # # # # # # # # # # # # # #
---------------------------------------------------------ident: Beispiel für reject $IPTABLES -A FORWARD -i $DMZ \ -p TCP --dport auth --syn -j REJECT ---------------------------------------------------------ident: Beispiel für accept von Ident-Abfragen $IPTABLES -A FORWARD -i $DMZ -o $INT \ -m state --state NEW,ESTABLISHED,RELATED \ -p TCP --sport $p_high --dport auth -j ACCEPT $IPTABLES -A FORWARD -i $INT -o $DMZ \ -m state --state ESTABLISHED,RELATED \ -p TCP --dport $p_high --sport auth -j ACCEPT
Will man Ident-Abfragen des SOCKS-Servers erlauben, muß man daran denken, daß unser Konzept mit den generell freigeschalteten Antwortpaketen oben nur vom DMZ in das interne Netzwerk erlaubt ist. Hier handelt es sich aber um eine
267
9 Firewalls bauen – Netzwerk
Verbindung, die in die Gegenrichtung läuft. Deshalb benötigen wir die zweite Regel, die Pakete zu bestehenden Ident-Verbindungen auch wieder aus dem internen Netzwerk in das DMZ zurück passieren läßt. Es fehlt nun noch die Fernwartung via ssh vom Internen Netzwerk in das DMZ: # ---------------------------------------------------------# SSH $IPTABLES -A FORWARD -i $INT -o $DMZ \ -m state --state NEW,ESTABLISHED,RELATED \ -p TCP --sport $p_ssh --dport ssh -j ACCEPT
Filterung DMZ – Extern Wir beginnen zunächst wieder mit dem Rückkanal für bereits bestehende Verbindungen und ICMP Echo Request: # ========================================================== # PART VII: Forwarding: DMZ --> Extern # ========================================================== # ---------------------------------------------------------# Rückkanal: eingehende Pakete zu einer bestehenden Verbindung $IPTABLES -A FORWARD -i $EXT -o $DMZ \ -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i $EXT -o $DMZ \ -m state --state NEW,INVALID -j my_drop # ---------------------------------------------------------# ICMP $IPTABLES -A FORWARD -i $DMZ -o $EXT \ -p ICMP --icmp-type echo-request -j ACCEPT
Ausgehende DNS-Verbindungen lassen wir aus dem DMZ zu: # ---------------------------------------------------------# DNS foreach ns ( $NS ) $IPTABLES -A FORWARD -i $DMZ -o $EXT \ -m state --state NEW,ESTABLISHED,RELATED \ -p UDP --sport $p_high -d $ns --dport domain \
Wir schränken hier die Namensauflösung innerhalb des DMZ nicht ein. Andere Proxies können dann DNS direkt (ohne SOCKS) benutzen. An dieser Stelle sei darauf hingewiesen, daß der Mailserver nicht unbedingt DNS benötigt. SMTP läßt sich bei vielen MTA’s (z. B. Postfix) so konfigurieren, daß kein DNS benötigt wird, schließlich verwenden wir ja den Mailserver des Providers als Relayhost und überlassen diesem die Zustellung. Die Abholung von E-Mails beim Provider durch den Mailserver kann auch über ein „socksified“ Programm durchgeführt werden (z. B. fetchmail), das dann die Namensauflösung über das SOCKS-Protokoll und damit den SOCKS-Server durchführt. Die Filterregeln für die Abholung von E-Mails durch den internen Mailserver: # ---------------------------------------------------------# SMTP, POP3 $IPTABLES -A -m -p -j
Alle benötigten Dienste, die wir bisher für die Clients direkt freigeschaltet hatten (HTTP, FTP, usw.), müssen wir nun für den SOCKS-Server freischalten. Zunächst für die Protokolle HTTP/HTTPS: # ---------------------------------------------------------# HTTP $IPTABLES -A -m -p -j
Hier wird noch einmal explizit angegeben, daß nur der SOCKS-Server HTTP/HTTPS-Verbindungen aufbauen darf. Dieselben Spielregeln gelten dann auch für FTP-Sitzungen: # ---------------------------------------------------------# ftp, out, control connection $IPTABLES -A -m -p -j
Eine ssh-Verbindung aus dem DMZ heraus selbst sollte nicht erfolgen. Aus Sicherheitsgründen sollte eine Fernwartung immer aus dem sichersten Netzwerk (internes Netzwerk) heraus durchgeführt werden. Notwendig könnte aber eine ssh-Verbindung aus dem DMZ heraus werden, wenn ssh via SOCKS ausgeführt werden soll. Die Filterregel dazu würde dann so aussehen: # ---------------------------------------------------------# SSH, nur für den SOCKS-Server $IPTABLES -A -m -p -d
Bei der Verwendung von ssh via SOCKS sind einige Spielregeln zu beachten. Sogenannte s-Bit-Programme lassen sich nicht per Laufzeit socksifizieren. Entweder muß das Programm explizit gegen die Library ldsocks gelinkt werden, oder man muß das s-Bit entfernen, damit man per Laufzeit ldsocks mit ein-
270
9.2 Einfacher Firewall
binden kann (Verwendung von socksify). Dann wiederum kann man keine privilegierten Ports als Source-Ports mehr verwenden. Der Aufruf von ssh sieht dann so aus: socksify slogin -v -P host.my.domain
Das -P sorgt dafür, daß der ssh-Client unprivilegierte Source-Ports verwendet. Das schließt die Verwendung von RhostsAuthentication und RhostsRSAAuthentication aus, außerdem muß die Gegenseite einen Verbindungsaufbau von unprivilegierten Ports zulassen. Filterung für direkte Verbindungen: Intern – Extern Eine direkte Verbindung über den Paketfilter hinweg ist genau genommen ein Rückschritt gegenüber der Verwendung von Proxies. Sicher kann man auch ein gemischtes Doppel fahren, d. h., einige Dienste direkt freischalten, andere ausschließlich über den Proxy zulassen. Die Entscheidung, wer wieviel an Sicherheit benötigt, hängt immer von den jeweiligen Anfordernissen ab und muß deshalb vom Leser selbst entschieden werden. Der allgemeine Grundsatz der ITSicherheit – „soviel wie nötig, aber so wenig wie möglich“ – hat auch hier seine Gültigkeit. Mit anderen Worten: alles, was über einen Proxy durchgeführt werden kann, sollte auch darüber durchgeführt werden. Direkte Verbindungen nur, wenn es nicht anders geht. Man sollte sich vor der Konfiguration alle direkten Verbindungen definieren und schriftlich fixieren. Die folgenden Filterregeln sollen direkte Namensauflösungen über die Nameserver des Internet-Providers erlauben, zusätzlich soll eine direkte ssh-Verbindung zu einem befreundeten Netzwerk erlaubt sein: # ========================================================== # PART VIII: Forwarding: Intern --> Extern, direkt # ========================================================== # ---------------------------------------------------------# Rückkanal: eingehende Pakete zu einer bestehenden Verbindung $IPTABLES -A FORWARD -i $EXT -o $INT \ -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i $EXT -o $INT \ -m state --state NEW,INVALID -j my_drop # ---------------------------------------------------------# ICMP
271
9 Firewalls bauen – Netzwerk
$IPTABLES -A FORWARD -i $INT -o $EXT \ -p ICMP --icmp-type echo-request -j ACCEPT # ---------------------------------------------------------# DNS foreach ns ( $NS ) $IPTABLES -A FORWARD -i $INT -o $EXT \ -m state --state NEW,ESTABLISHED,RELATED \ -p UDP --sport $p_high -d $ns --dport domain \ -j ACCEPT $IPTABLES -A -m -p -j end
Direkte Pings zuzulassen ist ebenfalls zweckmäßig, da sich das ICMP-Protokoll nicht „socksifizieren“ läßt. Am Ende des Skriptes fügen wir noch eine Regel ein, die Ident-Abfragen von außen generell verhindert. Dabei spielt es keine Rolle, wohin die Abfrage gehen soll: # # # #
Vollständiges Skript für einen einfachen Firewall #!/bin/tcsh # Firewallscript für fire # ========================================================== # PART I: Variablen # ========================================================== modprobe ip_tables modprobe ip_conntrack set IPTABLES = /usr/sbin/iptables # ---------------------------------------------------------# special ports set p_high set p_ssh set p_socks
= 1024:65535 = 1000:1023 = 1080
# unprivileged ports # common ssh source ports # Socks Server Port
# ---------------------------------------------------------# interfaces set EXT = ippp0 set INT = eth0 set DMZ = eth1 set IF
= ( $INT $DMZ $EXT )
# ---------------------------------------------------------# ip hosts set NS
# ========================================================== # PART V: Filterregeln für lokale Dienste # ========================================================== # ---------------------------------------------------------# Rückkanal: eingehende Pakete zu einer bestehenden Verbindung $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT -m state --state NEW,INVALID -j my_drop # ---------------------------------------------------------# ICMP
275
9 Firewalls bauen – Netzwerk
$IPTABLES -A OUTPUT -p ICMP --icmp-type echo-request -j ACCEPT # ---------------------------------------------------------# SYSLOG $IPTABLES -A OUTPUT -o $INT -p UDP \ -m state --state NEW,ESTABLISHED,RELATED \ --sport syslog -d $loghost --dport syslog -j ACCEPT # ========================================================== # PART VI: Forwarding: Intern --> DMZ # ========================================================== # ---------------------------------------------------------# Rückkanal: eingehende Pakete zu einer bestehenden Verbindung $IPTABLES -A FORWARD -i $DMZ -o $INT \ -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i $DMZ -o $INT \ -m state --state NEW,INVALID -j my_drop # ---------------------------------------------------------# ICMP $IPTABLES -A FORWARD -i $INT -o $DMZ \ -p ICMP --icmp-type echo-request -j ACCEPT # ---------------------------------------------------------# SOCKS $IPTABLES -A FORWARD -i $INT -o $DMZ \ -m state --state NEW,ESTABLISHED,RELATED \ -p TCP --sport $p_high --dport $p_socks -j ACCEPT $IPTABLES -A FORWARD -i $INT -o $DMZ \ -m state --state NEW,ESTABLISHED,RELATED \ -p UDP --sport $p_high --dport $p_high -j ACCEPT # ---------------------------------------------------------# SMTP, POP3 $IPTABLES -A FORWARD -i $INT -o $DMZ \ -m state --state NEW,ESTABLISHED,RELATED \
$IPTABLES -A FORWARD -i $EXT \ -p TCP --dport auth --syn -j REJECT # ---------------------------------------------------------# Ausputzer: Rest sperren, loggen $IPTABLES -A INPUT -j my_drop $IPTABLES -A FORWARD -j my_drop $IPTABLES -A OUTPUT -j my_drop
280
9.2 Einfacher Firewall
9.2.2
Proxy-Konfiguration (SOCKS)
Der Paketfilter ist fertig, was nun noch fehlt, ist die Konfiguration des Proxy. Dante SOCKS wurde bereits im Abschnitt 6.2 ausführlich beschrieben. Wir gehen deshalb an dieser Stelle nur auf eine Konfiguration ein, die auf die bisher aufgezeigte Firewall-Konfiguration paßt. SOCKS-Client Zunächst betrachten wir die Konfigurationsdatei /etc/socks.conf des Client. Generell ist zu beachten, daß es sich um die Konfiguration von SOCKS handelt. Die entsprechenden Regeln werden nur beachtet, wenn auch tatsächlich die SOCKS-Library benutzt wird, und die Paketfilterregeln entsprechend benötigte Dienste auch erlauben (insbesondere alle trotz SOCKS direkt angesprochenen Dienste sind hiervon betroffen). logoutput: syslog resolveprotocol: udp # default # (1) direkte Verbindung zu den Nameservern # route { # from: 192.168.1.0/24 # to: 193.101.111.0/24 port = domain # via: direct # } # (2) loopback = hostinterne Verbindungen route { from: 0.0.0.0/0 to: 127.0.0.0/8 via: direct command: connect udpassociate # everything but bind, bind confuses us. } # (3) Internes Netzwerk route { from: 0.0.0.0/0 to: 192.168.1.0/24 via: direct } # (4) Sonstiges --> SOCKS-Server route {
281
9 Firewalls bauen – Netzwerk
from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.168.2.2 port = 1080 protocol: tcp udp proxyprotocol: socks_v4 socks_v5 method: none } # (5) dito, nur mit Namensangabe route { from: 0.0.0.0/0 to: . via: 192.168.2.2 port = 1080 protocol: tcp udp proxyprotocol: socks_v4 socks_v5 method: none }
1. Wird eine direkte Verbindung zu einem Nameserver benötigt, muß die dazugehörige Regel als erste konfiguriert werden. Hier gilt sie für die Nameserver beim Provider (bitte durch die Nameserver des eigenen Providers ersetzen). Mit direct umgeht der SOCKS-Client vollständig den SOCKSServer. Wird die Route benutzt, muß natürlich auch der Paketfilter für den Firewall entsprechend konfiguriert werden. 2. Verbindungen von lokalen Prozessen (loopback) sollten natürlich direkt, das heißt, ohne Umweg über den SOCKS-Server erfolgen. 3. Verbindungen innerhalb des lokalen Netzwerkes sollen ebenfalls ohne Proxy durchgeführt werden. 4. Alle anderen Verbindungen erfolgen über den SOCKS-Server. Hier ist keine Authentifikation erforderlich. 5. Dieselbe Regel noch einmal, aber ohne IP-Adresse, falls der Client aus irgendwelchen Gründen einen Domain-Namen nicht auflösen kann. Vereinfacht gesagt, läßt sich auf der Client-Seite nur konfigurieren, ob SOCKS verwendet wird oder nicht. Man sollte darauf keine Sicherheit aufbauen, z. B. indem man einige Clients mit direkten, andere mit indirekten (via Proxy) Verbindungen ausstattet. Wer was darf, sollte ausschließlich über die Paketfilterung und den SOCKS-Server geregelt werden.
282
9.2 Einfacher Firewall
SOCKS-Server logoutput: syslog /var/log/dante internal: 192.168.2.2 port = 1080 external: 192.168.2.2 method: username none #rfc931 user.privileged: sockd user.notprivileged: sockd compatibility: sameport # ----------------------------------------------------------# welche Clients # (1) erlaubte Clients client pass { from: 192.168.1.0/24 port 1-65535 to: 0.0.0.0/0 method: none } # (2) keine sonstigen Clients erlaubt client block { from: 0.0.0.0/0 to: 0.0.0.0/0 log: connect error } # ----------------------------------------------------------# welche Dienste # (3) loopback am Server ??? block { from: 0.0.0.0/0 to: 127.0.0.0/8 log: connect error } # (4) alle Bind Requests block { from: 0.0.0.0/0 to: 0.0.0.0/0 command: bind log: connect error
283
9 Firewalls bauen – Netzwerk
} # (5) Rückkanal für bestimmte Antwortpakete pass { from: 0.0.0.0/0 to: 192.168.1.0/24 command: bindreply udpreply log: connect error } # (6) Namensauflösung für alle internen Clients pass { from: 192.168.1.0/24 to: 0.0.0.0/0 port = domain log: connect error method: none } # (7) alle internen Clients dürfen surfen pass { from: 192.168.1.0/24 to: 0.0.0.0/0 port = http log: connect error method: none } # (8) nur ein Client darf mehr ... pass { from: 192.168.1.9/32 to: 0.0.0.0/0 protocol: tcp udp } # (9) Ausputzer: alles sonstige sperren block { from: 0.0.0.0/0 to: 0.0.0.0/0 log: connect error }
Die Konfigurationsdatei für den SOCKS-Server sockd besteht grob aus drei Teilen: ❏ generelle Einstellungen, ❏ Direktiven die festlegen, welche Clients den Server benutzen dürfen, und
zuletzt ❏ Direktiven, die festlegen, was die Clients dürfen.
1. Zunächst die erlaubten Clients. 2. Alle anderen Clients werden abgewiesen.
284
9.2 Einfacher Firewall
3. Versuche, am Server eine Loopback-Adresse zu benutzen, werden abgelehnt. 4. Generell keine Bind-Requests (binden eines Sockets für Serverdienste, siehe Abschnitt 6.2). 5. Bestimmte Verbindungen benötigen eine Antwort auf Bind-Request. Solche Reply-Pakete sind nicht zu vergleichen mit einer normalen Verbindung, sondern gehören zum Socketaufbau. 6. Alle internen Clients dürfen eine Namensauflösung durchführen. 7. Alle internen Clients dürfen HTTP-Verbindungen aufbauen. 8. Ein Client darf via SOCKS im Prinzip alles (vorausgesetzt, der Paketfilter erlaubt dem SOCKS-Server die entsprechenden Dienste). 9. Eine Ausputzer-Regel zum Schluß. Zwar ist alles verboten, was nicht explizit erlaubt ist, aber hier wird zusätzlich geloggt, was von dieser Regel abgefangen wird. Damit ist unser Proxy konfiguriert und kann in Betrieb gehen. Auf die Konfiguration des Mailservers gehen wir hier nicht ein, da der Mailserver in einem „collapsed“ Firewall einen ganz normalen Mailserver darstellt. Die Beschreibung eines Mailservers würde den Rahmen dieses Buches sprengen. Grundsätzliche Überlegungen zum Mailserver finden sich in Abschnitt 7.1.1. Die Verwendung von SOCKS setzt einen veränderten Client voraus. Zwar wird einem das durch die Verwendung von zusätzlichen dynamischen Libraries zur Laufzeit leicht gemacht. Aber nicht jeder Client spielt mit. Eine Alternative dazu ist die Verwendung von transparenten Proxies. Transparente Proxies sind applikationsspezifische Proxies, das heißt, für jede Anwendung muß ein eigener Proxy eingerichtet und zur Verfügung gestellt werden. Wir gehen im Abschnitt 9.3 beim klassischen Firewall noch darauf ein. Was bleibt, ist die Einrichtung eines Caching-Only Nameservers, um zumindest einige Probleme, die mit SOCKS auftreten können, zu umgehen.
9.2.3
Caching-Only Nameserver
Der am weitesten verbreitete Nameserver ist wohl Bind. Bind hat in letzter Zeit immer wieder Negativ-Schlagzeilen gemacht: es wurden Exploits bekannt, mit denen man auf einem Server mit einem standardmäßig konfiguriertem Bind eine root-Shell erhalten konnte. Das hat die Internet-Gemeinde in helle Aufregung versetzt – ein Nameserver mit Bind lief ja fast überall. Glücklicherweise wurden die schlimmsten Fehler schnell gefixt, und gegen viele andere Angriffsszenarien hilft eine saubere, sichere Konfiguration. Nichtsdestotrotz bedeutet ein laufender Nameserver ein höheres Sicherheitsrisiko als gar
285
9 Firewalls bauen – Netzwerk
kein Nameserver. Der Administrator ist daher aufgefordert, regelmäßig die einschlägigen Sicherheitsinformationen zu lesen und bei möglicherweise auftretenden Sicherheitsproblemen schnellstmöglich Abhilfe zu schaffen. Trotzdem ist der Einsatz eines Caching-Only Nameservers bei Dialin-Verbindungen hilfreich. Daten, die einmal im Cache liegen, müssen nicht alle Nase lang erneut im Internet abgefragt werden – vorausgesetzt, bei der Konfiguration des Nameservers wurde kein Fehler gemacht. Hier eine einfache Konfigurationsdatei /etc/named.conf für Bind8: # ---------------------------------------------------# /etc/named.conf # ---------------------------------------------------options { directory "/var/named"; pid-file "/var/run/named.pid"; datasize default; stacksize default; coresize default; files unlimited; recursion yes; forward only; forwarders { 193.101.111.10; 193.101.111.20; }; allow-query { 192.168.1.0/24; 192.168.2.0/24; 127.0.0.0/8 }; allow-transfer { none; }; # query-source address * port 53; ndots:1; };
Neben einigen Standard-Optionen sind für die Sicherheit im wesentlichen folgende Optionen wichtig:
286
9.2 Einfacher Firewall
❏ forward only:
Alle Anfragen, die nicht lokal beantwortet werden können, werden an die Forwarders weitergereicht. Geben alle Forwarders zusammen keine erschöpfende Auskunft, versucht der Nameserver nicht, weitere Nameserver zu befragen. ❏ forwarders:
Die Nameserver, die ausschließlich den Nameserver mit einer Antwort versorgen sollen. Hier sind das die vom Provider vorgegebenen Nameserver. ❏ allow-query:
Wir erlauben nur dem internen Hosts (und loopback), den Nameserver zu befragen. ❏ allow-transfer:
Transfers komplett unterbinden. ❏ query-source:
Bind8 benutzt als Source-Port unprivilegierte Ports auch für UDP. Mit QuerySource kann man auch andere Ports angeben. Source-Port 53 wurde früher für Server-Server-Verbindungen benutzt. Falls ein Firewall entsprechend eingestellt ist, kann man mit der (auskommentierten) Zeile wieder das alte Verhalten herstellen. Die minimale Zoneninformation besteht aus der root „.“, localhost und den PTR-Einträgen für localhost: zone "." IN { type hint; file "root.hint"; }; zone "localhost" IN { type master; file "localhost.zone"; check-names fail; allow-update { none; }; }; zone "0.0.127.in-addr.arpa" IN { type master; file "127.0.0.zone"; check-names fail; allow-update { none; }; };
Die Dateien localhost.zone, 127.0.0.zone, sowie die Datei root.hint werden bei Bind mitgeliefert. Unter bestimmten Umständen kann es sinnvoll
287
9 Firewalls bauen – Netzwerk
sein, die lokalen Hosts ebenfalls im Nameserver zu konfigurieren, indem man den Nameserver als Primary konfiguriert. Beispiel: zone "my.domain" IN { type master; file "my.domain"; allow-update { none; }; allow-transfer { none; }; }; zone "1.168.192.in-addr.arpa" IN { type master; file "192.168.1.zone"; allow-update { none; }; allow-transfer { none; }; };
Auf die Dateien selbst und damit die ausführliche Konfiguration eines Nameserver gehen wir hier nicht ein, das würde wiederum den Rahmen dieses Buches sprengen. Neben einigen Beispielkonfigurationen und der mitgelieferten Dokumentation gibt es für Linux einen DNS-HOWTO (SuSE Linux: in den Howtos enthalten). Die Homepage für Bind, die neben der Originaldokumentation eine Vielzahl weiterer Links zu dem Thema enthält, ist http://www.isc.org/ Zur Abrundung fehlen noch ein paar Dinge: zum einen können alle lokalen Hosts auch in die Datei /etc/hosts eingetragen werden (auf jedem Client). Damit die Datei dann auch verwendet wird, muß in /etc/nsswitch.conf folgendes stehen: # /etc/nsswitch.conf ... hosts: files dns ...
Ferner muß der Resolver am Client angewiesen werden, welchen Nameserver er zu benutzen hat: search my.domain nameserver 192.168.2.2
Paketfilterung Bisher lief die Namensauflösung für die Clients zwischen dem internem Netzwerk und dem DMZ über das SOCKS-Protokoll. Wenn wir direkt auf einen
288
9.2 Einfacher Firewall
Nameserver im DMZ zugreifen wollen, müssen wir die Paketfilterung zwischen internem Netzwerk und dem DMZ ergänzen: ... set INT_NS ...
= 192.168.2.2
# ========================================================== # PART VI: Forwarding: Intern --> DMZ # ========================================================== ... # ---------------------------------------------------------# DNS foreach ns ( $INT_NS ) $IPTABLES -A FORWARD -i $INT -o $DMZ \ -m state --state NEW,ESTABLISHED,RELATED \ -p UDP --sport $p_high -d $ns --dport domain \ -j ACCEPT $IPTABLES -A -m -p -j end ...
SOCKS-Konfiguration Zu guter Letzt muß natürlich auch noch dem SOCKS-Client mitgeteilt werden, daß er jetzt direkt auf den Nameserver zugreifen kann, anstatt über das SOCKSProtokoll und den SOCKS-Server zu gehen: route { from: 0.0.0.0/0 to: 192.168.2.2/32 port = domain via: direct }
Der Eintrag muß auf jedem Client in /etc/socks.conf als erster route-Eintrag stehen.
289
9 Firewalls bauen – Netzwerk
9.2.4
Feste IP-Adresse
Die in diesem Abschnitt vorgestellte Konfiguration hat ausschließlich internen Clients gedient. Für Serverdienste, d. h., wenn andere unsere Server aus dem Internet heraus erreichen wollen, eignet sich eine Konfiguration mit dynamischem IP-Zugang nicht. Es gibt zwar Lösungen, von denen ist aber abzuraten. Provider verbinden nun mal mit dynamischen IP-Adressen fast immer eine ausschließliche Client-seitige Nutzung des Internet, und wer darüber eigene Dienste anbietet, sollte sich die AGBs des Providers sehr genau durchlesen. Es gibt aber auch Angebote von Providern, die explizit für die Bereitstellung von Serverdiensten gedacht sind und eine feste IP-Adresse beinhalten. Die Konfiguration ist dann eins zu eins verwendbar. Anstatt von Masquerading verwendet man Source-NAT: # ========================================================== # PART IV: Source-NAT, generell bestehende Verbindungen # ========================================================== # ---------------------------------------------------------# Source-NAT $IPTABLES -t nat -A POSTROUTING -o $EXT -j SNAT --to $fixed_ip echo "1" > /proc/sys/net/ipv4/ip_forward
# wieder einschalten
Dabei ist $fixed_ip die feste, vom Provider vorgegebene IP-Adresse. Für Serverdienste ist natürlich noch einiges zusätzlich zu konfigurieren. Darauf gehen wir aber erst im nächsten Abschnitt beim Firewall mit Grenznetz ein. Das dort Gesagte läßt sich auch hier mit dem „collapsed“ Firewall verwenden.
9.3 Firewall mit Grenznetz Neben den bisher vorgestellten „einfachen“ Firewall-Varianten darf in einem Buch über Firewalls der klassische Firewall mit einem Grenznetz (Demilitarized Zone, DMZ), zwei Paketfiltern und einem oder mehreren Single-Homed BastionHosts natürlich nicht fehlen (siehe auch Abschnitt 4.4 und Abbildung 4.9). Im letzten Abschnitt über den „collapsed“-Firewall haben wir schon erwähnt, daß es zwischen einem „collapsed“-Firewall und einem klassischen Firewall mit Grenznetz keine großen Unterschiede in der Anwendung gibt. Die Unterschiede finden sich eher in der Sicherheit wieder. Demnach läßt sich auch alles aus dem letzten Abschnitt fast eins zu eins übernehmen. Nur die Paketfilterung wird auf zwei getrennte, paketfilternde Router verteilt.
290
9.3 Firewall mit Grenznetz
Die Firewall-Konfigurationen in diesem Buch sind als Beispiele zu betrachten. Man kann es so umsetzen, oder auch nicht. Man kann aber auch Elemente aus einem vorgestellten Beispiel mit einer anderen Firewall-Konfiguration kombinieren. Oder eigene Erweiterungen einbauen. In diesem Sinne ist auch der Firewall mit Grenznetz, den wir hier vorstellen, nicht „der“ Firewall mit Grenznetz schlechthin, sondern nur ein mögliches, vielleicht auch typisches Beispiel. Als Ausgangspunkt enthält dieser Firewall einige wichtige Grundelemente, kann aber auch wie ein Baukasten leicht auf eigene Belange angepaßt, abgeändert oder erweitern werden. Zunächst soll eine „Standard“-Konfiguration vorgestellt werden, im wesentlichen ist das eine leicht angepaßte Variante unseres „collapsed“-Firewalls. Danach folgen einige Bausteine, die den Firewall mit DMZ ergänzen könnten. Grundlage für den Firewall mit DMZ ist die Konfiguration, wie sie in Abbildung 9.4 dargestellt ist. Die Rahmenbedingungen für die Basisvariante unseres Firewalls mit DMZ sind: ❏ „iro“ und „exa“ sind reine Paketfilter und bieten sonst keine weiteren Dien-
ste an (außer Fernwartungszugang).
Abbildung 9.4: Firewall mit zwei Paketfiltern, Grenznetz und Single Homed Bastion Host
291
9 Firewalls bauen – Netzwerk
❏ Es steht genau eine statische IP-Adresse zur Verfügung. Stehen statische IP-
Adressen für das gesamte DMZ zur Verfügung, ist die Konfiguration etwas einfacher und aus der vorgestellten Konfiguration ableitbar (DNAT entfällt, SNAT wird vom äußeren Paketfilter auf den inneren verlagert). ❏ Die Anbindung erfolgt via ISDN. Für den Firewall spielt es aber keine Rol-
le, ob es sich um eine Standleitung, eine DSL-Strecke oder um eine ISDNVerbindung handelt. ❏ Für DNS-Dienste verwenden wir einen „Caching-Only“-Nameserver in der
Demilitarized Zone. Die Konfiguration wurde bereits im Abschnitt 9.2.3 ausführlich beschrieben, wir gehen hier deshalb nicht weiter darauf ein. ❏ Alle Dienste sollen wieder über Proxy-Dienste abgewickelt werden. Die ein-
zigen Dienste, die wir direkt zulassen sind ssh und Ping (ausgehend). ❏ E-Mail wird ebenfalls wieder über einen Mailserver zur Verfügung gestellt.
Diesmal ist der Mailserver aber via SMTP erreichbar, d. h., der Mailserver holt die Daten via SMTP (SMTP verfügt über den Mechanismus „Remote Message Queue Starting“). Damit entfällt die POP3-Verbindung zwischen lokalem Mailserver und dem Provider. ❏ Generisches Proxying wird über SOCKS zur Verfügung gestellt. Auf die
SOCKS-Konfiguration gehen wir hier allerdings nicht noch einmal ein, dazu sei auf Abschnitt 9.2 verwiesen. ❏ Zur Fernwartung soll wieder auf allen, am DMZ beteiligten Systemen ssh
eingesetzt werden, und alle diese Systeme sollen die Möglichkeit erhalten, Syslog-Nachrichten an einen internen Host zu senden. Die Basiskonfiguration wird später dann ergänzt um Serverbausteine (wir stellen eigene Serverdienste zur Verfügung) und applikationsspezifische Proxies.
9.3.1
Paketfilterung
Die hier betrachtete Paketfilterung unterscheidet sich prinzipiell nicht von der Paketfilterung in Abschnitt 9.2 nach Anpassung der Interfaces. Betrachten wir dazu noch einmal die Abbildung 9.3. Die vier Sätze von Filterregeln werden aufgeteilt: ❏ Satz 1 (Zugang zu den Paketfiltern) bleibt auf beiden Paketfiltern unverän-
dert. Damit der äußeren Router auch erreichbar ist, muß der Filtersatz 2 (internes Netz – DMZ) gegebenenfalls entsprechen ergänzt werden (z. B. für den Syslog). ❏ Filtersatz 2 findet sich nur auf dem inneren Paketfilter, ❏ Filtersatz 3 nur auf dem äußeren Paketfilter.
292
9.3 Firewall mit Grenznetz
❏ Ist direktes Routing erforderlich (Filtersatz 4), sind die Regeln auf beiden
Paketfiltern erforderlich und nahezu identisch. Auf den ersten Blick sehen die folgenden Paketfilterregeln genauso aus wie für den „collapsed“-Firewall. Die Anordnung mit zwei getrennten Paketfiltern bringt jedoch einen kleinen, aber prinzipiellen Unterschied mit sich. Pakete, die über das (aus Sicht des inneren Paketfilters) externe Interface $DMZ weitergeleitet werden, können nicht alleine über das externe Interface identifiziert werden. Es könnten Pakete sein, die nur in das DMZ wollen, aber auch Pakete, die direkt nach draußen geroutet werden sollen. Für diese Unterscheidung ist nun zusätzlich die Angabe einer Ziel- (ausgehend) oder Quell-Adresse (eingehend) erforderlich: # Forwarding ins DMZ $IPTABLES -A FORWARD -i $INT -o $DMZ -d $DMZ_NET ... # hin $IPTABLES -A FORWARD -i $DMZ -o $INT -s $DMZ_NET ... # zurück # Forwarding nach Extern $IPTABLES -A FORWARD -i $INT -o $DMZ -d ! $DMZ_NET ... # hin $IPTABLES -A FORWARD -i $DMZ -o $INT -s ! $DMZ_NET ... # zurück
Die Angabe der IP-Adresse bezieht sich auf das nicht eindeutige Interface, also $DMZ. Für den äußeren Paketfilter sieht das ähnlich aus, nur ist hier das nicht eindeutige Interface $DMZ das interne Interface (aus der Sicht des äußeren Routers): # Forwarding aus dem DMZ $IPTABLES -A FORWARD -i $DMZ -o $EXT -s $DMZ_NET ... # hin $IPTABLES -A FORWARD -i $EXT -o $DMZ -d $DMZ_NET ... # zurück # Forwarding aus dem internen Netz $IPTABLES -A FORWARD -i $DMZ -o $EXT -s $INT_NET ... # hin $IPTABLES -A FORWARD -i $EXT -o $DMZ -d $INT_NET ... # zurück
DNS wird auf dem innerem Paketfilter „iro“ ausschließlich zum internen Nameserver zugelassen, der äußere Paketfilter schränkt DNS auf Verbindungen zwischen dem Nameserver des Providers und dem internen Nameserver ein. Während auf dem inneren Paketfilter nach wie vor keine eingehenden Verbindungen benötigt werden (Ausnahme: Syslog-Messages aus dem DMZ), muß die Filterung auf dem externen Paketfilter angebotene Serverdienste berücksichtigen. Das bedeutet, es können nicht mehr generell eingehende Pakete mit State NEW abgelehnt werden. Außerdem muß ein passsender Rückkanal für ausgehende
293
9 Firewalls bauen – Netzwerk
Pakete, die zu einer eingehenden Verbindung gehören, ebenfalls offengehalten werden: # ---------------------------------------------------------# Rückkanal: ausgehende Pakete zu einer bestehenden # eingehenden Verbindung (Serverdienste) $IPTABLES -A FORWARD -i $DMZ -o $EXT -s $DMZ_NET \ -m state --state ESTABLISHED,RELATED -j ACCEPT
Die Regel ist sehr bequem, aber auch sehr frei. Alternativ kann man statt dieser Regel für jeden Serverdienst eine passende Rückregel definieren, die auch noch Protokoll, Ports und gegebenenfalls IP-Adressen berücksichtigt. Skript für den inneren Paketfilter „iro“ #!/bin/tcsh # # Firewallskript für iro # ========================================================== # PART I: Variablen # ========================================================== modprobe ip_tables modprobe ip_conntrack set IPTABLES = /usr/sbin/iptables # ---------------------------------------------------------# special ports set p_high set p_ssh set p_socks
= 1024:65535 = 1000:1023 = 1080
# unprivileged ports # common ssh source ports # Socks Server Port
# ---------------------------------------------------------# interfaces set INT = eth0 set DMZ = eth1 set IF
# ========================================================== # PART V: Filterregeln für lokale Dienste # ========================================================== # ---------------------------------------------------------# Rückkanal: eingehende Pakete zu einer bestehenden Verbindung
296
9.3 Firewall mit Grenznetz
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT -m state --state NEW,INVALID -j my_drop # ---------------------------------------------------------# ICMP $IPTABLES -A OUTPUT -p ICMP --icmp-type echo-request -j ACCEPT # ---------------------------------------------------------# SYSLOG $IPTABLES -A OUTPUT -o $INT -d $loghost \ -m state --state NEW,ESTABLISHED,RELATED \ -p UDP --sport syslog --dport syslog -j ACCEPT # ========================================================== # PART VI: Forwarding: Intern --> DMZ, einschl. "exa" # ========================================================== # ---------------------------------------------------------# SYSLOG $IPTABLES -A FORWARD -i $DMZ -o $INT -s $DMZ_NET -d $loghost \ -m state --state NEW,ESTABLISHED,RELATED \ -p UDP --sport syslog --dport syslog -j ACCEPT $IPTABLES -A FORWARD -i $INT -o $DMZ -s $loghost -d $DMZ_NET \ -m state --state ESTABLISHED,RELATED \ -p UDP --sport syslog --dport syslog -j ACCEPT # ---------------------------------------------------------# Rückkanal: eingehende Pakete zu einer bestehenden Verbindung $IPTABLES -A FORWARD -i $DMZ -o $INT -s $DMZ_NET \ -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i $DMZ -o $INT -s $DMZ_NET \ -m state --state NEW,INVALID -j my_drop # ---------------------------------------------------------# ICMP $IPTABLES -A FORWARD -i $INT -o $DMZ -d $DMZ_NET \ -p ICMP --icmp-type echo-request -j ACCEPT
297
9 Firewalls bauen – Netzwerk
# ---------------------------------------------------------# DNS zum internen Nameserver foreach ns ( $ns_int ) $IPTABLES -A FORWARD -i $INT -o $DMZ -d $ns \ -m state --state NEW,ESTABLISHED,RELATED \ -p UDP --sport $p_high --dport domain \ -j ACCEPT $IPTABLES -A -m -p -j end
-m state --state NEW,ESTABLISHED,RELATED \ -p TCP --sport $p_ssh --dport ssh -j ACCEPT # ========================================================== # PART VIII: Forwarding: Intern --> Extern, direkt # ========================================================== # ---------------------------------------------------------# Rückkanal: eingehende Pakete zu einer bestehenden Verbindung $IPTABLES -A FORWARD -i $DMZ -o $INT -s ! $DMZ_NET \ -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i $DMZ -o $INT -s ! $DMZ_NET \ -m state --state NEW,INVALID -j my_drop # ---------------------------------------------------------# ICMP $IPTABLES -A FORWARD -i $INT -o $DMZ -d ! $DMZ_NET \ -p ICMP --icmp-type echo-request -j ACCEPT # ---------------------------------------------------------# SSH $IPTABLES -A FORWARD -i $INT -o $DMZ -d $FRIENDs \ -m state --state NEW,ESTABLISHED,RELATED \ -p TCP --sport $p_ssh --dport ssh -j ACCEPT # ========================================================== # SCHLUSS # ========================================================== # ---------------------------------------------------------# Ausputzer: Rest sperren, loggen $IPTABLES -A INPUT -j my_drop $IPTABLES -A FORWARD -j my_drop $IPTABLES -A OUTPUT -j my_drop
299
9 Firewalls bauen – Netzwerk
Skript für den äußeren Paketfilter „exa“ #!/bin/tcsh # # Firewallkript für exa # ========================================================== # PART I: Variablen # ========================================================== modprobe ip_tables modprobe ip_conntrack set IPTABLES = /usr/sbin/iptables # ---------------------------------------------------------# special ports set p_high set p_ssh set p_socks
= 1024:65535 = 1000:1023 = 1080
# unprivileged ports # common ssh source ports # Socks Server Port
# ---------------------------------------------------------# interfaces set EXT = ippp0 set DMZ = eth1:0 set IF
= ( $DMZ $EXT )
# ---------------------------------------------------------# ip hosts set ext_ip
# ========================================================== # PART V: Filterregeln für lokale Dienste # ========================================================== # ---------------------------------------------------------# Rückkanal: eingehende Pakete zu einer bestehenden Verbindung $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT -m state --state NEW,INVALID -j my_drop # ---------------------------------------------------------# ICMP
302
9.3 Firewall mit Grenznetz
$IPTABLES -A OUTPUT -p ICMP --icmp-type echo-request -j ACCEPT # ---------------------------------------------------------# SYSLOG $IPTABLES -A OUTPUT -o $DMZ -d $loghost \ -m state --state NEW,ESTABLISHED,RELATED \ -p UDP --sport syslog --dport syslog -j ACCEPT # ========================================================== # PART VII: Forwarding: DMZ --> Extern # ========================================================== # ---------------------------------------------------------# Rückkanal: eingehende Pakete zu einer bestehenden # ausgehenden Verbindung $IPTABLES -A FORWARD -i $EXT -o $DMZ -d $DMZ_NET \ -m state --state ESTABLISHED,RELATED -j ACCEPT # ---------------------------------------------------------# Rückkanal: ausgehende Pakete zu einer bestehenden # eingehenden Verbindung (Serverdienste) $IPTABLES -A FORWARD -i $DMZ -o $EXT -s $DMZ_NET \ -m state --state ESTABLISHED,RELATED -j ACCEPT # ---------------------------------------------------------# generell ungültige Pakete verwerfen $IPTABLES -A FORWARD -m state --state INVALID -j my_drop # ---------------------------------------------------------# ICMP $IPTABLES -A FORWARD -i $DMZ -o $EXT -s $DMZ_NET \ -p ICMP --icmp-type echo-request -j ACCEPT # ---------------------------------------------------------# DNS foreach ns ( $NS ) $IPTABLES -A FORWARD -i $DMZ -o $EXT -s $ns_int -d $ns \
303
9 Firewalls bauen – Netzwerk
-m state --state NEW,ESTABLISHED,RELATED \ -p UDP --sport $p_high --dport domain \ -j ACCEPT $IPTABLES -A -m -p -j end
$IPTABLES -A FORWARD -i $EXT \ -p TCP --dport auth --syn -j REJECT # ---------------------------------------------------------# Ausputzer: Rest sperren, loggen $IPTABLES -A INPUT -j my_drop $IPTABLES -A FORWARD -j my_drop $IPTABLES -A OUTPUT -j my_drop
9.3.2
Caching Web-Proxy
Im Zusammenhang mit Web-Proxies, also Proxies, die für HTTP-Verbindungen eingesetzt werden, sind drei Aufgabengebiete zu unterscheiden: ❏ Der eigentliche Proxy, der als Stellvertreter die Verbindung zum Zielserver
aufbaut und die Daten eins zu eins durchreicht. ❏ Eine Cache-Funktionalität, die statische Webseiten einen begrenzten Zeit-
raum vorhält, um die Zugriffe für die Anwender zu beschleunigen, aber auch um wertvolle Leitungskapazität zu sparen. ❏ Eine Filterfunktion, die den Inhalt der übertragenen Seiten prüft und schäd-
liche Inhalte entfernt oder sperrt. SOCKS erfüllt nur einen reinen Proxy-Zweck. Als generischer Proxy läßt SOCKS jeden beliebigen Inhalt durch, sofern nur der passende Port und TCP verwendet werden. Dabei muß nicht unbedingt HTTP übertragen werden. Für Caching-Zwecke bietet sich unter Linux Squid an. Squid ist ein CachingProxy, der neben HTTP auch mit FTP und Gopher umgehen kann. Squid verfügt auch über ein Protokoll, mit dem sich der lokale Cache mit anderen verteilten Caches im Internet abgleichen kann. Squid ist auf allen aktuellen LinuxDistributionen im Standardfall enthalten. Die Homepage von Squid, auf der sich auch eine Vielzahl an Zusatzinformation findet, ist http://www.squid-cache.org/
306
9.3 Firewall mit Grenznetz
Eine Fähigkeit, die Squid nicht besitzt, ist Content-Filtering. Squid kann also keine Inhalte beurteilen und filtern. Wer darauf nicht verzichten kann, sollte sich httpf oder auch muffin ansehen (weitere Informationen dazu im Abschnitt 6.4). Wir beschränken uns hier auf die Paketfilterung und SOCKS-Konfiguration für die Verwendung von Squid. Auf die eigentliche Squid-Konfiguration gehen wir nicht näher ein, dazu sei auf die Homepage von Squid und den dort vorhandenen, sehr guten FAQ verwiesen. Squid-Paketfilterung Wir gehen hier davon aus, daß Squid auf dem bisherigen Proxy-Server installiert ist. Natürlich läßt sich Squid auch auf einem eigens dafür hergerichteten Server installieren. Die Paketfilterregeln sind dann entsprechend anzupassen. Squid verwendet im Standardfall den TCP-Port 3128. Die folgende Filterregel läßt daher einen Verbindungsaufba der Clients im internen Netzwerk zum ProxyServer zu: # ---------------------------------------------------------# Squid $IPTABLES -A FORWARD -i $INT -o $DMZ -d $sockssrv \ -m state --state NEW,ESTABLISHED,RELATED \ -p TCP --sport $p_high --dport 3128 -j ACCEPT
Squid, SOCKS, Clients Wenn gleichzeitig noch SOCKS benutzt wird, müssen wir dafür sorgen, daß auch socksifizierte Clients direkte Verbindungen zu Squid aufnehmen. Dazu dient der folgende Eintrag in /etc/socks.conf: route { from: 0.0.0.0/0 to: 192.168.2.2/24 port = 3128 via: direct }
Diese Regel muß vor dem Eintrag stehen, der alle Verbindungen auf den SOCKSServer umleitet. Woher weiß der Client nun, daß er überhaupt den Squid-Proxy benutzen soll? Fast alle Webbrowser verfügen über die Möglichkeit, manuell Proxy-Verbindungen abhängig vom gewünschten Dienst zu konfigurieren.
307
9 Firewalls bauen – Netzwerk
Für HTTP muß dann zum Beispiel beim Netscape Communicator unter „manuelle Proxy-Konfiguration“ für den HTTP-Proxy der Server und der Port (hier: 192.168.2.2, Port 3128) angegeben werden. Mit den bisher aufgezeigten Filterregeln können die Clients keine direkte HTTPVerbindung zum Internet aufbauen. Da aber die SOCKS-Verbindung ja generell zum Socksserver möglich ist, und dieser auch gleichzeitig (wegen Squid) ausgehende TCP-Verbindungen zum Port 80 aufbauen können muß, könnte jemand versuchen, unter Umgehung des Squid-Servers über SOCKS eine HTTPVerbindung aufzubauen. Soll dies verhindert werden, muß der SOCKS-Server so konfiguriert werden, daß er HTTP-Verbindungen ablehnt: block { from: 192.168.1.0/24 to: 0.0.0.0/0 port = http log: connect error }
Bleibt zum Schluß die Frage nach HTTP via SSL. Eine verschlüsselte Verbindung kann nicht so ohne weiteres von einem Applikation Proxy übernommen und verändert werden. Die Verschlüsselung und die Prüfung der Zertifikate nimmt der Client direkt mit den Daten vom Zielserver vor. Squid ist nicht in der Lage, die Daten zu entschlüsseln und dort einzugreifen. Also werden von Squid Verbindungen via SSL einfach durchgereicht wie bei einem generischen Proxy. Dasselbe Problem hat auch auch ein Content-Filter. Wer Content-Filtering einsetzt, müßte konsequenterweise entweder alle SSL-Verbindungen verbieten oder ausschließlich auf vertrauenswürdige Sites einschränken. In unserer Konfiguration gehen alle ausgehenden HTTP- und SSL-Verbindungen vom Proxy-Server aus. Eine solche Einschränkung ist also einfach über die Filterregeln des externen Paketfilters „exa“ zu realisieren.
9.3.3
Webserver
Fast alle Providerangebote enthalten die Möglichkeit, eine Homepage auf der Hardware des Providers abzulegen. Solche Angebote sind oft mit vielen Zusatzfeatures ausgestattet wie eigene CGI-Skripte, unbeschränkter Datentransfer und vieles andere mehr. Darüber hinaus bieten Provider professionelle WebhostingAngebote an, bei denen man gegen entsprechendes Entgelt auch professionelle Leistung erwarten darf, insbesondere auch in Bezug auf höchste Verfügbarkeit der Webseiten im Internet. Der erste Schritt für die Eigendarstellung im Internet wird also immer sein, sich mit den Angeboten des Providers auseinanderzusetzen. Möglicherweise ist die
308
9.3 Firewall mit Grenznetz
gewünschte Leistung bereits im abgeschlossenen Paket schon kostenlos enthalten. Und trotzdem: irgendwann kommt der Wunsch auf, trotz der Mehrarbeit einen eigenen Webserver aufzubauen. Gründe dafür sind oft fehlende Funktionalitäten beim Provider, etwa eine spezielle Datenbankanbindung, vielleicht sogar an Inhouse-Daten, oder andere, selbst entwickelte Anwendungen. Spätestens jetzt ist eine eigene feste IP-Adresse unumgänglich. In der Regel existiert auch eine eigene Domain. Diese wird vom Provider in seinen Nameservern eingetragen, damit externe Surfer den Webserver finden können. Es gibt zwar auch Methoden, wie man einen Webserver mit dynamischer IP-Adresse findet, diese sollen hier aber nicht weiter behandelt werden. Paketfilterung Für Serverdienste müssen eingehende Verbindungen zum betroffenen Server zugelassen werden. Dies betrifft nur den externen Paketfilter „exa“, ein externer Surfer soll ja nicht in das interne Netzwerk gelassen werden. Folgende Regel ist in unserer Konfiguration bereits vorhanden und läßt Pakete, die zu einer eingehenden, bereits bestehenden Verbindung gehören, wieder hinaus: # ---------------------------------------------------------# Rückkanal: ausgehende Pakete zu einer bestehenden # eingehenden Verbindung (Serverdienste) $IPTABLES -A FORWARD -i $DMZ -o $EXT -s $DMZ_NET \ -m state --state ESTABLISHED,RELATED -j ACCEPT
Es fehlt also nur eine Regel für eingehende Pakete inklusive Verbindungsaufbau. Wir haben aber nur eine einzige IP-Adresse, die das externe Interface des äußeren Paketfilters bereits benutzt. Nur diese Adresse ist im Internet bekannt. Eingehende Verbindungen müssen daher an den eigentlichen Webserver weitergeleitet werden. Das geschieht mit Destination NAT (siehe Abschnitt 5.3.3): # ---------------------------------------------------------# Eingehende HTTP-Verbindung, DNAT set httpsrv = 192.168.2.3 $IPTABLES -t nat -A PREROUTING -i $EXT \ -p TCP --sport $p_high --dport http \ -j DNAT --to-source $httpsrv
309
9 Firewalls bauen – Netzwerk
Eingehende Pakete auf dem Interface $EXT werden an den Webserver weitergereicht. Die Zieladresse des Paketes wird dabei umgeschrieben. Das ist allerdings noch keine Filterregel, die das eingehende HTTP-Paket durchläßt. Diese muß gesondert konfiguriert werden. Der Routingmechanismus des NetfilterFrameworks sorgt dafür, daß man dabei direkt die Regel so setzen kann, als gäbe es kein Network Address Translation. Ziel-IP-Adresse ist die tatsächlich vorhandene (hier 192.168.2.3), ohne Rücksicht auf NAT und private Netzwerkadressen: # ---------------------------------------------------------# Eingehende HTTP-Verbindung, Paketfilterregel $IPTABLES -A FORWARD -i $EXT -o $DMZ -d $httpsrv \ -m state --state NEW,ESTABLISHED,RELATED \ -p TCP --sport $p_high --dport http -j ACCEPT
Damit ist der Webserver erreichbar. Vorausgesetzt, die Verbindung zum Internet steht. Was bei einer Verbindung in der Art einer Standleitung (wie zum xDSL-Verbindungen) selbstverständlich ist, muß bei Dialin-Verbindungen gesondert bedacht werden. Hier bieten Provider in der Regel die Möglichkeit (gegen Verrechnung der Telefongebühren), selbst die Verbindung zum Kunden aufzubauen, wenn jemand versucht, auf den Webserver zuzugreifen. Sicherer Webserver Wer selbst einen Webserver betreibt, muß auch einigen Aufwand betreiben, um den Webserver sicher zu machen und zu halten. Die Sicherheit von Webservern läßt sich grob in drei Bereiche unterteilen: ❏ Host-Sicherheit
Zunächst muß der Server als Host selbst sicher sein. Ein Angreifer könnte eine Möglichkeit finden, den Host auf anderen Wegen als über HTTP anzugreifen. Die Absicherung des Hosts an sich beschreibt Abschnitt 8.1. ❏ Webserver-Dienst: Programm und Konfiguration
Der Webserver selbst könnte in einer unsicheren Konfiguration ausgeliefert werden, oder es könnten Sicherheitslücken des Server-Daemons selbst auftauchen, die bisher nicht bekannt waren. Hier gilt es, bereits bei der Installation ein kritisches Auge auf die mitgelieferte Konfiguration zu werfen. Empfehlenswert ist, alle mitgelieferten, ausführbaren CGI-Programme erst einmal zu entfernen und nur solche hinzuzufügen, die unbedingt benötigt werden und die in der Vergangenheit nicht durch Sicherheitsprobleme aufgefallen sind.
310
9.3 Firewall mit Grenznetz
Beim Apache-Webserver werden einige CGI-Programme mitgeliefert, die zwar Debugging bei der Inbetriebnahme einfach machen, aber leider auch einem potentiellen Angreifer eine Fülle von Informationen über die Installation liefern, etwa printenv oder test.pl. Die Sicherheitsdiskussion ist ständig in Bewegung. Man sollte sich daher regelmäßig auf den einschlägigen Homepages der eingesetzten Webserver über den Stand der aktuellen Entwicklung informieren und die dort gegebenen Sicherheitsratschläge beherzigen. Die Homepage von Apache ist http://www.apache.org Weitere Internetadressen zum Thema Sicherheit finden sich im Anhang E.2. ❏ Sichere Webprogrammierung
Wer auf seinen Webseiten Eingaben zuläßt, muß auch auf eine sichere Programmierung achten. Es tauchen immer wieder Angriffsszenarien auf, die durch eine geschickte Wahl des Eingabestrings einen Webserver veranlaßt, bestimmte Befehle auf Shell-Ebene auszuführen. Den Webserver selbst in einer Chroot-Umgebung auszuführen hilft zwar. Besser ist es aber allemal, CGI-Programme so zu schreiben, daß diese unempfindlich gegenüber Eingabemanipulationen werden. Hinweise zu dieser Problematik und zur sicheren Webprogrammierung finden sich im „linux hacker’s guide“ ([ano00]). Wie man mit SuSE Linux einen sicheren Webserver installieren kann, beschreibt auch Marc Heuse ([email protected]) in http://www.suse.de/de/linux/docu/webserver
9.3.4
FTP-Server
Prinzipiell gelten für den FTP-Server dieselben Spielregeln wie für den Webserver. Die Konfiguration des Paketfilters, aber auch die Sicherheitshinweise lassen sich eins zu eins übernehmen. Wenn immer möglich, sollte man Webserver und FTP-Server getrennt betreiben. Kombinationsangriffe, bei denen FTP benutzt wird, Dateien abzulegen, die dann via Web ausgeführt werden, können bei getrennten Servern nicht eingesetzt werden. Weitere mögliche Mißbrauchsszenarien werden im Abschnitt 7.1.6 behandelt. Insbesondere auf den Mißbrauch als WAREZ-Host (Ablage von gestohlener Ware) ist ein Augenmerk zu richten. Man sollte sich überlegen, ob überhaupt ein FTPServer benötigt wird. Sollen nur Dateien vom Internet aus geladen werden, kann das auch über den Webserver geschehen. Webserver verfügen ebenfalls über Authentifikationsmechanismen, so daß sich auch userbezogene Zugriffsrechte implementieren lassen. Wird aber trotzdem ein FTP-Server benötigt, gibt es zwei Möglichkeiten, um eine möglichst hohe Sicherheit zu erzielen:
311
9 Firewalls bauen – Netzwerk
❏ Zum einen sollte man einen FTP-Server auswählen, der entsprechend der
aktuellen Sicherheitsdiskussion von Grund auf auf Sicherheit hin programmiert wurde (zum Beispiel proftpd). Von wu.ftpd ist wegen ständig auftauchender Sicherheitslücken abzuraten. ❏ Die zweite Möglichkeit ist die Verwendung eines Proxy, aber jetzt im um-
gekehrten Sinne. Bisher diente ein Proxy internen Clients für ausgehende Verbindungen. Umgekehrt kann ein spezieller Proxy einen Serverdienst bei eingehenden Verbindungen schützen. So ein Proxy ist der FTP-Proxy aus der SuSE Proxy-Suite, den wir bereits im Abschnitt 6.1 vorgestellt haben. Betrachten wir das Szenario in Abbildung 6.1. Dort laufen auf einem Host zusammen FTP-Proxy und der eigentliche FTP-Server. Der FTP-Proxy benutzt den Standard-Port 21, der FTP-Server läuft dagegen auf dem Port 1088. Paketfilterung Wir gehen davon aus, daß der beim Webserver aufgezeigte Rückweg für ausgehende Pakete einer eingehenden, bereits bestehenden Verbindung schon freigeschaltet ist. Wir benötigen nun für eingehende FTP-Verbindungen ebenfalls eine Destination-NAT-Regel, da es sich um einen anderen Zielport, und einen anderen Zielrechner handelt: # ---------------------------------------------------------# Eingehende FTP-Verbindung, DNAT, control channel set ftpsrv = 192.168.2.4 $IPTABLES -t nat -A PREROUTING -i $EXT \ -p TCP --sport $p_high --dport ftp \ -j DNAT --to-source $ftpsrv
Die Paketfilterregel nimmt wieder keine Rücksicht auf Network Address Translation und das private Netzwerk: # ---------------------------------------------------------# Eingehende FTP-Verbindung, Paketfilterregel control channel $IPTABLES -A FORWARD -i $EXT -o $DMZ -d $ftpsrv \ -m state --state NEW,ESTABLISHED,RELATED \ -p TCP --sport $p_high --dport ftp -j ACCEPT
Den Verbindungsaufbau in Richtung vom Internet hin zum FTP-Proxy haben wir damit konfiguriert, aber nur für den Kommunikationskanal. Bis jetzt können
312
9.3 Firewall mit Grenznetz
noch keine Daten transferiert werden (dazu gehört auch die Anzeige des Inhaltsverzeichnisses). FTP besitzt zwei Arten der Datenübertragung: passives FTP und aktives FTP. Bei aktivem FTP baut der Server die Verbindung für die Datenübertragung zum Client hin auf. Im Gegensatz zu ausgehenden Client-FTP-Verbindungen (bei denen würde aktives FTP bedeuten, daß ein beliebiger FTP-Server eine eingehnde TCP-Verbindung nach innen aufbauen darf), ist aktives FTP bei Servern weniger kritisch. Aktives FTP Unser Proxy ist so konfiguriert, daß er für Datenverbindungen bei aktivem FTP Source-Ports zwischen 40000 und 40999 benutzt (zur Proxy-Konfiguration später mehr). Wir benutzen hier nicht die Features des FTP-Connection-TrackingModules, sondern wickeln die Verbindung klassisch mit einer eigenen Filterregel ab: # ---------------------------------------------------------# Eingehende FTP-Verbindung, aktiver Datentransfer (ausgehend) set p_activeftp = 40000:40999 # Proxy(Src-Port)-->Client $IPTABLES -A -m -p -j
Voraussetzung ist wieder, daß eine bereits vorhandene Filterregel den Rückkanal für eingehende Pakete (einer ausgehenden, bereits bestehenden Verbindung) offen hält. Passives FTP Bei passiven Datenverbindungen ist es wieder der Client, der die (Daten-)Verbindung aufbaut. Es handelt sich also wieder um eine eingehende Verbindung. Der FTP-Proxy erlaubt es, den Bereich der Zielports einzuschränken: # ---------------------------------------------------------# Eingehende FTP-Verbindung, passiver Datentransfer (eingehend) set p_passiveftp = 41000:41999 # Client-->Proxy(Dst-Port) $IPTABLES -A FORWARD -i $EXT -o $DMZ -d $ftpsrv \
Konfiguration des FTP-Proxies Bei SuSE wird die Proxy-Suite mitgeliefert und läßt sich via YaST einfach installieren. Die Konfigurationsdatei ist /etc/proxy-suite/ftp-proxy.conf. Nachfolgend ein Auszug mit den wichtigsten Parametern. Für den FTP-Proxy wird eine ausführlich dokumentierte Beispiel-Konfigurationsdatei mitgeliefert, weitere Informationen finden sich in man ftp-proxy.conf. Das Beispiel hier ist nicht vollständig. # # /etc/proxy-suite/ftp-proxy.conf # [-Global-] ActiveMinDataPort 40000 ActiveMaxDataPort 40999 PassiveMinDataPort 41000 PassiveMaxDataPort 41999 AllowMagicUser
no
DestinationAddress localhost DestinationPort 1088 User Group Listen Port
Anfragen gibt der FTP-Proxy an localhost weiter, wir konfigurieren nachfolgend den FTP-Server (proftpd) so, daß er nur Verbindungen auf dem LoopbackInterface (IP-Adresse 127.0.0.1) akzeptiert. Das bedeutet, unser FTP-Server nimmt gar keine Verbindungen aus dem Netzwerk an (zusätzlich kann man den FTP-Server natürlich noch mit einer lokalen Paketfilterung ausstatten, die generell FTP-Verbindungen nur zum Port 21, das ist der FTP-Proxy, zuläßt). Der Konfigurationsabschnitt [-Global-] gilt nicht nur für die Serverkonfiguration, sondern auch für alle User, für die nicht explizit eine namentlich benannte Umgebung eingerichtet wurde (Beispiel: [nameduser]). Über die Direktive ValidCommands können die Kommandos, die im FTP-Protokoll zulässig sind, eingeschränkt werden (zu den Kommandos des FTP-Protokolls siehe RFC 0959). Zweckmäßigerweise schränkt man die Defaultrechte stark ein und räumt nur ausgewählten Usern mehr Rechte ein. In einer Standard-Konfiguration bindet proftpd den Port an 0.0.0.0. Das bedeutet, jede eingehende Verbindung auf den konfigurierten Port, auch Verbindungen an die IP-Adresse des Netzwerkinterfaces, werden akzeptiert. Wir möchten aber, daß proftpd nur auf dem Socket 127.0.0.1:1088 lauscht. Das gelingt mit einem Trick: Port 0 verhindert zunächst, daß der Server defaultmäßig auf 0.0.0.0 bindet. Mit einer VirtualHost-Umgebung auf localhost wird dann erreicht, daß proftpd genau auf dem gewünschten Socket lauscht: # # Auszug aus /etc/proftpd.conf # Port 0 SocketBindTight on ... Umask 022 MaxLoginAttempts 3 RequireValidShell yes PathAllowFilter "^[a-zA-Z0-9_.-]+$" PathDenyFilter "(\.ftp)|(\.ht)[a-z]+$" AllowFilter "^[a-zA-Z0-9@~ /,_.-]*$" DenyFilter "%" ... DenyAll
315
9 Firewalls bauen – Netzwerk
... Port 1088 ServerName "my-ftp-server" DefaultRoot /data/ftp Order Allow,Deny AllowGroup ftpusers DenyAll AllowGroup ftpusers DenyAll DenyAll ...
Für Details zur Konfiguration sei wieder auf die mitgelieferte Dokumentation verwiesen (SuSE: /usr/share/doc/packages/proftpd).
9.3.5
Transparente Proxies
Bisher unerwähnt blieben transparente Proxies. Transparente Proxies sollen, wie der Name schon verrät, ihren Dienst unauffällig und ohne Kenntnis des Client verrichten. Das Standard-Verfahren ist, eine ausgehende Verbindung eines Client zu einem Server, etwa einem Webserver, abzufangen und an einen Proxy weiterzuleiten, der dann stattdessen die Verbindung übernimmt. Der Client merkt von dem nichts, die Verbindung wird quasi „entführt“. Der Proxy muß dabei über besondere Fähigkeiten verfügen. Er muß irgendwoher die Information beziehen, an welche Zieladresse das Paket gehen soll. Bei SOCKS wird diese Information offiziell mitgeteilt, ein transparenter Proxy muß sich diese Information auf einem anderen Weg besorgen.
316
9.3 Firewall mit Grenznetz
Unter Kernel 2.2 war transparentes Proxying nur auf einem Host möglich, der als Router auch auf der Wegstrecke lag. Mit ipchains wurde einfach der Port umgeleitet (REDIRECT), das IP-Paket hatte dann immer noch die ursprüngliche Zieladresse. Unter Kernel 2.4 geht das nicht mehr, da der TCP/IP-Stack anders aufgebaut ist. Die eine Möglichkeit ist, ein anderes Interface zu verwenden, das das Netfilterframework mitliefert. Das bedeutet, daß der Proxy-Code abgeändert und neu kompiliert werden muß. Eine weitere Möglichkeit für transparentes Proxying existiert für Anwendungen, die in ihrem Protokoll noch einmal die Information über den Zielhost mitführen. HTTP gehört dazu, und Squid macht sich dieses zunutze. Web-Clients, die im Request-Header die Host-Direktive mitführen (HTTP/1.0 optional, HTTP/1.1 verpflichtend, also alle neueren Clients), liefern Squid diese Information frei Haus. Ein entsprechend konfigurierter Squid kann dann diese Information auswerten und als transparenter Proxy agieren. Auf dem inneren Paketfilter ist dazu Destination-NAT notwendig: # ---------------------------------------------------------# Eingehende FTP-Verbindung, DNAT, control channel set squidsrv = 192.168.2.2 $IPTABLES -t nat -A PREROUTING -i $INT \ -p TCP --sport $p_high --dport 80 \ -j DNAT --to-source ${squidsrv}:3128
Die Regel leitet ausgehende HTTP-Verbindungen an den Squid-Server weiter. Zusätzlich ist eine Regel erforderlich (hier nicht aufgezeigt), die eine HTTP-Verbindung zwischen den internen Clients und dem Squid-Server erlaubt. Die Squid-Konfiguration (Squid 2.3 bzw. Squid 2.4) benötigt folgende Parameter: http_port 8080 httpd_accel_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header on # nur Squid 2.4 # httpd_accel_single_host off
Mit der Direktive httpd_accel_uses_host_header wird Squid angewiesen, die eigentliche Zieladresse aus dem HTTP-Request-Header zu entnehmen.
317
9 Firewalls bauen – Netzwerk
Verfügt das Protokoll nicht über eine solche Information, d. h. , kann ein transparenter Proxy die Information nur aus dem IP-Paket beziehen, dann funktioniert transparentes Proxying nur unter zwei Bedingungen mit Kernel 2.4: 1. Der Proxy liegt in der normalen Route des IP-Paketes und Port Redirection wird lokal am Proxy ausgeführt (nur so enthält das IP-Paket noch die originale Zieladresse). 2. Die Routine getsockname() wird durch nf_getsockname() ersetzt. Die originale Routine getsockname() liefert unter dem Netfilter-Framework nämlich die echte lokale IP- und Port-Adresse.
9.4 Ausblicke Die Konfigurationsmöglichkeiten für Firewalls sind so vielzählig, wie es unterschiedliche Anforderungen gibt. In diesem Buch wurden einige gebräuchliche Konstellationen vorgestellt und ausführlich behandelt. Einige Bausteine wurden
Abbildung 9.5: Firewall mit zwei Paketfiltern, doppeltem Grenznetz und dual homed bastion hosts
318
9.4 Ausblicke
nur in jeweils einem Abschnitt angesprochen. Es empfiehlt sich daher, das gesamte Kapitel durchzuarbeiten, auch wenn vielleicht eine der vorgestellten Konfigurationen den eigenen Einsatzzweck bereits sehr gut beschreibt. Möglicherweise ergeben sich dann nützliche Kombinationen oder neue Ideen, die der eigenen Anforderung besser gerecht werden als die hier vorgestellte Variante. Aus dem hier vorgestellten Möglichkeiten läßt sich für höhere Sicherheitsanforderungen auch noch eine Variante generieren, die anhand von Abbildung 9.5 kurz veranschaulicht werden soll. Wenn nur Dienste zum Einsatz kommen, kann man auf eine direkte Verbindung gänzlich verzichten und einen oder mehrere Dual Homed Bastion Hosts einsetzen. Diese Dual Homed Bastion Hosts erhalten zwei Netzwerkkarten, von denen jeweils eine mit den externen Paketfilter, die andere mit dem internen Paketfilter verbunden ist. Dabei gibt es keine direkte Verbindung zwischen dem internen und externen Paketfilter. Routing auf den Bastion Hosts wird per Paketfilterung gänzlich unterbunden. Damit sind Proxies die einzige Möglichkeit der Verbindung zur Außenwelt. Was bleibt zum Schluß? Die im Internet verfügbaren Werkzeuge der Open Source Gemeinde entwickeln sich ständig weiter, es kommen auch neue hinzu, oder ältere sterben aus. Nützlich, aber zur Zeit noch nicht in Sicht wären zum Beispiel Netfiltermodule, die Content-Filtering für HTTP- und andere Protokolle durchführen könnten. Ebenso dringend notwendig wäre ein MTA, der ohne irgendwelche umständliche Hacks ein klares Konzept für Body Checks, insbesondere für Virenerkennung bietet. Zur Zeit zeichnet sich ab, daß Postfix bald über so eine Funktionalität verfügen wird.
319
9 Firewalls bauen – Netzwerk
320
Kapitel 10 Maintenance: Firewalls installieren, betreiben, überwachen Dieses Kapitel beschäftigt sich mit dem, was die Administration von Firewalls ausmacht: Paketfilter und Proxies laufen auf realen Systemen, und diese müssen installiert und während des Betriebes auch überwacht und gewartet werden. Auch wenn man Unix- und insbesondere Linux-Systemen nachsagt, daß sie stabil und ohne Abstürze Jahre hindurch ohne Reboot laufen können, kann und sollte man seinen Firewall nicht unbeaufsichtigt lassen. Logfiles füllen sich und beanspruchen mit der Zeit immer mehr Festplattenplatz, installierte Pakete können Sicherheitslücken enthalten, die im Laufe der Zeit bekannt werden und möglicherweise Gegenstand von Attacken werden. Firewalls an sich lenken manchmal Aufmerksamkeit auf sich und werden Ziel von Angriffsversuchen: es ist nun mal sehr interessant, einen geheimen Code zu knacken, etwa Informationen über Netzwerke hinter Firewalls herauszubekommen – obwohl ein Firewall-Betreiber eigentlich versucht, genau diese Information geheim zu halten. Offene, ungeschützte Systeme sind etwas für Skript-Kiddies, die schnell wieder aufgeben, wenn ein fertiger Exploit nicht auf Anhieb funktioniert. Für einen echten Hacker ist so ein System eher langweilig und dient bestenfalls als Ausgangsplattform für „richtige“ Angriffe. Wenn ein Firewall auf Dauer seinen Zweck erfüllen soll, ist die regelmäßige Überwachung und Pflege unerläßlich. Ein rechtzeitiger Update eines kritischen Softwarepaketes kann so manchen Einbruch verhindern. Ein Beobachten auffälliger IP-Adressen, etwa fortwährende Scans bekannter Exploits des eigenen Netzwerkes zeigt oft die Vorbereitung eines Einbruchs. Eine Information an den zuständigen Netzwerkverantwortlichen des Providers, aus dessen Bereich der Scan kommt, oder ein komplettes Aussperren der ungezogenen IP-Adresse kann zu einem guten Teil dazu beitragen, daß es gar nicht erst zum Einbruch kommt.
Und last, but not least: manchmal läßt sich der Einbruch doch nicht ganz verhindern. Das kann an einer zu freien Security-Policy, an Konfigurationsfehlern, zu späten Updates oder an einem unwahrscheinlichen, aber nicht auszuschließenden perfekten Hack-Angriff liegen. Auch hier ist die laufende Überwachung unbedingt erforderlich: es muß erst einmal festgestellt werden, daß überhaupt eingebrochen wurde. In einem solchen Falle wird man sich nach einem ersten Überblick und der Sicherung des aktuellen Zustandes in der Regel unverzüglich an eine Neuinstallation des betroffenen Rechners machen. Der Aufwand an Überwachung und Pflege hängt vom Einsatzgebiet des Firewall ab. Ein Firewall mit DMZ und diversen Serverdiensten mit fester, permanenter IP-Adresse benötigt natürlich wesentlich mehr Aufmerksamkeit und Pflege als ein Standalone-Host, der nur ab und zu online ist und seine IP-Adresse dynamisch bezieht. Die meisten folgenden Überlegungen werden für einen Firewall mit DMZ angestellt, gleichwohl gelten die Grundprinzipien natürlich auch für einfachere Konfigurationen.
10.1 Vor der Inbetriebnahme Firewalls im Sinne dieses Buches laufen auf realen Linux-Systemen. Man sollte sich deshalb bereits vor der Installation über einige Punkte Gedanken machen, die später auf die Sicherheit des Firewall Einfluß haben. Neben dem eigentlichen Firewall-Konzept sollte auch die Hardware, die physikalische Sicherheit der am Firewall beteiligten Systeme (Hardware, NetzwerkInfrastruktur, Backup) berücksichtigt werden. Auf dem System selbst kann man mit einer geeigneten Partitionierung bereits Einfluß auf die Sicherheit nehmen. Überflüssige Pakete sollten erst gar nicht installiert werden, dann hält sich auch die Anzahl der zu überwachenden Software und deren regelmäßiger Update in Grenzen. Überlegungen zum Worst-Case-Recovery (Wiederherstellung des Firewalls nach einem Einbruch oder nach einem Hardware-Ausfall) sind ebenfalls zu berücksichtigen.
10.1.1
Physikalische Sicherheit
Unter den Begriff physikalische Sicherheit fallen sowohl Maßnahmen, die physikalische Schäden vom System fernhalten, als auch Maßnahmen, die den physikalischen Zugriff einer unbefugten Person auf das System verhindern sollen: ❏ Höhere Gewalt: Brand, Wasser, Blitzschlag:
gehören eigentlich in das ganz normale IT-Sicherheitskonzept, für den Firewall-Bereich gelten dieselben Regeln. Allerdings ist darauf zu achten, daß
322
10.1 Vor der Inbetriebnahme
sich der Firewall bei einem Totalausfall nicht wie ein Kurzschluß, sondern wie eine durchgebrannte Sicherung verhält: keinesfalls sollte ein Hardwareschaden dazuführen, daß die Anbindung an das Internet schutzlos ist und alle Pakete ungefiltert durchläßt. Theoretisch ist das bei reinen Hardwarefirewalls denkbar, und zwar dann, wenn die Konfiguration in bestimmten Fällen auf eine (offene) Defaulteinstellung zurückgestellt wird. Bei einem Linux-System ist das eher unwahrscheinlich, da es dann eher eine defekte Hardware, aber keine in einem Flash oder ROM eingebrannte Defaultkonfiguration gibt. ❏ Aufstellungsort:
Als Negativbeispiel mag ein (fiktiver) Firewall dienen, der in einer großen Universität in der Ecke eines CIP-Pools steht und für alle zugänglich ist. Ein abgeschlossener Raum, etwa ein Rechnerraum, im Keller oder in der Gebäudemitte ohne Außenfenster oder ohne große Lüftungsschächte ist da schon eher der richtige Ort. ❏ Schlüsselregelung Rechnerraum:
Es sollte genau geregelt sein, wer den Zutritt zu diesem Raum hat. Am ehesten läßt sich sowas über eine streng kontrollierte Vergabe von Schlüsseln bewerkstelligen. ❏ Anbindung Netzwerkinfrastruktur:
Der abgeschottetste Raum nützt nichts, wenn die Netzwerkkabel zum Firewall zu einem Netzwerkschrank führen, der in einer Putzkammer irgendwo im Gebäude steht, die dann auch noch für jeden zugänglich ist. Es ist dann ein leichtes, den Firewall zu umgehen oder zu überbrücken. ❏ Sicheres Gehäuse:
Oft läßt es sich nicht vermeiden, daß der Raum, in dem sich der Firewall befindet, auch von weniger autorisierten Personen mitbenutzt wird. Ein PC im 19”-Gehäuse, eingebaut in einem abschließbaren 19”-Schrank, ist ebenfalls eine sehr gute Lösung. Auch eine PC-Box, in der der PC eingeschlossen werden kann (auf ausreichend Lüftung achten!) kann eine vernünftige Lösung darstellen. ❏ Diskettenlaufwerk, CD-ROM:
In dem Moment, in dem jemand mit einem eigenen Boot-Medium den PC startet, hat er auch die komplette Kontrolle über den PC. Es ist ein leichtes, bei einem Boot von Diskette als root die vollständige Kontrolle über das System zu erlangen. Sind die Sicherheitsanforderungen nicht sehr hoch, kann man auch am Gerät über ein Disketten-/CD-ROM-Schloß sicherstellen, daß kein Unbefugter Zugang zu Boot-Devices erhält. Aber Vorsicht: sehr viele billige Diskettenschlösser sind mit wenig Aufwand in Sekunden auszuschalten.
Den Bootvorgang von Diskette kann man auch im BIOS abstellen. Ohne BIOS-Passwort ist diese Maßnahme allerdings wirkungslos. Und viele BIOSVersionen haben leider ein Masterpasswort, mit dem man den Schutz wieder aufheben kann. Hier muß man sich beim Hersteller gezielt informieren. ❏ Bootloader:
Im Linux-Bereich hat LILO eine weite Verbreitung. LILO (und vielleicht auch andere Bootloader) hat die Möglichkeit, wichtige Dinge bereits beim Boot auf der Kommandozeile zu setzen: linux init=/bin/sh
Gibt man diese Zeile am Boot-Prompt ein, erhält man direkt eine root-Shell ohne Passwort. Das System befindet sich dabei im Single-User Mode. Um sich davor zu schützen, sollte man in /etc/lilo.conf folgendes setzen: # Start LILO global Section # If you want to prevent console users to boot with # init=/bin/bash, restrict usage of boot params by setting # a passwd and using the option restricted. password = was-auch-immer-ihr-wollt restricted
Die Datei /etc/lilo.conf enthält nun ein Passwort und sollte daher nur für root lesbar sein. Am besten setzt man das Passwort unmittelbar vor dem Aufruf von lilo, und löscht es danach gleich wieder aus der Konfigurationsdatei.
10.1.2
Partitionierung/Mounts
Viele Linux-Distributionen installieren das gesamte System in ein einziges Dateisystem. Für den Heimanwender mit seinem PC hat das den Vorteil, daß er sich kaum Gedanken über Partitionierung und Platzbedarf der einzelnen Partitionen zu machen braucht. Für Firewall-Systeme sollte man beim Thema Partitionierung und Dateisysteme etwas mehr investieren. Dateisysteme werden gemountet, d. h. sie werden in einen Verzeichnisbaum eingehängt, der eine einzige Wurzel „/“ hat (im Gegensatz zu Windows-Systemen, bei denen jedes Laufwerk eine eigene Wurzel darstellt). Beim Mounten lassen sich verschiedene Optionen angeben (die mitunter vom verwendeten Dateisystemtyp abhängen: ❏ rw:
Read-Write. Das Dateisystem ist les- und schreibbar. ❏ ro:
Read-Only. Das Dateisystem kann ausschließlich gelesen werden.
324
10.1 Vor der Inbetriebnahme
❏ suid:
Das Set-User-Flag (suid) und das Set-Group-Flag (sgid) werden akzeptiert und ausgeführt. ❏ dev:
Charakter- und Block-Devices werden als solche angesprochen. ❏ exec:
Die Ausführung von Executables (Binaries und Skripts) ist erlaubt. ❏ nosuid:
Set-User-Flag (suid) und Set-Group-Flag (sgid) werden ignoriert. Ist aber nur sicher, sofern suidperl(1) nicht installiert ist! ❏ nodev:
Block- und Charakterdevices werden wie normale Dateien, nicht wie Special Files behandelt. ❏ noexec:
Executables (Binaries und Skripts) dürfen nicht ausgeführt werden. ❏ remount:
Mit dieser Option läßt sich ein Dateisystem, welches bereits gemountet ist, noch einmal mounten. Notwendig ist dies zum Beispiel, wenn beim Booten der Dateisystemcheck schief ging und das root-Dateisystem nur read-only gemountet ist: mount -n -o remount,rw /
Die Option remount läßt sich natürlich auch dazu benutzen, die im folgenden beschriebenen Schutzmaßnahmen zurückzusetzen, wenn der Angreifer erst einmal root-Rechte hat. Man kann sich nun überlegen, welche Teile des Systems auf Partitionen/Dateisysteme ausgelagert werden kann, die nicht alle Rechte benötigen. Viele Konfigurationsdateien brauchen im laufenden Betrieb nicht geändert zu werden, Binaries – außer bei einem Update – erst recht nicht. Temporäre Dateien benötigen in der Regel weder die Möglichkeit, als Special Device angesprochen zu werden, noch müssen diese ein S-Bit haben. Eine Möglichkeit für ein reines Firewall-System zeigt die Aufteilung nach Tabelle 10.1: Die Größenangaben sind nur als Beispiel zu verstehen und hängen stark vom Einzelfall ab. Für eine konkrete Installation nach dem Schema entsprechend Tabelle 10.1 sind zwei Dinge zu beachten: 1. Zum einen ist natürlich auch in den Verzeichnissen / und /usr Schreibberechtigung erforderlich, wenn Software installiert oder Änderungen an der Konfiguration durchgeführt werden. Man kann also ro erst setzen, wenn die Installation vollständig abgeschlossen ist.
2. Zum zweiten gibt es auch immer wieder Software, die sich nicht an gängige Standards hält. Es kann durchaus vorkommen, daß ein Softwarepaket auch mal Executables in /var installiert. Meist hat solche Software aber sowieso nichts auf einem Firewall zu suchen. Gegebenenfalls ist etwas experimentieren erforderlich (zum Beispiel unvermeidbare Executables nach /usr/bin verschieben o. ä.). Auch wenn ein Eindringling mit root-Rechten Optionen wie ro oder nosuid wieder rückgängig machen könnte, ist das Verfahren trotzdem sinnvoll, weil verschiedene Sicherheitslücken auf dem Ändern von Konfigurationsdateien und ähnlichem bestehen und ein Angreifer erst dadurch root-Rechte erlangt. So ein Beispiel ist der rpc.statd-Exploit, der im Abschnitt 10.4 beschrieben wird. Ist /etc/inetd.conf hier nicht schreibbar, gelingt es dem Angreifer nicht, sich eine root-Shell auf diesem Wege zu angeln. Noch besser ist es, wenn man die Dateisysteme / und /usr auf ein hardwareseitig schreibgeschütztes Medium bannen kann. Eine Möglichkeit (allerdings sehr langsam) wäre es, / und /usr nicht zu trennen (in einem Dateisystem zu belassen) und dieses auf CD zu brennen. Allerdings ist der Aufwand bei Updates oder Konfigurationsänderungen sehr hoch – eigentlich nur durchführbar, wenn man ein identisches Schattensystem hat, von dem man aus die Kopien für das CD-ROM zieht. Eine etwas elegantere – wenn auch teurere – Methode wäre es, anstelle des CD-ROMs ein MOD-Laufwerk einzusetzen. Es gibt inzwischen preisgünstige ATAPI-Laufwerke (SCSI sowieso) mit 640 MBytes Kapazität.
10.1.3
Auswahl der zu installierenden Pakete
Als einfache Faustregel gilt: nur die unbedingt notwendigen Pakete installieren. Alles, was nicht unbedingt für den laufenden Betrieb erforderlich ist, hat auf einem System, das zum Firewall-Konzept gehört, absolut nichts zu suchen. Das klingt relativ einfach, wenn man sich aber an die konkrete Auswahl der Pakete macht, wird man schnell feststellen, daß der Teufel im Detail steckt. Bei
326
10.1 Vor der Inbetriebnahme
jeder Distribution sind die Programme auf etwas unterschiedliche Pakete verteilt, und bei jeder neuen Auflage einer Distribution können sich auch mal die Inhalte der Pakete ändern, oder auch ein Paket auf mehrere aufgesplittet werden. Man sollte es sich daher zur Gewohnheit machen, bei jeder neuen Ausgabe einer Distribution vor einer Installation die selbsterstellte Paketliste auf Konsistenz und Vollständigkeit zu prüfen. Oder besser: wie bei einer Erstinstallation mit der Paketauswahl noch einmal ganz von vorne zu beginnen. Das klingt nicht nur nach Arbeit, das ist einiges an Arbeit! Aber als Negativbeispiel sei der Nameserver Bind genannt: in vielen älteren Distributionen war der Nameserver Bind in der Default-Konfiguration, über die jede Distribution verfügt, enthalten. Eine normale 08/15-Installation führte also dazu, daß in dem frisch installierten, laufenden System ein Nameserver lief. Dann erschien (wieder einmal) ein Exploit, mit dem man über bestimmte Versionen des Bind in kürzester Zeit eine root-Shell erhalten konnte (CERT Advisory CA-2000-03). Zum Zeitpunkt des Erscheinens des Exploits waren so gut wie alle installierten BindVersionen betroffen. Da viele nicht wußten, daß bei ihnen der Nameserver Bind lief, hatten sie ihr System auch nicht aktualisiert. Und innerhalb weniger Wochen wurden Hunderte von Hosts kompromittiert. Es gab sogar Fälle, in denen der Eindringling nach Installation eines Rootkits den Bind via FTP aktualisierte, damit kein anderer Hacker sich dieses Hosts bedienen konnte, und der ursprüngliche Eindringling ungestört den Host als Sprungbrett von weiteren Attacken nutzen konnte. Das tragische an diesem Beispiel: Es traf überwiegend diejenigen, die eigentlich gar keinen Nameserver auf dem System benötigten. Von denjenigen, die den Nameserver bewußt betrieben, schaffte es der größte Teil, rechtzeitig einen Update durchzuführen. Aufgrund der Unterschiede in der Paket-Aufteilung und -Verwaltung zwischen Distributionen, aber auch zwischen einzelnen Ausgaben, lassen sich nur Grundregeln für die Paketauswahl angeben. Die Spezifikation der „richtigen“ Pakete ist schlichtweg unmöglich, auch die Anforderungen der einzelnen Systeme hängen ja vom konkreten Einsatzzweck ab. Wenn Sie es völlig anders angehen als hier beschrieben, kann das genauso richtig sein. Entscheidend ist, daß Sie diesen Schritt bewußt tun. Miminale Paketauswahl Beginnen sollte man mit der kleinsten Menge an Paketen, mit der man überhaupt ein lauffähiges System bekommt. Bei SuSE Linux ist das die Auswahl „Minimales System“. Das bei SuSE enthaltene Verwaltungstool YaST verwendet für die Beschreibung von Paketselektionen Textdateien. Diese sind auf der Installations-
CD im Verzeichnis /cdrom/suse/setup/descr enthalten und tragen die Endung *.sel. Hier das Selektionsfile für die miminimale Umgebung, Minimal.sel, gekürzt um die anderen Sprachversionen, enthalten ist nur der Part für „german“: # SuSE-Linux Configuration YaST Version 1.03 # -- (c) 1994-2000 SuSE GmbH # generated on Sat Jul 29 20:41:09 GMT 2000 Description.german: Minimal System. Utf8Description.german: Minimales System Info.german: Ofni.german: Kind: baseconf Visible: true Toinstall: aaa_base aaa_dir aaa_skel ash base bash bc bdflush bzip compress cpio cracklib cron ddrescue devs dhcpcd diff ed ext2fs file fileutil find gawk Llatsniot:
gdbm gppshare groff gzip idedma kbd less libjpeg libpng libz lilo lsof lvm mailx man mktemp modules ncurses net_tool netcfg nkitb openssh pads
Der Part zwischen Toinstall: und Llatsniot: wurde für den Druck umgebrochen, im Original befindet sich pro Zeile genau ein Paket, das installiert werden soll.
328
10.1 Vor der Inbetriebnahme
Aus der Liste kann man in der Regel weitere Pakete streichen. Jeder Distributor hat das Problem, daß die Pakete, die dort stehen, im für eine bestimmte Anwendung gedacht ist, die sich aber nicht unbedingt mit unseren Anforderungen hier decken muß. Streichkandidaten wären: dhcpd lvm libjpeg libpng
procmail reiserfs saxtools sendmail
y2t_* yast2
Will man einen Firewall-Router einsetzen, sollte man ohne DHCP arbeiten. Wenn kein Logical Volumemanager installiert ist, benötigt man auch kein Paket lvm. Ebenso wird reiserfs nur benötigt, wenn das Dateisystem auch zum Einsatz kommt. Die saxtools gehören zu X11-Installationen, die in der Regel auf Firewall-Systemen nichts zu suchen haben, die beiden Graphik-Libraries werden hier nur für die saxtools verwendet. Wenn das Firewall-System ein Mail-SendOnly-Host ist, dann kann man auch weniger große Mailpakete als sendmail einsetzen, etwa Postfix, den man so starten kann, daß kein smtpd-Daemon läuft und damit auch kein Empfang von E-Mail via Netzwerk möglich ist. Auf procmail kann man ebenso verzichten, auf einem Firewall-System empfängt man keine lokalen E-Mails, sondern routet diese an einen zentralen Mailserver weiter. Und die YaST2-Komponenten braucht man ebenfalls nicht, sofern man mit der Administration via YaST1 zurecht kommt. Mit YaST1 kann man die Paketauswahl interaktiv editieren und anschließend auf eine Floppy abspeichern. Selektion von erforderlichen Paketen Für ein Firewall-System liefert SuSE eine Auswahl „DMZ Basissystem“ mit. Aber auch dort sind mitunter Pakete dabei, die man auf dem konkreten System gar nicht haben will (zum Beispiel der eingangs erwähnte Bind). Man kann aber die beiden Selektionsfiles Minimal.sel und Dmz.sel miteinander vergleichen und sich die Pakete heraussuchen, die man gerne einsetzen möchte: ❏ bindutil:
Programme wie nslookup sind auf einem Firewall-System manchmal ganz nützlich. Das Paket enthält keinen Server, sondern nur Client-Programme. ❏ hardsuse:
Skripte von SuSE, die den Rechner automatisch gegen Eindringlinge absichern sollen. ❏ iptables:
Zum Erstellen der Filterregeln unverzichtbar (wer noch mit ipchains arbeitet, muß natürlich stattdessen ipchains installieren).
Werkzeuge zur Netzwerkanalyse. Vorsicht: diese sind zwar sehr hilfreich, können aber auch einem Eindringling, der sich eine root-Shell verschafft hat, das Leben deutlich erleichtern. Im Einzelfall abwägen. ❏ tcsh:
Eine weitere Shell, stellvertretend für andere Shells. Was man einsetzt, hängt in erster Linie von den Gewohnheiten des Administrators ab. Unverzichtbar ist in jedem Falle die Bash, weil viele System-Skripte (Startup, etc.) eine Bash oder andere Bourne-Shell-kompatible Shell benötigen. Dieses Liste kann man beliebig fortsetzen, das grundsätzliche Verfahren sollte aber sein, mit einem minimalen Setup anzufangen und benötigte Pakete nach und nach hinzuzufügen. Einfach gemacht wird dies bei SuSE wiederum durch YaST: man kann die Möglichkeit nutzen, mehrere Selektionen gleichzeitig zu laden, um zunächst den Minimalset auszuwählen und diesen dann um weitere Pakete zu ergänzen. Das eröffnet die Möglichkeit, ein eigenes „Addon“-Selektionsfile zu erstellen: # SuSE-Linux Configuration YaST Version 1.03 # -- (c) 1994-2000 SuSE GmbH # Beispiel Selektionsfile Description.german: DMZ Addon Info.german: Addon fuer Firewall-Installationen Ofni.german: Kind: addon Visible: false Toinstall: bindutil hardsuse iptables ipchains postfix pcre tcpdump ngrep tcsh Llatsniot:
330
10.1 Vor der Inbetriebnahme
Das so erzeugte Selektionsfile kann man auf eine DOS-formatierte Diskette kopieren (auch minix und ext2fs werden als Dateisystemtyp unterstützt) und im YaST im Auswahlmenü „Konfiguration laden“ über die Funktionstaste anwählen. Die Datei kann man mit einem ASCII-Editor einfach bearbeiten und den Bedürfnissen entsprechend anpassen. Ändert sich in Zukunft einmal die Paketaufteilung, und für ein gewünschtes Paket werden andere Pakete benötigt, dann kann man diese im YaST über die Funktionstaste ermitteln. Aber Vorsicht: die Abhängigkeiten werden in einer eigenen Liste gepflegt, und die wird von Menschenhand gemacht. Nicht alles, was YaST als nötig erachtet, ist auch tatsächlich für unseren Zweck hier notwendig. Werkzeuge für Eindringlinge Bei der Auswahl der zu installierenden Pakete und Programme kann man diese auch aus der Sicht eines Hackers beurteilen und unterscheiden zwischen ❏ Diensten, deren mögliche Sicherheitslücken dem Hacker ersten Zugang zum
System verschaffen, und ❏ Programmen, die dem Hacker nach dem Eindringen das Arbeiten erleich-
tern. Das Hauptaugenmerk ist in jedem Falle auf die erste Kategorie zu richten. Hat der Hacker erst einmal Zugang zum System und vielleicht sogar eine root-Shell, dann findet er auch einen Weg, Daten von außen in den Rechner zu transportieren. Wie einfach das ist, zeigt folgendes Beispiel. Der Eindringling legt die Datei /tmp/transferscript an: #!/bin/tcsh cat > /tmp/data
Die Datei muß natürlich ausführbar sein. Dann wird /etc/inetd.conf erweitert: 9707
stream
tcp
nowait
nobody /tmp/transferscript transferscript
Der Inetd muß natürlich seine Konfigurationsdatei neu lesen: kill -HUP
Mit dem Befehl auf dem externen System cat <wasauchimmer> | netcat 9707
Und schwupps, wasauchimmer steht jetzt auf dem kompromittierten System in /tmp/data. Dabei ist außer root-Rechten und dem Inetd nichts erforderlich, die Übertragung nutzt nichts außer TCP.
Manchmal wird in der Literatur empfohlen, nicht benötigte Programme zu löschen oder zu verschlüsseln, um es dem Angreifer schwerer zu machen. Das ist auch richtig, nur: es macht nur dann richtig Sinn, wenn man vorher alle Möglichkeiten ausgeschöpft hat, damit der Angreifer nach Möglichkeit erst gar nicht in das System gelangt. Ein anderes Beispiel könnte auch der FTP-Client sein, der bei eigentlich jeder Grundinstallation mitgeliefert wird. Man kann ihn löschen, allerdings gibt es auch Skriptsprachen, die fertige Module mitliefern. Ist zum Beispiel das Modul Net::FTP für Perl installiert, ist der Selbstbau eines FTP-Client ein einfacher 5-Zeiler, der sogar in der Manpage steht (man Net::FTP, sofern Net::FTP installiert ist). Programme wie netcat haben auf einem Firewall nichts zu suchen. Das Programm netcat kann auch als Daemon laufen und auf eingehende Verbindungen warten. Benutzt man höhere Ports, kann der Daemon auch von normalen Usern gestartet werden. Ebenso kritisch auf Firewall-Systemen sind Tools, die ein Mitschneiden des Netzwerkverkehrs erlauben wie tcpdump, ngrep etc. Allerdings muß man sich immer vor Augen halten, daß ein wirklich gewiefter Eindringling sich notfalls die Programme auf das kompromittierte System übertragen wird. Die äußere Absicherung eines Systems (ein äußerer Router traut seinem Webserver wenig und erlaubt erst gar keine ausgehenden Verbindungen) kann es einem Eindringling relativ schwer machen, aus dem kompromittierten System Nutzen zu ziehen.
10.1.4
Planung von regelmäßigen Updates
Vom Thema her gehören Updates eigentlich in den Abschnitt „Wartung“, aber: Zum einen werden Sicherheitsfixes fortlaufend publiziert. Das bedeutet konkret, wenn eine Distribution schon einige Tage und Wochen alt ist, wächst auch die Wahrscheinlichkeit, daß bereits Updates vorliegen. Das ist durchaus normal, und verfügbare Updates sollten bereits bei der Installation eingespielt werden. Zum anderen erleichtern einige Überlegungen bereits während der Installation hinterher die Arbeit, wenn man die Installationsdokumentation gleich im Hinblick auf die Notwendigkeiten eines späteren Updates pflegt. ❏ Wann ist ein Update erforderlich?
Solange das System einwandfrei ist, muß man nicht jede gerade verfügbare, neue Version einsetzen. Aber Sicherheitsprobleme, die entdeckt werden, müssen in der Regel schnellstmöglichst behoben werden. Denn in Hackerkreisen wurde die Lücke oft schon Wochen vorher bekannt, und es kommt nicht gerade selten vor, daß bei einer Publikation des Sicherheitsproblemes auch ein fertiger Exploit frei verfügbar ist (den Skript-Kiddies ohne großes Verständnis mißbrauchen können).
332
10.1 Vor der Inbetriebnahme
❏ Woher erfahre ich, daß es ein Sicherheitsloch gibt?
Aus den einschlägigen Mailinglisten und Webseiten. In der Regel gibt es auch bei den Herstellern der Distributionen entsprechende Ankündigungslisten, bei SuSE ist das die Webseite http://www.suse.de/de/support/mailinglists/. ❏ Woher bekomme ich das Update?
Die Hersteller von Distributionen bieten die Updates in der Regel im Internet auf FTP-Servern an. Bei SuSE findet man ausführliche Infos unter http://www.suse.de/de/support/download/updates/. Theoretisch ist es möglich, daß jemand auf dem FTP-Server ein „faules“ Paket (z. B. der Inetd wird durch einen Trojaner ersetzt) enthält. Für solche Fälle erhält man bei SuSE in der Mailingliste suse-security-annouce für das entsprechende Paket eine MD5-Checksumme, die man nach dem Herunterladen prüfen kann. Hier ein Beispiel mit Apache: md5sum apache-1.3.12-107.i386.rpm
Achtung: diese Checksumme ist nicht identisch mit der im Paket enthaltenen Checksumme: rpm -v --checksig apache-1.3.12-107.i386.rpm
liefert eine andere Checksumme, die nicht in der Mailingliste publiziert wird. ❏ Wie führe ich das Update durch?
Ganz einfach mit: rpm -Fhv apache-1.3.12-107.i386.rpm
Man sollte sich aber auch überlegen, wie das Paket überhaupt auf den Rechner kommt. Für das Update ein Loch in den Firewall zu schlagen, um direkt via FTP ein Update durchführen zu können, ist nicht empfehlenswert. Besser ist es, auf einem anderen System die benötigten Pakete herunterzuladen, auf CD zu brennen und dann erst nach der Verifizierung der Checksummen über das CD-ROM-Laufwerk am Firewall-System zu installieren. Um die Übersicht zu behalten, sollte man bereits bei der Installation eine ausführliche Dokumentation anlegen, in der die installierten Pakete mit ihren Versionsnummern, die durchgeführten Anpassungsmaßnahmen, Konfigurationsdateien, aber auch Information über die Hardware enthalten sind. Alle installierten Pakete werden im laufenden System mit rpm -qva
angezeigt. Dieser Befehl liefert zum Beispiel folgendes Output (gekürzte Liste): aaa_base-2000.7.24-4 aaa_dir-2000.7.29-0 aaa_skel-2000.7.16-1 aalib-1.2-193
Mit einer solchen Liste läßt sich bei einem Security-Alert relativ schnell feststellen, ob ein Update unumgänglich ist, oder ob eine nichtbetroffene, meist neuere Version bereits im Einsatz ist. Im Auge behalten sollte man bei Updates auch das Verhalten der Pakete in Bezug auf Konfigurationsänderungen. Es ist nicht auszuschließen, daß der PaketMaintainer beim Erstellen des Update-Paketes eine Konfigurationsdatei übersieht und nicht spezifiziert. Ein Update über RPM führt dann möglicherweise dazu, daß die mit Mühe und Sorgfalt erstellte Konfiguration außer Kraft gesetzt wird. Im schlimmsten Fall wird genau das Gegenteil erreicht: anstatt Sicherheitslücken zu schließen, werden neue gerissen. Je besser bei der Installation dokumentiert wird, was man am eigenen System gegenüber der Grundinstallation verändert hat, desto einfacher ist die Überprüfung nach Updates, ob noch alles in Ordnung ist. Man kann sich auch eine Liste aller Dateien erstellen, die gegenüber dem Grundpaket verändert worden sind: rpm -V <paketname>
Liefert alle Dateien, die sich gegenüber dem Installationspaket verändert haben. Konfigurationsdateien (solche, die das RPM-Paket als Konfigurationsdateien erkennt), sind mit einem eigenen Flag „c“ gekennzeichnet. Genauer wird dieser Integritätscheck noch im Abschnitt 10.4 beschrieben.
Vor der endgültigen Inbetriebnahme gibt es noch drei Dinge zu tun: ❏ eine vollständige Datensicherung, ❏ die Erstellung der Datenbank für einen File-Integritätscheck und ❏ die Erstellung eines Konzeptes für Worst-Case-Recovery.
334
10.1 Vor der Inbetriebnahme
Für die Datensicherung unter Linux genügt ein Dateibasiertes Backup mit tar. Dabei empfiehlt es sich, für jedes Dateisystem ein eigenes Tarfile anzulegen: tar tar tar tar
Die Option -l sorgt dafür, daß der Tar innerhalb desselben Dateisystems bleibt. Ansonsten ist noch darauf zu achten, daß das Verzeichnis, das man gerade sichert, nicht auch noch das Tarfile enthält, sonst sind fast alle Daten doppelt im Tarfile enthalten (entweder jeweils das Tarfile in ein anderes Dateisystem schreiben oder die Option --exclude= verwenden). Die Tarfiles sind auf einer gebrannten CD sehr gut aufgehoben, vom Standpunkt der Archivierung aus sollte man an dieser Stelle nur CD-R, keine CD-RW verwenden. Die nächste Aufgabe ist die Erstellung einer Signaturdatenbank aller Dateien. Eine ausführliche Beschreibung findet sich im Abschnitt 10.4. Nicht unbedingt lebensnotwendig, aber dringend empfehlenswert ist eine Strategie zum Worst-Case-Recovery. Gemeint ist der Fall, in dem das Firewall-System einen Totalausfall zu verzeichnen hat oder sonst irgendwie unbrauchbar geworden ist – unabhängig davon, ob ein Hardwareschaden oder ein Einbruch die Ursache ist. Konzept heißt in jedem Falle, daß man sich Gedanken macht, und diese auch schriftlich dokumentiert, damit im Falle eines Falles darauf zurückgegriffen werden kann. Oft ist dann die Einrichtung des Systemes etliche Monate oder Jahre her, und ohne schriftliche Dokumentation gelingt eine exakte Rekonstruktion oder Neuauflage des Systems selten. Ein Worst-Case-Recovery-Konzept beginnt bereits beim Backup, und beim Wiederauffinden der relevanten Datensicherungen. Von der bei der Installation erstellten CD läßt sich bei Standard-Hardware schon mit der normalen Bootdiskette, die jeder SuSE-Distribution mitgeliefert wird, das System wieder 1:1 herstellen. Gegebenenfalls muß man noch ein Rettungssystem auf Diskette kopieren. Dann hat man mit Boot- und Rescue-Disk ein vollständig laufendes Betriebssystem in der RAM-Disk, mit dem die einzelnen Partitionen von Hand gemountet und die Tarfiles dorthin wieder restauriert werden können. Entscheidend ist, daß von allen Änderungen am System jeweils wieder ein Backup angefertigt und über die einzelnen Maßnahmen Protokoll geführt wird. Bei Updates von mehreren Paketen empfiehlt sich wieder ein Voll-Backup, zwischendurch sind wohl die häufigsten Änderungen solche, die mit dem Finetuning des Firewall zu tun haben (etwa die Anpassung von Paketfilterregeln an aktuelle Situationen). In solchen Fällen genügt es auch, wenn die jeweils geänderte Datei
archiviert wird, manchmal ist auch ein Ausdruck auf Papier sinnvoll und hilfreich. Empfehlenswert: die Wiederherstellung auf einem zweiten System üben. Wenn man vorher bereits die Signaturdatenbank für den Fileintegritätscheck angefertigt hat, läßt sich nach der Wiederherstellung sogar genau prüfen, ob alles sauber geklappt hat (zu beachten ist, daß zwar Permission, Datum etc. richtig gesetzt werden, aber die Inodes in der Regel nicht mehr übereinstimmen). Dokumentiert man dazu die einzelnen Schritte, die man benötigt hat, inklusive aller eventuell aufgetretenen Klippen, und archiviert dazu nicht nur das Backup, sondern auch die Boot- und Rescue-Disketten (alles, was man zur Wiederherstellung benötigt), dann hat man ein perfektes Worst-Case-Recovery Konzept. Wenn die Verfügbarkeit eine sehr große Rolle spielt: aufwendig und nicht immer machbar, aber das Non Plus Ultra: ein zweites, identisches System in Reserve vorhalten.
10.2 Regelmäßige Wartung Irgendwann kommt der große Augenblick: das Firewall-System, nach bestem Wissen und Gewissen sorgfältig installiert, „geht an das Netz“, wird in Betrieb genommen. Das ist auch der Augenblick, wo die Aufmerksamkeit für das Firewall-System – nicht ganz zu unrecht – am höchsten ist. Gerade am Anfang wird man noch das eine oder andere nachbessern, weil es vorher nicht abzusehen war, man noch keine Erfahrung mit dem Firewall-Bau hatte oder ganz einfach weil sich Randbedingungen auch ändern können. Es ist gerade bei der ersten Inbetriebnahme keine schlechte Idee, erst einmal einige ganz wenige Dienste zuzulassen und sich auf das Allernötigste zu beschränken (zum Beispiel Empfang und Versand von E-Mail). Weitere Dienste kann man dann nach und nach hinzuschalten. Das verringert die Möglichkeit einer Fehlkonfiguration. Man kann sich viel besser auf die wenigen, bereits freigeschalteten Dienste konzentrieren und diese einige Zeit genau beobachten. Wer ohne große Erfahrung gleich von Anfang an eine sehr komplexe Firewall-Konzeption auf einem Schlag in Betrieb nimmt, verliert sehr schnell die Übersicht. Wie kann man denn feststellen, ob alles korrekt funktioniert? Oft lautet hier die Antwort, man hat ja Logfiles etc. Das ist aber nur die halbe Miete. Wenn jemand im Straßenverkehr überprüfen will, ob jemand sich an die Geschwindigkeitsbegrenzung hält, hat jeder eine Vorstellung davon, wie das funktioniert. Implizit aber nimmt man vorweg, welche Regeln denn gelten sollen. Es gibt eine Straßenverkehrsordnung, die regelt, wie man sich zu verhalten hat und was ein Verstoß ist. Und dazu das Schild, daß die aktuelle Geschwindigkeitsbegrenzung anzeigt.
336
10.2 Regelmäßige Wartung
Das Auswerten der Logfiles ist aber nur die Messung der Geschwindigkeit. Ob alles mit rechten Dingen zugeht, steht dort nicht. Das regelt eine Security Policy (siehe Kapitel 3). Jeder, der der Logfiles nicht nur betrachtet, sondern bewertet, hat eine Security Policy – wenn nicht schriftlich dargelegt, dann wenigstens im Kopf. Wie im Straßenverkehr erkennt man Verstöße nur an den Stellen, an denen man auch kontrolliert. Wer ein paar Tage lang einmal manuell den Netzwerkverkehr überwacht und Logfiles manuell ausgewertet hat, weiß, daß das ein Ding der Unmöglichkeit ist. Man hat eigentlich nur eine Chance, wenn man möglichst viel automatisiert. Im weiteren Verlauf dieses Kapitels werden wichtige Hilfswerkzeuge für die automatisierte Überwachung von Firewall-Systemen vorgestellt, die einen wichtigen Beitrag zur Sicherheit eines Firewall liefern. Eine automatisierte Überwachung ist auch in der Lage, als Frühwarnsystem zu arbeiten, das heißt, bei Angriffsmustern und ungewöhnlichen Vorkommnissen Alarm zu schlagen. Manuelle Kontrolle kommt fast immer zu spät. Dabei sollte man aber nicht aus den Augen verlieren, daß solche Überwachungssysteme auch nur kontrollieren, wozu sie gedacht und konfiguriert sind. Ein gesundes Mißtrauen und immer wieder stichprobenartige Kontrolle solcher Systeme ist angebracht. Eine Möglichkeit, die Sicherheit des eigenen Firewall-Konzeptes zu prüfen, ist, sich selbst als Hacker zu betätigen. Ryan Russell, der wesentliche Teile des Paketfilterungscodes im Kernel mitentwickelt hat und vom den auch die Tools ipchains und iptables stammen (und dazu die einschlägigen Howtos), hat zu diesem Thema ein eigenes Buch herausgebracht: „Hack Proofing your Network“ ([Rus00]). Ob man sich in dieser Richtung mehr Klarheit über die Sicherheit des Firewalls verschafft, ist Ansichtssache und hängt stark vom Einzelfall ab. Sicher, es ist nicht besonders schwer, sich die Exploits zu kürzlich bekannt gewordenen Sicherheitslücken zu verschaffen und damit das eigene System zu testen. Sofern der Distributor der eingesetzten Linux-Variante bereits ein Sicherheitsupdate veröffentlicht hat, kann man sich den Test mit dem Exploit schenken. Der Update hat höchste Priorität. Und wer sich doch mit der Lücke etwas intensiver auseinandersetzen will, sollte das nicht gerade auf der Produktivumgebung (dem laufenden Firewall) tun, sondern es in einer isolierten Umgebung ausprobieren. Und: kein Hackversuch, kein Test eines Exploits auf den laufenden Firewall ohne vorherige Autorisierung. Hacken als Sicherheitscheck lohnt sich nur dann, wenn man das Niveau von Skript Kiddies (das bloße Ausprobieren fertiger Exploits) verläßt und sich intensiver mit dem Thema auseinandersetzt. Der Zeitaufwand dafür sollte aber nicht unterschätzt werden.
Ein wichtiger, praktischer Aspekt blieb bisher unerwähnt: wie soll denn das Firewall-System gewartet werden? Der Idealfall ist eine eigene serielle Leitung für ein Login zu den Systemen. Eine serielle Leitung ist nur durch physikalischen Zugang zu manipulieren. Es gibt gängige Hardwaregeräte, die eine serielle Leitung über eine normale Twisted-Pair-Verkabelung über bis zu 300 m betreiben können. Ausreichend Verkabelung vorausgesetzt, ist so eine Anbindung technisch mit begrenztem Aufwand durchführbar. Eine ähnliche Variante ist ein eigenes Netzwerk, über das ausschließlich administriert wird. Der Secure-Shell Daemon kann so konfiguriert werden, daß er nur auf einem bestimmten Netzwerkinterface lauscht. Auf den anderen Interfaces ist er dann nicht sichtbar. Wenn keine eigene Anbindung möglich ist, bleibt immer noch eine Secure-ShellVerbindung über das normale Netzwerk. Man sollte sich gut überlegen, von wo aus der ssh-Zugang zu den Firewall-Systemen möglich sein sollte. Der Rechner, von dem aus ssh-Zugang zum Firewall-System besteht, ist dann sicherheitstechnisch ebenso zu behandeln wie die Firewall-Systeme selbst. Und: die SecureShell ist zwar eine sehr hohe Hürde für einen Hacker, aber ab und zu tauchen Sicherheitslöcher, meist in ganz bestimmten Konstellationen auf. Hier ist dann ein sofortiges Update erforderlich, wenn die eigene ssh-Version vom Sicherheitsloch betroffen ist. Regelmäßige Aufgaben sind folgende, für die der Firewall-Administrator auch entsprechend Zeit einplanen muß: ❏ Regelmäßige Backups:
Nicht nur vor der Inbetriebnahme, auch das laufende System benötigt regelmäßige Backups (nach jeder Änderung am System). ❏ Archivierung von Logfiles:
Logfiles sollte man archivieren, um bei späteren sicherheitsrelevanten Vorfällen darauf zurückgreifen zu können. Für den Heimanwender ist das sicher weniger notwendig, aber für Unternehmen spielt das immer öfter eine wichtige Rolle. Archivieren heißt normalerweise auch, daß die archivierte Information nachträglich nicht mehr geändert werden können sollte (auf CD brennen oder ähnliches). ❏ Bezug von sicherheitsrelevanten Mailinglisten:
Ohne die Information aus sogenannten Security-Mailinglisten kommt ein Firewall-Administrator heute kaum noch aus. Als wichtigste seien die Mailinglisten von www.securityfocus.com (bugtraq, ntbugtraq, incidents) und die CERT-Advisories (www.cert.org) genannt. Weitere Informationen finden sich im Anhang E. ❏ Durchführen sicherheitskritischer Updates:
Sicherheits-Updates sollten immer eingespielt werden, sofern das System auch betroffen ist. Im Abschnitt 10.1.4 wurde bereits ausführlich auf technische Details zu den Updates eingegangen.
338
10.3 Intrusion Dectection
10.3 Intrusion Dectection 10.3.1
Einführung
Als Intrusion Detection (ID) bezeichnet man die Erkennung von ungewöhnlichen oder abnormalen Aktivitäten mit dem Ziel, mögliche Beeinträchtigungen der Grundwerte der IT-Sicherheit (Verfügbarkeit, Vertraulichkeit, Integrität) frühzeitig zu erkennen und mögliche Verletzungen dieser Grundwerte bereits im Vorfeld zu verhindern. Das „Hacken“ im Internet ist vielleicht vergleichbar mit Wohnungseinbrüchen: dem eigentlichen Einbruch geht meist eine ganze Serie von Untersuchungen und vorbereitenden Maßnahmen voraus, um die Gefahr gering zu halten, beim eigentlichen Einbruch erwischt zu werden. Die Wohnung wird ausgespäht, möglichst viel an Information über Objekt, Bewohner und Gewohnheiten derselben gesammelt und ausgewertet. Ein unbekanntes Auto, das wochenlang täglich zu unterschiedlichen Zeiten auf der anderen Straßenseite steht, eine dunkle Gestalt, die jeden Abend unter der Straßenlampe sich eine Zigarette anzündet und das Gesicht verhüllt - das gehört in den Kriminalroman, nicht in die Wirklichkeit? Das denken Sie vielleicht. Die Erkennung von Brute Force-Ausspähungen, etwa ein Scan über das gesamte Netzwerksegment mit Tests auf die gerade beliebtesten Einbruchsmöglichkeiten gehört genauso zur Intrusion Detection wie die Aufdeckung subtiler Tests, die so vorsichtig und versteckt von sich gehen, das ein nicht geschultes und wenig aufmerksames Auge diese auf jeden Fall übersehen muß. Ob brutal oder subtil: immer geht es darum, den Unterschied zwischen „normalen“ und „abnormalen“ Aktivitäten zu entdecken. In einem Punkt hat es Intrusion Detection ein klein wenig einfacher: weil zu vielen Sicherheitslücken fertige Exploits als Tool existieren, die man nur noch anzuwenden braucht, gibt es bekannte Signaturen, die oft eindeutig dem Tool und damit auch der Absicht des Urhebers zuzuordnen sind. Solche Angriffe sind sobald die Exploits hinreichend bekannt sind, in der Regel sehr einfach zu entdecken. Diffizilere Varianten sind da schon sehr viel schwieriger zu entdecken, vor allem dann, wenn es sich um einen handgemachten Angriff handelt, der irgendwann vielleicht einmal zu einem fertigen Exploit führt. Man unterscheidet Intrusion Detection Systeme in Host-basierte und Netzwerkbasierte. Host-basierte Intrusion Detection Systeme schützen in erster Linie den Host, auf dem sie installiert sind. Netzwerk-basierte Intrusion Detection Systeme überwachen den Netzwerkverkehr in ihrem Netzwerksegment und versuchen dort Anomalien festzustellen.
Intrusion Detection und Firewalls Intrusion Detection ist eine Ergänzung zu den klassischen Firewall-Konzepten. Vor einem Firewall (im ungeschützten Bereich) können Netzwerk-basierte Intrusion Detections Systeme (NIDS) als Frühwarnsystem agieren und helfen, gegebenenfalls rechtzeitig schärfere Maßnahmen auf dem Firewall zu ergreifen. Hinter einem Firewall können diese als Schutz vor internen Hackern oder als Alarmglocke nach einem „Durchbruch“ fungieren. Und auf dem Firewall können hostbasierte Intrusion Detection Systeme helfen, Attacken gegen den Firewall frühzeitig zu erkennen und abzuwehren. Die Grenze zwischen normaler Firewall-Maintenance und IDS ist fließend. Die in den nachfolgenden Abschnitten vorgestellten Tools sind – bis auf Snort, ein reinrassiges IDS – sowohl als Komponenten für ein Intrusion Detection System als auch für die Firewall-Maintenance einsetzbar. Grundproblem von Intrusion Detection Während ein Firewall zu den klassischen Systemen zählt, ist IDS schon fast eine Modeerscheinung – zwar eine nützliche, brauchbare, die sich auch auf Dauer einen festen Platz bei der IT-Sicherheit behaupten wird. Aber IDS ist bei allem, was sich mit IT-Sicherheit beschäftigt, schon fast ein zwanghaftes Muß. Was man dabei nie aus den Augen verlieren sollte, sind zwei Punkte: ❏ Zum einen beschäftigt sich Intrusion Detection als Frühwarnsystem immer
mit möglichen, zukünftigen Ereignissen. Ob aber aufgezeichnete Spuren auch wirklich zu dem gefürchteten Ereignis führen, kann nur gesagt werden, wenn es anschließend auch wirklich passiert. Ein „es könnte“ ist noch lange kein „es ist“. Die Daten, die ein IDS sammelt, müssen analysiert und bewertet werden. Noch lange nicht jeder Alarm ist tatsächlich richtig. Es gehört ein bißchen Fingerspitzengefühl dazu, sogenannte „False Alarms“ von wirklich wichtigen Ereignissen zu trennen. Und „False Alarms“ gibt es nicht gerade wenige. ❏ Der zweite Punkt ist die Technik an sich: ein IDS bewertet nach festgelegten
Regeln. Und dort finden sich in der Regel nur bekannte Signaturen (weil in der Regel frei verfügbare Tools verwendet werden, die eben immer demselben Programmablauf folgen und somit auch immer dieselbe Signatur hinterlassen). Unbekannte, neue Signaturen sind dort nicht enthalten. Man darf sich also nicht gänzlich auf sein IDS verlassen.
340
10.3 Intrusion Dectection
Abbildung 10.1: Plazierung eines IDS-Systemes: (1) vor dem Firewall, (2) im Grenznetz und (3) im internen Netzwerk
Plazierungsmöglichkeiten von Intrusion Detection Systemen Die Plazierung eines IDS-Systems hängt vom gewählten Zweck ab. Sehen wir uns dazu Abbildung 10.1 an. Will man alle möglichen Angriffe protokollieren, dann darf das IDS natürlich nicht so positioniert sein, daß ein Großteil der Pakete schon herausgefiltert ist. IDS-1 ist hier vor dem Firewall im ungeschützten Teil des Internet plaziert. Technisch geht das nicht in allen Fällen (wenn z. B. der äußere Router eine Wählverbindung in das Internet aufbaut). Wenn aber für die Verbindung ein Router vom Provider gestellt wird, wird man diesen selten als äußeren Router für den Firewall verwenden. Schließlich hat der Provider in der Regel die Hoheit über dessen Konfiguration. Dann bleibt ein lokales Netzwerksegment zwischen Firewall und dem Router des Providers, in das man dann auch ein IDS stellen kann. Ein IDS im Grenznetz (IDS-2) hat einen etwas anderen Schwerpunkt. Zum einen kann es als Alarmsystem für Angriffe dienen, die eigentlich der äußere Router abfangen sollte (wenn dem Angreifer sozusagen der Durchbruch gelungen ist), zum anderen kann das IDS-2 besser unterscheiden helfen zwischen erwünschten Zugriffen auf Server im DMZ und unerwünschten Paketen. Ein internes IDS (IDS-3) hat natürlich eine absolute Alarmfunktion, wenn Pakete auftauchen, die ins Internet gehören und im lokalen Netzwerk nichts zu suchen haben. Ein IDS intern hat aber auch eine wichtige Überwachungsfunktion:
immer mehr Trojaner versuchen sich im Netzwerk zu verbreiten, wenn sie sich einmal auf einem Rechner eingenistet haben. Ein IDS, das die Signaturen von aktuellen Trojanern kennt, kann helfen, dem Übel schnell ein Ende zu bereiten. Ansonsten sind interne Angreifer leider nicht auszuschließen. Auch da kann das interne IDS helfen.
10.3.2
Snort
Snort ist ein einfaches, Netzwerk-basiertes Intrusion Detection System und frei verfügbar. Snort hört die Datenpakete auf dem Netzwerk ab und fungiert dabei als eine Kombination aus Paketfilter, Sniffer und Logger. Die Netzwerkpakete werden nach Quell- und Zielangaben gefiltert (Source-IP, Source-Port, Destination-IP, Destination-Port, Protokoll), der Inhalt analysiert und gegebenenfalls das Logging ausgelöst (Protokollierung, Alarmierung). Zugriff auf den gesamten Netzwerkverkehr erhält Snort über eine spezielle Library, libpcap/libpcapn, die auch vom Tool tcpdump verwendet wird. Snort wird auch als „Lightweight IDS“ bezeichnet, weil es sehr einfachen Regel folgt. Genaugenommen wird jedes Netzwerkpaket anhand der aufgestellten Regeln bewertet. Vorausgehende oder nachfolgende Pakete gehen in diese Bewertung nicht ein. Schwergewichtige Network Intrusion Detection Systeme verfügen über mehr als nur einfache Paketbewertung. Da es bei der Früherkennung um die Abweichung vom Normalen geht, kann man dort oft den „normalen“ Netzwerkverkehr aufzeichnen und statistisch bewerten lassen. Über einstellbare Schwellwerte läßt sich dann festlegen, was als Abweichung von diesem Profil (ungewöhnliche Zeiten, ungewöhnliche Abweichungen im User-Verhalten) gewertet werden soll und Alarm auslöst. Kontext-Abhängigkeiten können auch eine bestimmte Abfolge von Paketen bewerten. Snort hat all diese Funktionalitäten nicht und ist trotzdem ein sehr hilfreiches Tool. Viele Varianten von Angriffen beinhalten nämlich Netzwerkpakete, die normalerweise gar nicht vorkommen. Und bei vielen Exploits gibt es Signaturen, an denen der Exploit bereits in einem einzigen, typischen Netzwerkpaket festgemacht werden kann. Snort-Rules An dem Beispiel einer Snort-Regel läßt sich die Arbeitsweise von Snort gut erklären: alert icmp any any -> any any (msg:"IDS152 - PING BSD"; content: "| 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17|"; itype: 8; depth: 32;)
342
10.3 Intrusion Dectection
Diese Regel löst einen Alarm aus, wenn ein ICMP Echo Request (ICMP Typ 8) an einen beliebigen Host im Netzwerk gesandt wird. Dabei wird das ICMP-Paket nach einem bestimmten Inhalt durchsucht. Hier macht man sich die Eigenart zunutze, daß BSD-basierte Unix-Systeme beim Ping in den Daten eine hexadezimal inkrementierende Folge von Bytes enthalten. Die Suchtiefe ist maximal 32 Bytes. Ganz wichtig: alle Snort-Regeln müssen in je einer Zeile stehen. Der Snort-Parser beherrscht keine Formatierungen. Die Zeilen sind hier nur zur besseren Darstellbarkeit im Druck umbrochen. Rule-Syntax Der Text vor der runden Klammer wird als „Rule Header“ bezeichnet, der Text in den runden Klammern als „Rule Options“. Der Header der Regel folgt der Syntax: action protocol src-ip src-port (->|<>|<-) dest-ip dest-port
Unschwer zu erkennen ist die Richtungsangabe für die Pakete. Der Operator <> ist für bidirektionale Verbindungen. Die Begriffe src und dest beziehen sich auf den Operator ->. Bei <- sind die beiden Begriffe zu vertauschen. Auszulösende Aktion Die Aktion, die ausgelöst werden soll, wenn die Regel auf das Paket zutrifft, kennt folgende Schlüsselwörter: ❏ alert
Ein Alarm wird ausgelöst, und das Paket protokolliert. Ein Alarm kann die gesonderte Protokollierung in einer Datei /var/log/snort.alert sein, die Protokollierung über den Syslog oder die direkte Benachrichtigung über NetBIOS an eine Windows-Workstation. ❏ log
Snort protokolliert alle log- und alert-Aktionen in einem Verzeichnisbaum unter /var/log/snort (als Compile-Option oder Kommandozeilenoption einstellbar). Für jeden Host wird ein Unterverzeichnis mit der dazugehörigen IP-Adresse angelegt. ❏ pass
Das Paket, das auf diese Regel zutrifft, wird ignoriert, d. h., es wird kein Alarm ausgelöst. Um Fehlkonfigurationen vorzubeugen, haben alert-Regel Vorrang vor pass-Regeln. Das heißt, Pakete, auf die eine alert-Regel zutrifft, werden trotz einer pass-Regel ausgeführt (Reihenfolge alert -> pass -> log). Mit der Kommadozeilenoption -o läßt sich das Umkehren (Reihenfolge pass -> alert -> log).
Unterstützte Protokolle sind derzeit tcp, udp, und icmp. IP-Adresse, Portangabe IP-Adresse für Source und Destination kann entweder eine einzelne Adresse oder ein Subnetz sein: ❏ 192.168.0.1 - einzelne Adresse ❏ 192.168.0.0/24 - Subnetz.
Die Schreibweise 192.168.0.0/255.255.255.0 wird nicht unterstützt. ❏ any - beliebige IP-Adresse
Ein Port kann als einzelner Port, aber auch als Bereich angegeben werden: ❏ 53 - einzelner Port ❏ 500:1023 - Portbereich ❏ :1023 - alle privilegierten Ports (0-1023) ❏ 1024: - alle unprivilegierten Ports (1024:65535) ❏ any - beliebiger Port
Rule-Options Während die Paketfilterung bei Snort nur einer Vorsortierung der Pakete gleichkommt, machen die Rule-Options die eigentliche IDS-Fähigkeit von Snort aus. Ein gutes Beispiel dafür ist die einführende Regel weiter oben, ein Ping ist eben nicht gleich Ping. Optionen werden hinter der Regel in runden Klammern angeben: action protocol src-ip src-port -> dest-ip dest-port (key1: value; key2: value; ...)
Snort verfügt derzeit über folgende Optionen: ❏ msg:
„text“; bezeichnet den Text, der beim Alert- und Logeintrag mitangegeben wird. Man sollte hier immer eindeutige Texte setzen, um später die Logeinträge eindeutig zu den auslösenden Regeln zuordnen zu können.
❏ logto:
„“; Wenn Pakete nicht im Standard-Logfile protokolliert werden sollen, kann man hier ein alternatives Logfile angeben. Da dieses Logfile je Regel spezifiziert werden kann, lassen sich bestimmte Ereignisse zusammenfassen.
❏ ttl:
„“; Time-To-Live-Zähler. Snort testet allerdings nur auf Übereinstimmung, dient daher in erster Linie zur Erkennung von Traceroute. Beispiel:
344
10.3 Intrusion Dectection
alert udp !any any -> any any \ (msg:"IDS03 - MISC-Traceroute UDP";ttl:1;) ❏ id:
„“; 16-Bit Identification Field des IP-Headers. Manche Tools setzen hier bewußt feste Werte ein und können so mit dieser Option erkannt werden.
❏ dsize:
[>|<] ; Test auf die Größe des Datenbereiches. Der Test kann auch auf gleich stattfinden, wenn das größer/kleiner-Zeichen entfällt. Beispiel: alert icmp any any -> any any \ (msg:"IDS246 - MISC - Large ICMP Packet"; dsize: > 800;)
❏ content:
„“; Das eigentliche „Fleisch“ des Sniffers. Der Paketinhalt wird gegen den Content String getestet. Binäre und Textdaten können beliebig gemischt werden, dabei werden Binärdaten hexadezimal angegeben und mit dem „|“ eingeschlossen. Zwei Dinge sollten beachtet werden: ➢ Zum einen wird bei Text zwischen Groß- und Kleinschreibung unterschieden. Soll das nicht der Fall sein, muß man mit der Option nocase kombinieren. ➢ Zum anderen dürfte einleuchtend sein, daß es mitunter einiges an Re-
chenzeit kostet, wenn immer das gesamte Paket untersucht werden soll. Wenn bekannt ist, in welchem Teil des Paketes der gesuchte Code vorhanden ist, dann sollte man aus Geschwindigkeitsgründen immer die Suchtiefe mit offset und depth einschränken. Bei Geschwindigkeitsoptimierungen sollte man noch berücksichtigen, das die Content-Option immer als letzte ausgeführt wird. Daten werden nicht beim Verbindungsaufbau übertragen, sondern nur, wenn die Verbindung bereits steht (Flags PA). Beispiel: alert tcp any any -> any 143 (msg:"OVERFLOW-86-linux-imap1";\ flags:PA; content:"|e8 c0ff ffff|/bin/sh";) ❏ offset:
; Offset in Bytes, ab dem das Paket durchsucht werden soll. Kann nur zusammen mit der Content-Option verwendet werden.
❏ depth:
; Einschränkung der Suchtiefe. Durchsucht wird das Datenpaket im Bereich [offset..offset+depth]. Ebenfalls zur Verwendung im Zusammenhang mit der Content-Option.
❏ nocase;
Bei allen ASCII-Zeichen des Content-Strings werden Groß-/Kleinschreibung nicht beachtet.
; Der TCP-Header kennt 6 Flags; neben den definierten Flags im TCP-Header kennt Snort auch noch die beiden oberen, reservierten Bits in dem von den Flags benutzten Byte: ➢ 1, reserved bit 1 (MSB) ➢ 2, reserved bit 2 ➢ (U)RG ➢ (A)CK ➢ (P)SH ➢ (R)ST ➢ (S)YN
➢ (F)IN (LSB) Bestimmte Kombinationen dieser Flags, die im Normalfall nicht auftreten können, sind alleine schon ein Indiz für außergewöhnliche Pakete, etwa ein SYN-FIN-Scan (es macht keinen Sinn, bereits beim Verbindungsaufbau schon das „Schließen“-Flag mitzusenden) oder die Verwendung der reservierten Bits. Ein schönes Beispiel ist Xmas-Scan - wie beim Christbaum sind alle Lichter (Flags) an: alert tcp any any -> any any \ (msg:"IDS144 - SCAN-FullXMASScan";flags:SRAFPU;) ❏ seq:
; Test auf eine bestimmte TCP-Sequenz-Nummer.
❏ ack:
; Test auf eine bestimmte Acknowledgement-Nummer. Das Tool nmap setzt zum Beispiel Acknowledgement-Nummern auf 0.
❏ itype:
; ICMP-Typ eines ICMP-Paketes. Während man bei Tools wie ipchains den ICMP-Typ als Source-Port angibt, haben ICMP-Snort-Rules keinen Port (any), und der ICMP-Typ wird in den Rule-Options angegeben. Zu den Bedeutungen von ICMP-Typ und Code siehe auch Abschnitt A.4.
❏ icode:
; ICMP-Code eines ICMP-Paketes.
❏ session:
[printable|all]; Extrahiert Anwendungsdaten von TCP-Sessions. Damit läßt sich der Inhalt von TCP-Sessions wie FTP, rlogin, oder Telnet protokollieren. [printable|all] bezieht sich auf die übertragenen Zeichen.
❏ icmp_id: ❏ icmp_seq:
346
; ;
10.3 Intrusion Dectection
ICMP Identifier und ICMP Sequence-Number gehören genau genommen zu dem Paar ICMP Echo Request/Reply. Manche Tools setzen dort explizite Einträge. Beispiel: alert icmp any any -> any any \ (msg:"IDS184 - DDoS - TFN client command BE"; \ itype: 0; icmp_id: 456; icmp_seq: 0;) ❏ ipoption:
; IP-Optionen im IP-Header werden selten genutzt. Am bekanntesten ist noch Source-Routing. Die möglichen Argumente sind: ➢ rr Record Route ➢ eol ➢ nop
Es ist jeweils nur eine IP-Option pro Rule erlaubt. ❏ rpc:
, [number|*], [number|*]; Erkennung von RPC-Requests, die Angabe erfolgt mit dem Tripel .
❏ resp:
; Flexible Response. Hiermit kann Snort aktiv auf bestimmte Verbindungen reagieren und diese beenden. Mögliche Werte sind: ➢ rst_snd Sendet ein TCP-RST Paket an den Sender. ➢ rst_rcv
Sendet ein TCP-RST Paket an den Empfänger. ➢ rst_all
Sendet ein TCP-RST Paket an beide beteiligten Sockets. ➢ icmp_net
Sendet ein ICMP Network Unreachable an den Sender. ➢ icmp_host
Sendet ein ICMP Host Unreachable an den Sender. ➢ icmp_port
Sendet ein ICMP Port Unreachable an den Sender. ➢ icmp_all
Weitere Konfigurationsoptionen Snort wurde mit dem Konzept von Preprozessoren erweitert, um User-definierte Plugins einfach zu ermöglichen. Die Syntax ist: preprocessor :
Derzeit kennt Snort 4 Preprozessoren: ❏ minfrag:
Normalerweise werden Netzwerkpakete ausschließlich durch Netzwerkkomponenten fragmentiert. Nur in Ausnahmefällen liegt die MTU bei unter 512 Bytes (früher gab es bei PPP-Verbindungen über langsame Modems schon mal die Empfehlung, die MTU auf 256 herunterzusetzen). Fragmente die kürzer als 128 Bytes sind, sind prinzipiell verdächtig, deshalb ist der empfohlene Threshold 128. preprocessor minfrag: 128
❏ http_decode:
<port list> Häufig sind URLs kodiert, man spricht auch von Escapes. Dabei wird ein problematisches Zeichen als hexadezimale Zahl dargestellt, geführt von einem %-Zeichen. Um mit Snort solche Zeichenfolgen korrekt zu erkennen, muß zunächst eine Dekodierung vorgenommen werden. Übliche Ports, bei denen der HTTP-Dekoder aktiviert werden sollte, sind hier 80, 443 und vielleicht auch 8080. preprocessor http_decode: 80 443 8080
Mit der Anzahl der Ports und der Detection Period kann man sehr fein auf die eigenen Belange abstellen. In dem Beispiel schlägt der Portscanner schon Alarm, wenn ein Host innerhalb von 5 Sekunden mindestens 3 verschiedene Hosts auf dem eigenen Netzwerk anspricht. Bei so großen Zeitfenstern erhält man öfter Hits durch Antwortpakete von sehr häufig genutzten Servern wie Nameservern. Eine genaue Auswertung der Logfiles hilft bei der Anpassung der Regel (der Nameserver kann zum Beispiel durch eine passRule ausgeblendet werden. ❏ portscan_ignorehosts:
Wenn man eigene Scans durchführt, sollte man hiermit den eigenen Host ausblenden, um Fehlalarme zu vermeiden. preprocessor portscan_ignorehosts: 192.168.100.13
Ein weiteres Konzept sind Output-Module, die dem Anwender eine wesentlich flexiblere Handhabung ermöglichen sollen. Derzeit implementiert sind:
348
10.3 Intrusion Dectection
❏ alert_syslog:
<priority> Der Output wird wird via Syslog protokolliert. Dabei kann man die bei Syslog üblichen Einstellungen setzen: output alert_syslog: LOG_LOCAL3 LOG_WARNING
