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包处
当然也可以通过脚本自动化实现这一切。