Безопасность пароля минимума веб-сервера на основе 100 попыток в секунду
Предположение, что Вы используете DHCP для получения IP-адреса для VM и в зависимости от того, как сервер DHCP настраивается, можно отправить информацию об имени хоста на сервер DHCP. Если сервер DHCP был настроен для обновления записей DNS, машина может быть с готовностью определена этим именем хоста.
Существует a send host-name "<hostname>"; опция в /etc/dhcp3/dhclient.conf.
но большинство веб-приложений не было бы способно к обрабатыванию больше чем 100 запросов входа в систему в секунду.
То, что это означает: автор той статьи делает необоснованное (но не совсем неблагоразумный) утверждают, что отправка больше чем 100 входов в систему в секунду была бы эффективной атакой "отказ в обслуживании" против "большинства" веб-приложения.
Поскольку каждый регистрируется, типичное веб-приложение должно было бы хешировать пароль и сравнить его с хешированным представлением в базе данных. Если веб-приложение использует хорошую хеш-функцию, это действительно использует изрядное количество ЦП. Таким образом, требование, возможно, не совсем неблагоразумно, но по моему опыту большинство веб-приложений просто использует простой хеш как MD5, SHA1 или SHA256, который не является интенсивным ЦП.
Большая ошибка в той статье прибывает сюда:
Примечание: Примеры ниже основаны на 100 запросах пароля в секунду.
В следующих абзацах автор делает предложения для надежности пароля, на основе максимального процента заболеваемости 100 попыток в секунду. Это может быть разумным числом для нападения онлайн, где взломщик соединяется с живым веб-приложением.
Но для на офлайновом нападении, где взломщик сначала загрузил всю базу данных через fx атака с использованием кода на SQL, это совершенно неправильно. Например, вот реализация CUDA NVIDIA для SHA1, который может сделать 47 миллионов хешей в секунду на небольшом кластере сервера.
веб-приложения только должны смочь защитить от 100 попыток в секунду?
Извините, но не, Вы неправильно понимаете эту часть. Теперь Вы смотрите на него с точки зрения владельца веб-приложения, пытающегося защищать от нападения подбора пароля "в лоб" онлайн. Необходимо принять меры задолго до того, как это прибывает в это.
- Если отдельные учетные записи имеют определенное число неудавшихся, входят в систему попытки (3,5,10,25, могут все быть разумные числа), затем, учетная запись должна быть временно недоступной. (Или еще лучше, не отключайте учетную запись, но замедляйте попытки входа в систему, иначе tarpitting / ограничение уровня.)
- Если Вы получаете сотни неудавшихся попыток входа в систему в секунду в масштабе всей системы, то Ваш вход / контролирующая платформа (Nagios и т.д.) должен кричать предупреждения на Вас, так, чтобы Вы знающий о нападении.
Наконец, Вы могли бы хотеть считать FAQ, который идет со статьей, он делает авторов, имеющих в виду более ясный. Он говорит о том, как конечные пользователи могут генерировать довольно безопасный и все еще легкий помнить пароли - не об обработке серверной стороны паролей.
Обновление, после редактирования вопроса:
На основе текущей средней производительности большинства веб-серверов, каково максимальное количество попыток входа в систему, возможных во время атаки перебором?
Для простого хеша как SHA1 я сказал бы, что единственный четырехъядерный сервер, принимая хорошие методы программирования, мог обработать на очень грубой приблизительной оценке 10 000 запросов в секунду. Это будет полностью зависеть от платформы веб-приложения и используемого программирования, потому что обработка HTTP-соединения наверху будет господствовать над скоростью вычисления SHA1. Если бы мы используем Apache в режиме Prefork с fx PHP, то числа были бы большим количеством любителя, возможно, 2 000 запросов в секунду на сервер.
скажем, у Вас есть требование для системы, которая не может использовать складывающее tar или временное отключение учетной записи
Затем измените требования - это повреждается вне восстановления.
количество фактических попыток входа в систему в секунду в веб-системе очень полезно.
Снова, у Вас должно быть предупреждение, которое уведомляет Вас относительно атаки перебором задолго до того, как это получает это крупное.
Как мы должны ответить на что-то о "большинстве" веб-приложения? Большинство находится, вероятно, на интранет компании для запуска, но также и Вы, вероятно, вне "большинства" к тому времени, когда Вы добираетесь до веб-приложений, работающих 2 + серверы.
Так или иначе я не думаю, что это говорит, что Вы только получите 100 запросов в секунду, таким образом, это будет всем, от чего необходимо защитить, который является, как вопрос звучит, а скорее что можно, вероятно, только обработать 100 запросов в секунду (который является 60,000/минута) так, чтобы уровень сделал хороший компромисс.
Если Ваше приложение может обработать 1000x логины в секунду, возможно, заново продумать вещи.
Статья не упоминает точечную коррозию tar, которая является практикой замедления ответов входа в систему, столь грубое принуждение становится невозможным - Вы, возможно, видели его сами, где Вы пытаетесь войти в систему 5 раз и после того каждого раза, когда Вы вводите пароль, который это находится, там взбалтывая целую вечность прежде, чем сказать Вам, что перестало работать, и после 10 попыток, задержка становится больше. Продолжайте пробовать, и это подавляет замедление, но отпуск и возвращается через двадцать минут, и это быстро снова.
Выполнение, которое может сделать скота, вызывающего почти невозможный.
Автор той статьи делает огромное предположение о количестве запросов, что "нормальные" веб-приложения могут обработать. Если Ваш сайт находится на выделенном сервере с правильно написанным кодом, он может смочь обработать 1 000 запросов в секунду без потения. Более старый сервер без любого вида оптимизации может только смочь обработать 10 запросов в секунду, прежде чем это начнет прекращать работу. Автор должен был выбрать число для базирования его вычислений на, и 100 походит на разумное место для запуска.
При попытке защитить от или атак с подбором по словарю "в лоб", можно использовать множество методов, таких как точечная коррозия tar, как TessellatingHeckler упомянул, или помещение временных блокировок на учетной записи, как предложено статьей. Я даже видел системы, которые просто проигнорируют запросы от любого IP, который это видит, отправляют запросы выше определенного уровня.
Относительно исходного вопроса, взломщик захочет смочь попробовать как можно больше паролей, не снижая сервер, поэтому не то, чтобы необходимо смочь "защитить от" конкретного количества запросов в секунду, поскольку взломщик будет ограничение скорости их собственные инструменты, если они будут видеть, что он вызывает замедление на сервере, потому что это находится в их интересах не привлечь внимание себе. Просто разработайте свое приложение, чтобы смочь обработать Вашу ожидаемую нормальную нагрузку плюс некоторое разумное поле для роста и случайного скачка в трафике.
Если Вы волнуетесь по поводу универсальных DDos-атак, который является другим разговором полностью и не имеет никакого отношения к запросам в секунду на попытки пароля.
Можно реализовать легкую тюрьму для грубых садоводов. Скажите после 3 неудавшихся логинов Вы блокируете логины от того IP для 1 (или больше) минута (a), но просто продолжаете отправлять пользователю клиента / несоответствие пароля
Иначе должен разделить пользовательские и администраторские логины. скажите, Вы делаете некоторую основную форму для пользовательских логинов и помещенной около него, поддельная кнопка для администраторской ведьмы входа в систему всегда будет говорить "Пароль Incorect". и сделайте некоторую скрытую веб-страницу для настоящего администратора login:D