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.

 

CoreOS ed uso nei Datacenter

CoreOS Docker Cluster

CoreOS Docker Cluster

Ormai l’ho capito, dai tanti esempi di storie di successo in campo informatico che, le migliori invenzioni si realizzano nei garage. Così come i due famosi Steve furono capaci di creare da zero il primo Mac, così i creatori di Google concepirono il loro motore di ricerca proprio in un garage o giu’ di li. La storia che si sente inizia sempre cosi :
“Qualche anno fa, in un garage della Silicon Valley…” etc… ; ma cosa ci sarà mai in questi garage americani ?!?


Nasce così CoreOS

CoreOS è praticamente una leggerissima distribuzione Linux solo con kernel e systemd. Questa distribuzione, che effettua il boot in un paio di secondi, è pensata per chi deve realizzare e gestire cluster di centinaia, addirittura migliaia, di nodi. Praticamente permette di realizzare, con hardware di proprietà, un’infrastruttura IT come quella di Amazon o Google. Oltre ad essere già disponibile sui sistemi cloud di Amazon, di Rackspace e di Google ultimamente anche Microsoft ne ha annunciato la disponibilità su Windows Azure.

Il prodotto è davvero interessanteinfatti, in poco tempo ha avuto migliaia di raccomandazioni su GitHub ed una cifra compresa tra uno e cinque milioni di dollari da gruppi di investimento privati.

CoreOS, il cui codice è interamente disponibile su GitHub, è fortemente basato sudocker“, etcd e systemd oltre ad avere un sistema di aggiornamento del sistema operativo sottostante molto innovativo chiamato FastPatch:

FastPatch aggiorna l’intero sistema operativo in un’unica soluzione, non i singoli pacchetti, su uno schema di partizioni attivo/passivo e siccome le applicazioni e le configurazioni risiedono in ambienti completamente separati e indipendenti, non si corre il rischio di lasciare alcuni nodi del cluster in uno stato di inconsistenza.

Quindi se la vostra esigenza è quella di creare un cluster, CoreOS rappresenta davvero un’ottima scelta.

Nel prossimo articolo vedremo come creare un cluster CoreOS con Vagrant .

 

#CoreOSsistemaclusteravanzato

Controlliamo la velocita’ della nostra rete da terminale

speedtest-cli

Speed Test da Terminale

In questo articolo vedremo come effettuare uno speed test senza aprire il browser ed usando solo il terminale.

Premessa
Saper usare i molti comandi offerti dalla shell sul nostro terminale offre sicuramente enormi potenzialità, nonostante un primo impatto non sempre amichevole, con questo valido strumento avremo sempre il pieno controllo delle funzionalità di una distribuzione Linux, su cui potremo fare qualsiasi cosa senza usare interfacce grafiche.

Se per esempio vogliamo conoscere in tempo reale la velocità della nostra linea ADSL normalmente dovremmo aprire il browser, digitare un sito per effettuare la prova di velocità (per esempio speedtest.net) ed attendere il risultato; invece con la seguente mini guida utilizzeremo solo ed esclusivamente il terminale per effettuare lo stesso tipo di test di velocità sulla nostra linea.

Impariamo ad usare speedtest-cli, un piccolo tool che utilizza il popolare sito speedtest.net.

Il tool possiede gia di per se un lungo elenco di server disponibili per il test, divisi in ordine di distanza, ed è possibile utilizzarlo per testare il ping su un server specifico o connettersi agli Speedtest Mini server; mentre per gli utenti meno esigenti è possibile generare automaticamente un URL con l’immagine dello Speedtest ed i risultati ottenuti.

Installazione
Speedtest-cli può essere installato utilizzando Python Pip. Per installare Pip su Ubuntu (dalla 13.10 e successive, ma sono supportate anche le versioni precedenti), dovremo lanciare il seguente comando da terminale:

# sudo apt-get install python-pip

Usiamo quindi Pip per installare speetest-cli

# sudo pip install speedtest-cli

Per il futuro, quando si desidererà aggiornare speedtest-cli, potremo utilizzare il seguente comando:

# sudo pip install speedtest-cli --upgrade

Se non siete su Ubuntu esistono altri modi per installare speedtest-cli, basta visitare la pagina GitHub del programma.

Controllare la velocità della rete da terminale
Per testare la velocità di connessione a Internet da riga di comando utilizzando il miglior server (basato su ping) tutto quello che dovete fare è eseguire il seguente comando:

# speedtest-cli

Nota: il tool funziona anche con il comando speedtest invece di speedtest-cli (se avete installato lo strumento utilizzando Python Pip). Nei successivi comandi useremo il comando più corto per facilitare la digitazione.

Esempio di test rete adsl casalinga :

# speedtest-cli
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Vodafone DSL (88.xx.xx.xx)...
Selecting best server based on latency...
Hosted by ColocationIX (Berlin) [5.80 km]: 51.852 ms
Testing download speed........................................
Download: 7.65 Mbits/s
Testing upload speed..................................................
Upload: 2.51 Mbits/s

Il tool è estremamente flessibile e permette di impostare degli argomenti per svolgere ulteriori test. Per esempio è possibile testare la velocità di Internet ed ottenere automaticamente un link con l’immagine da condividere ovunque utilizzando il comando:

# speedtest --share # (che creera' un URL con un'immagine sul portale di speedtest.net)

Per un uso più avanzato, come la visualizzazione dei server di speedtest.net, il collegamento ad un determinato server e così via, possiamo leggere la guida indicata con il seguente comando:

# speedtest -h

Buon Test !

#speedtestsenzabrowserusandosoloilterminale

Twemproxy il proxy per Memcached

twemproxy2

Twemproxy (repository GitHub) è un proxy server che consente di ridurre il numero di connessioni aperte verso un server Memcached o Redis. Per cosa può essere utile questo strumento?

 

 

Le caratteristiche principali sono :

– ridurre il numero di connessioni al cache server agendo come un proxy;

– sharding di dati automatico tra più cache server;

– supporto per l’hash con diverse strategie e funzioni di hashing;

– configurabile per disabilitare i nodi caduti;

– esecuzione di istanze multiple, consentendo al client di connettersi al primo proxy server disponibile;

– pipelining e batching di richieste con risparmio di round-trip;

– configurabile per disabilitare i nodi non più funzionanti, e richiamarli successivamente, dopo un po’ di tempo;

Twemproxy è stato reso open source da Twitter (che lo ha sviluppato per le proprie esigenze) all’inizio del 2012, con il supporto a memcached, e recentemente ha aggiunto anche il supporto a Redis. Twitter fa uso estensivo dei cache server ed il sistema sul quale gira Twemproxy, per Twitter, è di dimensioni impressionanti; immaginate che i sistemisti devono gestire centinaia di cache server, che a loro volta amministrano svariati TB di dati ciascuno per oltre trenta servizi diversi, in-memory, inclusa la memorizzazione dei tweet. Parliamo di almeno due milioni di miliardi di query al giorno, ossia più di ventitré milioni di query al secondo, per un’infrastruttura che, peraltro, continua a crescere in maniera esponenziale.

Leggi anche articolo (“Ottimizzazre grazie a Memcached“)

 

Metasploit Framework

metasploit_logoTestiamo la nostra Sicurezza

Oggi giorno sempre piu’ servizi sono online e tra questi troviamo anche cose importanti come la gestione del conto bancario oppure il nostro profilo INPS ecc….; tutto cio’ e’ molto comodo ma e’ anche piu’ facile che una falla sui sistemi che usiamo possa rendere facile a persone poco raccomandabili di intercettare qualche nostro dato “sensibile” per poi servirsene a piacimento.

Certamente molti di noi si affidano al fatto che confidiamo nell’alto livello di sicurezza dei gestori di questi servizi, ma pochi pensano che in ogni conversazione, compresa quella tra computer in un luogo pubblico come Internet, deve avere entrambi i soggetti SICURI , quindi come fare per essere certi il piu’ possibile (dato che sicuro e’ morto) che noi per primi siamo esenti da bug ???? Un buon metodo e’ tenersi sempre aggiornati sui bug piu’ noti e pericolosi e poi testare la propria macchina. Il metodo migliore per farlo e’ quello di usare un Framework come Metasploit.

I metodi per usare Metasploit sono tanti e disparati , dall’usare un Live-CD, installarlo su di una Pen-Drive, creare una VM apposita ecc…
Stessa cosa si puo’ dire per i metodi d’installazione del Framework in questione quindi vi descrivero’ quello che preferisco e che trovo piu’ funzionale.

INSTALLAZIONE

mkdir git
cd git
git clone https://github.com/mcfakepants/metasploit-framework.git

…..a questo punto potete verificare cosa e’ stato scaricato nella DIR entrandoci e lanciando un ls -L
il risultato dovrebbe essere una lista come questa

git/metasploit-framework$ ls -L
config           external      modules     msfencode    msfrpcd    scripts
CONTRIBUTING.md  Gemfile       msfbinscan  msfmachscan  msfupdate  spec
COPYING          Gemfile.lock  msfcli      msfpayload   msfvenom   test
data             HACKING       msfconsole  msfpescan    plugins    tools
db               lib           msfd        msfrop       Rakefile
documentation    LICENSE       msfelfscan  msfrpc       README.md

a questo punto prima di lanciare la console di Metasploit per l’installazione conviene assicurarci di avere tutti i pacchetti per gli script in Ruby installati, per completare questa operazione possiamo lanciare il seguente comando :

gem install bundler

ora non ci rimane che lanciare l’installazione del Framework in questione tramite

sudo ./msfconsole -L

se dovessimo riscontrare un errore come questo: Could not find rake-10.0.4 in any of the sources potremo risolvere fermando l’installazione in corso con un Ctrl+C , ed eseguire, dalla stessa posizione in cui ci troviamo, il comando bundle install che installaera’ tutte le “GEMME” mancanti; rilanciamo pure l’installazione come prima con : # sudo ./msfconsole -L

Ci vorra’ qualche minuto per ultimare questa fase in quanto i pacchetti da scaricare sono diversi; al termine dell’installazione ci ritroveremo catapultati all’interno della console amministrativa di Metasploit, con una schermata di questo tipo

< metasploit >
 ------------
       \   ,__,
        \  (oo)____
           (__)    )\
              ||--|| *

=[ metasploit v4.9.0-dev [core:4.9 api:1.0] ]
+ -- --=[ 1288 exploits - 705 auxiliary - 203 post ]
+ -- --=[ 334 payloads - 35 encoders - 8 nops      ]

msf >

Ora tutto quello che ci rimane da fare e’ testare quelle criticita’ che ci sembrano piu’ rischiose e capire cosi’ se il nostro PC ne e’ affetto.

Una di quelle da verificare, per fare il nostro primo test, e’ quella relativa ad un bug nel parsing dei font presenti nei file SWF (i file Flash) di Adobe, grazie al quale un malintenzionato potrebbe essere in grado di eseguire codice malevolo sulla macchina della vittima fino ad arrivare ad ottenere il controllo di una shell remota, senza necessita’ di inserire una password. Questo bug e’ molto problematico in quanto colpisce tutti i sistemi operativi e tutti i PC che abbiamo installata una versione di Flash precedente alla 11.3

Per verificare se il vostro PC e’ affetto tornate nella console di metasploit ed eseguite il test lanciando la seguente stringa :

msf  > use exploit/windows/browser/adobe_flash_otf_font

Eseguendo questo exploit , metasploit costruira’ in pratica un falso webserver sulla vostra macchina locale, ed un finto client che va a leggere  una pagina HTML contenente un file SWF (che si trova nella cartella metasploit-framework/data/exploits/CVE-2012-1535), in modo da eseguire il test automaticamente.

In generale per avere più informazioni sull’utilizzo di qualsiasi comando basta invocare l’help dedicato:

msf > nomecomando -h

Vediamo adesso i comandi per interagire con le librerie di exploit e payload. Il primo da conoscere è show che serve per mostrare il contenuto delle librerie, ad esempio:

msf > show exploits

Con questo comando verrà stampata la lista di tutti gli exploit presenti.

Per visualizzare i payload similmente useremo:

msf > show payloads

Per cercare un elemento specifico possiamo servirci del comando search:

msf > search cve:2012 type:exploit app:client

Search utilizza keyword (type, app, platform, name, etc) per affinare la ricerca. Al solito è buona norma consultare l’help del comando per avere un’idea di tutte le sue funzionalità:

msf > search -h

Prossimamente verranno aggiunti su questo Blog altri articoli relativi ai Bug piu’ pericoli da testare grazie a Metasploit, fino ad allora buona pratica e buon divertimento.

Vedi anche precedente articolo KaliLinux