Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
linnix — Osservabilità Linux basata su eBPF con rilevamento di incidenti tramite IA. Con licenza AGPL-3.0. | Kitploit
Strumenti/GitHubGitHub/linnix-os/linnix
Sicurezza dell'Infrastruttura CloudSicurezza dei ContenitoriDevSecOpsThreat IntelligenceRisposta agli IncidentiSicurezza dell'IARilevamento di AnomalieAnalisi dei Log
GitHublinnix-os/linnix

linnix

Osservabilità Linux basata su eBPF con rilevamento di incidenti tramite IA. Con licenza AGPL-3.0.

Vedi Repository
24915315h 15m faRevisionato da Kitploit

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

Linnix

Trova quale processo sta danneggiando i tuoi SLO — non solo chi sta usando la CPU, ma chi sta causando stalli.

CI License DOI

Il Problema

top mostra CPU all'80%. Prometheus mostra alta latenza. Ma quale pod sta effettivamente bloccando il tuo servizio di pagamento?

Linnix utilizza eBPF + PSI (Pressure Stall Information) per rispondere a questa domanda. Il PSI misura il tempo di stallo effettivo — non l'utilizzo, ma la contesa. Un pod che usa il 40% della CPU con un PSI del 60% è peggiore di uno che usa il 100% della CPU con un PSI del 5%.

Cosa rileva Linnix:

  • Vicini rumorosi: Quale container sta affamando gli altri
  • Tempeste di fork: Creazione incontrollata di processi prima che mandi in crash il nodo
  • Attribuzione degli stalli: "Il Pod X ha causato uno stallo di 300ms al Pod Y"
  • Saturazione PSI: Pressione CPU/IO/Memoria che non appare in
top

[!IMPORTANT] Solo monitoraggio per impostazione predefinita. Linnix rileva e segnala — non agisce mai senza una configurazione esplicita.

🔒 Sicurezza e Privacy

  • Politica di sicurezza: Consulta il nostro modello di sicurezza, i privilegi richiesti e il processo di segnalazione delle vulnerabilità
  • Garanzie di sicurezza: Comprendi la nostra architettura "Monitor-First" e i controlli di sicurezza
  • Panoramica dell'architettura: Diagramma di sistema e flusso di dati per le revisioni di sicurezza

Promessa chiave: Tutta l'analisi avviene localmente. Nessun dato lascia la tua infrastruttura a meno che tu non configuri esplicitamente le notifiche Slack. Scopri di più sulla privacy dei dati →

Avvio rapido (Kubernetes)

Distribuisci Linnix come DaemonSet per monitorare il tuo cluster.

root@kitploit:~
# Apply the manifests
kubectl apply -f k8s/

Accedi all'API:

root@kitploit:~
kubectl port-forward daemonset/linnix-agent 3000:3000
# API disponibile su http://localhost:3000
# Streaming eventi: curl http://localhost:3000/stream

Avvio rapido (Docker)

Provatelo sulla vostra macchina locale in 30 secondi.

root@kitploit:~
git clone https://github.com/linnix-os/linnix.git && cd linnix
./quickstart.sh

Come Funziona

  1. Collector (eBPF): Risiede nel kernel, osservando gli eventi di fork, exec, exit e dello scheduler con un overhead inferiore all'1%.
  2. Reasoning Engine: Aggrega i segnali (PSI + CPU + Albero dei processi) per rilevare pattern di guasto.
  3. Triage Assistant: Quando una soglia viene superata, Linnix cattura lo stato del sistema e spiega la causa principale.

Rilevamenti Supportati

Tipo di IncidenteLogica di RilevamentoValore di Triage
Circuit BreakerPSI alto (>40%) + CPU alta (>90%)Identifica l'albero dei processi specifico che causa lo stallo.
Tempesta di fork>10 fork/sec per 2sIntercetta script incontrollati prima che mandino in crash il nodo.
Perdita di memoriaCrescita sostenuta della RSSSegnala i container che andranno in OOM prima o poi.
Job a vita breveRapido turnover di exec/exitIdentifica script di build inefficienti o loop di crash.

Sicurezza e Architettura

Linnix è progettato per la sicurezza in produzione.

  • Monitor-First: Le capacità di enforcement sono opzionali e richiedono una configurazione esplicita.
  • Basso overhead: Utilizza buffer eBPF perf, non polling di /proc.
  • Isolamento dei privilegi: Può essere eseguito con CAP_BPF e CAP_PERFMON su bare metal. Il DaemonSet Kubernetes attualmente utilizza la modalità privilegiata per semplicità.

Vedi SAFETY.md per il nostro modello di sicurezza dettagliato.

Funzionalità Kubernetes

Linnix ha un supporto Kubernetes di prima classe:

  • Attribuzione dei Pod: Ogni evento di processo è etichettato con pod_name, namespace, container_id
  • Consapevolezza dei Namespace: Filtra e interroga per namespace
  • Tracciamento del contributo PSI: Vedi quale pod ha contribuito alla pressione PSI a livello di sistema
  • Integrazione cgroup: Mappa i processi ai loro cgroup per l'aggregazione a livello di container
root@kitploit:~
# Esempio: Ottieni i processi che causano stalli nel namespace payments
curl "http://localhost:3000/processes?namespace=payments&sort=psi_contribution"

Commercio / Regolamento On-Chain

Linnix include un layer di pagamento senza fiducia (Linnix-Claw) che regola il lavoro da agente a agente on-chain tramite stablecoin ERC-20. Quando un agente delega un compito a un altro, il risultato — una ricevuta firmata con prova di telemetria — viene inviato a uno smart contract TaskSettlement che rilascia il pagamento direttamente dal pagatore al beneficiario.

Architettura

root@kitploit:~
Agent A (payer)                    Agent B (payee)
   │  createTask(taskId, payeeDID, maxAmount)
   │──────────────────────────────────▶│
   │                                   │ ← does work, captures eBPF telemetry
   │    submitReceipt(taskId, amount, receipt, sig)
   │◀──────────────────────────────────│
   │                                   │
   └──── TaskSettlement.sol ─── ERC-20 transfer ──▶ payee

Contratti chiave (testnet Base Sepolia):

ContrattoIndirizzo
AgentRegistry0x9a6FeBA6d7B97ef91099051eB61F372d1EcD83a3
TaskSettlement0x60eE6872920addF41359625B47A07401496bBD5b
StakeBond0xEE31fC610B9b64982990adB3ba228E9dBbfF6a73

Configurazione

Aggiungi una sezione [chain] al tuo linnix.toml:

root@kitploit:~
[chain]
enabled = true
rpc_url = "https://sepolia.base.org"
chain_id = 84532
settlement_contract = "0x60eE6872920addF41359625B47A07401496bBD5b"
registry_contract = "0x9a6FeBA6d7B97ef91099051eB61F372d1EcD83a3"
token_address = "0x036CbD53842c5426634e7929541eC2318f3dCF7e"  # USDC on Base Sepolia
token_decimals = 6

La chiave del firmatario viene risolta in ordine di priorità:

  1. chain.private_key nel file di configurazione
  2. Variabile d'ambiente LINNIX_CHAIN_PRIVATE_KEY
  3. Chiave secp256k1 derivata da HKDF dall'identità Ed25519 dell'agente (default — configurazione zero)

Demo End-to-End

root@kitploit:~
# Deploy contracts to a local Hardhat node
cd linnix-claw-contracts && npx hardhat node &
npx hardhat run scripts/deploy.js --network localhost

# Run the commerce demo
./scripts/demo_commerce_e2e.sh --local

Vedi il codice del contratto e cognitod/src/onchain.rs per i dettagli di implementazione.

Early Adopters

Questo progetto è in fase di sviluppo attivo. Se lo stai usando o valutando, apri una issue o scrivi a [email protected].

Licenza

  • Agente (cognitod): AGPL-3.0
  • Collector eBPF: GPL-2.0 o MIT (i programmi eBPF devono essere compatibili con la GPL per il caricamento nel kernel)

Licenze commerciali disponibili per team che non possono utilizzare AGPL. Vedi LICENSE_FAQ.md per i dettagli.

Scarica lo strumento