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ó.