Пр-р-р, вот вы меня разочаровали в гугле еще больше. Да и ладно это было бы багом, которым кто-то пользуется. Но судя по всему гугл в курсе этого и забивает на это ...
Просто опишу неплохой вариант, если у Вас есть желание съэкономить деньги, но вникнуть в тему самому.
К сожалению, при ддосе наших новостных порталов и казиношных сайтов, мы судорожно искали хороших и надежных "защитников". Сам я ведущий программист в этой конторе. Я хорошо разбираюсь в веб-программировании, и серверах в том числе, но как-то не видел реальным сдерживать нагрузку в 5-10 гб/сек(на некоторых провайдерах это засерало практически весь наш канал). Хорошая фирмочка была зарубежная, они до 15гб/сек ддоса прикрывали на ура, но стоило 7-10 тыс$ в месяц. Все услуги по защите от ддоса, предоставляемые хостинг-провайдерами, в том числе и рег.ру, достаточно слабенькие и падений сайта вызывают порой сами(или просто блокируют загрузку статики, что делает сайт вроде рабочим по их данным, но совершенно не читаемым со стороны клиентов).
Итак, решение.
Если ддос в районе 5-10гбит/сек, то берем сервер(выделенный или виртуальный - не важно), смотрите, чтобы процессор был пошустрее, оперативки поболее, диск - пофиг, но лучше, если БД будет на ssd или быстром hdd.
Я надеюсь, что раз Вы сталкиваетесь с ддосом и большими нагрузками(тем более большой магазин), то уже отказались от апача и используете более гибкую и производительную связку nginx+php-fpm.
Сразу скажу, что не буду писать все названия параметров, ибо когда начнете вникать по тому, что написал(если дочитаете хотя бы до конца), то без труда найдете всё для своих версий ПО на оф. сайтах. У кого берем сервера тоже не буду говорить, чтобы не сочли за рекламу.
Итак, в nginx ограничиваем размер тела запроса пользователя, кол-во запросов с одного айпишника в секунду. Nginx расскидывайте по ядрам процессора из расчета 2 процесса на ядро(играйтесь с этим конечно сами).
Отсекайте сразу все запросы, у которых http_referrer пустой, либо не начинается с "http(s)?://".
Также стоит глянуть неправильные/подозрительные юзер-агенты. Если в логе запросов такие имеются, то тоже их отсекайте.
При отсеивании выдавайте ОБЯЗАТЕЛЬНО хттп-ошибки(403 или еще какую). Если будете сбрасывать внутренней ошибкой 444, то боты будут тут же снова коннектиться. Если бот будет часто натыкаться на 403, то поймет, что спалился и его снимут с очереди долбежки к Вам и подключат к атаке следующий комп.
Увеличьте кеши запросов к БД, причем очень желательно, чтобы кеш хранился не на диске, а в оперативке. Иначе, если диск не ssd, то база данных серьезно будет тормозить работу всего сайта.
Если есть скрипты со сложной логикой, то ограничьте время их выполнения, а лучше уже отрендеренный результат кешируйте снова в оперативку. Иногда бывает сложно подключить кеш рендера кода, тогда просто ограничьте время исполнений скрипта и пожираемые им ресурсы. Пусть лучше 1(возможно и не бот) клиент получит ошибку, чем подвесит сайт. Ресурсы и время на скрипт прописываются в php.ini, так же на уровне php-fpm и также прямо в скрипте можно вроде переопределить.
Поставьте на фронтенд днс сервис cloudflare, он на себя возьмет некоторую нагрузку по отдаче статики. Если его подключите, то поменяйте айпи сервера, чтобы не ддосили Вас на прямую.
Не палите свой айпи в почтовых рассылках, рассылайте через какой-нибудь почтовый сервис или маленький отдельный сервачок.
Не увлекайтесь блокировкой по айпи в фаерволе(типа iptables), иначе сам фаервол будет сильно тормозить.
Применив это, новостной портал с нагрузкой в 60тыс уников в день держал ддос примерно месяц. Иногда подтормаживал сайт, но рендер был в пределах 1,5-2 сек. За месяц ддоса он ниразу не упал по причине ддоса, только когда в коде делали ошибки (у кого не бывает ... :))
Напоследок случайная находка(не сочтите за рекламу).
Просто оооочень удивил нас Амазон, когда используя его инфраструктуру разместили туда казиношные сайты. И теперь внимание !!! Продержал атаку в 56гбит/сек 😮. Мы все были просто в шоке. Счет за месяц, в котором был ддос, составил около 2тыс$, что просто пипец как мало в такой ситуации.
Вывод:
Если вникнуть, то вполне можно без особых усилий защититься от большинства ддос-атак самому. Достаточно правильно организовать инфраструктуру для проекта и писать качественный код, отдавая отчет какая часть кода какое железо будет грузить(проц, оперативу, диск и т.д.).
Всего хорошего и поменьше атак на Ваши проекты! :)
AdSense это делать точно не будет.
Начните проверку по ходу запросу:
1. Сперва проверьте уровень веб-сервера. Если используете шаред-хостинг, то наверняка стоит апач с поддержкой .htaccess. Проверьте содержимое этих файлов, там обычно в самом конце через много пустых строк будет редирект на партнерки.
2. Проверьте файл index.php в корневой папки с сайтом, посмотрите там тоже редиректы.
Наверняка уже на первом шаге всё нашли, если нет, то на втором точно :) Если всё ровно не нашли, то нужно глубже анализировать весь поток запроса и проверять где редирект прописан. Это уже Вам самому будет сложно сделать.
