slowforward

2026-03-30 06:31:08

esce “scritture complesse”, raccolta di testi relativi all’omonimo incontro di parma (dicembre, 2023)

[dia•foria // scritture complesse
diaforia.org/floema/2026/03/16…

Nel volume:

Andrea Borghi
DISCOMATERIA
Alessandro De Francesco
FLUSSO DI COSCIENZA INVERSO E CONOSCENZA SENZA COMPRENSIONE
Giovanni Fontana
SCRITTURE COMPLESSE
Marco Giovenale
UNA MACCHINA DI EFFETTI
Elvio Manganaro
LES ANNÉES COMBINATOIRES
Salvatore Margiotta/ Phoebe Zeitgeist
PHOEBE ZEITGEIST/SCRITTURE COMPLESSE
Nicolas Martino
L’ALFABETO HA FATTO BANG
Marco Mazzi
NIHIL
Susanna Pisciella
LETTURA CARTOGRAFICA, SCRITTURA DI PROGETTO
Daniele Poletti
IL SUPERAMENTO DELL’APPARTENENZA
Franco Purini
TRE RIFERIMENTI
Luigi Severi
MILLEPIANI DI SCRITTURA ESLEGE

Il lavoro grafico e di impaginazione è stato eseguito da FELIPE EMILIO PSZEMIAROWER e RUZANNA MELIKSETYAN, con la supervisione di [dia•foria.

Formato: 16×30 cm
Pagine: 152
a cura di Daniele Poletti e Elvio Maganaro
[dia•foria, febbraio 2026
collana: floema – esplorazioni della parola

per info e acquisti: info@diaforia.org
#AlessandroDeFrancesco #AndreaBorghi #DanielePoletti #diaforia #ElvioManganaro #FelipeEmilioPszemiarower #Floema #floemaEsplorazioniDellaParola #FrancoPurini #GiovanniFontana #LuigiSeveri #MarcoGiovenale #MarcoMazzi #NicolasMartino #PhoebeZeitgeist #RuzannaMelikesetyan #SalvatoreMargiotta #SusannaPisciella #DiaForia

SCRITTURE COMPLESSE (Parma 2023)

^{floema (www.diaforia.org)}

(in)sicurezza digitale

2026-06-22 16:57:54

AryStinger: la botnet che trasforma router D-Link in armi silenziose per attacchi globali

I ricercatori di XLab (Qianxin) hanno scoperto AryStinger, una botnet precedentemente sconosciuta che ha compromesso oltre 4.000 router obsoleti in tutto il mondo, trasformandoli in proxy silenziosi al servizio di attori malevoli. A differenza delle classiche botnet DDoS, AryStinger è progettata per il ricognizione e il supporto alle intrusioni — un’infrastruttura invisibile concepita per penetrare reti aziendali e governative.

Scoperta e timeline dell’operazione

Il 12 marzo 2026, il sistema di threat awareness di XLab ha rilevato l’indirizzo IP 107.150.106.14 che diffondeva un campione ELF con zero detection su VirusTotal, sfruttando due vulnerabilità datate: CVE-2013-3307 e CVE-2016-5681. Il campione, implementato in C, prendeva di mira router D-Link DIR-850L e DIR-818LW — dispositivi giunti a fine vita, privi di patch e ancora ampiamente diffusi in ambito SOHO.

Il 26 aprile è comparso un secondo campione correlato, questa volta scritto in Go e rivolto a dispositivi NAS, sfruttando CVE-2025-11837. Il percorso nel codice sorgente del campione Go rivela il nome del progetto interno: Ary-Attack — un dettaglio che ha consentito ai ricercatori di attribuire le due famiglie alla stessa operazione.

Architettura e capacità operative

AryStinger converte i dispositivi infetti in “executor” telecomandati, capaci di eseguire un insieme ricco di operazioni su richiesta del C2:

• Scansione di rete: port scanning, identificazione dei servizi, enumerazione di sottodomini — attività tipiche della fase di ricognizione pre-intrusione.
• Proxying e tunneling: il device infetto instrada traffico malevolo verso destinazioni terze, mascherando l’origine reale dell’attaccante.
• Esecuzione di comandi arbitrari sul sistema.
• Modifiche DNS: la botnet può alterare le configurazioni DNS del router per intercettare il traffico web degli utenti connessi.
• Payload multi-linguaggio: supporta l’iniezione di payload scritti in Go, Java e Python, garantendo flessibilità operativa.
• Canali di accesso persistente via dropbear (SSH) o gs-netcat.

Le comunicazioni con il server di comando e controllo avvengono via HTTP/HTTPS, con traffico serializzato tramite Protobuf e cifrato con XOR — una scelta che garantisce compattezza e una certa difficoltà nell’ispezione del traffico.

Distribuzione geografica e target

La telemetria di Qianxin mostra che la distribuzione delle infezioni è geograficamente concentrata: Corea del Sud (48,5%), Cina (31,8%), Svezia (6,4%), Malesia (3,5%) e Singapore (2,5%). La forte prevalenza asiatica suggerisce che il deployment iniziale sia stato mirato su mercati dove i router D-Link di fascia bassa hanno avuto larga diffusione e dove la sostituzione dei dispositivi a fine vita avviene con ritardi.

Il targeting di NAS oltre ai router nella seconda fase dell’operazione indica un’evoluzione verso dispositivi con maggiore capacità di elaborazione e connettività persistente — ideali per operazioni di lunga durata che richiedono stabilità dell’infrastruttura proxy.

Perché AryStinger è diversa dalle botnet tradizionali

La distinzione fondamentale di AryStinger rispetto a botnet come Mirai o AISURU è l’obiettivo operativo: non DDoS né mining di criptovalute, bensì la costruzione di un’infrastruttura di intrusione distribuita. I dispositivi compromessi diventano nodi di una rete di proxy residenziali che conferiscono agli attaccanti un’anonimizzazione difficile da penetrare: il traffico malevolo emerge da indirizzi IP domestici o di piccola impresa, superando spesso i blocchi basati su reputazione IP.

Questo modello operativo è tipico di gruppi APT che necessitano di infrastrutture di staging durante la fase di ricognizione e di pivoting nelle reti bersaglio. La capacità di modificare le configurazioni DNS aggiunge una dimensione ulteriore: chi usa un router infetto espone tutte le proprie comunicazioni a potenziale intercettazione.

Indicatori di compromissione (IoC)

# IP di spreading iniziale
107.150.106.14
# Dominio C2 autenticazione
eixfi.ajb8.com  (/auth endpoint)
# CVE sfruttate
CVE-2013-3307   (D-Link DIR-850L - autenticazione bypassata)
CVE-2016-5681   (D-Link DIR-818LW - esecuzione remota di codice)
CVE-2025-11837  (dispositivi NAS - variante Go)
# Processi sospetti da verificare sul dispositivo
syswapd0h
syswapd0w
# Percorso da verificare
/tmp/bin/  (presenza di campioni malware)
# Nome progetto interno (da path nel codice Go)
Ary-Attack

Due righe per i difensori

Per chi gestisce reti con dispositivi edge, le azioni prioritarie sono: sostituire immediatamente i router D-Link DIR-850L e DIR-818LW con modelli supportati e aggiornati; applicare gli aggiornamenti firmware più recenti su tutti i dispositivi di rete perimetrali; modificare le credenziali amministrative di default; disabilitare le interfacce di gestione remota se non strettamente necessarie. A livello di monitoraggio, è opportuno inserire il dominio eixfi.ajb8.com e l’IP 107.150.106.14 nelle blocklist e verificare nei log di rete la presenza di connessioni Protobuf verso host sconosciuti su porte non standard.

La scoperta di AryStinger conferma una tendenza consolidata: i dispositivi IoT e i router SOHO a fine vita restano un vettore di attacco privilegiato per costruire infrastrutture di intrusione persistenti e difficili da attribuire. La prossima botnet potrebbe già essere nascosta nel router del vostro operatore ISP locale.

Spcnet.it

2026-06-22 17:03:03

Troubleshooting su Linux: il metodo sistematico in 4 passi che risolve il 99% degli errori

Chi lavora con Linux da anni conosce bene quella sensazione: un errore inaspettato blocca il server, un servizio smette di rispondere, un sistema che ieri funzionava perfettamente oggi presenta comportamenti anomali. La differenza tra un amministratore di sistema esperto e uno alle prime armi non sta tanto nella conoscenza enciclopedica dei comandi, quanto nell’adozione di un metodo sistematico di analisi.

In questo articolo descriviamo un approccio in quattro passi che consente di affrontare con metodo qualsiasi errore su Linux, riducendo drasticamente i tempi di risoluzione e gli errori per tentativi.

Il principio fondamentale: metodo prima di tutto

Il troubleshooting efficace non è una questione di fortuna o di esperienza accumulata a caso. È una disciplina che richiede di rallentare, osservare e procedere un passo alla volta. La tentazione più comune è quella di applicare subito la prima soluzione trovata online, modificando più variabili contemporaneamente. Questo approccio porta quasi sempre a peggiorare la situazione o, nella migliore delle ipotesi, a non capire quale modifica ha effettivamente risolto il problema.

Passo 1: raccogliere indizi e definire il problema con precisione

Il punto di partenza è una definizione precisa del problema. “Il server non funziona” è inutile ai fini diagnostici. “Il web server restituisce un 503 su /api/users dopo il deploy delle 14:30″ è un punto di partenza solido.

Le domande da porsi immediatamente sono:

• Quando si è manifestato il problema per la prima volta?
• Cosa è cambiato recentemente? (aggiornamento pacchetti, modifica configurazione, riavvio)
• Il problema è riproducibile? In quali condizioni?
• Qual è esattamente il messaggio di errore?

Un consiglio pratico spesso sottovalutato: se un’applicazione non si avvia correttamente, chiudete l’interfaccia grafica e lanciatela da terminale. La maggior parte delle applicazioni stampa i messaggi di errore sullo standard output o standard error, fornendo clue preziosi che l’interfaccia nasconde.

Catturate sempre l’output esatto dell’errore. Un kernel panic al boot, un prompt GRUB rescue, o un messaggio “device not found” contengono già le informazioni necessarie per risolvere il problema.

Passo 2: analizzare lo stato del sistema e i log

Con il problema definito, è il momento di esaminare lo stato corrente del sistema. Questa fase si divide in due parti: lo stato delle risorse e l’analisi dei log.

Stato delle risorse

Verificate se CPU, memoria, disco e rete sono in condizioni normali:

# CPU e memoria
top
htop

# Spazio disco
df -h
du -sh /var/log/* | sort -rh | head -20

# Rete
ip a
ip route
ping -c 4 8.8.8.8


Analisi dei log

Linux mette a disposizione strumenti potenti per l’analisi dei log. Con systemd, il comando principale è journalctl:

# Log del boot corrente con dettagli errori
journalctl -xb

# Log di un servizio specifico (es. nginx)
journalctl -u nginx --since "1 hour ago"

# Seguire i log in tempo reale
journalctl -f

# Filtrare solo gli errori
journalctl -p err -b


Per i sistemi che usano ancora i log tradizionali:

# Syslog generale
grep -i error /var/log/syslog | tail -50

# Log kernel
dmesg | grep -i "error\|fail\|warn" | tail -30

# Ricerca per intervallo temporale
journalctl --since "2026-06-22 14:00" --until "2026-06-22 15:00"


Non è necessario comprendere ogni singola riga dei log. L’obiettivo è identificare parole chiave come error, failed, segfault, permission denied, o il nome del servizio problematico nelle righe temporalmente vicine all’evento.

Passo 3: formulare ipotesi e testare una variabile alla volta

Con i dati raccolti nei passi precedenti, è il momento dell’analisi. Basandosi sui sintomi, sui cambiamenti recenti e sui log, si formula un’ipotesi sulla causa del problema.

Alcune regole pratiche:

• Un segmentation fault → sospettare corruzione della memoria o libreria incompatibile
• “Permission denied” → verificare permessi file, SELinux/AppArmor, ACL
• “Device not found” al boot → UUID del disco modificato dopo aggiornamento o sostituzione
• Servizio che crasha dopo un aggiornamento → provare il rollback del pacchetto

La regola d’oro è modificare una variabile alla volta. Se sospettate che un aggiornamento del pacchetto abbia causato il problema, fate il downgrade su un sistema di test prima di applicarlo in produzione. Questo permette di isolare la causa con certezza.

# Rollback di un pacchetto su Debian/Ubuntu
apt-cache showpkg nginx
apt-get install nginx=1.24.0-2

# Su RHEL/Rocky Linux
dnf downgrade nginx

# Verificare i file di configurazione con sintassi check
nginx -t
systemd-analyze verify /etc/systemd/system/myservice.service


La ricerca online è un validissimo alleato: incollare il messaggio di errore esatto in un motore di ricerca, nella documentazione ufficiale della distro, o in un AI assistant porta quasi sempre a soluzioni già documentate.

Passo 4: applicare la correzione e documentare

Una volta identificata la causa, applicare la correzione in modo controllato. Per le modifiche più invasive (sostituzione hardware, rebuild dell’initramfs, cambio configurazione kernel), è fondamentale:

• Eseguire uno snapshot del sistema prima di procedere
• Procedere un passo alla volta
• Verificare dopo ogni modifica che il problema sia risolto e che nulla si sia rotto

Il passo finale, spesso trascurato, è la documentazione. Annotare cosa è andato storto, quali log hanno fornito i clue decisivi, e come è stato risolto il problema. Un ticket nel sistema di ticketing, un post nel blog interno, o anche una semplice nota in un file di testo possono fare la differenza quando lo stesso problema si ripresenterà tra sei mesi.

Strumenti essenziali da padroneggiare

Per mettere in pratica questo metodo in modo efficace, vale la pena avere familiarità con questi strumenti:

# Monitoraggio risorse
htop, btop, atop, glances

# Analisi disco e I/O
iotop, iostat, lsblk, blkid, smartctl -a /dev/sda

# Rete
ss -tlnp, netstat -tlnp, tcpdump, traceroute, mtr

# File di sistema
strace -p , lsof -i, inotifywait

# Analisi log avanzata
grep, awk, sed, logwatch, fail2ban-client status

Conclusione

Il troubleshooting su Linux non è magia: è l’applicazione di un metodo. Raccogliere i dati, analizzare i log, formulare ipotesi e testarle una alla volta, applicare la correzione e documentare. Quattro passi che, se seguiti con disciplina, permettono di affrontare con sicurezza qualsiasi problema, dai più banali ai più complessi.

La vera competenza si costruisce nel tempo, attraverso l’accumulo di esperienze documentate. Ogni errore risolto correttamente è una voce nel vostro archivio personale di soluzioni.

---

Fonte originale: Linux Troubleshooting: These 4 Steps Will Fix 99% of Errors – LinuxBlog.io

Linux Troubleshooting: These 4 Steps Will Fix 99% of Errors | LinuxBlog.io

I’ll admit, I hesitated a bit before writing this post. The whole point of this linuxblog.io and linuxcommunity.io forum is to bring together like-minded

^{Hayden James (LinuxBlog.io)}