Protecția Joomla

Creați un șablon de adaptare Joomla utilizând Bootstrap. Partea 5. Adăugarea icoanelor Bootstrap la elementele din meniul Joomla

Protecția Joomla

În acest articol voi vorbi despre cum puteți adăuga pictogramele Bootstrap la elementele de meniu individuale Joomla, prin simpla editare a setărilor acestor elemente.







Wedal Joomla Slider v1.1 - modul slideshow gratuit pentru Joomla de la wedal.ru (update)

Protecția Joomla

Astăzi aș dori să vă prezint o actualizare a modulului Wedal Joomla Slider - versiunea 1.1 =). În ciuda faptului că 1.1 de la 1.0 separă doar 10%, modulul a fost rescris aproape complet. Am adăugat câteva noi caracteristici utile, care anterior nu erau disponibile și care lipseau în dezvoltare. Sper că le plac.

Noile caracteristici ale programului Joomla 3.7

Protecția Joomla

În acest articol dau o prezentare generală a noilor caracteristici ale Joomla 3.7 cu exemple.

Filtre personalizate Pro - filtru rapid și convenabil pentru câmpurile suplimentare Virtuemart

Protecția Joomla

Astăzi, vom vorbi despre una dintre cele mai bune extensii la problema de filtrare a produselor Virtuemart-Custom Filters Pro.

Joomla Custom Fields - câmpuri personalizate în Joomla

Protecția Joomla

În acest articol vom analiza toate tipurile de câmpuri personalizate disponibile în Joomla, precum și exemple de utilizare a acestora pe site.

Protecția Joomla

Nu te poți apăra de inamic, fără să știi ce arma foloseste. Primul și cel mai important despre ceea ce ar trebui să știți - care sunt tipurile de atacuri asupra site-urilor. Știind cum poate fi hackat un site este mult mai ușor de înțeles cum să îl protejezi sau ce vulnerabilitate în cazul în care site-ul este deja hacked. În acest articol voi vorbi despre principalele tipuri de atacuri care pot fi angajate pentru site-ul Joomla.

Caracteristica de securitate a Joomla, ca un open source CMS.

După cum știți, Joomla este un proiect open source. Aceasta înseamnă că oricine poate vedea codul Joomla. Este bine sau rău? Întrebarea este controversată.

Pentru a înțelege avantajele și dezavantajele sursei deschise, imaginați-vă două casete. Negru și transparent. Cutia neagră este un cod privat. Dacă site-ul rulează pe un CMS auto-scris sau pur și simplu în PHP, nu puteți vedea codul său sursă. Tot ce se poate face este să trimiteți un efect de intrare și să monitorizați rezultatul obținut la ieșire. Ie trimiteți o solicitare (de exemplu, completați formularul și trimiteți datele) și, în schimb, primiți rezultatul (de exemplu, datele au fost primite cu succes sau o eroare).

Dacă vorbim despre o cutie transparentă, care este orice proiect open source, inclusiv Joomla, atunci putem vedea toate procesele care apar în ea. Toate punctele de date. Putem să înțelegem cu ușurință motivul pentru acest sau acel rezultat obținut la ieșire.

Deci, ce este cel mai bun din punct de vedere al securității: o cutie neagră sau transparentă? Primul răspuns care vine în minte este, desigur, negru. La urma urmei, ignoranța proceselor de procesare a datelor complică în mod semnificativ hacking-ul. Da, este, dar nu întotdeauna. Dacă codul închis a fost scris de un programator foarte bun și apoi a trecut testul, probabilitatea de hacking este extrem de mică. Problema este că acest cod, practic, scrie doar angajatii corporatiilor mari, cum ar fi Yandex, Google, Mail.ru, Vkontakte, etc. Nivelul angajaților din aceste companii este, de obicei, foarte ridicat, ca și salariul lor. Și acum să ne gândim, cine scrie site-uri web pentru afaceri mici și mijlocii? Crede-mă, nu geniul codului de program. De multe ori, ele permit vulnerabilități de bază, care sunt capabile să detecteze chiar și roboții automate, să nu mai vorbim în cazul în care site-ul va fi preluat de către hackeri. În plus, codul privat se relaxează. De ce a programator pentru a scrie cod eficient, în cazul în care încă nimeni nu vede?

Acum, uita-te la codul open source. Da, este complet vizibil, dar acest moment nu este numai negativ. Dacă comunitatea proiectului open source este mare (cum ar fi, de exemplu, în Joomla), informațiile despre toate vulnerabilitățile detectate sunt raportate dezvoltatorilor și vulnerabilitățile sunt închise. Acest lucru se întâmplă de mai multe ori, ca rezultat al calității codului. Astfel, sursa deschisă, în opinia mea, este preferabilă față de cea privată, dar are caracteristici care trebuie respectate. În primul rând, aceasta este o actualizare obișnuită atât a Joomla, cât și a extensiilor acesteia. Logica este după cum urmează: dacă a fost emisă o actualizare de securitate, atunci vulnerabilitatea a fost găsită în cod. Dacă s-ar găsi vulnerabilitățile, atunci a devenit cunoscută. Dacă devin cunoscute, atunci în viitorul apropiat cineva va încerca să le folosească. Dacă actualizați Joomla și actualizați la cele mai recente versiuni în timp util, vulnerabilitățile de pe site vor fi închise mai devreme decât pot utiliza. Ie puteți dormi liniștit.







Actualizarea la timp este principala caracteristică a protecției Joomla. Este important să înțelegeți acest lucru. S-ar putea să nu înțelegeți complexitatea atacurilor, dar trebuie să vă amintiți că aceste patch-uri trebuie să fie puse la timp, altfel site-ul dvs. nu va fi protejat.

Principalele tipuri de atacuri pe site-urile Joomla. Selectarea parolei.

Un alt tip masiv de atac constând într-o nerespectare a securității proprietarului site-ului este credulitatea lui. Prima imagine arată bine această imagine:

Protecția Joomla

Al doilea este puțin mai complicat, dar, în general, este exprimat prin încălcarea următoarelor reguli:

Principalele tipuri de atacuri pe site-urile Joomla. Atacurile specializate (XSS, injecție SQL, etc.).

Pentru a împiedica acest lucru, datele încărcate de utilizatori pe site trebuie să fie supuse unei filtrări stricte, excluzând posibilitatea de a descărca altceva decât ceea ce se așteaptă. Această sarcină ar trebui să fie rezolvată de dezvoltatori în faza de creare a prelungirii, dar suntem cu toții oameni, iar erorile nu sunt neobișnuite. Pentru Joomla, există extensii specializate care vă verifică singur toate formele și alte vulnerabilități. Acestea vor fi discutate într-un articol separat.

Principalele tipuri de atacuri asupra site-urilor Joomla, atacurilor DOS și DDOS.

Un tip periculos de atac datorită capacității limitate a serverului pe care este găzduit site-ul. Esența atacului este de a trimite atât de multe cereri pe site simultan încât serverul să nu mai facă față prelucrării lor, iar vizitatorii obișnuiți vor deveni inaccesibili. Este clar că astfel de atacuri nu pot fi permanente, dar durează câteva, deși uneori prelungite, timp. De obicei, atacurile DDOS sunt folosite atunci când site-ul are o prezență ridicată și ocupă poziții înalte pe cereri competitive. Atacurile DDOS sunt destul de scumpe, dar practic nu există protecție împotriva lor. Problema este că solicitările către site-ul sunt făcute din calculatoarele infectate ale utilizatorilor obișnuiți de Internet, fără știrea lor. În același timp, devine foarte dificilă separarea utilizatorilor obișnuiți care au vizitat site-ul de la cererile de atac.

Principalele tipuri de atacuri pe site-urile Joomla. Vulnerabilitățile serverului.

Se întâmplă adesea ca în hacking-ul site-ului să nu fie vina nici motorul, nici proprietarul. Vulnerabilitatea poate fi găsită pe serverul gazdă ce găzduiește site-ul. Acest caz este destul de frecvent, mai ales atunci când se folosește ieftinul hosting ieftin. Pe de o parte, calitatea profesioniștilor este slabă, celălalt - pentru hacker este un tidbit, de rupere care poate da acces direct la gazdă la sute de site-uri.

Securitatea unui site de la astfel de vulnerabilități este destul de simplă: utilizați numai găzduitori mari dovediți.

Asta e tot. Există și alte tipuri de atacuri, mai puțin frecvente. Dar ele vor fi folosite în acele cazuri în care site-ul dvs. este de interes real pentru hacker și decide să o facă personal. Acest caz nu este frecvent, deoarece 95% din site-urile de Internet nu au nimic care ar putea interesa hackerii atât de mult încât să încerce să hackeze site-ul manual. Dacă site-ul aduce un profit foarte mare și este un os în gâtul concurenților, atunci nu este un păcat să comandăm un audit profesional într-o companie care se ocupă de securitate.

Mulțumesc! Aștept cu nerăbdare să continuăm cu metode de protecție specifice!

Voi alătura motivele pentru continuarea subiectului și vreau să vă întreb: vă rugăm să ne spuneți exact cum ați asigurat descărcarea site-ului.

Cineva mi-a pus un minus, se pare că ar trebui să clarific pentru cei care vin aici pe vehicule blindate. Există programe precum exploratorul offline care poate descărca site-uri întregi. În timpul procesului de descărcare, există o serie de interogări care uneori chiar și unele dintre servitorii selectați încep să moaneze. Și dacă sunt deja în sarcină în acel moment. Nu mă uit la minus întrebarea mea rămâne reală. SW. Wedal, împărtășiți-vă experiența! Știu că o ai :)

Și cum mi-a lipsit un astfel de articol, se pare, și site-ul dvs. este semnat. Începutul este bun, așteptăm continuarea, ca să spunem așa, cu metode practice. Deși am pus deja o anumită protecție pe unele site-uri, dar totul a fost legat de ascunderea zonei administrate, de drepturile la foldere, de autentificare și de id-ul administratorului și așa mai departe. Dar cum să salvați un site cum ar fi descărcarea este interesant.

Dragă, Vitaly!
Prompt, și apoi nu știu unde să arate.
În fișierele text Jumla (Contacte, Expediere și Plăți, Bine ați venit pe pagina principală), a apărut un cod rău intenționat, care redă textul pe aceste pagini în semne "??".
Ie pe pagina principală a fost textul: Bine ați venit. Realizează în.
Copleșit de dosarele lui Djumla, nu a ajutat. Doar atașat Virtumart.
Jumla 1.5.22

Daniel, poate că nu este cod rău intenționat, dar tocmai ați salvat unele fișiere (limbă?) În codificare greșită. Codificarea trebuie să fie UTF8 fără BOM.

Vă mulțumim pentru clarificare. Am o singură opinie în mare cerere și mulți concurenți. Acum înțeleg de ce site-ul este închis cu cereri.

În ceea ce privește această frază în atacurile DOS este posibil mai mult în detaliu?
Citez pe Wedal:


Cum pun un filtru?

mistershadow, a răspuns la forum.

Și a văzut un aflux mare de atacuri asupra Joomla, sute de site-uri sunt afectate de atacurile ele însele ce gazduieste companii start pentru a închide la timp parola de admin ghicitul.

Am un site educațional cu o prezență de 1,5 mii în vară și un site de sex feminin de 300 de vizite. Au fost sacrificați timp de 3 săptămâni. Zona de administrare este ascunsă, parola este complexă. În .htaccess toate ip-urile sunt blocate în panoul admin. Nu mai merg la zona administratorului. Hoster afirmă că sarcina este prohibitivă. Busteni urca in fiecare zi de la ip diferite. Am uitat tot ip-ul, participarea a căzut de două ori. Ce ar trebui să fac? Nu-mi pot imagina.

Elvira, primele mele metode sunt:
- utilizați protecție împotriva inundațiilor - există un sh404sef. Vă recomand.
- "administrator ascuns" - se întâmplă în moduri diferite. Este cel mai eficient pentru a închide accesul la acesta prin .htaccess + .htpassword în directorul de administrare.
- schimbați hostetul la unul bun)
- dacă J! 1.5.x - SCHIMBĂ URGENT la una nouă.

Elvira și Magnum79, într-adevăr acum pe mai multe site-uri web înființat .htpassword suplimentare pe directorul de administrare, și anume Pentru a intra în zona de administrare, trebuie să introduceți parola de 2 ori (diferită). Dacă există încă o confuzie, atunci puteți accesa în mod suplimentar numai dintr-un singur IP, dar personal nu este convenabil pentru mine. IP primesc dinamic și aceasta nu este o opțiune, cu excepția faptului că pot rezolva subrețea. Joomla este unic 2,5 sau 3.
De asemenea, interesant, poate fi posibil pentru a ascunde într-un fel Joomla, astfel încât roboții nu se poate defini, dar cred că fie nu este real sau este foarte scump.

"Disguise J!" - Îmi amintește de modul în detstsve închise ochii și se pare că nu :) Aceasta va ajuta numai de la vârsta de hatskerov similare

Magnum79, nu neapărat. Faptul este că majoritatea robilor lucrează doar primitivi. Sunt folosiți cei mai simpli determinanți CMS. Aceeași etichetă generatoare. Acest lucru se datorează faptului că masa este importantă pentru roboți. Dacă o persoană are cel puțin grijă de securitatea site-ului său, atunci de ce să petreceți timp și resurse pe un astfel de site? La urma urmei, este mai ușor să găsești pe Internet o sută mai mult de aceeași protecție neprotejată.
Un alt lucru - dacă site-ul hacker a luat personal. Da, nu ajută.

Un fel de apă solidă pentru "gospodine", unde injecțiile SQL și altele? Nimeni nu sparge parolele acum.

Anton, căutarea parolelor este încă ruptă. Deci, acele gazde deconectează site-urile din cauza încărcării pe pagina standard de autentificare din zona de administrare. Vorbesc, pe baza experienței și experienței personale a clienților.
Injectarea SQL este deja pe Habr. Inca mai incerc sa scriu articole publice, sa implementez exemple de care pot sa faca non-programatorii. Injecția este un nivel complet diferit.

Blocate cu ajutorul accesului .htaccess la directorul / administratorul pentru toate IP-urile cu excepția ei - o problemă cu selecție rezolvată radical, cu toate că am atât de conectare și o parolă care sunt imposibil de găsit. O injecție SQL și alte dop ușor de blocat jHackGuard, ar putea scrie despre ea in articol. Am fost infectat de mai multe ori si am spart site-urile, asa ca nu stiu de rau. Odată vindecat magazin online familiare de la un virus care a paralizat de fapt, site-ul său, muck stând într-un discret un fișier „imagine“ cu extensia PNG, l-am găsit încercarea de a descărca un fișier de backup gazdă, Avast a arătat imediat în cazul în care creatura blocat.







Articole similare

Trimiteți-le prietenilor: