Il miracoloso NodeJS

piattaforma Open Source event-driven

NodeJS – una piattaforma Open Source event-driven

Ok, ammetto che fino a non molto tempo fa mi ero quasi scordato di Javascript, nonostante fosse stato uno dei primi linguaggi da me studiati, nel lontano 1997, quando mi approcciai al mondo del web; negli anni successivi pero’, non essendo io uno sviluppatore, le tecnologie di gestione e deploy dei server web che dovevo gestire si erano spostate verso un grande quantitativo di linguaggi, in particolare per la parte back-end , passando cosi dal php, perl, python, java, ruby, lua etc……

Come stavo dicendo, per me javascript era rimasto in sordina come un linguaggio di scripting che intercorreva tra l’hmtl ed il css, nella composizione piu’ o meno dinamica di una pagina web ,prima che i pesi massimi sopra citati entrassero in campo per svolgere il duro lavoro.

Poi, un giorno, a ciel sereno……BOOOOOOOMMMM ! scopro l’esistenza di NodeJS, ed iniziai a chiedermi a cosa si dovesse tutto l’interesse di cui stavo leggendo; scopro quindi che NodeJS e’ una piattaforma Open Source event-driven per l’esecuzione di codice JavaScript Server-side, costruita sul motore V8 di Google Chrome. Mmmmhhhh, ok bene, ma quindi? cosa fa?

Ebbene questa piccola rivoluzione creata da Google consente agli sviluppatori di realizzare web application con JavaScript non più solo lato client, ma anche sfruttandolo come linguaggio di programmazione lato server.

E gli sviluppi sono davvero moltissimi, cosi tanti che mettere un’elenco sarebbe noioso e stancante ma, tanto per farne uno molto odierno, con NodeJS possiamo, ad esempio, realizzare dei ChatBot.

Ma qual’e’ dunque il funzionamento che lo rende cosi appetitoso? Innanzitutto partiamo dal dire che Node funziona con una logica a eventi: quando un evento viene generato, allora viene eseguita un’azione. Grazie a questa tecnica non bisogna attendere che le istruzioni precedenti siano terminate, rendendo cosi il tutto molto veloce.

Nella pratica, non c’e’ bisogno di sapere come funziona il V8 per poter utilizzare NodeJS, basti sapere che e’ l’interprete javascript piu’ veloce al mondo, poiche’ e’ stato altamente ottimizzato utilizzando un tipo di programmazione JIT (Just In Time), che trasforma rapidamente il codice javascript in linguaggio macchina.

Ma la cosa che, almeno a parere personale, mi ha maggiormente colpito, e’ stato quello che possiamo chiamare come “Modello non bloccante” , questo si basa sul concetto degli eventi, ma per meglio chiarire dovremmo spiegare un minimo la differenza tra modello bloccante e NON bloccante.

Immaginiamo di dover creare un programma che ci permetta di scaricare un file da internet e che alla fine dell’esecuzione del download ci mostri un messaggio.

Bene, con il modello classico (bloccante) basato sulla programmazione sincrona potremmo schematizzare il processo nel seguente modo:

  • Scarica il file
  • Mostra il messaggio
  • Fai qualcos’altro

Ci aspetteremmo quindi che le azione vengano eseguite in ordine, leggendo le operazioni da eseguire dall’alto verso il basso.

Nel sistema asincrono di NodeJS invece le operazioni verranno svolte nel seguente modo:

  • Scarica file
  • Fai qualcos’altro
  • Mostra il messaggio

Perche’ questa diversita’ nell’esecuzione rende il tutto piu’ veloce e performante? Beh perche’ mentre il sistema effettua il download del file, il programma non rimane in attesa che il processo venga portato a termine ma anzi nell’attesa il programma esegue altre operazioni.

Il codice in oggetto avra’un aspetto tipo questo:

request(‘http://www.site.com/file.zip’, function (error, response, body) {
console.log(“Download completato!”);
});

console.log(“Mentre aspetto eseguo il resto del codice…”);

Quello appena descritto qui sopra e’ un’esempio di procedura di callback 

Ok ma se non fosse ancora del tutto chiaro, proviamo ancora a spiegare perche’ le callback sono cosi importanti, procediamo con l’esempio di prima ed aggiungiamo una difficolta’; adesso i file da scaricare sono diventati due, dunque nel sistema sincrono il programma procederebbe nel seguente modo:

  • Scarico primo file
  • Attendo che finisca
  • Scarico secondo file
  • Attendo che finisca
  • Mando messaggio

La grande differenza in questo esempio sarebbe che con NodeJS verrebbero lanciati entrambi i download, nello stesso momento, permettendo gia cosi un piu’ veloce download e, nel frattempo il programma e’ in grado di svolgere eventuali altri compiti. Ma questo come dicevo e’ soltanto un esempio, invece di un download multiplo, potrebbero essere delle query ad un DB, o la richiesta di dati a servizi esterni tramite API (Facebook, Twitter).

Pensiamo quindi ad un sistema come Facebook, che riceve X richieste di Like ogni tot secondi e vengono cosi aperti N operatori che devono attendere il loro turno per fare la modifica (del like) consumando comunque energie anche mentre sono fermi in attesa; invece NodeJS nella stessa situazione di richiesta di “reaction” sul sisto di FB (like o altro) si comporterebbe nel seguente modo:

metterebbe tutte le richieste in ordine di arrivo, prenderebbe la prima e, vedendo che si tratta di una sfilza di input le inserirebbe all’interno del sistema e, una volta capito che si tratta di stesse azioni (ad esempio che aggiungono un Like) che devono contattare un DB, NodeJS contatta il DB e invece di attendere per effettuare ogni singola modifica, aggancia alla richiesta una callback, per ogni richiesta di modifica, tutti uno dietro l’altro. Quando il DB finisce la prima modifica scatta la callback e NodeJS restituisce all’utente l’avvenuta modifica della pagina e cosi via, gestendo quindi con un solo operatore le N richieste di modifica del Like invece di crearne uno per ogni richiesta e parcheggiandoli tutti in attesa della loro singola modifica. Quindi con un server (magari anche un container con Docker) e con poche risorse possiamo gestire un’enorme quantita’ di richieste al secondo.

Inoltre NodeJS usa come sistema di pacchetti e librerie l’NPM, ma di questo fantastico sistema di librerie parleremo in un’altro articolo.

Nel prossimo articolo su NodeJS parleremo anche di 5 nuovi framework ottimi per chi si occupa di sviluppare.

#NodeJS

 

Ansible per l’automazione IT ed il Configuration Management

Ansible e l’automazione IT

Ansible e l’automazione IT

Ansible e’ un tool di Configuration Management ed IT Automation che sta riscuotendo un notevole successo tra gli addetti ai lavori in virtu’ della sua immediatezza, della sua semplicita’ di utilizzo e del superamento delle limitazioni della tipica configurazione basata su “server & agent”.

Che cos’e’ Ansible

Ansible quindi e’ un tool di Configuration Management ed IT Automation che rientra nella sfera degli strumenti tipici del metodo DevOps.

DevOps e’ un movimento nato per abbattere il muro di gomma che nel corso degli anni si e’ innalzato tra Developer e Sysadmin. Per usare un’analogia, DevOps e’ una cultura che ha lo scopo di creare una pipeline (in pratica un ponte di comunicazione) tra sviluppatori ed amministratori di sistema.

L’obiettivo e’ uno solo: aumentare costantemente la soddisfazione del cliente producendo ed erogando software allo stato dell’arte con continue release correttive.

Per raggiungere un obiettivo cosi’ ambizioso e’ importante poter contare non solo sulle persone ma anche sugli strumenti. Cosi’ sono nati tool agili ed intuitivi che hanno lo scopo di automatizzare lo sviluppo, il testing e la configurazione di server ed applicazioni. Questa famiglia di tool per il Configuration Management comprende gia diversi nomi blasonati come ad esempio Puppet, Chef, Saltstack e CFEngine.

Configuration Management in breve

Il Configuration Management e’ un processo utilizzato per definire la configurazione delle applicazioni web e dei server in modo consistente, possibilmente sotto controllo di versione. Con il Configuration Management e’ possibile definire a priori come dovra’ essere configurato il server X o l’applicazione Y. Il tutto in linguaggio sorgente o sotto forma di meta-linguaggio.

I tool di Configuration Management leggono le configurazioni a partire da un file sorgente ed applicano le stesse su uno o piu’ server, in modo automatico e prevedibile.

Esempio:

inizio configurazione
1 assicurati che apache2 sia installato
2 assicurati che php5 sia installato
3 assicurati che mysql sia installato
fine configurazione

Un tool di Configuration Management puo’ leggere queste istruzioni ed applicarle su uno o piu’ server. In questo modo l’operatore puo’ replicare la stessa configurazione su decine di server oppure ricostruire la stessa in pochi secondi quando uno o piu’ server vengono messi fuori uso.

Ansible, un po’ di storia

Lanciato nel 2012, Ansible  nasce da un’idea di Michael de Haan, creatore tra l’altro di Cobbler. De Haan un bel giorno sente la necessita’ di scrivere un software che potesse semplificare all’ennesima potenza le attivita’ di Configuration Management ed Automazione IT.

Fino a quel momento il panorama del Configuration Management era dominato da Puppet e Chef (che comunque mantengono e sicuramente manterranno  anche in futuro quote di mercato molto vaste). Ma seppure ottimi, sia Puppet che Chef hanno alcuni punti deboli, che fanno storcere il naso ai Sysadmin piu’ esigenti:

* Puppet e Chef funzionano principalmente in modalita’ server – agent

* Chef richiede anche la conoscenza del linguaggio Ruby

Anche se non si tratta di limitazioni insormontabili ci sono comunque alcuni svantaggi in questo tipo di approccio.

Prima di tutto non sempre e’ possibile installare un agent sul server di destinazione, poiche’ un agent e’ comunque un piccolo software che rimane in esecuzione permanente su uno o piu’ server ed ha lo scopo di attendere comandi e configurazioni impartite dal server master.

Sia Chef che Puppet utilizzano questo approccio che spesso non e’ possibile mettere in pratica.

Pensiamo ad esempio ad ambienti server che per ragioni di conformita’ o sicurezza non possono ospitare agenti o software estranei oppure a quei server con un discreto numero di anni sulle spalle, dove l’installazione di una versione aggiornata di Ruby (richiesta, ad esempio, da Puppet) potrebbe causare effetti imprevedibili.

I vantaggi di Ansible

Perche’ dunque adottare Ansibile ?
Se sei un Sysadmin o un Developer potrai trarre sicuramente grande beneficio dall’uso di questo tool: con Ansible non e’ mai stato cosi’ semplice definire lo stato di un server e delle tue applicazioni web.
Con Ansible quindi il risparmio di tempo e di codice e’ notevole rispetto a Puppet o Chef.

Curva di apprendimento bassa

Dalla lettura della documentazione alla scrittura dei primi Playbooks il passo sara’ breve, ed in pochi minuti vi sara’ possibile iniziare a lavorare con Ansible senza dover penare con configurazioni di server Master e agenti vari.

Non sono richieste capacita’ di coding

Puppet e Chef nascono entrambi da un team di sviluppatori follemente innamorati di Ruby. Per la definizione dello stato dei server e delle configurazioni Puppet adotta un linguaggio simile al codice Ruby mentre per definire lo stato di un server con Chef e’ addirittura essenziale conoscere il linguaggio, invece Ansible supera completamente questa limitazione.

In Ansible ad esempio e’ possibile definire che il server X dovra’ contenere Apache con due righe:
es:

Install Httpd
yum: name=httpd state=latest

Come si puo’ notare, a differenza di Puppet, Chef e Saltstack, Ansible non ha bisogno di nessun agente per applicare le configurazioni su un server. Ansible utilizza di default il trasporto SSH: questo elimina la necessita’ di installare software estraneo sui nodi.

Modulare e Open Source

Ansible e’ composto da numerosi moduli. Per analogia i moduli di Ansible hanno la stessa funzione delle risorse in Puppet. Ogni modulo svolge delle funzioni ben precise e gestisce un singolo aspetto di ogni sistema. Questa architettura consente di espandere Ansible praticamente all’infinito, senza contare che i moduli possono essere scritti in qualsiasi linguaggio di programmazione. Inoltre Ansible e’ Open Source e la comunita’ continua a crescere rapidamente.

Ansible, i concetti chiave

Prima di terminare con questa introduzione su Ansible vediamo quali sono i concetti chiave ed i componenti che ruotano attorno a questo software.

Ansible: l’inventario

L’inventario e’ una lista di server sui quali Ansible applica, a comando, le configurazioni di sistema e le istruzioni di automazione. L’inventario di solito e’ contenuto all’interno del file /etc/ansible/hosts anche se e’ possibile specificare una posizione a piacere.

All’interno dell’inventario l’operatore puo’ specificare la lista dei server “bersaglio”. E’ chiaramente obbligatorio che ogni server abbia una corrispondenza DNS anche se e’ possibile specificare ogni server con il proprio indirizzo IP . Un esempio di inventario:

[webservers]
webserver1.example.com
webserver2.example.com

[dbservers]
dbserver1.example.com
dbserver2.example.com

Ansible ed i Tasks

In Ansible i Tasks sono dei “compiti” ovvero una serie di istruzioni che Ansible esegue in ordine di apparizione. Ogni istruzione contiene la definizione e/o la configurazione che dovra’ essere applicata ad ogni sistema.

Ansible e gli Handlers

Gli Handlers in Ansible sono delle istruzioni che vengono eseguite a seguito di una determinata azione. Ad esempio dopo aver installato httpd un operatore puo’ voler avviare Apache automaticamente. Un esempio di Handler che avvia Apache su CentOS:

name: start httpd
service  : name=httpd state=started enabled=yes

Gli Handlers si basano sul modulo service di Ansible (questo modulo viene utilizzato per gestire i servizi di sistema).

Ansible ed i Playbook

In Ansible i Playbook sono delle collezioni di Tasks. Ogni Playbook puo’ contenere un determinato numero di Tasks e di Handlers. I Playbook devono essere definiti in linguaggio YAML.


Ansible ed i Moduli

Ansible e’ composto da numerosi moduli. Esistono moduli per gestire i servizi di Cloud Computing (EC2 su AWS), Rackspace e Google Compute Engine, esistono moduli per installare pacchetti software su server Linux con apt e yum, moduli per gestire file di configurazione e database e molto altro ancora.

Per una lista completa dei moduli puoi consultare la documentazione ufficiale: Ansible Modules.

#AnsibleConfigurationManagement

Puppet: automatizziamo e gestiamo ogni task

Puppet Labs

Puppet Labs

Introduzione a Puppet

Puppet è un software open source, scritto in linguaggio Ruby, che permette la gestione automatizzata e centralizzata di un’infrastruttura di sistemi Linux e Unix, essendo disponibile per tutte le principali distribuzioni Linux, ma anche per le diverse varianti di BSD oltre che Solaris e AIX.

Con Puppet è possibile gestire praticamente ogni risorsa di un sistema: programmi da insallare, servizi da avviare, file di configurazione con contenuti diversi a seconda di diverse logiche, utenti, cron jobs, mount point, esecuzione di comandi specifici ecc.
Praticamente permette di automatizzare ogni attività sistemistica cambiando di fatto il modo con sui si opera su sun server.

La logica di Puppet è di definire lo stato di un sistema e fare in modo che questo sia tale ogni volta che il client Puppet viene eseguito.
La prima volta che lo si esegue, vengono installati pacchetti, avviati servizi, modificati file di configurazione secondo quanto definito sul PuppetMaster, le volte successive, se non sono intervenute modifiche manuali sul sistema, o cambiamenti delle configurazioni sul master, non dovrebbe cambiare nulla, altrimenti verranno upgradati eventuali file di configurazione o servizi, cosi come indicato sul PuppetMaster.
Questo è un concetto importante per il sistemista, e’ un vero e proprio cambio di paradigma sul suo modo di operare, poiche’ in un sistema gestito con Puppet non si devono modificare a mano i file che Puppet gestisce, perchè questi vengono aggiornati al successivo collegamento/verifica con il Master e, visto che nelle condizioni ideali, Puppet gestisce tutte le risorse di un sistema (non è obbligatorio che sia così, ma è comunque consigliabile), di fatto, salvo in casi di emergenza, un sistemista non dovrà mai intervenire a mano sui suoi server.

Se da un lato tutto questo può risultare laborioso e in qualche modo “innaturale” nella gestione dall’altro comporta una serie di vantaggi clamorosi:
– Si può configurare il profilo di un server ed applicarlo a decine o centinaia di host, tutti uguali, tutti allineati, tutti configurati con la stessa logica.
– La procedura di setup e configurazione di un sistema è riproducibile, evitando cosi’ di trovarsi a gestire dei sistemi che poi non si sanno più reinstallare.
– E’ facile e quasi intrinseco prevedere per ogni host il suo corrispettivo di sviluppo, collaudo e produzione, non avendo limiti nel numero di ambienti previsti e avendo la certezza di avere i sistemi fra di loro allineati.
– I manifest di puppet sono generalmente gestiti con un sistema di versioning (git, subversion, cvs vanno tutti bene), questo comporta automaticamente una gestione formale, reversibile, documentata e tracciata delle modifiche fatte sui sistemi.

Il risultato è che, già in infrastrutture di qualche decine di host, Puppet diventa uno strumento unico e insostituibile per una gestione rapida ed efficace del parco macchine, lo sforzo inizlae di definizione delle sue configurazioni viene ampiamente ripagato nel tempo con tempi di gestione e setup dei sistemi enormemente ridotti.
Insomma, con Puppet ci si può dedicare al miglioramento e l’affinamento della propria infrastruttura risparmiando il tempo speso in attività ordinarie ripetitive e noiose.

Per chi volesse provare le potenzialita’ di Puppet oggi e’ possibile scaricare una versione Free Trial direttamente dal sito del produttore [To try Puppet Enterprise for free on up to 10 nodes].
Vi verranno richieste soltanto alcune informazioni formali, prima di poter ottenere il file installabile per la versione della nostra distro (sia 32 che 64 bit).
Potrete cosi’ scaricare il pacchetto puppet-<vostra versione>.tar.gz sul vostro Puppet Server; una volta estratto il contenuto del file, ad esempio sotto /opt , per lanciare l’installazione del pacchetto vi bastera’ lanciare lo script :

cd /opt/puppet

# sudo ./puppet-enterprise-installer

L’installazione procedera’ sostanzialmente da sola, all’inizio ci verra’ soltanto chiesta la conferma (premendo Y ) per avviare il processo d’installazione e copia dei file necessari, dopodiche’ bastera’ avere un po’ di pazienza.

Altrimenti e’ possibile questa ulteriore strada (ad esempio per un sistema Ubuntu 14.x)

wget https://apt.puppetlabs.com/puppetlabs-release-trusty.deb
sudo gdebi puppetlabs-release-trusty.deb 
sudo apt-get update 
sudo aptitude install puppet-common=3.7.3-1puppetlabs1 puppet=3.7.3-1puppetlabs1
sudo apt-get install puppetmaster-passenger

Nel caso in cui invece dobbiate solo fare un upgrade all’ultima versione vi bastera’ eseguire :

$ sudo apt-get update
$ sudo puppet resource package puppetmaster ensure=latest

Se poi non avete il tempo da impiegare nell’installazione, ma non volete perdere l’occasione di testare un prodotto cosi interessante potete anche scaricare una VM gia pronta al seguente link puppetlabs_VM

Configurazione

– Il puppet master
Raggiungete la macchina prescelta come puppet master che chiameremo, senza troppa fantasia, master e installate i programmi necessari:

root@master:

~# apt-get install puppetmaster

Questa operazione installerà anche le dipendenze, compreso il pacchetto per l’agent puppet.
L’installazione terminerà con uno sconfortante errore: niente paura! semplicemente il master non è ancora stato configurato a dovere e gli script di init non sono in grado di avviarlo correttamente.
Preoccupiamoci innanzitutto di permettere l’accesso ai file che verranno serviti dal nostro master, editate il file /etc/puppet/fileserver.conf e aggiungete una riga per permettere l’accesso alla sottorete 192.168.0.0/24 (per esempio).

 

Prepariamo un piccolo laboratorio con 3 macchine

Name                 IP                     OS                    Descrizione
puppet01        192.168.1.10            CentOS 6.5               puppet master
puppet02        192.168.1.20            CentOS 6.5               puppet client
puppet03        192.168.1.30            CentOS 5.10              puppet client

** configuriamo il file /etc/hosts

# vim /etc/hosts

192.168.1.10    puppet01
192.168.1.20    puppet02
192.168.1.30    puppet03

– Inseriamo queste due righe nel [main] edl file /etc/puppet/puppet.conf

certname = puppet
dns_alt_names = puppet,puppet01.localdomain

– Configuriamo il certificato
Con questo comando si creerà il certificato CA e il certificato per il puppetmaster

puppet01 # puppet master –verbose –no-daemonize

notice: Starting Puppet master version 2.7.25
(una volta apparsa la riga qui sopra potete chiudere con un Ctrl-C)

* verifichiamo: # puppet cert list –all
+ “srv-c6.localdomain” (10:BD:EB:92:CE:98:A7:37:FE:4B:D8:20:5E:C2:44:D5) (alt names: “DNS:puppet”, “DNS:puppet.localdomain”, “DNS:puppet01.localdomain”)

* riavviamo il servizio :

#  /etc/init.d/puppetmaster restart

Installazione dei client

sulle macchine puppet02 e puppet03 installare soltanto il client “puppet” nei seguenti modi :

Ubuntu/Debian : # sudo apt-get install puppet

RHEL/Centos   : # sudo yum install puppet -y

** sulle macchine client andremo a modificare il file puppet.conf indicando il nome della macchina Server, il puppetmaster

# vim /etc/puppet/puppet.conf

[agent]
server = puppet01

su puppet02 e puppet03

# puppet agent –test # si dovrebbe vedere l’agente creare una richiesta di certificato al master

ora su puppet01 eseguite

# puppet cert list –all # dovreste vedere le richieste effettuate dai client 01 e 02

La prima fase e’ cosi terminata, nel prossimo articolo vedremo come installare e configurare la Dashboard di Puppet per avere una gestione centralizzata tramite Browser

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