NotionNext BLOG

为什么压力测试QPS总是上不去

Mon, 22 Apr 2024 00:00:00 GMT

基于对DOT/DOH进行性能测试过程中遇到的几个问题进行总结

背景

每一个版本都会对dnproxy代理服务进行一次性能测试，主要的测试指标为：

使用长链接时，doh、httpdns的QPS

使用短链接时，doh、httpdns的QPS

开启缓存与未开缓存时，doh、httpdns的QPS

测试使用的打压工具为：wrk

使用的命令如下：

相关参数： -t8：指定wrk使用的线程数为8 -c4000：指定建立的TCP连接数为4000个 -d 20: 指定打压的持续时间为20s -H "Connection: close"：加上该header表示使用短链接，否则默认wrk使用长链接打压结束后会输出如下信息：

其中最重要的指标就是Requests/sec即qps。

问题一：新机器测QPS上不去

当时测试反馈使用dnsproxy在新物理机（16核）进行打压时QPS处于2w且CPU占用只有130%不到，不应该只有这么低的表现。由于dnsproxy这个程序并未进行任何代码的改动，之前是能够到达15w左右的QPS，所以先排除是代码修改引入的性能不佳问题，那么初步猜测可能是网络层面出现了什么问题。

在TCP进行三次握手的时候，linux内核会维护两个队列，分别是：

半连接队列，也称 SYN 队列；

全连接队列，也称 accept 队列；

服务端收到客户端发起的 SYN 请求后，内核会把该连接存储到半连接队列，并向客户端响应 SYN+ACK，接着客户端会返回 ACK，服务端收到第三次握手的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到 accept 队列，等待进程调用 accept 函数时把连接取出来。

其中这两个队列在linux的系统参数中有对应的默认值，分别为：

全连接的的最大值由somaxconn决定

半连接的最大值由上面两个参数共同决定，计算方式和条件比较多感兴趣可自己查询

会不会是队列设置的太小导致的打压时很多tcp连接溢出后被丢弃了？

为了验证猜想，我们首先在服务端查看dnsproxy服务实际使用到的全连接队列是多少,使用ss -lnt查看处于LISTEN状态的对应端口的Recv-Q及Send-Q。

Recv-Q：当前全连接队列的大小，也就是当前已完成三次握手并等待服务端 accept() 的 TCP 连接；

Send-Q：当前全连接最大队列长度，下面的输出结果说明监听5353端口的 TCP 服务，最大全连接长度为4096；

进行wrk持续打压发现，receive值一直没有超过其最大值

查看是否存在队列溢出丢弃的情况，使用nestat -s |grep 'overflowed'发现并没有持续的正常，所以排除服务端连接队列参数过小导致的问题

会不会是客户端就没有建立那么多连接数？

使用ss -s 查看客户端和服务端的TCP连接数发现，和wrk设置的2000连接数相差不大，排除客户端的问题。

会不会是网卡收包量或者路由器的问题？

首先使用tcpdump - i zeth0 port 5353 -w dnsproxy.pcap进行抓包，然后使用wireshark打开进行分析，这里分享几个技巧：

点击左下角的小圆点，wireshark会快速分析列出可能存在的问题，此时主要关注warning部分，如下面图所示可以看出存在两个需要关注的问题：

This frame is a (suspected) out-of-order segment
D-SACK Sequence

展开起列表点击其中一条我们就定位到对应的行，发现存在大量的Retransmission以及Dup ACK说明出现了包大量重传的问题，那就可能出现了网络拥塞。

我们进一步去验证起网卡收包流量情况，使用sar -n dev 1 100 |grep zeth0 统计网卡的发送及接受流量。

使用能够正常打压上去的物理机和有问题的机器进行对比，发现有问题的机器收包流量只有2m/s，是存在问题的。于是尝试使用换一个网卡直连的方式进行测试，发现流量正常了，QPS也上去了。

问题二：长连接QPS上得去，短连接QPS上不去

测试在使用-H "Connection: close"进行短连接测试发现QPS又比之前的值差了不少，使用的压力机和测试机都和测试长连接使用的是相同的，所以排除上面我们说的网卡、队列的问题影响，会不会是长短连接机制引起？

因为使用短连接，那么每一次请求就会有3次握手和4次挥手的流程。

为了找出具体的问题，我又尝试用另一条机器对测试机进行打压测试，发现该机器使用wrk进行打压的数据就比较正常，那问题就确定是压力机侧引起的。

我们都知道TCP 连接是基于五元组的，那么对于客户端来说，源 IP、目的 IP、目的端口、协议，这四个元素都不会变化，唯一会变的就是自己的源端口了

会不会是端口范围太小导致的？

查看系统设置的端口范围

发现端口范围也挺大的，那台能够正常打压上去的压力机也是这个范围，所以应该不是这个参数的问题。

会不会是连接状态的问题

在查看一下压力机连接数处于各个状态的数量

在筛选出5353端口使用的连接数

发现处于异常的机器有2.8w个连接是处于TIME-WAIT状态，并且一直没有释放掉，而正常的机器会只有1w不到的TIME-WAIT也不会随着打压一致变高，于是在对两个机器配置进行对比。

发现在有问题的机器上net.ipv4.tcp_tw_recycle = 1这个参数没有被设置，

先解释一下这两个参数的含义

net.ipv4.tcp_tw_reuse = 0 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭

net.ipv4.tcp_tw_recycle = 0 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭

从字面意思分析可能就是因为处于TIME-WAIT连接数太多且没有快速回收导致端口不够用，短连接进行建连上不去。于是在新环境添加上该参数后，结果报错了...

该配置参数竟然无法使用，

查看了一下linux的版本内核

发现这两台机器版本差异比较大，查看相关资料才得知Linux 从4.12内核版本开始移除了该参数设置，感兴趣的可以自行去查看具体的原因。那无法使用这个参数，有没有其他参数可以控制处于TIME-WAIT的连接数最大值呢？果然，linux提供了相关的设置参数，那就是：net.ipv4.tcp_max_tw_buckets

将该参数设置为一个比较小的值进行测试

进行测试后发现QPS就正常了，同时处于TIME-WAIT的连接数也不到1000，终于解决了这个问题！

无懈可击的DNSSEC

Mon, 22 Apr 2024 00:00:00 GMT

什么是DNSSEC

DNSSEC(Domain Name System Security Extensions)中文名称为DNS安全扩展，它是由IETF提供的一系列DNS安全认证机制，通过向现有DNS记录添加加密签名，解析器可以验证来自于权威域名服务器请求的信息，从而保证域名系统的安全性。

发起一次域名查询的流程如上图所示，客户端需要访问www.baidu.com，会通过域名解析服务器发起递归查询，我们经常配置的114.114.114.114就是一个递归服务器。如果递归服务器存在记录缓存，那么就会直接将www.baidu.com的A记录直接返回给客户端；如果不存在就需要通过根服务器、顶级域名服务器、权威服务器、二级域名服务器迭代查询。

由于DNS解析使用的是UDP协议，UDP 是一种无连接的、不可靠的传输层协议，所以攻击者就能很容易通过假冒域名服务器（根、顶级、权威服务器）给客户端发送伪造的响应，响应的IP可能是无效地址或者是欺诈网站地址，从而达到网络钓鱼、提供非法广告、监控 Web 流量以及阻止对特定域的访问等。同时由于解析服务器有缓存的功能，这些记录就会在服务器中保存一段时间才会失效，这就是常见的DNS欺骗攻击和缓存污染。

DNSSEC设计目的就是为了解决DNS欺骗攻击和缓存污染，它使用数字签名技术保证DNS的真实性和完整性，这些数字签名会与A、CNAME等常见记录类型一起存储在DNS域名服务器中。解析服务器可以对响应进行校验来确保所请求的DNS记录是否来自权威服务器，并且没有被篡改或者注入虚假的信息。

DNSEC是如何设计和运行

为了保证签名、分发、验签整个过程的可信可靠，DNSSEC添加了新的DNS记录类型：

RRSIG：用于存放资源记录签名

DNSKEY：用于存放公共签名密钥

DS：用于存放公钥哈希

NSEC、NSEC3：用于表示DNS记录不存在

RRset

RRset是一组资源记录集合，这个集合包含相同类型的记录。例如区记录里面存在www.baidu.com的多个A记录，那么它们就会全部归到一个A RRset中去。

ZSK

DNSSEC针对每一个区都有一对签名密钥ZSK（Zone Signature Key），ZSK的私钥用来对RRset进行数字签名，公钥用于验证签名，并将其哈希添加到DNSKEY记录中，方便递归服务器来查询。

递归服务器为了校验响应结果是否可信，他需要获取RRset、RRSIG和DNSKEY一同进行验证，使用DNSKEY对RRSIG进行解密，然后再与RRset哈希进行对比。如果DNSKEY是被信任的，那么如果验证通过，所有的记录就是可信任的。但是，DNSKEY泄漏或者被伪装那么还是不能保证数据的可靠，所以还需要有一种机制来验证ZSK是否正确可靠（套娃开始🪆）。

KSK

KSK(Key Signature Key)用来对ZSK进行签名和验证，使用KSK的私钥对ZSK公钥的DNSKEY记录进行签名，得到的数字签名也是一个RRSIG记录，为了能够对该RRSIG进行验签，将KSK的公钥存在在另一个DNSKEY记录中。此时就产生了两个DNSKEY，分别是：

ZSK的DNSKEY：用于存放ZSK公钥和使用KSK进行签名的RRSIG记录

KSK的DNSKEY：用于存放KSK公钥

此时，验证流程变得复杂起来，在ZSK流程的基础上，解析服务器向域名服务器请求ZSK公钥，返回了ZSK公钥的DNSKEY记录和对应的RRSIG记录（使用KSK签名的），为了校验ZSK的DNSKEY记录是否正确，解析服务器又需要向域名服务器请求KSK公钥，返回了KSK公钥的DNSKEY记录就可以验证ZSK的DNSKEY是否可被信任了。那么问题又来了，又该如何确保KSK的有效性呢？不会再设计出个KKSK来吧？

DS

为了验证KSK公钥的有效性，DNSSEC添加DS记录，该记录包含KSK公钥的DNSKEY的哈希，并由父区保存

于是整个校验过程又多了一步，解析服务器通过权威服务器B获取了KSK和ZSK后，还需要向他的父区顶级域名服务器A获取DS的记录，通过对比DS记录和KSK的哈希值来判断记录数据的有效可靠。这种设计使得子区的信任需要由父区来保证，父区的信任也需要由更上级保证，这样也就形成了一个完整的信任链。

信任链

每个区都有父区进行签名背书，如果信任父区，则子区所有记录在验证正确的情况就可以认定为是可信可靠的。根区的签名则是在“根区签名仪式”，由来自世界各地的特定的几人已公开且经严格审核的方式签署根DNSKEY RRset，并产生一条RRSIG记录，该记录用于校验根域名服务器的公共KSK和ZSK。

DNSSEC配置实践

配置

权威服务器A配置

首先创建一个aaa.com的区，然后再添加一条www.aaa.com的A记录。

得到区记录文件aaa.com.txt：

使用dnssec-keygen生成该区的KSK

dnssec-keygen -f KSK -a RSASHA1 -b 512 -n ZONE aaa.com.

使用dnssec-keygen生成该区的ZSK

dnssec-keygen -a RSASHA1 -b 512 -n ZONE aaa.com.

生成两对公私钥对

Kaaa.com.+005+29191.key Kaaa.com.+005+29191.private
Kaaa.com.+005+50076.key Kaaa.com.+005+50076.private

编辑aaa.com.txt文件,将KSK和ZSK的key添加进去

对区记录进行签名，得到aaa.com.txt.signed文件

dnssec-signzone -o aaa.com. aaa.com.txt

使用aaa.com.txt.signed替换aaa.com.txt，重启Bind

权威服务器B配置

创建一个com的区，然后再添加一条aaa.com的NS记录。

得到区记录文件com.txt：

使用dnssec-keygen生成该区的KSK

dnssec-keygen -f KSK -a RSASHA1 -b 512 -n ZONE com.

使用dnssec-keygen生成该区的ZSK

dnssec-keygen -a RSASHA1 -b 512 -n ZONE com.

生成两对公私钥对

Kaaa.com.+005+29191.key Kaaa.com.+005+29191.private
Kaaa.com.+005+50076.key Kaaa.com.+005+50076.private

编辑aaa.com.txt文件,将KSK和ZSK的key添加进去，并将授权的子区aaa.com.的DS记录添加进来

对区记录进行签名，得到com.txt.signed文件

dnssec-signzone -o com. com.txt

使用com.txt.signed替换com.txt，重启Bind

递归服务器验证

将递归服务器的根区指向权威服务器A

使用dig命令： dig @递归服务器 www.aaa.com. +dnssec

如果配置的没有问题返回结果为：

进行抓包得到

dnssec.cap

3.2KB

分析

递归服务器向112这台权威服务器请求www.aaa.com.,112权威服务器返回aaa.com.的子域所指的服务器给递归服务器，假定为113权威服务器。

递归服务器收到后又向113权威服务器请求www.aaa.com.,113权威服务器的区里有DNS记录并同时还会返回对应的RRSig（数字签名）

递归服务器收到结果，需要根据RRSig来判断这条DNS响应是否是113这台权威服务器发出的，这时递归服务器就会向113权威服务器请求ZSK公钥

113权威服务器收到请求后就会返回ZSK、KSK的DNSKEY记录及对应的RRSig

递归服务器收到包含KSK公钥的DNSKEY记录后，向112权威服务器查询DS记录

递归服务器收到DS记录后，就可以对KSK公钥进行哈希，比较两个值是否匹配。

由于整个过程是从根出发的，所以为了不从根再获取DS，就可以配置信任锚，将com.的DNSKEY添加到递归服务器里，这样就不会再根服务器去请求了。

在递归服务器的配置里添加Trust Anchors , 需要填写的就是com. 的DNSKEY 的记录值

总结

DNSSEC在并不安全的协议之上，添加了一个身份验证的安全层来确保记录的可信防篡改，类似HTTPS。通过使用DNSSEC，借助可靠的信任链就能有效地解决DNS欺骗攻击，防止攻击者给DNS系统带来潜在的安全威胁。

参考

DNSSEC？禁止套娃！

简介DNSSEC是DNS安全拓展，主要思想是通过在DNS记录中添加加密签名，从而为DNS解析流程提供来源可认证和数据完整性的保障。本文的目的是帮助大家大致理解DNSSEC的工作流程建议读者先掌握以下知识点再来阅读本文…

https://zhuanlan.zhihu.com/p/355579999

Manual Pages — BIND 9 9.18.2 documentation

arpaname translates IP addresses (IPv4 and IPv6) to the corresponding IN-ADDR.ARPA or IP6.ARPA names.

https://bind9.readthedocs.io/en/v9_18_2/manpages.html?highlight=dnssec-loadkeys-interval#zone

DNSSEC verification with dig

DNSSEC is the (not so) new technology that will finally fix the trust problems inherent in the DNS, making spoofing and forging much harder or impossible. Or at least, that's what everyone hopes.

https://backreference.org/2010/11/17/dnssec-verification-with-dig/

DNS隧道攻击和防护

Thu, 18 Apr 2024 00:00:00 GMT

隧道

现实生活中我们乘坐汽车或火车常常会遇到隧道，隧道在物理世界是一种跨越无法跨越的地形或边界的方法，而在网络世界中的隧道则是一种绕过端口屏蔽的通信方法。隧道技术是一种通过使用互联网络的基本设施在网络之间传递数据的方式，使用隧道传递的数据（或负载）可以是不同协议的数据帧或包。隧道技术将其他协议的数据帧或者数据包重新封装然后通过隧道发送。新的帧头提供路由信息，以便互联网传递被封装的负载数据。常见的隧道如下：

网络层

IPV6隧道
ICMP隧道
GRE隧道

传输层

TCP隧道
UDP隧道

应用层

SSH隧道
HTTP隧道
HTTPS隧道
DNS隧道

DNS隧道

DNS隧道是隐蔽信道的一种，通过将其他协议封装在DNS协议中进行通信。封装由客户端完成，将DNS流量还原成正常的流量由服务器完成。大多数防火墙和入侵检测设备对DNS流量是放行的，而隧道攻击正式利用了放行的特点以及协议解析流程来实现的。

DNS隧道有两种实现方式：

IP直连型DNS隧道直连也就是客户端直接和指定的目标DNS Server(Authoritative NS Server)连接，通过将数据编码封装在DNS协议中进行通信，这种方式速度快，但是隐蔽性比较弱，很容易被探测到，另外限制比较高，很多场景不允许自己指定DNS Server，很多的企业网络为了尽可能的降低遭受网络攻击的风险，一般将相关策略配置为仅允许与指定的可信任DNS服务器之间的流量通过。

域名型DNS隧道（中继）通过DNS迭代查询实现的中继隧道，比较隐蔽，但同时因为数据包到达目标DNS Server前需要经过多个节点，所以速度上较直连慢很多。

DNS隧道攻击

最常见的工具如下：

dns2tcp：支持直连模式的DNS隧道，只实现了简单的DNS隧道，相关命令和控制服务需要自行搭建，且已在kali系统中直接集成。

iodine：最活跃、速度最快、支持直连和中继模式，且支持丰富的编码、请求类型选择

dnscat2：封装在DNS协议中的加密C&C信道，直接运行工具即可实现数据传输、文件操作等命令和控制功能

dns2tcp

仓库

https://github.com/alex-sector/dns2tcp

说明

dns2tcp是一款利用dns协议传输tcp数据的工具,适用于客户端的防火墙禁止tcp出站流量，无法上网，dns2tcp利用dns协议传输tcp数据，从而实现上网(dns协议是udp协议走53端口)

安装

部署

服务端配置和启动：

客户端启动：

使用ssh即可进行登陆

抓包查看相关DNS报文

可以看出一直有TXT类型查询，心跳和数据传输都是通过TXT类型的DNS记录查询进行完成的，dns2tcp还支持KEY类型的记录。

iodine

仓库

https://github.com/yarrick/iodine

说明

iodine可以通过一台dns服务器制造一个IPv4数据通道，特别适合在目标主机只能发送dns请求的网络中环境中使用。iodine支持直接转发和中继两种模式，其原理是通过TAP虚拟网卡，在服务端建立一个局域网；在客户端，通过TAP建立一个虚拟网卡；两者通过DNS隧道连接，处于同一局域网（可以通过ping命令通信）。在客户端和服务端之间建立连接后，客户机上会多出一块“dns0”的虚拟网卡。

部署

服务端执行命令：

查看网卡发现多了一个dns0

客户端执行命令：

客户端这边也多了一个虚拟网卡tun0

DNS隧道建立后可以看到，服务端和客户端多了一个虚拟网卡，后续就可以通过这个网卡的ip进行相关通行。

查看DNS报文,发现iodine使用NULL类型查询，这是工具自动选择的，当然它还支持 PRIVATE, TXT, SRV, MX, CNAME, A这些类型

dnscat2

仓库

https://github.com/iagox86/dnscat2

部署

使用docker启动服务端

编译客户端

进入交互界面查看session，通过session与客户端通信

客户端收到服务端日志并执行

使用shell，向client发送命令

查看DNS报文,发现dnscat查询类型比较随机。

DNS隧道防护策略

隧道消息类型分布

在正常的DNS流量中。A记录类型的流量占20%-30%，CNAME记录为38%-48%，AAAA记录占25%，NS记录只有5%，TXT记录只有1%-2%。然而为了获取更高的带宽，一部分的DNS隐蔽信道工具如iodine。在默认配置下会使用TXT或NULL等不常用的记录类型

域名中关键字和规则

在DNS隧道的报文中，我们可以看到变化的都是子域名，区是可以作为关联异常流量的切入点。同时DNS隧道而言，控制端要不断借助DNS query的query_name来承载要传输的内容，所以从主机数量这个维度来看，在一个DNS隧道会话中，域名对应的主机名数量会明显大于正常的DNS通信。

数据包数量

DNS隧道会话一般会向外发送心跳报文、传输本机敏感信息、资源文件等，控制端会下达相关的远程控制指令等所以在 DNS 隧道会话中 DNS报文数量大。但正常客户端产生的DNS会话随着一次DNS解析任务结束而结束，DNS会话比较简短。大多数情况是2个，由1个DNS请求报文和1个DNS响应报文组成。

报文载荷量

一般正常的DNS查询报文都不会太大，但是DNS隧道由于是通过DNS报文中再封装其他协议的报文所以载荷量就会普遍大一些。

其他

参考

内网渗透基石篇-- 隐藏通信隧道技术（上） - FreeBuf网络安全行业门户

那么什么是隧道呢？这里的隧道，就是一种绕过端口屏蔽的通信方式。

https://www.freebuf.com/articles/network/271827.html

DNS 隧道通信特征与检测

本地域名服务器向根域名服务器发送请求报文，根域名服务器要么给出ip地址要么告诉本地域名服务器下一步应该去查询另一个域名服务器(假设这个域名服务器为A)。本地域名服务器会向A域名服务器发送请求报文，A域名服务器要么给出ip地址要么告诉本地域名服务器下一步应该去查询B域名服务器。过程以此类推，直到查找到ip地址为止。

http://blog.nsfocus.net/dns-tunnel-communication-characteristics-detection/

使用DNS2TCP搭建DNS隧道，绕过网络认证，实现免验证上网_校园网53端口绕不过认证-CSDN博客

文章浏览阅读2.7w次，点赞28次，收藏166次。本文主要介绍利用 DNS 查询流量来封装 TCP 流量 , 达到绕过防火墙的目的，搭建DNS隧道，绕过网络认证，实现上网。_校园网53端口绕不过认证

https://blog.csdn.net/deng_xj/article/details/88834124?utm_medium=distribute.pc_relevant.none-task-blog-2~default~baidujs_baidulandingword~default-0-88834124-blog-106159155.235^v38^pc_relevant_default_base&spm=1001.2101.3001.4242.1&utm_relevant_index=3

DNS隧道和工具-阿里云开发者社区

DNS隧道和工具

https://developer.aliyun.com/article/395249

内网隧道之dns2tcp-腾讯云开发者社区-腾讯云

github：https://github.com/alex-sector/dns2tcp

https://cloud.tencent.com/developer/article/2130056

DNS隧道检测特征总结

一、摘要企业内网环境中，DNS协议是必不可少的网络通信协议之一，为了访问互联网和内网资源，DNS提供域名解析服务，将域名和IP地址进行转换。网络设备和边界防护设备在一般的情况下很少对DNS进行过滤分析或屏蔽，…

https://zhuanlan.zhihu.com/p/143220945

WindowDNS使用GSS-TSIG协议

Fri, 19 Apr 2024 00:00:00 GMT

概述

GSS-TSIG全称Generic Security Service Algorithm for Secret Key Transaction，即密钥事务的通用安全服务算法，用于对 DDNS 更新进行认证，它使用了Kerberos v5的认证系统（实现了GSSAPI）。原先通过TSIG记录使用共享密钥可以对DNS消息进行认证，但是这种方式不能全自动，必须手动介入生成和配置。引入GSS-TSIG和TKey纪录后就提供了一系列不同的模式建立和删除共享密钥用于解析服务器和DNS服务器之间通行认证。GSS-TSIG 通过客户端和服务端进行协商从而建立一个安全的请求上下文，它利用 Kerberos 服务器（在 AD 域控制器上运行）充当 KDC（Kerberos 密钥分发中心），并为 Active Directory 域中的用户和计算机提供会话凭证和临时会话密钥。客户端和服务器协作创建并相互验证它们交换的消息上的事务签名。 Windows 2000、Windows Server 2003、Windows Server 2008、Windows Server 2008 R2、Windows Server 2012、Windows Server 2012 R2 和 Windows Server 2016 都支持使用 GSS-TSIG 的 DDNS 更新。

GSS-TSIG和Kerberos 认证的结合

一个keytab文件包含成对的 Kerberos 主体名称及其对应的加密密钥。它可以包含单个领域或多个领域的密钥。整个流程大概如下：

客户端使用keytab与KDC中的Authentication Server通信获取用户的TGT(AS-REQ/AS-REP)

客户端使用TGT与Ticket Granting Server通信获取 session ticket（TGS-REQ/TGS-REP）

客户端使用session ticket与DNS Server通信获取TKEY记录（Transaction Key RR），Transaction Key记录包含了共享密钥相关信息（TSIG）

客户端进行动态更新操作，发送数据包含：

需要更新的记录

tsig rr

在 KDC 上生成 keytab 文件并将其 SPN（Service Principal Name）映射到帐户，DNS 服务器对域进行身份验证。KDC 知道DNS服务器的密钥，在session ticket中使用DNS服务器密钥进行加密，client拿到后直接发给DNS Server，DNS server使用自己的密钥进行解密，解密成功并且验证client信息通过后，返回tkey给client，client在使用tkey进行动态更新的操作。

配置步骤

window侧

创建用户,全名：dns1

将新用户与服务主体名称（SPN）关联

生成keytab文件,使用Ktpass工具

window需要配置Kerberos 打开本地安全策略 -> 本地策略 -> 安全选项，设置Kerberos允许的加密类型

linux侧

linux机器上安装kerberos客户端

配置kerberos配置文件

配置hosts

将生成的keytab拷贝到linux机器，并执行命令获取ticket

如果该命令无任何返回说明执行成功，然后使用klist查看ticket

客户端已经从KDC获取了ticket。

Bind相关

编译完成后，在 named.conf 配置

启动named，使用named -d 6打开更详细的debug日志，如果named服务未启动，出现如下报错 ![[截屏2023-01-14 10.09.34.png]] 说明tkey-gssapi-credential配置有问题。

测试gss-tsig

首先使用kinit -k -t /etc/dns1.keytab DNS/dns1.example.com获取TGT，

然后使用nsupdate测试

❗

出现如下报错说明没有申请到TGT，需要使用kinit重新申请

❓

出现如下这个错误，说明在window那边没有example.com的SPN。需要在window那边配置一下

日志

没有报错说明操作成功，查看bind的debug日志可以看到如下信息：

整体流程报文分析

Service Ticket请求报文

Service Ticket响应报文

Tkey请求报文

Tkey响应报文

动态更新请求报文

动态更新响应报文

❓

TKey记录的作用是什么？

[RFC 2845] provides a means of authenticating Domain Name System(DNS) queries and responses using shared secret keys via the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server.Note that TKEY established keying material and TSIGs that use it are associated with DNS servers or resolvers. They are not associated with zones. They may be used to authenticate queries and responses but they do not provide zone based DNS data origin or denial authentication [RFC 2535].

通俗的理解就是Tkey记录支持多种模式下建立共享密钥的能力，从而解决之前使用手动设置密钥。TKey记录和区无关，它们可用于认证查询和响应但不提供区原始记录查询。

从报文我们可以看出，每次的更新都会协商出一个新的TSIG。

FRRouting使用

Fri, 19 Apr 2024 00:00:00 GMT

官方文档： FRR

架构

可以看出和Quagga基本类似，毕竟FRR就是从Quagga fork出来的，但支持更多的协议功能,同时架构图中省略了一个关键服务就是watchfrr，该服务用来监控其他服务的运行状态还有配置文件的更新。

FRR is currently implementing a new internal configuration system based on YANG data models. When this work is completed, FRR will be a fully programmable routing stack

FRR 目前正基于YANG 数据模型的发开一种新的配置模式。完成后，FRR 将是一个完全可编程的路由。

安装

通过Pakage包安装

通过Snapcraft安装

通过源码安装

前面两种方式比较简单，这里主要列出通过源码编译

编译libyang

编译frr

安装后需要注意

当使用 Linux 作为路由器时，有几个内核参数会影响 FRR 的整体操作。通常，这些参数应该在 sysctl 相关的配置文件中设置，例如， Ubuntu 的系统 /etc/sysctl.conf 和Centos 的系统/etc/sysctl.d/90-routing-sysctl.conf文件中。 net.ipv4.conf.all.forwarding=1net.ipv6.conf.all.forwarding=1

在使用ripd或ospfd时需要保证是开启了IP多播的，因为这些协议使用到了多播 CONFIG_IP_MULTICAST = yes

配置说明

系统日志

如果任何守护进程由于某种原因崩溃，它将写入位于/var/tmp/frr/[-]./crashlog目录下，该路径暂时不能通过配置文件进行修改。

配置文件

在/etc/frr目录下存在三个配置文件，分别是

daemon ：配置各个服务启动和启动参数的文件

frr.conf：配置每个服务具体的参数值

vtysh.conf：配置使用vtysh命令工具的

daemon文件

该配置文件就是用来负责配置开启哪些服务，以及每个服务的配置参数的设置。例如需要启动rip和bgp则修改配置文件

重启服务

重新启动会杀死所有正在运行的 FRR 守护程序并重新启动它们

重加载服务

重新加载应用磁盘配置和当前运行 FRR 进程的有效配置之间的差异，当修改了某一个服务的配置文件可以通过该命令使其生效。

❗

目前没有办法停止或重新启动单个守护程序。这是因为 FRR 的监控程序目前无法区分崩溃/终止的守护程序与故意停止或重新启动的守护程序。只有将需要停止的服务设置/etc/frr/daemons为no，然后重新启动服务。

frr.conf

使用过Quagga的应该知道，每个服务有对应的配置文件，默认的配置文件名是：守护进程名称 .conf。比如zebra 的默认配置文件是zebra.conf，ospf的默认配置文件是ospf.conf。

由于这样会创建大量的配置文件，因此frr使用一个文件为/etc/frr/frr.conf来配置所有的服务。当使用 init 脚本或 systemd 启动 FRR 时，vtysh会调用它来读取配置文件并将适当的部分仅发送给对它们感兴趣的守护进程，如果需要为每个服务指定配置，可以在daemon中通过配置参数-f 或者 --config_file进行指定。

vtysh.conf

配置vtysh工具

service integrated-vtysh-config

该命令表示，当在vtysh里面执行write命令时，配置写入到什么地方去。

service integrated-vtysh-config：

vtysh将始终写入frr.conf文件中

no service integrated-vtysh-config：

vtysh永远不会写frr.conf文件，它会要求守护进程编写它们各自的配置文件。

Neither option present (default)：

vtysh会检查是否frr.conf文件存在。如果是这样，配置写入将更新该文件。否则，将通过各个守护程序执行写入

vtysh

vtysh是一个cli工具，可用于为所有 FRR 守护进程提供前端服务的。它在构建时默认启用，但可以通过--disable-vtysh配置脚本的选项禁用。

FRR守护进程中，有一个watchfrr服务负责收集和写入各个服务的配置信息。使用vtysh进行相关服务的配置时，实际上是与watchfrr服务进行通信，通过watchfrr尝试配置写入，由于_watchfrr_以超级用户身份运行，因此 vtysh能够确保对 write integrated frr.conf。如果watchfrr没有运行或者配置写入失败，vtysh会尝试直接写入文件。

❗

在启动时，所有守护程序都会检查启动时是否存在frr.conf，如果存在，则不会加载各个配置文件。调用vtysh -b来处理frr.conf并将其设置应用于单个守护进程。

配置实例

实际上和quagga的配置方式几乎一样，这里将演示通过vtysh和配置文件的方式进行配置测试

OSPF

添加一个虚拟网卡并配置地址

保存以后会写入/etc/frr/frr.conf

另一台机器类似的操作。然后就可以通过查看route -n 查看路由，可以发现多了一条路由规则，就是通过ospf协议学习得到的。

BGP

在使用bgp时，绝大部分配置和quagga是一样的，但是frr需要添加一条配置项no bgp ebgp-requires-policy,才能正常的获取到路由。

初识SAML2.0协议

Thu, 18 Apr 2024 00:00:00 GMT

什么是SAML

SAML全称安全断言标记语言（Security Assertion Markup Language），它是一种基于XML的开放标准，用于表示和交换用户属性、身份和认证信息。在对用户进行一次身份验证的基础上，将验证结果传递给多个应用程序，达到单点登录SSO的效果。

SAML是一种身份验证，并不包括用户授权认证的过程。身份验证用于确认用户的身份，类似于身份证，用来展示一个人的信息并证明“我是我“。而授权则是确认用户的权限，表明用户他能进行哪些操作

SAML是如何运行的

📎

三个参与方：

1. 用户 2. 身份提供方（IDP）：是一种存储和管理用户数字身份的服务，IDP 可以通过验证账号密码等方式来检查用户身份，并提供用户身份列表供其他服务提供商（如 SSO）检查。 3. 服务提供方（SP）：用户使用的相关服务，如B站、淘宝、飞书都是服务的提供方.

如上图所示，处理流程：

用户访问SP提供的服务页面，并进行SSO登录

SP通过重定向跳转到IDP服务

IDP识别到用户未登录则会跳转到登录页面，用户进行登录操作

IDP登录成功后，返回SAML Response断言信息

SP获取到SAML断言后根据结果提供对应的访问策略 SAML断言包含了SP所需要的所有信息，包括断言的ID来源、签发时间、有效时间、SP的地址等信息。

在SP重定向到IDP时会发送一个AuthNRequest消息

可以看出，该XML里面存储了几个关键信息：

ID="ONELOGIN_809707f0030a5d00620c9d9df97f627afe9dcc24"

唯一ID

IssueInstant="2014-07-16T23:52:45Z"

签发时间

Destination=""

IDP地址

ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

使用的协议

AssertionConsumerServiceURL=""

回调SP的接口地址

发起方

IDP登录成功后就会返回响应的SAML Response

返回结果中也有一些关键信息：

InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685"

对应于SP发起请求的ID

响应结果

会话有效期

返回结果相关属性参数

整个流程图如下图所示：

上述用户以SP为入口是一种场景，还有一种场景是用户先登录IDP，然后在选择指定的SP应用，IDP再跳转到SP应用中去。

该场景处理流程：

用户访问IDP，进行登录；登录完成选择SP访问

IDP重定向到SP，生成SAML Response，并调用SP 的ACS url 将结果返回

SP验证SAML Response，并授权访问

代码实践

我是用go进行代码编辑和测试，使用https://samltest.id 这个网站进行测试，用到的三方库是 go get github.com/crewjam/saml

服务启动后，首先访问 http://localhost:8001/saml/metadata 获取xml元数据，上传到https://samltest.id/upload.php ，再访问 http://localhost:8001/auth 就会跳转到samltest的登录页面。

选择页面下方任意一个提供的账号密码进行登录,登录成功后就会显示如下信息

通过Wireshake抓包，监听lo网卡，端口设置tcp.port == 8001，我们可以得到

可以看出，首先访问/auth地址时，我们启动的服务（SP）将请求重定向到了https://samltest.id/idp/profile/SAML2/Redirect/SSO, 然后我们输入账号密码验证成功后，IDP就回调了/saml/acs接口，发送了saml断言信息，我们服务根据信息再经过重定向到我们最开始访问的/auth接口，最终返回具体的信息。整个测试过程，我们启动的服务是作为服务提供方，https://samltest.id, 则是作为身份提供方，对身份进行验证，并返回验证结果和身份的相关属性。

对接Okta

为了更好的模拟真实的对接场景，我将通过与okta进行SSO集成对接进行演示。使用ruby进行测试。首先登录okta后台，选择Application --> Create App Integration创建应用，然后再选择SAML2.0；再输入应用名。

Single sign on URL 填写的是SP的回调接口Audience URI 填写SP的metadata地址

Attribute Statements可填写一些属性，如用户名，ID等信息。

应用创建完成后，再将该应用授权给指定用户，在Directory --> People --> Add person 创建用户，然后点击该用户，选择Assign Application选择授权的应用。

所有的步骤操作完成后，我们获取okta的saml 登录证书地址，选择Application，点击创建的应用，再选择Sign on，就可看到okta提供的证书，为了拿到其地址我们点击View Idp metadata，他就会回跳转到新的页面，页面地址就是我们需要的IDP metadata url，将其替换代码的相应位置即可。

接下来测试流程就和上面经过抓包，使用我们对相关请求使用工具(https://www.scottbrady91.com/tools/saml-parser) 进行解码处理得到：

这是在重定向时携带的SAML Request的信息，包含ID、发起时间、目标IDP地址,回调SP的地址和发起者。

这是okta登录成功后回调请求/saml/acs接口时发送的SAML Response，包含目的SP回调地址，该消息对应的请求ID，响应状态，用户属性等。

总结

SAML协议制定于2005年，所以在制定的时候主要针对Web应用程序，并没有考虑后来的App，在兼容性上不是那么好。特别是在2012后OAuth2的出现，越来越多的人在单点登录上的第一选择更多是OAuth2（后面也会写相关文章来介绍OAuth2）。但SAML通过HTTP Redirect 和Post 协议来传递身份验证消息，并使用Form格式进行数据提交，整个协议交互比较简单，方便使用集成，在今天还是有它的一席之地的。

参考文档

SAML 2.0 Web 浏览器单点登录

SAML Web 浏览器单点登录 (SSO) 允许 Web 应用程序将用户认证授权给 SAML 身份提供者（而不是所配置的用户注册表）。

https://www.ibm.com/docs/zh/was-liberty/base?topic=authentication-saml-20-web-browser-single-sign

docs.oasis-open.org

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02.pdf

SAML2.0 指南

SAML 全称为 Security Assertion Markup Language ，是一种用于安全性断言的标记语言，目前的最新版本是 2.0

https://klose911.github.io/html/material/saml.html