Running Programs in Response to Sniffed DNS Packets - Stealthily Managing Iptables Rules Remotely, Part 2

Preparing the Infrastructure: DNS Sniffer and Iptables Chain

Before any Perl script can react to DNS traffic, the network must expose that traffic to a user‑space program. The classic tool for this job is pcap‑based sniffer, and in this guide we rely on a lightweight wrapper called watch_dns. This wrapper listens on a specified interface, filters only DNS queries, and prints each packet in a compact format:

That one‑liner is enough for a script to read a line, figure out who sent the query, and decide what to do next. The first step is to install the wrapper and make sure it runs with root privileges, because packet capturing needs elevated rights. On most distributions the wrapper lives in /opt/bin/watch_dns, but you can compile or copy it to any location you prefer.

Once you have the sniffer ready, you need an iptables chain to hold the temporary rules that will be generated on the fly. The chain is inserted into the INPUT table just before the default DROP rule. Creating it is a single line of shell:

With the chain in place, all inbound packets will first pass through allow_in. Rules you add to that chain can accept traffic from particular sources, while any packet that slips through without a matching rule will be dropped by the subsequent policy. The combination of a dynamic sniffer and a dedicated chain gives you a powerful way to grant temporary access to hosts that prove they can resolve a specific DNS name.

When deploying this system, keep in mind that the sniffer runs as root. If you prefer to run the Perl listener as a non‑privileged user, you can launch watch_dns via sudo and drop the rights for the rest of the workflow. This approach keeps the attack surface smaller while still allowing the listener to read the traffic stream.

It’s also worth noting that the DNS hostnames you want to react to must be reachable from the host running the sniffer. If the DNS server is behind a firewall or on a different VLAN, add appropriate routing or allow the traffic through before you can use the hostname as a trigger. In practice, many administrators point the queries to a local resolver that can resolve the trigger names quickly, thereby keeping the reaction time low.

With the sniffer outputting standardized lines and the chain ready, the next step is to build a Perl script that can parse those lines, look up commands to run, and invoke iptables safely. The code below is a direct descendant of the original example but has been reorganised and commented for clarity. It shows how the mapping hash works, how the script replaces placeholders with real IPs, and how periodic cleanup keeps the chain from growing indefinitely.

Constructing the Listener: Parsing, Mapping, and Executing Commands

The heart of the system is a Perl program that reads the sniffer’s output in real time. The script starts by declaring a few configuration variables. The $PERIODIC_SECONDS flag tells the listener to flush the temporary rules after a configurable interval. When set to zero, the script runs only on demand; otherwise, a simple SIGALRM loop keeps the rules fresh.

Next, the script points to the sniffer executable. On most installations, the default path is /opt/bin/watch_dns, but you can override it if you installed the tool elsewhere.

After the configuration block, a small iptables helper is defined. The $IPTABLES variable holds the absolute path to the binary (usually /sbin/iptables). The $CHAIN variable contains the name of the temporary chain we created earlier. Two data structures follow:

Here’s a distilled version of the mapping you might use:

With the mapping in place, the script opens a pipe to the sniffer:

It then enters an infinite loop, reading one line at a time. The line is parsed with a regular expression that extracts the source IP, destination IP, and hostname. If the line fails to match, the script skips it quietly unless debugging is enabled.

Once a valid command is found, the script substitutes the placeholders and runs the iptables command using the list form of system. This form avoids shell expansion and keeps the command execution clean.

If a periodic cleanup is configured, the script resets an alarm after each packet. The alarm handler, defined as run_periodic_commands, iterates over @periodic_commands and executes each list with system. In the default example, this just flushes the chain, ensuring that the temporary rules do not accumulate indefinitely.

While the Perl code is straightforward, a few edge cases deserve attention. The script does not validate IP addresses beyond the simple numeric format; malformed IPs could slip through. Also, because the sniffer is passive, it will see every DNS query that passes through, including retried or spoofed packets. If you need tighter control, consider adding an ACL in iptables to limit which sources the sniffer will process.

Finally, the whole mechanism relies on the sniffer being trustworthy. If an attacker can spoof DNS packets, they might trigger the listener to open ports they otherwise wouldn’t have. The example acknowledges this risk and flags the lack of authentication as a known vulnerability. For production use, you should place the sniffer behind a dedicated, hardened host and monitor its output with separate logging to detect abuse.

With the listener running, the sniffer feeding it, and the chain primed to accept rules, you now have a dynamic, DNS‑driven firewall that can grant or revoke access on demand. The next step is to tighten security, fine‑tune performance, and adapt the system to your particular needs.

Optimising and Securing the DNS‑Based Firewall

Having a working system is just the beginning. To make the solution reliable in a real‑world environment, you should address several practical concerns. The first is the risk of denial‑of‑service via excessive rule creation. Because every DNS query that matches a mapping key triggers a command, a malicious host could flood the sniffer with bogus queries, causing the listener to add thousands of iptables entries in a short period. The periodic flush mitigates this, but the flood could still overwhelm the kernel’s rule table. Raising $PERIODIC_SECONDS to a larger value (e.g., 30 or 60 seconds) gives the system time to drain the queue and prevents rule table exhaustion.

Second, the lack of authentication is a glaring weakness. If an attacker discovers the exact DNS names that map to privileged actions, they can generate queries that trigger those actions. A practical fix is to bind the sniffer to a private network segment that only trusted clients can reach. Alternatively, you can modify the Perl script to require a shared secret or hash embedded in the query name. For instance, using a DNS name like open-ssh.example.com could be expanded to open-ssh..example.com, and the script would verify the hash before acting.

Third, you might want to limit the types of packets the listener accepts. In the example, the mapping hash uses -p tcp for all rules, but you could extend it to allow UDP or ICMP traffic if your application requires it. Remember to always match the port number and protocol to avoid accidental openings.

Fourth, consider integrating the system with existing logging or intrusion‑detection frameworks. Every time a rule is added, emit a syslog entry with the source IP, destination IP, and hostname that triggered it. This record can later be correlated with other logs to detect suspicious patterns. If you’re using rsyslog or systemd-journald, simply prefix the log line with daemon.notice and the system will pick it up automatically.

Performance is another angle to optimize. The Perl system call blocks until the iptables command finishes, which is typically quick but can become noticeable if you add many rules in rapid succession. If you experience latency, switch to IPC::Open3 or fork child processes to run iptables asynchronously. However, be careful to handle the child processes correctly to avoid zombies.

When scaling to multiple hosts, you may want each machine to listen to its own sniffer but share a common list of hostnames. One approach is to maintain a central mapping file that each listener reads, then use iptables to direct traffic to the appropriate chain based on the hostname. This keeps the mapping logic centralized while allowing each server to react locally.

Security hygiene demands that you monitor the size of the allow_in chain regularly. The iptables -L allow_in -n --line-numbers command will show you the exact number of rules. If you see the chain growing unexpectedly, investigate the source IPs that triggered the rules. A sudden spike often indicates an ongoing attack.

Lastly, test the system thoroughly before deploying it in production. Use controlled DNS queries to confirm that rules are added and flushed as expected. Verify that unauthorized queries do not result in rule creation. And, as always, keep your system updated: iptables, the kernel, and the Perl interpreter all receive security patches that can affect how your dynamic firewall behaves.

By combining a passive DNS sniffer with a mapping‑driven listener, you get a lightweight, flexible firewall that can grant or revoke access on demand. The approach scales with your network size, integrates easily with existing tools, and can be hardened to resist abuse. With a little tuning and monitoring, this method becomes a practical addition to any security toolkit that requires rapid, on‑demand rule changes without rebooting or reloading the entire firewall configuration.