Hallo Leute, die Überschrift klingt evtl. ein wenig albern, ist jedoch ernst gemeint. Konkret geht es um Folgendes: Ich habe ein grundlegendes Verständnisproblem bei der Funktion von Firewalls. Bei einer Firewall im WLAN-Router ist mir die grundlegende Funktion klar: Auf welchen Ports darf von außen (WAN) ein Zugriff auf die an die Firewall angeschlossenen Geräte erfolgen? In den Dokus, Tutorials und config-Tools zu Firewalls taucht immer wieder der Bergiff "Zone" auf. Bei einfachen Varainten gibt es eine öffentliche, demilitarisierte und interne Zone. Was ich weiß: die Zone ist eine (logische?, virtuelle?, gedachte?) Abgrenzung zwischen verschiedenen Bereichen in einem Netzwerk. Z.B. ist im Router der WAN-Anschluss der externen Zone zugeordnet. Und vermutlich ist das WLAN-Netz dann das interne Netz. Aber was ist z.B. mit der DMZ? Und bei firewalld (die nutze ich) gibt es noch viel mehr Zonen. Lange Rede, kurzer Sinn: ich kann mir den Begriff der "Zone" nicht klarmachen, schon gar nicht bei einer Software-Firewall, die auf dem Rechner läuft. Obwohl ich schon einige Doku gelesen habe, bleiben mir die Zonen ein Rätsel. Ich würde mich deshalb sehr freuen, wenn sich hier jemand die Zeit nehmen würde und mir das Thema so erklärt, dass ich es ein für alle Mal verstehe. Andere Fragen meinerseits wären z.B., ob die Portfreigaben oder -Sperren jeweils in beide Richtungen wirken usw. Ich weiß, dass es verschiedene Firewall-Techniken mit verschiedenen Zielen gibt, aber aktuell brauche ich erstmal die Grundlagen. Aktuell ist mir das Thema wichtig, da ich für die Web-Entwicklung lokal ein LAMP-System einrichten möchte. Und da möchte ich dann alles zumachen bis auf die notwendigen http- und https-Ports etc., bei denen ich lediglich einen Zugriff vom selben Rechner auf den darauf laufenden Apache zulassen will. Alle anderen Teilnehmer/Netze sollen gesperrt werden. ***** Ich bin auch sehr dankbar für Hinweise zu erleuchtender Doku! ***** Liebe Grüße Marci
Das ist nicht so einfach. Administrator ist ein Vollzeitjob. Da solltest du ein paar Monate einplanen und erst mal ein Lehrbuch durcharbeiten. (Die Bücher, die ich kenne, sind schon seit 10 Jahren veraltet. Am besten beim größten Händler die Kundenrezensionen durchschauen). Oder einfach sagen, du bekommst eh keine ernsthaften Angriffe. Portfreigabe auf dem DSL-Router ist gut genug.
Hallo Xanthippos, vielen Dank für Deine Antwort. Ich war aktuell in der Bibliothek, und wurde leider nicht recht fündig. Die Bücher, die es gibt, sind zwar umfangreich (teilweise 500 Seiten und mehr), aber das Thema Firewall wird in wenigen Seiten abgehandelt. Dafür wird das komplette Spektrum der Cyber-Security behandelt, das ja inzwischen, wie Du richtig geschrieben hast, recht umfangreich und anspruchsvoll ist. ciao Marci
Naja, man muss auch sagen dass die Begriffe je nach Hersteller immer ein wenig anders genutzt werden. Aber grundsätzlich kannst Du Dir eine Zone als eine Art Gruppe vorstellen. In diese Gruppe kannst Du jetzt Netzwerkschnittstellen hinzufügen. Auf die Schnittstellen in einer Zone werden dann die Regeln für diese Zone angewandt. Eine Schnittstelle kann normalerweise nur in einer Zone sein. Einfaches Beispiel: Du hast eine Firewall an der es zwei "interne" Netzwerk-Schnittstellen gibt (sagen wir mal eine für Wifi und eine für LAN), und eine "externe" Schnittstelle die zum Internet geht. Nun willst Du für die Clients sowohl im Wifi als auch im LAN die gleichen Firewallregeln für den Internetzugriff anwenden. Du kannst natürlich nun alle Regeln mehrfach schreiben, jeweils für Wifi->Extern und LAN->Extern. Manche Firewalls bieten auch die Möglichkeit in einer Policy mehrere Quell/Ziel Schnittstellen anzugeben. Eleganter geht es jedoch mit Zonen: Du weist Deine Wifi und LAN Schnittstelle der Zone "intern" zu, und Deine Schnittstelle zum Internet der Zone "extern". Dann kannst Du in der Firewall-Policy statt den Schnittstellen die Zonen verwenden. Wenn Du später ggfs. ein weitere interne Netzwerkschnittstelle hinzufügst, musst Du sie nur der Zone "intern" zuweisen und schon werden die gleichen Regeln für diese Schnittstelle angewendet. In eine DMZ stellst Du ja gemeinhin Deine Server. Nehmen wir an, Du hättest jetzt mehrere DMZ-Netzwerke an mehreren Schnittstellen, auch dann könntest Du Dir mit der Zonen-Zuordnung das Leben erleichtern. Ich kenne firewalld jetzt nicht, aber was ich gelesen habe, verwendet dieser die Zonen um darüber einen (vor)definierten Regelsatz anzuwenden. Bei kommerziellen Firewalls die ich so gesehen habe (Cisco, Fortinet, Checkpoint) waren Zonen (wenn überhaupt vorhanden) eher optional, also man konnte sie einsetzen, musste es aber nicht. Natürlich kann man den Begriff "Zone" auch einfach so verwenden ohne damit direkt das technische Feature auf einer Firewall zu meinen. Also die berühmte "DMZ" ist so ein Beispiel. Nur weil sie DMZ heißt, muss man sie auf der Firewall nicht mit einem "Zonen" Feature konfigurieren. Das Wort "Zone" meint hier einfach ein Netzwerk für das besondere restriktive Regeln gelten (sollten). PS: Einige Details wurden hier bewusst weggelassen
:
Bearbeitet durch User
Marci W. schrieb: > Andere Fragen meinerseits wären z.B., ob die Portfreigaben oder -Sperren > jeweils in beide Richtungen wirken usw. Da in einer Kommunikation die Pakete üblicherweise in beiden Richtungen laufen, öffnet das erste Paket einer zugelassenen Kommunikation implizit die dazu passende Gegenrichtung. Bei TCP wird dazu der TCP-Kopf ausgewertet und daraus der Status abgeleitet. Bei UDP gibts das nicht, da läuft eine ungenutzte Verbindung nach einer Weile aus. Bissel schwieriger wird es bei Protokollen, die neben einer steuernden Hauptverbindung noch ad hoc sekundäre Verbindungen aufmachen, deren Ports frei ausgewürfelt werden. FTP, RPC, SIP, ... Da muss die Firewall die Hauptverbindung mitlesen und die darin aufgeführten Sekundärverbindungen entsprechend öffnen. Gand fies wird es dann, wenn die Hauptverbindung verschlüsselt ist.
DEr Begriff der Zone wird einfach für eine Gruppe mit identischen Regelungen verwendet, wobei man der Zone einen tollen Namen geben kann. Die DMZ=Demilitarisierte Zone z.B. hat überhaupt keine "Bewachung"=Einschränkungen und stellt den oder die in diese Zone zugeordneten Ports oder Rechner ungeschützt ins WAN, auch als Exposed Host bekannt wenn es sich um nur einen Rechner handelt. Entsprechend werden andere Zonen benannt und verwendet. Der Begriff kommt einfach daher, das man ja um sein Netzwerk (= eine Stadt) eine MAuer (die Firewall) baut, aber intern in der Stadt hat man "Kulturzentrum", "Verwaltung", "Wohnungen", "Industriegebiet", "Flughafen". Das sind alles Zonen, die auf verschiedene Arten mit der Außenwelt Kontakt aufnehmen können.
Marci W. schrieb: > Und bei firewalld (die nutze ich) gibt es noch viel mehr Zonen. Der Zonenbegriff ist nicht so ganz festgelegt und kann je nach Produkt etwas unterschiedliche Bedeutung haben. In den schon genannten Enterprise Firewalls fassen sie Interfaces zusammen. Eine bestimmte IP-Adresse kann dabei nur in einer Zone liegen. Im firewalld können Zonen neben dieser Rolle auch für frei wählbare IP-Bereiche stehen. Eine IP-Adresse kann im Prinzip zur Bereichsdefinition mehrerer Zonen passen, wobei dann weitere Eigenschaften der Zonendefinition das letztlich entscheiden.
Jens M. schrieb: > DEr Begriff der Zone wird einfach für eine Gruppe mit identischen > Regelungen verwendet Das ist eine bestimmte Interpretation einer Zone, aber nicht universell gültig. > Die DMZ=Demilitarisierte Zone z.B. hat überhaupt keine > "Bewachung"=Einschränkungen und stellt den oder die in diese Zone > zugeordneten Ports oder Rechner ungeschützt ins WAN, Wäre dem so, bräuchte man sie nicht. Eine DMZ als eigene Zone wird selbstverständlich auch gegen unbefugten Zugriff abgesichert. > auch als Exposed Host bekannt Eine DMZ als Zone für kontrolliert geöffnete Services ist fast schon das Gegenteil eines exposed host. > eine MAuer (die Firewall) baut Diese Analogie könnte eher verwirren, denn Netze mit DMZ haben typischerweise mindestens 3 getrennte Zonen: draussen/untrusted, drinnen/trusted, und eben die DMZ. Die Analog zur Stadtmauer passt dazu nicht wirklich, denn in diesem Modell muss Datenverkehr zwischen allen Zonen eine Mauer passieren.
:
Bearbeitet durch User
Es empfiehlt sich, zwischen Firewalls als Netzwerkkomponenten und Firewalls als Sicherheitselement von Betriebssystemen zu unterscheiden. Ein typischer Anwendungsfall von firewalld ist - wie es hier die Aufgabe ist - die Services eines einzelnen Servers mit nur einem Interface nach aussen abzusichern (mitunter auch in die andere Richtung). Wobei in diesem Kontext "aussen" alles ist, das nicht auf dem Server selbst sitzt, und "innen" das ist, was auf dem Server läuft. Firewalls als Netzwerkkomponenten verbinden mehrere Netze und hier ist dann "aussen" das Internet, "innen" das lokale Netz und eine evtl vorhandene DMZ ist ein weiteres abgetrenntes Netz. Das lässt sich auch kombinieren. Etwa indem bei mehreren Servern in einer DMZ die auf jedem davon aktiven firewallds diese Server gegeneinander abschotten. Die Netzwerkfirewall kann dies nicht, sichert aber gegenüber den anderen Zonen ab.
:
Bearbeitet durch User
Marci W. schrieb: > da ich für die Web-Entwicklung lokal > ein LAMP-System einrichten möchte. Und da möchte ich dann alles zumachen > bis auf die notwendigen http- und https-Ports etc. An deiner Stelle würde ich mir da nicht nur um die Ports Gedanken mache, sondern viel eher um die verwendeten IP-Adressen. Im einfachsten Fall richtest du den Apache und MySql so ein das diese nur auf der IP 127.0.0.1 "lauschen" (binding). Damit sind diese von einer NIC mit externer Anbindung garnicht erreichbar, nur von dem Rechner selbst aus. Man kann sich auch eine Virtuelle NIC einrichte (natürlich ohne bridge zu einer anderen) und da was aus dem Bereich 192.x.x.x. verwenden. Diese sind von extern auch nicht erreichbar usw. Generell kannst du den beiden recht detailliert sagen auf welcher IP (ggf. mehreren) und Port sie reagieren sollen. Die Defaulteinstellung ist halt nur das sie auf alle IP ohne Einschränkungen reagieren. - https://httpd.apache.org/docs/2.4/bind.html - https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_bind_address
Hallo Leute, zuerst einmal herzlichen Dank für Eure ausführlichen Antworten! Jetzt kann ich auch nachvollziehen, warum ich mir mit den Begrifflichkeiten und Funktionen einer Firewall schwer tue. ;-) (Ist nett gemeint! Schon dieser Thread hier zeigt, dass das Thema doch nicht ganz so "straight forward" ist). Hatte mich schon gewundert, denn normalerweise bin ich nicht "auf den Kopf gefallen". ;-) Ich bin auch ganz ehrlich: so richtig verstehen tu ich die Sache noch immer nicht. Ich schau mir mal nach guter (deutscher *) ) Doku im Netz, oder nach Büchern. *) Ich kann zwar recht gut (technisches) Englisch. Aber bei ansprechendem Inhalt und dazu noch in englisch, da tue ich mich schwer. Hatte schon mal versucht, höhere Mathe in englisch zu lesen (Schaum's outlines). Macht keinen Spaß. Liebe Grüße Marci
Die meisten Firewalls sind sog. "Paketfilter" und entfalten ihre Wirkung auf OSI-Layer 3 (IP). Jedes IP-Paket wird zunächst nach seinen Merkmalen gekennzeichnet: - Richtung (LAN->WAN oder umgekehrt) - Quell- und Ziel-Interfaces (phys. Ports) - Quell- und Ziel-IP oder IP-Bereiche ("Range") - transportierte Protokolle/Dienste (z.B. UDP/TCP auf Layer 4 oder HTTP/SIP/RTP auf Layer 5) - Quell- und Ziel-Port bzw. Port-Bereiche Diese Eigenschaften werden mit Regeln verknüpft, z.B.: - Forward (darf durch) - Drop (darf nicht durch, keine Meldung an den Sender) - Reject (darf nicht durch, Meldung an den Sender) - next Rule (nächte Regel) Daraus flechtet der Admin nun ein komplexes Regelwerk, was einerseits die beabsichtigte Funktion des Netzwerkes gewährleistet und anderseits Sicherheitsrisiken soweit als möglich behindert. Da die Angelegenheit recht komplex ist, bieten manche Firewall-Produkte vorgefertigte Regelsätze, auch oft "Profile" genannt, z.B. für die IP-Telefonie. Ganz prinzipiell gibts (theoretisch) zwei Maximal-Strategien: - erstmal "alles zu" und nach und nach die notendigen Durchgänge schaffen. Das ist sehr sicher, aber auch sehr arbeitsaufwändig, irgendwer nörgelt immer, dass irgendwas nicht funzt - erstmal "alles auf" und dann nach und nach Sicherheitsrisiken aussperren. Dann jammer zwar keiner, aber die Gefahr, etwas zu übersehen, ist immanent Ach ja ... speziell für die IP-Telefonie gibts noch eine "Spezialversion" von Firewall, der sog. "SBC" (session border controller). Die Klangqualität bei VOIP leidet besonders unter Latenzen (Laufzeitverzögerung) und deren (auslastungsabhängigen) Schwankungen, dem sog. "Jitter". Das versucht man durch optimierte Hard- u. Software zu vermeiden. Zusätzlich können SBCs noch die verwendeten Codecs der Audio- und Videostreams (seit SIP2 gehört auch Bildübertragung dazu), "on the fly" umcodieren. Das schafft Sicherheit und vereinfacht intern die Konfiguration der Endgeräte ...
Bisher kamen noch keine erklaerten Beispiele. Du hast einen Router, zB von der Telekom, der hat von aussen eine IP : zB 93.57.132.34, die wird dynamisch von der Telekom zugewiesen. Egal. Der Router hat nach innen 172.16.0.1, und spannt so das 172.16.x.x Netz auf. Das 172.16.x.x ist als privates Netz definiert und sollte nicht im internet geroutet werden. In dem stecken alles 172.16 -er devices, zB dein Webserver, als 172.16.0.2. Auf 172.16.0.3 is ein NAT Router, ein Guenstiger. Der ist aussen als 172.16.0.3 konfiguriert, von innen als 192.168.1.1, der spannt das 192.168.1.x Netz auf. Die lokale Zone, nit deinen PC's. Der hat als Gateway 172.16.0.1. eingetragen. Bedeutet, alles in diesem Netz, welches als Destination etwas anderes wie 192.168.1.x hat, aber nicht in der 172.16.0 Zone ist, wird durch diesen Router an 172.16.0.1 weitergeleitet. Der leitets dann nach aussen. Alles zum 172.16.xx Netz kann vom lokalen Router direkt addressiert werden. Das 192.168.x.x Netz ist auch als privates Netz definiert und sollte nicht im Internet geroutet werden. Das NAT, Network Address Translation, bewirkt nun, dass sich der lokale und der auessere Router merkt welche IP was nach aussen sandte. Und diese IPs duerfen nun etwas zurueck senden. Andere IPs kommen gar nicht erst rein. Den einen Webserver, welcher von aussen erreichbar sein soll, bekommt ein Portforwarding, Alles an den Web Server wird and 172.16.0.2 weitergeleitet. Der Webserver ist als http & https Server konfiguriert, und das Portforwarding geht nur fuer dieses Protokol. Der Webserver kann vom lokalen Netz als 172.16.0.2 erreicht werden. Aber umgekehrt geht nichts. denn der Webserver kann kein 192.168.1.x addressieren. Vollstaendig .. wahrscheinlich nicht.
:
Bearbeitet durch User
Hallo lieber Purzel H., sorry, habe Deinen ausführlichen Beitrag erst heute entdeckt! Hatte die letzten Tage auch keine Zeit mehr für das Thema "Firewall verstehen". Ich werde mir Deine Ausführungen mal genau durchlesen und versuchen, zu verstehen. A bissle peinlich ist mir der Thread ja schon. Ich bin jetzt zwar kein Admin, aber das Thema "Informatik" und "Elektronik" war immerhin Teil meines Studiums. <schäm>. Bisher hab ich einfach immer alles im Router und in der Firewall auf meinen Rechnern dicht gemacht. Ab und zu mal nen einfachen Online-Portscanner aufgerufen, um zu sehen, ob wirklich alles dicht ist. Das hat mir gereicht. Aber da ich nun "intern" a bissle was machen möchte, will ich jetzt schon genau wissen, wie das Ganze im Detail funktioniert. Also, nochmal herzlichen Dank und viele Grüße! ciao Marci
Purzel H. schrieb: > Das NAT, Network Address Translation, bewirkt nun, NAT ist eine veraltete Technologie, die gar nichts mit Firewalls zu tun hat. Das sorgt hier nur für Verwirrung. Es ist vielmehr nur eine Krücke, um Routing zwischen Netzen mit überlappenden Adressbereichen zu ermöglichen. Das hat aber mit Zugangskontrolle (a.k.a. Firewall) nichts zu tun. Die firewallähnliche teil-blockierende Wirkung einer NAT ist nur eine in der Regel unerwünschte Nebenwirkung. In modernen IPv6-Netzen braucht man das alles nicht. Kann also hier ignoriert werden, um das Verständnis zu vereinfachen.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Es empfiehlt sich, zwischen Firewalls als Netzwerkkomponenten und > Firewalls als Sicherheitselement von Betriebssystemen zu unterscheiden. Naja, die "Sicherheitselemente von Betriebssystemen" werden zwar gerne euphemistisch als "Firewall" bezeichnet und benutzen auch eine ähnliche Technik, aaaber... die Profis halten sie für nutzloses Schlangenöl. Ein korrekt konfigurierter Host braucht so etwas nämlich gar nicht: darauf lauschen die Dienste, die der Host anbieten soll, auf definierten Ports, und auf allen andern Ports lauscht nichts. "Lauscht nichts" heißt hier: wenn jemand irrtümlich oder absichtlich ein Paket an einen solchen Port schickt, dann sendet der Host bei TCP ein Paket mit dem RST-Flag (Reset) oder ignoriert das Paket im Fall von UDP. "Geschlossene" Ports, also die, auf denen kein Dienst auf Anfragen lauscht, sind also eh kein Problem, außer man geht von einem Fehler im IP-Stack des Betriebssystems aus, und dann helfen "Personal" oder "Desktop Firewalls" ohnehin auch nichts mehr. Das Problem sind daher die berühmt-berüchtigten "offenen Ports", mithin jene, auf denen ein Dienst lauscht. Dabei könnten "Personal" oder "Desktop Firewalls" tatsächlich etwas nutzen, um nämlich die Möglichkeit zu unterbinden, daß Pakete an diese Ports und damit an die dort lauschenden Dienste gesendet werden. Allerdings ist mir keine auch nur halbwegs professionelle Serversoftware bekannt, bei der man nicht in dieser Serversoftware einschränken kann, von wem sie Pakete annimmt... Ansonsten ist ein Firewall vor einem legitimen Dienst natürlich Unsinn, weil dann niemand mehr den Dienst nutzen kann, das heißt: Pakete für diesen Dienst müssen die "Personal" oder "Desktop Firewalls" ohnehin durchlassen, und helfen in diesem Fall überhaupt gar nichts. "Personal" und "Desktop Firewalls" helfen also nur Leuten, die zu faul sind ihre Maschine richtig zu konfigurieren -- und ansonsten vielleicht noch den Leuten, die bestimmte ausgehende Kommunikation unterbinden wollen. Aber das ist dann auch wieder so ein Problem, denn privilegierte Software, die auf dem Host läuft, den das "Firewall"-Spielzeug schützen soll, kann sich die gewünschten Kommunikationswege selbst freigeben, wie das zum Beispiel ein paar Microsoft-Programme machen sollen. Im Endeffekt versuchen diese "Personal" oder "Desktop Firewalls" das Problem zu hoher Komplexität zu lösen, indem sie weitere Komplexität hinzufügen. Das ist mindestens kontraproduktiv, wenn nicht bescheuert. In der Anfangszeit der "Personal" oder "Desktop Firewalls" ist es mehrmals vorgekommen, daß sie Sicherheitslücken hatten und es einem Angreifer so überhaupt erst ermöglicht haben, einen Host zu kompromittieren, der ohne "Personal" oder "Desktop Firewall" völlig safe gewesen wäre. Erschwerend kommt hinzu, daß Angriffe längst ganz anders, nämlich über Sicherheitlücken in legitimen Dienste und Social Engineering erfolgen. Gegen solche Angriffe helfen "Personal" oder "Desktop Firewalls" genau überhaupt gar nichts, im Gegenteil: da der Benutzer wegen des "Personal" oder "Desktop Firewall" glaubt, er sei gut geschützt, könnte er höhere Risiken eingehen. Das kennen wir von den Anfangszeiten des ABS in Autos, Fachleute sprechen dabei von Risikokompensation. Letzten Endes verkaufen "Personal" oder "Desktop Firewalls" nicht mehr als eine Illusion: nämlich die Illusion, man könne sich schützen, indem man irgendeine Software installiert, auf deren Verpackung groß und blinkend "Sicherheit auf Knopfdruck" steht. Damit waren die Malwarescanner schon ausgesprochen erfolglos... Cracker lesen keine blinkenden Schriften auf Shrinkwrap-Verpackungen, sondern Manuals. Vielleicht werden sie deswegen häufig mit Hackern verwechselt... :-) Der allerbeste Schutz jedes Computernutzers ist kein technischer, sondern befindet sich zwischen seinen Ohren. > Firewalls als Netzwerkkomponenten verbinden mehrere Netze Auch wenn ich natürlich weiß, was Du meinst, habe ich ein kleines Problem mit dieser Formulierung. Ein Firewall -- also nicht das Spielzeug von oben -- dient nicht der Verbindung, sondern der Trennung von Netzwerken. Der Firewall unterbindet dann die gesamte Kommunikation mit Ausnahme derer, die explizit zugelassen wurde -- und im Zweifelsfall kann der sogar noch etwas eine Menge mehr als ein blöder Paketfilter, nämlich in die Pakete hinein schauen und qualifizierte Entscheidungen anhand ihrer Protokollheader oder sogar anhand ihrer Inhalte (think Web Application Firewall) treffen.
MaWin O. schrieb: > NAT ist eine veraltete Technologie, die gar nichts mit Firewalls zu tun > hat. > Das sorgt hier nur für Verwirrung. Bisher sehr ich SNAT und DNAT nicht als veraltete Technologie an, dazu ist sie viel zu weit verbreitet. Sonst hast Du zwar hinsichtlich der Theorie vollkommen Recht, SNAT ist kein Firewall, unterbindet aber trotzdem eine unerwünschte Kommunikation von außen in das geSNATtete Netz. Das ist noch so ein Grund, warum viele Anwender von "Personal" oder "Desktop Firewalls" diesen Unsinn gar nicht brauchen, denn: von außen kann ja ohnehin niemand irgendwas in das Netzwerk hinter ihrem Router (okay, Gateway...) schicken, sofern dort kein DNAT eingerichtet ist. ;-)
Sheeva P. schrieb: > (prx) A. K. schrieb: >> Es empfiehlt sich, zwischen Firewalls als Netzwerkkomponenten und >> Firewalls als Sicherheitselement von Betriebssystemen zu unterscheiden. > Naja, die "Sicherheitselemente von Betriebssystemen" werden zwar gerne > euphemistisch als "Firewall" bezeichnet und benutzen auch eine ähnliche > Technik, aaaber... die Profis halten sie für nutzloses Schlangenöl. Ich hätte nicht erwartet, dass du beispielsweise das, was hinter iptables steht, in Bausch und Bogen als Schlangenöl verurteilst. ;-) Zum Begriff: Egal was ich für einen Unsinn mache und erzähle, bin ich doch zweifelsfrei ein Profi bei diesem Thema, denn ich habe damit beruflich nicht unerheblich zu tun. Da gibts halt auch solche und solche. ;-) > Ein > korrekt konfigurierter Host braucht so etwas nämlich gar nicht: darauf > lauschen die Dienste, die der Host anbieten soll, auf definierten Ports, > und auf allen andern Ports lauscht nichts. Man kann mit nicht nur auf Ports filtern, sondern auch auf IP-Ranges. Das kann sehr sinnvoll sein, weil beispielsweise ein Service, der nur fürs Management eines Servers verwendet wird, auch nur von den Management-Systemen angesprochen werden kann, und nicht auch vom Nachbarserver im gleichen Netz. Es führen zwar oft viele Wege nach Rom, etwa hosts.allow/deny, sshd.conf etc, aber man kann das weniger zerfleddert eben auch mit firewalld&Co machen. >> Firewalls als Netzwerkkomponenten verbinden mehrere Netze > > Auch wenn ich natürlich weiß, was Du meinst, habe ich ein kleines > Problem mit dieser Formulierung. Ein Firewall -- also nicht das > Spielzeug von oben -- dient nicht der Verbindung, sondern der Trennung > von Netzwerken. Gerne auch so herum. Sie sitzen halt dazwischen und tun beides, kontrolliert verbinden und kontrolliert trennen. Wenn vorher ein Switch oder Router dazwischen war, dann trennen sie, war es Luft, dann verbinden sie. Von solcher Sophisterei habe ich noch mehr, wenn gewünscht. ;-)
:
Bearbeitet durch User
Sheeva P. schrieb: > Das ist noch so ein Grund, warum viele Anwender von "Personal" > oder "Desktop Firewalls" diesen Unsinn gar nicht brauchen, denn: von > außen kann ja ohnehin niemand irgendwas in das Netzwerk hinter ihrem > Router (okay, Gateway...) schicken, sofern dort kein DNAT eingerichtet > ist. ;-) Die Vorstellung, dass es ein gefährliches "Draussen" und ein ungefährliches "Drinnen" gibt, ist jenseits einfacher Heimnetze schon lange Vergangenheit. In grösseren Umgebungen ist längst wichtig, Systeme auch im "Drinnen" gegeneinander abzusichern. Man kann darüber diskutieren, welchen Sinn "Personal Firewalls" für Normalanwender haben (*), aber die Windows-Firewall sehe ich analog zu dem, was ich vorhin über die Linux-Pendants schrieb, nicht als sinnlos an. *: Etwa wenn eine solche Firewall einen Port blockt, den man auch direkt in services.msc per Deaktivierung des solchen Anwendern zweifellos gut bekannten Dienstes "KeineAhnungWassDasSeinSoll" loswird. Letzteres ist natürlich technisch besser, aber diesem Anwender schwerer zu vermitteln. Auch sehe ich die Zonendefinition in Microsofts Firewall nicht als völlig sinnfrei an. Besonders nicht bei Mobilgeräten.
:
Bearbeitet durch User
Marci W. schrieb: > In den Dokus, Tutorials und config-Tools zu Firewalls taucht immer > wieder der Bergiff "Zone" auf. Bei einfachen Varainten gibt es eine > öffentliche, demilitarisierte und interne Zone. > > Was ich weiß: die Zone ist eine (logische?, virtuelle?, gedachte?) > Abgrenzung zwischen verschiedenen Bereichen in einem Netzwerk. Im Grunde ist eine Zone nichts anderes als ein Netzwerk. Der Firewall ist dann dafür zuständig, zu steuern, was wie mit wem zwischen den Netzwerken kommunizieren darf. Ich habe Dir mal mit dem Programm dia [1] einen groben Plan einer klassischen Infrastruktur eines Unternehmens gezeichnet, um das etwas zu verdeutlichen. Betrachten wir zunächst die drei Wölkchen: ganz oben das Internet, das ist da, wo die bösen Buben leben (nicht ganz richtig, später mehr dazu). Dann folgt eine DMZ, eine demilitarisierte Zone, dort leben Deine Server. Und unten gibt es das lokale Netzwerk der Firma, das "Firmen-LAN", in dem die Rechner der Mitarbeiter leben -- und die schützenswertesten Informationen gespeichert haben. Die DMZ ist dabei ein spezielles Netzwerk, in dem die Server stehen, auf die vom Internet aus zugegriffen werden soll (und meistens muß). Wenn Du beispielsweise eine Webagentur betreibst, werden dort womöglich Webserver stehen, die Deine CMS-Systeme betreiben und Deine Webseiten ausliefern -- und die Datenbankserver, die Deine CMS-Systeme zur Speicherung ihrer Daten benötigen. Aber schon hier siehst Du unterschiedliche Zugriffsmuster: die Webserver sollen ihre Seiten ja im Internet anbieten, und müssen deswegen auch aus dem Internet erreichbar sein. Die Datenbankserver dagegen müssen nur mit den Webservern reden und nicht aus dem Internet erreichbar sein. Unter anderem stellt genau das der Perimeter Firewall sicher: einerseits, daß die Webserver aus dem Internet über HTTP(S) erreichbar sind, aber dann andererseits auch, daß niemand aus dem Internet an die Datenbankserver kommen kann. Das ist relativ easy: der Perimeter Firewall blockiert allen eingehenden Verkehr aus dem Internet, und läßt nur Zugriffe vom Internet auf die Ports 80 (HTTP) und 443 (HTTPS) der Server web1, web2 und web3 in der DMZ zu. Die Datenbankserver sind vom Internet aus gar nicht erreichbar (trotzdem müssen die Systeme natürlich abgesichert sein für den Fall, daß der Angreifer einen der Webserver kompromittieren kann...). Die DMZ ist damit eine Zone -- oder ein Netzwerk -- dem der SysOp besondere Sorgfalt und Fürsorge angedeihen läßt, weil es vom Internet aus erreichbar und so ganz besonders gefährdet ist. Danach folgt ein zweiter, der Interne Firewall, der (im Idealfall) nur Datenverkehr aus dem Firmen-LAN ins Internet leiten kann und vom Internet oder der DMZ aus keine Zugriffe auf das Firmen-LAN zuläßt. Dieser Interne Firewall soll oft auch bestimmte Aktivitäten der Mitarbeiter verhindern, beispielsweise das Surfen auf Erwachsenenseiten während der Arbeitszeit. Deswegen nutzt dieser Firewall häufig eine andere Technologie, nämlich einen Proxy: der entscheidet über das Zulassen und Verweigern bestimmter Verbindungen nicht mehr nur anhand von Quell- und Zieladressen, Protokoll, Verbindungszustand, Paketflags etc., sondern ein Proxy schaut viel tiefer in die Datenpakete hinein und kann zum Beispiel erkennen (und verhindern), wenn Dein Kollege Videos von einer Erwachsenenseite sehen möchte. Mein Schaubild ist nun ganz bewußt besonders einfach gehalten, und es gibt nahezu unendlich viele Abwandlungen mit mehreren DMZs, Internen Firewalls, Firmen-LANs und so weiter. Denn die Erfahrungen und verschiedene Studien sagen: die meisten Angriffe auf Unternehmensnetze kommen nicht von außen, da sind sie ja abgesichert, sondern von innen. Was ist also ein Firewall? Ein Firewall ist ein Konzept zur Trennung von Netzwerken. Ob diese Netzwerke nun "Zone" oder "Netz" oder wie auch immer heißen, spielt dabei keine Rolle: der Firewall hat die Aufgabe, nur genau die erlaubte Kommunikation zwischen Rechnern zuzulassen, und alles andere wirksam zu verhindern. Das heißt, daß Firewalls besondere Aufmerksamkeit benötigen, bei Setup, Härtung, Monitoring, Logging, Intrusion Detection, und natürlich: beim Aufsetzen der Regeln, welche Kommunikation zulässig, und welche verboten ist. [1] http://dia-installer.de/
(prx) A. K. schrieb: > Ich hätte nicht erwartet, dass du beispielsweise das, was hinter > iptables steht, in Bausch und Bogen als Schlangenöl verurteilst. ;-) Nein, Iptables, Netfilter, IP, IPFW und IPFILTER und so das sind extrem nützliche Werkzeuge, keine Frage. Aber die sind ja alle keine "Personal" oder "Desktop Firewalls", sondern sind viel leistungsfähiger als irgendein Kinderquatsch, der auf dem zu schützenden Horst läuft... :-) > Zum Begriff: Egal was ich für einen Unsinn mache und erzähle, bin ich > doch zweifelsfrei ein Profi bei diesem Thema, denn ich habe damit > beruflich nicht unerheblich zu tun. Da gibts halt auch solche und > solche. ;-) Ich weiß das und würde Deine Expertise niemals anzweifeln!!1! > Man kann mit nicht nur auf Ports filtern, sondern auch auf IP-Ranges. Kennst Du denn eine professionelle Software in einem professionellen Netz, wo das nicht möglich ist? > Es führen zwar oft viele Wege nach Rom, > etwa hosts.allow/deny, sshd.conf etc, aber man kann das weniger > zerfleddert eben auch mit firewalld&Co machen. Die Konfigurationsdateien meiner Daemons muß ich doch eh anpassen, oder? > Gerne auch so herum. > > Sie sitzen halt dazwischen und tun beides, kontrolliert verbinden und > kontrolliert trennen. Naja, ich wollte auf "kontrolliert" hinaus... :-) > Wenn vorher ein Switch oder Router dazwischen war, > dann trennen sie, war es Luft, dann verbinden sie. Von solcher > Sophisterei habe ich noch mehr, wenn gewünscht. ;-) Please go ahead! ;-)
(prx) A. K. schrieb: > *: Etwa wenn eine solche Firewall einen Port blockt, den man auch direkt > in services.msc per Deaktivierung des solchen Anwendern zweifellos gut > bekannten Dienstes "KeineAhnungWassDasSeinSoll" loswird. Letzteres ist > natürlich technisch besser, aber diesem Anwender schwerer zu vermitteln. > Auch sehe ich die Zonendefinition in Microsofts Firewall nicht als > völlig sinnfrei an. Besonders nicht bei Mobilgeräten. Ich habe zwar Zertifikate als MCSE und MCDE, aber für WinNT4. Seitdem (1998, 1999) habe ich mit Microsoft-Produkten erfreulicherweise keine Berührungspunkte mehr... Ein Herzinfarkt reicht mir. :-)
Sheeva P. schrieb: > Unter anderem stellt genau das der Perimeter Firewall sicher: > Danach folgt ein zweiter, der Interne Firewall, Nja, Begriffe. Eine Firewall kann eine abstrakte Funktion sein, oder ein Gerät. Je nachdem, auf was davon man sich bezieht, ändert sich das Bild. Als abstrakte Funktion trennt diese Brandmauer exakt zwei Netze, so wie dargestellt. Wobei dann meistens ein Dreieck draus wird, mit 3 Brandmauern: Aussen-DMZ, Innen-DMZ, Aussen-Innen. Denn eine DMZ ist jenseits einfachster Umgebungen kein Zwischennetz zwischen drinnen und draussen. Als Geräte betrachtet, übernimmt eine Perimmeter-Firewall beide deiner dargestellten Funktionen. Typischerweise mindestens mit einem Interface nach draussen, einem nach drinnen, und einem zur DMZ. Interne Firewalls wiederum haben in meinem Verständnis dieses Begriffes die Aufgabe, mehrere interne Netze kontrolliert zu koppeln.
Sheeva P. schrieb: > Die Konfigurationsdateien meiner Daemons muß ich doch eh anpassen, oder? Zusammengefasst im Ruleset einer Betriebssystem-Firewall finde ich es zumindest übersichtlicher, lesbarer, als verstreut über ein Dutzend Configfiles, die alle ein wenig anders funktionieren.
:
Bearbeitet durch User
Sheeva P. schrieb: > Ich habe zwar Zertifikate als MCSE und MCDE Ich würde Deine Expertise doch niemals anzweifeln!!1!
Sheeva P. schrieb: > (prx) A. K. schrieb: >> Ich hätte nicht erwartet, dass du beispielsweise das, was hinter >> iptables steht, in Bausch und Bogen als Schlangenöl verurteilst. ;-) > > Nein, Iptables, Netfilter, IP, IPFW und IPFILTER und so das sind extrem > nützliche Werkzeuge, keine Frage. Aber die sind ja alle keine "Personal" > oder "Desktop Firewalls", sondern sind viel leistungsfähiger als > irgendein Kinderquatsch, der auf dem zu schützenden Horst läuft... :-) Viele können uns noch an fefe in de.comp.decurity.firewall erinnern, da wurde die Personal/Desktop Firewall von ihm als erstes mit "Schlangenöl" tituliert. Das dürfte mittlerweile ca. 20 Jahre her sein. Du erzählst uns also hier nix neues :-) P.S. de.comp.decurity.firewall hatte ich damals vorwiegend wegen fefe gelesen. Es war einfach nur eine Wonne, seine Postings zu "erleben". Dagegen ist dieses Forum harmlos ;-)
Beitrag #7420407 wurde vom Autor gelöscht.
Sheeva P. schrieb: > Ich habe Dir mal mit dem Programm dia [1] > einen groben Plan einer klassischen Infrastruktur eines Unternehmens > gezeichnet, um das etwas zu verdeutlichen. Danke für das Tool. Als Beispiel (für den TE und andere), wie es in Unternehmen heutzutage mindestens aussieht (oder sollte), wenn man den Begriff "Firewall" auf die so genannten Komponenten bezieht. Wenn man das auf die einzelnen Brandmauern runterbricht, wirds unübersichtlich.
:
Bearbeitet durch User
Frank M. schrieb: > Viele können uns noch an fefe in de.comp.decurity.firewall erinnern, da > wurde die Personal/Desktop Firewall von ihm als erstes mit "Schlangenöl" > tituliert. Das dürfte mittlerweile ca. 20 Jahre her sein. > > Du erzählst uns also hier nix neues :-) Dir und prx vermutlich nicht, aber trotzdem scheinen immer noch viele Menschen dankbar an der Konzept "Erhöhung der Sicherheit durch Hinzufügen von fehleranfälliger Komplexität" zu glauben. Schließlich ist es ja viel einfacher, schnell irgendein obskures Zeug mit der Aufschrift "sicher" zu installieren, als seinen Rechner richtig zu konfigurieren. ;-) Ich hab dcsf übrigens nicht nur wegen Fefe, sondern vor allem wegen Lutz Donnerhacke gelesen...
(prx) A. K. schrieb: > Sheeva P. schrieb: >> Ich habe Dir mal mit dem Programm dia [1] >> einen groben Plan einer klassischen Infrastruktur eines Unternehmens >> gezeichnet, um das etwas zu verdeutlichen. > > Danke für das Tool. Gerne, viel Vergnügen damit! :-) > Als Beispiel (für den TE und andere), wie es in Unternehmen heutzutage > mindestens aussieht (oder sollte), wenn man den Begriff "Firewall" auf > die so genannten Komponenten bezieht. Wenn man das auf die einzelnen > Brandmauern runterbricht, wirds unübersichtlich. Klar, aber ich finde "Server" und "Produktion" in Deinem Schaubild etwas irreführend. Vielleicht wäre "Interne Server" eine bessere Bezeichnung. Keine Ahnung, was mit "Produktion" gemeint ist -- denkt Du dabei etwa an sowas wie Maschinensteuerungen etc.?
Sheeva P. schrieb: > Keine Ahnung, was mit "Produktion" gemeint ist -- denkt Du dabei etwa an > sowas wie Maschinensteuerungen etc.? Ich bezog das Diagramm auf Unternehmen, die nicht nur heisse Luft wie Software produzieren, oder Schaltpläne, die dann in China zusammengelötet werden, sondern sowas mein Standardbeispiel einer Grossbäckerei, bei der es neben einer Verwaltung auch echte Produktherstellung gibt. Produktherstellung mit etlichen Maschinen aller Art und allen Alters ist eine Umgebung, bei der das Equipment u.U. bis Windows NT oder noch weiter zurück reicht und man die auch in frischen Fällen bestenfalls jährlich aktualisiert. In solchen Umgebungen würde ich raten, den Produktionsprozess selbst netztechnisch vom Verwaltungsapparat abzutrennen und den Übergang angemessen zu beschränken. Damit eine faule Mail zwar die Brötchenrezepte und Kundenlisten auf- oder zudeckt, aber die Produktion mit Notfallmassnahmen zur Logistik weitergeführt werden kann. Eine weitere solche interne Zone könnten beispielsweise Geräte wie Drucker oder Webcams und anderes IOT-Zeug sein, die sicherheitstechnisch nicht selten üble Gurken sind. Die willst du nicht als Zwischenstation ins übrige Netz missbraucht sehen wollen.
Sheeva P. schrieb: > Klar, aber ich finde "Server" und "Produktion" in Deinem Schaubild etwas > irreführend. Vielleicht wäre "Interne Server" eine bessere Bezeichnung. Das Diagramm ist natürlich nur sehr beispielhaft und irgendwelche allgemeinen Bezeichnungen mussten rein. Server, die direkt mit den genannten Produktsprozessen zu tun haben, aber nicht mit den Allerwelts-PCs der Anwender, gehören natürlich zur Produktions-Zone. Aber für sowas wie allgemeine Fileserver, Login-Server, Office-Kommunikation inklusive Mails - sofern noch lokal und nicht verclouded - Arbeitszeiterfassung uswusf hatte ich in diesem Diagramm die Server-Zone vorgesehen. Die von Anwendern zu trennen und per Firewall zu kontrollieren ist auch sehr sinnvoll. Besonders, wenn die interne Firewall mehr ist, als ein simpler Paketfilter.
:
Bearbeitet durch User
Hallo liebe Leute, OK, verstanden hab ich es schon längst. Ich möchte mich nochmal bei den Leuten, die geantwortet und umfangreiche Erklärungen geschrieben haben, danken, vor allem Sheeva P. und (prx)! Ich denke, das Problem ist, dass mir die Sache prinzipiell zwar völlig klar ist, aber ich einfach keine Ahnung habe, wie das im Einzelnen umgesetzt wird! Sprich: mir fehlt die Praxis! Ich werde nun deshalb ausgiebig mit der Firewall (firewalld) "spielen", denn ich bin mir sicher, dass das Ganze erst dadurch ein Gesicht bekommt. Dennoch git es wieder neue Fragen. Und ich denke, dass noch mehr Fragen kommen werden, wenn ich versuche, firewalld zu konfigurieren. Also hier meine Fragen: Hier hängt ein Speedport Router am WAN. In der Speedport Firewall kann man, wenn ich das richtig sehe, nur die Ports auf- und zumachen. Aktuell habe ich keine Ports offen. Sehe ich richtig, dass dann auch keine Gefahr droht und Angreifer unter keinen Umständen durch die FW kommen? Nun können sich ja auch andere Rechner via WLAN am Speedport anmelden. Ist es dann so, dass diese WLAN-Teilnehmer dann "hinter" der Firewall sitzen, also quasi auf der "internen" Seite, dort, wo auch mein Rechner hängt? So nun könnte ja auch ein Rechner, der auch auf dem Router hängt, versuchen, meinen Rechner anzugreifen. Sehe ich es richtig, dass nun die "Firewall" auf meinem Rechner dies zuverlässig verhindert, wenn ich dort auch alle Ports blockiere? Und wenn ich z.B. dem Zweitrechner den Zugriff auf den Webserver, der auf meinem Rechner läuft, erlauben will, dann mach ich den Port 80 bzw. 443 auf? Und letzte Frage: Obwohl ich weder im Speedport noch auf meinem Rechner irgend einen Port offen habe, kann ich dennoch problemlos im Internet surfen. Sind die Portsperren also nur in einer Richtung wirksam? So wie ich den Thread gelesen habe, kann ich für solche Sachen z.B. ein Proxy einsetzen. Mit dem könnte ich dann solche Dinge erreichen wie: Der Anwender an Rechner 2 kann nur Seiten von meinem Rechner anschauen, aber nicht im "externen" Web surfen? Sorry, dass immer neue Fragen kommen, aber ich will das Thema jetzt entgültig verstehen. Viele Grüße Marci
Marci W. schrieb: > Hier hängt ein Speedport Router am WAN. In der Speedport Firewall kann > man, wenn ich das richtig sehe, nur die Ports auf- und zumachen. Aktuell > habe ich keine Ports offen. Sehe ich richtig, dass dann auch keine > Gefahr droht und Angreifer unter keinen Umständen durch die FW kommen? Im Prinzip ja, wenn du das "unter keinen Umständen" nicht religiös ernst meinst. Aber das näher auszuführen wäre hier nicht angebracht. Für den Hausgebrauch reicht es. > Nun können sich ja auch andere Rechner via WLAN am Speedport anmelden. > Ist es dann so, dass diese WLAN-Teilnehmer dann "hinter" der Firewall > sitzen, also quasi auf der "internen" Seite, dort, wo auch mein Rechner > hängt? Ja. Wenn, wie meist der Fall, das WLAN und das LAN effektiv das gleiche Netz sind. Fritzboxen können jedoch ein Gastnetz haben (Speedports kenne ich nicht), welches vom LAN und vom normalen WLAN abgetrennt ist. > So nun könnte ja auch ein Rechner, der auch auf dem Router hängt, > versuchen, meinen Rechner anzugreifen. Ja. Ausnahme ist das eben genannte Gastnetz. Über dieses Gastnetz kannst du Leute an deinen Router lassen, ohne deine eigenen Rechnet zu gefährden. > Sehe ich es richtig, dass nun die "Firewall" auf meinem Rechner dies > zuverlässig verhindert, wenn ich dort auch alle Ports blockiere? Ebendies ist deren Sinn in einer solchen Konstellation. Wie zuverlässig das ist, ist wieder eine andere Frage, und so ganz von allein konfiguriert sich die nicht. > Sind die Portsperren also nur in einer Richtung wirksam? Richtig. Allerdings haben manche Edge Router auch die Möglichkeit, ausgehend initiierten Traffic einzuschränken. Fritzboxen können dies ein wenig, Stichwort ist Jugendschutz. > So wie ich den Thread gelesen habe, kann ich für solche Sachen z.B. ein > Proxy einsetzen. Mit dem könnte ich dann solche Dinge erreichen wie: > Der Anwender an Rechner 2 kann nur Seiten von meinem Rechner anschauen, > aber nicht im "externen" Web surfen? Wenn du es schaffst, den zweiten Rechner daran zu hindern, am Proxy vorbei zu operieren. Es ist aber nicht die Hauptaufgabe einfacher Edge Router, ausgehend initiierten Traffic zu kontrollieren. Entsprechend eingeschränkt sind sie daher.
:
Bearbeitet durch User
Hi (prx), vielen Dank! So langsam krieg ich ja anscheinend die Kurve... ;-) Gruß Marci
(prx) A. K. schrieb: >> Sehe ich es richtig, dass nun die "Firewall" auf meinem Rechner dies >> zuverlässig verhindert, wenn ich dort auch alle Ports blockiere? > > Ebendies ist deren Sinn in einer solchen Konstellation. Wie zuverlässig > das ist, ist wieder eine andere Frage, und so ganz von allein > konfiguriert sich die nicht. Microsofts Firewall nähert sich diesem Thema über die Klassifikation eines Interfaces in "Privat", "Öffentlich" und so (hab die Begriffe grad nicht genau im Kopf). "Privat" ist dabei relativ offen gegenüber dem eigenen Netz, "Öffentlich" hingegen geschlossen.
:
Bearbeitet durch User
Frank M. schrieb: > de.comp.decurity.firewall hatte ich damals vorwiegend wegen fefe > gelesen. Es war einfach nur eine Wonne, seine Postings zu "erleben". > Dagegen ist dieses Forum harmlos ;-) Robin S. Socha war auch so ein Spezialist, allerdings in einer der Linuxgruppen - wimre.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.