Configuring Firewall Logging: Correctly Setting Up Logging for SRV1 and SRV2

Distinguishing Firewall Logs from DNS Logs

It is crucial to understand that standard firewall logging (such as iptables or nftables) records packet headers like source IP, destination IP, and protocol. In contrast, BIND (Berkeley Internet Name Domain) logs record DNS-specific events, such as zone transfers, queries, and updates. The original request specifically asks for BIND logs on SRV1 to be sent to SRV2. This is not a firewall configuration task in the traditional sense of blocking traffic, but rather a logging infrastructure setup for DNS services.

If you are looking to log dropped packets at the network level, you should refer to our guide on Block MAC Address with Iptables During Attack. However, for this article, we focus exclusively on configuring the BIND daemon to generate detailed logs and forwarding them via syslog to a central server.

Prerequisites and Network Configuration

Before modifying configuration files, ensure that both SRV1 (the DNS server generating logs) and SRV2 (the log receiver) are properly configured on your network. You must verify that:

• Syslog Service is Active: Both servers must have a syslog daemon running (e.g., rsyslog, syslog-ng, or systemd-journald).
• Network Connectivity: SRV1 must be able to reach SRV2 over UDP port 514 (standard syslog) or TCP port 514/6514 if TLS is enabled. Test this with nc -zv SRV2_IP 514.
• BIND Installation: Ensure BIND is installed on SRV1. You can check this by running named -v.

If you need to secure the connection between these servers, consider implementing SSH tunneling or using a dedicated logging agent like Fluent Bit, though standard syslog is sufficient for basic setups.

Configuring BIND Logging on SRV1

The first step is to configure BIND on SRV1 to output logs to a file or directly to the system logger. Modern BIND versions often default to logging to /var/log/named.log or via the system journal. To ensure compatibility with SRV2, we will configure BIND to use the syslog facility.

Edit the main BIND configuration file, typically located at /etc/named.conf or /etc/bind/named.conf. Add or modify the logging section as follows:

logging {
    channel syslog_debug {
        syslog local2;
        severity debug;
    };

    category default {
        syslog_debug;
    };

    category queries {
        syslog_debug;
    };
};

In this configuration:

• channel syslog_debug: Defines a custom channel that sends logs to the local2 syslog facility. Using a local facility (like local0 through local7) prevents DNS logs from mixing with other system messages.
• severity debug: Sets the logging level to debug. For production, you might prefer info or warning to reduce noise, but debug ensures all queries are captured for troubleshooting.
• category queries: Ensures that DNS query logs are sent to this channel. This is the most critical part for monitoring who is querying your DNS server.

After editing, test the configuration syntax with named-checkconf. If no errors are reported, restart the BIND service using systemctl restart named (or systemctl restart bind9 depending on your distribution).

Configuring Syslog Forwarding to SRV2

Now that SRV1 is generating logs on the local2 facility, you must configure the syslog daemon on SRV1 to forward these specific logs to SRV2. We assume rsyslog is used here, as it is the most common implementation.

Edit the rsyslog configuration file, usually /etc/rsyslog.conf or a file in /etc/rsyslog.d/. Add the following line to forward local2 logs to SRV2:

local2.* @@SRV2_IP:514

Key points about this directive:

• local2.*: Selects all severity levels for the local2 facility.
• @@: Indicates TCP forwarding. Use @ for UDP. TCP is recommended for reliability to prevent log loss during network congestion.
• SRV2_IP:514: Replace SRV2_IP with the actual IP address of SRV2.

Restart the rsyslog service on SRV1 with systemctl restart rsyslog.

Verifying Log Reception on SRV2

On SRV2, you need to configure rsyslog to accept remote logs and write them to a specific file. Edit /etc/rsyslog.conf on SRV2 and ensure the following modules are loaded:

module(load="imtcp")
input(type="imtcp" port="514")

Then, create a rule to save the incoming BIND logs:

local2.* /var/log/srv1-bind-logs.log

Restart rsyslog on SRV2. To verify the setup, perform a DNS query on SRV1 (e.g., dig example.com @localhost) and then check the log file on SRV2. You should see entries containing the query details. If logs do not appear, check firewall rules on SRV2 to ensure port 514 is open for incoming TCP connections.

For more information on securing your server environment while managing logs, see Securing an Ubuntu Server for Development Purposes.

Frequently Asked Questions

What if I want to log firewall drops instead of DNS queries?

You should configure iptables or nftables with the --log-prefix option. This writes drop events to the kernel ring buffer, which rsyslog then captures. Refer to Block MAC Address with Iptables During Attack for specific syntax examples.

How do I filter only failed DNS lookups?

In the BIND logging section, you can change the severity to warn or error. Alternatively, use rsyslog filters on SRV2 to parse the log content and discard successful queries, keeping only those with status codes indicating failure.

Can I use UDP instead of TCP for forwarding?

Yes, replace @@ with @ in the rsyslog configuration on SRV1. UDP is faster but unreliable; packets may be lost if the network is congested. TCP ensures delivery but adds slight overhead.

Why are my logs not appearing on SRV2?

Check three things: 1) Is the firewall on SRV2 allowing inbound traffic on port 514? 2) Did you restart rsyslog on both servers after changes? 3) Are the facilities matching? Ensure SRV1 uses local2 and SRV2 listens for local2.

Is it safe to run BIND in debug mode on production?

No, debug mode generates excessive logs that can fill disk space quickly. Switch the severity back to info or warning once you have verified the logging pipeline works correctly.