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
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
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
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