你的DMZ区安全吗

■

为了安全起见，企业网一般会由防火墙分为多个不同的区域，如UNTRUST区域、TRUST区域、DMZ区域等等，这些区域之间存在一定的隔离关系，由防火墙策略进行灵活控制。DMZ区是位于企业内部网络和和外部网络之间的一个独立的区域，它能够解决企业网外部用户不能访问内部网络服务器的问题。在DMZ区域内可以放置一些需要公开的服务器及设备，如Web服务器、论坛及DNS服务器等，笔者所在单位也不例外，DMZ区部署有多台对外提供服务的服务器，并由防火墙控制从各个区域到DMZ区域的访问请求。

入侵事件回顾

本单位DMZ区有一台基于Linux操作系统的DNS服务器，这台服务器配置有静态公网IP，除了承担本单位自身域名的解析工作外，还为内网用户上网提供域名解析的转发服务，即将Internet上的域名解析请求转发到运营商处的DNS服务器（202.99.96.68）。

某天下午13：30左右，有用户反映常用的几个网站访问异常，在浏览器中输入对应的URL，却跳转到“您访问的域名有误或者网页不存在”的页面，或者一级页面可以打开，但是二级页面就打不开；过几分钟后，又恢复正常，如此反反复复，折腾得用户怨声载道。但是除了这几个常用网站外，其他网站访问没有发现任何异常。

笔者接到问题后，马上意识到是域名解析出现了问题。按照故障处理流程，先在cmd命令行中使用“nslookup”命令解析相关网站的域名，发现这几个异常网站的域名解析都指向了同一个公网IP地址；但是使用指定DNS服务器命令“nslookup www.XXX.com 202.99.96.68”进行对应解析，得到的IP地址却完全不同，这说明运营商DNS服务器没有问题，问题肯定出在单位的DNS服务器上！

笔者立即使用SSH远程登录到单位的DNS服务器上，仔细核查DNS服务的相关配置文件，果不其然，发现DNS配置文件“named.conf”设置的转发器“forwarders 202.99.96.68”变成了一个陌生的IP地址，看来系统肯定被入侵过！笔者利用“ll“命令看到配置文件“named.conf”就在15分钟前被修改过，而那时正是网站访问不正常的时候！

事件处理

既然我们已经找到故障的原因，那么处理起来就简单了：把转发器指向的IP重新修改为202.99.96.68，然后重启DNS服务，应该就能恢复正常了。事实上，我们这样做了之后，用户上网确实恢复了正常。但是我们必须要搞清楚服务器是如何被攻击的？攻击手段是什么？这样才能有针对性地做一些防护措施，保障DNS服务器的安全。

任何攻击手段都会在系统内留下些许的痕迹，笔者相信这次攻击也不例外。笔者在DNS服务器控制台输入“history”命令，查看最近的控制台命令记录，果然发现有非法通过VI命令修改named.conf配置文件的命令，这说明用户已经取得了root权限，但是这台服务器之前已经通过安装更新修正了“权限提升”的常见漏洞，那么最有可能的原因是系统的root密码已经被破解！于是笔者赶紧利用“passwd”命令将root密码进行了变更。也许到这里，不少网络管理员觉得危险已经解除，可以高枕无忧了；确实，密码修改以后，攻击者在短时间内很难再次入侵系统，但是攻击者的手段是可以变化的，如果你的服务器被攻击者盯上，那么很可能成为APT（Advanced Persistent Theat）攻击的牺牲品，将很难保证服务器不被再次入侵。所以我们在处理攻击或者入侵事件时，不要仅仅满足于解除当前的威胁，更要追本溯源，举一反三，深刻剖析出现问题的原因，然后及时调整或者强化安全策略，这样才能从根本上杜绝此类攻击的再次发生。

针对这起入侵事件，笔者相信入侵者不会善罢甘休，遂决定守株待兔，力争获取更多的攻击行为的信息。果然，半个小时后，通过netstat命令发现了一个可疑的TCP连接，“Foreign Address” 是 一 个陌生的IP，经过核查，是国外的IP，而连接的端口是22端口，即SSH服务使用的端口，笔者利用kill命令将对应的进程终止，但是很快该连接就自动重新建立，而且“Foreign Address”也发生了变化，分析到这一步，笔者基本可以断定这是一起僵尸网络攻击，攻击者控制了大量主机对本单位DNS服务器的22端口发起密码试探的攻击！这是非常危险的，如果攻击者控制的主机数量足够大，攻击软件足够强大，那么该服务器很快就会沦陷。

既然已经找到攻击根源，那么可以采用如下三种方式来阻断此次攻击：

1.直接利用控制台命令“service sshd stop” 将 SSH服务关闭。但是这样就会“殃及池鱼”，影响管理员使用SSH来进行远程维护。

2.启用Linux中自带的iptables防火墙来进行封堵。由于攻击IP是动态变化的，所以根据IP来制定iptables策略是不切实际的，只能依据22端口来制定封堵策略。同样，这种方式和方式1一样，会影响管理员使用SSH。

3.利用单位的防火墙进行封堵。由于该DNS服务器位于DMZ区，我们可以在防火墙上制定UNTRUST->DMZ方向的策略，将22端口在该方向上进行封禁；而对应TRUST->DMZ方向的策略，咱们仍然可以将22端口放行。这种方法就解决了管理员不能使用SSH进行远程维护的问题，只要管理员在单位内网区域，那么仍然可以利用SSH来进行远程维护；而外网的攻击者则被防火墙封禁，如果管理员需要在外网对该服务器进行远程维护，那么可以利用VPN进行接入，这样就大大增强了服务器的安全性。

事件总结

尽管通过上述的分析和技术手段，我们已经化解了一次危险的攻击，但是“明枪易躲，暗箭难防”，攻击者永远处于暗处，我们总是这样被动地去防御，很难产生好的效果。没有任何系统是百分百的安全，但是我们要做的工作是尽量减少被攻击的概率，要抱着“预防为主”的心态去主动强化安全工作。DMZ区由于其特殊性，必须加强防护措施，本文从主机、防火墙、应用级安全三个方面提出如下建议：

1.强化主机自身安全。不少网络管理员潜意识里认为Linux系统比Windows系统安全，经常忽视对Linux主机的安全防护；其实，在安全面前，所有主机都应该一视同仁，说不定哪天某台不受重视的服务器被入侵，然后成为了攻击其他主机的跳板，那就得不偿失了。无论什么系统，启用主机防火墙是第一步，要按照最低权限的原则部署防火墙策略，关闭与业务无关的常用端口，比如Web服务器，对外就只开放80端口，对于其他的21、22、23 等常用端口，一定要利用主机防火墙关闭；其次，禁用与业务无关的服务，特别是一些RPC远程过程调用的服务，若与业务无关，一定要禁用；然后，要及时安装重要的系统更新，特别是涉及到一些重大安全漏洞的更新，一定要安装；最后，设置强壮的密码也必不可少，特别是管理员密码设置，要符合相应的安全规则。

2.细化防火墙安全策略。通过步骤1我们强化了主机自身的安全，但是专业的硬件防火墙设备作为企业网络安全的第一道屏障，在针对网络层的攻击防护上，还是有着不可替代的作用。硬件防火墙的安全策略比主机防火墙策略要更加灵活，而且防护效果更加有效；它可以将企业网络划分为多个隔离区域，然后针对隔离区域之间的数据通信进行控制。对于DMZ区的安全策略，应重点细化UNTRUST->DMZ通信的安全策略，可以针对目的地址、目的端口做安全策略，要秉承“只有使用的端口才能放开”的最小权限原则进行设置，比如前面提到的DNS服务器入侵事件，最终就是通过在防火墙上设置了针对服务器IP、53端口的permit策略，而针对其他所有端口的deny策略，在不影响业务应用的同时，成功阻断了攻击者的入侵。

3. 部署专业的应用级入侵防护设备（IPS）。随着攻击方式的逐渐演变，一般的硬件防火墙设备在应用层攻击的防护上已经力不从心，难以保障DMZ区和内网服务器的安全，特别是一些攻击行为特征具有动态变化的特性，必须部署专业的IPS设备进行识别、拦截。由于IPS设备内置有大量的攻击特征库，而且可以定期进行升级更新，所以在拦截攻击时具有得天独厚的优势；借助IPS厂家的支持，相信能让DMZ区的安全更上一层楼。

随着IT技术的飞速发展，网络安全问题也日益突出，DMZ区服务器由于开放的原因，更容易成为攻击者的目标，在这种严峻的形势下，“防患于未然”应该成为企业安全工作的主线。本文结合笔者亲身经历的一起网络入侵事故，建议企业从主机、防火墙、入侵防护设备三个方面入手，结合自身的IT架构，打造三位一体的网络安全保障体系。希望在不久的将来，各位同行在被问到“你的DMZ区安全吗？”这个问题时，能够底气十足地给出肯定的回答。