Apache 一直是世界上使用率排名前三的 Web 服務器軟件。企業使用其構建 Web 應用,從很大程度上都須要對其安全性進行綜合考慮,以保證可以應對拒絕服務攻擊、流量竊聽、數據泄漏等網絡威脅,從而保證企業門戶網站的安全。除了使用業界流行的防火牆、IDS/IPS(入侵檢測系統 / 入侵防護系統)、WAF(Web 應用防火牆)、UTM(統一威脅管理)等外部安全設備對 Apache 服務進行安全防禦外,做爲一種優秀的開源服務器軟件,Apache 自己就具備不少優秀的特性能夠爲服務器管理員提供安全配置,以防範各類網絡攻擊。所以,充分、高效地挖掘 Apache 服務器的自身安全能力也是企業安全工做者一個必備的技能。基於此,本文將經過大量的實例,從服務器安全設置、運行環境安全保障、安全模塊保護、日誌管理等 6 個方面詳細剖析 Apache 服務器的安全防禦要點。html
Web 服務器也稱爲 WWW 服務器或 HTTP 服務器 (HTTP Server),它是 Internet 上最多見也是使用最頻繁的服務器之一,Web 服務器可以爲用戶提供網頁瀏覽、論壇訪問等等服務。linux
因爲用戶在經過 Web 瀏覽器訪問信息資源的過程當中,無須再關心一些技術性的細節,並且界面很是友好,於是 Web 在 Internet 上一推出就獲得了爆炸性的發展。如今 Web 服務器已經成爲 Internet 上最大的計算機羣,Web 文檔之多、連接的網絡之廣,也使人難以想像。所以,Web 服務器軟件的數量也開始增長,Web 服務器軟件市場的競爭也愈來愈激烈。本文所討論的就是一款最經常使用的 Web 服務器軟件—— Apache。算法
Apache 是一個免費的軟件,用戶能夠免費從 Apache 的官方網站下載。任何人均可以參加其組成部分的開發。Apache 容許世界各地的人對其提供新特性。當新代碼提交到 Apache Group 後,Apache Group 對其具體內容進行審查並測試和質量檢查。若是他們滿意,該代碼就會被集成到 Apache 的主要發行版本中。數據庫
Apache 的其餘主要特徵有:apache
支持最新的 HTTP 協議:是最早支持 HTTP1.1 的 Web 服務器之一,其與新的 HTTP 協議徹底兼容,同時與 HTTP1.0、HTTP1.1 向後兼容。Apache 還爲支持新協議作好了準備。編程
簡單而強大的基於文件的配置:該服務器沒有爲管理員提供圖形用戶界面,提供了三個簡單可是功能異常強大的配置文件。用戶能夠根據須要用這三個文件爲所欲爲地完成本身但願的 Apache 配置。瀏覽器
支持通用網關接口(CGI):採用 mod_cgi 模塊支持 CGI。Apache 支持 CGI/1.1 標準,而且提供了一些擴充。安全
支持虛擬主機:是首批既支持 IP 虛擬主機又支持命名虛擬主機的 Web 服務器之一。服務器
支持 HTTP 認證:支持基於 Web 的基本認證。它還有望支持基於消息摘要的認證。cookie
內部集成 Perl:Perl 是 CGI 腳本編程的事實標準。Apache 對 Perl 提供了良好的支持,經過使用其 mod_perl 模塊,還能夠將 Perl 的腳本裝入內存。
集成代理服務器:用戶還能夠選擇 Apache 做爲代理服務器。
支持 SSL:因爲版本法和美國法律在進出口方面的限制,Apache 自己不支持 SSL。可是用戶能夠經過安裝 Apache 的補丁程序集合(Apache-SSL)使得 Apache 支持 SSL。
支持 HTTP Cookie:經過支持 Cookie,能夠對用戶瀏覽 Web 站點進行跟蹤。
通常說來,Apache 服務器主要面臨以下幾種網絡威脅:
使用 HTTP 協議進行的拒絕服務攻擊:攻擊者會經過某些手段使服務器拒絕對 HTIP 應答。這樣會使 Apache 對系統資源(CPU 時間和內存)需求巨增,形成 Apache 系統變慢甚至徹底癱瘓,從而引發 HTTP 服務的中斷或者合法用戶的合法請求得不到及時地響應;
緩衝區溢出攻擊:因爲 Apache 源代碼徹底開放,攻擊者就能夠利用程序編寫的一些缺陷,使程序偏離正常流程。程序使用靜態分配的內存保存請求數據,攻擊者就能夠發送一個超長請求使緩衝區溢出,從而致使緩衝區溢出攻擊;
被攻擊者得到 root 權限,威脅系統安全:因爲 Apache 服務器通常以 root 權限運行,攻擊者經過它得到 root 權限,進而控制整個 Apache 系統;
Apache 服務器與客戶端通訊安全:若是採用明文傳輸,則服務器與客戶端的敏感通訊信息將有可能被黑客或者不法用戶獲取;
因爲 Apache 配置文件設置不當引發的安全問題:惡意者能夠隨意下載或修改刪除系統文件。這主要涉及到對訪問者的內容和權限的限制。
要應對上述這些安全威脅,要從 Apache 服務器端配置、運行環境、通訊鏈路安全保障、安全模塊使用、日誌管理等各方面、全方位的進行保障,下面將進行分門別類的詳細介紹。
通常狀況下,在 Linux 下啓動 Apache 服務器的進程 httpd 須要 root 權限。因爲 root 權限太大,存在許多潛在的對系統的安全威脅。一些管理員爲了安全的緣由,認爲 httpd 服務器不可能沒有安全漏洞,於是更願意使用普通用戶的權限來啓動服務器。http.conf 主配置文件裏面有以下 2 個配置是 Apache 的安全保證,Apache 在啓動以後,就將其自己設置爲這兩個選項設置的用戶和組權限進行運行,這樣就下降了服務器的危險性。
User apache
Group apache
須要特別指出的是:以上 2 個配置在主配置文件裏面是默認選項,當採用 root 用戶身份運行 httpd 進程後,系統將自動將該進程的用戶組和權限改成 apache,這樣,httpd 進程的權限就被限制在 apache 用戶和組範圍內,於是保證了安全。
Apache 服務器的版本號能夠做爲黑客入侵的重要信息進行利用,他們一般在得到版本號後,經過網上搜索針對該版本服務器的漏洞,從而使用相應的技術和工具備針對性的入侵,這也是滲透測試的一個關鍵步驟。所以,爲了不一些沒必要要的麻煩和安全隱患,能夠經過主配置文件 httpd.conf 下的以下兩個選項進行:
(1)ServerTokens:該選項用於控制服務器是否響應來自客戶端的請求,向客戶端輸出服務器系統類型或者相應的內置模塊等重要信息。Red Hat Enterprise Linux 5 操做系統在主配置文件中提供全局默認控制閾值爲 OS,即 ServerTokens OS。它們將向客戶端公開操做系統信息和相關敏感信息,因此保證安全狀況下須要在該選項後使用「ProductOnly」,即 ServerTokens ProductOnly。
(2)ServerSignature:該選項控制由系統生成的頁面(錯誤信息等)。默認狀況下爲 off,即 ServerSignature off,該狀況下不輸出任何頁面信息。另外一狀況爲 on,即 ServerSignature on,該狀況下輸出一行關於版本號等相關信息。安全狀況下應該將其狀態設爲 off。
圖 1 和圖 2 爲安全設定這兩個選項先後正常狀況下和錯誤狀況下的輸出頁面(經過 Rhel5 中的 Mozilla Firefox 瀏覽器訪問 Rhel5 中的 Apache 服務器)的詳細對比。能夠清楚看到,安全設定選項後,能夠充分地向客戶端用戶隱藏 Linux 操做系統信息和 Apache 服務器版本信息。
要從主目錄之外的其餘目錄中進行發佈,就必須建立虛擬目錄。虛擬目錄是一個位於 Apache 的主目錄外的目錄,它不包含在 Apache 的主目錄中,但在訪問 Web 站點的用戶看來,它與位於主目錄中的子目錄是同樣的。每一個虛擬目錄都有一個別名,用戶 Web 瀏覽器中能夠經過此別名來訪問虛擬目錄,如 http:// 服務器 IP 地址 / 別名 / 文件名,就能夠訪問虛擬目錄下面的任何文件了。
使用 Alias 選項能夠建立虛擬目錄。在主配置文件中,Apache 默認已經建立了兩個虛擬目錄。這兩條語句分別創建了「/icons/」和「/manual」兩個虛擬目錄,它們對應的物理路徑分別是「/var/www/icons/」和「/var/www/manual」。在主配置文件中,用戶能夠看到以下配置語句:
Alias /icons/ 「/var/www/icons/」
Alias /manual 「/var/www/manual」
在實際使用過程當中,用戶能夠本身建立虛擬目錄。好比,建立名爲 /user 的虛擬目錄,它所對應的路徑爲上面幾個例子中經常使用的 /var/www/html/rhel5:
Alias /test 「/var/www/html/rhel5″
若是須要對其進行權限設置,能夠加入以下語句:
<Directory 「/var/www/html/rhel5」> AllowOverride None Options Indexes Order allow,deny Allow from all </Directory>
設置該虛擬目錄和目錄權限後,可使用客戶端瀏覽器進行測試驗證,採用別名對該目錄中的文件進行訪問,瀏覽結果如圖 3 所示。
Apache 服務器須要綁定到 80 端口上來監聽請求,而 root 是惟一有這種權限的用戶,隨着攻擊手段和強度的增長,這樣會使服務器受到至關大的威脅,一但被利用緩衝區溢出漏洞,就能夠控制整個系統。爲了進一步提升系統安全性,Linux 內核引入 chroot 機制,chroot 是內核中的一個系統調用,軟件能夠經過調用函數庫的 chroot 函數,來更改某個進程所能見到的根目錄。
chroot 機制即將某軟件運行限制在指定目錄中,保證該軟件只能對該目錄及其子目錄的文件有所動做,從而保證整個服務器的安全。在這種狀況下,即便出現黑客或者不法用戶經過該軟件破壞或被侵入系統,Linux 系統所受的損壞也僅限於該設定的根目錄,而不會影響到整個系統的其餘部分。
將軟件 chroot 化的一個問題是該軟件運行時須要的全部程序、配置文件和庫文件都必須事先安裝到 chroot 目錄中,一般稱這個目錄爲 chroot「監牢」。若是在「監牢」中運行 httpd,那麼用戶根本看不到 Linux 文件系統中那個真正的目錄,從而保證了 Linux 系統的安全。
在使用該技術的時候,通常狀況下須要事先建立目錄,並將守護進程的可執行文件 httpd 複製到其中。同時,因爲 httpd 須要幾個庫文件,因此須要把 httpd 程序依賴的幾個 lib 文件同時也拷貝到同一個目錄下,所以手工完成這一工做是很是麻煩的。幸運的是,用戶能夠經過使用開源的 jail 軟件包來幫助簡化 chroot「監牢」創建的過程,具體步驟以下所示:Jail 官方網站是:http://www.jmcresearch.com/projects/。
首先將其下載,而後執行以下命令進行源代碼包的編譯和安裝:
#tar xzvf jail_1.9a.tar.gz #cd jail/src #make
jail 軟件包提供了幾個 Perl 腳本做爲其核心命令,包括 mkjailenv、addjailuser 和 addjailsw,他們位於解壓後的目錄 jail/bin 中。這幾個命令的基本用途以下所示:
mkjailenv:用於建立 chroot「監牢」目錄,而且從真實文件系統中拷貝基本的軟件環境。
addjailsw:用於從真實文件系統中拷貝二進制可執行文件及其相關的其它文件(包括庫文件、輔助性文件和設備文件)到該「監牢」中。
addjailuser:建立新的 chroot「監牢」用戶。
採用 jail 建立監牢的步驟以下所示;
(1)首先須要中止目前運行的 httpd 服務,而後創建 chroot 目錄,命令以下所示。該命令將 chroot 目錄創建在路徑 /root/chroot/httpd 下:
# service httpd stop # mkjailenv /root/chroot/httpd kjailenv A component of Jail (version 1.9 for linux) http://www.gsyc.inf.uc3m.es/~assman/jail/ Juan M. Casillas <assman@gsyc.inf.uc3m.es> Making chrooted environment into /root/chroot/httpd Doing preinstall() Doing special_devices() Doing gen_template_password() Doing postinstall() Done.
(2)爲「監牢」添加 httpd 程序,命令以下:
# ./addjailsw /root/chroot/httpd/ -P /usr/sbin/httpd addjailsw A component of Jail (version 1.9 for linux) http://www.gsyc.inf.uc3m.es/~assman/jail/ Juan M. Casillas <assman@gsyc.inf.uc3m.es> Guessing /usr/sbin/httpd args(0) Warning: can't create /proc/mounts from the /proc filesystem Done.
在上述過程當中,用戶不須要在乎那些警告信息,由於 jail 會調用 ldd 檢查 httpd 用到的庫文件。而幾乎全部基於共享庫的二進制可執行文件都須要上述的幾個庫文件。
(3)而後,將 httpd 的相關文件拷貝到「監牢」的相關目錄中,命令以下所示:
# mkdir -p /root/chroot/httpd/etc # cp – a /etc/httpd /root/chroot/httpd/etc/ 。。。。。。
添加後的目錄結構以下所示:
# ll 總計 56 drwxr-xr-x 2 root root 4096 03-23 13:44 dev drwxr-xr-x 3 root root 4096 03-23 13:46 etc drwxr-xr-x 2 root root 4096 03-23 13:46 lib drwxr-xr-x 2 root root 4096 03-23 13:46 selinux drwsrwxrwx 2 root root 4096 03-23 13:46 tmp drwxr-xr-x 4 root root 4096 03-23 13:46 usr drwxr-xr-x 3 root root 4096 03-23 13:46 var
(4)從新啓動 httpd,並使用 ps 命令檢查 httpd 進程,發現該進程已經運行在監牢中,以下所示:
# ps -aux | grep httpd Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.7/FAQ root 3546 0.6 0.3 3828 1712 pts/2 S 13:57 0:00 /usr/sbin/nss_pcache off /etc/httpd/alias root 3550 14.2 3.6 49388 17788 ? Rsl 13:57 0:00 /root/chroot/httpd/httpd apache 3559 0.2 1.4 49388 6888 ? S 13:57 0:00 /root/chroot/httpd/httpd apache 3560 0.2 1.4 49388 6888 ? S 13:57 0:00 /root/chroot/httpd/httpd apache 3561 0.2 1.4 49388 6888 ? S 13:57 0:00 /root/chroot/httpd/httpd apache 3562 0.2 1.4 49388 6888 ? S 13:57 0:00 /root/chroot/httpd/httpd apache 3563 0.2 1.4 49388 6888 ? S 13:57 0:00 /root/chroot/httpd/httpd apache 3564 0.2 1.4 49388 6888 ? S 13:57 0:00 /root/chroot/httpd/httpd apache 3565 0.2 1.4 49388 6888 ? S 13:57 0:00 /root/chroot/httpd/httpd apache 3566 0.2 1.4 49388 6888 ? S 13:57 0:00 /root/chroot/httpd/httpd root 3568 0.0 0.1 4124 668 pts/2 R+ 13:57 0:00 grep httpd
Apache 的一個優點即是其靈活的模塊結構,其設計思想也是圍繞模塊(module)概念而展開的。安全模塊是 Apache Server 中的極其重要的組成部分。這些安全模塊負責提供 Apache server 的訪問控制和認證,受權等一系列相當重要的安全服務。
Apache 下有以下幾類與安全相關的模塊:
mod_access 模塊可以根據訪問者的 IP 地址(或域名,主機名等)來控制對 Apache 服務器的訪問,稱之爲基於主機的訪問控制。
mod_auth 模塊用來控制用戶和組的認證受權(Authentication)。用戶名和口令存於純文本文件中。
mod_auth_db 和 mod_auth_dbm 模塊則分別將用戶信息(如名稱、組屬和口令等)存於 Berkeley-DB 及 DBM 型的小型數據庫中,便於管理及提升應用效率。
mod_auth_digest 模塊則採用 MD5 數字簽名的方式來進行用戶的認證,但它相應的須要客戶端的支持。
mod_auth_anon 模塊的功能和 mod_auth 的功能相似,只是它容許匿名登陸,將用戶輸入的 E-mail 地址做爲口令。
mod_ssl 被 Apache 用於支持安全套接字層協議,提供 Internet 上安全交易服務,如電子商務中的一項安全措施。經過對通訊字節流的加密來防止敏感信息的泄漏。可是,Apache 的這種支持是創建在對 Apache 的 API 擴展來實現的,至關於一個外部模塊,經過與第三方程序(如 openssl)的結合提供安全的網上交易支持。
爲了可以使用模塊功能,模塊一般以 DSO(Dynamic Shared Object)的方式構建,用戶應該在 httpd.conf 文件中使用 LoadModule 指令,使得可以在使用前得到模塊的功能。以下爲主配置文件中各個模塊的狀況,開啓安全模塊很是簡單,即去掉在各安全模塊所在行前的「#」符號便可,以下所示:
LoadModule auth_basic_module modules/mod_auth_basic.so LoadModule auth_digest_module modules/mod_auth_digest.so LoadModule authn_file_module modules/mod_authn_file.so LoadModule authn_alias_module modules/mod_authn_alias.so 。。。。。。
只有將上述安全模塊進行開啓後 ,Apache 才能實現相應的訪問控制和通訊加密功能。
在開啓了相應的安全模塊後,還須要對 Apache 的訪問控制策略進行設定。
目前,有兩種常見的認證類型,基本認證和摘要認證:
(1)基本認證(Basic):使用最基本的用戶名和密碼方式進行用戶認證。
(2)摘要認證(Digest):該認證方式比基本認證要安全得多,在認證過程當中額外使用了一個針對客戶端的挑戰(challenge)信息,能夠有效地避免基本認證方式可能遇到的「重放攻擊」。值得注意的是:目前並不是全部的瀏覽器都支持摘要認證方式。
全部的認證配置指令既能夠出如今主配置文件 httpd.conf 中的 Directory 容器中,也能夠出如今單獨的 .htaccess 文件中,這個能夠由用戶靈活地選擇使用。在認證配置過程當中,須要用到以下指令選項:
AuthName:用於定義受保護區域的名稱。
AuthType:用於指定使用的認證方式,包括上面所述的 Basic 和 Digest 兩種方式。
AuthGroupFile:用於指定認證組文件的位置。
AuthUserFile:用戶指定認證口令文件的位置。
使用上述的認證指令配置認證以後,須要爲 Apache 服務器的訪問對象,也就是指定的用戶和組進行相應的受權,以便於他們對 Apache 服務器提供的目錄和文件進行訪問。爲用戶和組進行受權須要使用 Require 指令,它主要可使用以下三種方式進行受權:
受權給指定的一個或者多個用戶:使用 Require user 用戶名 1 用戶名 2 …。
受權給指定的一個或者多個組:使用 Require group 用戶名 1 用戶名 2 …。
受權給指定口令文件中的全部用戶:使用 Require valid-user。
要實現用戶認證功能,首先要創建保存用戶名和口令的文件。Apache 自帶的 htpasswd 命令提供了創建和更新存儲用戶名、密碼的文本文件的功能。須要注意的是,這個文件必須放在不能被網絡訪問的位置,以免被下載和信息泄漏。建議將口令文件放在 /etc/httpd/ 目錄或者其子目錄下。
下面的例子在 /etc/httpd 目錄下建立一個文件名爲 passwd_auth 的口令文件,並將用戶 rhel5 添加入認證口令文件。使用如下命令創建口令文件(過程當中還會提示輸入該用戶的口令):
# touch passwd_auth # htpasswd -c /etc/httpd/passwd_auth rhel5 New password: Re-type new password: Adding password for user rhel5
命令執行的過程當中系統會要求用戶爲 rhel5 用戶輸入密碼。上述命令中的 -c 選項表示不管口令文件是否已經存在,都會從新寫入文件並刪去原有內容。因此在添加第 2 個用戶到口令文件時,就不須要使用 -c 選項了,以下命令所示
# htpasswd /etc/httpd/passwd_auth testuser
配置指令
Apache 實現訪問控制的配置指令包括以下三種:
(1)order 指令:用於指定執行容許訪問控制規則或者拒絕訪問控制規則的順序。order 只能設置爲 Order allow,deny 或 Order deny,allow,分別用來代表用戶先設置容許的訪問地址仍是先設置禁止訪問的地址。Order 選項用於定義缺省的訪問權限與 Allow 和 Deny 語句的處理順序。Allow 和 Deny 語句能夠針對客戶機的域名或 IP 地址進行設置,以決定哪些客戶機可以訪問服務器。Order 語句設置的兩種值的具體含義以下:
allow, deny:缺省禁止全部客戶機的訪問,且 Allow 語句在 Deny 語句以前被匹配。若是某條件既匹配 Deny 語句又匹配 Allow 語句,則 Deny 語句會起做用(由於 Deny 語句覆蓋了 Allow 語句)。
deny, allow:缺省容許全部客戶機的訪問,且 Deny 語句在 Allow 語句以前被匹配。若是某條件既匹配 Deny 語句又匹配 Allow 語句,則 Allow 語句會起做用(由於 Allow 語句覆蓋了 Deny 語句)。
(2)allow 指令:指明容許訪問的地址或地址序列。如 allow from all 指令代表容許全部 IP 來的訪問請求。
(3)deny 指令:指明禁止訪問的地址或地址序列。如 deny from all 指令代表禁止全部 IP 來的訪問請求。
應用實例
下面舉幾個簡單的例子對上述 order、allow 和 deny 命令的使用進行示範。
(1)在下面的例子中,admin.org 域中全部主機都容許訪問網站,而其餘非該域中的任何主機訪問都被拒絕,由於 Deny 在前,Allow 在後,Allow 語句覆蓋了 Deny 語句:
Order Deny,Allow Deny from all Allow from admin.org
(2)下面例子中,admin.org 域中全部主機,除了 db.admin.org 子域包含的主機被拒絕訪問之外,都容許訪問。而全部不在 admin.org 域中的主機都不容許訪問,由於缺省狀態是拒絕對服務器的訪問(Allow 在前,Deny 在後,Deny 語句覆蓋了 Allow 語句):
Order Allow,Deny Allow from admin.org Deny from db.admin.org
使用主配置文件配置用戶認證及受權
在本例子中,用戶能夠在 Apache 的主配置文件 httpd.conf 中加入如下語句創建對目錄 /var/www/html/rhel5 訪問的用戶認證和受權機制:
<Directory "/var/www/html/rhel5"> AllowOverride None AuthType Basic AuthName "rhel5" AuthUserFile /etc/httpd/passwd_auth Require user rhel5 testuser </Directory>
在上述例子中,使用了以下指令:
AllowOverride:該選項定義了不使用 .htaccess 文件。
AuthType Basic:AuthType 選項定義了對用戶實施認證的類型,最經常使用的是由 mod_auth 提供的 Basic。
AuthName:定義了 Web 瀏覽器顯示輸入用戶 / 密碼對話框時的領域內容。
AuthUserFile:定義了口令文件的路徑,即便用 htpasswd 創建的口令文件。
Require user:定義了容許哪些用戶訪問,各用戶之間用空格分開。
須要注意的是:在 AuthUserFile 選項定義中,還須要使用以下語句事先創建認證用戶 patterson 和 testuser,該選項中的定義才能生效:
#htpasswd -c /etc/httpd/passwd_auth rhel5 #htpasswd /etc/httpd/passwd_auth testuser
使用 .htaccess 文件配置用戶認證和受權
在本例子中,爲了完成如上述例子一樣的功能,須要先在主配置文件中加入以下語句:
<Directory 「/var/www/html/rhel5」> AllowOverride AuthConfig </Directory>
上述語句中的 AllowOverride 選項容許在 .htaccess 文件中使用認證和受權指令。、、而後,在 .htaccess 文件中添加以下語句便可:
AuthType Basic AuthName "Please Login:" AuthUserFile /etc/httpd/passwd_auth Require user rhel5 testuser、
同理,在 AuthUserFile 選項定義中,還須要使用以下語句事先創建認證用戶 patterson 和 testuser,該選項中的定義才能生效:
#htpasswd -c /etc/httpd/passwd_auth rhel5
#htpasswd /etc/httpd/passwd_auth testuser
在 SSL 通訊中,首先採用非對稱加密交換信息,使得服務器得到瀏覽器端提供的對稱加密的密鑰,而後利用該密鑰進行通訊過程當中信息的加密和解密。爲了保證消息在傳遞過程當中沒有被篡改,能夠加密 Hash 編碼來確保信息的完整性。服務器數字證書主要頒發給 Web 站點或其餘須要安全鑑別的服務器,證實服務器的身份信息,一樣客戶端數字證書用於證實客戶端的身份。
使用公用密鑰的方式能夠保證數據傳輸沒有問題,但若是瀏覽器客戶訪問的站點被假冒,這也是一個嚴重的安全問題。這個問題不屬於加密自己,而是要保證密鑰自己的正確性問題。要保證所得到的其餘站點公用密鑰爲其正確的密鑰,而非假冒站點的密鑰,就必須經過一個認證機制,能對站點的密鑰進行認證。固然即便沒有通過認證,仍然能夠保證信息傳輸安全,只是客戶不能確信訪問的服務器沒有被假冒。若是不是爲了提供電子商務等方面對安全性要求很高的服務,通常不須要如此嚴格的考慮
。
下面給出使用 SSL 進行通訊的過程(參見圖 4):
(1)客戶端向服務器端發起對話,協商傳送加密算法。例如:對稱加密算法有 DES、RC5,密鑰交換算法有 RSA 和 DH,摘要算法有 MD5 和 SHA。
(2)服務器向客戶端發送服務器數字證書。好比:使用 DES-RSA-MD5 這對組合進行通訊。客戶端能夠驗證服務器的身份,決定是否須要創建通訊。
(3)客戶端向服務器傳送本次對話的密鑰。在檢查服務器的數字證書是否正確,經過 CA 機構頒發的證書驗證了服務器證書的真實有效性以後,客戶端生成利用服務器的公鑰加密的本次對話的密鑰發送給服務器。
(4)服務器用本身的私鑰解密獲取本次通訊的密鑰。
(5)雙方的通訊正式開始。
在通常狀況下,當客戶端是保密信息的傳遞者時,他不須要數字證書驗證本身身份的真實性,如用戶一般使用的網上銀行交易活動,客戶須要將本身的隱祕信息——帳號和密碼發送給銀行,所以銀行的服務器須要安裝數字證書來代表本身身份的有效性,不然將會使得信息泄露。固然,在某些安全性要求極高的 B2B(Business to Business)應用,服務器端也須要對客戶端的身份進行驗證,這時客戶端也須要安裝數字證書以保證通訊時服務器能夠辨別出客戶端的身份,驗證過程相似於服務器身份的驗證過程。另外,在一些電子商務的應用中,可能還會使用到電子簽名,或者爲了信息交換的更加安全,會增長電子簽名和消息校驗碼(MAC)。而在一般狀況下,瀏覽器都會經過交互的方式來完成上述的通訊過程,下面在 Linux 中對 Apache 採用 SSL 也會做詳細地介紹。
安裝 SSL
雖然 Apache 服務器不支持 SSL,但 Apache 服務器有兩個能夠自由使用的支持 SSL 的相關計劃,一個爲 Apache-SSL,它集成了 Apache 服務器和 SSL,另外一個爲 Apache+mod_ssl,它是經過可動態加載的模塊 mod_ssl 來支持 SSL,其中後一個是由前一個分化出的,並因爲使用模塊,易用性很好,所以使用範圍更爲普遍。還有一些基於 Apache 並集成了 SSL 能力的商業 Web 服務器,然而使用這些商業 Web 服務器主要是北美,這是由於在那裏 SSL 使用的公開密鑰的算法具有專利權,不能用於商業目的,其餘的國家沒必要考慮這個專利問題,而能夠自由使用 SSL。
Apache+mod_ssl 依賴於另一個軟件:OpenSSL,它是一個能夠自由使用的 SSL 實現,首先須要安裝這個軟件。用戶能夠從網站 http://www.openssl.org/source/ 上下載 Linux 下 OpenSSL 的最新穩定版本:openssl-1.0.1c.tar.gz。
下載源代碼安裝包後,使用以下的步驟安裝便可:
(1)用 openssl-1.0.1c.tar.gz 軟件包安裝 OpenSSL 以前,首先需要對該軟件包進行解壓縮和解包。用如下命令完成軟件包的解壓縮和解包:
#tar xvfz openssl-1.0.1c.tar.gz
(2)解壓縮後,進入源碼的目錄 openssl-1.0.1c ,並使用配置腳本進行環境的設置。相應的命令爲:
// 改變當前目錄爲 openssl-1.0.1c 目錄 #cd openssl-1.0.1c // 執行該目錄下配置腳本程序 #./configure
(3)在執行 ./configure 以後,配置腳本會自動生成 Makefile。若是在設置的過程當中沒有任何的錯誤,就能夠開始編譯源碼了。相應的命令及其顯示結果以下:
#make & make install
安裝好 OpenSSL 以後,就能夠安裝使用 Apache+mod_ssl 了。然而爲了安裝徹底正確,須要清除原先安裝的 Apache 服務器的其餘版本,而且還要清除全部的設置文件及其缺省設置文件,以免出現安裝問題。最好也刪除 /usr/local/www 目錄(或改名),以便安裝程序能創建正確的初始文檔目錄。若是是一臺沒有安裝過 Apache 服務器的新系統,就能夠忽略這個步驟,而直接安裝 Apache+mod_ssl 了。
啓動和關閉 SSL
啓動和關閉該服務器的命令以下所示:
#apachectl start:啓動 apache。
#apachectl startssl:啓動 apache ssl。
#apachectl stop:中止 apache。
#apachectl restart:從新啓動 apache。
#apachectl status:顯示 apache 的狀態。
#apachectl configtest:測試 httpd.conf 配置是否正確。
# /usr/local/sbin/apachectl startssl
此時使用 start 參數爲僅僅啓動普通 Apache 的 httpd 守護進程,而不啓動其 SSL 能力,而 startssl 才能啓動 Apache 的 SSL 能力。若是以前 Apache 的守護進程正在運行,便須要使用 stop 參數先中止服務器運行。
在採用 OpenSSL 進行 Apache 通訊加密前,須要先產生與加密相關的認證憑證(也就是證書),以下步驟所示:
# openssl genrsa -out apache.key 1024 Generating RSA private key, 1024 bit long modulus ..........................................++++++ .....................++++++ e is 65537 (0x10001) # openssl req -new -key apache.key -out apache.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [GB]:CN State or Province Name (full name) [Berkshire]:China Locality Name (eg, city) [Newbury]:Beijing Organization Name (eg, company) [My Company Ltd]:CSO Organizational Unit Name (eg, section) []:CSO Common Name (eg, your name or your server's hostname) []:localhost Email Address []:CSO@ittf.org.cn Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:apacheserver An optional company name []:apacheserver # openssl x509 -req -days 365 -in apache.csr -signkey apache.key -out apache.crt Signature ok subject=/C=CN/ST=China/L=Beijing/O=CSO/OU=CSO/CN=localhost/emailAddress=CSO@ittf.org.cn Getting Private key
通過上述步驟後,將會產生三個文件 apache.csr, apache.key 和 apache.crt,而後把這三個文件拷貝到 /etc/httpd/conf/ca 目錄下便可。
而後,就能夠啓動 Mozilla、IE 或其餘支持 SSL 的瀏覽器,輸入 URL 爲:https://ssl_server/來查看服務器是否有相應,https 使用的缺省端口爲 443,若是一切正常,服務器將會返回給客戶端證書,由客戶端進行驗證而且判斷,是否接受該證書並進行下一步的通訊過程。
下面以 Linux 下的 Mozilla Firefox 瀏覽器爲例,來簡要說明使用 Apache+SSL 服務器的過程。首先,圖 5 給出了查看和驗證該證書的相關提示;最後,圖 6 則給出了證書驗證成功後,採用 SSL 進行保密傳輸的具體界面示意:
日誌文件是用戶管理和監控 Apache 安全的很是好的第一手資料,它清晰地記錄了客戶端訪問 Apache 服務器資源的每一條記錄,以及在訪問中出現的錯誤信息,能夠這樣說,Apache 能夠記錄 Web 訪問中感興趣的幾乎全部信息。
當運行 Apache 服務器時生成 4 個標準的日誌文件:
錯誤日誌
訪問日誌
傳輸日誌
Cookie 日誌
其中比較常見的是訪問日誌(access_log)和錯誤日誌(error_log),其中傳輸日誌和 cookie 日誌被 Apache 2.0 以上的版本丟棄,因此本文不討論這兩種日誌。固然,若是使用 SSL 服務的話,還可能存在 ssl_access_log、ssl_error_log 和 ssl_request_log 三種日誌文件。
另外,值得注意的是:上述幾種日誌文件若是長度過大,還可能生成注入 access_log.1,error_log.2 等的額外文件,其格式與含義與上述幾種文件相同,只不過系統自動爲其進行命名而已。
Apache 中提供以下 4 條與日誌相關的配置指令:
ErrorLog 指令:用於指定錯誤日誌的存放路徑,使用語法爲:ErrorLog 文件名;
LogLevel:用於指定錯誤日誌的錯誤登記,使用語法爲:Loglevel 等級;
LogFormat:用於爲日誌記錄格式命名,使用語法爲:LogFormat 記錄格式說明字符串 格式稱謂;
CustomLog:用於指定訪問日誌存放路徑和記錄格式,指定訪問日誌由指定的程序生成並指定日誌的記錄格式,使用語法爲:CustomLog 日誌文件名 格式稱謂。
在上述幾個文件當中,除了 error_log 和 ssl_error_log 以外,全部日誌文件以由 CustomLog 和 LogFormat 指令指定的格式生成。這些指令在 httpd.conf 文件中出現。使用 LogFormat 指令能夠定義新的日誌文件格式:
LogFormat 「%h %l %u %t \ 「%> %s %b 「common
假定使用的是 common 日誌格式或者 combined 日誌格式,這兩種格式都在默認的配置文件中定義。表 1 列出了 LogFormat 語句可使用的變量:
表 1. LogFormat 語句的變量
變 量 | 含 義 |
---|---|
%b | 發送字節,不包括 HTTP 標題 |
%f | 文件名 |
%{VARIABLE}e | 環境變量 VARIABLE 的內容 |
%h | 遠程主機 |
%a | 遠程 IP 地址 |
%{HEADER}i | HEADER 內容;發送到服務器的請求的標題行 |
%l | 遠程登陸名(若是提供該值,則從 identd 得到) |
%{NOTE}n | 來自另外一個模塊的 NOTE 通知的內容 |
%{HEADER}o | HEADER 的內容,回覆中的標題行 |
%p | 服務器服務於請求的規範端口 |
%P | 服務於請求的子進程的 ID |
%r | 請求的第一行 |
%s | 狀態。對於內部重定向的請求,該狀態爲初始請求—最後是 %>s |
%t | 時間,格式爲 common 日誌格式中的時間格式 |
%{format}t | 時間,格式由 format 給出。能夠是 strftime(3)格式 |
%T | 服務請求花費的時間,以秒計 |
%u | 來自 auth 的遠程用戶;若是返回的狀態(%s)爲 401 則多是假的 |
%U | 請求的 URL 路徑 |
%v | 服務於該請求的服務器的規範 ServerName |
在每一個變量中,能夠在前面設置一個條件,決定是否顯示該變量。若是不顯示,則顯示 -。這些條件是數值返回值列表的形式。另外,還可使用 CustomLog 指令指定日誌文件的位置和格式。若是沒有指定日誌文件的絕對路徑,則日誌文件的位置假定爲相對於 ServerRoot。下面是 httpd.conf 文件中指定日誌文件的語句:
// // The location and format of the access logfile(Common Logfile Format). // If you do not define any access logfiles within a <VirtualHost> // container, they will be logged here. Contrariwise, if you *do* // define per-<VirtualHost> access logfiles, transactions will be // logged therein and *not* in this file. // CustomLog logs/access_log common ErrorLog logs/error_log
通常說來,Apache 中的錯誤日誌記錄等級有如表 2 所示的八類:
表 2. 錯誤日誌記錄的等級
緊急性 | 等級 | 解釋 |
---|---|---|
1 | Emerg | 出現緊急情況使得系統不可用 |
2 | Alert | 須要當即引發注意的情況 |
3 | Crit | 危險狀況的警告 |
4 | Error | 除上述 3 種狀況以外的其餘錯誤 |
5 | Warn | 警告信息 |
6 | Notice | 須要引發注意的狀況,不如第 4 和第 5 類重要 |
7 | Info | 須要報告的通常消息 |
8 | Debug | 運行於 debug 模式的程序產生的消息 |
另外,在 Apache 中,將訪問日誌分爲以下 4 類:
普通日誌格式(common log format,CLF):大多很多天志分析軟件都支持這種格式,其在 LogFormat 指定中定義的暱稱爲 common;
參考日誌格式(referer log format):記錄客戶訪問站點的用戶身份,其在 LogFormat 指定中定義的暱稱爲 referer;
代理日誌格式(agent log format):記錄請求的用戶代理,其在 LogFormat 指定中定義的暱稱爲 agent;
綜合日誌格式(combined log format):即結合上述三種格式的日誌信息,其在 LogFormat 指定中定義的暱稱爲 combined。
在實際的使用過程當中,因爲綜合日誌格式有效地結合了其餘 3 種日誌格式和信息,因此在配製訪問日誌時,能夠有兩種方式:
(1)分別使用 3 個文件進行分別記錄,相應配置示例以下:
LogFormat 「%h %l %u %t \ 「%r\」 %>s %b」 common LogFormat 「%{Referer}i->%U」 referer LogFormat 「%{Apache User-agent}i」 agent CustomLog logs/access_log common CustomLog logs/referer_log referer CustomLog logs/agent_log agent
(2)使用一個綜合文件進行記錄,相應配置示例以下:
LogFormat 「%h %l %u %t \ 「%r\」 %>s %b \」%{Referer}i\」 \ 「%{Apache User-Agent}i\」」combined CustomLog logs/access_log combined