Шкідливі скрипти. Шукаємо та прибираємо шкідливий код на WordPress. Знешкодження серверних скриптів

WordPress – одна з найпопулярніших систем управління контентом, що використовується в різних цілях: від ведення блогів до електронної комерції. Існує широкий вибір плагінів і тем для WordPress. Трапляється, що якісь з цих розширень потрапляють до рук вебмайстрів після того, як зловмисник попрацював над ними.

Заради своєї вигоди він міг залишити в них рекламні посилання або код, за допомогою якого він керуватиме вашим сайтом. Багато користувачів WordPress не мають великого досвіду у програмуванні і не знають, як діяти в такій ситуації.

Для них я зробив огляд дев'яти найбільш ефективних інструментів для виявлення шкідливих змін у коді працюючого сайту або додатків, що встановлюються.

1. Theme Authenticity Checker (TAC)

Theme Authenticity Checker (інспектор автентичності тем, TAC) - WordPress - плагін, який сканує кожну встановлену темуна наявність підозрілих елементів на зразок невидимих ​​посилань або коду, зашифрованого за допомогою Base64.

Виявивши такі елементи, TAC повідомляє про них адміністратор WordPress , дозволяючи йому самостійно проаналізувати і при необхідності виправити вихідні файли тем:

2. Exploit Scanner

Exploit Scanner сканує весь вихідний код вашого сайту та вміст бази даних WordPress на наявність сумнівних включень. Так само, як і TAC, цей плагін не запобігає атакам і не бореться з їх наслідками в автоматичному режимі.

Він лише показує виявлені симптоми зараження адміністратору сайту. Якщо ви бажаєте видалити шкідливий код, доведеться це зробити вручну:

3. Sucuri Security

Sucuri - добре відоме рішення в галузі безпеки WordPress. Плагін Sucuri Security здійснює моніторинг файлів, що завантажуються на WordPress-сайт, веде власний список відомих загроз, а також дозволяє віддалено просканувати сайт за допомогою безкоштовного сканера Sucuri SiteCheck Scanner. За абонентську платуможна додатково зміцнити захист сайту, встановивши потужний екран мережі Sucuri Website Firewall :

4. Anti-Malware

Anti-Malware – плагін для WordPress, який здатний знаходити та видаляти троянські скрипти, бекдори та інший шкідливий код.

Параметри сканування та видалення можуть бути налаштовані. Цей плагін можна використовувати після безкоштовної реєстрації на gotmls.

Плагін регулярно звертається до сайту виробника, передаючи йому статистику виявлення зловредів та отримуючи оновлення. Тому якщо ви не хочете встановлювати на свій сайт плагіни, що відстежують його роботу, то вам варто уникати використання Anti-Malware:

5. WP Antivirus Site Protection

WP Antivirus Site Protection - це плагін, що сканує всі файли, що завантажуються на сайт, у тому числі WordPress -теми.

Плагін має власну базу сигнатур, що автоматично оновлюється через мережу. Він вміє видаляти погрози в автоматичному режимі, сповіщати адміністратора сайту електронній поштіі багато іншого.

Плагін встановлюється та функціонує безкоштовно, але має кілька платних доповнень, на які варто звернути увагу:

6. AntiVirus для WordPress

AntiVirus для WordPress – простий у використанні плагін, який здатний здійснювати регулярне сканування вашого сайту та надсилати сповіщення про проблеми безпеки електронною поштою. Плагін має «білий список», що настроюється, та інші функції:

7. Quterra Web Malware Scanner

Сканер від Quterra перевіряє сайт на наявність уразливостей, впроваджень стороннього коду, вірусів, бекдорів тощо. Сканер має такі цікаві можливості, як евристичне сканування, виявлення зовнішніх посилань.

Базові функції сканера безкоштовні, у той час як деякий додатковий сервіс обійдеться вам у $60 за рік:

8. Wordfence

Якщо ви шукаєте комплексне вирішення проблем безпеки вашого сайту, зверніть увагу на Wordfence.

Цей плагін забезпечує постійний захист WordPress від відомих типів атак, двофакторну автентифікацію, підтримку «чорного списку» IP-адрес комп'ютерів та мереж, що використовуються зломщиками та спамерами, сканування сайту на наявність відомих бекдорів.

Цей плагін безкоштовний у своїй базовій версії, але має преміум-функціонал, за який виробник запитує скромну абонентську плату:

9. Wemahu

Wemahu здійснює моніторинг змін у коді вашого сайту та пошук шкідливого коду.

База даних, на основі якої ведеться виявлення зловредів, поповнюється методом краудсорсингу: користувачі поповнюють її, відправляючи результати сканування заражених інсталяцій WordPress на сайт автора плагіна. Плагін також підтримує надсилання звітів електронною поштою та інші корисні функції.

Необхідно виконувати спільно. Якщо усунути початкову причину злому (наприклад, вразливість у розширенні CMS), але не видалити всі шкідливі файли, зловмисник зможе знову отримати доступ до сайту, скориставшись одним зі своїх скриптів. Якщо ж видалити всі завантажені шкідливі скрипти, але не усунути причину злому, зловмисник зможе повторно зламати сайт та знову завантажити на нього скрипти.

Виконувати роботу з видалення шкідливих скриптів та проводити аналіз причин злому повинен фахівець із відповідними знаннями та досвідом :

  • Для видалення шкідливих скриптів необхідне знання мови програмування PHP, а також знання «зсередини» популярних CMS (Joomla, WordPress тощо) та розширень для них. Ці знання потрібні, щоб відрізнити скрипти безпосередньо CMS та її розширень від сторонніх файлів, а також щоб при зустрічі із сумнівними скриптами мати можливість однозначно визначити, які дії вони виконують.
  • Для аналізу причин злому потрібен досвід адміністрування сервера. Це необхідно для аналізу стану файлів на обліковому записі, часу їх зміни, а також для зіставлення цих даних із журналами сервера для визначення, які саме дії зловмисника призвели до злому сайтів.

Тому якщо ваш сайт виявився зламаний, рекомендується, щоб уникнути повторних зламів, не виконувати роботу самостійно, а звернутися до фахівця, який здійснить необхідну діагностику та порекомендує або виконає необхідні діїдля вирішення проблеми, який зможе дати гарантію якості отриманого результату.

Тим не менш, існує низка заходів, які в деяких випадках допомагають відновити безпечну роботу сайту без спеціальних знань. Обмеженням наведеного нижче способу є те, що для відновлення роботи сайту потрібна наявність його резервної копії, створеної на момент до зламування. Якщо дата злому невідома, можна спробувати застосувати цей спосіб, використовуючи найранішу резервну копію наявних. Другим обмеженням, як наслідок з першого, є те, що після відновлення сайту будуть втрачені дані, додані на сайт після створення резервної копії, що відновлюється (наприклад, нові статті, зображення або документи). Якщо потрібно відновити роботу сайту, зберігши нові дані, необхідно звернутися до фахівця.

Ці заходи не дозволяють встановити причину злому сайту, проте кожна з них спрямована на усунення однієї з потенційних причин проникнення. Так як точна причина злому невідома, необхідно виконати їх усі. Дії розташовані в такому порядку, щоб спочатку повністю виключити можливість продовження діяльності зловмисника на сайті або акаунті хостингу теперішній момент, після чого попередити проникнення зловмисника на сайт у майбутньому

Наведені нижче дії припускають, що на вашому обліковому записі хостингу знаходиться лише один сайт . Якщо на обліковому записі розташовується кілька сайтів, то вони також могли зазнати злому, і сайт міг бути зламаний через них. Необхідно або перенести сайт, з яким проводяться відновлювальні роботи, на окремий обліковий запис, або проводити відновлення для всіх сайтів, розміщених на обліковому записі, одночасно.

Черговість дій важлива, тому необхідно виконувати їх у тому порядку, де вони розташовані нижче.

  • Відразу після виявлення злому сайту необхідно повністю заблокувати доступ відвідувачів до нього . Це, по-перше, завадить зловмиснику вести шкідливу діяльність на сайті, а по-друге, не дозволить йому перешкоджати проведенню відновлювальних робіт. Цей крок дуже важливий, оскільки видалення шкідливих скриптів та усунення причини злому не відбувається одномоментно - як правило, на це потрібно кілька годин. Якщо сайт залишиться доступним ззовні, зловмисник зможе зробити повторне завантаження скриптів у розділ сайту, який вже був очищений. При цьому зловмисник може використовувати різні IP-адреси для підключення, тому заборона доступу лише для списку IP-адрес не дасть результату. Щоб гарантовано очистити сайт від знайдених шкідливих скриптів, необхідно повністю закрити можливість звернення до сайту, що можна зробити тільки за допомогою повного блокування сайту для будь-яких відвідувачів. Зверніться до служби технічної підтримки хостингу, на якому розміщується ваш сайт, щоб зробити блокування.
  • Після блокування сайту необхідно перевірити комп'ютери, з яких робилася робота з сайтом, сучасним антивірусом з оновленими вірусними базами. Якщо сайт був зламаний шляхом крадіжки паролів від облікового запису за допомогою вірусу, необхідно переконатися, що подальша робота зі зламаним сайтом ведеться з комп'ютера, на якому віруси відсутні, інакше після зміни паролів доступу вони знову можуть бути вкрадені.
  • Після блокування сайту та перевірки на віруси необхідно змінити всі паролі доступу до облікового запису: доступи через FTP, через SSH, а також доступи до панелі керування хостингом. Якщо зловмисник отримував доступ до файлів облікового запису одним із цих способів, після зміни паролів він більше не зможе зробити це.
  • Після зміни паролів необхідно знищити всі процеси сервера, що працюють від імені облікового запису, на якому обслуговується сайт. Запущені зловмисником у фоновому режимі процеси, не знищені, зможуть після проведення відновлювальних робіт повторно розмістити шкідливі скрипти на сайті. Щоб цього не сталося, всі процеси, запущені до блокування сайту, мають бути знищені. Сайт у цей момент вже має бути заблокований, щоб зловмисник не зміг запустити нові процеси, звернувшись до одного зі своїх скриптів на сайті. Щоб знищити запущені на обліковому записі процеси, зверніться до служби технічної підтримки хостингу, на якому розміщується ваш сайт.
  • Тепер проникнення на сайт ззовні неможливе і можна розпочинати його відновлення.
  • Перед подальшими діями видаліть усі існуючі файли сайту, щоб серед них гарантовано не залишилося шкідливих скриптів, або скриптів CMS, у які зловмисник впровадив шкідливий код. Цей крок також важливий, оскільки при відновленні сайту із резервної копії не завжди видаляються файли, які існували до відновлення. Якщо після відновлення резервної копії на сайті залишаться старі шкідливі скрипти, зловмисник зможе повторно проникнути на сайт. Уникнути цього можна, вилучивши всі файли сайту перед відновленням.
  • Після видалення всіх файлів сайту відновіть сайт із резервної копії, створеної до його злому. Часто достатньо відновити лише файли сайту, проте якщо після їх відновлення у роботі сайту спостерігаються помилки, необхідно відновити сайт повністю: файли та базу даних.
  • Після відновлення з резервної копії оновіть версії системи керування сайтом (CMS) та її розширень до останніх. Це необхідно, щоб виключити присутність на сайті відомих уразливостей, через які він може бути зламаний. Як правило, оновлення можна зробити через розділ адміністрування CMS. Для отримання повних інструкційпо оновленню CMS необхідно звернутися на сайт розробника системи. Важливо оновити не тільки саму CMS, а й усі її розширення, оскільки часто злом відбувається через вразливість, яка присутня в одному з розширень CMS (наприклад, плагіни, теми оформлення, віджети та ін.). У цей момент ще не можна знімати блокування сайту для відвідувачів, оскільки він може бути вразливим. Щоб отримати доступ до сайту для оновлення, зверніться до технічної підтримки хостингу, на якому розміщується ваш сайт, і попросіть дозволити доступ до сайту лише з IP-адреси комп'ютера. Дізнатися вашу IP-адресу ви можете, наприклад, на inet.yandex.ru.
  • Після оновлення системи керування сайтом та її розширень зайдіть у розділ адміністрування сайту та змініть пароль доступу адміністратора до нього. Переконайтеся, що серед користувачів сайту немає інших користувачів з адміністративними привілеями (вони могли бути додані зловмисником), а якщо вони виявляться - видаліть їх.
  • Тепер, коли сайт відновлено з резервної копії та не містить шкідливих скриптів, CMS та її розширення оновлені до останніх версій, у яких відсутні вразливості, а паролі доступу до сайту та облікового запису хостингу змінені, можна знову відкрити сайт для відвідувачів.
  • Усі зазначені вище дії необхідно виконувати відповідно до зазначеної черговості, без перепусток та будь-яких змін. Якщо дії виконані неточно, на сайті можуть залишитися шкідливі скрипти або вразливості, внаслідок чого через короткий час він може знову зламаний зловмисником. Якщо з будь-яких причин виконати перелічені вище дії у тому вигляді, в якому вони вказані, можливості немає, зверніться до спеціаліста для проведення робіт із відновлення сайту після злому.

    Щоб захистити сайт від повторних зламів у майбутньому, необхідно дотримуватися наступних рекомендацій:
  • Слідкуйте за оновленнями CMS та розширень для неї на сайтах розробників та своєчасно виконуйте їх оновлення до останніх версій. Якщо у коментарі про оновлення є інформація про те, що воно усуває будь-яку вразливість, встановіть це оновлення якнайшвидше.
  • Виконуйте роботу з сайтом і з обліковим записом хостингу тільки з комп'ютерів, які захищені від вірусів сучасними антивірусами з вірусними базами, що постійно оновлюються.
  • Використовуйте складні паролі, щоб їх не можна було підібрати за словником.
  • Не зберігайте у програмах для підключення до сайту паролі від FTP та SSH, а також не зберігайте в браузері пароль доступу в адміністративний сайт і панель управління хостингом.
  • Час від часу (наприклад, раз на три місяці) змінюйте паролі доступу до сайту та до облікового запису хостингу.
  • Якщо на комп'ютері, з якого здійснювалася робота з сайтом, були виявлені віруси, змініть паролі доступу до сайту та облікового запису хостингу якнайшвидше. Змінювати необхідно всі паролі: паролі доступу FTP, SSH, пароль від адміністративної панелі сайту, а також пароль від панелі управління хостингом.
  • Не надавайте доступ до сайту третім особам, якщо ви не впевнені, що вони також дотримуватимуться наведених рекомендацій.
  • Шкідливий код потрапляє на сайт через необережність або злий намір. Призначення шкідливого коду різні, але, по суті, він завдає шкоди або заважає нормальній роботі сайту. Щоб прибрати шкідливий код на WordPress, його потрібно спочатку, знайти.

    Що таке шкідливий код на сайті WordPress

    за зовнішньому виглядуНайчастіше шкідливий код це набір букв і символів латинського алфавіту. Насправді це зашифрований код, за яким виконується та чи інша дія. Дії можуть бути різні, наприклад, ваші нові пости, відразу публікуються на сторонньому ресурсі. По суті, це крадіжка вашого контенту. Є коди та інші «завдання», наприклад, розміщення вихідних посилань на сторінках сайту. Завдання можуть витончені, але зрозуміло одне, що за шкідливими кодами потрібно полювати і видаляти.

    Як потрапляють шкідливі коди на сайт

    Лазівки для попадання кодів на сайт також безліч.

  • Найчастіше це теми і плагіни завантажені з «лівих» ресурсів. Хоча таке проникнення характерне для так званих зашифрованих посилань. Явний код не потрапляє на сайт.
  • Проникнення вірусу при зломі сайту, найнебезпечніше. Як правило, злом сайту дозволяє розмістити не лише «одноразовий код», але встановити код з елементами malware ( шкідливої ​​програми). Наприклад, ви знаходите код і видаляє його, а він відновлюється, через деякий час. Варіантів, знову — безліч.
  • Відразу зауважу, що боротьба з такими вірусами важка, а ручне видалення вимагає знань. Є три рішення проблеми: перше рішення – використовувати плагіни анітвірісники, наприклад, плагін під назвою BulletProof Security.

    Таке рішення дає хороші результати, але потребує часу, хоч і невеликого. Є більш радикальне рішення, позбавлення шкідливих кодів, включаючи складні віруси, це відновити сайт із заздалегідь зроблених резервних копій сайту.

    Оскільки хороший веб-майстер робить періодично, то відкотитися на не заражену версію, вийде без проблем. Третє рішення для багатих і лінивих, просто звертаєтеся до спеціалізованої «контори» або фахівця індивідуала.

    Як шукати шкідливий код на WordPress

    Важливо розуміти, що шкідливий код WordPress може бути в будь-якому файлі сайту, і не обов'язково в робочій темі. Він може занестися з плагіном, з темою, із «саморобним» кодом взятого з Інтернету. Спробувати знайти шкідливий код можна кількома способами.

    Спосіб 1. Вручну. Гортаєте всі файли сайту та порівнюєте їх із файлами незараженого бекапу. Знаходьте чужий код – видаляєте.

    Спосіб 2. За допомогою плагінів безпеки WordPress. Наприклад, . Цей плагін має чудову функцію, сканування файлів сайту на наявність чужого коду і плагін чудово справляється з цим завданням.

    Спосіб 3. Якщо у вас розумний support хостингу, і вам здається, що на сайті «чужий», попросіть їх просканувати ваш сайт своїм антивірусом. У їхньому звіті будуть вказані всі заражені файли. Далі, відкриваєте ці файли в текстовому редакторіта видаляєте шкідливий код.

    Спосіб 4. Якщо ви можете працювати з SSH доступом до каталогу сайту, то вперед там своя кухня.

    Важливо! Як би ви не шукали шкідливий код, перед пошуком і подальшим видаленням коду, закрийте доступ до файлів сайту (включіть режим обслуговування). Пам'ятайте про коди, які відновлюються при їх видаленні.

    Пошук шкідливих кодів за функцією eval

    Є в php така функція eval. Вона дозволяє виконувати будь-який код у її рядку. Причому код може бути закодований. Саме через кодування шкідливий код виглядає як набір літер та символів. Популярні два кодування:

  • Base64;
  • Rot13.
  • Відповідно в цих кодуваннях функція eval виглядає так:

    • eval (base64_decode (...))
    • eval (str_rot13 (...)) // у внутрішніх лапках, довгі не зрозумілі набори букв і символів.

    Алгоритм пошуку шкідливого коду за функцією eval наступний (працюємо з адміністративної панелі):

    • йдіть у редактор сайту (Зовнішній вигляд → Редактор).
    • копіюєте файл functions.php.
    • відкриваєте його в текстовому редакторі (наприклад, Notepad++) і за пошуком шукайте слово: eval .
    • якщо знайшли, не поспішайте нічого видаляти. Потрібно зрозуміти, що ця функція просить виконати. Щоб зрозуміти код потрібно розкодувати. Для розкодування є онлайн-інструменти, звані декодери.
    Декодери/Кодери

    Працюють декодери просто. Копіюєте код, який потрібно розшифрувати, вставляєте у поле декодера та декодуєте.

    На момент написання статті я не знайшов у себе жодного зашифрованого коду, знайденого в WordPress. Знайшов код із сайту Joomla. У принципі, різниці для розуміння розкодування немає. Дивимося фото.

    Як бачите на фото, функція eval після розкодування, вивела не страшний код, що загрожує безпеці сайту, а зашифроване посилання копірайту, автора шаблону. Його також можна видалити, але він повернеться після оновлення шаблону, якщо ви не використовуєте .

    На завершення зауважу, щоб не отримати вірус на сайт:

    • Шкідливий код на WordPress частіше приходить з темами та плагінами. Тому не ставте шаблони та плагіни з «лівих», не перевірених ресурсів, а якщо ставите, уважно їх прокачайте на наявність посилань та виконавчих функцій php. Після встановлення плагінів і тем із «незаконних» ресурсів, перевірте сайт антивірусами.
    • Обов'язково робіть періодичні бекапи та виконуйте інші.

    1. Розпакувати у папку сайту.
    2. перейти на посилання ваш_сайт/fscure/
    3. все

    Що вміє?

    1. Автоматичний пошук вірусів із сигнатур.
    2. Пошук рядка у файлах
    3. Видалення файлів
    4. Патч шкідливого коду за допомогою регулярних виразів

    Скрипт не зробить за вас всю роботу та потребує деяких мінімальних знань. Перед роботою рекомендується зробити бекап сайту.

    Як працює?

    При першому запуску складає індекс файлів. Файл fscure.lst у папці. Виводить список файлів, що містять потенційно шкідливі сигнатури. "Потенційно шкідливі" це означає, що вирішувати вірус це чи не вірус, доведеться вам. Список сигнатур налаштовується у файлі config.php, константа SCAN_SIGN. При налаштуваннях дефолту скрипт не перевіряє js файли і не містить для них сигнатур.

    Найчастіші проблеми

    1. не створює індекс fscure.lst. Може відбуватися, якщо не вистачає прав. Поставте 777 на папку fscure

    2. 5хх помилка. Найчастіше "504 Gateway Time-out". Скрипт не встигає відпрацювати та вилітає по таймууту. І тут є кілька шляхів прискорення його роботи. Швидкість насамперед залежить від розміру індексу. Він у файлі fscure.lst. Зазвичай файл до 5Мб у 90% випадків встигає обробити. Якщо не встигає, можна зменшити "жадібність" скрипта, заборонивши сканувати *.jpg;*.png;*.css в конфізі.
    У файлі config.php.

    // Розділювач; define("FILES_EXCLUDE","*.js;*.jpg;*.png;*.css");

    3. Хостинг видає попередження виду
    (HEX)base64.inject.unclassed.6: u56565656: /var/www/u65656565/data/www/34535335353.ru/fscure/index.php

    Вірусу у скрипті немає і не було. А (HEX) base64.inject.unclassed.6 це конструкція виду "echo base64_decode("), яка часто зустрічається і сама по собі цілком нешкідлива. останньої версіїя цей код замінив.

    Що робити, якщо у вас не вдалося знайти вірус самостійно?

    Ви можете звернутися до мене за допомогою. Розцінки у мене скромні. На роботу я даю гарантію 6 місяців. Вартість роботи 800 грн. для одного сайту. Якщо на обліковому записі кілька сайтів ціна визначається індивідуально.

    Якщо у вас все вдалося зробити самостійно, буду вдячний за матеріальну винагороду або посилання на мій сайт.

    Мої реквізити:
    yandex
    41001151597934

    webmoney
    Z959263622242
    R356304765617
    E172301357329

    Правда життя таке, що сайт рано чи пізно можуть зламати. Після успішної експлуатації вразливості хакер намагається закріпитися на сайті, розміщуючи в системних директоріях хакерські веб-шелли, завантажувачі та впроваджуючи бекдори в код скриптів та базу даних CMS.

    Сканери допомагають виявляти завантажені веб-шелли, бекдори, фішингові сторінки, спам-розсилювачі та інші типи шкідливих скриптів – все те, що їм відомо та заздалегідь додано до бази сигнатур шкідливого коду. Деякі сканери, наприклад, AI-BOLIT, мають набір евристичних правил, які дозволяють виявляти файли з підозрілим кодом, який часто використовується в шкідливих скриптах, або файли з підозрілими атрибутами, які можуть бути завантажені хакерами. Але, на жаль, навіть у разі використання кількох сканерів на хостингу, можливі ситуації, коли деякі хакерські скрипти залишаються не виявленими, що фактично означає, що у зловмисника залишається “чорний хід” і він може зламати сайт та отримати над ним повний контрольв будь-який момент.

    Сучасні шкідливі та хакерські скрипти значно відрізняються від тих, що були 4-5 років тому. Зараз розробники шкідливого коду комбінують обфускацію, шифрування, декомпозицію, зовнішнє підвантаження шкідливого коду і використовують інші хитрощі для того, щоб обманювати антивірусне програмне забезпечення. Тому ймовірність пропуску нових “шкідників” значно вища, ніж раніше.

    Що можна зробити в даному випадку для більш ефективного виявлення вірусів на сайті і хакерських скриптів на хостингу? Необхідно використовувати комплексний підхід: первісне автоматизоване сканування та подальший ручний аналіз. У цій статті йтиметься про варіанти виявлення шкідливого коду без сканерів.

    Спочатку розглянемо, що саме слід шукати під час злому.

  • Хакерські скрипти.
    Найчастіше при злому завантажують файли, що являють собою веб-шелли, бекдори, "завантажувачі" (uploaders), скрипти для спам-розсилок, фішингові сторінки + обробники форм, дорвеї та файли-маркери злому (картинки з лого хакерської групи, текстові файлиз "посланням" від хакерів і т.п.)
  • Інжекти (використання коду) у існуючих файлах .
    Другий за популярністю тип розміщення шкідливого та хакерського коду – це інжекти. У існуючі файли сайту.htaccess можуть впроваджувати мобільні та пошукові редиректи, у php/perl скрипти інжектувати бекдори, в.js та.html шаблони вбудовувати вірусні javascript фрагменти або редиректи на сторонні ресурси. Можливі інжекти і в медіа-файлах, наприклад. Часто шкідливий код складається з кількох компонентів: сам шкідливий код зберігається в exif-заголовку jpg файлу, а виконується за допомогою невеликого скрипта, що управляє, код якого не виглядає підозрілим для сканера.
  • Інжекти у базі даних.
    База даних є третьою метою для хакера. Тут можливі статичні вставки , , , які перенаправляють відвідувачів на сторонні ресурси, "шпигуть" за ними або заражають комп'ютер/мобільний пристрій відвідувача в результаті drive-by атаки.
    Крім того, у багатьох сучасних CMS (IPB, vBulletin, modx та ін.) шаблонизатори дозволяють виконувати php код, а самі шаблони зберігаються в базі даних, тому php код веб-шеллів і бекдор може бути вбудований безпосередньо в БД.
  • Інжекти в сервісах, що кешують.
    В результаті некоректного або небезпечного налаштування кешуючих сервісів, наприклад memcached, можливі інжекти в закешовані дані "на льоту". У деяких випадках хакер може впроваджувати шкідливий код на сторінки сайту без безпосереднього зламування останнього.
  • Інжекти/інціковані елементи в системних компонентах сервера.
    Якщо хакер отримав привілейований (root) доступ до сервера, він може замінити елементи веб-сервера або сервера, що кешує, на інфіковані. Такий веб-сервер з одного боку забезпечуватиме контроль над сервером за допомогою керуючих команд, з іншого боку – час від часу впроваджувати динамічні редиректи та шкідливий код на сторінки сайту. Як і у випадку інжекта в сервіс, що кеширує, адміністратора сайту швидше за все не зможе виявити факт злому сайту, так як всі файли і база даних будуть оригінальними. Цей варіант є найбільш складним для лікування.
  • Отже, припустимо, що сканерами ви вже перевірили файли на хостингу та дамп бази даних, але вони нічого не виявили, а вірусний, як і раніше, на сторінці або мобільний редирект продовжує відпрацьовувати при відкритті сторінок. Як шукати далі?

    Пошук вручну

    У unix складно знайти більш цінну пару команд для пошуку файлів та фрагментів, ніж find/grep.

    find. -name '*.ph*' -mtime -7

    знайде всі файли, які було змінено за останній тиждень. Іноді хакери скручують дату зміни у скриптів, щоб таким чином не виявити нові скрипти. Тоді можна пошукати файли php/phtml, у яких змінювалися атрибути

    find. -name '*.ph*' -сtime -7

    Якщо потрібно знайти зміни в якомусь часовому інтервалі, можна скористатися тим самим find

    find. -name '*.ph*' -newermt 2015-01-25 ! -newermt 2015-01-30 -ls

    Для пошуку у файлах незамінний grep. Він може шукати рекурсивно файлами вказаний фрагмент

    grep -ril ‘stummann.net/steffen/google-analytics/jquery-1.6.5.min.js’ *

    При зломі сервера корисно проаналізувати файли, які мають guid/suid прапор

    find / -perm -4000 -o -perm -2000

    Щоб визначити, які скрипти запущені в даний момент і вантажать CPU хостингу, можна викликати

    lsof +r 1 -p `ps axww | grep httpd | grep-v grep | awk ‘ ( if(!str) ( str= ) else ( str=str»,»))END(print str)’` | grep vhosts | grep php

    Використовуємо мозок та руки для аналізу файлів на хостингу
  • Йдемо в директорії upload, cache, tmp, backup, log, images, в які щось пишеться скриптами або завантажується користувачами, і переглядаємо вміст нових файлів з підозрілими розширеннями. Наприклад, для joomla можна перевірити.
    Для WordPress є сенс перевірити на скрипти директорію wp-content/uploads, backup та cache каталоги тем.
  • Шукаємо файли з дивними іменами
    Наприклад, php, fyi.php, n2fd2.php. Файли можна шукати
    • - за нестандартними поєднаннями символів,
    • - Наявність цифр 3,4,5,6,7,8,9 в імені файлів
  • Шукаємо файли з нехарактерними розширеннями
    Допустимо, у вас сайт на WordPress або Для них файли з розширеннями .py, .pl, .cgi, .so, .c, .phtml, .php3 будуть не зовсім звичайними. Якщо якісь скрипти та файли з цими розширеннями будуть виявлені, швидше за все, це будуть хакерські інструменти. Можливий відсоток помилкових виявлень, але він невеликий.
  • Шукаємо файли з нестандартними атрибутами чи датою створення
    Підозри можуть викликати файли з атрибутами, які відрізняються від існуючих на сервері. Наприклад, все.php скрипти були завантажені ftp/sftp і мають користувача user, а деякі створені користувачем www-data. Має сенс перевірити останні. Або якщо дата створення файлу скрипта раніше дати створення сайту.
    Для прискорення пошуку файлів із підозрілими атрибутами зручно користуватися unix командою find.
  • Шукаємо дорвеї за великою кількістю файлів .html або .php
    Якщо в каталозі кілька тисяч файлів.php або.html, швидше за все, це дорвей.
  • Логи на допомогу

    Логи веб-сервера, поштового сервісу та FTP можна використовувати для виявлення шкідливих та хакерських скриптів.

    • Кореляція дати та часу надсилання листа (які можна дізнатися з лога поштового сервераабо службового заголовка спам-листа) із запитами з access_log допомагають виявити спосіб розсилки спаму або знайти скрипт спам-розсилника.
    • Аналіз трансферу FTP xferlog дозволяє зрозуміти, які файли були завантажені в момент злому, які змінені і ким.
    • У правильно налаштованому лозі поштового сервера або у службовому заголовку спам-листа при правильному налаштуванні PHP буде ім'я або повний шлях до скрипта-відправника, що допомагає визначати джерело спаму.
    • За логами проактивного захисту сучасних CMS та плагінів можна визначати, які атаки були виконані на сайт і чи зуміла CMS протистояти їм.
    • За access_log та error_log можна аналізувати дії хакера, якщо відомі імена скриптів, які він викликав, IP-адресу або User Agent. У крайньому випадку можна переглянути запити POST в день злому і зараження сайту. Часто аналіз дозволяє знайти інші скрипти хакерів, які були завантажені або вже знаходилися на сервері в момент злому.
    Контроль цілісності

    Набагато простіше аналізувати злом та шукати шкідливі скрипти на сайті, якщо заздалегідь подбати про його безпеку. Процедура контролю за цілісністю (integrity check) допомагає своєчасно виявляти зміни на хостингу і визначати факт злом. Один з найпростіших і ефективних способів- Покласти сайт під систему контролю версій (git, svn, cvs). Якщо грамотно настроїти.gitignore, то процес контролю за змінами виглядає як виклик команди git status, а пошук шкідливих скриптів і змінених файлів - git diff.

    Також у вас завжди буде резервна копіяфайлів, до яких можна "відкотити" сайт за лічені секунди. Адміністраторам сервера та просунутим веб-майстрам можна використовувати inotify, tripwire, auditd та інші механізми для відстеження звернень до файлів та директорій, та контролю за змінами у файловій системі.

    На жаль, не завжди є можливість настроїти систему контролю версій або сторонні послуги на сервері. У разі shared-хостингу не вдасться встановити систему контролю версій та системні сервіси. Але це не біда, є чимало готових рішень для CMS. На сайті можна встановити плагін або окремий скрипт, який відстежуватиме зміни у файлах. У деяких CMS вже реалізовано ефективний моніторинг змін та механізм integrity check (Наприклад, Бітрікс, DLE). У крайньому випадку, якщо на хостингу є ssh, можна сформувати еталонний зліпок файлової системикомандою

    Акція «2 за ціною 1»

    Акція діє до кінця місяця.

    При підключенні послуги "Сайт під наглядом" для одного сайту, другий на тому ж обліковому записі підключається безкоштовно. Наступні сайти на акаунті – 1500 руб на місяць за кожен сайт.

    
    Top