Cyber Risk – il Dipendente infedele (la minaccia e’ in azienda)

il dipendente infedele

The Unfaithful Employee – #Cyber Risk

The unfaithful employee

Ormai leggiamo, sentiamo, vediamo speciali alla TV, che hanno come tema l’esponenziale crescita del Cyber Risk da cui derivano attacchi di ogni genere che vanno dalla truffa online, alla compra vendita di carte di credito, all’uso di speciali software/scripts ai Ransomware, che “rapiscono” i nostri device, personali o aziendali per un vero e proprio riscatto, spesso in cripto valute, etc….. e la lista e’ varia come la fantasia delle persone che le studiano.

Oltre ai pericoli sopra citati dobbiamo aggiungerne uno che negli ultimi anni sta evidenziandosi alla stregua dei cosiddetti “attacchi hacker”, questo pericolo e’ il rischio del “dipendente infedele”.
Gia, perche’ se e’ ancora vero che piu’ dell’80% delle spese in ambito security delle aziende e’ ancora improntato verso la “sicurezza del perimetro esterno”, sono sempre piu’ in aumento i casi documentati di violazioni (spesso ad hoc) da parte o con la complicita’ di dipendenti infedeli.

Del resto sono sempre piu’ lontani, o confinati nella cinematografia, gli attacchi del singolo hacker che punta ostinatamente la grande preda (Banche o Assicurazioni, la NASA ed i soliti noti….), mentre nella realta’ ormai siamo tutti collegati a tutti tramite e-mail, social network e cosi anche chi punta “alla balena bianca” passa prima per quelli che, nella migliore delle ipotesi, possono diventare vittime collaterali, ma comunque vittime.
Chi entra nella nostra privacy per poter arrivare ad un bersaglio piu’ importante, colpisce comunque prima noi ed i nostri diritti; questo perche’ non venga mai sottovalutata l’importanza che ormai rivestiamo tutti nei confronti di tutti, un po’ come spiegato anche nel famoso concetto dei 6 gradi di separazione (Six Degrees of Separation).
Basta quindi con l’idea ormai assurda di credere di essere al sicuro, affermando semplicemente: “perche’ dovrebbero colpire proprio me, io non ho nulla da nascondere….” ;
e’ esattamente questo modo di pensare che aiuta chi usa con capacita’ le tecniche di ingegneria sociale e di phishing a perpretare i loro crimini.

In effetti possiamo elencare alcuni punti importanti che possiamo descrivere come sfavorevoli alla lotta al Cyber Risk:

  • apparente e diffusa sensazione di sicurezza – troppe persone pensano che avere un antivirus sul pc ed un Firewall da 2 euro al mese sul cellulare basti alla protezione;
  • sottostimiamo che i danni possono essere pesantissimi – per un privato puo’ essere il trovarsi con il conto bancario svuotato, oppure dover pagare un riscatto x riavere l’accesso alle proprie foto, mentre per le aziende molto spesso e’ la perdita della reputazione e molto altro ancora….
  • il campo di gioco/battaglia e’ il mondo intero – questo e’ uno degli aspetti meno considerati, oggi giorno si puo’ venire attaccati da chiunque, da ogni parte del mondo, ed i motivi che smuovono gli attacchi possono essere i piu’ diversi, non soltanto quelli economici o legati allo spionaggio industriale (che fa molto spy story)
  • il rischio dell’errore umano e’ dietro l’angolo – quotidianamente i nostri software e le nostre app vengono aggiornate, spesso in automatico, perche’ le aziende scoprono (spesso troppo in ritardo) bugs e malfunzionamenti di ogni genere, a volte sono errori di programmazione, altri sono modifiche richieste dal mercato, altri ancora iniettati da dipendenti fraudolenti, o pagati per farlo etc….etc….

Non a caso, anche il mercato assicurativo sta introducendo polizze per il “cyber risk”, studiate per garantire risposte certe e complete a questo rischio in forte ascesa.

Ma torniamo al tema portante di questo articolo e proviamo a definire chi e’ il “dipendente infedele”.
Il dipendente infedele è quel soggetto che essendo all’interno di una azienda, attraverso svariate tecniche tra cui il social engineering e, l’utilizzo dei sistemi e delle tecnologie informatiche, riesce a carpire/rubare informazioni sensibili circa l’azienda stessa e i colleghi di lavoro.

Sbagliamo se pensiamo che per arrivare ad avere informazioni tanto importanti o confidenziali si debba essere per forza parte dell’ingranaggio dei Manager (anch’essi spesso non esenti da questo rischio per via del ruolo chiave che rivestono) , invece tipicamente queste figure, qualora non abbiano privilegi particolari o amministrativi, punteranno ad acquisire informazioni in qualsiasi  modo possibile, tipo rovistando tra le varie scrivanie in cerca di
post-it riportanti utenze e password, accedendo alle postazioni dei colleghi durante la loro assenza oppure introducendosi in aree con accesso restrittivo in cerca di documenti lasciati in vista, effettuando backup dalla rete aziendale interna o di database contenenti progetti in corso o qualsiasi altra informazione che potrebbe tornare utile, salvando il tutto su supporti esterni come chiavette USB e molto altro ancora……

Quali sono le cause

Generalizzando il concetto, potremmo dire che questa figura è solitamente caratterizzata da un forte senso di insoddisfazione verso l’azienda, i titolari o i colleghi.

I dati sottratti illecitamente solitamente vengono utilizzati per i seguenti scopi:

  • vendita delle informazioni ad una azienda concorrente in cambio di un compenso economico oppure di una offerta lavorativa migliore;
  • riutilizzo dei dati sottratti per aprire una società in parallelo spesso violando patti di non concorrenza;
  • estorsione di denaro verso i legittimi proprietari dei dati;
  • modifica/cancellazione di dati, oppure divulgazione senza scopo di lucro al fine di creare un danno economico e di immagine all’azienda.

Questo ci porta ad interrogarci circa la validita’ sul campo di molte delle piu’ comuni tecniche di policy aziendale, ma nel caso si verifichi una fuga di dati verso l’esterno ad opera di un dipendente infedele sara’ importante effettuare delle indagini per far luce sullo scenario accaduto e trattare nel modo più opportuno l’incidente verificatosi, e quale miglior sistema che adottare le tecniche della Digital Forensics ed i tencici specializzati in questa materia.

Questo fenomeno e’ in grande ascesa e le aziende che monitorano lo sviluppo del Cyber Crime, fanno notare come negli ultimi anni nel dark web, gli hacker stanno reclutando e preparando tecnicamanete degli insider con gli strumenti e le conoscenze necessarie a perpetrare attacchi, informatici e non, nei confronti delle loro aziende.

Il rischio del DarkWeb

Il dark web sta facendo leva principalmente su tre fattori predominanti, per creare la propria “armata” di dipendenti infedeli, quali:

  • insider trading: bastera’ dimostrare di poter accedere ad informazioni non disponibili al grande pubblico, per poter essere reclutati;
  • vendita di numeri di carte di credito da parte di insider che lavorano presso negozi di vendita al dettaglio;
  • installazione di malware all’interno delle aziende, eludendo così ogni sistema di sicurezza perimetrale.

Tutti motivi per i quali oggi giorno alle aziende non basta piu’ monitorare soltanto la parte fisica dei propri dati e device ma e’ costretta ad introdurre anche quelli che vengono definiti come “vigilanti del sentiment”, ossia personale preparato ed addestrato a riconoscere non soltanto gli abusi a livello tecnico ma principalmente i “segnali” della possibile infedelta’ , quindi del “sentiment negativo” dei dipendenti verso specifiche figure aziendali o dell’intera azienda, insomma dei veri e propri investigatori.

Anche in questo caso potremmo dettagliare con tre punti chiave, i motivi per cui un’azienda dovrebbe rivolgersi ad un’agenzia investigativa:

  • a tutela del patrimonio e della produttività aziendale;
  • a salvaguardia del know-how aziendale;
  • a sostegno del management

A coadiuvare questo articolo useremo le parole di due veri esperti del mondo digitale e della sicurezza, in grado di spiegare ancora meglio i concetti sopra descritti; eccovi dunque il video dell’ottima intervista fatta da Matteo Flora a Marianna Vintiadis

Godetevi il video:

La Russia si disconnette da Internet

URSS_disconnect_internet

La Russia di disconnette da Internet

Negli ultimissimi giorni, campeggia su molte testate occidentali (quali webnews, wired….) la notizia per cui la Russia si starebbe preparando ad affrontare un “test” molto particolare, soprattutto in questa era di Internet mondiale, secondo cui dovrebbero “disconnettere l’intera nazione da Internet” cosi da poter verificare la loro “capacita’ di rispondere ad un’eventuale attacco cyber” , testando al tempo stesso l’autonomia e la sicurezza della loro rete interna (Runet).

A riportare questa notizia e’ stato un’articolo comparso sul sito dell’agenzia di stampa russa RBK .

Questa idea, nata gia nel 2017, e’ scaturita in una proposta di legge presentata a fine 2018, che ha come scopo quello di creare misure protettive per lo spazio internet russo entro il 2020.

L’attuazione di questo progetto di legge potrebbe cambiare radicalmente il sistema di organizzazione dello scambio di traffico internet del paese, in quanto sarà il servizio federale per la supervisione delle comunicazioni  (Roskomnadzor) a decretare in quali punti di scambio esso dovrà passare e come dovra’ essere gestito.

Per la messa in opera, in tempi brevi, di questo progetto anche il governo russo ha dovuto aggiungere alcune modifiche al decreto di legge, tra le quali , l’accettazione da parte del governo russo di coprire i costi che gli ISP dovranno sostenere per aggiornare tutte le infrastrutture ed installare i nuovi server.

A guidare questo gruppo di lavoro, secondo quanto riferiscono i media russi, c’è Natalya Kaspersky, direttrice della società di sicurezza informatica russa Info Watch e cofondatrice di Kaspersky Lab.

La disconnessione dal resto del mondo, si apprende da alcune fonti russe, dovrebbe avvenire attorno ad aprile 2019, anche se non è stata ancora comunicata la data ufficiale, ma se il test dovesse dare i risultati auspicati dalle autorità russe, il Governo di Mosca darà continuità al progetto, sino ad arrivare all’obiettivo finale di “autodeterminazione” della Rete.

Il governo ha anche affermato che, secondo una loro previsione, entro il 2020 il 95% del traffico Internet generato in Russia sarà instradato attraverso server locali e non uscirà mai al di fuori dei confini della confederazione di stati.

Il costo previsto per l’intera operazione è di oltre 20 miliardi di rubli (circa 27 miliardi di euro). L’obiettivo finale è di sviluppare un controllo del traffico web, sulla falsa riga del sistema di censura “Great Firewall” della Cina.

In ultima analisi si potrebbe intravedere in questo test, una possibile risposta alle accuse mosse alla Russia da parte della NATO di essere una delle responsabili degli attacchi alla cyber sicurezza di altre nazioni, e un modo per avvicinarsi alla “sovranità delle rete” cinese che rientra in quella comunione di intenti stretta nel 2016 tra Vladimir Putin e Xi Jinping, segretario generale del Partito Comunista Cinese, quando le due potenze mondiali siglarono un accordo sullo sviluppo dell’informazione nei rispettivi Paesi.

#WarGames

Difenditi con ARTILLERY

Artillery Honeypot All-in-one

Artillery Honeypot All-in-one

In questo articolo parleremo di un tool che si pone come interessante aiuto verso la sicurezza delle nostre macchine in rete, il suo nome e’ Artillery , esso è un interessante software scritto interamente in python. La cosa molto interessante di questo tool e’ che lo possiamo intendere come una combinazione tra un honeypot, un tool di monitoraggio, ed un sistema di alerting. Uahoooo, tutto in un’unico strumento…….

I principi di funzionamento si caratterizzano dal fatto che in presenza di determinate attività di networking esso si comporta parzialmente come un honeypot, adottando anche manovre evasive e, contemporaneamente monitorizza il cambiamento di file sensibili; in entrambi i casi avvisando di quanto riscontrato i destinatari designati.
Artillery si pone in ascolto su di un certo numero di porte di uso comune (peraltro configurabile, tramite la variabile PORTS), e qualora riceva una richiesta di connessione per uno qualsiasi dei servizi fasulli, blocca in modo permanente l’indirizzo IP sorgente aggiungendo una relativa regola con target DROP a iptables.

Artillery può essere anche usato per prevenire attacchi di tipo brute force

L’ installazione ed il lancio di Artillery sono molto semplici: una volta effettuato il download via git, occorre lanciare uno script installer, editare un file di configurazione (“all’inizio questo passaggio sara’ meglio farlo su macchina virtuale per fare pratica della configurazione delle regole”) e poi mandarlo in esecuzione:

# cd /opt
apt-get update && apt-get install git [solo se ancora non avete installato il pacchetto git]
# git clone https://github.com/trustedsec/artillery/ artillery/
# cd artillery
# sudo ./setup.py

Welcome to the Artillery installer. Artillery is a honeypot, file monitoring, and overall security tool used to protect your nix systems.

Written by: Dave Kennedy (ReL1K)

Do you want to install Artillery and have it automatically run when you restart [y/n]: y
[*] Beginning installation. This should only take a moment.
[*] Adding artillery into startup through init scripts..
[*] Triggering update-rc.d on artillery to automatic start…
Do you want to keep Artillery updated? (requires internet) [y/n]: y
[*] Checking out Artillery through github to /var/artillery
Cloning into ‘/var/artillery’…
remote: Counting objects: 876, done.
remote: Total 876 (delta 0), reused 0 (delta 0), pack-reused 876
Receiving objects: 100% (876/876), 207.83 KiB | 293.00 KiB/s, done.
Resolving deltas: 100% (568/568), done.
Checking connectivity… done.
[*] Finished. If you want to update Artillery go to /var/artillery and type ‘git pull’
Would you like to start Artillery now? [y/n]: y
Starting Artillery… Ok
[*] Installation complete. Edit /var/artillery/config in order to config artillery to your liking..

Durante il processo di installazione verranno poste, come potete leggere qui sopra, alcune domande:
Do you want to install Artillery and have it automatically run when you restart [y/n]:
Do you want to keep Artillery updated? (requires internet) [y/n]:
Would you like to start Artillery now? [y/n]:

Artillery verrà installato come servizio sotto /etc/init.d/
E’ sempre consigliabile leggere con attenzione prima d’ impostare il file di configurazione.
In ogni caso, una volta effettuate delle modifiche alla configurazione, si può impartire e renderle immediatamente operanti:
# python restart_server.py

Fate attenzione a non commettere l’errore di editare invece i files risultanti dal download via git. Una volta che che lo script di installazione sia stato eseguito, per modificarne la configurazione posizionatevi piuttosto nella directory /var/artillery.

Il contenuto del file config è piuttosto chiarificatore delle funzionalità del software:
# determina se attivare l’attività di monitoraggio dell’integrità di files sensibili
MONITOR=YES
#
# le directories da monitorare, se ne possono ancora aggiungere “/root”,”/var/”, ecc.
MONITOR_FOLDERS=”/var/www”,”/etc/”
#
# frequenza del controllo in secondi.
MONITOR_FREQUENCY=60
#
# esclusione dal controllo per certe directories o files, ad esempio: /etc/passwd,/etc/hosts.allow
EXCLUDE=
#
# determina se attivare l’attività di HONEYPOT
HONEYPOT=YES
#
# ban automatico HONEYPOT
HONEYPOT_BAN=YES
#
# WHITELIST di indirizzi IP non vincolati dalle regole di controllo
WHITELIST_IP=127.0.0.1,localhost
#
# PORTS su cui attivare il monitoring
PORTS=”135,445,22,1433,3389,8080,21,5900,25,53,110,1723,1337,10000,5800,44443″
#
# determina se attivare l’alerting via email
EMAIL_ALERTS=OFF
#
# username SMTP
USERNAME=”thisisjustatest@gmail.com”
#
# password SMTP
PASSWORD=”pass”
#
# destinatario
SMTP_TO=”testing@test.com”
#
# server per l’invio, per default gmail
SMTP_ADDRESS=”smtp.gmail.com”
#
# Porta SMTP per l’invio. Di default è quella gmail con TTLS
SMTP_PORT=”587″
#
# Indirizzo EMAIL su cui ricevere gli ALERTS
ALERT_USER_EMAIL=”user@whatever.com”
#
# determina se l’invio delle email di alerting debba avvenire seguendo una certa frequenza. Se impostato a off, gli alerts
# verranno inviati automaticamente in tempo reale (può significare un mucchio di spam)
EMAIL_TIMER=ON
#
# la frequenza con la quale saranno inviati gli ALERTS per email (per default ogni 10 minuti)
EMAIL_FREQUENCY=600
#
# Attivazione del monitoraggio dei tentativi BRUTE FORCE contro SSH
SSH_BRUTE_MONITOR=ON
#
# Quanti tentativi prima del BAN
SSH_BRUTE_ATTEMPTS=4
#
# Per effettuare degli aggiornamenti automatici
AUTO_UPDATE=OFF
#
# ANTI DOS imposta la macchina a limitare le connessioni, e va impostato ad OFF nel caso non lo si intenda utilizzare
ANTI_DOS=ON
#
# Le porte dotate di protezione ANTI-DOS
ANTI_DOS_PORTS=80,443
#
# I parametri che limitano le connessioni come misura anti DOS
ANTI_DOS_THROTTLE_CONNECTIONS=50
ANTI_DOS_LIMIT_BURST=200
#

Artillery ha un set di porte (comuni o comunemente attaccate) preimpostato sulle quali si pone in ascolto.
A rivelarle basta un semplice:

# netstat -antp |grep LISTEN
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 827/dnsmasq
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 637/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 706/cupsd
tcp 0 0 0.0.0.0:1433 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:1337 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:90 0.0.0.0:* LISTEN 734/nginx -g daemon
tcp 0 0 0.0.0.0:44443 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:1723 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:47323 0.0.0.0:* LISTEN 616/rpc.statd
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:3389 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:135 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:5800 0.0.0.0:* LISTEN 2428/python
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 1089/mysqld
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 606/rpcbind
tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 2428/python
tcp6 0 0 :::53 :::* LISTEN 827/dnsmasq
tcp6 0 0 :::22 :::* LISTEN 637/sshd
tcp6 0 0 ::1:631 :::* LISTEN 706/cupsd
tcp6 0 0 :::46327 :::* LISTEN 616/rpc.statd
tcp6 0 0 :::90 :::* LISTEN 734/nginx -g daemon
tcp6 0 0 :::111 :::* LISTEN 606/rpcbind
tcp6 0 0 :::80 :::* LISTEN 1153/apache2

P.S.: L’esclusione dell’indirizzo IP che non riesca ad autenticarsi validamente viene effettuata attraverso il controllo del file /var/log/auth.log (per le distribuzioni basate su Debian).

Il tool e’ potente ed altamente configurabile; non rimane che dare un’occhiata alla configurazione e fare qualche prova, magari all’inizio giocando con qualche servizio aperto su di una VM.

 

PENETRATION TEST

Penetration Test

Penetration Test

 

Oggi giorno tutto e’ e sara’ sempre piu’ connesso o interconnesso in rete, dalle nostre vite sociali, ai dati aziendali fino all’ultima frontiera rappresentata dall’Internet delle Cose IoT, che è un neologismo riferito all’estensione di Internet al mondo degli oggetti e dei luoghi concreti.

Tutto questo scambio continuo di dati (foto, login, codici…) richiede che le aziende incaricate di mantenere al sicuro i nostri dati piu’ importanti debbano essere sempre preparati dal pericolo sempre maggiore di un’intrusione, in effetti il comportamento non sarebbe diverso da una squadra di vigili del fuoco che si allenano costantemente simulando ogni tipologia di situazione cosi da sapere sempre cosa fare, come risolvere e se possibile come prevenire un disastro.

Una delle metodologie a cui dovrebbero affidarsi i team di sicurezza interni, o tramite specifiche consulenze, sono i cosidetti PENETRATION TEST.
Che cosa s’intende quando si usa questo termine? Il penetration test è la metodologia di valutazione della sicurezza di un sistema o di una rete. L’analisi comprende più fasi ed ha come obiettivo evidenziare le debolezze della piattaforma fornendo il maggior numero di informazioni sulle vulnerabilità che ne hanno permesso l’accesso non autorizzato. L’analisi è condotta dal punto di vista di un potenziale attaccante e consiste nello sfruttamento delle vulnerabilità rilevate al fine di ottenere più informazioni possibili per accedere in modo fraudolento al sistema. Un pen-test dunque consiste nel testare la sicurezza di un sistema cercando di violarlo sottoponendolo ad una grande varietà di attacchi informatici e non. L’obiettivo è quello di individuare eventuali vulnerabilità sfruttabili da terzi per ottenere accessi non autorizzati ai servizi e ai sistemi analizzati.

Oltre ai problemi di sicurezza, devono essere rilevati, quali possibili punti deboli, i problemi relativi alla configurazione, il cosidetto “tuning“, che incidono sulla robustezza e le performance del sistema, e gli errori di progettazione della rete. Non a caso, a volte una cattiva configurazione è più pericolosa di un bug.

Questa e’ una lista sintetica che descrive cio che un pen-tet cerca d’individuare:

  • bug, vulnerabilità e security hole nel software presente;
  • punti deboli nella progettazione della rete;
  • punti deboli di firewall e router;
  • punti deboli negli script dei web-server;
  • errori nella configurazione dei principali servizi in esecuzione;
  • problemi relativi l’accesso fisico alle macchine.

Una volta portato a termine il test, tutti i problemi di sicurezza rilevati vengono presentati al cliente o alla propria direzione informatica assieme ad una valutazione del loro impatto nel sistema e nello scenario del business aziendale, fornendo inoltre una soluzione tecnica o proposta di migrazione e mitigazione del sistema.

Il penetration test ci fornisce quindi una stima chiara sulle capacità di difesa e del livello di penetrazione raggiunto nei confronti di problematiche quali:

  • vulnerabilità interne al sistema;
  • vulnerabilità esterna al sistema;
  • difetti sicurezza fisica

Quali sono le modalita’ in cui i Penetration Tester svolgono il loro ruolo ??
I processi di penetration test possono essere effettuati in diverse modalità. La differenza consiste sulla quantità e qualità delle informazioni disponibili a coloro che devono effettuare l’analisi riguardo ai sistemi analizzati. I processi di analisi che vengono condotti in un penetration test hanno diversi tempi di azione in cui vengono alternate fasi manuali e fasi automatiche. Vengono acquisite inizialmente le informazioni principali sull’architettura della piattaforma e sui servizi offerti. Dall’analisi di questi dati deriva la scelta di come condurre il passo successivo, consistente in una enumerazione dei principali errori e problemi. Subentrano cosi nell’equazione i Penetration Tools che, uniti all’esperienza manuale dell’analista permettono quindi di evidenziare tutte le possibili vulnerabilità, incluse quelle più recenti e, a volte, alcune ancora non di pubblico dominio. I problemi riscontrati sono quindi manualmente verificati.

L’attività si considera conclusa una volta portata a termine la reportistica composta dal report di analisi sommaria dedicato al management o executive summary, contenente l’analisi dell’impatto di rischio di quanto riscontrato e tempistiche per l’azione di rientro o mitigazione delle problematiche riscontrate, e dal report tecnico, contenente l’analisi dettagliata dei problemi e la soluzione tecnica.

Va aggiunto per maggiore chiarezza che il penetration test va effettuato su sistemi esposti su Internet e comunque sulle piattaforme sensibili collegate a grosse reti, testando le vulnerabilita’ sia con attacchi esterni alla rete che con attacchi dall’interno della stessa e, possibilmente gia prima prima che esse entrino nella fase di completo esercizio.
Possiamo distinguere vari livelli tecnici dei test, piu’ a grandi linee si possono delineare tre grandi categorie:

  • livello basso: questo è il test che in genere fanno i tool di auditing automatici, a la Nessus per intenderci. Si controlla solo se ci sono servizi in esecuzione con vulnerabilità note, in genere vengono rilevate solo grosse falle e misconfigurazioni macroscopiche.
  • livello medio: oltre a controllare i servizi in esecuzione, viene testata la rete, i firewall, i router, etc…, e si fa spesso ricorso anche a tecniche di social engineering.
  • livello alto: qui siamo a livelli paranoici, si può arrivare a controllare i sorgenti (se disponibili) dei programmi alla ricerca di nuove vulnerabilità (quindi meglio optare per software open source e li dove e’ possibile per far sviluppare internamente cio di cui si ha bisogno), o ad esercitare la tecnica denominata del trashing detto anche information diving, che è la pratica di risalire ad informazioni riservate attraverso il setacciamento dei rifiuti della vittima, come resoconti, bollette, corrispondenza. Una delle tecniche preferite dal famoso Kevin Mitnick.

Mettendo insieme tutte queste metodologie ed informazioni possiamo darvi un piccolo scenario di cio che viene eseguito, a grandi linee, durante un’attacco:

  • Ricognizione di base: informazioni dal sito, informazioni sul dominio e sull’amministratore. A volte basta visitare il sito per raccogliere importanti notizie sul software presente sul server, spesso infatti in fondo all’home page i webmaster inseriscono notizie sul sistema operativo, webserver, etc…., come ad esempio trovare indicazioni come queste “Powered by Apache, Linux Inside…” , mettono a rischio i sistemi.
  • Ricostruzione della struttura interna della rete
  • Raccolta Info:Una volta identificata la struttura della rete e il numero di macchine bisogna raccogliere il maggior numero di informazioni su ognuna di esse. Quindi occorre ricercare i servizi in esecuzione, identificare i sistemi operativi, la versione dei servizi, il tipo di processore, i nomi utente (standard e non), le risorse condivise, etc.
  • Tracciamento vulnerabilita‘: dopo aver determinato i tipi di servizi attivi sull’host bersaglio si deve tracciare una mappa delle vulnerabilità, e occorre ricercare (o scrivere) gli exploit applicabili contro i servizi bersaglio.
  • Analisi della topologia della rete.
  • Applicazione degli exploit.
  • Verifica della possibilità di sniffing e tentativi di DoS & DDoS.
  • Test su router e firewall.
  • Pulizia delle tracce dell’attacco.
  • Stesura del report.

Al termine degli attacchi e della valutazione dei log raccolti un sistema potra’ dirsi vulnerabile se è possibile:

  • accedere a risorse interne;
  • leggere e modificare file riservati;
  • controllare il traffico in entrata e/o uscita;
  • eseguire programmi senza averne i permessi;
  • accedere alla macchina con i permessi di amministratore (root) da parte di utenti non privilegiati;
  • controllare la configurazione della rete e dei servizi.

Punti critici:
cerchiamo ora di evidenziare i lati negativi del preparare un pen-test che purtroppo e’ un po come fare i lavori di casa mentre voi ci abitate dentro……
I punti critici da prendere in considerazioni sono: trattamento dei dati raccolti, salvaguardia dei sistemi e dei dati, riservatezza riguardo le vulnerabilità emerse durante il pen-test. Durante il penetration test potrebbero verificarsi dei disagi dovuti al lavoro del tester, si potrebbero avere perdite o danni ai dati o ancora una momentanea perdita di accessibilità. Ad esempio una macchina dedicata all’e-commerce potrebbe rimanere inaccessibile a causa di una simulazione di un DoS, con conseguenze economiche dirette. O ancora, una azienda che fornisce servizi a terzi, potrebbe vedere i propri servizi interrotti con evidente disagio per i clienti.
Prima di cominciare il test bisogna concordare quale livello di rischio il committente è disposto a correre, invitandolo anche a fare un backup dei dati prima di effettuare il pen-test. Bisogna prevedere tali evenienze in fase di stipula del contratto, declinando per quanto possibile le responsabilità e garantendo però, allo stesso tempo, adeguate misure per il recupero del sistema.

Per ultimare questa carellata sul valore di un Pen-test aggiungo che il suo valore è strettamente legato alle capacità del tester, dunque affidiamoci soltanto a persone preparate che possono dimostrare esperienza pratica svolta su clienti tracciabili; inoltre esso perde di validità non appena si apportano modifiche (anche minime) alla configurazione di una macchina interessata al test, quindi è consigliabile eseguire un pen-test poco prima di mettere in produzione la rete. Inoltre anche lasciando inalterate le macchine testate, il pen-test dovrebbe essere ripetuto periodicamente, poichè oggi giorno vengono trovate quotidianamente nuove vulnerabilità e nuovi exploit.

Semplificate i vostri Firewall

Ipset facilita il Firewall

Ipset facilita il Firewall

Facilitare la gestione del Firewall usando IPSET

Premessa
iptables, che fa parte del più ampio framework netfilter, è notoriamente il tool in user-space destinato alla definizione delle regole di firewall del kernel Linux.

Ipset è una estensione per iptables che permette la creazione di regole firewall applicabili contemporaneamente ad interi insiemi di indirizzi. A differenza di quanto avviene nelle normali catene iptables, che sono memorizzate e traversate linearmente, i sets sono memorizzati in strutture dati indicizzate, caratteristica che ne rende la consultazione molto efficiente, anche in presenza di sets voluminosi, oltre che in situazioni dove è facile immaginarne l’utilità, come il blocco di lunghe liste di “bad” hosts senza doversi preoccupare dell’eccessivo impiego di risorse di sistema o della congestione di quelle di rete, ipset offre anche un nuovo approccio a determinati aspetti inerenti la progettazione di un firewall, semplificandone la configurazione.

Ipset e’ composto da due parti, un modulo kernel e, uno strumento di amministrazione, alcune distribuzioni includono anche dei wrapper di servizio per caricare configurazioni ipset al boot, come l’ipset-service di Fedora.

Prima di proseguire è doveroso spendere un po’ di tempo a rinfrescare alcuni concetti fondamentali di iptables.

In sintesi, la configuratione di un firewall iptables consiste di un set di “chains” built-in (raggruppate in quattro “tables”) che contengono ciascuna una lista di regole o “rules”.

Per ciascun pacchetto, in ciascuna fase del suo trattamento, il kernel consulta la chain appropriata per determinarne il destino.
Le chains vengono consultate in rigoroso ordine, basato sulla direzione del pacchetto (remoto->locale, remoto->remoto oppure locale->remoto) e la sua fase corrente di trattamento o processing (prima o dopo il “routing”).

Il pacchetto viene confrontato con ciascuna delle regole della chain, nell’ ordine, fino a che non viene trovata una corrispondenza. Una volta che ciò avviene, viene intrapresa la azione specificata nel target della regola.
Se viene invece raggiunta la fine della chain senza trovare una corrispondenza, viene intrapresa la azione target di default per la catena, o policy.

Una chain non è altro che una lista ordinata di regole, ed una regola non è altro che una combinazione corrispondenza/target.
Un semplice esempio di corrispondenza è “TCP destination port 25″.
Un semplice esempio di target può essere “scarta il pacchetto” (DROP).
I targets possono anche redirigere ad altre chains definite dall’utente, cosa che fornisce un meccanismo per raggruppare e suddividere le regole seguendo una logica.
Ciascun comando iptables destinato a definire una regola, corto o lungo che sia, è composto di tre parti fondamentali che specificano la table/chain, la corrispondenza (match) ed il target

Per creare una completa configurazione firewall, occorre di fatto mandare in esecuzione una serie di comandi iptables, in uno specifico ordine.

ipset
ipset è una “match extension”, cioè una estensione basata sulla definizione di corrispondenze, per iptables.
Per poterla usare è prima necessario creare e popolare dei “sets” univocamente chiamati utilizzando il tool a linea di comando ipset, e successivamente fare riferimento a tali sets in una o più regole iptables.

Un set può essere semplicemente una lista di indirizzi archiviata per un efficiente ritrovamento.
Prendiamo come riferimento i seguenti normali comandi iptables destinati a bloccare il traffico in ingresso proveniente da 201.121.12.1 e 202.121.12.2:

# iptables -A INPUT -s 201.121.12.1 -j DROP
# iptables -A INPUT -s 202.121.12.2 -j DROP

La sintassi che specifica la corrispondenza (-s 201.121.12.1) significa “i pacchetti il cui indirizzo di origine è 201.121.12.1″. Per bloccare sia 201.121.12.1 che 202.121.12.2, devono venire definite due distinte regole iptables con due distinte specificazioni di corrispondenza (una per 201.121.12.1 ed una per 202.121.12.2).

In alternativa, i seguenti comandi ipset/iptables servono ad ottenere lo stesso risultato:

# ipset -N myset iphash
# ipset -A myset 201.121.12.1
# ipset -A myset 202.121.12.2
# iptables -A INPUT -m set --set myset src -j DROP

I comandi ipset appena visti creano un nuovo set (myset, del tipo iphash) con due indirizzi (201.121.12.1 e 202.121.12.2).
Il successivo comando iptables fa quindi riferimento al set specificando la corrispondenza con -m set –set myset src, che significa “i pacchetti il cui source header è compreso nel set di nome myset”.
Il flag src significa che la corrispondenza deve avvenire su “source”. Analogamente il flag dst avrebbe spostato la corrispondenza su “destination”, mentre il flag src,dst avrebbe riguardato sia source che destination.

Nella seconda versione è richiesto un solo comando iptables, indipententemente da quanti indirizzi IP siano presenti nel set.
Anche se fossero migliaia, sarebbe necessaria sempre una singola regola iptables, mentre l’approccio tradizionale, senza il vantaggio offerto da ipset, richiederebbe migliaia di regole.

Tipi di set
Ciascun set è di uno specifico tipo, che definisce che genere di valore possa esservi memorizzato (indirizzi IP, networks, porte ecc.) così come debba essere ricercata la corrispondenza (ovvero, quale parte del pacchetto debba essere controllata e come debba essere confrontata coi valori presenti nel set).
Oltre ai tipi più comuni, che controllano gli indirizzi IP, ne sono disponibili addizionali che si riferiscono alla porta, sia all’indirizzo IP che alla porta contemporaneamente, oppure contemporaneamente al MAC address e all’indirizzo IP, ecc.

Ciascun tipo di set ha le proprie regole per tipo, range e distribuzione dei valori che può contenere.
Differenti tipi di set usano anche differenti tipi di indici e risultano ottimizzati per differenti scenari. La scelta del migliore o più efficiente tipo di set dipende quindi dalla situazione.

I tipi più flessibili di set sono iphash, che archivia liste di indirizzi IP arbitrari, e nethash, che archivia liste di networks eterogenee (IP/mask) di varie dimensioni. Si faccia comunque riferimento all man page di ipset per un elenco completo ed una descrizione di tutti i tipi di set.

È anche disponibile il tipo speciale setlist, che consente di raggruppare insieme differenti sets in un set unico.
È vantaggioso se si desidera, ad esempio,avere un singolo set che contenga sia singoli indirizzi IP che networks.

Faccio ora un esempio per capire meglio la potenza di ipset:

Limitare l’accesso restringendolo solo a certi hosts pubblici da parte di certi PC della rete locale
Supponiamo che nell’ufficio di cui gestite la rete passino spesso stagisti e che il megadirettore sia molto infastidito dall’idea che questi impiegati, Pippo, Pluto e Paperino possano passare il tempo a trastullarsi con Internet invece di lavorare e vi chieda di limitare l’accesso da parte dei loro PCs a uno specifico set di siti cui è necessario collegarsi solo per lavoro.
Per limitare i tre PC (192.168.0.5 è quello di Pippo, 192.168.0.6 quello di Pluto e 192.168.0.7 quello di Paperino) ad accedere solamente a corriere.it, repubblica.it e inps.it, si possono utilizzare i seguenti comandi:

# ipset -N limited_hosts iphash
# ipset -A limited_hosts 192.168.0.5
# ipset -A limited_hosts 192.168.0.6
# ipset -A limited_hosts 192.168.0.7
# ipset -N allowed_sites iphash
# ipset -A allowed_sites corriere.it
# ipset -A allowed_sites repubblica.it
# ipset -A allowed_sites inps.it
# iptables -I FORWARD \
-m set --set limited_hosts src \
-m set ! --set allowed_sites dst \
-j DROP

Questo esempio effettua un confronto con due sets in una singola regola. Se il l’indirizzo sorgente è compreso in limited_hosts e la destinazione non è compresa in allowed_sites, il pacchetto viene semplicemente scartato (a limited_hosts è permesso comunicare solamente con allowed_sites).

Si noti che dato che questa regola si trova nella chain FORWARD, non riguarda le comunicazioni da e verso il firewall stesso nè il traffico interno.

Cosi’ come per iptables, ipset vi permette di caricare le regole da un file ed effettuare l’output in un formato adatto al caricamento, nel seguente modo :

# ipset save > /path/to/ipset.save
# ipset restore < /path/to/ipset.save

Ipset vi permettera’ di mantenere la configurazione del vostro firewall piu’ corta, leggibile e molto piu’ facile da mantenere. Se vi servono ulteriori informazioni potete visitare il sito del progetto http://ipset.netfilter.org

 

#IpsetfacilitailvostroFirewall