黑客技术没你想象的那么难——dns劫持篇什么是DNS劫持DNS劫持就是通过劫持了DNS服务器通过某些手段取得某域名的解析记录控制权进而修改此域名的解析结果导致对该域名的访问由原IP地址转入到修改后的指定IP其结果就是对特定的网址不能访问或访问的是假网址从而实现窃取资料或者破坏原有正常服务的目的。DNS劫持通过篡改DNS服务器上的数据返回给用户一个错误的查询结果来实现的。DNS劫持症状在某些地区的用户在成功连接宽带后首次打开任何页面都指向ISP提供的“电信互联星空”、“网通黄页广告”等内容页面。还有就是曾经出现过用户访问Google域名的时候出现了百度的网站。这些都属于DNS劫持。再说简单点当你输入google.com这个网址的时候你看到的网站却是百度的首页。目录一、什么是DNS二、DNS原理三、什么是DNS劫持及危害四、DNS劫持方法五、如何防止DNS劫持网络层面六、如何防止DNS劫持应用层面七、历史著名劫持案例一、什么是DNS在网络中机器之间只认识IP地址机器之间最终都要通过IP来互相访问。但是为了方便记忆可以为IP地址设置一个对应的域名通过访问域名就可以找到对应IP地址的网站。比如我们访问今日头条官网的时候在浏览器地址栏输入头条地址https://www.toutiao.com/看似我们访问的是域名而实际上是通过IP地址访问的今日头条官网。可以在终端命令窗口ping 今日头条官网域名就可以看到该域名对应的IP地址了。从 www.toutiao.com 到 202.108.250.213 的转换工作称为域名解析域名解析需要由专门的域名解析服务器来完成DNS就是进行域名解析的服务器Domain Name System 或Domain Name Service。注直接使用 202.108.250.213是无法访问今日头条官网的这是因为今日头条的服务器做了设置限制IP访问。一般的网站会选择放在虚拟主机且在主机上放置了很多个网站而每个网站绑定1个或以上域名、虚拟主机上。例如Apache主机的配置会将对应的ip解析到对应的网站目录的实现一台服务器上配置多个站点一般用户在访问的时候会产生一个http请求报文上面的host信息可以提供给服务器告诉服务器要访问的域名从而实现一台主机绑定一个IP即使有多个网站也不会相互干扰。但使用IP访问主机不知道用户访问的具体目录请求便会出现错误。二、DNS原理DNS 查询时会先在本地缓存中尝试查找如果不存在或是记录过期就继续向 DNS 服务器发起递归查询,这里的 DNS 服务器一般就是运营商的 DNS 服务器。1、DNS工作原理第一步客户机提出域名解析请求并将该请求发送给本地的域名服务器。第二步当本地的域名服务器收到请求后就先查询本地的缓存如果有该纪录项则本地的域名服务器就直接把查询的结果域名对应的IP地址返回。第三步如果本地的缓存中没有该纪录则本地域名服务器就直接把请求发给根域名服务器然后根域名服务器再返回给本地域名服务器一个所查询域(根的子域) 的主域名服务器的地址。第四步本地服务器再向上一步返回的域名服务器发送请求然后接受请求的服务器查询自己的缓存如果没有该纪录则返回相关的下级的域名服务器的地址。第五步重复第四步直到找到正确的纪录。第六步本地域名服务器把返回的结果保存到缓存以备下一次使用同时还将结果返回给客户机。2、查询过程虽然只需要返回一个IP地址但是DNS的查询过程非常复杂分成多个步骤。工具软件dig可以显示整个查询过程。$ dig math.stackexchange.com上面的命令会输出六段信息。第一段是查询参数和统计。第二段是查询内容。上面结果表示查询域名 math.stackexchange.com 的A记录A是address的缩写。第三段是DNS服务器的答复。上面结果显示math.stackexchange.com有四个A记录即四个IP地址。600是TTL值Time to live 的缩写表示缓存时间即600秒之内不用重新查询。第四段显示 stackexchange.com的NS记录Name Server的缩写即哪些服务器负责管理stackexchange.com的DNS记录。上面结果显示stackexchange.com共有四条NS记录即四个域名服务器向其中任一台查询就能知道stackexchange.com的IP地址是什么。第五段是上面四个域名服务器的IP地址这是随着前一段一起返回的。第六段是DNS服务器的一些传输信息。上面结果显示本机的DNS服务器是192.168.1.253查询端口是53DNS服务器的默认端口以及回应长度是305字节。如果不想看到这么多内容可以使用short 参数。$ dig short math.stackexchange.com#返回151.101.129.69151.101.65.69151.101.193.69151.101.1.69上面命令只返回math.stackexchange.com对应的4个IP地址即A记录。3、DNS服务器下面我们根据前面这个例子一步步还原本机到底怎么得到域名math.stackexchange.com的IP地址。首先本机一定要知道DNS服务器的IP地址否则上不了网。通过DNS服务器才能知道某个域名的IP地址到底是什么。DNS服务器的IP地址有可能是动态的每次上网时由网关分配这叫做DHCP机制也有可能是事先指定的固定地址。Linux系统里面DNS服务器的IP地址保存在/etc/resolv.conf文件。上例的DNS服务器是192.168.1.253这是一个内网地址。有一些公网的DNS服务器也可以使用其中最有名的就是Google的8.8.8.8和Level 3的4.2.2.2。本机只向自己的DNS服务器查询dig命令有一个参数显示向其他DNS服务器查询的结果。$ dig 4.2.2.2 math.stackexchange.com上面命令指定向DNS服务器4.2.2.2查询。4、域名的层级DNS服务器怎么会知道每个域名的IP地址呢答案是分级查询。请仔细看前面的例子每个域名的尾部都多了一个点。比如域名math.stackexchange.com显示为math.stackexchange.com. 这不是疏忽而是所有域名的尾部实际上都有一个根域名。举例来说www.example.com真正的域名是www.example.com.root简写为www.example.com.。因为根域名.root对于所有域名都是一样的所以平时是省略的。根域名的下一级叫做顶级域名top-level domain缩写为TLD比如.com、.net再下一级叫做次级域名second-level domain缩写为SLD比如www.example.com里面的.example这一级域名是用户可以注册的再下一级是主机名host比如www.example.com里面的www又称为三级域名这是用户在自己的域里面为服务器分配的名称是用户可以任意分配的。总结一下域名的层级结构如下。主机名.次级域名.顶级域名.根域名即host.sld.tld.root5、根域名服务器DNS服务器根据域名的层级进行分级查询。需要明确的是每一级域名都有自己的NS记录NS记录指向该级域名的域名服务器。这些服务器知道下一级域名的各种记录。所谓分级查询就是从根域名开始依次查询每一级域名的NS记录直到查到最终的IP地址过程大致如下。从根域名服务器查到顶级域名服务器的NS记录和A记录IP地址从顶级域名服务器查到次级域名服务器的NS记录和A记录IP地址从次级域名服务器查出主机名的IP地址仔细看上面的过程你可能发现了没有提到DNS服务器怎么知道根域名服务器的IP地址。回答是根域名服务器的NS记录和IP地址一般是不会变化的所以内置在DNS服务器里面。下面是内置的根域名服务器IP地址的一个例子。上面列表中列出了根域名.root的三条NS记录A.ROOT-SERVERS.NET、B.ROOT-SERVERS.NET、C.ROOT-SERVERS.NET以及它们的IP地址即A记录198.41.0.4、192.228.79.201、192.33.4.12。另外可以看到所有记录的TTL值是3600000秒相当于1000小时。也就是说每1000小时才查询一次根域名服务器的列表。目前世界上一共有十三组根域名服务器从A.ROOT-SERVERS.NET 到M.ROOT-SERVERS.NET。6、分级查询的实例dig 命令的trace参数可以显示DNS的整个分级查询过程。$ dig trace math.stackexchange.com上面命令的第一段列出根域名.的所有NS记录即所有根域名服务器。根据内置的根域名服务器IP地址DNS服务器向所有这些IP地址发出查询请求询问math.stackexchange.com的顶级域名服务器com的NS记录。最先回复的根域名服务器将被缓存以后只向这台服务器发请求。接着是第二段。上面结果显示.com域名的13条NS记录同时返回的还有每一条记录对应的IP地址。然后DNS服务器向这些顶级域名服务器发出查询请求询问math.stackexchange.com 的次级域名stackexchange.com的NS记录。上面结果显示 stackexchange.com 有四条NS记录同时返回的还有每一条NS记录对应的IP地址。然后DNS服务器向上面这四台NS服务器查询 match.stackexchange.com的主机名。上面结果显示match.stackexchange.com有4条A记录即这四个IP地址都可以访问到网站。并且还显示最先返回结果的NS服务器是ns-463.awsdns-57.comIP地址为205.251.193.207。7、NS 记录的查询dig命令可以单独查看每一级域名的NS记录。$ dig ns com$ dig ns stackexchange.comshort参数可以显示简化的结果。$ dig short ns com$ dig short ns stackexchange.com8、DNS的记录类型域名与IP之间的对应关系称为记录record。根据使用场景记录可以分成不同的类型type前面已经看到了有A记录和NS记录。常见的DNS记录类型如下。A地址记录Address返回域名指向的IP地址。NS域名服务器记录Name Server返回保存下一级域名信息的服务器地址。该记录只能设置为域名不能设置为IP地址。MX邮件记录Mail eXchange返回接收电子邮件的服务器地址。CNAME规范名称记录Canonical Name返回另一个域名即当前查询的域名是另一个域名的跳转详见下文。PTR逆向查询记录Pointer Record只用于从IP地址查询域名详见下文。一般来说为了服务的安全可靠至少应该有两条NS 记录而A记录和MX记录也可以有多条这样就提供了服务的冗余性防止出现单点失败。CNAME记录主要用于域名的内部跳转为服务器配置提供灵活性用户感知不到。举例来说facebook.github.io这个域名就是一个 CNAME记录。上面结果显示facebook.github.io的CNAME记录指向github.map.fastly.net。也就是说用户查询facebook.github.io的时候实际上返回的是github.map.fastly.net的IP地址。这样的好处是变更服务器IP地址的时候只要修改github.map.fastly.net这个域名就可以了用户的facebook.github.io域名不用修改。由于CNAME记录就是一个替换所以域名一旦设置CNAME记录以后就不能再设置其他记录了比如A记录和MX记录这是为了防止产生冲突。举例来说foo.com指向bar.com而两个域名各有自己的MX记录如果两者不一致就会产生问题。由于顶级域名通常要设置MX记录所以一般不允许用户对顶级域名设置CNAME记录。PTR记录用于从IP地址反查域名。dig 命令的-x参数用于查询PTR记录。上面结果显示192.30.252.153 这台服务器的域名是 pages.github.com。逆向查询的一个应用是可以防止垃圾邮件即验证发送邮件的IP地址是否真的有它所声称的域名。dig命令可以查看指定的记录类型。$ dig a github.com$ dig ns github.com$ dig mx github.com三、什么DNS劫持以及危害1、什么是DNS劫持DNS劫持又称域名劫持,是指通过某些手段取得某域名的解析控制权修改此域名的解析结果导致对该域名的访问由原IP地址转入到修改后的指定IP其结果就是对特定的网址不能访问或访问的是假网址。如果可以冒充域名服务器然后把查询的IP地址设为攻击者的IP地址这样的话用户上网就只能看到攻击者的主页而不是用户想要取得的网站的主页了这就是DNS劫持的基本原理。DNS劫持其实并不是真的“黑掉”了对方的网站而是冒名顶替、招摇撞骗罢了。2、DNS劫持危害钓鱼诈骗网上购物,网上支付有可能会被恶意指向别的网站更加加大了个人账户泄密的风险。网站内出现恶意广告轻则影响网速重则不能上网四、DNS劫持方法1、利用DNS服务器进行DDOS攻击正常的DNS服务器递归查询过程可能被利用成DDOS攻击。假设攻击者已知被攻击机器的IP地址然后攻击者使用该地址作为发送解析命令的源地址。这样当使用DNS服务器递归查询后DNS服务器响应给最初用户而这个用户正是被攻击者。那么如果攻击者控制了足够多的肉鸡反复的进行如上操作那么被攻击者就会受到来自于DNS服务器的响应信息DDOS攻击。如果攻击者拥有着足够多的肉鸡群那么就可以使被攻击者的网络被拖垮至发生中断。利用DNS服务器攻击的重要挑战是攻击者由于没有直接与被攻击主机进行通讯隐匿了自己行踪让受害者难以追查原始的攻击来。2、DNS缓存感染攻击者使用DNS请求将数据放入一个具有漏洞的的DNS服务器的缓存当中。这些缓存信息会在客户进行DNS访问时返回给用户从而把用户客户对正常域名的访问引导到入侵者所设置挂马、钓鱼等页面上或者通过伪造的邮件和其他的server服务获取用户口令信息导致客户遭遇进一步的侵害。3、DNS信息劫持TCP/IP体系通过序列号等多种方式避免仿冒数据的插入但入侵者如果通过监听客户端和DNS服务器的对话就可以猜测服务器响应给客户端的DNS查询ID。每个DNS报文包括一个相关联的16位ID号DNS服务器根据这个ID号获取请求源位置。攻击者在DNS服务器之前将虚假的响应交给用户从而欺骗客户端去访问恶意的网站。假设当提交给某个域名服务器的域名解析请求的DNS报文包数据被截获然后按截获者的意图将一个虚假的IP地址作为应答信息返回给请求者。原始请求者就会把这个虚假的IP地址作为它所要请求的域名而进行访问这样他就被欺骗到了别处而无法连接想要访问的那个域名。4、DNS重定向攻击者将DNS名称查询重定向到恶意DNS服务器上,被劫持域名的解析就完全在攻击者的控制之下。演示DNS重定向首先我们要用一个无线网卡来伪造ap。启动伪ap前的准备Ifconfig –a 查看当前网卡情况Ifconfig wlan0 up 激活无线网卡Airmon-ng start wlan0 将你的无线网卡开启“Monitor”模式如果这里有其他进程干扰的话就先把干扰进程kill掉再进行。在设置监听模式前先输入airmon-ng check kill结束进程。探测目标ap为伪ap的假设做准备airodump-ng wlan0mon.在上面探测ap中我们可以了解到WiFi名称ssid、加密方式以及信道等信息。接下来我们就可以启动伪ap了。airbase-ng wlan0mon -e “xiaoqin00” -c 6 这里环境不同启动方式也不一样我这里是kali2.0的环境所以这样以前版本启动方式为airbase-ng mon0 -e “xiaoqin00” -c 6这个时候我们就可收到我们伪造的ap了但是这个ap无法行使正常的功能你连接的话它会一直保持获取ip中的状态。接下来就需要我们配置和这个伪ap配套的dhcp了。apt-get install udhcpd修改/etc/udhcpd.conf配置文件自定义IP池、网关、DNS、interface等等。推荐用gedit工具来编辑文件gedit /etc/udhcpd.conf修改IP池192.168.x.y192.168.x.z修改执行dhcp功能的接口可以用过ifconfig -a或者iwconfig命令来查看接口修改DNS、网关、netmask等修改/etc/default/udhcpd修改dhcpd功能为yes。DHCPD_ENABLE“yes”开启dhcp服务service udhcpd start。配置好dhcp后我们还需要解决流量问题这里192.168.2.0/24中的流量需要通过主机网卡eth0与外界进行交互。我们用iptables来解决这个。再接着就是配置dns服务了。这里我们使用msf中的fakedns来提供dns服务。我们将http://xiaoqin00.com的域名劫持到192.168.2.1上。当这都配置好后我们来连接这个伪ap。现在只要被攻击者一进入www.xiaoqin00.com他就会被劫持到错误的站点这算是钓鱼的一种方法吧。当你完成这些之前如果目标主机已经连接上WiFi可以对它的WiFi用mdk3等工具进行ddos攻击强制目标断开连接。*在智能手机中如果两个WiFi一样那么手机会保持当前连接并对新出现的WiFi自动进行屏蔽。*构造伪dhcp服务器有很多种方法。5、ARP欺骗ARP攻击就是通过伪造IP地址和MAC地址实现ARP欺骗能够在网络中产生大量的ARP通信量使网络阻塞攻击者只要持续不断的发出伪造的ARP响应包就能更改目标主机ARP缓存中的IP-MAC条目造成网络中断或中间人攻击。ARP攻击主要是存在于局域网网络中局域网中若有一台计算机感染ARP病毒则感染该ARP病毒的系统将会试图通过”ARP欺骗”手段截获所在网络内其它计算机的通信信息并因此造成网内其它计算机的通信故障。ARP欺骗通常是在用户局域网中造成用户访问域名的错误指向。如果IDC机房也被ARP病毒入侵后则也可能出现攻击者采用ARP包压制正常主机、或者压制DNS服务器以使访问导向错误指向的情况。我们可以使用ettercap或者arpspoof来实现dns劫持。6、本机劫持本机的计算机系统被木马或流氓软件感染后也可能会出现部分域名的访问异常。如访问挂马或者钓鱼站点、无法访问等情况。本机DNS劫持方式包括hosts文件篡改、本机DNS劫持、SPI链注入、BHO插件等方式。本机dns劫持的操作比较简单就是将目标主机的dns缓存给偷偷篡改掉。上面我们已经知道了dns的查询过程是先查询本地dns文件找不到的话再去服务器查询。所以这种本机dns劫持的效果还是挺给力的。就像这样进入hosts文件改掉dns。等机主上机时如果他要访问www.xiaoqin00.com的话它的会话会被劫持到192.168.2.1上。当然你也可以破解路由器直接更改路由器的dns设置。五、如何防止DNS劫持网络层面1、互联网公司准备两个以上的域名一旦黑客进行DNS攻击用户还可以访问另一个域名。2、手动修改DNS在地址栏中输入http//192.168.1.1 如果页面不能显示可尝试输入http//192.168.0.1。填写您路由器的用户名和密码点击“确定”。在“DHCP服务器—DHCP”服务中填写主DNS服务器为更可靠的114.114.114.114地址备用DNS服务器为8.8.8.8点击保存即可。3、修改路由器密码在地址栏中输入http//192.168.1.1 如果页面不能显示可尝试输入http//192.168.0.1填写您路由器的用户名和密码路由器初始用户名为admin密码也是admin如果您修改过则填写修改后的用户名和密码点击“确定”填写正确后会进入路由器密码修改页面在系统工具——修改登录口令页面即可完成修改原用户名和口令和2中填写的一致六、如何防止DNS劫持应用层面本小节内容来自美图在HTTPS环境的DNS优化实践通过该优化方案使美图App请求耗时节约近半。真实案例提供给大家参考。美图的移动端产品在实际用户环境下会面临 DNS 劫持、耗时波动等问题这些 DNS 环节的不稳定因素导致后续网络请求被劫持或是直接失败, 对产品的用户体验产生不好的影响。为此对移动端产品的 DNS 解析进行了优化探索产生了相应的 SDK。在这过程中参考借鉴了业内的主流方案也进行了一些实践上的思考。下面的内容会主要以 Android 平台来进行说明。LocalDNS VS HTTP DNS在长期的实践中互联网公司发现 LocalDNS 会存在如下几个问题域名缓存: 运营商 DNS 缓存域名解析结果将用户导向网内缓存服务器;解析转发 出口 NAT: 运营商 DNS 转发查询请求或是出口 NAT 导致流量调度策略失效;为了解决 LocalDNS 的这些问题业内也催生了 HTTP DNS 的概念。它的基本原理如下:原本用户进行 DNS 解析是向运营商的 DNS 服务器发起 UDP 报文进行查询而在 HTTP DNS 下我们修改为用户带上待查询的域名和本机 IP 地址直接向 HTTP WEB 服务器发起 HTTP 请求这个 HTTP WEB 将返回域名解析后的 IP 地址。比如 DNSPod 的实现原理如下:相比 LocalDNS, HTTP DNS 会具备如下优势:根治域名解析异常: 绕过运营商的 DNS向具备 DNS 解析功能的 HTTP WEB 服务器发起查询;调度精准: HTTP DNS 能够直接获取到用户的 IP 地址从而实现准确导流;扩展性强: 本身基于 HTTP 协议可以实现更强大的功能扩展;那么是否直接全部走 HTTP DNS 呢?美图移动端 DNS 优化策略探索HTTP DNS 相比 LocalDNS 存在一些优势, 然而 HTTP DNS 本身也是存在一定的成本问题。美图的产品线丰富涉及的域名也较为广泛为了适应各产品的实际场景在实践中设计了较为灵活的策略控制。首先在策略上并未完全放弃 LocalDNS。一个 App 涉及的域名众多在策略上能够配置其核心 API 域名走 HTTP DNS而对于非核心请求仍希望它先尝试走 LocalDNS, 在异常情况下才升级走 HTTP DNS。那么如何判断 LocalDNS 的异常情况呢?选择一下三个指标来衡量一个 DNS 服务器的质量情况:IP 记录的 TTL 时间: 在 DNS 劫持发生的情况下返回的 TTL 可能会有非常大的值;解析耗时: 如果一个 DNS 服务器解析耗时不理想那么它也不是我们希望的;返回的 IP 的可连接性: 对返回的 IP 进行质量测试如果连接状况不佳那么这个 DNS 服务器有劫持的可疑;在 Android 平台上通过系统方法获得的解析结果信息是非常有限的上面的指标有的将无法获取因此在实践中我们会自己去构造 DNS 查询报文向运营商的多个 DNS 服务器发起查询。通过上面几个指标的综合评定当 LocalDNS 表现不佳的时候策略上我们将升级走 HTTP DNS尝试让用户获取更好的 DNS 解析效果。在 DNS 解析环节还有一个我们比较关心的指标那就是 DNS 解析的耗时LocalDNS 在过期的情况下会发起递归查询这个时间是不可控的在部分情况下甚至能达到数秒级别HTTP DNS 相对会好一些但正常来看也会有200ms 左右的耗时。这个时间能否再优化一些呢我们 SDK 在本地构建了自己的记录缓存池每次通过 LocalDNS 或是 HTTP DNS 解析得到记录都存在缓冲池中。当然这个是普遍的做法系统底层的 netdb 库也是这样实现。区别在于我们做了一个小改动对于过期的记录我们采用懒更新的策略当查到过期的缓存记录时先返回过期记录给用户同时再异步重新发起 DNS 查询更新缓存记录。这个小改动能够保证我们二次解析时都能命中本地缓存极大地降低 DNS 解析耗时不过它也带来了一定的风险性。因此实践中我们也会添加异步定期的 DNS 记录缓存池扫描功能及时发现缓存中的过期记录并进行更新也降低 App 命中过期记录的情况。无侵入的 SDK 接入方式探索在 DNS 优化的实践中我们遇到最大的问题倒不是策略层面设计问题而是我们的 DNS SDK 运用到实际 App 产品业务上的姿势问题。业内对 HTTP DNS 在实际业务中的接入方式多采用 IP 直连的形式即原本直接请求 http://www.meitu.com现在我们先调用 SDK 进行域名解析拿到 IP 地址比如 1.1.1.1然后替换域名为: http://1.1.1.1/这样操作之后 由于 URL 中 HOST 已经是 IP 地址网络请求库将跳过域名解析环节直接向 1.1.1.1 服务器发起 HTTP 请求。在实际操作中对于 IP 直连的方案我们踩了不少的坑。首先对于 HTTP 请求采用 IP 直连的方案后我们还是需要进行的一个操作是手动配置 Header 中的 HOST :HTTP 协议相对比较容易只需要处理 HOST那么 HTTPS 呢发起HTTPS请求首先需要进行 SSL/TLS 握手其流程如下:客户端发送 Client Hello携带随机数、支持的加密算法等信息;服务端收到请求后选择合适的加密算法连同公钥证书、随机数等信息返回给客户端;客户端检验服务端证书的合法性计算产生随机数并用证书公钥加密发送给服务端;服务端通过私钥获取随机数信息基于之前的交互信息计算得到协商密钥并通知给客户端;客户端验证服务端发送的数据和密钥通过后双方握手完成开始进行加密通信;在我们采用 IP 直连的形式后上述 HTTPS 的第三步会发生问题, 客户端检验服务端下发的证书这动作包含两个步骤:客户端用本地保存的根证书解开证书链确认服务端的证书是由可信任的机构颁发的。客户端需要检查证书的 Domain 域和扩展域是否包含本次请求的 HOST。证书的验证需要这两个步骤都检验通过才能够进行后续流程否则 SSL/TLS 握手将在这里失败结束。由于在 IP 直连下我们给网络请求库的 URL 中 host 部分已经被替换成了 IP 地址因此证书验证的第二步中默认配置下 “本次请求的 HOST” 会是一个 IP 地址这将导致 domain 检查不匹配最终 SSL/TLS 握手失败。那么该如何解决这个问题解决 SSL/TLS 握手中域名校验问题的方法在于我们重新配置 HostnameVerifier, 让请求库用实际的域名去做域名校验代码示例如下:我们又解决了一个问题那么 IP 直连下 HTTPS 的问题都搞定了吗没有HTTPS 还有 SNI 的场景要特殊处理。SNIServer Name Indication是为了解决一个服务器使用多个域名和证书的SSL/TLS扩展。它的基本工作原理如下服务端配置有多个域名和对应的证书。客户端在与服务器建立SSL链接之时,先发送自己要访问站点的域名。服务器根据这个域名返回一个合适的证书。跟上面 Domain 校验的情况类似这里的网络请求库默认发送给服务端的 “要访问站点的域名” 就是我们替换后的 IP 地址。服务端在收到这样一个 IP 地址形式的域名后将是一脸懵逼找不到对应的证书最后只好下发一个默认的域名证书回来。接下来发生的是客户端在检验证书的 Domain 域时怎么也检查不通过因为服务端下发的证书本来就不是对应该域名的。最后 SSL/TLS 握手失败告终。上述这个 SNI 场景下的问题我们是否有办法解决呢可以解决需用客户端重新定制 SSLSocketFactory , 不过修改的代码相对较多这里就不列举了。如果我们 SDK 要接入到 App 实际业务中到 HTTPS SNI 场景处理这里相信很多同学都崩溃了接入的工作量其实也不低。很多情况下可能就做了妥协只有 Okhttp 场景才使用这个 SDK因为 Okhttp 本身支持 DNS 替换没有上面那些问题。在美图的实践中我们不仅仅希望 Okhttp 的请求才进行这个 DNS 优化我们希望在 App H5 页面加载、播放器播放等场景也能应用相应的优化。在这样的需求下IP 直连的接入方案带来的接入工作量其实不低甚至需要改动到部分轮子。在最初的实践中我们也的确尝试了落实 IP 直连 到各个模块然而即使克服了改造的工作量问题实际运行上还是会有不少坑。那么有没有更合适的一种技术方案能够降低 我们 DNS SDK 的接入工作量也能兼顾各种使用场景比如 HTTPS、RTMP 协议等基于这样的目标我们在实践中尝试探索了一种对业务集成友好的无侵入式 DNS SDK 集成方案。下面我们以 Android 平台进行说明。我们知道在 Java 层面上进行 DNS 解析的基本方式是调用如下方法:Android 平台上常用的 Okhttp、HttpUrlConnection 等网络请求库都会依赖这个形式的 DNS 解析。我们深入分析 InetAddress 的运行流程其大致如下:在上述流程中我们可以知道InetAddress 会有到 AddressCache 尝试获取已缓存记录的动作而这里 AddessCache 是一个 static 的 map 结构变量。因此在这里我们来对它做点小手脚 :模仿系统的 AddressCache 构造一个我们自己的 AddressCahce 结构不过它的 get 方法被替换为从我们 SDK 获取解析记录。通过反射的形式用我们修改后的 AddressCache 替换掉系统的 AddressCache 变量。这个偷天换日的操作之后HttpsUrlConnection 等 Java 层网络请求在进行 DNS 解析时就会是这样一个流程:通过这个形式我们能够完美解决 Java 层的 DNS SDK 接入问题对于业务方来说他们并不需要做任何 URL 替换操作对应的 HTTPS 场景下的问题也不复存在。Java 层的接入解决了 那么 Native 层呢我们知道在 Android 平台上像 WebView、播放器等模块他们进行网络连接的操作都是在 native 层进行的并不会调用到 Java 层的 InetAddress 方法。首先在 C/C 层我们知道进行 DNS 解析会使用 getaddrinfo 或是 gethostbyname2 这两个函数。另外我们还知道在 Android 等 Linux 系统下对于 .so 这类可共享对象文件会是 ELF 的文件格式。因此从这些已知信息我们可以得到下列一些情况:我们的 App 中 a.so 中直接使用到了系统 libc.so 中的 getaddrinfo 函数那么根据 ELF 文件规范在 a.so 的 .rel.plt 表中会有如下关系定义: getaddrinfo 0xFFFFFF 。.rel.plt 表中的映射关系为 a.so 的运行指出了 getaddrinfo 这个外部符号在当前内存空间中的绝对地址。正常情况下a.so 中执行到 getaddrinfo 的函数流程是这样的:那么在这里我们是否可以手动修改这个映射表内容把 getaddrinfo 的内存地址替换成我们的 my_getaddrinfo 地址呢这样a.so 在实际运行时会被拐到我们的 my_getaddrinfo 中实际上确实是可行的。 我们尝试在 SDK 启动后对 a.so 的 .rel.plt 表进行修改达到接管 a.so DNS 的目的,修改后的 a.so 运行流程如下:通过上面的方式我们能够比较完美地接管 App 在 Java 层 和 Native 层 DNS 过程实现业务方无任何额外改动的情况下运用我们的 DNS SDK 优化效果。SDK 上线后的效果表现在实际运用中我们取得了比较好的效果。得益于 DNS SDK 在命中本地缓存率上的策略优化我们的移动端产品在网络请求中 DNS 解析环节耗时得到降低从实际监控数据来看完整网络请求的耗时也能够降低 100ms 左右。通过 HTTP DNS 的引入和 LocalDNS 优化升级策略我们的网络请求成功率有提升在未知主机等具体错误率表现出下降的趋势。由于 SDK 层面本身做好了灵活的策略配置我们通过线上监控和配置也让各产品在效益和成本之间取得一个最佳的平衡点。七、历史著名DNS劫持案例2009年巴西最大银行遭遇DNS攻击1%用户被钓鱼。2009年巴西一家最大银行Bandesco巴西银行曾遭受DNS缓存病毒攻击成为震惊全球的““银行劫持案”。受到影响的用户会被重定向至一个假冒的银行网站该假冒网站试图窃取用户密码并安装恶意软件。DNS缓存病毒攻击是利用互联网域名系统中的漏洞进行的没有及时打补丁的ISP很容易受到攻击。合法的IP会被某个网站给取代即使终端用户输入正确的网址也会被重定向至那些恶意网站。有近1%的银行客户受到了攻击如果这些客户注意到了银行SSL证书在被重定向时出现的错误提示就不会上当受骗。2010年1月12日 上午7时40分 “百度域名被劫持”事件。当时有网民发现百度首页登陆发生异常情况。上午8时后在中国内地大部分地区和美国、欧洲等地都无法以任何方式正常登陆百度网站而百度域名的WHOIS传输协议被无故更改网站的域名被更换至雅虎属下的两个域名服务器部分网民更发现网站页面被篡改成黑色背景以及伊朗国旗同时显示“This site has been hacked by Iranian Cyber Army”该网站已被伊朗网军入侵字样以及一段阿拉伯文字然后跳转至英文雅虎主页这就是“百度域名被劫持”事件。2012年10月25日 日本邮储银行、三井住友银行和三菱东京日联银行各自提供的网上银行服务都被钓鱼网站劫持。据日本《日经电脑》报道日本邮储银行、三井住友银行和三菱东京日联银行于2012年10月25日和10月26日分别发布公告提醒用户三家银行各自提供的网上银行服务都被钓鱼网站劫持出现要求用户输入信息的虚假页面在登录官方网站后会弹出要求用户输入密码等的窗口画面本次虚假弹出式窗口页面的目的在于盗取用户网上银行服务的密码。这种弹出式窗口页面上还显示有银行的标志等乍看上去像真的一样。2013年5月6日 史上最大规模DNS钓鱼攻击预估已致800万用户感染。2014年1月21日 北京2014年1月21日全国大范围出现DNS故障下午15时20分左右中国顶级域名根服务器出现故障大部分网站受影响此次故障未对国家顶级域名.CN造成影响所有运行服务正常。如何系统学习网络安全/黑客网络安全不是「速成黑客」而是守护数字世界的骑士修行。当你第一次用自己写的脚本检测出漏洞时那种创造的快乐远胜于电影里的炫技。装上虚拟机从配置第一个Linux环境开始脚踏实地从基础命令学起相信你一定能成为一名合格的黑客。如果你还不知道从何开始我自己整理的282G的网络安全教程可以分享我也是一路自学走过来的很清楚小白前期学习的痛楚你要是没有方向还没有好的资源根本学不到东西下面是我整理的网安资源希望能帮到你。需要的话可以V扫描下方二维码联系领取~如果二维码失效可以点击下方链接去拿一样的哦【CSDN大礼包】最新网络安全/网安技术资料包~282G无偿分享1.从0到进阶主流攻防技术视频教程包含红蓝对抗、CTF、HW等技术点2.入门必看攻防技术书籍pdf书面上的技术书籍确实太多了这些是我精选出来的还有很多不在图里3.安装包/源码主要攻防会涉及到的工具安装包和项目源码防止你看到这连基础的工具都还没有4.面试试题/经验网络安全岗位面试经验总结谁学技术不是为了赚$呢找个好的岗位很重要需要的话可以V扫描下方二维码联系领取~因篇幅有限资料较为敏感仅展示部分资料添加上方即可获取如果二维码失效可以点击下方链接去拿一样的哦【CSDN大礼包】最新网络安全/网安技术资料包~282G无偿分享