#node.js #security #brute-force #server-side-attacks
#node.js #Безопасность #перебор #атаки на стороне сервера
Вопрос:
У меня есть проект MERN stack, запущенный на Heroku, сегодня кто-то начал наводнять мой сервер множеством запросов на вход (перебор). Каждый запрос имеет другой IP-адрес, поэтому я не могу заблокировать IP. Это вызвало сбой веб-сайта.
Как я могу заблокировать его тогда? Как я могу разрешить вход только с моего веб-сайта?
Комментарии:
1. Вы уверены, что каждый отдельный запрос поступает с другого IP-адреса? Это кажется маловероятным. Злоумышленник может использовать несколько IP-адресов, но было бы необычно, если бы вы никогда не видели повторный запрос с того же IP-адреса.
2. да, проверка журналов для каждого запроса fwd=»ip» отличается..
3. Одним из типичных решений является требование взаимодействия с человеком при входе в систему, например, с помощью captcha или решения без captcha, которое просит пользователя щелкнуть мышью по определенному месту на экране (и использует детектор, чтобы увидеть, похож ли он на реального пользователя).
Ответ №1:
Типичное решение, которое, как вы увидите, используется многими страницами входа, — это один из нескольких методов, требующих взаимодействия с человеком, и его трудно дублировать скриптам.
Вы наверняка видели системы captcha, которые запрашивают у пользователя интерпретацию некоторого изображения, которое компьютерам нелегко или непрактично анализировать.
Существует также система без капчи, которая просит пользователя щелкнуть мышью по определенному месту на экране и анализирует движение, чтобы увидеть, похоже ли оно на человеческое. Они часто отображаются как щелчок по кнопке «Я не робот».
Многие сайты (например, некоторые авиакомпании США и ряд финансовых сайтов) теперь требуют, чтобы пользователь задавал «сложные» вопросы (например: «Где вы родились?» или «Какой ваш любимый вкус мороженого?»), И если запрос на вход поступает без ранее размещенного подписанного файла cookie дляэтот пользователь (или другие знакомые показатели обнаружения браузера), тогда вопрос о вызове требуется, прежде чем вы сможете даже попытаться войти в систему.
Более драконовский подход (который может оказать большее влияние на конечного пользователя) заключается в отслеживании неудачных попыток входа в систему для каждой учетной записи, и после определенного числа вы начинаете замедлять ответы (это замедляет работу систем злоумышленников), а после некоторого большего количества неудачных ответов вы немедленно терпите неудачукаждый запрос и требует от конечного пользователя подтверждения своего запроса на вход с помощью сообщения электронной почты, отправленного на его зарегистрированный адрес электронной почты. Это неудобно для конечного пользователя, но предотвращает более N догадок для любой отдельной учетной записи без подтверждения конечного пользователя. Через некоторое время вы можете очистить предыдущие номера попыток входа в систему для любой данной учетной записи, освободив ее для нормальной работы.
Комментарии:
1. Я добавил recaptcha V2 для интерфейса и серверной части 🙂 теперь он получает статус 400 неверный запрос, потому что у него нет captcha!! спасибо 🙂