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