Regeneration Tap with Security Onion Sensors
wal...@gmail.com
I am a new Security Onion (SO) user. Recently, I have begun setting up a complete network sniffing, IDS/IPS setup on my company's network instead of purchasing a more expensive solution.
We are using a 4x1 regeneration tap (https://www.network-visibility.com/en/products/products_regenerationtaps.php) to mirror the SPAN port on our managed switch. So the tap will be installed on our main LAN.
Our tap has 4 regeneration ports and we plan to use 4 systems each connected as a sensor to the tap. Each of these sensors are not connected to the main LAN.
My questions are as follows:
- If the 4 outputs of the tap goes into each sensor, does each sensor need to be configured to run a different type of program say snort/bro/wireshark ?
- How does one avoid duplicating work done by each sensor ?
- Where does one connect the master server ? Should the master be on the main LAN or a separate but accessible VLAN with the sensors ? How does the user access data from all these sensors ? All through the master ?
- Does the master server need to be connected to the tap ?
- If the master is receiving data from the sensors, wouldn't that show up on the tap and then lead to an infinite loop for the sensors ?
- Are the sensors remote configurable ? If so, how does one secure them from other users on the main LAN ? I guess putting them on a restriced VLAN helps.
Please advise. I have read your Production deployment doc and that is similar to what we are doing but some of my understanding isn't clear despite your docs and FAQs.
Thanks.
Vikas W.
Wes
Vikas,
To answer you questions,
- If the 4 outputs of the tap goes into each sensor, does each sensor need to be configured to run a different type of program say snort/bro/wireshark ?
Sensors are normally setup to run various tools, such as Snort/Suricata, Bro, netsniff-ng, Sguil, Squert, ELSA. You can choose if you wish to enable/disable some of these tools--that is up to you. Is there any reason you want to have multiple sensors, instead of allocating more RAM/CPU/NICs/Worker processes to a single sensor? The intent is to capture and review the same information, correct?
- How does one avoid duplicating work done by each sensor ?
One way to avoid duplication of effort is to run Best Practices:
https://github.com/Security-Onion-Solutions/security-onion/wiki/Best-Practices
- Where does one connect the master server ? Should the master be on the main LAN or a separate but accessible VLAN with the sensors ? How does the user access data from all these sensors ? All through the master ?
Many people connect to the master server through the use of a jump box/analyst machine--a VM running the Security Onion ISO image. This allows you to safely view and pull down data from the master, and gives you a local copy of Sguil, NetworkMiner, and Wireshark. The master should be able to communicate with the sensors on the following ports:
It is up to you on how you decide to implement such communication. The master receives alert data from the sensors, and stores it in a central database (securityonion_db). You query this database when you use Sguil (tcl/tk)/Squert (web). Otherwise, when using ELSA, the information is aggregated after being pulled from each sensor's ELSA database, and the results are provided to you. When requesting a PCAP via Sguil or CapMe, the master requests the PCAP from a specific sensor and provides the information for your viewing pleasure.
- Does the master server need to be connected to the tap ?
The master server DOES NOT need to be connected to the tap. It only needs to be able to communicate with the sensor via the ports mentioned in the "Firewall" page above.
- If the master is receiving data from the sensors, wouldn't that show up on the tap and then lead to an infinite loop for the sensors ?
I've not run into such an issue.
- Are the sensors remote configurable ? If so, how does one secure them from other users on the main LAN ? I guess putting them on a restriced VLAN helps.
The sensors can be managed by logging in over SSH (ex. putty), or through the use of Salt, a feature enabled by default when running Best Practices:
https://github.com/Security-Onion-Solutions/security-onion/wiki/Salt
Yes, you can assign the management interface for each to a restricted/protected area of the network.
Keep in mind, you should have at least two interfaces on each sensor--one for management, and one for sniffing.
Hope that helps to clarify some things for you.
Thanks,
Wes
wal...@gmail.com
> Sensors are normally setup to run various tools, such as Snort/Suricata, Bro, netsniff-ng, Sguil, Squert, ELSA. You can choose if you wish to enable/disable some of these tools--that is up to you. Is there any reason you want to have multiple sensors, instead of allocating more RAM/CPU/NICs/Worker processes to a single sensor? The intent is to capture and review the same information, correct?
I have a few old single CPU core blades with 2-4 GB RAM available and would like to put them to some use rather than buy a new system with 8-16 cores and 16GB RAM. Hence this is what I am going for. I am doing this as an experiment to learn how to do NSM, and all my taps and such are from eBay for now.
Thanks Wes for the detailed answers. Really appreciate it.
Regards
Vikas W.