2

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)

Andrew Barber
  • 1,089
  • 12
  • 23
  • 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 Answers3

5
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.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • 2
    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 06:27
  • Rate limiting should be in the box with the server because that provides some protection even in case your firewall/router ever gets hacked. Putting extra firewall on another box only makes sense if you cannot directly protect the box with the valuables. – Mikko Rantalainen Jan 23 '18 at 06:42
1

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.

user39668
  • 140
  • 5
  • 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
0

Use Denyhosts... 3 strikes- your out!

It works like a charm..

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

Hope this helps

Arenstar
  • 3,592
  • 2
  • 24
  • 34
  • 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
  • 1
    @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
  • No. fail2ban is *not* right. It is actually wrong; it won't work at all. Reading my question more thoroughly would give away why that is: I'm not running FTP on the server with iptables. Two seconds of reading (much less than 10 years) would have shown that. – Andrew Barber Nov 10 '10 at 22:19
  • 1
    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
  • 1
    The three lines of iptables required is hardly "overcomplicated". BTW, ever heard of "defense in depth"? Or, are you one of those guys who thinks "Oh, if I install these whiz-bang tools, I'll be all sekure!!" As for not being able to see where I say my FTP server is not where I'm looking... what do you think I meant by "bastion firewall" or "this is for a debian firewall/router which protects a DMZ of mixed OSs"? – Andrew Barber Nov 11 '10 at 11:14