Una panoramica sul mondo della Sicurezza Informatica, del Networking, della Virtualizzazione e non solo. Blog particolarmente indicato per i reparti IT che comunque alterna articoli scritti per specialisti con articoli formulati con linguaggio semplice e comprensibile a tutti.

Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.

giovedì 19 maggio 2016

WebTool, Strumenti e News

Facciamo il punto su qualche webtool estremamente utile nella diagnostica di problemi di sicurezza.


haveibeenpwned.com


haveibeenpwned.com si occupa di raccogliere database di account e password compromesse, così da consentire una ricerca rapida



E' evidente che la sua efficacia è proporzionale al numero di enti che hanno deciso di condividere il proprio security breach (troverete adobe, ma non troverete dropbox, ad esempio). Ma è un ottimo punto di partenza.



CERT


I CERT (Computer Emergency Response Team) sono osservatori incaricati di raccogliere incidenti e vulnerabilità informatiche. Normalmente sono considerati un punto di riferimento, anche a livello governativo, in ambito IT Security.


In italia abbiamo IT-CERT https://www.certnazionale.it/





National Vulnerability Database


Il NVD americano, pariteticamente ed in collaborazione con i CERT, fornisce un'interfaccia dove cercare vulnerabilità note per pacchetti, librerie o software anche specifici.






VirusTotal


Ci allontaniamo un attimo, ma è sicuramente un must. Virustotal consente la scansione di un file confrontandolo con 56 motori antivirus diversi. Se siete incerti sul contenuto di un file, sicuramente questo è un ottimo modo per togliersi qualche dubbio.





DataBreachToday


Mantenersi aggiornati fa parte della IT Security e conoscere per tempo i security breach ci consente di mettere in atto ragionevoli precauzioni.



lunedì 11 aprile 2016

Quanto è facile rubare password?

Ormai anche i muri sanno che le connessioni https sono da preferire a quelle http, le connessioni imaps a quelle imap (143/TCP) o le connessioni submission SSL/TLS sono da preferire a quelle smtp (25/TCP) qualora ci si autentifichi per inviare email. 

Questo è assodato, ma la domanda che spesso mi rivolgono è "ok, ma chi vuoi abbia mai le competenze per catturare le mie password?". Proviamo a fare un laboratorio per cercare di capire quanto è semplice.

Come in linea con il resto del blog, in questo articolo non verrà spiegato come fare, lo scopo esclusivo è quello di sensibilizzare alla sicurezza informatica.

L'articolo è rivolto sia ai normali utilizzatori, sia a chi ha a che fare con queste tecnologie e spesso per "pigrizia" o per mancanza di volontà preferisce configurare connessioni in chiaro piuttosto che seguire la strada corretta di dotare ed utilizzare sul proprio server un certificato valido.



Hardware


Per questa prima prova, inizieremo a fare un Man in The Middle (MiTM) su una connessione ethernet, interrompendo in maniera silente ed invisibile un collegamento fisico.


Nello specifico, banalmente ci siamo dotati di una qualsiasi macchina con 2 schede di rete, intercettando una patch.





Più "in alto" intercettiamo la patch, e più informazioni carpiamo. Se intercettiamo la patch del router, è evidente che avremo informazioni riguardanti l'intera rete, se intercettiamo solo quella di un host, la nostra ricerca si limiterà a quest'ultimo ed al traffico di broadcast.

Lo stesso ragionamento vale in ambito geografico, ricordandoci che internet è un insieme di nodi e rimbalzi da un punto "A" ad un punto "B" e nel mezzo attraversiamo potenzialmente decine di scenari in cui questa operazione di sniffing è facilmente fattibile.



Software


Come sistema operativo abbiamo utilizzato una distribuzione Linux specifica e normalmente utilizzata per questo tipo di attività, tuttavia avremmo potuto fare la medesima cosa con una distribuzione qualsiasi e persino con una macchina Windows con uno sniffer di rete attivo. L'aver utilizzato una distribuzione specifica ci ha solo velocizzato le operazioni di installazione dei tool, facilmente reperibili in rete.

Questa è sostanzialmente la cronologia delle operazioni, con relativo tempo impiegato.

  1. Scaricamento ed installazione della distribuzione Linux (40m)
  2. Configurazione del bridge tra eth2 ed eth4, le nostre NIC (10m)
  3. Esecuzione e configurazione dei tool di sniffing e logging delle password (5m) 





I risultati


Nel giro di meno di 1h abbiamo creato una macchina in grado di catturare tutto il traffico e restituirci le credenziali di accesso in chiaro.



Qui sopra possiamo osservare il risultato di un test di login su un form di autenticazione in HTTP e di un'interrogazione IMAP su di un qualsiasi server di posta. Facile, no?




Access Point liberi


Facciamo un passo in avanti. Per catturare quelle informazioni abbiamo bisogno indubbiamente di un accesso fisico. Potrebbe essere più semplice, quindi, lasciare un simpatico Access Point aperto a tutti.

Ed ecco che:

  1. Installeremo e configureremo il sistema di emulazione AP (15m)
  2. Creeremo le regole di NAT dalla (nel nostro caso) wlan2 alla br0 (5m)
  3. Installeremo e configureremo un Server DHCP per rilasciare gli indirizzi alla wlan (15m)






E come una carta moschicida, in un attimo avremo il traffico (e quindi le relative password) di chi vi si connette, dando in cambio un po' di banda.

Spiegato, concretamente, uno degli evergreen della sicurezza "user-side": mai connettersi a reti non affidabili o aperte. Il rischio di incappare in reti volontariamente lasciate aperte per raccogliere dati è altissimo.



Proxy SSL


Spostiamoci ancora più in là. Creiamo un proxy al cui interno fare decrypt del traffico crittografato. Il funzionamento è pressappoco questo (agiremo creando delle semplici regole di NAT in grado di intercettare le porte su cui il traffico non in chiaro tradizionalmente avviene):






L'utente, come spesso accade, avrà una richiesta di accettazione di un certificato (a sinistra una connessione sicura, a destra una alterata). E' evidente che qualsiasi proxy deve necessariamente riscrivere il traffico, quindi il massimo che si può fare è generare un certificato per la porzione di traffico Proxy-Client.


All'interno del proxy SSL, quindi, vi è una generazione di un certificato forgiato ad hoc per la sessione, ed ogni sessione ha il suo certificato creato in real time con lo scopo di ingannare l'utente.



Sostanzialmente tutto il traffico originariamente crittografato, diviene in chiaro, esponendoci ai rischi di cui sopra.

Ed eccoci al secondo evergreen informatico: "non accettare mai tutti i certificati, ovvero non cliccare sempre e solamente su continua".


NB: Se si importa la root CA del proxy, e quindi l'attaccante ha accesso alla macchina client, i certificati vengono visti come verdi!





More, more and more...


Non ci siamo spinti oltre, non abbiamo parlato di arp poisoning con lo scopo di dirottare il traffico verso di noi al posto del gateway (magari lo faremo in un prossimo articolo), non abbiamo parlato di DoS su WiFi con lo scopo di sostituirsi ad un Access Point, non abbiamo parlato di fake web page con lo scopo di fare injection di codice malevolo... insomma... c'è tanta carne sul fuoco già in questo articolo.

Le morali della favola sono:
  • Evitare come fosse peste bubbonica le connessioni in chiaro (se un sito è HTTP, inserire credenziali non è mai una buona idea)
  • Quando un certificato https è "rosso", c'è un motivo. E se il browser vi segnala un problema, tenetene conto.



giovedì 7 aprile 2016

Cosa succede quando si risparmia troppo sullo storage in un ambiente virtuale?

In ambiente virtuale, il datastore è sicuramente uno degli aspetti più importanti e più sottovalutati in assoluto. Non è inusuale vedere errori grossolani di dimensionamento ed osservare un sovrautilizzo dei dischi SATA (lenti per definizione) e di RAID hardware con performance poco più di "fake raid".

Questo è vero sia quando il datastore è locale e direttamente collegato al singolo server, sia (e peggio) quando il datastore è condiviso da un pool di server.



Tipologie di SAN


Qui abbiamo approfondito come creare una SAN iSCSI con dischi in RAID su una LUN LVM Linux affinchè sia collegata con un pool di server VMWare. Questo procedimento non è differente da cosa accade nei NAS economici, anch'essi con una loro distribuzione linux che si occupa di gestire i dischi ed i collegamenti. Questa architettura, tuttavia, ha dei profondi limiti.

Possiamo dire, riassumendo banalmente, che gli storage si dividono (non me ne volete, è una mia personale classificazione) in:
  • Software Storage (molto economici), ovvero tutti i marchi che utilizzano a bordo un OS Linux e la suite md a gestione dei raid (o anche un Windows Storage Edition, se preferite)
  • Hardware Storage (molto costosi), ovvero tutti i marchi che implementano principalmente a livello hardware la gestione dei dischi
Nel primo caso vedremo ovviamente delle latenze e, per quanto performante potrà essere il sistema, non potrà mai avere un paragone che non sia schiacciante verso la più performante soluzione hardware. Ma si può fare qualcosa? Abbiamo margini di movimento? Lo vedremo nel proseguo dell'articolo.




I costi


In verità non ci sono grandi vie di mezzo sull'aspetto economico. C'è una linea di demarcazione che suddivide nettamente il prodotto "Software" più costoso dal prodotto "Hardware" più economico. Questo mette in difficoltà chi, come me, sviluppa anche progetti e preventivi. Da un punto di vista è facile risultare costoso e perdere di competitività, da un altro è facile quotare un prodotto economico ma non in grado di essere all'altezza delle aspettative (e questo in ambienti virtuali è un disastro).
Allora ho deciso di dedicarmi all'ottimizzazione di un prodotto economico, impiegando (purtroppo) mesi nell'osservazione e nell'affinamento di tutto il possibile per spingere al massimo lo storage software, basato su linux, che avevo tra le mani.



Ottimizzazione di un prodotto commerciale basato su Linux


Il prodotto su cui ho lavorato, un top di gamma di un noto produttore dal nome breve, aveva 8 dischi da 4Tb SATA WD RE, per un totale nominale di 32Tb. Processore Xeon, 32Gb di RAM ECC e 8 NIC, di cui 4 a 10Gbit. In aggiunta, due dischi M2 SSD da 128GB in RAID1 a fare da cache sia in lettura sia in scrittura.

A leggere i datasheet ed i performance test, era una Ferrari. Poteva essere usato anche al CERN di Ginevra. La verità è stata decisamente più mesta ed impietosa.

I primi due mesi, abbiamo avuto latenze così gravi e performance così basse da avere macchine corrotte, datastore persi dagli host, storage vmotion falliti. La media delle latenze si aggirava intorno ai 600ms (e per chi non lo sapesse, oltre i 40ms uno storage è già palesemente e gravemente in crisi).

Non ci siamo persi d'animo, per i successivi 6 mesi è stato un continuo di ticket aperti con il supporto oltre continente, ma senza alcun esito. 6 mesi del tutto inconcludenti. Senza contare gli innumerevoli bug scovati che ci hanno indotto a pensare a processi qualitativi di revisione del software decisamente carenti.

Questo ne è un esempio: cache SSD abilitata, a detta del produttore una features in grado di velocizzare esponenzialmente lo storage. Peccato che, a dischi SSD pieni, le operazioni di riciclo della cache diventavano una cozzaglia di colli di bottiglia così gravi da mandare durante qualche storage vmotion persino in timeout il datastore su vmware (14 secondi, QUATTORDICI SECONDI DI LATENZA, avete letto bene) con una frequenza di una volta ogni 4-5 giorni.


Data Rate

 Latenze (forse il parametro più importante)






Gli ultimi due mesi abbiamo deciso di invalidare la garanzia e mettere mani direttamente al sistema linux. Abbiamo fatto decine di cambiamenti e soprattutto centinaia di test in ogni condizione e con ogni variazione possibile ed immaginabile, sia lato vmware sia lato SAN. Abbiamo prodotto più fogli excel e grafici di quanto avrei voluto, ma lavorando molto sull'utilizzo corretto della RAM dello storage intesa come cache, coinvolgendo il supporto al controllo SIOC di vmware, utilizzando la vFlash (features comunque così costosa da non avere un senso ed una applicabilità reale con apparati SAN così economici) e apportando una marea di variazioni, siamo riusciti ad avere il massimo matematico che potevamo ricavare da quell'hardware. Sufficiente? Dipende ovviamente da cosa ci deve girare e dalla mole di lavoro che hanno le VM.





Credeteci, abbiamo fatto innumerevoli test. Questo articolo tuttavia non vuole fare una statistica degli storage più o meno performanti, quindi marchi e modelli sono stati oscurati. Lo scopo è solo capire se uno storage "software" top di gamma può arrivare a performance similari ad uno "hardware" entry level.



Dopo quasi un anno di lavoro e di test, queste sono le mie personalissime conclusioni


Storage economici possono essere utilizzati solo per sistemi di backup, tipicamente con scritture relativamente sequenziali, impegnative come throughput ma meno sensibili a latenze elevate. 

In ambienti di produzioni, onestamente, dopo aver subìto macchine corrotte e dopo il tempo e gli sforzi che sono serviti ad avere un prodotto stabile e al limite dell'accettabile, non consiglierei questa soluzione nemmeno al mio peggior nemico. Vada per gli ambienti di test, vada anche per un paio di Domain Controller, ma per metterci database o fileserver ci vuole tanto coraggio. E nei miei test non ho usato proprio una macchinetta, ho preso il massimo, equipaggiato con il massimo delle opzioni ed i dischi più enterprise che il mercato SATA offriva.

Sostanzialmente, per quanto abbia tentato con tutte le mie forze e sperato di avvicinare uno storage "software" ad uno con hardware dedicato e specifico per questo scopo, le differenze sono e rimangono abissali ed i costi rispecchiano, in conclusione, esattamente i risultati ottenuti.

Senza considerare che le soluzioni hardware consentono solitamente anche la ridondanza a caldo dei controller ed hanno mediamente un bacino di clientela enterprise, con un livello di supporto decisamente migliore.

giovedì 3 marzo 2016

Creare una SAN iSCSI con dischi in RAID su una LUN LVM Linux per VMWare

Sono ormai mesi che sperimento storage con un occhio particolare verso il collegamento su vmware. La parte storage è indubbiamente un punto dolente per chi fa virtualizzazione, ed abbiamo dedicato intere giornate per incrementare le performance senza andare necessariamente su macchine enterprise (per intenderci, da 50k€ in su), mantenendoci quindi in un contesto più a portata di portafoglio per tutte quelle realtà con due host e senza troppe pretese.

Ho avuto modo di lavorare su svariate macchine, QNAP, Netgear ReadyNas, Synology, etc.. fondamentalmente tutte basate su Linux. Una delle perplessità maggiori nasce dal fatto che tutte queste macchine hanno in comune la possibilità di erogare centinaia di servizi del tutto inutili per chi vuole solo collegare delle LUN via iSCSI, con le massime performance possibili.

Quindi, come creare una macchina dedicata a questo scopo e che sia sufficientemente performante a prezzi ragionevoli?


Cosa ci serve


  • Una macchina decente, nel nostro caso uno Xeon quad core;
  • Possibilmente dischi di tipo enterprise, nel nostro caso 8x4Tb WD RE (qui ne parliamo abbondantemente);
  • Linux Debian, scaricabile da qui;
  • Abbastanza RAM, nel nostro caso almeno 24Gb (ci servirà da cache);
  • Quattro NIC 10Gb sullo storage e (nel nostro caso, trattandosi di due host esx) 2 NIC 10Gbit per host, che verranno collegate in direct attach (rame) per contenere i costi della parte network


Cosa realizzeremo?



Una SAN iSCSI 4x10Gbit, nel nostro caso con 32Tb nominali in RAID6 con 20Gb di Cache su RAM.




Architettura






Prepariamo il sistema


1. Installiamo Debian sulla nostra macchina SAN 

(non mi soffermerò oltre su questo aspetto, la rete è piena di guide ed how-to, del resto si presuppone che questa operazione sia alla portata di chi lavora con questi strumenti


2. Aggiorniamo e prepariamo il sistema

apt-get update
apt-get upgrade
apt-get install vim iotop iscsitarget lvm2 hdparm

3. Creiamo il RAID

Ovviamente è necessario modificare i dischi in base alla propria architettura

mdadm --create  --chunk=512 --verbose /dev/md0 --level=5 --spare-devices=0 --raid-devices=6 /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg

Le considerazioni sul livello del RAID, sulla sua affidabilità e sulle performance le facciamo in un altro articolo. Sono considerazioni di primaria importanza, ma troppo prolisse per essere affrontate in questo how-to.


4. Creiamo le partizioni sull'array

fdisk --compatibility=nondos /dev/md0
Creiamo la partizione con n
Primaria con p
Il numero è 1
Il resto è molto intuitivo, una volta terminato usciamo con w per salvare.

Abbiamo creato quindi /dev/md0p1


5. Creiamo le LVM (ci consentiranno, inoltre, di aggiungere spazio a caldo all'aumentare dei dischi)

pvcreate /dev/md0p1 (creazione del physical volume) 
vmcreate vg_iscsi /dev/md0p1 (creazione del vollume group) 
lvcreate -L 2T -n lv_iscsi vg_iscsi (sostituire 2T con la dimensione voluta, creazione del logical volume)

A titolo informativo:
cpn pvs vediamo i physical volume
con vgs i volume group
e con lvs i logical volume


6. Impostiamo la parte network iscsi

Nel nostro caso abbiamo utilizzato NIC con supporto TOE, 10Gbit ed essendo collegate in Direct Attach preferisco assegnare loro 4 classi differenti e far fare Round Robin a vmware:

NAS_NICn ------------------------ HOSTn_NICn
eth0 10.20.30.1/30---------------- Host1_eth0 10.20.30.2/30
eth1 10.20.30.5/30---------------- Host1_eth1 10.20.30.6/30
eth2 10.20.30.9/30---------------- Host2_eth0 10.20.30.10/30
eth3 10.20.30.13/30-------------- Host2_eth1 10.20.30.14/30




6. Inizializziamo la parte di iscsi target

vi /etc/default/iscsitarget 
ISCSITARGET_ENABLE=true

Impostiamola

vi /etc/iet/ietd.conf 
Target iqn.2016-03.local.mynas:storage.sys0 
Lun 0 Path=/dev/disk/by-id/dm-name-vg_iscsi-lv_iscsi,Type=fileio,ScsiId=lun0,ScsiSN=lun0


Avviamola

service iscsitarget restart


9. Ottimizziamo la cache

In base a quanta RAM abbiamo, possiamo definire quanta ne deve utilizzare l'array.

Nel nostro caso, 24Gb di RAM, 8 dischi, possiamo definire tranquillamente 16384 pagine per disco
echo 16384 > /sys/block/md0/md/stripe_cache_size
Controlliamo frequentemente la RAM, NON dobbiamo assolutamente andare in swap (vanificheremmo completamente la cache), quindi se serve riduciamo quel valore! Facciamo in modo da avere sempre almeno 1Gb di ram libera

free -m 
                      total       used         free     shared    buffers     cached
Mem:         24576      22179         2397          8      10552        688
Swap:           7628             0         7628


10. Colleghiamo via iscsi gli host vmware esxi


Aggiungiamo in configuration > storage gli adapter iscsi



Ognuno con la sua NIC ovviamente collegata



Creiamo due virtual switch, uno per NIC (se tutte le NIC supportano i jumbo frame, utilizziamoli portando l'MTU a 9000 sia del virtual switch sia della VMKernel Port)




Dopo i vari rescan, assicuriamoci che il percorso venga raggiunto in Round Robin (dai nostri test è emerso che questa è la soluzione più performante) tramite il tasto destro sul Device > Manage Path






11. Attendiamo che il rsync sia terminato prima di fare ogni test di performance 
(su questo aspetto ne parleremo in seguito, utilizzando iperf per la parte network, hdparm per il sistema NAS e la macchina virtuale vmware iometer per la parte datastore VMFS)

watch -n 5 "cat /proc/mdstat" 
      [==============>......]  resync = 73.7%  finish=216.0min speed=98800K/sec

mdadm --detail /dev/md0 


Durante la fase di inizializzazione, è del tutto normale che un disco venga messo come spare device, serve a velocizzare le operazioni di rebuilding. Sostanzialmente il RAID 5 viene portato a RAID 3. Al termine, i devices verranno riportati a RAID 5 automaticamente.



Performance


Con iperf abbiamo misurato circa 4,1Gbit per NIC di banda di rete utilizzabile. 2 NIC da 10Gbit ci erogano, quindi, circa 7-8Gbit reali utilizzabili in Round Robin in Direct Attach, senza considerare il minor overhead generato dai jumbo frame a 9000. Lato network, con questa configurazione, tenderei ad escludere colli di bottiglia.

Con VMWare IOMeter, la macchina virtuale di vmware dedicata ai test di performance degli storage, abbiamo ottenuto questi valori (256k/120s):

100% Random, 50%Write e 50%Read
IOPS (R/W): 1914 / 1914
TROUGHPUT (R/W) MByte/s: 478 / 478
Latenza (R/W) ms: 3,62 / 3,93 

Frutto ovviamente di una cache molto generosa.


Questo è ciò che ci dice hdparm direttamente sullo storage:

hdparm -tT /dev/md0
/dev/md0:
 Timing cached reads:   56652 MB in  1.99 seconds = 28427.91 MB/sec
 Timing buffered disk reads:  2448 MB in  3.00 seconds = 815.92 MB/sec

E' evidente che hdparm dia un risultato in lettura particolarmente favorevole perchè, con un numero di meccaniche elevato, la lettura ne beneficia. Il penalty dei RAID 5 e 6 è alto proprio in scrittura, quindi da quel valore possiamo desumere che, invece e senza cache in write, un R5 di 8 meccaniche SATA restituisca appena 200MB/sec reali. Qui c'è poco da fare, dischi SAS 10k e 15k rpm o, meglio ancora i dischi SSD, uniti ad una buona e corposa cache, ci aumentano esponenzialmente le performance. 

Alla fine in uno storage i costi maggiori si concentrano sui dischi, e questo è del tutto giustificato da delle performance che rispecchiano il budget investito.



Conclusione


Con circa 2k€ abbiamo creato una SAN che sul mercato, con quelle performance, costa mediamente il triplo. Una SAN, inoltre, che è pulita da tutte le appendici che si porta dietro un prodotto NAS e soprattutto esente da attacchi e vulnerabilità tipiche dei prodotti commerciali (ci sono varianti di cryptolocker specifiche per i vari vendor di NAS).

Ovviamente questa è solo una guida rapida, al lettore il compito di approfondire e personalizzare ogni voce, tra cui innanzitutto impostare un meccanismo di autenticazione iscsi.

Utilizzerei questo sistema in un ambiente di produzione? Lo utilizzerei per i backup e per piccoli cluster vmware, ma davvero piccoli. Per architetture più performanti, con accessi su database, andrei su una SAN pensata e nata per fare solo questo, evitando assolutamente qualsiasi apparato che faccia anche da NAS. Farsi molto male con un sistema dalle prestazioni degradate è un attimo, latenze superiori ai 15ms sui datastore vmware si traducono in evidenti disagi per chi utilizzerà quelle macchine, questo è uno dei motivi per cui progettare bene la parte storage è assolutamente fondamentale in ambienti virtuali.



Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

mercoledì 10 febbraio 2016

Quanto è rischioso Windows XP nel reale? 1 anno dopo...

Da aprile 2014 è terminato il supporto extended ad XP SP3, cessato definitivamente il 31/12/2014. A questo si aggiunge il termine del supporto di Explorer 8.

Un prodotto non aggiornato è un prodotto che, con il passare del tempo, diverrà sempre più vulnerabile. Nuovi exploit su codice che non verrà mai corretto garantiranno un accesso indisturbato. 

L'intera sicurezza informatica, del resto, si basa su un perpetuo rincorrersi tra chi scopre una falla e chi vi pone rimedio. I più astuti mantengono le informazioni per loro, sfruttandole il più possibile nell'arco temporale massimo. I più "pigri" finiscono per utilizzare software in grado di raccogliere queste informazioni (quando ormai sono divenute pubbliche) e applicarle, delle volte, senza nemmeno troppe competenze. Il nostro laboratorio utilizza questa seconda, estremamente accessibile, tecnica.

Ma nel concreto?

Nel concreto facciamo un interessante esperimento per capire, un anno abbondante dopo il termine del supporto, quanto è esposta una macchina Windows XP appena formattata, aggiornata e pulita.

Attenzione: questo non è un tutorial su come effettuare queste manovre, ma un esperimento di sicurezza. Richieste di informazioni sulle modalità di accesso non autorizzato non avranno seguito.

Fase 1 - Installiamo Windows XP Pro ex novo





Fase 2 - Aggiorniamo Windows XP ed installiamo un antivirus qualsiasi

Per quanto l'antivirus non agisca a livello di remote command execution, dissipiamo ogni perplessità simulando uno scenario reale.



Possiamo asserire senza dubbio che, concettualmente, una macchina appena formattata, aggiornata e pulita sia esente da problemi derivati da software esterni. Non è stato installato null'altro, neanche Java o Flash. Giusto i vmware tools.



Fase 3 - Analisi ed Exploit

Come da premessa, questo non è un tutorial su come prendere il controllo di una macchina XP, quindi informazioni utili a questo scopo saranno oscurate.

A questo punto è sufficiente utilizzare una distribuzione linux opportunamente forgiata per eseguire dei vulnerability scanner e trovare degli exploit da applicare mediante tool estremamente noti.







Fase 4 - Accesso

Ben 3 exploit hanno concesso un accesso privilegiato come administrator.




Fase 4 - Permanenza

Una volta aperta una shell all'interno del sistema operativo, facilmente ci si può creare un accesso permanente e persistente anche dopo il riavvio.


Pur potendo l'antivirus intervenire, è evidente che un accesso amministrativo ci consente la sua neutralizzazione.


Conclusioni

Intendiamoci, non è un'operazione semplice ed alla portata di tutti. Ma non è nemmeno un'operazione particolarmente complessa per chi ha dimestichezza con questo tipo di azioni. Ad ogni modo, in un paio di minuti scarsi, una macchina XP appena formattata e aggiornata è stata compromessa completamente senza l'utilizzo di alcun software eseguito sull'host vittima e senza alcuna azione di tipo umana avviata dall'operatore. Al lettore l'arduo compito di trarne conclusioni in piena autonomia.


lunedì 1 febbraio 2016

ReadyNAS e VLAN

Se avete un ReadyNAS Netgear (ma probabilmente la soluzione si applica a tutti i nas linux based), spesso utilizzato per backup, può accadere di voler renderlo visibile su più VLAN 802.1q. Nativamente il software non consente questo tipo di configurazione, tuttavia entrando in ssh si accede all'ambiente Linux (farsi un backup preventivo dei dati non è mai una trovata erronea).


Per prima cosa aggiorniamo il sistema di repository ed installiamo vconfig:
apt-get update
apt-get install vconfig


Poniamo il caso di voler aggiungere la vlan con vid 123 che ha come rete 192.168.123.0/24 e come ip del nas 192.168.123.10, andremo a dare questo comando:

vconfig add eth0 123 
ifconfig eth0.123 192.168.123.10 netmask 255.255.255.0 broadcast 192.168.123.255 up

Con il primo comando creiamo la vlan, con il secondo creiamo l'interfaccia virtuale visibile con il classico ifconfig .

In alcuni casi viene creata una rotta statica erronea per i server DNS (probabilmente qualche automatismo del ReadyNAS), ponendo il caso di avere come dns 1.2.3.4 e 5.6.7.8 e come gateway della rete untagged (ovvero la rete di base su cui non abbiamo tag vlan) 192.168.1.1, i comandi da dare saranno questi:

route del -net 1.2.3.4 gw 192.168.1.1 netmask 255.255.255.255 dev eth0 
route del -net 5.6.7.8 gw 192.168.1.1 netmask 255.255.255.255 dev eth0

A questo punto sarà sufficiente creare un automatismo che all'avvio impartisca i comandi necessari (le modifiche si perdono al boot) opportunamente inseriti in uno script bash. 

vi /etc/ethinitvlan.sh 
#!/bin/bash
........
........
 
chmod +x /etc/ethinitvlan.sh



Ci sono molti modi per farlo (e decisamente più raffinati con gli init, con if-up, etc..), se non volete perderci troppo tempo, potreste creare una riga di cron così:

* * * * * root ISOK=$( route -n | grep "eth0.123" | grep "0.0.0.0" | wc -l ); if [ $ISOK -le 0 ]; then bash /etc/ethinitvlan.sh; echo "$( date ) inizializzate le vlan" >> /var/log/myvlan.info; fi
crontab /etc/cron 

riavviate e provate, dovrebbe funzionare tutto (ammesso che il vostro switch sia configurato correttamente). Adesso avete un nas in grado di erogare share di rete attraverso vlan differenti su una porta taggata 802.1q. Potreste, quindi, per aumentare il livello di sicurezza, creare delle condivisioni "per vlan" inserendo la network consentita. L'interfaccia del ReadyNAS lo consente ed utilizza gli hostallow di samba.


Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.

giovedì 14 gennaio 2016

Licenziamento in tronco per l'utilizzo privato delle email? Tanta confusione...

Di recente i giornali hanno riportato una sentenza della corte di Strasburgo relativa al controllo della posta elettronica aziendale dei dipendenti.


"MAIL e messaggi via chat controllati dai datori di lavoro che sono anche autorizzati a licenziare i dipendenti in caso di uso a fini personali durante l'orario d'ufficio. E' questa la sentenza della Corte europea dei diritti umani secondo la quale il controllo della posta elettronica (e dei programmi di messaggistica) e il licenziamento se l'uso è privato, non viola la privacy dei lavoratori."

"STRASBURGO - I datori di lavoro possono controllare l'uso che i dipendenti fanno della mail aziendale e sono anche autorizzati a licenziarli in caso di utilizzo a fini personali."
da ANSA


Iniziamo con il dire che c'è stata molta confusione e che gli articoli (di qualsiasi giornale o agenzia, non solo di quelli citati) hanno portato alla luce solo una parte della sentenza, omettendone completamente il resto. Come sempre più spesso accade, si tende al sensazionalismo.




Allo stato attuale, la nostra normativa sulla privacy non prevede l'accesso alle email personali, ovvero tutte le email nominali nome.cognome, n.cognome e così via. Prevede, invece, un utilizzo condiviso e accessibile alle email generiche, come info@, amministrazione@, ufficiotecnico@ etc. E' evidente, quindi, che in assenza di disposizioni diverse, l'accesso alle email personali è perseguibile per legge e non è un'operazione lecita (che poi avvenga o meno, non sta a noi dirlo). In questo articolo scritto quasi 2 anni fa, se ne parla approfonditamente: http://claudiodabbicco.blogspot.it/2014/02/monitoraggio-delle-connessioni.html.

Ogni azienda, tuttavia, ha la possibilità di creare delle policy interne che il lavoratore può anche non sottoscrivere. In caso di reale necessità, quindi, l'azienda può porre dei limiti agli strumenti che mette a disposizione dei propri lavoratori. Può, ad esempio, dichiarare che le email potrebbero essere controllate per "motivi di sicurezza" o "immagine aziendale". Così come potrebbe informare il lavoratore che rispondere ad un'email ufficiale con "xkè" è motivo di licenziamento in tronco, potrebbe anche definire un limite nell'utilizzo, confinando lo strumento all'uso esclusivamente aziendale. E' questo il caso che riguarda i due articoli sopra riportati, ovvero l'azienda poteva visionare le email e l'utilizzo personale della posta elettronica era stato esplicitamente vietato e causava il licenziamento immediato del lavoratore (che ne era a conoscenza perchè aveva sottoscritto la policy aziendale).

Spesso non si considerano aspetti importanti legati ad un utilizzo personale della posta aziendale, come l'esposizione dell'intero dominio a spam, virus, l'invio inutile di loghi aziendali a destinatari privati, l'utilizzo di banda e risorse economicamente a carico dell'azienda. Che differenza intercorre tra utilizzare un'auto aziendale per fini privati ed utilizzare invece l'email? Se l'idea comune è che l'email cada gratis come manna dal cielo e non abbia costi per nessuno... bhè, non è così.

A questo punto, la domanda è: perchè se tutti abbiamo almeno un account gmail, apple, yahoo, libero... non utilizziamo quello e lasciamo che le risorse aziendali vengano utilizzate solo per questo scopo? A prescindere da cosa e come abbiamo firmato. Ritengo sia una soluzione non solo più saggia, ma che ci garantirebbe una serie di vantaggi non da poco (basti pensare ad un cambio di lavoro con la conseguente perdita della propria casella di posta legata a tutti i servizi sottoscritti in anni di navigazione).



sabato 9 gennaio 2016

NSA, Juniper e Computer Quantistici. Il punto.

Facciamo un attimo il punto su due argomenti d'attualità che riguardano da vicino il mondo della sicurezza informatica.


NSA e la vicenda Juniper


Di recente Juniper, nota e diffusissima azienda di firewall hardware, ha scoperto codice malevolo inserito all'interno del proprio firmware.
Si vocifera che, con ogni probabilità, vi sia un coinvolgimento della solita NSA, l'agenzia di sicurezza nazionale americana. Dopo ricerche e revisioni di codice, si è anche scoperto che governi stranieri erano a conoscenza della backdoor inserita dall'NSA e ne hanno sfruttato l'esistenza per avvantaggiarsi a loro volta e controspiare l'agenzia americana.

Cisco ed altri competitor hanno dichiarato di aver avviato un processo interno di revisione del codice, volto ad identificare intromissioni simili. Non c'è da stupirsi, Juniper non sarà nè la prima nè l'ultima ad essere implicata in questo fenomeno, aspettiamoci casi simili anche su altri contesti e con altri vendor.

Fermo restante che l'injection di codice malevolo a quei livelli difficilmente può avvenire senza aver compromesso una risorsa interna all'azienda, è evidente quanto si svolga quotidianamente una guerra senza esclusioni di colpi. Può lo spauracchio del terrorismo giustificare la violazione costante, incontrollata e violenta della nostra privacy? Intendiamoci, la rete non è un far west, è giusto che gli organi competenti abbiamo strumenti per gestirla... ma fino a che punto i controllori debbano avere carta bianca e poteri illimitati?




Computer Quantistici


E' odierna la notizia di un computer quantistico dichiaratamente funzionante: http://www.repubblica.it/tecnologia/2016/01/08/news/google_il_nostro_computer_quantistico_funziona_-130785803/ originariamente presentato nel 2013.

Tempo fa parlavamo della crittografia quantistica in questo stesso blog. Ricordiamo che un computer quantistico sfrutta il qubit al posto del bit, aprendo a delle potenzialità di calcolo inimmaginabili con l'attuale limitata codifica binaria. https://it.wikipedia.org/wiki/Computer_quantistico



Il risvolto meno noto di avere, ad oggi, un computer quantistico funzionante è la possibilità  di trovare una soluzione a problemi matematici complessi in tempi ragionevolmente brevi. Sembrerebbe una cosa positiva, ma in realtà non lo è soprattutto per determinati settori dell'informatica. Tutta la crittografia moderna si basa su problemi matematici complessi e fattorizzazione di numeri primi. Problemi che, con i mezzi tradizionali, richiedono una capacità di calcolo estremamente elevata e, di conseguenza, un tempo estremamente lungo per essere risolti e quindi vanificare il processo crittografico. Sostanzialmente l'avanzare della capacità di calcolo, così come lo è stato l'introduzione del calcolo distribuito (basti pensare a macchine zombie e botnet integralmente dedicate a questo scopo), è un vero e proprio incubo che avvicina sempre più pericolosamente il bastone e la carota.

Morale della favola: se una macchina è in grado di sfornare performance 100 milioni di volte maggiori nella capacità di calcolo, questo non può che minare direttamente le basi della crittografia, riscrivendo il paradigma per cui "se per forzare questa chiave ho bisogno di 10 anni, allora è sufficientemente sicura".

Che vantaggi ha invece l'impiego della tecnologia, ad oggi, nel mondo reale? Probabilmente quasi nessuno (eccezione fatta per pochi isolati casi), perchè la capacità di calcolo è già da tempo solitamente abbondante nelle nostre sale CED e non è probabilmente più il fattore limitante da molti anni. Basti pensare a quanto il mondo dello storage sia rimasto indietro, con latenze e performance dettate da lenti accessi magnetici ancora in uso per via della relativa giovinezza (e quindi costo) del mondo SSD. Intendiamoci, c'è scenario e scenario.

giovedì 5 novembre 2015

Numeri e statistiche dell'IT Security in Italia

Di recente il Clusit ha rilasciato il suo consueto ed annuale rapporto sull'IT Security focalizzato principalmente nel nostro Paese. L'ottimo ed esemplare rapporto, unito all'affidabilità dell'organizzazione e ad autorevoli autori, disegnano un quadro prevedibile ed in linea con quanto spesso citato nei precedenti articoli di questo blog.
Proviamo a guardare qualche numero non solo riportato dal Clusit, ma anche da altre comprovate fonti.

  • Nel 2014 gli investimenti globali in sicurezza delle infrastrutture informatiche è cresciuto dell'8%, nonostante la crisi mondiale abbia colpito qualsiasi settore.
  • In Italia i danni causati da attacchi informatici si aggirano intorno ai 9 miliardi (per intenderci, la tanto discussa manovra dell'IMU è di 4 miliardi).
  • I danni derivati da attacchi informatici, sempre in Italia, hanno superato la somma dei problemi hardware, software e di interruzione elettrica.
  • E' cambiato il parametro di misurazione da "ricevere/non ricevere un attacco informatico andato a buon fine" a "quando riceverò un attacco informatico che andrà a buon fine", sostanzialmente si da per scontato che prima o poi qualcosa succederà.

Come riportato dal precedente articolo, 2015Q1Q2 Considerazioni in ambito sicurezza informatica, è evidente un "incattivimento" degli attacchi. Assistiamo sempre meno ai fenomeni Hacktivisti e sempre più ad attacchi finalizzati al lucro. Lo scenario informatico si è evoluto, svezzato, portandoci verso una perdita di "pseudo-etica" che, nel bene o nel male, caratterizzava spesso questo tipo di azioni.

Anche le tipologie di attacco, come previsto, sono differenti. I fenomeni hacktivisti veicolano attacchi tecnicamente spesso meno evoluti (non per questo meno dannosi), come i DDoS, a differenza di attacchi commerciali di spessore ed elevatura normalmente più raffinati. In entrambi i casi, certamente, ci sono eclatanti eccezioni. 


A proposito dei DDoS, il tempo medio di un attacco finalizzato ad interrompere un servizio, è aumentato da 4h a 22h e nel 2014 abbiamo assistito ad un attacco record da 321Gbit/s (in grado di mettere in crisi anche ISP e AS importanti). E la risposta è "si", avete letto bene.




Tra i settori maggiormente colpiti, ovviamente, il cloud, il gaming e soprattutto si nota un incremento esponenziale dell'hacking governativo mosso o ricevuto da enti di questo tipo (CyberWarfare).



Utilizzare i social per cambiare l'opinione pubblica


Interessanti valutazioni stanno prendendo in considerazione anche i fenomeni di "Psychological Warfare" e "Percepition Management", veicolati attraverso i Social Network con lo scopo di fare pressioni psicologiche e cambiare la percezione della realtà su larga scala. Fenomeno tutt'altro che banale e che, a conti fatti, sta sortendo effetti devastanti (basti pensare alle vicende legate ai vaccini, ma è solo l'esempio più eclatante). Nel 2012 un rapporto governativo Italino evidenziava come i profili creati "ad hoc" stessero drammaticamente incrementando e venissero seguiti con costanza. Nel 2013 il governo degli stati uniti monitorizzò una notizia falsa (riguardava l'aggressione di un poliziotto verso un uomo di colore). La notizia ebbe una diffusione enorme (oggi la chiameremmo "virale", nel 2013 questo termine non esisteva). La stessa fonte rilasciò la smentita e questa rettifica, invece, ebbe una diffusione di appena il 24% rispetto alla notizia reale.
Morale della favola, alla fine sono sempre gli utilizzatori l'anello debole. Vuoi per sensazionalismo (condivido nonostante la fonte non autorevole), vuoi per ingenuità (condivido senza accertarmi della fonte), vuoi per disattenzione (condivido credendo sia una fonte autorevole), la circolazione di notizie la cui fonte è assolutamente non attendibile è uno dei cancri sociali del nostro tempo.


giovedì 15 ottobre 2015

L'altra faccia del Cloud...

Ormai si sente spesso parlare di servizi Cloud, una storia che i più nostalgici chiamavano, in tempi non sospetti, Outsourcing. Sta prendendo certamente piede, ha indubbi e tangibili vantaggi e si vende molto facilmente grazie alla tipologia di vendita tipica delle diete caratteristiche di chi soffre di gastrite come me, ovvero "pagami poco, ma pagami spesso" (che poi il costo al cliente finale sia davvero più conveniente di un investimento iniziale, questo è tutto da vedere e nella maggior parte dei casi facilmente si può evincere come non sia così).

Si narra che l'Imperatore della Cina, preso dal nuovo gioco degli scacchi, volle ricompensare il suo inventore chiedendogli cosa avesse voluto in dono. "solo un chicco di riso nella prima casella, due chicchi nella seconda, quattro nella terza e così via, vostra maestà", rispose l'inventore degli scacchi. Stupito l'Imperatore rispose "tutto qui?", acconsentendo e pensando fosse una richiesta del tutto irrisoria. Arrivati a metà scacchiera, il conto riportava quasi 4 miliardi di chicchi di riso, ovvero una risaia intera. A fine scacchiera l'imperatore, per mantenere la sua parola, non potette fare altro che cedere il suo impero.

Questo simpatico aneddoto introduce il punto 1.


I costi


Apparentemente, 9 euro al mese per un office non sono tanti. In un anno diventano 108, in 20 mesi mi sono ripagato una licenza permanente e tipicamente un PC con office dura in media 5 anni portandomi ad un costo di 540 euro (l'office, in buona sostanza, mi è costato 3 volte).

Possiamo fare innumerevoli considerazioni su quanto office 365 offra molti più servizi (offra? tolga?) di una licenza permanente e limitata ad una singola macchina. Ed io sono d'accordo. Ma francamente ad un utente serve l'office per lavorare sul suo foglio excel o word... punto.

E' solo un esempio, non è mia intenzione prendere il caso specifico di office 365, ma non è inusuale che i costi della stragrande maggioranza dei servizi in cloud appaiano piccoli e frammentati, ma poi sommati e attualizzati ad una media ed una aspettativa di vita di un servizio, diventino considerevoli.

Altro aspetto è il concetto di "espansione". Hai a disposizione 100, la tua attività è cresciuta, auguri e felicitazioni, adesso mi devi 100+10. Spesso però, quando contestualizziamo questo aspetto, siamo più che felici di pagare qualcosa in seguito ad un incremento della nostra attività. Ma è davvero così? I dati crescono con l'aumentare dei nostri introiti? Non mi sembra. I dati crescono perlopiù con il passare del tempo, e così ci porteremo dietro un "carrozzone" sempre più ingombrante.





Dove sono i miei dati?


Bella domanda. Alcuni dichiarano esplicitamente dove si trovano i dati. Altri, i più grandi, semplicemente li sparpagliano tra i propri datacenter. I miei dati, sostanzialmente, non sono più ben localizzati, confinati, definiti. Al contrario, diventano spesso un fantastico puzzle le cui sembianze ed i cui contorni sono del tutto ignoti.

Ecco qualche esempio:

"I dati personali raccolti da Google possono essere archiviati ed elaborati negli Stati Uniti d'America o in qualsiasi altro Paese in cui Google è presente attraverso proprie strutture o propri agenti.". "Un Cliente residente in un Paese al di fuori degli Stati Uniti accetta inoltre di rispettare tutte le normative locali in materia di condotta online e contenuti accettabili, incluse le leggi che disciplinano l'esportazione e la riesportazione di dati verso o dagli Stati Uniti e il Paese in questione."

Non sottovalutiamo che, dopo il Patriot Act, c'è una certa "goliardia" nel concetto di privacy.

Indubbiamente datacenter più piccoli e specializzati (ad esempio il classico esempio di "gestionale in cloud") offrono più vantaggi sotto questo aspetto.

Non ultimo, è bene ricordare che l'art.25 comma 1 della direttiva 96/46/CE e l'art.45 del Codice Privacy impongono serie restrizioni sulla trasferibilità dei dati fuori dalla Comunità Europea, anche temporaneamente.






I miei dati sono al sicuro?


Quando la nuvola diventa temporalesca, si scappa. C'è poco da fare, se i dati vengono persi, i fattacci sono i tuoi. Non c'è provider che non ti faccia firmare la clausola di esclusione di responsabilità. E non c'è datacenter che non abbia mai incontrato problemi di Data Loss.

Ecco qualche policy simpatica che nessuno legge:

LIMITAZIONE DI RESPONSABILITÀ 
L'UTENTE RICONOSCE E ACCETTA ESPRESSAMENTE CHE GOOGLE E I PARTNER NON SARANNO RESPONSABILI NEI SUOI CONFRONTI PER QUALSIASI DANNO DIRETTO, INDIRETTO, INCIDENTALE, SPECIALE, CONSEQUENZIALE O ESEMPLARE, INCLUSI, A TITOLO ESEMPLIFICATIVO, I DANNI PER LA PERDITA DI PROFITTI, AVVIAMENTO, USO, DATI O ALTRE PERDITE INTANGIBILI (ANCHE SE GOOGLE O I PARTNER SONO STATI AVVISATI DELLA POSSIBILITÀ DI TALI DANNI.) DERIVANTI DA: (i) USO O IMPOSSIBILITÀ DI UTILIZZARE I SERVIZI GOOGLE, (ii) COSTO PER IL PROCACCIAMENTO DI BENI O SERVIZI SOSTITUTIVI RISULTANTI DA MERCI, DATI, INFORMAZIONI O SERVIZI ACQUISTATI O OTTENUTI O DA MESSAGGI RICEVUTI O TRANSAZIONI CONCLUSE TRAMITE O DAI SERVIZI GOOGLE, (iii) ACCESSI NON AUTORIZZATI O ALTERAZIONI DELLE TRASMISSIONI O DEI DATI DELL'UTENTE, (IV) DICHIARAZIONI O CONDOTTA DI QUALSIASI TERZA PARTE SUI SERVIZI GOOGLE O (v) QUALSIASI ALTRO ASPETTO CORRELATO AI SERVIZI GOOGLE. 

Ma troviamo casi simili anche altrove:


Insomma, i backup non sono un opzional, anche se l'infrastruttura non è la tua. E la cosa, paradossalmente (avevamo scelto il cloud proprio per non occuparci della manutenzione dei nostri dati), si complica parecchio quando i sistemi non sono i tuoi.



Rivoglio indietro i miei dati!


Una volta nella nuvola, riavere indietro i propri dati non è sempre semplice.
Per trasferire il software e i servizi a governi di paesi sottoposti a embargo o ad alcune parti verso le quali esiste il divieto di esportazione, il licenziatario dovrà ricevere l’autorizzazione del governo degli Stati Uniti. Per ulteriori informazioni, il licenziatario potrà leggere il documento treasury.gov/resource-center/Documents/soc_net.pdf. Inoltre, i servizi a pagamento sono soggetti alle leggi e ai regolamenti vigenti negli Stati Uniti in materia di controllo dell’esportazione. Il licenziatario dovrà conformarsi a tali leggi e regolamenti. Queste leggi includono limitazioni circa le destinazioni, gli utenti finali e l’utilizzo finale. Per ulteriori informazioni, il licenziatario potrà visitare la pagina www.microsoft.com/exporting.
Ho appreso ieri che Google stessa pone pesanti limitazioni sul recupero dei tuoi dati se vuoi cessare il servizio. Restrizioni che rendono estremamente difficoltoso il passaggio altrove.



Conclusione


Voglio essere chiaro: io non sono contro il cloud. Ha aperto scenari importanti, vero, ma spesso è stata una forzatura e le aziende hanno sottoscritto contratti che definire "alla leggera" è un eufemismo. Troppo spesso ci si dimentica che i dati di un'azienda sono un patrimonio inestimabile, più degli automezzi, più degli immobili e spesso persino più di ogni altra cosa. Quando i dati della contabilità o i dati dei CAD di produzione vengono persi, ci si rende conto del vero valore di quelle informazioni. Un'azienda non compra alla leggera un immobile, perchè dovrebbe dare i propri dati così superficialmente? Senza valutare poi i rischi legati all'assenza di connettività e ai danni che questa può arrecare alla produttività.
Il cloud è un fenomeno interessante, ma non sempre. Il cloud privato, ad esempio, può essere una strada ibrida e che può preservare la riservatezza ed il controllo del nostro patrimonio informatico, pur erogando tutti i servizi estremamente comodi ed interessanti tipici del cloud.


Si rimanda ad un utile documento informativo redatto dal Garante della Privacy che riporta un interessante e condiviso decalogo che andrebbe consultato prima di decidere di spostare i propri dati nella nuvola. Reperibile QUI.