Stunnel centos 7 настройка

Обновлено: 04.07.2024

Инструкция применима к CentOS версий 7 и 8, CentOS mini (минимальная сборка), Fedora.

Базовая настройка сети

Смотрим все установленные сетевые адаптеры в системе:

В результате получаем что-то подобное:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:50:56:81:28:3c brd ff:ff:ff:ff:ff:ff
inet 192.168.156.22/22 brd 192.168.159.255 scope global ens32
valid_lft forever preferred_lft forever
3: ens34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:50:56:81:3f:22 brd ff:ff:ff:ff:ff:ff
inet 10.243.254.68/26 brd 10.243.254.127 scope global ens34
valid_lft forever preferred_lft forever

* Из примера видно, что в моем CentOS есть 3 сетевых карты — lo (локальная петля), ens32 и ens34 — сетевые Ethernet адаптеры.

Если нужно настроить сеть для адаптера ens32, открываем на редактирование следующий конфигурационный файл:

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

DEVICE=ens32
BOOTPROTO=static
IPADDR=192.168.0.155
NETMASK=255.255.255.0
GATEWAY=192.168.0.1
DNS1=192.168.0.54
DNS2=192.168.0.11
ONBOOT=yes

. а также для CentOS 8 добавим:

Основные опции

Опция Описание Возможные значения
DEVICE Имя сетевого адаптера Должно совпадать с именем в системе. В данном примере ens32
BOOTPROTO способ назначения IP-адреса static: ручное назначение IP, dhcp: автоматическое получение IP
IPADDR IP-адрес адрес, соответствующий вашей сети
NETMASK Сетевая маска должна соответствовать вашей сети
GATEWAY Шлюз по умолчанию IP-адрес сетевого шлюза
DNS1 Основной DNS-сервер IP-адрес сервера имен
DNS2 Альтернативный DNS-сервер IP-адрес сервера имен
ONBOOT Способ запуска сетевого интерфейса yes: автоматически при старте сервера, no: запускать вручную командой
NM_CONTROLLED Указываем, должен ли интерфейс управляться с помощью NetworkManager yes: управляется NetworkManager, no: не может управляться NetworkManager

Чтобы настройки применились, перезапускаем сетевую службу.

systemctl restart network

б) для CentOS 8 вводим 2 команды:

systemctl restart NetworkManager

nmcli networking off; nmcli networking on

* в большей степени, это основное отличие версий 7 и 8. Чтобы команды смогли поменять настройки, для интерфейсов необходима настройка NM_CONTROLLED=yes.

Дополнительные опции (не обязательны для работы сети)

Настройка сети из консоли (командами)

Настройка из консоли будет работать только до перезагрузки системы. Ее удобно применять для временного конфигурирования или проведения тестов.

Назначение IP-адреса или добавление дополнительного к имеющемуся:

ip a add 192.168.0.156/24 dev ens32

* в данном примере к сетевому интерфейсу ens32 будет добавлен IP 192.168.0.156.

Изменение IP-адреса:

ip a change 192.168.0.157/24 dev ens32

* однако, по факту, команда отработает также, как add.

Удаление адреса:

ip a del 192.168.163.157/24 dev ens32

Добавление маршрута по умолчанию:

ip r add default via 192.168.0.1

Добавление статического маршрута:

ip r add 192.168.1.0/24 via 192.168.0.18

Удаление маршрутов:

ip r del default via 192.168.160.1

ip r del 192.168.1.0/24 via 192.168.0.18

Команда ifconfig

В новых версиях CentOS утилита ifconfig не установлена и при вводе одноименной команды можно увидеть ошибку «Команда не найдена». Необходимо либо воспользоваться командой ip (ip address), либо установить утилиту ifconfig.

yum install ifconfig

yum install net-tools

Настройка WiFi

Принцип настройки беспроводной сети на CentOS не сильно отличается от проводной.

Создаем конфигурационный файл со следующим содержимым:

ESSID="dmoskwifi"
MODE=Managed
KEY_MGMT=WPA-PSK
TYPE=Wireless
BOOTPROTO=none
NAME=dmoskwifi
ONBOOT=yes
IPADDR=192.168.1.50
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
DNS1=192.168.1.1
DNS2=77.88.8.8

* где dmoskwifi — название WiFi сети (SSID).

Несколько IP на одном сетевом адаптере

В зависимости от версии операционной системы, дополнительные адреса добавляются посредством:

  1. Псевдонимов — создание нового виртуального интерфейса с названием <имя интерфейса>:<номер>.
  2. Добавлением IPADDRx и NETMASKx в конфигурационном файле.

Рассмотрим оба варианта подробнее.

Создание псевдонимов (более ранние версии CentOS 7 и ниже)

Создаем новый конфигурационный файл для сетевого интерфейса:

DEVICE=ens32:1
BOOTPROTO=static
IPADDR=192.168.0.156
NETMASK=255.255.255.0
GATEWAY=192.168.0.1
DNS1=192.168.0.54
DNS2=192.168.0.11
ONBOOT=yes

* где ens32 — имя физического интерфейса, :1 — виртуальный номер.

Перезапускаем сетевые службы.

Настройка конфигурационного файла (поздние версии CentOS 7 и выше)

Открываем конфигурационный файл для сетевого интерфейса, например:

DEVICE=ens32
BOOTPROTO=static
IPADDR=192.168.0.155
NETMASK=255.255.255.0
IPADDR1=192.168.0.156
NETMASK1=255.255.255.0
IPADDR2=192.168.0.157
NETMASK2=255.255.255.0
GATEWAY=192.168.0.1
DNS1=192.168.0.54
DNS2=192.168.0.11
ONBOOT=yes

* где ens32 — имя физического интерфейса, дополнительные адреса задаются с помощью опций IPADDR1, IPADDR2, NETMASK1, NETMASK2.

Перезапускаем сетевые службы.

Для автоматического получения IP-адреса от сервера DHCP мы должны задать следующее значение для опции BOOTPROTO в конфигурационном файле:

* в наших примерах выше данный параметр имеет значение static.

Переопределение DNS с помощью dhclient.conf

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

interface "enp0s3"
supersede domain-name-servers 8.8.8.8, 8.8.4.4;
>

* где enp0s3 — имя сетевого интерфейса, который будет получать адрес от сервера DHCP. 8.8.8.8, 8.8.4.4 — адреса, которые будут настоены на интерфейсе, независимо от того, какие предложит сервер DHCP.

Или мы можем использовать адреса от DHCP, но сделать приоритетными свои:

interface "enp0s3"
prepend domain-name-servers 127.0.0.1;
>

* в данном примере, мы зададим в качестве основного сервера DNS — 127.0.0.1.

Чтобы данный метод сработал в CentOS 8, необходимо открыть файл:

В раздел [main] добавить:

Переопределение DNS в NetworkManager (альтернативный способ)

Метод, описанный выше по переопределению DNS не подходит для NetworkManager без изменения настройки dhcp, так как адреса будут получены и обработаны с помощью встроенных методов. Выше, предоставлено решение в виде настройки dhcp=dhclient, однако мы рассмотрим альтернативный способ, на случай, если кому-то это пригодится.

Очень часто возникает потребность защитить от различных систем мониторинга работу SSH, VPN, либо других сервисов. С этим отлично справится stunnel, который мы и рассмотрим в данной статье.

Введение

Мы рассмотрим работу с данным программным продуктом на примере дистрибутива Fedora (и CentOS с подключённым репозиторием EPEL7) и будем защищать OVN сервер.

Установка stunnel

Пакет доступен в главном репозитории Fedora. Установим его:

Настройка сервера stunnel

Все файлы конфигурации сервера должны находиться в каталоге /etc/stunnel, поэтому создадим главный конфиг stunnel.conf и укажем правильные права доступа:

Листинг файла /etc/stunnel/stunnel.conf:

Создадим каталог для индивидуальных конфигов защищаемых сервисов:

Листинг файла /etc/stunnel/conf.d/ovn.conf:

Создание сертификатов

Stunnel будет осуществлять аутентификацию клиентов при помощи сертификатов.

Создадим каталог для их хранения:

Сгенерируем сертификат для нашего сервера:

На выходе мы получим файлы server.crt (открытый ключ) и server.key (секретный ключ). Загрузим их на сервер в каталог /etc/stunnel/certs любым удобным для нас способом и установим chmod 0600:

Сгенерируем сертификаты для клиентов (каждый клиент должен выполнять этот шаг самостоятельно, а затем лишь передать свой открытый ключ (файл client.crt) на сервер):

Объединим все открытые ключи клиентов в единый бандл:

Скопируем полученный clients.pem на сервер любым способом и установим chmod 0644:

При появлении нового клиента его публичный ключ должен быть добавлен в бандл, а сервис stunnel перезапущен.

Запуск сервера

Теперь мы наконец готовы запустить наш сервер:

Настройка клиентов

Создадим каталог для хранения пользовательских сертификатов:

Создадим конфиг клиента client.conf и установим ему корректные права доступа:

Листинг файла /etc/stunnel/client.conf:

Скопируем публичный ключ сервера server.crt, а также клиентский сертификат (открытый (client1.crt) и закрытый (client1.key) ключи) в /etc/stunnel/certs и установим им правильный chmod:

Теперь изменим OVN подключение так, чтобы в качестве IP-адреса сервера использовался 127.0.0.1:1194.

Программа Stunnel предназначена для развертывания шифрования SSL между удаленным клиентом и локальным или удаленным сервером. Stunnel добавляет функциональность SSL к наиболее часто используемым демонам Inetd (например, POP2, POP3) и IMAP-серверам без каких-либо изменений в коде программы.

Stunnel превращает любой небезопасный TCP-порт в зашифрованный с помощью криптографического пакета OpenSSL. Это похоже на небольшую безопасную VPN, которая работает на определенных портах.

Примечание: данное руководство было протестировано на виртуальных выделенных серверах Ubuntu 12.04, Ubuntu 12.10, Ubuntu 13.04.

1: Подготовка системы

При помощи нижеприведенных команд обновите список пакетов и сами пакеты:

apt-get update
apt-get upgrade

2: Установка Stunnel

Программу Stunnel можно установить при помощи стандартного менеджера пакетов:

apt-get install stunnel4 -y

3: Настройка Stunnel

Настройки Stunnel хранятся в файле stunnel.conf, который по умолчанию находится в /etc/stunnel. Чтобы создать этот файл, используйте:

Чтобы идентифицировать себя на сервере, нужно использовать сертификат SSL; для этого необходимо задать путь к этому сертификату в файле stunnel.conf Используйте следующую строку (сам файл сертификата будет создан далее):

Затем нужно указать сервис для взаимодействия с Stunnel. Это может быть любой сервис, который использует сеть (почтовый сервер, прокси-сервер и т.д.).

В данном руководстве для примера будет показано, как защитить трафик между прокси-сервером Squid и клиентом, использующим Stunnel. Инструкции по установке Squid можно найти в разделе 6.

Указав название сервиса, взаимодействующего с Stunnel, нужно указать Stunnel, на каком порте нужно прослушивать данный сервис. Это может быть любой из 65535 портов, если только он не заблокирован другим сервисом или фаерволом.

[squid] accept = 8888

Далее нужно указать в конфигурационном файле порт и IP-адрес сервиса, для которого создается безопасный туннель. В основном Stunnel принимает пакеты от безопасного порта, а затем пересылает их на порт и IP-адрес указанного сервиса.

По умолчанию Squid-прокси запускается на локальном хосте и использует порт 3128; следовательно, чтобы программа Stunnel могла принимать соединения с этим сервисом, в данном случае в конфигурационный файл нужно внести следующую строку:

В целом конфигурационный файл stunnel.conf должен иметь такой вид:

client = no
[squid] accept = 8888
connect = 127.0.0.1:3128
cert = /etc/stunnel/stunnel.pem

Примечание: параметр client = no не является обязательным, поскольку Stunnel по умолчанию работает в режиме сервера.

4: Создание SSL-сертификата

Stunnel использует сертификат SSL для защиты соединений. Такой сертификат можно легко создать с помощью пакета OpenSSL:

openssl genrsa -out key.pem 2048
openssl req -new -x509 -key key.pem -out cert.pem -days 1095
cat key.pem cert.pem >> /etc/stunnel/stunnel.pem

Вышеприведенные команды генерируют закрытый ключ, создают сертификат при помощи этого ключа, а затем объединяют эти файлы в один файл по имени stunnel.pem, который и будет использовать Stunnel.

Примечание: при создании сертификата нужно указать некоторую информацию; обратите внимание на поле Common Name – в нем нужно указать имя хоста или IP-адрес сервера.

Затем настройте автоматический запуск Stunnel. Для этого откройте файл /etc/default/stunnel4 в текстовом редакторе:

и измените значение параметра ENABLED на 1:

В завершение перезапустите Stunnel, чтобы обновить настройки.

5: Установка прокси-сервера Squid

Чтобы установить Squid, используйте:

apt-get install squid3 -y

6: Настройка Stunnel как клиента

Примечание: данный раздел демонстрирует установку и настройку Stunnel в качестве клиента в Windows, но настройки и инструкции по установке программы в Linux или даже Android останутся такими же. Единственное отличие – местонахождение конфигурационного файла stunnel.conf.

Для того, чтобы Stunnel мог взаимодействовать с сервером, сертификат SSL (см. раздел 4) должен находиться на клиенте. Существует множество способов перемещение файла stunnel.pem с сервера, но в данном случае для этого используется протокол SFTP – одновременно достаточно простой и безопасный.

При помощи SFTP-клиента (например, Filezilla) подключитесь к серверу и загрузите файл stunnel.pem из каталога /etc/stunnel/ на клиент.

Примечание: чтобы получить больше информации о работе SFTP, читайте руководство «Использование SFTP для безопасного обмена файлами с удаленным сервером».

Скачайте Stunnel с сайта проекта.

Установите Stunnel в любой удобной точке системы. Затем перейдите в папку Stunnel и переместите в нее файл сертификата stunnel.pem.

Создайте в папке Stunnel файл stunnel.conf (если такого файла еще нет). Откройте файл при помощи текстового редактора (например, Notepad).

Для начала нужно указать путь к сертификату, который в Windows находится в каталоге Stunnel.

Примечание: в Ubuntu этот файл находится в каталоге /etc/stunnel/.

В данном случае нужно перевести Stunnel в режим клиента. Поместите следующую строку в файл:

Далее нужно указать конфигурации сервиса, который нужно использовать.

Сначала укажите имя сервиса, затем его IP и порт, который должна прослушивать программа Stunnel на клиенте.

[squid] accept = 127.0.0.1:8080

Для этого подойдет любой порт на клиентском компьютере, если он не занят другим сервисом и не блокируется брандмауэром.

Затем нужно настроить Stunnel для передачи пакетов, поступающих на данный порт, серверу Stunnel; для этого укажите IP-адрес виртуального сервера и порт, заданный при настройке сервера Stunnel (в данном случае это порт 8888):

connect = [внешний IP-адрес]:8888

В итоге файл stunnel.conf будет иметь такой вид:

cert = stunnel.pem
client = yes
[squid] accept = 127.0.0.1:8080
connect = [Server’s Public IP]:8888

Сохраните и закройте файл.

Готово! Взаимодействие клиента и сервера надежно защищено SSL-туннелем. Теперь для подключения к любому сервису VPS нужно вводить не только IP, но также и порт, заданный в параметре accept конфигурационного файла Stunnel.

Например, чтобы подключиться к прокси-серверу Squid на облачном сервере, нужно указать 127.0.0.1:8080, и Stunnel автоматически подключится к сервису, запущенному на указанном порте. Чтобы защитить трафик, настройте браузер использовать порт 8080 в качестве прокси.


Существует бесчисленное множество сервисов, которые предоставляют VPN, в том числе и бесплатные. Вот несколько причин, почему бесплатный VPN — это плохая идея.

  1. Качество. Те, кто пользовался бесплатным VPN, знают, что в большинстве случаев сервис просто ужасен: низкая скорость, постоянные обрывы. Это и неудивительно, ведь, кроме тебя, им одновременно может пользоваться еще пара сотен человек.
  2. Безопасность. Даже если качество более-менее сносное, ты не знаешь, что на самом деле происходит с твоим трафиком. Хранится и анализируется ли он, кто и в каких целях оперирует сервисом. Бесплатный сыр, как говорится.
  3. Малое количество или полное отсутствие опций и настроек: нет возможности выбрать шифр, протокол и порт. Остается только пользоваться тем, что дали.

С платными сервисами дела обстоят лучше: можно ожидать какого-то гарантированного качества и наличия настроек. Но ты все еще не можешь знать наверняка, хранятся твои логи непосредственно на сервере или нет. К тому же твоего провайдера могут заблокировать.

TLS-трафик OpenVPN

TLS-трафик OpenVPN

Некоторые популярные платные VPN предоставляют средства обхода DPI, но чем больше популярность, тем больше шанс, что провайдер узнает о сервисе и сможет полностью заблокировать доступ к нему. От полной блокировки не защищен никто, но, когда используешь публичный сервис, шанс всегда выше.

Пара слов об OpenVPN

OpenVPN использует два канала: канал управления (control channel) и канал данных (data channel). В первом случае задействуется TLS — с его помощью ведется аутентификация и обмен ключами для симметричного шифрования. Эти ключи используются в канале данных, где и происходит само шифрование трафика.

Что такое stunnel

Stunnel — это утилита для обеспечения защищенного соединения между клиентом и сервером посредством TLS для программ, которые сами шифровать трафик не умеют. Например, можно туннелировать трафик для netcat , vnc и даже bash . В нашем случае stunnel будет использоваться для маскировки трафика OpenVPN под «чистый» TLS, чтобы его было невозможно определить посредством DPI и, следовательно, заблокировать.

С учетом того что OpenVPN использует шифрование для своего канала данных, у нас есть два варианта настройки:

  • использовать шифрование stunnel плюс шифрование канала данных OpenVPN;
  • использовать шифрование stunnel, а шифрование канала данных OpenVPN отключить.

Таким образом, в первом варианте получается два слоя: один от stunnel, второй от OpenVPN. Этот вариант позволит использовать RSA вместе с ECDSA. Недостаток в том, что тратится больше ресурсов, и второй вариант позволит этого избежать. В любом случае настройка stunnel остается неизменной.

Что нам понадобится

Провайдер VPS

Первым делом нужно выбрать провайдера, который нам предоставит виртуальный выделенный сервер (VPS). Что выбирать — дело каждого и зависит от страны и от того, сколько ты готов платить. Главная рекомендация — выбирай страну, наиболее близкую по географическому расположению, это сведет задержку к минимуму. Но, конечно, живя в Китае, покупать сервис в Индии или Пакистане смысла мало.

Выбор ОС

Я буду использовать RHEL 7.4. Для точного копирования команд из статьи годится и CentOS 7 (1708), так как это бесплатная и почти идентичная копия RHEL, основанная на его коде. Возможно, подойдут другие дистрибутивы, а также производные RHEL (Fedora), но пути конфигурационных файлов и версии программ могут отличаться.

Подготовка и первичная настройка

После покупки сервера и установки системы нам нужно попасть на сервер. Я буду делать это с помощью SSH. Вся конфигурация будет проходить в два этапа: настройка на сервере (включает в себя первичную настройку) и настройка клиентов.

После покупки, скорее всего, тебе дадут доступ по SSH с логином root и паролем. Позже лучше создать обычного пользователя, а рутовые команды выполнять после sudo -i . Нужно это в том числе для защиты от брутфорса — пользователь root общеизвестный, и при попытках брута, вероятней всего, будет использоваться именно он.

Для начала нам понадобится подключить репозиторий EPEL — пакет openvpn лежит именно там.

На RHEL, CentOS, Fedora, OpenSUSE и, возможно, других установлен и включен по умолчанию SELinux. Проверить это можно командой getenforce или sestatus . Чтобы не нырять в дебри его настроек и спастись от возможной головной боли, мы переведем его в режим permissive . В этом режиме он будет оповещать нас о нарушениях политик безопасности, но предпринимать никаких действий не станет. Таким образом, у тебя всегда будет возможность его поизучать. Для этого нужно изменить следующую директиву в файле /etc/selinux/config :

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

  • iptables-services — файлы .service для управления утилитой iptables ;
  • openvpn — сам сервер OpenVPN;
  • зачем нужен unzip , попробуй догадаться сам. 🙂

Базовая защита

Поскольку китайские боты и скрипт-киддиз не дремлют и, скорее всего, уже сейчас пробуют подобрать пароль к твоему серверу, перенесем sshd на другой порт и запретим логин от рута. Перед тем как это сделать, нужно убедиться, что в системе существует другой пользователь с доступом по SSH, или добавить нового и установить для него пароль.

где eakj — имя пользователя. В идеале нужно использовать ключи SSH, но в этом случае обойдемся паролем. Не забудь проверить, раскомментирована ли строчка %wheel ALL=(ALL) ALL в файле /etc/sudoers . Теперь изменим следующие директивы в файле /etc/ssh/sshd_config :

Перечитаем конфиги ( systemctl reload sshd ), убедимся, что sshd поднялся без проблем ( systemctl status sshd ), и попробуем открыть дополнительную сессию SSH, не закрывая текущей.

Продолжение доступно только участникам

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Читайте также: