За последний день или около того у одного из экземпляров была задействована большая пропускная способность. Это означает, что мы почти превысили нашу норму (примерно одинаковое количество входящих и исходящих).
Просматривая журналы, единственное, что я вижу, - это множество из 400 172 ошибок в nginx access.log с той же текстовой строкой.
Я изменил nginx на другой порт, реализовал fail2ban, но, поскольку трафик идет с разных IP-адресов, это не работает. У меня также есть наш провайдер VPS для изменения IP нашего VPS.
Fail2ban в настоящее время отключает все подключения к порту 80, что не идеально, поскольку мы хотели бы использовать этот порт.
Что мы можем сделать, чтобы улучшить ситуацию? Если мы отбрасываем подозрительный трафик, будет ли это засчитываться в нашу норму?
Больше информации
Мне удалось получить более подробную информацию, изменив уровень журнала ошибок nginx.
Единственная ошибка, которая, похоже, происходит, - это то, что cleint отправил неверный запрос при чтении строки запроса клиента.
Домен новый и ранее не использовался (это новый субдомен на одном из давно существующих доменов).
Я проверю, использует ли он тот же путь.
Кроме того, есть ли причина, по которой его увеличивающийся беспроигрышный трафик объясняется только тем, что входящие пакеты блокируются?
Как правило, любой трафик, который доходит до вас или до шлюза (исходящий от вашего хоста), засчитывается в вашу пропускную способность. Это верно, даже если активность незначительна или состоит только из трафика, заблокированного брандмауэром вашего хоста.
Как можно скорее избавиться от вредоносного трафика. Однако похоже, что у вас может быть проблема, связанная с планом хостинга с большой пропускной способностью, но небольшими квотами на передачу - вы испытываете фундаментальную проблему с такими планами, если это так.
То, что вы будете делать отсюда, зависит от трафика. Если это всего несколько хостов, рассмотрите возможность блокировки этих хостов с помощью брандмауэра VPS-провайдера, если они делают эту опцию доступной. Если это робот поисковой системы, добавьте файл robots.txt, запрещающий им сканировать любой путь, по которому возникают ошибки.
172 в ваших журналах не является частью кода ошибки - эти строки означают только, что ваш сервер вернул код ошибки 400 Bad Request а страница с ошибкой, которую он отправил, имела длину 172 байта.
Поскольку это ошибка 400, скорее всего, это не поисковая система (если вы не запускаете странное приложение CGI), но, не зная, что это за строка запроса (включая метод), трудно сказать, что происходит. Но попробуйте решить эту проблему, основываясь на том, что, похоже, пытается сделать «злоумышленник».
Блокировка запросов в nginx вряд ли сильно изменит.
Вместо этого вы можете рассмотреть возможность блокировки этих запросов на сетевом уровне, отбросив нежелательный трафик; это означает, что отправитель трафика получит кучу открытых соединений. Если скорость не меняется, шансы довольно хорошие, это злонамеренно. Вы можете рассмотреть возможность отправки жалобы о злоупотреблениях исходному интернет-провайдеру, если все она поступает из одной сети и выглядит как наводнение, а не как автоматический процесс, пытающийся что-то сделать. Это может быть так же просто, как если бы у кого-то было ваше доменное имя до вас.
Не зная о вашем хостинг-провайдере, я не могу дать окончательный ответ относительно того, учитываются ли отклоненные запросы в вашей квоте, но в целом, если они достигают вашего экземпляра сервера, они обычно учитываются.
В этом случае настоятельно рекомендуется использовать fail2ban. Если вы отбрасываете входящие пакеты и не отклоняете их, это означает, что вы не увидите увеличения исходящего трафика в виде ICMP-пакетов «Соединение отклонено».
Есть ли закономерность во входящих запросах? Все ли они из определенного блока CIDR или являются запросами для определенного URL-адреса? Это URL-адрес на вашем веб-сайте или случайная строка?
Если это один и тот же URL-адрес каждый раз, я бы предложил заблокировать эти запросы в Nginx, если вы еще этого не сделали.
Если это конкретный исходный блок CIDR, который достаточно мал, вы можете просто отключить все соединения с этих адресов.
Похоже, вы подвергаетесь DDoS-атаке. Эта статья о сбоях сервера дает отличный совет: Я под DDoS. Что я могу сделать?