堵住域名和邮件的漏洞

核心提示：域名系统(DNS)是Internet上其他服务的基础，E－mail是Internet上最重要的服务。但是DNS和E－mail系统也是Internet上安全漏洞最多的地方，而题目在哪里?在我们每天都要使用DNS和E－mail时，怎样样才能放心？

域名系统(DNS)是Internet上其他服务的基础，E－mail是Internet上最重要的服务。但是DNS和E－mail系统也是Internet上安全漏洞最多的地方，而题目在哪里?在我们每天都要使用DNS和E－mail时，怎样样才能放心？

域名系统

DNS是Internet上其它服务的基础。它处理DNS客户机的要求：把名字翻译成IP地址；把IP地址翻译成名字；并提供特定主机的其它已公布信息（如MX记录）。下面先容DNS使用中业已知晓的两个安全题目，并给出相应的解决方法。

名字欺骗

为使用的方便如答利用户履行远程系统命令，系统治理员常常在某些主机之间建立相互信任的关系，当主机间的信任是借助名字并通过DNS来认证时，就会导致名字欺骗的出现，如图所示。

当主机B访问主机A(同时也作为DNS服务器）如履行rlogin时，A接收到这个连接并取得发起本次连接主机B的IP地址。为验证本次连接的正当性，主机A就向本地DNS服务器逆向查询对应于这个IP地址的主机名字。当返回的查询结果——主机名B为本机所信任的主机时，就答应来自B的远程命令rlogin。下面我们再来看看主机D是如何利用验证漏洞来欺骗主机A的。当主机D也履行rlogin时，主机A一样要验证本次连接的正当性。假设A不能根据D的IP在本地DNS服务器中查询到对应的主机名时，就会向其它DNS服务器发出要求，最后终会找到DNS服务器C。假设进侵者修改DNS服务器C中对应于自己IP地址的主机名为主机B时，主机A就会取得对应于D的IP地址的主机名是B的逆向查询结果，因此主机A认可本次连接。因而欺骗A成功。

从上面的讨论可知，当欺骗产生时，在A的域名数据库中关于名字B有3个IP地址条目，其中B→B_IP条目位于A所保护的正向DNS树上，B_IP→B条目位于A所保护的逆向DNS树上，D_IP→B条目位于Cache中，即主机名与IP地址之间的关系不是逐1对应的。若主机A在验证进程中再多走1步，即再用主机名B正向查询对应的IP地址(双向查询)，就会发现同时有D的IP和B的IP对应着名字B。这样主机A便可以够辨认主机D的欺骗企图，但是双向查询其实不总有效，例如对多宿主机。

隐躲信息

与DNS有关的第2个安全题目是它会泄漏那些你不想流露的信息。例如1些组织的系统治理员会依本组织的功能单元来命名内部主机名和其它信息，或依本组织的体系结构来计划本组织域名下的名字空间，也可能由于内部某个秘密项目的方便展开而为1些主机设置别名。这些信息1旦被进侵者获得，那末组织内那些重要的主机就会1览无疑地显现在进侵者眼前。

进侵者获得被进侵者的DNS信息的方法有很多。最通常的1种方法是连接被进侵者站点的DNS服务器并要求区传输（ZoneTransfer），仿佛它们是被进侵者站点的DNS服务器的辅助服务器。

防范这类进侵的方法有两种。1种是利用DNS软件（注：BIND4.9.3以上的版本）自带的两个安全特性：限制名字数据库中的数据只被特定的主机查询；只答应真实的Secondary主机从Primary主机上提取Zone数据（库）。这类方法具有实现的方便性和高效性，但还不够完善。由于DNS数据库依然暴露在进侵者的范围之内，仍有可能被进侵者用匪夷所思的方法盗取。在我们看来，第2种方法相比第1种方法更安全，固然本钱会更高，使用的技术也更复杂。

第2种方法以防火墙/NAT为基础，并应用私有地址和注册地址的概念。现以1个园区网为例加以描写。首先我们把园区网的IP地址空间划分为两大部份：私有地址部份和注册地址部份（作为全部Internet地址空间的1部份）。与此对应，园区网的名字空间也分为两大部份：对外可见的（外部）名字域（作为全部Internet名字空间的1部份）和对外不可见的（内部）名字域。二者域名相同，但域名数据库的大小不同。为对外隐躲信息，所之外部DNS数据库相对小，而内部DNS数据库相对大。相应地，完成域名到IP地址转换的DNS服务器也存在两套，即内部DNS服务器和外部DNS服务器。鉴于划分地址空间的原则——所有园区网内的主机使用私有地址；对Internet服务的主机用NAT完成注册地址到其私有地址的静态映照；访问Internet的主机用NAT完成其私有地址到注册地址的动态映照。因此内部DNS服务器组仅对园区网内的主机服务，外部DNS服务器组对Internet主机服务。内部DNS服务器提供园区网（内部）名字域到私有IP地址的解析，只能由园区网内的主机使用，对Internet主机不可见，即不在上级DNS服务器登记，而对园区网（内部）名字域外的Internet域名解析的任务直接提交外部DNS服务器完成。这时候，须在内部DNS服务器的启动文件中设置forworder和slave选项。不过这里要留意的1点是DNS服务器间不能进行多极forworder级连。

外部DNS服务器放在防火墙的DMZ局域网上。外部DNS服务器提供园区网（外部）名字域到静态转换的注册IP地址的解析，由Internet主机使用。为了解决（连接）可能的反向地址查询和双向查询，外部DNS服务器不但要为静态转换的注册IP地址定义PTR记录，而且要为每1个用于动态转换的注册地址定义1个伪主机名，并定义1个PTR记录。外部DNS服务器对Internet代表园区网名字域。由于对外服务，所以须在上级DNS服务器上登记。

E－mail系统

E－mail作为Internet上最重要服务的同时，也是安全漏洞最多的服务之1。E－mail系统之所以是1种最脆弱的服务，是由于它可以接收来自Internet上任何主机的任何数据。功能上来讲，E－mail系统由3部份组成：服务器部份用来向外部主机发送邮件或从外部主机接收邮件；发信代理部份将邮件正确地放进本地主机邮箱中；用户代理部份让收信人浏览邮件并编排出站邮件。由于各种不同缘由，每个部份都存在被攻击的漏洞。

Internet上，服务器间的邮件交换是通过SMTP协议来完成的。主机的SMTP服务器接收邮件（该邮件可能来自外部主机上的SMTP服务器也可能来自本机上的用户代理），然后检查邮件地址，以便决定在本机发送还是转发到其它1些主机。Unix系统上的SMTP程序通常是Sendmail。有关Sendmail的安全题目报导层见叠出的1个缘由在于，它是1个异常复杂的程序，长达30000多行，另1个缘由是它需root用户特权运行。

针对引发E－mail系统不安全的种种缘由，主要有以下几种解决方案。

方法1：使用Unix系统自带的安全特性

Sendmail之所以不安全的1个重要缘由是，它以root身份运行后台守护进程。假设我们使Sendmail不具有root权限，并最大程度地下降它的权限，那末即使它被攻破，也不会给系统带来多大的影响。假设我们使Sendmail不运行动后台守护进程（daemon），反过来讲就增大进侵者连接Sendmail的难度。若连接都建立不起来，固然也就无从谈起攻击Sendmail的题目了。

方法2：使用代理

上面这类方法的1个弊端是全部E－mail系统的效率会下降，由于每隔10分钟Sendmail才扫描1次邮件队列，才会把邮件发送到用户的邮箱。假设我们设置1个邮件代理来专门接收邮件并结合使用防火墙技术，不但效率明显进步，安全性也进1步增强。

1个专门接收邮件的邮件代理会直接断尽进侵者通过SMTP与Sendmail建立连接的可能（不同于上面的方法，它只是增大了连接Sendmail的难度）。由于SMTP协议中关于邮件接收的命令相当简单，唯一6条指令，因此依此编写邮件代理程序，程序不但结构清楚（程序本身不容易出现bug），而且代码少（轻易检查和发现它的所有安全题目）。由于没有更多的任务要完成，所以邮件代理所需权限也小。相比于长达3万多行的、结构复杂的、程序bug不断被报导的、系统权限极高的Sendmail来讲，邮件代理的上风是明显的。

邮件代理的免费程序可直接从Internet上download下来。我手边的邮件代理程序是TIS防火墙工具包的1部份，它由smap和smapd组成。其中smap唯一700多行，专门接收邮件并把接收到的邮件放到邮件队列中。smap也是由inetd启动，因此不需要作为root用户来运行。smapd每隔1分钟处理邮件队列，并把处理完的邮件转交给Sendmail发送到本地或其它主机。

初看，方法1和方法2在性能上几近没有甚么辨别，但实际情况不是这样的。方法1中，若Sendmail处理邮件队列的时间超过10分钟，那末10分钟后就有可能有两个Sendmail进程来处理邮件队列，及可能有多个Sendmail进程被inetd启动以接收进站邮件，又由于文件锁机制的存在，在任甚么时候候只能由1个Sendmail进程操纵邮箱，因此有可能造成系统资源被大量占用。极端情况下，还会导致全部系统资源的完全占有，从而导致系统崩溃。若我们每隔20分钟来处理邮件队列，系统崩溃的可能性会下降，但是E－mail系统的性能也随之下降。方法2中，首先，完成邮件接收（smap）和处理邮件队列（smapd）是两个不同程序，且任务单1、极其小巧。其次，真正处理邮件队列的任务还是由Sendmail来完成的，换言之，由于smapd长时占据邮箱而导致文件锁的长时存在的可能性极小。Sendmail处理邮件队列时需检查邮件地址，因此也就会访问DNS、系统的别名表，最后还可能改写邮件地址。但是，真实的耗时操纵还不是这些而是向外转发邮件，它须与目的主机建立TCP连接，若连接建立不起来，还要履行retry和timeout操纵。

方法3：修改源码

即使按上面的方法增强了E－mail系统的安全，还是存在1些安全漏洞。1般而言E－mail账户都是系统账户，既然是系统账户就在某种程度上能访问1定的系统资源，就1定程度上要挟系统的安全。而进侵者获得某个邮件账户的访问权不是甚么难事，如直接在网上监听SMTP信包(注：大多数包是明文传送)，所以假设我们使用户能接收邮件但又不在系统上有账户时，便可以杜尽这类安全隐患。另外，1般Unix系统本身不支持超过5000个系统用户的特性又进1步增强了这类方法的实际意义。

源码修改只需改动用户认证那部份，即不通过/etc/passwd文件中往认证用户的正当性，你可自己建立1套认证机制，如结合Radius、TACAS＋或LDAP技术。更有甚者，还可应用1次性口令来增强口令的安全性。我们现在已修改完源码并处于进1步完善的工作中。

评论加载中... 内容： 评论者： 验证码：