公司使用的Proxy 伺服器是基於Linux系統的,經常會出現一些或多或少的問題。直接影響到使用者正常的Internet訪問。因為是以前的同事做的,再加上,本人一直忙於其它的項目,沒時間去調整,最佳化。前不久,Linux系統突然無法進入GNU/GNOME案頭環境,促使我下定決心重新規劃並部署一台符合當前應用環境需要的Proxy 伺服器系統來。
在部署之前,我們先來看看現有的Proxy 伺服器的系統內容:該Proxy 伺服器採用的是基於Redhat Linux 8.x作業系統的以NCSAR為認證模式的Squid 2.3 Proxy 伺服器。因系統比較陳舊,穩定性有所欠缺,同時還存在以下不足之處:
1. 因Squid配置的問題,系統無法自動釋放Squid的Cache及日誌所佔用磁碟空間,經常會因為磁碟空間不足而導致Squid停止服務,需要人為的去刪除cache及日誌以釋放磁碟空間。
2. 需要在Proxy 伺服器上,為不同的使用者佈建不同的密碼,以前公司職員並不多,倒不是很麻煩,但,隨著公司的發展,職員的數量大幅增加,加重了IT管理員的工作負擔,同時,也非常難以保證與Windows域賬戶的一致知性;
3. 用戶端不能使用AD整合的賬戶認證模式,使用者每次訪問Internet都需要重複的輸入使用者名稱及密碼,大大降低了使用者使用感受。
4. 沒有實現針對不同Internet對象,設定不同的使用者權限;
5. 無法監督使用者訪問Internet的行為,直接影響到公司網路的正常商業行為。
據此,我們不難發現,此Proxy 伺服器需要經常對其進行維護,非常影響IT工作人員的工作效率。從公司現階段的實際情況出發,對Proxy 伺服器的功能重新規劃如下:
1. 能夠在一點條件下,自動回收被Squid佔用的磁碟空間;
2. 利用AD伺服器上的使用者帳號資訊對使用者的身份進行驗證,避免重複的設定使用者資訊;
3. 提供三種使用者權限:
1. 拒絕所有許可權;
2. 允許訪問Internet,但不允許下載視頻、音頻、可執行檔等;
3. 不受限,可訪問任意Internet資源;
4. IT管理員可以查看使用者訪問Internet的日誌,監督使用者訪問Internet的行為;
既然我們的目標已經非常明確了,我們就不再廢話,開始主題吧!
I.系統內容:
1. CentOS 5.0 Linux
2. squid-2.6.STABLE6-4.el5
3. samba-3.0.23c-2.el5.2.0.2
4. sarg-2.2.1-1.el5.rf
5. winbind
6. krb5
II. 修改kerberos 5驗證服務的設定檔(非特殊說明,均工作在root使用者模式下):
執行下列命令:
[root@proxy ~]# vim /etc/krb5.conf
修改後的krb5.conf為:
1[logging]
2 default = FILE:/var/log/krb5libs.log
3 kdc = FILE:/var/log/krb5kdc.log
4 admin_server = FILE:/var/log/kadmind.log
5
6[libdefaults]
7 default_realm = COMPANY.COM #預設的網域名稱(Realm)
8 dns_lookup_realm = false
9 dns_lookup_kdc = false
10 ticket_lifetime = 24h
11 forwardable = yes
12
13[realms]
14 COMPANY.COM = {
15 kdc = adsrv.company.com:88 #此處指定KDC伺服器的名稱或IP地址
16 admin_server = adsrv.company.com:749 #此處指定管理伺服器的名稱或IP地址
17 default_domain = company.com #預設的網域名稱(domain)
18 }
19
20[domain_realm] #domain與realm的對應關係
21 .company.com = COMPANY.COM
22 company.com = COMPANY.COM
23
24[kdc]
25profile = /var/kerberos/krb5kdc/kdc.conf
26
27[appdefaults]
28 pam = {
29 debug = false
30 ticket_lifetime = 36000
31 renew_lifetime = 36000
32 forwardable = true
33 krb4_convert = false
34 }
III. 利用Kinit工具測試krb5的設定是否正確
執行下列命令:
[root@proxy ~]# kinit administrator@COMPANY.COM
提示輸入使用者administrator的密碼,正確輸入密碼之後返回以下資訊:
kinit: NOTICE: ticket renewable lifetime is 1 week
或直接返回到命令列狀態,其它提示資訊均可能是出錯資訊。請務必確認您的Linux系統與Windows網域服務器的時間及時區設定一致,否則將無法正常與活動目錄伺服器正常通訊。
IV. Samba配置
因為我們此處並不涉及到真正的samba伺服器的配置,所以並沒有將整個的配置內容放在這裡,而僅僅只放了架設SquidProxy 伺服器所需要的部分,如下所示:
1[global]
2idmap gid = 10000-20000
3idmap uid = 10000-20000
4password server = 192.168.21.21
5workgroup = COMPANY #域的NetBios名
6os level = 20
7encrypt passwords = yes
8security = ads #設定為Windows活動目錄安全-ADS驗證
9realm = COMPANY.COM #驗證域realm,必須大寫
10winbind use default domain = yes
以上列出來的項目均需要根據實際情況改動。
V. 通過ntlm驗證程式來測試之前所做的配置是否正確
在做測試之前,如必要時,請重新啟動Linux伺服器。不過,你也可以嘗試僅重新啟動samba及winbind服務來達到同樣的目的(呵呵……這得看運氣!):
[root@proxy ~]# service winbind restart
[root@proxy ~]# service smb restart
重啟系統或以上服務之後,執行以下命令:
[root@proxy ~]# ntlm_auth –username=administrator
提示輸入使用者administrator的密碼,正確輸入密碼之後返回以下資訊:
NT_STATUS_OK: NT_STATUS_OK (0x0)
當返回的結果如上面所描述的話,則說明域帳號administrator已經通過了AD的認證。可以開始接下來的工作了。
VI. 配置NSS(Name Service Switch)
NSS是Name Service Switch的縮寫,具體功能請參考維基百科中的解釋http://en.wikipedia.org/wiki/Name_Service_Switch,具體配置如下:
passwd: files winbind
group: files winbind
其它部份無需改變。
VII. Squid的配置
既然是做Proxy 伺服器,Squid的設定當然是重中之重,下面,根據具體實現功能的不同,分別講述Squid的設定:
1. 為Squid配置第三方身分識別驗證程式
1#啟用squid-2.5-ntlmssp做為ntlm驗證模式的輔助協議
2auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
3auth_param ntlm children 5
4auth_param ntlm keep_alive on
5
6#啟用squid-2.5-basic做為基本驗證模式的輔助協議
7auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
8auth_param basic children 5
9auth_param basic realm Squid proxy-caching web server
10auth_param basic credentialsttl 2 hours
11auth_param basic casesensitive off
12
13#下面的這句參數是重點,保證了Squid可以針對不同的使用者組進行不同的存取控制策略
14external_acl_type NT_global_group %LOGIN /usr/lib/squid/wbinfo_group.pl
2. 使用者存取控制清單的設定
1#將AD中的internet全域群組映射到ProxyUsers
2acl ProxyUsers external NT_global_group internet
3#將AD中的nolimitedinternet全域群組映射到noLimited
4acl NoLimited external NT_global_group nolimitedinternet
5#此句保證了所有使用者必須經過身分識別驗證
6acl AuthenticatedUsers proxy_auth REQUIRED
7#定義不允許下載的檔案類型
8acl InvalidFiles urlpath_regex -i \.mp3$ \.avi$ \.rmvb$ \.mpg$ \.rm$ \.wma$ \.wmv$ \.scr$ \.exe$ \.ocx$ \.dll$ \.com$
9#定義不允許訪問的網域名稱及IP地址,其存放於檔案“denyDomain.list”與“denyIP.list”中
10acl denyDomain dstdomain "/etc/squid/denyDomain.list"
11acl denyIP dst "/etc/squid/denyIP.list"
12
13#允許NoLimited使用者訪問任意Internet資源
14http_access allow AuthenticatedUsers NoLimited
15http_access deny denyDomain
16http_access deny denyIP
17http_access deny InvalidFiles
18
19#禁止使用者訪問denyDomain.list以及denyIP.list中的網域名稱及IP地址,並禁止下載InvalidFiles指定的檔案類型
20http_access allow AuthenticatedUsers ProxyUsers
21acl all src 0.0.0.0/0.0.0.0
22acl manager proto cache_object
23acl localhost src 127.0.0.1/255.255.255.255
24acl to_localhost dst 127.0.0.0/8
25acl SSL_ports port 443
26acl Safe_ports port 80 # http
27acl Safe_ports port 21 # ftp
28acl Safe_ports port 443 # https
29acl Safe_ports port 70 # gopher
30acl Safe_ports port 210 # wais
31acl Safe_ports port 1025-65535 # unregistered ports
32acl Safe_ports port 280 # http-mgmt
33acl Safe_ports port 488 # gss-http
34acl Safe_ports port 591 # filemaker
35acl Safe_ports port 777 # multiling http
36acl CONNECT method CONNECT
請注意此配置中的兩條語句的位置。第一條“http_access allow AuthenticatedUsers NoLimited”,第二條“http_access allow AuthenticatedUsers ProxyUsers”,此兩條語句都是將許可權應用到使用者組,但不同的是位置,在Squid的ACL配置語句中,先後順序決定了其許可權的不同。大家一定要多注意,細細去揣摩。
VIII. 更改winbind管道的許可權
一定不能忘記這一點,沒有winbind管道的足夠的許可權,系統是沒辦法對使用者的身份進行驗證的。其命令如下:
[root@proxy ~]# chown –R root:squid /var/cache/samba/winbindd_privileged
[root@proxy ~]# chmod –R 750 /var/cache/samba/winbindd_privileged
IX. 重啟所有相關服務
命令如下:
[root@proxy ~]# service smb restart
[root@proxy ~]# service winbind restart
[root@proxy ~]# service squid restart
到此為止,我們已經成功地完成了squidProxy 伺服器的配置。接下來,我們還需要給予IT管理員查看並監督使用者訪問Internet行為的能力。
X. Sarg的安裝與配置
為了簡單起見,我們直接下載二進位的安裝包,執行下列命令獲得二進位安裝包:
[root@proxy ~]# http://dag.wieers.com/rpm/packages/sarg/sarg-2.2.1-1.el5.rf.i386.rpm
安裝當然更簡單了啦,沒什麼好說的,執行下列命令即可:
[root@proxy ~]# rpm –Uvh sarg-2.2.1-1.el5.rf.i386.rpm
安裝完後,重新啟動一下Apache伺服器當然是再好不過了。