Check Point уже исправлен — как проверить, не успели ли его взломать

Если шлюз Check Point уже обновлён, подтвердите установленное исправление на каждом устройстве и проверьте события до его установки: аномальные входы Mobile Access по сертификату и последующие обращения к внутренним службам. Бюллетень Check Point подтверждает эксплуатацию CVE-2026-85102 в обработке VPN-сертификатов и CVE-2026-93616 в службе управления, рекомендует оба направления поиска и отсылает к sk1000171 за отдельными признаками для сервера управления.

Исправление закрывает уязвимый путь для новых попыток, но само по себе не устанавливает, получил ли злоумышленник доступ раньше. Разъяснение CISA к директиве BOD 26-04 требует в предусмотренных ею случаях проверять возможную компрометацию до установки обновления. Директива обязательна для гражданских федеральных ведомств США; за их пределами такая проверка остаётся разумной частью реагирования на уже эксплуатируемую уязвимость.

Подтвердите исправление на каждом затронутом узле

Составьте перечень Security Gateway и Spark Firewall, через которые доступны VPN-подключения. Запишите для каждого продукт, ветку версии, фактическую сборку или установленный пакет, режим управления и время обновления. Если шлюзы работают в кластере, проверьте участников по отдельности: доступность общего адреса ничего не говорит о состоянии конкретного узла.

Сводка BleepingComputer для шлюзов называет Check Point LivePatch Take 26 для поддерживаемых R81.20, R82 и R82.10 либо исправленные Jumbo Hotfix R81.20 Take 166, R82 Take 126, R82.10 Take 44 и R81.10 Take 190 или более поздние; для Spark Firewall перечислены R82.00.10 Build 2325 и R81.10.17 Build 4968 или более поздние сборки. Выбирайте пакет по точной модели и ветке в рекомендациях производителя и сверяйте результат на самом устройстве. Успешное завершение задачи в системе развёртывания ещё не доказывает, что нужное исправление действует на всех шлюзах.

Сервер Security Management занесите в перечень отдельно. Его уязвимость относится к другой службе и требует собственного исправления; защищённый VPN-шлюз не подтверждает защищённость управления. Не переносите номер исправления шлюза на сервер управления только потому, что продукты принадлежат одной ветке.

Определите окно проверки и сохраните журналы

Для каждого устройства установите, с какого момента уязвимая конфигурация была доступна извне и когда наличие исправления удалось подтвердить. Журналы ищите прежде всего между этими точками. Если первая дата неизвестна, расширьте поиск до самых ранних доступных записей и отметьте границу хранения данных.

Сохраните исходные события Mobile Access, шлюза, управления и сетевого мониторинга до изменения правил регистрации или очистки хранилища. Приведите отметки времени к одной зоне и проверьте расхождение часов: без этого один вход легко ошибочно связать с чужими сетевыми обращениями. Временная шкала должна показывать, какие журналы действительно покрывают период до обновления, а где доказательств просто нет.

Проверьте сертификатные входы Mobile Access

Выберите записи о входах с сертификатом и сопоставьте их с разрешёнными пользователями, выданными сертификатами и обычными источниками подключения. Подозрение вызывают неизвестный субъект сертификата, непривычная учётная запись, новый адрес источника или вход в необычное для пользователя время. Начните с опубликованных примеров поля Subject, но не ограничивайте ими выборку: наблюдавшиеся значения не образуют полного списка возможных атак.

Для каждого неразъяснённого входа восстановите соседние события: предшествующие попытки, результат аутентификации, начало и конец сессии, выданный адрес и доступные журналы обращений к ресурсам. Затем проверьте рабочие объяснения, например плановую замену сертификата или разрешённый удалённый доступ. Одна необычная запись ещё не доказывает эксплуатацию; вместе с тем отсутствие успешного входа не исключает попытку против уязвимости, срабатывающей до аутентификации.

Свяжите подозрительный вход с внутренней активностью

Для неразъяснённой сессии проверьте, куда обращались её пользователь и назначенный ему адрес после входа. Короткая серия попыток соединиться с разными внутренними узлами, портами или службами может указывать на вторую стадию: поиск доступных целей внутри сети. Сравнивайте её с разрешёнными ресурсами и обычной работой той же учётной записи, чтобы не принять штатную проверку сети за проникновение.

Сопоставьте события Mobile Access с журналами межсетевого экрана, сетевых потоков и самих целевых служб. Разделяйте отклонённые попытки и подтверждённые соединения; отдельно ищите признаки изменений на системах, до которых дошёл подозрительный сеанс. Если продолжения не видно, сохраните сам факт необычного входа и пределы наблюдения: отсутствие записи о сканировании не доказывает, что доступом не воспользовались иначе.

Проверьте сервер управления отдельно

Для Security Management выделите собственный период уязвимости и отдельные источники событий: журналы веб-службы, аудит управления, записи о запуске процессов и изменениях файлов. Сопоставьте опубликованные индикаторы именно этой уязвимости с фактически доступными журналами. Не объявляйте произвольный путь, имя файла или одиночную ошибку доказательством взлома.

Не смешивайте выводы по двум поверхностям атаки. Подозрительная сессия Mobile Access относится к расследованию шлюза; подозрительное выполнение на сервере управления требует своей последовательности событий и проверки затронутых полномочий. Это различие определяет, какие сертификаты, учётные записи и внутренние системы понадобится включить в реагирование.

Что делать при подтверждении доступа

Сначала сохраните исходные журналы и состояние затронутых систем, затем ограничьте подозрительные сессии и соединения по процедуре реагирования организации. Если выявлено злоупотребление учётной записью или риск раскрытия её секретов, смените пароль, перевыпустите затронутый сертификат и проверьте действующие сессии и права. По журналам внутренних систем определите, ограничился ли доступ просмотром служб или сопровождался действиями на этих узлах.

Если записи сохранились лишь частично, зафиксируйте вывод точно: «в доступных данных признаков не найдено» не означает «компрометации не было». Укажите проверенные устройства, временные границы журналов и неразъяснённые события. Это даст команде реагирования основание решить, нужен ли более глубокий анализ конкретных систем или помощь поддержки Check Point.

Читайте также:

• Обновление установлено не всегда: как проверить исправления Windows
• WebLogic атакуют через ошибку 10 из 10 — на исправление дали три дня
• CloudStack 4.23 получил 120 исправлений — обновление меняет резервные копии