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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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