Помітити, що сайт взламаний не завжди вдається. Ось у мене був випадок, коли клієнт чисто випадково помітив, що на його сайті внизу були сторонні посилання на сайти з продажу ліків. В інтернеті це називається pharma hack. Але щоб виявити, що ваш сайт заражений цим “вірусом” потрібно його відвідати, але з певними умовами:
— це має бути захід через гугл по пошуковій фразі
— з цієї ip-адреси ви ще жодного разу не заходили на свій сайт
— з цього броузера ви ще жодного разу не заходили на свій сайт (або почистити кукі).
Саме через те, що “лєві” посилання показуються лише при цих умовах, власники сайтів навіть не здогадуються, що їх сайт був зламаний.

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

1.Почну з банального – не використовуйте в якості адміністратора логін admin (а також його похідні: adminadmin, administrator, root). Якщо у вас уже є такий логін, то створіть новий акаунт з іншим нестандартним іменем, наприклад: direktor. Для цього нового акаунта дайте права адміністратора, а акаунт admin видаліть, або ж дайте йому роль “підписник”. Ну і звісно, що потрібно обирати складні паролі – з цифрами, буквами в верхньому регістрі і достатньо довгим (мінімум 8 символів).

2.Встановіть плагін Limit Login Attempts. По замовчуванню, він буде блокувати всіх, хто 5 разів неправильно введе логін-пароль на 20 хвилин. Якщо з цього айпі будуть нові спроби підбору паролю, то плагін заблокує доступ вже на 24 години. Це значно покращить захист вашого сайту. Бо зараз існують цілі мережі ботів, що тільки тим і займаються, що підбирають паролі до адмінки. Цілком можливо, що саме в цю секунду на ваш сайт здійснюється масована атака ботів, що підбирають пароль.

Окрім цього, я використовую такий хитрий хід: для логіну admin, даю роль “підписник” і ставлю йому простий пароль: 123456. Боти дуже швидко підбирають пароль, входять в адмінку, але нічого більше зробити не можуть ;)

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

3. Встановіть плагін Better WP Security. Це дуже потужний плагін для продвинутих юзерів. Деякий функціонал в ньому потрібно включати з обережністю, бо він може вплинути на інші плагіни, які заглючать від цього. Під такими галочками, що включать конфліктний функціонал, є попередження, так що будьте уважні.
По суті він може замінити і плагін Limit Login Attempts, бо також має функцію блокування від підбору пароля. 

Я налаштовую його так: вмикаю 404 detection та File Change Detection та вмикаю надсилання емейлу про щоденні логи по цим пунктам. В Directory Check List вніс папку wp-content/cache, щоб зміни в ній не фіксувались. Більше я нічого не використовую з його функціоналу. І ще нюанс: листи з цього плагіну гугл вперто відправляє спам, тож майте це на увазі.

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

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

Давненько я нічого нового не публікував, все займаюсь іншими речами: роблю свою першу тему для вордпресу, вивчаю css та jquery, взявся за сайт присвячего доктору Хаусу, найняв туди контент-менеджера, тепер всі прибутки з того сайту йдуть їй на зарплату, але впевнений, що це швидко окупиться.

А ще давно я собі намітив в todo’шках, аби оптимізувати код сторінок сайту, бо вони занадто багато займають. Загалом проблема великого розміру коду сторінок властива всім вордпресовським блогам, на які поначіплювано багато плагінів, чи використовують преміум-теми. Колись провіряв по сервісу webo.in свій блог, так він знайшов багато слабких місць і дав довжелезний список рекомендацій, як покращити код сайту і зробити його швидшим та легшим для завантаження.
Коли я то все почав вручну робити, то вже на перших пунктах затикався, бо не знав як додавати ETag / Last-Modified для файлів, зменшувати кількість css та javascript’ів теж непросто, бо не знаєш, чи надовго в тебе той чи інший плагін, який їх використовує. Короче, я забив на то всьо і зрозумів, що ще не доріс до такої оптимізації.

І тут, буквально позавчора натикаюсь на один скрипт, що оптимізує сайти якраз по цим параметрам. А як я втішився, коли побачив, що для wordpress’у вони випустили плагін, що робить всю ручну оптимізацію автоматичною, по натисканню однієї кнопки. Ляпота!

Загалом суть цього плагіну така: він об’єднує всі css-файли в один, всі js скрипти теж в один файл, потім його стискає gzip’ом, додає ETag / Last-Modified для усіх файлів, мініфікує сторінки (minify), додає кешуючі заголовки до всіх файлів, а в наступних версіях навіть обіцяють автоматом збирати CSS-спрайти (CSS Sprites).

І все що треба, так це скачати плагін PHP Speedy, активувати, та перейти на сторінку його налаштувань, де за допомогою підказок ви дізнаєтесь, що треба зробити. На правильних хостингах (яким я вважаю TOPUA.net) нічого не треба змінювати, а ось на більшості прийдеться змінити права доступу на файл конфігу плагіну, та дати права 777 на папку cache цього плагіну, в якій і будуть зберігатись наші оптимізовані css та js файли.

Я коли провірив, то очам своїм не міг повірити. Ось характеристика моєї головної сторінки блогу до оптимізації (дані взяті з плагіну Yslow):

А ось після того, як я натиснув кнопочку ‘Activate’ в плагіні PHP Speedy:

Вражає, правда? (тут А це найвища оцінка а F це найгірша, така американська система оцінок)

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

Пробуйте і ви. Провірити можна на око, а можна отримати і точні дані завдяки аддонам Firebug (вкладка NET) та Yslow.

В моєму випадку з бази я викинув 67% сміття, у вас я думаю показники будуть більші. Отож по порядку:

1. Clean Options – чистим опції
2. Знищуємо таблиці від непотрібних плагінів
3. Міняємо кодування бази даних Вордпресу
4. Вилучаємо ревізії постів
5. Викидаєм зайве з Dashboard

А почалося все з цього:

Зверніть увагу на таблицю wp_options – 1.3Mb – це ж нечуванно!

Clean Options – чистим опції
Саме прикріше те, що “сміттєва” інформація знаходиться в таблиці wp_options (мабудь розраховували на те, що звичайний юзер побоїться в неї залізти). Отож скачуємо плагін Clean Options і запускаємо його кнопкою Find Orphaned Options. Ви побачите довжелезний список опцій що були добавленні плагінами, що стоять у вас, або колись стояли. От видалити ті опції плагінів що уже не стоять задача нелегка, адже там явно не вказано від якого плагіну той чи інший запис, тому прийдеться діяти наосліп озброївшись пошуком по гуглю. (можливо все таки варто зробити бекап бази перед цими діями, я відповідальності за ваші дії не несу). А нижче ви побачите список новин з rss-каналів що появляються в Панелі керування.

Ну признайтесь, хтось з вас їх читав? Я ні, а саме ці новини і займають по пару мегабайт в ваших базах даних вордпресу. От від них ми і безболісно позбавимось. Виділяєте їх і тиснете на “View Selected Options Information” де ви побачите зміст цих полів. Перед вами простягнеться довжелезне простирадло з довжелезним скроллом зі змістом того “сміття”. Одразу ж після завершення завантаження сторінки жміть End на клавіатурі, вибирайте галочку “Yes, Remove ALL of these options from the wp_options table.” і Submit. Здавалося би все — діло зроблене, але насправді ці дані все ще лишились в базі і для того щоб їх остаточно знищити слід зробити оптимізацію таблиць. Для цього заходимо в PhpMyAdmin і вибираємо таблицю wp_options а внизу вибираєм пунктик “Optimize Table”

Знищуємо таблиці від непотрібних плагінів

Як швидко дізнатись, що таблиця не “рідна-вордпресовська” а від плагіну?
По замовчуванню вордпрес створює 10 таблиць:
wp_comments
wp_links
wp_options
wp_postmeta
wp_posts
wp_terms
wp_term_relationships
wp_term_taxonomy
wp_usermeta
wp_users
Думаю у вас кількість таблиць значно більша і вияснити яка з них іще використовується, а яка вже ні, справа дещо складніша. Я лише так “на око” по назвам прикидував, здебільшого в назвах міститься натяк на те до якого плагіна вона відноситься. Ті таблиці що мені були невідомі я просто назву їх закидував в гугль і дивився результат. Таким чином з бази я викинув 21-у таблицю із 35!

Виправлення помилки в кодуваннях таблиць бази даних WordPress

В мене виявилось що по налаштуваннях MySql на хостингу всі нові таблиці створювались в кодуванні latin1_swedish_ci що є зовсім неправильним, але легко виправляється. Для цього в PhpMyAdmin в закладці Operations(Операции) знаходимо рядок: Collantions (Сравнение) і міняємо його на utf8_general_ci. Go! ok.
А от як бути з тими що вже в неправильному кодуванні? В інтернеті є описаний спосіб як його поміняти, але мені було простіше видалити всі таблиці в неправильному кодуванні і заново активувати плагіни що їх створювали (але в цьому я був впевнений, а вам так діяти не рекомендую, краще залишіть як є).

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

define('WP_POST_REVISIONS', false);

а потім все в тому ж PhpMyAdmin (Ви ж іще не закрили вкладку із ним, чи не так ;)) робимо запит:

DELETE FROM wp_posts WHERE post_type = 'revision'; 

Опісля виділяємо таблицю wp_posts і робимо її оптимізацію (надіюсь ще пам’ятаєте, пару абзаців вище я писав як ще робиться)

Викидуєм зайве з Dashboard (панель керування)
Ну і нарешті заліземо в один файлик — wp-admin/index.php з якого викинемо зайві рядки, аби нові rss-новини більше не засмічували базу.

<div id="dashboard-widgets-wrap">

<?php wp_dashboard(); ?>

</div>

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

і я нею задоволений, з 3-ох мегабайт зменшити базу до 1 метра!
p.s. До речі, плагін Clean Options після всіх цих дій, можна вимкнути, а коли обновитесь до нової версії WordPress то знову ввімкнете і повторите ці дії.

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

<meta name="generator" content="WordPress 2.5.1" /><!-- leave this for stats -->

Для цього в functions.php вашої теми слід добавити два рядочки:

<?php
  remove_action('wp_head', 'wp_generator');
  remove_action('wp_head', 'wlwmanifest_link');
?>

а якщо вам надоїли попередження про оновлення версії вордпресу, то можна і їх вимкнути (до речі я теж схиляюся до думки що версія 2.3.3 є самою оптимальною)

Для цього в файлі wp-includes/update.php коментуєм значком # “лишній рядок” :

#add_action( init', 'wp_version_check');

Це до речі певним чином і прискорить роботу в адмінці.