Какая лучшая контрмера Distributed Brute Force?

Ответ 1

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

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

Объединяя методы 3 и 4 с исходным сообщением в виде "нечеткого" или динамического белого списка, а затем - и здесь трюк - не блокирование не-белых списков IP, просто дросселирование их в ад и обратно.

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

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

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

Итак, нам нужно сделать что-то еще.

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

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

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

(+), если злоумышленник "не владеет" ни сервером, ни полями наших пользователей, ни самим соединением, и в этих случаях у нас больше нет проблемы с "аутентификацией", у нас есть подлинный размер франшизы ситуация с FUBAR по напряжению

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

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

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

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

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

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

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

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

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

Нельзя отрицать, что такая устойчивая атака все равно будет представлять собой DoS-атаку, но с описанной системой на месте она повлияет только на то, что, как я подозреваю, является крошечным подмножеством пользователей, а именно людьми, t используйте "помнить меня" cookie И, случается, регистрируются во время атаки и не регистрируются с любого из их обычных IP-адресов И кто не может читать CAPTCHA. Только те, кто может сказать "нет" всем этим критериям, в частности ботам и действительно неудачникам-инвалидам, будут отвергнуты во время бот-атаки.

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

Edit: В ответ на комментарии к дросселю имени пользователя: это дроссель, зависящий от имени пользователя, независимо от источника атаки.

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

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

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

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

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

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

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

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

Ответ 4

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

• Пользователь знает что-то (т.е. пароль)
• Пользователь имеет что-то (т.е. брелоки)
• Пользователь - (т.е. сканирование сетчатки)

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

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

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

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

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

Изменить, Новая идея:

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

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

Ответ 5

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

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

Ответ 6

Ранее я ответил на очень похожий вопрос в Как я могу затормозить попытки входа пользователя в 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 может быть разорен. Существуют альтернативные решения, возможно, вариант "Назовите это животное", который мог бы хорошо работать как заменитель.

Ответ 7

Подводя итог схеме Йенса на диаграмму перехода /statebase псевдо-состояния:

• пользователь + пароль → запись
• user +! password → denied
• user + known_IP (пользователь) → входная дверь, // never throttle
• пользователь + unknown_IP (пользователь) → catflap
• (# denied > n) через catflaps (сайт) → дроссельные катфлапы (сайт) // slow the bots
• catflap + throttle + пароль + captcha → запись // humans still welcome
• catflap + throttle + пароль +! captcha → denied // a correct guess from a bot

замечания:

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

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

Ответ 8

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

Ответ 9

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

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

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

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

Несколько методов могут быть успешно объединены, но хороший вкус, безусловно, в порядке.

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

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

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

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

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

Ответ 10

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

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

Ответ 11

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

Я бы посоветовал вам разобраться, как быстро можно сломать пароль, и пользователи меняют их в два раза чаще. Надеюсь, это поможет.

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

Ответ 12

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

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

Ответ 13

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

В верхней части моего разума:

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

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

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

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

Ответ 14

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

Был ли взломан/взломан reCaptcha/OCRd/побежден/сломан?

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

Ответ 15

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

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

Что-то вроде "password" забивает 1, тогда как "c6eqapRepe7et * Awr @ch" может набрать 9 или 10 очков, и чем выше оценка, тем больше времени требуется для дросселирования.

Ответ 16

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

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

** Проверьте свои записи в обратном (PTR) (под номером ip6.arpa.), чтобы узнать, могут ли они быть использованы в ноль в on/4, у которых есть записи VS/4, которые этого не делают. И.Е. Обычно ip6.arpa будет иметь ~ 32 "." S в адресе, но попытка с последними отсутствующими может ускользнуть от сетевых блоков, у которых есть записи VS других, которые этого не делают. Если вы сделаете это дальше, станет возможно пропустить большие части адресного пространства.

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

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

Ответ 17

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

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