Взломали хостинг:)

Была очень похожая ситуация, целую кучу сайтов позаражало. Заепались чистить все от этого вируса. В выдачу так же оч много созданных вирусом страниц попало, и еще в чем самый прикол, в индекс страницы созданные вирусом попали быстрее чем основные страницы сайта.

О господи... у вас все сайты были на 1 аккаунте, верно? Взломали 1 сайт, а уж остальные от него "заразились".

выделенный сервер все там...:)

А что в логах? Может от компъютера было заражение, или реально взломали. У хостера логи запросите если они в панели не отображаются - там 90% информации будет видно, что и от куда появилось.

программист копаетцо уже:)

меня вот больше интересует как все это теперь с выдачу убирать оно блин в топе висит и траф идет))

---------- Добавлено 03.07.2014 в 16:16 ----------

сейчас по выдаче полазил неколько сотен сайтов нашел которые ломанули для аналогичных доров:)

если кому интересно в личку могу пример линков кинуть

SSH - процентов эдак 80

Ну дырками пусть занимается специалист по дырках :D В данном случае - программист. А удалить страницы просто - надо отдавать нормальные 404 и 403 ошибки на них.

А ничего что 95% взломов сайтов под доры совершается через сами движки? 😂

Программист ни разу не специалист по дыркам, большая часть программистов просто на просто не знает на что и как смотреть. Этим занимаются специалисты по ИБ, например пентестеры.

не тормозите! лейте на партнерки! :)

Вся соль аналогичных вопросов заключается в том, что далеко не всегда есть возможность выяснить где находится дыра, сейчас попытаюсь пояснить почему:

Выяснить конечно можно но представьте себе путь которым придется это сделать, ведь что получается по сути, вы видите только конечный результат, вам залили какие-то страницы, и вот они лежат, стало быть уязвимость может находится например в одной из функций одного из ваших сайтов, а так же может находится в демоне apache или mysql а еще например может находится в ядре (kernel) вашей системы, каким методом или алгоритмом вы собираетесь проверить все эти точки? Ведь проблемы бывают на столько разные.... К примеру помню баг в драйвере реалтек сетевых карт, при отправке определенного запроса сервер просто отключал сетевую карту.... а может сейчас уже новый баг в одном из драйверов который дает доступ к системе? В общем подход нужен обратно пропорциональный, искать дыры после того как взлом случился.... задача очень сложная и практически не реальная, куда проще искать взломы в момент самих взломов, а именно подготовится к проникновению в вашу систему заранее, что это значит:

1. Ни в коем случае не экономить место под логи, причем любые логи, это могут быть логи веб сервера (причем как access так и error) это могут быть логи mysql query (да их может быть много, однако они отражают все SQL запросы в базу и легко могут быть подвержены ротации). Так же могут быть включены логи PHP.

2. Отдельно стоит поговорить об окружениях в которых работают ваши сайты, если у вас есть возможность!! каждый сайт должен быть изолирован от других, основная проблема виртуальных хостингов заключается в том, что злоумышленники взломав всего 1 сайт получают доступ ко ВСЕМ остальным сайтам на акаунте... базам, настройкам и.т.п По этому если вы владелец VPS или Выделенного Сервера не исключайте изоляцию из настроек, выдавайте каждому сайту свое окружение, создавайте своего пользователя как системного так и для доступа к базам данных.

3. По моему личному наблюдению + небольшому 10 летнему опыту работы в хостинг индустрии, 90% всех взломов происходит с использованием известных уязвимостей в известных движках, ведь согласитесь если вы создали движок сами , поставили его себе на сайт и пользуетесь им исключительно ВЫ, каким бы крутым атакующим не был наш злоумышленник у него нет ни малейшего представления какие функции вы используете, как они построены и какие из них содержат погрешности программирования, это значительно усложняет методики поиска уязвимостей, другое дело когда можно скачать свежую Joomla или WP с оф. сайта и командным орбазом придать жесткому анализу все её функции... найдя уязвимость - под атакуемые машины сразу попадают тысячи, сотни тысяч пользователей сети..... и утекают гигабайты персональных данных и.т.п По этому если у вас есть материальная возможность разработки своего движка для своих сайтов - это огромный бонус!!!

4. Аналитика или с чего начинать: Если вы хотя бы раз смотрели в лог веб сервера , вас должен заинтересовать вопрос, чем же нам помогает этот самый лог, ведь там кроме обращения к конкретному файлу и наверняка подмененному ИП атакующего ничего нет, и от части вы совершенно правы, одним из важных на мой взгляд принципов изучения атак, заключается полное хранение развернутых POST запросов к вашему ресурсу, сделать такой механизм очень не сложно, я покажу самый простой пример, но можно наколдовать и куда поинтересней:

file trace.php:

<?
if (!empty($_POST)) {
$data = var_export($_POST,true);
file_put_contents("/home/user/post.log", $data, FILE_APPEND | LOCK_EX);
}
?>

После чего в php.ini для вашего окружения можно прописать следующее:

Данная конструкция будет записывать в указанный лог файл ВСЕ данные всех POST запросов которые прийдут на ваш виртуальный хост, как правило этот файл дает около 90% результативной информации при выявлении уязвимости, к примеру если через кривой редактор в вашем движке был залит файл то скорее всего в POST логе вы обнаружите содержимое того самого файла, а так же сможете понять куда было произведено обращение и какие параметры передавались в этот момент в POST запросе. Следом эти данные может будет сравнить с данными из sql query log , если были модификации в базе данных - то аналогично будет ясно какие запросы были инициаторами этих самых изменений...

На самом деле это только начало, но без него и говорить не о чем, когда у вас нет логов, когда у вас нет информации по запросам к вашей системе, по переданным в неё данным - искать уязвимость это тыканье пальцем в небо.... Увы, и ах, но это именно так. Обычно в таких случаях "умники" сразу смотрят версии продуктов и если они не актуальны то все лечение заключается в установке последней версии вашего движка, однако по прежнему нет никакой ясности в том, являлось ли это причиной проблемы....

С радостью проконсультирую или отвечу на доп. вопросы лично.