Всех категорически приветствую!
Сегодня назначаем Apache порты для прослушки, создаем защищенные хосты (HTTPS) и перенаправляем запросы с HTTP на HTTPS.
Краткий обзор по настройке Apache был в предыдущей статье (в ней разбирались виртуальные хосты).
Порты в Apache.
Иногда возникают ситуации, когда необходимо, чтобы различные сайты висели на разных портах. Например, хочется, чтобы основной сайт открывался на порту 80, а какая-нибудь web-морда управления системой умного дома – на порту 48080. По умолчанию Apache принимает соединения на порты 80 (http) и 443 (https) (слушает эти порты), поэтому для первого случая ничего делать не нужно, а вот со вторым сейчас разберемся.
Чтобы заставить Apache слушать дополнительные порты, а виртуальные хосты принимать соединения с этих портов, требуется подправить два конфига.
1) Открываем и правим файлик «/etc/apache2/ports.conf», добавив в него строку «Listen 48080», тем самым разрешив Apache слушать дополнительный порт:
2) Открываем и правим конфиг виртуального хоста «/etc/apache2/sites-available/имя_конфига.conf», изменив в нем номер порта, с которого нужно принимать соединения:
Перезапускаем конфиги Apacche:
#> systemctl reload apache2
Проверяем:
Что и требовалось получить.
если непонятно, откуда взялся «test-site1.ru», то читайте предыдущую статью
Замечания:
Поскольку у нашего сервера всего один IP-адрес, то обратиться к этому сайту можно с любого доменного имени, привязанного к данному IP, указав в конце номер порта после двоеточия.
Если мы деактивируем виртуальный хост с назначенным портом 48080, то при попытке обращения к нему будем отправлены на дефолтный сайт web-сервера.
HTTPS (SSL/TLS)
HTTPS – тот же гипертекстовый протокол, но использующий защищенную схему передачи данных между сервером и клиентом (браузером, к примеру).
Если у вас есть сайт, на котором просто имеется какая-то шир.потребная информация и пара фоток красивых берёзок, то вам будет достаточно обычного HTTP, поскольку «угонять» у вас особо нечего. Но, как только в игру вступает обмен какими-либо ценными данными (логины, пароли, данные банковских карт, документы, интимные фотки и т.д.), то тут уже пригодится HTTPS.
Смысл HTTPS в том, что он использует для установления сессии протокол SSL/TLS (SSL уже подустарел), а последний, в свою очередь, использует сертификаты и ключи (как самозаверенные, так и заверенные в глобальных центрах сертификации) для шифрования данных. Зашифрованные с использованием ключей данные достаточно сложно раскрыть, даже если они и будут перехвачены в великой глобальной сетке (время и сложность расшифровки будет зависеть от битности ключа – выше битность – сложнее сломать, но и тяжелее переваривать самой системе).
Что касается сертификатов. Как я уже сказал, есть самозаверенные (или самоподписанные) «самопалы» и сертификаты, заверенные в доверенных центрах сертификации (так скажем, «официальные» сертификаты). Чем они отличаются друг от друга?
Первое отличие в том, что «самопал» (созданный вами и подписанный самостоятельно на сервере, например) не будет являться доверенным, поскольку отсутствует в базах данных браузеров и сертификационных центров, а это значит, что никто не может гарантировать его подлинность. Иными словами, встает вопрос верификации. «Самопалы» проверить нигде невозможно, и поэтому существует гипотетическая возможность напороться на MITM-атаку. Посему, такие сертификаты лучше использовать только в личных целях без привлечения широкой аудитории, использующей на сайте персональные данные.
Что касаемо центров сертификации, то оные являются третьей доверенной стороной, у которой можно независимо верифицировать сертификат и удостовериться в безопасности обмена данными.
Используя «самопал» в браузере вы получите вот такую картину:
Соединение будет условно защищенным и браузер не будет ему доверять несмотря на наличие сертификата, поскольку уровень защиты «самопалов» на порядок ниже.
Нет, параноить не стоит, поскольку визит на такой сайт не означает, что вас тут же "нахлобучат", но нужно иметь ввиду, что защита тут не на высшем уровне, и анализировать, что, куда и для чего вводите.
С сертификатами, полученными в доверенном центре безопасности, таких проблем нет. Они имеются в сертификационных базах данных и вопросов не вызывают.
Но, в обоих случаях соединения будут считаться защищенными, о чем свидетельствует закрытый замок в адресной строке браузера:
Второе отличие самозаверенных сертификатов от «официальных» в том, что последние стоят денег. На момент написания статьи самый простой «официальный» SSL-сертификат для физ.лица стоил порядка 1100 рублей за год.
Если вы пользуетесь услугами хостеров, то имейте ввиду, что иногда они раздают простенькие сертификаты в качестве бонусов.
HTTPS в Apache
Итак, ближе к нашей песочнице.
Базовый пакет Apache уже содержит в себе джентльменский набор для работы с HTTPS, нужно только довести его до ума и заточить под свои нужды.
Генерация самоподписных сертификатов и ключей – тема отдельная и ее мы рассмотрим позже. Сейчас будем использовать пока то, что «из коробки» дает нам Apache.
Итак, дано:
- Сайт с доменным именем test-site2.ru
Что хотим:
- Получить рабочий https://test-site2.ru
Решение.
Первым делом нужно активировать модуль поддержки SSL в Apache и полностью его (apache) рестартануть:
#> a2enmod ssl
#> systemctl restart apache2
Далее копируем файл дефолтного SSL-конфига хоста, обозвав его понятным нам образом:
#> cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/site2ru-ssl.conf
Теперь подкрутим этот конфиг («/etc/apache2/sites-available/site2ru-ssl.conf») под себя:
(посмотреть листинг рабочего файла конфига можно на моем сайте: site2ru-ssl.conf)
- Прописываем алиасы, путь к корневой директории хоста и директорию (тоже корневую, в моем случае), к которой будут применяться дополнительные правила (.htaccess):
- Исключаем использование протокола SSL старой версии, добавив строку «SSLProtocol all –SSLv2»:
- Проверяем строки с указанием расположения «пробных» сертификатов и ключей (и желательно проверить их фактическое наличие в указанной директории):
Сохраняем файлик.
Теперь активируем хост и перезагрузим конфиги Apache:
#> a2ensite site2ru-ssl.conf
#> systemctl reload apache2
Проверяем:
Понимаем риск и продолжаем:
Что и требовалось получить.
***
Виртуальные HTTPS-хосты множатся так же, как и обычные (см. предыдущую статью), только с использованием конфига для HTTPS (аналогично рассмотренному выше). В качестве примера - листинг конфига для test-site1.ru в SSL обертке.
Да, использовать один самозаверенный сертификационный набор для нескольких сайтов можно, но это все равно, что есть из одной тарелки всей семье.
Редирект с HTTP на HTTPS
Для чего он нужен? Как часто в адресной строке браузера вы набираете «http://» или «https://»? Правильно – или никогда или крайне редко. Сейчас браузеры даже не отражают протокольную вводную, если специально не ткнуть в адресное поле. Наберите, например, «yandex.ru» и после загрузки ткните в адресную строку:
Да, показывает https, НО, набрав в адресной строке «yandex.ru» мы изначально использовали отнюдь не механизм https, поскольку по умолчанию браузер отрабатывает классический http и просится на 80-й порт, если ему явно не указать какой протокол (и/или порт) использовать. Но, тем не менее, мы попали на https и используем 443 порт.
Это называется редирект или по-русски – перенаправление.
Вариантов редиректа множество. Самые популярные:
- при помощи конфигурации хоста (директива redirect);
- при помощи файла «.htaccess» (ReWrite) (рассмотрим в следующей статье).
Реализуется редирект в конфиге хоста достаточно просто.
Для начала включим в Apache модуль «alias» (обычно включен, но все же…) и рестартанем Apache:
#> a2enmod alias
#> systemctl restart apache2
Теперь в обычном http конфиге
(«/etc/apache2/sites-available/tsite2ru.conf»)
хоста test-site2.ru добавим директиву «Redirect / https://test-site2.ru»:
Сохраняем файлик и перезагружаем конфиги Apache:
#> systemctl reload apache2
Отныне все запросы, приходящие на этот виртуальный http хост будут переадресованы на виртуальный хост https.
Шпаргалка:
Активировать (деактивировать) модуль Apache: a2enmod (a2dismod) имя_модуля
Рестарт Apache: systemctl restart apache2
Перезагрузка конфигов Apache: systemctl reload apache2
На этом сегодня все!
В следующей статье про .htaccess и .htpasswd как средства защиты и управления.
Ставьте лайк и подписывайтесь!
До связи!