XML-RPC on vanem viis, kuidas äpid WordPressiga suhtlevad. Selleks kasutatakse faili xmlrpc.php. Enamik väikeettevõtte lehti saab selle välja lülitada ja kui sa ei kasuta Jetpacki ega mõnd vanemat avaldamisäppi, siis ma teeksingi seda. Enne kontrolli siiski, kas mõni vajalik ühendus sellest sõltub.
Mis on XML-RPC WordPressis?
XML-RPC on vana kaugpäringute protokoll: äpp saadab HTTP POST-päringus XML-i ja WordPress teeb soovitud toimingu ära. WordPressis käib see aadressi /xmlrpc.php kaudu. Vaikimisi on see sisse lülitatud alates WordPress 3.5-st, mis ilmus 2012. aastal.
Nii said äpid ja teised saidid eemalt postitusi avaldada, sisu muuta ning lehte hallata. XML-RPC kaudu töötavad ka pingback’id ja trackback’id. Omal ajal oli sellest kasu, sest eraldi äpist avaldamiseks polnud palju muid mugavaid viise.
Praegu teeb suure osa sellest tööst REST API, mis kuulub WordPressi põhiosa alates versioonist 4.7. Ka ametlik WordPressi mobiiliäpp saab kasutada rakenduse paroole ja REST API-t. Seega telefonist postitamine ei tähenda automaatselt, et XML-RPC peab lahti olema. Vaata üle just see äpp, mida sina kasutad.
Üks konks siiski on. Jetpack kasutab XML-RPC-d endiselt osade WordPress.com-iga seotud toimingute jaoks. Sama võivad teha vanemad arvutis töötavad blogimisprogrammid, IFTTT/Zapieri moodi ühendused ning vanemad Androidi või iOS-i avaldamisäpid. Vana ei tähenda, et see oleks kasutusest kadunud.
Miks botid xmlrpc.php-d pommitavad?
Neid tõmbab ligi system.multicall. Sellega saab panna ühte HTTP-päringusse sadu kasutajanime ja parooli katseid. Sisselogimiskatsete piiraja, mis loeb ainult wp-login.php päringuid, ei pruugi neid näha, kuigi bot proovib samal ajal XML-RPC kaudu paroole.
See eristab xmlrpc.php kaudu tehtavat paroolirünnet tavalisest sisselogimislehe ründamisest. Eesmärk on sama: leida toimiv sisselogimine. Teekond ja katsete pakkimise viis on teised. Sisselogimislehte tuleb kaitsta, aga see ei kata automaatselt XML-RPC-d. Meie WordPressi sisselogimise kaitse juhend räägib peauksest; XML-RPC kohta tuleb eraldi otsus teha.
Siis on veel pingback.ping. Ründaja võib panna sinu lehe saatma päringuid ohvrile DDoS-peegeldusrünnaku osana või kasutada seda sisemiste serverite uurimiseks. Vaevalt et e-poe omanik sellist võimalust küsis.
Ja üks nüanss veel: XML-RPC lubab rakenduse paroole ning paljud kaheastmelise autentimise lahendused ei kaitse XML-RPC kaudu sisselogimist. See, et tavalisel sisselogimislehel küsitakse teist kinnitust, ei tõesta veel, et see tee on kaetud.
Kuidas kontrollida, kas XML-RPC on sisse lülitatud?
Alusta lihtsast kontrollist. Ava brauseris https://yoursite.com/xmlrpc.php ja asenda domeen enda omaga. Kui näed teadet XML-RPC server accepts POST requests only., on see aadress ligipääsetav. See on vihje, mitte tõend, et kõik XML-RPC meetodid või sisselogimine toimivad: brauser saatis GET-päringu, XML-RPC kasutab POST-i.
Kui terminali kasutamine on sulle okei, küsi sellelt aadressilt saadaolevate meetodite nimekirja:
curl -s -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>' https://yoursite.com/xmlrpc.phpKui pääsed serveri logidele ligi, otsi korduvaid POST /xmlrpc.php kirjeid juhuslikelt IP-aadressidelt. Sellist jälge botid jätavadki. Kui ligipääs on blokeeritud, võid näha hoopis keelavat vastust. Kui miski seda aadressi ei kasuta, on see just soovitud tulemus.
Kas XML-RPC tuleks välja lülitada?
Enamiku väikeste ettevõtete lehtede puhul jah, täielikult. Kui muudad lehti WordPressis, võtad tellimusi vastu oma e-poes ega kasuta vanemat avaldamisprogrammi, ei tunne sa sellest ilmselt puudust. Ma ei jätaks tagumist ust lahti lihtsalt seepärast, et see oli algusest peale olemas.
Enne blokeerimist peatu korraks, kui kasutad:
- Jetpacki, mis vajab XML-RPC-d osaks ühendusest WordPress.com-iga.
- Vanemat arvuti- või mobiiliäppi, mis avaldab sinu lehele postitusi.
- Vanemat automaatikat või muud ühendust, mis sõltub XML-RPC-st.
Kui sa ei tea kas mõni äpp seda vajab, pane enne muutmist kirja kõik äpid, mis sisu avaldavad või sünkroonivad. Seejärel võid XML-RPC välja lülitada, ühendused läbi proovida ja vajadusel muudatuse tagasi võtta. Kui keegi teine haldab sinu lehe ühendusi, küsi temalt enne. Pole mõtet avastada katkist ühendust keset kiiret müügipäeva.
Kuidas XML-RPC WordPressis välja lülitada?
Vali üks viis. Kõiki allolevaid variante pole vaja korraga kasutusele võtta. Mina eelistan blokeerimist serveris, sest siis ei jõua päring üldse PHP-ni. Plugina lüliti on lihtsam, kui serveri seadete muutmine ei kõla just mõnusa pärastlõunana.
Blokeeri xmlrpc.php serveris
Apache’i puhul lisa oma lehe .htaccess faili see:
<Files xmlrpc.php>
Require all denied
</Files>Nginxi puhul on vastav serveri seadistus järgmine:
location = /xmlrpc.php { deny all; }Kui sa ei tea, kus see seadistus asub, palu muudatus teha majutajal või lehe haldajal. Jetpacki kasutades ära XML-RPC-d täielikult blokeeri, kui sa pole valmis selle ühenduse katkemiseks. Teine võimalus on lubada ainult Jetpacki IP-aadressid, kuid seda nimekirja tuleb edaspidi jälgida.
Kasuta koodijuppi või mu-pluginat
See PHP filter keelab XML-RPC meetodid, mis nõuavad sisselogimist:
add_filter( 'xmlrpc_enabled', '__return_false' );Tähtis: see ei lülita välja pingback’e. Kui valid selle tee, eemalda ka pingback’i meetodid:
add_filter( 'xmlrpc_methods', function ( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );Pane kood koodijuppide haldamise vahendisse või mu-pluginasse, mitte kohta, kust see teema vahetamisel kaob. Ära ka eelda, et ülal kirjeldatud brauserikontroll näitab nüüd blokeeritud aadressi. See lahendus muudab seda, mida XML-RPC teha saab, mitte ei peata päringut serveris.
Kasuta turvapluginat või tulemüüri
Enamikul turvapluginatel on XML-RPC väljalülitamise lüliti. Kui sa serveri faile ei puutu, on see kõige lihtsam algus. Lülita see sisse ja proovi seejärel oma äpid ning ühendused läbi. Loe ka, mida lüliti täpselt blokeerib: mõni lahendus keelab sisselogimise, kuid jätab pingback’i meetodid alles. Turva plugin ei tee kõiki neid valikuid sinu eest.
Mis siis, kui XML-RPC peab sisse jääma?
Jäta see sisse põhjusega, mitte kogemata. Kui Jetpack või vanem äpp seda vajab, piira tulemüüris päringute sagedust, kasuta tugevaid ja igal pool erinevaid paroole ning kontrolli, et tulemüür kataks ka /xmlrpc.php. Siin saab abiks olla tasuta WordPressi tulemüür.
Ka WordPressi sisselogimise kaitse on vajalik, aga kontrolli eraldi, kas sinu seadistus hõlmab XML-RPC-d. Ainult wp-login.php jaoks tehtud reeglid ei pruugi seda liiklust peatada.
Pärast muudatust avalda testpostitus äpist, mida kasutad, ja kontrolli Jetpacki ühendust, kui see sul olemas on. Seadistus pole valmis enne, kui oled proovvinud asja, mille see võib katki teha.
Mida XML-RPC väljalülitamine ei paranda?
See ei tee nõrku paroole tugevamaks ega uuenda vana pluginat. Samuti ei takista see botte REST API kaudu kasutajanimesid leidmast. See on eraldi teema, millest räägime loos REST API kaudu kasutajate leidmisest. XML-RPC on üks võimalik sissepääs mitmest. Kui sa seda ei vaja, pane see kinni ja tegele ka ülejäänud lehega.
Kahe minuti kontroll tänaseks
Ava oma lehe /xmlrpc.php aadress. Kui näed teadet, et server võtab vastu ainult POST-päringuid, küsi endalt üks asi: mis minu lehel seda veel kasutab? Kontrolli Jetpacki ja avaldamisäppe. Kui vastus on „mitte miski“, lülita XML-RPC välja ning proovi oma tavaline postitamise viis läbi. Kaks minutit kuluvad nii paremini kui botte kuulamata ukse taga, mida sa ise ei kasuta.