Gefährliche Personal Firewalls - Die Sicherheitslüge!

[moscht]

dann musst Du mal Urlaub am Bodensee machen :smile: das wär ja nichtmal aus der welt...

haste aim, icq, yahoo?! mir is halt sonntags manchmal langweilig...und am bodensee isses schön ;D



wieviel eine "richtige" Konfiguration bringt, kann ich kaum beurteilen - auf jeden Fall haben wir hier eine Arbeitsgruppe, nun, brauchst Du einen bestimmten Trojaner, oder einen bestimmten Virus ?? Sach' Bescheid :biggrin:
ich kenn uninetze... ;)

allerdings kann ich mir viren etc auch "kontrolliert" besorgen... :)

diese Rechner sind "überhaupt nicht" konfiguriert und gepatched schon gar nicht. Man hätte sich aber einiges "ersparen" können, wenn diese Rechner zumindest teilgepatched gewesen wären... das mit sicherheit, nur wer will das schon machen...

andererseits ist es in letzter Zeit "besser" geworden. Meine Firewall hat praktische keine Hits mehr die aus der Uni kommen, dito für Viren-Mails
ob das alles so böse programme sind die ports ausm uninetz absuchen :X ;) kann man ja nie wissen :)

[No.3]

das wär ja nichtmal aus der welt...

haste aim, icq, yahoo?! mir is halt sonntags manchmal langweilig...und am bodensee isses schön ;D

weder das eine noch das andere und schon gar nicht das dritte :biggrin:

reg Dich einfach mal, dann kannst Du mir eine PM schicken

ist Sonntags in Schtuagert nix los ??


allerdings kann ich mir viren etc auch "kontrolliert" besorgen... :)

nun, das lief ziemlich unkontrolliert ab. Aber wie gesagt, mittlerweile ist es besser geworden. Wir haben denen auch ein paar Mal auf die Zehen getreten, dass die die Patches einspielen sollen. Auch die Uni hat einige Ports geschlossen etc. Mittlerweile ist es doch wesentlich ruhiger geworden.

Rainer

[Moscht]

Zudem läuft der Kerio-Dienst mit System-Rechten, so einfach abschiessen ist also auch nicht.
ob das wirklich von vorteil ist, wenn das ding mit systemrechten läuft ;)
denk nicht nur an das reine umgehen dieses dienstes...sondern u.a. auch an den möglichen missbrauch dieses dienstes...
es ist eben ein dienst mehr, der fehleranfällig sein kann...

der schlichte tcpip filter hätte hier wohl einen ähnlichen wenn nicht wesentlich effektiveren effekt...

Das ist ein Punkt, wo eine PFW echt nützlich ist - eine strikte Bindung des Servers an die Client-PCs.würd ich hier eine pfw auf nem server finden, da würde der zuständige herr von mir aber schleunigst auf die griffel bekommen...
die server bieten dass was se anbieten sollen an, alles andere ist dicht und damit ist nicht gemeint, dass irgend ein programm sich versucht davor zu schieben...

Anm.: Es ging nicht darum die Daten des Servers vor Leuten zu schützen, die sowieso Zugriff zu den Client-PCs haben, aber wer es jetzt schafft Zugriff vom INTERNET auf den Server zu bekommen, verdient meinen Respekt...

(auf dem normalen Desktop ist es natürlich quatsch, die WinXP-FW der Clients ist nur nicht deaktiviert, wegen faul :wink: )logik? will jemand wirklich in dein netz/auf dein server, geht er meist nicht den schwersten weg...und da bieten sich deine clients ja geradezu an!

[---]

.

[BUGFIX]

Huch,

was ist denn hier auf einmal los?

Du hast Dich gerade lächerlich genmacht und selbst disqualifiziert - herzlichen Glückwunsch (oder herzliches Beileid wie man's nimmt).
Aber gut extra für Dich, wenn keine Services nach aussen angeboten werden sagt das estmal nur das der Rechner _nichts_ nach aussen anbietet, so weit klar?
Wenn ich jetzt auf diesem Rechner meinen Webbrowser (temporär) starte wird logisch eine Verbindung aufgebaut und logisch öffnet der Browser dann einen Port, soinst könnte er ja nicht kommunizieren (woraus folgt das Du da auch mit Deiner PFW nichts blocken kannst). Wenn ich den Browser beende ist wieder Schluss und nichts wird nach aussen angeboten, alle Ports sind geschlossen - so einfach ist das. Entweder kannst Du oder willst Du nicht verstehen.


Ich kenne den Funktinsablauf des TCP-Handshaking. Wenn ein Programm einen Socket aufmacht, dann kann es Im prinzip auch SYN-Pakete engtgegenehmen - dass dies ein Webbrowser nicht macht - ist ne glücklioche Sache - muss aber nicht sein.

Das Ulukays Software über jeden Zweifel erhaben ist wissen wir ja jetzt

Dennoch hätte der Browser auch syn-PAkete annehmen können, und dann hätte man mit 'netstat -ano' nur noch zuschauen können dass da irgenwelche Socket-Operationen stattfinden (womit ich über die Art und Länge des Pakets immer noch nix weiß - aber egal)


Ganz toll, was Du sagst ist also, wenn kein Programm nach draussen darf (kein Passierschein da ist), kann auch kein Programm missbraucht werden?
Ganz Toll wirklich messerscharf kombiniert.

Jetzt zeig mir mal den User wo es nicht ein (also kein) Programm gibt nach draussen senden darf?


Wiedermal willst du nicht (dass du das nich könntest , nehm ich dir nicht ab) zwischen darf Traffik überall hin und darf Traffik nur zu bestimmte Zielen unterscheiden.
Pauschal nach draußen? hm - nö - die Tasache dass ich eine Gegenprobe gemacht habe um mir genau das zu bestätigen (testweise - ne regel erstellt und siehe da - dann kann er auch raus) ändert auch nix daran.
Es geht halt nur mit einem solchen Wirt.


Was soll das denn? Wie bist Du denn? 14? Wir sind hier doch nicht im Kindergarten.


Ganz einfach - ein wieder mal missverstandener Kommentar; wie doch Leute manchmal am Wort von anderen kleben - Das hat schon was von Heilspredigern.


Komischerweise wurde es nicht von Deiner PFW geblockt...


Wenn etwas geblockt wird, muss ich sicherstellen, dass es auch wirklich meine PFW war - deswegen werden ich (nur für Testzwecke) auch die PFW so konfigurieren, dass er durch kann. quasi als gegenprobe...



Zeig' mir den User bei dem kein Browser (oder sontiges Programm - es gibt auch eine Version für den E-Mail Client Thunderbird) ins Internet darf. Leider hast Du den Sinn eines Proof of Concept immer noch nicht verstanden und versucht dies durch billige Polemik wett zu machen. Nun Leute Die weniger von dem Thema verstehen magst Du damit beeindrucken, mich lässt das jedoch völlig kalt. (Was mich zu dem Schluss bringt, das Du von dem allg. Thema leider nicht so viel verstehst, wie Du Dir das vorstellst).


[] den Unterschied zwischen garnich im Internet und rgelementiert im Internet verstanden.
Mache Programme dürfen nur ganz bestimmte Sachen - andere nur im Lan - nix desto trotz kann man auch so arbeiten.


Blödsinn, wie jemand so lernresistent sein kann ist echt unglaublich. Mehr Code immer erhöhtes Sicherheitsrisiko völlig gleich ob Opensource oder nicht. Ulukay hat es bereits schon gesagt -[...].


Richtig - die Betonung liegt auf Risiko (= muss im Einzellfall nicht so ein)
Ulukay Aussage diesbezüglich war aber eine Andere.


Du hast Das scheinbar nicht verstanden - wenn ich über das http-Protokoll eine ftp-Anfrage 'tunnel' sieht das von aussen aus als würde ich eine normale http-Anfrage senden. Innen wird FTP 'betreiben' und aussen herrum (der Tunnel also) ist http. Das kann man nunmal so gut wie gar nicht überwachen - und schon gar nicht mit einer PFW.


Womit du wieder einen Wirt (für den Tunnel) brauchst, und du also wieder vorraussetzt, dass irgend ein Programm überhaupt den Connect zum 'Ziel' schafft.


'Ist' würde ich nicht direkt sagen, aber potenziell sicherer ist Opensource Software IMHO schon. Beispiel die Kernel der Betriebssysteme: Windows Kernel vielleicht 1000nde Entwickler, Linux Kernel hat dagegen 100.000ende wenn nicht soagr ne Million von Entwicklern. Quizfrage: Wo werden wohl mehr Fehler entdeckt?


Bei dem Projekt das genauer durchgelesen wird => dürfte bei Open source leigen.
Aber nich aufgrund der Masse, sonder eher , weil es Eizelne giebntr den den Code genaustens Abklopfen, immer mit der Überlegung, was man tun müsste um in soetwas einzubrechen.
Und da wird wird leider Seitens MS bei Microsoft zu wenig gemacht.


Noch etwas zu Dir BUGFIX, es tut mir ja leid, dass Du einiges scheinbar nicht nachvollziehen kannst (oder willst), dass ändert aber immer noch nichts daran das es der Wahrheit entspricht.
Fakt ist doch, dass Deine PFW breakout nicht aufhalten konnte, Du musstest das selbst Durch geeigente konfiguration machen.
Also, sorry deutlicher geht es doch nicht mehr - deine PFW hat da klar versagt, deshalb könnte man doch mal darüber ruhig und sachlich nachdenken, dass Deine Aussagen bzgl.Tunneling und den Missbrauch von guter Software eben weitestgehend falsch sind, da die PFW eben nicht geholfen hat. (was für einen Beweis willst Du denn noch?)
Wenn Du immer mehr haltlose Polemik hinterher wirfst, werden Deine Ausfürhungen dadurch nun mal auch nicht richtiger.


Ich habe eine Konfiguration 'gebastelt' die auch dann noch geht (zugegeben nicht inn 100% der Fälle) - falls man eine solchee Regel hat. Und das eingelich nur, damit die Leute die Sagen, dass hat jeder so, merken, dass auch in diesem Fall einiges verhindert werden kann.
Du erinnerst dich an die Tabelle? Eben weil sie nicht 100% der Fälle abhält, hab ich das Y bei Tunneling mit dem Sternchen versehen. Und auch wenn du das ganricht akzetpieren willst. Selbst wenn du annimmst, dass alle Tunneling versuche glücken, ist gegenüber der Konfiguration ohne PFW nichts verloren. Aber mit 'netstat -ano' kommt man da nicht wieter.

Es fehlt also immenoch der Beweis für die Behauptung: ein System mit PFW ist immer unsicherer als ein System ohne.


MfG
BUGFIX

[Sith_TirEilo]

Hi,

Ich kenne den Funktinsablauf des TCP-Handshaking. Wenn ein Programm einen Socket aufmacht, dann kann es Im prinzip auch SYN-Pakete engtgegenehmen - dass dies ein Webbrowser nicht macht - ist ne glücklioche Sache - muss aber nicht sein.

Das Ulukays Software über jeden Zweifel erhaben ist wissen wir ja jetzt

Dennoch hätte der Browser auch syn-PAkete annehmen können, und dann hätte man mit 'netstat -ano' nur noch zuschauen können dass da irgenwelche Socket-Operationen stattfinden (womit ich über die Art und Länge des Pakets immer noch nix weiß - aber egal) *seufz* - langsam kann ich Ulukay verstehen.

Wiedermal willst du nicht (dass du das nich könntest , nehm ich dir nicht ab) zwischen darf Traffik überall hin und darf Traffik nur zu bestimmte Zielen unterscheiden.
Pauschal nach draußen? hm - nö - die Tasache dass ich eine Gegenprobe gemacht habe um mir genau das zu bestätigen (testweise - ne regel erstellt und siehe da - dann kann er auch raus) ändert auch nix daran.
Es geht halt nur mit einem solchen Wirt.Ach mensch... ich bin es echt leid. Aber gut, was lass ich mich auch auf so eine Farce ein.
Nun gut. Du sagst also, das bei Dir der Webbrowser nicht überall hinsenden darf? Das heisst, immer wenn Du auf einen fremden Link (z.B. hier im Forum) klickts, musst Du erst die Adresse dahinter freischalten, damit Du die auch mit Deinem Browser anschauen kannst? Auch bei Onlinespiele (sofern du manchmal zockst) musst Du jedesmal die IP des Gameservers freischalten, damit dein Game funktioniert? Damit das ganze Sinn macht, müsstest Du alle IPs die Du im Laufe des Tages freigeschaltet hast und die zufällig zum IP-Pool einens Providers gehören, am nächsten Tag wieder verbieten, da sich theoretisch eine böse Gegenstellte eingewählt haben könnte.
Ich habe ja schon viel gehört, aber das sich jemand sebst das Internet kastriert ist echt fast nicht zu glauben... aber gut... wie Du meinst. *kopfschüttel*

Hätte ich das vorher gewusst, hätte ich weniger Links für Dich gepostet, muss ja ne heiden Arbeit gewesen sein die alle freizuschalten - SCNR.

Ganz einfach - ein wieder mal missverstandener Kommentar; wie doch Leute manchmal am Wort von anderen kleben - Das hat schon was von Heilspredigern.Schwachsinn!
Wenn etwas geblockt wird, muss ich sicherstellen, dass es auch wirklich meine PFW war - deswegen werden ich (nur für Testzwecke) auch die PFW so konfigurieren, dass er durch kann. quasi als gegenprobe...[ ] Du hast verstanden was ein formaler Beweis ist
[X] Du willst Dich mit Beweisverfahren (http://de.wikipedia.org/wiki/Beweis_%28Mathematik%29) beschäftigen (hoffentlich ist Wikipedia bei Dir schon freigeschaltet...)

[ ] den Unterschied zwischen garnich im Internet und rgelementiert im Internet verstanden.

Mache Programme dürfen nur ganz bestimmte Sachen - andere nur im Lan - nix desto trotz kann man auch so arbeiten.

[...]

Womit du wieder einen Wirt (für den Tunnel) brauchst, und du also wieder vorraussetzt, dass irgend ein Programm überhaupt den Connect zum 'Ziel' schafft.
Also ich habe selten soviel Ignoranz und Lernresistenz erlebt.

[X] Du hast das Prinzip von Tunneling nicht verstanden
Funktioniert logsich nur wenn ein Wirt da ist den (bzw. das) man 'tunneln' kann - man man man....


[X] Du hast die Idee hinter breakout nicht verstanden

Also noch mal ganz langsam extra für Dich:

Die These ist: Es ist nicht möglich mit einer PFW (und nicht sonstigen Methoden) zu verhindern das ein vertrauenswürdigesProgramm X von einem bösen Programm Y dazu benutzt werden kann um böse Daten Z zu senden.
Dabei wird von einem Homeuser ausgegangen, da Homeuser nun mal die Zielkundschaft von PFWs sind (Quizfrage, warum setzen keine seriösen Sicherheitsfirmen PFW auf ihren Clients ein, wenn sie doch so toll und sicher sind?), auserdem wird davon ausgegangen das es mind. ein Programm auf dem Rechner gibt, welches uneingeschränkten Zugriff auf das Internet hat und damit als vertauenswürdeig eingestuft wird. (z.B. ein Browser der ganz normal innerhalb normaler Parameter funktioniert). Ob Du das nun glaubst oder nicht, aber stell Dir vor, bei nahzu jedem User gibt es ein solches Programm, da ich niemanden kenne der sein System freiwillig so verstümmelt wie Du es tust. Es wird dabei hier also von einem Druchscnittsrechner ausgegangen.

Soweit zur These um das nun zu beweisen wird folgendes gemacht:
X = IE
Y = breakout
Z = Aufruf der Site http://www.dingens.org/breakout.html (Die Domain hast Du ja zum Glück schon freigeschaltet)

Wenn Du das nun blockst, weil es bei Dir kein Programm mit freiem Internetzugang gibt bzw. weil Du schlicht kein vertrauenswürdiges Programm auf dem Rechner hast, ändert das nach wie vor nichts an der Korrektheit des Beweises - denn auch dein kastrierter IE hatte gesendet ohne das die PFW dies gemerkt hat.

Es geht hier einzig darum, das die PFW nicht merkt das dass vertrauenwürdeige Programm getunnelt wird. Nicht mehr - nicht weniger.

Du erinnerst dich an die Tabelle? Eben weil sie nicht 100% der Fälle abhält, hab ich das Y bei Tunneling mit dem Sternchen versehen. Und auch wenn du das ganricht akzetpieren willst. Selbst wenn du annimmst, dass alle Tunneling versuche glücken, ist gegenüber der Konfiguration ohne PFW nichts verloren. Aber mit 'netstat -ano' kommt man da nicht wieter.Ach Du bist ja ein Held! Dann sag mir mal wieviel Tunnelingversuche Deine PFW blockt? sind 99%? Sind es 50%? Sind es vielleicht nur 1%?
Na kannst Du so eine Aussage treffen? Nein - oh wunder...
Also entweder Deine PFW schützt prinzipell vor Tunneling (sie kann also entscheiden ob ein Packet gute oder böse Daten enthält) oder eben nicht. Da sie es nicht tut schafft sie auch gegen Tunneling keine Abhilfe - sie schafft auch nicht ein bischen Abhilfe, oder gelegentlich Abhilfe. Man kann keine genauen Zahlen bringen, also schützt sie ganz bis gar nicht vor Tunneling.

Es fehlt also immenoch der Beweis für die Behauptung: ein System mit PFW ist immer unsicherer als ein System ohne.Deine tolle Tabelle:

X = keine Abhilfe
Y = Abhilfe

1) Software (API-konform) 'telefoniert' nach hause (siehe tunneling)
mit Firewall: X | ohne: X

2) Software versucht zu tunneln
mit Firewall: X | ohne: X

//spiel keine Rolle keine Ahung warum das in Deiner Tabelle auftaucht
3) DoS Attacken
mit Firewall: X | ohne: X

//Wenn keine Dienste angeboten werden, können auch keine Fehler darin ausgenutzt werden - Mit PFW schon, da der Dienst trotzdem noch offen ist, auch wenn die PFW sich davor setzt.
Aber grundsätzlich schafft nichts gegen OS Fehler Abhilfe. Selbstlos und edel wie ich bin kreide ich das auch mal nicht der PFW an
4) Implementierungsfehler im OS (Dienste usw.)
mit Firewall: X | ohne: X

5) Implementierungsfehler PFW
mit Firewall: X | ohne: Y

6) Prinzipelle Schwächen der Systemumgebung
mit Firewall: X | ohne: X

Hmm.. komischerweise sind die 'Y' bei der Konfiguration ohne PFW zahlreicher als bei der mit.

Aber da dir das als Beweis sicherlich wieder nicht reicht, dann bringe mir doch mal ein Beweis wo sie die Sicherheitslage erhöht. Denn wenn die Sicherheit nicht verringert wird und auch nicht erhöht wird (wo Du mir ja zugestimmt hast), wieso denn dann noch eine PFW? Wegen den vielen bunten Knöpfchen?
Also bring mir mal einen Anwendungsfall bei dem die PFW eine Schutz geboten hat, den man nicht durch vernünftige Konfiguration hätte erreichen können (und jetzt bitte nicht wieder ankommen mit: "Meine PFW hat SPYWARE X daran gehindert Daten zu senden")


Gruß,

Sith

[moscht]

Den man auch so leicht konfigurieren kann ;D
dankeschön :)

eigentor ;D

aber schwer zu konfigurieren ists ja nunmal wirklich nicht

ich hock auch zuhaus ;)


Ja, kommt auf die Art des Servers an...nein ganz und garnicht, egal was für n server, sowas wie ne pfw hat darauf nix verloren...



Ja, aber die Frage ist immer noch, WEM sie etwas anbieten...wenn man nicht gerade ne Server/Pro Version hat ist es keinesfalls so einfach und bequem bestimmte Clients von bestimmten Diensten auszusperren...bei win9x systemen stimme ich dir zu aber auch das geht, hier muss man zwar wirklich aufwand betreiben
allerdings bei zeitgemäsen systemen wie der kompletten nt schiene sehe ich darin kein problem (auch nicht bei winxp home), bei linux sehe ich kein problem damit, bei bsd nicht, irix, aix ebenfalls nicht...also nenne mir bitte diese client betriebssysteme die davon betroffen sind (was du anprangerst)




Ja, wenn er auf die Clients will muss er über den Router.... UND, die Clients bieten keinerlei Dienste an. Das ist der Punkt.
Der Server bietet zwangsläufig nen NetBIOS an, lässt sich nicht vermeiden.
Zudem liegen die wichtigen Daten wirklich auf dem Server, nicht auf den Clients...

EDIT: Vielleicht unklar gewesen - mit Server meinte ich natürlich private Sachen...Fileserver auf ner kleinen LAN, oder im HO etc. etc.gut hier bin ich von einem anderen standpunkt als du ausgegangen...

bieten die clients wirklich keine angriffsfläche? sprich der server dient zusätzlich noch als gateway, router, proxy VOR dem eigentlichen router? dann will ich auch nichts gesagt haben ;)

[(del676)]

Ich kenne den Funktinsablauf des TCP-Handshaking. Wenn ein Programm einen Socket aufmacht, dann kann es Im prinzip auch SYN-Pakete engtgegenehmen - dass dies ein Webbrowser nicht macht - ist ne glücklioche Sache - muss aber nicht sein.


nein hast du offensichtlich nicht, tcp handshaking und tcp pakete mit syn flag entgegennehmen tut sicher nicht der browser :rolleyes:

aber bitte, rede weiter unsinn wenn du dich weiter blamieren willst

[BUGFIX]

nein hast du offensichtlich nicht, tcp handshaking und tcp pakete mit syn flag entgegennehmen tut sicher nicht der browser :rolleyes:

aber bitte, rede weiter unsinn wenn du dich weiter blamieren willst

Dass der Browser kene Syns annimmt ist eine sache der Implemenierung -
im Prinzip kann man auch solche Ports (die zum engegennehmen von Verbindungspaketen gedacht sind) auch SYN annehmen.
Das TCP-Protokoll erlaubt die Annahmen von SYN bei geichzeitigem Setzten des Rest Flags. auch auf Port die eigentlich nur einer Spezifischen verbindung zur verfügung stehen sollten.
Aber wie schon gesagt - das ist eine Sache der Impementierung.

Dass dein Browser es nicht tut - was ich hoffen möchte - bedeutet noch lange nicht dass man Highports nicht vor SYNs schützen sollte.

@Sith_TirEilo

Aja- jetzt also wieder die "wenn es nicht 100% hilft - hilft es garnicht" Achiene. [Womit du dich völlig ins Aus schießt]
Gut selbst wenn dem So wäre :
Dein "alles richtig konfigurieren" bringt auch nix, da du NIE die 100% erreichen kannst.
Außerdem tippe ich mal darauf dass du dich noch anschnallst, was deiner Argumentation ja auch Schwachsinn ist, denn 100%Sicherheit brings ja auch nicht.

Bleib du nur auf dem Standpunkt. Was die Leser dieses Threads betrifft, kann ich nur sagen:
Überlegt euch selbst was ihr für eure Sicherheit tun könnt. Ihr müsst die Mittel und Wege wählen - und dass kann euch keiner Abnhemen - kein CCC ,keine PC Prof. und auch keine Softwarschmiede (obs sie nun Microsoft heißt oder Symantec).

Werde ich es also dabei Bewenden lassen, auch wenn andere meinen ständig den gleichen (nichfuntkionierenden) Sermon von Vorvorgestern als angebliche Beweise ins Feld zu führen.

MfG

BUGFIX

[---]

.

[Der Berater]

tcp handshaking und tcp pakete mit syn flag entgegennehmen tut sicher nicht der browser :rolleyes:

Sollte ich die Irnonie nicht verstanden haben: Sorry.
Ansonsten: Autsch.

http://img103.exs.cx/img103/765/3wayhandshake0vh.th.jpg (http://img103.exs.cx/my.php?loc=img103&image=3wayhandshake0vh.jpg)

[_kleinerMann_]

Aja- jetzt also wieder die "wenn es nicht 100% hilft - hilft es garnicht" Achiene. [Womit du dich völlig ins Aus schießt]Ich glaube Du hast das nicht so ganz verstanden, was man eigentlich sagen wollte. Ich versuche das mal zusammenzufassen:

Als erstes der Angriff von aussen: Bei einem Angriff von aussen hilft eine PFW eigentlich schon, da sie sich vor die Ports setzt und jedes Packet ablehnt, dass sich da verbinden will. Hier kann man sagen, dass eine PFW prinzipiell davor schützt (auch wenn sie im Einzelfall versagen kann). Hier würde ich auch sagen, dass eine PFW 'Sinn' machen würde, wenn man nicht das gleiche Ergebnis (wenn nicht sogar besser) durch das abschalten von Diensten erreichen könnte. Man kann aber sagen, dass eine PFW bei Angriffen von aussen prinzipiell schützt.

Jetzt Tunneling: Beim Tunneling ist es eben so, dass ein vertrauenswürdiges Programm antsatt 'guter' Daten, plötzlich 'schlechte' Daten sendet, wenn ich dass richtig verstanden habe. Eine PFW kann nun mal nicht unterscheiden, ob ein vertrauenswürdiges Programm gute oder schlechte Daten sendet. Deshalb schützt schon vom Prinzip her dagegen keine PFW. Meiner Meinung nach wird das in dem breakout-Programm auch gut gezeigt. Denn ich muss ehrlich sagen, dass zumindest bei mir der Browser jede Website besuchen darf und ich die nicht erst extra freischalten muss. So wie ich das verstanden habe, hat das bei Dir ja auch geklappt, nachdem Du dem IE als vertauenswürdig eingestuft hast. Also ich würde schon sagen, das der Beweis (so man ihn denn so nennen will) geklappt hat - sogar bei Dir.
Ich glaube mit den konkreten Zahlen meinte man auch anders, ich vermute man wollte damit sagen, wenn ein PFW schon prinzipiell nicht vor einer bestimmten Angriffsart schützt und man auch keine Zahlen nennen kann wann sie vielleicht doch mal schützt, ist das praktisch kein Schutz. Wenn man wenigstens sagen könnte 1 von 100 Tunnelingversuchen wird von der PFW geblockt, obwohl sie eigentlich prinzipiell nicht davor schützt, könnte man damit arbeiten, solche Zahlen fehlen nun mal leider. Also kann man auch nicht pauschal sagen das eine PFW da den Schutz erhöht, wie es von Dir behauptet wird. Klar, 100%igen Schutz wird es nie geben, aber wenn durch die PFW der Schutz eben auch nicht erhöht wird und man mit da seht wie ohne, werden die Dinger doch irgendwie obsolet, meinst Du nicht auch?


Viele Grüsse,

Der kleine Mann

[HellHorse]

Sollte ich die Irnonie nicht verstanden haben: Sorry.
Ansonsten: Autsch.
Wieviele Browser kennst du, die einen eigenen TCP-Stack haben?

[Der Berater]

Aus dem Kopf: Exakt einen.
Einen Lynx Port auf eine VAX mit modular aufgebauter Canop-State-Arch.
Im Rahmen meine Diss. habe ich interessante Projekte gesehen, die in die Richtung Browser-Sandboxing gingen.

Leider geht es in diesem Thread nicht mehr darum, den Gegenstand PF zu diskutieren, vielmehr ho(h)len nun alles Beteiligten ihre Dödel raus, wurschteln damit in der Luft herum und denken sich laut "Meiner ist länger als deiner!".

MfG
P.

[(del676)]

Sollte ich die Irnonie nicht verstanden haben: Sorry.
Ansonsten: Autsch.

http://img103.exs.cx/img103/765/3wayhandshake0vh.th.jpg (http://img103.exs.cx/my.php?loc=img103&image=3wayhandshake0vh.jpg)

der browser nimmt GAR keine pakete entgegen, das macht das OS
und 2. ist das ein ACK paket von der IP zu der du eine Verbindung aufbauen willst, kein syn paket zum verbindungsaufbau einer dritten ip :rolleyes:

[Der Berater]

der browser nimmt GAR keine pakete entgegen, das macht das OS

Nicht immer. Auf standard OS bezogen: You are right.

Und das SYN-Flag ist gesetzt, das war Gegenstand der Diskussion. Dass du etwas anderes meinst, ist mir klar. Nur solltest du es eben auch genau so schreiben und nicht hoffen, dass Leute hier interpretieren.
Schau mal, Leute, die sich in diese Diskussion einklinken sollten idealerweise profundes Wissen vorweisen können.
Bei solchen Diskussionen reagiere ich auf Geschriebenes, nicht auf das, was der Schreiber meinen könnte.

MfG
P.

[---]

.

[---]

.

[Sith_TirEilo]

Hi,

Als erstes der Angriff von aussen: Bei einem Angriff von aussen hilft eine PFW eigentlich schon, da sie sich vor die Ports setzt und jedes Packet ablehnt, dass sich da verbinden will. Hier kann man sagen, dass eine PFW prinzipiell davor schützt (auch wenn sie im Einzelfall versagen kann). Hier würde ich auch sagen, dass eine PFW 'Sinn' machen würde, wenn man nicht das gleiche Ergebnis (wenn nicht sogar besser) durch das abschalten von Diensten erreichen könnte. Man kann aber sagen, dass eine PFW bei Angriffen von aussen prinzipiell schützt.

Jetzt Tunneling: Beim Tunneling ist es eben so, dass ein vertrauenswürdiges Programm antsatt 'guter' Daten, plötzlich 'schlechte' Daten sendet, wenn ich dass richtig verstanden habe. Eine PFW kann nun mal nicht unterscheiden, ob ein vertrauenswürdiges Programm gute oder schlechte Daten sendet. Deshalb schützt schon vom Prinzip her dagegen keine PFW. Meiner Meinung nach wird das in dem breakout-Programm auch gut gezeigt. Denn ich muss ehrlich sagen, dass zumindest bei mir der Browser jede Website besuchen darf und ich die nicht erst extra freischalten muss. So wie ich das verstanden habe, hat das bei Dir ja auch geklappt, nachdem Du dem IE als vertauenswürdig eingestuft hast. Also ich würde schon sagen, das der Beweis (so man ihn denn so nennen will) geklappt hat - sogar bei Dir.
Ich glaube mit den konkreten Zahlen meinte man auch anders, ich vermute man wollte damit sagen, wenn ein PFW schon prinzipiell nicht vor einer bestimmten Angriffsart schützt und man auch keine Zahlen nennen kann wann sie vielleicht doch mal schützt, ist das praktisch kein Schutz. Wenn man wenigstens sagen könnte 1 von 100 Tunnelingversuchen wird von der PFW geblockt, obwohl sie eigentlich prinzipiell nicht davor schützt, könnte man damit arbeiten, solche Zahlen fehlen nun mal leider. Also kann man auch nicht pauschal sagen das eine PFW da den Schutz erhöht, wie es von Dir behauptet wird. Klar, 100%igen Schutz wird es nie geben, aber wenn durch die PFW der Schutz eben auch nicht erhöht wird und man mit da seht wie ohne, werden die Dinger doch irgendwie obsolet, meinst Du nicht auch?Ja so in etwa kann man das sagen.

Aja- jetzt also wieder die "wenn es nicht 100% hilft - hilft es garnicht" Achiene. [Womit du dich völlig ins Aus schießt]
Gut selbst wenn dem So wäre :
Dein "alles richtig konfigurieren" bringt auch nix, da du NIE die 100% erreichen kannst.
Außerdem tippe ich mal darauf dass du dich noch anschnallst, was deiner Argumentation ja auch Schwachsinn ist, denn 100%Sicherheit brings ja auch nicht....ja ist schon gut... passt schon...


Was bringt es mir jetzt eigentlich konkret, wenn ich IPSEC verwende statt der Kerio um den Traffic zu filtern ?

Vorher lief der Kerio Dienst aber kein IPSEC-Dienst. Jetzt ist es andersrum.

Ich nehme mal an, dass IPSEC "sicherer" ist, weil es tiefer im System steck, right ?IPSec ist eine Protokoll Erweitrung für das IP, dementsprechend ist es auch kein Programm somit kannst Du das nicht direkt mit einer PFW vergleichen, siehe dazu:

http://de.wikipedia.org/ipsec
http://www.microsoft.com/germany/ms/security/newsletter/artikel/ipsec.mspx
http://www.microsoft.com/germany/ms/security/newsletter/artikel/ipsec2.mspx

Gruß,

Sith

[Der Berater]

Und, kennt jemand eine GUI-Anwendung, welche die komfortabel nötigen Regeln erstellt ? Denn es ist ziehmlich umständlich für jeden Port und jede IP ne Regel zu machen... Gibt es sowas ?

Aber sicher:
http://www.hernanracciatti.com.ar/ipfront/

Wünsche viel Spaß.

MfG
P.

[BUGFIX]

Ich glaube Du hast das nicht so ganz verstanden, was man eigentlich sagen wollte. Ich versuche das mal zusammenzufassen:


Gut, schauen wir uns die Sache in Ruhe und Stück für Stück an.


Als erstes der Angriff von aussen: Bei einem Angriff von aussen hilft eine PFW eigentlich schon, da sie sich vor die Ports setzt und jedes Packet ablehnt, dass sich da verbinden will. Hier kann man sagen, dass eine PFW prinzipiell davor schützt (auch wenn sie im Einzelfall versagen kann). Hier würde ich auch sagen, dass eine PFW 'Sinn' machen würde, wenn man nicht das gleiche Ergebnis (wenn nicht sogar besser) durch das abschalten von Diensten erreichen könnte. Man kann aber sagen, dass eine PFW bei Angriffen von aussen prinzipiell schützt.

gut - da sind wir uns ja wie mir scheint einig.


Jetzt Tunneling: Beim Tunneling ist es eben so, dass ein vertrauenswürdiges Programm antsatt 'guter' Daten, plötzlich 'schlechte' Daten sendet, wenn ich dass richtig verstanden habe. Eine PFW kann nun mal nicht unterscheiden, ob ein vertrauenswürdiges Programm gute oder schlechte Daten sendet. Deshalb schützt schon vom Prinzip her dagegen keine PFW. Meiner Meinung nach wird das in dem breakout-Programm auch gut gezeigt. Denn ich muss ehrlich sagen, dass zumindest bei mir der Browser jede Website besuchen darf und ich die nicht erst extra freischalten muss. So wie ich das verstanden habe, hat das bei Dir ja auch geklappt, nachdem Du dem IE als vertauenswürdig eingestuft hast. Also ich würde schon sagen, das der Beweis (so man ihn denn so nennen will) geklappt hat - sogar bei Dir.


Wenn du zu einem Ziel den Traffik erlaubt hast, und dein Browser betrügt dich und sendet innerhalb der Verbindung Daten, die er nicht senden soll, bist du schon in die Kategorie der "alles Verloren" Fälle.
Denn wenn deine 'trustet' Programme gegen dich arbeiten, kannst du nicht tun außer jegliche LKommunikation unterbinden. Da Spielt die PFW aber ebensowenig eine Rolle wie "alle Dienste zu" oder IPSEC, PGP oder SSH, oder was auch immer du für Schutzmechanismen (für Inhalt) aufzählen willst.
Insofern sind wir bei diesem Beispiel wieder bei einer gleichstandsituation angekommen.
In diesem Fall müsste aber deine Gegenstelle Teil des Angriffs sein, denn ein normaler Server (wie der 3dCenter-Server) wird in einem solchen Fall nicht mitspielen, da er mit dem 'Bösen traffic' nix anfangen kann.

Was die Tunneling-Beispiele betrifft, liegt die Sache aber etwas anders. Denn hier wird nicht eine Bestehende und erlaubte Verbindung ausgenutzt, sonderen versucht unter dem Deckmantel eines Programms das möglicherweise 'trusted' (aber das hängt von deinem Regelwerk ab) ist daten an Dritte zu senden.
Und diese neue Verbindung lässt sich immer erkennen und aushebeln. Das meinte ich mit Prinzipiel nicht funktional.
Die PFW tut in beiden Fällen genau das was du ihr gesagt hast. Im einen Fall (dem IE ist alles erlaubt) macht sie genau das. der IE baut eine verbindung auf, die PFW prüft mit dem Regelwerk gegen - passende Regel gefunden - und die Verbindung kommt zur stande.
Im anderen Fall (dem IE ist nicht alles erlaubt) wird die Firewall den Versuch des Verbindungsaufbaus erkennen und, da keine passende Regel exisiert, diesen entweder Abblocken oder den Benutzer fragen.
Du siehst die Funktion einer PFW wird auch durch Breakout (in welcher Variante auch immer) nicht unterwandert.


Ich glaube mit den konkreten Zahlen meinte man auch anders, ich vermute man wollte damit sagen, wenn ein PFW schon prinzipiell nicht vor einer bestimmten Angriffsart schützt und man auch keine Zahlen nennen kann wann sie vielleicht doch mal schützt, ist das praktisch kein Schutz. Wenn man wenigstens sagen könnte 1 von 100 Tunnelingversuchen wird von der PFW geblockt, obwohl sie eigentlich prinzipiell nicht davor schützt, könnte man damit arbeiten, solche Zahlen fehlen nun mal leider.


Das mit dem "prinzipiell nicht davor schützt" sollte nochmal überdacht werden.
Wann schützt eine PFW prinzipiell nicht?
Genau dann wenn expliziet eine Verbindung zugelassen wird, und diese Verbindung genutzt wird, umd 'böse Daten' zu transportieren.
Ergo:
1) Wenn ich eine Regel erstelle die obriges Möglich macht.
2) Wenn der 'trusted' Partner ein Teil des Angrifft ist.
Beispiel: Wenn deine Bank deine Geheimnummer an alle weitergibt, spielt es keine Rolle ob du sorgfältig mit der Karte und der Nummer umgegangen bist.

Also - zurück zur deiner Argumentation:
Im ersten fall kann ich (mit dem richtigen Regelwerk) mehr Sicherheit erreichen, da die Verbindung vom Breakout nicht zu stande kommt.
Im Zweiten Fall hab ich keinen Schutz.

Wenn du jetzt beide Fälle unter "Tunneling" einordnetst, kannst du entweder qualitativ mitteln (dann tust du so als ob beide Fälle gleich oft Vorkommen) und erhälst 50 von 100 Fällen bei den die Firewall hilft (und das reproduzierbar), oder du gewichtest nach Häufigkeit.
Im Fall der Gewichtung nach Häufigkeit hättest du das ganze Spektrum (von 0% bis 100%) aber für jeden Nutzer würdest du eine andere Prozentzahl erhalten.
Der Arme Tropf der sich nur mit 'Verrätern' unterhält, und der Andere der sich nur mit 'sauberen' Gegenstellen unterhält, wären dann die extremwerte ( 0% bzw 100%).


Also kann man auch nicht pauschal sagen das eine PFW da den Schutz erhöht, wie es von Dir behauptet wird. Klar, 100%igen Schutz wird es nie geben, aber wenn durch die PFW der Schutz eben auch nicht erhöht wird und man mit da seht wie ohne, werden die Dinger doch irgendwie obsolet, meinst Du nicht auch?


Nicht zu 100% - aber das sagte ich ja bereits. Was den Letzten Teil deines Post betrifft - stehst du entweder im Widerspruch mit den ersten Sätzen, oder du meinst was anderes.

Bei letzterem bitte ich um eine Präzisierung.

MfG

BUGFIX

[_kleinerMann_]

Wenn du zu einem Ziel den Traffik erlaubt hast, und dein Browser betrügt dich und sendet innerhalb der Verbindung Daten, die er nicht senden soll, bist du schon in die Kategorie der "alles Verloren" Fälle.
Denn wenn deine 'trustet' Programme gegen dich arbeiten, kannst du nicht tun außer jegliche LKommunikation unterbinden.Mit anderen Worten eine PFW schützt nicht vor Tunneling, aber man kann etwas dagegen tun, in dem man jegliche Kommuniktaion dorthin unterbindet - was den klitze kleinen Nebeneffekt hat, dass auch "gute" Kommunikation dorthin nicht mehr gestattet ist.

Also gut letztes Beispiel: Angenommen das 3Dcenter, würde auf normale http Anfragen auf ihrer Website ganz normal reagieren, nehmen wir weiter an, ein böser Admin, hätte den Webserver der die domain vom 3dcenter verwaltet so eingerichtet, dass es auf über das http getunnelte FTP-Anfragen reagieren würde, dass bedeutet man könnte per ftp böse Daten an das 3dcenter schicken die aber aussehen, als würden sie normale http Anfragen darstellen. (Ist natürlich alles frei erfunden, die 3DCenter Crew würde soetwas nie machen ;))
Nun kannst Du zwar jegliche Kommuniktaion zum 3dcenter blocken, aber du könntest auch nicht mehr die normale Site vom 3dcenter aufrufen.

Was ich damit sagen will ist, dass Du zwar die komplette Kommunikation zu irgend einem Host unterbinden kannst, wodurch logisch nicht mehr getunnelt werden kann da die komplette Kommunikation lahmgelegt ist, aber die Unterscheidung, ob Dein Browser jetzt nen böses getunneltes Packet sendet oder eben eine normale Anfrage sendet, kann Deine PFW nicht leisten.
Somit schützt Deine PFW einfach prinzipiell nicht vor Tunneling. Irgendwie fehlt mir da das Argument, alles abschalten ist irgendwie daneben. Ich kann auch den Stecker ziehen, dann kann auch nicht mehr getunnelt werden. Es geht eben nicht darum einfach alles zu verbieten, wodurch logisch auch nicht mehr getunnelt werden kann, sondern um eine differenzierte Regelung, die eben nur die bösen Packte blockt.
Bei Dir ist es so, dass entweder alle Packete (sowohl böse als auch gute) zu einem Host geblockt werden, dass hat aber nichts mit 'Unterbinden von Tunneling' zu tun. Um Tunneling prinzipiell zu verhindern müsste Deine PFW in der Lage sein nur die bösen Packte, also die Packte bei denen getunnelt wird, zu filtern.

Wodurch sich der Rest Deines Posts erübrigt hat.

Wie gesagt ich will das hier nicht alles wieder aufflammen lassen, da ich finde das Sith_TirEilo das ausführlich genug dargelegt hat. Deshalb entweder Du akzeptierst dass eine PFW prinzipiell nicht davor schützt, oder eben nicht.
Bei letzerem, frage ich mich, warum nahezu jeder Sicherheitsexperte (auch die die PFWs befürworten) sagt, dass vor Tunneling prinzipiell nichts schützt.
Ich werde dazu nun auch nichts weiter sagen, da ich das Gefühl habe, bei Dir gegen eine Wand zu reden und ich ehrlich gesagt nicht die Zeit dazu habe hier Seitenlange Posts zu verfassen um Deine Argumente, die irgendwie 'am Thema vorbei' sind, zu entkräften.


Viele Grüsse,

Der kleine Mann

[---]

.

[BUGFIX]

Mit anderen Worten eine PFW schützt nicht vor Tunneling, aber man kann etwas dagegen tun, in dem man jegliche Kommuniktaion dorthin unterbindet - was den klitze kleinen Nebeneffekt hat, dass auch "gute" Kommunikation dorthin nicht mehr gestattet ist.


Wie bereits beim letzten Post von mir beschrieben:
[Auf dein Beispiel bezogen]
Wenn du unbedingt was von 3DCenter haben willst, und die Kommunikation dahin erlaubst, wird die PFW nicht gegen deine Anweisung handeln.
Auch bräuchte man für dein Beispiel einen Client, der die FTP-Daten in den http-traffic verpackt.

Auf den Rest deine Postings werde ich nicht eingehen, da du die getroffene Unterscheidung zwischen Tunneling in einer Verbindung und Tunneling mit neuen Verbindungen bewusst zu ignorieren scheinst.

MfG

BUGFIX

[_kleinerMann_]

Wenn du unbedingt was von 3DCenter haben willst, und die Kommunikation dahin erlaubst, wird die PFW nicht gegen deine Anweisung handeln. Kann also auch kein Tunneling dorthin verhindern...

Auch bräuchte man für dein Beispiel einen Client, der die FTP-Daten in den http-traffic verpackt.Wie zum Beispiel breakout, oder beliebiges anderes Schadprogramm?

Auf den Rest deine Postings werde ich nicht eingehen, da du die getroffene Unterscheidung zwischen Tunneling in einer Verbindung und Tunneling mit neuen Verbindungen bewusst zu ignorieren scheinst.Richtig, da es keine Rolle spielt.

Wenn Dein Browser eine komplett neue Verbindung zu einem beliebigen Host aufbaut (wobei der Host bei dir dann trusted wäre, andernfalls könnte keine Verbindung hergestellt werden), siehst Du zwar das eine neue Verbindung aufgebaut wird, die PFW kann da aber nur pauschal wieder sagen, jawohl der trusted Browser darf eigene neue Verbindungen aufbauen oder nein, er darf es nicht. Die PFW kann nicht sagen, ja jetzt darf der Browser mal eine Verbindung aufbauen weil da nicht getunnelt wird und bei der nächsten dann nein, weil dort getunnelt wird darf er das diesmal nicht.
Diese Entscheidung kann eben kein Programm treffen, weil man eben nicht unterscheiden kann ob Daten 'gut' oder 'böse' sind.
Wieder fehlt die Unterscheidung, ob die Verbindung die da aufgebaut werden soll zum tunneln missbraucht wird, oder ob es eine 'normale' Verbindung ist.
Selbe Frage wie oben, woher weiss nun Deine PFW ob die Packete die dort ausgetauscht werden auch vertrauenswürdig sind? Woher weiss Deine PFW denn nun ob in diesen Packeten was getunnelt wird? Woher weiss denn Deine PFW, ob die ersten 1.000 Packte normal sind und das 1.001 nicht doch ein getunneltes Packet ist?

Es bleibt dabei, Tunneling kann man prinzipiell nicht entdecken - da sind sich Experten einig - wie kommst Du nur darauf das Deine PFW dazu in der Lage wäre?

Ich versuche es nochmal anders: Wir sind uns doch einig, dass nur getunnelt werden kann wenn eine Verbindung (warum auch immer) zu Stande gekommen ist, richtig? Wie willst Du denn bitte überprüfen, ob Deine PFW Tunneling verhindert, wenn Du nie eine Verbindung zulässt? Normalerweise müsste doch die PFW dafür sorgen, das keine Verbindung zu Stande kommt, nachdem sie das erste Packet untersucht hat und dabei festgestellt hat, dass bei diesem Packet getunnelt wird. Das tut sie jedoch nicht.

Ich meine, wenn ich meine Fenster wasserdicht abdichten will, dann teste ich doch auch mit Wasser ob die wirklich dicht sind und sage nicht: "Nein ich lasse einfach kein Wasser an die Fenster kommen, dann kann auch nichts undicht werden." Klar wenn nie Wasser an die Scheiben kommt, können die Fenster auch nicht undicht werden, das heisst aber noch lange nicht das die Fenster wasserdicht sind, einfach weil die halt nie mit Wasser in Berührung kommen.

Aber gut, was soll man da noch sagen, Du lässt Dich ja doch nicht überzeugen (bzw. willst Dich nicht überzeugen lassen), völlig gleich wie stichhaltig die Argumente sind.
Ja ich weiss du wirst die Beispiele wieder so verdrehen und umschreiben das es irgendwie zu deinen Argumenten passt... bitte schön... Ändert aber immer noch nichts daran, dass PFW kein Tunneling entdecken können, völlig gleich wie krampfhaft Du versuchst das zu ignorieren und zu leugnen

Deine Argumnetationsweise kommt mir vor wie:

Ich: 1 + 1 = 2 und zwar nur 2!
Du: Nein, denn 1 + 1 - 2 = 0


Deine Argumente mögen richtig sein, (ja wenn ich den Stecker ziehe kann ich Tunneling verhindern), haben jedoch mit dem Thema (kann eine PFW prinzipiell Tunneling verhindern, bzw. überhaupt entdecken?) herzlich wenig zu tun.

Viele Grüsse,

Der kleine Mann

[BUGFIX]

Auch bräuchte man für dein Beispiel einen Client, der die FTP-Daten in den http-traffic verpackt.

Wie zum Beispiel breakout, oder beliebiges anderes Schadprogramm?


Nope - Breakout (oder ein anderes Schadprogramm) wird immer eine neue Verbindung aufbauen.

Tunneling in dem Sinne wie du es benutzt setzt aber etwas anderes Vorraus:
a) Einen Client den ich brauche um Sinnvolle daten zu übertrage (also der trusted ist), aber der gleichzeitig auch in der von mir gewünschten Verbindung daten überträgt die nicht übertragen werden sollen.

b) Eine Gegenstelle die mir die gewünschten daten liefert und gleichzeitig den 'bösen Datenstrom' abgreift.

Breakout gehört definitiv nicht in diese Kategorie.
Wer es mir nicht glaubt, soll es Ausprobieren. Alle in diesem Thread genannten Breakout-Beispiele (ob nun für Mozilla, oder IE) sind von dem Typ, dass sie eine neue Verbindung aufbauen.
Diese neue Verbindung kann man abgreifen.

Insofern - genug der Worte, denn das kann jeder selbst nachvollziehen.

MfG

BUGFIX

[_kleinerMann_]

Tunneling in dem Sinne wie du es benutzt setzt aber etwas anderes Es gibt kein tunneling in "meinem" Sinne, es gibt nur Tunneling allgemein. Tunneling ist Tunneling, es gibt kein Tunneling von mir, oder ein Tunneling von Dir.

a) Einen Client den ich brauche um Sinnvolle daten zu übertrage (also der trusted ist), aber der gleichzeitig auch in der von mir gewünschten Verbindung daten überträgt die nicht übertragen werden sollen.Nein ist nicht nötig. Na, wer weiss warum?

b) Eine Gegenstelle die mir die gewünschten daten liefert und gleichzeitig den 'bösen Datenstrom' abgreift.Sonst würde Tunneling wohl nicht funktionieren, wenn keine Gegenstelle da ist. Ich denke man kann davon ausgehen, dass auch eine Gegenstelle darauf wartet, dass die Schadsoftware ihr die geheimen Kontodaten des Users übermittelt. Was willst Du damit bitte sagen?
Ist genauso sinnvoll wie: "Tunneling geht nicht, weil keine Verbindung hergestellt werden kann".
Surfen geht auch nicht wenn keine Server da sind die Websiten anbieten...

Nope - Breakout (oder ein anderes Schadprogramm) wird immer eine neue Verbindung aufbauen.

[...]

Breakout gehört definitiv nicht in diese Kategorie.
Wer es mir nicht glaubt, soll es Ausprobieren. Alle in diesem Thread genannten Breakout-Beispiele (ob nun für Mozilla, oder IE) sind von dem Typ, dass sie eine neue Verbindung aufbauen. Diese neue Verbindung kann man abgreifen.Was willst Du mir damit sagen? Ja klar sehe ich das da eine Verbindung, entweder vom Schadprogramm selbst, oder vom missbrauchten trusted Wirt erstellt wird. Weder Sith_TirEilo, noch Ulukay, noch ich habe jemals das Gegenteil behauptet (korrigiert mich wenn ich daneben liege), jedoch ist das nebensächlich. Es geht nicht darum zu erkennen ob eine Verbindung hergstellt wird oder nicht, sondern darum, ob bei dieser Verbindung getunnelt wird. Woran sieht Deine PFW jetzt bitte ob diese Verbindung (völlig gleich wer sie herrgestellt hat) nun getunnelt wird oder nicht? Klar sie kann wieder sagen: "Nö is nicht" und die Verbindung trennen bzw. deren Aufbau unterbinden, aber sie kann nicht sagen: "Nö is' nicht weil getunnelt wird".


Dein einziges Argument an das Du Dich noch klammerst, ist scheinbar dass breakout für Dich ein schlechtes Beispiel ist... gut sieh' es wie Du willst, da Du sonst nicht mehr bringst (bringen kannst), hast Du wohl eingesehen, dass man Tunneling nicht unterbinden kann (auch nicht mit einer PFW). In diesem Fall 'gut gemacht' es hat lange gedauert, aber was lange wärt wird endlich gut.


Viele Grüße,

Der kleine Mann

[Sith_TirEilo]

Hi,

@kleiner Mann
Endlich! Wenigstens einer hat mich verstanden. Ich dachte schon ich rede gegen eine Wand.

@BUGFIX
Wenn Du jetzt immer noch meinst das PFWs gegen Tunneling (die einzige Bastion bei der PFW Mehrwert darstellen würden - wie wir uns ja einig waren) schützen - dann ist Dir leider wirklich nicht mehr zu helfen ;)

Bis dann...

Sith

[BUGFIX]

[...]
Was willst Du mir damit sagen? Ja klar sehe ich das da eine Verbindung, entweder vom Schadprogramm selbst, oder vom missbrauchten trusted Wirt erstellt wird. Weder Sith_TirEilo, noch Ulukay, noch ich habe jemals das Gegenteil behauptet (korrigiert mich wenn ich daneben liege), jedoch ist das nebensächlich. Es geht nicht darum zu erkennen ob eine Verbindung hergstellt wird oder nicht, sondern darum, ob bei dieser Verbindung getunnelt wird. Woran sieht Deine PFW jetzt bitte ob diese Verbindung (völlig gleich wer sie herrgestellt hat) nun getunnelt wird oder nicht? Klar sie kann wieder sagen: "Nö is nicht" und die Verbindung trennen bzw. deren Aufbau unterbinden, aber sie kann nicht sagen: "Nö is' nicht weil getunnelt wird".
[...]




Dass Breakout mit der Definition von dem Begriff "Tunneling" wie du ihn eingesetzt hast nix zu tun hat.
Sollte es dir entfallen Sein, dann Lese doch bitte den Thread nochmal durch.
Ulukay und Sith_TirEilo haben Breakout als das Beispiel für Tunneling ind Feld geführt, wärend ich zu den Beispielen von Breakout gesagt habe, dass sie nicht funktionieren.
Gut - da wir jetzt einmal so weit sind und Breakout begraben können:
Wie ich schon sagte, bei dem Ausnutzen einer Verbindung bei der Beides (also gewollter und ungewollter Inhalt) ausgetauscht wird, gibt es keinen Schutz durch eine PFW (steht aber auch in der Tabelle von mir.

Bleibt dir als gegenargument jetzt also noch dieser Fall des Tunnelns übrig (bei dem weder "mit PFW" nocht "ohne PFW" helfen).
Gut verfeinern wir also die Tabelle, und fügen eine Weiternen Punkt hinzu:

X = keine Abhilfe
Paketinhalt-Manupulation:
mit PFW: X ohne PFW: X

Wieder keine verminderte Sicherheit durch PFW Software an dieser Stelle.

MfG

BUGFIX

[Sith_TirEilo]

Hi,

Sollte es dir entfallen Sein, dann Lese doch bitte den Thread nochmal durch.
Ulukay und Sith_TirEilo haben Breakout als das Beispiel für Tunneling ind Feld geführt, wärend ich zu den Beispielen von Breakout gesagt habe, dass sie nicht funktionieren. Was nach wie vor zwar falsch ist da deine PFW breakout ziemlich genau gar nicht geblockt hat, aber gut lassen wir das. Bei breakout sollte nur gezeigt werden das die PFW nicht unterscheiden kann ob ein gutes Programm nun böse Daten sendet (weil eben getunnelt wird) oder nicht. Das da kein Protokoll über ein anderes getunnelt wird ist klar, es soll lediglich die Idee dahinter demonstriert werden und das es funktioniert. Aber gut Du bist da wohl zu kleinkarriert für.

Also wieder Deine Tabelle:

1) Software (API-konform) 'telefoniert' nach hause (siehe breakout)
mit Firewall: X | ohne: X

2) Software versucht zu tunneln
mit Firewall: X | ohne: X

3) DoS Attacken
mit Firewall: X | ohne: X

4) Implementierungsfehler im OS (Dienste usw.)
mit Firewall: X | ohne: X

5) Implementierungsfehler PFW
mit Firewall: X | ohne: Y

6) Prinzipelle Schwächen der Systemumgebung
mit Firewall: X | ohne: X

7) Paketinhalt-Manipulation:
mit PFW: X ohne PFW: X

Nach dem Du ja nun scheinbar eingesehen hast, dass vor Tunneling PFWs ganz bis gar nicht schützen (wobei ich mich schon gefragt habe ob Du von Anfang an überhaupt verstanden hast was Tunneling ist, da Du immer wieder von "seinem" "ihrem" "sonstigen" Tunneling sprichst, es wurde ja schon klar gestellt das es nur Tunneling allg. gibt und nicht zig verschiedene Definitionen - aber das nur am Rande), erhöhen sie die Sicherheit nicht. Will heissen man steht erstmal sowohl mit als auch ohne PFW gleich da. Soweit so gut - da waren wir uns (abgesehen vom Tunneling) einig.
Nun ist es so, auch das wurde schon öfters erwähnt, das _jedes_ Programm die Sicherheitslage beeinträchtigt. Eine PFW bringt nun mal keinerlei Nutzen (Sicherheitslage wird ja nicht erhöht - welchen Sinn hat sie dann noch?) und beeinträchtigt eben die Sicherheitslage allein durch dessen Existenz, sieht man ja in Deiner Tabelle (vom Gewurschtel im IP-Stack mal ganz zu schweigen).

Um es kurz zu machen:
Bei Angriffen von aussen (gleich welcher Art) ist eine PFW nicht nötig, weil ein besseres Ergebnis druch vernünftige Konfiguration zu erreichen ist.
Bei Angriffen von innen (wieder gleich welcher Art) schütz eine PFW ziemlich genau gar nicht - wenn Schadsoftweare auf dem Rechner gelangt ist, hat man verloren, ob mit oder ohne.
Es wird nirgendwo die Sicherheit erhöht, also wird sie allein druch die Existensz eine weiteren Programmes das (meist mit Systemrechten) im Hintergrund läuft beeinträchtigt.
Genau da hast Du dann Deine verminderte Sicherheit. Was gibt es daran nicht zu verstehen?

Gruß,

Sith

[BUGFIX]

Hi,

[...]
Um es kurz zu machen:
Bei Angriffen von aussen (gleich welcher Art) ist eine PFW nicht nötig, weil ein besseres Ergebnis druch vernünftige Konfiguration zu erreichen ist.
Bei Angriffen von innen (wieder gleich welcher Art) schütz eine PFW ziemlich genau gar nicht - wenn Schadsoftweare auf dem Rechner gelangt ist, hat man verloren, ob mit oder ohne.
Es wird nirgendwo die Sicherheit erhöht, also wird sie allein druch die Existensz eine weiteren Programmes das (meist mit Systemrechten) im Hintergrund läuft beeinträchtigt.
Genau da hast Du dann Deine verminderte Sicherheit. Was gibt es daran nicht zu verstehen?

Sith

Wenn du deine Kiste wirklich ganz aus dem Netz nehmen kannst, könntest du mit deinem Scenario recht haben, wenn da nicht der kleine Schönheitsfehler wäre, dass wenn du Wirklich jeden Traffik vermeiden kannst, ein möglicher Implementierungsfehler in der PFW-Software auch nixmehr ändert.

Du sagst also man soll einfach alles Abschalten und gut ist.
Wie sieht das alsoi in der Praxis aus (z.B.: UNI-Netzwerk) wenn du auf SMB, FTP, SSH nicht verzichten kannst?
Die PFW bietet dir trotz aktivierter (also nutzbarer) Dienste eine Regulationmöglichkeit an, die du mit deinem "alles abschalten" nicht erreichen kannst.
Noch zu deiner Tabelle:
Warum ist der Fall: "Blaster-Angriff von außen - Firewall schützt - ohne PFW kein Schutz" nicht drin?
Vergessen - oder passt er dir nicht ins Konzept?
Dass PFW-Software tatsächlich Schutz bietet ist Tatsache (was _kleinerMann_ nicht Bestreitet - im gegensatz zu dir, Sith_TirEilo)

Also ich bleibe dabei:
PFW ist in solcheiner (sehr Verbreiteten) Umgebung durchaus Sinnvoll. Deine Forrderung "alles Abschalten" klingt da schon sehr Weltfremd.

MfG

BUGFIX

[Sesshoumaru]

Du sagst also man soll einfach alles Abschalten und gut ist.
Wie sieht das alsoi in der Praxis aus (z.B.: UNI-Netzwerk) wenn du auf SMB, FTP, SSH nicht verzichten kannst?
Die PFW bietet dir trotz aktivierter (also nutzbarer) Dienste eine Regulationmöglichkeit an, die du mit deinem "alles abschalten" nicht erreichen kannst.

Ob man nun die Dienste abschaltet, wenn sie nicht gebraucht werden, oder sie zu der Zeit per Firewall abblockt, macht doch keinen Unterschied. Wenn man sie benötigt, schaltet man sie wieder ein, bzw. die Firewall aus, dann kann man sie nutzen und ist angreifbar, das lässt sich nicht verhindern.


Noch zu deiner Tabelle:
Warum ist der Fall: "Blaster-Angriff von außen - Firewall schützt - ohne PFW kein Schutz" nicht drin?


Vielleicht, weils nicht stimmt? Port 135 lässt sich einfach per Windows Hausmitteln dicht machen, dann kommt Blaster nicht rein. Der Dienst, den man dazu abschaltet, wird von so gut wie niemandem genutzt, das ist normalerweise kein Verlust. Und wenn man ihn nutzt, muss er halt offen und aktiv sein, da darf die Firewall also auch nichts abblocken.

[---]

.

[Der Betreff]

Hat denn niemand ne Idee wegen der Konfiguration von IPSEC ? :(

http://www.hernanracciatti.com.ar/ipfront/

Nächster Versuch.

[_kleinerMann_]

Du sagst also man soll einfach alles Abschalten und gut ist.Da hat Sith_TirEilo meiner Meinung nach auch völlig Recht.

Wie sieht das also in der Praxis aus (z.B.: UNI-Netzwerk) wenn du auf SMB, FTP, SSH nicht verzichten kannst?Was soll dann sein? Dann schalte ich diesen Dienst eben einfach ein. Wenn er erreichabr sein soll, was willst Du da blocken? Übringens kann man all diese Dienste auch vernünftig konfigurieren, dass auch wirklich nur gewollte Personen draufzugreifen können.
(Nebenbei, wer will denn SMB benutzen? SMB ist böse[tm])

Die PFW bietet dir trotz aktivierter (also nutzbarer) Dienste eine Regulationmöglichkeit an, die du mit deinem "alles abschalten" nicht erreichen kannst.Nein, - denn wer hätte das gedacht - ich kann meine Serverdienste sogar konfigurieren und zwar so, dass auch wirklich nur bestimmte Hosts (bzw. Benutzer) darauf zugreifen können. (Ist eigenlich auch nicht schwerer als eine PFW sinnvoll zu konfigurieren).
Wieso läuft wohl keine PFW auf einem Web-/Mail-/Sonstwas-Server? Nach Deinem (Irr)Glauben könnte man damit Server ja richtig gut absichern, so dass auch nur die gewünschten Personen (z.B. registrierte Kunden) darauf zu greifen können? Wieso ist in der Praxis nicht ein Server mit einer PFW ausgestattet (nein auch die, die auf Windows laufen, haben keine)?
Wer einen Serverdienst wie FTP oder SSH ins Internet anbieten will, sollte schon wissen was er da tut, entsprechend ist der auch in der Lage so etwas ordentlich zu konfigurieren (auch wenn die Realität manchmal anders aussieht - da hat dann aber auch keine PFW mehr geholfen). Wollen wir mal alle hoffen, dass Du nicht so bald Serveradmin wirst.

Warum ist der Fall: "Blaster-Angriff von außen - Firewall schützt - ohne PFW kein Schutz" nicht drin?
Vergessen - oder passt er dir nicht ins Konzept?Wieso sollte das bitte in Deine Tabelle (Du hast die ja erstellt - so gesehen ist es Deine Schuld das Du da diesen Fall nicht aufgenommen hast)?
Die Tabelle wäre wohl ewig lang wenn für jeden Fehler im OS extra ein Eintrag hinzugefügt werden müsste? Übrigens, konnte man auch diesen Dienst so einstellen das er nicht von aussen erreichbar ist.
Es wäre übrigens genauso sinnvoll dort einzutragen, dass die Norten PFW vor 3 Jahren eine Fehler hatte der es ermöglichte beliebigen Code auszuführen.

Dass PFW-Software tatsächlich Schutz bietet ist Tatsache (was _kleinerMann_ nicht Bestreitet - im gegensatz zu dir, Sith_TirEilo)So habe ich das nicht gemeint, ich meinte das sie prinzipiell, bei Angriffen von aussen (und zwar nur von aussen) schützen könnte (konjunktiv!). Die meisten sind aber recht erbärmlich implemtiert (siehe das Problem mit der Manipulation vom Stack, was Sith_TirEilo auch schon erwähnte). Eine wesentlich sicherer und effektiverer Schutz ist nun mal, wenn man nicht benötigte Dienste abschaltet (denn dann können definitiv keine Fehler mehr ausgenutzt werden) und die Dienste die man unbedingt ins Internet anbieten muss, vernünftig konfiguriert. Übrigens ist für mich ein könnte noch kein Tatsache. Ich könnte theoretisch auch extrem intelligent sein - eine Tatsache ist das aber noch lange nicht.

PFW ist in solch einer (sehr Verbreiteten) Umgebung durchaus Sinnvoll. Deine Forrderung "alles Abschalten" klingt da schon sehr Weltfremd.Womit Du (immer noch) falsch liegst.
Wo wir gerade bei "realistischen" Praxisszenarien sind, welcher Homeuser hat denn einen ssh-Server bei sich laufen? Welcher Homeuser bietet denn bitte SMB ins Internet an? Da fragt man sich wer hier weltfremd ist, Du oder Sith_TirEilo?
Ich kenne nicht einen Homeuser der nen ssh-Server oder smb ins Netz anbietet, auch ein FTP Server stellt ehr eine absolute Ausnahme dar. So weitverbreitet kann Dein Modell scheinbar nicht sein. Die meisten Homeuser die ich kenne wollen nicht einen Dienst ins Internet anbieten (ob sie das nun wissen sei mal dahingestellt). Ich denke 'solche' Homeuser sind deutlich verbreiteter als Deine FTP, SSH, SMB-Server anbietenden User.


Irgendwie windest Du Dich wie ein Ahl, erst hast Du gesagt das von aussen zwischen PFW und 'vernünftig Konfigurieren' (womit auch Dienste gemeint sind) bestenfalls Gleichstand herrscht, dafür schützt Dich die PFW vor Tunneling.
Jetzt schützt sie nicht mehr vor Tunneling bietet aber einen Mehrwert bei Angriffen von aussen gegenüber 'vernünftig Konfigurieren'.
Du solltest Dich bei Deinen Argumenten mal festlegen und diese dann (bis zum bittern Ende) vertreten, oder eben revidieren falls Du eingesehen hast warum sie falsch sind. Mal so dann wieder so zu argumentieren ist sehr ungünstig, einfach weil es unglaubwürdig wirkt.

Abschliessendes, ich finde Sith_TirEilo hat das schon richtig empfohlen (wenn auch etwas übertrieben aggressiv), genauso wie Ulukay das schon seit längerem predigt.
Nicht benötige Dienste abschalten, benötigte Dienste (was meiner Meinung nach bei Homeuser so gut wie nie der Fall ist) vernünftig konfigurieren und sonst eben alles was im "How-To wie man sein Windows sicherer machen kann - Vol. 2" steht beherzigen und schon sollte der Rechner sicher sein.

Aber bleibe nur bei Deiner Meinung, man hat ja auch Jahrhunderte lang gewusst das die Erde ein Scheibe ist. Die Wahrheit bleibt eben immer noch die Wahrheit, selbst wenn keiner daran glaubt oder etwas davon wissen will.

Viele Grüsse,

Der kleine Mann

P.S. Hat denn niemand ne Idee wegen der Konfiguration von IPSEC ?Gehört irgendwie nicht in diesen Thread, hier geht es doch um PFW, oder habe ich was verpasst. Mach doch einen eigenen Thread auf - da kann man Dir sicherlich auch besser helfen.

[BUGFIX]

Also ein endgültig letztes Mal:

1) Mit einer PFW kann ich Dienste regulieren.
Ich brauche die Dienste nicht abzuschalten (und dadurch Funktionaltiät verlieren), ich setzt fest wer darf und wer nicht - und dass, so zeigt die Praxis, funktioniert zuverlässig.
[Wer es live sehen will, der komme bitte nach Konstanz]

2) Kann ich Anwendungen beim Verbindungsaufbau so reglementieren, dass zum Beispiel ungleibetes Autoupdate von Anwendungen (die täglich benutzt werden) verhindert werden kann.

3) Ist eine installierte PFW nicht gleichzusetzten mit einem Aktiven Server.
Sie macht also keinen Port auf, den man von außen beliebeig bearbeiten kann.
[Das nur zu info - nicht dass hier noch ein Leser diese Threads auf die Idee gebracht wird]

4)
Brauchst du mir nicht Vorzuwerfen, ich würde wie mich wie ein Aal umherwinden, nur weil ich Stück für Stück eure ganzen Beispiele aus der Praxis (also Code-Beispiele) wiederlege, und ihr euch dann auf einige Fälle versteift, bei dem eine PFW keine Schutz bietet.

Zum Thema Homeuser:
Er wird vielleicht nicht gerade nen SSH anbieten - allerdings sind Serverdienste wie WWW und FTP verbreiteter als du meinst.

Das einzige was ihr wirklich beweisen konntet, ist das alle eure Code-Beispiele gegen PFWs nicht funktionieren.

Also dann - einen schönenn Abend noch, und auf dass du immer rechtzeitig 'Netstat -an" aufrufst, um offene Ports zu finden. :)

MfG

BUGFIX

[(del676)]

Also ein endgültig letztes Mal:

1) Mit einer PFW kann ich Dienste regulieren.
Ich brauche die Dienste nicht abzuschalten (und dadurch Funktionaltiät verlieren), ich setzt fest wer darf und wer nicht - und dass, so zeigt die Praxis, funktioniert zuverlässig.
[Wer es live sehen will, der komme bitte nach Konstanz]

das kann man bei den diensten selbst konfigurieren, dafür brauche ich kein buntes stück zusätzliche software
[wer es live sehen will kommt nach kärnten]


2) Kann ich Anwendungen beim Verbindungsaufbau so reglementieren, dass zum Beispiel ungleibetes Autoupdate von Anwendungen (die täglich benutzt werden) verhindert werden kann.

ich kann die autoupdates bei jedem programm abdrehen das ich benutze, dafür brauche ich kein buntes stück zusätzliche software
[wer es live sehen will kommt nach kärnten]


3) Ist eine installierte PFW nicht gleichzusetzten mit einem Aktiven Server.
Sie macht also keinen Port auf, den man von außen beliebeig bearbeiten kann.
[Das nur zu info - nicht dass hier noch ein Leser diese Threads auf die Idee gebracht wird]

nö, sie sitzt nämlich hinter ALLEN ports, egal ob sie offen oder geschlossen sind, weil sich das bunte stück software in den tcpip stack einnistet


4)
Brauchst du mir nicht Vorzuwerfen, ich würde wie mich wie ein Aal umherwinden, nur weil ich Stück für Stück eure ganzen Beispiele aus der Praxis (also Code-Beispiele) wiederlege, und ihr euch dann auf einige Fälle versteift, bei dem eine PFW keine Schutz bietet.

du windest dich wie ein aal. und eine willigkeit von admins zu lernen ist gleich 0.


Also dann - einen schönenn Abend noch, und auf dass du immer rechtzeitig 'Netstat -an" aufrufst, um offene Ports zu finden. :)


du wirst es kaum glauben, aber das muss ich nicht, denn ich WEISS im gegensatz zu dir was ich auf meinem pc habe. bei mir telefonieren nich 100 trojaner raus die du dir bei irgendwelchen illegalen cracks zugezogen hast - DU willst ja dauernd "ports kontrollieren" - ich nicht, ich brauche das nicht, ich BENUTZE meinen pc nämlich anstatt 24/7 vor einer bunten software zu sitzen und paranoid jedes paket 10x zu kontrollieren ... :rolleyes:

[Sith_TirEilo]

Hi,

1) Mit einer PFW kann ich Dienste regulieren.
Ich brauche die Dienste nicht abzuschalten (und dadurch Funktionaltiät verlieren), ich setzt fest wer darf und wer nicht - und dass, so zeigt die Praxis, funktioniert zuverlässig.Was hat denn ein Beschränkung auf bestimmte IPs mit sinnvoll regulieren zu tun?
Damit das überhaupt sinnvoll funktionieren würde, müsste Dir jeder der auf Deine Serverdienste zugreifen will persönlich die IP Adresse mitteilen. Du müsstest die dann in Deiner PFW freischalten, erst dann könnte der Benutzer auf Deine Dienste zugreifen. Nach dem Datenaustausch müsstest Du die IP sofort wieder verbieten, da die meisten User nun mal ihre IPs dynamisch zugwiesen bekommen und Du nicht weisst wer die IP von dem User eben, als nächstes bekommt.
Das halte ich doch sehr praxisuntauglich. Viel flexibler ist es, bei Deinen Diensten die Du anbieten willst, ganz normale Nutzerkennungen mit Passwort zu verteilen - ist auch wesenlich sicherer, weil so wirklich nur die User denen Du erlaubt hast zu kommunizieren, auf Deine Dienste zugreifen können.

2) Kann ich Anwendungen beim Verbindungsaufbau so reglementieren, dass zum Beispiel ungleibetes Autoupdate von Anwendungen (die täglich benutzt werden) verhindert werden kann.Aha, Du bist also einer von denen die die 'automatischen Updates von Windows', von ihrer PFW blocken lassen?
Erstens, lässt sicht sowas meist direkt in der Software einstellen.
Zweitens, wenn Software bei mir trusted ist, dann darf die auch Verbindungen herstellen (diese Verbindungen habe ja alle einen Sinn), sonst wäre sie nicht trustet. Gerade solche Auto-Update Funktionen finde ich äußerst praktisch, nimmt mir zumindest viel Arbeit ab, da die Software immer auf dem neusten Stand ist und ich nicht von Hand nach Patches suchen muss.
Drittens ist es auch nicht direkt der Sinn einer Sicherheitssoftware trusted Software am 'arbeiten' zu hindern. Also wenn das Dein einziger Grund ist warum Du eine PFW braucht - na dann gute Nacht....

3) Ist eine installierte PFW nicht gleichzusetzten mit einem Aktiven Server.Ich kann ich ja irren, aber Du warst es doch der gemeint hat, dass PFW Dienste sinnvoll regulieren können (ist denn ein SSH-Service kein Serverdienst?) Niemand anders hat PFW mit Servern in Verbindungen gerbacht. Es ist eben kein Unterschied ob ein FTP-Server bei einem Homeuser läuft oder auf einem dezidierten Server in einem Rechencenter. Der Dienst der angeboten wird ist der gleiche. Wenn Du also sagst, dass eine PFW da sinnvoll wie auch immer regulieren kann, dann muss das auch auf einem 'normalen' Server genauso funktionieren. Doch da frage ich mich, warum das in der Praxis nicht gemacht wird? Entweder weil alle Admins dumm sind und nicht so schlau wie Du, oder weil Du eben einfach falsch liegst.

4)
Brauchst du mir nicht Vorzuwerfen, ich würde wie mich wie ein Aal umherwinden, nur weil ich Stück für Stück eure ganzen Beispiele aus der Praxis (also Code-Beispiele) wiederlege, und ihr euch dann auf einige Fälle versteift, bei dem eine PFW keine Schutz bietet.Nun, viele Codebeispiele bei denen eine PFW einen Schutz bietet, der nicht mit vernünftiger Konfiguration erreicht werden könnte, hast Du auch nicht gerade gebracht. Moment ich zähle mal schnell nach:

...

Oh, ich sehe gerade Du hast nicht ein (also kein) Codebespiel gebracht. Wer nichts macht kann auch nichts falsch machen...


Er wird vielleicht nicht gerade nen SSH anbieten - allerdings sind Serverdienste wie WWW und FTP verbreiteter als du meinst.Ich kenne wirklich nur einen in meinem Bekanntenkreis der einen FTP-Server anbietet. Aber gut gegen Serverdienste ist ja nichts einzuwenden, solange die Leute wissen was sie tun. Wissen sie's nicht ist ehh alles verloren egal ob mit oder ohne PFW. Die die wissen wie man solche Serverdienste aufsetzt (zumindest der den ich kenne mit dem FTP-Server), benutzen für dessen Absicherung sicherlich keine PFW.

Das einzige was ihr wirklich beweisen konntet, ist das alle eure Code-Beispiele gegen PFWs nicht funktionieren.Hmm... breakout konnte bei Dir nach draussen telefonieren, bis Du den Stecker gezogen hast (also gesagt hast das ein Browser gar nicht senden darf, völlig gleich wohin und ob es der User war der senden wollte oder breakout).
Hmm.... komisch 'nicht funktionieren' sieht bei mir anders aus, aber gut. Hoffentlich bist Du kein Admin, da kann Deine Definition von 'nicht funktionieren' schnell nach hinten los gehen.

Also dann - einen schönenn Abend noch, und auf dass du immer rechtzeitig 'Netstat -an" aufrufst, um offene Ports zu finden.Nein bei mir weiss ich genau welche meiner (zahlreichen) Programme eine Internetverbindung benötigen (und die dürfen sie dann auch herstellen) und welche nicht - wäre dies anders würde ich ihnen nicht vertrauen.
Wenn bei Dir die PFW eben alles überwachen muss, ob nicht vielleicht doch ein paar (trusted) Programme heimlich eine Verbindung herstellen wollen, hätte ich an Deiner Stelle andere Sorgen.


Gruß,

Sith

[möp]

Warum ist der Fall: "Blaster-Angriff von außen - Firewall schützt - ohne PFW kein Schutz" nicht drin? weil es so einfach nicht stimmt?


ich hatte weder blaster, sasser noch sonstwas...und zwar ohne patch...und der patch wäre sogar ein völlig konfigurationsfreie sache gewesen...tja ham nur wenige gemacht

[WunderHerrlich]

Mal ein wenig OT: Reicht ein netstat -an -o und der Windows-Taskmanager mit aktivierter PID-Spalte um Verbindungen eindeutig zuordnen zu können?

[(del676)]

wieder ein herrliches beispiel dafür dass man mit einer PFW seinen PC unsicherer macht (und viel mehr Angriffsfläche bietet):
http://www.heise.de/security/news/meldung/57678

ohne PFW kein DNS-Poisoning.

[Hucke]

wieder ein herrliches beispiel dafür dass man mit einer PFW seinen PC unsicherer macht (und viel mehr Angriffsfläche bietet):
http://www.heise.de/security/news/meldung/57678

ohne PFW kein DNS-Poisoning.

Tja. Je komplexer der Krempel wird, desto anfälliger für Fehler wird er. Wieder ein Argument für Deine (und nicht nur Deine) Sichtweise der Dinge.

[Holundermann]

Was hat denn ein Beschränkung auf bestimmte IPs mit sinnvoll regulieren zu tun? Damit das überhaupt sinnvoll funktionieren würde, müsste Dir jeder der auf Deine Serverdienste zugreifen will persönlich die IP Adresse mitteilen. Du müsstest die dann in Deiner PFW freischalten, erst dann könnte der Benutzer auf Deine Dienste zugreifen. Nach dem Datenaustausch müsstest Du die IP sofort wieder verbieten, da die meisten User nun mal ihre IPs dynamisch zugwiesen bekommen und Du nicht weisst wer die IP von dem User eben, als nächstes bekommt. Das halte ich doch sehr praxisuntauglich. Viel flexibler ist es, bei Deinen Diensten die Du anbieten willst, ganz normale Nutzerkennungen mit Passwort zu verteilen - ist auch wesenlich sicherer, weil so wirklich nur die User denen Du erlaubt hast zu kommunizieren, auf Deine Dienste zugreifen können.

ein dhcp server wird im normalfall so konfiguriert das er den clients immer die selbe ip zuweist. interne ip adressen gebe ich personal firewalls prinzipiell bekannt.

Der Dienst der angeboten wird ist der gleiche. Wenn Du also sagst, dass eine PFW da sinnvoll wie auch immer regulieren kann, dann muss das auch auf einem 'normalen' Server genauso funktionieren. Doch da frage ich mich, warum das in der Praxis nicht gemacht wird? Entweder weil alle Admins dumm sind und nicht so schlau wie Du, oder weil Du eben einfach falsch liegst.

im professionellen bereich hängt ja meist auch eine professionelle hardware firewall vor dem netz das die dienste im internet anbietet. im idealfall in einer dmz. ich kenne jedoch trotzdem ein beispiel für eine personal firewall auf einem web und mailserver, in unserer firma wird das so gehandhabt weil der server in einer farm steht und wir nicht direkt zugriff auf die dortige firewall konfig haben.

zumindest einen portfilter sollte jeder in seinem netz haben. wenn nun ein rechner nicht über einen router ins internet geht sondern dieser direkt verbunden ist ist eine pfw pflicht, nicht zu unrecht hat ms eine firewall integriert im sp2 von win xp! wenn man dann noch genaue einstellungen treffen möchte, evtl. um unnötigen traffic zu vermeiden oder einfach selbst bestimmen will welches programm nach hause telefonieren darf (und nein, der windows explorer muss das in meiner config nicht...), ist eine pfw auf applikation level schon sinnvoll...

[BUGFIX]

....
ohne PFW kein DNS-Poisoning.

Eine schöne Falschaussage - lassen wir sie mal so stehen - als leuchtendes Beispiel für unprofessionelle Verallgemeinerungen.

Besser wäre:
Jedes Programm, dass DNS Namen zwischenspeichert, lässt sich durch modifizierte DNS-Server beeinflussen. Das solche DNS-Dienste in Firewalls vorkommen, ist eine Sache, aber auch Windows hat einen DNS-Caching Dienst.

Alternative zu diesen - nun ja - jedes Programm das einen DNS namen haben will (auch im Lokalen Netz) den Zugang zum DNS-Server des Vertrauens ermöglichen.

In dem Sinne:

Traue keinem DNS Namen den du nicht selbst im DNS-Server eingetragen hast



MfG

BUGFIX

[(del676)]

Eine schöne Falschaussage - lassen wir sie mal so stehen - als leuchtendes Beispiel für unprofessionelle Verallgemeinerungen.

Besser wäre:
Jedes Programm, dass DNS Namen zwischenspeichert, lässt sich durch modifizierte DNS-Server beeinflussen. Das solche DNS-Dienste in Firewalls vorkommen, ist eine Sache, aber auch Windows hat einen DNS-Caching Dienst.

dieser ist bei einem ordentlich konfigurierten System nicht aktiviert.


Alternative zu diesen - nun ja - jedes Programm das einen DNS namen haben will (auch im Lokalen Netz) den Zugang zum DNS-Server des Vertrauens ermöglichen.

In dem Sinne:

Traue keinem DNS Namen den du nicht selbst im DNS-Server eingetragen hast



MfG

BUGFIX

zeig mir eine Security Warnung für DNS-Poisoning für Windows XP SP2.

(insbesondere würde es mich wundern wie man den DNS Cache zumüllen kann wenn es gar keinen DNS Cache gibt)

soviel zu unprofessionell :rolleyes:

[BUGFIX]

dieser ist bei einem ordentlich konfigurierten System nicht aktiviert.
[...]
zeig mir eine Security Warnung für DNS-Poisoning für Windows XP SP2.




Wenn man den DNS-Cache abschaltet, muss das Programm selbst den DNS-Server fragen, das heißt, dass du also wesentlich mehr potentielle Schwachstellen zulässt (ein DNS-Cache - gegen 30 oder mehr einzelne Implementationen der DNS-Abfrage).
Wie das mit deiner "Weniger ist Mehr" Philosophie zusammenpasst ist mir persönlich nicht nachvollziehbar.

Zum Thema XP SP2:
ist egal ob SP2 oder nicht - auch egal ob Windows XP oder nicht - die Schwachstelle ist (Ausnahmsweise) mal nicht der Code des Caches selbst sondern die Tatsache das auf eine (nicht vertrauenswürdige) DNS-Antwort vertraut wird.

Ergo:
Lieber 3 Quellen fragen als eine.
Das heißt im Umkehrschluss aber auch , dass die Einwahldaten der meisten Provider schlichtweg überschrieben werden müssen, da viele Provider bei der Einwahl einen DNS-Cache-Server statt eines wirklichen DNS-Servers angeben.
Um das zu umgehen sollte man in der Netzwerkeigenschaften einen DNS-Server fest eintragen.

MfG

BUGFIX

PS: Weiß jemand, ob es Bemühungen gibt, das DNS-System als Ganzes zu überarbeiten - vielleicht im Rahmen des IPv4 -> IPv6 Wechsels?

[ZilD]

für home user sind pf sicherlich ausreichend.

du hast ein frisch aufgesetztes windows 2000/XP sys und verbindest dich mit dem internet.
bevor du überhaupt irgendwie ein update machen kannst bist du schon offen wie ein scheunentor.
oft genug erlebt.

"der computer wird in 30 sekunden neu gestartet"
*gg*

[King Rollo]

für home user sind pf sicherlich ausreichend.

du hast ein frisch aufgesetztes windows 2000/XP sys und verbindest dich mit dem internet.
bevor du überhaupt irgendwie ein update machen kannst bist du schon offen wie ein scheunentor.
oft genug erlebt.

"der computer wird in 30 sekunden neu gestartet"
*gg*

Deshalb sollte man ja auch VOR dem ersten Verbinden mit dem Internet alle Update aufspielen.

[sloth9]

Deshalb sollte man ja auch VOR dem ersten Verbinden mit dem Internet alle Update aufspielen.

Was ja nicht geht (Henne, Ei).

[King Rollo]

Was ja nicht geht (Henne, Ei).

Warum nicht? Microsoft biete seine Updates auf CD an bzw. kann man sich bei einem Freund die Sachen auf CD brennen.

[sloth9]

Warum nicht? Microsoft biete seine Updates auf CD an bzw. kann man sich bei einem Freund die Sachen auf CD brennen.

Der ja auch irgendwann mal Windows installiert hat, sich also bei nem anderen Freund die Sachen auf CD gebrannt hat; welcher auch mal ein frisches Windows hatte...

[Gast]

Der ja auch irgendwann mal Windows installiert hat, sich also bei nem anderen Freund die Sachen auf CD gebrannt hat; welcher auch mal ein frisches Windows hatte...
es gibt immernoch die möglichkeit die updates auf cd von ms zuschicken zu lassen KOSTENFREI

dann ist noch der punkt...man kann sien system konfigurieren.,..ich nehm dir jegliches win2k/xp system ungepatcht ans netz ohne das ich ovn würmern geplagt werden...dcomcnfg und ein häkchen entfernen reicht dafür.,..dass das nicht das optimum an sicherheit ist, mag sein...aber für den updateprozess reicht es allemal...

[Gast]

für home user sind pf sicherlich ausreichend.

du hast ein frisch aufgesetztes windows 2000/XP sys und verbindest dich mit dem internet.
bevor du überhaupt irgendwie ein update machen kannst bist du schon offen wie ein scheunentor.
oft genug erlebt.

"der computer wird in 30 sekunden neu gestartet"
*gg*
system zumindest einer minimalen konfiguration unterziehen und das passiert nicht...wer das erlebt der ist einfach zu unbedarft (sorry, wenns "zu" deutlich ausgesprochen ist)


eine pfw als ausreichend zu bezeichnen O.o...für was zusätzlichen balast...zusätzliche risiken und und und aufladen für etwas das man durch wenige mausklicks bekommt!