Neue Informationen zum WebRTC IP Leak

Bei NAT nutzt die VM die Routingtabelle des Hostsystems, bei bridged ihre eigene. Auf Deutsch gesagt, wenn du NAT verwendest und dein Hostsystem ist ins VPN eingewählt, so ist die VM auch im VPN. Nimmst du bridged surft die VM ohne VPN, du bist also komplett unabhängig vom Hostsystem.
 
Dr_Iwan_Kakalakow;n12332 said:
@stephan,
deshalb möchte ich die Häkchen ja selbst setzen, wenn die BETA es (noch) nicht schafft. Schaue mir den Link gleich an.

Nachtrag:
Linkinhalt gelesen. Das weiss ich ja.
Ich meine die Häkchen in meiner Windows-Firewall, die ich selbst setzen möchte, sobald ich mit VPN online bin.
Click to expand...

Häkchen in der Windows-Firewall? Du meinst die in Windows eingebaute Firewall unter Systemsteuerung? Der im PP-Client eingebaute Firewall-Schutz setzt eine Handvoll unterschiedlicher Regeln, die Verbindungs/Routing-abhängig sind. Ich rate davon ab, dass von Hand zu machen, weil sich diese Regeln dynamisch ändern (müssen ggf bei jedem Verbindungsaufbau angepasst werden). Als Beispiel kannst Du die Regeln aber ansehen, wenn Du in der PP-Software den Firewall-Schutz aktivierst und dann im Interface der Windows-Firewall nachsiehst.
 
PP Stephan;n12366 said:
Ich rate davon ab, dass von Hand zu machen, weil sich diese Regeln dynamisch ändern (müssen ggf bei jedem Verbindungsaufbau angepasst werden).
Click to expand...
Na, dann werde ich davon mal lieber die Finger lassen und abwarten bis Lars in einer neuen BETA etwas einbaut.
Vielleicht funktioniert dann die BETA bzgl. Firewalleinstellungen bei mal.
 
Wie gesagt, im nächsten Update funktioniert der Schutz auch wenn Du selbst ein 10'er-Netz verwendest. Wird auch nicht mehr lange dauern.
 
@Kingb7: Leider äußern sich die meisten hier nie, vor was sie sich eigentlich schützen möchten. Wenn man sich vor allen möglichen und unmöglichen, theoretischen und praktischen Gefahren und vor allen Geheimdiensten der Welt mit allen möglichen Angriffszenarien schützen möchte, weil man sich als Staatsfeind No1 in allen Ländern der Welt sieht, dann muss man zur bestmöglichsten Sicherheit noch das Maximale an zusätzlicher Sicherheit nutzen - kein Thema.

Ich gebe Dir völlig recht, dass man zum Schutz vor bestimmten Überwachungen bzw. Gefahren natürlich nicht mit der gleichen IP sein Klarnamen-Facebook-Profil und die Seiten nutzen darf, bei denen man absolute Anonymität benötigt.
Vor diesem Gefahren-Konstrukt muss ich mich aber nicht schützen. Meine Bedrohung liegt nicht darin, dass jemand, der eine PP-IP hat, Kontakt mit Facebook aufnimmt und Facebook bittet, zu schauen, ob dort ein Klarnamen-Profil bekannt ist, welches jemals die gleiche IP genutzt hat.

Was ich vergessen habe zu erwähnen ist, dass ich zum hardwäremäßig ausreichend bestückten VPN-Router einen weiteren Router einsetzen werde, der ohne VPN ins Netz geht. Geräte, die keinerlei Verschlüsselung oder IP Verschleierung benötigen, wie z.B. mein Fernseher oder eine meiner NAS, die laufen dann darüber ;)
 
Nochmal allgemein zu dieser VM Geschichte:

Ihr wisst schon, dass ihr euch dadurch zwangsweise ne weitere Software installieren müsst, die selbst wieder Schwachstellen haben kann, die euer Hauptsystem auch direkt betreffen. Nämlich den Hypervisor...

Nur mal allgemein zum Tenor, ne VM macht unangreifbar. Das halte ich für'n schönes Gerücht. Nehmt doch zb n Linux Live System, das schraubt eure Sicherheit definitiv höher als diese VM Sache, die alles verkompliziert.
 
Der Hypervisor ist allerdings deutlich einfacher gestrickt, als ein OS. Die Zahl der Sicherheitslücken/Bugs ist nach gängiger Sichtweise proportional zur Anzahl der Zeilen Source-Code. Danach ist die Reihenfolge: Hypervisor
 
JackCarver;n12364 said:
Bei NAT nutzt die VM die Routingtabelle des Hostsystems, bei bridged ihre eigene. Auf Deutsch gesagt, wenn du NAT verwendest und dein Hostsystem ist ins VPN eingewählt, so ist die VM auch im VPN. Nimmst du bridged surft die VM ohne VPN, du bist also komplett unabhängig vom Hostsystem.
Click to expand...

Na,das ist ja mal ne klipp und klare Antwort,nach der ich gesucht habe:kiss:
 
Wg. NAT/Bridge: Ich dachte immer, bei einer Bridge hängt der Gast direkt im Netzwerk des Hosts, bei NAT wird der Traffic über den Host geroutet. Das Gastsystem ist dann nicht im öffentlichen Netzwerk sichtbar. Deswegen nimmt ja auch die Bridge, wenn man z.B. zwischen Host und Gast kaskadieren will, z.B. Host > Tor, Gast > VPN, so dass man die Kaskade Tor > VPN hat.
 
Wenn du kaskadieren willst, dann nimm NAT. Stimmt ja, dass hier der Traffic über den Host geroutet wird und wenn der Host bereits im VPN ist und du dich aus dem Gast heraus wieder zu nem VPN Server verbindest, dann geht das durch den Host.
Nimmst du Bridged, wird sozusagen ne Brücke zum Netzwerkadapter gebaut, die den Host auslässt, du machst dann alles getrennt vom Host. So könntest du den Host zu PP Amsterdam verbinden und den Gast zu PP Hünenberg, beides läuft parallel, im NAT Fall kaskadierst du.


[h=2]Bridged Network: Direkte Verbindung zum LAN[/h] Bei der direkten Verbindung zum LAN ist die VM netzwerktechnisch nicht von einem physischen Rechner zu unterscheiden. Für Server – außer für solche, die zu Testzwecken rein virtuelle Netzwerke versorgen sollen – ist dies die einzige sinnvolle Betriebsart. In VMware Workstation heißt diese Konfiguration „Bridged“, in Hyper-V „External“, in Virtual PC konfiguriert man den virtuellen Netzwerkadapter mit dem Namen des physischen, über den die Verbindung zum Netz hergestellt werden soll. In Virtual Server heißt die Konfiguration „Public“ und wird ebenfalls mit den Namen der entsprechenden physischen Netzwerkadapter konfiguriert.

Die VMs befinden sich immer im gleichen Netzwerksegment wie die Hosts, auf denen sie ausgeführt werden.


NAT: Subnetz mit Host-Zugriff

Hier kann der Host mit den VMs per Netzwerk Daten austauschen und optional als Router fungieren. In Hyper-V wird diese Betriebsart als „Internal“ bezeichnet, wobei NAT per Network Policy and Access Server eingerichtet wird. In VMware heißen beide Varianten verschieden: „NAT“ steht für Zugriff auf den Host mit Router-Funktion, „Host-only“ ist die Konfiguration ohne NAT, die in der Voreinstellung den Zugriff auf den Host beinhaltet. In Virtual PC heißt die NAT-Variante „Shared Networking (NAT)“, eine Nicht-NAT-Variante gibt es nicht, kann aber über einen Loopback-Adapter manuell konfiguriert werden. Virtual Server kennt den Modus gar nicht, weder mit noch ohne NAT, kann aber ebenfalls den Loopback-Trick verwenden.
Click to expand...

Hab das mal als copy+paste von http://www.windowspro.de/andreas-kroschel/netzwerk-optionen-fuer-virtuelle-maschinen kopiert.
Wie du siehst, ist bei Bridged die VM netzwerktechnisch nicht von einem physischen Rechner zu unterscheiden, es ist hier so, als wenn Host und Gast auf unterschiedlichen Rechnern laufen, somit keine Kaskade möglich.

Bei NAT kann der Host als Router fungieren, somit ist ne Kaskade möglich.
 
@Jack: genau so mache ich es auch, VPN auf Host, in der VM komme ich über NAT ins Netz und dort nochmal VPN. Leider ist das sicherheitstechnisch nicht unbedingt schlau, wie ich feststellen musste, denn in der VM kann man dann zB auch auf die Fritzbox an dem der Host hängt zugreifen und soweit ich weiß auch auf die anderen Netzwerkgeräte.

Kann ich das irgendwie unterbinden? Ich will nur, dass der VM Traffic über den Host VPN geroutet wird.

Na los Jack, du hast mir damals schon mit der Comodo Firewall geholfen und bist der mit dem meisten Wissen im Forum hier!!!
 
Hab grad kein Testwindows da, aber vom Prinzip musst du einfach Zugriffe der VM auf dein LAN blocken. Wenn ich bei OSX die Firewall hochfahre und dort zb lediglich Zugriffe auf die PP Server und den Port 53 UDP zur DNS Auflösung zulasse, so kann sich mein System zwar zu den Servern verbinden und auch darüber surfen aber selbst Zugriffe auf die EasyBox oder benachbarte Rechner sind dann nicht mehr möglich.

Das interessante daran ist eigentlich, dass man anmerken könnte wieso das überhaupt geht. Ich benötige ja zumindest Anfangs den Router um überhaupt raus zu kommen, aber das liegt einfach daran, dass ich lediglich Ziel-IPs aus meinem LAN blocke. Darüberhinaus, wie im Falle VPN über den Router zu einem Server ist erlaubt.

Mit den Settings geht im LAN btw gar nix mehr, noch nichtmal Drucken etc am Netzwerkdrucker.

Edit:
Da in der VM ja irgendein OS läuft, musst du nur dessen Firewall dafür bemühen.
 
Schau Dir doch einfach mal die routing-Tabellen an, dann siehst Du auch, wie die Pakete ihren Weg finden. Wenn das default-gw für die VM über TOR oder sonst was läuft, wird natürlich auch der VPN-Tunnel in der VM über diesen Weg aufgebaut.

Das ist bei NAT wohl zwangsläufig der Fall, da das NW-Interface zur VM auf dem Host automatisch die default-route des Hosts berücksichtigt.

Ich benutze nur bridged für meine VMs, vermute aber, daß im NAT mode ein zusätzliches virtuelles Interface auf dem Host erzeugt wird, von dem der ganze traffic (genattet) der VM ausgeht.
Einfach mal ausprobieren, wie ifconfig vor und nach dem Starten der VM aussieht. Ebenso interessant ist, wie route vorher und nachher aussieht.

Im bridge-mode merkt der host nichts von der VM, sie ist aber im gleichen subnet wie der host. Dafür kann sie auch nach extern Services anbieten, da ja nicht genattet. Hängt also alles von den Eigenschaften der VM und dem routing ab.

EDIT: ich habe nur VirtualBox im EInsatz. Das kann bei VM-ware und anderen Virtualisierungen anders sein
 
Ich vermute, dass deine Lösung etwas anders ist, als das was ich meinte. Nehmen wir mal Parallels als Virtualisierung, so ist es dort so, dass in der Betriebsart NAT:

- Ich wähle mich im Hostsystem zu nem PP Server ein, ich teste meine IP im Gastsystem und habe dieselbe PP IP wie das Hostsystem => Mache ich nun eine weitere VPN Verbindung im Gastsystem, so geht diese zwangsläufig durch die Host PP Verbindung.

Betriebsart Bridged:

- Ich wähle mich im Hostsystem zu nem PP Server ein, ich teste meine IP im Gastsystem und habe nach wie vor eine Non PP IP => Der Traffic von Host und Gast ist voneinander unabhängig. Ein VPN im Gastsystem wäre hier parallel zu einem VPN im Hostsystem, nicht kaskadiert.

Da ich Tor nicht nutze, kann ich dazu nicht soviel sagen, aber:

Assuming Tortilla installed its driver properly go to the Virtualbox network tab and select Bridged Adapter then Tortilla Adapter under name. Click Advanced, then click Adapter Type, and select Intel PRO/1000 MT Dekstop.
Click to expand...

Das hört sich so an, als ob hier eine Bridge vom Network Adapter der VM zum Tortilla Adapter gebaut wird, der wohl der Tor Adapter ist. Es wird keine Bridge zum LAN Adapter des Hostsystems gebaut. Damit ist klar, dass der Traffic hier durch Tor geht, ist aber halt was anderes als der Fall, den ich meinte und als das was man allgemein unter Bridged VM versteht.

Siehe nochmal:

Bridged Network: Direkte Verbindung zum LAN
Click to expand...

von http://www.windowspro.de/andreas-kro...elle-maschinen

Eine direkte Verbindung zum LAN bedeutet erstmal keine Verbindung durch Tor.

Edit:
Hier von einer anderen Seite Tortilla betreffend:

4. Run Tortilla.exe; this will install the Tortilla Adapter as a virtual network adapter and will run the Tortilla client
5. Configure a virtual machine to use the Tortilla Adapter as its network adapter
Click to expand...

https://github.com/CrowdStrike/Tortilla

Die Punkte 4 u 5 sind diejenigen, die in deinem Forum auch beschrieben sind. Du baust die Bridge hier als Ausnahmefall nicht auf den LAN Adapter, sondern auf den Tortilla Adapter.
 
Seit Tagen sehe ich, dass hier vom eigentlichen Thema abgeschweift wird!
Bleibt hier doch bei dem Thema, wie der Thread-Betreff lautet.
Man hat keine Lust x OffTopic-Seiten in einem Thread zu lesen die damit nix zu tun haben, wenn man sich für das eigentliche Thread-Thema interessiert!

Wer sich eine virtuelle Maschine aufbauen möchte, der kann ja mal Google und YouTube benutzen.
Lest euch ein und probiert es aus - so habe auch ich angefangen - ich nutze seit Jahren VM's.
Man findet alles, wenn man sucht, so weiß man dann was z.B. NAT, Bridge Network etc. macht oder wie man im Gast ein Mikrofon einrichten kann usw.

Um nicht noch weiter vom Thema abzuschweifen braucht ihr jetzt nichts von mir zitieren oder dazu etwas zu sagen!
Danke!
 
In der neue Beta-Version sollte jetzt der Firewall-Schutz auch dann funktionieren, wenn Ihr in eineim 10'er-Netz seid. Bitte Feedback geben, falls das nicht erwartungsgemäß funktionieren sollte.
 
PP Stephan;n12202 said:
Kannst Du uns mal deine Routing-Table per mail schicken (wenn eine VPN Verbindung aufgebaut ist)? In der Konsole

route print >routing.txt

Dann liegt im aktuellen Verzeichnis die Datei routing.txt, die Du an eine E-Mail an PP support schicken kannst.
Click to expand...
Die habe ich dir vor ein paar Tagen per PN zukommen lassen.
Noch keine Rückmeldung erhalten!
 
Oops, ich habe die PN nicht gesehen, daher bat ich das per e-mail zu senden...

Aber es wäre nun ohnehin erstmal sinnvoll, dies mit der aktuellen Beta-Version zu testen. Den Beta-Thread habe ich im letzten Post verlinkt.
 
You must log in or register to reply here.
Back
Top