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

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

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

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

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

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

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

В 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 = $ 1} else {str = str »,» $ 1}} END {print str}' `| grep vhosts | grep php

1. Йдемо в директорії upload, cache, tmp, backup, log, images, в які щось пишеться скриптами або завантажується користувачами, і переглядаємо вміст на наявність нових файлів з підозрілими розширеннями. Наприклад, для joomla можна перевірити .php файли в каталозі images: find ./images -name '* .ph *' Швидше за все, якщо щось знайдеться, то це буде шкідливий.
   Для WordPress має сенс перевірити на скрипти директорію wp-content / uploads, backup і cache каталоги тем.
2. Шукаємо файли з дивними іменами
   Наприклад, php, fyi.php, n2fd2.php. Файли можна шукати
   • за нестандартними сполученням символів,
   • наявності цифр 3,4,5,6,7,8,9 в імені файлів

1. Шукаємо файли з нехарактерними розширеннями
   Припустимо, у вас сайт на WordPress або Для них файли з розширеннями .py, .pl, .cgi, .so, .c, .phtml, .php3 будуть не зовсім звичайними. Якщо якісь скрипти і файли з даними розширеннями будуть виявлені, швидше за все це будуть хакерські інструменти. Можливий відсоток помилкових виявлень, але він не великий.
2. Шукаємо файли з нестандартними атрибутами або датою створення
   Підозри можуть викликати файли з атрибутами, що відрізняються від існуючих на сервері. Наприклад, всі .php скрипти були завантажені по ftp / sftp і мають користувача user, а деякі створені користувачем www-data. Має сенс перевірити останні. Або якщо дата створення файлу скрипта раніше дати створення сайту.
   Для прискорення пошуку файлів з підозрілими атрибутами зручно користуватися unix командою find.
3. Шукаємо Дори по великому числу файлів .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, можна сформувати еталонний зліпок файлової системи командою

ls -lahR> original_file.txt

і при виникненні проблем створити новий зліпок в інший файл, а потім порівняти їх в програмах WinDiff, AraxisMerge Tool або BeyondCompare.

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