Wird jetzt klarer, hatte Dein erstes Posting so verstanden, dass Du meinst mer benutzt TCP/IP (Transport Layer) und braucht dazu keine Physikalische Verbindung (Physical Link Layer).
Wie ich aber gelesen habe, scheinen immer mehr Leute dazu überzugehen TCP/IP net als Bestandteil des (theoretischen) ISO/OSI Schichtenmodells sondern als (praktisch orientiertes) Konkurrenzmodell dazu zu sehen (war mir auch neu, aber mer lernt ja nie aus).
Verflucht, jetzt wird mir auch langsam klar, was Du damit meinst. Mein Kopf wird leicht, die Luft entweicht ... Sorry.
Du willst damit sagen, daß das theoretische Gerüst nicht mehr aus Sicht von OSI betrachtet werden sollte. Richtig? Dem kann ich nicht ganz zustimmen. Da OSI unter den Netzspezialisten wesentlich etablierter ist, ist es meiner Meinung nach auch hier die bessere Wahl, um die Kommunikationsabläufe zu erklären.
Auf jeden Fall aber war Dein Hinweis wirklich gut. Sorry, das ich das nicht gleich erkannt habe. Ich überlege mir gerade, ob ich am Schluß des Threads noch einmal auf das neuere TCP/IP-Modell eingehen werde (auch wenn das an dem Sachverhalt nichts ändern wird - hierfür ist es tatsächlich egal, welches Modell verwendet wird). Einen Hinweis ist es aber allemal wert.
ähem neuer? afaik ist das TCP/IP modell älter als das OSI - als am OSI noch gewerkelt und spezifiziert wurde hat man schon IP lösungen benötuigt und da hat die industrie einfach mal mit dem TCP/IP modell angefangen
ähem neuer? afaik ist das TCP/IP modell älter als das OSI - als am OSI noch gewerkelt und spezifiziert wurde hat man schon IP lösungen benötuigt und da hat die industrie einfach mal mit dem TCP/IP modell angefangen
okay - bevor ich noch weiter halbwahrheiten poste hier mal ein paar richtigstellungen
1. Das OSI-Modell existiert seit 1979
2. Der TCP/IP stapel existiert seit dem 1. Januar 1983
3. Der TCP/IP Stapel wurde entwickelt umdas veraltete NCP abzulösen
4. Der TCP/IP Stapel implementiert nicht das OSI-Modell, gleicht diesem aber weitesgehend und setzte sich gegen OSI-Modell-implementierende Protokolle durch
5. der TCP/IP Stapel wurde im ARPNET von Vinton Cerf und Robert Kahn entwickelt
so alles richtig gestellt - sorry für die Verwirrung
OK. Hier eine erste Zusammefassung zum Thema: Also, Desktop-Firewalls laufen weitaus stabiler als externe Firewalls und können von Hackern nicht so leicht überlistet werden. Allerdings sind die Analysefähigkeiten von externen Firewalls besser, da sie sich professioneller mit Paketen ausseinandersetzen und sich zudem besser mit der Materie des Porthackens auskennen.
Bye Ronald
NACHTRAG für alle Neueinsteiger, welche die Beiträge nur „überfliegen“: Dieser Beitrag hier sollte lediglich dazu dienen, die Diskussion um das Thema etwas anzufachen. Die hier enthaltenen Aussagen sind wohlbewusst falsch. Vergesst das also ganz schnell wieder.
OK. Hier eine erste Zusammefassung zum Thema: Also, Desktop-Firewalls laufen weitaus stabiler als externe Firewalls und können von Hackern nicht so leicht überlistet werden. Allerdings sind die Analysefähigkeiten von externen Firewalls besser, da sie sich professioneller mit Paketen ausseinandersetzen und sich zudem besser mit der Materie des Porthackens auskennen.
Ich weiß ja nicht, was Du da eingenommen hast, aber ich will dasselbe haben!
Gib mir 5 .
Bisher hatten Ronald und ich ja in einigen Punkten unsere Differenzen, aber im Großen und Ganzen hatte ich ihm eine gewisse Ahnung doch zugerechnet.
Aber vielleicht hat er sich ja nur vertippt.
EDIT:
Durchgeatmet - Du vergleichst eine Dektop Firewall mit einer externen (z.B.: Checkpoint auf Secure Plattform oder GenuGate auf gehärtetem BSD) und kommst zu dem Schluss, dass eine Desktop FW stabiler läuft???!!!
Ich bitte um Begründung...!!
Dann kommst Du zu dem Ergebnis, dass eine Desktop FW von einem Hacker nicht "so leicht überlistet werden kann" - woran machst Du das bitte an unserer bisherigen Diskussion fest?
Darüberhinaus bitte ich um Begriffserklärung:
Porthacking
Ich kenne Portscanning, der Begriff Porthacking ist mir unbekannt, hacken kann mer einen Dienst hinter einem Port, aber net den Port selber.
Eine Desktop Firewall KANN NIE so sicher und stabil sein, wie eine externe auf einem dafür EXTRA eingerichtetem Gerät. Kurz: HardwareFirewall!
Deine „Hardwarefirewall“ ist aber nicht mal in der Lage, die Verbindung einer „verbotenen“ Applikation zum Netz zu unterbinden. So einfach wie eine externe Firewall läßt sich eine Desktop-Firewall nicht überlisten.
Also: externe Firewall = sicherer als eine Desktop Firewall? Glaube ich nicht. Da fehlen mir noch die wirklichen Argumente.
Stabil? Wie meinst Du das?
Bin, wie Du siehst, von Deiner Argumentation noch nicht überzeugt.
Wenn Du Applikationen hast, denen Du keinen Netzzugriff gestatten möchtest, dann konfigurier die Applikation so, dass sie keinen Netzzugriff durchführt. Wenn sie sich nicht so konfigurieren lässt, deinstallier den Schrott.
Will eine bösartige Applikation wirklich ohne Deine Genehmigung ins Netz, kann sie die Regeln der "Desktop Firewall" mit denselben Rechten ändern, die auch der angemeldete User hat, im schlimmsten Fall kann er gleich die ganze "Desktop Firewall" aus dem Speicher schmeißen lassen. Dann hat sich's was mit dem Blocken von Netzzugriffen - sowohl eingehende als auch ausgehende Verbindungen.
Um so etwas auf einer externen "Firewall" anzurichten, müsste so eine bösartige Applikation schon den letzten Konfigurationszugriff auf die externe "Firewall" erst mal mitloggen, identifizieren und daraus dann die Syntax für eine gültige Konfigurationsänderung basteln - das dürfte nicht ganz einfach sein.
Von einer "Überlistung" einer externen "Firewall" kann auch kaum eine Rede sein, wenn Du erst geschwätzige Software installierst und dann nicht willst, dass die Software geschwätzig ist. Auf so eine Schizophrenie ist eine externe Hardware allerdings nicht ausgelegt, sondern primär auf die Abwehr von unberechtigten Zugriffen von außen, und da gilt der Grundsatz, dass die Firewalling-Software auf jedem beliebigen Gerät laufen darf, nur nicht auf den Rechnern, die geschützt werden sollen.
Wenn Du Applikationen hast, denen Du keinen Netzzugriff gestatten möchtest, dann konfigurier die Applikation so, dass sie keinen Netzzugriff durchführt. Wenn sie sich nicht so konfigurieren lässt, deinstallier den Schrott.
Will eine bösartige Applikation wirklich ohne Deine Genehmigung ins Netz, kann sie die Regeln der "Desktop Firewall" mit denselben Rechten ändern, die auch der angemeldete User hat, im schlimmsten Fall kann er gleich die ganze "Desktop Firewall" aus dem Speicher schmeißen lassen. Dann hat sich's was mit dem Blocken von Netzzugriffen - sowohl eingehende als auch ausgehende Verbindungen.
Um so etwas auf einer externen "Firewall" anzurichten, müsste so eine bösartige Applikation schon den letzten Konfigurationszugriff auf die externe "Firewall" erst mal mitloggen, identifizieren und daraus dann die Syntax für eine gültige Konfigurationsänderung basteln - das dürfte nicht ganz einfach sein.
Von einer "Überlistung" einer externen "Firewall" kann auch kaum eine Rede sein, wenn Du erst geschwätzige Software installierst und dann nicht willst, dass die Software geschwätzig ist. Auf so eine Schizophrenie ist eine externe Hardware allerdings nicht ausgelegt, sondern primär auf die Abwehr von unberechtigten Zugriffen von außen, und da gilt der Grundsatz, dass die Firewalling-Software auf jedem beliebigen Gerät laufen darf, nur nicht auf den Rechnern, die geschützt werden sollen.
Danke Dir!
Ich hätte es nicht anders geschrieben!
@Ronald
Ich weiss ja nicht wo du dein Wissen her hast.
Ich arbeite in ner professionellen IT-Abteilung in einem mittelständischen Unternehmen mit 400 Mitarbeitern.
Das ist n bisschen was anders als ZoneAlarm auf dem Rechner.
Fakt ist, das in ERSTER Linie der Schutz den Netzes von AUSSEN gewährleistet werden muss!
Zusätzlich kann an der Firewall so viel in Sachen Ports und Paketfilter gemacht werden, dass das Netz auch von innen nach aussen recht sicher ist.
Bitte lass die Kirche beim Dorf und siehs mal aus nem praktischen Punkt heraus.
Nicht aus dem des paranoider Users, der sich über sein geschwätziges Windows aufregt!
Wie sys3 schon gesagt hat. Wenn deine SW-Firewall weg ist, dann ist dein rechner nackt! Und dann ist er gefährdet.
Es gibt fertige Scripts mit denen man SW-Firewalls per Mausklick abschiessen kann.
Will eine bösartige Applikation wirklich ohne Deine Genehmigung ins Netz, kann sie die Regeln der "Desktop Firewall" mit denselben Rechten ändern, die auch der angemeldete User hat, im schlimmsten Fall kann er gleich die ganze "Desktop Firewall" aus dem Speicher schmeißen lassen. Dann hat sich's was mit dem Blocken von Netzzugriffen - sowohl eingehende als auch ausgehende Verbindungen.
Das ist ein wirklich gutes Argument. Langsam kommen wir der Sache näher.
Zitat:
Zitat von sys3
Um so etwas auf einer externen "Firewall" anzurichten, müsste so eine bösartige Applikation schon den letzten Konfigurationszugriff auf die externe "Firewall" erst mal mitloggen, identifizieren und daraus dann die Syntax für eine gültige Konfigurationsänderung basteln - das dürfte nicht ganz einfach sein.
OK, es gibt noch eine Reihe anderer Angriffspunkte für externe Firewalls (vor allem bei der Verendung von dedicated Proxies), welche allerdings allesamt erst recht auch auf Desktop-Firewalls zutreffen.
Zitat:
Zitat von sys3
Von einer "Überlistung" einer externen "Firewall" kann auch kaum eine Rede sein, wenn Du erst geschwätzige Software installierst und dann nicht willst, dass die Software geschwätzig ist. Auf so eine Schizophrenie ist eine externe Hardware allerdings nicht ausgelegt, sondern primär auf die Abwehr von unberechtigten Zugriffen von außen, und da gilt der Grundsatz, dass die Firewalling-Software auf jedem beliebigen Gerät laufen darf, nur nicht auf den Rechnern, die geschützt werden sollen.
DAS ist das Argument für eine externe Firewall schlechthin.
Zitat:
Zitat von sys3
Wenn Du Applikationen hast, denen Du keinen Netzzugriff gestatten möchtest, dann konfigurier die Applikation so, dass sie keinen Netzzugriff durchführt. Wenn sie sich nicht so konfigurieren lässt, deinstallier den Schrott.
Und das ist ein gewichtiges Argument für den Einsatz einer Desktop-Firewall (mit all ihren erweiterten Featrues): Wie willst Du denn anhand des bloßen Einsatzes einer externen Firewall überhaupt herausfinden, dass eine Applikation unerlaubt mit dem Netzwerk kommuniziert? Selbst wenn Dir die Applikation vorgaukelt, Du könntest jeglichen Netzwerkverkehr per Einstellung unterbinden – glaubst Du daran, dass sie sich auch wirklich daran hält? Und eine heimlich installierte Malware (also Spyware, Hackertools, etc.) wird sich kaum freiwillig bei Dir melden, wenn sie mit dem Netz kommunizieren will. Dagegen ist eine externe Firewall machtlos (was nicht bedeutet, daß demgegenüber eine Desktopfirewall >>immer<< in der Lage ist, solche Zugriffe zu unterbinden – aber dazu kommen wir noch).
Summa summarum Deinen Beitrag schon blau markiert unter der Überschrift „Zusammenfassung“ gelegt werden (es fehlen lediglich noch ein paar Kleinigkeiten).
@All
Zitat:
Zitat von Ronald
OK. Hier eine erste Zusammefassung zum Thema: Also, Desktop-Firewalls laufen weitaus stabiler als externe Firewalls und können von Hackern nicht so leicht überlistet werden. Allerdings sind die Analysefähigkeiten von externen Firewalls besser, da sie sich professioneller mit Paketen ausseinandersetzen und sich zudem besser mit der Materie des Porthackens auskennen. Bye Ronald
So langsam sollte jedem klar sein, dass der Beitrag nur dazu dienen sollte, die Diskussion um das Thema etwas anzufachen (hätte eigentlich auffälliger sein sollten – zum einen der Titel „eine >>erste<< Zusammenfassung“ und zum Anderen war der Text ja nicht einmal blau ). Bis zu diesem Zeitpunkt hatte sich nämlich noch niemand zu den aktuellen Fragen geäußert. Jeder schien sich auf meine nächste Zusammenfassung zu verlassen, ohne selbst etwas dazu beitragen zu wollen. So ist der Thread aber nicht gedacht.
Ich werde noch bis Dienstag warten und so auf den einen oder anderen Beitrag hoffen, ehe ich die nächste Zusammenfassung schreibe.
Viele Spyware Programme und andere "böse" Programme arbeiten auf verschiedenen Ports.
Diese können ja recht einfach an der Firwall geblockt werden.
Also von innen nach aussen!
Damit kann man viel blocken!
Ebenfalls ist es ratsam über einen Proxy den Internetverkehr abzuwickeln.
Damit brauchen Applikationen die aufs Web zugreifen wollen eine Anmeldung. Ohne diese ist keine Internetverbinung möglich.
z.B. muss man für ICQ einen Proxy angeben wenn man icq im Firmennetzwerk nutzen möchte.
Wenn Du Applikationen hast, denen Du keinen Netzzugriff gestatten möchtest, dann konfigurier die Applikation so, dass sie keinen Netzzugriff durchführt. Wenn sie sich nicht so konfigurieren lässt, deinstallier den Schrott.
Und das ist ein gewichtiges Argument für den Einsatz einer Desktop-Firewall (mit all ihren erweiterten Featrues): Wie willst Du denn anhand des bloßen Einsatzes einer externen Firewall überhaupt herausfinden, dass eine Applikation unerlaubt mit dem Netzwerk kommuniziert? Selbst wenn Dir die Applikation vorgaukelt, Du könntest jeglichen Netzwerkverkehr per Einstellung unterbinden – glaubst Du daran, dass sie sich auch wirklich daran hält? Und eine heimlich installierte Malware (also Spyware, Hackertools, etc.) wird sich kaum freiwillig bei Dir melden, wenn sie mit dem Netz kommunizieren will. Dagegen ist eine externe Firewall machtlos.
Mein Text war da schon etwas schroff, ich wollte nicht gegen den Einsatz einer "Desktop-Firewall" plädieren, nur die Schwächen einer solchen aufzeigen und die Behauptung, sie sei per se "besser", demontieren. Diese Absicht ist sicher nicht gut rüber gekommen, aber um Viertel nach 12 nachts nach einem langen Arbeitstag bin ich halt nicht mehr so frisch (*um Verständnis heischend* ).
Ehrlich gesagt würde ich mich bei verdächtiger Software eher auf die Presseberichte und einen Netzwerksniffer verlassen als auf eine "Desktop Firewall". Das Konzept, erst irgendeine Software ohne vertrauenswürdigen Ruf zu installieren und dann auf dem letzten Meter per Netzwerkfilter zu stoppen, ist mir eher suspekt. Auch bei Malware bin ich eher der Meinung, die Anstrengung in die Verhinderung von deren Start/Installation zu stecken anstatt nachher deren E.T.-Funktion zu blockieren. Also zusammenfassend bin ich mehr für Vorbeugung als für Nachsorge.
Eine "Personal Firewall" ist nicht besser als eine externe "Firewall", sondern vor allem anders. In den Punkten, in denen sich ihre Funktionen mit der einer externen "Firewall" decken, ist die externe "Firewall" zuverlässiger. Den Netzzugriff mancher lediglich vorwitziger Software zu blockieren, ist dagegen die Domäne der "Personal Firewall". Wie gut sie tatsächlich bösartige Software blockieren kann, hängt stark von einigen Faktoren ab (Wie gut haben hat der Hersteller die "Personal Firewall" vor unberechtigtem Beenden geschützt? Hat der angemeldete User Admin/root-Rechte? Lohnt es sich für den Malware-Programmierer, eine "Personal Firewall" abzuschießen - lies: Wie hoch ist der Prozentsatz derer, die überhaupt eine "Personal Firewall" benutzen).
Als zusätzliche (aber nicht als einzige) Schutzmaßnahme ist eine "Personal Firewall" sicher sinnvoll, ganz besonders, wenn man ein undurchsichtiges und netzwerktechnisch kaum konfigurierbares System wie Microsoft Windows benutzt. In jedem Fall ist eine "Personal Firewall" besser als gar keine Vorkehrungen.
Viele Spyware Programme und andere "böse" Programme arbeiten auf verschiedenen Ports. Diese können ja recht einfach an der Firwall geblockt werden. Also von innen nach aussen! Damit kann man viel blocken!
Viel? Ich würde eher sagen: einiges. Das Problem: Die Entwickler von Malware, welche eigene Ports in Anspruch nehmen wollen, kennen die Schwächen von portbasierter Filterung ganz genau. Versuche doch einmal den Port 80 von innen nach außen zu sperren, ohne den Internetzugang zu unterbinden. Genau dieser wird von vielen Malwareapps verwendet. Auf Port-Ebene kann hier eine externe Firewall also nur sehr bedingt helfen.
Unterm Strich würde ich sagen ist Deine Aussage durchaus richtig, aber sie birgt auch eine gewisse Gefahrenquelle: Sie gaukelt dem Anwender eine Sicherheit vor, die es lediglich Ansatzweise gibt.
Zitat:
Zitat von io.sys
Ebenfalls ist es ratsam über einen Proxy den Internetverkehr abzuwickeln. Damit brauchen Applikationen die aufs Web zugreifen wollen eine Anmeldung. Ohne diese ist keine Internetverbinung möglich.
Ich weiß schon was Du meinst, aber für alle anderen Leser: Nur weil eine Firewall im Proxy-Modus läuft, bedeutet das noch lange nicht, dass man sich erst auf dem Proxy authentifizieren muß, ehe man sich mit dem Internet in Verbindung setzen kann. Die meisten Home-DSL-Firewalls bieten eine solche Authentifizierung auch gar nicht erst an, was zur Folge hat, dass in der Regel alle Home-Netzwerkte und die meisten kleineren Unternehmen diesen Mechanismus nicht nutzen.
Grundsätzlich gibt es zwei populäre Möglichkeiten dieser Authentifizierung:
Rechner freischalten: Das geschieht in der Regel über einen Internet Browser hinweg durch einmalige Angabe von einer Internetzugangskennung + Passwort (HTML-Dialog). Danach erst können alle Applikationen von diesem Rechner aus mit dem Internet kommunizieren. Für viele Malwareprogramme stellt das kein Hindernis dar. Sie bringen einfach keine Fehlermeldung hervor, wenn die gewünschte Netzwerkverbindung nicht funzt und versuchen es später noch einmal. Wenn sie intelligent genug programmiert wurden, dann warten sie auch erst auf bestimmte Netzwerkaktivitäten, ehe sie selber den Schritt zur Kommunikation wagen. Hier hilft die Proxy-Authentifizierung also nur sehr bedingt. Zudem kommt folgendes Problem: Um einen PC für die Kommunikation freizuschalten oder zu sperren reicht ein dynamischer Paketfilter (IP-Filter) zwar vollkommen aus. Dennoch können ciruit level Proxies (also generische Proxies, welche auf OSI 4 aufsetzen) dieser Aufgabe nicht nachkommen. Für die Authentifizierung bedarf es ja schließlich einer ausgewachsenen HTML-Kommunikation zwischen dem Rechner und dem Proxy, welche auf höheren Schichten angesiedelt ist. Von daher gibt es diese Funktionalität nicht auf Paketfirewalls und reinen SIFs. Lediglich ALFs mit >>generischen<< Proxy oder „vergewaltigte“ SIFs können diese Funktionalität bieten.
Internetfreischaltung für einzelne Prozesse: Diese Variante ist im Kampf gegen Malware schon wesentlich effizienter: Bei jedem Start einer Applikation wird – bildlich gesehen - ein Mix aus Prozess-ID und Rechnername für die Authentifizierung des Internetzugriffs verwendet. Nach der Kennungs- und Passworteingabe sind alle Fenster des freigeschalteten Prozesses dann in der Lage, mit dem Internet zu kommunizieren. Wird ein weiterer Prozess gestartet, welcher ebenfalls mit dem Internet kommunizieren will, so muß der Anwender erneut Kennung und Passwort eingeben, um die Kommunikation explizit auch für den neuen Prozess zu erlauben. Auch hier gibt es mehrere Möglichkeiten, den Mechanismus zu unterwandern. Einige davon werden wir noch behandeln, da sie auch dazu dienen, eine Desktop-Firewall zu umgehen. In der Praxis ist der Prozess-Zugriffsschutz aber durchaus wirkungsvoll, da sich dadurch die Kommunikation zahlreicher Malware, welche sich über das http-Protokoll mit den Internet verbinden will, tatsächlich blockieren läßt. Allerdings funktioniert diese Authentifizierung nur im http-Proxy.
Mit anderen Worten ist diese Art der Authentifizierung stark vom Dienst abhängig. Zudem wird diese Authentifizierung in kleineren Netzen nur selten eingesetzt, da solche Proxies nicht ganz billig sind und diese auch hier nur in einer ALF zur Anwendung kommen.
Hinweis für alle, die sich fragen, wie die Firewall an die Prozess-ID der Session gelangt: Sie arbeitet nicht wirklich mit der Prozess-ID. Vielmehr versucht eine Applikation (ein Prozess) eine Verbindung zur Firewall aufzubauen und übergibt ihr dabei einen – aus Authentifizierungssicht – „leeren“ Header. Die Firewall erkennt daraufhin, daß es sich um einen neuen Prozess handelt. Nun wird eine Standardkommunikation für die Authentifizierung ausgelöst, um den Prozess bei der Firewall freiszuschalten. Die Firewall eröffnet daraufhin eine neue Session und schickt nach erfolgter Authentifizierung die interne Session-ID über den Header an die Applikation zurück. Die Applikation meldet sich von nun an bei jeder Anforderung mit den gefüllten Header-Informationen bei der Firewall. Die Firewall erkennt daraufhin die authentifizierte Anfrage und bearbeitet den Vorgang ohne neue Authentifizierung …
@sys3
Zitat:
Zitat von sys3
Eine "Personal Firewall" ist nicht besser als eine externe "Firewall", sondern vor allem anders. In den Punkten, in denen sich ihre Funktionen >>mit der einer externen "Firewall" decken<<, ist die externe "Firewall" zuverlässiger.
Absolut richtig. Allerdings wird aus finanziellen Gründen wohl keiner auf die Idee kommen, vor jedem PC eine externe Firewall aufzustellen. Hier hat die Desktopfirewall also strategisch gesehen durchaus ihre Vorteile. Zudem sind es die erweiterten Features einer Desktopfirewall, die das Sicherheitskonzept erst abrunden. Gerade für den Otto-Normalverbraucher ist das ein wichtiges Werkzeug, welches nicht wichtiger, aber eben auch nicht unwichtiger ist, als eine externe Firewall.
Zitat:
Zitat von sys3
Also zusammenfassend bin ich mehr für Vorbeugung als für Nachsorge.
Dieser Herangehensweise ist theoretisch die Beste. Praktisch fehlt es den Anwendern oftmals am notwendigen Wissen um diese Materie und nicht zuletzt an der notwendigen Disziplin. Unter diesen Umständen kann >>im günstigsten Fall<< einem die Desktopfirewall mit ihren erweiterten Features helfen, das schlimmste zu verhindern: Je nach Softwareumfang schlägt sie Alarm, wenn eine Applikation unerlaubt auf das Netzwerk zugreifen möchte oder wenn Autostarteinträge verändert werden, etc. Zu vermitteln, wo deren Grenzen liegen und wie man mit dem Werkzeug „Firewall“ (intern und extern) richtig umgeht, finde ich deshalb wenigstens genauso wichtig, wie das Thema Vorbeugung, da dies schlicht praxisnäher ist.
1.) Sollte eine sichere Firewall die PAP Struktur aufweisen, d.h. externer Paketfilter, Application Level Gateway, interner Paketfilter.
Damit wäre das Argument "Verwundbarkeit einer Proxy-Firewall" zumindest aus meiner Sicht aus der Welt.
2.) Haben wir uns ja schon vorher über die Notwendigkeit interner Schutzmassnahmen als Ergänzung einer Firewall unterhalten.
Imho sollte ein IDS/IRS ausreichend sein.
Im Gegensatz zu der PF-Lösung allerdings wesentlich leichter zu administrieren und aus Sicht der Persormance für die Nutzer transparent sein.
Ich habe zwar schon Netze mit internen Firewalls gesehen, aber die haben lediglich Netzsegmente mit höheren Sicherheitsanforderungen gegenüber anderen Segmenten abgeschottet.
Wenn mer die Paranoia auf die Spitze treiben will, sollte mer auch noch anführen, dass net nur die Strahlung des Monitors angemessen und ausgewertet werden kann (zu dem Thema kompromittierend Abstrahlung von Rechnern mal nach "Tempest" PC googlen)...
...nach dem Motto "ich habe einen TFT, der strahlt ja net"...
Edit:
Ach ja, auf einer Proxyfirewall funktioniert kein Port, für den kein Proxy konfiguriert ist und die Dynamischen Ports von Protokollen wie ftp setzen eine entsprechende Verbindungsaufnahme voraus.
1.) Sollte eine sichere Firewall die PAP Struktur aufweisen, d.h. externer Paketfilter, Application Level Gateway, interner Paketfilter. Damit wäre das Argument "Verwundbarkeit einer Proxy-Firewall" zumindest aus meiner Sicht aus der Welt.
Du kannst doch nicht ernsthaft sagen, daß eine ALF innerhalb eines Screened Gateways alleine schon durch die vorgeschalteten Paketfilter ausreichend geschützt ist. Welche Art von Angriffen auf eine ALF läßt sich denn damit blocken?
Zitat:
Zitat von Catweazle
Ach ja, auf einer Proxyfirewall funktioniert kein Port, für den kein Proxy konfiguriert ist
Beziehst Du das auf JEDE Firewall im Proxy-Modus oder nur auf ALFs? Kannst Du das bitte Konkretisieren?
Zitat:
Zitat von Catweazle
die Dynamischen Ports von Protokollen wie ftp setzen eine entsprechende Verbindungsaufnahme voraus.
Ich verstehe den Zusammenhang jetzt nicht. Was genau meinst Du damit?
Zitat:
Zitat von Catweazle
2.) Haben wir uns ja schon vorher über die Notwendigkeit interner Schutzmassnahmen als Ergänzung einer Firewall unterhalten. Imho sollte ein IDS/IRS ausreichend sein. Im Gegensatz zu der PF-Lösung allerdings wesentlich leichter zu administrieren und aus Sicht der Persormance für die Nutzer transparent sein.
Guter Einwand. Wie schon erwähnt geht es hier jedoch nicht nur um die supergroßen Netzwerke, welche in der Regel von Profis gewartet werden. Es geht auch (oder besser vor allem) um Home-Netzwerke und um Netze von kleinen Unternehmen. Ich glaube nicht, daß ein (network-based) IDS/IRS für diese Leute wirklich besser zu administrieren ist. Zudem bietet das IRS in Händen von "nicht Profis" einem Angreifer erweiterte Möglichkeiten für DoS-Attacken.
Aus meiner Sicht ist in Home-Netzwerken eher die Verwendung beider Firewallarten zu empfehlen. Das es in größeren Netzwerken Lösungen gibt, welche dieselben Probleme auf eine andere Art verwaltungstechnisch handhabbarer angehen, steht auf einem anderen Blatt.
Das IDS scheint ein Steckenpferd von Dir zu sein. Ich habe allerdings ein wenig das Gefühl, daß Du dem IDS/IRS einfach zuviel zutraust (zumindest der Netzwork-based-Verison). Wie bereits vorgeschlagen sollten wir >>nachdem der Thread hier zu ende geführt wurde<< einen neuen Thread zum Thema IDS aufmachen.
Zitat:
Zitat von Catweazle
zu dem Thema kompromittierend Abstrahlung von Rechnern mal nach "Tempest" PC googlen ... nach dem Motto "ich habe einen TFT, der strahlt ja net"...
Tempest-Attacken … Meinst Du mit Deinem Hinweis, daß nun auch von Flachbildschirmen eine aus der Entfernung messbare und in ein Videosignal umwandelbare Strahlung ausgeht? Bei CRT ist das klar, aber bei TFT wäre mir das neu. Auch per google konnte ich keinen verwendbaren Beitrag dazu finden.
Um so etwas auf einer externen "Firewall" anzurichten, müsste so eine bösartige Applikation schon den letzten Konfigurationszugriff auf die externe "Firewall" erst mal mitloggen, identifizieren und daraus dann die Syntax für eine gültige Konfigurationsänderung basteln - das dürfte nicht ganz einfach sein.
OK, es gibt noch eine Reihe anderer Angriffspunkte für externe Firewalls (vor allem bei der Verendung von dedicated Proxies), welche allerdings allesamt erst recht auch auf Desktop-Firewalls zutreffen. Aus diesem Grund ist Deine Aussage absolut richtig.
Also mein Statement mit der PAP Firewall war darauf bezogen, weil in dieser Konstellation der externe Paketfilter das ALG vor bestimmten Angriffen "schützt", denen eine reine Personal Firewall schutzlos ausgeliefert ist.
2.) Meinte Proxyfirewall im engeren Sinne (Proxybasiertes ALG), auf dem für jeden Dienst ein Proxy eingerichtet werden muss.
Da ist wieder das Problem mit der Begriffsbestimmung.
Das aktive FTP hatte ich nur als Beispiel angegeben, weil in dem Fall, dass ein Proxy aktives FTP erlaubt weitere Ports im Rahmen einer über Port 21 etablierten Verbindung zugelassen sind (falls des net klar rüberkam - sorry).
3.) Hm, manchmal geht es um grosse Netze, manchmal net .
4.) Jepp - IDS ist ein Steckenpferd von mir, schon allein was snort in Verbindung mit einer mysql-Datenbank und ACID leistet (alles Freeware) ist imho beeindruckend, wenn mer das mit z.B. dem Network Flight Recorder von vor fünf Jahren vergleicht.
5.) Es geht net um die Abstrahlung des Monitors, auch der Rechner strahlt und mit dem entsprechenden Equipement lässt sich das in Informationen umwandeln.
Sorry, daß ich erst heute darauf antworten kann (es fehlte mir einfach an Zeit).
Zitat:
Zitat von Catweazle
… weil in dieser Konstellation der externe Paketfilter das ALG vor bestimmten Angriffen "schützt", denen eine reine Personal Firewall schutzlos ausgeliefert ist.
Eine ALF innerhalb eines Screened Gateways ist ganz sicher gegen >>bestimmte<< Angriffsformen von nicht autorisierten Quellen geschützt, welche sich durch die vorgeschalteten Paketfilter blockieren lassen. Einigen wir uns darauf, das dies NICHT bedeutet, daß die ALF durch die Paketfilter >>maßgeblich<< vor Angriffen geschützt ist, OK?
Zitat:
Zitat von Catweazle
Meinte Proxyfirewall im engeren Sinne (Proxybasiertes ALG), auf dem für jeden Dienst ein Proxy eingerichtet werden muss.
Aus der Sicht eines Admins hast Du Recht. Allerdings ist der generische Proxy aus technischer Sicht vergleichbar mit dem Konfigurationsmodul einer Paketfilter-Firewall und somit weit von einem dedicated Proxy entfernt. Im Detail:
Nur wenn hier eine dienstbasierte Regel festgelegt werden soll (also eine Regel, welche weit über die Port- und Adressfreischaltung hinausgeht – sich also auf Paketinhalte bezieht), muß dafür ein dedicated Proxy eingerichtet werden. Jeder einzelne dedicated Proxy läuft als eigenständiger Thread (oder gar Prozess) in der Firewall, welcher mit einem eigenen Filtertreiber-Modul zusammenarbeitet.
Anders sieht es bei der einfachen Portfreischaltung aus: Hier gibt es einen einzigen zentralen Thread (bzw. Prozess), der diese Zugriffe steuert. Das bedeutet, je mehr dedicated Proxies eingerichtet werden, desto mehr Filtertreiber-Module und Proxy-Threads (resp. Prozesse) muß die Firewall bedienen. Bei einer simplen Portfreischaltung ist das nicht der Fall (egal für wie viele Dienste er benötigt wird).
Das hat zur Konsequenz, daß in einem professionellen Umfeld eines größeren Netzwerks eine extra Firewall pro dedicated Proxy eingesetzt wird. Das wird erreicht, indem man den vorgeschalteten Paketfilter (aus dem Screened Gateway) gleichzeitig als Load Balancing Router einsetzt (eingehende Pakete für Dienst1 (PortX) werden von hier aus an Firewall1 geschickt, Dienst2 (PortY) an Firewall2, etc.). Diesen Aufwand muß man für Regeln auf generische Proxies einer ALF (reine Port- und Adressfreischaltung) nicht betreiben (jedenfalls nicht stärker, als man es bei einer Paketfirewall auch tun müsste).
Summa summarum ist es von der verwendeten ALF abhängig, ob man per Default für jeden Kommunikationsport erst einmal von Hand eine Regel erstellen muß, oder ob einige Standard-Ports bereits vorkonfiguriert wurden (über den generischen Proxy). Das ist nicht anders, als bei einer SIF oder einem Paketfilter auch.
Zitat:
Zitat von Catweazle
auch der Rechner strahlt und mit dem entsprechenden Equipement lässt sich das in Informationen umwandeln
Habe mich in Sachen „tempest“ noch einmal eingelesen. Vieles war mir neu. Danke für den Tipp.
Und hier kommen auch schon die nächsten Fragen an euch: Was ist NAT (Network-Address-Translation), bzw. PAT (Port and Address Translation) und worin unterschieden sich beide? Was ist eine DMZ (Demilitarisierte Zone)? Und was ein VPN (Virtuelles Privates Netzwerk)? Wie funktioniert das?
Damit sollten die wichtigsten Kürzel, welche immer mal wieder im Zusammenhang mit Firewalls fallen, geklärt sein.
melde mich aus dem Urlaub zurück - weia ist das früh und dunkel.
Muss jetzt erstmal etwas "Nachlese" betreiben, obwohl ja netterweise net zuviel dazu gekommen ist (zumindest bei diesem Thread).
Dafür hat sich ja das Forenlayout komplett geändert -> schon wieder, naja wenigstens sind wir alle auf dem aufsteigenden Ast.
Den Satz bezüglich der PF "net besser oder schlechter, sondern anders" kann ich in der Form auf jeden Fall unterschreiben, wenn wir daraus jetzt noch ableiten, dass es eben für jede Art von Firewall ihren speziellen Einsatzzweck gibt.
Beim Natting muss mer zwischen statischem und Dynamischen Natting unterscheiden:
Statisches Natting wandelt private IPs in öffentliche (public) IPs um.
Dynamisches Natting wandelt private IPs in eine öffentliche IP um, daher wird es auch "Hide Natting" genannt, weil es die Struktur des dahinterliegenden Netzes nach aussen versteckt.
Ein zweiter Punkt ist, dass sich damit beliebig viele interne Maschinen an das Internet anschliessen lassen und nur eine der raren und teuren public IPs benötigt wird.
Zu PAT könnte ich mir zwar etwas denken, aber damit kenne ich mich nicht aus.
Zu einer DMZ hatten wir uns ja bereits unterhalten ("drittes Bein der Firewall, an dem Maschinen hängen, die aus mehreren Netzen, die die Firewall trennt, zugänglich sein müssen").
Zu dem Thema VPN gibt es so viel zu sagen, wo soll ich da anfangen.
Grundsätzlich ist ein VPN ein in sich geschlossenes Netzwerk unter Nutzung eines unsicheren Trägernetzwerkes (z.B. Internet).
Erreicht wird dies in der Regel durch eine Kombination von Verschlüsselung und Tunnelung.
).
(Dein Humor ist ganz nach meinem Geschmack)
). Bis zu diesem Zeitpunkt hatte sich nämlich noch niemand zu den aktuellen Fragen geäußert. Jeder schien sich auf meine nächste Zusammenfassung zu verlassen, ohne selbst etwas dazu beitragen zu wollen. So ist der Thread aber nicht gedacht.
Linear-Darstellung
