Furkan İkkan Türkçe
Back to posts
Post

· Network & System Administrator

LLM-generated iptables rules from security logs: LOG and DROP suggestion prompt

Use an LLM to analyze firewall logs and suggest temporary iptables rules. Practical prompt template for LOG and DROP actions.

Yapay ZekaiptablesloggingLLMfirewall

I’ve been experimenting with LLMs to help interpret repetitive firewall noise. Instead of manually grepping through /var/log/iptables.log for suspicious patterns, I wanted a way to feed recent log entries into a model and get actionable iptables suggestions back—specifically LOG and DROP rules for transient threats like scanners or botnets. This isn’t about replacing manual review; it’s about accelerating the triage phase.

Why automate rule suggestions from logs

In my environment, iptables logs often show bursts from the same source IP targeting unused ports—think port scans on high-numbered TCP/UDP services or repeated SSH attempts on non-standard ports. Manually correlating these takes time, especially during off-hours. By using an LLM to summarize the intent behind the log entries, I can quickly decide whether a temporary block is warranted.

The key is framing the prompt correctly. You’re not asking the model to generate production-ready firewall policy; you’re asking it to observe patterns and propose a cautious, time-bound reaction. Think of it as a junior analyst summarizing log snippets for your review.

Prompt template I use

Here’s the exact prompt I feed into a local LLM (like Mistral or Llama 3) via ollama, after extracting the last 50 lines of iptables LOG output:

Analyze the following iptables LOG entries. Each line shows a packet that matched a LOG rule (usually placed before DROP in INPUT chain).

Identify: 
- Repeating source IPs
- Common destination ports or protocols
- Likely intent (scan, brute force, misconfiguration)

Then suggest: 
1. A temporary iptables DROP rule for the most offending source (if any)
2. An optional LOG-only rule if the behavior is suspicious but not clearly malicious

Use this format for each suggestion:
iptables -I INPUT -s <IP> -p <proto> --dport <port> -j DROP
# or
iptables -I INPUT -s <IP> -p <proto> --dport <port> -j LOG --log-prefix "FIREWALL: "

Only suggest rules if a clear pattern exists. If unsure, say "No clear pattern detected."

---
<PASTE_LOG_HERE>

I keep the tone neutral and instructional. The model doesn’t need to know iptables internals—it just needs to spot repetition and infer intent from port/protocol combinations.

Real example from my logs

Last week, I pasted this snippet into the prompt:

Jan 10 03:14:22 firewall kernel: IN=eth0 OUT= MAC=... SRC=185.130.105.117 DST=10.0.0.5 PROTO=TCP SPT=45332 DPT=23
Jan 10 03:14:25 firewall kernel: IN=eth0 OUT= MAC=... SRC=185.130.105.117 DST=10.0.0.5 PROTO=TCP SPT=45335 DPT=23
Jan 10 03:14:28 firewall kernel: IN=eth0 OUT= MAC=... SRC=185.130.105.117 DST=10.0.0.5 PROTO=TCP SPT=45338 DPT=23
Jan 10 03:14:31 firewall kernel: IN=eth0 OUT= MAC=... SRC=185.130.105.117 DST=10.0.0.5 PROTO=TCP SPT=45341 DPT=23

The model responded:

Repeated TCP SYN packets to port 23 (Telnet) from 185.130.105.117. Likely scan for legacy services.

Suggested rule:
iptables -I INPUT -s 185.130.105.117 -p tcp --dport 23 -j DROP

I reviewed it, added a comment with -m comment --comment "Scanner via LLM suggestion 2024-01-10", and set a cron job to remove it after 4 hours. No false positives in this case.

Safety checks and automation

I never apply LLM-suggested rules directly. Always:

  • Review the logic
  • Add a traceable comment
  • Test in a non-production chain first (or use -C to check)
  • Schedule automatic removal unless manually extended

You could wrap this in a script that:

  1. Tails the iptables log
  2. Extracts the last N lines
  3. Feeds them to the LLM via API or local inference
  4. Parses the output for iptables -I lines
  5. Outputs to a file for manual review

But even semi-automated—just copying logs into a chat interface—saves me 5–10 minutes per incident.

Limitations and when not to use this

This works best for noisy, repetitive scans. It’s less effective for:

  • Low-and-slow attacks
  • Legitimate traffic misidentified due to asymmetric routing
  • Application-layer threats (those need WAF or ModSecurity logs)

Also, be cautious with LLMs that hallucinate iptables syntax. Always validate the generated rule with iptables -t filter -C INPUT ... before inserting.

As I mentioned before in my post on [AI-assisted log anomaly detection](https://furkanikkan.com/urun/ai-ile-log-anomali-tespiti-gpt-4o-mini-syslog-hatalarini-bulma-87), the goal isn’t to replace judgment—it’s to reduce cognitive load when the signal is buried in volume.

Final thoughts

If you’re already logging iptables drops (and you should be), this prompt turns passive logs into active triage material. It’s not magic, but it’s a force multiplier for small teams or solo admins managing perimeter defenses. Try it with your next scanner incident—just be sure to clean up the rule afterward.

Cover image: ₡ґǘșϯγ Ɗᶏ Ⱪᶅṏⱳդ · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/148598741@N02/51973552248