option for Anti-hammering IP-whitelist

[Bubbi]

First off, thank you for developing the fantastic FileZilla server and client! I don't know where I would be without it. (probably still here, but using a lesser FTP server/client)

Deep within FileZilla server, there is an effective anti-hammering feature. Maybe a bit too effective..
I was wondering if it could be renewed a bit, by giving the server admin a few options when setting up the server?

At work we have setup FileZilla server and use it on a daily basis as the main transportation of files through our network. Multiple times a day, we encounter the anti-hammering / anti-spamming feature in FileZilla when downloading and uploading files and we are getting increasingly annoyed by it.

Even if I am the only one connecting to the FileZilla server, saving and loading 2-5 files a minute with Visual Studio 2010 activates the anti-hammering.
This is a bit too effective for my taste. Even if we use FileZilla client to connect to the server, it only allows sending 5-10 text-files and then it stops for 10 seconds, whereafter it logs in again and sends another 5-10 files and so forth.


Wouldn't it be an idea to let the server-admin setup the server to whitelist certain IP addresses or IP ranges, that would never get hit by the anti-hammering feature?
Anti-hammering should never be turned completely off, just for the whitelisted IP addresses.

I'm sure that you (users and developers) could come up with a few more nifty options when setting the server up?

If you have any thoughts for or against a change like this, please spend a few minutes on a reply. I'm sure that we all want to make FileZilla better in the end

[boco]

Hmm, anti-hammering should only be activated upon failed logins, and not touch successful ones. So does your client produce failed logins?

[botg]

Even if I am the only one connecting to the FileZilla server, saving and loading 2-5 files a minute with Visual Studio 2010 activates the anti-hammering.

Since when is Visual Studio an FTP client?

[Bubbi]

boco: That is very interesting. We successfully connect every time, as far as we know, but I will return later with a little info from the log.

botg: Well, Visual Studio is not a FTP client by itself, as it is an IDE, but it contains a method to connect to an FTP server (http://kb.discountasp.net/KB/a788/how-d ... oject.aspx).
I have read something about the 2010 version was the first version, where Microsoft developed the FTP client by themselves. Previously a 3rd party plugin was used, but I cannot confirm that by myself.

Also I have read a post from boco (http://forum.filezilla-project.org/view ... =6&t=22233), where he describes that Internet Explorer will first try with an anonymous account, even if the user specifies login-info. Maybe Visual Studio 2010 also does the same thing (shitty programmers == shitty programming)?
We have no anonymous account on the server, so this could be the problem, but I will return with more info later.

[Bubbi]

My god.. Visual Studio does exactly the same as Internet Explorer, as boco had described
It actually creates 2 connections to the FTP server. one with the login specified and one as anonymous that doesn't do anything.. It just connects!
This was quite a problem, while we had no account for "anonymous". It activated the anti-hammering feature and also blocked all other FTP accounts from the same IP address..

After we created an anonymous account, we could see that by downloading and uploading 3 files within a minute with Visual Studio, it had used 4 connections. 1 was the actual account and 3 were anonymous.. :S
I guess Microsoft really have some shitty programmers


The anonymous connections were timed out within a minute, but I can easily see 20-40 connections being created when several persons are uploading/downloading from the server. Of course, that shouldn't be a problem for FileZilla, but damn.. that's just wrong..

Bottom line: The solution was to create an anonymous account linking to an empty folder.

boco, thanks for throwing out a couple of clues
Now, if only we could reward Microsoft for such shitty coding..

[botg]

Now, if only we could reward Microsoft for such shitty coding..

You already did by buying Windows and Visual Studio.

[boco]

I think he/she forgot the sarcasm tags, botg...

[Bubbi]

Sorry, but yeah.. [sarcasm] was definitely on

[indexfz]

Like the first poster, I find Filezilla the best FTP client out there, so thank you for that. Though I really do hope devs find a more elegant solution to this "log-in mishap"

[nurmichl]

Hi @all
Filezilla is IMHO the best solution as ftp-Server for windows machines.

We also had some problems with connections from Chrome-ftp-clients. When we use this browser as client, we have slow connections after 10 logins (also on successful logins)

In filezilla's logfile I can see login attempts of the user "anonymous" prior each log in of a regular user.
Other clients (firefox, ie) log in immediately with the correct user.


My idea was to clear the antiHammer-counter of the specified client-ip-address after a successful login-attempt.

Therefore i modified the code and compiled the project.
Here's the patch. I hope this helps some one.

Code: Select all

Index: ControlSocket.cpp
===================================================================
--- ControlSocket.cpp	(revision 4625)
+++ ControlSocket.cpp	(working copy)
@@ -3230,6 +3230,8 @@
 
 	m_pOwner->SendNotification(FSM_CONNECTIONDATA, (LPARAM)op);
 
+	m_pOwner->AntiHammerClear(m_RemoteIP);
+
 	return TRUE;
 }
 
Index: ServerThread.cpp
===================================================================
--- ServerThread.cpp	(revision 4625)
+++ ServerThread.cpp	(working copy)
@@ -947,6 +947,17 @@
 	LeaveCritSection(m_GlobalThreadsync);
 }
 
+void CServerThread::AntiHammerClear(const CStdString& ip)
+{
+	EnterCritSection(m_GlobalThreadsync);
+
+	std::map<CStdString, int>::iterator iter = m_antiHammerInfo.find(ip);
+	if (iter != m_antiHammerInfo.end())
+		m_antiHammerInfo.erase(iter);
+
+	LeaveCritSection(m_GlobalThreadsync);
+}
+
 CHashThread& CServerThread::GetHashThread()
 {
 	return *m_hashThread;
Index: ServerThread.h
===================================================================
--- ServerThread.h	(revision 4625)
+++ ServerThread.h	(working copy)
@@ -79,6 +79,7 @@
 	void GetNotifications(std::list<CServerThread::t_Notification>& list);
 
 	void AntiHammerIncrease(const CStdString& ip);
+	void AntiHammerClear(const CStdString& ip);
 	
 	CHashThread& GetHashThread();

Have a nice day

[boco]

@botg: How is the current behavior? Does the delay ''wear off'' over time? In my opinion both possible behaviors (wearing off vs. reset on successful login) have valid reasons to exist, so I think it should be configurable (in the config only).

[botg]

Yes, the delay isn't permanent. After some time it resets again.