Uwaga na stare wersje systemów operacyjnych

Ostatnie wersje ransomware oraz malware, jak choćby NotPetya, Petya.A oraz WannaCry dedykowane były wyraźnie maszynom windowsowym - zarówno serwerom jak i stacjom roboczym, PC i laptopom. Widać też było wyraźnie jakie zagrożenie tworzyć może wybiórcze aktualizowanie systemów i pomijanie poprawek bezpieczeństwa oraz używanie systemów, gdzie nie wszystkie luki zostały załatane a sam system jest już nie wspierany jak choćby Windows XP.

Problem ten dotyczy według analityków głównie desktopów, bowiem równo 90 proc. z nich pracuje pod kontrolą różnych wersji Windows. Z pozostałych 10 proc., maszyny z Linuxem stanowią 2 proc. zaś z MacOS - 3,6 proc. reszta to "inne systemy operacyjne" jak choćby FreeBSD. W przypadku małych serwerów, używanych zwykle w firmach MSP, sytuacja jest podobna - Windows nie stanowi systemu operacyjnego dla około 12 proc. maszyn, z czego udziały Red Hat (RHEL) wynoszą 1,2 proc. zaś innych systemów linuksowych jak Ubuntu, SUSE, Debian, CentOS i Oracle Linux razem stanowią o 10,5 proc.

Zupełnie inna jest sytuacja jeśli chodzi o średnie i duże serwery - webowe, bezpieczeństwa, czy wyspecjalizowane systemowe. Tutaj udziały systemów unixowych i Linuxsów wynoszą 66 proc., zaś Windows różnych wersji - 33 proc. z tendencją spadkową. Z tych 66 proc. pod kontrolą takich systemów jak Debian, Ubuntu czy CentOs pozostaje 37 proc. Teoretycznie wszelkie luki i podatności w tych systemach są znane, zaś takie jak w protokole wymiany plików w Windows, która umożliwiła atak WannaCry - nie istnieją. Jednak, według analityków Palmer Security, nie tyle w dystrybucjach Linuxów nie ma luk, ile niewiele o nich wiadomo.

Tymczasem jak zwrócili uwagę analitycy pracujący dla portalu The Register, istnieje problem kompatybilności, istotny zwłaszcza w przypadku nowych dystrybucji Linuxa. Czasem konfigurowanie na nowo aplikacji prawidłowo działających w poprzedniej wersji systemu zajmuje kilka dni lub nawet tydzień. Stąd też w wielu przypadkach administratorzy nie wgrywają nowej dystrybucji.

I tak w przypadku Red Hat Enterprise Linux (RHEL) w wielkich firmach istnieją serwery, pracujące pod kontrolą RHEL 5.x, który znajduje się od 10 lat na rynku. Nieco młodsza i jeszcze popularniejsza dystrybucja - RHEL 7.x - jest już na rynku trzeci rok. Co prawda rozszerzone wsparcie dla 5.x będzie kontynuowane do 2020 roku, ale podstawowego wsparcia - w tym dla bezpieczeństwa - już praktycznie nie ma. W ciągu najbliższych dwóch lat skończy się też podstawowe wsparcie dla dystrybucji RHEL 7.x i zostanie tylko rozszerzone.

Podobnie dzieje się w przypadku najczęściej używanego Ubuntu. Standardowy system posiada wsparcie trwające tylko 9 miesięcy. Za to dystrybucje "long-term suport" posiadają wsparcie pięcioletnie. Obecnie najstarszą używaną wersją Ubuntu jest 14.04, jeszcze wspieraną w ramach long term suport, ale już niedługo. Z kolei nowsza wersja 16.04 będzie posiadała wsparcie długookresowe do 2021 roku. W obu przypadkach może ono nie dotyczyć luk bezpieczeństwa. Z kolei CentOS jest często używany jeszcze w wersji 5, która nie ma wsparcia od marca 2017 roku. Nowsza i popularna wersja 6 jest na rynku od 2011 roku i będzie wspierana w zakresie rozszerzonym do 2020 roku, zaś obecna wersja 7 jest jeszcze rzadko używana.

Teoretycznie wszystkie te wersje będą miały na bieżąco aktualizowane luki bezpieczeństwa oraz funkcjonalne. Jednak z konieczności twórcy dystrybucji skupią się głównie na nowszych systemach i ewentualne wykrywanie podatności będzie spowolnione. Pozostaje też jeszcze problem tzw. patchowania - ogólna opinia w działach IT iż Linux we wszystkich dystrybucjach jest systemem zasadniczo bezpiecznym przed wszystkimi zagrożeniami, powoduje iż często systemy te są uaktualniane rzadko i "od przypadku do przypadku".

Warto jeszcze zwrócić uwagę, iż podwersje są często inaczej wspierane niż wersje główne. I tak w przypadku RHEL 6.0, rozszerzone wsparcie zakończyło się w 2012 roku, za to dla RHEL 6.7 będzie trwało jeszcze rok. W przypadku wersji głównych uaktualnienia w zasadzie nie tworzą żadnego problemy dla aplikacji "nie tykają ich". Jednak jeśli z wersji głównej RHEL 6.2 dokona się uaktualnienia do RHEL 6.3 i następnie będzie się patchować tą wersję, zamykając znalezione luki, wówczas nie można zagwarantować, że nie będzie problemów z aplikacjami.

Wiedzą o tym administratorzy stad też wolą pozostawać przy starych, ale sprawdzonych wersjach głównych - którym czasem kończy się nawet rozszerzone wsparcie - i nie uaktualniać ich do nowszych podwersji, żeby nie tworzyć sobie niepotrzebnych i czasochłonnych problemów. Zwłaszcza, że w przypadku rzadziej spotykanych podwersji patce - w tym i bezpieczeństwa - pojawiają się z mniejszą częstotliwością niż dla wersji głównych.

Oczywiście problemy z patchami można ominąć - analitycy z The Register zauważają, że wystarczy stworzyć wirtualne środowisko, klonując serwer i tam badając, jak zadziała dany patch i ewentualnie sprawdzić, co można będzie zrobić jeśli zostanie zmieniona konfiguracja aplikacji.

Można też wrócić do roboczej wersji systemu, jeśli okaże się, że nowy patch "namiesza w aplikacjach". Jednak jest to bardzo czasochłonne i większość administratorów, nie mających "żyłki badacza" chce takiego wysiłku uniknąć stosując procedury, które analitycy Palmer Security nazywają dość ironicznie "automatycznym administrowaniem": reagowanie tylko na bezpośrednie zagrożenie, przyjmowanie zasady, że ""najważniejsze jest aby system i aplikacje działały tak, aby nie trzeba było nic przy nich robić" i swoisty minimalizm, zakładający, ze najprostsze rozwiązania, które sprawdziły się rok czy dwa lata temu, sprawdzą się zawsze. Tymczasem, jak zauważają analitycy "nie jest tak, że w dystrybucjach Linuxa nie ma luk. Są, tylko nie wiemy o nich, dopóki ktoś ich nie użyje".

Marek Meissner