Security Onion – Server + Sensor Testing

Now that we are done with the installation, it's time to go testing! There are two parts to testing:

1. Generating packets - that will likely be caught by your IDS rules
   
2. Viewing alerts - from the Analyst workstation
   

Generating packets

What we really want to do here is to "generate packets that will generate IDS alerts". There are a couple of ways to achieve this:

1. Adding local rules to the Sensor and sending crafted packets (using Scapy or Hping3) to trigger alerts. This post explains the method.
   

   A note on updating local rules: Add your local rules to the /etc/nsm/local.rules file of your Server and then run the "sudo rule-update" command in your Sensor machine. This will update the rules in your Sensor(s). Remember that, running rule-update on the Server causes the Server to download rules from the internet. Running rule-update on the Sensor causes the Sensor to download the rules from the Server.
   

2. Replaying an existing packet capture (pcap) file using tcpreplay. I find this method to be simpler. For one, there is no dearth of (malicious) pcap files on the internet and Security Onion itself provides some pcaps in the /opt/samples directory. So this is the method I am going to use.
   

The command: tcpreplay –i eth0 –t /tmp/mypcaps/test.pcap replay the contents of test.pcap over the eth0 interface. To run the command you can either use sudo or run directly as root (by running sudo su - before)

From the tcpreplay output you can see that it has successfully replayed 36286 packets. Also, check if Snort has written any alerts in the /nsm/sensor_data/<Sensor Machine Name>-<Intf>/snort-1/

(The snort-1 indicates it is Snort sensor number 1. Here I have only one sensor so it's enough to check in snort-1 directory)

Viewing Alerts

Ok, now after generating packets and getting convinced that Snort has generated some alerts, let's go and check the output in 3 different tools installed by default on a Security Onion Server:

1. Sguil
   
2. Snorby
   
3. Squert
   

For testing, I want to view the alerts in these tools from my Windows 7 host machine (which I would like to think of as a separate analyst workstation).

SGUIL

Sguil is built on Tcl/tk. For launching Sguil on Windows you need to install Sguil client for Windows and Active Tcl Community edition:

After you download and install the pre-requisites, launch Sguil and select the interface:

In the "Selecting the interface" screen has a checkbox for each interface that you can check/uncheck. The checkboxes are not clearly visible in my machine (probably because of display settings…?)

So once you select the interface and "Start SGUIL", you will see an output similar to this:

As you can see Sguil provides a list of all the alerts. For each alert, you can choose to view the Packet Data and the Rule that triggered the alert. Sguil also allows you to do DNS lookups on the same screen.

SNORBY

Snorby is installed by default in port 444 of your Security Onion Server machine. You have to use the URL https://<IP of server>:444/ to access Snorby.

Below is the output from Snorby for the same PCAP file. I love Snorby for it's really cool UI and the excellent drill down capabilities it offers. For example, you could click on "High" severity events and it would take you to the list of those events. From there if you select an event it shows you the individual packet details and the rule that triggered the alert. The drill down is possible from anywhere on the Dashboard (including the graphs).

SQUERT

Squert is another Web based GUI for Snort alerts that you can access from the URL: https://<IP of Server>/squert

In addition to the drill-down provided (similar to Snorby) Squert also offers a Map feature that plots the IP addresses on a map. Also, it has a good summary tab as well:

Conclusion

In this article we have seen how to test the setup created earlier. There are lots of interesting features in each of these GUI tools. But those will have to be covered in separate articles themselvesJ

How I built a simple IDS Lab

Last week I wanted to setup an IDS lab for writing and testing out Snort rules. I was not sure where exactly to begin but the idea that I had in mind was something like this:



Given the complexity of this architecture I think I should write a line or two explaining the componentsJ:

1. The Sensor – Sniffs the packets, validates them against rules and sends any alerts to the server. For my requirement, this is the machine that runs the Snort IDS.


2. The Server – Collects and stores the alerts and provides the necessary infrastructure for viewing/analyzing alerts. In other words, this is the host for any of the GUIs for Snort.


3. The Analyst Workstation– This is just about any machine using which an Intrusion Analyst can login to one of those Snort GUIs, view and take further action on the generated alerts.

As I was hunting around the internet to implement this setup using VMware workstation, I came across Security Onion (or SO for short). The description in their site goes:

Security Onion is a Linux distro for intrusion detection, network security monitoring, and log management. It's based on Ubuntu and contains Snort, Suricata, Bro, OSSEC, Sguil, Squert, Snorby, ELSA, Xplico, NetworkMiner, and many other security tools. The easy-to-use Setup wizard allows you to build an army of distributed sensors for your enterprise in minutes!


Quite impressed by what I had read, I immediately downloaded the Security Onion ISO (~1.4 GB) from Sourceforge. True to their word, setting up the lab turned out to be quite simple and elegant. Yeah, ok, the next best thing since sliced bread…. Barring the initial struggles, I was able to get my lab running in about 2-3 hours.You may refer the steps I followed during the setup from here.

Security Onion - Server + Sensor Setup

This post follows from the context of "How I setup an IDS Lab"

In this article we’ll see how to create and test an IDS Sensor-Server setup using Security Onion and VMware Workstation. I have divided the setup into 6 steps:
1. Pre-installation
2. Installation
3. Cloning (optional)
4. Server Setup
5. Sensor Setup
6. Post-Setup

PRE-INSTALLATION

So let's get started! In the pre-installation there are 3 simple steps –

1. Download the ISO from sourceforge.net,


2. Configure the hardware details and the ISO to be used for your VM.


3. Boot into the Live system first. From there we will install the OS to disk in the next step.

INSTALLATION

The installation is simply point-and-click. You need to double-click on the "Install Security Onion…" CD icon in the desktop and the OS installation gets started. If you have done a Windows installation then this is verisimilar to that – next, next and finish!

After you install Onion requests for a restart. Please do the restart and then setup the basic networking. Here I am using DHCP instead of static IP because I didn't want to go experimenting with gateways, DNS servers and domain names. In fact I don't even want this setup to connect to the internetJ.

CLONING

The pre-installation and installation steps take about an hour. And let's say if I botch up the configuration in any of the next steps I will have to restart from the beginning (yaawwwnn..). In order to avoid this I am taking a snapshot. I didn't want to mention this as a separate step so just added it under cloning J.

And, the rational for cloning goes like this - in this setup we are going to need a Server and a Sensor. The setup of the both these systems is the same till the above step. So I thought it would be easier to take a clone of the VM and use the clone as a Sensor. The cloning hardly takes a few minutes whereas installing the OS for the Sensor machine will take another 1 hour. Hmm… same logic again…

However, if you are using VMware Player and you don't have support for cloning then you can install the sensor again as a separate machine. In this case,  you don't have to change the hostname and delete the "server" user when setting up the Sensor machine.

SERVER SETUP

When the cloning completes we have two VMs. For now we will allow the cloned VM to rest and focus our attention on the original VM we created. In this step I am going to install the required software on the Server machine. I wish to keep this install as minimalistic as the installer allows. I say this because the installer doesn't ask me whether I want to disable Snorby. They are installed by default. So wherever I get a chance to disable something – like Salt and ELSA – I am going to do it.

After the setup is completed, I verify it using "sudo sostat | less". This is a very useful command to check the status of the services that you have installed in your machine. In case you want to restart the services you can run "sudo service nsm restart".

I then create a new user called "sensoragent". This user is required by the Sensor machine (which have not yet started to configure) to send data to the Server. And of course better user names can be chosenJ. The user must also be able to run commands using "sudo" and to enable this I use the visudo command. The command just opens up the GNU nano editor. Add a line for the sensoragent user in the file and save the file (Ctrl+o) and exit (Ctrl+x).

SENSOR SETUP

As you remember right, the Sensor machine was created as a clone of the Server machine. So the first thing I am going to do after logging into the Sensor machine is to change its name to from SERVER SO to SENSOR SO. For this I need to edit two files: /etc/hosts and /etc/hostname. After that I have to create a new user called "sensor" and add it to the sudoers group (using visudo).

I can then logout and then login as sensor user, delete the "server" user (to avoid confusion) and then continue the sensor setup. I guess the sensor setup should be fairly self-explanatory. If you did not understand earlier why I created the "sensoragent" user then you will likely understand it now.

POST-SETUP

Now you have the Server and the Sensor machines up and running successfully. It is time to test. At this point also you might want to take individual snapshots of the Server and the Sensor machines (who knows how the testing might turn out?)

Which Networking Mode to choose for your VM?

This article assumes you are using VMware Workstation or VMware Player.

Whenever you want to install or deploy a VM, it is important to answer the question of "Which networking mode should I use for this VM? Should it be a bridge, NAT or host-only?"

And the answer to this question – like many other good questions – depends on what you want to achieve. Should your VM interact with the host? Should it be able to connect to the internet? Should it be able to talk to other VMs in my host? If so, what kind of network configuration the other VMs should have?

So, for working through this every time, I thought I'll create a reference table that shows the behavior of VMs in these three different networking modes:

For verifying this table, I just fired up a couple of VMs, adjusted their network settings and did a series of ping tests to confirm.

And finally, based on this exercise I also wanted to add a few more observations:

1. The host OS can always interact with your VM irrespective of the VM's Network Configuration.
   
2. When you use "Bridged Mode" for your VM the IP address of the VM will be in the same subnet as the host.
   
3. When you use "NAT mode" for your VM, the IP address of the VM will be in the 192.168.74.0/24 subnet.
   
4. When you use "Host-only mode" for your VM, the IP address of the VM will be in the 192.168.233.0/24 subnet.
   
5. In "Host-only mode" your VM can ONLY interact with other VMs that are in "Host-only mode". They cannot interact with your host.

Figuring out Linux start-up from Oracle Developer Days

Few months back I had downloaded the Oracle Developer Days appliance. It had Oracle Linux with Oracle 11g and APEX installed. When I boot the machine Oracle database was already started and running. I wondered – How is it done? The rest of this post explains this "how". 

While preparing for the GSEC exam, I have read that during Linux boot up the first process to be started is the init (initialization). I also know that init is a daemon process and refers to the /etc/inittab file for further instructions. I go and check out the inittab file given below:

# Default runlevel. The runlevels used by RHS are: #   0 - halt (Do NOT set initdefault to this) #   1 - Single user mode #   2 - Multiuser, without NFS (The same as 3, if you do not have networking) #   3 - Full multiuser mode #   4 - unused #   5 - X11 #   6 - reboot (Do NOT set initdefault to this) # id:5:initdefault:   # System initialization. si::sysinit:/etc/rc.d/rc.sysinit   l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6

From the file I get some more information to proceed further.

1. 
   
   There are 7 run levels (0 to 6)


2. 
   
   The initdefault keyword specifies the default run level. Here the default run level is  5 (which is “X11” aka the X-Windows System)


3. 
   
   The directory for the run level is /etc/rc.d/ Well, here is where I should go next!

---

A listing on the /etc/rc.d directory gives me the following output: 

[root@localhost rc.d]# ls -ralt total 124 -rwxr-xr-x  1 root root   220 Jul  4  2009 rc.local -rwxr-xr-x  1 root root  2255 Jul  4  2009 rc -rwxr-xr-x  1 root root 27752 Mar  3  2010 rc.sysinit drwxr-xr-x 10 root root  4096 Apr 15  2010 . drwxr-xr-x  2 root root  4096 Aug 22  2012 rc6.d drwxr-xr-x  2 root root  4096 Aug 22  2012 rc5.d drwxr-xr-x  2 root root  4096 Aug 22  2012 rc4.d drwxr-xr-x  2 root root  4096 Aug 22  2012 rc3.d drwxr-xr-x  2 root root  4096 Aug 22  2012 rc2.d drwxr-xr-x  2 root root  4096 Aug 22  2012 rc1.d drwxr-xr-x  2 root root  4096 Aug 22  2012 rc0.d drwxr-xr-x  2 root root  4096 Aug 20 21:29 init.d drwxr-xr-x 97 root root 12288 Aug 20 21:32 ..

From the above output it looks like there are separate directories for each run level. However, I am interested only in exploring run level 5 and that too processes named oracle (remember, the original question was "how does Oracle database start automatically at the time of system boot?". So I navigate to the /etc/rc.d/rc5.d and search for “oracle” :

[root@localhost rc5.d]# ls -ralt | grep -i ora lrwxrwxrwx  1 root root   18 Apr  6  2010 S99oracle -> /etc/init.d/oracle

Before continuing the chase, let me mention something about this name "S99oracle". The S indicates that the file is a start script. When Linux boots up, the S* scripts in the default run level directory are executed with the argument "start". The 99 indicates the priority of the script (1 being the highest priority or first to be executed). And of course "oracle" indicates the script could have something to do with starting up the Oracle database. With this understanding in mind, I open the S99oracle file:

#!/bin/sh # # export JAVA_HOME=/usr/java/latest export ORACLE_HOME=/home/oracle/app/oracle/product/11.2.0/dbhome_2 export ORACLE_HOME_LISTENER=$ORACLE_HOME export ORACLE_TRACE=Y export PATH=$JAVA_HOME/bin:$ORACLE_HOME/bin:$PATH echo $PATH   # Source function library. . /etc/rc.d/init.d/functions   # See how we were called. case "$1" in   start)         su - oracle -c "$ORACLE_HOME/bin/lsnrctl start"         su - oracle -c $ORACLE_HOME/bin/dbstart         su - oracle -c "/home/oracle/apexlistener.sh start"         ;;   stop)         su - oracle -c $ORACLE_HOME/bin/dbshut         su - oracle -c "$ORACLE_HOME/bin/lsnrctl stop"         su - oracle -c "/home/oracle/apexlistener.sh stop"         ;;   restart|reload)         su - oracle -c $ORACLE_HOME/bin/dbshut         su - oracle -c "$ORACLE_HOME/bin/lsnrctl stop"         su - oracle -c "/home/oracle/apexlistener.sh stop"         su - oracle -c "$ORACLE_HOME/bin/lsnrctl start"         su - oracle -c $ORACLE_HOME/bin/dbstart         su - oracle -c "/home/oracle/apexlistener.sh start"         ;;   status)         $ORACLE_HOME/bin/lsnrctl status         ;;   *)         echo $"Usage: $0 {start|stop|restart|reload}"         exit 1 esac   exit 0

As expected the S99oracle file contains 3 other scripts that get called - lsnrctl (to start the database listener), dbstart (don't know what this is, will have to check), apexlistener.sh (to start the Apex DB Listener). Now moving on to the dbstart file... 

#!/bin/sh # # $Id: dbstart.sh 22-may-2008.05:05:45 arogers Exp $ # Copyright (c) 1991, 2008, Oracle. All rights reserved.  #   ################################### # # usage: dbstart $ORACLE_HOME # # This script is used to start ORACLE from /etc/rc(.local). # It should ONLY be executed as part of the system boot procedure. # # This script will start all databases listed in the oratab file # whose third field is a "Y".   If the third field is set to "Y" and # there is no ORACLE_SID for an entry (the first field is a *), # then this script will ignore that entry. # # This script requires that ASM ORACLE_SID's start with a +, and # that non-ASM instance ORACLE_SID's do not start with a +.

"This script will start all databases listed in the oratab file" - Hmm.... At this point I have understood how the Oracle database gets started automatically when Linux boots up. But just for completeness' sake. I shall take a look at the oratab file and get off this file chain... 

[oracle@localhost /]$ find . -name "*oratab*" 2>/dev/null ./home/oracle/app/oracle/product/11.2.0/dbhome_2/install/oratab ./etc/oratab

There are two versions, which one does Oracle DB use? I did a diff to find out if the content of the files was different:

[oracle@localhost bin]$ diff /etc/oratab /home/oracle/app/oracle/product/11.2.0/dbhome_2/install/oratab 1,20d0 < # < # This file is used by ORACLE utilities.  It is created by root.sh < # and updated by the Database Configuration Assistant when creating < # a database. < < # A colon, ':', is used as the field terminator.  A new line terminates < # the entry.  Lines beginning with a pound sign, '#', are comments. < # < # Entries are of the form: < #   $ORACLE_SID:$ORACLE_HOME:<N|Y>: < # < # The first and second fields are the system identifier and home < # directory of the database respectively.  The third filed indicates < # to the dbstart utility that the database should , "Y", or should not, < # "N", be brought up at system boot time. < # < # Multiple entries with the same $ORACLE_SID are not allowed. < # < # < orcl:/home/oracle/app/oracle/product/11.2.0/dbhome_2:Y

The file /home/oracle/app/oracle/product/11.2.0/dbhome_2/install/oratab is a ZERO byte file. All the entries are present in the /etc/oratab file only.

Before ending this article, let me summarize some important points about /etc/oratab file:

1. It’s used by ORACLE utilities


2. It is created by root.sh


3. It is Updated by DBCA when creating a database. Important: If you create a database through CREATE DATABASE command then the /etc/oratab DOES NOT get updated


4. The records in the file should be in the format $ORACLE_SID:$ORACLE_HOME:<N|Y>:

 

Wireshark - How to carve out a File from an SMB Capture?

Just now made a mind map on one approach to extract a file from a SMB packet capture. Image is attached below:



Of course, the easiest way to extract files from an SMB capture is to use Wireshark's File --> Export Objects --> SMB/SMB2 option. But I feel the first option is more fun :)