В примере на данной странице представлено развертывание Oxidized с целью автоматизированного сбора конфигураций с коммутаторов BDCOM. Для сбора с оборудования других производителей действия аналогичные с поправкой на их специфику подключения и получения конфигураций конкретных моделей.

 Oxidized – это система автоматического резервного копирования конфигураций сетевого оборудования. Она подключается к маршрутизаторам, коммутаторам и другим устройствам, получает их текущие конфигурации и сохраняет версии файлов в Git-репозитории.

Страница проекта на github.com.

В данной инструкции для подключения к оборудованию и сбора конфигураций используется исключительно протокол SSH. Сам Oxidized кроме SSH поддерживает так же некоторые другие протоколы подключения.

 

Для развертывания Oxidized подготовлена виртуальная машина со следующими характеристиками:

CPU: 2 vCPU

RAM: 2 ГБ

Диск: 50 ГБ (система+данные)

Сеть: 1 Gbit/s

ОС: Ubuntu Server 24.04 LTS

Это характеристики для небольшой установки для бэкапа 20-30 сетевых устройств, а не универсальные параметры.

 

Размещение сервера Oxidized следует выполнять в соответствии с политиками информационной безопасности организации, руководствуясь принципом минимально необходимых сетевых доступов.

Предпочтительно размещать сервер в отдельном серверном VLAN или выделенном сегменте сети, предоставляя ему доступ к оборудованию через правила межсетевого экрана. Размещение Oxidized непосредственно в VLAN сетевого оборудования также допустимо, если это не противоречит требованиям ИБ и доступ к устройствам ограничен соответствующими ACL.

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

 

Создаем ВМ, если еще не создана. Устанавливаем операционную систему.

Раздача IP-адреса по DHCP с привязкой к MAC-адресу.

 

Настраиваем весь диск под систему и данные.

Открываем доступ в Интернет на время настроек.

Отмечаем установку SSH сервера.

Задаем понятное название, например, в данном случае название: sw-backup-server.

Создаем учетные данные пользователя и ожидаем установку.

 

Подключаемся по SSH.

Переходим в режим с правами root.

(вводим пароль)

 

Проверяем доступ в Интернет (DNS и доступ к сайтам).

 

Обновляем систему.

 

Можно проверить версию Ubuntu после обновления.

Затем отключаем автообновления и доступ в Интернет.

 

Установка Oxidized.

Устанавливаем зависимости Oxidized.

 

Можно проверить версии и готовность системы к установке.

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

 

Устанавливаем основной сборщик конфигураций Oxidized.

 

Устанавливаем веб-интерфейс и REST API.

Сам по себе основной Oxidized может работать без веб-интерфейса. oxidized-web – необязательный компонент.

 

Проверка

 

На момент установки актуальные версии были такие:

 

Создание системной учётной записи и первичная инициализация Oxidized.

Oxidized не рекомендуется запускать от имени root. Для его работы создаётся отдельная системная учётная запись oxidized. От её имени будет выполняться служба, храниться рабочая конфигурация и сохраняться резервные копии конфигураций сетевого оборудования.

Создаём пользователя.

Для примера выбрано имя: oxidized.

 

Проверка

 

Переключаемся на пользователя oxidized.

 

Выполняем первый запуск программы одноимённой командой. Это необходимо для создания начального файла конфигурации и пользовательских рабочих каталогов.

(в этом месте oxidized это команда, совпавшая с именем пользователя)

 

При первом запуске программа может сообщить, что конфигурация создана, либо завершиться с сообщением об отсутствии источника устройств.

 

Проверяем, какие файлы созданы:

Домашний каталог /home/oxidized важен не сам по себе – именно в нём Oxidized создаёт пользовательскую конфигурацию и связанные рабочие данные.

Завершаем сеанс пользователя oxidized.

Дальнейшее редактирование конфигурационного файла выполняется от имени администратора (root), поскольку далее необходимо не только изменить параметры работы программы, но и назначить соответствующие права доступа к файлу.

 

Редактирование основной конфигурации.

Делаем резервную копию конфигурации, чтоб было к чему вернуться.

 

Редактируем содержимое файла конфигурации.

 

Задаём параметры его работы:

-учётные данные для подключения к коммутаторам;

-модель оборудования BDCOM;

-периодичность сбора конфигураций;

-параметры подключения по SSH;

-Git-репозиторий для хранения конфигураций и истории изменений;

-источник списка оборудования (router.db);

-настройки веб-интерфейса.

 

Назначение параметров конфигурации.

Измененные параметры относительно дефолтной конфигурации подчеркнуты на скриншоте.

Назначение параметров.

username – имя пользователя для подключения к оборудованию по умолчанию.

password – пароль для подключения к оборудованию по умолчанию.

Если для устройства в router.db указаны индивидуальные учётные данные, то будут использоваться они.

Логины и пароли хранятся в открытом виде!

model: bdcom – модель оборудования по умолчанию. Если модель указана в router.db, применяется значение оттуда.

resolve_dns: false – отключает определение IP-адресов по DNS-именам устройств.

interval: 604800 – интервал опроса оборудования в секундах (604800 = 7 суток). Настраивается индивидуально под потребности в каждом конкретном случае. Можно забирать конфигурацию 1 раз в сутки если на оборудовании выполняется интенсивная работа, или 1 раз в месяц, если оборудование настроено и его больше не трогают.

debug: false – отключает режим отладки и подробное диагностическое журналирование.

run_once: false – Oxidized работает постоянно, а не выполняет только один цикл сбора конфигураций.

threads: 1 – количество одновременно работающих потоков сбора конфигураций.

use_max_threads: false – не использовать автоматически максимальное количество потоков.

timeout: 30 сек – время ожидания ответа при подключении к устройству.

timelimit: 300 сек – максимальное время выполнения сбора конфигурации одного устройства.

retries: 2 – количество повторных попыток при неудачном подключении или сборе конфигурации.

prompt – регулярное выражение для распознавания приглашения командной строки сетевого оборудования (окончание # или >).

next_adds_job: false – отключает автоматическое создание дополнительного задания при принудительном запуске опроса устройства через REST API. Для обычного периодического сбора конфигураций параметр несущественен.

vars: – начало блока дополнительных переменных, передаваемых модели оборудования.

enable: true – передавать модели BDCOM переменную enable со значением true (используется при работе с привилегированным режимом, без этого невозможно вывести конфигурацию).

groups: {} – словарь групп оборудования. В данной конфигурации группы не заданы.

group_map: {} – правила автоматического распределения устройств по группам. Не настроены.

models: {} – дополнительные индивидуальные настройки моделей оборудования. Не заданы.

pid – путь к файлу, в котором хранится идентификатор процесса Oxidized.

log – путь к файлу журнала работы Oxidized.

 

Веб-интерфейс Oxidized.

extensions – начало блока дополнительных расширений Oxidized.

oxidized—web – настройки расширения веб-интерфейса и REST API.

load: true – включает загрузку расширения Oxidized Web.

listen: 0.0.0.0 – разрешает принимать подключения на всех сетевых интерфейсах сервера. Поэтому доступ к веб-интерфейсу необходимо ограничивать правилами файервола или сетевого экрана.

port: 8888 – порт, на котором работает веб-интерфейс.

 

Подключение к сетевому оборудованию.

input – начало блока настроек получения конфигураций от оборудования.

default: ssh – использовать SSH в качестве протокола подключения по умолчанию.

debug: false – отключает отладочный режим для входных подключений.

ssh – настройки подключения по протоколу SSH.

secure: false – отключает проверку подлинности SSH-хоста по его ключу (host key verification). Шифрование SSH-соединения при этом сохраняется, однако Oxidized не проверяет, что подключается именно к ожидаемому устройству. Это упрощает первоначальную настройку, но снижает защиту от подмены SSH-сервера. Для повышения безопасности рекомендуется использовать строгую проверку SSH-ключей устройств (secure: true) с предварительным заполнением и сопровождением файла known_hosts.

timeout: 30 сек – время ожидания ответа при установлении SSH-соединения.

auth_methods: [«password»] – использовать парольную аутентификацию.

kex: []– отдельный список алгоритмов обмена ключами SSH не задан.

encryption: []– отдельный список алгоритмов шифрования SSH не задан.

host_key: []– отдельный список алгоритмов проверки ключей SSH-хоста не задан.

Параметры kex, encryption и host_key оставлены пустыми. Это означает, что мы не переопределяем списки алгоритмов SSH вручную. Фактически используемые алгоритмы определяются библиотекой SSH и её настройками.

 

Хранение конфигураций и история изменений.

output – начало блока настроек сохранения полученных конфигураций.

default: git – использовать Git для хранения конфигураций и ведения истории изменений. Это позволяет просматривать различия между версиями и при необходимости возвращаться к предыдущим.

git – настройки Git-репозитория.

user: Oxidized – имя автора изменений, которое будет отображаться в истории Git.

email: oxidized@localhost – электронный адрес автора изменений в записях Git. Это не адрес для отправки уведомлений.

repo – путь к локальному Git-репозиторию, в котором хранятся конфигурации и история их изменений.

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

 

Источник списка сетевого оборудования.

source – начало блока настроек источника списка оборудования.

default: csv – использовать CSV-файл в качестве источника списка устройств.

csv – настройки CSV-источника.

file – путь к файлу router.db, содержащему список сетевого оборудования.

delimiter: !ruby/regexp /:/ – использовать двоеточие (:) в качестве разделителя полей файла.

map – определяет соответствие столбцов файла router.db параметрам Oxidized.

name: 0 – первый столбец – имя устройства.

ip: 1 – второй столбец – IP-адрес устройства.

model: 2 – третий столбец – модель оборудования.

username: 3 – четвёртый столбец – имя пользователя для подключения.

password: 4 – пятый столбец – пароль для подключения.

Таким образом, активирована возможность задавать индивидуальные учётные данные для каждого устройства.

Например, model: 2 – индивидуальное указание оборудования в файле router.db

Цифра 2 – это порядковый номер столбца, начиная с нуля (индексы массива).

Если строка в router.db выглядит так:

то Oxidized читает её следующим образом:

Поэтому в конфигурации:

model: 2 означает: взять значение модели из третьего столбца файла router.db.

 

Сопоставление моделей оборудования

model_map: {} – дополнительная таблица соответствия названий моделей оборудования. В текущей конфигурации не используется, поскольку отдельные правила сопоставления не заданы.

 

Настройка уведомлений об ошибках сбора конфигураций. Эта часть конфигурации относится к дополнительным настройкам и скрипту авто-архивирования, который описан в конце. Эти настройки могут понадобится не всем. Кому не нужно – удалить их.

 

hooks – начало блока дополнительных действий (обработчиков событий) Oxidized.

email_node_fail: – имя обработчика, предназначенного для уведомления об ошибке сбора конфигурации устройства.

type: exec – при возникновении события выполнить внешнюю команду или скрипт.

events: [node_fail] – запускать обработчик при возникновении ошибки сбора конфигурации устройства.

cmd – путь к выполняемому скрипту отправки уведомления по электронной почте.

async: true – выполнять скрипт асинхронно, не ожидая его завершения.

timeout: 30 сек – максимальное время выполнения обработчика.

Данный блок подключает внешний скрипт отправки уведомлений. При возникновении ошибки сбора конфигурации сетевого устройства Oxidized запускает скрипт /usr/local/sbin/oxidized-mail-alert.sh, который формирует и отправляет сообщение администратору по электронной почте. Настройка самого скрипта и почтовой службы рассматривается отдельно (в конце).

 

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

 

Список устройств router.db.

Создаём список устройств.

 

Начинать следует с одного устройства.

Добавляем в файл одну строку для тестового коммутатора.

 

Пароли в router.db хранятся в открытом виде. Поэтому файл должен иметь ограниченные права доступа, а резервные копии самого файла необходимо защищать наравне с основным конфигурационным файлом Oxidized.

 

Назначаем права файла – oxidized: владелец, чтение и запись.

 

Выполняем тестовый запуск командой:

 

Проверяем результат в отдельной SSH сессии.

 

Проверяем журнал (лог):

По логу:

-Oxidized starting – приложение запущено.

-Loaded 1 nodes – загружен один коммутатор.

-Oxidized-web server listening on 127.0.0.1:8888 – веб-интерфейс запущен, но пока доступен только с самого сервера.

(настройка для доступа с любых интерфейсов уже добавлен в конфигурацию, см. выше)

-Configuration updated for /BDCOM-S2900-01 – конфигурация узла обработана и сохранена в репозитории.

Папка configs.git создана, но пока нужно проверить содержимое резервной копии.

 

Проверяем, создался ли Git-репозиторий:

 

Проверяем содержание.

Из вывода видно, что show fan-status – команда не выполняется. Возможно, другой синтаксис или вообще отсутствует в данной модели.

Проверяем по очереди команды в коммутаторе при подключении по SSH вручную (не через oxidized).

 

Команда show fan-status так же не выполняется.

 

Убираем неподдерживаемую команду. У кого в BDCOM есть вентиляторы, и такая команда выполняется – убирать её не нужно.

Открываем модель:

 

Удаляем следующий блок целиком:

Сохраняем Ctrl+X, выходим.

 

Перезапускаем Oxidized

В терминале, где запущен Oxidized от пользователя oxidized, нажимаем Ctrl+C. Затем запускаем снова.

 

Ожидаем 15-30 секунд и проверяем результат от root.

 

Проверяем что вывелось в конфигурацию при запрое из Oxidized.

В сохранённом файле виден вывод конфигурации коммутатора.

 

Проверяем вход в WEB-интерфейс через браузер из компьютера администратора.

(у каждого свой IP-адрес)

Конфигурацию коммутатора можно просмотреть в браузере.

Из недостатка замечен доступ без логина и пароля.

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

 

Служба и автозапуск при старте системы.

Останавливаем ручной запуск

В терминале, где запускали oxidized от пользователя oxidized, нажимаем Ctrl+C.

 

Проверяем, что процесс остановлен:

Не должно остаться процесса:

 

Создаём службу systemd.

Выполняем в терминале с правами root.

 

Или создаем файл вручную.

И добавляем содержание.

Сохраняем Ctrl+X, выходим.

 

Включаем автозапуск.

 

Запускаем службу.

 

Проверяем работу.

Проверяем последние записи логов.

Active: active (running) – служба работает.

enabled – будет запускаться автоматически после перезагрузки.

Загружен один узел.

Веб-интерфейс слушает 0.0.0.0:8888.

 

Заполняем файл router.db коммутаторами. Если логин и пароль отличаются, записываем их согласно формата в конце через двоеточие.
Например:

Система настроена и будет собирать конфигурации коммутаторов автоматически 1 раз в неделю.

 

Для повышения информационной безопасности на данном сервере необходимо выполнить следующие мероприятия:

Настроить доступ в сервер только с IP-адреса администратора и его дублера. (в iptables или другом используемом FW)

Отключить работу по IPv6 если не используется.

Дополнительно можно настроить работу SSH только по протоколу IPv4 (в файле /etc/ssh/sshd_config)

В каждом коммутаторе рекомендуется создавать отдельного пользователя с ограниченными правами для Oxidized.

Следует учитывать что router.db содержит учётные данные в открытом виде и не хранить файл в ненадежных местах.

Настроить оповещение о событиях на email.

 

Дополнения ниже описывают решение специфических задач и не являются обязательными в работе Oxidized.

 

ДОПОЛНЕНИЕ 1.

​

ДОПОЛНЕНИЕ 2.

​

ДОПОЛНЕНИЕ 3.

​

ДОПОЛНЕНИЕ 4.

​