Izolarea zonelor de administrare prin IP, VPN sau protecție suplimentară

Pe scurt: Cel mai eficient protejați zona de administrare dacă o deschideți doar pentru rețele cunoscute: prin lista de IP-uri permise în serverul web, printr-un VPN cu adresă de ieșire fixă sau cu o a doua autentificare, prealabilă. Contează o listă completă a tuturor adreselor de administrare, tratarea corectă a proxy-urilor și a CDN-urilor și un test din exterior. Izolarea completează autentificarea în doi factori și actualizările, nu le înlocuiește.

De ce este backend-ul deschis, de fapt?

În multe companii, administratorii au actualizat PHP săptămâna trecută și au repornit worker-ii. Cine se uită după aceea în jurnalele de acces constată adesea altceva: pagina de autentificare a CMS-ului, instrumentul pentru baza de date și panoul de hosting sunt apelate non-stop din toată lumea. Ele sunt necesare însă doar unui număr mic de oameni din propria echipă.

Fiecare dintre aceste adrese este suprafață de atac. Formularele de autentificare sunt încercate la nesfârșit, instrumentele de administrare conțin propriile vulnerabilități, iar pluginurile pentru backend sunt adesea mai puțin bine verificate decât nucleul unui CMS. Dacă necunoscuții nu pot ajunge deloc în aceste zone, multe atacuri se pierd în gol încă înainte de a începe.

Încadrat onest: împotriva PHP2Shell în sine, aceasta ajută puțin. Vulnerabilitățile se află în interpretor și, potrivit php.net, pot fi declanșate fără autentificare prin pagini PHP publice. Izolarea backend-ului este o întărire permanentă, nu un patch de urgență.

Protejarea zonei de administrare prin IP, VPN sau a doua autentificare

Nu există o singură metodă corectă. Hotărâtor este cum lucrează echipa dumneavoastră și unde rulează site-ul.

În practică se dovedește bună o combinație: permisiune doar pentru VPN sau pentru rețeaua firmei, plus o a doua autentificare ca nivel de rezervă. Autentificarea propriu-zisă din CMS rămâne cu procedeu în doi factori, așa cum este descris în ghidul Autentificarea în doi factori pentru accesul de administrare.

Ce adrese aparțin, de fapt, backend-ului?

Cea mai frecventă slăbiciune nu este tehnica, ci o listă incompletă. Procedați de aceea în această ordine:

1. Inventariați paginile de autentificare ale CMS-ului sau magazinului, inclusiv adresele alternative de login create de pluginuri.
2. Căutați instrumentele de administrare: interfețe de bază de date, manageri de fișiere, scripturi de instalare, pagini de stare și de monitorizare.
3. Includeți panourile de hosting și de server, care rulează adesea pe porturi proprii.
4. Verificați instanțele de test și de staging, care folosesc deseori aceleași date de acces ca site-ul live.
5. Delimitați interfețele: Unele căi de backend sunt apelate și de frontend-ul public, de exemplu pentru cereri Ajax. Nu aveți voie să le blocați orbește, altfel formularele sau coșurile de cumpărături se strică.

Punctul cinci este motivul pentru care o izolare trebuie testată întotdeauna. La WordPress, de exemplu, un fișier din directorul de administrare este folosit și pentru funcții publice.

Configurare: lista de IP-uri permise plus a doua autentificare

În Nginx se pot combina ambele condiții. Cu satisfy all, o cerere trebuie să provină dintr-o rețea permisă și să treacă în plus de a doua autentificare. Calea, adresele și transmiterea către PHP sunt substituenți:

location ^~ /backend/ {
    satisfy all;

    allow 192.0.2.0/24;      # Rețeaua firmei (substituent)
    allow 198.51.100.10;     # Ieșire VPN (substituent)
    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;
    }
}

Location-ul PHP imbricat este important: prin ^~, alte reguli pentru .php nu mai sunt evaluate. În Apache obțineți același lucru cu un bloc în care trebuie îndeplinite ambele condiții:

<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>

Fișierul de parole aparține în afara webroot-ului. A doua autentificare transmite datele de acces la fiecare cerere, de aceea folosiți-o doar prin HTTPS.

Capcanele: CDN, proxy, IPv6 și home office

Dacă site-ul dumneavoastră se află în spatele unui CDN precum Cloudflare sau al unui load balancer, serverul web vede la început doar adresele acestuia. O listă de IP-uri permise ar bloca atunci fie pe toți, fie ar lăsa să treacă pe toți. Serverul web trebuie să preia adresa reală dintr-un antet, în Nginx cu set_real_ip_from și real_ip_header, în Apache cu mod_remoteip.

Se aplică următoarea regulă: acceptați antetul doar de la adresele proxy-urilor proprii. Altfel, orice vizitator poate simula o origine oarecare. La fel de important este ca serverul de origine să nu fie accesibil direct, deoarece altfel proxy-ul cu tot cu regulile lui poate fi ocolit. Indicații în acest sens găsiți la Firewall pentru serverul web.

Alte două puncte sunt adesea trecute cu vederea. Dacă serverul este accesibil prin IPv6, și adresele IPv6 ale rețelei dumneavoastră au nevoie de o intrare, altfel administratorii cu IPv6 se lovesc de blocare. Iar conexiunile private la internet își schimbă regulat adresa. Pentru home office și furnizori externi, un VPN este de aceea, de regulă, soluția mai stabilă.

Cum verificați dacă izolarea funcționează

O regulă netestată nu este considerată implementată. Verificați de la o conexiune din afara rețelei firmei, de exemplu prin rețeaua mobilă:

# Așteptat: 403 (blocat) sau 401 (se cere o a doua autentificare)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Verificați direct și fișierele PHP, nu doar directorul
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php

Apoi aceleași apeluri din rețeaua firmei sau din VPN: acolo pagina trebuie să fie accesibilă. Controlați după aceea frontend-ul public, adică formularele, căutarea și coșul de cumpărături. În jurnalele din zilele următoare, accesările către adresele de administrare ar trebui să apară aproape numai cu statusul 401 sau 403.

Dacă zona a fost până acum deschisă, merită să aruncați o privire asupra conturilor existente. Cum găsiți administratorii necunoscuți descrie Găsirea conturilor de administrator străine în CMS și server. Complementar, o protecție împotriva încercărilor în masă frânează atacurile, vedeți Protejarea autentificărilor de administrare împotriva atacurilor brute force.

Cum ajută PHP SOS concret?

• Inventariem toate adresele de administrare ale site-urilor, panourilor și instrumentelor dumneavoastră și le separăm de căile necesare public.
• Alegem împreună cu dumneavoastră procedeul potrivit, în funcție de mărimea echipei, home office și hosting.
• Implementăm regulile în serverul web, ținem cont de CDN, proxy și IPv6 și păstrăm în același timp o cale de întoarcere.
• Testăm din exterior și din interior și predăm o scurtă documentație cu rețelele permise.

Izolarea zonelor de administrare face parte din întărirea serverului pentru servere web PHP oferită de noi.

Întrebări frecvente

Surse

• OWASP Cheat Sheet Series
• Documentația Nginx
• Apache HTTP Server: documentație