Installing SecurityOnion on oVirt

- 7 minutes read - 1363 words

Following on from my earlier post about getting the SecurityOnion ISO loaded into my oVirt cluster we’re going to cover how to set up an evaluation IDS system for your homelab. We will assume that you’ve already created your ISO domain, downloaded the latest SO ISO, and uploaded it to oVirt.

Packet Mirror vNIC

My first thought when I launched into this was buying a network tap and putting it inline between my VM LAN switch and the router. Unfortunately, I’m trying to do this on effectively zero budget so a tap that could handle gigabit traffic was a little out of my price range. In that case, virtualization to the rescue!

My current oVirt host has two physical NICs installed and two networks defined; ‘managment’ and ‘data’. All of the VMs that are currently deployed have their NICs attached to the ‘data’ network and ‘management’ is reserved for things like SPICE traffic, hosted engine calls, and (eventually) VM migration. This means that for the purpose of our tests we only care about the data flowing on the ‘data’ network because that is the traffic coming in and out of our VMs.

To be able to view this traffic we need to go to Network -> vNIC Profiles and create a new profile. We will want to pick our data network and ‘No Network Filter’ as our filtering choice. Then most importantly we need to check the option labeled ‘Port Mirroring’ which will allow this NIC to view all packets that are sent or received on our data network from this host. It is important to realize that this profile only allows a VM connected to it to see the data network traffic on the host it is currently resident on. If you have an actual multi-node cluster you will need to deploy multiple sensor VMs using this vNIC profile to capture traffic from each host.

VM Requirements and Install

I’m only monitoring traffic from 3-5 VMs at a time so I went for the minimum possible hardware requirements per the documentation. If I eventually get more nodes I will probably set up a primary VM to handle ingestion and processing with smaller sensor VMs on each host to actually monitor the traffic. With that in mind I created a new VM from the ‘Blank’ template with 4 CPU cores, 8GB of RAM, 100GB of disk space, and 2 NICs. One NIC is connected to the data network with the default vNIC profile and the other also connects to the data network but using the special port mirrored vNIC profile instead. I also attached the SecurityOnion ISO I uploaded earlier and set it as the primary boot device.

Once the install GUI boots up go through the standard install configuring timezone and other applicable settings. I also made sure to set up my disk with LVM as this makes adding additional space far easier in the future should the need arise. I also configured the installed user to share a name with the SO application user I will be creating later in the install process, in my case idsadmin. When the primary installation is finished, reboot the VM and remove the SO ISO from it’s configuration so we boot immediately to the new installation.

Now that the install is finished and we’ve booted to the new install it is time to login via the graphical console. From the oVirt UI we will want to pull down the remote viewer configuration file and open it up to get at the desktop login window. Logging in as the OS user we created during the install we will be presented with the default desktop. To begin the sensor configuration we will open a terminal with <ALT>+<SHIFT>+T and running sudo sosetup-minimal.

I selected which VM NICs would be the monitor and sensor interfaces by comparing the oVirt UI with the output of ip addr and matching MAC addresses. I also chose to use static IP addressing because I already had this server added to my FreeIPA DNS setup and will hopefully be integrating it more fully with FreeIPA in the future. I also chose to configure the sniffing interface since this is going to at least start as a standalone instance instead of just being a master server with deployed sensors. Once the first round of configuration is done, reboot the server when prompted and log back in to the GUI.

To finish the setup we need to run sudo sosetup-minimal one more time and skip the network configuration step. When asked for the type of install select the ‘Evaluation Mode’ setting to configure a base install which will require the minimum CPU and RAM. When asked for the new application username I chose to repeat the OS username and password I used earlier but any combination is sufficient. Otherwise I allowed the installer to take all of its defaults and waited for it to finish. The install did end up taking quite a while with most of the configuration time spent on setting up the Elastic stack which handles all of the log management and searching. Once the setup is finished you should be able to access all of the various SO tools via links provided on the desktop.

In my case I had some trouble accessing Kibana after the initial setup. When I tried to access the application I could provide my credentials but I would get a HTTP 502 error when it tried to load the actual application. In the end the solution seems to have been to reboot the VM and wait a little bit for everything to come back up happily.

If you run into trouble you can always check the status of the components with sudo so-status and can attempt to start any failed or stopped services with sudo so-start. More information on SO service management can be found here.

oVirt Guest Agent

The last step for me was getting oVirt to correctly communicate with the VM and list things like IP address and FQDN correctly. It should have been as simple as running sudo apt-get install ovirt-guest-agent as per the documentation, but it was not to be! After installing the package and failing to start the service I ran into a couple of different issues. First was that the log directory /var/log/ovirt-guest-agent was owned by root:root instead of by the guest agent user ovirtagent. This meant that even when the service crashed I had no idea why because the logfile couldn’t be written out. Quick fix was to simply change the permissions in question with sudo chown -R ovirtagent:ovirtagent /var/log/ovirt-guest-agent and continue on troubleshooting.

Next, by following along in the log I saw that the service was trying to access a device file called /dev/virtio-ports/com.redhat.rhevm.vdsm and failing. A quick explore through the filesystem showed why…it didn’t exist! But we did have /dev/virtio-ports/ovirt-guest-agent.0 which looked promising. Around the same time I came across this mailing list discussion which both described my problem and a solution.

You want to edit the service configuration file at /etc/ovirt-guest-agent.conf and modify the device line in the [virtio] section to point to the port name we found earlier in /dev. After that, we also need to make sure udev gives that port the correct permissions so we will create a new rule file, shown below.

# /etc/udev/rules.d/55-ovirt-guest-agent.rules
SYMLINK=="virtio-ports/ovirt-guest-agent.0", OWNER="ovirtagent", GROUP="ovirtagent"

Afterwards refreshing udev with sudo udevadm trigger --subsystem-match="virtio-ports" should be enough to get everything in place. From there you can use SystemD to start and enable the ovirt-guest-agent service.

Conclusion

I’m still in the early stages of testing out this install path but so far it is looking pretty promising. I’m getting traffic in to the system with the mirrored port and sitting around 30% utilization overall for CPU and memory. My VM network also isn’t terribly active but it is an interesting testbed in the meantime. I may look into generating some more aggressive traffic to see what the load looks like but for now just learning the interface is going to be a plus.

References