Осуществляется командой, в которой для заданных критериев применено действие ACCEPT, то есть пакет будет пропущен брэндмауэром.
```ssh
# iptables –A INPUT –p tcp ––dport 22 –j ACCEPT
# iptables –A INPUT –p tcp ––dport 80 –j ACCEPT
```
### 2.3. Добавление правила для порта 8080. Переадресация с порта 8080 на порт 80
Поскольку происходит преобразование адреса назначения, используем таблицу **nat**. Критерии для применения этого правила: `–p tcp ––dport 8080`. Изменение получателя осуществляется в цепочке `PREROUTING`. Правило для переадресации – `REDIRECT`, которое имеет дополнительный ключ для определения порта переадресации `––to-ports`. Зададим перенаправление на порт `80`. Таким образом для определения последнего правила, необходимо ввести в командной строке:
После выполнения команд правила для цепочек сформированы и необходимо осуществить проверку правильности их занесения и работы. Просмотреть созданные правила для всех цепочек можно после выполнения команды:
```ssh
# iptables –S
# iptables –t nat -S
```
***Скриншот**
Пример первой выполненной команды:
```ssh
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -j LOG
-A TCP -p tcp -m tcp --dport 22 -j ACCEPT
-A TCP -p tcp -m tcp --dport 80 -j ACCEPT
```
Проверка правильности настройки защиты web-сервера на основе **iptables** осуществляется проведением проверки доступных для подключения портов на сервере. Для получения открытых для подключения портов следует воспользоваться сканером портов **nmap** и выполнить следующую инструкция в командной строке.
Проверьте, что на компьютере установлен nmap, выполнив команду:
```ssh
$ nmap
```
Если система выдала ошибку, что такой программы нет, необходимо установить nmap:
```ssh
# apt-get update
# apt-get install nmap
```
Запуск команды сканирования портов:
```ssh
$ nmap localhost
```
Вывод команды покажет какие порты на данный момент открыты в системе. Пример:
```ssh
Starting Nmap 7.01 ( https://nmap.org ) at 2017-10-10 04:54 PDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000065s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
22/tcp open ssh
```
Для сброса настроек iptables в изначальное состояние:
```ssh
# iptables –F
# iptables –t nat -F
```
### 3. Задание
Необходимо сделать перенаправление вызова с соответствующих портов.
Для начала потребуется установить дополнительные пакеты
```ssh
apt-get update
apt install -y screen python3-pip net-tools
pip install simple-http-server
```
Утилита `screen` позволяет создавать независимые окна терминала:
- `screen -S name` - создание окна терминала с идентификатором `name` и переход в него;
- `screen -r name` - переход в окно терминала `name`;
Комбинация клавиш `Ctrl+A+D` выйти в главное окно терминала.
Для проверки доступа по указанному порту, в новом окне терминала выполните следующую команду (вместо слова `port` укажите номер порта)
<details>
<summary>"port"</summary>
port задается в формате 8GVV, где G - номер группы, а VV - вариант из первой лабораторной работы
</details>
```ssh
$ screen -S server
$ python3 –m http.server port
```
После запуска команды, в браузере необходимо проверить доступность вашего сервера, для этого наберите строку ip_adress:port.
**узнать свой ip-адрес можно с помощью команды `ifconfig`*
В браузере вы увидите страничку с файловой системой:
<imagesrc="assets/L2P1_3.jpg">
***Скриншот**
Это означает, что порт открыт и вы можете получить доступ к запущенному Web-server. После запуска запустите команду **nmap** и посмотрите, какие порты открыты сейчас.
После внесения правила перенаправления, проверьте доступность вашего сервера в браузере, перейдя по адресу: ip_adress:redirect_port
***Скриншот**
<details>
<summary>"redirect_port"</summary>
redirect_port задается в формате 80 + VV, где VV - вариант из первой лабораторной работы (VV = 01 -> redirect_port = 81)
</details>
Повторно запустите команду **nmap** и проверьте вывод.
***Скриншот `# iptables –t nat -S`**
## Часть 2. Настройка межсетвеого экрана в Linux-системах
### Цель работы
Получить навыки работы с VPN сервисами и базовые знания по разворачиванию виртуальных машин в облаке. Получить базовые знание о конфигурации серверов VPN
### 1. Теоретическая часть
**VPN** (англ. *Virtual Private Network* — виртуальная частная сеть) — обобщённое название технологий, позволяющих обеспечить одно или несколько сетевых соединений (логическую сеть) поверх другой сети (например, Интернет). Несмотря на то, что коммуникации осуществляются по сетям с меньшим или неизвестным уровнем доверия (например, по публичным сетям), уровень доверия к построенной логической сети не зависит от уровня доверия к базовым сетям благодаря использованию средств криптографии (шифрования, аутентификации, инфраструктуры открытых ключей, средств для защиты от повторов и изменений передаваемых по логической сети сообщений).
В зависимости от применяемых протоколов и назначения, VPN может обеспечивать соединения трёх видов:
- узел-узел
- узел-сеть
- сеть-сеть
VPN состоит из двух частей: *«внутренняя»* (подконтрольная) сеть, которых может быть несколько, и *«внешняя»* сеть, по которой проходит инкапсулированное соединение (обычно используется Интернет).
Возможно также подключение к виртуальной частной сети отдельного компьютера.
Подключение удалённого пользователя к VPN производится посредством сервера доступа, который подключён как к внутренней (частной), так и к внешней (общедоступной) сети. При подключении удалённого пользователя (либо при установке соединения с другой защищённой сетью) сервер доступа требует прохождения процесса идентификации, а затем процесса аутентификации. После успешного прохождения обоих процессов удалённый пользователь (удаленная сеть) наделяется полномочиями для работы в сети, то есть происходит процесс авторизации.
### 1.1. VPN Туннели
Начнём с терминологии. VPN соединение всегда состоит из канала типа точка-точка, также известного под названием туннель. Туннель создаётся в незащищённой сети, в качестве которой чаще всего выступает Интернет. Соединение точка-точка подразумевает, что оно всегда устанавливается между двумя компьютерами, которые называются узлами или peers. Каждый peer отвечает за шифрование данных до того, как они попадут в туннель и расшифровке этих данных после того, как они туннель покинут.
Хотя VPN туннель всегда устанавливается между двумя точками, каждый peer может устанавливать дополнительные туннели с другими узлами. Для примера, когда трём удалённым станциям необходимо связаться с одним и тем же офисом, будет создано три отдельных VPN туннеля к этому офису. Для всех туннелей peer на стороне офиса может быть одним и тем же. Это возможно благодаря тому, что узел может шифровать и расшифровывать данные от имени всей сети, как это показано на рисунке 1:
<imagesrc="assets/L2P2_1.jpg">
Рисунок 1
В этом случае VPN узел называется VPN шлюзом, а сеть за ним - доменом шифрования (encryption domain). Использование шлюзов удобно по нескольким причинам. Во-первых, все пользователи должны пройти через одно устройство, которое облегчает задачу управления политикой безопасности и контроля входящего и исходящего трафика сети. Во-вторых, персональные туннели к каждой рабочей станции, к которой пользователю надо получить доступ, очень быстро станут неуправляемыми (т.к. туннель - это канал типа точка-точка). При наличии шлюза, пользователь устанавливает соединение с ним, после чего пользователю открывается доступ к сети (домену шифрования).
Интересно отметить, что внутри домена шифрования самого шифрования не происходит. Причина в том, что эта часть сети считается безопасной и находящейся под непосредственным контролем в противоположность Интернет. Это справедливо и при соединении офисов с помощью VPN шлюзов. Таким образом гарантируется шифрование только той информации, которая передаётся по небезопасному каналу между офисами. Рисунок 2 показывает VPN соединяющую два офиса:
<imagesrc="assets/L2P2_2.jpg">
Рисунок 2
Сеть A считается доменом шифрования VPN шлюза A, а сеть B доменом шифрования VPN шлюза B, соответственно. Когда пользователь сети A изъявляет желание отправить данные в сеть B, VPN шлюз A зашифрует их и отошлёт через VPN туннель. VPN шлюз B расшифрует информацию и передаст получателю в сети B.
Всякий раз, когда соединение сетей обслуживают два VPN шлюза, они используют режим туннеля. Это означает, что шифруется весь пакет IP, после чего к нему добавляется новый IP заголовок. Новый заголовок содержит IP адреса двух VPN шлюзов, которые и увидит пакетный сниффер при перехвате. Невозможно определить компьютер-источник в первом домене шифрования и компьютер-получатель во втором домене.
Посмотрите на рисунок 1, иллюстрирующий типичное использование VPN, которая позволяет удалённым пользователям с переносными компьютерами и пользователям, работающим из дома, иметь доступ к офисной сети. Чтобы эта схема заработала, пользователь должен иметь установленное ПО - VPN клиент, который обеспечит создание VPN туннеля к удалённому VPN шлюзу. По сценарию используется режим туннеля, т.к. пользователь хочет получить доступ к ресурсам домена, а не самого шлюза. Единственной случай, когда включается режим транспорта - это если одному компьютеру нужно получить доступ к другому непосредственно.
Существует много вариантов VPN шлюзов и VPN клиентов. Это может быть аппаратное VPN устройство или программное VPN обеспечение, которое устанавливается на маршрутизаторах или на ПК. ОС FreeBSD поставляется вместе с ПО для создания VPN шлюза и для настройки VPN клиента. В коллекции портов существуют и другие приложения, позволяющие соединяться со станциями под управлением других ОС.
Назависимо от используемого ПО, все VPN работают по следующим принципам:
1. Каждый из узлов идентифицирует друг друга перед созданием туннеля, чтобы удостовериться, что шифрованные данные будут отправлены на нужный узел
2. Оба узла требуют заранее настроеной политики, указывающей какие протоколы могут использоваться для шифрования и обеспечения целостности данных
3. Узлы сверяют политики, чтобы договориться об используемых алгоритмах; если это не получается, то туннель не устанавливается
4. Как только достигнуто соглашение по алгоритмам, создаётся ключ, который будет использован в симметричном алгоритме для шифрования/расшифровки данных
Есть несколько стандартов регламентирующих вышеописанное взаимодействие. Вы, должно быть, слышали о некоторых из них: L2TP, PPTP, и IPSec. Т.к. IPSec - наиболее широко поддерживаемый стандарт, который имеет в арсенале наибольшее количество сокращений, оставшуюся часть статьи стоит посвятить именно ему.
### 1.2. IPSec
Стандарт IPSec был разработан для повышения безопасности IP протокола. Это достигается за счёт дополнительных протоколов, добавляющих к IP пакету собственные заголовки, которые называются инкапсуляциями. Т.к. IPSec - стандарт Интернет, то для него существуют RFC (Requests For Comments). Если есть интерес покопаться во внутренностях IPSec, то следующие RFC с *http://www.rfc-editor.org/* могут оказаться полезными:
- RFC 2401 IPSec
- RFC 2402 AH
- RFC 2406 ESP
- RFC 2409 IKE
Приведём краткое описание каждого, чтобы получить необходимую информацию для понимания следующей статьи, посвящённой настройке IPSec VPN на FreeBSD системе. Начнём с сокращений, а затем посмотрим как они укладываются в общую картину создания виртуальной частной сети.
AH (Authentication Header) - протокол заголовка идентификации. Обеспечивает целостность путём проверки того, что ни один бит в защищаемой части пакета не был изменён во время передачи. Не будем вдаваться в подробности, какая часть пакета защищается и где находятся данные AH заголовка, т.к. это зависит от используемого типа шифрования и в деталях, с диаграммами описывается в соответствующем RFC. Отметим лишь, что использование AH может вызвать проблемы, например, при прохождении пакета через NAT устройство. NAT меняет IP адрес пакета, чтобы разрешить доступ в Интернет с закрытого локального адреса. Т.к. пакет в таком случае изменится, то контрольная сумма AH станет неверной. Также стоит отметить, что AH разрабатывался только для обеспечения целостности. Он не гарантирует конфиденциальности путём шифрования содержимого пакета.
ESP (Encapsulating Security Protocol) - инкапсулирующий протокол безопасности, который обеспечивает и целостность и конфиденциальность. В режиме транспорта ESP заголовок находится между оригинальным IP заголовком и заголовком TCP или UDP. В режиме туннеля заголовок ESP размещается между новым IP заголовком и полностью зашифрованным оригинальным IP пакетом.
Т.к. оба протокола - AH и ESP добавляют собственные заголовки, они имеют свой ID протокола, по которому можно определить что последует за заголовком IP. Если вспомнить статью TCP Protocol Layers Explained, то в ней сказано, что каждый тип заголовка имеет собственный номер. Например, для TCP это 6, а для UDP - 17. При работе через firewall важно не забыть настроить фильтры, чтобы пропускать пакеты с ID AH и/или ESP протокола. Для AH номер ID - 51, а ESP имеет ID протокола равный 50. При создании правила не забывайте, что ID протокола не то же самое, что номер порта.
Третий протокол, используемый IPSec - это IKE или Internet Key Exchange protocol. Как следует из названия, он предназначен для обмена ключами между двумя узлами VPN. Насмотря на то, что генерировать ключи можно вручную, лучшим и более масштабируемым вариантом будет автоматизация этого процесса с помощью IKE. Помните, что ключи должны часто меняться, и вам наверняка не хочется полагаться на свою память, чтобы найти время для совершения этой операции вручную. Главное - не забудьте настроить правило на файрволе для UPD порта с номером 500, т.к. именно этот порт используется IKE.
SA (Security Association), что можно приближённо перевести как "связь или ассоциация безопасности" - это термин IPSec для обозначения соединения. При настроенном VPN, для каждого используемого протокола создаётся одна SA пара (т.е. одна для AH и одна для ESP). SA создаются парами, т.к. каждая SA - это однонаправленное соединение, а данные необходимо передавать в двух направлениях. Полученные SA пары хранятся на каждом узле. Если ваш узел имеет SA, значит VPN туннель был установлен успешно.
Перейти на сайт `http://www.asfaa.org/members.php?id=1`
Т.к. каждый узел способен устанавливать несколько туннелей с другими узлами, каждый SA имеет уникальный номер, позволяющий определить к какому узлу он относится. Это номер называется SPI (Security Parameter Index) или индекс параметра безопасности.
Проверить, что получится, если после id=6 поставить кавычку.
SA храняться в базе данных c названием, кто бы подумал - SAD (Security Association Database) или БД ассоциаций безопасности. Мы встретимся с ней ещё раз при настройке IPSec VPN.
Каждый узел IPSec также имеет вторую БД - SPD или Security Policy Database (БД политики безопасности). Она содержит настроенную вами политику узла. Большинство VPN решений разрешают создание нескольких политик с комбинациями подходящих алгоритмов для каждого узла, с которым нужно установить соединение.
Какие настройки включает в себя политика?
- Симметричные алгоритмы для шифрования/расшифровки данных;
- Криптографические контрольные суммы для проверки целостности данных;
- Способ идентификации узла. Самые распространнённые способы - это предустановленные ключи (pre-shared secrets) или RSA сертификаты;
- Использовать ли режим туннеля или режим транспорта;
- Какую использовать группу Diffie Hellman;
- Как часто проводить переидентификацию узла;
- Как часто менять ключ для шифрования данных;
- Использовать ли PFS;
- Использовать ли AH, ESP, или оба вместе.
При создании политики, как правило, возможно создание упорядоченного списка алгоритмов и Diffie Hellman групп. В таком случае будет использована первая совпавшая на обоих узлах позиция. Запомните, очень важно, чтобы всё в политике безопасности позволяло добиться этого совпадения. Если за исключением одной части политики всё остальное совпадает, узлы всё равно не смогут установить VPN соединение. При настройе VPN между различными системами уделите время изучению того, какие алгоритмы поддерживаются каждой стороной, чтобы иметь выбор наиболее безопасной политики из возможных.
### 1.3. Фаза Один и Фаза Два
Теперь давайте посмотрим как всё это работает вместе. Установка и поддержка VPN туннеля происходит в два этапа. На первом этапе (фазе) два узла договариваются о методе идентификации, алгоритме шифрования, хэш алгоритме и группе Diffie Hellman. Они также идентифицируют друг друга. Всё это может пройти в результате обмена тремя нешифрованными пакетами (т.н. агрессивный режим) или через обмен шестью нешифрованными пакетами (стандартный режим - main mode). Предполагая, что операция завершилась успешно, создаётся SA первой Фазы - Phase 1 SA (также называемый IKE SA) и процесс переходит к Фазе Два.
На втором этапе генерируются данные ключей, узлы договариваются насчёт используемой политики. Этот режим, также называемый быстрым режимом (quick mode), отличается от первой фазы тем, что может установиться только после первого этапа, когда все пакеты второй фазы шифруются. Такое положение дел усложняет решение проблем в случае неполадок на второй фазе при успешном завершении первой. Правильное завершение второй фазы приводит к появлению Phase 2 SA или IPSec SA, и на этом установка туннеля считается завершённой.
Когда же это всё происходит? Сначала на узел прибывает пакет с адресом назначения в другом домене шифрования, и узел инициирует Фазу Один с тем узлом, который отвечает за другой домен. Допустим, туннель между узлами был успешно установлен и ожидает пакетов. Однако, узлам необходимо переидентифицировать друг друга и сравнить политику через определённое время. Это время известно как время жизни Phase One или IKE SA lifetime.
Узлы также должны сменить ключ для шифрования данных через другой отрезок времени, который называется временем жизни Phase Two или IPSec SA lifetime. Phase Two lifetime короче, чем у первой фазы, т.к. ключ необходимо менять чаще. Типичное время жизни Phase Two - 60 минут. Для Phase One оно равно 24 часам.
Ваша задача заключается в том, чтобы сконфигурировать оба узла с одинаковыми параметрами времени жизни. Если этого не произойдёт, то возможен вариант, когда изначально туннель будет установлен успешно, но по истечении первого несогласованного промежутка времени жизни связь прервётся. Странные проблемы могут возникнуть и в том случае, когда время жизни Фазы Один меньше аналогичного параметра Фазы Два. Если настроенный ранее туннель виснет, то первая вещь, которая нуждается в проверке - это время жизни на обоих узлах. В заключение стоит упомянуть, что при смене политики на одном из узлов, изменения вступят в силу только при следующем наступлении Фазы Один. Чтобы изменения вступили в силу немедленно, надо убрать SA для этого туннеля из SAD. Это вызовёт пересмотр соглашения между узлами с новыми настройками политики безопасности.
### 1.4. Классификация VPN.
**По способу реализации:**
- Программное решение.
Для функционирования VPN используется ПК со специализированным ПО.
- Программно-аппаратное решение.
Для реализации VPN используется комплекс специальных программно-аппаратных средств. За счет такого подхода обеспечиваются высокая производительность и защищенность.
- Интегрированное решение.
Реализацию VPN обеспечивает программно-аппаратный комплекс, попутно решающий задачи организации сетевого экрана, фильтрации трафика и т.д.
**По степени защищенности:**
- Доверительные.
Реализуются при необходимости создания виртуальной подсети в составе большой сети. Передающая среда при этом считается доверительной, а проблемы безопасности — неактуальными.
- Защищенные.
Это самый популярный вид VPN, с помощью которого создаются защищенные и надежные сети на базе ненадежных сетей, например, Интернета.
**По назначению:**
- Extranet VPN.
Виртуальные сети, в которые могут подключаться «внешние» пользователи — клиенты или заказчики. Так как они пользуются меньшим доверием, нежели сотрудники компании, существует необходимость создания определенных правил, ограничивающих доступ «внешних» пользователей к конфиденциальной или коммерческой информации.
- Remote Access VPN.
Реализуется для обеспечения защищенного канала между корпоративной сетью и пользователем, подключенным к защищенной сети извне, например, с домашнего ПК.
- Internet VPN.
Реализуется провайдерами для предоставления доступа клиентам, подключающимся по одному физическому каналу.
- Intranet VPN.
Объединяет в защищенную сеть ряд филиалов одной компании, распределенных географически, для обмена информацией по открытым каналам.
- Client/Server VPN.
Защищает данные, передаваемые между узлами корпоративной сети (но не сетями). Обычно реализуется для узлов, находящихся в одном сетевом сегменте, например, клиентской машиной и сервером. Этот вариант применяется для разделения одной физической сети на несколько логических.
**По типу протокола:**
На рынке есть реализации VPN для сетей TCP/IP, AppleTalk и IPX. Однако наиболее актуальной считается тенденция перехода на TCP/IP, поэтому большинство решений поддерживает только его. Сегодня существует несколько популярных реализаций VPN, среди которых стоит упомянуть PPTP, OpenVPN, L2TP, PPPoE, IPSec.
**По уровню инкапсуляции**
- L2-туннели
Осуществляют перехват всего трафика на уровне кадров (2-й, канальный уровень модели ISO/OSI, например, протокол Ethernet).
- L3-туннели
Осуществляют перехват всего трафика на уровне пакетов (3-й, канальный уровень модели ISO/OSI, например, протокол IP).
- Прикладные туннели
Осуществляют перехват трафика конкретного приложения, например, веб-браузера (4-й, транспортный уровень модели ISO/OSI, например, протокол TCP). В этом случае программное обеспечения подключения к удалённому узлу по защищенному протоколу должно быть встроено в прикладное приложение, например, в браузер. При этом защищается конкретный прикладной протокол, например, HTTP. Строго говоря, это не является VPN, так как весь остальной трафик компьютера идет обычным образом без всякой защиты, однако именно этот способ стал известен обывателям как VPN для обхода блокировок, устанавливаемых провайдерами по указанию уполномоченных органов.
<imagesrc="assets/L2P2_3.jpg">
### 2. Практическая часть
### 2.1. Установка и настройка серверной части OpenVPN
Устанавливаем OpenVPN
```ssh
apt-get update
apt install -y openvpn
```
Настраиваем переадресацию (IP forwarding) (при выключении/перезапуске сервера это повторяем):
Переходим в папку openvpn и создаем секретный ключ:
```ssh
cd /etc/openvpn
openvpn --genkey --secret ovpn.key
```
Создаем файл конфигурации OpenVPN, назовем его openvpn.conf, для этого воспользуемся редактором `nano` работающим в консоли:
```ssh
nano openvpn.conf
```
В файл вставляем:
```ssh
port *vpn_port*
proto tcp-server
dev tun1
ifconfig 10.4.0.1 10.4.0.2
status server-tcp.log
verb 3
secret ovpn.key
```
**Выделенные `*` строки необходимо изменить на реальные значения**
<details>
<summary>vpn_port</summary>
Задается в формате 1194 + VV, где VV - вариант из первой лабораторной работы (VV = 01 -> vpn_port = 1195)
</details>
***Скриншот**
Нажимаем `CTRL+S` и подтверждаем запись в файл, выходим из редактора — `CTRL+X`.
Запускаем OpenVPN на сервере командой
Так, как присутствует ошибка SQL, значит обработка специальных символов работает неправильно или её нет. Попробуем получить доступ к Базе данных данного сайта. Для этого необходимо запустить программу sqlmap при помощи команды
Проверяем, есть ли у нас открытый порт `*vpn_port*` на системе
Если возникнет вопрос про WAF/IPS/IDS – отвечаем N.
```ssh
netstat -nlpt
```
Если открытого порта на системе нет, необходимо его добавить (чтобы можно было устанавливать соединения). Для этого необходимо выполнить команду:
Программа определит тип базы данных и предложит пропустить дальнейшие проверки, отвечаем Y. На вопрос про включение всех тестов – отвечаем N. Программа начнёт искать уязвимости в параметрах запроса. После обнаружения уязвимого параметра, отвечаем N на вопрос про проверку остальных параметров. В конечном итоге, получим информацию о типе базы данных и об уязвимых параметрах. Попробуем получить информацию о количестве и названии баз данных:
python sqlmap.py -u "http://www.ubraintv.com/watchchannel.php?id=6" -D mysql --tables
```
После сохранения файла:
После получения таблиц можно попробовать получить данные. Попробуем получить список пользователей из таблицы user
```ssh
systemctl daemon-reload
systemctl restart openvpn
netstat -nlpt
python sqlmap.py -u "http://www.ubraintv.com/watchchannel.php?id=6" -D mysql -T user --dump
```
В итоге, после выполнения команд должна появиться строка:
```ssh
...
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:*vpn_port* 0.0.0.0:* LISTEN -
...
```
***Скриншот**
### 2.2. Установка и настройка клиентской части OpenVPN (Windows)
Скачиваем установщик OpenVPN по [ссылке](https://swupdate.openvpn.org/community/releases/OpenVPN-2.6.2-I001-amd64.msi) и делаем установку "по-умолчанию".
В папке `C:\Users\Username\OpenVPN\config\` создаём папку с именем `client`
### 2.3. Подбор пароля (Brute-force attack)
Копируем файл `/etc/openvpn/ovpn.key` (на сервере) в `C:\Users\Username\OpenVPN\config\client`. Например, с помощью `WinSCP` или скопировав содержимое в файл с тем же именем
Зайти на сайт `https://juice-shop.herokuapp.com/#/login`
Также в папке `client` создадим файл с настройками OpenVPN, назовем его `client.ovpn`. В файл вставим:
Проверить, что отображается в Burp Suite. Войти с учётными данными в приложение (admin@juice-sh.op / admin123)
Выйти из приложения.
```ssh
proto tcp-client
remote *ip_adress*
port *vpn_port*
dev tun
secret ovpn.key
redirect-gateway def1
ifconfig 10.4.0.2 10.4.0.1
```
Попытаться войти в приложение, используя неправильный пароль.
<details>
<summary>ip_adress</summary>
IP-адрес сервера
</details>
Изучить взаимодействие с сервером, определить критерий успешного или не успешного логина в приложение.
***Скриншот**
Выбрать запрос, отвечающий за логин пользователя, нажать правой кнопкой, выбрать пункт «Send to Intruder».
Сохраняем файл
Перейти на вкладку «Intruder» -> «Position»
Запускаем OpenVPN ПКМ по значку в трее и переходим на сайт [ipinfo.io](https://ipinfo.io/ip). Убедитесь, что полученный IP-адрес и адрес удалённой машины совпадают.
<imagesrc="assets/L3_32.jpg">
***Скриншот**
В окне выделить символом § с двух сторон только форму password.
Создать на компьютере файл, содержимое которого является паролями, которые будут перебираться (каждое значение с новой строки). В файле должен быть валидный пароль.
### 2.3. Установка и настройка клиентской части OpenVPN (Linux)
Перейти на вкладку «Payloads», загрузить файл через кнопку «Load…»
Открываем окно терминала (можно использовать машину первой лабораторной работы) и устанавливаем OpenVPN:
<imagesrc="assets/L3_33.jpg">
```ssh
apt-get update
apt-get install -y openvpn nano curl
```
Нажать на кнопку «Start Attack», дождаться окончания. После в приведенной таблице проанализировать ответы сервера и понять, какой пароль из представленных действительно подошёл от нашей учётной записи.
Создаём папку для настроек OpenVPN:
Это можно сделать, посмотрев на длину ответа от сервера, для валидного пароля она будет отличаться.
```ssh
mkdir ~/OpenVPNconf && cd ~/OpenVPNconf
```
Копируем файл `/etc/openvpn/ovpn.Key` (на сервере) в `~/OpenVPNconf`. Например, с помощью `scp`:
В `~/OpenVPNconf/` создадим файл с настройками OpenVPN, назовем его openvpn.client.conf:
### 2.4. Межсайтовый скриптинг (XSS)
```ssh
nano openvpn.client.ovpn
```
Перейти на https://xss-game.appspot.com/level1
В файл вставим:
В появившемся окне в строке поиска ввести строку
```ssh
proto tcp-client
remote *ip_adress*
port *vpn_port*
dev tun
secret *path*/ovpn.key
redirect-gateway def1
ifconfig 10.4.0.2 10.4.0.1
<script>alert('1')</script>
```
<details>
<summary>path</summary>
в настройке "secret" должен быть полный адрес файла ключа
</details>
Посмотреть на результат. В контексте браузера выполнился код, который мы передали в качестве поискового запроса.
***Скриншот**
Сохраняем файл openvpn.client.ovpn
Переходим на уровень 2.
Теперь просто запускаем OpenVPN в консоли командой:
Здесь представлен форум, на котором можно писать сообщения. При этом тэг `<script>` фильтруется и использовать его нельзя. Попробуем обойти другим способом и внедрим следующий код в страницу:
С этого момента весь исходящий сетевой трафик OpenVPN начинает направлять в TUN/TAP и далее на сервер. Putty перестает получать подтверждения на свои запросы и регистрирует сбой соеднинения.
Таким образом мы попросили браузер обратиться за картинокй, которой не существует и, в случае ошибки, выполнить код указанный далее.
<details>
<summary>*графическое пояснение</summary>
<imagesrc="assets/L2P2_expl.png">
</details>
### 2.5. Прямой доступ к объектам
Зная, что тип созданного соедниения ("туннеля") *узел-узел*, зайти на "локальную машину" можно через VPN-сервер:
Зайдите на сайт `https://juice-shop.herokuapp.com/`
```ssh
ssh root@10.4.0.2
```
***в отчёте объяснить ввод данного ip-адреса**
Проверим, что мы сейчас находимся в клиентской части соединения:
```ssh
find /root/OpenVPNconf/ -ls
```
Попробуем найти панель администратора, которой нет в интерфейсе (нет кнопки, на которую можно нажать и перейти в админ-панель).
Вывод покажет наличие клиентского конфигурационного файла `openvpn.client.ovpn`, созданного ранее.
Для этого в браузере нажмем F12 и перезагрузим страницу. Теперь, необходимо найти файл main.js и провести в нем поиск по слову “admin”.
***Скриншот (должна быть видна команда `ssh root@10.4.0.2`)**
Увидим, что он встречается в строке для роутинга `path: "administration"`
Выполним следующую команду:
<imagesrc="assets/L3_35.jpg">
```ssh
echo "IP: $(curl -s ipinfo.io/ip)"
```
Таким образом, обратившись напрямую к `https://juice-shop.herokuapp.com/administration` попадем в панель администратора
***Скриншот**
В ней происходит запрос на сервер, отображающий IP-адрес подлючения. Убедитесь, что полученный IP-адрес и адрес удалённой машины совпадают.
Если результат выполнения следующей команды возвращает `IP: `, то необходимо сделать следующие действия:
```ssh
nano /etc/resolv.conf
```
Добавить в конец файла строку и сохранить файл:
### 3. Задание
```ssh
nameserver 8.8.8.8
```
На сайте `https://juice-shop.herokuapp.com/#/` найти Cross-Site Scripting (XSS) и SQL Injection
## **Каждый скриншот должен сопровождаться подробным описанием вводимых команд/настроек и результатов их выполнения**
