Towards ELK on Security Onion: A Technology Preview

[Doug Burks]

http://blog.securityonion.net/2017/03/towards-elk-on-security-onion.html

Please let us know what you think.

Thanks in advance for any and all feedback!

--
Doug Burks

[Chris V]

This is fantastic news! music to my ears! Doug, this is epic my friend! I will be testing the script on a test vm here at work.

Thanks!

[Doug Burks]

Thanks, Chris! Please let us know how it goes!

> --
> Follow Security Onion on Twitter!
> https://twitter.com/securityonion
> ---
> 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.



--
Doug Burks

[James Taylor]

Agreed.. Glad to hear...perfect timing.

[Doug Burks]

Thanks James! Please let us know your thoughts as you test!


--
Doug Burks

[Wes]

Looking forward to testing as well! One thing I noticed -- the blog entry references:

'https://github.com/SMAPPER/elk-test' for Justin Henderson's Logstash configs.

Should it not be 'https://github.com/SMAPPER/Logstash-Configs' ?

Thanks,
Wes

[Doug Burks]

Nice catch, Wes! I've updated the blog post.


--
Doug Burks

[Jon Mark Allen]

Super excited about this.

I did notice a sequence error in the install script.

apt-get is used on line 146 to ensure git is installed, but 'git clone' was already executed on line 137.

JM

[wedgeshot]

Doug,

Thanks for all you do with this project, was hoping to see this headed our way after seeing the video from the SecOnion conference videos this past summer.

Is it possible that Martin's new work with fed, galaxy, pulsar are included with this preview or it that coming down the road?

I'll be testing for sure and will let you know.

[jesse...@gmail.com]

Doug,

This is an extremely good move for Security Onion. I read on one of your posts that this is in testing phase. Do you have any idea when this change to ELK will be usable within live environments? Thanks!

[Doug Burks]

Hi Jon Mark,

Nice catch! I've fixed this in my dev version:
https://github.com/dougburks/elk-test/commit/ed333a1310b1bfc7015ded6739011ba49e899257


--
Doug Burks

[Doug Burks]

Hi wedgeshot,

This preview does not include fed/galaxy/pulsar since they're not yet
ready for production. If and when they reach stable status, we can
certainly take a look at them.


--
Doug Burks

[Doug Burks]

On Thu, Mar 16, 2017 at 11:42 PM, <jesse...@gmail.com> wrote:
> Doug,
>
> This is an extremely good move for Security Onion. I read on one of your posts that this is in testing phase. Do you have any idea when this change to ELK will be usable within live environments? Thanks!

Hi Jesse,

This is going to be a big project and it's going to take some time to
make sure we get it right. We're not ready to commit to any time
frame at this point. The more feedback we can get from the community
now, the faster we can get there!


--
Doug Burks

[namobud...@gmail.com]

Rock on Doug! I'll try this in my lab in the next week!!!

Awesome.

[jesse...@gmail.com]

On Friday, March 17, 2017 at 7:29:50 AM UTC-4, Doug Burks wrote:

Doug,

Roger that. I plan on performing a series of tests on VMware ASAP.

[James Taylor]

Spent some time this morning initial setup seemed to work. Looks like good start.. Thanks. Will continue testing.

[Doug Burks]

On Fri, Mar 17, 2017 at 8:41 AM, <namobud...@gmail.com> wrote:
> Rock on Doug! I'll try this in my lab in the next week!!!
>
> Awesome.

Thanks, namobuddhaonion!


--
Doug Burks

[Doug Burks]

Thanks, Jesse!


--
Doug Burks

[Doug Burks]

On Fri, Mar 17, 2017 at 2:43 PM, James Taylor <jtay...@gmail.com> wrote:
> Spent some time this morning initial setup seemed to work. Looks like good start.. Thanks. Will continue testing.

Thanks, James!

--
Doug Burks

[wedgeshot]

Doug,

I took my home Optiplex 755(Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz) with 8 GIG of RAM that has been running SO for quite some time... system has been shut down for a few months as I've been distracted with other stuff.

I performed "sudo soup", reboot then ran sosetup followed by running the securityonion_elsa2elk.sh and things look to be just fine. I'll let it run for a while and patch on a regular basis.

I'll be spinning this up at work over the next few weeks once I find some real hardware to run it on :)

Nice clean scripting BTW .... thanks to all the other folks that worked on this as well.

[Doug Burks]

Thanks, wedgeshot!


--
Doug Burks

[Marcus Liberto]

Works flawlessly on a HPdl380G7 with 8GB of ram.

What do you think?
-I absolutely love it. Its everything I wanted and more.
What works well?
-Dashboard presentations, drilling down while hunting, pivoting between capme interface and squert.
What needs to be improved?
-Not so much what needs to be improved, but looking forward to future enhancements/capabilities in relation to the stable master/sensor setup. Would love to see how this works with ELK vs ELSA.

Thank you so much for this Doug! Let me know if there is any way I can help with testing or development.

-Marcus

[Chris V]

Kurrus? Saw your video :) We had a brief exchange about surricata and snort a few months back. I am as excited as you are with ELK :)

[Daniel K]

Looks great. :)

Are you looking into including any event correlation engine into Security Onion?

[Doug Burks]

Hi Marcus,

Thanks for your feedback! Replies inline.

On Mon, Mar 20, 2017 at 10:44 AM, Marcus Liberto
<marcus...@gmail.com> wrote:
> On Thursday, March 16, 2017 at 4:16:22 PM UTC-4, Doug Burks wrote:
>> http://blog.securityonion.net/2017/03/towards-elk-on-security-onion.html
>>
>> Please let us know what you think.
>>
>> Thanks in advance for any and all feedback!
>>
>> --
>> Doug Burks
>
> Works flawlessly on a HPdl380G7 with 8GB of ram.
>
> What do you think?
> -I absolutely love it. Its everything I wanted and more.
> What works well?
> -Dashboard presentations, drilling down while hunting, pivoting between capme interface and squert.
> What needs to be improved?
> -Not so much what needs to be improved, but looking forward to future enhancements/capabilities in relation to the stable master/sensor setup. Would love to see how this works with ELK vs ELSA.

Yep, we'll be working on distributed architecture over the next few
weeks to see what that's going to look like.

> Thank you so much for this Doug! Let me know if there is any way I can help with testing or development.

Stay tuned! There will be more rounds of testing and feedback. Thanks!



--
Doug Burks

[Doug Burks]

Hi Daniel,

Replies inline.

On Tue, Mar 21, 2017 at 2:42 AM, Daniel K <ker...@gmail.com> wrote:
> Looks great. :)

Thanks for your feedback!

> Are you looking into including any event correlation engine into Security Onion?

Right now, we're just focused on getting to Elastic as quickly as
possible. In the meantime, we already have OSSEC which does some
correlation.


--
Doug Burks

[namobud...@gmail.com]

I just loaded up Security Onion ELK edition in a Proxmox VM. Damn it's nice Doug! All the Elsa searches are recreated and it seems like we'll be able to drill down much quicker.

GREAT WORK bro!

It's exciting...

[Doug Burks]

[Harvii Dent]

This is great news.

Is there a plan to support using an independent (existing) ELK deployment outside of Security Onion?

[namobud...@gmail.com]

After using the test a bit more I think ELK correlation and pivoting will take hunting to a whole new level.

I noticed when I tried to run NetworkMiner that it looked like it was the windows version and would not run. I am I missing something?

It's amazing work Doug. :-).

[Doug Burks]

On Wed, Mar 22, 2017 at 9:30 AM, Harvii Dent <harvi...@gmail.com> wrote:
> This is great news.
>
> Is there a plan to support using an independent (existing) ELK deployment outside of Security Onion?

Hi Harvii,

We don't officially support independent Elastic deployments, but if
it's working for you today, then it should continue to work.

--
Doug Burks

[Doug Burks]

Hi namobuddhaonion,

Replies inline.

On Wed, Mar 22, 2017 at 10:19 AM, <namobud...@gmail.com> wrote:
> After using the test a bit more I think ELK correlation and pivoting will take hunting to a whole new level.

Thanks for the feedback!

> I noticed when I tried to run NetworkMiner that it looked like it was the windows version and would not run. I am I missing something?

NetworkMiner hasn't changed in this Technology Preview. We've always
run NetworkMiner.exe via Mono. If you have further questions about
NetworkMiner, please start a new thread to discuss.

> It's amazing work Doug. :-).

Thanks!


--
Doug Burks

[Marcelo Ramos]

Hi Doug,

This sounds rather exciting. Can't help but wonder what is the main motivation behind this? I have noticed there is little activity on upstream ELSA...

Will have a play as soon as I can and feedback here.

--Marcelo

[Doug Burks]

Hi Marcelo,

Replies inline.

On Thu, Mar 23, 2017 at 12:50 PM, Marcelo Ramos <marcel...@gmail.com> wrote:
> Hi Doug,
>
> This sounds rather exciting. Can't help but wonder what is the main motivation behind this? I have noticed there is little activity on upstream ELSA...

We've had lots of folks ask for Elastic Stack on Security Onion and
we're simply responding to demand.

> Will have a play as soon as I can and feedback here.

Sounds good, thanks!


--
Doug Burks

[Jon Gerdes]

> Please let us know what you think.

I ran the script on a customized single SO install VM. I neutered the eval sections of the script ran it and drank a coffee and nearly spat out the last mouthful over the screen! It looks simply gorgeous.

We use ELK quite extensively already and this fits right in. We have a classic ES cluster with a LK frontend gather n index plus Redis buffer setup for logs.

I need to spend some time getting to grips with it and developing potential workflows but first impressions are really, really good.

I note there are geo fields populated in the data and K has some rather spiffing mapping widgets.

Great stuff.

[Doug Burks]

Hi Jon,

Thanks for the feedback!


--
Doug Burks

[brandon larson]

I have just installed the new pre-beta release of ELK on Security Onion. First off, thank you to Doug and friends for all of the work you continue to do! I am not that familiar with ELK so I have just been clicking around to see what I can find. I have noticed that on the Dashboard (DNS for example) it seems to be limited by the "top" responses. Is there a way, similar to ELSA, where it shows the bottom? Also, is there a reason we can't have ELK and ELSA? Is it a resource issue or other dependency conflict? I am having a hard time remembering all of the useful ELSA queries to see how I can do the same on ELK.
Thanks again!!

[brandon larson]

I see that you can edit and increase the limit in order to see the bottom.

[Justin Henderson]

On Sunday, March 26, 2017 at 6:54:34 AM UTC-5, brandon larson wrote:
> I see that you can edit and increase the limit in order to see the bottom.

Brandon, thank you for your comments. You are spot on about having both ELK and ELSA being a resource issue. On top of that maintaining both would be problematic.

ELK is being looked at as a transition from ELSA as it is becoming a more common platform within the community. It also introduces some interesting components for log enrichment and dealing with alert data and Bro data. Also, switching to it would allow Security Onion to transition from a network security monitoring platform to a network security monitoring platform with full logging and analysis capabilities similar to commercial SIEMs.

Should this change from ELSA to ELK happen I will try and publish some blogs and documentation on some of the ELK components to speed up their transition. Expect that if it happens it will take some time. This is a fairly significant change.

[brandon larson]

Justin,

Thanks for the reply, and more importantly thank you for the work you have done with this integration of ELK. I am a novice when it comes to ELK so yes any documentation would be useful. For now, I am just learning on the fly. I'm working on standing up a separate ELK server for host logs so that it will force me to learn the ins and outs. Thanks again.

[corq]

On Thursday, March 16, 2017 at 4:16:22 PM UTC-4, Doug Burks wrote:
> http://blog.securityonion.net/2017/03/towards-elk-on-security-onion.html
>

> Please let us know what you think.
>

> Thanks in advance for any and all feedback!
>
> --
> Doug Burks

Just loaded it up, and was very excited. I've been playing with T-POT (honeypot) that uses Kibana backend and it's pretty exciting to hear about this possibility for Security-Onion. Thanks for all your work!

[corq]

[Brian Kellogg]

Initial test worked flawlessly. Great work and scripting!

Love the dashboards, will help greatly with aggregate data hunts and general daily posturing.

Only thing I miss so far with my limited testing is having multiple sub tabs open in one browser tab as ELSA does.

[Doug Burks]

Hi Brian,

Replies inline.

On Tue, Mar 28, 2017 at 9:58 AM, Brian Kellogg <thef...@gmail.com> wrote:
> Initial test worked flawlessly. Great work and scripting!
>
> Love the dashboards, will help greatly with aggregate data hunts and general daily posturing.

Glad to hear it, thanks!

> Only thing I miss so far with my limited testing is having multiple sub tabs open in one browser tab as ELSA does.

I had similar thoughts when I first started experimenting with Kibana
and I've tried to address this somewhat with the Indicator dashboard.
I'm hoping to do a blog post and/or video at some point to talk more
about workflow, but let me provide a simple example here.

Common workflow in ELSA:
- search for "1.2.3.4 groupby:program"
- drill into Snort alerts and group by message
- go back to the groupby:program tab and then drill into bro_dns and
group by hostname
- go back to the groupby:program tab and then drill into bro_http and
group by site
- go back to the groupby:program tab and then drill into bro_conn and
group by source IP, destination IP, and destination port
- go back to the groupby:program tab and then drill into bro_notice
and group by notice_msg
- go back to the groupby:program tab and then drill into bro_ssl and
group by hostname

Similar workflow in Kibana:
- click on hyperlinked IP address of interest
- this takes you to the Indicator dashboard, searches for that IP
address, and automatically displays all of the above information (DNS
queries, source IP addresses, destination IP addresses, destination
ports, Bro notices, NIDS alerts, HTTP sites, SSL hostnames)
- drill into any interesting logs via the search panel at the bottom

So, depending on your goals and your workflow, a good Kibana dashboard
can automatically highlight the most valuable data and make you more
efficient.

--
Doug Burks

[Brian Kellogg]

Thanks Doug, agree with everything. Getting old and stuck in my ways.

Is any help needed as far as log import parsers. I haven't worked with ELK much at all besides testing it a couple times quickly but would be willing to help bring parity between what ELSA can parse and what may be missing with SO ELK. Pretty busy right now, but can try to carve out time if the help would be beneficial. Thanks

[Doug Burks]

On Wed, Mar 29, 2017 at 11:29 AM, Brian Kellogg <thef...@gmail.com> wrote:
> Thanks Doug, agree with everything. Getting old and stuck in my ways.
>
> Is any help needed as far as log import parsers. I haven't worked with ELK much at all besides testing it a couple times quickly but would be willing to help bring parity between what ELSA can parse and what may be missing with SO ELK. Pretty busy right now, but can try to carve out time if the help would be beneficial. Thanks

Yes, the more coverage we have for different log types, the better! Thanks!


--
Doug Burks

[jesse...@gmail.com]

Hello all,

Just wanted to share my experience with testing the ELK installation script, and its functionality afterwards. Very good stuff. Here's a short video depicting the results:

https://youtu.be/cUP_ZRn5rro

[Chris V]

Good stuff Jesse!

[Doug Burks]

Hi Billy,

Since this is just a technology preview and not to be used for
production purposes, you shouldn't really need to remove the sample
logs. You can simply change the Kibana time window to look at time
after those logs were written.

If you really do need to remove the sample logs, you could delete the
Elasticsearch index for that day.

Alternativately, you could always build a new Security Onion test VM
but, before running the Elastic script, remove the tcpreplay lines
that create the sample logs:
https://github.com/Security-Onion-Solutions/elk-test/blob/master/securityonion_elsa2elk.sh#L272-L283

On Tue, Apr 4, 2017 at 5:29 AM, Billy Bulaclac
<billy.b...@producersbank.com.ph> wrote:
> Hi All,
>
> How can I remove the sample logs generated during the installation?
>
> --
> Follow Security Onion on Twitter!
> https://twitter.com/securityonion
> ---
> 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.



--
Doug Burks

[BelleCrosse]

Hello Doug and the SO Team,

I just wanted to say thank you for all the hard work, testing and integration performed to bring this new platform to life.

I apologize for having not replied sooner as I have been testing the new platform in a cloud environment that was previously deployed as a "master server". I reran "sosetup" to switch to a "stand-alone" deployment scheme.

As a result of running the ELK script upgrade, the system as a whole ran perfectly fine using the SO image 14.04.5. Also, the Kibana integration is a great addition to an already great security tool. The dashboards are also very useful by providing aggregated datasets for the analysts in one place.

Further, I have also deployed the SO-ELK on a physical server in my lab and it's been running with no issues since deployment.

Thank you Doug and everyone in the SO team. I can't wait for the final production version of the SO-ELK because it will just be awesome mates.

Good Day mate!

BelleCrosse

[Doug Burks]

Thanks, BelleCrosse!

--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
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.

--

Doug Burks

[markd...@gmail.com]

I installed it to virtualbox and it seems to have installed fine. but watching it go past on the install I wrote down a few areas it showed an error, excuse the imprecise explanation but I didnt keep an exact copy of the messages...

lmenezes elasticsearch failed to download from all possible locations

warning couldnt locate pandoc

warning no previous inclusion file match *.pyo, *.pyc (and a bunch of other .py?)

but like I said it seems to be running ok all the same.

[Doug Burks]

Hi markdkberry,

Thanks for the feedback!

Those kinds of errors should go away altogether once we move to real
packages. At this point, we're mainly interested in making sure that
it's running and provides you the kinds of dashboards, visualizations,
and pivots that you need to do analysis and incident response.


--
Doug Burks

[Doug Burks]

On Tue, Apr 11, 2017 at 11:32 AM, Konrad Uminski
<konrad...@gmail.com> wrote:
> Is anyone getting a logstash error?
>
> at the point of: Waiting for Logstash to initialize
> "ERROR: logstash not available for more than 240 seconds."

Hi Konrad,

What are the specs of your VM?

How many CPU cores and at what speed?

How much RAM?


--
Doug Burks

[wedgeshot]

Doug,

I'm running ELK preview now on a Dell 720xd , 2 procs, 128GIG of Ram and 11 3TB drives in a RAID6 config.

I'm averaging over 9 million records in a 24 hours period based on the Overview dashboard number.

I can't seem to get through an entire day without Kibana timing out on a refresh or even clicking on say Bro notices. I'm not using Kibana for a lot of the day but checking in on it once in a while. Today I stopped Kibana, restarted elasticsearch and then started Kibana and that seem to bring Kibana back to life ;)

I'll try and dig in soon to see if logs reveal any problems. I know a brief stint with ELK prior memory settings were key for performance :) so I'll be looking at that for sure.

Thanks again for all your efforts.

[Konrad Uminski]

Doug Burks

I manage to figure out, at first i was not paying attention to the install, when i looked I saw "restart apache2" after I did that everything worked perfectly.

[wedgeshot]

FOLLOWUP: I un-commented and set ES_HEAP_SIZE=28g in /etc/init.d/elasticsearch and boy what a difference and performance. Kibana was still responding at the end of the day as well. You can only give a maximum of 31 GIG to Elasticsearch according to the comments section and I also remember that from my prior brief experience.

So in summary, it's java under the hood so give as much memory as you can afford to ELK ;)

[Marcus Liberto]

I've been experiencing the same thing with a similar setup but haven't had a chance to play under the hood yet.  I'll give this a whirl.  Thanks for sharing WedgeShot!

--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---

You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/ReAPgPn746M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.

[wedgeshot]

Sure thing.... So I've got two fulls days of great performance without restarting on the 720xd at work.

On my home server with only 8 GIG of RAM I'm running now with ES_HEAP_SIZE=4g and things are working today but slow response on page loads. I'd say maybe a SO w/ ELK systems need to have a minimum of 16GIG of RAM with 12 of that going to ELK(thinking out loud) for a positive experience.

On Thursday, April 13, 2017 at 8:10:07 AM UTC-4, Marcus Liberto wrote:
> I've been experiencing the same thing with a similar setup but haven't had a chance to play under the hood yet.  I'll give this a whirl.  Thanks for sharing WedgeShot!
>
>
> On Wed, Apr 12, 2017 at 8:07 PM, wedgeshot <wedg...@gmail.com> wrote:
> On Tuesday, April 11, 2017 at 9:50:01 PM UTC-4, wedgeshot wrote:
>
> > Doug,
>
> >
>
> >   I'm running ELK preview now on a Dell 720xd , 2 procs, 128GIG of Ram and 11 3TB drives in a RAID6 config.
>
> >
>
> > I'm averaging over 9 million records in a 24 hours period based on the Overview dashboard number.
>
> >
>
> > I can't seem to get through an entire day without Kibana timing out on a refresh or even clicking on say Bro notices. I'm not using Kibana for a lot of the day but checking in on it once in a while. Today I stopped Kibana, restarted elasticsearch and then started Kibana and that seem to bring Kibana back to life ;)
>
> >
>
> > I'll try and dig in soon to see if logs reveal any problems.  I know a brief stint with ELK prior memory settings were key for performance :) so I'll be looking at that for sure.
>
> >
>
> > Thanks again for all your efforts.
>
>
>
> FOLLOWUP:  I un-commented and set ES_HEAP_SIZE=28g in /etc/init.d/elasticsearch and boy what a difference and performance. Kibana was still responding at the end of the day as well. You can only give a maximum of 31 GIG to Elasticsearch according to the comments section and I also remember that from my prior brief experience.
>
>
>
> So in summary, it's java under the hood so give as much memory as you can afford to ELK ;)
>
>
>
>
>
> --
>
> Follow Security Onion on Twitter!
>
> https://twitter.com/securityonion
>
> ---
>
> You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
>
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/ReAPgPn746M/unsubscribe.
>

> To unsubscribe from this group and all its topics, send an email to security-onio...@googlegroups.com.
>
> To post to this group, send email to securit...@googlegroups.com.

[Justin Henderson]

Thanks all to the feedback on performance and stability. For this preview we intentionally have not put these settings in. However, we will try to anticipate and design around this assuming we move forward with the new additions.

Also note, if you are trying to tune Elasticsearch you can also get a boost by enabling the bootstrap.mlockall: true setting in /etc/elasticsearch/elasticsearch.yml and setting MAX_LOCKED_MEMORY=unlimited in /etc/default/elasticsearch. 

Also, you may want to enable the MAX_OPEN_FILES in /etc/default/elasticsearch and set it to something like 65536 or higher. If you do this you will also need to edit /etc/security/limits.conf and adjust accordingly such as adding the below line to the bottom of the config file.

elasticsearch - nofile 65536

Note: Since this is a tech preview we are focusing primarily on functionality but know that performance will be strongly considering and designed around if this architecture change takes place. All, thank you for so much feedback. This is extremely helpful.

Sincerely,

Justin Henderson

(312) 857-5755
Systems and Security Architect
GSE # 108, Cyber Guardian Red / Blue

http://www.linkedin.com/in/justinhenderson2014/

To unsubscribe from this group and all its topics, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.

[Doug Burks]

On Thu, Apr 13, 2017 at 11:47 PM, Justin Henderson
<jhend...@tekrefresh.com> wrote:
> Thanks all to the feedback on performance and stability. For this preview we
> intentionally have not put these settings in. However, we will try to
> anticipate and design around this assuming we move forward with the new
> additions.
>
> Also note, if you are trying to tune Elasticsearch you can also get a boost
> by enabling the bootstrap.mlockall: true setting in
> /etc/elasticsearch/elasticsearch.yml

Hi Justin,

To clarify, I think this setting is now called bootstrap.memory_lock,
right? From /etc/elasticsearch/elasticsearch.yml:

# ----------------------------------- Memory -----------------------------------
#
# Lock the memory on startup:
#
# bootstrap.memory_lock: true





--
Doug Burks

[Justin Henderson]

I think you may be right. The setting is already in the file. It just needs uncommented.

[Marcus Liberto]

When clicking on the pcaps that pivot me over to capme...every pcap says "No Data Sent" and when I download sample pcaps and open in wireshark there is no data.  Is this a future feature?

-Marcus

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.

[Justin Henderson]

Marcus, did you start with a fresh install when setting up this technology preview? This feature is one of the technology preview components and should be working. 

Also, it is possible that if updates were installed after running the technology preview bash script that it may have broke something.

This is one of the core features I am hoping to see moving forward.

Sincerely,

Justin Henderson

(312) 857-5755
Systems and Security Architect
GSE # 108, Cyber Guardian Red / Blue

http://www.linkedin.com/in/justinhenderson2014/

[Marcus Liberto]

Yep fresh install of the 14.04.5.2 iso, ran soup updates, ran the .sh file, edited ES_HEAP_SIZE as mentioned earlier. I'm throwing about 100Mbit/s, negligible packet loss, CPU usage is moderately low, memory is high but not hitting swap significantly (HP DL390G7 12 cores, 128GB ram). I'll attempt a reinstall without doing soup updates next week and report back to the thread. Thanks for the quick reply Justin!

> To unsubscribe from this group and all its topics, 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.
>
>
>
>
>
>
> --
>
> Follow Security Onion on Twitter!
>
> https://twitter.com/securityonion
>
> ---
>
> You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
>
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/ReAPgPn746M/unsubscribe.
>

> To unsubscribe from this group and all its topics, 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.
>
>
>
>
>
>
>
> --
>
> Follow Security Onion on Twitter!
>
> https://twitter.com/securityonion
>
> ---
>
> You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
>
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/ReAPgPn746M/unsubscribe.
>

> To unsubscribe from this group and all its topics, send an email to security-onio...@googlegroups.com.

[Justin Henderson]

You are welcome.

If for some reason it doesn't work after a reinstall let me know. I'll
spin off my own and then we can try to pinpoint what's going on.

[Marcus Liberto]

No luck. Fresh install without soup updates. Attached screenshots for reference.

[Marcus Liberto]

Disregard...looks like packet loss outside of the NIC. Doesn't seem to be a problem with a separate low volume environment I just set up (~10MBit/s average, 8GB ram, 12 cores). Sorry to throw the thread off track.

=========================================================================
Packets received during last monitoring interval (600 seconds)
=========================================================================

eth4: 62769737

=========================================================================
Packet Loss Stats
=========================================================================

NIC:

eth4:

RX packets:959934397 dropped:0 TX packets:1 dropped:0

-------------------------------------------------------------------------

pf_ring:

Appl. Name : <unknown>
Tot Packets : 953419620
Tot Pkt Lost : 194339404


Appl. Name : snort-cluster-55-socket-0
Tot Packets : 948385790
Tot Pkt Lost : 671103640

-------------------------------------------------------------------------

IDS Engine (snort) packet drops:

/nsm/sensor_data/SO-server-eth4/snort-1.stats last reported pkt_drop_percent as 68.985
-------------------------------------------------------------------------

Bro:

Average packet loss as percent across all Bro workers: 25.604242

bro: 1493054874.259560 recvd=759053106 dropped=194349793 link=759053106

Capture Loss:

bro 100.0

If you are seeing capture loss without dropped packets, this
may indicate that an upstream device is dropping packets (tap or SPAN port).

-------------------------------------------------------------------------

Netsniff-NG:
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +234012 Lost: -1503
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +342673 Lost: -32804
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +285747 Lost: -1192
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +251171 Lost: -1
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +416690 Lost: -247132
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +358628 Lost: -3
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +348527 Lost: -2104
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +290883 Lost: -4
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +481973 Lost: -5200
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +293023 Lost: -5097
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +424731 Lost: -11533
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +365627 Lost: -12
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +287252 Lost: -5916
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +276616 Lost: -13
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +285411 Lost: -2649
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +344345 Lost: -8592
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +327307 Lost: -3
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +314197 Lost: -4473
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +398740 Lost: -12206
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +339085 Lost: -12
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +330692 Lost: -16609
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +270147 Lost: -3
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +275869 Lost: -29673
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +242993 Lost: -7
File: /var/log/nsm/SO-server-eth4/netsniff-ng.log Processed: +312980 Lost: -16361

=========================================================================
PF_RING
=========================================================================
PF_RING Version : 6.4.1 (unknown)
Total rings : 2

Standard (non ZC) Options
Ring slots : 4096
Slot version : 16
Capture TX : Yes [RX+TX]
IP Defragment : No
Socket Mode : Standard
Total plugins : 0
Cluster Fragment Queue : 2808
Cluster Fragment Discard : 0

=========================================================================
Log Archive
=========================================================================
/nsm/sensor_data/SO-server-eth0/dailylogs/ - 0 days
4.0K .

/nsm/sensor_data/SO-server-eth1/dailylogs/ - 0 days
4.0K .

/nsm/sensor_data/SO-server-eth2/dailylogs/ - 0 days
4.0K .

/nsm/sensor_data/SO-server-eth3/dailylogs/ - 0 days
4.0K .

/nsm/sensor_data/SO-server-eth4/dailylogs/ - 1 days
508G .
508G ./2017-04-24

/nsm/bro/logs/ - 1 days
1.1G .
1.1G ./2017-04-24
60K ./stats

[Justin Henderson]

I'm glad you found the issue (although sorry you have packet loss). No worries on the side track. 

The community grows as the community supports one another.

> > > security-onion+unsubscribe@googlegroups.com.
> > > To post to this group, send email to security-onion@googlegroups.com.

> > > Visit this group at https://groups.google.com/group/security-onion.
> > > For more options, visit https://groups.google.com/d/optout.
> > >
> >
> >
> > --
> >
> >
> > Sincerely,
> >
> > Justin Henderson
> > (312) 857-5755
> > Systems and Security Architect
> > GSE # 108, Cyber Guardian Red / Blue
> > http://www.linkedin.com/in/justinhenderson2014/

--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/ReAPgPn746M/unsubscribe.

To unsubscribe from this group and all its topics, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.

[Chris V]

On Thursday, March 16, 2017 at 1:16:22 PM UTC-7, Doug Burks wrote:
> http://blog.securityonion.net/2017/03/towards-elk-on-security-onion.html
>
> Please let us know what you think.
>
> Thanks in advance for any and all feedback!
>
> --
> Doug Burks

Question, so regarding current SO enterprise production deployments what is the goal to update them to ELK once the official release comes out? I am assuming the only changes made by such a script would be to the master server only? Any changes needed to the sensors?

Sorry I know this is thinking a little forward but just curious on what the idea would be. Not sure If I should build out my deployment now or wait for the official SO/ELK release. I have my budget now :)

[Doug Burks]

Hi Chris,

Replies inline.

On Tue, May 16, 2017 at 6:15 PM, 'Chris V' via security-onion
<securit...@googlegroups.com> wrote:
> On Thursday, March 16, 2017 at 1:16:22 PM UTC-7, Doug Burks wrote:
>> http://blog.securityonion.net/2017/03/towards-elk-on-security-onion.html
>>
>> Please let us know what you think.
>>
>> Thanks in advance for any and all feedback!
>>
>> --
>> Doug Burks
>
> Question, so regarding current SO enterprise production deployments what is the goal to update them to ELK once the official release comes out? I am assuming the only changes made by such a script would be to the master server only? Any changes needed to the sensors?

We're still working on what distributed deployments will look like,
but it will most likely require changes to not only the master server
but also the sensors as well.

> Sorry I know this is thinking a little forward but just curious on what the idea would be. Not sure If I should build out my deployment now or wait for the official SO/ELK release. I have my budget now :)

We're not ready to commit to any release dates yet, so if you need
monitoring now, you should probably proceed with your deployment using
the current version of Security Onion.

--
Doug Burks

[Eric Holtzclaw]

On Thursday, March 16, 2017 at 1:16:22 PM UTC-7, Doug Burks wrote:
> http://blog.securityonion.net/2017/03/towards-elk-on-security-onion.html
>
> Please let us know what you think.
>
> Thanks in advance for any and all feedback!
>
> --
> Doug Burks

So far I have ran it in the Demo mode and it's very impressive.
Can't wait till the Master / Slave is working.

Also, I have mine own ES Cluster and Kibana that would be great to send the master + slave JSON information too.

Keep us posted

Best,
Eric

[Doug Burks]

Hi Eric,

Replies inline.

On Fri, May 26, 2017 at 1:32 AM, Eric Holtzclaw
<eric.ho...@gmail.com> wrote:
> So far I have ran it in the Demo mode and it's very impressive.

Thanks for the feedback!

> Can't wait till the Master / Slave is working.
>
> Also, I have mine own ES Cluster and Kibana that would be great to send the master + slave JSON information too.

Perhaps you could modify /etc/syslog-ng/syslog-ng.conf and add a new
destination to send to your ES cluster.

> Keep us posted

Stay tuned!

--
Doug Burks

[Doug Burks]

Technology Preview 3 (TP3) is now available!

Blog post:
http://blog.securityonion.net/2017/07/towards-elastic-on-security-onion.html

Discussion:
https://groups.google.com/d/topic/security-onion/Sr8wrJSQxo0/discussion

--
Doug Burks