Also, nicht das wir aneinander vorbei reden: In diesem Beitrag geht es ausschließlich um externe >>Network<<-Based-IDS (was im Klartext bedeutet, daß es sich um IDS Sniffer handelt). Im Folgenden nenne ich die Dinger der Einfachheit halber IDS oder IDS-Sniffer.
Für alle anderen Leser: Ein IDS (Intrusion Detection System) besteht aus einer passiven und einer aktiven Komponente. Die passive Komponente versucht durch Sammeln und Analyse von Daten über Rechner, Netzwerk und Netzwerkverkehr mögliche Angiffe zu identifizieren. Die aktive Komponente (IRS) leitet bei einer festgestellten Attacke Gegenmaßnahmen ein.
Hinweis: Externe IDS Sniffer sind in der Regel kein Bestandteil von Firewalls, sondern arbeiten als eigenständige Systeme in geschützten Netzwerken. Aus diesem Grund gehört der Beitrag eigentlich nicht in diesen Thread.
Ein Netzwerk-Based IDS überprüft den Netzwerkverkehr auf Indizien für Angriffe. Dazu zählen neben Portscans oder DoS-Versuchen (wie SYN-Floodings) auch Kontaktversuche zu eventuell installierten Backdoors. Bei letzterem wird oft auch nach bekannten Signaturen in den Datenpaketen gescannt. Das IDS ist manchmal in der Lage, bei einem Angriff die Verbindung des Angreifers zum Zielsystem zu unterbrechen (IRS) und zudem den Angriffsversuch aufzuzeichnen.
Soweit klingt das Konzept ja erst einmal toll. Jedoch sollen IDS Sniffer möglichst den kompletten Datentransfer in einem Netzwerk auf Indizien für einen Angriff untersuchen. Das Problem: Um dies realisieren zu können, müsste er gleichzeitig die Arbeit aller TCP/IP-Stacks im Netzwerk verrichten. Die erforderliche Leistung geben die derzeitigen Systeme aber leider nicht her. IDS Sniffer müssen sich also stets auf eine bestimmte Art der Kontrolle und möglichst auch auf die Überwachung bestimmter Server beschränken. Einem einzelnen IDS Sniffer entgeht also ein beachtlicher Prozentsatz des gesamten Netzwerkverkehrs.
Erkennen IDS Sniffer jedoch einen Angriff, so konzentrieren sie Ihre Überwachung auf diese Verbindung und sind erst so zu einer erweiterten Analyse fähig. Sie sind dann allerdings nicht mehr in der Lage, andere Verbindungen gleichzeitig zu observieren. Und: Da ein IDS Sniffer als passive Komponente nicht wirklich an dem Datenaustausch teilnimmt (Monitor-Mode), ist er nicht in der Lage, in die Verbindung hineinzusehen. So interpretiert er die Pakete nach einem Standartschema und trifft seine Entscheidungen u.a. bezüglich der IP- und TCP-Paketlänge. Da die Pakete nicht wie bei dem Empfänger zusammenhängend betrachtet werden, findet hier z.B. keine Überprüfung der TCP-Prüfsummen statt.
Ein IDS Sniffer, welcher z.B. auf einen bestimmten Server festgelegte Ports überwacht, lässt sich durchaus in die Irre führen: Bevor sich der Angreifer auf das überwachte Zielsystem einloggt, sendet er ein TCP-SYN-Paket mit einer gespooften - also veränderten – Absenderadresse. So täuscht er einen DoS-Angriff vor, der von einem anderen Rechner ausgeht. Falls ein IDS Sniffer aktiv ist, so wird er seine Analyse nun auf die vermeintliche Verbindung zu dem anderen Rechner hin konzentrieren. So kann sich der Angreifer an dem System anmelden, ohne daß der Sniffer die Aktion mitscannt. Sobald der TCP/IP-Stack die dedizierte Überwachung der angeblichen Verbindung wegen eines Timeouts beendet, ist der IDS Sniffer wieder aktiv.
Eine weitere Möglichkeit besteht darin, ein Verbindungsende vorzutäuschen, vorausgesetzt der IDS Sniffer überprüft die TCP-Prüfsummen (Sequenznummern) nicht: Der empfangende Rechner hingegen prüft diese und verwirft alle "falschen" Pakete. So geht der IDS Sniffer z.B. nach einem Paket mit einem FIN- oder RST-Falg von einem Abbruch der Übertragung aus. Befindet sich das Paket jedoch in einem TCP-Paket einer weit entfernten Sequenznummer, so wird der Rechner das Paket verwerfen und mit der Verbindung fortfahren. Der IDS Sniffer hält hingegen die Verbindung für beendet und stellt im ungünstigsten Fall seine Verbindungsüberprüfung ein.
Auch ist er bei einer Änderung der Länge des TCP-Headers und der sporadischen Einschleusung von falschen Prüfsummen oft nicht mehr in der Lage, die Inhalte dieser Pakete korrekt zu interpretieren.
Entgegen Deiner Vermutung können IDS Sniffer übrigens auch einem DoS-Angriff zum Opfer fallen. Sehr erfolgreich lassen sich hierfür fragmentierte IP-Pakete verwenden (ähnlich wie sie von defekten Netzwerkkarten erzeugt werden). Diese werden im allgemeinen vom IDS nicht als Angriff erkannt. Einige Betriebssysteme auf denen die IDS Sniffer aufsetzen, verkraften eine übermäßige Flut diese Pakete nicht und hängen sich auf. Es gibt eine ganze Reihe von solchen Paketen. Einige wurden genauer im Phrack Magazin beschrieben (http://www.phrack.org).
Ich hoffe Deine Neugierde wurde erst einmal gestillt.
Bye, Ronald
PS: Ich kenne die aktuellen IDS Modelle nicht. Ich wäre Dir also dankbar, wenn Du mich auf veralteten Aussagen aufmerksam machen könntest.
... dies alles ist dem Durchschnittsbürger bekannt, und auch hier wieder ebenfalls den Nicht-Fahrradbesitzern.
Und das es Vieren und Hacker gibt, ist dem Durchschnittsbürger nicht bekannt? Ich kenne niemanden, der nicht zumindest weiß, daß er sich um diese Problematik mal kümmern >>müßte<<. Einige "müßten" allerdings schon seit Jahren ... Zudem ist mir seit geraumer Zeit niemand mehr begegnet, der sich einen PC zulegen wollte und von Vieren und Hackern noch nichts gehört hat. Da hat die Aufklärung der letzten Jahre gute Arbeit geleistet.
Von Viren (oder auch Vieren, das mag bei so manchem genau in der Schreibweise zutreffen) und Hackern hat Otto Normal-Aldi-Käufer ein paar mal was gehört, aber bei "Firewall" dürften die meisten nicht-Computerzeitschriftenleser aussteigen. Spätestens bei der Frage, wovor kann eine "Firewall" schützen und wovor nicht, und was muss da eigentlich eingestellt werden, fürchte ich, ist das Wissen in der Computergemeinde unter aller Kanone. Vom gelegentlichen Update der Sicherheitssoftware rede ich da noch nicht mal...
Mal etwas von "Hackern" und "Viren" gehört zu haben, reicht da wohl kaum aus, um "Firewalls" zum Allgemeinwissen zu erklären.
also mit SNORT ist mir das noch net passiert. Der setzt auf der LIBPCAP auf und TCPDUMP entgeht ja in der Regel auch kein Paket.
Die NIC ist im Promiscous Mode, d.h. die "saugt" alle Pakete auf, das Problem von Drops bei GB Ethernet lässt sich durch mehrere parallel angeordnete Sensoren lösen. http://www.snort.org/docs/Gb_tapping.pdf
Darüberhinaus existiert bei Snort schon seit längerem ein Paket Reassembly Modul, welches fragmentierte Pakete wieder zusammensetzt.
Wir haben schonmal eine defekte NIC in einer DMZ entdeckt, weil die Pakete komplett im Eimer waren (das sah im ACID recht lustig aus, hat aber unser IDS net zum Absturz gebracht).
Im Übrigen:
Ist es korrekt, dass ein IDS mindestens aus zwei Komponenten (z.B. bei Snort: Sensor, Datenbank) besteht, aber Deine zweite Komponente beschreibt bereits ein IRS (Intrusion Respone System), da automatische Gegenmaßnahmen aber rechtlich net unbedenklich sind (-> Verhältnismässigkeit) wird da in der Regel momentan noch von abgesehen, sowas einzusetzten (Achtung: KLUG*******-Modus ).
EDIT: Jetzt wird mer schon zensiert, wenn mer sich selber "Klugausscheider" nennt
P.S.: Ich find's gut, dass wir hier trotz teilweise unterschiedl. Ansichten doch recht sachlich argumentieren, das ist ja net in jedem Thread so.
Von Viren … und Hackern hat Otto Normal-Aldi-Käufer ein paar mal was gehört, aber bei "Firewall" dürften die meisten nicht-Computerzeitschriftenleser aussteigen.
Dem stimme ich zu. Allerdings sollte es doch reichen, wenn die Gefahr (also „Achtung! Es gibt Hacker!“) allgemein bekannt ist und nicht die Lösung. Der Anwender >>muß<< sich dann selber informieren. Wenn Du einem Nachbar erzählst, daß es eine Gefahrenquelle auf seinem Grundstück gibt und ein paar Monate danach verletzt Du Dich dort, dann kann er sich auch nicht darauf berufen, daß Du ihm nicht darauf hingewiesen hast, daß ein Zaun das Problem lösen könnte.
Zudem gibt es ja noch den Grundsatz: Unwissenheit schützt vor Strafe nicht.
Das Problem ist, daß es an eindeutigen Gesetzen dazu fehlt. Aus diesem Grund versuchen wir ja hier krampfhaft, das Debakel mit parallelen auf die alten Gesetze abzubilden (wobei wir gewiss einige Fehler machen). Das es keine entsprechenden Gesetze für das Internet gibt, war ja klar. Dafür sind die Gesetze viel zu alt. Aber ich habe wenigstens auf etwas >>Greifbares<< gehofft, was sich darauf anwenden läßt. Ich selber habe nichts Eindeutiges dazu gefunden. Viele Dinge widersprechen sich da.
Mich beschäftigt dieses Thema ja nicht erst seit heute. Ich habe mich schon mit vielen Menschen darüber unterhalten, viele Artikel im Internet gelesen (allerdings nie etwas eindeutiges gefunden ) Was eine grobe Fahrlässigkeit in Bezug auf diese Thematik genau darstellt, ist nirgends festgelegt (logisch, weil die Gesetze zu alt sind). Mit anderen Worten liegt diese Entscheidung wohl beim Richter. Liegt aber eine grobe Fahrlässigkeit vor, so ist auch eine Privatperson rechtlich angreifbar.
Das alles ist schon ziemlich schwer zu überschauen und hier scheint es leider auch niemanden zu geben, der uns etwas Handfestes dazu sagen kann. Ich möchte aber spätestens morgen Abend die nächste Zusammenfassung schreiben. So werde ich wohl auf die >>mögliche<< Gefahr einer rechtlichen Konsequenz aufmerksam machen.
Zitat:
Zitat von sys3
…(oder auch Vieren, das mag bei so manchem genau in der Schreibweise zutreffen)…
Verdammt, daß passiert mir aber auch immer wieder.
Es macht aber einen riesigen Unterschied aus, ob Du die Pakete nur anzuzeigen oder analysieren willst.
Zitat:
Zitat von Catweazle
Darüberhinaus existiert bei Snort schon seit längerem ein Paket Reassembly Modul, welches fragmentierte Pakete wieder zusammensetzt.
Das soll für ALLE Netzwerkpakete einer JEDEN Verbindung gelten? Dann müsste er ja für jede einzelne Verbindung einen separaten TCP/IP-Stack aufbauen. Wie soll er das machen, in der Kürze der Zeit, die ihm zur Verfügung steht? Ich denke, daß kann er nur, wenn Regeln für >>bestimmte<< Pakete/Ports/Server erstellt wurden. Und diese Anzahl ist durch seine Leistung begrenzt. Die andere Möglichkeit wäre, daß er ähnlich wie eine SIF mit Protokolldaten arbeitet. Aber dann kann von einem wirklichen Reassembly keine Rede sein. Auf die Daten der zusammenhängenden Pakete kann er dann nämlich nicht mehr zugreifen.
Zitat:
Zitat von Catweazle
Die NIC ist im Promiscous Mode
Genau darin steckt auch das Problem eines jeden Sniffers: Er nimmt nicht aktiv an der Verbindung teil. Bei einer festgestellten Attacke, welche er anhand der DB-Regeln "erkannt" hat, muß er sich intern auf eine genaue Analyse der Verbindung einstellen (Pakete bis OSI 7 aufbereiten, zusammensetzen, reinschauen, analysieren) Nur so kommt er an die detaillierten Infos für den Trace. Du könntest jetzt sagen, daß eine ALF das ja auch macht. Aber mit dem Unterschied, daß sie als Proxy aktiv an der Verbindung teilnimmt. Selbst wenn sie im Router-Modus arbeiten würde, welche ebenfalls real zwischen zwei Netzen hängt, könnte sie Pakete verwerfen, neu anfordern, etc. Eben daß, was man so machen kann, um den Datenstrom wenn nötig zu drosseln. Dein IDS Sniffer kann das nicht, da er lediglich am Netz horcht (Monitor Mode), ohne daß die Pakete ihn passieren müssen. Ich bezweifle mal, daß er genügend Reserven hat, um mal nebenher die Attacke zu analysieren und gleichzeitig seinen bisherigen Aufgaben in einem 100 MBit-Netz nachzugehen. Und wenn er die Reserven hat, was passiert dann bei zwei, drei, fünf Attacken? Irgendwann wird er schon aufgeben, was eine IDS-Attacke wieder möglich macht.
Natürlich kann ich mich irren. Es mag sein, daß die Algorithmen derart verbessert wurden, daß sich moderne IDS zusammen mit der neuen Hardware von solchen Attacken auch in 100MBit-Netzen nicht mehr blenden lassen (der Hersteller wird das auf jeden Fall behaupten). Das käme auf einen Test an.
Zitat:
Zitat von Catweazle
…aber Deine zweite Komponente beschreibt bereits ein IRS (Intrusion Respone System), …
Der Satz war nicht für Dich gedacht. Er war für die anderen Leser, damit sie wissen, was ein IDS ist (deshalb der Hinweis: „Für alle anderen Leser: …“). Ein Network-Based-IDS einer Desktop Firewall, um den es im Thread später gehen wird, arbeitet tatsächlich mehr als IPS – also mit integriertem IRS. Aber dazu kommen wir noch.
Wie ich gemerkt habe, hinke ich den neueren Modellen stark hinterher. Ich muß mich dringend mal wieder damit auseinandersetzen. Da scheint sich einiges getan zu haben^^
Hinweis: Die Antwort auf die Frage "Ist eine Firewall auch dann notwendig, wenn Du nichts zu verbergen hast?" wurde in den Thread "Firewall FAQ für Laien" gezogen.
Mir ist klar, dass die Meisten von euch die Antworten auf die folgenden Fragen kennen. Mein Ziel ist es aber, daß die Antworten in einer kurzen Form >>mit möglichst einfachen Worten<< zusammengefasst werden. Das kann für eine Firewallberatung sehr hilfreich sein. Also, wer kann mir dabei helfen?
Was ist eine IP-Adresse? Was ist ein Port? Was ist eine Subnetzmaske? Was ist ein Service oder Dienst? Und wie gelingt es eigentlich einem Wurm, ohne Dein Zutun Dein System zu befallen?
Hallo sys3. Es ist toll, daß Du Dich so rege an dieser Diskussion beteiligst.
Zitat:
Zitat von sys3
Von Viren … und Hackern hat Otto Normal-Aldi-Käufer ein paar mal was gehört, aber bei "Firewall" dürften die meisten nicht-Computerzeitschriftenleser aussteigen.
Dem stimme ich zu. Allerdings sollte es doch reichen, wenn die Gefahr (also „Achtung! Es gibt Hacker!“) allgemein bekannt ist und nicht die Lösung. Der Anwender >>muß<< sich dann selber informieren. Wenn Du einem Nachbar erzählst, daß es eine Gefahrenquelle auf seinem Grundstück gibt und ein paar Monate danach verletzt Du Dich dort, dann kann er sich auch nicht darauf berufen, daß Du ihm nicht darauf hingewiesen hast, daß ein Zaun das Problem lösen könnte.
...
Wenn Du Deinen Nachbarn so direkt auf eine konkrete, speziell von seinem Besitz ausgehende Gefahr, hinweist, dann ja. Wenn Du Deinen Nachbarn aber nur allgemein warnst, ein Dritter könne etwas Gefährliches auf seinem Grundstück hinterlassen, wenn er das Gelände nicht sichert, werden weder Dein Nachbar noch ich anfangen, einen hohen Zaun zu ziehen, einen Hundezwinger aufzustellen oder Kameras zu installieren.
Wenn die IP Adresse Strasse und Hausnummer eines Rechners ist, dann ist der Port die Klingel, die mer drücken muss, um jemanden in dem Haus zu erreichen.
Die Erklärung finde ich recht putzig und sie gibt unbedarften Leuten eine erste Idee des Konzeptes, welches dahintersteht.
Gem. IPV4 eine Nummer aus 4 Octets, über die ein Rechner im Internet eindeutig identifiziert werden kann.
Mit einer Subnetzmaske kann ich grob gesagt die Anzahl der Rechner bestimmen, die von meinem Rechner aus adressiert werden können
Wobei die 4 Octets dann in Netzid und Hostid unterteilt werden
Class C = 1.2.3 Octet = NetzID, 4, Octet HostID (max Anzahl Hosts = 254
0-255 = 256 Adr. insgesamt, die 0 für das Netz, 255 als Broadcast)
Class A = 1. Octet = NetzID, 2.3.4 Octet HostID (max Anz. = 254 * 254 *254)
Ganz grob, darüber kann mer aber ganze Bücher schreiben
PORTS
Grundsätzlich gibt es drei versch. Arten von Ports:
Die Well Known Ports von 0 bis 1023.
Die Registered Ports von 1024 bis 49151 und
Die Dynamic/Private Ports von 49152 bis 65535
Grundsätzl. hat mer sich darauf geeinigt, dass hinter bestimmten Ports bestimmte Services auf eine Kontaktaufnahme lauschen.
Will ich also mit einem bestimmten Rechner smtp (Mail) reden, dann mache ich das mit einem telnet auf die IP und den Port 25, dort begrüsst mich dann (sofern ein entspr. Service aktiv ist) der smtp deamon, über den ich dann gespoofte Mails absenden kann, da das smtp-Protokoll eines der ältesten und anfälligsten ist.
Direkt mit dem Web-Server kommuniziere ich mittels TELNET, IP und auf Port 80.
Die Liste könnte mer jetzt beliebig weiterführen.
Kommen wir jetzt zu Ronalds Frage: Wie kann sich ein Wurm auf meinem Rechner ausbreiten.
Im Internet gibt es jede Menge allg. zugängliche Quellen, in denen aktuelle Sicherheitslücken von Protokollen, Servern oder Client Programmen gesammelt werden.
Wenn ein böser Bube einen solchen sog. "Exploit" ausnutzen will, dann setzt das in der Regel jede Menge Hirnschmalz voraus.
Selbst das Ausnutzen eines sog. Pufferüberlaufes ist nicht trivial, denn mann muss dafür Sorge tragen, dass das, was mer ausgeführt haben will auch entsprechend in dem Speicherbereich auftaucht, der Executable ist, dafür muss mer sich sehr gut in Computerarchitektur und auch in dem Programm, welches mer nutzen will, auskennen.
Ich gebe zu, ich habe mal jemandem dabei über die Schulter sehen dürfen, aber net sonderlich viel verstanden...
Das Problem ist, dass es mittlerweile jede Menge Baukästen gibt, aus denen Scriptkiddies ohne Hirn und Verstand "ihren" Virus zusammenschustern können.
Zum Thema IDS nochmal:
Da hatte ich ja schon geschrieben, dass mer in Hochgeschwindigkeitsnetzen dazu übergeht, mehrere Sensoren zu konzentrieren.
Darüberhinaus git es auch mehrere Loggingmöglichkeiten.
Mer kann z.B. den gesamten Traffic vom Sensor zunächst nur schreiben lassen und danach auf einer anderen Maschine analysieren oder mer lässt den Sensor gleich auch die Analyse mitmachen, was etwas mehr Zeit kostet, wobei es immer auch auf die Policy (conf-file) ankommt, wie schnell der ist.
Im Conf-file kann mer z.B. Pass Rules definieren (Verbindungen, die auf bestimmte Kriterien net untersucht werden sollen).
Dann gibt es die Möglichkeit Plugins (Preprozessoren) gezielt zu aktivieren oder deaktivieren, je nachdem, ob mer sie braucht oder net.
Alles in allem kann mer sagen, dass die Möglichkeiten so vielfältig sind und das eben dass eine gute Implementierung von einer mittelprächtigen unterscheidet, dass jeder Sensor genau weiss, was er zu tun hat (sowas geht in komplexen Netzen net von jetzt auf gleich, aber es lohnt sich, weil mer auch viel lernt!)
Hinweis: Die Antworten auf die Fragen "Was ist eine MAC-/NIC-/Node-Nummer?" und "Was eine IP-Adresse?", sowie "Was ist eine Subnetzmaske?", "Was ist ein Service oder Dienst?" und "Wie gelingt es eigentlich einem Wurm, ohne Dein Zutun Dein System zu befallen?" wurden in die „Firewall FAQ für Laien“ gezogen. Geblieben sind die Zusatzinfos:
Zusammenfassung: Grundsätzliche Regeln für die Subnetzmaske
Innerhalb eines Subnetzes müssen die Subnetzmasken auf allen PCs und Servern, die direkt miteinander kommunizieren wollen, identisch sein. Der Grund ist folgender: Anhand der eigenen IP-Adresse und der Subnetzmaske kann jeder Rechner im Netz ermitteln, wie der Netzwerkname seines Subnetzes lautet. Geht eine Anfrage an eine IP-Adresse, welche zu einem anderen Subnetz gehört, so merkt das der Rechner nun und schickt die Anfrage direkt zu seinem „default Gateway“ (oder besser seinem default Router), welcher die Anforderung weiterreicht. Das ist auch der einzige Grund, warum man die Subnetzmaske nicht nur auf den Netzwerkkomponenten, sondern auch auf jedem Client bekannt geben muss.
Mit anderen Worten definiert die Subnetzmaske auf dem Rechner, welche Adressen direkt ansprechbar sind. Sind die Masken inkonsistent, so gibt es schlicht und ergreifend Kommunikationsprobleme, da die Adressierung in eine der beiden Richtungen nicht mehr funktioniert (der Rechner mit der größeren Subnetzmaske nimmt dann an, dass sein Gegenpart in einem anderen Netzsegment steht und leitet die Anfrage an sein default Gateway weiter).
Hinweis: Auf einem physikalischen Netzwerk können unterschiedliche logische Netzwerke (mit unterschiedlichem Netzwerk-Adressteil) aufgesetzt und gleichzeitig verwendet werden. Dies wird unter anderem eingesetzt, wenn später das Netzwerk wirklich aufgeteilt werden soll oder wenn früher getrennte Netze physikalisch zusammengefasst wurden. In diesem Fall könnten durchaus unterschiedliche Subnetzmasken zum Einsatz kommen. Hierbei handelt es sich jedoch um vollkommen unterschiedliche Subnetze, die sich zur Kommunikation nur zufällig ein und dasselbe Kabel teilen.
Eine Subnetzmaske darf keine Lücken aufweisen. Sie muss also von links nach rechts bündig sein, d.h. wenn das nächste rechte Feld beschrieben wird (also ungleich 0 ist), so muss das davor liegende linke Feld mit 255 gefüllt sein (gültig: 255.128.0.0 und 255.255.255.0, etc. / ungültig: 128.255.0.0 oder 255.0.255.0, etc.). Die letzte Ziffer, welche ungleich 0 ist, darf wiederum nur eine der folgenden Werte einnehmen: 128, 192, 224, 240, 248, 252, 254 oder 255. Ist der Wert ungleich 255, so wird es jedoch etwas schwerer, den Host-Teil der IP-Adresse zu ermitteln.
Wenn mehrere Netzwerke miteinander verbunden werden sollen, so ist dies einfacher, wenn die Subnetzmasken der Netzwerke gleich sind. Das ist aber nicht zwingend erforderlich.
Adressbereiche für private Netzwerke
Um kompatibel mit dem Internet zu sein, sollte man in einem privaten Netz die IP-Adressen 192.168.x.x verwenden (x = Werte zwischen 1 bis 254), da dieser Bereich offiziell für private Netzwerke freigegeben ist. Die für diesen Adressbereich empfohlene Subnetzmaske lautet 255.255.255.0. Zumindest sollte sie aber keinesfalls kleiner als 255.248.0.0 sein.
Der private IP-Bereich soll verdeutlichen, dass in diesem Adressbereich kein Internetserver registriert wurde, welcher mit einem Rechner aus dem privaten Netz einen Adresskonflikt auslösen könnte. Denn ist das private Netzwerk mit dem Internet verbunden und gäbe es dieselbe IP-Adresse eines internen Rechners auch im Internet, so wäre nicht klar, an welchen der beiden Rechner die Netzwerkpakete geschickt werden sollen. Theoretisch würde eine Anfrage eines Rechners aus dem privaten Netz auf diese IP-Adresse einen IP-Adresskonflikt produzieren. Um so etwas zu vermeiden, werden keine IP-Anfragen zum default Gateway geleitet, die auf das eigene Subnetz passen. Das default Gateway würde ohnehin keine Anfragen weiterreichen, bei der die IP-Adresse des Zielrechners in das Netz des Quellrechners passt. Das hat wiederum zur Folge, dass alle Internetserver, deren IP-Adressen in die Subnetzadresse des eigenen Netzes passen, aus diesem Subnetz heraus nicht zu erreichen sind. Deshalb gibt es den Bereich, welcher für private Netzwerke reserviert wurde. Nur wenn man ihn verwendet, kann man einen solchen Konflikt sicher ausschließen.
Hinweis: Alternativ zum oben genannten Adressbereich existieren auch weitere, für den privaten Gebrauch reservierte Adressbereiche: 172.16.x.x bis 172.31.x.x (empfohlene Subnetzmaske: 255.255.0.0; sie sollte auf keinen Fall kleiner sein, wenn der komplette Adressbereiche beansprucht wird) und 10.x.x.x (empfohlene Subnetzmaske: 255.0.0.0; sie sollte auf keinen Fall kleiner als 254.0.0.0 sein).
Einem weit verbreiteten Gerücht zufolge, werden die privaten Adressbereiche nicht geroutet. Das ist allerdings nicht richtig. Innerhalb des privaten Netzes lassen sich damit natürlich Subnetze einrichten, welche die internen Router auch miteinander verbinden können. Allerdings werden sämtliche interne Anfragen an diese IP-Adressen nicht an das Internet weitergereicht. Das erscheint logisch, denn man wird im Internet keinen Server finden, dessen IP-Adresse zu der Adresse aus einem privaten Adressbereichs passt.
Kommen wir gleich zu den nächsten Fragen: Was ist ein OSI-Schichtenmodell? Wozu ist es gut? Und welche Schichten aus dem OSI-Modell sind für Firewalls interessant und warum?
Die Antworten hierauf sind notwendig, damit ich euch die Arten und die Fähigkeiten der Firewalls auf eine verständliche Art näher bringen kann.
[*]Um kompatibel mit dem Internet zu sein, mußt Du in einem privaten Netz eine Subnetmaske von 255.255.255.0 einstellen (Du wirst doch ohnehin nicht mehr als 254 Rechner pro Subnetz anschließen wollen, oder?). Zudem mußt Du die IP-Adressen 192.168.x.x (x = Werte zwischen 0 bis 254) verwenden, da nur dieser Bereich offiziell für private Netze freigegeben ist.
Der von Dir angegebene Bereich privater IP-Adressen ist veraltet (statt 192.168.0.0/8 gilt schon länger 192.168.0.0/16) und da fehlen noch ein paar IP-Bereiche: http://de.wikipedia.org/wiki/Private_IP-Adresse
@All
Bitte lest den Anhang „Grundsätzliche Regeln für die Subnetzmaske“ noch einmal. Wie ich in einem Test gerade herausgefunden habe, hatte ich dort Falschaussagen drin (Betreff Subnetzmask und spezifische Routes).
@sys3
Zitat:
Zitat von sys3
Der von Dir angegebene Bereich privater IP-Adressen ist veraltet (statt 192.168.0.0/8 gilt schon länger 192.168.0.0/16) und da fehlen noch ein paar IP-Bereiche: http://de.wikipedia.org/wiki/Private_IP-Adresse
Das ist ein guter Hinweis. Danke. Ich habe das mit dem „muß“ noch einmal umformuliert.
Du hast natürlich Recht, daß man auch eine andere Subnetmask verwenden kann (192.168.0.0/16). Das sollte auch nur eine Empfehlung sein. Ich habe das entsprechend angepasst.
Die Aussage mit dem 192.168.0.0/8 ist aber schon recht Fatal: Die 8 bedeutet, daß hier nur ein Byte (8 Bit) als Subnetmask definiert wird (also 255.0.0.0). Das geht so lange gut, bis jemand in Deinem Netz auf die Idee kommt, eine IP-Adresse jenseits der 192.168.x.x für einen Rechner zu vergeben. Da die 168 nun zum Host-Bereich gehört, ist da ja durchaus erlaubt. Würde das default Gateway Anfragen an diesen Rechner auch ins Internet leiten, könnte diese IP einen IP-Adressenkonflikt auslösen. Tatsächlich ist es aber so, dass Du aus diesem Netz heraus keine Rechner aus dem Internet ansprechen kannst, die mit 192.x.x.x beginnen, da Anfragen an diese IP-Adressen aus netzwerktechnischer Sicht zu Deinem eigenen Subnetz gehören.
Dein Link ist eine gute Wahl, um weitere freie Adressbereiche für den privaten Gebrauch zu ermitteln. Um Missverständnisse zu vermeiden, sollte man dabei jedoch folgendes beachten: Die dort angegebene Netzmaske bezieht sich auf den frei definierbaren Bereich und hat nichts mit der Subnetzmaske zu tun, die auf den Systemen angegeben werden muß. Ich sage das nur, weil das auf der Page leider relativ missverständlich angegeben wird.
Bye, Ronald
Nachtrag: Die missverständliche Formulierung wurde auf wikipedia am 20. Dezember 2004 geändert. Auch habe ich die fehlenden Adressbereiche für die FAQ daraus übernommen.
Zusammenfassung für folgende Fragen: Was ist ein OSI-Schichtenmodell? Wozu ist es gut? Und welche Schichten aus dem OSI-Modell sind für Firewalls interessant und warum?
Das OSI-Schichtenmodell (OSI="Open Systems Interconnection") unterteilt die Abläufe, in denen eine Kommunikation über ein Netzwerk vonstatten geht, in bestimmte Bereiche. Diese Unterteilung ist notwendig, damit Netzwerkspezialisten eine gemeinsame Sprache sprechen, wenn sie versuchen, bestimmte Vorgänge zu erklären.
In der Praxis sieht das wie folgt aus:
Sender: Das Programm, welches Daten von Deinem PC versenden möchte, schickt die Daten zur OSI-Schicht 7, wo sie nacheinander bis Schicht 1 aufbereitet werden, um sie anschließend über das Netzwerkkabel zum Empfänger zu schicken. Die Aufbereitung ist notwendig, um alle Daten in kleine, transportfähige Netzwerkpakete zu packen.
Empfänger: Er nimmt die Pakete in der OSI-Schicht 1 entgegen und bereitet jedes Paket Schicht für Schicht wieder auf. Erst wenn die Netzwerkpakete in der Schicht 7 des Empfängers angekommen sind, kann die Applikation auf der Empfängerseite die Daten verarbeiten, da sie erst hier wieder ihre ursprüngliche Form angenommen haben.
Nun stellt sich die Frage, an welcher Stelle die Firewalls mit ihrer Paketanalyse und -Filterung eingreifen.
Begriffserklärung:
>ausgehende< Pakete gehen von OSI-Schicht 7 bis OSI-Schicht 1 zum Netzwerkkabel [=>Sender]
>eingehende< Pakete gehen den umgekehrten Weg (Netzwerkkabel -> Schicht 1 bis 7) [=>Empfänger]
.o<------->Applikation, welche ihre Daten mit dem Netzwerk austauscht .| » 7. OSI-Schicht Application Layer (Protokoll der Anwendungsschicht)
will eine Firewall in die Pakete hineinsehen, so operiert die Firewall in dieser Schicht, da >eingehende< Pakete erst durch die darunter liegende Schicht 6 aufbereitet sein müssen, um in die Pakete "hineinsehen" zu können (wird von Stateful Inspection und Application Level Firewalls / dedicated Proxies verwendet)
6. OSI-Schicht Presentation Layer (Protokoll der Darstellungsschicht)
Kodierung, Kompression, Kryptographie der Paketinhalte
diese Schicht ist für Firewalls uninteressant (keine Firewall greift direkt auf diese Schicht zu)
5. OSI-Schicht Session Layer (Protokoll der Kommunikationssteuerung)
hilft Zusammenbrüche der Sitzung u.ä. zu beheben
diese Schicht ist für Firewalls uninteressant (keine Firewall greift direkt auf diese Schicht zu)
» 4. OSI-Schicht Transport Layer (Transportprotokoll)
stellt zuverlässige EndToEnd-Verbindungen zwischen Sender und Empfänger zur Verfügung
ciruit level Proxies (gemeint sind Firewall-Router im Proxy-Modus) greifen auf diese Schicht genauso zu, wie Stateful Inspection Firewalls, da die >eingehenden< Pakete für ihre Arbeit zuvor vom Layer 3 aufbereitet sein müssen
» 3. OSI-Schicht Network Layer (Paketebene)
übernimmt die Paketadressierung und die Auswahl des richtigen Pfades
Paketfilter-Firewalls (Firewall-Router) greifen auf diese Schicht zu (also auch Stateful Inspection Firewalls), da die >eingehenden< Pakete für ihre Arbeit vom Layer 2 aufbereitet sein müssen, um genügend Informationen für eine Paketfilterung zu erlangen
2. OSI-Schicht Link Layer (Sicherungsschicht / Verbindungsebene)
Aufteilung des Bitstromes in Einheiten (Pakete)
diese Schicht ist für Firewalls uninteressant (keine Firewall greift direkt auf diese Schicht zu)
Grundsätzlich gilt: Je höher die Schicht ist, desto mehr Informationen stehen für die Filterung zur Verfügung. Für die Netzwerkpakete bedeutet eine höhere Schicht jedoch wesentlich mehr Zeitaufwand, da die Pakete in jeder darunter liegenden Schicht zuvor aufwendig aufbereitet werden müssen, bis sie die höhere Schicht erreichen. Mit anderen Worten: Firewalls, welche bereits an Hand der wenigen Informationen die in der OSI-Schicht 3 zur Verfügung stehen, entscheiden, ob Pakete durchgelassen werden, oder nicht, sind extrem schnell, aber dafür in ihren Analysemöglichkeiten sehr begrenzt.
So weit zu den theoretischen Fragen. Kommen wir zum Wesentlichen: Welche Arten von Firewalls gibt es? Wie treten sie in Erscheinung? Und was unterscheidet sie voneinander?
Das würde mich auch interessieren, wie Du das meinst.
Auf dem Schichtenmodell basiert doch die Kommunikation.
Selbst, wenn jetzt jemand meint, er "macht nur TCP/IP" benutzt er ja auch zumindest die darunter liegenden Schichten (auch wenn er sich net darum kümmert .
@ Ronald:
melde mich zurück - war eine Woche auf Lehrgang.
Habe mir nochmal bissie zurückliegende Postings durchgelesen.
Ich glaube, dass unser Missverständnis bezüglich der Fähigkeiten eines IDS Pakete zu reassembeln und trotzem alles mitzubekommen daraf beruht, dass wir von unterschiedlichen Anbindungen der Sensoren ausgehen.
Wie es mir scheint gehst Du davon aus, dass ein Spiegelport auf einem Switch verwendet wird (in der Praxis führt das meistens schon zu Paketverlusten auf dem Switch, wenn tatsächlich mehrere Ports auf einen einzelnen gemirrort werden - was bei einigen Herstellern zwar möglich, technisch aber Mummpitz ist, weil der interne Speicher des Switches überläuft - was bei einigen Switchen dann zu netten Fehlern auf den anderen Ports führt).
Ich gehe davon aus, dass eine Leitung per TAP gespiegelt wird und damit kann der Sniffer bzw. die "Snifferphalanx" auch umgehen, bzw. die Pakete reassemblen.
Die Stateful Inspection hast Du net korrekt dargestellt, sofern Du dich auf die Checkpoint beziehst.
Stateful Inspection hat zunächst einmal nichts mit der Application Layer Schicht zu tun.
Stateful bedeutet in diesem Zusammenhang nur, dass eine Verbindung beim Aufbau auf ihre Zulässigkeit überprüft wird (Source Dest Service) und dann in den State Table eingetragen wird. Sofern nachfolgende Pakete zu dieser Verbindung gehören, wird nur im State-Table nachgeschaut, ob die Verbindung eingetragen ist, oder net.
Wenn ein Paket ohne Syn Flag ankommt, welches net in der State Table steht, wird es sofort verworfen.
Was die ALGs angeht, so hast Du wieder recht.
also - das OSI ist ein referenzmodell der ISO - und damit reine Lufthüllen um alles zu erklären - auch den TCP/IP stack, welcher hingegen wirklich verwendet wird.
Beides sind schichtenmodelle, und beide haben eine gewisse gültigkeit.
ich hab mal ausnahmsweise nicht gegoogelt, sondern ge-wiki-piert und bin aufjenen interessaten artikel gestoßen, welcher den zusammenhang recht gut erklärt:
das OSI ist ein referenzmodell der ISO - und damit reine Lufthüllen um alles zu erklären
Genau das habe ich bereits in der besagten Zusammenfassung geschrieben (allerdings habe ich es ein wenig anders formuliert). Ich verstehe Deinen Einwand leider noch immer nicht. *grübel*
@Catweazle
Zitat:
Zitat von Catweazle
Stateful Inspection hat zunächst einmal nichts mit der Application Layer Schicht zu tun.
Die Stateful Inspection Firewall (SIF) arbeitet auch auf dem Application Layer, ist aber, wie Du schon sagst, keine reine ALF. Dennoch sieht die SIF auch in die Pakete hinein (sie inspiziert die Pakete), um zusammenhängende Pakete zu erkennen und somit dynamische Portregeln anlegen zu können. Das realisiert sie natürlich über den Application Layer 7. Ich glaube aber schon, dass wir beide das Gleiche meinen. Ich habe gerade die Zusammenfassung fertig gestellt. Dort sollte es klarer werden (so hoffe ich).
Zitat:
Zitat von Catweazle
Die Stateful Inspection hast Du net korrekt dargestellt….
Da habe ich es doch glatt versäumt, auch auf den Schichten 3 und 4 die SIF einzutragen. Sorry. Danke für den Tipp. Werde das gleich mal korrigieren.
Zitat:
Zitat von Catweazle
… bezüglich der Fähigkeiten eines IDS …
Ich habe gerade mein Wissen darum erneuert. Die haben ja wirklich ein paar gute Ideen dort eingebracht, auch wenn mir noch nicht ganz klar ist, wie die das genau realisiert haben. Ich werde mal versuchen, mehr darüber in Erfahrung zu bringen. Wenn ich etwas Neues dazu herausbekommen habe, werde ich das hier darlegen (wenn nötig mache ich dann einen neuen Thread dazu auf).
Zusammenfassung zu den Fragen: Welche Firewallarten gibt es? Und was unterscheidet sie voneinander?
Die beiden grundlegenden Firewallkonzepte
Paketfilter Firewall
Sie sind sehr schnell und sollen Netzwerkpakete an Hand ihrer IP-Adresse bzw. Ihres Ports sperren oder durchlassen. Sie können im Router- oder Proxy-Modus arbeiten. Für letzteres verwenden sie einen ciruit level Proxy, welcher auf Layer 3 und 4 im OSI-Schichtenmodell operiert.
Eine ALF (auch „Application Level Gateway“ / ALG genannt), arbeitet auf Layer 7 im OSI-Schichtenmodell und ist somit in der Lage, in die Pakete hinein zu sehen (Content Filter). Das ermöglicht den Einsatz so genannter dedicated Proxy (spezialisierte Content Filter), welche zusammenhängende Pakete auf ihren Inhalt hin untersuchen können (z.B. SMTP-Virenscanner, http-Filter, ftp-Verbindungs- und Befehlsfilter, etc.).
Da diese Firewall sämtliche Netzwerkpakete aufwendig bis zum OSI-Layer 7 zusammensetzen muss, sind die Hardwareanforderungen hier ungleich höher, als bei Paketfiltern. Dafür ist sie jedoch in der Lage, verbindungsgebundene Pakete zu erkennen und somit dynamische Portregeln zu erstellen, welche bestimmte Ports automatisch freischalten, wenn die Anforderung aus dem internen Netz heraus kommt (bei einigen Protokollen ginge das nicht, ohne in die Pakete hineinzusehen).
Die Verwendung von dedicated Proxies bietet jedoch den nicht zu unterschätzenden Nachteil, dass sich der Administrator sehr gut mit den zu überprüfenden Diensten auskennen muss, um vernünftige Regeln betreffs der Paketinhalte erstellen zu können. Eine ALF ist also wesentlich schwerer zu Administrieren, als eine Paketfilter-Firewall.
Für die normalen Paketfilter-Regeln, bei denen die Paketinhalte nicht ausgewertet werden müssen, verwendet die ALF ein Modul, welches man generischer Proxy nennt. Dieses Modul ist nichts anderes, als ein simpler Paketfilter inmitten einer ALF.
Hinweis: Die Aufgabe einer Application Level Firewall besteht nicht darin, bestimmten Applikationen den Zugriff zum Netz zu gewähren oder zu verbieten. Dieser Aufgabe kann zumindest eine externe ALF auch nur sehr bedingt gerecht werden. Der Name Application wurde lediglich aus dem Application Layer der OSI-Schicht 7 abgeleitet. Die Funktionalität, Zugriffregeln für Applikationen zu erstellen, gehört in der Regel zu den erweiterten Funktionalitäten einer Desktop Firewall und basiert auch dort auf einer Prozesskontrolle, welche nichts mit dem Firewallmodul zu tun hat.
Mischformen
Screened Gateway
Eine Paketfilter-Firewall ist sehr schnell, eine ALF sehr langsam, dafür aber gründlicher in ihrer Analyse der Pakete. Damit die ALF nicht überlastet wird, ergibt es einen Sinn, erst eine Paketfilert-Firewall aufzustellen, dahinter eine ALF und dahinter wieder eine Paketfilter-Firewall. Der Vorteil: Der Datenstrom passiert in beiden Richtungen zuerst eine der beiden Paketfilter-Firewalls. Nur die Pakete, welche die Paketfilter durchlassen, gehen an die ALF, welche zusätzliche Prüfungen durchführt. Die Paketfilter-Firewalls werden also als Vorfilter genommen, um den Datenstrom für die ALF zu verringern. Solche Systeme nennt man „Screened Gateway“.
Stateful Inspection Firewall
Der Philosophie von Screened Gateways folgend kam die Firma checkpoint (www.checkpoint.de) auf eine verblüffend einfache, wenngleich geniale Idee: Warum sollte man nicht einen Paketfilter und eine ALF in einem einzigen System vereinen? Man analysiert die Pakete also erst auf Layer 3 und ggf. 4 und reicht nur die Pakete an Layer 7 weiter, welche die Paketfilter passieren dürfen. Das wirklich geniale daran war aber, dass checkpoint nicht vorhatte, eine schnellere ALF zu entwickeln, sondern einen Paketfilter zu erschaffen, der in der Lage ist, dynamische Portregeln auch für Protokolle anzulegen, für deren Verbindungsanalyse man in die Pakete hineinsehen muss.
Im OSI-Layer 7 sollte also lediglich eine kurze Inspektion stattfinden, um eine Art Statustabelle aller Netzwerkpakete nutzen zu können. In ihr wird der Status der Verbindung gespeichert und überwacht, wie die Herkunft, das Ziel, die MAC's, die Sequenznummern, belegte Ports, verwendete Protokolle, Offsets und Verbindungsbefehle. Dadurch erkennt diese Firewall Zusammenhänge zwischen TCP- und UDP-Paketen und ist genau wie die ALF in der Lage, dynamische Regeln zu erstellen, welche bestimmte Ports automatisch freischalten, sobald eine entsprechende Anforderung aus dem internen Netz heraus kommt.
Dedicated Proxies werden ihrer Spezifikation nach bei dieser Firewall nicht eingesetzt. Sie bietet dem Administrator also lediglich einen generischen Paketfilter an. Dadurch ist sie schneller als eine herkömmliche ALF und lässt sich zudem wesentlich leichter konfigurieren. Checkpoint nennt diesen Firewalltyp „Stateful Inspection Firewall“, kurz SIF (manchmal auch „Stateful Paket Firewall“ / SPF genannt). Da sie auf aufwendige dedicated Proxies verzichtet und sich so lediglich auf Paketfilter-Regeln konzentriert, wird eine SIF ganz klar als Paketfilter-Firewall klassifiziert.
Als größten Vorteil gegenüber einem konventionellen Paketfilter kann man den Umstand ansehen, dass hier keine eingehenden Trojanerports mehr gesperrt werden müssen. Genau wie bei einer ALF blockiert auch diese Firewall per default alle externen Ports, ausgenommen der Ports, die dynamisch von innen angefordert wurden oder per expliziter Port Forwarding-Regel auf einen Rechner aus der DMZ oder dem internen Netz zeigen. Sie ist somit in der Lage, das PAT-Konzept zu realisieren.
Die meisten Hersteller bieten für ihre SIF allerdings auch dedicated Proxies an. Das ist grundsätzlich möglich, da eine SIF unter anderem auf dem OSI-Layer 7 aufsetzt. Dennoch widerspricht dies völlig dem ursprünglichen Konzept von checkpoint. Werden die dedicated Proxies aktiviert, so ist die SIF tatsächlich keine Paketfilter-Firewall mehr und gehört dann eher in die Rubrik "Application Level Firewall mit einem internen, vorgeschalteten Paketfilter".
Zusammenfassung zu den Fragen: Wie treten die Firewalls in Erscheinung?
Wie treten Desktopfirewalls in Erscheinung?
Eine lokal auf dem Rechner installierte Desktopfirewall überwacht den durch sie hindurch fließenden Datenstrom vor Ort (auf dem Rechner; im folgenden Quellsystem genannt). Aus Sicht des Zielsystems liegt diese Firewall also hinter dem Netzwerkadapter des Quellsystems. Dadurch verändert sich weder die Netzwerkadresse des Quellsystems, noch der Kommunikationsweg zum Zielsystem. Aus Sicht der Kommunikation ist also die Desktopfirewall praktisch unsichtbar.
Wie treten externe Firewalls in Erscheinung?
Router-Modus: Hierbei legt sich die Firewall ebenfalls unsichtbar zwischen beide Netzwerke und ermöglicht so eine direkte Verbindung, sodass sich die Systeme hinter der Firewall ohne Umweg ansprechen lassen. Der Datenstrom fließt also einfach durch die Firewall hindurch (wie bei einer passiven Netzwerkkomponente - z.B. ein Switch oder ein Router). Die Gegenstelle sieht die Firewall nicht. Dennoch kann die Firewall den Datenstrom unterbrechen (bestimmte Pakete herausfiltern). Diese direkte Verbindungsart wird als "Router-Modus" bezeichnet.
Proxy-Modus: Die Firewall stellt sich als Vermittlungsstelle für beide Kommunikationspartner sichtbar zwischen das Quell- und Zielsystem. Dieser Modus wird "Proxy-Modus" genannt und ermöglicht das [[NAT]]- bzw. [[PAT]]-Konzept. Mehr Infos dazu befinden sich in der Beschreibung zum Proxy.
transparent Proxy: Für den Client aus dem internen Netz sieht es so aus, als würde er direkt auf das Zeil zugreifen (z.B. eine Webseite). Der Benutzer muss hier also im Browser keinen Proxy eintragen und gelangt dennoch auf die richtige Seite. Tatsächlich schaltet sich aber unbemerkt der Proxy dazwischen. Gemäß dem NAT- bzw. PAT-Konzept sieht das Zielsystem deshalb nicht den Client, sondern nur die Adresse des Proxys und kommuniziert so mit dem Proxy (also mit der Firewall). Mehr Infos dazu sind in der Beschreibung zum Proxy zu finden.
Wenn man glaubt anhand der Verbindungsmodi genau ermitteln zu können, was ein Firewall-Router oder eine Proxy-Firewall ist, dann erlebt man schnell eine Überraschung:
Leider wird jede Paketfilter-Firewall offiziell auch als '''Firewall-Router''' bezeichnet. Und das vollkommen unabhängig davon, in welchem Verbindungsmodus die Firewall läuft (über Proxy oder direkt). Der „Router“ im Namen lässt aber instinktiv auf eine direkte Verbindung schließen. Eine Schlussfolgerung, die nicht immer stimmen muss.
Das offizielle Synonym für Application Level Firewalls (ALF) ist „Proxy-Firewall“. Doch auch wenn es kaum Anwendungsfälle dafür gibt, in denen sie nicht als Proxy arbeiten, bedeutet dies nicht, dass eine Application Level Firewall im Proxy-Modus laufen muss. Der Name „Proxy-Firewall“ erweckt aber genau diesen Anschein.
Zudem ist ein „Firewall-Router“, welcher im Proxy-Modus läuft, aus technischer Sicht ebenfalls eine „Proxy-Firewall“. Aber nur weil dieser als Proxy fungiert, handelt es sich dabei noch lange nicht um eine Application Level Firewall, sondern um einen Paketfilter. Nicht jede Proxy-Firewall ist also eine Application Level Firewall.
Kommen wir nun zu den nächsten Fragen: Welche grundlegenden Stärken und Schwächen haben externe Firewalls? Welche Stärken haben Desktop-Firewalls gegenüber externen Firewalls? Und welche Schwächen haben Desktop-Firewalls gegenüber dem externen Verwandten?
).
) Was eine grobe Fahrlässigkeit in Bezug auf diese Thematik genau darstellt, ist nirgends festgelegt (logisch, weil die Gesetze zu alt sind). Mit anderen Worten liegt diese Entscheidung wohl beim Richter. Liegt aber eine grobe Fahrlässigkeit vor, so ist auch eine Privatperson rechtlich angreifbar.
Linear-Darstellung
