Скриване на админ частта чрез IP, VPN или допълнителна защита

Накратко: Най-ефективно защитавате админ частта, като я отворите само за известни мрежи: чрез IP филтър в уеб сървъра, чрез VPN с фиксиран изходящ адрес или чрез втори, предварителен вход. Важни са пълен списък на всички адреси за администриране, правилното третиране на прокси и CDN и тест отвън. Скриването допълва двуфакторното удостоверяване и актуализациите, но не ги замества.

Защо изобщо е отворена административната част?

В много фирми през изминалата седмица администраторите са актуализирали PHP и са рестартирали работните процеси (worker). Който след това погледне журналите за достъп, често установява нещо друго: страницата за вход на CMS, инструментът за базата данни и хостинг панелът се извикват денонощно от цял свят. А са нужни само на шепа хора от собствения екип.

Всеки от тези адреси е повърхност за атака. Формулярите за вход се изпробват, инструментите за администриране съдържат собствени уязвимости, а добавките за административната част често са проверени по-слабо от ядрото на CMS. Когато външни лица изобщо не могат да стигнат до тези зони, много атаки пропадат още преди да започнат.

Честна оценка: срещу самия PHP2Shell това помага малко. Уязвимостите са в интерпретатора и според php.net могат да бъдат задействани без вход в системата чрез публични PHP страници. Скриването на административната част е постоянно заздравяване, а не спешен пач.

Защита на админ частта чрез IP, VPN или втори вход

Няма един-единствен правилен метод. Решаващо е как работи екипът Ви и къде работи уебсайтът.

На практика се доказва комбинацията: разрешаване само за VPN или фирмената мрежа, плюс втори вход като резервно ниво. Същинският вход в CMS остава с двуфакторно удостоверяване, както е описано в наръчника Двуфакторно удостоверяване за достъпа на администраторите.

Кои адреси всъщност принадлежат към административната част?

Най-честата слабост не е технологията, а непълният списък. Затова действайте в този ред:

1. Отчетете страниците за вход на CMS или магазина, включително алтернативните адреси за вход, които създават добавките.
2. Потърсете инструменти за администриране: интерфейси за бази данни, файлови мениджъри, инсталационни скриптове, страници за състояние и мониторинг.
3. Включете хостинг и сървърните панели, които често работят на собствени портове.
4. Проверете тестовите и staging инстанциите, които често ползват същите данни за достъп като живия сайт.
5. Разграничете интерфейсите: някои пътища на административната част се извикват и от публичния фронтенд, например за Ajax заявки. Тях не бива да блокирате на сляпо, иначе формулярите или количките за пазаруване ще спрат да работят.

Точка пет е причината скриването винаги да се тества. При WordPress например файл в админ папката се използва и за публични функции.

Конфигурация: IP филтър плюс втори вход

При Nginx двете условия могат да се комбинират. С satisfy all заявката трябва да идва от разрешена мрежа и освен това да премине втория вход. Пътят, адресите и предаването към PHP са примерни стойности:

location ^~ /backend/ {
    satisfy all;

    allow 192.0.2.0/24;      # фирмена мрежа (примерна стойност)
    allow 198.51.100.10;     # изход на VPN (примерна стойност)
    deny  all;

    auth_basic           "Interner Bereich";
    auth_basic_user_file /etc/nginx/htpasswd-backend;

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }
}

Вложената PHP location е важна: заради ^~ другите правила за .php вече не се оценяват. При Apache постигате същото с блок, в който трябва да са изпълнени и двете условия:

<Location "/backend">
    AuthType Basic
    AuthName "Interner Bereich"
    AuthUserFile /etc/apache2/htpasswd-backend
    <RequireAll>
        Require ip 192.0.2.0/24 198.51.100.10
        Require valid-user
    </RequireAll>
</Location>

Файлът с паролите принадлежи извън уеб корена (webroot). Вторият вход предава данните за достъп при всяка заявка, затова го използвайте само през HTTPS.

Клопките: CDN, прокси, IPv6 и работа от вкъщи

Ако уебсайтът Ви е зад CDN като Cloudflare или зад балансьор на натоварването, уеб сървърът вижда първоначално само неговите адреси. IP филтърът би блокирал или всички, или никого. Уеб сървърът трябва да вземе истинския адрес от заглавна част: при Nginx с set_real_ip_from и real_ip_header, при Apache с mod_remoteip.

Важи следното: приемайте заглавната част само от адресите на собствените си прокси. Иначе всеки посетител може да симулира произволен произход. Също толкова важно е първоизточникът да не е достъпен директно, защото иначе проксито заедно с правилата му може да бъде заобиколено. Насоки има в Защитна стена за уеб сървъри.

Още две точки често се пропускат. Ако сървърът е достъпен по IPv6, и IPv6 адресите на Вашата мрежа се нуждаят от запис, иначе администраторите с IPv6 ще попаднат пред блокировка. А частните интернет връзки сменят адреса си редовно. За работа от вкъщи и външни доставчици VPN затова обикновено е по-стабилното решение.

Как да проверите дали скриването действа

Правило, което не е тествано, не се счита за въведено. Проверявайте от връзка извън фирмената мрежа, например през мобилната мрежа:

# Очаквано: 403 (блокирано) или 401 (изискан втори вход)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Проверете и директно PHP файловете, не само директорията
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php

След това същите извиквания от фирмената мрежа или от VPN: там страницата трябва да е достъпна. После проверете публичния фронтенд, тоест формулярите, търсенето и количката. В журналите на следващите дни достъпите до адресите на администрацията трябва да се появяват почти само със статус 401 или 403.

Ако зоната досега е била отворена, си струва да погледнете съществуващите акаунти. Как да откриете непознати администратори, описва Откриване на чужди админ акаунти в CMS и на сървъра. Допълнително защитата срещу масово подбиране на пароли забавя атаките, вижте Защита на админ входовете срещу Brute Force.

Как помага PHP SOS конкретно?

• Отчитаме всички адреси за администриране на Вашите уебсайтове, панели и инструменти и ги отделяме от пътищата, които са нужни публично.
• Избираме заедно с Вас подходящия метод в зависимост от размера на екипа, работата от вкъщи и хостинга.
• Въвеждаме правилата в уеб сървъра, отчитаме CDN, прокси и IPv6 и оставяме отворен път за връщане.
• Тестваме отвън и отвътре и предаваме кратка документация с разрешените мрежи.

Скриването на админ частите е част от нашето заздравяване на сървъри за PHP уеб сървъри.

Често задавани въпроси

Източници

• OWASP Cheat Sheet Series
• Документация на Nginx
• Apache HTTP Server: документация