---
layout: post
title: Home Lab 2016 (2015)
category: homework
tag: imported
author: adricnet
---
*draft post, no images, end notes, links yet*

Revamped and reconfigured post-SEC511 and SOC Augusta 2015, with some input from GSE studies Google group, plus some good stuff for file analysis that I'm currently neglecting ...

Gear
====

The physical hardware of the lab is two Shuttle mini servers, a extra switch or two, and the tap on the cable modem. 

Hyper
-----

One of the Shuttles is an ESXi hyper with a few internal drives:

* a tiny SSD (mSATA) ~8 GB for ESX boot and key ISO install media
* a pair of 1 TB hybrid SATA3 drives as VM storage

The hyper server has some extra network ports from a PCI card that we put to good use. Its physical network connections are to the primary switch for the the X network and to the tap on the cable modem.

For simplicity and ease of NSM both these virtual networks (and their vSwitches) are fully opened up in VMWare for promiscuous mode (sniffing). This is not a good production configuration but it is great for the lab.

Sandbox
-------

The other Shuttle server is a Linux install with REMnux 6 for malware analysis including a Cuckoo Sandbox server for automated malware analysis against configured VirtualBox virtual machines.

Tap
---

I have an inexpensive tap between the cable modem and the primary router. Its only good for a slow network and combines duplex onto one port, which is all great for my Internet connection ( ~20 Mbps downstream ) which isn't capable of more than 100 Mbps total anyway.

{need graphic}

Networks
========

Eschewing a more sophisticated network architecture for now we have one production network for everything. Most of the non-lab gear is on wireless anyway. We'll call this network 192.168.X.0/24.

The hyper has a few vSwitches including for the production X network (labelled "Lab"), the tap coming in from the cable modem (labelled "Loose") . As noted both a fully unsecured in VMWare so we can sniff them.

Security Onion for NSM
==============

We have two SO virtual machines monitoring all of this to get the coverage we need with acceptable performance. The main SO install is on SOSIFT, a Security Onion 12.04 with the SIFT3 packages added. The cable modem tap gets its own sensor in this build.

SOSIFT has separate management and monitoring interfaces (both on Lab vSwitch and X network) and is configured in SO advanced setup as an Standalone server with Bro, Suricata, ELSA listening on that last interface with full pcap, file extraction enabled.

cablesensor is also SO 12.04 configured in advanced mode to be a sensor (only) and is connected up to SOSIFT as master for Suricata, ELSA with full pcap, file extraction enabled.

Kali for event source
=====

A Kali Linux 1 virtual machine on the hyper serves as the source of all our attack traffic in this model. Following the tutorials I have OpenVAS/gbsa and Metasploit framework all ready to go. Both the OpenVAS scans as well as any db_nmap scans from *msfconsole* are visible to the Security Onion systems because the Lab network they use is fully monitored by SOSIFT.


Testing
====

While I was still setting everything up I used some simple network utilities to keep an eye on my network configs. It was easy to have a ping with a silly pattern running on the Kali scanner system and a matching tcpdump on the sensor interfaces, before moving on testmyids.com, and then the OpenVAS and nmap scans.

1. Ping (from kali) to some target system on X network, continuously, with a pattern, and watch for those pings where you should see them (sensor interface):
 * <pre>ping -p '0xdeadbeef' 192.168.X.250 #ping SOSIFT mgmt IP</pre>
 * <pre>tcpdump -nni eth1 -v -x 'host 192.168.X.241' #kali's IP</pre>

2. Then try the same with Internet DNS. This should be visible in two places in the sensor net: the lab network and the cable modem tap.
 * <pre>dig @8.8.4.4 adric.net TXT #from kali ask GDNS for my SPF records</pre>
 * <pre>tcpdump -nni eth1 -v -X 'port 53 and host 192.168.x.241' #lab sensor shoudl see kali's request</pre>
 * <pre>tcpdump -nni eth2 -v -X 'port 53 and host 8.8.4.4' #will show DNS request outbound and response</pre>
 *  this proves we have sensor coverage for the lab and the Internet link!

3. Then we can use testmyids.com, a handy site that causes an alert in one of the default Snort/Suricata rules from Emerging Threats GPL. We should be able to see LAN and WAN for Kali activity, as well as WAN for all systems on X network (cable modem tap). Log on into sguil interactively via console and monitor the cablemodem monitoring and lab monitoring interfaces (for me that's sosift-eth2 and cablesensor-eth1) and then generate some events, alerts:
 * <pre>curl www.testmyids.com # from a Mac on production network</pre>
 * <pre>curl www.testmyids.com # from Kali VM </pre>
 * should all alert via the appropriate sensor interface in Sguil, ELSA

4. After that I was confident than some discovery scans in OpenVAS and msfconsole would populate, and they did.

Working!
=====

Events generated from Kali aimed anywhere on X network populate nicely into sguil on SOSIFT (via remote console) and into ELSA (web UI). OpenVAS security was relaxed (/etc/default/ ) to allow non-localhost connections to the management and admin Web UI (Greenbone Security Assistant) and the self-signed certificate for ELSA needs to be trusted for any browser to let you use it. I have hosts file all over for the servers, sensors, kali so I can use hostnames when I want to.

Refs
=====

* SEC511 "Security Operations and Continuous Monitoring" : https://www.sans.org/course/continuous-monitoring-security-operations, for GMON : http://www.giac.org/certification/continuous-monitoring-certification-gmon

* GSE, study group: https://www.giac.org/certification/security-expert-gse , https://groups.google.com/forum/#!forum/giac-study

* *#SOCAugusta2015, @securityonion*

* VMWare vSwitches for sniffing: "Configuring promiscuous mode on a virtual switch or portgroup (KB 1004099)" http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004099

* for SO, start here:
https://github.com/Security-Onion-Solutions/security-onion/wiki/Installation
and then keep reading about Hardware requirements, production setups and testing:
https://github.com/Security-Onion-Solutions/security-onion/wiki/PostInstallation

* Googled up some examples of working ping patterns (must be hex bytes):
http://www.tutorialspoint.com/unix_commands/ping.htm

* Test My IDS history: http://blog.testmyids.com/2015/01/8-years-of-testmyids.html

* Needed some help from this awesome reference to get db_connect in Kali 1, since Kali2 does this automagically with *msfdb init*:
https://github.com/rapid7/metasploit-framework/wiki/Setting-Up-a-Metasploit-Development-Environment

* To dig into this excellent resource:
https://www.offensive-security.com/metasploit-unleashed/


