Видалення шкідливого коду Joomla. Бортовий журнал Звідки ж беруться віруси

Якщо у вас є доступ до сайту SSH, ви можете знайти файли з інжектованим кодом виконанням наступних команд:

#grep -lr --include=*.php "eval(base64_decode" /pathWebroot #grep -lr --include=*.php "strrev(" /pathWebroot)

Якщо доступу немає, можете попросити службу підтримки хостингу зробити це за вас і надіслати вам звіт.

Разом 1606 входжень. Це практично всі файли PHP. Видалити інжектований код вручну марно. На це піде дуже багато часу. Виявлено новий файл images/post.php для виконання будь-якого коду.

Спершу необхідно зробити повну резервну копію сайту на той випадок, якщо щось піде не так.

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

#grep -lr --include=*.php "eval(base64_decode" /pathWebroot | xargs sed -i.bak "s/eval(base64_decode[^;]*;//" #grep -lr --include=*). php "strrev(" /pathWebroot | xargs sed -i._bak "s/$_ = strrev([^;]*; @$_([^;]*;//"

Команди видалять усі входження подібного шкідливого коду з файлів і зробить їх резервні копії з розширенням .bak. Це дозволить вам тільки виграти час для здійснення повного відновлення сайту, але не позбавить вас наступних атак. Слід розуміти, що висока ймовірність наявності файлів типу images/post.php описаного вище для виконання будь-якого коду і старі дірки у встановлених розширеннях.

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

Використовуються лише стандартні модулі Joomla

Крім стандартних компонентів використовуються com_jshopping та com_phocapdf.

Крім того, необхідно переглянути вміст усіх цих папок. Вони є групи плагінів.

#ls ./plugins/authentication gmail index.html joomla ldap #ls ./plugins/captcha index.html recaptcha #ls ./plugins/content emailcloak geshi joomla codemirror index.html none tinymce #ls./plugins/editors-xtd article image index.html pagebreak readmore #ls./plugins/extension index.html joomla #ls. ./plugins/quickicon extensionupdate index.html joomlaupdate #ls ./plugins/search categories contents index.html newsfeeds weblinks #ls ./plugins/system cache /plugins/user contactcreator index.html joomla profile

Крім стандартних плагінів використовується плагін phocapdf.

Крім стандартних шаблонів використовується templ1.

• Завантажуємо дистрибутив останнього релізу, розпаковуємо архів у директорію майбутнього сайту та видаляємо з неї директорію installation.
• Перейменовуємо файл htaccess.txt на.htaccess. Якщо в ньому використовувалися директиви, записані вами , перенесіть їх із зараженої копії.
• Копіюємо файл configuration.php із зараженої копії, попередньо переглянувши відсутність у ньому інжектованого коду.

Сторонні розширення

• Знаходимо використовувані сторонні компоненти Phoca PDF, JoomShopping, плагін "Phoca PDF Content Plugin", завантажуємо.
• Розпаковуємо та копіюємо файли, попередньо створивши структуру директорій як у зараженої копії. Не забуваймо про файли локалізації.

Трохи складніше справа з шаблоном. Шаблон згенерований спеціальним програмним забезпеченням і знайти його неможливо. Доведеться "виколупувати з нього все непотрібне".

На щастя, у шаблоні є 21 PHP файл і весь інжектований код був видалений командою #grep -lr --include=*.php "strrev(" /pathWebroot | xargs sed -i._bak "s/$_ = strrev([^ ;]*; @$_([^;]*;//"

Власні файли

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

Сайт повинен почати працювати відразу, як тільки ви заміните старий вміст на новий.

Зайдіть в адміністративну панель сайту, замініть ім'я користувача та пароль доступу до CMS і перегляньте, чи не замінений e-mail SuperUsers (зловмисник може скористатися функцією відновлення забутого пароля). Ніколи не використовуйте стандартне ім'я користувача admin. Уважно перегляньте права всіх користувачів. Не виключена можливість заведення зловмисником ще одного адміністратора.

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

Після закінчення відновлювальних робіт встановіть плагін BotsGo404.

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

Як дізнатися, що сайт став жертвою атаки, в ході якої на нього потрапив шкідливий код? Перше і найпростіше - сайт перестав працювати чи виглядає не так, як має виглядати "здоровий" ресурс. Це може виявитися у появі небажаного контенту або зникнення Вашого, сторінки не завантажуються або завантажуються з помилками. До того ж, якщо Ваш сайт доданий до Яндекса або Google веб-майстер, Ви з великою ймовірністю отримаєте повідомлення від цих систем про шкідливий код. У деяких випадках про вразливість можна дізнатися від свого браузера (скриншот з Google Chrome).

Вкрай небажано в таких випадках намагатися відкривати сторінку далі.

Розбиратися в мотивах людини, яка встановила на Ваш сайт шкідливий код, а тим більше шукати його, ми не будемо. Наша основна мета - знайти "поганий" код і видалити його. Для початку необхідно просканувати ресурс, щоб знайти всі "заражені" сторінки. Це дозволяє звузити коло пошуку. Наприклад, шкідливий код міг бути поміщений у вигляді Javascript скрипту на якусь окрему сторінку, скажімо у вміст посту або коментар до нього. У такому разі проблема може бути вирішена через адмінку сайту видаленням такого коду із вмісту/коментарю. Інакше доводиться шукати його у вихідному коді Вашого ресурсу.

Для сканування сайту на предмет уразливостей можна скористатися https://sitecheck.sucuri.net У результаті можна побачити наступне:

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

Отримати доступ до вихідного коду сайту можна кількома шляхами:

Не намагаєтеся знайти шкідливий код у вихідних файлах Вашого сайту, підставивши його повністю. Виділіть його унікальну частину, як наприклад googleleadservices.cn у нашому випадку, та повторіть пошук кілька разів.

Після виявлення шкідливого коду його потрібно видалити. У нашому випадку сайт працював під Joomla, а "поганий" скрипт був вставлений в index.php у кореневій директорії. Саме тому вразливість була виявлена ​​відразу на кількох сторінках, оскільки даний index.php використовується при побудові всіх сторінок ресурсу.

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

Завжди краще попередити, ніж лікувати, тому я рекомендую:

З питаннями та зауваженнями прошу у коментарі.

Часто можна побачити в мережі: сайт працював нормально і раптом почав працювати, як двірник з похмілля, хостер пише гнівні листи, пошукові системи обходять сайт стороною, а браузери блокують попередженням «Є інформація, що цей сайт атакує комп'ютери!»

Найпоширеніша на сьогодні причина — це використання quickstart (quickstart це інсталяційний архів, що дозволяє в кілька хвилин розгорнути точну копію сайту, з усіма розширеннями), як правило, завантаженого з варезних ресурсів; Квікстарт, купленого у розробника, зрозуміло, можна не боятися. Дуже зручно, не потрібно мучитися з дизайном, встановленням розширень, налаштуванням сайту. Щоправда, часто разом із сайтом можна отримати набір скриптів, що дають контроль над вашим ресурсом, таких як розсилання спаму, роздача вірусів або розміщення невидимих ​​посилань на сторонні ресурси (чорний SEO).

Для чого варезні ресурси включають backdoor (від англ. back door - "чорний хід") в архів? Як правило, варезні ресурси живуть за рахунок відрахувань за кожне завантаження від файлообмінників, а ті, у свою чергу, показом реклами та платними підписками, що дозволяють збільшити швидкість завантаження, яка для простих користувачів зазвичай обмежена. Але багатьом цього здається мало, тим більше, коли є можливість керувати сотнями і навіть тисячами сайтів. Якщо вже хочете використовувати quickstart, то купіть його у розробника, тим більше його вартість в середньому становить 30-50 доларів, що загалом недорого навіть за нинішнього курсу.

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

Так, однією з можливих причин витоку «Панамського архіву» фахівці називають застарілі CMS - Drupal, що містив на момент злому не менше 25 вразливостей, і WordPress 4.1 з уразливим плагіном.

По-перше, антивірус шукає шкідливість саме для ПК, скільки б Ви не розміщували на своєму комп'ютері backdoor на php, заразити його (ПК) не вдасться.

По-друге, це може бути короткий шматочок коду (зазвичай зашифрований), який підвантажує шкідливі скрипти з іншого ресурсу, а раз так, то шукати його марно.

Можна піти різними шляхами.

Перший варіант

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

Ставимо чисту Joomla (або іншу CMS), встановлюємо шаблон, всі компоненти, модулі, плагіни, що стояли на вашому сайті. Переносимо всі зображення зі старого сайту, директорія images, попередньо перевіривши, щоб у ній не залишалося жодних файлів, крім зображень, у тому числі у внутрішніх директоріях. Якщо у вас встановлений компонент K2, зображення будуть перебувати в директорії media/k2/items/cache/.

Увага! Не зайвим буде перевірити наявність зображень з явно рандомною назвою, як i2495mg.gif, зазвичай в таких зображеннях ховається код, що виконується.

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

Підключаємо базу зі старого сайту

Експортуємо базу. Заходимо на хостингу в phpmyadmin, вибираємо в стовпці зліва потрібну базу та переходимо у вкладку «Експорт». Натискаємо "Виділити все", можна поставити стиск zip, і в самому низу сторінки натискаємо "Ок". Зберігаємо базу на власний ПК. Заходимо в phpmyadmin, створюємо нову базу, переходимо в неї, відкриваємо вкладку імпорт і вказуємо шлях до дампа, що скачає. Тепер залишилося підправити configuration.php, що знаходиться в корені каталогу, відкриваємо його будь-яким редактором. Наприклад, Notepad ++.

public $ db = "base"; - замість base вказуємо своє ім'я бази;

public $user = "root"; - якщо ви не змінювали ім'я користувача на локальному сервері, залишаємо як є;

public $password = ""; - На локальному сервері зазвичай стоїть порожній пароль, теж залишаємо.

Зберігаємо зміни, перевіряємо роботу сайту.

Другий варіант

Якщо у вас достатньо досвіду, то можна включити перегляд вихідного коду і подивитися, чи є «чужі» посилання, далі подивитися, наприклад, через firebug, звідки вони беруться. Як правило, вони зашифровані і, як правило, алгоритмом base64.

Якщо досвіду не вистачає, то можна скористатися онлайн-сервісом, найпростіший варіант - у кабінеті вебмайстра Яндекс або Google або веб-сканер https://rescan.pro/. Я більше схиляюся до ручного перегляду коду сторінки, хоча, звичайно, варто визнати, що всілякі скрипти та сканери помітно пришвидшують роботу.

Приклад пошуку «лівих» посилань

Для прикладу я взяв квікстарт із одного з варезних ресурсів. Натискаємо Ctrl+F5 для перегляду вихідного коду, навіть при швидкому перегляді відразу знаходимо:

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

Відкриваємо Notepad++, натискаємо Ctrl+F, переходимо у вкладку «Знайти у файлах», вказуємо директорію шаблону, а рядку пошуку шукане, у разі "sa_wqngs". Натискаємо «Знайти все». Пошук знаходить два збіги.

Видаляємо рядки, оновлюємо сторінку, рядки з посиланнями не зникли, а оскільки я раніше не знайшов прямих посилань, код зашифрований.

Запускаємо новий пошук, тепер за "base64" і бачимо в коді шаблону:

Видаляємо рядки 174, 184, 186 (код коментувати не буду, хто хоче, може знайти опис у мережі). Знову оновлюємо сторінку з вихідним кодом, посилання зникли. Також проходимо всі результати пошуку з base64, до речі, подібних вставок у шаблоні знайшлося з десяток. Тут добре допомагає сортування за часом, тому якщо більшість файлів шаблону датовані, припустимо, 1 травня 2014 року, то файли, змінені, скажімо, через вісім місяців щонайменше підозрілі.

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

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

Звичайно, вручну не завжди вдається знайти деякі «сюрпризи», так, можливо, ви вчасно не оновили систему чи розширення, і на сайт був встановлений backdoor... Зараз існує безліч сканерів, один із них AI-Bolit. До того ж, він безкоштовний для некомерційного використання.

Використовуємо його для «експериментального» сайту, де я шукав зайві посилання. Як ним користуватися, добре документовано на офіційному ресурсі, тому не дублюватиму інформацію.

За результатами експрес-перевірки я отримав повідомлення про дві вразливості. Перша повідомляла про застарілу версію двигуна, це, загалом, я і так знав.

Друга говорила про вразливість у administrator/components/com_k2/lib/elfinder/elFinder.class.php - AFU: elFinder. Можливо, причина у тому, що компонент теж застарів.

Про всяк випадок я скачав останню версію компонента з офіційного сайту і порівняв версію, на який скаржився сканер, зі свіжоскачаною. Для цього зручно використовувати плагін для Notepad ++, Compare. Як і передбачалося, відмінність полягала лише у версіях.

На цьому перевірку можна було б і завершити, але про всяк випадок я вирішив відчути себе параноїком. Один з вірних способів – подивитися, які пакети ваш сайт посилає в мережу. Ставимо Wireshark, він також добре задокументований на сайті розробника. Переходимо сторінками сайту, дійсно, сайт звертається до мережі, але тут нічого страшного. Йде підвантаження шрифтів із Google Fonts, відео з YouTube…

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

Звичайно, непогано поставити елементарні засоби захисту, але про це вже у наступній частині.

Joomla - не тільки одна з найпопулярніших CMS в Інтернеті. На превеликий жаль, ця система управління контентом найбільш схильна до атак хакерів. Сьогодні ми поговоримо про те, що робити, якщо ваш сайт на Joomla зламаний, а також розглянемо заходи профілактики та боротьби зі зловмисниками.

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

Не розглядатиму екзотичні випадки, коли атака на сайт відбувається цілеспрямовано з метою видобування інформації. Бо при розміщенні конфіденційних даних у мережі Інтернет, використовується будь-що, тільки не Joomla. Мотивація сучасних зломщиків досить зрозуміла і її можна розбити на три основні розділи.

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

Непоодинокі випадки, коли зловмисник отримує доступ до бази даних і в адміністративну панель, а ви виявляєте чужі статті та новини у списку матеріалів.

Файли Joomla можуть бути повністю видалені або замінені скриптами зловмисника. Є висока ймовірність, що відвідувач побачить щось у червоно-темних тонах, де буде написано, що злом здійснено чудовим хлопцем із Туреччини.

У 2015 році з цієї причини відбувалася більшість зламів.

Який алгоритм роботи шкідливих скриптів та зловмисників?

Атака на сайт здійснюється через уразливість CMS Joomla чи компонента. Бувають випадки, коли шкідливий код спочатку є у встановленому розширенні.

Це стосується тих компонентів, плагінів, модулів, які були завантажені нелегально.

Результат проникнення на сайт – поява численних файлів скриптів у різних каталогах Joomla.

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

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

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

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

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

Доступ до SSH. Без нього говорити про повноцінну боротьбу з вірусами неможливо

Оперативна та кваліфікована техпідтримка

Щоденне резервне копіювання. Ідеальний варіант - можливість відновити чи завантажити копію місячної давності

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

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

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

Крок 1. Очищаємо сайт від шкідливих файлів

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

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

На регулярно оновлюваному сайті пошук доведеться проводити вручну. І робити це за допомогою SSH. Завдання буде гранично простим. Необхідно з'ясувати, які файли змінювалися останнім часом. Наприклад, за тиждень. Для операційної системи Debian команда виглядатиме так:

find /каталог, де здійснюється пошук/ -type f -mtime -7

Згідно з цією командою, система відобразить ті файли, що змінювалися за останні 7 днів. Звертаємо увагу на файли з розширенням PHP.

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

На скріншоті ми бачимо два файли. Перший — найімовірніше вірус. Другий – це системний файл Joomla.

Звідки такі висновки?

Справа в тому, що в каталозі /components/com_weblinks/views/category/ ніякого файлу start.php не повинно бути в принципі.

А файл error.php у каталозі /logs/ є частиною CMS. Втім, якщо конкретно його буде видалено, нічого критичного не станеться, оскільки служить сховищем лігв Joomla.

Крок 2. Захищаємо сайт від зломів

Припустимо, що ви успішно впоралися з видаленням всіх шкідливих скриптів. Техпідтримка хостингу та антивірус відрапортували: «так, все чисто». Що необхідно зробити, щоб запобігти такому?

Оновлення Joomla та розширень до останньої актуальної версії

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

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

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

Чи всі розширення використовуються?

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

Чим менше на вашому сайті додаткових розширень, тим менша ймовірність злому!

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

Звертаю вашу увагу на компонент, який вирішує безліч завдань, пов'язаних з безпекою сайту. Ім'я йому – «RSFirewall».

Розглянемо коротко основні можливості, функції та завдання, які вирішуються RSFirewall:

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

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

Аналіз прав на каталоги та файли.

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

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

Логування будь-яких відвідувань сайту та можливість блокування IP адрес, з яких здійснювалася спроба злому

Заборона доступу до сайту із зазначених країн.

Компонентний платний. Актуальна версія доступна виключно для Joomla версій 3.X

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

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

Установка компонента стандартна здійснюється через менеджер розширень. Після того, як компонент встановлений, заходимо «Компоненти – RSFirewall – System Check»

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

файлів Joomla, які зазнавали зміни та відрізняються від аналогів з оригінального дистрибутива.

шкідливих файлів

буде здійснено перевірку прав на каталоги та файли

Щоб перевірка почалася, достатньо натиснути кнопку «Perform the System Check».

Розглянемо результат аналізу.

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

Розглянемо повністю список, не виключаючи і текст виділений зеленим кольором.

Checking if you have the latest Joomla! Version - Перевірка: чи є встановлена ​​версія Joomla останньої. Як бачимо, з цим усе гаразд. На момент написання статті такою була версія Joomla 3.4.8

Checking if you have the latest RSFirewall! Version — Перевірка: є встановлена ​​версія компонента RSFirewall останньої. Це важлива характеристика безпеки вашої системи, оскільки від версії до версії компонент не тільки обростає базою даних шкідливих скриптів, але постійно змінюється функціонально згідно з виявленими в Joomla вразливості.

Checking if you have a weak database password — У разі компонент перевіряє злостійкість пароля до бази даних.

Checking if the default "admin" user is active . - Логін супер адміністратора сайту з метою безпеки має відрізнятися від широкопоширеного «admin». Якщо компонент знаходить у базі даних користувача з таким логіном, з'явиться попередження.

Checking if you have set your FTP password — На етапі установки Joomla або редагування її налаштувань допускається фатальна помилка. Доступ за протоколом FTP вказується у конфігураційному файлі Joomla. Є місце і не менш трагічний варіант. При збереженні спільних налаштувань Joomla в полі доступу FTP записується логін і пароль до адміністративної панелі. Тому слідкуйте, щоб у файлі configuration.php відповідні параметри були порожніми.

Checking if you have Search Engine Friendly URLs enabled — Перевірка: чи увімкнена у загальних налаштуваннях Joomla підтримка SEF URL.

Checking the integrity of configuration.php — Перевірка файлу configuration.php на коректність та цілісність.

Checking if any admin users have weak passwords — Перевірка всіх паролів супер адміністраторів вашого сайту на злостійкість

Checking your session lifetime - Перевірка часу життя сесії, що задається в загальних налаштуваннях Joomla. Якщо воно перевищує 15 хвилин, з'явиться попередження.

Checking if there are any files left in the Joomla! temporary folder — У цьому випадку перевіряється: чи розташовуються файли в тимчасовому каталозі Joomla. За промовчанням таким каталогом є папка «tmp». Потрібно стежити за чистотою даного каталогу, оскільки після встановлення розширень або оновлення Joomla там можуть бути зайві архіви та скрипти.

Checking for .htaccess — Перевірка існування файлу .htaccess. Після встановлення Joomla у корені сайту за промовчанням створюється файл htaccess.txt. Ваше завдання перейменувати його в.htaccess. Саме так, як написано, з точкою на початку і без.txt наприкінці

Checking if the Joomla! temporary folder is publicly accessible — Перевіряється, чи доступний каталог для тимчасових Joomla файлів для відкритого доступу. Що мається на увазі під цим? Простіше кажучи, чи можна набрати в адресному рядку браузера посилання на вид www.ваш сайт.com/tmp.

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

Checking your Session Handler - Перевірка типу обробника сесій. Нам рекомендують встановити значення «Ні». Зробити це можна у загальних налаштуваннях Joomla

Перейдемо до вивчення наступного розділу, де проводився аналіз конфігурації сервера.

Ми бачимо, що конфігураційні директиви PHP з точки зору компонента не налаштовані належним чином.

Розбиратися в тому яка директива за що відповідає потребі немає. Однак, потрібно вирішити питання з тимчасовим каталогом Joomla, про який я писав вище.

Скопіюйте його на жорсткий диск свого комп'ютера, а з кореня сайту видаліть, бо він має виключно інформативний характер і повідомляє значення директив PHP, які ви повинні вставити у свій php.ini

Як його знайти на сервері і чи доступний туди доступ, слід уточнити у вашого хостинг провайдера. Нерідко директиви PHP змінюються шляхом зміни налаштувань хостинг-панелі. Тому універсального рецепту тут нема.

Тут наведено результати сканування вашої системи. Пропоную вивчити їхній результат.

Scanning the integrity of your Joomla! (CMS) files — у цьому розділі буде показано результат сканування файлів CMS Joomla та порівняння з оригінальним дистрибутивом на цілісність та можливу зміну файлів. Порівнювати будуть не тільки скрипти, але також файли зображень, CSS. Загалом, усе.

Scanning your folders — сканування за протоколом FTP відвідати кожен і переконатися, що він чистий від шкідливих скриптів

Scanning your files — у разі йдеться про права на файли. Дії мають бути аналогічними, як у випадку з каталогами

Scanning your files for common malware — сканування щодо наявності шкідливого коду. Як бачимо, RSFirewall знайшов один файл і при його аналізі в текстовому редакторі він був визнаний дійсно шкідливим і видалений мною з сервера.

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

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

Лікування сайту здійснюється платно.

Актуальна вартість робіт вказана на сторінці: «Лікування сайтів (CMS Joomla) від вірусів»

З повагою, Володимир Єгоров