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: http://www.vmware.com 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 hardware-wise. 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 many. 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. Sincerely, Don [1] Speaking of which, the source document for that is or was at: http://seclab.cs.ucdavis.edu/papers/bishop,heberlein-1996.pdf "'ken'@FTU" wrote: > > Hello, > > I'm looking to set up a lab of about 30 host to simulater an > Internet/DMZ/Intranet. > > 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. > > 'ken' > > ---------------------------------------------------------------------------- > 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: > https://alerts.securityfocus.com/ -- 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: https://alerts.securityfocus.com/
This archive was generated by hypermail 2b30 : Thu Oct 18 2001 - 10:52:43 PDT