Изолированная крепость для Apache и 1С на Linux
Назад

Изолированная крепость для Apache и 1С на Linux

Изолированная крепость для Apache и 1С на Linux

В современной ИТ-инфраструктуре запуск сервиса «как есть» — это осознанный и зачастую неоправданный риск. Мы привыкли полагаться на внешние межсетевые экраны, но забываем, что самая опасная атака - та, что происходит во внутреннем контуре системы.

Systemd Hardening — это стратегия усиления защиты, использующая встроенные механизмы менеджера служб для глубокой изоляции процессов (песочницы) и жесткого ограничения их прав в ОС Linux. В этой статье мы разберем, как превратить стандартные процессы Apache и 1С в изолированные сущности, минимизируя «поверхность атаки».

Концепция защиты: Zero Trust на уровне сервиса

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

Эта концепция строится на трех столпах:

  • Изоляция файловой системы (FS): процесс видит и взаимодействует только с теми директориями, которые критически необходимы для его работы.
  • Фильтрация системных вызовов: запрет потенциально опасных функций ядра, которые могут быть использованы для повышения привилегий.
  • Принцип минимальных прав: полный отказ от привилегий суперпользователя (root) и ограничение возможностей процесса на уровне Capabilities

Инструментарий аудита: systemd-analyze security

Прежде чем возводить стены, нужно понять, насколько они сейчас «картонные». В systemd встроен мощный инструмент для аудита безопасности.

Команда systemd-analyze security <service_name> проверяет различные настройки сервиса, связанные с безопасностью, назначая каждому из них числовое значение «уровня подверженности» (Exposure), в зависимости от того, насколько важна настройка. Затем он рассчитывает общий уровень воздействия для всего сервиса, который является оценкой в диапазоне 0.0 (идеально)...10.0 (небезопасно), указывающей на то, насколько уязвима служба с точки зрения безопасности.

При работе с результатами анализа важно избегать ложных выводов. Высокий показатель подверженности не является автоматическим подтверждением наличия активной дыры в безопасности. Это лишь индикатор того, что служба имеет избыточные права.

Ключевые аспекты глубокого анализа:

  • Комплексность защиты: многие настройки песочницы можно обойти, если они не используются в связке. Например, если сервис сохраняет права на монтирование, он может сам отменить ограничения файловой системы.
  • Границы изоляции: настройки ограничивают только код самого сервиса. Если у приложения есть доступ к IPC (например, D-Bus), оно может запросить выполнение операций у других, менее защищенных служб. Любой анализ будет неполным, если политика доступа IPC не подтверждена.
  • Эшелонированная оборона: важно использовать максимально строгий набор настроек, где каждый параметр страхует предыдущий.

Apache: Минимализм и жесткие границы

Apache часто становится «входной дверью» для злоумышленников. Наша задача — сделать эту дверь максимально узкой и закрытой.

Глубокое управление доступом к данным

Мы реализуем принцип «белого списка» для файловой системы:

  • ProtectSystem=strict: этот параметр монтирует всю операционную систему в режиме Read-Only для сервиса.
  • NoExecPaths=/: радикальная мера безопасности, запрещающая запуск любых исполняемых файлов во всей системе.
  • ExecPaths: мы открываем точечные «форточки» в предыдущем запрете, разрешая запуск только самого исполняемого файла Apache, интерпретатора sh и минимального набора утилит (id, rm), необходимых для работы apache2ctl.
  • InaccessiblePaths=/dev/shm: закрытие доступа к разделяемой памяти предотвращает запуск эксплойтов через общие сегменты памяти.
  • ReadWritePaths: весь системный раздел остается неизменным, кроме папок для логов и PID-файлов, куда Apache обязан вносить данные

Безопасность памяти и вызовов

  • MemoryDenyWriteExecute=yes: запрещает создание областей памяти, одновременно доступных для записи и исполнения. Это эффективно блокирует атаки типа «переполнение буфера».
  • SystemCallFilter=@system-service: разрешает только стандартный, безопасный набор вызовов для системных служб.
  • SystemCallFilter=~memfd_create: тильда (~) означает запрет. Мы блокируем создание анонимных файлов в памяти, что часто используется вредоносным программным обеспечением для скрытного присутствия.
  • CapabilityBoundingSet: даже если Apache работает от имени root, мы отбираем у него права, оставляя лишь критически важные: смену владельца (CHOWN), обход прав (DAC_OVERRIDE) и привязку к портам (NET_BIND_SERVICE)

1С:Предприятие: Изоляция «тяжелого» сервиса

Для 1С требуется более гибкий подход из-за использования JIT-компиляции и сложного взаимодействия между процессами (ragent, rmngr, rphost).
Особенности настройки для 1С:

  • MemoryDenyWriteExecute=no: вынужденное послабление, необходимое для работы JIT-компилятора 1С. Этот риск компенсируется жестким ограничением путей через NoExecPaths.
  • Расширенный фильтр вызовов: используется детальный список групп (@ipc, @process, @memlock, @signal, @timer) для обеспечения взаимодействия между компонентами кластера.
  • Микросегментация сети: вместо того чтобы полагаться только на внешний Firewall, мы ограничиваем сервис внутри systemd: 
       - SocketBindDeny=any: блокируем всё.
        - SocketBindAllow=tcp(udp): разрешаем только рабочие порты 1С.

Общие механизмы «песочницы» (Namespaces)

Для обоих сервисов создается персональная «виртуальная реальность»:

  • PrivateDevices=yes: процесс не видит физические диски, только базовые виртуальные устройства.
  • PrivateTmp=yes: изолированная папка /tmp, отделенная от системной.
  • ProtectProc=invisible: процесс не видит других пользователей и программ в системе.
  • ProtectHome=yes: полный запрет доступа к /home и /root.
  • UMask=0077: все созданные сервисом файлы будут доступны только ему самому.

Сводная таблица параметров и обоснование для ИБ

Эта таблица является ключевым аргументом для специалистов по информационной безопасности, объясняющим, зачем нужна каждая конкретная строка в конфигурации.


Параметр Обоснование для ИБ-специалиста Цель настройки
User/Group=… Принцип наименьших привилегий (PoLP) Исключение запуска от root. Взлом процесса не дает прав суперпользователя
ProtectSystem=strict Монтирование всей ОС (/usr, /bin, /lib) в режиме ReadOnly Защита от модификации бинарных файлов и внедрения Rootkit-ов
NoExecPaths=/ Запрет исполнения кода из любой точки ФС Блокировка запуска произвольных скриптов, загруженных в /tmp или /var
ReadWritePaths=... Белый список путей с правами записи Ограничение области повреждения данных (Blast Radius) рабочими папками
ExecPaths=... Явное разрешение запуска конкретных исполняемых файлов Whitelisting кода. Запрещает запуск gcc, python, nc, perl и инструментов атаки
CapabilityBoundingSet=... Ограничение возможностей процесса (POSIX capabilities) Удаление опасных прав (доступ к дискам, управление сетью)
NoNewPrivileges=yes Контроль SUID-переходов Запрет на повышение привилегий через сторонние исполняемые файлы
SystemCallArchitectures=native Блокировка вызовов других архитектур Защита от эксплойтов, использующих "переход" между x32 и x64
SystemCallFilter=... Фильтрация системных вызовов (seccomp) Ядро запрещает вызовы mount, reboot, ptrace и другие нецелевые функции
PrivateDevices=yes Изоляция от /dev/. Процесс не видит физические диски Защита от прямого чтения данных с носителей или перехвата ввода-вывода
PrivateTmp=yes Уникальная, пустая папка /tmp для сервиса Защита от атак через временные файлы и предотвращение утечки данных
ProtectHostname=yes Запрет изменения имени хоста Предотвращение манипуляций с сетевой идентификацией сервера
ProtectKernelModules=yes Запрет на загрузку модулей ядра Блокировка попыток внедрения на уровень ядра и сокрытие следов взлома
ProtectProc=invisible Ограничение видимости других процессов в /proc Защита от сбора информации о других сервисах в системе
LockPersonality=yes Запрет изменения домена исполнения (personality) Защита от эмуляции других ОС, используемой в сложных эксплойтах
MemoryDenyWriteExecute=no Вынужденная мера для 1С 1С использует JIT. Разрешено, но компенсировано через NoExecPaths
RestrictAddressFamilies=... Белый список сетевых протоколов Запрет экзотических протоколов. Оставлены только TCP/UDP и Netlinks
RestrictNamespaces=yes Запрет создания контейнеров внутри процесса Предотвращение атак типа "Container breakout"
RestrictRealtime=yes Запрет планировщика реального времени Защита от DoS-атак: процесс не сможет "повесить" CPU
RestrictSUIDSGID=yes Запрет на создание файлов с битами SUID/SGID Исключает создание "черных ходов" для повышения прав
SocketBindDeny/Allow Запрет на создание файлов с битами SUID/SGID Исключает создание "черных ходов" для повышения прав

Практическая реализация и результаты 

Для достижения максимального уровня защиты мы объединяем все разобранные параметры в итоговые конфигурационные файлы (drop-in unit files).

Итоговая конфигурация для Apache
(/etc/systemd/system/apache2.service.d/hardening.conf)

[Service]
# Реализация «белого списка» для файловой системы:
#
InaccessiblePaths=/dev/shm
NoExecPaths=/
ExecPaths=/bin/sh /usr/bin/id /usr/bin/rm /usr/sbin/apache2 /usr/sbin/apachectl /usr/sbin/apache2ctl /usr/lib/apache2 /usr/lib
# Для корректой работы веб-сервисов 1С
#
ExecPaths=/opt/1cv8/x86_64/8.3.24.1342 /usr/sbin/ldconfig /sbin/ldconfig.real /usr/bin/awk /usr/bin/sort /usr/bin/sed
ReadWritePaths=/var/log/apache2 /var/lock/apache2 /var/run/apache2

Mask=0077

# Безопасность памяти и вызовов
#
CapabilityBoundingSet=CAP_CHOWN CAP_DAC_OVERRIDE CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID
SystemCallArchitectures=native
SystemCallFilter=@system-service mincore
SystemCallFilter=~memfd_create
SystemCallFilter=~@clock @mount @reboot

MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
LockPersonality=yes

# Изоляция (Namespaces)
#
PrivateDevices=yes
PrivateTmp=yes
ProtectClock=yes

ProtectControlGroups=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectProc=invisible
ProtectSystem=strict
ProcSubset=pid

RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes

# Сетевые ограничения
#
SocketBindDeny=any
SocketBindAllow=tcp:80
SocketBindAllow=tcp:443
SocketBindAllow=udp:443

Итоговая конфигурация для 1С:Предприятие (/etc/systemd/system/srv1cv8-8.3.24.1342@2141.service.d/hardening.conf)

Конфигурация адаптирована под специфику работы кластера 1С: 

[Unit]
Description=1C:Enterprise Server 8.3 (8.3.24.1342) 2141 (%I)
[Service]

# Задаем переменные для отдельного сервис 1С
Environment=SRV1CV8_DATA=/home/usr_1c_21/.1cv8/1C/1cv8
Environment=SRV1CV8_PORT=2140
Environment=SRV1CV8_REGPORT=2141
Environment=SRV1CV8_RANGE=2160:2191
Environment=SRV1CV8_DEBUG=-debug

# Определяем Java
Environment=JAVA_HOME=/usr/lib/jvm/bellsoft-java11-runtime-full-amd64

 # Переопределяем пользователя по-умолчанию
User=usr_1c_21
Group=grp1cv8

# Реализация «белого списка» для файловой системы:
#
ProtectSystem=strict
NoExecPaths=/
ReadWritePaths=/var/1C /home/usr_1c_21/.1cv8 /tmp
# Разрешаем запуск основных процессов 1С ragent rmngr dbda rphost и исполняемых файлов
ExecPaths=/opt/1cv8/x86_64/8.3.24.1342
# Разрешаем запуск java
ExecPaths=/usr/lib/jvm/bellsoft-java11-runtime-full-amd64
# Разрешаем запуск утилит необходимых для 1С
ExecPaths=/bin/sh /usr/bin/awk /usr/bin/sort /usr/bin/sed /sbin/ldconfig /sbin/ldconfig.real /usr/bin/wc /usr/bin/grep /usr/bin/fc-list
ExecPaths=/lib/x86_64-linux-gnu

UMask=0077
 
# Безопасность памяти и вызовов
#
CapabilityBoundingSet=CAP_SYS_RESOURCE CAP_NET_BIND_SERVICE CAP_CHOWN CAP_SETGID CAP_SETUID
NoNewPrivileges=no
LockPersonality=yes
SystemCallArchitectures=native
MemoryDenyWriteExecute=no
SystemCallFilter=@system-service @ipc @process @memlock @signal @timer
SystemCallFilter=prlimit64 mincore fallocate flock getdents getdents64 fstatfs

# Изоляция (Namespaces)
#
PrivateDevices=yes
PrivateTmp=yes
ProtectHostname=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectControlGroups=yes
ProtectKernelLogs=yes
ProtectProc=default
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes

# Сетевые ограничения
#
SocketBindDeny=any
# Разрешаем tcp ragent
SocketBindAllow=ipv4:tcp:2140
# Разрешаем tcp rmngr
SocketBindAllow=ipv4:tcp:2141
# Разрешаем tcp rphost
SocketBindAllow=ipv4:tcp:2160-2191
# Разрешаем udp ragent
SocketBindAllow=ipv4:udp:2140
# Разрешаем udp rmngr
SocketBindAllow=ipv4:udp:2141
# Разрешаем udp rphost
SocketBindAllow=ipv4:udp:2160-2191

Самым убедительным доказательством успешного Hardening-а является изменение рейтинга безопасности в сервисе.

Состояние «До» (сервис из коробки)

При стандартной установке Apache или 1С результат systemd-analyze security обычно выглядит пугающе:

7-1 Изолированная крепость (1).png

7-2 Изолированная крепость (1).png

  • Оценка: 9.2 / 10 (небезопасно)
  • Статус: Сервис имеет полный доступ к /dev, может видеть все процессы в системе, изменять параметры ядра и выполнять любые системные вызовы. В случае взлома злоумышленник получает практически неограниченный плацдарм для атаки на всю ОС.

Состояние «После»

После применения наших конфигураций картина радикально меняется:

7-3 Изолированная крепость (1).png

7-4 Изолированная крепость (1).png

  • Оценка: 2.5-2.8 / 10 (OK / Безопасно)
  • Статус: Большинство индикаторов сменились на позитивные иконки. Сервис теперь ограничен в правах, не видит соседей по системе, лишен возможности исполнять сторонний код и надежно заперт в рамках своих рабочих каталогов.

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

Использование systemd-analyze security в сочетании с глубокой настройкой юнитов — это современный стандарт администрирования Linux, который должен стать обязательным для любой промышленной инсталляции 1С или веб-сервисов.

Обеспечение информационной безопасности является критически важным для любой ИТ-структуры. Если вы хотите узнать больше о современных инструментах и подходах к информационной безопасности или вы готовы предложить тему для обсуждения, напишите нам на corp@1c-prem.ru. Будем рады, если в итоге нашего разговора появится новая статья или интересная тема для вебинара.



Назад