Polski hosting - jest raczej fatalnie
Istnieją w Internecie porównania rozmaitych usług hostingowych. Bierze się w nich pod uwagę wszystko: od stosunku pojemność-cena, aż do ilości administratorów czy sposobu wentylacji macierzy dyskowych. My spróbujemy podejść do zagadnienia od nieco innej strony i sprawdzimy, jak firmy proponujące przetrzymywanie u siebie naszych dzieł podchodzą do zagadnień bezpieczeństwa. Nie bierzemy pod uwagę, czy jest to hosting u pana Tadzika, czy może wielka korporacja - sprawdzamy wyłącznie sposób zabezpieczenia serwerów. Wniosek mamy jeden: na porządku dziennym jest oprogramowanie, które nie było aktualizowane od kilkunastu miesięcy.
Sprawdzanie zabezpieczeń w serwerach to spacer tuż nad przepaścią. Nigdy nie wiadomo, czy któryś z administratorów nie zauważy naszych testów i nie uzna, że należy dogłębnie przebadać maszynę znajdującą się po drugiej stronie kabla. Nigdy nie wiadomo, czy pracujący na jego usługach Snort nie podniesie alarmu, że dzieją się jakieś okropieństwa. I choć to mało prawdopodobne, zawsze istnieje możliwość, że zdecyduje się on na wysłanie do mojego dostawcy internetowego e-maila z prośbą o wyjaśnienia. Słowem: ryzyko duże, a efekty badań mogą być mizerne.
Mimo wszystko postanowiłem spróbować przetestować polskie serwery. Starałem działać się w sposób zupełnie nieinwazyjny, choć nie zawsze było to możliwe. Testowałem, czy prawdą jest, iż szewc bez butów chodzi. Zacząłem od bardzo prostych zabaw w pingowanie serwera, przez badanie zwracanych nagłówków, aż do testów SSH. Miałem zamiar pobawić się jeszcze hmapem i httprintem, ale wyniki testów mnie przeraziły. Dlaczego? Tylko popatrzcie...
Ping, ping - jest tam kto?
Pierwszy test z pozoru był bardzo prosty: w linii poleceń ( Start | Wszystkie programy | Akcesoria | Wiersz polecenia ) wpisywałem ping nazwaserwera.pl. Chciałem w ten sposób sprawdzić, czy i w jakim czasie serwer odpowiada na pingi. Czas służył mi głównie jako materiał porównawczy, za bardzo się nim nie przejmowałem. Ciekaw natomiast byłem, jak jest z poprawnością konfiguracji firewalla w firmach hostingowych.
Warto bowiem wiedzieć, że maszyny włączone do Internetu i pracujące w trybie 24/7/365 powinny akceptować większość pakietów ICMP - i odpowiadać na nie. Jeśli tego nie robią, świadczy to o tym, iż osoba konfigurująca firewall była zdecydowanie nadgorliwa. ICMP bowiem - jak wskazuje sama nazwa ( Internet Control Message Protocol ) - pozwala na szybkie diagnozowanie problemów występujących w sieci oraz dogadanie się hostów w kwestii ewentualnej dalszej interakcji. Jego zupełne odfiltrowanie może prowadzić do bardzo nieoczekiwanych efektów w rodzaju braku dostępności witryny WWW czy problemów z wysyłaniem e-maili od strony użytkowników.
Dlatego zanim w radosnym szale eksperymentów zdecydujemy się na wycięcie w IPTables całego ruchu ICMP, pomyślmy, czy nie warto byłoby odpowiedzieć choćby na pakiety typu destination-unreachable, time-exceeded, source-quench, parameter-problem i echo-reply.
Administratorzy trzech serwerów z naszej listy wpadli w radosny szał filtrowania wszystkiego... Nie świadczy to o nich najlepiej.
Serwer WWW to...
W kroku drugim sprawdzamy nagłówki zwracane przez serwer WWW - podobnie funkcjonuje znany serwis http://Netcraft.com - i przyglądamy im się. Prawda jest taka, że teoretycznie żadna to filozofia, bo nagłówki łatwo zmienić. Wygląda jednak na to, że niewielu administratorów rzeczywiście to robi: wobec potrzeby nieustannego niańczenia użytkowników i łatania serwera trudno jest ciągle pamiętać o tak marginalnym zagadnieniu. Tym niemniej wszelkie zaprezentowane w tabeli wyniki należy potraktować z pewną nieufnością...
Do zbierania wyników posłużyłem się skryptem PHP własnej produkcji. Odpytywał on kolejne serwery z listy i zapisywał wyniki do bazy danych.
Choć nagłówki łatwo sprawdzić również w przeglądarce ( np. w Firefoksie czy Linksie ), skrypt dał mi wygodę automatycznego parsowania wyników. To naprawdę dużo, kiedy testuje się prawie dziewięćdziesiąt różnych serwerów w odstępach czasu.
Jak łatwo zauważyć, dominuje software starszy niż rok. Wygląda na to, że właściciele lubią kusić licho!
Puk, puk, to ja, admin
Odstatni test dotyczył sprawdzianu SSH - powłoka SSH ( Secure SHell ) udostępnia możliwość szyfrowanego połączenia z serwerem, na przykład w celu wykonania prac administracyjnych. Włamywaczowi może udać się przechwycić dane wysyłane przez SSH, a mimo tego nie zdobędzie istotnych danych, np. hasła czy nazw kont na serwerze.
Test był prosty: w konsoli wpisałem polecenie ssh nazwaserwera.pl ( tylko systemy uniksowe i uniksopodobne ) i przyglądałem się wynikom. Nie starałem się logować, nie podejmowałem ataku metodą brute force - wyłącznie obserwowałem.Dobrze skonfigurowany serwer powinien odrzucić moje połączenie ( nie jestem przecież upowazniony choćby do rozpoczynania sesji SSH ). Nieco mniej dobrze skonfigurowany - wyświetli znak zachęty do logowania oraz baner informujący o obsługiwanej wersji protokołu. Pozwoli też na wielokrotne próby logowania ( 3 razy na podejście ).
Fatalnie skonfigurowany serwer SSH - świadczący o adminie bardzo źle - nie tylko się przedstawi, ale i natychmiast poinformuje użytkownika o własnej konfiguracji.
Większość testowanych serwerów hostingowych była skonfigurowana na poziomie pomiędzy "nieco mniej dobrze" a "fatalnie".
Podsumowanie
Łatwo zauważyć, że im serwer mniejszy, tym z reguły właściciele bardziej o niego dbają. Nietrudno jednak dostrzec, że nawet najsprawniejsi mają problemy z dotrzymaniem tempa. W serwerach dominuje mająca już kilka miesięcy i posiadająca wiele niepokojących bugów wersja PHP 4.3.9. PHP 4.4.1 to wielka rzadkość, PHP 5.1.1 nie ma nikt. Tym niemniej widać pewien postęp: kiedy rozpocząłem przymiarki do artykułu miesiąc temu, w serwerach dominował PHP 4.3.5-4.3.6.
Jak twierdzą właściciele serwerów, głównym problem z aktualizacjami - PHP 4.3.9 został udostępniony 22 sierpnia 2004 roku! - powodują zmiany w Zend Engine, czyli silniku napędzającym PHP. Niby są one niewielkie, jednak potrafią doprowadzić do załamania skryptów napisanych dla wcześniejszych wersji języka.
