域名系统(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有三个IP地址条目，其中B→B_IP条目位于A所维护的正向DNS树上，B_IP→B条目位于A所维护的逆向DNS树上，D_IP→B条目位于Cache中，即主机名与IP地址之间的关系不是一一对应的。若主机A在验证过程中再多走一步，即再用主机名B正向查询对应的IP地址(双向查询)，就会发现同时有D的IP和B的IP对应着名字B。这样主机A就可以识别主机D的欺骗企图，然而双向查询并不总有效，例如对于多宿主机。
隐藏信息
与DNS有关的第二个安全问题是它会泄露那些你不想透露的信息。例如一些组织的系统管理员会依本组织的功能单元来命名内部主机名和其它信息，或依本组织的体系结构来规划本组织域名下的名字空间，也可能因为内部某个秘密项目的方便开展而为一些主机设置别名。这些信息一旦被入侵者获取，那么组织内那些重要的主机就会一览无疑地呈现在入侵者面前。
入侵者获取被入侵者的DNS信息的方法有很多。最通常的一种方法是连接被入侵者站点的DNS服务器并请求区传输（Zone Transfer），好像它们是被入侵者站点的DNS服务器的辅助服务器。
防范这种入侵的方法有两种。一种是利用DNS软件（注：BIND 4.9.3以上的版本）自带的两个安全特性：限制名字数据库中的数据只被特定的主机查询；只允许真正的Secondary主机从Primary主机上提取Zone数据（库）。这种方法具有实现的方便性和高效性，但还不够完善。因为DNS数据库仍然暴露在入侵者的范围之内，仍有可能被入侵者用匪夷所思的方法窃取。在我们看来，第二种方法相比第一种方法更安全，当然成本会更高，使用的技术也更复杂。
第二种方法以防火墙/NAT为基础，并运用私有地址和注册地址的概念。现以一个园区网为例加以描述。首先我们把园区网的IP地址空间划分为两大部分：私有地址部分和注册地址部分（作为整个Internet地址空间的一部分）。与此对应，园区网的名字空间也分为两大部分：对外可见的（外部）名字域（作为整个Internet名字空间的一部分）和对外不可见的（内部）名字域。两者域名相同，但域名数据库的大小不同。为对外隐藏信息，所以外部DNS数据库相对小，而内部DNS数据库相对大。相应地，完成域名到IP地址转换的DNS服务器也存在两套，即内部DNS服务器和外部DNS服务器。鉴于划分地址空间的原则——所有园区网内的主机使用私有地址；对Internet服务的主机用NAT完成注册地址到其私有地址的静态映射；访问Internet的主机用NAT完成其私有地址到注册地址的动态映射。因此内部DNS服务器组仅对园区网内的主机服务，外部DNS服务器组对Internet主机服务。 内部DNS服务器提供园区网（内部）名字域到私有 IP地址的解析，只能由园区网内的主机使用，对Internet主机不可见，即不在上级DNS服务器登记，而对园区网（内部）名字域外的Internet域名解析的任务直接提交外部DNS服务器完成。这时，须在内部DNS服务器的启动文件中设置forworder和 slave选项。不过这里要注意的一点是DNS服务器间不能进行多极forworder级连。
外部DNS服务器放在防火墙的DMZ局域网上。外部DNS服务器提供园区网（外部）名字域到静态转换的注册IP地址的解析，由Internet主机使用。为了解决（连接）可能的反向地址查询和双向查询，外部DNS服务器不仅要为静态转换的注册IP地址定义PTR记录，而且要为每一个用于动态转换的注册地址定义一个伪主机名，并定义一个PTR记录。外部DNS服务器对Internet代表园区网名字域。由于对外服务，所以须在上级DNS服务器上登记。
E－mail系统
E－mail作为Internet上最重要服务的同时，也是安全漏洞最多的服务之一。E－mail系统之所以是一种最脆弱的服务，是因为它可以接收来自Internet上任何主机的任何数据。功能上来说，E－mail系统由三部分组成：服务器部分用来向外部主机发送邮件或从外部主机接收邮件；发信代理部分将邮件正确地放入本地主机邮箱中；用户代理部分让收信人阅读邮件并编排出站邮件。由于各种不同原因，每个部分都存在被攻击的漏洞。
Internet上，服务器间的邮件交换是通过SMTP协议来完成的。主机的SMTP服务器接收邮件（该邮件可能来自外部主机上的SMTP服务器也可能来自本机上的用户代理），然后检查邮件地址，以便决定在本机发送还是转发到其它一些主机。Unix系统上的SMTP程序通常是Sendmail。有关Sendmail的安全问题报道层出不穷的一个原因在于，它是一个异常复杂的程序，长达30000多行，另一个原因是它需root用户特权运行。
针对引起E－mail系统不安全的种种原因，主要有以下几种解决方案。
方法1：使用Unix系统自带的安全特性
Sendmail之所以不安全的一个重要原因是，它以root身份运行后台守护进程。如果我们使Sendmail不具有root权限，并最大程度地降低它的权限，那么即使它被攻破，也不会给系统带来多大的影响。如果我们使Sendmail不运行为后台守护进程（daemon），反过来讲就增大入侵者连接Sendmail的难度。若连接都建立不起来，当然也就无从谈起攻击Sendmail的问题了。
方法2：使用代理
上面这种方法的一个弊病是整个E－mail系统的效率会降低，因为每隔十分钟Sendmail才扫描一次邮件队列，才会把邮件发送到用户的邮箱。如果我们设置一个邮件代理来专门接收邮件并结合使用防火墙技术，不仅效率显著提高，安全性也进一步增强。
一个专门接收邮件的邮件代理会直接断绝入侵者通过SMTP与Sendmail建立连接的可能（不同于上面的方法，它只是增大了连接Sendmail的难度）。由于SMTP协议中关于邮件接收的命令相当简单，仅有六条指令，因而依此编写邮件代理程序，程序不仅结构清晰（程序本身不易出现bug），而且代码少（容易检查和发现它的所有安全问题）。由于没有更多的任务要完成，所以邮件代理所需权限也小。相比于长达三万多行的、结构复杂的、程序 bug不断被报道的、系统权限极高的Sendmail来说，邮件代理的优势是明显的。
邮件代理的免费程序可直接从Internet上download下来。我手边的邮件代理程序是TIS防火墙工具包的一部分，它由smap和smapd组成。其中smap仅有700多行，专门接收邮件并把接收到的邮件放到邮件队列中。smap也是由inetd启动，因此不需要作为root用户来运行。smapd每隔一分钟处理邮件队列，并把处理完的邮件转交给Sendmail发送到本地或其它主机。
初看，方法1和方法2在性能上几乎没有什么区别，但实际情况不是这样的。方法1中，若Sendmail处理邮件队列的时间超过十分钟，那么十分钟后就有可能有两个Sendmail进程来处理邮件队列，及可能有多个Sendmail进程被inetd启动以接收入站邮件，又由于文件锁机制的存在，在任何时候只能由一个Sendmail进程操作邮箱，因此有可能造成系统资源被大量占用。极端情况下，还会导致整个系统资源的完全占有，从而导致系统崩溃。若我们每隔20分钟来处理邮件队列，系统崩溃的可能性会降低，然而E－mail系统的性能也随之降低。方法2中，首先，完成邮件接收（smap）和处理邮件队列（smapd）是两个不同程序，且任务单一、极其小巧。其次，真正处理邮件队列的任务还是由Sendmail来完成的，换言之，由于smapd 长时占据邮箱而导致文件锁的长时存在的可能性极小。Sendmail处理邮件队列时需检查邮件地址，因此也就会访问DNS、系统的别名表，最后还可能改写邮件地址。然而，真正的耗时操作还不是这些而是向外转发邮件，它须与目的主机建立TCP连接，若连接建立不起来，还要执行retry和timeout操作。
方法3：修改源码
即使按上面的方法增强了E－mail系统的安全，还是存在一些安全漏洞。一般而言E－mail账户都是系统账户，既然是系统账户就在某种程度上能访问一定的系统资源，就一定程度上威胁系统的安全。而入侵者获取某个邮件账户的访问权不是什么难事，如直接在网上监听SMTP信包(注：大多数包是明文传送)，所以如果我们使用户能接收邮件但又不在系统上有账户时，就能杜绝这种安全隐患。此外，一般Unix系统本身不支持超过5000个系统用户的特性又进一步增强了这种方法的实际意义。
源码修改只需改动用户认证那部分，即不通过/etc/passwd文件中去认证用户的合法性，你可自己建立一套认证机制，如结合Radius、TACAS＋或LDAP技术。更有甚者，还可运用一次性口令来增强口令的安全性。我们现在已修改完源码并处于进一步完善的工作中。
