0

1c-web-access-ssl

Защищаем веб-публикацию 1С:Предприятие при помощи SSL и аутентификации по паролю

24.09.2022

Получение бесплатного сертификата Let’s Encrypt

На сегодняшний день получение бесплатного сертификата Let’s Encrypt является наиболее оптимальным способом для защиты ваших веб-служб. Некоторых пугает кажущаяся сложность данной операции и необходимость продления сертификата каждые 90 дней, но ничего страшного в этом нет. все прекрасно автоматизировано и работает по принципу один раз настроил и забыл.

Прежде всего установим службу для управления сертификатами:

apt install certbot

Затем создадим некоторую инфраструктуру для ее работы:

mkdir /var/www/letsencrypt
chown -R www-data:www-data /var/www/letsencrypt

Затем создадим файл конфигурации для веб-сервера Apache:

nano /etc/apache2/conf-available/le.conf

И поместим в него следующий текст:

Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/

<Directory "/var/www/letsencrypt/.well-known/acme-challenge/">
Options None
AllowOverride None
ForceType text/plain
Require all granted
RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"
</Directory>

Затем подключим созданную конфигурацию к Apache:

a2enconf le

Проверим конфигурацию веб-сервера на ошибки и перезапустим его:

apachectl -t
service apache2 restart

Теперь попробуем пробное получение сертификата:

certbot certonly --dry-run --webroot -w /var/www/letsencrypt -d 1с.example.com

где 1с.example.com – используемый нами домен, ключ –dry-run обозначает пробную попытку, без реального получения сертификата. Если все прошло без ошибок получим сертификат по-настоящему:

certbot certonly --webroot -w /var/www/letsencrypt -d 1с.example.com

Если ваш сервер находится внутри периметра, то для нормальной работы certbot вы должны пробросить наружу как 443 порт (HTTPS), так и 80 порт (HTTP).

При установке certbot задания на автоматический запуск продления будут созданы автоматически, ничего делать не нужно. Но потребуется настроить перезапуск веб-сервера после обновления сертификата, для этого откройте конфигурационный файл /etc/letsencrypt/renewal/1с.example.com.conf и добавьте в секцию [renewalparams] строку:

[renewalparams]
...
renew_hook = systemctl reload apache2

Это обеспечит перезапуск Apaсhe после обновления сертификата, если обновления не было, то перезапускаться служба не будет.

Настройка SSL-шифрования на веб-сервере Apache

Сертификат получен, самое время перейти к настройке веб-сервера. Современные реалии диктуют единственный вариант работы: только HTTPS, все запросы по незащищенному протоколу HTTP должны автоматически перенаправляться на HTTPS-версию. При этом не следует делать недоступным HTTP-порт, во-первых, он нужен для работы certbot, во-вторых, это создаст неудобство пользователям, так как просто набрав в адресной строке 1с.example.com они никуда не попадут, пока явно не укажут протокол: https://1с.example.com.

Так как наш веб-сервер, по условиям, обслуживает только публикации 1С, то мы не будем создавать новые виртуальные хосты, а отредактируем те, что по умолчанию. Откроем файл /etc/apache2/sites-available/000-default.conf и приведем его к следующему виду:

<VirtualHost *:80>   
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]


ServerAdmin webmaster@example.com
DocumentRoot /var/www/html

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Конфигурация стандартная и особо в комментариях не нуждается, за исключением первых трех строк, которые осуществляют перенаправление на HTTPS всех HTTP запросов, кроме Let’s Encrypt.

Теперь откроем /etc/apache2/sites-available/default-ssl.conf – файл с настройками виртуального хоста с SSL-защитой и внесем в него следующие строки:

<VirtualHost *:443>
ServerAdmin webmaster@example.com
DocumentRoot /var/www/html

ErrorLog ${APACHE_LOG_DIR}/error_ssl.log
CustomLog ${APACHE_LOG_DIR}/access_ssl.log combined

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/1с.example.com/cert.pem
SSLCertificateChainFile /etc/letsencrypt/live/1с.example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/1с.example.com/privkey.pem
SSLCACertificateFile /etc/letsencrypt/live/1с.example.com/chain.pem

Protocols h2 http/1.1
Header always set Strict-Transport-Security "max-age=63072000"
</VirtualHost>

Конфигурация, в целом, тоже стандартная. Набор SSL-опций включает шифрование и указывает пути к сертификатам. Последние две строки разрешают протокол HTTP/2, если поддерживается клиентом и включают HSTS, специальный заголовок, который предписывает клиенту, если он уже один раз успешно соединился с сайтом по HTTPS отвергать подключения по HTTP в течении указанного в параметре max-age времени. На время отладки эту опцию рекомендуется закомментировать.

Теперь откроем главный файл конфигурации Apache /etc/apache2/apache2.conf и добавим туда глобальные опции, отвечающие за шифрование:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off
SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

Так как правильное их формирование вопрос сложный, то рекомендуем воспользоваться специальным генератором moz://a SSL Configuration Generator. В нашем случае взяты настройки среднего уровня (Intermediate) обеспечивающие необходимый баланс между безопасностью и совместимостью. Рекомендуем время от времени посещать указанный сайт и обновлять настройки шифрования собственного сервера.

Теперь подключим необходимые модули Apache и виртуальный хост для работы с SSL:

a2enmod headers
a2enmod rewrite
a2enmod ssl
a2ensite default-ssl

Проверяем конфигурацию и перезапускаем веб-сервер:

apachectl -t
service apache2 restart

Если все сделано правильно, то при обращении к веб-публикации 1С она будет открываться только через защищенное соединение.

Включаем дополнительную аутентификацию по паролю

У нас нет основания сомневаться во встроенном механизме аутентификации 1С:Предприятия, во всяком случае в онлайн-сервисах дополнительной аутентификации не предусмотрено, но есть слабое место – пользователи. Во многих базах могут использоваться простые пароли или не использоваться вообще, часть таких паролей могут использоваться скриптами и средствами автоматизации, поэтому взять и установить сразу всем сложные пароли будет не так-то просто.

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

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

Прежде всего создадим файл паролей. Можно использовать один пароль для всех публикаций, либо разные, а также комбинировать этот подход. Например, установим пароль для пользователя user1c:

htpasswd -c /etc/apache2/.htpasswd user1c

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

htpasswd  /etc/apache2/.htpasswd glbuch

Затем в директории публикации базы, например, /var/www/infobase создадим файл .htaccess:

nano /var/www/infobase/.htaccess

И добавим в него следующие строки:

AuthType Basic
AuthName "Restricted Content"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

Первая строка включает Basic-аутентификацию, вторая задает наименование области безопасности, можете вписать туда все что угодно. Затем указывается путь к файлу паролей и политика аутентификации, valid-user обозначает что доступ получит любой аутентифицированный пользователь. Если нужно указать конкретные учетные записи, то последнюю строку нужно изменить следующим образом:

Require user user1c glbuch

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

1cv83-web-access-ssl-001.png

И только после того, как вы пройдете аутентификацию средствами веб-сервера вам будет предложено войти под своим именем в программу 1С:Предприятие:

1cv83-web-access-ssl-002.png

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

1cv83-web-access-ssl-003.png

Чтобы автоматизировать вход и избежать лишних запросов учетных данных можно указать в свойствах информационной базы дополнительные параметры запуска:

/WSN user1c /WSP Pa$$w0rd_1

Где ключ /WSN определяет пользователя веб-сервера, а ключ /WSP – пароль.

1cv83-web-access-ssl-004.png

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

Свежие комментарии

Подписка

Лучшие статьи

Рубрики

Популярное

2

SSL certbot Let’s Encrypt

https://certbot.eff.org/ Поддержка Snap Оснастка Certbot поддерживает архитектуры x86_64, ARMv7 и ARMv8. Хотя мы настоятельно рекомендуем большинству пользователей установить Certbot через оснастку, вы можете
3

Завершение сеансов 1С

Есть несколько вариантов решения вопроса. Бухгалтера должны не закрывать программу, а нажимать Файл – Выход, так происходит правильное закрытие сеанса на сервере.
knocking
Previous Story

Port Knocking в Linux

esxi
Next Story

4 способа сбросить пароль root на хосте
VMWare ESXi

Latest from Blog

RouterOS/MikroTik на Debian

RouterOS — операционная система, основанная на ядре Linux, предназначенная для маршрутизации, брандмауэра, работы с VPN как сервером и клиентом, а также функционирования в качестве точки беспроводного доступа. Эта система может действовать в роли

How to Install Proxmox Virtual Environment on Debian 11

Introduction Proxmox Virtual Environment is an open-source virtualization management program. It provides a single platform to manage services and functions like KVM Hypervisor, Linux Containers (LXC), storage & networking. In addition, it

Настройка Wireguard VPN на своем сервере

Настройка серверной части После успешного подключения я напишу несколько команд и описание того что они производят для понимания процесса: Обновляем список пакетов в репозиториях apt update Обновим сами пакеты apt upgrade -y

Установка Zabbix 7 c NGINX + PostgreSQL + TimescaleDB на Ubuntu Server или Debian

Сервер Zabbix предполагает достаточную вариативность в выборе СУБД и веб-сервера, поэтому многое тут будет зависеть от персональных предпочтений. Однако расширение TimescaleDB позволяет поддерживать высокий уровень производительности и масштабирования при работе с временными

Настройка простого беспроводного репитера на устройстве MikroTik

При развертывании беспроводных сетей достаточно часто возникают ситуации, когда в некоторых местах квартиры или офиса мощность Wi-Fi сигнала недостаточна для уверенной работы. Конечно, наиболее действенным решением является создание централизованно управляемой сети и
Go toTop

Don't Miss

Wildcard

Бесплатный Wildcard SSL-сертификат для поддоменов

Для простых веб-приложений достаточно одного домена (example.com). Однако для сложных систем, с разделением

базы 1С на веб-сервере Windows и Linux

Публикация базы 1С на веб-сервере используется для работы через браузер