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

Condividere e’ bello con Screen

screen_terminalSCREEN appartiene a quella categoria di applicativi molto potenti ma poco conosciuti, basta però utilizzarlo anche una sola volta per non poterne più fare a meno. Tecnicamente è un multiplexer per terminale, ovvero un applicativo con cui eseguire, all’interno di una console, molti comandi contemporaneamente, oppure connettersi allo stesso schermo virtuale da più console.

Proprio questa seconda opportunità è quella preferita dagli utenti GNU/Linux, infatti, tramite screen si può lanciare un programma, disconnettersi dal suo output, fare altro e riagganciarsi ad esso in un altro momento senza aver perso nulla!

Ma cerchiamo di spiegarci meglio; sicuramente per lavoro, sia chi usa Linux che chi usa Windows, acra’ dovuto connettersi in remoto su altre macchine e spesso si usano tool quali Putty, diciamo che per varie necessita’ le operazioni di calcolo lanciate sulla macchina su cui operate occupano parecchio tempo e non potete fare log-out per non perdere l’attivita’ iniziata…., bene, nel mondo unix e linux esistono due soluzioni a questo problema e si tratta delle utility `nohup` e `screen`. In questo articolo spiegherò come usare  “screen“.

Iniziamo con l’installazione :

sudo apt-get install screen

Fatto questo, si può avviare screen, semplicemente digitando nel terminale della macchina remota:

screen

e si avra’ subito una sessione in cui poter lavorare.
Per inviare comandi direttamente a screen, si usa la combinazione di tasti CTRL-a (abbreviati in seguito con C-a) e poi va digitato il comando.
Ad esempio, per avviare una nuova sessione, basta digitare C-a c, oppure per avere l’elenco dei comandi, C-a ?.
Le combinazioni sicuramente necessarie da sapere sono:

C-a ? :: visualizza la pagina di aiuto
C-a c :: avvia una nuova sessione
C-a n :: torna alla sessione precedente
C-a p :: va alla sessione successiva
C-a h :: crea un file di log per la sessione
C-a m :: avvia monitoraggio per una sessione
C-a a :: va alla sessione che ha segnalato un evento di monitoraggio
C-a d :: stacca il terminale da screen, lasciando il processo attivo
C-a k :: chiude la sessione corrente di screen

Ora, cosa succede se mi disconnetto senza chiudere screen? Viene semplicemente lasciata aperta la sessione, ed al nuovo accesso, basterà digitare:

screen -ls

per avere l’elenco delle sessioni attualmente attive, es :

@tuttiperlinux:~$ screen -ls
There is a screen on:
326.pts-2.tuttiperlinux (01.10.2014 09:50:57) (Attached)
1 Socket in /var/run/screen/S-tuttiperlinux.

e per riconnettersi alla sessione, basterà digitare:

screen -r 326

o piu’ semplicemente “screen -r” se esiste una sola sessione attiva.

Se la vostra necessita’ e’ invece quella di condividere una sessione di lavoro/diagnosi con altri colleghi potrete, ad esempio collegarvi remotamente tutti sullo stesso server , successivamente usare una utenza specifica per la manutenzione del servizio in questione e collegarvi tutti alla stessa sessione, esempio :

screen -x <user>; #che potra' essere tomcat, come apache ecc...

condividendone lo stesso terminal e potendo cosi interagire avendo davanti a voi tutto cio’ che succede sulla macchina a prescindere da chi stia impartendo i comandi.

Caratteristiche principali

Persistenza
Similmente a tool quali VNC, “screen” permette all’utente di avviare delle applicazioni da un computer e poi riconnettersi da un altro computer e continuare ad usare la stessa applicazione senza farla ripartire. Questo rende gli spostamenti, come ad esempio tra casa e lavoro, molto più semplici. Screen fornisce una funzionalità terminal-agnostic (ovvero funziona indipendentemente dal terminale utilizzato) perciò gli utenti possono disconnettersi e riconnettersi utilizzando tipi diversi di terminali, permettendo alle applicazioni di continuare senza percepire il cambio del terminale.
Finestre multiple
Possono essere create sessioni multiple, ognuna delle quali di solito ospita una singola applicazione. Le finestre sono numerate e l’utente può utilizzare la tastiera per passare da un’applicazione all’altra. Alcune GUI forniscono delle tab o qualche altra opzione simile per fornire questa caratteristica. Ogni finestra ha la sua scroll-back buffer, così è possibile vedere l’output anche quando la finestra non è attiva in quel momento e questo output può essere salvato anche quando si passa ad un altro computer. Le finestre possono essere ripartite in più screen tramite split screen. Mentre alcune applicazioni di testo hanno già questa funzionalità, Screen permette che ogni finestra sia divisa orizzontalmente in un numero qualsiasi di altre applicazioni.
Condivisione di sessione
Screen permette che più computer si connettano alla stessa sessione allo stesso tempo, permettendo così la collaborazione tra più utenti. Lo stesso computer può essere utilizzato per fare connessioni simultanee multiple, fornendo funzionalità alternative per la divisione della schermata, in particolare per i computer con più monitor.

Insomma una gran comodita’, un tool sicuramente utile da usare in tante diverse situazioni….!

Firewall apriamo un passaggio segreto

fwknop_spaPort-knoking – II Episodio

Poco tempo fa abbiamo affrontato il concetto di sicurezza utilizzando la tecnologia del port-knoking . Oggi affronteremo una seconda metodologia legata al port knoking.

Facciamo un passo indietro considerando il firewall il miglior sistema di difesa in nostro possesso. Il port-knoking e’ in pratica una tecnica di autorizzazione che agisce sul firewall e che puo’ essere realizzato con diverse metodologie; la “bussata” dipendera’ dal software di port-knoking utilizzato, ma in tutti i casi si compone di pacchetti TPC/IP appositamente forgiati dall’utente.

Le tipologie piu’ frequenti sono due:

  • sequenza affinche’ l’utente venga riconosciuto , il client deve inviare alcuni pacchetti secondo una sequenza creata al momento della configurazoine su diverse porte TCP o UDP;
  • payload tutto il necessario per il riconoscimento dell’utente e’ contenuto nel payload dei pacchetti

a) la prima tipologia e’ di facile realizzazione e utilizzo, ma e’ relativamente fragile perche’ basta uno sniffer di pacchetti per ascoltare la sequenza la sequenza inviata al server, replicarla e ottenere cosi’ l’accesso;

b) se il nostro desiderio di sicurezza e’ piu’ paranoico, allora soltanto il port-knoking basato sui payload potranno soddisfarci, inqunato questi sono al sicuro dai tentativi di replay-attack.

PARANOIA

Il mondo e’ bello ma e’ pericoloso, se questo e’ assodato anche per voi possiamo passare alla visione piu’ paranoica per provare una nuova configurazione tramite il software fwknop, un sistema di port-knoking che pone la sua forza nel criptare i payload del pacchetto di autorizzazione.

Fwknop va oltre al semplice sistema di port-knoking, esso in realta’ e’ il prototipo di una nuova tecnologia chiamata : Single Packet Authorization o (SPA) che si differenzia proprio per la possibilita’ di autorizzare l’utente utilizzando un’unico pacchetto TCP/IP.

SPA si comporta alla stessa maniera del port-knoking, solo che  invia un singolo pacchetto criptato verso il server di destinazione.
Questo comporta una migliore velocità nell’accedere al servizio che decidiamo di nascondere (esempio SSH), ed un maggiore livello di discrezione sulla rete (al contrario il Port Knocking classico può essere scambiato per un tentativo di port scanning da un IDS) e soprattutto protegge dai tentativi di connessioni replicate ( il singolo pacchetto criptato viene creato tutte le volte con valore casuale e non può essere riutilizzato!).

Fwknop è composto da un client ed un server.
Il demone fwknopd installato sul server sniffa le connesioni che arrivano sull’interfaccia di rete tramite la libreria libpcap, appena riceve dal client il pacchetto criptato e firmato con la chiave giusta abilita la connessione dell’indirizzo IP sorgente verso il servizio prestabilito (iptables).
Una volta inviato il pacchetto tramite il client fwknop si ha un lasso di tempo per stabilire la connessione verso il servizio protetto (di default 30 sec.), sfiorata questa tempistica il server chiude la connessione.

INSTALLAZIONE

sudo apt-get install fwknop-server libpcap-dev

sudo apt-get install fwknop-client

Oltre ai pacchetti vanno inserite due regole iptables fondamentali per il funziomaneto di fwknop:

iptables -I INPUT 1 -i eth0 -p tcp --dport 22 -j DROP
iptables -I INPUT 1 -i eth0 -p tcp --dport 22 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

La prima blocca tutte le connessioni in entrata per il servizio SSH, la seconda invece accetta le connessioni già stabilite (questa servirà quando fwknop server ci autorizzerà a collegarsi verso il demone ssh).
ATTENZIONE!!!
Così facendo chiuderete tutte le connessioni verso ssh, accertatevi di poter accedere al server
dalla console locale o abilitate la connessione a un singolo ip.
Esempio:

iptables -I INPUT -i eth0 -s 3.3.3.3 -p tcp --dport 22 -j ACCEPT

In questo caso le configurazioni sul server remoto le eseguirò da una connessione con ip 3.3.3.3 , che avra’ libero accesso.

Configurazione fwknop server/client

Immaginiamo lo scenario:

ServerSPA: 2.2.2.2

ClientSPA: 1.1.1.1

UserClientSPA: pippo

*** Geneare le chiavi sul client e prenderne nota:

pippo@clientspa:~$ fwknop -A tcp/22 -D 2.2.2.2 --key-gen --use-hmac --save-rc-stanza
[*] Creating initial rc file: /home/pippo/.fwknoprc.
[+] Wrote Rijndael and HMAC keys to rc file: /home/pippo/.fwknoprc
pippo@clientspa:~$
pippo@clientspa:~$ grep KEY /home/pippo/.fwknoprc
KEY_BASE64                  NPhe11+ORlK1Yfr4ipzW+ngQxzRt8kjI6UTDXLZYSv0=
HMAC_KEY_BASE64             SypMEUIhiAKTjeHlHoWR5dfu7hrLVvLnoIXINPbGTOowST1vUIs+tOtMc/XlKl6+JcVw7qc2jrpqmKujZxvnqw==
pippo@clientspa:~$

*** Creare sul serverspa (2.2.2.2) il file “/etc/fwknop/access.conf” inserendo le chiavi del client:

SOURCE                     ANY
REQUIRE_SOURCE_ADDRESS     Y
KEY_BASE64                  NPhe11+ORlK1Yfr4ipzW+ngQxzRt8kjI6UTDXLZYSv0=
HMAC_KEY_BASE64             SypMEUIhiAKTjeHlHoWR5dfu7hrLVvLnoIXINPbGTOowST1vUIs+tOtMc/XlKl6+JcVw7qc2jrpqmKujZxvnqw==

*** Controllare che sul file di configurazione del serverspa (2.2.2.2) sia configurata l’interfaccia di rete (WAN) corretta su cui fwknopd starà in ascolto:

[root@serverspa]# grep PCAP_INTF /etc/fwknop/fwknopd.conf
# the PCAP_INTF setting.
PCAP_INTF                   eth0;

***  Far partire il demone fwknop sul serverspa (2.2.2.2):

[pippo@serverspa]$ sudo /etc/init.d/fwknop-server start
Avvio di fwknopd:                                          [  OK  ]
[pippo@serverspa]$

Test di connessione

Controllare che il serverspa (2.2.2.2) blocchi di default le connessioni verso il servizio SSH:

pippo@clientspa:~$ nmap 2.2.2.2 -p22

Starting Nmap 6.40 ( http://nmap.org ) at 2014-04-30 23:21 CEST
Nmap scan report for 2.2.2.2
Host is up (0.0011s latency).
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap done: 1 IP address (1 host up) scanned in 1.97 seconds

*** Spedire il pacchetto SPA al serverspa ed abilitare l’accesso SSH al clientspa:

pippo@clientspa:~$ fwknop -n 2.2.2.2 -a 1.1.1.1 # in assenza di ip statico 1.1.1.1 dovrà essere sempre sostituito dall’ip pubblico assegnato dal vostro ISP.

 

*** Collegarsi dal clientspa verso il serverspa tramite ssh client entro 30 secondi :

pippo@clientspa:~$ fwknop -n 2.2.2.2 -a 1.1.1.1
pippo@clientspa:~$ ssh root@2.2.2.2
root@2.2.2.2's password:
Last login: Wed Apr 30 23:06:51 2014 from 5.5.5.5
[root@serverspa ~]#

Conclusioni

Fwknop non puo’ garantire una sicurezza assoluta (come nessun altro software) ma integrato nel vostro sistema insieme ad altri tool puo’ aumentarne notevolmente il livello.

Pro:

  • Protegge i servizi da eventuali 0-day
  • Riduce i tempi di risposta del Port Knocking
  • Cripta il playload
  • Disponibilità del client per vari dispositivi

Contro:

  • Non è utilizzabile con tutti i servizi (soprattutto quelli pubblici a cui devono accedere qualsiasi utente)
  • Devi sempre avere un client disponibile

 

*** Leggi anche Portknoking & Honeypot SSH

Sicurezza – Honeypot SSH

Kippo honeypotUn Honeypot SSH con Kippo

Chiunque abbia un minimo di esperienza nel mettere a punto server rivolti verso Internet conosce bene la quantità di scansioni e di attacchi automatizzati che si possono ricevere in brevissimo tempo, a volte nel momento stesso in cui ci si collega in Rete.

Molti scanner non sono sofisticati e si limitano a cercare porte ssh aperte per tentare un bruteforce e, in caso di successo, passare il controllo ad un attaccante umano (un cracker non un hacker).

Come descritto in un precedente articolo “Sicurezza con il PortKnocking” , i passi da fare per mettersi al sicuro non sono mai abbastanza ed inparticolare alcuni servizi vanno completamente blindati anche solo per evitare enormi moli di log del firewall, solo per i tentativi di login al servizio SSH; proprio per questi motivi un ottimo esercizio e’ quello di creare un honeypot partendo da quest’ultimo servizio.

In questo contesto si colloca Kippo: un honeypot che simula un server ssh vulnerabile il cui obiettivo è quello di impegnare un attaccante e registrarne i movimenti. E’ un tool open source scritto in Python progettato quindi per registrare attacchi di tipo bruteforce e, soprattutto, l’intera interazione shell effettuata dall’ attaccante. In pratica quando un utente malintenzionato cercherà di entrare nel vostro sistema si troverà davanti un finto sistema che registrerà tutte le sue attività.

Kippo nel tempo si è guadagnato una certa popolarità dovuta alla sua semplicità d’uso, portabilità e al fatto che permette di riprodurre i log degli attacchi registrati.

Installazione

Kippo è programmato in Python e si basa sul framework Twisted, è necessario quindi un interprete python almeno alla versione 2.5.

I requisiti sono i seguenti:

  • Python 2.5+
  • Twisted 8.0+
  • PyCrypto
  • Zope Interface

come prima cosa bisogna cambiare la porta del server SSH per fare questo basta aprire e modificare il file sshd_config:

# vim /etc/ssh/sshd_config

e sostituire la porta 22 con un’altra a vostra scelta,

Dopo aver modificato il parametro Port 22 con un altro (es. 2443) riavviare il servizio con il commando:

 # /etc/init.d/ssh restart

Una volta sistemato questo piccolo dettaglio, bisogna installare tutti i pacchetti necessari per il corretto funzionamento di Kippo:

Prima di mettere in esecuzione l’ honeypot occorre configurarlo agendo sui parametri nel file kippo.cfg.

Le principali opzioni sono le seguenti:

  • ssh_addr: l’indirizzo dell’interfaccia su cui vogliamo mettere kippo in ascolto (di default su tutte)
  • ssh_port: il numero della porta
  • password: la password per collegarsi all’ honeypot, di default è 123456 che statisticamente è la password più comune che si può trovare. Se impostiamo una password difficile rischiamo di far fallire un attacco brute force! e ci perdiamo il bello del divertimento.
  • [database_mysql]: parametri per loggare tutta l’attività di kippo su un db mysql. Di default questa opzione non è attiva.

Su Linux per motivi di sicurezza kippo non può essere eseguita come root e quindi non può mettersi direttamente in ascolto sulle porte basse del sistema (< 1024) tra cui anche quella di default del server ssh (la porta 22).

Per reindirizzare la porta 22 sulla porta in cui abbiamo messo in ascolto la honeypot dobbiamo impostare un reindirizzamento con il firewall di sistema. L’impostazione corretta dipende dal firewall che state usando sul vostro server e dalla tipologia della rete.

Ad esempio con iptables:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 22 -j REDIRECT --to-port 2443

oppure usando l’ottimo tool rinetd, come spiegato enll’articolo “Catturare il traffico di rete“.

Installiamo i pacchetti
# apt-get install python-dev openssl python-openssl python-pyasn1 python-twisted

Visto che la porta 22 (che kippo dovrà monitorare) può essere utilizzata solo dall’ utente root e per ragioni di sicurezza non è consigliato usare kippo come utente root bisogna installare un altra piccola applicazione, Authbind, che ci permetterà di eseguire kippo sulla porta 22:

# apt-get install authbind

Ora creiamo un altro utente (non-root) che useremmo per eseguire kippo (non è vietato eseguire kippo come root ma per ragioni di sicurezza è consigliato usare un utente apposito):

# adduser kippo

e aggiungiamolo alla lista dei sudoers:

 # vim /etc/sudoers

aggiungendo la seguente stringa nel file:

kippo ALL=(ALL:ALL) ALL

(sotto l’utente root)

 Non ci resta che dare all’ utente kippo i privilegi per usare la porta 22:

# touch /etc/authbind/byport/22
# chown kippo:kippo /etc/authbind/byport/22
# chmod 777 /etc/authbind/byport/22

Ora non ci resta che cambiare utente ed entrare nel sistema con l’utente kippo, una volta cambiato utente siamo pronti a scaricare kippo (verificare sul sito del progetto per nuove versioni):

# wget https://kippo.googlecode.com/files/kippo-0.8.tar.gz /home/<utente xxx>/Downloads/

estraiamo i file:

# tar -zxvf kippo-0.8.tar.gz -C /opt/

ora ci spostiamo nella cartella del programma e modifichiamo il file kippo.cfg inserendo la porta 22 come target (di default è impostata la 2222) con la porta da voi prescelta, tipo la 2443.

# vim kippo.cfg

ed in fine modifichiamo il file start.sh:

# vim start.sh

sostituendo la stringa:

twistd -y kippo.tac -l log/kippo.log –pidfile kippo.pid

con:

authbind –deep twistd -y kippo.tac -l log/kippo.log –pidfile kippo.pid

ora non ci resta che eseguire il programma con:

# ./start.sh

…… e qualsiasi tentativo di connettersi alla porta 22 del sistema sarà registrato da Kippo e file di log verranno archiviati nella cartella corrispondente. Kippo rimane in esecuzione in background e aspetta che qualche attaccante si faccia vivo.

Quando finalmente riusciremo a registrare un attacco (e solitamente è questione di solo poche ore!) l’honeypot si occuperà di registrare ogni movimento.

Nella cartella log/ verranno salvati i log interattivi delle sessioni registrate e in quella dl/ verranno salvati i file e gli eseguibili che gli ignari attaccanti tenteranno di scaricare sul server (di solito rootkit, malware generici, etc)

Il divertimento, una volta collezionati un po di log interattivi, è quello di riprodurli con il playlog che è una utilità che permette di riprodurre i log come se fossero un video.

Il programma si trova nella cartella utils/, per eseguirlo (da linea di comando):

python playlog.py /path/to/xxx.log

Statistiche

Quando si ha una honeypot funzionante a pieno regime può risultare scomodo controllare periodicamente i log per capire il numero di attacchi ricevuti, la durata e altre informazioni utili.

Per facilitarci le cose possiamo affidarci a un programma come Kippo Graph che si occupa di generare statistiche dettagliate e farci risparmiare del tempo prezioso.

Sicurezza con il PortKnocking

portknockingMi e’ capitato spesso di dover configurare firewall per proteggere i Server di mia competenza e molte volte capita l’esigenza di dover tenere aperto un accesso dall’esterno, per poter operare in qualunque momento o per qualunque motivo. Ovviamente questo ci potrebbe esporre facilmente alla possibilita’ di venire attaccati; che cosa fare in questi casi ??? Beh! le possibili soluzioni sono davvero tante, tante quanto la fantasia di chi le studia; in questo articolo quindi descrivero’ semplicemente un mio modo personale di arginare tale possibile pericolo.

* Il primo suggerimento e’ quello di spostare il servizio SSH dalla porta 22 ad una di vostra preferenza, stando ben attenti a non usare possibili porte utilizzabili da altri servizi web.

* Il secondo suggerimento e’ quello di creare un servizio di Honeypot (tipo honeyd a bassa interazione, oppure come honeynet ad alta interazione) , da tenere in ascolto sulla porta standard (la 22) dell’SSH, cosi’ che i male intenzionati trovino la porta attiva e nel tentativo di attaccarvi perdano tempo e si ritrovino successivamente all’interno di servizi fasulli.

* Il terzo suggerimento e’ quello di utilizzare la tecnica del port-knocking per poter gestire a proprio piacimento ogni accesso in SSH attivando e disattivando tramite una sequenza di caratteri che solo voi conoscete e che potrete cambiare a piacimento.

PORTKNOCKING

Iniziamo col dire che cosa e’ questa tecnica: le tecniche di Port knocking permettono di aumentare considerevolmente la sicurezza di un server che deve garantire alcuni servizi non permanenti attraverso IP pubblici. Se s’inviano dei pacchetti a delle porte prestabilite sulle quali il demone è in ascolto e nel caso la sequenza sia corretta, questi attiverà un comando che potrà eseguire delle regole di iptables che apriranno le porte necessarie alla connessione. Il vantaggio è notevole in quanto il server potrebbe rimanere sempre in stealth mode e aprire le porte per un determinato servizio solo in caso di necessità.

Innanzitutto per poter utilizzare il portknocking e’ necessario che il firewall sia attivo e funzionante, ora posiamo installare il pacchetto software

sudo apt-get install knockd

Configurazione knockd

  1. Per fare in modo che il demone parta all’avvio del computer modificare con un editor di testo a piacimento, e con i privilegi di amministrazione il file /etc/default/knockd in questo modo:

    START_KNOCKD=1

     

  2. Sempre nel medesimo file /etc/default/knockd modificare con un editor di testo a piacimento, e con i privilegi di amministrazione indicando su quale interfaccia il demone dovrà rimanere in ascolto:

    KNOCKD_OPTS="-i eth0"

     

Configurazione knockd.conf per l’apertura di una sola porta

Modificare con un editor di testo a piacimento, e con i privilegi di amministrazione il file /etc/knockd.conf impostandolo come segue:

[options]
        logfile = /var/log/knockd.log

[openSSH]
        sequence    = 7000,8000,9000
        # Questa è la sequenza delle porte sulle quali knockd rimarrà in ascolto. Di default il protocollo è TCP.
        # Quali e quante porte usare è discrezionale.

        # sequence   = 7000:udp,8000:tcp,9000:udp
        # Esempio con sequenza con porte miste udp/tcp

        seq_timeout = 30
        #Tempo di attesa massimo per completare la sequenza.

        command     = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
        # Quando la sequenza verrà accettata verrà inserita una regola che aprirà la porta SSH standard.

        tcpflags    = syn
        # Ulteriore filtro, sul tipo di flag del pacchetto inviato alla sequenza di porte.
        
[closeSSH]
        sequence    = 9000,8000,7000
        # Questa è un'altra sequenza di porte sulle quali knockd rimarrà in ascolto.

        seq_timeout = 30

        command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
        # Quando la sequenza verrà accettata verrà inserita una regola che cancellerà quella creata in precedenza.

        tcpflags    = syn
        # Ulteriore filtro, sul tipo di flag del pacchetto inviato alla sequenza di porte.

La variabile «%IP%» passa alla regola di iptables l’indirizzo che ha effettuato la richiesta di connessione, in questo caso verrà permessa l’apertura della porta SSH discriminando solo l’IP validato.

Configurazione per l’apertura di una sola porta, per soli esperti

Un’altra possibilità per usare il demone knockd, e’ utilizzabile solo se il firewall sul server è configurato per accettare le connessioni “established” e “related” alla porta che si vuole aprire (es ssh, 22) è di chiudersi subito dietro la porta appena aperta, per evitare che, restando “aperta”, qualche malintenzionato tenti un brute-force al servizio, lanciando uno script anzichè impostando delle regole sul firewall.

Per questo scopo il file /etc/knockd.conf può ad esempio essere modificato, con un editor di testo a piacimento, e con i privilegi di amministrazione, come segue :

[options]
        logfile = /var/log/knockd.log

[openSSH]
        sequence    = 7000,8000,9000
        seq_timeout = 30
        start_command     = /etc/init.d/ssh start
        tcpflags    = syn

        cmd_timeout = 5
        stop_command     = /etc/init.d/ssh stop
        # Dopo cmd_timeout secondi, viene eseguito il comando stop_command

Ricordiamo ancora che è indispensabile che il firewall sul server accetti le connessioni “related” ed “established” altrimenti la sezione “stop_command”, appena sarà eseguita, vi chiuderà la connessione SSH senza quindi avere possibilità di connettervi al server!

tuttiperlinux@server:~# iptables -nL | grep ":22"

ACCEPT     tcp  --  0.0.0.0/0    0.0.0.0/0           tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0    0.0.0.0/0           tcp spt:22 dpts:513:65535 state RELATED,ESTABLISHED
ACCEPT     tcp  --  0.0.0.0/0    0.0.0.0/0           tcp spts:1024:65535 dpt:22 flags:0x17/0x02 state RELATED,ESTABLISHED
ACCEPT     udp  --  0.0.0.0/0    0.0.0.0/0           udp dpt:22 state ESTABLISHE

Configurazione knockd.conf per l’apertura di più porte

Nell’esempio sopra esposto si è visto come aprire una sola porta. Se l’esigenza fosse però quella di aprirne di più procedere creando più sessioni «[openServizio]» e «[closeServizio]». Questo sistema risulta però scomodo per ovvi motivi, per ottenere lo stesso risultato è consigliato usare degli script.

Modificare con un editor di testo a piacimento, e con i privilegi di amministrazione il file /etc/knockd.conf impostandolo come segue:

[options]
        logfile = /var/log/knockd.log

[open]
        sequence    = 7000,8000,9000
        seq_timeout = 30
        tcpflags    = syn
        command     = sh /etc/open_ports %IP%


[close]
        sequence    = 9000,8000,7000
        seq_timeout = 30
        tcpflags    = syn
        command     = sh /etc/close_ports %IP%

In questo caso invece di eseguire direttamente iptables si richiamano due script passando il parametro «%IP%» alla variabile speciale «$1».

Esempio di script open_ports

Modificare con un editor di testo a piacimento, e con i privilegi di amministrazione il file /etc/open_ports impostandolo come segue:

iptables -A INPUT -s $1 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -s $1 -p tcp --dport 21 -j ACCEPT
iptables -A INPUT -s $1 -p tcp --dport 631 -j ACCEPT
iptables -A INPUT -s $1 -p tcp --dport 5125 -j ACCEPT
iptables -A INPUT -s $1 -p tcp --dport 5126 -j ACCEPT
iptables -A INPUT -s $1 -p tcp --dport 8888 -j ACCEPT
iptables -A INPUT -s $1 -p tcp --dport 10000 -j ACCEPT
iptables -A INPUT -s $1 -p tcp --dport 81 -j ACCEPT

Esempio di script close_ports

Modificare con un editor di testo a piacimento,  e con i privilegi di amministrazione il file /etc/close_ports impostandolo come segue:

iptables -D INPUT -s $1 -p tcp --dport 22 -j ACCEPT
iptables -D INPUT -s $1 -p tcp --dport 21 -j ACCEPT
iptables -D INPUT -s $1 -p tcp --dport 631 -j ACCEPT
iptables -D INPUT -s $1 -p tcp --dport 5125 -j ACCEPT
iptables -D INPUT -s $1 -p tcp --dport 5126 -j ACCEPT
iptables -D INPUT -s $1 -p tcp --dport 8888 -j ACCEPT
iptables -D INPUT -s $1 -p tcp --dport 10000 -j ACCEPT
iptables -D INPUT -s $1 -p tcp --dport 81 -j ACCEPT

Esempio di una connessione

Per effettuare la connessione digitare il seguente comando all’interno di una finestra di terminale:

./knock -v <ip_host> port1 port2 port3 port...

Ora non resta altro che fare pratica e pratica ma sono sicuro che il portknocking vi dara’ tanta soddisfazione.

Leggete anche l’articolo sulla sicurezza inerente Metasploit Framework.