# How to Configure Separate iptables Logging for Security Monitoring

> Learn to configure separate iptables logging for enhanced security monitoring. This guide shows how to use log prefixes and rsyslog to manage firewall logs efficiently and prevent disk issues.

- Repository: [IMTheNachoMan/How-To-Secure-A-Linux-Server](https://github.com/imthenachoman/How-To-Secure-A-Linux-Server)
- Tags: how-to-guide
- Published: 2026-05-14

---

**To configure separate iptables logging for security monitoring, add a unique `--log-prefix` to your firewall rules, configure rsyslog to filter those prefixed messages into a dedicated file, and implement log rotation to prevent disk exhaustion.**

When iptables logs are mixed into general system files like `/var/log/syslog`, security events become needles in a haystack. The `imthenachoman/How-To-Secure-A-Linux-Server` repository documents a proven method for isolating firewall traffic into a standalone log that intrusion detection tools can monitor efficiently. This approach creates a clean, searchable audit trail without the noise of general system messages.

## Step 1 - Add a Unique Log Prefix to iptables Rules

The foundation of separate logging is the `--log-prefix` parameter. When creating or editing firewall rules, append `--log-prefix "[IPTABLES] "` (including the trailing space) to the `LOG` target. This tag makes every log line uniquely identifiable.

According to the repository's README, this prefix is required for tools like PSAD (Port Scan Attack Detector) to distinguish firewall events from other system logs【https://github.com/imthenachoman/How-To-Secure-A-Linux-Server/blob/master/README.md#L3850】.

Example rule configuration:

```bash
sudo iptables -A INPUT -p tcp --dport 22 -j LOG --log-prefix "[IPTABLES] "

```

The trailing space after the bracket ensures clean separation between your tag and the kernel-generated message content.

## Step 2 - Configure rsyslog to Filter and Redirect

Once your rules emit prefixed logs, create [`/etc/rsyslog.d/10-iptables.conf`](https://github.com/imthenachoman/How-To-Secure-A-Linux-Server/blob/main//etc/rsyslog.d/10-iptables.conf) to intercept these messages before they reach the general syslog. The repository provides the exact configuration in the *Separate iptables Log File* section【https://github.com/imthenachoman/How-To-Secure-A-Linux-Server/blob/master/README.md#L3852-L3855】:

```conf
:msg, contains, "[IPTABLES] " /var/log/iptables.log
& stop

```

**Key directives explained:**

- **`:msg, contains, "[IPTABLES] "`** - Selects any log line containing your prefix.
- **`/var/log/iptables.log`** - The dedicated destination file.
- **`& stop`** - Terminates processing for matched messages, preventing duplication in `/var/log/syslog`.

Apply the configuration by reloading rsyslog:

```bash
sudo systemctl restart rsyslog

```

## Step 3 - Implement Log Rotation

A dedicated log file requires rotation to prevent unbounded growth. Create `/etc/logrotate.d/iptables` with the following settings referenced in the repository【https://github.com/imthenachoman/How-To-Secure-A-Linux-Server/blob/master/README.md#L3900-L3903】:

```conf
/var/log/iptables.log {
    rotate 7
    daily
    compress
    missingok
    notifempty
    create 640 root adm
}

```

This configuration retains one week of compressed logs (`rotate 7`, `daily`, `compress`), skips rotation if the file is missing (`missingok`), skips empty files (`notifempty`), and recreates the file with secure permissions (`create 640 root adm`).

## Integration with Security Monitoring Tools

Isolating iptables logs significantly enhances security monitoring capabilities. The repository demonstrates this integration in the *iptables Intrusion Detection and Prevention with PSAD* section【https://github.com/imthenachoman/How-To-Secure-A-Linux-Server/blob/master/README.md#L1878-L1953】.

**Benefits include:**

- **Reduced false positives:** Tools like PSAD and Fail2Ban monitor only `/var/log/iptables.log` instead of parsing entire system logs.
- **Performance efficiency:** Rsyslog filtering occurs at the system level, writing only relevant lines to disk.
- **SIEM ready:** The dedicated file can be shipped to centralized logging platforms without filtering overhead.

## Complete Implementation Script

Apply the entire pipeline with the following commands:

```bash

# Add logging rule with unique prefix

sudo iptables -A INPUT -p tcp --dport 22 -j LOG --log-prefix "[IPTABLES] "

# Create rsyslog filter configuration

cat <<'EOF' | sudo tee /etc/rsyslog.d/10-iptables.conf
:msg, contains, "[IPTABLES] " /var/log/iptables.log
& stop
EOF

# Activate rsyslog changes

sudo systemctl restart rsyslog

# Create logrotate configuration

cat <<'EOF' | sudo tee /etc/logrotate.d/iptables
/var/log/iptables.log {
    rotate 7
    daily
    compress
    missingok
    notifempty
    create 640 root adm
}
EOF

```

## Summary

- **Tagging:** Use `--log-prefix "[IPTABLES] "` on iptables LOG targets to create filterable log entries.
- **Routing:** Configure [`/etc/rsyslog.d/10-iptables.conf`](https://github.com/imthenachoman/How-To-Secure-A-Linux-Server/blob/main//etc/rsyslog.d/10-iptables.conf) with `:msg, contains` selectors and `& stop` directives to isolate traffic to `/var/log/iptables.log`.
- **Maintenance:** Deploy `/etc/logrotate.d/iptables` with daily rotation and seven-day retention to ensure sustainable storage usage.
- **Monitoring:** Direct PSAD, Fail2Ban, and SIEM tools to the dedicated log file for efficient threat detection.

## Frequently Asked Questions

### Why is the trailing space important in the iptables log prefix?

The trailing space after `[IPTABLES]` ensures clean separation between your custom tag and the kernel-generated log content. This prevents concatenation issues and makes grep patterns, regular expressions, and parsing scripts more reliable when analyzing `/var/log/iptables.log`.

### What happens if I omit the `& stop` directive in rsyslog?

Without `& stop`, rsyslog continues processing matched messages through subsequent rules in the configuration chain. This results in duplicate entries appearing in both your dedicated iptables log and the default system logs like `/var/log/syslog`, defeating the purpose of isolation.

### How does separate iptables logging improve PSAD performance?

PSAD (Port Scan Attack Detector) monitors firewall logs to detect malicious traffic patterns. When iptables logs are isolated in `/var/log/iptables.log`, PSAD parses a significantly smaller dataset rather than scanning entire system logs, reducing CPU usage and minimizing false positives from unrelated system events.

### Can I use this method with nftables or ufw?

While this specific guide targets legacy **iptables**, the same architectural pattern applies: use the nftables `log prefix` option or configure UFW's underlying iptables rules with `--log-prefix`, then apply identical rsyslog filtering and logrotate configurations to achieve separate logging for any Linux firewall subsystem.