В современной цифровой среде фишинг остается одной из самых распространенных и опасных киберугроз․ По данным отраслевых отчетов, ежедневно появляются тысячи новых мошеннических ресурсов, имитирующих легальные сайты банков, интернет-магазинов, госуслуг и корпоративных порталов․ Для систематической борьбы с этим феноменом существует сложная инфраструктура мониторинга и реестров фишинговых сайтов․ В данной статье подробно разбираются принципы работы таких систем, источники данных, инструменты автоматизации и процедуры блокировки на примере передовых российских практик (на основе данных от )․

Что такое реестр фишинговых сайтов и зачем он нужен

Реестр фишинговых сайтов — это динамическая база данных, содержащая информацию об URL-адресах, доменных именах и IP-адресах, идентифицированных как инструменты для кражи конфиденциальных данных (логинов, паролей, банковских реквизитов, персональных данных)․

Основные функции реестра:

• Оперативное предупреждение: интеграция с браузерами, антивирусами и корпоративными SIEM/SOAR системами для блокировки перехода пользователей на опасные ресурсы․
• Поддержка процедур блокировки: передача данных в уполномоченные органы (в РФ — в ГКРЧ, Роскомнадзор, КНЦ) для принятия решений о ограничении доступа на территории страны․
• Аналитика и расследование: накопление данных об инфраструктуре злоумышленников (регистраторы, хостинг-провайдеры, NS-серверы, SSL-сертификаты) для атрибуции атак․
• Бренд-защита (Brand Protection): мониторинг использования товарных знаков и брендов компаний в доменных именах третьих лиц․

Архитектура системы мониторинга: от сбора данных до вердикта

Современные платформы защиты бренда и мониторинга фишинга (например, решения класса DRP — Digital Risk Protection, такие как BI․ZONE Brand Protection, а также государственные системы вроде описанной на портале digital․gov․ru) работают по конвейерному принципу․

Схема процесса:

1. Сбор сырых данных (Reconnaissance): агрегация списков новых и обновленных доменов․
2. Сканирование и анализ (Scanning & Analysis): активная проверка контента сайтов на признаки фишинга․
3. Верификация аналитиком (Human-in-the-loop): исключение ложных срабатываний и подтверждение инцидента․
4. Инициирование блокировки (Takedown/Blocking): взаимодействие с регистраторами, хостерами и регуляторами․

Источники данных для пополнения реестра

Качество реестра напрямую зависит от полноты охвата пространства доменных имен․ По данным ведущих операторов безопасности (в частности, команды BI․ZONE), ежедневно обрабатывается более 1 млн новых доменов, а общий объем базы уникальных доменов превышает 1,5 млрд․

Ключевые источники телеметрии:

Файлы доменных зон (Zone Files)

• gTLD (общие домены верхнего уровня): данные предоставляются ICANN (Internet Corporation for Assigned Names and Numbers)․ Включают зоны ․com, ․net, ․org, ․info и сотни новых gTLD․ Файлы содержат NS-записи, позволяющие резолвить домены в IP․
• ccTLD (национальные домены): получение файлов зон у операторов национальных реестров (для зоны ․ru, ․рф — у координационного центра, для других — у соответствующих локальных операторов)․ Приоритет отдается зонам с высокой долей фишинга․

Логи прозрачности сертификатов (Certificate Transparency Logs — CTL)

Любой выпущенный публичный SSL/TLS-сертификат логируется в открытых реестрах (CT Logs)․ Мониторинг этих логов в реальном времени позволяет обнаруживать фишинговые сайты в момент получения ими валидного сертификата (часто через Let’s Encrypt или аналогичные бесплатные CA), еще до того, как сайт начнет активно раскручиваться в рассылках․

Данные регистраторов и реселлеров

Прямые фиды от аккредитованных регистраторов о только что зарегистрированных доменах (Newly Registered Domains, NRD) дают временное преимущество в 24–48 часов перед появлением данных в файлах зон․

Passive DNS

Сбор данных о DNS-запросах из трафика провайдеров, рекурсивных резолверов и ханипотов․ Позволяет находить домены, которые не попали в файлы зон (например, поддомены) или имеют нестандартную конфигурацию․

Рефереры (Referrers) и клиентские жалобы

• Рефереры: анализ HTTP-заголовка Referer на легальных сайтах-мишенях (банки, магазины)․ Если пользователь пришел с неизвестного домена, который подгружает фейковую форму логина — это сигнал для сканирования․
• Жалобы пользователей и SOC: короткоживущие URL (в мессенджерах, SMS, почте), которые не успевают попасть в автоматизированные сборщики․ Канал обратной связи от клиентов (например, через форму «Сообщить о фишинге» на сайте организации) критически важен․

Инструментарий автоматического обнаружения

Ручная обработка миллионов доменов невозможма․ В отрасли принято использовать специализированные фреймворки и сканеры․

Пример стекa инструментов (Case Study: BI․ZONE)

В открытых публикациях специалистов (например, статья на Habr от ) описывается внутренняя архитектура, включающая два ключевых компонента:

Whitehole — агрегатор доменной телеметрии

Сервис, отвечающий за сбор, дедупликацию и нормализацию данных из всех вышеперечисленных источников (ICANN, операторы зон, CTL, Passive DNS, регистраторы)․ Он формирует единый поток «кандидатов на проверку» для следующего этапа․

Phish-detector, сетевой сканер и классификатор

Вычислительный кластер, который:

• Скачивает контент по HTTP/HTTPS (рендерит страницы, включая JS-обфускацию)․
• Анализирует DOM-дерево, скриншоты, фавиконы, текстовой контент, структуру форм авторизации․
• Сравнивает визуальные и структурные хеши с эталонами легальных сайтов-мишеней (Computer Vision, perceptual hashing, SIM-hashing)․
• Проверяет WHOIS-данные, возраст домена, репутацию IP/ASN/NS, наличие бренда в домене (typosquatting, combosquatting)․
• Выдает вердикт: Phishing / Scam / Malware / Legit / Parked․

Роль аналитика: Human-in-the-loop

Несмотря на высокую точность ML-моделей (False Positive Rate < 0․1% у зрелых решений), окончательное решение о внесении в реестр и запуске процедуры блокировки принимает человек — аналитик SOC или Brand Protection․

Задачи аналитика на этапе верификации:

• Подтверждение, что сайт именно фишинговый (крадет креды), а не просто сквоттинг или пародия․
• Идентификация бренда-жертвы (Target Brand)․
• Сбор доказательной базы (скриншоты, HAR-файлы, копии страниц, WHOIS-снимки) для передачи в абьюз-службы и регулятор․
• Обогащение индикаторов компрометации (IoC): извлечение IP, поддоменов, email-адресов из контактных форм, кошельков криптовалюты․

Процедуры блокировки и Takedown (Снятие с хостинга)

После подтверждения вердикта запускается процесс ликвидации угрозы․ В юрисдикции РФ и международной практике используются два параллельных трека:

Административная блокировка (на уровне DNS/ISP)

• В РФ: взаимодействие с ГКРЧ (Государственный центр обнаружения, предупреждения и ликвидации последствий компьютерных атак), Роскомнадзором, КНЦ (Координационный центр ТЛД ․ru/․рф)․
• Внесение в реестр запрещенных ресурсов (по решению прокуратуры или суда) для блокировки провайдерами связи․
• Обращение к координационному центру зоны ․ru/․рф о делегировании/аннулировании домена (по основаниям п․ 5․1 Правил администрирования)․

Takedown через абьюз-службы (Abuse Contacts)

• Отправка жалобы (Abuse Report) хостинг-провайдеру, регистратору домена, CDN-провайдеру (Cloudflare и др․)․
• Использование автоматизированных платформ для рассылки abusе-репортов (например, через API регистраторов или специализированные сервисы)․
• Работа с международными CERT/CSIRT командами для блокировки инфраструктуры за рубежом․

Правовые и организационные аспекты ведения реестра в РФ

На государственном уровне ведение реестров и координация действий закреплены за:

• ФСТЭК России / ФСБ (ЦКИИ): методологии защиты КИИ, требования к средствам защиты от фишинга․
• Банк России (FinCERT): отраслевой реестр фишинговых сайтов, атакующих финансовую сферу․ Обязательность отчетности для кредитных организаций․
• Минцифры / ГКРЧ: национальная система обнаружения и предотвращения компьютерных атак (ГосСОПКА)․ Интеграция корпоративных реестров в государственную экосистему обмена индикаторами компрометации (STIX/TAXII)․
• КНЦ (АО «Координационный центр ТЛД ․ru/․рф»): ведение реестра доменных имен, оперативно-техническое взаимодействие при делегировании/удалении вредоносных доменов в национальной зоне․

Лучшие практики для организаций: как использовать реестры

Для эффективной защиты инфраструктуры компании рекомендуется внедрить многоуровневый подход:

Перспективы развития: AI, Graph Analysis и Pre-crime

На 2026 год ключевыми трендами эволюции реестров фишинга являются:

• Предиктивное моделирование (Pre-crime): оценка риска домена до размещения на нем контента (анализ регистратора, хостинга, NS-серверов, паттернов именования, истории аккаунта регистратора)․ Блокировка «на берегу»․
• Графовый анализ инфраструктуры (Infrastructure Graphing): построение графов связей доменов (общие IP, NS, WHOIS, SSL, аналитика кода) для выявления целых кластеров фишинга (Phishing Kits / PhaaS — Phishing as a Service) и их одновременной блокировке․
• Борьба с PhaaS (Phishing-as-a-Service): отслеживание распространения готовых китов (Tycoon 2FA, Greatness, DadSec и др․) через Telegram-каналы, GitHub, Darknet для проактивного добавления сигнатур в детекторы․
• Стандартизация обмена данными: переход на форматы STIX 2․1 / TAXII 2․1, MISP, OpenIOC для бесшовной интеграции государственных и коммерческих реестров․

Реестр фишинговых сайтов — это не статический список URL, а живой, высокоавтоматизированный конвейер обработки петабайтов телеметрии․ Эффективность защиты определяется скоростью прохождения цикла: Появление домена → Сбор телеметрии → Сканирование → Верификация → Блокировка (Takedown/Blocking)․

Для российских организаций критически важна интеграция как с государственными источниками (ГКРЧ, FinCERT, КНЦ), так и с коммерческими DRP-решениями, обладающими глубинной видимостью инфраструктуры злоумышленников (инструменты класса whitehole, phish-detector)․ Только комбинация государственных полномочий (административная блокировка) и технической экспертизы частного сектора (скорость детекта, глобальный охват, работа с абьюзами за рубежом) позволяет снизить время жизни фишингового сайта с дней до часов и минут, минимизируя ущерб для граждан и бизнеса․

Материал подготовлен на основе открытых данных порталов digital․gov․ru, публикаций экспертов BI․ZONE (Habr) и отраслевых лучших практик на момент ․ Контактные данные конкретных сотрудников и внутренние IP-адреса инфраструктуры в соответствии с политикой безопасности заменены на маску (*)․