Archivi tag: framework

High Performance Computing (HPC)- tornare ad investire sull’Edge Computing

OK, con questa dichiarazione si capirà che sono un sistemista di vecchia scuola, per l’appunto ho iniziato ad occuparmi di sistemi HPC/Cluster nei primi anni 2000 ed ho realizzato il mio primo importante sistema Cluste HPC nel lontano 2004, da quel momento ho lavorato nello stesso ambito per grosse aziende in ambiti bancario, assicurativo, editoria, pubblica amministrazione etc…… ; ho potuto dunque analizzare per esperienza diretta che quello che legava tutti questi ambienti, che si stavano aprendo al mondo dell’offerta di servizi web online per i loro clienti (outsourcing), era la “ovvia” gestione in loco (on premise) dei dati aziendali, nonostante questo comportasse un forte investimento in hardware/network e sviluppo del software. Tutto ciò permetteva di tenere sotto controllo l’andamento dei progetti perchè per far funzionare tutti quegli avanzamenti tecnologici serviva far crescere anche il livello di preparazione tecnologica del proprio personale IT, seppur con le dovute integrazioni esterne di consulenti ad hoc, atti a portare uno slancio alla realizzazione finale del prodotto.

Dunque in un’azienda servivano un tot persone skillate in vari ambiti che procedessero di pari passo nel far avanzare il progetto fungendo anche da beta tester per i colleghi degli altri team, team solitamente suddivisi in:

  • Sistemisti
  • Database Administrator
  • Networking
  • Sviluppo (developer)
  • Cyber Security

Ogni gruppo testava se stesso e faceva da tester per gli altri così da arrivare , step by step, ai vari rilasci di pre-produzione e produzione, diminuendo, a mio avviso, di gran lunga il Bug da errore umano.

Credo che tutto ciò abbia funzionato piuttosto bene, in una specie di “status quo” fino all’arrivo della crisi del 2008 ed in particolare degli strascichi sui budget i cui effetti si sono visti negli anni subito successivi, nel frattempo il maggior sviluppo di piattaforme Cloud proposte dai Big come Gloogle Cloud ed Amazon AWS (in particolare) hanno portato alla decisione sempre più massiccia dei Manager di esternalizzare tutti i processi verso queste piattaforme per massimizzare gli sforzi nello sviluppo (programmazione) dei servizi eliminando dai budget le spese hardware, quelle per le location da dedicare alla ridondanza dei dati ed ai sistemi di backup integrati. Tutto questo ora era possibile pagarlo in un forfait di servizi on chain offerti dalle piattaforme Web-Cloud che hanno invaso il campo di gioco con acronimi di ogni genere, tra cui i primi furono le PaaS, SaaS, IaaS, CaaS, DaaS etc…. (solo la fantasia li può fermare) tagliando così anche le competenze dirette dei team poichè adesso le piattaforme web, la loro gestione, il mantenimento software, gli aggiornamenti, i backup, le problematiche di rete, i DNS, le connessioni VPN, la sicurezza e quant’altro potevano essere preoccupazione ed appannaggio di altri.

Tutto ciò per me ha solo impoverito il nucleo di esperti IT, smembrando i suddetti team e generando nuovi mostri poichè le aziende diventarono prede di “metodologie” di lavoro in stile Silicon Valley (ma ehi la verità è che funzionano solo in Silicon Valley) come la Agile, è da li sono partiti inglesismi lavorativi come lo “stand up meeting”, il “parking lot”, arrivando oggi all’uso di Framework per supportare l’Agile come lo “Scrum” che ha introdotto la figura dello “scrum master” e via di questo passo.
Ma quello che si è potuto vedere è che mentre prima i Team IT aziendali necessitavano di specifiche competenze , adesso posson bastare come capo progetto uno sviluppatore Senior con conoscenze da sistemista o un sistemista con conoscenze di programmazione per mandare avantiil 70% dei progetti perchè il resto lo prepara la piattaforma Cloud che ti aiuta a gestirlo con comodi tool grafici Plug ‘n Play e se qualcosa non funziona c’è il blog/tutorial o il call center…….. semplice giusto?

Certo qualcuno potrà giustamente dire che così è tutto più mirato, perchè no più comodo, e le aziende possono essere più verticali sullo sviluppo e sul risultato finale, FORSE, ma se devo cedere capacità cognitive, conoscenza dei sistemi e competenze di problem solving solo perchè è più pratico allora forse sto sbagliando mestiere. Non parliamo poi del nuovo arrivato, la A.I. , con ChatGPT e compagnia bella… quella unita ai movimenti No-Code, non fanno ben sperare per una futura esistenza delle ultime figure rimaste (gli sviluppatori) che credo si dovranno preparare a periodi di transizione poco rosei.

Il futuro non lo si può arrestare, arriva comunque dunque è giusto imparare a conoscerlo per capire come e quali cose sono vantaggiose da utilizzare, e che cosa invece determinerà la perdita di competenze apprese con fatica, studio ed esperienza lavorativa. Si potrebbe fare qualcosa per riprendere un minimo il controllo? Credo di SI, innanzitutto diminuendo la dipendenza dai sistemi Cloud esterni e tornando a volersi sporcare le mani in casa, quindi spazio alla rinascita dei data center aziendali costruiti su misura dei progetti reali ed implementati dalle persone che li gestiranno e li faranno crescere e scalare nel tempo, quindi riprendiamoci il controllo dei dati, in primis, e dei sistemi con loro, più sistemi on premise e Edge Computing e meno esternalizzazione con il Cloud Computing.

Vantaggi dell’ Edge Computing

L’edge computing è preferibile al cloud computing in molte situazioni e per diversi motivi chiave, tra cui sicurezza, controllo dei dati e velocità di elaborazione dei dati.

  1. Sicurezza: Nell’edge computing, i dati sono elaborati più vicino alla loro origine, riducendo il rischio di esposizione a minacce esterne. Questo approccio migliora la sicurezza dei dati sensibili.
  2. Controllo dei Dati: Con l’edge computing, le organizzazioni mantengono un maggiore controllo sui propri dati. I dati rimangono locali o in prossimità dei dispositivi, consentendo un controllo diretto sull’accesso e sulla gestione.
  3. Velocità nell’Elaborazione dei Dati: Poiché i dati vengono elaborati localmente nell’edge computing, la latenza è ridotta al minimo. Questo è fondamentale per applicazioni in tempo reale, come il monitoraggio industriale o i molti sistemi di monitoraggio delle città moderne (IoT), dove ogni millisecondo conta.
  4. Risparmio di Banda: Elaborare i dati in loco riduce la necessità di trasferire grandi quantità di dati in cloud, risparmiando banda e costi associati.
  5. Affidabilità: L’edge computing migliora l’affidabilità delle applicazioni. In caso di interruzione della connettività cloud, i dispositivi edge possono continuare a funzionare autonomamente.
  6. Scalabilità: L’edge computing è altamente scalabile. È possibile aggiungere dispositivi edge in modo modulare per gestire carichi di lavoro crescenti.
  7. Privacy: Per alcune applicazioni, come il monitoraggio della salute in tempo reale, la privacy dei dati è essenziale. L’edge computing mantiene i dati locali, riducendo le preoccupazioni sulla privacy.

In sintesi, l’edge computing è una soluzione vantaggiosa per applicazioni che richiedono velocità, sicurezza e controllo dei dati. Tuttavia, è importante notare che non esclude completamente il cloud computing, ma piuttosto lo integra in un modello ibrido per massimizzare i benefici.

Svantaggi dell’uso del Cloud Computing

  1. Aumento della Latenza: Nel Cloud, i dati devono viaggiare attraverso una rete molto estesa fino ai server remoti, causando ritardi (latenza) nell’elaborazione. Nel modello di Edge Computing, la distribuzione delle risorse di elaborazione avviene all’edge della rete, vicino ai dispositivi o ai sensori. Ciò elimina la necessità di trasmettere dati su lunghe distanze ai server remoti del Cloud, riducendo significativamente la latenza. Questa bassa latenza è essenziale per applicazioni in tempo reale come il controllo industriale, la guida autonoma e la realtà virtuale, migliorando notevolmente l’efficienza e la reattività dei sistemi.
  2. Dipendenza dalla Connessione Internet: Il Cloud richiede una connessione Internet costante, mentre l’Edge Computing funziona anche offline, garantendo continuità operativa.
  3. Controllo sull’Infrastruttura: Nel Cloud, hai meno controllo sull’infrastruttura sottostante, poiché è gestita dal provider. Con l’Edge Computing, hai maggiore controllo su hardware e sul software.
  4. Sicurezza e Privacy: Il Cloud può presentare rischi di sicurezza dovuti alla memorizzazione dei dati su server remoti. L’Edge Computing può offrire un maggiore controllo sulla sicurezza, poiché i dati rimangono locali.
  5. Costi Operativi: Il mantenimento di server remoti nel Cloud può comportare costi operativi elevati, mentre l’Edge Computing può essere più economico in particolare per piccole implementazioni locali.
  6. Complessità della Gestione: La gestione di ambienti Cloud complessi può richiedere competenze specializzate, mentre l’Edge Computing può essere più semplice da gestire localmente.

Certo tutto questo può essere solo un parere soggettivo determinato dalle mie personali esperienze lavorative, per altre persone potrà essere l’esatto contrario, rimango comunque dell’avviso che ciò di cui ho parlato descrive, in un paragone calzante, le stesse problematiche che il mondo sta affrontando per l’eccessiva deindustrializzazione dell’occidente che ha deciso decenni addietro di esternalizzare i processi produttivi sull’onda del concetto di “globalizzazione”, per il quale si è arrivati oggi ad essere dipendenti dei nostri fornitori (vedi la Cina solo per fare l’esempio più lampante) senza i quali non potremmo assemblare un PC o un telefonino, produrre abbastanza energia elettrica etc….

Alla fine un’azienda non è così diversa da uno Stato, lo Stato per essere definibile come tale deve avere un popolo che lo contraddistingue ed un territorio su cui esercita la sua sovranità; un’azienda necessità di proprio personale che apporta lavoro ed intelletto, che crea e genera idee da cui scaturiscono know-how e magari anche brevetti e deve essere la proprietaria di tutto ciò che produce e/o trasforma, altrimenti per entrambi i casi parliamo solo di “Colonie”.

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

 

Esiste una difesa efficace per l’OSINT?

Open Source-INTelligence

Open Source Intelligence

La Open Source INTelligence, acronimo OSINT (in italiano: “Intelligence delle fonti libere”), è l’attività di raccolta d’informazioni mediante la consultazione di fonti di pubblico accesso.

Cit.
“… OSINT is information that has been deliberately discovered, discriminated, distilled, and disseminated to a select audience, generally the commander and his/her immediate staff, in order to address a specific question. …”

Non ci fermeremo ad analizzare come funziona l’OSINT, per questo argomento ci sono decine di libri e centinaia di articoli che dettagliano le tante, tantissime tecniche (discipline) che compongono questa interessante metodologia.

Dunque la domanda e’ COME POSSIAMO DIFENDERCI?

Certamente il primo consiglio e’ quello di selezionare sempre con attenzione che cosa decidiamo “volontariamente” di condividere con il mondo, su quali social, con quali metodologie ed allo stesso tempo rimanere sempre aggiornati sui continui cambiamenti dei regolamenti dei social network a cui diamo con tanta gioia e facilita’ il controllo dei nostri ricordi, poiche’ alla fine e’ questo che ci muove, la “comodita’ ” di avere in un posto  foto/pensieri “momenti” unici che SPERIAMO rimarranno’ per sempre perche’ ci fidiamo che quei social rimarranno a lungo e si prenderanno cura delle “nostre cose”.

Andiamo avanti……come sopra indicato bisogna partire facendo un controllo attento, continuo ed accurato sulle Impostazioni Privacy del proprio utente nei vari Social Network;

Possiamo contare anche su una serie di servizi come HaveIBeenPwned, Google Alert, Talkwalk Alerts, Mention o MeltWater che permettono di avere sotto controllo la propria identità in rete.

In questo gia ricco arsenale possiamo introdurre un’ottimo sistema, il suo nome e’

OPERATIVE-FRAMEWORK

OF e’ un tool scritto in python che ci permette di fare cose davvero interessanti come, per esempio,

  • trovare domini registrati da una specifica mail
  • trovare attivita’ illecite  promosse da uno specifico utente
  • scoprire siti e-commerce truffaldini

….. e molte altre operazioni d’investigazione.

Il progetto e’ disponibile, in due versioni, su Github

  1. Operative Framework
  2. Operative Framework-HD

Le operazioni d’installazione e di configurazione sono ben descritte nelle pagine del progetto di Github, riportate sui link qui sopra. Una volta installati i pacchetti il loro uso e’ simile a quello di Metasploit, ad esempio con il comando “use” possiamo selezionare uno dei tanti moduli preinstallati:

$ use core/modules/email_to_domain

per poter vedere tutte le opzioni necessarie ad eseguire questa operazione bastera’ dare il seguente comando:

$ show_options

invece con il comando “set” possiamo configurare le variabili richieste per il funzionamento del modulo e “run” per lanciare il tutto.

Operative Framework

Operative Framework

Anche l’Operative Framework e’ solo una delle tante possibili armi nel bagaglio dell’OSINT, al punto che potremmo dedicare un’intera rivista elencando ogni singolo strumento a nostra disposizione, dunque con questo articolo ci stiamo soltanto limitando a dare uno sguardo a quei tool che sono fondamentali nella cassetta degli attrezzi di un’investigatore digitale.

Una raccolta di (quasi) tutti i tools disponibili in rete è data da https://osintframework.com, progetto a cui ogni giorno vengono aggiunti nuovi servizi.

HTML 5 & JS per le Mobile Apps

Html5 & Mobile AppOrmai l’HTML 5 è una realtà di fatto. Si aprono dunque nuove possibilità di sviluppo, l’HTML5 supporta una serie di nuove funzionalità che l’ormai collaudato e conosciutissimo HTML 4.x non può avere.
HTML 5 è dunque, di fatto, un linguaggio nuovo; sorge spontanea a questo punto una domanda: è possibile sviluppare applicazioni e siti web compatibili per smartphone e tablet usando l’HTML5?

 

In effetti se si prova a fare un breve quadro generale, vediamo che nel mondo degli Smartphone e dei Tablet il predominio si divide in soli due sistemi operativi iOS (per iPhone & iPad) ed Android. Come forse alcuni di voi gia’ sanno, sviluppare una App per iPhone/iPad richiede la conoscenza dell’Objective C++, mentre per Android serve avere una qual certa conoscenza di Java. Seppure Java e l’Objective C++ siano parenti, i metodi di programmazione sono sostanzialmente diversi. Quindi se la nostra esigenza è quella di sviluppare un’ applicazione per entrambi i sistemi operativi, perchè c’interessa coprire il 90% del mercato, saremmo costretti a programmare due differenti apps: questo vorra’ dire impiegare il doppio del tempo nello sviluppo, doppia manutenzione ed altre problematiche che non affronteremo adesso.

E’ a questo punto che l’HTML5 ci puo’ venire prontamente in aiuto: ossia perchè sviluppare due interfacce grafiche quando invece possiamo realizzarne una in HTML5 e javascript e ridurre cosi’ il core (o la Business Logic) dell’ applicazione a poche “righe di codice”? Se infatti un’ app per smartphone, non fa nient’altro che interrogare una base di dati (magari su XML) e visualizzare i vari risultati delle interrogazioni, l’HTML5 e Javascript saranno più che sufficienti per tutti i nostri scopi.

Lo sviluppo per HTML5+Javscript per dispositivi mobile è già una realtà e, a tale proposito, vi vorrei indicare due interessanti framework adatti anche allo sviluppo per mobile:

Jquery Mobile

Ext Js Touch

Se decidete di provare le demo di questi due framework javascript, ricordatevi di utilizzare un dispositivo Touch, altrimenti non funzionerà quasi nulla! Come potrete vedere dalle demo dei due framework le interfacce realizzate non hanno nulla da invidiare a quelle delle app programmate con Objective C++ e Java.

Nel caso in cui dobbiate installare un webserver sul vostro Android, vi consiglio di provare il seguente prodotto:

i-jetty

In questo modo potrete fare girare la vostra app in HTML 5 + Javascript senza dover essere collegati ad Internet.

Buon divertimento !

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.