Если мой веб-сайт использует POST-форму для входа в систему, каков быстрый и простой способ предотвратить наводнение моего веб-сервера POST-запросами от мошеннического клиента, пытающегося взломать мои учетные записи с помощью грубой силы?
PHP / MySQL / Apache.
Предотвратить взлом методом грубой силы сложнее, чем может показаться на первый взгляд. Решением будет объединить элементы управления - один-единственный элемент управления не сократит горчицу. И запомните цель: вы хотите замедлить атаку методом грубой силы до точки, при которой она будет либо неэффективной, либо вы сможете ее обнаружить и принять меры. Второй вариант обычно более эффективен, чем первый.
Вы можете использовать капчу (в настоящее время это популярный метод), но капчи часто могут быть прочитаны автоматически, а когда они не могут быть прочитаны компьютером, фермы людей могут быть получены путем оплаты низкооплачиваемых рабочих или с помощью капчи. для защиты «бесплатного» порно (использовались оба метода).
Совет других использовать секретное значение в форме на самом деле не поможет; злоумышленник просто должен проанализировать HTML, чтобы найти секретное значение и включить его в свой пост. Это довольно просто автоматизировать, так что это не совсем хорошая защита. Да, и если значение оказывается легко предсказуемым (с использованием плохого или неисправного ГПСЧ или плохого семени), вы снова наверху.
Отслеживание IP-адреса - это нормально, но только если вы не поддерживаете NAT. При использовании NAT действительные пользователи будут выглядеть как дубликаты. И помните, что злоумышленники могут выдавать себя за другие системы; одна атакующая система может использовать другие IP-адреса и даже перехватывать трафик к этой системе (одним из хороших механизмов для этого является отравление ARP).
Вы можете использовать максимальное количество неудачных тайм-аутов за определенный период времени (например, 3 в течение 1 часа). Это замедляет атакующего, но не обязательно останавливает его. Вы можете включить автоматическую разблокировку, но вам нужно будет выполнить некоторую математику и убедиться, что время разблокировки действительно полезно.
Еще один полезный механизм - экспоненциальная отсрочка. Это может быть возможно привязать к сеансу (который злоумышленник не должен возвращаться на сервер) к IP-адресу (с перерывами с NAT) или к учетной записи (которая не учитывает брутфорс между несколькими учетными записями) .
Чтобы другие средства защиты были полезны, у вас должны быть надежные пароли. Если ваши пароли легко угадываются (есть ли они в словаре? Короткие? Сложные?), Атака будет успешной. Рекомендуется реализовать минимальные требования к надежности пароля и словарь «недопустимых паролей» (в сочетании с обычными заменами символов для этого словаря). В качестве альтернативы вы можете использовать такую систему, как OATH, сертификат входа в систему или аппаратные токены (например, SecurID RSA).
Думаю, что загадки клиента обсуждал Берт Калиски. По сути, вы даете клиенту задачу, которая легка для сервера, но трудна для клиента; клиент совершает DoS-атаку, тратя собственные ресурсы на решение головоломки. Сложность здесь будет заключаться в определении правильной сложности головоломки. Например, это может быть факторинг большого числа. Как бы то ни было, вы должны предположить наиболее эффективный из возможных алгоритмов, и вы должны иметь возможность обрабатывать разную производительность разных браузеров на разных машинах (потенциально медленных), замедляя автоматические атаки вне браузеров (потенциально быстрее, чем ваш javascript). Я упоминал, что вам нужно реализовать решение на JavaScript?
Но вы по-прежнему сталкиваетесь с атакой, которая работает с несколькими учетными записями. Мне не известны какие-либо общедоступные элементы управления, которые хорошо работают против этого, если вы не можете отслеживать IP-адреса.
Затем вы захотите защитить имена пользователей. Злоумышленник, который не знает имен пользователей (требуется система, которая не указывает, когда имена пользователей действительны), должен будет узнать как имя пользователя, так и пароль, вместо простого подтверждения имени пользователя, а затем просто атаковать пароли.
И вам нужно быть осторожным, чтобы сообщения об ошибках и время сервера не выдавали (не) действительные пароли.
И когда вы имеете дело с сообщениями об ошибках, убедитесь, что механизмы восстановления пароля ничего не выдадут. Даже в других хороших системах восстановление пароля может все взорвать.
Но все это говорит о том, что атака в конечном итоге зависит от производительности сервера. Вы можете просто реализовать очень медленный механизм аутентификации (должен быть медленным как для действительной, так и для недействительной аутентификации). Онлайн-атака гарантированно будет проходить не быстрее, чем сервер может обрабатывать запросы.
Затем вам необходимо обнаруживать атаки методом перебора, поэтому вашей системе необходим хороший контрольный журнал. Но вам нужно быть осторожным, чтобы не регистрировать слишком много сообщений журнала, иначе вы откроете простой способ настроить сервер, заполнив дисковое пространство. Что-то вроде сообщения системного журнала «предыдущее сообщение было получено 1000 раз» было бы неплохо.
После того, как вы закончите проектирование, и снова, когда вы закончите реализацию, вы захотите изучить всю систему и все функции системы, математически смоделировать ее с учетом текущих настроек и производительности сервера и определить среднее количество времени, которое потребуется злоумышленнику для грубой силы (а) одной учетной записи и (б) любой учетной записи (брутфорс между учетными записями, чтобы избежать контроля, специфичного для учетной записи).
Один из подходов состоит в том, чтобы отслеживать IP-адрес (или даже первые 3 октета IP-адреса) каждого запроса и добавлять значительное время для ответа (или даже для отбрасывания) запросов, поступающих от IP-адресов, у которых было больше чем x запросов за последние y минут.
Это неэффективно (или менее эффективно) против распределенных атак, но в остальном работает довольно хорошо при относительно простой реализации.
Для более надежной защиты можно также занести в черный список оскорбительные IP-адреса (IP-адреса или снова первые 3 октета IP-адресов, которые представили более, скажем, 6 неудачных попыток за последние 2 минуты или меньше), систематически запрещая доступ к такому IP-адресу на период скажем 15 минут.
Что ж, если вы знаете IP-адрес источника попытки входа в систему, вы можете разрешить ему 5 попыток, а затем заставить этот IP-адрес ждать в течение 5-минутного периода «охлаждения». Если вы считаете, что 5 минут - это слишком мало, увеличьте время до более подходящего (можно увеличить до 24 часов или больше, если вы считаете это необходимым). Это может не сработать, если у них есть десятки скоординированных узлов в ботнете.
