[PanteraBM]

So, ich hab mich jetzt hier mal durchgelesen, Thema Firewall haben ja nun die meisten eine Antipathie gegen entwickelt. Dazu hab ich mir mal folgende Seite angesehen, die gerne als contra gegen Firewall gepostet wird:
http://home.arcor.de...ustricksen.html

Zu 1.: ja, das kanns geben, ist aber nicht das Prolbme der Fierwall, sondern vom Browser. Irgendwie ja auch logisch, dass Plugin`s Wirtsprogramme brauchen...

Zu 2.: Wo ist das Problem, dass Real Player über http Bilder vom Internet runterlädt?

Zu 3.: Meine Firewall bringt auch direkt die .exe als Namen, aber jeder DAU weiss nicht, was das für ein Programm ist, daher ist der Programmname als Anzeige für viele besser. Könnte man aber wie gesagt auch sicher Einstellen(mit dem nötigen Wissen).

Zu 4.: Also das mit der DNS stimmt zwar, aber sicher nicht "kuendigung-maier.doc.recent-documents.customer-102321.example.com", es wird z.b. abgfragt: "www.winfuture.ch", aber keine Dokumentnamen!

Zu 5.: Tunneling ist ja genau dazu da und wird auch gnutzt. Früher hab ich für einen Test im Geschäft auch einen HTTP Tunnel gebraucht, um gewisse Dienste im Internet von mir aus zu gebrauchen. Allerdings ist nur nur möglich wenn 1. HTTP freigegeben ist und 2. das Programm selber!

Zu 6.: Jo, das kommt vor. Aber was das mit einer firewall zu tun hat, ist mir nicht ganz klar. Ich denke, dass hat mit dem Browser zu tun... Wobei ein Alternativbrowser ja sowieso klar ist.

Zu 7.: Ok, das mit em Ersetzen von Dateien ist gut möglich. Aber wie geschieht sowas? Durch einen Virus oder Wurm. Wie kommt der rein? Sicher nicht über die Firewall, sondern über Email oder anderi Sachen. Aber klar: wenn man per Mail einen Virus aktiviertn, kann man schlussendlich alles machen...

Zu 8.: Auch hier, das Programm muss man ja erst einmal isntallieren haben. Beispielsweise über Mail, aber auch hier ist FW nicht schuld.

zu 9.: Ja... kommt vor(siehe oben)

Zu den Angriffen von aussen: alle drei sind möglich, wobei 1 und 3 klae Benutzerfehler sind. Bei 2. ist jeder Programm betroffen, denn Bugs kommen immer vor .


Weiterhin frage ich mich zu den Argumenten: eine Firewall bringt nichts, da die Ports ja sowieso geschlossen sind, wenn ein Programm ins Inet möchte, ist der Port sowieso offen. Das mag stimmen, aber: meine Firewall verhindert, dass fremde Programme einfach Ports öffnen und verhindert, dass sie einfach durch einen offenen Port hereinstolzieren.

Dabei ist wohl klar, dass man sich nicht mit ZA schützen kann. Es muss schon was anständiges sein, Hardware Firewall oder Tiny, dann allerdings bietet eine Firewall wunderbaren Schutz(Blast und Co. hatten beispielsweise keine Chance).

[Rika]

1. Nein, es ist ein generelles Problem von Application Control.
2. Stichwort: Tunnel über erlaubte Kanäle
4. nstx - IP-over-DNS ist da viel lustiger. Und du hast DNS nicht verstanden.
5. DNS, ICMP...
6. Die PFWs behaupten aber den Browser gegen Exploits schützen zu können.
7. Richtig. Und das bedeutet daß die Application Control nicht funktioniert.

>meine Firewall verhindert, dass fremde Programme einfach Ports öffnen
Nein, kann sie prinzipbedingt nicht.

>verhindert, dass sie einfach durch einen offenen Port hereinstolzieren.
Ja, aber lässt sich trivial umgehen. Ich sage mal nur IP Defragmentation Header Rewrite. Und macht das System auch gegen diverse DoS-Attacken überhaupt erst anfällig. Und manchmal kann man sogar genau über die PFW erst reinspazieren.

>Schutz(Blast und Co. hatten beispielsweise keine Chance)
Hatten sie auf gepatchten und/oder konfigurierten System auch nicht. Daher ist die PFW überflüssig.

[Gecko]

Hi,

Rika, darf ich dich was Fragen?


Ich lese seit geraumer Zeit mit großem Interesse deine Posts über IT-Sicherheit. Auch die von Dir angefügten Links zum Thema überfliege ich hin und wieder.

Nutz du persönlich eine Firewall?

Wenn ja, welche?

Denn ich habe es aufgegeben Symantec und Co. zu nutzen, nachdem ich eine Menge dieser Progs ausprobiert habe.

Über eine konstruktive Antwort würde ich mich freuen

[PanteraBM]

Nungut, du scheinst wieder alles zu widerlegen was ich mir überlegt habe
Mir sind aber einige Sachen nicht klar:

Zitat

du hast DNS nicht verstanden

Wäre froh um eine Erklärung, dachte ich wüsste, worum es bei DNS geht

Zitat

Nein, es ist ein generelles Problem von Application Control.

welches generelle Problem?

Zitat

>meine Firewall verhindert, dass fremde Programme einfach Ports öffnen
Nein, kann sie prinzipbedingt nicht.

Hab damit aber bisher gute Erfahrungen gemacht... Wieso funktionert es prinzipbedingt nicht?

Zitat

>Schutz(Blast und Co. hatten beispielsweise keine Chance)
Hatten sie auf gepatchten und/oder konfigurierten System auch nicht. Daher ist die PFW überflüssig.

Hier im Geschäft hatten alle den Sicherheitspatch nicht, die Firewall hat alles abgefangen. Bietet also den gleichen Schutz auch ohne Patches(soll nicht heissen, dass ich die Sicherheitspatches verteufel, mein System scannt laufend danach ).

Zitat

Ich sage mal nur IP Defragmentation Header Rewrite.

Toller Begriff... nur: was ist das?



Edit: denkst du wirklich, dass Rika, der ja eigentlich nur schlechtes über Firewalls schreibst, eine besitzt? I don`t think so. Falls du eine willst, nimmt Tiny, die Einzige, welche sich auch vernünftig konfigurieren lässt. Wie immer: Hirn anmachen

Dieser Beitrag wurde von PanteraBM bearbeitet: 19. August 2004 - 13:52

[wiz]

Zitat (Rika: 19.08.2004, 14:22)

7. Richtig. Und das bedeutet daß die Application Control nicht funktioniert.

mein ZA zeigt an, wenn ein Programm verändert wurde

[Rika]

@Gecko: Hier zuhause benutze ich zwangsläufig 'nen Router, aber in meiner Studentenbude nutze ich einen unmaskierten direkten PPPoE-Zugang. Ohne Paketfilter o.ä.

Aber derzeit baue ich mir aus sowas, Linux und iptables 'ne kleine Firewall-Appliance. Und 'n P1-150-Rechner steht hier auch noch rum.

@PanteraBM:

1. Es geht darum daß man ähnlich wie www. an den authorativen DNS-Server für winfuture.ch die Daten als die zugehörige Subdomain codiert, nicht als die Domain selber.
2. Das generelle Problem daß sie nicht funktioniert solange der User mit Adminrechten arbeitet und die Control Rückmeldungen im gleichen Benutzerkontext liefert.
3. Sie kann keine Ports schließen - schau dir doch mal die Ausgabe von "netstat -ano" an, dann siehst du's.
4. _und/oder konfigurierten System_ -> auch ohne Patches und ohne Packetfilter unanfällig, unanfällig wenn die PFW ausfällt, unanfällig gegen sämtliche zukünftige Remote-Sicherheitslücken. Und das System wird schneller, stabiler und unproblematischer.
5. Kennst du dich mit TCP/IP aus?
Man nehme ein IP-Paket, fragmentiere es, verändere den Fragment Offset des zweiten auf den Beginn des ersten und packe als Payload in das zweite Paket den eigentlichen Payload. Alle gängigen PFWs sowie manche Router agieren dann wie folgt: 1. Sie erkennen, daß das Paket fragmentiert ist - warten auf das nächste Fragment. 2. Alle Fragmente sind vorhanden, jetzt wird das Paket defragmentiert. Dabi wird der Fragment Offset genutzt und der Payload der zweiten Pakets überschreibt komplett das erste - ein komplett neues Paket entsteht. Der Fehler ist daß der Inhalt der bereits vorhanden Daten nicht statisch deklariert wird. 3. Diese Paket wird geprüft. Absenderadresse ist die eigenen IP bzw. 127.0.0.1 - klar, ungefährlich, weiterleiten. Da die Adresse ja nur im Payload, nicht aber im Header der ursprünglichen Pakete stand, kann man problemlos lokale Adressen verwenden und somit auch NAT-Geräte durchtunneln. 4. Jetzt wo das Paket erstmal durch den Paketfilter geschlüpft ist, kann man alles anstellen wovor der Packetfilter schützen sollte.
Die Geschichte ist nicht allzu neu und hat beim sogenannten Land-Angriff Win98, auch Linux zu diesem Zeiten und fast sämtlcieh gängige Hardware-Geräte gehörige Kopfschmerzen bereitet.
Also eigentlich 'ne alte Geschihcte... warum es die Hersteller sämtliche PFWs bis heute nicht hinbekommen haben, obwohl man es ihnen seit Jahren predigt...

@wiz:
Und wenn das Programm das ZA sagt daß das OK ist, dann zeigt dir ZA das nicht mehr an.

[PanteraBM]

Vielen Dank für die Antworten. 2 Dinge hab ich aber noch:

>>>>Es geht darum daß man ähnlich wie www. an den authorativen DNS-Server für winfuture.ch die Daten als die zugehörige Subdomain codiert, nicht als die Domain selber.<<<<

Ich hab das so verstanden: www.winfuture.de wird zu 212.72.175.18 oder umgekehrt, je nachdem. Was ist da an meiner Überlegung dann falsch, wenn ich behaupte, es werden dabei keine Dokumentnamen abgefragt, verstehe deine Aussage nicht...

>>>>Sie kann keine Ports schliessen<<<<
Heisst also, wenn ich der Firewall definiere, dass kein Programm durch Port 9996(z.B.) kommen darf, wird das gänzlich ignoriert und ein Programm, beispielsweise ein Wurm, kann trotz der Definition durch diesen Port reinkommen? Ich kann doch einstellen, dass durch Port x nichts durchkommen darf... oder dass durch Port 23 nur Programm xy darf, sobald ein Anderes durch will, meldet es mir die FW.

Punkt 5: gut erklärt

Dieser Beitrag wurde von PanteraBM bearbeitet: 19. August 2004 - 20:36

[Rika]

1. Wenn www.winfuture.de aufgelöst wird, dann geht www.winfuture.de an deinen DNS-Server. Der schaut nach "aha, de, mal an den Root-Server", der Root-Server verweist auf deNIC, deNIC schaut nach "winfuturede", aha, schicken mers an deren DNS-Server, ns.winfuture.de bekommt dann "www|winfuture.de", www ist also eine Submoain auf winfuture.de

Bin ich nun einer mit hinreichend Einfluss und stelle für winfuture.de selber einen Nameserver auf, der für diese Domain dann authorativ ist - dann bekomme ich sämtliche Anfragen an sämtliche Subdomains von winfuture.de, inklusive der nichtexistenten wie z.B. Kuedigung.Maier.doc.winfuture.de oder noch besser gleich entsprechend escapete Daten (4e8G-kflMsj8722.winfuture.de). Die Antworten schicke ich im TXT-Record zurück - und, was wunder, shcon habe ich einen Tunnel IP-over-DNS.

2. Nein. Aber wenn etwas durchkommt, dann nimmt das Programm die Daten trotzdem an. Was bei einer Umgehung der Firewall nach benannter Methode also schädlich ist.
Ebenso kann dann kein anderes Programm diesen Port öffnen.