Beiträge von Oliver222

Meerwind stellte folgende Rückfrage:

Zitat

[...]Da sie, (die zu blockierenden Seiten), danach immer noch erschien(en), habe ich sie in der Hosts-Datei ohne Endung auch noch mal eingetragen und zwar mit dem Zeichen # vorne dran.

Wozu die zusätzliche Raute (#)? So eine Syntax (Zeichenfolge) ist in der HOSTS-Datei nicht vorgesehen (siehe obigen Kommentar: PvW). Unabhängig davon, kann auf Windows-Systemen nur eine einzige HOSTS-Datei residieren. Diese wird entweder aufgerufen und bearbeitet (über z.B. Notepad) oder über ein externes Programm produziert und konfiguriert (wie z.B. HostsXpert). Das Resultat bliebe dennoch das Gleiche. Dabei gilt:

a....es existiert nur eine einzige HOSTS, und zwar,

b....ohne Endung abgespeichert (also ohne *.txt, doc, etc.),

c....mit den korrekten Inhalten,

d....im dafür dedizierten (Windows-ME) Ordner: c:\windows\hosts.

Meiner Ansicht nach wärest Du dabei gut beraten, Dir zur Erstellung und Bearbeitung solcher neuen Listeneinträge HostsXpert weiterhin zunutze zu machen, sofern es auf Deinem System problemlos funktionieren sollte.

Zitat

127.0.0.1 http://www.affaire.com
127.0.0.1 affaire.com

Die Syntax ist korrekt. Ordne daher weitere zu sperrende Seiten nach diesem Schema zeilenorientiert - und zwar nach Domains sortiert - untereinander an.

Oliver

intoxic8ed,

als Antwort auf Deine PM,

Du speicherst Deine signons.txt separat ab, um somit Deine dortig gespeicherten PW´s - und zwar unabhängig von Neuinstallationen des FF´s - jeweils unkompliziert in den neuen Browser integrieren zu können, sofern ich Dich hier richtig verstanden habe.

Tatasache ist jedoch dass - nach meinen bisherigen Informationen - der FF inzwischen intern die Zeichenkodierungen aus Sicherheitsgründen anders verwaltet, als noch in den vorhergehenden FF-Versionen.

Damit die alten Inhalte der "signons.txt" in die neuen FF-Versionen integriert werden können, müsste somit das Zeichenkodierungs-Format - meiner Ansicht nach - beim Aufrufen und Abspeichern auf UTF-8 abgeändert werden.

Microsoft Windows bringt zwei Editoren mit, welche dazu i.d.L. sind:

* WordPad
* Notepad (alias Microsoft Editor)

In Editor einfach "Datei" > "Sichern unter" auswählen und im dann erscheinenden Dateiauswahldialog die Codierung: "UTF-8" einstellen.

In Wordpad verhält es sich ähnlich: "Datei" > "Sichern unter" > "Dateityp": "Unicode-Textdokument" auswählen.

Lasse uns diese Diskussion bitte öffentlich weiterführen...

Oliver

Meerwind stellte dar:

Zitat

auf meinem Rechner existiert unter Windows eine "hosts.sam"-Datei, die ich nicht öffnen kann, da es eine unbekannte Anwendung ist[...]

Aus Deiner Antwort lässt sich entnehmen, dass es Dir an grundlegenden Systemkenntnissen mangelt. Macht nix

Bei Zugriffen auf noch unbekannte Datei-Endungen (i.d.F. die HOSTS-Datei), müsste bei Dir eine Dialog-Box erscheinen, welche zuerst eine Zuordnung zu dem jeweiligen Programm erfragt, mit welchem Du diese Datei dann öffnen, bzw. auch bearbeiten kannst.

Ein Linksklick auf die noch unbekannte HOSTS-Datei, müsste bei Dir am Mauszeiger ein Kontextmenü mit: Öffnen mit... verursachen. Suche anschliessend unter lokalen Anwendungen das Notepad als Programm zum Öffnen und Bearbeiten dieser HOSTS-Datei heraus. Gehe dann im Anschluss der weiteren Bearbeitung so vor, wie bereits schon oben beschrieben wurde und speichere dann diese neue HOSTS-Datei ohne Endung ab (wie bereits von Estartu beschrieben).

Versuche es - zwecks Bearbeitung dieser verdammten HOSTS - noch einmal mit untenstehenden Link. Mein obiger Link war dagegen irreführend.

Oliver

http://www.funkytoad.com/download/HostsXpert.zip

Meerwind erklärte:

Zitat

[...]Könntet ihr mir evtl. nochmal GENAU Schritt für Schritt erklären, was ich tun kann?[...]Und wie gesagt, Windows ME und einen 7 Jahre alten Rechner.[...]

Sofern lokale Proxylösungen, bzw. FW-Definitionen aus wie auch immer gearteten Gründen für Dich nicht realisierbar sein sollten, überprüfe einmal, ob bei Dir unter Windows-ME eine C:\Windows\hosts Datei existiert, deren Inhalt lautet wie Folgt:

Zitat

# Copyright (c) 1993-1999 Microsoft Corp.
#
# Dies ist eine HOSTS-Beispieldatei, die von Microsoft TCP/IP
# für Windows 2000 verwendet wird.
#
# Diese Datei enthält die Zuordnungen der IP-Adressen zu Hostnamen.
# Jeder Eintrag muss in einer eigenen Zeile stehen. Die IP-
# Adresse sollte in der ersten Spalte gefolgt vom zugehörigen
# Hostnamen stehen.
# Die IP-Adresse und der Hostname müssen durch mindestens ein
# Leerzeichen getrennt sein.
#
# Zusätzliche Kommentare (so wie in dieser Datei) können in
# einzelnen Zeilen oder hinter dem Computernamen eingefügt werden,
# aber müssen mit dem Zeichen '#' eingegeben werden.
#
# Zum Beispiel:
#
# 102.54.94.97 rhino.acme.com # Quellserver
# 38.25.63.10 x.acme.com # x-Clienthost

127.0.0.1 localhost

Alles anzeigen

Öffne anschliessend diese Datei zur Bearbeitung mit dem Notepad, oder benutze zur Erstellung und Bearbeitung solcher Datei "HostsXpert" (Link s.u.).

Um jetzt eine Internet-Domain durch Einträge über diese Datei zu sperren, ist es notwendig, solche zu sperrenden URL´s einmal mit und ohne WWW-Präfix neben der Schleifenschaltung (127.0.0.1) einzutragen. Trage daher die zu sperrenden Seiten jeweils untereinander in neue Zeilen ein, und zwar mit der notwendig vorgelagerten Loopback: 127.0.0.1.

Für eine Sperrung dieses Firefox-Forum würde das ganze dann z.B. so aussehen:
127.0.0.1 http://www.firefox-browser.de/forum/.de
127.0.0.1 http://firefox-browser.de/forum/.de

Diese Syntax begründet sich in der Tatsache, dass der Eintrag "http://www.firefox-browser.de/forum/.de" somit auch dann in der HOSTS-Liste ignoriert wird, sofern man bloss "firefox-browser.de" aufruft und umgekehrt. Diese Vorgehensweise bewirkt, dass der Browser beim Aufruf nicht mehr den DNS-Server nach der IP-Adresse der Seite selber befragt, sondern dieser Webseite somit direkt der IP: 127.0.0.1 (Localhost) zuordnet, was somit ins digitale "Nirwana" (also zur Sperrung) führt.

Beachte dabei jedoch, dass das obige Hosts-Bearbeitungs-Verfahren auch mit Nachteilen verbunden sein könnte, (welche für Dich vermutlich nicht von Relevanz sein dürften), wie z.B.:

a.Reine (numerische) IP-Adressen werden nicht gefiltert.

b.Die Sammlung (Listung) der unerwünschten Domains ist den gewünschten Zieladressen (Subdomains) stets kategorisch anzupassen.

c.Das grafische Layout einiger Webseiten könnte "verzerrt" dargestellt werden.

Oliver

http://files1.majorgeeks.com/files/45efb537…/HostsXpert.zip
http://de.mcafee.com/common/de/redirects/mpfp/userguide.asp
http://de.wikipedia.org/wiki/Hosts

Meerwind fragte:

Zitat

[...]leider kann ich den fox filter nicht installieren, weil ich ein Windows ME drauf habe.[...]

Clientseitig (also lokal) liesse sich bei Dir bereits schon auf Systemebene die Windows ME-Hosts-Datei bearbeiten, um solche unerwünschten Webseiten zu sperren. (Pfad unter Win 98\ME = C:\WINDOWS // bzw. %Systemroot%). Trage dort die jeweiligen restriktiven Domains ein. Dieses Verfahren ist allerdings mit Vor - bzw. Nachteilen verbunden:

Vorteile:

a.Greift bei allen Windows-Browsern. (Durch "Hosts-Priority" / "Hosts-Vorrang" und zwar noch vor dem jeweiligen Browser und kann somit auch nicht "ausgehebelt" werden, sofern Du die Zugriffsrechte dieser Hosts-Datei unter Windows im Vorfeld bereits geregelt hattest, was unter Windows-ME allerdings nicht möglich ist).

b.Die Zuordnungen der jeweiligen IP-Adressen (Domains) liessen sich für Dich obendrein bequem durch ein eigenes Script - und zwar über Auswahldialoge für solche Domains - jeweils unkompliziert in die Hosts-Datei einbinden, um somit Sperrungen, bzw. Umleitungen festzulegen.

Nachteile:

a.Es lassen sich in der Hosts-Datei bloss einzelne übergeordnete Domains sperren. Derivate, bzw. DNS-Delegierungen solcher Domains, müssten dann einzelnd in der Datei separat und untergruppiert ausdefiniert werden. (Durch Einspeisung der einzelnen Subdomains in die Hosts).

b.Der "Berechnungsaufwand" (also Zeit und Energie) so eines Systems, welches durch Zugriffe auf die zunehmenden Einträge so einer wachsenden Hosts-Datei zurückgreifen muss, steht m. A. nach in keinem proportionalen Verhältniss mehr zu separat verfügbaren Browser-Programmen, welche die Handhabung solcher Domain-Sperrungen wesentlich "effizienter" verwalten können.

Ansonsten erreichst Du eine wirkungsvolle Sperrung solcher Webseiten u.A. über die Konfiguration Deiner Firewall (Router), oder durch den Einsatz lokaler Proxies (z.B. Proxomitron, Squid, etc.), welche Du in den FF einbindest.

In Bezug auf solche HTTP-Sperrungen (und der Möglichkeit der Umgehungen) gilt dabei in hierarchischer Reihenfolge:

Externer Router > Lokales System (z.B. Windows-Firewall / Windows-Hosts / lokaler Proxy) > Browser-Programm (Erweiterung).

Oliver

intoxic8ed stellte Folgendes dar:

Zitat

[...]bislang gehe ich immer so vor, dass ich eben diese daten sichere und fx deinstalliere und den mozilla-ordner in den anwendungsdaten lösche.

Bist Du als Admin an Deinem System angemeldet? Nach meinen bisherigen Erfahrungen, besteht ein kausaler Zusammenhang zwischen den individuellen XP-Benutzerkonten und den damit verbundenen Ordnern: "Dokumente und Einstellungen" (also den Anwendungsdaten). Im Windows-Explorer wird in "Dokumente und Einstellungen" i.d.R. noch ein weiteres Benutzerkonto: (Administrator) dargestellt. Dieses Konto ist jedoch nicht mit dem Benutzerkonto des eigentlichen Computer-Administrators identisch. Der Zugriff darauf ist daher gesperrt und somit bloss im "Abgesicherten Modus" möglich.

intoxic8ed erklärte:

Zitat

[...]beim versuch die key-dateien zurückzukopieren klappte es zwar auch, nur dass sie im browser nunmal eben nicht angezeigt wurden.

Das "Re-Importieren" bisheriger PW´s aus einer alten "signons3.txt" heraus in eine neue FF-Umgebung hinein, beschränkt sich - meiner Ansicht nach - eher auf eine Inkompatibilität der zu verarbeitenden Zeichensätze selber, als auf einem "Fehler" in der Sache an sich. Der FF neigt sich - nach meiner bisherigen Einschätzung - daher dem UTF-8 Standard zur Darstellung von sprachspezifischen Zeichen eher positiv entgegen und ersetzt somit die vorher benutzten HTML-Sonderzeichen, welche ja als bisherige PW-Kodierungen zur Anwendung kamen.

Versuche einmal die alte signons3.txt (unter Anwendungsdaten) mit dem Notepad zu öffnen und speichere diese Datei dann im Anschluss unverändert - bloss unter dem UTF-8 Standard (statt ANSI) wieder ab. Daraufhin den FF neu starten...

Melde Dich nochmal zurück...;)

Oliver

Anna Conda erklärte:

Zitat

Wir (und vermutlich tausende Admins anderer Hochschulen) warten schon über zwei Jahre darauf, dass das Wurzelzertifikat endlich einmal im Firefox hinterlegt wird.

DFN-PKI gehört - so weit ich hier informiert bin - zu T-Systems (Telekom) und unterscheidet dabei obendrein noch zwischen unterschiedlichen Sicherheitsstufen (z.B. Global = Kostenlos). Sofern solche Zertifikatsverfügungen jedoch in dieser Ausgestaltung nach unterschiedlichen "Klassen" urteilen, sind sie - meiner Meinung nach - nur "bedingt" anwendbar - um nicht zu sagen wertlos!!!

Wer übernimmt - Deiner Ansicht nach - für solche zertifizierten Beglaubigungen die Verantwortung? Wer steht bezüglich des Public Key´s gerade? Eure Fakultät? Vielleicht die Telekom? Vielleicht sogar das TC TrustCenter? Ein spendenorientiertes Open-Source-Projekt? Lächerlich!!!

Es sei denn, das von Dir hier angestossene Zertifikats-Thema würde - in Bezug auf den Firefox - bereits im Vorfeld über "Investoren", und zwar als eine Art geschlossenes "Browser-Zertifikats-Bündel" aufgekauft werden. Nach meiner bisherigen Ansicht, könnte es somit u.U. vielleicht zu zwei Versionen des FF´s in Bezug auf die Antragserstellung solcher Zertifikate kommen. (Kapitalisierte Version, vs. Freie Version). So eine Verfahrensweise war in der Historie der IT definitiv bisher nichts Neues...

Wissenvermittlung (durch Hochschulen) und Geldgeschäfte sind - meiner Ansicht nach - immer noch sehr getrennt zu behandelnde Themen.

Oliver

intoxic8ed erklärte:

Zitat

[...]musste wieder mal FF neu installieren, [...]mit den pw's hats aber diesmal nicht geklappt,[...]

Du solltest hier mehr Angaben machen.

Ganz nebenbei - Benutze generell keinen PW-Manager. Weder browserintegriert (über FF), noch über externe Programme. Halte Deine vertraulichen PW´s daher stets unter pers. (Offline) Verschluss. So bequem, wie es vielleicht zuerst erscheinen mag: Verlasse Dich niemals auf einen digitalen PW-Manager!!!

a.Benutzt Du MozBackup zur Wiederherstellung Deiner alten FF-Daten? Dies könnte u.U. bei der Portierung von vertraulichen PW-Daten auf neuere FF-Versionen Fehler verursachen. (Problem ist bereits bekannt).

b.Hattest Du manuell auf eine neuere FF-Version (z.B. 3.X, mit neuen Profil) gewechselt?. PW´s werden laut ASCII-Zeichensatz - nach meinen bisherigen Erkenntnissen - nicht aut. in die neue FF-Version (3X) mit übernommen. (Problem ist bereits bekannt).

b.1.Sofern Du jedoch noch nicht auf eine aktuelle Version von > FF 3.0.3 upgedatet haben solltest, so gilt - nach meinen bisherigen Informationen - ein Bug (Fehler) in der Handhabung der internen FF-PW-Verwaltung < 3.0.3, und zwar i.B. auf Domain-Namen, welche separate Sonderzeichen enthalten können (siehe b.). (Problem ist auch bereits bekannt).

Melde Dich nochmal zurück

Oliver

http://www.mozilla-europe.org/de/firefox/3.0.2/releasenotes/
http://www.tecchannel.de/sicherheit/new…in_firefox_302/
http://www.pro-linux.de/news/2008/13265.html

Maria Freund fragte Folgendes:

Zitat

[...]Wenn Sie vermuten, dass das angezeigte Zertifikat nicht "update.mozilla.org" gehört, brechen Sie bitte die Verbindung ab, und benachrichtigen Sie den Administrator der Website.

Zertifikate (OCSP) können gefälscht werden. Zertifikate (über SSL und TLS) sind daher - meiner Ansicht nach - quellenbezogen eher als zweifelhaft zu betrachten. Die somit resultierenden Fehlermeldungen können dabei eher verunsichern, als dass sie unbedarften Anwendern einen wahren Sicherheitsgewinn vermitteln.

Update daher Deinen Firefox besser manuell über die originale Webseite (s.u.) und lasse somit während des Installationsprozesses die alten FF-Dateien, innerhalb des OS-Systemverzeichnisses, durch die neuen Daten überschreiben.

Maria Freund fragte anschliessend noch Folgendes:

Zitat

[...]Ist das ein Grund zur Beunruhigung???

Nein.

Verlasse Dich dabei nicht zu sehr auf die Technik. Mathematische Bewertungs-Algorithmen, welche hierbei (quantitativ nicht qualitativ) zur Anwendung kommen, können Deiner individuellen "Bewertungsgewichtung" - und zwar in Bezug auf die Beurteilung solche Webseiten - immer "noch" nichts entgegensetzen...

Oliver

http://www.mozilla-europe.org/de/firefox/
http://www.rrze.uni-erlangen.de/dienste/intern…rtifikate.shtml

PvW stellte dar:

Zitat

[...]Kein ernstzunehmender Teilnehmer wird Deine Angaben ohne
Deine Zustimmung dauerhaft speichern.[...]

Mit Teilnehmern waren die einzelnen User so einer Community gemeint, welche garantiert nicht immer gemäss Datenschutz handeln würden. Sei mal nicht naiv...

Oliver

ulikabuli erklärte:

Zitat

[...]beendete ich mein Mitgliedschaft in dem Forum wieder, weil ich erkannte, daß jedermann meine Daten (z. B. Vor- & Zuname, Geburtsdatum etc.) einsehen konnte.

Deine pers. Daten befinden sich innerhalb eines Forums??? Vielleicht noch ein paar mehr Angaben von Dir? Handelt es sich dabei um ein Social-Network? (z.B. Facebook, Twitter, etc.?) Mich würde dabei obendrein Folgendes interessieren:

a.Hattest Du bloss im Zuge der Anmeldung für dieses Forum Deine persönlichen Daten hinterlassen müssen?

b.Hattest Du dagegen Deine pers. Daten (Name, Anschrift, etc.) im System vielleicht etwas vorbehaltlos anderen Teinehmern offenbart?

Sollte es sich dabei um a. handeln, so würde der Datenschutz des Forums greifen. Sollte es in Deinem Falle jedoch b. sein, so würde ich mir an Deiner Stelle ernsthafte Gedanken machen. Du kannst zwar die Bezüge zu Deinen im Forum bereits bekanntgegebenen Daten durch eine erneute Registration (mit Log-In) neu gestalten - jedoch würde das nichts an der bisherigen Offenbarung Deiner pers. Daten im I-Net andern können, welche stets unter Verschluss gehalten werden sollten.

a.1Testweise ein neues Profil versucht?

b.1Lösche das Cookie, sowie die alten Formulardaten für dieses Forum von Hand. (Danach FF erneut starten und Log-In anschliessend erneut abspeichern).

c.1.Editiere bzw. suche zuerst nach der "key3.db" und der "signons.txt" im Profilverzeichniss. (signons.txt erforderlich).

d.1.Überprüfe mit dem Button: "View Saved Passwords", ob Deine Passwörter und die entsprechende Zuordnungen stimmen.

Alles nichts Neues...

Oliver

G. Hulk hat Folgendes geschrieben:

Zitat

Falls ich den Beitrag von Oliver mal ins Deutsche übersetzen darf: Er hat studiert und gelernt sich unverständlich auszudrücken.[...]

Werde mir Deinen Beitrag zu Herzen nehmen. Unverständlichkeit bringt uns hier nicht weiter.

Nur - Wie versucht man jemanden die Funktionen von z.B. "Header-Daten" nahezubringen, der bisher noch nicht mit dem "HTTP-Protokoll" - zur Basis - selber in Berührung kam? Eine gewisse Terminologie (Fachausdrücke) (und vor allem Lernen) ist dabei erforderlich.

Darüberhinaus gibt es innerhalb dieses Forums - nach meiner bisherigen Einschätzung - definitiv einige hilfsbereite Teilnehmer, die verdammt "was auf dem Kasten" haben.

[OT]Was dagegen Deine Andeutung auf das Studieren selber (vermutlich über die deutsche Regelstudienzeit) angehen sollte, so ist Studieren in Germany - meiner Ansicht nach - inzwischen leider, trotz der s.g. Bildungsoffensive hinsichtlich des akademischen Generationsgefälles und der damit einhergehenden Chancenungleichheit zwischen Alt und Jung, fast schon zu einer Art Luxusgut avanciert...

Oliver

Road-Runner stellte Folgendes dar:

Zitat

[...]Das (eine System-Formatierung) ist auf jeden Fall die sicherste Alternative, um diesen Mist los zu werden.

Volle Zustimmung - unter der Voraussetzung, dass das jeweilig neu eingerichtete System - und zwar in Hinblick auf gleichartige oder zukünftige Bedrohungen hin - bestmöglichst abgesichert wird.

Frage wäre nur: Wie wirksam kann dabei - gerade in Bezug auf heutige sog. Recovery-Partitionen hin - eine Formatierung eigentlich noch sein?

Neuartige Malware (z.B. Rootkits) ist inzwischen - nach meinen bisherigen Kenntnissen - bereits durchaus i.d.L., partitionsübergreifend und somit auch unabhängig der jeweiligen "Ablageorganisation" (also des jeweiligen Datei-Systems), "negativ" auf den Wiederherstellungsprozess aus solche Daten-Repositories (Daten-Bunkern) hin einzuwirken.

Eine Formatierung "auf Metall" im ursprünglichen Sinne, wird dabei - nach meiner Meinung - eigentlich immer seltener...

Oliver

user983475934 erklärte:

Zitat

Auf das eigene Benutzerkonto hat ein normaler eingeschränkter Nutzer (also eigenes Benutzerkonto) immer Zugriff,[...]

Diesbezüglich hast Du Recht! Ich glaube dennoch, wir sprechen hier leider von zwei verschiedenen Dingen. Dabei geht es - meiner Ansicht nach - nicht alleine darum, wer auf Dein bereits eingeschränktes System-Konto gleichzeitig zugreifen kann und darf, sondern was Dir über solche übergeordneten und administrativen Gruppenrichtlinien-Verfügungen an Zugriffen (z.B. in Firmen) zuteil wurde. Verwechsele diesen Umstand daher nicht mit einem bei Dir zu Hause installierten Windows-System, innerhalb dessen Du vermutlich per Installation ohnehin als Admin für Dich selber, unter eingeschränkten Rechten, arbeitest. Auf so einem System gilt im allg. - meiner Meinung nach - stets so etwas wie: "Master and Servant". Theoretisch lässt sich daher jedes Windows NT-Derivat über Richtlinien und NTFS-Rechte - und zwar in Bezug auf die Gpedit.MSC - dahingehend einmauern, so dass untergeordnete Anwender somit wenig bis gar nichts mehr dürfen und Schädlinge kein Schlupfloch mehr finden.

user983475934 fand heraus:

Zitat

Doch der Zugriff auf das Benutzerverzeichnis (%USERPROFILE%) ist schreibend. Andernfalls könnte Firefox nicht mal die Einstellungen speichern.

Welche Einstellungen? Noch einmal: Der FF ist (bloss) ein Programm. Er muss sich daher genau jenen Einschränkungen "beugen", welche Du unter Windows, und zwar im Zuge der Kontenvergabe, im Vorfeld, bereits ausdefiniert hattest. Du könntest daher unter Windows den FF auch insoweit einschränken, so dass dieser nicht einmal mehr schreibend eine Historie im Cache anlegen - geschweige denn Nutzer-Einstellungen - übernehmen darf.

Sowohl die Authentisierung (über die System-Konten), wie auch die Zugriffssteuerung (über NTFS / EFS) sind dabei - nach meinen bisherigen Erfahrungen - zwei unterschiedlich zu behandelnde Aspekte der allgemeinen System-Sicherheit, an welcher Verwalter und Benutzer somit für jedes mögliche Niveau der Wirksamkeit auch gleichmäßig teilnehmen müssen. Verwechsele dabei bitte nicht, dass Du als Verwalter somit durchaus auch untergeordneten Nutzern zeitlich begrenzte Privilegien erteilen dürftest.

user983475934 erklärte abschliessend:

Zitat

cacls "C:\Dokumente und Einstellungen\Administrator" /T /E /G Jeder:F

Über CACLS werden bloss hoher gestellte Benutzerrechte zugewiesen. Diese "entstehen" somit nicht automatisch, s.o..

[OT]Deine bisher hier dargelegten Argumente rechtfertigen - meiner Ansicht nach - ganz bestimmt noch nicht den Einsatz einer VM.

Oliver

http://technet.microsoft.com/en-us/library/cc758691.aspx

mike1234 erklärte:

Zitat

In der letzten Ausgabe vom ComputerBild??? stand, wie man die Datenschutzfunktionen in FF einschaltet.

Gilt ComputerBild für Dich als technische Referenz?

Du offenbarst im Internet - unabhängig des eingesetzten Browsers - immer auch anonyme, systembezogene Daten. Das lässt sich leider nicht ganz vermeiden, um wiederum Daten von der Gegenstelle (also dem Server) zu erhalten. Es müsste dabei - meiner Ansicht nach - immer noch gelten müssen:

a.Der sog. Zielkonflikt. Also das allgemeine Verhältniss zwischen "Geben und Nehmen", und zwar in Bezug auf den sog. Digital Handshake. Zwischen der Browseranfrage und dem angesprochenen Ziel-Server, gelte somit bei einer "minimalen Anfrageverfügung" durch so einen Browser, stets auch ein "serverseitiges Maximum" an übertragbaren Daten, welche für Dich "auszuschöpfen" wären. Dabei gelte dann das Gefälle: So viel Daten wie nötig (to Server) - so wenig Daten wie möglich (from Client).

b.Einen Browser, welcher es Dir bereits über seine individuellen Konfigurationsmöglichkeiten gestattet, Einfluss auf die Übertragung einzelner Metadaten zu nehmen.

c.Darüberhinaus der Einsatz externer HTTP(Header)-Filter, (also lokaler Proxie-Filter), welche in den Browser integriert werden können und somit zusätzliche Metadaten aus der Browser-Anfrage für Dich herausfiltern könnten. (Bis der Server dann, auf Grund Mangels an übertragener Header-Daten, nicht mehr antworten kann).

Was die "browserseitige Selektion solcher Header-Daten" selber angeht, so sind die Open-Source-Projekte (z.B. FF / K-Meleon, etc.) - meiner Ansicht nach - den Browsern wie Opera und IE bereits weit voraus. Bezüglich der Übertragung solcher Umgebungsvariablen durch so einen Browser, müsste somit eine Hierarchie gelten wie folgt:

Vorherige Webseite (Referrer) < Sprache (en-us,en;q=0.5) < Browser und Betriebsystem < Hostname (bereits über die jeweilige IP dedizierbar) < Maschinen-(IP)-Adresse (Kennung des Computers im Netzwerk selber; u.U. Personenbezug).

Der FF kann daher bloss einen Bestandteil Deiner hier angeführten Problematik darstellen. Er ist jedoch nicht das Problem...

Oliver

http://www.zendas.de/service/browserdaten.html
http://www.meb.uni-bonn.de/html_tutorial/tebd.htm

user983475934 fand heraus:

Zitat

[...]Genau daran lag es. Auf mein Profilverzeichnis hat nun "Jeder" Lesezugriff und schon startet der Firefox mit eingeschränkten Rechten.
Firefox ist in dieser Hinsicht schlampig programmiert. Der Fehler, dass auf das Benutzerprofil nicht zugegriffen werden kann, hätte abgefangen werden müssen.[...]

Keine voreiligen Schlussfolgerungen. Darüberhinaus bitte die Kausalität zwischen dem jeweilig eingesetzten OS und Firefox einhalten. Es gilt bezüglich der Hierarchie - nach meinen bisherigen Erfahrungen - immer noch OS > Programm (FF). Somit könntest Du auf Deinem System, z.B. über den Aufruf der Kommandozeilenebene (unter Windows): runas /user:%COMPUTERNAME%Administrator %1 eine beliebige Anwendung im Kontext eines anderen Benutzers zur Ausführung bringen, um dieser Applikation dann den einmaligen Zugriff auf Dein eigentliches Heimatverzeichnis zu gewähren. (z.B. über eine im System abgelegte Batch-Datei). Nur, was hat so eine eingeschränkte OS-Verfügung mit dem FF selber zu tun?

Sofern Du jedoch Win2000/NT/XP im Vorfeld dieser Diskussion auf ein FAT32 Datei-System hin ausgerichtet haben solltest (also kein Journaling Filesystem (NTFS)), wird mir einiges klar...

user983475934 erklärte dann Folgendes:

Zitat

[...]Ein normales eingeschränktes (Windows)-Benutzerkonto hat nämlich Zugriff auf das Profilverzeichnis.[...]

Lesend - dagegen nicht schreibend. Genausogut hätte ein Virus somit auch nur lesend auf Deine Systemdatei(en) Zugriff, jedoch - im Zuge solcher OS-Konten-Einschränkungen - definitiv keine Schreibrechte auf Deinem System.

user983475934 stellte Folgendes dar:

Zitat

[...]Den Firefox in einer virtuellen Maschine laufen zu lassen bringt einen enormen Sicherheitsgewinn.[...]

Einen enormen Sicherheitsgewinn würdest Du genau dann verbuchen, wenn Du Deine Nase in die Bücher steckst und somit dazulernst. Ein im Vorfeld bereits "hermetisch" abgesichertes OS "spottet" dabei - meiner Ansicht nach - jeder Sandbox. Es sei denn, Du testest neuartige Viren auf ihre möglichen systemspezifischen Auswirkungen hin.

Oliver

user983475934 fand Folgendes heraus:

Zitat

Zitat:
File system (assuming NTFS): The app cannot access the user’s profile directory at all. That includes “My Documents”, “Temporary Internet Files”, “Cookies”, etc.
Genau daran lag es. Auf mein Profilverzeichnis hat nun "Jeder" Lesezugriff und schon startet der Firefox mit eingeschränkten Rechten.

Die von user983475934 erstellte Antwort, muss man sich - meiner Ansicht nach - langsam auf der Zunge zergehen lassen. Was für ein Wiederspruch in sich...

Systemverfügung (OS) > Datenformat (NTFS / FAT32) > Program (z.B. Firefox), dabei gilt: NTFS > FAT32. (Abwärtskompatibilität). Worüber reden wir hier eigentlich?

Der von boardraider verlinkte Beitrag ist - meiner Ansicht nach - definitiv weiterführend. Dieser Link wurde von Dir (user983475934) jedoch bedauerlicherweise missverstanden (und zwar in Bezug auf die sog. "Restricted Tokens", bzw. die "SID´s" (Security Identifiers)). Dabei gilt - nach meinen bisherigen Informationen - dass die Security Identifiers" (SID´s), als einzelne Programm-Prozesse, den vom System vergebenden sog. Access Tokens (also den User-ID´s) unterstehen. Solche "Access Tokens" werden bereits beim "Log-On" in das OS selber vergeben. Aus dieser Kombination von Berechtigungskontrollen (DACL) - und zwar zwischen den einzelnen A. Tokens und den zugehörigen SID´s (also den jeweiligen Prozesseigentümern) kann es - meiner Meinung nach - systemtechnisch zu "Fehleinschätzungen" und zwar bezüglich der einzelnen Zugriffsrechte kommen. Diese Problematik kann jedoch nicht vom FF alleine ausgehen - sie ist meiner Einschätzung nach dagegen eher systemgebunden...

Oliver

http://msdn.microsoft.com/en-us/library/aa379596(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa379316.aspx
http://technet.microsoft.com/en-us/library/cc783557.aspx

Um mal weit auszuholen: Zertifikatsaussteller gewährleisten i.A. die allgemeine Sicherheit einer Public-Key Infrastruktur und stellen somit die zentralen Institutionen des Vertrauens selber dar, indem sie eine verbindliche dedizierte Zuordnung von vertraulichen Schlüsselpaaren zu Personen, bzw. Unternehmen und Einrichtungen vornehmen (Zertifizierung (B2B-B2C)).

Rechtliche Argumente:
Thawte firmiert in Südafrika. Somit gilt - soweit ich hier richtig informiert bin - bezüglich dieses ausgelagerten Geschäftsmodelles auch kein Rechtshilfeabkommen, bzw. kein DBA-Sachverhalt (Doppelbesteuerungsabkommen) mit der BRD. Mögliche Auskunftersuchen, bzw. Auslieferungsanträge in Strafsachen, seitens der BRD, wären somit wirkungslos. Wirkungslos u.A. auch zu Eurem rechtlichen Nachteil (z.B. durch EMail-Betrugsversuche zu Euren Lasten). Dies könnte sich für Euch (die ihr ja in der BRD rechtlich firmieren) - und zwar in Bezug auf Eure EMail-Sicherheit - u.U. zu einem Nachteil (durch so eine lokale Rechtsoase Thawtes) entwickeln. Sofern Ihr daher bezüglich Eures Geschäftsmodelles auf vertrauenswürdige Signaturen (Zertifikate) angewiesen sein solltet (z.B. über A-Ratings), könnte daher "ein skeptischer Blick" auf den Aussteller solcher Zertifikate - sowohl kundenseitig, wie auch von Eurer Seite aus - von Nöten sein.

Technische Argumente:
Das Prinzip des Web of Trust ist in der Kryptologie das Bestreben, die Echtheit von digitalen Schlüsseln durch ein Netz von gegenseitigen Bestätigungen (Signaturen) der einzelnen Teilnehmer zu sichern. Der private Schlüssel wird somit zwischen zwei kommunikativen Gegenstellen nicht mehr vertraulich generiert, sondern unterliegt - bezüglich seiner Evaluation - einem Kollektivprinzip vieler Anwender. Dies mag - nach meiner Meinung - einerseits der Schlüsselsicherheit (Kommunikationsverschlüsselung) selber dienlich sein - nicht jedoch der Anonymität der einzelnen Gesprächspartner. Dem Schlüssel haften somit personenbezogene Daten an, die mitveröffentlicht werden. Durch die Signaturen anderer Personen, beinhaltet der Schlüssel somit auch eine Liste der Personen, mit denen der Schlüsselinhaber in der Vergangenheit Umgang hatte. Auf einem Schlüsselserver sind diese Daten obendrein öffentlich einsehbar und daher auch automatisiert abrufbar.

Die entsprechenden Schlüssel (private keys) werden unter FF importiert, jedoch erst lokal auf Deinem System generiert. Unter Vista kann es dabei (durch spc-Dateien) - meiner Erfahrung nach - zu Problemen kommen. Serverseitig werden dabei - meiner Ansicht nach - jedoch keine relevanten Daten hochgeladen.

Oliver

user983475934 erklärte:

Zitat

[...]Der Firefox läuft nur mit eingeschränkten Rechten und somit auch alle weiteren Anwendungen (wie den Schadcode), den Firefox ausführt.

Wir sprechen hier aneinander vorbei - vermutlich von Dir provoziert.

Grundlage ist stets ein - durch die einzelnen OS-Kontenverfügungen - abgesichertes Betriebssystem. Erst dann gilt die Einschränkung einzelner Programme selber, und zwar auf der bereits abgesicherten Systembasis. Es gilt somit - im übertragenen Sinne - eine System-Hierarchie, bestehend aus OS und den darauf aufsetzenden Programmen einzuhalten. Das weisst Du selber vermutlich besser als wir.

user983475934 stellte dar:

Zitat

Ich habe es gerade getestet, die Umgebungsvariablen USERNAME und USERPROFILE sind bei beiden Ausführungsmethoden identisch.

Na - Wie genau wurde bei Dir getestet? Ein USERNAME muss schliesslich nicht immer ein unbedingtes Äquivalent zum jeweiligen USERPROFILE - und zwar in Bezug auf die einzelnen ausführbaren Programme (z.B. den FF) selber darstellen. Es gilt - nach meinen bisherigen Informationen - immer noch Username > UserProfile. Die Kombination aus unterschiedlichen Systemprozessen ("PropertyAttributes" unter Windows), auf welche der FF dann in Folge "zurückgreifen" muss, können meiner Ansicht nach dabei Fehler verursachen.

user983475934 überzeugte zuguterletzt durch:

Zitat

Man braucht übrigens nicht den ProcessExplorer, einfach cmd mit eingeschränkten Rechten ausführen, das reicht zur Kontrolle auch.[...]

Genau damit hast Du Dich - meiner Ansicht nach - bezüglich weiterer Diskussionen, gerade selber "disqualifiziert"...

Ich wage diesbezüglich inzwischen schon nicht mehr so sehr dazu, auf "Windows-Probleme" selber zu tippen, sondern eher auf "Schulferien"...

Oliver

user983475934 stellte Folgendes in Frage:

Zitat

Wie bitte schön? Ein Programm das so aufgeführt wird, ist total in seinen Rechten kastriert. Es kann z.B. nicht in C:\Programme schreiben, genauso wenig ins Systemverzeichnis.

Genau dass könnte z.B. einmal wichtig werden, sofern ungewollte Drive-By-Downloads oder unbekannte Erweiterungen innerhalb des Firefoxes bei Dir aktiviert und somit ausserhalb Deiner Kontrolle innerhalb des Browsers installiert werden sollten. Alles was somit per HTTP, FTP, - bzw. über ein ungesichertes Transport-Protokoll Deiner Wahl etc. automatisch aus dem Netz (durch ungewollte FF-Updates) nachladen kann - und somit auch innerhalb des FF´s ausführen darf - wäre daher in Folge für Dein System als gefährlich einzustufen.

user983475934 erklärte darüberhinaus:

Zitat

Beim IE klappt es ja auch problemlos.[...]

IE = System (also ein Bestandteil von Windows). FF = Programm (und somit definitiv kein Bestandteil von Windows selber, sondern bloss eine auf Windows aufsetzende Programm-Verfügung mit sekundären Rechten).

Zitat

Es macht übrigens keinen Unterschied, ob ich einen normal installierten Firefox oder eine portable version von portableapps.com nehme. Beide Feuerfüchse starten dann einfach nicht mehr.

Was für ein Wunder (s.o.)...

Die Instanzen (Prozess) - bzw. Profilverwaltung durch den Firefox könnte u.U. für Dein Problem verantwortlich sein. Alternativ dazu könnte es - meiner Ansicht nach - auch an den von Windows bereitgestellten Umgebungsvariablen liegen. (und zwar USERNAME und USERPROFILE, in Relation zu dem jeweilig gestarteten Programm, auf Basis des angemeldeten ADMIN). Hier gab es scheinbar in der Vergangenheit bereits Probleme (Profil des "angemeldeten Benutzers" vs. des jeweiligen "Prozessbesitzers").

a.Benutzt Du verschiedene Profile unter FF?

b.Verwendet FF dabei stets immer das Profil des angemeldeten Benutzers?

c.Werden bei Dir (unter RunAs) die Windows-Umgebungsvariablen des angemeldeten Benutzers eingehalten? (Kontrolle z.B. über den "Prozess Explorer").

Ich würde fast auf ein Windows-Problem (Basis) tippen...

Oliver

http://www.firefox-browser.de/wiki/MOZ_NO_REMOTE