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

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

Крок 1: З’ясуйте, що насправді могла дати ця вразливість

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

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

Крок 2: Визначте період, коли ви були під загрозою

Цей період обмежують дві дати:

  1. Коли пролом відкрився на вашому сайті. Зазвичай це день, коли ви встановили уражену версію. Якщо ви його не знаєте, розумною заміною буде дата публікації CVE у бюлетені з вашого повідомлення (посилання є на кожній сторінці повідомлення): від моменту публікації про вразливість знали і зловмисники.
  2. Коли ви оновилися. День, коли ви його закрили.

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

Крок 3: Перевірте, хто має доступ до вашого сайту

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

  • Облікові записи адміністраторів. У WordPress: Users, потім фільтр за Administrator. У Joomla: Users, потім User Manager. Шукайте будь-який обліковий запис, якого ви не створювали. Застереження: деякі вразливості (наприклад, та, що стосується Simple Membership) дозволяють зловмиснику захопити наявний обліковий запис замість створення нового, тому сама лише ця перевірка нічого не доводить. Саме тому зміна облікових даних у кроці 4 має значення навіть тоді, коли список користувачів виглядає чистим.
  • Нещодавно додані плагіни, теми чи розширення, яких ви не встановлювали.
  • Заплановані завдання (у WordPress їх показує плагін WP Crontrol; багато бекдорів перевстановлюють себе із запланованого завдання).
  • Паролі застосунків (WordPress: Users, Profile, Application Passwords), тихий спосіб зберегти доступ через API після зміни пароля.

Крок 4: Змініть облікові дані

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

  • Паролі всіх облікових записів адміністраторів.
  • Секретні ключі і солі у wp-config.php (WordPress). Це завершує сеанси всіх користувачів, включно з будь-яким зловмисником, який має вкрадений сеанс; офіційний генератор видасть нові значення. У Joomla відповідником є значення $secret у configuration.php.
  • Ваші паролі до панелі керування хостингом і до FTP/SFTP, якщо ними з кимось поділилися або якщо вони давні.

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

Крок 5: Проскануйте і перевірте файли

  • Запустіть сканування на шкідливе програмне забезпечення від вашого хостинг-провайдера, якщо панель керування його пропонує (більшість спільних хостингів пропонують), або надійний безкоштовний сканер. Для WordPress безкоштовне сканування Wordfence порівнює ваші файли з офіційними копіями.
  • Перегляньте нещодавно змінені файли приблизно від початку періоду під загрозою і далі, особливо файли PHP у каталогах завантажень. Там PHP не має бути практично ніколи.
  • Якщо ваш хостинг зберігає журнали доступу, перегляньте цей період на предмет запитів до вразливого компонента з адрес, яких ви не впізнаєте. Відсутність слідів тут мало про що свідчить, оскільки журнали перезаписуються, але знахідка є вирішальною.

Якщо самоперевірка щось виявила

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

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

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

Якщо ви вже оновилися до того, як надійшов мій лист

Логіка та сама: повідомлення означає, що ваш сайт нещодавно повідомляв про уражену версію, тому період під загрозою існував, навіть якщо зараз він закритий. Кроки 2 до 4 все одно відповідають на питання, яке має значення.