2007.08_Apache jako Reverse Proxy.pdf

Apache

jako Reverse Proxy

Obrona

Radosław Pieczonka

stopień trudności

W środowisku irmowym często można na serwerach

intranetowych znaleźć oprogramowanie potencjalnie podatne

na różnego rodzaju ataki. Co gorsza, zdarza się, iż od

publikacji informacji o dziurze w zabezpieczeniach do wydania

odpowiedniej łatki mija niemało czasu.

OWA ( Outlook Web Access ), wyśmie-

nita aplikacja typu webmail, która staje

się coraz popularniejszym sposobem dostępu

do poczty w środowisku serwerów Microsoft, a

co za tym idzie, znajduje się ona również coraz

częściej na celowniku sieciowych wandali.

Z różnych powodów serwery tego typu apli-

kacji znajdują się często wewnątrz irmowego

intranetu, co stanowi świetne rozwiązanie, o ile

nie zachodzi potrzeba zdalnego dostępu. Z re-

guły jednak, prędzej czy później zachodzi po-

trzeba uzyskania dostępu do aplikacji spoza

sieci lokalnej. Aby zapewnić taki dostęp, nale-

ży rozważyć kilka opcji. Pierwszym z możliwych

rozwiązań jest zestawianie połączeń wirtual-

nych sieci prywatnych, co jednak wymaga m.in.

dodatkowej koniguracji komputerów klienckich,

czego najczęściej chcielibyśmy uniknąć.

Inną możliwością jest kolokacja serwerów

aplikacji w serwerowni zewnętrznego operato-

ra. Istotną zaletą takiego rozwiązania jest brak

konieczności nadzorowania infrastruktury i ser-

werów przez naszego administratora i pozosta-

wienie tych obowiązków pracownikom provide-

ra. Często okazuje się jednak taka opcja mniej

elastyczną, zaś koszta utrzymania takiej infra-

struktury mogą być wyższe niż w przypadku in-

nych rozwiązań. Co ważniejsze, w niektórych

sytuacjach ważne z punktu widzenia polityki

bezpieczeństwa jest przechowywanie wrażli-

wych danych wewnątrz infrastruktury irmy, nie

zaś u zewnętrznego operatora.

Aby pozostawić dane wewnątrz naszej sie-

ci, najczęściej lokalizujemy serwery w streie

zdemilitaryzowanej, tak by pozostały pod naszą

kontrolą, ale jednocześnie były dostępne z In-

ternetu poprzez korporacyjny irewall z iltrowa-

niem pakietów, systemem IPS i innymi zabez-

pieczeniami. Choć w tym wypadku mamy pełną

kontrolę nad serwerami, to samo rozwiązanie z

punktu widzenia sieci nie różni się znacząco od

poprzedniego. Informacje, zarówno w sieci we-

Z artykułu dowiesz się

• czym jest reverse proxy,

• jak skonigurować Apache2 dla reverse proxy,

• jak zabezpieczyć publikowane zasoby.

Co powinieneś wiedzieć

• podstawy koniguracji Apache2.

hakin9 Nr 8/2007

www.hakin9.org

J edną z takich aplikacji jest Microsoft

Bezpieczne publikowanie zasobów intranetowych

Listing 1. Podstawowa koniguracja vhosta w Apache2

tu. Aby to osiągnąć, wykorzystamy

serwer http Apache2 wraz z moduła-

mi mod_proxy i mod_proxy_http . Li-

sting 1 prezentuje podstawową koni-

gurację vhosta dla publikowania we-

wnętrznego serwisu dla klientów łą-

czących się do publicznego serwera.

Przy takiej koniguracji Apache'a

strona http://owa.lan powinna być do-

stępna z Internetu pod adresem http:

//intra.company.com . Trudno jednak

stwierdzić, aby takie rozwiązanie pod-

nosiło w sposób znaczący bezpieczeń-

stwo, co więcej, przy takich ustawie-

niach nadal publikujemy zasoby tylko

jednego wewnętrznego serwera i to

wszystko to, co jest na nim dostępne.

Co możemy zrobić w celu poprawienia

zaprezentowanego reverse proxy?

Przede wszystkim warto nieco

bardziej szczegółowo określić, jakie

zasoby mają być publikowane i pod

jakimi nazwami, zmieńmy więc:

ServerAdmin admin@foo.bar

ServerName intra.company.com

ErrorLog /var/log/apache2/owa.foo.bar-error.log

CustomLog /var/log/apache2/owa.foo.bar-access.log common

ProxyPass / http://owa.lan/

ProxyPassReverse / http://owa.lan/

ProxyRequests Off

Order deny,allow

Allow from all

</Proxy>

</VirtualHost>

wnętrznej, jak i zewnętrznej, przetwa-

rzane są w podobny sposób, serwery

mają publiczne adresy IP czy nazwy

domenowe, a komunikacja szyfrowa-

na poprzez SSL wymaga osobnych

certyikatów dla serwera.

Aby pominąć ograniczenia, ja-

kie stawia przed nami lokowanie

serwerów w streie zdemilitaryzo-

wanej oraz jeśli chcemy w jeszcze

większym stopniu podnieść bez-

pieczeństwo, możemy postawić na

maszynie pełniącej rolę irmowego

irewalla/nata lub na dedykowanym

serwerze w DMZ usługę reverse

proxy. Ten sposób dostępu do zaso-

bów może wydawać sie najtrudniej-

szym i najbardziej zaawansowanym,

jest jednak niezmiernie elastyczny i

daje nam wiele nowych funkcji.

Weźmy jako przykład sytuację,

gdy mamy w sieci serwer Microsoft

Exchange z aplikacją webmail OWA,

intranetowy serwer z webową ba-

zą wiedzy i aplikacją CRM, routing i

NAT realizowany jest na dedykowa-

nym routerze sprzętowym lub linuk-

sowym oraz serwer linuksowy zlo-

kalizowany w streie zdemilitaryzo-

wanej. Tym, co chcielibyśmy osią-

gnąć, jest umożliwienie przeglądania

bazy wiedzy oraz poczty z Internetu

oraz zachowanie dostępu do syste-

mu CRM tylko z sieci lokalnej.

Po pierwsze, musimy umożliwić

serwerowi w DMZ dostęp do intrane-

towych serwerów OWA i bazy wie-

dzy, co w skrócie sprowadza się do:

• ProxyPass/ http://owa.lan/,

• ProxyPassReverse http://owa.lan/.

• utworzenia reguł umożliwiających

dostęp do OWA na MS IIS z IP

serwera w DMZ,

• utworzenia reguł umożliwiających

dostęp do strony bazy wiedzy z IP

serwera w DMZ,

• utworzenie odpowiednich reguł

irewalla i NAT-a, aby umożliwić

ruch pomiędzy wybranymi ser-

werami intranetowymi oraz ser-

werem w DMZ.

na szczegółowy wykaz publikowa-

nych folderów webowych:

• ProxyPass/exchange http://owa.

lan/exchange,

• ProxyPassReverse /exchange

http://owa.lan/exchange,

• ProxyPass /exchweb http://owa.

lan/exchweb,

• ProxyPassReverse /exchweb

http://owa.lan/exchweb,

• ProxyPass /public http://owa.lan/

public,

• ProxyPassReverse /public http://

owa.lan/public,

Jeśli możemy przeglądać zawartość

stron z publicznego serwera, oznacza

to, że czas opublikować je do Interne-

External ISP colocated

Web servers

Direct SSL

secured traffic

Direct SSL

secured traffic

Internet

Intranet

Linux Firewall / NAT

Rysunek 1. Diagram dostępu w wariancie kolokacji

www.hakin9.org

hakin9 Nr 8/2007

Obrona

• ProxyPass /knb http://webserver.

lan/knowledgebase,

• ProxyPassReverse /knb http://

webserver.lan/knowledgebase.

dostępnym serwerze reverse proxy,

mamy możliwość publikacji zasobów

wielu serwerów pod jedną nazwą do-

menową, a co za tym idzie, z wykorzy-

staniem jednego certyikatu dla SSL.

Może to stanowić dla irmy znaczące

udogodnienie oraz skutkować obniże-

niem kosztów utrzymania certyika-

tów nabywanych u komercyjnych do-

stawców. Ciekawym sposobem wyko-

rzystania reverse proxy w kontekście

szyfrowania jest również instalacja po-

jedynczego akceleratora kryptogra-

icznego dla wszystkich serwerów ir-

my, co daje nam możliwość znaczne-

go uproszczenia i optymalizacji infra-

struktury klucza publicznego stosowa-

nej w irmie.

powodem niespodziewanych proble-

mów w wypadku niektórych aplika-

cji webowych. Na przykład w wypad-

ku publikacji wspominanego kilkakrot-

nie Outlook Web Access , koniguracja

domyślna serwera IIS i Exchange po-

woduje drobny, acz przykry problem,

którym jest autentykacja z wykorzy-

staniem NTLM czyli tzw. Windows In-

tegrated Authentication . Zgodnie z oi-

cjalnymi publikacjami Microsoft, auten-

tykacja NTLM authentication nie dzia-

ła poprzez serwery proxy. Po dokład-

niejszym sprawdzeniu okazuje się, iż

działa ona w przeglądarkach, innych

niż Microsoft producentów, takich jak

Mozilla Firefox czy Opera, ale nie funk-

cjonuje, gdy próba otworzenia tej sa-

mej strony wykonywana jest z Internet

Explorera. Wiedząc, gdzie leży pro-

blem, możemy wyłączyć autentyka-

cję opartą o NTLM po stronie serwe-

Ciphered connections

Dzięki powyższej zmianie, dostęp jest

ograniczony jedynie do wybranych

katalogów, zaś zależnie od wywoła-

nego adresu, prezentowana będzie

zawartość odpowiedniego serwera

intranetowego. Warto jednak pamię-

tać o tym, że choć do ruchu wewnątrz

sieci lokalnej mamy zazwyczaj spore

zaufanie, ruch w Internecie to przypa-

dek przeciwny. W związku z tym, po-

wszechną i wskazaną praktyką jest,

by takie połączenia były szyfrowane.

Aby pozostać w zgodzie z ową przy-

jętą procedurą, zaimplementujmy w

naszym rozwiązaniu szyfrowanie po-

przez dodanie wpisów odpowiadają-

cych za SSL do koniguracji serwera:

Specyiczne problemy

Pomimo iż opisywane rozwiązanie

jest bardzo dobre, może stać się ono

DMZ Web servers

Listen 443

oraz

Direct SSL

secured traffic

Direct SSL

secured traffic

NameVirtualHost *:443

Gdy Apache nasłuchuje już na domyśl-

nym porcie HTTPS, możemy zaktuali-

zować naszą konigurację vhosta do

stanu zaprezentowanego w Listingu 2

i Rysunku 1, gdzie korzystamy również

z dyrektywy SSLProxyEngine , któ-

ra umożliwia publikowanie zasobów z

wykorzystaniem protokołu HTTPS.

Jeśli publikowane zasoby ma-

ją być dostępne jedynie dla pracow-

ników irmy oraz innych zaufanych

podmiotów, warto rozważyć imple-

mentację dodatkowej warstwy au-

toryzacji klienta poprzez certyika-

ty. Serwer proxy może wymagać od

przeglądarki klienta przedstawienia

prawidłowego certyikatu, zanim po-

łączenie zostanie ustanowione.

Innym aspektem implementa-

cji mod_proxy jako reverse proxy jest

rozkładanie ruchu pomiędzy serwery

celem równoważenia obciążenia oraz

przeniesienie odpowiedzialności za

szyfrowanie ruchu z serwera aplikacji

na serwer proxy. Gdy publikujemy we-

wnętrzne zasoby HTTP z uruchomio-

nym szyfrowaniem SSL na publicznie

Internet

Intranet

Linux Firewall / NAT

with reverse proxy

and appilcation firewall

HTTP traffic

Rysunek 2. Diagram dostępu w wariancie DMZ

Linux Firewall / NAT

with reverse proxy

and appilcation firewall

Internet

Intranet

SSL

secured traffic

HTTP traffic

LAN Web servers

Rysunek 3. Diagram dostępu przez reverse proxy

hakin9 Nr 8/2007

www.hakin9.org

Bezpieczne publikowanie zasobów intranetowych

ra IIS (w Exchange Management Con-

sole ) lub, jeśli chcemy zachować moż-

liwośc takiej autentykacji w sieci LAN,

możemy za pomocą mod_headers dla

Apache zmodyikować nagłówki tak,

by serwer proxy rozgłaszał jedynie w

podstawowy sposób, jak poniżej:

ikacji każdego fragmentu kodu źró-

dłowego, a często w wypadku za-

mkniętych rozwiązań, nawet do kodu

dostępu. Jeśli w sieci intranet do pew-

nego stopnia można dopuścić takie

zagrożenie, to już w wypadku zaso-

bów publikowanych do Internetu, ko-

nieczne jest, by stosowane rozwiąza-

nia były jak najbezpieczniejsze.

Gdy implementujemy reverse

proxy, nie tylko możemy wykorzystać

je do prostego publikowania z dodat-

kowym zabezpieczeniem w formie

szyfrowania SSL. Dzięki modułowi

mod_security2 możemy utworzyć

całkowicie nową warstwę iltrowania

ruchu dla naszych rozwiązań.

Jednym z najpopularniejszych za-

grożeń, na jakie narażone są aplika-

cje webowe, są ataki wstrzykujące

kod jak SQL injection. Najczęściej po-

wodowane przez niewłaściwą obsłu-

gę zmiennych, mogą zostać załatane

poprzez modyikacje kodu aplikacji.

Wyobraźmy sobie sytuację, w któ-

rej używana jest spora aplikacja we-

bowa, utworzona dłuższy czas temu

i nigdy niemodyikowana. Sporo wy-

darzyło się od czasu, kiedy ją napi-

sano, PHP nie powinno juz np. wyko-

rzystywać zmiennych globalnych ( re-

gister_globals ) do obsługi wywołań

GET/POST; obecnie kładzie się rów-

nież znacznie większy nacisk na bez-

pieczeństwo. Jednak dla stworzonego

kiedyś skomplikowanego oprogramo-

wania, aktualizacja do bieżących stan-

dardów może okazać się koszmarem.

Często zdarza się wręcz, iż lepiej jest

napisać nowy system w miejsce stare-

go, gdyż może to być tańsze od łatania

słabo udokumentowanej aplikacji.

Nawet jeśli zapadnie decyzja o

tworzeniu nowego rozwiązania, nie

stanie sie to w ciągu dni czy nawet ty-

godni, a my nie możemy sobie pozwo-

lić na publiczny dostęp do dziurawego

oprogramowania. Jeśli system jest po-

datny na wstrzykiwanie kodu, łatwo so-

bie wyobrazić jak tragiczne w skutkach

może być wpisanie do przeglądarki w

polu adresu http://company.com/bug-

gy.php?username=jonny;DRO-

P%20TABLE%20users

Aby uniknąć podobnych nad-

użyć, można wykorzystać mod_se-

curity2 do blokowania typowych ata-

ków wstrzykiwania kodu.

Jeśli dana dystrybucja zawiera

bieżącą wersję mod_security2 , mamy

szczęście, jednak w większości wy-

padków konieczna będzie kompilacja i

instalacja tego modułu ze źródeł.

Na szczęście instalacja tego mo-

dułu jest dość prosta, i nie powinna

stanowić żadnego problemu. Poza

instalacją pakietów z odpowiednimi

bibliotekami jak libxml2 , trzeba do-

konać drobnej zmiany w Makeile,

gdzie trzeba prawidłowo zadeklaro-

wać ścieżkę do katalogu instalacji

Apache (np. /usr/share/apache2 De-

bianie), a następnie po prostu wyko-

nać polecenia make i make install .

Po zainstalowaniu modułu mod_

security2 dla Apache2, należy jesz-

cze zmodyikować konigurację ser-

wera, tak by ładował on odpowied-

Header unset WWW-Authenticate

Header set WWW-Authenticate §

"Basic realm=webmail.company.com"

Firewall warstwy aplikacji

W wielu sytuacjach dynamicznie ge-

nerowana zawartość strony przygo-

towywana jest za pomocą PHP, ASP

czy innej podobnej technologii. Roz-

wiązania takie są potencjalnie podat-

ne na pewne rodzaje nadużyć. Nie

zdarza się raczej, by irma dyspono-

wała zasobami koniecznymi do wery-

Listing 2. Koniguracja vhosta z SSL i wybranymi zasobami

ServerAdmin admin@foo.bar

ServerName intra.company.com

ErrorLog /var/log/apache2/ssl-intra.company.com-error.log

CustomLog /var/log/apache2/ssl-intra.company.com-access.log common

SSLEngine on

SSLCertiicateFile /etc/ssl/certs/ssl-cert-intra.company.com.pem

SSLCertiicateKeyFile /etc/ssl/private/ssl-cert-intra.company.com.key

SSLProxyEngine on

ProxyPass /exchange https://owa.lan/exchange

ProxyPassReverse /exchange https://owa.lan/exchange

ProxyPass /exchweb https://owa.lan/exchweb

ProxyPassReverse /exchweb https://owa.lan/exchweb

ProxyPass /public https://owa.lan/public

ProxyPassReverse /public https://owa.lan/public

ProxyPass /knb http://webserver.lan/knowledgebase

ProxyPassReverse /knb http://webserver.lan/knowledgebase

ProxyRequests Off

Order deny,allow

Allow from all

</Proxy>

</VirtualHost>

Listing 3. Skrypt vulnerable.php

This site is vulnerable to javascript injection

if ( ! isset ( $_GET [ 'username' ])) $_GET [ 'username' ] = "no username supplied" ;

echo $_GET [ 'username' ]

Listing 4. Adnotacja włamania w logach bezpieczeństwa

[Thu Apr 12 13:09:21 2007] [error] [client xxx.xxx.xxx.xxx] ModSecurity:

Access denied with code 409 (phase 2). Pattern match "<script" at ARGS:

username. [hostname "company.com"] [uri "/vulnerable.php?username=

noob<script>alert(\\"I%20am%20so%20vulnerable...\\")</script>"]

[unique_id"kiwv4Fdi6FkABAVRAMsABBAAA"]

www.hakin9.org

hakin9 Nr 8/2007

Obrona

Listing 5. Dodane wpisy do

pliku koniguracyjnego Apache2

cRule jest prosta i sprowadza się do

wykonania określonych czynności,

gdy zadeklarowany wzorzec zostanie

wykryty w przychodzącym od klien-

ta wywołaniu. Ekipa odpowiedzialna

za mod_security2 była na tyle miła,

by wraz z kodem źródłowym rozpo-

wszechniać predeiniowany zestaw

reguł. Umieszczone tam wpisy pokry-

wają się z najczęściej spotykanymi w

sieci problemami zabezpieczeń apli-

kacji webowych; intuicyjnie podzie-

lone i dobrze skomentowane, znane

są pod nazwą Core Rule s. Zachęcam

do zapoznania się z zawartością tego

zbioru regułek, gdyż dają one wgląd w

wiele metod ataków na aplikacje we-

bowe oraz wzorców, które pozwalają

tego typu zachowania zidentyikować

i zablokować.

Jak można zauważyć w Core Ru-

le s, każda reguła SecRule może przyj-

mować dwa lub trzy argumenty. Pierw-

szy wskazuje na miejsce, w którym

mamy poszukiwać wzorca, a kolejny to

tenże wzorzec. Jako trzeci, opcjonalny

argument, możemy zadeklarować, ja-

kie działania mają być podjęte w wy-

padku wystąpienia łańcucha znaków

zgodnego z wzorcem – operacja ta bę-

dzie miała pierwszeństwo nad działa-

niami deklarowanymi jako domyślne.

Aby zademonstrować, w jaki

sposób mod_security2 może chro-

nić stronę przed nadużyciem, stwo-

rzymy mały, dziurawy skrypt vulne-

rable.php , który będzie dostępny na

słabo skonigurowanym serwerze,

co w efekcie spowoduje podatność

na atak typu script injection .

Gdy otwieramy taką stronę, mo-

żemy wykorzystać podatność na

wstrzyknięcie kodu javascript poprzez

wklejenie go jako części nazwy użyt-

kownika, jak na przykład:

LoadFile /usr/lib/libxml2.so

LoadModule security2_module §

/usr/lib/apache2/modules/ §

mod_security2.so

LoadModule unique_id_module §

/usr/lib/apache2/modules/ §

mod_unique_id.so

nie pliki, co można najprościej osią-

gnąć poprzez dodanie wpisów, któ-

re przedstawia Listing 5 w odpowied-

nim miejscu plików koniguracyjnych.

mod_unique_id powinien być do-

stępny w domyślnej instalacji Apa-

che2 i jest wymagany do poprawnej

pracy mod_security2 .

Gdy mod_security2 jest już do-

stępny i załadowany do Apache, po-

zostaje włączyć jego obsługę dla całe-

go serwera, wybranych lokalizacji czy

vhostów, w naszym zaś przypadku dla

vhosta odpowiedzialnego za reverse

proxy, do czego służy dyrektywa Se-

cRuleEngine On . Dodatkowo może-

my ustalić, jakie operacje zostaną wy-

konane domyślnie w wypadku wykry-

cia potencjalnego ataku za pomocą

SecDefaultAction . Stwórzmy więc ta-

ką konigurację, która odrzuci poten-

cjalnie szkodliwe wywołania z błędem

409 oraz zaloguje je w celu później-

szej analizy. Możliwe jest również mo-

dyikowanie zachowania iltra dla kon-

kretnych reguł, o czym napiszemy za

chwilę. Warto zdawać sobie sprawę

z faktu, iż mod_security2 domyślnie

wykonuje pewne operacje w celu nie-

dopuszczenia do ukrycia ataku przed

wzorcami wykorzystywanym do je-

go wykrycia. Wywołanie przekazane

przez klienta zostaje doprowadzone

do postaci kanonicznej, usunięte zo-

staną wielokrotne slashe, wskazania

do bieżącego katalogu, a także zde-

kodowane zostaną kody znaków w

URLu, co znacząco ogranicza moż-

liwości obejścia zabezpieczeń.

Najczęściej spotykaną w konigu-

racji mod_security2 dyrektywą jest

SecRule . Za pomocą tych wpisów

tworzymy nasze reguły bezpieczeń-

stwa, które będą wywoływać wcze-

śniej zadeklarowane domyślne za-

chowanie. Idea działania reguł Se-

username=noob<script>alert §

2(”I am so vulnerable...”)</script>,

Czego efekt widać na Rysunku 5.

intr.company.com owa.lan webserver.lan

HTTPS

HTTP

Internet

Intranet

Firewall / Router

Rysunek 4. Diagram dostępu w wariancie reverse proxy w DMZ

Rysunek 5. Przykładowy efekt udanego wstrzyknięcia skryptu

hakin9 Nr 8/2007

www.hakin9.org

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: