Apache
縱觀 Apache的漏洞史,它曾經出現過許多次高危漏洞。但這些高危漏洞,大部分是由 Apache的 Module造成的, Apache核心的高危漏洞幾乎沒有。 Apache有很多官方與非官方的 Module,默認啟動的 Module出現過的高危漏洞非常少,大多數的高危漏洞集中在默認沒有安裝或 enable的 Module上。因此,檢Apache安全的第一件事情,就是檢查 Apache的 Module安裝情況,根據“最小權限原則”,應該盡可能地減少不必要的 Module,對於要使用的 Module,,則檢查其對應版
本是否存在已知的安全漏洞。定制好了 Apache的安裝包后,接下來需要做的,就是指定 Apache進程以單獨的用戶身份行,這通常需要為 Apache單獨建立一個 user/group需要注意的是, Apache以rot身份或者 admin身份運行是一個非常糟糕的決定。這里的admin身份是指服務器管理員在管理機器時使用的身份。這個身份的權限也是比較高的,因為管理員有操作管理腳本、訪問配置文件、讀寫日志等需求。
使用高權限身份運行 Apache的結果可能是災難性的,它會帶來兩個可怕的后果:
(1)當黑客入侵Web成功時,將直接獲得一個高權限(比如root或 admin)的shell
(2)應用程序本身將具備較高權限,當出現bug時,可能會帶來較高風險,比如刪除本地重要文件、殺死進程等不可預知的結果
比較好的做法是使用專門的用戶身份運行 Apache,這個用戶身份不應該具備 shell,它唯一的作用就是用來運行Web應用。以什么身份啟動進程,在使用其他Wb容器時也需要注意這個間題,很多P網站的管理員喜歡將 Tomcat配置為root身份運行,導致的后果就是黑客們通過漏洞得到了 webshell后,發現這個 webshell已經具備root權限了
Apache還提供了一些配置參數,可以用來優化服務器的性能,提高對抗DDOS攻擊的能力。我們曾在“應用層拒絕服務攻擊”一章中提到過這些參數:
LimitRequestFieldsize
Limi tRequestline
AcceptFilter
MaxRequestworkers
在 Apache的官方文檔中,對如何使用這些參數給出了指導。這些參數能夠起到一定的作用,但單台機器的性能畢竟有限,所以對抗DDOS不可依賴於這些參數,但聊勝於無。最后,要保護好 Apache Log。一般來說,攻擊者入侵成功后,要做的第一件事情就是清除入侵痕跡,修改、刪除日志文件,因此 access log應當妥善保管,比如實時地發送到遠程的 syslog服務器上。
jBoss遠程命令執行
jBoss是J2EE環境中一個流行的web容器,但是jBos在默認安裝時提供的一些功能卻不太安全,如果配置不得當,則可能直接造成遠程命令執行。由於jBos在默認安裝時會有一個管理后台,叫做 JMX-Console,它提供給管理員一些強大的功能,其中包括配置 MBeans,這同樣也會為黑客們打開方便之門。通過8080端口(默認安裝時會監聽8080端口)訪問/ jmx-console能夠進入到這個管理界面。默認安裝時訪間JMX- Console是沒有任何認證的。
在 JMX-Console中,有多種可以遠程執行命令的方法。最簡單的方式,是通過JMX- Console為黑客大開方便之門,通過簡單的“ Google hacking”,可以在互聯網上找到很多開放了 JMX-Console的網站,其中大多數是存在漏洞的。
因此出於安全防御的目的,在加固時,需要刪除 JMX-Console后台,事實上, jBoss的使用完全可以不依賴於它。要移除 IMX-Console,只需要刪除 jmx-consolewar和 web-console war即可,它們分別位於 SJBOSS HOME/server/all/deploy和 ISJBOSS HOME/server/default/deploy目錄下。使用如下命令刪除
cd SJBOSS HOME
bin/shutdown. sh
mv ./server/all/deploy/imx-consle war jmx-console-all bak
mv ./server/default/deploy/jmx-console war jmx-console. war-default-bak
mv ./server/all/deploy/management/console-mgr. sar/web-console warweb-console-allbak
mv ./server/de fault/deploy/management/console-mgr sar/web-console war
web-console-default bak
bin/run.sh
如果出於業務需要不得不使用 JMX-Console,則應該使用一個強壯的密碼,並且運行JMX-Console的端口不應該面向整個 Internet開放。
Tomcat遠程命令執行
Apache Tomcat與 jBoss一樣,默認也會運行在8080端口。它提供的 Tomcat Manager的作用與 IMX-Console類似,管理員也可以在 Tomcat Manager中部署war包.
但值得慶幸的是, Tomcat Manager布署war包需要有 manager權限,而這一權限是在配置
文件中定義的。一個典型的配置文件如下:
root@enitrogen conf): cat tomcat-users, xml
<?xm1 version='1o' encoding-,utf-8.?>
<ctomcat-users>
<role rolename="tomcat”/>
<role rolename="role1"/>
<user username=" tomcat password=“tomcat" roles="tomcat"/>
<user username="both" password-“tomcat">
<user username="role. password-"tomcatroles="role1"/>
</tomcat-users>
root@ nitrogen conf]#
需要由管理員修改此文件,定義出 manager角色:
<user username="manager" password="! em4n4g3r! e#! roles="manager"/>
但是,像下面這種配置,就存在安全隱患了。
[rootgnitrogen conf]# cat tomcat -users. xml
<?xml version=1.0, encoding='utf-8?>
<tomcat-users>
crole rolename="tomcat"/>
<role rolename=“role1”/>
<role rolename="manager"/>
<user username="tomcat" password="tomcat" roles="tomcat, manager”/>
<user username="both" password="tomcat" roles="tomcat, role1”/>
<user username="rolel' password="tomcat" roles="role1”/>
它直接將 tomcat用戶添加為 manager角色,而 tomcat用戶的密碼很可能是一個默認密碼tomcat，這種配置違背了“最小權限原則”，在 Tomcat后台可以直接上傳war包:Tomcat管理后台上傳war包處
當然也可以通過腳本自動化實現這一切。