On 4/9/07, <b class="gmail_sendername">Ben Wilhelm</b> <<a href="mailto:zorba-tor@pavlovian.net">zorba-tor@pavlovian.net</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br>Roger Dingledine wrote:<br>> Kyle: this would be more useful if it didn't depend on a non-free vm<br>> player. Do any of the free software variants of VMWare actually work<br>> well enough for this approach?
<br><br>I've been running Tor clients and servers under VMWare Server for a<br>while now. I do my secure browsing inside a dedicated VM, and my<br>firewall is set up to block all outgoing traffic from the VM. The VM<br>
connects directly to my Tor server (on another VM, though that's not as<br>important) which itself connects to the outside world. It's not quite<br>ideal because in theory that VM could snoop around my LAN and report on
<br>stuff, but I could disable that with some more work (putting that VM in<br>a dead-end virtual network so it can't talk to anything except a Tor<br>server), I'm just lazy and don't think that's really likely to be an issue.
<br><br>VMWare Player ought to be possible to set up so that it runs behind a<br>DHCP server on whatever is running VMWare. VMWare Server definitely is.<br><br>-Ben<br></blockquote></div><br><br>Ben, you got the right idea. I use JanusVM with Ubuntu and Backtrack.
<br><br>In the first version of JanusVM, we only had the bridged network interface. With the latest release, we have two network interfaces (bridged and NAT'd). We changed it for security purposes. <br><br>I changed my Ubuntu network connection in VMWare Server from BRIDGED to NAT. Now with JanusVM and Ubuntu (or Backtrack), I'm using VMWare's NAT'd virtual NIC to connect from Ubuntu to JanusVM. In Ubuntu, I just filter out all network traffic that not going to or from my NAT'd interface netmask. So if my LAN is on
192.168.1.X and my NAT'd interface is on 192.168.242.X, then I just filter out everything that is not from 192.168.242.X. This keeps me safe from the following types of attacks, which I haven't talked about or released until now. I AM NOT CALLING THIS AN EXPLOIT, it is just a very simple query (nslookup) that can be used as an attack.
<br><br><span class="q">Roger Dingledine wrote:</span><br>>James Muir, HD Moore, others: can you give some thought to what attacks<br>>and vulnerabilities remain even in this model? I guess we can still<br>>overflow the browser and start looking around for private data on the
<br>>computer, like an Outlook address book. What other issues remain? And<br>>does this approach introduce any new issues?<br><br>Here's your answer Roger:<br><br>*** DISCLAIMER ***<br>The following is just a very, very simple yet effective means to acquire your REAL EXTERNAL IP address from WITHIN your internal LAN. This does not work on every router/DNS server out there, but it works on the two ActionTec's and one D-Link retail routers I tested.
<br><br>DEMO URL: <a href="http://janusvm.peertech.org/Flash/internal-dns-leak.html">http://janusvm.peertech.org/Flash/internal-dns-leak.html</a><br><br>
(yes, I know I just revealed my IP address to the everyone reading this, but
honestly I don't care because [1] I'm making a point and [2] it has
already been rolled to a new IP by the time you read this.)<br>
<br>We (coderman and I) have addressed and solved the issues of side-channel attacks to reveal your true IP to a server on the Internet. Now we started thinking about things that can reveal our true IP INSIDE our LAN. (HINT: UPNP would be another place to poke around at to get a real external IP, for all you Java fans.) When using VMWare's NAT'd interfaces in the setup I just described above, you effectively stop this type of attack from working.
<br><br>ENJOY!!!<br><br>~Kyle<br>;-)<br>