Актуализиране на Check Point от R77.30 на 80.20

Актуализиране на Check Point от R77.30 на 80.20

През есента на 2019 година Check Point прекрати поддръжката на версиите R77.XX, и беше необходимо да се обновим. За разликите между версиите, плюсовете и минусите на преминаването към R80 вече е казано много. Нека по-добре да говорим за това как всъщност да обновим виртуалните appliance на Check Point (CloudGuard за VMware ESXi, Hyper-V, KVM Gateway NGTP) и какво може да се обърка.

И така, имахме 2 инженери CCSE, повече от десет виртуални клъстери Check Point R77.30, няколко облака, малко хотфиксове и цяла море от разнообразни бъгове, глюкове и т.н., на всякакви цветове и размери, а също и много стегнати срокове. Да започваме!

Съдържание:

Подготовка
Обновяване на управленския сървър
Обновяване на клъстера

Актуализиране на Check Point от R77.30 на 80.20

Така изглежда типичната облачна инфраструктура на клиента с виртуален Check Point

Подготовка

На първо място, трябва да проверим дали имаме достатъчно ресурси за обновяване. Препоръчителните минимални изисквания за R80.20 в момента изглеждат така:

Устройство

CPU

RAM

HDD

Security Gateway

2 ядра

4 Gb

От 15 GB

SMS

2 ядра

6 Gb

Препоръките са описани в документа CP_R80.20_GA_Release_Notes.

Но нека бъдем реалисти. Ако в самата минимална конфигурация това е достатъчно, то, както показва практиката, обикновено имаме включена https инспекция, SmartEvent работи на SMS и т.н., което, разбира се, изисква съвсем различни мощности. Но в общи линии, те не са много по-различни от тези за R77.30.

Но има нюанси. И те се отнасят, на първо място, до размерите на физическата памет. Много операции във самия процес на обновлението ще изискват място на твърдия диск.

За управленския сървър размерът на свободното пространство на диска ще зависи много от обема на текущите логове (ако искаме да ги запазим) и от количеството на запазените версии на базата данни, въпреки че те не са ни в голямо количество нужни вече. Разбира се, за нодовете на клъстера (освен ако не съхранявате логовете и локално) всичко това няма значение. Ето как можем да проверим наличието на необходимо място:

  1. Свързваме се с Smart Management Server по ssh, влизаме в expert mode и въвеждаме командата:

    [Expert@cp-sms:0]# df -h

  2. На изхода ще видим приблизително такава конфигурация:

    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
    tmpfs             2.0G 0  2.0G   0% \/dev\/shm
    /dev/mapper/vg_splat-lv_log           243G  177G 53G  78% /var/log

  3. В момента ни интересува дялът /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

Преди да започнем работа, трябва да направим следното:

  1. Инсталираме пакета Migration Tools на управляващия сървър. За целта е необходимо да изтеглим образа от портала. Check Point.
  2. Качваме архива на управляващия сървър чрез WinSCP в папката /var/log/UpgradeR77.30_R80.20 (ако е необходимо, предварително създайте папка).
  3. Свързваме се с управляващия сървър чрез SSH и минаваме в папката с архива:cd /var/log/UpgradeR77.30_R80.20/
  4. Разархивираме файла:tar -zxvf ./.tgz
  5. Стартираме инструмента pre_upgrade_verifier с командата: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
  6. След изпълнението на командата ще бъде съставен отчет за несъвместимите настройки. Той е наличен на адрес: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). По-удобно е да го изтеглите чрез SCP и да го прегледате в браузър.
    За отстраняване на всички несъвместими настройки използвайте SK117237.
  7. След това отново стартирайте инструмента pre_upgrade_verifier, за да се уверите, че всички причини за несъвместимост са отстранени.
  8. Следва да съберем информация за мрежовите интерфейси, таблицата за маршрутизация и да изтеглим конфигурацията 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
  9. Изтеглете получения файл чрез SCP.
  10. Създаваме snapshot на ниво виртуализация.
  11. Увеличаваме времето за изчакване на 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, времето за изчакване ще бъде изключено.

  12. Прикрепяме и монтираме инсталационния образ SMS.iso към виртуалната машина.

    Преди следващата стъпка ЗАДЪЛЖИТЕЛНО отново проверете, че имате достатъчно неразпределено пространство на твърдия диск (напомням, че са необходими 13 GB). 

  13. Преди започване на експорта на конфигурацията променяме лог файла с командата: fw logswitch

Експорт на конфигурацията и логовете

  1. Стартираме утилитата 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

  2. Вземаме checksum от архива: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
  3. Запазваме получената стойност в текстов файл.
  4. Свързваме се с SMS през SCP и извеждаме архива с конфигурацията на работната станция. Задължително използвайте предаване на файлове в бинарен формат.

Експорт на базата SmartEvent

Тук ще ни трябва предварително инсталиран SMS версия R80. Подходящ е всякакъв тестов вариант. 

  1. От SMS ни е необходим скрипт, разположен тук:$RTDIR/bin/eva_db_backup.csh
  2. През SCP качваме скрипта eva_db_backup.csh в папката: /var/log/UpgradeR77.30_R80.20/
  3. Свързваме се по SSH с SMS. Копираме файла в папката: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
    $RTDIR/bin/eva_db_backup.csh
  4. Променяме кодировката: dos2unix $RTDIR/bin/eva_db_backup.csh
  5. Добавяме собственик: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
  6. Добавяме права: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
  7. Стартираме експорта на базата SmartEvent: $RTDIR/bin/eva_db_backup.csh
  8. Извеждаме получените файлове чрез SCP: $RTDIR/bin/-db-backup.backup и $RTDIR/bin/eventiaUpgrade.tar на работната станция.

Актуализация

  1. Преминаваме в WebUI GAIA SMS → CPUSE → Покажи всички пакети.
  2. В случай, че CPUSE дава грешка при свързването с облака Check Point, проверяваме DGW, DNS и настройки на Proxy.
  3. Ако всичко е вярно, а грешката не изчезва, трябва да обновим CPUSE ръчно, следвайки sk92449.
  4. Сваляме образа и преминаваме Verifier. При нужда отстраняваме несъответствията.

    В резултат трябва да видим следното съобщение:

    Актуализиране на Check Point от R77.30 на 80.20

  5. Избираме R80.20 Fresh Install and Upgrade for Security Management.
  6. При инсталиране на обновлението избираме Clean Install. След инсталацията системата ще се перезареди.
  7. Преминаваме през First Time Wizard.
  8. След получаване на достъп проверяваме потребителските акаунти.
  9. Свързваме се с SMS по SSH и променяме шелла на нашия потребител на /bin/bash/:

    set user shell /bin/bash/

    save config (в случай, че искаме bin/bash/ да бъде шел по подразбиране и след перезареждане).

  10. След това се свързваме с SMS през SCP и в бинарен режим предаваме архива с конфигурацията SMS_w_logs_export_r77_r80.tgz в папката /var/log/UpgradeR77.30_R80.20/
  11. Вземаме checksum от архива: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz и го сравняваме с предходната стойност. Контролната сума трябва да съвпада.
  12. Увеличаваме времето за изчакване на 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 указваме новото време за изчакване в експертен режим (в секунди). Ако зададете стойност 0, времето за изчакване ще бъде изключено.

  13. За импортиране на настройките стартираме утилитата 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 ще издаде или съобщение за успешно приключване на операцията, или грешка. 

Контролен списък за проверки след актуализация

  1. Достъпност на ресурсите.
  2. SIC с GW.
  3. Лицензи. Ако лицензите се показват неправилно или не се показват на SMS, стартирайте командата vsec_central_licence за разпределение на лицензите.
  4. Настройка на политиката. 

Импорт на базата SmartEvent

  1. Активирайте блейда SmartEvent.
  2. Свързваме се чрез WinSCP към SMS и в бинарен режим предаваме предишно експортираните файлове -db-backup.backup и eventiaUpgrade.tar в папката /var/log/UpgradeR77.30_R80.20/
  3. Стартираме скрипта с командата: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
  4. Проверяваме статуса: watch -n 10 eventiaUpgrade.sh
  5. Проверяваме логовете в SmartEvent. СОН!

Актуализираме клъстера Check Point GW (Активен/Резервен)

Преди да започнем работата

  1. Запазваме конфигурацията на GAIA от всеки узел на клъстера в файл, за целта използваме командата: clish -c "show configuration" > ./.txt
  2. Експортираме файловете с помощта на WinSCP.
  3. Свързваме се с WebUI на двата узла и преминаваме на раздела CPUSE → Показване на всички пакети.
  4. Намираме пакета за актуализация за версия R80.20 Fresh Install, натискаме Изтеглете.
  5. Проверяваме, че CCP-протоколът работи в режим Вroadcast, за това въвеждаме командата: cphaprob -a if
    Ако е избран режим Multicast, сменете го с командата: cphaconf set_ccp broadcast (командата се изпълнява на всеки узел).
  6. Настройваме Downtime за активните узли във вашата система за мониторинг.
  7. Проверяваме, че на ниво виртуализация са включени параметрите MAC Address Change и Forged Transmits за sync-мрежата.

Актуализация

  1. Свързваме се по ssh към активния узел и стартираме командата за мониторинг на състоянието на клъстера: watch -n 2 cphaprob stat
  2. Връщаме се в WebUI на резервния узел на раздела CPUSE и за избрания пакет R80.20 Fresh Install стартираме Verifier.
  3. Анализираме отчета Verifier. Ако инсталацията е разрешена, преминаваме напред.
  4. Избираме пакета R80.20 Fresh Install и стартираме АктуализацияПо време на ъпгрейда системата ще бъде рестартирана. Настройките на GAIA се запазват. По време на рестартирането следим състоянието на клъстера. След зареждането статусът на актуализирания възел трябва да се промени на READY. В редица случаи имаме момент, когато все още неактуализираният възел преминава в статус Active Attention и спира да показва статуса на актуализирания възел. Не се притеснявайте - такъв вариант също е допустим.
  5. След завършване на ъпгрейда отваряме SmartDashboard.
  6. Отваряме клъстерния обект и променяме версията на клъстера от R77.30 на R80.20. Натискаме Ок. Ако при запазване на промените се появи грешка:
    Се е случила вътрешна грешка. (Код: 0x8003001D, Не може да се получи достъп до файла за операция на запис),
    следвайте SK119973. След това запазваме промените и натискаме Инсталирай политика.
  7. В настройките премахваме отметката от параметъра За клъстери на шлюзове, ако инсталацията на член на клъстера се провали, не инсталирайте на този клъстер.
  8. Инсталираме политиката. Системата ще генерира грешка за активния възел, който все още не е актуализиран.
  9. Свързваме се с актуализирания възел по ssh и стартираме командата за мониторинг на състоянието на клъстера: watch -n 2 cphaprob stat
  10. Свързваме се с WebUI на активния възел и преминаваме на таба CPUSE → Показване на всички пакети.Намираме пакета за актуализация за версия R80.20 Fresh Install, натискаме Изтеглете.
  11. Настройваме Downtime за активните узли във вашата система за мониторинг.
  12. Връщаме се в WebUI на активния възел на таба CPUSE и за избрания пакет R80.20 Fresh Install стартираме Verifier.
  13. Анализираме отчета Verifier. Ако инсталацията е разрешена, преминаваме напред.
  14. Избираме пакета R80.20 Fresh Install и стартираме Ъпгрейд. По време на ъпгрейда системата ще бъде рестартирана. Настройките на GAIA се запазват. По време на рестартирането следим състоянието на клъстера на вече актуализирания възел. След рестартиране състоянието на клъстера на актуализирания възел ще се промени от READY на ACTIVE.
  15. Когато ъпгрейдът завърши, стартираме SmartDashboard и инсталираме политиката.

Контролен списък за проверки след актуализация

  • Събитийните журнални записи в SmartLog, състоянието на VPN тунелите.
  • Настройки на GAIA.
  • Възстановяване на клъстера след тестов Failover.
  • Лицензи и договори. В случай че лицензите се показват неправилно или не се показват на SMS, стартираме командата. vsec_central_licence за разпределяне на лицензите.
  • CoreXL.
  • SecureXL.
  • Hotfix и CPinfo на два възела.

Заключение

По принцип на този момент всичко е - вие сте актуализирани.

При нас процесът отне средно от 6 до 12 часа, в зависимост от размерите на експортираните бази. Работата се проведе в две нощи: една – за актуализация на SMS, втора – за клъстера.

Не е имало задържане на трафика, независимо от това, че всички по-горе споменати грешки проверихме на себе си.

Разбира се, понякога могат да възникнат и напълно нови трудности в процеса на актуализация, но това е Check Point, и както всички знаем, винаги има hotfix!

Пожелавам ви успешни черно-розови нощи и ъпгрейди!

Източник: habr.com

Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри 🔥 Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри | ProHoster