Sending alerts via syslog

Syslog output allows an OSSEC manager to send the OSSEC alerts to one or more syslog servers. Because OSSEC only sends the alerts via syslog, these options are for server or local installations only.

OSSEC also supports sending alerts via cef, json, and to Splunk.

Configuration options

These configurations options require a server or local installation.

syslog_output
server
  • IP Address of the syslog server.
  • Allowed: any valid IP address
port
  • Port to forward alerts to.
  • Default 514
  • Allowed: Any valid port
level
  • Minimum alert level of the alerts to be forwarded.
  • Allowed: 1 - 16
group
  • Alerts belonging to this group will be forwarded.
  • Allowed: Any valid group. Separate multiple groups with the pipe (|) character.
  • Examples:
<group>syscheck</group>
<group>authentication_failure|authentication_success</group>
rule_id
  • Alerts matching this rule_id will be forwarded.
  • Allowed: Any valid rule_id
location
  • Alerts from this location will be forwarded.
  • Allowed: Any valid logfile location
use_fqdn
  • By default, ossec truncates the hostname at the first period (‘.’) when generating syslog messages. Setting this option to ‘yes’ will cause it to use the full hostname configured on the server.
  • Default no
  • Allowed yes, no
format
  • Format of alert output. The default format is “default”, or full syslog output.
  • CEF is the ArcSight Common Event Format.
  • json can be used with a variety of tools.
  • The splunk option is for sending data to a Splunk server.
  • Allowed default, cef, splunk, json
  • Example:
<syslog_output>
  <server>10.0.0.1</server>
  <port>514</port>
  <format>cef</format>
</syslog_output>

Enabling Syslog output

An OSSEC server can be configured to send the alerts via syslog. In this example all alerts are sent to 192.168.4.1, and alerts of level 10 and above are also sent to 10.1.1.1:

<ossec_config>
  ...

  <syslog_output>
    <server>192.168.4.1</server>
  </syslog_output>

  <syslog_output>
    <level>10</level>
    <server>10.1.1.1</server>
  </syslog_output>

  ...
</ossec_config>

After this change is made, the client-syslog process should be enabled:

# /var/ossec/bin/ossec-control enable client-syslog

And finally restart the OSSEC processes:

# /var/ossec/bin/ossec-control restart

ossec-csyslog should start along with the other OSSEC processes:

Starting OSSEC HIDS v2.8 (by Trend Micro Inc.)...
...
Started ossec-csyslogd...
...

And in the logs:

# tail -n 1000 /var/ossec/logs/ossec.log | grep csyslog
2008/07/25 12:55:16 ossec-csyslogd: INFO: Started (pid: 19412).
2008/07/25 12:55:16 ossec-csyslogd: INFO: Forwarding alerts via syslog to: ‘192.168.4.1:514′.
2008/07/25 12:55:16 ossec-csyslogd: INFO: Forwarding alerts via syslog to: ‘10.1.1.1:514′.

Here is an example of what the listening syslog daemon should receive (every log separated by level, rule, location and the actual event that generated it):

Jul 25 12:17:41 enigma ossec: Alert Level: 3; Rule: 5715 - SSHD authentication success.; Location: (jul) 192.168.2.0->/var/log/messages;
srcip: 192.168.2.190; user: root; Jul 25 13:26:24 slacker sshd[20440]: Accepted password for root from 192.168.2.190 port 49737 ssh2

Examples:

Send all alerts to 10.10.10.125:

<syslog_output>
  <server>10.10.10.125</server>
</syslog_output>

Send all alerts to 10.10.10.126 in CEF:

<syslog_output>
  <server>10.10.10.126</server>
  <format>cef</format>
</syslog_output>

Send all alerts level 6 and above to 10.10.10.127 on port 515:

<syslog_output>
  <server>10.10.10.127</server>
  <port>515</port>
  <level>6</level>
</syslog_output>