A. 查看linux中的TCP連接數
1)統計80埠連接數
2）統計httpd協議連接數
3）、統計已連接上的，狀態為「established
4)、查出哪個IP地址連接最多,將其封了.
1、查看apache當前並發訪問數：
對比httpd.conf中MaxClients的數字差距多少。
2、查看有多少個進程數：
3、可以使用如下參數查看數據
統計httpd進程數，連個請求會啟動一個進程，使用於Apache伺服器。
表示Apache能夠處理1388個並發請求，這個值Apache可根據負載情況自動調整。
4341
netstat -an會列印系統當前網路鏈接狀態，而grep -i "80"是用來提取與80埠有關的連接的，wc -l進行連接數統計。
最終返回的數字就是當前所有80埠的請求總數。
netstat -an會列印系統當前網路鏈接狀態，而grep ESTABLISHED 提取出已建立連接的信息。 然後wc -l統計。
最終返回的數字就是當前所有80埠的已建立連接的總數。
查看Apache的並發請求數及其TCP連接狀態：
TIME_WAIT 8947 等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認
FIN_WAIT1 15 等待遠程TCP連接中斷請求，或先前的連接中斷請求的確認
FIN_WAIT2 1 從遠程TCP等待連接中斷請求
ESTABLISHED 55 代表一個打開的連接
SYN_RECV 21 再收到和發送一個連接請求後等待對方對連接請求的確認
CLOSING 2 沒有任何連接狀態
LAST_ACK 4 等待原來的發向遠程TCP的連接中斷請求的確認
TCP連接狀態詳解
LISTEN： 偵聽來自遠方的TCP埠的連接請求
SYN-SENT： 再發送連接請求後等待匹配的連接請求
SYN-RECEIVED：再收到和發送一個連接請求後等待對方對連接請求的確認
ESTABLISHED： 代表一個打開的連接
FIN-WAIT-1： 等待遠程TCP連接中斷請求，或先前的連接中斷請求的確認
FIN-WAIT-2： 從遠程TCP等待連接中斷請求
CLOSE-WAIT： 等待從本地用戶發來的連接中斷請求
CLOSING： 等待遠程TCP對連接中斷的確認
LAST-ACK： 等待原來的發向遠程TCP的連接中斷請求的確認
TIME-WAIT： 等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認
CLOSED： 沒有任何連接狀態
LAST_ACK 5
SYN_RECV 30
ESTABLISHED 1597
FIN_WAIT1 51
FIN_WAIT2 504
TIME_WAIT 1057
其中的
SYN_RECV表示正在等待處理的請求數；
ESTABLISHED表示正常數據傳輸狀態；
TIME_WAIT表示處理完畢，等待超時結束的請求數。
查看Apache並發請求數及其TCP連接狀態
查看httpd進程數（即prefork模式下Apache能夠處理的並發請求數）：
返回結果示例：
1388
表示Apache能夠處理1388個並發請求，這個值Apache可根據負載情況自動調整，我這組伺服器中每台的峰值曾達到過2002。
查看Apache的並發請求數及其TCP連接狀態：
返回結果示例：
LAST_ACK 5
SYN_RECV 30
ESTABLISHED 1597
FIN_WAIT1 51
FIN_WAIT2 504
TIME_WAIT 1057
其中的SYN_RECV表示正在等待處理的請求數；ESTABLISHED表示正常數據傳輸狀態；TIME_WAIT表示處理完畢，等待超時結束的請求數。
狀態：描述
CLOSED：無連接是活動 的或正在進行
LISTEN：伺服器在等待進入呼叫
SYN_RECV：一個連接請求已經到達，等待確認
SYN_SENT：應用已經開始，打開一個連接
ESTABLISHED：正常數據傳輸狀態
FIN_WAIT1：應用說它已經完成
FIN_WAIT2：另一邊已同意釋放
ITMED_WAIT：等待所有分組死掉
CLOSING：兩邊同時嘗試關閉
TIME_WAIT：另一邊已初始化一個釋放
LAST_ACK：等待所有分組死掉
vim /etc/sysctl.conf
編輯文件，加入以下內容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
然後執行 /sbin/sysctl -p 讓參數生效。
net.ipv4.tcp_syncookies = 1 表示開啟SYN cookies。當出現SYN等待隊列溢出時，啟用cookies來處理，可防範少量SYN攻擊，默認為0，表示關閉；
net.ipv4.tcp_tw_reuse = 1 表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連接，默認為0，表示關閉；
net.ipv4.tcp_tw_recycle = 1 表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關閉。
net.ipv4.tcp_fin_timeout 修改系統默認的 TIMEOUT 時間
客戶端與伺服器端建立TCP/IP連接後關閉SOCKET後，伺服器端連接的埠
狀態為TIME_WAIT
是不是所有執行主動關閉的socket都會進入TIME_WAIT狀態呢？
有沒有什麼情況使主動關閉的socket直接進入CLOSED狀態呢？
主動關閉的一方在發送最後一個 ack 後
就會進入 TIME_WAIT 狀態 停留2MSL（max segment lifetime）時間
這個是TCP/IP必不可少的，也就是「解決」不了的。
也就是TCP/IP設計者本來是這么設計的
主要有兩個原因
1。防止上一次連接中的包，迷路後重新出現，影響新連接
（經過2MSL，上一次連接中所有的重復包都會消失）
2。可靠的關閉TCP連接
在主動關閉方發送的最後一個 ack(fin) ，有可能丟失，這時被動方會重新發
fin, 如果這時主動方處於 CLOSED 狀態 ，就會響應 rst 而不是 ack。所以
主動方要處於 TIME_WAIT 狀態，而不能是 CLOSED 。
TIME_WAIT 並不會佔用很大資源的，除非受到攻擊。
還有，如果一方 send 或 recv 超時，就會直接進入 CLOSED 狀態
如何合理設置apache httpd的最大連接數？
手頭有一個網站在線人數增多，訪問時很慢。初步認為是伺服器資源不足了，但經反復測試，一旦連接上，不斷點擊同一個頁面上不同的鏈接，都能迅速打開，這種現象就是說明apache最大連接數已經滿了，新的訪客只能排隊等待有空閑的鏈接，而如果一旦連接上，在keeyalive 的存活時間內（KeepAliveTimeout，默認5秒）都不用重新打開連接，因此解決的方法就是加大apache的最大連接數。
1.在哪裡設置？
apache 2.24，使用默認配置（FreeBSD 默認不載入自定義MPM配置），默認最大連接數是250
在/usr/local/etc/apache22/httpd.conf中載入MPM配置（去掉前面的注釋）：
Include etc/apache22/extra/httpd-mpm.conf
可見的MPM配置在/usr/local/etc/apache22/extra/httpd-mpm.conf，但裡面根據httpd的工作模式分了很多塊，哪一部才是當前httpd的工作模式呢？可通過執行 apachectl -l 來查看：
Compiled in moles:
core.c
prefork.c
http_core.c
mod_so.c
看到prefork 字眼，因此可見當前httpd應該是工作在prefork模式，prefork模式的默認配置是：
<IfMole mpm_prefork_mole>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfMole>
2.要加到多少？
連接數理論上當然是支持越大越好，但要在伺服器的能力范圍內，這跟伺服器的CPU、內存、帶寬等都有關系。
查看當前的連接數可以用：
ps aux | grep httpd | wc -l
或：
pgrep httpd|wc -l
計算httpd佔用內存的平均數:
ps aux|grep -v grep|awk '/httpd/{sum+=$6;n++};END{print sum/n}'
由於基本都是靜態頁面，CPU消耗很低，每進程佔用內存也不算多，大約200K。
伺服器內存有2G，除去常規啟動的服務大約需要500M（保守估計），還剩1.5G可用，那麼理論上可以支持1.5 1024 1024*1024/200000 = 8053.06368
約8K個進程，支持2W人同時訪問應該是沒有問題的（能保證其中8K的人訪問很快，其他的可能需要等待1、2秒才能連上，而一旦連上就會很流暢）
控制最大連接數的MaxClients ，因此可以嘗試配置為：
<IfMole mpm_prefork_mole>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 5500
MaxClients 5000
MaxRequestsPerChild 100
</IfMole>
注意，MaxClients默認最大為250，若要超過這個值就要顯式設置ServerLimit，且ServerLimit要放在MaxClients之前，值要不小於MaxClients，不然重啟httpd時會有提示。
重啟httpd後，通過反復執行pgrep httpd|wc -l 來觀察連接數，可以看到連接數在達到MaxClients的設值後不再增加，但此時訪問網站也很流暢，那就不用貪心再設置更高的值了，不然以後如果網站訪問突增不小心就會耗光伺服器內存，可根據以後訪問壓力趨勢及內存的佔用變化再逐漸調整，直到找到一個最優的設置值。
(MaxRequestsPerChild不能設置為0，可能會因內存泄露導致伺服器崩潰）
更佳最大值計算的公式：
apache_max_process_with_good_perfermance < (total_hardware_memory / apache_memory_per_process ) * 2
apache_max_process = apache_max_process_with_good_perfermance * 1.5
附：
實時檢測HTTPD連接數：
watch -n 1 -d "pgrep httpd|wc -l"
B. 滲透測試之埠掃描
埠掃描:埠對應網路服務及應用端程序
服務端程序的漏洞通過埠攻入
發現開放的埠
更具體的攻擊面
UDP埠掃描:
如果收到ICMP埠不可達,表示埠關閉
如果沒有收到回包,則證明埠是開放的
和三層掃描IP剛好相反
Scapy埠開發掃描
命令:sr1(IP(dst="192.168.45.129")/UDP(dport=53),timeout=1,verbose=1)
nmap -sU 192.168.45.129
TCP掃描:基於連接的協議
三次握手:基於正常的三次握手發現目標是否在線
隱蔽掃描:發送不完整的數據包,不建立完整的連接,如ACK包,SYN包,不會在應用層訪問,
僵屍掃描:不和目標系統產生交互,極為隱蔽
全連接掃描:建立完整的三次握手
所有的TCP掃描方式都是基於三次握手的變化來判斷目標系統埠狀態
隱蔽掃描:發送SYN數據包,如果收到對方發來的ACK數據包,證明其在線,不與其建立完整的三次握手連接,在應用層日誌內不記錄掃描行為,十分隱蔽,網路層審計會被發現跡象
僵屍掃描:是一種極其隱蔽的掃描方式,實施條件苛刻,對於掃描發起方和被掃描方之間,必須是需要實現地址偽造,必須是僵屍機(指的是閑置系統,並且系統使用遞增的IPID)早期的win xp,win 2000都是遞增的IPID,如今的LINUX,WINDOWS都是隨機產生的IPID
1,掃描者向僵屍機發送SYN+ACY,僵屍機判斷未進行三次握手,所以返回RST包,在RST數據包內有一個IPID,值記為X,那麼掃描者就會知道被掃描者的IPID
2,掃描者向目標伺服器發送SYN數據包,並且偽裝源地址為僵屍機,如果目標伺服器埠開放,那麼就會向僵屍機發送SYN+ACK數據包,那麼僵屍機也會發送RST數據包,那麼其IPID就是X+1(因為僵屍機足夠空閑,這個就為其收到的第二個數據包)
3,掃描者再向僵屍機發送SYN+ACK,那麼僵屍機再次發送RST數據包,IPID為X+2,如果掃描者收到僵屍機的IPID為X+2,那麼就可以判斷目標伺服器埠開放
使用scapy發送數據包:首先開啟三台虛擬機,
kali虛擬機:192.168.45.128
Linux虛擬機:192.168.45.129
windows虛擬機:192.168.45.132
發送SYN數據包:
通過抓包可以查看kali給linux發送syn數據包
linux虛擬機返回Kali虛擬機SYN+ACK數據包
kali系統並不知道使用者發送了SYN包,而其莫名其妙收到了SYN+ACK數據包,便會發RST包斷開連接
也可以使用下列該命令查看收到的數據包的信息,收到對方相應的SYN+ACK數據包,scapy默認從本機的80埠往目標系統的20號埠發送,當然也可以修改
如果向目標系統發送一個 隨機埠:
通過抓包的獲得:1,kali向linux發送SYN數據包,目標埠23456,
2,Linux系統由自己的23456埠向kali系統的20號埠返回RST+ACK數據包,表示系統埠未開放會話結束
使用python腳本去進行scapy掃描
nmap做隱蔽埠掃描:
nmap -sS 192.168.45.129 -p 80,21,110,443 #掃描固定的埠
nmap -sS 192.168.45.129 -p 1-65535 --open #掃描該IP地址下1-65535埠掃描,並只顯示開放的埠
nmap -sS 192.168.45.129 -p --open #參數--open表示只顯示開放的埠
nmap -sS -iL iplist.txt -p 80
由抓包可知,nmap默認使用-sS掃描,發送SYN數據包,即nmap=nmap -sS
hping3做隱蔽埠掃描:
hping3 192.168.45.129 --scan 80 -S #參數--scan後面接單個埠或者多個埠.-S表示進行SYN掃描
hping3 192.168.45.129 --scan 80,21,25,443 -S
hping3 192.168.45.129 --scan 1-65535 -S
由抓包可得:
hping3 -c 100 -S --spoof 192.168.45.200 -p ++1 192.168.45.129
參數-c表示發送數據包的數量
參數-S表示發送SYN數據包
--spoof:偽造源地址,後面接偽造的地址,
參數-p表示掃描的埠,++1表示每次埠號加1,那麼就是發送SYN從埠1到埠100
最後面跟的是目標IP
通過抓包可以得知地址已偽造,但對於linux系統(192.168.45.129)來說,它收到了192.168.45.200的SYN數據包,那麼就會給192.168.45.200回復SYN+ACK數據包,但該地址卻是kali偽造的地址,那麼要查看目標系統哪些埠開放,必須登陸地址為kali偽造的地址即(192.168.45.200)進行抓包
hping3和nmap掃描埠的區別:1,hping3結果清晰明了
2,nmap首先對IP進行DNS反向解析,如果沒成功,那麼便會對其埠發送數據包,默認發送SYN數據包
hping3直接向目標系統的埠發送SYN數據包,並不進行DNS反向解析
全連接埠掃描:如果單獨發送SYN數據包被被過濾,那麼就使用全連接埠掃描,與目標建立三次握手連接,結果是最准確的,但容易被入侵檢測系統發現
response=sr1(IP(dst="192.168.45.129")/TCP(dport=80,flags="S"))
reply=sr1(IP(dst="192.168.45.129")/TCP(dport=80,flags="A",ack=(response[TCP].seq+1)))
抓包情況:首先kali向Linux發送SYN,Linux回復SYN+ACK給kali,但kali的系統內核不清楚kali曾給linux發送給SYN數據包,那麼kali內核莫名其妙收到SYN+ACK包,那麼便會返回RST請求斷開數據包給Linux,三次握手中斷,如今kali再給Linux發ACK確認數據包,Linux莫名其妙收到了ACK數據包,當然也會返回RST請求斷開數據包,具體抓包如下:
那麼只要kali內核在收到SYN+ACK數據包之後,不發RST數據包,那麼就可以建立完整的TCP三次握手,判斷目標主機埠是否開放
因為iptables存在於Linux內核中,通過iptables禁用內核發送RST數據包,那麼就可以實現
使用nmap進行全連接埠掃描:(如果不指定埠,那麼nmap默認會掃描1000個常用的埠,並不是1-1000號埠)
使用dmitry進行全連接埠掃描:
dmitry:功能簡單,但功能簡便
默認掃描150個最常用的埠
dmitry -p 192.168.45.129 #參數-p表示執行TCP埠掃描
dmitry -p 192.168.45.129 -o output #參數-o表示把結果保存到一個文本文檔中去
使用nc進行全連接埠掃描:
nc -nv -w 1 -z 192.168.45.129 1-100: 1-100表示掃描1-100號埠
參數-n表示不對Ip地址進行域名解析,只把其當IP來處理
參數-v表示顯示詳細信息
參數-w表示超時時間
-z表示打開用於掃描的模式
C. Kali Linux 網路掃描秘籍 第三章 埠掃描（二）
執行 TCP 埠掃描的一種方式就是執行一部分。目標埠上的 TCP 三次握手用於識別埠是否接受連接。這一類型的掃描指代隱秘掃描， SYN 掃描，或者半開放掃描。這個秘籍演示了如何使用 Scapy 執行 TCP 隱秘掃描。
為了使用 Scapy 執行 TCP 隱秘 掃描，你需要一個運行 TCP 網路服務的遠程伺服器。這個例子中我們使用 Metasploitable2 實例來執行任務。配置 Metasploitable2 的更多信息請參考第一章中的「安裝 Metasploitable2」秘籍。
此外，這一節也需要編寫腳本的更多信息，請參考第一章中的「使用文本編輯器*VIM 和 Nano）。
為了展示如何執行 SYN 掃描，我們需要使用 Scapy 構造 TCP SYN 請求，並識別和開放埠、關閉埠以及無響應系統有關的響應。為了向給定埠發送 TCP SYN 請求，我們首先需要構建請求的各個層面。我們需要構建的第一層就是 IP 層：
為了構建請求的 IP 層，我們需要將 IP 對象賦給變數 i 。通過調用 display 函數，我們可以確定對象的屬性配置。通常，發送和接受地址都設為回送地址， 127.0.0.1 。這些值可以通過修改目標地址來修改，也就是設置 i.dst 為想要掃描的地址的字元串值。通過再次調用 dislay 函數，我們看到不僅僅更新的目標地址，也自動更新了和默認介面相關的源 IP 地址。現在我們構建了請求的 IP 層，我們可以構建 TCP 層了。
為了構建請求的 TCP 層，我們使用和 IP 層相同的技巧。在這個立即中， TCP 對象賦給了 t 變數。像之前提到的那樣，默認的配置可以通過調用 display 函數來確定。這里我們可以看到目標埠的默認值為 HTTP 埠 80。對於我們的首次掃描，我們將 TCP 設置保留默認。現在我們創建了 TCP 和 IP 層，我們需要將它們疊放來構造請求。
我們可以通過以斜杠分離變數來疊放 IP 和 TCP 層。這些層面之後賦給了新的變數，它代表整個請求。我們之後可以調用 dispaly 函數來查看請求的配置。一旦構建了請求，可以將其傳遞給 sr1 函數來分析響應：
相同的請求可以不通過構建和堆疊每一層來執行。反之，我們使用單獨的一條命令，通過直接調用函數並傳遞合適的參數：
要注意當 SYN 封包發往目標 Web 伺服器的 TCP 埠 80，並且該埠上運行了 HTTP 服務時，響應中會帶有 TCP 標識 SA 的值，這表明 SYN 和 ACK 標識都被激活。這個響應表明特定的目標埠是開放的，並接受連接。如果相同類型的封包發往不接受連接的埠，會收到不同的請求。
當 SYN 請求發送給關閉的埠時，返回的響應中帶有 TCP 標識 RA，這表明 RST 和 ACK 標識為都被激活。ACK 為僅僅用於承認請求被接受，RST 為用於斷開連接，因為埠不接受連接。作為替代，如果 SYN 封包發往崩潰的系統，或者防火牆過濾了這個請求，就可能接受不到任何信息。由於這個原因，在 sr1 函數在腳本中使用時，應該始終使用 timeout 選項，來確保腳本不會在無響應的主機上掛起。
如果函數對無響應的主機使用時， timeout 值沒有指定，函數會無限繼續下去。這個演示中， timout 值為 1秒，用於使這個函數更加完備，響應的值可以用於判斷是否收到了響應：
Python 的使用使其更易於測試變數來識別 sr1 函數是否對其復制。這可以用作初步檢驗，來判斷是否接收到了任何響應。對於接收到的響應，可以執行一系列後續檢查來判斷響應表明埠開放還是關閉。這些東西可以輕易使用 Python 腳本來完成，像這樣：
在這個 Python 腳本中，用於被提示來輸入 IP 地址，腳本之後會對定義好的埠序列執行 SYN 掃描。腳本之後會得到每個連接的響應，並嘗試判斷響應的 SYN 和 ACK 標識是否激活。如果響應中出現並僅僅出現了這些標識，那麼會輸出相應的埠號碼。
運行這個腳本之後，輸出會顯示所提供的 IP 地址的系統上，前 100 個埠中的開放埠。
這一類型的掃描由發送初始 SYN 封包給遠程系統的目標 TCP 埠，並且通過返回的響應類型來判斷埠狀態來完成。如果遠程系統返回了 SYN+ACK 響應，那麼它正在准備建立連接，我們可以假設這個埠開放。如果服務返回了 RST 封包，這就表明埠關閉並且不接收連接。此外，如果沒有返回響應，掃描系統和遠程系統之間可能存在防火牆，它丟棄了請求。這也可能表明主機崩潰或者目標 IP 上沒有關聯任何系統。
Nmap 擁有可以執行遠程系統 SYN 掃描的掃描模式。這個秘籍展示了如何使用 Namp 執行 TCP 隱秘掃描。
為了使用 Nmap 執行 TCP 隱秘掃描，你需要一個運行 TCP 網路服務的遠程伺服器。這個例子中我們使用 Metasploitable2 實例來執行任務。配置 Metasploitable2 的更多信息請參考第一章中的「安裝 Metasploitable2」秘籍。
就像多數掃描需求那樣，Nmap 擁有簡化 TCP 隱秘掃描執行過程的選項。為了使用 Nmap 執行 TCP 隱秘掃描，應使用 -sS 選項，並附帶被掃描主機的 IP 地址。
在提供的例子中，特定的 IP 地址的 TCP 80 埠上執行了 TCP 隱秘掃描。和 Scapy 中的技巧相似，Nmap 監聽響應並通過分析響應中所激活的 TCP 標識來識別開放埠。我們也可以使用 Namp 執行多個特定埠的掃描，通過傳遞逗號分隔的埠號列表。
在這個例子中，目標 IP 地址的埠 21、80 和 443 上執行了 SYN 掃描。我們也可以使用 Namp 來掃描主機序列，通過標明要掃描的第一個和最後一個埠號，以破折號分隔：
在所提供的例子中，SYN 掃描在 TCP 20 到 25 埠上執行。除了擁有指定被掃描埠的能力之外。Nmap 同時擁有配置好的 1000 和常用埠的列表。我們可以執行這些埠上的掃描，通過不帶任何埠指定信息來運行 Nmap：
在上面的例子中，掃描了 Nmap 定義的 1000 個常用埠，用於識別 Metasploitable2 系統上的大量開放埠。雖然這個技巧在是被多數設備上很高效，但是也可能無法識別模糊的服務或者不常見的埠組合。如果掃描在所有可能的 TCP 埠上執行，所有可能的埠地址值都需要被掃描。定義了源埠和目標埠地址的 TCP 頭部部分是 16 位長。並且，每一位可以為 1 或者 0。因此，共有 2 ** 16 或者 65536 個可能的 TCP 埠地址。對於要掃描的全部可能的地址空間，需要提供 0 到 65535 的埠范圍，像這樣：
這個例子中，Metasploitable2 系統上所有可能的 65536 和 TCP 地址都掃描了一遍。要注意該掃描中識別的多數服務都在標準的 Nmap 1000 掃描中識別過了。這就表明在嘗試識別目標的所有可能的攻擊面的時候，完整掃描是個最佳實踐。Nmap 可以使用破折號記法，掃描主機列表上的 TCP 埠：
這個例子中，TCP 80 埠的 SYN 掃描在指定地址范圍內的所有主機上執行。雖然這個特定的掃描僅僅執行在單個埠上，Nmap 也能夠同時掃描多個系統上的多個埠和埠范圍。此外，Nmap 也能夠進行配置，基於 IP 地址的輸入列表來掃描主機。這可以通過 -iL 選項並指定文件名，如果文件存放於執行目錄中，或者文件路徑來完成。Nmap 之後會遍歷輸入列表中的每個地址，並對地址執行特定的掃描。
Nmap SYN 掃描背後的底層機制已經討論過了。但是，Nmap 擁有多線程功能，是用於執行這類掃描的快速高效的方式。
除了其它已經討論過的工具之外，Metasploit 擁有用於 SYN 掃描的輔助模塊。這個秘籍展示了如何使用 Metasploit 來執行 TCP 隱秘掃描。
為了使用 Metasploit 執行 TCP 隱秘掃描，你需要一個運行 TCP 網路服務的遠程伺服器。這個例子中我們使用 Metasploitable2 實例來執行任務。配置 Metasploitable2 的更多信息請參考第一章中的「安裝 Metasploitable2」秘籍。
Metasploit 擁有可以對特定 TCP 埠執行 SYN 掃描的輔助模塊。為了在 Kali 中啟動 Metasploit，我們在終端中執行 msfconsole 命令。
為了在 Metasploit 中執行 SYN 掃描，以輔助模塊的相對路徑調用 use 命令。一旦模塊被選中，可以執行 show options 命令來確認或修改掃描配置。這個命令會展示四列的表格，包括 name 、 current settings 、 required 和 description 。 name 列標出了每個可配置變數的名稱。 current settings 列列出了任何給定變數的現有配置。 required 列標出對於任何給定變數，值是否是必須的。 description 列描述了每個變數的功能。任何給定變數的值可以使用 set 命令，並且將新的值作為參數來修改。
在上面的例子中， RHOSTS 值修改為我們打算掃描的遠程系統的 IP 地址。地外，線程數量修改為 20。 THREADS 的值定義了在後台執行的當前任務數量。確定線程數量涉及到尋找一個平衡，既能提升任務速度，又不會過度消耗系統資源。對於多數系統，20 個線程可以足夠快，並且相當合理。 PORTS 值設為 TCP 埠 80（HTTP）。修改了必要的變數之後，可以再次使用 show options 命令來驗證。一旦所需配置驗證完畢，就可以執行掃描了。
上面的例子中，所指定的遠程主機的錢 100 個 TCP 埠上執行了 TCP SYN 掃描。雖然這個掃描識別了目標系統的多個設備，我們不能確認所有設備都識別出來，除非所有可能的埠地址都掃描到。定義來源和目標埠地址的TCP 頭部部分是 16 位長。並且，每一位可以為 1 或者 0。因此，共有 2 ** 16 或 65536 個可能的 TCP 埠地址。對於要掃描的整個地址空間，需要提供 0 到 65535 的 埠范圍，像這樣：
在這個李忠，遠程系統的所有開放埠都由掃描所有可能的 TCP 埠地址來識別。我們也可以修改掃描配置使用破折號記法來掃描地址序列。
這個例子中，TCP SYN 掃描執行在由 RHOST 變數指定的所有主機地址的 80 埠上。與之相似， RHOSTS 可以使用 CIDR 記法定義網路范圍。
Metasploit SYN 掃描輔助模塊背後的底層原理和任何其它 SYN 掃描工具一樣。對於每個被掃描的埠，會發送 SYN 封包。SYN+ACK 封包會用於識別活動服務。使用 MEtasploit 可能更加有吸引力，因為它擁有交互控制台，也因為它是個已經被多數滲透測試者熟知的工具。
除了我們之前學到了探索技巧，hping3 也可以用於執行埠掃描。這個秘籍展示了如何使用 hping3 來執行 TCP 隱秘掃描。
為了使用 hping3 執行 TCP 隱秘掃描，你需要一個運行 TCP 網路服務的遠程伺服器。這個例子中我們使用 Metasploitable2 實例來執行任務。配置 Metasploitable2 的更多信息請參考第一章中的「安裝 Metasploitable2」秘籍。
除了我們之前學到了探索技巧，hping3 也可以用於執行埠掃描。為了使用 hping3 執行埠掃描，我們需要以一個整數值使用 --scan 模式來指定要掃描的埠號。
上面的例子中，SYN 掃描執行在指定 IP 地址的 TCP 埠 80 上。 -S 選項指明了發給遠程系統的封包中激活的 TCP 標識。表格展示了接收到的響應封包中的屬性。我們可以從輸出中看到，接收到了SYN+ACK 響應，所以這表示目標主機埠 80 是開放的。此外，我們可以通過輸入夠好分隔的埠號列表來掃描多個埠，像這樣：
在上面的掃描輸出中，你可以看到，僅僅展示了接受到 SYN+ACK 標識的結果。要注意和發送到 443 埠的 SYN 請求相關的響應並沒有展示。從輸出中可以看出，我們可以通過使用 -v 選項增加詳細讀來查看所有響應。此外，可以通過傳遞第一個和最後一個埠地址值，來掃描埠范圍，像這樣：
這個例子中，100 個埠的掃描足以識別 Metasploitable2 系統上的服務。但是，為了執行 所有 TCP 埠的掃描，需要掃描所有可能的埠地址值。定義了源埠和目標埠地址的 TCP 頭部部分是 16 位長。並且，每一位可以為 1 或者 0。因此，共有 2 ** 16 或者 65536 個可能的 TCP 埠地址。對於要掃描的全部可能的地址空間，需要提供 0 到 65535 的埠范圍，像這樣：
hping3 不用於一些已經提到的其它工具，因為它並沒有 SYN 掃描模式。但是反之，它允許你指定 TCP 封包發送時的激活的 TCP 標識。在秘籍中的例子中， -S 選項讓 hping3 使用 TCP 封包的 SYN 標識。
在多數掃描工具當中，TCP 連接掃描比 SYN 掃描更加容易。這是因為 TCP 連接掃描並不需要為了生成和注入 SYN 掃描中使用的原始封包而提升許可權。Scapy 是它的一大例外。Scapy 實際上非常難以執行完全的 TCP 三次握手，也不實用。但是，出於更好理解這個過程的目的，我們來看看如何使用 Scapy 執行連接掃描。
為了使用 Scapy 執行全連接掃描，你需要一個運行 UDP 網路服務的遠程伺服器。這個例子中我們使用 Metasploitable2 實例來執行任務。配置 Metasploitable2 的更多信息請參考第一章中的「安裝 Metasploitable2」秘籍。
此外，這一節也需要編寫腳本的更多信息，請參考第一章中的「使用文本編輯器*VIM 和 Nano）。
Scapy 中很難執行全連接掃描，因為系統內核不知道你在 Scapy 中發送的請求，並且嘗試阻止你和遠程系統建立完整的三次握手。你可以在 Wireshark 或 tcpmp 中，通過發送 SYN 請求並嗅探相關流量來看到這個過程。當你接收到來自遠程系統的 SYN+ACK 響應時，Linux 內核會攔截它，並將其看做來源不明的響應，因為它不知道你在 Scapy 中 發送的請求。並且系統會自動使用 TCP RST 封包來回復，因此會斷開握手過程。考慮下面的例子：
這個 Python 腳本的例子可以用做 POC 來演系統破壞三次握手的問題。這個腳本假設你將帶有開放埠活動系統作為目標。因此，假設 SYN+ACK 回復會作為初始 SYN 請求的響應而返回。即使發送了最後的 ACK 回復，完成了握手，RST 封包也會阻止連接建立。我們可以通過觀察封包發送和接受來進一步演示。
在這個 Python 腳本中，每個發送的封包都在傳輸之前展示，並且每個收到的封包都在到達之後展示。在檢驗每個封包所激活的 TCP 標識的過程中，我們可以看到，三次握手失敗了。考慮由腳本生成的下列輸出：
在腳本的輸出中，我們看到了四個封包。第一個封包是發送的 SYN 請求，第二個封包時接收到的 SYN+ACK 回復，第三個封包時發送的 ACK 回復，之後接收到了 RST 封包，它是最後的 ACK 回復的響應。最後一個封包表明，在建立連接時出現了問題。Scapy 中可能能夠建立完成的三次握手，但是它需要對本地 IP 表做一些調整。尤其是，如果你去掉發往遠程系統的 TSR 封包，你就可以完成握手。通過使用 IP 表建立過濾機制，我們可以去掉 RST 封包來完成三次握手，而不會干擾到整個系統（這個配置出於功能上的原理並不推薦）。為了展示完整三次握手的成功建立，我們使用 Netcat 建立 TCP 監聽服務。之後嘗試使用 Scapy 連接開放的埠。
這個例子中，我們在 TCP 埠 4444 開啟了監聽服務。我們之後可以修改之前的腳本來嘗試連接 埠 4444 上的 Netcat 監聽服務。
這個腳本中，SYN 請求發送給了監聽埠。收到 SYN+ACK 回復之後，會發送 ACK回復。為了驗證連接嘗試被系統生成的 RST 封包打斷，這個腳本應該在 Wireshark 啟動之後執行，來捕獲請求蓄力。我們使用 Wireshark 的過濾器來隔離連接嘗試序列。所使用的過濾器是 tcp && (ip.src == 172.16.36.135 || ip.dst == 172.16.36.135) 。過濾器僅僅用於展示來自或發往被掃描系統的 TCP 流量。像這樣：
既然我們已經精確定位了問題。我們可以建立過濾器，讓我們能夠去除系統生成的 RST 封包。這個過濾器可以通過修改本地 IP 表來建立：
在這個例子中，本地 IP 表的修改去除了所有發往被掃描主機的目標地址的 TCP RST 封包。 list 選項隨後可以用於查看 IP 表的條目，以及驗證配置已經做了修改。為了執行另一次連接嘗試，我們需要確保 Natcat 仍舊監聽目標的 4444 埠，像這樣：
和之前相同的 Python 腳本可以再次使用，同時 WIreshark 會捕獲後台的流量。使用之前討論的顯示過濾器，我們可以輕易專注於所需的流量。要注意三次握手的所有步驟現在都可以完成，而不會收到系統生成的 RST 封包的打斷，像這樣：
此外，如果我們看一看運行在目標系統的 Netcat 服務，我們可以注意到，已經建立了連接。這是用於確認成功建立連接的進一步的證據。這可以在下面的輸出中看到：
雖然這個練習對理解和解決 TCP 連接的問題十分有幫助，恢復 IP 表的條目也十分重要。RST 封包 是 TCP 通信的重要組成部分，去除這些響應會影響正常的通信功能。洗嘜按的命令可以用於刷新我們的 iptable 規則，並驗證刷新成功：
就像例子中展示的那樣， flush 選項應該用於清楚 IP 表的條目。我們可以多次使用 list 選項來驗證 IP 表的條目已經移除了。
執行 TCP 連接掃描的同居通過執行完整的三次握手，和遠程系統的所有被掃描埠建立連接。埠的狀態取決於連接是否成功建立。如果連接建立，埠被認為是開放的，如果連接不能成功建立，埠被認為是關閉的。
D. 暢談linux下TCP（上）
tcp 協議 是互聯網中最常用的協議 ， 開發人員基本上天天和它打交道，對它進行深入了解。 可以幫助我們排查定位bug和進行程序優化。下面我將就TCP幾個點做深入的探討
客戶端：收到 ack 後 分配連接資源。 發送數據
伺服器 : 收到 syn 後立即 分配連接資源
客戶端：收到ACK， 立即分配資源
伺服器：收到ACK， 立即分配資源
既然三次握手也不是100%可靠， 那四次，五次，六次。。。呢? 其實都一樣，不管多少次都有丟包問題。
client 只發送一個 SYN， server 分配一個tcb， 放入syn隊列中。 這時候連接叫 半連接 狀態；如果server 收不到 client 的ACK， 會不停重試 發送 ACK-SYN 給client 。重試間隔 為 2 的 N 次方 疊加（2^0 , 2^1, 2^2 ....）；直至超時才釋放syn隊列中的這個 TCB;
在半連接狀態下， 一方面會佔用隊列配額資源，另一方面佔用內存資源。我們應該讓半連接狀態存在時間盡可能的小
當client 向一個未打開的埠發起連接請求時，會收到一個RST回復包
當listen 的 backlog 和 somaxconn 都設置了得時候， 取兩者min值
Recv-Q 是accept 隊列當前個數， Send-Q 設置最大值
這種SYN洪水攻擊是一種常見攻擊方式，就是利用半連接隊列特性，占滿syn 隊列的 資源，導致 client無法連接上。
解決方案:
為什麼不像握手那樣合並成三次揮手? 因為和剛開始連接情況，連接是大家都從0開始， 關閉時有歷史包袱的。server(被動關閉方) 收到 client(主動關閉方) 的關閉請求FIN包。 這時候可能還有未發送完的數據，不能丟棄。 所以需要分開。事實可能是這樣
當然，在沒有待發數據，並且允許 Delay ACK 情況下， FIN-ACK合並還是非常常見的事情，這是三次揮手是可以的。
同上
CLOSE_WAIT 是被動關閉方才有的狀態 。
被動關閉方 [收到 FIN 包 發送 ACK 應答] 到 [發送FIN， 收到ACK ] 期間的狀態為 CLOSE_WAIT， 這個狀態仍然能發送數據。 我們叫做 半關閉 , 下面用個例子來分析:
這個是我實際生產環境碰到的一個問題，長連接會話場景，server端收到client的rpc call 請求1，處理發現請求包有問題，就強制關閉結束這次會話， 但是 因為client 發送 第二次請求之前，並沒有去調用recv，所以並不知道 這個連接被server關閉， 繼續發送 請求2 ， 此時是半連接，能夠成功發送到對端機器，但是recv結果後，遇到連接已經關閉錯誤。
如果 client 和 server 恰好同時發起關閉連接。這種情況下，兩邊都是主動連接，都會進入 TIME_WAIT狀態
1、 被動關閉方在LAST_ACK狀態(已經發送FIN)，等待主動關閉方的ACK應答，但是 ACK丟掉， 主動方並不知道，以為成功關閉。因為沒有TIME_WAIT等待時間，可以立即創建新的連接， 新的連接發送SYN到前面那個未關閉的被動方，被動方認為是收到錯誤指令，會發送RST。導致創建連接失敗。
2、 主動關閉方斷開連接，如果沒有TIME_WAIT等待時間，可以馬上建立一個新的連接，但是前一個已經斷開連接的，延遲到達的數據包。 被新建的連接接收，如果剛好seq 和 ack欄位 都正確, seq在滑動窗口范圍內(只能說機率非常小，但是還是有可能會發生)，會被當成正確數據包接收，導致數據串包。 如果不在window范圍內，則沒有影響( 發送一個確認報文（ack 欄位為期望ack的序列號，seq為當前發送序列號），狀態變保持原樣)
TIME_WAIT 問題比較比較常見，特別是CGI機器，並發量高，大量連接後段服務的tcp短連接。因此也衍生出了多種手段解決。雖然每種方法解決不是那麼完美，但是帶來的好處一般多於壞處。還是在日常工作中會使用。
1、改短TIME_WAIT 等待時間
這個是第一個想到的解決辦法，既然等待時間太長，就改成時間短，快速回收埠。但是實際情況往往不樂觀，對於並發的機器，你改多短才能保證回收速度呢，有時候幾秒鍾就幾萬個連接。太短的話，就會有前面兩種問題小概率發生。
2、禁止Socket lingering
這種情況下關閉連接，會直接拋棄緩沖區中待發送的數據，會發送一個RST給對端，相當於直接拋棄TIME_WAIT， 進入CLOSE狀態。同樣因為取消了 TIME_WAIT 狀態，會有前面兩種問題小概率發生。
3、tcp_tw_reuse
net.ipv4.tcp_tw_reuse選項是 從 TIME_WAIT 狀態的隊列中，選取條件：1、remote 的 ip 和埠相同， 2、選取一個時間戳小於當前時間戳； 用來解決埠不足的尷尬。
現在埠可以復用了，看看如何面對前面TIME_WAIT 那兩種問題。 我們仔細回顧用一下前面兩種問題。 都是在新建連接中收到老連接的包導致的問題 ， 那麼如果我能在新連接中識別出此包為非法包，是不是就可以丟掉這些無用包，解決問題呢。
需要實現這些功能，需要擴展一下tcp 包頭。 增加 時間戳欄位。 發送者 在每次發送的時候。 在tcp包頭裡面帶上發送時候的時間戳。 當接收者接收的時候，在ACK應答中除了TCP包頭中帶自己此時發送的時間戳，並且把收到的時間戳附加在後面。也就是說ACK包中有兩個時間戳欄位。結構如下:
那我們接下來一個個分析tcp_tw_reuse是如何解決TIME_WAIT的兩個問題的
4、tcp_tw_recycle
tcp_tw_recycle 也是藉助 timestamp機制。顧名思義， tcp_tw_reuse 是復用 埠，並不會減少 TIME-WAIT 數量。你去查詢機器上TIME-WAIT 數量，還是 幾千幾萬個，這點對有強迫症的同學感覺很不舒服。tcp_tw_recycle 是 提前 回收 TIME-WAIT資源。會減少 機器上 TIME-WAIT 數量。
tcp_tw_recycle 工作原理是。