venerdì 22 aprile 2016

Credenziali nascoste in PowerCli


In questi giorni mi stavo occupando di sistemare degli script in PowerCLI che avevo preparato anni fa e mi è subito balzata agli occhi una cosa ORRIBILE... tutte le credenziali erano in chiaro all'interno dello script :-O

Sorvolando sulle considerazioni che a quei file l'accesso è ovviamente limitato ad una ristretta cerchia di persone (amministratori di sistema) mi sono comunque posto il dubbio se non esistesse un metodo migliore per fare quanto mi serviva... la necessità era di poter lanciare gli script in modalità unattended ma di non essere costretto a scrivere le credenziali direttamente in chiaro nel testo del comando.

Frugando sulla rete mi sono imbattuto in una serie di articoli che presentavano una funzionalità specifica di PowerCLI fatta apposta per accedere al vCenter da script senza essere costretti al salvataggio in chiaro della password che verrà recuperata da un xml esterno allo script dove sarà salvata in modo crittografato.

Nel file xml in realtà rimarranno in chiaro lo username e l'indirizzo dello stesso vCenter ma mi permetto di ritenere il fatto decisamente meno grave :-)

Passando a descrivere la parte operativa per prima cosa sarà necessario creare il suddetto file xml grazie al comando seguente:

New-VICredentialStoreItem -Host VCServerName -Password PASSWORD -User domain\username -file c:\cred.xml

Ora che abbiamo il nostro "repository" delle credenziali di accesso vediamo come richiamarle per poter effettuare il login dallo script al nostro vCenter.

Il tutto si risolve in un paio di righe di codice:

- la dichiarazione di una variabile che identifica l'oggetto dove sono archiviate le credenziali;
- richiamare le credenziali attraverso delle variabili che dipendono da quella precedentemente definita.

Ossia:

$creds = Get-VICredentialStoreItem -file C:\cred.xml

Connect-VIServer -Server $creds.Host -user $creds.User -password $creds.Password


Ovviamente nulla vieta, nel caso sia necessario effettuare diversi login o login con utenti diversi di moltiplicare alla bisogna i file xml ricordandosi di specificare la variabile "principale" con un nome differente e di conseguenza le variabili "figlio".

Ora i vostri script non riporteranno più le password per l'accesso ai vCenter e non ci sarà nemmeno bisogno che voi siate davanti al terminale per inserirla al momento giusto :-D

mercoledì 23 marzo 2016

Invocare gli script dentro le VM

A volte capita che sia necessario effettuare delle modifiche a delle VMs ma non si possa, o semplicemente non si voglia :-P, accedere ad una ad una per lanciare il comando.

Nel mio caso si trattava di una modifica da apportare nel corso di una operazione totalmente gestita da script e che pertanto non era possibile compiere a mano.

Ed ecco che il comando Invoke-VMScript viene meravigliosamente in aiuto in questi casi permettendo di sfruttare la potenza della hypervisor per arrivare fino dentro le macchine virtualizzate.

Per poterlo utilizzare ovviamente ci si dovrà connettere via powerCLI al vCenter dove sono ospitate le macchine sulle quali vogliamo lanciare i comandi o in alternativa lanciare il powershell classico e caricare l'Add-in di VMware con il comando "Add-Pssnapin VMware.VimAutomation.Core" (rimane ovvio che sul PC dal quale stiamo lanciando il comando, in entrambi i casi il PowerCLI di VMware debba essere installato).

In seguito basterà chiamare il comando Invoke-VMScript specificando la VM sulla quale vogliamo intervenire e indicando (tra virgolette) dopo il parametro -ScriptText il comando completo di path che verrà eseguito all'interno del sistema operativo. 
E' possibile specificare che tipo di script vogliamo lanciare o meglio, il comportamento di default in caso di sistema operativo guest windows è quello di lanciare un Powershell quindi, se volessimo modificare tale comportamento saremmo costretti a specificarlo.
Infine dobbiamo fornire le credenziali per effettuare l'autenticazione al sistema operativo guest. Sarà necessario fornire un'utenza e una password che siano autorizzati ad eseguire il comando che vogliamo lanciare ;-P.

Invoke-VMScript restituirà in una graziosa cornicetta ASCII l'output del comando lanciato all'interno del sistema operativo. Se non è previsto che il comando abbia un output, o l'output possa essere troppo verboso è possibile sfruttare un piping verso il nulla :-)

Nell'esempio sotto riportato vado ad aggiungere all'interfaccia Ethernet0 di un sistema Windows Server 2012 un ulteriore indirizzo IP (10.0.0.1/24) sfruttando il comando netsh e l'utente amministrativo del sistema.
Come si può vedere, visto che il comado netsh non prevede output, ho preferito redirigere tutto a quello che in linux sarebbe il /dev/null ma che in powershell diventa out-null.

Invoke-VMScript -VM TEST-VM -ScriptText "C:\Windows\System32\netsh.exe interface ipv4 add address Ethernet0 10.0.0.1 255.0.0.0" -ScriptType BAT -GuestUser "administrator" -GuestPassword "Pa$$w0rd" | out-null

Qui sotto riporto il link al techpaper di VMware relativo al comando:

lunedì 21 marzo 2016

Powershell da task manager di windows

Ok... ore che lavori al tuo script in powershell lo provi, lo "debugghi", lo riprovi ancora un'ultima volta e ora... arriva il momento di vederlo camminare con le sue "gambette" :-D

Lo affidi alle amorevoli cure del task manager di Windows!

Ok ma come si fa?

Sfortunatamente non si può operare allo stesso modo che con gli script in DOS ma è necessario specificare il path dell'interprete, che nel nostro caso è ovviamente powershell.
Una volta fatto questo e solo nei parametri andremo ad indicare il percorso completo dello script (meglio se tra virgolette per evitare problemi con gli eventuali spazi).

Fino a qui tutto chiaro ma sfortunatamente ancora non sufficiente...

Infatti dobbiamo spiegare a powershell che dovrà trattare quello che gli abbiamo dato in pasto nei parametri come un comando e non come un oggetto.

Per fare questo basta anteporre al percorso dello script un "&" ovviamente con l'accortezza di racchiudere tutto tra virgolette nel caso si inseriscano degli spazi.


Quindi per ricapitolare e rendere facile il copia incolla :-P

Nella riga del comando metteremo il path per l'eseguibile di powershell:

C:\Windows\system32\windowspowershell\v1.0\powershell.exe

Mentre nella riga dei parametri, con tutte le virgolette del caso, piazzeremo un "&" e poi il percorso completo dello script in powershell che intendiamo eseguire tramite lo schedulatore di windows:

"& "C:\test.ps1""

Solo per completezza vi ricordo di controllare anche i permessi con i quali fate eseguire lo script allo schedulatore e di impostare correttamente il fatto che possa essere eseguito anche quando l'utente non è loggato.


lunedì 22 febbraio 2016

SandBlast Check Point come farlo funzionare...


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: 
  1. Installazione, aggancio alla management, aggiornamento e installazione delle licenze sulle appliances; 
  2. Abilitazione della feature sui gateway interessati. 
  3. Creazione di una policy per la threat emulation. 
  4. Configurazione della seconda appliance. 
  5. Configurazione del Multiple Sandblast Appliances. 
  6. 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). 

  1. # tecli advanced remote activate 
  2. # tecli advanced remote show 
  3. 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) 
  4. # tecli advanced remote activate 
  5. # tecli advanced remote show 
  6. # tecli advanced remote add “IP_ADDRESS” (uno degli IP presenti nella lista delle Suggested Appliances for Private Cloud) 
  7. Install policy 
  8. (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...