Re: [PEN-TEST] VMware

[Greg <g () HOOBIE NET>]

It can work, you can configure two or three (maybe four) bridged networks
within VMWare. I have done two NICs after some tinkering.

You will have to edit the VM config file for your virtual system by adding
relevant lines for ethernet1, just copy the ethernet0 entry. You will have
to specify a type of 'custom' and point the new ethernet1 at VMnet1.

Once this is done you have to configure VMNet1 (which is a service) to act
as a bridged ethernet. This is achieved with the console utility supplied
with VMware called vnetconfig. Issue the command :

vnetconfig -s -ib vmnet1

You will be prompted to select the ethernet card to bridge onto to, select
the card that you didn't select during installation. Now restart all the
VMnet services.

When you power up the virtual machines you will have two virtual NICs
presented to the system, RedHat autodetects eth1 fine and then you're ready
to go. You can add up to four NICs I guess but I've not tried that many.

Some colleagues and I recently used this method to bridge a dual homed MS
proxy server with one NIC on the Internet and the other in the internal
corporate network with a redhat Linux server (complete with a large
selection of security tools, proxies, port redirectors etc.) Works a treat
and provided a great conduit to the internal network in additon to the tools
capability.

regards

Greg




-----Original Message-----
From: Penetration Testers [mailto:PEN-TEST () SECURITYFOCUS COM]On Behalf
Of Batten, Gerald
Sent: 12 September 2000 15:47
To: PEN-TEST () SECURITYFOCUS COM
Subject: Re: [PEN-TEST] VMware


Interesting, but the dual-homed theory won't work, at least not right now...
When you install the latest version of VMWare, it asks you which NIC you
want it mapped to (which you can't change after the fact, which is extremely
annoying).  So, any virtual system you install will be limited to 1 NIC.  A
possible exception would be a dial-up connection in addition to the NIC.

At least, this is my experience.

Gerald Batten

Security Analyst
EXOCOM ENABLING TECHNOLOGIES CORP.
http://www.exocom.com

*Note: Views expressed in this e-mail are not necessarily those of my
employer.
**Note:  Views expressed in this e-mail are not necessarily mine either.

> -----Original Message-----
> From: Greg [mailto:g () HOOBIE NET]
> Sent: Monday, September 11, 2000 12:46 PM
> To: PEN-TEST () SECURITYFOCUS COM
> Subject: VMware
>
>
> To continue on the topic of VMware started by Mark Teicher:
>
> VMware works great running Linux under NT (and vice versa no doubt),
> allocating 32MB RAM to linux is more than enough to use most
> of the Linux
> specific testing tools providing you don't want X. I'm sure you could
> probably run with less. I haven't yet encountered a Linux
> tool that would
> not run under VMWare, including all of the raw packet tools
> like NMAP etc.
>
> Another consideration is using VMware as an attack tool by creating a
> virtual system on a compromised box. Imagine a situation
> where an NT system
> is compromised on a remote network but no further incursion
> can be made into
> the network due to a lack of suitable tools (which is
> starting to change.)
> If VMware is installed onto the compromised system and a
> cheeky reboot is
> performed, it is possible to load a preconfigured linux VM
> disk image onto
> the NT system.
>
> The virtual Linux system can be assigned an address on the compromised
> network (bridged) and hey presto, root and any tools you want
> on a un*x box
> in the target network. Taking this a stage further,
> compromising a dual
> homed NT system and installing a dual homed virtual Linux box
> over it makes
> for many interesting possibilities.
>
> If VMware could be run as a non-interactive service (and thus
> not a desktop
> window) then it's use would be harder to detect to a local user. A new
> system appearing on a network may raise eyebrows in some
> vigilant network
> ops departments but generally will go unnoticed. Any reboot
> is always a bit
> dodgy, if have authoritah and you think it won't affect
> production systems
> (too much) then go but beware, if the system does not come back up...
>
> regards
>
> Greg