Categoria: Tecnica

Pubblicato il

Wazuh – A cosa serve

La piattaforma Wazuh offre funzionalità XDR e SIEM per proteggere i carichi di lavoro cloud, container e server. Queste includono l’analisi dei dati di log, il rilevamento di intrusioni e malware, il monitoraggio dell’integrità dei file, la valutazione della configurazione, il rilevamento delle vulnerabilità e il supporto per la conformità normativa.

La soluzione Wazuh si basa sull’agente Wazuh, che viene distribuito sugli endpoint monitorati, e su tre componenti centrali: il server Wazuh, l’indicizzatore Wazuh e la dashboard Wazuh.

  • L’ indicizzatore di Wazuh è un motore di ricerca e analisi full-text altamente scalabile. Questo componente centrale indicizza e memorizza gli avvisi generati dal server Wazuh.
  • Il server Wazuh analizza i dati ricevuti dagli agenti. Li elabora tramite decodificatori e regole, utilizzando l’intelligence sulle minacce per individuare i noti indicatori di compromissione (IOC). Un singolo server può analizzare i dati provenienti da centinaia o migliaia di agenti e scalare orizzontalmente se configurato in cluster. Questo componente centrale viene utilizzato anche per gestire gli agenti, configurandoli e aggiornandoli da remoto quando necessario.
  • La dashboard di Wazuh è l’interfaccia utente web per la visualizzazione e l’analisi dei dati. Include dashboard predefinite per la ricerca di minacce, la conformità normativa (ad esempio, PCI DSS, GDPR, CIS, HIPAA, NIST 800-53), le applicazioni vulnerabili rilevate, i dati di monitoraggio dell’integrità dei file, i risultati della valutazione della configurazione, gli eventi di monitoraggio dell’infrastruttura cloud e altro ancora. Viene inoltre utilizzata per gestire la configurazione di Wazuh e per monitorarne lo stato.
  • Gli agenti Wazuh vengono installati su endpoint quali laptop, computer desktop, server, istanze cloud o macchine virtuali. Forniscono funzionalità di prevenzione, rilevamento e risposta alle minacce. Sono compatibili con sistemi operativi come Linux, Windows, macOS, Solaris, AIX e HP-UX.

Oltre alle funzionalità di monitoraggio basate su agenti, la piattaforma Wazuh è in grado di monitorare dispositivi senza agenti come firewall, switch, router o IDS di rete, tra gli altri. Ad esempio, i dati di log di un sistema possono essere raccolti tramite Syslog e la sua configurazione può essere monitorata tramite interrogazioni periodiche dei dati, via SSH o tramite API.

Pubblicato il

Zabbix Proxy su container con Sqlite

  1. Su Ubuntu 24.04 installa docker
  2. Lavora in “sudo -s” nella /root
  3. Fai una directory zabbix-proxy
  4. Crea una directory data con dentro sqlite e logs
  5. Dai permessi chmod -R 777 ./data/
  6. Crea un docker compose come quello che vedi qui sotto
  7. Fallo partire: docker “compose up -d”
  8. Controlla che stia su “docker ps” e anche “docker stats zabbix-proxy-sqlite”
  9. Quando si modifica il docker-compose bisogna fare “docker compose down’ e poi ‘docker compose up -d’

docker-compose.yml



services:
  zabbix-proxy-sqlite:
    image: zabbix/zabbix-proxy-sqlite3:7.0-ubuntu-latest
    container_name: zabbix-proxy-sqlite
    restart: unless-stopped

    # Limiti di risorse: proteggiamo la VM da 8GB
    deploy:
      resources:
        limits:
          memory: 1G    # Il container non supererà mai 1GB (ne usa circa 160MB ora)
        reservations:
          memory: 256M  # RAM garantita al boot

    ports:
      - "10051:10051"

    environment:
      # --- Connessione ---
      - ZBX_HOSTNAME=zp01
      - ZBX_SERVER_HOST=10.12.14.56
      - TZ=Europe/Rome

      # --- Database SQLite ---
      - ZBX_DBNAME=zabbixproxy01.sqlite

      # --- Ottimizzazione Performance (per 100 host) ---
      - ZBX_CONFIGCACHESIZE=32M      # Cache per la configurazione degli host
      - ZBX_HISTORYCACHESIZE=16M     # Buffer per i dati prima della scrittura su disco
      - ZBX_HISTORYINDEXCACHESIZE=4M # Velocizza l'indicizzazione dei dati

      # --- Tuning Processi ---
      - ZBX_STARTPOLLERS=10          # Numero di processi per interrogare gli host
      - ZBX_STARTPOLLERSUNREACHABLE=5 # Processi dedicati agli host offline
      - ZBX_STARTTRAPPERS=5          # Per dati inviati attivamente dagli agenti

    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./data/sqlite:/var/lib/zabbix/db_data
      - ./data/logs:/var/lib/zabbix/logs
    logging:
      driver: "json-file"
      options:
        max-size: "10m" # Ogni file di log massimo 10 Mega
        max-file: "3"   # Tiene solo gli ultimi 3 file


Pubblicato il

Update zabbix proxy containerized

Procedura definitiva per aggiornare un proxy Zabbix containerizzato (SQLite) — versione 7.0.x → 7.0.x

Questa procedura è valida per:

  • proxy Zabbix 7.0.x containerizzati
  • database SQLite interno
  • nessun dato da preservare (proxy online)
  • configurazione gestita via variabili ZBX_*
  • nessun bind‑mount del file di configurazione

È esattamente il modello che ora funziona.

1️⃣ Preparazione

1.1. Verifica versione attuale del proxy

bash

docker exec -it zabbix-proxy-sqlite zabbix_proxy -V

1.2. Verifica che il proxy sia online sul server

(UI → Administration → Proxies)

2️⃣ Scarica l’immagine aggiornata

bash

docker pull zabbix/zabbix-proxy-sqlite3:7.0-ubuntu-latest

Questo garantisce che il nuovo container userà l’ultima build della 7.0 LTS.

3️⃣ Spegni e parcheggia il vecchio container

bash

docker stop zabbix-proxy-sqlite
docker rename zabbix-proxy-sqlite zabbix-proxy-sqlite-old

Questo ti permette un rollback immediato.

4️⃣ Crea il nuovo container (modello corretto)

⚠️ Niente bind‑mount del file di configurazione. ⚠️ Nessun volume per il DB SQLite.

Il comando standard è:

bash

docker run -d \
  --name zabbix-proxy-sqlite \
  --restart unless-stopped \
  -p 10051:10051 \
  -e ZBX_SERVER_HOST="10.12.14.56" \
  -e ZBX_HOSTNAME="NOME_DEL_PROXY" \
  zabbix/zabbix-proxy-sqlite3:7.0-ubuntu-latest

Per gli altri proxy, cambia solo:

  • --name
  • ZBX_HOSTNAME

Esempio:

Codice

zabbixproxy02
zabbixproxy03

5️⃣ Verifica immediata

5.1. Container running

bash

docker ps | grep zabbix-proxy-sqlite

5.2. Log del proxy

bash

docker logs -f zabbix-proxy-sqlite

Devi vedere:

  • “Starting Zabbix Proxy…”
  • “received configuration data from server”
  • nessun errore sed
  • nessun errore sul log file
  • creazione del DB SQLite senza errori

5.3. Versione

bash

docker exec -it zabbix-proxy-sqlite zabbix_proxy -V

6️⃣ Verifica dal server Zabbix

UI → Administration → Proxies → proxy‑name

Controlla:

  • Last seen aggiornato
  • Stato Online
  • Nessun errore

7️⃣ Rollback (se necessario)

bash

docker stop zabbix-proxy-sqlite
docker rm zabbix-proxy-sqlite
docker rename zabbix-proxy-sqlite-old zabbix-proxy-sqlite
docker start zabbix-proxy-sqlite

Rollback istantaneo.

Pubblicato il

Copia di due directory

Se vuoi fare una copia di due directory su due NAS il comando migliore che tu possa utilizzare è RSYNC:

/bin/rsync -rtlhv –no-p –no-g –no-o –ignore-existing /volume1/a500-Musica/Music/ /volume1/music/

/bin/rsync -rtlhv –no-p –no-g –no-o –ignore-existing /volume1/a500-Photo/Photo/ /volume1/photo/

Pubblicato il

Sostituzione Sonicwall Alta Affidabilità con due nuove unità

Questa procedura serve a guidare la sostituzione di due firewall Sonicwall in alta affidabilità resi obsoleti dal passare del tempo, con una coppia di firewall in alta affidabilità.

Si assume la nuova coppia sia gia’ stata registrata, provata e configurata con la configurazione della vecchia coppia di firewall.

Si assume che il cluster HA sia funzionante e a regime (Primario Attivo e Secondario Stand by)

Occorre avere a disposizione un pc portatile con interfaccia ethernet configurata su un ip compatibile con l’interfaccia di management del firewall (se di fascia NSa) il quale è di default configurato con l’ip 192.168.1.254/24

  1. Etichettare tutti i cavi
  2. Spegnere il vecchio secondario, che deve essere in STAND-BY ovviamente.
  3. Smontare il vecchio secondario
  4. Montare il nuovo primario al posto del vecchio secondario
  5. Collegare i cavi al nuovo primario ma senza inserire sino a fondo le ethernet in modo che non siano collegate elettricamente ma pronte ad esserlo con una piccola pressione per minimizzare i tempi. L’interfaccia per l’alta disponibilità non deve essere collegata.
  6. Accendere il nuovo primario che (ripeto) non dovra’ avere i cavi elettricamente connessi.
  7. Attendere sino a che il nuovo primario sia pronto all’operativita’ (spie con la chiave inglese spente)
  8. Spegnere il vecchio primario
  9. Spingere le connessioni ethernet del nuovo primario in modo che siano elettricamente connesse.
  10. Effettuare i primi test per verificare che tutto sia perfettamente funzionante.
  11. Nota che l’interfaccia di alta disponibilità non è collegata.

NOTA BENE : In caso di problemi è sufficiente spegnere il nuovo primario ed accendere il vecchio primario per essere nella vecchia situazione sicuramente funzionante.

Se possibile lasciare questa configurazione per qualche giorno, in modo da essere perfettamente certi che il nuovo primario sia operativo esattamente come ci si aspetta.

Inserimento nuova unità secondaria

Per l’inserimento del nuovo secondario è sufficiente smontare il vecchio primario e al suo posto installare il nuovo secondario rispettando l’ordine delle interfacce ethernet. Ora è possibile collegare l’interfaccia di alta disponibilità. Accendere il nuovo secondario e aspettare. Il nuovo primario prenderà in carico il nuovo secondario, gli invierà la configurazione e lo farà ripartire.. dopo circa 10 minuti la pagina della gestione HA dovrebbe mostrare il primario attivo e il secondario in stand-by.

Pubblicato il

Proxmox aggiornamento da 8.4.16 a 9.1

Oggi 7 gennaio 2026 ho iniziato l’aggiornamento del nostro Proxmox 8.4.16 all’ultima versione. Elenco i passi necessari che ho fatto per questo aggiornamento.

A macro step questi sono i passi:

  • Allineamento di tutti i nodi all’ultima versione di PVE nel mio caso 8.4.16
  • Aggiornamento di CEPH da versione Reef (V.18) a Squid (V.19) su tutti i nodi
  • Aggiornamento di tutti i nodi alla V9.1 di PVE

Aggiornamento di CEPH da Reef a Squid

Questo si fa abbastanza velocemente: è sufficiente modificare le sorgenti ceph con
sed -i ‘s/reef/squid/’ /etc/apt/sources.list.d/ceph.list
e impostare il flag noout:
ceph osd set noout
Seguito da:
apt update
apt full-upgrade

Ovviamente su tutti i nodi.
Il flag di noout deve restare cosi’ sino alla fine dell’aggiornamento.

Aggiornamento da PVE V.8.4.16 a V9.1

Successivamente quando tutti i nodi sono su CEPH Squid si modificano le sorgenti APT in che da bookworm si modifica in trixie con un comando sed:

sed -i ‘s/bookworm/trixie/g’ /etc/apt/sources.list
sed -i ‘s/bookworm/trixie/g’ /etc/apt/sources.list.d/pve-no-subscription.list
sed -i ‘s/bookworm/trixie/g’ /etc/apt/sources.list.d/pve-enterprise.list
sed -i ‘s/bookworm/trixie/g’ /etc/apt/sources.list.d/pve-enterprise.list
sed -i ‘s/bookworm/trixie/g’ /etc/apt/sources.list.d/ceph.list
Per verifica poi fa un:
grep -R “trixie” /etc/apt/sources.list /etc/apt/sources.list.d
dovresti vedere un bel po’ di file che matchano e poi un
grep -R “book” /etc/apt/sources.list /etc/apt/sources.list.d
e non dovrebbe darti nessun risultato
Ora puoi procedere con:
apt update
Seguito da:
apt dist-upgrade
e poi un ‘reboot’
Ovviamente su tutti i nodi.
Quando hai finito dovresti avere solo da togliere il flag noout, basta che lo fai su un nodo
ceph osd unset noout

Il tuo cluster ora è V9.1

Fonti:
https://pve.proxmox.com/wiki/Upgrade_from_8_to_9?utm_source=copilot.com#In-place_upgrade
https://pve.proxmox.com/wiki/Ceph_Reef_to_Squid

Pubblicato il

Disabilitare Hyper-V per abilitare la “nested virtualization” in Vmware Workstation

Fai girare questo script se continui a ricevere l’errore da Vmware Workstation che non puo’ abilitare la “Intel VT-x”

@echo off
echo Disattivazione di Hyper-V e funzionalità correlate…

:: Disattiva Hyper-V e componenti legati
dism /Online /Disable-Feature:Microsoft-Hyper-V-All /NoRestart
dism /Online /Disable-Feature:VirtualMachinePlatform /NoRestart
dism /Online /Disable-Feature:HypervisorPlatform /NoRestart
dism /Online /Disable-Feature:Microsoft-Windows-Subsystem-Linux /NoRestart
dism /Online /Disable-Feature:Containers /NoRestart
dism /Online /Disable-Feature:Windows-Defender-ApplicationGuard /NoRestart

:: Disattiva il caricamento dell’hypervisor all’avvio
bcdedit /set hypervisorlaunchtype off

:: Disabilita la sicurezza basata sulla virtualizzazione (VBS)
reg add “HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard” /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f
reg add “HKLM\SYSTEM\CurrentControlSet\Control\Lsa” /v LsaCfgFlags /t REG_DWORD /d 0 /f

:: Disabilita Credential Guard (se attivo)
reg delete “HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard” /f

echo.
echo Riavviare il computer per applicare le modifiche.
pause

Pubblicato il

Ubuntu 24.04 – Estendere hard disk su VM

Segui questi passi:

Aumenta di quanto server il disco su Vmware

Fai ripartire la VM

Usa “cfdisk” via terminale sulla vm per effettuare il resize della partizione

Usa resize sulla partizione da allargare.

Successivamente vai su write

Ultimo step da shell usa il comando ” sudo resize2fs /dev/sda2″

Controlla con ‘df’ la nuova dimnsione della partizione.

fonte: https://www.youtube.com/watch?v=brR0G7Fg3i0

Pubblicato il

Qnap – Permessi particolari sulle cartelle nidificate.

Questo si applica quando abbiamo un utente, anche AD, che deve accedere in full control ad una cartella che è posizionata dentro ad una cartella in read-only per lui.

Occorre abilitare le “autorizzazione avanzate” come in figura

Poi nella GUI di Qnap nelle cartelle condivise dare accesso all’utente, come in figura togliendo “Applica le modifiche ai file e alle cartelle secondarie” per ovvi motivi.

successivamente via windows dare i permessi come segue per le cartelle ‘read only’:

Dare ‘Full Control’ alle cartelle che Mario Rossi deve avere il pieno accesso.

Pubblicato il

Vmware Vcsa8 – Password di root scaduta

Se hai installato un vcsa8 piu’ o meno di default, la sacdenza delle password e’ impostata a 90 giorni. Siccome di solito le cose vanno nel verso giusto (almeno nei primi 90 giorni) potrebbe capitare che un giorno entri nel vcenter e vedi un paio di errori del tipo “la password di root e’ in scadenza” in giallo e un’altro in rosso “La password di root e’ scaduta”. In realta’ non c’e’ nulla che non funzioni, ma se provi ad entrare nella console del vcsa, quella su porta 5480 per capirci, ti da un errore del genere “Exception in invoking authentication handler user password expired”.

Meno male che risolvere e’ una minchiata: entri in ssh sull’ip del vcsa con la vecchia password.. ci pensa un po’ e poi lui stesso si rende conto che sta dicendo una minchiata e ti dice che la passeword di root e’ scaduta, ti chiede la vecchia password e ti fa inserire la nuova, due vole come al solito. A questo punto puoi entrare nella parte web e correre e cambiare la scadenza da “90 giorni” a “mai”.