Обнаружили, что на сайт атакуют с помощью обычных post-запросов с CURL.
При этом что происходит?
Слетают все стили. Отображается только голый html как в админке, так и во фронтенде.
Мы нашли скрипт на одном из форумов(от туда мы узнали, что наш сайт атакуют). А также мы просмотрели логи сервера и обнаружили, что есть ip, которые делают по несколько тысяч запросов в час.
Мы знаем, какой контроллер и мод атакуют. Но ведь с тем же успехом можно атаковать вообще любой контроллер.
Также мы закомментировали код контроллера, но это не помогло.
Полагаю, речь идёт об обычном HTTP DoS, а не уязвимости. Со стороны веб-сервера можно ограничить как доступ к сервису для конкретного IP-адреса или подсети, так и защитить отдельные контроллеры. Кроме того, в некоторых веб-серверах (например, в NGINX) вы можете ограничивать интенсивность запросов в т.ч. на конкретные URL с нужных адресов.
Из наиболее радикальной стратегии защиты — блокировка IP-адресов в фаерволе. Если вы затрудняетесь применить эти техники самостоятельно, напишите на sales@simtechdev.com и мы поможем вам справиться с этой проблемой.
Через curl просто отправляют post запрос на index.php, передается controller, mode и пара переменных. И это вся логика атаки!
Но тем не менее они смогли порушить функционирование сайта. Т.е. стили перестали подгружаться.
1) ограничить доступ к конкретному айпи - не вариант, потому что мы не знаем конкретных IP. они могут быть какие угодно
2) ограничить интенсивность запросов?
мы посмотрели в логи и вычислили, что активность запросов была совсем низкая. Около 2-3 запросов в секунду. Это для DDoS крайне мало. Поэтому мы и не можем установить интенсивность. Этот вариант возможен, но тоже сомнительный.
Думаю насчет ограничения запросов с других доменов к этому контроллеру. Можно это сделать?
Я пробовал закомментировать код моего контроллера, на который отправлялись запросы. Тем не менее сайт все-равно падал. Видимо атака влияла еще до работы моего контроллера.
Можно вручную сделать доступ к контроллеру по определенному токену(с input type="hidden"), но все-равно врядли спасет.
Во-первых, задуматься об увеличении ресурсов для вашего сервера, поскольку 2-3 RPS – это очень маленький запас по производительности. Во-вторых, убедитесь, что это не поисковые роботы (их интенсивность можно задать в robots.txt). В-третьих, можно самому составить стратегию защиты, чётко сформулировав правила атаки:
а) Если атакуют с разных IP-адресов, то ограничиваем интенсивность с одного IP-адреса до приемлемого.
б) Если можно правилом на веб-сервере локализовать атаку, то можно применять ограничения для конкретных локейшенов.
в) Если у атакующих подставной и уникальный User-Agent, то можно блокировать по этому заголовку.
г) ...
Целая масса вариантов, многое зависит от самой атаки. Приложите к задаче access-лог за 5 минут, попробуем вместе проанализировать.
Коллега немного не правильно сформулировал проблему. Сервер нормально выдерживает и гораздо большее количество запрос. Проблема в том что, если кеш был очищен, т.е файлы less не были скомпилированы, то при частых запросах к сайту файл стилей просто не создается, его нет в файлах кеша, но при этом в шаблоне путь к файлу есть. Соответственно сайт отображается без стилей.
Коллега немного не правильно сформулировал проблему. Сервер нормально выдерживает и гораздо большее количество запрос. Проблема в том что, если кеш был очищен, т.е файлы less не были скомпилированы, то при частых запросах к сайту файл стилей просто не создается, его нет в файлах кеша, но при этом в шаблоне путь к файлу есть. Соответственно сайт отображается без стилей.
Полагаю, если вы хотите избежать этой проблемы, вам придётся «прогревать» кеш заранее. Например, вы можете составить список URL на основе sitemap, дополнив нужными, и проходиться cURL после каждого сброса кеша перед запуском сервиса в эксплуатацию. Несколько лет назад решал похожую задачу для разворачивания русскоязычных демо-магазинов.