137人参与 • 2024-08-06 • 云计算
作者:羿莉 (萧羿)
dns(domain name system) [ 1] 是任何网络活动的基础。它将易于记忆的域名转换为机器能够理解的 ip 地址。监控 dns 服务可以帮助用户识别网络活动并保持系统安全。出于合规和安全性的考虑,公司通常要求对网络日志进行存储和分析。通过 dns 日志,可以清晰了解企业域名解析的使用情况,于发现配置错误和不必要的网络障碍,减少系统中断,在帮助企业对用户行为、网络行为进行审计的同时,及时发现潜在的安全问题。
dns 查询的结果通常会在本地域名服务器中进行缓存,如果本地域名服务器中有缓存的情况下,则会跳过如下 dns 查询步骤,很快返回解析结果。下面的示例则概述了本地域名服务器没有缓存的情况下,dns 查询所需的几个步骤:
dns(域名系统)中存在多种不同类型的记录,每种记录类型有特定的用途。以下是一些最常见的 dns 记录类型及其解释:
以上是一些基本的 dns 记录类型,每种类型在日常网络和域名的解析中扮演着重要角色。
日志审计服务 [ 2] 是阿里云日志服务 sls [ 3] 平台下的一款应用,它在继承了日志服务 sls 的全部功能以外,还有强大的多账号管理及跨地域采集阿里云各种云产品日志的功能,并且支持通过资源目录 [ 4] (resource directory)的方式有组织性地统一地管理和记录多账号下云产品实例的日志信息。
登录 sls 产品控制台 [ 5] 。
在日志应用 栏选择审计与安全 页签,然后单击日志审计服务。
日志审计现已支持内网 dns 日志、公网 dns 解析日志、全局流量管理日志这三种日志类型,用户可以按需开启。
此外,除了基础存储、查询、告警等 sls 功能外,还支持跨账号 [ 7] 采集、精细化采集策略 [ 8] 、terraform [ 9] 配置等功能。此处不详细展开,用户可以参考内网 dns 日志转存 sls [ 10] 进行配置使用。
具体的日志字段内容,及解释请参见附录。
日志审计会自动开启用户满足采集策略的地域及 vpc 实例的流量分析功能,详情参见开启 dns 内网日志采集 [ 11] 。开启流量分析功能后,日志会自动转存投递到用户的日志审计 dns 专属库 dns_log 中,下面是具体日志内容及相应字段含义的解释介绍。
例如我们查询阿里云日志服务控制台 sls.console.aliyun.com 的 ip 地址。
dig sls.console.aliyun.com +short
在该请求日志内容中,可以看到会话请求 id 为 50999,该 id 会在后续模块应答日志中继续复用,直至得到完整请求应答日志, 请求域名服务器为内网 ecs 的 ip 地址172.16.0.184,响应地址为阿里云内置域名解析服务地址 100.100.2.136,响应端口为 53。
请求日志模块为 global,请求域名为完全限定域名 [1****2] sls.console.aliyun.com.,dns 记录类型为 a 类,请求发出的 ecs 所属的实例在 cn-hangzhou 地域,其 vpc id 为 vpc-bp9fj,ecs 主机 id 为 i-bp19d7,主机名为izbp********d7z,主机所属账号为 148**********782,dns 信息标志为 rd ad ,具体细节可参见附录日志字段说明。
发出请求后,首先得到一条递归模块应答日志,从根域名服务器开启递归,得到sls.console.aliyun.com. 的 cname 记录为 sls-console-adns.console.aliyun.com.
然后继续查询 sls-console-adns.console.aliyun.com. 得到一条缓存模块应答日志,其对应的 cname 记录为 sls-console-adns.console.aliyun.com.gds.alibabadns.com.
继续查询 sls-console-adns.console.aliyun.com.gds.alibabadns.com. 得到对应的缓存模块应答日志,其 cname 记录为 tyjr-cn-hangzhou.aliyun.com.
继续查询 tyjr-cn-hangzhou.aliyun.com. 找到缓存应答模块对应的 cname 记录为 tyjr-cn-hangzhou.aliyun.com.vipgds.alibabadns.com.
追溯到域名 tyjr-cn-hangzhou.aliyun.com.vipgds.alibabadns.com. 后,得到对应的资源记录应答集合,并找到其真正的 a 记录地址例如 47.97.242.13。
最后我们得到一条完整的全局应答日志,从而找到 sls.console.aliyun.com. 对应的 ip 地址。
首先用户需要进入 dns 控制台 [ 13] ,添加对应的域名,并打开相应域名下的 dns 流量分析功能。
dig y*****.online @dns27.hichina.com
当前公网解析日志仅包含响应模块,在 sls 日志审计下可以得到如下的响应日志,其结果是一条 soa 记录,指定关于该区域的权威信息,如 dns 区域的主名称服务器,区域的管理员,ttl 等信息。
首先用户需要进入 dns 控制台,全局流量管理界面,购买全局流量管理实例,并创建接入域名。
dig ti*****.g****.net +vc
其响应日志内容记录在日志审计中如下:
因为 dns 日志包含了丰富的信息,所以知道这些字段的具体解释,以及这些字段出现异常时,其内容所代表的特殊意义,对于我们在网络安全和网络性能中排查定位将会提供很大帮助。下面,本文大概总结了一些在监控 dns 日志时安全运营人员应该注意的信号,掌握这些信号就可以快速而轻松地发现问题。详情可参见附录中日志字段的详细介绍。
下面我们通过几个具体的实践案例,深入体验如何洞察 dns 日志。
通过对 dns 数据包"请求阶段"中的解析路径进行划分,我们将 dns 解析路径分为四类。
以下三类均属于 dns 解析路径劫持:
下面我们将构造一个直接应答的解析路径劫持实验:
1)正常请求返回及日志审计 dns 日志记录如下:
dig aaa.y******.online
在 sls 日志审计的 dns_log 可以看到正常的权威解析的资源记录集 ["y******.online. 600 soa dns27.hichina.com. hostmaster.hichina.com. 2024060609 3600 1200 86400 600 "],对应的权威 dns 解析服务器为 dns27.hichina.com,因为没有配置对应的 ip 记录,所以应答资源记录集为空。
2)自建 dns 服务器,并配置记录,更改 nameserver 配置
接下来,我们基于 bind [ 15] 自建一个 dns 解析服务器,其 ns 地址为 172.16.0.186,在该 dns 服务器的 zone 数据库文件(y*****.online.zone)下配置一条记录:
[aaa a 172.16.0.189]
3)然后我们修改本地 nameserver,将其地址指向我们自建的 dns 服务器
4)自建 dns 服务器直接应答,跳过前往权威 dns 服务器查询请求过程
此时 dig aaa.y******.online. 返回的 ip 地址为 172.16.0.189,即我们在自建 dns 解析服务器配置的 a 记录返回。没有经过权威解析服务器的请求流程,直接应答一个结果,从而将 aaa.y******.online 域名的访问劫持到我们指定的 ip 地址。
下面展示一个 private zone 域名转发 的日志洞察示例,比如由于某些业务场景安全需要,需要将某些服务的域名访问地址从公网方式(.xxx.com)切换到 vpc 内网方式( -vpc-inner.region.xxx.com),而当前线上业务应用部署复杂,业务切换流依赖较多,直接进行业务代码切换的复杂性太大,很容易影响上下游业务,这个时候我们可以通过简单 privatezone 域名转发的案例进行域名切换,从而实现平滑业务流程,无损且快捷地切换到对应链路,而 dns 解析日志可以帮助我们验证域名转发是否配置正确,符合期望。
1)此时我们请求域名 ***.xxx.com.
2)经过 private zone 域名转发,经过权威普通模块,得到一个 cname 记录 ***-vpc-inner.cn-hangzhou.xxx.com.,以下为模块应答日志。
继续递归,得到 ***-vpc-inner.cn-hangzhou.xxx.com. 的 cname 记录 ***-vpc-inner.cn-hangzhou.xxx.com.yyy.zzz.com.
继续递归,得到 ***-vpc-inner.cn-hangzhou.xxx.com.yyy.zzz.com. 的 cname 记录 -vpc-inner.cn-hangzhou.xxx.com..com.
等走完全部递归查询,可以得到真正的 ip 地址为 100...35。
3)最终我们得到完整应答日志,得到 ***.xxx.com. 请求所对应的真正的解析地址 ip 记录。因为日志中有完整的 vpc、ecs id、ecs hostname 信息,后续出现问题,安全运维人员可以直接排查定位,判断 dns 解析路径是否符合期望。
rcode 是作为应答日志可以反映基本的解析状态,rcode 返回值 servfail(2) 或者 nxdomain (3)是两个较为典型且常见的解析失败场景,前者说明 dns 服务器遇到内部错误或者超时引起的解析失败,后者表示这个域名并未找到。此时我们结合具体的用户阿里云 uid 信息,和具体的 ecs 信息(内网场景)则可以更快捷地定位到此时出现问题的服务。下表是查找访问不存在的域名(rcode=3)的汇总统计记录。
rcode :3 and global | select distinct(query_name), ecs_hostname, region_id, vpc_id, user_id
前文已经提到,query_name 字段如果出现安全异常值(例如安全威胁库中已知的恶意地址),则可以作为一个非常直观的安全威胁的证据指标,另外某些 query_name 的解析量飙升,也可以作为判断 dos 攻击的依据,下面是一个 vpc 下,通过全局响应日志进行 query_name 统计的图表示例,如果从中发现了对某些已知恶意域名的访问,则可以进一步排查,找到安全威胁:
* and vpc_id: vpc-j6cd*****mgkrt6 and ( region_id : cn-hongkong ) and global and ( region_id : cn-hongkong ) and rcode: 0 |select count(*) as total_req, query_name group by query_name
正常情况下域名的解析请求量维持在一个可控平稳的范围(如下图),如果出现某个域名的请求量出现陡增,例如从 20 次/min 提升到了 1000 次/min,说明该域名可能遭受了攻击,可以通过创建告警分组评估 [ 16] ,分别监控需要特殊关注的域名目标,通知到响应的安全运维人员处。
* and vpc_id: vpc-j6cd*****mgkrt6 and ( region_id : cn-hongkong ) and global and rcode: 0 |select date_trunc('minute', __time__ )as t , query_name, count(*) as total_req group by t, query_name
解析响应时间异常同样值得引发注意,这里我们仅用全局应答日志的 rt 进行统计分析,全局应答日志的 rt 是表示整个查询到应答的时延,解析路径的各个模块也包括在内,因为有 cache 模块的存在,正常情况下响应时延在一个可控范围。如果某个域名的 rt 突然提升,有可能是因为用户的 dns 服务器网络配置存在问题,或者是遭遇了网络攻击,此时的域名解析服务器已经不堪重负,因此 rt 的统计分析也是非常有价值的观测指标。
* and vpc_id: vpc-j6cd*****mgkrt6 and ( region_id : cn-hongkong ) and global and rcode: 0 |select date_trunc('minute', __time__ )as t , query_name, avg(rt)
as avg_rt where rt>=60 group by t, query_name
附录
dns 日志字段
相关链接:
[1] dns(domain name system)
https://help.aliyun.com/zh/dns/basic-concepts
[2] 日志审计服务
https://help.aliyun.com/zh/sls/user-guide/overview-of-log-audit-service
[3] 日志服务 sls
https://help.aliyun.com/zh/sls/product-overview/what-is-log-service
[4] 资源目录
https://help.aliyun.com/zh/resource-management/product-overview/what-is-resource-management
[5] sls 产品控制台
https://sls.console.aliyun.com/lognext/profile
[6] 开启日志采集功能
https://help.aliyun.com/zh/sls/user-guide/enable-log-collection-1#section-h4b-mzq-ed1
[7] 跨账号
https://help.aliyun.com/zh/sls/user-guide/configure-multi-account-collection?spm=a2c4g.11186623.0.i4
[8] 采集策略
[9] terraform
[10] 内网 dns 日志转存 sls
[11] 开启 dns 内网日志采集
[12] 完全限定域名
https://en.wikipedia.org/wiki/fully_qualified_domain_name
[13] dns 控制台
https://dns.console.aliyun.com/
[14] fqdn
https://en.wikipedia.org/wiki/fully_qualified_domain_name
[15] bind
https://bind9.readthedocs.io/en/v9.18.14/chapter1.html
[16] 分组评估
https://help.aliyun.com/zh/sls/user-guide/use-the-group-evaluation-feature
您想发表意见!!点此发布评论
版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。
发表评论