I’m working on a Python script that monitors the /var/log/suricata/fast.log file to detect intrusion attempts. When an intrusion is detected, the script sends an email alert to the administrator. Once it’s complete, I’ll be happy to share it with the community!
I’m looking to add a feature that will automatically block IP addresses involved in high-priority intrusion attempts. Specifically, I want the script to:
Add the offending IP address to a block list or group.
Create a rule to block traffic from that IP.
I’d like to handle this via a console command because I need to integrate it directly into my script.
Does anyone know how to block an IP address using a console command on Linux? Any guidance on how to implement this would be greatly appreciated.
I understand that this script might not be perfect, but I’m eager to learn and improve.
Hi UI,
a rule to block an IP boils down to a simple iptables command. Without any finesse maybe “iptables -I INPUT -p all -s insertnaughtyIPhere -j DROP”. You can rely on the iptables manpage for details.
If I understand correctly you would like to add your insight (bad IPs) to an “official” blocklist. If and how this can be done will certainly depend on their house rules.
I understand it is not there, but would it be better to get it working in IPF rather than develop something new? Fail2ban is a purpose built solution to monitor logs and to ban IP’s from the monitor. It may need a bit of shoe-horning to get the configs set up for IPF
Possibly. I have not investigated but from the screenshot, it only monitors SSH and webserver activity. F2b monitors all logs (and/or the journal on systemd systems)
Thanks for all the answers! I will take a look at the other solutions once I finish this project.
For now, I’ve developed a script that adds the blocked IPs to the /etc/sysconfig/firewall.local file like this:
#!/bin/sh
# Used for private firewall rules
# See how we were called.
case "$1" in
start)
iptables -I CUSTOMINPUT -p all -s 192.168.1.234 -j DROP
iptables -I CUSTOMINPUT -p all -s 100.120.120.120 -j DROP
iptables -I CUSTOMINPUT -p all -s 200.20.20.20 -j DROP
iptables -I CUSTOMINPUT -p all -s 21.22.23.24 -j DROP
iptables -I CUSTOMINPUT -p all -s 20.20.20.20 -j DROP
## add your 'start' rules here
;;
stop)
## add your 'stop' rules here
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac
After rebooting the ipf, the rules appear in the iptables -L output under the CUSTOMINPUT chain:
Chain CUSTOMINPUT (1 references)
target prot opt source destination
DROP all -- 20.20.20.20 anywhere
DROP all -- 21.22.23.24 anywhere
DROP all -- 200.20.20.20 anywhere
DROP all -- 100.120.120.120 anywhere
DROP all -- 192.168.1.234 anywhere
However, I’m still able to reach the network from the host 192.168.1.234:
A little annotation:
Fail2ban is suited to ban illegal login attempts.
Because it is ever a bad idea to allow logins to IPFire from outside ( red ), the tool isn’t an option. It should be located on the server. IMO
But the goal of @user-ip is different from this, I think.
Yes I was trying to create a warning to an admin account based on the logs created by SURICATA and block this ips.
But it’s great to learn about new tools.
That was the origin of F2B, but it developed massively since it started. Now it is a general purpose tool to ban IPs based on string matching in log files. They do not have to be login attempts. In my old server I use it to protect the webserver from repeat queries as well as unauthorised connections to OpenVPN (not a failed login explicitly but a particular type of response the server would never get from its expected clients). I also have a number of different postfix filters to block other illegalities (connections which are not logons).
Yes, F2B is much more than a logon filter.
But the main main mechanism is the automaton for a Chomsky-3-language ( aka regular expression ). This demands the unencrypted packet, which is present in the connection end point only, with increasing use of SSL based protocols.
Packets which shall be forwarded to internal devices leave log messages in IPFire, which are not really parseable for unwanted traffic, only.
Sorry, but that is not right. F2B does not care about SSL as it does not look at packets. It only looks at logs. As long as a log event is generated which can be identified in some way by regex and contains an IP address, F2B can process it. Suricata logs can be monitored, as can any other ones.
Please read the OP. The user wants to monitor the /var/log/suricata/fast.log and create an action from it. F2B can do that. It can even be configured just to mail a message without creating a firewall rule, if that is all you want, but it is more usual to use it to create a firewall rule.
