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

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

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

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

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

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

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

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

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

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

Щоб захистити сайт від повторних зламів у майбутньому, необхідно дотримуватися наступних рекомендацій:

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

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

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

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

Ось приклад лістингу: ./components/com_wrapper/wrapper.php ./components/com_wrapper/controller.php ./components/com_wrapper/router.php. com_banners/models/banner.php ./components/com_banners/models/banners.php ./components/com_banners/controller.php ./components/com_banners/router.php ./components/com_finder/views/search/view.html. php ./components/com_finder/helpers/route.php ./components/com_finder/helpers/html/filter.php ./components/com_finder/helpers/html/query.php ./components/com_finder/controllers/suggestions.json. php ./components/com_jshopping/tables/productfiles.php ./components/com_jshopping/tables/statictext.php ./components/com_jshopping/tables/country.php ./components/com_jshopping/tables/productlabel.php ./components /tables/shippingext.php .... ./administrator/components/com_jshopping/controllers/orderstatus.php ./administrator/components/com_jshopping/controllers/shippingsprices.php ./administ rator/components/com_jshopping/controllers/vendors.php ./administrator/components/com_jshopping/controllers/productlabels.php ./administrator/components/com_jshopping/controllers/categories.php ./administrator/components/com_cache/cache.php . administrator/components/com_cache/models/cache.php ./administrator/components/com_cache/controller.php ./administrator/components/com_cache/views/purge/view.html.php ./administrator/components/com_cache/views/cache /view.html.php ./administrator/components/com_cache/helpers/cache.php ./administrator/components/com_content/tables/featured.php

Разом 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.

Дивимося список модулів

#ls ./modules index.html mod_banners mod_login mod_users_latest mod_articles_archive mod_breadcrumbs mod_menu mod_weblinks mod_articles_categories mod_custom mod_random_image mod_whosonline mod_articles_category mod_feed mod_related_items mod_wrapper mod_articles_latest mod_finder mod_search mod_articles_news mod_footer mod_stats mod_articles_popular mod_languages ​​mod_syndicate #ls ./administrator/modules index.html mod_latest mod_menu mod_quickicon mod_title mod_custom mod_logged mod_multilangstatus mod_status mod_toolbar mod_feed mod_login mod_popular mod_submenu mod_version

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

Дивимося список компонентів

#ls ./components com_banners com_finder com_media com_search com_wrapper com_contact com_jshopping com_newsfeeds com_users index.html com_content com_mailto com_phocapdf com_weblinks #ls ./administrator/components com_admin com_config com_installer com_media com_phocapdf com_users com_banners com_contact com_joomlaupdate com_menus com_plugins com_weblinks com_cache com_content com_jshopping com_messages com_redirect index.html com_categories com_cpanel com_languages ​​com_modules com_search com_checkin com_finder com_login com_newsfeeds com_templates

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

Дивимося список плагінів

#ls ./plugins authentication content editors-xtd finder phocapdf search user captcha editors extension index.html quickicon system

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

#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.

Дивимося список шаблонів

#ls./templates atomic beez_20 beez5 index.html system templ1

Крім стандартних шаблонів, використовується 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.

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

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

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

Навіщо хакери зламують сайт?

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

Просування сайту зловмисника.

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

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

Злам для підвищення самооцінки хакера

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

Розсилка спаму "від особи" вашого сайту.

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

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

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

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

Результат проникнення на сайт – поява численних файлів скриптів у різних каталогах 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.

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

Компонент RSFirewall

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Розділ Joomla Configuration

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

Розділ Server Configuration

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

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

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

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

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

Розділ Scan Result

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

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

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

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

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

Підведемо підсумки

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

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

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

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

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

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

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

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

Шукаємо шкідливий код на сайті

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

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

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