Sguil- Can not Connect to LocalHost on Port 7734

[Barbara]

Hi everyone,

I'm using a Security Onion 14.05 virtual machine on an ESXi 5.1 server. The VM uses Snort and ELSA.

Actually, I have a few copies of the same VM (I'm using the same OVA, which I created from an Hardware 8 VM on my laptop with VMware Workstation 10), each is on a different DL Gen 8 server and has about 1.8 TB of space and about 20 GB of RAM.
The servers are located on separate almost identical networks (one server for each network) and each monitors all the network's traffic with port mirror.
My problem was that from a time to time, the virtual machines stop alerting on new events in their networks and when I tried to connect to Sguil, I got the following error: "Cannot connect to localhost on port 7734".
After searching about this problem on different forums online, I have learned that this error means that there are too many uncategorized events and in order to fix it- I need to categorize the events and restart the nsm service.
My new problem is that on each network, Security Onion can deal with a different number on uncategorized events. In one network it continues to function regularly with 7000 uncategorized events (I got there when there were 15,000 uncategorized events and reduced the number of these events to find the system's limit which is about 7000 uncategorized events), on another two it can't deal with 14 uncategorized events and on my laptop, where the virtual machine has only 4 GB of RAM and 90 GB of disk space- it continues to function with 200,000 uncategorized events.

My question is- what can be the cause of these differences? Can there be another reason for this error? I have read online that a brutal shutdown can cause this error, but when I tried to cause it by brutally shutdown the VM on my laptop (turning the laptop off brutally, terminating the VMware Workstation service, etc...) it still worked fine.

Thanks in advance for your help,

Barbara

[Wes Lambert]

Hi Barbara,

I can't tell you  exactly why you experience different results with each install, however, one thing that can affect operation is MySQL performance (impacted by available RAM/load on the box).  you could try running mysqlcheck on the databases to ensure consistency and/or run sguil-db-purge on each box to see if it works better for you.

Thanks,

Wes

--
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.

--

https://twitter.com/therealwlambert

https://securityonion.net/

[Barbara]

Hi Wes,

Thanks for trying to help me!
The problem is that it is the same virtual machine (each server has a different copy of the original machine) on each of the servers and all the servers are from the same model, with the same size of disk space and the same amount of RAM.
I can't access to any of the virtual machines right now, except for the one on my laptop, which functions the best despite the fact that it has only 4 GB of RAM and 90 GB of disk space.
In general, I used db purge on some cases to fix the problem, in others I just changed the status of the events to 1.
I want to find the source of the problem, to avoid purging the database too often.
Can you think of something that can cause the same VM with the same hardware resources to perform differently on each server?

[Wes Lambert]

Hi Barbara,

Are you hosting other VMs on the same physical servers -- so that each physical server's resources could be affected differently, allowing each of the Security Onion's assigned resources to be affected differently?

Thanks,

Wes

--
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.

[Barbara]

Hi Wes,
In all cases except for one- my Security Onion VM is all alone in the server. The one that shares a server with another VM is actually the VM that functions the best.

[Wes Lambert]

Hi Barbara,

Have you tried checking the CPU/RAM utilization on each of the problem boxes?

Are each of these boxes monitoring the same throughput?

Thanks,

Wes

On Thu, Jun 28, 2018 at 12:14 AM Barbara <barbar...@gmail.com> wrote:

Hi Wes,
In all cases except for one- my Security Onion VM is all alone in the server. The one that shares a server with another VM is actually the VM that functions the best.

--
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.

[Barbara]

Hi Wes,

The servers are all in very similar networks, some are busier than others, but not by a great deal. The busiest network is the one its Security Onion machine functions the best. One of the VM's that functioned poorly did have less RAM than the others, so I gave it some more, but it didn't help much.

[Wes Lambert]

I can't really say why you are experiencing different results.  If you attach sostat-redacted output for each of the machines, I can try to take a look and see if anything sticks out.

Thanks,

Wes

On Fri, Jun 29, 2018 at 5:42 AM Barbara <barbar...@gmail.com> wrote:

Hi Wes,

The servers are all in very similar networks, some are busier than others, but not by a great deal. The busiest network is the one its Security Onion machine functions the best. One of the VM's that functioned poorly did have less RAM than the others, so I gave it some more, but it didn't help much.

--
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.

[Barbara]

Thanks Wes. I'll try to do that, but it will probably take some time to publish the outputs here.
In any way, is there something that I should look for in the outputs?