信息安全案例

信息安全案例一：信息安全中的公开信息安全

最近网上热炒一个帖子，一名清华理科生根据影星王珞丹的微博，推理出王珞丹的住址。主要过程包括，根据王珞丹微博提到的她当演员这么多年，还没在四环以里买房子，并且在其他微博中提到她在四环堵车的情况，可以知道王珞丹住四环外，然后再根据她发的两张从家里拍小区的照片，大致知道小区中有一个大的四方形花坛。然后在google earth上找北京，找到有方形花坛的小区，然后再根据照片拍摄的位置和角度，就找到了王珞丹住住址。

2008年奥运会举办前，因为国家领导万无一失的要求，北京进行了大规模的信息系统安全性检查，我参与了很多系统的安全性测试，遇到了这么一个案例。

北京某区政府门户网站上，通过搜索网站，找到了一个邮箱使用说明,该网页说明了如何使用区政府公务员邮件系统。其中有以下描述：

--------------------------------------------------------------------- 在地址栏输入https://www.360docs.net/doc/1a11095169.html,，按回车键登陆北京xx网站。如图1所示，选择公务员邮箱，输入邮箱名，邮箱密码默认为六个1，鼠标单

击登陆。例如，选择公务员邮箱，在用户名处输入tjjbgs，密码输入111111，单击登陆即可进入统计局办公室的邮箱。

--------------------------------------------------------------------- 从这一段描述中，可以获得以下信息，邮箱命名方式一般用中文拼音的第一个字母，密码默认六个1,那么对于攻击者，只要在网上找找，就能找到区重

要领导名字、重要部门的名称，再据此进行攻击。不过在本次测试中不需要，因为帮助说明最后给出了区重要领导的邮件地址（编写者是为了方便人员发邮件，直接告诉别人，给哪个部门发邮件发哪个邮箱等）。对这些公布的邮件进行了简单的口令测试（大纲只测了五分钟后），有重要领导的邮箱密码尚未改变，有两位领导已经改变，不过改得有些简单，123456，与没改一样。登录进行，看到了给领导发的汇报材料，请示之类的。还好我只是测试人员，不是XX功人员，否则以此领导的邮箱群发个XX功的宣传邮件，我想在当时保奥运的严格要求形势下，应该反应会比较激烈，后果很严重。

从铁人王进喜照片泄密案到现在的影星隐私泄露表明，很多时候，信息安全问题是在不经意间产生的。公开的信息会出卖你的，不要太不以为意，信息安全如是，生活中如是。

信息安全案例之二：不安全的“安全密码”

2011年七月，处理了一起服务器入侵事件，这起事件可以说是非常普通的入侵案件，每年都会处理很多起，也没有什么技术含量，只是这起案件带来了一些对安全的思考。因为前几天写的一个案例被杨泉老师说要作为案例在讲课时候进行介绍，为了给以后的各位老师们提供素材，所以准备逐步把自己做这么多年安全中遇到过的案例逐步写出了，给各位CISP老师和其他信息安全培训讲师做参考。

事件起因非常简单：管理员发现一台服务器被入侵，但是不知道如何被入侵的，正好此单位信息化领导是朋友，请我去帮忙看看。简单了解了一下情况，服务器前有防火墙，只开放了80、3389端口，服务器补丁打全了。按照老习惯怀疑可能SQL注入，但是看web日志前，习惯性的先简单看了看服务器日志，发现服务器安全日志中存在多个互联网IP地址从远程终端登录的记录，甚至有在夜间的。于是问了一下管理员和开发商人员，在记录的时间段内是否进行过登录，回答均没有在那个时间登录过，初步判断可能是密码被猜出来，攻击者直接从终端服务进行了远程登录，登录到系统上进行了操作。

问管理员密码情况如何，管理员说我们密码安全性应该比较好，有字母、有特殊字符，而且12位长，问之什么密码，答约：zaq12wsxZAQ!@WSX。大家看起来应该比较复杂，仔细看一下你的计算机键盘，其实就是最左边的一排键，从下按到上，兜一圈按下来，然后按着shift键再重按一次。自认为聪明的管理员啊，这种密码的设置方式，攻击者都知道了，不再是安全的密码了，案例非常简单，似乎没有什么参考价值，其实其中牵涉到了密码设置的问题。

账号密码设置是信息安全中最基本的安全措施，尽管非常简单，但是任然有大量的安全事件与密码有关，如何设置一个好的密码，其实是一门学问。很多安

全资料。都提到设置密码，提到的都是多少位长度、大写字母、小写字母、数字都有，但上面案例中管理员设置的密码似乎都符合以上要求，长度够、复杂度够。但仍然不是安全的密码。因为这种密码对于纯粹穷举的暴力破解是很好的，但是对结合了社会工程学的口令破解方式，这种密码就属于安全性不足的密码了。

好的密码应该包含两个特点：自己很好记、别人不好猜。

案例中的管理员设置的密码符合了第一条，没有符合第二条，所谓不好猜应该指的是不好推理出来，使用电话号码、生日作为密码的就明显不符合不好推理的情况，攻击者可以通过收集目标信息从而推理出来，还有就是必须无规律，案例中的管理员就是使用了规律的密码，构成密码的字符在键盘上是顺序排列的，也就意味着有规律可循、可以推理出来，因此不是好密码。

还有些管理员设置了很复杂的口令，的确无规律，不可推理，能有效的应对攻击者的口令破解，但是大多很难记忆，不符合第一条要求。由于不好记忆，于是管理员会将口令保存在excel表中、存放在自己的个人电脑中，或者记在笔记本里面，这也为口令的保管带来了另外的安全威胁（这种做法的风险下次通过另外一个案例进行介绍)。但如果仅仅把密码记忆在脑中，又存在由于时间长而忘记口令的情况(我每年大约也处理2~3次因为口令过于复杂，忘记口令无法进入系统，最后只能破解进入系统的情况）。

如何设置一个好的口令的例子:记忆一句话，例如，我的生日是10月28日，由此生成密码，取拼音的第一个字母：wdsrs10y28r，再做略微变形，如在最后加个感叹号，第一个字母大写等，最后密码为：Wdsrs10y28r! 密码具有足够的安全性，并且也不容易忘记，只要你记住这句话，甚至你将这句话记在笔记本上也比你直接记密码好。

另外，推荐采取密码信封的方式，在系统上设置一个非常复杂的用户名和口令，无需记忆，将它写在一张纸，封在信封中，保存在安全的地方，例如保险柜中，当系统发生问题时，或者紧急情况下，由相关人员授权开启信封，获得进入系统的权限。

总之：密码是信息系统的安全的根本，设置一个好的密码能解决很多安全问题，请不要轻视密码的设置，牢记好的密码两个特点，自己很好记、别人不好

猜，两者缺一不可。非常的期望今后再有人找我处理被入侵的服务器，不要再是密码这种简单的原因所导致的。安全，业务并不复杂，从设置好你的密码开始。

信息安全案例三：信息展示最小化原则

在每次给CISP们进行信息安全技术培训和意识培训时，我一般都会强调一

个理念，“信息展示最小化”，即给你的用户展示的信息应该是你需要向他展示的信息，除此之外的任何信息都是需要保护的。相信很多学员在培训时听了，但是并没有真正意识到信息最小化原则的意义，或者是觉得这样做太麻烦。如果对此不能理解，请参见以下的真实案例。

2008年奥运会前，我实施了北京的很多政府网站渗透测试，在其中一个政府门户网站测试中，渗透进入了网站中。采取的方法和利用都很简单，利用了系统开放日志和一个脚本开发的问题。

北京市各政府门户网站，都属于首都之窗政府网站群的一部分，但是这些网站，有些是集中托管在首信机房中，也有的是自己管理。出于安全的考虑，首都之窗网站群集中由首信公司进行安全保障，其中有一项保障机制就是各门户网站应开放自己的网站访问日志给首信公司进行集中采集，集中分析。我进行渗透测试的网站也不例外，由于网站是构建在IIS上的，因此管理人员采取了将日志存放目录设置为网站的目录，可以从web访问（此方式可能为首信的统一要求），首信通过定制开发的程序，每天从互联网上通过web下载将日志下载到日志服务器上进行保存。

发现此问题问题后，我安排了一名测试人员将日志下载下来，让他通过日志访问记录，尝试还原出网站的目录和文件结构基本情况。在还原的过程中，测试人员看到了以下的日志记录：

-----------------------------------------------------------------2008-01-08 010:58:16 2.2.2.2 - 11.11.11.11 80 GET /admin/yjglqwe.asp - 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)

-----------------------------------------------------------------

从以上记录中，可以看出网站上存在一个/admin/yhglqwe.asp的脚本文件，因为访问记录上的返回值200，表示访问成功。

随后测试人员尝试直接通过https://www.360docs.net/doc/1a11095169.html,/admin/yhglqwe.asp 直接从互联网访问此脚本,意外的发现访问成功，并且打开了测试网站系统的用户管理页面，测试表明已经可以对用户进行操作。

幸好我们只是测试人员，不是一名攻击者，否则系统上会多几个后门账户了。

总结问题的原因：网站对脚本的调用没有进行限制，正常情况下应该登录验证后才能调用此脚本，而脚本并无此验证功能，只有调用到就可以操作用户。开发人员通过给脚本起一个无规律的名称，因为攻击者不知道文件的名称，无法调用而保证安全。但是，日志系统把这一秘密给暴露了。

问题的解决：最终在防火墙上设置策略，只允许来自首都之窗的日志采集服务器的IP地址对日志进行访问（当时考虑到还可以采用FTP，采集日志需进行验证，由于首都之窗的采集日志程序已经开发确定为从Web下载，无法修改，因此放弃）。

案例给我们的启示：在信息安全中，我们无法保障我们的系统会存在什么样的问题，但是，我们应该保证我们的系统尽量减少信息的泄露，也许就是这简单的工作，就能保障你的系统免受一次可能的攻击。如果没有这个日志开发的要求，我相信被测试网站的这个漏洞也很难被发现，因为我们无法知道这个调用用户管理功能的脚本德名称。

为了你的信息系统安全，请记住“信息展示最小化”原则。