Tuesday, September 06, 2005

VMWare Team LAN Appears Shared

Previously I wrote about my plans to incorporate VMWare into my classes. Originally I intended to use GSX Server. I thought I would give each student his or her own independent image. I assumed people would want to build their own sensors (from the ground up), and that required providing complete virtual machines.

Based on feedback here and in classes since that post, I've learned most people don't care about building sensors. They are more interested in analysis. Therefore, I decided students didn't need dedicated VMs. Therefore, I could run a few VMs with dedicated functions, and let students share systems as normal users. For example, in my last class a dozen students all logged in to a single FreeBSD image to perform analysis.

In the future, I plan to have multiple images running. For example, I plan to offer several complete Sguil installations. Students in groups of two or four might share one Sguil server. My current test environment uses VMWare Workstation 5 running 6 FreeBSD 5.4 REL images simultaneously.

Since VMWare 3.x I've wondered about the product's networking support. For example, if I provided a set of VMs with internal NICs, could they see each other's traffic? I decided to answer this question by putting my 6 FreeBSD VMs into a single VM "team", as shown.
One interface (lnc0 on each) is bridged so I can access the systems remotely. The second interface (lnc1 on each) is limited to the team and is addressed with an internal scheme. Here is the question: if freebsd54-rel_01 pings freebsd54-rel_02, will freebsd54-rel_03 see it? Here is the ping:

$ hostname
fbsd5401.taosecurity.com
$ ping -c 1 10.1.1.202
PING 10.1.1.202 (10.1.1.202): 56 data bytes
64 bytes from 10.1.1.202: icmp_seq=0 ttl=64 time=2.943 ms

--- 10.1.1.202 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.943/2.943/2.943/0.000 ms

Here is what another system on the team sees:

fbsd5403# tcpdump -n -i lnc1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lnc1, link-type EN10MB (Ethernet), capture size 96 bytes
08:19:58.946640 IP 10.1.1.201 > 10.1.1.202: icmp 64: echo request seq 0
08:19:58.946695 IP 10.1.1.202 > 10.1.1.201: icmp 64: echo reply seq 0

Yes. That is great. Life is much simpler now, since any machine can see any other machine on the same team. That facilitates setting up networks that can be monitored.

2 comments:

J_Kenpo said...

Of course people wouldn’t want to know how to build sensors, in the short amount of time that is allotted to the class, and the fact that people are lazy and do not want to do the work ;) Ultimately it is a judgment call for you if knowing the internals of sensor operation is necessary for analysts. I have found in the past that knowing how a sensor is built and how it functions can be crucial to working with the Sguil setup; after all, you remember the slogan for SPREG don’t you... And considering if the analysts in the class come from a small NSM operation, know which services need to be restarted that work with the sensors operation (example: Barnyard is 9/10 times the culprit of issues on my sensor) might be a necessity. What you might consider is if there is having them build sensors if there is enough time remaining at the tail end of the class...

I’ve used VMWare since you mentioned it a few years ago in one of your posts. The networking support seems pretty complete. I’ve been able to run separate sensor, Sguil Server, and Database server instances that actually monitor the external network of the host OS. However, I usually use it to do assessments and test of released exploits. I set up one single sensor in VMWare, a victim machine or machines, and a attacker, and run the Sguil console in the host OS to analyze attacks or study released exploits to see how they work. I’ve had, on one setup of VMWare workstation, Win95A, 95B, 98, 98SE, Windows 2000 all running concurrently, with a Linux sensor instance. All 6 VM’s were able to see each other, and the sensor was able to see traffic across all. I had them set up bridged since this was in a test network. I know the Honeynet guys use VMWare for some of their stuff, and in the Honeynet Projects SOTM 29, they used a RedHat 7.2 VM configured in a bridged network.

The nice thing about this is you can make a backup of the VM’s base install, so any changes made during the class can be restored before each class.

Anonymous said...

Rich.. Glad to see you are still very active in security. Hope all is well for you and your family.. Take care - xAFCERT teammate - Terry....