• Atbalsts gan xmlrpc klientu, gan serveru izveidei
• Pilnībā automatizēta vai pilnībā manuāla, smalkgraudaina kodēšana un dekodēšana no php vērtībām uz xmlrpc
• Atbalsts UTF8, Latin-1 un ASCII rakstzīmju kodēšanai. Ja ir iespējots php mbstring paplašinājums, tiek atbalstīts vēl vairāk rakstzīmju kopu.
• Atbalsts gan pieprasījumu, gan atbilžu http saspiešanai, sīkfailiem, starpniekserveriem, pamata autentifikācijai un https, ntlm autentifikācijai un saglabāšanai ar paplašinājumu php cURL
• Ienākošā xmlrpc pieprasījuma parametru tipu izvēles validācija
• Atbalsts metodēm system.listMethods, system.methodHelp, system.multicall un system.getCapabilities
• Atbalsts par un xmlrpc paplašinājumi
• Iespēja reģistrēt esošās php funkcijas vai klases metodes kā tīmekļa pakalpojumus, iegūstot pievienotās vērtības informāciju no phpdoc komentāriem
• Bibliotēkā ir iekļauts tīmekļa vizuālais atkļūdotājs

Prasības

• PHP 5.3.0 vai jaunāka versija; Ieteicams 5.5 vai jaunāks
• php "curl" paplašinājums ir nepieciešams, ja vēlaties izmantot SSL vai HTTP 1.1, lai sazinātos ar attāliem serveriem
• php paplašinājums "mbstring" ir nepieciešams, lai ļautu saņemt pieprasījumus/atbildes rakstzīmju kopās, kas nav ASCII, Latin-1, UTF-8
• php "xmlrpc" vietējais paplašinājums nav nepieciešams, taču, ja tas ir instalēts, šīs bibliotēkas darbība netiks traucēta.

Lejupielādēt

Jaunumi

• 2017. gada 1. jūlijs
  Izlaistas lib versijas 4.2.0 un 3.1.0.
  Izlaiduma piezīmes ir pieejamas vietnē Github
• 2016. gada 20. janvāris
  Izlaista lib versija 4.0.0.
  Šī ir pirmā reize, kad API saskata lielas izmaiņas, likvidējot pagātni un uzsākot pāreju uz mūsdienu php.
  Ir ieviestas nosaukumvietas un tiek izmantota noklusējuma rakstzīmju kopa, ja UTF-8; ir pievienots mbstring atbalsts un daudz kas cits.
  Lai iegūtu pilnu izmaiņu sarakstu, dodieties uz Github
• 2015. gada 19. aprīlis
  Izlaista lib versija 3.0.1.
• 2014. gada 15. jūnijs
  Izlaista lib versija 3.0.0.
• 2013. gada 15. decembris
  Projekts pārcēlās uz GitHub

  Tiešsaistes xmlrpc atkļūdotājs

  Demonstrācijas xmlrpc atkļūdotāja lietojumprogramma, kas izveidota uz šīs bibliotēkas, ir aktīva adresē http://gggeek.altervista.org/sw/xmlrpc/debugger/. Jūs varat izmantot atkļūdotāju, lai piem. vaicājiet SF demonstrācijas serveri vai atkļūdojiet savu personīgo xmlrpc serveri, ja tas ir pieejams tīklā.

  Attīstība

  Apraksts	statuss - atjaunināts 2009/07/26
  Atjauniniet dokumentāciju visām funkcijām, kas pievienotas kopš 2. versijas	Lēns progress...
  Pievienojiet iespēju izvēlēties xml ziņojumu formatējumu	Līdzīgi tam, ko dara php vietējais xmlrpc paplašinājums
  Labojiet brīdinājumus, kas tiek izvadīti, darbojoties ar PHP 5 STRICT režīmā	Iespējams, tas jau ir izdarīts 3.0 versijā, atsakoties no php 4 compat...
  Paplašiniet automātisko php funkciju līdz xmlrpc metodes iesaiņojumam, lai izmantotu izņēmumu apstrādi un atgrieztu xmlrpc kļūdu atbildes
  Paplašiniet automātisko stub ģeneratoru, lai automātiski konvertētu php funkcijas uz PHP xmlrpc metodēm<= 5.0.2	skatiet AMPHP kodu, kā to izdarīt. Daudzi uzlabojumi versijā 2.1 Tagad, kad serveris var automātiski reģistrēt php funkcijas, tas vairs nav vajadzīgs...
  Labāks atbalsts mbstring, ja tas ir iespējots	Jātaisa piem. charset encoding uzminēt ātrāk
  Uzlabojiet atbalstu "1. versijas" sīkfailiem
  Pievienojiet iespēju izmantot vietējo kļūdu kodu vietā
  PEAR saderība: pievienojiet sinonīmus funkcijām, kas pastāv ar dažādiem nosaukumiem lib PEAR versijā
  Pievienojiet atbalstu xmlrpc paplašinājumam
  Pievienojiet atkļūdotājam iespēju palaist pilnu validator1 testu komplektu
  Pārbaudiet WSDL lietojamību, lai aprakstītu atklātos pakalpojumus un tulkošanu uz/no system.methodSignature un system.describeMethods	Dažas problēmas pastāv, izmantojot XSD, lai stingri definētu xmlrpc. Relax NG noteikti ir labāka alternatīva, taču citos rīku komplektos ir maz atbalsta, lai to izmantotu kopā ar WSDL failu...
  Atbalsta http novirzīšanu (302)
  Pievienojiet vietnei sf.net nelielu datubāzi, lai mēs varētu ieviest validatora lapu, kas reģistrē ienākošos lietotājus, piemēram, xmlrpc.com vietnē.
  Pievienojiet etalonu komplektam iespēju augšupielādēt rezultātus vietnē sf.net
  Uzrakstiet php paplašinājumu, kas paātrinās visvairāk izmantotās lib funkcijas	Piemēram, skatiet, kā adodb to izdarīja
  Pārbaudiet ātruma/atmiņas pieaugumu, izmantojot simplexml un relaxng, nevis manuālu xml parsēšanu

  drošību

  Trešais drošības pārkāpums: 2005. gada augusts

  Tā bija turpmāka un aktīva reakcija uz otro tālāk norādīto drošības pārkāpumu. Jebkāda eval() izmantošana ir noņemta, jo tā joprojām bija potenciāla izmantošana.

  Kad bibliotēka tika sākotnēji rakstīta, tajā laikā pieejamās php versijas neietvēra call_user_func(), et al. Tāpēc tika rakstīts šo ierobežojumu ietvaros divās no xml parsētāja izsauktajām funkcijām izmantot eval(). Šī lietojuma dēļ servera klase izmantoja arī eval(), jo tai bija jāparsē xml, izmantojot tās pašas funkcijas.

  Šīs apstrādātāja funkcijas un masīvs, kas tiek izmantots sākotnējā ziņojuma satura uzturēšanai, ir pārrakstīts, lai izveidotu php vērtības, nevis veidotu php kodu novērtēšanai. Tam vajadzētu novērst jebkādu koda izpildes iespējamību.

  Otrais drošības pārkāpums: 2005. gada jūlijs

  Drošības ievainojamība, ko 2005. gada 27. jūnijā atklāja Džeimss Bercegejs no GulfTech Security Research, ir izraisījusi diezgan lielu ažiotāžu. Tas ir nokļuvis Salshdot pirmajā lapā, ir minēts Netcraft, LWN un daudzās citās vietnēs.

  Sīki izstrādāti norādījumi par izmantošanas koda izveidi ir publicēti internetā, un daudziem tīmekļa mitināšanas administratoriem rodas jautājums, kāds ir labākais aizsardzības plāns un kādi ir patiesie riski. Šeit ir dažas atbildes.

  Problēmas apjoms

  • Kļūda ietekmē divas bibliotēkas, kas pazīstamas kā PEAR::XMLRPC un PHPXMLRMPC.
    Tas NEIETEKMĒ xmlrpc ieviešanu, kas ir iebūvēta php un iespējota kompilēšanas laikā ar opciju "--with-xmlrpc" (Unix operētājsistēmā Windows parasti tas tiek iespējots/atspējots, mainot atbilstošo rindiņu failā php.ini )
  • kļūda (attālo saimniekdatoru ievadītā php koda izpilde) atrodas tikai failā xmlrpc.inc phpxmlrpc izplatīšanā un RPC.php Bumbieru izplatīšanā
  • gan PEAR::XMLRPC, gan PHPXMLRMPC ir izlaiduši atjauninātas bibliotēkas versijas, kas novērš problēmu
  • abas bibliotēkas ir izmantotas daudzās php lietojumprogrammās (skatiet iepriekš nepilnīgo sarakstu).
    Tā kā visa lib pamatā sastāv no 2 ļoti vienkāršiem failiem, ikviens mēdz tos salabot atbilstoši savai gaumei/vajadzībām un apvienot tos, izplatot savu lietotni.
    Lielākā daļa augsta līmeņa projektu ir bijuši ļoti ātri, izlaižot jaunas attiecīgo lietotņu versijas, taču katram lietotājam būs nepieciešams daudz ilgāks laiks, lai atjauninātu savu sistēmu.
    Jāsaka, ka daudzas lietojumprogrammas vēl nesen tika piegādātas ar ļoti novecojušām phpxmlrpc bibliotēkas versijām; pirmā injekcijas kļūda tika novērsta 2001. gadā nevienam nepamanot (...)

    Tas diemžēl padara sistēmu administratoriem daudz grūtāk atrast vienkāršu problēmas risinājumu: pastāv liela iespēja, ka publiskajos mitināšanas serveros iepriekš minētie faili tiks atrasti daudzos dažādos direktorijos un dažādās versijās.

  Kā tiek aktivizēta ievainojamība

  • Lai izraisītu kļūdu, uzbrucējam ir nepieciešams īpaši izstrādāts xml, kas jānovērtē xmlrpcval objekta izveides procesā. Xmlrpcval objekti tiek izveidoti, kad servera skripts atkodē xmlrpc pieprasījumus vai kad daži php skripti darbojas kā xmlrpc klients un atkodē servera nosūtīto atbildi.
    Servera skripts ir specifisks lietojumprogrammai, un to bieži sauc par server.php (bet ir iespējams jebkurš projekta vai lietotāja izvēlēts variants), un tajā ir jāietver gan faili xmlrpc.inc, gan xmlrpcs.inc (bumbieru versijai serveris .php ir ekvivalents xmlrpcs.inc).
  • Pilnīgi droši ir (afaik...) tikai xmlrpc.inc un xmlrpcs.inc iekļaušana php skriptos, kā arī to izsaukšana tieši caur http pieprasījumiem, jo ​​šajos divos failos tiek veikta tikai funkciju, mainīgo un klašu definēšana, t.i. nav tūlītējas koda izpildes.
  • Faili server.php un diskusija.php, kas tiek izplatīti ar pilnu phpxmlrpc lib, faktiski īsteno reāllaika xmlrpc serveri, tāpēc jūs varētu apsvērt iespēju bloķēt piekļuvi tiem vai vēl labāk tos noņemt, ja atrodat, ka tie ir izvietoti ražošanas serveros (no augšas prātu, es varu uzburt kādu uzbrukumu, iesaistot otru php lietotni, kas cieš no pārņemšanas-php-faila iekļaušanas pārkāpuma, lai tos ievilktu + izmantotu lib zināmo kļūdu)

  Aizsardzības līdzekļi

  • Piešķiriet savam tīmekļa servera procesam pēc iespējas mazāk sistēmas privilēģiju. Operētājsistēmā Unix tas parasti ietver Apache palaišanu kā neviens lietotājs un/vai jailroot/chroot vidē. Tā kā PHP dzinējs darbojas ar vienu un to pašu lietotāju kā tīmekļa serveri, šī ir pirmā aizsardzības līnija: jebkurš uzbrucēja ievadītais php kods darbosies serverī kā vismazāk priviliģēts lietotājs, un viss kaitējums, ko tas varētu nodarīt, tiks ierobežots līdz. izjaucot pašu php lietojumprogrammu
  • palaidiet php drošajā režīmā. Ja esat publisks resursdators un to nedarāt, iespējams, ka jūsu serveris tik un tā ir iesakņojies. Tas neļauj php skriptiem izmantot jebkuru funkciju, kuru uzskatāt par nedrošu, piemēram, system() vai eval()
  • Cietais bloks: atrodiet visus esošos phpxmlrpc failus (xmlrpc.inc un xmlrpcs.inc) un atspējojiet tos (chmod 0) visā sistēmā.
    Tas, protams, var novērst dažu lietotāju lietojumprogrammu darbību, tāpēc jums par to jāinformē lietotāji, kad to darāt.
  • Mīkstais bloks: nomainiet visas esošo phpxmlrpc failu kopijas (xmlrpc.inc un xmlrpcs.inc) ar tām, kas nāk no versijas 1.1.1.
    Diemžēl šī metode nav 100% garantēta, lai visas lietotnes darbotos. Daži lib objektu iekšējie elementi ir mainīti no versijas 0.9 uz 1.0 uz 1.1 (piemēram, xmlrpcresp objektā saglabāto http galvenes attēlojums), un, ja kods, ko esat izvietojis savos serveros, tos iedala apakšklasēs, var rasties problēmas. Pa vadu nosūtītais xml ir mainījies arī attiecībā uz dažām vecākām lib versijām (jo īpaši: versijā 1.0.99.2 nepareizi kodētas rakstzīmes ārpus ASCII diapazona kā html entītijas, turpretim tagad tās tiek kodētas kā xml rakstzīmju kopas entītijas). Ir pievienoti arī daži jauni kļūdu atbildes kodi. To sakot, jums vajadzētu būt par 95% drošiem, palaist šo skriptu, un sēdēt un gaidīt, kamēr lietotāji sāks kliegt, ka kaut kas ir bojāts...
  • PHP PEAR bibliotēku var jaunināt ar vienas rindas komandu, tāpēc tā nav liela problēma:
    bumbieru jauninājums XML_RPC un lai noteiktu, vai tas ir jaunināts (1.3.1 vai jaunāka versija ir labi, jaunākā versija ir 1.3.2):
    pērļu saraksts | grepRPC

  Daži papildu apsvērumi

  Lai nodrošinātu labāku lietotāja pieredzi, arī failam xmlrpcs.inc ir izlabots versijā 1.1.1. Sīkāk: nosūtot serverim īpaši izstrādātu nepareizi veidotu xml failu, php skripts izdos php kļūdu, nevis atgrieztu atbilstošu xml atbildi.
  Pēc dažu domām, tas faktiski ietver "ceļa atklāšanas drošības pārkāpumu" (ti, parādītajā php kļūdas ziņojumā parasti ir ietverta sensitīva informācija par failu sistēmas ceļiem), taču jebkuram atsevišķam PHP skriptam ir tāda pati drošības problēma, ja sistēmas administrators palaiž ražošanas serverus ar ini direktīva display_errors=Ieslēgts.
  Es arī skaidri zinu, ka vietnē xmlrpc.inc ir daudz vietu, kur funkcijas izsaukšana ar neparedzētu parametru radīs php brīdinājumu vai kļūdu, un es neplānoju tuvākajā laikā ieviest stingru parametru pārbaudi katrai funkcijai — ja jūs tiecieties uz to, imho, jūs varētu arī vispirms kodēt Java.

  Vai tas ir pasaules gals?

  ES ceru ka nē.
  Iemesls ir tāds, ka ir desmitiem PHP lietojumprogrammu, kas cieš no koda ievadīšanas. Paskatieties uz ziņojumu dēļu drošības trasi... un tomēr daudzi cilvēki joprojām uzskata, ka PHP ir laba izvēle tīmekļa izstrādei.
  Atcerieties: drošība ir process, nevis stāvoklis, ko var sasniegt.

  Pirmais drošības pārkāpums: 2001. gada septembris

  Es saņēmu šo padomu no Dena Libija. Ar viņa atļauju tas tiek reproducēts šeit. Ņemiet vērā, ka šī izmantošana ir labota PHP XML-RPC versijā 1.01 un jaunākās versijās. -- Edd Dumbill Otr, 2001. gada 24. septembris ============== PHP drošības robs: potenciāls XML-RPC izmantojums =================== ======================== Kopsavilkums: izmantojot Useful Inc jaunāko php xmlrpc bibliotēkas versiju 1.0, uzbrucējs var strukturēt xml tādā veidā, lai piemānītu xml-rpc bibliotēku, lai tā izpildītu php kodu tīmekļa serverī. Es varēju izpildīt patvaļīgu php kodu un ar izslēgtu php drošo režīmu sistēmas komandas. Uzbrucējs to var viegli izmantot kā vārteju vīrusu palaišanai. Sīkāka informācija: Es parādīju problēmu, modificējot server.php piemēra skriptu, kas iekļauts xmlrpc izplatīšanā, un pēc tam izsaucot to, izmantojot skriptu client.php, kas arī ir daļa no izplatīšanas. Es apietu standarta servera kodu un vienkārši atbalsoju atbildes klientam. Man izdevās panākt, lai klients izpildītu patvaļīgu php kodu. Pēc tam es atjaunoju server.php paraugu tā sākotnējā stāvoklī un izmantoju Telnet, lai nosūtītu modificētu pieprasījums. Es arī varēju panākt, lai kods tiktu izpildīts serverī, lai gan tam bija nepieciešama nedaudz atšķirīga sintakse. Uzbrukuma centrā tiek izmantota php eval() funkcija. Tā kā es zināju, ka xml-rpc bibliotēka izmanto eval, lai izveidotu savas datu struktūras no xml ievades, bija tikai jāstrukturē ievades xml tā, lai tas: a) netiktu izspiests, pirms tiek nodots eval. b) neģenerēt php sintakses kļūdu Parasti visus datus, kas nav skaitļi, bibliotēka izņem pirms to nodošanas eval. Taču izrādās, ja nosūtīsi a tagu, kam seko neparedzēta atzīme, piemēram, , atsoļa kods tiks apiets un tā vietā tiks novērtēti neapstrādāti dati. Klienta izmantošana: šeit ir tipiska xml-rpc atbilde: Sveika pasaule Kad šāda atbilde tiek novērtēta, tā izskatās šādi: new xmlrpcval("sveiki pasaule", "string") Šeit ir xml-rpc atbilde, kas izpildīs php kodu, lai atbalsotu "

  Sveika pasaule

  klienta pusē: ", "virkne"); atbalss "

  Sveika pasaule

  "; \$atkritumi = masīvs(" Šajā gadījumā virkne, kas tiks novērtēta, ir: new xmlrpcval("", "string"); echo "

  Sveika pasaule

  "; $waste = array("", "string") Ir iespējams aizstāt visu starp "string"); un \$waste ar patvaļīgu gandrīz jebkura garuma kodu. Visbeidzot, šeit ir tas, kas izdrukās saturu pašreizējā direktorijā: ", "virkne"); atbalss "
  "; echo `ls -al'; atbalss "
  
  "; iziet; \$atkritumi = array(" Servera izmantošana: servera izmantošana ir gandrīz tāda pati kā klientam, izņemot to, ka serveris izmanto citu eval komandu, un tāpēc tai ir nepieciešama nedaudz atšķirīga sākuma un beigu sintakse, lai izvairītos no php sintakses kļūdām. Šeit ir tāds pats kods kā iepriekš, taču tas darbosies pret serveri. system.listMethods ", "virkne")); atbalss "

  ja redzat direktoriju sarakstu, es tikko izpildīju php un sistēmas kodu, izmantojot xml-rpc.

  "; echo "tagad es mēģināšu izveidot direktoriju sarakstu, izmantojot ls -al:\n "; echo `ls -al'; atbalss ""; echo "Es varētu vienkārši izsaukt rm -rf vai ierakstīt programmu diskā un izpildīt to (piemēram, vīrusu) vai izlasīt dažus failus. Jauku dienu.
  
  "; iziet; $atkritumi = array(masīvs(" Problēmas apgabals: vietnē xmlrpc.inc ir funkcija xmlrpc_cd(), kuru izsauc xml parsētājs, lai apstrādātu rakstzīmju datus. funkcija xmlrpc_cd($parser, $data) (globāls $_xh, $xmlrpc_backslash, $xmlrpc_twoslash; //if (ereg("^[\n\r \t]+$", $data)) return; // print " pievienojot [$(data)]\n"; if ($_xh[$parser]["lv"]==1) ( $_xh[$parser]["qt"]=1; $_xh[$parser][ "lv"]=2; ) if ($_xh[$parser]["qt"]) ( // citāta virkne $_xh[$parser]["ac"].=str_replace("\$", "\\" $", str_replace(""", "\"", str_replace(chr(92),$xmlrpc_backslash, $data))); ) else $_xh[$parser]["ac"].=$data; ) It ir pēdējais, kas izraisa datu pievienošanu bez aizbēgšanas. Tas ir ļoti bīstami. Šķiet, ka šis cits ir paredzēts skaitliskiem datiem, un ir pieliktas lielas pūles, lai iestatītu un atiestatītu "qt" (pēdiņas) mainīgo, kas ieslēdz un izslēdz aizbēgšanu. Tomēr man nav uzreiz skaidrs, kāpēc skaitliskos datus nevajadzētu līdzīgi izspiest un noņemt if/else, lai šāda veida izmantošanas iespējamība būtu nulle.

No sestdienas pēcpusdienas manā serverī, kurā ir aptuveni 25 vietnes Wordpress, sākās mežonīgas bremzes. Tā kā iepriekšējos uzbrukumus (1. uzbrukums - tieši pirms gada, 2. uzbrukums - martā) izdevās pārdzīvot nemanot, tad uzreiz nesapratu, kas notiek.

Kad es to izdomāju, izrādījās, ka ir meklētas paroles + daudz pieprasījumu uz XMLRPC.

Rezultātā to visu bija iespējams nogriezt, lai gan ne uzreiz. Ir trīs vienkārši triki, kā no tā izvairīties.

Šos paņēmienus, visticamāk, zina visi, bet es uzkāpu uz pāris grābekļiem, kurus aprakstos neatradu - pēkšņi tas kādam ietaupīs laiku.

1. Pārtraucam uzskaitīšanu, Limit Login Attempts spraudni - mēs precīzi formulējam, jo ​​citas aizsardzības stipri apkarina serveri, piemēram, izmantojot Login Security Solution spraudni, serveris nomira pēc pusstundas, spraudnis ļoti noslogo datu bāze.

Iestatījumos noteikti atzīmējiet izvēles rūtiņu "Par starpniekserveri" - pretējā gadījumā tas visiem noteiks jūsu servera IP un automātiski bloķēs visus.
ATJAUNINĀT, pateicoties DarkByte, sīkāka informācija ir atrodama zemāk komentāros - atzīmējiet izvēles rūtiņu "Starpniekserveram" tikai tad, ja definīcija nedarbojas, kad ir iespējots "Tiešais savienojums".

2. Atspējot XML-RPC - spraudnis Atspējot XML-RPC (tikai aktivizējiet to un viss).

3. Aizveriet wp-login.php — ja piekļūstat vietnei, izmantojot IP, spraudnis nedarbojas un atlasītāji turpina āmurēt vietni. Lai no tā izvairītos, pievienojiet failam .htaccess:

Pasūtiet Noliegt, Atļaut aizliegt no visiem

Mēs nokopējam wp-login failu, pārdēvējam to par jebkuru dīvainu nosaukumu, piemēram, poletnormalny.php un faila iekšpusē ar automātisko labošanu mainām visus wp-login.php uzrakstus uz poletnormalny.php.
Viss, tagad jūs varat piekļūt administratora panelim tikai ar savu failu.

Pēc šīm 3 vienkāršajām darbībām vietnes atkal sāka lidot un iestājās miers.

Nu pēkšņi ir interesanti

Viena no iespējām ir, kā redzēt, ka jums uzbrūk. To var redzēt nginx žurnālos (piemēram, šeit ir Debian /var/log/nginx access.log faila ceļš).

Pirms dažām dienām es pamanīju, ka manu vietņu slodze uz hostingu ir ievērojami palielinājusies. Ja parasti tas bija 100-120 "papagaiļu" (KP) apvidū, tad pēdējās dienās tas pieaudzis līdz 400-500 KP. Šeit nav nekā laba, jo hoster var pāriet uz dārgāku tarifu vai pat vispār bloķēt piekļuvi vietnēm, tāpēc es sāku to izdomāt.

Bet esmu izvēlējies metodi, kas saglabās XML-RPC funkcionalitāti: spraudņa Disable XML-RPC Pingback instalēšana. Tas noņem tikai "bīstamās" metodes pingback.ping un pingback.extensions.getPingbacks, atstājot XML-RPC funkcionalitāti. Pēc instalēšanas spraudnis ir tikai jāaktivizē — nav nepieciešama papildu konfigurēšana.

Pa ceļam es savās vietnēs .htaccess failā atzīmēju visus uzbrucēju IP, lai bloķētu viņu piekļuvi. Es tikko pievienoju faila beigām:

Pasūtiet Atļaut, Aizliegt Atļaut no visiem Aizliegt no 5.196.5.116 37.59.120.214 92.222.35.159

Tas arī viss, tagad esam droši pasargājuši emuāru no turpmākiem uzbrukumiem, izmantojot xmlrpc.php. Mūsu vietnes ir pārtraukušas ielādēt mitināšanas pieprasījumus, kā arī uzbrukt trešo pušu vietnēm, izmantojot DDoS.

XML-RPC tehnoloģija tiek izmantota WordPress sistēmā, lai nodrošinātu dažādas jaukas funkcijas, piemēram, pingbacks, trackbacks, attāla vietņu pārvaldība bez pieteikšanās administratora apgabalā utt. Diemžēl uzbrucēji to var izmantot, lai veiktu DDoS uzbrukumus vietnēm. Tas ir, jūs veidojat skaistus interesantus WP projektus sev vai pēc pasūtījuma, un tajā pašā laikā, neko nenojaušot, varat būt daļa no DDoS robottīkla. Savienojot kopā desmitiem un simtiem tūkstošu vietņu, slikti cilvēki rada spēcīgu uzbrukumu savam upurim. Lai gan arī jūsu vietne cieš, jo. slodze nonāk hostingā, kur tā tiek mitināta.

Pierādījums par šādu sliktu darbību var būt servera žurnāli (access.log in nginx), kas satur šādas rindas:

103.238.80.27 - "POST /wp-login.php HTTP/1.0" 200 5791 "-" "-"

Bet atpakaļ pie XML-RPC ievainojamības. Vizuāli tas izpaužas kā lēna vietņu atvēršana jūsu serverī vai nespēja tās vispār ielādēt (502 Bad Gateway kļūda). Mana FASTVPS mitinātāja tehniskais atbalsts apstiprināja manus minējumus un ieteica:

1. Atjauniniet WordPress uz jaunāko versiju kopā ar spraudņiem. Kopumā, ja sekojat, iespējams, esat lasījis par nepieciešamību instalēt jaunāko 4.2.3. drošības kritikas dēļ (tāpat kā iepriekšējās versijās). Īsāk sakot, atjaunināšana ir laba.

1. Instalējiet spraudni Disable XML-RPC Pingback.

XML-RPC atspējošana programmā WordPress

Man šķiet, ka iepriekš iespēja iespējot / atspējot XML-RPC bija kaut kur sistēmas iestatījumos, bet tagad es to nevaru atrast. Tāpēc vienkāršākais veids, kā no tā atbrīvoties, ir izmantot atbilstošo spraudni.

Atrodiet un lejupielādējiet Disable XML-RPC Pingback vai instalējot to tieši no sistēmas administratora paneļa. Papildus nekas nav jākonfigurē, modulis sāk darboties uzreiz. Tas noņem XML-RPC saskarnes metodes pingback.ping un pingback.extensions.getPingbacks. Noņem arī X-Pingback no HTTP galvenēm.

Vienā no emuāriem es atradu vēl dažas iespējas, kā noņemt XML-RPC atspējošanu.

1. Veidnē atspējojiet XML-RPC.

Lai to izdarītu, tēmas failam functions.php tiek pievienota rinda:

Pasūtiet Noliegt, Atļaut aizliegt no visiem

Es personīgi neizmantoju pēdējās divas metodes, jo. Pieslēdzu Disable XML-RPC Pingback spraudni - domāju, ka pietiks. Tikai tiem, kam nepatīk papildu iestatījumi, es piedāvāju alternatīvas iespējas.