SYSLOG Suricata alerts to external SIEM

[cr...@advancedcybersecurity.co.uk]

Hi,
I am trying to send IDS alerts to an external SIEM using syslog. I navigated to /etc/nsm/<Sensor name/ and added the following line to the barnyard2.conf files (and commented out the default syslog line):

"output log_syslog_full: sensor_name $fakesensorname, server $1.1.1.1, protocol udp, port 514, operation_mode complete"

but I am not receiving anything in my SIEM, please can anyone who has got this operational please advise? or suggest troubleshooting steps (SIEM is confirmed functional when receiving on UDP:514).

Any help would be appreciated.

[Doug Burks]

Hi Craig,

Have you seen the following page on our Wiki?
https://code.google.com/p/security-onion/wiki/ThirdPartyIntegration

After updating barnyard2.conf, did you restart barnyard?

Have you looked at the barnyard2 log file for any relevant clues?

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

[CB]

Hi Doug,
yes i did see that link but it doesnt detail the syntax for the barnyard method - the logs do not mention anything in particular.

/CB

[Doug Burks]

After updating barnyard2.conf, did you restart barnyard?

[CB]

yes using "sudo nsm_sensor_ps-restart --only-barnyard2", i am getting the following error but barnyard does appear to start:

* stopping: barnyard2 (spooler, unified2 format) (not running) [ WARN ]
- stale PID file found, deleting!
* starting: barnyard2 (spooler, unified2 format)

[Doug Burks]

If it shows WARN when you try to restart it, then it most likely
failed the last time you tried to start it.

Please send your barnyard2 log file:
/var/log/nsm/HOSTNAME-INTERFACE/barnyard2.log

[CB]

OK so it seems something is wrong, when defining the server IP does this need to be prefixed by a "$" and does the sensor name also have to have a "$" prefixign the name? are there problems with host names containing hypens "-"?

My barnyard2.conf file is:

barnyard2.conf: auto-generated by NSMnow Administration on Sun Oct 5 20:25:32 UTC 2014
config logdir: /nsm/sensor_data/Sensorname
config classification_file: /etc/nsm/Sensorname/classification.config
config reference_file: /etc/nsm/Sensorname/reference.config
config sid_file: /etc/nsm/Sensorname/sid-msg.map
config gen_file: /etc/nsm/Sensorname/gen-msg.map
config hostname: Sensorname
config interface: eth1
input unified2
output sguil: sensor_name=Sensorname agent_port=8000
output database: alert, mysql, user=root dbname=snorby host=127.0.0.1 disable_signature_reference_table
#output alert_syslog: LOG_LOCAL6 LOG_ALERT
output log_syslog_full: sensor_name=$Sensorname, server=$1.1.1.1, protocol udp, port 514, operation_mode complete

when i restart barnyard and check the barnyard2.log i see the following:

Executing: barnyard2 -c /etc/nsm/Sensorname/barnyard2.conf -d /nsm/sensor_data/Sensorname -f snort.unified2 -w /etc/nsm/Sensorname/ba rnyard2.waldo -i 1 -U
Running in Continuous mode

--== Initializing Barnyard2 ==--
Initializing Input Plugins!
Initializing Output Plugins!
Parsing config file "/etc/nsm/Sensorname/barnyard2.conf"
: Duplicate classification "default-login-attempt"found, ignoring this line
: Duplicate classification "non-standard-protocol"found, ignoring this line
: Duplicate classification "shellcode-detect"found, ignoring this line
: Duplicate classification "string-detect"found, ignoring this line
: Duplicate classification "suspicious-filename-detect"found, ignoring this line
: Duplicate classification "suspicious-login"found, ignoring this line
: Duplicate classification "system-call-detect"found, ignoring this line
: Duplicate classification "tcp-connection"found, ignoring this line
: Duplicate classification "trojan-activity"found, ignoring this line
: Duplicate classification "unusual-client-port-connection"found, ignoring this line
: Duplicate classification "web-application-activity"found, ignoring this line
ERROR: /etc/nsm/Sensorname/barnyard2.conf(13) Undefined variable name: Sen.
Fatal Error, Quitting..
Barnyard2 exiting
===============================================================================
Record Totals:

[Doug Burks]

Replies inline.

On Tue, Oct 7, 2014 at 5:36 PM, CB <cr...@advancedcybersecurity.co.uk> wrote:
> OK so it seems something is wrong, when defining the server IP does this need to be prefixed by a "$"

No, I don't think so.

> and does the sensor name also have to have a "$" prefixign the name?

No, I don't think so.

> are there problems with host names containing hypens "-"?

Not that I'm aware of.

[CB]

OK i have removed the "$" and "=" and i cant see any errors but I am still not receiving anything at the SIEM, please can you confirm the below is as expected:

Restart Barnyard:

sudo nsm_sensor_ps-restart --only-barnyard2
Restarting: Sensorname
* stopping: barnyard2 (spooler, unified2 format) [ OK ]
* starting: barnyard2 (spooler, unified2 format) [ OK ]

LOG FILE:

tail -300 /var/log/nsm/Sensorname/barnyard2.log

Executing: barnyard2 -c /etc/nsm/Sensorname/barnyard2.conf -d /nsm/sensor_data/Sensorname -f snort.unified2 -w /etc/nsm/Sensorname/ba rnyard2.waldo -i 1 -U
Running in Continuous mode

--== Initializing Barnyard2 ==--
Initializing Input Plugins!
Initializing Output Plugins!
Parsing config file "/etc/nsm/Sensorname/barnyard2.conf"
: Duplicate classification "default-login-attempt"found, ignoring this line
: Duplicate classification "non-standard-protocol"found, ignoring this line
: Duplicate classification "shellcode-detect"found, ignoring this line
: Duplicate classification "string-detect"found, ignoring this line
: Duplicate classification "suspicious-filename-detect"found, ignoring this line
: Duplicate classification "suspicious-login"found, ignoring this line
: Duplicate classification "system-call-detect"found, ignoring this line
: Duplicate classification "tcp-connection"found, ignoring this line
: Duplicate classification "trojan-activity"found, ignoring this line
: Duplicate classification "unusual-client-port-connection"found, ignoring this line
: Duplicate classification "web-application-activity"found, ignoring this line

+[ Signature Suppress list ]+
----------------------------
+[No entry in Signature Suppress List]+
----------------------------
+[ Signature Suppress list ]+

WARNING: Ignoring bad line in SID file: 'v1'

[Doug Burks]

I don't see anything out of the ordinary in that output.

Are you sure your Security Onion box is able to send to your SIEM over UDP 514?

Have you seen the following?

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

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

[Jose Ortiz]

Did some experiments and found that "operation_mode complete" creates a fragmented packet. RFC 3164 states that the total length of a packet must be less than 1024 bytes. I suspect that either your SIEM can not reassemble the packet, or the datagram gets discarded due to its size.

[Craig Bird]

What should be used instead of "operation_mode complete"

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

[Jose Ortiz]

You can use "operation_mode default"

[CB]

Thanks - does using default (not complete) mean i will not have the associated packet capture? Is it missing anything else?

Is there any other method of sending the full alert and packet data to an external SIEM?

/CB

[Jose Ortiz]

Refer to the attached captures. Using the "default" option will not give you the payload. There is no fragmentation if you use "protocol tcp", but the logged packet is split in 3 pieces. It will be up to the application to assemble this.

The other method of sending the full alert and packet data is "output database"

[CB]

Hi All,
Thanks for your replies I have now got this functional using "Default" but dont have the payload information, i changed this to "complete" and the SIEM recieves a hugely increased amount of events containing no information. I have changed the protocol from UDP:514 to TCP:514 but my SIEM does not support TCP Syslog.

@Jose: I am very interested in the "output database" option but cant find any information on its usage or how to configure it, do you have experience with this?

/CB

[Doug Burks]

Keep in mind that even if you get the IDS alerts sending payload
information, that's just a small piece of the entire flow. That's why
we provide full packet capture with netsniff-ng. You may be better
off using "Default" and then coming up with a way to pivot from your
SIEM to CapME to retrieve full packet capture.

[Craig B]

Payload would be beneficial for initial alert validation, we use another Full Packet Capture product with advanced indexing and search capabilities so do not use CapMe

/CB

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