Network Anomaly
Introduction
RESP_ANOMALY events report network anomaly detections on ADS-TEC IRF1000 and IRF3000 devices. The appliance raises this event when the integrated monitor detects threats such as ARP spoofing or IP conflicts that may affect the OT network. The device limits event creation to five messages per hour to prevent audit.log overflow. When you see such events, verify the switch port and connected device, check for duplicated IP addresses, and ensure that only trusted devices are present on the affected network segment. Where possible, apply port security or DHCP snooping on switches and review your remote access policies to reduce the risk of successful spoofing attacks.
Webinterface View
In the VIEW web interface, RESP_ANOMALY entries are shown in the Anomaly audit section as human-readable alerts. The system parses the raw audit.log data and displays one line per detected anomaly. This view displays alerts from the integrated network monitoring system and reports potential security threats such as ARP spoofing attacks or duplicate IP addresses that conflict with the device's own IP address.
The table in the web interface contains the following columns:
| Column | Description | Example |
|---|---|---|
| Date | Local date when the anomaly was logged. | 01/10/25 |
| Time | Local time when the anomaly was logged. | 21:43:37 |
| Title | Short title of the anomaly, derived from the audit field title. |
ARP Spoofing Alert |
| Description | Human-readable description taken from the audit field description. It includes the device IP address, interface, and the conflicting MAC address. |
Device IP address (192.168.0.254) on interface (LAN) was seen being claimed by a device with a different MAC address (00:11:22:33:44:55) |
Use this view for quick operational checks. You can immediately see when the device detects suspicious ARP activity and which IP address and interface are affected. For deeper analysis, correlate the same timestamp and title with the full RESP_ANOMALY entry in the audit.log file that is ingested into your SIEM or SOC tools.
Explanation of the raw audit.log entry
The device writes RESP_ANOMALY records into audit.log. Generic auditd fields follow standard auditd behavior; refer to the official auditd documentation for full semantics. The anomaly-specific details are contained inside the msg='...' payload.
The following table summarizes the relevant fields for RESP_ANOMALY entries:
| Field | Description | Example |
|---|---|---|
| type | Audit record type. | RESP_ANOMALY |
| msg=audit(ts:serial) | Audit header with Unix timestamp and serial number. | audit(1736541817.640:20) |
| pid | Process ID of the program that emitted the message. | 6493 |
| uid | Effective UID of the process. | 65534 |
| auid | Login audit user ID. | 4294967295 |
| ses | Audit session ID. | 4294967295 |
| msg (string) | Start of the user message payload that contains anomaly details. | msg='...' |
| interface | Ethernet interface on which the network anomaly occurred. | LAN |
| ip_address | IP address involved in the anomaly. | 192.168.0.254 |
| mac_address | MAC address that was seen claiming the IP address. | 00:11:22:33:44:55 |
| title | Short title of the anomaly for display in the web UI. | ARP Spoofing Alert |
| description | Human-readable description of the network anomaly. | Device IP address (192.168.0.254) on interface (LAN) was seen being claimed by a device with a different MAC address (00:11:22:33:44:55) |
| exe | Path of the executable that wrote the audit-log message. | /sbin/arp-spoof-detector |
| hostname | Auditd hostname field; not filled for this event. | ? |
| addr | Auditd address field; not filled for this event. | ? |
| terminal | Auditd terminal field; not filled for this event. | ? |
| res | Result flag from auditd. For RESP_ANOMALY this is always set to failed, because no context-dependent success evaluation is possible. |
failed |
| UID | Text rendering of uid appended by auditd. |
UID="nobody" |
| AUID | Text rendering of auid appended by auditd. |
AUID="unset" |
When integrating into a SIEM or SOC, use type=RESP_ANOMALY as the main filter and parse the key–value pairs inside msg='...' to extract interface, IP address, MAC address, title, and description for correlation and alerting.
When the event is generated
The RESP_ANOMALY event is generated by the arp-spoof-detector program when it observes that one IP address is claimed by more than one MAC address on a monitored interface. This typically indicates ARP spoofing activity or a duplicate IP address situation that may also conflict with the firewall's own IP configuration.
The detector monitors ARP traffic on the configured interfaces. When it detects such an anomaly, it calls audit_log_user_message() from libaudit and writes a RESP_ANOMALY entry into the audit.log file. The detector sends a user message when its detection state changes, for example when it detects a new anomaly or when an existing anomaly is cleared. To protect log storage, the system limits RESP_ANOMALY event creation to five messages per hour.
Sample audit.log entry
type=RESP_ANOMALY msg=audit(1736541817.640:20): pid=6493 uid=65534 auid=4294967295 ses=4294967295 msg='interface="LAN" ip_address="192.168.0.254" mac_address="00:11:22:33:44:55" title="ARP Spoofing Alert" description="Device IP address (192.168.0.254) on interface (LAN) was seen being claimed by a device with a different MAC address (00:11:22:33:44:55)" exe="/sbin/arp-spoof-detector" hostname=? addr=? terminal=? res=failed'UID="nobody" AUID="unset"