Re: [security-onion] Capacity planning help?

[Peter Feger]

This is what I use to give a good "guestimate" of the disk usage. It
has worked well for me. (Thanks to RMB for this calculation)

Drive storage can be calculated by the following:
"Avg Link Utilization in Mbps" * 4.5 == "Storage/Day in GBs" This is
valid on the Sensor side only! Database is really dependent on how
long you keep the data.

If you are seeing 800Mbps you would need about 3.6Tb of disk per day.

Using the GigaVue I will assume that you are setup for aggregated
taps. You will want to keep an eye on the GigaVue for load and
dropped packets if you are going to use the 1G copper. Taking a 10G
feed and piping it down to a 1G will place a load in the Gigamon
Appliance. If you can I would suggest that you utilize the fiber
tool ports to eliminate back pressure on the GigaVue.

Best of luck

Pete





On Wed, Jul 25, 2012 at 9:31 AM, Gregory Pendergast
<greg.pe...@gmail.com> wrote:
> I've been testing SO on an undersized box for a little while now, and could use some help determining what I need for production use.
>
> Right now all I intend to monitor is our internet pipe, which is a 10Gig link. However, that bandwidth isn't near saturated, and we generally see 800Mbps - 2 Gbps. The sensor will be monitoring from a 1Gig tool interface on a GigaVue tap.
>
> Given that information (let me know if more is needed), what kind of rig do I need to support that environment? Right now I'm running both server & sensor on a server w/ ~3.5GB memory and 1.5TB of disk space. Naturally, I'm blowing that out of the water, and we're in a slow period on the network (I work for a university).
>
> I was originally planning a single server installation (server + sensor) for production, but separating those will probably prove more scalable.
>
> Thanks,
> Greg
>
> --
>
>

[Peter Feger]

Greg,

For the server side it will take far less disk. You are basically
setting up a LAMP stack. If you are not going to be running mysql on
the same box I would use a VM. The POC box MySQL had about 55,000
events and only used about 4 gig of data. I have never had any
positive experience with databases running on a VM as such I either
put them on dedicated hardware or will share it with the server on
hardware.

For the sensor; 8G ram dual cpu and as much disk as you cant throw at
it. SATA is fine

If you are going to be seeing 800Mbps I would use 32G Ram, 2xIntel
E5-2670. Ive noticed over the years tat a 1G interface usually will
saturate at about 600Mbps. Get Intel nics (QP 1GigE) and at least one
Intel X520 for the fiber. With that much data hitting the sensor you
will want SAS drives ar at the very minimum near-inline SAS.

My current setup is a 10G feed from the Gigamon. that tool port has 4
1G taps connected to it. I currently use 8x3Tb Near-inline-SAS Sata
drives on a raid5 with no hot spare to get the most disk space I can
for pcaps and session data. 32G Ram, 2 Intel E5-2670 CPU's I can
handle 2 feeds with about 1 week of data retention

Suggested sensor set up
RAM 8 gig
CPU dual Xeon 2.4Ghz or better
Intel Nics
7200 RPM SATA drives as much as you can get on board. RAID5 No Hot
Spare, Split on 2 virtual disks, 25 G for OS and remainder for /nsm I
run /nsm at 96% of capacity)


Regards

Pete


On Thu, Jul 26, 2012 at 10:48 AM, Gregory Pendergast
<greg.pe...@gmail.com> wrote:
> On Wednesday, July 25, 2012 11:46:47 AM UTC-4, magickal1 wrote:
>> This is what I use to give a good &quot;guestimate&quot; of the disk usage. It

>> has worked well for me. (Thanks to RMB for this calculation)
>>
>> Drive storage can be calculated by the following:

>> &quot;Avg Link Utilization in Mbps&quot; * 4.5 == &quot;Storage/Day in GBs&quot; This is

>> valid on the Sensor side only! Database is really dependent on how
>> long you keep the data.
>

> Thanks Pete. Acknowledging that it depends on how long you retain data, I assume the per/day disk requirements for the Server component (assuming I split those functions) would be substantially less. Am I right about that?
>
> Also, I've reviewed the hardware requirements page, but that's a little sparse. Do you have any suggestions for CPU and memory requirements on the server and/or CPU requirements on the sensor? (I'm assuming that the 1GB+ RAM for each interface applies more to the sensor than the server, so I'm taking that as the minimal sensor guideline.)

>
>
>> Using the GigaVue I will assume that you are setup for aggregated
>> taps. You will want to keep an eye on the GigaVue for load and
>> dropped packets if you are going to use the 1G copper. Taking a 10G
>> feed and piping it down to a 1G will place a load in the Gigamon
>> Appliance. If you can I would suggest that you utilize the fiber
>> tool ports to eliminate back pressure on the GigaVue.
>

> Right now we only have 1GB tool ports on the GigaVue. I'm going to spec my sensor w/ a 1Gig & 10Gig interface card, then hope to get funding to add one or more 10G tool ports to the GigaVue as well. Thanks for the guidance though. I do need to keep a closer eye on the dropped packets.
>
> Thanks again,
> Greg
>
> --
>
>

[Castle, Shane]

I have a problem with this "rule of thumb" of taking your average traffic flow in Mbps and multiplying by 4.5 to give a daily disk requirement in GB.

Suppose we use my numbers: 25Mbps is my average flow. If I use the RoT I get ~113GB. Now, let's look at the actual arithmetic:

Number of seconds/day = 86,400
25Mbps = 3.125MB/sec
3.125 x 86,400 = 270,000 or 270GB/day; if powers of 1024 are used, then we could say 251.5GB/day. This is quite a different number from 113GB/day.

Looking at some recent days bears out the full arithmetic exercise:

scastle@nsm:/nsm/sensor_data/nsm-eth1/dailylogs$ du -sh *
104G 2013-02-02
86G 2013-02-03
261G 2013-02-04
276G 2013-02-05
299G 2013-02-06
289G 2013-02-07
269G 2013-02-08
97G 2013-02-09
69G 2013-02-10
238G 2013-02-11
330G 2013-02-12
221G 2013-02-13

So why does this "rule of thumb" persist? I think it leads folks to an incorrect idea of how to size their hardware requirements.

--
Shane Castle
Data Security Mgr, Boulder County IT

-----Original Message-----
From: securit...@googlegroups.com [mailto:securit...@googlegroups.com] On Behalf Of Benson Mathews
Sent: Wednesday, February 13, 2013 11:52
To: securit...@googlegroups.com
Subject: Re: [security-onion] Capacity planning help?

Hi Pete,

Do you have any details on what is the disk performance requirements for the Onion monitoring a 10Gbps link.

I work for a University and I'm spec'ing out our server requirements for 10G IDS. Based on the calc you provided earlier for Disk space measurement "Avg Link Utilization in Mbps" * 4.5 == "Storage/Day in GBs" . We see an avg of 6Gbps today. So that would mean 27TB per day. And for disk speed measurement, considering only the pcaps - at avg of 6Gbps would mean a sustained write speeds on 750MB/s.

I looked at a similar Dell R720 spec with the 7.2K RPM 3TB Near-Inline SAS 6Gbps drives. After speaking with the Dell Storage engineer about this specific drive , he mentioned that the drive can give a sustained transfer rate of 68-155MB/sec depending where on the platter you are writing to. If the drive is relatively empty the write performance should be closer to the 155MB/sec when it is writing to the outermost disk tracks. If we use the minimum figure of 68MB/sec then we'd need at least 12 drives so sustain 750MB/sec disregarding any write performance overhead of the RAID level we choose.

I would probably be better of considering the 10K or 15K RPM Sata drives. But it hard to get the high storage at that speeds.

I'm trying to see if we can offload the data to our SAN. And would you be able to help by providing some approx disk performance/IOPs requirement for the Onion with 10Gbps feed.


Thanks,
Benson

--
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?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

[Castle, Shane]

You can reduce the captured data with a packet filtering expression, if you are *sure* you will never be interested in any packets that satisfy the expression. For instance, I have narrowed down the servers and ports involved in disk backups on our network and do not capture that traffic. This BPF would be used only by netsniff-ng.

In a Uni environment, you might not want to capture all the HTTP traffic, for instance, but still alert on it with Snort/Snorby/Sguil/Bro. You'd set up your BPF so that it was not used by Snort or Bro but was used by netsniff-ng. This might reduce your packet captures significantly, at the expense of not being able to examine the data stream in detail for HTTP.

--
Shane Castle
Data Security Mgr, Boulder County IT

-----Original Message-----
From: securit...@googlegroups.com [mailto:securit...@googlegroups.com] On Behalf Of Benson Mathews
Sent: Thursday, February 14, 2013 07:53
To: securit...@googlegroups.com
Subject: Re: [security-onion] Capacity planning help?

Ok thats good to know and thanks for sharing the numbers you are seeing. I have a test server (smaller box) ready to monitor a 1G feed and should be able to validate the disk space requirements.

Your calc is logical and similar to whats mentioned on the Hardware requirements wiki page. And that would mean TBs!! worth of data for a day for a 10G. I was just looking in the forum to see if anyone had evaluated the Onion for 10G and their experiences and to see what sort of disk usage others had. Thats when how I came across this RoT.

Thanks for the feedback. But can anyone provide some disk IO requirements that the Onion would demand on the server?

Thanks,
Benson