Шаг 5 — Настройка виртуальных хостов (рекомендуется)
При использовании веб-сервера Apache вы можете использовать виртуальные хосты (аналогичные серверным блокам в Nginx) для инкапсуляции данных конфигурации и размещения на одном сервере нескольких доменов. Мы создадим домен example.com, но вы должны заменить это имя собственным доменным именем. Чтобы узнать больше о настройке доменного имени с помощью DigitalOcean, пройдите наш обучающий модуль Введение в DigitalOcean DNS.
Создайте каталог для example.com следующим образом, используя опцию для создания необходимых родительских каталогов:
Затем назначьте владение каталогом с помощью переменной среды :
Разрешения корневых каталогов веб-сервера должны быть правильными, если вы не изменяли значение . Тем не менее, вы можете проверить это с помощью следующей команды:
Затем создайте в качестве примера страницу , используя или свой любимый редактор:
Добавьте в страницу следующий образец кода HTML:
/var/www/example.com/html/index.html
Сохраните файл и закройте его после завершения.
Для обслуживания этого контента Apache необходимо создать файл виртуального хоста с правильными директивами. Вместо изменения файла конфигурации по умолчанию мы создадим новый файл :
Введите следующий блок конфигурации, который похож на заданный по умолчанию, но обновлен с учетом нового каталога и доменного имени:
/etc/apache2/sites-available/example.com.conf
Обратите внимание, что мы изменили на новый каталог, а — на адрес электронной почты, доступный администратору сайта example.com. Также мы добавили две директивы: директиву , которая устанавливает базовый домен и должна соответствовать определению виртуального хоста, и директиву , которая задает дополнительные имена, которые должны давать совпадение, как если бы они были базовыми именами
Сохраните файл и закройте его после завершения.
Активируем файл с помощью инструмента :
Отключите сайт по умолчанию, определеный в :
Затем проверим ошибки конфигурации:
Вы должны увидеть следующий результат:
Перезапустие Apache для внесения изменений:
Теперь Apache должен обслуживать ваше доменное имя. Вы можете проверить это, открыв в браузере адрес , после чего должны увидеть примерно следующее:
Чем различаются HTTP Basic и Digest аутентификации
HTTP Basic и Digest аутентификации предназначены для контроля доступа на уровне веб-сервера. Если при попытке открыть веб-страницу или войти в настройки роутера вы видите такое окно:
Для конечного пользователя Basic и Digest выглядят одинаково. С технической точки зрения они различаются тем, что при Basic аутентификации пароль передаётся в открытом виде, а при Digest пароль зашифрован. Но официальная документация Apache рекомендует не полагаться на шифрование Digest, поскольку оно слишком слабое, а вместо этого использовать Basic аутентификацию в паре с HTTPS, чтобы невозможно было перехватить логин и пароль.
Step 5: Testing
To check if ModSecurity is working, you can launch a simple SQL injection attack on your own website. (Please note that it’s illegal to do security testing on other people’s websites without authorization.) Enter the following URL in your web browser.
https://yourdomain.com/?id=3 or 'a'='a'
If ModSecurity is working properly, your Apache web server should return a 403 forbidden error message.
And in the audit log (), you can see the following line in section H, which means ModSecurity detected and blocked this SQL injection attack by using OWASP CRS v3.3.0.
Action: Intercepted (phase 2)
When ModSecurity runs in mode, it won’t block this SQL injection attack.
Виртуальные хосты в Windows 7
В качестве примера поместим один или несколько проектов на диск D: локального компьютера. Сначала организуем структуру каталогов. На диске D: создаем каталог «mysites», а в нём каталог для первого сайта «site1». В каталоге «site1» сделаем два подкаталога: «www» и «logs». В первом подкаталоге будет располагаться сам сайт, а во втором, журналы виртуального хоста: access.log (журнал доступа) и error.log (журнал ошибок).
Файлы журналов создавать не надо, они будут созданы автоматически. А в каталоге «www», пока нет сайта, поместим простейший файл-заглушку «index.html» следующего содержания:
Теперь немного поправим настройки для виртуальных хостов веб-сервера Apache. Открываем C:\xampp\apache\conf\extra\ httpd-vhosts.confКак видим, этот файл уже содержит два примера виртуальных хостов. Не будем их трогать, а ниже разместим следующие строки:
NameVirtualHost *:80
<VirtualHost *:80>
DocumentRoot "C:/xampp/htdocs"
ServerName localhost
</VirtualHost>
<VirtualHost *:80>
ServerAdmin webmaster@site1.ru
DocumentRoot "D:/mysites/site1/www"
ServerName site1
ServerAlias www.site1
ErrorLog "D:/mysites/site1/logs/error.log"
CustomLog "D:/mysites/site1/logs/access.log" common
<Directory "D:/mysites/site1/www">
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
Первая директива NameVirtualHost *:80 включает поименное использование виртуальных хостов на 80-ом порту (обычный http, если нужен https, используем 443 порт).Следующие четыре строки это общая секция для всех виртуальных хостов. Если клиент обращается к серверу по IP-адресу или по несуществующему имени он попадет на этот виртуальный хост. В нашем случае в корневую директорию веб-сервера. Остальные строки это описание нашего первого виртуального хоста. Если нужно добавить ещё один виртуальный хост, то просто копируем эту секцию, вставляем ниже и по аналогии изменяем данные. Сохраняем файл.Значение данных в секции виртуального хоста:
- <VirtualHost *:80> Какой порт используется
- ServerAdmin webmaster@site1.ru Эл. почта администратора сайта
- DocumentRoot «D:/mysites/site1/www» Корневой каталог сайта
- ServerName site1 Имя хоста
- ServerAlias www.site1 Псевдоним хоста. Можно обращаться, используя псевдоним
- ErrorLog «D:/mysites/site1/logs/error.log» Расположение журнала ошибок
- CustomLog «D:/mysites/site1/logs/access.log» common Расположение журнала доступа. Оператор common определяет общую степень детализации журнала. Если нужна более подробная детализация, то вместо common пишем combined
- <Directory «D:/mysites/site1/www»> Подсекция, в которой определяются права и настройки для конкретного каталога.
- AllowOverride All Эта директива нужна для правильной работы системы SEF
Из панели управления XAMPP перестартовываем Apache. Изменяем файл C:\Windows\System32\drivers\etc\hosts. Дописываем в него две строки:
127.0.0.1 site1 127.0.0.1 www.site1
Вместо 127.0.0.1 можно написать 127.0.0.2, а для следующего виртуального хоста 127.0.0.3, но в этом нет особой нужды. Об этом напишу в другой раз. А сейчас сохраняем файл. Открываем браузер и адресной строке вводим http://site1 или просто site1. Если всё сделано правильно, видим информацию из файла-заглушки.
Шаг 1. Создание сертификата
Для боевого сервера, сертификат должен быть получен от доверенного центра сертификации — либо локального для компании, либо коммерческого. Или получен бесплатно от Let’s Ecnrypt.
Для тестовой среды можно сгенерировать самоподписанный сертификат. Для этого сперва переходим в рабочую папку.
а) на Red Hat / CentOS:
cd /etc/httpd
б) на Debian / Ubuntu:
cd /etc/apache2
в) во FreeBSD:
cd /usr/local/etc/apache24
Создаем папку для сертификатов и переходим в нее:
mkdir ssl ; cd ssl
И генерируем сертификат:
openssl req -new -x509 -days 1461 -nodes -out cert.pem -keyout cert.key -subj «/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=test.dmosk.local/CN=test»
* в данном примере созданы открытый и закрытый ключи на 4 года (1461 день); значения параметра subj могут быть любыми в рамках тестирования.
Установка mod_pagespeed
Установка mod_pagespeed – очень простой процесс, зависящий от используемой операционной системы. В системах Ubuntu и Debian есть пакеты, которые можно просто загрузить и установить (они доступны в любом дистрибутиве Linux, который использует пакеты .deb). В других дистрибутивах Linux можно скачать исходный и скомпилировать модуль.
Если используется 32-битная версия (нежелательно):
Затем удалите загруженный пакет.
Примечание: установка модуля из исходного кода выходит за рамки этой статьи.
Данный модуль активируется автоматически сразу после установки. Тем не менее, для его корректной работы необходимо перезапустить веб-сервер Apache:
Готово! Теперь модуль mod_pagespeed установлен и запущен на на виртуальном выделенном сервере. В этом можно убедиться, посмотрев на заголовки ответа страницы; там должно появиться значение X-Mod-Pagespeed с номером установленной версии.
Инсталляционный пакет обрабатывает множество конфигураций «из коробки». В целом, в Apache для этого модуля есть специальные краткие настройки по умолчанию, которые включаются автоматически. Версия модуля, которая будет установлена и активирована, определяется в зависимости от используемой версии Apache. Так, при работе с Apache 2.2 будет установлен mod_pagespeed.so; для Apache 2.4 устанавливается mod_pagespeed_ap24.so.
Примечание: mod_pagespeed работает в Apache 2.2 и выше. Кроме того, Apache 2.4.1 не может использовать данный модуль из-за ошибки в программе. Потому необходимо использовать Apache 2.4.2+.
Кроме того, к установке Apache были добавлены конфигурационные файлы. Основным конфигурационным файлом является pagespeed.conf, который находится в:
Шаг 2. Настройка ModSecurity
В /etc/apache2/mods-enabled/security2.conf файле конфигурации вы можете найти следующую строку.
Это означает, что Apache включит все *.conf файлы в /etc/modsecurity/каталог.Нам нужно переименовать файл modsecurity.conf-recommended.
sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
Отредактируйте этот файл с помощью текстового редактора командной строки.
sudo nano /etc/modsecurity/modsecurity.conf
Найдите следующую строку.
SecRuleEngine DetectionOnly
Эта конфигурация указывает ModSecurity регистрировать HTTP-транзакции, но не предпринимает никаких действий при обнаружении атаки. Измените его на следующее, чтобы ModSecurity обнаруживал и блокировал веб-атаки.
SecRuleEngine On
Затем найдите следующую строку (строка 186), которая сообщает ModSecurity, какая информация должна быть включена в журнал аудита.
SecAuditLogParts ABDEFHIJZ
Настройка по умолчанию неверна, настройку следует изменить на следующую.
SecAuditLogParts ABCEFHJKZ
Перезапустите Apache, чтобы изменения вступили в силу.
sudo systemctl restart apache2
Назначение и использование файла .htaccess
Файл (первый символ в названии файла — точка) применяется для управления веб-сервером Apache со стороны конечного пользователя хостинга. В этот файл прописываются директивы, которые веб-сервер обрабатывает, выполняя действия в соответствии с установленными настройками.
Файл может быть размещен в корневом каталоге веб-сервера (прямо в каталоге www). В этом случае директивы из такого .htaccess действуют по всему веб-серверу. Также .htaccess может находиться и в конкретном подкаталоге сервера. Тогда директивы, которые указаны в этом файле, «перекрывают» действие директив из «основного» файла, который размещен в каталоге www или в любом каталоге более высокого уровня. То есть, действие директив из .htaccess наследуется сверху вниз, но не наоборот. Изменения, внесенные в файл, вступают в силу немедленно. Это связано с тем, что информация из .htaccess перечитывается при каждом обращении к веб-серверу Apache.
В может быть помещено большинство из доступных директив для веб-сервера. Следует заметить, что директивы, в описании которых в поле Context отсутствует упоминание .htaccess недоступны для использования в этом файле конфигурации. На примере директивы AddType видим, что поле Context содержит упоминание о .htaccess, соответственно вы можете ее использовать:
Если использовать нужную директиву не получилось, и вы увидели ошибку после добавления директивы в .htaccess, скорее всего, использование команды запрещено в условиях виртуального хостинга. Напишите в техническую поддержку, мы постараемся вам помочь. Просьба подробно описать проблему и указать цели, которых хотите достичь использованием данной директивы.
Conclusion
can be used effectively to ensure human-readable URLs. The file itself has many more uses than simply this module, however, and it should be noted that many other Apache modules may be installed to extend its functionality.
There are other resources that detail the capabilities of :
- Apache mod_rewrite Introduction
- Apache Documentation for mod_rewrite
- mod_rewrite Cheat Sheet
is a critical module for web application security, but can sometimes end up in redirect loops or ubiquitous, ambiguous errors. For tips on debugging , see this StackOverflow post.
Rewrite rules are written with regular expressions. To become an expert, reference this tutorial all about regular expressions.
For quick analysis of your regular expression patterns, here is an online debugger that can provide immediate feedback and live interpretations of your regular expression patterns.
4: Настройка перезаписи
Данный раздел покажет, как настроить базовую перезапись URL-адресов. В качестве примера используется ссылка example.com/about.
Создайте файл about.html:
Скопируйте следующий код и поместите его в файл:
Обратите внимание: доступ можно получить только к about.html. Если вы введёте ссылку ip_адрес_сервера /about, вы получите ошибку 404 Not Found
Создайте правило перезаписи, чтобы исправить это.
Откройте файл .htaccess:
Добавьте в него следующую строку:
Теперь файл содержит такие настройки:
Теперь браузер сможет обслуживать страницу example.com/about.
На примере этого правила можно рассмотреть общий синтаксис перезаписи.
- ^about$ — шаблон, с которым совпадает URL, и который пользователи вводят в браузере. В данном примере используются метасимволы, благодаря которым можно чётко обозначить местонахождение шаблона: символ ^ определяет начало шаблона, а • $ — конец.
- about.html: исходный путь к странице, по которому обслуживается файл about.html.
- : флаг, который отключает чувствительность URL-адреса к регистру.
Согласно этому правилу, доступ к странице можно получить по следующим ссылкам:
А такие ссылки не сработают:
Для чего нужен mod_rewrite / Что умеет mod_rewrite
Слово «rewrite» в названии модуля буквально означает «перезапись». Эта «перезапись» относится к URL (адресу сайта, страницы, файла). Перезапись (преобразование) происходит между тем, что введено в строке браузера пользователя (фактически, отправлено на веб-сервер) и тем, что веб-сервер получит на самом деле.
Наглядным примером применения mod_rewrite являются ЧПУ (аббр. от «человекопонятный URL») — URL-путь, состоящий из понятных слов, вместо идентификаторов, и отражающий файловую структуру сайта. Например, вместо /c14/3/97/ или /index.php?cat=10&subcat=2&id=41 будет /product/phone/Samsung/.
Человекопонятные пути улучшают удобство использования, Кроме того, позволяют по названию ссылки заранее предполагать содержимое страницы по ней, и представлять структуру сайта.
Это очень популярное, но не единственное применение mod_rewrite. Этот модуль умеет делать перезапись на основе разных данных: к примеру, на основе типа браузера. Это позволяет показывать разные страницы в зависимости от типа браузера, IP адреса, языка пользователя, установленных кукиз и т.д.
mod_rewrite умеет делать редирект (перенаправление) на другой адрес. В результате, если ваш сайт переехал на другой домен или поменялась структура сайта, вы можете настроить автоматическую переадресацию со старых адресов страниц на новые.
mod_rewrite умеет запрещать доступ к определённым ресурсам, как по определённому условию, так и безусловно. Т.е. вы можете настроить контроль доступа, закрыв определённые страницы для всех пользователей, либо на основе их стран, языка, веб-браузера и т.д.
На самом деле – это не всё, что умеет mod_rewrite! И даже в этом мануале вы встретитесь с дополнительными примерами применения mod_rewrite.
Прежде чем мы перейдём к теории и практики использования mod_rewrite, нужно включить модуль mod_rewrite для веб-сервера, либо убедиться, что mod_rewrite уже включен. Если вы используетесь shared (совместным) хостингом, то у большинства хостеров этот модуль включен по умолчанию. Ниже показано, как включить этот модуль на своём собственном локальном (домашнем) сервере, либо веб-сервере на VPS.
Скринкаст: Обзор конфигурации Apache в Ubuntu
В скринкасте представлен последовательный обзор конфигурации web сервера Apache в Ubuntu при стандартной установке LAMP в Ubuntu server 16.04. Описана стартовая страница web сервера, структура домашней директории Apache, назначение каталогов и конфигурационных файлов. Приведены команды для управления и настройки конфигурации веб сервера. Описаны логика, структура, особенности и подход в конфигурации Apache. Дано понятие контекста действия директив Apache. Приведены ссылки на необходимую документацию. Скринкаст поможет вам разобраться в настройке web сервера Apache2 в операционной системе Ubuntu для своего разработческого или продуктивного веб сервера, как на виртуальной машине, так и на выделенном VDS или на своем Ubuntu Desktop персональном компьютере.
Смотреть на YouTube скринкаст: Обзор конфигурации Apache в Ubuntu
Содержание скринкаста:
- Задачи и план скринкаста………………………….00:05
- Среда LAMP Ubuntu в данном обзоре конфигурации Apache..00:59
- Обзор стартовой страницы Apache в Ubuntu……………01:29
- Обзор домашней директории Apache в Ubuntu…………..05:57
- Контекст действия директив Apache………………….09:50
- Логика загрузки конфигурации Apache………………..11:19
- Описание назначения директорий и конфигов Apache…….11:35
- Команды конфигурации и управления Apache в Ubuntu……17:44
- Резюме по скринкасту……………………………..25:33
Шаг 5: тестирование
Для проверки работы ModSecurity, вы можете запустить простую атаку с помощью SQL-инъекции на свой собственный веб-сайт, проводить тестирование безопасности на чужих веб-сайтах без авторизации незаконно.Введите следующий URL-адрес в своем веб-браузере.
https://myvps.com/?id=3 or 'a'='a'
Открываем журнал аудита /var/log/apache2/modsec_audit.log, видим строку в разделе H, что означает, что ModSecurity обнаружил и заблокировал эту атаку с использованием SQL-инъекций с помощью OWASP CRS v3.3.0.
Action: Intercepted (phase 2)
Когда ModSecurity работает в DetectionOnly режиме, он не блокирует эту атаку с использованием SQL-инъекции.
Шаг 2. Установка модуля SSL для Apache
Прежде, чем устанавливать модуль, выполняем команду:
apachectl -M | grep ssl
Если видим строчку, на подобие:
ssl_module (shared)
Спускаемся к шагу 3 данной инструкции.
Иначе, устанавливаем httpd ssl_module.
а) Для CentOS:
yum install mod_ssl
б) Для Ubuntu/Debian:
a2enmod ssl
в) Для FreeBSD:
Открываем файл конфигурации apache:
ee /usr/local/etc/apache24/httpd.conf
* подразумевается, что используется apache 2.4.
Находим и снимаем комментарии со следующих строчек:
…
LoadModule ssl_module libexec/apache24/mod_ssl.so
…
Include etc/apache24/extra/httpd-ssl.conf
…
И ставим комментарии в следующих строках:
#<IfModule ssl_module>
#SSLRandomSeed startup builtin
#SSLRandomSeed connect builtin
#</IfModule>
Чтобы настройки применились, необходимо перезапустить веб-сервер одной из команд:
systemctl restart httpd
systemctl restart apache2
service apache2 restart
* первая, как правило, используется в системах на базе RPM, вторая — DEB, третья — BSD.
Example 2 — Adding Conditions with Logic Using RewriteConds
Rewrite rules are not necessarily always evaluated one by one without any limitations. The directive lets us add conditions to our rewrite rules to control when the rules will be processed. All abide by the following format:
General RewriteCond structure
- specifies the directive.
- is the string to test against.
- is the pattern or condition to match.
- are optional parameters that may modify the condition and evaluation rules.
If a evaluates to true, the next will be considered. If it doesn’t, the rule will be discarded. Multiple may be used one after another, though all must evaluate to true for the next rule to be considered.
As an example, let’s assume you would like to redirect all requests to non-existent files or directories on your site back to the home page instead of showing the standard 404 Not Found error page. This can be achieved with following conditions rules:
Redirect all requests to non-existent files and directories to home page
With the above:
- is the string to check. In this case, it’s the requested filename, which is a system variable available for every request.
- is a built-in condition which verifies if the requested name exists on disk and is a file. The is a negation operator. Combined, evaluates to true only if the specified name does not exist or is not a file.
- Similarly, evaluates to true only if the specified name does not exist or is not a directory.
The on the final line will come into effect only for requests to non-existent files or directories. The itself is very simple and redirects every request to the website root.
Conclusion
lets you create human-readable URLs. In this tutorial, you learned how to use the directive to redirect URLs, including ones with query strings. You also learned how to conditionally redirect URLs using the directive.
If you’d like to learn more about , take a look at Apache’s mod_rewrite Introduction and Apache’s official documentation for mod_rewrite.
Пример 1 – Упрощение строки запросов с RewriteRule
Веб – приложения часто используют строки запроса, которые добавляются к URL – адресу, используя знак вопроса ( ) после адреса. Отдельные параметры разделяются с помощью амперсанда (). Строки запроса могут быть использованы для передачи дополнительных данных между отдельными страницами приложения.
Например, страницы результатов поиска написанные на PHP, могут использовать URL, как . В этом примере два дополнительных параметра передают воображаемый сценария приложения: со значением и со значением . Приложение может использовать информацию строки запроса, чтобы построить правильную страницу для посетителя.
Правила перезаписи Apache часто используются для упрощения таких длинных и неприглядных ссылок как выше в дружественные URL – адреса, которые легче вводить и интерпретировать визуально. В этом примере, мы хотели бы, упростить ссылку выше, чтобы сделать . и значения параметров и andreyex к прежнему адресу, но без строки запроса и имени сценария.
Вот одно правило для реализации этого:
Простой пример
явно сопоставляются в запрашиваемом адресе и Apache указал запустить вместо этого .
обычно используются в правила[ перезаписи. Они говорят Apache, чтобы добавить любые дополнительные строки запроса к обслуживаемому URL. Без этого, дополнительная строка запроса будет отбрасываются.
Хотя этот метод позволяет достичь желаемого эффекта, как имя элемента и author жестко закодированы в правила. Это означает, что правило не будет работать для любыми другими предметами, например , или author, как .
Для того, чтобы сделать правило более общо, мы можем использовать регулярные выражения, чтобы соответствовать части исходного адреса и использовать те части в схеме замещения. Модифицированное правило будет выглядеть следующим образом :
Простой пример
Первое регулярное выражение группы в скобках соответствует строке, содержащей буквенно-цифровые символы и цифры, как и сохраняет совпавший фрагмент в качестве переменной . Вторая группа выражений в скобках соответствует точно , , или , и так же сохраняет совпавший фрагмент как .
Согласованные фрагменты затем в результирующий URL в переменные и вместо жёстко и , которые мы использовали раньше.
Выше будет преобразовывать, например, в . Этот пример также на будущее, позволяя нескольким элементам и author правильно переписать с использованием единого правила.
Правила перезаписи не обязательно всегда вычисляются один за другим без каких – либо ограничений. Директива позволяет нам добавлять условия для наших правил перезаписи, чтобы контролировать, когда правила будут обработаны. соблюдает следующий формат:
Если имеет значение истинно, то сразу после будет рассмотрен. Если это не будет, то правило будет отброшено. Многократная может использоваться один за другим, и с поведением по умолчанию, все они должны оценить, верно и в следующем правиле для рассмотрения.
В качестве примера, давайте предположим, что вы хотели бы перенаправить все запросы на несуществующие файлы и каталоги на вашем сайте обратно на главную страницу вместо того чтобы показывать стандартную страницу ошибку 404 Not Found. Это может быть достигнуто с следующими условиями правил:
С учетом указанных выше:
На последней строке вступит в силу только для запросов на несуществующие файлы и каталоги. Сама по себе очень проста и перенаправляет каждый запрос на корень сайта.
полезный модуль Apache, который может быть эффективно использован для обеспечения удобочитаемых URL. На этом уроке вы узнали, как использовать директиву для перенаправления URL – адресов, в том числе с строки запроса. Вы также узнали перенаправление URL – адреса с помощью директивы .
Если вы хотите узнать больше о , посмотрите на введение в mod_rewrite Apache и официальной документации Apache для mod_rewrite.
Настройка ssl сертификата Lets Encrypt в apache
Теперь настроим работу web сервера apache с ssl сертификатом. Хотя если быть точным, то tls сертификатом. Устанавливаем пакет certbot для получения бесплатного ssl сертификата от let’s encrypt. Для этого нам сначала надо подключить репозиторий epel.
# dnf install epel-release # dnf install certbot
После установки пакетов certbot, если его запустить, напишет ошибку, что не может сам настроить apache.
Настроим все сами. Для начала создадим самоподписанный дефолтный сертификат, чтобы apache не ругался на отсутствие файла и смог запуститься.
# openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/pki/tls/private/localhost.key -out /etc/ssl/certs/localhost.crt
Все параметры оставляйте дефолтные, не принципиально. Мы этот сертификат использовать не будет. Перезапустите apache.
# apachectl restart
Теперь выпустим сертификат для нашего домена. Имейте ввиду, чтобы получить сертификат у вас должно быть действующее доменное имя, ссылающееся на web сервер, который настраиваете. Let’s Encrypt будет по доменному имени обращаться к серверу, на котором настраиваете сертификат, чтобы проверить домен. В тестовой лаборатории с вымышленным доменным именем получить настоящий ssl сертификат не получится.
# certbot certonly
В качестве способа аутентификации выбирайте
1: Apache Web Server plugin (apache)
Дальше заполняйте в соответствии с вашими названиями. После получения сертификата, укажем его в конфигурации виртуального хоста. В моем случае в файле z.serveradmin.ru.conf. Добавляем туда параметры ssl.
<VirtualHost *:80 *:443>
ServerName z.serveradmin.ru
ServerAlias www.z.serveradmin.ru
DocumentRoot /web/sites/z.serveradmin.ru/www
ErrorLog /web/sites/z.serveradmin.ru/log/error.log
CustomLog /web/sites/z.serveradmin.ru/log/access.log common
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/z.serveradmin.ru/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/z.serveradmin.ru/privkey.pem
<Directory /web/sites/z.serveradmin.ru/www>
Options FollowSymLinks
AllowOverride All
Require all granted
</Directory>
php_admin_value date.timezone 'Europe/Moscow'
php_admin_value max_execution_time 60
php_admin_value upload_max_filesize 30M
</VirtualHost>
Перезапускайте apache и проверяйте работу сайта по https, зайдя по соответствующему протоколу.
По аналогии делаете с остальными виртуальными хостами, для которых используете бесплатные сертификаты let’s encrypt. Осталось дело за малым — настроить автоматический выпуск новых ssl сертификатов, взамен просроченным. Для этого добавляем в /etc/crontab следующую строку:
# Cert Renewal 30 4 * * * root /usr/bin/certbot renew --post-hook "/usr/sbin/apachectl restart" >> /var/log/le-renew.log
Переадресация с http на https в apache
В настроенном ранее примере https отлично работает, но неудобно, что нет автоматической переадресации с http на https. Чтобы использовать безопасную версию сайта, необходимо вручную в браузере набирать https. Хотя все современные браузеры уже сами умеют проверять версии сайта и если есть защищенная, то они автоматически сами ее выбирают.
Тем не менее, лучше все же добавить редирект с http на https. Его можно сделать двумя различными способами:
- Через файл .htaccess
- С помощью настройки виртуального хоста.
Мне нравится больше второй вариант, поэтому приводим конфиг виртуального хоста к следующему виду.
<VirtualHost *:80>
ServerName z.serveradmin.ru
ServerAlias www.z.serveradmin.ru
Redirect permanent / https://z.serveradmin.ru
</VirtualHost>
<VirtualHost *:443>
ServerName z.serveradmin.ru
ServerAlias www.z.serveradmin.ru
DocumentRoot /web/sites/z.serveradmin.ru/www
ErrorLog /web/sites/z.serveradmin.ru/log/error.log
CustomLog /web/sites/z.serveradmin.ru/log/access.log common
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/z.serveradmin.ru/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/z.serveradmin.ru/privkey.pem
<Directory /web/sites/z.serveradmin.ru/www>
Options FollowSymLinks
AllowOverride All
Require all granted
</Directory>
php_admin_value date.timezone 'Europe/Moscow'
php_admin_value max_execution_time 60
php_admin_value upload_max_filesize 30M
</VirtualHost>
Перечитывайте конфиг httpd и проверяйте. Должно работать автоматическое перенаправление на https версию.
Global Configuration Section
This section is used to configure some options that control how Apache works as a whole.
There are some interesting options you may want to modify in this section:
Timeout
By default, this parameter is set to «300», which means that the server has a maximum of 300 seconds to fulfill each request.
This is probably too high for most set ups and can safely be dropped to something between 30 and 60 seconds.
KeepAlive
This option, if set to «On», will allow each connection to remain open to handle multiple requests from the same client.
If this is set to «Off», each request will have to establish a new connection, which can result in significant overhead depending on your setup and traffic situation.
MaxKeepAliveRequests
This controls how many separate request each connection will handle before dying. Keeping this number high will allow Apache to serve content to each client more effectively.
Setting this value to 0 will allow Apache to serve an unlimited amount of request for each connection.
KeepAliveTimeout
This setting specifies how long to wait for the next request after finishing the last one. If the timeout threshold is reached, then the connection will die.
This just means that the next time content is requested, the server will establish a new connection to handle the request for the content that make up the page the client is visiting.
MPM Configuration
The next section specifies the configuration of the MPM (Multi-Processing Module) options. You can cross-reference which section your Apache installation was compiled with by exiting into the terminal and typing:
apache2 -l
Compiled in modules: core.c mod_log_config.c mod_logio.c prefork.c http_core.c mod_so.c
As you can see, in this server, «prefork.c» is a module that was compiled in and is also in the «apache2.conf» file. Your installation may have multiple to choose from, but only one can be selected.
You can adjust the configuration of the prefork MPM in the appropriate section.
Шаг 3 – Настройка перезаписи URL
Здесь мы установим базовую перезапись URL, которая преобразует URL – адреса в реальные пути к коду. В частности, мы будем разрешать пользователям доступ.
Начнем с создания файла с именем в корневой директории веб.
sudo nano /var/www/html/about.html
Скопируйте следующий HTML-код в файл, а затем сохраните и закройте его.
/var/www/html/about.html
<html>
<head>
<title>О нас</title>
</head>
<body>
<h1>О нас</h1>
</body>
</html>
Вы можете получить доступ к странице http://your_server_ip/about.html, но обратите внимание, что если вы попытаетесь получить доступ к http://your_server_ip/about, вы увидите ошибку 404 Not Found. Но чтобы пользователи получили доступ к странице с помощью about вместо того, чтобы, переписать правила позволит эта самая функциональность
соблюдает следующий формат:
Общая структура RewriteRule
- определяет директиву.
- является регулярное выражение, которое соответствует желаемой строки из URL, типы просмотра в браузере.
- это путь к реальному URL, то есть путь файловых серверов Apache.
- необязательные параметры, которые можно изменять, как работает правило.
Откройте файл .
sudo nano /var/www/html/.htaccess
После первой строки, добавьте отмеченный красным цветом, и сохраните файл.
/var/www/html/.htaccess
RewriteEngine on RewriteRule ^about$ about.html
В этом случае, это шаблон, это замена, и является флагом. Наш пример использует несколько символов со специальным значением:
- указывает на начало URL, после .
- указывает на конец URL.
- соответствует строке “about”.
- является фактическим файл, который обращается к пользователю.
- является флагом, который делает случай правила нечувствительным.
Теперь, вы должны иметь возможность доступа к http://your_server_ip/about в вашем браузере. На самом деле, с правилом показанным выше, следующие URL – адреса будут указывать about.html:
- , из-за определения правила.
- , Так как правило не чувствительно к регистру.
- , так как оригинальное собственное имя файла всегда будет работать.
Ниже не будет:
- , потому что правило четко указано, что не может быть ничего после помощью символа.
- , потому что она не будет соответствовать строке about в правиле.
Теперь у вас есть оперативный файл с простым правилом, вы можете изменить и расширить для ваших потребностей. В следующих разделах мы покажем два дополнительных примера наиболее часто используемых директив.
