Редагуємо файли WordPress для підвищення рівня безпеки двіжка

Базовий захист CMS від можливих атак

Сьогодні поговоримо про захист ЦМС-ки WordPress від різного роду зовнішніх загроз, яким піддані буквально всі сайти інтернету. Не існує сайту, який не можна було б зламати. Зламують все. Великі інтернет портали і банківські онлайн системи також на 100% не захищені від атак хакерів. І це при тому, що там у них на зарплатні сидять досвідчені програмісти, що забезпечують захист.

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

Твій сайт, скоріше всього, не зацікавить серйозного хакера, але забезпечити базовий захист свого дітища таки потрібно. Щодня до мільйонів юних програмістів приходить свідомість того, що не погано б випробувати на практиці отримані знання на черговому вебінарі. У цій статті я розповім як захистити свій блог від таких ось незміцнілих умів. Тобто, як самостійно забезпечити мінімальний (базовий) захист WordPress.

Інсталяційний файл «install.php»

Видалити не можна залишити

В вище представленому рядку, кожен самостійно вирішує де поставити кому. Багато хто радить залишити цей файл на сервері під іншим ім'ям (перейменувати). Інші кажуть, що його можна просто перемістити в якусь іншу директорію (папку). А я раджу просто видалити цей файл після інсталяції Вордпрес, тобто, поставити кому після слова «Видалити». Не питай мене навіщо, просто видали його з серверу просто зараз. А якщо він тобі такий дорогий, збережи його на своєму ПК в якійсь папці.

Де шукати файл «install.php»

Отже, заходиш на сервер через FTP-клієнт, відкриваєш кореневу директорію сайту, ім'я якої може відрізнятися в залежності від налаштувань серверу на хостингу. Ім'я кореневої папки може бути абсолютно різним, наприклад, «htdocs», «public_html», «www», «www.realcase.lviv.ua» і т.д. і т.п. Цей інсталяційний файл лежить в папці «wp-admin». Знаходиш в цій папці файлик під назвою «install.php», виділяєш його красивим синеньким кольором, і впевненим рухом руки, сміливо натискаєш кнопку «Del» на клавіатурі. Або ж, як я вже вище радив, перетягуєш його кудись подалі...

Файл «install.php»

Інформаційний файл «readme.html»

Тут однозначно лише «видалити» без всяких «залишити»

Інформаційний файл «readme.html»

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

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

Видаляємо інші сміттєві файли

Файл «readme.txt», «license.txt» та ін.

Відправляючи на той світ файл «readme.html», не забуваємо слідом за ним відправити туди ж і його побратимів: — текстові файли «readme.txt», «license.txt», «COPYING.txt» і іже з ними. Знову ж таки, не питай навіщо, просто зроби це. Ці сміттєві файли можуть бути заховані дуже глибоко. Тому, слід перевірити всі папки двіжка.

Як швидко знайти і видалити всі сміттєві файли?

Видаляємо сміттєві файли

Файлів з розширенням «.txt» в папках двіжка WordPress може бути дуже багато, штук 16 і більше. Назви можуть бути написані як в нижньому, так і в верхньому регістрі.

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

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

Відкриваєш на своєму комп'ютері папку з двіжком, вводиш в поле пошуку цей рядок «.txt» (1), і чекаєш долю секунди на результат. Виділяєш блакитним кольором все знайдене "добро", і відправляєш в кошик (2). Але краще відразу відправити це сміття в кращий світ, притиснувши клавішу «Shift» + «Del». Бо не варто зайвий раз засмічувати подібним сміттям кошик, тобто системний диск.

Редагуємо файл «wp-config.php»

Забороняємо редагування файлів двіжка з адмін-панелі

Щоб раз і назавжди заборонити редагувати будь-які файли двіжка безпосередньо з адмін-панелі Вордпресу, потрібно відредагувати конфігураційний файл з ім'ям «wp-config.php». Цей файл лежить в корені сайту, там же ж де до недавнього часу безтурботно лежав "передчасно покійний" «readme.html», — пам'ятаємо..., — скорбимо... :).

Заборона редагування файлів

Отже, відкриваєш на редагування php-файл з ім'ям «wp-config.php», використовуючи текстовий редактор «Notepad++», і вписуєш в нього (можна скопіювати рядок нижче) наступний php-код, див. скріншот вище і код нижче. define( 'DISALLOW_FILE_EDIT', true ); Прописати даний рядок коду можеш в будь-якому місці даного файлу. Для наглядності і певної семантики, я прифастриґував цей код відразу під дефолтним блоком констант «define()», в рядку 41.

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

Що робить цей рядок коду?

Цей рядок коду блокує доступ до файлу під назвою «theme-editor.php», який лежить в папці «wp-admin», ось повний шлях до цього файлу: «mysite.com/wp-admin/theme-editor.php ». Заблокувати доступ також можна і за допомогою файлу «.htaccess», про який ми поговоримо трохи нижче. Отож, як ми можемо перевірити, що все блокується і ніхто не зможе редагувати файли з адмінки? Відповідь дивимося і читаємо нижче.

Блокування редактора теми двигунця WordPress

Зайшовши в адмін-панель, наводимо мишку на пункт меню «Зовнішній вигляд» і бачимо в самому кінці випадаючого меню пункт під назвою «Редактор тем» (1), див. скріншот вище. Після додавання нашого рядка коду, цей пункт меню зникає, тобто стає недоступний з адмінки (2). Проте, більш-менш обізнана людина може вбити в адресний рядок шлях до цього файлу — «mysite.com/wp-admin/theme-editor.php» (3), і таким чином спробувати викликати редактор теми Вордпрес. Але тут його підстерігає гірке розчарування: "Вибачте, вам не дозволено переглядати цю сторінку". Отакої...

Змінюємо дефолтний префікс таблиць в базі даних WordPress

Під час інсталяції Вордпрес, користувачеві доступний пункт форми, в якому можна змінити префікс таблиць в базі даних WordPress. За замовчуванням там прописано значення «wp_». Заміни це значення на якесь інше, наприклад, «rcs_», див. скріншот нижче.

Префікс таблиць в базі даних

Якщо під час інсталяції WordPress ти залишив(-ла) префікс таблиць БД без змін, — не біда. Це значення можна запросто змінити в нашому, наразі відкритому, файлі конфігурації — «wp-config.php». Скролиш на 25-30 рядків донизу, і знаходиш ось такий рядок коду: $table_prefix = 'wp_'; Змінюєш значення перемінної — «wp_» на будь-яке інше і зберігаєш текстовий документ. Все, префікс таблиць змінено. Унікальний префікс таблиць, звісно ж, не стане особливо важкою перепоною на шляху зловмисника, проте він дещо ускладнить процес проникнення. Після цього, файл «wp-config.php» можна закрити і залити на сервер.

Конфігураційний файл «.htaccess» веб-сервера «Apache»

Нижче зображено фрагмент конфігураційного файлу веб-сервера «Apache» з керуючими (забороняючими) директивами. Цей файл іменується як «.htaccess». За допомогою даного файлу, у нас є можливість управляти поведінкою веб-сервера «Apache» і йому подібними. Ми можемо забороняти або дозволяти якісь дії як для користувачів, так і роботів, тобто програм.

Директиви файлу .htaccess для захисту

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

  1. AddDefaultCharset utf-8

    Почнемо з першого рядка, який зображено на скріншоті вище. Це керуюча інструкція для веб-сервера, яка визначає кодування за замовчуванням. Вона вказує серверу в якому кодуванні потрібно віддавати документи клієнту, тобто нам з тобою і всім нашим гостям. Значення директиви «utf-8» — це стандарт кодування документів (Unicode Transformation Format у восьмибітному поданні Юнікоду).

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

  2. DirectoryIndex index.php index.html

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

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

    Варто відзначити, що індексний файл не обов'язково повинен носити горду назву «index», він може бути з яким завгодно ім'ям, наприклад, «golovnyy-fayl.php». Директива «DirectoryIndex» не має прямого відношення до системи безпеки сайту, але вона, так само як і перший рядок, не буде зайвою в файлі «.htaccess».

  3. Options -Indexes

    Забороняємо відображення вмісту папок

    Заборона лістингу директорій

    Якщо попередні дві директиви не мають відношення до захисту блогу від злому, то інші три мають безпосереднє відношення до системи безпеки сайту. Під номером три розташована інструкція що забороняє лістинг директорій. Тобто, вона потрібна для того, щоб ніхто не зміг побачити вміст папки на сервері, при відсутньому в ній індексного файлу. На скріншоті нижче яскраво продемонстровано, що побачить людина, коли введе в адресний рядок ось такий запит: «mysite.com/wp-includes/».

    Заборона лістингу директорій

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

    Після того, коли ти додаси в файл «.htaccess» рядок «Options -Indexes», сервер зловмисникові покаже веселу комбінацію з кулака і великого або середнього пальця (опціонально). Тобто, при запиті «mysite.com/wp-includes/», сервер видасть сторінку з помилкою 403, що означає: доступ до папки «wp-includes» заборонений.

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

  4. Захищаємо конфігураційний файл серверу «.htaccess»

    Виявляється, захисник теж потребує захисту

    Еге ж, так воно і є, захисника також потрібно захищати. І робиться це за допомогою нижче наведеного коду. У коді нижче, переноси зелених рядків обов'язкові. Тому стеж за цим. Інакше отримаєш від сервера по шапці, тобто помилку 500.

    <files .htaccess>order allow,denydeny from all</files>

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

  5. Захист конфіг-файлу двіжка від стороннього доступу

    Використовуємо файл .htaccess для захисту «wp-config.php»

    Не дивлячись на те, що файли «.htaccess» і «wp-config.php», який ми редагували трохи вище, лежать на одному рівні (в кореневій директорії сайту), все ж до конфігураційного файлу сервера «.htaccess» пробитися дещо складніше ніж до звичайного «.php». Тому, варто захистити конфігураційним файлом сервера, такий же ж конфіг-файл двіжка.

    <files wp-config.php>order allow,denydeny from all</files>

    Для цього потрібно прописати в «.htaccess» кілька, вже нам знайомих, рядків, див. код вище. Це правило всім забороняє доступ до файлу «wp-config.php» іззовні. Цей конфігураційний файл двіжка містить багато важливих даних, тому його слід гарнесенько захищати. Як мінімум, його потрібно захистити даними способом.

Додаємо корисні функції у файл «functions.php»

Додаткові налаштування безпеки

Щоб підвищити рівень безпеки сайту, можна додати в файл «functions.php» кілька рядків коду, який, до певної міри, допоможе захиститися від зовнішніх загроз. Отже, відкриваємо в «Notepad++» php-файл з назвою «functions.php», який лежить в директорії використовуваної теми Вордпрес. Наприклад, якщо ти юзаєш в своєму блозі тему «Twenty Seventeen», відтак, шукати цей файл потрібно за наступною адресою: «mysite.com/wp-content/themes/twentyseventeen/functions.php».

Редагування файлу «functions.php»

У відкритому файлі ставимо курсор відразу ж над першою функцією або між блоками коментарів (1), і тричі тиснемо на Ентер (2). В результаті, отримуємо пару порожніх рядків, див. скріншот вище. Після цього, у порожній простір вставляємо 5 нових функцій, які я розділив на три блоки, див. скріншот нижче.

Додавання нових функцій у файл «functions.php»

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

remove_action( 'wp_head', 'wp_generator' );remove_action( 'wp_head', 'wlwmanifest_link' );remove_action( 'wp_head', 'rsd_link' );

Ці три функції видаляють непотрібні HTML елементи з блоку «head», який розташований в самому верху HTML-коду сторінки. Побачити ці елементи можна в браузері. Зараз розповім як це зробити.

Дивимося вихідний код поточної сторінки

Відкриваємо наш сайт, і, навівши курсор мишки на вільну від посилань область сторінки, клікаємо правою клавішею (1). З'явиться вікно з пунктами меню. Вибираємо передостаннє — «Переглянути джерело сторінки» (2), див. скріншот нижче. Або ж, натискаємо на клавіатурі комбінацію клавіш «Ctrl+U».

Переглянути джерело сторінки

Відкриється сторінка в новій вкладці, на якій буде багато різних і, наразі, незрозумілих рядків коду. Щоб прискорити процес пошуку шуканих елементів у всій цій каші, знову натискаємо на клаві комбінацію «Ctrl+F». У правому верхньому куті браузера з'явиться вікно пошуку, в яке вставляємо фрагмент з коду, наприклад, «generator», і тиснемо на Ентер. Шукане слово буде миттєво знайдено і виділено помаранчевим кольором, див. скріншот нижче.

Метатеги на відкритій сторінці generator wlwmanifest та rsd

На картинці вище видно, як WordPress за допомогою метатега «generator» повідомляє цілому світу про версію нашого двіжка, яка, на сьогоднішній день — «5.1». І це може послужити погану службу для нашого блогу. Адже знаючи версію Вордпресу, зломщикові буде простіше розробити алгоритм майбутньої атаки. А стосовно двох елементів «link», які підключають XML файли, вони також не несуть якоїсь користі. Тому і їх сміливо видаляємо.

Забороняємо використання HTML-тегів у коментарях

Щоб убезпечити базу даних від впровадження шкідливого коду, потрібно заборонити користувачам використовувати в коментарях HTML-теги. Самі по собі HTML-теги абсолютно нешкідливі, і не становлять якоїсь небезпеки. Але серед них є деякі елементи, які здатні підключати сторонні файли зі скриптами, наприклад, «script», «frame», «iframe», «embed» і «object». Саме вони і становлять головну небезпеку.

add_filter( 'pre_comment_content', 'esc_html' );

Функція представлена вище, перетворює спеціальні символи в HTML сутності при додаванні їх в базу даних. І навпаки, перетворює HTML сутності в спецсимволи при їх виведенні з бази даних. Це свого роду фільтр-перетворювач перед вхідними даними в базу даних.

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

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

Відключаємо підказки Вордпресу про невірний логін або пароль

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

Підказки WordPress про неправильний логін або пароль

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

function no_wordpress_errors(){return 'Може годі вже ламати адмінку?';}add_filter( 'login_errors', 'no_wordpress_errors' );

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

Кодування та збереження текстових документів

UTF-8 без BOM

Невірне кодування документу

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

Щоб кириличні символи в php-файлах правильно відображалися в браузері, перед їх збереженням потрібно змінити дефолтне кодування «ANSI» на «UTF-8».

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

Неправильне кодування файлу може створити проблеми більш серйозні. Я не буду сьогодні втомлювати тебе новою темою про кодування, поки що відкладемо в сторону це питання. Скажу лише, що кодування документів в «UTF-8» мусить бути без «BOM».

Абревіатура «BOM» розшифровується як «Byte Order Mark». Простіше кажучи, «BOM» — це символи на початку найпершого рядка документу. Ці символи текстовий редактор нам не показує. Однак, при обході наших скриптів інтерпретатором PHP, ці приховані символи можуть привести до фатальної помилки через недосконалість самої мови PHP.

Як змінити кодування документу «ANSI» на «UTF-8»

Робиться це в будь-якому текстовому редакторі, який наділений такою можливістю. Наведу приклад заміни кодування файлу за допомогою кращого безкоштовного редактора «Notepad++». Про нього ми поговоримо в наступній статті, зараз на цьому моменті не будемо зупинятись. Отже, файл відкрито. Дивимося в правий нижній кут, і бачимо кодування «ANSI» або будь-яке інше. Щоб перекодувати документ, потрібно відкрити меню «Кодування», і вибрати пункт «Перетворити на UTF-8», див. зображення нижче.

Заміна кодування документа з «ANSI» на «UTF-8»

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

Загальні рекомендації з безпеки

Видаляємо усі невикористовувані теми

Зайди на сервер через будь-який файловий менеджер, і відкрий сховище тем WordPress за цією адресою: «mysite.com/wp-content/themes/». Там ти побачиш папки з назвами тем. Свою тему залиш, а решта видали. Кожен використовуваний плагін або тема — це потенційна дірка в безпеці. Чим їх менше, відповідно, менше дірок.

Видаляємо непотрібні плагіни

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

Логін адміністратора сайту

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

Пароль від адмінки

Щоб процес підбору пароля відняв у зловмисника достатньо часу для того, щоб той залишив свій задум, пароль слід робити складним. Тобто він повинен складатися з 16-20 символів. Не варто використовувати восьми-символьні паролі або менше цього. Отже, пароль повинен бути довгим і нечитабельним. Відтак, він повинен складатися з латинських букв у різних регістрах, цифр та спецсимволів: @-#_$+()%!^&*.

Наприклад, якщо навмання пробігтися по клавіатурі пальцями, в результаті цих акордів, отримаємо приблизно ось це: «f51sl68d9m1f0m2j5». Тепер приберемо звідси кілька цифр, припудримо парочкою спецсимволів і, вишенька на торт, — поміняємо регістр в деяких літерах. В результаті чого, ми отримаємо ось такий чудовий пароль для нашої адмінки: «F5_sL6-8#D&9m*F0M+2j». Звісно ж, такий код ти ніколи в житті не запам'ятаєш, тому саме час згадати мої рекомендації щодо заходів безпеки при зберіганні паролів. Ну і не забувай цей пароль періодично оновлювати, додаючи, прибираючи або переміщаючи у ньому символи.

Не зберігай паролі в браузері

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

Ось, власне, і все. Сьогодні ми прикрили діри в системі безпеки блогу. Але це той мінімум, так званий, must-have, який повинен мати кожен сайт на Вордпресі. Про дірки поменше, яких достатньо для злому, я розповім в майбутніх статтях. Сьогодні ми з тобою зробили небагато, проте, такий-сякий, а замочок на дверцятах блогу вже висить. З чим я тебе і вітаю. До зустрічі!

Щоб зрозуміти наскільки ти в темі, пройди тест 👇
  • 100 секунд на проходження тестуRealCase

    Тест
  • 5 питань по тематиці сайту
  • 4 варіанти відповідей на кожен
Готовий(-а) перевірити рівень своїх знань?

  •  Цей тест ще ніхто не проходив, ти будеш першим(-ою)

   
  
 
 
📚Не проґав!
💬Коментарі (Ще немає... твій буде першим)  
    • Ліміт 2000 символів
    • залишилось: