[Rika]

1. Der WMP ist der einzige, bei dem es nicht ganz so einfach ist. Die versteckten Optionen kann man aber mit XSetup alle erreichen.

2. Es wird immer gehen. Zur not kann man immer noch NTDLL:TerminateProcess einbinden - das ist der direkteste Aufurf, den man nicht unterbinden kann. Sorry, aber solange der Benutzer Adminrechte (Standardbenutzer) oder zumindest Prozessverwaltungsrechte hat (Template: Hauptbenutzer), hat er immer die Möglichkeit, Prozesse zu beenden.

[Meltdown]

Zitat (simcard: 03.02.2004, 12:55)

Schön, das zu hören 

Beschwer Dich deswegen nicht bei uns...

Das ist nicht unsere Schuld.

Nebenbei: Es muß doch lästig sein, ständig dafür sorgen zu müssen,
das irgendein Tool im Hintergrund läuft. Dazu dann der ganze Rattenschwanz
an Aktualisierungsaufwand, der sich da mit dranhängt. Schon Windows allein herzurechten - da will ich gar nicht mehr drüber...

Du machst Dich so nur abhängig von etwas.

[Meltdown]

Zitat (simcard: 03.02.2004, 13:27)

Bin von nix abhängig 

Kontra!
Natürlich bist Du das, weil Du es ohne offensichtlich nicht hinkriegst.

Und ICH (zumindest - man beachte die Betonung!) hätte echt keine Lust bei jedem Mayor-Update einer Firewall erst die die Kurierung der Kinderkrankheiten abzuwarten, nur weil der Hersteller mal wieder meinte er müsste (um seine Kassen aufzubessern)
eine neue Version herausbringen...

Dieser Beitrag wurde von Meltdown84 bearbeitet: 03. Februar 2004 - 13:49

[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.