Il modulo IPS è quello che più spesso trasforma un FortiGate sano in un FortiGate lento, e le domande d’esame su questo dominio arrivano quasi sempre in coppia: una sulla costruzione del sensore, una su cosa fare quando la CPU resta inchiodata. Sono lo stesso problema visto da due lati, perché il carico dipende da quante firme hai chiesto al motore di valutare e su quanto traffico.

Chi fa cosa: decoder, motore, sensore, policy

Prima di cercare attacchi, i decoder di protocollo identificano il protocollo di ogni flusso: le firme sono specifiche per protocollo, quindi il FortiGate cerca una firma HTTP solo nel traffico HTTP e così risparmia risorse. Le porte dei decoder si cambiano solo da CLI, e quelli impostati su auto rilevano il proprio traffico su qualsiasi porta. Sopra i decoder gira il motore IPS, che esamina il traffico solo per le firme elencate in un sensore. E il sensore non fa nulla finché non lo selezioni in una policy. Vale anche il contrario, ed è una trappola classica in laboratorio: serve almeno una policy con ispezione IPS attiva perché il FortiGate scarichi gli aggiornamenti delle definizioni.

Costruire un sensore che non scansiona il mondo

Un sensore IPS è un elenco di voci, e ogni voce è di tipo Signature — firme scelte a mano, l’unico modo per includere firme custom — oppure Filter, cioè un insieme di attributi. Gli attributi sono Target, Severity, Protocol, OS e Application; più valori dentro lo stesso gruppo si combinano in OR, gruppi diversi si combinano in AND. Un filtro con OS Linux e Application Apache seleziona quindi solo le firme che valgono per entrambi: se ti servono tutte le firme Linux e tutte quelle Apache devi creare due filtri, non uno.

Le voci vengono valutate dall’alto verso il basso e vince la prima corrispondenza, quindi l’ordine è configurazione, non estetica: una voce larga in cima annulla le eccezioni che hai scritto sotto.

FortiOS include sensori predefiniti: default filtra Critical, High e Medium lasciando a ciascuna firma la sua azione; high_security filtra le stesse ma forza Block; all_default_pass mette tutto in pass/monitor; protect_http_server filtra su Target Server e Protocol HTTP. Il punto pratico è perché high_security è più aggressivo: le firme nuove escono volutamente larghe e spesso con azione pass, per coprire subito la minaccia e affinarle dopo. Usalo dove i falsi positivi sono un prezzo accettabile.

Contro i falsi positivi dei rilasci freschi c’è un’arma più chirurgica, il tempo di attesa per VDOM: le firme appena aggiornate restano in monitor fino a sette giorni e il log dice che la firma è in hold.

config system ips
    set signature-hold-time 3d12h
    set override-signature-hold-by-id enable
end

Solo le voci di tipo Signature accettano le impostazioni rate-based: rate-count, rate-duration, rate-mode e rate-track. Con continuous l’azione scatta appena il contatore raggiunge la soglia; con periodical servono quel numero di occorrenze dentro la durata. È lo strumento giusto per i login falliti. I filtri non hanno le opzioni rate-based: se una domanda te le propone su un filtro, è un distrattore.

Perché la CPU sale e cosa si tocca

Il primo riflesso è misurare, non configurare.

get system performance status
get system performance top
get ips session

Il primo dà gli stati di CPU e memoria, più le medie di sessioni, session setup rate e attacchi IPS bloccati. Il secondo elenca i processi per uso di CPU e dice se è davvero il motore IPS a mangiare il tempo. Il terzo mostra la memoria usata e quella massima disponibile all’IPS. Una riga di CPU con quasi tutto in system e quasi zero idle significa apparato saturo di traffico da ispezionare, e la risposta documentata è ridurre il traffico ispezionato — bloccare protocolli inutili, restringere le policy — non alzare a caso i contatori.

Le manopole vere stanno in config ips global. engine-count decide quanti motori girano in parallelo: lascialo a zero, che significa scelta automatica. np-accel-mode e cp-accel-mode abilitano NTurbo e IPSA, cioè l’offload delle sessioni flow-based ai processori di rete e del pattern matching ai content processor. Il database esteso e le definizioni OT vanno nella direzione opposta: aumentano il numero di firme da valutare, e infatti le firme OT sono escluse di default.

Fail-open e conserve mode: il compromesso va dichiarato

Il fail-open non è una modalità prestazionale: scatta quando il buffer del socket IPS è pieno e il motore non ha più spazio per creare sessioni. Con fail-open disable, che è il default, le nuove sessioni che richiedono ispezione flow-based vengono scartate; con enable passano senza ispezione. Le sessioni offloadate a NTurbo non supportano il fail-open e vengono scartate comunque.

Se il sistema ci finisce spesso puoi aumentare socket-size, ma il compromesso va detto per intero: un buffer troppo grande consuma più memoria e porta in conserve mode più spesso, uno troppo piccolo riporta al fail-open. La conserve mode ha soglie in percentuale di RAM — 88 per entrarci, 82 per uscirne — e si verifica con diagnose hardware sysinfo conserve. Una policy con il solo IPS continua a lavorare; se sulla stessa policy c’è anche l’antivirus in modalità proxy, decide av-failopen.