Как проверить защищённость 1С на Linux: аудит уязвимостей

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

Несанкционированный доступ к чужим информационным системам — уголовно наказуемое деяние (в России это статьи 272–274 УК РФ). Любые проверки выполняйте только на своём оборудовании, на тестовых стендах или по письменному договору с владельцем системы. Сканирование чужих серверов, даже «из любопытства», уже может квалифицироваться как правонарушение.

Типовая связка «1С на Linux» — это сервер 1С:Предприятия, СУБД (чаще PostgreSQL, реже MS SQL в контейнере или Oracle) и веб-сервер Apache или nginx для публикации тонкого клиента и веб-сервисов. У каждого звена свои типовые слабые места, и аудит стоит строить по слоям: сеть, операционная система, СУБД, сервер 1С, прикладной уровень.

С каких векторов чаще всего «вскрывают» 1С на Linux

Практика показывает, что реальные компрометации редко связаны с экзотическими уязвимостями платформы. Чаще всего используются банальные просчёты: порт СУБД, доступный из интернета; пароль администратора кластера, совпадающий с паролем пользователя ОС; веб-публикация без TLS и с включённой отладкой; учётная запись postgres с заводским паролем.

Второй класс векторов — прикладной: пользователи 1С с пустыми или словарными паролями, отсутствие ограничения по времени и адресам входа, включённый режим отладки на рабочем сервере (он позволяет подключиться конфигуратором к чужому сеансу при наличии доступа к кластеру), права «Администрирование» у рядовых сотрудников.

Проверка сетевого периметра

Начните с того, что видит потенциальный атакующий: какие порты слушает сервер и кому они доступны. На самом сервере список открытых сокетов покажет команда ss -tulpn. Снаружи — сканирование с контролируемой машины, например nmap -sV адрес_сервера. Разница между двумя картинками покажет, что реально доступно из сети, а что закрыто межсетевым экраном.

Минимально необходимый набор снаружи — обычно только 443/tcp (веб-доступ) и при необходимости SSH с ограничением по адресам. Порты агента сервера 1С (1540), менеджера кластера (1541) и рабочих процессов (диапазон 1560–1591 по умолчанию) должны быть доступны только тем машинам, где работают клиенты и веб-сервер. Порт PostgreSQL (5432) — только localhost или серверу 1С.

ss -tulpn | grep -E '1540|1541|5432' && sudo iptables -L -n -v

Если база файловая и опубликована через веб-сервер — проверьте, что каталог с файлом 1Cv8.1CD недоступен для прямого скачивания по URL. Это одна из самых обидных утечек: вся база уходит одним запросом.

Аудит учётных записей и паролей

На уровне 1С выгрузите список пользователей и проверьте: есть ли учётные записи без паролей, используется ли аутентификация ОС там, где она не нужна, совпадают ли имена с типовыми (Администратор, Admin, 1c). Подбор пароля к веб-доступу или тонкому клиенту — самый массовый сценарий атаки, поэтому включите в настройках информационной базы требования к сложности пароля и ограничение на число неудачных попыток, если версия платформы это поддерживает.

На уровне Linux проверьте, под какими учётными записями работают службы: агент сервера 1С обычно работает от пользователя usr1cv8, PostgreSQL — от postgres. У этих учётных записей не должно быть интерактивного входа в систему (shell /usr/sbin/nologin), а их пароли не должны использоваться где-либо ещё. Отдельно проверьте /etc/shadow на предмет пустых паролей и учётных записей с UID 0, кроме root.

Проверка СУБД и хранилища данных

PostgreSQL — самая частая СУБД в связке с 1С на Linux. Проверьте файл pg_hba.conf: методы аутентификации должны быть scram-sha-256 (или хотя бы md5 на старых версиях), а не trust. Строки вида host all all 0.0.0.0/0 trust означают, что база доступна любому без пароля — это критическая находка.

Убедитесь, что listen_addresses в postgresql.conf ограничен localhost или адресом сервера 1С, а не звёздочкой. Проверьте, кто владеет каталогом данных и файлами резервных копий: бэкапы, лежащие с правами чтения для всех или на общем сетевом ресурсе без ограничений, — готовый источник утечки всей базы, включая персональные данные сотрудников.

Настройки сервера 1С и веб-публикации

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

Для веб-публикаций убедитесь, что: включён TLS (работа по HTTP передаёт пароли открытым текстом), в файле default.vrd отключены неиспользуемые сервисы (каждый опубликованный веб-сервис — потенциальная точка входа), а доступ к публикации ограничен по адресам, если она нужна только внутренним сотрудникам. Проверьте также, что в конфигурации не осталось включённым «безопасный режим»-обход для внешних обработок — запуск произвольных epf-файлов на сервере эквивалентен выполнению кода.

Журналирование и обнаружение вторжения

Аудит бесполезен без способа заметить атаку в моменте. Включите технологический журнал 1С с записью событий аутентификации и исключений, настройте сбор логов PostgreSQL (log_connections, log_failed logins) и системного журнала (journald, /var/log/auth.log) в централизованное хранилище или хотя бы с регулярным просмотром.

Признаки возможной компрометации: неудачные входы подряд под разными именами, сеансы 1С в нерабочее время, новые учётные записи в ОС или в списке пользователей базы, изменённые файлы публикации, неожиданный рост исходящего трафика с сервера СУБД. Любой из этих признаков — повод для расследования, а не для откладывания.

Что делать с найденными уязвимостями

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

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

1. 1
   Сделайте резервную копию базы и конфигурационных файлов
2. 2
   Просканируйте порты снаружи и изнутри, сопоставьте результаты
3. 3
   Проверьте pg_hba.conf, listen_addresses и права на каталог данных
4. 4
   Проверьте пароли администраторов кластера, базы и ОС
5. 5
   Отключите отладку, лишние публикации и неиспользуемые сервисы
6. 6
   Включите журналирование входов и настройте регулярный просмотр логов
7. 7
   Повторите сканирование и убедитесь, что лишнего больше не видно

Частые вопросы