Un firewall che decide in base alla porta non decide quasi più niente: la maggior parte del traffico interessante viaggia su 443, e la porta dice soltanto che è HTTPS. Application control sposta la decisione sul contenuto. Usa i decoder di protocollo del motore IPS per riconoscere l’applicazione dal flusso anche quando gira su porte o protocolli non standard, e sul traffico HTTP copre le versioni 1.0, 1.1 e 2.0. Serve una sottoscrizione FortiGuard Application Control attiva: senza, il sensore esiste ma non riconosce nulla.

Il sensore in profile mode

Profile mode è la modalità tradizionale: costruisci un application sensor sotto Security Profiles e lo agganci a una firewall policy. L’alternativa, il NGFW policy-based, fa scegliere applicazioni e categorie URL direttamente nella security policy senza profili; si imposta per VDOM, esiste solo se l’inspection mode del VDOM è flow-based, impone il central NAT e non supporta il wizard IPsec. Il blueprint chiede il primo caso.

FortiOS porta tre sensori precaricati: default, che monitora tutte le applicazioni, wifi-default e block-high-risk. L’errore più comune è applicare default aspettandosi che blocchi qualcosa: monitora e basta.

Dentro il sensore decidono due blocchi. La sezione Categories assegna un’azione a un’intera categoria di firme; Application and Filter Overrides agisce su singole applicazioni o su filtri costruiti per categoria, comportamento, popolarità, protocollo, rischio, tecnologia o vendor. Le quattro azioni non sono simmetriche, e la differenza pesa in diagnosi: Monitor lascia passare e scrive un log, Allow lascia passare e non scrive niente, Block scarta e logga, Quarantine blocca il traffico proveniente dall’IP dell’attaccante fino alla scadenza impostata e logga. Se hai messo Allow su una categoria e poi cerchi conferme nei log, non le troverai mai.

config application list
    edit "corp-apps"
        set other-application-action pass
        set other-application-log enable
        config entries
            edit 1
                set category 23
                set exclusion 34527
                set action block
            next
        end
    next
end

L’esclusione toglie la firma da quella entry, non dal sensore: l’applicazione esclusa può ancora fare match con le entry successive, e se una di quelle la blocca resta bloccata.

Perché vince una firma che non ti aspettavi

Quasi ogni applicazione fa match con più di una firma. FortiOS valuta i segmenti in ordine sequenziale — il segmento predefinito è la sezione Categories, ogni override ne aggiunge uno, e nella CLI questi segmenti sono le entries — mentre dentro un segmento l’ordine non conta. A parità di segmento vincono, in quest’ordine: le firme custom sulle FortiGuard, la firma con più azioni pre e post-match, il peso dell’applicazione, la visibilità (le firme nascoste perdono), il conteggio di pattern e pcre, e da ultimo l’ID più alto.

Nella pratica decide quasi sempre il peso, che FortiGuard assegna e tu non puoi cambiare. Si legge così:

get application name status | grep -A10 "app-name: \"Facebook\""

Le firme specifiche pesano più di quelle di protocollo: Facebook vale 10, SSL vale 1. È questo che spiega il caso classico — la regola sulla categoria sembra ignorata perché il traffico è stato etichettato con una firma diversa da quella su cui avevi lavorato. L’altra metà dei falsi misteri è il traffico cifrato: quello che il decoder legge dipende dal profilo SSL/SSH agganciato alla policy. Con la sola certificate inspection restano visibili SNI e certificato, mentre le firme che cercano pattern nel payload hanno bisogno della full SSL inspection.

Le due leve sulle porte, che non sono la stessa cosa

Si confondono di continuo, e producono blocchi che nessuno sa spiegare.

La prima è Block applications detected on non-default ports, cioè enforce-default-app-port: vive nel profilo e ribalta le azioni permissive. Un’applicazione con azione monitor o allow vista su una porta diversa da quella dichiarata dalla firma FortiGuard viene bloccata; le azioni block bloccano comunque, su qualunque porta. Nell’esempio della documentazione FTP su 21 passa e FTP su 2121 no.

La seconda è Network Protocol Enforcement, e ragiona al contrario: dalla porta verso il servizio. Dichiari quali protocolli sono ammessi su una porta nota e il motore IPS applica la violation action a chi non rispetta. Scatta in due casi: quando un dissector conferma un servizio non ammesso su quella porta, e quando nessun servizio viene confermato ma i dissector escludono tutti quelli ammessi.

config application list
    edit "protocol-GUI"
        set control-default-network-services enable
        config default-network-services
            edit 1
                set port 80
                set services http
                set violation-action block
            next
        end
    next
end

Leggere gli eventi

Gli eventi stanno in Log & Report > Security Events. La scheda Summary mostra i cinque eventi più frequenti per ogni tipo di UTM, ma richiede disk logging e historical FortiView attivi: senza, la card Application Control resta vuota e sembra che il sensore non logghi. Il dettaglio è nella scheda Logs, e cliccando una categoria nella Summary si arriva ai log già filtrati. Da CLI:

execute log filter category app-ctrl
execute log display
diagnose fortiview result security-log action=blocked

Nell’output di diagnose fortiview result security-log application control è logcat-10, e ogni riga porta nome evento, azione e conteggio: è il modo più veloce per capire se un blocco è avvenuto davvero prima di mettersi a leggere i log riga per riga. Un ultimo dettaglio che sorprende: perché il traffico DNS venga davvero loggato non basta l’opzione Allow and Log DNS Traffic, serve un override sull’applicazione DNS con azione Monitor.