Backup Hw100/1000/2000 Не Блокнотиком

[Zev]

Приветствую, коллеги.

Столкнулся с проблемой - нужно периодически делать backup конфига iplir config, iplir config IFs, iplir config firewall. Узлов на данный момент 25, но сеть растет медленно, но неустанно. Т.е. уже сейчас нужно собирать параметры настроек со 150 источников...

К сожалению (?), с данным вендором работаю не очень давно и поэтому знаю далеко не все его фишки и плюшки.

Погуглив нашел способ типа: "зайди по ssh на устройство, открой файл, выдели текст, вставь его в блокнот на сервере-зранилище, сохрани..." Какой то грустный способ бекапирования сетевого оборудования... Наверно я просто плохо искал, т.к. уверен, что у столь серьезного производителя нет нормального способа делать бекапы настроек своих координаторов.

Через SCP (с сервера, где стоит Администратор) не могу скачать файлы...

Единственное, что приходит в голову - эксептовый скрипт на баше, но туда надо пароли все вкладывать... Да и непонятно где еще эту линуксовую тачку брать...

Коллеги, может кто уже решил подобную проблему как-то? Поделитесь, пожалуйста...

[slavanchuk]

admin export keys binary-encrypted <tftp | usb> – экспорт ключей, справочников и настроек служб ViPNet на другой компьютер (по TFTP) или на USB-флэш.

[Zev]

Но я прошу прощения. Мне не нужен экспорт ключей...

Если у меня погорит железка - все равно придется ключевую информацию изменять. Это не проблема. А вот конфиги фильтрации, туннелирования, особенно если в туннеле НАТ настроен, это так сходу не восстановить...

Поэтому и хочу ее бэкапить.

[slavanchuk]

В состав экспортируемой информации входят следующие данные:

файлы, содержащие ключи шифрования для связанных с ПАК узлов (ключевые

базы);

файлы, содержащие информацию о связанных с ПАК узлах (справочники);

настройки защищенной сети (файл iplir.conf);

настройки сетевых интерфейсов (IP-адрес, маска подсети, файл iplir.conf-

<интерфейс>);

маршрут по умолчанию и статические маршруты (системная таблица

маршрутизации);

настройки временной зоны;

правила обработки открытых IP-пакетов (файл firewall.conf);

настройки системы защиты от сбоев;

настройки транспортного модуля (файл mftp.conf);

настройки протоколирования;

настройки дополнительных сервисов (DHCP-сервера, DNS-сервера, NTP-сервера);

настройки взаимодействия с UPS;

текущие ключи для соединений по протоколу SSH2;

журнал регистрации IP-пакетов;

журнал транспортных конвертов MFTP;

очередь почтовых конвертов (для ПАК, поддерживающих функцию Сервера-

маршрутизатора).

[Zev]

Спасибо за развернутый ответ!

А нельзя указать ПАКу выполнять эту команду по расписанию. Ведь можно перейти в ядро. Нет так чего-то наподобие cron'а?

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

[slavanchuk]

Да, это команды режима администратора. По поводу крона не подскажу - пока что задачи такой на HW не было. Единственное, что неприятно - для экспорта нужно остановить демоны iplir и тому подобное (насколько я помню).

[Zev]

slavanchuk, спасибо за ответ. если ничего не нарою - то, видимо придется делать экзек скрипт по Вашему предложению...

Хотя это я на сервак, где со скриптом должен выложить все пароли от железок, да еще и пароль администратора... Мне такое решение не нравится.

Может коллеги знают еще какой-то, более безопасный?... Или есть продукт, собирающий бэкапы с випнетов?...

[Kurtasanov]

Вообще по уму данный функционал следует интегрировать в ПО StateWatcher. А то вроде стоит как паравоз, а делает с гулькин нос.

[slavanchuk]

Ну, в StateWatchere ему не место. Лучше стоит в PolicyManager полноценное управления настройками (хотя бы, основными) сделать. Но там этого не планируется тоже.

[Zev]

Коллеги, т.е. получается, что по уму от вендора решения бекапирования нет?

А как решают данную проблему профессионалы? Ручками на девайс ходят или пароли на тачке со скриптами хранят? Поделитесь секретом, пожалуйста.

[slavanchuk]

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

[Zev]

Не согласен с Вами. Пусть при обновлении прошивки конфиг прямо залить нельзя. Но по конфтигу можно легко понять как устройство работало - какой порт как настроен (можно и по иной информации восстановить - схемы, соседнее оборудование), таблица маршрутизации (восстановить сложнее, но тоже возможно), таблица натирования (вот здесь уже будут большие проблемы, если ранее не велись и не актуализировались таблицы соответствия). И правила фильтрации. Вот здесь как раз и есть засада. Как в короткие сроки восстановить матрицу фильтрации? Бог с ними с ключами. Ну умрет железка. Да фиг с ней. Перенастроим и ключи новые сделаем. А вот как и с кем через ВПН она дружила (ведь не у всех трафик через тунель фильтруется по умолчанию - permit ip any any). Вот и придется дампить трафик, слушать недовольство клиентов и т.д. и т.п. При этом в ВПНе тоже мог быть НАТ...

К тому же при стоимости в 60 т.р. меленькой HW100x кто будет поднимать кластера?

Вот и встает вопрос бекапирования. Но для винды (там у меня живет Администратор) я не умею писать скрипты. Линуксовой тачки в сети у меня пока нет. А если и будет, то для нее нужно покупать випнет клиент, чтобы она могла видеть остальные устройства. И это костыль. Вот я и пытаюсь добиться (но я уже и сам понял ответ на свой вопрос) ответа - Есть ли рекомендуемое/официальное/хотя бы рабочее средство, которым профессионалы снимают конфиги. Еще раз подчеркиваю. Конфиги. Мне не нужны ключи.

Пусть оно будет стоить денег, но випнет клиент тоже платный...

[slavanchuk]

Как Вы догадались, готового решения под Вашу задачу нет. Если не брать фэйловер, то резервные копии определённо делать нужно. И именно тех настроек, которые не входят в справочники и ключи (что хранится в ЦУС). Получается, в Вашем случае проще делать периодический бэкап ручками. А документирование правил экранирования - это правила хорошего тона.

[Zev]

Эх... Раньше меня брала печаль, что мы не делаем свое (Российское) сетевое оборудование (на момент печали, я не был знаком с нашим оборудованием).

Теперь я знаком с "нашим" сетевым оборудованием...

[slavanchuk]

Ну, как сказать. Я поработал с сетевым оборудованием cisco. Есть свои плюсы и минусы.Но не увидел там автоматического бэкапа по сети. Конечно, возможностей у cisco на порядок больше, но и Инфотекс им не так давно стал заниматься. Кстати, уязвимостей у cisco хватает (известных на сегодняшний день).

[Zev]

Я тоже поработал с оборудованием Cisco. Некоторые линейки могут сбрасывать конфиг сами при сохранении. Некоторые сами по расписанию. Самые простые позволяют зайти на себя и сбросить файл на удаленный сервер. Скриптами это делается на раз-два. Не встретил ни одной железки у cisco, с которой у меня возникли бы проблемы при бекапировании. Другие производители - райском, хуавей, элайд телесин, джунипер, эстера, стоунсофт, вочгард - проблем с резервированием конфигов нет. Может и есть еще подобное випнету оборудование, но я такого не встречал. Поэтому и не верил до последнего, что тут все так печально и производителю совершенно безразличны комфорт и удобство людей, отвечающих за работоспособность этого железа. Можно было бы в випнет клиент, что на машине с випнет администратором стоит и бекапилку добавить. Не надорвались бы.

[Zev]

Да и я не говорю, что циска - умница, а випнет нет. Хотя и намекаю :-) Я говорю о том, что циска заинтересована в развитии (хотя, как вы верно сказали, АСА с софтом 8.1 и АСА с софтом 8.4 - две разные АСЫ и положительных эмоций лично мне это не дало), а випнет держится только на своей сертификации. Насколько я понимаю - банальное тегирование появилось не так давно. А это, извините, must have. Имхо. Вот стоунсофт получит сертификаты ФСБ и посмотрим, что с випнетом будет.

[slavanchuk]

Кстати, в качестве межсетевого экрана/IPS мы планируем использовать именно продукт StoneSoft, так как они планируют сертифицировать свой механизм IPS. И, кстати, StoneSoft в некоторых отношениях привлекательнее даже Cisco. А как криптосредство - не знаю. Сертификаты ФСБ получают СКЗИ, реализующие ГОСТ. Разве StoneSoft это планирует? А с переходом на новую прошивку cisco asa совсем недавно мучился. Отвратительно, но в новом варианте натирования есть свои плюсы.

[Zev]

StoneSoft FW и IPS имеют сертификаты ФСТЭК. В ФСБ сертификаты они пока не получили. Уже давно обещают, но пока так и не сделали.

Про ГОСТ и СКЗИ не понял Вас. Я ни разу не сталкивался с StoneSoft FW, работающим не с ГОСТовыми крипто библиотеками. У нас ведь в России запрещена западная криптография. Разве нет? Собственно по этому и не сталкивался.

Я тоже недавно мучился с новой прошивкой АСЫ. Мне тоже совсем не понравилось. Я как раз мучался с натированием. Но плюсов в этом новом варианте я не заметил.

[slavanchuk]

Сертификаты по новым требованиям к IPS они ещё не получили, но обещают, что к концу года будут. А по поводу StoneSoft действительно в реестре ФСБ есть StoneGate SSL VPN, сертифицированный в прошлом году по КС2. Значит, там ГОСТовая криптография.

А в новом натировании более тонкие настройки. Непривычно, но вполне работать можно. Как раз, мучения были, когда заводили две ASA 5510 в кластер, а на старой была прошивка 8.04. Решили версию не понижать и перейти на новую - только разгребли этот завал. А как она отконвертировала автоматически правила - вообще лучше не вспоминать .

[intellegent]

Коллеги. постараюсь ответить на Ваши вопросы.

Да, сохранения настроек в том виде, как Вы хотите нет. Пока нет.

НУ а насчет удобства управления оборудованием западных вендоров вот что хочу сказать - переведите это оборудование в режим соответствия FIPS и почувствуйте разницу. Наш продукт все время работает в режиме соответствия требованиям регуляторов, т.е. соответствия требованиям аналогичным FIPS.

Для наглядности приведу цитату из документации на PaloAlto

Reference Guide.

When FIPS is enabled, the following apply:

• To log into the firewall, the browser must be TLS 1.0 compatible.

• All passwords on the firewall must be at least six characters.

• Accounts are locked after the number of failed attempts that is configured on the

Device > Setup > Management page. If the firewall is not in FIPS mode, it can be

configured so that it never locks out; however in FIPS mode, and lockout time is required.

• The firewall automatically determines the appropriate level of self-testing and enforces

the appropriate level of strength in encryption algorithms and cipher suites.

• Non-FIPS approved algorithms are not decrypted and are thus ignored during SSL

decryption.

• When configuring IPSec, a subset of the normally available cipher suites is available.

• Self-generated and imported certificates must contain public keys that are 2048 bits (or

more).

• The serial port is disabled.

• Telnet, TFTP, and HTTP management connections are unavailable.

• Surf control is not supported.

• High availability encryption is required.

• PAP authentication is disabled.

• Log forwarding is not supported

[slavanchuk]

То есть, после перехода на FIPS удобства будет меньше, безопасности больше, судя по Вашим пунктам.

[intellegent]

Да. Только это не по моим пунктам, а пунктам PaloAlto

В США рынок коммерческой тайны не регулируется государством, соответственно производители идут на поводу у потребителей и удовлетворяют все их желания. Например, хочу по открытому каналу настроить на удаленном маршрутизаторе IPSec и задать через этот же открытый канал preshared-key. Все можно, а будет ли после этого VPN канал защищенным никого не волнует.

[ksardex]

admin export keys binary-encrypted <tftp | usb> – экспорт ключей, справочников и настроек служб ViPNet на другой компьютер (по TFTP) или на USB-флэш.

а как импортировать обратно?)

[slavanchuk]

а как импортировать обратно?)

1. Останавливаете демоны HW1000 (failover,mftp,iplir).
   
   
2. выполняем admin remove keys, чтобы удалить текущую конфигурацию.
   
   
3. при следующей авторизации запустится мастер первичной инициализации.
   

Мастер первичной инициализации работает как с дистрибутивом, так и с экспортом. Сам пока не пробовал - это в теории. Вроде бы, ещё должна быть команда для запуска мастера. И, вроде бы, есть ещё команда vipnet stop для остановки всех демонов сразу (но про неё написано только в документации на linux координатор).