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.

Comments

Anonymous 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.
11:23 AM
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....
3:28 PM
Post a Comment

Popular posts from this blog

Zeek in Action Videos

Image
This is a quick note to point blog readers to my Zeek in Action YouTube video series for the Zeek network security monitoring project .  Each video addresses a topic that I think might be of interest to people trying to understand their network using Zeek and adjacent tools and approaches, like Suricata, Wireshark, and so on.  I am especially pleased with Video 6 on monitoring wireless networks . It took me several weeks to research material for this video. I had to buy new hardware and experiment with a Linux distro that I had not used before -- Parrot .  Please like and subscribe, and let me know if there is a topic you think might make a good video.
Read more

MITRE ATT&CK Tactics Are Not Tactics

Image
Just what are "tactics"? Introduction MITRE ATT&CK  is a great resource, but something about it has bothered me since I first heard about it several years ago. It's a minor point, but I wanted to document it in case it confuses anyone else. The MITRE ATT&CK Design and Philosophy document from March 2020 says the following: At a high-level, ATT&CK is a behavioral model that consists of the following core components: • Tactics, denoting short-term, tactical adversary goals during an attack; • Techniques, describing the means by which adversaries achieve tactical goals; • Sub-techniques, describing more specific means by which adversaries achieve tactical goals at a lower level than techniques; and • Documented adversary usage of techniques, their procedures, and other metadata. My concern is with MITRE's definition of "tactics" as "short-term, tactical adversary goals during an attack," which is oddly recursive. The key word in the tacti
Read more

New Book! The Best of TaoSecurity Blog, Volume 4

Image
  I've completed the TaoSecurity Blog book series . The new book is  The Best of TaoSecurity Blog, Volume 4: Beyond the Blog with Articles, Testimony, and Scholarship .  It's available now for Kindle , and I'm working on the print edition.  I'm running a 50% off promo on Volumes 1-3 on Kindle through midnight 20 April. Take advantage before the prices go back up. I described the new title thus: Go beyond TaoSecurity Blog with this new volume from author Richard Bejtlich. In the first three volumes of the series, Mr. Bejtlich selected and republished the very best entries from 18 years of writing and over 18 million blog views, along with commentaries and additional material.  In this title, Mr. Bejtlich collects material that has not been published elsewhere, including articles that are no longer available or are stored in assorted digital or physical archives. Volume 4 offers early white papers that Mr. Bejtlich wrote as a network defender, either for technical or pol
Read more