Progetti

🏠 Infrastruttura Linux in autogestione

Due server Debian (Raspberry Pi 4) in funzione 24/7. L'obiettivo: rendere i servizi raggiungibili da Internet in modo sicuro senza aprire nessuna porta sul router – e gestirli in modo che un guasto venga notato e possa essere risolto. Questo sito gira su questa infrastruttura.

Struttura

• Servizi: web server (nginx), password manager (Vaultwarden), filtro DNS (AdGuard Home), condivisione file, monitoraggio (Uptime Kuma, Netdata) – tutti come container Docker, gestiti con Compose e Portainer.
• Accesso: pubblicazione tramite Cloudflare Tunnel (zero trust) invece del port forwarding; amministrazione remota tramite Tailscale con subnet router verso la rete di casa.
• Secondo server: si occupa del monitoraggio e riceve i backup del primo server.

Sicurezza

• SSH solo con chiavi, login con password e come root disattivati; fail2ban contro attacchi brute force.
• TLS ≥ 1.2, HSTS e header di sicurezza incl. Content Security Policy per il sito.
• Container esposto senza privilegi di root, con file system in sola lettura e limite di processi.
• Segreti (token API) separati dagli script, in file leggibili solo dall'utente del servizio.

Backup e monitoraggio

• Script Bash via cron: snapshot coerente del database, archivio dei dati più un archivio di sistema (configurazione, crontab, inventario dei container).
• Il secondo server preleva gli archivi tramite accesso rsync in sola lettura, ne verifica l'integrità e ruota le versioni vecchie.
• Notifica di successo o errore via messenger; Uptime Kuma dà l'allarme se un backup non viene eseguito.
• Inventario di rete giornaliero con nmap/ndiff – nuovi dispositivi o porte aperte vengono segnalati.

Cosa ho imparato

Una verifica di sicurezza della mia infrastruttura ha rivelato, tra l'altro, un servizio raggiungibile pubblicamente con privilegi eccessivi, file di backup nella directory web e un database in un volume Docker non persistente. Tutto risolto, documentato e inserito nel piano di backup – da allora verifico le modifiche in modo mirato anche dall'esterno.

🖥️ Ambiente di test Proxmox VE

Progetto di apprendimento in corso: Proxmox VE come VM sotto KVM (virtualizzazione annidata) sul mio computer di lavoro – isolato dal resto della rete.

Realizzato

• Installazione, repository (no-subscription invece di enterprise) e aggiornamenti incl. cambio kernel.
• Template Debian 13 dall'immagine cloud ufficiale, cloud-init con utente e chiave SSH.
• VM distribuite da riga di comando (qm clone) – pronte in meno di un minuto.

Prossimi passi

• Backup e ripristino con vzdump – incluso un vero test di ripristino.
• Dominio AD con Windows Server 2022 (DNS, DHCP, criteri di gruppo).
• Configurazione uniforme di più VM Debian con Ansible.

🗺️ Progetto d'esame IHK: proof of concept IPAM/DDI

L'obiettivo era sostituire la gestione degli indirizzi IP su fogli di calcolo con un IP Address Management centralizzato. Ho realizzato un dominio di laboratorio isolato e valutato l'integrazione DNS/DHCP di una soluzione DDI/IPAM.

Approccio

• Dominio di laboratorio: Windows Server 2022 con AD DS, DNS e DHCP.
• DDI/IPAM: integrazione DNS/DHCP configurata e qualità dei dati verificata.
• RBAC: modello di ruoli e permessi per admin, operatori e sola lettura.
• Audit/reportistica: modifiche tracciabili ed esportazioni (ad es. CSV/PDF).

Risultato

• Integrazione DNS/DHCP verificata end-to-end nell'ambiente di laboratorio.
• Maggiore trasparenza: lease, record, cronologia delle modifiche e report invece di fogli manuali.
• Basi poste per pilota ed esercizio (backup, aggiornamenti, monitoraggio).

📡 Security lab

Per proteggere bene i sistemi voglio capire come funzionano gli attacchi: protocolli radio, RFID/NFC e sicurezza Wi-Fi – esclusivamente in ambienti di test propri o espressamente autorizzati.