Wie funktioniert eine Firewall?

[Marci W. (Gast)]

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

[Xanthippos (xanthippos)]

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.

[Marci W. (Gast)]

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

[Markus M. (adrock)]

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

[(prx) A. K. (prx)]

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.

[Jens M. (schuchkleisser)]

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.

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

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.

[Irgend W. (Firma: egal) (irgendwer)]

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

[Marci W. (Gast)]

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

[Frank E. (Firma: Q3) (qualidat)]

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 ...

[Purzel H. (hacky)]

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.

[Marci W. (Gast)]

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

[MaWin O. (mawin_original)]

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.

[Sheeva P. (sheevaplug)]

(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.

[Sheeva P. (sheevaplug)]

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. ;-)

[(prx) A. K. (prx)]

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. ;-)

[(prx) A. K. (prx)]

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.

[Sheeva P. (sheevaplug)]

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/

[Sheeva P. (sheevaplug)]

(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! ;-)

[Sheeva P. (sheevaplug)]

(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. :-)

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

Sheeva P. schrieb:
> Ich habe zwar Zertifikate als MCSE und MCDE

Ich würde Deine Expertise doch niemals anzweifeln!!1!

[Frank M. (ukw) (Moderator)]

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 ;-)

[(prx) A. K. (prx)]

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.

[Sheeva P. (sheevaplug)]

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...

[Sheeva P. (sheevaplug)]

(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.?

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

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.

[Marci W. (Gast)]

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

[(prx) A. K. (prx)]

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.

[Marci W. (Gast)]

Hi (prx),

vielen Dank! So langsam krieg ich ja anscheinend die Kurve... ;-)

Gruß

Marci

[(prx) A. K. (prx)]

(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.

[Markus M. (adrock)]

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.