infosec/labs/lab3/README.md

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

Цель работы

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

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

Брандмауэр - это система или группа систем, реализующих правила управления доступом между двумя сетями. Фактические средства, с помощью которых это достигается, весьма различны, но в принципе брандмауэр можно рассматривать как пару механизмов: один для блокирования передачи информации, а другой, - для пропуска информации. Некоторые брандмауэры уделяют больше внимания блокировке передачи информации, другие - ее пропуску. Важно понимать, что конфигурация брандмауэра, как механизма обеспечения выполнения определенных правил, определяет правила для всех систем, которые он защищает.

1.1. Работа IPTABLES. Основные понятия

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

• # - если перед командой стоит данный знак, это означает, что команда должна выполняться от имени пользователя root (суперпользователь)
• $ - если перед командой стоит данный знак, это означает, что команда должна выполняться от имени обычного пользователя.

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

# iptables [-t table] command [match] [target/jump]         

Если в правило не включается спецификатор [-t table], то по умолчанию предполагается использование таблицы filter, если же предполагается использование другой таблицы, то это требуется указать явно. Спецификатор таблицы так же можно указывать в любом месте строки правила, однако более или менее стандартом считается указание таблицы в начале правила. Можно использовать следующие таблицы:

• Таблица nat используется главным образом для преобразования сетевых адресов (Network Address Translation). Через эту таблицу проходит только первый пакет из потока. Преобразования адресов автоматически применяется ко всем последующим пакетам;
• Таблица mangle используется для внесения изменений в заголовки пакетов. Примером может служить изменение поля TTL, TOS или MARK;
• Таблица filter используется главным образом для фильтрации пакетов. Для примера, здесь мы можем выполнить DROP, LOG, ACCEPT или REJECT без каких либо ограничений, которые имеются в других таблицах;

Далее, непосредственно за именем таблицы, должна стоять команда. Если спецификатора таблицы нет, то команда всегда должна стоять первой. Команда определяет действие iptables, например: вставить правило, или добавить правило в конец цепочки, или удалить правило и т.п. Ниже перечислены команды iptables:

• -A, --append - добавление нового правила в конец заданной цепочки;
• -D, --delete - удаление правила из цепочки. Команда имеет два формата записи, первый - когда задается критерий сравнения с опцией -D, второй - порядковый номер правила;
• -R, --replace - замена одного правила другим;
• -I, --insert - вставка нового правила в цепочку. Число, следующее за именем цепочки, задает номер для вставляемого правила;
• -L, --list - вывод списка правил в заданной цепочке. Если имя цепочки не указывается, то выводится список правил для всех цепочек;
• -F, --flush - сброс (удаление) всех правил из заданной цепочки (таблицы). Если имя цепочки и таблицы не указывается, то удаляются все правила, во всех цепочках;
• -Z, --zero - обнуление всех счетчиков в заданной цепочке. Если имя цепочки не указывается, то подразумеваются все цепочки;
• -N, --new-chain - создание новой цепочки с заданным именем в заданной таблице;
• -X, --delete-chain - удаление заданной цепочки из заданной таблицы. Удаляемая цепочка не должна иметь правил, а также ссылок на нее из других цепочек. Если имя цепочки не указано, то будут удалены все цепочки заданной таблицы кроме встроенных;
• -P, --policy - определение политики «по-умолчанию» для заданной цепочки. Политика «по-умолчанию» определяет действие, применяемое к пакетам, не попавшим под действие ни одного из правил в цепочке;
• -E, --rename-chain - переименование пользовательской цепочки.

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

• -p, --protocol - тип протокола. Примерами протоколов могут быть TCP, UDP и ICMP (список протоколов можно посмотреть в файле /etc/protocols), а также ключевое слово ALL;
• -s, -src, --source - IP-адрес(а) источника пакета. Может указываться как единственный IP-адрес, так и в виде address/mask, например как 192.168.0.0/255.255.255.0,или 192.168.0.0/24. Символ !, установленный перед адресом, означает логическое отрицание;
• -d, -dst, --destination - IP-адрес(а) получателя. Имеет синтаксис схожий с критерием -source;
• -i, --in-interface - интерфейс, с которого получен пакет. При отсутствии этого критерия предполагается любой интерфейс;
• -o, --out-interface - имя выходного интерфейса. Критерий допускается использовать только в цепочках OUTPUT, FORWARD и POSTROUTING, в противном случае будет генерироваться сообщение об ошибке;
• -f, --fragment - правило распространяется на все фрагменты фрагментированного пакета, кроме первого;
• -m limit - устанавливает предельное число пакетов в единицу времени, которое способно пропустить правило;
• --dport, ¬-destination-port - порт или диапазон портов, на который адресован пакет;

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

• ACCEPT - пакет прекращает движение по цепочке (и всем вызвавшим цепочкам, если текущая цепочка была вложенной) и считается принятым;
• DNAT - используется для преобразования адреса места назначения в IP заголовке пакета.Если пакет подпадает под критерий правила, выполняющего DNAT, то этот пакет, и все последующие пакеты из этого же потока, будут подвергнуты преобразованию адреса назначения и переданы на требуемое устройство, хост или сеть;
• DROP - действие «сбрасывает» пакет. "Сброшенные" пакеты прекращают свое движение полностью;
• LOG служит для журналирования отдельных пакетов и событий. В журнал могут заноситься заголовки IP пакетов и другая интересующая информация;
• MARK используется для установки меток на определенные пакеты. Действие может выполняться в пределах таблицы mangle;
• QUEUE - ставит пакет в очередь на обработку пользовательскому процессу. Оно может быть использовано для нужд учета, проксирования или дополнительной фильтрации пакетов;
• REDIRECT - выполняет перенаправление пакетов и потоков на другой порт той же ЭВМ;
• REJECT - используется, как правило, в тех же самых ситуациях, что и DROP, но в отличие от нее, команда 'REJECT` выдает сообщение об ошибке на хост, передавший пакет;
• RETURN - прекращает движение пакета по текущей цепочке правил и производит возврат в вызывающую цепочку, если текущая цепочка была вложенной, или, если текущая цепочка лежит на самом верхнем уровне (например, INPUT), то к пакету будет применена политика «по-умолчанию»;
• SNAT - используется для преобразования сетевых адресов, т.е. изменение исходящего IP адреса в IP заголовке пакета;
• TOS используется для установки битов в поле Type of Service IP заголовка. Поле TOS содержит 8 бит, которые используются для маршрутизации пакетов;
• TTL используется для изменения содержимого поля Time To Live в IP заголовке;
• ULOG предоставляет возможность журналирования пакетов в пользовательское пространство. Оно заменяет традиционное действие LOG, базирующееся на системном журнале.

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

Описание задачи: требуется защитить web-сервер. Необходимо разрешить доступ к портам 80 и 22 и сделать перенаправление вызова с порта 8080 на 80. При попытке обратится к портам сервера, не описанным в операционной системе (ОС) как сервис, следует отказывать в обслуживании. При попытке обратится к портам, описанным в системе как сервисы, следует отказывать в обслуживании и заносить данные об этом в журнал. Для выполнения задания необходима следующая последовательность действий.

2.1. Определение политики по умолчанию

Определение политики по умолчанию для цепочек с учетом того, что все порты системы для должны быть закрыты для внешнего пользователя. Поскольку осуществляется фильтрация пакетов, их обработка будет производится в таблице filter. Используем ключ –P чтобы задать политику по умолчанию. Зададим правило для входящих пакетов (цепочка INPUT). Действие для обработки политики по умолчанию LOG (журналирование запроса). Поскольку политика по умолчанию определяется для всех портов, критерии проверки опускаются.

# iptables -P INPUT ACCEPT
# iptables -A INPUT -j LOG

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

# iptables –P OUTPUT ACCEPT         

2.2. Добавление правил для портов 22 и 80

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

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