[2003] Webserver met ASP dichttimmeren

[Zoetjuh]

Hoi allen,

Momenteel zit ik toch wel met een groot vraagteken. Iemand wil bij ons een ASP pagina gaan draaien (waar ik opzich geen problemen mee heb). Nu is wel het zo dat ik allen niet wil dat die ASP-pagina ook door de rest van die server kan bladeren..

Wanneer ik op een standaard Win2K3 installatie (met ASP) het volgende script uitvoer:

code:

<%
  Dim fso, f, f1, fc, s
  Set fso = Server.CreateObject("scripting.FileSystemObject")

  Set f = fso.GetFolder("..\..\..")
  Set fc = f.SubFolders
  For Each f1 in fc
    Response.Write(f1.name & "<br>")
  Next
%>

Dan krijg ik mijn Root directory listing; wat inhoud dat ASP op die pagina al véél te ver komt. Hij kan dan wel geen mappen aanmaken, maar toch..

Er zijn, zover ik alles begrijp, enkele zaken waarmee ik aan de haal moet. Heb hier ook al een twee daagjes mee lopen spelen, maar zonder success helaas.

• Username en password uit de <processModel> uit de "machine.config"
• Rechten van de ASPNet User (ook al lijkt dit meer een IIS5.0 iets)
• De Identity van de Application pool

Ik heb wel een nieuwe pool aan kunnen maken en heb hier een nieuw account aan kunnen knopen als Identity (M'n nieuwe 'ASP_Secure' user). Ik heb vervolgens (zoals MS aangeeft) enkele "Local Policies" aangepast zodat deze user bepaalde rechten kreeg.

Nu is het helaas dat, wanneer ik de site probeer te kijken, ik een "Service Unavailable" melding krijg en de nieuwe pool die ik had aangemaakt stopt dan ook..

Ik vroeg me af of iemand weet hoe ik m'n IIS6.0 machine dicht kan timmeren...


Zoet

[alt-92]

1) dat soort scripts niet gebruiken
2) parent paths uitzetten
3) op zoek gaan naar wat whitepapers over IIS / Windows 2003 Security.

[Zwelgje]

BackSlash32 schreef op zaterdag 05 maart 2005 @ 01:11:
1) dat soort scripts niet gebruiken
2) parent paths uitzetten
3) op zoek gaan naar wat whitepapers over IIS / Windows 2003 Security.

parent paths staat op een iis6 'by default' uit.. zal iemand wel hebben aangezet voor de migratie van zijn (brakke) site van iis5 naar 6...slecht codeerwerk en ipv je code aan te passen moet de www server worden aangepast

[Verwijderd]

Je was aardig op weg door een nieuwe app pool aan te maken welke draait onder een restricted user account. Nog even met de rechten rommelen en dan gaat dat wel lukken.

Misschien kun je ook overstappen op .NET. Op .NET assemblies kun je namelijk heel uitgebreid rechten zetten d.m.v. code access security.

[Zoetjuh]

Verwijderd schreef op zaterdag 05 maart 2005 @ 10:07:
Je was aardig op weg door een nieuwe app pool aan te maken welke draait onder een restricted user account. Nog even met de rechten rommelen en dan gaat dat wel lukken.

Misschien kun je ook overstappen op .NET. Op .NET assemblies kun je namelijk heel uitgebreid rechten zetten d.m.v. code access security.

Dank voor je reactie Jeroen. Helaas ben ik niet bepaald een ASP/.NET expert, maar weet ik wel dat die lui ook "plain old ASP" gebruiken, dus (als ik alles goed begrijp) moet ik toch wel proberen om het middels die Application Pool (en NTFS-rechten) op te lossen.

Overigens @ BackSlash32
Dit script is een voorbeeldje waarmee ik het een en ander aan het testen ben. Ik weet straks niet wat er allemaal in die code gezet gaat worden, maar ik probeer liever te voorkomen dàt er dingen kunnen gebeuren die ik niet wil, i.p.v. dat ik dat straks moet genezen Verder ja inderdaad, 'Parent Paths' staan standaard uit op IIS6.0 (dus ook bij mij).

PS. De meeste bruikbare whitepages die ik tot nu toe gezien heb vertellen mij hoe IIS6.0 juist secure is (vergeleken met IIS5.0) en geeft aan waarom het wel niet okee is en dat je de Base Analyzer nog kan draaien (al gedaan) en evt de URL-Filter (heb de docs hiervan nagelezen, maar biedt niet de mogelijkheden die ik zoek).

Update:
Heb zojuist de volgende link doorgewerkt; maargoed dit is dus alleen voor ASP.NET? http://msdn.microsoft.com...etsec/html/SecNetHT01.asp

[ Voor 29% gewijzigd door Zoetjuh op 06-03-2005 00:12 ]

[Zoetjuh]

Nougoed, heb de Pool nu wel draaiende (door de identity-user van pool ook aan de IIS_WPG toe te voegen), maar deze heeft alsnog toegang tot de root van de schijf. Nogsteeds geen hele oplossing dus

[alt-92]

ACLs vergeten zeker.

[gorgi_19]

Username en password uit de uit de "machine.config"

Afaik heeft dit sowieso geen nut, aangezien die directive specifiek is voor ASP.Net-account en het ASP / IIS account daar niets mee doet.

[Verwijderd]

Volgens mij moet dit volledig met ACL's (Access Control Lists) te regelen zijn: je server gebruikt een speciaal account om ASP mee te laten werken. Deny toegang(srechten) voor al je schijven en daarmee directories, behalve waar dergelijke scripten wel "mogen komen". Probeert een script in een directory te lezen/schijven/eigenschappen op te vragen waar jij een deny op gezet hebt, dan krijgt de gebruiker (programmeur tijdens het testen van het script) een access denied foutmelding.

[alt-92]

Dat is ook wat er in diverse Best Practices en security whitepapers staat (die TS zegt gelezen te hebben).

[Zoetjuh]

Verwijderd schreef op zondag 06 maart 2005 @ 23:52:
Volgens mij moet dit volledig met ACL's (Access Control Lists) te regelen zijn: je server gebruikt een speciaal account om ASP mee te laten werken. Deny toegang(srechten) voor al je schijven en daarmee directories, behalve waar dergelijke scripten wel "mogen komen". Probeert een script in een directory te lezen/schijven/eigenschappen op te vragen waar jij een deny op gezet hebt, dan krijgt de gebruiker (programmeur tijdens het testen van het script) een access denied foutmelding.

Ik ben bang dat je het hier over het ASPNET account hebt? Dat is het enige 'niet-compleet-IIS-geldende' account waarvan ik me kan bedenken dat je die bedoeld. Voor zover ik tot nu toe heb kunnen testen, zal dat account alleen voor .NET werken (wanneer ik dat account aan de Application Pool toewijs).

Wel ben ik inderdaad verder eens aan de slag gegaan met het denyen voor het IIS_<PC> account. Dit werkt inderdaad wel. Wel is het zo dat ik dan, om alles echt netjes dicht te gooien, ALLE mappen op een DENY moet gooein voor dat account. Momenteel:

- C:\Windows -> Complete Deny voor IIS_<PC>
- C:\Windows\System32 -> Complete Deny voor IIS_<PC>

Vervelende is alleen dat de System32\Drivers gewoon nogsteeds te listen is.. Is er misschien een commando om op iedere map een ACL aan te passen; zodat de IIS_<PC> dus gedenied wordt? Dan zet de rechten wel weer goed voor die paar mappen waar deze wel bij mag. Gebruik maken van "Reset on Folders/Subfolders"-etc is uiteraard géén goed idee, dus was benieuwd of hier andere methoden voor zijn.

[Zoetjuh]

BackSlash32 schreef op maandag 07 maart 2005 @ 00:03:
Dat is ook wat er in diverse Best Practices en security whitepapers staat (die TS zegt gelezen te hebben).

Heb je misschien een linkje naar die Best Practices die je bedoelt? Ik heb absoluut het een en ander aan docu gelezen, maar 90% slaat op ASP.NET (en niet op ASP) en/of IIS5.0 (en dus niet 6.0)

[ Voor 4% gewijzigd door Zoetjuh op 07-03-2005 08:39 ]

[Verwijderd]

met welk account vraag je die code op? als integrated authentication aanstaat kan je best wel een onderwater een ander account gebruiken (impersonate privilege). zorg dat alleen "anonymous" aanstaat als je test...