arch-leipzig schrieb
Wenn ich via RJ45-Stecker zum Modem (Thomson THG570k, aus dem Jahr 2010) verbunden bin, kann ich dann auch auf "iptables" verzichten? Ich weiss nicht ob so ein Kabelmodem eine eingebaute Firewall hat, das Handbuch ist recht spärlich dazu.
Das ist eine Frage, die man nur nach etwas Beschäftigung mit dem IP-Protokoll und der lokalen Situation beantworten kann. Z.B.:
1. Kriterium:
Ist mein Rechner mit einem *unsicheren* Netzwerk verbunden?
a) In den meisten Fällen befinden sich die Endgeräte in einem lokalen privaten Netzwerk (erkennbar daran, daß die Netzwerkkarten IP-Adressen aus vordefinierten privaten IP-Bereichen (z.B. 192.168.*.*) haben. Diese Endgeräte sind z.B. vom Internet her nicht direkt erreichbar. Das ist dann zum einen das Firmen- oder private LAN hinter einem Router (der die Verbindung zu einem potentiell unsicheren Netzwerk hält und regelt). Solange dieser Router keine Pakete ins lokale LAN weiter-/umleitet kann keine Afrage von "außen" die lokalen Rechner erreichen bzw. gefährden.
b) Etwas anderes ist es, wenn das Endgerät über seine Netzwerkkarte/Struktur mit einem unsicheren Netzwerk verbunden ist. Sowas kann sein:
* das Hotel-LAN/WLAN
* öffentlicher Hot-Spot
* DSL/Kabel-Modem, bei dem das Endgerät selbst z.B. über PPPoE eine öffentliche IP bekommt
* Uni-Netzwerk
* usw, eigentlich alles bei dem die anderen Netzteilnehmer nicht unter meiner Kontrolle stehen.
Für sich könnte jetzt der Fall mit dem DSL/kabelmodem zutreffen. Du solltest also feststellen, ob dein Rechner eine öffentliche (=nicht private IP) hat wenn du eine Internetverbindung hast. Wenn das der Fall wäre, dann hast du ein ganz anderes Gefährdungspotential als Endgeräte hinter einem Router/Firewall.
Kurz: meinen Rechner kann eine HTTP-Anfrage aus Honkong nicht erreichen wenn ich meinen Router nicht anweise: Laß Pakete an Port 80 durch und leite diese an meinen Rechner weiter (PortForwarding). Dieses Paket käme aber auf meinen Rechner, wenn ich direkt mit dem Internet (öffentliche IP) verbunden wäre. Dann müßte ich mir wesentlich mehr Gedanken machen, das Gefährungspotential ist einfach - technisch - viel größer als hinter einem Router (der sichere von unsicheren Netzen trennt).
2. Kriterium:
Dienste, Blocken und wie funktioniert IP überhaupt?
Eine IP-Adresse ist wie ein Mehrparteienwohnhaus, die Dienste sind die einzelnen Bewohner. Ein Besucher will i.d.R. zu jemand Bestimmtes, also Hohlweg 23 -> Müller. Das würde entsprechen z.B. <IP-Addr>:80 für den Port 80, an dem normalerweise Pakete(Besucher) für einen Web/HTTP-Server ankommen. Ein Besucher braucht immer einen Namen um ggf. Einlaß zu finden, daß nennt sich Socket und setzt sich bei IP aus IP-Addr:Port zusammen. Hinter den Ports stehen auf den Rechnern dann Dienste, die eben auf Anfragen reagieren, genau wie Müller die Tür aufmacht wenn jemand bei ihm klingelt.
Wenn ich einen Webserver auf Port 80 betreibe erwarte ich auch Anfragen (Besuche für Müller), d.h. Müller muß mit Besuchen (Staubsauger-Vertretern z.B.) selbst fertig werden. Er kann seine Klingel nicht einfach abstellen, weil dann könnte er auch ausziehen. Wenn ich keinen Dienst für SSH (i.d.R. Port 22, nennen wir ihn Meier) laufen habe, dann befindet sich an der Außentürklingel keine Klingel mit dem Namen Meier. D.h. eine Schuhpaket-
Zustellung(ssh-Anfrage) für Meier würde in dem Haus nie ankommen, da ja keine Klingel vorhanden ist. Der Zusteller würde irgendwann frustiert (=Timeout) aufgeben. Selbst wenn der Schuhpaketzusteller es bei Müller versuchen würde, dann würde Müller sagen: Schuhe? Ich nehme nur Einschreibebriefe an. Und tschüss!
So ist in dem Haus "IP" eigentlich alles geregelt, es gibt Bewohner die auch Besuch für sie erwarten. Wie sie mit dem Besuch umgehen ist dann ihre Sache (=Dienst-Konfiguration). Wer nicht hier wohnt kriegt auch keinen Besuch **auf den er reagieren könnte**
Jetzt kommt die Hausverwaltung auf die Idee: wir brauchen für teuer Geld unbedingt einen Concierge, einen Torwächter der die Außenklingel "bewacht". Was macht dieser Wächter nun für sein Geld eigentlich?
Es kommt ein Besucher für Müller (http, Port 80). Aha, zu Müller? (Er blättert in seinem Verzeichniss) Ja, Müller wohnt hier, gehen Sie weiter und klingeln Sie. Nun ein Besucher für Meier (ssh, Port 22): Zu Meier? (Er blättert in seinem Verzeichniss) Nein, einen Meier gibt es hier nicht, da brauchen sie erst garnicht die Namen an der Klingel zu lesen.
Das ist jetzt erstmal nicht sehr prickelnd was der Torwächter macht für teuer Geld. Die Hausbewohner mokieren zu Recht bei der Eigentümerversammlung: Müller(http): Ich zahle doch kein Geld für jemand, der meine Besucher kontrolliert die zu mir wollen, die ich eingeladen habe. Andere: Laßt diese Besucher doch selbst lesen, ob Meier oder Schablowski hier überhaupt wohnen! Aufstand im Hohlweg 23!
Das ist nun in Etwa das "Dilemma" mit den "Personal Firewalls" auf Paketfilter-Basis. Ich brauche per Regelwerk nicht ssh, smtp etc. auszuschließen, wenn am Ende gar niemand Anfragen auf diese Dienste annehmen würde (keine Klingel am Haus). Für alles andre (wo also Dienste existieren) würde der Paketfilter diese ja auch durchlassen.
So ist IMHO ein bewährtes Mittel, erstmal eine Bestandsaufnahme der eigenen Bewohner zu machen (netstat -tulpen). Und diese Dienste dann entsprechend zu konfigurieren, also das Besuchsverhalten: Sanni hatte z.B. weiter oben den ntp-Dienst laufen, und zwar so daß an der Haus-Außenklingel der Name stand (0.0.0.0:123/udp). Gewünscht/ausreichend war allerdings, daß dieser "Bewohner" nur Besuch von innerhalb des Hauses erwartet, also ein Namesnschild nur an der Wohnungstür-Klingel, nicht an der Außentür. Eine so vorgenommene Konfiguration des Netzwerkes (brauche ich Dienst xyz? Wenn ja, kann ich diesen konfigurieren) läßt dann einen Paketfilter oftmals überflüssig werden. Kein Dienst = kein Port = keine Reaktion auf etwaige Anfragen. Und wenn der Rechner von Sanni immer hinter einem Router/Firewall sitzt, die eben nicht Anfragen auf 123/udp exakt zu seinem Rechner weiterleiten würde aus dem Internet, dann wäre ein "offenes Scheunentor" auf seinem Rechner prinzipiell erstmal kein Problem. Da der Router selbst ja (hoffentlich) keinen ntp-Dienst öffentlich anbietet *und* eben Anfragen nicht ins lokalen Netz weiterleitet, diese Anfragen also einfach "leerlaufen".
Um den ellenlangen Beitrag kürzer zu machen:
Ich würde einen Paketfilter immer in Erwägung ziehen bei dem Endgerät, welches *direkt* aus einem unsicheren Netzwerk erreichbar ist (Laptop im Hotel, Router im eigenen LAN). Und das weniger zum "Filtern, was nicht notwendig ist" (s.o.), sondern ggf. zum Loggen und für spezielle Gegebenheiten die eine öffentliche Anbindung mit sich bringen (statefull inspection z.B., oder content-Filterung, unsaubere/überlange Pakete sofern der IP-Stack das nicht selbst regeln kann). Aber auch hier gilt IMHO: erstmal die Dienste konfigurieren bzw. abstellen.
Am Laptop z.B. habe ich sowohl einen ssh-Dienst als auch einen NFS-Server, welche ich im eigenen LAN benötige. Diese starte ich aber nur, wenn ich mich wirklich in meiner gesicherten Umgebung befinde. Einen einfachen Paketfilter für Anfragen von außen kann ich mir für diese Ports dann sparen.
Grr, ich muß weg: Ich rede nicht gegen Sicherheit durch einen Wächter an "vorderster Front", v.a. da es Konstellationen gibt die nur so regelbar sind. Wichtig ist IMHO aber, daß grundlegende Verständniss wo (und wo nicht) Gefahren überhaupt entstehen können bzw. eben nicht.