HOWTO: Securely publish internal IIS webserver

[Verwijderd]

HOWTO: Securely publish internal IIS webserver using Apache Proxy

Stel je hebt een Microsoft IIS webserver op je interne netwerk die je bereikbaar wilt maken voor mensen vanaf het Internet. Je kan dit natuurlijk doen door gebruik te maken van de NAT functie in iptables op je LINUX gateway met het volgende commando:

iptables -A PREROUTING -t nat -p tcp -d $EXTIF --dport 80 j DNAT --to 192.168.0.2:80

Deze methode bied echter 2 zeer grote nadelen,...

1. Je IIS webserver staat nu direct gekoppeld aan het Internet via je LINUX gateway, dit houd in dat je IIS webserver ook door hackers en Code-red/NIMDA wormen gehacked kan worden vanwege de 'exploits' die in IIS aanwezig zijn tenzij je je IIS continue up-to-date houd met dat laatste patches, iets wat veel tijd en moeite kost gezien het groot aantal 'exploits' in IIS.

2. Via de NAT mapping open je een poort van het Internet naar je interne netwerk, indien je IIS webserver gehackt word dan kan de hacker via IIS toegang verkrijgen tot andere onderdelen van je interne netwerk via de IIS webserver. Dit kan je overigens voorkomen door de IIS webserver in een DMZ omgeving op je interne netwerk te plaatsen om op die manier te voorkomen dat de IIS server
belangrijke data op je interne netwerk kan benaderen.

Zoals je dus ziet is de NAT mapping naar je interne IIS server nou niet bepaald ideaal te noemen tenzij je een hoop tijd kwijt wilt zijn aan het up-to-date houden van je IIS webserver.

Gelukkig is er een manier om dit anders te doen... Via de Apache webserver.

Apache bied de mogelijkheid om als Proxy server te functioneren, deze functie zullen we gaan gebruiken om Internet gebruiker toegang te verlenen tot data op onze interne webserver.

De Apache webserver zal gaan dienen als 'doorgeefluik' tussen het Internet en ons interne netwerk. Een bezoeker vanaf het Internet maakt verbinding met de Apache webserver, de Apache webserver zal vervolgens de data die de bezoeker opvraagt ophalen bij de interne IIS webserver en vervolgens deze data aan de bezoeker presenteren. Het lijkt voor de bezoeker dus alsof de data van de Apache webserver afkomstig is terwijl de data in feite van de IIS webserver afkomstig is.

In het voorbeeld dat ik nu ga geven publish ik een IIS webserver waarop Outlook Web Access (MS Exchange webmail) draait via de Apache webserver op de LINUX gateway.

- Installatie van Apache op de LINUX gateway.

Download Apache van www.apache.org, zelf heb ik gekozen voor Apache 1.3.24 en niet voor de 2.0 versie, als je dus voor Apache 2.0 kiest dan kan deze HOWTO een klein beetje afwijken.

Zorg ervoor dat je Apache compiled met de Proxy module
./configure --enable-module=proxy --prefix=/usr/local/apache (<- Installeerd Apache in /usr/local/apache)

Na de installatie van Apache moet je je httpd.conf aanpassen.

- Aanpassen HTTPD.CONF

Open httpd.conf en uncomment de volgende regels:

code:

#<IfModule mod_proxy.c>
#    ProxyRequests On

#    <Directory proxy:*>
#     Order deny,allow
#     Deny from all
#     Allow from .your-domain.com
#    </Directory>

#    ProxyVia On

#</IfModule>

Door het aanpassen van de deny,allow regels kan je de toegang tot je Apache proxy regelen.

Nu moeten we de ProxyPass regels toevoegen welke ervoor zorgen dat Apache data van de Interne IIS webserver gaat ophalen:

Voeg de volgende regels toe onder de ProxyVia On regel

ProxyPass /exchange/ http://192.168.50.9/exchange/
ProxyPassReverse /exchange/ http://192.168.50.9/exchange/

Deze 2 regels zorgen ervoor dat de directory /exchange/ word doorgelinkt naar de interne IIS webserver op http://192.168.0.9/exchange/

Dit staat er dus in mijn httpd.conf:

code:

<IfModule mod_proxy.c>
    ProxyRequests On

    <Directory proxy:*>
      Order deny,allow
      Allow from all
    </Directory>

    ProxyVia On

    ProxyPass /exchange/ http://192.168.50.9/exchange/
    ProxyPassReverse /exchange/ http://192.168.50.9/exchange/

</IfModule>

Stel het externe ip adres van je LINUX gateway is 213.53.99.12... Als iemand dan de pagina http://213.53.99.12/exchange/ opent dan krijgt deze persoon de data die op http://192.168.50.9/exchange/ (onze interne IIS webserver) staat te zien.

- Waarschuwingen

Link NOOIT de naar de IIS root directory!!!

bijvoorbeeld:

ProxyPass / http://192.168.50.9/
ProxyPassReverse / http://192.168.50.9/

Alles wat dan binnenkomt op http://213.53.99.12/ zal Apache direct door sturen naar de interne IIS webserver.

Als er een NIMDA worm binnenkomt op de LINUX gateway en de volgende aanval uitoefend:

GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir

Dan zal deze door de Apache gateway deze request doen op de IIS webserver met als gevolg dat je Apache webserver je interne IIS webserver infecteerd met de NIMDA worm.

Wat je wel kan doen is een virtuele directory op de Apache linken aan de interne IIS webserver.

bijvoorbeeld:

ProxyPass /IISrootDIR/ http://192.168.50.9/
ProxyPassReverse /IISrootDIR/ http://192.168.50.9/

http://213.53.99.12/IISrootDIR/ zal je dan toegang geven tot de interne IIS webserver. Met deze methode ben je veilig voor NIMDA aanvallen omdat deze altijd gericht zullen zijn op http://213.53.99.12/ en dus zullen stranden op de Apache webserver.

Als een hacker echter achterkomt dat de directory /IISrootDIR/ naar een IIS webserver leid kan deze echter nog wel handmatig gebruik maken van de 'exploits' in IIS door bijvoorbeeld het volgende commando via telnet uit te voeren:

GET /IISrootDIR/scripts/..%255c../winnt/system32/cmd.exe?/c+dir

Dit word dan doorgestuurd naar http://192.168.50.9/scripts/..%255c../winnt/system32/cmd.exe?/c+dir
en krijgt de hacker de C schijf van de IIS webserver te zien mits de IISwebserver voorzien is van de laatste patches.

Kortom: Link nooit door naar de IIS root directory omdat dan al je werk alsnog voor niks geweest is.

Het is wel veilig om het volgende te doen:

ProxyPass / http://192.168.50.9/IISsubDIR/
ProxyPassReverse / http://192.168.50.9/IISsubDIR/

Als er dan een een NIMDA aanval op de Apache webserver binnenkomt zal deze 'm doorsturen naar de IISsubDIR.

bijvoorbeeld:

GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir

Gaat naar:
http://192.168.50.9/IISsubDIR/scripts/..%255c../winnt/system32/cmd.exe?/c+dir
welke niet bestaat en dus resulteerd in een 404 - Not Found. Op deze manier kan een hacker ook geen gebruik maken van deze exploit.

[Wilke]

Hmmmm, ja, als je een exploit al kent lukt het wel om met een proxy het probleem te omzeilen...je kunt natuurlijk ook de patch(es) van MS installeren of niet

Maar goed, er is IMHO nog een veel betere oplossing mogelijk: om te beginnen geen IIS draaien

[Kettrick]

Op zondag 26 mei 2002 17:55 schreef Wilke het volgende:
Maar goed, er is IMHO nog een veel betere oplossing mogelijk: om te beginnen geen IIS draaien

Dat is helaas niet altijd een oplossing

[Verwijderd]

Hmm, verhaal ziet er goed uit

Zou dit ook kunnen: mijn server draait op www.muhlenbaumer.com . Kan ik nu michiel.muhlenbaumer.com naar mijn pc (intern netwerk) laten verwijzen ?

[Verwijderd]

Ik heb een andere (betere?) oplossing.

code:

NameVirtualHost *

<VirtualHost *>
    ServerAdmin [e-mail]
    ServerName webmail.bedrijf.nl
    ProxyPass / http://webmail.bedrijf.nl/
    ProxyPassReverse / http://webmail.bedrijf.nl/
</VirtualHost>

Vervolgens zet je in de /etc/hosts file webmail.bedrijf.nl --> 192.168.0.x en het werkt als een trein. Zonder dit krijg je van die enorm vage dingen dat de helft niet werkt en dat je steeds weer een loginbox voor je neus krijgt

Op deze manier kun je dus ook meerdere websites hosten door gewoon meerdere virtualhosts aan te maken.

Aantal dingetjes:

- Je moet Exchange SP2 hebben geinstalleerd, anders werken de public folders niet via deze reverse proxy.
- Als je transparante proxy gebruikt in combinatie met dit werkt het niet. Je moet blijven aanmelden...
- Installeer gewoon Squirrelmail en laat die naar het IP van de Exchange server wijzen. Je hebt dan geen contactpersonen/ agenda's, maar dan moet je maar ff afwegen of het de moeite waard is.

[Verwijderd]

Op zondag 26 mei 2002 18:02 schreef CowMike het volgende:
Hmm, verhaal ziet er goed uit

Zou dit ook kunnen: mijn server draait op www.muhlenbaumer.com . Kan ik nu michiel.muhlenbaumer.com naar mijn pc (intern netwerk) laten verwijzen ?

Ja, alleen moet je dan in de DNS michel.muhlenbaumer.com naar je externe IP laten wijzen...dat is een klein beetje jammer

[deadinspace]

Op zondag 26 mei 2002 17:57 schreef RoeLz het volgende:
Dat is helaas niet altijd een oplossing

Hmm, om wat voor reden dan precies niet?
Performance is het probleem iig niet (zeker niet met apache2).

[Verwijderd]

Op zondag 26 mei 2002 19:16 schreef deadinspace het volgende:

[..]

Hmm, om wat voor reden dan precies niet?
Performance is het probleem iig niet (zeker niet met apache2).

Omdat een hoop dingen alleen maar goed werken op IIS (o.a. Outlook Web Access) en omdat je soms ASP moet draaien...

Je kan wel ASP op Apache draaien met mod_asp of ChiliSoft ASP maar mijn ervaring daarmee is dat je ASP pakket af en toe niet helemaal lekker loopt als je niet op IIS draait.

Een hoop software leveranciers maken ASP pakketen en deze zomaar even aanpassen om op Apache te draaien is een no-go omdat je dan je support verliest.

Op werk hebben wij een ASP CRM software pakket dat dus alleen maar goed werkt op IIS, ik heb al eens geprobeerd om het aan de gang te krijgen op Apache met mod_asp en ChiliSoft ASP maar het werkte niet lekker.

Vaak heb je binnen een bedrijf het niet altijd voor het zeggen welke webserver je wilt draaien, dit word altijd bepaald door welke software pakketen er binnen een bedrijf gebruikt worden.

[DJSmiley]

Op zondag 26 mei 2002 18:02 schreef CowMike het volgende:
Hmm, verhaal ziet er goed uit

Zou dit ook kunnen: mijn server draait op www.muhlenbaumer.com . Kan ik nu michiel.muhlenbaumer.com naar mijn pc (intern netwerk) laten verwijzen ?

Yeps,zolang je bij je apache config files kunt.... en je een goeie portmapping maakt.
overigens kun je ook apache -> gekke poort -> je router -> lokale pc prt 80 routen.....
voor als je zelf prt 80 al ingebruik hebt, kun je op die manier voor de buitenwereld toch 80 gebruiken, onder een subdomein.

Ik heb zelf trouwens ellende met proxy en proxyreverse, heb het in gebruik voor MDaemon, alleen snapt die het niet helemaal (Cookies gaan om de zeik)

Met mod_Rewrite kun je hetzelfde bereiken... die ga ik dus binnekort eens proberen.

[Verwijderd]

Op zondag 26 mei 2002 19:12 schreef Felix het volgende:
Ik heb een andere (betere?) oplossing.

code:

NameVirtualHost *

<VirtualHost *>
    ServerAdmin [e-mail]
    ServerName webmail.bedrijf.nl
    ProxyPass / http://webmail.bedrijf.nl/
    ProxyPassReverse / http://webmail.bedrijf.nl/
</VirtualHost>

Zo zou het inderdaad ook heel goed kunnen ja, is min of meer hetzelfde principe...

Dat probleem met dat inloggen heb ik niet, eigenlijk helemaal geen problemen met OWA op deze manier...

[Verwijderd]

[forum=23] -> [forum=10]

Tja, NON-Windows OS speelt wel een erg kleine rol in dit hele verhaal, dat in principe over IIS/Apache gaat.

Als je een bug in de Apache Proxy hebt, dan kun je nog leuke dingen uithalen hoor
Daarnaast is het tegenwoordig mogelijk met iptables om bijvoorbeeld nimda eruit te filteren. Hoe dat moet? Moet je mij niet vragen, aangezien ik al even niet meer al te druk met iptables bezig ben geweest.

Kortom dit gaat voornamelijk om een Windows omgeving, waarin ook een GNU/Linux gateway staat. Daarom staat deze beter in [forum=10]

[Verwijderd]

Op zondag 26 mei 2002 19:13 schreef Felix het volgende:

[..]

Ja, alleen moet je dan in de DNS michel.muhlenbaumer.com naar je externe IP laten wijzen...dat is een klein beetje jammer

Die verwijst al naar mijn externe IP (MyDNS ). Ik zal t ff gaan uittesten

[Verwijderd]

Ok, het werkt