Reverse shell e bind shell: differenze e come difendersi

Reverse shell e bind shell sono due facce dello stesso obiettivo — ottenere una linea di comando su una macchina remota — ma si distinguono per un dettaglio che cambia tutto: la direzione in cui parte la connessione. Capire quella direzione non è un tecnicismo da manuale: è esattamente ciò che determina quale delle due funziona contro un’azienda protetta da firewall, e quindi cosa un difensore deve sorvegliare. È il motivo per cui, in un penetration test reale, una delle due è oggi molto più usata dell’altra.

In questa guida vediamo cosa sono le due tecniche, in cosa differiscono davvero, perché le reverse shell dominano gli attacchi moderni e — soprattutto — come si rilevano e si contrastano. Senza fornire strumenti operativi: l’obiettivo è capire il meccanismo per difendersi, non eseguirlo.

1. Cos’è una shell, in breve
2. Bind shell: l’attaccante si collega alla vittima
3. Reverse shell: è la vittima a collegarsi all’attaccante
4. Perché le reverse shell dominano
5. Come si rilevano e si contrastano
6. Il ruolo nel penetration test

Cos’è una shell, in breve

Una shell è l’interfaccia che permette di impartire comandi a un sistema operativo: il ponte tra chi scrive un comando e la macchina che lo esegue. Bash su Linux, PowerShell e il prompt dei comandi su Windows sono shell. Avere “una shell” su un sistema significa, in sostanza, poter eseguire comandi su quel sistema.

Nel contesto della sicurezza offensiva, l’obiettivo di molti attacchi è proprio ottenere una shell su una macchina remota — un accesso da riga di comando che consente di esplorare il sistema, muoversi nella rete e, nelle mani di un criminale, sottrarre dati. Reverse shell e bind shell sono i due modi in cui questo accesso remoto viene stabilito. La differenza sta tutta in chi avvia la connessione.

Bind shell: l’attaccante si collega alla vittima

Nella bind shell, la macchina bersaglio “mette in ascolto” una shell su una porta di rete e attende connessioni. L’attaccante, dal proprio sistema, si collega a quella porta e ottiene il controllo. In termini di ruoli di rete, è il bersaglio a fare da server (resta in attesa) e l’attaccante a fare da client (inizia la connessione verso il bersaglio).

Lo schema ha un punto debole evidente, ed è il motivo per cui oggi è poco efficace: richiede che la macchina bersaglio accetti connessioni in ingresso su quella porta. In qualsiasi rete aziendale moderna, i firewall bloccano per impostazione predefinita le connessioni in entrata non previste, e i sistemi dietro NAT non sono nemmeno raggiungibili direttamente dall’esterno. La bind shell, quindi, funziona bene in scenari limitati — reti interne già compromesse, ambienti senza filtri — ma si infrange contro le difese perimetrali standard.

Reverse shell: è la vittima a collegarsi all’attaccante

La reverse shell ribalta la direzione, ed è questa inversione a renderla la tecnica dominante. Qui è la macchina bersaglio a iniziare la connessione verso l’attaccante: è il sistema compromesso a “chiamare casa”, collegandosi a un server in ascolto controllato dall’attaccante. I ruoli di rete sono invertiti rispetto alla bind shell — il bersaglio fa da client, l’attaccante da server.

Il vantaggio per l’attaccante è enorme e tutto difensivo-evasivo: le connessioni in uscita sono quasi sempre permesse. Un firewall che blocca rigidamente ciò che entra lascia in genere passare ciò che esce, perché il traffico in uscita è quello legittimo degli utenti che navigano. Una reverse shell si traveste da normale connessione uscente — spesso verso porte usate dal traffico web, per confondersi ancora meglio — e attraversa indisturbata difese che avrebbero fermato una bind shell. È il motivo per cui, in un attacco reale come in una simulazione, la reverse shell è oggi lo standard.

Perché le reverse shell dominano

La ragione si riassume in un principio che ogni difensore dovrebbe avere chiaro: la maggior parte delle organizzazioni controlla con attenzione ciò che entra nella propria rete, e molto meno ciò che ne esce. Questo squilibrio è esattamente la leva della reverse shell. Finché il traffico in uscita non viene filtrato e ispezionato con lo stesso rigore di quello in entrata, una macchina compromessa avrà sempre una via per “chiamare” l’esterno.

Comprendere questo ribalta anche la strategia difensiva: difendersi dalle reverse shell non significa alzare altri muri all’ingresso, ma iniziare a sorvegliare le uscite.

Come si rilevano e si contrastano

Sul piano del rilevamento, la reverse shell lascia tracce a chi sa dove guardare. Una connessione in uscita da un server che normalmente non inizia connessioni, traffico verso indirizzi o porte inusuali, sessioni che restano aperte a lungo o si ripetono a intervalli regolari: sono anomalie che il monitoraggio del traffico in uscita e una soluzione di endpoint detection possono cogliere. La chiave è avere una linea di base di cosa è “normale” per ogni sistema, così che l’anomalia risalti.

Sul piano della prevenzione, le misure che contano sono strutturali. Il filtraggio del traffico in uscita (egress filtering) — consentire le connessioni uscenti solo verso destinazioni e porte legittime, invece di lasciarle aperte per impostazione predefinita — è la contromisura più diretta, e quella che la maggior parte delle reti trascura. La segmentazione della rete limita i danni: una macchina compromessa che non può raggiungere il resto dell’infrastruttura vale molto meno per un attaccante. E a monte di tutto resta la riduzione della superficie d’attacco — perché una shell, reverse o bind che sia, presuppone che l’attaccante sia riuscito prima a eseguire codice sul sistema, cosa che richiede una vulnerabilità da chiudere.

Il ruolo nel penetration test

Reverse e bind shell sono strumenti standard del lavoro di un hacker etico, e il loro uso in un test autorizzato è ciò che distingue la sicurezza offensiva legittima dall’attacco criminale: stesse tecniche, finalità opposta. In un penetration test, ottenere una shell su un sistema bersaglio non è il fine, ma la prova concreta che una vulnerabilità è realmente sfruttabile — e il punto di partenza per documentare fin dove un attaccante potrebbe spingersi. È la differenza tra sapere che una porta è aperta e dimostrare cosa ci si può fare. Di chi sono questi professionisti e come operano legalmente abbiamo parlato nell’approfondimento sull’importanza dell’ethical hacking in azienda.

Capire come un attaccante otterrebbe il controllo di un sistema è il primo passo per impedirglielo. Cyberment lo fa sul campo per le imprese italiane con il Penetration Test certificato ISO 27001, in cui hacker etici simulano attacchi reali — reverse shell incluse, in ambiente autorizzato e controllato — per dimostrare quali vulnerabilità sono davvero sfruttabili, e con il Vulnerability Assessment per individuarle e chiuderle prima che lo faccia qualcun altro.