Какая лучшая контрмера для распределенной грубой силы?

Во-первых, немного предыстории: не секрет, что я внедряю систему аутентификации + аутентификации для CodeIgniter, и пока я побеждаю (так сказать). Но я столкнулся с довольно нетривиальной задачей (которую большинство библиотек авторизации пропускают полностью, но я настаиваю на правильной ее обработке): как разумно бороться с крупномасштабными, распределенными атаками с переменным именем пользователя методом перебора .

Я знаю все обычные трюки:

1. Ограничение количества неудачных попыток для каждого IP / хоста и запрет доступа нарушителей (например, Fail2Ban) - что больше не работает, так как ботнеты стали умнее
2. Комбинируя вышесказанное с черным списком известных «плохих» IP / хостов (например, DenyHosts), который опирается на ботнеты, попавшие на первое место, чего они все чаще не делают
3. Белые списки IP / хостов в сочетании с традиционной аутентификацией (к сожалению, бесполезны для динамических пользователей IP и большого оттока на большинстве веб-сайтов)
4. Установка ограничения по количеству неудачных попыток в течение N минут / часов и регулирование (приостановка) всех попыток входа в систему после этого в течение нескольких минут / часов (с проблемой, что атака DoS становится игрой ботнета)
5. Обязательные цифровые подписи (сертификаты с открытым ключом) или аппаратные токены RSA для всех пользователей без опции логин / пароль (без сомнения, надежное решение, но практично только для закрытых выделенных сервисов)
6. Принудительные схемы сверхсильных паролей (например,> 25 бессмысленных символов с символами - опять же, слишком непрактично для обычных пользователей)
7. И, наконец, CAPTCHA (которые могут работать в большинстве случаев, но раздражают пользователей и практически бесполезны против решительного, находчивого злоумышленника )

Теперь это только теоретически осуществимые идеи. Существует множество идей по взлому, которые взрывают сайт широко (например, для обычных DoS-атак). То, что я хочу, это что-то лучше. И под лучшими я имею в виду:

• Он должен быть защищен (+) от DoS-атак и атак методом перебора, и не должен содержать каких-либо новых уязвимостей, которые могли бы позволить немного хитрому боту продолжить работу под радаром.

• Это должно быть автоматизировано. Если для проверки каждого входа в систему или отслеживания подозрительной активности требуется оператор-человек, это не сработает в реальном сценарии.

• Это должно быть осуществимо для широкого использования в Интернете (т. Е. Высокий отток, большой объем и открытая регистрация, которую могут выполнять непрограммисты)

• Это не может помешать работе пользователя до такой степени, что случайные пользователи будут раздражены или разочарованы (и потенциально могут покинуть сайт)

• Это не может включать котят, если они действительно не очень безопасные котята

(+) Под «безопасным» я подразумеваю, по крайней мере, такую ​​же безопасность, как способность параноидального пользователя хранить свой пароль в секрете.

Итак - давайте послушаем это! Как бы вы это сделали ? Знаете ли вы о лучшем опыте, о котором я не упомянул (о, пожалуйста, говорите)? Я признаю, что у меня есть собственная идея (объединяющая идеи из 3 и 4), но я позволю истинным экспертам говорить, прежде чем смущать себя ;-)

Ладно, хватит тормозить; вот что я придумала до сих пор

(извините, длинный пост вперед. Будь смелым, друг, путешествие того стоит)

Объединение методов 3 и 4 из исходного поста в своего рода «нечеткий» или динамический белый список, а затем - и вот в чем хитрость - не блокирование IP-адресов, не занесенных в белый список, а просто удушение их в ад и обратно .

Обратите внимание, что эта мера предназначена только для того, чтобы помешать этому очень специфическому типу атаки. На практике, конечно, он будет работать в сочетании с другими передовыми подходами к аутентификации: регулирование фиксированного имени пользователя, регулирование для каждого IP-адреса, политика надежных паролей с применением кода, неконтролируемый вход в систему cookie, хэширование всех эквивалентов паролей перед их сохранением, никогда использование вопросов безопасности и т. д.

Предположения о сценарии атаки

Если злоумышленник нацеливается на переменные имена пользователей, наше регулирование имен пользователей не срабатывает. Если злоумышленник использует ботнет или имеет доступ к большому диапазону IP, наше регулирование IP бессильно. Если злоумышленник предварительно очистил наш список пользователей (обычно это возможно в веб-службах с открытой регистрацией), мы не можем обнаружить продолжающуюся атаку на основании количества ошибок «пользователь не найден». И если мы введем ограничивающий дросселирование в масштабе всей системы (все имена пользователей, все IP-адреса), любая такая атака будет делать DoS для всего нашего сайта на время атаки плюс период регулирования.

Поэтому нам нужно сделать что-то еще.

Первая часть контрмеры: Белый список

В чем мы можем быть абсолютно уверены, так это в том, что злоумышленник не может обнаружить и динамически подделать IP-адреса нескольких тысяч наших пользователей (+). Что делает белый список осуществимым. Другими словами: для каждого пользователя мы храним список (хэшированных) IP-адресов, с которых пользователь ранее (недавно) вошел в систему.

Таким образом, наша схема внесения в белый список будет функционировать как запертая «входная дверь», где пользователь должен быть подключен с одного из своих признанных «хороших» IP-адресов, чтобы вообще войти в систему. Атака грубой силой на эту «парадную дверь» была бы практически невозможна (+).

(+) если злоумышленник не «владеет» ни сервером, ни всеми ящиками наших пользователей, ни самим соединением - и в этих случаях у нас больше не возникает проблема «аутентификации», у нас есть подлинный размер франшизы. Ситуация FUBAR

Вторая часть контрмеры: общесистемное регулирование непризнанных IP-адресов

Для того чтобы белый список работал для веб-службы с открытой регистрацией, где пользователи часто переключают компьютеры и / или подключаются с динамических IP-адресов, нам нужно держать «дверь в кошку» открытой для пользователей, подключающихся с нераспознанных IP-адресов. Хитрость заключается в том, чтобы спроектировать эту дверь так, чтобы ботнеты застревали и таким образом, чтобы законные пользователи беспокоились как можно меньше .

В моей схеме это достигается путем установки очень ограниченного максимального числа неудачных попыток входа в систему с помощью неутвержденных IP-адресов в течение, скажем, 3-часового периода (может быть целесообразнее использовать более короткий или более длинный период в зависимости от типа услуги), и сделать это ограничение глобальным , т.е. для всех учетных записей пользователей.

Даже медленная (1-2 минуты между попытками) грубая сила будет обнаружена и сорвана быстро и эффективно с использованием этого метода. Конечно, действительно медленная грубая сила все еще может остаться незамеченной, но слишком медленные скорости наносят ущерб самой цели атаки грубой силы.

Что я надеюсь достичь с помощью этого механизма регулирования, так это то, что, если максимальный предел достигнут, наша «кошачья дверь» на некоторое время захлопывается, но наша входная дверь остается открытой для законных пользователей, подключающихся обычными способами:

• Либо путем подключения с одного из их распознанных IP-адресов
• Или с помощью постоянного файла cookie для входа (из любого места)

Единственные законные пользователи, которые будут затронуты во время атаки - т.е. в то время как регулирование было активировано - это будут пользователи без постоянных файлов cookie для входа, которые входили в систему из неизвестного местоположения или с динамическим IP-адресом. Эти пользователи не смогут войти в систему, пока не прекратится регулирование (что может занять некоторое время, если злоумышленник продолжит работу ботнета, несмотря на регулирование).

Чтобы позволить этой небольшой группе пользователей протиснуться через запечатанную в противном случае дверь кошки, даже если боты все еще били ее, я бы использовал «резервную» форму входа в систему с CAPTCHA. Чтобы при отображении сообщения «Извините, но вы не можете войти с этого IP-адреса в данный момент», добавьте ссылку « Безопасный резервный вход в систему - ТОЛЬКО ЧЕЛОВЕК ( боты: не лгите ) ». Помимо шутки, когда они щелкают по этой ссылке, дают им аутентифицированную reCAPTCHA форму входа в систему, которая обходит регулирование всего сайта. Таким образом, если они люди и знают правильный логин + пароль (и могут читать CAPTCHA), им никогда не будет отказано в обслуживании, даже если они подключаются с неизвестного хоста и не используют cookie-файл автологина.

Да, и просто для пояснения: поскольку я считаю, что CAPTCHA, как правило, являются злыми, опция входа в систему «резервного копирования» будет появляться только при активном регулировании .

Нет никаких сомнений в том, что подобная устойчивая атака все равно будет представлять собой форму DoS-атаки, но при наличии описанной системы она повлияет только на то, что, как я подозреваю, будет крошечной группой пользователей, а именно на людей, которые не используют cookie «Помни меня» И случается, что он входит в систему во время атаки, И не входит ни с одного из своих обычных IP-адресов И не может читать CAPTCHA. Только те, кто может сказать «нет» ВСЕМ из этих критериев - особенно боты и действительно несчастные люди с ограниченными возможностями - будут отвергнуты во время атаки ботов.

РЕДАКТИРОВАТЬ: На самом деле, я подумал о том, чтобы позволить даже пользователям с CAPTCHA проходить через «блокировку»: вместо или в качестве дополнения к резервному входу в CAPTCHA, пользователь может выбрать одноразовое использование. пользовательский код блокировки, отправленный на его электронную почту, который он затем может использовать для обхода регулирования. Это определенно пересекает мой порог «раздражения», но так как он используется только в качестве крайней меры для небольшого подмножества пользователей, и поскольку он все еще превосходит блокировку вашей учетной записи, это будет приемлемо.

(Также обратите внимание, что ничего этого не произойдет, если атака будет менее изощренной, чем неприятная распределенная версия, которую я описал здесь. Если атака идет с нескольких IP-адресов или с использованием нескольких имен пользователей, она будет сорвана намного раньше и без каких -либо последствий для всего сайта)

Итак, это контрмера, которую я буду реализовывать в моей библиотеке аутентификации, как только я убедлюсь, что это правильно и что нет более простого решения, которое я пропустил. Дело в том, что существует очень много хитрых способов сделать что-то не так в безопасности, и я не против того, чтобы делать ложные предположения или безнадежно ошибочную логику. Поэтому, пожалуйста, высоко оцените любые отзывы, критику и улучшения, тонкости и т.д.

Несколько простых шагов:

Черный список определенных общих имен пользователей, и использовать их в качестве приманки. Администратор, гость и т. Д. Не позволяйте никому создавать учетные записи с этими именами, поэтому, если кто-то попытается войти в систему, вы знаете, что кто-то делает то, что не должен делать.

Убедитесь, что любой, кто имеет реальную власть на сайте, имеет безопасный пароль. Требовать от администраторов / модераторов иметь более длинные пароли с сочетанием букв, цифр и символов. Отклоните тривиально простые пароли от обычных пользователей с объяснениями.

Одна из самых простых вещей, которую вы можете сделать, это сообщить людям, когда кто-то пытался войти в их учетную запись, и дать им ссылку, чтобы сообщить об инциденте, если это не они. Простое сообщение, когда они входят в систему: «Кто-то пытался войти в вашу учетную запись в 4:20 утра среды бла-бла. Нажмите здесь, если это был не вы». Это позволяет вам вести статистику атак. Вы можете усилить меры контроля и безопасности, если увидите, что количество мошеннических обращений резко возросло.

Если я правильно понимаю МО атак грубой силы, то одно или несколько имен пользователей будут пробоваться непрерывно.

Есть два предложения, которые я не видел здесь:

• Я всегда думал, что стандартной практикой было иметь небольшую задержку (секунду или около того) после каждого неправильного входа в систему для каждого пользователя. Это удерживает грубую силу, но я не знаю, как долго задержка в одну секунду будет сдерживать атаку по словарю. (словарь из 10000 слов == 10000 секунд == около 3 часов. Хм. недостаточно хорошо.)
• вместо замедления всего сайта, почему бы не использовать имя пользователя. Дроссель становится все более резким с каждой неправильной попыткой (я думаю, до предела, так что реальный пользователь все еще может войти)

Редактировать : в ответ на комментарии к дросселю имени пользователя: это дроссель к конкретному имени пользователя без учета источника атаки.

Если имя пользователя задушено, то может быть обнаружена даже скоординированная атака по имени пользователя (мульти IP, одно предположение на IP, то же имя пользователя). Отдельные имена пользователей защищены дросселем, даже если злоумышленники могут попробовать другого пользователя / пройти в течение тайм-аута.

С точки зрения злоумышленников, в течение тайм-аута вы сможете впервые сделать предположение о 100 паролях и быстро обнаружить один неверный пароль для каждой учетной записи. Вы можете только сделать 50-секундное предположение за тот же период времени.

С точки зрения учетной записи пользователя, для взлома пароля все равно требуется одинаковое среднее число догадок, даже если догадки поступают из нескольких источников.

Для злоумышленников в лучшем случае это будет та же попытка взломать 100 учетных записей, что и 1 учетная запись, но, поскольку вы не ограничиваете ресурсы на всем сайте, вы можете довольно быстро увеличить дроссель.

Дополнительные уточнения:

• обнаруживать IP-адреса, которые предполагают наличие нескольких учетных записей - 408 Request Timeout
• обнаруживать IP-адреса, которые используют один и тот же аккаунт - 408 Request Timeout после большого (скажем, 100) числа догадок.

Идеи пользовательского интерфейса (могут не подходить в этом контексте), которые также могут уточнить выше:

• если вы контролируете настройку пароля, то показ пользователя, насколько надежным является его пароль, побуждает его выбрать лучший.
• если вы контролируете страницу входа в систему , то после небольшого (скажем, 10) числа предположений об одном имени пользователя предложите CAPTCHA.

Существует три фактора аутентификации:

1. Пользователь что- то знает (т.е. пароль)
2. У пользователя есть что-то (например, брелок)
3. Пользователь - это что-то (например, сканирование сетчатки)

Как правило, веб-сайты применяют только политику № 1. Даже большинство банков применяют только политику 1. Вместо этого они полагаются на подход «знает что-то другое» к двухфакторной аутентификации. (IE: пользователь знает свой пароль и девичью фамилию своей матери.) Если вы можете, способ добавить второй фактор аутентификации не слишком сложен.

Если вы можете сгенерировать около 256 символов случайности, вы можете структурировать их в таблице 16 × 16, а затем попросить пользователя указать, например, значение в таблице ячейки A-14. Когда пользователь регистрируется или изменяет свой пароль, дайте ему таблицу и попросите его распечатать и сохранить ее.

Сложность такого подхода заключается в том, что когда пользователь забывает свой пароль, как он хочет, вы не можете просто предложить стандарт «ответьте на этот вопрос и введите новый пароль», поскольку он также уязвим для перебора. Кроме того, вы не можете сбросить его и отправить по электронной почте новый, так как их электронная почта также может быть скомпрометирована. (См .: Makeuseof.com и их украденный домен.)

Другая идея (которая включает в себя котят), это то, что BOA называет SiteKey (я полагаю, они используют торговую марку). Вкратце, у вас есть пользователь, загружающий изображение при регистрации, и когда он пытается войти в систему, попросите его выбрать свое изображение из 8 или 15 (или более) случайных. Таким образом, если пользователь загружает фотографию своего котенка, теоретически только он точно знает, какая картинка у него из всех других котят (или цветов или чего-то еще). Единственная реальная уязвимость, которой обладает этот подход, - это атака «человек посередине».

Еще одна идея (но без котят) - отслеживать IP-адреса, с которых пользователи получают доступ к системе, и требовать от них дополнительной аутентификации (капча, выбрать котенка, выбрать ключ из этой таблицы), когда они входят в систему с адреса, который у них есть. не раньше Также, как и в GMail, пользователи могут просматривать, где они недавно вошли в систему.

Редактировать, Новая идея:

Другой способ проверки попыток входа - проверить, пришел ли пользователь с вашей страницы входа. Вы не можете проверить рефералов, так как они могут быть легко подделаны. Вам нужно установить ключ в переменной _SESSION, когда пользователь просматривает страницу входа в систему, а затем проверить, существует ли этот ключ, когда он отправляет свои данные для входа. Если бот не отправит сообщение со страницы входа, он не сможет войти. Вы также можете упростить это, включив в процесс javascript, либо используя его для установки файла cookie, либо добавив некоторую информацию в форму после ее загрузки. Или вы можете разделить форму на две разные отправки (то есть, пользователь вводит свое имя пользователя, отправляет, затем на новой странице вводит свой пароль и снова отправляет).

Ключ, в этом случае, является наиболее важным аспектом. Распространенным методом их генерации является некоторая комбинация данных пользователя, их IP-адреса и времени их отправки.

Ранее я отвечал на очень похожий вопрос в разделе Как я могу ограничить попытки входа пользователя в PHP . Я повторю предложенное решение здесь, так как я полагаю, что многие из вас найдут его информационным и полезным, чтобы увидеть какой-то реальный код. Пожалуйста, помните, что использование CAPTCHA может быть не лучшим решением из-за все более точных алгоритмов, используемых в настоящее время в бастерах CAPTCHA:

Вы не можете просто предотвратить DoS-атаки, связав регулирование до одного IP-адреса или имени пользователя. Черт, вы даже не можете предотвратить попытки быстрого входа в систему с помощью этого метода.

Зачем? Потому что атака может охватывать несколько IP-адресов и учетных записей пользователей, чтобы обойти ваши попытки регулирования.

Я уже писал в другом месте, что в идеале вы должны отслеживать все неудачные попытки входа на сайт и связывать их с меткой времени, возможно:

CREATE TABLE failed_logins(
    id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(16) NOT NULL,
    ip_address INT(11) UNSIGNED NOT NULL,
    attempted DATETIME NOT NULL
) engine=InnoDB charset=UTF8;

Определите определенные задержки на основе общего количества неудачных входов в систему за определенный промежуток времени. Вы должны основывать это на статистических данных, извлеченных из вашей failed_loginsтаблицы, так как они будут меняться с течением времени в зависимости от количества пользователей и от того, сколько из них могут вспомнить (и ввести) свой пароль.

10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha

Запросите таблицу при каждой неудачной попытке входа в систему, чтобы найти количество неудачных попыток входа в систему за указанный период времени, скажем, 15 минут:

SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

Если количество попыток за указанный период времени превышает ваш лимит, либо принудите регулирование, либо заставьте всех пользователей использовать капчу (т.е. reCaptcha) до тех пор, пока количество неудачных попыток за данный период времени не станет меньше порогового значения.

// array of throttling
$throttle = array(10 => 1, 20 => 2, 30 => 'recaptcha');

// assume query result of $sql is stored in $row
$sql = 'SELECT MAX(attempted) AS attempted FROM failed_logins';
$latest_attempt = (int) date('U', strtotime($row['attempted']));
// get the number of failed attempts
$sql = 'SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)';
// assume the number of failed attempts was stored in $failed_attempts
krsort($throttle);
foreach ($throttle as $attempts => $delay) {
    if ($failed_attempts > $attempts) {
        // we need to throttle based on delay
        if (is_numeric($delay)) {
            $remaining_delay = time() - $latest_attempt - $delay;
            // output remaining delay
            echo 'You must wait ' . $remaining_delay . ' seconds before your next login attempt';
        } else {
            // code to display recaptcha on login form goes here
        }
        break;
    }
}

Использование reCaptcha при определенном пороге гарантирует, что атака с нескольких фронтов будет сведена к минимуму, и обычные пользователи сайта не будут испытывать значительную задержку для законных неудачных попыток входа в систему. Я не могу гарантировать гарантию, так как это уже было расширено на то, что CAPTCHA могут быть уничтожены. Существуют альтернативные решения, возможно, вариант «Назови это животное», который вполне может подойти в качестве замены.

Я должен спросить, провели ли вы анализ затрат и выгод по этой проблеме; Похоже, вы пытаетесь защитить себя от злоумышленника, у которого достаточно присутствия в сети, чтобы угадать количество паролей, отправляя, возможно, 3-5 запросов на IP (так как вы отклонили регулирование IP). Сколько (примерно) будет стоить такая атака? Это дороже, чем стоимость счетов, которые вы пытаетесь защитить? Сколько гигантских ботнетов хочет то, что у тебя есть?

Ответ может быть нет - но если это так, я надеюсь, что вы получите помощь от какого-то специалиста по безопасности; навыки программирования (и оценка StackOverflow) не сильно связаны с ноу-хау безопасности.

Чтобы обобщить схему Йенса в диаграмме / псевдо-переходе состояния:

1. пользователь + пароль -> запись
2. пользователь +! пароль -> отказано
3. пользователь + known_IP (пользователь) -> входная дверь, // never throttle
4. пользователь + unknown_IP (пользователь) -> catflap
5. (#denied> n) через catflaps (сайт) -> дроссельная заслонка (сайт) // slow the bots
6. catflap + throttle + password + captcha -> запись // humans still welcome
7. catflap + газ + пароль +! капча -> отказано // a correct guess from a bot

Замечания:

• Никогда не дросселируйте входную дверь. Элбонская государственная полиция хранит ваш компьютер в вашем доме, но не может вас допрашивать. Грубая сила - это жизнеспособный подход с вашего компьютера.
• Если вы предоставите "Забыли пароль?" ссылка, то ваша учетная запись электронной почты становится частью поверхности атаки.

Эти наблюдения охватывают различные типы атак, против которых вы пытаетесь противостоять.

Похоже, вы пытаетесь защититься от медленной грубой силы . Не так уж много вы можете с этим поделать. Мы используем PKI и не вводим пароли. Это помогает, но если ваши клиенты время от времени посещают рабочие места, это не очень применимо.

Отказ от ответственности: я работаю в двухфакторной компании, но не здесь, чтобы подключить его. Вот некоторые наблюдения.

Файлы cookie могут быть украдены с помощью XSS и браузера. Пользователи обычно меняют браузеры или очищают свои куки.

Исходные IP-адреса являются одновременно динамически изменяемыми и поддельными.

Капча полезна, но не аутентифицирует конкретного человека.

Можно успешно сочетать несколько методов, но хороший вкус, безусловно, в порядке.

Сложность пароля хорошая, все, что основано на паролях, критически зависит от паролей, обладающих достаточной энтропией. ИМХО, надежный пароль, записанный в безопасном физическом месте, лучше слабого пароля в памяти. Люди знают, как оценить безопасность бумажных документов гораздо лучше, чем знают, как определить эффективную энтропию в имени своей собаки, когда она используется в качестве пароля для трех разных веб-сайтов. Подумайте о том, чтобы дать пользователям возможность распечатать большую или маленькую страницу, полную разовых паролей.

Вопросы безопасности, такие как «каким был талисман в старшей школе», в основном являются еще одной паршивой формой «чего-то, что вы знаете», большинство из которых легко угадать или открыто сделать достоянием общественности.

Как вы заметили, уменьшение количества неудачных попыток входа в систему является компромиссом между предотвращением атак методом перебора и простотой DoSing учетной записи. Агрессивные политики блокировки могут отражать отсутствие доверия к энтропии паролей.

Лично я не вижу выгоды от принудительного истечения срока действия пароля на веб-сайте. Атакующий получает ваш пароль один раз, затем он может изменить его и выполнить эту политику так же легко, как и вы. Возможно, одним из преимуществ является то, что пользователь может заметить раньше, если злоумышленник изменит пароль учетной записи. Еще лучше было бы, если бы пользователь был каким-то образом уведомлен, прежде чем злоумышленник получил доступ. В этом отношении полезны сообщения типа «N неудачных попыток с момента последнего входа в систему».

Наилучшая безопасность обеспечивается вторым фактором аутентификации, который является внеполосным по сравнению с первым. Как вы сказали, аппаратные токены в «чем-то, что у вас есть» великолепны, но у многих (не всех) есть реальные накладные расходы администратора, связанные с их распространением. Я не знаю ни одного биометрического решения «что-то, что ты есть», подходящего для веб-сайтов. Некоторые двухфакторные решения работают с поставщиками openid, у некоторых есть PHP / Perl / Python SDK.

Моя самая высокая рекомендация - просто следить за тем, чтобы пользователи информировались о неудачных попытках входа в свои учетные записи. Пользователи, скорее всего, будут более серьезно относиться к надежности своего пароля, если им будут представлены доказательства того, что кто-то на самом деле пытается войти в их учетную запись ,

Я на самом деле поймал кого-то, кто взломал учетную запись моего брата на myspace, потому что он пытался войти в учетную запись gmail, которую я для него установил, и использовал функцию «сбросить пароль по электронной почте» ... которая зашла в мой почтовый ящик.

1. Как насчет одноразового пароля перед вводом обычного пароля? Это сделает очевидным, что кто-то атаковал до того, как у него появилось много возможностей угадать основной пароль?

2. Держите глобальный счет / частоту сбоев входа в систему - это показатель для атаки - во время атаки будьте более строгими в отношении сбоев входа в систему, например, более быстрого запрета IP-адресов.

Я не верю, что есть идеальный ответ, но я был бы склонен подходить к нему на основе попыток спутать роботов, если чувствуется атака.

С моей головы:

Переключиться на альтернативный экран входа в систему. Он имеет несколько пробелов имени пользователя и пароля, которые действительно появляются, но только один из них находится в нужном месте. Имена полей RANDOM - сессионный ключ отправляется вместе с экраном входа в систему, затем сервер может выяснить, что это за поля. В случае успеха или неудачи он затем отбрасывается, поэтому вы не можете попытаться повторить атаку - если вы отклоните пароль, они получат новый идентификатор сеанса.

Предполагается, что любая форма, отправленная с данными в неправильном поле, принадлежит роботу - ошибка входа в систему, точка, и этот IP-адрес задушен. Убедитесь, что случайные имена полей никогда не совпадают с допустимыми именами полей, чтобы кто-то, использующий что-то, что запоминает пароли, не вводил в заблуждение.

Далее, как насчет другого рода капчи: у вас есть ряд вопросов, которые не вызовут проблем у человека. Тем не менее, они не случайны. Когда начинается атака, всем задается вопрос № 1. Через час вопрос № 1 отбрасывается, его больше никогда не использовать, и каждый получает вопрос № 2 и так далее.

Злоумышленник не может загрузить базу данных и вставить в своего робота из-за разового характера вопросов. Он должен отправить новые инструкции в свой ботнет в течение часа, чтобы иметь возможность что-либо делать.

Поскольку несколько человек включили CAPTCHA в качестве резервного механизма, я добавляю более ранний вопрос и поток StackOverflow об эффективности CAPTCHA.

ReCaptcha был взломан / взломан / OCR'd / победил / сломан?

Использование CAPTCHA не ограничивает улучшения вашего регулирования и других предложений, но я думаю, что число ответов, которые включают CAPTCHA в качестве запасного варианта, должно учитывать человеческие методы, доступные людям, которые хотят нарушить безопасность.

Вы также можете регулировать скорость, основываясь на надежности пароля пользователя.

Когда пользователь регистрирует или меняет свой пароль, вы рассчитываете степень надежности его пароля, например, от 1 до 10.

Нечто подобное «паролю» присваивается 1, в то время как «c6eqapRepe7et * Awr @ ch» может набирать 9 или 10, и чем выше этот показатель, тем дольше дросселирование срабатывает.

Первый ответ, который я обычно слышал, задавая этот вопрос, - это изменить порты, но забудьте об этом и просто отключите IPv4. Если вы разрешаете только клиентам из сетей IPv6, вы больше не будете молиться о простом сканировании сети, и злоумышленники прибегнут к поиску DNS. Не используйте тот же адрес, что и ваш Apache (AAAA) / Sendmail (MX-> AAAA) / что вы раздали всем (AAAA). Убедитесь, что ваша зона не может быть изменена, подождите, пока вы разрешаете кому-либо загружать ее?

Если боты обнаружат, что ваш сервер настроил новые имена хостов, просто добавьте немного бреда к вашим именам хостов и измените ваш адрес. Оставьте старые имена и даже настройте ** honeypot-имена для бот-сети для тайм-аута.

** Протестируйте ваши обратные (PTR) записи (в ip6.arpa.), Чтобы увидеть, можно ли их использовать для обнуления в / 4, в которых есть записи VS / 4, в которых нет. IE Как правило, ip6.arpa будет иметь ~ 32 "." В адресе, но попытка с последними несколькими пропущенными может ускользнуть от сетевых блоков, имеющих записи, против других, которые не имеют. Если вы продолжите в том же духе, станет возможным пропустить большие части адресного пространства.

В худшем случае пользователям придется настраивать туннель IPv6, но вряд ли им придется заходить так далеко, как VPN в DMZ ... Хотя возникает вопрос, почему это не первый вариант.

Также Kerberos это круто, но IMHO LDAP удары (Что технически не так с NISPlus? Я читал, что Sun решила, что пользователи хотят LDAP, и из-за этого они отказались от NIS +). Kerberos отлично работает без LDAP или NIS, просто нужно управлять пользователями на хосте за хостом. Использование Kerberos дает вам простую в использовании, если не автоматизированную, PKI.

Здесь немного поздно, но я подумал, предполагая сложный случай - злоумышленник использует много случайных IP-адресов, случайных имен пользователей и случайных паролей, выбранных, скажем, из списка 10 000 самых популярных.

Одна вещь, которую вы могли бы сделать, особенно если система кажется атакованной в том, что в системе много попыток ввода неправильного пароля, и особенно, если пароль имеет низкую энтропию, это задать дополнительный вопрос, например, как зовут ваших родителей, например , Если злоумышленник получит доступ к миллиону учетных записей, попробовав пароль «пароль1», есть большая вероятность, что он получит много, но вероятность того, что имена будут правильными, значительно уменьшит успех.