Кейс: закрытие уязвимостей по результатам независимой проверки и усиление защиты партнерского портала на 1С-Битрикс

Проект: партнерский портал (B2B) на 1С-Битрикс
Клиент: (NDA)
Задача: по итогам независимой проверки безопасности внедрить меры, снижающие риски эксплуатации и утечки данных, не нарушив работу ключевого функционала.

Контекст

Партнерские порталы почти всегда находятся «между двух огней»: с одной стороны — доступность для внешних пользователей, с другой — повышенные требования к защите, потому что внутри обычно есть данные сотрудников, документы, интеграции и административные разделы.

По итогам внешней проверки безопасности были зафиксированы типовые зоны риска: доступность чувствительных файлов и служебной информации, необходимость ужесточить доступ к административным разделам, снижение риска SSRF через пользовательский ввод, а также настройка security-заголовков и уменьшение информации о стеке, которую сервер отдает в ответах.

Что сделали

1) Убрали доступ к чувствительным файлам и служебной информации

• Удалили служебную страницу, раскрывающую конфигурацию окружения (аналог phpinfo), чтобы исключить утечку версий и настроек.
• Закрыли доступ к чувствительным файлам и служебным артефактам, которые не должны читаться извне.
• Ограничили набор потенциально опасных функций PHP на уровне конфигурации (через disable_functions), чтобы снизить вероятность выполнения команд в случае попыток эксплуатации.

Зачем: даже если где-то остается слабое место, злоумышленнику сложнее «развить» атаку до компрометации сервера.

2) Усилили контроль доступа к административным зонам

• Для закрытых зон внедрили ограничения по спискам доверенных IP (allowlist), чтобы доступ к администрированию был только у уполномоченных сотрудников.
• Дополнительно точечно ограничили доступ к инструментальным обработчикам и сценариям, которые потенциально могут использоваться в атакующих цепочках.

Зачем: админка и служебные обработчики — типовая точка входа для перебора, сканирования и попыток эксплуатации.

3) Временная мера: базовая авторизация на период работ (и когда она реально нужна)

На период внедрения исправлений мы применяли базовую авторизацию (HTTP Basic Auth) как быструю временную меру снижения рисков. После того как постоянные меры защиты были внедрены и проверены — ограничение сняли по запросу клиента.

Важно: базовая авторизация не заменяет исправление уязвимостей. Ее ценность в другом — это «быстрый барьер», который:

• отрезает массовые сканеры и автоматические попытки (до приложения просто не доходят)
• дает время спокойно внедрить и протестировать постоянные настройки без риска «поймать» атаку в процессе
• полезен, если раздел по природе закрытый (партнерский кабинет, staging/тест, сервисные зоны), и публичный доступ туда не требуется

Когда это может потребоваться:

• срочно снизить экспозицию (пока идет внедрение правок или расследование)
• закрыть доступ к закрытому разделу на время работ
• временно защитить непубличный контур, который не должен индексироваться и быть доступным всем

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

4) Снизили риск SSRF и нежелательных сетевых запросов

• На уровне firewall настроили блокировку исходящих запросов к внутренним сетям (iptables), чтобы исключить использование сервера как «прокси» к внутренней инфраструктуре.
• На уровне PHP отключили возможности для удаленных подключений и инклюдов:
• allow_url_fopen = Off
• allow_url_include = Off

Зачем: SSRF — это не про «один запрос», а про цепочку. Мы перекрыли ключевые условия, чтобы такую цепочку собрать было существенно сложнее.

5) Убрали лишнюю идентификацию стека и включили security-заголовки

Чтобы сервер меньше «рассказывал о себе» и включить стандартные механизмы защиты на стороне браузера:

• скрыли сведения о PHP: expose_php = Off
• на уровне FastCGI скрыли технические заголовки:
• fastcgi_hide_header X-Powered-By;
• fastcgi_hide_header Server;
• установили модуль/настройку для очистки лишних заголовков
• включили и проверили корректность security-заголовков, включая:
• HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy

Зачем: это не «серебряная пуля», но это обязательная гигиена: меньше лишней информации для атакующего и больше встроенной защиты на стороне браузера.

6) Обновили окружение

Выполнили обновление серверного ПО (в рамках допустимого для проекта), включая компоненты веб-стека (nginx, php-fpm и системные пакеты).

Зачем: это скучно, но очень полезно: злоумышленники в первую очередь эксплуатируют известные «дыры» в старых версиях. Обновления закрывают такие уязвимости и заметно снижают риск атаки.

Результат

• Закрыли доступ к служебной информации и чувствительным файлам.
• Ограничили опасные функции и сетевые сценарии на уровне PHP.
• Снизили риск SSRF через комбинацию сетевых правил и настроек интерпретатора.
• Настроили скрытие лишних HTTP-заголовков и включили security-заголовки (HSTS/CSP и др.).
• Ужесточили доступ к закрытым зонам через allowlist и временные ограничения на период работ.
• Обновили окружение, чтобы закрыть известные риски устаревших компонентов.

Итог: портал стал заметно устойчивее к типовым атакам и автоматическим сканированиям.

Защита построена этапами — отказ одной меры ведет за собой включение следующей.