infosec/labs/lab3/README.md

Лабораторная работа 3

Цель работы

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

1. Теоретическая часть

На сегодняшний день по данным исследований, около 70% процентов сайтов содержат хотя бы одну уязвимость критического уровня. В компьютерной безопасности термин «уязвимость» (англ. vulnerability) используется для обозначения недостатка в системе, используя который можно намеренно нарушить её целостность и вызвать неправильную работу. Уязвимость может быть результатом ошибок программирования, недостатков, допущенных при проектировании системы, ненадежных паролей, вирусов и других вредоносных программ, скриптовых и SQL-инъекций. Некоторые уязвимости известны только теоретически, другие же активно используются и имеют известные эксплойты.

Обычно уязвимость позволяет атакующему «обмануть» приложение — заставить его совершить действие, на которое у того не должно быть прав. Это делается путём внедрения каким-либо образом в программу данных или кода в такие места, что программа воспримет их как «свои».

1.1. OWASP

Open Web Application Security Project (OWASP) — это открытый проект обеспечения безопасности веб-приложений. Сообщество OWASP включает в себя корпорации, образовательные организации и частных лиц со всего мира. Сообщество работает над созданием статей, учебных пособий, документации, инструментов и технологий, находящихся в свободном доступе.

Раз в несколько лет OWASP публикует рейтинг наиболее популярных уязвимостей в Web-приложениях, который называется OWASP Top 10. На данный момент список выглядит следующим образом:

• A1 Внедрение кода
• A2 Некорректная аутентификация и управление сессией
• A3 Межсайтовый скриптинг (XSS)
• A4 Нарушение контроля доступа
• A5 Небезопасная конфигурация
• A6 Утечка чувствительных данных
• A7 Недостаточная защита от атак
• A8 Подделка межсайтовых запросов (CSRF)
• A9 Использование компонентов с известными уязвимостями
• A10 Незащищенный API

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

1.2. Внедрение кода (SQL Injection)

Все данные, как правило, хранятся в специальных базах, обращения к которым строятся в виде запросов, чаще всего написанных на специальном языке запросов SQL (Structured Query Language – структурированный язык запросов). Приложения используют SQL-запросы для того, чтобы получать, добавлять, изменять или удалять данные, например при редактировании пользователем своих личных данных или заполнении анкеты на сайте. При недостаточной проверке данных от пользователя, злоумышленник может внедрить в форму Web-интерфейса приложения специальный код, содержащий кусок SQL-запроса.

Такой вид атаки называется инъекция, в данном случае самый распространённый — SQL-инъекция. Это опаснейшая уязвимость, позволяющая злоумышленнику получить доступ к базе данных и возможность читать/изменять/удалять информацию, которая для него не предназначена. Например, изменить вместе с именем и фамилией баланс своего счета, посмотреть баланс чужого счета, или же, похитить конфиденциальные личные данные.

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

В целом эта разновидность атак имеет общее название «Ошибки валидации», к ней относятся далеко не только SQL-инъекции и мы будем упоминать этот вектор еще не раз.

1. Пользователь переходит по ссылке, передавая определённые параметры

2. Сервер обрабатывает параметры, формирует SQL-запрос и отправляет его в базу данных

3. База данных возвращает результат и сервер использует \ти данные в формировании страницы

4. Что произойдёт, если в параметре передать строку, содержащую специальные символы, дополняющие SQL-запрос?

5. Сервер обработает эти данные, подставит их в запрос и, если запрос валидный, выполнит запрос

6. Дальше данные обработаются и вернутся на страницу пользователя

Различают несколько видов SQL-инъекций:

1. Внедрение операторов SQL (SQL Injection)
2. Слепое внедрение операторов SQL (Blind SQL Injection)

1.3. Межсайтовый скриптинг (XSS)

Межсайтовое выполнение сценариев (Cross site scripting или XSS) – это возможность вставки HTML\JS – кода в уязвимую страницу. Инъекция кода осуществляется через все доступные способы ввода информации. Успешное завершение атаки может привести к использованию значений различных переменных, доступных в контексте сайта, записи информации, перехвату пользовательских сессий, данных и т.д. Cross-Site Scripting (XSS) – Это уязвимость на стороне клиента.

Условно Cross-Site Scripting (XSS) делят на:

• Сохраненный вариант (Persistent / Stored)
• Отраженный вариант (non-persistent / reflected)

Как это работает:

1. Пользователь вводит на Web-сайте в строке поиска слово “secureweb”.

2. Web-сервер отображает введенную поисковую фразу на странице так, как она была введена в поле

3. Обнаружив уязвимость злоумышленник отправляет жертве ссылку с внедренным кодом

4. После перехода по ссылке в браузере пользователя выполняется внедренный код

5. После выполнения кода злоумышленник может похитить авторизационные данные пользователя и выполнять действия от его имени на сайте

1.4. Подбор паролей

Одним из основных механизмов защиты современных веб-приложений является механизм управления доступом. Обычно выделяют следующие этапы управления доступом:

• идентификация – установление идентификационных данных;
• аутентификация – подтвержденное установление идентифика- ционных данных;
• авторизация – назначение прав идентификационным данным.

При входе в веб-приложение (sign in, log in) пользователь идентифицируется (сообщает свой идентификатор) и аутентифицируется (доказывает, что он именно тот пользователь, чей идентификатор был сообщен). Большинство веб-приложений используют аутентификацию по паролю. В веб-приложениях с высоким уровнем защищенности (например, в Интернет-банках) также применяются протоколы двухфакторной аутентификации. Очевидным недостатком аутентификации по паролю является возможность использования паролей с плохими статистическими характеристиками. Хранение пароля или его передача по каналам связи в открытом или даже зашифрованном виде потенциально несет угрозу раскрытия пароля.

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

Самой распространенной атакой является брутфорс или перебор по словарю. Как это работает:

1. Пользователь задаёт пароль и логин (или использует логин по умолчанию):

2. Злоумышленник с помощью специализированного софта последовательно подбирает пароли пользователя.

1.5. Обратный путь в директориях (Path Traversal)

Атака по обходному пути (также известная как Path Traversal) предназначена для доступа к файлам и каталогам, которые хранятся вне корневой папки сервера. Путем манипулирования переменными, которые ссылаются на файлы с чередованием «dot-dot-slash или (../)» и его вариантами или с использованием абсолютных путей к файлу, может быть получен доступ к произвольным файлам и каталогам, хранящимся в файловой системе, включая исходный код приложения или конфигурацию и критические системные файлы. Следует отметить, что доступ к файлам ограничен управлением операционным доступом системы (например, в случае заблокированных или используемых файлов в операционной системе Microsoft Windows) или файлах без права чтения в Linux.

Как это работает:

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

2. Злоумышленник меняет наименование файла на путь к файлу, который он хочет прочесть, к примеру ../../../../../../../../etc/passwd. Сервер так же обрабатывает параметр и возвращает пользователю файл с соответствующим названием.

1.6. Прямой доступ к объектам

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

mysite.ru/read_message.jsp?id=123654

Перебирая число после id= можно будет читать чужие личные сообщения. Эксплуатация данной уязвимости очень проста и не требует вообще никаких специальных навыков – достаточно лишь перебирать число в адресной строке браузера и наслаждаться результатом. Так же возможно перебирать имена файлов или другие идентификаторы. Как ни парадоксально, но этой "детской болезни", порой были подвержены достаточно крупные европейские платежные системы.

1.7. Некорректная настройка механизмов безопасности

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

• доступность интерфейсов управления в т.ч. фактически неиспользуемые: сетевые порты, URI
• разглашение информации в сообщениях об ошибках (фреймворк, ЯП, СУБД, сервер)
• Проблемы на границе сфер ответственности администраторов и разработчиков (workingCopy)
• автодополнение и кэширование
• отсутствие флагов или заголовков безопасности (защита от client-side атак: Clickjacking, XSS)
• файлы, содержащие конф. информацию, доступны всем (*.php.1)

Несколько примеров того, как это работает:

• доступность интерфейсов управления

• Разглашение информации в сообщениях об ошибках

• Проблемы на границе сфер ответственности администраторов и разработчиков (workingCopy)

1.8. Использование компонентов с известными уязвимостями

Ни одно современное веб-приложение не работает без подключения сторонних компонентов (пришлось бы тратить слишком много времени на изобретение велосипеда). Основная проблема данного подхода в том, что приложение использует чужой код, но не следит за его актуальностью и состоянием. А в этом коде могут содержаться критические уязвимости или незадекларированные возможности. Очень хорошим примером является пример с библиотекой SSL/TLS, в которой за последние несколько лет нашли огромное количество уязвимостей:

• FREAK (экспортные ключи)
• POODLE (downgrade и CBC)
• HEARTBLEED (некорректная проверка длины)
• BEAST (предсказуемый IV и CBC)
• CRIME / BREACH (компрессия)

2. Практическая часть

2.1. Настройка Burp Suite

Скачайте и установите Burp Suite Community

Создайте временный проект

Выбираем настройки по умолчанию

После запуска программы переходим на вкладку “Proxy”, отключаем прерывание запросов:

Переходим на вкладку «Options». Настройка прокси-сервера должна выглядеть следующим образом:

Открываем браузер Chrome и заходим в «настройки» -> «Дополнительно» -> «Настройки прокси-сервера»

После нажатия, попадаем в меню Подключений. Выбираем «Настройка сети»

Настраиваем прокси-сервер в соответствии с тем, что было указано в настройках Burp Suite.

После настройки переходим на сайт http://burpsuite/ и скачиваем сертификат, нажав на кнопку CA Certificate.

После этого заходим в «настройки браузера Chrome» –> «Дополнительно» -> «Настроить сертификаты».

В появившемся окне нажимаем импорт и продвигаемся по меню, выбрав скачанный ранее файл сертификата. Его необходимо добавить в доверенные центры сертификации.

Настройка завершена. Для того, чтобы удостовериться, что всё работает, введите в адресной строке http://yandex.ru

После отображения страницы перейдите в Burp Suite на вкладку «Proxy» -> «HTTP History». В ней вы увидите запросы, которые отправляет ваш браузер и ответы, которые получает от сервера.

2.2. Внедрение кода (SQL Injection)

Осуществляется командой, в которой для заданных критериев применено действие ACCEPT, то есть пакет будет пропущен брэндмауэром.

# 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. Таким образом для определения последнего правила, необходимо ввести в командной строке:

# iptables -t nat -I PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 80

После выполнения команд правила для цепочек сформированы и необходимо осуществить проверку правильности их занесения и работы. Просмотреть созданные правила для всех цепочек можно после выполнения команды:

# iptables –S
# iptables –t nat -S

*Скриншот

Пример первой выполненной команды:

-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, выполнив команду:

$ nmap

Если система выдала ошибку, что такой программы нет, необходимо установить nmap:

# apt-get update
# apt-get install nmap

Запуск команды сканирования портов:

$ nmap localhost

Вывод команды покажет какие порты на данный момент открыты в системе. Пример:

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 в изначальное состояние:

# iptables –F
# iptables –t nat -F

3. Задание

Необходимо сделать перенаправление вызова с соответствующих портов.

Для начала потребуется установить дополнительные пакеты

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;
• screen kill name - удаление окна терминала name;
• screen -ls - список созданных окон.

Комбинация клавиш Ctrl+A+D выйти в главное окно терминала.

Для проверки доступа по указанному порту, в новом окне терминала выполните следующую команду (вместо слова port укажите номер порта)

"port"

port задается в формате 8GVV, где G - номер группы, а VV - вариант из первой лабораторной работы

$ screen -S server
$ python3 –m http.server port

После запуска команды, в браузере необходимо проверить доступность вашего сервера, для этого наберите строку ip_adress:port.

*узнать свой ip-адрес можно с помощью команды ifconfig

В браузере вы увидите страничку с файловой системой:

*Скриншот

Это означает, что порт открыт и вы можете получить доступ к запущенному Web-server. После запуска запустите команду nmap и посмотрите, какие порты открыты сейчас.

После внесения правила перенаправления, проверьте доступность вашего сервера в браузере, перейдя по адресу: ip_adress:redirect_port *Скриншот

"redirect_port"

redirect_port задается в формате 80 + VV, где VV - вариант из первой лабораторной работы (VV = 01 -> redirect_port = 81)

Повторно запустите команду 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:

Рисунок 1

В этом случае VPN узел называется VPN шлюзом, а сеть за ним - доменом шифрования (encryption domain). Использование шлюзов удобно по нескольким причинам. Во-первых, все пользователи должны пройти через одно устройство, которое облегчает задачу управления политикой безопасности и контроля входящего и исходящего трафика сети. Во-вторых, персональные туннели к каждой рабочей станции, к которой пользователю надо получить доступ, очень быстро станут неуправляемыми (т.к. туннель - это канал типа точка-точка). При наличии шлюза, пользователь устанавливает соединение с ним, после чего пользователю открывается доступ к сети (домену шифрования).

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

Рисунок 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 туннель был установлен успешно.

Т.к. каждый узел способен устанавливать несколько туннелей с другими узлами, каждый SA имеет уникальный номер, позволяющий определить к какому узлу он относится. Это номер называется SPI (Security Parameter Index) или индекс параметра безопасности.

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 для обхода блокировок, устанавливаемых провайдерами по указанию уполномоченных органов.

2. Практическая часть

2.1. Установка и настройка серверной части OpenVPN

Устанавливаем OpenVPN

apt-get update
apt install -y openvpn

Настраиваем переадресацию (IP forwarding) (при выключении/перезапуске сервера это повторяем):

modprobe iptable_nat
echo 1 | tee /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 10.4.0.1/2 -o eth0 -j MASQUERADE

Переходим в папку openvpn и создаем секретный ключ:

cd /etc/openvpn
openvpn --genkey --secret ovpn.key

Создаем файл конфигурации OpenVPN, назовем его openvpn.conf, для этого воспользуемся редактором nano работающим в консоли:

nano openvpn.conf

В файл вставляем:

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

Выделенные * строки необходимо изменить на реальные значения

vpn_port

Задается в формате 1194 + VV, где VV - вариант из первой лабораторной работы (VV = 01 -> vpn_port = 1195)

*Скриншот

Нажимаем CTRL+S и подтверждаем запись в файл, выходим из редактора — CTRL+X.

Запускаем OpenVPN на сервере командой

service openvpn start

Проверяем, есть ли у нас открытый порт *vpn_port* на системе

netstat -nlpt

Если открытого порта на системе нет, необходимо его добавить (чтобы можно было устанавливать соединения). Для этого необходимо выполнить команду:

nano /lib/systemd/system/openvpn.service

И изменить следующие строки ExecStart и ExecReload следующим образом:

ExecStart=/bin/true --config /etc/openvpn/openvpn.conf
ExecReload=/bin/true --config /etc/openvpn/openvpn.conf

После сохранения файла:

systemctl daemon-reload
systemctl restart openvpn
netstat -nlpt

В итоге, после выполнения команд должна появиться строка:

...
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 по ссылке и делаем установку "по-умолчанию".

В папке C:\Users\Username\OpenVPN\config\ создаём папку с именем client

Копируем файл /etc/openvpn/ovpn.key (на сервере) в C:\Users\Username\OpenVPN\config\client. Например, с помощью WinSCP или скопировав содержимое в файл с тем же именем

Также в папке client создадим файл с настройками OpenVPN, назовем его client.ovpn. В файл вставим:

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

ip_adress

IP-адрес сервера

*Скриншот

Сохраняем файл

Запускаем OpenVPN ПКМ по значку в трее и переходим на сайт ipinfo.io. Убедитесь, что полученный IP-адрес и адрес удалённой машины совпадают.

*Скриншот

2.3. Установка и настройка клиентской части OpenVPN (Linux)

Открываем окно терминала (можно использовать машину первой лабораторной работы) и устанавливаем OpenVPN:

apt-get update
apt-get install -y openvpn nano curl

Создаём папку для настроек OpenVPN:

mkdir ~/OpenVPNconf && cd  ~/OpenVPNconf

Копируем файл /etc/openvpn/ovpn.Key (на сервере) в ~/OpenVPNconf. Например, с помощью scp:

scp root@ip_adress:/etc/openvpn/ovpn.key  ~/OpenVPNconf/

В ~/OpenVPNconf/ создадим файл с настройками OpenVPN, назовем его openvpn.client.conf:

nano openvpn.client.ovpn	

В файл вставим:

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

path

в настройке "secret" должен быть полный адрес файла ключа

*Скриншот

Сохраняем файл openvpn.client.ovpn

Теперь просто запускаем OpenVPN в консоли командой:

openvpn --config ~/OpenVPNconf/openvpn.client.ovpn

С этого момента весь исходящий сетевой трафик OpenVPN начинает направлять в TUN/TAP и далее на сервер. Putty перестает получать подтверждения на свои запросы и регистрирует сбой соеднинения.

*графическое пояснение

Зная, что тип созданного соедниения ("туннеля") узел-узел, зайти на "локальную машину" можно через VPN-сервер:

ssh root@10.4.0.2

*в отчёте объяснить ввод данного ip-адреса

Проверим, что мы сейчас находимся в клиентской части соединения:

find /root/OpenVPNconf/ -ls

Вывод покажет наличие клиентского конфигурационного файла openvpn.client.ovpn, созданного ранее.

*Скриншот (должна быть видна команда ssh root@10.4.0.2)

Выполним следующую команду:

echo "IP: $(curl -s ipinfo.io/ip)"

*Скриншот

В ней происходит запрос на сервер, отображающий IP-адрес подлючения. Убедитесь, что полученный IP-адрес и адрес удалённой машины совпадают.

Если результат выполнения следующей команды возвращает IP: , то необходимо сделать следующие действия:

nano /etc/resolv.conf

Добавить в конец файла строку и сохранить файл:

nameserver 8.8.8.8

Каждый скриншот должен сопровождаться подробным описанием вводимых команд/настроек и результатов их выполнения