Home page logo

pen-test logo Penetration Testing mailing list archives

Re: Lab leads??
From: Don Bailey <baileydl () mitre org>
Date: Thu, 18 Oct 2001 10:42:50 -0400

Definitely consider VMware for providing multiple target OSes on your
Intel hardware.  The benefits of running VMware with Linux as the host
OS include increased stability, and the ability to monitor / log your
vmnet interfaces and traffic with tcpdump or other *nix sniffer.  This
goes a long way for after action analysis.

If you have a multi-cpu server class box (at least a gig of ram and 100
GB of storage), think about using VMware GSX server.  In an attack lab,
your hardware will be idle most of the time.  To save on space (we don't
all have HUGE labs) and the hardware itself, you can run 4 VMs per CPU
on your server.  Other benefits include remotely starting and stopping
the VMs through a web interface, and displaying the VMs (if need be) to
both Linux and Windows workstations.  Previous comments about do-over
images, (non-persistent drive images VMware calls it, I think) still
apply.  Works great, and I simply keep backup image tarballs to use when
I really mess things up.

Funds might be an issue with a lab this size.  With current hardware
prices being as low as they are, you could build a dual-Athlon 1.4GHz
system with 1GB of RAM and a ton of hdd space for around $1K.  Red Hat
7.1 will be free.  Even with the purchase of VMware GSX server, you'll
save several thousand dollars by not having to build as many target x86
boxen.  For more info on VMware and their cool products, visit: 

If your Intel hardware isn't beefy enough to run VMware at an acceptable
speed, consider using Ghost to create images of various Windows
operating systems and patch levels.  Burn the images to CD and create a
custom boot floppy that autostarts Ghost and allows you select which
image to install.  Re-installation time takes about 30 seconds to 2
minutes.  A veritable time saver once all the initial image-creation
work is done.  Be careful, the images can be system specific--so to
maximize your use of the images, keep all your systems exactly the same

Because Linux and OpenBSD are so quick to install, you can just keep the
install CDs around and re-install as necessary without too much time or
effort.  Removable drives can be helpful, but don't go beserk--they get
disorganized, system specific, and a pain to manage if there are too

You'll find more difficulty with your Sparc hardware and Solaris than
anything else.  Removable drives that you can dd to images and vice
versa will help here.  Keeping systems with 2.5.1, 2.6, 7 and 8 running
will be a boon for testing the "backwards compatibility" of new
exploits.  Exploits for Sparc Solaris != Exploits for x86 Solaris, so an
intel box or two to toss Sol x86 on is helpful--I have gotten Sol x86 to
run under VMware, but without a window manager, VERY slow, and I never
verified how networking was.

Linux will be the OS you play with most often, so at least one box that
continually runs this is a good idea.  You can make this a DNS server
for the other boxen and create fake domains like I have (goodguys.org,
badguys.org, lamer.edu).  This can also be your tftp, nfs, samba and ftp
server for your exploits, rootkits, sunfreeware, rpms, and windows
software--think of it as your "warez" box.  This box should be
off-limits to attack for productivity reasons.

And don't forget to put a router or two in the mix.  Cisco 2600s are
what I have--easily configurable and plenty of ethernet ports.  On the
subject of wiring etc. try to use hubs instead of switches--this will
save you some grief for simple sniffing and hijacking, unless you WANT
to try sniffing or hijacking with switches.  Also keep your media types
consistent if possible--ALL 10baseT or ALL 100baseT, as some
auto-sensing hubs will cause you pains with traffic seperation. 
Introduce more complex hardware (network appliances, WAPs, layer-2 /
layer-3 switches) only as necessary.

And KVM switches are a good idea.  If you're on the cheap, a Belkin will
do, but if you want kick-ass, I'd go with a BlackBox ServSwitch 1x8-port
or 4x16-port.  This will help with space and heat... AND wheeling your
chair around to each workstation.

These are just quick hints (hopefully helpful) for attack / network
simulation lab setup.  I have a ton more info on the lab security and
user features from my work experience--a bit beyond the standard Matt
Bishop "air-gap & move-media-as-necessary" model [1] employed by many. 
If there's enough interest, I'll post a generic setup and security guide
for review and comment--just email me.



[1]  Speaking of which, the source document for that is or was at:


"'ken'@FTU" wrote:


I'm looking to set up a lab of about 30 host to simulater an

Does anyone have any sources (papers) or ideas that might help? Here are
a few parameters:

Lab must contain various OS'es.
Lab must be able to be very easily configurable to create and
demonstrate holes and how to patch them. (But then recreate the hole to
demonstrate the weakness again to another set of people.)
The holes must be at the network, os and application levels.

One idea I had is to create images of servers known to have holes,
demonstrate the exploit, patch the hole, show it is fixed and then
reimage the disk with the old hole. The imaging trick should work with
different OS's as well. What do you think?

Thanks in advance.


This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:

Don Bailey
Senior INFOSEC Engineer/Scientist
Secure Information Technology
The MITRE Corporation

This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]