Security Onion for multiple customers

[Ralph T]

First off. Awesome suite of tools you have integrated Doug! Thank you for your tireless efforts. This is the best open source project I have run across thus far.

Security Onion seems to be designed for the single enterprise network, with a standalone install, or server and one or more sensors per company.

I have about two dozen (rather cash poor) SMB's that I provide services for (jack of all trades). This keeps me hopping most of the day. I would like to provide some nightly network security analysis for some select customers. I envision deploying a sensor per customer and using a central copy of SO to investigate and analyze the days traffic.

So I have several questions:
1. Are any of you doing something similar... that is, monitoring and managing multiple sensors on different customer networks from a central location?

2. Is salt capable of managing the sensors in this sort of a configuration?

3. How difficult is it to add/remove sensors?

4. Am I asking this question in the right forum, or is there a more appropriate forum/group?

Thanks in advance

Ralph

[Matt Gregory]

Hi Ralph,

You could technically do what you are describing from a technical standpoint; as long as the various networks allow the sensors to connect back to the server, there shouldn't be any problem monitoring them all. Salt should also be able to manager your sensors like any distributed environment.  With that said, it doesn't seem like a good idea.

First, you'll be co-mingling different customers' data on the same server and in the same databases, so there are some privacy issues there.  There might even be some legal issues depending on the type of data (e.g., HIPAA, PCI, etc.) your are storing.

Second, if any of your customers have the same network address ranges, it might get confusing from an analysis standpoint due to the difficulty in distinguish the network any given traffic originated from. This might be mitigated due to different sniffing interface names (i.e., hostname-interface) but I'm not sure of all the ramifications.

You might consider instead installing a standalone deployment in each location and then connecting to each box independently from a local client.

Matt

Ralph

--
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at http://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.

[Ralph T]

Thanks Matt,

You make some very good points. It's probably smarter and safer to keep all the collected data within the confines of the customer LAN. That was my initial plan, but remote access has been a real challenge. I struggled for about three weeks on this.

I never could get x11rdp to function correctly.

The various flavors of VNC proved unreliable.

I am able to forward X sessions thru a compressed ssh tunnel OK. However, quite a few of my customers have ADSL which has a low upload speed. So performance is a big issue with that.

The No Machine folks came out with version 4, and retired version 3.5. Version 4 is quite a bit different, in that the free version no longer supports virtual sessions on the distant end. You have to use the physical display, which if run headless, will default to a very low, almost useless resolution. I finally figured out that I could trick the graphics cards into thinking there is a monitor, using a D15 connector and 3 resistors in sort of a VGA dummy load configuration. If I have to reboot the distant end, then I change the resolution back to something useful. It works OK. This seems to work the best out of everything I have tried so far.

I guess another option would be using some ssh port tunneling fu to bring the various web based consoles to my local machine. I haven't done much with that yet.

My goal is to monitor the small businesses that I work for. Do some periodic (nightly) analysis to determine "what's on the wire". Mitigate the threats, and educate the owners and users. I'm fighting the losing battle in the small business arena where there is little or no funding for this sort of thing. Owners are almost clueless. It's very frustrating.

Anyway thanks very much for your help. If you have any ideas that would be applicable to this task, you have my ear!

Ralph

[Jeremy Hoel]

Some other options could include:

Sending the alerts via rsyslog to a common SIEM.  Since the alerts would be tagged from the sites real ip address they could be labeled in the SIEM based on that unique field and you could quickly see the text of the alerts and then for more info, log into the site to do work.  The data itself would remain at the site but you could get quick reports and see trends across all of them.

You could use openvpn on the main sensors with port forwarding at the edge to get access to each local site and work 'on' their network with your tools.

If you had a static IP and they have a firewall and port forwarding you could connect directly

Ssh tunnels is a good option but there are multiple ports if you use more then just the web tools (sguil)

I'm willing to guess that each site is going to be different though in regards to access and ability to use the same connection method. 

[Matt Gregory]

Actually, you don't need to use RDP to connect remotely to a server or standalone box located on your customers' premises.  Instead, install the Security Onion ISO in a VM on a local machine, but without running sosetup.  Then, you can connect to all the web interfaces (e.g., Squert, Snorby, ELSA) via a web browser.  You can also run Sguil in your local VM and just point it at your customers' SO boxes. Lastly, you can SSH into the boxes for administration. You'll, of course, have to make sure you have appropriate firewall/routing/proxy settings configured at each location to allow you to remote in.

Alternatively, you could do a distributed deployment like you originally mentioned, with the SO server on your local premises and still connecting to it with an SO VM as described above. I would still recommend having a separate server for each customer so that you are not co-mingling their data.

Matt

[Ralph T]

Thanks to Matt and Jeremy for some great ideas and insight.