2

I have a script running every minute by a crontab.

This script scans the system logs and grabs the IPs of every failed attempt to login on the server's dovecot, exim or ssh and add them to an ipset, blocking that IP forever.

The problem is this: the script runs every minute and is doing well what it is supposed to do, that is, grab the IP of attackers and add them to ipset, but I still have log entries of the same IP trying to attack the system for an hour.

In other words. Suppose someone tries to attack the system now. Within one minute the script will run and grab all IPs with more than 3 password failures and add them to an ipset. Even so, I have logs of IPs trying to brute force attack the site for hours and the connection is not interrupted.

My supposition is this: ipset works by adding an IP to a table and that IP will be blocked the next time that IP comes to the server but the connection will not drop if the IP is already connected to the server trying to attack. Is this right? If it is, is there a way to interrupt a connection going on?

NOTE: Just for the record: the commands I have used to add the ipset named blocking to iptables was like this: 

iptables -A INPUT -p tcp --dport XX -m set --set blocking src -j DROP

where XX is the port I am blocking.

Improve this question
9
  • 2
    Why you do not use fail2ban? Commented Apr 8, 2013 at 7:35
  • because it does not work. Commented Apr 8, 2013 at 7:35
  • I've tried this with netcat, and it blocks well, even when client is connected. My guess is that there is block only for NEW connections in iptables rules (--syn flag in iptables cmd). Check this. Commented Apr 8, 2013 at 7:44
  • Note:- Netfilter work TOP-Bottom manner, so just make sure your rule for blocking particulate should be in top of other ip's Commented Apr 8, 2013 at 7:52
  • @int what command should I type to check that and if the problem is this, how do I fix that? Commented Apr 8, 2013 at 8:00

1 Answer 1

Reset to default
3

iptables -A adds to the end of the chain (note that the long form of -A is --append). You probably have a rule similar to iptables -A INPUT -p tcp --dport XX -j ACCEPT near the top, which is interfering because it is being matched first when the rules are executed top to bottom.

There are two obvious ways to work around this:

  • Use a separate blocking chain, which gets called before the service's accept rule. This is the approach I'd use, since if the jump to the block chain is properly conditioned, all those rules won't be tested if there is no need to. You'd need to work out which block chain to add to. Another upside is that if you need to, doing iptables -F smtp-blocks is much easier than manually finding and deleting each block to port 25. (The fact that you are using sets may alleviate this to some extent; I'm not too familiar with rule sets and what can be done with them.)

  • Replace iptables -A with iptables -I. Using -I inserts at the top (or before the specified index, if one is specified), ensuring that the blocking rule gets executed before the service accept rule.

My supposition is this: ipset works by adding an IP to a table and that IP will be blocked the next time that IP comes to the server but the connection will not drop if the IP is already connected to the server trying to attack. Is this right? If it is, is there a way to interrupt a connection going on?

It depends on the rule. If a TCP-protocol rule specifies that it should match only on SYN packets (--syn) then it will only match when the connection is being initiated; however, the default is to match on every packet. UDP has no concept of connection initiation, although you may be able to use connection tracking for similar purposes. That said, if you do not explicitly specify anything, if properly placed the newly added rule will match the next incoming packet, which will be handled according to the rule in question. If the rule says -j DROP, from the remote party's point of view that's about the same as if you just yanked the network cable.

Improve this answer
2
  • thanks. Just one final question. From times to times I check my iptables using --list flag and I see that the ipset is not there. Obviously iptables is losing the connection to ipset every time the server restarts. Is there a way to save this permanentely? Commented Apr 8, 2013 at 8:18
  • That's really a different question, but look at your iptables initialization scripts; it should be trivial to from there figure out how to store rules across reboots. (I don't see you specifying an environment, so anything more specific is anyone's guess.) That said, consider carefully the implications of doing so before you enable something like that. If your script goes awry in any way, or you mistype your own password, it becomes very easy to lock yourself out of the system. Without saving rules across reboots, as long as you can initiate a reboot somehow, you are fine. Commented Apr 8, 2013 at 8:21

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.