Budowa Windows NT: jak przebiega komunikacja?

Główna zaleta Windowsa, czyli zgodność wsteczna, jest jednocześnie jego największym obciążeniem. Obsługa kompatybilności z trzema dekadami oprogramowania wymaga utrzymywania wielu składników, które po latach okazały się bardzo kiepskim pomysłem.

Windows NT miał być przenośnym i sieciowym systemem operacyjnym o wielu warstwach zgodności. Dziś, w czasach Windows 11, każdy z tych terminów oznacza coś diametralnie innego, niż w momencie powstawania NT. W rezultacie wiele decyzji projektowych fundamentalnych dla NT miało bardzo dużo sensu, ale ich implementacja prędko się zestarzała. Ponadto, Microsoft miał w dawnych czasach tendencje do wymyślania każdej technologii na nowo, także sieci. Każde "sieciowe" rozwiązanie z tamtych lat jest więc skrojone pod wymarłe i zapomniane protokoły.

Sercem NT i jedną z głównych cech odróżniających go od Linuksów jest mechanizm komunikacji międzyprocesowej z obsługą sieci, czyli DCOM RPC. Składniki systemowe w NT są zdefiniowane jako obiekty COM, z którymi można wdawać się w interakcję programistycznie, także skryptowo (przez Visual Basic i PowerShell). Zarządzanie systemem NT polega właśnie na konfigurowaniu stosownych opcji w obiektach COM. Protokołem komunikacji jest MSRPC. To na nim oparta jest cała komunikacja domenowa oraz wiele mechanizmów sieciowych. Odpytywanie zdalnych komputerów np. o usługi oraz zdalne konfigurowanie ich za pomocą MMC przebiega właśnie za pomocą RPC. Jest to także, wraz z OLE, jeden z mechanizmów komunikacji międzyprocesowej (wymiana komunikatów) o zasięgu lokalnym.

Dalsza część artykułu pod materiałem wideo

Obiektowa natura DCOM RPC jest przeciwieństwem modelu uniksowego, gdzie ustawienia trzymane są w plikach, a zmiana konfiguracji wymaga po prostu zdalnego zalogowania, a nie "wysłania uwierzytelnionego żądania RPC". Także zaawansowana, "głęboka" konfiguracja i stan systemu są reprezentowane w uniksach jako pliki (znajdujące się w katalogach /dev, /sys i /proc). Błędnym jest zakładanie, że windowsowym odpowiednikiem tego mechanizmu jest binarny Rejestr. Jest to tylko wewnętrzna baza danych - poprawna rekonfiguracja powinna zachodzić poprzez interakcję z COM, którego zmiana stanu jest odzwierciedlana poprzez zmiany w Rejestrze. Działa tak również warstwa WMI, pod spodem korzystająca z tych samych protokołów.

Doszukiwanie się na siłę podobnych mechanizmów w systemach linuksowych, poprzez przytaczanie takich składników, jak systemd, D-Bus, NetworkManager i Gsettings to nietrafiona analogia. Komunikacja międzyprocesowa odbywa się w Linuksach w znacząco odmienny sposób niż w NT i choć podejście znane z Windowsów nie jest unikatowe, zdecydowanie należy do rzadkości. Stosowane są także mieszanki: Windows 10 oferuje wszak serwer SSH. Wbudowany.

Sam fakt stosowania obiektowej natury nie oznacza jeszcze, że rozwiązanie jest niebezpiecznie skomplikowane. Wszak bezpieczne parsowanie strumieni tekstowych także nie bywa łatwe. Problem z DCOM RPC polega na tym, że będąc głównym mechanizmem komunikacji, w referencyjnej implementacji (NT 3.1) założono, że będzie zawsze słuchającym serwerem pracującym w zaufanej sieci IPX/Novell rozpiętej na skalę np. jednego budynku i będzie stosować dość słabe uwierzytelnianie, znane z serwera OS/2 LAN Manager. Założenie, że wszystko zawsze musi być "modelem programowania" bardzo niekorzystnie zniosło wprowadzenie do Windowsa protokołu TCP/IP, a następnie popularyzację rozległych LAN-ów i w końcu - internetu.

Skomplikowany model zdalnego zarządzania o słabym uwierzytelnianiu prędko ugiął się pod naporem masowej, potencjalnie niebezpiecznej komunikacji internetowej. Robaki Sasser i Blaster, wykorzystujące słabości implementacji RPC w Windows, wywołały ogólnoświatowe epidemie. W odpowiedzi, Microsoft na przestrzeni kolejnych lat wprowadził zaporę sieciową, obowiązkowe aktualizacje i kompilację zabezpieczającą przed przepełnieniami bufora. Zmniejszyło to liczbę dziur, ale (jak wiemy) nie rozwiązało problemu w całości. Dziś dalej odkrywane są podatności w RPC. Usługi nie da się usunąć bez zerwania kompatybilności - także na osobistych komputerach niekorzystających z domen i zdalnego zarządzania.

Microsoft miał więcej pomysłów z przerabianiem wszystkiego na API. Rezultatem owego podejścia był Internet Explorer (i możliwość wołania COM/WMI przez skrypty), ActiveX oraz makra Office. Elementy te były czołowymi kanałami propagacji złośliwego oprogramowania i dopiero od niedawna są one domyślnie wyłączone lub nieobecne. Dzisiejsze dziury w Windows są już bardziej wyrafinowane, choć wciąż zdarzają się podatności np. w Win32k oraz Buforze Wydruku.

Nowoczesne mechanizmy komunikacji i konfiguracji w Windows stosują dziś o wiele bezpieczniejsze, silnie uwierzytelnione i podpisane połączenia RPC, a zalecanym protokołem komunikacji jest WinRM, korzystający z… HTTPS. Graficzne narzędzia administracji zdalnej także są webowe: funkcjonalny następca MMC, Windows Admin Center, jest dostępny jako panel administracyjny otwierany przez przeglądarkę internetową. Nowoczesność ma jednak swoje ograniczenia. Nie może zepsuć microsoftowej maszyny do zarabiania pieniędzy: kompatybilności.