Failed Count can be > Maximum Failed Count about anti_brute_force HOT 7 CLOSED

We talked about adding delegate, but now i am not sure it will be a good thing. This extension should block, or at least slow down, attackers. Using delegate for each page load, even if user is valid and logged-in is not that good idea.
It would be better to have delegate called whenever someone tries to log-in to Symphony. That would allow your extension to deny access if IP is blocked, and would pave way for other extensions, e.g., authenticating user through external service, blocking user if not logged-in for extended period of time, etc...

I was also trying to find a way for a "quick hack", so your extension could use it in meantime (while Symphony developers can decide if new delegate is OK or not), but there's nothing i can see there except for injecting code into one of the core files, or replacing one of them completely :(.
You could try to make temporary changes to tbl_authors, to prevent author from ever logging-in, but that would deny access to valid/real user too.

from anti_brute_force.

One more thing: for now you could logout "banned" author every time. It would still not prevent him/her from posting data to specific pages, once he/she guessed password, but it could at least slow them down a bit (not that much really, but they would have to know more about Symphony, to keep trying :).

Or, you could add some rules to .htaccess (read about rewrite_map). But that would work only on Apache servers.

Another thing: Banning by IP number may prevent single attackers, but it will not help prevent brute force attacks from botnets or anyone who can change their IP numbers quickly. So maybe there could be an option to block account when extension notices access from too many IP numbers in a short period of time?

from anti_brute_force.

Check out post by brendo. InitaliseAdminPageHead delegate is called before pages handle $_POST actions. It is after logging-in, but if your extension can throw exception before actions are handled, it should be OK (especially if it will also logout banned IP :).

from anti_brute_force.

@ahwayakchih: Did not knew I would get a personal novel from you :) Thanks for all of this information. These are my responses, since they are not answers :)

1- I thought of the extra load delegates generates. But something like PreUserAuth (only fired on the login page) would even be BETTER.

2- I search a "quick hack" me too... guess what, I had to modify the core, which is a no go for me. I will auto-logout any blocked user... sorry _IP_.. this way, the cookie won't be send, and they will never know if the guessed it right.

3- auto log out -> brilliant, thanks !

4- I also though about multiple IP's issue, but since HTTP is _Stateless_ I cannot base a simple SQL clause with anything else then the IP. Simple attacks (wannabes) controls everything else except IP... For botnets protection, I would recommend a IDS (Intrusion Detection System). The only thing I can think if is maybe ban a subnet... but this is risky...

5- Too many tries in short time: Ok but what the system do ? Block everybody ? Try to find a pattern that matches a subnet ? What if you have a record in the DB that is not related to the specific botnet and that f*cks the search pattern out ? This seems like a lot of work to do!!!

6- InitaliseAdminPageHead is called before PreGen ? Wow, method names can lead to false conclusion, I cannot remind it to me more often !! I will check this out for sure !

from anti_brute_force.

But something like PreUserAuth (only fired on the login page) would even be BETTER.

Try to suggest that to Symphony developers, maybe they will include such delegate :).

this way, the cookie won't be send, and they will never know if the guessed it right.

You're, right. I did not even think about that - i was focused more on the Symphony side of things. I keep forgetting that cookie will not be send as soon as it is set ;). And since Symphony uses sessions, authorization will be there, and will be cleared, which is really good in this case.

For botnets protection, I would recommend a IDS (Intrusion Detection System)

Right. That's probably too much for this extension target purpose.

The only thing I can think if is maybe ban a subnet... but this is risky...

Yeah, that may ban valid users. And will not work on botnets anyway.

Too many tries in short time: Ok but what the system do?

Maybe block account for everyone except first logged user? I mean, if there is user logged in, and someone else tries to break in, we should be able to recognize which user logged in earlier, without repeated failures. Extenstion could use both "whitelists" and "blacklists". If IP (or SessionID?) is on the whitelist, it is not "banned", otherwise extension throws error.

Wow, method names can lead to false conclusion,

Haha, it is by accident. We're just lucky it is called before $_POST actions are handled. If you logout user at InitaliseAdminPageHead and throw message about being banned, actions will not be handled, and everything should be safe then.

from anti_brute_force.

Super ! I will update the extension following our charming discussion ! But do not expect a Black/Whitelist feature for tomorrow!

• I will use the InitaliseAdminPageHead delegate as well as the original one, just in case InitaliseAdminPageHead is not fired on ALL pages (Are they ?)
• Auto log out banned ips
• No solutions where "only compatible with Apache" ... this s*cks for other servers !
• I thought about SessionID but they are not reliable. i.e. server restarts after overflow of data...
• Add Black/Whitel/Grey-list feature which should be AWESOME to have and facilitate management.
  Blacklist -> Banned forever, overrides all others tables, NO EMAIL UN BAN POSSIBLE
  Whitelist -> Never gets banned
  Greylist -> Banned users by ip will go automatically into greylist for _x_ days/months. If IP is greylisted more than _y_ times in _x_ month/days -> BLACKLIST THEM... for ever... or until admin wants too.
  As for botnets, I feared they could full the DB, hence the update of the failedcount instead of a new insert to log each failed attemps. As for the "colored"-listed, they should only limited to 1 record per IP.

I can now conclude that a botnet would have (maxFailedAttemps * nb-of-IP-they-have * maxGreyListCount) attempts to guess the password... I think this is the closest we can get to build a free open-source "ISD" for symphony

I hope the community will like it and that my time and efforts will help other as other helped me.

from anti_brute_force.

All featured discussed here are implemented in the dev branch as of today except the colored list which will be featured in the 1.2 version

from anti_brute_force.