新建立一個站，采用默認向導，在設置中注意以下幾個地方：

在應用程序設置里：執行權限為默認的純腳本，應用程序池使用獨立的名為：315safe的程序池。

名為315safe的應用程序池可以適當設置下"內存回收"：這里的最大虛擬內存為：1000M，最大使用的物理內存為256M，這樣的設置幾乎是沒限制這個站點的性能的。



在應用程序池里有個"標識"選項，可以選擇應用程序池的安全性帳戶，默認才用網絡服務這個帳戶，大家就不要動它，能盡量以最低權限去運行大，隱患也就更小些。在一個站點的某些目錄里，譬如這個"uploadfile"目錄，不需要在里面運行asp程序或其他腳本的，就去掉這個目錄的執行腳本程序權限，在"應用程序設置"的"執行權限"這里，默認的是"純腳本"，我們改成"無"，這樣就只能使用靜態頁面了。依次類推，大凡是不需要asp運行的目錄，譬如數據庫目錄，圖片目錄等等里都可以這樣做，這樣主要是能避免在站點應用程序腳本出現bug的時候，譬如出現從前流行的upfile漏洞，而能夠在一定程度上對漏洞有扼制的作用。

在默認情況下，我們一般給每個站點的web目錄的權限為IIS用戶的讀取和寫入，如圖：



但是我們現在為了將SQL注入，上傳漏洞全部都趕走，我們可以采取手動的方式進行細節性的策略設置。

1． 給web根目錄的IIS用戶只給讀權限。如圖：

然后我們對響應的uploadfiles/或其他需要存在上傳文件的目錄額外給寫的權限，并且在IIS里給這個目錄無腳本運行權限，這樣即使網站程序出現漏洞，入侵者也無法將asp木馬寫進目錄里去，呵呵， 不過沒這么簡單就防止住了攻擊，還有很多工作要完成。如果是MS-SQL數據庫的，就這樣也就OK了，但是Access的數據庫的話，其數據庫所在的目錄，或數據庫文件也得給寫權限，然后數據庫文件沒必要改成.asp的。這樣的后果大家也都知道了把，一旦你的數據庫路徑被暴露了，這個數據庫就是一個大木馬，夠可怕的。其實完全還是規矩點只用mdb后綴，這個目錄在IIS里不給執行腳本權限。然后在IIS里加設置一個映射規律，如圖：





這里用任意一個dll文件來解析.mdb后綴名的映射，只要不用asp.dll來解析就可以了，這樣別人即使獲得了數據庫路徑也無法下載。這個方法可以說是防止數據庫被下載的終極解決辦法了。