megavolt0

Саурон приказал своему орккомнадзору фильтровать эти запросы, записывать их и, в некоторых случаях, подменять. То есть Саурон не видит, что хоббит делал на сайте, ведь там протокол HTTPS, но вот какие сайты хоббит запрашивал — он видит. А если хоббит захотел открыть эльфийский сайт, то можно в DNS запросе подменить ответ и хоббит вместо эльфийского сайта увидит злобную картинку от орккомнадзора. Или просто обвинить хоббита в сочувствии и поддержке эльфов, признать его эльфоагентом. Тогда мудрые эльфы придумали протокол DNS-over-HTTPS (сокращенно DOH). Это когда DNS-сервер прикидывается обычным веб-сервером, работающим по протоколу HTTPS, и интернет-браузер хоббита запрашивает у этого сервера IP-адреса сайтов по зашифрованному протоколу.

Саурон сначала приуныл, но потом до него дошло, что DNS сервера эльфов, поддерживающие протокол DOH, это те же сервера, что и работающие по обычному DNS протоколу. Да и серверов таких совсем не много. Тогда Саурон приказал своим оркам блокировать любые запросы хоббитов к известным серверам, поддерживающим DOH. Это заставит хоббита пользоваться мордорскими DNS серверами и можно и дальше фильтровать/записывать/подменять его запросы. Что ж делать хоббиту? Ну, например, использовать личный VPN, как написано в начале статьи. Но у хоббита есть потребность обойтись без VPN. Хоббит хитрый и он подумал: обращения к серверу DOH всё равно выглядят как обычный HTTPS, выдаёт их в основном только то, что они идут к известным Саурону DNS-серверам. Что если сделать свой web-сервер, такой же, как тысячи других, работающий по HTTPS, но при этом способный выступать посредником между хоббитом и публичным DNS-сервером. Т.е. сервер хоббита будет принимать зашифрованные DNS запросы, пересылать их публичному эльфийскому DNS-серверу, принимать ответы, зашифровывать и отправлять обратно хоббиту. Получится реверс-прокси сервер для DOH. Расположить его конечно нужно там, куда не дотянуться беспредельничающие орки.

Для Саурона это будет выглядеть так, как будто хоббит ходит на очередной web-сайт. Конечно, если он начнёт вглядываться очень пристально в конкретного хоббита, то через некоторое время поймет что к чему. Но хобиттов в Мордоре миллионы и Саурон предпочитает бить по площадям. Кроме того DOH реверс-прокси лишит Саурона списка эльфийских сайтов, которые запрашивал хоббит. А это может помочь хоббиту в его не простой жизни.

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

Ниже будут конфиги. Их форматирование будет безбожно убито. Они всё равно останутся рабочими, но будут некрасивенькими. Конфиги в нормальном виде можно найти в оригинале статьи.

Для начала хоббиту нужно заблаговременно озаботится арендой доменного имени. Как это сделать примерно описано в начале этой статьи. Предположим хоббит арендовал доменное имя theshire.ru. В принципе он мог его и использовать для реверс-прокси. Но можно добавить имя третьего уровня. Тогда сам домен можно будет потом использовать для чего-то ещё. Так больше гибкости. Хоббит решил сделать имя третьего уровня ns1.theshire.ru. У него получились такие записи домена:

В этих записях вписан IP арендованного хоббитом VPS. Думаю не нужно напоминать, что виртуальный сервер должен находится за пределами Мордора. Хоббит, используя эту статью, арендовал предельно дешёвую виртуалку с такими параметрами:

Как видно, на сервере установлена операционная система CentOS 7. Далее нужно настроить защищённый вход на сервер, как описано здесь, и файрволл сервера, как описано здесь. Только при настройке файрволла нужно в ipt-set записать другое содержимое:

#!/bin/sh

IF_EXT="venet0"

IPT="/sbin/iptables"

IPT6="/sbin/ip6tables"

# flush

$IPT --flush

$IPT -t nat --flush

$IPT -t mangle --flush

$IPT -X

$IPT6 --flush

# loopback

$IPT -A INPUT -i lo -j ACCEPT

$IPT -A OUTPUT -o lo -j ACCEPT

# default

$IPT -P INPUT DROP

$IPT -P OUTPUT DROP

$IPT -P FORWARD DROP

$IPT6 -P INPUT DROP

$IPT6 -P OUTPUT DROP

$IPT6 -P FORWARD DROP

# allow forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward

# NAT

# #########################################

# SNAT - local users to out internet

$IPT -t nat -A POSTROUTING -o $IF_EXT -j MASQUERADE

# INPUT chain

# #########################################

$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# ssh

$IPT -A INPUT -i $IF_EXT -p tcp --dport 22 -j ACCEPT

# nginx

$IPT -A INPUT -i $IF_EXT -p udp --dport 53 -j ACCEPT

$IPT -A INPUT -i $IF_EXT -p tcp --dport 80 -j ACCEPT

$IPT -A INPUT -i $IF_EXT -p tcp --dport 443 -j ACCEPT

$IPT -A INPUT -i $IF_EXT -p tcp --dport 853 -j ACCEPT

# OUTPUT chain

# #########################################

$IPT -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Не забудьте про правильное имя внешнего интерфейса в переменной IF_EXT (вторая строчка), как описано в этой статье.

Обновим сервер и установим необходимые утилиты:

yum -y update

yum -y install net-tools wget

Проверим, не сидит ли какая-то дефолтная http служба на нужном нам 80-ом порту:

netstat -tulnp | grep 80

Сидит, собака

Убиваем её

systemctl stop httpd

systemctl disable httpd

yum -y remove httpd

Теперь сервер готов. Реверс-прокси сделаем конечно же на nginx. Ранее уже была статья про использование его в такой роли. Ретранслировать DOH запросы не на столько простая задача, как кажется. Дабы не изобретать велосипед, используем уже готовый проект NGINX-DNS. Благодаря скриптам этого проекта мы не только сделает DOH между хоббитом и его реверс прокси, но и обмен по протоколу DOT между реверс-прокси и публичным DNS. Т.е даже хостинг VPS не сможет заглянуть в трафик хоббита! Кстати, для этого проекта подойдёт не каждый nginx. Тот, который в epel-release, НЕ подойдёт. Поэтому epel-release ни в коем случае не устанавливаем, он всё поломает. Накатим репозиторий с правильным nginx:

cd /tmp

wget http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release...

rpm -ivh nginx-release-centos-7-0.el7.ngx.noarch.rpm

Проверим, что операционная система теперь знает, где брать nginx и модули к нему:

yum list | grep nginx

Отлично. Устанавливаем nginx и нужный модуль:

yum -y install nginx.x86_64 nginx-module-njs.x86_64

Еще раз проверьте, что файрволл настроен и открытые порты выглядят так:

iptables -L -n

Теперь любым удобным способом откроем для редактирования файл /etc/nginx/conf.d/default.conf (хоббитам с лапаками рекомендую использовать WinSCP и Notepad++). В этом файле сразу после строчки

server {

нужно найти строчку

server_name localhost;

и вместо localhost вписать своё доменное имя. У хоббита это так (не удалите случайно точку с запятой!):

server_name ns1.theshire.ru;

Файл можно сохранить и закрыть. Запускаем nginx и смотрим, что всё в порядке:

systemctl start nginx

systemctl status nginx

Дальше в браузере на компьютере переходим по доменному адресу сервера. У хоббита это http://ns1.theshire.ru

Оно живое! Но только по протоколу HTTP, а нам надо по HTTPS. Для этого нужно сделать SSL сертификаты от letsencryp. Сертификаты весь прогрессивный эльфийский мир делает с помощью Certbot. Поскольку epel-release мы не используем, то ставить certbot хоббиту придётся через жопу Pip.

Накатим питона с либами:

yum -y install python3 augeas-libs

и подготовим виртуальную среду:

python3 -m venv /opt/certbot/

/opt/certbot/bin/pip install --upgrade pip

Отлично. Можно и накатить сам certbot:

/opt/certbot/bin/pip install certbot certbot-nginx

ln -s /opt/certbot/bin/certbot /usr/bin/certbot

Теперь сделаем сертификаты:

certbot --nginx

Соглашаемся с условиями использования, указываем почту (желательно настоящую, туда, если что, будут спамить о проблемах с сертификатами) и отказываемся от спама. На запрос доменного имени нужно выбрать своё. У хоббита получилось так:

Если на этом этапе не удаётся создать сертификаты, появляются ошибки, то:

--  ещё раз проверить настройки файрволла и доступность страницы приветствия по (у хоббита это http://ns1.theshire.ru);

--  возможно домен арендован и/или его записи внесены менее 24 часов назад и не все DNS серверы успели их синхронизировать. Тогда придётся подождать.

Современный certbot настолько преисполненный, что он сам вписал настройки HTTPS в nginx и сам применил их. Хоббитам остаётся только открыть свой доменный адрес по HTTPS:

SSL сертификаты выдаются всего на три месяца. Дабы они не прокисли, добавляем в планировщик задачу по обновлению:

echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew -q" | tee -a /var/spool/cron/root > /dev/null

и проверяем результат:

crontab -l

Теперь превратим наш безобидный nginx в боевой DOH сервер. Для начала остановим его:

systemctl stop nginx

Теперь из проекта NGINX-DNS с гитхаба скопируем нужные нам файлы и засунем в папку nginx. При этом старые конфиги nginx удалять не будем, а просто добавим к имени приставку .old:

cd /tmp

wget https://github.com/TuxInvader/nginx-dns/archive/refs/heads/m...

unzip master.zip

cp -r nginx-dns-master/njs.d /etc/nginx/

cd /etc/nginx/

mv nginx.conf nginx.conf.old

mv ./conf.d/default.conf default.conf.old

В папке /etc/nginx/ создадим файл nginx.conf с вот таким содержимым:

user nginx;

worker_processes auto;

load_module modules/ngx_stream_js_module.so;

error_log /var/log/nginx/error.log error;

#error_log off;

pid /var/run/nginx.pid;

events {

worker_connections 1024;

}

http {

include /etc/nginx/mime.types;

default_type application/octet-stream;

# logging directives

log_format doh '$remote_addr - $remote_user [$time_local] "$request" '

'[ $msec, $request_time, $upstream_response_time $pipe ] '

'$status $body_bytes_sent "$http_x_forwarded_for" '

'$upstream_http_x_dns_question $upstream_http_x_dns_type '

'$upstream_http_x_dns_result '

'$upstream_http_x_dns_ttl $upstream_http_x_dns_answers '

'$upstream_cache_status';

access_log /var/log/nginx/doh-access.log doh;

#access_log off;

resolver 1.1.1.1 valid=10s;

# This upstream connects to a local Stream service which converts HTTP -> DNS

upstream dohloop {

zone dohloop 64k;

server 127.0.0.1:8053;

keepalive_timeout 60s;

keepalive_requests 100;

keepalive 10;

}

# Proxy Cache storage - so we can cache the DoH response from the upstream

proxy_cache_path /var/cache/nginx/doh_cache levels=1:2 keys_zone=doh_cache:10m;

# The DoH server block

server {

server_name ns1.theshire.ru;

root /usr/share/nginx/html;

# Listen on standard HTTPS port, and accept HTTP2, with SSL termination

listen 443 ssl http2 default_server;

ssl_certificate /etc/letsencrypt/live/ns1.theshire.ru/fullchain.pem; # managed by Certbot

ssl_certificate_key /etc/letsencrypt/live/ns1.theshire.ru/privkey.pem; # managed by Certbot

ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

ssl_session_cache shared:ssl_cache:10m;

ssl_session_timeout 10m;

# DoH may use GET or POST requests, Cache both

proxy_cache_methods GET POST;

# Return 404 to all responses, except for those using our published DoH URI

location / {

return 404 "404 Not Found\n";

}

# This is our published DoH URI

location /dns-query {

# Proxy HTTP/1.1, clear the connection header to enable Keep-Alive

proxy_http_version 1.1;

proxy_set_header Connection "";

# Enable Cache, and set the cache_key to include the request_body

proxy_cache doh_cache;

proxy_cache_key $scheme$proxy_host$uri$is_args$args$request_body;

# proxy pass to the dohloop upstream

proxy_pass http://dohloop;

}

}

server {

if ($host = ns1.theshire.ru) {

return 301 https://$host$request_uri;

} # managed by Certbot

listen 80;

listen [::]:80;

server_name ns1.theshire.ru;

return 404; # managed by Certbot

}

}

# DNS Stream Services

stream {

# DNS logging

log_format dns '$remote_addr [$time_local] $protocol "$dns_qname"';

access_log /var/log/nginx/dns-access.log dns;

#access_log off;

# Include the NJS module

js_include /etc/nginx/njs.d/nginx_stream.js;

# The $dns_qname variable can be populated by preread calls, and can be used for DNS routing

js_set $dns_qname dns_get_qname;

#DNS upstream pool.

upstream dns {

zone dns 64k;

server 1.1.1.1:53;

}

# DNS over TLS upstream pool

upstream dot {

zone dot 64k;

server 1.1.1.1:853;

}

# DNS(TCP) and DNS over TLS (DoT) Server

# Upstream can be either DNS(TCP) or DoT. If upstream is DNS, proxy_ssl should be off.

server {

# DNS TCP

listen 53;

# DNS DoT

listen 853 ssl;

ssl_certificate /etc/letsencrypt/live/ns1.theshire.ru/fullchain.pem; # managed by Certbot

ssl_certificate_key /etc/letsencrypt/live/ns1.theshire.ru/privkey.pem; # managed by Certbot

ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

# This is used to pull out question for logging

js_preread dns_preread_dns_request;

# Enable SSL re-encryption for DoT connection upstream

proxy_ssl on;

proxy_pass dot;

}

# DNS over HTTPS (gateway) Service

# Upstream can be either DNS(TCP) or DoT. If upstream is DNS, proxy_ssl should be off.

server {

listen 127.0.0.1:8053;

js_filter dns_filter_doh_request;

proxy_ssl on;

proxy_pass dot;

}

# DNS(UDP) Server

# DNS UDP proxy onto DNS UDP

server {

listen 53 udp;

proxy_responses 1;

js_preread dns_preread_dns_request;

proxy_pass dns;

}

}

Указанный выше конфиг сделан для нашего хоббита и его доменного имени ns1.theshire.ru. Чтобы переделать файл под другого хоббита и другое доменное имя:

Найти строчки, начинающиеся на «server_name», и заменить в них доменное имя ns1.theshire.ru на своё.

Найти строчки, начинающиеся на «ssl_certificate», и заменить в них путь на сертификат своим. Свой путь можно найти в аналогичных строчках файла /etc/nginx/default.conf.old

Сохраните и закройте файл. Выполните тест корректности конфига командой:

nginx -t

У хоббита хоть и лапки, но прямые. У него получилось с первого раза:

Если есть ошибки, то будут написаны номера строк с ними. Смотрим в эти строки и исправляем. Чаще всего хоббиты нечаяно удаляют «;» в конце строк.

Теперь nginx можно запустить и добавить в автозагрузку.

systemctl start nginx

systemctl enable nginx

Собственно всё. Хоббит сделал сервер который:

1. Может работать как обычный DNS сервер по порту 53/UDP. Если добавить его IP в настройки DNS, например, сетевой карты компьютера, то всё взлетит. Обратите внимание, что это не шифрованный обмен. Обычный DNS. Если этот функционал не нужен, то просто закомментируйте/удалите строку с портом 53 в файле /root/ipt-set и перезагрузите сервер.

2. Принимает запросы по протоколу DOH (по порту 443), расшифровывает их, разбирает, перенаправляет запросы на публичный DNS сервер по зашифрованному протоколу DOT, полученные ответы зашифровывает и отправляет хоббиту.

3. Принимает запросы по протоколу DOТ, расшифровывает их, разбирает, перенаправляет запросы на публичный DNS сервер по, опять же, протоколу DOT, полученные ответы зашифровывает и отправляет хоббиту. Протокол DOT на сегодня не особо распространён в браузерах. Если этот функционал не нужен, то просто закомментируйте/удалите строку с портом 853 в файле /root/ipt-set и перезагрузите сервер.

Хоббиту осталось настроить браузер.

В Mozilla Firefox нужно открыть Настройки -> Параметры сети -> Настроить, в самом низу поставить галочку «Включить DNS через HTTPS» и вписать свой DNS адрес. У нашего хоббита он такой:

https://ns1.theshire.ru/dns-query

Другим хоббитам вместо ns1.theshire.ru нужно вписать свой домен.

В Google Chrome открыть Настройки -> Конфиденциальность и безопасность -> Безопасность -> Использовать безопасный DNS-сервер вписать сервер также, как это указано выше для Firefox. У нашего хоббита это получилось так:

Для других браузеров хоббиту предлагается напрячь лапки и погуглить.

В качестве домашнего задания также предлагается нагуглить, как настроить Windows 10 для использования DOH. Необязательный пункт. Браузеры не зависят от этого и используют настройку, показанную выше.

Дальше хоббит пользуется браузером как обычно. Сайты должны без проблем открываться. Убедится, что сервер работает как надо, можно сходив в файл лога /var/log/nginx/doh-access.log. Там будут логгированы все DNS запросы хоббита по протоколу DOH.

Посмотрев логи умненький хоббит должен подумать, а нужны ли ему эти следы? Если нет, то он в файле /etc/nginx/nginx.conf:

-- находит строчку, начинающуюся на «error_log» и ставит в ее начале #. А вот из строчки «#error_log off;» наоборот символ # убирает.

-- находит строчки, начинающиеся на «access_log» и ставит в их начале #. Во всех строчках «#access_log off;» символ # убирает.

Дальше нужно сохранить файл. Остановить сервер командой:

systemctl stop nginx

удалить все файлы из папки /var/log/nginx/ и запустить сервер обратно:

systemctl start nginx

Теперь никаких следов.

За сим эта часть саги про хоббита заканчивается. Обсуждение в https://t.me/SecFAll_chat

Утаскивать в сообщества запрещаю.

Pritunl — тот же OpenVPN, но с преферансом и куртизанками. Почитать можно здесь. На самом деле Pritunl является оболочкой для OpenVPN, предоставляя удобный графический интерфейс для создания конфигураций OpenVPN сервера, создания пользователей, генерации ключей и т.д. Продукт предназначен для энтерпрайза, но есть и бесплатная версия. Её функционал урезан, однако для личных целей или для малого офиса его вполне достаточно. Установка не сложная, советую попробовать.

Нам понадобится любой VPS с поддержкой TUN/TAP. Pritunl можно поставить практически на любую операционную систему. Про это можно почитать здесь. В рамках данной статьи будет применяться CentOS 7.

Обновим сервер командами:

yum -y install epel-release

yum -y update

Для начала настройте безопасную аутентификацию на сервере, как написано здесь. Далее настроим правила файрволла. В текущей статье будет настраиваться следующая конфигурация: порт для web-консоли — 4445, порт для подключение ovpn-клиентов — 443. Для настроийки файрволла используйте вот эту инструкцию. Единственный момент — в файл ipt-set вписывайте не то, что указано в инструкции, а вот такое содержимое:

#!/bin/sh

IF_EXT="venet0"

VPN_PORT="443"

WEBADMIN_PORT="4445"

IPT="/sbin/iptables"

IPT6="/sbin/ip6tables"

# flush

$IPT --flush

$IPT -t nat --flush

$IPT -t mangle --flush

$IPT -X

$IPT6 --flush

# default

$IPT -P INPUT DROP

$IPT -P OUTPUT DROP

$IPT -P FORWARD DROP

$IPT6 -P INPUT DROP

$IPT6 -P OUTPUT DROP

$IPT6 -P FORWARD DROP

# loopback

$IPT -A INPUT -i lo -j ACCEPT

$IPT -A OUTPUT -o lo -j ACCEPT

$IPT6 -A INPUT -i lo -j ACCEPT

$IPT6 -A OUTPUT -o lo -j ACCEPT

# allow forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward

# INPUT chain

# #########################################

$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPT6 -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# ssh

$IPT -A INPUT -p tcp --dport 22 -j ACCEPT

# pritunl_web

$IPT -A INPUT -p tcp --dport $WEBADMIN_PORT -j ACCEPT

$IPT -A INPUT -p tcp --dport 80 -j ACCEPT

# pritunl_vpn

$IPT -A INPUT -p tcp --dport $VPN_PORT -j ACCEPT

$IPT -A INPUT -p udp --dport $VPN_PORT -j ACCEPT

# OUTPUT chain

# #########################################

$IPT -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

$IPT6 -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

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

Если всё сделано верно, то по команде

iptables -L -n

будет получен такой вывод:

Обратите внимание, что открыт также порт 80. Это нужно для получения и обновления сертификатов от LetsEncrypt для нашей web-консоли. Не лишним будет проверить, что этот порт не занят. Такое может быть, если при установке операционной системы сразу установлен apache или иной web-сервер. Выполните команду:

netstat -tulnp | grep 80

В ответ мы должны получить ровно ничего, а значит порт свободен.

Если система ругается, что -bash: netstat: command not found, то выполняем команду:

yum install net-tools -y

Теперь пробуем:

netstat -tulnp | grep 80

Если в выводе команды видим:

то значит порт занят, в данном случае, службой httpd. Остановим её и уберем из автозагрузки:

systemctl stop httpd

systemctl disable httpd

Таким же способом можно проверить незанятость порта 443.

Теперь добавим репозиторий mongodb командой:

tee /etc/yum.repos.d/mongodb-org-4.0.repo << EOF

[mongodb-org-4.0]

name=MongoDB Repository

baseurl=https://repo.mongodb.org/yum/redhat/7/mongodb-org/4.0/x86_64...

gpgcheck=1

enabled=1

gpgkey=https://www.mongodb.org/static/pgp/server-4.0.asc

EOF

Добавим репозиторий pritunl командой:

tee /etc/yum.repos.d/pritunl.repo << EOF

[pritunl]

name=Pritunl Repository

baseurl=https://repo.pritunl.com/stable/yum/centos/7/

gpgcheck=1

enabled=1

EOF

Импортируем ключи:

rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7....

gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 7568D9BB55FF9E5287D586017AE645C0CF8E292A

gpg --armor --export 7568D9BB55FF9E5287D586017AE645C0CF8E292A > key.tmp; rpm --import key.tmp; rm -f key.tmp

Теперь можно установить mongodb и pritunl командами:

yum -y install pritunl mongodb-org

Запустим службы mongodb и pritunl и добавим в автозагрузку mongodb:

systemctl start mongod pritunl

systemctl enable mongod

Запустите приведенные ниже команды, чтобы увеличить ограничение на количество открытых файлов на сервере. Это нужно для нормальной работы mongodb:

sh -c 'echo "* hard nofile 64000" >> /etc/security/limits.conf'

sh -c 'echo "* soft nofile 64000" >> /etc/security/limits.conf'

sh -c 'echo "root hard nofile 64000" >> /etc/security/limits.conf'

sh -c 'echo "root soft nofile 64000" >> /etc/security/limits.conf'

Когда вы запускаете Pritunl в первый раз, на веб-сервере, работающем через порт 443, вам будет показано приглашение настроить базу данных. Программа установки базы данных запросит ключ установки и URI MongoDB. Чтобы получить ключ установки запустите команду:

pritunl setup-key

В ответ получите тот самый setup-key из цифр и букв.

Теперь можно перейти по адресу https://[IP-адрес вашего сервера] в браузере. Так как сертификат для https пока самоподписанный, то увидим предупреждение. Соглашаемся:

Получаем приглашение настроить базу данных:

Используем секретный ключ, полученный ранее командой pritunl setup-key. Строчку URI не трогаем.

Некоторое время будет идти создание и настройка базы данных.

После это появится запрос логина и пароля.

Логин и пароль получим в ssh-консоли командой:

pritunl default-password

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

Здесь вам нужно сделать как инимум одну настройку: поменять порт с 443 на 4445. Также рекомендую изменить имя пользователя и пароль с дефолтных на свои.

Также, если у Вас есть доменное имя и настроена DNS-запись на IP-адрес сервера (подробнее можно найти в этой статье), то може вписать это имя в поле «Lets Encrypt Domain». Это позволит ходить в консоль по имени, а не по IP-адресу и не получать указанное выше предупреждение браузера при каждом входе. Если использовать доменное имя не планируется, оставьте поле пустым. Вы всегда можете вернуться к этим настройкам позднее.

Когда настройки сделаны, нажмите Save. Если вы ввели доменное имя, то некоторое время будет происходить получение сертификата Lets Encrypt . Обычно 5-10 секунд.

Так как порт мы поменяли, то в браузере нужно открыть новый адрес:

-- https://[IP-адрес вашего сервера]:4445 — если доменное имя не используется

-- https://[имя сервера]:4445 — если доменное имя используется

Теперь мы видим консоль

Осталось сделать еще одну вещь, прежде, чем мы начнем конфигурировать vpn-сервер.

Мы будем в web-консоли создавать vpn-серверы, а pritunl будет сам прописывать правила для них в iptables. При этом, в начале статьи, мы сделали свои настройки iptables. Нужно сделать так, чтобы это всё уживалось и не конфликтовало. Выше, после установки mongodb и pritunl мы добавили в автозагрузку только mongodb. И это неспроста. Теперь в файл /root/ipt-set в самом конце мы допишем строчки:

# Starting Pritunl Service

systemctl start pritunl

Сохраним и перезагрузим сервер командой reboot.

Т.е. теперь у нас будут при запуске сервера отрабатываться настройки iptables из файла ipt-set и только после применения настроек скрипт ipt-set запустит pritunl, а тот уже, в свою очередь, добавит в iptables свои настройки. В итоге никаких конфликтов и никаких лишних доступов.

Всё, ssh-консоль больше не нужна, заходим в web-консоль и работаем с ней. Жмём сверху в меню «Users», а потом кнопку «Add Organization».

Вводим любое имя организации. Не важно.

И нажимаем «Add». Теперь жмём «Add User». Здесь вводим имя будущего пользователя, а также пин-код. В пин-коде должно быть не менее 6 цифр. Он используется как второй фактор при авторизации. Email вводить не обязательно.

Жмём «Add» и получаем запись нового пользователя.

Обратите внимание на иконки слева. Когда создадим vpn-сервер, то с их помощью сможем получить готовый конфиг пользователя.

Сверху в меню выбираем «Servers»

Жмём кнопку «Add Server» и, в появившемся окне, сверху, «Advanced».

На скриншоте цветом выделены параметры, на которые нужно обратить внимание:

-- Name — любое понятное вам имя сервера.

-- Port — порт, на котором будет работать сервер. В моём примере я ставлю 443.

-- Protocol — протокол. В моём примере я ставлю tcp.

-- Encryption Cipher — ставим AES 256bit или 512bit.

-- DNS Server — DNS сервер, к которому будут обращаться клиенты. Я поставил гугловые восьмёрки.

-- Enable Google Authenticator — если поставите галочку, то клиенты смогут дополнительно, при аутентификации, использовать одноразовые пароли из Google Authenticator. Сначала потренеруйтесь без этой опции. Её можно включить позже.

-- Bind Address — впишите внешний IP вашего сервера к которому будет привязан vpn-сервер.

-- Hash Algorithm — ставьте SHA-256.

-- Allow Multiple Devices — если галочка стоит, то клиент сможет использовать свой конфиг и ключи на нескольких устройствах одновременно.

-- Block Outside DNS — если галочка стоит, то клиенты будут использовать только тот DNS -сервер, который прописан здесь.

-- Inter-Client Communication — если галочка стоит, то клиенты могут видеть друг друга по виртуальным IP-адресам.

Настраиваем и жмём Add. Теперь нужно привязать сервер к организации.

Жмём кнопку «Attach Organization»

и привязываем наш сервер к организации.

Т.е. мы можем создать разные организации (например отдельные организации для рабочих и домашних устройств или для разных отделов в офисе), у каждой организции свой набор пользователей и серверов. Это позволит очень гибко предоставлять и прекращать доступы. Один сервер можно привязать к нескольким организациям.

Итоговый вид такой:

Оратите внимание: вместе с организацией к серверу прикрепился и пользователь этой организации.

Запускаем сервер кнопкой «Start Server» и видим, что сервер запустился

Дальше в меню выбираем «Users». Используя иконки напротив имени пользователя скачиваем конфиг с ключами.

Например если так:

То будет предложено несколько временных ссылок на разные типы ахивов. Скачиваем zip, внутри него стандартный ovpn-файл, который добавляем в OpenVPN-клиент.

Или так:

Тогда будет скачан tar-архив, но внтури всё тот же ovpn-файл.

Если нажать на стрелочку, то увидите виртуальный адрес клиента (или несколько адресов, если клиенту разрешено использовать профиль на нескольких устройствах):

Как использовать готовый ovpn-файл, описано во второй половине этой статьи.

На этом, думаю, достаточно. Пользуйтесь. В web-консоли ещё куча кнопок, кроме описанных здесь. Их все можно нажимать, найдёте ещё много интересного.

Связь с автором в чатике канала Телеграм.

Ранее я уже выкладывал на Пикабу статьи про личные VPN, личные хранилища файлов и прочие штуки для защиты личной информации. Планирую несколько статей по полезным для личного использования OpenSorce сервисам. Если эта статья не улетит в минус, выложу сюда и другие.

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

Примечание 1: это статья рассчитана на нулевой или начальный уровень читающего. Очень подробно и просто, без занудства.

Примечание 2: Всё описанное в этой статье приведено только в обучающих целях и не должно быть использовано для противоправных действий. Администрация сайта не несёт ответственность за действия третьих лиц, использующих инструкции из данной статьи. Все скриншоты и адреса сайтов в этой статье являются художественным вымыслом, совпадения с реальными адресами и сайтами случайно.

Примечание 3: статья может и будет дорабатываться. Наиболее актуальный вариант как всегда в первоисточнике. Да и конфиги там выглядят как надо.

Nginx это не только web-сервер, но и кое что получше. Его можно использовать в качестве обратного прокси или реверс-прокси. Что это значит? Реверс-прокси это посредник между пользователем и реальным web-сервером. Это значит, мы можем скрыть от пользователя (или от того, сто фильтрует наш трафик ) настоящий адрес web-сервера, обеспечить доступ по https к серверу, который умеет только http, можем подменить домен web-сервера, можем фильтровать содержимое трафика как с целью подмены содержимого сайта, так и для защиты web-сервера от атак злодеев, можем кэшировать сайт для ускорения, можем балансировать нагрузку, можем… Да очень много можем! Например, сделать своё собственное зеркало RuTracker или любого другого сайта, к которому нет доступа обычным способом.

Лучше всего показывать на реальных примерах. Нам понадобится VPS с минимальными характеристиками. Nginx не требователен к ресурсам. Главное, чтобы хватило лимитов трафика под Вашу задачу. В данной статье для скриншотов будет использоваться VPS с операционной системой CentOS 7. Для других операционных систем конфиги абсолютно аналогичны. Старайтесь использовать минимальную конфигурацию операционной системы без дополнительных пакетов.

Также нам понадобится домен. Можете использовать домен третьего уровня у какого-то своего домена, но лучше для таких дел арендовать отдельный новый платный домен, или арендовать бесплатный домен где-нибудь на freenom.com. Вы должны быть готовы к тому, что ваш домен добавят в реестр запрещенных сайтов. Это не должно затронуть какие-либо другие Ваши сервисы, кроме реверс-прокси. Для этого домена нужно добавить A запись с IP адресом нашего VPS. Как арендовать домен и настраивать DNS записи можно почитать здесь. Для примера в статье будет использоваться домен mydomain.com

Как арендовать и первично настроить VPS описано здесь, здесь и здесь. Должен быть разрешён доступ к серверу по портам tcp/22, tcp/80 и tcp/443. Если вы используете эту статью для настройки файрволла, то конфиг ipt-set будет выглядеть так:

#!/bin/sh

IF_EXT="venet0"

IPT="/sbin/iptables"

IPT6="/sbin/ip6tables"

# flush

$IPT --flush

$IPT -t nat --flush

$IPT -t mangle --flush

$IPT -X

$IPT6 --flush

# loopback

$IPT -A INPUT -i lo -j ACCEPT

$IPT -A OUTPUT -o lo -j ACCEPT

# default

$IPT -P INPUT DROP

$IPT -P OUTPUT DROP

$IPT -P FORWARD DROP

$IPT6 -P INPUT DROP

$IPT6 -P OUTPUT DROP

$IPT6 -P FORWARD DROP

# allow forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward

# NAT

# #########################################

# SNAT - local users to out internet

$IPT -t nat -A POSTROUTING -o $IF_EXT -j MASQUERADE

# INPUT chain

# #########################################

$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# ssh

$IPT -A INPUT -i $IF_EXT -p tcp --dport 22 -j ACCEPT

# WEB

$IPT -A INPUT -i $IF_EXT -p tcp --dport 80 -j ACCEPT

$IPT -A INPUT -i $IF_EXT -p tcp --dport 443 -j ACCEPT

# OUTPUT chain

# #########################################

$IPT -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Обновим сервер:

yum -y update

yum -y install epel-release

Ставим собственно Nginx

yum -y install nginx

Пробуем запустить

systemctl start nginx

Теперь, если мы попробуем в браузере перейти по адресу нашего домена http://mydomain.com (вы, соответсвенно вводите своё имя домена), то должны увидеть страницу-заглушку. Типа такой:

Также можно проверить работоспособность службы командой:

systemctl status -l nginx

Вывод команды должен выглядеть так:

Если возникли проблемы и служба не запускается, то скорее всего вы используете не минимальный дистрибутив операционной системы и в системе уже установлен какой-то web-сервер, который занимает порт. Чтобы проверить это, установим сетевые утилиты

yum install net-tools -y

И проверим, кто занимает порт

netstat -tulnp | grep 80

В выводе команды вы можете увидеть, например:

tcp 0 0 :::80 :::* LISTEN 104/httpd

Это значит, что установлен Apache и запущен его демон httpd. Убираем это командами:

systemctl stop httpd

systemctl disable httpd

А потом пробуем запустить службу Nginx как описано выше. Если всё хорошо, добавляем её в автозагрузку:

systemctl enable nginx

Переходим к конфигу Nginx. Откройте файл /etc/nginx/nginx.conf

Напомню, все манипуляции с фалами я делаю с помощью программ WinSCP, как это описано в этой статье. В качестве редактора рекомендую использовать программу Notepad++. Установите её на свой компьютер и укажите в настройках WinSCP путь к редактору в меню Options->Preferences->Editors. Он должен быть первым в списке для использования по умолчанию.

В конфиге уже есть секция

server {

listen 80 default_server;

listen [::]:80 default_server;

server_name _;

root /usr/share/nginx/html;

# Load configuration files for the default server block.

include /etc/nginx/default.d/*.conf;

location / {

}

error_page 404 /404.html;

location = /40x.html {

}

error_page 500 502 503 504 /50x.html;

location = /50x.html {

}

}

Именно эта секция выводит страницу-заглушку. А вот ниже есть закоментированный пример секции https (порт 443) страницы-заглушки. Крайне желательно эту секцию сделать работающей. Нам понадобятся сертификаты. Установим certbot и получим сертификат командами:

yum -y install certbot python2-certbot-nginx

certbot certonly

На запрос:

Вводим 1

На запрос:

Вводим свой действующий e-mail. На него будут приходить в уведомления. Например, если срок сертификата истекает и его необходимо продлить.

Напомню: Let’s Encrypt выдаёт сертифакты со сроком действия три месяца.

Далее принимаем соглашение и отказываемся от рассылок, вводим, соответственно, A и N

Дальше нужно ввести имя Вашего домена. В моём случае это mydomain.com. И нажать Enter. Если у Вас настроена A запись, как указано в начале статьи, и прошло достаточно времени (запись должна прореплицироваться на все DNS-сервера, это можета занимать до 24-х часов, дожен пинговаться адрес домена), то будет получен сертификат и мы получим вывод в консоли:

IMPORTANT NOTES:

- Congratulations! Your certificate and chain have been saved at:

/etc/letsencrypt/live/mydomain.com/fullchain.pem

Your key file has been saved at:

/etc/letsencrypt/live/mydomain.com/privkey.pem

Your cert will expire on 2020-02-26. To obtain a new or tweaked

version of this certificate in the future, simply run certbot

again. To non-interactively renew *all* of your certificates, run

"certbot renew"

Заметьте, тут сразу есть пути к файлам сертификата и их можно очень удобно скопировать в конфиг. Возвращаемся к файлу /etc/nginx/nginx.conf, раскоментируем секцию для https и исправим пути на сертификат. Получится так:

# Settings for a TLS enabled server.

server {

listen 443 ssl http2 default_server;

listen [::]:443 ssl http2 default_server;

server_name _;

root /usr/share/nginx/html;

ssl_certificate "/etc/letsencrypt/live/mydomain.com/fullchain.pem";

ssl_certificate_key "/etc/letsencrypt/live/mydomain.com/privkey.pem";

ssl_session_cache shared:SSL:1m;

ssl_session_timeout 10m;

ssl_ciphers HIGH:!aNULL:!MD5;

ssl_prefer_server_ciphers on;

# Load configuration files for the default server block.

include /etc/nginx/default.d/*.conf;

location / {

}

error_page 404 /404.html;

location = /40x.html {

}

error_page 500 502 503 504 /50x.html;

location = /50x.html {

}

}

Сохраним файл и перезапустим службу Nginx. Перезапускать службу нужно каждый раз, когда вы меняете конфиги Nginx.

systemctl restart nginx

И проверяем, что старница-заглушка доступна в браузере по адресу https://mydomain.com (вы вводите своё имя домена).

В конфиге /etc/nginx/nginx.conf обратите внимание на строчку

include /etc/nginx/conf.d/*.conf;

Это значит, что если мы в папке /etc/nginx/conf.d/ разместим файл с расширением .conf, то он будет включен в основной конфиг и выполнен вместе с ним. Так и будем делать. Файл /etc/nginx/nginx.conf закрываем и больше не трогаем.

Теперь определим, к чему мы будем проксировать трафик. Например, я хочу чтоб при переходе по адресу test.mydomain.com, во-первых, происходила переадресация на адрес https://test.mydomain.com (мы за безопасность и шифрование), а во-вторых, открывался сайт eng.rkn.gov.ru.

Сначала создадим домен третьего уровня вида test.mydomain.com

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

Т.е. создадим на DNS-сервере А запись test (вы подставляете своё имя) с тем же IP-адресом, что и основной домен mydomain.com (вы подставляете своё имя). Дождитесь, чтобы запись прореплицировалась по DNS-серверам. Можно проверить, что домен пингуется командой на VPS:

ping test.mydomain.com -c 3

Должны корректно пройти три пинга

PING test.mydomain.com (185.nnn.nnn.nnn) 56(84) bytes of data.

64 bytes from vpsNNNN.hostsailor.com (185.nnn.nnn.nnn): icmp_seq=1 ttl=64 time=0.031 ms

64 bytes from vpsNNNN.hostsailor.com (185.nnn.nnn.nnn): icmp_seq=2 ttl=64 time=0.019 ms

64 bytes from vpsNNNN.hostsailor.com (185.nnn.nnn.nnn): icmp_seq=3 ttl=64 time=0.019 ms

--- test.secfall.com ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2000ms

rtt min/avg/max/mdev = 0.019/0.023/0.031/0.005 ms

В папке /etc/nginx/conf.d/ создаём файл с именем вида test.mydomain.com.conf следующего содержания:

server {

listen 80;

server_name test.mydomain.com;

location /.well-known/acme-challenge {

alias /usr/share/nginx/html/.well-known/acme-challenge;

}

location / {

return 301 https://$server_name$request_uri;

}

}

Перезапускаем службу Nginx и, с помощью команды certbot certonly, делаем сертификат для нашего домена третьего уровня test.mydomain.com (подставляете свои имена).

Если сертификат получен, дописываем (т.е. добавляем с новой строчки в конце) в файл /etc/nginx/conf.d/test.mydomain.com.conf секцию для https:

server {

listen 443 ssl;

server_name test.mydomain.com;

access_log /var/log/nginx/test.mydomain.com.access.log;

error_log /var/log/nginx/test.mydomain.com.error.log;

client_max_body_size 0;

underscores_in_headers on;

ssl_certificate /etc/letsencrypt/live/test.mydomain.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/test.mydomain.com/privkey.pem;

ssl_stapling on;

ssl_stapling_verify on;

location /.well-known/acme-challenge {

alias /usr/share/nginx/html/.well-known/acme-challenge;

}

location / {

proxy_set_header Host eng.rkn.gov.ru;

add_header Front-End-Https on;

add_header Referer-Policy no-referrer;

proxy_pass http://eng.rkn.gov.ru;

}

}

Рассмотрите внимательно конфиг. В нём test.mydomain.com вы заменяете на своё имя домена, а eng.rkn.gov.ru на имя того сервера, который будете проксировать. И обратите внимание, что в данном конфиге к eng.rkn.gov.ru сервер обращается по http, а нам отдаёт по https. Такое полезно, когда web-сервер расположен где-то во внутренней инфраструктуре и нет необходимости или возможности прикрутить к нему https.

Например, есть некий сервис который вообще не умеет в https. Мы устанавливаем его на сервер, привязываем к адресу localhost и к порту, например, 8080. Теперь к сервису нельзя обратится извне, а только «изнутри» сервера по адресу http://localhost:8080. На этот же сервер ставим реверс-прокси, как написано выше, и указываем

proxy_pass http://localhost:8080;

Т.е. Nginx будет обращаться к этому же серверу на localhost к нашему сервису по порту 8080. А нам будет отдавать нормальный https. Да ещё всякой фильтрации для безопасности можно навесить, чтобы помешать злодеям ломать наш сервис. Но об этом ниже.

Сохраняем файл, перезапускаем службу Nginx. Возможно вы где-то накосячили и ошиблись. Тогда командой

systemctl status -l nginx

смотрим, в чём ошибка. Обычно Nginx достаточно внятно пишет, что ему не нравиться, и даже укавает номер строки конфига, где есть ошибка.

Если служба запустилась без ошибок, то в браузере открываем адрес test.mydomain.com Получится как-то так:

Обратите внимание, что хотя мы не писали в адресе https, сервер сам перевёл нас на зашифрованный трафик. Всё, мы сделали зеркало сайта! Дальше можно дорабатывать конфиг. Например добавить строчку

proxy_cookie_domain rkn.gov.ru $host;

proxy_pass_header Set-Cookie;

Это позволит обеспечить корректную работу куков и нормальную авторизацию на проксируемом сайте. Получится так (показан кусок конфига, только с параметрами проксирования):

location / {

proxy_cookie_domain eng.rkn.gov.ru $host;

proxy_pass_header Set-Cookie;

proxy_set_header Host eng.rkn.gov.ru;

add_header Front-End-Https on;

add_header Referer-Policy no-referrer;

proxy_pass http://eng.rkn.gov.ru;

}

Можно включить фильтрацию текста. Например заменять слово «Roskomnadzor» на «Roskompozor». Нужно дописать пару строчек (показан кусок конфига, только с параметрами проксирования):

location / {

proxy_cookie_domain rkn.gov.ru $host;

proxy_pass_header Set-Cookie;

proxy_set_header Host eng.rkn.gov.ru;

add_header Front-End-Https on;

add_header Referer-Policy no-referrer;

proxy_pass http://eng.rkn.gov.ru;

sub_filter "Roskomnadzor" "Roskompozor";

sub_filter_once off;

}

Директива

sub_filter «Roskomnadzor» «Roskompozor»;

показывает что на что менять.

Директива

sub_filter_once off;

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

Сохряняем конфиг, перезапускаем службу Nginx и с помощью комбинации Ctrl+F5 (чтобы игнорировать кэш браузера) обновляем страницу в браузере. Получится как-то так :)

Теперь про фильтрацию заголовков. Это нужно делать, если проксируете трафик к какому-то своему сервису и нужно его дополнительно защитить. Я покажу часть конфига с проксированием со всеми основными примочками безопасности (кусок с ними выделен линиями). Я не буду расписывать — для чего они. Это тема отдельной статьи. Если интересно — легко сможете нагуглить.

location / {

proxy_cookie_domain rkn.gov.ru $host;

proxy_pass_header Set-Cookie;

proxy_set_header Host eng.rkn.gov.ru;

#------------------------------------------------------------------------------------------------------------------------------------------

proxy_headers_hash_max_size 512;

proxy_headers_hash_bucket_size 64;

proxy_set_header Accept-Encoding "";

proxy_set_header X-Forwarded-Proto $scheme;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

add_header X-Content-Type-Options nosniff;

add_header X-XSS-Protection "1; mode=block";

add_header Content-Security-Policy "default-src 'self';

frame-ancestors https://framer.mozilla.org;

form-action 'self';

base-uri 'self';

script-src 'self' https://mc.yandex.ru https://ssl.google-analytics.com;

img-src 'self' https://mc.yandex.ru https://ssl.google-analytics.com;

style-src 'self' 'unsafe-inline' https://mc.yandex.ru https://fonts.googleapis.com;

font-src 'self' https://mc.yandex.ru https://themes.googleusercontent.com;

frame-src https://mc.yandex.ru;

object-src 'none'

";

add_header X-Frame-Options "DENY";

proxy_cookie_path / "/; HTTPOnly; Secure";

#------------------------------------------------------------------------------------------------------------------------------------------

add_header Front-End-Https on;

add_header Referer-Policy no-referrer;

proxy_pass http://eng.rkn.gov.ru;

}

Если Вам нужно добавить ещё одно зеркало, то порядок действий такой:

1. Добавляет новую A запись с доменом третьего уровня на DNS-сервере. Ждем, пока не начнёт пинговаться с нашего VPS.

2. Создаем ещё один файл конфига в папке /etc/nginx/conf.d/ с секцией для 80 порта (для http) и перезапускаем Nginx.

3. Делаем сертификаты с помощью certbot.

Дописываем секцию для https в конфиг. Указывем пути на сертификаты. Перезапускаем Nginx.

Еще можно добавить ключ для алгоритма Диффи-Хелмана. Настроить автообновлене сертификатов. Как сделать, описано в этой статье.

P.S. Всё, что описано в статье - может сделать каждый! Это не сложно. Повышая свою грамотность в современных технологиях вы делаете мир лучше.

P.P.S. Да, это можно сделать парой команд в докере. Но докер не доступен на виртуалках нижнего ценового диапазона, да и статься, чтобы руки научить.