I’ve been experimenting with LLMs to make sense of noisy security logs, especially when you need to act fast. The idea is simple: feed syslog entries from failed SSH attempts, port scans, or suspicious traffic into a prompt, and get back a targeted iptables rule you can apply temporarily. It’s not about replacing your firewall team — it’s about giving you a starting point when you’re staring at a wall of journalctl output at 2 a.m.
Here’s how I set it up in my environment. First, I collect logs using a simple tail command focused on auth failures:
journalctl -u sshd --since '5 minutes ago' | grep 'Failed password' | awk '{print $NF}' | sort | uniq -c | sort -nr
This gives me a count of failed attempts per IP. I pipe that into a Python script that formats it for an LLM prompt. The prompt tells the model: "Based on these repeating failed SSH attempts from the following IPs, suggest a single iptables rule to block the top offender for 30 minutes. Return only the rule."
For example, if the log shows 47 failed attempts from 185.130.105.227, the LLM might return:
`iptables -I INPUT -s 185.130.105.227 -p tcp --dport 22 -j DROP
To remove after 30 minutes:
iptables -D INPUT -s 185.130.105.227 -p tcp --dport 22 -j DROP
Or automate removal with:
(sleep 1800 && iptables -D INPUT -s 185.130.105.227 -p tcp --dport 22 -j DROP) &
I’ve found that keeping the prompt tight and task-focused yields better results than asking for a full analysis. The model doesn’t need to know about your network topology — just the pattern and the action you want.
One thing I learned the hard way: never auto-apply the rule without reviewing it. I once had an LLM suggest blocking an entire /16 because it misread clustered cloud IPs as a single attacker. Now I always check the output manually before running it. I also limit the suggestion to a single IP and a specific port unless the log clearly shows a broader pattern.
As I mentioned before in my post on LLM-generated iptables suggestions, the goal isn’t full automation — it’s augmentation. You still own the decision. But when you’re tired and the logs are piling up, having the model do the first pass saves minutes that add up.
For longer-term use, I’m looking at wrapping this in a systemd timer that runs every 5 minutes, checks for new patterns, and logs suggestions to a file for review. No auto-execution — just a ready-to-copy rule when you need it. It’s low-risk, high-signal, and fits right into an existing log-watching habit.
If you’re already centralizing logs with tools like Graylog or ELK, you could extend this to query those backends instead of journalctl. The core idea stays the same: turn noise into actionable, specific firewall guidance — one prompt at a time.
Cover image: Jefferson Lab · PDM (Openverse / kamu malı) · https://www.flickr.com/photos/53950384@N02/55166241881