从安全的角度看待DNS

以前对DNS(Domain Name System)熟悉就也许的知道是一个提供域名解析服务,作为互联网的基础设施,任何一个IT职员都市或多或少都接触到DNS,随着我最近的接触不断提高,我发现DNS照样有许多细节手艺需要熟悉和掌握的,本文以一个中型互联网企业搭建域DNS服务器架构为基础,从平安的角度看待DNS举行形貌,都是一些经验之谈,希望读者能有所收获。

DNS协议

DNS通过开放53端口,通过该端口来监听请求并提供响应的服务,DNS 监听 TCP 和 UDP 都是 53 端口。若是攻击职员在扫描主机端口的时刻发现一台主机开放了53端口,那么就可以判断这是一台DNS服务器,而且对外了。对外开放53端口,也就意味着运行外部对这台DNS服务器举行平安扫描,若何举行平安扫描,DNS会有哪些平安问题,后面会说。

出于性能的思量,DNS查询请求用UDP协议交互而且每个请求的巨细小于512字节,然则若是返回的请求巨细大于512字节,交互双方会协商使用TCP协议。

DNS查询

说完DNS的端口,那就接着说DNS的服务,DNS提供出来的就是域名解析服务(将域名转换为IP地址的历程),这个服务是怎么实现域名解析服务的?我说一下也许查询历程(如下两张图)

从安全的角度看待DNS

从安全的角度看待DNS

假设你想接见 sspai.com 这个网站,那么就如走这个流程

  • 先问 客户端(内陆主机)DNS服务器
  • 再问 局部(局域网)DNS域服务器
  • 再去问 根域名
  • 最后问 顶级域名服务器

若是使用类linux系统,可以使用 dig 下令来显示整个分级查询的历程,

  ~ dig +trace sspai.com

; <<>> DiG 9.10.6 <<>> +trace sspai.com
;; global options: +cmd


# 第一段列出根域名.的所有NS纪录,即所有根域名服务器。
.			3600	IN	NS	d.root-servers.net.
.			3600	IN	NS	k.root-servers.net.
.			3600	IN	NS	j.root-servers.net.
.			3600	IN	NS	a.root-servers.net.
.			3600	IN	NS	b.root-servers.net.
.			3600	IN	NS	e.root-servers.net.
.			3600	IN	NS	f.root-servers.net.
.			3600	IN	NS	h.root-servers.net.
.			3600	IN	NS	c.root-servers.net.
.			3600	IN	NS	i.root-servers.net.
.			3600	IN	NS	g.root-servers.net.
.			3600	IN	NS	l.root-servers.net.
.			3600	IN	NS	m.root-servers.net.
;; Received 472 bytes from 10.249.150.1#53(10.249.150.1) in 1 ms


# 接着询问sspai.com的顶级域 com.的NS纪录
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.
com.			86400	IN	DS	30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.			86400	IN	RRSIG	DS 8 1 86400 20200801170000 20200719160000 46594 . nl6GGtQwgNAf1YLcWFFcQyXZ1BE/E5dhOVVBIxTCl0QNtvt9sb+btQIM NOVpc6JovoxxfXvDxotRmCqVe9BJunaZvCqMGySy8JdFTcSo1kdVKXvU nI+b3mad5ROgvP2GaUZelhRIn7++FIQAjSUl40H/jdaQP2fxXDH1PQ4B oBhQwnlDo/rn3AJxhH+P2hx/23fadNwsmh/WY9truU1Gv4cf+uwAPkE9 QFSKDcDF7VgTF1bHN9A9nuURQXIjGQkZAGUHaR9bIrKtgYDa3szrmdOJ GejllYy4VyKoBxwZLkV+W7gt+ODYXxAz42UFk5VOGF560wfCIM11FSYR +XPqPg==
;; Received 1169 bytes from 192.36.148.17#53(i.root-servers.net) in 65 ms


# 询问sspai.com的次级域名 NS纪录
sspai.com.		172800	IN	NS	dns17.hichina.com.
sspai.com.		172800	IN	NS	dns18.hichina.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A  NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20200724044108 20200717033108 24966 com. Tf4OQOpeShS1V8R5W7+YWbLa+iIn/wJf3iDfMsHf4P7TJ1ZBm+1EC4FB bdE2Xcyi9wFIetecgTseEQGLYEKdwUBx6mqGmR3nHMaRDl+4Sm+hBufD UUR+2sGFNM/KMWC5zgm7nLc4wHBSrsq8T36nache8cXBhEWSEvR+MIGw o1fJdUNWhihU/maM05P4wrigqDw5igwIkDZZ1O3Fz5uwnQ==
M34OU778JRD89U2DUUTAAI48T6FEI7CV.com. 86400 IN NSEC3 1 1 0 - M34P2GDRCOK7PL50LT2A785I7P76KSGS  NS DS RRSIG
M34OU778JRD89U2DUUTAAI48T6FEI7CV.com. 86400 IN RRSIG NSEC3 8 2 86400 20200725051418 20200718040418 24966 com. Fis/2uVliOd9QYjFtzH0SVeSU4lAtekdPXOlqU5Zp+IxDXOovSM31wmL YD9zQRdfecDoiurSZi/yZceE2HxgWyWDc1epW7gTQYGOr99s7dxA08dm +gZZIExIIYNpc1MzSqktmLQuOg9yyUQwyf1YWCrQF8d+e3/fdPxFBunf j2psiF3BKzhPt5tlzfx98Gu8pckCBk9pV3xFXCAv5Vx0/A==
;; Received 947 bytes from 192.41.162.30#53(l.gtld-servers.net) in 177 ms


## 查询到有一条A纪录,通过这个IP(119.23.141.248) 地址就可以接见到这个网站
sspai.com.		600	IN	A	119.23.141.248
;; Received 54 bytes from 140.205.41.28#53(dns18.hichina.com) in 31 ms

而详细实现这个查询历程的手艺有

  • 递归查询
  • 迭代查询
  • 反向查询

这里的每种查询手艺都不简朴,迭代、递归查询也是实现DNS服务的焦点,但不是我这篇文章想讲述的重点,以是忽略。想领会细节的可以自己查询一下网络资料,反向查询有挺多平安知识的,我就单独写成一篇文章了:https://www.cnblogs.com/mysticbinary/p/13344930.html

集成Facebook SDK之Facebook登录

查询的手艺细节可以不用体贴,然则常见的DNS纪录类型照样要体贴的:

A:地址纪录(Address),返回域名指向的IP地址。
AAAA :A 纪录处置 IPV4,AAAA 处置 IPV6。

SOA :起始授权机构纪录,SOA 备注说明晰众多 NS(name server)纪录中谁是主名称服务器,不介入功效,然则不能缺少。
NS:域名服务器纪录(Name Server),返回保留下一级域名信息的服务器地址。该纪录只能设置为域名,不能设置为IP地址。

MX:邮件纪录(Mail eXchange),返回吸收电子邮件的服务器地址。

CNAME:规范名称纪录(Canonical Name),返回另一个域名,即当前查询的域名是另一个域名的跳转(类似302跳转)。

PTR:逆向查询纪录(Pointer Record),只用于从IP地址查询域名。

准许我!下次你在看到A、AAAA、SOA、NS、MX、CNAME、PTR一定要一秒之内想出他们是干嘛的。由于太重要了。
准许我!下次你在看到A、AAAA、SOA、NS、MX、CNAME、PTR一定要一秒之内想出他们是干嘛的。由于太重要了。
准许我!下次你在看到A、AAAA、SOA、NS、MX、CNAME、PTR一定要一秒之内想出他们是干嘛的。由于太重要了。

从平安的角度上看,为了保证服务的平安可靠,至少应该有两条NS纪录,而A纪录和MX纪录也可以有多条,这样就提供了服务的冗余性,防止泛起单点失败。

域维护

由于DNS服务就是一个类似分布式的服务,分布式就是涣散的,若何保证各个涣散的机械能实时的同步新闻呢?在主域名服务器和从域名服务器之间维护同一个zone文件。可以简朴的理解为,DNS设定一个协议来在主域名服务器和从域名服务器之间维护同一个zone文件。主要有以下两种同步的手段有:

  • 全量传输 AXFR (full zone transfer)
    就是设定一个牢固时间(好比2分钟一次),就同步一次zone文件
  • 增量传输 IXFR (incremental zone transfer)
    通报异常大的zone文件是异常耗资源的(时间、带宽等),尤其是只有zone中的一个纪录改变的时刻,没有必要通报整个zone文件,增量传输是允许主域名服务器和从域名服务器之间只传输那些改变的纪录。

ZONE文件是DNS上保留域名设置的文件,一个域名对应一个ZONE文件。

若是你的企业局域网只有一台DNS服务器,那么就不需要AXFR、IXFR
从安全的角度看待DNS

若是你的企业局域网有多台DNS服务器,那么就需要AXFR、IXFR
从安全的角度看待DNS

做DNS监控,就会用到ES手艺,通过纪录,你会发现你纪录的DNS服务器clientIp为127.0.0.1,而且在牢固周期就会传输AXFR类型的Domain。
从安全的角度看待DNS

DNS平安

DNS自己的DNS服务破绽、区域转发设置错误、找真实IP绕过WAF等,都是常见的DNS平安,今天就到这把,后续有精神在写了…..

参考

http://www.ruanyifeng.com/blog/2016/06/dns.html
https://www.cnblogs.com/cobbliu/archive/2013/03/24/2979521.html
https://www.cnblogs.com/bluestorm/p/10345334.html
https://www.cnblogs.com/Dy1an/p/11157152.html

原创文章,作者:28x29新闻网,如若转载,请注明出处:https://www.28x29.com/archives/23602.html