Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
2  
Why you do not use fail2ban? –  int Apr 8 '13 at 7:35
    
because it does not work. –  Digital Robot Apr 8 '13 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. –  int Apr 8 '13 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 –  Rahul Patil Apr 8 '13 at 7:52
    
@int what command should I type to check that and if the problem is this, how do I fix that? –  Digital Robot Apr 8 '13 at 8:00

1 Answer 1

up vote 3 down vote accepted

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.

share|improve this answer
    
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? –  Digital Robot Apr 8 '13 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. –  Michael Kjörling Apr 8 '13 at 8:21
    
thanks I will check that. –  Digital Robot Apr 8 '13 at 8:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.