meerkat: o consolă Suricata care îți arată surse, nu alerte

Suricata este un senzor superb și un interlocutor groaznic. Îndreaptă-l spre o interfață expusă la internet cu un ruleset standard și îți va povesti, individual și pe larg, despre fiecare pachet care îl deranjează. Semnalul e acolo — dar atenția nimănui nu supraviețuiește volumului.

meerkat este răspunsul nostru, acum open source sub licența 0BSD. Este numit după Suricata suricatta — suricata, santinela care stă de veghe și dă alarma. Rulează pe router, lângă Suricata însuși, iar pagina lui principală nu este o listă de evenimente. Este o listă de adrese sursă.

Argumentul, cu cifre

Iată o fereastră de patru minute măsurată pe un router de edge în producție: 891 de alerte, defalcate pe categorii:

pondere	categorie	ce este
68.8%	ET CINS	„sursa e pe o listă de reputație”
16.3%	ET DROP	blocklist-ul Dshield, aceeași idee
10.6%	GPL ICMP	cineva dă ping
2.6%	SURICATA	evenimente ale motorului (ack invalid, checksum-uri)
1.4%	ET SCAN	scanare reală
0.3%	ET COMPROMISED	indicator real de compromitere

Am încercat să trimitem asta într-un canal de chat. A inundat canalul în câteva minute, iar cele două categorii care contează cu adevărat — ultimele două rânduri — au defilat necitite laolaltă cu restul.

Lecția tentantă este „filtrează mai agresiv”. Noi credem că e lecția greșită. Volumul nu este un bug în ruleset; hit-urile din feed-urile de reputație chiar merită înregistrate, doar că nu merită câte o notificare individuală fiecare. Lecția reală este că un canal de chat este unealta greșită. Un flux de alerte răspunde la „ce tocmai s-a întâmplat?” — dar întrebarea pe care o are de fapt un operator este „cine îmi face ceva și ce am de gând să fac în privința lui?”

Agregate per adresă sursă, cele 891 de rânduri devin câteva zeci. Fiecare rând este o decizie: blochezi, confirmi, pui pe allowlist sau ignori. Acesta e tot produsul. Tot restul decurge de aici.

Ce face

meerkat urmărește eve.json-ul lui Suricata, îmbogățește fiecare alertă cu ASN, țară și oraș și stochează totul în SQLite pe mașină. UI-ul web oferă:

• Surse, agregate — prima și ultima apariție, numărul de alerte, ce semnături s-au declanșat, ce porturi au fost sondate, cea mai gravă severitate și starea curentă. Filtrezi după țară, AS, port, semnătură, severitate, stare, fereastră de timp sau volum minim.
• O sursă, tot ce se știe — intri în detaliul unei adrese și vezi ce a declanșat, când, pe ce porturi și ce a făcut un operator în privința ei, pe o cronologie.
• Acțiuni cu responsabilitate — blochezi, deblochezi, confirmi sau pui pe allowlist, o sursă sau în bloc, întotdeauna cu un motiv și o expirare.
• Un ruleset cu care poți raționa — întregul catalog Suricata instalat, corelat cu cât te-a costat de fapt fiecare regulă în volum de alerte. Activezi sau dezactivezi o regulă sau o categorie, suprascrii o severitate, setezi dispoziții per semnătură — notify, digest sau mute pentru feed-urile de reputație, dintr-un singur click. Schimbările sunt aplicate prin reconstruire cu suricata-update și reload live, apoi recitite de pe disc, astfel încât UI-ul reflectă ce rulează cu adevărat senzorul.

De ce un block este un apel nftables, niciodată un drop în Suricata

meerkat poate bloca o sursă, dar n-o face niciodată comutând o regulă Suricata pe drop. Blocarea este un apel către nftables, firewall-ul care este deja în calea traficului.

Credem că această separare este corectă și merită să avem o opinie fermă despre ea:

• Senzorul rămâne senzor. În momentul în care Suricata devine punctul de aplicare, fiecare reload de ruleset este o schimbare care afectează traficul și fiecare sughiț al motorului este o cădere. Detecția și aplicarea au cerințe de fiabilitate diferite; cuplarea lor înseamnă că ambele moștenesc ce e mai rău din fiecare.
• Blocările rămân auditabile. O regulă de firewall creată cu un motiv și o expirare este o acțiune de operator pe care o poți lista, revizui și anula. Un drop îngropat într-un ruleset de 40.000 de semnături nu este.
• Firewall-ul se pricepe mai bine. A arunca traficul de la o adresă este o decizie de kernel de o linie. Să ceri unui motor de deep packet inspection să facă o treabă pe care o poate face un lookup într-un set este din nou unealta greșită — aceeași greșeală ca la canalul de chat, în direcția opusă.

Mic, local, pe router

Ca restul tooling-ului nostru, meerkat este un singur binar Go care rulează pe routerul însuși — fără agent, fără cloud, fără pipeline care să-ți trimită datele de alerte în SIEM-ul altcuiva înainte să le poți citi. Datele rămân pe mașina care le-a produs, ceea ce înseamnă și că funcționează bine pe uplink-urile contorizate sau modeste unde trăiesc de fapt routerele de edge.

Este software beta. Așteaptă-te la bug-uri; nu a avut încă testarea pe care o merită o piesă de infrastructură de securitate. Citește avertismentele din README înainte să-l instalezi.

Dacă vrei să vezi cum arată în practică această clasă de date de edge, harta noastră publică de amenințări arată detecțiile de la marginea AS210622.

Cum a fost construit

meerkat este a treia unealtă pe care am livrat-o anul acesta cu agenți de AI coding scriind cea mai mare parte a implementării sub design și review umane. Judecățile de bază — surse în loc de evenimente, nftables în loc de drop-uri în Suricata, SQLite pe mașină în loc de un backend în cloud — au fost luate de oameni; agenții au făcut construirea destul de rapidă ca să merite efortul. Povestea completă este în studiul nostru de caz despre construirea a trei unelte cu agentic development.

Concluzii

1. Agregă la unitatea de decizie. Operatorii decid despre surse, nu despre pachete — așa că prima pagină a UI-ului este cea cu surse.
2. Volumul este și el o informație. Hit-urile din feed-urile de reputație au locul în baza de date, nu în notificările tale.
3. Ține detecția și aplicarea separate. Senzorul veghează; firewall-ul blochează; fiecare își face treaba bine.

Dacă edge-ul tău e zgomotos și nimeni nu citește de fapt alertele, te putem ajuta — iar dacă rulezi Suricata pe un router pe undeva, încearcă meerkat și spune-ne ce se strică.