През есента на 2019 година Check Point спря поддръжката на версиите R77.XX и трябваше да направим обновление. Много е казано за различията между версиите, предимствата и недостатъците на преминаването към R80. Нека да поговорим по-добре за това как на практика да обновим виртуалните устройства на Check Point (CloudGuard за VMware ESXi, Hyper-V, KVM Gateway NGTP) и какво може да се обърка.
И така, имахме 2 инженери CCSE, над десет виртуални клъстера Check Point R77.30, няколко облака, малко хотфиксове и цял океан от разнообразни бъгове, проблеми и всичко такова, във всички цветове и размери, а също така и много кратки срокове. Започваме!
Съдържание:
Така изглежда типичната облачна инфраструктура на клиента с виртуален Check Point
Подготовка
Първо трябва да проверим дали разполагаме с достатъчни ресурси за обновление. Препоръчителните минимални изисквания за R80.20 в момента изглеждат така:
Device
CPU
RAM
HDD
Security Gateway
2 ядра
4 Гб
От 15 GB
SMS
2 ядра
6 Гб
—
Препоръките са описани в документа .
Но да бъдем реалисти. Ако в най-малката конфигурация това е достатъчно, то както показва практиката, обикновено имаме активирана HTTPS инспекция, на SMS работи SmartEvent и т.н., което освен всичко друго изисква съвсем различни мощности. Но по принцип не по-големи от тези за R77.30.
Но има нюанси. И те се отнасят основно до размера на физическата памет. Много операции непосредствено по време на обновлението ще изискват пространство на твърдия диск.
За сървъра за управление размерът на свободното пространство на диска ще зависи много от обема на текущите логове (ако желаем да ги запазим) и от количеството съхранени ревизии на базата данни, въпреки че те не ни трябват в голямо количество. Разбира се, за нодовете на клъстера (освен ако не съхранявате логовете и локално) това всъщност няма значение. Ето как можем да проверим наличието на необходимо пространство:
- Свързваме се със Smart Management Server по ssh, влизаме в expert mode и въвеждаме командата:
[Expert@cp-sms:0]# df -h
- На изхода ще видим приблизително такава конфигурация:
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_splat-lv_current 30G 7.4G 21G 27% /
/dev/sda1 289M 24M 251M 9% /boot
В момента ни интересува разделът
/dev/mapper/vg_splat-lv_log 243G 177G 53G 78% /var/log - В момента ни интересува разделът /var/log
Имайте предвид, че в зависимост от политиката за съхранение и изтриване на стари логфайлове, както и от размера на експортираното хранилище, може да е необходимо повече пространство. Ако при създаване на архива свободното пространство стане по-малко от посоченото в политиката за съхранение на логфайлове, системата ще започне да изтрива стари логове и НЯМА да ги включи в архива.
Също така, за самия процес на актуализиране системата ще се нуждае от минимум 13 GB неразпределено място на твърдия диск. Можете да проверите наличието му с командата:
[Expert@cp-sms:0]# pvs
Ще видим приблизително такъв изход:
PV VG Fmt Attr PSize PFree
/dev/sda3 vg_splat lvm2 a- 141.69G 43.69G
В този случай имаме 43 GB. Ресурсите са достатъчни. Можем да преминем към актуализиране.
Актуализираме сървъра за управление на Check Point SMS
Преди да започнем работа, е необходимо да направим следното:
- Инсталираме пакета Migration Tools на сървъра за управление. За целта е необходимо да изтеглите образа от портала..
- Качваме архива на сървъра за управление чрез WinSCP в папката /var/log/UpgradeR77.30_R80.20 (ако е необходимо, предварително да създадете папка).
- Свързваме се със сървъра за управление чрез SSH и отиваме в папката с архива:cd /var/log/UpgradeR77.30_R80.20/
- Разархивираме файла:tar -zxvf ./.tgz
- Стартираме утилитата pre_upgrade_verifier с командата: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- След изпълнението на командата ще бъде генериран отчет за несъвместимите настройки. Той е достъпен на адреса: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). По-удобно е да го изтеглите чрез SCP и да го прегледате чрез браузър.
За отстраняване на всички несъвместими настройки използвайте. - След това повторно стартирайте утилитата pre_upgrade_verifier, за да се уверите, че всички причини за несъвместимостта са отстранени.
- Следва да съберем информация за мрежовите интерфейси, таблицата за маршрутизация и да изтеглим конфигурацията на GAIA:
ip a > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
ip r > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
clish -c "show configuration" > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt - Изтегляме получения файл чрез SCP.
- Правим snapshot на ниво виртуализация.
- Увеличаваме времето за изчакване на SSH сесията до 8 часа. Тук е на късмет: в зависимост от размерите на експортираното хранилище, това може да отнеме от няколко минути до няколко часа. За целта:
[Expert@HostName]# clish -c "show inactivity-timeout" проверяваме текущото време за изчакване на clish,[Expert@HostName]# clish -c "set inactivity-timeout 720" уточняваме новото време за изчакване на clish (в минути),
[Expert@HostName]# echo $TMOUT проверяваме текущото време за изчакване в expert mode,
[Expert@HostName]# export TMOUT=3600 уточняваме новото време за изчакване в expert mode (в секунди); ако зададете стойност 0, времето за изчакване ще бъде изключено.
- Зареждаме и монтираме инсталационния образ SMS.iso към виртуалната машина.
Преди следващата стъпка ЗАДЪЛжИТЕЛНО отново проверете, че имате достатъчно неизползвано пространство на твърдия диск (напомням, необходимо е 13 GB).
- Преди да започнем експорта на конфигурацията, променяме лог файла с командата: fw logswitch
Експорт на конфигурация и логове
- Стартираме утилитата migrate_export за извеждане на конфигурацията. За целта влизаме в предварително създадената папка: cd /var/log/UpgradeR77.30_R80.20/ и използваме командата: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
или
влизаме в папката: cd $FWDIR/bin/upgrade_tools/ и
стартираме оттам командата: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz - Взимаме checksum от архива: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Записваме получената стойност в бележник.
- Свързваме се към SMS през SCP и извеждаме архива с конфигурацията на работната станция. Задължително ползвайте пренос на файлове в Binary формат.
Експорт на базата SmartEvent
Тук ще ни е необходим предварително инсталиран SMS версия R80. Всеки тестов вариант е подходящ.
- От SMS ни трябва скриптът, разположен тук:$RTDIR/bin/eva_db_backup.csh
- През SCP качваме скрипта eva_db_backup.csh в папката: /var/log/UpgradeR77.30_R80.20/
- Свързваме се по SSH към SMS. Копираме файла в папката: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh - Променяме кодировката: dos2unix $RTDIR/bin/eva_db_backup.csh
- Добавяме собственик: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
- Добавяме права: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Стартираме експорта на базата SmartEvent: $RTDIR/bin/eva_db_backup.csh
- Извеждаме получените файлове през SCP: $RTDIR/bin/-db-backup.backup и $RTDIR/bin/eventiaUpgrade.tar на работната станция.
Актуализация
- Преминаваме към WebUI GAIA SMS → CPUSE → Показване на всички пакети.
- В случай, че CPUSE показва грешка при свързването с облака Check Point, проверяваме DGW, DNS и настройките на Proxy.
- Ако всичко е вярно, а грешката не изчезва, то трябва да обновим CPUSE ръчно, ръководейки се по.
- Изтегляме образа и преминаваме Verifier. При необходимост отстраняваме несъответствия.
В резултат трябва да видим следното съобщение:
- Избираме R80.20 Fresh Install and Upgrade for Security Management.
- При инсталирането на обновлението избираме Clean Install. След инсталацията системата ще се рестартира.
- Преминаваме през First Time Wizard.
- След получаване на достъп проверяваме акаунтите.
- Свързваме се към SMS по SSH и променяме shell на нашия потребител на /bin/bash/:
set user shell /bin/bash/
save config (в случай, че искаме да оставим bin/bash/ като shell по подразбиране и след рестартиране).
- След това свързваме се към SMS през SCP и в режим Binary прехвърляме архива с конфигурацията SMS_w_logs_export_r77_r80.tgz в папка /var/log/UpgradeR77.30_R80.20/
- Взимаме checksum от архива: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz и сравняваме с предишната стойност. Checksum трябва да съвпадат.
- Увеличаваме timeout за SSH сесия до 8 часа. За целта:
[Expert@HostName]# clish -c "show inactivity-timeout" проверяваме текущото време за изчакване на clish,
[Expert@HostName]# clish -c "set inactivity-timeout 720" уточняваме новото време за изчакване на clish (в минути),
[Expert@HostName]# echo $TMOUT проверяваме текущото време за изчакване в expert mode,
[Expert@HostName]# export TMOUT=3600 посочваме нов timeout в expert mode (в секунди). Ако зададете стойност 0, timeout ще бъде изключен.
- За импортиране на настройки стартираме утилитата migrate import. За целта отиваме в папката: cd $FWDIR/bin/upgrade_tools/и стартираме импорта: ./migrate imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Наслаждавайте се на живота в следващите няколко часа. НЕ ИЗКЛЮЧВАЙТЕ SSH-СЕСИЯТА по време на процедурата. В края процесът migrate ще издаде или съобщение за успешно завършване на операцията, или грешка.
Чек-лист проверки след обновление
- Достъпност на ресурсите.
- SIC с GW.
- Лицензи. Ако лицензиите се показват неправилно или не се показват на SMS, стартирайте командата vsec_central_licence за разпределение на лицензиите.
- Настройка на политиката.
Импорт на базата SmartEvent
- Активирайте блейда SmartEvent.
- Свързваме се чрез WinSCP с SMS и в режим binary предаваме преди това изнесените файлове -db-backup.backup и eventiaUpgrade.tar в папка /var/log/UpgradeR77.30_R80.20/
- Стартираме скрипта с командата: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
- Проверяваме статуса: watch -n 10 eventiaUpgrade.sh
- Проверяваме логовете в SmartEvent. СЪН!
Обновяваме клъстера Check Point GW (Active/Backup)
Преди да започнем работа
- Запазваме конфигурацията GAIA от всяка нода на клъстера в файл, за това използвайте командата: clish -c "show configuration" > ./.txt
- Експортируеме файлове с помощта на WinSCP.
- Свързваме се с WebUI на двете ноди и отиваме на раздела CPUSE → Show all packages.
- Намираме обновителния пакет за версия R80.20 Fresh Install, натискаме Изтеглете.
- Проверяваме дали CCP протоколът работи в режим Broadcast, за целта вводим командата: cphaprob -a if
Ако е избран режим Multicast, сменете го с командата: cphaconf set_ccp broadcast (командата се изпълнява на всяка нода). - Настройваме Downtime за активните ноди в системата за мониторинг.
- Проверяваме, че на ниво виртуализация са включени параметрите MAC Address Change и Forged Transmits за sync мрежата.
Актуализация
- Свързваме се чрез ssh с Active нода и стартираме командата за мониторинг на състоянието на клъстера: watch -n 2 cphaprob stat
- Връщаме се в WebUI на Standby нода на раздела CPUSE и за избрания пакет R80.20 Fresh Install стартируеме Verifier.
- Анализираме отчета Verifier. Ако инсталацията е разрешена, продължаваме.
- Избираме пакета R80.20 Fresh Install и стартираме Upgrade. По време на Upgrade системата ще бъде рестартирана. Настройките на GAIA се запазват. При рестартиране проследяваме състоянието на клъстера. След зареждане статусът на обновената нода трябва да се смени на READY. В някои случаи имаше моменти, когато още не обновената нода преминаваше в статус Active Attention и спираше да показва статуса на обновената нода. Не се притеснявайте – такъв вариант също е допустим.
- След приключване на обновлението отваряме SmartDashboard.
- Отваряме клъстерния обект и променяме версията на клъстера от R77.30 на R80.20. Натискаме Ок. Ако при запазване на промените се появи грешка:
An internal error has occurred. (Code: 0x8003001D, Could not access file for write operation),
следвайте. След това запазваме промените и натискаме Install Policy. - В настройките сме махнали отметката от параметъра For gateway clusters, if installation on a cluster member fails, do not install on that cluster.
- Инсталираме политиката. Системата ще даде грешка за Active-нода, която все още не е обновена.
- Свързваме се с обновената нода по ssh и стартираме командата за мониторинг на състоянието на клъстера: watch -n 2 cphaprob stat
- Свързваме се с WebUI на Active-нода и преминаваме на раздела CPUSE → Show all packages.Намираме обновителния пакет за версия R80.20 Fresh Install, натискаме Изтеглете.
- Настройваме Downtime за активните ноди в системата за мониторинг.
- Връщаме се в WebUI на Active-нода на раздела CPUSE и за избрания пакет R80.20 Fresh Install стартируеме Verifier.
- Анализираме отчета Verifier. Ако инсталацията е разрешена, продължаваме.
- Избираме пакета R80.20 Fresh Install и стартираме Upgrade. По време на Upgrade системата ще бъде рестартирана. Настройките на GAIA се запазват. При рестартиране проследяваме състоянието на клъстера на вече обновената нода. След рестартиране състоянието на клъстера на обновената нода ще се промени от READY на ACTIVE.
- Когато приключи процесът на Upgrade, стартираме SmartDashboard и установяваме политиката.
Чек-лист проверки след обновление
- Журналите на събитията в SmartLog, състоянието на VPN тунелите.
- Настройките на GAIA.
- Възстановяване на клъстера след тестов Failover.
- Лицензии и договори. В случай, че лицензите се показват неправилно или не се показват на SMS, стартираме командата. vsec_central_licence за разпределение на лицензите.
- CoreXL.
- SecureXL.
- Hotfix и CPinfo на две ноди.
Заключение
Всъщност на този етап всичко е – обновихте се.
Процесът ни отнемаше средно от 6 до 12 часа, в зависимост от размерите на експортируемите бази. Работихме две вечери: едната – за обновление на SMS, втората – за клъстера.
Не беше имало престои на трафика, въпреки че проверихме всички по-горе споменати грешки.
Разбира се, понякога могат да възникнат и съвсем нови трудности в процеса на обновление, но това е Check Point и, както всички знаем, винаги има hotfix!
Успешни черно-розови нощи и обновления!
Източник: habr.com
