Белый список (освобождение от блокировки)

Обзор — что делает эта страница

Страница Белый список управляет IP-адресами и диапазонами, которые нужно вывести из конвейера автоматической блокировки InfraGuard. Всё, что здесь зарегистрировано, образует «реестр исключений», к которому коллекторы обнаружения обращаются непосредственно перед блокировкой, — это не даёт заблокировать доверенные источники (CDN, партнёрские API, офисные каналы) из-за ложного срабатывания.

Центральное понятие здесь — срок действия:

• expires_at равен NULL → постоянное исключение (никогда не истекает). Для всегда доверенных источников, таких как CDN и офисные каналы.
• expires_at содержит дату → временное исключение (автоматически прекращает действовать после этого момента). Для коротких окон расследования или для автоматических вердиктов о невиновности.

Исключения поступают из трёх источников:

Таблица infr_whitelist находится на подключении legacy_glory (та же БД, что и blacklist_info и таблицы suricata_*), а не в базе приложения. Благодаря этому Node-коллектор srct_tx может читать эту таблицу напрямую прямо перед блокировкой и записывать в неё невиновные IP.

Когда использовать

• Предотвратить ложные срабатывания: заранее внесите обычный трафик (боты мониторинга, партнёрские краулеры, платёжные обратные вызовы), способный задеть эвристики сканирования и частоты.
• Временное исключение на время расследования: задайте диапазону дату окончания, чтобы освободить его на несколько дней.
• Всегда доверять CDN и офису: постоянно освободите фронтальные IP Cloudflare/Google/AWS/Akamai или фиксированный офисный IP.
• Проверить автоматические вердикты: просматривайте, продлевайте или удаляйте записи auto, созданные srct_tx.
• Разблокируйте в блок-листе ошибочно заблокированный IP и не дайте заблокировать его снова (зарегистрировав исключение).

Устройство

Показатели вверху (5)

Их вычисляет WhitelistService::summary() с кешем на 30 секунд. Действует = is_active = 1 И (expires_at IS NULL ИЛИ expires_at > now).

Список исключений

Таблица с фильтрами (25 строк на страницу). Сортировка: сначала постоянные (expires_at IS NULL DESC) → срок по возрастанию → id по убыванию.

Фильтры: состояние (действует · истекло · все), источник (вручную · автоматически · по умолчанию · все) и поиск (IP · CIDR · название). Список опрашивает обновления каждые 30 секунд.

Окно добавления вручную

Кнопка [Add manually] (Добавить вручную) открывает модальное окно. Поля: IP или CIDR, название (необязательно) и дата-время окончания (необязательно; пусто = постоянно).

Как пользоваться

1. Добавить исключение вручную

1. Нажмите [Add manually] (Добавить вручную).
2. Введите IP или CIDR. Одиночный IP приводится к /32, диапазон — к своему адресу сети (см. правила нормализации ниже).
3. При желании укажите название и дату-время окончания. Оставьте срок пустым, чтобы получить постоянное исключение.
4. Нажмите [Add] (Добавить). Если такой же cidr уже существует, запись активируется заново (is_active=1), а её срок и название обновляются.

2. Правила нормализации (normalizeCidr)

WhitelistService::normalizeCidr() переписывает ввод в каноническую форму (не зависит от языка и совпадает с соглашением сопоставления в srct_tx).

203.0.113.10        → 203.0.113.10/32     (одиночный IP становится /32)
203.0.113.0/24      → 203.0.113.0/24      (без изменений)
203.0.113.55/24     → 203.0.113.0/24      (биты узла маскируются → адрес сети)
10.0.0.5/8          → 10.0.0.0/8
999.1.1.1           → (недопустим → null, 422 invalid_ip)

• Только IPv4. Длина префикса 0–32.
• Перед сохранением контроллер проводит предварительную проверку регулярным выражением ^\d{1,3}\.\d{1,3}\.\d{1,3}(\.\d{1,3})?(/\d{1,2})?$, а сервис завершает её с помощью filter_var(... FILTER_FLAG_IPV4) + ip2long.

При добавлении диапазона /24 биты узла можно оставить — 203.0.113.55/24 автоматически сохраняется как 203.0.113.0/24 (адрес его сети).

3. Ввод срока действия

• Пусто → постоянно (expires_at = NULL).
• YYYY-MM-DD или YYYY-MM-DD HH:MM → разбирается через Carbon::parse.
• Неудачный разбор также означает «постоянно» (parseExpiry → null).

4. Удаление

Действие удаления в строке списка вызывает remove после подтверждения. Строка удаляется физически (не помечается как удалённая). Даже запись CDN с источником seed можно удалить, но при следующем запуске сидера она может быть создана заново.

5. Автоматическое признание невиновности в srct_tx (источник auto) — как оно наполняется

Коллектор srct_tx проверяет невиновность по очень строгой процедуре непосредственно перед блокировкой IP со сканированием или аномальной частотой и оставляет здесь запись auto только тогда, когда вердикт бесспорен.

1. Фильтр по белому списку — если IP уже есть в infr_whitelist (плюс список CDN в самом коде), он немедленно освобождается и пропускается.
2. Проверка репутации только для кандидатов «только E» — в AbuseIPDB проверяются лишь те IP, у которых есть склонный к ложным срабатываниям признак «короткое сканирование само по себе» (эвристика E) и нет ни одного из жёстких признаков (A/A2/B/C/D) (ключи по кругу · кеш 6 ч · лимит на проход).
3. Вердикт о полной невиновности — если abuse_score=0 И reports=0 И это не Tor (либо IP в белом списке с оценкой 0), в infr_whitelist(source=auto) автоматически регистрируется исключение на 30 дней (ip/32), а блокировка пропускается.

Автоматическое признание невиновности есть только у srct_tx. kts_tx (Kitsune ML) лишь читает белый список и фильтрует по нему — он не делает запросов репутации и не регистрирует записи автоматически.

6. cidrList() — повторное использование при генерации кода

WhitelistService::cidrList() возвращает список действующих и не истёкших CIDR без дубликатов (кеш на 30 секунд). Этот список подставляется как источник константы CDN_WHITELIST_CIDRS, когда страница Правила и пороги генерирует скрипты srct_tx/kts_tx, — так исключения, которыми управляют в интерфейсе, попадают в реальный код коллектора.

Источники данных

Таблица infr_whitelist (подключение: legacy_glory, миграция 000734)

Индексы: (is_active, expires_at), source.

infr_whitelist создаётся в БД legacy_glory (GLORY). Если legacy_glory не настроено как mysql/mariadb, миграция и сидер защищены и ничего не делают — страница отрисовывается, но показатели читаются как 0. В реальных развёртываниях подключение GLORY должно быть заполнено.

Сидер InfrWhitelistSeeder (source=seed, постоянно)

Переносит ранее прошитые в коде диапазоны CDN/OFFICE (идемпотентно за счёт firstOrCreate). Включает фронтальные диапазоны Cloudflare, Google, Meta, AWS и Akamai, а также фиксированный IP OFFICE.

php artisan db:seed --class=InfrWhitelistSeeder

Модель · сервис

• Модель: App\Models\Infr\InfrWhitelist (protected $connection = 'legacy_glory').
• Сервис: App\Services\Security\WhitelistService — summary() (показатели, кеш 30 с), page() (фильтрация и разбивка на страницы), add()/remove() (записи), cidrList() (источник для генерации кода) и normalizeCidr() (статический SOT).
• Контроллер: App\Http\Controllers\Security\WhitelistController — index · live · add · remove.

Права доступа

Схема уровней: demo=1 · staff=5 · admin=10. То есть staff и admin могут и читать, и писать; при неудачной записи возвращается 403 forbidden (уведомление «Не разрешено (уровень 2 или выше)»).

Каждая запись фиксируется в InfrAuditLog:

• Добавление → sec.whitelist_add (target=ip, в meta есть id · reactivated).
• Удаление → sec.whitelist_remove (target=ip, в meta есть id).

Полную политику уровней и ролей см. в разделе Уровни доступа, а разбор записей — в Журнале аудита.

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

Все показатели равны 0, а список пуст

Подключение legacy_glory не настроено либо таблица infr_whitelist ещё не создана. Проверьте настройки БД GLORY и выполните миграцию и сидер. При ошибках БД сервис аккуратно возвращает пустые значения.

«Недопустимый IP / CIDR» (422)

Введённое значение не является IPv4, либо длина префикса выходит за пределы 0–32. IPv6 не поддерживается. Примеры: 203.0.113.10, 203.0.113.0/24.

Я ввёл /24, но сохранённый диапазон отличается

Так и задумано. Биты узла маскируются до адреса сети (203.0.113.55/24 → 203.0.113.0/24).

Создаст ли повторное добавление того же IP дубликат?

Нет. Поле cidr уникально, поэтому существующая запись активируется заново, а её срок и название обновляются (в ответе reactivated: true). Если существующая запись была seed, источник так и остаётся seed.

Почему появляются записи auto и можно ли их удалить?

srct_tx автоматически зарегистрировал IP, признанный им явно невиновным, как исключение на 30 дней. Удалить её можно, но если этот IP снова будет отмечен ошибочно, запись может появиться вновь.

Исчезают ли истёкшие записи сами собой?

Строка остаётся, но после наступления срока перестаёт попадать в подсчёт «действующих». Переключите фильтр состояния на истекло/все, чтобы их увидеть. Чтобы избавиться от них полностью, удалите их.

Я освободил IP, но его всё равно блокируют

Проверьте: (1) действительно ли нормализованный диапазон покрывает IP этого трафика (например, /32 против /24); (2) кеш cidrList() (30 с) и был ли заново сгенерирован скрипт коллектора; (3) нет ли уже записи о блокировке в blacklist_info. Существующие блокировки нужно снимать из блок-листа.

Смежные темы

• Блок-лист и репутация — управление списком блокировок (противоположность исключению)
• Автоблокировка — автоблокировка планировщиком (вето по белому списку и невиновности)
• Угрозы — разбор угроз IDS, детализация по IP
• Правила и пороги — константы srct_tx/kts_tx + подстановка cidrList
• Репутация IP — запрос к AbuseIPDB внутри приложения
• Журнал аудита — аудит операций записи