【www.bbyears.com--php安全】
所有业务的正常运转，离不开一个安全的运行环境，系统安全性直接关系到业务稳定、可靠、以及可用性，本章就介绍一些系统安全相关的话题，具体包括：1、加密基础概念
2、CA和证书的基础概念
3、ssl协议和openssl命令
4、利用openssl建立私有CA，完成证书颁发和管理
5、利用gpg实现加解密
6、ssh服务
7、dropbear提供ssh服务
8、aide监控文件安全性
9、sudo相关内容
第一章 加密基础相关概念
1、安全的目标：
保密性：confidentiality
完整性：integrity
可用性：availability
2、攻击类型：
威胁保密性的攻击：窃听，通信量分析
威胁完整性的攻击：更改，伪装，重放，否认
威胁可用性的攻击：拒绝服务(DoS)
3、为了完成安全的目标用到的解决方案
技术：加密和解密
加密和解密：
传统加密方法：替代加密方法，置换加密方法
现代加密方法：现代块加密方法
服务：用于低于攻击的服务，也就是为了上述安全目标而特地设计的安全服务
服务：
认证机制
访问控制机制
4、对称加密
对称加密：加密和解密使用同一个秘钥;但加密算法和解密算法可能不同
工作过程为：
发送者将发送的数据利用秘钥，使用加密的算法加密成明文，发送给对方;接收方收到加密的数据后，利用同一个秘钥，和解密的算法，将数据由密文解密成明文
常见的对称加密算法：
DES：Data Encryption Standard，56位秘钥
3DES：Triple DES
AES：Advanced Encryption Standard，支持128位、192位、256位、384位秘钥
Blowfish
Twofish
RC6
CAST5
对称加密特性：
<1>加密解密使用同一个秘钥
<2>将原始数据分隔成为固定大小块，逐个进行加密
对称加密的缺陷：
<1>秘钥过多
<2>秘钥分发困难
<3>数据来源无法确认
5、公钥加密(非对称加密)：秘钥分为公钥和与之配对的私钥
公钥：公钥从私钥中提取产生，可以公开给所有人;pubkey
私钥：通过工具创建，私钥只能使用则自己留存，必须保证其私密性，secret key
特点：用公钥加密的数据，只能使用与之配对的私钥解密;反之，用私钥加密的数据只能用与之配对的公钥解密
用途：
数字签名：主要在于让接收方确认发送方的身份。将数据用单项加密(MD5、SHA)算法，得出来的特征码，用自己的私钥进行加密，这就是数字签名
秘钥交换：发送方用对方的公钥加密一个对称加密的秘钥，并发送给对方，以实现秘钥交换
数据加密：一般很少用公钥加密发送的数据本身，因为公钥加密的加密效率很低，因此一般用对称秘钥加密要发送的数据本身
公钥机密的工作模式：
模式一：公钥加密，私钥解密
B将数据发送给A，B就拿A的公钥对数据进行加密，然后将加密后的数据发送给A，那此时，加密后的数据只能被A的私钥进行解密，因此，即使有第三方拿到加密的数据，也无法完成解密，只有A自己有自己的私钥，因此实现了数据的保密性
模式二：私钥加密，公钥解密
A用自己的私钥加密一份数据给B，加密后的数据只能被A的公钥进行解密，因此，如果有第三方拿到加密后的数据，是能够解密的，因为A的公钥是公开的，任何人都可以拿到，因此可以解密
但此种方式的作用，并不是真正拿来加密数据，而是用来进行身份验证(数字签名)，也就是说，A用自己的私钥加密一段数据(数据不是要发送的数据本身，而是要加密数据利用单向加密算法得出来的特征码)，然后发送给B，B拿A的私钥进行解密，能够解密成功，就证明发送方一定是A，因为只有A的公钥能解开A的私钥;一旦解开数据后，得到的就是要发送数据的特征码，等后面真正发送数据后，可以利用该段特征码，来验证数据的完整性
公钥加密的常用的算法：
RSA：既能实现数字签名，也能实现加解密
DSA：有时也被称为DSS，数字签名标准。仅能实现数字签名，不能实现加解密
6、单向加密：只能加密，不能解密。仅能提取数据的特征码
特性：
定长输出：无论原始数据多大，得出的特征码都是固定长度的
雪崩效应：原始数据的微小改变，将导致特征码的巨大变化
功能：主要用来实现验证数据的完整性
常见的单向加密算法：
MD5：Message Digest 5 消息摘要，5版本。128bit定长输出
SHA1：Secure Hash Algorithm 1，160位定长输出
SHA224、SHA256、SHA384、SHA512
7、秘钥交换:IKE(Internet Key Exchange)
常见的交换算法：
公钥加密：用对方的公钥加密对称秘钥，这样对方就能以自己的私钥解开，从而获得对称加密的秘钥
DH(Deffie-Hellman)算法：
<1> A: a,p 协商生成公开的整数a, 大素数p
B: a,p
<2> A:生成隐私数据 x， (x B:生成隐私数据 y,计算得出 a^y%p，发送给A
<3> A:计算得出 （ a^y%p） ^x = a^xy%p， 生成为密钥
B:计算得出 （ a^x%p） ^y = a^xy%p, 生成为密钥
8、加密通信的双方的通信过程展示
A有一段数据要发送给B,A就用单向加密的算法计算出数据的特征码，而后A用自己的私钥加密这段特征码，生成数字签名，至此能够保证数据的完整性(通过比对特征码)，和身份验证(数字签名),但是不能保证数据的保密性，因为数据本身还没被加密。
因此，A会继续在原有数据和数字签名的基础上，生成一个一次性的对称加密秘钥，然后利用对称加密算法结合秘钥，去加密原有数据和数字签名。然后，A用B的公钥，对对称加密的秘钥进行加密，并附加到之前利用对称加密算法生成的数据的后面，然后发送给B
当B收到数据后，就用B自己的私钥解密附加在后面的对称加密的秘钥，从而得到了对称加密的秘钥(这就完成了秘钥交换，实际是双方都知道了对称加密的秘钥的过程就是秘钥交换)，然后利用对称加密的秘钥进一步解开数据和数字签名，然后利用A的公钥解开数字签名，得到数据本身的特征码，然后利用同样的单项加密算法，计算出收到的数据的特征码，然后比对特征码，从而验证数据的完整性
9、中间人攻击：
以上通信过程中还是有一个严重的漏洞，就是当A和B键从来没进行过通信，那么A怎么获知B的公钥，或者B怎么获知A的公钥。假设当A没B的公钥时，向B发送请求，要求获知B的公钥，但是此时，如果有第三方C获取到请求后，冒充自己就是B，然后将C自己的公钥发送给A，A就认为C就是B。而C又会冒充自己是A，向B进行通信，从而也获取了真正B的公钥，而此后A和B通信的过程中，就都会交由C，数据的安全性就无从保障。这种情况就是中间人攻击
第二章 CA的和证书的基础概念
1、PKI:Public Key Infranstructure公钥基础设施
由四个部分组成：
签证机构：CA机构
注册机构：RA，相当于CA的派出机构，用于接收注册申请
证书吊销列表：CRL
证书存取库：CB
2、CA的作用
CA：保证通信双方，能够可靠的拿到对方的公钥(避免中间人攻击)，而设定的双方都信任的第三方可信机构
A将自己的公钥提请给CA，CA经过特殊的防伪处理后，将处理后的A的公钥发送给A，处理过后的A的公钥就称之为CA证书。以后，如果B如果请求要A的公钥，那么A就将CA证书发送给B,当B拿到证书后，不会立马就任何该证书，而是要验证该证书是否是合法的，还要验证是否是B信任的CA机构颁发的，验证完了之后，才会认可
CA证书一般会包含：提请证书的人的名称，提请人的公钥，证书有效期，然后CA机构会用自己的私钥，加密以上的一整段数据的特征码，然后将加密后的特征码(也就是数字签名)附加在数据之后，这个整体就是CA证书
CA证书后面有CA机构用CA机构自己的私钥对证书内容部分的特征码加密的数据，通信方要解开此数字签名就需要用到CA自身的公钥，但是如何获取到CA机构自己的公钥，如果直接申请，那么此时又会存在中间人攻击的可能，因此，一般是CA机构会给自己发一个CA证书，然后获取CA自身的证书，一般不能通过网络发送，因此一般情况下，是线下交易
3、CA证书格式：
X.509，定义证书结构和认证协议的标准，在X.509的标准中，定义了证书需要具备的结构：
版本号：是X.509的v1还是v2还是v3版本
序列号：CA机构所发出的证书的序列号
签名算法ID：证书所使用的算法
发行者的名称：CA机构自己的名称
证书有效期限
主体名称：提请CA证书的用户的名称
主体公钥：
发行者的唯一标识：CA机构的ID
主体的唯一标识：提请者的ID
扩展信息
发行者的签名：CA机构利用自己的私钥对以上内容的特征码加密，生成的数字签名，将数字签名附加在证书内容之后，作为证书的一部分
第三章 ssl协议和openssl命令
1、SSL协议：SSL和TLS
SSL：安全套接字层，由Netscape发布于1994年，分为V1.0、V2.0、V3.0但由于其版权属于Netscape公司，且各版本均被爆出有协议漏洞，因此使用的不多
TLS：Transport Layer Security，传输层安全，是国际互联网工程师协会发布的类似于SSL的协议，其分为V1.0、V1.1、V1.2、V1.3的版本，使用较多的是V1.2的版本
2、TLS的分层设计：
<1>最底层：基础算法的原语的实现，如AES、RSA、MD5
<2>向上一层：各种算法的实现，也就是算法的具体实现的方式
<3>再向上一层：组合算法实现的半成品
<4>最高层：用各种组件拼装而成的各种成品密码学协议软件;
3、SSL协议的开源实现：OpenSSL
OpenSSL由三部分组成：
libencrypt库：加密解密库，专用于实现加密解密功能，主要由开发人员使用
libssl库：用于实现ssl安全通信机制的库，主要由开发人员使用
openssl多用途命令行工具：openssl
4、SSL会话的主要的三步：
客户端向服务器端所要并验证证书(证书里面有服务器端的公钥信息);
双方协商生成对称秘钥;
双方采用对称秘钥，进行加密通信的过程
会话过程后，进行断开
5、在SSL会话之前开始之前的双方Handshake Protocol，SSL握手阶段的执行流程
也就是双方在正式开始SSL会话之前的通信前商量加密算法和生成会话秘钥阶段的详细过程介绍，(以HTTPS协议为例)
<1>第一阶段：client-hello
客户端向服务器端发送：
支持的协议版本，如：tls1.2
客户端生成一个随机数，用于稍后生成对称秘钥
支持的加密算法，比如AES、RSA、SHA
支持的压缩算法
<2>第二阶段：server-hello
服务器端向客户端发送：
确认使用的加密通信的协议版本，如tls1.2
生成一个随机数，用于稍后生成对称秘钥
确认使用的加密算法
向客户端发送服务器证书
如果有必要，有可能会向客户端索要客户端的证书(如：当客户端请求的是网银页面时)
<3>第三阶段：客户端收到服务器端的server-hello后给出的回应
验证服务器证书，如果没问题，则通过解密证书获取到服务器的公钥;
验证的内容：
发证机构：验证发证机构是否是可信的，也就是验证证书签名(CA的数字签名)
证书的完整性，也是验证证书的数字签名里面的解密出来的特征码
证书的持有者：验证证书里面的持有者是否与要访问的页面是一致的
证书有效期
证书是否被吊销
发送以下信息给服务器端：
一个随机数，用于生成对称秘钥
编码变更通知：表示随后的信息都将用双方商定的加密方法和秘钥发送
客户端握手结束通知：表示客户端在正式通信前的握手阶段结束
<4>第四阶段：服务器端
收到客户端发来的最后一个随机数后，利用含此随机数在内的一共三个随机数生成对称秘钥;
向客户端发送以下信息:
编码变更通知：表示随后的信息都将用双方商定的加密方法和秘钥发送
服务器端握手结束通知：表示服务器端握手阶段已经结束
6、基于SSL的通信的实现过程整理总结：
A、B双方要进行通信时：A为客户端，B为服务器端
<1>A发送hello信息给B，B接收后，发送hello信息给A，此时为双方建立通信前的确认，需要协商双方真正通信时所用到的加密算法，包括单向加密、对称加密、公钥加密、秘钥交换用的方法
<2>A请求B的证书，B于是将自己的证书(CA处理后的公钥)发送给A
一般情况下，客户端不会有证书提供给服务器端，因为一方面是证书的使用费使得客户端不会去用，另一方面客户端访问服务器端的时候，一般不会验证客户端的身份，比如访问某网站，网站不会要求客户端有证书才响应内容给客户端，而客户端是要验证服务器端的证书的，因为为了防止访问的网站的正确性，防止钓鱼网站等。
但有时服务器端也会验证客户端的证书，比如当客户端访问的是网银页面的时候，会验证证书，当我们去银行开通网银的时候，一般会有个加密狗之类的东西，其实里面存储的就是用户自己的ca证书，只是一般该ca证书的颁发机构不是市面上公认的CA机构，而是银行自己建的一个CA签发机构，仅对自己银行内部有效
<3>A收到B的证书后，验证B的证书，如果验证没有问题
<4>A验证B的证书没问题后，生成一个随机数，作为对称加密的秘钥，A利用双方之前协商的秘钥交换算法(假设为公钥加密)，则将此秘钥用B的公钥加密后发送给B
<5>B收到A发送过来的密文的秘钥后，利用自己的私钥，解密得出对称加密的秘钥，然后利用对称加密的秘钥和之前协商的对称加密的算法，给A发送A所请求的数据，进行正常数据的发送
<6>当正常的数据传输完成后，A(客户端)请求通信断开，服务器也断开，然后通信终止
7、openssl命令
openssl命令行工具有众多子命令，主要分为三类：
标准命令：enc、ca、req、genrsa…
消息摘要命令(dgst子命令相关)
加密命令(enc子命令相关)
<1>使用openssl命令行工具完成对称加密：
工具：openssl enc子命令
支持的算法：aes、des、3des等
enc命令的用法：
openssl enc -CIPHERNAME -e|d -in /PATH/TO/FILE -out /PATH/TO/FILE
选项解释：
-CIPHERNAME：加密的算法的名称，可通过openssl –help查看所支持的加密算法的名称
-e|d：-e表示加密，-d表示解密
-in /PATH/TO/FILE 要加密的文件
-out /PATH/TO/FILE 加密后的文件
-pass STRING 表示对称加密的秘钥是什么
-a|-base64 表示以base64文本格式进行编码，如果不指定，可能是以二进制格式进行编码
如对/testdir/file1进行对称加密：
openssl enc -des3 -e -a -salt -in /testdir/file1 -out /testdir/jmfile1 输入后回车，会要求输入对称加密的秘钥，输入完成，即可完成加密
-des3表示采用des3的加密算法，-a表示以base64文本格式进行编码，-salt表示加点杂质
解密上面加密的文件：
openssl enc -des3 -d -a -salt -in /testdir/jmfile1 -out /testdir/file2 输入后回车，会要求输入对称加密的秘钥，输入完成，即可完成解密
<2>单向加密
工具：openssl dgst、md5sum、sha1sum、sha256sum…
用法：
md5sum /PATH/TO/FILE
sha1sum /PATH/TO/FILE
openssl dgst -md5|-sha1… /PATH/TO/FILE
<3>生成用户密码的命令：
工具：passwd、openssl passwd
例如：
openssl passwd -1 -salt 12345然后回车，会提示要求输入密码，输入完成后，即可生成加密后的密码
-1 表示使用md5方式加密
-salt STRING表示生成密码时加入的杂质的内容
-salt后面加的杂质的内容可以用随机数生成，生成随机数可以用openssl的子命令生成
openssl passwd -1 -salt `openssl rand -hex 4`
<4>openssl生成随机数：
工具：openssl rand
用法：openssl rand [-out FILE] [-base64] [-hex] NUM
-out FILE 表示将生成的随机数保存在某个文件中
-base64 表示使用base64编码，生成的随机数后面可能会有=，要去掉=后才是真正的随机数
-hex 表示使用十六进制数字编码
NUM 表示生成随机字符串的长度
如：
openssl rand -base64 10
表示生成一个10个字节的随机数，采用base64编码格式进行输出
openssl rand -hex 10
输出10个字节的16进制字节长度的随机数，相当于输出20个字符
Linux上的随机数生成器：
/dev/random:仅从熵池中返回随机数，当随机数用尽，会阻塞后续请求随机数的应用
/dev/urandom:从熵池中返回随机数，随机数用尽，会利用软件生成伪随机数，不会阻塞。伪随机数不安全
熵池中随机数的来源：
硬盘I/O中断时间间隔
键盘I/O中断时间间隔
<5>openssl实现公钥加密：
加密解密：
支持的算法：RSA、ELGamal
工具：openssl rsautl
数字签名:
支持的算法：RSA、DSA、ELGamal
工具：openssl rsautl
秘钥交换
支持的算法：DH、RSA
生成私钥：(公钥一般不需要生成，而是自动的会从私钥中提取产生)
openssl genrsa 512|768|1024|2048…表示生成一个长度为512、768…位的私钥
openssl genrsa 1024 > /PATH/TO/FILE 表示生成一个1024位的私钥保存到文件中
openssl genrsa 1024 -out /PATH/TO/FILE 也表示生成一个1024位的私钥保存到文件中
生成的私钥文件，不能让其他人访问，因此一般要将私钥文件的权限变成600，为了简化步骤，可以直接在生成私钥时就定义其权限，如：
(umask 077;openssl genrsa 1024 -out /PATH/TO/FILE)
用了小括号，相当于在一个子shell中运行，因此此时的子shell的umask设置仅对子shell生效
从私钥中提取公钥：一般不用手工提取
openssl rsa -in /PATH/TO/私钥文件 -pubout
表示从私钥文件中提取出公钥
第四章 利用openssl建立私有CA，完成证书颁发和管理
1、openssl配置文件中关于CA的配置段介绍
openssl的配置文件为/etc/pki/tls/openssl.cnf，其中定义了openssl完成CA工作时的相关属性定义
2、建立私有CA
在确定配置为CA的服务器上生成一个自签证书，为CA提供所需的目录及文件即可
步骤：
<1>生成CA自己的私钥，而在openssl的配置文件中定义了私钥存放的位置为/etc/pki/CA/private/cakey.pem
(umask 077;openssl genrsa -out /etc/pki/CA/private/cakey.pem 2048 )
<2>为CA提供工作所需要的目录及文件：
mkdir /etc/pki/CA/{certs,crl,newcerts} 注意：如果目录不存在才创建
touch /etc/pki/CA/{serial,index.txt}
echo 01 >>/etc/pki/CA/serial
创建两个CA工作需要用到的文件，serial为存放证书编号的文件，并且要给该文件提供一个初始的编号，标号必须是2位数字。
index.txt文件用于存放签署过的证书的索引
<3>生成CA自己的自签证书，而在openssl的配置文件中，也定义了自签证书的存放位置为/etc/pki/CA/cacert.pem
发起签署CA证书的请求
openssl req -new -x509 -key /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.pem -days 3650
表示发起CA证书签署请求，
-new表示这是一个新申请的签署请求
-x509 表示这是自签证书，该选项只有在CA为自己生成自签证书时使用
-key指明私钥的存放路径
-out 标明所生成的请求的文件存放路径，如果是自签证书，将直接生成签署过的证书，如果不是自签证书，则将生成的签署请求文件发送给CA服务器，由CA服务器根据请求文件生成证书文件
-days 指明申请的证书的有效期限为多少天
命令执行后会要求填入一些信息：
国家代码：CN
省份：beijing
城市：beijing
公司名：nwc
部门：ops
持有者名称：ca.nwc.com(注意:此处最好与此CA服务器的主机名保持一致)
管理员的邮件地址：nwc@nwc.com
3、另一个主机建立CA申请请求,CA进行签署颁发证书
某服务器需要用到证书进行安全通行时，需要向CA服务器请求签署证书：
步骤：
<1>在需要使用证书的服务器上建一个目录，生成私钥(真实环境中建议将该目录建在需要用到证书的服务的相关目录下，便于管理)
<2>生成签署请求
openssl req -new -key /testdir/testssl/mykey.private -out /testdir/testssl/mykey.csr -days 365
表示生成证书签署请求，使用的私钥文件路径为/testdir/testssl/mykey.private，生成的签署请求的文件为/testdir/testssl/mykey.csr，申请的证书有效期为365天
执行命令后会要求填入一些信息：
国家、身份、城市、单位、部门、持有者、管理员邮箱等
注意：持有者要写成主机名， 否则可能造成后期用户访问时，提示证书与访问的主机名不一致，此处应为www.nwc.com
<3>将生成的请求文件拷贝到CA服务器上
<4>在CA服务器上进行签署，生成证书，在openssl的配置文件中，定义了签署完成的证书的存放位置为/etc/pki/CA/certs/目录下
openssl ca -in /tmp/mykey.csr -out /etc/pki/CA/certs/mykey.crt -days 365
表示签署证书，-in指明请求签署文件的路径，-out指明生成的证书的路径，-days表示签署多少天
命令执行后，会让确认两次，确认好了之后，即完成了签署的动作，生成了签署过后的证书
<5>将签署的证书发给请求方
4、证书的吊销
<1>在客户端获取要吊销的证书的serial
openssl x509 -in /PATH/FROM/CERT_FILE -noout -serial -subject
<2>在CA上，根据客户提交的serial与subject信息，对比检验是否与index.txt文件中的信息一致
吊销证书：
openssl ca -revoke /etc/pki/CA/newcerts/SERIAL.pem
<3>生成吊销证书的编号(第一次吊销一个证书时才需要执行)
echo 01 > /etc/pki/CA/crlnumber
<4>更新证书吊销列表
openssl ca -gencrl -out /etc/pki/CA/crl/ca.crl
查看crl文件：
openssl crl -in /etc/pki/CA/crl/ca.crl -noout -text
第五章 利用gpg实现加解密
1、gpg实现对称加密
<1>对称加密file文件
gpg -c file
ls file.gpg
<2>在另一台主机上解密file
gpg -o file -d file.gpg
2、gpg实现公钥加密
在hostB主机上用公钥加密，在hostA主机上解密
<1>在hostA主机上生成公钥/私钥对
gpg –gen-key
<2>在hostA主机上查看公钥
gpg –list-keys
<3>在hostA主机上导出公钥到nwckey.pub
gpg -a –export -o nwckey.pub
<4>从hostA主机上复制公钥文件到需加密的B主机上
scp nwckey.pub HOST_B:/PATH/TO/SOMEWHERE
<5>在需加密数据的hostB主机上生成公钥/私钥对
gpg –list-keys
gpg –gen-key
<6>在hostB主机上导入公钥
gpg –import nwckey.pub
gpg –list-keys
<7>用从hostA主机导入的公钥，加密hostB主机的文件file,生成file.gpg
gpg -e -r nwc file
file file.gpg
<8>复制加密文件到hostA主机
scp file.gpg HOST_A:/PATH/TO/SOMEWHERE
<9>在hostA主机解密文件
gpg -d file.gpg
gpg -o file -d file.gpg
<10>删除公钥和私钥
gpg –delete-keys nwc
gpg –delete-secret-keys nwc
第六章 ssh服务
1、SSH协议的基本概念
SSH：Secure Shell
监听在TCP协议的22号端口
SSH协议版本：
sshv1：基于CRC-32做MAC，因此不安全，建议勿用
sshv2：基于双方主机协商选择最安全的MAC实现机制，建议使用。
sshv2基于DH实现秘钥交换，基于RSA或DSA实现身份认证
客户端通过检查服务器端的主机秘钥来判定是否与其进一步通信
服务端程序为：openssh-server，配置文件为/etc/ssh/sshd_config
客户端程序为：openssh-client,配置文件为/etc/ssh/ssh_config
2、SSH服务器端的相关配置：
配置文件：/etc/ssh/sshd_config
服务脚本：/etc/rc.d/init.d/sshd
服务脚本配置文件：/etc/sysconfig/sshd
获取关于服务配置文件的帮助：man sshd_config
/etc/ssh/sshd_config配置文件中相关指令说明：(#开始的相关选项表示使用的是默认值)
Port 22 指明ssh服务监听的端口
ListenAddress IP_ADDR 表示监听的地址，可出现多次
0.0.0.0表示当前主机的所有地址
Protocol 2 表示支持的ssh协议版本，建议是2
SyslogFacility AUTHPRIV 表示日志记录的设施，要想知道该设置的具体日志放在哪里，则查看rsyslog的配置文件/etc/rsyslog.conf文件中的相关定义，此处相当于日志存在/var/log/secure日志中
LogLevel INFO 表示定义记录的日志级别
PermitRootLo