1、解決DOS攻擊生產(chǎn)案例:根據(jù)web日志或者或者網(wǎng)絡(luò)連接數(shù)，監(jiān)控當(dāng)某個(gè)IP 并發(fā)連接數(shù)或者短時(shí)內(nèi)PV達(dá)到100，即調(diào)用防火墻命令封掉對(duì)應(yīng)的IP，監(jiān)控頻 率每隔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、描述密鑰交換的過程

對(duì)稱加密算法

對(duì)稱加密：加密和解密使用同一個(gè)密鑰
特性：
加密、解密使用同一個(gè)密鑰，效率高
將原始數(shù)據(jù)分割成固定大小的塊，逐個(gè)進(jìn)行加密
缺陷：
密鑰過多
密鑰分發(fā)
數(shù)據(jù)來源無法確認(rèn)
常見對(duì)稱加密算法:
DES：Data Encryption Standard，56bits
3DES：
AES：Advanced (128, 192, 256bits)
Blowfish，Twofish
IDEA，RC6，CAST5

非對(duì)稱加密實(shí)現(xiàn)加密

接收者
生成公鑰/密鑰對(duì)：P和S
公開公鑰P，保密密鑰S
發(fā)送者
使用接收者的公鑰來加密消息M
將P(M)發(fā)送給接收者
接收者
使用密鑰S來解密：M=S(P(M))

非對(duì)稱加密實(shí)現(xiàn)數(shù)字簽名

發(fā)送者
生成公鑰/密鑰對(duì)：P和S
公開公鑰P，保密密鑰S
使用密鑰S來加密消息M
發(fā)送給接收者S(M)
接收者
使用發(fā)送者的公鑰來解密M=P(S(M))

RSA和DSA

RSA：公鑰加密算法是1977年由Ron Rivest、Adi Shamirh和LenAdleman在（美國(guó)麻省理工學(xué)院）開
發(fā)的，RSA取名來自開發(fā)他們?nèi)叩拿郑蟪闪SA數(shù)據(jù)安全有限公司。RSA是目前最有影響力的公
鑰加密算法，它能夠抵抗到目前為止已知的所有密碼攻擊，已被ISO推薦為公鑰數(shù)據(jù)加密標(biāo)準(zhǔn)。RSA算
法基于一個(gè)十分簡(jiǎn)單的數(shù)論事實(shí)：將兩個(gè)大素?cái)?shù)相乘十分容易，但那時(shí)想要對(duì)其乘積進(jìn)行因式分解卻極
其困難，因此可以將乘積公開作為加密密鑰
DSA (Digital Signature Algorithm)：1991年7月26日提交，并歸屬于David W. Kravitz前NSA員工，
DSA是Schnorr和ElGamal簽名算法的變種，被美國(guó)NIST作為SS(DigitalSignature Standard)， DSA是基
于整數(shù)有限域離散對(duì)數(shù)難題的，其安全性與RSA相比差不多。DSA只是一種算法，和RSA不同之處在于
它不能用作加密和解密，也不能進(jìn)行密鑰交換，只用于簽名,它比RSA要快很多

3、https的通信過程

Http屬于超文本傳輸協(xié)議，也可以被翻譯成超文本轉(zhuǎn)移協(xié)議，屬于應(yīng)用層協(xié)議，Https不是新的應(yīng)用層協(xié)議，只是在原有的協(xié)議接口替換成了SSL(Secure Socket Layer)和TLS(Transport Layer Security)協(xié)議.

對(duì)稱加密

服務(wù)端給客戶端的消息是密文的，只有服務(wù)器和客戶端才能讀懂，就可以保證數(shù)據(jù)的保密性。同時(shí)，在交換數(shù)據(jù)之前，驗(yàn)證一下對(duì)方的合法身份，就可以保證通信雙方的安全。

服務(wù)器把數(shù)據(jù)加密后服務(wù)器必須要把加密的密鑰告訴客戶端，客戶端才能利用對(duì)稱密鑰解開密文的內(nèi)容。但是如果服務(wù)端將這個(gè)對(duì)稱密鑰以明文的方式發(fā)給Client,還是會(huì)被中間人截獲，中間人也會(huì)知道對(duì)稱密鑰，依然無法保證通信的保密性。

對(duì)稱加密+非對(duì)稱加密

之前的對(duì)稱加密，解密的密鑰很容易被獲取，非對(duì)稱加密解密算法里，公鑰加密的數(shù)據(jù)，有且只有唯一的私鑰才能夠解密，所以服務(wù)器只要把公鑰發(fā)給客戶端，客戶端就可以用這個(gè)公鑰來加密進(jìn)行數(shù)據(jù)傳輸?shù)膶?duì)稱密鑰。

客戶端利用公鑰將對(duì)稱密鑰發(fā)給服務(wù)器時(shí)，即使中間人截取了信息，也無法解密，因?yàn)樗借€只部署在服務(wù)器，其他任何人都沒有私鑰，因此，只有服務(wù)器才能夠解密。服務(wù)器拿到客戶端的信息并用私鑰解密之后，就可以拿到加解密數(shù)據(jù)用的對(duì)稱密鑰，通過這個(gè)對(duì)稱密鑰來進(jìn)行后續(xù)通信的數(shù)據(jù)加解密。

但是同樣的存在一個(gè)安全問題，就是中間人自己制造了一套公鑰和私鑰，同樣可以獲取通信內(nèi)容，

數(shù)字證書

避免中間人偽造自己的公鑰和私鑰，服務(wù)器首先生成公私鑰，然后將公鑰提供給相關(guān)機(jī)構(gòu)(CA)。CA是Certificate Authority的縮寫，也叫“證書授權(quán)中心”。CA將服務(wù)端公鑰放入數(shù)字證書并將數(shù)字證書頒布給服務(wù)器（其實(shí)主要就是利用CA的私鑰給Server的公鑰打上標(biāo)簽，由于私鑰無法偽造，從而可保證唯一性).

數(shù)字證書中加入了數(shù)字簽名的機(jī)制，保證數(shù)字證書一定是服務(wù)端發(fā)給客戶端的，即使中間人想發(fā)送一個(gè)偽造的證書，但是由于CA不會(huì)給它頒發(fā)這個(gè)證書（因?yàn)樗鼪]有經(jīng)營(yíng)這個(gè)網(wǎng)站的資質(zhì)嘛，所以CA的信譽(yù)、對(duì)申請(qǐng)者的審核、對(duì)自己私鑰的保管這3點(diǎn)非常重要，任何一環(huán)出問題，都會(huì)導(dǎo)致中間人有機(jī)可乘，從而重蹈1.2的覆轍) ，從而無能為力.

數(shù)字簽名簽發(fā)和校驗(yàn)使用的非對(duì)稱密鑰是CA自己的公鑰和私鑰，跟證書申請(qǐng)者（提交證書申請(qǐng)的公司實(shí)體）提交的公鑰沒有任何關(guān)系。
根CA證書都是自簽名，即用自己的公鑰和私鑰完成了簽名的制作和驗(yàn)證。而證書鏈上的證書簽名都是使用上一級(jí)證書的非對(duì)稱密鑰進(jìn)行簽名和驗(yàn)證的。根CA和多級(jí)CA的密鑰對(duì)都是自簽名和自認(rèn)證，因?yàn)檫@些廠商跟瀏覽器和操作系統(tǒng)都有合作，它們的根公鑰都默認(rèn)裝到了瀏覽器或者操作系統(tǒng)環(huán)境里。

通信過程

之前的過程基本上接近真正的通信過程，會(huì)有兩次非對(duì)稱加密和一次對(duì)稱加密，真正的Https過程如下：
①客戶端發(fā)起SSL通信，報(bào)文中包含客戶端支持的SSL的指定版本，加密組件列表(加密算法及密碼長(zhǎng)度)

②服務(wù)端通過SSL通信，將SSL版本及加密算法版本中的一組發(fā)送至客戶端.

③服務(wù)端發(fā)送客戶端Certificate報(bào)文，報(bào)文中包含公開密鑰證書.

④客戶端驗(yàn)證證書的合法性(頒發(fā)證書的機(jī)構(gòu)是否合法，證書中包含的網(wǎng)站地址是否與正在訪問的地址一致等) ，如果證書受信任，則瀏覽器欄里面會(huì)顯示一個(gè)小鎖頭，否則會(huì)給出證書不受信的提示;
如果證書受信任，或者用戶接受了不受信的證書，客戶端會(huì)生成一個(gè)Pre-master secret的隨機(jī)密碼串，并且通過接受到公鑰加密.

⑤服務(wù)端會(huì)通過私鑰解密出Pre-master sercret隨機(jī)密碼串，通過Pre-master sercret解密密發(fā)來的握手信息，并驗(yàn)證Hash是否與瀏覽器發(fā)來的一致.之后通過密碼加密一段握手信息，發(fā)給客戶端.

⑥客戶端解密并計(jì)算握手信息的Hash，如果與Server發(fā)來的Hash一致，此時(shí)握手過程結(jié)束，利用對(duì)稱加密算法進(jìn)行加密.