Как Вы предотвращаете атаки перебором УСПОКОИТЕЛЬНЫХ услуг передачи данных
Я собираюсь реализовать УСПОКОИТЕЛЬНЫЙ API к нашему веб-сайту (на основе услуг передачи данных WCF, но это, вероятно, не имеет значения).
Все данные, предлагаемые через этот API, принадлежат определенным пользователям моего сервера, таким образом, я должен удостовериться, что только у тех пользователей есть доступ к моим ресурсам. Поэтому все запросы должны быть выполнены с комбинацией входа в систему/пароля как часть запроса.
Каков рекомендуемый подход для предотвращения атак перебором в этом сценарии?
Я думал о входе неудавшихся просьб, отклоненных из-за неправильных учетных данных и игнорирования запросов, происходящих из того же IP после того, как определенный порог неудавшихся запросов был превышен. Действительно ли это - стандартный подход, или действительно ли я - отсутствие чего-то важного?
2 ответа
Сама по себе блокировка на основе IP опасна из-за большого количества шлюзов NAT.
Вы можете замедлить работу (tar pit) клиента, если он быстро сделает слишком много запросов; то есть намеренно вставьте задержку в пару секунд перед ответом. Люди вряд ли будут жаловаться, но вы замедлили работу ботов.
Я бы использовал тот же подход, что и на веб-сайте. Отслеживайте количество неудачных попыток входа в систему в определенном окне - скажем, разрешите 3 (или 5 или 15) в течение некоторого разумного промежутка, скажем, 15 минут. Если пороговое значение превышено, заблокируйте учетную запись и отметьте время, когда произошла блокировка.Вы также можете записать это событие в журнал. По прошествии еще одного подходящего периода, скажем, часа, разблокируйте аккаунт (при следующей попытке входа). Успешные входы в систему сбрасывают счетчики и время последней блокировки. Обратите внимание, что вы никогда не пытаетесь войти в заблокированную учетную запись, вы просто возвращаете логин с ошибкой.
Это эффективно ограничит любую атаку методом перебора, что сделает атаку на разумный пароль очень маловероятной. Злоумышленник, используя мои цифры выше, сможет попробовать только 3 (или 5 или 15) раз за 1,25 часа. Используя свои журналы, вы можете определить, когда такая атака может произойти, просто выполнив поиск нескольких блокировок из одной и той же учетной записи в один и тот же день. Поскольку служба предназначена для использования программами, после того, как программа, обращающаяся к службе, правильно установит свои учетные данные, она никогда не столкнется с ошибкой входа, если не будет выполнена атака. Это было бы еще одним признаком того, что может произойти нападение.Как только вы узнаете, что атака находится в процессе, вы можете принять дальнейшие меры для ограничения доступа к IP-адресам-нарушителям или привлечь власти, если это необходимо, и остановить атаку.