L'interoperabilità dei sistemi di messaggistica è un ottimo obbiettivo perché impedisce che un utente sia bloccato da un software di messaggistica e, di conseguenza, favorisce sia la libertà che la concorrenza. Anche Bruce Schneier afferma che in teoria è un bene.
Dei ricercatori hanno valutato che l'interoperabilità porta ad una superficie di attacco maggiore su parecchi aspetti. In pratica succede che la sicurezza complessiva diventa pari a quella della piattaforma peggiore: un brutto livellamento verso il basso diventa il risultato dell'applicazione di un principio che dovrebbe essere buono.
Dei ricercatoti hanno pubblicato un attacco Side-Channelbasato sul consumo di corrente e si supponeva che questo algoritmo fosse resistente a questo tipo di attacco.
La parte interessante, fa notare Bruce Schneier, non è tanto l'attacco in se ma che abbiano usato una tecnica di machine learning per istruire il sistema su come portarlo a termine: effettivamente è importante notare che una tecnica relativamente nuova come quella del machine learning possa essere usata per trovare vulnerabilità e, ovviamente di contro, anche per forzare un sistema.
Capita di dover aprire un tunnel socks5 ma se poi questo tunnel deve restare aperto per ore e magari resistere a vari eventi avversi non basta il semplice comando ssh
ssh -ND 8080 root@192.168.1.1
perché se il server destinazione (il 192.168.1.1) ad esempio viene riavviato il tunnel cade. Per ovviare a questo ed altri inconvenienti basta un breve script che si occupa di verificare che il tunnel sia aperto e, in caso contrario, che lo apra e che faccia tutto questo all'infinito. Quantomeno fino a quando non lo blocchiamo a mano noi.
Questo è lo script bash
#!/bin/bash
# Script che apre e tiene aperto un tunnel socks5
# porta utente e ip o dns sono hardcoded ma volendo potrebbero essere messi come parametri
# Ciclo while infinito
while true
do
# Il comando if verifica l exit code del comando che sta cercando qualcosa in LISTEN sulla porta 8080 che è il mio tunnel
if netstat -an | grep 8080 | grep -q LISTEN
then
# Se lo ha trovato allora entra qui e attende 1 secodo poi salta il ramo else e ricomincia il coclo infinito
sleep 1
else
# Se non lo trova allora entra qui e il comando sotto crea in background il tunnel e poi aspetta 2 secondi poi continua il ciclo infinito
nohup ssh -ND 8080 root@192.168.1.1 > /dev/null 2>&1 &
sleep 2
fi
done
Era da più di due anni che non uscivano aggiornamenti per Nagios Core. Nel 2022 ne sono già usciti 3, l'ultimo dei quali pochi giorni fa.
Visto il lungo periodo di assenza potreste aver dimenticato di aggiornare oppure, visto che la versione 4.4.7 ha un bug che porta a dover disabilitare il check della release, potreste essere giustificati quindi ho pensato di avvisare che ora l'ultima release è la 4.4.9 quindi correte ad aggiornare.
Si sente alle volte dire che le auto elettriche richiederanno troppa elettricità al sistema mettendolo in crisi: non è vero perché la quantità di elettricità aggiuntiva richiesta è modesta, è in crescita graduale (le auto elettriche sono in crescita graduale) e potranno addirittura essere la soluzione ad un problema che invece è reale. Quello della stabilizzazione dei carichi di rete.
Tutto passa da volontà politiche, modifiche alle normative e incentivi. Per diverse ragioni è utile puntare sulla produzione di elettricità da fotovoltaico (è più economico, ci rende indipendenti dall'estero, abbiamo tanto sole) e questo richiede che vengano sbloccati progetti già pronti a partire riducendo la burocrazia normativa. Una volta che il fotovoltaico sarà libero di cresce avremo abbondante energia elettrica ma, per sua natura, intermittente (legata alle condizioni meteorologiche). È qui che nuovamente entra in gioco la normativa: un auto elettrica predisposta a VTG (Veicle To Grid: dall'auto alla rete elettrica) che venisse lasciata connessa alla rete potrebbe fornire energia alla rete nei momenti di scarsità (con vantaggi economici per il proprietario dell'auto) stabilizzando la produzione elettrica.
Quindi l'unico vero problema futuro reale, l'intermittenza della produzione elettrica fotovoltaica, potrebbe essere risolto dalle tante e capaci batterie delle auto elettriche connesse alla rete con tecnologia VTG. Basterebbe solo adeguare la normativa per consentirlo.
All'interno di un attacco informatico condotto dalla corea del nord contro ricercatori di sicurezza informatica dell'ovest l'hacker indipendente P4x è stato colpito direttamente e non l'ha presa molto bene.
Visto che, dopo un anno, nessuno ha preso provvedimenti ha pensato di darsi da fare lui per portare avanti il principio che "Se non vedono che abbiamo i denti, semplicemente continueranno a tornare" e gli è riuscito piuttosto bene visto che ha tirato giù tutti i router chiave del paese causando il blocco totale di internet.
Sono ormai alcune settimane che ho iniziato ad usare Syncthing (Open Source) per tenere sincronizzati file e cartelle tra i miei vari computer, server e smartphone e devo dire che come alternativa a Dropbox è veramente interessante.
Il compito che svolge è simile da Dropbox ma ci sono alcune differenze.
Syncthing non ha un server proprio dove custodisce una copia online dei dati come fa Dropbox quindi niente interfaccia web per la gestione dei propri file ma anche niente limiti di spazio. Si può tenere in sincronia tutti i file che si vuole e il limite è dato solo dallo spazio disco dei vostri dispositivi.
La gestione del versioning dei file è decisamente più articolata e flessibile ma come contro, ovviamente, utilizza il vostro spazio disco. Basta avere l'accortezza di attivare un versioning molto esteso solo su un computer con molto spazio storage per aggirare il problema: per esempio su uno smartphone solitamente non è il caso di sprecare spazio.
Il client Android ha il vantaggio di salvare una copia locale così da avere i dati disponibili anche offline ma, di contro, non è possibile selezionare una scheda sd come destinazione
Ci sarebbero svariate altre caratteristiche e informazioni interessanti ma mi sono limitato a citare i principali pro e contro di Syncthing rispetto a Dropbox.
Un applicazione per smartphone intelligente ha dei dati salvati in modo da poterli usare anche da altri dispositivi: l'esempio più facile è un blocco note che viene usato dall'app sul telefono ma anche da computer e da tablet.
L'approccio più tipico e facile è di avere un server centrale di proprietà di chi sviluppa e rende disponibile l'applicazione al quale si collegano tutti i dispositivi in modo da tenere aggiornati i dati. Si tratta della soluzione più facile per l'utente che deve solamente avere un account che poi imposta sui vari dispositivi per trovare tutti i suoi dati su tutti i dispositivi.
Una seconda possibilità è di poter impostare l'utilizzo di un proprio server per sincronizzare i dati. Questa opzione richiede competenze e risorse dell'utilizzatore che non sono più da utente e richiede anche che il software per implementare il server sia disponibile. Di contro ci sono notevoli vantaggi dal punto di vista della sicurezza (i miei dati sono solo su miei dispositivi/server) e della continuità del servizio (se chiudono il server centrale io continuo ad avere il tutto funzionante perché uso un mio server)
Segnala Bruce Schneier che c'è un kickstarting (crowdfunding) per una candela con fuoco vero controllabile via internet e, giustamente, si domanda: cosa potrebbe andare storto?
Alcuni lettori di Bruce hanno lasciato commenti particolarmente significativi:
Puoi verificare da remoto se casa tua ha una perdita di gas.
La si potrebbe chiamare candela di Darwin.
Prossimamente l'integrazione con svariati assistenti vocali per una migliore e più veloce esperienza di incendio.
Voi sareste pronti ad abbandonare Google come ha fatto il Quinta?
Io, francamente, non ancora anche se è da tempo che ci sto pensando.
Probabilmente potrei iniziare a sostituire qualcuno dei servizi che uso con delle alternative che Stefano Quintarelli segnala. Magari partendo da allwaysync.
Questa legge impone a tutti gli oggetti connessi di avere un ragionevole livello di sicurezza: dato che i produttori di dispositivi IoT devono aggiornare il loro software per poter vendere in California e che non ha senso mantenere un ramo "sicuro" per la California e uno "insicuro" per tutti gli altri, questo miglioramento sarà per tutti.
Interessante articolo di Bruce Schneier sull'uso dei dati personali degli IoT (per esempio videocamere di sorveglianza ma anche aspirapolvere e altro). I produttori di questi oggetti non pubblicano nulla sulla trasparenza nell'uso dei nostri dati e non commentano al riguardo quando interpellati. Siete sempre convinti che sia bello, comodo e fantastico avere il proprio sistema di allarme, con magari videocamere interne, connesso via internet al sito del produttore? Segue una traduzione molto libera del breve articolo di Bruce.
I dispositivi IoT sono dispositivi di sorveglianza e i produttori generalmente li usano per raccogliere dati sui loro clienti. La sorveglianza è ancora il modello di business di Internet e questi dati sono usati contro l'interesse dei clienti: sia dai produttori che da qualche terza-parte al quale il produttore vende i dati. Ovviamente questi dati possono anche essere usati dalle forze dell'ordine; lo scopo dipende dalla nazione.
Niente di tutto questo è una novità e molto di questo è spiegato nel mio (ndt suo: di Bruce) libro Data and Goliath. Quello che è comune per le aziende di Internet è di pubblicare un "rapporto sulla trasparenza" che indica almeno le informazioni generali su come le forze dell'ordine usano questi dati. Le aziende IoT non pubblicano questi report. TechCrunch ha chiesto informazioni ad alcune di queste aziende e, fondamentalmente, ha scoperto che nessuno parla.
Un aspirapolvere potrebbe essere trasformato in una spia e questo può succedere perché, prima di tutto, c'è la mania di avere tutto quanto connesso ad internet ( IoT ) e poi perché qualcuno ha avuto la strana idea di dotarlo di un microfono.
A questo punto, dato che spesso la sicurezza informatica di questi oggetti è molto bassa, succede che vengano trovati sistemi per manometterli e trasformarli in dispositivi di sorveglianza. In questo caso bisogna poter mettere fisicamente le mani sull'aspirapolvere quindi il tipo di attacco è limitato: se hai un malintenzionato in casa il problema maggiore non è l'aspirapolvere.
Se anche voi usate da sempre FoxyProxy per gestire i proxy di Firefox vi sarete accorti che per un po' di tempo non era stato aggiornato per essere compatibile con la nuova tipologia di plugin di Firefox. Nel frattempo mi sono arrangiato a mano e poi ho dimenticato di controllare.
Ora mi sono accorto che è stato aggiornato (in realtà totalmente riscritto) e quindi possiamo tornare ad usarlo.
Se avete l'esigenza di esporre un servizio web di casa vostra e volete farlo in maniera sicura gestendo voi direttamente il tutto per avere il massimo controllo una soluzione è il reverse proxy con autenticazione.
Per fare un esempio potreste voler pubblicare in internet una ip cam di sorveglianza che guarda l'esterno di casa. Il modo più facile è di impostare una regola sul vostro router per aprire la porta della videocamera ma questo presenta almeno un paio di problematiche che portano a sconsigliarlo. La più ovvia è che la videocamera potrebbe non avere l'impostazione per proteggerla con password e non è bello che chiunque possa guardare fuori da casa vostra. Una seconda considerazione è sul grado di sicurezza della vostra ip cam: potrebbe avere dei bug che permettono ad un malintenzionato di prenderne il controllo o, anche se non ne avesse, in futuro potrebbero saltarne fuori e il produttore quasi certamente non pubblicherà un aggiornamento per tappare la falla.
La soluzione reverse proxy con autenticazione è indubbiamente più complessa ma permette di avere il pieno controllo della parte che si pubblica in internet e di poter quindi tenere aggiornati tutti i componenti alle ultime versioni: un sistema correttamente configurato e mantenuto aggiornato è una buona garanzia di sicurezza.
Cosa serve per realizzarlo? Prima indico un breve elenco di oggetti che servono e poi qualche dettaglio sulle configurazioni.
Elenco:
Un ip pubblico (niente NAT/Carrier Grade NAT altrimenti non siete raggiungibili dall'esterno)
Un router che possa tenere aggiornato un dns dinamico con il vostro ip (o un ip pubblico statico)
Un server sempre acceso da adibire a reverse proxy
Se utilizzare una Debian con Apache come web server allora dovete abilitare i vari moduli proxy e un idea di settaggi del reverse proxy potrebbe essere:
Come vedete ho messo un rediret permenent per HTTP (porta 80) in modo che se anche cerchi di accedere senza l'HTTPS vieni rediretto sul sito sicuro. Nella sezione sopra, quella HTTPS (porta 443), ho indicato le posizioni dei certificati, l'ip interno del web server da esporre (da notare che può essere anche solo HTTP ma verso l'esterno viene fatto transitare HTTPS), come AuthName non mettete nulla di personale perché è visibile a chiunque prima dell'autenticazione e poi c'è il file dove salverete utente e password.
Fatto in questo modo potete accedere da internet al vostro servizio web semplicemente con https://tuo.dominio.it/ vi apparirà la richiesta di nome utente e password e tutto quanto transiterà in maniera cifrata.
Durante un upgrade da Debian 8 a Debian 9 potrebbe capitarvi che il server non torni raggiungibile.
Se avete un accesso diretto (tastiera e monitor oppure una console di un server virtuale) usatelo e verificate che sia tutto a posto lato network.
Con un networkctl ottenete la lista delle interfacce di rete e poi verificate che nel file /etc/network/interfaces il nome sia lo stesso: se non lo fosse allora sistematelo e riavviate il network con un systemctl restart networking.service.
Già che ci siete verificate anche che il servizio di rete sia abilitato allo startup controllando cosa dice un systemctl status networking.service perché potrebbe essere disabled.
Recentemente è stato scoperto un attacco che funziona quando un dispositivo usa un particolare tipo di generatore di numeri pseudo casuali con chiave hardcoded.
Noto che ultimamente vengono creati a contorno oggetti che anni fa uno non si sarebbe mai aspettato per simili evenienze: il logo di DUHK Attack è proprio simpatico 😀
Breve post a mo di appunto su come sistemare la vulnerabilità chiamata shellshock in un server Debian 7 Wheezy.
Verificate che sia vulnerabile e scaricate il pacchetto deb come indicato qui.
Inserite temporaneamente il repository di sviluppo (sid) e aggiornate la libreria libc6 come indicato qui. Come detto in un commento anche per me ha funzionato installando libc6 e non libc6-amd64.
Ricordatevi di togliere il repository sid una volta terminato.
Ora che avete il pacchetto libc6 aggiornato potete installare il deb bash scaricato prima: se cercate di installarlo senza aggiornare la libc6 vi segnala errore.
Spesso capita che mi segnaliate che l'ADSL non va più oppure che ha iniziato ad andare male.
Cose tipo: "cade spesso la linea" oppure "prima andavo più veloce ora vado piano"
La maggior parte di queste segnalazioni mi arrivano tramite un articolo che ho scritto per DynamicK diverso tempo fa ma che riguardava un problema specifico che ormai è rientrato.
Dato che i problemi sono reali e un utente che prima navigava e scaricava tranquillamente si trova ad avere una linea decisamente peggiore rispetto a prima ho pensato di darvi un infarinatura su alcune delle possibili cause.
La rete in rame di Telecom Italia è piuttosto vecchia e spesso malconcia: non è strano che possa capitare che uno o più cavi in rame che portano l'ADSL nelle case subisca un degrado. Infiltrazioni di acqua, topi che rosicchiano i cavi (non ridete: è capitato) semplice usura che crea un brusco calo della qualità del cavo e altro.
In queste condizioni è normale che la qualità del vostro collegamento peggiori: che si può fare? Nulla 🙁
Forse, tra tanto tempo, verrà sfilato il rame per essere sostituito con la fibra ottica e questo risolverà.
Un altra situazione che può portare ad un brusco degrado è l'aumento delle ADSL attivate dai vicini di casa.
I cavi in rame, prima di diramarsi verso i singoli appartamenti, viaggiano in grandi fasci tutti insieme. Anche se ci sono parecchi cavi non è possibile attivare molte ADSL perché, oltre un certo numero, creano interferenza l'una con l'altra (ho semplificato un po' e ho omesso che esistono tecniche per ridurre molto questo problema)
Anche in questo caso non c'è molto da fare se non sperare nell'arrivo della fibra.
Tutto questo succede per qualsiasi operatore (esclusi i pochissimi fortunati utenti Fastweb raggiunti in fibra fino all'edificio) perché i cavi sono sempre di proprietà di Telecom Italia sia per le ADSL Telecom Italia che per quelle di tutti gli altri operatori.
Non fatevi quindi venire l'idea di risolvere cambiando operatore perché, se il problema è di degrado o affollamento, non risolvereste nulla!
Questi sono due possibili motivi: ce ne possono essere altri, magari legati ad altri tipi di interferenze, ma il grosso è per questi due.
Se invece la vostra ADSL è sempre andata male da quando ve l'hanno attivata, oltre ai questi motivi, può anche essere che siate distanti dalla centrale telefonica (basta anche 800/900 metri se i cavi sono vecchi) e quindi il cavo, più di quello, non regga.
Se avete domande al riguardo, dubbi o volere esporre il vostro problema i commenti sono aperti!
Per me che è una passione non è un problema il crearmi una cultura digitale ma non tutti sono appassionati di questi argomenti e non devono essere obbligati ad esserlo.
Che invece si debba creare una cultura digitale per tutti è corretto: si tratta del futuro e non si può scappare.
Leggo un passaggio del Corriere della Sera di ieri che dice:
La ricetta di Pileri è radicale: «Bisogna rendere progressivamente obbligatoria l' erogazione di alcuni servizi via Internet, dandosi precise scadenze temporali: per esempio porsi l' obiettivo di mettere tutte le ricette mediche digitali in rete entro il dicembre del 2012. La stessa cosa si potrebbe fare, in ambito scolastico, rendendo obbligatorie le transazioni con la scuola. Evidentemente è necessario aiutare i soggetti come gli anziani che non sanno usare la rete».
Io non sarei capace di alfabetizzare chi parte praticamente da zero tipo anziani o anche giovani che non hanno dimestichezza con le nuove tecnologie ma credo che ci sia gente in grado di farlo.
L'altro dubbio è la reale penetrazione della banda larga in Italia: ora come ora è scarsa e dubito che si possa pianificare di spegnere dei servizi erogati nel vecchio stile per passarli in digitale senza avere certezze sulla diffusione della banda larga.
Cosa vogliamo fare: obbligare a comunicare con la scuola solo eletronicamente per poi accorgerci che molti genitori si possono connettere ad interent solo con un vetusto modem 56k?
Portiamoli quindi avanti insieme questi due progetti: servizi migrati su internet e diffusione della banda larga.
Magari sarà già stato pianificato proprio così ma non vorrei che poi le due cose, all'atto pratico, le portassero avanti con velocità diverse!
Spesso capita che mi segnaliate che l'ADSL non va più oppure che ha iniziato ad andare male.
Per me che è una passione non è un problema il crearmi una cultura digitale ma non tutti sono appassionati di questi argomenti e non devono essere obbligati ad esserlo.