Leggendo un post di Stefano Quintarelli ho scoperto questo interessante browser: LibreWolf.
Si tratta di un browser basato su firefox e focalizzato sulla privacy, sulla sicurezza e sulla libertà.
Si può installare su svariate piattaforme e sicuramente lo proverò.
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.
L'algoritmo a chiave pubblica CRYSTALS-Kyber è raccomandato dal NIST nel processo di selezione della crittografia post-quantica.
Dei ricercatoti hanno pubblicato un attacco Side-Channel basato 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.1perché 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.
Quindi occhio a far arrabbiare un hacker 😉
Via Quintarelli e Wired
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:
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.
Grazie ad una nuova legge dello stato della California avremo maggior sicurezza sui dispositivi IoT.
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.
Via Bruce Schneier
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.
Via BoingBoing
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.
Bruce Schneier si domanda perché un aspirapolvere debba essere dotato di microfono e pure io me lo chiedo. In più mi chiedo anche il perché di questa mania di avere tutto connesso: soprattutto visto che quasi nessuno si cura della sicurezza di questi oggetti.
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:
Per accedere in maniera sicura bisogna esporre il servizio in HTTPS quindi usiamo Let's Encrypt per avere un certificato gratuito per il dns che abbiamo impostato nel nostro router.
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:
<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/tuo.dominio.it/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/tuo.dominio.it/privkey.pem
ServerAdmin tuaemail@example.it
ServerName tuo.dominio.it
ProxyPass / http://192.168.1.100/
ProxyPassReverse / http://192.168.1.100/
<Proxy *>
AuthType Basic
AuthName "Restricted Access"
AuthUserFile "/cartella/dove/metti/il/file/passwordapache"
Require user nomeutente
</Proxy>
</VirtualHost>
<VirtualHost *:80>
ServerName tuo.dominio.it
Redirect permanent / https://tuo.dominio.it/
</VirtualHost>
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 😀
Via Bruce Schneier
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.