Довольно часто бывает, что размещая статьи или ссылки - люди ставят на них входящие ссылки, чтобы их статья не затерялась в недрах многостраничников. Уберете такие статьи - отвалится часть входящих ссылок на ваш сайт.
Если размещали не глядя левое, то понятно, что в сад. Если среднее, то можете сделать чтобы эти статьи не сильно мозолили глаза в навигации по сайту, а сами статьи пусть живут.
Можно поробовать между nginx и апачем включить HTTP 1.1 Строка в конфиге nginx:
proxy_http_version 1.1;
Можно еще настроить между ними keepalive... но проще с ним не заморачиваться
как-то не догадался, что в шаред хостинге могут быть такие вопросы.. по шареду - никак.
можно прописать в файле /etc/my.cnt
[mysqld]bind-address = 127.0.0.1
и перезапустить mysql
Попробуйте посмотреть в сторону CDN.
На крайний случай можно самим разбросать траф на десяток самых дешевых вдсов, сделать типа самодельного CDN-на...
/etc - в .tgz, чтобы ничего не забыть. на новом хостинге руками вытащить и переложить несколько нужных конфигов. не вздумайте перезаписывать etc полностью.
базы - дамп.sql.gz --> restore
файлы - rsync в обертке ssh
Все уже написано до нас. (с) не я
Лень и работа напильником - вот наш удел. :)
Можно прицепить что-то типа snort-а (со времен фрибсд 4.1 не пользовался им), но лениво...
Можно использовать то, что уже стоит на хостинге nginx(перловые хуки) или apache+mod_... (давненько еще на apache 1.3 делал на mod_filter, он использовался для других целей, но среди прочего он успешно ловил шелы, эксплоиты и т.д.)
Конкретно, для этого топика, я бы предложил суммарные логи бекенда завернуть в трубу (заметку не читал, первая из гугля), статику фильтровать нет смысла - пусть nginx ее отдает как и раньше или с диска или из кеша.
В трубе считаем количество плохих запросов для каждого ip в единицу времени, т.к. скрипт один можно все хранить в переменной в раме (не забывая раз в пару минут зачищать не нужные значения). Если взаимодействовать нескольком скриптам, то в /dev/shm.
Когда предел плохости достигнут или баним на сутки ip через iptables(лениво..) или учим nginx сразу отшивать этот ip-шник (что-то типа try_files).
Ну как-то так.
Значит решение задачи очень сильно упрощается. Сейчас взлом поставлен на поток и идет на автомате, посмотрите логи своего вебсервера, чтобы убедиться в этом.
Перекроете этот поток, направленный на WP - решатся все ваши проблемы.
Глядим логи, собираем на коленке IDS на 80-м порту, пишем правила, мониторим, исправляем, мониторим... спим намного спокойней. Защищить нужно сразу весь хостинг, а не париться с каждым отдельным инсталом, тогда количество клиентов не играет никакой роли.
Вторым этапом, когда появится время, пишем сканер уязвимостей WP и поиск шелов. Кстати шелы можно выявлять и давить на первом этапе.
Вот примерно такое направление движения.
в общем случае: 1 маска = 1 строке в .htaccess
можно еще поиграться таким вариантом
RewriteRule ^(go|run|jump|drink|sex|sleep|happy)/$ index.php?act=$1 [L] RewriteRule ^(go|run|jump|drink|sex|sleep|happy)/(.+)$ index.php?act=$1&to=$2
.
...представляю, поэтому я не использую построение ЧПУ через .htaccess
RewriteRule ^go/(.+)?$ index.php?act=go&to=$1
попробуйте так:
RewriteRule ^go/$ index.php?act=go [L] RewriteRule ^go/(.+)$ index.php?act=go&to=$1
