Как «навесить» капчу на готовый сайт (anti-ddos, apache2/nginx)?
Сайт одного из клиентов под ддосом. Похоже, ддосят через реальных визиторов (предположение: где-то на своем или ломаном сайте повесили ссылки, и их посетители незаметно для себя подгружают разные страницы, или исполняют какой-то JS код, который выполняет запросы. Но я часто вижу запросы с рандомными уникальными параметрами вроде /somepage.php?zGzn1=Ar4lt1aB). Обычно с одного IP даже если много запросов, то одинаковый User-Agent.
Сейчас самописно скриптом грепаю-баню. (уже под 1000 IP в iptables). Есть вариант, перейти на cloudflare, они знают, как бороться с ddos'ом, но не хочется перетаскивать DNS к ним.
Поэтому возник вопрос: Можно ли как-то навесить капчу поверх сайта, просто что-то подправив в конфигах вебсервера? (не переписывая его или с минимальными изменениями и чтобы ботовый запрос не дергал медленную CMSку). Чтобы если нет нужной куки - то выкидывал на капчу и только при решении капчи и получении валидной куки (человек осознанно загружает) - пускал бы на сайт. Главное - запрос от бота должен минимально грузить сервер.
На данный момент сайт под apache 2.4, но могу как-то через nginx прокси зарулить его, через caddy, traefik, хоть через черта лысого. Так что, подойдет решение для любого вебсервера. Есть ли что-то такое? (это главный вопрос)
И еще пара вопросов
- а как-то через CORS (Access-Control-Allow-Origin, ...) или Content-Security-Policy можно решить эту проблему (чтобы браузеры не запрашивали ничего, даже по GET запросам, ни во фреймах, никак) или не поможет? У меня тут скептицизм, потому как они в браузере отрабатывают, а значит, какой-то "тяжелый" запрос к сайту все равно выполнится, отожрет ресурсы и трафик и только в браузере отбросится.
- можно ли как-то узнать, с чего это (и с каких сайтов) браузеры с разных IPк нам лезут? В referer ничего нет.
Чем больше знаю, тем лучше понимаю, как мало знаю.
Капча ведь от полноценного DDoS-а не поможет. Если будет настоящий DDoS с 100500+ запросами в секунду - просто замучаетесь генерировать/отправлять эту капчу, с нулевым результатом, клиенты так и будут её без остановки запрашивать...
Самое простое - в самих скриптах проверять валидность данных. Например аргумент zGzn1=Ar4lt1aB у вас где-нибудь существует/используется? Нет? Ну и баньте запрашивающего сразу, не через iptables - так через отдельный файл, скидывать туда все блокированные IP-шки.
Можно сделать a-la Captcha, статичную страничку, на которую будут редиректиться все непроверенные запросы, и там JS-форма с кнопкой(ами), и надо щелкнуть определённую, и тогда будет нужный cookie/аргумент, и полный доступ к сайту... Но атакующие могут тоже адаптироваться, надо учитывать.
Да, CORS поможет, потому что браузер сначала HTTP OPTIONS запросом узнаёт разрешения https сайта - а уже потом ломится за содержимым. Но тут зависит от механизма, действительно ли атакующие браузеры делают запрос с какой-то злонамеренной страницы? Если бы страница была - она отображалась бы в Referer... А тут больше похоже на вредоносный браузерный плагин, а не на ссылку с какой-то страницы, и CORS просто не сработает.
Ну, слава Богу, у нас пока "не настоящий" DDoS, но хватает, чтобы положить виртуалку. Так что, пока что, нужна не панацея от всех болезней, включая чуму и рак, а просто удобное лекарство от перхоти.
zGzn1=Ar4lt1aB нигде не используется, но это случайная часть запроса. В этом - так, а в следующем будет 2bQQj=d3k2nnWs. Я сейчас скриптом и выгрепываю такое. Но проблема - логи большие (особенно, во время атак) и выгрепывать все это занимает ощутимое время, несколько секунд на IP. И за одну итерацию (проверку всех подключенных IP, получаю через lsof) - уходит пара минут. Потом новая итерация. Сервак успевают положить, потом я что-то баню, рестартую, но снова забивают запросами. Через какое-то время забаниваются все сегодняшние IP и атака прекращается.
Про JS страничку - спасибо, идея очень интересная! А можно ли как-то проверять в вебсервере (то есть - быстро проверять, а не через PHP/Python) какую-то правильность куки (чтобы любая кука не работала)? Чтобы куки для разных IP, User-Agent'ов требовались разными.
CORS может помочь даже от GET запроса? Нас GET'ами долбят, не POST'ами...
Про браузерный плагин - интересная идея. Не исключено. Хотя мне кажется, что (по юзер-агентам) запросы и с телефонов идут, так что, может это и не плагин.
Всё очень просто. В ваших скриптах есть URL аргументы, состоящие сразу из больших и маленьких букв? Нету? Ну воооот... А начинающиеся на цифру? Агаааа... Ну и так далее.
А с кукой ещё проще, используйте уникальное имя, и всё. Конечно когда-нибудь атакеры это имя увидят, и его подделку у себя добавят, а у вас уже другое имя есть... Ну и так далее. Работа с кукой с таким-то жёстко прописанным именем есть в nginx.
Есть oneliner (ну почти): в нгинксе запретить доступ без куки, и у кого ее нет - отправлять на капчу которая ее повесит
Минус - живые люди тоже должны будут один раз пройти
Минус вполне себе терпимый (все лучше, чем когда сайт лежит). Но вопрос - а можно ли сделать капчу чисто на фронтенте (HTML/JS) без бэкенда? Если нельзя и нужен бэк, который будет генерировать кастомную страничку каждый раз или проверять капчу, то не получится ли так что обработка капчи (неправильной, боты ее не могут пройти успешно, но могут делать попытки) будет по сложности-скорости сравнимой с генерацией обычной страницы?
Ярослав, вместе с картинкой с сервера ты должен прислать зашифрованный правильный ответ на капчу в куке (или сохранить в сессии на стороне сервера), а при отправке формы с ответом юзера - свериться на бэке. Если будешь генерить ответ капчи на клиенте - клиент и сможет расковырять, по другому никак.
а, суть в том, что генерить капчу выйдет по ресурсам даже дороже чем отдать просто боту ту страницу что он искал? В этом вопросе всё зависит исключительно от целевой страницы, но я более чем уверен, что твои вычисления куда серьезнее капчи. В данном случае можно обойти проблему предварительной генерацией множества капч (хоть на другом пк), либо, например, менять капчу раз в час (к примеру) - тогда генерировать её надо будет как раз всего лишь раз в час.
но, в идеале, злоумышленник должен достаточно быстро увидеть защиту и перехотеть ддосить.
а универсальное решение всё таки посредник, т.е. клаудфлейр, обойти его пусть и тоже можно, но никак не в плоскости того решения, которым атаковать тебя выбрал злоумышленник. Там уже и капча есть, и under attack mode (котрый многие включают по дефолту и он всегда капчу выдаёт), и очень много плюх даже на бесплатном тарифе. Я бы таки задумался честно говоря.
Ярослав, и действительно, AUser0 дал вполне себе хороший вариант. Если не нужен оверкилл и о ддосе речи не идёт - тогда и правда можно генерить капчу на клиенте. Но тогда как быстро ты вернешься с этим вопросом?)
но, в идеале, злоумышленник должен достаточно быстро увидеть защиту и перехотеть ддосить.
Оооой, это ну оооочень оптимистичный вариант. IMHO такие атаки ставятся "на автомат", и их исполнение ни кто не контролирует, из принципа "а пусть долбят". То есть и подстраиваться на обход защиты тоже скорее всего не будут, IMHO. А кончится она тогда, когда грохнут/сотрут уже саму систему управления этой атакой.
Сложный
Средний
