W

iele standardowo zainstalowanych serwerów WWW obsługiwanych za pomocą Apacza ujawnia zbyt wiele danych umożliwiających przeprowadzenie tzw. ataku banner grabbing należącego do grupy ataków typu fingerprinting. Jeśli chodzi o standardową konfigurację Apacza atak banner grabbing można przeprowadzić bez szczegółowego wgłębiania się w nagłówek HTTP. W przypadku zdezaktualizowanych serwerów może stanowić to pretekst do szybko podjętej decyzji o ataku wymierzonym w wykryte podatności starszej wersji.

Ze względu na fakt, iż wiele serwisów nie posiada dobrze skonfigurowanych stron błędów (korzystają z standardowych szablonów dostarczonych z oprogramowaniem) z reguły, aby uzyskać informację o wersji zainstalowanego serwera WWW wystarczy wywołać adres wybranej strony z przykładowym, błędnym odnośnikiem: http://www.abc.pl/obiektnieistnieje. W odpowiedzi serwera otrzymamy komunikat błędu wraz z danymi zawartymi w stopce strony:

Apache/2.2.9 (Debian) mod_ssl/2.2.9 OpenSSL/0.9.8g

W powyższym przykładzie możemy zauważyć, że informacje te nie tylko zdradzają wersję serwera WWW (Apache/2.2.9), ale również wersje dołączonych do niego modułów (mod_ssl/2.2.9) oraz innego oprogramowania systemowego (OpenSSL/0.9.8g) jak i samą wersję dystrybucji Linuksa (Debian). Przy założeniu, że ten sam serwer skonfigurował już poprawną obsługę stron błędów jego wersja niestety nadal zawarta jest w nagłówku HTTP:

agresor@nfsec:[~]: nc abc.pl 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 21 Mar 2010 10:17:03 GMT
Server: Apache/2.2.9 (Debian) proxy_html/3.0.0 mod_ssl/2.2.9 OpenSSL/0.9.8g
Last-Modified: Mon, 24 Nov 2008 07:56:58 GMT
ETag: "2c016-3c6-45c6abd3ca680"
Accept-Ranges: bytes
Content-Length: 966
Vary: Accept-Encoding
Connection: close
Content-Type: text/html; charset=UTF-8
Content-Language: pl

Ta sama sytuacja odnosi się do przypadku, w którym Apache działa jako reverse proxy. Wówczas udostępniane są nie tylko dane samego serwera pośredniczącego, ale również docelowego:

HTTP/1.1 200 OK
Date: Sun, 21 Mar 2010 10:40:32 GMT
Server: Zope 2.9.5;Zope/(Zope 2.9.5-final, python 2.4.3, linux2) ZServer/1.1 Plone/2.5.1
Content-Type: text/html; charset=utf-8
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 1041
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Language: pl

W powyższym nagłówku zawarte są dane serwera znajdującego się za Apaczem (Zope 2.9.5), oprogramowanie systemowe (python 2.4.3) jak i wersja aplikacji internetowej (Plone/2.5.1). Aby zapobiec zgłaszaniu się Apacza w tak otwarty sposób m.in. również dla standardowych stron z kodem 404 wystarczy odpowiednio ustawić opcję ServerTokens oraz ServerSignature w pliku konfiguracyjnym na wartości:

ServerTokens Prod
ServerSignature Off

Wówczas odpowiedź serwera WWW na błędne żądanie będzie ujęta tylko w postaci:

agresor@nfsec:[~]: nc abc.pl 80
DELETE / HTTP/1.0

HTTP/1.1 405 Method Not Allowed
Date: Sun, 21 Mar 2010 11:58:52 GMT
Server: Apache
Vary: accept-language,accept-charset,Accept-Encoding
Accept-Ranges: bytes
Connection: close
Content-Type: text/html; charset=iso-8859-2
Content-Language: pl
Expires: Sun, 21 Mar 2010 11:58:52 GMT

Niestety sytuacja ta pozostaje bez zmian w stosunku do trybu proxy. W tym celu należy do Apacza załadować moduł umożliwiający kontrolę i modyfikację nagłówków w żądaniach użytkownika i odpowiedziach serwera – mod_headers. Dzięki temu jesteśmy w stanie manipulować poszczególnymi wartościami w nagłówku HTTP, w tym również polem Server. Przykładowy wpis w pliku httpd.conf:

<IfModule mod_headers.c>
    Header set Server NF.sec
</IfModule>

spowoduje zwracanie nagłówków dla serwera ukrytego za Apaczem już w postaci:

HTTP/1.1 200 OK
Date: Sun, 21 Mar 2010 12:23:13 GMT
Server: NF.sec
Content-Type: text/html;charset=utf-8
Content-Language: pl
Set-Cookie: previous_page="http://abc.pl/folder_view"; Path=/
Set-Cookie: current_page="http://abc.pl/folder_view"; Path=/
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 3926
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive

Przedstawionego rozwiązania nie należy traktować jako mechanizmu bezpieczeństwa, gdyż bazuje ono jedynie na czystej metodzie bezpieczeństwa poprzez utajnienie (ang. security through obscurity). Jest to jedynie prosty sposób na uniknięcie ataku typu banner grabbing przeprowadzonego na nasz serwer WWW.

Więcej informacji: mod_headers, ServerTokens, ServerSignature, Apache jako Reverse Proxy