Linux - System Preferences - Ensure Suspicious Packets Are Logged

What the martian packet logger does

This Automox Worklet™ enables kernel-level logging for martian packets on your Linux endpoints. Martian packets are IP frames with impossible or un-routable source addresses that should never appear on your network.

The Worklet configures two critical kernel parameters: net.ipv4.conf.all.log_martians and net.ipv4.conf.default.log_martians. When enabled, these settings cause the kernel to log any packets with suspicious source addresses to the system log, creating an audit trail of potential network reconnaissance or spoofing attempts.

If the Worklet detects these settings are not persistent, it creates a configuration file in /etc/sysctl.d/automox_martian_logging.conf to preserve the settings across system reboots.

Martian packets, also known as impossible datagrams, are packets with source IP addresses that should never appear on any legitimate network. These addresses include reserved ranges like 0.0.0.0/8, 10.0.0.0/8 in external traffic, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12 in external traffic, 192.0.2.0/24, 192.168.0.0/16 in external traffic, 224.0.0.0/4, and 240.0.0.0/4. When such packets appear on your network, they indicate either misconfigured routing, network attacks, or compromised infrastructure.

The Worklet applies these settings at runtime using sysctl, making them immediately active on your endpoint. It also creates a persistent configuration file so that the settings remain in place across system reboots and survive service restarts. This dual-layer approach guarantees that martian packet logging is both immediately effective and persistently configured across endpoint lifecycle events.

Why enable martian packet logging

Martian packets represent a clear security signal. When an endpoint receives packets claiming to originate from impossible addresses, it indicates either a misconfigured network path or an active attack. By logging these events, you gain visibility into network anomalies that other security tools might miss.

Without martian logging enabled, your kernel silently drops these suspicious packets and discards evidence of the attempt. This leaves your security team blind to reconnaissance, IP spoofing, and source route attacks that target your endpoints. Enabling logging transforms your endpoints into network monitors that contribute to your overall security posture.

Security frameworks and compliance standards recommend or require comprehensive logging of network anomalies. CIS Benchmarks specifically reference martian packet logging as a defense mechanism. Organizations handling sensitive data benefit from this additional layer of network monitoring, which helps identify attack patterns across your infrastructure.

Martian packet logging is particularly valuable for detecting network-based attacks that operate at the IP layer, below most traditional application security tools. Attackers using IP spoofing to launch denial of service attacks, reflective amplification attacks, or session hijacking attempts all generate martian packets that get logged when this feature is enabled. Your security team can use these logs to identify attack sources, correlate incidents with other suspicious activity, and adjust firewall rules and network configurations to block attack vectors.

In environments with significant network monitoring requirements, martian packet logging integrates with centralized logging systems like syslog, ELK Stack, and Splunk. The entries in your kernel log can be collected and analyzed at scale to detect infrastructure-wide patterns that indicate coordinated attacks or systematic reconnaissance.

How martian packet logging works

1. Evaluation phase: The Worklet checks the current values of net.ipv4.conf.all.log_martians and net.ipv4.conf.default.log_martians using the sysctl utility. If both values equal 1, logging is properly enabled and the evaluation exits successfully. If either value is 0, the evaluation reports a failure, triggering remediation.

2. Remediation phase: The Worklet checks whether martian logging configuration already exists in /etc/sysctl.d/. If no persistent configuration exists, it creates /etc/sysctl.d/automox_martian_logging.conf and writes the required settings. It then applies the settings immediately using sysctl -w and flushes the routing cache with sysctl -w net.ipv4.route.flush=1 to apply the changes immediately. Finally, it re-evaluates both parameters to confirm successful configuration.

Martian packet logging requirements

• Linux endpoint (any distribution using sysctl and systemd)

• Root or sudo access to execute sysctl commands

• Write access to /etc/sysctl.d/ directory

• Automox Agent version 1.42.22 or later

Expected kernel logging behavior

After the Worklet executes successfully, both kernel parameters will be set to 1, and your endpoint will begin logging all martian packets to the system kernel log. You can verify this by checking the configuration with sysctl net.ipv4.conf.all.log_martians and sysctl net.ipv4.conf.default.log_martians, both of which should return 1.

When the endpoint receives martian packets, entries will appear in your kernel log (typically viewable via dmesg or in /var/log/kern.log depending on your logging configuration) with messages like "Martians..." or IP spoofing warnings. This evidence of suspicious network activity can be correlated with other security events to identify coordinated attacks or reconnaissance patterns against your endpoints.

To verify the Worklet's success, log into the endpoint and run sysctl net.ipv4.conf.all.log_martians net.ipv4.conf.default.log_martians. Both should return a value of 1. You can also check that the configuration file was created with cat /etc/sysctl.d/automox_martian_logging.conf if the Worklet created the persistent configuration. Running dmesg | grep -i martian will show any martian packets that have already been logged since the Worklet ran.

The Worklet's remediation logs also appear in the Automox Activity Log within the console, providing a timestamped record of when martian logging was enabled on each endpoint. This audit trail is valuable for compliance reporting and incident response investigations where you need to establish when specific security controls were activated.

How to validate verify suspicious packets are logged changes

1. Run this Worklet on a pilot Linux endpoint and review evaluation output for verify suspicious packets are logged.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as exit, else.

4. Validate remediation effects from script operations such as function, sysctl, check_sysctl_martian_logging, then rerun evaluation for compliance.