Paweł Goleń, blog

Pierwsza kwestia to szyfrowany dostęp do konta, tak, by hasło nie było przesyłane w formie jawnej. Najlepiej, jeśli szyfrowane jest całość sesji, czyli również połączenia, w których przesyłane są pliki, minimum to uwierzytelnienie przez bezpieczny, szyfrowany kanał. Skoro hasło nie jest przesyłane w formie jawnej, warto zadbać by nie było również trywialne do złamania/odgadnięcia, czyli mówiąc wprost - hasło powinno być złożone i unikalne. Po raz kolejny polecam narzędzia do zarządzania hasłami, na przykład KeePass i po raz kolejny przyznaję się, że większości swoich haseł po prostu nie znam (luźna uwaga - w takiej sytuacji warto utrzymywać kilka aktualnych kopii bazy haseł). Jeśli to jest możliwe, konto z dostępem do modyfikacji plików powinno być wyłączane, jeśli jest nieużywane.

W ostatnim czasie można obserwować wzmożone(?) przypadki "iframe injection", czyli po prostu dopisania do strony fragmentu kodu, który próbuje robić złe rzeczy (np. infekować odwiedzających malware), a że często jest to jakiś iframe stąd nazwa, choć moim zdaniem niezbyt szczęśliwa. W wielu przypadkach scenariusz takiego ataku wyglądał w ten sam sposób - komputer użytkownika został zawirusowany, wirus odczytał hasła zapisane w plikach konfiguracyjnych klientów FTP (np. w TotalCommander) i wykorzystał je do modyfikacji plików znajdujących się na serwerach FTP. Przed tego typu atakami można się bronić w prosty sposób - nie zapamiętywać haseł w programach, nawet jeśli plik konfiguracyjny jest szyfrowany (co w zasadzie jest fikcją). Oczywiście warto zadbać o to, by komputer był czysty (bez malware), ale to już zupełnie inny temat.

Warto stosować minimalne uprawnienia na plikach, czyli na przykład zdejmować prawo do zapisu na plikach po ich umieszczeniu na serwerze. Zdejmując prawa do zapisu na plikach i katalogach, ogranicza się powierzchnię ataku. Na przykład wspominany wcześniej wirus może "zgłupieć" jeśli nie będzie mógł zapisywać/modyfikować plików na serwerze FTP. Oczywiście w przyszłości autorzy wirusów mogą dopisać w swoich programach krok zmiany uprawnień (nadania prawa do zapisu do katalogu/pliku), jednak póki co ten prosty krok podnosi nieco poprzeczkę. Jest to praktyczne wykorzystanie zasady minimalnych uprawnień (przywilejów), a przy okazji wpasowuje się w podejście defence-in-depth.

Jeśli istnieją możliwości konfiguracji, warto wyłączyć automatyczne tworzenie indeksów katalogów. Warto również zadbać, a w zasadzie utrudnić lub uniemożliwić, o dostęp do serwisu "z boku". O co chodzi? W wielu wypadkach na jednym serwerze wirtualnym można utrzymywać wiele domen (różnych stron, aplikacji). Często poszczególne domeny są przekierowywane na określone katalogi w katalogu głównym (w niektórych przypadkach stosowany jest nawet chroot, dzięki czemu aplikacja nie może "wyjść" w górę poza swój katalog). Rozdzielenie różnych serwisów między różne (najlepiej jeśli odseparowane od siebie przez mechanizm chroot) katalogi jest dobrą praktyką, ale istnieje jeszcze ten "katalog główny", do którego również można się dostać. Co więcej - zwykle można się za jego pośrednictwem dostać również do podkatalogów, w których znajdują się inne serwisy. W szczególnych przypadkach konfiguracja serwera stosowana w przypadku dostępu za pośrednictwem "katalogu głównego" jest inna, niż dostęp bezpośredni do katalogu, co może prowadzić do wielu ciekawych dla znalazcy, a niezbyt pożądanych dla właściciela serwisu, odkryć. Dlatego warto zablokować dostęp do katalogu głównego (przez plik .htaccess). W ten sam sposób warto zablokować dostęp do katalogów, w których przechowywane są dane, do których użytkownicy nie mają bezpośrednio dostępu, lecz uzyskują do nich dostęp za pośrednictwem aplikacji. W szczególności mogą to być pliki różnego rodzaju rozszerzeń. W "normalnej" sytuacji tego typu zasoby powinny znaleźć się poza rootem serwera WWW, w przypadku hostingów ograniczenie dostępu do takich "specjalnych" katalogów może być jedynym możliwym do zrealizowania rozwiązaniem.

Ograniczenie dostępu do serwisu według zasady default deny może być również dobrym pomysłem, choć nie ukrywam, że często pracochłonnym i nie zawsze opłacalnym. Po prostu najpierw odmawia się dostępu do wszystkich zasobów dla wszystkich użytkowników, a później zezwala na dostęp tylko do tych zasobów, które są niezbędne (a przynajmniej do niezbędnych katalogów i typów plików). Ustalenie listy niezbędnych zasobów może być zrealizowane na przykład przy pomocy narzędzia Burp i wbudowanego w niego spidera (zarówno aktywnego, jak i pasywnego).

Na koniec kwestia monitorowania zmian. Tu również możliwości są ograniczone, ponieważ serwer znajduje się poza naszą kontrolą, a intruz, który przejmie konto, może skutecznie zmodyfikować działanie własnych skryptów weryfikacji integralności plików. Z drugiej strony ręczne sprawdzanie plików jest niezbyt efektywnym rozwiązaniem. Sam napisałem skrypt, który zwraca w postaci XML listę wszystkich plików na serwerze wraz z ich sha1. Dane te są okresowo pobierane przez drugi skrypt uruchamiany już w kontrolowanym przeze mnie środowisku i zapisywane w bazie danych. Następnie tworzony jest raport zawierający listę nowych, usuniętych oraz zmodyfikowanych plików. Do ręcznego sprawdzenia pozostaje tylko ten skrypt.