Sign up ×

This is along a similar line to other posts on brute-force attacks, but a bit more specific:

We are able to enforce decent passwords, generally, and user name policy also avoids falling prey to what 99.9% of the brute-force FTP stuff is trying... but I see no reason to allow thousands of attempts endlessly, and they can sometimes make fill the log files with lots of noise that makes it harder to find potentially more targeted things.

So, for passive FTP, would some sane rate-limiting in iptables for incoming TCP 21 be reasonably effective at cutting off the massive numbers of failed attempts while not ever getting in the way of normal use? I presume that this would be done via rate-limiting connections from the same IP to TCP 21.. is that correct? Are there problems I'm not thinking of there?

Next, then; what would you suggest for a simple iptables command on a bastion firewall/router to just put in some protection against the hardest/fastest hitting brute-force attacks? My thinking would be something along the lines of a trigger of 25 connections (on the principle that a successful login would be only a single connection to TCP 21) within a minute or so, and then a block for a half hour. Do those numbers seem reasonable?

(other info: this is for a debian firewall/router which protects a DMZ of mixed OSs)

share|improve this question
Key points to note in my question above: bastion firewall (not host-based) mixed OSs in the DMZ (mostly Windows, so answers like fail2ban aren't terribly relevant) and iptables rate-limiting ; I'm asking if this will work; if not, why not and if so, how. –  Andrew Barber Nov 10 '10 at 22:24

3 Answers 3

up vote 3 down vote accepted
iptables -A INPUT -p tcp -m state --state NEW --dport 21 -m recent --name ftpattack --set
iptables -A INPUT -p tcp --dport 21 -m state --state NEW -m recent --name ftpattack --rcheck --seconds 60 --hitcount 4 -j LOG --log-prefix 'FTP REJECT: '
iptables -A INPUT -p tcp --dport 21 -m state --state NEW -m recent --name ftpattack --rcheck --seconds 60 --hitcount 4 -j REJECT --reject-with tcp-reset

these rules near or at the top of your ruleset will allow only three connections to port 21, from any given IP address, in a rolling 60-second window. To allow n, use --hitcount n+1; to use a bigger window than 60 seconds, increase --seconds 60.

share|improve this answer
Almost right. I think you'll want to put these rules on the FORWARD chain, rather than the INPUT chain, since the FTP server is not the same as the router. +1 anyway. :D –  Steven Monday Nov 10 '10 at 22:25
Right; for my specific use it would be on the FORWARD chain instead. +1 –  Andrew Barber Nov 10 '10 at 22:28
Sorry, you're right; I'd failed to pick up on the distinction between the two boxes. That said, I might be inclined to put this code on the FTP server itself anyway; there's nothing written in stone that says there can be one and only one firewall. I often put application-specific iptables on the application boxes, to avoid lunatic complexity in my main firewall ruleset. –  MadHatter Nov 11 '10 at 6:27

As MadHatter had mentioned, the recent module is what you want to use however you also need to be able to limit the number of login attempts a user is able to try in a single TCP connection. If the user can try 1000 attempts before they are forced to disconnect and reconnect then limiting connections via the recent module is pretty fruitless. You would need to say (through configuration of the FTP daemon - see the docs for that) that the user is only allowed to try to login say 5 times per each connection and then use a recent rule to say if they connect more then say 5 times within a minute then block them. Yes allowing 25 attempts does sound high but not nearly enough for brute force and help avoid a lot of false positives. I use rules similar to this with SSH and the OpenSSH server option MaxAuthTries. Hope this helps.

share|improve this answer
Does help, yes; That's basically what I ended up doing. I forget how many I limited it to (20-ish), but that's the idea I used. +1 –  Andrew Barber Dec 28 '11 at 19:06

Use Denyhosts... 3 strikes- your out!

It works like a charm..

Or.. more hardcore.. a dedicated firewall with Snort/IDS

Hope this helps

share|improve this answer
My impression is that denyhosts is specific to ssh. I would recommend fail2ban. I agree that something of this sort is the right approach, however. Trying to throttle an application-level action (logins) through policy imposed at the transport layer (iptables) strikes me as a kludge. –  dfranke Nov 10 '10 at 21:58
@Arenstar : It's not really answering my question, so no, it doesn't help. I have in place policies and tools on the servers (some of which are Windows) that have been keeping the attacks out for the 10+ years they've been happening, but I'm just exploring this as another route. Snort on the (already dedicated) firewall could be a potential, functional alternative, but it's still not answering my question. –  Andrew Barber Nov 10 '10 at 22:06
@dfranke : It absolutely is a kludge, which is why I'm uneasy enough about it that I've never tried to do it. But if it turns out it's a kludge that ends up keeping some noise out of the logs and reducing the (admittedly smallish) bandwidth that the attempts are using, all for a couple lines added to my iptables script and no measurable effect on my users... I'd be happy to throw it in. –  Andrew Barber Nov 10 '10 at 22:10
Dfranke is right.. fail2ban was right.. However, your 10 years experience clearly dont understand how im answering your questions? i was politely telling you that your being overly complicated for a simple problem.. and something like pfSense.. will certainly answer all your questions, plus all the ones you didnt learn about in 10 years :D –  Arenstar Nov 10 '10 at 22:11
Are we still talking about this-and your 10 years of "security"?? hehehe If you dont like someones answer then move on :D I dont want to be reminded of your overcomplicated IT work in my inbox.. Furthermore, i cant see where you wrote the FTP server is not the place your attempting to stop these connections.. –  Arenstar Nov 10 '10 at 22:29

Your Answer


