whitelist: diagnose обещает «переживёт ребут», не сверяясь с protect.conf; add_wl без дедупа и без предупреждения о широких CIDR #38

1. diagnose: «whitelist переживёт ребут» проверяет не то, что обещает

scripts/diagnose.sh:495-503 сверяет живой сет с na_filter.nft и на совпадении печатает:

[+] whitelist в файле и в памяти совпадают (переживёт ребут)

Ребут — да, переживёт. Но protect.conf в сверке не участвует, а именно он — вход для ре-рана install.sh protect, который перегенерирует .nft (na-whitelist-four-places). В итоге адрес, который есть в .nft + в памяти + в CrowdSec, но отсутствует в protect.conf, диагностика объявляет здоровым, а первый же ре-ран protect его молча выкидывает.

Живой пример с ноды флота (us1): джамп-хост оператора 179.254.126.53 лежит в na_filter.nft, в живом сете и в crowdsec/parsers/s02-enrich/na-whitelist.yaml, но в protect.conf его нет:

$ grep -oE 'WHITELIST:=[^}]*' /etc/node-accelerator/protect.conf
WHITELIST:=209.112.89.0/24,209.112.89.41,217.60.99.30
$ nft list set inet na_filter whitelist_v4 | grep -o '179\.254\.126\.53'
179.254.126.53
$ na-diagnose | grep whitelist
  [+]  whitelist в файле и в памяти совпадают (переживёт ребут)

Такой дрейф — штатное следствие дизайна: авто-whitelist SSH-IP (protect.sh:319-322) в protect.conf не пишется намеренно (комментарий на :1518 это оговаривает), а в .nft попадает. То есть сценарий «раскурили ноду из транзитной сессии → IP осел в файле → диагностика довольна» воспроизводится сам собой на каждой ноде.

Починка: добавить третий источник в сравнение и разделить вердикты — «переживёт ребут» (live == .nft) и «переживёт ре-ран protect» (live == protect.conf), назвав в предупреждении конкретные адреса. Строку про авто-IP имеет смысл выводить явно: «адрес X добавлен транзитно, в protect.conf его нет — при ре-ране исчезнет».

2. protect.sh:add_wl() — нет дедупа и нет предупреждения о широком CIDR

add_wl() {
    for x in ${1//,/ }; do
        ...
        elif [[ "$x" =~ ^([0-9]{1,3}\.){3}[0-9]{1,3}(/[0-9]{1,2})?$ ]]; then WL4+="${WL4:+, }$x"

Дубликат из CSV оператора уходит в ruleset как есть — на двух наших нодах в protect.conf, в .nft, в живом сете и в CrowdSec-yaml один и тот же адрес прописан дважды:

WHITELIST:=179.254.126.0/24,185.244.163.245,141.11.100.235,209.112.89.169,141.95.127.57,193.111.248.238,193.111.248.238,217.60.99.30

Соседний цикл для node-port peers (protect.sh:610-616) дедуп уже делает — то есть в одном файле два разных подхода к одной задаче.

Второе: /24 и шире принимаются молча. При этом whitelist в na — это полный обход (accept раньше автобана, CrowdSec-бунсера и per-IP лимитов, плюс доступ к node-port при NODE_PORT_WHITELIST_ONLY=1), так что 209.112.89.0/24 в конфиге ноды означает «256 адресов чужого хостера имеют иммунитет». У нас такие /24 нашлись на 6 боксах — все приехали копипастой при раскуре, никто их потом не перечитывал.

Починка: дедупить (как в :610), а на префикс короче /29 печатать warn с явной формулировкой, что whitelist — это обход всех защит, а не «доверенный список». Дёшево и ловит ровно тот класс ошибок, который иначе живёт годами.

Окружение

node-accelerator 4.0.0 / 4.0.1, 11 нод + панель, Debian 12/13. Обе находки — с боевого аудита флота, не из чтения кода.