[Apache] reverse proxy: leestekens

[Verwijderd]

Hallo.

Ik heb hier een webapplicatie draaien op een Windows 2000 server in combinatie met IIS 5. Nu is het zo dat deze applicatie aangeboden moet worden op internet. Aangezien ik er niet zo'n voorstander van ben om die machine direct aan internet te hangen had ik het volgende bedacht.

Een Linux machine met Apache welke met behulp van de proxy module van Apache de pagina's bij de Windows 2000 machine haalt en vervolgens aanbiedt op de client.

So far so good en bovenstaande werkt allemaal als een trein. Alleen met leestekens maakt apache er een zooitje van.

een statische html pagina met de volgende inhoud:

code:

<p>Dit werkt wel: &Iuml; &Euml; </p>
<p>Dit werkt niet:Ï Ë </p>

De leestekens werken wel goed zodra ik de pagina direct van de IIS server haal.
Zodra ik de pagina door de linux machine haal werkt de onderste regel (dus zonder ascci notatie) niet. In plaats van de Ï Ë krijg ik 2 vierkantjes.


Iemand enig idee hoe ik apache aan zijn verstand gepeuterd krijg dat hij de onderste regel ook gewoon moet doorgeven zonder het zaakje te vernaggelen?

Stukje httpd.conf:

code:

<VirtualHost 10.1.1.43>
        ServerName test.bedrijf.nl

        ProxyPass / http://webapplicatie.bedrijf.nl/
        ProxyPassReverse / http://10.1.1.101/

        ErrorLog /www/test.bedrijf.nl/logs/error.log
        CustomLog /www/test.bedrijf.nll/logs/access.log common
</VirtualHost>

[ Voor 3% gewijzigd door Verwijderd op 01-11-2004 14:12 ]

[Spider.007]

Klopt de encoding van je pagina's op IIS wel? Met welke browser kijk je momenteel? Staat de encoding van je Apache wel goed?

[Verwijderd]

Spider.007 schreef op 01 november 2004 @ 14:25:
Klopt de encoding van je pagina's op IIS wel? Met welke browser kijk je momenteel? Staat de encoding van je Apache wel goed?

Encoding was het toverwoord.

In mijn apache configuratie stond de "DefaultCharset op UTF-8 Dit heb ik veranderd in UTF-1 en nu werkt alles naar behoren.

[Wilke]

Verwijderd schreef op 01 november 2004 @ 14:10:
Aangezien ik er niet zo'n voorstander van ben om die machine direct aan internet te hangen had ik het volgende bedacht.

Op zich mooi dat het nu werkt (ook via Apache enzo), maar is het misschien niet een handiger oplossing om gewoon een (Linux) firewall tussen die machine en het internet in te zetten (die alleen poort 80 doorlaat)? Want aangezien Apache alle requests gewoon (ongewijzigd?) doorgeeft aan de Windows machine denk ik niet dat je op deze manier veel problemen zult afvangen.

Of herschrijft die Apache proxy-module alle requests voordat hij ze doorgeeft?

[Verwijderd]

Wilke schreef op 01 november 2004 @ 15:08:
[...]

Of herschrijft die Apache proxy-module alle requests voordat hij ze doorgeeft?

Dat is wel de bedoeling. Mbv de rewrite rule wil ik alle illegale urls eruit vissen. (denk aan ../../ etc)

[Wilke]

okee, dan snap ik het ja.

[_JGC_]

Bovenstaande heb ik dus geflikt met een paar windows webservers met Win2K3 en een OpenBSD router ervoor die alles naar squid doorverwees.
Leuk en aardig, maar apache en squid kunnen soms ook doodleuk lek zijn, net als IIS, en dan heb je 2 points of failure: de requests die door squid of apache komen naar IIS kunnen nog steeds exploits bevatten en je stelt jezelf bloot aan apache of squid aanvallen. In principe maak je het probleem alleen maar erger.

Na een dag kwamen er klachten omdat de klanten niet meer hun spul konden uploaden met Frontpage... bleek dat MS een leuk HTTP protocol voor authenticatie heeft ontworpen: NTLM. Zelfs MS Proxy server of MS ISA server kan dat niet proxy'en (het schijnt mogelijk te zijn met een NTLM proxy geval in squid die je vervolgens met samba in een domein hangt, waarbij die NTLM proxy de authenticatie overneemt. erg omslachtig).

De huidige setup is een OpenBSD router die alleen poort 80 ingaand toestaat, dit moet voldoende zijn om een Win2K3 server te beveiligen.

[Verwijderd]

De linux machine staat trouwens in een DMZ zone (De IIS server in het lan). Ik maak trouwens gebruik van alleen Apache (dus geen squid).

Op het moment dat ze mijn Linux machine hacken is er in princiepe niks aan de hand.
De hacker heeft dan de rechten van de gebruiker waar apache onder draait. Daarnaast zit hij in een volledig dichtgetimmerde DMZ zone. (muv die mapping naar de IIS server).

Dus wil de hacker doordringen tot mijn IIS server dan zal ie kennis van 2 OSsen/ webservers moeten hebben.


In jouw situatie hoeft de hacker alleen IIS te exploiten en op poortje 80 een of ander achterdeurtje te installeren. Je Openbsd machine staat dan direct buitenspel (tenzij deze Stateful packet inspection doet).

Zoals ik hierboven al zei staat de IIS server in het lokale LAN dus met NTLM authenticatie problemen zullen we geen problemen hebben en daarbij gebruiken we geen frontpage.

[Verwijderd]

Verwijderd schreef op 01 november 2004 @ 22:14:
De linux machine staat trouwens in een DMZ zone (De IIS server in het lan). Ik maak trouwens gebruik van alleen Apache (dus geen squid).

Op het moment dat ze mijn Linux machine hacken is er in princiepe niks aan de hand.
De hacker heeft dan de rechten van de gebruiker waar apache onder draait. Daarnaast zit hij in een volledig dichtgetimmerde DMZ zone. (muv die mapping naar de IIS server).

Dus wil de hacker doordringen tot mijn IIS server dan zal ie kennis van 2 OSsen/ webservers moeten hebben.


In jouw situatie hoeft de hacker alleen IIS te exploiten en op poortje 80 een of ander achterdeurtje te installeren. Je Openbsd machine staat dan direct buitenspel (tenzij deze Stateful packet inspection doet).

Zoals ik hierboven al zei staat de IIS server in het lokale LAN dus met NTLM authenticatie problemen zullen we geen problemen hebben en daarbij gebruiken we geen frontpage.

Op zich een prima setup met een server in het DMZ en IIS op je LAN. Alleen zit er een denkfout in het verhaal. Je IIS webserver kan nog steeds direct vanaf Internet worden aangevallen als de attack via poort 80 plaatsvindt. Je reverse proxy kan alleen een aantal bekende attacks eruit filteren en de rest wordt ongewijzigd doorgegeven aan je IIS server. Daarnaast zou je een dual-homed proxy server moeten hebben, wat dan tevens ook het enige pad is van in je interne LAN naar buiten. Op deze manier voorkom je dat standaard connectback shells van veel exploits verbinding kunnen maken met hun aanvaller. Meestal maken die gebruik van een hoge UDP poort en dat komt als het goed is niet door je HTTP proxy heen. Tenzij de connectback shell HTTP proxy support heeft, maar dat ben ik nog niet tegengekomen.

Moraal van dit verhaal: De opstelling met de reverse proxy is niet per definitie beter. Application layer attacks zijn nou eenmaal moeilijk te stoppen met firewalls en proxies. Het is misschien zelfs belangrijker om het aantal uitgaande protocollen vanaf de IIS-server zoveel mogelijk te beperken. Maar goed als ze een exploit op je machine kunnen runnen is er tegen de vastberaden aanvaller weinig bestand.

[ Voor 12% gewijzigd door Verwijderd op 01-11-2004 22:59 ]