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.