<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ??碼云GVP開源項目 12k star Uniapp+ElementUI 功能強大 支持多語言、二開方便! 廣告
                # 安全方面的提示 本文中的提示和技巧有些是針對網絡服務器的建立的,有些是綜合性的,其余的則是針對Apache的。 ## 保持不斷更新和升級 Apache HTTP服務器有一個很好的安全記錄和一個高度關注安全問題的開發社團。但是這仍然不能避免在發行版中存在或大或小的問題。所以知道這個軟件的版本更新和升級補丁是至關重要的。如果你是直接從Apache組織得到Apache HTTP服務器的,我們強烈建議你訂閱[Apache HTTP服務器通告郵件列表](http://httpd.apache.org/lists.html#http-announce)以保證能夠在第一時間得知軟件的版本更新和升級補丁。許多第三方Apache軟件發行版也有類似的服務。 當然,Web服務器出現的問題在絕大多數時候不是由Apache源代碼引起的,而是由附加的代碼、CGI腳本、底層操作系統引起的。因此你必須保持機器上所有軟件的及時更新。 ## ServerRoot目錄的權限 通常,Apache由root用戶啟動,在提供服務時切換為由`User`指令所指定的用戶。正如root所執行的任何命令那樣,你必須保證`ServerRoot`下的文件是受保護的,不允許非root用戶對它修改。不僅文件本身,而且目錄及其父目錄都必須只能由root來改寫。例如,如果將`ServerRoot`指定為`/usr/local/apache` ,則推薦以root身份來建立此目錄,如: ``` mkdir /usr/local/apache cd /usr/local/apache mkdir bin conf logs chown 0 . bin conf logs chgrp 0 . bin conf logs chmod 755 . bin conf logs ``` 這里已經假定了"/"、"/usr"、"/usr/local"只能由root來改寫。在安裝`httpd`可執行文件時,應該確保它也受到了同樣的保護: ``` cp httpd /usr/local/apache/bin chown 0 /usr/local/apache/bin/httpd chgrp 0 /usr/local/apache/bin/httpd chmod 511 /usr/local/apache/bin/httpd ``` 你可以在其中建立htdocs子目錄,該子目錄可以允許其他用戶改寫 -- root不會執行其中任何文件,也不應該在其中建立文件。 如果允許非root用戶對由root執行或讀寫的文件有寫權限,則會危及系統。比如,別人有可能會覆蓋`httpd`可執行文件,那么下一次啟動時,就會執行惡意代碼。如果日志目錄(對非root用戶)是可寫的,別人就有可能用一個指向其他敏感文件的連接來覆蓋日志文件,使那個文件被改寫為雜亂的數據。如果日志文件本身(對非root用戶)是可寫的,別人就可能偽造日志。 ## 服務器端包含 服務器端包含(SSI)會帶來一些潛在的安全隱患。 首先是增加了服務器的負載。Apache必須解析所有允許SSI的文件,而無論其中是否包含SSI指令。雖然增加的負載較小,但是在共享服務器環境中會變得很顯著。 SSI文件與CGI腳本一樣存在風險。使用"exe ccmd"元素,允許SSI的文件可以執行任何CGI腳本,以及由httpd.conf設置的執行Apache的用戶或組所允許執行的任何程序。 有若干方法可以在得到SSI好處的同時提高SSI文件的安全性。 服務器管理員可以使用[關于CGI](#calibre_link-550)中所描述的[suexec](#calibre_link-230) ,以隔離野蠻SSI文件所造成的破壞。 對.html或.htm后綴的文件允許SSI是危險的,尤其是在一個共享的或者高流量的服務器環境中。被允許SSI的文件應該有一個單獨的后綴,比如常規的.shtml ,使服務器的負載保持在最低水平,并使風險管理更容易。 另一個方案是,關閉SSI頁面執行腳本和程序的功能,即在用`Options`指令中,用`IncludesNOEXEC`替換`Includes` 。注意,用戶仍然可以使用 &lt;--#include virtual="..." --&gt;來執行位于`ScriptAlias`指令指定的目錄中的CGI腳本。 ## 關于CGI 首先,你不得不信任CGI程序的作者以及你自己發現CGI中潛在安全漏洞的能力,無論這些漏洞是有預謀的或者僅僅是意外。CGI腳本可以執行web服務器用戶所允許執行的任意系統命令,如果沒有經過仔細的檢查,這可能是極其危險的。 由于所有CGI腳本都以相同的身份執行,所以可能會和其他腳本(有意或無意地)沖突。比如,用戶A憎恨用戶B,因此他就可能寫一個腳本去破壞用戶B的數據庫。[suEXEC](#calibre_link-230)是一個允許腳本以不同的身份運行的程序,它包含在Apache1.2以后的版本中,并被Apache服務器代碼中特殊的掛鉤所調用。還有一種常用的方法是使用[CGIWrap](http://cgiwrap.unixtools.org/) 。 ## 未指定為腳本的CGI 僅在下列情況下,可以考慮允許用戶執行位于任意目錄中的CGI腳本: * 你絕對信任用戶不會寫一些有意無意會使系統遭受攻擊的腳本。 * 你認為安全因素與其他因素相比顯得不那么重要,存在一兩個潛在漏洞也無關緊要。 * 你沒有用戶,而且沒人會來訪問你的服務器。 ## 指定為腳本的CGI 把CGI集中在特定的目錄中,并由管理員決定其中的內容。這樣絕對比使用不作為腳本的CGI來得安全,除非對這些目錄有寫權限的用戶被信任,或者管理員希望對每個CGI腳本/程序進行潛在安全漏洞測試。 大多數站點都選擇這種方案,而不使用未指定為腳本的CGI。 ## 其他動態內容的來源 嵌入在Apache中作為模塊運行的腳本解釋器,比如:mod_php, mod_perl, mod_tcl, mod_python 將會使用和Apache一樣的用戶身份運行(參見`User`指令),所以被這些模塊執行的腳本可能訪問任何Apache服務器能夠訪問的對象。一些腳本引擎可能提供了某些方面的限制,但是最好在假定他們并不存在的前提下做好安全防護。 ## 系統設置的保護 為了得到真正嚴密的保護,應該禁止用戶使用可能導致安全特性被覆蓋的`.htaccess`文件,方法是在服務器配置文件中設置: ``` <Directory /> AllowOverride None </Directory> ``` 使所有目錄無法使用`.htaccess`文件,明確指定可以使用的目錄除外。 ## 默認配置下服務器文件的保護 默認訪問是偶爾會被誤解的Apache特性之一。也就是,除非你采取措施,否則,如果服務器能夠通過標準URL映射規則找到一個文件,那么就可能把它提供給客戶端。比如下例: ``` # cd /; ln -s / public_html Accessing http://localhost/~root/ ``` 它會允許客戶端遍歷整個文件系統。其解決方法是,在服務器配置中增加下列指令: ``` <Directory /> Order Deny,Allow Deny from all </Directory> ``` 這樣,對文件系統的默認訪問被禁止。而對需要訪問的區域,可以增加正確的`Directory`塊,比如: ``` <Directory /usr/users/*/public_html> Order Deny,Allow Allow from all </Directory> <Directory /usr/local/httpd> Order Deny,Allow Allow from all </Directory> ``` 必須特別注意`Location`和`Directory`指令的相互作用,比如,即使`<Directory />`拒絕訪問,`<Location />`指令仍然可能推翻其設置。 還必須留意`UserDir`指令,此設置如果類似"./",則與上述例子有相同的風險。如果你使用的是1.3或更高版本,我們強烈建議在服務器配置文件中包含以下指令: ``` UserDir disabled root ``` ## 觀察日志文件 要了解服務器上發生了什么,就必須檢查[日志文件](#calibre_link-260)。雖然日志文件只是記錄已經發生的事件,但是它會讓你知道服務器遭受的攻擊,并幫助你判斷是否提達到了必要的安全等級。 一些例子: ``` grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log grep "client denied" error_log | tail -n 10 ``` 上例會列出試圖使用[Apache Tomcat Source.JSP Malformed Request Information Disclosure Vulnerability](http://online.securityfocus.com/bid/4876/info/)的攻擊次數。下例會列出最后十個被拒絕的客戶端: ``` [Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com] client denied by server configuration: /usr/local/apache/htdocs/.htpasswd ``` 可見,日志文件只是記錄已經發生的事件,所以,如果客戶端可以訪問`.htpasswd`文件,而且在[訪問日志](#calibre_link-492)中發現類似如下的記錄: ``` foo.bar.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1" ``` 這可能表示服務器配置文件中的下列指令已經被注解了: ``` <Files ~ "^\.ht"> Order allow,deny Deny from all </Files> ```
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看