WEB board

BOARD-WASH-20260910:WAVE-3340
По поручению владельца 18:43Z назначена исполнительская волна 3340 (external), Codex gpt-5.6-luna xhigh, M4. Полная история карточки и база l115c 1ad52e16b доставлены, brief-guard и проверка Git-базы пройдены. Задача: проверить существующую сдачу, устранить остатки, передать бандл и доказательства. Финальная приёмка и посадка остаются за координатором. Ранее отложенная функция не включается; статус parked/backlog сохранён, идёт проверка технического остатка.
КАРТА ДОКУМЕНТОВ: ноут /Users/annakorin/nc-ops-scripts/board-wash-20260910/3340-wash-external-brief.md; M4 /Users/milamarty/waves/inputs/board-wash-20260910/external-tickets.json; ожидаемый отчёт /Users/milamarty/waves/3340WASHEXTERNAL-REPORT.md. Правила обогащения: WEB-449.

WASH3340-RECEIVED:306
Получена и прочитана сдача 3340. GO относится только к объёму исполнителя. Бандл сохранён на ноуте и SHA256 проверен. Исправление d182e853a (два файла disclosure/тест) ещё НЕ принято координатором и НЕ посажено. Исторические внешние статусы ниже не перепроверены живьём.

OCI firewall / origin lock

### Критерии

1. OCI Security List no longer exposes SSH to `0.0.0.0/0`; allowed source set is verified.
2. At least one NSG exists and does not rely only on inherited Default Security List.
3. WEB-075 origin-lock is applied for public 80/443 where appropriate.
4. A real foreign-source negative probe rejects SSH, while an allowed source still works.

### Факты / коммит

Ticket created `2026-08-21T01:43:56.214Z`, status `parked`, priority P1. Initial body recorded VCN `nc-vcn`, Default Security List ingress `0.0.0.0/0` for TCP 22/80/443 and ICMP, with no NSG. It correctly distinguishes host-layer ufw/ssh-policy from cloud-layer exposure and points to WEB-075 origin-lock.

The later owner decision was to narrow after the thirtieth deployment. The ticket’s later evolution reports a narrow SSH rule for `86.45.55.126/32`, broad SSH removed, a dummy `192.0.2.1/32` negative substitution refused and the prior rule restored. The same evolution explicitly leaves dynamic home-IP risk, no NSG, public 80/443, and WEB-075 origin-lock as residuals; the negative was not a real foreign machine probe.

The cited truth artifacts are absent here: `/Users/milamarty/Downloads/GATE13-OCI-TRUTH-20260821.md` and `/Users/milamarty/Downloads/GATE13-OCI-TRUTH-RAW-20260821.json`. The `oci_fw_read.py` / `oci_fw_set.py` tools are described as laptop tools, not source files in this worktree. No OCI CLI/API, SSH, production or external infrastructure operation was performed. No source SHA is claimed.

### Остаток

Obtain a current OCI snapshot, create/apply NSG and WEB-075 origin-lock through the coordinator’s infrastructure process, then run a genuine foreign-source negative and allowed-source positive test. Do not reapply the historical narrow rule blindly.

### KNOWN ISSUES / ТРАБЛШУТИНГ

- Симптом: cloud layer can be wider than host layer; SSH may appear safe from ufw logs while OCI still permits world ingress. Two-minute check after artifacts arrive: inspect the raw JSON with `jq` for Security List ingress and NSGs, then compare with current public IP allowlist. No live read was run here.
- Root: OCI VCN Security List/NSG configuration, not an application source file.
- Treatment: coordinator performs snapshot-backed change, preserves rollback, verifies 22/80/443 separately, and records a true foreign-source negative. Missing raw paths above are a blocker for safe execution.

### ДЛЯ ТИКЕТА

Evolution: `2026-08-21` discovery and owner decision to defer narrowing; subsequent owner-reported narrow SSH and dummy-rule negative; later triage marks SSH portion stale/done but NSG and origin-lock separately parked behind WEB-032/WEB-075 migration. Paths: ticket history and canon above; external truth paths `/Users/milamarty/Downloads/GATE13-OCI-TRUTH-20260821.md`, `/Users/milamarty/Downloads/GATE13-OCI-TRUTH-RAW-20260821.json`; referenced laptop scripts `oci_fw_read.py`, `oci_fw_set.py`; related repository source only contains unrelated host egress-fence material and was not substituted for OCI truth.

[13.09 11:01Z координатор] Мойка отложенных, волна 3668. Вердикт: ЖДЁТ-ВЛАДЕЛЬЦА. SSH сужен до /32; остался NSG=0 + origin-lock WEB-075; окно миграции — решение владельца.

[13.09 16:51Z координатор] Живая сверка облачного слоя, сделана координатором прямо сейчас через OCI API (подписанный запрос, тенант прода, `securityLists` по VCN `nc-vcn`). Тело тикета описывало состояние на 21.08 — оно УСТАРЕЛО наполовину, и это важно знать, чтобы никто не чинил уже починенное.

ЧТО УЖЕ ЗАКРЫТО: **SSH на 0.0.0.0/0 больше НЕТ.** Порт 22 разрешён ровно двум адресам, и у правил стоят описания:
- `86.45.55.126/32` TCP 22 — «SSH — только наш адрес (WEB-306…)»
- `129.80.41.210/32` TCP 22 — «a2 node tunnel»

ЧТО ОТКРЫТО МИРУ СЕЙЧАС (и почему): 80/443 — публичные по назначению; ICMP — диагностика; SIP `5060` TCP+UDP и `5074` TCP+UDP, RTP `10000-10020` UDP и `13200-13300` UDP — телефония, она обязана быть достижима извне. Egress: `0.0.0.0/0` all. Network Security Groups по-прежнему не создано ни одной — их роль тут выполняет список безопасности VCN.

ЧТО НЕ ЗАКРЫТО И ЯВЛЯЕТСЯ НАСТОЯЩИМ ОСТАТКОМ ТИКЕТА: **origin-lock не применён.** Проверено пробой:
```
curl -H "Host: sixbyy.com" http://129.213.25.105/    → 301
curl -k -H "Host: sixbyy.com" https://129.213.25.105/ → 200
curl http://129.213.25.105/ (без Host)                → 301
```
`sixbyy.com` и `app.sixbyy.com` резолвятся в Cloudflare (104.21.16.129 / 172.67.212.182), но сам origin отвечает 200 по прямому IP. Значит, кто знает адрес машины, обходит Cloudflare целиком — вместе с WAF, лимитами и защитой от ботов. Это ровно наш класс «починка одного слоя ≠ защищённая система»: хостовой слой закрыт, облачный по SSH закрыт, а обход фронта остался.

ДВЕ ОПАСНОСТИ, которые надо снять ДО того, как сужать 80/443 до диапазонов Cloudflare (иначе починка security-дыры уронит прод):
1. **Выпуск/продление сертификата.** Если сертификат на origin выпускается через ACME HTTP-01, порт 80 обязан оставаться открытым миру, иначе продление молча перестанет работать и через 90 дней сайт ляжет. Проверить способ выпуска ДО сужения.
2. **Проверка посадки `public 200`.** Шаг проверки в ранбуке посадки обращается к публичному адресу; если он ходит на прямой IP, а не через Cloudflare, сужение сломает проверку каждой посадки.

План (координатор, без владельца — по его постоянному «делай сам всё, что нужно для живучести»): (1) установить способ выпуска сертификата и адрес, который дёргает проверка посадки; (2) добавить правила 443 с источниками = актуальные диапазоны Cloudflare, СОХРАНИВ существующее правило `0.0.0.0/0` на 443; (3) проверить, что сайт жив через Cloudflare; (4) только после этого удалить правило `0.0.0.0/0` на 443 и повторить пробу прямого IP — ожидается отказ соединения; (5) 80 трогать в последнюю очередь и только если ACME не зависит от него. Откат на каждом шаге — одно правило обратно.

РЕШЕНИЕ=parked
ОСНОВАНИЕ=2026-09-22: сверка координатора 2026-09-13 — SSH сужен, но NSG=0 и origin-lock WEB-075 не применён; прямой origin отвечает 200.
ЧТО НУЖНО=в окне миграции создать NSG, применить WEB-075 origin-lock и подтвердить разрешённый плюс настоящий foreign-source negative probe.
triage-neo 4616

РЕШЕНИЕ=parked
ОСНОВАНИЕ=2026-09-13, живая сверка: SSH сужен до /32, но NSG=0 и origin-lock WEB-075 не применён; прямой origin отвечает 200, движения 7+ дней нет.
ЧТО НУЖНО=ПРЕДЛОЖЕНИЕ=split; первый шаг: проверить ACME и public-200 путь перед NSG/origin-lock; triage-neo 4713

[27.09 15:30Z координатор] Взят в работу по слову владельца 27.09 15:28Z. Первый шаг: read-only сверка ingress OCI (security lists/NSG), какие порты реально нужны (ACME, 443 через Cloudflare, SSH /32), затем план сужения с откатом до применения.

[27.09 15:33Z координатор] Сверка 27.09 (read-only, OCI SDK с ноутбука + A1). Снимок до: nc-ops-scripts/oci-sl-before-20260927.json.
Сделано: удалено временное правило 3610-3611 от A2 (замер 14.09, на A1 никто не слушает; владелец тогда просил вернуть как было). Прод 200, SSH ок. Правил 12→11.
Нашёл:
1) ГЛАВНОЕ: прод отвечает напрямую по IP 129.213.25.105 в обход Cloudflare (https app.sixbyy.com --resolve на origin = 200). 80/443 открыты миру в OCI и ufw. WAF/лимиты Cloudflare обходятся.
2) Мешают простому замку на диапазоны Cloudflare: nb.wool2.online и dev.wool2.online смотрят прямо на origin (не через CF); сертификат sip.sixbyy.com продлевается webroot по 80 напрямую; sixbyy-сертификаты через nginx-authenticator (HTTP-01 идёт через CF, это ок).
3) Открыты миру без слушателя: 5074 tcp/udp и 13200-13300 udp (эксперимент SIP) — в OCI и в ufw.
4) SIP 5060/5061 и RTP 10000-10020 открыты миру — нужны софтфонам, оставить (защита на уровне Asterisk).
План (ждёт слова владельца, с откатом из снимка):
 а) закрыть 5074 и 13200-13300 в OCI и ufw;
 б) на origin пускать 443 только с диапазонов Cloudflare для vhost sixbyy (nginx allow/deny по реальному адресу соединения), wool2 и sip не трогать; 80 оставить для ACME;
 в) вариант шире: увести wool2 за Cloudflare, затем замок 443 уже в OCI.
Рекомендую а+б сейчас.

[27.09 15:44Z координатор] [27.09 15:50Z координатор] Сделано по слову владельца 15:39 («делай, как говоришь»). Полный след для нулевого агента.

СИМПТОМ/НАХОДКА: прод A1 (129.213.25.105) отвечал на 443 напрямую по IP в обход Cloudflare: `curl -sk --resolve app.sixbyy.com:443:129.213.25.105 https://app.sixbyy.com/` = 200 с любого адреса. Значит WAF, rate-limit и защита от DDoS в Cloudflare обходились.

КАК ИСКАЛ: OCI SDK с ноутбука (venv /private/tmp/claude-501/ocisdk, запуск из run/), ingress Default Security List nc-vcn; на A1 `ss -ltnu`, `ufw status`; DNS; выборка ss established :443 за 60 с — только адреса CF (172.71.x, 104.23.x); grep IP origin по скриптам флота — только SSH (A2 туннели a1-tunnel*, M1 nightly git fetch), на 443 не влияет.

ЧТО СДЕЛАНО (все с откатом):
1) OCI: снимок до `nc-ops-scripts/oci-sl-before-20260927.json`. Удалены: 3610-3611 от A2 (временное с 14.09), 5074 tcp/udp и 13200-13300 udp (эксперимент SIP, слушателя нет). 12→8 правил.
2) ufw A1: удалены allow IN 5074/tcp, 5074/udp, 13200:13300/udp (v4+v6). Бэкап /etc/ufw/user*.rules.pre-web306-20260927. ALLOW OUT на эти порты оставлены (исходящие, безвредны).
3) nginx A1: бэкап всего /etc/nginx в /root/nginx-pre-web306-20260927. Новый /etc/nginx/conf.d/cf-only-geo.conf: geo по $realip_remote_addr (адрес TCP-соединения, НЕ заголовок CF-Connecting-IP — его можно подделать) → $nc_from_cf; разрешены диапазоны CF (из cloudflare-real-ip.conf), localhost, 10.0.0.0/16, владелец 86.45.55.126, A2 129.80.41.210. /etc/nginx/cf-only-guard.inc: `if ($nc_from_cf = 0) { return 444; }`, подключён сразу после listen 443 в app.sixbyy.com, sixbyy.com(+www), dev.sixbyy.com. nginx -t ок, reload.
НЕ ТРОНУТО и почему: nb/dev.wool2.online смотрят прямо на origin (не через CF) — замок их сломал бы; sip.sixbyy.com — только 80 для ACME webroot; 80 открыт всем (ACME, редирект на https); SIP 5060/5061 и RTP 10000-10020 нужны софтфонам. Замок на уровне OCI невозможен, пока wool2 не за CF.
ПРОВЕРКА: app/sixbyy через CF 200, nb.wool2 301 (как было); напрямую с адреса владельца 200 (в allowlist, ожидаемо); внешняя проверка из не-allowlist — см. следующий коммент.
ОТКАТ: убрать строку `include /etc/nginx/cf-only-guard.inc;` из трёх vhost (или cp -a из /root/nginx-pre-web306-20260927) + nginx -t + reload; OCI — восстановить правила из json-снимка.
РИСК НА БУДУЩЕЕ: список диапазонов CF меняется редко, но меняется. При обновлении cloudflare-real-ip.conf пересобрать cf-only-geo.conf (та же выборка set_real_ip_from). Если A2/владелец сменят IP — прямой доступ пропадёт, через CF будет работать.
ОСТАЛОСЬ: а) решение по wool2 (увести за CF → тогда можно замок в OCI); б) автообновление диапазонов CF.