iodine

iodine初步研究

Posted by Xiaoxi on December 16, 2016

iodine初步研究

Iodine 可以让我们通过DNS来隧道传输IPv4的数据。它适用于某些只能使用DNS服务的网络情况下，比如在某些防火墙的隔离下、某些Wifi登陆认证前等等。此外，它的使用需要一个TUN/TAP.其带宽是不对称的，在LAN网络下，上传速度为3Mbit/s,下载速度为680kbit/s;Wifi网络下，分别为200kbit/s与50kbit/s.

注：使用的时候，服务端和客户端需使用同样的协议，在大多数情况下，两者使用同样版本的iodine即可。不同版本的协议之间的向前兼容和向后兼容尚不能解决。

整个流程：

  1. 服务器打开本机dns0，设定内网IP（192.168.99.1），设定MTU，开始监听域名xiaoxi.pegasusux.xyz

  2. 客户端以root权限运行，通过密码开始尝试查询xiaoxi.pegasusux.xyz

  3. 自动检测寻找适用的DNS类型，顺序依次为NULL、PRIVATE、TXT、SRV、MX、CNAME和A类型

  4. 检测客户端与服务端的版本信息是否匹配。若匹配，得到当前客户端userid，并得到登陆验证信息；否则，退出；（此外，若服务器端在线数量达上限，也会匹配失败）

  5. 客户端依据收到的登陆验证信息，计算出最终验证信息，发送到服务端。服务端通过验证后，返回x.x.x.x-y.y.y.y-mtu-netmask （server ip-client ip-mtu-netmask）信息，进入下一步。

  6. 设定tun虚拟网卡的ip（如192.168.99.2），建立路由（Adding route 192.168.99.0/27 to 192.168.99.2

    add net 192.168.99.0: gateway 192.168.99.2 ）

  7. 协调设定TUN的MTU值，并得到服务端IP（192.168.99.1）

  8. 尝试直接连接模式，即尝试直接使用IP请求连接到服务器IP（注：这里的IP为服务器伪装的IP，而非服务器的公网IP）。如果可达，就采用直接模式进行通信；如果不可达，尝试迭代模式；注：直接模式下使用的是Raw UDP协议

  9. 使用EDNS0插件，并依次进行上传检查、下载检查、探测适合的编码器格式。

  10. 首先，尝试lazy模式进行通信；若lazy模式失败，则适用传统模式

  11. 整个DNS tunnel 建立完毕。

“lazy-mode”（延迟模式）

iodine 支持lazy-mode（延迟模式）：使用延迟模式以提高性能和减少延迟。但是，少部分的DNS中继可能无法处理延迟模式下的流量模式，导致没有或很有的数据通过。

客户端 - 服务器DNS流量序列重新排序用以提供增强的（交互式）性能与大大降低传输延迟。

想法起源于lucas Nussbaum在IFIP国际安全会议，2009上PPT（http://www.loria.fr/~lnussbau/tuns.html）

在开发过程中，没有参考任何其他项目的代码或文档。

服务器：

上游数据立即ack，以保持慢上行数据尽可能的快（客户端等待ack来发送下一个数据片段）

ping请求被应答，要么是下游的数据到达了tun，要么是新的上游ping／数据来到了客户端。

在大多数情况下，这意味着我们要回答以前的DNS查询，而不是当前一个。当前查询保留在队列中，并在下行数据必须被发送时使用。

上游数据包通常作为对先前ping包的回复，并且上游数据包本身保持在队列中。

客户端：

立即下载下游数据，以保持其快速流动（包括在最后下游段之后的ping）。

此外，在所有可用的上游数据由服务器发送（在某些情况下用尽最后一个查询）之后，发送附加的ping以为下一个下游数据填充服务器。

Raw UDP协议

所有Raw UDP protol消息都以3字节的标头开始：0x10d19e 这不是有效的DNS消息的开始，因此很容易识别。 第四个字节包含命令和用户ID。

 7654 3210
+----+----+
|CCCC|UUUU|
+----+----+

命令：

  1. 登录消息（command = 1）：

    标头后跟一个与DNS登录中相同密码的MD5哈希。 客户端通过发送此消息启动原始模式，并使用登录验证信息+1，服务器使用登录验证信息-1进行响应。 在交换登录消息之后，服务器和客户端切换到原始udp模式以用于其余连接。

  2. 数据消息（command= 2）：

    在头部得到有效载荷数据之后，其可以被压缩。

  3. Ping（command= 3）：

    从客户端发送到服务器，然后返回，主要用以保持会话的持续。

握手流程

  1. 默认情况下，握手的dns类型是自动检测的。（检测结果一般取最大的带宽速率）
  2. 确认版本匹配情况
  3. 握手包，登陆验证
  4. 尝试能否使用EDNS0协议，以便于传输大于 512 字节
  5. 确认传输编码方式
  6. 确认下载速度
  7. 尝试延迟模式
  8. 设置片段大小
  9. 握手结束

DNS tunnel 传输类型：

默认情况下，自动检测技术会自动探测合适的DNS请求类型，以达到最大的带宽速率。带宽从高到低依次是：NULL、PRIVATE、TXT、SRV、MX、CNAME和A类型。注意，SRV，MX和A可能将通过“智能”高速缓存名称服务器获取实际IP地址的额外查找，这可能会减慢或完全失败。（其中NULL和PRIVATE类型，还不是很清楚）然而，有些DNS中继服务器会施加了偏移图片的限制，这可能导致某些DNS请求类型会失败？？？？这不是很懂

iodine 提供多种编解码器，分别是base32、base64、base64u、base128。base128的传输效率最高，但是某些情况下会不适用。自动检测模式下，iodine会依次从base32—》base128的顺序检测，最终取一个最高级的编解码器。

其余需要注意的点

  1. iodine 支持直接转发和中继两种模式。客户端和服务端建立通信后，可以看到客户机上多出一块名为dns0的虚拟网卡。iodine支持NULL,TXT,SRV,MX,CNAME,A等多种查询请求类型,并且支持EDNS,支持base32，base64，base128等多种编码规范。iodine在直连模式下，速度相当可观。在中继模式下，使用谷歌的dns，也是Dns Tunneling工具中速度最快的。
  2. 后台会持续ping数据，保证数据连同
  3. 客户端会查询一个外部的IP用以发送数据。

OPTIONS

帮助文件

共有的选项
-v  打印版本然后退出
-h  打印使用信息然后退出
-f  保持前台运行
-4  强制使用IPv4的DNS请求
-6  强制使用IPv6的DNS请求
-u user 在建立隧道后，放弃特权，以user用户运行（建立隧道一般需要root权限）
-t chrootdir 建立隧道后，切换root的目录，用于隔离
-d device 使用TUN设备来替代通常的设备，在Linux上是dnsX或者tunX。在Mac OS X 10.6,为utunX，它会尝试使用内置在OS系统中的utun设备
-P password 用于认证的密码。如果没加这个指令，连接过程中会让你输入密码。密码最长为32个字符
-z context 在初始化后，应用SELinux的环境（未理解）
-F pidfile 新建一个pidfile，写入其进程号
客户端选项
-r 跳过原始UDP模式。如果没有使用，iodine会尝试直接连接到运行iodined服务器的公网IP上，测试其是否可以直接访问。如果可以直接访问，流量就将会直接发送到服务器而不是DNS中继
-R rdomain 使用OpenBSD路由域用于DNS连接
-m fragsize 控制最大下载速度的片大小。如果没有设置，客户端会自动测试最大的可接受下载速度
-M namelen 最大的上传域名长度，默认为255. 范围为100-255.使用此选项可缩减上行带宽，有利于下行带宽。对于在使用全长主机名执行不可靠的DNS服务器时也很有用，当片段大小自动探测器每次返回非常不同的结果时，这是值得注意的。
-T dnstype
DNS请求类型覆盖。 默认情况下，自动检测将探测工作的DNS请求类型，并将选择预期提供最多带宽的请求类型。 然而，可能发现DNS中继施加了偏移图片的限制，这可能导致提供更多带宽的“意外”DNS请求类型。
在这种情况下，使用此选项覆盖自动检测。 在（预期）减少带宽顺序，支持的DNS请求类型是：NULL，PRIVATE，TXT，SRV，MX，CNAME和A（返回CNAME）。 请注意，SRV，MX和A可能将通过“智能”高速缓存名称服务器获取实际IP地址的额外查找，这可能会减慢或完全失败。 PRIVATE类型使用值65399（在“私有使用”范围内），并且需要实现RFC 3597的服务器
-O downenc 强制所有查询类型响应（NULL除外）的下游编码类型。 默认为自动检测，但可能无法发现更高级编解码器的所有问题。 使用此选项覆盖自动检测。 Base32是最低级的编解码器，应该始终工作; 当自动检测失败时使用。 Base64提供更多带宽，但可能无法在所有名称服务器上工作。 Base64u等于Base64，除了使用下划线（'_'）而不是加号（'+'），可能在Base64不工作的地方工作。 Base128使用高字节值（大多数在iso8859-1中的重音字母），这可能与一些名称服务器工作。 对于TXT查询，Raw将提供最大的性能，但只有当名称服务器路径对于被认为是“可读文本”的响应是完全8位清理时，这才会起作用。
-L 0|1 惰性模式开关。 -L1（默认）：使用延迟模式以提高性能和减少延迟。 少部分DNS中继似乎无法处理延迟模式下的流量模式，导致没有或很少的数据通过。 iodine客户端将检测到这一点，并尝试切换回传统模式，但这可能总是工作。 在这些情况下，使用-L0强制在传统模式下运行。
-I interval 请求之间的最大间隔（ping），以便中间DNS服务器不会超时。 默认为4，在延迟模式，在大多数情况会工作正常。 当太多SERVFAIL错误发生时，iodine会自动将其降低到1.为了获得绝对最小DNS流量，增加到4以上，但不要高到SERVFAIL错误开始发生。 有一些DNS中继具有非常小的超时，特别是dnsadvantage.com（ultradns），即使与-I1将给SERVFAIL错误; 数据仍然会有波谷，这些误差可以忽略。 最大有用值为59，因为iodined将在不活动60秒后关闭客户端的连接。

服务端选项
-c 禁用检查所有传入请求的客户端IP地址。 默认情况下，来自不匹配的IP地址的请求将被拒绝，但是当通过DNS服务器集群路由请求时，这将导致问题
-s 不尝试配置IP地址或MTU。 只有在您已经配置了将要使用的设备时，才应使用此选项
-D 提高debug级别。 级别1会打印每个RX/TX数据包的信息。使用-f选项。在级别2（-DD）或更高版本上，将打印出DNS详细包信息。 当使用Base128上行编码时，最好将其视为ISO Latin-1文本，而不是（非法）UTF-8。 这很容易做到：使用命令行"LC_ALL = C luit iodined -DD ..."（见luit（1））
-m mtu 设定tun设备的mtu（最大传输单元）大小.它会在登陆的时候，发送到客户端，然后客户端会对其tun设备使用同样的mtu。默认为1130，注意如果需要的话，DNS网络会自动适应这个值。
-l listen_ip4 服务端仅接受某个特定的ip4地址发来的数据。默认情况它会接受来送任何来源的数据
-L listen_ip6 服务端仅接受某个特定IP6地址的数据。默认会接受任何来源的数据
-p port 让服务端监听port端口，而非默认的53端口。如果'listen_ip4'不包括本地主机，这个'端口'可以与'dnsport'相同。 注意：您必须自己将dns请求转发到此端口。
-n auto|external_ip 在NS响应中返回的IP地址。 默认值是返回在查询中用作目标的地址。 如果external_ip是'auto'，iodined将使用ipify.org web服务来检索主机的外部IP，并将其用于NS响应。(检索ipify获取（对外ip）公网的ip)
-d dnsport 如果指定此端口，则不在隧道域内的所有传入请求将转发到localhost上的此端口，以由真实DNS处理。 如果'listen_ip'不包括localhost，这个'dnsport'可以和'port'相同。 注意：转发不完全透明，不建议在生产环境中使用。
-i max_idle_time 如果没有接收到流量，请使服务器在max_idle_time秒后停止。 这应该与systemd或upstart按需激活相结合才能有效。
客户端参数：
nameserver：用于中继dns流量的名称服务器。 这可以是任何中继名称服务器或运行iodined如果可达的服务器。 此字段可以作为IPv4 / IPv6地址或作为主机名。 此参数是可选的，如果未指定，将从/etc/resolv.conf文件读取名称服务器。
topodomain：dns流量将作为“topdomain”下的子域的查询发送。 这通常是您拥有的域的子域。 使用短的域名获得更好的吞吐量。 如果名称服务器是iodined服务器，则可以自由选择顶级域。 此参数必须在客户端和服务器上相同。
服务端参数：
tunnel_ip[/netmask]
这是tun接口上的服务器的IP地址。 客户端将被给予范围中的下一个ip号码。 建议使用10.0.0.0或172.16.0.0范围。 默认网络掩码为/27，可以通过在此处指定来覆盖。 使用较小的网络将限制并发用户数。
topdomain
dns流量预计到达作为'topdomain'下的子域的查询。 这通常是您拥有的域的子域。 使用短的域名获得更好的吞吐量。 此参数必须在客户端和服务器上相同。 除了“topdomain”之外的域的查询将在给出-b选项时转发，否则它们将被删除。
安全
登录是一个相对安全的地方-密码为MD5哈希，该密码在传输前从未在之前传输过。 但是，所有其他数据不以任何方式加密。 DNS流量也容易受到重放，注入和中间人攻击，特别是当使用-c选项时。 强烈建议使用ssh或vpn隧道。 在服务器和客户端上，使用iptables，pf或其他防火墙阻止从tun接口进入的所有流量，除了使用的ssh或vpn端口。
环境
IODINE_PASS
如果环境变量IODINE_PASS被设置，iodine将使用它设置为密码的值，而不是请求一个。 -P选项仍然优先。
IODINED_PASS
如果设置了环境变量IODINED_PASS，iodined将使用它设置为密码的值，而不是请求一个。 -P选项仍然优先。

iodine的协议数据信息

1. iodine中相关的DNS 协议

快速字母索引／寄存器

索引 寄存器
0-9 数据包
A-F 数据包
I IP地址
L 登陆
N 下载速度（NS.topdomain A型回复）
O 选项
P ping
R 下游压缩探头
S 切换上游编解码器
V 版本
W （WWW.topdomain A型回复）
Y 下行编解码检查
Z 上行编解码器检查

（Cache Miss Counter）CMC = 2 byte 缓存不命中计数器，每次缓存不命中时会增加数据

一、版本验证数据包：（Version）

  • 客户端发送包格式：

    • 第一个字节为v或V
    • 其余的字节以base32编码：4字节的大端协议版本信息+CMC（缓存计数器）

  • 服务端回应包格式：

    1. 4字节：

      VACK： 表示版本验证正常，后接登陆验证数据

      ​VNACK： 表示版本不同，后接服务器版本信息

      ​VFUL： 表示服务端连接的用户数已满，后接最大用户数量

    2. 4 字节的信息：分别代表先前所说的登陆验证数据／版本信息／最大用户数量

    3. 1字节的新用户的userid（如果不是VACK，则为任意数据）

二、登陆验证数据包（Login）
  • 客户端发送数据包格式：
    • 第一个字节是l或L
    • 其余字节以base32编码方式编码：1字节的userid，16字节的md5哈希值：（前面32字节的password）xor（8次重复的登陆验证信息）+再后接CMC
  • 客户端回应包格式：
    • LNACK 表示没有被接受，登陆验证失败
    • x.x.x.x-y.y.y.y-mtu-netmask 表示登陆验证成功（server ip-client ip-mtu-netmask）
三、IP请求（用于尝试原始登陆）
  • 客户端发送数据包格式：
    • 第一个字节是i或I
    • 编码为base32的5个比特userid信息，3个比特的CMC信息
  • 服务器回应包格式：
    • BADIP（如果userid非法）
    • 正常包：
      • 第一个字节为I
      • 后接iodined 服务器的DNS ip(非服务器自身的IP，其伪装的内网IP，如192.168.11.1）:可能为4字节的IPv4或16字节的IPv6
四、上传检查／反射
  • 客户端发送数据包格式：
    • 第一个字节是z或Z
    • 大量不能被解码的数据
  • 服务器回应包格式：
    • 被请求的域复制为原始数据，在可用于请求类型的最低级下游编解码器中。（还未理解！）
五、下载检查
  • 客户端发送数据包格式：
    • 第一个字节是y或Y
    • 1个字节，意味着使用下行编码检查
    • 以base32格式编码的5位检查变量，3位CMC信息
    • 可能会有额外的数据，依赖于检查变量

  • 服务端发送数据包格式

  • 所请求的下载的数据；数据内容取决于检查变量编号。
  • BADCODEC 如果请求的数据，不可达。
    • BADLEN 如果验证变量不可达或者其它额外的数据
    • 在O选项下，下载编码字符是一样的。
    • 检查变量信息：发送一个编码的字符DOWNCODECCHECK1 定义在encoding.h
    • 其它的一些编码格式，比如base64等
六、选择编码器

  • 客户端发送

    • 第一个字节是s或S
    • 以base32编码的5位userid信息

    • 以base32编码的5位表示要选择的编码格式

      • 5：base32

      • 6：base64

      • 26:base64u

      • 7: base128

    • 以base32编码的3字节的CMC

  • 服务端发送：

    • 确认后，回复编码格式的编号信息。（接下来，所有的上传数据必须以这种格式来编码）
    • BADCODEC 更改编码没有被确认。客户端必须回退到一开始的编码方式
    • BADLEN 如果发送的请求长度太短
七、选项

  • 客户端发送包格式：

    • 第一个字节是s或S
    • base32格式的5位userid
    • 1字节的option
    • base32格式的3字节CMC

  • 服务端发送包格式

    • 接受后，option的全名.接下来，option会马上开始在服务端生效。

    • BADCODEC 如果没有被接受，先前的模式继续执行

    • 注：所有的options仅影响与其所请求的客户端的连接

    • options的字符：

      t or T: Downstream encoding Base32, for TXT/CNAME/A/MX (default)
s or S: Downstream encoding Base64, for TXT/CNAME/A/MX
u or U: Downstream encoding Base64u, for TXT/CNAME/A/MX
v or V: Downstream encoding Base128, for TXT/CNAME/A/MX
r or R: Downstream encoding Raw, for PRIVATE/TXT/NULL (default for
	PRIVATE and NULL)

    • 如果编解码器不支持请求类型，服务器将使用Base32; 请注意，服务器将回答客户端发送的任何请求类型的混合。服务器可以忽略此选项; 客户端必须始终使用每个下游DNS数据包中指示的下游编码类型。

    • l或L：延迟模式，服务器将保持一个请求未应答，直到下一个进来。仅适用于数据传输; 握手包总是立即回答。 i或I：立即（非延迟）模式，服务器将立即应答所有请求（几乎）。

八、探针下游片段大小（探测下载速度）
  • 客户端发送包格式：
    • 第一个字节是r或R
    • base32编码的15位信息（UUUUF FFFFF FFFFF 4位的userid信息，11位的片大小）
    • 接下来接一长串随机的数据，其内容不必关心

  • 服务端发送

    • 请求的字节数作为响应。 前两个字节包含请求的长度。 第三个字节是107（0x6B）。 第四个字节是随机值，每个后续字节以107递增。这由客户端检查以确定损坏。
    • BADFRAG 如果请求的长度不被接受，则拒绝。
九、设置下载片段大小（设置下载速度）
  • 客户端发送：
    • 第一个字节为n或N
    • 接下来以base32编码：
      • 1字节的userid
      • 2字节的下载片段大小
      • CMC
  • 服务端发送
    • 2字节的新下载片段大小。这之后，所有的下载有效载荷的长度为max（fragsize+2）字节长
    • 如果不被接受，返回BADFRAG
十、数据

上传数据头

 3210 432 10 43 210 4321 0 43210
+----+---+--+--+---+----+-+-----+
|UUUU|SSS|FF|FF|DDD|GGGG|L|UDCMC|
+----+---+--+--+---+----+-+-----+ 下载数据头

 7 654 3210 765 4321 0
+-+---+----+---+----+-+
|C|SSS|FFFF|DDD|GGGG|L|
+-+---+----+---+----+-+ UUUU = Userid L = Last fragment in packet flag 数据包标志中的最后一个片段 SS = Upstream packet sequence number 上传包的序列号 FFFF = Upstream fragment number 上传片段数 DDD = Downstream packet sequence number 下载包序列号 GGGG = Downstream fragment number 下载片段数 C = Compression enabled for downstream packet 对下行数据包启用压缩 UDCMC = Upstream Data CMC, 36 steps a-z0-9, case-insensitive 上游数据CMC 36个步骤a-z0-9，不区分大小写

上行数据包以1字节ASCII十六进制编码用户字节开始; 然后3个字节Base32编码头; 然后1 char data-CMC; 然后得到有效载荷数据，用选择的上游编解码器编码。

下载数据以2字节的数据头开始，接下来是有效载荷数据，它可能会被压缩

在NULL或PRIVATE的回应中，下载数据一般都是原生的（未编码的）。其它的类型下，一般都会被编码。

编码格式从第一个字节的数据得到。

TXT类型：

t or T: Base32	 encoded before chop, decoded after un-chop
s or S: Base64	 encoded before chop, decoded after un-chop
u or U: Base64u	 encoded before chop, decoded after un-chop
v or V: Base128	 encoded before chop, decoded after un-chop
r or R: Raw	 no encoding, only DNS-chop SRV/MX/CNAME/A类型:
h or H: Hostname encoded with Base32
i or I: Hostname encoded with Base64
j or J: Hostname encoded with Base64u
k or K: Hostname encoded with Base128 SRV和MX可以回复多个主机名，每个主机名分别编码。 每个具有10多个优先级，并且在严格地增加优先级序列10,20,30等中没有间隙地进行编码/解码。 注意，一些DNS中继将随机响应中的答案记录。
十一、Ping
  • 客户端发送
    • 第一个字节为p或P
    • 其余以base32编码
      • 1字节 4位的userid
      • 1字节
        • 3位的下载序列号
        • 4位的下载片段大小
      • CMC
  • 服务器对Ping和数据包的响应是DNS NULL / TXT / ..类型响应，始终从2字节下行数据头开始，如上所示。 如果服务器没有任何发送，则在标头之后不添加数据。如果服务器有要发送的东西，它将在报头之后添加下游数据分组（或其一些片段）。
CATALOG
    FEATURED TAGS
    Web 编程 Security 算法 学习笔记 操作系统 SQL PHP 脚本语言 C++ 学习总结 计算机网络 安全工具 扯淡 Hnu 链路层 CTF DNS AWD Papers AOS Python WP
    FRIENDS