[Oisf-users] Suricata 2.0.8 -->Cannot get logs to SIEM

[chuckpc at yahoo.com]

Hello,
at one point after following your config, it appeared as if 'generic sim messages' were arriving at the SIEM.Of course I made more changes and I'm not back there again.I'll continue to keep working in time allotments until I get it working.
I'm still not convinced fully that messages are arriving at the Juniper JSA SIEM, however I'll keep trying things.I think what you provided me is closer to getting it working.
By the way, what options and explanations are there for ;mark.info--->      local5.*;mark.info   


thanks,Charles

      From: Brandon Lattin <latt0050 at umn.edu>
 To: Oliver Humpage <oliver at watershed.co.uk> 
Cc: chuckpc at yahoo.com; "oisf-users at openinfosecfoundation.org" <oisf-users at openinfosecfoundation.org> 
 Sent: Tuesday, June 30, 2015 10:42 AM
 Subject: Re: [Oisf-users] Suricata 2.0.8 -->Cannot get logs to SIEM
   
Ack. 
nc is great for backdoors, but not exactly my first choice for production configurations.
Just export it with a specific facility.
rsyslog.conf snippet:local5.*;mark.info              @foo.bar.com


suricata.yaml snippet (note the double syslog config; necessary as eve-log to syslog doesn't do anything without "- syslog:" also configured; someday this will get fixed?) :
  - syslog:      enabled: yes      # reported identity to syslog. If omitted the program name (usually      # suricata) will be used.      identity: "suricata"      facility: local5      level: Info ## possible levels: Emergency, Alert, Critical,                   ## Error, Warning, Notice, Info, Debug
  # Extensible Event Format (nicknamed EVE) event log in JSON format  - eve-log:      append: yes      enabled: yes      type: syslog #file|syslog|unix_dgram|unix_stream      #filename: eve-port0.json      # the following are valid when type: syslog above      identity: "suricata"      facility: local5      level: Info ## possible levels: Emergency, Alert, Critical,                   ## Error, Warning, Notice, Info, Debug      types:        - alert:            payload: no           # enable dumping payload in Base64            payload-printable: yes # enable dumping payload in printable (lossy) format            packet: no            # enable dumping of packet (without stream segments)            http: no              # enable dumping of http fields


Or you could just use Splunk with a Splunk Universal Forwarder and just eat the eve.json directly off the sensor ;-P


On Tue, Jun 30, 2015 at 9:29 AM, Oliver Humpage <oliver at watershed.co.uk> wrote:


On 30 Jun 2015, at 15:05, chuckpc at yahoo.com wrote:

> *.* @172.18.1.155:514

If that's sending absolutely everything that gets syslogged to the SIEM, perhaps the SIEM is getting confused?

Have you tried getting rsyslog to send the suricata output to a file, and then sending individual lines over to the SIEM using nc(1)? That'd make sure it really was logging the lines you'd expect, and then you can use eg

echo '<14>sourcehost LogLine' | nc -u 172.19.1.155 514

to see if you can get the SIEM to accept valid lines. Also compare said lines with the output of snort and see if there's a difference.

If that works, try limiting what's being sent in rsyslog. If it doesn't work, I'd suspect a config issue in the receiving host.

You may have already tried all this of course. I'm afraid I use logstash (and logstash-forwarder) to centralise log collection, so my knowledge of Junipers and rsyslog is limited.

Oliver.

_______________________________________________
Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
Suricata User Conference November 4 & 5 in Barcelona: http://oisfevents.net




-- 
Brandon LattinSecurity Analyst
University of Minnesota - University Information Security
Office: 612-626-6672

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20150701/66cab178/attachment.html>