kk Blog —— 通用基础


date [-d @int|str] [+%s|"+%F %T"]
netstat -ltunp
sar -n DEV 1

RRSIG、DNSKEY、信任炼和NSEC

1
2
3
4
dig @192.58.128.30 +dnssec . A
dig @192.58.128.30 +dnssec . NS

dig @192.58.128.30 +dnssec . DNSKEY

https://www.dazhuanlan.com/xwuxin/topics/1848106

DNSSEC 验证流程

第一步:RRSIG

前述提到,DNSSEC 的状况下,每一个纪录都应该要经过数字签章做签署的动作。所以 DNSSEC 里面有提到一种 DNS 纪录,这个纪录叫做 RRSIG,会附在 DNS 请求的回复当中。

内容大概像这样:

1
2
3
4
5
6
7
8
9
   网域名称       TTL  类型   内容
   a.z.w.example. 3600 IN MX  1 ai.example.
   a.z.w.example. 3600 RRSIG  MX 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
                              4kX18MMR34i8lC36SR5xBni8vHI= )

第一行是 ai.example 这个网域的 MX 纪录。

第二行是给第一笔记录使用的 RRSIG 纪录。

RRSIG 的格式是这样的:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[对应格式] [算法编号] [涵盖数量]  [有效时间长短] [签章期限] 
|            |         |              |           |
|   ---------/         |              |           |
|  /  -----------------/              |           |
|  | /  /-----------------------------/           |
|  | |  |   /-------------------------------------/
|  | |  |   |
|  | |  |   |
MX 5 2 3600 20040509183619 ( 20040409183619 38519 example. OM.....HI= ) 
                             |               |     |         |
  /--------------------------/               |     |         |
  |          /-------------------------------/     |         |
  |          |      /------------------------------/         |
  |          |      |            /---------------------------/
[签署日期] [Tag] [签署者名称] [内容,base64]

DNSKEY

随着 RRSIG 的出现,我们拿到凭证的内容了。不过我们需要验证这个签章是不是伪造的,然后是谁签的。这个信息,会在 DNSKEY 纪录当中。

1
2
3
4
5
6
7
   example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
                                          Cbl+BBZH4b/0PY1kxkmvHjcZc8no
                                          kfzj31GajIQKY+5CptLr3buXA10h
                                          WqTkF7H6RfoRqXQeogmMHfpftf6z
                                          Mv1LyBUgia7za6ZEzOJBOztyvhjL
                                          742iU/TpPSEDhm2SNKLijfUppn1U
                                          aNvv4w==  )

DNSKEY 里面会包含拿去签署 RRSIG 的公钥。

不过,即使我们能够确认「这个 RRSIG 和 DNSKEY 对得起来」,也还不能够确认「这个 DNSKEY 真的属于这个网域」。

所以我们会需要一个能够信任方式,来验证这个 DNSKEY。

就像前面提到的 HTTPS 凭证信任链的状况,我们可能有几种做法,可以验证这个东西:

  1. 用其他的方式去获得「这个网域真正的公钥」,例如 PGP、中华邮政寄 U 盘、用纸抄、用 scp 先下载一份

  2. 叫别人证明你是合法的(参考 HTTPS 中介凭证机制)

信任链机制

前述提到,只拿到 DNSKEY 没什么用。然后若要将上述第一种取得真正公钥的方式,放到 DNS 这种许多人用的协定之上,是不可行的。想像一下,你要联网之前,必须要插 U 盘。这是一个多荒诞的事情?

所以,我们可以依赖上一级网域的 DNS 纪录,把上一级凭证的公钥放在那边。在 DNSSEC 中,这个叫做 DS (Delegation Signer) 纪录。由于你可以指定非常多的子网域,所以 DS 纪录中,只会记载「这个凭证的指纹 (hash)」。

真的很短,他长得像这样:

1
2
 dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
                                            98631FAD1A292118 )

然后假设一笔 DNSKEY 是被上一级签署过的话,他会看起来像这样:

1
2
3
4
5
6
7
8
9
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
                                         fwJr1AYtsmx3TGkJaNXVbfi/
                                         2pHm822aJ5iI9BMzNXxeYCmZ
                                         DRD99WYwYqUSdjMmmAphXdvx
                                         egXd/M5+X7OrzKBaMbCVdFLU
                                         Uh6DhweJBjEVv5f2wwjM9Xzc
                                         nOf+EPbtG9DMBmADjFDc2w/r
                                         ljwvFw==
                                         ) ;  key id = 60485

其中,我们会发现 key id 和上面的 DS 纪录是一样的。另外,是可以通过 DNSKEY 去计算出 DS 的数值,所以我们可以通过证明这两个之间的关系,来保证 DNSKEY 纪录的可靠性。 特殊状况: 找不到纪录怎么办? (NSEC)

在 DNS 的状况下,基本上,若找不到东西,只要回复 NXDOMAIN 就好了。不过在 DNSSEC 的状况下,由于回复的数据内容内也要证明这消息不是伪造的,但这东西根本查不到,所以我们要想办法告诉对方「我真的找不到」。

DNSSEC 想到了这个问题,所以又有一种纪录叫做 NSEC (Next Secure)。这个纪录里面会记载说「下一笔纪录是什么」。

所以,假设今天有 A、B、D。有人问了 C,你找不到,但是你可以用 NSEC 和他说:「下一笔真的是 D,我知道他还有 A、RRSIG 和 NSEC,你可以看看 D 是不是真的有这些东西」来确保你没有说谎。

由于 DNS 纪录是以字母来做排序的,所以你可以确定「真的没有那笔东西」。

另外,若某一个网域的纪录是存在的,只是问错类别(例如你有 A 但对方问 MX)的话,这时候的回复里面会告诉对方这个网域所有的纪录

不过,不管是不是这个状况,NSEC 都有可能引起安全疑虑,之后会提到。

邮件MIME格式分析

base64 解码

1
2
3
4
5
6
7
From: "=?gb2312?B?26zQocHB?=" <gaoxl@legendsec.com>

26zQocHB 是 base64 编码, 解码方法:

echo 26zQocHB | base64 -d > /tmp/dd

iconv -fgbk -tutf8 /tmp/dd

https://www.cnblogs.com/crystalray/atricles/3302427.html

总体来说,MIME消息由消息头和消息体两大部分组成。这里,分别称为为邮件头、邮件体。

邮件头

邮件头包含了发件人、收件人、主题、时 间、MIME版本、邮件内容的类型等重要信息。每条信息称为一个域,由域名后加“: ”和信息内容构成,可以是一行,较长的也可以占用多行。域的首行必须“顶头”写,即左边不能有空白字符(空格和制表符);续行则必须以空白字符打头,且第 一个空白字符不是信息本身固有的,解码时要过滤掉。

邮件头中不允许出现空行。有一些邮件不能被邮件客户端软件识别,显示的是原始码,就是因为首行是空行。

例如:

1
2
3
4
5
6
7
8
9
Date: Mon, 29 Jun 2009 18:39:03 +0800
From: "=?gb2312?B?26zQocHB?=" <gaoxl@legendsec.com>
To: "moreorless" <moreorless@live.cn>
Cc: "gxl0620" <gxl0620@163.com>
BCC: "=?gb2312?B?26zQocHB?=" <venus.oso@gmail.com>
Subject: attach
Message-ID: <200906291839032504254@legendsec.com>
X-mailer: Foxmail 6, 15, 201, 21 [cn]
Mime-Version: 1.0

邮件体

在邮件体中,大致有如下一些域:

有的域除了值之外,还带有参数。值与参数、参数与参数之间以“;”分隔。参数名与参数值之间以“=”分隔。

邮件体包含邮件的内容,它的类型由邮件头的“Content-Type”域指出。常见的简单类型有text/plain(纯文本)和text/html(超文本)。

multipart类型,是MIME邮件的精髓。邮件体被分为多个段,每个段又包含段头和段体两部分,这两部分之间也以空行分隔。常见的multipart类型有三种:multipart/mixed, multipart/related和multipart/alternative。从它们的名称,不难推知这些类型各自的含义和用处。它们之间的层次关系可归纳为下图所示:

可以看出,如果在邮件中要添加附件,必须定义multipart/mixed段;如果存在内嵌资源,至少要定义multipart/related段;如果纯文本与超文本共存,至少要定义multipart/alternative段。

示例:

 

MIME编码

参考rfc2047,MIME Part Three:Message Header Extensions for Non-ASCII Text

http://tools.ietf.org/html/rfc2047

MIME编码的两种方法:

对邮件进行编码最初的原因是因为Internet上的很多网关不能正确传输8bit内码的字符,比如汉字等。编码的原理就是把8bit的内容转换成7bit的形式以能正确传输,在接收方收到之后,再将其还原成8bit的内容。   

MIME是“多用途网际邮件扩充协议”的缩写,在MIME协议之前,邮件的编码曾经有过UUENCODE等编码方式,但是由于MIME协议算法简单,并且易于扩展,现在已经成为邮件编码方式的主流,不仅是用来传输8 bit的字符,也可以用来传送二进制的文件,如邮件附件中的图像、音频等信息,而且扩展了很多基于MIME的应用。

从编码方式来说,MIME 定义了两种编码方法Base64与QP(Quote-Printable):

Base64

Base64是一种通用的方法,其原理很简单,就是把三个Byte的数据用4个Byte表示,这样,这四个Byte中,实际用到的都只有前面6 bit,这样就不存在只能传输7bit的字符的问题了。Base64的缩写一般是“B”。

Base64将输入的字符串或一段数据编码成只含有{‘A’-‘Z’, ‘a’-‘z’, ‘0’-‘9’, ‘+’, ‘/’}这64个字符的串,'=‘用于填充。其编码的方法是,将输入数据流每次取6bit,用此6bit的值(0-63)作为索引去查表,输出相应字符。这样,每3个字节将编码为4个字符(3×8 → 4×6);不满4个字符的以’=‘填充。 Base64的算法很简单,它将字符流顺序放入一个24位的缓冲区,缺字符的地方补零。 然后将缓冲区截断成为4个部分,高位在先,每个部分6位,用64个字符重新表示。如果输入只有一个或两个字节,那么输出将用等号“=”补足。这可以隔断附加的信息造成编码的混乱。

QP

另一种方法是QP(Quote-Printable)方法,通常缩写为“Q”方法,其原理是把一个8 bit 的字符用两个16进制数值表示,然后在前面加“=”。所以我们看到经过QP编码后的文件通常是这个样子:=B3=C2=BF=A1=C7=E5=A3=AC=C4=FA=BA=C3=A3=A1。

QP编码要求编码后每行不能超过76个字符。当超过这个限制时,将使用软换行,用”=”表示编码行的断行,后接CRLF。(76的限制包括”=”)。

“=” 等号被编码为”=3D”。

tab和空格出现在行尾时,需要被编码为”=09”(tab) “=20”(space)

编码格式:encoded-word = “=?” charset “?” encoding “?” encoded-text “?=”

编码信息有"=?“和”?=“括起来,”=?“后是字符集名称,再一个”?“后是编码方式,再一个”?“后是编码后的字符串。字符集和编码方式都不区分大小写。

字符集可以是任意系统支持的字符集(iso-8859-1、utf-8、gb2312、gbk、gb18030….)

编码方式有两种:"B"或"b"代表base64编码;"Q"或"q"代表QP编码。

Generally, an “encoded-word” is a sequence of printable ASCII characters that begins with “=?”, ends with “?=”, and has two “?"s in between. It specifies a character set and an encoding method, and also includes the original text encoded as graphic ASCII characters, according to the rules for that encoding method.

 

SMTP与MIME的关系

从上图可以看出发件人、收件人地址都出现了两次,一次在smtp命令中(SMTP email address),一次在邮件正文中(MIME email address)。需要注意的是:

邮件正文中可以包含发件人、收件人的别名,smtp命令中不可以

密送人的地址不一定会出现在邮件正文中。不同客户端实现不同。

参考:

rfc4021,Registration of Mail and MIME Header Fields,

http://www.apps.ietf.org/rfc/rfc4021.html,

4个替代phpMyAdmin的工具

https://blog.csdn.net/weixin_34392906/article/details/92377986

phpMyAdmin是管理MySQL数据库最流行的Web界面。但也有许多其他的工具,我们可代替phpMyAdmin的使用。

1. Adminer

Adminer是我的第一选择使用的,而不是phpMyAdmin。 Adminer是单一的PHP脚本,它可以在文档根目录轻松上传,没有任何安装或配置,访问就可用。

Adminer还可以用来管理SQL服务器,Oracle,PostgreSQL等等。 下载Adminer

2. MyWebSQL

MyWebSQL是一个最终的台式机替代品,他在Web上管理你的MySQL数据库。

它的界面像自己喜欢的桌面应用程序,你不需要不断切换网页,以简单的做好事情。

只需登录到您的数据库和管理数据库,如果你是在您的桌面上工作! 下载MyWebSQL

3. phpMiniAdmin

phpMiniAdmin是快速和容易管理MySQL数据库,是phpMyAdmin轻量级的选择。

phpminiadmin是写在只有大小为10KB+,它可以轻松上传到Web服务器的文档根目录,并在Web浏览器访问PHP。 下载phpMiniAdmin

4. SQL Buddy

SQL Buddy是用于MySQL管理的一个很棒的工具,phpMyAdmin的一个替代品。

它超级容易建立,还有一个漂亮的界面。 下载SQL Buddy