При публикации информационных баз 1С на веб-сервере (под управлением IIS или Apache) системные администраторы часто сталкиваются с серьезной брешью в безопасности. Настроив доступ для удаленных сотрудников через обычный интернет-браузер (Веб-клиент) и ограничив их роли в конфигурации, мы рассчитываем на то, что пользователи будут работать в строго контролируемой среде. Однако по умолчанию платформа 1С позволяет использовать адрес этой же веб-публикации для подключения через полноценный Тонкий клиент.
Пользователю достаточно прописать URL-адрес публикации вида https://server.domain.ru/base в окне запуска своего локального Тонкого клиента, чтобы подключиться к базе через веб-сервер. В консоли администрирования такое соединение будет отображаться как работа через «модуль расширения веб-сервера», но фактически пользователь получит полный интерфейс Тонкого клиента. Это создает угрозу подбора (брутфорса) паролей учетных записей с административными правами из внешней сети. Рассмотрим подробнее, как решить эту проблему и полностью заблокировать запуск Тонкого клиента через веб-протоколы, оставив доступ только пользователям с браузерами.
Этот метод является наиболее гибким и надежным, так как он работает непосредственно на уровне бизнес-логики платформы 1С. Мы можем определить тип запущенного клиентского приложения и структуру строки соединения с базой в момент авторизации пользователя. При подключении Тонкого клиента через веб-сервер строка соединения всегда содержит специфический параметр WS= (Web Service), в то время как при локальном подключении по сети (в режиме клиент-сервер) строка соединения содержит параметр Srvr=, а в файловом режиме — File=.
Разберем по шагам, как реализовать проверку в конфигурации. Для этого нам понадобится внести изменения в модуль управляемого приложения.
Выполним следующие действия:
ПередНачаломРаботыСистемы (или создадим ее, если она отсутствует).
Процедура ПередНачаломРаботыСистемы(Отказ)
#Если ТонкийКлиент Тогда
// Получаем строку соединения текущего сеанса
СтрокаСоединения = СтрокаСоединенияИнформационнойБазы();
// Переводим строку в верхний регистр для исключения ошибок ручного ввода адреса
СтрокаВВерхнемРегистре = ВРег(СтрокаСоединения);
// Проверяем наличие признака подключения через веб-сервер (параметр WS)
Если Найти(СтрокаВВерхнемРегистре, "WS=") > 0 Тогда
// Формируем сообщение для пользователя и отменяем запуск системы
ТекстПредупреждения = "Внимание! Запуск информационной базы через Тонкий клиент по веб-протоколу (HTTP/HTTPS) заблокирован администратором безопасности. Пожалуйста, используйте для работы интернет-браузер.";
ПоказатьПредупреждение(, ТекстПредупреждения);
Отказ = Истина;
Возврат;
КонецЕсли;
#КонецЕсли
КонецПроцедуры
Проанализируем работу данного алгоритма:
Srvr="server-1c";Ref="db_name";. Директива препроцессора #Если ТонкийКлиент выполняется, но проверка условия Найти(..., "WS=") возвращает 0. Доступ разрешен.#Если ТонкийКлиент вообще не отрабатывает (для них активна директива #Если ВебКлиент). Код блокировки игнорируется, и пользователи спокойно работают в браузере.ws="https://server.domain.ru/base". Система мгновенно выявляет вхождение подстроки WS=, выводит предупреждение и корректно прерывает сеанс до начала инициализации основных интерфейсов.Если мы хотим защитить базу данных от попыток подбора паролей (брутфорса), наиболее эффективным решением будет отсекать нежелательные подключения еще на подступах к платформе 1С — прямо на веб-сервере. Это сэкономит ресурсы сервера приложений и базы данных, так как запросы злоумышленников даже не дойдут до стадии авторизации в СУБД.
Для реализации этого метода мы воспользуемся тем, что любое сетевое приложение при отправке HTTP-запросов передает заголовок User-Agent, который идентифицирует программу. Обычные браузеры передают стандартные идентификаторы движков (например, содержащие слова Chrome, Gecko, Mozilla), в то время как исполняемый файл Тонкого клиента 1С (1cv8c.exe) передает специфическую строку, содержащую подстроку 1C+Enterprise (или 1cv8).
Выясним, как настроить фильтрацию этих заголовков на популярных веб-серверах.
Для фильтрации запросов в IIS нам потребуется установленный официальный модуль URL Rewrite (Служба перезаписи URL-адресов). Настроить правило можно через графический интерфейс диспетчера IIS или напрямую отредактировав конфигурационный файл web.config, который находится в папке с веб-публикацией нашей базы 1С.
Откроем файл web.config текстовым редактором и добавим в секцию <system.webServer> правила перезаписи:
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Block_1C_ThinClient" stopProcessing="true">
<match url=".*" />
<conditions>
<!-- Проверяем HTTP-заголовок User-Agent на содержание сигнатуры Тонкого клиента -->
<add input="{HTTP_USER_AGENT}" pattern="1C\+Enterprise" />
</conditions>
<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Access via 1C Thin Client is restricted by security policy." />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
После сохранения изменений IIS начнет мгновенно возвращать HTTP-ошибку 403 Forbidden на любые попытки Тонкого клиента подключиться к базе. При этом пользователи в браузере не заметят никаких изменений.
Если публикация выполнена на веб-сервере Apache, блокировку можно настроить через конфигурационный файл конкретного виртуального хоста (обычно это httpd.conf или файлы в директории sites-enabled) либо через файл локальных настроек каталога .htaccess в папке публикации.
Для этого убедимся, что в конфигурации Apache активирован модуль обработки правил перезаписи (LoadModule rewrite_module modules/mod_rewrite.so), и добавим следующие директивы:
RewriteEngine On
# Проверяем наличие сигнатуры Тонкого клиента 1С в User-Agent
RewriteCond %{HTTP_USER_AGENT} 1C\+Enterprise [NC,OR]
RewriteCond %{HTTP_USER_AGENT} 1cv8 [NC]
# Отправляем ответ 403 Forbidden и прекращаем дальнейшую обработку запроса
RewriteRule ^ - [F,L]
Флаг [NC] означает игнорирование регистра символов при поиске соответствия, а флаг [F] принудительно возвращает код ответа 403.
Иногда возникает гибридная задача: необходимо полностью закрыть доступ через Тонкий клиент для всех пользователей из глобальной сети Интернет, но при этом оставить возможность подключения через Тонкий клиент для нескольких доверенных лиц (например, ИТ-специалистов, главного бухгалтера), работающих из филиалов со статическими внешними IP-адресами.
В такой ситуации оптимальным решением будет создание двух параллельных публикаций одной и той же информационной базы на одном веб-сервере:
/BGU_Web):
Данная публикация открыта для всего интернета. На уровне веб-сервера (с использованием механизмов из Способа 2) мы настраиваем жесткую блокировку заголовков User-Agent, содержащих 1C+Enterprise. Любой внешний пользователь сможет зайти в базу только через обычный веб-браузер.
/BGU_Thin):
На этой публикации блокировка по User-Agent не настраивается, что позволяет запускать Тонкий клиент. Однако доступ к самому URL-адресу публикации строго ограничивается на сетевом уровне веб-сервера. Мы настраиваем белый список IP-адресов (IP Address and Domain Restrictions в IIS или директивы Require ip в Apache), разрешая подключения только с доверенных публичных IP-адресов наших удаленных офисов или домашних адресов ключевых сотрудников. Запросы со всех остальных IP-адресов будут отсекаться веб-сервером на сетевом уровне.
Для ИТ-инфраструктур с повышенными требованиями к информационной безопасности лучшим решением против брутфорса и несанкционированного доступа является внедрение авторизации по клиентским SSL-сертификатам на веб-сервере IIS или Apache.
Суть метода заключается в следующем:
.pfx или .p12) для каждого доверенного удаленного пользователя.При любой попытке обращения к веб-серверу (будь то браузер или Тонкий клиент 1С) сервер сначала затребует предъявление валидного цифрового сертификата. Если сертификат отсутствует или скомпрометирован, веб-сервер мгновенно разорвет SSL-соединение, даже не показывая злоумышленнику стандартную форму авторизации 1С с предложением ввести логин и пароль. Это делает подбор паролей технически невозможным.
Мы рассмотрели различные методы защиты публикации баз 1С от нежелательного запуска Тонкого клиента через веб-сервер. Выбор конкретного метода зависит от структуры вашей компании и доступных ресурсов: