Я определенно рекомендовал бы использовать что-то как Fail2ban или DenyHosts, чтобы сделать это. Это точно, для чего они сделаны, и как Zoredache говорит, я не могу вообразить, почему у Вас была бы проблема с использованием сторонней программы.
Однако Вы могли использовать recent
модуль для IPtables, который существует в более новых версиях программного обеспечения. (Я не уверен, как новый точно, но если Вы были в курсе, я думаю, что у Вас должен быть он.) Не столь легко настроить или также показанный как сторонние программы, но это - возможность. Ряд правил как это:
iptables -A INPUT -m recent --name nobruteforce --rcheck -j DROP
iptables -A INPUT -m recent --name nobruteforce --set -j DROP
добавят все пакеты, которые соответствуют
к черному списку, и заблокирует дальнейшие пакеты, прибывающие из того же исходного IP-адреса. Вы заменили бы
с любыми опциями IPtables Вы обычно используете для идентификации атак перебором; например, это могло бы быть что-то как
iptables -A INPUT -m recent -p tcp --dport 22 --name nobruteforce --set -j DROP
хотя действительно отмечают, что каждый пакет, который прибывает для портирования 22 (который не соответствовал более раннему правилу) инициировал бы это. Будьте осторожны с recent
модуль, потому что это могло серьезно испортить вещи, если Ваши правила когда-нибудь производят положительную ложь. Если бы необходимо использовать его, для ограничения последствий, я предложил бы добавить ограничение по времени и/или минимальное требование хита к второму правилу:
iptables -A INPUT -m recent --name nobruteforce --rcheck --seconds 7200 --hitcount 5 -j DROP
Это заблокировало бы пакеты только после того, как 5 пакетов "в лоб" будут получены, и в конце 2 часов (7 200 секунд) это удалит исходный адрес из черного списка.
Больше информации о ipt_recent
доступно по http://snowman.net/projects/ipt_recent/
Нет, хешированный пароль bcrypt с разумным рабочим фактором сам по себе должен быть достаточно безопасным.
Должен не согласиться с предыдущим ответом: это действительно имеет смысл, но не полностью.
Шифрование AES здесь добавит дополнительный уровень к безопасности паролей, основанный на информации, которая не сохраняется в базе данных (я предполагаю, что вы не поместите ключ AES в ту же базу данных с паролями). Существует несколько сценариев, в которых база паролей может быть взломана без доступа к конфигурации приложения. (SQL-инъекции, база данных на другом сервере, доступ к резервным копиям базы данных и т. Д.)
Даже при использовании специфической для пользователя соли bcrypt слабые пароли по-прежнему относительно легко взломать. И в любой базе паролей будет много ненадежных паролей.
То, что не имеет смысла: почему симметричное шифрование, когда вы просто могли добавить секретный ключ к паролю перед запуском BCrypt? Таким образом, такой же уровень безопасности получают:
$hash = $bcrypt->hash('some-password-here' . 'crypto_key');
Подробнее: http://blog.mozilla.org/webappsec/2011/05/10/sha-512-w-per-user-salts-is -not-достаточно /