2 Server Set Up; SecOnion & Storage

424 views
Skip to first unread message

James Clayton

unread,
Feb 17, 2017, 11:49:42 AM2/17/17
to security-onion
I've gotten two servers. One I'm going to use for Security Onion, the other has 16TiB of storage. I'm thinking that I should install Fedora on the storage box, then mount a path on the Security Onion to write the traffic data there. Has anyone done a set up like this?
Message has been deleted

Wes

unread,
Feb 17, 2017, 7:57:44 PM2/17/17
to security-onion
On Friday, February 17, 2017 at 11:49:42 AM UTC-5, James Clayton wrote:
> I've gotten two servers. One I'm going to use for Security Onion, the other has 16TiB of storage. I'm thinking that I should install Fedora on the storage box, then mount a path on the Security Onion to write the traffic data there. Has anyone done a set up like this?

James,

Is there any particular reason you are not using the storage/drives for the box with Security Onion installed?

If you are going to use two separate boxes, it may be best to first copy/backup your data, then send it off to the remote server/share, as you may experience issues with writing/retrieving data to/from the share.

Also, is there any reason you are choosing to use Fedora for the other machine, or is this personal preference?

Thanks,
Wes

James Clayton

unread,
Feb 20, 2017, 6:12:13 PM2/20/17
to security-onion
Hi Wes,

The company purchased two servers. They didn't tell me why they wanted to have the storage on another server. Based on what you said, and my assumptions, I am going to ask them if I can install SO on the storage device. I chose Fedora as a personal preference. I absolutely agree that the IO is going to be a problem by storing remotely.

Let me ask you, would it make sense to capture pcaps then send them to the remote server. One thing I cannot work out with SO is the methodology for capturing pcaps. I can always use netsniff-ng or wireshark, but as soon as I save the pcap the monitoring stops.

Is there a method to be constantly writing the traffic information then go back in time to pull out data I think I should review? Let's say my alert system, ArcSight, sees something. I'd like to go back to SO and analyze the traffic.

James

Wes

unread,
Feb 20, 2017, 6:35:08 PM2/20/17
to security-onion

James,

You may want to see:

https://github.com/Security-Onion-Solutions/security-onion/wiki/netsniff-ng

When full packet capture is enabled through setup, netsniff-ng automagically sniffs traffic and records it to /nsm/sensor_data/HOSTNAME-INTERFACE/dailylogs/YYYY-MM-DD/.

The way Security Onion is built, it allows analysts to pivot from IDS alerts and other logs, to PCAP to gain greater context around an event. This allows those previously captured packets to be correlated to events and retrievable later on.

If you are going to send them to a remote server, I would just be careful about how often you prune the PCAPs from the Security Onion machine, as you may end up trying to pivot from an alert/event in Sguil/Squert/ELSA and not be able to since the PCAP has already rolled off or been moved.

Storage of PCAPs, Bro logs, and ELSA logs are controlled by settings defined in /etc/nsm/securityonion.conf (CRIT_DISK_USAGE) and in /etc/elsa_node.conf (log_size_limit).

By default, the /nsm directory will be purged of old files when disk utilization reaches 90 percent (by /usr/sbin/nsm_sensor_clean). ELSA, by default, will take up half of this and have its log_size_limit value defined accordingly. The rest of space will be allotted for Bro logs and PCAPs.

Ex. 100 TB Drive assigned to /nsm:

~50 GB for ELSA logs
~40 GB for Bro logs/PCAPs

Hope this helps to clarify.

Thanks,
Wes

James Clayton

unread,
Feb 21, 2017, 5:56:14 PM2/21/17
to security-onion
I found this article: https://github.com/Security-Onion-Solutions/security-onion/wiki/Hardware

It looks like the master/sensor scheme is why they orginally ordered two servers. A master and a storage. For a sensor do I just collect the logs and then access them with the master? Or do I copy the pcaps to the master to examine? What do you think?

Wes

unread,
Feb 21, 2017, 6:46:04 PM2/21/17
to security-onion
On Tuesday, February 21, 2017 at 5:56:14 PM UTC-5, James Clayton wrote:
> I found this article: https://github.com/Security-Onion-Solutions/security-onion/wiki/Hardware
>
> It looks like the master/sensor scheme is why they orginally ordered two servers. A master and a storage. For a sensor do I just collect the logs and then access them with the master? Or do I copy the pcaps to the master to examine? What do you think?

James,

The main analyst tools (Sguil/Squert/ELSA) included in Security Onion allow you to view the aggregation of alerts and events across all of your sensors.

Things like Bro logs, PCAPs, and ELSA logs are stored locally on the sensors, but alert data is sent by sensors to the master server to be accessed via sguild (the server process behind the data provided to/accessible by Sguil/Squert). When you pivot to PCAP transcript, you are actually pulling the PCAP data from the respective sensor (where the traffic was recorded). Each sensor has an ELSA node, and this is queried by the master server (when running ELSA queries), then the results are aggregated/returned to the user in the browser.

In your case, you could have the master server, with lesser storage, and the other machine as the sensor.

Once setup has been run on both machines, for everyday purposes of examining alerts, you may want to just access the master servers via a dedicated analyst machine, spun up from the Security Onion ISO image.

You can run so-allow on the master server (https://github.com/Security-Onion-Solutions/security-onion/wiki/Firewall#so-allow) to add firewall exceptions for the analyst machine, point your Sguil client to the master server IP, and go from there (as well as accessing Squert and ELSA from the Chromium browser).

Thanks,
Wes

James Clayton

unread,
Feb 23, 2017, 12:19:55 PM2/23/17
to security-onion
for anyone who finds this post, there is a similar post in this group. here is the link https://groups.google.com/forum/#!topic/security-onion/M3-k_INON20

James Clayton

unread,
Feb 24, 2017, 9:30:14 AM2/24/17
to security-onion
Hi Everyone I found the perfect video for Master / Sensor on LinkedIn. Thanks for the information: https://www.linkedin.com/pulse/security-onion-production-master-server-slave-sensor-jesse
Reply all
Reply to author
Forward
0 new messages