[Meltdown]

Zitat (simcard: 03.02.2004, 14:05)

Noch nicht, warten wir mal ab

Wenn Du das wirklich willst, hab ich da nicht die geringsten Zweifel...

Aber je mehr irgendwie "verwandte" Windows-Systeme auf dem Markt
kommen, desto mehr muß man sich Aufbau, Organisation, Bugs und Besonderheiten dieser Systeme einprägen...

Wie lange das noch gut gehen soll, frage ich mich auch allmählich.
Microsoft hat da ja selbst schon Probleme die Sache vor die Reihe zu bekommen...

[Rika]

@simcard:

1. Wie ich schon sagte: Solange du mindestens Hauptbenutzer bist, kannst du alles killen. Wenn die Leute sich dort so dämlich anstellen - Trojaner stellen sie geschickter an.

2. Wesentlich einfacher: Einfach automatisch Zulassen an den Abfrage-Dialog schicken. Das geht so schnell, da sieht der User den Dialog nichtmal.

3. ZoneAlarm ist saudumm. Ports sind immer Stealth, und dieses unsinnige Verhalten lässt sich nicht abstellen. Zudem funktionieren die Filteregel für UDP-Pakete nachweislich nicht.

@Meltdown:

Ist dir schon mal aufgefallen, dass viele begründen können, warum DTFs unsicher sind und warum praktisch niemand (besonders niemand, der sie tatsächlich einsetzt) bergünden kann, warum sie den Rechner sicher machen sollen?

[Meltdown]

Zitat (Rika: 03.02.2004, 17:41)

@Meltdown:
Ist dir schon mal aufgefallen, dass viele begründen können, warum DTFs unsicher sind und warum praktisch niemand (besonders niemand, der sie tatsächlich einsetzt) bergünden kann, warum sie den Rechner sicher machen sollen?

Nach 14 Thread-Seiten ist es auch zu mir durchgedrungen...

[Superia]

Zitat (Rika: 03.02.2004, 12:38)

Das ist doch die einzige Funktion, die bei DTFs wirklich vielversprechend ist: Applikationskontrolle. Und genau die funktioniert aus obengenannten Gründen nicht.

Ach nein? (Nach der Installation des letzten MSIE-Patches)

Zitat

Alles andere wie Portfilter ist doch sinnlos - was zu ist, bleibt zu, was offen ist, bleibt trotz DTF weiterhin offen.
Jede Version von Outpost hat dieses Problem

Und woher weist Du dass?
Du hast doch wohl noch nie mit Outpost Pro gearbeitet!?

[Rika]

Du willst es offensichtlich nicht kapieren:

1. Avant Browser soll offensichtlich Zugriff zum Netz haben - aber die Firewall vergeutet deine Zeit mit einer zusätzlichen Nachfrage.
2. Trojaner XYZ soll keinen Zugriff haben - die Firewall wird aber entweder einfach beendet oder die Abfrage automatisch vom Trojaner beantwortet.
3. Anwendungd SpyABC will Zugriff auf's Internet, soll ihn aber nicht bekommen. Statt die Firewall das ganze blockieren zu lassen, solltest du dich eher fragen, warum du SpyABC überhaupt verwendest.
4. Ich habe Outpost ebenfalls getestet und musste feststellen, dass sowohl FIN-Scans als auch XMAS-Scans problemlos erkennen können, welche Ports offen und welche geschlossen sind. Egal wie sehr sie blockiert wurden.
5. Ebenso ist dein toller Beitrag bezüglich DLL-Injection vollkommen sinnfrei, denn gegen Mehrfach-DLL-Injection (a.dll -> b.dll -> c.dll -> Wirtsprogramm) nützt das gar nix - wenn sich der Trojaner überhaupt die Mühe macht, die Firewall nicht selbst zu manipulieren, sondern sich nur dran vorbeischmuggeln will.
6. Ebenfalls nützt das nix gegen Shell-Aufrufe anderer Programme - so wie z.B. der RealPlayer einfach eine temporäre HTML-Datei erzeugt, diese aufruft und alle Daten in der URL rausschmuggelt. Mit DNS-Abfragen ist das noch viel interessanter und geschickter.
7. Und warum nicht einfach einen eigenen TCP/IP-Stack mitbringen und alles direkt an die Netzwerktreiber schicken? Tja, da kann auch Outpost nichts nachprüfen, weil es umgangen wird. Sowas ist shcon längst Standardrepoirtoire von Trojanern.

Und mal was für dich zum Lesen: http://home.arcor.de...ustricksen.html

[Meltdown]

Nebenbei: Ich denke das das Tool doch vorher aufschreien sollte -
bevor die DLL-Datei ausgetauscht wird. Und nicht hinterher
"Meldung machen"...

[Legin]

Also kann ich als Resümme dieses Threats sehen dass ich meine DTF besser deinstalliere? (Norton, ja ich schäme mich!!!!!)

Soll ich dann ohne irgenteinen "Schutz" durchs internet streifen? Ich hätte ja noch die "Firewall" (kann man das so nennen?) im Router, nur die ordentlich zu konfigurieren, so dass alles läuft was laufen soll, ist mir (noch) nicht gelungen....

Legin

Dieser Beitrag wurde von Legin bearbeitet: 03. Februar 2004 - 21:23

[Rika]

1. Wenn kein Programm läuft, das Internetzugriff benötigt, sollte höchstens nur genau ein Port offen sein: 135 -> wenn nicht: checken, was läuft, deaktivieren

2. Der RPC-Service am Port 135 wartet nur auf Anfragen, verschickt aber selber nix. Ergo, wenn dort ein Angriffspunkt existiert, dann muss die Verbindung von außen initiiert werden. Das verhindert aber bereits das NAT im Router. Extra Blockier-Regeln sind relativ sinnlos.

3. Eine Firewall taugt nicht zur Kontrolle ausgehender Verbindungen - hab ich ja gezeigt. Sie taugt nur mäßig zur Kontrolle eingehender Verbindungen - aber das übernimmt ja ohnehin der Router. Wozu dann denn überhaupt 'ne extra Firewall? Das bringt doch nix.

4. Nächster Punkt: Was ist denn überhaupt die Aufgabe einer Firewall? Sie trennt ein sicheres von einem unsicheren Netz. Wenn der Rechner direkt am Netz hängt, wo soll sie da denn was trennen? Bzw. wenn er im lokalen Netz hängt, dann doch nur am Router, aber doch nicht auf dem Rechner - zumal der Router bereits genau das macht.

[Meltdown]

..."ein Kampf der Ideologien"...



Meine Güte, was für'n Threadtitel...

(Die Mods haben nicht nur den Thread geteilt, sondern anscheinend auch
Zensur betrieben. Wenn ich mir die 1. Seite so anschaue, fehlt da auch
was...)

Dieser Beitrag wurde von Meltdown84 bearbeitet: 03. Februar 2004 - 21:58

[Meltdown]

Zitat (simcard: 03.02.2004, 23:27)

So, musste erstmal suchen, wo der Thread hinverfrachtet wurde.
Wer sich den Titel ausgedacht hat  

Das er verfrachtet wurde, war wohl notwendig.

Ich mußte auch erstmal suchen. Da will man sich austauschen,
und wird dann einfach umgeleitet...



Sowas auch...

[Rika]

1. Ein Cookie ist nix weiter als eine Textdatei und dient normalerweise dazu, Session-IDs zwischenzuspeicher - was wesentlich sicherer als ständiges Transferen in der URL ist.

Wenn das Cookie-Management schlecht und die Webseite datengeirig ist, dann liessen sich theoretisch Bewegungsprofile erstellen. Extrem unwahrscheinlich, praktisch nie angewendet - Cookies sind ungefährlich.

Auf keinen Fall jedoch können sie Code ausführen.

2. Bockwurst hat hinter dem w vier Zeichen, nicht drei.

3. PestPatrol taugt nix.

4. Theoretisch sind immer noch Angriffe über Fehler in der TCP/IP-Implementierung des Betriebssystems möglich. Nur sind diese Zeiten schon längst passe und wenn doch noch so ein Fehler auftritt, kann einen eine Firewall davor nicht schützen. Im Gegenteil, meist ist es die Firewall, die dann gegen solche Fehler anfällig ist.

5. Insgesamt sei zu sagen: Präventives und umsichtiges Handeln ist immer besser als reaktives Handeln. Insofern sollten Spybot, AdAware etc. nur der eigenen Überprüfung dienen - wenn sie was finden, dann sollte man sich vor allem überlegen, was man falsch gemacht hat. Das darf nämlich kein Dauerzustand werden.