Záplatování a aktualizace systémů je klíčovým krokem ke snížení možných vektorů útoků proti vaší infrastruktuře. Pokud jsou ve vašem prostředí systémy, které nejsou aktuální s opravami, mohou se vyskytnout vektory útoků, o kterých nevíte, že mohou potenciálně ovlivnit celou vaši organizaci. Jaké kroky však máte k dispozici, když událost opravy neproběhne podle očekávání?
[ Čtenářům se také líbilo: Zabezpečení zděděného systému Linux ]
Například nemusí být splněny závislosti, mohou existovat neshodné verze napříč i686 a x86_64 RPM, nové verze balíčků nemusí fungovat podle očekávání nebo se může pokazit něco jiného. Když se něco pokazí, je důležité mít plán, jak postupovat. To sníží úroveň stresu a zajistí, že každý, kdo na úkolu pracuje, bude vědět, co dělají ostatní.
Testovací opravy
Při opravování je důležité nejprve opravy otestovat v testovacím prostředí které odpovídá vašemu produkčnímu prostředí . Pokud záplaty testujete na jiném hardwaru, s různými verzemi softwaru nebo s různými pracovními zátěžemi či procesy, než je vaše produkční prostředí, není zaručeno, že výsledky záplatovacích testů budou odrážet to, co se stane ve výrobě. Jakmile budete mít testovací prostředí, kde si můžete ověřit, že by měl být nainstalován daný balíček oprav, výrazně snížíte pravděpodobnost problémů při instalaci aktualizací.
Nezdařené opravy
Pokud se aktualizace nepodaří nainstalovat, první věcí, kterou musíte udělat, je zachytit jakýkoli výstup na konzole nebo do protokolů. Může se jednat o pouhé zkopírování souboru protokolu do samostatného umístění nebo o zkopírování textu zobrazeného na obrazovce konzoly. V závislosti na způsobu pokusu o opravu můžete zkusit znovu spustit aktualizace, tentokrát s povoleným podrobným výstupem. Jakmile budete mít chybový výstup, budete chtít vidět všechny rozdíly mezi vaším testovacím prostředím a tím, co máte v produkci. Musíte také ověřit, že všechny záplaty byly použity při testování a že žádné záplaty nebo chyby nebyly náhodně vynechány. Jednou ze základních položek, které je třeba zkontrolovat, je seznam nainstalovaných RPM na vašem testovacím serveru pro porovnání s verzemi na vašem produkčním serveru.
Například na produkčním serveru:
# rpm -qa --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n'| sort &> /tmp/rpm-qa.prod.output.txt
Pak to můžete porovnat s výstupem shromážděným na vašem testovacím serveru v jeho /tmp/rpm-qa.dev.output.txt .
Měli byste také zkontrolovat, zda je k dispozici yum úložiště jsou na obou systémech stejná. Můžete to udělat ve třech jednoduchých krocích.
Nejprve vymažte mezipaměť:
# yum clean all
# rm /var/cache/yum/* -rf Dále aktualizujte správce předplatného:
# subscription-manager refresh
Za třetí, uveďte repozitáře v yum pomocí -v argument, abyste viděli další informace, jako je repodate a počet balíčků v úložištích:
# yum repolist -v V následujícím příkladu se podíváme na rhel-8-for-x86_64-appstream-rpms úložiště používané klientem na mém serveru Red Hat Satellite:
Repo-id : rhel-8-for-x86_64-appstream-rpms
Repo-name : Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
Repo-revision: 1605844838
Repo-updated : Thu 19 Nov 2020 11:02:03 PM EST
Repo-pkgs : 13,502
Repo-size : 31 G
Repo-baseurl : https://opendemo.usersys.redhat.com/pulp/repos/opendemoorg/Library/content/dist/rhel8/8/x86_64/appstream/os
Repo-expire : 1 second(s) (last: Wed 31 Dec 1969 07:00:00 PM EST)
Repo-filename: /etc/yum.repos.d/redhat.repo Klíčové řádky jsou zde repo-id , znovu aktualizováno , repo-balíčky a repo-baseurl . Pokud moje testovací a produkční systémy zobrazují různé informace pro jejich upstream úložiště, pak existuje šance, že závislosti nemusí být splněny nebo něco jiného může selhat. Pokud tomu tak je, budete muset prozkoumat, proč systémy vidí různé informace.
Další nastavení
Předpokládejme, že testovací a produkční systémy mají očekávané RPM a stejná úložiště, ale záplatování stále selhává. V takovém případě mohou být dalšími možnými příčinami nesprávně použité nastavení zabezpečení, nedostatek místa na disku nebo možná nesprávná uživatelská oprávnění. Chcete-li je prozkoumat, zkontrolujte protokoly, jako je /var/log/messages , /var/log/secure a /var/log/audit/audit.log může být užitečné, stejně jako použití příkazu df -h pro kontrolu místa na disku. Zákazníci společnosti Red Hat jsou také vítáni, když si otevřou lístek podpory pro pomoc s řešením problému.
[ Bezplatný online kurz:Technický přehled Red Hat Enterprise Linux. ]
Sbalit
Existuje mnoho možných příčin záplat, které se neinstalují správně, ale možnost porovnat testovací prostředí s produkčním prostředím výrazně usnadní odstraňování problémů. Konfigurace, závislosti, pracovní zatížení a úložiště by měly být v obou prostředích stejné.