Захист PHP-скриптів від аналізу та модифікації. Захист PHP-скриптів від аналізу та модифікації Використовуйте унікальний логін адміністратора

Створюємо власну сторінку реєстрації для мультисайту замість стандартної wp-signup.php.

У звичайному встановленні WordPress сторінку реєстрації (авторизації, скидання пароля) виводить файл wp-login.php .

• /wp-login.php - авторизація
• /wp-login.php?action=register - реєстрація
• /wp-login.php?action=lostpassword - скидання пароля

Для мультисайту wp-login.php є окремі умови. Так, при переході за посиланням /wp-login.php?action=register на мультисайті WordPress зробить редирект на сторінку /wp-signup.php . У багатьох темах сторінка виглядає не дуже привабливо, тому ми зробимо власну.

Основний сайт мережі

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

functions.php?

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

Ліричний відступ

Варто зазначити, що MU-плагіни завантажуються раніше за звичайні плагіни і до повного завантаження ядра WordPress, тому виклик деяких функцій може призвести до фатальних помилок у PHP. Подібне «раннє» завантаження має і свої плюси. Скажімо, усередині будь-якої теми не можна чіплятися до деяких екшенів, які спрацьовують ще до завантаження файлу functions.php з теми. Прикладом цього можуть бути екшени з плагіну Jetpack виду jetpack_module_loaded_related-posts (related-posts - назва модуля) за допомогою яких можна відстежувати активність модулів в Jetpack. До цього екшену неможливо "причепитися" з файлу теми, тому що екшен вже спрацював до завантаження теми - плагіни завантажуються раніше. Подивитися на загальну картинку порядку завантаження WordPress можна на сторінці Action Reference у кодексі.

Порядок у файлах

MU-плагіни можуть містити будь-яку кількість файлів та будь-яку структуру, яка здасться вам логічною. Я дотримуюсь приблизно такої ієрархії:

|-mu-plugins |-|-load.php |-|-|-selena-network |-|-|-|-signup |-|-|-|-|-plugin.php |-|-|-| -|-... |-|-|-|-jetpack |-|-|-|-|-plugin.php

У файлі load.php підключаються всі необхідні плагіни для нашої мережі:

// Load Traslates for all addons load_muplugin_textdomain ("selena_network", "/selena-network/languages/"); // Network Signup require WPMU_PLUGIN_DIR . "/selena-network/signup/plugin.php"; // Інші plugins // require WPMU_PLUGIN_DIR ...

Усередині папки selena-network зберігаються папки плагінів, у кожній є свій plugin.php , які ми підключаємо в load.php . Це дає гнучкість та можливість швидко відключати та включати деякі речі.

Адреса сторінки реєстрації

Щоб вказати адресу сторінки реєстрації, використовується фільтр wp_signup_location. Його можна знайти всередині файлу wp-login.php і саме він відповідає за редирект на wp-signup.php.

Case "register" : if (is_multisite()) ( wp_redirect(apply_filters("wp_signup_location", network_site_url("wp-signup.php"))); exit;

Додамо свою функцію до mu-plugins/selena-network/signup/plugin.php , яка буде віддавати адресу сторінки реєстрації на поточному сайті:

Function selena_network_signup_page ($url) ( return home_url () . "/signup/"; ) add_filter ("wp_signup_location", "selena_network_signup_page", 99);

selena_network - префікс, який я використовую в іменах всіх функцій усередині MU-плагінів на своєму сайті для запобігання колізії, його слід замінити на свій власний унікальний префікс. Пріоритет додавання фільтра 99, тому що деякі плагіни, наприклад bbPress і BuddyPress можуть перезаписати цю адресу на власну (MU-плагіни завантажуються раніше, ніж звичайні плагіни, див. вище). Зверніть увагу, що використовується home_url() замість network_site_url() , щоб залишити відвідувача на тому ж домені. Як адресу можна використовувати будь-яку URL-адресу.

Створення сторінки

Тепер створимо сторінку з адресою site.com/signup/ через звичайний інтерфейс, а в папці дочірньої теми шаблон для нашої нової сторінки – page-signup.php. Замість слова "signup" можна використати унікальний ID.

Всередині нового шаблону необхідно викликати функцію selena_network_signup_main() , яка виводитиме форму реєстрації.

Варто зауважити, що весь процес із шаблонами не обов'язковий і замість цього можна створити свій шорткод, який також викликатиме функцію selena_network_signup_main() .

wp-signup.php та wp-activate.php

Тепер займемося створенням функції, яка виводитиме форму реєстрації. Для цього скопіюємо файли wp-signup.php та wp-activate.php з кореня WordPress у mu-plugings/selena-network/signup/ (і не забуваємо їх підключити всередині mu-plugins/selena-network/signup/plugin.php) . Подальші маніпуляції з файлами дуже складно і довго описувати, тому доведеться зробити їх самостійно. Я лише опишу, що саме треба зробити і опублікую вихідні файли свого проекту:

1. На початку файлу видалити всі require , виклик функцій та інший код поза функціями.
2. Перейменувати всі функції, додавши до імен унікальні префікси.
3. Нижню частину коду wp-signup.php обернути на функцію selena_network_signup_main і на початку написати global $active_signup; .
4. Замінити верстку на власну в потрібних місцях.

Всередині wp-activate.php необхідно зробити приблизно те саме:

1. Видалити весь код поза функціями, обернути верстку на окрему функцію.
2. Змінити верстку у місцях, де це необхідно.

Файл wp-activate.php відповідає за сторінку активації облікового запису. Як і зі сторінкою реєстрації, для неї необхідно створити окремий шаблон, усередині якого викликати функцію з файлу wp-activate.php .

Надсилаємо листи активації

Сторінка реєстрації надсилає відвідувачу листа з посиланням на активацію облікового запису. За замовчуванням цим займається функція wpmu_signup_user_notification() із файлу ms-functions.php . Її функціонал можна запозичувати для своєї функції. Причина, через яку необхідно відмовитися від використання цієї функції, - вона відправляє посилання активації облікового запису з wp-activate.php . "Вимкнути" ж цю функцію можна за допомогою фільтра wpmu_signup_user_notification віддаючи по ньому false (якщо цього не зробити, лист активації буде відправлятися двічі, окей, насправді два різні листи).

Function armyofselenagomez_wpmu_signup_user_notification($user, $user_email, $key, $meta = array()) ( // ... // Код з функції wpmu_signup_user_notification() wp_mail($user_email, wp_specialchars_decode($subject), $ ; return false; ) add_filter("wpmu_signup_user_notification", "armyofselenagomez_wpmu_signup_user_notification", 10, 4);

В результаті сторінка реєстрації в темі Селена стала виглядати набагато чистіше та акуратніше.

Висновок

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

Зауважу, що правити файли слід обережно і намагатися не сильно відходити від вихідних, щоб у подальшому, якщо WordPress змінить файли wp-signup.php і wp-activate.php, їх простіше було порівнювати між собою для пошуку змін.

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

Бонус. Захист від спамерів

Навіть найменші сайти на WordPress часто зазнають нальоту спам-реєстрацій. Можна писати нескінченні умови для фільтрації ботів, часто більше схожі на спробу створити штучний інтелект 🙂 (я не експерт з налаштування Apache, тому мої правила можуть бути не дуже правильними).

RewriteEngine On RewriteBase / RewriteRule ^wp-signup\.php - RewriteRule ^wp-activate\.php - # BEGIN WordPress # Правила від WordPress за замовчуванням не чіпаємо:) # ... # END WordPress

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

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

1. Валідація вхідних даних
2. Захист від XSS атак
3. Захист від CSRF атак
4. Запобігання SQL ін'єкцій
5. Захист файлової системи
6. Захист даних сесії
7. Обробка помилок
8. Захист файлів, що підключаються

Валідація вхідних даних

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

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

Захист від XSS атак

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

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

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

Захист від CSRF атак

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

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

Наступний простий приклад показує як незахищений сайт може зазнати CSRF атаки:

Припустимо, що Боб хоче зробити CSRF атаку над Алісою. Він сформував спеціальну url адресу та відправив його Алісі на e-mail:

Відвідай мій сайт!

Якщо Аліса авторизована на сайті example.com і пройде за цим посиланням, то з її рахунку на рахунок Боба буде переведено $1000. Як альтернатива Боб може відправити і зображення, а в атрибуті src внести "погану" адресу.

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

В якості запобігання подібним атакам, використовуйте тільки POST запити до процесів, призначених для зміни інформації в базі даних. Не використовуйте $_REQUEST. Користуйтеся $_GET -ом для обробки параметрів GET, і $_POST для отримання POST параметрів.

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

Запобігання SQL ін'єкцій

Для виконання запитів до бази даних слід використовувати PDO. Завдяки параметризованим запитам і підготовленим виразам, ви можете звести нанівець загрозу ін'єкцій SQL.

Давайте розглянемо наступний приклад:

У коді, представленому вище, ми надсилаємо запит метод prepare() , включаючи іменні параметри: :name і:age . Таким чином, запит компілюється для подальшої підстановки даних. При виклику методу execute() , запит повністю формується та виконується. Якщо ви користуєтеся подібною технікою, всі спроби зловмисника здійснити SQL ін'єкцію будуть зведені до нуля.

Захист файлової системи

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

Цей скрипт дуже небезпечний, тому що через нього можна отримати доступ до будь-якого каталогу, який доступний з файлу зі скриптом: до каталогу з сесіями, системним папкам та багато іншого.

Захист даних сесії

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

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

Починаючи з PHP 5.4, ви можете передати об'єкт типу SessionHandlerInterface в session_set_save_handler() .

Обробка помилок

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

На публічному сервері вам необхідно відключити такі опції, як display_errors і display_start_up_errors , а такі опції як error_reporting і log_errors , повинні бути активні, щоб всі помилки, що виникли у користувачів, записувалися в логи.

Також можна використовувати “ set_error_handler ” для визначення свого власного обробника помилок. Однак тут можуть виникнути обмеження, адже власний обробник поступається рідному PHP механізму. Помилки E_CORE_ERROR , E_STRICT або E_COMPILER_ERROR не можуть бути виловлені в тому ж файлі, де і певний обробник. Більше того, помилки, які можуть виникнути в самому обробнику, також не можуть бути відловлені.

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

Захист файлів, що підключаються

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

Підсумок

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

Давайте з вами подумаємо, хто такий хакер? Хакер – це не зломщик! Люди часто плутають ці поняття. Хакер - це насамперед людина з нестандартним мисленням, і в цьому її сила, якщо можна сказати.

Щоб успішно протистояти хакеру, потрібно навчитися нестандартно мислити. Як кажуть, клин клином вибивають.

Сьогодні я запропоную вам дуже незвичайний спосіб захиститись від атак типу php include. Підходить він, звичайно, далеко не всім. І якщо чесно захищає він не від самої атаки, а від її виявлення. Заінтригував?

Як шукається інклуд…

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

Виглядає це так. Зловмисник модифікує всі параметри по черзі, припускаючи що дані цих параметрів потрапляють у функцію інклуда. Ну або якщо по-простому намагається «приєднати» файли. І для того щоб визначити чи є вразливість чи ні, йому необхідно додати який-небудь файл на цільовій системі (приєдналося - вразливість є, ні - вразливості немає).

Звичайно якщо зловмисник діє ззовні, то він не знає структуру розташування каталогів і файлів, і не може приєднати будь-який файл, так як не буде знати шляхи до нього. Але бувають такі файли, які завжди існують у системі, і до яких завжди є права на читання. Для Linux це /etc/passwd, а для Windows - нехай буде C:\boot.ini. Але втім Windows нас мало цікавить, тому далі ми говоритимемо про passwd

/etc/passwd

Напевно ви натикалися у своїх логах на більшу кількість записів виду:

Action=../etc/passwd%00
?action=../../etc/passwd%00
?action=../../../etc/passwd%00
?action=../../../../etc/passwd%00
?action=../../../../../etc/passwd%00
?do=../etc/passwd%00
?do=../../etc/passwd%00
?do=../../../etc/passwd%00
?do=../../../../etc/passwd%00
?do=../../../../../etc/passwd%00
?id=../etc/passwd%00
?id=../../etc/passwd%00
?id=../../../etc/passwd%00
?id=../../../../etc/passwd%00
?id=../../../../../etc/passwd%00

Якщо так, то знайте, у вас намагалися знайти php include (ну або можливість читання довільних файлів, але нас зараз це не цікавить). Так от, якщо один із ваших параметрів не обробляється належним чином і потрапляє у функцію include(), то тоді б файл /etc/passwd приєднався, вміст його інтерпретувалося як php скрипт, і оскільки він не містить тегів php коду, він би вивівся в браузер в незмінному вигляді. Це і послужило б зломщику «маркером» наявності вразливості.

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

Захищайтесь, добродію!

Напевно, ви зараз подумали: «Він що, хоче запропонувати звичайний WAF і фільтрувати пакети за наявністю /etc/passwd в них?». Ні. Це стандартний метод. Це приклад того, як мислить звичайна людина.

Давайте виявимо трохи фантазії. Чому б нам просто не додати трохи php коду у вміст файлу passwd? І якщо раптом у зловмисника вдасться його приєднати, то наш php код виконається. (Вважаєте маренням? — загляньте на закінчення)

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

Але як додати php код в /etc/passwd адже його синтаксис жорстко регламентований? У кожного користувача є поле "comment" - опис користувача, туди можна вписати все що завгодно (за винятком двокрапки, зрозуміло). Тому беремо та додаємо користувача в систему з потрібним нам коментарем. Після цього /etc/passwd буде містити такий рядок

root:x:0:0:Superuser:/:
daemon:*:1:5::/:/sbin/sh
bin:*:2:2::/usr/bin:/sbin/sh
sys:*:3:3::/:
adm:*:4:4::/var/adm:/sbin/sh
securityuser:*:1001:1001::/:

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

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

Висновок

Так, я цілком усвідомлюю, що все написане вище схоже на марення. І чудово розумію, що ніхто це на практиці не використовуватиме. Але писав не для цього. Писав я, щоб показати приклад нестандартного підходу в галузі захисту.

Дякуємо за увагу =)

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

Захист на рівні сервера:

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

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

phpSHIELD. Прототип SourceGuardian для PHP. Після злиття двох розробників перестав розвиватись як самостійний продукт. Основний функціонал той самий, публічних декодерів немає.

ionCube PHP Encoder. Другий за популярністю комерційний продукт для захисту скриптів. Після появи публічних декодерів для Zend все частіше використовувалися і встановлювалися на віртуальних хостингах. Дозволяє шифрувати не лише скрипти, а й шаблони, XML-документи, зображення, бінарні файли. Прив'язує захищені файли до серверів, є потужний обфускатор, підтримуються всі операційні системи. Публічних декодерів немає, але в деяких випадках знімається deZender.

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

DWebEncoder. Екзотичний захист під Windows, призначений для створення скриптових презентацій та каталогів на компакт-дисках. У встановленому вигляді є щось типу самостійного web-сервера, на якому виконуються закодовані php-скрипти. Публічних декодерів немає.

PHP Compact. Захист швидше теоретичний, ніж практичний. Розроблялася на одному з вітчизняних форумів, але схоже далі за авторські релізи справа не просунулась. Декодерів немає, як і захищених скриптів.

Доповнення з відкритим кодом до старовинних php-акселераторів Turck MMCache та eAccelerator. Переводить скрипти в байт-код з метою підвищення швидкості виконання. Є версії модулів під Windows та Linux. Публічних декодерів немає, але, можливо, відкритий код проекту якось допоможе у вивченні.

Захист на рівні вихідного коду:

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

PHPCipher. Захист є он-лайн сервіс. На сайт завантажується архів із вашими скриптами і назад завантажується вже захищений. Платна ліцензія дозволяє підписувати захищені скрипти своїми даними та використовувати для комерційних цілей. Безкоштовна ліцензія дозволяє використовувати лише особисті потреби. Сам захист є захищеним Zend"ом php-модулем, який підключається до захищених скриптів. Після deZend"а модуля захисту та отримання з нього всіх необхідних констант знімається повністю до вихідного коду. Функції обфускатора немає.

ByteRun Protector for PHP. Комерційний продукт, залежно від типу ліцензії, дозволяє захищати скрипти як на рівні сервера, так і на рівні вихідного коду. Серверний захист зі стандартними можливостями нічого особливого немає. Захист на рівні скриптів знімається дуже легко автоматично та вручну. Публічного декодера на серверну версію немає.

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

CodeLock. Ще один популярний захист, чудовий приклад безграмотного програмування. Є програмою на php, дозволяє кодувати як самі скрипти, так і результат їх роботи в браузері засобами javascript. Скрипти можна захищати паролем, але через бездарну реалізацію пароль легко дізнатися навіть не знімаючи навісний захист. Модуль захисту являє собою засмічений порожнім кодом php-скрипт, який підключається до скриптів, що захищаються. Алгоритм захисту дуже простий, повністю знімається до вихідного коду. Функції обфускації немає.

TrueBug PHP Encoder, з недавнього часу TrueBug PHP Obfuscator & Encoder. Дуже цікавий протектор для дослідження. До версії 1.0.2 використовувалися стандартні засоби php для gzip-компресії, починаючи з версії 1.0.3, авторами був розроблений власний алгоритм стиснення. У новому продукті TrueBug PHP Obfuscator & Encoder додано функцію обфускування та оптимізації вихідного коду. Єдине слабке місце захисту - постійний алгоритм декодування скриптів, але алгоритм змінюється кожної версії захисту. Після аналізу захисту знімається легко в точності до вихідного коду, природно за умови що не був використаний обфускатор.

Zorex PHP CryptZ. Захист, як і CodeLock, є додатком на php, для його роботи потрібна база MySQL. Модуль захисту - скрипт, що підключається на php, зашифрований в кілька шарів. Після аналізу алгоритму знімається дуже легко в точності до вихідного коду. Функції обфускатора немає.

Free PHP Encoder. Безкоштовний онлайновий сервіс для кодування php-скриптів. Модуль захисту являє собою php-скрипт, що підключається, накритий Zend"ом, який треба завантажити з сайту. Після зняття Zend"а і розбору алгоритму захист легко знімається повністю до вихідного коду. Алгоритм захисту постійний, функції обфускатора немає.

Скрипт на php, кодування примітивне, стандартний base64. Більшої уваги не заслуговує і практичного інтересу не становить.

"Сайти банків ламають заради грошей, Пентагон - заради шпигунства, а мій проект нікому не потрібен", - на жаль, саме так вважає більшість власників особистих блогів, інтернет-візиток, віртуальних представництв невеликих компаній. Про те, як захистити сайт, замислюються лише одиниці, а дарма. У сучасних реаліях абсолютно будь-який майданчик, незалежно від типу чи популярності, цікавий в очах хакерів. Кому і навіщо може знадобитися ваш ресурс? Давайте розбиратися:
1. Витівки скрипткіддіс. Жаргонізм позначає хакерів-початківців, які роблять перші кроки на “темній стороні”. Обзавівшись кількома інструментами, або написавши пару власних програм, вони горять бажанням перевірити їхню працездатність на першій жертві, що трапилася, і вибирають, як правило, найбільш легкі (слабко захищені і не оновлені CMS) цілі.
2. Чорне SEO. Послуги нечистих на руку оптимізаторів все ще в ходу - розміщення прихованих посилань у коді проектів, що мають ТІЦ понад 10, як і раніше, практикується. І, перш за все, під удар потрапляють ресурси на двигунах з відкритим вихідним кодом (Joomla, Drupal, OpenCart і так далі).
3. Побудова бот-нет. Захист WordPress за допомогою htaccess та плагінів актуальний ще й тому, що абсолютно будь-який ресурс може бути використаний для створення зомбі-мережі, що використовується в ході DDoS-атак, розсилки спаму тощо.
4. Супутній збиток. Нарешті, атакувати можуть не вас - основною метою буде хостинг, а сайт послужить лише як одна велика вразливість IT-інфраструктури провайдера. Зрозуміло, його доля буде байдужа до хакерів.

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

Отже, можна з упевненістю стверджувати — питання безпеки торкаються абсолютно кожного веб-майстра. І якщо ними знехтувати, всі зусилля з пошукового просування (а це — гроші та дорогоцінний час) здатні відразу піти прахом. Проблема дуже актуальна, тому я вирішив розпочати серію статей, присвячених мережевим загрозам та методам боротьби з ними. У трьох випусках буде розглянуто популярну CMS систему — Вордпрес.

Методи захисту сайту на WordPress

Один із найпримітивніших способів злому — брутфорс. Термін перекладається як “груба сила”, і означає отримання пари логін/пароль методом повного перебору можливих варіантів. Найчастіше брутфорсери намагаються полегшити своє життя, скориставшись похибками в налаштуваннях движка та сервера – це допомагає їм, наприклад, дізнатися ім'я облікового запису, що суттєво скорочує кількість комбінацій. Саме про усунення цих уразливостей, а також про методи боротьби зі спробами несанкціонованого доступу й йтиметься.

1. Використовуйте унікальний логін адміністратора

За замовчуванням, система пропонує створити користувача з ім'ям admin. Однак для захисту сайту на WordPress найкраще використовувати логін, що складається з набору випадкових букв і цифр. На діючому ресурсі ім'я адміністрататора можна змінити без особливих проблем, використовуючи один із двох способів:

Через адмінку. Зайдіть до розділу “Користувачі”, натисніть кнопку “Додати нового” та створіть обліковий запис. У полі “Роль” виберіть “Адміністратор” та підтвердіть операцію. Потім перейдіть від імені щойно створеного обліку, поверніться до розділу “Користувачі”, виберіть “admin” і натисніть “Видалити”. У вікні виставте радіокнопку в позицію "Зв'язати весь вміст" і виберіть нового адміністратора зі списку, а потім натисніть "Підтвердити видалення".
. Використовуючи phpMyAdmin. Набагато простіше здійснити цю процедуру через панель управління базами даних. Виберіть необхідну базу даних, знайдіть таблицю wp_users, знайдіть рядок “admin” (ID=1), натисніть на “Змінити” і впишіть бажане ім'я.

2. Заведіть спеціальний обліковий запис для публікацій

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

3. Поставте складний пароль

Дотримуйтесь загальноприйнятих рекомендацій: довжина пароля повинна становити не менше 10 символів, він повинен бути унікальним і складатися з випадкової послідовності великих і великих букв, цифр і спеціальних знаків.
У жодному разі не можна:
. складати пароль із значущих фраз
. використовувати будь-які фактичні дані (дата народження, дівоче прізвище, номер банківського рахунку, поточний рік…)
Це виключить ризик підбору кодової фрази за словником, а також суттєво збільшить час, потрібний для брутфорсу. Так, злом послідовності з 10-ти символів, що складається тільки з малих літер і цифр (hki458p1fa), займе 10 днів машинного часу для одного ПК, але варто додати великі літери та додаткові знаки (Nv6$3PZ~w1), як цей період збільшиться до 526 років, гарантуючи практично абсолютний захист WordPress. Вигадувати і запам'ятовувати подібні паролі досить складно, особливо якщо ви займаєтеся кількома проектами. Тому, для їх генерації та зберігання краще використовувати спеціальні менеджери, наприклад - KeePassX, що розповсюджується безкоштовно, або звичайний тестовий документ (краще, якщо він буде запакований в архів з паролем).

4. Змініть пароль для бази даних

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

1. Зайдіть до панелі керування phpMyAdmin
2. Перейдіть на вкладку “Користувачі” та виберіть власника бази даних.
3. Натисніть на “Редагування привілеїв”
4. Знайдіть графу “Змінити пароль” та впишіть нову секретну послідовність у відповідні поля
5. Збережіть зміни, натиснувши “Ок”

Тепер залишилося редагувати wp-config.php, інакше Вордпрес не зможе підключитися до бази даних. Знайдіть рядок define('DB_PASSWORD', 'password'); та впишіть новий пароль замість слова password. Зверніть увагу: оскільки знак (‘) застосовується для відокремлення SQL-команд, його слід використовувати у складі секретної фрази.

5. Регулярно оновлюйте паролі

Їх варто міняти принаймні раз на півроку. Позачергова зміна кодових фраз повинна обов'язково здійснюватися після:

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

6. Не забудьте поміняти секретні ключі для куки

Вони розміщуються у файлі wp-config.php. Усього їх 8:

define("AUTH_KEY", "unique key"); define("SECURE_AUTH_KEY", "unique key"); define("LOGGED_IN_KEY", "unique key"); define("NONCE_KEY", "unique key"); define("AUTH_SALT", "unique key"); define("SECURE_AUTH_SALT", "unique key"); define("LOGGED_IN_SALT", "unique key"); define("NONCE_SALT", "unique key");

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

Для підвищення безпеки, послідовності символів за замовчуванням необхідно замінити на унікальні відразу після розгортання CMS. Для зручності розробники створили веб-генератор, розташований за адресою www.api.wordpress.org/secret-key/1.1/salt/ — при заході вам будуть ключі, а якщо оновити сторінку, то комбінації актуалізуються.

7. Подвійна авторизація для адмінки

Htaccess дозволяє додатково захистити сайт Вордпрес шляхом додавання аутентифікації на рівні сервера. Код буде виглядати так:

# Вибираємо файл скрипта авторизації: # Задаємо базовий тип аутентифікації - це означає, що при спробі # звернення до вказаного каталогу або файлу буде запитаний пароль: AuthType basic # Вписуємо текст, який відображатиметься в заголовку форми: AuthName "Identify yourself" # Вказуємо шлях до файлу, що містить кодову фразу : AuthUserFile "/home/сайт/.htpasswd" # Вказуємо, що при зверненні до файлу wp-login.php необхідно ввести пароль: Require valid-user# Забороняємо доступ до файлу.htpasswd третім особам: order allow,deny deny from all

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

Замість “login” підставляємо бажане ім'я. Залишилося згенерувати сам пароль, а також зашифрувати його, адже зберігати подібні дані у відкритому вигляді - недозволена розкіш. І тому існує безліч сервісів, але краще написати потрібний скрипт самостійно. Робиться це так:

1) Створіть у блокноті файл із розширенням.php, наприклад, crypt.php
2) Внесіть туди код, підставивши замість слова "Password" придуманий вами пароль:

3) Збережіть файл і завантажте в кореневу директорію
4) Перейдіть за посиланням имя_сайта.ru/crypt.php - на екрані з'явиться хеш пароля
5) Збережіть це значення у файлі.htpasswd і завантажте його в кореневий каталог, а crypt.php видаліть

Останній штрих – заборона перегляду вмісту директорії веб-ресурсу. Достатньо додати в htaccess єдиний рядок:

Options All-Indexes

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

8. Встановіть капчу

Використання капчі дозволить відсікнути якщо не всіх, то, принаймні, більшу частину ботів-брутфорсерів, а заодно. Каталог плагінів для захисту сайту на WordPress пропонує багато варіантів. Крім підключення фірмового рішення від Google, великий інтерес представляє Captcha by BestWebSoft змішаного (графіка та текст) типу, в основі якої лежать математичні дії. Незалежність від сервісів, наочність та прийнятний рівень складності робить модуль одним із найкращих.

Налаштування не є особливими проблемами. Вкладка “Базові” дозволяє вибрати, де потрібно відображати капчу, а також вказати заголовок та символ для позначення полів, обов'язкових до заповнення.

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

Ще одна корисна можливість - вбудований білий список IP-адрес, для яких капча не відображатиметься.

Результатом встановлення та активації плагіна стане поява форми на сторінці авторизації:

9. Змініть адресу адмінки

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

1. Перейменуйте файл wp-login.php. Використовуйте випадкову послідовність малих латинських літер, цифри та тире. Наприклад: abc-123.php
2. У файлі знайдіть всі згадки wp-login.php і замініть їх на нову назву.
3. Для коректної роботи сайту заміну необхідно зробити також у: wp-activate.php, general-template.php, post-template.php, functions.php, class-wp-customize-manager.php, general-template.php, link-template.php, admin-bar.php, post.php, pluggable.php, ms-functions.php, canonical.php, functions.wp-scripts.php, wp-signup.php, my-sites.php, schema.php, ru_RU.po

Після цих маніпуляцій адмінка розташовуватиметься за адресою сайт/abc-123.php. Доступ до нового файлу слід обмежити та захистити паролем так, як зазначено вище. Крім того, можна ввести в оману потенційних хакерів, створивши фальшивий файл wp-login.php, а також встановивши для нього пароль.

Ще більш простий варіант - використання доповнення "Rename wp-login.php". Після встановлення плагіна для захисту сайту в меню "Налаштування" -> "Постійні посилання" з'явиться нове поле:

10. Вкажіть IP адміна

Додаткову безпеку можна забезпечити у випадку, якщо у вас є статична IP-адреса. Заборонивши доступ до wp-login.php з іншого комп'ютера, крім власного, ви значно ускладните життя зломщикам:

order deny,allow deny from all allow from 127.0.0.1, 127.0.02 #Через кому вказуємо ваші IP-адреси

11. Вимкніть помилки авторизації

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

add_filter("login_errors",create_function("$a", "return null;"));

Для цього виберіть в адмінці "Зовнішній вигляд" -> "Редактор" -> "Функції теми". Прописувати код необхідно після тега

12. Використовуйте захищене з'єднання.

Для шифрування трафіку між комп'ютером користувача та веб-сервером існує протокол https, використання якого унеможливлює перехоплення важливих даних, у нашому випадку — ідентифікаційних. Щоб його активувати, спочатку потрібно придбати SSL-сертифікат, що виконує відразу дві функції: посвідчення справжності веб-ресурсу і шифрування інформації, що передається. Отримати його можна у спеціалізованих центрах, або у низки реєстраторів доменних імен. Для некомерційних цілей цілком достатньо придбати безкоштовний сертифікат початкового рівня (такі пропонує компанія www.startssl.com). Що ж до процесу установки, зазвичай він докладно описаний у довідковому розділі хостера.

Отримавши SSL-сертифкат, необхідно налаштувати переадресацію адміністративної частини веб-ресурсу на захищене з'єднання. У випадку Вордпрес це робиться за допомогою наступної конструкції:

Options +FollowSymlinks RewriteEngine On RewriteCond %(HTTPS) =off RewriteCond %(REQUEST_URI) =/wp-login.php RewriteRule (.*) https://%(HTTP_HOST)%(REQUEST_URI)

Також форсувати використання сертифікатів SSL можна лише на рівні движка. Для цього відкрийте файл wp-config.php та додайте після

define("FORCE_SSL_ADMIN", true);

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

Options +FollowSymlinks RewriteEngine on RewriteCond %(HTTPS) =off RewriteRule ^(.*)$ https://%(HTTP_HOST)%(REQUEST_URI)

13. Блокуйте зловмисників

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

Order Allow,Deny Allow from all Deny from 127.0.0.1, 127.0.02 #Вказуємо небажані IP

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

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

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

Галочку навпроти “Блокувати IP за будь-якого запиту wp-login.php” варто ставити в тому випадку, якщо ви зміните адресу адмінки способом, описаним раніше.

Для цього можна використовувати і власний інструмент WP Cerber:

Режим плагіна для захисту сайту “Цитадель” також не потребує додаткового настроювання. Він призначений для “консервації” проекту за масованої брутфорс-атаки. Галочку навпроти "Записувати спроби входу в файл" краще зняти - це допоможе виключити додаткове навантаження на сервер.

Вкладка “Списки доступу” використовується для створення “чорного” та “білого” списку IP (якщо у вас є статична адреса, обов'язково внесіть її до списку довірених), а розділ “Інструменти” дозволяє здійснювати імпорт та експорт внесених раніше налаштувань. Втім, ці можливості не потребують окремого розгляду.

14. Перемістіть конфігураційний файл

Як ми з'ясували вище, wp-config.php зберігають такі критично важливі дані, як логін і пароль для доступу до MySQL, а також ключі API. Наступний крок начебто очевидний — захист WordPress через htaccess за допомогою обмеження доступу до файлу:

Order allow,deny Deny from all

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

15. Додайте перевірку REFERER

Метод, який добре зарекомендував себе при захисті WordPress від спаму, допоможе і у разі протистояння брутфорсерам. Адже перебір паролів — аж ніяк не ручна робота: для цього використовуються спеціалізовані програми. А значить, включивши перевірку заголовків у вхідних запитах, можна відсікти ботів з порожнім HTTP REFERER:

RewriteEngine On RewriteCond %(REQUEST_METHOD) POST RewriteCond %(REQUEST_URI) .(wp-comments-post|wp-login)\.php* RewriteCond %(HTTP_REFERER) !.*сайт.* RewriteCond %(HTTP_US *) http://%(REMOTE_ADDR)/$1

16. Захистіть XML-RPC

Починаючи з версії 3.5, з Вордпрес зникла можливість відключення протоколу виклику віддалених процедур XML-RPC. В основному він потрібен для взаємодії з мобільними програмами, проте подібний функціонал потрібний далеко не кожному. При цьому xmlrpc.php активно використовується для проведення DDoS-атак, будучи ахіллесовою п'ятою всього проекту.

Крім того, хакери придумали використовувати XML-RPC для брутфорсу. Використання методу wp.getUsersBlogs дозволяє здійснювати перебір облікових даних набагато швидше, ніж через форму адмінки. Оскільки багато викликів XML-RPC вимагають авторизації, запит виду:

wp.getUsersBlogs admin 12345

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

1) Заблокувавши доступ до файлу xmlrpc.php через htaccess

require_once(ABSPATH . "wp-settings.php");

необхідно прописати

function remove_x_pingback($headers) ( unset($headers["X-Pingback"]); return $headers; ) add_filter("wp_headers", "remove_x_pingback");

4) Використовуючи плагін Control XML-RPC publishing, що повертає в "Налаштування" -> "Написання" відповідну опцію:

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

17. Слідкуйте за брутфорс-атаки

Насамкінець варто згадати про цікавий плагін для логування спроб злому - Authentication and xmlrpc log writer. Хоча той же WP Cerber має вбудовані засоби моніторингу, даний модуль буде однаково корисний, особливо тим, кому потрібні можливості описаного вище протоколу. AX LogWriter вміє відстежувати брутфорс через xmlrpc.php, завдяки чому можна оцінити рівень загрози та доцільності повної відмови від використання його можливостей. Нарешті, тим, хто зовсім не займався безпекою свого проекту, плагін для захисту сайту розплющить очі на важливість перерахованих заходів.

Використання AX LogWriter не є складним. Після встановлення меню адмінки з'явиться відповідний розділ, де можна внести всі необхідні зміни:

У полі “Error Type” виберіть спосіб збереження. Підтримується запис у системний лог, сервер сервера Апач, а також можливість створення кастомного файлу. В останньому випадку для нього можна також налаштувати ім'я (Custom Error Log Name) та директорію (Custom Error Log Path). Це відкриває широкі можливості для системного адміністратора – наприклад, рішення можна використовувати разом із fail2ban. Також не забудьте вибрати відповідний часовий пояс у графі Timezone.

Кастомний лог можна переглядати безпосередньо з адмінки на сторінці Custom Log Viewer:

Підсумуємо:

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