Как вы предотвращаете атаки грубой силы на службы данных RESTful

Я собираюсь внедрить API RESTful на наш сайт (на основе служб данных WCF, но это, вероятно, не имеет значения).

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

Какой рекомендуемый подход для предотвращения нападений грубой силы в этом сценарии?

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

Ответ 1

Блокировка на основе IP сама по себе является рискованной из-за количества шлюзов NAT там.

Вы можете замедлить (tar pit) клиента, если он слишком быстро выполнит запросы; то есть преднамеренно вставить задержку в пару секунд до ответа. Люди вряд ли будут жаловаться, но вы затормозили ботов.

Ответ 2

Я бы использовал тот же подход, что и с веб-сайтом. Следите за количеством неудачных попыток входа в определенное окно - скажем, разрешите 3 (или 5 или 15) в течение некоторого разумного промежутка времени, скажем, 15 минут. Если превышено пороговое значение, заблокируйте учетную запись и отметьте время блокировки. Вы также можете зарегистрировать это событие. После того, как пройдет еще один подходящий период, скажем, час, откройте учетную запись (при следующей попытке входа). Успешные логины reset счетчики и последнее время блокировки. Обратите внимание, что вы никогда не пытаетесь выполнить вход в заблокированную учетную запись, вы просто возвращаете логин.

Это позволит эффективно ограничить любую атаку грубой силой, что делает атаку на разумный пароль очень маловероятным. Злоумышленник, используя мои номера выше, сможет попробовать только 3 (или 5 или 15) раз за 1.25 часа. Используя ваши журналы, вы можете обнаружить, когда такая атака могла произойти, просто путем поиска нескольких локаутов из одной учетной записи в тот же день. Поскольку ваша служба предназначена для использования программами, как только программа, обращающаяся к службе, имеет свои учетные данные, установленную правильно, она никогда не будет испытывать ошибку входа в систему, если не будет проведена атака. Это было бы еще одним признаком того, что атака может произойти. Как только вы узнаете, что атака находится в процессе, вы можете принять дополнительные меры для ограничения доступа к нарушающим IP-адресам или вовлечь власти, если это необходимо, и прекратить атаку.