DNS BIND之dnssec安全介绍

Domain Name System Security Extensions (DNSSEC)DNS安全扩展,是由IETF提供的一系列DNS安全认证的机制(可参考RFC2535)。它提供了一种来源鉴定和数据完整性的扩展,但不去保障可用性、加密性和证实域名不存在。DNSSEC是为解决DNS欺骗和缓存污染而设计的一种安全机制。
开发DNSSEC技术的目的之一是通过对数据进行数字“签名”来抵御此类攻击,从而使您确信数据有效。但是,为了从互联网中消除该漏洞,必须在从根区域到最终域名(例如, www. icann. org )的查找过程中的每一步部署该项技术。对根区域进行签名(在根区域部署 DNSSEC )是整个过程中的必要步骤。需要说明的是,该技术并不对数据进行加密。它只是验证您所访问的站点地址是否有效。完全部署 DNSSEC 可以确保最终用户连接到与特定域名相对应的实际网站或其他服务。尽管这不会解决互联网的所有安全问题,但它确实保护了互联网的关键部分(即目录查找),从而对 SSL (https:) 等其他保护“会话”的技术进行了补充,并且为尚待开发的安全改进技术提供了平台。
一、DNSSEC概念与原理
DNSSEC通过为通过为DNS中的数据添加数字签名信息,使得客户端在得到应答消息后可以通过检查此签名信,使得客户端在得到应答消息后可以通过检查此签名信息来判断应答数据是否权威和真实,从而为 从而为DNS数据提供数据来源验证和数据完整性检验,可以防止针对 可以防止针对DNS的相关攻击。

DNSSEC引入新的资源记录:
1.DNSKEY:用于存储验证 DNS数据的公钥
2.RRSIG:用于存储 DNS资源记录的签名信息
3.NSEC:存储和对应的所有者相邻的下一个资源记录 ;主要用于否定存在验证。
4.DS(Delegation Signer授权签名者),用于DNSKEY验证过程,存储密钥标签,加密算法和对应的DNSKEY的摘要信息。
二、DNSSEC功能
1.为DNS数据提供来源验证
2.为数据提供完整性性验证
3.为查询提供否定存在验证
即为否定应答消息提供验证,确认授权服务器上不存在所,确认授权服务器上不存在所
查询的资源记录))
三、部署DNSSEC有两种场景
1.配置安全的域名解析服务器(Resolver),该服务器可以保护使用它的用户,防止被DNS 欺骗攻击。这里只涉及数字签名的验证工作。
2.)配置安全的权威域名服务器(Name Server),对权威域的资源记录进行签名,保护服务器不被域名欺骗攻击。
四、开启DNSSEC
在BIND的配置文件(一般是/etc/named.conf)中打开DNSSEC选项
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
注:
dnssec-enable: 是否支持DNSSEC开关,默认为yes。
dnssec-validation: 是否进行DNSSEC确认开关,默认为no。
dnssec-accept-expired: 接受验证DNSSEC签名过期的信号,默认为no。
dnssec-lookaside:当设置dnssec-lookaside,它为验证器提供另外一个能在网络区域的顶层验证DNSKEY的方法。
dnssec-must-be-secure: 指定验证等级,如果选yes,named只接收安全的回应,如果选no,一般的dnssec验证将允许接收不安全的回应。
五、DNSSEC中KSK和ZSK
KSK表示密钥签名密钥 (Key Signing key) (一种长期密钥)
ZSK 表示区域签名密钥 (Zone Signing Key) (一种短期密钥)
如果有足够的时间和数据,加密密钥最终都会被破解。对于 DNSSECv中使用的非对称密钥或公钥密码系统而言,这意味着攻击者可通过强力攻击方法或其他方法确定公钥-私钥对的私钥部分(该部分用于创建对 DNS 记录的有效性进行验证的签名),从而使 DNSSEC 提供的保护失效。 DNSSEC 使用短期密钥(即区域签名密钥 (ZSK) ) 来定期计算 DNS 记录的签名,同时使用长期密钥(即密钥签名密钥 (KSK) ) 来计算 ZSK 上的签名,以使其可以得到验证,从而挫败了这些破解企图。 ZSK 被频繁更改或滚动,以使攻击者难以“猜测”,而期限较长的 KSK 则经过一个长得多的时段之后才更改(当前的最佳做法是以年为单位设置此时段)。由于 KSK 对 ZSK 进行签名而 ZSK 对 DNS 记录进行签名,因此只需具有 KSK 即可对区域中的 DNS 记录进行验证。 它是以 授权签名者 (Delegation Signer, DS) 记录形式传递到“父”区域的一个 KSK 示例 。父区域(例如,根区域)使用其自己的、由其自己的 KSK 签名的 ZSK 对子区域(例如, .org )的 DS 记录进行签名。
这意味着,如果 DNSSEC 被完全采用,则根区域的 KSK 将是每个经 DNSSEC 验证的域名(或尚待开发的应用程序)的验证链的一部分。
六、密钥对生成
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE zonename
1.DNSSEC标准中指定使用非对称密钥来生成和验证签名;
2.参数a表示使用的加密算法(三种算法:DSA/RSA/椭圆曲线DSA)
2.参数b用来制定密钥长度;
密钥长度需要考虑到密钥的可靠性和性能,
以及如何根据需要在两者之间取得平衡。
3.参数n指定密钥类型(ZONE/HOST)
4."zonename"密钥的名字(密钥的所有者密钥的所有者)
实例:
#/home/slim/bind/sbin/dnssec-keygen -a RSASHA1 -b 1024 -n ZONE test.com
Generating key pair...............++++++ ..++++++
Ktest.com.+005+28938
# ls
Ktest.com.+005+28938.key  #.key公有密钥
Ktest.com.+005+28938.private #.private私有密钥
5.根据DNSSEC部署经验,至少需要两种类型密钥才能地对DNSSEC域区进行安全的管理
ZSK(Zone-Signing Key)区签名密钥——用于签名域区内的数据
KSK(Key-Signing Key)密钥签名密钥——用于签名ZSK并创建区的"安全入口点"
dnssec-keygen -a RSASHA1 -b 1024  –f KSK -n ZONE zonename
实例:
#/home/slim/bind/sbin/dnssec-keygen -a RSASHA1 -b 1024 -f KSK -n ZONE test.com
Generating key pair.........++++++ ....++++++
Ktest.com.+005+23668
# ls
Ktest.com.+005+23668.key
Ktest.com.+005+23668.private
七、文件签署
签署之前,先将KSK和和ZSKZSK公有密钥添加到域区文件中。可以使用如下方式:
$INCLUDE到zonefile或者cat Kzonename+<alg>+<fing>.key >> zonefile
在区文件test.com.zone末尾添加如下信息
$INCLUDE "Ktest.com.+005+23668.key"
$INCLUDE "Ktest.com.+005+28938.key"

dnssec-signzone -o zonename –f result.file [-N INCREMENT][-k KSKfile] [-t] zonefile [ZSKfile]
1.签名工具BIND自带
2.参数o指定所有域区文件起始
3.-N INCREMENT序列号自增
4.参数-K指定KSK文件名称
5."zonefile"被签名的zone文件
6.ZSKfile制定ZSK文件名称
7.-f指定输出文件名称
8.-t显示统计信息
实例:
../bind/sbin/dnssec-signzone -o test.com test.com.zone
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
                    ZSKs: 1 active, 0 stand-by, 0 revoked
test.com.zone.signed
签名后输出文件为test.com.zone.signed
签署域区的过程主要包括:
1.将域区文件中的资源记录按照规则进行排序
2.为域区中的每个资源记录生成一个NSEC记录
3.将生成的签名信息存储在相应的RRSIG记录中
4.签名后文件比原域区文件更大

八、加载签名后的区数据
更新named.conf文件
zone "test.com" IN {
        type master;
        file "zone/test.com.zone";
};
改为
zone "test.com" IN {
        type master;
        file "zone/test.com.zone.signed";
};

九、DNSSEC验证流程验证流程
在父区验证
1、在验证时,解析器在父区查找被验证区的DS记录
2、如果不存在,向DLV注册机构发出一个对DLV记录的请求
3、如果成功,DLV资源记录被当做这个区的DS记录
4、在递归服务器上进行验证

注:DLV旁路认证概念旁路认证概念
1.DLV—DNSSECLookasideValidation
2.DLV是一个DNS服务器,提供DNSSEC签名认证的信任链解决方案,递归服务器配置的信任锚点是DLV,就可以认证域,进而认证权威域授权的信任的权威域。
递归服务器的配置:dnssec-lookaside 当设置dnssec-lookaside,它为验证器提供另外一个能在网络区域的顶层验证DNSKEY的方法
dnssec-lookaside "." trust-anchor dlv.cnnic.cn
trusted-keys {
dlv.cnnic.cn 256 3 5 "qWmA7OpfdqvqMtLCzZTm982aTaeC6tTRiPUOFDVMXEkIuM14T8Tw6jg2qmX7JUtriYHAGwIQ+9jzYyRziSFdijaO2elgh90NMW0jIcjZ+3cHehpETCEUar813SHN38biRu4UL0EQ/X5C5LJyh1djaw8eZFXxaLyT8fcJedBZtYE=";
}

十、发布公钥
要让其他人验证你的数字签名,其他人必须有一个可靠的途径获得你的公开密钥。DNSSEC通过上一级域名服务器数字签名的方式签发你的公钥。用dnssec-signzone 时,会自动生成keyset-文件和dsset-开头的两个文件,分别存储着KSK的DNSKEY记录和DS记录。作为test.net区的管理员,你需要把这两个文件发送给.net的管理员,.net的管理员需要把这两条记录增加到.net区中,并且用.net的密钥重新签名。
test.net. 86400 IN NS ns.test.net.
86400 DS 15480 5 1 (
F340F3A05DB4D081B6D3D749F300636DCE3D
6C17 )
86400 RRSIG DS 5 2 86400 20060219234934 (
20060120234934 23912 net.
Nw4xLOhtFoP0cE6ECIC8GgpJKtGWstzk0uH6
………
YWInWvWx12IiPKfkVU3F0EbosBA= )
如果你的上一级域名服务器还没有配置DNSSEC,你不得不另找其他方式了,比如,把上述两个文件提交到一些公开的trust anchor数据库中发布,或者直接交给愿意相信你的解析服务器的管理员,配置到他们的trust anchor文件中。
注:配置Trust anchor
要给解析服务器配置可信锚(Trust Anchors),也就是你所信任的权威域的DNSKEY。理想情况下我们可以配置一个根的密钥就够了,但是目前DNSSEC还没有完全部署的情况下,我们需要配置很多安全岛(Secure Island)的密钥,可以从很多公开的网站下载这些可信域的DNSKEY文件,包括:
(1)Root Zone DNSSEC Trust Anchors:https://www.iana.org/dnssec/。2010年7月部署实施,如果DNSSEC全部部署成功,这一个公开密钥就足够了。
(2)The UCLA secspider : https://secspider.cs.ucla.edu,由美国加州大学洛杉矶分校(UCLA)张丽霞教授的实验室维护。
(3)The IKS Jena TAR:https://www.iksjena.de/leistungen/dnssec.php
这些文件大概是这样的格式:
trusted-keys {
"test.net." 256 35 "AQPzzTWMz8qS…3mbz7Fh
...
fHm9bHzMG1UBYtEIQ==";
"193.in-addr.arpa." 257 3 5 "AwEAAc2Rn….HlCKscYl
...
kf2kOcq9xCmZv….XXPN8E=";
};
假设上述trust anchors的文件为/var/named/trust-anchors.conf,则在/etc/named.conf中增加下面一行:
include "/var/named/se-c-trust-anchors.conf";
---------------------  
作者:slimina  
来源:CSDN  
原文:https://blog.csdn.net/zhu_tianwei/article/details/45082015  
版权声明:本文为博主原创文章,转载请附上博文链接!

原文地址:https://www.cnblogs.com/pipci/p/10475162.html

时间: 2024-10-30 01:30:38

DNS BIND之dnssec安全介绍的相关文章

DNS&BIND入门

本文主要论述DNS基本原理,BIND正反向解析.主从同步.子域授权及view 1.DNS基本原理 DNS:Domain Name Service,域名服务器,基于udp和tcp完成名称解析服务 C/S架构的协议--客户端.服务端:监听于53/udp,53/tcp两个端口:属于应用层协议 BIND:Bekerley Internat Name Domain-->ISC BIND是DNS在互联网上最著名的实现,提供DNS和DHCP服务 DNS查询类型: 递归查询:一般客户机和服务器之间属递归查询,即

DNS&BIND——动态更新的DNS主从复制

本文配置的正向解析的主从服务,反向同理,不赘述了.... 从服务器应该是一台独立的名称服务器(首先要成为缓存服务器) 主动通知的必要条件(i或ii,满足其一即可) 主服务器的区域解析库文件中,必须有一条NS记录是指向从服务器(主动通知) master: vim  /etc/named.rfc1912.zones also-notify {slave_ip;}; 从服务器只需要定义区域.而无需提供解析库文件; 解析库文件自动同步至/var/named/slaves目录中 主服务器得允许从服务器作区

DNS&BIND——基础知识

DNS & BIND(1) what-DNS& BIND DNS: Domain Name Service 已于C/S架构的协议 53/udp:  域名解析 53/tcp  :  区域传输 BIND: Bekerley Internet Name Domain BIND对DNS协议的开源实现,包含对域名的查询和响应所需的所有软件 BIND是互联网上最广泛使用的一种DNS服务器 传输方式 1)区域传输 的时候使用TCP协议 : 主DNS服务器: 从自己本机的数据文件中读取该区的DNS数据信息

DNS&BIND——DNS的ACL和视图

bind中的基础安全相关配置 (一)ACL定义:把一个或多个主机归并为一个集合,并通过一个统一的名称调用 acl acl_name{ ip; ip; net/prelen;} ; 实例: acl mynet{机 172.25.0.0/46;}; bind 由四个内置的aclnone:    没有一个主机any:     任意主机local:   本机localnet:本机的IP同掩码运算后得到的网络地址   注意:    acl,先定义后使用,一般定义在配置文件中的option前面 访问控制的指

DNS&BIND——源码编译bind9和DNS的压力测试

源码编译bind9 why-Source installation-bind9 安装rpm包那么方便,为什么要手动编译bind9呢,因为编译安装可以按照自己的需求拓展相应的模块,可以增加软件的灵活性哦~ how-Source installation-bind9 安装编译环境 编译源码通常都需要安装Devel包等~~~ [[email protected] yum.repos.d]# yum groupinstall "Development Tools" "Server P

Linux DNS (bind) 子域授权

一个区域内可能有主DNS.从DNS.子域DNS,本节以主DNS授权子域为例讲解. 子域授权配置过程: 1.编辑主DNS正向区域文件 [[email protected] named]# vim dove.com.zone    #编辑主DNS正向区域文件 $TTL    600 @       IN      SOA     dove.com.       admin.dove.com. (            2015041802   #由于有从DNS服务器,所以序列号每次修改须加一    

Linux DNS服务系列之原理介绍及正反向解析配置

前言 我们在访问一个网站的时候,只要输入该网站的网址就会跳转到该网站页面,而实现这一过程就需要DNS服务器将域名解析为IP地址,进而实现数据通信.那么DNS服务器是如何工作的呢?本系列分为两部分,本文将详解DNS服务原理及正反向解析配置. DNS服务原理详解 DNS相关知识 DNS:Domain Name Service,域名解析服务 监听端口:udp/53,tcp/53 应用程序:bind 根域:. 一级域: 组织域:.com, .org, .net, .mil, .edu, .gov, .i

Linux上-DNS(bind)搭建2015091601

1.DNS的基础概念 2.DNS域名解析查询过程 3.DNS基本服务的实现 4.DNS主从同步的实现 5.DNS的高级视图功能     本机的相关信息: [[email protected] ~]#uname –r   //查看当前系统的内核版本 2.6.32-504.el6.x86_64 [[email protected] ~]#cat /etc/redhat-release    //查看当前系统的发行版本 CentOS release6.6 (Final) [[email protect

DNS(BIND) 视图的简单应用

实验os DNS 服务器 centos 6.6  10.211.55.6 测试机          centos 6.6  10.211.55.18 测试机          centos 6.6   10.211.55.19 不同ip访问实现dns解析不同结果,知识包含bind acl和view的应用. 配置文件 /etc/named.conf acl列表先规定才能引用,一般定义在配置文件开头 acl  访问控制列表  定义来至不同测试机的ip view 定义视图   视图必须包含zone的信