1、解决DOS攻击生产案例:根据web日志或者网络连接数，监控当某个IP 并发连接数或者短时内PV达到100，即调用防火墙命令封掉对应的IP，监控频 率每隔5分钟。防火墙命令为:iptables -A INPUT -s IP -j REJECT
[root@centos7 ~]#touch deny_hosts.txt
[root@centos7 ~]#vim deny_dos.sh
#!/bin/bash
#*************************************************************
LINK=100
#while true;do 由于是5分钟检测一次，所以不需要开启循环，否则会每5分钟运行一个deny_dos.sh，导致系统重复运行。如果不添加计划，则需要开启循环。
ss -nt | awk -F"[[:space:]]+|:" '/^ESTAB/{print $(NF-2)}'|sort |uniq -c|while read count ip;do
if [ $count -gt $LINK ];then
echo $ip is deny
grep -q "$ip" deny_hosts.txt || { echo $ip >> deny_hosts.txt;iptables -A INPUT -s $ip -j REJECT; }
fi
done
#break
#done
[root@centos7 ~]#chmod +x /data/deny_dos.sh
[root@centos7 ~]#crontab -e
[root@centos7 ~]#crontab -l
*/5 * * * * /root/deny_dos.sh
2、描述密钥交换的过程
DH (Deffie-Hellman)：生成对称（会话）密钥
DH 实现过程：
A：g，p 协商生成公开的整数g，大素数p
B：g，p
A：生成隐私数据：a (a<p)，计算得出 g^a%p，发送给B
B：生成隐私数据：b,(b<p)，计算得出 g^b%p，发送给A
A：计算得出 [(g^b%p)^a]%p = g^ab%p，生成为密钥
B：计算得出 [(g^a%p)^b]%p = g^ab%p，生成为密钥
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一致，此时握手过程结束，利用对称加密算法进行加密.
4、使用awk以冒号分隔获取/etc/passwd文件第一列
awk -F: '{print $1}' /etc/passwd
