search

Solutions-Nitriques / anti_brute_force

Secure your Symphony CMS login page against brute force attacks
http://symphonyextensions.com/extensions/anti_brute_force/
Other
10 stars 12 forks source link

Failed Count can be > Maximum Failed Count #3

Closed nitriques closed 13 years ago

nitriques commented 13 years ago

The FailedLoginAttempt is fired BEFORE the AdminPagePreGenerate

Right now, if a blocked user continue to POST login data to the login page it's stils tries to auth the user, register a failed attemp (which reset the block duration), and then throws the exception.

How about fixing this? preventing Symphony to try to auth the user ?

Since this is a _open-source security_ piece of software, I feel I have to publish the issues I know about !

ahwayakchih commented 13 years ago

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.

ahwayakchih commented 13 years ago

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?

ahwayakchih commented 13 years ago

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 :).

nitriques commented 13 years ago

@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 !

ahwayakchih commented 13 years ago

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.

nitriques commented 13 years ago

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

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.

nitriques commented 13 years ago

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