Analiza jurnalului serverului: cum să înțelegeți că cineva încearcă să vă pirateze?

Giteqa

Salutare, prieteni!

Când închiriați un VPS și implementați un proiect pe el, vi se poate părea că în sistem domnește o liniște deplină până când site-ul este vizitat de utilizatori reali. Însă este suficient să deschideți logurile brute ale sistemului pentru ca această iluzie a calmului să se destrame instantaneu. În anul 2026, internetul s-a transformat într-un mediu agresiv, unde mii de scanere AI automatizate și rețele botnet testează non-stop fiecare adresă IPv4 și IPv6 disponibilă în căutare de vulnerabilități.

Majoritatea atacurilor cibernetice de succes nu au loc pentru că atacatorii folosesc exploit-uri private extrem de complexe. Hackerii găsesc pur și simplu un panou de administrare deschis, un backup uitat într-un director public sau ghicesc o parolă slabă de SSH. Serverul „strigă” întotdeauna că este atacat, lăsând sute de înregistrări în jurnale. Principalul lucru este să știi cum să citești aceste înregistrări. Din experiența personală, deoarece înregistrez tutoriale video pentru canalul nostru de YouTube, vă pot spune următorul lucru: chiar dacă un server este pornit de doar câteva minute, boții îl sondează deja, iar acest lucru este clar vizibil de îndată ce deschideți folderul de loguri.

În acest articol, vom analiza principalii indicatori ai activității suspecte în logurile Linux (Ubuntu 24.04 / Debian) și Nginx, și vom învăța Microsoft să identificăm atacatorii înainte ca aceștia să provoace daune reale.

Key Takeaways: Principalul despre analiza logurilor

  • Logurile sunt cutiile negre ale sistemului: În cazul oricărei anomalii în comportamentul serverului, auditul trebuie să înceapă din două puncte principale: /var/log/auth.log (securitatea SO) și jurnalul de acces al serverului web.

  • Automatizarea învinge rutina: Căutarea manuală a urmelor de intruziune în fișiere text de dimensiuni de gigabyți este ineficientă. Utilizați expresii regulate și utilitare de automatizare (Fail2ban, Graylog).

  • Liniștea este un semn rău: Dacă fișierele log au exact 0 octeți sau se întrerup brusc, acesta este un semn sigur că un atacator s-a instalat deja în sistem și a șters toate urmele prezenței sale.

Cum se instalează Fail2ban și Graylog?

Am înregistrat ghiduri video detaliate care prezintă procesul pas cu pas de instalare și configurare a ambelor instrumente de protecție automată și monitorizare pe serverul dumneavoastră.

  • Ghid video pentru instalarea Fail2ban pe Ubuntu:


    Toate comenzile pentru configurarea închisorii SSH și a timpilor de blocare le veți găsi în descrierea videoclipului și în comentariul fixat.

  • Ghid video pentru implementarea sistemului de colectare a logurilor Graylog:


    Toate fișierele de configurare, cheile de depozit și comenzile pentru integrarea nodului de date sunt disponibile în descrierea videoclipului.

Principalii indicatori de atac: Ce trebuie să căutați în jurnale?

1. SSH Brute Force (Ghicirea parolelor)

Jurnalul de autentificare este primul loc în care lovesc rețelele botnet. Deschideți fișierul /var/log/auth.log (pe CentOS/RHEL, acesta este /var/log/secure). Dacă vedeți linii nesfârșite de tipul:

Plaintext
Failed password for invalid user admin from 192.0.2.5 port 43210 ssh2

Acest lucru înseamnă că un atac de tip dicționar este executat împotriva serverului dumneavoastră chiar în acest moment, rulând prin logări populare (root, admin, user, test).

2. Scanarea după fișiere ascunse și panouri de administrare (Web Scanning)

In logurile unui server web Nginx sau Apache (/var/log/nginx/access.log), un atac arată ca o avalanșă de cereri rapide care returnează statusul 404 Not Found. Scanerele caută interfețe vulnerabile și fișiere de configurare:

  • GET /wp-admin/ sau /wp-login.php (scanare după vulnerabilități WordPress)

  • GET /.env или GET /config.json (încercări de a fura parolele bazelor de date și cheile API)

  • GET /.git/config (o încercare de a descărca depozitul proiectului)

  • GET /phpMyAdmin/index.php (căutarea panourilor de gestionare a bazelor de date)

3. Injecții SQL și Executarea de la distanță a comenzilor (RCE)

Dacă în jurnalele serverului web顶 apar cereri care conțin o mulțime de caractere ciudate, ghilimele sau căi de sistem, cineva vă țintește intenționat:

  • GET /index.php?id=1+AND+(SELECT+321+FROM+(SELECT(SLEEP(5))) — verificarea prezenței unei vulnerabilități de injecție SQL oarbă.

  • GET /cgi-bin/main.cgi?cmd=cat%/etc/passwd — o încercare de citire neautorizată a fișierelor de sistem Linux.

Tabel comparativ de bază: Tipuri de activitate în logurile de server

Tip de activitateExemplu de linie de logObiectivul ataculuiAcțiunea imediată a administratorului
SSH Brute ForceFailed password for root from...Obținerea controlului complet root asupra SO.Schimbarea portului SSH, dezactivarea logării root, trecerea la chei SSH.
Vulnerabilități CMSGET /wp-content/plugins/... 200Injectarea unui web shell sau a unui script de spam.Actualizarea imediată a nucleului CMS și a tuturor plugin-urilor.
Path TraversalGET /../../etc/passwd 400Citirea fișierelor de configurare și a datelor private.Configurarea corectă a restricțiilor open_basedir în PHP.
Scanarea porturilorCereri TCP scurte cu zero date transferate.Maparea serviciilor active care rulează pe server.Închiderea tuturor porturilor neutilizate prin UFW/iptables.

Practic: 3 comenzi для auditul rapid al serverului din consolă

Pentru a evalua rapid situația curentă pe un server sub Ubuntu 24.04, utilizați aceste comenzi simple de terminal. Ele agregă datele text în statistici structurate:

  1. Găsiți primele 10 adrese IP care atacă SSH-ul prin brute force:

    Bash
    sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -n 10
    
  2. Analizați cele mai frecvente erori 404 în Nginx (identificarea scanerelor):

    Bash
    sudo awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 10
    
  3. Verificați logările reușite în conturile de utilizator:

    Bash
    sudo grep "Accepted password\|Accepted publickey" /var/log/auth.log
    

FAQ: Pe scurt despre principalul

  • Logurile serverului meu arată mii de erori „Failed password” în fiecare zi. Este timpul să intru în panică?

    Nu, acesta este zgomotul de fundal standard al internetului. Boții automatizați scanează secvențial toate adresele IP disponibile. Atâta timp cât ați dezactivat autentificarea prin parolă pentru utilizatorul root și ați configurat Fail2ban, aceste încercări sunt complet inofensive pentru serverul dumneavoastră.

  • Ce ar trebui să fac dacă descopăr adresa IP a unui atacator?

    Blocați-o la nivel de firewall. De exemplu, utilizând utilitarul UFW, acest lucru se poate face printr-o singură comandă scurtă: sudo ufw deny from adresa_IP.

  • Cum pot proteja logurile împotriva ștergerii de către hackeri?

    Dacă un atacator obține privilegii root, va șterge fișierele jurnale. Pentru a preveni acest lucru, configurați colectarea centralizată a logurilor pe un server izolat (de exemplu, utilizând sistemul Graylog menționat mai devreme).

Concluzie

Analiza regulată a logurilor este o abilitate fundamentală care vă permite să observați din timp interesul unui hacker pentru proiectul dumneavoastră și să blocați amenințarea în etapa de recunoaștere. Rețineți: securitatea sistemului este la fel de puternică ca și cea mai slabă zale a sa. Codul curat, porturile închise și monitorizarea logurilor de rețea garantează un uptime stabil.

Deoarece analiza profundă a pachetelor, parsarea logurilor în timp real și funcționarea sistemelor de apărare (cum ar fi Fail2ban, Zeek sau Suricata) creează o sarcină constantă asupra subsistemului de discuri și a procesorului, securitatea solicită o bază hardware de înaltă calitate.

Dacă vă aflați în prezent în căutarea unei soluții de găzduire fiabile pentru proiectele dumneavoastră, explorați serviciile noastre NVME VPS / Dedicated Server la MivoCloud.


Autorul articolului — Anatolie Cohaniuc