Безпека адмінки OpenCart: захист панелі від зламу

Зламаний магазин рідко виглядає зламаним. Сайт працює, замовлення йдуть, менеджери нічого не помічають. А тим часом у таблиці oc_user сидить адміністратор, якого ніхто не створював, у папці image/catalog лежить файл cache.php, що ніякий не кеш, а веб-шел, і клієнтська база з телефонами й адресами вже пішла спамерам. Розкривається таке зазвичай випадково: клієнт поскаржився, що з головної його перекинуло на казино, або Google раптом позначив сайт як небезпечний.

Точок входу в цих історіях майже завжди дві. Перша — сама адмінка: не дірка в ядрі OpenCart і не хитрий SQL-injection, а банальний вхід через /admin з підібраним чи вкраденим паролем. Друга — модулі з піратських сайтів: у nulled-збірку платного розширення закладено бекдор, і власник власноруч заносить зловмисника в магазин разом з «безкоштовним» модулем, який шукав, щоб зекономити пару тисяч гривень. Найприкріше, що левова частка таких зламів закривається годиною роботи з конфігами та простою гігієною розширень. Нижче зібрано, що саме зробити, у порядку від обов'язкового до бажаного, з прикладами для OpenCart 2.x, 3.x і 4.x.

Чому боти знаходять вашу адмінку за хвилини

Відкрийте access.log будь-якого магазину, що прожив у мережі хоча б місяць. Там гарантовано будуть рядки такого вигляду:

185.220.101.34 - - [05/Jul/2026:03:12:44] "GET /admin/ HTTP/1.1" 200
185.220.101.34 - - [05/Jul/2026:03:12:45] "POST /admin/index.php?route=common/login HTTP/1.1" 200
185.220.101.34 - - [05/Jul/2026:03:12:47] "POST /admin/index.php?route=common/login HTTP/1.1" 200

Це не хакер, який обрав саме вас. Це бот, що обходить мільйони доменів за списком стандартних шляхів: /admin, /administrator, /wp-admin, /manager. Знайшов сторінку логіна OpenCart і почав перебирати пари логін-пароль зі злитих баз. Таких запитів на живому магазині буває хоч греблю гати, сотні за ніч, і жоден з них не потрапляє в поле зору власника, бо OpenCart ніде в адмінці невдалі спроби входу не показує.

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

Закрийте вхід на рівні сервера

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

Apache: .htaccess у папці адмінки

Якщо у вашого офісу чи дому статична IP-адреса, кладете в папку адмінки файл .htaccess:

# Apache 2.4
Require ip 91.218.100.15

Кілька адрес перелічуються через пробіл. Якщо IP динамічна, замість цього ставте базову автентифікацію: браузер питатиме окремий логін і пароль ще до того, як покаже форму OpenCart.

Спершу загляньте в панель хостингу, у більшості вона це вміє з коробки: у cPanel розділ називається Directory Privacy, у Plesk це Protected Directories. Обираєте папку адмінки, задаєте логін і пароль, і панель сама створює потрібні файли. Якщо такого розділу не знайшлося, напишіть у підтримку хостера: подібні речі налаштовують за одне звернення. Ручний варіант через .htaccess лишається для тих, у кого доступ до сервера повний:

AuthType Basic
AuthName "Restricted"
AuthUserFile /home/user/.htpasswd
Require valid-user

Файл .htpasswd генерується командою htpasswd -c /home/user/.htpasswd імʼя_користувача і має лежати за межами кореня сайту. Виходить двоє дверей із різними ключами: щоб дістатися до перебору пароля OpenCart, боту спершу треба зламати HTTP-автентифікацію, а такого масові сканери не роблять.

NGINX: тут є граблі, на які наступають майже всі

На NGINX файли .htaccess не працюють. Взагалі. Це класична помилка при переїзді з Apache: людина скопіювала магазин, .htaccess із заборонами переїхав разом з файлами, і власник спокійно живе з думкою, що адмінка закрита. А NGINX ці файли навіть не читає, і форма логіна відкрита всьому світу.

На NGINX обмеження прописуються в конфігурації віртуального хоста. І тут друга пастка, вже суто NGINX-ова:

# НЕПРАВИЛЬНО: захист не працює
location /k7-panel/ {
    allow 91.218.100.15;
    deny all;
}

Виглядає логічно, але запит до k7-panel/index.php цей блок не зловить: PHP-файли зазвичай обробляє окремий location ~ \.php$, а регулярні вирази в NGINX мають пріоритет над префіксними локаціями. Тобто статику в папці ви закрили, а сам вхід в адмінку — ні. Правильний варіант: окрема регулярка для PHP усередині панелі, розміщена в конфігу вище за загальну:

# ПРАВИЛЬНО: блок стоїть перед загальним location ~ \.php$
location ~ ^/k7-panel/.*\.php$ {
    allow 91.218.100.15;
    deny all;

    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.1-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Після зміни конфігурації обов'язково nginx -t і перезавантаження. І не полінуйтеся перевірити результат з телефона через мобільний інтернет: якщо з чужої IP-адреси відкривається 403, все зроблено правильно. На віртуальному хостингу прямого доступу до конфігів NGINX зазвичай нема, тоді це питання до підтримки хостера: нормальна підтримка додасть такий блок за одне звернення.

Користувачі та права: не всі під одним логіном

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

OpenCart має повноцінну систему груп користувачів: System → Users → User Groups в англомовному інтерфейсі. Для кожної групи галочками задається доступ на перегляд і на зміну по кожному контролеру окремо. Менеджеру, який обробляє замовлення, досить прав на sale/order, customer/customer і суміжні розділи.

Права на marketplace/installer,system/users йому ні до чого: саме через встановлення розширень і бекапи зловмисник із вкраденим менеджерським паролем перетворюється на господаря магазину.

Окремий пункт — логін першого адміністратора. Ім'я admin бот підставляє першим, тому обліковий запис із таким логіном віддає половину пари логін-пароль безкоштовно. Створіть нового адміністратора з нестандартним ім'ям, зайдіть під ним і видаліть стандартного.

І раз уже відкрили список користувачів, придивіться до нього уважно. Обліковий запис, якого ви не створювали, означає що магазин уже зламано. Такі записи, до речі, найчастіше з'являються після встановлення nulled-модулів: у зламаному платному розширенні докинути в інсталятор кілька рядків, що створюють прихованого адміністратора або пишуть веб-шел у файлову структуру, — справа на п'ять хвилин для того, хто цей nulled збирав. Тож кожне розширення з «безкоштовного» джерела перетворюється на лотерею, де призовий фонд ваш магазин. Перевірити модуль на предмет піратського походження можна на warez.rip.

Перебір пароля: чому штатного захисту нема

Тут OpenCart є за що покритикувати. Для покупців захист від перебору існує: параметр Max Login Attempts у налаштуваннях магазину (вкладка Option), після перевищення обліковий запис блокується на годину, спроби пишуться в таблицю oc_customer_login. А от форма входу в адмінку в 2.x і 3.x не має жодного обмеження спроб. Жодного. Бот може довбати route=common/login тисячами запитів, і OpenCart слухняно перевірятиме кожен пароль, нічого ніде не блокуючи й не логуючи.

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

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

Двофакторної автентифікації в стандартному OpenCart теж нема, в жодній версії, включно з 4.x. На маркетплейсі є розширення, що додають TOTP-коди через Google Authenticator і аналоги; якщо в адмінку ходить більше двох людей, таке розширення відпрацьовує свою ціну сповна. Тільки беріть його з офіційного маркетплейсу, з огляду на попередній розділ.

Токен сесії та HTTPS

Погляньте на адресний рядок відкритої адмінки OpenCart 3.x:

https://example.com/k7-panel/index.php?route=common/dashboard&user_token=f3a91c...

Оцей user_token — перепустка вашої сесії. У 2.x він називався просто token, суть та сама: хто має посилання з живим токеном, той працює в адмінці від вашого імені без жодного пароля. Тому повне посилання зі сторінки адмінки не можна кидати в чати, тикети підтримки чи скриншоти без замальовування. Токен помирає разом із сесією, але сесія живе годинами, і цього досить. З тієї ж опери звичка не виходити з адмінки на чужих чи спільних комп'ютерах: кнопка Logout існує не для краси, вона вбиває сесію разом з токеном одразу, а не колись потім.

З цієї ж причини адмінка має працювати тільки по HTTPS. Якщо в HTTP_SERVER і HTTPS_SERVER конфігурації адмінки досі прописано http://, токен і пароль літають мережею відкритим текстом, і в кав'ярняному Wi-Fi їх збере хто завгодно. Сертифікат Let's Encrypt безкоштовний і ставиться з панелі будь-якого притомного хостингу, тож виправдань тут нема: обидві константи в config.php адмінки мають починатися з https://.

Файли, права доступу і те, що лежить у корені

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

Права на конфіги. Після завершення налаштування магазину обидва конфігураційні файли, кореневий config.php і config.php адмінки, переводьте в режим тільки для читання:

chmod 444 config.php
chmod 444 k7-panel/config.php

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

Папка storage. OpenCart 3.x після встановлення сам показує в адмінці попередження про те, що каталог storageтреба винести за межі кореня сайту, і кнопку Move, яка робить перенесення автоматично. Натисніть її, це найкоротший шлях. Сенс у тому, що в storage лежать логи, кеш і сесії, і тримати їх у зоні, доступній по HTTP, нема чого. На Apache каталог system прикритий власним .htaccess, але ви вже знаєте з розділу про NGINX, чого вартий цей захист після переїзду на інший веб-сервер. Якщо кнопка з якихось причин недоступна, перенесення робиться руками: перемістити папку рівнем вище кореня і виправити DIR_STORAGE в обох конфігах.

Папка install. Її видаляють одразу після встановлення магазину. OpenCart про це нагадує, але на живих сайтах вона трапляється досі, а це готовий інструмент для перевстановлення магазину чужими руками.

Бекапи в корені. Окрема болячка, яку видно в логах сканерів: запити до /backup.sql, /dump.sql, /1.sql. Боти цілеспрямовано шукають дампи, забуті в корені після переносу чи ручного бекапа. А в дампі OpenCart вся таблиця oc_user з хешами паролів адміністраторів і вся клієнтська база. Файли бекапів мають жити за межами кореня сайту, крапка. Якщо дамп треба тимчасово покласти в корінь для переносу, він видаляється в ту ж годину, а не «потім якось».

Старі версії: дірка, яку не залатати конфігом

Усе перелічене вище має сенс, тільки якщо сам движок і розширення не діряві. Магазин на OpenCart 2.0 з PHP 5.6, який «працює і не чіпайте», лишається бомбою з годинниковим механізмом незалежно від того, як хитро схована адмінка. Уразливості старих версій давно розібрані по кісточках у публічних звітах, і сканери перевіряють їх автоматично, разом із версією движка, яку OpenCart охоче видає в заголовках і структурі відповідей.

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

І про PHP. Гілки, що вийшли з підтримки, не отримують виправлень безпеки, тож тримати магазин на PHP 7.4 у 2026 році означає свідомо ризикувати. OpenCart 3.0.3.x нормально працює на PHP 8.0–8.1, для старіших збірок перехід може вимагати правок у сторонніх модулях, але це разова робота, а не постійна загроза.

Як зрозуміти, що вас уже зламали

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

Список адміністраторів у базі, без посередництва адмінки (зламана панель може ховати чужі записи):

SELECT user_id, username, email, status, date_added FROM oc_user;

Все, що ви не створювали, — привід для повного розслідування, а не просто видалення рядка.

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

PHP-файли там, де їх бути не може. У каталозі зображень виконуваних файлів нема за визначенням, тому перевірка тривіальна:

find image/ -name "*.php"

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

find . -name "*.php" -mtime -7

І останнє: system/storage/logs/error.log. Різкий сплеск помилок виду «undefined function» чи «failed to open stream» із незнайомими шляхами часто означає, що чужий скрипт намагається запуститися і йому щось заважає. Лог, який ніхто не читає, не попередить ні про що.

Чек-лист безпеки адмінки

1. Закрити вхід на рівні сервера: IP-обмеження або HTTP-автентифікація. На NGINX переконатися, що правило ловить саме PHP-запити.
2. Видалити обліковий запис із логіном admin, створивши заміну з нестандартним ім'ям.
3. Роздати менеджерам окремі облікові записи з мінімальними правами через User Groups.
4. Поставити паролі з менеджера паролів; за потреби додати 2FA-розширення з офіційного маркетплейсу.
5. Перевести адмінку на HTTPS в обох константах конфігурації; не передавати посилання з user_token.
6. chmod 444 на обидва config.php; папки 755, файли 644, ніяких 777.
7. Перенести storage за межі кореня кнопкою Move; видалити папку install і бекапи з кореня.
8. Не ставити nulled-модулі; сумнівні перевіряти на warez.rip.
9. Видалити невикористовувані розширення повністю, не лише вимкнути; тримати актуальну гілку PHP.