Jak poprawnie aktualizować bezpieczeństwo w FreeBSD

Jak FreeBSD obsługuje aktualizacje bezpieczeństwa

FreeBSD obsługuje aktualizacje bezpieczeństwa za pomocą dwóch oddzielnych narzędzi, ponieważ serwer FreeBSD składa się z dwóch odrębnych elementów. System podstawowy, czyli kernel oraz środowisko użytkownika dostarczone wraz z wydaniem, jest łatany za pomocą freebsd-update. Wszystko, co zostało zainstalowane dodatkowo, stanowi pakiet, a pakiety są łatane za pomocą pkg. Uruchomienie jednego narzędzia z pominięciem drugiego sprawia, że połowa maszyny pozostaje niezałatana, a system nie wyświetli żadnego powiadomienia w tej sprawie.

SSD Nodes nie oferuje obrazów FreeBSD. Nasze plany obejmują systemy Linux. Niniejszy wpis powstał mimo to, ponieważ grupy odbiorców całkowicie się pokrywają: osoby zarządzające naszymi serwerami Ubuntu i Debian często używają FreeBSD na firewallach lub na pojedynczych maszynach, które przejęły w zarządzanie. Rozdzielony model aktualizacji jest elementem, który często zaskakuje administratorów systemów Linux, dlatego warto go opisać. Każde polecenie, format komunikatu bezpieczeństwa oraz data wsparcia technicznego poniżej zostały zweryfikowane w sierpniu 2026 roku na podstawie strony bezpieczeństwa FreeBSD oraz stron podręcznika systemowego projektu.

Jedna uwaga przed przejściem do poleceń. FreeBSD nie instaluje sudo w systemie podstawowym. Wszystkie poniższe operacje wymagają uprawnień root. Należy użyć su - lub najpierw zainstalować sudo bądź doas z pakietów.

System podstawowy i pakiety to odrębne światy

W systemie Ubuntu apt zarządza całą maszyną. Jądro, openssl, nginx oraz własne narzędzia użytkownika są dostarczane jako pliki .deb przez jedno narzędzie, a apt upgrade aktualizuje je wszystkie jednocześnie.

FreeBSD dzieli to na dwie części. System podstawowy jest budowany i wersjonowany jako jedna całość: 15.1-RELEASE-p3 to pojedynczy numer obejmujący jądro, bibliotekę C, sshd oraz kopię OpenSSL w /usr/lib. Żaden z tych elementów nie pochodzi z pkg. Cała reszta znajduje się w /usr/local, jest dostarczana jako pakiet binarny zbudowany z drzewa ports i posiada własną wersję.

Dzięki temu na jednej maszynie mogą współistnieć dwie kopie OpenSSL: kopia systemowa w /usr/lib, aktualizowana wyłącznie przez freebsd-update, oraz kopia pakietowa w /usr/local/lib, aktualizowana wyłącznie przez pkg. To, której kopii użyje dany program, zależy od tego, z którą został skonsolidowany (linked). Oprogramowanie instalowane z pakietów zazwyczaj korzysta z kopii pakietowej. Aktualizacja jednej z nich nie wpływa na drugą.

Trzy polecenia pozwalają określić stan systemu:

freebsd-version -u
freebsd-version -k
uname -r

freebsd-version -u wyświetla poziom poprawek zainstalowanego środowiska użytkownika (userland). freebsd-version -k wyświetla poziom poprawek zainstalowanego jądra, a freebsd-version(1) wyjaśnia, dlaczego wartości te mogą się różnić od uname: „jeśli zainstalowano nowe jądro, ale system nie został jeszcze zrestartowany, freebsd-version wyświetli wersję i poziom poprawek nowego jądra”. uname -r wyświetla wersję aktualnie uruchomionego jądra. Istnieje również freebsd-version -r, które wyświetla uruchomione jądro, ale jest „odporne na zmienne środowiskowe”, co ma znaczenie wewnątrz jaila, gdzie UNAME_r jest często ustawione na inną wartość.

Biuletyny bezpieczeństwa i powiadomienia o erratach

Zespół ds. bezpieczeństwa FreeBSD wydaje dwa rodzaje powiadomień, które pełnią odmienne funkcje.

Biuletyn bezpieczeństwa (Security Advisory) dotyczy luki w zabezpieczeniach systemu bazowego. Identyfikator ma postać FreeBSD-SA-26:55.elf: litery SA, dwucyfrowy rok, kolejny numer w danym roku oraz nazwa dotkniętego komponentu. Biuletyny FreeBSD-SA-26:52.if_wg oraz FreeBSD-SA-26:50.kqueue zostały opublikowane 2026-07-29. Pełna lista znajduje się na stronie biuletynów FreeBSD.

Powiadomienie o erracie (Errata Notice) dotyczy problemów z poprawnością lub stabilnością, które wymagają wdrożenia w gałęzi wydania, ale nie mają wpływu na bezpieczeństwo. Format jest identyczny, z tą różnicą, że zamiast SA stosuje się EN: FreeBSD-EN-26:19.zfs, FreeBSD-EN-26:18.tzdata. Klasycznym przykładem jest aktualizacja danych stref czasowych. Nieaktualne dane stref czasowych nie stanowią wektora ataku, jednak powodują błędne znaczniki czasu do momentu zastosowania poprawki. Erraty są wymienione na stronie powiadomień o erratach FreeBSD.

Oba rodzaje powiadomień są podpisane kluczem PGP (Pretty Good Privacy) oficera ds. bezpieczeństwa i archiwizowane pod adresem security.FreeBSD.org. Oba są również dostarczane do systemu za pomocą freebsd-update.

W tym miejscu często pojawiają się nieporozumienia u administratorów systemów Linux. Żaden z tych rodzajów powiadomień nie dotyczy pakietów. Strona dotycząca bezpieczeństwa jasno to określa: problemy w kolekcji FreeBSD Ports "są opisywane oddzielnie w dokumencie FreeBSD VuXML". Zdalna luka w pakiecie nginx nigdy nie otrzyma numeru SA. Jeśli monitorowany jest wyłącznie kanał biuletynów, informacje o takich zagrożeniach nie zostaną odebrane.

Jak otrzymywać informacje o aktualizacjach bezpieczeństwa FreeBSD?

Listą, do której należy dołączyć, jest freebsd-security-notifications. Jest ona moderowana i generuje niewielki ruch, a publikowane są na niej bezpośrednio powiadomienia o poprawkach (advisories) oraz erraty. Subskrypcji można dokonać pod adresem lists.freebsd.org.

freebsd-announce również jest moderowana i zawiera powiadomienia o poprawkach wraz z ogłoszeniami o wydaniach, więc jest odpowiednia, jeśli preferuje się jedną listę dla wszystkich informacji. freebsd-security to lista dyskusyjna. Jej lektura jest przydatna, jednak nie jest to miejsce, w którym uzyskuje się informacje o konieczności instalacji poprawek.

Wszystkie te listy dotyczą wyłącznie systemu bazowego. Informacje o podatnościach pakietów nie są przesyłane pocztą elektroniczną. Należy je sprawdzać poprzez wykonanie odpowiedniego polecenia.

pkg audit oraz powiązana z nim baza danych

VuXML, czyli Vulnerabilities and Exposures Markup Language, to prowadzony przez projekt FreeBSD rejestr problemów bezpieczeństwa dotyczących portów i pakietów. Każdy wpis zawiera nazwę podatnego pakietu, zakresy wersji, których dotyczy problem, identyfikatory CVE (common vulnerabilities and exposures) oraz krótki opis. Cały zbiór jest dostępny pod adresem indeksu VuXML, gdzie można go sortować według pakietu, identyfikatora CVE lub daty.

pkg audit to narzędzie służące do odczytu tych danych:

pkg audit -F

-F pobiera aktualną kopię bazy danych przed rozpoczęciem sprawdzania. Należy używać tej flagi za każdym razem. Bez -F porównanie odbywa się względem kopii znajdującej się już na maszynie, która może być nieaktualna od miesięcy, przez co wynik nie ma wartości diagnostycznej. Polecenie porównuje wersję każdego zainstalowanego pakietu z każdym wpisem w VuXML, wyświetla dopasowania wraz z numerami CVE oraz linkiem do strony VuXML, a na końcu podaje liczbę znalezionych problemów w zainstalowanych pakietach.

Warto znać jeszcze dwie flagi opisane w pkg-audit(8). pkg audit -r dodatkowo „wyświetla pakiety, które zależą od podatnych pakietów i tym samym również mogą być podatne”. Pozwala to ustalić, że podatna biblioteka stanowi zagrożenie, ponieważ korzysta z niej sześć zainstalowanych elementów. pkg audit -R wyświetla wynik w formacie JSON lub innym formacie maszynowym, co jest przydatne przy integracji z systemami monitoringu.

Pakiet pkg instaluje skrypt okresowy w /usr/local/etc/periodic/security/410.pkg-audit. Jest on uruchamiany w ramach codziennego przeglądu bezpieczeństwa i wysyła wynik pocztą do użytkownika root. Należy upewnić się, że jest włączony, sprawdzając linię w /etc/periodic.conf:

daily_status_security_pkgaudit_enable="YES"

Ta codzienna wiadomość e-mail jest najbliższym odpowiednikiem mechanizmu unattended-upgrades znanego z Ubuntu w systemie FreeBSD, przy czym różnica stanowi istotę działania: unattended-upgrades instaluje poprawki automatycznie, podczas gdy pkg audit jedynie informuje o konieczności ich wdrożenia. pkg audit generuje raporty. Nigdy nie instaluje poprawek. W standardowej instalacji FreeBSD żaden mechanizm nie instaluje aktualizacji bezpieczeństwa bez ingerencji administratora.

Naprawa podatnego pakietu

pkg update
pkg upgrade

W repozytoriach pakietów FreeBSD nie istnieje wydzielony kanał wyłącznie dla poprawek bezpieczeństwa. System Ubuntu pozwala na pobieranie aktualizacji wyłącznie z noble-security, pozostawiając pozostałe pakiety w dotychczasowych wersjach. FreeBSD nie posiada odpowiednika tego rozwiązania, dlatego naprawa jednego podatnego pakietu wiąże się z przyjęciem wersji oferowanej obecnie przez repozytorium wraz ze wszystkimi powiązanymi zależnościami. Planuj aktualizacje pakietów jako zaplanowaną zmianę, a nie jako zadanie wykonywane w tle.

Szybkość otrzymania poprawki zależy od wybranej gałęzi repozytorium. Domyślnie stosowana jest gałąź quarterly, która według podręcznika zapewnia „bardziej przewidywalne i stabilne środowisko” poprzez przyjmowanie wyłącznie aktualizacji niezawierających nowych funkcji. Gałąź latest zawiera najnowsze wersje wszystkich pakietów. Jeśli zatem pkg audit -F zgłasza podatność pakietu, a pkg upgrade informuje, że brak dostępnych aktualizacji, oznacza to, że poprawka nie trafiła jeszcze do używanej gałęzi. Jest to mechanizm często prowadzący do nieporozumień.

Aby przełączyć maszynę na gałąź latest, skopiuj plik repozytorium dostarczony z systemem i edytuj kopię:

mkdir -p /usr/local/etc/pkg/repos
cp /etc/pkg/FreeBSD.conf /usr/local/etc/pkg/repos/FreeBSD.conf

Zmień quarterly na latest w linii url wewnątrz kopii, a następnie uruchom pkg update -f, aby pobrać nowy katalog. Skopiuj plik zamiast wpisywać nazwę repozytorium z pamięci: nazwa wewnątrz /etc/pkg/FreeBSD.conf jest tą, której faktycznie używa system, a plik w lokalizacji /usr/local/etc/pkg/repos nadpisuje tylko to repozytorium, którego nazwa jest identyczna.

Stosowanie poprawek systemu podstawowego

freebsd-update fetch
freebsd-update install

fetch pobiera poprawki dla bieżącego wydania i wyświetla listę plików, które zostaną zmodyfikowane. Jeśli nie ma żadnych zadań do wykonania, narzędzie wyświetla No updates needed to update system to 15.1-RELEASE-p3. i kończy działanie. Jeśli dostępne są poprawki, proces kończy się komunikatem informującym o konieczności uruchomienia polecenia instalacji. Żadne zmiany nie zostaną wprowadzone, dopóki nie zostanie uruchomione freebsd-update install, dlatego fetch można bezpiecznie wywoływać w dowolnym momencie.

freebsd-update(8) dostarcza aktualizacje binarne dla wersji ALPHA, BETA, RC oraz RELEASE, ale nie dla PRERELEASE, STABLE ani CURRENT. W przypadku korzystania z stable/15 kompilacja odbywa się ze źródeł, więc to narzędzie nie ma zastosowania.

Pobieranie można zautomatyzować, pozostawiając instalację jako proces ręczny. Wiersz dla /etc/crontab z podręcznika systemowego:

@daily                                  root    freebsd-update cron

freebsd-update cron odczekuje losowy czas od 1 do 3600 sekund, a następnie pobiera aktualizacje w taki sam sposób jak fetch i wysyła wiadomość e-mail do użytkownika root, gdy oczekują one na instalację. Losowe opóźnienie zapobiega sytuacji, w której wszystkie maszyny z FreeBSD w Internecie obciążają serwery lustrzane w tej samej sekundzie.

Dwa elementy w wynikach działania polecenia często wprowadzają użytkowników w błąd. src component not installed, skipped jest normalnym zjawiskiem na serwerze bez drzewa źródeł i nie stanowi błędu. Zestaw komponentów jest kontrolowany przez linię Components w pliku /etc/freebsd-update.conf, a dostępne opcje to src, world oraz kernel.

Jeśli instalacja przebiegnie nieprawidłowo, freebsd-update rollback usuwa ostatnio zainstalowane poprawki. W przypadku systemu z rootem na ZFS można postąpić lepiej, tworząc najpierw środowisko rozruchowe (boot environment):

bectl create pre-patch
freebsd-update fetch install

Jeśli poprawiony system nie uruchamia się, należy wybrać stare środowisko rozruchowe z menu programu ładującego, co przywróci system do stanu początkowego. Ta możliwość wycofania zmian jest jednym z praktycznych powodów używania ZFS jako systemu plików dla partycji root, a rozwiązanie to niemal nie zajmuje miejsca na dysku, dopóki oba środowiska nie zaczną się od siebie różnić.

Czy moje wydanie FreeBSD jest nadal wspierane?

Każde wydanie jest wspierane przez określony czas, publikowany jako tabela gałęzi na stronie dotyczącej bezpieczeństwa. Według stanu na sierpień 2026 tabela ta przedstawia się następująco:

• releng/15.1, czyli 15.1-RELEASE, do 31 marca 2027
• releng/15.0, czyli 15.0-RELEASE, do 30 września 2026
• releng/14.4, czyli 14.4-RELEASE, do 31 grudnia 2026
• stable/15 do 31 grudnia 2029
• stable/14 do 30 listopada 2028

Wydania punktowe otrzymują krótkie okresy wsparcia. Wsparcie dla 15.0-RELEASE kończy się około siedem tygodni po napisaniu tego tekstu, ponieważ wydanie 15.1 zostało opublikowane i uruchomiło odliczanie. Gałęzie stabilne są wspierane przez lata, są to gałęzie źródłowe, których freebsd-update nie obsługuje.

Sprawdź swoje wydanie za pomocą freebsd-version -u i porównaj je z tabelą. freebsd-update również wyświetla ostrzeżenia. W miarę zbliżania się daty końcowej, fetch wyświetla komunikat:

WARNING: FreeBSD 15.0-RELEASE is approaching its End-of-Life date.
It is strongly recommended that you upgrade to a newer
release within the next 2 months.

Po przekroczeniu tej daty ostrzeżenie zmienia się na WARNING: FreeBSD 15.0-RELEASE HAS PASSED ITS END-OF-LIFE DATE. Niewspierane wydanie nadal działa. Przestaje jednak otrzymywać biuletyny bezpieczeństwa, co oznacza, że każda kolejna podatność w systemie bazowym pozostanie w nim na stałe.

Aktualizacja wydania polega na wykonaniu freebsd-update -r 15.1-RELEASE upgrade, następnie freebsd-update install, ponownym uruchomieniu, ponownym wykonaniu freebsd-update install, następnie pkg-static upgrade -f w celu przeinstalowania wszystkich pakietów względem nowych bibliotek, a na końcu freebsd-update install. Podręcznik wskazuje, że mogą wystąpić tylko dwie fazy instalacji zamiast trzech, w zależności od tego, czy numery wersji jakichkolwiek bibliotek uległy zmianie. Zaplanuj okno serwisowe i przeczytaj przewodnik konfiguracji serwera FreeBSD 15 przed rozpoczęciem prac.

Restart czy wystarczy ponowne uruchomienie usługi?

FreeBSD odpowiada na to pytanie za pomocą jednego porównania:

freebsd-version -k
uname -r

freebsd-version -k to jądro na dysku. uname -r to jądro w pamięci. Różne ciągi znaków oznaczają, że zainstalowano nowe jądro, a aktualnie uruchomione jest stare, więc należy wykonać restart. Zgodne ciągi znaków oznaczają, że poprawka nie dotyczyła jądra, więc restart nie przyniesie żadnych korzyści.

W przypadku poprawek przestrzeni użytkownika należy zrestartować każdy proces korzystający ze zmodyfikowanego kodu. Poprawka biblioteki OpenSSL w /usr/lib nie wpłynie na sshd, który został uruchomiony trzy tygodnie temu i nadal ma w swojej przestrzeni adresowej zmapowaną starą bibliotekę. Plik na dysku jest nowy. Uruchomiony proces nie.

service sshd restart

Ta sama zasada dotyczy pakietów. pkg upgrade zastępuje plik binarny na dysku, podczas gdy uruchomiony proces nadal korzysta ze starej wersji, więc service nginx restart jest krokiem, który faktycznie wprowadza poprawkę w życie.

System bazowy nie posiada odpowiednika narzędzia needrestart znanego z Debiana, więc nic nie wyświetli monitu ani nie przechowa listy wymaganych działań. Należy samodzielnie śledzić, które usługi korzystają z poprawionej biblioteki, lub wykonać restart po każdej aktualizacji obejmującej biblioteki systemowe. Na serwerze, którego konfiguracja znajduje się w systemie kontroli wersji, restart jest rutynową operacją i jest znacznie tańszy niż błędne przekonanie o posiadaniu zainstalowanych poprawek.

Aktualizacja maszyny z uruchomionymi jailami

Jail współdzieli jądro systemu z hostem, dlatego ostrzeżenie dotyczące jądra dotyczy całego hosta, a każdy jail na maszynie dziedziczy ten problem. Po zaktualizowaniu hosta i jego restarcie, kwestia jądra zostaje rozwiązana dla wszystkich jaili. Przestrzeń użytkownika wewnątrz każdego jaila stanowi oddzielną instalację z własnym poziomem poprawek, a freebsd-version -j <jail> raportuje go z poziomu hosta. Pakiety wewnątrz jaila również są odrębne, a pkg -j <jail> audit -F przeprowadza ich audyt bez konieczności wchodzenia do jaila. Ten podział na współdzielone jądro i oddzielną przestrzeń użytkownika stanowi tę samą różnicę strukturalną, która definiuje porównanie jaili z kontenerami Docker.

Tłumaczenie na Ubuntu

Każdy nawyk z FreeBSD ma swój odpowiednik, dzięki czemu można przenieść rutynę w obu kierunkach.

• Łatki systemu bazowego: freebsd-update fetch, a następnie freebsd-update install. W systemie Ubuntu stosuje się apt update && apt upgrade, który obejmuje system bazowy oraz wszystkie pozostałe elementy jednocześnie.
• Oprogramowanie firm trzecich: pkg update && pkg upgrade w systemie FreeBSD. W systemie Ubuntu ponownie apt.
• Sprawdzanie znanych podatności: pkg audit -F w systemie FreeBSD. W systemie Ubuntu 24.04 najbliższym poleceniem jest pro security-status, które wyświetla aktualizacje bezpieczeństwa dla zainstalowanych pakietów, w tym zawartość Expanded Security Maintenance.
• Automatyczna instalacja: unattended-upgrades w systemie Ubuntu automatycznie stosuje aktualizacje bezpieczeństwa. FreeBSD nie posiada odpowiednika, dlatego freebsd-update cron pobiera i wysyła powiadomienia e-mail, podczas gdy instalację przeprowadza się ręcznie.
• Kanał z poradami: freebsd-security-notifications zawiera pozycje FreeBSD-SA oraz FreeBSD-EN. ubuntu-security-announce zawiera powiadomienia Ubuntu Security Notices.
• Baza danych podatności: VuXML dla portów i pakietów FreeBSD. Śledzenie CVE dla pakietów Ubuntu.
• Sprawdzanie konieczności restartu: freebsd-version -k w porównaniu z uname -r we FreeBSD. Obecność pliku /var/run/reboot-required w systemie Ubuntu.
• Okres wsparcia: tabela gałęzi na stronie bezpieczeństwa FreeBSD. Harmonogram wydań oraz pro security-status w systemie Ubuntu.

Podstawowa rutyna jest identyczna w obu systemach: subskrypcja kanału informacyjnego, uruchamianie audytu zgodnie z harmonogramem, a następnie decyzja o tym, co i kiedy zainstalować oraz kiedy wykonać restart. FreeBSD po prostu wymaga jawnego wykonania drugiej części procesu, ponieważ nie robi tego automatycznie. Szersze porównanie systemów Linux i FreeBSD jako platform serwerowych omawia pozostałe zmiany, które zachodzą podczas przenoszenia obciążenia między tymi systemami.

FAQ

Czy freebsd-update aktualizuje również pakiety?

Nie. freebsd-update obejmuje wyłącznie system bazowy, czyli jądro oraz narzędzia użytkownika dostarczone wraz z wydaniem. Oprogramowanie zainstalowane w /usr/local pochodzi z pakietów i jest aktualizowane za pomocą pkg upgrade. Należy uruchomić pkg audit -F, aby sprawdzić, które zainstalowane pakiety posiadają znane luki bezpieczeństwa, ponieważ biuletyny systemu bazowego ich nie uwzględniają, a listy mailingowe dotyczące bezpieczeństwa ich nie ogłaszają.

Skąd wiadomo, czy aktualizacja FreeBSD wymaga restartu?

Należy porównać freebsd-version -k z uname -r. Pierwsze polecenie wyświetla wersję jądra zainstalowaną na dysku, w tym tę, która została właśnie zapisana, ale jeszcze nie uruchomiona. Drugie polecenie wyświetla wersję jądra, która aktualnie pracuje. Różne ciągi znaków oznaczają konieczność restartu. Zgodne ciągi oznaczają, że poprawka dotyczyła tylko przestrzeni użytkownika, więc należy zrestartować odpowiednie usługi, na przykład za pomocą service sshd restart, ponieważ uruchomiony proces utrzymuje starą bibliotekę w pamięci do momentu restartu.

Jaka jest różnica między Security Advisory a Errata Notice?

Security Advisory, na przykład FreeBSD-SA-26:55.elf, usuwa lukę bezpieczeństwa w systemie bazowym. Errata Notice, na przykład FreeBSD-EN-26:18.tzdata, naprawia problem z poprawnością lub stabilnością, który nie wpływa na bezpieczeństwo, jak na przykład nieaktualne dane stref czasowych. Oba typy dokumentów używają schematu: rok, dwukropek, numer porządkowy, komponent. Oba są podpisywane przez Security Officer i dostarczane przez freebsd-update, przy czym żaden z nich nie dotyczy oprogramowania zainstalowanego z portów lub pakietów.

Czy istnieje odpowiednik unattended-upgrades dla FreeBSD?

Nie w systemie bazowym. freebsd-update cron pobiera oczekujące poprawki systemu bazowego i wysyła powiadomienie na adres root, ale nigdy ich nie instaluje. Skrypt okresowy, który instaluje pkg, uruchamia pkg audit codziennie i wysyła wynik pocztą, ale również niczego nie aktualizuje. Automatyczna instalacja jest rozwiązaniem, które należy skonfigurować samodzielnie za pomocą cron, a ponieważ aktualizacja pakietów we FreeBSD pobiera najnowszą wersję zamiast tylko poprawek bezpieczeństwa, większość administratorów czyta powiadomienia i przeprowadza instalację ręcznie.

Jak sprawdzić, czy wydanie FreeBSD jest nadal wspierane?

Należy uruchomić freebsd-version -u, aby sprawdzić wersję systemu, a następnie porównać ją z tabelą wspieranych gałęzi na stronie bezpieczeństwa FreeBSD. Wydania punktowe mają krótkie okna wsparcia: według stanu na sierpień 2026, wsparcie dla 15.0-RELEASE kończy się 30 września 2026, podczas gdy 15.1-RELEASE jest wspierane do 31 marca 2027. freebsd-update fetch ostrzega o zbliżającym się terminie, a po jego przekroczeniu wyświetla komunikat informujący, że wydanie OSIĄGNĘŁO DATĘ KOŃCA WSPARCIA (END-OF-LIFE). Po tym terminie żadne nowe biuletyny bezpieczeństwa nie będą dotyczyć danego systemu.