Admin sadaļu norobežošana ar IP, VPN vai papildu aizsardzību

Īsi sakot: Admin sadaļu visefektīvāk aizsargājat, atverot to tikai zināmiem tīkliem: ar IP atļaušanu tīmekļa serverī, ar VPN ar fiksētu izejas adresi vai ar otru, priekšā ieslēgtu pieteikšanos. Svarīgs ir pilns visu administrēšanas adrešu saraksts, pareiza starpnieku serveru un CDN apstrāde un tests no ārpuses. Norobežošana papildina divu faktoru pieteikšanos un atjauninājumus, bet tos neaizstāj.

Kāpēc aizmugure vispār ir atvērta?

Daudzos uzņēmumos administratori pagājušajā nedēļā ir atjauninājuši PHP un pārstartējuši darbprocesus. Kas pēc tam apskata piekļuves žurnālus, bieži redz ko citu: CMS pieteikšanās lapa, datubāzes rīks un hostinga panelis tiek atvērti visu diennakti no visas pasaules. Vajadzīgi tie tomēr ir tikai nedaudziem cilvēkiem savā komandā.

Katra no šīm adresēm ir uzbrukuma virsma. Pieteikšanās veidlapas tiek pārmeklētas ar paroļu minēšanu, administrēšanas rīkos ir savas ievainojamības, un spraudņi aizmugurei bieži ir sliktāk pārbaudīti nekā CMS kodols. Ja svešinieki šīm sadaļām vispār netiek klāt, daudzi uzbrukumi izplēn, vēl neesot sākušies.

Godīgi vērtējot: pret pašu PHP2Shell tas palīdz maz. Ievainojamības atrodas interpretatorā, un saskaņā ar php.net tās var izraisīt bez pieteikšanās caur publiskām PHP lapām. Aizmugures norobežošana ir pastāvīga nostiprināšana, nevis ārkārtas ielāps.

Admin sadaļas aizsardzība ar IP, VPN vai otro pieteikšanos

Nav vienas pareizas metodes. Izšķiroši ir tas, kā strādā jūsu komanda un kur darbojas vietne.

Praksē labi darbojas kombinācija: atļauja tikai VPN vai uzņēmuma tīklam, papildus otra pieteikšanās kā rezerves līmenis. Īstā pieteikšanās CMS paliek ar divu faktoru metodi, kā aprakstīts ceļvedī Divu faktoru pieteikšanās administratora piekļuvēm.

Kuras adreses vispār pieder aizmugurei?

Biežākais vājums nav tehnika, bet nepilns saraksts. Tāpēc rīkojieties šādā secībā:

1. Apkopot CMS vai veikala pieteikšanās lapas, ieskaitot alternatīvas pieteikšanās adreses, ko izveido spraudņi.
2. Meklēt administrēšanas rīkus: datubāzu saskarnes, failu pārvaldniekus, instalēšanas skriptus, statusa un monitoringa lapas.
3. Iekļaut hostinga un servera paneļus, kas bieži darbojas uz savām portām.
4. Pārbaudīt testa un staging instances, kas bieži izmanto tos pašus piekļuves datus kā produkcijas vietne.
5. Nodalīt saskarnes: daži aizmugures ceļi tiek izsaukti arī no publiskās priekšpuses, piemēram, Ajax pieprasījumiem. Tos nedrīkst akli bloķēt, citādi sabojāsies veidlapas vai iepirkumu groziņi.

Piektais punkts ir iemesls, kāpēc norobežošana vienmēr jātestē. Piemēram, WordPress gadījumā fails admin mapē tiek izmantots arī publiskām funkcijām.

Konfigurācija: IP atļaušana plus otra pieteikšanās

Ar Nginx abus nosacījumus var apvienot. Ar satisfy all pieprasījumam jānāk no atļauta tīkla un papildus jāiztur otrā pieteikšanās. Ceļš, adreses un PHP nodošana ir vietturi:

location ^~ /backend/ {
    satisfy all;

    allow 192.0.2.0/24;      # uzņēmuma tīkls (vietturis)
    allow 198.51.100.10;     # VPN izeja (vietturis)
    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;
    }
}

Ieliktā PHP location ir svarīga: ar ^~ citi .php noteikumi vairs netiek izvērtēti. Ar Apache to pašu sasniedzat ar bloku, kurā jāizpildās abiem nosacījumiem:

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

Paroļu failam jāatrodas ārpus tīmekļa saknes. Otrā pieteikšanās pārsūta piekļuves datus ar katru pieprasījumu, tāpēc lietojiet to tikai pa HTTPS.

Kļūdas: CDN, starpniekserveris, IPv6 un mājas birojs

Ja jūsu vietne atrodas aiz CDN, piemēram, Cloudflare, vai slodzes balansētāja, tīmekļa serveris sākotnēji redz tikai tā adreses. IP atļauja tad vai nu visus nobloķētu, vai visus laistu cauri. Tīmekļa serverim īstā adrese jāpārņem no galvenes: ar Nginx izmantojot set_real_ip_from un real_ip_header, ar Apache mod_remoteip.

Tur ir spēkā: galveni pieņemt tikai no savām starpniekservera adresēm. Citādi katrs apmeklētājs var uzdoties par jebkuru izcelsmi. Tikpat svarīgi, lai origin serveris nebūtu tieši sasniedzams, jo citādi starpniekserveri kopā ar tā noteikumiem var apiet. Norādes ir rakstā Ugunsmūris tīmekļa serverim.

Divus citus punktus bieži nepamana. Ja serveris ir sasniedzams ar IPv6, ierakstu vajag arī jūsu tīkla IPv6 adresēm, citādi administratori ar IPv6 uzdursies bloķēšanai. Un privātie interneta pieslēgumi regulāri maina adresi. Mājas biroja darbam un ārējiem pakalpojumu sniedzējiem VPN tāpēc parasti ir stabilāks risinājums.

Kā pārbaudīt, vai norobežošana darbojas

Noteikums, kas nav pārbaudīts, neskaitās ieviests. Pārbaudiet no pieslēguma ārpus uzņēmuma tīkla, piemēram, ar mobilo tīklu:

# Sagaidāms: 403 (bloķēts) vai 401 (pieprasīta otrā pieteikšanās)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Pārbaudīt arī PHP failus tieši, ne tikai direktoriju
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php

Pēc tam tos pašus izsaukumus no uzņēmuma tīkla vai VPN: tur lapai jābūt pieejamai. Pēc tam pārbaudiet publisko priekšpusi, tas ir, veidlapas, meklēšanu un iepirkumu grozu. Nākamo dienu žurnālos piekļuvēm admin adresēm gandrīz tikai jāparādās ar statusu 401 vai 403.

Ja sadaļa līdz šim bijusi atvērta, vērts pārskatīt esošos kontus. Kā atrast nepazīstamus administratorus, apraksta Svešu admin kontu atrašana CMS un serverī. Papildus palēnina aizsardzība pret masveida minēšanu, skatiet Admin pieteikšanās aizsardzība pret Brute Force.

Kā PHP SOS palīdz konkrēti?

• Mēs apkopojam visas jūsu vietņu, paneļu un rīku administrēšanas adreses un nodalām tās no publiski vajadzīgajiem ceļiem.
• Mēs kopā ar jums izvēlamies piemēroto metodi atkarībā no komandas lieluma, mājas biroja un hostinga.
• Mēs ieviešam noteikumus tīmekļa serverī, ņemam vērā CDN, starpniekserveri un IPv6 un pie tam paturam atvērtu atkāpšanās ceļu.
• Mēs testējam no ārpuses un no iekšpuses un nododam īsu dokumentāciju ar atļautajiem tīkliem.

Admin sadaļu norobežošana ir daļa no mūsu PHP tīmekļa serveru nostiprināšanas.

Biežāk uzdotie jautājumi

Avoti

• OWASP Cheat Sheet Series
• Nginx dokumentācija
• Apache HTTP Server: dokumentācija