Isključivanje WordPress XML-RPC: Najbrži način za smanjenje brute force napada

Isključivanje WordPress XML-RPC-a je proces koji brzo smanjuje brute force pokušaje, zloupotrebe pingback-a i nepotreban bot promet onemogućavanjem udaljenog pristupa xmlrpc.php datoteci na vašoj web stranici. Ako ne koristite Jetpack, WordPress mobilnu aplikaciju, stare alate za udaljeno objavljivanje ili prilagođenu integraciju koja koristi XML-RPC, isključivanje XML-RPC-a je sigurni i praktični korak za očvršćavanje većine WordPress stranica. Najefikasnija metoda je blokiranje zahtjeva na razini servera prije nego što WordPress obradi; to jest, isključivanje pristupa xmlrpc.php putem Apache, LiteSpeed, Nginx ili WAF pravila obično je učinkovitije od gašenja putem dodatka.

U ovom vodiču ćete korak po korak saznati zašto biste trebali isključiti WordPress XML-RPC, u kojim slučajevima ne biste trebali isključiti i kako to sigurno implementirati u različitim okruženjima servera. Bez obzira na to radite li na infrastrukturi Hostragons ili drugom hosting okruženju, cilj je smanjiti površinu napada bez kompromitovanja vaše stranice, smanjiti nepotrošene resurse i stvoriti upravljivi sigurnosni standard. Ako tražite brzu i sigurnu osnovu za hosting vaše WordPress stranice, WordPress hosting izbor je takođe važan deo ovog procesa.

Što je XML-RPC i koja je njegova svrha u WordPress-u?

XML-RPC je stari protokol za udaljenu komunikaciju koji omogućava različitim sistemima da komuniciraju slanjem podataka u XML formatu putem HTTP-a. U WordPress-u, ta funkcionalnost se najčešće obavlja putem xmlrpc.php datoteke u korenskom direktoriju. Historijski gledano, ova datoteka se koristila za objavljivanje postova iz WordPress mobilne aplikacije, upravljanje komentarima na daljinu, pingback-e i interakciju nekih trećih strana sa stranicom.

Kako je REST API postao mnogo popularniji u modernom WordPress ekosistemu, značaj XML-RPC-a je opao. Međutim, datoteka je i dalje dostupna u mnogim instalacijama. To znači da je lako prepoznatljiva, standardno dostupna i može biti automatizovana kao meta za napadače. Botovi, posebno oni koji skeniraju nasumične IP adrese, mogu pokušati pristupiti xmlrpc.php adresi u roku od nekoliko minuta, čak i ako je vaša domena tek postavljena. Stoga je važno razmisliti o sigurnosnim osnovama prilikom aktiviranja nove domene koristeći provjera domene.

U kojim slučajevima XML-RPC može biti potreban?

XML-RPC nije potreban za svaku stranicu. Neke starije funkcije Jetpack-a, određene operacije WordPress mobilne aplikacije, razne usluge automatizacije ili stari desktop blog editori mogu zahtevati XML-RPC. Takođe, prilagođene integracije mogu koristiti xmlrpc.php za slanje sadržaja ili prikupljanje podataka na daljinu. Stoga je važno proveriti radne tokove vaše stranice pre nego što ga isključite.

Praktična provera je sledeća: Ako sadržaj na vašu stranicu unosite samo putem wp-admin panela, ne koristite Jetpack, ne objavljujete putem mobilne aplikacije i vaš programer nije postavio prilagođenu XML-RPC integraciju, verovatno vam XML-RPC nije potreban. Veći deo korporativnih stranica, blogova, katalog stranica, malih poslovnih web stranica i WooCommerce prodavnica radi besprekorno dok je XML-RPC isključen. Ipak, ako imate kritične procese kao što su plaćanje i integracije sa dostavom, najbolje je testirati promenu tokom perioda sa malo saobraćaja.

Zašto je WordPress XML-RPC rizičan za brute force napade?

Brute force napad je kada napadač automatskim alatima neprekidno pokušava različite kombinacije korisničkog imena i lozinke. U WordPress-u, ovi pokušaji se obično obavljaju putem wp-login.php; međutim, XML-RPC može napadaču ponuditi povoljniji put. Neki XML-RPC metodi omogućavaju više pokušaja prijave unutar jedne HTTP zahteva. Osobito, funkcija system.multicall može pomoći u obavljanju stotina pokušaja sa manje vidljivim zahtevima na loše konfiguriranim sistemima.

Na primer, pokušaj 500 lozinki putem wp-login.php izgleda kao 500 zasebnih zahteva, dok se isti pokušaji mogu poslati u manjem broju paketa putem XML-RPC. To može dovesti do toga da sigurnosni dodaci i jednostavno praćenje logova otkriju napad sa zakašnjenjem. Na kraju, CPU opterećenje raste, PHP radnici postaju zauzeti, baza podataka se opterećuje nepotrebnim upitima, a pravi posetioci dobijaju sporije odgovore. U okruženjima deljenog hostinga, to nije samo sigurnosni rizik već i problem performansi i korišćenja resursa.

Još jedan rizičan aspekt XML-RPC-a je zloupotreba pingback-a. Pingback mehanizam je dizajniran kako bi obavestio da je druga stranica linkovala na vaš sadržaj; međutim, može se zloupotrebiti za generisanje prometa sličnog DDoS-u ili za ciljanje trećih strana. Stoga isključivanje XML-RPC-a ne samo da smanjuje pokušaje prijave, već takođe smanjuje verovatnoću zloupotrebe pingback-a.

Odluka o isključivanju XML-RPC-a: Brza tabela poređenja

Kao što se može videti iz tabele, najbrži i najmoćniji put je isključiti XML-RPC na serveru ili WAF nivou ako vam nije potreban. Korišćenje dodatka je lako; međutim, ako napadački zahtev dođe do PHP-a, potrošnja resursa će se nastaviti. Stoga, na sajtovima sa visokim prometom, fokus na e-trgovinu ili napadima, prioritet bi trebao biti pravilo za web server.

Kontrolna lista pre nego što počnete

Osnovni princip prilikom postavljanja sigurnosnih opcija je prvo meriti i pripremiti plan povratka. Proces isključivanja XML-RPC-a je obično bez rizika; međutim, nijedna promena ne bi trebala biti izvedena nasumice na aktivnoj stranici. Sledeća kontrolna lista smanjuje verovatnoću grešaka tokom implementacije.

• Napravite rezervnu kopiju aktivnog fajla i baze podataka iz poslednja 24 sata. Rezervna kopija pre ažuriranja WordPress-a, sigurnosne prilagodbe i promene dodatka je obavezna.
• Proverite da li koristite Jetpack, WordPress mobilnu aplikaciju, alat za udaljeno objavljivanje ili prilagođene integracije.
• Istražite broj xmlrpc.php zahteva u pristupnim logovima. Ako vidite desetine ili stotine zahteva po minuti, mogli biste biti pod napadom.
• Izvršite promenu tokom sati sa niskim prometom. Posebno u WooCommerce prodavnicama, testirajte tokove korpe, plaćanja i članstva kasnije.
• Odredite metodu povratka. Osigurajte da imate pristup upravljaču datotekama, FTP-u ili SSH-u za komentarisanje ili brisanje pravila koja ste dodali.

U profesionalnom hosting okruženju, redovno pravljenje rezervnih kopija, ažurirane verzije PHP-a, izolovana struktura računa i podrška vatrozida čine veliku razliku. U vezi sa ovim pitanjima, možete se povezati sa Siguran Web Hosting i SSL certifikat sadržajima za opštu sigurnost sajta.

Metoda 1: Isključivanje XML-RPC-a putem .htaccess na Apache-u ili LiteSpeed-u

Najčešći način na WordPress stranicama koje koriste Apache i LiteSpeed je dodavanje pravila za blokiranje pristupa xmlrpc.php u .htaccess datoteku u korenskom direktoriju. Budući da LiteSpeed podržava .htaccess pravila kompatibilna sa Apache-om, ova metoda se može direktno primeniti u mnogim hosting okruženjima. Najveća prednost je što se zahtev odbija pre nego što WordPress jezgra počne obrađivati.

Korak po korak implementacija

• Otvorite upravljačku ploču hostinga i pristupite upravljaču datotekama ili se povežite sa public_html direktorijem putem FTP-a.
• Pronađite .htaccess datoteku i napravite njenu rezervnu kopiju na računaru. Ako datoteka nije vidljiva, aktivirajte opciju za prikaz skrivenih datoteka.
• Ne brišući pravila koja je postavio WordPress, dodajte pravilo za blokiranje XML-RPC-a na vrh datoteke.
• Logika pravila trebala bi biti: odbiti sve pristupe xmlrpc.php datoteci.
• Sačuvajte promene i proverite adresu vašeg domena, npr. alanadiniz.com/xmlrpc.php u pretraživaču.

Logika koju ćete koristiti u Apache 2.4 i LiteSpeed okruženjima je sledeća: za xmlrpc.php datoteku koristi se definicija Require all denied. U starijim Apache 2.2 okruženjima može se videti pristup sa Deny from all; međutim, preporučuje se korišćenje ažuriranog server softvera prema standardu iz 2026. godine. Ako još uvek radite sa starijom verzijom Apache-a, to je pitanje koje treba unaprediti ne samo za XML-RPC već i za opštu sigurnost.

U slučaju uspešnog blokiranja, adresa xmlrpc.php može vratiti odgovor 403 Forbidden, 404 Not Found ili slične odgovore u zavisnosti od konfiguracije servera. Važno je da stranica ne vrati odgovor poput XML-RPC server accepts POST requests. Ako se ova izjava vidi, to znači da je datoteka i dalje dostupna.

Metoda 2: Blokiranje pristupa XML-RPC-u na Nginx-u

U Nginx okruženjima .htaccess ne radi; jer Nginx ne čita .htaccess na bazi direktorijuma. Stoga, pravilo treba dodati u konfiguraciju server block-a koji pripada vašoj stranici. Ako koristite upravljani hosting, ovo polje možda neće biti direktno dostupno za vas; u tom slučaju možete zatražiti od tima tehničke podrške da isključi pristup xmlrpc.php.

Osnovni pristup na Nginx-u je odbijanje zahteva ili vraćanje 404 putem location = /xmlrpc.php bloka. Sa sigurnosnog aspekta, eksplicitno zabraniti 403 ili prikazati 404 kao da datoteka ne postoji može se koristiti. Pristup 404 preferiraju administratori koji žele da daju manje informacija botovima. Nakon dodavanja pravila, treba testirati Nginx konfiguraciju i ponovo učitati servis. Ova operacija mora biti pažljivo izvršena jer netačan karakter može sprečiti otvaranje cele stranice.

Nakon promene na VPS ili dedicated serverima koji koriste Nginx, korisno je pratiti pristupne logove. Trebali biste videti da xmlrpc.php zahtevi više ne rezultiraju 403 ili 404. Ako se isti IP adrese i dalje pokušavaju učestalo, može se dodati drugi sloj zaštite putem fail2ban, ograničenja brzine ili WAF pravila. Za sveobuhvatnije vodiče o upravljanju serverima, možete se obratiti sigurnost VPS servera.

Metoda 3: Isključivanje XML-RPC-a putem sigurnosnog dodatka

Za korisnike koji ne žele da uređuju tehničke datoteke, sigurnosni dodaci su praktično rešenje. Dodatci poput Wordfence, Solid Security ili All-In-One Security mogu imati opcije za isključivanje XML-RPC-a, isključivanje pingback-a ili blokiranje pokušaja prijave putem XML-RPC-a. Ova metoda obezbeđuje brz početak, posebno za male blogove i osnovne korporativne stranice.

Međutim, važno je znati granice pristupa putem dodatka. Ako dodatak blokira zahtev nakon što WordPress obradi, napadač može ponovo aktivirati PHP proces. To znači da potrošnja CPU-a i memorije nije potpuno zaustavljena u slučaju intenzivnih napada. Stoga, isključivanje putem dodatka je mnogo bolje od ne preduzimanja nikakvih mera; ali na stranicama koje su pod napadom, trebala bi se dodati zaštita na nivou servera ili WAF-a.

Šta treba imati na umu pri korišćenju dodatka

• Preuzmite sigurnosni dodatak samo iz zvaničnog WordPress dodatka direktorija ili sa zvanične stranice proizvođača.
• Nemojte birati dodatke koji se dugo nisu ažurirali. Aktivno održavanje i usklađenost u 2026. godini je važan signal sigurnosti.
• Ne koristite više sigurnosnih dodataka za istu funkcionalnost. Sukobi mogu izazvati probleme sa prijavom, keširanjem i pristupom datotekama.
• Nakon postavljanja XML-RPC opcije, testirajte zdravlje stranice, obrasce, prijavu članstva i tokove plaćanja.
• Redovno pregledajte logove dodatka. Ako postoji kontinuirani napad, dodajte blokiranje na osnovu IP-a ili WAF pravila.

Metoda 4: Blokiranje putem WAF-a, CDN-a i vatrozida hostinga

Web Application Firewall, poznat kao WAF, jedan je od najučinkovitijih slojeva za filtriranje štetnih zahteva pre nego što dođu do aplikacije. CDN rešenja kao što je Cloudflare mogu blokirati xmlrpc.php zahteve ispred servera. ModSecurity ili posebna WAF pravila koja nudi vaš pružatelj hostinga takođe funkcionišu na sličan način. Ovaj sloj je posebno dragocen za blokiranje velikog broja bot zahteva bez da dođu do WordPress-a.

Pravilo WAF-a mora biti jasno: ako URI putanja sadrži xmlrpc.php, blokiraj zahtev ili primeni izazov. Ako vam XML-RPC nije potpuno potreban, blokada je jasnija. Ako vam je potrebna delimična podrška, možete koristiti pristup samo određenim IP adresama. Na primer, ako vaša automatizovana usluga dolazi sa fiksnog IP-a, ovaj IP može biti stavljen na belu listu, a svi ostali xmlrpc.php zahtevi se odbacuju. Ova metoda je uravnotežena između sigurnosti i kontinuiteta poslovanja.

WAF sloj je značajniji uz SSL. Na sajtovima koji ne koriste HTTPS, podaci za prijavu i sigurnost sesije su dodatno ugroženi. Stoga je uz isključivanje XML-RPC-a neophodno pokrenuti celu stranicu putem HTTPS-a, razmotriti upotrebu HSTS-a i pratiti trajanje sertifikata. U ovom trenutku, SSL certifikat i Instalacija besplatnog SSL-a mogu biti korišćeni kao prirodne podrške.

Kako testirati nakon isključivanja XML-RPC-a?

Nakon promene, jedina tačka koju treba proveriti nije samo otvaranje stranice. Treba izvršiti provere kao što su: Da li je XML-RPC isključen, da li sistem prijave funkcioniše bez problema, da li su stvarni korisnički procesi pogođeni, da li postoje očekivani rezultati u logovima i slično. Sledeći tok testiranja pruža praktičnu i dovoljnu validaciju.

• Otvorite adresu alanadiniz.com/xmlrpc.php u pretraživaču. Očekuje se da dobijete odbijeni pristup, 404 ili prazan odgovor. Tekst XML-RPC server accepts POST requests ne bi trebao da se vidi.
• Prijavite se na WordPress administrativnu ploču sa vašim običnim korisničkim podacima. Potvrdite da se stranica za prijavu normalno otvara, nezavisno od XML-RPC-a.
• Testirajte kontakt formu, formu za komentare, prijavu članstva i WooCommerce korake plaćanja.
• Proverite u pristupnim logovima servera koji status kodovi se vraćaju za xmlrpc.php zahteve. Odgovori 403 ili 404 pokazuju da pravo pravilo funkcioniše.
• Ako koristite sigurnosni dodatak, pregledajte dnevnik događaja. Trebali biste primetiti smanjenje starih pokušaja bota ili da su oni blokirani.

Za tehničkiji test, možete poslati POST zahtev putem terminala; međutim, za većinu vlasnika stranica, provere putem pretraživača i logova su dovoljne. Ako se nakon promene izgubi veza sa Jetpack-om, mobilna aplikacija ne može objaviti ili dođe do greške u integraciji, to znači da je XML-RPC zapravo potreban. U tom slučaju, umesto potpunog isključivanja, treba razmotriti strategiju davanja dozvola na osnovu IP-a ili primenu ograničenja brzine.

Da li je isključivanje XML-RPC-a dovoljno? Dodatne sigurnosne mere

Isključivanje XML-RPC-a je brza i efikasna mera protiv brute force napada; međutim, samo po sebi ne obezbeđuje potpunu sigurnost. Napadači mogu nastaviti pokušaje preko wp-login.php, REST API-a, slabo konfigurisanih dodataka, starih tema ili provaljenih lozinki. Stoga, nakon isključivanja XML-RPC-a, važno je razmišljati o višeslojnoj sigurnosti WordPress-a.

Osnovne mere koje treba primeniti

• Koristite jaku lozinku i jedinstveno korisničko ime. Izbegavanje korisničkog imena admin je i dalje jednostavna, ali efikasna mera.
• Dodajte dvostruku autentifikaciju. 2FA na administratorskim računima ozbiljno smanjuje rizik od provale lozinki.
• Primijenite ograničenje pokušaja prijave. Koristite ograničenja brzine ili sigurnosni dodatak za wp-login.php.
• Ažurirajte WordPress jezgro, dodatke i teme. Stari dodaci su jedan od najčešćih uzroka stvarnih provala.
• Obrišite dodatke i teme koje ne koristite. Pasivni, ali stari dodaci mogu takođe predstavljati rizik na datotečnom sistemu.
• Proverite dozvole datoteka. Nepotrebne dozvole za pisanje povećavaju rizik od zlonamernog učitavanja datoteka.
• Redovno pravite rezervne kopije i testirajte vraćanje. Rezervna kopija je pretpostavka dok se ne testira.
• Koristite pouzdanu hosting infrastrukturu. Izolacija, ažurirani PHP, WAF i podrška za pravljenje rezervnih kopija smanjuju uticaj napada.

Na primer, ako samo isključite XML-RPC i ostavite lozinku za administratora kao 123456, najslabija karika sigurnosnog lanca ostaje otvorena. S druge strane, korišćenje jakih lozinki, 2FA, ažuriranog softvera, WAF-a i sigurnog hostinga zajedno smanjuje učinak običnih bot napada. Ovaj pristup je takođe važan za SEO u 2026. godini; jer slabo zaštićene stranice mogu doživeti zlonamerne preusmeravanja, generisanje spam stranica i zagađenje indeksa, gubeći organsku vidljivost.

Uticaj isključivanja XML-RPC-a na performanse i SEO

XML-RPC napadi nisu direktni faktor rangiranja; međutim, njihovi indirektni uticaji su snažni. Ako intenzivan bot promet troši resurse servera, vreme odgovora stranice se povećava, Core Web Vitals vrednosti se mogu pogoršati, a iskustvo stvarnih korisnika može opasti. Takođe, na stranicama koje često nailaze na ograničenja resursa mogu se pojaviti 500 greške, problemi sa vremenskim ograničenjima i prekidi. Googlebot takođe može sporije ili pažljivije indeksirati sporadične ili greške stranice.

Razmislimo o jednom primeru: Normalno, vaša početna stranica se otvara sa vremenom odgovora servera od 300 ms; međutim, kada xmlrpc.php primi 1000 zahteva u minuti, PHP radnici se preopterećuju i vreme odgovora prelazi 2 sekunde. Na strani korisnika, stranica se usporava, stopa konverzije opada, a statistika indeksiranja u Google Search Console može varirati. Isključivanje XML-RPC-a na nivou servera pomaže u prekidu ovog nepotrebnog opterećenja pre nego što dođe do aplikacijskog sloja, čime se doprinosi stabilnosti performansi.

Što se tiče SEO-a, sigurna i brza stranica zavisi od tehničke infrastrukture koliko i od kvaliteta sadržaja. HTTPS, ažurirani PHP, brzi disk, pravilno keširanje, čista struktura teme i smanjenje površine napada treba se razmatrati zajedno. Zbog toga bi podešavanje sigurnosti WordPress-a trebalo biti na agendi ne samo sistemskih administratora već i SEO i timova za sadržaj. Ova tema može biti podržana sadržajem Optimizacija brzine WordPressa i kontrolna lista tehničkog SEO-a unutar Hostragons bloga.

Alternativne strategije ako ne možete potpuno isključiti XML-RPC

U nekim projektima XML-RPC se ne može potpuno isključiti. Na primer, određeni mobilni tokovi objavljivanja, korporativna automatizacija ili stare integracije i dalje mogu zavisiti od ovog protokola. U tom slučaju, cilj nije ostaviti sve otvoreno, već kontrolisati pristup. Prva opcija je beleženje IP adresa. Pristup XML-RPC-u je dozvoljen samo IP adresama pouzdanih usluga, dok se svi ostali zahtevi odbacuju.

Druga opcija je primena ograničenja brzine. Sprečava se slanje previše xmlrpc.php zahteva u kratkom vremenskom periodu sa određenog IP-a. Ova metoda nije tako sigurna kao potpuno isključivanje; međutim, smanjuje obim napada na stranicama koje imaju potrebu za uslugom. Treća opcija je onemogućavanje pingback metoda i omogućavanje samo potrebnih metoda. Ovo zahteva napredniju konfiguraciju i treba ga primeniti pod kontrolom programera.

Četvrta opcija je povezivanje pristupa XML-RPC-u sa dodatnim sigurnosnim slojem. Na primer, može se zahtevati dodatna autentifikacija putem HTTP basic auth, VPN-a, ograničenja korporativnih IP adresa ili WAF izazova. Ovi pristupi smanjuju rizik od javne tačke pristupa. Ipak, gde god je moguće, dugoročno rešenje je prebacivanje starih integracija na modernije i kontrolisane metode kao što je REST API.

Praktična mapa puta za korisnike Hostragons-a

Ako ste vlasnik stranice koja se hostuje na Hostragons-u, prvo uradite analizu potreba za XML-RPC sigurnošću, a zatim izaberite najmanje složenu metodu. U deljenim hosting ili WordPress hosting paketima, uređivanje .htaccess putem upravljača datotekama može biti dovoljno za većinu korisnika. Ako koristite VPS ili posvećeni server, možete planirati korišćenje Nginx-a, Apache-a, LiteSpeed-a i WAF slojeva zajedno.

Redosled primene može biti sledeći: Prvo napravite rezervnu kopiju, zatim proverite servise koji koriste XML-RPC, zatim izvršite blokiranje na serveru, završite testove i pratite logove tokom 24 sata. Ako napadi nastave, dodajte pravilo WAF-a, blokiranje IP-a i ograničenje pokušaja prijave. Na kraju, završite sa opštim sigurnosnim podešavanjima kao što su 2FA, politika ažuriranja, redovne rezervne kopije i SSL.

Ovaj proces nije prodajna strategija, već osnovni korak higijene. Ipak, ako vaša infrastruktura neprestano stvara probleme zbog starih verzija PHP-a, nedovoljnih resursa ili nedostatka vatrozida, razmatranje savremenijeg hosting plana može biti razborito. Okruženje optimizovano za WordPress sa sigurnosnim slojevima pruža otpornost u trenutku napada i poboljšava svakodnevne performanse. U tom kontekstu, stranice WordPress hosting, cloud server i SSL certifikat nude prirodne smernice za čitaoce.

Često postavljana pitanja

Da li isključivanje WordPress XML-RPC-a može oštetiti moju stranicu?

U većini standardnih WordPress stranica, isključivanje XML-RPC-a ne oštećuje stranicu. Administrativna ploča, tema, sadržaj, obrasci i korisnički deo obično nisu pogođeni. Međutim, ako koristite Jetpack, WordPress mobilnu aplikaciju ili prilagođene integracije koje koriste XML-RPC, mogu se javiti problemi sa povezivanjem. Stoga je važno proveriti potrebu za korišćenjem pre isključivanja i testirati osnovne funkcionalnosti nakon toga.

Kako mogu znati da li je XML-RPC isključen?

Otvorite adresu alanadiniz.com/xmlrpc.php u pretraživaču. Ako vidite poruku poput XML-RPC server accepts POST requests, datoteka je dostupna. Ako dobijete 403, 404 ili odbijeni pristup, pravilo za isključivanje verovatno funkcioniše. Za precizniju proveru možete pregledati pristupne logove servera i videti koji status kodovi se vraćaju za xmlrpc.php zahteve.

Da li isključivanje XML-RPC-a potpuno zaustavlja brute force napade?

Isključivanje XML-RPC-a u velikoj meri smanjuje pokušaje brute force-a; međutim, ne eliminiše sve rizike. Napadači mogu nastaviti pokušaje putem wp-login.php. Stoga, isključivanje XML-RPC-a treba biti praćeno snažnim lozinkama, dvostrukom autentifikacijom, ograničenjem pokušaja prijave, WAF-om i politikom ažuriranja dodataka.

Da li trebam isključiti XML-RPC ako koristim Jetpack?

Neke funkcije Jetpack-a mogu zahtevati XML-RPC vezu. Ako koristite Jetpack, proverite koje module koristite pre nego što potpuno isključite XML-RPC. Alternativno, možete odobriti pristup samo IP adresama Jetpack usluga, blokirati sve druge xmlrpc.php zahteve ili definisati kontrolisani pristup na WAF-u.

Da li je bolje isključiti putem dodatka ili na serveru?

Za najbolju performansu i sigurnost, isključivanje na serveru ili WAF nivou je efikasnije; jer se zahtev odbija pre nego što WordPress i PHP obrade. Isključivanje putem dodatka je lakše za korisnike sa malo tehničkog znanja, ali ne može potpuno sprečiti potrošnju resursa u slučaju intenzivnih napada. Ako je moguće, treba preferirati pravilo servera, a ako ne, pouzdan dodatak sa WAF podrškom.

Kratak pregled i sledeći koraci

Isključivanje WordPress XML-RPC-a je jedan od najbržih načina za smanjenje brute force, zloupotrebe pingback-a i nepotrebnog bot prometa na stranicama koje ne koriste XML-RPC. Najrobustniji pristup je blokiranje pristupa xmlrpc.php na serveru ili WAF-u, a zatim izgradnja višeslojne zaštite sa bezbednošću prijave, 2FA, ažuriranjima, SSL-om i redovnim rezervnim kopijama. Ako želite da pregledate infrastrukturu vaše stranice, možete istražiti rešenja za WordPress hosting i sigurnost Hostragons-a; možete započeti sa malom kontrolnom listom za vašu trenutnu stranicu danas.