Сервер 1С под Linux: потерян доступ, как вернуть его законно и закрыть лишнее

Запрос «как взломать 1С на Linux» почти всегда означает одно из двух: забыт пароль администратора или не получается подключиться к серверу . Обходить защиту незачем. Для обеих ситуаций есть законные способы вернуть доступ, и о них ниже.

Взламывать 1С на Linux незаконно и опасно: «активаторы» и подменённые библиотеки содержат закладки, а нарушение лицензионных условий грозит ответственностью. Если нужен доступ к своей базе, идите через резервную копию, права владельца сервера и поддержку партнёра. Эту схему разберём по шагам: как устроен сервер, где хранятся права, какие порты открыть, как работать с rac и как закрыть доступ чужим.

Как устроена безопасность 1С на Linux

Сервер 1С на Linux не требует отдельной «админки». Его составляют несколько процессов, и у каждого своя роль.

• 🔹 ragent — агент сервера. Запускается как служба, принимает подключения и поднимает остальные процессы.
• 🔹 rmngr — менеджер кластера. Хранит список баз, сеансов и блокировок.
• 🔹 rphost — рабочие процессы. Именно они выполняют код конфигурации.
• 🔹 ras — сервер администрирования. Через него работают консоль и утилита rac.

Служба работает не от root. Стандартный пакет создаёт пользователя usr1cv8 и группу grp1cv8. Платформа лежит в каталоге вида /opt/1cv8/x86_64/<номер версии>/. Служба называется srv1cv8 в стандартной установке, а при нескольких версиях платформы обычно появляется отдельный сервис под каждую.

В 1С действуют три независимых уровня доступа. Путают их постоянно.

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

Легальное восстановление доступа администратора

Начинайте с самого безопасного. Вернуть доступ к своей базе можно тремя путями, от простого к трудоёмкому.

Шаг 1. Проверить, есть ли другой администратор

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

Попросите коллег проверить, не работает ли кто-то в базе сейчас под полными правами. Нужная учётная запись иногда лежит в соседней базе-копии, и пароль известен.

Шаг 2. Поднять копию из резервной копии

Если полных прав нет ни у кого, поднимите проверенную копию базы на тестовом сервере. Для файловой базы это копия каталога с 1Cv8.1CD. Для клиент-серверной — восстановление из .dt или из бэкапа СУБД.

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

Шаг 3. Обратиться к владельцу лицензии и партнёру

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

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

Сетевой доступ и порты: что открывать, а что нет

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

Основные порты кластера по умолчанию:

Клиентам нужен доступ как минимум к 1540, 1541 и диапазону рабочих процессов. Порт 1545 нужен только администраторам. Наружу его открывать нельзя.

Проверьте, слушает ли сервер нужные порты:

ss -tlnp | grep -E '154[0-9]|15[6-9][0-9]'

Если порты видны локально, а с рабочего места не открываются, смотрите межсетевой экран. Для ufw команды такие:

sudo ufw allow from 192.168.10.0/24 to any port 1540:1541 proto tcp
sudo ufw allow from 192.168.10.0/24 to any port 1560:1591 proto tcp

Подсеть замените на свою. Правило «разрешить всем» на эти порты оставлять нельзя: кластер превращается в мишень для перебора паролей.

Консоль администрирования rac

Утилита rac — командный клиент к серверу администрирования. На Linux это обычный способ управлять кластером без графической консоли.

Сначала запустите ras. Он работает отдельным процессом:

/opt/1cv8/x86_64/8.3.xx.xxxx/ras cluster --daemon

Номер версии подставьте свой: он совпадает с каталогом платформы. Затем проверьте связь и получите идентификатор кластера:

/opt/1cv8/x86_64/8.3.xx.xxxx/rac localhost:1545 cluster list

В выводе будет строка cluster с UUID. Он нужен во всех следующих командах.

Что делают самые частые команды:

1. rac cluster list — показать кластеры сервера.
2. rac infobase summary list --cluster=<UUID> — перечислить информационные базы.
3. rac session list --cluster=<UUID> — посмотреть открытые сеансы.
4. rac session terminate --cluster=<UUID> --session=<UUID сеанса> — завершить зависший сеанс.
5. rac cluster admin list --cluster=<UUID> — показать администраторов кластера.

Если у кластера уже есть администраторы, команды потребуют --cluster-user и --cluster-pwd. Это нормально: утилита не пускает без аутентификации, и обходить её не надо.

Новый администратор кластера создаётся так:

rac cluster admin register --cluster=<UUID> --name=admin2 --pwd=<пароль> --auth=pwd

Пароль не оставляйте в истории оболочки. Передавайте его из защищённого файла или вводите в интерактивном сеансе.

Служба на сервере: проверка перед разбором доступа

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

systemctl status srv1cv8
journalctl -u srv1cv8 --since "1 hour ago"
ps -u usr1cv8 -o pid,rss,cmd | grep -E 'ragent|rmngr|rphost'

Первая показывает состояние службы. Вторая выводит записи системного журнала: там видны отказы запуска и нехватка прав на каталоги. Третья показывает процессы кластера и объём занятой ими памяти.

Если rphost растёт в памяти до нескольких гигабайт и сервер уходит в своп, пользователи жалуются на «зависания», хотя пароли тут ни при чём. Жалобу на «нет доступа» стоит сверять с нагрузкой, прежде чем менять права.

После изменения настроек сети или прав перезапускайте службу вне рабочих часов: все сеансы на этот момент разорвутся.

Журналы регистрации и техжурнал: где искать причину

Когда вход не проходит, ответ почти всегда есть в журналах. Их два, и они разные.

Журнал регистрации живёт внутри базы. Откройте его в режиме 1С:Предприятие: Администрирование → Поддержка и обслуживание → Журнал регистрации. Там видны входы, неудачные попытки аутентификации, изменения пользователей и ролей. Фильтруйте по событию «Сеанс» и по пользователю.

Технологический журнал пишется на сервере в файлы. Включается он файлом logcfg.xml в каталоге conf платформы. Минимальный пример для событий исключений:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="/var/log/1c/techlog" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

Каталог из location должен быть доступен на запись пользователю usr1cv8. Параметр history задаёт, сколько часов хранить файлы. Иначе журнал за неделю займёт весь диск.

Что искать в техжурнале при проблемах с входом:

• 🔎 EXCP — исключения с текстом ошибки;
• 🔎 CONN — подключения клиентов и их разрыв;
• 🔎 SDBL — обращения к базе данных, полезно при долгих запросах.

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

Защита сервера 1С от несанкционированного доступа

Законный способ «не быть взломанным» складывается из мелочей. Ниже порядок, который стоит пройти на каждом сервере.

Сеть и учётные записи

1. Откройте порты 1540, 1541, 1560–1591 только для внутренней подсети или VPN.
2. Порт 1545 и ras оставьте для адресов администраторов, остальным закройте.
3. Для администрирования ОС используйте ключи SSH, вход по паролю отключите.
4. Не запускайте службу 1С от root: ей хватает usr1cv8.

Права в самой 1С

• 👤 Роль «Полные права» — только двум-трём людям, у каждого своя учётная запись.
• 👤 Не давайте пользователям общий логин «Администратор» без пароля.
• 👤 Для рядовых сотрудников включайте только нужные роли.
• 👤 Заведите отдельную учётную запись для обмена и для интеграций, с минимальными правами.

Обновления и резервные копии

Платформу обновляйте до актуального релиза из линейки 8.3: в новых версиях закрывают уязвимости. Перед обновлением сделайте копию и проверьте её восстановление.

Копия, которую не пробовали разворачивать, не считается копией. Раз в квартал поднимайте её на тестовом сервере и проверяйте, что вход работает.

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