(Свободный проект альтруистов) 100% выполненное задание (публичный вариант) к демонстрационному экзамену по сетевому и системному администрированию. Полностью и только на Debian. Основано на первоисточнике: https://github.com/storm39mad/DEMO2022/tree/main/azure
В формате docx: Very Easy Linux.docx
| Name VM | ОС | RAM | CPU | IP | Additionally |
|---|---|---|---|---|---|
| RTR-L | Debian 11/CSR | 2 GB | 2/4 | 4.4.4.100/24 | |
| 192.168.100.254/24 | |||||
| RTR-R | Debian 11/CSR | 2 GB | 2/4 | 5.5.5.100/24 | |
| 172.16.100.254 /24 | |||||
| SRV | Debian 11/Win 2019 | 2 GB /4 GB | 2/4 | 192.168.100.200/24 | Доп диски 2 шт по 5 GB |
| WEB-L | Debian 11 | 2 GB | 2 | 192.168.100.100/24 | |
| WEB-R | Debian 11 | 2 GB | 2 | 172.16.100.100/24 | |
| ISP | Debian 11 | 2 GB | 2 | 4.4.4.1/24 | |
| 5.5.5.1/24 | |||||
| 3.3.3.1/24 | |||||
| CLI | Win 10 | 4 GB | 4 | 3.3.3.10/24 |
Необходимо выполнить создание и базовую конфигурацию виртуальных машин.
- На основе предоставленных ВМ или шаблонов ВМ создайте отсутствующие виртуальные машины в соответствии со схемой.
- Характеристики ВМ установите в соответствии с Таблицей 1;
- Коммутацию (если таковая не выполнена) выполните в соответствии со схемой сети.
- Имена хостов в созданных ВМ должны быть установлены в соответствии со схемой.
- Адресация должна быть выполнена в соответствии с Таблицей 1;
- Обеспечьте ВМ дополнительными дисками, если таковое необходимо в соответствии с Таблицей 1;
#(Если изначально доступна работа из под пользователя с обычными привилегиями, то повышение привилегий, то есть работа из под root, выполняется через команду sudo -i).
#На демо-экзамене предоставляются ISO-образы с дополнительным ПО. Установка пакетов через них. Выход в реальный интернет не предоставляется.
#К примеру, на виртуальной машине RTR-L нужно установить необходимые по заданию пакеты. Для этого необходимо вмонтировать в VM один из ISO-образов и добавить его в source.list (необязательно все, только самый первый).
#Одновременно с добавлением образа в source.list, производится обновление списка доступных пакетов от каждого смонтированного образа.
#Если требуется установить ПО, связанные с которым пакеты находятся на нескольких образах, то в proxmox надо так же выбрать уже другой образ, по образцу выше. После этого в Debian, для обновления пакетов от другого образа, нужно выполнить следующие команды:
#Далее нужно настроить статическую IP-адресацию на каждой машине. Адресация представлена в конце комплекта оценочной документации. Для сопоставления MAC-адресов с IP-адресами на каждой машине, нужно проделать следующее:
#На proxmox, при выборе виртуальной машины и просмотре списка его оборудования, нужно обратить внимание на MAC-адрес и имя моста (bridge). У другой машины, присоединённой к текущей (пример ISP), имя моста будет идентичным.
#По одинаковому названию моста можно увидеть связность конкретных машин. По их MAC-адресам — связь с IP-адресами.
#Настройка IP-адресов каждой машины (кроме CLI). Каждый интерфейс настраивается через nmcli одной длинной командой:
#Названия интерфейсов можно посмотреть и через nmcli connection. Если наименования не содержат Wired connection и они имеют красный цвет, то нужно ввести команду systemctl restart NetworkManager и заново ввести nmcli connection.
#Элементы команд полностью не нужно вписывать (кроме имён и цифр). Достаточно вбить начало команды (пример: ipv4.ad), как в терминале Cisco, и через нажатие на TAB произойдёт автодописывание (ipv4.addresses).
nmc(TAB) co(TAB) mod(TAB) Wi(TAB) 1 ipv4.a(TAB) 5.5.5.1/24 ipv4.me(TAB) m(TAB) au(TAB) y(TAB) con-n(TAB) ISP-RTRR.
#На виртуальной машине CLI, по заданию, операционная система Windows 10. Порядок изменения имени хоста и IP-адреса там другой:
#Для отправки файлов с помощью scp (или для соединения по ssh), нужно отредактировать sshd_config на начальной (откуда), конечной (куда отправляем файл) и промежуточной виртуальной машине (через какую машину проходит файл). Допустим, нужно отправить файл test с RTR-L на RTR-R. После установки пакетов, включая ssh, на RTR-L, RTR-R и ISP между ними редактируется строка с разрешением на аутентификацию из под root.
В рамках данного модуля требуется обеспечить сетевую связность между регионами работы приложения, а также обеспечить выход ВМ в имитируемую сеть “Интернет”
- Сети, подключенные к ISP, считаются внешними:
- Запрещено прямое попадание трафика из внутренних сетей во внешние и наоборот;
#Сперва, нужно разрешить пересылку пакетов через устройства, осуществляющих маршрутизацию (RTR-L, ISP и RTR-R).
#Для выполнения условия о запрете прямого прохождения трафика, необходимо установить firewalld на RTR-L и RTR-R. Интерфейсы на них, смотрящие во внешние сети, определить в зону external. В зоне external разрешён не весь, а только определённый вручную тип трафика, а также выполняется трансляция трафика, идущего из внутренних сетей во внешние.
- Платформы контроля трафика, установленные на границах регионов, должны выполнять трансляцию трафика, идущего из соответствующих внутренних сетей во внешние сети стенда и в сеть Интернет.
- Трансляция исходящих адресов производится в адрес платформы,расположенный во внешней сети.
- Между платформами должен быть установлен защищенный туннель, позволяющий осуществлять связь между регионами с применением внутренних адресов.
- Трафик, проходящий по данному туннелю, должен быть защищен:
- Платформа ISP не должна иметь возможности просматривать содержимое пакетов, идущих из одной внутренней сети в другую.
- Туннель должен позволять защищенное взаимодействие между платформами управления трафиком по их внутренним адресам
- Взаимодействие по внешним адресам должно происходит без применения туннеля и шифрования
- Трафик, идущий по туннелю между регионами по внутренним адресам, не должен транслироваться.
- Трафик, проходящий по данному туннелю, должен быть защищен:
#На RTR-L и RTR-R устанавливаем libreswan для работы IPsec (создание защищённого туннеля). Для его установки потребуется использовать два образа с ПО, монтируя и извлекая их поочерёдно, когда потребует этого установщик в debian.
#Сначала выполняется создание GRE-туннеля между RTR-L и RTR-R. После — настройка файрволла на ISP. Поверх туннеля — настройка IPsec.
#Для большего удобства, лучше скопировать mytunnel.conf и mytunnel.secrets с RTR-L на RTR-R через scp, в аналогичную директорию.
#Дополнительная проверка работы IPsec. Запуск tcpdump на ISP, при оправке ICMP-запросов с RTR-R на RTR-L. На скрине ниже видно, что ICMP-запросы и ответы именуются иначе.
#Для организации подключения виртуальных машин, имеющих адреса во внутренних сетях, к новосозданному туннелю и для связи стороны Left со стороной Right, нужно настроить один из протоколов маршрутизации (EIGRP или OSPF) с помощью frr.
- Платформа управления трафиком RTR-L выполняет контроль входящего трафика согласно следующим правилам:
- Разрешаются подключения к портам DNS, HTTP и HTTPS для всех клиентов;
- Порты необходимо для работы настраиваемых служб
- Разрешается работа выбранного протокола организации защищенной связи;
- Разрешение портов должно быть выполнено по принципу “необходимо и достаточно”
- Разрешается работа протоколов ICMP;
- Разрешается работа протокола SSH;
- Прочие подключения запрещены;
- Для обращений в платформам со стороны хостов, находящихся внутри регионов, ограничений быть не должно;
- Разрешаются подключения к портам DNS, HTTP и HTTPS для всех клиентов;
- Платформа управления трафиком RTR-R выполняет контроль входящего трафика согласно следующим правилам:
- Разрешаются подключения к портам HTTP и HTTPS для всех клиентов;
- Порты необходимо для работы настраиваемых служб
- Разрешается работа выбранного протокола организации защищенной связи;
- Разрешение портов должно быть выполнено по принципу необходимо и достаточно”
- Разрешается работа протоколов ICMP;
- Разрешается работа протокола SSH;
- Прочие подключения запрещены;
- Для обращений в платформам со стороны хостов, находящихся внутри регионов, ограничений быть не должно;
- Разрешаются подключения к портам HTTP и HTTPS для всех клиентов;
- Обеспечьте настройку служб SSH региона Left и Right:
- Подключения со стороны внешних сетей по протоколу к платформе управления трафиком RTR-L на порт 2222 должны быть перенаправлены на ВМ Web-L;
- Подключения со стороны внешних сетей по протоколу к платформе управления трафиком RTR-R на порт 2244 должны быть перенаправлены на ВМ Web-R;
#Проверка подключения по ssh. Если на CLI имя пользователя не «root», то к команде ssh дописывается -l root (английская л):
В рамках данного модуля необходимо настроить основные инфраструктурные службы и настроить представленные ВМ на применение этих служб для всех основных функций.
- Выполните настройку первого уровня DNS-системы стенда:
- Используется ВМ ISP;
- Обслуживается зона demo.wsr
- Наполнение зоны должно быть реализовано в соответствии с Таблицей 2;
- Сервер делегирует зону int.demo.wsr на SRV;
- Поскольку SRV находится во внутренней сети западного региона, делегирование происходит на внешний адрес маршрутизатора данного региона.
- Маршрутизатор региона должен транслировать соответствующие порты DNS-службы в порты сервера SRV
- Внешний клиент CLI должен использовать DNS-службу, развернутую на ISP, по умолчанию;
(Делегирование зоны — это не то же самое, что и создание slave-сервера! В нашем случае создаются два master-сервера!).
| Zone | Type | Key | Meaning |
|---|---|---|---|
| demo.wsr | A | isp | 3.3.3.1 |
| A | www | 4.4.4.100 | |
| A | www | 5.5.5.100 | |
| CNAME | internet | isp | |
| NS | int | rtr-l.demo.wsr | |
| A | rtr-l | 4.4.4.100 |
- Выполните настройку второго уровня DNS-системы стенда;
- Используется ВМ SRV;
- Обслуживается зона int.demo.wsr;
- Наполнение зоны должно быть реализовано в соответствии с Таблицей 2;
- Обслуживаются обратные зоны для внутренних адресов регионов
- Имена для разрешения обратных записей следует брать из Таблицы 2;
- Сервер принимает рекурсивные запросы, исходящие от адресов внутренних регионов;
- Обслуживание клиентов(внешних и внутренних), обращающихся к к зоне int.demo.wsr, должно производится без каких либо ограничений по адресу источника;
- Внутренние хосты регионов (равно как и платформы управления трафиком) должны использовать данную DNS-службу для разрешения всех запросов имен;
| Zone | Type | Key | Meaning |
|---|---|---|---|
| int.demo.wsr | A | web-l | 192.168.100.100 |
| A | web-r | 172.16.100.100 | |
| A | srv | 192.168.100.200 | |
| A | rtr-l | 192.168.100.254 | |
| A | rtr-r | 172.16.100.254 | |
| A | webapp2 | 192.168.100.100 | |
| A | webapp2 | 172.16.100.100 | |
| CNAME | webapp | webapp2 | |
| CNAME | ntp | srv | |
| CNAME | dns | srv |
#На SRV выполняются аналогичные шаги, вплоть до настройки apparmor. После apparmor — уже с дополнительными коррективами:
- Выполните настройку первого уровня системы синхронизации времени:
- Используется сервер ISP.
- Сервер считает собственный источник времени верным, stratum=4;
- Сервер допускает подключение только через внешний адрес соответствующей платформы управления трафиком;
- Подразумевается обращение SRV для синхронизации времени;
- Клиент CLI должен использовать службу времени ISP;
#Далее нужно зайти на CLI и синхронизировать время с ISP. Для начала, нужно любыми способами зайти в Панель Управления и выбрать «Дата и Время».
#Дополнительно, нужно включить автоматическую синхронизацию времени и даты. Делается это так же через Control Panel (Панель управления) -> Administrative Tools -> Services -> Windows Time. С ручного управления переключаем на автоматическое, запускаем сервис и применяем изменения.
- Выполните конфигурацию службы второго уровня времени на SRV
- Сервер синхронизирует время с хостом ISP;
- Синхронизация с другими источникам запрещена;
- Сервер должен допускать обращения внутренних хостов регионов, в том числе и платформ управления трафиком, для синхронизации времени;
- Все внутренние хосты(в том числе и платформы управления трафиком) должны синхронизировать свое время с SRV;
- Сервер синхронизирует время с хостом ISP;
- Реализуйте файловый SMB-сервер на базе SRV
- Сервер должен предоставлять доступ для обмена файлами серверам WEB-L и WEB-R;
- Сервер, в зависимости от ОС, использует следующие каталоги для хранения файлов:
- /mnt/storage для система на базе Linux;
- Диск R:\ для систем на базе Windows;
- Хранение файлов осуществляется на диске (смонтированном по указанным выше адресам), реализованном по технологии RAID типа “Зеркало”;
- Сервера WEB-L и WEB-R должны использовать службу, настроенную на SRV, для обмена файлами между собой:
- Служба файлового обмена должна позволять монтирование в виде стандартного каталога Linux
- Разделяемый каталог должен быть смонтирован по адресу /opt/share;
- Каталог должен позволять удалять и создавать файлы в нем для всех пользователей;
- Служба файлового обмена должна позволять монтирование в виде стандартного каталога Linux
#На SRV сначала нужно реализовать программно RAID 1 (Зеркало) на двух накопителях по 2 ГБ. Сами накопители уже имеются на SRV. Наличие и наименования накопителей проверяются командами fdisk -l или lsblk.
#Далее перезагружаем SRV командой reboot. После перезагрузки и входа из под root, перепроверяем наименование RAID-массива. Оно должно измениться.
#После выполнения тех же действий на WEB-L, в качестве итоговой проверки следует создать нового пользователя (желательно на WEB-L и WEB-R), зайти из под него и попробовать создать, отредактировать и удалить файлы по пути /opt/share. Ограничений в действиях быть не должно.
- (Один из возможных вариантов) Реализуйте файловый сервер на базе SRV
- Сервер должен предоставлять доступ для обмена файлами серверам WEB-L и WEB-R;
- Сервер, в зависимости от ОС, использует следующие каталоги для хранения файлов:
- /mnt/storage для система на базе Linux;
- Диск R:\ для систем на базе Windows;
- Все созданные файлы в рамках обмена должны принадлежать одному специальному пользователю;
- Сервера WEB-L и WEB-R должны использовать службу, настроенную на SRV, для обмена файлами между собой:
- Служба файлового обмена должна позволять монтирование в виде стандартного каталога Linux;
- Разделяемый каталог должен быть смонтирован по адресу /opt/share;
- Каталог должен позволять удалять и создавать файлы в нем для всех пользователей;
- Служба файлового обмена должна позволять монтирование в виде стандартного каталога Linux;
#2. Не указано, что необходимо реализовывать именно файловый SMB-сервер, то есть, можно любой другой.
#3. Условие «Все созданные файлы в рамках обмена должны принадлежать одному специальному пользователю» следует понимать так: создаваемые файлы в /mnt/storage (SRV) и /opt/share (WEB-L и WEB-R), при проверке через ls -l, должны показывать свою принадлежность конкретному пользователю, допустим, tester, а не root и nobody.
#4. Условие с принадлежностью файлов конкретному пользователю ставит под сомнение возможность использования Samba, так как там это крайне трудно реализовать.
#Теперь необходимо внести изменения в конфигурационный файл /etc/exports, позволяющие осуществить монтирование каталогов с помощью NFS. Параметры первой добавленной строки позволят создавать файлы на SRV из под пользователя tester. Следующие четыре строки дают доступ хостам к каталогу /mnt/storage и также выполняют функции первой строки.
#Если ВДРУГ потребуется перезагрузить SRV, то скорее всего, после ввода команды reboot, появится такое сообщение. Ничего страшного в нём нет, потребуется только подождать 1-2 минуты до завершения перезагрузки.
- (Одна из возможных полных альтернатив настройке файлового сервера) Выполните конфигурацию служб SSH на WEB-L и WEB-R:
- SSH-сервер должен использовать порт 1022;
- Подключение с аккаунтом root разрешено только в связках WEB-L WEB-R и WEB-R WEB-L;
- Внешние подключения к WEB-L возможны только для специально созданного аккаунта sshuser;
- Подключения из внутренних сетей к WEB-L и WEB-R возможны для любых аккаунтов, кроме root;
#Все необходимые настройки вносятся в конфигурационный файл /etc/ssh/sshd_config, на WEB-L и WEB-R. И так как в этом задании изменён порт ssh, то позже нужно будет изменить правила в файрволлах на RTR-L и RTR-R, для обеспечения корректного доступа с внешних сетей.
#То есть, запись root@192.168.100. * включает в себя связку из аккаунта root и диапазона адресов внутренней сети 192.168.100.0 - 192.168.100.255.
#Запись sshuser@?.?.?. * включает в себя связку из аккаунта sshuser и диапазонов адресов, которым соответствуют внешние сети в задании: 3.3.3.0 - 3.3.3.255, 4.4.4.0 - 4.4.4.255, 5.5.5.0 - 5.5.5.255.
#Запись * @192.168.100. * включает в себя связку из любых аккаунтов и диапазона адресов внутренней сети 192.168.100.0 - 192.168.100.255.
#Далее необходимо сгенерировать приватные и публичные ключи на WEB-L и WEB-R, а после — отправить друг другу только публичные ключи. Предполагается, что по беспарольной аутентификации, с использованием ключей, WEB-L и WEB-R будут взаимодействовать только между собой. А с остальными ПК и не-root аккаунтами — по паролям.
#Такие действия необходимы для соблюдения условий задания о запрете на вход из под root со стороны внутренних сетей, а конкретнее, с адресов GRE-туннеля. Через DenyUsers в /etc/ssh/sshd_config не получится просто запретить связку root@10.5.5. *, в противном случае соединение по ssh между WEB-L и WEB-R не будет устанавливаться.
#Редактирование правил на файрволлах RTR-L и RTR-R, которые касаются именно перенаправления подключений по ssh.
#Теперь, для проверки соблюдения всех заданных условий, необходимо создать какого-нибудь пользователя и пользователя sshuser на WEB-L и WEB-R. Затем, в различных вариациях пробовать подключаться по ssh к WEB-L и WEB-R.
- Выполните настройку центра сертификации на базе SRV:
- В случае применения решения на базе Linux используется центр сертификации типа OpenSSL и располагается по адресу /var/ca
- Выдаваемые сертификаты должны иметь срок жизни не менее 500 дней;
- Параметры выдаваемых сертификатов:
- Страна RU;
- Организация DEMO.WSR;
- Прочие поля (за исключением CN) должны быть пусты;
#По пути /var/ca/ теперь расположен наш локальный корневой центр сертификации, со всеми необходимыми для него файлами.
Данный блок подразумевает установку и настройку доступа к веб-приложению, выполненному в формате контейнера Docker
- Образ Docker (содержащий веб-приложение) расположен на ISO-образе дополнительных материалов;
- Выполните установку приложения AppDocker0;
- Пакеты для установки Docker расположены на дополнительном ISO-образе;
- Инструкция по работе с приложением расположена на дополнительном ISO-образе;
#Если файл имеет расширение просто tar, то распаковывать его не нужно! Добавляем образ с расширением tar так же, в локальный docker-репозиторий по инструкции ниже.
#Порт сервера может быть другим, 80 например. На этом моменте нужно заострить внимание, иначе веб-страница на CLI не откроется!
- Необходимо реализовать следующую инфраструктуру приложения.
- Клиентом приложения является CLI (браузер Edge);
- Хостинг приложения осуществляется на ВМ WEB-L и WEB-R;
- Доступ к приложению осуществляется по DNS-имени www.demo.wsr;
- Имя должно разрешаться во “внешние” адреса ВМ управления трафиком в обоих регионах;
- При необходимости, для доступа к к приложению допускается реализовать реверс-прокси или трансляцию портов;
#Инструкция (Readme.txt) по работе с приложением в docker-контейнере написана на русском языке. Имеющееся ПО в Debian для просмотра и редактирования текстовых файлов не распознаёт кириллицу, поэтому целесообразнее перенести или отобразить этот файл в CLI, на Windows 10. Один из способов — отобразить содержимое инструкции через веб-страницу, при доступе к WEB-L с CLI.
#По указанному пути должна быть доступна инструкция. Особое внимание на используемый порт приложением.
#Второй способ — скопировать инструкцию Readme.txt с WEB-L на CLI, через scp с использованием настроенного ранее порта 2222.
- Доступ к приложению должен быть защищен с применением технологии TLS;
- Необходимо обеспечить корректное доверие сертификату сайта, без применения “исключений” и подобных механизмов;
- Незащищенное соединение должно переводится на защищенный канал автоматически;
- Необходимо обеспечить отказоустойчивость приложения;
- Сайт должен продолжать обслуживание (с задержкой не более 25 секунд) в следующих сценариях:
- Отказ одной из ВМ Web
- Отказ одной из ВМ управления трафиком.
- Сайт должен продолжать обслуживание (с задержкой не более 25 секунд) в следующих сценариях:
#Ситуация с обеспечением «доверия» к сертификату сайта здесь особая. Можно применить минимум усилий по настройке сертификации (облегчённый вариант), но тогда этот единственный подпункт задания не будет выполнен и по нему не засчитают 0,5 баллов (лол). Или же, при проведении более сложной настройки сертификации (усложнённый вариант, нужно зубрить), задание будет выполнено в полном объёме.
#Теперь в браузере при вводе адреса https://www.demo.wsr должно осуществляться корректное отображение содержимого веб-страницы, без внесения сайта в исключения и т.п.
#При желании, можно поэкспериментировать с вызовом функций из файла Readme.txt или попробовать отключать по очереди веб-сервера (WEB-L и WEB-R) и/или маршрутизаторы (RTR-L и RTR-R). Вызовы функций должны без проблем работать, как и балансировка трафика (включается в работу другой веб-сервер взамен выключенного).
P.S. По факту, пункты задания с «обеспечением отказоустойчивости приложения» не являются выполненными. Вместо отказоустойчивости, была реализована балансировка (в файле конфигурации default, в nginx). Разница в том, что реализованный функционал балансировки предназначен для равномерного распределения клиентских подключений между WEB-L и WEB-R и не способен обеспечить стабильный доступ к веб-сайту, если отключается один из маршрутизаторов (RTR-L или RTR-R).
Время простоя, в случае отключения одного из маршрутизаторов — 35-60 секунд (больше лимита в 25 секунд по заданию).
Время простоя, в случае отключения WEB-L или WEB-R — 15-20 секунд (меньше лимита; именно так и нужно).
Реализованную балансировку на демо-экзамене вполне могут засчитать как отказоустойчивость, если квалификация проверяющих не очень высокая или если они готовы пойти на уступки. В остальном, имеется риск потерять 1,2 балла.
P.P.S. К сожалению, пока отсутствуют варианты с реализацией именно отказоустойчивости и именно в рамках задания.