Публикация 1С на веб-сервере: открыт ли OData без пароля
Публикация 1С на веб-сервере нужна для веб-клиента, удалённых сотрудников и обменов через OData и HTTP-сервисы. Неприятность в том, что такая публикация может отдавать данные базы любому, кто знает адрес, а снаружи это не видно: в браузере по-прежнему открывается форма входа. Разбираем, откуда берётся открытая публикация, как проверить её одним запросом curl и что держать на постоянном мониторинге.
Почему публикация 1С может быть открыта без пароля?
Базу публикуют из конфигуратора («Администрирование → Публикация на веб-сервере») или утилитой webinst. На веб-сервере появляется каталог публикации с файлом default.vrd, а в нём строка подключения к базе — атрибут ib, например Srvr="srv1c";Ref="buh";.
Первая причина открытой публикации — логин и пароль в этой строке. Для обменов в неё нередко дописывают параметры Usr и Pwd пользователя 1С, чтобы внешней системе не нужно было авторизоваться самой. С этого момента веб-сервер подключается к базе от имени этого пользователя на любой запрос, в том числе анонимный.
Вторая — публикуется больше, чем нужно. Флажок «Публиковать стандартный интерфейс OData» включает адрес …/odata/standard.odata/, а элемент httpServices с publishByDefault="true" публикует все HTTP-сервисы конфигурации, в том числе те, про которые администратор не знает. Обмен настроили, потом забыли, а адрес живёт годами.
Третья — HTTP без шифрования. Если публикация отвечает на 80-м порту без перенаправления на https, логин и пароль Basic-авторизации уходят по сети открытым текстом: base64 — это кодировка, а не шифрование.
Все элементы default.vrd описаны в руководстве администратора 1С:Предприятия, в приложении о служебных файлах.
Почему форма входа в браузере ничего не доказывает?
Самая частая ошибка проверки — открыть адрес публикации в браузере, увидеть окно авторизации и успокоиться. Корень публикации веб-клиент отдаёт с кодом 200 всегда: страница загружается целиком, а вход происходит позже, уже в браузере. По такому ответу нельзя понять, защищена ли база.
Проверять нужно адреса, которые отвечают программам: стандартный интерфейс OData и конкретные HTTP-сервисы. Именно через них данные уходят без всякого интерфейса — списком справочников и документов.
Как проверить OData 1С без авторизации?
Достаточно одного анонимного запроса к стандартному интерфейсу:
curl -s -o /dev/null -w "%{http_code}\n" https://1c.example.ru/buh/odata/standard.odata/
Как читать ответ:
— 401 (обычно с заголовком WWW-Authenticate: Basic) или 403 — без пароля не пускают, это норма;
— 200 и в теле список сущностей вида Catalog_… и Document_… — данные открыты любому, кто знает адрес;
— 404 — OData в этой публикации не опубликован;
— 500 — ошибка 1С или веб-сервера (нет лицензии, база недоступна): про пароль это ничего не говорит, но разобраться стоит.
То же самое повторите для каждого HTTP-сервиса, который опубликован: https://1c.example.ru/buh/hs/exchange/ping и так далее. Корневые адреса сервисов видны в конфигураторе (Общие → HTTP-сервисы, свойство «Корневой URL») и в default.vrd.
Два условия, без которых проверка врёт. Запрос должен идти снаружи — из сети без вашего VPN и доменной авторизации, иначе может сработать аутентификация ОС. И строго без учётных данных: без логина в адресе вида https://user:pass@…, без ~/.netrc и без сохранённых паролей в инструменте, которым проверяете. Иначе вы получите 200 и решите, что всё открыто, — или наоборот.
Как проверить, что публикация 1С не работает по HTTP?
Тот же адрес OData, но по http://:
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" http://1c.example.ru/buh/odata/standard.odata/
Правильный ответ — 301, 302 или 308 с переходом на https. Если пришли 401 или 200, публикация принимает запросы без шифрования, и пароль интеграции можно перехватить по пути. Смотрите именно путь OData, а не корень сайта: на 80-м порту часто стоит сайт по умолчанию со страницей «It works!» или 404, к публикации он отношения не имеет.
Как закрыть публикацию 1С
— Уберите Usr и Pwd из атрибута ib в default.vrd. Для внешней системы заведите отдельного пользователя 1С с минимальной ролью и передавайте логин в каждом запросе.
— Публикуйте только нужное: снимите флажок OData, если им никто не пользуется; у httpServices поставьте publishByDefault="false" и включайте сервисы по одному элементами service.
— Для интеграций сделайте отдельную публикацию и ограничьте её по IP на веб-сервере: Require ip в Apache, «Ограничения IP-адресов и доменов» в IIS.
— Включите https и перенаправление с 80-го порта; срок сертификата поставьте на контроль — как это сделать, мы разбирали в статье про мониторинг SSL-сертификатов.
— После правки перезапустите веб-сервер и повторите оба запроса curl.
Почему одной проверки мало?
Публикация меняется чаще, чем кажется. Её переопубликовали из конфигуратора после обновления платформы — default.vrd сгенерирован заново. Подрядчик добавил HTTP-сервис для обмена с сайтом. Базу перенесли на новый сервер и скопировали старый каталог публикации. Каждый раз защита может слететь, и узнаете вы об этом не от мониторинга, а от того, кто нашёл открытый адрес.
Поэтому проверку стоит запускать по расписанию снаружи и поднимать алерт: открыто без пароля — critical, работает по http без перенаправления — warning. Вместе с доступностью публикации это часть мониторинга 1С наравне с сеансами, лицензиями и rphost.
Что проверить у себя
— Составьте список всех публикаций: каталоги с default.vrd на всех веб-серверах, включая старые и тестовые.
— В каждом default.vrd проверьте атрибут ib — нет ли в нём Usr и Pwd.
— Сделайте анонимный запрос снаружи к …/odata/standard.odata/ — ожидается 401 или 403.
— Повторите запрос к каждому опубликованному hs/… сервису.
— Проверьте, что http:// отвечает перенаправлением на https.
— Посмотрите publishByDefault у httpServices и решите, нужен ли OData вообще.
— Убедитесь, что проверка стоит в расписании и шлёт алерт, а не делается раз в год.
Можно ли оставить OData открытым, если адрес никто не знает?
Нет. Имена публикаций типовые (buh, zup, ut, base), поддомены вида 1c. видны в публичных журналах сертификатов, а автоматические сканеры проверяют типовые пути на всех доступных хостах подряд. Защищают пароль и ограничение по IP, а не неизвестный адрес.
Почему HTTP-сервис 1С отвечает без авторизации?
Чаще всего в строке подключения default.vrd прописаны Usr и Pwd, и веб-сервер входит в базу от этого пользователя на любой запрос. Проверить легко: найдите запрос к сервису в журнале регистрации и посмотрите, от какого пользователя открыт сеанс. Если это пользователь из default.vrd, а не тот, кто вызывал сервис, — причина найдена.
Как часто проверять публикацию 1С?
Раз в час достаточно: публикация меняется редко, а один запрос в час не создаёт нагрузки. Важнее другое — проверка должна идти снаружи, без учётных данных, и заканчиваться алертом дежурному, а не строкой в отчёте.
Как это сделано в Voltir
В разделе порталов можно добавить запись типа «Публикация 1С»: платформа следит за доступностью адреса и раз в час делает один анонимный GET без учётных данных и без перехода по редиректам — к …/odata/standard.odata/, к указанному вами пути hs/… и к тому же OData по http://. Никаких попыток входа и перебора путей; результат — метрики onec_publication_auth_required и onec_publication_plain_http и алерты OneCPublicationNoAuth (critical) и OneCPublicationPlainHttp (warning). Как поставить адрес на внешнюю проверку, описано в документации по мониторингу порталов, дашборды 1С можно посмотреть в живом демо.
Если нужно, чтобы на такие алерты реагировал дежурный, есть мониторинг как услуга; стоимость — на странице тарифов.