Як обмежити доступ до wp-admin за IP або через VPN

Що саме дає обмеження доступу

Коли правило налаштоване на рівні Apache або Nginx, сторонній запит відхиляється ще до запуску WordPress, PHP і плагінів. Користувач отримує відповідь 403 Forbidden, а WordPress не витрачає ресурси на обробку запиту.

Зазвичай обмежують два маршрути: /wp-admin/ і /wp-login.php. Перший веде до адміністративної частини, а другий обробляє вхід. Саме обмеження URL не замінює двофакторну автентифікацію, сильні паролі та своєчасні оновлення, але створює додатковий мережевий бар’єр.

Для сайтів з Elementor важливо врахувати пов’язані запити. Редактор може використовувати admin-ajax.php, REST API та інші ресурси. Якщо бездумно заблокувати весь /wp-admin/ без винятків, редактор або окремі функції сайту можуть перестати працювати.

• Зменшується кількість автоматичних спроб входу до WordPress.
• Адмін-панель стає недоступною з невідомих мереж.
• Запити відхиляються раніше, ніж їх обробить PHP або WordPress.
• Правило можна поєднати з VPN, двофакторною автентифікацією та контролем сесій.

Коли обрати IP-allowlist, а коли VPN

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

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

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

VPN має бути саме приватним, контрольованим рішенням із персональними обліковими записами. Публічні VPN-сервіси не є заміною власному каналу доступу: їхні адреси можуть бути спільними, змінюватися або блокуватися.

• Фіксований офісний IP: використовуйте allowlist.
• Змінні мережі та мобільні адміністратори: використовуйте приватний VPN.
• Кілька співробітників: краще виділити окрему VPN-підмережу, ніж постійно редагувати список адрес.
• Публічний сайт і адмінка можуть працювати через різні мережеві правила.

Підготовка перед блокуванням

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

З’ясуйте свою фактичну публічну IPv4-адресу та перевірте, чи використовується IPv6. Якщо провайдер або VPN видає IPv6, а в правилі дозволена лише IPv4, доступ може працювати нестабільно або блокуватися неочікувано.

Також потрібно визначити, чи є перед сервером CDN, reverse proxy або балансувальник. У такій схемі веб-сервер може бачити IP проксі, а не реального відвідувача. Неправильно налаштований заголовок реальної IP-адреси може або заблокувати всіх, або звести обмеження нанівець.

• Зробіть резервну копію конфігурації веб-сервера.
• Перевірте доступ із дозволеної мережі та наявність аварійного способу входу.
• Визначте IPv4- і IPv6-адреси офісу або VPN.
• З’ясуйте, чи проходить трафік через Cloudflare, CDN, проксі або балансувальник.
• Переконайтеся, що правило застосовується саме до потрібного віртуального хоста та домену.

Приклад обмеження в Apache

У сучасному Apache 2.4 доступ за IP зазвичай задають директивою Require ip. Конкретне місце залежить від конфігурації сервера: це може бути VirtualHost, каталог WordPress або окремий файл правил. Зміни потрібно вносити лише там, де хостинг дозволяє конфігурацію Apache.

Для wp-admin можна дозволити одну адресу або підмережу. Окремо можна захистити wp-login.php. Перед перезавантаженням сервера перевірте синтаксис конфігурації доступною для вашого середовища командою перевірки.

• Не вказуйте адресу внутрішньої мережі на кшталт 192.168.1.10, якщо сервер бачить ваш публічний IP.
• Якщо використовується IPv6, додайте потрібну IPv6-адресу або підмережу окремим правилом.
• Не копіюйте синтаксис Apache у конфігурацію Nginx: це різні сервери.

<Directory "/var/www/example.com/public/wp-admin">
    Require ip 203.0.113.25
    Require ip 2001:db8:1234::/64
</Directory>

<Location "/wp-login.php">
    Require ip 203.0.113.25
    Require ip 2001:db8:1234::/64
</Location>

Що врахувати для .htaccess

На shared hosting доступ до конфігурації VirtualHost часто відсутній, але можуть бути дозволені правила в .htaccess. У такому разі можливості залежать від директив AllowOverride. Якщо хостинг не дозволяє Require або не дає змінювати правила доступу, не вставляйте конфігурацію навмання: зверніться до підтримки або використайте налаштування серверної панелі.

Після зміни перевірте не лише сторінку входу, а й сам /wp-admin/. Увійдіть із дозволеної адреси, відкрийте редактор Elementor і протестуйте збереження сторінки.

Приклад обмеження в Nginx

У Nginx доступ за IP задають директивами allow і deny. Їх можна розмістити в потрібному server або location-блоці. Порядок має значення: спочатку вказують дозволені адреси, а потім заборону для всіх інших.

Для wp-admin часто захищають окремий location, а для wp-login.php додають точкове правило. Конкретна конфігурація може відрізнятися залежно від шаблону хостингу, PHP-FPM і наявності проксі.

• Після редагування перевірте конфігурацію Nginx до перезавантаження.
• Дозволяйте адресу VPN-сервера або VPN-підмережу, а не локальну адресу пристрою.
• Не блокуйте весь сайт директивою deny all, якщо мета — захистити лише адмінські маршрути.

location ^~ /wp-admin/ {
    allow 203.0.113.25;
    allow 2001:db8:1234::/64;
    deny all;
}

location = /wp-login.php {
    allow 203.0.113.25;
    allow 2001:db8:1234::/64;
    deny all;
}

Проксі, CDN і реальна IP-адреса

Якщо домен працює через reverse proxy або CDN, веб-сервер може отримувати всі запити з однієї адреси проксі. Тоді просте правило allow за IP або дозволить усім користувачам проксі доступ до адмінки, або заблокує всіх адміністраторів.

Для коректної роботи потрібно налаштувати довірені проксі та механізм визначення реальної IP-адреси на рівні веб-сервера. Не можна без перевірки довіряти будь-якому заголовку X-Forwarded-For або подібному: клієнт може підробити його, якщо проксі не перезаписує значення.

Після налаштування перевірте access log. У ньому має відображатися очікувана адреса адміністратора, а не лише IP CDN. Якщо є сумніви, попросіть системного адміністратора або хостинг перевірити ланцюжок проксі.

• Визначте список довірених проксі.
• Налаштуйте real IP лише для цих проксі.
• Перевірте журнали доступу з дозволеної та забороненої мережі.
• Не вважайте наявність заголовка X-Forwarded-For доказом його достовірності.

Перевірка після впровадження та типові помилки

Тестуйте правило з двох різних мереж: із дозволеної та забороненої. У дозволеній мережі мають відкриватися wp-login.php, wp-admin і потрібні функції WordPress. У забороненій — повертатися 403 Forbidden. Перевірте також мобільний інтернет, IPv6 і підключення через VPN.

Для Elementor окремо протестуйте завантаження редактора, збереження змін, медіафайли та перегляд сторінки. Якщо редактор перестав працювати, не відкривайте без обмежень увесь wp-admin. Спочатку проаналізуйте журнали й визначте, який саме запит блокується.

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

• Заблокували себе через зміну IP або підключення до іншої Wi-Fi-мережі.
• Додали лише IPv4, хоча адміністратор підключається через IPv6.
• Застосували правило до всього сайту замість wp-admin і wp-login.php.
• Заблокували необхідні запити Elementor або admin-ajax.php.
• Налаштували allowlist для IP проксі, не налаштувавши визначення реальної адреси.
• Поклалися лише на зміну URL входу: прихований URL не є контролем доступу.

Додатковий захист адмін-панелі

Обмеження за IP або VPN не скасовує базові заходи безпеки. Облікові записи адміністраторів мають використовувати унікальні складні паролі та двофакторну автентифікацію. Не залишайте спільний обліковий запис для всієї команди: персональні акаунти спрощують аудит і блокування доступу співробітника, який більше не працює із сайтом.

Регулярно оновлюйте WordPress, тему, Elementor, розширення та серверне програмне забезпечення. Видаляйте невикористовувані плагіни, обмежуйте кількість адміністраторів і контролюйте журнали входу.

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

• Двофакторна автентифікація для всіх адміністраторів.
• Унікальні облікові записи замість спільного логіна.
• Регулярні резервні копії та перевірка відновлення.
• Оновлення WordPress, Elementor, плагінів і серверних компонентів.
• Моніторинг невдалих входів і змін конфігурації.