Това е помощен документ, показващ как да бъде извършена стандартна настройка на Apache HTTP сървър под CentOS 7 и Scientific Linux 7, с поддръжка на SSL. За да може да изпълните инструкциите, които са описани по-долу, трябва да имате издаден сървърски X.509 сертификат, частния ключ към него и сертификатната верига към сертификата.

Възможно е вече да имате инсталиран пакетите httpd (това е името на пакета, който съдържа Apache web-сървъра) и mod_ssl (това е пакета, който интегрира Apache web-сървъра и библиотеките на OpenSSL). Може да проверите дали това е така като изпълните следния команден ред (не е нужно да сте super user):

$ rpm -q httpd mod_ssl

Ако получите резултат подобен на:

httpd-2.4.6-88.el7.centos.x86_64
mod_ssl-2.4.6-88.el7.centos.x86_64

то имате инсталирани и двата пакета и няма какво да инсталирате (възможно е да имате инсталиран httpd, но не и mod_ssl). В случай, че не бъде върнат резултат от изпълнението на комамдния ред по-горе, то най-вероятно пакетите httpd и mod_ssl не са инсталирани в системата. За да ги инсталирате, изпълнете като super user:

# yum install httpd mod_ssl

Ако сте инсталирали пакетите httpd и mod_ssl, както е показано по-горе, то имате прясна инсталация на Apache сървъра, в която има поддръжка на SSL. Тя съдържа конфигурационните файлове с всички нужни базови настройки (включително и тестов X.509 сървърски сертификат), на базата на които може да бъде стартиран успешно демона httpd (изпълнимия файл на Apache web-сървъра). Въпреки, че тази базова конфигурация е работеща, тя е само за тестови цели и не може (а и не бива) да бъде използваема за web-сървър в продукция. Редакцията на базовата конфигурация, за да може тя да бъде използвана в продукция, засяга декларациите във файла:

/etc/httpd/conf.d/ssl.conf

доколкото всички модерни web-сървъри предоставят възможността за изгражсане на защитена SSL връзка между тях и клиентските браузъри. По-долу е показано съдържанието на този файл така, както би следвало да изглежда, ако се вземат предвид повечето добри практики по настройка на Apache с SSL. След него има подробни обяснения за някои от най-важните декларации, които са специфични за всяка конкретна инсталация.

Listen 443 https

SSLStaplingCache "shmcb:logs/stapling-cache(150000)"

SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog

SSLSessionCache         shmcb:/run/httpd/sslcache(512000)

SSLSessionCacheTimeout  300

SSLRandomSeed startup file:/dev/urandom  256

SSLRandomSeed connect builtin

SSLCryptoDevice builtin

<VirtualHost _default_:443>

ErrorLog logs/ssl_error_log

TransferLog logs/ssl_access_log

LogLevel warn

SSLEngine on

SSLProtocol TLSv1.2

SSLHonorCipherOrder on

SSLStrictSNIVHostCheck Off

SSLCompression off

SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire

SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

SSLCertificateFile /etc/pki/tls/certs/pki-root.uni-sofia.bg.crt

SSLCertificateKeyFile /etc/pki/tls/private/pki-root.uni-sofia.bg.key

SSLCertificateChainFile /etc/pki/tls/certs/pki-root.uni-sofia.bg.chain.crt

<Files ~ "\.(cgi|shtml|phtml|php3?)$">
    SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>

BrowserMatch "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x %{SSL_CLIENT_M_SERIAL}x %{SSL_CLIENT_S_DN}x \"%r\" %b"

SSLUseStapling on

SSLStaplingResponderTimeout 5

SSLStaplingReturnResponderErrors off

SSLOCSPEnable on

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

Header always set X-Frame-Options SAMEORIGIN

Header always set Content-Secure-Policy "default-src 'self';"

Header always set Referrer-Policy "same-origin"

Header set X-XSS-Protection "1; mode=block"

Header set X-Content-Type-Options "nosniff"

Header set Content-Security-Policy "default-src 'self'; base-uri 'none'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests" "expr=%{CONTENT_TYPE} =~ m#text/html#i"

Header always set Feature-Policy "microphone 'none'; payment 'none'; sync-xhr 'self' https://hpc-service-host.unite.uni-sofia.bg"

</VirtualHost>                                 

• SSLCertificateFile

  След тази деклрация се посочва файла (с пълния път до него), в който се съдържа X.509 сертификата на сървъра (само този сертификат, без никакви други допълнителни сертификати). Отбележете, че този файл е текстов и сертификатния блок в него започва от реда:

  -----BEGIN CERTIFICATE-----

  и завършва с:

  -----END CERTIFICATE-----

  Файлът може да е читаем за всички локални потребители в системата, но трябва да бъде собственост на root. Правата за достъп и собствеността върху файла могат да се установят така:

  # chmod 644 /etc/pki/tls/certs/pki-root.uni-sofia.bg.crt
  # chown root:root /etc/pki/tls/certs/pki-root.uni-sofia.bg.crt

• SSLCertificateKeyFile

  След тази деклрация се посочва файла (с пълния път до него), в който се съдържа частния ключ към X.509 сертификата на сървъра. Това е текстов файл и съдържанието на частния ключ в него започва от реда:

  -----BEGIN RSA PRIVATE KEY-----

  и завършва с:

  -----END RSA PRIVATE KEY-----

  Този файл трябва да е читаем само от root. Правата за достъп и собствеността върху файла могат да се установят така:

  # chmod 600 /etc/pki/tls/private/pki-root.uni-sofia.bg.key
  # chown root:root /etc/pki/tls/private/pki-root.uni-sofia.bg.key

• SSLCertificateChainFile

  След тази деклрация се посочва файла (с пълния път до него), в който се съдържат всички X.509 сертификати, които са част от веригата между X.509 сертификата и сертификата на удостовериятеля. Всеки един от тези сертификати е описан във файла с текстов блок, който започва с реда:

  -----BEGIN CERTIFICATE-----

  и завършва с:

  -----END CERTIFICATE-----

  Файлът може да е читаем за всички локални потребители в системата, но трябва да бъде собственост на root. Правата за достъп и собствеността върху файла могат да се установят така:

  # chmod 644 /etc/pki/tls/certs/pki-root.uni-sofia.bg.chain.crt
  # chown root:root /etc/pki/tls/certs/pki-root.uni-sofia.bg.chain.crt

• Header always set Feature-Policy "microphone 'none'; payment 'none'; sync-xhr 'self' https://hpc-service-host.unite.uni-sofia.bg"

  В края на този ред стои URL-a, с който ще бъде достъпван сървъра. За примера това е https://hpc-service-host.unite.uni-sofia.bg. В конкретния случай, трябва да смените този запис, за да отразява конкретното име на хост, което е зададено на сървъра.

От критична важност е да направите така, че ако клиент иницира HTTP сесия (некриптирана, не-SSL сесия), тя да бъде преиницирана от сървъра като HTTPS сесия (криптирана, SSL-сесия). Това става като създадете файла:

/etc/httpd/conf.d/rewrite.conf

и поставите в него следното съдържание:

<IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteCond "%{SERVER_PORT}"       "^80$"
        RewriteRule "^(.*)$"               "https://%{SERVER_NAME}$1" [R=301,L]
</IfModule>

След като завършите описанието (редакцията) на конфигурацията, рестартирайте Apache сървъра, за да проверите дали направените декларации са читаеми и интерпретируеми от от демона httpd при неговото стартиране:

# systemctl restart httpd

Следните операции засягат стартирането, спирането и рестартирането на демона httpd:

• стартиране при зареждане на системата:

  # systemctl enable httpd

• предотвратяване на стартирането при зареждане на системата:

  # systemctl disable httpd

• ръчно стартиране:

  # systemctl start httpd

• ръчно спиране:

  # systemctl stop httpd

• ръчно инициране на препрочитането на конфигурационните файлове:

  # systemctl reload httpd

• ръчно рестартиране

  # systemctl restart httpd

Стандартно, журналните (log) файлове на Apache в CentOS 7 и Scientific Linux 7, се съхраняват в директорията:

/var/log/httpd/

Ако се следва конфигурацията, препоръчана по-горе, следните журнални (log) файлове ще бъдат създадени и архивирани в тази директория:

• access_log

  съхранява информация по процеса на обработката от страна на демона httpd, на клиентски заявки, получени по некриптирана (не-SSL) комуникация от браузърите на клиентите

• error_log

  съхранява евентуално възникналите грешки при стартирането и работата на демона httpd, свързани с некриптирана (не-SSL) комуникация от и до сървъра

• ssl_request_log

  съхранява информация по процеса на обработката от страна на демона httpd, на SSL заявкте (по протокол HTTPS), получени от браузърите на клиентите - тук са описани използваните шифри, параметрите на клиентските X.509 сертификати (ако такива са използвани от страна на клиента)

• ssl_access_log

  съхранява информация по процеса на обработката от страна на демона httpd, на клиентски заявки, получени по криптирана (SSL/HTTPS) комуникация от браузърите на клиентите

• ssl_error_log

  съхранява информация относно грешките, възникнали при стартирането и работата на демона httpd, свързани с поддръжката на SSL-базираната web-услуга

По подразбиране, в CentOS 7 и Scientific Linux 7, журналните файлове на Apache се архивират веднъж на седмица и се запазват четири последователни архивирани копия на тези файлове. Този тип параметризация се определя от декларациите във файловете:

/etc/logrotate.conf
/etc/logrotate.d/httpd

Как тези два файла заедно определят периодичността на архивирането? Във файла:

/etc/logrotate.conf

има декларацията:

weekly

която именно определя периодичността на архивирането, освен ако във файла

/etc/logrotate.d/httpd

няма декларация за периодичността. Ако я има, тя е с по-висок приоритет.

Броят на архивни копия се определя от декларацията:

rotate

По подразбиране, в /etc/logrotate.conf, след rotate, стои числото 4. Това указва да бъдат запазвани само четири последователни архивирани копия на журналните файлове. В момента, в който трябва да се създаде нов архив, а вече има четири стари архивни копия, най-старото от тях се изтрива.

Ако декларации, които се намират във файла /etc/logrotate.conf, бъдат дублирани в /etc/logrotate.d/httpd, последните ще са с по-висок приоритет.

Къде се намират архивираните копия на журналните файлове и в какъв формат? По подразбиране, архивните копия на журналните (log) файлове се намират в същата директория /var/log/httpd и са в същия (текстов) формат, в който са и "живите". Разликата между "живите" и архивираните файлове (по подразбиране) е в тяхното име - то е мофицирано така, че в края му е добавена датата на архивирането, например:

access_log-20190414
error_log-20190414
ssl_access_log-20190414
ssl_error_log-20190414
ssl_request_log-20190414

В този случай архивирането е извършено на 14 април 2014.

Ако се очаква размера на журналните файлове да нараства твърде много, съхраняването на архивираните копия може да създаде проблем с изчерпване на свободното дисково пространство. За да се предотврати това, трябва да се зададе автоматично компресиране на създадените архивирани копия. Задаването става чрез добавянето на деклрацията:

compress

във файла /etc/logrotate.d/httpd. След нейното добавяне, новите архивирани копия на журналните файлове ще бъдат създавани във формат gzip:

access_log-20190414.gz
error_log-20190414.gz
ssl_access_log-20190414.gz
ssl_error_log-20190414.gz
ssl_request_log-20190414.gz

Архивираните копия, които са създадени при това, ще са все още в некомпресиран вид. Добре е да ги компресирате ръчно, за да може най-старите от тях да бъдат автоматично изтрити, когато се наложи това:

# cd /var/log/httpd
# gzip -9 *

От особена важност е да проверите дали SSL параметрите, които сървъра допуска да се договорят с браузърите, съответстват на стандартите за сигурност и дали параметрите ("headers") на комуникацията, която ще се установи между сървъра и браузърите са в съгласие с установените норми на безопасност.

• проверка на параметрите на SSL комуникацията:

  https://www.ssllabs.com/

  https://www.immuniweb.com/ssl/

• проверка на "headers":

  https://securityheaders.com