


Apache HTTP Web服务器保持安全的秘诀
Apache HTTP服务器是世界上最常见的Web服务器软件,这点是明摆着的。据最近一项调查显示,全世界运行Apache HTTP的网站数量超过4.2亿个。鉴于数字如此惊人,我们自然很好奇地想了解Apache背后的更多详情。
我们Pingdom网站的人员都是Apache HTTP Web服务器的拥趸,因为我们用它来运行我们的主网站Pingdom.com。所以我们逮住机会、兴致勃勃地采访William A. Rowe Jr。也就不足为奇了,前不久他还在完全志愿者组成的Apache软件基金会担任HTTP服务器项目副总裁一职。他在近12年一直效力于Apache软件基金会,担任过不同岗位,包括2007年至2009年任职基金会董事。
一种错误的想法:开源不大安全
首先,我们向Bill(注:William的昵称)抛出了人们通常所持的这个想法:由于在Apache HTTP服务器等开源项目中,源代码向公众开放,所以这意味着开源不大安全。这种观点认为,实际上,谁要是想钻运行开源软件的系统的空子,只要查看代码,就能弄清楚如何闯入进去。另一方面,闭源软件天生要来得更安全,因为代码不是谁都可以随随便便查看的。
Bill答复:“很显然,这是一种错误的认识。”
他继续说:“公开披露自己的部分源代码,这其实是像微软这些闭源产品开发公司最不担心的。它们更加担心的是有人用间谍手段刺探源代码,或者通过渗透测试发现软件缺陷(bug);这种情况下,它们不知道自己的源代码在接受审查。”
他解释,如今,针对软件的安全审查在很大程度上实现了自动化。Bill说:“谁都可以进行这样的审查;由于审查是自动化的,所以可以重现。”
Apache HTTP服务器用户社区经常被邀请进行这样的审查,自动扫描代码,一旦发现了异常,就提醒相应的项目组。发现的异常有可能是明确的安全漏洞,也可能不是明确的安全漏洞,但是应予以关注,因为它可能会成为一个明确的安全漏洞。
Bill的观点是,黑客针对二进制代码做这样的事不是重大问题,无论二进制代码是用闭源代码编写的,还是用开源代码编写的。他表示,简而言之,坏人在继续捣鼓闭源产品,正如他们在以同样的手法捣鼓开源产品。
针对逆向工程和反编译等方面的牢骚在安全领域其实算不得什么
他补充说:“针对逆向工程和反编译等方面的牢骚在安全领域其实算不得什么;实际上,对研究安全人员来说只会适得其反。安全研究人员在努力化解问题。要是没有源代码,也就缺乏必要的透明度了,那样他们无法搞清楚可以采取什么化解措施,一开始就避免问题,或者无法搞清楚他们已经发现的漏洞有什么样的实际影响。”
你可能会认为,Bill为其中一个比较知名的开源软件项目工作了这么久,其立场肯定会偏袒一方。别犯想当然的毛病,那样很容易摈弃他的观点。
他的观点是,闭源软件实际上妨碍了安全研究人员了解安全漏洞的范围。Bill表示,如何找出安全漏洞在开源与闭源之间区别不是很大。这往往就是这个过程:建立任意模式,然后看看会不会引起未预期的后果。
Apache在内部如何处理安全问题?
随后我们稍稍改变了话题的方向,着重探讨总体上的Apache基金会和具体上的HTTP项目在内部如何处理安全问题。
在Apache肩负处理安全问题这个重任的是Apache软件基金会安全小组(ASF Security Team),Bill是这个团队的成员之一。他表示,开始,“我们还以为只会接到关于httpd的安全事件报告。但情况很快就发生了变化。”
安全团队的规模慢慢扩大到了随时都有5名活跃成员,临时委员会有10名成员。Bill解释:“我们实际上扮演了调度员的角色。”
至少在外人看来,这个过程似乎很简单:“团队确认我们确实遇到了酷似安全事件报告的问题,对不是安全事件报告的任何问题进行排查,然后将排查结果交给相应的人员或部门。”
“如果我们接到公众反馈上来的零日安全漏洞,或者实际的重现情形--通过另一家机构悄悄传递给我们,我们随后会转交给某个相应的Apache项目;我们成为了这个项目的资源中心,帮助他们了解你与报告这个事件的那一方如何互动。”
然后,视项目会不会重现报告的安全漏洞而定,安全团队帮助项目应对安全研究人员(通常是报告安全漏洞的那个人或那家组织)。Bill解释:“我们对他们说,嘿,在我的下一个版本中,我们会拿出修复程序,你在那个时间点之前别用这个版本,这是我们的时间表。”
我们并没有试图有意隐藏我们的代码执行什么样的功能
“我们并没有试图有意隐藏我们的代码执行什么样的功能,而我们能做的就是修补漏洞,我们只是说自己在修复软件缺陷,而不是把任何注意力引向这个事实:旧代码中存在安全问题,安全问题是这个样子。”
据Bill声称,有些人在密切关注重大开源项目(如Linux内核、httpd及其他项目)提交的代码,一心寻找在不远的将来可能堵上的漏洞。Bill解释:“如果他们能找到我们正努力堵上的漏洞,他们想找到机会窗口,以便可以钻这个安全漏洞的空子。”
“所以我们扮演的是资源中心,尽量化解困惑、化解每一个项目的压力--我们在任何时间有100个左右的项目,每个项目都在处理各自的安全问题,无论是在排查安全问题,还是迅速处理安全问题。”
我们还应补充一下,安全团队在努力帮助确认看起来像特定问题域问题的某些问题,比如最近的散列安全漏洞(http://arstechnica.com/business/news/2011/12/huge-portions-of-web-vulnerable-to-hashing-denial-of-service-attack.ars)。随后,安全团队会查看其他Apache项目可能会受到什么影响,团队可以在多大程度上与别人共享有关的安全报告,即便受直接影响最大的那个项目正在处理当前的安全漏洞。
个人能选择感兴趣的事来做
无论从哪个标准来看,Apache HTTP都是一个成熟的软件项目,在问世近17年后,最近迎来了版本2.4.我们请Bill回顾一下他在Apache基金会和HTTP项目时候的情况,现在安全方面是不是在占用更多的时间。
项目越成熟,你在表面上的变化方面谈论得越多。
他简短有力的回答是:“当然就历史久远的项目而言,就我个人而言,答案是肯定的。项目越成熟,你在表面上的变化方面谈论得越多,发布新的特性方面谈论得越少,会更加偏向于维护状态,这里来些优化,那里有些安全问题。”
“而Apache上下的每个人都可以选择感兴趣的事来做;我是指,所有的代码开发者、所有的代码捐献者都被鼓励致力于项目中对他们个人来说最有兴趣的那些方面。在一些情况下,那是付钱请他们做的工作;在另一些情况下,那也是对他们的雇主或下游客户来说最感兴趣的工作。”
Bill表示,这意味着,在HTTP项目或其他任何项目从事安全方面工作的人往往是倾向于对安全、漏洞和维护有着浓厚兴趣的那些人。他解释:“他们只想开发出那些修复程序,然后发布给公众。”
“我们通过关注调查来了解整体情况。”
眼看我们的采访就要结束,与Bill的讨论再次将方向转向Apache主导Web服务器软件市场的现实。据NetCraft最近的服务器调查显示(http://news.netcraft.com/archives/2012/03/05/march-2012-web-server-survey.html),运行Apache HTTP的网站占总量的65%以上。
我们问Bill是不是平时在看诸如此类的调查和统计数字。
Bill笑着说:“作为一家基金会,不去看。但是我们确实有一些具体的公众人员,他们对名声和营销很关注。当然,我们醉心于确保Apache和Apache基金会有好的名声,维持好的名声,为此我们致力于开发优秀代码。但是只有知道我们在开发优秀代码的人才关心这个。”
当然,我们醉心于确保Apache和Apache基金会有好的名声,维持好的名声,为此我们致力于开发优秀代码。
在这个庞大的现有用户群中,版本2的Apache HTTP占了92.2%。更具体地说,今年2月底的一项调查显示(https://blogs.apache.org/httpd/entry/apache_http_server_usage_survey),最常见的Apache HTTP版本是2.2,占了89.2%。
Bill更感兴趣的是这些数字,而不是市场份额占多少百分比。他表示,他主要关注升级周期和升级方面的滞后:“我关注2月的那项调查;我可以看到,2.2.3仍得到广泛采用;这个版本的代码至今已有五个年头了,”他说。
Bill解释:“我们在关注红帽或其他核心操作系统发行版,它们推出了重大版本,人们在安装它,其实不想更改。而从安全的角度来看,那些2.2.3版本不是特别容易受到攻击,因为它们已经打上了一系列增量补丁。”
Bill在接下来的一两个月会关注升级和降级模式。他会研究人们在如何采用版本2.4,然后研究那些升级的人当中有多少比例在一段时间后会回到之前的版本。
关键字:服务器、安全、升级、网站
新文章:
- CentOS7下图形配置网络的方法
- CentOS 7如何添加删除用户
- 如何解决centos7双系统后丢失windows启动项
- CentOS单网卡如何批量添加不同IP段
- CentOS下iconv命令的介绍
- Centos7 SSH密钥登陆及密码密钥双重验证详解
- CentOS 7.1添加删除用户的方法
- CentOS查找/扫描局域网打印机IP讲解
- CentOS7使用hostapd实现无AP模式的详解
- su命令不能切换root的解决方法
- 解决VMware下CentOS7网络重启出错
- 解决Centos7双系统后丢失windows启动项
- CentOS下如何避免文件覆盖
- CentOS7和CentOS6系统有什么不同呢
- Centos 6.6默认iptable规则详解