Un server fără monitorizare nu e sigur, e doar liniștit. Discul plin, un proces care mănâncă CPU-ul sau o mie de autentificări eșuate se văd abia când clienții sună. Monitorizarea e și singura dovadă că ai observat un incident la timp.
Metricile îți spun că ceva e în neregulă; logurile îți spun ce. Patru metrici sunt obligatorii pe orice server: spațiul pe disc, memoria disponibilă, încărcarea procesorului și conexiunile deschise; pentru o aplicație web adaugi rata de erori 5xx și latența la percentila 95. Din loguri, cele de autentificare arată brute force și logări neobișnuite, nginx arată scanări și exploatări, aplicația arată excepțiile, iar auditd înregistrează comenzi rulate ca root și modificări în fișiere sensibile. journalctl le citești local; sistemul central le păstrează.
Primul lucru pe care îl face un atacator după ce intră e să curețe logurile. Dacă singura copie e pe mașina compromisă, investigația s-a terminat înainte să înceapă. De aceea Grafana Alloy trimite logurile în timp real pe o mașină la care serverul de producție are doar canalul de ingestie. Alertele funcționează invers: cu cât sunt mai multe, cu atât sunt ignorate. Definești un obiectiv de nivel de serviciu, de exemplu 99,9 % din cereri fără eroare, și alertezi când îl consumi prea repede. Discul sub 10 % și un login din afara VPN-ului merită să trezească pe cineva.
OUG 155/2024, transpunerea NIS2 aprobată prin Legea 124/2025, cere entităților înregistrate la DNSC o alertă timpurie în 24 de ore de la constatarea unui incident semnificativ, notificare în 72 de ore și raport final la o lună de la aceasta. Fără loguri și metrici nu poți nici constata incidentul, nici scrie raportul. GDPR cere, prin art. 33, notificarea ANSPDCP în 72 de ore de la aflarea unei breșe și, prin art. 32, capacitatea de a detecta astfel de evenimente. Logurile conțin adrese IP, deci date personale: termen definit și acces limitat.
| Semnal | Sursa | Prag de alertă tipic | De ce contează |
|---|---|---|---|
| Spațiu pe disc | node_exporter | sub 10–15 % liber, 15 minute | Baza de date refuză scrieri, logurile se pierd |
| Erori HTTP 5xx | nginx, aplicație | peste 1 % din cereri, 5 minute | Simptom direct pentru utilizatori |
| Latență p95 | aplicație, nginx | peste SLO-ul definit | Degradare înaintea căderii |
| Autentificări SSH | auth.log / journal | login reușit din afara VPN | Brute force, cont compromis |
| Fișiere sensibile | auditd | orice modificare în /etc/ssh, /etc/sudoers.d | Persistența atacatorului |
| Certificat TLS | blackbox_exporter | expiră în sub 14 zile | Site inaccesibil la expirare |
journalctl --since "-1h" -p warning
journalctl -u ssh --since today | grep -E "Accepted|Failed"
sudo ausearch -m EXECVE -ts recent// /etc/alloy/config.alloy
loki.write "central" {
endpoint { url = "http://10.0.0.20:3100/loki/api/v1/push" }
}
local.file_match "sistem" {
path_targets = [
{__path__ = "/var/log/auth.log", job = "varlogs", host = "web-01"},
{__path__ = "/var/log/nginx/*.log", job = "varlogs", host = "web-01"},
]
}
loki.source.file "sistem" {
targets = local.file_match.sistem.targets
forward_to = [loki.write.central.receiver]
}groups:
- name: server
rules:
- alert: DiscAproapePlin
expr: node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} < 0.10
for: 15m
labels:
severity: critical
annotations:
summary: "Sub 10 % spațiu liber pe / ({{ $labels.instance }})"Discul s-a umplut cu loguri de nginx într-o noapte de scanare intensă, iar PostgreSQL a refuzat scrierile. Nimeni nu a aflat până la prima reclamație de dimineață. O alertă pe spațiul liber sub 15 % și logrotate configurat corect au eliminat clasa de incident.
Un server compromis avea logurile de autentificare șterse, deci nu se știa de când era atacatorul înăuntru. Copia din Loki, pe o mașină separată, arăta prima logare reușită cu trei săptămâni înainte, dintr-o cheie SSH adăugată de un fost colaborator.
Logurile de securitate, autentificări, sudo, auditd, cel puțin șase luni, ca să poți investiga un incident descoperit târziu. Logurile de acces web conțin adrese IP, deci date personale: le păstrezi cu un termen definit în politica GDPR, de obicei 30–90 de zile, apoi le agregi sau le ștergi.
Pentru un singur server, o verificare externă de disponibilitate plus alerte simple pe disc și memorie pot fi suficiente la început. Prometheus și Loki devin necesare când ai mai multe mașini sau când trebuie să dovedești ce s-a întâmplat.
Monitorizarea urmărește sănătatea sistemului: resurse, erori, latență. Un SIEM colectează evenimente de securitate din mai multe surse și le corelează: 500 de autentificări eșuate urmate de una reușită, apoi o cheie nouă în authorized_keys. Pe un server mic, Loki cu câteva reguli acoperă ambele roluri.
Un server de producție e atacat automat din primele minute după ce primește IP public, indiferent cât de mic e proiectul. Ghidul ordonează controalele după impact, de la accesul SSH până la răspunsul la incident, cu legislația din România care se aplică. Fiecare temă are o pagină dedicată, cu răspuns scurt, exemple și configurări.