Получение бесплатного сертификата 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 combinedSSLEngine 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.pemProtocols 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 offSSLUseStapling 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
Сохраняем файл, перезапуск веб-сервера не требуется, настройка начнет действовать сразу для всех новых подключений. Теперь, при попытке доступа к публикации вы увидите следующий запрос:
И только после того, как вы пройдете аутентификацию средствами веб-сервера вам будет предложено войти под своим именем в программу 1С:Предприятие:
Если вы используете для доступа к опубликованным на веб-сервере базам тонкий клиент, то увидите дополнительное окно аутентификации на веб-сервере, настроить запоминание пароля здесь нельзя и это может быть неудобно пользователям.
Чтобы автоматизировать вход и избежать лишних запросов учетных данных можно указать в свойствах информационной базы дополнительные параметры запуска:
/WSN user1c /WSP Pa$$w0rd_1
Где ключ /WSN определяет пользователя веб-сервера, а ключ /WSP – пароль.
Если публикаций несколько, то файл .htaccess следует создать в директории публикации каждой информационной базы, при этом вы можете комбинировать политики доступа, куда-то разрешать доступ всем пользователям, а куда-то только некоторым. При необходимости настройки можно изменять налету, перезапуск веб-сервера не требуется.
Свежие комментарии