Detto ciò, vi chiedo se potete darmi un vostro parere su quale distribuzione, o quale applicativo si può utilizzare per difenderci da "remoti" attacchi provenienti dalla rete.
Il problema è che la sicurezza non è un qualcosa che va tanto al chilo. Non so se hai mai sentito il termine "threat model". Questo termina indica la tipologia di attacchi. Cioè, se da un lato ci sono quelli che lavorano per rendere più sicuri i sistemi, dall'altro c'è chi lavora per bypassare questi blocchi.
Per cui trovo quantomeno fuorviante il marketing da parte dei venditori di software, che vogliono far credere che col loro pacchetto è tutto ok. Si si, infatti gli hacker hanno bucato pure Solarwind. E parliamo di gente che produce software per usi molto molto professionali.
Non voglio dire che siano tutti mentitori o non valga la pena preoccuparsi. Però partire dal presupposto che se vogliono bucarti, ti bucano. Un pò come il ladro d'auto che disse "se voglio la tua auto, sta sicuro che l'avrò".
Tutto questo pippone per dire che la cosa veramente da fare sarebbe studiare. Studiare i tipi di attacchi, studiare i sistemi e modelli di sicurezza.
Che voglio dire? C'è Fedora che ha SELinux abilitato di default. Si tratta di un sistema MAC molto avanzato. Ma probabilmente la sigla MAC non ti dirà nulla, soprattutto riguardo quello che questi sistemi non possono fare. Da cui la necessità di accoppiare un firewall. Ma non basta. Far girare i processi in sandbox, limitati via capabilities, è un ulteriore muro. Ma nemmeno questo basta. Usare seccomp per limitare il numero e tipo di syscall che la sandbox può effettuare, innalza ulteriormente quel muro. E così via, perchè ci sono ulteriori sistemi che fanno fronte a determinate categorie di attacchi.
E per il kernel abbiamo patchset specifici, come PaX. E c'è la possibilità di usare distro non convenzionali, che fanno uso di componenti non standard. Per esempio Alpine non solo patcha il kernel per renderlo più robusto, ma usa Musl al posto di Glibc ( chiaramente le vulnerabilità di Glibc non sono presenti in Musl, per cui un malware si attacca ), non usa Systemd, ecc... Ma staresti sfruttando il fatto di usare componenti non standard, per i quali gli hacker non hanno realizzato malware. Però se l'hacker ce l'ha proprio con te, potrebbe creare degli exploit ad hoc per il tuo stack software.
C'è SubgraphOS che fa uso massiccio dei namespace per far girare tutti i programmi in sandbox. Però alcuni studi hanno messo in discussione le sue capacità, soprattutto in relazione alla concorrente QubesOS ( quest'ultima usa le virtual machine Xen come sistema d'isolamento ).
Cioè, voglio dire che ci si può affidare al produttore X e sperare, oppure acculturarsi e decidere quale strada seguire, magari partire da una Arch o Gentoo e customizzare la distro mettendo in piedi i meccanismi di protezione che si ritiene più adatti al proprio caso.
E una conoscenza, ancora basilare, aiuta pure ad usare i sistemi prodotti da altri. Per esempio c'è Firejail, ma leggendo il manuale, una persona a digiuno di conoscenze specifiche sulla sicurezza e i meccanismi implementati in Linux, probabilmente non capirà molto. E allora o ti fidi di loro o resterai sempre col dubbio.
Altrimenti basta una Ubuntu, visto che pure ha firewall e sistema MAC ( AppArmor ). Il problema è che c'è gente che di mestiere trova il modo di bypassare questi sistemi di sicurezza e più la distro è comune e diffusa ( e usa meccanismi d'uso comune ) e più sale la probabilità di credere di essere protetti quando invece non lo si è affatto.
Windows 10 pure ha un bel pò di meccanismi di sicurezza e dobbiamo riconoscere a MS di aver fatto un buon lavoro. Ma questo non evita ai suoi utilizzatori di fare brutti incontri.
Se vuoi il mio parere, la prima cosa da fare è rendere la distro stateless, cioè la root del filesystem deve stare su un fs in sola lettura ( non intendo montato in ro, ma un fs che non consenta proprio le scritture, tipo squashfs ). E' lo stesso tipo di root che si usa per i device embedded ( DD-WRT e OpenWRT fanno così, per esempio ).
Questo ti garantisce quantomeno che il filesystem root resti integro anche dopo un attacco. Accoppiaci delle politiche che blocchino l'accesso alla partizione UEFI e sei a cavallo. Il problema è che poi non puoi installare i programmi nel modo classico. Cioè li installi, ma vanno in ram e devi ricostruire l'immagine del root fs, altrimenti li perderai al successivo boot.
Io ho risolto facendo uso dei container, tramite systemd-nspawn. I container ovviamente sono contenuti su un filesystem r/w. Praticamente hai un sistema host base immutabile e stateless e un volume r/w con dentro tutta una serie di container.
Idem per i dati. Non puoi salvarli in $HOME, altrimenti li perderesti al successivo riavvio.
E fortunamente c'è la possibilità di mettere su un simile setup facilmente, usando distro come Tails o MXLinux, ma anche facendo il remastering di immagini live di distro "normali".
