Analiza systemu open source polskich serwisów rządowych

avlab.pl 4 miesięcy temu
Zdjęcie: Analiza oprogramowania open source polskich serwisów rządowych


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. Zebrane wyniki są interesujące — przekrój zastosowanych technologii jest spory, pomimo tego, iż łączny udział dwóch głównych systemów to ponad 65%.

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.

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.

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.

Serwis dane.gov.pl.

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ć, iż 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ę, iż 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ę, iż 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 wszystkich 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 adekwatnie 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żeli 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%.

Udział systemów CMS w serwisach publicznych.

Poniższa tabela zawiera bardziej szczegółowe wyniki z uwzględnieniem języka, w którym napisano dany CMS i wersji oprogramowania, jeżeli była możliwa do wykrycia:

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 wszystkich 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ć, iż 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ż:

  • NASK (49)
  • Centrum Informatyki Statystycznej (33)
  • Atman (21)
  • T-Mobile Polska (21)
  • Centralny Osrodek Informatyki (19)
  • Orange Polska (19)
  • Centrum Przetwarzania Danych Ministerstwa Finansów (17)
  • IQ PL (17)
  • Netia (12)
  • Centrum e-Zdrowia (10)
  • Beyond.pl (10)
  • IT arte (10)
  • eTOP (10)
Idź do oryginalnego materiału