安全加固总论

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

在系统上线的过程当中，通常要通过三重检查：主机基线扫描、主机端口扫描、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更新包（这种现像十分常见），又非要更新那只能本身手动编译。但原来的编译参数是什么不知道，编译出来的是否与操做系统相兼容更很差说--连操做系统官方都还没有验证好。说软件包版本扫描对服务器稳定性作出了挑战，最主要的也正在于此。

 

2、漏洞修复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库的程序的漏洞就无法经过白名单进行处理了。