(in)sicurezza digitale

2026-07-27 17:09:45

JadeProx: il cluster cinese che si è tradito da solo mentre colpiva ospedali, ministeri e università in Asia

Un server Alibaba Cloud lasciato aperto per errore ha smascherato un intero cluster di cyberspionaggio China-nexus: intrusioni attive contro un ospedale vietnamita, il Ministero degli Esteri malese, decine di istituti universitari di Hong Kong e persino un pacchetto di spear-phishing indirizzato al Congresso dell’Honduras. Group-IB lo chiama JadeProx, e la sua tradecraft ruota attorno a un loader Windows mai documentato prima, il TriBack Loader, distribuito anche tramite un finto installer di Claude.

Un errore operativo che vale un intero dossier

A metà aprile 2026 i ricercatori di Group-IB hanno individuato, nella regione Singapore di Alibaba Cloud, un server di staging esposto senza alcuna autenticazione. Al momento della pubblicazione del report, il 23 luglio 2026, il server era già stato smantellato, ma la sua cronologia bash, i pacchetti di phishing, gli strumenti post-exploitation e i path dei webshell hanno permesso di ricostruire in dettaglio un’operazione attiva su tre continenti diversi.

Gli obiettivi identificati sono eterogenei ma coerenti con un mandato di raccolta informativa ad ampio spettro tipico degli operatori legati alla Cina: il sistema di imaging medicale (PACS, Picture Archiving and Communications System) di un ospedale pubblico vietnamita, da cui transitano radiografie, TAC e risonanze dei pazienti; il Ministero degli Esteri della Malesia, violato con webshell e strumenti di tunneling; l’infrastruttura universitaria di Hong Kong, colpita con una scansione massiva; e un pacchetto di spear-phishing con decoy finanziario indirizzato al Congresso Nazionale dell’Honduras. Gli operatori sono arrivati al server dell’ospedale vietnamita attraverso webshell piazzate su un’interfaccia di gestione Java esposta su Internet.

TriBack Loader: un unico loader, quattro varianti

Al centro della tradecraft c’è un loader Windows che Group-IB battezza TriBack Loader, mai documentato in precedenza. Compare in quattro catene di infezione, tutte costruite attorno al DLL sideloading: un eseguibile legittimo firmato viene abbinato a una DLL malevola e a un payload cifrato in formato .dat o .log.

La DLL inverte i byte del payload, li decifra con XOR a chiave rotante, ed esegue lo shellcode tramite chiamate Win32 che gli EDR monitorano meno rispetto alla classica CreateThread. Le quattro varianti si differenziano proprio nella chiamata finale usata per l’esecuzione: due si affidano a InitOnceExecuteOnce e a un callback TimerQueue, una terza sfrutta EtwpCreateEtwThread, una routine non documentata di ntdll per la creazione di thread. Anche il binario firmato ospite cambia da variante a variante. Per i ricercatori, la ripetizione sistematica della stessa sequenza di API suggerisce l’esistenza di un builder automatizzato per la generazione del loader.

Due varianti distribuiscono AdaptixC2, framework open source di post-exploitation già osservato in altre campagne ransomware. Una terza variante, particolarmente insidiosa, si maschera da software Claude: usa DonutLoader per eseguire Beagle, una backdoor documentata per la prima volta da Sophos. La quarta variante resta un mistero: il file cifrato che ne conteneva il payload non è mai stato recuperato.

L’esca perfetta: un finto Claude con MSI malevolo

Uno degli aspetti più rilevanti per un pubblico di professionisti è la campagna di impersonificazione del software Anthropic. Il dominio claude-pro[.]com, registrato il 28 marzo 2026, ha distribuito un installer MSI malevolo che, superato un prompt UAC, posizionava la catena di sideloading nella cartella di avvio di Windows per garantirsi la persistenza. La backdoor Beagle consegnata da questa variante comunicava con license[.]claude-pro[.]com come infrastruttura di comando e controllo.

Sophos, lavorando a partire dal sito fasullo, dalla sua infrastruttura di hosting e dai campioni di malware raccolti, ha rilevato la stessa chiave XOR riutilizzata in build risalenti a febbraio 2026, ma ha specificato che una chiave condivisa non basta da sola a confermare un singolo attore dietro tutte le campagne: nell’ecosistema China-nexus gli strumenti circolano liberamente tra gruppi diversi. Lo stesso approccio prudente vale per Group-IB, che raggruppa le intrusioni asiatiche sotto l’etichetta JadeProx senza attribuirle in modo definitivo a un gruppo APT già catalogato.

Se la valutazione di Sophos è corretta e il sito fasullo faceva parte di una campagna di malvertising attiva, l’esposizione va ben oltre ministeri e ospedali: raggiunge chiunque, nel mondo, stesse semplicemente cercando di scaricare Claude.

Vulnerabilità vecchie di anni per colpire infrastrutture nuove

Sul fronte dello scanning contro l’istruzione di Hong Kong, gli operatori hanno lanciato Nuclei con template a severità critica contro una lista di 14.653 URL legati al settore educativo, individuando 13 vulnerabilità uniche. Il report non specifica quanti tentativi di sfruttamento successivi abbiano avuto successo, ma indica quattro CVE specifiche tentate contro singoli host, tutte con punteggio CVSS 9.8: CVE-2018-11511 (ASUSTOR ADM), CVE-2021-24139 (plugin WordPress 10Web Photo Gallery), CVE-2021-31755 (router Tenda AC11) e CVE-2021-32305 (WebSVN).

Il dettaglio interessante per i difensori è che la falla su Tenda AC11 è nel catalogo KEV (Known Exploited Vulnerabilities) di CISA dal 3 novembre 2021, con una scadenza di remediation federale spirata appena due settimane dopo. In altre parole: la parte “artigianale” e sofisticata di questa operazione — loader custom, sideloading, ETW abuse — si appoggia a un ingresso iniziale banale, fatto di CVE pubbliche e non patchate da anni. L’ingegneria del loader conta poco se la porta d’ingresso resta aperta dal 2021.

Cosa monitorare

Group-IB e i ricercatori coinvolti raccomandano di concentrare il rilevamento sulla catena di sideloading piuttosto che sui singoli indicatori di rete, dato che nomi file e host firmati cambiano a ogni build:

• Segnalare binari vendor firmati eseguiti da directory scrivibili dall’utente, temporanee o dalla cartella Startup, specialmente in presenza di file .dat o .log cifrati nella stessa cartella.
• Cercare copie sospette di hostfxr.dll, avk.dll o MpClient.dll, insieme a cartelle annidate del tipo _CL_###### e allo script ~del.vbs.bat.
• Bloccare o investigare i domini del cluster: claude-pro[.]com, license[.]claude-pro[.]com, sylverixstrategy[.]com, gouvvbo[.]top, vertextrust-advisors[.]com, e tre domini civetta che imitano vendor di sicurezza condividendo lo stesso IP — update-trellix[.]com, update-crowdstrike[.]com, update-sentinelone[.]com.
• Dare priorità alle applicazioni Java esposte su Internet, quindi a qualsiasi sistema pubblico con una falla non patchata di severità 9.8, incluse le quattro citate.

Indicatori di compromissione

Domini:
claude-pro[.]com (registrato 28/03/2026)
license[.]claude-pro[.]com
sylverixstrategy[.]com
gouvvbo[.]top
vertextrust-advisors[.]com
update-trellix[.]com
update-crowdstrike[.]com
update-sentinelone[.]com

Infrastruttura di staging:
43.106.71[.]28:8000

CVE sfruttate (CVSS 9.8):
CVE-2018-11511 - ASUSTOR ADM
CVE-2021-24139 - 10Web Photo Gallery (WordPress)
CVE-2021-31755 - Tenda AC11 (KEV CISA dal 03/11/2021)
CVE-2021-32305 - WebSVN

Artefatti su disco:
hostfxr.dll / avk.dll / MpClient.dll (copie sospette)
_CL_###### (cartelle annidate)
~del.vbs.bat

Malware associato:
TriBack Loader (loader custom, DLL sideloading)
AdaptixC2 (post-exploitation open source)
DonutLoader -> Beagle backdoor

Fonti: report Group-IB, The Hacker News, Sophos.

JadeProx: Tracing a China-nexus Operation Through an OPSEC Mistake

During ongoing monitoring of malicious infrastructure, Group-IB identified an exposed staging server that uncovered an active China-nexus operation.

^{Sathwik Ram Prakki (Group-IB)}

Kevin Beaumont

2026-07-27 13:47:38

Google search:

site:claude.ai/public

Coming soon to
claude.ai/robots.txt

/share was full of chats but they added it to robots.txt

Spcnet.it

2026-07-27 10:13:44

PHP-FPM: perché pm static batte dynamic e ondemand sui server ad alto traffico

Il process manager sbagliato è spesso il vero collo di bottiglia di PHP

Quando un’applicazione PHP inizia a rallentare sotto traffico reale, la prima cosa che si tende a ottimizzare è il codice: query più efficienti, cache applicativa, opcache. Tutte cose giuste, ma c’è un parametro a monte che viene sistematicamente sottovalutato e che, su un server con traffico costante, può pesare quanto tutto il resto messo insieme: il process manager (PM) di PHP-FPM.

La quasi totalità delle installazioni lascia pm impostato su dynamic, il valore di default, oppure viene consigliato di passare a ondemand quando la memoria disponibile è scarsa. Per un server che riceve traffico costante e prevedibile, però, esiste una terza opzione quasi sempre trascurata: pm = static. In questo articolo vediamo perché, come calcolare i parametri corretti e in quali scenari conviene davvero.

Le tre modalità del process manager

PHP-FPM gestisce un pool di processi worker che eseguono lo script PHP per ogni richiesta. Il parametro pm nel file di configurazione del pool decide come questi worker vengono creati e distrutti nel tempo:

• dynamic: il numero di processi figli varia dinamicamente in base a pm.max_children, pm.start_servers, pm.min_spare_servers e pm.max_spare_servers. All’avvio del servizio vengono lanciati pm.start_servers worker, poi il pool si espande e si contrae seguendo il carico.
• ondemand: i processi vengono avviati solo quando arriva una richiesta, invece di essere già pronti all’avvio del servizio come accade con dynamic. Ottimo per il risparmio di memoria, meno per la latenza sul primo hit.
• static: il numero di processi figli è fisso, determinato unicamente da pm.max_children. Nessuna logica di scaling: i worker vengono creati all’avvio e restano attivi.

La documentazione ufficiale di PHP elenca tutte le direttive globali di php-fpm.conf, ma la scelta tra queste tre modalità è più una questione di architettura del server che di singola direttiva.

Un parallelo utile: il governor della CPU

Chiunque abbia mai armeggiato con le impostazioni di risparmio energetico della CPU (CPUFreq governor, presenti sia su *nix che su Windows) riconoscerà lo stesso identico compromesso:

• ondemand: scala la frequenza dinamicamente in base al carico corrente, saltando rapidamente alla frequenza massima per poi scendere durante i periodi di inattività.
• conservative: scala la frequenza in modo più graduale rispetto a ondemand.
• performance: mantiene sempre la CPU alla frequenza massima.

Il compromesso è lo stesso che si ritrova in PHP-FPM: un’impostazione privilegia la reattività immediata, le altre il risparmio di risorse durante i periodi di inattività. Con il governor performance, i core mantengono la frequenza massima invece di scalare verso il basso in idle: è un boost di prestazioni relativamente sicuro, il cui costo dipende quasi solo dai limiti termici della CPU. Lo stesso principio, applicato ai processi PHP-FPM invece che ai cicli di clock, è ciò che rende pm = static efficace su un server sotto carico costante.

Usare pm static per il massimo delle prestazioni

L’impostazione pm = static dipende fortemente dalla memoria libera disponibile sul server. Se la memoria è scarsa, ondemand o dynamic restano scelte più sicure. Se invece la memoria è disponibile, static elimina gran parte dell’overhead di gestione del pool impostando il numero di worker al massimo che il server può sostenere.

In pratica, pm.max_children con static va calcolato come il numero massimo di processi PHP-FPM che possono girare senza generare pressione sulla memoria disponibile o sulla cache del sistema, e senza saturare le CPU con una coda di operazioni PHP-FPM in attesa.

Un caso reale: un server con 32 GB di RAM installata, pm = static e pm.max_children = 100, usa un massimo di circa 10 GB. Anche con circa 200 utenti attivi negli ultimi 60 secondi (dato preso da Google Analytics), circa il 70% dei worker PHP-FPM resta idle. Questo è precisamente il punto: PHP-FPM lavora sempre alla capacità massima configurata, indipendentemente dal traffico istantaneo, e i worker idle restano pronti a rispondere immediatamente ai picchi di traffico invece di dover attendere che il process manager ne generi di nuovi (e poi li termini dopo che pm.process_idle_timeout scade).

Calcolare pm.max_children, non indovinarlo

Il passaggio più importante, spesso saltato, è misurare invece di stimare a occhio. Prima si misura la dimensione media residente (RSS) di un worker PHP-FPM sotto carico reale:

ps --no-headers -o rss -C php-fpm | awk '{ sum += $1; n++ } END { print sum/n/1024 " MB" }'

A questo punto si divide la memoria che si è disposti a dedicare a PHP-FPM per questo valore medio. Se un worker occupa in media 60 MB e si vogliono allocare 6 GB a PHP-FPM, il calcolo è circa pm.max_children = 100 (6144 / 60). È fondamentale lasciare margine per il sistema operativo, il web server e il database: non va mai assegnata a PHP-FPM tutta la RAM fisica disponibile.

Da qui si procede per iterazioni: si testa sotto carico reale e si affina il valore osservando uso di memoria, utilizzo CPU e tempi di risposta. Con pm = static, poiché i worker restano già residenti in memoria, i picchi di traffico si traducono in picchi di carico e CPU molto più contenuti, e le medie restano più stabili nel tempo.

Per monitorare i processi attivi in tempo reale si può usare top filtrato per utente:

top -bn1 | grep php-fpm

Impostando anche pm.max_requests a un valore alto (o a 0 per disabilitare il riavvio periodico dei worker) si evita ulteriore overhead di gestione, ma questa scelta ha senso solo su un server di produzione senza memory leak noti negli script PHP. In generale conviene comunque impostare un valore alto ma finito, ad esempio pm.max_requests = 1000, per garantire un riavvio periodico dei worker senza reintrodurre overhead significativo.

Quando usare ondemand e dynamic invece di static

Con pm = dynamic capita spesso di incontrare un warning simile a questo nei log:

WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers,
or pm.min/max_spare_servers), spawning 32 children, there are 4 idle,
and 59 total children

Il consiglio più comune, in questi casi, è passare a ondemand. Su un server costantemente sotto carico, però, questa scelta si ritorce contro: ondemand azzera i worker idle appena il traffico cala, per poi doverli rigenerare non appena il traffico torna a salire, scambiando risparmio di memoria con latenza di spawn esattamente nel momento peggiore. Un timeout di idle molto alto attenua il problema, ma a quel punto conviene semplicemente passare a pm.static con un pm.max_requests elevato.

dynamic e soprattutto ondemand restano invece la scelta giusta in scenari con molti pool PHP-FPM distinti sullo stesso server, ad esempio hosting condiviso con centinaia di account cPanel o siti diversi ciascuno con il proprio pool. In un ambiente con 100+ pool e 200+ domini, dove la maggior parte dei siti riceve pochissimo traffico, static o dynamic sprecherebbero enormi quantità di memoria su worker perennemente idle: ondemand chiude i worker inattivi liberando memoria, motivo per cui è diventato il default in ambienti come cPanel.

Un cenno ai container

Lo stesso ragionamento va adattato quando PHP-FPM gira dentro un container con risorse limitate (ad esempio 0.5 vCPU e 1 GB di RAM) e la scalabilità è orizzontale, tramite orchestrazione (Docker Swarm, Kubernetes). In questi contesti pm.static resta spesso l’unica scelta sensata a livello di singolo container, ma la decisione su quando far partire un nuovo container non può basarsi solo su CPU e memoria: va monitorato anche il numero di processi PHP-FPM attivi rispetto a pm.max_children. Se il pool ha 50 worker configurati e 40 sono già occupati, è il momento di avviare un nuovo container, indipendentemente da quanto CPU e RAM stiano effettivamente segnalando in quel momento. Questo richiede di esporre lo stato di php-fpm status al sistema di autoscaling, valutato a intervalli brevi.

Conclusione

Superata una certa soglia di traffico costante, ondemand e dynamic introducono un overhead di gestione dei processi che una configurazione static ben calcolata elimina alla radice. La regola pratica è semplice da enunciare ma richiede disciplina nell’applicarla: non indovinare pm.max_children, misurarlo a partire dal consumo medio di RSS dei worker sotto carico reale, lasciare margine per OS, web server e database, e poi affinare osservando le metriche reali. Su un server dedicato o una VM con traffico prevedibile, il guadagno in stabilità di CPU e tempi di risposta è concreto. Su hosting condiviso con centinaia di pool a bassissimo traffico, ondemand resta la scelta più razionale. Conoscere il proprio sistema, prima ancora del proprio codice PHP, è ciò che fa la differenza.

Fonte: PHP-FPM tuning: Using ‘pm static’ for max performance, LinuxBlog.io (Hayden James)

PHP-FPM tuning: Using 'pm static' for max performance | LinuxBlog.io

Let's take a quick look at how best to set up PHP-FPM for high throughput, low latency, and more stable CPU and memory use. By default, most setups have

^{Hayden James (LinuxBlog.io)}

Spcnet.it

2026-07-27 10:17:02

Nmap su Linux: la guida pratica a scanning e discovery di rete per sistemisti

Chi amministra server Linux prima o poi si trova a dover rispondere a una domanda apparentemente semplice: “cosa è realmente esposto su questa macchina, e su questa rete?” La risposta corretta non arriva mai da un elenco di regole firewall letto a memoria, ma da una verifica attiva. Nmap (Network Mapper) resta lo strumento di riferimento per questo tipo di verifica: open source, nato nel 1997, ancora oggi il punto di partenza per audit di sicurezza, mappatura di reti e troubleshooting di connettività.

In questo articolo vediamo un percorso pratico per usare nmap in scenari reali di amministrazione sistemi: dalla discovery degli host alla scansione delle porte, fino agli script NSE per individuare vulnerabilità e configurazioni deboli.

Nota importante: esegui scansioni solo su reti e host di tua proprietà o per cui hai autorizzazione esplicita. La scansione non autorizzata può costituire reato in molte giurisdizioni, Italia compresa (accesso abusivo a sistema informatico, art. 615-ter c.p.).

Installazione

Nmap è disponibile nei repository di tutte le distribuzioni principali:

# Debian/Ubuntu
sudo apt install nmap

# Fedora/RHEL/CentOS
sudo dnf install nmap

# Arch/Manjaro
sudo pacman -S nmap

# Verifica
nmap --version

Host discovery: chi è vivo sulla rete

Il primo passo in qualsiasi audit è capire quali host rispondono. Per questo si usa la scansione “ping”, che salta completamente il controllo delle porte:

nmap -sn 192.168.1.0/24

Su una rete locale nmap non si limita all’ICMP: usa il protocollo ARP, molto più veloce e capace di scovare anche dispositivi che ignorano i normali ping. Su reti instradate, invece, combina richieste ICMP echo, TCP SYN sulla porta 443, TCP ACK sulla porta 80 e timestamp ICMP. Il risultato è un inventario rapido e silenzioso di ciò che è realmente connesso, utile ad esempio quando serve scoprire quale indirizzo IP il DHCP ha assegnato a un nuovo dispositivo.

Scansione delle porte

Una volta identificati gli host attivi, il passo successivo è capire quali servizi espongono. Senza opzioni, nmap scansiona le 1.000 porte TCP più comuni e non richiede privilegi root:

nmap 192.168.1.10

Da root, il tipo di scansione predefinito diventa la SYN scan (o “stealth scan”), più veloce perché non completa mai l’handshake TCP a tre vie e lascia meno tracce nei log applicativi:

sudo nmap -sS 192.168.1.10

Le 1.000 porte di default lasciano fuori parecchio. Un’istanza MySQL su una porta non standard, o un demone SSH spostato sulla 2222, restano invisibili. Per una copertura completa:

sudo nmap -sS -p- 192.168.1.10   # tutte le 65.535 porte
sudo nmap -p 22,80,443,3306 192.168.1.10   # porte specifiche
sudo nmap -p 1-1024 192.168.1.10   # un intervallo

Va tenuto d’occhio anche l’UDP, spesso trascurato ma sede di servizi critici come DNS (53), SNMP (161) e NTP (123):

sudo nmap -sU -p 53,161,123 192.168.1.1

Le scansioni UDP sono più lente perché una porta chiusa non sempre genera una risposta esplicita: conviene limitare l’intervallo di porte o armarsi di pazienza.

Version detection e OS fingerprinting

Sapere che la porta 22 è aperta è utile. Sapere che dietro c’è OpenSSH 8.9p1 lo è molto di più, soprattutto per intercettare versioni obsolete durante un audit di sicurezza:

sudo nmap -sV 192.168.1.10

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.6
80/tcp   open  http    nginx 1.24.0
3306/tcp open  mysql   MySQL 8.0.35

Con --version-intensity (da 0 a 9, default 7) si regola quanto nmap insiste nel probing: abbassarlo a 2-3 velocizza la scansione senza perdere molta precisione sui servizi comuni.

Per un’ipotesi sul sistema operativo, tramite fingerprinting dello stack TCP/IP, serve almeno una porta aperta e una chiusa:

sudo nmap -O 192.168.1.10

Su macchine virtuali o stack TCP personalizzati la stima può essere imprecisa, ma resta un segnale utile per separare rapidamente server Linux, macchine Windows e dispositivi embedded su uno stesso segmento di rete.

Per un quadro completo in un colpo solo (OS detection, version detection, script scanning e traceroute) c’è la scansione aggressiva:

sudo nmap -A 192.168.1.10

Genera molto traffico: da evitare su reti di produzione senza una finestra di manutenzione concordata.

Nmap Scripting Engine (NSE): oltre il semplice port scan

La vera potenza di nmap emerge con NSE, il motore di scripting che esegue controlli automatizzati sugli host scoperti: dalla ricerca di vulnerabilità note alla verifica di configurazioni deboli. Gli script risiedono in /usr/share/nmap/scripts/ e sono organizzati in categorie (default, auth, vuln, discovery, intrusive, safe).

# Vulnerabilità note (categoria più invasiva, usarla con criterio)
sudo nmap --script=vuln 192.168.1.10

# Accesso FTP anonimo
sudo nmap --script=ftp-anon -p 21 192.168.1.10

# Header HTTP (spesso rivelano versioni software o debug info)
sudo nmap --script=http-headers -p 80,443 192.168.1.10

# Open relay SMTP
sudo nmap --script=smtp-open-relay -p 25 192.168.1.20

Un controllo rapido su porta 80/443 con http-headers capita spesso di far emergere header con versioni software esposte inutilmente: una correzione da cinque minuti che chiude una falla di information disclosure.

Output e automazione

Per qualsiasi verifica che vada oltre il controllo estemporaneo, conviene salvare i risultati:

sudo nmap -sV 192.168.1.0/24 -oA scan_results

Il flag -oA genera contemporaneamente output normale (.nmap), XML (.xml, utile per l’integrazione con altri strumenti e dashboard) e formato “grepable” (.gnmap), comodo per il parsing rapido da shell.

Combinazioni utili nel lavoro quotidiano

# Solo porte effettivamente aperte, timing aggressivo su rete affidabile
sudo nmap -sS -T4 --open 192.168.1.10

# Tutti i server SSH su una subnet
sudo nmap -p 22 --open -sV 192.168.1.0/24

# Verifica che MySQL non sia esposto inutilmente
sudo nmap -p 3306 --open 192.168.1.0/24

# Discovery + version scan solo sugli host realmente attivi
sudo nmap -sn 192.168.1.0/24 -oG - | grep "Up" | awk '{print $2}' | sudo nmap -sV -iL -

MySQL esposto senza motivo è uno degli errori di configurazione più comuni e più pericolosi: una scansione mirata come quella sopra richiede due secondi e può intercettare il problema prima che lo trovi qualcun altro.

Nmap ha inoltre sei template di timing, da T0 (paranoico, lentissimo) a T5 (aggressivo): T3 è il default bilanciato, T4 va bene su reti locali affidabili, mentre su VPN o collegamenti lenti conviene scendere a T2 per evitare falsi negativi dovuti a pacchetti persi.

Porte filtrate: un segnale, non un fastidio

Nmap distingue tre stati: open, closed e filtered. Quest’ultimo indica che un firewall o un packet filter sta bloccando silenziosamente la sonda. Se compaiono molte porte filtrate su un server che non ti aspetti sia protetto da firewall, vale la pena indagare: potrebbe essere ufw, firewalld, un ruleset nftables o un security group del provider cloud. In ogni caso, è un’indicazione da non ignorare, e lo stesso principio vale per i probe di version detection e OS fingerprinting, che un firewall può alterare o azzerare.

Conclusione

Nmap non si impara in un pomeriggio, ma i comandi visti coprono la maggior parte del lavoro quotidiano di un sistemista: discovery degli host, scansione delle porte, identificazione di servizi e versioni, script NSE per approfondire, e output strutturato per automazione o revisione successiva. La sequenza tipica è semplice: si parte con -sn per la discovery, si aggiunge -sV quando servono i dettagli sui servizi, e si porta NSE in campo quando serve scavare più a fondo. Timing prudente in produzione, aggressivo nel proprio lab: è una distinzione che vale la pena interiorizzare prima di lanciare la prima scansione su un ambiente che non si controlla del tutto.

Fonte originale: Hayden James, “nmap on Linux: Guide to Network Scanning and Discovery”, LinuxBlog.io.

nmap on Linux: Guide to Network Scanning and Discovery | LinuxBlog.io

A practical guide to nmap on Linux covering host discovery, port and service scanning, OS detection, NSE scripts, output formats, and real-world command combinations sysadmins actually use.

^{Hayden James (LinuxBlog.io)}