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

StackOverflow https://stackoverflow.com/questions/479233

Вопрос

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

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

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

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

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

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

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

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

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

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

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

Это было полезно?

Решение

Ладно, хватит тянуть время;вот к чему я пришел на данный момент

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Редактировать: На самом деле, я придумал способ пропустить даже пользователей с КАПЧЕЙ во время "карантина":вместо резервного входа с КАПЧЕЙ или в качестве дополнения к нему предоставьте пользователю возможность отправлять на его электронную почту одноразовый код блокировки, специфичный для конкретного пользователя, который затем он может использовать для обхода ограничения.Это определенно превышает мой порог "раздражения", но поскольку оно используется только как последнее средство для небольшого числа пользователей, и поскольку это все еще лучше, чем быть заблокированным из вашей учетной записи, это было бы приемлемо.

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

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные усовершенствования:

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

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

  • если вы контролируете настройку пароля, то показ пользователю насколько надежен их пароль поощряет их выбирать что-то получше.
  • если вы контролируете вход в систему Страница, после небольшого (скажем, 10) числа угадываний одного имени пользователя, предложите КАПЧУ.

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы не можете просто предотвратить 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);

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

Обобщить схему Йенса в диаграмму перехода псевдосостояния / базу правил:

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

Наблюдения:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У меня в голове не укладывается:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top