1、解决DOS攻击生产案例:根据web日志或者或者网络连接数，监控当某个IP 并发连接数或者短时内PV达到100，即调用防火墙命令封掉对应的IP，监控频 率每隔5分钟。防火墙命令为:iptables -A INPUT -s IP -j REJECT
[root@centos7 ~]# cat /data/checkddos.sh
#!/bin/bash
/usr/sbin/ss -tn | awk -F " +|:" '/ESTAB/{ip[$(NF-2)]++}END{for(i in ip)if(ip[i]>10) print i}' > /data/ddosip.txt
while read IP;do
/usr/sbin/iptables -A INPUT -s $IP -j REJECT
echo "The $IP reject" >> /data/checkddos.txt
done < /data/ddosip.txt
[root@centos7 ~]# chmod +x /data/checkddos.sh
[root@centos7 ~]# ll /data/checkddos.sh
-rwxr-xr-x. 1 root root 270 Mar 7 20:41 /data/checkddos.sh
[root@centos7 ~]# crontab -l
*/5 * * * * /data/checkddos.sh
2、描述密钥交换的过程
对称加密算法
对称加密：加密和解密使用同一个密钥
特性：
加密、解密使用同一个密钥，效率高
将原始数据分割成固定大小的块，逐个进行加密
缺陷：
密钥过多
密钥分发
数据来源无法确认
常见对称加密算法:
DES：Data Encryption Standard，56bits
3DES：
AES：Advanced (128, 192, 256bits)
Blowfish，Twofish
IDEA，RC6，CAST5
非对称加密实现加密
接收者
生成公钥/密钥对：P和S
公开公钥P，保密密钥S
发送者
使用接收者的公钥来加密消息M
将P(M)发送给接收者
接收者
使用密钥S来解密：M=S(P(M))
非对称加密实现数字签名
发送者
生成公钥/密钥对：P和S
公开公钥P，保密密钥S
使用密钥S来加密消息M
发送给接收者S(M)
接收者
使用发送者的公钥来解密M=P(S(M))
RSA和DSA
RSA：公钥加密算法是1977年由Ron Rivest、Adi Shamirh和LenAdleman在（美国麻省理工学院）开
发的，RSA取名来自开发他们三者的名字，后成立RSA数据安全有限公司。RSA是目前最有影响力的公
钥加密算法，它能够抵抗到目前为止已知的所有密码攻击，已被ISO推荐为公钥数据加密标准。RSA算
法基于一个十分简单的数论事实：将两个大素数相乘十分容易，但那时想要对其乘积进行因式分解却极
其困难，因此可以将乘积公开作为加密密钥
DSA (Digital Signature Algorithm)：1991年7月26日提交，并归属于David W. Kravitz前NSA员工，
DSA是Schnorr和ElGamal签名算法的变种，被美国NIST作为SS(DigitalSignature Standard)， DSA是基
于整数有限域离散对数难题的，其安全性与RSA相比差不多。DSA只是一种算法，和RSA不同之处在于
它不能用作加密和解密，也不能进行密钥交换，只用于签名,它比RSA要快很多
3、https的通信过程
Http属于超文本传输协议，也可以被翻译成超文本转移协议，属于应用层协议，Https不是新的应用层协议，只是在原有的协议接口替换成了SSL(Secure Socket Layer)和TLS(Transport Layer Security)协议.
对称加密
服务端给客户端的消息是密文的，只有服务器和客户端才能读懂，就可以保证数据的保密性。同时，在交换数据之前，验证一下对方的合法身份，就可以保证通信双方的安全。
服务器把数据加密后服务器必须要把加密的密钥告诉客户端，客户端才能利用对称密钥解开密文的内容。但是如果服务端将这个对称密钥以明文的方式发给Client,还是会被中间人截获，中间人也会知道对称密钥，依然无法保证通信的保密性。
对称加密+非对称加密
之前的对称加密，解密的密钥很容易被获取，非对称加密解密算法里，公钥加密的数据，有且只有唯一的私钥才能够解密，所以服务器只要把公钥发给客户端，客户端就可以用这个公钥来加密进行数据传输的对称密钥。
客户端利用公钥将对称密钥发给服务器时，即使中间人截取了信息，也无法解密，因为私钥只部署在服务器，其他任何人都没有私钥，因此，只有服务器才能够解密。服务器拿到客户端的信息并用私钥解密之后，就可以拿到加解密数据用的对称密钥，通过这个对称密钥来进行后续通信的数据加解密。
但是同样的存在一个安全问题，就是中间人自己制造了一套公钥和私钥，同样可以获取通信内容，
数字证书
避免中间人伪造自己的公钥和私钥，服务器首先生成公私钥，然后将公钥提供给相关机构(CA)。CA是Certificate Authority的缩写，也叫“证书授权中心”。CA将服务端公钥放入数字证书并将数字证书颁布给服务器（其实主要就是利用CA的私钥给Server的公钥打上标签，由于私钥无法伪造，从而可保证唯一性).
数字证书中加入了数字签名的机制，保证数字证书一定是服务端发给客户端的，即使中间人想发送一个伪造的证书，但是由于CA不会给它颁发这个证书（因为它没有经营这个网站的资质嘛，所以CA的信誉、对申请者的审核、对自己私钥的保管这3点非常重要，任何一环出问题，都会导致中间人有机可乘，从而重蹈1.2的覆辙) ，从而无能为力.
数字签名签发和校验使用的非对称密钥是CA自己的公钥和私钥，跟证书申请者（提交证书申请的公司实体）提交的公钥没有任何关系。
根CA证书都是自签名，即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的非对称密钥进行签名和验证的。根CA和多级CA的密钥对都是自签名和自认证，因为这些厂商跟浏览器和操作系统都有合作，它们的根公钥都默认装到了浏览器或者操作系统环境里。
通信过程
之前的过程基本上接近真正的通信过程，会有两次非对称加密和一次对称加密，真正的Https过程如下：
①客户端发起SSL通信，报文中包含客户端支持的SSL的指定版本，加密组件列表(加密算法及密码长度)
②服务端通过SSL通信，将SSL版本及加密算法版本中的一组发送至客户端.
③服务端发送客户端Certificate报文，报文中包含公开密钥证书.
④客户端验证证书的合法性(颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等) ，如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示;
如果证书受信任，或者用户接受了不受信的证书，客户端会生成一个Pre-master secret的随机密码串，并且通过接受到公钥加密.
⑤服务端会通过私钥解密出Pre-master sercret随机密码串，通过Pre-master sercret解密密发来的握手信息，并验证Hash是否与浏览器发来的一致.之后通过密码加密一段握手信息，发给客户端.
⑥客户端解密并计算握手信息的Hash，如果与Server发来的Hash一致，此时握手过程结束，利用对称加密算法进行加密.