Вижу один нормальный вариант:
http://www.mikeyboldt.com/configure-htaccess-to-use-fastcgi-for-php/
Будет и FastCGI и в пределах каждого сайта.
Меняем лишь в .htaccess строку
на
либо
и т.п..
И в самом скрипте (php52-fcgi, php53-fcgi) на пути к cgi-бинарникам с нужной версией.
Не проблема в следующий раз написать YandexBot
Потом Яндекс заблокируете?
Это совсем не решение.
Значит не такой уж известный, раз наши клиенты, владельцы от небольших до крупных интернет-магазинов его не используют :)
Но всякое бывает, я соглашусь. Пока не сталкивались.
Я за вас все ip проверять не буду =)
Если они не принадлежат вам и вашему серверу, то можете ещё вбить их по очереди в https://www.nic.ru/whois/ и проверить, кому они принадлежат.
Если это не поисковые боты и тем более с неизвестных стран, то блокируйте.
Здесь, к сожалению, я больше ничего подсказать не могу.
Судя по всему это действительно атака, потому как представляется ботом Гугла, но 177.129.214.45 никакого отношения к нему не имеет.
Запустите команду. Покажет список для блокировки. Проверьте, чтобы случайно ip-адрес вашего компьютера или сервера туда не попал.
Если всё, ок, то запустите:
Заблокирует всех, с которых больше 5 подключений к web-серверу.
Если случайно заблокируете реального посетителя, то можно разблокировать командой:
Если безопасность важна, то лучше обратитесь к специалистам.
Никто ко всему серверу доступ по подобным протоколам не даёт. Это не безопасно, да и стандартным образом не получится (настройки программ тоже продуманы, чтобы не удалось сделать подобных бессмысленных действий)
Я думаю, что лучше не стоит вам настраивать блокировки, потому как не до конца понимаете, что такое netstat -ntu и её связь с посещаемостью.
3 подключения по netstat - это не так много на самом деле.
Не проще смотреть логи сайта, на который идёт атака?
У нас тоже на серверах, которые настраивали пару лет назад, до сих пор mpm-itk работает.
Во-первых, эта сборка сама по себе ресурсоёмкая. Кроме того, имеет проблемы с сегфолтами в связке с различными модулями. Если настроить и ничего не трогать, то реально заставить работать. Но при изменениях (версии экстеншенов php, различные дополнительные модули) проблемы возникают периодически.
После пары лет в использовании на высоконагруженных хостинговых серверах сделали однозначный выбор в пользу FastCGI. При грамотном тюнинге даёт отличную производительность (выше, чем mpm-itk), меньше потребляет ресурсов (всё-таки отдельные процесссы apache "прожорливее", чем cgi), позволяет без проблем использовать несколько версий php, наборы модулей, отдельный php.ini (без "костылей", а прямо в связке с панелями управления).
Так же запросто работают ограничения ресурсов и т.п.
У mpm-itk всё это либо не реализовано, либо реализовано частично или через "костыли".
Всякие nginx + php-fpm и прочие варианты даже не рассматриваем. Это всё в виде индивидуальных решений, но никак не для общего использования с панелями управления.
P.S.: И за всё время использования столкнулись только с одной ситуацией, где на FastCGI пришлось делать изменения в коде - это http-авторизация в php-скрипте. Но небольшие изменения всё решили. Больше случаев, где отказ от mod_php создал проблемы, не припомню.
И это минус? FastCGI вполне отлично себя показывает.
Про mpm-itk я бы даже не стал говорить. Очень не стабильная и медленная сборка.
Панель добавляет свою маску. Скорее всего из-за нее.
