Firewalls knacken

Kann mir einer sagen wie man Firewalls knacken kann?

....man kann es sagen , aber ich tu es nicht !
Es gibt bestimmte Sachen , wo man von "Hacken" spricht. Wesentlich ist , was man ereichen will , ob es legal oder illegalen Hintergrund hat ! Das Umgehen einer Firewall hat für den Normal-User keinen Wert ,es bringt keinen Nutzen. Wer FW knacken will strebt Illegale Dinge an.Dies wird auf diesem Board definitiv nicht unterstützt.
Selbstverständlich gibt es Möglichkeiten Firewalls zu umgehen. Diese sind zum Teil sogar recht simpel !

cu

Ja ok, dann sag es halt net! Ist ja net mein problem!

@winnie ...... sogar kinderleicht*gg*.
Menno wer ein bischen nachdenkt kommt von selbst drauf ....... welche ports sind standartmässig geöffnet ? Die vom IE und AIM,ICQ usw. Alles klar ?

Jo. Thx @NoName

nun ja, so pauschal würde ich das mit dem umgehen nicht sagen.

es gibt natürlich viele wege firewalls zu passieren.
und was bei der einen klappt muss bei der anderen firewall noch lange nicht klappen.

es gab in der vergangenheit angriffe auf firewalls in dem man datenpakete so klein fragmentiert hatte, dass die firewall das paket auf einem port connecten liess, welcher eigentlich als geblockt galt.

desweiteren ist eine sehr beliebte methode datenpakete, z.b. durch einen proxy an andere zielports zu tunneln.

anderseits gibt es aber auch durchaus programmierfehler in der firewall software selbst, die dazu führen können, dass z.b. durch einen gezielten pufferüberlauf in stack/heap/kernelspace code injected wird der dann z.b. eine shell spawned.

selbst stateful-inspection firewalls die input und output traffic kontrollieren, können zwar portbinding bzw. connectback shellcodes nach aussen blocken, nicht aber findsocketcodes. diese hängen sich an sockets bereits authorisierter systeme und dürfen deshalb ungehindert durch.

wird dann der traffic auch noch verschlüsselt, macht selbst die beste application firewall nix mehr.

cheers

johnny

Jep ! Sehr gut erläutert ! Mit dem Pufferoverflow dürfte aber bei den meisten guten FW`s der Geschichte angehören ! Aber gerade mit angehängten Codes läßt sich auch ohne große Kentnisse die FW-Funktion aushebeln. Was NoName meinte , ist , das gerade "normale" Daten die FW passieren können. Diese können als normale HTML-Codes in Dokumenten den Port 80 passieren , ohne das eine FW das anstößig findet. Bestes Beispiel sind die neuen Arten von Dialer-Programmen. Ohne ein hinterlegtes Muster sind diese durchaus sofort aktionsfähig . Neuere Trojaner benutzen ebenfalls diese Vorgehensweise um ihre Clients abzulegen. Ohne hinterlegtes Muster (Signatur) ist auch da die FW machtlos , da es sich ja um "ganz normale Anwendungen" handelt. Womit ich nun auch die Frage des Threadstarters beantwortet habe. Daher auch mein etwas "simpler" Erklärungsstil , aber Otto-Normalverbraucher kann mit einigen Fachwörtern eh nichts anfangen. (Auch ich muß ab-und an mal bei einigen Wörtern nachschauen *g*)

cu

firewalls werden in der regel, weniger auf bugs geaudited als daemons. selbst daemons die
zur majorklasse gehören, wie z.b. bind oder apache
und schon von tausenden geaudited wurden, weisen immer wieder fehler auf. gerade wenn firewalls an sich auch services bereitstellen, wie z.b. ssh, smtp, ftp usw. wie es auch bei den grossen enterprise firewalls der fall ist ( checkpoint, cisco pix usw. )
früher wurden wesentlich mehr bugs gefunden,
da nicht auf secure code qualität geachtet wurde.

einfache bugs wie unchecked buffers z.b. via
strcpy (buf,argv[1]);
brachten schon den morris wurm hervor.
lange glaubte man strncpy(buf,argv[1],sizeof(buf));
wäre sicher. leider falsch. hier hat man es mit einem off-by-one zu tun, der ebenfalls exploitable ist. off-by-ones sind übrigens im code zum teil sehr schwer aufzufinden und finden sich immer wieder, dann und wann auch in bekannten, schon oft geauditen services. einige zeit glaubte man auch mit malloc allozierte speicher seien sicher, da im heap und nicht stack gelegen. fakt aber ist, dass auch hier exploits möglich sind, nur halt etwas anders als beim stack smash. hinzu kommen noch viele andere bug-klassen ( signed integers, formatstrings, additionsbugs usw.)

da firewalls sich oft, standard libraries bedienen, wie z.b. der glibc oder zlib, sind auch diese dann vulnerable.

der einzige unterschied zu früher ist halt, dass das normale bug-fuzzing nur noch selten funktioniert.
hier ist entweder source-code analyse oder reverse engineering angesagt.

fakt ist, dass man auch einem stück firewall-code nicht unbedingt mehr vertrauen muss als jedem anderen service auch.

wer security in advanced mode haben will, sollte mit policy based OS acls arbeiten und kernel-patches wie PAX arbeiten. ein non-excutable stack/heap macht zwar einen daemon noch nicht immun gegen einen denial of service attack, schützt aber doch sehr gut gegen remote code execution.
sogar wind0wZ l4m3r können sich da z.b. securestack 2.0 bedienen, um vor dieser art von angriffen gefeiht zu sein.

cheers

johnny