# Лабораторная работа 2 *** ## Выполнение лабораторной работы ### Подключение к серверу Выполняются лабораторные работы на двух серверах: 1. 1 часть и 2 часть пункт 2.1 выполняются на сервере (**hostname : user@G-studentXX-L2-server**): ```sh IP-SERVER:PORT ``` 2. 2 часть пункт 2.3 (клиентская часть OpenVPN в ОС Linux/Ubuntu) выполняется на сервере (**hostname : user@G-studentXX-L2-client**): ```sh 10.5.143.101:PORT ``` Где порт подключения (*PORT*) у каждого студента индивидуальный:
А-01м-23
Студент SSH EXTERNAL 1 EXTERNAL 2 VPN
Антимонов Марк Евгеньевич 10122 10180 10181 10190
Антипов Дмитрий Алексеевич 10222 10280 10281 10290
Вареско Сергей Константинович 10322 10380 10381 10390
Зимовин Михаил Юрьевич 10422 10480 10481 10490
Капкин Егор Вячеславович 10522 10580 10581 10590
Кирьянов Борис Юрьевич 10622 10680 10681 10690
Ковалев Артур (Ин) 10722 10780 10781 10790
Козлов Игорь Алексеевич 10822 10880 10881 10890
Кононенко Александр Вячеславович 10922 10980 10981 10990
Кочурова Виктория Артёмовна 11022 11080 11081 11090
Ли Егор Андреевич 11122 11180 11181 11190
Медведев Игорь Сергеевич 11222 11280 11281 11290
Поташов Сергей Евгеньевич 11322 11380 11381 11390
Солдатов Михаил Дмитриевич 11422 11480 11481 11490
Черемных Юрий Алексеевич 11522 11580 11581 11590
А-02м-23
Студент SSH EXTERNAL 1 EXTERNAL 2 VPN
Викторов Глеб Олегович 20122 20180 20181 20190
Градов Алексей Олегович 20222 20280 20281 20290
Китайский Артём Сергеевич 20322 20380 20381 20390
Макаров Кирилл Олегович 20422 20480 20481 20490
Мосалов Кирилл Дмитриевич 20522 20580 20581 20590
Наников Игорь Яковлевич 20622 20680 20681 20690
Савин Вадим Евгеньевич 20722 20780 20781 20790
Сметанин Александр Сергеевич 20822 20880 20881 20890
Соколов Игорь Алексеевич 20922 20980 20981 20990
Фенске Александр Вячеславович 21022 21080 21081 21090
Шашерина Александра Всеволодовна 21122 21180 21181 21190
Шепелев Дмитрий Дмитриевич 21222 21280 21281 21290
Юрченков Глеб Андреевич 21322 21380 21381 21390
Логин: **root** Пароль: **root** ***Рекомендуется изменить пароль** ### Требования к отчёту: - Титульный лист - Описание проделанной работы и вводимых команд - Скриншоты результатов выполнения и их описание - Вывод *** ## Часть 1. Настройка межсетевого экрана в Linux-системах ### Цель работы Получить практические навыки настройки межсетевого экрана (фаервола), а также настройки переадресации сетевых соединений и трансляции адресов (NAT). ### 1. Теоретическая часть **Брандмауэр** - это система или группа систем, реализующих правила управления доступом между двумя сетями. Фактические средства, с помощью которых это достигается, весьма различны, но в принципе брандмауэр можно рассматривать как пару механизмов: один для блокирования передачи информации, а другой, - для пропуска информации. Некоторые брандмауэры уделяют больше внимания блокировке передачи информации, другие - ее пропуску. Важно понимать, что конфигурация брандмауэра, как механизма обеспечения выполнения определенных правил, определяет правила для всех систем, которые он защищает. ### 1.1. Работа *IPTABLES*. Основные понятия Обработка пакетов осуществляется согласно определенным правилам. Каждое правило - это строка, содержащая в себе критерии определяющие, подпадает ли пакет под заданное правило, и действие, которое необходимо выполнить в случае выполнения критерия. В общем виде правила задаются в командной строке так: ```sh 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` (журналирование запроса). Поскольку политика по умолчанию определяется для всех портов, критерии проверки опускаются. ```ssh iptables -P INPUT ACCEPT iptables -A INPUT -j LOG ``` Определим также политику «по-умолчанию» для исходящих пакетов с разрешением всем исходящим IP-пакетам беспрепятственно проходить фильтрацию. Для определения заданной политики по умолчанию необходимо выполнить в консоли ```ssh iptables -P OUTPUT ACCEPT ``` ### 2.2. Добавление правил для портов 22 и 80 Осуществляется командой, в которой для заданных критериев применено действие 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 -t nat -I PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 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. Задание Необходимо сделать перенаправление вызова с \*EXTERNAL 2\* на \*EXTERNAL 1\*. Для начала потребуется установить дополнительные пакеты ```ssh apt-get update apt install -y screen python3-pip net-tools nano pip install simple-http-server ``` Утилита `screen` позволяет создавать независимые окна терминала: - `screen -S name` - создание окна терминала с идентификатором `name` и переход в него; - `screen -r name` - переход в окно терминала `name`; - `screen kill name` - удаление окна терминала `name`; - `screen -ls` - список созданных окон. Комбинация клавиш `Ctrl+A+D` выйти в главное окно терминала. Для проверки доступа по указанному порту, в новом окне терминала выполните следующие команды ```ssh screen -S server python3 -m http.server *EXTERNAL 1* ``` После запуска команды, в браузере необходимо проверить доступность вашего сервера, для этого наберите строку: ```ssh http://*IP-SERVER*:*EXTERNAL 1* ``` **узнать свой ip-адрес можно с помощью команды `ifconfig`* В браузере вы увидите страничку с файловой системой: ***Скриншот** Это означает, что порт открыт и вы можете получить доступ к запущенному Web-server. После запуска запустите команду **nmap** и посмотрите, какие порты открыты сейчас. После внесения правила перенаправления, проверьте доступность вашего сервера в браузере, перейдя по адресу: ```ssh http://*IP-SERVER*:*EXTERNAL 2* ``` ***Скриншот** Повторно запустите команду **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 ```ssh apt-get update apt install -y openvpn ``` Настраиваем маскарадинг (или маскирование) исходящих пакетов из подсети 10.4.0.1/2, направленных к интерфейсу *eth0* ```ssh iptables -t nat -A POSTROUTING -s 10.4.0.1/2 -o eth0 -j MASQUERADE ``` Переходим в папку openvpn и создаем секретный ключ: ```ssh cd /etc/openvpn openvpn --genkey secret ovpn.key ``` Создаем файл конфигурации OpenVPN, назовем его openvpn.conf, для этого воспользуемся редактором `nano` работающим в консоли: ```ssh nano openvpn.conf ``` В файл вставляем: ```ssh port *VPN* proto tcp-server dev tun1 ifconfig 10.4.0.1 10.4.0.2 status server-tcp.log verb 3 secret ovpn.key ``` **Выделенные `*` строки необходимо изменить на реальные значения** ***Скриншот** Нажимаем `CTRL+S` и подтверждаем запись в файл, выходим из редактора — `CTRL+X`. Запускаем OpenVPN на сервере командой ```ssh service openvpn start ``` Проверяем, есть ли у нас открытый порт `*VPN*` на системе ```ssh netstat -nlpt ``` Если открытого порта на системе нет, необходимо его добавить (чтобы можно было устанавливать соединения). Для этого необходимо выполнить команду: ```ssh nano /lib/systemd/system/openvpn.service ``` И изменить следующие строки `ExecStart` и `ExecReload` следующим образом: ```ssh ExecStart=/bin/true --config /etc/openvpn/openvpn.conf ExecReload=/bin/true --config /etc/openvpn/openvpn.conf ``` После сохранения файла: ```ssh systemctl daemon-reload systemctl restart openvpn netstat -nlpt ``` В итоге, после выполнения команд должна появиться строка: ```ssh ... Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:*VPN* 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` Копируем файл `/etc/openvpn/ovpn.key` (на сервере) в `C:\Users\Username\OpenVPN\config\client`. Например, с помощью `WinSCP` или скопировав содержимое в файл с тем же именем Также в папке `client` создадим файл с настройками OpenVPN, назовем его `client.ovpn`. В файл вставим: ```ssh proto tcp-client remote *IP-SERVER* port *VPN* dev tun secret ovpn.keY providers legacy default redirect-gateway def1 ifconfig 10.4.0.2 10.4.0.1 ``` ***Скриншот** Сохраняем файл Запускаем OpenVPN ПКМ по значку в трее и переходим на сайт [ipinfo.io](https://ipinfo.io/ip). Убедитесь, что полученный IP-адрес и адрес удалённой машины совпадают. ***Скриншот** ### 2.3. Установка и настройка клиентской части OpenVPN (Linux) Открываем окно терминала (второй сервер) и устанавливаем OpenVPN: ```ssh apt-get update apt-get install -y openvpn nano curl ``` Создаём папку для настроек OpenVPN: ```ssh mkdir ~/OpenVPNconf && cd ~/OpenVPNconf ``` Копируем файл `/etc/openvpn/ovpn.Key` (на VPN-сервере) в `~/OpenVPNconf`. Например, с помощью `scp`: ```ssh scp -P *SSH* root@*IP-SERVER*:/etc/openvpn/ovpn.key ~/OpenVPNconf/ ``` В `~/OpenVPNconf/` создадим файл с настройками OpenVPN, назовем его openvpn.client.conf: ```ssh nano openvpn.client.ovpn ``` В файл вставим: ```ssh proto tcp-client remote *IP-SERVER* port *VPN* dev tun secret *path*/ovpn.key redirect-gateway def1 ifconfig 10.4.0.2 10.4.0.1 ```
path в настройке "secret" должен быть полный адрес файла ключа
***Скриншот** Сохраняем файл openvpn.client.ovpn Теперь просто запускаем OpenVPN в консоли командой: ```ssh openvpn --config ~/OpenVPNconf/openvpn.client.ovpn ``` С этого момента весь исходящий сетевой трафик OpenVPN начинает направлять в TUN/TAP и далее на сервер. Putty перестает получать подтверждения на свои запросы и регистрирует сбой соеднинения.
*графическое пояснение
Зная, что тип созданного соедниения ("туннеля") *узел-узел*, зайти на "локальную машину" можно через VPN-сервер: ```ssh ssh root@10.4.0.2 ``` ***в отчёте объяснить ввод данного ip-адреса** Проверим, что мы сейчас находимся в клиентской части соединения: ```ssh find /root/OpenVPNconf/ -ls ``` Вывод покажет наличие клиентского конфигурационного файла `openvpn.client.ovpn`, созданного ранее. ***Скриншот (должна быть видна команда `ssh root@10.4.0.2`)** Выполним следующую команду: ```ssh echo "IP: $(curl -s ipinfo.io/ip)" ``` ***Скриншот** В ней происходит запрос на сервер, отображающий IP-адрес подлючения. Убедитесь, что полученный IP-адрес и адрес удалённой машины совпадают. Если результат выполнения следующей команды возвращает `IP: `, то необходимо сделать следующее действие: ```ssh echo "nameserver 8.8.8.8" >> /etc/resolv.conf ```