Suricata and external ELSA

[James Richards]

I am in the process of replacing a suricata node in an existing environment, and did a default SO install with nothing running on the box except for suricata.

I think I added the correct destination for the external ELSA node correctly, but logs are not appearing from suricata, though other logs are arriving from the box.

Is there a source statement needed for suricata in the syslog-ng.conf?

Many thanks,

Jim

[Doug Burks]

Hi Jim,

Have you seen the following?
https://code.google.com/p/security-onion/wiki/ThirdPartyIntegration#How_do_I_send_IDS_alerts_to_an_external_system?

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



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

[James Richards]

Doug,

Thanks much, I did, but I am trying make sure I am understanding the flow of messages.

Would I be looking at adding a line such as:

source s_suricata { file("$PATH_TO_SURICATA_ALERTS" program_override("sguil_alert")); };

to the syslog-ng.conf and ensure that the appropriate dest is listed as well?

Jim

[James Richards]

Oops, I meant to edit the reference to SQUIL in the line.

[James Richards]

Interestingly,

I turned on BRO, and am getting BRO logs in my exteral ELSA system, just not suricata, thoughts? and thanks! I have tried to read through eveything possible, but so far, to no avail.

On Wednesday, October 1, 2014 12:00:55 PM UTC-5, Doug Burks wrote:

[Doug Burks]

Per the Wiki page, you have (at least) 2 options:

- Edit ALL /etc/nsm/HOSTNAME-INTERFACE/barnyard2*.conf files on ALL
sensors with a new "output" to send IDS alerts to your external
systems and then restart all barnyard2 instances:
sudo nsm_sensor_ps-restart --only-barnyard2

OR

- On your master server (running sguild), configure
/etc/syslog-ng/syslog-ng.conf with a new "source" to monitor
/var/log/nsm/securityonion/sguild.log for "Alert Received" lines and a
new "destination" to send to your external system, and then restart
syslog-ng.

Which of these options are you trying to do?

[James Richards]

Hi Doug,

Thanks much. I am trying to use the first option, in my barnyard2.conf I have added the following out line:

output log_syslog_full: sensor_name utlmad0d0365-eth4, server x.x.x.x, log_priority log_alert, operation_mode default

(where x.x.x.x is the IP address of my remote ELSA box).

I am guessing I am still having some syntax issues, and am continuing to look.

[Doug Burks]

After modifying barnyard2.conf, did you restart barnyard2?

Are there any relevant clues in the barnyard2 log file?

[Jim Richards]

Sorry for the delay,

I decided to make sure I had a clean slate, so I popped in the latest SO cd in the machine, blew away the file systems and started from scratch. I installed the standalone, but the only thing enabled is suricata, all else are not running. I set it up to use ETPRO rules, set up the ETPRO a license number.

The only change I made was to syslog-ng.conf where I added the destination for our central ELSA box.

I can see other information coming from this host in our ELSA a server, so it looks like that part is correct and functioning. I can see the snort.unified files piling up under /nam/sensor_data/

But no alerts are getting to ELSA a.

Also, I accepted all of the defaults in the setup.

Any ideas would be greatly appreciated!

Jim

> 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/DA_V6Uq6rNY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to security-onio...@googlegroups.com.

[Doug Burks]

It sounds like you didn't follow the instructions here:
https://code.google.com/p/security-onion/wiki/ThirdPartyIntegration#How_do_I_send_IDS_alerts_to_an_external_system?

Which of these options are you trying to do?

EITHER

- Edit ALL /etc/nsm/HOSTNAME-INTERFACE/barnyard2*.conf files on ALL
sensors with a new "output" to send IDS alerts to your external
systems and then restart all barnyard2 instances:
sudo nsm_sensor_ps-restart --only-barnyard2

OR

- On your master server (running sguild), configure
/etc/syslog-ng/syslog-ng.conf with a new "source" to monitor
/var/log/nsm/securityonion/sguild.log for "Alert Received" lines and a
new "destination" to send to your external system, and then restart

syslog-ng. To do this modify /etc/syslog-ng/syslog-ng.conf and add
the following lines:

# This line specifies where the sguild.log file is located, and
informs syslog-ng to tail the file, the program_override inserts the
string sguil_alert into the string
source s_sguil { file("/var/log/nsm/securityonion/sguild.log"
program_override("sguil_alert")); };

# This line filters on the string “Alert Received”
filter f_sguil { match("Alert Received"); };

# This line tells syslog-ng to send the data read to the IP address of
10.80.4.37, via UDP to port 514
destination d_sguil_udp { udp("10.80.4.37" port(514)); };

# This log section tells syslog-ng how to structure the previous
‘source / filter / destination’ and is what actually puts them into
play
log {
source(s_sguil);
filter(f_sguil);
destination(d_sguil_udp);
};