Marco Lazzarotto

Mitigare la vulnerabilità 'Copy Fail' (CVE-2026-31431) con un semplice Playbook Ansible

postmaster@mlazzarotto.it (Marco Lazzarotto) — Fri, 01 May 2026 00:00:00 +0100

In poche parole: c’è un nuovo bug critico per Linux in circolazione

‘Copy Fail’ è un nuovo e fastidioso bug di local privilege escalation, CVE-2026-31431, trovato dal team di analisti Xint Code.

Questo bug in pratica permette all’attaccante di ottenere i permessi di root su molti sistemi operativi Linux (Ubuntu, Debian, RHEL, Suse, Alma, Amazon Linux), con uno script Python di soli 732 bytes.

‘Copy Fail’ richiede solo un account utente locale senza privilegi: nessun accesso alla rete, nessuna funzionalità di debug del kernel, nessuna libreria preinstallata. L’API di crittografia del kernel (AF_ALG) è abilitata di default praticamente in tutte le distribuzioni principali, quindi l’intero intervallo di patch dal 2017 in poi è vulnerabile.

Capire bene la vulnerabilità ‘Copy Fail’

In poche parole, immaginate il kernel Linux che per evitare di leggere sempre da disco i file, ne tiene una copia in memoria: la cosiddetta page cache. Questa cache viene usata normalmente per velocizzare alcune operazioni da parte del kernel. Tutto in regola.

Poi però, entra in gioco algif_aead, uno dei moduli del kernel Linux che espone il sottosistema crittografico allo userspace mediante l’interfaccia AF_ALG. In parole povere? Una API per i servizi crittografici, usata per esempio in protocolli come IPsec.

Nel lontano 2017 è stato modificato questo modulo del kernel per renderlo più “efficiente” e gli hanno detto “Invece di fare una fotocopia del documento (il file) su cui devi lavorare, scrivi direttamente sull’originale che il kernel ti passa nella page cache” grazie a una chiamata di sistema chiamata splice() che passa i dati per riferimento invece di copiarli.

Questa ottimizzazione in-place è la radice del problema, perché ha permesso a un utente di scrivere dati dove non avrebbe assolutamente dovuto.

E quali dati può scrivere un attaccante? Può andare a riscrivere una piccola parte di /usr/bin/su per fare in modo di poter eseguire su e diventare quindi l’utente root.

L’aspetto ‘fantasma’

Una delle cose più subdole di questa vulnerabilità è che la modifica avviene solo in RAM. Il file su disco rimane intatto.

Ciò significa che tutti i classici sistemi di controllo dell’integrità dei file (come Tripwire, AIDE, Wazuh, ecc.) non vedono nulla di strano. Questo è molto pericoloso perché non lascia tracce su disco.

La fuga dai container

Prima parlavamo della page cache, quella parte di memoria che serve a velocizzare le operazioni del kernel. Ebbene, la page cache è condivisa tra tutti i container su uno stesso host (Podman, Docker, Kubernetes, etc.).

Questo significa che un container vulnerabile o infettato da un attacco di tipo supply chain, può fare container escape in una maniera spaventosamente semplice.

Il playbook Ansible per la mitigazione immediata

Traendo spunto dalla KB di Morrolinux e da questo gist su Github dell’utente m3nu ho creato un playbook Ansible disponibile a questo link copy-fail-CVE-2026-31431-mitigation-ansible-playbook che permette di applicare la mitigazione e di fare rollback in seguito all’aggiornamento del kernel.

tasks:
 - name: Apply Mitigation
 tags: [mitigation]
 when: not (rollback | bool)
 block:
 # --- Debian family modprobe blacklist + unload ---
 - name: Apply modprobe blacklist (Debian family)
 when: ansible_facts['os_family'] == 'Debian'
 block:
 - name: Create modprobe blacklist for {{ target_module }}
 ansible.builtin.copy:
 dest: "{{ modprobe_conf_path }}"
 content: |
 # Generated by Ansible — CVE-2026-31431 mitigation
 install {{ target_module }} /bin/false
 owner: root
 group: root
 mode: "0644"

 - name: Unload module {{ target_module }} if currently loaded
 community.general.modprobe:
 name: "{{ target_module }}"
 state: absent
 register: rmmod_result
 failed_when:
 - rmmod_result is failed
 - >-
 'not currently loaded' not in (rmmod_result.msg | default(''))
 and 'not currently loaded' not in (rmmod_result.stderr | default(''))
 - >-
 'is in use' not in (rmmod_result.msg | default(''))
 and 'is in use' not in (rmmod_result.stderr | default(''))

 - name: Remind operator to reboot if module was in use (Debian)
 when: >-
 'is in use' in (rmmod_result.msg | default(''))
 or 'is in use' in (rmmod_result.stderr | default(''))
 ansible.builtin.debug:
 msg: "REMINDER: Module was in use and could not be unloaded. Reboot required to complete mitigation."

 # --- kernel initcall blacklist (RHEL/Alma 9 and 10 only) ---
 - name: Apply kernel initcall blacklist (Red Hat family)
 when:
 - ansible_facts['os_family'] == 'RedHat'
 - ansible_facts['distribution_major_version'] in ['9', '10']
 block:
 - name: Check current grubby kernel args (pre-change)
 ansible.builtin.command: "grubby --info=ALL"
 register: grubby_info_pre
 changed_when: false
 check_mode: false

 - name: Add '{{ target_kernel_arg }}' to all kernels via grubby
 ansible.builtin.command:
 cmd: "grubby --update-kernel=ALL --args='{{ target_kernel_arg }}'"
 register: grubby_add_result
 changed_when: target_kernel_arg not in grubby_info_pre.stdout

 - name: Remind operator to reboot (RHEL)
 when: grubby_add_result.changed
 ansible.builtin.debug:
 msg: "REMINDER: Kernel args changed. Reboot required to activate mitigation."

Analizziamo il playbook

Il playbook è compatibile con sistemi operativi basati su RHEL (CentOS, Rocky, Alma) e basati su Debian (Ubuntu e Mint). Di base utilizza la funzione serial per eseguire il playbook solo su un numero limitato di host simultaneamente, di default il 25%. Ad esempio, avendo 100 host nell’inventory, la mitigazione sarà applicata a 25 host nel primo batch, 25 nel secondo e così via.

La funzione max_fail_percentage invece, tollera un tasso di errori del 20%. Ad esempio, se ci sono 25 host nel batch, se 6 o più host falliscono, il job sarà abortito.

Il Pre Task mostra alcune informazioni sul sistema operativo e sul kernel per ogni host e raccoglie informazioni sullo stato del sistema.

Il Task per le distribuzioni Debian-based disabilita il modulo kernel e lo mette in blacklist, e se il modulo è in uso, ricorda all’utente di riavviare il sistema. Per le distribuzioni RHEL-based invece, usa il comando grubby per disabilitare il modulo e ricorda sempre all’utente di riavviare il sistema.

Il Post Task raccoglie ulteriori informazioni e presenta all’utente un sommario delle azioni eseguite.

Come eseguirlo

Innanzitutto è necessario preparare il file di configurazione di Ansible e l’inventory come in ogni playbook Ansible. Successivamente lanciare un ping per controllare la raggiungibilità dei server. Infine, usare ansible-playbook mitigation-playbook.yaml per lanciare la mitigazione su tutti i server, o usare l’opzione --limit webservers per limitare il playbook solo a un determinato gruppo di host. Per il rollback, come sopra, ma si userà l’opzione --tags rollback per eseguire solo i task di rollback.

Verificare che la mitigazione funzioni

In seguito all’esecuzione del playbook, è necessario verificare che la mitigazione abbia avuto effetto. Per fare ciò usare questi due metodi, in base alla distribuzione dei vostri host:

Sulle distribuzioni Debian-based usare lsmod | grep algif_aead.
Sulle distribuzioni RHEL-based usare grep initcall_blacklist /proc/cmdline.

La mia opinione: un passo in più per i container

Personalmente, la mia opinione è che fermarsi alla configurazione dell’host non sia sufficiente se fai girare dei container. Poiché i container condividono il kernel della macchina host, un riavvio o un errore di configurazione che ricarica il modulo vulnerabile per sbaglio lascerebbe i tuoi workload di nuovo esposti.

Sappiamo che questo exploit ha bisogno di aprire un socket della famiglia AF_ALG per poter comunicare con la Crypto API del kernel. Per questo motivo, vi consiglio caldamente di implementare un approccio “defense in depth” (difesa su più livelli) utilizzando seccomp. Se configurate un profilo personalizzato per il vostro container runtime, potete dire al sistema di bloccare del tutto le syscall di tipo socket dirette verso AF_ALG. In questo modo, anche se il modulo algif_aead dovesse magicamente riattivarsi sull’host, il kernel “segherà” in tronco qualsiasi tentativo del container di sfruttarlo.

Un’esempio di policy seccomp.

{
 "defaultAction": "SCMP_ACT_ALLOW",
 "syscalls": [
 {
 "names": ["socket"],
 "action": "SCMP_ACT_ERRNO",
 "args": [
 {
 "index": 0,
 "value": 38,
 "op": "SCMP_CMP_EQ"
 }
 ],
 "comment": "Blocca i socket AF_ALG (famiglia 38) per mitigare Copy Fail"
 }
 ]
}

Non abbassate la guardia!

Eccoci arrivati alla fine. C’è una cosa fondamentale che ci tengo a precisare: la soluzione basata su Ansible e modprobe che abbiamo appena visto è un’ottima “pezza” per proteggersi nell’immediato, ma ricordatevi che non è la cura definitiva.

La mia opinione personale è che i workaround di sicurezza non dovrebbero mai essere dimenticati sui server a prendere polvere. Tenete d’occhio i bollettini di sicurezza dei vostri vendor (che sia Canonical, Red Hat, SUSE o altri). Non appena rilasceranno i pacchetti del kernel aggiornati con la patch ufficiale per la CVE-2026-31431, programmate l’installazione e un bel riavvio delle macchine. Una volta che i sistemi avranno il kernel patchato, potrete fare pulizia e rimuovere i file creati da questo playbook.

Spero che questa guida vi abbia fatto risparmiare qualche mal di testa! Se avete dubbi, domande o se volete condividere come state gestendo questa CVE nei vostri ambienti, contattatemi pure su LinkedIn o se avete bisogno di una consulenza personalizzata, potete prenotare una call nel footer di questa pagina.

Wall Street si affida all'IA, l'Europa costruisce il suo fortino digitale: due futuri a confronto

postmaster@mlazzarotto.it (Marco Lazzarotto) — Tue, 14 Apr 2026 00:00:00 +0100

La notizia è di quelle che definiscono un’epoca: la Casa Bianca sta spingendo le più grandi banche d’affari del mondo¹ — parliamo di colossi come Goldman Sachs, Bank of America, e Citigroup — a usare l’intelligenza artificiale di Anthropic (Claude Mythos) per la loro cybersicurezza. Un’alleanza tra governo, finanza e big tech che sembra un trailer di un film di fantascienza.

Ma dietro i riflettori di questa mossa apparentemente avveniristica, si nascondono due domande fondamentali che ci riguardano tutti, da Trento a San Francisco:

L’IA sta per rendere obsoleti gli esperti di sicurezza informatica?
Mentre gli USA si legano a un’unica “scatola nera”, cosa sta facendo l’Europa per non rimanere a guardare?

Spoiler: le risposte sono molto più complesse e interessanti di un semplice “sì” o “no”.

Il mito dell’IA “ladra” di lavoro: i dati dicono altro

“Ok Google, trovami un bug”: il mito dell’IA che ci ruba il lavoro

La prima reazione istintiva è la paura. Se un’IA può fare red teaming e scovare vulnerabilità, che ne sarà delle decine di migliaia di professionisti che oggi lo fanno come lavoro?

Qui, per fortuna, i dati ci vengono in soccorso e dipingono un quadro completamente diverso. Partiamo da un numero che fa impressione: secondo il Fortinet Global Cybersecurity Skills Gap Report del 2025², a livello globale mancano all’appello 4,7 milioni di professionisti della cybersecurity. Non è un errore di battitura. In Italia, il divario è altrettanto serio, con circa 136.000 annunci di lavoro all’anno nel settore ICT contro solo 73.000 nuovi talenti in ingresso³⁴.

L’IA non arriva in un mercato saturo per rubare posti, ma in un settore in piena emergenza dove le forze umane non bastano più.

Il vero gioco: Monopolio USA contro Sovranità Europea

Secondo Gartner⁵, entro il 2026 il 50% dei Centri Operativi di Sicurezza (SOC) userà l’IA come supporto decisionale. L’obiettivo non è sostituire l’analista, ma dargli un “superpotere”: automatizzare i compiti ripetitivi, analizzare quantità di dati ingestibili per un umano e segnalare solo le anomalie che richiedono intuito e creatività. L’IA diventa un alleato, un force multiplier che permette ai team, oggi sotto organico e stressati, di concentrarsi sulla strategia anziché sulla routine.

La mia opinione è che il profilo del professionista della sicurezza evolverà: da tecnico iper-specializzato a stratega e supervisore di sistemi intelligenti. Il suo compito non sarà più trovare l’ago nel pagliaio, ma insegnare all’IA come si cerca l’ago e, soprattutto, capire se quello che ha trovato è davvero un ago.

Il vero gioco: USA vs. Europa, Monopolio vs. Sovranità

E qui arriviamo al cuore geopolitico della faccenda.

Atto Primo: La scommessa americana sul “tutto e subito”

Da una parte abbiamo il Team USA. Il governo fa da sponsor, Wall Street adotta in massa una soluzione proprietaria e potentissima. Veloce, efficiente, centralizzato. La quintessenza dell’approccio americano. Persino Jamie Dimon di JPMorgan, noto scettico, è stato invitato al tavolo ¹(anche se non ha partecipato). Il rischio? Un vendor lock-in spaventoso. Affidare la sicurezza dell’infrastruttura finanziaria più critica del pianeta a un unico fornitore privato crea un singolo punto di fallimento (un single point of failure) dalle conseguenze inimmaginabili. E, non dimentichiamolo, un precedente storico che ci insegna a essere prudenti quando agenzie governative (come l’NSA) e colossi tecnologici dialogano troppo intimamente.

Atto Secondo: La maratona europea per l’autonomia

Dall’altra parte c’è il Team Europa, che gioca una partita completamente diversa. Più lenta, più frammentata, ma con un obiettivo chiarissimo: la sovranità digitale. L’Europa ha capito che la dipendenza tecnologica è la nuova dipendenza energetica. E si sta muovendo.

Contrariamente a quanto si pensa, non sono solo parole.

La rete dei Poli Europei per l’Innovazione Digitale (EDIH), con oltre 200 hub attivi, sta aiutando le piccole e medie imprese a digitalizzarsi scegliendo soluzioni tecnologiche europee. Non si tratta solo di innovare, ma di farlo costruendo un ecosistema autonomo.
E anche se un “Fondo per la Sovranità Digitale” a livello UE non ha ancora cifre definite, iniziative nazionali come il Fondo per la Repubblica Digitale in Italia (con circa 220 milioni di euro) dimostrano che si sta investendo per colmare il gap di competenze.

Cosa significa tutto questo? Due visioni del futuro

Due filosofie, una sola scelta: quale futuro digitale vogliamo?

Quello a cui stiamo assistendo non è solo un dibattito tecnico, ma uno scontro tra due filosofie.

L’approccio americano privilegia la velocità e la potenza, anche a costo di centralizzare il potere nelle mani di pochi giganti e creare dipendenze strategiche. L’approccio europeo è più cauto. Punta a costruire un’alternativa resiliente, aperta e distribuita, anche se questo richiede più tempo e coordinamento.

Per chi lavora nel settore, la lezione è duplice. Primo: l’IA non è una minaccia, ma lo strumento che definirà il prossimo decennio. Ignorarla non è un’opzione. Secondo: la scelta degli strumenti che usiamo non è mai neutrale. Dietro un software c’è un modello di business, un’ideologia e una strategia geopolitica.

La vera domanda, quindi, non è se useremo l’IA per la nostra sicurezza, ma quale IA sceglieremo: quella chiusa e centralizzata o quella aperta e federata?

La risposta a questa domanda deciderà chi controllerà le chiavi del nostro futuro digitale.

Perché ho spostato il mio blog da Cloudflare Pages a Kubernetes: una storia di sub-directory e libertà

postmaster@mlazzarotto.it (Marco Lazzarotto) — Mon, 13 Apr 2026 00:00:00 +0100

L’idillio iniziale: perché Cloudflare Pages sembrava la scelta perfetta

25 luglio 2022, questo è stato il primo commit sul repo Github del mio blog. In precedenza usavo Wordpress con soddisfazione, ma mi sono accorto che usavo meno del 10% delle funzionalità del CMS per il mio blog, che richiedeva manutenzione continua per evitare rischi di sicurezza. Ho cominciato a vagliare diversi strumenti che mi potessero dare la possibilità di scrivere un blog in formato semplice (Markdown), senza necessità di un backend e di un database e con una manutenzione minima.

Fu durante quella ricerca che scoprii Hugo e ne fui subito molto soddisfatto sotto diversi punti di vista e decisi quindi di salvere i miei articoli su Github e fare l’hosting del sito su Cloudflare Pages, visto che il mio dominio era gia’ configurato li'.

L’integrazione era perfetta: un push di un nuovo articolo sul branch master (allora il branch di default aveva ancora quel nome, poi sostituito con main) dava il segnale a Cloudflare Pages (ora chiamato Workers & Pages) che era il momento di usare Hugo per rigenerare il contenuto statico del sito e pubblicarlo.

Perfetto, non sbagliava mai un colpo e una volta sistemato, era la cosa piu’ comoda e semplice del mondo.

Leggera deviazione: unificare i domini per attrarre piu’ traffico sul portfolio

Passano gli anni, arriviamo nel 2026 e inizio la mia carriera da freelancer in ambito networking e devops e ho bisogno di portare piu’ traffico sul mio sito portfolio lazzarotto.dev per attrarre potenziali clienti.

Uno dei suggerimenti migliori che ho ricevuto, è quello di spostare il blog da mlazzarotto.it (che ha portato 1000 visite negli ultimi 90 giorni) e unirlo al dominio lazzarotto.dev per uniformare i domini.

Il motivo era piuttosto semplice: agli occhi di Google avevo due siti web distinti e in competizione tra loro:

mlazzarotto.it (il blog)
lazzarotto.dev (il portfolio)

Qui avevo due strade:

spostare il blog nel sottodominio blog.lazzarotto.dev
spostare il blog nel path lazzarotto.dev/blog

Facendo qualche ricerca online, ho capito che la seconda opzioni era quella consigliata da tutti i “pro” del campo web design e SEO.

L’ostacolo inaspettato: il problema del miodominio.dev/blog

Cloudflare Workers & Pages funziona benissimo quando il sito statico da pubblicare viene esposto nella root del dominio (o sottodominio) come https://mlazzarotto.it/, ma diventa velocemente un inferno cercare di pubblicare il sito web sul subpath https://lazzarotto.dev/blog per via della logica di Cloudflare.

Non nego di aver speso diverse ore a cercare di far funzionare i workers per pubblicare il sito nel modo giusto, e ci sono anche arrivato vicino, ma c’era sempre qualche problema di alcune risorse (CSS e JS) che non venivano referenziate correttamente da Hugo. E quindi il sito era visibile, ma senza styling e senza componenti dinamici.

Il momento della decisione: valutare le alternative

Anche se il mio focus professionale non è primariamente sui servizi di hosting per siti statici, ho esplorato le alternative più comuni per il mio caso d’uso.

Una delle prime alternative che ho scartato è stata GitHub Pages, principalmente per via di un uptime non sempre impeccabile per i miei standard. A questo si aggiunge una mia preferenza personale a distanziarmi dall’ecosistema Microsoft e dalla sua attuale direzione.

L’immagine qui sotto e’ stata presa da https://mrshu.github.io/github-statuses/ il giorno 11 aprile 2026 e oggettivamente non mi fa impazzire, per quanto il mio blog non necessiti di di uptime al 99.9999%.

Esistono poi altre soluzioni come Netlify e Vercel ma rimaneva comunque il problema dell’uso di una subpath per rendere disponibile questo blog su https://lazzarotto.dev/blog. Pertanto, visto che sto gia’ facendo hosting del mio portfolio su Kubernetes usando Traefik come reverse proxy, ho deciso di tenere anche il blog nel mio homelab.

La nuova architettura: un’occhiata al nuovo setup

La nuova architettura prevede l’uso di Gitea come repository e per la parte di Continuos Integration, Kubernetes per il deployment del blog e ArgoCD per la parte di Continuos Delivery.

Con questi 3 strumenti sono riuscito a replicare in maniera soddisfacente la combinazione che usavo precedentemente, ovvero Github + Cloudflare Pages, in modo piuttosto semplice (relativamente) e che mi permette comunque di avere la pubblicazione di un nuovo post in meno di 5 minuti.

Di seguito illustrero’ come funziona la pipeline.

Gitea: il controllo del mio codice

Utilizzo Gitea gia’ da un po’ di tempo per tenere in locale i miei progetti personali, tra i quali anche il codice del mio sito portfolio, e lo uso anche come software di Continuous Integration grazie alla funzionalita’ Gitea Actions che e’ praticamente una copia di Github Actions.

Nel repo del blog ho create quindi un workflow che crea un’immagine Docker, la carica sul registry Docker (sempre su Gitea) e poi modifica il manifest di Kubernetes in modo che ArgoCD aggiorni il deployment.

La configurazione del workflow e’ piuttosto semplice e usa alcuni packages esterni da Github.

Kubernetes: l’orchestratore di tutto

Mentre Gitea si occupa di gestire il codice sorgente, Kubernetes ha il compito di orchestrate i pod (2 repliche) ed assicurarsi che l’applicazione sia sempre funzionante grazie all’implementazione di healt-check.

Il deploy avviene automaticamente grazie all’integrazione di ArgoCD che fa il deploy del nuovo replicaSet appena Gitea modifica il manifest.

Il tutto avviene mantenendo un’alta affidabilita’ e senza downtime.

Il quadro generale

Di seguito potete vedere lo schema di come funziona il mio workflow e la pipeline tra Gitea, ArgoCD e Kubernetes.

Riflessioni finali: era la mossa giusta?

Quindi, era la mossa giusta? Assolutamente sì. Ho barattato la semplicità di un servizio gestito con la totale flessibilità di una soluzione mia, risolvendo il mio problema specifico e costruendo una piattaforma su cui potrò sperimentare ancora a lungo. Per me, è una vittoria su tutti i fronti.

Ora confrontiamo i pro e i contro di questa soluzione.

Pro

Controllo completo del workflow
Codice sorgente privato nel mio homelab, cio’ significa che non verra’ usato da Github per il training di Copilot
Nessun costo (ovviamente, in questo calcolo non considero il costo più grande: il mio tempo; ma dato che l’obiettivo era anche fare pratica con nuovi strumenti, lo considero un investimento formativo a tutti gli effetti)
Possibilita’ di testare differenti tipi di workflow e fare pratica con gli strumenti

Contro

Uptime non allo stesso livello di Cloudflare (SPOF ovunque, del resto e’ il mio laboratorio e non ho nessuna ridondanza)
Velocita’ forse leggermente minore (ma uso comunque Cloudflare per il caching)
Piu’ elementi che possono rompersi e quindi potenzialmente piu’ tempo da perdere per sistemare cio’ che si rompe.

Prossimamente: come ho automatizzato tutto con ArgoCD

Nel prossimo articolo di questo blog analizzero’ nel dettaglio come ho implementato il deploy automatico tramite ArgoCD.

Attacco a LiteLLM: Perché pip install ti ha tradito e requirements.txt ti ha salvato

postmaster@mlazzarotto.it (Marco Lazzarotto) — Wed, 25 Mar 2026 00:00:00 +0100

Introduzione: L’illusione di sicurezza di un comando innocente

Chi non conosce il comando pip? E’ uno dei comandi piu’ utilizzati per chi sviluppa codice in Python o per chi utilizza regolarmente software open-source distribuiti sul repository PyPi. pip e’ quel comando che (almeno nella mia esperienza) non delude mai ed e’ praticamente essenziale (anche se ultimamente sta cedendo il posto ad altri strumenti come Poetry e uv) per chi ha bisogno di installare librerie per sviluppare con Python, ma talvolta, questo senso di sicurezza puo’ farci cadere in un brutto tranello.

Ma cosa succede quando questa fiducia viene tradita? E’ esattamente quello che e’ successo il 24 marzo 2026. Un tranello preparato con cura da un gruppo di hacker conosciuto come TeamPCP che ha trasformato pip install in un’arma per raccogliere secrets (come variabili di sistema, chiavi SSH, credenziali di provider cloud) e tentare lateral movement tramite cluster Kubernetes.

Anatomia di un disastro annunciato: Cosa è successo a LiteLLM?

Il payload iniettato non era uno scherzo: era un credential stealer progettato per scandagliare l’ambiente alla ricerca di env vars, chiavi SSH, credenziali AWS/GCP/Azure, token Kubernetes, per poi esfiltrare tutto verso un dominio malevolo (models.litellm.cloud).

Il team dietro a LiteLLM ha infatti dei workflow CI/CD per portare il proprio software dallo stato di codice sorgente a pacchetto sul repo PyPi. Uno di questi workflow si occupa di eseguire una scansione del proprio codice e delle dipendenze (tramite Trivy) prima di andare a distribuire il pacchetto.

Ed e’ stato proprio Trivy (a quanto pare) ad aver permesso al gruppo TeamPCP di bypassare questo workflow di sicurezza per caricare su PyPi le due versioni di LiteLLM vulnerabili.

Il Tradimento di pip install <package>

Come scrivevo sopra, il comando pip e’ proprio quel comando di cui si ha solitamente fiducia cieca, a cui si affida il compito di aggiornare o installare le varie librerie necessarie e usandolo, pero’, diamo lasciamo il “controllo” a lui.

Lasciando il controllo a pip, almeno in questo caso, ha causato pero’ l’ingresso delle versioni vulnerabili di LiteLLM in miglia di sistemi, che sono diventati insicuri e potenzialmente compromessi. Cio’ e’ successo semplicemente perche’ e’ stato deciso di aggiornare le librerie senza curarsi di quale versione venisse installata.

E non e’ solo teoria. Il team di LiteLLM ha confermato che chi usava la loro immagine Docker ufficiale non e’ stato colpito. Perché? Semplice: quell’immagine usava un file requirements.txt con le versioni pinnate! È la prova concreta che questa pratica, da sola, ha fatto da scudo a chissà quante aziende.

Esempio di un Dockerfile insicuro

# Dockerfile VULNERABILE
FROM python:3.11-slim
WORKDIR /app
RUN pip install litellm fastapi uvicorn
...

Una build basata su un Dockerfile come questo, eseguita nella finestra temporale dell’attacco, avrebbe installato la versione 1.82.7 senza battere ciglio, aprendo una falla enorme nella sicurezza dell’infrastruttura.

L’Eroe che non ti aspetti: requirements.txt e il potere del pinning

Con il pinning andiamo a dire a pip “installa questa versione e non aggiornarla, mai”. In pratica stiamo fissare virtualmente una specifica versione con una puntina da disegno. Questa non e’ solo una best practice (in Python, cosi’ come in Docker o in altri software di gestione pacchetti) per evitare problemi di breaking changes introdotte nei pacchetti nuovi, ma anche evita l’installazione scosiderata di nuove versioni con potenziali problemi.

Uno di quei problemi che va a prevenire, infatti, (anche se in modo relativo) e’ l’installazione di versioni nuove e non testate e che potenzialmente sono affette da bug importanti o da vulnerabilta'.

Alziamo il livello: Dalla toppa del momento a una strategia di Supply-Chain Security

La sicurezza della supply-chain e’ una delle sfide piu’ critiche per le aziende moderne che si occupano di distribuire software. Parte della sfida e’ che non esiste una definizione univoca e funzionale di sicurezza della supply-chain ed e’ una sfida che si estende su un’area estremamente ampia che include tutto, dalle minacce fisiche alle minacce informatiche (come in questo caso).

Se prendiamo ad esempio un software con LiteLLM che nel file requirements.txt contiene circa 80 righe di dipendenze e se pensiamo che ogni dipendenza usera’ con tutta probabilita’ altre dipendenze, si crea una catena di opportunita’ per un attaccante di infiltrarsi potenzialmente in decine o centinaia di migliaia di host diversi.

Ma allora quali sono i comportamenti da attuare per prevenire un attacco di questo tipo?

Valutazione dei vendor e delle librerie: e’ necessario valutare attentamente ogni libreria (che sia open-source o commerciale) prima dell’integrazione, controllando la reputazione del maintainer;
Pratiche di sviluppo sicuro: adottare il framework NIST SSDF per definire requisiti di sicurezza e scansioni automatiche con strumenti quali Dependabot o Snyk e integrare strumenti di code signing per garantire che il software distribuito non sia stato manomesso durante la build o la distribuzione;
Soluzioni pratiche immediate: usare Sigstore e Codign per code signing nelle pipeline CI/CD per firmare container e binari.

Conclusioni: La fiducia è bene, il controllo è meglio

La fiducia nel mondo open-source e’ sicuramente fondamentale, ma va abbinata a pratiche di sicurezza robuste, come il pinning o tool come Dependabot che verificano le dipendenze usate.

Secondo voi, attacchi di questo tipo diventeranno la nuova normalità nel mondo open-source?

Proteggere la supply-chain del software non è un’opzione, ma una necessità. Se la sicurezza delle tue pipeline di CI/CD è una priorità e vuoi capire come implementare strategie robuste come quelle descritte in questo articolo, visita il mio portfolio per scoprire come posso aiutarti.

Kubernetes, Longhorn e immagini non-root: cronaca di un fix di permessi

postmaster@mlazzarotto.it (Marco Lazzarotto) — Sun, 08 Feb 2026 00:00:00 +0000

Intro

Per la mia nuova attivita’ da freelancer come DevOps Engineer, ho pensato di sviluppare un sito web utilizzando Flask come backend e un template (il cui nome e’ “Simone - Personal Portfolio Template”), acquistato da ThemeForest come frontend.
Niente di troppo complicato; HTML, CSS e Javascript fanno il 90% del lavoro, e il restante 10% e’ composto dal backend in Flask che si occupa di gestire il funzionamento interno come il contact form con Captcha, il routing delle pagine, l’endpoint per il livenessProbe di Kubernetes e tutta quella parte per i motori di ricerca (robots.txt e sitemap).

E’ da un paio di mesi che sto hostando questo sito web lazzarotto.dev sul mio homelab tramite Kubernetes sul mio cluster di 3 nodi K3S, con due repliche per HA (decisamente overkill) e Longhorn come storage (in realta’ usato solo per i file di log di Flask). Fino alla settimana scorsa utilizzavo l’immagine piu’ comune per un sito web in Flask, ovvero python:3.14-slim; si tratta di un’immagine Docker basata sulla famosissima distro Linux Debian Trixie.

Immagine Non-Root e Distroless

Il sito web funzionava bene con l’immagine Docker menzionata in precedenza, ma era da parecchio tempo che su Reddit (e non solo) sentivo parlare di queste immagini distroless e senza utente “root”, che permettevano di avere un livello di sicurezza maggiore rispetto alle classiche immagini Docker.
E per questo motivo, oltre al fatto che volevo “mettere le mani in pasta” e imparare, ho deciso di convertire il mio Dockerfile per avere un’immagine Docker del mio sito web root-less e distro-less.

Ho pertanto utilizzato comunque l’immagine python:3.14-slim come builder nel mio Dockerfile, ma, ho usato gcr.io/distroless/python3-debian13:nonroot come release.
Quindi, immagine costruita, fatto il deploy su Kubernetes con la nuova immagine e il pod partiva, ma dopo qualche secondo andava in crash. Guardando tra i log del pod, scoprivo che loguru (la libreria per il logging) non riusciva a scrivere il file di log nella cartella che avrebbe dovuto essere “montata” dal PVC di Longhorn.

Troubleshooting su un Container Distroless

Se avete mai lavorato con un container distroless, sicuramente saprete quanto sia complicato fare troubleshooting di un’app in un container del genere. Per chi non lo sapesse, un’immagine distroless e’ un’immagine Docker in cui manca qualsiasi programma basilare di Linux, tra cui: apt/yum, ls, tar, sh o bash. E quindi e’ impossibile usare docker exec o kubectl exec per entrare nel container e controllare lo stato del mountpoint in questione.

A questo punto, il mio pensiero era “ho cambiato due cose: distro e utente che fa girare l’app”. E non avevo idea di quale delle due modifiche effettuate sull’immagine avesse introdotto il problema della scrittura dei log.
Cio’ che mi rimaneva da fare era ricreare l’immagine Docker, comunque senza utente “root”, ma con una distro di base in modo da avere accesso quantomeno a ls, touch, etc.

Tengo a sottolineare che tutto cio’ avveniva mentre il mio sito web era offline perche’ non ho un ambiente di test nel mio homelab (non ancora, almeeno).

Una volta fatto il deploy del pod con la nuova immagine di “debug”, riuscivo a loggarmi nel pod (anzi, nel container del pod) e a rendermi conto che la cartella /app/logs non era di proprieta’ dell’utente corrente (se ricordo dovrebbe essere un utente con UID 1000), ma bensi’ di proprieta’ di root.

Come Perdere Tempo Chiedendo a Gemini la Soluzione

Mi sono rivolto inizialmente a Gemini 2.5 Flash (lo so, avrei dovuto usare il modello Pro, ma pensavo che la soluzione fosse semplice) per trovare la soluzione al problema dei permessi della cartella logs.

Le sue risposte sembravano veramente buone ed era sempre molto self confident, come succede sempre con le sue allucinazioni, ça va sans dire. Ci sono stato dietro per mezz’ora circa, ma alla fine mi sono arreso e mi sono rimesso a cercare con Google, in maniera “vecchio stile”.

La Soluzione

La soluzione e’ arrivata tramite una issue del repo Github del progetto Longhorn che mi ha salvato.

In breve, il problema nasce dal fatto che Longhorn, quando “monta” il PVC nel container, imposta l’utente e il gruppo owner a root, e questo fa in modo che l’utente non-root della mia immagine non possa accedere a tale PVC.

Ci ho messo comunque un po’ di tempo a mettere assieme i pezzi, lo devo ammettere, ma alla fine ho scelto la soluzione numero 7 (Case 7) che era la migliore per il mio caso d’uso perche’ non mi richiedeva di creare StorageClass custom o stravolgere i manifest, ma di agire direttamente sul securityContext del mio Deployment.
In pratica, si tratta di dire a Kubernetes: ‘Ehi, quando monti questo volume, per favore assicurati che appartenga a un gruppo a cui il mio utente applicativo può scrivere’. Semplice ed efficace.

Conclusioni e Manifest

Ecco qua, un intero pomeriggio di debug per aggiungere tre righe di YAML al mio securityContext. Ma al di là della soluzione tecnica, questa esperienza mi ha ricordato due cose importanti.
Primo: le immagini minimali e non-root sono fantastiche per la sicurezza, ma possono rendere il debug un vero incubo se non si è preparati. Secondo: mai sottovalutare il potere di una ricerca “vecchio stile” su GitHub issues quando l’AI ti manda fuori strada.

Adesso il mio sito è di nuovo online, più sicuro di prima, e io ho imparato una lezione preziosa sui permessi dello storage in Kubernetes.

Aggiungo qui sotto la parte utile del mio manifest che ho usato per il deployment dell’app.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: lazzarotto-dev
 namespace: dmz
 labels:
 app: lazzarotto-dev
spec:
 replicas: 2
 selector:
 matchLabels:
 app: lazzarotto-dev
 revisionHistoryLimit: 2
 template:
 metadata:
 labels:
 app: lazzarotto-dev
 spec:
 securityContext:
 runAsGroup: 1000
 runAsNonRoot: true
 runAsUser: 1000
 fsGroup: 2000
 containers:
 - name: lazzarotto-dev
 image: git.mlazzarotto.it/marco/lazzarotto_dev:20260205-113032
 imagePullPolicy: Always
 [...]

Aumentare La Sicurezza Di Navidrome: Autenticazione SSO con Traefik e Authentik

postmaster@mlazzarotto.it (Marco Lazzarotto) — Sun, 11 May 2025 00:00:00 +0000

Introduzione

I servizi di streaming musicale come Navidrome offrono un modo fantastico per accedere alla propria collezione musicale personale da qualsiasi luogo. Tuttavia, l’esposizione di tali servizi a Internet comporta problemi di sicurezza.

Questa guida mostra come proteggere l’istanza di Navidrome utilizzando le funzionalità di Single Sign-On (SSO) di Authentik dietro il reverse proxy Traefik.

Implementando questa configurazione, aggiungerete un ulteriore livello di sicurezza al vostro server musicale, mantenendo al contempo un comodo accesso per gli utenti legittimi.

Presupposti e record DNS

Questa guida presuppone che abbiate già installato e configurato

Authentik come identity provider
Traefik come reverse proxy
Navidrome come server di streaming musicale

Per gli scopi di questo tutorial, utilizzeremo i seguenti domini:

music.example.com: L’istanza di Navidrome rivolta al pubblico
example.com: Il vostro dominio esterno
internal.example.com: Il vostro sottodominio interno

Comprendere il flusso di autenticazione

Il flusso di autenticazione funziona come segue:

Un utente tenta di accedere a music.example.com
Traefik intercetta la richiesta e la inoltra ad Authentik tramite il middleware authentik-forward-auth
Se l’utente non è autenticato, viene reindirizzato alla pagina di login di Authentik
Dopo l’autenticazione, Authentik rimanda l’utente a Navidrome con le intestazioni di autenticazione
Navidrome legge queste intestazioni per identificare l’utente e concede l’accesso di conseguenza

È importante notare che la nostra configurazione esclude deliberatamente l’autenticazione per due percorsi specifici:

/share/: Permette l’accesso anonimo ai link musicali condivisi
/rest/: Permette l’accesso alle API per applicazioni mobili come Symfonium o DSub

Questa autenticazione selettiva fornisce sia sicurezza che funzionalità, laddove necessario.

Configurazione di Authentik

Application e Provider

Per impostare Navidrome in Authentik:

Dal cruscotto di amministrazione di Authentik, selezionare “Applications” e fare clic su “Create with Provider”
Nella schermata “Application”:
- Inserire “Navidrome” come nome
- Impostare uno slug appropriato (ad esempio, “navidrome”)
- Aggiungere una descrizione e un’icona opzionale
Nella schermata “Choose a provider”:
- Selezionare “Proxy Provider”
Nella schermata “Configure Provider”:
- Inserire un nome per il provider (ad esempio, “navidrome-proxy”)
- Selezionare il flusso di autenticazione che si utilizza di solito
- Scegliere “Forward auth (single application)”
- Inserire https://music.example.com come host esterno
Saltare la schermata “Configure Bindings” e completare la procedura guidata.

Outpost

Quindi, collegare l’applicazione all’avamposto Authentik:

Andate su “Outpost” nell’interfaccia di amministrazione di Authentik
Modificare il “authentik Embedded Outpost”
Nella sezione “Applications”, aggiungere l’applicazione Navidrome appena creata
Salvare le modifiche

Configurazione di Traefik

La configurazione di Traefik gestisce l’instradamento del traffico e l’autenticazione. Ecco il setup:

# Configurazione di Traefik per Navidrome con Authentik SSO
http:
 routers:
 to-authentik-outpost:
 entryPoints: webSecure
 rule: "Host(`music.example.com`) && PathPrefix(`/outpost.goauthentik.io/`)"
 service: authentik
 priority: 200
 middlewares:
 - authentik-forward-auth
 to-protected:
 entryPoints: webSecure
 rule: "Host(`music.example.com`) && !(PathPrefix(`/share/`) || PathPrefix(`/rest/`))"
 service: navidrome
 priority: 100
 middlewares:
 - authentik-forward-auth
 to-subsonic:
 entryPoints: webSecure
 rule: "Host(`music.example.com`) && PathPrefix(`/rest/`)"
 service: navidrome
 priority: 150
 to-navidrome:
 entryPoints: webSecure
 rule: "Host(`music.example.com`) && PathPrefix(`/share/`)"
 service: navidrome
 priority: 100
 services:
 navidrome:
 loadBalancer:
 servers:
 - url: http://navidrome.internal.example.com:4533
 authentik:
 loadBalancer:
 servers:
 - url: https://authentik.internal.example.com:9443

 middlewares:
 authentik-forward-auth:
 forwardAuth:
 address: http://authentik.internal.example.com:9000/outpost.goauthentik.io/auth/traefik
 trustForwardHeader: true
 authResponseHeaders:
 - X-authentik-username
 - X-authentik-groups
 - X-authentik-entitlements
 - X-authentik-email
 - X-authentik-name
 - X-authentik-uid
 - X-authentik-jwt
 - X-authentik-meta-jwks
 - X-authentik-meta-outpost
 - X-authentik-meta-provider
 - X-authentik-meta-app
 - X-authentik-meta-version

Spiegazione della Configurazione

La configurazione di Traefik è composta da diversi componenti chiave:

Routers:

to-authentik-outpost: Gestisce i percorsi specifici per le autorizzazioni con la massima priorità (200)
to-protected: Indirizza il traffico generale di Navidrome attraverso l’autenticazione
to-subsonic: Consente l’accesso non autenticato alle API Subsonic (/rest/)
to-navidrome: Permette l’accesso diretto ai link condivisi (/share/)

Services:

navidrome: Punta alla tua istanza Navidrome
authentik: Punta alla tua istanza Authentik

Middleware:

authentik-forward-auth: Il componente critico che inoltra le richieste di autenticazione ad Authentik e passa le informazioni sull’utente tramite intestazioni a Navidrome

La configurazione utilizza le priorità di instradamento per garantire che le eccezioni di autenticazione funzionino correttamente; i numeri più alti hanno la precedenza.

Configurazione di Navidrome

Affinché Navidrome si integri correttamente con questa configurazione di autenticazione, è necessario configurare due importanti impostazioni:

ReverseProxyWhitelist: Impostare l’indirizzo IP del server Traefik per garantire che Navidrome si fidi delle intestazioni di autenticazione
ReverseProxyUserHeader: Impostare questo parametro su X-authentik-username, in modo che Navidrome sappia quale header contiene il nome utente

È possibile configurare queste impostazioni nelle variabili d’ambiente o nel file di configurazione di Navidrome:

ND_REVERSEPROXYWHITELIST=<il_tuo_ip_traefik>
ND_REVERSEPROXYUSERHEADER=X-authentik-username

Per ulteriori opzioni di configurazione, consultare la documentazione di Navidrome.

Conclusione

Una volta completata la configurazione, l’istanza di Navidrome è ora protetta da Authentik SSO. Quando gli utenti visiteranno music.example.com, verrà presentata loro la pagina di login di Authentik. Dopo l’autenticazione, otterranno l’accesso a Navidrome.

Uno degli aspetti più comodi di questa integrazione è il provisioning automatico degli utenti. Se un utente si autentica tramite Authentik ma non esiste ancora in Navidrome, verrà creato automaticamente un nuovo account utilizzando il nome utente di Authentik (e una password randomica).

Questo approccio garantisce una solida sicurezza, pur mantenendo un accesso comodo per gli utenti legittimi, con l’esclusione dell’autenticazione selettiva per funzionalità specifiche come i link condivisi e l’accesso alle app mobili.

Risorse Utilizzate

https://github.com/brokenscripts/authentik_traefik

https://www.navidrome.org/docs/usage/reverse-proxy/

https://docs.goauthentik.io/docs/add-secure-apps/providers/proxy/server_traefik

Esporre Seafile 12 dietro Traefik: La Guida Completa Alla configurazione

postmaster@mlazzarotto.it (Marco Lazzarotto) — Thu, 01 May 2025 00:00:00 +0000

Introduzione

Seafile è una potente piattaforma open-source per la sincronizzazione e la condivisione di file che offre un’alternativa ai servizi di archiviazione cloud commerciali. Quando si implementa Seafile in un ambiente di produzione, solitamente si desidera posizionarlo dietro un reverse proxy come Traefik per gestire la terminazione SSL, il routing e funzionalità di sicurezza aggiuntive.

In questa guida, ti illustrerò la configurazione esatta di Traefik necessaria per esporre correttamente Seafile 12 su internet. Questa configurazione gestisce tutti e tre i componenti essenziali di Seafile: l’interfaccia web, il servizio di trasferimento file (seafhttp) e l’accesso WebDAV (seafdav).

Comprendere l’Architettura di Seafile

Prima di addentrarci nella configurazione, è importante capire che Seafile è costituito da più servizi che devono essere instradati correttamente:

Interfaccia Web Principale - L’interfaccia primaria con cui gli utenti interagiscono con Seafile
Seafhttp - Gestisce il caricamento e il download dei file
Seafdav - Fornisce accesso WebDAV ai file

Ciascuno di questi servizi necessita delle proprie regole di routing in Traefik.

Configurazione di Traefik

Iniziamo con la configurazione completa di Traefik necessaria per Seafile 12:

http:
 routers:
 routerSeafile:
 entryPoints: websecure
 service: seafile
 rule: "Host(`sf.mydomain.com`)"
 middlewares:
 - "HSTS"
 tls: {}
 routerSeafHttp:
 entryPoints: websecure
 service: seafhttp
 rule: "Host(`sf.mydomain.com`) && PathPrefix(`/seafhttp`)"
 middlewares:
 - "HSTS"
 - "seafhttp-strip-prefix"
 - "removeDuplicateSlashes"
 tls: {}
 routerSeafdav:
 entryPoints: websecure
 service: seafdav
 rule: "Host(`sf.mydomain.com`) && PathPrefix(`/seafdav`)"
 middlewares:
 - "HSTS"
 tls: {}

 services:
 seafile:
 loadBalancer:
 servers:
 - url: http://seafile.local:8000
 serversTransport: insecureTransport
 seafhttp:
 loadBalancer:
 servers:
 - url: http://seafile.local:8082
 serversTransport: insecureTransport
 seafdav:
 loadBalancer:
 servers:
 - url: http://seafile.local:8080
 serversTransport: insecureTransport

Configurazione del Middleware

Oltre alle regole di routing principali, dobbiamo definire alcuni middleware per gestire la sicurezza e la manipolazione dei percorsi:

http:
 middlewares:
 HSTS:
 headers:
 stsSeconds: 15552000
 stsIncludeSubdomains: true
 forceSTSHeader: true
 stsPreload: true
 frameDeny: true
 browserXssFilter: true
 seafhttp-strip-prefix:
 stripPrefix:
 prefixes:
 - "/seafhttp"
 forceSlash: true
 removeDuplicateSlashes:
 replacePathRegex:
 regex: "/{2,}"
 replacement: "/"
 serversTransports:
 insecureTransport:
 insecureSkipVerify: true

Analisi della Configurazione

Analizziamo le parti principali di questa configurazione:

1. Definizioni dei Router

Definiamo tre router separati, ciascuno gestisce un componente diverso di Seafile:

routerSeafile: Instrada le richieste all’interfaccia utente principale di Seafile
routerSeafHttp: Instrada le richieste di trasferimento file al servizio seafhttp
routerSeafdav: Instrada le richieste WebDAV al servizio seafdav

2. Regole di Routing

Ogni router utilizza una combinazione di regole basate su nome host e percorso:

Interfaccia principale: Corrisponde alle richieste a sf.mydomain.com
Seafhttp: Corrisponde alle richieste a sf.mydomain.com/seafhttp
Seafdav: Corrisponde alle richieste a sf.mydomain.com/seafdav

3. Servizi

Ogni router è collegato al suo servizio corrispondente, che definisce dove Traefik dovrebbe effettuare il proxy delle richieste:

Interfaccia principale: Proxy a http://seafile.local:8000
Seafhttp: Proxy a http://seafile.local:8082
Seafdav: Proxy a http://seafile.local:8080

4. Middleware

Applichiamo diversi middleware importanti:

HSTS: Impone l’uso di HTTPS da parte dei client
seafhttp-strip-prefix: Rimuove il prefisso /seafhttp prima dell’inoltro al backend
removeDuplicateSlashes: Pulisce gli URL con slash duplicati. Questo è diventato necessario per me dopo la migrazione da Seafile 11 a 12, ma potrebbe non essere necessario per te.

5. Considerazioni sulla Sicurezza

L’impostazione insecureTransport consente a Traefik di comunicare con i servizi interni utilizzando HTTP
Gli header HSTS garantiscono che i client utilizzino sempre HTTPS per le connessioni future
Header di sicurezza aggiuntivi proteggono da vulnerabilità web comuni

Conclusione

Questa configurazione fornisce un modo sicuro ed efficiente per esporre Seafile 12 dietro Traefik. La configurazione gestisce correttamente tutti e tre i componenti di Seafile, garantendo che gli utenti possano accedere all’interfaccia web, caricare/scaricare file e utilizzare la funzionalità WebDAV.

Utilizzando Traefik come reverse proxy, si ottengono diversi vantaggi, tra cui la gestione automatica dei certificati SSL (se configurata), potenti capacità di routing e livelli di sicurezza aggiuntivi. Questa specifica configurazione si concentra sulle esigenze di routing specifiche di Seafile implementando al contempo le migliori pratiche di sicurezza.

Ricorda che questa configurazione presuppone che tu abbia già configurato Seafile correttamente e che sia accessibile internamente agli indirizzi definiti. La configurazione presuppone inoltre che tu abbia configurato correttamente Traefik con certificati SSL per il dominio specificato.

Aumentare La Sicurezza Di Seafile: Nascondere I Campi Di Accesso Quando Si Usa SSO

postmaster@mlazzarotto.it (Marco Lazzarotto) — Sat, 26 Apr 2025 00:00:00 +0000

Potenziare la Sicurezza di Seafile: Nascondere i Campi di Accesso Quando si Utilizza SSO

Quando si tratta di proteggere la tua istanza Seafile, i piccoli dettagli fanno una grande differenza. Oggi condivido un miglioramento di sicurezza semplice ma potente che richiede solo pochi minuti per essere implementato, ma fornisce una protezione significativa per la tua fortezza di dati.

Il Problema: I Metodi di Accesso Duplici Creano Rischi

Se hai configurato il Single Sign-On (SSO) con servizi come Authentik o Authelia per la tua istanza Seafile, congratulazioni! Hai fatto un passo importante verso il miglioramento della tua postura di sicurezza. Tuttavia, esiste una vulnerabilità subdola che spesso viene trascurata.

Anche con SSO configurato, Seafile continua a visualizzare per impostazione predefinita i campi di accesso nativi con nome utente e password. Questo crea un vettore di attacco non necessario – è come installare un sistema di sicurezza all’avanguardia per la tua casa ma lasciare una porta laterale sbloccata.

I potenziali attaccanti possono ignorare la tua brillante implementazione SSO e martellare l’accesso tradizionale, tentando di forzare l’ingresso nel tuo sistema. Questo è particolarmente preoccupante perché:

Mina i benefici di sicurezza della tua implementazione SSO
L’accesso tradizionale potrebbe avere una protezione più debole contro tentativi ripetuti
Gli utenti potrebbero confondersi su quale metodo di accesso utilizzare

La Soluzione: CSS al Soccorso

La soluzione è piacevolmente semplice – alcune righe di CSS possono rimuovere completamente dalla vista quei campi di accesso vulnerabili. La bellezza di questo approccio è che non si limita a nascondere visivamente i campi; impedisce qualsiasi interazione con essi.

Ecco il magico frammento CSS di cui hai bisogno:

.login-panel {
 background: transparent;
 box-shadow: none;
}

#login-form {
 display: none;
}

.login-panel-hd {
 display: none;
}

Come Implementare Questa Soluzione

Accedi al pannello di amministrazione di Seafile
Naviga nella sezione impostazioni di sistema
Cerca il campo CSS personalizzato sotto Impostazioni
Incolla il frammento CSS mostrato sopra
Salva le modifiche
Aggiorna la pagina di accesso per confermare che i campi di accesso tradizionali siano scomparsi

Perché Questo è Importante per la Sicurezza

Considera questa modifica come la chiusura di una porta non necessaria nel tuo firewall. Rimuovendo l’interfaccia di accesso tradizionale, stai eliminando un’intera superficie di attacco. Gli attaccanti non possono più tentare di indovinare combinazioni di nome utente/password perché quei campi semplicemente non esistono più.

Questo approccio segue il principio del minimo privilegio – se SSO è il tuo metodo di autenticazione scelto, non c’è motivo di esporre percorsi di accesso alternativi.

Il Vantaggio per l’Esperienza Utente

Oltre alla sicurezza, questa modifica semplifica anche l’esperienza utente. I tuoi utenti non affronteranno la confusione di vedere molteplici opzioni di accesso – verranno guidati direttamente al tuo provider SSO, riducendo potenziali confusioni e ticket di supporto.

Considerazioni Finali

La sicurezza non riguarda sempre implementazioni complesse. A volte, le misure di sicurezza più efficaci sono le più semplici – come rimuovere punti di ingresso non necessari. Questa piccola modifica CSS rappresenta la perfetta intersezione tra maggiore sicurezza e migliore esperienza utente.

Ricorda: nel mondo della sicurezza, ciò che non può essere visto spesso non può essere sfruttato. Buona protezione!

Installazione di Zabbix-agent in Home Assistant OS

postmaster@mlazzarotto.it (Marco Lazzarotto) — Fri, 13 Dec 2024 00:00:00 +0000

Introduzione

Home Assistant OS è una distribuzione Linux altamente specializzata e ottimizzata per l’esecuzione della piattaforma domotica Home Assistant.

Una delle sue caratteristiche principali, che può rappresentare sia un vantaggio in termini di sicurezza che uno svantaggio in termini di flessibilità, è l’impossibilità di accedere direttamente alla console del sistema operativo.

Questa limitazione rende particolarmente complessa l’installazione di software aggiuntivo come l’agent di Zabbix, strumento essenziale per il monitoraggio del sistema.

La Soluzione

Per fortuna, la comunità open source viene ancora una volta in nostro aiuto.

Grazie al prezioso contributo dell’utente GitHub pschmitt, è stata sviluppata una soluzione elegante che permette di aggirare questa limitazione.

L’approccio proposto consiste nell’installare l’agent di Zabbix come add-on nativo di Home Assistant, integrandosi perfettamente con l’ecosistema esistente.

Il Repository

L’utente pschmitt mantiene un repository GitHub pubblico, accessibile all’indirizzo https://github.com/pschmitt/home-assistant-addons/, dove ha reso disponibile il codice necessario per l’installazione dell’agent Zabbix.

Questo repository è stato specificamente progettato per essere compatibile con il sistema di add-on di Home Assistant, garantendo un’installazione pulita e sicura.

Procedura di Installazione

Per integrare il repository nel vostro sistema Home Assistant, avete a disposizione due metodi:

Metodo Manuale: Potete seguire la procedura standard per l’aggiunta di repository di terze parti, dettagliatamente descritta nella documentazione ufficiale di Home Assistant all’indirizzo: https://www.home-assistant.io/common-tasks/os#installing-third-party-add-ons
Metodo Automatico: Per una procedura più rapida e a prova di errore, potete utilizzare il link diretto che automatizza l’intero processo di aggiunta del repository:

Completamento dell’Installazione

Una volta completata con successo l’aggiunta del repository, all’interno del vostro Home Assistant saranno disponibili due nuovi add-on: zabbix-agent e zabbix-agent2.

Questi add-on rappresentano rispettivamente la versione classica e la versione più recente dell’agent Zabbix. Dopo aver scelto e installato l’add-on più adatto alle vostre esigenze e averlo configurato correttamente, sarete in grado di monitorare il vostro server Home Assistant attraverso la piattaforma Zabbix.

Questa integrazione vi permetterà di mantenere sotto controllo tutti i parametri critici del vostro sistema Home Assistant, garantendo una supervisione professionale della vostra installazione domotica.

Hugo - Generatore di Siti Statici

postmaster@mlazzarotto.it (Marco Lazzarotto) — Sat, 13 Aug 2022 00:00:00 +0000

Cos’è un generatore di siti web statici

Un generatore di siti web statici è un software che genera un sito web HTML statico usando come “input” dei dati grezzi e del codice come templates.

In sostanza, un generatore di siti statici automatizza il compito di generare le singole pagine HTML e le rende pronte per essere servite agli utenti in anticipo.

Siti web dinamici e statici

Un sito web statico quindi è un sito web composto di una o più pagine web HTML che vengono caricate sempre nello stesso modo, in modo piuttosto basico in quanto non viene utilizzato codice Javascript o eseguite operazioni su database.

L’opposto di un sito web statico, è il sito web dinamico (o CMS). Quest’ultimo genera le pagine HTML da servire all’utente in maniera dinamica e cioè quando l’utente ne fa richiesta. Può utilizzare variabili come ora, data, cookies o geolocalizzazione, per fornire all’utente un’esperienza d’uso personalizzata. Tutto questo viene supportato da codice Javascript.

Esempi di generatori di siti web statici:

Hugo
Jekyll
Gatsby
Next.js

Esempi di siti web dinamici:

Wordpress
Joomla
Drupal
Magento

Come funziona

Un generatore di siti web statici come Hugo, non è altro che un programma il cui scopo è generare pagine web a partire da codice Markdown e un template a scelta.

Il codice Markdown, utilizzato sotto forma di file, serve al programma come sorgente dal quale ottenere il testo delle varie pagine del sito. Il template invece è un codice di sviluppatori terzi che si occupa della formattazione delle pagine web.

Unendo i due componenti, si ottengono delle pagine in formato HTML con all’interno testo e formattazione.

Per utilizzare Hugo basta un computer (anche offline), Hugo infatti può funzionare come web server standalone, ma solo per motivi di test. All’esecuzione del comando hugo publish il software genererà tutte le pagine web.

Perché ho scelto Hugo

Precedentemente utilizzavo Wordpress, un potentissimo CMS adatto a mille utilizzi diversi, ma per me anche troppo. Per il mio tipico utilizzo era troppo potente, direi addirittura overkill, con le centinaia di opzioni diverse a volte era difficile trovare la pagina giusta per cambiare questa o quella impostazione.

Inoltre, l’ho scelto anche per un motivo di sicurezza e soprattutto performance.

Già, perché intanto il codice HTML statico è inattaccabile sotto il punto di vista informatico visto che non basandosi su Javascript e database, non è proprio possibile utilizzare falle per ottenere il controllo del sito (o peggio ancora, del server).

Inoltre, il funzionamento intrinseco delle pagine HTML statiche permette una velocità di accesso senza pari. Infatti, su PageSpeed Insights ottengo un punteggio superiore a 90 nella home e superiore a 95 sui singoli articoli (il collo di bottiglia sta nelle immagini, devo ancora lavorarci su).

Pro e contro

Pro

Velocità
Semplicità: una volta configurato permette di concentrarsi sulla scrittura degli articoli
Flessibilità, facilità di personalizzazione con temi
Nessun software da mantenere
Sicurezza
Possibilità di scrivere i post ovunque senza usare il CMS
Hosting gratuito (a breve un articolo a proposito)

Contro

Possibilità d’utilizzo limitate a blog o semplice sito web
Nessun editor con funzionalità di formattazione (non nativamente)
Plugin limitati e non installabili con un singolo click
Configurazione iniziale non proprio banale

Considerazioni

Come avete potuto vedere Hugo, ma i generatori di siti statici in generale, sono adatti a chi ha poche pretese dal punto di vista di plugin e aggiunta di funzionalità, ma c’è anche da dire che i temi non si limitano all’aspetto grafico (come invece avviene su Wordpress), ma portano funzionalità al sito.

Un esempio è il tema che uso su questo sito, che per dirne una supporta la ricerca e il cambio di modalità chiaro/scuro.

D’altra parte è anche vero che la configurazione iniziale non è banale. La documentazione c’è, ma in inglese e talvolta non è proprio immediata da trovare.

Crediti: Icons created by Freepik - Flaticon

Demo di Nextcloud Hub – come provarlo

postmaster@mlazzarotto.it (Marco Lazzarotto) — Thu, 28 Jul 2022 00:00:00 +0000

Avete sempre voluto testare Nextcloud ma non avete voglia di installarlo perché troppo complicato? Oppure volete giusto dare un’occhiata per capire cosa c’è di nuovo nella versione 18 (Hub)? Oppure volete farlo vedere a un amico?

In questo articolo vi spiegherò come poter mettere le mani e testare un’istanza completamente funzionante di Nextcloud Hub, potendo provare così tutte le funzionalità offerte da questo potente strumento.

Su questo sito scrissi in passato un paio d’articoli su come provare delle versioni demo di Nextcloud senza necessità di doverlo installare.

I precedenti articoli però facevano riferimento al sito di un certo Jason Bayton, che purtroppo non ha più mantenuto queste istanze demo, e sono ferme alla versione 14.

In ogni caso non c’è da disperare, perché l’omonima software house ha reso disponibile online una versione demo dell’ultima versione di Nextcloud.

Come

Semplicissimo, andate su questo link e cliccate sul pulsante Take me there!

Cliccando su quel pulsante vi si aprirà una pagine con un modulo di registrazione, e dopo aver completato i campi vi arriverà un’email da parte di Nextcloud con un link per avviare l’istanza demo.

D’ora in poi quello che vedrete sullo schermo sarà una versione demo di Nextcloud Hub, completamente funzionante con molte app attive, compresa Collabora Online.

Collabora Online è la suite office open source utilizzata di default da Nextcloud.

ATTENZIONE: vi informo che dopo 60 minuti l’utente di prova verrà eliminato, quindi non caricate niente di personale perché altrimenti sarà tutto eliminato per lasciare spazio agli altri utenti.

CentOS 8 - Bind di logstash su porta 514

postmaster@mlazzarotto.it (Marco Lazzarotto) — Sun, 28 Nov 2021 00:00:00 +0200

La situazione: è necessario inviare i log da un vecchio apparecchio a logstash in esecuzione su un CentOS 8, per archiviare i log su ElasticSearch.

Il problema

Il dispositivo è vecchio e non supporta la modifica della porta syslog predefinita da 514/udp a qualcosa di diverso, come la porta 5140/udp. Purtroppo questo può accadere, ad esempio su appliance virtuali come ZeroShell, dove non c’è modo di cambiare la porta syslog da quella predefinita, ma c’è una soluzione rapida a questo problema!

Quello che vi mostrerò è come fare il binding di qualsiasi processo su qualsiasi porta privilegiata, mentre lo si esegue come utente non privilegiato

Perché

Si tratta di una funzione di sicurezza, in quanto se ci si connette a un servizio su una di queste porte si può essere abbastanza sicuri di essere in presenza di un servizio vero e non di un falso messo in piedi da qualche hacker. Sarebbe davvero pericoloso permettere a tutto il sistema di collegarsi a qualsiasi servizio su una porta non privilegiata, perché le porte da 1 a 1023 sono effettivamente privilegiate!

Comunque, questa non è una guida su come impostare la porta di ascolto di logstash, ma piuttosto per consentire a java di effettuare il binding su una porta < 1024.

Come

La procedura è molto semplice. Prima di tutto dobbiamo trovare il percorso del processo java fornito con logstash e il percorso della libreria libjli.so.

I due percorsi dovrebbero assomigliare a questo:

/usr/share/logstash/jdk/bin/java
/usr/share/logstash/jdk/lib/jli

Una volta ottenuto il percorso dei due file, è possibile iniziare. Immettere i seguenti comandi come root.

setcap CAP_NET_BIND_SERVICE=+eip /usr/share/logstash/jdk/bin/java; getcap /usr/share/logstash/jdk/bin/java # questo permette a java di fare il bind su porta < 1024
echo "/usr/share/logstash/jdk/lib/jli" > /etc/ld.so.conf.d/java.conf # questo sarà usato da ldconfig
ldconfig; ldconfig -v -p | grep libjli # controllo se la libreria è nella cache
reboot

Quando il sistema si carica, avviare il servizio e verificare lo stato e se è collegato alla porta giusta.

systemctl start logstash; journalctl -xef -u logstash # avvia il servizio e controlla il servizio
systemctl status logstash # controlla lo stato del servizio
ss -tlnp | grep 514 # controlla se logstash ha il bind sulla 514

A questo punto si dovrebbe avere logstash attivo e funzionante, e soprattutto in ascolto sulla porta 514.

Generazione anteprime automatica su Nextcloud con Preview Generator

postmaster@mlazzarotto.it (Marco Lazzarotto) — Sat, 06 Feb 2021 08:00:00 +0000

Ciao, oggi vi spiegherò come generare anteprime su Nextcloud delle vostre foto in anticipo, per rendere l’esperienza d’uso più piacevole.

A cosa servono le anteprime?

Le anteprime, o thumbnail, sono delle versioni più piccole delle immagini che caricate su Nextcloud (qui la guida su come installare Nextcloud su Ubuntu). Le anteprime sono molto utili nella navigazione delle cartelle di Nextcloud. Facciamo un esempio: abbiamo caricato 200 foto nella cartella Londra su Nextcloud. Se non esistessero le anteprime e volessimo entrare nella cartella Londra, non potremmo vedere l’anteprima delle foto per capire al volo quale di questa vogliamo aprire.

Ma non vengono generate automaticamente?

Sì, è vero, ma… Nextcloud genera le anteprime solo nel momento in cui è necessario. Ad esempio quando entriamo in una cartella in cui sono state caricate diverse foto. Ma cosa succederebbe se entrassi nella cartella Parigi, la quale contiene più di 1000 foto? Nextcloud sarebbe costretto a generare più di 1000 anteprime al momento, e le anteprime verrebbero visualizzate lentamente una alla volta.

Ecco la soluzione!

La soluzione al problema è abbastanza semplice e richiede solo pochissimi comandi! Ci vieni in aiuto l’applicazione Preview Generator. Questa applicazione ci permette di generare le anteprime in anticipo e definire ogni quanto Nextcloud andrà a generarle per i nuovi files.

E ora ovviamente vi spiego come installarla e configurarla!

Prima di cominciare

Colleghiamoci in SSH, con l’utente root, sulla macchina dov’è installato Nextcloud.

Diamo il seguente comando per rendere eseguibile lo script occ che ci servirà più avanti (il percorso di installazione di Nextcloud può variare):

chmod +x /var/www/nextcloud/occ

Alcuni dettagli sulla generazione delle anteprime

Di default Nextcloud per ogni foto genera diverse anteprime ognuna con una diversa dimensione, per esempio se andate a vedere i file, per la visualizzazione a griglia, la visualizzazione a elenco o ancora la visualizzazione tramite l’app Foto, saranno mostrate anteprime di dimensioni tutte diverse.

Questo comporta il fatto che per ogni file vengono create diverse anteprime e di conseguenza la generazione di centinaia o migliaia di files comporta un certo utilizzo di spazio sul disco.

Esistono però dei parametri che è possibile definire per limitare la dimensione massima delle anteprime, o per quali file generarle. Per ulteriori dettagli vi invito a leggere la documentazione ufficiale di Nextcloud qui e qui.

Per esempio, per limitare la dimensione massima delle anteprime più grandi, che di default è 4096x4096 pixel, è possibile usare i seguenti comandi (ovviamente i valori sono in pixel).

sudo -u www-data php /var/www/nextcloud/occ config:system:set preview_max_x --value 2048
sudo -u www-data php /var/www/nextcloud/occ config:system:set preview_max_y --value 2048

Un altro parametro che è possibile configurare per ridurre le dimensioni delle anteprime, è la qualità delle stesse (di default è 90).

sudo -u www-data php /var/www/nextcloud/occ config:system:set jpeg_quality --value 60

NB: se non avete voglia di modificare i parametri, potete ovviamente lasciare tutto di default! Inoltre, per controllare i parametri appena impostati, basterà aprire il file config.php di Nextcloud.

Ecco come generare tutte le anteprime

Iniziamo accedendo a Nextcloud, clicchiamo sull’icona del nostro utente e poi su Applicazioni. Andiamo quindi nella sezione Multimedia e cerchiamo Preview Generator, infine clicchiamo sul bottone Scarica e abilita.

Bene, una volta installata l’app dovremo dare solo un comando da terminale per generare tutte le anteprime per le immagini già presenti, ma questo sarà fatto solo la prima volta. Vedremo più avanti come automatizzare il processo. Diamo il seguente comando per generare tutte le anteprime:

sudo -u www-data php /var/www/nextcloud/occ preview:generate-all -vvv

Il comando potrebbe durare da pochi secondi a diversi minuti in base al numero di foto presenti e alle risorse del sistema.

Pianificazione automatica

E ora vi spiego come pianificare la generazione delle anteprime usando cron, in modo che vengano generate tutte le anteprime periodicamente per le nuove immagini.

Aprite il crontab con il seguente comando:

crontab -u www-data -e

Inserite all’interno, nell’ultima riga, il seguente comando che avvierà la generazione delle nuove anteprime ogni 30 minuti (ovviamente è possibile impostarlo con maggiore o minore frequenza):

*/30 * * * * php /var/www/nextcloud/occ preview:pre-generate

Considerazioni finali

Ottimo! D’ora in poi vedrete che navigando su Nextcloud tutte le foto saranno molto più veloci ad aprirsi, in quanto Nextcloud avrà già pronte le anteprime per le immagini. Se non vedete miglioramenti per le nuove foto, significa che la pianificazione impostata sopra dev’essere ancora eseguita, quindi basterà aspettare.

In caso di dubbi o domande non esitate a commentare. Per altri dettagli potete guardare oltre alla documentazione ufficiale di Nextcloud linkata sopra, anche la pagina Github del progetto Preview Generator.

Cos’è Nextcloud – Il Cloud personale e open source

postmaster@mlazzarotto.it (Marco Lazzarotto) — Thu, 28 Jan 2021 00:00:00 +0000

Cos’è Nextcloud

Nextcloud è un software che permette di ospitare su un computer, server o addirittura un Raspberry Pi un’infrastruttura simile a quella dei servizi di cloud storage. È un’alternativa interessante anche ai tradizionali file server, sia in ambito casalingo sia in ambito professionale.

Nextcloud come alternativa a Google Drive, Dropbox o OneDrive

I servizi di file storage come Google Drive, Dropbox o OneDrive sono diventati molto popolari ultimamente. Essi permettono infatti di sincronizzare automaticamente i vostri files con il cloud e attraverso diversi dispositivi in modo del tutto automatico.

Questi servizi di cloud storage offrono nei loro piani gratuiti solo pochi gigabyte per l’archiviazione dei dati ma offrono anche diversi piani a pagamento per chi necessitasse ulteriore spazio.

Nextcloud si propone come alternativa gratuita a Google Drive, Dropbox e OneDrive.

Vantaggi

I vantaggi sono molteplici: il costo molto basso e l’assenza di costi mensili, il controllo completo, la gestione dei dati (cosa che non è sempre scontata) e lo spazio limitato solo dalla dimensione degli hard disks a vostra disposizione.

I vantaggi di avere un server personale con Nextcloud sono i seguenti:

Costi di partenza molto bassi senza rinnovi mensili

Esatto, i costi iniziali sono bassissimi se non nulli, in quanto per poter installare un proprio server con Nextcloud non serve hardware potente. Infatti è possibile utilizzare anche un semplicissimo Raspberry Pi (il cui prezzo parte da €35 per la versione da 2GB di RAM) e poi è possibile usare i dispositivi di archiviazione che si hanno già in casa, come chiavette USB, dischi esterni, o HDD/SSD.

Privacy e controllo completo dei dati

Privacy, questa sconosciuta. Sempre più frequentemente veniamo a conoscenza di attacchi informatici mirati all’esposizione di dati sensibili, anche chiamati data breach, presso i più famosi servizi web al mondo. Purtroppo non è una cosa che possiamo controllare, a meno che non decidiamo di tenere i nostri file in casa.

Utilizzando Nextcloud come cloud storage avremo il controllo completo dei nostri dati. Come? Facile, avendo un server in casa e mettendo in atto le giuste misure di sicurezza, come l’uso di una VPN, sarà impossibile che qualche malintenzionati riesca a rubarci i dati.

Inoltre, Nextcloud supporta nativamente la crittografia End-to-End dei documenti. Ciò significa che nel caso qualche malintenzionato riesca ad avere accesso al nostro server, non riuscirà a leggere i file caricati, perché non saranno visibile in quanto crittografati.

Spazio illimitato

Lo spazio sarà illimitato o quasi, dipende da quali dischi utilizzeremo. E se un giorno dovessimo decidere che lo spazio che abbiamo non è abbastanza, basterà spostare i file su un disco più capiente.

Svantaggi

Nonostante l’hosting in casa di Nextcloud sembra la soluzione a tutto, ha degli svantaggi e dei limiti. Alcuni degli svantaggi sono:

sarà vostro dovere fare manutenzione al server e sistemarlo in caso di problemi (molto rari) e per questo sarà necessario avere una minima conoscenza del sistema operativo Linux
altresì sarete voi a dover eseguire dei backup periodici dei documenti, in caso di guasto dell’hard disk o peggio, del furto dello stesso
la velocità dei download/upload sarà limitata ovviamente dalla connessione Internet di casa e dalla velocità dei dischi

Le features di Nextcloud

Vediamo ora alcune delle principali funzionalità di Nextcloud:

Creazione di utenti multipli e gestione dei privilegi
Condivisione tra utenti e tramite url pubblici
Accesso tramite web browser, client software e app
Sincronizzazione automatica dei files tramite il client
Sicurezza, con possibilità di 2FA (autenticazione a 2 fattori) e End-to-end encryption
Controllo delle versioni delle modifiche dei files
Possibilità di creazione e modifica di files di Office (Word, Excel e PowerPoint) tramite Collabora, che viene installato di default
Decine e decine di app ufficiali e di terze parti per estendere le funzionalità di Nextcloud (qui c’è lo store)
Possibilità di collegamento con storage esterno (Google Drive, Dropbox, Amazon, ecc.)
Gestione del calendario, contatti e email
Chat e sistema di videoconferenza tramite Nextcloud Talk

E ora?

Spero di avervi dato un’anteprima su cos’è Nextcloud e cosa può fare per voi. Se avete deciso di provarlo, potete vedere la mia guida a come installarlo su Ubuntu 20.

Installare Nextcloud 20 su Ubuntu – Il Metodo “Lungo”

postmaster@mlazzarotto.it (Marco Lazzarotto) — Sat, 23 Jan 2021 08:00:00 +0000

Ciao a tutti, in questo articolo cercherò di spiegarvi nel modo più completo possibile come installare Nextcloud 20 su Ubuntu. I passaggi descritti sono stati testati su Ubuntu 20.04 LTS.

La modalità per installare Nextcloud 20 su Ubuntu della quale vi spiegherò i passi da seguire, sarà l’installazione più “difficile” e lunga, e cioè installando separatamente MySQL, Apache e PHP.

Per chi invece non avesse o non potesse seguire tutti i passaggi descritti di seguito, potrà installare Nextcloud in altri modi, ad esempio con i pacchetti snap.

Cos’è Nextcloud?

Se non sapete ancora cos’è Nextcloud e quali sono le sue fantastiche funzionalità, vi invito a leggere prima di tutto il mio post al riguardo Cos’è Nextcloud – Il Cloud personale e open source.

Prerequisiti

Una macchina fisica o virtuale con Ubuntu 20.04 LTS o superiori (potrebbe funzionare anche con versioni meno recenti), con almeno 1GB di RAM.
Tempo necessario: circa 20/30 minuti.

Tutti i comandi qui di seguito dovranno essere eseguiti come utente root oppure tramite il comando sudo da anteporre ad ogni comando.

Installazione pacchetti

Di seguito trovate un comando (bello lungo) che permetterà di installare tutti i pacchetti necessari al funzionamento di Nextcloud. Nel caso utilizziate una versione meno recente di Ubuntu, è possibile che non troviate la versione 7.4 di PHP, e dovrete ricorrere a una versione minore come la 7.3 o 7.2.

apt install apache2 php7.4 php7.4-fpm php7.4-mysql php7.4-zip php7.4-curl php7.4-apcu php-dompdf php7.4-xml php7.4-mbstring php7.4-intl php-imagick php7.4-bcmath php7.4-gmp libapache2-mod-php7.4 mariadb-server unzip

Nota: come potete vedere ho inserito tra gli altri pacchetti anche MariaDB, che utilizzeremo come database server. Per chi non volesse utilizzare MariaDB come database potrà usare MySQL, in quanto tutti i comandi della guida sono validi su entrambi i database.

Configurazione di Apache:

Cominciamo con l’attivazione dei moduli di Apache necessari al nostro scopo:

a2enmod rewrite headers env dir mime ssl

Apache per funzionare ha bisogno di alcuni file di configurazione che gli indichino quali pagine mostrare. Possiamo usare un programma come WinSCP o FileZilla per creare e modificare il file o direttamente da terminale nano o vi. Creiamo quindi il file /etc/apache2/sites-available/nextcloud.conf e all’interno del file appena creato inseriamo il testo seguente:

<VirtualHost *:80>
 DocumentRoot /var/www/nextcloud/
 ServerName your.server.com

 <Directory /var/www/nextcloud/>
 Require all granted
 AllowOverride All
 Options FollowSymLinks MultiViews

 <IfModule mod_dav.c>
 Dav off
 </IfModule>
 </Directory>
</VirtualHost>

<IfModule mod_ssl.c>
 <VirtualHost _default_:443>
 DocumentRoot /var/www/nextcloud
 ErrorLog ${APACHE_LOG_DIR}/error.log
 CustomLog ${APACHE_LOG_DIR}/access.log combined
 SSLEngine on
 SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
 SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
 <IfModule mod_headers.c>
 Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
 </IfModule>
 </VirtualHost>
</IfModule>

Il testo qui sopra, per chi non lo comprendesse, in poche parole indica ad Apache di mostrare il contenuto della cartella /var/www/nextcloud quando aprirete il sito tramite browser. In aggiunta alla porta 80, il sito sarà raggiungibile anche tramite il protocollo HTTPS sulla porta 443.

Nota: Il certificato usato è quello di default e di conseguenza self-signed, pertanto all’accesso della pagina di Nextcloud il browser mostrerà un avviso di sicurezza, ma potete ignorarlo.

A questo punto attiviamo il nuovo sito e disattiviamo quello di default che non utilizzeremo con i seguenti comandi:

a2dissite 000-default
a2ensite nextcloud.conf
systemctl restart apache2

Configurazione di MariaDB

Wizard iniziale

Prima di poter utilizzare MariaDB, sarà necessario eseguire un primo wizard per “mettere in sicurezza” l’istanza del database, in modo da evitare eventuali accessi non autorizzati.

Ora vi spiegherò come eseguire e rispondere al wizard.

Per lanciare il wizard utilizziamo il seguente comando: mysql_secure_installation

Essendo una procedura guidata, ci verranno chieste alcune informazioni.

Io vi consiglio di rispondere nel modo seguente, ovviamente come password dovrete inserirne una vostra personalizzata.

Prima domanda: premete INVIO (la password non è ancora stata definita)
Seconda domanda: inserite una password a vostra scelta per l’account root del database. Da conservare per i passaggi successivi.
Terza domanda: inserire la stessa password.
Dalla quarta domanda in poi: confermare le impostazioni di default con il tasto INVIO.

Creazione utente e schema

A questo punto andiamo a creare lo schema sul db e un utente con i privilegi sullo schema. Questi ci serviranno per far comunicare Nextcloud con il database.

Per prima cosa apriamo la shell di MariaDB, in questo modo. La password da utilizzare per fare entrare è quella impostata durante il wizard sopra.

mysql -uroot -p

Una volta entrati creiamo lo schema, l’utente e diamo i permessi completi all’utente appena creato. Al posto di password inseriamo una password a nostra scelta, abbastanza complessa.

CREATE DATABASE nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER nextcloud@localhost IDENTIFIED BY "password";
GRANT ALL PRIVILEGES ON nextcloud.* TO nextcloud@localhost;
quit

Installazione Nextcloud

Bene, arrivati a questo punto avremo Apache e MariaDB configurati. Non ci resta che scaricare il pacchetto di Nextcloud e configurarlo.

Andiamo sul sito di Nextcloud, andiamo nella sezione COMMUNITY PROJECTS e clicchiamo col tasto destro su Get ZIP file, quindi copiamo il collegamento al file.

Ora torniamo sul terminale di Ubuntu e diamo il seguente comando per scaricare l’archivio contenente i file di Nextcloud.

wget https://download.nextcloud.com/server/releases/latest.zip

Ora diamo i seguenti comandi per scompattare la cartella e dare i permessi giusti:

unzip latest.zip -d /var/www
chown -R www-data:www-data /var/www/nextcloud

Come vedete sopra, la cartella in cui ho scompattato l’archivio è /var/www. Questa è solo la cartella che contiene il “motore” di Nextcloud. Possiamo scegliere quindi dove mettere la cartella che conterrà effettivamente i nostri dati che andremo a caricare. Il percorso può essere sullo stesso disco o su un disco esterno. In ogni caso è sempre sconsigliato usare la cartella /var/www/nextcloud come contenitore dei dati, per motivi di sicurezza.

mkdir /opt/nextcloud_data
chown -R www-data:www-data /opt/nextcloud_data

Ottimo, a questo punto basterà collegarsi al server Apache tramite il browser per iniziare il wizard di setup. Nel mio caso sarà https://192.168.1.219/.

Wizard di Nextcloud

Siamo arrivati quasi alla fine, ora rimane solo da utilizzare il wizard per configurare Nextcloud. Qui sotto potete vedere come si presenta.

Nelle prime due caselle dovrete inserire il nome e la password del nuovo utente (che sarà anche amministratore). Nella terza casella sarà da inserire il percorso della cartella che conterrà tutti i file e cartelle caricati in futuro.

Infine, nelle ultime quattro caselle dovrete inserire i dati del database: nome utente (nel nostro caso nextcloud), la password che avete scelto, il nome del database (nel nostro caso sempre nextcloud) e nell’ultima casella potete lasciare il valore di default in quanto il database server è installato sulla stessa macchina che contiene anche Apache.

Cliccate quindi sul pulsante Termina configurazione e attendete che Nextcloud finisca la sua installazione. Al termine vi sarà proposta la seguente schermata di benvenuto.

Ultimi ritocchi

Giunti a questo punto, Nextcloud sarà configurato e pronto per poter essere utilizzato. Rimangono però alcuni azioni da eseguire per configurarlo al meglio e ottimizzare il sistema. Di seguito inserirò alcuni comandi da eseguire.

PHP

sed -i 's/output_buffering = 4096/output_buffering = Off/g' /etc/php/7.4/apache2/php.ini
sed -i 's/memory_limit = 128M/memory_limit = 512M/g' /etc/php/7.4/apache2/php.ini
sed -i 's/memory_limit = 128M/memory_limit = 512M/g' /etc/php/7.4/cli/php.ini
sed -i 's/upload_max_filesize = 2M/upload_max_filesize = 16G/g' /etc/php/7.4/apache2/php.ini
sed -i 's/post_max_size = 8M/post_max_size = 16G/g' /etc/php/7.4/apache2/php.ini
systemctl restart apache

Caching

sed -i "s/);/ 'memcache.local' => '\\\OC\\\Memcache\\\APCu',\n);/g" /var/www/nextcloud/config/config.php
chown -R www-data:www-data /var/www/nextcloud/config/config.php

Controllo indici database

chmod +x /var/www/nextcloud/occ
sudo -u www-data /var/www/nextcloud/occ db:add-missing-indices

Considerazioni finali

Bene, ora che avete visto come installare Nextcloud 20 su Ubuntu a questo punto avete Nextcloud funzionante e pronto. Non vi resta che utilizzarlo per caricare i vostri documenti. Ricordate comunque di fare un backup, sopratutto del database e della cartella nextcloud_data.

Come eliminare password e altro da un repo su Github

postmaster@mlazzarotto.it (Marco Lazzarotto) — Sun, 01 Dec 2019 00:00:00 +0000

Oggi vi spiegherò come eliminare dati sensibili come password da un repository Github in modo veloce e facile.

Potreste chiedermi:

Per quale motivo hai messo delle password in bella vista su Github?

Effettivamente è una bella domanda.

Il problema

In questi giorni sto sperimentando con qualche script in Python e al momento sto lavorando su uno script che controlla il prezzo su Amazon di un articolo e mi manda un’email se il prezzo scende sotto ad un certo costo.

Per spedire le email sto usando Gmail e come ben saprete, per usare il servizio di Google è necessario inserire username e password.

Il repository che ho creato è privato, quindi solo io posso accederci e vedere il codice, ma nell’ottica di renderlo pubblico è sicuramente consigliabile rimuovere la password del mio account Gmail (nonostante abbia usato una password per le app, anche se ormai l’ho già distrutta).

Come rimediare

Create un file di testo, col nome che volete (esempio passwords.txt), con all’interno le parole chiavi da rimuovere.Importante! Le parole chiavi devono essere 1 per riga.
```
pas5word123
s3cr3t
c1scol1fe
```
Scaricate lo strumento BFG Repo-Cleaner
Clonate il repo in una cartella (ad esempio C:\TEMP\repo-da-pulire) con il seguente comando:
```
git clone --mirror https://github.com/mlazzarotto/amazon-price-scraper.git
```
(Ovviamente sostituendo l’url con quello del vostro repo.)
Aprite una finestra Prompt o PowerShell e date il seguente comando sostituendo ovviamente il nome del file con le password da rimuovere e la cartella dove avete clonato il repo:
```
java -jar d:\mlazz\Downloads\bfg-1.13.0.jar --replace-text passwords.txt my-repo.git
```

Una volta eseguita l’operazione, per applicare le modifiche su Github date il comando seguente:

cd amazon-price-scraper.git
git reflog expire --expire=now --all && git gc --prune=now --aggressive

In questo modo avrete rimosso tutte le password scomode dal repository di Github e da tutti i commit precedenti.

Questo significa che se qualcuno dovesse andare a controllare la cronologia di tutti i commit precedenti che avete fatto, non troverà la password, ma la parola ***REMOVED***, come potete vedere nell’immagine qui sotto.

Nextcloud Security Scan

postmaster@mlazzarotto.it (Marco Lazzarotto) — Tue, 11 Apr 2017 00:00:00 +0000

Nextcloud ha rilasciato un utile strumento, la cui funzione è la scansione di un’installazione Nextcloud per trovare eventuali problemi di sicurezza.

Lo strumento è disponibile a questo indirizzo: Nextcloud Security Scan.

Utilizzarlo è semplicissimo: basta inserire l’indirizzo pubblico della propria installazione e cliccare su Scan.

Una volta cliccato su Scan dopo pochi secondi vedrete il risultato della scansione:

Poco più sotto potrete vedere se e quali miglioramenti alla sicurezza sono necessari per avere un punteggio più alto:

Come installare Transmission su Ubuntu 16

postmaster@mlazzarotto.it (Marco Lazzarotto) — Fri, 10 Mar 2017 00:00:00 +0000

In questa guida vi spiegherò come installare il demone (ovvero il server) di Transmission su Ubuntu 16.

Tramite questo software sarete in grado di gestire i vostri torrent sia da interfaccia Web, che da Android, iOS, Linux, Windows e Mac.

Questo può non sembrare molto utile ai più, ma è sicuramente utile se avete a casa un vecchio muletto su cui installare Transmission, o un server VPS in hosting.

Installazione pacchetti

Prima di tutto aggiungiamo il repository di Transmission con il seguente comando:

sudo add-apt-repository ppa:transmissionbt/ppa

Alla domanda successiva date INVIO.

Nota: nel caso il comando sopra non venisse riconosciuto, installare il pacchetto software-properties-common con il seguente comando:

sudo apt-get install software-properties-common

Quindi aggiorniamo la cache di apt e installiamo i pacchetti necessari:

sudo apt-get update
sudo apt-get install transmission-cli transmission-common transmission-daemon

Configurazione

Transmission è quasi pronto all’uso così com’è, ma per configurarlo al meglio basterà modificare il file /var/lib/transmission-daemon/info/settings.json.

Ora vi spiegherò quali sono le voci più importanti.

Nota bene: prima di cominciare a modificare i file di configurazione è buona cosa fare una copia del file.

sudo cp /var/lib/transmission-daemon/info/settings.json /var/lib/transmission-daemon/info/settings.json.ORIGINALE

Prima di procedere assicuratevi che il servizio sia fermo in modo da evitare che il file di configurazione venga sovrascritto usando il seguente comando:

service transmission-daemon stop

Cartella di destinazione dei downloads

"download-dir": "/var/lib/transmission-daemon/downloads",

Questa è la cartella dove finiranno i download completati. Se decidete di cambiarla, ricordati di assegnare come proprietario della nuova cartella l’utente debian-transmission e il gruppo omonimo.

"incomplete-dir": "/var/lib/transmission-daemon/Downloads",

Questa cartella è dove finiranno i files non completi. L’unica differenza con l’opzione dei download completati è la D maiuscola. Io non ho avuto modo di provarlo, ma vi consiglio di scrivere la d minuscola per sicurezza.

Porta in uso

"peer-port": 51413,

Questa è la porta da aprire sul firewall, oppure da fare il NAT.

Username e password

Le credenziali di default sono transmission come utente e transmission come password.

Per cambiare la password inserite una password a scelta al posto dei caratteri alfanumerici, inserendola all’interno dei doppi apici.

"rpc-password": "{8a8ff244e16b626fbf4eeb02f51516b1a08dcc54oX2OV9Gb",

Ad esempio

"rpc-password": "mia_password",

Stessa cosa per lo username

"rpc-username": "transmission",

Whitelist?

"rpc-whitelist-enabled": true,

Con la riga qui sopra è possibile definire se abilitare l’accesso a tutti i client o solo a quelli specificati nella riga qui sotto.

Se volete permettere l’accesso a qualsiasi indirizzo ip, impostate il parametro su false.

"rpc-whitelist": "127.0.0.1",

Questa invece è la lista degli indirizzi ip abilitati. Funziona ovviamente solo se la whitelist è impostata su true.

Alcuni esempi:
"rpc-whitelist": "127.0.0.1,192.168.*.*",
"rpc-whitelist": "127.0.0.1,192.168.1.*",

Limiti di velocità

"speed-limit-down": 100, "speed-limit-down-enabled": false, "speed-limit-up": 100, "speed-limit-up-enabled": false,

Tramite le righe qui sopra è possibile abilitare e definire i limiti di velocità. È comunque possibili modificarli successivamente dal client o interfaccia web.

Umask

"umask": 2,

Questa impostazione serve per definire i permessi sui file scaricati da Transmission.

Impostiamola a 2 per dare pieno accesso sui file al programma. Per concludere la configurazione, diamo all’utente debian-transmission il possesso della cartella /var/lib/transmission-daemon.

sudo chown -R debian-transmission:debian-transmission /var/lib/transmission-daemon

In questo modo direttamente dall’interfaccia web o dai vari clients sarà possibile modificare molte impostazioni, senza dover modificare a mano il file settings.json.

Infine avviamo il servizio

sudo service transmission-daemon start

Accedere all’interfaccia web

Per accedere all’interfaccia web basta aprire un browser e digitare http://<indirizzo_del_computer>:9091.

Vi saranno quindi richieste le credenziali e verrete accolti da una schermata come questa:

Alcuni client di terze parti

Elenco qui sotto alcuni client di terze parti per gestire i vostri torrent:

Transmission Remote Gui (Windows, Mac e Linux)
Transmission Remote (Android)

Cambiare tema all’interfaccia web

Per cambiare tema all’interfaccia web possiamo scaricare una skin gratuita da questo sito.

Ecco i comandi da inserire:

cd /usr/share/transmission
sudo mv web web_BAK
cd web
sudo wget https://github.com/ronggang/transmission-web-control/blob/master/release/transmission-control-full.tar.gz
sudo tar xzvf transmission-control-full.tar.gz

Ecco fatto. Se il browser dovesse mostrarvi ancora la vecchia interfaccia, premete CTRL + R.

In conclusione

A questo punto se avete seguito i passaggi scritti qui sopra avrete un server con Transmission installato e configurato. Se volete altra documentazione potete dare uno sguardo alla documentazione di Ubuntu liberamente accessibile a questo indirizzo TransmissionHowTo.

Contatti

postmaster@mlazzarotto.it (Marco Lazzarotto) — Tue, 28 Feb 2017 19:02:23 +0000

Per contatti mi trovate su LinkedIn,

oppure al mio indirizzo email mlazzarotto91 at gmail.com.

Come installare LAMP su Ubuntu 16

postmaster@mlazzarotto.it (Marco Lazzarotto) — Tue, 28 Feb 2017 00:00:00 +0000

Questa vuole essere una semplice guida su come installare LAMP su un computer o macchina virtuale con Ubuntu Linux.

La versione di Ubuntu che ho utilizzato per testare questa guida è la 16.04, ma è compatibile anche con le versioni precedenti di Ubuntu, a patto che tale versione sia ancora supportata (cioè che siano ancora disponibili i server da cui scaricare i pacchetti).

Cos’è LAMP?

Wikipedia utilizza la seguente definizione:

LAMP è un acronimo che indica una piattaforma software per lo sviluppo di applicazioni web che prende il nome dalle iniziali dei componenti software con cui è realizzata.

In parole povere, LAMP è un acronimo che indica una piattaforma di sviluppo utilizzata come base per moltissime applicazioni web.

Può essere utile per installare complessi siti web (ad esempio WordPress, Joomla, Redmine, Drupal e molti altri) oppure per cominciare a creare il proprio sito da zero.

Composizione di LAMP

L’installazione di LAMP prevede l’installazione di questi quattro programmi, a cui possono essere aggiunti molti altri a seconda della necessità del sito web che si desidera utilizzare.

Linux
Apache
MySQL o MariaDB
PHP

Pacchetti opzionali

phpMyAdmin
Perl
Python

Le varianti più comuni

Oltre a LAMP esistono alcune varianti. Di seguito ne elenco alcune:

XAMPP: è un pacchetto “portable” multipiattaforma. Non necessita di installazione, è piuttosto semplice da usare ma è consigliato solo per ambienti di test.
WAMP: è simile a LAMP tranne per il fatto che è stato creato per funzionare su sistemi Windows.
MAMP: simile a WAMP ma su sistema operativo Mac OS.

MySQL o MariaDB?

Questa è la domanda che alcuni di voi potrebbero farsi. Entrambi sono dei sistemi di gestione di database relazionali.

Le principali motivazioni per scegliere MariaDB sono il numero maggiore di funzionalità, le migliori performance e la maggior scelta di motori.

Io personalmente da qualche tempo scelgo MariaDB per i motivi che ho scritto qui sopra, oltre al fatto che nelle varie community e forum viene preferito a MySQL.

In questa guida sarà utilizzato MariaDB, ma l’installazione di MySQL è molto simile: basterà sostituire mysql a mariadb durante l’installazione dei pacchetti.

Installazione

Aprite da Ubuntu una shell e digitate la seguente riga per installare Apache, MariaDB e PHP 7.0.

sudo apt-get install apache2 php7.0 mariadb-server

In alternativa è possibile installare i suddetti pacchetti da Ubuntu Software Center.

Ecco fatto. Ora vediamo come gli strumenti disponibili per amministrare MariaDB (o MySQL).

Come amministrare MariaDB

Per amministrare MariaDB esistono diversi strumenti, tutti molto validi, la cui differenza sta nella semplicità d’uso e nelle funzionalità. Alcuni di questi strumenti sono: il client di MariaDB, phpMyAdmin e MySQL Workbench.

Per ognuno di essi scriverò una breve descrizione.

Il client a riga di comando

Come si può intuire è un client che si utilizza dalla shell o riga di comando. A mio parere il più potente dei tre ma anche il meno user-friendly. È adatto a utenti che conoscono bene MariaDB e il linguaggio SQL oppure per chi vuole imparare.

Il client viene installato con il pacchetto mariadb-server.

phpMyAdmin

È un’applicazione web scritta in PHP. È la più semplice da usare delle tre opzioni in quanto non è necessario conoscere la sintassi di SQL perché tutto (o quasi) il database è gestibile tramite l’interfaccia web, oltre a questo è possibile visualizzare alcuni grafici e diverse statistiche del database.

Si installa con il seguente comando:

sudo apt-get install phpmyadmin

Una volta installato (richiede Apache o lighthttpd come web server) è possibile accedere tramite http://<indirizzo_ip_del_server>/phpmyadmin.

MySQL Workbench

È un software disponibile per Windows, Linux e Mac OS.

Come livello di semplicità d’uso si posizione a metà strada tra phpMyAdmin e il client a riga di comando.

Similmente a phpMyAdmin è possibile avere alcune informazioni sullo stato del database e grafici, anche dell’utilizzo delle risorse del sistema.

A differenza di quanto si può pensare, è possibile utilizzarlo anche con MariaDB, ma con alcune limitazioni.

Come mettere in sicurezza MariaDB

Durante l’installazione di MariaDB non viene richiesta una password per l’utente root, che è vuota. Per impostarla e modificare altre impostazioni per mettere in sicurezza MariaDB, diamo il comando

mysql_secure_installation

Dopo aver dato INVIO ci saranno poste alcune domande.

Alla prima domanda ci sarà chiesta la password attuale dell’utente root. Diamo INVIO per inserire la password attuale che è vuota.

Alla seconda domanda rispondiamo Y per impostare la password dell’utente root. Inseriamo quindi 2 volte la nuova password dando INVIO per confermare.

Successivamente rispondiamo ancora Y per rimuovere l’utente anonimo.

Alla prossima domanda rispondiamo N se vogliamo usare strumenti quali MySQL Workbench dal un computer remoto, altrimenti rispondiamo Y se usiamo il client a riga di comando o phpMyAdmin.

Infine rispondiamo 2 volte Y per rimuovere il database di test e per ricaricare la tabella dei privilegi.

Apache

Di default, dopo l’installazione di Apache è possibile collegarsi a http://<indirizzo_ip_del_server> per vedere una pagina di esempio.

Apache lavora con i “Virtual Hosts”, ovvero dei file che specificano cosa far vedere in base a cosa si digita nella barra degli indirizzi.

Il file di configurazione che regola cosa Apache “mostra” si trova in /etc/apache2/sites-enabled con il nome 000-default.conf.

Quel file è un collegamento del file originale in /etc/apache2/sites-available.

Se decidete di modificarlo, vi consiglio di fare una copia dell’originale nel caso qualcosa andasse storto.

Per applicare le modifiche effettuate digitate il seguente comando:

service apache2 reload

Archivio

postmaster@mlazzarotto.it (Marco Lazzarotto) — Mon, 01 Jan 0001 00:00:00 +0000