Introducció

Què és lippycat?

lippycat és una eina de captura i anàlisi del trànsit de xarxa creada per a infraestructures modernes. Captura paquets d’interfícies de xarxa o de fitxers PCAP i ofereix modes CLI i TUI (interfície d’usuari de terminal) per al monitoratge i l’anàlisi en temps real.

Mentre que eines tradicionals com tcpdump ofereixen bolcats de paquets en brut i Wireshark necessita una interfície gràfica, lippycat omple aquest buit: anàlisi que té en compte els protocols amb la comoditat d’una interfície de terminal, i captura distribuïda quan una sola màquina no és suficient.

Casos d’ús

Monitoratge de xarxa Captureu i analitzeu el trànsit de qualsevol interfície. Filtreu per protocol, amfitrió, port o expressions BPF personalitzades. Escriviu fitxers PCAP per a l’anàlisi fora de línia.

Anàlisi de VoIP Feu el seguiment de les trucades SIP d’extrem a extrem, correlacioneu fluxos RTP i escriviu fitxers PCAP per trucada. Superviseu les mètriques de qualitat de les trucades i detecteu problemes en temps real.

Monitoratge de seguretat Inspeccioneu les negociacions TLS, detecteu anomalies dels protocols i captureu trànsit per a l’anàlisi forense. Admet la desencapsulació ESP-NULL per inspeccionar túnels xifrats.

Captura distribuïda Desplegueu nodes Hunter lleugers en diversos segments de xarxa i agregueu el trànsit en un processador central. Superviseu-ho tot des d’una única TUI.

Comparació amb eines semblants

lippycat se centra en els protocols DNS, TLS, HTTP, correu electrònic, RADIUS i VoIP, amb una anàlisi detallada de cadascun.

Quan convé utilitzar lippycat en lloc d’altres opcions:

• Necessiteu captura distribuïda en diversos segments de xarxa
• Voleu monitoratge interactiu al terminal (sense interfície gràfica)
• Analitzeu trànsit VoIP i voleu fitxers PCAP per trucada
• Necessiteu desplegar agents de captura en servidors sense interfície gràfica

Quan convé utilitzar altres opcions:

• Necessiteu analitzar protocols poc habituals o propietaris (Wireshark)
• Necessiteu un bolcat ràpid de paquets amb una sola línia d’ordres (tcpdump)
• Necessiteu estadístiques àmplies de protocols (tshark)

Visió general de les ordres

lippycat segueix un patró coherent [verb] [object]:

lc [verb] [object] [flags]

L’itinerari d’aprenentatge d’aquest manual segueix una complexitat progressiva:

graph LR
    sniff["lc sniff"]
    watch["lc watch"]
    hunt["lc hunt"]
    process["lc process"]
    tap["lc tap"]
    remote["lc watch remote"]

    sniff --> watch --> hunt --> process --> tap --> remote

    subgraph Local
        sniff
        watch
    end

    subgraph Distributed
        hunt
        process
        tap
        remote
    end

Cada ordre es basa en conceptes de l’anterior; per això, llegir el manual en ordre facilita l’aprenentatge.

Conceptes bàsics

Aquest capítol tracta els conceptes fonamentals que cal entendre abans de capturar trànsit amb lippycat. Si ja coneixeu la captura de paquets (per exemple, per experiència amb tcpdump o Wireshark), podeu llegir-lo per sobre i continuar amb Instal·lació i configuració.

Paquets i protocols

El trànsit de xarxa es compon de paquets, unitats de dades discretes que s’envien entre amfitrions. Cada paquet conté capes de protocol imbricades:

Ethernet → IP → TCP/UDP → Application (HTTP, SIP, DNS, ...)

lippycat captura paquets a la capa d’enllaç i analitza cada capa de protocol, extraient informació significativa segons el mode de protocol que utilitzeu.

Protocols que analitza lippycat

Interfícies de xarxa

Una interfície de xarxa és el punt on la vostra màquina es connecta a una xarxa. Exemples habituals:

• eth0 / ens33 — Ethernet per cable
• wlan0 — Sense fil
• lo — Bucle local (només trànsit local)
• any — Captura simultània en totes les interfícies

Per veure les interfícies disponibles:

lc list interfaces

Permisos de captura

La captura de paquets requereix privilegis elevats perquè implica llegir tot el trànsit d’una interfície, i no només el destinat a la vostra aplicació.

Opció 1: executar com a root

sudo lc sniff -i eth0

Opció 2: concedir una capacitat (recomanada per a producció)

sudo setcap cap_net_raw+ep /usr/local/bin/lc

Això concedeix únicament la capacitat específica necessària, d’acord amb el principi de privilegi mínim.

Filtres BPF

Els Berkeley Packet Filters (BPF) permeten indicar al nucli quins paquets ha de capturar, reduint la càrrega de CPU mitjançant el filtratge al nivell més baix, abans que els paquets arribin a l’espai d’usuari.

Capturar només trànsit DNS:

lc sniff -i eth0 -f "port 53"

Capturar només trànsit cap a un amfitrió concret o des d’aquest:

lc sniff -i eth0 -f "host 10.0.0.1"

Combinar filtres:

lc sniff -i eth0 -f "host 10.0.0.1 and port 5060"

Els filtres BPF utilitzen una sintaxi estàndard compartida amb tcpdump i Wireshark. Consulteu l’Apèndix C: referència de filtres BPF per veure patrons habituals.

Format PCAP

PCAP (Packet Capture) és el format de fitxer estàndard per emmagatzemar paquets capturats. Els fitxers escrits per lippycat es poden obrir amb Wireshark, analitzar amb tshark o reproduir amb tcpreplay.

Escriure els paquets capturats en un fitxer:

lc sniff -i eth0 -w capture.pcap

Llegir un fitxer PCAP a la TUI:

lc watch file capture.pcap

lippycat admet diversos modes d’escriptura de PCAP:

• PCAP unificat — Tots els paquets en un fitxer
• PCAP per trucada — Un fitxer per trucada VoIP (SIP Call-ID)
• PCAP amb rotació automàtica — Fitxer nou en arribar a un llindar de mida o temps

Anàlisi de protocols

Més enllà de la simple captura de paquets, lippycat fa anàlisi de protocols: entén l’estructura i la semàntica dels protocols que supervisa:

• DNS: analitza els tipus de consulta, els codis de resposta i les dades dels registres
• TLS: extreu SNI, cadenes de certificats, negociació de xifratge i empremtes JA3/JA3S/JA4
• VoIP: segueix els diàlegs SIP, correlaciona fluxos RTP i calcula mètriques de qualitat de les trucades
• HTTP: reconstrueix parelles de petició/resposta dels fluxos TCP (amb desxifratge TLS opcional)
• Correu electrònic: segueix sessions SMTP, IMAP i POP3 amb correlació de remitent/destinatari
• RADIUS: descodifica missatges UDP visibles d’autenticació/comptabilització i associa respostes amb peticions

Aquesta anàlisi es fa en temps real durant la captura i es mostra tant al mode CLI com al mode TUI.

El model distribuït

lippycat pot funcionar com un sistema distribuït per capturar trànsit en diversos segments de xarxa:

graph LR
    h1["Hunter<br>(edge)"]
    h2["Hunter<br>(edge)"]
    p["Processor<br>(central)"]
    out["TUI / PCAP / Analysis"]

    h1 -->|gRPC| p
    h2 -->|gRPC| p
    p --> out

• Els nodes Hunter capturen paquets a la perifèria de la xarxa i els transmeten mitjançant gRPC
• Els processadors reben, agreguen i analitzen paquets de diversos nodes Hunter
• Tap combina tots dos rols per a desplegaments en una sola màquina

Aquesta arquitectura es tracta detalladament a la Part III: captura distribuïda. De moment, n’hi ha prou amb saber que tots els conceptes de captura local (interfícies, filtres, protocols) també s’apliquen al mode distribuït.

Instal·lació i configuració

Compilació des del codi font

Requisits:

• Go 1.25 o posterior
• Make
• Capçaleres de desenvolupament de libpcap (libpcap-dev a Debian/Ubuntu, libpcap-devel a RHEL/Fedora)

Clonar el repositori:

git clone https://github.com/endorses/lippycat.git

Entrar al directori del projecte:

cd lippycat

Crear una compilació de desenvolupament (conjunt complet, amb símbols de depuració):

make build

Alternativament, crear una compilació de publicació optimitzada (sense símbols):

make build-release

Per a una compilació ràpida de desenvolupament sense informació de versió:

make dev

Compilacions especialitzades

lippycat utilitza etiquetes de compilació de Go per crear binaris més petits i especialitzats. Si només necessiteu un subconjunt de funcions:

Compilar totes les variants a bin/:

make binaries

Per a la majoria d’usuaris, el conjunt complet (make build) és l’opció més senzilla. Les compilacions especialitzades són útils per a desplegaments de producció en què voleu binaris mínims a cada node.

Acceleració GPU

Per a acceleració GPU amb CUDA (requereix GPU NVIDIA i el conjunt d’eines CUDA):

make build-cuda

Consulteu Optimització del rendiment per obtenir detalls sobre els motors GPU.

Objectius d’instal·lació

Instal·lar a $GOPATH/bin:

make install

Instal·lar per a tot el sistema a /usr/local/bin (requereix sudo):

make install-system

Permisos

La captura de paquets requereix accés a sòcols de xarxa en brut. Teniu dues opcions:

Opció 1: executar amb sudo

L’opció més senzilla per a desenvolupament i proves:

sudo lc sniff -i eth0

Opció 2: capacitats de Linux (recomanada)

Concedir només la capacitat específica necessària:

sudo setcap cap_net_raw+ep $(which lc)

Després d’això, lc pot capturar sense sudo:

lc sniff -i eth0

Nota: la capacitat s’assigna al fitxer binari. Si el torneu a compilar i el sobreescriviu, heu d’assignar-li la capacitat de nou.

Configuració

lippycat cerca un fitxer de configuració YAML en aquestes ubicacions (per ordre de prioritat):

1. $HOME/.config/lippycat/config.yaml (preferida)
2. $HOME/.config/lippycat.yaml (estàndard XDG)
3. $HOME/.lippycat.yaml (heretada)

Ordre de prioritat (guanya la més alta):

CLI flags > Environment variables > Config file > Defaults

Exemple de configuració:

# PCAP read timeout (ms)
pcap_timeout_ms: 200

# Promiscuous mode
promiscuous: false

# DNS settings
dns:
  ports: "53"
  track_queries: true
  detect_tunneling: true

# VoIP settings
voip:
  tcp_performance_mode: balanced

L’arrel del repositori inclou un example-config.yaml complet amb totes les opcions disponibles documentades. Consulteu l’Apèndix B: referència de configuració per veure l’esquema complet.

Variables d’entorn

Verificació de la instal·lació

Després de la instal·lació, verifiqueu que tot funciona:

Comprovar la versió:

lc version

Llistar les interfícies de xarxa disponibles:

lc list interfaces

Mostrar la configuració actual:

lc show config

Si lc list interfaces mostra les vostres interfícies de xarxa, ja podeu començar a capturar. Continueu amb Captura CLI amb lc sniff.

Captura CLI amb lc sniff

lc sniff és la base de lippycat: una eina CLI de captura de paquets semblant a tcpdump o tshark, amb anàlisi de protocols integrada i compatibilitat amb VoIP.

La vostra primera captura

Selecció d’una interfície

Primer, esbrineu quines interfícies estan disponibles:

lc list interfaces

Això mostra les interfícies de captura amb el tipus, l’estat operatiu i les adreces IP, incloent-hi el bucle local, interfícies VPN/túnel i interfícies inactives. Una indicació de la ruta per defecte, quan està disponible, ajuda a identificar les interfícies de sortida de l’amfitrió. Trieu la interfície connectada a la xarxa que voleu supervisar. Utilitzeu --json per obtenir metadades estructurades o --names per obtenir un nom d’interfície per línia.

Consell: utilitzeu lc list interfaces --all per incloure ponts reconeguts, enllaços de contenidors/VM i fonts especials de captura ocultes a la vista per defecte. Utilitzeu --check per provar breument l’accés de captura sense mode promiscu ni lectura de paquets; s’ometen les fonts especials de captura. El llistat per si sol no comprova els permisos.

Captura bàsica

Iniciar la captura en una interfície:

sudo lc sniff -i eth0

La interfície per defecte és any (totes les interfícies). Podeu indicar diverses interfícies separades per comes:

sudo lc sniff -i eth0,eth1

Premeu Ctrl+C per aturar la captura. lippycat mostra un resum dels paquets capturats.

Format de sortida

lc sniff escriu cada paquet capturat a stdout com una línia de JSON. Això facilita passar-lo a jq, grep o altres eines. Canvieu al format de text per obtenir una sortida fàcil de llegir:

sudo lc sniff -i eth0 --format text

Consulteu Treballar amb la sortida JSON per canalitzar, filtrar i desar la sortida de paquets.

Utilitzeu -q (mode silenciós) per suprimir la sortida de paquets i millorar el rendiment quan només necessiteu fitxers PCAP.

Filtratge bàsic

Utilitzeu filtres BPF amb -f / --filter per centrar-vos en trànsit concret (consulteu l’Apèndix C: referència de filtres BPF per veure la sintaxi completa):

Capturar només trànsit DNS:

sudo lc sniff -i eth0 -f "port 53"

Capturar trànsit cap a un amfitrió concret o des d’aquest:

sudo lc sniff -i eth0 -f "host 10.0.0.1"

Capturar només trànsit TCP al port 5060 (SIP):

sudo lc sniff -i eth0 -f "tcp port 5060"

Combinar condicions:

sudo lc sniff -i eth0 -f "host 10.0.0.1 and port 5060"

Mode promiscu

Per defecte, la interfície només captura trànsit destinat a la vostra màquina. Activeu el mode promiscu per veure tot el trànsit del segment:

sudo lc sniff -i eth0 -p

Lectura de fitxers PCAP

Analitzar fitxers PCAP existents en lloc d’interfícies en viu:

lc sniff -r capture.pcap

No calen privilegis elevats per llegir fitxers.

Registres estructurats de protocols

Establiu --log-dir per escriure fitxers de protocols normalitzats tot mantenint la sortida de paquets existent a stdout. Aquestes opcions de l’ordre pare funcionen amb totes les subordres de protocol:

lc sniff http -r capture.pcap --log-dir ./logs --log-streams conn,http,files

El registre està desactivat per defecte. La sortida és TSV d’estil Zeek per defecte, o JSONL amb --log-format json. Les cues són limitades: ateneu els avisos de descart i utilitzeu una aturada ordenada per buidar els buffers als fitxers. Consulteu Registres estructurats de protocols per veure tots els esquemes, les opcions, la rotació, la semàntica de completesa i les indicacions de privadesa.

Treballar amb la sortida JSON

Tots els analitzadors de protocols comparteixen la mateixa estructura de sortida JSON basada en PacketDisplay. Cada paquet té camps comuns (marca de temps, IP i port d’origen/destinació, protocol, longitud) i un objecte opcional de metadades específiques del protocol (VoIPData, DNSData, TLSData, HTTPData, EmailData o RADIUSData).

Separació de stdout i stderr

lippycat segueix les convencions Unix: les dades de paquets van a stdout i els missatges de registre a stderr. Això permet canalitzar les dades de paquets de manera neta sense deixar de veure els registres:

Canalitzar els paquets cap a jq mantenint els registres visibles al terminal:

sudo lc sniff dns -i eth0 | jq '.DNSData.QueryName'

Redirigir els registres a un fitxer i canalitzar els paquets per processar-los:

sudo lc sniff dns -i eth0 2>dns-capture.log | jq '.DNSData.QueryName'

Descartar completament els registres:

sudo lc sniff dns -i eth0 2>/dev/null | jq '.DNSData.QueryName'

Anàlisi entre protocols

Com que tots els protocols comparteixen els mateixos camps bàsics, podeu capturar sense una subordre de protocol i filtrar per metadades específiques de protocol amb jq:

Capturar trànsit general i després filtrar DNS i TLS:

sudo lc sniff -i eth0 2>/dev/null | \
  jq -r 'if .DNSData then
    "DNS: " + .DNSData.QueryName
  elif .TLSData then
    "TLS: " + (.TLSData.SNI // "no-sni")
  else empty end'

Desament i reproducció

Combineu la sortida JSON amb l’escriptura PCAP per obtenir anàlisi estructurada i fidelitat completa dels paquets:

Escriure PCAP i JSON simultàniament:

sudo lc sniff dns -i eth0 -w dns-traffic.pcap 2>/dev/null > dns-analysis.jsonl

Reproduir el PCAP més tard amb un analitzador de protocol diferent:

lc sniff tls -r dns-traffic.pcap

El fitxer PCAP conté els paquets en brut i es pot tornar a analitzar amb qualsevol subordre de protocol o obrir amb Wireshark.

Modes de protocol

lc sniff té subordres específiques de protocol que permeten una anàlisi detallada. Cadascuna afegeix filtratge, correlació i sortida adaptats al protocol.

Anàlisi de DNS

sudo lc sniff dns -i eth0

Captura consultes i respostes DNS amb correlació de consulta/resposta i seguiment del temps de resposta.

Opcions principals:

Inspecció de TLS

sudo lc sniff tls -i eth0

Analitza negociacions TLS sense desxifrar el trànsit. Extreu SNI, detalls de certificats, conjunts de xifratge i empremtes TLS.

Opcions principals:

Cada opció d’empremta té una variant -file corresponent per a la càrrega massiva des de fitxers.

Captura HTTP

sudo lc sniff http -i eth0

Reconstrueix parelles de petició/resposta HTTP dels fluxos TCP amb mesurament de RTT.

Opcions principals:

Cada opció de patró té una variant -file corresponent per a la càrrega massiva (p. ex., --hosts-file, --paths-file). La cerca massiva de paraules clau utilitza l’algoritme Aho-Corasick mitjançant --keywords-file.

Monitoratge de correu electrònic

sudo lc sniff email -i eth0

Captura sessions SMTP, IMAP i POP3 amb seguiment de sessions.

Opcions principals:

Autenticació i comptabilització RADIUS

sudo lc sniff radius -i eth0

Captura missatges UDP RADIUS visibles d’autenticació i comptabilització, associa respostes amb peticions observades i elimina els atributs que contenen credencials de la sortida habitual. Quan calgui, restringiu la captura a un compte exacte o a una identitat de línia vinculada al desplegament:

sudo lc sniff radius -i eth0 --radius-username 'alice@example.test'

Opcions principals:

El capítol de captura RADIUS i POI documenta totes les opcions compartides, la vinculació d’àmbit, els límits d’estat i el lliurament LI opcional.

Anàlisi de VoIP

VoIP és el mode de protocol de lippycat amb més funcions:

Iniciar una captura VoIP bàsica:

sudo lc sniff voip -i eth0

Filtrar per un usuari SIP (s’admeten comodins):

sudo lc sniff voip -i eth0 -u alicent

Utilitzar una coincidència de sufix:

sudo lc sniff voip -i eth0 -u "*456789"

Filtrar diversos usuaris:

sudo lc sniff voip -i eth0 -u "alicent,robb"

Restringir la captura a un port SIP concret:

sudo lc sniff voip -i eth0 -S 5060

Utilitzar un interval de ports RTP personalitzat:

sudo lc sniff voip -i eth0 -R 8000-9000

Opcions principals:

Desencapsulació ESP-NULL

La desencapsulació ESP està desactivada per defecte: sense --esp-null o --esp-heuristic, els paquets ESP es transmeten intactes i el filtre BPF de VoIP no els admet.

Activeu-la per al trànsit VoIP dins de túnels ESP-NULL (habituals en desplegaments IPsec on el xifratge està desactivat però es manté l’emmarcament ESP):

sudo lc sniff voip -i eth0 --esp-null --esp-icv-size 12

lippycat elimina la capçalera ESP i el tràiler ICV, exposant els paquets UDP/SIP/RTP interns per a l’anàlisi normal. Amb --esp-icv-size -1 (valor per defecte), la mida ICV es detecta automàticament.

--esp-heuristic identifica ESP-NULL inspeccionant el contingut de la càrrega útil en lloc del tràiler ESP. Preferiu --esp-null quan se sap que la SA utilitza xifratge NULL: en SA realment xifrades, l’heurística de contingut pot confondre text xifrat amb trànsit intern.

Sortida de fitxers PCAP

Escriptura de fitxers PCAP

Desar els paquets capturats per a l’anàlisi fora de línia amb -w:

sudo lc sniff -i eth0 -w capture.pcap

El fitxer resultant es pot obrir amb Wireshark, analitzar amb tshark o tornar a llegir amb lc watch file.

Cada subordre de protocol també admet -w:

Per a DNS:

sudo lc sniff dns -i eth0 -w dns-traffic.pcap

Per a VoIP:

sudo lc sniff voip -i eth0 -w voip-traffic.pcap

PCAP per trucada (VoIP)

En mode VoIP, l’opció -w crea automàticament fitxers PCAP separats per trucada, dividits entre senyalització SIP i contingut multimèdia RTP:

sudo lc sniff voip -i eth0 --sip-user alicent -w /var/capture/alicent

Això crea /var/capture/alicent_sip_<callid>.pcap i /var/capture/alicent_rtp_<callid>.pcap.

Per veure funcions més avançades de PCAP per trucada (organització de directoris, patrons de nom de fitxer i accions de finalització), consulteu Agregació central amb lc process i Mode autònom amb lc tap.

Ajust del rendiment

Modes de rendiment TCP

El reassemblatge TCP és necessari per a SIP sobre TCP i HTTP. lippycat ofereix perfils de rendiment preconfigurats mitjançant -M / --tcp-performance-mode:

sudo lc sniff voip -i eth0 -M throughput

Per a un control detallat, es poden ajustar paràmetres TCP individuals (límits de goroutines, mides de buffer, temps d’espera). Consulteu lc sniff voip --help per veure la llista completa.

Restricció de ports

En xarxes amb molt trànsit TCP, utilitzeu restriccions explícites de ports SIP i RTP per centrar la captura tot permetent SIP sobre TCP quan n’hi hagi:

sudo lc sniff voip -i eth0 -S 5060 -R 10000-20000

L’antiga opció VoIP --udp-only encara s’accepta per compatibilitat, però està oculta i és obsoleta perquè pot ometre trànsit SIP TCP.

Acceleració GPU

Traslladar la comparació de patrons dels filtres d’aplicació a CUDA per a captures d’alt cabal:

sudo lc sniff voip -i eth0 -g auto

Les opcions GPU de sniff voip només es registren en compilacions CUDA, com ara binaris compilats amb make build-cuda.

Actualment OpenCL no està implementat. El valor s’accepta per compatibilitat de configuració, però es recorre a la comparació amb CPU. L’anàlisi de SIP i l’extracció de Call-ID també es mantenen a la CPU.

Consulteu Optimització del rendiment per veure la configuració GPU i les proves de rendiment.

Injecció en una interfície virtual

Injectar paquets filtrats en una interfície de xarxa virtual perquè altres eines els utilitzin:

sudo lc sniff voip -i eth0 -V --vif-name lc0

Això crea una interfície TAP lc0 des de la qual altres eines (Wireshark, tcpdump) poden capturar, veient només el trànsit filtrat seleccionat per lippycat.

Captura interactiva amb lc watch

lc watch ofereix una interfície d’usuari de terminal (TUI) interactiva per al monitoratge de paquets en temps real. Si lc sniff és com tcpdump, lc watch és com Wireshark, però al vostre terminal.

Mode de captura en viu

Inici de la captura en viu

Iniciar la captura en viu en el mode per defecte:

sudo lc watch

Especificar explícitament el mode en viu:

sudo lc watch live

Capturar en una interfície concreta amb un filtre BPF:

sudo lc watch live -i eth0 -f "port 5060"

Activar el mode promiscu:

sudo lc watch live -i eth0 -p

Opcions principals:

Disposició de la TUI

La interfície s’organitza en cinc pestanyes:

Dreceres de teclat globals

Funcionen en qualsevol pestanya:

Navegació a la pestanya Capture

La pestanya Capture és la vista principal. Navegueu amb tecles d’estil vim:

Filtratge a la TUI

Premeu / a la pestanya Capture per entrar al mode de filtre. Escriviu una expressió de filtre i premeu Enter per aplicar-la.

Tipus de filtre:

Gestió de filtres:

Modes de vista

Premeu v per alternar entre vistes específiques de protocol:

RADIUS no té una vista agregada separada. Les seves metadades descodificades, amb les credencials eliminades, apareixen a la llista normal de paquets i al panell de detalls en sessions en viu i de fitxer.

Anàlisi de fitxers PCAP

Obertura de fitxers PCAP

Analitzar trànsit capturat prèviament, sense privilegis elevats:

Obrir un sol fitxer PCAP:

lc watch file capture.pcap

Obrir diversos fitxers PCAP en una vista combinada:

lc watch file sip.pcap rtp.pcap signaling.pcap

En obrir diversos fitxers, els paquets es combinen i es mostren per ordre de marca de temps.

L’obertura indexa tots els paquets lògics acceptats en un emmagatzematge temporal privat. El diàleg de progrés mostra les fases de lectura, ordenació i indexació, el nombre de fonts, els paquets/bytes lògics, el temps transcorregut i l’ús temporal de disc. Escape cancel·la i espera la neteja; si la substitució falla o es cancel·la, es conserva el conjunt de dades anterior que ja estava preparat. La navegació comença només després que l’anàlisi finalitzi correctament. El BPF d’entrada (-f) s’aplica abans de la indexació; el reassemblatge i la desencapsulació poden modificar els paquets lògics respecte dels registres originals.

Cada paquet indexat continua sent navegable, filtrable i exportable després de l’expulsió de la memòria cau. watch.buffer_size / --buffer-size limita els anells de paquets en viu/remots i l’historial d’esdeveniments retingut, no la completesa dels paquets fora de línia. La capçalera mostra el total de paquets; Statistics separa el total i els paquets coincidents de les files/bytes en cau i dels bytes d’índex. La zona inferior es reserva per a notificacions. Les estadístiques globals i de coincidències cobreixen tot el conjunt de dades/consulta; les estimacions limitades d’extrems s’etiqueten per separat. Els esdeveniments i les trucades continuen tenint historials retinguts limitats; els seus filtres no ofereixen l’historial complet d’esdeveniments o trucades del fitxer.

Els filtres interactius de paquets recorren tot el conjunt de dades de manera asíncrona. Escape cancel·la el recorregut. Si falla o es cancel·la, es conserven l’última consulta completada, les etiquetes dels filtres i les estadístiques. Eliminar o buidar els filtres també consulta tot el conjunt de dades.

S’admeten marques de temps que retrocedeixen: els paquets lògics normalitzats s’ordenen al disc abans de l’anàlisi amb estat, preservant les marques de temps i utilitzant primer l’ordre dels arguments i després la seqüència original de cada font per desfer empats. L’ordenació utilitza memòria limitada i comparteix el pressupost de disc configurat amb els conjunts de dades i les consultes. Les entrades malformades, el disc ple i un BPF invàlid fan fallar l’obertura sense publicar resultats parcials. S’admeten fins a 64 fonts de fitxer regular; es poden combinar fitxers PCAP i PCAPNG d’una sola secció i interfície. Dividiu les captures PCAPNG amb diverses seccions/interfícies abans d’obrir-les.

Opcions del mode de fitxer:

Aquestes opcions sobreescriuen les claus de configuració watch.offline.*. També s’apliquen en passar al mode fora de línia mitjançant Settings o un diàleg de fitxer. Sortiu del mode fora de línia abans de canviar els pressupostos de recursos. El camp de buffer de Settings correspon als anells de paquets en viu/remots i a l’historial d’esdeveniments retingut; configureu l’emmagatzematge fora de línia amb les opcions o claus YAML anteriors.

El còmput de disc inclou resums, detalls, desplaçaments, manifests i fitxers de consulta; els conjunts de dades preparat i de substitució comparteixen el pressupost. Reserveu espai per a tots dos durant la substitució i per als vectors de consulta filtrada; les consultes on tot coincideix utilitzen identificadors implícits. L’emmagatzematge normalitzat pot superar la mida de la font. L’esgotament físic del disc, els límits de pressupost configurats i els errors de permisos provoquen errors explícits, preservant l’últim conjunt de dades/consulta completat. Allibereu espai o canvieu el directori/pressupost i torneu-ho a provar. Els fitxers temporals propis s’eliminen en cancel·lar/aturar; els errors de neteja continuen visibles per tornar-ho a provar. El pressupost de cau no és un límit RSS del procés: la memòria del lector/reassemblatge, l’analitzador, els esdeveniments/trucades retinguts i l’entorn d’execució Go és addicional. El text en clar TLS fora de línia té un límit separat de 16 MiB; superar-lo fa fallar la indexació.

L’emmagatzematge de fitxers fora de línia manté metadades compactes cercables i llegeix els bytes de paquet inalterats dels fitxers oberts originalment. Manteniu les entrades sense canvis fins que acabin la sessió i les exportacions: editar-les o truncar-les fa fallar explícitament les lectures. Un camí substituït mai no subministra bytes a una sessió existent. Reanomenar o desenllaçar pot conservar l’accés mitjançant el descriptor propi quan el sistema operatiu ho admet.

Trieu --offline-backing-policy snapshot per crear còpies privades validades de les entrades abans d’indexar-les. La seva mida completa compta contra el pressupost de disc. El PCAP clàssic comprimit amb gzip també necessita un suport descomprimit; els paquets transformats conserven els seus bytes efectius per separat. No hi ha cap recurs automàtic a snapshots després d’un error de font. La política queda fixada per a cada obertura. La navegació i els filtres d’aplicació només estan disponibles quan l’anàlisi ordenada completa i les seves metadades finals estan preparades.

Premeu w per exportar l’última consulta de coincidències completada (o tots els paquets si no hi ha filtre de paquets). L’exportació transmet una instantània fixa a PCAP de nanosegons, preservant els bytes en brut normalitzats, el tipus d’enllaç efectiu, les marques de temps i les longituds capturades/originals. Es rebutgen els tipus d’enllaç efectius mixtos; exporteu aquestes entrades per separat. Les marques de temps absents o fora de l’interval de segons Unix de 32 bits sense signe també provoquen errors explícits. Les consultes buides indiquen que no hi ha paquets per desar. Escape cancel·la l’exportació. La destinació només se substitueix atòmicament si l’operació té èxit; la cancel·lació o els errors preserven una destinació existent i eliminen la sortida temporal. L’exportació requereix espai lliure addicional al costat de la destinació, fora del pressupost de disc de la sessió.

Desxifratge TLS

Si teniu un fitxer de registre de claus TLS (p. ex., de la variable d’entorn SSLKEYLOGFILE), podeu desxifrar trànsit HTTPS durant l’anàlisi de fitxers:

lc watch file capture.pcap --tls-keylog keys.log

Funcions de la TUI

Diàlegs clicables

Els diàlegs admeten entrada de ratolí i teclat. Feu clic en un botó habilitat per actuar, o utilitzeu Tab / Shift+Tab per donar el focus als controls i Enter / Space per activar un botó amb focus. Feu clic als camps de text per editar-los. La barra d’accions es distribueix en diverses línies en terminals estrets; utilitzeu la roda sobre una llista per desplaçar-la. Fer clic fora d’un diàleg només cancel·la la seva capa visible.

Al selector de protocol, feu clic en una fila i trieu Apply, o feu doble clic a la fila per aplicar-la. La descripció es manté sota la llista perquè la selecció no mogui les altres files.

Els diàlegs de fitxer ofereixen segments del camí clicables i controls Up, New folder i Show details. Un clic selecciona una fila; Open obre un fitxer o entra en un directori. Fer doble clic també entra en un directori o obre un fitxer en mode d’obertura. Feu clic al camp de cerca o de nom de fitxer per editar-lo; Cancel edit abandona l’edició en línia, mentre que Cancel tanca el diàleg. Els mateixos controls s’apliquen als selectors de fitxer de Settings.

En mode de desament, seleccionar un fitxer existent omple el seu nom i fer doble clic dona el focus al nom de fitxer sense desar. Trieu Save per enviar el nom de fitxer. Si la destinació existeix, Replace confirma la sobreescriptura i Keep editing torna al diàleg de fitxer conservant el nom.

Els diàlegs d’obertura i filtratge fora de línia ofereixen Cancel i continuen visibles mentre acaba la neteja. No es pot tornar a sol·licitar la cancel·lació mentre està en curs. Si la neteja falla, Retry cleanup i Quit estan disponibles allà on s’ofereixen.

Pestanya Statistics

Premeu Alt+3 per veure estadístiques de trànsit en temps real:

• Distribució de protocols i recomptes de paquets
• Taxes de trànsit
• Estadístiques de nodes distribuïts (quan es connecta a processadors)

La vista de detalls dels paquets és deliberadament limitada durant la captura en viu. Els comptadors exactes d’entrada continuen comptant cada paquet vàlid, mentre que el canal de detalls pot mostrejar paquets, descartar un lot de detalls en cua o expulsar el paquet més antic del seu anell pendent per mantenir visibles els diagnòstics més recents. La pestanya Statistics mostra aquestes etapes per separat com Sampled Out, Batch Queue Drops i Pending Evictions. Packets Delivered i el seu percentatge retingut mesuren la retenció de detalls d’extrem a extrem des de l’entrada vàlida de la TUI; no mesuren la integritat de la captura ni els paquets escrits a PCAP.

Els paquets SIP reconeguts eviten el mostreig adaptatiu de detalls, però encara es poden perdre a les etapes posteriors de cua de lots o anell pendent. La reproducció PCAP fora de línia utilitza un camí pendent separat que ho preserva tot i no hereta l’expulsió de l’anell en viu.

Tots aquests comptadors de la TUI són acumulatius per a la sessió actual. No sumeu instantànies successives. Un percentatge retingut baix significa que les files de paquets són una mostra diagnòstica incompleta. Utilitzeu els comptadors exactes d’entrada/protocol per a les taxes de trànsit i una sortida PCAP quan calguin proves completes dels paquets.

Alterneu entre les subvistes Overview i Distributed amb v o les tecles 1/2. Exporteu les estadístiques a JSON amb e.

Pestanya Settings

Premeu Alt+4 per veure i modificar les opcions de captura:

• Selecció de la interfície
• Configuració del filtre BPF

Pestanya Help

Premeu ? per obrir el sistema d’ajuda cercable:

• Referència de dreceres de teclat
• Sintaxi de filtres
• Ordres
• Fluxos de treball

Cerqueu amb / i navegueu pels resultats amb n/N. Aneu a les seccions amb 1-4.

Notificacions emergents

Els missatges d’estat apareixen com notificacions emergents a la part inferior de la pantalla i desapareixen automàticament al cap de 2–5 segons. Els tipus inclouen èxit (verd), error (vermell), informació (blau) i advertiment (groc). Les notificacions relacionades se substitueixen entre si; per exemple, “Paused” se substitueix per “Resumed”.

Desament de paquets

Premeu w a la pestanya Capture per desar els paquets mostrats en un fitxer PCAP. S’obre un diàleg de fitxer per triar el camí de sortida. Torneu a prémer w per aturar l’escriptura contínua al fitxer.

Ara que coneixeu la captura local (CLI i TUI), podeu aprendre sobre la captura distribuïda a la Part III, on els nodes Hunter capturen a la perifèria i els processadors agreguen centralment.

Visió general de l’arquitectura distribuïda

El mode distribuït de lippycat permet capturar trànsit en diversos segments de xarxa i agregar-lo en un punt central per analitzar-lo. Aquest capítol explica l’arquitectura, quan utilitzar-la i com triar la topologia de desplegament adequada.

Per què distribuir la captura?

Un únic punt de captura només veu el trànsit del seu segment de xarxa. En xarxes reals, el trànsit d’interès passa per diversos segments: centres de dades, sucursals, DMZ i regions del núvol. La captura distribuïda resol tres problemes:

1. Visibilitat entre segments: desplegueu nodes Hunter allà on passa el trànsit. Un processador central ho agrega tot en una sola vista.
2. Escalabilitat: repartiu la càrrega de captura entre molts agents lleugers en lloc d’una màquina sobrecarregada.
3. Separació de responsabilitats: captureu en zones restringides (DMZ, producció) i analitzeu des d’una zona de monitoratge. Els nodes Hunter necessiten CAP_NET_RAW; el processador no.

El model Hunter/processador

L’arquitectura distribuïda de lippycat té dos tipus de node:

• Els nodes Hunter capturen paquets a la perifèria de la xarxa i els transmeten a un processador mitjançant gRPC. Són lleugers (~50 MB de RAM) i estan dissenyats per funcionar en cada segment de xarxa que voleu supervisar.
• Els processadors reben paquets de diversos nodes Hunter, fan anàlisi de protocols, escriuen fitxers PCAP i atenen clients TUI per al monitoratge en temps real.

flowchart TB
    subgraph Edge["Distributed Hunters"]
        direction LR
        H1[Hunter<br/>datacenter-1]
        H2[Hunter<br/>datacenter-2]
        H3[Hunter<br/>branch-office]
    end

    subgraph Processor["Processor Node"]
        P[Processor<br/>monitor.internal:55555]
        VIRT[Virtual Interface<br/>lc0]
    end

    subgraph Outputs[" "]
        direction LR
        subgraph Tools["Analysis Tools"]
            direction LR
            WS[Wireshark]
            TD[tcpdump]
            SNORT[Snort/Zeek]
        end

        PCAP[(PCAP Files)]

        subgraph Clients["Monitoring Clients"]
            direction LR
            TUI1[TUI Client]
            TUI2[TUI Client]
        end
    end

    H1 -->|gRPC/TLS| P
    H2 -->|gRPC/TLS| P
    H3 -->|gRPC/TLS| P
    VIRT --> Tools
    P --> PCAP
    P <-->|gRPC/TLS| Clients

Flux de dades: els nodes Hunter agrupen paquets en lots (per defecte: 64 per lot) i els transmeten al processador per gRPC. El processador escriu PCAP, difon als subscriptors TUI, injecta en interfícies virtuals i, opcionalment, reenvia cap amunt.

Reenviament de paquets i esdeveniments

Cada sessió Hunter o Tap que reenvia utilitza una representació canònica cap amunt:

El mode d’esdeveniments redueix l’amplada de banda i l’exposició de contingut en brut, però el receptor no pot reconstruir proves de paquets ni repetir anàlisis dependents de paquets. Utilitzeu un node Tap amb retenció PCAP local quan calguin tant metadades centralitzades com proves a la perifèria. L’API d’esdeveniments i les capacitats d’anàlisi es negocien; la incompatibilitat provoca un tancament segur llevat que el productor permeti explícitament un recurs a paquets que es registra. En mode d’esdeveniments jeràrquic, els processadors conserven la identitat d’origen i utilitzen un spool recuperable i un límit de confirmació per a cada salt de reenviament.

També hi ha un tercer tipus de node:

• Tap combina Hunter i processador en un sol procés. Captura localment i ofereix totes les funcions del processador sense la sobrecàrrega gRPC entre captura i processament. Consulteu el Capítol 9 per obtenir més detalls.

Topologies de xarxa

Radial

La topologia més senzilla. Tots els nodes Hunter es connecten directament a un processador:

flowchart TB
    H1[Hunter 1] -->|gRPC/TLS| P
    H2[Hunter 2] -->|gRPC/TLS| P
    H3[Hunter 3] -->|gRPC/TLS| P

    subgraph P[Processor]
        direction TB
        A[Aggregation]
        F[Filtering]
        W[PCAP Writing]
    end

Quan utilitzar-la: desplegaments petits o mitjans (fins a ~50 nodes Hunter), un sol emplaçament i requisits senzills.

Processador:

lc process --listen :55555 --write-file /var/capture/all.pcap \
  --tls-cert server.crt --tls-key server.key

Nodes Hunter:

sudo lc hunt --processor processor:55555 -i eth0 --tls-ca ca.crt

Jeràrquica

Arquitectura de diversos nivells per a segmentació geogràfica o de xarxa. Els processadors de perifèria agreguen localment i reenvien a processadors regionals o centrals:

flowchart LR
    subgraph Site1["Site A"]
        H1[Hunter 1] --> E1[Edge Processor]
        H2[Hunter 2] --> E1
    end

    subgraph Site2["Site B"]
        H3[Hunter 3] --> E2[Edge Processor]
        H4[Hunter 4] --> E2
    end

    E1 -->|gRPC/TLS| R[Regional Processor]
    E2 -->|gRPC/TLS| R
    R -->|gRPC/TLS| C[Central Processor]

Quan utilitzar-la: desplegaments en diversos emplaçaments, distribució geogràfica, segmentació DMZ/interna i agregació gradual amb filtratge a cada nivell.

Processador central:

lc process --listen :55555 --write-file /var/capture/central.pcap \
  --tls-cert server.crt --tls-key server.key

Processador regional (reenvia al central):

lc process --listen :55555 --processor central:55555 \
  --tls-cert server.crt --tls-key server.key --tls-ca ca.crt

Processador de perifèria (reenvia al regional):

lc process --listen :55555 --processor regional:55555 \
  --tls-cert server.crt --tls-key server.key --tls-ca ca.crt

La profunditat de la jerarquia està limitada a 10 nivells. Manteniu-la en 3 o menys per obtenir un rendiment òptim (cada salt afegeix ~500 ms a les operacions de gestió).

Diversos processadors

Repartiu els nodes Hunter entre diversos processadors independents per distribuir la càrrega:

flowchart LR
    H1["Hunters 1-50"] --> P1[Processor 1]
    H2["Hunters 51-100"] --> P2[Processor 2]
    H3["Hunters 101-150"] --> P3[Processor 3]

Quan utilitzar-la: desplegaments molt grans on un sol processador no pot gestionar tot el trànsit, o quan voleu dominis de monitoratge independents.

Segmentació DMZ

Capturar tant de la DMZ com de xarxes internes mitjançant reenviament jeràrquic a través del tallafoc:

flowchart TB
    subgraph DMZ["DMZ"]
        DH1[Hunter: web-01]
        DH2[Hunter: web-02]
        DP[DMZ Processor]
    end

    subgraph Internal["Internal Network"]
        IH1[Hunter: app-01]
        IH2[Hunter: db-01]
        IP[Central Processor]
    end

    DH1 --> DP
    DH2 --> DP
    DP -->|"firewall (port 55555)"| IP
    IH1 --> IP
    IH2 --> IP

El processador DMZ reenvia el trànsit agregat a través d’un únic port del tallafoc al processador intern, que el combina amb les captures internes. Això significa:

• Els nodes Hunter de la DMZ mai no necessiten accés directe a la xarxa interna
• Només cal una regla de tallafoc (processador DMZ → processador intern al port 55555)
• El processador intern té una vista unificada de totes dues zones

Quan utilitzar-la: entorns sensibles a la seguretat on la captura travessa límits de confiança.

Model de seguretat

Totes les connexions gRPC utilitzen TLS per defecte. Heu d’indicar explícitament --insecure per desactivar el xifratge (bloquejat quan LIPPYCAT_PRODUCTION=true).

Hi ha tres modes de seguretat disponibles:

Recomanació: utilitzeu TLS mutu en producció. Impedeix que nodes Hunter no autoritzats es connectin al vostre processador.

Per a la generació i gestió de certificats, consulteu el Capítol 13: seguretat.

Triar el mode adequat

No tots els desplegaments necessiten l’arquitectura distribuïda completa. Aquesta guia ajuda a decidir:

Camí de migració: comenceu amb sniff o tap en una sola màquina. Quan necessiteu visibilitat entre segments, desplegueu nodes Hunter i un processador. El coneixement de les opcions es transfereix: la majoria d’opcions de sniff també funcionen amb hunt (consulteu el Capítol 7).

Planificació de capacitat

Nodes Hunter

Processadors

Regles orientatives:

• El valor per defecte de --max-hunters és 100; ajusteu-lo segons la RAM disponible
• Cada node Hunter transmet ~10.000 paquets/s en hores punta
• La latència d’extrem a extrem és habitualment <100 ms
• L’interval de batec és de 5 segons; els nodes Hunter inactius es netegen després de 5 minuts

Què ve a continuació

• Capítol 7: captura a la perifèria amb lc hunt — desplegar i configurar nodes Hunter
• Capítol 8: agregació central amb lc process — configurar processadors
• Capítol 9: mode autònom amb lc tap — quan voleu tots dos rols en un binari
• Capítol 13: seguretat — configurar certificats TLS/mTLS

Captura a la perifèria amb lc hunt

Els nodes Hunter són agents de captura lleugers que funcionen a la perifèria de la xarxa. Si heu utilitzat lc sniff (Capítol 4), ja coneixeu gairebé tot el necessari: hunt captura com sniff, però reenvia a un processador en lloc d’escriure localment.

De Sniff a Hunt

Si ja coneixeu lc sniff, també us orientareu ràpidament amb lc hunt. Compareu:

El que heu après amb sniff:

sudo lc sniff voip -i eth0 --sip-user alicent -w calls.pcap

L’equivalent distribuït comença creant un filtre:

lc set filter -P central:55555 --tls-ca ca.crt \
  --type sip_user --pattern alicent

Després, inicieu el node Hunter:

sudo lc hunt voip -i eth0 --processor central:55555 --tls-ca ca.crt

La majoria d’opcions de captura (-i, -f, --sip-port, --rtp-port-range) es mantenen. Canvien el filtratge i la sortida: els filtres de trucades VoIP es gestionen centralment al processador amb lc set filter, i --processor envia els paquets coincidents a aquest processador. El processador s’encarrega d’escriure PCAP, servir la TUI i fer l’anàlisi (consulteu el Capítol 8).

Què es manté igual

Novetats

La vostra primera captura distribuïda

Inicieu un processador (consulteu el Capítol 8 per obtenir tots els detalls):

Al terminal 1, inicieu el processador:

lc process --listen :55555 --write-file /tmp/captured.pcap \
  --tls-cert server.crt --tls-key server.key

Al terminal 2, inicieu un node Hunter:

sudo lc hunt --processor localhost:55555 -i eth0 --tls-ca ca.crt

El node Hunter captura paquets a eth0, els agrupa en lots i els transmet al processador mitjançant gRPC. El processador ho escriu tot a captured.pcap.

Reenviament de paquets o esdeveniments

Els nodes Hunter utilitzen --forward-mode packets per defecte per compatibilitat. El processador rep paquets en brut, és responsable de l’anàlisi de protocols i pot oferir sortida PCAP, vistes TUI de paquets, injecció en interfícies virtuals i nova anàlisi posterior.

Amb --forward-mode events, l’anàlisi passa al node Hunter. Només els esdeveniments normalitzats de connexió, DNS, TLS, HTTP, SMTP, RADIUS i metadades de fitxers travessen la xarxa; els paquets en brut i el contingut dels fitxers no. El processador central pot registrar i mostrar els esdeveniments negociats, però no pot reconstruir proves de paquets, repetir l’anàlisi ni oferir sortida dependent de paquets per a aquest productor.

sudo lc hunt -P processor:55555 -i eth0 --forward-mode events \
  --event-delivery-profile reliable \
  --event-spool-dir /var/lib/lippycat/event-spool --tls-ca ca.crt

El perfil fiable per defecte reté els lots no confirmats en un spool recuperable de perifèria. memory-only redueix l’ús de disc, però les admissions en cua confirmades es poden perdre si el processador falla. Configureu límits de bytes/antiguitat i trieu drop_oldest o drop_new; la pèrdua continua visible a l’estat del node Hunter.

Operació del spool fiable d’esdeveniments

Doneu a cada node Hunter el seu propi directori de spool i superviseu tant el límit configurat com l’espai lliure del sistema de fitxers. Les càrregues útils dels registres codificats estan limitades a 4 MiB fins i tot quan l’emmagatzematge total del spool és il·limitat; si no es pot desar un esdeveniment o el seu informe exacte de pèrdua, el reenviament s’atura en lloc d’ocultar la pèrdua. Per veure el comportament de recuperació i la resposta segura als errors d’inici o durabilitat, consulteu Emmagatzematge i recuperació del spool d’esdeveniments.

Es negocien les capacitats d’esdeveniments i la política d’anàlisi. La incompatibilitat provoca un tancament segur llevat que --event-fallback-to-packets permeti explícitament recórrer a paquets en brut. Manteniu aquesta opció desactivada quan el mode d’esdeveniments sigui un límit de privadesa. Els nodes existents que només admeten paquets continuen sent compatibles perquè el mode de paquets és el valor per defecte.

Les metadades no són anònimes: URL, adreces de correu, noms DNS, certificats i atributs de fitxers poden ser sensibles. Utilitzeu TLS/mTLS, autoritzeu les identitats dels nodes, restringiu i xifreu l’emmagatzematge del spool i apliqueu límits de retenció.

Per a proves locals ràpides sense TLS:

Iniciar el processador en mode insegur (només per a proves):

lc process --listen :55555 --write-file /tmp/captured.pcap --insecure

Després, iniciar el node Hunter en mode insegur (només per a proves):

sudo lc hunt --processor localhost:55555 -i eth0 --insecure

Nodes Hunter específics de protocol

Com sniff, hunt té subordres de protocol que afegeixen filtratge i anàlisi especialitzats.

Node Hunter VoIP (hunt voip)

El node Hunter VoIP és el mode més utilitzat. Captura trànsit SIP/RTP amb emmagatzematge intel·ligent de trucades en buffers: els paquets es mantenen localment fins que una trucada coincideix amb els filtres del processador, i després es reenvien. Les trucades sense coincidència es descarten a la perifèria, reduint l’amplada de banda més d’un 90%.

Comportament en actualitzar: els nodes Hunter VoIP ara reben filtres d’aplicació amb eBPF desactivat. Una incompatibilitat anterior d’interfície podia seleccionar trucades àmpliament malgrat tenir filtres distribuïts d’identitat o IP instal·lats. --no-filter-policy utilitza deny per defecte: un conjunt buit de filtres aplicables no reenvia cap trucada. La correcció pot reduir el trànsit reenviat després d’actualitzar. Per seleccionar intencionadament de manera àmplia, utilitzeu un conjunt buit de filtres aplicables amb --no-filter-policy allow; allow no anul·la filtres instal·lats ni predicats explícits de captura. Consulteu el registre de canvis del repositori per veure els canvis de comportament de la versió.

Node Hunter VoIP amb TLS:

sudo lc hunt voip --processor processor:55555 -i eth0 --tls-ca ca.crt

Node Hunter VoIP amb optimització BPF per a un port SIP concret:

sudo lc hunt voip --processor processor:55555 -i eth0 \
  --sip-port 5060 --tls-ca ca.crt

Node Hunter VoIP amb captura selectiva de contingut multimèdia a Linux:

sudo lc hunt voip --processor processor:55555 -i eth0 \
  --rtp-ebpf --sip-port 5060 --tls-ca ca.crt

Amb --rtp-ebpf, els extrems RTP/RTCP s’aprenen de l’SDP de les trucades coincidents; --rtp-port-range és innecessari. --sip-port és opcional i restringeix la captura de senyalització. El contingut multimèdia es captura només després de la selecció i la publicació dels extrems, de manera que l’RTP anterior no es desa en buffers. Un interval RTP configurat explícitament continua restringint els extrems apresos. Consulteu Captura selectiva de contingut multimèdia amb eBPF.

Node Hunter VoIP amb un interval de ports RTP personalitzat:

sudo lc hunt voip --processor processor:55555 -i eth0 \
  --rtp-port-range 8000-9000 --tls-ca ca.crt

Node Hunter VoIP amb TLS mutu:

sudo lc hunt voip --processor processor:55555 -i eth0 \
  --tls-cert hunter.crt --tls-key hunter.key --tls-ca ca.crt

Com funciona el buffer de trucades:

flowchart LR
    C[Capture] --> D[Detect SIP/RTP]
    D --> B[Buffer per call]
    B --> M{Filter match?}
    M -->|Yes| F[Forward to processor]
    M -->|No| X[Drop]

1. El node Hunter captura paquets SIP i RTP
2. Els paquets es desen localment en buffers, agrupats per SIP Call-ID
3. La subscripció de filtres rep filtres del processador (usuari SIP, número de telèfon, IP)
4. Els paquets del buffer es comparen amb els filtres
5. Només es reenvien les trucades coincidents: senyalització SIP i contingut multimèdia RTP associat

Els filtres es gestionen centralment al processador i s’envien als nodes Hunter. Els nodes Hunter no configuren filtres de trucades localment. Utilitzeu lc set filter / lc rm filter per a canvis de filtre en viu; consulteu el Capítol 10 per a l’administració CLI.

Node Hunter DNS (hunt dns)

Captura consultes i respostes DNS per reenviar-les al processador.

Node Hunter DNS:

sudo lc hunt dns --processor processor:55555 -i eth0 --tls-ca ca.crt

Node Hunter DNS només UDP amb ports personalitzats:

sudo lc hunt dns --processor processor:55555 -i eth0 \
  --dns-port 53,5353 --udp-only --tls-ca ca.crt

Opcions específiques de DNS: --dns-port (per defecte: 53), --udp-only.

Node Hunter HTTP (hunt http)

Captura trànsit HTTP amb filtratge opcional d’amfitrió/camí/mètode a la perifèria.

Node Hunter HTTP amb filtratge d’amfitrió:

sudo lc hunt http --processor processor:55555 -i eth0 \
  --host "*.example.com" --http-port 80,8080 --tls-ca ca.crt

Opcions específiques d’HTTP: --http-port, --host, --path, --method.

Node Hunter TLS (hunt tls)

Captura negociacions TLS per a l’anàlisi d’empremtes (JA3/JA3S/JA4).

Node Hunter TLS en diversos ports:

sudo lc hunt tls --processor processor:55555 -i eth0 \
  --tls-port 443,8443 --tls-ca ca.crt

Opcions específiques de TLS: --tls-port (per defecte: 443).

Node Hunter de correu electrònic (hunt email)

Captura trànsit SMTP, IMAP i POP3 amb filtratge d’adreces.

Node Hunter de correu només SMTP amb filtratge de remitent:

sudo lc hunt email --processor processor:55555 -i eth0 \
  --protocol smtp --sender "*@suspicious.com" --tls-ca ca.crt

Opcions específiques de correu: --protocol (smtp/imap/pop3/all), --smtp-port, --imap-port, --pop3-port, --address, --sender, --recipient.

Node Hunter RADIUS (hunt radius)

Captura trànsit UDP RADIUS visible d’autenticació i comptabilització, aplica criteris exactes d’identitat a la perifèria i reenvia al processador els paquets seleccionats i les seves metadades validades d’observació i procedència. Les projeccions habituals de visualització i registre estructurat eliminen els atributs que contenen credencials:

sudo lc hunt radius --processor processor:55555 -i mirror0 \
  --radius-username 'alice@example.test' --tls-ca ca.crt

La subordre RADIUS comparteix les opcions de port, identitat, àmbit i correlació limitada amb sniff radius i tap radius. Consulteu Captura RADIUS i POI per veure la taula completa d’opcions i les restriccions del desplegament distribuït.

Resiliència i control de flux

Els nodes Hunter estan dissenyats per resistir interrupcions de xarxa i caigudes del processador.

Control de flux

El processador envia senyals de control de flux als nodes Hunter mitjançant respostes als batecs:

El control de flux es basa en l’ús de la cua d’escriptura PCAP del processador. Els clients TUI lents no activen el control de flux; en canvi, s’hi descarten paquets selectivament.

Reconnexió automàtica

Quan es perd la connexió amb el processador, el node Hunter es reconnecta automàticament:

Durant la reconnexió, la captura de paquets continua. Els canals d’entrada normal i prioritari SIP tenen límits separats, seguits d’un canal de sortida combinat limitat. El canal SIP coincideix automàticament amb --buffer-size llevat que --sip-buffer-size s’estableixi a un valor positiu que el sobreescrigui. Cues més grans donen marge per a pics i utilitzen més memòria; no fan que una sobrecàrrega sostinguda sigui sense pèrdues.

Buffer de desbordament a disc

Per a desconnexions llargues (hores, dies), activeu el buffer de desbordament a disc:

sudo lc hunt --processor processor:55555 -i eth0 \
  --disk-buffer --disk-buffer-max-mb 2048 --tls-ca ca.crt

Quan la cua de memòria s’omple, els lots es desen al disc. Quan es restableix la connexió, els lots de disc tornen a la cua de memòria (ordre FIFO, els més antics primer).

• --disk-buffer — activar el desbordament a disc
• --disk-buffer-dir — directori del buffer (per defecte: /var/tmp/lippycat-buffer)
• --disk-buffer-max-mb — ús màxim de disc en MB (per defecte: 1024)

Tallacircuit

Quan el processador cau durant un període llarg, el tallacircuit evita intents constants de connexió:

• S’obre després de 5 errors de connexió consecutius
• Espera 30 segons abans de permetre un nou intent
• Estat semiobert: permet connexions de prova limitades abans de la recuperació completa

Ajust del rendiment

Pressió del buffer de captura

Utilitzeu els indicadors de longitud i capacitat de cada canal per identificar si està saturat el canal normal, el prioritari SIP o el de sortida combinada. Interpreteu els comptadors SIP com resultats successius:

El creixement persistent del canal de sortida indica problemes de cabal en el processament o reenviament posterior, més que només un problema de capacitat d’entrada.

Configuració dels lots

L’agrupació en lots controla com s’agreguen els paquets abans d’enviar-los. Lots més grans redueixen la sobrecàrrega gRPC però augmenten la latència:

Per a monitoratge en temps real de baixa latència:

sudo lc hunt --processor processor:55555 -i eth0 \
  --batch-size 16 --batch-timeout 50 --tls-ca ca.crt

Per a captura massiva d’alt cabal:

sudo lc hunt --processor processor:55555 -i eth0 \
  --batch-size 256 --batch-timeout 500 --tls-ca ca.crt

Per al perfil equilibrat per defecte:

sudo lc hunt --processor processor:55555 -i eth0 \
  --batch-size 64 --batch-timeout 100 --tls-ca ca.crt

Acceleració GPU

Aquestes opcions estan disponibles en compilacions CUDA.

Activar la comparació de patrons VoIP accelerada amb GPU a la perifèria:

Detectar automàticament el millor motor:

sudo lc hunt --processor processor:55555 -i eth0 \
  --enable-voip-filter --gpu-backend auto --tls-ca ca.crt

Forçar CUDA en GPU NVIDIA:

sudo lc hunt --processor processor:55555 -i eth0 \
  --enable-voip-filter --gpu-backend cuda --gpu-batch-size 200 --tls-ca ca.crt

Utilitzar SIMD de CPU sense necessitat de GPU:

sudo lc hunt --processor processor:55555 -i eth0 \
  --enable-voip-filter --gpu-backend cpu-simd --tls-ca ca.crt

L’acceleració GPU és més útil amb taxes de paquets altes (>10.000 pps) i moltes trucades SIP simultànies. Consulteu el Capítol 14: rendiment per veure proves de rendiment.

Optimització dels filtres BPF

Per als nodes Hunter VoIP en xarxes amb molt trànsit TCP, utilitzeu opcions BPF per ometre trànsit TCP i centrar-vos en SIP/RTP:

Restringir la captura a un port SIP concret:

sudo lc hunt voip --processor processor:55555 -i eth0 \
  --sip-port 5060 --tls-ca ca.crt

Restringir tant el port SIP com l’interval RTP:

sudo lc hunt voip --processor processor:55555 -i eth0 \
  --sip-port 5060 --rtp-port-range 10000-20000 --tls-ca ca.crt

L’antiga opció VoIP --udp-only encara s’accepta per compatibilitat, però està oculta i és obsoleta perquè pot ometre trànsit SIP TCP.

Algoritme de comparació de patrons

Per a conjunts grans de filtres, l’algoritme Aho-Corasick ofereix una comparació ~265 vegades més ràpida que el recorregut lineal:

Seleccionar automàticament Aho-Corasick per a 100 patrons o més i la comparació lineal en la resta de casos:

sudo lc hunt --processor processor:55555 -i eth0 \
  --pattern-algorithm auto --tls-ca ca.crt

Forçar Aho-Corasick per a conjunts més petits de filtres:

sudo lc hunt --processor processor:55555 -i eth0 \
  --pattern-algorithm aho-corasick --tls-ca ca.crt

Fitxer de configuració

Totes les opcions de hunt es poden establir a ~/.config/lippycat/config.yaml:

hunter:
  processor_addr: "processor.example.com:55555"
  id: "edge-hunter-01"
  interfaces:
    - eth0
    - eth1
  bpf_filter: "port 5060 or portrange 10000-20000"
  buffer_size: 10000
  batch_size: 64
  batch_timeout_ms: 100
  batch_queue_size: 1000

  voip:
    udp_only: false
    sip_ports: "5060"
    rtp_port_ranges: "10000-32768"

  tls:
    cert_file: "/etc/lippycat/certs/hunter.crt"
    key_file: "/etc/lippycat/certs/hunter.key"
    ca_file: "/etc/lippycat/certs/ca.crt"

Els valors de les opcions tenen prioritat sobre els valors del fitxer de configuració.

Agregació central amb lc process

Els processadors són el centre de l’arquitectura distribuïda. Reben paquets dels nodes Hunter, fan anàlisi de protocols, escriuen fitxers PCAP i atenen clients TUI per al monitoratge en temps real. Aquest capítol cobreix tot el necessari per executar un processador.

Conceptes bàsics del processador

Inici d’un processador

Un processador necessita una adreça d’escolta i certificats TLS:

Processador mínim amb TLS:

lc process --listen :55555 \
  --tls-cert server.crt --tls-key server.key

Processador amb escriptura PCAP:

lc process --listen 0.0.0.0:55555 \
  --write-file /var/capture/packets.pcap \
  --tls-cert server.crt --tls-key server.key

Per a proves locals sense TLS:

lc process --listen :55555 --insecure

Els nodes Hunter es connecten automàticament al processador. No cal configuració al processador per acceptar un node Hunter concret: qualsevol node Hunter amb les credencials TLS correctes es pot connectar.

Productors de paquets i esdeveniments

Un processador pot acceptar simultàniament nodes en mode de paquets i d’esdeveniments. El mode de paquets és el valor per defecte i manté l’autoritat d’anàlisi al processador: hi ha paquets en brut disponibles per a PCAP, vistes de paquets, interfícies virtuals i anàlisi central. El mode d’esdeveniments és opcional i dona l’autoritat d’anàlisi a la perifèria: s’accepten metadades normalitzades del productor sense bytes de paquets en brut ni contingut de fitxers, i el processador no crea un segon flux canònic d’esdeveniments per a aquesta sessió.

lc process és neutre respecte dels protocols i, per tant, no té subordres de protocol. Els paquets i les metadades de hunt radius i tap radius utilitzen els mateixos camins d’entrada, PCAP, registre estructurat i TUI que els altres protocols admesos. La selecció de captura RADIUS s’aplica al productor; els filtres gestionats pel processador es distribueixen als nodes Hunter RADIUS compatibles. El processador mostra i registra una projecció amb les credencials eliminades. Consulteu Captura RADIUS i POI per veure els requisits d’àmbit distribuït i de lliurament LI opcional.

El registre negocia l’API d’esdeveniments, els tipus, el perfil d’anàlisi amb estat, l’enriquiment i els límits. Es rebutja una petició incompatible llevat que el productor permeti explícitament un recurs visible a paquets. Això permet que nodes antics que només admeten paquets convisquin amb nodes nous capaços de transmetre esdeveniments sense afeblir silenciosament una política de privadesa del mode d’esdeveniments.

Un Write-Ahead Log (WAL) és un diari persistent. En mode d’entrada fiable d’esdeveniments, el processador escriu els esdeveniments rebuts en aquest diari abans de confirmar-los al productor. Això permet recuperar-los després d’una caiguda del processador. Consulteu el Glossari.

L’entrada fiable confirma l’admissió recuperable al WAL; l’entrada només en memòria confirma l’admissió en cua i pot perdre esdeveniments confirmats si el processador falla. L’entrada almenys una vegada es deduplica per identitat de productor/sessió/esdeveniment, mentre que la pressió de sortida i la pèrdua de transport continuen sent observables per separat. Protegiu el WAL i les sortides de metadades com proves sensibles i utilitzeu TLS/mTLS i autorització de privilegi mínim.

Opcions principals

Gestió de nodes Hunter

Quan es connecten nodes Hunter, el processador:

1. Registra el node Hunter i l’assigna al conjunt de connexions
2. Comença a rebre lots de paquets mitjançant transmissió contínua gRPC
3. Envia respostes als batecs amb senyals de control de flux
4. Distribueix els filtres actius al node Hunter

L’estat dels nodes Hunter se supervisa mitjançant batecs (interval de 5 segons). Els nodes Hunter inactius es netegen després de 5 minuts sense batec.

Canals de sortida

Cada paquet que rep un processador es pot enviar a diverses destinacions simultàniament. Aquests canals de sortida són independents; activeu qualsevol combinació:

flowchart LR
    Hunters -->|gRPC| P[Processor]
    P --> PCAP["PCAP Files<br/>(unified, per-call, auto-rotating)"]
    P --> LOGS["Structured Logs<br/>(TSV or JSONL)"]
    P --> TUI["TUI Subscribers<br/>(lc watch remote)"]
    P --> VIF["Virtual Interface<br/>(lc0 → Wireshark, Snort, etc.)"]
    P --> UP["Upstream Processor<br/>(hierarchical forwarding)"]
    P --> Hooks["Command Hooks<br/>(gzip, upload, alerting)"]
    P --> LI["LI Delivery<br/>(X2/X3 to MDF)"]

lc tap admet els mateixos canals de sortida (consulteu Mode autònom amb lc tap).

Les seccions següents cobreixen cada canal en detall. Per al lliurament LI, consulteu Intercepció legal.

Registres estructurats de protocols

Establiu --log-dir per activar els fluxos normalitzats per defecte conn, dns, ssl, http, smtp, files i radius. El registre està desactivat per defecte i utilitza TSV d’estil Zeek llevat que se seleccioni --log-format json:

lc process --listen :55555 --log-dir /var/log/lippycat \
  --log-streams conn,dns,ssl --tls-cert server.crt --tls-key server.key

El valor per defecte --log-emit-stage terminal evita fitxers duplicats en una jerarquia de processadors. Les cues limitades protegeixen el processament de paquets; per això els operadors han de supervisar els avisos de descart. Consulteu la guia completa Registres estructurats de protocols per veure esquemes, rotació, completesa, entrada a SIEM i privadesa.

Modes d’escriptura PCAP

Els processadors admeten tres modes d’escriptura PCAP independents. Tots tres poden estar actius simultàniament.

PCAP unificat

Escriure tots els paquets rebuts en un únic fitxer continu:

lc process --listen :55555 \
  --write-file /var/capture/all-traffic.pcap \
  --tls-cert server.crt --tls-key server.key

Casos d’ús: compliment normatiu/pistes d’auditoria, anàlisi forense i reproducció del trànsit.

PCAP per trucada (VoIP)

Escriure fitxers PCAP SIP i RTP separats per a cada trucada VoIP:

lc process --listen :55555 \
  --per-call-pcap \
  --per-call-pcap-dir /var/capture/calls \
  --per-call-pcap-pattern "{timestamp}_{callid}.pcap" \
  --tls-cert server.crt --tls-key server.key

Per a cada trucada es creen dos fitxers:

20250123_143022_abc123_sip.pcap    # SIP signaling
20250123_143022_abc123_rtp.pcap    # RTP media

Marcadors de patró: {callid}, {from}, {to}, {timestamp}.

Els fitxers roten independentment quan arriben a 100 MB. El PCAP per trucada només s’aplica al trànsit VoIP; els paquets no VoIP els gestionen els altres escriptors.

Casos d’ús: enregistrament de trucades VoIP, anàlisi de qualitat per trucada i arxivament selectiu.

Cicle de vida dels fitxers per trucada

El gestor d’escriptors per trucada és responsable de la vida lògica de cada Call-ID. La seva màquina d’estats és:

Les Call-ID finalitzades es retenen durant una hora, coincidint amb la finestra de compatibilitat de trucades tancades. El gestor també aplica un límit intern estricte de 100.000 marques de baixa i expulsa les entrades més antigues quan cal. Aquests límits restringeixen l’ús de memòria tot absorbint trànsit de xarxa retardat o duplicat. Quan qualsevol límit de retenció elimina una entrada, un paquet posterior es pot tractar com una generació nova de Call-ID; els noms dels artefactes continuen incloent material únic de generació perquè un fitxer antic no es confongui amb la nova trucada activa.

per_call_pcap.max_writers és un llindar flexible de pressió, no un límit destructiu de capacitat. Superar-lo emet un advertiment amb freqüència limitada, però no finalitza, marca de baixa ni desconnecta una trucada possiblement activa. Les trucades inactives i les completades segons el protocol continuen sent les vies segures per alliberar recursos. Els operadors que estableixen aquest llindar han de dimensionar els límits de descriptors de fitxer per a superacions temporals.

La política actual no reté paquets tardans. En particular, els paquets suprimits no creen un PCAP .late i no poden invocar una segona vegada l’acció normal de finalització de trucada. Un futur mode de retenció tardana hauria d’utilitzar un PCAP independent diferent amb la seva pròpia capçalera vàlida i una semàntica de finalització separada.

Les dates de modificació dels fitxers no són un estat de cicle de vida. Per tant, un reinici del procés o una marca de baixa caducada mai no provoca que un escriptor continuï un fitxer existent només perquè s’ha modificat recentment. Només un escriptor que encara sigui al conjunt actiu del gestor pot afegir dades als seus fitxers. Els artefactes nous s’obren amb creació exclusiva. Una col·lisió de camí selecciona un nom amb el sufix _gen_<Unix-nanoseconds> (amb un sufix numèric de reintent si cal), escriu una capçalera PCAP independent nova i mai no trunca ni afegeix dades ambiguament al fitxer existent.

PCAP amb rotació automàtica

Escriure paquets no VoIP en fitxers amb rotació automàtica segons l’activitat:

lc process --listen :55555 \
  --auto-rotate-pcap \
  --auto-rotate-pcap-dir /var/capture/bursts \
  --auto-rotate-idle-timeout 30s \
  --auto-rotate-max-size 100M \
  --tls-cert server.crt --tls-key server.key

Desencadenants de rotació:

• Temps d’inactivitat: tancar el fitxer després de 30 segons d’inactivitat (configurable)
• Mida del fitxer: rotar quan el fitxer arriba a 100 MB (configurable)
• Durada: rotar després d’1 hora com a màxim

Sortida:

20250123_143022.pcap    # First burst
20250123_144530.pcap    # Next burst after 30s idle

Casos d’ús: pics de trànsit de xarxa, captura basada en sessions i monitoratge de l’amplada de banda.

Combinació de modes

Tots tres modes són independents. Activeu-los junts per obtenir una captura completa:

lc process --listen :55555 \
  --write-file /var/capture/all.pcap \
  --per-call-pcap --per-call-pcap-dir /var/capture/calls \
  --auto-rotate-pcap --auto-rotate-pcap-dir /var/capture/bursts \
  --tls-cert server.crt --tls-key server.key

Els paquets VoIP s’encaminen a l’escriptor per trucada. Els paquets no VoIP van a l’escriptor amb rotació automàtica. Tots els paquets van a l’escriptor unificat.

Accions d’ordres

Executar ordres personalitzades quan s’escriuen fitxers PCAP o finalitzen trucades VoIP.

Acció de finalització PCAP

S’executa quan es tanca qualsevol fitxer PCAP:

Comprimir fitxers PCAP:

lc process --listen :55555 --per-call-pcap \
  --pcap-command 'gzip %pcap%' \
  --tls-cert server.crt --tls-key server.key

Pujar fitxers PCAP a emmagatzematge al núvol:

lc process --listen :55555 --per-call-pcap \
  --pcap-command 'aws s3 cp %pcap% s3://captures/' \
  --tls-cert server.crt --tls-key server.key

Marcador: %pcap% — camí complet del fitxer PCAP.

Acció de finalització de trucada VoIP

S’executa quan acaba una trucada VoIP (després d’un període de gràcia de 5 segons per a paquets tardans):

lc process --listen :55555 --per-call-pcap \
  --voip-command '/opt/scripts/process-call.sh %callid% %dirname%' \
  --tls-cert server.crt --tls-key server.key

Marcadors:

Acció de túnels DNS

S’executa quan es detecta un túnel DNS (processador o mode tap dns):

lc process --listen :55555 \
  --tunneling-command 'echo "ALERT: %domain% score=%score%" >> /var/log/tunneling.log' \
  --tunneling-threshold 0.7 \
  --tunneling-debounce 5m \
  --tls-cert server.crt --tls-key server.key

Marcadors: %domain%, %score%, %entropy%, %queries%, %srcips%, %hunter%, %timestamp%.

Detalls d’execució de les accions

• Les ordres s’executen de manera asíncrona; mai no bloquegen el processament de paquets
• Les ordres s’executen mitjançant l’intèrpret d’ordres (sh -c)
• --command-timeout controla el temps límit d’execució (per defecte: 30 s)
• --command-concurrency limita les execucions paral·leles (per defecte: 10)
• Les ordres fallides es registren però no afecten el processament

Gestió de filtres

Els processadors gestionen filtres que controlen quins paquets reenvien els nodes Hunter. Això és especialment important per als nodes Hunter VoIP, on els filtres determinen quines trucades es capturen.

Fitxer de filtres

Els filtres es desen en un fitxer YAML:

lc process --listen :55555 \
  --filter-file /etc/lippycat/filters.yaml \
  --tls-cert server.crt --tls-key server.key

Ubicació per defecte: ~/.config/lippycat/filters.yaml.

Format del fitxer de filtres:

filters:
  - id: "filter-001"
    type: "sip_user"
    pattern: "alicent@example.com"
    action: "forward"
    enabled: true

  - id: "filter-002"
    type: "phone_number"
    pattern: "*456789"
    action: "forward"
    enabled: true

  - id: "filter-003"
    type: "ip_address"
    pattern: "192.168.1.0/24"
    action: "forward"
    enabled: false

  - id: "filter-004"
    type: "dns_domain"
    pattern: "*.malware-domain.com"
    action: "forward"
    enabled: true

  - id: "filter-005"
    type: "tls_sni"
    pattern: "*.example.com"
    action: "forward"
    enabled: true

Tipus de filtre

Els filtres cobreixen totes les categories de protocols admeses:

Per veure la llista completa de tipus de filtre, patrons de comodins i detalls de coincidència, consulteu l’Apèndix E: referència de tipus de filtre.

Distribució de filtres

Quan es carreguen filtres, el processador els distribueix automàticament a tots els nodes Hunter connectats. Els nodes Hunter reben actualitzacions de filtres mitjançant transmissió contínua gRPC i les apliquen al processament local de paquets.

Per a canvis en viu, utilitzeu les ordres d’administració:

lc set filter -P processor:55555 --tls-ca ca.crt \
  --type sip_user --pattern alicent

lc rm filter -P processor:55555 --tls-ca ca.crt --id filter-001

El fitxer YAML de filtres continua sent útil per a l’estat d’inici i la importació per lots, però les actualitzacions habituals de filtres no requereixen reiniciar el processador.

Topologies avançades

Mode jeràrquic

Els processadors poden reenviar trànsit a processadors superiors, creant arquitectures de diversos nivells:

Processador de perifèria, que rep dels nodes Hunter i reenvia al regional:

lc process --listen :55555 \
  --processor regional-processor:55555 \
  --tls-cert server.crt --tls-key server.key --tls-ca ca.crt

Processador regional, que rep de la perifèria i reenvia al central:

lc process --listen :55555 \
  --processor central-processor:55555 \
  --tls-cert server.crt --tls-key server.key --tls-ca ca.crt

Processador central per a l’agregació final:

lc process --listen :55555 \
  --write-file /var/capture/all-traffic.pcap \
  --tls-cert server.crt --tls-key server.key

flowchart LR
    subgraph Site1["Site A"]
        H1[Hunter] --> E1[Edge Processor]
        H2[Hunter] --> E1
    end
    subgraph Site2["Site B"]
        H3[Hunter] --> E2[Edge Processor]
        H4[Hunter] --> E2
    end
    E1 -->|gRPC/TLS| R[Regional]
    E2 -->|gRPC/TLS| R
    R -->|gRPC/TLS| C[Central]

Cada processador de la cadena pot escriure PCAP localment a més de reenviar cap amunt.

El reenviament de paquets és el valor per defecte per compatibilitat. Per transmetre esdeveniments normalitzats amb un límit d’admissió recuperable a cada salt, configureu explícitament cada processador no terminal:

lc process --listen :55555 --id regional \
  --processor central:55555 --forward-mode events \
  --event-delivery-profile reliable \
  --event-spool-dir /var/lib/lippycat/processor-event-spool \
  --tls-cert server.crt --tls-key server.key --tls-ca ca.crt

La transmissió conserva la identitat i la seqüència del productor original. El mode fiable reté els lots no confirmats al spool d’esdeveniments; el mode només en memòria pot perdre treball confirmat en una caiguda. El recurs a paquets està desactivat llevat que s’estableixi explícitament --event-fallback-to-packets.

Operació del spool fiable d’esdeveniments cap amunt

Doneu a cada processador el seu propi directori de spool i superviseu tant el límit configurat com l’espai lliure del sistema de fitxers. Les càrregues útils dels registres codificats estan limitades a 4 MiB fins i tot quan l’emmagatzematge total del spool és il·limitat. Per tant, --event-ingress-max-batch-bytes del receptor ha de ser com a mínim de 4 MiB, i --event-queue-size ha de poder contenir un lot entrant complet (fins a 4.096 esdeveniments). Per veure el comportament de recuperació i la resposta segura als errors d’inici o durabilitat, consulteu Emmagatzematge i recuperació del spool d’esdeveniments.

Interfície virtual

Exposeu el trànsit agregat de tots els nodes Hunter connectats en una interfície de xarxa virtual per integrar-lo amb eines de tercers:

Iniciar un processador amb una interfície virtual:

lc process --listen :55555 --virtual-interface \
  --tls-cert server.crt --tls-key server.key

Supervisar la interfície amb Wireshark:

wireshark -i lc0

Alternativament, executar un IDS sobre el flux agregat:

snort -i lc0 -c /etc/snort/snort.conf

Opcions d’interfície virtual: --virtual-interface, --vif-name (per defecte: lc0), --vif-type (tap/tun), --vif-buffer-size.

Requereix la capacitat CAP_NET_ADMIN.

Fitxer de configuració

Totes les opcions del processador es poden establir a ~/.config/lippycat/config.yaml:

processor:
  listen_addr: "0.0.0.0:55555"
  id: "prod-processor-01"
  max_hunters: 100
  max_subscribers: 100
  write_file: "/var/capture/packets.pcap"
  enable_detection: true
  filter_file: "/etc/lippycat/filters.yaml"

  per_call_pcap:
    enabled: true
    output_dir: "/var/capture/calls"
    file_pattern: "{timestamp}_{callid}.pcap"

  auto_rotate_pcap:
    enabled: true
    output_dir: "/var/capture/bursts"
    idle_timeout: "30s"
    max_size: "100M"

  pcap_command: "gzip %pcap%"
  voip_command: "/opt/scripts/process-call.sh %callid% %dirname%"
  command_timeout: "30s"
  command_concurrency: 10

  tls:
    cert_file: "/etc/lippycat/certs/server.crt"
    key_file: "/etc/lippycat/certs/server.key"
    ca_file: "/etc/lippycat/certs/ca.crt"
    client_auth: true

Per veure procediments de desplegament en producció (serveis systemd, monitoratge, comprovacions d’estat), consulteu el Capítol 12: manual d’operacions.

Mode autònom amb lc tap

El mode Tap combina captura local de paquets amb totes les funcions del processador en un sol procés. És l’opció adequada quan voleu PCAP per trucada, servei TUI, accions d’ordres o reenviament cap amunt, però no necessiteu la complexitat de nodes Hunter i processador separats.

La fórmula: tap = process + hunt - gRPC

Tot el que pot fer hunt (captura, filtratge GPU, detecció de protocols) i tot el que pot fer process (escriptura PCAP, servei TUI, accions d’ordres, interfície virtual), sense el transport gRPC entre tots dos.

flowchart LR
    subgraph Tap["lc tap (single process)"]
        direction LR
        C[Capture<br>+ Filtering] --> A[Protocol<br>Analysis]
        A --> W[(PCAP Writing)]
        A --> V[Virtual<br>Interface]
    end

    NIC["Network<br>Interface"] --> C
    TUI[TUI Client] <-->|gRPC| Tap
    A -.->|optional| UP[Upstream<br>Processor]

Quan utilitzar Tap

La pregunta clau: necessiteu capturar des de diverses màquines? Si és així, utilitzeu hunt + process. Si no, tap és més senzill.

Modes de reenviament cap amunt i proves locals

Quan s’estableix --processor, --forward-mode packets és el valor per defecte per compatibilitat. Envia paquets en brut perquè el processador superior pugui crear PCAP, servir vistes de paquets, injectar en una interfície virtual i fer l’anàlisi canònica.

--forward-mode events, en canvi, fa l’anàlisi canònica al node Tap i només envia metadades normalitzades. Els bytes dels paquets en brut i el contingut dels fitxers mai no entren al transport d’esdeveniments. Per tant, les funcions superiors dependents de paquets no estan disponibles, però els escriptors PCAP locals, la rotació, la sortida per trucada i les accions posteriors a l’escriptura del node Tap continuen funcionant:

sudo lc tap -i eth0 -P central:55555 --forward-mode events \
  --auto-rotate-pcap --auto-rotate-pcap-dir /var/lib/lippycat/pcap \
  --event-spool-dir /var/lib/lippycat/event-spool --tls-ca ca.crt

Utilitzeu aquesta topologia per retenir proves forenses a la perifèria tot centralitzant metadades menys reveladores. La transmissió fiable d’esdeveniments utilitza un spool recuperable; memory-only pot perdre esdeveniments admesos en cua si el processador falla. Protegiu tant els PCAP com els spools d’esdeveniments amb permisos restringits, xifratge i límits de retenció. La negociació d’esdeveniments provoca un tancament segur llevat que --event-fallback-to-packets permeti explícitament el recurs. El mode de paquets per defecte continua sent interoperable amb versions superiors que només admeten paquets.

Operació del spool fiable d’esdeveniments cap amunt

Doneu a cada node Tap el seu propi directori de spool i superviseu tant el límit configurat com l’espai lliure del sistema de fitxers. Les càrregues útils dels registres codificats estan limitades a 4 MiB fins i tot quan l’emmagatzematge total del spool és il·limitat; si no es pot desar un esdeveniment o el seu informe exacte de pèrdua, el reenviament s’atura en lloc d’ocultar la pèrdua. Per veure el comportament de recuperació i la resposta segura als errors d’inici o durabilitat, consulteu Emmagatzematge i recuperació del spool d’esdeveniments.

Ús bàsic

Registres estructurats de protocols

Tap comparteix la cadena de registre estructurat del processador. tap dns, tap http i les altres subordres de protocol hereten les opcions de l’ordre pare:

sudo lc tap dns -i eth0 --insecure \
  --log-dir /var/log/lippycat --log-streams conn,dns

El registre està desactivat per defecte. En reenviar cap amunt, el valor per defecte --log-emit-stage terminal només emet al processador terminal. Consulteu Registres estructurats de protocols per veure esquemes de camps, comportament TSV/JSONL, rotació, observacions de límit inferior i controls de privadesa.

TLS està activat per defecte per a la interfície de gestió (connexions TUI):

Captura autònoma amb TLS:

sudo lc tap -i eth0 --tls-cert server.crt --tls-key server.key

Per a proves locals sense TLS:

sudo lc tap -i eth0 --insecure

Connectar la TUI al node Tap:

lc watch remote -P tap-host:55555 --tls-ca ca.crt

Alternativament, connectar sense TLS:

lc watch remote -P localhost:55555 --insecure

lc watch remote es pot connectar directament amb --processor (-P) o llegir els processadors i nodes Tap de destinació d’un fitxer YAML de nodes. Consulteu Monitoratge remot amb la TUI per veure el format de fitxer i els camins de cerca per defecte.

Subordres de protocol

Com sniff i hunt, tap té subordres específiques de protocol.

VoIP (tap voip)

El mode Tap més habitual. El PCAP per trucada està activat per defecte:

Captura VoIP amb filtratge d’usuari SIP:

sudo lc tap voip -i eth0 --sip-user alicent --insecure

Captura VoIP amb TLS i un directori PCAP per trucada:

sudo lc tap voip -i eth0 \
  --per-call-pcap-dir /var/voip/calls \
  --tls-cert server.crt --tls-key server.key

Captura VoIP restringida a un port SIP:

sudo lc tap voip -i eth0 --sip-port 5060 --insecure

Captura selectiva de contingut multimèdia a Linux:

sudo lc tap voip -i eth0 --sip-user alicent \
  --rtp-ebpf --sip-port 5060 --insecure

Amb --rtp-ebpf, els extrems RTP/RTCP s’aprenen de l’SDP de les trucades coincidents; --rtp-port-range és innecessari. --sip-port és opcional i restringeix la captura de senyalització. El contingut multimèdia es captura només després de la selecció i la publicació dels extrems, de manera que l’RTP anterior no es desa en buffers. Un interval RTP configurat explícitament continua restringint els extrems apresos. Consulteu Captura selectiva de contingut multimèdia amb eBPF.

Captura VoIP d’alt rendiment:

sudo lc tap voip -i eth0 --tcp-performance-mode high_performance --insecure

El PCAP per trucada crea fitxers SIP i RTP separats per a cada trucada:

20250123_143022_abc123_sip.pcap    # SIP signaling
20250123_143022_abc123_rtp.pcap    # RTP media

Les accions d’ordres VoIP funcionen igual que al processador:

sudo lc tap voip -i eth0 \
  --voip-command '/opt/scripts/process-call.sh %callid% %dirname%' \
  --insecure

DNS (tap dns)

Captura DNS amb detecció de túnels i alertes:

Captura DNS amb alertes de túnels:

sudo lc tap dns -i eth0 \
  --tunneling-command 'echo "ALERT: %domain% score=%score%" >> /var/log/tunneling.log' \
  --tunneling-threshold 0.7 \
  --insecure

Captura DNS amb ports personalitzats:

sudo lc tap dns -i eth0 --dns-port 53,5353 --udp-only --insecure

HTTP (tap http)

Captura HTTP amb filtratge d’amfitrió, camí i mètode:

Captura HTTP amb filtratge d’amfitrió:

sudo lc tap http -i eth0 --host "*.example.com" --insecure

Captura HTTP amb desxifratge HTTPS:

sudo lc tap http -i eth0 --tls-keylog /tmp/sslkeys.log --insecure

TLS (tap tls)

Captura de negociacions TLS amb empremtes JA3/JA3S/JA4:

Captura TLS amb filtratge SNI:

sudo lc tap tls -i eth0 --sni "*.example.com" --insecure

Correu electrònic (tap email)

Captura SMTP, IMAP i POP3 amb filtratge d’adreces:

Captura de correu només SMTP:

sudo lc tap email -i eth0 --protocol smtp --insecure

Captura de correu amb filtratge de remitent:

sudo lc tap email -i eth0 --sender "*@suspicious.com" --insecure

RADIUS (tap radius)

El mode RADIUS combina la captura local d’autenticació/comptabilització amb sortides del processador com PCAP, registres estructurats i visualització TUI remota:

sudo lc tap radius -i mirror0 --radius-port 1645,1646 \
  --log-dir /var/log/lippycat --log-streams radius --insecure

Els criteris exactes de compte, MAC, atribut i línia amb àmbit utilitzen les mateixes opcions que sniff radius i hunt radius. La captura RADIUS ordinària no requereix una compilació LI; el lliurament X2 autoritzat opcional es configura independentment. Consulteu Captura RADIUS i POI per veure la configuració completa.

Escriptura PCAP

Tap admet els tres modes PCAP del processador (consulteu el Capítol 8 per obtenir detalls):

PCAP unificat:

sudo lc tap -i eth0 --write-file /var/capture/all.pcap --insecure

PCAP per trucada, activat per defecte per a tap voip:

sudo lc tap voip -i eth0 \
  --per-call-pcap --per-call-pcap-dir /var/capture/calls --insecure

PCAP amb rotació automàtica:

sudo lc tap -i eth0 \
  --auto-rotate-pcap --auto-rotate-pcap-dir /var/capture/bursts \
  --auto-rotate-idle-timeout 30s --auto-rotate-max-size 100M --insecure

Les accions d’ordres (--pcap-command, --voip-command) funcionen igual que al processador.

Servei TUI

Els nodes Tap ofereixen una API de gestió gRPC a --listen (per defecte: :55555), que permet als clients TUI connectar-se per al monitoratge en temps real:

Iniciar el node Tap amb TLS:

sudo lc tap voip -i eth0 --tls-cert server.crt --tls-key server.key

Connectar la TUI des d’un altre terminal:

lc watch remote -P tap-host:55555 --tls-ca ca.crt

Per al desenvolupament local, utilitzeu --insecure tant al node Tap com a la TUI:

sudo lc tap voip -i eth0 --insecure

lc watch remote -P localhost:55555 --insecure

Reenviament cap amunt

Els nodes Tap poden reenviar trànsit capturat a un processador central, actuant com nodes de perifèria en un desplegament jeràrquic:

Un node Tap de perifèria captura localment i reenvia al processador central:

sudo lc tap voip -i eth0 \
  --processor central-processor:55555 \
  --tls-cert edge.crt --tls-key edge.key --tls-ca ca.crt

Això combina l’escriptura PCAP local i l’accés TUI a la perifèria amb l’agregació central.

Telemetria del buffer de captura

Tap utilitza canals normal, prioritari SIP i de sortida combinada. Amb sip_buffer_size: 0, la capacitat SIP coincideix automàticament amb buffer_size; un valor positiu la sobreescriu explícitament.

sip_priority_classified compta cada paquet reconegut i encaminat pel camí prioritari SIP, inclosos els que després es degraden o es descarten definitivament. capture_buffer_sip_demotions compta paquets classificats retinguts al canal normal després d’omplir-se el canal SIP i no és una pèrdua de paquets. capture_buffer_sip_drops compta paquets classificats rebutjats per tots dos canals d’entrada i és una pèrdua definitiva de paquets. Utilitzeu els tres parells de longitud/capacitat dels canals per localitzar l’etapa saturada.

flowchart LR
    subgraph Edge["Edge Tap Node"]
        T[Local Capture]
        LP[(Local PCAP)]
        T --> LP
    end

    subgraph Central["Central Processor"]
        P[Aggregation]
        CP[(Central PCAP)]
        P --> CP
    end

    T -->|gRPC/TLS| P
    TUI1[Local TUI] <-->|gRPC| T
    TUI2[Central TUI] <-->|gRPC| P

Interfície virtual

Exposar trànsit filtrat a eines de tercers mitjançant una interfície de xarxa virtual:

Capturar i exposar trànsit en una interfície virtual:

sudo lc tap voip -i eth0 --virtual-interface --insecure

Supervisar amb Wireshark:

wireshark -i lc0

Alternativament, executar tcpdump:

tcpdump -i lc0 -w filtered.pcap

Requereix la capacitat CAP_NET_ADMIN. Consulteu --vif-name, --vif-type, --vif-buffer-size per a la configuració.

Fitxer de configuració

Totes les opcions de tap es poden establir a ~/.config/lippycat/config.yaml:

tap:
  interfaces:
    - eth0
  bpf_filter: ""
  buffer_size: 10000
  sip_buffer_size: 0 # Automatic: match buffer_size
  batch_size: 100
  batch_timeout_ms: 100
  listen_addr: ":55555"
  id: "edge-tap-01"
  processor_addr: "" # Empty for standalone, set for upstream forwarding

  per_call_pcap:
    enabled: true
    output_dir: "/var/capture/calls"
    file_pattern: "{timestamp}_{callid}.pcap"

  auto_rotate_pcap:
    enabled: false
    output_dir: "/var/capture/bursts"
    idle_timeout: "30s"
    max_size: "100M"

  pcap_command: "gzip %pcap%"
  voip_command: ""
  command_timeout: "30s"
  command_concurrency: 10

  tls:
    cert_file: "/etc/lippycat/certs/server.crt"
    key_file: "/etc/lippycat/certs/server.key"

  voip:
    sip_user: ""
    udp_only: false
    sip_ports: ""
    tcp_performance_mode: "balanced"
    tcp_reassembly_shards: 1

Administració CLI

lippycat ofereix un conjunt d’ordres CLI per gestionar i inspeccionar desplegaments distribuïts. Aquestes ordres segueixen un patró coherent de verb i objecte i generen JSON per facilitar-ne l’ús en scripts.

flowchart LR
    subgraph Commands["CLI Admin Commands"]
        direction TB
        Show["lc show"]
        List["lc list"]
        Set["lc set"]
        Rm["lc rm"]
    end

    subgraph Targets["Resources"]
        direction TB
        Proc[Processor Status]
        Hunters[Hunter Info]
        Filters[Filters]
        Topo[Topology]
        Ifaces[Interfaces]
    end

    Show --> Proc
    Show --> Hunters
    Show --> Topo
    Show --> Filters
    List --> Ifaces
    List --> Hunters
    List --> Filters
    Set --> Filters
    Rm --> Filters

Totes les ordres remotes es connecten a un processador mitjançant gRPC i comparteixen un conjunt d’opcions de connexió. Les ordres locals (show config, list interfaces) s’executen sense connexió a un processador.

Els resultats d’exemple següents utilitzen valors il·lustratius. Els noms i les descripcions de les interfícies depenen de l’amfitrió; els camps JSON opcionals depenen del desplegament i de la telemetria disponible.

Opcions de connexió

Totes les ordres remotes admeten aquestes opcions. TLS està activat per defecte: cal passar explícitament --insecure per desactivar-lo.

Aquestes opcions també es poden definir al fitxer de configuració, sota remote:

remote:
  processor: "processor.example.com:55555"
  insecure: false
  tls:
    ca: "/etc/lippycat/certs/ca.crt"
    cert: "/etc/lippycat/certs/client.crt"
    key: "/etc/lippycat/certs/client.key"
    skip_verify: false

Inspecció amb lc show

L’ordre show obté informació d’un processador en execució. Totes les subordres excepte show config requereixen -P.

show status

Mostra l’estat del processador i les estadístiques agregades:

lc show status -P processor:55555 --tls-ca ca.crt

{
  "storage": {
    "filters": {
      "mode": "yaml",
      "state": "ready",
      "last_outcome": "committed",
      "commits": 3
    }
  },
  "processor_id": "central-proc",
  "status": "healthy",
  "total_hunters": 1,
  "healthy_hunters": 1,
  "warning_hunters": 0,
  "error_hunters": 0,
  "total_packets_received": 12500,
  "total_packets_forwarded": 0,
  "total_filters": 3
}

show hunter

Mostra els detalls d’un Hunter concret:

lc show hunter --id edge-01 -P processor:55555 --tls-ca ca.crt

{
  "hunter_id": "edge-01",
  "hostname": "capture-node-1",
  "remote_addr": "10.0.1.10:45678",
  "status": "healthy",
  "connected_duration_sec": 3600,
  "interfaces": ["eth0"],
  "stats": {
    "packets_captured": 500000,
    "packets_matched": 12500,
    "packets_forwarded": 12500,
    "packets_dropped": 0,
    "capture_buffer_regular_drops": 0,
    "capture_buffer_sip_drops": 0,
    "capture_buffer_sip_demotions": 0,
    "batch_channel_drops": 0,
    "capture_buffer_regular_len": 0,
    "capture_buffer_regular_capacity": 1000,
    "capture_buffer_sip_len": 0,
    "capture_buffer_sip_capacity": 100,
    "capture_buffer_output_len": 0,
    "capture_buffer_output_capacity": 100,
    "buffer_bytes": 1048576,
    "active_filters": 3,
    "cpu_percent": 12.5,
    "memory_rss_bytes": 67108864,
    "rtp_ownership_unresolved": 0,
    "rtp_ownership_ambiguous": 0,
    "identity_inheritance_suppressed": 0,
    "tcp_established_idle_retentions": 0,
    "tcp_pre_rearm_discarded_chunks": 0,
    "tcp_rearm_rejected_chunks": 0
  },
  "capabilities": {
    "filter_types": ["sip_user", "ip_address"],
    "max_buffer_size": 67108864,
    "gpu_acceleration": true,
    "af_xdp": false
  }
}

show topology

Mostra tot l’arbre de la topologia distribuïda. És útil per verificar desplegaments jeràrquics:

lc show topology -P processor:55555 --tls-ca ca.crt

{
  "processor_id": "central-proc",
  "address": ":55555",
  "status": "healthy",
  "hierarchy_depth": 0,
  "reachable": true,
  "hunters": [
    {
      "hunter_id": "edge-01",
      "hostname": "capture-node-1",
      "remote_addr": "10.0.1.10:45678",
      "status": "healthy",
      "connected_duration_sec": 3600,
      "interfaces": ["eth0"],
      "stats": {
        "packets_captured": 500000,
        "packets_matched": 12500,
        "packets_forwarded": 12500,
        "packets_dropped": 0,
        "capture_buffer_regular_drops": 0,
        "capture_buffer_sip_drops": 0,
        "capture_buffer_sip_demotions": 0,
        "batch_channel_drops": 0,
        "capture_buffer_regular_len": 0,
        "capture_buffer_regular_capacity": 1000,
        "capture_buffer_sip_len": 0,
        "capture_buffer_sip_capacity": 100,
        "capture_buffer_output_len": 0,
        "capture_buffer_output_capacity": 100,
        "buffer_bytes": 1048576,
        "active_filters": 3,
        "cpu_percent": 12.5,
        "memory_rss_bytes": 67108864,
        "rtp_ownership_unresolved": 0,
        "rtp_ownership_ambiguous": 0,
        "identity_inheritance_suppressed": 0,
        "tcp_established_idle_retentions": 0,
        "tcp_pre_rearm_discarded_chunks": 0,
        "tcp_rearm_rejected_chunks": 0
      },
      "capabilities": {
        "filter_types": ["sip_user", "ip_address"],
        "max_buffer_size": 67108864,
        "gpu_acceleration": true,
        "af_xdp": false
      }
    }
  ],
  "downstream_processors": [
    {
      "processor_id": "region-east",
      "address": "10.0.2.1:55555",
      "status": "healthy",
      "upstream_processor": "central-proc:55555",
      "hierarchy_depth": 1,
      "reachable": true
    }
  ]
}

show filter

Mostra els detalls d’un filtre concret:

lc show filter --id myfilter -P processor:55555 --tls-ca ca.crt

show config

Mostra la configuració local com a JSON. Aquesta és l’única subordre de show que no requereix connexió a un processador:

lc show config

Llistats amb lc list

list interfaces

Descobreix les interfícies de xarxa disponibles per a la captura. És una ordre local: no cal connexió a un processador:

lc list interfaces

NAME     TYPE       STATE  ADDRESSES                NOTES
eth0     Ethernet   up     192.168.1.42/24           default route
wlan0    Wi-Fi      down   —
lo       Loopback   up     127.0.0.1/8, ::1/128
any      Aggregate  —      —                        all network interfaces

7 additional capture devices hidden; use --all to show them.

La vista per defecte inclou interfícies físiques, de bucle local, VPN/túnel i interfícies de xarxa sense classificar, encara que estiguin inactives. any només apareix quan la biblioteca de captura l’ofereix. S’amaguen els ponts reconeguts, determinats enllaços virtuals com ara veth de contenidors i dispositius TAP de màquines virtuals, i fonts de captura especials com D-Bus i NFQUEUE; les interfícies amb una ruta per defecte detectada continuen visibles. Utilitzeu --all per veure tots els dispositius de captura. Les llistes llargues d’adreces es reparteixen en línies de continuació sense ometre cap adreça.

A Linux, les metadades del sistema operatiu proporcionen els tipus d’interfície, l’estat operatiu i indicacions sobre les rutes per defecte IPv4/IPv6 de la taula d’encaminament principal. Altres plataformes utilitzen les metadades disponibles i indiquen com a desconegudes les dades que no poden obtenir. La indicació de la ruta per defecte no avalua l’encaminament basat en polítiques ni selecciona automàticament la interfície adequada per a la vostra captura.

lc list interfaces --all
lc list interfaces --names
lc list interfaces --json --check

--names imprimeix un nom per línia i no es pot combinar amb --json ni --check. El JSON conté una matriu interfaces, un hidden_count i, opcionalment, warnings. Cada interfície inclou name, type, state i default_route; description i addresses s’inclouen quan estan disponibles. Les entrades d’adreça contenen ip i un prefix_len opcional.

El llistat no comprova els permisos ni requereix root. --check obre breument els dispositius de xarxa mostrats sense mode promiscu i els tanca sense llegir paquets. La columna CAPTURE indica available, unavailable o skipped; els errors apareixen a NOTES. Les fonts de captura especials s’ometen. Amb --json, els resultats utilitzen els camps capture_access i, opcionalment, capture_error. Aquests resultats descriuen l’accés en el moment de la comprovació; les captures posteriors poden utilitzar opcions diferents.

Els errors d’accés a dispositius individuals no fan fallar l’ordre. Els errors d’enumeració retornen un estat de sortida diferent de zero i escriuen diagnòstics a stderr (--json utilitza un objecte d’error JSON). Els avisos de descobriment apareixen a stderr en mode de text/noms i dins del resultat en mode JSON.

list hunters

Llista els Hunters connectats a un processador remot:

Llista tots els Hunters connectats:

lc list hunters -P processor:55555 --tls-ca ca.crt

list filters

Llista els filtres configurats en un processador remot:

Llista tots els filtres:

lc list filters -P processor:55555 --tls-ca ca.crt

Llista els filtres d’un Hunter concret:

lc list filters -P processor:55555 --tls-ca ca.crt --hunter hunter-1

Creació de filtres amb lc set

L’ordre set filter crea o actualitza filtres en un processador (semàntica d’upsert). Funciona en dos modes: en línia i amb fitxer.

Mode en línia

Especifiqueu les propietats del filtre directament mitjançant opcions:

Creeu un filtre d’usuari SIP:

lc set filter -P processor:55555 --tls-ca ca.crt \
  --type sip_user --pattern "alicent@example.com"

Creeu un filtre de domini DNS amb comodí:

lc set filter -P processor:55555 --tls-ca ca.crt \
  --type dns_domain --pattern "*.malware-domain.com"

Creeu un filtre d’empremta TLS JA3:

lc set filter -P processor:55555 --tls-ca ca.crt \
  --type tls_ja3 --pattern e7d705a3286e19ea42f587b344ee6865

Creeu un filtre d’interval IP CIDR:

lc set filter -P processor:55555 --tls-ca ca.crt \
  --type ip_address --pattern "192.168.1.0/24"

Creeu un filtre de compte RADIUS exacte amb una revisió explícita:

lc set filter -P processor:55555 --tls-ca ca.crt \
  --type radius_username --pattern 'alice@example.test' --revision 1

Els filtres MAC requereixen exactament el perfil d’interpretació admès:

lc set filter -P processor:55555 --tls-ca ca.crt \
  --type radius_mac --pattern '02-00-00-00-00-01' --revision 1 \
  --radius-mac-profile calling-station-id-uppercase-hyphen-v1

Creeu un filtre amb un ID i una descripció personalitzats:

lc set filter -P processor:55555 --tls-ca ca.crt \
  --id voip-monitor-01 \
  --type sip_user --pattern "*456789" \
  --description "Monitor calls to 456789"

Seleccioneu Hunters concrets:

lc set filter -P processor:55555 --tls-ca ca.crt \
  --type sip_user --pattern "robb@example.com" \
  --hunters edge-01,edge-02

Si s’omet --id, es genera automàticament un UUID.

Mode amb fitxer (per lots)

Importeu diversos filtres d’un fitxer YAML:

lc set filter -P processor:55555 --tls-ca ca.crt -f filters.yaml

El fitxer YAML utilitza el mateix format que el fitxer de filtres del processador. Els criteris RADIUS compostos han d’utilitzar el mode amb fitxer; consulteu l’esquema i exemple de filtre RADIUS.

Tipus de filtre

Per veure la llista completa de tipus de filtre, descripcions, patrons amb comodins i detalls de coincidència, consulteu l’Apèndix E: Referència dels tipus de filtre.

Opcions de set filter

Eliminació de filtres amb lc rm

Filtre individual

lc rm filter --id myfilter -P processor:55555 --tls-ca ca.crt

Eliminació per lots

Elimineu diversos filtres a partir d’un fitxer d’IDs (un per línia):

lc rm filter -f filter-ids.txt -P processor:55555 --tls-ca ca.crt

El format del fitxer és senzill: un ID de filtre per línia; s’ignoren els comentaris amb # i les línies en blanc.

# VoIP filters to remove
voip-monitor-01
voip-monitor-02

# DNS filter
dns-tunnel-detector

Sortida JSON i codis de sortida

Totes les ordres remotes escriuen JSON a stdout (resultats) i stderr (errors). La sortida es formata amb sagnat quan s’escriu en un terminal i de manera compacta quan es passa per una canonada.

Codis de sortida

Format dels errors

{
  "error": "processor address is required (use --processor or set remote.processor in config)",
  "code": "UNAVAILABLE"
}

Exemples de scripts

Script de comprovació de l’estat

#!/bin/bash
status=$(lc show status -P processor:55555 --tls-ca /etc/lippycat/ca.crt \
  2>/dev/null | jq -r '.status')
if [ "$status" = "healthy" ]; then
    echo "OK"
else
    echo "UNHEALTHY: $status"
    exit 1
fi

Supervisió del nombre de Hunters

watch -n 5 'lc show status -P processor:55555 --tls-ca ca.crt | \
  jq "{total: .total_hunters, healthy: .healthy_hunters}"'

Exportació d’una instantània de la topologia

lc show topology -P processor:55555 --tls-ca ca.crt \
  > topology-$(date +%Y%m%d).json

Cicle de vida dels filtres

Creeu un filtre:

lc set filter -P processor:55555 --tls-ca ca.crt \
  --id suspect-01 --type sip_user --pattern "*456789"

Comproveu que existeix:

lc show filter --id suspect-01 -P processor:55555 --tls-ca ca.crt

Llista tots els filtres:

lc list filters -P processor:55555 --tls-ca ca.crt

Elimineu el filtre quan hàgiu acabat:

lc rm filter --id suspect-01 -P processor:55555 --tls-ca ca.crt

Monitoratge remot amb la TUI

El mode remot de la TUI (lc watch remote) es connecta als processadors i mostra dades de paquets en directe dels Hunters distribuïts. Us ofereix una vista centralitzada de diversos segments de xarxa sense executar cap captura local.

flowchart LR
    subgraph Edge["Network Edge"]
        H1[Hunter 1]
        H2[Hunter 2]
        H3[Hunter 3]
    end

    subgraph Central["Processor"]
        P[Aggregation]
    end

    H1 -->|gRPC| P
    H2 -->|gRPC| P
    H3 -->|gRPC| P
    TUI["lc watch remote"] <-->|gRPC/TLS| P

Inici ràpid

Connecteu-vos directament a un processador:

lc watch remote -P processor.example.com:55555 --tls-ca ca.crt

Connecteu-vos mitjançant un fitxer de nodes:

lc watch remote --nodes-file nodes.yaml

Alternativament, utilitzeu la ubicació per defecte ~/.config/lippycat/nodes.yaml:

lc watch remote

Connecteu-vos amb TLS:

lc watch remote -P processor.example.com:55555 --tls-ca ca.crt

Connecteu-vos amb TLS mutu:

lc watch remote -P processor.example.com:55555 --tls-ca ca.crt --tls-cert client.crt --tls-key client.key

Per a proves locals:

lc watch remote -P localhost:55555 --insecure

Configuració del fitxer de nodes

Utilitzeu --processor (-P) per connectar-vos directament a un sol processador o node Tap. Utilitzeu --nodes-file si voleu que la TUI carregui un o diversos processadors d’un YAML en iniciar-se. Podeu proporcionar totes dues opcions; la TUI posarà a la cua les connexions de totes dues fonts.

El fitxer de nodes indica a la TUI a quins processadors i Hunters s’ha de connectar.

Ubicació del fitxer

La TUI cerca nodes.yaml en aquest ordre:

1. Camí indicat amb --nodes-file
2. ~/.config/lippycat/nodes.yaml
3. ./nodes.yaml (directori actual)

Format

processors:
  - name: main-processor
    address: processor.example.com:55555
    tls:
      enabled: true
      ca_file: /etc/lippycat/certs/ca.crt
      cert_file: /etc/lippycat/certs/client.crt
      key_file: /etc/lippycat/certs/client.key
      skip_verify: false

  - name: backup-processor
    address: 192.168.1.101:55555

Camps de configuració

Cada node pot tenir la seva pròpia configuració TLS, cosa que permet entorns mixtos (p. ex., producció amb mTLS i desenvolupament sense xifratge).

Navegació per la TUI

Tecles globals

Vista de paquets

La llista de paquets i el panell de detalls inclouen metadades RADIUS descodificades, amb les credencials ocultades, rebudes dels Hunters i nodes Tap; RADIUS no requereix una subordre watch específica.

Vista Nodes

Vista de trucades (VoIP)

Pestanya Nodes

La pestanya Nodes mostra els processadors connectats i els seus Hunters en una vista d’arbre:

┌─ Nodes ────────────────────────────────────────────┐
│                                                    │
│  Processor: main-processor (192.168.1.100:55555)   │
│  ├─ edge-hunter-01 (10.0.1.10)                     │
│  │  Status: ACTIVE | Packets: 1,234 | Dropped: 0   │
│  │  Interfaces: eth0                               │
│  │                                                 │
│  └─ edge-hunter-02 (10.0.1.11)                     │
│     Status: ACTIVE | Packets: 5,678 | Dropped: 2   │
│     Interfaces: eth1, wlan0                        │
│                                                    │
│  [Enter node address to add...]                    │
└────────────────────────────────────────────────────┘

Cada Hunter mostra:

• Estat: ACTIVE, IDLE o DISCONNECTED
• Paquets: capturats, coincidents, reenviats, descartats
• Filtres actius: nombre de filtres aplicats
• Interfícies: interfícies de xarxa supervisades
• Últim senyal de vida: temps des de l’última comprovació de l’estat

Indicadors de canvi

La CPU i la RAM utilitzen colors de text persistents segons la utilització: el color de primer pla normal del tema per sota del 70%, taronja Solarized (#cb4b16) a partir del 70% i vermell Solarized (#dc322f) a partir del 90%. L’augment de nivell requereix tres mostres reals diferents de mètriques; les instantànies repetides i els redibuixats no compten. El color de nivell elevat desapareix per sota del 65% i el de nivell alt per sota del 85%. Aquests llindars de presentació no modifiquen l’estat del node. Els valors de CPU/RAM ja no parpellegen ni mostren fletxes de canvi.

El percentatge de CPU mostrat continua sent l’ús brut del procés: el 100% representa un nucli, de manera que els valors poden superar el 100%. La classificació del color divideix aquest percentatge per la capacitat efectiva de CPU indicada en nuclis, incloses les quotes fraccionàries. La capacitat reflecteix l’afinitat de CPU visible i les restriccions de quota dels cgroups, inclosos els avantpassats restrictius; no és una reserva garantida de CPU. El color de la RAM compara el RSS del procés amb el límit de memòria indicat del cgroup. És una relació aproximada entre procés i límit: exclou altra memòria imputada al cgroup.

Totes dues mètriques comparteixen els llindars percentuals validats watch.nodes_resources.elevated (per defecte 70) i watch.nodes_resources.high (per defecte 90). Els valors han de ser finits i complir 0 < elevated < high <= 100; els parells no vàlids es registren i se substitueixen pels dos valors per defecte. El marge de retorn per defecte és de cinc punts percentuals. Amb llindars personalitzats baixos o molt propers, el marge es redueix a la meitat del llindar elevat o a la meitat de la distància entre els llindars, el que sigui més petit. Si falten dades de capacitat o límits de memòria, les mètriques no són vàlides o els nodes estan desconnectats, el text és neutre. Els camps addicionals de telemetria de capacitat i marca temporal de les mostres mantenen la compatibilitat: els clients antics els ignoren, mentre que els nodes o intermediaris antics els poden ometre. Sense una marca temporal d’una mostra real de mètriques, els colors dels recursos es mantenen neutres encara que es puguin mostrar els valors.

Els totals de paquets comparteixen un indicador d’activitat discret per node. Els totals de paquets capturats o reenviats que augmenten utilitzen breument un fons verd (#859900) només quan canvia el total arrodonit mostrat; els reinicis dels comptadors estableixen una nova referència sense ressaltat. Els canvis de filtres utilitzen un fons blau neutre (#268bd2) amb una diferència amb signe. Aquestes cel·les temporals utilitzen text Solarized base3 (#fdf6e3). NEW i RECOVERED marquen transicions observades del cicle de vida. Les instantànies inicials i els canvis de subscripció estableixen una referència sense avisos d’incorporació. Els comptadors sense activitat no impliquen que els nodes siguin obsolets o estiguin desconnectats.

La taula i el graf comparteixen els mateixos indicadors. Una línia fixa d’esdeveniments recents mostra l’última transició de cicle de vida o d’estat, la seva antiguitat i qualsevol altre esdeveniment dels 30 segons anteriors. Desapareix al cap de 30 segons i s’omet en terminals molt baixos. Els indicadors de comptadors i filtres duren aproximadament un segon i els de cicle de vida uns cinc segons; expiren en el següent tic de la interfície encara que la captura estigui en pausa.

A Settings en mode remot, seleccioneu Nodes highlighting i premeu Enter per alternar entre normal (per defecte) i quiet. El mode silenciós conserva els colors persistents del text de CPU/RAM, les etiquetes, l’estat i els esdeveniments recents, però suprimeix els fons temporals de comptadors, filtres i cicle de vida i els ressalts de les vores. El canvi té efecte immediat sense reiniciar la captura i es desa com a watch.nodes_highlighting al fitxer de configuració.

Afegir nodes de manera interactiva

Podeu afegir nodes sense editar el fitxer de nodes:

1. Aneu a la pestanya Nodes (Alt+2)
2. Seleccioneu el camp d’entrada i premeu Enter
3. Escriviu l’adreça del processador (p. ex., 192.168.1.100:55555)
4. Feu clic a Confirm o premeu Enter per connectar-vos; Cancel tanca el diàleg per afegir un node. Feu clic al camp d’adreça per donar-li el focus.

Gestió de subscripcions a Hunters

Per defecte, en connectar-vos a un processador es transmeten els paquets de tots els seus Hunters. Les subscripcions a Hunters us permeten centrar-vos en segments de xarxa concrets.

Subscripció a Hunters

Seleccioneu un processador a la pestanya Nodes i premeu s. Feu clic a les caselles dels Hunters o a les seves etiquetes per alternar les subscripcions, o navegueu amb ↑ / ↓ i alterneu-les amb Space. All i None modifiquen tota la llista. Trieu Confirm (o premeu Enter mentre la llista tingui el focus) per aplicar els canvis; Cancel o Esc els descarta. Confirmar una selecció buida no subscriu a cap Hunter.

Cancel·lació de la subscripció

• Un sol Hunter: aneu al Hunter i premeu d
• Tots els Hunters: obriu el selector (s), desmarqueu-los tots i confirmeu

Avantatges

• Redueix l’amplada de banda: només els Hunters als quals esteu subscrits transmeten paquets a la vostra TUI
• Permet centrar-vos en segments concrets sense soroll dels altres
• Diversos clients TUI poden tenir subscripcions independents al mateix processador

Gestió de filtres

La TUI ofereix gestió interactiva de filtres per als processadors connectats i els seus Hunters. Els filtres controlen quin trànsit capturen i reenvien els Hunters: són el mecanisme principal per seleccionar trucades, dominis o amfitrions concrets en un desplegament distribuït. Els filtres es poden aplicar globalment (a tots els Hunters) o a Hunters concrets.

Gestió de filtres des de la TUI

A la pestanya Nodes, premeu f per obrir la vista de gestió de filtres. Això us permet:

• Veure els filtres actius del processador connectat
• Crear filtres nous amb tipus i patró
• Activar/desactivar filtres sense eliminar-los
• Eliminar els filtres que ja no necessiteu

Feu clic en una fila de filtre per seleccionar-la i després utilitzeu Edit o Delete; fer clic a la casella alterna l’estat d’activació sense obrir l’editor. New crea un filtre i Close tanca el gestor. Search, Type i Status es poden clicar; Clear search elimina el text de cerca. L’eliminació requereix confirmació.

A l’editor, feu clic als camps de text, les opcions de tipus, la casella d’activació o els Hunters de destinació. Save valida i envia l’esborrany; Cancel el descarta. El selector de destinataris només ofereix Hunters compatibles, amb els controls All, None, Confirm i Cancel. Cancel·lar la selecció de destinataris conserva l’esborrany pare. Una llista buida de destinataris del filtre significa tots els Hunters compatibles; això és diferent d’una subscripció de paquets buida, que no rep res.

Els canvis de filtre tenen efecte immediat: el processador envia els filtres actualitzats a tots els Hunters connectats.

L’editor interactiu gestiona els tipus de filtre simples de VoIP, DNS, TLS, HTTP, correu electrònic i universals. Pot mostrar i eliminar filtres RADIUS existents, però per crear-los, editar-los, activar-los, desactivar-los o revisar-los cal lc set filter, per conservar les dades estructurades d’àmbit i revisió.

Tipus de filtre

L’editor de la TUI admet filtres de VoIP, DNS, TLS, HTTP, correu electrònic i universals. La creació i modificació de filtres RADIUS continuen restringides a CLI/YAML. Consulteu l’Apèndix E: Referència dels tipus de filtre per veure la llista completa de tipus gestionats des de la CLI.

Alternativa CLI

Per a operacions amb filtres mitjançant scripts o per lots, utilitzeu les ordres CLI (vegeu Administració amb la CLI):

Llisteu els filtres actuals:

lc list filters -P processor:55555 --tls-ca ca.crt

Creeu un filtre:

lc set filter -P processor:55555 --tls-ca ca.crt \
  --type sip_user --pattern "alicent@example.com"

Mostreu els detalls del filtre:

lc show filter --id myfilter -P processor:55555 --tls-ca ca.crt

Elimineu un filtre:

lc rm filter --id myfilter -P processor:55555 --tls-ca ca.crt

Configuració TLS

Opcions de la línia d’ordres

Utilitzeu TLS de servidor per verificar el certificat del processador:

lc watch remote -P processor.example.com:55555 --tls-ca ca.crt

Utilitzeu TLS mutu perquè totes dues parts s’autentiquin:

lc watch remote -P processor.example.com:55555 --tls-ca ca.crt --tls-cert client.crt --tls-key client.key

Ometeu la verificació per tenir una connexió xifrada sense comprovació d’identitat (només per a proves):

lc watch remote -P processor.example.com:55555 --tls-skip-verify

Desactiveu completament TLS per a proves. El mode de producció bloqueja aquesta opció:

lc watch remote -P localhost:55555 --insecure

TLS per node al fitxer de nodes

Quan us connecteu a diversos processadors amb autoritats de certificació diferents:

processors:
  - name: production
    address: prod-processor.internal:55555
    tls:
      enabled: true
      ca_file: /etc/lippycat/certs/prod-ca.crt
      cert_file: /etc/lippycat/certs/prod-client.crt
      key_file: /etc/lippycat/certs/prod-client.key

  - name: staging
    address: staging-processor.internal:55555
    tls:
      enabled: true
      ca_file: /etc/lippycat/certs/staging-ca.crt

Fitxer de configuració

Els valors per defecte de TLS es poden definir al fitxer de configuració:

watch:
  tls:
    enabled: true
    ca_file: "/etc/lippycat/certs/ca.crt"
    cert_file: ""
    key_file: ""

La configuració TLS per node de nodes.yaml substitueix aquests valors per defecte.

Supervisió de diversos nodes

Desplegament en diversos centres

processors:
  - name: nyc-processor
    address: nyc-monitor.company.com:55555
    tls:
      enabled: true
      ca_file: /etc/lippycat/certs/ca.crt

  - name: london-processor
    address: lon-monitor.company.com:55555
    tls:
      enabled: true
      ca_file: /etc/lippycat/certs/ca.crt

Segmentació de xarxa

Superviseu diferents zones des d’una sola TUI:

processors:
  - name: dmz-processor
    address: 192.168.1.10:55555

  - name: internal-processor
    address: 10.0.0.50:55555

  - name: guest-wifi-processor
    address: 172.16.0.20:55555

Subscripcions a Hunters preseleccionades

Limiteu de quins Hunters rebeu dades en iniciar:

processors:
  - name: main-processor
    address: processor.example.com:55555
    subscribed_hunters:
      - "edge-hunter-01"
      - "edge-hunter-03"

Resolució de problemes

“Failed to connect to node”

Comproveu que el processador està en execució i escoltant:

ss -tlnp | grep 55555

Proveu la connectivitat de xarxa:

nc -zv processor-host 55555

Comproveu les regles del tallafoc:

sudo iptables -L -n | grep 55555

No es mostren paquets

• Comproveu que els Hunters estan realment connectats al processador: lc list hunters -P processor:55555 --tls-ca ca.crt
• Comproveu que hi ha trànsit a la interfície del Hunter: sudo tcpdump -i eth0 -c 10
• Comproveu si esteu subscrits a algun Hunter (premeu s a la pestanya Nodes)
• Proveu-ho sense filtres BPF per descartar un filtratge excessiu

Desconnexions freqüents

• Comproveu l’estabilitat de la xarxa: ping -c 100 processor-host
• Superviseu l’ús de recursos del processador: top -p $(pgrep lippycat)
• Augmenteu els límits de connexió del sistema: ulimit -n 4096
• Reviseu si hi ha errors als registres del processador

Notes sobre el rendiment

La TUI remota és lleugera: només mostra dades, no captura paquets:

Ajusteu --buffer-size per controlar l’ús de memòria (per defecte: 10.000 paquets).

Límits recomanats

• Processadors per TUI: 5-10 per a una interfície àgil
• Total de Hunters visibles: 50-100 segons la latència de xarxa

Manual d’operacions

Aquest capítol tracta el desplegament, la supervisió i el manteniment de lippycat en producció. Inclou la configuració de serveis systemd, les comprovacions d’estat, la gestió de registres, la resposta a incidents i els procediments de manteniment.

Desplegament

Requisits del sistema

Instal·lació del binari

Compileu a partir del codi font:

make build-release

sudo cp bin/lc /usr/local/bin/

sudo chmod +x /usr/local/bin/lc

Atorgueu capacitats de captura per evitar executar-lo com a root:

sudo setcap cap_net_raw,cap_net_admin=eip /usr/local/bin/lc

Creació de la configuració

sudo mkdir -p /etc/lippycat/certs

sudo cp config.yaml /etc/lippycat/

sudo chown root:root /etc/lippycat/config.yaml

sudo chmod 600 /etc/lippycat/config.yaml

Serveis systemd

Captura autònoma (Sniff)

# /etc/systemd/system/lippycat.service
[Unit]
Description=lippycat Network Traffic Capture
After=network.target

[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/lc sniff voip -i eth0 --config /etc/lippycat/config.yaml
Restart=always
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Node processador

# /etc/systemd/system/lippycat-processor.service
[Unit]
Description=lippycat Processor Node
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/lc process \
  --listen 0.0.0.0:55555 \
  --tls-cert /etc/lippycat/certs/server.crt \
  --tls-key /etc/lippycat/certs/server.key \
  --per-call-pcap --per-call-pcap-dir /var/capture/calls \
  --filter-file /etc/lippycat/filters.yaml
Restart=always
RestartSec=5
LimitNOFILE=65536
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Node Hunter

# /etc/systemd/system/lippycat-hunter.service
[Unit]
Description=lippycat Hunter Node
After=network.target

[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/lc hunt voip -i eth0 \
  --processor processor.internal:55555 \
  --tls-ca /etc/lippycat/certs/ca.crt
Restart=always
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Activació i inici

sudo systemctl daemon-reload

sudo systemctl enable lippycat-processor

sudo systemctl start lippycat-processor

sudo systemctl status lippycat-processor

Comprovacions de l’estat

Transport d’esdeveniments normalitzats

Confirmeu la negociació del mode d’esdeveniments als registres dels nodes, genereu una transacció DNS o HTTP coneguda i localitzeu-la al registre estructurat del processador i a la cronologia d’esdeveniments de la TUI. Configureu alertes per a l’esgotament de l’spool del productor o del WAL del processador, els lots rebutjats, les omissions per compatibilitat i els buits en la seqüència d’esdeveniments. Verifiqueu per separat el PCAP local del Tap quan calgui evidència dels paquets.

La versió 1 de la subscripció TUI comença en un límit de dades en directe i mai no reprodueix un interval de desconnexió. Després d’una interrupció, és normal que hi hagi un buit en reconnectar. És diferent de l’expulsió local, en què l’anell limitat de la TUI elimina una fila antiga que ja havia arribat. La pèrdua durant el transport afecta la completesa de les dades; l’expulsió només afecta la finestra de visualització.

En les actualitzacions graduals, actualitzeu els processadors abans que els productors d’esdeveniments i manteniu el mode de paquets com a base de compatibilitat. Activeu el mecanisme alternatiu només després de comprovar-ne l’impacte en l’amplada de banda i la privadesa. Manteniu desactivades les opcions d’inclusió de camps sensibles i metadades de fitxers tret que siguin necessàries, i protegiu els spools d’esdeveniments, els WAL, els registres i el transport de la TUI com a evidències de captura.

Emmagatzematge i recuperació de l’spool d’esdeveniments

El reenviament fiable d’esdeveniments emmagatzema els lots no confirmats en un directori spool exclusiu. No compartiu mai aquest directori entre processos ni n’editeu els fitxers mentre el procés propietari estigui en execució. El límit de 4 MiB de càrrega útil codificada continua actiu quan es desactiva el límit total de bytes lògics.

El límit configurat i l’estat pendent descriuen els bytes lògics que esperen confirmació. L’ús físic del disc pot ser més alt mentre els fitxers confirmats o expulsats esperen que s’eliminin, de manera que cal supervisar per separat l’espai lliure del sistema de fitxers. La neteja es torna a intentar en iniciar i durant les actualitzacions posteriors de l’spool; els registres retirats no es tornen a enviar.

Si l’emmagatzematge no pot conservar un esdeveniment i la cobertura exacta de la seva pèrdua, el reenviament s’atura en lloc d’informar d’una transmissió correcta. Un error que deixi incerta la durabilitat també bloqueja el reenviament i els canvis de l’spool. Atureu el node afectat i torneu a obrir el mateix directori per recuperar-ne l’últim estat complet. En cas d’errors de propietat, corrupció o recuperació, conserveu tot el directori, corregiu la causa indicada i reinicieu. Aparteu-lo només quan accepteu explícitament que tots els esdeveniments pendents es perdin.

Abans d’una actualització que canviï l’empremta de la política d’anàlisi d’esdeveniments, buideu els registres pendents de l’spool en mode d’esdeveniments amb la versió anterior i la seva configuració original. Atureu les captures noves, deixeu que es confirmin els lots pendents i comproveu que el recompte pendent arriba a zero abans d’aturar el procés antic. Els registres pendents incompatibles bloquegen intencionadament l’inici amb la política nova; l’aplicació no els descarta ni els reinterpreta silenciosament. Si l’inici informa d’una discrepància de política, conserveu el directori i torneu-lo a obrir amb la versió i configuració anteriors per completar la transmissió.

Comprovació ràpida de l’estat

Comproveu si el servei està en execució:

systemctl is-active lippycat-processor

Comproveu si el processador funciona correctament:

lc show status -P localhost:55555 --tls-ca ca.crt

Comproveu quins Hunters estan connectats:

lc list hunters -P localhost:55555 --tls-ca ca.crt

Script de comprovació diària de l’estat

#!/bin/bash
# daily-health-check.sh

echo "=== lippycat Health Check — $(date) ==="

# Service status
echo "1. Service Status:"
systemctl is-active lippycat-processor
systemctl is-active lippycat-hunter

# Resource usage
echo -e "\n2. Resource Usage:"
ps aux | grep "[l]c " | head -5

# Disk space for PCAP files
echo -e "\n3. PCAP Storage:"
df -h /var/capture/ 2>/dev/null || echo "PCAP directory not configured"

# Processor status (distributed deployments)
echo -e "\n4. Processor Status:"
lc show status -P localhost:55555 --tls-ca /etc/lippycat/certs/ca.crt 2>&1

# Recent errors in logs
echo -e "\n5. Recent Errors (last 24h):"
journalctl -u 'lippycat*' --since "24 hours ago" --priority=err --no-pager -q

echo -e "\n=== Health Check Complete ==="

Supervisió de les connexions dels Hunters

Observeu el nombre de Hunters en temps real:

watch -n 5 'lc show status -P localhost:55555 --tls-ca ca.crt | \
  jq "{total: .total_hunters, healthy: .healthy_hunters}"'

Utilitzeu aquest script per generar alertes quan faltin Hunters:

#!/bin/bash
expected=3
actual=$(lc show status -P localhost:55555 --tls-ca ca.crt 2>/dev/null | \
  jq -r '.healthy_hunters')
if [ "$actual" -lt "$expected" ]; then
    echo "ALERT: Only $actual/$expected hunters connected"
    exit 1
fi

Gestió de registres

lippycat utilitza registres estructurats a stdout/stderr. Quan s’executa sota systemd, els registres van al journal.

Visualització de registres

Seguiu els registres en directe:

journalctl -u lippycat-processor -f

Mostreu els registres de l’última hora:

journalctl -u lippycat-processor --since "1 hour ago"

Mostreu només els errors:

journalctl -u lippycat-processor --priority=err

Mostreu els registres de tots els serveis lippycat:

journalctl -u 'lippycat*' --since today

Rotació de registres

Si es registren dades en fitxers en lloc del journal:

# /etc/logrotate.d/lippycat
/var/log/lippycat/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    create 644 root root
}

Anàlisi de registres

#!/bin/bash
# Quick error summary from journal
echo "Error Summary (last 24h):"
journalctl -u 'lippycat*' --since "24 hours ago" --priority=err --no-pager | \
  awk '{for(i=5;i<=NF;i++) printf "%s ", $i; print ""}' | \
  sort | uniq -c | sort -nr | head -10

Resposta a incidents

Ús elevat de memòria

Gravetat: crítica; pot provocar una terminació per OOM

1. Comproveu l’ús actual:

   ps aux | grep "[l]c "
   top -p $(pgrep -f "lc.*process")
   

2. Canvieu al mode optimitzat per a memòria:

   sudo systemctl stop lippycat-processor
   # Edit config: tcp_performance_mode: "memory"
   sudo systemctl start lippycat-processor
   

3. Reinicieu d’emergència si la memòria supera els límits:

   sudo systemctl restart lippycat-processor
   

Servei aturat

1. Comproveu l’estat i els registres recents:

   sudo systemctl status lippycat-processor
   journalctl -u lippycat-processor --lines=50
   

2. Intenteu reiniciar:

   sudo systemctl restart lippycat-processor
   sleep 5
   sudo systemctl status lippycat-processor
   

3. Si el reinici falla, proveu una configuració mínima:

   sudo systemctl stop lippycat-processor
   lc process --listen :55555 --insecure  # Minimal, no PCAP, no TLS
   

Desconnexions de Hunters

Els Hunters es reconnecten automàticament amb espera exponencial (vegeu el Capítol 7: Resiliència). Si els Hunters continuen desconnectats:

1. Comproveu l’estat del servei Hunter al node perifèric:

   ssh edge-node systemctl status lippycat-hunter
   

2. Verifiqueu la connectivitat de xarxa:

   ssh edge-node nc -zv processor.internal 55555
   

3. Comproveu si hi ha problemes amb els certificats TLS:

   journalctl -u lippycat-hunter --since "1 hour ago" | grep -i tls
   

Recollida de dades de diagnòstic

#!/bin/bash
# collect-diagnostics.sh
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
DIAG_DIR="/tmp/lippycat_diag_$TIMESTAMP"
mkdir -p "$DIAG_DIR"

echo "Collecting diagnostics..."

# System info
uname -a > "$DIAG_DIR/system.txt"
cat /etc/os-release >> "$DIAG_DIR/system.txt"

# Service status
systemctl status 'lippycat*' > "$DIAG_DIR/services.txt" 2>&1

# Process info
ps aux | grep "[l]c " > "$DIAG_DIR/processes.txt"
free -h > "$DIAG_DIR/memory.txt"
df -h > "$DIAG_DIR/disk.txt"

# Network
ip addr show > "$DIAG_DIR/interfaces.txt"
ss -tlnp | grep 55555 > "$DIAG_DIR/listeners.txt"

# Processor status (if running)
lc show status -P localhost:55555 --tls-ca /etc/lippycat/certs/ca.crt \
  > "$DIAG_DIR/processor_status.json" 2>&1
lc show topology -P localhost:55555 --tls-ca /etc/lippycat/certs/ca.crt \
  > "$DIAG_DIR/topology.json" 2>&1

# Recent logs
journalctl -u 'lippycat*' --since "2 hours ago" > "$DIAG_DIR/logs.txt"

# Configuration (sanitize if needed)
lc show config > "$DIAG_DIR/config.json" 2>&1

# Archive
tar -czf "/tmp/lippycat_diag_$TIMESTAMP.tar.gz" -C /tmp "lippycat_diag_$TIMESTAMP"
rm -rf "$DIAG_DIR"
echo "Saved: /tmp/lippycat_diag_$TIMESTAMP.tar.gz"

Manteniment

Gestió de l’emmagatzematge PCAP

Els fitxers PCAP s’acumulen ràpidament en producció. Configureu una neteja automatitzada:

#!/bin/bash
# pcap-cleanup.sh — run from cron
PCAP_DIR="/var/capture"
RETENTION_DAYS=30

# Remove old PCAP files
find "$PCAP_DIR" -name "*.pcap" -mtime +$RETENTION_DAYS -delete
find "$PCAP_DIR" -name "*.pcap.gz" -mtime +$RETENTION_DAYS -delete

# Remove empty directories
find "$PCAP_DIR" -type d -empty -delete

# Report disk usage
echo "PCAP storage: $(du -sh "$PCAP_DIR" | cut -f1)"

Afegiu-ho a cron:

# Daily PCAP cleanup at 3 AM
0 3 * * * /opt/scripts/pcap-cleanup.sh >> /var/log/pcap-cleanup.log 2>&1

Planificació de capacitat

Estimació de l’ús de disc

Estimació dels recursos del processador

Escaleu horitzontalment amb diversos processadors si un de sol no pot gestionar la càrrega (vegeu el Capítol 6: Topologia amb diversos processadors).

Llista de comprovació de seguretat

Executeu-la mensualment:

• El binari té les capacitats mínimes (getcap /usr/local/bin/lc)
• El fitxer de configuració té permisos restrictius (ls -la /etc/lippycat/config.yaml)
• Els certificats TLS no han caducat (openssl x509 -enddate -noout -in cert.crt)
• LIPPYCAT_PRODUCTION=true està definit (bloqueja --insecure)
• No hi ha Hunters no autoritzats connectats (lc list hunters -P ...)
• Els directoris PCAP tenen els permisos adequats
• Les regles del tallafoc restringeixen el port 55555 als amfitrions autoritzats

Actualització

1. Descarregueu o compileu la versió nova
2. Atureu el servei: sudo systemctl stop lippycat-processor
3. Substituïu el binari: sudo cp lc /usr/local/bin/
4. Restaureu les capacitats: sudo setcap cap_net_raw,cap_net_admin=eip /usr/local/bin/lc
5. Inicieu el servei: sudo systemctl start lippycat-processor
6. Verifiqueu: lc show status -P localhost:55555 --tls-ca ca.crt

Els Hunters es reconnectaran automàticament després que el processador es reiniciï.

Nivells d’escalat

Seguretat

Lippycat captura i transporta trànsit de xarxa sensible: credencials SIP, fluxos de mitjans RTP, adreces IP internes i dades potencialment regulades. Aquest capítol descriu els controls de seguretat disponibles per protegir aquestes dades durant la transmissió, l’emmagatzematge i als logs. Pressuposa que teniu un desplegament distribuït operatiu, tal com es descriu a la Part III, i que el prepareu per a producció.

TLS per al mode distribuït

Totes les connexions gRPC de l’arquitectura distribuïda —de Hunter a processador, de processador a processador i de TUI a processador— requereixen TLS per defecte. Sense TLS, els paquets capturats viatgen en text pla entre nodes.

Modes de seguretat

Lippycat admet tres modes TLS:

Requisits de certificats segons el tipus de node

Cada tipus de node necessita certificats diferents segons el mode TLS:

Generació de certificats amb OpenSSL

Les versions modernes de Go requereixen noms alternatius del subjecte (SAN) en tots els certificats. Els certificats que només utilitzen el nom comú (CN) es rebutgen. El procediment següent genera una CA, un certificat de servidor per al processador i un certificat de client per als Hunters.

Pas 1: creeu una autoritat de certificació

mkdir -p /etc/lippycat/certs && cd /etc/lippycat/certs

Genereu la clau de la CA i el certificat autosignat:

openssl req -x509 -newkey rsa:4096 -days 3650 -nodes \
  -keyout ca-key.pem -out ca-cert.pem \
  -subj "/C=US/ST=State/L=City/O=YourOrg/CN=Lippycat CA"

Pas 2: genereu el certificat del processador (servidor)

Genereu la clau privada:

openssl genrsa -out server-key.pem 4096

Creeu la sol·licitud de signatura del certificat:

openssl req -new -key server-key.pem -out server-req.pem \
  -subj "/CN=processor.example.com"

Creeu el fitxer d’extensions; els SAN són obligatoris:

cat > server-ext.conf <<EOF
subjectAltName = DNS:processor.example.com,DNS:localhost,IP:127.0.0.1
extendedKeyUsage = serverAuth
EOF

Signeu el certificat amb la CA:

openssl x509 -req -in server-req.pem -days 365 \
  -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial \
  -out server-cert.pem -extfile server-ext.conf

Substituïu processor.example.com pel nom de host o l’adreça IP que els Hunters utilitzaran per connectar-se. Afegiu diversos SAN si el processador és accessible amb diversos noms:

subjectAltName = DNS:processor.example.com,DNS:processor,IP:10.0.1.100,IP:127.0.0.1

Pas 3: genereu un certificat de Hunter (client)

Per a mTLS, cada Hunter necessita el seu propi certificat:

openssl genrsa -out hunter01-key.pem 4096

openssl req -new -key hunter01-key.pem -out hunter01-req.pem \
  -subj "/CN=hunter-01.example.com"

cat > client-ext.conf <<EOF
extendedKeyUsage = clientAuth
EOF

openssl x509 -req -in hunter01-req.pem -days 365 \
  -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial \
  -out hunter01-cert.pem -extfile client-ext.conf

Pas 4: establiu els permisos i feu la neteja

chmod 600 *-key.pem

chmod 644 *-cert.pem

rm -f *.conf *-req.pem

Inici dels nodes amb TLS

Un cop disponibles els certificats, inicieu el desplegament distribuït:

Inicieu el processador amb TLS del servidor:

lc process --listen 0.0.0.0:55555 \
  --tls-cert /etc/lippycat/certs/server-cert.pem \
  --tls-key /etc/lippycat/certs/server-key.pem

Inicieu el Hunter i verifiqueu la identitat del processador:

sudo lc hunt voip -i eth0 \
  --processor processor.example.com:55555 \
  --tls-ca /etc/lippycat/certs/ca-cert.pem

Per a producció amb mTLS (descrit a la secció següent), afegiu les opcions d’autenticació del client.

TLS mutu (mTLS)

El TLS del servidor xifra el canal i permet als clients verificar el processador, però qualsevol client pot connectar-s’hi. El TLS mutu afegeix la verificació inversa: el processador verifica la identitat del Hunter mitjançant certificats de client. Aquesta és la configuració recomanada per a producció.

Model de confiança

flowchart TB
    CA["Internal CA<br/>(ca-cert.pem)"]

    CA -->|signs| SC["Server Cert<br/>(processor)"]
    CA -->|signs| HC1["Client Cert<br/>(hunter-01)"]
    CA -->|signs| HC2["Client Cert<br/>(hunter-02)"]
    CA -->|signs| TC["Client Cert<br/>(TUI client)"]

    subgraph Processor
        SC
        CAcopy1["CA cert (for verifying clients)"]
    end

    subgraph Hunters
        HC1
        HC2
        CAcopy2["CA cert (for verifying server)"]
    end

    subgraph "TUI Clients"
        TC
        CAcopy3["CA cert (for verifying server)"]
    end

Tots els certificats estan signats per la mateixa CA. Cada node confia en qualsevol certificat signat per aquesta CA. Per revocar un Hunter, deixeu d’emetre-li certificats i reinicieu el processador: el Hunter revocat ja no pot presentar un certificat de client vàlid.

Activació de mTLS

Inicieu el processador i exigiu certificats de client:

lc process --listen 0.0.0.0:55555 \
  --tls-cert /etc/lippycat/certs/server-cert.pem \
  --tls-key /etc/lippycat/certs/server-key.pem \
  --tls-client-auth \
  --tls-ca /etc/lippycat/certs/ca-cert.pem

Inicieu un Hunter que presenti un certificat de client:

sudo lc hunt voip -i eth0 \
  --processor processor.example.com:55555 \
  --tls-cert /etc/lippycat/certs/hunter01-cert.pem \
  --tls-key /etc/lippycat/certs/hunter01-key.pem \
  --tls-ca /etc/lippycat/certs/ca-cert.pem

Connecteu un client TUI que també presenti un certificat de client:

lc watch remote -P processor.example.com:55555 \
  --tls-cert /etc/lippycat/certs/tui-cert.pem \
  --tls-key /etc/lippycat/certs/tui-key.pem \
  --tls-ca /etc/lippycat/certs/ca-cert.pem

Fitxer de configuració

Per als desplegaments de producció, deseu els paràmetres TLS al fitxer de configuració en lloc de la línia d’ordres. Així, els camins de les claus no apareixen a les llistes de processos ni a l’historial de l’intèrpret d’ordres:

# /etc/lippycat/config.yaml — processor
processor:
  listen_addr: "0.0.0.0:55555"
  tls:
    cert_file: "/etc/lippycat/certs/server-cert.pem"
    key_file: "/etc/lippycat/certs/server-key.pem"
    ca_file: "/etc/lippycat/certs/ca-cert.pem"
    client_auth: true

# /etc/lippycat/config.yaml — hunter
hunter:
  processor_addr: "processor.example.com:55555"
  tls:
    cert_file: "/etc/lippycat/certs/hunter01-cert.pem"
    key_file: "/etc/lippycat/certs/hunter01-key.pem"
    ca_file: "/etc/lippycat/certs/ca-cert.pem"

CA comercials

Si el processador utilitza un certificat d’una CA coneguda (Let’s Encrypt, DigiCert, etc.), els Hunters no necessiten --tls-ca: el magatzem de confiança del sistema ja inclou la CA emissora:

sudo lc hunt voip -i eth0 --processor processor.example.com:55555

Això simplifica el desplegament dels Hunters, però no proporciona autenticació del client. Combineu-ho amb mTLS si necessiteu restringir quins Hunters poden connectar-se.

Cicle de vida dels certificats

Supervisió de la caducitat

Comproveu les dates de validesa dels certificats i configureu-ne la supervisió automatitzada:

Comproveu les dates d’un certificat:

openssl x509 -in /etc/lippycat/certs/server-cert.pem -noout -dates

Verifiqueu que hi hagi SAN, tal com exigeix Go:

openssl x509 -in /etc/lippycat/certs/server-cert.pem -noout -text \
  | grep -A1 "Subject Alternative Name"

Afegiu una tasca cron o una comprovació de supervisió per avisar abans que caduquin els certificats:

# /etc/cron.daily/check-lippycat-certs
#!/bin/bash
CERT="/etc/lippycat/certs/server-cert.pem"
DAYS_LEFT=$(( ($(date -d "$(openssl x509 -in "$CERT" -noout -enddate \
  | cut -d= -f2)" +%s) - $(date +%s)) / 86400 ))

if [ "$DAYS_LEFT" -lt 30 ]; then
    echo "lippycat server certificate expires in $DAYS_LEFT days" | \
      mail -s "Certificate Expiry Warning" ops@example.com
fi

Rotació dels certificats

Per rotar els certificats sense interrompre les connexions:

1. Genereu un certificat nou signat per la mateixa CA.
2. Actualitzeu el fitxer de configuració amb els camins nous.
3. Recarregueu el servei de manera controlada:

Genereu la clau de substitució:

openssl genrsa -out server-key-new.pem 4096

Creeu-ne la sol·licitud de signatura:

openssl req -new -key server-key-new.pem -out server-req-new.pem \
  -subj "/CN=processor.example.com"

Signeu el certificat de substitució:

openssl x509 -req -in server-req-new.pem -days 365 \
  -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial \
  -out server-cert-new.pem -extfile server-ext.conf

Col·loqueu el certificat nou al seu lloc:

mv server-cert-new.pem server-cert.pem

mv server-key-new.pem server-key.pem

Recarregueu el servei:

systemctl reload lippycat-processor

Verifiqueu el certificat de substitució:

openssl s_client -connect processor:55555 -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -dates

Els Hunters es reconnectaran automàticament amb el nou certificat del servidor, sempre que estigui signat per la mateixa CA.

Revocació d’un certificat

Actualment, Lippycat no implementa comprovacions CRL ni OCSP. Per revocar un certificat compromès:

1. Retireu el certificat compromès del node.
2. Reinicieu el processador per desconnectar el Hunter afectat.
3. Genereu un certificat nou per al node de substitució.
4. Si la clau de la CA s’ha compromès, regenereu tota la CA i torneu a emetre tots els certificats.

Mode de producció

Establir la variable d’entorn LIPPYCAT_PRODUCTION bloqueja el funcionament insegur:

export LIPPYCAT_PRODUCTION=true

Amb aquesta variable establerta, qualsevol intent d’utilitzar --insecure es rebutja en iniciar-se:

FATAL: --insecure flag is not allowed in production mode (LIPPYCAT_PRODUCTION=true)

Això evita que els operadors desactivin TLS accidentalment en producció. Establiu-la al fitxer d’unitat systemd de cada node:

# /etc/systemd/system/lippycat-processor.service
[Service]
Environment="LIPPYCAT_PRODUCTION=true"
ExecStart=/usr/local/bin/lc process --listen :55555 --config /etc/lippycat/config.yaml

Sense --insecure i sense certificats TLS, els nodes es neguen a iniciar-se: no hi ha cap retorn silenciós al text pla.

Mode insegur

Per al desenvolupament i les proves locals, --insecure desactiva TLS completament. Totes dues parts de la connexió han d’utilitzar aquesta opció:

lc process --listen :55555 --insecure

sudo lc hunt voip -i eth0 --processor localhost:55555 --insecure

En iniciar-se, es mostra un avís destacat:

═══════════════════════════════════════════════════════════════
  SECURITY WARNING: TLS ENCRYPTION DISABLED
  Packet data will be transmitted in CLEARTEXT
  This mode should ONLY be used in trusted networks
  TLS is enabled by default — remove --insecure for production
═══════════════════════════════════════════════════════════════

Rendiment de TLS

TLS afegeix una sobrecàrrega mínima en maquinari modern amb suport AES-NI:

No hi ha cap motiu de rendiment per desactivar TLS.

Autenticació amb clau d’API

Els processadors i els nodes Tap poden exigir claus d’API per a les API gRPC de gestió i streaming. Aquesta és una capa d’autenticació alternativa per a desplegaments on distribuir certificats de client és poc pràctic, tot i que cal continuar utilitzant TLS per protegir la clau durant la transmissió.

Activeu l’autenticació amb clau d’API amb --api-key-auth i definiu les claus al fitxer de configuració:

security:
  api_keys:
    enabled: true
    keys:
      - name: "ops-tui"
        key: "lc_live_generated_secret"
        role: "viewer"
        description: "Read-only remote TUI access"

Els clients envien la clau com a metadades gRPC amb el nom x-api-key. En mode de producció, lippycat exigeix mTLS o autenticació amb clau d’API quan el TLS mutu no està activat.

Desxifrat del trànsit TLS capturat

Les seccions anteriors descrivien TLS per a les connexions gRPC del mateix lippycat. Aquesta secció tracta un altre cas d’ús: desxifrar el trànsit xifrat amb TLS que lippycat ha capturat: HTTPS, SMTPS, IMAPS i altres protocols encapsulats en TLS que circulen per la xarxa supervisada.

Com funciona

El desxifrat de TLS requereix claus de sessió exportades per l’aplicació client o servidor mitjançant el mecanisme SSLKEYLOGFILE. Aquestes claus es desen en el format NSS Key Log Format, un estàndard de facto admès per Wireshark, navegadors i moltes aplicacions de servidor.

Com que el TLS modern utilitza secret perfecte cap endavant (Diffie-Hellman efímer), les claus s’han de capturar durant l’execució, en la negociació TLS. No és possible desxifrar posteriorment només amb la clau privada del servidor.

Suport de les aplicacions

La majoria d’aplicacions modernes admeten el registre de claus:

Ús de la CLI

Indiqueu a lippycat un fitxer de registre de claus generat per l’aplicació de destinació:

Per a una captura en directe independent:

sudo lc sniff http -i eth0 --tls-keylog /tmp/sslkeys.log

Per a una captura en directe en mode Tap:

sudo lc tap http -i eth0 --tls-keylog /tmp/sslkeys.log

Per injectar claus en temps real mitjançant una canonada amb nom, creeu la canonada:

mkfifo /tmp/sslkeys.pipe

Inicieu Tap amb la canonada:

sudo lc tap http -i eth0 --tls-keylog-pipe /tmp/sslkeys.pipe &

Inicieu l’aplicació de destinació amb la mateixa canonada:

SSLKEYLOGFILE=/tmp/sslkeys.pipe ./myserver

Transmissió distribuïda de claus

En mode distribuït, els Hunters transmeten automàticament les claus de sessió TLS al processador juntament amb els paquets capturats:

flowchart LR
    subgraph Hunter
        HK["--tls-keylog /tmp/keys.log"]
    end

    subgraph Processor
        PW["Writes paired files:<br/>session.pcap + session.keys"]
    end

    Hunter -->|"gRPC (TLS-encrypted)<br/>packets + session keys"| Processor

Feu la captura amb el registre de claus al Hunter:

sudo lc hunt http -i eth0 \
  --processor central:55555 \
  --tls-keylog /tmp/sslkeys.log \
  --tls-ca ca.crt

Al processador, deseu les claus juntament amb els PCAP:

lc process --listen :55555 \
  --tls-keylog-dir /var/capture/keys \
  --tls-cert server.crt --tls-key server.key

Anàlisi fora de línia

Torneu a analitzar les captures desades amb el registre de claus associat:

Per a l’anàlisi amb la CLI:

lc sniff http -r /var/capture/session.pcap --tls-keylog /var/capture/keys/session.keys

Per a l’anàlisi amb la TUI:

lc watch file /var/capture/session.pcap --tls-keylog /var/capture/keys/session.keys

Integració amb Wireshark

Els fitxers de registre de claus de Lippycat són plenament compatibles amb Wireshark:

1. Obriu el fitxer PCAP a Wireshark.
2. Aneu a Edit > Preferences > Protocols > TLS.
3. Establiu (Pre)-Master-Secret log filename al fitxer de registre de claus.
4. Feu clic a Apply: ara el contingut desxifrat és visible.

Per a captures distribuïdes, el processador escriu fitxers associats que podeu passar directament a Wireshark:

/var/capture/session.pcap        # Encrypted traffic
/var/capture/keys/session.keys   # Session keys

Limitacions

• Cal un registre de claus: el secret perfecte cap endavant impedeix desxifrar sense claus de sessió.
• No es pot desxifrar només amb una clau privada: l’intercanvi de claus RSA (no efímer) és rar i obsolet.
• El moment és important: les claus han d’arribar abans o poc després de la negociació TLS.
• Accés a la mateixa màquina: el node que captura ha de poder llegir el fitxer de registre de claus.

Protecció dels fitxers de registre de claus

Els fitxers de registre de claus contenen secrets de sessió que poden desxifrar tot el trànsit capturat associat. Tracteu-los amb la mateixa cura que les claus privades:

chmod 600 /var/capture/keys/*.keys

chown lippycat:lippycat /var/capture/keys/

En mode distribuït, les claus estan protegides durant la transmissió pel canal TLS gRPC entre Hunter i processador.

Funcions de protecció de dades

A més del xifrat del transport, lippycat inclou diverses funcions per protegir les dades sensibles emmagatzemades i als logs.

Depuració de Call-ID

Els Call-ID de SIP sovint contenen identificadors d’usuari, noms de domini o tokens de sessió. Escriure’ls als fitxers de log pot provocar vulneracions de privadesa. La depuració de Call-ID utilitza hash SHA-256 per generar identificadors coherents però anonimitzats:

Original:   john.doe@company.com-session-12345
Sanitized:  john.d...a1b2c3d4

La forma depurada és determinista: el mateix Call-ID genera sempre el mateix hash, de manera que encara podeu correlacionar entrades de log entre components.

# /etc/lippycat/config.yaml
voip:
  security:
    sanitize_call_ids: true
    call_id_hash_length: 8       # Hash prefix length (4-16 bytes)
    call_id_max_log_length: 16   # Call-IDs longer than this are sanitized

Activeu-ho en tots els entorns. L’impacte en el rendiment és negligible (<1 microsegon per Call-ID).

Xifrat de PCAP

Els fitxers PCAP contenen totes les dades útils dels paquets: credencials SIP, mitjans RTP i dades d’autenticació. Lippycat pot xifrar els fitxers PCAP emmagatzemats amb AES-256-GCM i derivació de claus PBKDF2.

voip:
  security:
    enable_pcap_encryption: true
  encryption:
    enabled: true
    key_file: "/etc/lippycat/keys/pcap.key"
    algorithm: "aes-256-gcm"
    pbkdf2_iterations: 100000     # Minimum 10,000; 100,000+ recommended

Si el fitxer de clau no existeix, lippycat el genera automàticament amb permisos 0600. Per a producció, genereu i gestioneu la clau manualment:

Genereu una clau de xifrat de 256 bits:

openssl rand -out /etc/lippycat/keys/pcap.key 32

chmod 600 /etc/lippycat/keys/pcap.key

chown lippycat:lippycat /etc/lippycat/keys/pcap.key

Rotació de claus: atureu lippycat, canvieu el nom de la clau antiga i reinicieu-lo. Es genera una clau nova automàticament. Conserveu la clau antiga si necessiteu desxifrar fitxers escrits anteriorment.

Rendiment: AES-256-GCM afegeix aproximadament un 5-10% de sobrecàrrega de CPU i ~1-2% de sobrecàrrega d’emmagatzematge (nonce i etiqueta d’autenticació per bloc). L’acceleració AES-NI de maquinari ho redueix considerablement.

Permisos dels fitxers PCAP

Tots els fitxers PCAP es creen amb permisos 0600 (només el propietari pot llegir i escriure). Això s’aplica als PCAP unificats, als PCAP per trucada i als PCAP amb rotació automàtica. No cal configurar-ho: és el comportament per defecte.

Prepareu el directori de sortida amb restriccions equivalents:

sudo mkdir -p /var/lib/lippycat/pcaps

sudo chmod 700 /var/lib/lippycat/pcaps

sudo chown lippycat:lippycat /var/lib/lippycat/pcaps

Fins i tot amb el xifrat PCAP activat, els permisos dels fitxers proporcionen defensa en profunditat perquè impedeixen l’accés no autoritzat als fitxers xifrats.

Validació dels límits de Content-Length

Els missatges SIP inclouen una capçalera Content-Length. Sense validació, un missatge maliciós o malformat que especifiqui un valor enorme pot esgotar la memòria. Lippycat valida els valors de Content-Length durant l’anàlisi dels missatges TCP SIP amb diverses capes de protecció:

• Longitud de cadena limitada a 10 caràcters (evita el desbordament d’enters durant l’anàlisi)
• Valor màxim configurable (1 MB per defecte)
• Mida màxima total del missatge configurable (2 MB per defecte)

voip:
  security:
    max_content_length: 1048576     # 1 MB — reasonable for production
    max_message_size: 2097152       # 2 MB — reasonable for production

Per als entorns d’alta seguretat, reduïu aquests límits:

voip:
  security:
    max_content_length: 65536       # 64 KB
    max_message_size: 131072        # 128 KB

Les infraccions es registren com a avisos amb el valor causant i la font, de manera que podeu detectar intents d’escaneig o atac.

Seguretat de les interfícies virtuals

Tal com es descriu al Capítol 4, lippycat pot crear interfícies virtuals TAP/TUN per transmetre paquets filtrats a eines posteriors com Wireshark o Snort. Això requereix privilegis elevats.

Configuració amb privilegis mínims

L’enfocament recomanat utilitza les capacitats de fitxer de Linux per concedir només la capacitat CAP_NET_ADMIN:

Concediu la capacitat mínima necessària:

sudo setcap cap_net_admin+ep /usr/local/bin/lc

Verifiqueu la capacitat:

getcap /usr/local/bin/lc

La sortida esperada és /usr/local/bin/lc = cap_net_admin+ep.

Ara el comandament es pot executar sense sudo:

lc sniff voip -i eth0 --virtual-interface

Renúncia als privilegis

Quan és inevitable executar-se com a root, lippycat pot passar a un usuari sense privilegis després de crear la interfície:

sudo lc sniff voip -i eth0 \
  --virtual-interface \
  --vif-drop-privileges lippycat

El procés crea la interfície com a root i després passa a l’UID/GID de l’usuari lippycat. El bucle d’injecció de paquets s’executa sense privilegis.

Aïllament amb espais de noms de xarxa

Per a desplegaments de producció amb requisits de seguretat estrictes, executeu la interfície virtual en un espai de noms de xarxa aïllat:

Creeu l’espai de noms:

sudo ip netns add lippycat-isolated

Executeu amb aïllament de l’espai de noms:

sudo lc sniff voip -i eth0 \
  --virtual-interface \
  --vif-netns lippycat-isolated

Només les eines de l’espai de noms poden veure la interfície:

sudo ip netns exec lippycat-isolated wireshark -i lc0

La interfície és invisible per a la pila de xarxa del host, cosa que impedeix captures no autoritzades.

Desplegament en contenidors

Per a Docker o Kubernetes, concediu CAP_NET_ADMIN sense executar tot el contenidor com a root:

Per a Docker:

docker run --cap-add=NET_ADMIN lippycat:latest

# Kubernetes
securityContext:
  capabilities:
    add:
    - NET_ADMIN
  runAsNonRoot: true
  runAsUser: 1000

Llista de comprovació de seguretat

Abans de posar un desplegament en producció, verifiqueu els punts següents:

Transport:

• TLS activat en totes les connexions gRPC (sense opcions --insecure)
• LIPPYCAT_PRODUCTION=true establert als fitxers d’unitat systemd
• mTLS activat amb --tls-client-auth al processador
• Els certificats inclouen SAN (no només CN)
• Supervisió de la caducitat dels certificats preparada

Dades emmagatzemades:

• Els directoris de sortida PCAP tenen permisos 0700
• Xifrat PCAP activat per als desplegaments sensibles
• Clau de xifrat desada en un sistema de fitxers segur amb permisos 0600
• Fitxers de registre de claus (--tls-keylog) protegits amb permisos 0600

Aplicació:

• Depuració de Call-ID activada a la configuració
• Límits de Content-Length configurats adequadament
• Les interfícies virtuals utilitzen capacitats de fitxer (no root)
• Les claus privades no s’han incorporat al control de versions

Operacions:

• Els fitxers de configuració tenen permisos 0600 (contenen camins de claus)
• Procediment de rotació de certificats documentat i provat
• Accés als fitxers de registre de claus auditat

Notes sobre compliment normatiu

Aquestes funcions de seguretat donen suport als marcs habituals de compliment normatiu:

Resolució de problemes

“certificate relies on legacy Common Name field, use SANs instead”

El certificat es va generar sense noms alternatius del subjecte. Torneu-lo a generar amb una extensió subjectAltName, tal com es mostra a Generació de certificats amb OpenSSL.

Verifiqueu que un certificat existent contingui SAN:

openssl x509 -in server-cert.pem -noout -text | grep -A1 "Subject Alternative Name"

“TLS is disabled but –insecure flag not set”

No s’han proporcionat certificats TLS i no s’ha establert --insecure. Proporcioneu certificats o permeteu explícitament el mode insegur per a les proves.

“No client certificate provided”

El processador exigeix mTLS (--tls-client-auth), però el Hunter no ha presentat cap certificat de client. Afegiu --tls-cert i --tls-key al Hunter.

“Failed to verify certificate”

La validació del certificat ha fallat. Causes habituals:

Comproveu si el certificat ha caducat:

openssl x509 -in cert.pem -noout -enddate

Comproveu si el nom de host coincideix amb els SAN:

openssl x509 -in cert.pem -noout -text | grep -A2 "Subject Alternative Name"

Verifiqueu la cadena de certificats:

openssl verify -CAfile ca-cert.pem server-cert.pem

El desxifrat TLS no funciona

1. Verifiqueu que el fitxer de registre de claus existeixi i contingui entrades.
2. Comproveu que les claus es van capturar durant la negociació TLS (les claus no es poden generar posteriorment).
3. En mode distribuït, confirmeu que el Hunter tingui --tls-keylog establert i que el processador tingui --tls-keylog-dir configurat.
4. Per a Wireshark, assegureu-vos que el format de registre de claus comenci amb CLIENT_RANDOM o CLIENT_HANDSHAKE_TRAFFIC_SECRET.

Optimització del rendiment

lippycat inclou valors per defecte raonables, però els desplegaments en producció sovint es beneficien d’ajustos. Aquest capítol presenta les opcions de rendiment disponibles: comença pels perfils de rendiment TCP (la millora més senzilla) i continua amb l’acceleració GPU i els algorismes de cerca de patrons. Cada apartat es basa en els conceptes de captura i distribució de les parts II i III.

Perfils de rendiment TCP

Els perfils de rendiment TCP són conjunts de paràmetres preajustats que configuren entre 17 i 19 opcions internes amb un sol indicador. Controlen el comportament del reassemblatge TCP, l’assignació de memòria, les estratègies de memòria intermèdia i els fils d’E/S. Si no teniu requisits específics, triar el perfil adequat és l’optimització individual amb més impacte.

Triar un perfil

Establiu el perfil amb --tcp-performance-mode en les ordres que fan reassemblatge local de SIP sobre TCP. sniff voip utilitza balanced, throughput, latency i memory; tap voip utilitza minimal, balanced, high_performance i low_latency.

sudo lc sniff voip -i eth0 --tcp-performance-mode balanced

Per a tap voip, els quatre perfils corresponen a situacions d’ús diferents:

Mínim — Per a dispositius encastats (Raspberry Pi), entorns de prova o desplegaments amb menys de 10 trucades simultànies. Utilitza memòries intermèdies de mida fixa i un sol fil d’E/S per mantenir-se per sota de 25 MB de RAM. La contrapressió està activada per evitar l’esgotament de la memòria.

Equilibrat (per defecte) — L’opció adequada per a la majoria de desplegaments en producció amb entre 10 i 100 trucades simultànies i entre 2 i 8 GB de RAM disponible. La mida adaptativa de les memòries intermèdies i l’ajust automàtic permeten adaptar-se als patrons de trànsit durant l’execució.

Alt rendiment — Desplegaments en centres de dades amb entre 100 i 1.000 trucades simultànies o més. Les memòries intermèdies circulars, el doble de fils d’E/S i la contrapressió desactivada maximitzen el cabal a costa d’un consum de memòria superior (fins a 500 MB). Els lots més grans augmenten lleugerament la latència per paquet.

Baixa latència — Anàlisi en temps real, detecció de frau o supervisió de la qualitat de les trucades on importa processar en menys d’un segon. Una mida de lot d’1 significa que cada paquet es processa immediatament. L’ajust automàtic està desactivat per mantenir un comportament previsible.

Sobreescriure paràmetres individuals

Els perfils estableixen una configuració de base. Podeu sobreescriure qualsevol paràmetre individual:

Utilitzeu el perfil equilibrat amb més memòries intermèdies per a una xarxa amb ràfegues de trànsit:

sudo lc sniff voip -i eth0 \
  --tcp-performance-mode balanced \
  --max-tcp-buffers 10000

Utilitzeu el perfil d’alt rendiment amb la contrapressió reactivada per seguretat:

sudo lc sniff voip -i eth0 \
  --tcp-performance-mode throughput \
  --enable-backpressure

Utilitzeu el perfil de memòria amb un temps d’espera del flux més llarg per a diàlegs SIP lents:

sudo lc sniff voip -i eth0 \
  --tcp-performance-mode memory \
  --tcp-stream-timeout 300s

Els mateixos paràmetres funcionen en fitxers de configuració YAML:

voip:
  tcp_performance_mode: "balanced"
  max_tcp_buffers: 10000

Triar un perfil per a nodes distribuïts

En un desplegament distribuït (capítol 6), els nodes Hunter i els processadors tenen necessitats d’ajust diferents:

• Els nodes Hunter utilitzen ajustos del temps d’espera d’inactivitat de SIP TCP i filtres gestionats pel processador, però no ofereixen --tcp-performance-mode.
• Els processadors reben paquets ja reassemblats per gRPC, de manera que el perfil TCP afecta principalment qualsevol captura local que pugui fer el processador (rellevant en mode Tap, capítol 9).
• Els nodes Tap combinen tots dos rols. Adapteu el perfil al volum de trànsit local.

Fragments de reassemblatge TCP en mode Tap

tap voip utilitza un fragment de reassemblatge TCP per defecte. Això conserva el comportament d’un únic reassemblador i també és la configuració de retorn. En sistemes on els perfils mostren que el reassemblador és el coll d’ampolla, les connexions TCP independents es poden repartir entre nuclis:

sudo lc tap voip -i eth0 --tcp-reassembly-shards 4 --insecure

Totes dues direccions i tots els paquets d’una connexió s’encaminen al mateix fragment, de manera que l’ordre per flux no canvia. El límit global de pàgines en memòria intermèdia es divideix entre els fragments en lloc de multiplicar-se, i el límit per connexió no canvia. La telemetria informa de la suma de discontinuïtats de reassemblatge i d’alliberaments per retenció limitada de tots els fragments. Cada fragment afegeix un reassemblador i un conjunt de fluxos; compareu, per tant, paquets/s, CPU, memòria dinàmica, assignacions, discontinuïtats i tots els comptadors de descart de captura i flux amb 1, 2, 4 i 8 fragments i una combinació representativa de fluxos. Ajusteu processor.detection_workers juntament amb el nombre de fragments; els fragments addicionals no ajuden si massa pocs treballadors els alimenten. Torneu a --tcp-reassembly-shards 1 si empitjoren l’ús de recursos o la telemetria d’integritat.

Prioritat de captura SIP i els seus límits

La memòria intermèdia de captura proporciona a la senyalització SIP reconeguda una via prioritària amb mida independent. En mode automàtic (sip_buffer_size: 0 o --sip-buffer-size 0), la capacitat de paquets coincideix amb la de la memòria intermèdia de captura ordinària. Un valor positiu és una sobreescriptura explícita: els valors més grans donen marge per a ràfegues limitades i consumeixen més memòria, mentre que els més petits redueixen la memòria i permeten degradar la prioritat abans. Per a SIP sobre TCP, el reconeixement manté estat: després d’observar una línia inicial SIP creïble, els segments posteriors de capçalera i cos en totes dues direccions de la connexió utilitzen la via prioritària. El classificador de fluxos conserva com a màxim 65.536 entrades, manté com a màxim 1 KiB de possible prefix de línia inicial per direcció, fa caducar les entrades inactives al cap de dos minuts i les elimina amb TCP FIN o RST.

Aquesta protecció només comença després d’un inici SIP recognoscible. Quan la captura s’incorpora a una connexió TCP ja establerta, o mentre una línia inicial encara està dividida entre segments incomplets, aquests paquets utilitzen la via ordinària. Per tant, es poden descartar en sobrecàrrega abans que el flux adquireixi prioritat. Un inici complet recognoscible posterior encara pot donar prioritat a la connexió.

La via prioritària és limitada i no garanteix absència de pèrdues. Quan és plena, un paquet SIP reconegut passa a la via ordinària. Si totes dues vies són plenes, el paquet es rebutja i es compta com a descart SIP de la memòria intermèdia de captura; el desbordament de la via ordinària es compta separadament. Aquests comptadors distingeixen quina via ha perdut el paquet, però per si sols no identifiquen una causa a la xarxa anterior o al nucli. Si augmenten els descarts SIP, reduïu el trànsit ofert amb un filtre BPF, augmenteu la capacitat de servei posterior o investigueu les altres etapes identificades de pèrdua de captura i processament abans d’atribuir una causa arrel.

sip_priority_classified és el nombre inclusiu de paquets reconeguts i encaminats per la via de prioritat SIP. Inclou els paquets acceptats per aquesta via, els comptats per capture_buffer_sip_demotions després de passar a la via ordinària i els comptats per capture_buffer_sip_drops després que totes dues vies d’entrada els rebutgin. Les degradacions indiquen un servei de prioritat deteriorat; només els descarts SIP finals contribueixen als totals de pèrdua de paquets.

Capacitat i retenció del detector

El detector de protocols té per defecte 100.000 contextos de flux actius i 100.000 resultats en memòria cau. Configureu els límits de manera independent:

detector:
  max_flows: 100000
  max_cache_entries: 100000

Quan arriba una clau nova a una estructura plena, el detector expulsa un lot amb el 10% de les entrades més antigues (almenys una) i després admet la clau. Aquesta histèresi evita el cost d’expulsar en cada inserció posterior. Els fluxos expulsats són els de darrera activitat més antiga; les entrades de cau expulsades són les que caduquen abans. La pressió de capacitat és, per tant, un senyal de retenció, no una prova que s’hagin descartat paquets.

Reduir detector.max_flows disminueix la memòria i la durada d’una pausa individual d’expulsió, però conserva l’historial de protocols de menys fluxos. Amb un conjunt de treball superior al límit, augmenta la reclassificació i un flux de llarga durada poc actiu pot perdre l’estat. Un límit més alt millora la retenció i redueix la freqüència d’expulsió a costa de memòria i lots del 10% més grans. detector.max_cache_entries té el mateix compromís entre memòria i reclassificació. Els valors zero o negatius desactiven el límit corresponent i només s’han d’utilitzar amb un altre límit de memòria fiable.

Ajusteu-ho amb trànsit representatiu d’alta cardinalitat i canvieu un sol límit cada vegada. Una bona configuració estabilitza la memòria resident sense pressió recurrent en cada senyal de vida ni empitjorament de la pèrdua de captura.

Criteris d’acceptació

L’evidència per a una versió de producció ha d’incloure proves de rendiment sostingut al límit per a fluxos i cau amb 1.000, 10.000 i 100.000 entrades, i una prova amb treballadors del detector concurrents. Entre esdeveniments de lot, la inserció en règim estable no ha de créixer linealment amb el límit. Amb el valor per defecte de 100.000 entrades, un lot d’expulsió s’ha de completar en 100 ms en cada classe de maquinari de producció compatible. Aquest és el pressupost de latència de la memòria intermèdia de paquets que correspon al temps d’espera de lot per defecte de Hunter/Tap.

Registreu el cabal mitjà, la latència de cua de les insercions i la latència dels lots d’expulsió. El resultat de 100 ms de temps real és evidència de versió vinculada a l’amfitrió, la cadena d’eines, la compilació, el nombre de treballadors i les dades de prova; no és un llindar de CI portable. La CI ha de comprovar, en canvi, l’escalabilitat amb la cardinalitat i el comportament de les assignacions.

Telemetria de capacitat

La telemetria del detector apareix sota HunterStats.detector en cada senyal de vida; Tap utilitza els mateixos camps per a la font local:

Els comptadors són monòtons durant la vida d’un detector i es reinicien quan s’inicia un detector nou o un procés de captura nou. Els senyals de vida són instantànies; no sumeu, doncs, un comptador entre informes successius. Calculeu diferències no negatives per font i tracteu un valor inferior com un reinici. Per a una visió del conjunt de nodes, sumeu els darrers indicadors per font i les diferències dels comptadors per font durant el mateix interval. Tingueu en compte les fonts que s’incorporen o surten de l’agregat i manteniu separats els valors de flux i de cau.

La darrera durada d’expulsió i la darrera mida de lot descriuen l’esdeveniment completat més recent i substitueixen els valors anteriors. No sumeu aquests camps del darrer esdeveniment ni en calculeu taxes. Conserveu mostres externament si són importants la mitjana, el màxim o la latència de cua.

Observeu la tendència de flow_last_eviction_duration_ns mentre els indicadors d’entrades es mantenen a prop del límit. Amb el límit per defecte de 100.000 fluxos, els lots milloren el cabal i el treball total sota bloqueig, però els episodis individuals d’expulsió de fluxos observats han mantingut el bloqueig exclusiu durant 27–44 ms, davant d’uns 7 ms abans de l’agrupació en lots. Reduïu detector.max_flows quan aquesta pausa sigui massa llarga per a la càrrega; tornar a l’expulsió amb recorregut complet del mapa en cada inserció restitueix la regressió de cabal. Correlacioneu la pressió del detector amb l’ocupació de la memòria intermèdia de paquets i els comptadors de descart identificats.

Acceleració GPU

L’acceleració GPU agilitza la cerca de coincidències dels filtres d’aplicació en el costat de captura sobre valors ja extrets pels analitzadors de protocols. No analitza SIP ni extreu Call-IDs; aquestes operacions continuen a la CPU.

Selecció del motor

lippycat comprova els motors disponibles per ordre de prioritat i selecciona el millor:

flowchart LR
    Auto["--gpu-backend auto"] --> CUDA{CUDA\navailable?}
    CUDA -->|Yes| UseCUDA[Use CUDA]
    CUDA -->|No| SIMD["Use CPU SIMD\n(always available)"]

Seleccioneu un motor explícitament o deixeu que el triï la detecció automàtica:

Detecteu automàticament el motor (recomanat):

sudo lc sniff voip -i eth0 --gpu-backend auto

Forceu CUDA:

sudo lc sniff voip -i eth0 --gpu-backend cuda

Forceu CPU SIMD:

sudo lc sniff voip -i eth0 --gpu-backend cpu-simd

Desactiveu completament l’acceleració:

sudo lc sniff voip -i eth0 --gpu-backend disabled

Per a sniff voip, hunt i tap, aquests indicadors GPU només es registren en compilacions CUDA. watch live ofereix els seus propis indicadors GPU en compilacions estàndard.

Requisits dels motors

El motor CPU SIMD utilitza instruccions AVX2 quan estan disponibles i recorre a SSE4.2 en cas contrari. No requereix maquinari ni controladors especials i ofereix bon rendiment en CPU modernes.

El valor opencl continua acceptant-se per compatibilitat de configuració, però el motor OpenCL no està implementat. La detecció automàtica l’omet, i una selecció explícita recorre a la cerca de coincidències per CPU després que falli la inicialització.

Resultats de les proves de rendiment

Proves de rendiment mesurades en un Intel i9-13900HX amb 64 paquets per lot:

Ajust de la mida del lot

La mida del lot controla el compromís entre cabal i latència:

Per a monitoratge en temps real de baixa latència:

--gpu-batch-size 256

Per a un ús general equilibrat en producció:

--gpu-batch-size 1024

Per al cabal màxim en captures de gran volum:

--gpu-batch-size 4096

Els lots més grans amortitzen el cost per lot però afegeixen latència (els paquets esperen fins que el lot s’omple o venç un temps d’espera). Per a la supervisió VoIP on importa la visibilitat en temps real, manteniu-vos entre 256 i 1024. Per a l’anàlisi massiva de PCAP o la captura perifèrica d’alt cabal, utilitzeu entre 2048 i 4096.

Configuració YAML

gpu:
  enabled: true
  backend: "auto"
  device_id: 0
  max_batch_size: 1024
  pinned_memory: true
  stream_count: 4

Algorismes de cerca de patrons

Quan filtreu trànsit amb conjunts grans de noms d’usuari SIP, números de telèfon o altres identificadors, l’elecció de l’algorisme de cerca de patrons té un gran impacte en el rendiment.

Opcions d’algorisme

Establiu l’algorisme amb --pattern-algorithm:

On n és la longitud de l’entrada, m és la longitud total dels patrons i z és el nombre de coincidències.

En mode auto, lippycat passa a Aho-Corasick quan el nombre de patrons arriba a 100. Per sota d’aquest llindar, el recorregut lineal evita el cost de construir l’autòmat.

Rendiment a escala

La diferència esdevé molt marcada quan augmenta el nombre de patrons:

El temps de cerca de coincidències d’Aho-Corasick es manté gairebé constant independentment del nombre de patrons perquè tots es compilen en un autòmat finit que processa cada byte d’entrada exactament una vegada.

Configuració

Utilitzeu la selecció automàtica en la majoria de desplegaments:

sudo lc sniff voip -i eth0 --pattern-algorithm auto

Forceu Aho-Corasick per a llistes grans de filtres:

sudo lc hunt voip --processor central:55555 \
  --pattern-algorithm aho-corasick \
  --pattern-buffer-mb 128

Utilitzeu un recorregut lineal per a uns quants patrons:

sudo lc sniff voip -i eth0 --pattern-algorithm linear

En YAML:

voip:
  pattern_algorithm: "auto"
  pattern_buffer_mb: 64

L’ús de memòria d’Aho-Corasick és modest: 100.000 patrons de 20 caràcters de mitjana consumeixen menys de 100 MB per a l’autòmat complet. Per a càrregues d’intercepció legal amb desenes de milers d’objectius (capítol 17), Aho-Corasick és l’única opció viable.

Filtres BPF

Els filtres BPF (Berkeley Packet Filter) s’executen en l’espai del nucli i descarten paquets no desitjats abans que arribin a lippycat. És la forma més eficient de filtratge perquè els paquets rebutjats mai no travessen el límit entre el nucli i l’espai d’usuari.

Captureu només trànsit SIP:

sudo lc sniff voip -i eth0 -f "port 5060"

Captureu SIP i un interval de ports RTP:

sudo lc hunt voip --processor central:55555 \
  -i eth0 -f "port 5060 or portrange 10000-20000"

Captureu trànsit d’un amfitrió específic:

sudo lc sniff voip -i eth0 -f "host 192.168.1.100 and port 5060"

En desplegaments VoIP, les restriccions explícites de ports SIP i RTP són la manera més segura de reduir la càrrega de l’espai d’usuari sense descartar SIP sobre TCP:

sudo lc hunt voip --processor central:55555 \
  -i eth0 --sip-port 5060 --rtp-port-range 10000-20000

Consulteu l’apèndix C: referència de filtres BPF per a la sintaxi completa dels filtres.

Escalabilitat distribuïda

Els desplegaments distribuïts (capítol 6) introdueixen dimensions d’ajust addicionals: els paràmetres de lot controlen l’eficiència de gRPC, el filtratge VoIP a la perifèria redueix l’amplada de banda i les topologies jeràrquiques reparteixen la càrrega entre nivells.

Paràmetres de lot dels nodes Hunter

Els nodes Hunter agrupen els paquets en lots abans d’enviar-los al processador per gRPC. Ajusteu --batch-size i --batch-timeout segons el compromís entre latència i cabal que necessiteu:

Per a supervisió de baixa latència amb poques trucades:

sudo lc hunt voip --processor central:55555 \
  --batch-size 16 --batch-timeout 50

Per a la configuració equilibrada per defecte en producció:

sudo lc hunt voip --processor central:55555 \
  --batch-size 64 --batch-timeout 100

Per a captura massiva d’alt cabal:

sudo lc hunt voip --processor central:55555 \
  --batch-size 256 --batch-timeout 500

Els lots més grans redueixen el cost de gRPC per paquet, però augmenten el temps màxim que un paquet espera abans de transmetre’s (el temps d’espera del lot, en mil·lisegons).

Filtratge a la perifèria

Una de les millores de rendiment més grans en mode distribuït és el filtratge a la perifèria. Quan els nodes Hunter utilitzen subordres específiques de VoIP i filtratge accelerat per GPU, poden reduir més d’un 90% el volum de trànsit transmès al processador:

Creeu el filtre perifèric:

lc set filter -P central:55555 --tls-ca ca.crt \
  --type sip_user --pattern alicent

Inicieu el node Hunter amb filtratge perifèric i acceleració GPU:

sudo lc hunt voip --processor central:55555 \
  --sip-port 5060 \
  --rtp-port-range 10000-20000

El processador envia el filtre d’usuari SIP alicent al node Hunter. Aquest manté les trucades en memòria intermèdia a la perifèria i només transmet les que coincideixen, de manera que el processador rep una fracció del trànsit brut.

Capacitat del processador

Els processadors supervisen la càrrega interna (profunditat de la cua d’escriptura PCAP, treball pendent cap a l’amunt) i senyalitzen control de flux als nodes Hunter quan estan sobrecarregats:

Si veieu senyals SLOW o PAUSE als registres del processador (capítol 12), el processador s’està convertint en un coll d’ampolla. Opcions:

1. Afegiu més processadors i repartiu-hi els nodes Hunter.
2. Activeu el filtratge perifèric per reduir el volum d’entrada.
3. Utilitzeu el mode jeràrquic: els processadors regionals agreguen dades dels nodes Hunter locals i després les transmeten a un processador central.

Topologies jeràrquiques

Per a desplegaments a gran escala (50 nodes Hunter o més), una jerarquia de dos nivells evita sobrecarregar un únic processador:

50 hunters --> 5 regional processors --> 1 central processor

Cada processador regional gestiona 10 nodes Hunter i aplica anàlisi de protocols abans de transmetre resums cap a l’amunt. Això redueix la càrrega del processador central en un ordre de magnitud. Consulteu el capítol 6 per configurar la topologia.

Ajust específic de l’entorn

Els diferents entorns de desplegament requereixen combinacions diferents de les tècniques anteriors. Aquí teniu configuracions provades per a situacions habituals.

Sistemes encastats (Raspberry Pi, SBC ARM)

sudo lc sniff voip -i eth0 \
  --tcp-performance-mode memory \
  --memory-optimization

Preveieu entre 10 i 50 trucades simultànies. El perfil memory manté unes memòries intermèdies TCP conservadores. Activeu --memory-optimization per recuperar-les de manera agressiva.

Màquines virtuals

sudo lc sniff voip -i eth0 \
  --tcp-performance-mode balanced \
  --max-tcp-buffers 5000

Ajusteu els límits de memòria intermèdia TCP segons la RAM assignada a la màquina virtual.

Servidors físics

sudo lc sniff voip -i eth0 \
  --tcp-performance-mode throughput \
  --max-tcp-buffers 20000

En maquinari dedicat amb 8 GB de RAM o més i una CPU moderna, utilitzeu el perfil throughput. Si teniu una GPU NVIDIA i heu compilat amb -tags cuda, afegiu --gpu-backend auto perquè la selecció CUDA o SIMD triï el millor motor. Per a interfícies de 10GbE o més, distribuïu la captura entre nodes Hunter addicionals.

Kubernetes / contenidors

# Pod resource limits
resources:
  limits:
    memory: "4Gi"
    cpu: "4"
  requests:
    memory: "2Gi"
    cpu: "2"

lc sniff voip -i eth0 \
  --tcp-performance-mode balanced \
  --max-tcp-buffers 5000

Adapteu el perfil TCP al límit de memòria del contenidor: els 100 MB del perfil balanced encaixen còmodament en un contenidor de 2 GB. L’accés directe a la GPU des dels contenidors és possible però complex.

Node Hunter distribuït a la perifèria amb recursos limitats

Per a nodes Hunter desplegats en dispositius perifèrics petits que transmeten a un processador central:

sudo lc hunt voip --processor central:55555 \
  --batch-size 32 --batch-timeout 200 \
  --sip-port 5060 --rtp-port-range 10000-20000 \
  --tls-ca ca.crt

Les restriccions de ports SIP/RTP redueixen la càrrega de captura sense descartar SIP TCP. Els lots petits mantenen l’ús de memòria previsible. Si utilitzeu una compilació CUDA, afegiu --enable-voip-filter --gpu-backend cpu-simd per accelerar la cerca de coincidències perifèrica sense maquinari GPU.

Anàlisi del perfil de memòria

Quan feu ajustos, és útil observar l’ús real de memòria. Activeu pprof per utilitzar l’analitzador de memòria integrat de Go:

sudo lc tap voip -i eth0 --debug-listen 127.0.0.1:6060

En un altre terminal, captureu un perfil de memòria dinàmica:

go tool pprof http://localhost:6060/debug/pprof/heap

L’indicador --debug-listen està disponible a tap, process i hunt, i accepta adreces de bucle local per defecte. Per exposar pprof en una altra adreça, afegiu --debug-allow-non-loopback. Els desplegaments existents poden continuar utilitzant LC_PPROF_ADDR=127.0.0.1:6060 si s’omet l’indicador.

Per a comprovacions ràpides sense pprof:

Observeu l’ús de memòria al llarg del temps:

watch -n 10 'ps -o rss,vsz,comm -p $(pgrep -f "lc (sniff|hunt|process|tap)")'

Si la memòria creix contínuament, comproveu si hi ha:

• Un temps d’espera de flux TCP massa alt (no s’alliberen les memòries intermèdies obsoletes)
• Un nombre de memòries intermèdies massa alt per a la RAM disponible
• Absència de l’indicador --memory-optimization en sistemes amb recursos limitats

Referència ràpida

Anàlisi detallada dels protocols

Els analitzadors de protocols de lippycat extreuen metadades estructurades i admeten filtratge adaptat al protocol. Aquests capítols cobreixen el comportament de cada analitzador, els camps de metadades i investigacions pràctiques:

• VoIP: anàlisi de SIP i RTP: senyalització, fluxos multimèdia, qualitat de trucades i PCAP per trucada.
• Anàlisi de DNS: correlació de consultes, metadades i detecció de túnels.
• Inspecció de TLS: negociacions, certificats i empremtes.
• Anàlisi d’HTTP: peticions, respostes i captura del cos.
• Anàlisi de protocols de correu electrònic: SMTP, IMAP i POP3.
• Captura RADIUS i POI: autenticació, comptabilització i operacions POI autoritzades.

Per veure les subordres i opcions de protocol, consulteu Captura CLI amb lc sniff. Els exemples utilitzen jq; consulteu Treballar amb la sortida JSON per veure convencions de sortida compartides, canalització i fluxos de reproducció.

VoIP: anàlisi de SIP i RTP

L’anàlisi VoIP és el mode de protocol més madur de lippycat. Segueix els diàlegs de senyalització SIP, correlaciona els fluxos de mitjans RTP amb les sessions SIP que els controlen i admet l’extracció de PCAP per trucada per a l’anàlisi fora de línia.

Flux de senyalització SIP

SIP (Session Initiation Protocol) utilitza un model de petició/resposta per establir, modificar i acabar trucades de veu i vídeo. lippycat segueix tot el cicle de vida del diàleg. Una trucada reeixida típica segueix aquesta seqüència:

sequenceDiagram
    participant Caller
    participant Callee

    Caller->>Callee: INVITE (SDP offer)
    Callee-->>Caller: 100 Trying
    Callee-->>Caller: 180 Ringing
    Callee-->>Caller: 200 OK (SDP answer)
    Caller->>Callee: ACK

    Note over Caller,Callee: RTP media (bidirectional)
    Caller->>Callee: RTP audio stream
    Callee->>Caller: RTP audio stream

    Callee->>Caller: BYE
    Caller-->>Callee: 200 OK

lippycat analitza cada missatge SIP i n’extreu:

Mètodes SIP que lippycat reconeix: INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS, PRACK, UPDATE, INFO, REFER, SUBSCRIBE, NOTIFY, MESSAGE, PUBLISH.

Captura de trànsit SIP

La captura VoIP bàsica mostra tot el trànsit SIP i RTP d’una interfície:

sudo lc sniff voip -i eth0

Filtreu per usuari SIP per centrar-vos en extrems concrets:

Per a un sol usuari:

sudo lc sniff voip -i eth0 -u alicent

Per a diversos usuaris:

sudo lc sniff voip -i eth0 -u "alicent,robb"

Per a una coincidència de sufix amb comodí (tots els números acabats en 456789):

sudo lc sniff voip -i eth0 -u "*456789"

Extraieu informació d’establiment de trucada amb jq:

Per mostrar totes les peticions INVITE amb qui truca i qui rep la trucada:

sudo lc sniff voip -i eth0 2>/dev/null | \
  jq -r 'select(.VoIPData.Method == "INVITE") |
    [.Timestamp, .VoIPData.From, .VoIPData.To, .VoIPData.CallID] |
    @tsv'

Per seguir les transicions d’estat d’una trucada amb un Call-ID concret:

sudo lc sniff voip -i eth0 2>/dev/null | \
  jq -r 'select(.VoIPData.CallID == "abc123@pbx.local") |
    [.Timestamp, .VoIPData.Method // ("Response " + (.VoIPData.Status|tostring))] |
    @tsv'

Transport SIP: UDP i TCP

SIP funciona tant sobre UDP com sobre TCP. UDP és més habitual per a la senyalització, però TCP s’utilitza per a missatges grans (p. ex., SIP amb SDP que supera l’MTU) i és necessari per a SIP xifrat amb TLS (SIPS).

Per defecte, lippycat captura tant el trànsit SIP UDP com TCP. SIP TCP requereix reassemblatge del flux, cosa que afegeix sobrecàrrega de CPU. En xarxes amb molt trànsit TCP que no és SIP, podeu ometre completament el processament TCP:

El mode només UDP genera un filtre BPF optimitzat que exclou TCP:

sudo lc sniff voip -i eth0 -U -S 5060

Quan cal SIP TCP, trieu un perfil de rendiment per ajustar els paràmetres de reassemblatge (vegeu Captura CLI amb lc sniff):

sudo lc sniff voip -i eth0 -M throughput

Fluxos de mitjans RTP i SRTP

Un cop establert un diàleg SIP, els mitjans circulen com a paquets RTP (Real-time Transport Protocol). lippycat detecta els fluxos RTP identificant paquets dins dels intervals de ports configurats (per defecte: 10000-32768) que coincideixen amb l’estructura de la capçalera RTP.

Cada paquet RTP conté metadades que lippycat extreu:

lippycat correlaciona els fluxos RTP amb el diàleg SIP que els controla mitjançant el Call-ID. Quan els paquets RTP arriben abans de l’INVITE SIP corresponent (fet que passa quan la captura comença a mitja trucada), lippycat crea un registre de trucada sintètic i el fusiona quan apareix la senyalització SIP.

Supervisió dels fluxos RTP:

Per mostrar els fluxos RTP actius amb SSRC i còdec:

sudo lc sniff voip -i eth0 2>/dev/null | \
  jq -r 'select(.VoIPData.IsRTP) |
    [.SrcIP, .DstIP, .VoIPData.SSRC, .VoIPData.Codec, .VoIPData.SequenceNum] |
    @tsv'

Per detectar salts en la seqüència RTP (possible pèrdua de paquets):

sudo lc sniff voip -i eth0 2>/dev/null | \
  jq -r 'select(.VoIPData.IsRTP) |
    [.VoIPData.SSRC, .VoIPData.SequenceNum] | @tsv' | \
  awk -F'\t' '{
    if (prev[$1] != "" && $2 != (prev[$1]+1) % 65536)
      print "Gap: SSRC="$1, "expected="(prev[$1]+1)%65536, "got="$2;
    prev[$1] = $2
  }'

Intervals de ports RTP personalitzats:

Si la vostra centraleta utilitza ports RTP no estàndard, especifiqueu explícitament l’interval:

sudo lc sniff voip -i eth0 -R 8000-9000

sudo lc sniff voip -i eth0 -R "8000-9000,40000-50000"

Mètriques de qualitat de les trucades

Els números de seqüència i les marques temporals RTP permeten analitzar la qualitat de les trucades. Tot i que lippycat captura les metadades RTP en brut, podeu obtenir mètriques estàndard de qualitat a partir de la sortida JSON:

Pèrdua de paquets: es detecta pels salts en el número de seqüència RTP. El número de seqüència és un comptador de 16 bits que augmenta una unitat per paquet i torna a zero després de 65535.

Jitter: variació en el temps d’arribada entre paquets. Calculeu-lo comparant l’interval d’arribada esperat (basat en marques temporals RTP) amb els temps d’arribada reals.

MOS (Mean Opinion Score): estimació de la qualitat de veu entre 1,0 (dolenta) i 5,0 (excel·lent). MOS es deriva del factor R, que té en compte el còdec, la pèrdua de paquets, el jitter i el retard. Un MOS superior a 4,0 es considera de bona qualitat.

Exemple: calculeu el percentatge de pèrdua de paquets per SSRC d’un fitxer PCAP:

El comandament següent analitza una gravació per SSRC. El comentari dins del programa awk forma part del programa i es conserva:

lc sniff voip -r call-recording.pcap 2>/dev/null | \
  jq -r 'select(.VoIPData.IsRTP) |
    [.VoIPData.SSRC, .VoIPData.SequenceNum] | @tsv' | \
  awk -F'\t' '
    { count[$1]++; seq[$1] = $2 }
    END {
      for (ssrc in count) {
        # Expected = max_seq - min_seq + 1 (approximate)
        loss = 1 - (count[ssrc] / (count[ssrc] + 0.001))
        printf "SSRC=%s packets=%d\n", ssrc, count[ssrc]
      }
    }'

Per supervisar la qualitat de les trucades en producció, exporteu les dades RTP a un sistema de supervisió dedicat o utilitzeu la vista de trucades en temps real de la TUI (vegeu Captura interactiva amb lc watch).

Flux de treball PCAP per trucada

L’escriptura PCAP per trucada crea fitxers de captura separats per a cada trucada VoIP, cosa que facilita arxivar, reproduir o compartir gravacions de trucades individuals.

La funció PCAP per trucada està disponible als nodes processadors i Tap. Crea dos fitxers per trucada:

20250123_143022_abc123_sip.pcap    # SIP signaling packets
20250123_143022_abc123_rtp.pcap    # RTP media packets

Captura independent amb PCAP per trucada (mode Tap):

sudo lc tap voip -i eth0 \
  --per-call-pcap \
  --per-call-pcap-dir /var/voip/calls \
  --per-call-pcap-pattern "{timestamp}_{callid}.pcap" \
  --insecure

Captura distribuïda amb PCAP per trucada (processador):

lc process --listen :55555 \
  --per-call-pcap \
  --per-call-pcap-dir /var/capture/calls \
  --pcap-command 'gzip %pcap%' \
  --tls-cert server.crt --tls-key server.key

El hook --pcap-command s’executa quan es tanca cada fitxer PCAP i permet comprimir, pujar o arxivar automàticament. El hook --voip-command s’executa quan acaba tota una trucada (tots dos fitxers SIP i RTP estan finalitzats):

lc process --listen :55555 \
  --per-call-pcap --per-call-pcap-dir /var/capture/calls \
  --pcap-command 'gzip %pcap%' \
  --voip-command '/opt/scripts/process-call.sh %callid% %dirname%' \
  --tls-cert server.crt --tls-key server.key

Marcadors dels patrons de noms de fitxer: {callid}, {from}, {to}, {timestamp}.

El període de gràcia PCAP (--pcap-grace-period, 5 segons per defecte) controla quant espera lippycat després de l’últim paquet abans de tancar els fitxers PCAP d’una trucada. Això té en compte els paquets RTP que arriben tard i les retransmissions.

Per a la configuració completa del PCAP per trucada, vegeu Agregació central amb lc process i Mode independent amb lc tap.

Flux de dades VoIP

Entendre com circulen els paquets per l’analitzador VoIP ajuda a resoldre problemes i ajustar el rendiment:

flowchart LR
    A[Network Interface] --> B[gopacket]
    B --> C{Protocol Detection}
    C -->|UDP| D[SIP Parser]
    C -->|UDP| E[RTP Detector]
    C -->|TCP| F[TCP Reassembly]
    F --> D
    D --> G[VoIP Packet Processor]
    E --> G
    G --> H{GPU Available?}
    H -->|Yes| I[GPU Acceleration]
    H -->|No| J[CPU Processing]
    I --> K[Filter & Display]
    J --> K

Els paquets SIP UDP s’analitzen directament. Els paquets SIP TCP passen primer pel motor de reassemblatge (configurat amb --tcp-performance-mode). Els paquets RTP es detecten per l’estructura de la capçalera dins de l’interval de ports configurat. El processador de paquets VoIP correlaciona els fluxos RTP amb els diàlegs SIP mitjançant el Call-ID. L’acceleració GPU, quan està disponible, descarrega la cerca de patrons per al filtratge d’usuaris SIP.

Captura selectiva de mitjans amb eBPF

hunt voip --rtp-ebpf i tap voip --rtp-ebpf poden rebutjar mitjans no relacionats abans que libpcap els transmeti per descodificar-los en l’espai d’usuari. Aquesta via Linux activada explícitament manté el lector libpcap i actualitza els mapes d’un filtre de socket persistent quan canvien les trucades seleccionades. No reinicia la captura per l’activitat de trucades. L’assignació existent en l’espai d’usuari, l’atribució de filtres, la caducitat i les comprovacions de sortida continuen sent autoritatives.

Els mitjans seleccionats per trucada es capturen només després de la selecció i la publicació dels extrems. Les metadades SDP validades i limitades es poden conservar abans de la selecció; no es conserva l’historial RTP. Els filtres IP/CIDR independents i la política configurada sense filtres continuen aplicant-se.

L’aprenentatge compartit d’SDP conserva les seccions de mitjans independents vàlides abans i després d’una secció invàlida, només amb extrems IP/port numèrics exactes. No fa inferències a partir de DNS, candidats ICE ni intervals d’adreces. S’admeten els perfils RTP i UDP/TLS/RTP per a àudio, vídeo i altres tipus de mitjans. RTCP utilitza per defecte el port següent; un port/adreça RTCP explícit substitueix aquest valor, mentre que RTCP mux utilitza un extrem compartit. El port RTP 65535 requereix a=rtcp-mux, a=rtcp-mux-only o un port/adreça a=rtcp: explícit vàlid: el port següent implícit seria 65536, fora de l’interval UDP. Sense una d’aquestes declaracions, l’analitzador rebutja conservadorament tota la secció. Les dades invàlides de mitjans, connexió o RTCP invaliden la secció afectada sense reutilitzar l’adreça d’una secció anterior. Les dades invàlides de connexió de sessió impedeixen heretar extrems; encara es pot utilitzar una adreça posterior vàlida a nivell de mitjans. Els ports zero, els mitjans inactius i les adreces de pausa no especificades no aporten extrems nous. Els extrems acceptats prèviament es conserven fins a la neteja autoritativa del cicle de vida de la trucada. En arribar a la capacitat, només es conserven els primers extrems únics en l’ordre del trànsit dins del límit configurat i la derivació queda incompleta. La derivació incompleta d’una trucada seleccionada aplica la política de fallada d’admissió configurada i bloqueja la recuperació de l’aplicació del filtre fins que el context de senyalització afectat es repari, se substitueixi vàlidament o es retiri. Una resposta completa de l’altra part no resol per si sola una oferta incompleta. L’SDP en mètodes SIP no relacionats no resol la incertesa de negociació. Rebutjar una oferta posterior conserva la incertesa del seu predecessor fins que una negociació reeixida n’estableixi la substitució.

La recuperació d’admissió admet la seqüència d’oferta diferida formada per un INVITE observat sense cos, una resposta provisional fiable inicial amb etiqueta (per exemple, 183) que conté l’oferta SDP amb capçaleres Require: 100rel i RSeq vàlides, i una resposta SDP completa en el PRACK corresponent. La prova requereix la mateixa branca de diàleg i el mateix cicle de vida de la trucada seleccionada: el número de resposta RAck de PRACK ha de coincidir amb RSeq i el número/mètode CSeq que referencia ha de coincidir amb el CSeq INVITE de la resposta provisional. El CSeq propi de PRACK i la branca Via identifiquen la seva transacció separada. L’oferta sola, una resposta final o ACK sense cos i l’SDP de PRACK no relacionat no poden resoldre la resposta que falta. Les proves absents, contradictòries, caducades sense correspondència o perdudes per capacitat continuen sent incertes; encara es poden promoure extrems segurs independentment. Altres contextos no resolts, promocions d’extrems fallides o escriptures de control també impedeixen la recuperació. Els enllaços conservats estan limitats i no apareixen als logs d’estat ni d’avisos.

La recuperació conserva enllaços fiables limitats d’oferta/resposta per iniciador de petició i branca de diàleg. La resposta fiable inicial ha de tenir RSeq entre 1 i 2^31-1; les respostes fiables vàlides posteriors continuen requerint enllaç exacte i confirmació. Els enllaços sense correspondència caduquen amb pending_ttl. Un cop validada la resposta, el seu context limitat del cicle de vida actual sobreviu a aquesta caducitat fins a la substitució o retirada aplicable. Un rebuig amb correspondència exacta del PRACK restaura la incertesa.

L’oferta provisional fiable requereix la resposta en PRACK, tal com defineix RFC 3262, secció 5. L’SDP en ACK després d’un PRACK sense cos no substitueix aquesta prova d’admissió que falta; l’intercanvi continua sent incert. L’associació SDP ordinària del processador és un comportament separat i encara pot associar extrems d’ACK. Un UPDATE primerenc no pot respondre una oferta provisional fiable pendent. Els UPDATE primerencs i els de diàleg establert tenen restriccions d’oferta/resposta diferents, tal com descriu RFC 3311, secció 5.1.

Després que una resposta final INVITE reeixida observada estableixi el diàleg, un re-INVITE complet confirmat o un UPDATE de diàleg establert de qualsevol participant pot substituir la incertesa de negociació aplicable en aquell mateix diàleg i trucada activa. Això inclou capçaleres de transacció contradictòries, PRACK defectuós, ofertes diferides no resoltes i SDP parcial. La vigència es comprova en l’espai de seqüència de l’iniciador de la reparació; els números CSeq de qui truca i de qui rep la trucada no es comparen mai entre si. Una petició sola, una resposta parcial o rebutjada, capçaleres de substitució contradictòries, un intercanvi obsolet o un altre diàleg no poden establir la recuperació. Els contextos independents no resolts, la pèrdua de proves de cicle de vida/recursos, les promocions d’extrems fallides i les escriptures de control encara impedeixen restaurar l’aplicació del filtre.

En mode enforce, l’assignació obsoleta d’extrems basada només en incertesa continua disponible durant la gràcia de mitjans finals del rol. Els extrems necessaris per a un intercanvi històric vàlid, la reparació completa o una obligació independent continuen protegits; les observacions parcials o contradictòries no esdevenen historial vàlid només perquè s’hagin conservat. Una negociació vàlida que recupera un extrem cancel·la només la retirada pendent d’aquell extrem. La neteja torna a comprovar el cicle de vida exacte i els requisits independents actuals; un callback obsolet no pot eliminar l’assignació d’un cicle de vida reutilitzat. L’acabament autoritatiu de la trucada deixa la neteja final per al període de gràcia d’acabament. Les noves ofertes vàlides i la pausa/represa conserven l’assignació històrica del registre. La recuperació shadow actualitza proves i diagnòstics tot conservant l’assignació d’extrems en l’espai d’usuari. L’estat de retirada utilitza els límits existents configurats de metadades i per propietari.

Tap utilitza el valor efectiu de --pcap-grace-period tant per a la retirada d’extrems com per a l’acabament de trucades; els valors no positius es normalitzen al valor existent per defecte de cinc segons abans de construir l’encaminament. Hunter utilitza el seu PCAPGracePeriod configurat amb el mateix valor alternatiu de cinc segons; no té cap opció --pcap-grace-period. Un pont d’admissió directe de baix nivell pot utilitzar intencionadament zero per a una retirada immediata; aquest comportament de biblioteca no canvia els valors d’inici per defecte dels rols.

La gràcia protegeix l’atribució durant la seva finestra, inclosa una parella obsoleta amb un extrem compartit per una altra trucada. Un cop caduca, encara s’aplica l’alternativa existent de resolució unilateral: els paquets arbitràriament tardans es poden resoldre mitjançant el propietari restant d’un extrem compartit. Els marcadors d’alliberament que suprimeixen aquesta alternativa són un reforç secundari i no s’implementen en aquest canvi.

L’analitzador SIP combina les línies Require repetides i conserva l’últim valor de les capçaleres úniques CSeq, RSeq i RAck per als consumidors generals. L’admissió accepta duplicats vàlids idèntics després de comparar-ne el significat: els camps numèrics ignoren els zeros inicials, es normalitzen els espais en blanc i els mètodes SIP es comparen distingint majúscules i minúscules. Un únic RSeq o RAck malformat invalida el seu enllaç fiable sense fer incert un intercanvi ordinari d’oferta/resposta altrament vàlid. Un grup repetit que contingui qualsevol valor malformat continua sent contradictori, incloses les barreges vàlid/malformat i les repeticions invàlides idèntiques. Un CSeq contradictori conserva només proves mínimes/màximes vàlides limitades per al seu iniciador; els conflictes de mètode i els límits malformats o no disponibles continuen sent explícitament incerts. Una substitució completa, correcta i confirmada ha de superar la marca d’incertesa aplicable. Encara es poden aprendre extrems SDP segurs de trucades seleccionades dins dels límits configurats, sense autoritzar sortides ni aportar proves. La política de fallada open/closed i totes les restriccions explícites de captura/espai d’usuari continuen vigents.

L’analitzador conserva l’interval validat CSeqMin/CSeqMax perquè les proves descriguin amb precisió cada ocurrència vàlida, independentment de l’últim valor de capçalera exposat als consumidors generals. Actualment, la recuperació utilitza només CSeqMax com a límit de vigència; CSeqMin es conserva per al contracte de proves de l’analitzador i la validació de l’interval, no com a segon llindar de recuperació.

Les proves pendents, la procedència dels extrems i la neteja diferida estan vinculades als cicles de vida autoritatius de les trucades. Les proves vinculades explícitament a una sessió/generació antiga es rebutgen fins i tot després que caduqui l’historial de reproducció. La retirada registra proteccions exactes limitades de seqüència dels iniciadors anteriors per posar en quarantena identitats de trànsit reutilitzades durant replay_window (per defecte 2m), mesurat des de la retirada amb el rellotge monòton del pont en lloc de les marques temporals dels paquets. Una retirada posterior de la mateixa identitat renova la finestra; les observacions de reproducció no l’allarguen. Els conflictes malformats sense límits utilitzables bloquegen aquell iniciador; la pèrdua d’identitat/límits bloqueja el Call-ID reutilitzat dins de la finestra.

L’historial de reproducció té un conjunt separat només d’entrades exactes compartit entre dominis d’observació: replay_guard_capacity (per defecte 10000) i replay_guard_bytes (per defecte 2097152), amb 128 bytes comptabilitzats per entrada. S’apliquen tots dos límits; l’historial no consumeix capacitat de derivació seleccionada activa. Les proteccions no caducades no s’expulsen mai per admetre entrades noves. El manteniment de caducitat del worker existent recorre el mapa exacte, amb el treball limitat per la capacitat configurada. El tancament allibera els recursos comptabilitzats. No hi ha cap magatzem probabilístic de desbordament.

Si no es pot registrar una protecció de retirada, totes les proves d’aquell domini d’observació són conservadores fins a l’última retirada no registrable més replay_window. Aquesta alternativa conserva les proteccions exactes existents i segueix la política open/closed configurada; no deixa el pont permanentment inutilitzable. La sobrecàrrega sostinguda pot allargar l’interval. Un cop caduca, les trucades ja actives concilien les proves restants i les incerteses independents en lloc de declarar-se conegudes a cegues. Quan la pressió de reproducció ha descartat observacions, la recuperació requereix una nova petició completa i una resposta corresponent observades després del descart; una resposta en memòria cau anterior a la pressió no pot substituir proves absents. Retirar una trucada amb aquestes proves absents registra una protecció de Call-ID bloquejat durant la finestra. Els avisos agregats es limiten a l’interval de reintent i no inclouen identitats del trànsit.

El valor per defecte de dos minuts és un marge d’enginyeria respecte de l’horitzó habitual de transacció SIP de 32 segons, 64 vegades T1 amb T1 de 500 ms, descrit a RFC 3261, secció 17.1.1.2, i del pending_ttl existent de 30 segons. No limita tots els diàlegs SIP, el reassemblatge TCP, les cues de captura, l’emmagatzematge temporal dels Hunters ni els retards de transmissió. Configureu la finestra segons els retards coneguts del desplegament. Un cop caduca, les identitats de trànsit idèntiques no vinculades no poden distingir un intercanvi nou d’una captura antiga o d’un missatge retardat; les reproduccions arbitràries queden fora d’aquesta garantia de protecció finita.

Les proves de diàlegs primerencs es conserven separadament per a cada branca limitada. La confirmació observada resol el diàleg guanyador; l’assignació exclusiva dels diàlegs perdedors segueix la gràcia de mitjans finals, mentre es mantenen els requisits compartits i independents. Diverses branques reeixides continuen sent conservadores. Tant una oferta INVITE amb la seva resposta fiable com una oferta diferida amb la seva resposta PRACK poden conservar l’SDP canònic acceptat mentre es repeteix SDP idèntic en una resposta provisional fiable posterior. Cada resposta provisional nova requereix el seu propi RSeq següent vàlid i el RAck/PRACK corresponent en el mateix cicle de vida i diàleg primerenc. Les retransmissions amb el mateix RSeq no generen una nova obligació de confirmació. L’SDP modificat continua sent conservador i només afegeix extrems fins a una reparació vàlida; un 200 final que repeteixi la resposta canònica no pot eludir un PRACK pendent. Els bytes SDP iguals per si sols no poden validar proves RSeq, RAck, de diàleg o de cicle de vida no relacionades.

rtp_ebpf.scopes[].uncertainty informa per domini de unknown_calls actives úniques i de comptadors de motius superposats: conflicting_headers, faulty_prack, partial_sdp, delayed_offer, fork_ambiguity i evidence_loss. Una trucada pot tenir diversos motius; no sumeu els comptadors de motius per obtenir un total de trucades. identical_duplicates i conflicting_duplicates són comptadors acumulatius de missatges amb un grup de capçalera única repetit, comptats separadament per CSeq, RSeq i RAck. Tres o més línies repetides en un grup compten una vegada, no una per línia; aquests comptadors no compten les trucades actualment desconegudes. Els duplicats vàlids idèntics per si sols no creen incertesa.

malformed_rseq i malformed_rack compten separadament els missatges analitzats que contenen almenys una ocurrència malformada d’aquell tipus de capçalera, una vegada per tipus i missatge, incloses les retransmissions. Un grup de duplicats mixt o invàlid incrementa tant el comptador del tipus malformat com conflicting_duplicates; una capçalera única malformada no incrementa el comptador de duplicats. Aquests comptadors d’ocurrències són independents dels totals de trucades actives desconegudes i es poden superposar.

replay_guards i replay_guard_bytes informen de l’ús d’historial exacte per domini; replay_guard_capacity i replay_guard_byte_limit són límits del conjunt compartit, no quotes multiplicades pel nombre de dominis. replay_window_ns informa de la finestra efectiva configurada. replay_unrecorded compta acumulativament els intents fallits d’inserció de proteccions i replay_degraded_ns és l’interval conservador restant de tot el domini, zero quan és inactiu. Les trucades actives afectades per aquell interval també apareixen als totals únics de trucades desconegudes i als comptadors superposats evidence_loss. Aquests camps no requereixen identitats ni etiquetes dinàmiques; les versions antigues els ometen.

degraded_since_unix_ns identifica l’inici de la degradació actual i degraded_duration_ns la seva durada transcorreguda, inclosos els estats degraded-closed i control-failed. Una conciliació completa reeixida restableix tots dos; open_duration_ns continua sent el temps acumulatiu d’obertura confirmada i té un significat diferent. El JSON d’estat CLI exposa aquests camps addicionals. La vista Nodes mostra diagnòstics agregats d’admissió per al Hunter o processador/Tap seleccionat tant en disposició de taula com de graf. En aquests diagnòstics no apareixen adreces d’extrems, identitats de trucada ni errors bruts de l’analitzador/backend. Els nodes antics ometen els camps nous i els clients antics els ignoren.

Aquesta semàntica compartida dels extrems també s’aplica amb eBPF desactivat; obrir l’admissió del nucli no inventa mai atribució en l’espai d’usuari.

El pressupost d’extrems del rastrejador inclou RTP, RTCP separat i claus de diagnòstic antigues basades només en ports. Les claus de diagnòstic no poden autoritzar mitjans, però poden ocupar espai necessari per a extrems exactes posteriors durant canvis de mitjans. Aquest pressupost compartit és anterior a la correcció posterior. Sense admissió, el rastrejador ordinari té un valor de biblioteca per defecte de 64 extrems per trucada i el processador VoIP local de 32; la connexió actual dels comandaments no ofereix cap paràmetre de límit d’extrems per a l’operador. Els paràmetres de recursos d’admissió no augmenten aquests límits ordinaris del registre. Tingueu en compte l’RTCP separat i les claus de diagnòstic en interpretar els avisos de limitació de recursos. L’expulsió o retirada del rastrejador acaba la selecció heretada del Hunter encara que quedi un buffer temporal; les coincidències obsoletes en buffer no autoritzen sortides. Si el conjunt de tokens de propietaris seleccionats es desborda, la recuperació requereix un registre autoritatiu buit, inclosa la retirada de trucades no seleccionades, o una captura reiniciada explícitament després de corregir les condicions de capacitat.

Els avisos SDP informen durant el manteniment de comptadors agregats depurats de casos parcials, fallits, limitats per recursos i suprimits, com a màxim una vegada per interval de 30 segons, més un resum final pendent en aturar-se. S’apliquen els paràmetres normals del logger. No necessiten eBPF ni sortida de logs estructurats. Sniff/Hunter utilitzen informes de buffer, Tap utilitza el seu processador local i el processament distribuït informa de missatges SIP complets per la seva pròpia via. El tractament de paquets no espera l’E/S de logs.

Amb --rtp-ebpf, no necessiteu --rtp-port-range: els extrems RTP i RTCP s’aprenen de l’SDP de la trucada seleccionada, inclosos els extrems fora de l’interval generat per defecte 10000–32768. Utilitzeu --sip-port per limitar la captura de senyalització als vostres ports SIP; és opcional i ometre’l conserva la descoberta en ports arbitraris. Per exemple:

sudo lc hunt voip --processor processor:55555 -i eth0 \
  --rtp-ebpf --sip-port 5060 --tls-ca ca.crt

Si establiu explícitament --rtp-port-range, continua sent una restricció de captura: s’exclouen els extrems de mitjans apresos fora d’aquell interval. Un --filter explícit també continua vigent i ha de permetre la senyalització i els mitjans que voleu capturar.

Els ports SIP explícits també limiten la descoberta UDP sense mitjans: un datagrama sense una capçalera RTP/RTCP reconeguda amb confiança s’exclou fora d’aquells ports de senyalització, fins i tot en un port explícit d’interval de mitjans. El BPF ordinari basat en ports amb admissió desactivada pot admetre aquest datagrama. Els modes shadow i degraded-open conserven aquesta limitació explícita.

Amb --rtp-ebpf, inclòs el mode shadow, els selectors IP/CIDR de Hunt i Tap admeten mitjans elegibles independentment dels extrems de trucades seleccionades. No eludeixen mai els predicats explícits de paquets ni les comprovacions de sortida en l’espai d’usuari. Amb eBPF desactivat, Tap encamina els filtres IP/CIDR mitjançant BPF clàssic. En configuracions mixtes de filtres IP i identitat SIP, un paquet RTP coincident per IP es pot capturar però rebutjar en l’espai d’usuari perquè no està associat a una trucada seleccionada. Per tant, desactivar l’admissió no conserva aquesta sortida de filtres mixtos per als mitjans no associats. Les configuracions Tap realment només IP no tenen cap filtre d’identitat SIP que exigeixi aquesta associació. La selecció de mitjans IP/CIDR del Hunter continua sent independent amb eBPF activat o desactivat.

--rtp-ebpf-mode=shadow registra decisions limitades tot conservant la recepció dinàmica de mitjans. Les fallades d’actualització en execució provoquen per defecte admissió àmplia dins del domini afectat, conservant les restriccions explícites de captura; --rtp-ebpf-failure-policy=closed conserva les entrades vàlides instal·lades sense obrir. Una escriptura fallida de control de mode s’informa separadament. L’aplicació del filtre només es reprèn després de conciliar completament l’estat actual. Una fallada d’inici no activa mai silenciosament shadow ni una captura àmplia.

--rtp-ebpf-shadow-sample-every (per defecte 1) utilitza mostreig determinista compartit per les decisions del nucli, l’observació de captura i l’atribució verificada; YAML utilitza rtp_ebpf.shadow_sample_every sota els paràmetres VoIP del rol. Per a trames completes de fins a 256 bytes, la regla inclou el domini, la longitud completa i tots els bytes de la trama. Un N positiu selecciona aproximadament una de cada N identitats; 1 inclou totes les identitats elegibles. Les còpies idèntiques comparteixen l’elegibilitat i es compta cada còpia elegible. Els hash trien mostres; els bytes exactes estableixen la identitat. Les observacions no mostrejades no ocupen entrades de correlació. Aquest paràmetre sol no activa l’admissió.

Avís de dimensionament shadow: els valors per defecte conserven només 1024 identitats de trames elegibles diferents, mostregen cada identitat (N=1) i mantenen les entrades durant uns 60–61 segons. Això deixa poc espai per a trànsit de fons elegible diferent. Dividir 1024 per aquesta finestra de retenció dona aproximadament 17 identitats elegibles diferents per segon abans de reservar marge per a ràfegues. És un càlcul teòric de dimensionament de l’emmagatzematge, no una taxa de paquets admesa, un rendiment mesurat ni un llindar d’acceptació. Una identitat és una trama completa, de manera que modificar números de seqüència o dades útils crea identitats noves fins i tot dins del mateix flux.

shadow_evidence_capacity limita les identitats de trames completes elegibles diferents. Les entrades de correlació caduquen estrictament després del doble de pending_ttl, en el següent manteniment de retry_interval. El dimensionament aproximat és el nombre d’identitats elegibles diferents per segon multiplicat per aquella finestra, amb marge per a ràfegues; la finestra per defecte és d’uns 60–61 segons. pending_ttl també controla les metadades SIP pendents, de manera que reduir-lo canvia el comportament de promoció. L’historial de propietaris retirats dura més de tres TTL i continua limitat per la capacitat de propietaris. L’historial separat de mostres utilitza el mateix paràmetre de capacitat de proves, compta ocurrències i pot sobreescriure encara que la taula d’identitats tingui espai.

Quan augmenta el volum d’identitats elegibles, considereu augmentar l’interval de mostreig abans d’augmentar la capacitat. El mostreig redueix tant les identitats conservades com el treball dels hooks mentre compta cada còpia de cada identitat elegible. Una capacitat més gran conserva més proves, però augmenta la memòria i el treball de manteniment: el manteniment recorre les entrades mantenint el mutex de correlació i les observacions elegibles concurrents utilitzen TryLock. No obtenir el bloqueig implica una pèrdua real de proves i pot impedir la classificació; una capacitat més gran per si sola no garanteix proves completes.

L’emmagatzematge creix separadament per a la taula de correlació de trames completes, l’historial de mostres de diagnòstic, l’historial de propietaris i l’anell del nucli. La taula d’identitats conté els bytes exactes de les trames i l’estat de correlació; l’historial de mostres conté ocurrències limitades i pot sobreescriure independentment; l’historial de propietaris està limitat per la seva capacitat; l’emmagatzematge de l’anell del nucli està limitat separadament. El mostreig canvia quines observacions entren en aquestes vies però no n’augmenta les capacitats configurades. No s’hi implica cap estimació fixa de memòria per entrada ni garantia de durada del recorregut.

La classificació requereix proves úniques de trama completa, observació de captura, atribució verificada al cicle de vida seleccionat i generació històrica de publicació. Les trames de més de 256 bytes, les proves truncades o duplicades, les mostres tardanes, l’absència de propietari, les diferències de configuració i les revisions d’extrems modificades continuen sent incompletes. El desbordament elegible real o la pressió de bloqueig invaliden afirmacions d’unicitat no demostrades, potencialment també sobre altres proves pendents. La pèrdua persistent pot impedir classificacions útils. L’estat no exposa continguts de paquets ni identitats de trucades. La pèrdua de l’anell del nucli, la sobreescriptura de mostres conservades, les mostres malformades, els errors de recollida i la correlació incompleta tenen comptadors separats. Els rebutjos classificats són observacions mostrejades, mai comptadors exactes de rebuig de tot el trànsit ni proves de paritat.

Els diagnòstics de mitjans absents distingeixen la derivació d’extrems desconeguda dels mitjans intencionadament inactius. Una revisió acceptada d’extrem o completesa restableix l’expectativa, de manera que un paquet de mitjans anterior no pot ocultar un canvi posterior de mitjans. Els avisos per propietari estan limitats en nombre i freqüència i només identifiquen una referència numèrica transitòria del propietari. No amplien mai l’admissió automàticament.

Per defecte, totes les interfícies comparteixen un domini d’observació. Els paràmetres de domini explícits separen trànsit local superposat i han d’agrupar la senyalització i els mitjans relacionats. S’admet Ethernet; la captura cooked any i els predicats VLAN explícits es rebutgen. Els fragments, les cadenes complexes d’extensions i l’encapsulació admesa poden passar per una via de compatibilitat comptabilitzada, cosa que redueix la selectivitat. Els paquets desconeguts i els diagnòstics de mitjans absents no obren cap domini.

La senyalització TCP reassemblada de Tap utilitza la interfície i la marca temporal de captura de l’últim byte que contribueix al missatge. Les interfícies del mateix domini d’observació comparteixen l’emmarcament, inclosos els segments en cua, però cada missatge sintetitzat conserva la font real que hi contribueix. Les interfícies de dominis separats no completen mai les trames de les altres. Les trucades senyalitzades per TCP comparteixen la mateixa comptabilització de capacitat que les senyalitzades per UDP. Les respostes terminals de diàleg només completen després del tractament pel processador (o d’un descart explícit d’injecció), conservant la gràcia de mitjans finals i la neteja específica del cicle de vida. Amb l’admissió desactivada, els límits de trucades no positius conserven el valor antic per defecte; els pressupostos positius configurats continuen aplicant-se.

L’admissió de sockets requereix sockets Linux AF_PACKET, SO_ATTACH_BPF, crides BPF activades, els tipus de mapa necessaris i helpers d’anell. Els anells es van introduir a Linux 5.8; això és un mínim funcional, no una versió mínima del nucli verificada universalment. La configuració del nucli, el comportament del verificador, la política de distribució i les restriccions dels contenidors encara poden rebutjar l’inici. Els sockets de paquets requereixen CAP_NET_RAW; les operacions privilegiades d’objectes BPF requereixen CAP_BPF o l’alternativa antiga CAP_SYS_ADMIN. CAP_NET_ADMIN no és un requisit general del carregador de filtres de socket; la configuració de captura pot requerir permisos independentment. Abans de Linux 5.11, la memòria BPF habitualment compta contra RLIMIT_MEMLOCK; els nuclis més nous poden utilitzar comptabilització de memòria per cgroup. L’aplicació no augmenta automàticament el límit de memòria bloquejada. Vegeu el carregador BPF de Linux, la documentació dels anells i les indicacions de comptabilització de memòria.

Els gestors activats utilitzen el mode immediat i retiren les dades de socket/anell conservades abans de l’activació; els paquets posteriors no es comparen amb un límit permanent del rellotge del sistema. El buidatge d’inici és limitat i permet pèrdua de paquets. Els enllaços no admesos, els predicats VLAN explícits, l’ús fora de línia, la retirada de packet-mmap no admesa i els errors de càrrega, associació o buidatge fan fallar l’inici explícitament.

Vegeu la referència de configuració per a tots els límits de recursos. docs/VOIP_EBPF_ADMISSION.md del repositori proporciona detalls de plataforma, privilegis, diagnòstic i verificació; el pla d’implementació registra l’estat actual d’integració. libpcap continua sent una dependència cgo i cgo no desactiva la concurrència de goroutines.

Anàlisi de DNS

L’analitzador DNS correlaciona les consultes amb les seves respostes i mesura la latència de resolució.

Correlació de consulta/resposta

lippycat associa les consultes DNS amb les seves respostes utilitzant l’identificador de transacció (un identificador de 16 bits a la capçalera DNS). Quan es correlaciona una resposta, el camp QueryResponseTimeMs mostra el temps d’anada i tornada en mil·lisegons.

sequenceDiagram
    participant Client
    participant Resolver

    Client->>Resolver: Query (TxID: 0xA1B2, A record for example.com)
    Resolver-->>Client: Response (TxID: 0xA1B2, 93.184.216.34, TTL=3600)
    Note right of Client: RTT measured

Iniciar la captura DNS:

sudo lc sniff dns -i eth0

Filtrar per domini:

Per a un domini exacte:

sudo lc sniff dns -i eth0 --domain example.com

Per a coincidències amb comodins:

sudo lc sniff dns -i eth0 --domain "*.example.com"

Carregar patrons de domini d’un fitxer per al monitoratge massiu:

sudo lc sniff dns -i eth0 --domains-file watchlist.txt

Camps de metadades DNS

Cada paquet DNS inclou metadades estructurades:

Investigacions DNS habituals

Trobar resolucions DNS lentes:

sudo lc sniff dns -i eth0 2>/dev/null | \
  jq -r 'select(.DNSData.IsResponse and .DNSData.QueryResponseTimeMs > 100) |
    [.Timestamp, .DNSData.QueryName, (.DNSData.QueryResponseTimeMs|tostring) + "ms"] |
    @tsv'

Supervisar respostes NXDOMAIN (dominis inexistents):

sudo lc sniff dns -i eth0 2>/dev/null | \
  jq -r 'select(.DNSData.ResponseCode == "NXDOMAIN") |
    [.Timestamp, .SrcIP, .DNSData.QueryName] | @tsv'

Seguir tipus de registre concrets:

Per a consultes de registres MX (descobriment de servidors de correu):

sudo lc sniff dns -i eth0 2>/dev/null | \
  jq -r 'select(.DNSData.QueryType == "MX") |
    [.Timestamp, .DNSData.QueryName, (.DNSData.Answers[]?.Data // "pending")] |
    @tsv'

Per a registres TXT, que sovint s’utilitzen per a SPF, DKIM i verificació de dominis:

sudo lc sniff dns -i eth0 2>/dev/null | \
  jq 'select(.DNSData.QueryType == "TXT")'

Detecció de túnels DNS

lippycat inclou detecció de túnels DNS basada en entropia. Els túnels codifiquen dades en consultes DNS, generant noms de domini amb una entropia (aleatorietat) inusualment alta. L’analitzador puntua cada consulta de 0,0 (normal) a 1,0 (molt sospitosa):

Marcar possibles túnels DNS:

sudo lc sniff dns -i eth0 --detect-tunneling 2>/dev/null | \
  jq -r 'select(.DNSData.TunnelingScore > 0.7) |
    [.Timestamp, .SrcIP, .DNSData.QueryName,
     "score=" + (.DNSData.TunnelingScore|tostring)] | @tsv'

Les consultes d’alta entropia (subdominis llargs i aparentment aleatoris) combinades amb un gran volum de consultes a un sol domini són indicadors forts de túnels DNS o exfiltració de dades.

Inspecció de TLS

L’analitzador TLS inspecciona missatges de negociació sense desxifrar el trànsit. Extreu metadades de connexió dels missatges ClientHello i ServerHello, incloent-hi SNI, conjunts de xifratge i empremtes TLS.

Anàlisi de negociacions TLS

sequenceDiagram
    participant Client
    participant Server

    Client->>Server: ClientHello (SNI, cipher suites, extensions)
    Note right of Client: JA3 fingerprint computed
    Server-->>Client: ServerHello (selected cipher, extensions)
    Note right of Server: JA3S fingerprint computed
    Server-->>Client: Certificate (server certificate chain)
    Server-->>Client: ServerHelloDone
    Client->>Server: ClientKeyExchange
    Client->>Server: ChangeCipherSpec
    Client->>Server: Finished
    Server-->>Client: ChangeCipherSpec
    Server-->>Client: Finished
    Note over Client,Server: Encrypted application data

lippycat captura i analitza els missatges de negociació no xifrats a l’inici de cada connexió TLS.

Iniciar la captura TLS:

sudo lc sniff tls -i eth0

Filtrar per Server Name Indication (SNI):

Per a un domini concret:

sudo lc sniff tls -i eth0 --sni example.com

Per a un comodí:

sudo lc sniff tls -i eth0 --sni "*.example.com"

Per a filtratge massiu des d’un fitxer:

sudo lc sniff tls -i eth0 --sni-file domains.txt

Empremtes JA3 i JA3S

JA3 crea una empremta d’un client TLS calculant el hash dels camps següents del missatge ClientHello:

TLS Version | Cipher Suites | Extensions | Elliptic Curves | EC Point Formats

Aquests camps es concatenen i se’n calcula el hash MD5 per produir una empremta de 32 caràcters. Com que les diferents aplicacions construeixen el ClientHello de manera diferent (ordres diferents dels conjunts de xifratge, extensions diferents), l’empremta JA3 identifica el programari client independentment de l’adreça IP.

JA3S aplica el mateix concepte a ServerHello, generant l’empremta de la resposta del servidor (versió TLS, conjunt de xifratge seleccionat i extensions).

lippycat calcula totes dues automàticament:

Nota de compatibilitat JA4: les compilacions que inclouen la correcció de conformitat amb l’estàndard utilitzen SHA-256 (truncat a 12 caràcters hexadecimals) i la transformació del primer/últim caràcter ALPN requerida per JA4. Les empremtes produïdes per compilacions antigues de lippycat utilitzaven un valor MD5 truncat no estàndard i també poden codificar ALPN de manera diferent. Substituïu les empremtes JA4 emmagatzemades i els filtres tls_ja4 per valors generats per una implementació JA4 conforme. lippycat no compara silenciosament tots dos formats. No s’emet cap avís de compatibilitat en temps d’execució perquè els valors heretats i estàndard tenen la mateixa sintaxi i no es poden distingir de manera fiable.

Filtrar per una empremta coneguda:

Capturar trànsit que coincideixi amb una empremta JA3 coneguda de programari maliciós:

sudo lc sniff tls -i eth0 --ja3 "e7d705a3286e19ea42f587b344ee6865"

Carregar diverses empremtes d’un fitxer d’intel·ligència d’amenaces:

sudo lc sniff tls -i eth0 --ja3-file known-bad-ja3.txt

Crear un inventari d’empremtes:

Llistar empremtes JA3 úniques amb SNI:

sudo lc sniff tls -i eth0 2>/dev/null | \
  jq -r 'select(.TLSData.HandshakeType == "ClientHello") |
    [.SrcIP, .TLSData.SNI, .TLSData.JA3Fingerprint] | @tsv' | \
  sort -u

Camps de metadades TLS

Investigacions TLS habituals

Detectar versions TLS febles:

sudo lc sniff tls -i eth0 2>/dev/null | \
  jq -r 'select(.TLSData.Version == "TLS 1.0" or .TLSData.Version == "TLS 1.1") |
    [.Timestamp, .SrcIP, .DstIP, .TLSData.SNI, .TLSData.Version] | @tsv'

Correlacionar ClientHello amb ServerHello:

lippycat correlaciona parelles de negociació quan --track-connections està activat (per defecte). Les parelles correlacionades inclouen la latència de negociació:

sudo lc sniff tls -i eth0 2>/dev/null | \
  jq -r 'select(.TLSData.CorrelatedPeer) |
    [.Timestamp, .TLSData.SNI, (.TLSData.HandshakeTimeMs|tostring) + "ms"] |
    @tsv'

Connexions d’alt risc:

sudo lc sniff tls -i eth0 2>/dev/null | \
  jq -r 'select(.TLSData.RiskScore > 0.5) |
    [.Timestamp, .SrcIP, .TLSData.SNI, .TLSData.Version,
     "risk=" + (.TLSData.RiskScore|tostring)] | @tsv'

Anàlisi d’HTTP

L’analitzador HTTP reconstrueix parelles de petició/resposta dels fluxos TCP i mesura la latència de resposta.

Correlació de petició/resposta

lippycat segueix les converses HTTP correlacionant peticions amb les seves respostes a la mateixa connexió TCP. Quan la correlació té èxit, el camp RequestResponseTimeMs mostra el temps de resposta del servidor.

Iniciar la captura HTTP:

sudo lc sniff http -i eth0

Filtrar per amfitrió, camí, mètode o codi d’estat:

Filtrar per amfitrió:

sudo lc sniff http -i eth0 --host "*.example.com"

Filtrar per patró de camí:

sudo lc sniff http -i eth0 --path "/api/*"

Capturar només peticions POST i PUT:

sudo lc sniff http -i eth0 --method "POST,PUT"

Capturar només respostes d’error:

sudo lc sniff http -i eth0 --status "4xx,5xx"

Combinar filtres:

sudo lc sniff http -i eth0 --host api.example.com --method POST --status "5xx"

Camps de metadades HTTP

Investigacions HTTP habituals

Trobar respostes API lentes:

sudo lc sniff http -i eth0 2>/dev/null | \
  jq -r 'select(.HTTPData.Type == "response" and .HTTPData.RequestResponseTimeMs > 500) |
    [.Timestamp, .HTTPData.Host, .HTTPData.Path,
     (.HTTPData.StatusCode|tostring),
     (.HTTPData.RequestResponseTimeMs|tostring) + "ms"] | @tsv'

Supervisar taxes d’error:

sudo lc sniff http -i eth0 2>/dev/null | \
  jq -r 'select(.HTTPData.Type == "response") |
    (.HTTPData.StatusCode|tostring|.[0:1]) + "xx"' | \
  sort | uniq -c | sort -rn

Anàlisi del tipus de contingut:

sudo lc sniff http -i eth0 2>/dev/null | \
  jq -r 'select(.HTTPData.ContentType != null and .HTTPData.ContentType != "") |
    .HTTPData.ContentType' | \
  sort | uniq -c | sort -rn

Desxifratge HTTPS

Per al trànsit HTTPS, lippycat pot desxifrar dades d’aplicació si proporcioneu un fitxer de registre de claus TLS (SSLKEYLOGFILE):

sudo lc sniff http -i eth0 --tls-keylog /tmp/sslkeys.log

Això requereix que l’aplicació exporti les claus de sessió. Consulteu Seguretat per obtenir detalls sobre la configuració del desxifratge TLS.

Captura del cos

Per defecte, no es captura el contingut del cos HTTP. Activeu-la per inspeccionar el contingut:

sudo lc sniff http -i eth0 --capture-body --max-body-size 65536

Per comparar paraules clau en moltes peticions, utilitzeu el comparador massiu Aho-Corasick:

sudo lc sniff http -i eth0 --capture-body --keywords-file suspicious-terms.txt

Anàlisi de protocols de correu electrònic

L’analitzador de correu admet SMTP, IMAP i POP3 amb seguiment de sessions i correlació de transaccions.

Anàlisi de SMTP

La captura SMTP segueix la transacció del sobre: EHLO, MAIL FROM, RCPT TO, DATA i respostes del servidor. lippycat detecta la negociació STARTTLS i els intents d’autenticació.

sequenceDiagram
    participant Client
    participant Server

    Server-->>Client: 220 mail.example.com ESMTP
    Client->>Server: EHLO client.local
    Server-->>Client: 250-STARTTLS
    Client->>Server: STARTTLS
    Server-->>Client: 220 Ready
    Note over Client,Server: TLS handshake
    Client->>Server: EHLO client.local
    Client->>Server: AUTH LOGIN
    Server-->>Client: 235 Authenticated
    Client->>Server: MAIL FROM:<alice@example.com>
    Server-->>Client: 250 OK
    Client->>Server: RCPT TO:<bob@example.com>
    Server-->>Client: 250 OK
    Client->>Server: DATA
    Server-->>Client: 354 Start mail input
    Client->>Server: (message body)
    Client->>Server: .
    Server-->>Client: 250 OK

Iniciar la captura de correu electrònic:

Per a tots els protocols de correu:

sudo lc sniff email -i eth0

Només per a SMTP:

sudo lc sniff email -i eth0 --protocol smtp

Filtrar per adreça:

sudo lc sniff email -i eth0 --address alice@example.com

Filtrar específicament per remitent:

sudo lc sniff email -i eth0 --sender alice@example.com

Filtrar específicament per destinatari:

sudo lc sniff email -i eth0 --recipient bob@example.com

Camps de metadades de correu electrònic

IMAP i POP3

La captura IMAP i POP3 segueix les operacions de la bústia:

Només per a IMAP:

sudo lc sniff email -i eth0 --protocol imap

Per a ports personalitzats:

sudo lc sniff email -i eth0 --imap-port "143,993" --pop3-port "110,995"

Els camps específics d’IMAP inclouen l’etiqueta d’ordre, la bústia seleccionada, els UID dels missatges i els indicadors. Els camps POP3 inclouen números i mides de missatge.

Investigacions de correu habituals

Detectar sessions SMTP no xifrades:

sudo lc sniff email -i eth0 --protocol smtp 2>/dev/null | \
  jq -r 'select(.EmailData.Command == "EHLO" and
    .EmailData.STARTTLSOffered == false) |
    [.Timestamp, .SrcIP, .DstIP, "No STARTTLS"] | @tsv'

Supervisar intents d’autenticació:

sudo lc sniff email -i eth0 2>/dev/null | \
  jq -r 'select(.EmailData.AuthMethod != null and .EmailData.AuthMethod != "") |
    [.Timestamp, .SrcIP, .EmailData.Protocol, .EmailData.AuthMethod,
     .EmailData.AuthUser] | @tsv'

Seguir el flux de correu:

sudo lc sniff email -i eth0 --protocol smtp 2>/dev/null | \
  jq -r 'select(.EmailData.Command == "MAIL" or .EmailData.Command == "RCPT") |
    [.Timestamp, .EmailData.MailFrom // "", (.EmailData.RcptTo | join(","))] |
    @tsv'

Captura RADIUS i operacions POI de Tap

lc sniff radius, lc hunt radius i lc tap radius comparteixen descodificació UDP, predicats ordinaris exactes, perfils de captura i associació limitada de peticions. La captura ordinària no requereix ni una compilació LI ni una tasca X1 activada. lc process continua sent neutral respecte del protocol; utilitzeu els comandaments existents lc watch live, watch file i watch remote per veure les metadades RADIUS.

Les vies RADIUS de Tap local i Hunt/Process autenticades directament han superat verificacions sintètiques de versió, incloses les instantànies de filtres, l’aïllament d’àmbit en reconnectar, les sortides ordinàries i la paritat X2 descodificada. Actualitzeu tant el Hunter com el processador per obtenir instantànies de filtres autoritatives. Els relés conserven el trànsit ordinari però no transmeten l’autoritat de l’origen de captura per a X2. La verificació de línies conegudes en producció i l’acceptació del MDF receptor continuen pendents; les dades de prova del repositori són sintètiques.

Topologia de captura i àmbit admès

Emmiralleu l’enllaç UDP visible de BRAS/BNG a AAA en una interfície POI dedicada:

flowchart TB
    BNG["BRAS/BNG"] <--> RADIUS["UDP RADIUS link"] <--> AAA["AAA server"]
    RADIUS -->|"mirror"| POI["Dedicated tap POI"]
    POI -->|"X2/TLS"| MDF["MDF"]
    ADMF["ADMF"] -->|"X1/mTLS"| POI

Observeu tant la direcció de petició com la de resposta en la mateixa font de captura aïllada. Els valors per defecte inclouen UDP 1812 i 1813; els ports configurats s’afegeixen a aquests valors. S’admeten IPv4 i IPv6 Access-Request (1), Access-Accept (2), Access-Reject (3), Accounting-Request (4), Accounting-Response (5) i Access-Challenge (11). No s’admeten TCP, RadSec/TLS, DTLS, trànsit intern xifrat, CoA, Disconnect ni altres codis de missatge. No s’accepta ni es necessita cap secret compartit. Tots els fragments IPv4 i totes les capçaleres Fragment d’IPv6, inclosos els fragments atòmics, s’exclouen de l’anàlisi i l’atribució RADIUS. Les sortides genèriques de paquets poden conservar fragments si el BPF de captura els admet; un BPF només de ports no ho pot garantir.

L’àmbit de l’operador i la revisió del perfil descriuen una frontera d’unicitat establerta per l’administrador. Els noms d’interfície, els extrems IP, els atributs NAS i els filtres BPF no demostren aïllament d’operadors. Una font de proxy s’ha d’aïllar en aquella frontera; rebutgeu la selecció de línies en una font mixta amb valors concrets de línia no únics. Els extrems client/servidor de transport continuen separats dels camps NAS transportats pel paquet. Reiniciar o reobrir la captura inicia una època nova; les proves antigues no poden travessar aquest buit.

L’associació de respostes és observacional, no una verificació de l’autenticador. Sense secret, ni el Response Authenticator ni l’Identifier de vuit bits demostren pertinença. L’herència única requereix exactament una petició compatible observada en el mateix àmbit i tupla de captura. Les peticions competidores, l’estat caducat i la pèrdua de capacitat suprimeixen l’herència. Una challenge no autoritza l’intercanvi següent i l’autenticació no autoritza l’accounting posterior sense identitat. Les respostes observades abans de les seves peticions no s’emmagatzemen temporalment ni s’autoritzen retroactivament.

Confiança distribuïda i sincronització dels filtres

Per a RADIUS X2, connecteu el Hunter directament amb TLS mutu. El SAN del certificat de client verificat ha de coincidir amb el seu ID de Hunter; aquest ID també ha de coincidir amb l’origen de l’observació. TLS només de servidor i el transport insegur admeten captura ordinària però no autoritzen X2. Els processadors ascendents conserven els bytes originals, l’àmbit de captura i les proves d’atribució, però un certificat de relé només demostra la identitat del relé. Lliureu X2 al POI connectat directament; l’autorització d’origen de relé no forma part d’aquesta versió.

Els Hunters actualitzats demanen una instantània de filtres autoritativa en subscriure’s. El processador captura la política actual i connecta el flux d’actualitzacions atòmicament; el Hunter substitueix tota la seva política de registre abans d’aplicar les actualitzacions en directe posteriors. Les instantànies buides eliminen els filtres suprimits. Una actualització perduda per una cua plena tanca aquella subscripció perquè la reconnexió pugui obtenir la política actual.

Les versions antigues conserven el seu protocol d’actualització existent. Un Hunter actualitzat tracta les actualitzacions ADD antigues com a substitucions, però un processador antic no pot comunicar eliminacions durant buits de registre com a instantània autoritativa. Actualitzeu tots dos extrems per obtenir les garanties de la versió RADIUS distribuïda; les versions antigues sense capacitat RADIUS no poden rebre filtres RADIUS. Els paquets bruts antics continuen disponibles per a les sortides ordinàries i no poden autoritzar X2 sense proves actuals validades.

L’associació de peticions continua sent local a un Hunter, una interfície i una època de captura. Recrear l’estat de captura/transmissió inicia una època nova, mentre les observacions ja en cua conserven el seu àmbit original. Una petició perduda en el transport encara pot tenir una resposta autoritzada a partir de proves úniques del costat de captura, subjecta a l’admissió actual de tasques del processador; una petició mai observada en la captura no pot fer-ho.

Captura ordinària

Descodifiqueu una gravació fora de línia; no cal cap compilació LI ni tasca:

lc sniff radius -r radius.pcap --format text

Observeu un User-Name complet exacte, inclosos el realm i les majúscules/minúscules:

sudo lc sniff radius -i mirror0 --radius-username 'alice@example.test'

Captureu ports addicionals de servei i escriviu el flux opcional d’observació:

sudo lc tap radius -i mirror0 --insecure --radius-port 1645,1646 \
  --log-dir ./logs --log-streams radius

Utilitzeu captura distribuïda ordinària; X2 requereix addicionalment un origen autenticat:

sudo lc hunt radius -i mirror0 --processor processor.example:55555 \
  --tls-ca ca.crt --radius-username 'alice@example.test'

Els predicats ordinaris són conjuntius: tots els criteris de nom d’usuari, MAC, AVP i línia resolta proporcionats han de coincidir amb el mateix missatge completament validat, o el predicat complet de petició ha de continuar vigent per a una resposta associada de manera única. Aquesta conjunció pertany a la política del comandament ordinari. A Tap i Hunt, grups dinàmics de filtres/tasques configurats independentment també poden seleccionar trànsit; la selecció és la unió de grups complets coincidents. Per tant, un grup dinàmic pot transmetre trànsit fora del predicat del comandament ordinari. Els grups no combinen mai criteris parcials i les coincidències ordinàries no autoritzen LI.

Paquets diferents no aporten mai criteris parcials. Els atributs repetits poden satisfer criteris separats sense concatenació. La coincidència del nom d’usuari és exacta sobre bytes UTF-8 i distingeix majúscules/minúscules: sense retallar, comodins, eliminació de realm ni normalització Unicode. Els objectius de text requereixen entre 1 i 253 bytes UTF-8.

Per a sniff radius, els logs estructurats s’executen després de la selecció ordinària i comparteixen la mateixa observació, àmbit i associació de captura que les sortides CLI/de paquets. Les coincidències ordinàries rebutjades no generen registres estructurats; les peticions competidores encara arriben al correlacionador abans de la selecció i la validació només es compta una vegada.

L’escriptura PCAP, la transmissió ascendent, els subscriptors Watch, la sortida d’interfície virtual, els logs estructurats i el lliurament LI mantenen activació i cues pròpies. Activar X2 no activa fitxers de paquets ni logs; activar --log-dir no autoritza LI. RADIUS no utilitza fitxers VoIP per trucada. El text, JSON i logs habituals oculten credencials, autenticadors i atributs no autoritzats; les sortides PCAP i X2 explícites conserven els bytes originals validats segons els seus contractes de sortida.

Opcions i configuració compartides

Els tres comandaments de protocol utilitzen les mateixes claus YAML radius.*. Els noms d’entorn són LIPPYCAT_RADIUS_ seguit de la clau en majúscules. Les opcions prevalen sobre l’entorn, l’entorn sobre YAML i YAML sobre els valors per defecte. Per exemple, --radius-transaction-timeout 20s, radius.transaction_timeout: 20s i LIPPYCAT_RADIUS_TRANSACTION_TIMEOUT=20s seleccionen el mateix paràmetre.

Els intervals invàlids i les combinacions incompatibles de perfil/objectiu fan fallar la configuració; els límits no s’ajusten silenciosament. Les retransmissions no allarguen el cicle de vida de la petició. Les pèrdues de capacitat conserven proteccions de silenci; si l’estat de protecció necessari no hi cap, l’herència s’atura globalment fins que transcorri tot un període de silenci. La coincidència directa i les sortides seleccionades independentment continuen disponibles.

radius:
  ports: [1645, 1646]
  protocol_scope: auth-accounting-udp
  username: alice@example.test
  mac_profile: calling-station-id-uppercase-hyphen-v1
  mac: 02-00-00-00-00-01
  line_profile: nas-port-id
  line_id: line-a
  operator_scope: operator-a/nas-a
  profile_revision: v1
  transaction_timeout: 30s
  quiet_guard: 30s
  max_candidates: 65536
  max_per_key: 4
  candidate_bytes: 67108864
  total_bytes: 100663296

NatParas, assignacions de línies i objectius X1

Els valors administratius NatParas s’han de resoldre abans de configurar X1. lippycat no consulta l’inventari d’abonats ni infereix relacions entre comptes i línies.

nas-port-id i agent-circuit-id seleccionen atributs concrets alternatius; no són un OR automàtic. --radius-line-id line-a amb nas-port-id crea el predicat complet de tipus 87 dins de l’àmbit/revisió proporcionat explícitament. L’inventari ascendent ha de proporcionar un valor concret i la seva frontera d’unicitat. El mateix line-a pot existir en dos operadors, de manera que no es pot tractar com a globalment únic. L’activació en producció requereix registres de l’operador per al NAS emissor, bytes exactes del valor, convenció MAC i àmbit, verificats amb una captura no sensible d’una línia coneguda. Les dades de prova operator-a/operator-b del repositori reutilitzen intencionadament valors de línia i no estableixen un acord d’assignació en producció.

Els AVP complets inclouen octets de tipus i longitud. Hex accepta majúscules o minúscules amb només espais XML inicials/finals i serialitza en majúscules. Els objectius User-Name i NAS-Port-Id contenen 1–253 bytes de valor. Els objectius Agent-Circuit-Id contenen 1–63 bytes i exactament un subatribut de fabricant; l’ID de fabricant és 00000DE9. Rebutgeu longituds incorrectes, espais interns, 0x, separadors, valors buits, AVP concatenats, subatributs VSA addicionals d’objectiu, altres fabricants/tipus, perfils de línia no resolts i absència d’àmbit. Els atributs vàlids repetits/agrupats capturats continuen permetent coincidències independents; la codificació d’objectius no reescriu els bytes dels paquets.

La interpretació de MAC de captura utilitza només l’atribut 31, Calling-Station-Id, amb la convenció explícita de majúscules i guions. Els valors capturats amb minúscules, dos punts, punts, sufixos o farciment no produeixen cap identitat MAC. Les adreces Ethernet i NAS no són mai alternatives de MAC d’abonat. La NAI X1 no coincideix amb SIP; SIP necessita sipUri. Tots els criteris de tasca es combinen amb AND dins d’una mateixa tasca i àmbit; els criteris mixtos RADIUS/SIP/IP, OR/negats i els criteris d’àmbit NAS no admesos es rebutgen en conjunt.

Vegeu el contracte d’identitat per a les regles binàries exactes i la guia de desplegament LI per al comportament d’activació, modificació, reinici i admissió de la generació actual.

Configuració de POI Tap i MDF

Compileu amb make tap-li o make build-li per obtenir opcions X1/X2. Els comandaments RADIUS ordinaris continuen disponibles en compilacions sense LI. Configureu un àmbit de captura dedicat, TLS mutu per a X1 i el lliurament MDF, un ProcessorID únic estable i estat LI durable abans de crear una tasca X2Only i una destinació explícitament habilitada per a X2. L’extrem MDF es configura mitjançant l’administració de destinacions X1; no és un objectiu de captura ordinari.

Les vinculacions exclusives de LI són compartides per tap i process:

Aquestes claus utilitzen variables d’entorn LIPPYCAT_LI_RADIUS_*, com ara LIPPYCAT_LI_RADIUS_OPERATOR_SCOPE. Els paràmetres de captura radius.operator_scope i radius.profile_revision han de coincidir amb la vinculació explícita del desplegament LI. Configureu el perfil MAC LI per als objectius MAC X1; el perfil ordinari no activa LI implícitament. El directori pare de l’estat durable ha d’existir prèviament. Provisioneu claus independents de filtres i estat administratiu i després inicialitzeu o migreu totes dues instantànies xifrades abans d’iniciar el node; vegeu la configuració d’emmagatzematge LI. La inicialització administrativa fixa el seu camí més .radius-correlation; la migració conserva el camí original de l’assignador. Un camí personalitzat d’assignador en execució ha de coincidir amb aquesta fixació. Moure la instantània administrativa no restableix ni mou l’assignador separat sense xifrar. --li-radius-transaction-timeout ha de ser igual a --radius-transaction-timeout a tap radius; els desplegaments de processador han de configurar el mateix cicle de vida que el desplegament de captura Hunter. Una diferència en Tap local rebutja l’inici.

sudo lc tap radius -i mirror0 --id poi-a \
  --tls-cert server.crt --tls-key server.key --tls-ca capture-ca.crt \
  --radius-operator-scope operator-a/nas-a --radius-profile-revision v1 \
  --li-enabled --filter-file /var/lib/lippycat/poi-a-filters.enc \
  --filter-store-key-id filters-1 --filter-store-key-file /etc/lippycat/filters.key \
  --li-state-file /var/lib/lippycat/poi-a-li.enc \
  --li-state-key-id state-1 --li-state-key-file /etc/lippycat/li-state.key \
  --li-radius-operator-scope operator-a/nas-a --li-radius-profile-revision v1 \
  --li-radius-origin-node poi-a-local --li-radius-source mirror0 \
  --li-radius-mac-profile calling-station-id-uppercase-hyphen-v1 \
  --li-x1-listen :8443 \
  --li-x1-tls-cert x1.crt --li-x1-tls-key x1.key --li-x1-tls-ca admf-ca.crt \
  --li-delivery-tls-cert delivery.crt --li-delivery-tls-key delivery.key \
  --li-delivery-tls-ca mdf-ca.crt

L’origen de captura del Tap local és l’ID de processador més -local, de manera que aquest exemple vincula l’origen poi-a-local. La identitat X2 NFID/IPID continua sent poi-a.

Això inicia el POI configurat; configureu l’objectiu per àmbit i la destinació X2 mitjançant X1 abans que es pugui fer el lliurament. Les opcions existents --log-dir, PCAP i interfície virtual es poden activar independentment. Les peticions RADIUS X3 i combinades X2/X3 es rebutgen. El mapa de correlació continua limitat a 65.536 entrades i 16 MiB; una fallada d’assignació rebutja X2 en lloc de generar ID incoherents.

Les dades útils X2 en brut utilitzen el format 11 i exactament el missatge RADIUS declarat, sense Ethernet/IP/UDP ni farciment final. Payload Direction és Unknown. El Correlation ID de vuit bytes no zero representa un intercanvi observat, no una sessió d’abonat ni l’Identifier RADIUS. Les retransmissions i les respostes associades de manera única el reutilitzen dins del cicle de vida conservat de la petició; les coincidències directes òrfenes reben ID per observació. Es pot lliurar cada datagrama coincident capturat, inclosos duplicats d’emmirallament. No es garanteix un lliurament durable exactament una vegada.

L’acord amb el MDF receptor ha d’incloure el format 11, la direcció Unknown, el cicle de vida de l’intercanvi, la correlació de vuit bytes, els duplicats i el tractament d’orfes. Les proves sintètiques de receptor són proves locals; la interoperabilitat externa i l’acceptació de l’operador continuen pendents. Utilitzeu ProcessorID separats per a codificadors independents, conserveu l’emmagatzematge de correlació en reiniciar i canvieu la identitat si es restableix l’emmagatzematge. Les fallades d’emmagatzematge/codificació suprimeixen X2 mentre les sortides ordinàries continuen. Vegeu lliurament X2 RADIUS en brut per a la propietat de l’estat i el contracte d’observació per a l’associació.

Comptadors operatius

Els missatges INFO estructurats exposen instantànies limitades de comptadors. RADIUS capture counters pertany al runtime de captura per època; s’emet amb el primer trànsit, aproximadament cada minut mentre continua el trànsit i en aturar-se o en una frontera d’època. La revalidació posterior de bytes no incrementa els comptadors d’origen.

RADIUS X2 counters pertany al processador autoritatiu durant el seu cicle de vida. stale_generations compta fallades de permisos temporals de generació de callbacks; allocation_errors i encoding_errors compten intents fallits d’assignació/codificació. encoded compta PDU codificades; queue_accepted i queue_errors compten resultats d’enviament a la cua X2; skipped compta productes no enviats. L’acceptació en cua no prova el lliurament TLS. Les estadístiques compartides de lliurament LI comptabilitzen el lliurament a destinacions i els intents de reintent i fallada entre protocols; no les interpreteu com a totals de paquets només RADIUS ni les sumeu amb observacions de captura. El gestor LI informa separadament de radius_stale_references a les seves estadístiques d’aturada, comptant referències de propietaris de tasques rebutjades en l’admissió. Vegeu supervisió del lliurament LI per a les estadístiques de lliurament existents.

Un comptador creixent de missatges malformats significa que les entrades intentades no han superat la validació estructural; les respostes ambigües/caducades/suprimides per capacitat no tenen propietari heretat. L’esgotament d’estat creixent indica associació incompleta malgrat la continuïtat de la coincidència directa. S’espera que el rebuig de referències obsoletes després de canvis de tasca elimini assignacions obsoletes. Els descarts de les cues de sortida mesuren la pèrdua de la destinació independentment de la salut de la descodificació i l’associació. Els comptadors no exposen ID de compte, línia o tasca com a etiquetes.

Registres estructurats de protocols

lippycat pot escriure metadades normalitzades de protocols al costat de les sortides de paquets, PCAP, TUI, interfície virtual i LI. Els fitxers utilitzen noms de flux i semàntica de camps familiars de Zeek, però no substitueixen el seu ecosistema d’analitzadors i scripts. En particular, una captura filtrada o iniciada tard produeix observacions útils de límit inferior en lloc de mesuraments complets de connexió.

Activació dels registres

El registre està desactivat per defecte. Proporcionar --log-dir l’activa per a process, tap i sniff; el directori es crea si cal.

Per a un processador terminal en un desplegament distribuït:

lc process --listen :55555 --log-dir /var/log/lippycat

Per a captura local amb JSONL i fluxos seleccionats:

sudo lc tap dns -i eth0 --insecure \
  --log-dir /var/log/lippycat --log-format json --log-streams conn,dns

Per a captura CLI fora de línia o en viu, amb la sortida estàndard de paquets sense canvis:

lc sniff http -r capture.pcap --log-dir ./logs --log-streams conn,http,files

Les opcions compartides són:

Les claus YAML equivalents són events.queue_size, events.drop_policy, logs.dir, logs.format, logs.streams, logs.rotate_interval, logs.queue_size, logs.emit_stage, logs.post_rotate_command, logs.include_http_headers, logs.include_email_body_preview, i files.extract, files.extract_dir, files.max_size i files.total_size.

events:
  queue_size: 20000
  drop_policy: drop_new
logs:
  dir: /var/log/lippycat
  format: tsv
  streams: [conn, dns, ssl, http, smtp, files, radius]
  rotate_interval: 1h
  queue_size: 10000
  emit_stage: terminal
  post_rotate_command: "gzip %log%"
  include_http_headers: false
  include_email_body_preview: false
files:
  extract: false
  extract_dir: /var/lib/lippycat/files
  max_size: 10485760
  total_size: 104857600

En una jerarquia de processadors, terminal evita fitxers duplicats escrivint només en un node que no reenvia cap amunt. Utilitzeu all deliberadament per registrar en cada etapa activada, o none per suprimir la sortida de fitxers.

Codificacions de sortida

TSV és el valor per defecte. Escriu capçaleres Zeek (#separator, #set_separator, #empty_field, #unset_field, #path, #open, #fields i #types) i un peu #close. Els temps són segons Unix amb sis decimals, els intervals són segons, els booleans són T/F, i els vectors/conjunts se separen per comes. - significa sense establir, (empty) significa present però buit, i els bytes de control s’escapen com \xHH.

JSON és JSON Lines: un objecte per fila. Utilitza els mateixos noms de camp, incloent-hi claus com id.orig_h; els booleans, números i matrius tenen tipus JSON natius. Els valors sense establir són null, mentre que els valors presents buits són "" o []. Els fitxers JSON continuen utilitzant noms compatibles amb Zeek com dns.log.

Fluxos i camps

Tot l’ordre i els tipus de camps següents estan fixats per internal/pkg/logschema. uid és un identificador de connexió d’estil Zeek generat per lippycat. community_id és Community ID v1 per a unions entre eines, i node_id identifica la font de captura original, no necessàriament el processador que escriu el fitxer. Els valors no disponibles queden sense establir.

conn.log

Un resum de cicle de vida per flux observat (caducitat, expulsió o aturada ordenada).

L’orientació d’iniciador/responent segueix el SYN TCP quan és visible i, si no, el primer paquet observat. Els valors de bytes i paquets són recomptes observats. service és el protocol d’aplicació detectat; conn_state i history resumeixen el comportament TCP visible; els booleans d’adreça local poden quedar sense establir quan es desconeix la localitat.

capture_scope=full significa que la font pretenia observar tot el flux de la interfície. filtered significa que un filtre BPF, de protocol, d’objectiu o distribuït ha restringit la captura. Això no demostra una transmissió sense pèrdues. partial=true significa que la connexió va començar abans de l’observació, no es va veure un SYN TCP, només es va veure una direcció, se sap que es van descartar paquets o el còmput és incomplet d’una altra manera. Tracteu tots els comptadors i la durada de les files parcials com límits inferiors. Un àmbit full encara pot ser parcial.

dns.log

Una observació de transacció DNS. trans_id és l’identificador de transacció DNS; rtt és el temps de resposta correlacionat. La classe/tipus de consulta i el codi de resposta apareixen com valors numèrics i descriptius. AA, TC, RD, RA i Z són indicadors de la capçalera DNS; answers i TTLs són vectors de resposta; rejected marca una transacció rebutjada.

ssl.log

Una observació de negociació TLS. Inclou version, cipher, curve negociats, SNI server_name, estat de represa/alerta/ALPN, estat d’establiment, identificadors i identitats dels fitxers de certificat, resultat de validació i empremtes JA3/JA3S/JA4. Les empremtes són extensions habituals de lippycat, no camps bàsics de Zeek.

http.log

Una observació de transacció HTTP. trans_depth ordena les transaccions d’una connexió. Les columnes de petició/resposta descriuen mètode, autoritat i URI, capçaleres estàndard seleccionades, versió, longituds observades del cos, estat de resposta i resposta informativa. tags i proxied contenen anotacions de l’analitzador/proxy; els vectors de fitxers s’uneixen a files.log. password no es recull per defecte.

smtp.log

Una observació de transacció SMTP. Registra la profunditat de transacció, HELO i remitent/destinataris del sobre, capçaleres de missatge seleccionades i salts d’encaminament, última resposta del servidor, estat TLS, identificadors de fitxers adjunts i classificació de correu web. No registra el cos del missatge.

files.log

Una observació limitada d’entitat HTTP o adjunt SMTP. fuid és l’identificador del fitxer; source indica el protocol que el transporta; depth i parent_fuid descriuen la imbricació; analyzers descriu el processament. Les columnes de mida i pèrdua indiquen bytes observats, declarats, absents i de desbordament. Els hashes cobreixen els bytes recuperats; hash_complete només és cert quan se sap que aquests bytes representen tota l’entitat descodificada. Un valor fals significa que els hashes identifiquen un prefix observat i no s’han de comparar com hashes de fitxers sencers. extracted només s’estableix quan l’extracció explícita té èxit.

Rotació i operacions

Transport remot d’esdeveniments i retenció TUI

Els nodes Hunter i Tap poden reenviar registres normalitzats amb --forward-mode=events. El receptor obté esdeveniments, no els paquets originals: no estan disponibles l’escriptura PCAP superior, la injecció en interfícies virtuals ni l’anàlisi que necessita bytes de paquets. Un node Tap pot retenir PCAP local mentre reenvia esdeveniments quan calen totes dues coses.

El transport d’esdeveniments negocia compatibilitat d’API i semàntica. El reenviament de paquets és el valor per defecte compatible amb versions antigues; --event-fallback-to-packets permet un recurs explícit i registrat. El mode fiable utilitza spool limitat del productor i WAL d’entrada del processador, mentre que el mode només en memòria no resisteix caigudes.

La versió 1 de la subscripció d’esdeveniments TUI és només en viu i no ofereix reproducció. El recompte de pèrdua de transport representa buits o omissions abans de la visualització. El recompte separat d’expulsió local representa esdeveniments rebuts que han sortit de l’anell TUI limitat per antiguitat i no indica pèrdua de transport.

Cada flux activat té una cua limitada no bloquejant i un únic escriptor. Una cua d’esdeveniments o de flux plena descarta treball nou i incrementa comptadors; els avisos periòdics resumeixen els descarts. El control de flux del processador considera la pressió sostinguda de les cues d’esdeveniments i registres, incloent-hi cada cua de sortida del distribuïdor, però cap configuració de registre pot garantir sortida sense pèrdues. events.drop_policy accepta actualment drop_new; les polítiques no admeses fallen durant la inicialització.

L’anàlisi de fitxers HTTP i SMTP requereix bytes del cos a l’analitzador de captura. En un desplegament distribuït, inicieu l’ordre de protocol pertinent del node Hunter amb --capture-body i un --max-body-size adequat; el processador no pot recuperar posteriorment cossos que el node Hunter ha omès. L’anàlisi MIME SMTP també està condicionada per privadesa amb --log-include-email-body-preview. Les capçaleres HTTP i les previsualitzacions del cos del correu continuen desactivades llevat que s’estableixin les opcions d’activació respectives.

Els fitxers actius s’anomenen conn.log, dns.log, etc. A l’interval configurat, es tanca i reanomena un fitxer actiu, per exemple a conn-2026-08-22-14-30-00.log, i després s’obre un fitxer actiu nou en el registre següent. L’aturada ordenada amb SIGINT/SIGTERM buida les cues, escriu els registres pendents i els peus TSV. SIGKILL, una caiguda o un sistema de fitxers ple no ho poden fer.

L’ordre posterior a la rotació s’executa de manera asíncrona mitjançant /bin/sh; cada marcador %log% se substitueix per un camí amb cometes per a l’intèrpret d’ordres. Per exemple:

lc process --log-dir /var/log/lippycat \
  --log-post-rotate-command 'gzip %log%'

L’ordre té exactament els mateixos privilegis que el procés lippycat. Utilitzeu una ordre fixa controlada per l’administrador, eviteu secrets als arguments i superviseu els registres d’error de les accions. La retenció i la gestió de l’espai de disc continuen sent responsabilitat de l’operador.

Exemples d’entrada a SIEM

Per a JSONL, apunteu un agent a /var/log/lippycat/*.log, analitzeu un objecte JSON per línia i utilitzeu el nom del fitxer com conjunt de dades. Exemple de font/transformació Vector:

[sources.lippycat]
type = "file"
include = ["/var/log/lippycat/*.log"]
read_from = "beginning"

[transforms.lippycat_json]
type = "remap"
inputs = ["lippycat"]
source = '''
. = parse_json!(.message)
'''

Per a TSV, utilitzeu una entrada/analitzador que entengui les capçaleres Zeek i els fitxers rotats. El mòdul Zeek de Filebeat o una cadena Vector/Fluent Bit compatible amb Zeek són adequats; no tracteu les línies de capçalera com dades. Preserveu uid, community_id i node_id com cadenes exactes. Com que uid és local a un cicle de vida de flux observat, community_id és la clau preferida d’unió entre productes; incloeu el temps i node_id en resoldre col·lisions o connexions repetides.

Privadesa i seguretat

Els registres estructurats poden contenir dades personals: adreces IP, noms DNS, SNI, URL, adreces i assumptes de correu, agents d’usuari, noms de fitxer, identitats de certificat i identificadors estables de flux. Les cadenes de consulta i els camins poden contenir credencials o tokens. Restringiu els permisos del directori, xifreu l’emmagatzematge i el transport, definiu una política de retenció i recolliu només els fluxos justificats per la finalitat del monitoratge.

Els valors per defecte conservadors mantenen el registre i l’extracció desactivats, ometen capçaleres HTTP arbitràries, limiten tota l’anàlisi/extracció de fitxers i mai no posen càrregues útils de paquets, cossos HTTP/correu, RTP/contingut multimèdia ni bytes extrets a les files de registre de metadades. Activar l’extracció de fitxers crea fitxers de contingut separats i requereix controls d’accés proporcionalment més estrictes. Les opcions de fitxers estructurats no autoritzen el lliurament LI; les metadades LI continuen condicionades independentment per compilació, execució, tasca activa, objectiu i perfil de lliurament.

Observacions RADIUS

lc sniff radius -r radius.pcap --log-dir ./logs --log-streams radius selecciona el flux addicional d’observacions RADIUS de versió 1. Cada missatge vàlid seleccionat té el seu propi registre; els atributs utilitzen instàncies hexadecimals ordenades incloses en una llista permesa. La subordre específica sniff radius aplica la selecció ordinària abans d’escriure registres i comparteix la mateixa observació/àmbit amb les sortides CLI i de paquets, sense recomptes duplicats de validació. Les credencials, els autenticadors, les proves de tasca i els atributs desconeguts s’ometen dels registres habituals. PCAP i X2 mantenen els seus contractes separats de sortida de bytes. Consulteu Operacions RADIUS per veure selecció, àmbit, estat i comptadors.

DHCP, NTP i inventaris locals

La selecció per defecte continua sent conn,dns,ssl,http,smtp,files,radius. Quatre fluxos addicionals són opcionals: dhcp, ntp, known_hosts i known_services. Seleccioneu-los amb --log-streams; no calen subordres de protocol noves. Les observacions DHCP/NTP tipades també estan disponibles per als subscriptors d’esdeveniments i la TUI quan el registre de fitxers està desactivat.

lc sniff -r network.pcap --log-dir ./logs --log-streams dhcp,ntp
sudo lc tap -i eth0 --insecure --inventory \
  --inventory-local-cidrs 192.0.2.0/24,2001:db8::/32 \
  --log-dir ./logs --log-streams dhcp,ntp,known_hosts,known_services

Registres de missatge i associació

DHCP i NTP escriuen un registre per missatge acceptat, incloent-hi retransmissions del protocol. A diferència de l’agregació de transaccions/sessions de Zeek, una resposta afegeix un registre nou i mai no reescriu ni consumeix una petició. El sobre conserva els extrems UDP observats, l’UID del flux, Community ID, l’àmbit de captura i la font. Els identificadors d’associació proporcionen un context d’intercanvi separat i limitat; els reintents de transport conserven la identitat original de transmissió i es dedupliquen a l’entrada.

DHCP cobreix els tipus de missatge DHCPv4 1–8, incloent-hi decline, release i inform. DHCPv6 i BOOTP pur s’exclouen d’aquest registre; la detecció BOOTP continua disponible. Els registres mantenen separades les adreces next-server i server-identifier. Els identificadors de maquinari/client utilitzen sortida hexadecimal, sense assumir mai que són text imprimible. Les opcions absents queden sense establir; una concessió present de valor zero continua sent zero. Les opcions repetides i les àrees d’opcions sobrecarregades es validen dins de lectors limitats. Els missatges malformats acceptats mostren partial i, per a entrada incompleta, truncated; no es registren bytes d’opcions desconegudes o de fabricant.

L’associació DHCP separa autoritat/època/font de captura, identitat de client, identificador de transacció, context de retransmissor i distincions de servidor. Mai no uneix clients utilitzant només l’identificador de transacció ni fabrica un únic UID de flux entre difusions i canvis d’adreça. La caducitat o expulsió de l’associació no suprimeix el missatge actual. No es promet un historial complet de concessions.

NTP cobreix els modes de missatge de temps 1–5. S’exclouen modes de control/privats, anàlisi NTS, autenticació, conclusions de qualitat del rellotge i càlculs de desplaçament del rellotge del client. Els valors de poll/precision i retard arrel amb signe conserven el signe; la dispersió arrel i les marques de temps 32.32 en brut conserven els valors exactes de la xarxa. Les marques de temps en brut són cadenes hexadecimals. Les marques zero no estan disponibles; les conversions no zero utilitzen l’era més pròxima al temps de captura. Els identificadors de referència continuen sent quatre bytes en brut perquè la interpretació depèn de la versió i l’estrat.

L’associació client/servidor NTP requereix àmbits coincidents, extrems invertits i la marca de temps de petició retornada. Les marques de temps duplicades són ambigües. Els missatges sense coincidència, de difusió i simètrics continuen generant registres. Tots dos protocols utilitzen els estats d’associació request, unique, missing, ambiguous, expired, capacity_suppressed i not_applicable; aquests estats mai no afirmen autenticació.

Proves i política d’inventari

Els esdeveniments d’inventari estan activats per defecte per a tots els amfitrions i serveis unicast observats que compleixin els requisits. Desactiveu-los amb --inventory=false, o restringiu opcionalment els subjectes amb IPv4/IPv6 --inventory-local-cidrs. Els CIDR no restringeixen la captura de paquets. Només els CIDR configurats explícitament classifiquen els extrems de connexió com locals; una llista buida no marca totes les adreces observades com locals, i l’espai privat no és implícitament local. S’exclouen subjectes no especificats, multicast i de difusió. Els fluxos de registre d’inventari continuen sent opcionals i requereixen una política local compatible o fonts d’esdeveniments compatibles que produeixin inventari. Configureu els nodes Hunter pel seu camí normal de configuració; els processadors no els distribueixen aquesta política.

L’activació de l’inventari és una política d’anàlisi, no una petició de sortida. sniff sense consumidors no crea cap entorn opcional d’esdeveniments; els registres estructurats, una sortida explícita d’esdeveniments o l’extracció de fitxers sol·licitada l’activen. La descodificació ordinària de protocols, la selecció i la sortida de paquets continuen disponibles sense aquest entorn. Les altres topologies conserven els seus propis consumidors d’esdeveniments i cicle de vida. L’equivalent YAML de --inventory=false és events.inventory.enabled: false. Els CIDR delimiten els subjectes d’inventari, no la captura de paquets ni el cost de l’anàlisi de connexions i protocols.

Els amfitrions coneguts requereixen una negociació TCP completa observada o totes dues direccions UDP. Els serveis coneguts requereixen addicionalment un responent orientat de manera fiable, el seu port i un protocol sustentat per anàlisi real. Un SYN aïllat, una adreça de destinació, una oferta DHCP, una pista de port o una etiqueta de protocol en cau són insuficients. Els registres de servei UDP requereixen un intercanvi DNS, NTP o DHCP admissible descodificat i associat correctament. S’ometen responents ambigus i conjectures de servei de client de difusió/retransmissor. Els valors de prova són tcp_handshake, udp_bidirectional, dns_exchange, ntp_exchange i dhcp_exchange.

Els esdeveniments d’inventari s’emeten tan aviat com estan disponibles les proves de paquets necessàries, sense esperar la caducitat de la connexió. Els resums ordinaris de connexió conserven el comportament existent de caducitat, expulsió, EOF, reinicialització o tancament. En mode remot de paquets, la TUI deriva localment esdeveniments d’inventari dels paquets rebuts; utilitzeu la vista All i filtreu per known per trobar-los. La connexió que compleix els requisits proporciona el sobre; el camp separat host és el subjecte. La captura parcial continua visible. L’entrada d’esdeveniments i els retransmissors jeràrquics reenvien els esdeveniments d’inventari derivats a la font sense derivar-ne una segona còpia.

La deduplicació d’amfitrions inclou àmbit i adreça; les claus de servei també inclouen port del responent, transport i protocol. L’àmbit separa nodes d’origen, èpoques de productor/captura i interfícies o entrades fora de línia. S’emet la primera observació que compleix els requisits dins de la finestra de retenció; la caducitat o expulsió permet una reemissió posterior. És un inventari limitat d’observacions, no una identitat permanent d’actius. Els límits d’entrades i bytes comptabilitzats s’apliquen globalment i per àmbit.

Les marques de progrés del temps de captura mai no retrocedeixen, incloent-hi la reproducció fora de línia; l’entrada tardana no pot reactivar estat caducat. La reinicialització esborra l’estat d’associació/deduplicació, i EOF/tancament buiden els resums de connexió. La identitat fora de línia inclou la política efectiva i la revisió d’anàlisi; els canvis de política en viu requereixen un límit de sessió del productor. Els CIDR invàlids i els límits d’estat o temps d’espera zero/negatius fallen la validació. L’inventari desactivat no reté estat d’inventari. La pressió d’associació, la pèrdua d’esdeveniments i l’expulsió de l’anell TUI tenen comptadors diferents. Consulteu les opcions compartides i les opcions d’ordres.

Privadesa i compatibilitat

Els identificadors DHCP de maquinari/client, el nom d’amfitrió i el domini requereixen tant una petició del subscriptor de camps sensibles com permís del servidor mitjançant --event-allow-sensitive-fields. Els detalls de subjecte/servei d’inventari utilitzen la mateixa política: s’ometen esdeveniments d’inventari no autoritzats amb còmput explícit de pèrdua per política. La projecció no modifica els esdeveniments compartits ni desactiva la correlació interna. Les metadades de capçalera NTP no requereixen cap activació addicional de camps sensibles. Els registres locals seleccionats explícitament inclouen aquests camps sensibles; restringiu l’accés als fitxers, l’emmagatzematge i la retenció.

Els quatre tipus amplien la versió 1 de l’API d’esdeveniments sense renumerar tipus existents ni canviar el perfil semàntic. Els tipus admesos són diferents dels requisits dels consumidors configurats. Els interlocutors antics poden continuar les càrregues existents quan els tipus nous són opcionals, amb informes explícits de pèrdua de compatibilitat per omissions. Els fluxos obligatoris no disponibles rebutgen la negociació o utilitzen un recurs a paquets configurat explícitament; mai no tenen èxit silenciosament amb sortida absent. Les regles existents de confirmació de spool/WAL i preservació de camps desconeguts continuen aplicant-se.

Intercepció legal

lippycat implementa interfícies d’intercepció legal (LI) segons els estàndards ETSI, que permeten interceptar comunicacions amb autorització quan es desplega dins d’una infraestructura d’intercepció legal. Aquest capítol tracta l’arquitectura, el desplegament i el funcionament de les capacitats LI per als operadors que necessiten integrar lippycat amb sistemes ADMF (Administration Function) i MDF (Mediation/Delivery Function).

Important. La intercepció legal està subjecta a requisits legals estrictes en totes les jurisdiccions. Desplegar capacitats LI sense l’autorització legal adequada és il·legal. Assegureu-vos que la vostra organització disposi del marc legal, els processos de supervisió i els controls d’auditoria necessaris abans d’activar funcions LI.

Visió general de les interfícies ETSI

lippycat implementa tres interfícies ETSI definides a TS 103 221-1 i TS 103 221-2:

La interfície X1 transporta comandaments administratius: l’ADMF envia peticions d’activació, modificació i desactivació de tasques al processador (que actua com a Network Element). La interfície X2 lliura Intercept Related Information (IRI), inclosos els esdeveniments de senyalització SIP. La interfície X3 lliura Content of Communication (CC): les dades útils reals dels mitjans, com l’àudio RTP.

Arquitectura

El diagrama següent mostra com interactuen l’ADMF, el processador lippycat i el MDF:

flowchart TB
    ADMF["ADMF<br/>(Administration)"]

    subgraph NE["lippycat Processor"]
        X1["X1 Server :8443"]
        LIM["LI Manager"]
        ENC["X2/X3 Encoder"]
        DC["Delivery Client"]
        X1 <--> LIM
        LIM --> ENC --> DC
    end

    subgraph Hunters["Hunter Nodes"]
        H1["Hunter 1"]
        H2["Hunter 2"]
    end

    MDF["MDF<br/>(Mediation/Delivery)"]

    ADMF <-->|"X1 (HTTPS/mTLS)"| X1
    LIM -->|"filters"| Hunters
    H1 -->|"matched packets"| LIM
    H2 -->|"matched packets"| LIM
    DC -->|"X2 IRI (TLS)"| MDF
    DC -->|"X3 CC (TLS)"| MDF

El flux funciona de la manera següent:

1. L’ADMF envia una tasca d’intercepció al processador mitjançant la interfície X1 (o el processador consulta les tasques existents a l’ADMF en iniciar-se: vegeu Sincronització de l’estat ADMF).
2. El gestor LI tradueix els identificadors d’objectiu de la tasca a filtres de captura i els transmet als Hunters connectats.
3. Els Hunters comparen els paquets amb aquells filtres a la vora de la xarxa i transmeten el trànsit coincident al processador.
4. El processador codifica la senyalització SIP coincident i les metadades de protocol activades i autoritzades com a PDU X2 IRI i els mitjans RTP com a PDU X3 CC.
5. El client de lliurament envia les PDU codificades als extrems MDF designats mitjançant TLS.

Requisits de compilació

El suport LI es controla amb l’etiqueta de compilació li. Les compilacions estàndard exclouen tot el codi LI mitjançant eliminació de codi mort: els binaris sense LI no contenen tipus, gestors ni vies de configuració LI.

Compileu el processador amb suport LI:

make processor-li

Compileu el conjunt complet amb suport LI:

make build-li

Compileu Tap amb suport LI per a captura independent i lliurament LI:

make tap-li

Verifiqueu que les compilacions sense LI no continguin codi LI:

make verify-no-li

Els Hunters no necessiten suport LI. Fan filtratge a la vora de la xarxa amb la mateixa infraestructura de filtres tant si els filtres provenen de tasques LI com de configuració manual. Només el processador (o Tap en mode independent) necessita l’etiqueta de compilació li perquè allotja el servidor X1 i el client de lliurament X2/X3.

Configuració i desplegament

Activació de LI

LI s’activa amb l’opció --li-enabled al processador o Tap. L’adreça d’escolta X1, el certificat del servidor, la clau del servidor i la CA de client ADMF són obligatoris; una configuració TLS X1 incompleta fa fallar l’inici. També calen certificats de lliurament per a la comunicació MDF.

Inicialitzeu o migreu un magatzem xifrat de filtres gestionats abans d’activar LI. La persistència administrativa, quan està configurada, també requereix una instantània xifrada inicialitzada amb la seva pròpia clau independent de 32 bytes en brut. L’estat en text pla no es carrega mai en execució. Seguiu la guia de configuració i migració d’emmagatzematge amb el node aturat. L’exemple següent pressuposa que aquestes instantànies ja existeixen. --li-state-file buit desactiva la persistència administrativa quan la reproducció no la requereix.

lc process --listen :55555 \
  --tls-cert server.crt --tls-key server.key \
  --li-enabled \
  --filter-file /var/lib/lippycat/filters.enc \
  --filter-store-key-id filters-1 --filter-store-key-file /etc/lippycat/keys/filters.key \
  --li-state-file /var/lib/lippycat/li-state.enc \
  --li-state-key-id state-1 --li-state-key-file /etc/lippycat/keys/li-state.key \
  --li-x1-listen :8443 \
  --li-x1-tls-cert /etc/lippycat/li/x1-server.crt \
  --li-x1-tls-key /etc/lippycat/li/x1-server.key \
  --li-x1-tls-ca /etc/lippycat/li/admf-ca.crt \
  --li-admf-endpoint https://admf.example.com:8443 \
  --li-admf-tls-cert /etc/lippycat/li/x1-client.crt \
  --li-admf-tls-key /etc/lippycat/li/x1-client.key \
  --li-admf-tls-ca /etc/lippycat/li/admf-ca.crt \
  --li-delivery-tls-cert /etc/lippycat/li/delivery.crt \
  --li-delivery-tls-key /etc/lippycat/li/delivery.key \
  --li-delivery-tls-ca /etc/lippycat/li/mdf-ca.crt

La mateixa configuració es pot expressar en YAML. Aquest és l’enfocament recomanat per a desplegaments de producció:

# /etc/lippycat/config.yaml
processor:
  listen_addr: ":55555"
  tls:
    enabled: true
    cert_file: "/etc/lippycat/certs/server.crt"
    key_file: "/etc/lippycat/certs/server.key"

  filter_file: "/var/lib/lippycat/filters.enc"
  filter_store:
    mode: auto
    key_id: "filters-1"
    key_file: "/etc/lippycat/keys/filters.key"

  li:
    enabled: true
    state_file: "/var/lib/lippycat/li-state.enc"
    state_key_id: "state-1"
    state_key_file: "/etc/lippycat/keys/li-state.key"

    # X1 server — receives task requests from ADMF
    x1_listen_addr: ":8443"
    x1_tls_cert: "/etc/lippycat/li/x1-server.crt"
    x1_tls_key: "/etc/lippycat/li/x1-server.key"
    x1_tls_ca: "/etc/lippycat/li/admf-ca.crt"

    # X1 client — sends notifications to ADMF and queries state
    admf_endpoint: "https://admf.example.com:8443"
    admf_tls_cert: "/etc/lippycat/li/x1-client.crt"
    admf_tls_key: "/etc/lippycat/li/x1-client.key"
    admf_tls_ca: "/etc/lippycat/li/admf-ca.crt"
    admf_keepalive: "30s"

    # ADMF state synchronization
    admf_sync_on_startup: true # Query ADMF for state on startup
    admf_sync_timeout: "30s" # Timeout for startup sync
    admf_reconcile_interval: "5m" # Periodic reconciliation (0 = disabled)

    # X2/X3 delivery — sends intercept data to MDF
    delivery_tls_cert: "/etc/lippycat/li/delivery.crt"
    delivery_tls_key: "/etc/lippycat/li/delivery.key"
    delivery_tls_ca: "/etc/lippycat/li/mdf-ca.crt"
    delivery_tls_pinned_cert:
      - "sha256:A1B2C3D4E5F6..." # Optional: pin MDF certificates

Configuració de certificats LI

Les interfícies LI requereixen TLS mutu (mTLS) en totes les connexions. Això significa que el processador ha de presentar un certificat de client en connectar-se a l’ADMF i el MDF i ha de verificar els certificats presentats per aquells sistemes. Hi intervenen tres cadenes de certificats separades:

flowchart TB
    subgraph chains["Certificate Chains"]
        direction TB

        subgraph admf_chain["ADMF Chain"]
            ADMF_CA["ADMF CA"]
            ADMF_Cert["ADMF Client Cert"]
            ADMF_CA --> ADMF_Cert
        end

        subgraph li_chain["LI CA Chain (your organization)"]
            LI_CA["LI CA"]
            X1Srv["X1 Server Cert<br/>(processor)"]
            X1Cli["X1 Client Cert<br/>(notifications → ADMF)"]
            Deliv["Delivery Cert<br/>(X2/X3 → MDF)"]
            LI_CA --> X1Srv
            LI_CA --> X1Cli
            LI_CA --> Deliv
        end

        subgraph mdf_chain["MDF Chain"]
            MDF_CA["MDF CA"]
            MDF_Cert["MDF Server Cert"]
            MDF_CA --> MDF_Cert
        end
    end

Els certificats necessaris al costat del processador són:

Tots els certificats han d’utilitzar claus RSA 2048+ o ECDSA P-256+ amb hash SHA-256 o més fort. El servidor X1 requereix TLS 1.3 i una CA de client ADMF de confiança; no s’inicia si falta l’adreça d’escolta, el certificat, la clau o la CA de client. Les interfícies sortints X1 i X2/X3 requereixen TLS 1.2 o posterior.

Per als conceptes generals TLS i la generació de certificats, consulteu el Capítol 13: seguretat. La diferència principal per a LI és mantenir cadenes CA separades per a l’ADMF, els certificats LI de la vostra organització i el MDF: habitualment els operen entitats diferents.

Permisos de fitxer. Només el propietari del procés ha de poder llegir les claus privades:

chmod 600 /etc/lippycat/li/*.key

chmod 644 /etc/lippycat/li/*.crt

chmod 700 /etc/lippycat/li/

chown root:root /etc/lippycat/li/*

Fixació de certificats. Per a més garanties en la via de lliurament X2/X3, podeu fixar el certificat del servidor MDF mitjançant la seva empremta SHA-256:

Obteniu l’empremta:

openssl x509 -in mdf-server.crt -noout -fingerprint -sha256 | \
  sed 's/://g' | cut -d= -f2

Configureu la fixació amb l’empremta obtinguda:

--li-delivery-tls-pinned-cert sha256:A1B2C3D4E5F6...

Quan la fixació està configurada, el client de lliurament rebutja qualsevol certificat MDF que no coincideixi amb una empremta fixada, encara que el certificat sigui altrament vàlid sota la CA configurada.

Interfície d’administració X1

La interfície X1 és el pla de control entre l’ADMF i el processador. L’ADMF la utilitza per gestionar tasques d’intercepció i destinacions de lliurament; el processador la utilitza per retornar notificacions d’estat a l’ADMF.

Operacions admeses

Totes les peticions utilitzen codificació XML segons ETSI TS 103 221-1. Per exemple, una petició ActivateTask inclou l’identificador de tasca (XID), els identificadors d’objectiu, els ID de destinació i el tipus de lliurament:

<activateTaskRequest>
  <x1RequestMessage>
    <admfIdentifier>ADMF-001</admfIdentifier>
    <x1TransactionId>550e8400-e29b-41d4-a716-446655440000</x1TransactionId>
    <messageTimestamp>2025-12-27T10:30:00Z</messageTimestamp>
    <version>v1.13.1</version>
  </x1RequestMessage>
  <taskDetails>
    <xId>a1b2c3d4-e5f6-7890-abcd-ef1234567890</xId>
    <targetIdentifiers>
      <targetIdentifier>
        <sipUri>sip:alicent@example.com</sipUri>
      </targetIdentifier>
    </targetIdentifiers>
    <listOfDIDs>
      <dId>d1e2f3g4-h5i6-7890-jklm-nop123456789</dId>
    </listOfDIDs>
    <deliveryType>X2andX3</deliveryType>
    <implicitDeactivationAllowed>true</implicitDeactivationAllowed>
  </taskDetails>
</activateTaskRequest>

Cicle de vida de les tasques

Les tasques passen pels estats següents:

GetTaskDetails informa del valor de provisió definit per l’esquema awaitingProvisioning per a tasques pendents, failed per a tasques fallides i complete per a tasques actives, suspeses i desactivades. X1 no emet cap extensió d’estat de tasca específica de fabricant.

Quan implicitDeactivationAllowed està establert a true, el processador desactiva automàticament la tasca quan arriba a EndTime i notifica l’ADMF. Quan està establert a false, només una petició explícita DeactivateTask o un error fatal pot acabar la tasca.

Les tasques es poden modificar mentre estan actives. Els camps següents es poden modificar amb ModifyTask:

• Identificadors d’objectiu (afegeix o elimina criteris de filtre)
• ID de destinació (canvia els extrems de lliurament)
• Tipus de lliurament (canvia entre X2Only, X3Only, X2andX3)
• Hora d’acabament
• Paràmetre de desactivació implícita

XID i StartTime no es poden modificar després de l’activació.

Reintent idempotent i reactivació explícita

Repetir un ActivateTask equivalent mentre una tasca està activa o pendent és un reintent idempotent. No reinstal·la filtres, no avança la generació d’activació ni canvia el límit d’inici programat.

Una tasca desactivada es conserva temporalment com a marca de baixa i no es pot reprendre automàticament. Un ActivateTask explícit i autenticat només la pot reactivar quan la identitat d’intercepció protegida no ha canviat: han de coincidir l’XID, el tipus de lliurament i el conjunt canònic de parelles tipus/valor d’objectiu. L’ordre dels objectius i els duplicats exactes són irrellevants. La nova petició pot substituir els ID de destinació, les hores d’inici i acabament de mediació i les opcions de cicle de vida, subjecta a la validació actual normal. Les tasques suspeses i fallides continuen sense poder utilitzar aquesta operació.

Configureu totes les destinacions de substitució abans de reactivar i verifiqueu que cadascuna admeti el tipus de lliurament demanat. En cas d’èxit, el processador conserva l’antiga desactivació a l’historial d’auditoria, avança la generació d’activació i instal·la només els filtres nous. En cas de fallada de validació o instal·lació, la marca de baixa continua sense aplicar filtres i sense canvis. Si es perd la resposta, utilitzeu GetTaskDetails abans de reintentar: una petició idèntica activa/pendent es pot repetir amb seguretat; un resultat deactivated requereix una altra activació explícita després de corregir l’error subjacent.

Tipus de lliurament

Cada tasca especifica quina informació s’ha de lliurar:

Notificacions ADMF

El processador envia notificacions a l’ADMF per informar de l’estat operatiu: