安全加固总论

一、漏洞扫描的种类及其修复方法

在系统上线的过程中，一般要经过三重检查：主机基线扫描、主机端口扫描、web扫描。相应的漏洞我们划归为：主机基线配置漏洞、主机端口漏洞、web应用漏洞。

 

1.1主机基线扫描

1.1.1 主机基线扫描的必要性

虽然基线配置存在于主机内部不能为攻击者直接利用，从定义上不宜称之为“漏洞”；但是如果使用telnet确实存在用户名密码明文传输问题，如果没有超时自动退出登录窗口确实有可能被攻击者利用，所以从影响上称之为“漏洞”也不能说名不副实。所以基线扫描存在的不是有没有必要的问题，而只该是尺度的问题。比如多久超时退出，密码有效期多长，密码长度和复杂度该怎样等等。

 

1.1.2 主机基线配置漏洞的修复方法

主机基线配置漏洞，总的而言就是修改主机配置文件。一般的扫描器给出的html扫描报告都会给出漏洞修复要修改的文件和修改的内容（这也是更推荐修复人员直接看html报告的原因），按给的建议进行操作一般就可以修复相应的漏洞。当然有时扫描器兼顾不到所有操作系统或者没有兼顾到最新版本的操作系统，所以有些时候会有些出入但总体而言问题不大。修复中最大的问题，一是部分漏洞修复修改的文件有重复，如果逐个漏洞按修复建议进行修复，那会有重复工作；二是单个的漏洞修复方法没有考虑全局，如果严格逐个执行漏洞的修复操作可能会有问题，比如要求root不能远程登录主机又要求普通用户不能su到root，如果就这么操作，那么远程就没法使用root了。鉴于这两点，推荐的做法是逐个漏洞写成脚本，然后合并重复项考虑执行后对系统使用的影响进行增减，最后执行脚本即可。

 

1.2 主机端口扫描

1.2.1 主机端口扫描的必要性

端口是主机的门户，所有的网络攻击都要通过端口进行。如果主机不开放任何端口那就可以认为这是一台绝对安全的主机。但一台服务器不可避免要开放端口，不然其本身应没有什么意义。而当服务器一旦开启端口，就必要保证端口的安全性，因为如果端口存在漏洞攻击者就可能通过端口攻击乃至进入、控制系统。端口扫描和端口漏洞修复是保证端口安全性的两大保障。

 

1.2.2 主机端口漏洞的修复方法

主机端口漏洞，“修复”方法一般有四种：一是打补丁或升级软件，从软件代码层面彻底修复漏洞；二是使用白名单，包括防火墙白名单、主机/etc/hosts.deny等文件的白名单及软件自身的白名单三种形式；三是修改和隐藏软件版本号。前边在“修复”这个词上加上了双引号，因为前面三种方法中，只有第一种打补丁/升级方式是真正修复了漏洞。第二种白名单提升的安全性与白名单的数量负相关。在下文中我们会对第三种修改和隐藏版本号这一方式进行讨论，说明其为什么不失为一种修复方式。

 

1.3 web应用扫描

1.3.1 web应用扫描的必要性

web应用扫描并不是对web服务的端口再次进行扫描，也不是对web服务的端口进行更深入的扫描；主机端口扫描和web应用扫描，没有包含关系也没有重合关系。主机端口扫描只是对web所使用的中间件进行了扫描但没有对web中间件之上的web应用进行扫描，web应用扫描是正是对中间件之上的web应用进行扫描。web应用服务是服务器向服户提供服务的主要表现形式，其他的安全其宗旨都靠拢于保障web应用服务的安全，web应用自身的安全性更应进行保障。

 

1.3.2 web应用漏洞的修复方法

web应用漏洞，可以大略分为两种，一种是sql注入、xss和csrf等技术方面的漏洞，另一种是验证码可反复使用等业务交互逻辑方面的漏洞。但不管是哪一类，修复方法都是让程序员修改代码升级应用。一是web应用漏洞一般不归维护人员处理，二是各web漏洞的修复方法随具体存在漏洞的代码的不同而变化没有统一固定的形式，所以这里不多叙述。

 

1.4 软件包版本扫描

1.4.1 软件包版本扫描的非必要性

在最为严格的情况下，还有针对系统软件包的检查，凡是有更新的软件包必须更新到最新版本，不然判定为有漏洞。稳定是服务器操作系统的第一要素，但凡适合作为服务器的操作系统，一般而言都不会采用最新的软件版本。强制所有软件包更新到最新版本换取有限的安全性提升的要求，对服务器稳定性做出了挑战，在总体上有可能会给系统带来更大的安全隐患。反过来，对于修复漏洞而言，大多数软件包并不监听端口（比如curl）或者并没有监听端口（比如未启动的httpd）如果攻击者能利用这些软件包的漏洞那么需要攻击者已经具有了主机的权限，既然已经具有了主机权限攻击者又何必反过来去利用这些漏洞呢。或许也存在可能是攻击者可利用这些漏洞进行权限提升--这里有疑问因为权限提升的前提一般是有一个高权限用户运行了有漏洞的程序然后攻击者通过缓冲区溢出以该用户身份执行命令--这里权当存在这种可能，这带来的利弊策略制定者要进行考量。一般而言不推荐实施这种要求。

 

1.4.2 软件包版本漏洞的修复方法

对于执行者而言只能执行上层的决定，如果软件包版本不是最新这个问题指明必须要处理那也只好处理。从原理上这类扫描就是通过“rpm -qa|grep 包名”然后将包名上的版本号与其最新的版本号相比较看是否一致来判断的。一种办法是，如果该软件包不是必须的可直接用”rpm -e 包名”或“yum erase 包名”将软件包卸载（一定要注意如果上面两个命令执行后提示软件受保护卸载错误那么不要强制卸载，不然系统可能很多命令都执行不了）。第二种方法是将软件更新到最新版本版本，不过要注意iso文件制作的本地yum源是不行的需要到软件源的updates目录下载那才是操作系统官方发布的最新的软件包。

但还有一个问题就是观察发现扫描器并是以软件官方发而的软件为准而不是以操作系统官方updates目录为准。软件官方和操作系统官方经常是有区别的，比如Linux内核的官方是linus团队，他们只发布源代码至于怎么编译、是否与Linux版本完全兼容、打包成rpm或deb或其他格式这些事他们不管；CentOS官方是Redhat，其编译适配CentOS后在updates中发布rpm更新包。问题就在于如果扫描器以软件官方发布的版本为准，而操作系统官方还没有推出该版本的rpm更新包（这种现像十分常见），又非要更新那只能自己手动编译。但原来的编译参数是什么不知道，编译出来的是否与操作系统相兼容更不好说--连操作系统官方都尚未验证好。说软件包版本扫描对服务器稳定性做出了挑战，最主要的也正在于此。

 

二、漏洞修复FAQ

 

2.1 修改和隐藏版本号是否能够提升安全性？

从直观感受上来说是这样的场景：我手上有exp，你只管修改和隐藏版本号，我怎样都可以攻击你。但这个场景其实有一个很大的问题：你怎么知道这台机器是有这个漏洞可以用这个exp？或者从正向提问：现在你是一名渗透测试人员，你如何确定一台机器是否有漏洞、有什么漏洞？渗透测试简而言之就是两种方法：第一种是扫描器，第二种是手工测试。

凡扫描器者其要义就是“匹配特征码”，匹配上了就是有漏洞，没匹配上就是没漏洞。版本号就是扫描器最常使用的特征码，版本匹配上就是有漏洞，版本没匹配上就是没漏洞。如果你用扫描器扫描，我把版本号改了扫描器告诉你没有漏洞，那我是不是骗过你了呢，那我是不是骗过了其他用扫描器的攻击者了呢，那我是不是提高了安全性了呢？

或者你是一名高手，不用扫描器，用手工测试的方式。根据PTES标准，渗透测试可划分为前期交互、信息收集、威胁建模、漏洞分析、渗透攻击、后渗透攻击、报告生成等七个阶段。信息收集根据不同环境可收集的信息很多，但具体到一台要攻击的主机而言，最重要的信息就是开放了哪些端口，是什么服务，服务是什么版本？还是要扯到版本上来，因为漏洞是和版本相关，知道了什么版本你才知道要去检测什么漏洞。如果我隐藏了版本那么你所有漏洞都要测，如果我告诉你一个错误的版本你可能就去测那些不存在的漏洞。而且漏洞的表现经常和主机相关联，经常表现出“异常”，攻击者没看到版本或者版本不对，看到这些异常也可能会判断主机不存在漏洞。

总而言之，修改和隐藏版本号可以欺骗以版本为“特征码”的扫描器，可以增加人工渗透的成本，所以是可以提高系统的安全性。“增加成本”这道理和家里上锁有相似，可以这样讲家里的锁对于真要进你家的开锁高手而言就是形同虚设，但你并不会就不上锁也不会否认上锁提高了安全性。

 

2.2 为什么需要使用修改和隐藏版本号的方式？

无论怎么说，修改和隐藏版本号漏洞总还是在那里的，总是让人不放心，为什么一定要用修改版本号的方式而不是直接修改漏洞。其实防火墙的修复方式也没真正修复漏洞，所以使用修改和隐藏版本号的原因与使用白名单的原因都一样：方便。如果“方便”两个字不能让人觉得值得过牺牲的安全性。那我们来看看如果不用白名单，不用修改和隐藏版本号，而是去升级怎么个“复杂”。

对于开源免费的产品比如tomcat，一般没有单独的补丁修复漏洞就是要下载官方提供的最新版本。从时间纵向而言，tomcat平均每月一版，要真正修复漏洞那就是每个月要重新部署一次，整个企业有多少个tomcat呢；从产品横向而言，常用的就有tomcat、apache等十数种产品，每次推出新版本就升级那是一个旁大的工作量，而且还没考虑升级可能带来的配置变动，以及之前的部署人员的特殊配置带来的种种问题。

对于商业收费的产品比如weblogic，会有单独的补丁包。不需要重新安装软件和部署应用，但是协商启停这一较小的工作，在数量放大下也是一个不小的工作量。

 

2.3 怎么评价白名单修复方式？

相比打补丁升级白名单方式更加方便，相比修改和隐藏版本号方式虽然也没有修复漏洞但没在白名单的ip就不能连接也就无法利用漏洞，所以不失为一种修复方式。

由于白名单提升的安全性与白名单数量负相关，所以从技术角度上讲，白名单应当遵从“最小化”原则，白名单数量应尽可能地少。但从运行平稳角度上讲，白名单应当遵从“最大化”原则，不能确定要不要加入白名单地都需要加入白名单。矛盾的焦点在于难于确定“是不是要加入白名单”，这种无法确定是很常见的，比如一台数据库是我只能说我是在用，但我没法确定你有没有在用他有没有在用，尤其是在老的系统或者经过多次交接的系统。如果白名单只列我给的，导致别的系统出了问题这当如何处理。这是白名单方式存在的一个最大问题。

 

2.4 白名单方式中iptables和/etc/hosts.allow等文件这两种方式有什么区别？

更准确的说法是防火墙和/etc/hosts.allow等文件这两种方式有什么区别，这是我们暂且将防火墙和iptables视为同义。

iptables对什么端口都能限制，而/etc/hosts.allow和/etc/hosts.deny只对使用了libwrap库的服务生效（比如ssh、telnet），对没使用libwrap库的服务不生效（比如httpd）。所以能用iptables就用iptables这样统一一些方便管理。

但是linux才有防火墙，aix和sunos没有防火墙（更准确地说是比较复杂），所以aix和sunos只能用/etc/hosts.allow和/etc/hosts.deny。但这就有一个问题，就是那些在aix或sunos上但又没有使用libwrap库的程序的漏洞就没法通过白名单进行处理了。