Sensor CPU requirements

[Kevin TeStrake]

I've read the FAQ and trolled through the archives, but I can't seem to find anything that documents CPU requirements for sensors.

I've got a 5-sensor deployment planned in a production network, all tapping 1GBps links.

Most of the sensors will see ~500 GB/day, with one of the sensors hitting 3TB/day (monitoring two links).

I've seen reference to two CPU cores per monitored link (Bro + Snort) plus a core or two for OS overhead, which leads me to start with 4-cores for the smaller units and 8-cores for the larger unit.

I'm buying all new gear for this and I don't know what the CPU needs will be. At home I'm running Security Onion in a stand-alone instance on an Xeon 1220 v3 and am perfectly happy, but I have far less traffic, as one can imagine.

For the smaller sensors, am I looking for something bigger than an Intel Xeon E3-1246 v3? (4-cores, 8-threads)

Smaller Units - ThinkServer RS140 w/E3-1246 v3, 16GB RAM, 8TB HDD, dual Intel NIC.

Larger Unit - ThinkServer RD450 w/E5-2620 v3, 32GB RAM, 18TB HDD, quad Intel NIC.

Since this hardware is being purchased, I want to get enough resources to be happy with the results without throwing away money.

Anyone have advice?

Thanks,
Kevin

[Wes]

Kevin,

I think the cores could be on point, but I would recommend getting as much RAM as you can--it's relatively cheap and will only benefit you. As for storage, it really depends on how much data you want to keep (if its PCAPS + Bro Logs + ELSA, etc).

You can take a look here to get an idea of how much storage for each--disk is cheap, so I would try to get as much as possible (Rounded up, performing full PCAP and everything else would be around 1TB a day for a 50 50Mb/s link):
https://github.com/Security-Onion-Solutions/security-onion/wiki/Hardware#storage

I believe the Intel NICs are always recommended, so I think you would be okay there.

Thanks,
Wes

[Doug Burks]

On Fri, Jan 29, 2016 at 12:28 PM, Kevin TeStrake <ke...@testrake.net> wrote:
> I've read the FAQ and trolled through the archives, but I can't seem to find anything that documents CPU requirements for sensors.
>
> I've got a 5-sensor deployment planned in a production network, all tapping 1GBps links.

A very rough ballpark estimate would be 200Mbps per Snort instance or
Bro worker. So if you have a fully saturated 1Gbps link, then you'll
want at least 5 Snort instances and 5 Bro workers, which means you'll
need at least 10 CPU cores for Snort and Bro with additional CPU cores
for netsniff-ng and/or other services.


--
Doug Burks
Need Security Onion Training or Commercial Support?
http://securityonionsolutions.com

[Marco Fahrner]

Just to make sure I get that right. For his example that would mean he'd need 10 cores per fully saturated 1Gbps interface? Doesn't that depend on the CPU a lot though? Or is the limiting factor the snort process itself, not the computational power of the CPU that backs it? Because that sounds quite a lot to me.

[Doug Burks]

Hi Marco,

As I mentioned, it's a "very rough ballpark estimate" :)

It does depend on the CPU speed and many other variables as well, such as:
- how many rules you have enabled
- what kind of rules you have enabled
- exactly how much traffic you have
- exactly what kinds of traffic you have
- what kinds of traffic are you excluding via BPF

So if you have a fully saturated 1Gbps interface, you may be able to
get by with less than 5 snort instances if you're able to trim your
ruleset significantly and exclude traffic via BPF.

But again, this is a "very rough ballpark estimate". Your mileage may vary.

> --
> 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 https://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.

[Marco Fahrner]

Okay, thanks for the insight Doug! I feel like it's pretty hard to find decent information on system sizing for this matter anyways. I've basically done this on my system by trial-and-error and doing exactly as you said: removing all unneeded traffic with BPF (for example the TSM backup traffic, etc. which would otherwise also use heaps of storage).

[Seth Hall]

> On Feb 3, 2016, at 8:25 AM, Marco Fahrner <hsp...@gmail.com> wrote:
>
> I've basically done this on my system by trial-and-error and doing exactly as you said

Don't feel bad about that. You're doing the same that everyone else is doing. :)

There isn't an answer to the question of system sizing. Speaking as a Bro developer, you'd be surprised how many little changes that you wouldn't expect to make a difference can make a huge difference (positive and negative). In Bro we also continually have small ups and downs in performance and behavior between releases as we rework various systems and add new scripts and functionality.

.Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/