flood table is used to control the number of events, like contacting someone. event is the name of the event (for eg. contact) hostname is the hostname of the visitor and timestamp is the timestamp of the event. By sotring these in the flood it's easy to count how many users your hostname contacted in the last hour. As all hostname based mechanisms, this is flawed as well, but binding to a session would be even more trouble -- too easy to circumvent.
Drupal 7 prevents brute force attacks on accounts. It does so by refusing login attempts when more than 5 attempts failed. The amount of failed logins is recorded in the table 'flood'. You can either wait before trying to login again or clean the flood table with the procedure below.
If you forgot your password, generate a new password and update the database.
Execute the following query on the Drupal database:
DELETE FROM `flood`;
To execute this query it will be necessary to login to the database. This is typically done through the command line or through a GUI interface such as phpMyAdmin. If Drush is installed on your server, the drush sql-cli command provides quick access to an SQL command-line interface.
You'll notice that while your site is getting attacked, MySQL writes a record to the flood table on every login attempt, even after a user (or in my case a bot) has been locked out. Depending on how fast your bot is, this can still bring your site to it's knees, and will flood your flood table with useless records. beware.
If this happens to you, block the offending IP address, and hope your bot's not smart enough to get a new one.
Writing to the database on every hit makes you vulnerable to attacks of this sort, but if you're being hit that hard, then trying to address the problem within drupal can't work as well as a system level measure.
If you have root access to your server, look at using something like fail2ban to automatically manage firewall rules.
I haven't looked cloasely at the D7 implementation, but if it really is writing to db for every bad hit, then that's not good. Some improvement could be had by only writing a new record if the last one written is more than X seconds old. Not so many writes, but still involves select queries. More could be achieved by storing this info in memcached rather than the database, so you don't cause any disk IO.
DELETE FROM `flood`;
you can use this code in phpmyadmin sql file run this code and you can login you site.this query use for prevent Brute Force Attack
This is not a magic "code" that would prevent brute force attacks. If any, it's the opposite of it, because it clears the flood table where all "flood" attempts are recorded so you're just resetting the timer for an attacker.
Comments
http://drupaler.ru/table/drup
http://drupaler.ru/table/drupal/flood/6
Purpose of flood table
Taken from this comment by chx: http://drupal.org/node/164983#comment-589458
Charles
Drupal development, Cape Town, South Africa
Tip for clearing flood table & restoring access
via http://drupal.org/node/1023440:
Drupal 7 prevents brute force attacks on accounts. It does so by refusing login attempts when more than 5 attempts failed. The amount of failed logins is recorded in the table 'flood'. You can either wait before trying to login again or clean the flood table with the procedure below.
If you forgot your password, generate a new password and update the database.
Execute the following query on the Drupal database:
DELETE FROM `flood`;To execute this query it will be necessary to login to the database. This is typically done through the command line or through a GUI interface such as phpMyAdmin. If Drush is installed on your server, the drush sql-cli command provides quick access to an SQL command-line interface.
From the command line, with Drush installed:
drush php-eval 'db_query("DELETE FROM `flood`");'Drupal 7 DOES NOT prevent brute force attacks on MySQL
You'll notice that while your site is getting attacked, MySQL writes a record to the flood table on every login attempt, even after a user (or in my case a bot) has been locked out. Depending on how fast your bot is, this can still bring your site to it's knees, and will flood your flood table with useless records. beware.
If this happens to you, block the offending IP address, and hope your bot's not smart enough to get a new one.
use fail2ban
Writing to the database on every hit makes you vulnerable to attacks of this sort, but if you're being hit that hard, then trying to address the problem within drupal can't work as well as a system level measure.
If you have root access to your server, look at using something like fail2ban to automatically manage firewall rules.
I haven't looked cloasely at the D7 implementation, but if it really is writing to db for every bad hit, then that's not good. Some improvement could be had by only writing a new record if the last one written is more than X seconds old. Not so many writes, but still involves select queries. More could be achieved by storing this info in memcached rather than the database, so you don't cause any disk IO.
prevent brute Force Attack
DELETE FROM `flood`;
you can use this code in phpmyadmin sql file run this code and you can login you site.this query use for prevent Brute Force Attack
Best regards,
Omprakash Mankar
Senior Drupal Developer
Wrong
This is not a magic "code" that would prevent brute force attacks. If any, it's the opposite of it, because it clears the flood table where all "flood" attempts are recorded so you're just resetting the timer for an attacker.
Use it only if you know what you're doing.