Десять років brute-force атак, фейкових роботів і логів, більших за базу. У якийсь момент вибір став простим: власний плагін безпеки чи далі налаштовувати чужий чи написати шар, який мені потрібен.
Чого я хотів
Фільтрації до запуску WordPress. Журналу, який читає людина. Жодного банера з апселом в адмінці. Жодної залежності від хмари для рішення, яке можна ухвалити на сервері. Ці чотири вимоги відсікли більшу частину ринку.
Від чого відмовився
Від розповзання функцій. Плагін безпеки, який ще робить бекапи, SEO і попапи, отримує три нові способи зламатися. Я тримав вузький обсяг: запити, боти, вхід, логи.
П’ять уроків
- Рання фільтрація краща за розумну. Запит, відхилений до PHP, майже нічого не коштує.
- Логи вирішують, чи зможете ви налаштувати систему о третій годині ночі.
- Хибні спрацювання - головний ворог: один заблокований checkout дорожчий за сотню ботів.
- У кожної функції має бути вимикач і білий список.
- Підтримка і є продукт. Інструмент безпеки, що перестав оновлюватися, стає уразливістю.
Чим це коштує
Часом. Оновлення, сумісність із кешем і CDN, нові патерни ботів, підтримка. Власний плагін не безкоштовний через те, що ви його написали; він безкоштовний до першого релізу WordPress, який його зламає.
Коли брати готовий
Якщо потрібен один захищений сайт і немає особливих вимог, беріть підтримуваний плагін із зрозумілим changelog. Свій пишіть, коли вимога специфічна, ви можете його обслуговувати і вам подобається ця задача. Інакше ви купуєте другу роботу.
Перш ніж писати свій
- Ви можете підтримувати його роками, а не місяцями.
- Вам потрібна поведінка, якої немає в готових плагінів.
- Ви вмієте тестувати під навантаженням і читати логи.
- У вас є план відкату після невдалого оновлення.
- Ви приймаєте навантаження підтримки.
- Ви робите це не заради економії.
Три питання, які ставлять
Власний плагін безпечніший? Лише поки його підтримують. Закинутий власний гірший за підтримуваний чужий.
Можна ставити клієнтам? Лише з планом підтримки й описаним процесом оновлень.
Як часто він змінюється? Так само часто, як WordPress і трафік ботів. Код безпеки не буває готовим.
Я написав свій, бо хотів цю роботу. Це єдина чесна причина починати.
Як я перевіряю реліз
Кожен реліз проходить один список: чистий WordPress, сторінка з кешу, оформлення замовлення, вхід із неправильним паролем, відомий User-Agent бота і живий браузер. Якщо правило ламає щось із перших чотирьох, реліз не виходить. Список лежить у репозиторії, а не в голові.
Що поза обсягом
Бекапи, чистка після зараження, SEO і швидкість сайту. Плагін безпеки, який робить усе, стає тим, що ламає все. Межу тримаю і кажу клієнтам, де брати решту.
Що зробив би інакше
Почав би з логів, а не з правил. Перша версія блокувала зайве, а логи були нечитабельними. Тиждень спостереження без блокувань зекономив би два релізи.
Коли власний плагін безпеки виправданий
Власний плагін безпеки виправданий, коли розрив структурний: запити, які треба відкидати до PHP, логи, які читаються о третій ночі, правила, що переживають оновлення. Для звичайного сайту підтримуваний плагін дешевший. Каталог плагінів WordPress - місце, з якого варто почати.
Ціна власного плагіна - не код, а підтримка: оновлення ядра, нові сигнатури ботів, сумісність із кешем і CDN. Якщо цього нема кому робити, за рік вийде діра з логотипом. Тому свій шар я пишу лише там, де готовий відповідати за нього сам. Решту закривають перевірені плагіни.
І документація: без неї підтримувати цей шар не буде кому.
Кожне правило доведеться комусь відлагоджувати о третій ночі.
Ще за темою: Найкращий плагін безпеки для WordPress: на що зважати і BotBlocker Security: WAF, що вмикається раніше за WordPress.