Журнал "Information Security/ Информационная безопасность" #2, 2026

В инфраструктуре могут одновременно существовать разные дистрибутивы, ядра и версии системных библио- тек, что сильно усложняет работу по защите конечных точек. Linux все чаще использу- ется в контейнерных и облачных средах, где нужно понимать контекст не только хоста, но и каждого контей- нера и оркестратора. Остаются незамеченны- ми Fileless-атаки, использо- вание вредоносных скрип- тов и угрозы типа Lateral Movement (горизонтальное перемещение). Долгие годы корпора- тивные системы строи- лись вокруг Windows- парадигмы, и подавляю- щее большинство реше- ний по кибербезопасно- сти разрабатывались под этот стек. Но теперь уже Linux все чаще ста- новится основной платформой как для серверов, так и для рабочих станций, и компании сталкиваются с нехваткой зре- лых средств защиты именно для Linux-систем. По данным BI.ZONE EDR и BI.ZONE TDR, около 90% ком- паний, у которых в инфраструк- туре есть операционные систе- мы на базе Linux, не являю- щиеся ГИС или ОКИИ, не соблюдают как минимум одно требование из нашего стандар- та защищенной системы. Этот стандарт сформулирован на основе рекомендаций ФСТЭК России и производителей ПО, а также с учетом опыта команд BI.ZONE, которые сталкиваются с расследованием кибератак. В рамках мониторинга было зафиксировано, что лишь 8% компаний, имеющих ОС Linux в инфраструктуре, соблюдают все требования, 44% не соблюдают от одного до трех требований и 48% не соблюдают четыре и более требований. Давайте разберем, какие про- блемы возникают при защите конечных точек в Linux-среде и что должно уметь современ- ное EDR-решение, чтобы обес- печить безопасность ИТ-инфра- структуры. Проблема защиты конечных точек на Linux Создать надежную систему защиты для Linux непросто. Это связано с несколькими причи- нами. Во-первых, приходится рабо- тать в сильно разнородной и динамичной среде. В отличие от Windows, где высокая сте- пень унификации, системам на Linux свойственна сильная волатильность. В инфраструк- туре могут одновременно суще- ствовать разные дистрибутивы, ядра и версии системных биб- лиотек, что сильно усложняет работу по защите конечных точек. Во-вторых, при сборе низко- уровневой телеметрии возни- кают технические ограничения. Стандартные механизмы мони- торинга, такие как auditd, часто значительно влияют на про- изводительность системы. А современные технологии, например eBPF, требуют свежих ядер. В большинстве же инфра- структур есть старые версии ОС, обновление которых по раз- ным причинам невозможно. В них eBPF неприменим. Поэто- му такой метод не позволит собирать события со 100% систем. В-третьих, Linux все чаще используется в контейнерных и облачных средах, где нужно понимать контекст не только хоста, но и каждого контейнера и оркестратора. Кроме того, EDR-решение должно покрывать уникальные техники атак, специфичные для Linux и Cloud Native. В таких средах злоумышленники неред- ко используют легитимные ути- литы системы (bash, cron, ssh, systemd) для закрепления, гори- зонтального перемещения и маскировки следов. В контей- нерных инфраструктурах атаки могут развиваться за секунды: от компрометации образа до побега из контейнера и доступа к оркестратору. Поэтому EDR- решение должно уметь анали- зировать действия не только на уровне хоста, но и в контекс- те контейнера – его сетевую активность, взаимодействие с API Kubernetes, обращение к образам и реестрам. Контейнеры и средства мониторинга Использование контейнеров и микросервисных архитектур значительно усложняет задачи мониторинга и расследования инцидентов. Контейнеры делят одно ядро операционной систе- мы, из-за чего становится слож- но понять, где именно произош- ло подозрительное действие – внутри контейнера или на уров- не хоста. Из-за этого трудно построить точную картину атаки и определить границы компро- метации. Кроме того, без использова- ния оркестратора практически невозможно контролировать конфигурации контейнеров и управлять безопасностью на уровне их жизненного цикла. Контейнеры запускаются и завершаются динамически, что делает классические меха- низмы инвентаризации и аудита неэффективными. Отдельный важный риск – короткоживущие контейнеры: угроза может исчезнуть вместе с контейнером до того, как ее заметят. В логах и на диске такие эпизоды часто почти не оставляют следов. Наконец, остаются незаме- ченными Fileless-атаки, исполь- зование вредоносных скриптов и угрозы типа Lateral Movement (горизонтальное перемеще- ние). Защита контейнерных сред с помощью EDR Некоторые современные EDR-решения научились учи- тывать специфику контейнер- ных и облачных окружений, обеспечивая видимость и конт- роль там, где традиционные средства мониторинга бес- сильны. EDR обеспечивает привязку событий к конкретным контей- нерам и контексту оркестрации. Система фиксирует не просто факт запуска процесса, напри- мер curl или bash, а указывает, в каком контейнере и в каком поде это произошло: "Процесс curl запущен в контейнере nginx:1.25, namespace frontend, deployment webapp, service account default". 48 • СПЕЦПРОЕКТ Что должен уметь EDR для российских ОС се больше и больше российских компаний и государственных структур переходят на отечественные операционные системы – Astra Linux, РЕД ОС, ОС “Альт”. Этот переход предписан нормативными документами, но он несет с собой новые техно- логические вызовы в аспекте информационной безопасности. В Иван Рогалёв, руководитель BI.ZONE EDR Фото: BI.ZONE