Basi delle policy firewall – come verificare le stealth rule

Aggiornato – gennaio 2017

La stealth rule del firewall è la regola esplicita, posta in prossimità dell'inizio della policy, che nega l'accesso al firewall oltre quanto necessario per gestire il dispositivo. Dovrebbe essere definita come segue:

Source = ANY

Destination = [self]

Service / Application = ANY

Action = DROP

Logging = Enabled

Questo non si applica esattamente a determinati firewall, come Juniper Netscreen, che definiscono l'accesso amministrativo tramite impostazioni a livello di interfaccia anziché tramite la policy del firewall. Tuttavia, anche in questi casi gli auditor possono richiedere una stealth rule come prassi consolidata.

Perché definire una stealth rule

La stealth rule garantisce che le regole definite successivamente nella policy non consentano inavvertitamente l'accesso al firewall. Ad esempio, il firewall può avere un'interfaccia nella zona Web-DMZ. Una richiesta del team di sviluppo web può chiedere l'accesso SSH a tutti i sistemi nella Web-DMZ. Senza soffermarsi troppo sulla richiesta, sembra ragionevole che il team necessiti dell'accesso SSH a tutti quei server se è l'unico proprietario dei sistemi definiti nella Web-DMZ. Tuttavia, senza una stealth rule definita correttamente, l'accesso SSH sarebbe consentito non solo ai server nella Web-DMZ, ma anche al firewall stesso. Chiaramente non è appropriato, ma potrebbe passare inosservato a un amministratore del firewall per anni.

Per evitare questo errore semplice, ma significativo, è opportuno definire una stealth rule nella policy del firewall.

Come verificare la presenza di una stealth rule

Il processo è molto lineare. Esamini ogni policy e verifichi che una regola posta in prossimità dell'inizio della policy, dopo le necessarie regole amministrative, neghi tutto il traffico diretto al firewall (Any, Self, Any, Drop, Log).

In che modo FireMon può aiutare

FireMon fornisce controlli predefiniti per verificare l'esistenza della stealth rule in ciascuna policy. Questo controllo fa parte delle valutazioni predefinite e può essere aggiunto anche a qualsiasi valutazione definita dall'utente.

Un'altra opzione efficace è cercare le regole autonomamente utilizzando SiCL. In questo caso la ricerca è piuttosto lineare. Occorre verificare che in prossimità dell'inizio della policy esista una regola esplicita che scarta tutto il traffico diretto al firewall. Utilizzando la variabile predefinita self è possibile creare una query SiCL applicabile a tutti i dispositivi. In questo caso, la sintassi SiCL per questa ricerca è:

rule{ POSITION < 5 and source.any=true and destination is superset of self and SERVICE.any=true and action=’DROP’}

Nell'esempio riportato sopra ho specificato che la regola doveva essere una delle prime 4 regole della policy e che la destinazione deve contenere interamente lo spazio di indirizzamento del firewall (destination is superset of self). Superset comprende uguale e maggiore. Self è l'oggetto firewall stesso.