From what I do know, it is possible for the physical adapter on the host to be connected to the Internet, and for all the virtual machines (connected to the same Internal Network ID) to be communicating with one another - but the virtual machines will NOT be able to interface with the Internet through the host’s physical network connection.

I do not believe that a bridge interface is created when the Internal Network is used - thus preventing the possibility of data leakage through the loopback interface created on the host.

Bill

Is the host only adapter swtiched on when internal networking is active? Can it be removed and still have guest communicate?

Just wanted to say thank you. This was a very simple, quick to the point guide that helped me tremendously. It’s really nice to have a little setup to test out my ethical hacking skills on. This was especially nice for me seeing as how I run Ubuntu as my host anyway and run backtrack 4 R1 and Windows Xp sp 3 as my guests. I found this info in the virtualbox help but It wasn’t as straight forward as your blog was. You have me as a fan of the blog, thanks again!

Since I ran through and did the install of BT4, I simply recompiled with LibSSH support.

I don’t remember the exact steps, but here’s a link to how to rebuild Hydra with support for LibSSH:
http://forums.remote-exploit.org/backtrack-4-package-feature-requests/23874-hydra-compiled-without-libssh-support.html

Bill

Thanks for the guide, it helped hugely in setting up these machines as VMs… I have a notable point, though…

I got to a certain point in the disc, and it became obvious that one of the main tools used in the the cracking of the very first disc is Hydra… My point being that the version which comes with BT4 Beta/PreRel isn’t compiled against libssh.

This means that the stated tool for cracking disc 1.100 is unusable. No doubt there are other tools in the colossal BT4 suite which will make up for it, I just thought it was a useful point to note.