Send copy of SNORT alerts to remote server.

[Jake Sallee]

I am using an open source NAC called PacketFence, which supports network remediation based on snort events.

I am also deploying a distributed snort sensor network.

My question is, is it possible to configure the central server to forward the events it receives from my sensors to my NAC instead of having to try to receive alerts from all of my sensor boxes.

The SO server already acts as an excellent aggregator and it would simplify my configuration immensely.

I searched to archives here and didn't find much about this. I will keep looking and practicing my google-fu but any assistance is greatly appreciated.

[Pietro Delsante]

Hi Jake,

I think that this might be similar to what you want to do:

https://groups.google.com/d/msg/security-onion/KY9EHLIQiZM/xU-NPNiLHvUJ

You could set up your sensors to forward the Snort events to the server through Barnyard2 and syslog-ng, and have your server act as a syslog-ng relay. Unfortunately this would duplicate the fluxes between the sensors and the collector, as the sensors are already forwarding the events through the Sguil agent. I am not aware of any easy way to configure the server to take the events received through Sguil and forward them to an external server through syslog or anything else, but I would be extremely happy if there were anything like that, as I would use it as well.

Regards,
Pietro

[Jake Sallee]

Okay!

So, after some research and a very brief conversation with a sguil dev, it seems like extending the sguil server program to send a copy of the snort alerts to a remote address should be doable with less effort than I initially feared.

So, with that in mind, I have decided take on the task of writing said code myself. I will contribute the code back to the project if the devs think it is good enough.

My question is for the SO dev team. Do you make heavy modifications to the sguil server program? Such that if I was to study the source from the sguil website I would not be able to roll any code I generate into the server in SO.

[Doug Burks]

Hi Jake,

Before you begin modifying source code, have you considered monitoring
/var/log/nsm/securityonion/sguild.log? It may give you everything you
need.

If you decide that you need to modify source code, you'll find that
the changes we've made to Sguil are very small. You can grab our
source like this:

apt-get source securityonion-sguil-server

This will give you:
- the original sguil tarball
- our patches
- the final code with our patches integrated

Doug

> --
> 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/groups/opt_out.
>
>



--
Doug Burks
http://securityonion.blogspot.com

[Pietro Delsante]

Hi Doug,

Please correct me if I'm wrong, but the log messages you're talking about would be something like this:

****************************
2013-07-31 05:23:22 pid(31549) Sensor Data Rcvd: GenericEvent 0 3 misc-activity test-sensor-eth1 {2013-07-31 05:08:31} 10 16071203 16071203 55524C205858582E5858582E5858582E3437 192.168.236.222 195.234.233.47 6 57713 80 10001 420042 1 4D6574686F643A20504F535420486F73743A205858582E5858582E5858582E3437205552493A202F525043322052656665727265723A202D2055413A20544D5320487474702055736572204167656E742028636F6D70617469626C653B204D53494520352E353B2057696E646F7773204E5420352E3029205472616E732044657074683A2031205265717565737420426F6479204C656E6774683A2035313120526573706F6E736520426F6479204C656E6774683A2038383634312053746174757320436F64653A2032303020537461747573204D6573736167653A204F4B20496E666F20436F64653A202D20496E666F204D6573736167653A202D2046696C656E616D653A202D20546167733A2028656D7074792920557365726E616D653A202D2050617373776F72643A202D2050726F786965643A202D204D494D4520547970653A20746578742F786D6C204D44353A202D2045787472616374696F6E2046696C653A202D205549443A204142324E4833624B4B746C
****************************

Applying all necessary hex decoding, this would result in something like:

****************************
2013-07-31 05:23:22 pid(31549) Sensor Data Rcvd: GenericEvent 0 3 misc-activity test-sensor-eth1 {2013-07-31 05:08:31} 10 16071203 16071203 "URL XXX.XXX.XXX.47" 192.168.YYY.YYY XXX.XXX.XXX.47 6 57713 80 10001 420042 1 "Method: POST Host: XXX.XXX.XXX.47 URI: /RPC2 Referrer: - UA: TMS Http User Agent (compatible; MSIE 5.5; Windows NT 5.0) Trans Depth: 1 Request Body Length: 511 Response Body Length: 88641 Status Code: 200 Status Message: OK Info Code: - Info Message: - Filename: - Tags: (empty) Username: - Password: - Proxied: - MIME Type: text/xml MD5: - Extraction File: - UID: AB2NH3bKKtl"
****************************

Unfortunately, using this format directly would mean quite a hard work on the SIEM's side, which is something that many of us would rather avoid, I assume. So, basically, using sguild.log would mean to write something that takes these Sguil logs, unpacks them and rebuilds the original Barnyard2 syslog format to be passed to the SIEM (or whatever).

You're right this might be easier than modifying Sguil's own code, but this could also be done by reading the MySQL database; I'm just not so sure about which method would be the best in terms of performances...

[Paul Halliday]

> --
> 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/groups/opt_out.
>
>

Couldn't you just specify multiple outputs in barnyard.conf?


--
Paul Halliday
http://www.pintumbler.org/

[Doug Burks]

Depending on what information Jake is looking for, he might be able to
just monitor /var/log/nsm/securityonion/sguild.log for "Alert
Received" lines which wouldn't require any decoding.
Doug

[Pietro Delsante]

On Wednesday, July 31, 2013 4:38:18 PM UTC+2, Doug Burks wrote:
> Depending on what information Jake is looking for, he might be able to
>
> just monitor /var/log/nsm/securityonion/sguild.log for "Alert
>
> Received" lines which wouldn't require any decoding.
>
> Doug
>

Well, no idea about what Jake's needs are, I was talking from my very own point of view... :-P However, I don't know PacketFence, but I am pretty sure it would prefer to receive Snort's events in its original syslog format (i.e. the one used by Barnyard2), rather than the logs produced by sguild.

For the moment, the only way I have found to obtain syslog fluxes that are compatible with a SIEM or remote syslog collector or anything of the like is to have each sensor forward the logs directly from Barnyard2, which is something I would rather avoid as it is a duplicate, and it also makes my overall architecture a bit more complicated as I also have to tunnel this syslog traffic into the autossh tunnel...

[Jake Sallee]

If I may, I will clarify my needs and perhaps then you may be able to let me know if I am way off base or not.

PackeFence is our NAC solution and it can act on SNORT alerts, this much has already been established.

The reasoning behind trying to get the alerts from the SO server is the fact that I am in the process of deploying 50+ sensors in different buildings across my campus.  Having a single point to get the logs from makes log collection easier and also the maintenance and management much easier.  It will also save bandwidth on the network since otherwise I would need to effectively double the traffic coming from the sensors.

It seems that PacketFence is really only looking for 2 things; the source IP that generated the alert and the SNORT ID for the alert.  Both of which are contained in the alert received line that Doug mentioned.

As I understand it, PF simply parses the log as it arrives and looks for SNORT IDs it is configured to trigger on and then takes the configured action on the source IP contained in that alert.

If this is is true then no decoding is necessary and my current theory is to simply reflect the log to the PF server and write the custom regex necessary to handle the new format of the log input ... and it SHOULD "just work".

IF this works, I will be able to combine the real-time scanning and forensic capabilities of SO with ability to remediate and deny access to the network via NAC ... this is the holy grail of network security ... at least for me : )

I am always open to suggestions and if you can spot any omissions in my reasoning, please, by all means tell me.

Thank you for your dialog in this thread, it is very helpful.

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

[A T]

Hi,

I have same problem now. I want to know if someone had implemented that and what is the solution.

Thank you

[Doug Burks]

Please see:
https://code.google.com/p/security-onion/wiki/ThirdPartyIntegration

> 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/groups/opt_out.

[A T]

Thank you so much Doug

[Clement Chen]

If I remember correctly, SO used to send Snort alerts to /var/log/syslog. In my system it looks like the following:

Jun 26 23:29:23 xxxx snort: [1:16078:4] SERVER-WEBAPP PHP memory_limit vulnerability exploit attempt [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 12.201.135.200:59241 -> xxx.xxx.xxx.xxx:80

I have Splunk monitoring the file and extract Snort Alerts out of it.

But interestingly it was gone after I upgraded SO. Do you know what changes causes this?

Thanks.

[Doug Burks]

Hi Clement,

Security Onion configures Barnyard2 to send Snort alerts to syslog.
My guess is that you chose to disable ELSA leaving the stock syslog
config in place (writing to /var/log/syslog). Is that correct?

Have you made any changes to barnyard2.conf or perhaps enabling ELSA?