Vbuletin de neegalat. Observații vBulletin sau încercări de a stoca în cache conținutul dinamic. Continuarea este disponibilă numai pentru membri
Probabil ați văzut forumuri pe motorul vBulletin de multe ori. Forumurile ca atare nu mai sunt la modă, dar vBulletin este încă unul dintre cele mai populare motoare. În cea mai recentă versiune (a cincea) sa, au fost găsite mai multe vulnerabilități care pot distruge foarte mult viața unui administrator. În acest articol vă voi spune cum sunt folosite.
Prima problemă este filtrarea incorectă a datelor utilizatorului. A fost raportat de un cercetător independent de securitate care a dorit să rămână anonim. Vulnerabilitatea, deși are unele limitări, a primit o stare critică, deoarece vă permite să citiți orice fișiere și să executați cod arbitrar pe sistemul țintă.
A doua vulnerabilitate a fost găsită de cercetătorii de la TRUEL IT și a primit identificatorul CVE-2017-17672. Este legat de caracteristicile deserializării datelor din motor și poate fi folosit de un atacator pentru a șterge fișiere arbitrare din sistem.
Rapoartele complete care detaliază ambele probleme au fost publicate ca parte a programului Beyond Security al SecuriTeam. Există, de asemenea, exploatări PoC pentru a demonstra vulnerabilitățile. Să trecem prin toate acestea în ordine.
Pregătiri
Am folosit distribuția WAMP ca server.
Citiți fișiere, executați comenzi
Deci, motivul primei vulnerabilități este logica incorectă la procesarea parametrului routestring, care permite unui atacator să includă orice fișier de pe disc prin includere și să execute codul PHP care se află în acesta.
Calea noastră începe cu cel mai important fișier - index.php, unde are loc inițializarea de bază a aplicației.
/index.php
48: $app = vB5_Frontend_Application::init("config.php"); ... 60: $routing = $app->getRouter(); 61: $metoda = $routing->getAction(); 62: $template = $routing->getTemplate(); 63: $clasa = $routing->getControllerClass();Să ne uităm la metoda vB5_Frontend_Application::init.
/includes/vb5/frontend/application.php
13: clasa vB5_Frontend_Application extinde vB5_ApplicationAbstract 14: ( 15: funcția publică statică init($configFile) 16: ( 17: parent::init($configFile); 18: 19: self::$instance = new vB5_Frontend:_20); self::$instance->router = new vB5_Frontend_Routing( 21: self::$instance->router->setRoutes();Aici ne interesează metoda setRoutes.
47: funcția publică setRoutes() 48: ( 49: $this->processQueryString(); ... 54: if (isset($_GET["routestring"])) 55: ( 56: $cale = $_GET[" rută șirul"];Variabila $path conține valoarea userdata din parametrul routestring. Puteți trece calea către pagina de forum în ea și va fi încărcată.
Să presupunem că am trecut /test .
După atribuirea unei variabile, există o bucată de cod care scapă de bara oblică de la începutul liniei, dacă este prezentă.
/includes/vb5/frontend/routing.php
75: if (strlen($cale) ȘI $cale(0) == "/") 76: ( 77: $cale = substr($cale, 1); // $cale = "test" 78: )include\vb5\frontend\routing.php
83: dacă (strlen($cale) > 2) 84: ( 85: $ext = strtolower(substr($cale, -4)) ; 86: dacă (($ext == ".gif") SAU ($ext == ".png") SAU ($ext == ".jpg") SAU ($ext == ".css") 87: SAU (strtolower(substr($cale, -3)) == ".js" )) 88: ( 89: antet ("HTTP/1.0 404 Nu a fost găsit"); 90: die(""); 91: ) 92: )După cum puteți vedea, verificarea este destul de ciudată. Cel puțin, prezența unei liste de extensii interzise scrise direct în cod este confuză. Și, în general, însuși faptul că extensia se obține prin tăierea a patru caractere de la sfârșitul rândului (linia 85) este derutant. În general, dacă încercăm să primim un fișier cu extensii gif, png, jsp, css sau js, serverul va returna o pagină 404 și scriptul se va opri din executare. Când toate verificările sunt trecute, metoda getRoute din clasa vB_Api_Route este apelată folosind callApi. Acesta caută rute potrivite pe baza informațiilor furnizate de utilizator.
Continuarea este disponibilă numai pentru membri
Opțiunea 1. Alăturați-vă comunității „site” pentru a citi toate materialele de pe site
Calitatea de membru al comunității în perioada specificată vă va oferi acces la TOATE materialele Hacker, vă va crește reducerea cumulativă personală și vă va permite să acumulați un rating profesional Xakep Score!
Dacă conduceți propriul forum, mai devreme sau mai târziu trebuie să vă gândiți să vă protejați forumul - la urma urmei, atacatorii nu dorm! În acest subiect, eu (cu ajutorul Habrowser ReaM) am întocmit o listă de sfaturi pentru creșterea securității forumului dvs. Interesat? Bun venit la hack :)
Deci, să începem:
1) Să actualizăm până la sfârșitul liniei noastre (3.5.x, 3.6.x, 3.7.x)
Descriere: Fara comentarii
De ce?: Jelsoft închide în mod constant vulnerabilitățile emergente. Nimeni nu vrea să lucreze la forumul de anul trecut, nu?
2) Redenumiți panourile de administrare și moderare
Descriere: Redenumim panoul de administrare, dar în configurație nu scriem în niciun caz calea către panoul de administrare redenumit. Redenumim și modulul, dar acesta poate fi deja înregistrat în configurație (deși este și indezirabil), deoarece este mai puțin vulnerabil. Convinge-te singur :)De ce?: Dacă redenumiți panoul de administrare și nu specificați calea în configurație, va fi mult mai dificil să îl găsiți și deci să aplicați XSS sau chiar mai rău. Există dezavantaje: - editarea unui profil și adăugarea moderatorilor nu va mai funcționa fără a edita manual link-urile.
3) Plasați .htaccess pe panoul de administrare:
Descriere:
a) dacă ip-ul este static, atunci
ordona permite, refuza
nega de la toti
permite de la %your_IP%
B) Am setat și o parolă suplimentară:
De ce?: Protecția suplimentară cu parolă pentru panoul de administrare nu strică niciodată.
4) Ștergeți fișierele și folderele:
Descriere:
a) Ștergeți fișierele:
/validator.php (dacă este disponibil)
/checksum.md5 (dacă este disponibil)
b) Ștergeți folderele:
/instalare/
De ce?: Fișierele nesigure din versiunile zero pot face posibilă vizualizarea listei de fișiere, iar folderul de instalare este foarte dăunător =)
5) Mutați atașamentele și avatarele
B) Avatare -> Tip de stocare a imaginii utilizatorului
Avatarurile trebuie să fie stocate într-o bază de date
De ce?: Linia 3.5, dacă memoria îmi servește corect, a oferit legături directe către imagini - care, dacă configurația de găzduire era incorectă, dădeau șansa de a inunda shell-ul.
6) Setați permisiunile pentru foldere
Descriere: Dacă pasul 5 a fost finalizat, acum putem seta în siguranță drepturile pentru folderele personalizate_* la 644, deoarece nu avem nevoie de ele acum (sau le puteți șterge). Apoi, dacă ați instalat vBulletin conform instrucțiunilor, toate folderele din / (rădăcină) ar trebui să aibă 644 de permisiuni, dacă nu, atunci setați permisiunile la 644.
De ce?: Facem dificil pentru un hacker să umple carcasa.
7) Niciodată, niciodată, pentru nimeni, nu activăm opțiunea „Permite html”.
Descriere: Fara comentarii. De ce are cineva nevoie de HTML?
De ce?: Posibilitatea atacurilor XSS atunci când funcția este activată.
8) Plasați .htaccess în folderul includes
Descriere: Am pus .htaccess în folderul includes cu următorul conținut:
Comanda permite, refuza
nega de la toti
De ce?:
- dacă un obuz este cumva inundat acolo, ei nu vor putea accesa el.
- dacă sunteți ddosed, atunci este posibil ca interpretul php să cadă și să rămână doar Apache - și Apache vă permite deja să citiți fișiere php - prin urmare va fi posibil să citiți toate fișierele din folderul /includes/ - aceeași config. .php, ceea ce nu este foarte bun.
9) Împingeți următorul .htaccess în directorul cu fișiere care au atribute 0777:
kerk _http://vbsupport.org/forum/member.php?u=30
Descriere:
RemoveHandler.phtml
RemoveHandler.php
RemoveHandler.php3
RemoveHandler.php4
RemoveHandler.php5
RemoveHandler.cgi
RemoveHandler.exe
RemoveHandler.pl
RemoveHandler.asp
RemoveHandler.aspx
RemoveHandler.shtml
Comanda permite, refuza
Negați de la toți
De ce?: Scripturile cu extensiile specificate nu mai pot fi folosite într-un director cu acest htaccess.
10) Editați config.php, introduceți id-ul administratorilor în câmpul utilizator care nu poate fi șters.
Descriere:/includes/config.php. Doar introduceți id-ul administratorilor după ce ați făcut toate modificările necesare profilului.
De ce?: Nu este nevoie ca nimeni să schimbe din nou profilurile de administrator, nici măcar pentru sine. Dacă aveți nevoie, ei vor șterge ID-ul din fișier, îl vor schimba și îl vor returna înapoi. Siguranța este pe primul loc! :)
11) După ce eliminați modurile/hack-urile, nu uitați să ștergeți fișierele pe care le-ați descărcat împreună cu acestea.
Descriere: Fara comentarii
De ce?: De ce aveți nevoie de fișiere suplimentare pe server? Nu este nevoie...
12) Nu salvați niciodată copii de rezervă la îndemâna serverului web.
Descriere: Fără comentarii
De ce?: Acestea vor fi disponibile pentru descărcare pentru oricine recunoaște numele copiei de rezervă. Desigur, puteți adăuga htaccess, dar totuși, de dragul securității, faceți copii de rezervă dincolo de accesul serverului web.
13) Instalați pluginul „File Inspector”.
Autor - Ghost (http://www.vbsupport.org/forum/member.php?u=38422)
Descriere (citat):
În timp ce parcurgeam vechile mele scripturi, am dat peste acest produs - File Inspector. Acestea sunt câteva module pentru vBulletin, cu ajutorul cărora puteți salva o listă a fișierelor existente în baza de date și puteți verifica din când în când dacă vreunul dintre ele s-a schimbat (dimensiunea, proprietarul și drepturile de acces sunt salvate pentru fiecare fișier) - sistemul încorporat sarcina cron va notifica administratorul prin e-mail despre inconsecvențele găsite. Puteți salva mai multe copii (reviziuni) diferite ale listelor de fișiere în baza de date pentru comparare (verificarea automată cu notificare prin e-mail este verificată numai cu cea mai recentă revizuire). Aspectul și setările disponibile pot fi văzute în capturi de ecran.INSTALARE: Pentru a instala, trebuie să încărcați două fișiere PHP din arhivă pe server și să importați produsul din fișierul „product-gfi.xml”.
ACTUALIZARE: Actualizarea versiunii nu este furnizată, așa că pentru a instala una nouă, este recomandat să dezinstalați mai întâi versiunea anterioară.
ZY Produsul a funcționat cu succes pe toate versiunile de la 3.6.8 la 3.8.1 inclusiv. Adevărat, un link către meniul drop-down din bara de navigare a fost adăugat în diferite locuri, dar acestea sunt lucruri minore.
Descărcați de pe vbsupport.org
De ce?: Un lucru indispensabil în căutarea de shell-uri pe un site web, dar trebuie instalat în prealabil.
Rezultat:
Este destul de dificil să obțineți acces la panoul de administrare, așa că puteți încărca și un shell prin panoul de administrare. Puteți încărca un shell prin vulnerabilități vB, dar dacă îl încărcați în /includes (pentru unele hack-uri există fișiere care necesită 777), atunci în folderul nostru includes avem deny from all - shell-ul pur și simplu nu va fi accesibil din exterior !
Puteți seta permisiuni la 644 pentru folderele rămase, dacă ați parcurs toți pașii - atunci va fi destul de dificil de încărcat, mai ales dacă chroot-ul este configurat corect. Și, în cele din urmă, am adăugat protecție față de administratorii înșiși, care se furișează, expunându-se astfel la XSS și troieni.
De fapt, asta-i tot... Acesta este primul meu subiect despre Habré, așa că te rog nu da prea tare :)
UPD: Mutat la „Securitatea informațiilor”.
Selectați motorul forumului. IPB, vBulletin, Phpbb
Un motor de forum este un lucru necesar pentru un site serios. Principiul este bine cunoscut: orice site ar trebui să fie interactiv. Există multe modalități de a obține interactivitate, de la comentarii la articole până la propria rețea socială tematică. Forumul este poate cel mai universal instrument pentru feedback real din partea vizitatorilor.
Forumul vă permite să:
Creați o audiență permanentă de utilizatori ai site-ului care vor reveni constant și vor fi activi. Activitatea vizitatorilor este bani reali.
Economisirea conținutului. Dacă creați un forum, atunci conținutul va fi creat de utilizatori, iar proprietarul nu trebuie să cumpere cantități mari de texte pentru promovare.
Extinderea nucleului semantic al site-ului. Crearea unui forum permite, fără prea mult efort din partea proprietarului, extinderea numărului de solicitări pentru care site-ul este promovat.
Instalarea motorului de forum este un proces simplu, dar configurarea și administrarea ulterioară pot cauza o mulțime de dificultăți pentru un începător. Cu toate acestea, există o cantitate imensă de documentație pentru fiecare motor popular, așa că, dacă doriți, puteți înțelege totul. Sau angajează un administrator profesionist.
În general, marea majoritate a motoarelor sunt destul de potrivite pentru funcționarea normală a forumului, au aproximativ același set de funcții de bază, inclusiv un sistem flexibil pentru setarea drepturilor de acces pentru utilizatori. Acestea diferă prin ușurința de administrare, un set de șabloane și pluginuri, fiabilitate și suport tehnic de la producător. Voi începe recenzia cu primele trei din Runet: Phpbb este poate cel mai popular motor pentru crearea unui forum pe Runet. Pentru un începător, principalul avantaj al Phpbb este că atât motorul de forum în sine, cât și tot felul de suplimente sunt gratuite. Există, de asemenea, multe comunități diferite de fani Phpbb, atât pe internetul vorbitor de limbă rusă, cât și pe cel străin.
Alte avantaje includ viteza de operare, simplitatea și flexibilitatea relativă a setărilor, un număr mare de șabloane și suplimente. Dacă faci un forum în phpbb, atunci acesta poate fi folosit ca parte a site-ului (există posibilitatea integrării cu multe cms), dar poți să faci și un site portal mai mult sau mai puțin cu drepturi depline pe baza lui.
Dar există și un dezavantaj al Phpbb - este foarte vulnerabil atât la atacurile de spam, cât și la hacking odată cu introducerea codului cuiva. Pentru a evita acest lucru, trebuie să instalați suplimente speciale pentru a vă proteja împotriva spamului și, de asemenea, să actualizați în mod regulat motorul instalând versiuni noi. Din păcate, acest lucru nu oferă întotdeauna protecție 100%, așa că va trebui să monitorizați acest lucru manual singur sau prin numirea moderatorilor. Îl puteți descărca de pe site-ul oficial https://www.phpbb.com/
IPB (Invision Power Board) este un motor de forum plătit, care sperie imediat majoritatea începătorilor. Cu toate acestea, dacă proiectul se dorește a fi serios, atunci este puțin probabil ca o sumă de aproximativ 200 USD pentru un IPB să oprească un webmaster hotărât. Dar gândiți-vă de zece ori dacă sunteți pregătit, chiar și de dragul unei game foarte largi de posibilități, să refaceți constant motorul IPB pentru dvs., cu riscul de a vă complica suportul și actualizările.
Sistemul are un număr imens de posibilități de integrare cu diferite servicii - diverse cm-uri, bloguri, chat-uri, galerii foto etc. Poate că un portal pe acest motor poate fi considerat un site complet cu drepturi depline, desigur, cu anumite setări.
Și aici există o muscă semnificativă în unguent - motorul IPB este actualizat destul de rar, utilizatorii înșiși acționează ca testeri, care găsesc ei înșiși vulnerabilități și erori. În orice caz, codul ajunge să fie „strâmb” și suboptim. Nu există comunități de fani ruși de înaltă calitate, toate problemele vor trebui rezolvate independent. Localizările în limba rusă sunt, de asemenea, departe de a fi perfecte;
Datorită complexității și incorecității codului, forumurile de pe IPB sunt afișate corect numai în FireFox în alte browsere pot apărea probleme minore;
De asemenea, poate exista o problemă la actualizarea de la a doua la a treia versiune - structura skin-urilor și a claselor s-a schimbat, iar dacă forumul a fost modificat, actualizarea va fi problematică.
Sistemul de șabloane IPB este extrem de confuz, schimbarea aspectului nu este atât de ușoară, va trebui să „împingeți” o mulțime de fișiere. Designul standard nu este rău și destul de familiar - dar este standard, ceea ce, în sine, poate fi un dezavantaj semnificativ pentru mulți. Puteți descărca Invision Power Board de pe site-ul oficial http://www.invisionpower.com/apps/board/ 
vBuletin (vb). În segmentul de limbă rusă a internetului, vBulletin este denumit în mod tradițional „vobla” sau „chic”. Acesta este poate cel mai bun motor de forum, nu mai este nimic de adăugat. Prețul de aproximativ 250 USD (licența este achiziționată pentru un an și include actualizări gratuite în acest timp) este destul de justificat și cu siguranță se va plăti de la sine economisind timp și nervi. Aici totul funcționează ca un ceas. Este destul de clar de ce se iau banii - motorul vBulletin este îmbunătățit constant și este clar că la el lucrează programatori profesioniști și nu doar fanii.
Nu are rost să enumerați toate funcțiile - acesta (sau suplimentele) implementează aproape tot ceea ce ar putea avea nevoie un administrator pentru a crea un forum. Există multi-citare, suport pentru podcasting, comunități de utilizatori, grupuri sociale, un sistem flexibil de reputație și multe altele.
Desigur, vBulletin are un număr mare de suplimente și comunități de utilizatori, așa că nu vor fi probleme de întreținere, mai ales că există o echipă oficială de asistență. Dezavantajul vBulletin, deși nu foarte mare, îl reprezintă completările plătite, de exemplu, pentru blogurile utilizatorilor.
În general, forumul nu are defecte. Poate fi recomandat pentru proiecte mari serioase tocmai datorita fiabilitatii si rezistentei la tot felul de atacuri. Ca urmare, creează o încărcare semnificativă pe server, mai ales cu suplimente instalate, dar pentru proiecte serioase folosesc de obicei servere serioase și administratori serioși. Îl puteți descărca de pe site-ul oficial http://www.vbulletin.com/
SMF (Simple Machines Forum). Un motor simplu pe care îl poate gestiona orice începător. Simplitatea este compensată de lipsa de funcționalitate, dar nu toată lumea are nevoie de un set complet de caracteristici. Instalarea pluginurilor (mod-urilor) este organizată convenabil în motor, acestea pot fi descărcate și instalate direct din panoul de administrare în doar câteva clicuri.
Panoul administrativ este oarecum neobișnuit, dar pentru un începător acest lucru nu este un dezavantaj, deoarece nu are experiență sau obiceiuri cu alte motoare. Nefamiliaritatea nu înseamnă inconvenient. Un alt avantaj este prezența unui număr mare de convertoare pentru comutarea de la alte motoare.
Forumul este foarte de încredere în ceea ce privește hacking-ul, iar spam-ul... ei bine, spam-ul este o problemă eternă care are nevoie și poate fi combatetă. În ciuda faptului că SMF este gratuit, dezvoltatorii și utilizatorii experimentați oferă asistență tuturor celor care au nevoie pe forumul oficial al proiectului.
Pe baza acestui motor, puteți crea și site-uri web cu drepturi depline, folosind suplimente speciale pentru portaluri (Adk Portal, EzPortal etc.) Cu toate acestea, marea întrebare este dacă merită să faceți un portal bazat pe un forum. Este mai logic să faci un forum ca o completare la site-ul principal pe un motor cu drepturi depline.
Intellect Board (IntBoard). Un motor de forum pentru fani, scris de un fan și abandonat cu succes de acesta. Cu toate acestea, abandonul nu este un motiv pentru a nu-l recomanda categoric.
Să vorbim imediat despre deficiențe. Problemele apar adesea din senin, suportul lipsește ca clasă, forumul oficial este practic mort, iar proprietarii forumurilor de pe acest motor răspund rareori acolo. Practic nu există suplimente sau șabloane - trebuie să faci totul singur.
Dar există și avantaje. Codul motorului este suficient de simplu încât chiar și un începător poate să-și dea seama și să remedieze singur unele probleme, precum și să ajusteze unele funcții pentru el însuși. Motorul este foarte ușor și creează puțină sarcină pe server. Panoul de administrare este extrem de nestandard, dar are, poate, cea mai bună oportunitate de a configura drepturi pentru utilizatori; un sistem de grupuri și drepturi de acces la fiecare secțiune specifică vă va permite să creați un sistem de moderare puternic și eficient.
PunBB. Un motor simplu, ușor, cu o comunitate destul de puternică, care va ajuta la rezolvarea problemelor care apar. Nesolicitant pentru resursele serverului. Panoul administrativ este intuitiv.
Aspectul este realizat folosind CSS, astfel încât începătorii care sunt obișnuiți cu aspectul tabelului vor găsi că este neobișnuit să editeze șabloane. Cu toate acestea, acesta este și un plus - este timpul să stăpânim tehnologiile moderne.
Un dezavantaj serios este disponibilitatea ridicată pentru spam - trebuie să monitorizați acest lucru manual, pe lângă pluginurile instalate.
ExBB este un motor gratuit, a cărui particularitate este că funcționează cu baze de date text fără a utiliza MySQL. Poate acum 10 ani, acesta era un avantaj - astfel de site-uri creau mai puțină încărcare, iar găzduirea cu suport pentru baze de date era mult mai costisitoare. În prezent, orice găzduire acceptă MySQL, iar bazele de date text reprezintă un dezavantaj; sunt mult mai lente și mai puțin fiabile.
Cu toate acestea, puteți crea un forum folosind acest cms pentru un site mic unde nu este așteptat un aflux mare de vizitatori și mesaje. Este ușor de instalat, ușor de întreținut și are un număr mare de utilizatori și un forum de asistență pe site-ul oficial.
Vanilla – acest motor puțin cunoscut este poziționat ca un plus la Wordpress, unul dintre cele mai populare cms. Printre caracteristicile standard ale WordPress nu există nicio posibilitate de a crea un forum. Desigur, puteți adapta orice motor de forum, dar nu este atât de ușor. Vanilla este instalat ca un plugin obișnuit.
Sistemul de mesaje personale este implementat într-un mod neobișnuit - sunt publicate ca subiecte obișnuite, dar sunt vizibile doar pentru cei cărora le sunt adresate. În orice subiect, pe lângă cel public, puteți lăsa un mesaj personal. Neobișnuit, dar destul de convenabil. În general, se pare că dezvoltatorii au decis să facă un forum spre deosebire de toate celelalte. Dacă acesta este un plus sau un minus, depinde de tine să decizi.
În general, există o mulțime de motoare - puteți încerca, vă puteți stabili imediat cu ceva popular, puteți chiar să scrieți sau să comandați ceva propriu. Este imposibil să spunem fără ambiguitate care opțiune va fi optimă pentru fiecare caz specific.
Administrarea unor astfel de servicii de obicei nu este responsabilă pentru nimic, așa că dacă forumul tău dispare într-un moment minunat, în cel mai bun caz își vor cere scuze.
În următorul articol vă voi spune ce există
Mă ocup de mai multe VPS-uri pe care se învârt... în general nu zona mea de responsabilitate și, prin urmare, ceea ce se învârte acolo se învârte, încetinește moderat, funcționează moderat. Și s-a dovedit că un anumit forum rula pe unul dintre ele, iar forumul a început să încetinească. Și am vrut să-mi dau seama...
Sursă
- Forum pentru vBulletin 3.8.x
- Mutat în subdomeniul forum.domain.com
- Nginx 1.1.13, php 5.3.x (fpm)
- În afară de forum, nu rulează nimic pe acest server. ( este important).
- Mysql pe un server separat, comunicare prin TCP/IP.
fundal
Am locuit pe forum, nu m-am deranjat, am arătat xm de sus sarcina este în jur de 30-40 la sută. Și apoi a venit ora „X” și încărcătura a sărit pe un platou plat de 90 la sută cu vârfuri mai mari, ceea ce, în general, nu este un zumzet. Suspiciunea de DDOS nu a fost confirmată. Jurnalele au arătat o sarcină normală de lucru. Ei bine, înainte de a crește prostește resursele, a apărut ideea de a înțelege ce se întâmplă și de a încerca să punem în cache tot ce era posibil.Ancheta. Prima parte - ce își dorește o femeie vizitatoare?
Deoarece nu eram familiarizat cu ideologia și caracteristicile acestui software, am început să studiez problema analizând jurnalele și traficul dintre vizitatori și server. În primul rând, am fost surprins să descopăr că atașamentele la mesajele din forum sunt date exclusiv de script atașament.php, în timp ce fișierele în sine pot fi stocate în baza de date sau pe un disc local, dar returnarea se face doar printr-un script. Si nimic altceva. Adică, obținem 8-10 zvâcniri suplimentare ale interpretului PHP per fir de mesaj cu 8-10 fotografii. Și asta este pentru fiecare vizitator. Deoarece înregistrarea pe acest forum nu este necesară pentru a vizualiza atașamentele, atașamentele pot fi stocate în cache pentru, să zicem, câteva zile. Ceva de genul:locație = /attachment.php ( expiră max; limit_req zone=lim_req_1s_zone burst=5; fastcgi_pass forum__php_cluster; include /etc/nginx/fastcgi_params; include /etc/nginx/fastcgi_params_php-fpm; fastcgi_cache set_forum___Control_Control_Cache; ; fastcgi_hide_header Set-Cookie fastcgi_cache_key "$request_method:$http_if_modified_since:$http_if_none_match:$request_uri:" fastcgi_cache_use_stale updating timeout invalid_header a_chec_0; și undeva în secțiunile http declara forum_att__cache: fastcgi_cache_path /var/ cache/nginx/att levels=1:2 keys_zone=forum_att__cache:4m max_size=2g inactiv=2d;
A doua „revelație” pentru mine a fost că există arhive pe forum și nu numai că există, dar aproape jumătate din solicitări provin de la ele. Aspectul paginilor permite, de asemenea, ca conținutul acestora să fie stocat în cache:
locație /arhivă/ ( expiră 10 d; limit_req zone=lim_req_1s_zone burst=2; locație ~ \.css$ ( expiră max; ) fastcgi_pass forum__php_cluster; fastcgi_index index.php; include /etc/nginx/fastcgi_params; include /etc/fastcgi_params/fastcphp -fpm; fastcgi_param SCRIPT_FILENAME $document_root/index.php fastcgi_param SCRIPT_NAME $fastcgi_cache_cache; che_use_stale eroare de actualizare timeout invalid_header http_500; fastcgi_cache_valid 2d ) și la secțiunea http: fastcgi_cache_path /var/cache/nginx/arc levels=1:2 keys_zone=forum_arc__cache:4m max_size=2g inactive=2d; În același timp, să ne protejăm de atacurile DDOS: limit_req_zone "$psUID" zone=lim_req_1s_zone:2m rate=1r/s;
Vă voi spune despre formarea cheii „$psUID” mai târziu.
Ancheta. Partea a doua - autorizare în vBulletin
Din punctul de vedere al unui vizitator al forumului, un vizitator poate fi fie un utilizator înregistrat, fie un invitat. Dar o situație complet diferită se dezvoltă dacă observăm situația „a venit, a mers, a autentificat, a mers, a deconectat, a mers” din punctul de vedere al apariției și dispariției cookie-urilor în browser. Deci, ștergeți cookie-urile pentru domeniu și subdomeniile acestuia, deschideți HTTPfox și vedeți ce se întâmplă:HTTP/1.1 200 OK Set-Cookie: PHPSESSID=cdme9rrptft67tbo97p4t1cua5; expiră=mi, 22-feb-2012 15:04:12 GMT; cale=/; domain=.domain.com Set-Cookie: bblastvisit=1329059052; expiră=Lun, 11-Feb-2013 15:04:12 GMT; cale=/; domain=.domain.com Set-Cookie: bblastactivity=0; expiră=Lun, 11-Feb-2013 15:04:12 GMT; cale=/; domain=.domain.com Set-Cookie: uid=XCuiGU831OyC8VLqAx/QAg==; expiră=Joi, 31-Dec-37 23:55:55 GMT; domain=.domain.com; cale=/
CU uidȘi PHPSESSID totul este clar - acestea sunt mașinațiunile nginx și interpretul php cu opțiunea instalată session.auto_start, dar restul sunt monitori de activitate pe forum. Dar cookie-ul principal de sesiune al vBulletin nu a fost încă observat. Privind în viitor, voi spune că vBulletin nu folosește o sesiune PHP standard (mai precis, APROAPE nu o folosește), ci își menține propria, al cărei identificator este stocat într-un cookie bbsessionhash. Deci, utilizatorul s-a autentificat, dar nu există nicio sesiune - adică este anonim fără o sesiune. În acest caz, link-urile către forum pot avea două tipuri (asta înseamnă toate link-urile de pe pagină, și nu unul ca acesta și altul ca ăsta):
forum.domain.com/forumdisplay.php?s=12b66e447be52ebc84ab16d3f39626fb&f=69
forum.domain.com/forumdisplay.php?f=69
Și dacă urmați linkul de primul tip, atunci următorul răspuns de pe forum va fi cookie-ul de sesiune, dar dacă urmați linkul de al doilea tip, nu va fi. Dacă nu ați primit un cookie de la sesiune cu al doilea răspuns, atunci puteți să vă plimbați pe forum fără sesiune și neliniștit până când întâlniți un link de primul tip (nu mi-am putut da seama de modelul apariției lor), sau vrei să te autentifici. Dacă autentificarea are succes, cookie-ul de sesiune va ajunge în orice mod. Dacă înainte de a se autentifica, oaspetele a fost anonim cu o sesiune, atunci sesiunea va fi înlocuită pentru el. Arata cam asa:
HTTP/1.1 200 OK Set-Cookie: bbsessionhash=85745bc6110db5221e159087bf037f24; cale=/; domeniu=.domeniu.com; Numai Http
După conectare, sesiunea este „stabilă” și nu există un salt cu link-uri. Procedura de deconectare nu este diferită - toate modulele cookie existente de forum sunt șterse (chiar și cele care nu au fost setate) și cookie-ul unei noi sesiuni („anonim”) este scris:
HTTP/1.1 200 OK Set-Cookie: bbsessionhash=șters; expiră=joi, 01-ian-1970 00:00:01 GMT; cale=/; domain=.domain.com Set-Cookie: bblastvisit=șters; expiră=joi, 01-ian-1970 00:00:01 GMT; cale=/; domain=.domain.com Set-Cookie: bblastactivity=șters; expiră=joi, 01-ian-1970 00:00:01 GMT; cale=/; domain=.domain.com Set-Cookie: bbthread_lastview=deleted; expiră=joi, 01-ian-1970 00:00:01 GMT; cale=/; domain=.domain.com Set-Cookie: bbreferrerid=șters; expiră=joi, 01-ian-1970 00:00:01 GMT; cale=/; domain=.domain.com Set-Cookie: bbuserid=șters; expiră=joi, 01-ian-1970 00:00:01 GMT; cale=/; domain=.domain.com Set-Cookie: bbpassword=șters; expiră=joi, 01-ian-1970 00:00:01 GMT; cale=/; domain=.domain.com Set-Cookie: bbthreadedmode=deleted; expiră=joi, 01-ian-1970 00:00:01 GMT; cale=/; domain=.domain.com Set-Cookie: bbstyleid=șters; expiră=joi, 01-ian-1970 00:00:01 GMT; cale=/; domain=.domain.com Set-Cookie: bblanguageid=șters; expiră=joi, 01-ian-1970 00:00:01 GMT; cale=/; domain=.domain.com Set-Cookie: bbsessionhash=3d0bdc5dbe8dabae361deebe8f6048d2; cale=/; domain=.domain.com; Numai Http
Adică, la ieșire obținem o persoană anonimă (oaspete), dar sută la sută cu o sesiune.
Ca rezultat, din punct de vedere al software-ului de forum ȘI Antetele HTTP avem trei tipuri de utilizatori: invitat fără sesiune, invitat cu sesiune, vizitator autentificat. Mai mult, la nivelul nginx, distingerea celui de al doilea de al treilea este extrem de problematică.
Acum, după ce ați înțeles ce cookie-uri și cum se deplasează între vizitator și server, puteți aborda problema stocării în cache a conținutului dinamic. După cum știți, funcționalitatea pentru stocarea în cache a răspunsurilor din backend-ul fastcgi în nginx este încorporată în modulul ngx_http_fastcgi_module. Pentru a face acest lucru, trebuie să înregistrați o zonă de stocare în cache la nivel global în secțiunea http și o cheie în locația dorită. Și dacă pentru conținut static condiționat (imagini, arhive) cheia pentru stocarea în cache ar putea fi considerată un URI cu adăugiri minore, atunci. pentru dinamica de cache trebuie să țineți cont și de utilizator Ar părea o regulă ca
fastcgi_cache_key "$request_method:$http_if_modified_since:$http_if_none_match:$gazdă:$request_uri:$cookie_bbsessionhash:";
ar putea satisface atât oaspeții, cât și utilizatorii autentificați, dar, în practică, vizitatorii au început să primească conținutul cache-ului altcuiva. Memorarea în cache a dinamicii „adevărate” a trebuit să fie dezactivată. Sper ca verdictul să nu fie definitiv.
Cu toate acestea, aceste informații nu sunt inutile. Pe baza acesteia, putem genera o cheie pentru a limita frecvența solicitărilor în funcție nu numai de adresa IP a vizitatorului, ci și de starea acestuia.
setați $psUID „anon”; setați $psUCL „anon”; if ($cookie_bbsessionhash) (setează $psUID „$cookie_bbsessionhash”; setează $psUCL „utilizator”; ) if ($psUCL = „anon”) (setează $psUID „anon:$adresă_la distanță”; )
Am plasat acest fragment al configurației în secțiunea de server din configurația nginx înainte de a descrie toate locațiile. Drept urmare, primim o cheie originală pentru un utilizator care are o sesiune și o cheie bazată pe adresa IP pentru vizitatorii care nu au o sesiune (de exemplu, pentru crawlerele de căutare).
