Eyeglass Alarm Forwarding and Syslog Guide

Overview

Alarms can be forwarded over syslog. This guide explains how to filter alarms by severity, application, or alarm code, and forward the matching alarms to a syslog server.

Scope note

For richer, field-level alarm integration (JSON payloads, SIEM/SOAR/ITSM tools), the Webhook alarm integration and the vendor-specific SIEM integrations under the Integration Guide are the recommended and better-supported path. Syslog forwarding has a lower data ceiling than webhooks — see Limitations below.

Limitations

• Syslog messages carry limited information compared to email or webhook alerts. This mechanism only provides the alarm type, source application, and severity — not full event detail.
• Only the forwarding methods documented below are supported.

Deprecation Notice

• SNMP forwarding was deprecated as of release 2.5.8.1.
• /var/log/messages is being deprecated as a log source for alarm forwarding. As of release 2.5.7, alarms are written to a dedicated log using syslog-ng.

Supported Alarms

All Eyeglass alarms are documented in the Alarm Codes reference.

Requirements

• Eyeglass OVF version 2.5.8 or later, on openSUSE 15.1 or later.

Configure Syslog Forwarding

Release 2.5.7 or later is required. Alarms are written to a dedicated log (/opt/superna/sca/logs/igls_alarms.log) that rolls over independently of the database-backed alarm history shown in the GUI.

1. SSH to the appliance as admin, then elevate to root:

   sudo -s

2. Edit the syslog-ng configuration:

   nano /etc/syslog-ng/conf.d/superna.conf

3. Check your syslog-ng version, since the config file's @version line must match it:

   syslog-ng --version

4. Add a filter, source, destination, and log block. Example — forward two specific Ransomware Defender alarm codes to a syslog server:

   @version: 3.29
   
   filter f_superna {
     message("RSW0002") or message("RSW0011") ;
   };
   
   source igls_src { file("/opt/superna/sca/logs/igls_alarms.log"); };
   
   destination logserver { udp("x.x.x.x" port(514)); };
   
   log {
     source(igls_src);
     filter(f_superna);
     destination(logserver);
   };

   Replace x.x.x.x with your syslog server's IP address, and @version with the value returned by syslog-ng --version.

5. Restart the service for changes to take effect:

   systemctl restart syslog-ng

6. Confirm it's running:

   systemctl status syslog-ng

   It should show an active/running state.

How to Filter and Forward Alarms

Forward by Severity

filter f_superna {
  message("Severity:CRITICAL") or message("Severity:MAJOR") ;
};

Forward by Alarm Code (Recommended)

The most precise option — forward only the exact alarm codes you need. See the Alarm Codes reference for the full list.

filter f_superna {
  message("RSW0002") or message("RSW0011") ;
};

Filter by Application

Each Eyeglass feature has an alarm-code prefix:

• Ransomware Defender: RSW
• Easy Auditor: EAU
• DR: SCA

Forward Ransomware Defender lockout/restore alarms, excluding Security Guard test alarms (replace igls-sg with your configured Security Guard service account name):

filter f_superna {
  (message("RSW0002") or message("RSW0011")) and not message("igls-sg") ;
};

Forward all Ransomware Defender and Easy Auditor alarms:

filter f_superna {
  message("RSW") or message("EAU") ;
};

Forward all Ransomware Defender alarms except Security Guard alarms:

filter f_superna {
  (message("RSW")) and not message("igls-sg");
};

Integrating Ransomware Defender Events with a SIEM

Best Practice

Syslog and log-length limits mean not all data available in Ransomware Defender is captured this way. The Webhook alarm integration is the recommended integration path — it delivers a full JSON payload with field-level data for programmatic SIEM processing.

The syslog alarm raised when Ransomware Defender detects a user includes the user ID, IP address, and a subset of the affected files. This IP address can be used in a SIEM trigger to locate and disable the corresponding network port. Example:

[DEBUG] IGLS_ALARMS:168 - Eyeglass, , Event: 2021-02-26 19:28:23.916, AID:AD02\sgdemo, Port:Nil, Type:null, EntityType:, Extra Data:{"clientIps":"172.31.1.65","info":"Successfully locked out user AD02\\sgdemo"}, Description:Locked user access.172.31.1.65, NSA, Severity:CRITICAL, Impact:false, Category:RSW0002

Use the client IP and user fields to build a trigger in your SIEM to disable the port the affected host is connected to.

Finding Example Syslog Formats

cat /opt/superna/sca/logs/igls_alarms.log

Syslog Message Format

Eyeglass syslog messages are comma-separated with the following sections:

#	Section	Description
1	[DEBUG] IGLS_ALARMS:168 - Eyeglass	Always the same literal prefix
2	(empty)	Always blank
3	Event: <value>	Timestamp of the event
4	AID:<value>	Entity of the alarm — varies by alarm type (e.g. affected user for Ransomware Defender, source/target cluster + access zone for DR Zone Readiness)
5	Port:Nil	Always Nil
6	Type:null	Always null
7	EntityType:	Always blank
8	Extra Data:{<value>}	Alarm-type-specific detail — may include info, event severity, user, affected zone, affected cluster, detectors, number of affected files, status, start/finish times, job source, or a failover log URL
9	Description: <value>	Human-readable description, e.g. "Readiness job execution found warnings."
10	NSA	Always NSA
11	Severity:<value>	Alarm severity
12	Impact:false	Always false
13	Category:<value>	Alarm code — see the Alarm Codes reference

Example: Ransomware Event

[DEBUG] IGLS_ALARMS:168 - Eyeglass, , Event: 2023-04-27 01:39:11.445, AID:ADTEST1\tuser1, Port:Nil, Type:null, EntityType:, Extra Data: {"clientIps":"172.25.22.21","event severity":"WARNING","user name":"ADTEST1\\tuser1","affected zone":"System","affected Isilon clusters":["dg-isi34"],"detectors":"THREAT_DETECTOR_03","number of affected files":"60","info":"Lockout required."}, Description:Ransomware event received. Event severity: WARNING, user: ADTEST1\tuser1172.25.22.21, NSA, Severity:CRITICAL, Impact:false, Category:RSW0001

Example: DR Failover

[DEBUG] IGLS_ALARMS:168 - Eyeglass, , Event: 2023-04-27 22:44:34.25, AID:DFS Policy Failover 2023-04-27_22-40-01, Port:Nil, Type:null, EntityType:, Extra Data: {"Status":"Success","Finished":1682649874241,"Started":1682649601989,"URL":"https://172.25.22.42/failover_logs/DFS_Failover__dg-isi34__2023-04-27_22-40-01__SUCCESS/DFS_Failover__dg-isi34__2023-04-27_22-40-01__SUCCESS.html"}, Description:Failover Succeeded, NSA, Severity:INFORMATIONAL, Impact:false, Category:SCA0040

Example: Easy Auditor

[DEBUG] IGLS_ALARMS:168 - Eyeglass, , Event: 2023-04-27 23:21:42.879, AID:auditreport1, Port:Nil, Type:null, EntityType:, Extra Data: {"info":[{"Search type:":"MANUAL"},{"Query name:":"auditreport1"},{"Number of records:":0}]}, Description:Easy Auditor Report job succeeded., NSA, Severity:INFORMATIONAL, Impact:false, Category:EAU0006

Troubleshooting Syslog Forwarding

1. Enable verbose logging:

   syslog-ng-ctl verbose --set=on
2. Check forwarding statistics for the destination label used in your config (logserver in the examples above):

   syslog-ng-ctl stats | grep logserver
   If the counters are zero or not incrementing, nothing has matched your filter.
3. Reset the stats to re-test:

   syslog-ng-ctl stats --reset

Packet Capture for Syslog Messages

1. Log in as admin, then elevate to root:

   sudo -s
2. Monitor UDP traffic to your syslog server (replace x.x.x.x with its IP address):

   tcpdump -nnAs0 -i eth0 udp port 514 -v | grep -A 2 "x.x.x.x"
   This produces no output until a matching alarm is forwarded — leave it running.
3. In a second SSH session, trigger a test alarm:

   igls test AlarmTest
   note

   The random test alarm may not match your configured filter — adjust your filter to match on severity (see the examples above) if needed.

4. Repeat the test and check the stats counter until you see a packet appear in the first session, then verify the message arrives on your actual syslog server.