Beiträge von Oliver222

Claudia 72 fragte Folgendes:

Zitat

[...]Ich habe meine Chronik gelöscht. Da dort eine wichtige Internetadresse drin war, müsste ich diese wieder herstellen.Wie funktioniert das?[...]

Nicht einfach.

Die Historie Deiner bereits gelöschten URL-Aufrufe wird unter Firefox als separate und darüberhinaus versteckte Datei - und zwar in Form einer sog. „downloads.sqlite“ gespeichert - die vom OS (also Deinem Betriebssystem) vermutlich bereits schon als gelöscht markiert und somit zum Überschreiben entbunden wurde.

Somit liessen sich die sog. Verlaufsdaten - also Deine über einen zeitlichen Verlauf hinweg angesteuerten und mittlerweile gelöschten Daten des Browsers - auch aus dem Betriebssystem (z.B. Windows) selber heraus mit Betriebsmitteln (z.B. über zeitlich gesetzte Wiederherstellungspunkte) nicht mehr extrahieren (wiederherstellen), sofern keine externen Datenwiederherstellungsprogramme zur Anwendung kämen.

Die Freigabe des Betriebssystems zum Überschreiben solcher gelöschten Daten (i.d.F. Deiner Chronik) bedeutet jedoch nicht zwangsläufig, dass Deine Chronik als geschlossene Datei u.U. nicht doch wiederaufbereitbar (also wiederherstellbar) wäre, da so ein Betriebssystem i.d.R. die Zuordnungen einzelner Datenfragmente wiederum auf unterschiedliche Sektoren des Datenträgers willkürlich zu verteilen vermag.

Deine gelöschten Daten können sich somit physikalisch immer noch auf Deinem Computer befinden, sofern Du:

a. Eine relativ grosse Festplatte als C:\ (als System - und Datenlaufwerk) nutzt.

b. Den Computer - vom gegebenen Zeitpunkt an - bisher „relativ wenig“ beanspruchtest.

c. Bisher keinen Defragmentierungsprozess dieses Datenträgers eingeleitet hattest.

Was schlussendlich die Wiederaufbereitung Deiner verlorenen Chronik angeht, so versuche es einmal mit der frei erhältlichen Applikation: „Recuva“. (Verlinkung des Programms s.u.).

Bedenke dabei jedoch, dass so ein Browser u.U. auch die Ausführung sicherheitskritischer Bereiche erfüllen muss (z.B. vertrauliche Firmen- / Finanzdienstleisterzugänge etc.), was als Zustand erst ein unbedingtes und regelmässiges Überschreibungsverfahren dieser Speicherbereiche (Chronik / Historie) mit Nullen erforderlich machen würde.

Oliver

http://www.filehippo.com/download_recuva

.Ulli erklärte u.A. Folgendes:

Zitat

[...]Ein manipulierter Treiber kann so einiges, ihn aber über die API des WebGL zu manipulieren dürfte schwierig sein.[...]

Das Thema wurde von Dir vermutlich missverstanden - oder ich habe mich im Voraus falsch ausgedrückt...

Ein OS-Graphikkarten-Treiber wird weniger über die API (also der Schnittstelle zwischen Betriebssystem und System-Anwender) des browsergeführten Web GL´s selber angegriffen (kompromittiert) werden können (wie von Dir dargestellt) - Umgekehrt könnte jedoch ein Schuh daraus entstehen.

In diesem Szenario müsste dann die API des Web GL´s über den jeweils eingesetzten Browser (z.B. Firefox) u.U. auf einem bereits kompromittierten Hardware-Treiber (Graphik-Treiber) des Betriebssystems selber aufsetzten und diese übertragenen Daten im Anschluss auch als authentisch (wahrheitsgemäss) interpretieren müssen - was wiederum verheerende Konsequenzen für die Anwendungssicherheit der Nutzer solcher "WebGL-Browser" nach sich ziehen könnte.

Darüberhinaus können - meiner Beurteilung nach - folgende Sicherheitsbeeinträchtigungen wirken:

Zitat

a. Ein wie auch immer gearteter Graphik-Karten Treiber (auf den der Browser über WebGL uneingeschränkt zugreifen dürfte), hätte somit grundsätzlich auch Zugriff auf die Gleitkomma-Einheit des Coprozessors so einer Graphik-Karte. Diese FPU (Gleitkommaeinheit /Coprozessor) ist massgebend zur Berechnung ungerader Zahlen. (z.B. für Computerspiele).

b. Allgemeine Verschlüsselungsverfahren greifen i.d.R. zur Berechnung kryptographischer Chiffrierungen - durch eine generische Berechnung der Verschlüsselung auf Koprozessoren (also der Festkommaarithmetik) - des eigentlichen Hauptprozessors (der CPU) selber zu, um überhaupt in kurzer Zeit qualitative kryptographische Übertragungen berechnen zu können. Der jeweils eingesetzte Hauptprozessor ist für solche Berechnungen nicht geeignet.

c. Wird nun ein - wie auch immer gearteter und bereits kompromittierter Browser - unter Einsatz von WebGL - von einem unbedarften Nutzer verwendet, so bestünde die Möglichkeit (die Gefahr), eben genau über diese kompromittierte interaktive Schnittstelle (also über den bereits kompromittierten Browser selber), bereits berechnete und vertrauliche Zugangs-Verfahren zuungunsten des Anwenders unter Einsatz einer Scriptsprache (z.B. JavaScript) durch uneingeschränkte Zugriffe auf solche graphischen Coprozessoren wieder zurückzuberechnen.

Der zugrundeliegende Browser sollte von daher nicht als interaktive Schnittstelle direkt auf Hardware aufsetzen dürfen, deren Treiber-Software u.A. für kryptographische Berechnungen in Hinblick auf vertrauliche Zugänge (Finanzdienstleister, Banken, Behörden, etc.) verwendet wird.

.Ulli erklärte darüberhinaus Folgendes:

Zitat

Zurück zum WebGL.
Es ging ja nicht um ein BIOS, sondern um die Ausführung eines Programms.

Nein - Es geht dabei um den uneingeschränkten Zugriff des interaktiven Browsers auf ungesicherte Hardware-Treiber - Nicht um ausführbare Prozesse. Ein ungesicherter Hardware-Treiber verhält sich im sog. eingeschränkten User-Mode (Betriebssystem-Umgebung) immer noch sicherer als im uneingeschränkten Kernel-Mode.

Ulli stellte obendrein leider Folgendes dar:

Zitat

[...]Blogs jeglicher Art und Reputation werden hier immer noch als Rülpsen oder Flatulenz (Aufblähung) einer Person dieses Planeten abgetan.[...]

Das unterscheidet jene Menschen die sich stetig weiterentwickeln - und solche Blogs verarbeiten - von jenen Menschen, die bedauerlicherweise stehenzubleiben scheinen.

Das unterscheidet darüberhinaus jene Menschen die dazu tendieren „vorzuverurteilen“ von jenen Menschen, die versuchen ihre Ansichten ständig zu revidieren.

@.Ulli - Denke mal in Ruhe darüber nach, was Du in Bezug dieses Kommentars geschrieben hast. Wir alle haben die Weisheit und das Wissen nicht mit der Muttermilch aufgenommen, jedoch brauchen wir die Möglichkeiten und das Wissen vieler Anderer (u.A. auch der ganzen Blog-Beiträge) um hier überhaupt weiterzukommen.

Ich kann mich irren - Jedoch was wir innerhalb dieses Forums in der Zukunft nicht brauchen werden, sind „alteingesessene Mitglieder“, die „glauben“ alles zu wissen, um von daher für neue technische Herausforderungen nicht mehr empfänglich zu sein.

Oliver

.Ulli erklärte Folgendes:

Zitat

Immer herrlich solch publizistische Überschriften zu sehen: WebGL: 3D-Standard gefährdet Firefox und Chrome.[...]

Solche Beiträge nicht voreilig vorverurteilen. Lese Dich bitte genauer in die Thematik ein.

Meinen bisherigen Kenntnissen nach, stellt die Interpretation interaktiver Inhalte über WebGL - innerhalb des jeweils eingesetzten Browsers (z.B. Firefox 4 / Chrome / Safari) - theoretisch kein Risiko dar.

Praktisch geht es jedoch - unter Umgehung der Betriebssystemsverfügungen - um den direkten Zugriff des Browsers auf die Graphik-Hardware des Betriebssystems, was meiner Ansicht nach unüberschaubare Konsequenzen für die eingesetzte Systemsicherheit selber zur Folge haben könnte.

Sofern ein wie auch immer gearteter Browser uneingeschränkt auf Hardware-Treiber (also in diesem Falle: Graphik-Treiber) des zugrundeliegenden Systems (z.B. Windows) zuzugreifen vermag ist somit - unabhängig vom Browser - logischerweise die geschriebene Treiber-Software für diese GUI (graphische Schnittstelle) das schwächste Glied in der Sicherheits-Kette.

Grund dafür ist die Tatsache, dass für OEM-Graphik-Treiber (die logischerweise auf der Hardware-Schnittstelle selber aufsetzten und im Anschluss wiederum vom Browser direkt interpretiert werden müssen) bisher noch kein Sicherheitsstandard definiert wurde.

Hinzu käme obendrein, dass unter Einsatz von Java-Script im Browser als „offene Schnittstelle zum Nutzer hin" die Aufbereitungen solcher graphischen Inhaltsdaten (z.B. der einzelnen Shader einer Graphik) leichter zu berechnen wären was - unter Voraussetzung einer bereits erfolgten Kompromittierung - wiederum anonyme Rückschlüsse auf das jeweils eingesetzte System zuliesse. (Timing-Attacks / Kryptographische Fernanalysen).

Wie auch immer gearteter Browser haben somit - meiner Beurteilung nach - nichts im Kernel-Modus des Betriebssystems verloren.

Oliver

https://wiki.mozilla.org/Blocklisting/B…raphics_Drivers
http://www.contextis.com/resources/blog/webgl/

Miss oud erklärte u.A. Folgendes:

Zitat

[...]Wir benutzen einen gemeinsamen Router, ich habe jetzt seit ein paar Tagen den Privatmodus eingestellt, bin mir aber eben nicht sicher gewesen, ob trotzdem weiterhin die Seiten im Router zu sehen sind.[...]

Mache Dir diesbezüglich keine Gedanken.

Stichwort: Zugangsdaten < > (ungleich) Inhaltsdaten.

Die Inhalte der von Dir in der Vergangenheit aufgerufenen Web-Seiten sind über den Router nachträglich durch „Dritte“ definitiv nicht einsehbar, da solche Router bloss verbindungslose Übertragungswege abzuspeichern vermögen.

Ein Router stellt darüberhinaus kein Cache (Puffer-Speicher) für Daten-Inhalte dar.

Jedoch liessen sich dagegen die ursprünglichen Zugänge (also die IP-Adressierungen) über das Log-Protokoll des jeweils eingesetzten Routers dennoch nachträglich recherchieren. Dein ehemaliger Lebenspartner müsste dazu jedoch die bereits im Router gespeicherten IP-Adressen erneut aufrufen - um somit erkennen zu können - welche Webinhalte Du - zu welchem Zeitpunkt genau - im Vorfeld bereits aufgesucht hattest. Im Zuge dieser Vorgehensweise würden ihm jedoch keineDeiner vertraulichen Daten offenbart werden können (z.B. Inhalte Deiner bereits verfassten emails / bzw. formulierte Beiträge innerhalb diverser Sozialnetzwerke).

Folgende Zugangsadressierungen können - meines Wissens nach - als Logdatei (also als sog. „Ereignisprotokolldatei“) automatisch und routerseitig als Zugriffsprotokoll clientseitig (temporär) gespeichert werden:

Zitat

- Zeitpunkt und Datum des Internetzugriffs.
- Das zugrundeliegende Übertragungs-Protokoll (z.B. UDP / HTTP / Telnet / etc.).
- Source / Quelle: also Deine IP-Adresse.
- Destination / Ziel: also die (erste) dedizierbare Bestimmungsadresse Deines Aufrufs.
- Temporäre MAC-Adresse (routerseitige Geräteerkennung innerhalb Deines Netzwerkes).
- OS (Betriebssystem).

Miss oud erklärte u.A. Folgendes:

Zitat

Wir benutzen einen gemeinsamen Router, ich habe jetzt seit ein paar Tagen den Privatmodus eingestellt, bin mir aber eben nicht sicher gewesen, ob trotzdem weiterhin die Seiten im Router zu sehen sind.[...]

Der Privatmodus des Firefoxes hat keinen Einfluss auf das Übertragungsprotokoll Deiner Netzwerkzugriffe. Platt und andersherum ausgedrückt, endet der Privatmodus des Firefoxes genau mit dem Anfang des Netzwerk-Kabels, welches aus Deinem Computer heraus weiter zum Router geführt wird.

Miss oud fragte darüberhinaus Folgendes:

Zitat

Meine Mails kann er auch lesen???? Daher wahrscheinlich das Wissen, dass ich eine neue E-Mailadresse habe.

Nein. Noch einmal. Dein ehemaliger Lebenspartner wird Inhalte Deiner vertraulichen Nachrichten aus den Router-Logdateien heraus nicht schöpfen können. Eine solche Wiederaufbereitung von Dateninhalten ist technisch mit handelsüblichen Routern so nicht zu realisieren.

Sofern Ihr beide jedoch nur einen gemeinsam genutzten Computer als Zugangsgerät zum Internet betreibt, wäre es u.U. jedoch denkbar, dass Dein ehemaliger Lebenspartner lokal über dieses Gerät (z.B. über ein gemeinsam genutztes Notebook) dennoch auf Deine Daten zuzugreifen vermag, sofern ihr auf diesem System ein gemeinsames Zugangskonto nutzt und er somit u.U. Zugriff auf Deine Programme - bzw. Deinen email-Client hätte.

Soweit ich es zu beurteilen vermag, betrachte von daher bitte eher die Qualität Deiner Daten-Sicherheit gegenüber dem Wert Deiner Daten die auf Deinem Computer bisher hinterlegt sind/wurden, um somit für Dich geeignete Schutzprofile zur Anwendung zu bringen.

Oliver

.Ulli erklärte u.A. Folgendes:

Zitat

[...]Da liegt etwas, aka Objekt, mit einer virusartigen Signatur im Cache herum.
Egal wie es dort hinein kam, es tut nichts, es kann nichts tun - es liegt einfach nur so herum. Eine unbekannte Seite meinte es zu benötigen, wozu auch immer. Das Objekt liegt sowohl genutzt innerhalb des Fx vor als auch im Cache für einen späteren, wiederholten Gebrauch.[...]

Meiner Ansicht nach richtig und verständlich.

Im Puffer-Bereich (also Cache) des Browsers (z.B. des Firefoxes) abgelegte Datenfragmente stellen im Zuge ihrer „Benutzung“ nur genau dann ein Sicherheitsproblem dar, sofern diese Datenfragmente aktiv ausführbare Scripte enthalten, welche wiederum durch den einmaligen oder auch nachhaltigen Zugriff wie auch immer gearteter Interpreter (z.B. Programme / Prozesse) zur Ausführung gelangen können / dürfen - was ja eigentlich nicht sein soll.

Dabei ist es - meinen bisherigen Kenntnissen nach - unerheblich, ob diese Zugriffsverfügungen des Browsers im Registerbereich des RAM´s residieren oder längerfristig auf dem Datenträger abgelegt werden. Entscheidend sind vielmehr die wiederholbaren Zugriffsmöglichkeiten auf diesen Cache unter verschiedenen Browserkonfigurationen. (z.B. mit oder ohne JavaScript, FlashCookies, zugeschalteten Prozessen innerhalb der bereits konfigurierten und individuellen Browserumgebung).

mfzb erwiderte u.A. Folgendes:

Zitat

Na jetzt aber langsam - Dein Beitrag ist wieder beleidigend. Die Fragen nicht verstehen und großmaulige Antworten geben - so was habe ich echt gern.[...]

.Ulli hat Dich nicht beleidigt. Er erwiderte - meiner Beurteilung nach - auf Deine Anfrage hin mit einer technisch korrekt ausgestalteten Antwort, die Du vielleicht falsch auffasstest, um diese darüberhinaus durch technisches Unverständnis u.U. als Beleidigung gegenüber Deiner Person zu interpretieren.

Dir obliegt darüberhinaus nicht das Recht „Spitzen“ gegen technische elaborierte Antworten zu „fahren“, dessen Essenz Du im Ansatz vermutlich noch nicht einmal verstanden hast.

Frage lieber nach. Dafür sind wir alle hier.

mfzb fragte u.A. Folgendes:

Zitat

[...]Betreffend AV-Software werde ich demnächst von Avira wahrscheinlich auf Avast umsteigen. Trotzdem interessiert mich jetzt das Thema und würde es gerne ausprobieren, wie sich die andere Einstellung auf das Surfen auswirkt.

Mache Dir bitte Gedanken über die sog. präventiven Massnahmen (also eine im Vorfeld etablierte Systemabsicherung Deines Computers) zur Abwehr kompromittierender Einwirkungen (z.B. gegenüber Viren / Würmer / Makroprotokolle / etc.).

Von Relevanz ist dabei nicht ein wie auch immer ausgestalteter und perfekter Virenscanner, sondern eher die duch Dich im Vorfeld durchgreifend ausgestaltete Absicherung Deines Computer-Systems.

Oliver

Es geht im Zuge dieses Threads - meiner Meinung nach - nicht bloss um „protektionistische Klüngelei“ - innerhalb dieser Gemeinschaft - sondern eher um die Darstellung der Wahrheit - von der wir hier alle letztendlich (hoffentlich) profitieren dürfen. Wenn sich dann auch alle mit qualifizierten Beiträgen beteiligen würden.

bugcatcher:
Welches Zitat - in Bezug auf Deine vergangenen Darstellungen - wurde denn von mir zu Deinen technisch argumentatorischen Nachteilen genau verfälscht? Ich höre Dir im Moment sehr genau zu (s.u.).

Bugcatcher erläuterte darüberhinaus im Zuge dieser Diskussion Folgendes.

Zitat

[...]Hab ich nicht behauptet. Das ist die Umschreibung deines generellen Verhaltens in allen Threads an denen du dich hier beteiligst...[...]

Damit hast Du Dich - meiner Beurteilung nach - gerade für weitere (technische) Diskussionen disqualifiziert. Darüberhinaus nach einen Mod zu „schreien“, da sich scheinbar Deine technische Beleuchtung zu erschöpfen erscheint, führt zu keiner Weiterführung - bzw. schlussendlichen Zielstellung dieser Thematik.

Bugcatcher stellte u.A. Folgendes dar:

Zitat

Der Router ignoriert aber nicht die zusätzliche Headerinformation. Er blockiert die gesamte Anfrage.[...]

Was für ein Wunder...
Hast Du [Bugcatcher] es denn immer noch nicht begriffen?

a. Der Zugriff auf einen dedizierten Router (zur Konfiguration) aus dem Intranet (LAN) heraus, muss i.d.R. über notwendige „HTTP-Referrer“ (als eine zusätzliche verifizierbare Zugriffs-Information dieses geschlossenen Netzwerkes) erfolgen, da solche zu konfigurierenden Router - auf diesem vereinfachten kommunikativen Level (2 oder 3) - für externe/interne Verschlüsselungsverfahren nicht immer geeignet ausgestaltet (konfiguriert) wurden. Eine notwendige (wenn auch einfache) Verschlüsselung der anfragenden IP-Pakete gegenüber so einem Router würde darüberhinaus bloss auf Level 2 erfolgen können.

b. Demgegenüber muss der öffentliche Zugriff - bzw. die Weiterführung zu übertragender Informationen (des Nachrichtenstroms) - über wie auch immer geartete Router - als funktionierende Firewall - über das Internet i.d.R. auf Basis der Kommunikationsschicht 3 (der Netzwerkschicht) selber geführt werden.

Genau dort wird gefiltert.

Das die von Dir zitierten „Anfragen“ somit bereits routerseitig abgewiesen werden, ist eher der Sicherheit, als der allgemeinen Zugänglichkeit dienlich.

@Cosmos
Das Philosophie-Forum der theoretischen Informatik befindet sich woanders.

Oliver

Bugcatcher versuchte u.A. Folgendes abzustreiten:

Zitat

[...]Sie [die Anfrage auf Unterdrückung des Referers] erhält Relevanz(,)wenn ein Router die Anfrage falsch auslegt und es dadurch zu einem ungewollten (User will (es) nicht so haben und weils der User nicht will, wirds auch Mozilla und der Routerhersteller nicht so haben) Verhalten kommt.

Das ist nicht Dein Ernst?

Führen wir im Zuge dieses Threads eine qualitativ orientierte technische Diskussion oder sprechen wir hierbei eher von subjektiven „Launen“ digitaler „Vermittlungs - bzw. Endgeräte“?

Bugcatcher erklärte (in einem vergangenen Beitrag) u.A. Folgendes:

Zitat

[...]Und einige Router kommen offensichtlich mit dem "Do not Track"-Headereintrag, den Firefox bei aktivierter Option mitschickt, nicht klar (vermutlich als "unbekannt" registriert)[...]

Für wie auch immer geartete „HTTP Referrer“ - sowie auch für das zu übertragende sog. „Fingerprinting“ (Erkennung von Betriebssystemen) - gilt bislang noch kein universell gültiger Standard gegenüber der einzelnen HTTP-Anfragen selber. Egal ob es sich dabei um HTTP-Zugriffe auf Router oder Webseiten handelt. Firefox ist im Zuge dieser Vorgehensweise leider nicht das Mass der Dinge.

Das „Do not Track“ Verfahren des Firefoxes kann von daher durch die angefragte „Gegenstelle“ auf der Netzwerk/Transportschicht ignoriert bzw. auch abgelehnt werden. Diese Reaktion der Gegenstelle würde somit keinen Fehler darstellen.

Entschuldige darüberhinaus bitte - Aber das Mozilla „doof“ ist (Deine interpretative Wortwahl) - wurde innerhalb dieses Diskussionsverlaufs - und allgemein - von niemanden behauptet.

Mozilla wächst an den „objektiv“ veröffentlichen Fehlern. Dazu gehört zwangsläufig ein gehöriges Mass an Kritik.

Sofern Du [Bugcatcher] im Zuge dieser Diskussion scheinbar an Deine technischen Grenzen geführt wirst, so sage diesbezüglich lieber nichts mehr.

Wir alle „wissen“ gar nichts. Wir entdecken fortwährend nur Neues...

Oliver

bugcatcher erklärte u.A. Folgendes:

Zitat

Wenn ein Interface über HTTP aufgerufen wird, verarbeitet es auch Header-Daten [...]

Ist uns bekannt - Du erklärst uns bedauerlicherweise - zumindest mir - leider nichts Neues.

bugcatcher stellte darüberhinaus Folgendes dar:

Zitat

[...]Vermutlich würde ein Firmware-Update des Routers [gegenüber den Anfragen des Firefoxes] helfen, sofern dieser [diese Router-Software] überhaupt noch durch den Hersteller unterstützt wird.[...]

Update in Bezug auf welche Anfragen? Aus dem geschlossenen Intranet oder systemübergreifend aus dem Internet? Firefox oder andere Browser? Klingt das eben von Dir genannte nicht etwas arrogant? Ich glaube wir sprechen hierbei von zwei unterschiedlichen streckentechnischen Zugriffsverfahren auf solche Router.

Darüberhinaus stellt - meinen bisherigen Kenntnissen nach - das von Dir [bugcatcher] genannte sog. Header Block Tracking der durch den Firefox übertragenen IP-Pakete keinen wirklichen Schutz (also keine Opt-Out-Massnahme) gegenüber möglichen individuellen Auswertungen diverser Webseiten dar, da dieser Option nicht zwangsläufig durch die kommunikative Gegenstelle (also der angefragten Webseite / dem Request) selber gefolgt werden muss. Es wird dabei bloss eine Anfrage auf Unterdrückung der zusätzlichen Header-Informationen erwirkt, die jedoch nicht von Relevanz ist.

Webseiten müssen somit nicht auf die angefragte Ablehnung des „Header-Block-Tracking“ durch den Browser reagieren.

Der Firefox-Browser ist obendrein durch seine Verbreitung inzwischen auf den uneingeschränkten Zugriff möglichst vieler Internetseiten angewiesen. Diese benötigen jedoch zur statistischen Auswertung möglichst viele internal records informations (interne Datenzugriffsaufzeichnungen), die jedoch durch anonymisierende Zugriffsverfahren des Browsers selber nicht mehr gewährleistet werden können.

Denke abschliessend bitte noch einmal in Ruhe über diesen „Zielkonflikt“ und Deine vorangestellten Ausführungen nach - und melde Dich darüberhinaus im Anschluss daran bitte mit einer möglichst objektiven Aussage gegenüber „Tracking-Procedures" wieder. Nicht böse gemeint.

Oliver

https://wiki.mozilla.org/Privacy/Jan2011_DoNotTrack_FAQ

PvW erlärte u.A. Folgendes:

Zitat

[...]Die (VodaFone) DSL-EasyBox 602,Firmware Version:20.02.024 hier (XPSp3-via LAN) bleistiftsweise läßt das Einloggen in die Konfigurationsoberfläche nicht zu.[...]

Wie kommst Du darauf?

Ein LAN geführter und darüberhinaus kabelgebundener Zugriff - der als sicherer gilt, als die Signalausbreitungen eines WLAN gestützten Funkzugriffes - könnte unter den default-Einstellungen (also Standard-Einstellungen) dieses Gerätes (EasyBox 602) lauten wie folgt:

a. Ansprache über die Host-Eingabe in der URL-Leiste des Browsers: easy.box

b. Benutzername: root

c. Kennwort: 123456

Anspruchsloser lässt sich der Zugriff auf dieses Konfigurationsmenü per Standard-Einstellung vermutlich nicht realisieren.

Die Frage die sich - meiner Ansicht nach - dabei jedoch stellt ist die Tatsache, inwieweit solche Gateways (also Router), die ja unterschiedliche IP-Funktionssektoren (z.B. Internet, Telephonie,) synchron (gleichzeitig) verwalten müssen, bereits schon auf der Netzwerkschicht (Protokollschicht 3) gegenüber äusserlich einwirkenden Kompromittationen wirklich abgesichert sind.

Das paketvermittelnde und darüberhinaus verbindungslose IP-Protokoll (Level 3) gilt für eine wie auch immer geartete vertrauliche und verbindliche Kommunikationsführung bezüglich seines Ursprungs als nicht sicher ausgestaltet.

Oliver

joe44 fragte folgendes:

Zitat

[...]seit ich Firefox 4 installiert habe, kommt beim Aufruf immer eine seitenbreite Fehlermeldung:

XML-Verarbeitungsfehler: Nicht definierte Entität.[...]

Versuche die bisherigen Firefox-Versionen auf Deinem System über die Deinstallationsroutine vollständig zu entfernen. Dazu gehören auch alle Profile, Lesezeichen sowie auch bereits installierte Add-Ons. Die bisherigen IE-Tabs sind ohnehin nicht mehr FF4 kompatibel.

Sofern Du Windows benutzt, lösche darüberhinaus den folgenden (versteckten) Ordner aus dem Explorer heraus.

C:\Users\<username>\AppData\Local\Mozilla\Firefox\...

Installiere daraufhin den FF4 erneut.

Solltest Du obendrein die Interpretation des Internet-Explorers zur Interaktion mit diversen WWW-Serven innerhalb der Firefox-Umgebung benötigen, so versuche statt der Erweiterung: IE-Tab einmal die Erweiterung: IE-View einzusetzen.

Oliver

http://kb.mozillazine.org/Uninstalling_Firefox
http://ieview.mozdev.org/

Bugcatcher erklärte u.A. Folgendes:

Zitat

Ein Fehler auf Seiten der Routers. Der hat die Information die Firefox mit der Option verschickt „in den falschen Hals“ bekommen.

Das ist - meiner Ansicht nach - einer der trivialsten Erklärungsversuche, die wir hier bisher vernehmen durften. Ganz bestimmt liegt es an keinem Fehler auf den Seiten des Routers. Ohne es böse Dir gegenüber zu meinen - jedoch wenn Du diesbezüglich keine Ahnung hast, dann sage lieber gar nichts.

Darlee
Für den Zugriff auf das Konfigurationsmenü des Speedport-Routers gilt folgende Zuschaltung: (Habe u.A. selber einen benutzt).

- Java Script einschalten
- Pop-Up Blocker deaktivieren
- Cookies zulassen
- Referer (about:config / [network.http.sendRefererHeader 1]) zuschalten.

Mit diesen einmaligen Grundeinstellungen (die sich jedoch nur für eine geschlossene Intranet, bzw. Router-Konfiguration anraten) lässt sich - meinen Erfahrungen nach - versionsunabhängig mit jedem Firefox auf so eine Konfiguration zugreifen.

Oliver

Road-Eunner erklärte u.A. Folgendes:

Zitat

[...]Das wäre vielleicht einfacher. Vor dem Lesen der Feeds den privaten Modus einschalten und nachher wieder ausschalten.[...]

Das wäre zu einfach. Der sog. PBM-Modus (Private Browsing Mode) des Firefoxes (sowie auch ähnliche Funktionen anderer Browser) schützen definitiv nicht vor der Ablage von zusätzlichen Daten (z.B. einige Add-Ons / Flash-Cookies etc.).

Solche browsergeführten nicht-standardisierten Programme, die nicht den PBM-Spezifikationen des Browsers selber entsprechen, können von daher - im Zuge des sog. Private-Modus - dennoch wie auch immer geartete Verlaufsdaten auf dem lokalen System hinterlegen.

Was liegt somit also näher, als nicht gleich die gesamte Arbeitsumgebung des Browsers auf ein separates (gemountetes) und temporäres Laufwerk zu legen?

Oliver

http://developer.mozilla.org/En/Supporting_…for_extensiions

http://blog.mozilla.com/addons/2010/02…ed-for-add-ons/

Atebe fragte u.A. Folgendes:

Zitat

[...]Welche Löschung (RSS-Feeds) muss ich denn aktivieren, damit nicht bekannt ist, was ich gelesen habe?

Gar keine.

Sofern ich Dich richtig verstehen durfte, so lassen sich - meinen Informationen nach - einzelne Datenfelder nicht aus Live-Feeds heraus löschen.

In der Standard-Konfiguration rendern sowohl der IEx als auch der Firefox 2x das XML Format des RSS - bzw. des ATOM-Protokolls in eine menschlich lesbare Form, die sich schlussendlich in den jeweiligen Browsern - über HTML - darstellen lassen. Sofern also die einzelnen XML-Feeds innerhalb der Arbeitsumgebung Deines Browsers interpretiert werden, so landen die Verlaufsdaten des jeweiligen zeitgesteuerten Abrufs solcher Feeds somit im Cache dieses Browsers - z.B. des Firefoxes - dessen Cache-Daten sich in einem versteckten Profil-Ordner Deines Betriebssystems befinden.

Einzelne Inhalte solcher bereits aufgerufenen XML-Feeds lassen sich - meinen Kenntnissen nach - dagegen nicht herauslöschen. Ratsamer ist es vermutlich eher, die gesamte Historie (wie mein Vorredner bereits beschrieb) zu tilgen oder das entsprechende Feed einfach zu deinstallieren.

Atebe erklärte darüberhinaus u.A. Folgendes:

Zitat

[...]Ich kann nicht bestimmen, was auf meinem PC gespeichert wird[...]

Doch das kannst Du indem Du z.B.:

a. Für vertrauliche Kommunikationsführungen überhaupt keinen Computer verwendest.

b. Betriebssystem und Browser innerhalb einer „gekapselten" virtuellen Maschine (VM) ausführst.

c. Einen Portable-Browser auf USB-Stick installierst.

d. Innerhalb des Browsers nur einen im RAM installierten Cache nutzt.

e. Den lokalen Browser-Cache auf ein RAM-Laufwerk legst (Eintrag: Firefox „about:config“).

Grundsätzlich werden jedoch durch das zugrundeliegende Betriebssystem auf Deinem Computer bei Aufruf wie auch immer gearteter Daten (Applikationen / Dienste / Internetabrufe / Downloads / etc.) Datenfragmente in den sog. File-Slacks (also innerhalb der unalloziierten Bereiche des lokalen Datenträgers) hinterlegt. Solche abgelegten Informationen können dann nur noch durch ein regelmässiges Überschreibungsverfahren der freien Festplatten-Sektoren unwiederuflich unreproduzierbar gemacht werden.

Oliver

Ouroboros1 fragte u.A. folgendes:

Zitat

[...]Ich hatte mir den Report von dem die Rede ist, angeschaut.[...]

Der sog. „Mozilla Crash-Reporter“ (Absturz-Melder) ist in den Tiefen des Firefox-Browsers voreingestellt und darüberhinaus bereits schon aktiviert. Somit werden Informationen - bzw. können sogar „anonyme Bewegungsprofile" - an Mozilla übertragen werden, sofern diese Option (also der Crash-Report) im Vorfeld nicht deaktiviert wurde.

Ouroboros1 erklärte darüberhinaus folgendes:

Zitat

[...]Meine Kentnisse reichten aber leider nicht, um da etwas betreffend ID oder ob alle Tabs gespeichert werden auszulesen.[...]

Gebe bitte einmal: about:crashes in die obige URL-Leiste des Browsers ein. Sofern sich der Firefox-Browser dagegen gar nicht mehr starten lässt, versuche es einmal mit der Visualisierung des inhaltsgeschützten System-Ordners unter Windows Vista / 7: %APPDATA%\Mozilla\Firefox\Crash Reports\. Dieses versteckte System-Verzeichnis lässt sich sichtbar machen und darüberhinaus bearbeiten.

Ouroboros1 fragte obendrein folgendes:

Zitat

[...]es gibt einen Unterschied zwischen "pending" und "submitted", schätze mal bei "submitted" wäre es egal ob ich den Crash report entfernt habe oder nicht, weil er bereits "übermittelt" wurde?[...]

Richtig.

Benutzt Du vielleicht Windows XP?
In einem solchem System existiert - meinen bisherigen Informationen nach - noch ein Unterschied zwischen der schwebend wirksamen (engl. „pending") Akkumulation (also der Ansammlung) von Log-Files, die vorläufig auf dem lokalen Rechner abgelegt werden können - Sowie dagegen den bereits schon automatisch übertragenen (engl. „submitted“) Daten an diverse Mozilla-Server. Die jeweiligen Optionen lassen sich im Browser definieren.

Unabhängig davon, wird gerade durch die Einstufung der persönlichen Rechtefestlegung der einzelnen Nutzer die Vergabe von Zugriffsrechten - sowie auch die Möglichkeit von Zugriffsverboten individuell definiert - um somit unauthentifizierte Zugriffe auf zu schützende Daten überwachen (engl. „auditing") zu können.

Mozilla befolgt diese Vorgaben.

Oliver

http://support.mozilla.com/de/kb/Mozilla%20Absturz-Melder
http://kb.mozillazine.org/Breakpad

Brummelchen erklärte u.A. folgendes:

Zitat

Um auf deine Frage zu antworten - vermutlich die, die die reguläre Wartezeit
von VeriSign mit allen Vor- und Nachteilen nicht bezahlen und gehen wollen.

Zustimmung.

Nur SSL-Zertifikate werden - meinen Informationen nach - darüberhinaus bereits schon wertbezogen an der „Börse“ gehandelt - bzw. gewinnbringend weiterverkauft.

Microsofts „Authenticode“ > „VeriSign“.

Microsoft arbeitet - meines Wissens nach - u.A. mit dem SSL-Authentifizierungssystem „VeriSign“ als suborientierte (untergeordnete) Zertifizierungsstelle zusammen, wobei im Zuge „VeriSigns" obendrein noch zwischen privaten und kommerziell ausgestellter Zertifikate unterschieden werden muss.

Das muss man sich einmal auf der Zunge zergehen lassen. Es gibt Zertifikate mit unterschiedlichen materiellen „Wert“!!!

Sofern für zwei unterschiedlich ausgestalteter Zertifikatsqualifikationen (also privat / kommerziell) wiederum unterschiedlich aufwendige Identitätsnachweise geführt werden müssen so wird - meiner Beurteilung nach - die Gesamtheit des vertraulichen Authentifikationsverfahrens digitaler Zugänge schlussendlich in ein „ad absurdum“ geführt.

Oliver

http://heise.de/security/meldu…es-1212986.html

Wer v Was ist Comodo?

Wer benötigt darüberhinaus solche individuell ausgestellten Zertifikate, die noch nicht einmal „Root“ sind?

Oliver

[O.T.]
Der Aufbau solcher sicherheitsrelevanten digitalen Infrastrukturen (über Zertifikate) sind grundsätzlich problematisch, da der sog. „Vertrauensanker“ (das engültige Zertifikat im Browser) bereits schon über den „Validierungspfad“ (die Zertifikatskette) selber kompromittiert sein kann.

Am besten, man vertraut überhaubt keinem Zertifikat.

Guten Morgen Ihr Lieben,

sofern mir so ein Urteil überhaupt zusteht - So vermisse ich gegenüber den aktuellen Ereignissen in Japan in diesem Forumsbereich einige relevante Beiträge.

Es kann z.B. eigentlich nicht sein, dass die lokale Fussballthematik (z.B. Borussia vs. Dortmund) in diesem Forumsbereich (Smalltalk) einen höheren Stellenwert einnimmt, als die vorangegangenen Ereignisse in Japan – welche vermutlich in Konsequenz langfristig auch Germany wirtschaftlich negativ zu beeinflussen vermögen.

Darüberhinaus ergab sich im Diskussionssektor dieses intelligenten Forums in der Vergangenheit einmal eine sehr interessante Wechselrede in Bezug auf AKW´s gegenüber dem Aspekt der alternativen Energieerzeugung die – meiner Meinung nach - dazu führen sollte - inwieweit führende Export-Nationen – nach heutigem Erkenntnisstand – noch auf Atomenergie angewiesen sein sollten...

Ich musste meine Meinung diesbezüglich teilweise revidieren.

Ich kann mich irren – jedoch fördert Germany – meiner Ansicht nach – diesbezüglich eine Art themenbezogene protektionistische „Kokonpolitik“, da die "Wahrheit“ über die aktuelle seriöse deutsche Tagespresse teilweise gesucht werden muss – bzw. z.T. nicht immer den internationalen Pressemitteilungen entspricht.

Hoffentlich sind wir international i.d.L. aus dieser Katastrophe zu lernen. Das sind wir den Opfern schuldig.

„Bild“ und „MoPo“ führen diesbezüglich scheinbar nicht viel weiter, sondern fördern darüberhinaus - meiner Meinung nach - eher bloss eine Form von nationaler „Borniertheit“.

Oliver

Zitat

Ich möchte mich mit meinem dienstlichen Laptop in das Netzwerk meines Arbeitgebers einschalten, um (von) zu Hause (aus) arbeiten zu können[...]

Die Frage ist verdammt schwer zu beantworten, da Unternehmensnetzwerke bezüglich ihres betrieblichen Risikos solcher vertraulichen Fernzugänge i.d.R. unterschiedlich gesicherte Authentifikationsmassnahmen verwenden.

Zitat

a. Welches Betriebssystem benutzt Du?

b. Wird eine proprietäre VPN-Lösung eingesetzt?

c. Musstest Du bisher überhaupt eine VPN-Software auf dem lokalen Endgerät (Deinem Notebook) installieren?

d. Ist Dein Router darüberhinaus i.d.L. „Portwarding“ (Portweiterleitung) zu betreiben?

e. Werden obendrein für die vertraulichen Zugänge „Tokens“ als sog. „Ethernet to token-ring bridging“ eingesetzt?

Soweit ich es bisher überhaupt zu beurteilen vermag müssen – innerhalb des einfachen Zugangsverfahrens – bloss die Proxy-Server Einstellungen des Unternehmensnetzwerkes mit der entsprechenden Portzuweisung im Netzwerk-Dialog des Firefox-Browsers eingetragen werden. Die IP-Adresse kann unter den Windows-DHCP-Einstellungen weiterhin automatisch bezogen werden.

Firefox:
Extras > Einstellungen > Erweitert > Netzwerk > Einstellungen >>> „Manuelle Proxy-Konfiguration“ einen Zugangs-Proxy (mit Portadresse) eintragen, um für alle weiteren Übertragungsprotokolle von Relevanz zu sein, die über diesen Server und unter dieser Port-Adresse geführt werden dürfen. Die Sicherheit weiterer Zugriffe auf Daten, würde dann auf einem passwortgestützten Authentifikationsverfahren des Zugangsservers selber aufsetzen. Dieses Verfahren ist jedoch als unsicher zu betrachten.

Sofern Du jedoch einen „Remote-Access-VPN“ (vertraulichen Fernzugriff über das ungesicherte Netz) mittels IP-Sec-Passthrough-Verfahren betreiben möchtest, müsste Dein Router (z.B. als IPSec-Gateway) dieses Verfahren und diese Vertrauensstellung unterstützen können.

Ein paar weiterführende Informationen Deinerseits könnten nützlich sein...

Oliver

Keicy fragte u.A. Folgendes:

Zitat

[...]Kennt nicht doch irgendwer nen (ein) Tool, AntiViren Programm oder sonstiges womit man diese Datei (wlcomn.*) wieder loswird.....?[...]

Unabhängig Deiner Anfrage - Achte einmal auf die Namens-Endung (nicht die Suffix) dieser Datei.

„wlcom(m)..*“ steht (als authentifizierter Microsoft-Prozess) scheinbar einer trojanisierten (gefälschten Version): „wlcom(n).*“ gegenüber, die jedoch mit dem ursprünglichen Microsoft-Systemprozess bloss die ersten fünf Buchstaben gemein hat. Die Ähnlichkeit der latein-alphabetischen Zeichen (m und n) entspricht – meiner Ansicht nach – als Maskierungsangriff dieses ursprünglichen MS-Dienstes dennoch einer sehr trivialen (einfachen) technischen Kompromittierung, der sich auf einfache Weise habhaft werden lässt.

Um sich dieses trojanisierten Prozesses wieder zu entledigen reicht es – meinen Informationen nach - die in die Ausführungsumgebung (also die in die Windows-Registratur) eingespeisten Informationen erfolgreich zu entfernen. Gehe dazu vor wie folgt:

Zitat

a. Lade Dir das Freeware-Programm „Regseeker“ herunter und installiere es. (Download-Verlinkung s.u.).

b. Starte die Applikation und stelle im Anschluss daran in der obigen Suchfunktion den String der Datei (wlncomn.*) ein.

c. Lösche die gefundenen Einträge.

d. Reboote Deinen Computer.

e. Lösche daraufhin die „Executable“ dieses Prozesses im Verzeichnis: C:\WINDOWS\wlcomn.exe, da diese Datei sonst über ihren eigenen Prozess-Zugriff „gelockt“ (gesperrt) wäre.

Sofern Dein Computer jedoch bereits schon im Vorfeld kompromittiert wurde, empfiehlt sich eine Neuinstallation (kein Image).

Achte allgemein darauf, dass die Verlässlichkeit (engl. „dependability“) Deines Computer-Systems keine unzulässigen Zustände annehmen darf - und dass obendrein bestehende Funktionen auf diesem System zuverlässig (engl. „reliability“) erbracht werden.

Verlässlichkeit < > Zuverlässigkeit

Das sicherste Computer-System ist das ohne Daten...

Oliver

http://www.download3k.com/DownloadLink1-RegSeeker.html

worel erklärte Folgendes:

Zitat

Die Datei dumprep.exe (11kB) scheint mir aber vertrauenswürdig, da sie eine
"Microsoft Windows" Signatur, und eine Versionsnummer hat.

Unter dem registrygeführten Aufruf "dumprep.exe" werden unter Windows XP Fehlermeldungen des Betriebssystems protokolliert, die u.U. zur einer erheblichen Verlangsamung (engl. slowdown) der Verarbeitungssequenzen führen können. Dieser MS-Prozess ist somit zwar als vertrauenswürdig – jedoch bezüglich einer wie auch immer gearteten Kompromittierungen – als irrelevant zu betrachten. Es müssten dennoch in den Run-Verfügungen Deiner Registry noch weitere „verdächtige Einträge“ existieren.

Ohne es böse zu meinen, aber gehe bitte auf die ursprünglich von Dir gestellte Grundthematik ein – sonst kommen wir hier nicht weiter.

a. Existiert auf Deinem System eine wie auch immer geartete und veränderte wlanmon.*?

b. Wird in den Run-Keys der Registry u.A. ein Prozess gestartet, der mit Zahlenzeichen beginnt und mit *. exe endet?

Nochmalig – Es können keine zwei gleichnamige Prozesse gleichzeitig auf einem lokalen System (also auf Deinem Computer) nebeneinander existieren. Bei dll Bibliotheken ist dies jedoch möglich.

worel erklärte darüberhinaus Folgendes:

Zitat

[...]Durch welchen fiesen Trick wird eigentlich erreicht, dass die Fake-DLL beim Start
des Firefoxbrowsers so fest eingebunden wird, und für den Start unentbehrlich ist?
-Eine DLL namens wlanmon.dll gehört von Haus aus **sicher nicht** zu Firefox dazu![...]

Nein. Applikationen sind standardmässig nicht fest an solche externen dll-Bibliotheken gebunden. Anwendung greifen bloss darauf zu. Somit kann der Firefox (wie jede andere Anwendung auch) über den sog. LoadLibrary-Aufruf auf eine bereits kompromittierte *.dll Datei zuzugreifen, sofern über das Betriebssystem der sog. safe DLL search mode im Vorfeld nicht aktiviert wurde. Dies ist eher eine alte Windows-Vererbung als eine neue Firefox-Geschichte.

Unter Windows XP (ohne SP2) ist diese gesicherte DLL-Einstellung z.B. standardmässig deaktiviert. Diese Einstellung liesse sich jedoch durch einen modifizierten Eintrag SafeDllSearchMode in der Windows-Registry nachträglich rehabilitieren.

Schaue Dir einmal die Werteausführungen des Process Monitors auf Deinem lokalen System an. (Downloadlink s.u.). Setze zur vereinfachte Veranschaulichung der Ausgabe die entsprechenden Filter.

Oliver

http://msdn.microsoft.com/en-us/library/ff919712(VS.85).aspx
http://download.sysinternals.com/Files/ProcessMonitor.zip