|
|
09.11.2018, 09:35
|
|
Gvenv_nk
Наталья Комарова
Зарегистрирован:
2011-11-07
Сообщений: 43
|
Здравствуйте! Надеюсь, кто-то из бывалых товарищей сталкивался с такой бедой и сможет дать нам совет.
Суть проблемы в следующем.
После выходных, а может и раньше, но клиент обратил на это внимание только 5 ноября, на сайте начались проблемы с шаблонами компонентов. Выглядит это так: пользователи размещают новость, сайт начинает тормозить, потом снова загружается, но со сломанным html.
А именно: захожу на главную страницу и вижу, что она вся расползлась из-за кучи незакрытых дивов. Нахожу сломанные компоненты, лезу в код и вижу, что (далее возможны варианты): отсутствуют закрывающие теги в суффиксе, или, наоборот, пустой префикс, а в суффиксе все на месте, или вообще отсутствует какой-либо код в компоненте. При том, что еще несколько минут назад там все было в порядке, работало корректно, проходило валидацию.
У клиентов доступа к компонентам нет, возможность форматирования в текстовых полях отрублена, вообще есть права только на редактирование отдельных разделов. Никто все это время никаких шаблонов на сайте не правил, шла только текущая работа - размещение новостей, документов, ну еще народ обращался на сайт через форму обратной связи, пользователи обращались к поиску - все, как всегда.То есть человеческий фактор - живой вредитель из числа авторизованных пользователей - исключается.
Проверили сайт антивирусами - сразу несколькими онлайн сервисами + свежий бэкап прогнали через айболит. Итоги: гугл и яндекс пока молчат, Dr.Web ничего не обнаружил, 2ip.ru пишет, что на сайте обнаружены iframe-вставки, ссылающиеся на сомнительные сайты либо обфусицированный код (вопрос: где и как их искать?). Техподдержка хостинга тоже проверила антивирусом и ничего не нашла.
Поменяли пароли, доступ к базе, фтп, ssh. Все скрипты, на которые ссылались макеты дизайна, заменили на чистые (скачали заново из источников). После подключения к базе с новым паролем сайт надолго ушел в астрал (502 ошибка), потом очнулся весь покореженный - упало несколько инфоблоков, выводящихся на главную страницу. В очередной раз я все починила, пока работает (до следующего раза).
Видимо, дело идет к тому, чтобы поднимать все это хозяйство из бэкапа недельной давности. А проблема в том, что это сайт муниципального образования, они в течение дня размещают на нем очень много контента и ежедневно отсылают отчеты о проделанной работе (со ссылками на публикации) в вышестоящие инстанции. Восстанавливать все это будет страшным гемором. А самое ужасное, что мы можем все это поднять, восстановить, затратив кучу усилий, а потом все начнется снова. Т.е. хотелось бы все-таки поставить диагноз, прежде чем приступать к ампутации.
В логах я своим плохо вооруженным глазом обратила внимание на следующий момент:
GET /wp-login.php?action=register HTTP/1.0 (т.е. кто-то пытается авторизоваться на сайте через вордпресс? или как еще это понимать? и каждый раз с разных ip-адресов??)
В общем, вопрос: можно ли каким-то образом вычислить источник зла, найти и обезвредить? Может, в вашей практике такое уже случалось?
В техподдержку тоже написала, жду ответа.
Заранее благодарна за помощь.
Наталья Комарова
|
|
|
09.11.2018, 18:26
|
|
Алексей
Алексей Царапкин
Зарегистрирован:
2011-11-16
Сообщений: 32
|
Все верно - надо искать вредоносный код.
Для начала установите последнее обновление системы, если не установлено и сделайте бэкап.
Если проблема не исчезнет, то скачиваем систему той же редакции, что и у вас.
Дальше отрываем в meld скачаную с нетката и вашу систему (которая должна быть обновлена до последнего патча), ищем несоответствия.
Если проверка системных файлов не принесла результата следует начать проверять код своих компонентов и макетов.
Проанализировать слабые места. Проверить используются ли где то прямые SQL запросы, и как в них передаются переменные, если передаются.
Проверьте формы, если это не формы компонентов, то как в них происходит обработка данных, есть ли фильтрация, проверяются ли файлы по MIME типу.
Проверьте компоненты, везде ли указан правильный формат полей типа "файл" и "множественная загрузка" и указан ли вообще.
Так же стоит проверить есть ли на сайте AJAX запросы и какие данные в них передаются, есть ли проверка этих данных на стороне сервера.
Пишутся ли какие-то файлы (временные или постоянные), что и как туда пишется, проверяются ли входные данные.
Стоит обратить пристальное вникамие на то используются ли какие то сторонние библиотеки и если используются, то какие, погуглить уязвимости этих библиотек.
Это в общих чертах.
Цитата:А проблема в том, что это сайт муниципального образования, они в течение дня размещают на нем очень много контента и ежедневно отсылают отчеты о проделанной работе (со ссылками на публикации) в вышестоящие инстанции.
Если это школа, пту или вуз - источник проблем можно устранить, например, отчислив всех студентов, а в первую очередь, студентов IT направления. Я сам был таким студентом, так что знаю о чем говорю.
Хотя честно говоря, я бы таких студентов наоборот поощрял бы и привлекал к работе над проектом, давая возможность реализовать свой потенциал в правильном русле.
Если сами не справитесь - пишите на почту или в Telegramm.
Правда с гос конторами я работаю на особых условиях, которые не подлежат обсуждению, но они не страшные.
Решаю нестандартные задачи
|
|
|
10.11.2018, 17:35
|
|
Руслан Густокашин
Студия Вэлпис
Зарегистрирован:
2012-02-06
Сообщений: 962
|
Да, сталкивался с подобным поведением.
План решения проблемы такой:
1. Проверить свободное место на хостинге, достаточно ли его.
2. Посмотреть на размер БД, не превышает ли он разумные пределы и не превышает ли разрешенный хостером лимит.
3. Проверить, не превышает ли ваш сайт разрешенную хостером нагрузку. Но это актуально в случае, если у вас обычный виртуальный хостинг, а не VPS или "железный" сервер.
4. Проверить, нет ли в админке такого пользователя, которому назначены права супервизора или директора. Речь идет не о членстве в группе Администраторов, а именно о назначении прав во вкладке "Права".
Если это все не откроет причину сбоев, тогда дополнительно:
5. Делаем проверку и лечение уязвимостей кода и бэкдоров силами опытного "вирусолога".
6. Смотрим логи MySQL сервера, нет ли там ругани насчет того, что какая-то из таблиц упала
Все это делать нужно на Netcat свежей версии. Если версия ниже 5.6, то, конечно, срочно обновлять и потом обязательно лечить (см.п.5), потому что Неткэт более ранних версий имел серьезные уязвимости.
Можем выполнить весь комплекс этих работ по договору, гарантийный срок 1 год. Если что-то снова упадет - будет на нашей ответственности. 
|
|
|
11.11.2018, 20:40
|
|
Gvenv_nk
Наталья Комарова
Зарегистрирован:
2011-11-07
Сообщений: 43
|
Здравствуйте, Алексей и Руслан, огромное спасибо вам за подробные рекомендации. Примем к сведению и постараемся реализовать. Хотя кое-что пытаемся делать сами.
Постараюсь ответить по порядку, сначала Алексею:
1. Последнее обновление установлено, полный бэкап есть.
2. С Linux и meld я совсем не дружу, являясь блондинкой по сути своей (((, но передам этот совет администратору сервера, обслуживающему сайт, он попробует провести такой сравнительный анализ.
3. а вот код макетов и компонентов как раз сейчас перепроверяю, нахожу и исправляю уязвимости.
4. до форм и AJAX запросов пока руки не дошли, но - да, будем проверять, конечно же.
5. поля типа файл тоже перепроверю, там кое-где формат реально не указан.
6. сторонние библиотеки заменены на чистые, заново скачанные с оф. сайтов.
7. это сайт администрации поселения Московский (ТиНАО), где только что прошли выборы, но политическая борьба там кипит такая, что мировая политика отдыхает.
Руслану:
1. На хостинге места достаточно, БД лимит не превышает.
2. Пользователь с правами директора на сайте только один, остальные - редактора разделов. Но: админский пароль знал сотрудник, который как раз недавно уволился со скандалом. Другое дело, что пароли и явки я периодически меняю в целях профилактики, и как раз недавно, перед тем как началась вся эта хрень, доступы в админку, к панели хостинга, фтп, базе и т.п. были обновлены.
3. Вирусологи (уж не знаю, насколько опытные - например, хостеры ру.центра, ТП Неткэт, наш администратор сервера) перепроверили сайт каждый своими методами и ничего устрашающего не обнаружили. Техподдержка неткэта еще перелопатила системные файлы - и тоже ничего.
4. Логи MySQL будем смотреть, спасибо за совет.
При этом сами мы обнаружили у себя на сайте явные признаки DDoS-атак. Происходит это несколько раз в день, как по расписанию: обычно первый всплеск активности происходит ночью, второй - часа в 3 дня. После каждой бомбардировки что-нибудь слетает в коде шаблонов. После того как наш сисадмин вычислил диапазон атакующих ip-адресов и забанил их в .htaccess, а я по возможности вычистила код компонентов, разрушения стали менее заметными. Сегодня последняя атака была ночью, день (боюсь сглазить) прошел спокойно.
Короче, мы обязательно примем к сведению ваши советы, а у нас, в свою очередь, назрел вопрос: не поменять ли хостинг-площадку? Nic.ru, в частности, не оказывает услуг по защите, надо для этих целей приглашать специально обученных товарищей за дополнительные гонорары. Рассматриваем reg.ru. Как думаете, есть ли в этом смысл, и если да, то кого посоветуете?
И да, возможно, нам придется обратиться к вам за профессиональной помощью, но сначала мы должны обсудить вопрос оплаты с руководством. В общем, сегодня-завтра понаблюдаем за тем, как будут развиваться события.
Наталья Комарова
|
|
|
12.11.2018, 13:51
|
|
Алексей
Алексей Царапкин
Зарегистрирован:
2011-11-16
Сообщений: 32
|
Цитата:2. С Linux и meld я совсем не дружу, являясь блондинкой по сути своей (((, но передам этот совет администратору
meld - по сути текстовый редактор, наверняка есть версия для win ну или аналоги. Просто он умеет сравнивать и показывать различия сразу по каталогам, а не отдельными файлами.
От DDOS можно закрыться CDN сервисами например. CloudFlare, или уже встроеный в систему Айри
Решаю нестандартные задачи
|
|
|
12.11.2018, 15:16
|
|
Gvenv_nk
Наталья Комарова
Зарегистрирован:
2011-11-07
Сообщений: 43
|
Ага, спасиб, загуглю, будем осваивать. Удачи Вам!
Наталья Комарова
|
|
|
13.11.2018, 21:56
|
|
yatanson
yatanson
Зарегистрирован:
2012-07-16
Сообщений: 6
|
Такая проблема у меня встречалась только с одним сайтом, он на nic.ru. Также приходилось восстанавливать шаблоны компонентов. После обращения в тп хостинга по этому вопросу, был похожий сбой, который чудесным образом самоустранился, хотя тп писала что не нашла причину сбоя.
yatanson
|
|
|
19.11.2018, 11:52
|
|
trevor
Зарегистрирован:
2018-08-23
Сообщений: 20
|
Столкнулся с подобной проблемой. Вообще не знал,что делать и где искать причину. Спасибо вам за советы, помогли все вернуть в прежнее состояние
Продвижение сайта
|
|
|
01.12.2018, 22:39
|
|
URLVir
URLVir
Зарегистрирован:
2018-12-01
Сообщений: 3
|
* wp-login.php в логах норма, обычно так боты сканируют на уязвимости, сканируют практически любой сайт. Это не зависит от движка.
* Использование iframe не является чем то плохим) Да бывает вредоносный код, но это может быть даже видео
*айболит не панацея, нужно уметь его результаты анализировать. Очень часто клиенты видят крупный список якобы заражённых файлов, которые таковыми не являются.
* Не нужно отчислять студентов, более чем уверен что они не виноваты.)
Если есть вопросы, спрашивайте тут или пишите на почту - web@urlvir.ru . Отвечу.
URLVir.ru - срочное лечение и защита сайтов - web@urlvir.ru
|
|
|
01.12.2018, 23:07
|
|
URLVir
URLVir
Зарегистрирован:
2018-12-01
Сообщений: 3
|
От Ddos не может слетать код) Ddos атаки направлены на стабильность сервера) А у Вас похоже виртуальный хостинг под контролем nic.ru (хочу заметить, хотсинги напрямую не предоставляют защиту, их обязанность обеспечить стабильную работу сервера и безопасность серверного ПО, защиту от Ddos обычно предлагают как отдельную услугу) Если у Вас VDS, то это уже другой вопрос
Цитата:.
После того как наш сисадмин вычислил диапазон атакующих ip-адресов и забанил их в .htaccess, а я по возможности вычистила код компонентов, разрушения стали менее заметными. Сегодня последняя атака была ночью, день (боюсь сглазить) прошел спокойно.
Что именно Вы вычистили? Тут либо Вы не совсем верны в терминах, либо немного ошибаетесь в причинах поломок.
Как мне кажется, Вы рано бьёте тревогу. Если два специалиста посмотрели сайт и не нашли живых вирусов, а обычно их видно явно. То всё у Вас хорошо. Из личного опыта, Netcat в заказах бывает очень редко, в плане безопасности (при условии свежих обновлений) у неё всё хорошо.
URLVir.ru - срочное лечение и защита сайтов - web@urlvir.ru
|
|
|
01.12.2018, 23:09
|
|
URLVir
URLVir
Зарегистрирован:
2018-12-01
Сообщений: 3
|
А вот это уже интересно) Опыт работы с поддержкой nic.ru и с ветренными косяками на их оборудовании, сталкивался не один раз))) Может они какие либо обновления делают на виртуальном хостинге (ПО), от сюда и идут проблемы с отображением кода. Модуль какой отключили или просто глючит.
URLVir.ru - срочное лечение и защита сайтов - web@urlvir.ru
|
