More options for Autoban

[venomhed]

Hello,

I am sure I will get flamed and bashed for requesting this, but I would love to see more options for the Autoban feature. Such as a list of who has been banned, when, why, and then the option to click on one or many and unban the offending IP/User.

Reason is, when I look at my logs, I am getting a ton of dimwits trying to snack into my FTP site. I have some solid passwords, but still, what if someone "sniffed" out my password?

I am looking into the SSL options but am a noob at this.

Thanks for any suggestions in advance.

[botg]

Autoban will be removed in a future version, I made a big mistake implementing it in the first place.

[venomhed]

I know you are busy, but is there a reason to remove Autoban? It seems handy even though now I am using SSL etc and some nice passwords. It seems handy for those fools that hammer my site now and again.

[boco]

Filezilla Server already has a method to stop these 'people'. After some consecutive logins it introduces an artificial delay, which is raised with every further attempt. Soon, it becomes too annoying for the intruder, and he stops. But it never stops a regular visitor with the same IP to enter the server (with some delay).

Autoban, on the other side, has a serious flaw: Think of public proxies, universities or routers. Lots of people with the same IP. Say one of 1000 people tries to crack your server and gets his ass banned. Now the remainig 999 people are no more able to visit your server. All banned. With VPNs it's even worse.


My recommendation: Use strong, unguessable passwords, disable Autoban and let 'em bite concrete! If YOU made no configuration error they'll never get in.

[spec1alk]

With FTP "crackers" being scripted, I don't see how the time delay really makes a difference. All the guy has to do is let the thing run for several hours/days/weeks. He doesn't care because its scripted and maybe once a month it is able to crack some poor saps site.

Maybe it needs to be explained to me a little further.

[botg]

With a secure password, it's impossible for him to crack the password before every single atom in this universe has decayed.

[boco]

To crack a password within a reasonable time, the attacker has to make sure his crack attempts are fast. But as the logins to Filezilla Server become slower and slower, it soon makes no sense anymore. A password can be cracked in some weeks, sure, but only if you can check fast. With only one attempt in a minute the efforts are by far greater than the gain. So he stops.

[venomhed]

Interesting and thanks for taking the time to clarify the autoban feature. i wasn't aware of the delay, but that makes better sense.

Still, aren't non ssl/tls passwords sent in clear text? Is that an easy way for someone to grab your user name and pass? Or maybe you were implying that a proper FTP server would have ssl/tls enabled since it is rather easy to implement.

Thanks!

[boco]

Filezilla Server has support for SSL/TLS, you just have to switch it on. Most people prefer using browsers as FTP clients, so it is disabled by default (browsers don't support FTPS).

But that is a different story. No delay and no Autoban feature protect you against sniffers and man-in-the-middle attacks. But FTPS should.

[dayron]

I don't usually beg...but I'm begging now. Please don't remove autoban. It's one of the main features that led me recently to start using FileZilla over the pay-to-play products. Even at it's current level of functionality IP autoban works perfect for how I use it and I'm sure many others. There are other options in FileZilla that seem to be "use at your own risk" like the Strict IP filter options, in misc. options there is the checkbox with the warning of "this could result in corrupt file transfers", and if GSS is enabled and you have the wrong version of Windows for Kerberos we're warned clearly that it could crash Filezilla.

So I'm beggin ya please... just warn folks of the issues by the checkbox they have to check... but leave the feature. It's changed my FTP serverlife And BTW FileZilla is a fantastic product both client and server. Thank you for all the work!

Autoban will be removed in a future version, I made a big mistake implementing it in the first place.

[botg]

Autoban just creates a false sense of security.

[da chicken]

I agree that tar pitting is far more effective at stopping cracking (and DoS).

IMO, there are two issues here:
1. Do not use obvious FTP usernames for accounts with permissions you don't want people to have. An unknown username is just as secure as an unknown password. IIS's FTP is often attacked because it automatically grants the local Administrator account access, so attackers try and hit that. On such systems, you have to rename the Administrator account in order to protect the system, or use something other than IIS FTPd.
2. Do not use simple passwords. If you want it to be secure, use a secure password.

If you're not running a public FTP server:
1. Don't use the default port. Yes, it's just an obscurity measure, but it still requires the attacker to have knowledge of your systems which they probably do not have.
2. Use allow/deny hosts.
3. Use SFTP. FTP is inherently insecure, so complaining to make your FTP server software more secure is always a bit silly. FTPS is not much better. If you really, really need it, try SFTP with certificate-based or key-based authentication (I'd love it if FileZilla could do this, but it's probably quite complex for a cross-platform system).
4. If possible, use a different instance of your ftp server on a different port (or on a different server) for accounts with higher-than-guest privileges. I highly recommend using allow/deny hosts with this. Let them hammer all they want. The tar pit will prevent loss of service, and they'll be grinding at a blank wall anyways.

[dayron]

I'm not arguing against tarpitting and I agree the use of autoban in place of strong user names and passwords would be a false sense of security.

I have a very active FTP server (as we have users in most every time zone in the world and all with their own public IP address...no proxies to worry about), and my concern is some of the brute-force attacks I experince may last for hours. I'm guessing not all of these brute-force attack methods are "smart" enough to know when they are being "tarpitted" so they will just pound away for hours even if delayed. Yes that prevents DoS and greatly reduces the results the attacker may expect, but in the meantime does that effect my legit user's connection times? Is tarpitting IP based or will all connections to the FTP server be effected whilst attackers fruitlessly pound away on my FTP server delaying my legit users?

I agree that tar pitting is far more effective at stopping cracking (and DoS).

IMO, there are two issues here:
1. Do not use obvious FTP usernames for accounts with permissions you don't want people to have. An unknown username is just as secure as an unknown password. IIS's FTP is often attacked because it automatically grants the local Administrator account access, so attackers try and hit that. On such systems, you have to rename the Administrator account in order to protect the system, or use something other than IIS FTPd.
2. Do not use simple passwords. If you want it to be secure, use a secure password.

If you're not running a public FTP server:
1. Don't use the default port. Yes, it's just an obscurity measure, but it still requires the attacker to have knowledge of your systems which they probably do not have.
2. Use allow/deny hosts.
3. Use SFTP. FTP is inherently insecure, so complaining to make your FTP server software more secure is always a bit silly. FTPS is not much better. If you really, really need it, try SFTP with certificate-based or key-based authentication (I'd love it if FileZilla could do this, but it's probably quite complex for a cross-platform system).
4. If possible, use a different instance of your ftp server on a different port (or on a different server) for accounts with higher-than-guest privileges. I highly recommend using allow/deny hosts with this. Let them hammer all they want. The tar pit will prevent loss of service, and they'll be grinding at a blank wall anyways.

[dayron]

Revisiting the posts below will tarpitting a brute-force attack that lasts for hours hinder the legit users that are attempting to log on during the attack if IP autoban isn't in use? If so how long will legit users have to wait?

I'm not arguing against tarpitting and I agree the use of autoban in place of strong user names and passwords would be a false sense of security.

I have a very active FTP server (as we have users in most every time zone in the world and all with their own public IP address...no proxies to worry about), and my concern is some of the brute-force attacks I experince may last for hours. I'm guessing not all of these brute-force attack methods are "smart" enough to know when they are being "tarpitted" so they will just pound away for hours even if delayed. Yes that prevents DoS and greatly reduces the results the attacker may expect, but in the meantime does that effect my legit user's connection times? Is tarpitting IP based or will all connections to the FTP server be effected whilst attackers fruitlessly pound away on my FTP server delaying my legit users?

I agree that tar pitting is far more effective at stopping cracking (and DoS).

IMO, there are two issues here:
1. Do not use obvious FTP usernames for accounts with permissions you don't want people to have. An unknown username is just as secure as an unknown password. IIS's FTP is often attacked because it automatically grants the local Administrator account access, so attackers try and hit that. On such systems, you have to rename the Administrator account in order to protect the system, or use something other than IIS FTPd.
2. Do not use simple passwords. If you want it to be secure, use a secure password.

If you're not running a public FTP server:
1. Don't use the default port. Yes, it's just an obscurity measure, but it still requires the attacker to have knowledge of your systems which they probably do not have.
2. Use allow/deny hosts.
3. Use SFTP. FTP is inherently insecure, so complaining to make your FTP server software more secure is always a bit silly. FTPS is not much better. If you really, really need it, try SFTP with certificate-based or key-based authentication (I'd love it if FileZilla could do this, but it's probably quite complex for a cross-platform system).
4. If possible, use a different instance of your ftp server on a different port (or on a different server) for accounts with higher-than-guest privileges. I highly recommend using allow/deny hosts with this. Let them hammer all they want. The tar pit will prevent loss of service, and they'll be grinding at a blank wall anyways.

[boco]

Tarpit/Honeypot

Tarpitting will hold the attacker's connection open and delaying it as long as possible. As attacks normally originate from only one IP, it should not have an influence on other users (unless you set ridiculously small limit concerning concurrent connections).

http://en.wikipedia.org/wiki/Tarpit_(networking)