Avendo trovato non poche difficoltà a reperire informazioni e guide ben strutturate ho deciso di pubblicare un paio di paginette per chi si dovesse trovare nella mia stessa situazione e prima di gettarsi totalmente nello sconforto decidesse di tentare il tutto per tutto con una ultima disperata ricerca su internet...
La presente vuole essere una guida (non esaustiva) all'installazione e alla prima configurazione delle lame Threat Emulation e Threat Extraction di Check Point configurate su appliances dedicate.
INSTALLAZIONE APPLIANCE
L’installazione delle appliance TE non si differenzia da quella di un normale gateway Check Point.
Le appliances hanno già precaricato una versione di Gaia specifica per le appliance che fanno Threat Emulation.
ATTENZIONE! Non è una versione normale di Gaia ma è ad-hoc per la Threat Emulation.
(Non verranno qui riportati i passaggi relativi all’installazione di un gateway Check Point dandoli per scontati al lettore di questa tipologia di documento e comunque facilmente reperibili con una banale ricerca su Google)
NON esiste un cluster di TE appliances!
Il Fail-over è manuale ossia nel caso in cui una delle due macchine dovesse avere problemi sarà necessaria una nuova installazione delle policy definendo la macchina superstite come destinazione dei processi di emulazione.
Diverso il discorso per quanto riguarda il bilanciamento del carico relativo ai processi di emulazione. Questa operatività e definita da una configurazione specifica della TE che verrà spiegata più avanti nel documento.
Le operazioni che andremo a compiere per l’installazione delle appliance Sandblast saranno:
- Installazione, aggancio alla management, aggiornamento e installazione delle licenze sulle appliances;
- Abilitazione della feature sui gateway interessati.
- Creazione di una policy per la threat emulation.
- Configurazione della seconda appliance.
- Configurazione del Multiple Sandblast Appliances.
- La threat extraction.
Installazione – aggancio alla management – aggiornamento e installazione delle licenze
Installazione
Una volta posizionate e cablate le macchine si procederà ad un’installazione standard del gateway dalla console e successivamente dalla WebUI al solito indirizzo
https://192.168.1.1 raggiungibile collegandosi all'interfaccia di management.
Dovranno essere abilitate solo le feature di Gateway.
Nessuna feature di cluster dovrà essere attivata.
L’ideale è attivare almeno due interfacce di cui una sarà quella di management e la seconda gestirà il traffico di emulazione da e verso il firewall (meglio di più e magari aggregate se si prevedono parecchi file da analizzare).
Aggancio alla management
L’operazione di aggancio alla management ricalca quella di un gateway standard senza alcuna differenza.
E’ necessario assicurarsi di aver installato sulla Management l’R77.30 Management Add-On per poter gestire tutte le feature delle blade Threat Emulation e Threat Extraction (vedi
SK105412).
Il consiglio in questa fase è quello di evitare di attivare la feature di Threat Emulation ed Extraction ma di effettuare questa operazione in un secondo momento.
Quindi per prima cosa fare il “SIC “e definire la macchina solo come firewall per procedere “puliti” alle fasi successive.
Come per qualunque altro gateway sarà necessario sistemare la topologia, in modo che la macchina ruoti il traffico in maniera corretta, e l’anti-spoofing per non bloccare connessioni legittime.
Se l’appliance fosse superiore al modello TE100 sarà necessario anche abilitare l’hyper threading (non attivo di default). Vedi
sk93000.
Aggiornamento e installazione delle licenze
A questo punto è possibile caricare le licenze sulla macchina, direttamente da Smart Update, e procedere all’aggiornamento degli ultimi hotfix attraverso il CPUSE via WebUI.
IMPORTANTE!!!
Attenzione alle e-mail... la scansione delle stesse senza configurare il gateway come MTA potrebbe dare come risultato numerosi errori nella ricezione delle mail o l'impossibilità totale di ricevere mail in modo corretto.
Per maggiori informazioni consultate la sezione dedicata nel documento di Check Point:
Abilitazione della feature sui gateway
Una volta completata in maniera corretta l’installazione delle appliances ed effettuato il collegamento con la SMS siamo pronti per l’attivazione delle funzionalità di Threat Emulation.
Il prodotto dovrà essere attivato sul nodo (o cluster) primario attraverso il quale il traffico da emulare passerà e sulla appliance che dovrà effettuare l’emulazione.
Inizialmente verrà attivata e configurata una sola delle appliance e solo in seguito si attiverà la feature per il bilanciamento del carico.
Nell'ordine si dovrà procedere:
- attivando la Threat Emulation sull'appliance definendo il target di emulazione come locale
- poi sul nodo (o cluster) primario definendo come target l’appliance.
Il workflow è definito nella guida di Check Point e riportato sotto:
Una volta spuntata la voce editando il nodo partirà un semplice wizard che chiederà semplicemente dove dovrà essere effettuata l’emulazione dei file.
Editando il gateway è poi possibile definire ulteriori opzioni ma che, salvo si voglia evitare di condividere anonimamente le risultanze delle minacce rinvenute con il Cloud di Check Point, possono essere lasciate ai valori di default.
L’unica differenza tra le configurazioni del gateway primario e l’appliance sarà quindi ovviamente l’Analysis Location che per l’appliance sarà settato il "This gateway" mentre per il gateway primario avrà definito il nome che l'appliance ha sulla management.
Creazione di una policy per la threat emulation
Attivate le appliance è ora necessario definire una policy per renderle effettivamente operative.
Dalla management ci si dovrà recare nel tab relativo alla blade Threat Prevention.
Prima cosa utile da fare sarebbe creare degli UserCheck personalizzati che verranno mostrati agli utenti nel caso in cui il firewall dovesse bloccare gli accessi ad una risorsa o chiedere all'utente l’azione da intraprendere. Tali UserCheck verranno poi sostituiti durante la definizione della policy ai check di default.
Il secondo passo è quello di creare un profilo partendo possibilmente dal Recommended_Profile e modificando le varie voci all'occorrenza.
Abilitare la Threat Emulation e definire il livello di protezione che si vuole garantire:
Definire i parametri relativi alla protezione e se applicata all’HTTP e al SMTP e i tipi di file supportati:
Specificare l’Analysis Location (la Threat Emulation Appliance) e le caratteristiche delle macchine sulle quali verrà effettuata l’emulazione:
Se la protezione è sul protocollo SMTP eventuali esclusioni di indirizzi mail e come comportarsi in caso nella mail venga rinvenuto contenuto non conforme.
Attenzione al parametro relativo al logging che può generare parecchie entry nel fw.log.
La stessa policy dovrà essere ASSOLUTAMENTE installata sia sul gateway principale che sulla appliance della Threat Emulation pena il non funzionamento dell’emulazione.
Un punto di particolare rilievo e di cui tenere conto (soprattutto in fase di installazione) è che solo dopo aver applicato una policy alla Threat Emulation Appliance questa comincerà il download delle immagini dei client per l’emulazione (l'appliance di default arriva senza immagini a bordo).
L’operazione di download e inizializzazione dei virtual client è terribilmente lunga e durante il processo verranno restituiti una marea di log che indicano l’impossibilità di procedere all’emulazione dei file.
Una valutazione “spannometrica” senza tenere conto della velocità della rete (ogni immagine “pesa” circa 4GB) è di un paio di ore per l’inizializzazione di una singola macchina.
Per verificare lo stato del download delle immagini è possibile collegarsi in ssh all’appliance e (comando riconosciuto sia da clish che da expert) dare il comando:
# tecli show download images
Per la verifica dello stato delle emulazioni invece si può usare:
# tecli show statistics
Configurazione della seconda appliance
A questo punto, ossia una volta che la prima delle due appliance è stata correttamente e completamente configurata, è possibile procedere alla messa in opera della seconda macchina.
La procedura è ovviamente identica alla prima ossia, nell'ordine:
- Installazione della macchina
- Configurazione dell’appliance via console e poi via WebUI
- Aggancio alla management
- Installazione delle licenze e aggiornamento con le hotfix
Configurazione del Multiple Sandblast Appliances
Check Point ha previsto una sorta di load balancing tra le appliance per la fase di emulazione.
Non esiste un reale metodo di fail-over se non quello manuale di riconfigurare le policy puntando alla seconda appliance ed effettuare un’install policy sui gateway.
La documentazione ufficiale è reperibile a questo
link.
Per configurare le machine con la feature Multiple Sandblast appliance si dovranno seguire i passaggi sotto indicati:
Connettersi in expert mode ai firewall del nodo primario -NON LE APPLIANCES - (l’operazione deve essere completata su entrambi i gateway nel caso di un cluster).
- # tecli advanced remote activate
- # tecli advanced remote show
- Install policy (dopo l’install la feature si disattiverà nuovamente ma alla successiva attivazione nella lista dovrebbero apparire gli IP nell'elenco delle Suggested Appliances for Private Cloud)
- # tecli advanced remote activate
- # tecli advanced remote show
- # tecli advanced remote add “IP_ADDRESS” (uno degli IP presenti nella lista delle Suggested Appliances for Private Cloud)
- Install policy
- (nel caso di un cluster ripetere sull'altro nodo)
Qui arriva una delle parti più curiose del prodotto.
Per potersi rendere conto del fatto che l'emulazione stia realmente avvenendo su entrambe le appliance non dovremo usare il comando visto prima (tecli s s) ma potremo (da command line) vedere quanti file vengono processati per unità di tempo (minuto, ora, giorno o mese) con:
# tecli show througput (minute - hour - day - month)
Oppure ci potremmo avvalere dello Smart Tracker nella vista dedicata alla Threat Emulation:
che vede inserita di default una colonna con la dicitura "Analyzed On" che riporterà il nome del Gateway sul quale l'emulazione è stata processata.
La threat extraction
La modalità di funzionamento della blade Threat Extraction è illustrata nell'immagine tratta dalla documentazione Check Point.
La mail attraversa il gateway su cui è attiva la funzionalità e gli eventuali allegati vengono privati della parte “attiva”.
L’attivazione della blade avviene sul gateway primario sul quale è già presente e operativa la funzionalità di MTA (la feature non va attivata sulle appliance della Threat Emulation).
L’eventuale presenza di una Threat Emulation attiva permette di verificare che i file che vengono “disattivati” non siano realmente dei file compromessi da malware (comportamento definibile dalle impostazioni della blade).
Per rendere la blade funzionante è necessario innanzitutto procedere con l’attivazione sul gateway (o cluster) mettendo la spunta sulla rispettiva voce.
Se la funzionalità di Mail Transfer Agent non fosse già attiva sul gateway il wizard proporrebbe delle form dove inserire i dati per la configurazione del MTA.
Alla fine verrà richiesto di effettuare un’installazione delle policy e di configurare il flusso delle mail in modo che attraversino il gateway.
Le impostazioni da dare sul gateway sono scarse e prevedono esclusivamente la possibilità di forzare uno stato di detect a prescindere da quanto definito sulla policy e la gestione dello spazio che i log dovranno occupare.
Maggiore dettaglio invece è possibile direttamente nelle policy definibili dal tab Threat Prevention.
Dovrà essere creata una nuova policy, o editata una esistente, mettendo la spunta nella casella relativa alla Threat Extraction nella sezione General Properties.
Apparirà una nuova sezione relativa alla Threat Extraction dalla quale sarà possibile definire il comportamento della lama.
Uno dei settaggi ai quali prestare maggiore attenzione è quello della sezione "Extraction Method" che definisce il comportamento nel caso in cui vengano rilevati componenti attivi nell'allegato della mail.
Si può decidere che l’allegato venga convertito in un PDF oppure che tutto il contenuto potenzialmente malevolo venga estratto.
Nella successiva sezione si dichiarano quali mail devono essere processate e quali no.
Nell'ultima sezione invece si definiscono il logging e le eccezioni relative a tipologie particolari di file.
Alla fine sarà necessario il classico l’install della policy che dovrà essere effettuato sul gateway sul quale la Threat Extraction e l’MTA è attivo e che dovrà essere dichiarato nell'elenco degli "Install on" gateway nella apposita colonna della policy.
Spero che queste indicazioni possano tornare utili a qualcuno...
