Z tego korzystają polskie serwisy rządowe. Analiza narzędzi

Na podstawie publicznie dostępnych informacji i z użyciem kilku skryptów wykonałem analizę używanych systemów CMS przez serwisy działające w domenie .gov.pl. Dodatkowo przygotowałem zestawienie podmiotów świadczących usługi hostingu tych witryn.

Komputer - zdjęcie poglądowe

Źródło zdjęć: © Licencjodawca

Michał Giza

28 października 2024, 15:00

Zebrane wyniki są interesujące — przekrój zastosowanych technologii jest spory, pomimo tego, że łączny udział dwóch głównych systemów to ponad 65 proc.

WhatCMS.org

Pierwszym krokiem był wybór API serwisu umożliwiającego wykrywanie systemów CMS i ich wersji. Na co dzień korzystam z wtyczki Wappalyzer, której działanie w ogólnym znaczeniu jest w pełni wystarczające. Dostępne jest także bardzo intuicyjne API.

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

Niestety zakres systemów CMS, które Wappalyzer wykrywa z powodzeniem, wydaje się ograniczony w stosunku do możliwości alternatywnego rozwiązania. WhatCMS.org całkowicie spełnił oczekiwania. W porównaniu do Wappalyzer umożliwia także gromadzenie linków do profili w serwisach społecznościowych na analizowanych witrynach. Obsługa API ogranicza się do wysłania zapytania do endpoint’a /API/Tech podając klucz API i żądany URL.

Przykład danych zwróconych z API WhatCMS.org© Licencjodawca

Zbiór adresów serwisów rządowych

Dane o adresach podmiotów publicznych są w pełni dostępne na tej stronie. Potrzebowałem jednak listy w formie tekstowej, a scrapowanie tej konkretnej strony jest w pewnym sensie utrudnione. Można było oczywiście użyć rozwiązań typu Selenium czy Playwright, natomiast znacznie szybszym sposobem okazało się skorzystanie z nieco starszej listy dostępnej w formacie CSV na tej stronie.

Plik Aktualizacja_wykazu_stron_www_-_2022-07-20.csv jest podzielony na dwie kolumny: Nazwa podmiotu publicznego i Adres strony internetowej. W pliku znajduje się około 98 tys. adresów. Interesowały mnie wyłącznie serwisy w domenie .gov.pl, które wyodrębniłem poleceniem GREP do osobnego pliku.

Trzy adresy były błędne tzn. zawierały dwie kropki w nazwie domeny, co spowodowałoby błędy podczas działania skryptów.

IZBA CELNA;bip..uc.gov.pl
SAMORZĄDOWE CENTRUM USŁUG WSPÓLNYCH W POŁAŃCU;scuw-polaniec..bip.gov.pl
WOJEWÓDZKI SĄD ADMINISTRACYJNY W WARSZAWIE;bip..wsa.gov.pl

Podmieniłem każde takie wystąpienie na jeden znak kropki. Ostatecznie otrzymałem dokładnie 8432 domeny *.gov.pl.

Należało pamiętać, że część serwisów mogła być dostępna wyłącznie z polskich adresów IP, co jak najbardziej jest dobrą i zasadną praktyką. Zamierzałem jednak użyć wspomnianego serwisu WhatCMS.org, który korzysta z zagranicznych adresacji. Aby uniknąć dużej ilości błędów związanych z brakiem dostępu (timeout, refused itp.), aktywowałem połączenie VPN do zagranicznego serwera, aby mój wyjściowy adres "przedstawiał się" jako zagraniczny, a następnie uruchomiłem skrypt, który zwyczajnie odpytywał każdą domenę z listy. W przypadku zwrócenia kodu HTTP 200 domena była zapisywana do kolejnego pliku.

Zwróciłem uwagę, że pewne serwisy mogą przekierowywać na zewnętrzne witryny. Dlatego dodałem do skryptu warunek, aby przekierowania na inną domenę także były zapisywane do pliku — to serwisy rządowe, ale niekoniecznie działające pod domeną .gov.pl, np. ZUS.pl. Co więcej okazało się, że część adresów występuje jednocześnie z prefiksem www i bez niego. Usunąłem takie wystąpienia i w konsekwencji do analizy pozostało 7140 unikalnych adresów.

Działanie skryptu

Skrypt dla każdego adresu z pliku wykonywał request HTTP do API serwisu WhatCMS.org. Zwracane odpowiedzi w formacie JSON były na bieżąco zapisywane. Dzięki temu podejściu skrypt mógł zostać przerwany we właściwie dowolnym momencie, a po ponownym uruchomieniu kontynuował pracę od ostatnio analizowanego adresu. Pełniło to również rolę oczywistego zabezpieczenia przed różnymi "awariami", np. chwilowymi problemami z działaniem sieci.

W następnej kolejności wykonywane było parsowanie danych zwróconych z API. Jeśli wartość code w tablicy result wynosiła 200 (kod HTTP oznaczający udane przetworzenie żądania), to skrypt odczytywał wartości name dla categories zawierających wartości "CMS". W innym przypadku do pliku z wynikami zapisywany był zwrócony komunikat błędu. Wykluczając pojedyncze błędy związane z połączeniem do API (rozwiązane poprzez ponowne uruchomienie skryptu poprzedzone usunięciem wadliwych danych z pliku), przy kilku domenach pojawiły się problemy z wykryciem używanego systemu CMS bądź niemożliwość nawiązania połączenia do docelowej domeny przez serwis WhatCMS.org. Były to jednak sporadyczne sytuacje i nie mają one widocznego wpływu na otrzymane statystyki.

Dodatkowo nie wszystkie serwisy publiczne używają powszechnie znanych systemów zarządzania treścią. Przykładem są witryny *.bip.gov.pl. Nie zostały one uwzględnione w statystyce procentowej.

Wyniki — systemy CMS na rządowych serwisach

Poniższy wykres w celu zachowania czytelności przedstawia wyłącznie rozwiązania z udziałem powyżej 1 proc.

Udział systemów CMS w serwisach publicznych© avlab.pl

Można zauważyć, że popularne systemy są wykorzystywane znacznie częściej niż ich mniej rozpoznawalne alternatywy. To rozsądny wybór, ponieważ każde z tych rozwiązań jest aktywnie rozwijane i otrzymuje aktualizacje. Łatwiej wtedy także o wsparcie techniczne i development aplikacji we własnym zakresie, bo większość programistów posiada doświadczenie i know-how pracy przy znanych systemach CMS.

Jedynie trzy systemy CMS (kreator Adobe Muse nie jest już rozwijany) z powyższej listy stanowią rozwiązania w pełni komercyjne. Pozostałe narzędzia oferują wersje bezpłatne i/lub są dostępne na licencjach open-source. Może się wydawać, że koszty wdrożenia systemu z otwartym kodem źródłowym (np. WordPress) będą mniejsze, ale często jest to nieprzemyślana opinia. Systemy publiczne są niezwykle złożone i czas niezbędny na dostosowanie bezpłatnego rozwiązania do wymagań może okazać się elementem problematycznym. Pisane od podstaw ("szyte na miarę") aplikacje czy komercyjne systemy zapewniają pod tym względem większą elastyczność.

Duża liczba wykorzystywanych systemów zarządzania treścią jest napisana w języku PHP. Zaletą tej technologii jest łatwość instalacji oraz utrzymania takiej aplikacji. Wystarczy skonfigurować serwer WWW do obsługi PHP (co nie jest skomplikowanym procesem) i umieścić pliki aplikacji w ścieżce ustawionej jako document root.

Z wyjątkiem Adobe Muse, które wsparcie zakończyło się 26.03.2020, każde z rozwiązań jest stale utrzymywane przez swoich tworców. Niestety biorąc pod uwagę używane wersje, dochodzimy do wniosku, że aktualne wsparcie posiada wyłącznie WordPress 6.6.1 i Jekyll 3.8.5. To stwierdzenie dotyczy oczywiście systemów, dla których możliwe było uzyskanie zainstalowanej wersji.

Nie oznacza to oczywiście, że pozostałe wersje stosowane w serwisach publicznych są podatne. Istnieje takie ryzyko, szczególnie w przypadku bardzo przestarzałych wersji WordPress, Joomla czy Drupal. Jednak trzeba pamiętać, że większość podatności dla tych systemów występuje wyłącznie w określonych konfiguracjach lub dotyczy wyłącznie pewnych pluginów itp. Dodatkowo nawet jeśli w danej wersji występuje podatność, to programiści mogli naprawić te błędy bez aktualizacji całego systemu CMS. Niektóre funkcjonalności aplikacji mogą być kompatybilne jedynie z określoną wersją CMS, stąd aktualizacja i dostosowanie kodu mogłoby być działaniem nieopłacalnym.

Hosting serwisów publicznych

Oprócz analizy zainstalowanych systemów CMS przeprowadziłem także sprawdzenie obejmujące podmioty świadczące usługi ich hostingu. Zebrałem adres IP powiązany z każdą domeną i w ten sposób uzyskałem 824 unikalnych adresów. Następnie korzystając z API serwisu IPinfo.io zweryfikowałem dla każdego adresu państwo, ASN i (gdy był dostępny) rekord PTR (revDNS).

Jak można się było spodziewać, zdecydowana większość, bo 782 adresy, wskazują na Polskę. Poza tym analizowane serwisy rządowe korzystają z serwerów znajdujących się poza naszym państwem. Odpowiadają za nie następujące podmioty:

Imperva (USA) – 6 adresów (AS19551)
Cloudflare (USA) – 5 adresów (AS13335)
Fastly (USA) – 2 adresy (AS54113)
OVH (Francja) – 12 adresów (AS16276)
Hetzner (Niemcy) – 4 adresy (AS24940)
Amazon (Niemcy) – 1 adres (AS16509)
Imperva (Niemcy) – 1 adres (AS19551)
Oracle (Niemcy) – 1 adres (AS31898)
Azure (Irlandia) – 3 adresy (AS8075)
Amazon (Irlandia) – 2 adresy (AS16509)
Azure (Holandia) – 4 adresy (AS8075)
Forpsi (Czechy) – 1 adres (AS24806)

Jak widać są to w dużej mierze usługi związane z bezpieczeństwem i ochroną anty-DDoS. Należy pamiętać, że przykładowo Imperva czy Cloudflare nie posiadają w swoich ofertach usługi hostingu — adres IP kilku domen faktycznie wskazuje na te serwisy, natomiast w praktyce ich działanie jest oparte na reverse proxy (wraz z dodatkowymi zabezpieczeniami, m.in. WAF). Pisałem o tym bardziej szczegółowo w tym miejscu. Stanowi to standardową praktykę, szczególnie w sytuacji utrzymywania dużych serwisów.

W przypadku polskich podmiotów za największą ilość hostowanych serwisów odpowiadają: nazwa.pl (173), home.pl (88) i Cyber_Folks (67). Na liście najczęściej pojawiały się również: