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.