Oxidized: резервные копии конфигураций сетевых устройств

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

Проверка конфигураций по эталону (скрипт, правила, отчёт) описана в статье сканирование конфигураций. Изменение любой конфигурации должно идти по процессу: управление изменениями. Безопасная настройка самих устройств: hardening коммутатора и маршрутизатора.

Как это устроено

Резервная копия, версия и проверка конфигурации живут в одном контуре.

Oxidized по расписанию заходит на каждое устройство по SSH, забирает конфигурацию, сохраняет её в Git и сравнивает с предыдущей версией. Любое изменение видно как коммит: что, когда, а при настроенном хуке ещё и оповещение. Раз в день или после изменения запускается проверка правил, которая отвечает на вопрос: соответствует ли конфигурация эталону.

Шаг 1. Учётная запись для копирования

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

Шаг 2. Установка в Docker

sudo mkdir -p /srv/oxidized/config /srv/oxidized/data
sudo chown -R 30000:30000 /srv/oxidized          # пользователь внутри контейнера, смотрите документацию образа

docker run -d --name oxidized --restart unless-stopped \
  -v /srv/oxidized/config:/home/oxidized/.config/oxidized \
  -p 127.0.0.1:8888:8888 \
  oxidized/oxidized:latest

Ожидаемо: контейнер запускается; в каталоге /srv/oxidized/config появляется файл конфигурации по умолчанию. Для боевой установки закрепите версию образа вместо latest. Интерфейс слушает только 127.0.0.1: он показывает конфигурации устройств, и выставлять его в сеть без пароля нельзя; для доступа администраторов используйте обратный прокси с аутентификацией или SSH-туннель.

Шаг 3. Настройка и список устройств

Основной файл /srv/oxidized/config/config:

---
username: oxidized
interval: 3600
threads: 10
timeout: 20
retries: 2
rest: 0.0.0.0:8888
input:
  default: ssh
  ssh:
    secure: true
output:
  default: git
  git:
    user: Oxidized
    email: oxidized@example.com
    repo: /home/oxidized/.config/oxidized/configs.git
source:
  default: csv
  csv:
    file: /home/oxidized/.config/oxidized/router.db
    delimiter: !ruby/regexp /:/
    map:
      name: 0
      ip: 1
      model: 2
hooks:
  notify_change:
    type: exec
    events: [post_store]
    cmd: '/home/oxidized/.config/oxidized/notify.sh'
    async: true
    timeout: 60

Список устройств в router.db: имя, адрес, тип устройства (модель указывает, как разговаривать с этим оборудованием):

sw-core-01:192.0.2.21:ios
sw-access-02:192.0.2.22:routeros
fw-edge:192.0.2.1:fortios

Список моделей и их названия смотрите в документации Oxidized. Закрытый ключ учётной записи положите в каталог настроек и укажите в конфигурации; не храните пароль открытым текстом, если устройства поддерживают вход по ключу. После запуска проверьте:

docker logs --tail 20 oxidized
curl -s http://127.0.0.1:8888/nodes.json | jq -r '.[] | "\(.name) \(.last.status)"'

Ожидаемо: у каждого устройства статус success. Статус no_connection означает недоступность или ошибку входа, no_access отказ в правах. Адрес сервера Oxidized должен быть разрешён на устройствах в списке доступа управления: сегмент администрирования. Сервер копирования сам должен находиться в сегменте управления.

Шаг 4. Видеть и разбирать изменения

Каждое изменение конфигурации появляется в Git отдельным коммитом. Посмотреть историю одного устройства и что изменилось:

cd /srv/oxidized/config/configs.git
git --git-dir=. log --oneline -n 10 -- sw-core-01
git --git-dir=. diff HEAD~1 HEAD -- sw-core-01

Ожидаемо: список коммитов и разница между двумя последними версиями. Пример, как выглядит значимое изменение: в диффе появляется строка с разрешением доступа или новый локальный пользователь. Для оповещений достаточно простого скрипта, который запускается после каждого сохранения (хук из конфигурации). Oxidized передаёт ему имя устройства в переменной окружения:

#!/usr/bin/env bash
# notify.sh: сообщение о смене конфигурации
echo "Изменена конфигурация устройства $OX_NODE_NAME (событие $OX_EVENT)" | mail -s "Конфигурация: $OX_NODE_NAME" secops@example.com

Каждое оповещение сверяют с реестром изменений: есть заявка на это изменение или нет. Изменение без заявки — повод для разговора и, возможно, для инцидента: реестр изменений и откат. Если оповещения отключить, вы теряете главное преимущество: быструю реакцию на несанкционированную правку.

Шаг 5. Охват: все ли устройства подключены

Оценка зрелости смотрит на долю устройств, подключённых к системе управления конфигурациями: она должна быть не меньше 90%. Устройство, которого нет в списке, не копируется и не контролируется, а новое оборудование появляется постоянно. Сверка с реестром активов делается скриптом:

#!/usr/bin/env bash
# Охват копирования: устройства из реестра, по которым последняя выгрузка успешна
# registry.txt: имена сетевых устройств из реестра активов, по одному в строке
ok=$(curl -s http://127.0.0.1:8888/nodes.json | jq -r '.[] | select(.last.status=="success") | .name' | sort -u)
total=$(sort -u registry.txt | wc -l)
covered=$(comm -12 <(sort -u registry.txt) <(echo "$ok") | wc -l)
echo "Охват: $covered из $total ($((100 * covered / total))%)"
echo "Нет в Oxidized или выгрузка не удалась:"
comm -23 <(sort -u registry.txt) <(echo "$ok")

Ожидаемо: строка с процентом и список устройств, по которым нужно разбираться. Запускайте раз в неделю и сохраняйте результат: динамика охвата сама по себе доказательство. Поле .last.status зависит от версии API; проверьте вывод nodes.json и подправьте путь к полю, если он отличается. Регулярная сверка со списком устройств сети (например, по сканированию) — часть процесса: реестр ИТ-активов.

Шаг 6. Проверка конфигураций по правилам

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

Какие артефакты хранить

Что хранить	Что показывает
Описание системы управления конфигурациями: схема, настройки, порядок восстановления	Централизованное решение есть и описано
Выгрузка списка подключённых устройств (`router.db`, вывод `nodes.json`)	Какие устройства охвачены
Результат расчёта охвата за последние месяцы	Охват не ниже 90% и регулярно проверяется
Примеры изменений конфигурации: коммит, заявка, оповещение	Версии хранятся, изменения контролируются

Диагностика

Симптом	Причина и что делать
Статус `no_connection`	Устройство недоступно с адреса сервера или закрыт SSH. Проверьте список доступа управления и сеть
Статус `no_access` или ошибки входа	Нет прав у учётной записи или изменился пароль. Проверьте ключ и роль на устройстве
Конфигурация приходит обрезанной	Не подходит модель или постраничный вывод. Проверьте модель в `router.db` и настройки терминала
В каждом коммите изменяется одна и та же строка	Динамические значения (время, счётчики). Исключите их фильтром модели или отключите вывод на устройстве
Новое устройство не попало в систему	Нет связи между реестром и списком Oxidized. Включите сверку в процесс ввода оборудования

Где это в модели зрелости

Материал относится к направлению «Сетевая безопасность» (хаб: сетевая безопасность, карта: карта зрелости). На третьем уровне используется система централизованного управления конфигурациями сетевых устройств с резервным копированием, контролем версий и мониторингом, подключено не менее 90% устройств, а актуальность подключения регулярно проверяется. Oxidized с Git, оповещениями и скриптом охвата закрывает эти пункты.

Как проверить

У каждого устройства из тестовой выборки есть выгрузка не старше суток и история в Git.
Тестовое изменение на устройстве вызывает коммит и оповещение.
Скрипт охвата выдаёт значение не меньше 90% и список отсутствующих.
Учётная запись копирования имеет только права чтения и ограничена по адресу.
Доступ к репозиторию конфигураций ограничен и журналируется.

Источники

Oxidized, документация и список моделей: github.com/ytti/oxidized.
CIS Control 4, безопасная конфигурация корпоративных активов и ПО: cisecurity.org/controls.
NIST SP 800-128, управление конфигурациями информационных систем: csrc.nist.gov.