Securitate cPanel: Cum protejați contul de hosting împotriva atacurilor

Securitate cPanel: Cum protejați contul de hosting împotriva atacurilor, fiindcă un cont cPanel compromis înseamnă toate site-urile, toate bazele de date și tot e-mailul din cont, deodată. Am curățat conturi în care un singur site vechi, uitat într-un subdosar, a dat atacatorului acces la cinci domenii active. Ghidul spune ce puteți face din cPanel (mult), ce ține de furnizor (restul) și în ce ordine, cu ce am învățat din incidentele de pe conturile clienților.

Căile de intrare, în ordinea frecvenței: o aplicație web vulnerabilă (WordPress cu module neactualizate, în primul rând), o parolă slabă sau refolosită la cPanel, FTP sau e-mail, un calculator de administrator infectat, un site vechi de pe același cont, și, rar, o vulnerabilitate a serverului. Măsurile de mai jos le acoperă pe toate.

Securitate cPanel: Cum protejați contul de hosting împotriva atacurilor

1. Al doilea factor pentru cPanel

Security, Two-Factor Authentication: scanați codul QR cu aplicația de autentificare și confirmați. De acum, autentificarea cere parola și codul de 30 de secunde. Este măsura cu cel mai mare efect pentru cel mai mic efort; configurarea pe toate conturile importante este descrisă în ghidul despre autentificarea în doi pași. Activați-o și pe contul de client al furnizorului, de unde se poate reseta parola cPanel.

2. Parole și contul de contact

Parolă generată, de cel puțin 16 caractere, unică, în manager de parole; schimbată la orice suspiciune. Adresa de contact din Preferences, Contact Information, la un e-mail pe care nu îl găzduiți pe același cont (dacă contul cade, notificarea trebuie să ajungă totuși), cu toate notificările de securitate bifate: autentificări de la adrese noi, schimbări de parolă, cota de spațiu.

3. Restricția pe adrese IP

Dacă accesați cPanel de la birou și de acasă, cereți furnizorului restricția accesului la panou pe adresele dumneavoastră (Host Access Control în WHM); din cPanel nu o puteți seta singur. Pentru site-urile din cont, IP Blocker (sau IP Deny Manager) blochează adresele și intervalele care fac scanări sau încercări repetate, cum arătăm în ghidul despre limitarea accesului prin IP Deny Manager.

4. ModSecurity

Firewall-ul de aplicație, activat din Security, ModSecurity, pe fiecare domeniu. Setul de reguli (de obicei OWASP CRS sau cel al furnizorului) blochează injecțiile, încărcările de fișiere periculoase și tiparele cunoscute de atac înainte să ajungă la aplicație. Când blochează ceva legitim, dezactivați regula respectivă, nu tot modulul; procedura este în ghidul despre activarea protecției ModSecurity.

5. Permisiunile și dosarele de încărcare

755 pe dosare, 644 pe fișiere, 600 pe fișierele de configurare cu parole; nimic cu 777. În dosarele de încărcare (uploads, cache, temp ale oricărei aplicații), un .htaccess care interzice execuția PHP: este regula care oprește cel mai des al doilea pas al unui atac, când atacatorul a reușit să urce un fișier, dar nu îl poate rula. Pe conturile pe care le administrăm, această regulă este aplicată pe toate dosarele scriibile, după un incident în care rădăcina unui portal rămăsese neprotejată.

# .htaccess în dosarele de încărcare
<FilesMatch "\.(php|phtml|php[0-9]|phar|cgi|pl|py|sh)$">
    Require all denied
</FilesMatch>

6. Aplicațiile din cont

Fiecare instalare (WordPress, magazin, formulare) actualizată în aceeași săptămână cu lansarea versiunilor; instalările de test și cele vechi șterse, nu doar „oprite”. WordPress Toolkit sau Softaculous din cPanel listează toate instalările din cont și versiunile lor; un inventar lunar găsește site-urile uitate. Măsurile specifice WordPress sunt în ghidul despre securizarea unui site WordPress.

7. FTP și SSH

FTP simplu transmite parola în clar; folosiți SFTP sau FTP cu TLS, cu conturi separate pe fiecare colaborator, limitate la dosarul lui, șterse la finalul colaborării; configurarea este în ghidul despre accesul FTP și SFTP în cPanel. Pentru SSH, chei în locul parolelor, din SSH Access, Manage SSH Keys.

8. E-mailul

Conturile de e-mail cu parole slabe sunt sparte și folosite pentru spam, ceea ce duce la blocarea domeniului și, uneori, la suspendarea contului. Parole generate pe fiecare cont, filtrul de spam activ, SPF, DKIM și DMARC configurate din Email Deliverability, și verificarea din Track Delivery a mesajelor trimise pe care nu le recunoașteți. Un cont care trimite 5.000 de mesaje într-o noapte se vede acolo dimineața.

9. Jurnalele

Errors și Raw Access din Metrics, cu arhivarea lunară bifată; o privire săptămânală după cereri POST spre fișiere PHP necunoscute, 404 în masă și autentificări eșuate. Cum le citiți este în ghidul despre jurnalele de erori și acces. Jurnalul de autentificări cPanel nu este vizibil din panou; cereți-l furnizorului la orice suspiciune.

10. Copiile de siguranță

Copii automate, în alt loc decât serverul, testate; sunt măsura care transformă un incident dintr-o catastrofă într-o după-amiază de restaurare. Cele două unelte din panou sunt descrise în ghidurile despre copiile automate și copiile manuale.

Ordinea în prima zi pe un cont nou

1. Al doilea factor pe cPanel și pe contul de client; parolă nouă, generată.
2. Adresa de contact externă și notificările de securitate.
3. Inventarul instalărilor și ștergerea celor de test sau vechi.
4. ModSecurity activ pe toate domeniile.
5. Permisiuni corectate în masă și .htaccess anti-PHP în dosarele scriibile.
6. Conturile FTP și SSH: doar cele necesare, cu chei sau SFTP.
7. Parole noi pe toate conturile de e-mail slabe (cele sub 12 caractere se schimbă indiferent de vechime).
8. Arhivarea jurnalelor bifată, prima copie de siguranță descărcată.

Durează două ore pe un cont cu trei site-uri și elimină cele mai frecvente cauze de compromitere pe care le-am întâlnit. Restul măsurilor se adaugă în prima lună.

Semnele unui cont deja compromis

Înainte de a securiza, verificați că nu securizați un cont deja spart: fișiere PHP în dosarele de încărcare, fișiere cu date de modificare recente pe care nu le explicați, sarcini cron pe care nu le-ați creat (Cron Jobs din panou), conturi de e-mail sau redirecționări necunoscute, utilizatori FTP în plus, trafic de e-mail neobișnuit în Track Delivery, procese PHP cu nume străine în Resource Usage. Oricare dintre ele înseamnă curățare înainte de securizare; măsurile de mai sus aplicate peste o infecție o conservă.

Ce ține de furnizor

• Actualizările serverului, ale cPanel și ale PHP; o versiune PHP retrasă (7.4 și mai vechi) nu mai primește corecții de securitate, indiferent ce faceți dumneavoastră.
• Izolarea conturilor între ele (CloudLinux CageFS): fără ea, un cont compromis de pe același server poate citi fișierele altora.
• cPHulk sau echivalent, împotriva încercărilor repetate de autentificare la panou și la e-mail.
• Scanerul de malware al serverului (Imunify, ClamAV) și firewall-ul de rețea.
• Copiile de siguranță ale serverului, cu politica lor de păstrare.

Întrebați furnizorul explicit despre fiecare; un răspuns vag la „aveți izolare între conturi?” este un motiv de mutare. Licențele cPanel piratate, întâlnite la găzduiri foarte ieftine, înseamnă un panou fără actualizări; cazul este descris în articolul despre pericolele unei licențe cPanel frauduloase.

Calculatorul administratorului

Un procent surprinzător de compromiteri începe pe calculatorul celui care administrează contul: un program care fură parolele salvate în browser sau în clientul FTP. Măsurile: sistem de operare și browser actualizate, fără parole salvate în clienți FTP, manager de parole cu parolă principală, al doilea factor peste tot (care face parolele furate inutile), și atenție la e-mailurile „de la cPanel” care cer autentificare; furnizorul nu trimite astfel de mesaje. Cazul unui miner instalat pe laptopul unui administrator, cu rotirea tuturor credențialelor după, ne-a învățat că lista de conturi de rotit trebuie să existe dinainte.

Când administrați mai multe conturi

Agențiile și dezvoltatorii care țin zeci de conturi cPanel au aceleași măsuri de aplicat de zeci de ori. Un inventar central (cont, furnizor, instalări, versiuni, data ultimei verificări, persoana responsabilă) și un script care rulează lunar verificările automate (sume de control, fișiere PHP în dosare de încărcare, fișiere modificate recent) pe fiecare cont, cu raport pe e-mail doar când găsește ceva, fac diferența dintre o oră pe lună și o săptămână după un incident. Pe conturile pe care le administrăm, scriptul rulează pe 40 de instalări în sub zece minute.

Lista lunară

1. Inventarul instalărilor din cont și versiunile lor; actualizări și ștergeri.
2. Utilizatorii: conturi FTP, chei SSH, conturi de e-mail, administratori în aplicații; ștergeți ce nu mai e folosit.
3. Jurnalele: POST suspecte, 404 în masă, trimiteri de e-mail neobișnuite.
4. Fișierele modificate recent în afara actualizărilor (find cu -mtime, din terminal) și fișierele PHP din dosarele de încărcare.
5. Copia de siguranță: există, e recentă, s-a restaurat o dată în ultimele trei luni.
6. Spațiul și resursele: un salt neexplicat indică deseori un script străin.

Dacă în ciuda măsurilor contul este compromis, ordinea pașilor de răspuns (izolare, dovezi, curățare, credențiale, cauză) este în ghidul despre răspunsul la incidente de securitate, iar curățarea unui site WordPress, în cel despre detectarea și eliminarea malware-ului. Verificarea externă a antetelor, a TLS-ului și a configurărilor vizibile se face cu scanerul de securitate GOAI.

Surse

• Documentația cPanel: uneltele din secțiunea Security și configurarea conturilor.
• Documentația cPanel, ModSecurity: activarea pe domenii și gestionarea regulilor.