Varnost Strukture Mape WordPress: Onemogočanje Dostopa do Mape "wp-includes"

Varnost Strukture Mape WordPress se najvarneje zagotovi z onemogočanjem neposrednega dostopa do mape "wp-includes". Namesto da bi slepo blokirali celotno mapo, je bolje onemogočiti izvajanje PHP datotek v tej mapi in onemogočiti seznam map. Mapa wp-includes namreč vsebuje nujne JavaScript, CSS in nekatere statične datoteke, ki so potrebne za delovanje jedra WordPressa; popolno onemogočenje dostopa do mape lahko pokvari oblikovanje spletne strani, urejevalnik ali funkcionalnosti vtičnikov. Pravi pristop je, da, če uporabljate Apache, z .htaccess pravili onemogočite neposreden dostop do PHP, če pa uporabljate Nginx, to storite z uporabo pravila location v blokih strežnika, nato pa testirate spletno stran z odgovori 403/404 in kritičnimi testi strani.

Najpogostejša napaka pri varnosti WordPressa je, da se uporabniki zadovoljijo le s močnimi gesli ali vtičniki za varnost. Napadalci pogosto pregledujejo mape, kjer se nahajajo osnovne datoteke, stare vtičnike, nepravilna dovoljenja datotek in odprte sezname map. Mapa wp-includes je tudi ena izmed tarč teh pregledov. V tem priročniku boste našli praktične korake, kako omejiti dostop do wp-includes v resničnih gostiteljskih okoljih, katere pravila lahko pokvarijo spletno stran, primerne konfiguracije za Apache in Nginx, metode testiranja ter seznam za vzdrževanje. Za varnejše delovanje vaše WordPress strani lahko razmislite o WordPress gostovanje in o splošni zaščiti s SSL certifikat.

Kaj je mapa wp-includes in zakaj jo je treba zaščititi?

Mapa wp-includes je ena izmed glavnih map, ki vsebuje osnovne knjižnice jedra WordPressa. V njej se nahajajo sistem tem, blok urejevalnik, sestavni deli REST API, obdelava medijev, razredi, funkcije in različne JavaScript datoteke. Poenostavljeno povedano, wp-includes je ena izmed motornih prostorov WordPressa; to ni področje, ki bi ga morali uporabniki neposredno obiskovati.

Navadni obiskovalec ne potrebuje, da odpre naslov site.com/wp-includes/. Vendar pa se v izvorni kodi strani lahko vidijo nekatere statične vsebine pod wp-includes. Na primer, privzete skripte WordPressa, skripti za emojije ali sestavni deli urejevalnika se lahko naložijo iz te mape. Zato je ob sprejemanju varnostnih ukrepov treba pravilno določiti cilj: onemogočiti neposreden spletni dostop do PHP datotek, ne da bi onemogočili delovanje statičnih datotek.

Ta razločitev je temelj profesionalnega pristopa k varnosti strukture mape WordPress. Kratkoročno se lahko zdi, da je naključno zapiranje map varno, vendar lahko povzroči težave, kot so beli zaslon na živi spletni strani, pokvarjen upravljalski panel, neobstoječi blok urejevalnik ali napačen izgled teme. Cilj je zaščititi datoteke, ki jih WordPress potrebuje, in zmanjšati površino napada.

Kaj prinaša onemogočanje dostopa do wp-includes?

Onemogočanje neposrednega izvajanja PHP v mapi wp-includes samo po sebi ne ustavi vseh napadov; vendar pa znatno zmanjša površino napada. Še posebej na okuženih spletnih straneh napadalci poskušajo naložiti zlonamerne PHP datoteke v dostopne mape ali poklicati obstoječe datoteke. Prepoved neposrednega izvajanja PHP datotek pod wp-includes ustvari dodatno oviro v tem scenariju.

Ta ukrep prinaša naslednje koristi:

• Omejuje neposredno klicanje osnovnih PHP datotek preko URL-jev.
• Pomaga preprečiti prikaz vsebine mape, če je seznam map odklopljen.
• Zmanjšuje nepotrebne uhajanja informacij pred avtomatskimi bot pregledi.
• Čeprav ni vtičnika za varnost, zagotavlja zaščito na ravni spletnega strežnika.
• Okrepi plastično varnost v kombinaciji z WAF, SSL, posodobljenim PHP in dovoljenji datotek.

Pomembno je, da je ta postopek varnostna plast. Če imate zastarele vtičnike, šibko geslo za skrbnika ali prevzet račun FTP, pravilo za wp-includes samo po sebi ne bo dovolj. Varnost je kombinacija gostiteljske infrastrukture, aplikacije, upravljanja uporabnikov in rednega vzdrževanja. Za varno osnovo lahko povežete Varno spletno gostovanje in dodatno zaščito pri upravljanju domen z Varnost domene.

Najpogostejše napake pri onemogočanju wp-includes

Popolna blokada mape

Najpogostejša napaka je blokiranje vseh HTTP zahtevkov, ki prihajajo v mapo wp-includes, z 403 napako. Ta metoda se na prvi pogled zdi smiselna; vendar lahko WordPress naleti na nepričakovane težave, ker nalaga nekatere statične vsebine iz te mape. Na primer, blok urejevalnik se morda ne bo odprl, nekatere JavaScript datoteke se morda ne bodo naložile, ali pa se bodo na prednji strani pojavile majhne, vendar kritične težave z oblikovanjem.

Uvedba pravila brez testiranja na živi strani

Edina napaka v .htaccess ali Nginx konfiguraciji lahko povzroči napako 500 Internal Server Error. To je še posebej tvegano pri straneh z velikim prometom. Preden posredujete pravilo na živo stran, je treba narediti varnostno kopijo datoteke, po možnosti preizkusiti v staging okolju in nato preiti na živo stran nadzorovano. Če v infrastrukturi Hostragons uporabljate možnosti staging ali varnostnega kopiranja, lahko Varnostno kopiranje spletnega gostovanja dodate kot naravno notranjo povezavo.

Popolnoma zaupanje v vtičnik za varnost

Vtičniki za varnost so koristni; vendar pa pravila na ravni spletnega strežnika stopijo v akcijo prej. Če je zahteva blokirana s strani Apache ali Nginx, preden doseže PHP, se zmanjša tudi poraba virov. Zato je treba osnovna pravila strežnika upoštevati tudi ob uporabi vtičnikov.

Kontrolni seznam pred uporabo

Pred omejitvijo dostopa do wp-includes je treba pripraviti kratek postopek, ki znatno zmanjša tveganje za prekinitev. Spodnji kontrolni seznam je še posebej priporočljiv za žive WordPress strani:

• Opravite varnostno kopijo trenutne .htaccess ali Nginx konfiguracije.
• Posodobite jedro WordPress, teme in vtičnike.
• Preverite, ali je vaša različica PHP podprta in varna.
• Preverite dovoljenja datotek: mape naj bodo običajno 755, datoteke 644.
• Ne pustite nepotrebnih dovoljenj za pisanje za kritične datoteke, kot so wp-config.php in .htaccess.
• Če uporabljate predpomnilnik, CDN ali vtičnik za varnost, načrtujte čiščenje predpomnilnika po spremembi.
• Ustvarite seznam kritičnih področij, ki jih je treba testirati, kot so administrativni panel, domača stran, stran z objavami, kontaktni obrazec in stran za plačilo.

Te priprave trajajo približno 10-15 minut; vendar pa preprečijo težave, ki bi lahko povzročile večurno prekinitev zaradi napačnega pravila. Pri korporativnih straneh je varneje izvesti spremembo v časih z nizkim prometom.

Onemogočanje PHP dostopa do wp-includes z .htaccess na strežniku Apache

Najpogostejša metoda na skupnih gostovanjih, ki uporabljajo Apache, je datoteka .htaccess. Pravilna pravila dodana v datoteko .htaccess, ki se nahaja v osnovni mapi WordPress, lahko preprečijo določene klice PHP v mapi wp-includes. Preden začnete, prenesite kopijo datoteke na svoj računalnik ali ustvarite varnostno kopijo preko upravljalnika datotek v nadzorni plošči gostovanja.

Priporočena pravila .htaccess

Spodnji pristop se osredotoča na onemogočanje neposrednega dostopa do PHP v mapi wp-includes in ohranja delovanje statičnih datotek:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-includes/.*[.]php$ - [F,L]
</IfModule>

Logika tega pravila je preprosta: če URL začne z wp-includes in se konča z .php, je zahteva zavrnjena. Tako se datoteke PHP v wp-includes ne morejo klicati iz brskalnika. Hkrati pa dostop do statičnih datotek, kot so .js, .css, .png, .svg, ostaja omogočen. To je bolj varna ravnotežje za prednjo stran WordPressa in upravljalski panel.

Onemogočanje seznama map

Druga ključna nastavitev je onemogočanje seznama map. Če je na strežniku omogočen seznam map, lahko uporabniki vidijo vsebino nekaterih map. Običajno je dovolj, da dodate naslednjo vrstico v glavno datoteko .htaccess:

Options -Indexes

Ta vrstica preprečuje prikaz seznama datotek v mapah, kjer ni datoteke index. V modernem gostovanju je to pogosto privzeto izklopljeno; vendar je dobro preveriti, saj predstavlja dobro varnostno prakso.

Testiranje po spremembi

Po dodajanju pravila izvedite naslednje teste:

• Odprite naslov siteadresiniz.com/wp-includes/; seznam map ne bi smel biti viden.
• Poskusite neposredno klicati znano PHP datoteko pod wp-includes; pričakujte 403 ali 404 napako.
• Preverite domačo stran, blog, in upravljalski panel.
• Preverite v orodjih za razvijalce brskalnika v razdelkih Console in Network, ali so prisotne 404/403 napake.
• Če uporabljate vtičnik za predpomnjenje ali CDN, očistite predpomnilnik.

Če so vsi testi uspešni, se lahko pravilo varno pusti v produkcijskem okolju. Če prejmete napako 500, je najhitrejša rešitev, da odstranite dodane vrstice in obnovite varnostno kopijo datoteke .htaccess.

Onemogočanje PHP dostopa do wp-includes na strežniku Nginx

Na VPS, dediciranih ali upravljanih strežniških okoljih, ki uporabljajo Nginx, .htaccess ne deluje. Pravilo je treba dodati v konfiguracijsko datoteko Nginx, običajno znotraj bloka strežnika. Za to potrebujete dostop do SSH in pravice za urejanje konfiguracijskih datotek. Če niste prepričani, je bolje poiskati pomoč pri podporni službi gostovanja.

Priporočeno pravilo lokacije Nginx

Osnovno pravilo se lahko uporablja na naslednji način:

location ~* ^/wp-includes/.*[.]php$ {
deny all;
}

To pravilo zavrača vse zahteve do PHP datotek v mapi wp-includes. Po spremembi je pomembno testirati konfiguracijo:

nginx -t

Če test uspe, se Nginx ponovno naloži:

systemctl reload nginx

Komanda reload je bolj nadzorovana v primerjavi z restart; osveži konfiguracijo brez popolnega prekinitve aktivnih povezav. Kljub temu je priporočljivo, da se spremembe na kritičnih straneh izvajajo v času z nizkim prometom.

Na kaj paziti pri uporabi Nginx

• Prepričajte se, da ste pravilo dodali v pravilen blok strežnika; na istem strežniku lahko obstaja več spletnih strani.
• Če uporabljate CDN ali obratni proxy, izvedite prave teste šele po čiščenju predpomnilnika CDN.
• Preverite, ali konfiguracija PHP-FPM obdeluje le potrebne datoteke.
• Preverite dnevniške datoteke: access.log in error.log hitro pokažejo napako v pravilih.

Napačna razvrstitev lokacij v okolju Nginx lahko privede do nepričakovanih rezultatov. Zato se prepričajte, da pravilo ne sovpada z permalinki WordPressa in bloki za obdelavo PHP.

Primerjava metod

Spodnja tabela povzema glavne metode, ki se uporabljajo za omejevanje dostopa do wp-includes:

V praksi so najboljši rezultati doseženi s kombinacijo teh metod. Na primer, ko se pravilo .htaccess na Apache gostovanju kombinira z ustreznimi dovoljenji datotek, posodobljenim jedrom WordPress, SSL in rednim varnostnim kopiranjem, se ustvari plastična obramba. Ker sta požarni zid in izolacija v gostiteljski infrastrukturi prav tako pomembna, je izbira Korporativno gostovanje kritična na pomembnih spletnih straneh.

Dovoljenja datotek in nastavitve lastništva

Onemogočanje dostopa do wp-includes ostane nepopolno, če so dovoljenja datotek napačna. Splošno sprejeta dovoljenja v WordPressu so 755 za mape in 644 za datoteke. Ta dovoljenja omogočajo spletnemu strežniku, da bere datoteke, hkrati pa zmanjšujejo nepotrebna dovoljenja za pisanje. V nekaterih posebnih gostiteljskih okoljih so lahko drugačne nastavitve uporabnikov in skupin; zato je treba upoštevati tudi priporočila vašega nadzorne plošče.

Še posebej je dovoljenje 777 resna varnostna nevarnost. Možnost pisanja za vse v mapo omogoča zlonamerne naloge datotek. Tudi v mapah, kot so wp-content/uploads, ki morajo biti pisljive, je treba onemogočiti izvajanje PHP. Mapa wp-includes pa ne bi smela biti pisljiva s strani uporabnikov, razen v primeru posodobitev WordPressa.

Med varnostnim pregledom je mogoče preveriti naslednje vrednosti:

• Mapa wp-includes: običajno 755
• PHP datoteke v wp-includes: običajno 644
• wp-config.php: po možnosti 600 ali bolj omejena dovoljenja, primerna za strukturo gostovanja
• .htaccess: običajno 644, brez nepotrebnih dovoljenj za pisanje po urejanju

Te nastavitve se lahko na vsakem strežniku obnašajo drugače. Napačna dovoljenja lahko povzročijo, da spletna stran ne more izvesti posodobitev ali brati datoteke. Po spremembi je treba pregledati zdravje WordPressa in napake v dnevnikih.

Ali varnostni vtičniki to opravijo?

Varnostni vtičniki, kot sta Wordfence in iThemes Security, lahko samodejno predlagajo nekatere ukrepe za utrjevanje. Ti vtičniki so koristni na področjih, kot so zaščita pred brute force, spremljanje sprememb datotek, skeniranje zlonamerne programske opreme in varnost prijave. Vendar je treba preveriti, kaj vtičnik počne glede onemogočanja dostopa do wp-includes.

Nekateri vtičniki samodejno dodajo pravila v .htaccess. Drugi zagotavljajo zaščito le na ravni aplikacije. Zaščita na ravni aplikacije se aktivira šele, ko zahteva doseže WordPress, zato ni tako zgodnja kot blokiranje na ravni strežnika. Zato je profesionalni pristop, da se oceni tako vtičnik kot konfiguracija strežnika.

Če uporabljate vtičnik za varnost, izvedite naslednje preglede:

• Preverite, ali vtičnik dodaja pravila v .htaccess ali Nginx.
• Prepričajte se, da se ne prekrivata dva različna pravila, ki opravljata isto nalogo.
• Preverite, ali so se nastavitve varnosti po posodobitvi vtičnika spremenile.
• Spremljajte uporabo predpomnilnika in virov strežnika za merjenje vpliva na zmogljivost.

Hkratna uporaba več varnostnih vtičnikov običajno ni dobra ideja. Prekrivajoči se požarni zid, pravila za prijavo in prepisovanje lahko zmanjšajo zmogljivost ali povzročijo napačne blokade.

Testiranje zaščite wp-includes: Praktičen scenarij

Za ugotovitev, ali je aplikacija uspešna, ni dovolj, da se spletna stran samo odpre. Spodnjih 7 korakov praktičnega testa je mogoče uporabiti v večini namestitev WordPress, od malih poslovnih strani do projektov e-trgovine:

• 1. Odprite domačo stran v skritem zavihku in preverite, ali je prišlo do vizualnih motenj.
• 2. Obiščite blog objavo, stran kategorije in stran z rezultati iskanja.
• 3. Prijavite se v wp-admin panel; odprite blok urejevalnika in knjižnico medijev.
• 4. Preverite razdelek Console v orodjih za razvijalce brskalnika.
• 5. Preverite v razdelku Network, ali ni nepotrebno blokiranih statičnih datotek pod wp-includes.
• 6. Poskusite neposredno klicati PHP datoteko pod wp-includes; pričakujte 403 ali 404 odgovor.
• 7. Preverite zapis napak strežnika za nove in ponavljajoče se napake.

Ta test traja približno 5 minut in hitro ujame napačne konfiguracije. Še posebej na straneh, ki vključujejo plačilne procese, kot je WooCommerce, je treba dodatno testirati strani za nakupovalne košarice, plačila in uporabniške račune. Na straneh, ki generirajo dobiček, lahko celo majhna ovira JavaScript vpliva na stopnjo konverzije.

Dodatni ukrepi za varnost strukture mape WordPress

Zaščita wp-includes je dober začetek; vendar je treba varnost WordPressa obravnavati celovito. Spodnji dodatni ukrepi dodatno zmanjšujejo površino napada:

• Namesto da bi poskušali skriti različico WordPressa, jo redno posodabljajte.
• Popolnoma odstranite neuporabljene teme in vtičnike.
• Ustvarite težko uganljive uporabniške namene za skrbnike.
• Uporabite dvofaktorsko avtentikacijo.
• Če ne uporabljate XML-RPC, omejite dostop do njega.
• Za wp-login.php uporabite omejitev hitrosti ali dodatno avtentikacijo.
• Redno izvajajte samodejne varnostne kopije in teste obnovitve.
• Uporabite HTTPS po celotni spletni strani; brez SSL so podatki za prijavo ogroženi.

SSL ne onemogoča dostopa do wp-includes neposredno; vendar pa zagotavlja osnovno varnost za uporabniške seje, podatke iz obrazcev in promet v upravljalskem panelu. Zato je SSL vedno ena izmed prvih plasti v varnostnih priročnikih za WordPress. Na tem mestu lahko naravno vključite povezave do kupite SSL certifikat in Namestitev brezplačnega SSL.

Kdaj bi morali poiskati profesionalno pomoč?

Dodajanje pravila .htaccess na preprostem Apache gostovanju je za večino uporabnikov obvladljivo. Vendar pa je morda bolje poiskati profesionalno pomoč, če gre za posebno konfiguracijo Nginx, več spletnih strani, trgovino WooCommerce, spletno mesto z visokim prometom ali korporativni portal. Varnostno pravilo mora biti namreč ne le tehnično pravilno, temveč tudi varno za poslovno nadaljevanje.

Priporočamo strokovno pomoč v naslednjih primerih:

• Če gostite več WordPress strani na strežniku.
• Če so Nginx, Varnish, CDN in WAF uporabljeni skupaj.
• Če se po nedavnih spremembah povečuje število napak 403, 404 ali 500.
• Če je spletna stran predhodno doživela okužbo z zlonamerno programsko opremo.
• Če upravljate sistem, ki obdeluje plačila, članstva ali osebne podatke.

Varnostna gostiteljska infrastruktura, pravilna izolacija, redno varnostno kopiranje in strokovna podpora so nevidni, a kritični deli varnosti WordPress. Pri izbiri infrastrukture je treba upoštevati ne le prostor na disku; temveč tudi varnostne kopije, požarni zid, podporo različic PHP, upravljanje SSL in kakovost tehnične podpore. V tem kontekstu so lahko Hostragons paketi gostovanja in Prilog WordPress spletne strani vsebine koristne za bralce.

Zaključek

Pravi način za onemogočanje dostopa do mape wp-includes v okviru varnosti strukture mape WordPress ni popolna blokada mape, temveč onemogočanje neposrednega dostopa do PHP datotek v mapi wp-includes in izklop seznama map. Ta postopek se lahko hitro izvede z uporabo .htaccess za Apache in pravil location za Nginx. Vendar pa je pred vsako spremembo potrebno narediti varnostno kopijo in po njej izvesti teste v upravljalskem panelu in na prednji strani.

Na kratko: ne motite statičnih datotek, omejite dostop do PHP, onemogočite seznam map, preverite dovoljenja datotek in redno posodabljajte. Za varnejšo in bolj obvladljivo infrastrukturo WordPress lahko pregledate rešitve za gostovanje, domene in SSL pri Hostragons; za podporo pri konfiguraciji, ki ustreza vašim potrebam, se lahko obrnete na nas.

Pogosta vprašanja

Ali je varno popolnoma zapreti mapo wp-includes?

Na splošno ni priporočljivo. V mapi wp-includes se lahko nahajajo JavaScript, CSS in statične datoteke, ki jih WordPress potrebuje. Popolna blokada lahko pokvari videz spletne strani ali upravljalski panel. Bolj varna izbira je onemogočiti neposreden dostop do PHP datotek v tej mapi.

Kaj storiti, če po dodajanju pravila .htaccess dobim napako 500?

Najprej odstranite zadnja dodana pravila ali obnovite varnostno kopijo datoteke .htaccess. Nato preverite pravilo glede napak v sintaksi. Če se napaka nadaljuje, preglejte dnevnik napak gostovanja ali poiščite pomoč pri tehnični podpori.

Ali .htaccess deluje na strežniku Nginx?

Ne. .htaccess se uporablja v okolju Apache in LiteSpeed. Na strežnikih Nginx se podobne omejitve izvajajo s pravili location znotraj blokov strežnika in po spremembi je treba testirati konfiguracijo z nginx -t.

Ali ta postopek popolnoma zaščiti mojo WordPress stran?

Ne. Onemogočanje dostopa do PHP datotek v wp-includes je pomembna varnostna plast, vendar sama po sebi ni dovolj. Posodobitve, močna gesla, dvofaktorska avtentikacija, SSL, varnostne kopije, požarni zid in pravilna dovoljenja datotek morajo biti skupaj uporabljeni.

Ali, če uporabljam vtičnik za varnost, moram dodati pravilo za wp-includes?

Odvisno od tega, katere pravila uporablja vtičnik. Nekateri vtičniki dodajo pravila v .htaccess, drugi pa zagotavljajo zaščito le na ravni aplikacije. Običajno je močnejša rešitev, da se na ravni strežnika omeji dostop do PHP, ne da bi pri tem povzročili prekrivanje.