常用協定及網路相關整理

# 常用協定及網路相關整理 ###### tags: `CEH`、`learning` ## OSI vs TCP/IP | | OSI(7層) | TCP/IP(4層) | 用途 | ex | Protocol | |---| :-----------: | :--------: | :--------: | :-------: | :--:| | 7 | Application應用層 | Application應用層 | 處理應用程式，提供使用者網路應用服務 | 各種應用程式 | HTTP.DHCP.FTP... | | 6 | Presentation展示層 | (同上) | 轉換資料的表達方式，以及處理資料的加解密 | 將ASCII編碼轉成應用層可以使用的資料，或是處理圖片檔或音訊檔 | ASCII. MIME | | 5 | Session會議層 | (同上) | 負責建立網路連線，當資料傳輸結束後中斷連線 |SOCKS. NetBIOS | | 4 | Transport傳輸層 | Transport傳輸層 | 負責電腦整體的資料傳輸及控制(流量管制與錯誤控制)，將一個較大的資料切割成多個適合傳輸的資料 | TCP協定在傳輸資料內加入驗證碼，在對方收到之後回傳ACK，確保資料的傳輸完整性 | TCP.UDP SSL.TLS | | 3 | Network網路層 | Internet網路層 | 定義路由及定址，讓資料能在網路間傳遞 | IP協定在資料傳輸時將IP位址加入傳輸資料內，形成封包 | IP.ICMP | | 2 | Data Link資料鏈結層 | Link鏈結層 | 在網路之間建立邏輯連結，並處理流量控制及錯誤偵測，將實體層的的數位訊號封裝成Data Frame，包含MAC address | 網路卡.Switch| MAC. ARP | | 1 | Physical實體層 | (同上) | 傳遞電子訊號(0/1)形成網路 | 網路線.網路卡.Hub | Ethernet, Wifi | ![](https://i.imgur.com/5E24DVq.png) ## IP (Internet Protocol) - OSI Layer3 (網路層)協定 - 根據src & dst的address來傳送資料 - 定義了 - 定址方法 (IPv4、IPv6) - data的封裝結構(封包結構) ![](https://i.imgur.com/w9dU9Nn.png =400x) - Verison (4bit): IPv4 or IPv6 - IHL(Internet Header Length, 4bit): IP封包header的長度(#個byte)，預設值為5 - Type of Service (8bit, PPPDTRUU): - P(Precedence): IP封包的優先權 - D(Delay): 0(一般延遲). 1(低延遲) - T(Throughput): 1(高傳送量) - R(Reliability): 1(高可靠度) - U(Unuse) - Ttotal Length(16bit): 包含header及data，最大封包65535 - Identification: 如果封包有切割(太大需切割)，同一筆資料切割的封包識別碼相同 - Flags(3bit, 0DM): - D(Don't Fragment): 1(不可分段) - M(More Fragment): 0(這是最後一個分段). 1(不是最後分段) - Fragment Offset : 目前分段在原始資料中的位置(一個單位8bit) - 最大65535bit的資料，以8bit為一個基本offset，故最大值為65535/8 = 8191 - 預設值為0 - TTL(8bit, 0-255) : 表示該資料在網路上的存活時間，封包每經過一個router，TTL減一，若發現TTL=0，該packet會被Router drop - Protocol Number (8bit): 封包乘載的資料是屬於哪個通訊協定(IP、ICMP、TCP、UDP, etc) | Protocol | Protocol No. | |:--------:|:--------:| | ICMP | 1 | | IP | 4 | | TCP | 6 | | UDP | 17| - Header Checksum (8bit): 錯誤檢查 - 把IP header以每2byte為單位(除去Checksum欄位)加總起來(重複直到結果為2byte)，之後取補數即為Checksum - ex. IP header如下 `45 00 00 30` `cc 61 40 00` `40 06``4c 02` (checksum) `0a 05 04 6b` `0a 08 09 ed` 1. 計算`0x4500 + 0x0030 + 0xcc61 + 0x4000 + 0x4006 + 0x0a05 + 0x046b + 0x0a08 + 0x09ed = 0x1b3fc ` 2. 重複2byte為單位加總，把進位的部分加上 = `0x1 + 0xb3fc = 0xb3fd` 3. 取補數 `0xb3fd = 0b1011001111111101` $\Rightarrow$ `0b0100110000000010 = 0x4c02` - Option: 長度可變，提供其他選擇性服務(例如指定封包傳送路徑) - Padding: 因為IP header一定是32bit的整數倍，若Option不足32bit的整數倍，用來補齊 $\Rightarrow$ IP header若不含Option就是20byte ## ICMP (Internet Control Message Protocol) - OSI Layer3(網路層) Protocol - 目的 - 解析網路封包 - 分析路由 - ICMP基於IP協定，透過送出ICMP封包，利用回傳的Error Message來判斷網路狀態 - router再轉發ICMP封包時，會把IP Header的TTL減一 - 若TTL=0，會回傳`ICMP time exceeded`的error message - 工具 - `traceroute`利用TTL - `ping`利用`ICMP echo request`及`ICMP echo reply` - 測試網路連線是否正常。 - 向目的端設備發送一個ICMP echo@要求封包(request)，並且等待目的端回傳封包(reply)。 - 回報ping封包(reply)到目的端設備來回所需的最少時間、最大時間與平均時間，可以用來確認到指定設備之間網路路徑的可靠程度。 - 基於IP協定實作 - Message Type(3bit): 代表該封包所控制的訊息功能(共13種) - 每種Type的Header也會長的不太一樣 | Msg Type | 功能 | | :--------: | -------- | | 0 | Echo Reply | | 3 | Destination Unreachable (目的地無法到達) | | 4 | Source Quench (來源抑制) | | 5 | Redirect (改變來源路徑)| | 8 | Echo Request | |9|Router Advertisement (路由器宣傳)| |10|Router Solicaitation (路由器懇請) | |11|Time Exceeded for a Datagram (溢時傳輸)| |12|Parameter Problem on Datagram (參數問題)| |13|Timestamp Request| |14|Timestamp Reply| |15|Information Request (停用)| |16|Information Reply (停用)| |17|Address Mask Request| |18|Address Mask Reply | - **0** Echo Reply & **8** Echo Request - 當被探勘的主機收到Echo Request封包，會回傳ICMP ECHO Reply，告知發出request的主機該路徑是可以到達的 - Header: reply會將收到request的Identifier的值放在自己Sequence Number的欄位內 - **3** Destination Unreachable - 當路徑中的某個Router發現某個IP封包無法在往下傳送，會傳一個封包給發送原始封包者，並丟棄該封包 - header: - Code(3bit): 註明無法到達的原因 0. Network Unreachable : 找不到適當路徑 (因為Router) 1. Host Unreachable : 找不到適當路徑到目標主機 2. Protocol Unreachable : 封包格式不符合IP封包格式 3. Port Unreachable : 目標主機的指定port沒有開 4. Fragmentation Needed and DF set (資料須分割且設定不可分割位元) : Router收到一個需要分段的封包(MTU太大)，但該封包上有設定DF(Disable Fragment) 6. Source Route Failed (來源路徑選擇失敗) 7. Destination Network Unknown (無法識別目的地網路) 8. Destination Host Unknown (無法識別目的主機) 9. Source Host Isolated (來源主機被隔離) 10. Communication with Destination Network Administratively Prohibited (管理上禁止和目的地網路通訊) 11. Communication with Destination Host Administratively Prohibited (管理上禁止和目的地主機通訊) 12. Network Unreachable for Type of Service (無法到達此型態的網路服務) 13. Host Unreachable for Type of Service (無法到達此型態的主機服務) 14. Communication Administratively Prohibited (網路流量被禁止) - **4** Source Quench (來源抑制) - 若Router/Gateway的receive buffer已滿，此時會drop掉接下來收到的封包，並回傳Source Quench封包給該封包的來源主機 - **5** Redirection - 當Router發現經由他轉送的目標主機，有其他路徑可以更快到達時，會傳Redirect封包通知來源主機請他改變傳輸路徑 - **11** Time Exceeded (逾時傳輸) - 當Router/Gateway發現某個IP封包的TTL=0時，會發送一個Time Exceeded封包給來源主機，並drop掉該主機 - **12** Parameter Problem - 當Router/Gateway發現IP封包中的某些參數值不正確而無法處理該封包時，會傳Parameter Problem封包給來源封包 - Header: Pointer指向有問題的offset - **13** Timestamp Request & **14** Timestamp Reply - 詢問某部主機的系統時間 - **17** Address Mask Request & **18** Address Mask Reply - 要求獲得/回應某一個subnet的Mask - [ref](http://www.tsnien.idv.tw/Internet_WebBook/chap5/5-4%20ICMP%20%E9%80%9A%E8%A8%8A%E5%8D%94%E5%AE%9A.html) - 要補圖ㄚㄚㄚ ## ARP (Address Resolution Protocol) - OSI Layer2 (連結層) - 詢問某IP是屬於哪個主機 - 因為乙太網路(規定實體層，是大部分區域網路(LAN, Local Area Network)的標準)中，規定ethernet封包的src address及dst address必須為48bit的MAC Address，但TCP/IP網路上又是使用32bit的IP address，因此藉由ARP來達成兩種封包的地址轉換 - 以IP位址查詢相應的MAC Address 1. 主機A(163.15.2.1)想要傳送訊息給163.15.2.4，他會發出ARP request，廣播到所屬網路區段內 2. 163.15.2.4主機收到後(其他主機收到會自己drop掉)，會發送ARP reply(包含自己的MAC Address)給主機A 3. 主機A會將詢問過的IP及收到的MAC Address，存到自己的ARP Cache中 - RARP (Reverse ARP): 用MAC Address反向查IP Address，現在大多由DHCP or Bootp協定取代 ## TCP (Transport Control Protocol) - OSI Layer4 (傳輸層)協定 - End-to-End，每個端點可以透過彼此溝通確保資料傳輸的正確性 - TCP封包格式 ![](https://i.imgur.com/6P2INvp.png) - Source/Destination Port: 來源/目的port號，範圍為0-65535 - 0-1023(固定配置埠Static Allocated Port): 配置給固定的應用程式或常用的server | Port Number | Protocol | 服務名稱 | | :--------: | :--------: | :--------: | | 7 | TCP/UDP | 回應測試(Ping) | |21 | TCP | FTP | |22|TCP|SSH, SCP| | 23 | TCP| Telnet(不安全) | |25|TCP|SMTP| |53 |TCP/UDP| DNS| |70| TCP|Gopher| |80|TCP|HTTP| |443|TCP|HTTPS| - 1024及以上(動態配置埠Dynamic Allocated Port): 需要時才分配，或由使用者指定 - Sequence Number: 該封包的順序編號(避免順序亂掉) - Acknowledge Number: Reply封包的確認號碼，也是期望發出端下次發送封包的sequence number，亦表示該號碼之前的封包都正常接收 - Data Offset: Data的起始位置，因為TCP封包的Option長度不固定，因此每個封包的data起始位置不同 - Code bits: 6bits(`U A P R S F`), 控制訊息傳遞 :::success - FIN.RST.ACK.SYN: 連線管控 - URG.PSH: 插隊用,以降低在路上丟失的風險 - PSH: 等待正在處理的封包處理完 - URG: 直接drop掉正在處理的封包,TCP會用PR機制通知 ::: 1. URG(Urgent): 表示該封包為緊急資料，此時Urgent Pointer欄位才會有效 2. ACK(Acknowledge): 表示該封包有回應功能，會確認Acknowledge Number欄位中的號碼。 3. PSH(Push): 請求對方立刻傳送Send Buffer中的封包 4. RST(Reset):　強迫對方結束連線，且發送方已斷線 5. SYN(Synchronous):　通知對方發送方要求建立TCP連線 6. FIN(Finish): 通知對方資料已傳送完畢，是否同意斷線，但此時發送方依然在連線中等待對方回應 - Window: 控制封包流量(單位為byte)，告知對方目前本身還有多少Receive Buffer可以接收封包。如果`Window=0`，表示Receive Buffer已滿。 - Checksum: 16bits，接收方可以依Checksum欄位中的值來確定所收封包是否正確 - Checksum計算方式(與IP Checksum類似，但還需要驗證IP header中的欄位) 1. 先產生一個Pseudo Header (由下列組成) 1. Source IP: 4byte in IP header 2. Destination IP: 4byte in IP Header 3. Protocol: 1byte in IP Header 4. TCP Header Length 2. 將Pseudo Header + TCP header 每2byte為單位加總起來(除了Checksum欄位)，重複直到只剩2byte，取補數即為結果 :::info - ex. IP header 如下 `45 00 00 30` `cc 61 40 00` `40 06``4c 02` (ip checksum) `0a 05 04 6b` `0a 08 09 ed` - TCP header如下 `f3 dd 0c d3` `d9 fa f8 26` `00 00 00 00` `70 02 ff ff` `8e e9` (tcp checksum) `00 00` `02 04 05 b4` `04 02 00 00` - Source IP = 0a 05 04 6b (#13byte in IP header) Destination IP = 0a 08 09 ed (#15byte in IP header) Protocol = 06 (#10byte in IP header) TCP header Length = 28byte = 0x1c 1. Pseudo Header = `0x0a05 + 0x046b + 0x0a08 + 0x09ed + 0x06 + 0x001c = 0x2287` 2. 再加上TCP header中除了checksum的欄位值 `0x2287 + 0xf3dd + 0x0cd3 + 0xd9fa + 0xf826 + 0x0000 + 0x0000 + 0x7002 + 0xffff + 0x0000 + 0x0204 + 0x05b4 + 0x0402 + 0x0000 = 0x47112` 3. 重複加到2byte $\rightarrow$`0x4 + 0x7112 = 0x7116` 4. 取補數 `0x7116 = 0b0111000100010110` $\Rightarrow$ `0b1000111011101001 = 0x8ee9` ::: - Urgent Pointer: 當URG bit設定時，Urgent Pointer中的值代表緊急資料在data區的offset - Options: 目前該欄位只用於表示接收端能夠接收最大資料區段的大小，若沒有使用該欄位，則資料區段大小不限 - Padding: 因為Option長度不定，但header須為32bit的整數倍，因此用來補齊 - TCP三方交握 (3-Way Handshake): TCP在傳送資料之前須要先建立連線 1. Server和Client皆為`CLOSED`狀態，但若某個服務有開，Server會主動監聽該服務的port 2. Client向Server發送SYN封包(`Code=000010`)，要求建立新連線 - 此時會設定`Sequence Number`為一個亂數`m` - Client處於`SYN_SENT`狀態 4. Server收到之後，會回傳SYN+ACK封包(Code=010010) - 設定`Sequence Number` = 亂數`n` - 設定`Acknowledge Number` = `m+1` - Server進入`SYN_RCVD`狀態 5. Client收到SYN+ACK之後，代表Server同意建立連線，需再次傳送ACK封包(`Code=010000`)表示確認收到資料 - 設定`Sequence Number` = `m+1` - 設定`Acknowledge Number` = `n+1` - Client進入`ESTABLISHED`狀態 6. Server收到ACK封包(`Code=010000`) - Server進入`ESTABLISHED`狀態 - TCP四次揮手 (4-way handshake): TCP結束連線 1. Client及Server皆為`ESTABLISHED`狀態 2. Client傳輸完資料後，向Server發送FIN封包(`Code=000001`)，表示資料傳輸完畢 - 設定`Sequence Number` = 一個亂數`x` 3. Server收到FIN封包，告知應用層要釋放TCP連線，然後向Client傳送ACK封包(`Code=010000`) - 設定`Sequence Number` = 亂數`y` - 設定`Acknowledge Number` = `x+1` - Server進入`CLOSE_WAIT`狀態 (此時Server不會再收Client的資料，但依然可以向Client傳資料) 4. Client收到ACK封包之後會進入`FIN_WAIT_2`狀態，等待Server傳完資料再次確認 5. 當Server傳完所有資料之後，會向Client發送FIN+ACK封包(`Code=010001`) - 設定`Sequence Number` = 亂數`z` - 設定`Acknowledge Number` = `x+1` - Server進入`LAST_ACK`狀態等待Client確認 6. Client收到FIN+ACK封包，最後向Server傳送ACK封包(`Code=010000`) - 設定`Sequence Number` = `x+1` - 設定`Acknowledge Number` = `z+1` - Client進入`TIME_WAIT`狀態，此狀態會持續一段時間(Timer設定的時間)，之後Client才會進入`CLOSED`狀態 7. Server收到ACK封包，進入`CLOSED`狀態 - [ref](https://www.it145.com/9/14306.html) ## UDP - 相較於TCP， UDP連線前不需要建立連線，也就是說Client隨時都可以向Server傳封包。 - 優點: 傳輸速度快、可以即時反應訊息 - 缺點: 資料可能lost、重複傳遞、未依序到達 - 適合用在對資料正確性要求不高的環境(視訊) - UDP封包: - 傳輸層封包最大長度為65536bytes, 因此扣除IP header的20bytes及UDP header的20bytes，理論上UDP傳輸的資料長度最大可以為65496bytes - 但為了避免IP封包在傳輸過程中再次被segment，連結層會設定最大傳輸單位(MTU, Maximum Transmission Unit), - 以Ethernet為例，MTU=1518byte - 即data frame的大小為1518byte (包含header的14byte及校驗用和FCS的最後4byte) - 也就是說IP協定(網路層)要處理的資料大小為1500byte(包含IP header 20bytes) - 故UDP封包最大應為1480byte (包含20byte的UDP header)，故UDP傳送的資料大小須小於1460byte，就可以避免再次被segment http://www.tsnien.idv.tw/Internet_WebBook/chap7/7-5%20UDP%20%E9%80%9A%E8%A8%8A%E5%8D%94%E5%AE%9A.html - UDP封包格式 - Source/Destination Port (各16bit) - Length: 封包所承載的Data大小(包含header) (16bit) - Checksum: 檢查錯誤用，若檢查錯誤即丟棄。 - 有些環境為了提高效率，Checksum欄位會直接設成0，不使用該功能 - 檢查方式與TCP checksum相同 ## HTTP (Hyper Text Transport Protocol)/ HTTPS - HTTP是用來傳輸hyper text文件(ex.html文件)的應用層協定(Layer 7)，以Client-Serve模式運作 - 瀏覽器作為Client端(稱做user-agent)，通過URL向HTTP Server(即Web Server,預設為80port)發送請求 - Web Server收到之後，會向Client返回一個status code (ex. `HTTP/1.1 200 OK`) - Web Server: Apache Server, IIS Server (Internet Information Service) - 藉由TCP作為資料傳輸的方式(但要用UDP也可以) - Client送出請求，經過TCP 3way Handshake之後就可以透過TCP傳遞給Server - 然而這個傳輸過程，封包都是明文傳輸 :arrow_right: HTTPS (HTTP Secure, HTTP + SSL/TLS) - HTTP無連接 - 每次連接只處理一個request, Server處理完Client的request並收到reply之後，馬上段開連結 - 但若每次request都需要進行一次tcp三方交握，非常浪費資源 :arrow_right: Keep-Alive功能 - Keep-Alive功能使Client到Server的連接持續有效，可以避免需要重新建立連線 - 大部分的Web Server(ex. IIS, Apache)都支持HTTP Keep-Alive - 但缺點是會影響性能，因為本來可以釋放的資源被占用 - HTTP無狀態(Stateless) - 即兩個HTTP request之間，是沒有Context(上下文)關係的，也就是說，HTTP Server不會記住這個Client是否曾經有送過請求 (即使Keep-Alive功能也不影響這個狀態) - 優: 避免不必要的連接占用 / 缺: 每次請求會傳輸大量重複的內容 - Sol :arrow_right: 1. Cookie - 在client端紀錄登錄訊息到下次與server的session - ex. 購物車 3. Session - 在server端根據需求設置session，並將sessionid傳給client保存 (存在記憶體中，無過期時間的cookie)，直到瀏覽器關閉後這個cookie就會被清掉。 - HTTP/1.1協定中定義了8種method，以不同方式操作指定的資源 `HTTP Server至少應該實作GET即HEAD method, 其他都是optional` 1. GET - 向指定資源發出"顯示請求" - 用於讀取資料 - GET會被網路爬蟲隨意存取 - 瀏覽器利用在url後面帶上querystring來送出GET請求 - ex. `https://www.google.com/search?q=dog` 3. HEAD - 與GET大致類似，但server reply時不得傳輸message body (只要獲取request的header) 5. POST - 將要處理的資料交給指定的資源 - 把參數放在request的message body中 - ex. 登入會員, 送出表單 7. PUT - 替換目標資源(更新) - vs PATCH - ex. 某人更新基本資料，只有要更新姓名 - PUT會把其他的(ex. 性別.大頭照...)也更新一遍 - PATCH就只會更新姓名，沒動到的都不會更新 - 若要更新的資源不存在 - PATCH會創建新的資源 - PUT只對已存在的資源進行更新 9. DELETE - 刪除指定的資源 11. TRACE - Client發出request之後，這個封包可能需要穿過各種設備(ex. 防火牆、Proxy、Gateway, etc)，每個node都可能會修改原始HTTP request - TRACE允許client查看server收到的最終request長甚麼樣子 ![](https://i.imgur.com/vg1wGbk.png) 13. OPTIONS - 請求Web Server告知其支援的各種功能 - 若Options請求的URI是*，代表請求整個server支援的功能 - ex. `OPTIONS * HTTP/1.1` - 若URI是個實際資源位址，即請求查詢特定資源的可用功能 - ex. `OPTIONS https://meow.com/index.html HTTP/1.1` - 如果成功，Server會return一個包含各種header的200 OK回應，每個header描述server所支援的功能 - ex. `Allow: GET, HEAD, PUT` 15. CONNECT - 要求啟動一個雙向通訊，通常用來建立tunnel - ex. 存取使用SSL - 將server作為proxy, 讓server代替client去訪問其他網頁，再將data返回給client - 若成功，Server會回應`HTTP/1.1 200 Connection Established` (不是200 OK) - HTTP Status Code - 1xx : 等我一下 (請求已被接受，但需要等待處理) - ex. 100 Continue - 2xx : 成功惹 - ex. 200 OK - 3xx : 重新導向 - ex. 301 Moved Permanently, 302 Found (暫時移到其他位置) - 4xx : Client死掉 - ex. 403 Forbidden, 404 Not Found - 5xx : Server死掉 - ex. 500 Internal Server Error, 502 Bad Gateway - HTTPS = HTTP + SSL/TLS - HTTPS通過SSL提供的數據加密、身份驗證和消息完整性驗證等安全機制，為Web訪問提供了安全性保證 - [ref](https://www.google.com/search?q=dog) - HTTP2.0 vs HTTP1.1 - HTTP的瓶頸 - 載入延遲 - 因為HTTP一條連線只能處理一個request, 大部分瀏覽器每個domain最多開啟6條，而每條連線要開啟都要先做TCP三方交握，若同時開啟多條連線，彼此間需要分享頻寬，會影響傳輸效能 - HTTP只有Client才能發出request，因此就算Server知道Client需要某個資源，也需要等到Client主動請求，無法預先提供支援 - HTTP的request及response header都沒有壓縮，每個header大小為200byte~2KB，每個訊息平均要700~800byte，而且有高重複的資訊 (ex. User-Agent, Host, Cookie, Version, \r\n\s, GET/POST等) - SPDY : HTTP2.0是based on SPDY協定 (基於TCP開發的應用層協定) - 由Google開發，最早被用於Google Chrome瀏覽器中用來存取Google SSL的加密服務，用於縮短網頁的載入時間(by壓縮、Multiplexing、Priority)及提高安全性 - SPDY只需要建立一個TCP連線即可傳送網頁內容及圖片等資源 - 該條連線沒有限制request次數 - 將訊息拆成Control Fram和Data Frame，將資料切成多個Data Frame交錯傳送，並壓縮Header資訊 - 將重複的訊息、詞彙建成一個字典，簡化成常用的key - ex.只傳送與前一個request不相同的header attribute - Client可以決定request Data Frame的優先級，交錯傳送重要度較高的Data Frame - 傳輸的訊息為Binary (而非hyper text)，更容易被壓縮傳輸 - Server可以主動推播內容 (而非只能被動等待Client請求)，減少Client載入頁面的延遲時間 - SPDY使用TLS加密 - [ref1](https://sls.weco.net/CollectiveNote20/SPDY) - [ref2](https://www.cnblogs.com/frankyou/p/6145485.html) - [ref3](https://blog.csdn.net/zqjflash/article/details/50179235) - vs 1.1 1. 2.0採用binary格式而非1.1的text格式 (壓縮效果較佳+準確率較高) 2. 2.0是Multiplexing，即一條連線可以重複使用 3. 2.0壓縮header，降低傳輸成本 4. 2.0的Server可以主動將資源推播到Client的buffer ## SSL (Secure Socket Layer) / TLS (Transport Layer Security) - SSL位於應用層和傳輸層之間，可以為任何基於TCP的應用層協定提供安全保障 ![](https://i.imgur.com/FjTeBFk.png) - 應用層封包會先傳遞給SSL, 讓SSL進行加密，並增加SSL Header - 要求對每個數據禁行加密即解密 $\rightarrow$ 系統資源開銷大 - SSL協定分成兩層: - 上層 1. SSL Handshake Protocol - 用來協商通訊過程中使用的加密套件(加密演算法、密鑰交換演算法、MAC演算法)，在server-client之間交換密鑰及進行身分驗證 3. SSL Change Cipher Spec Protocol - 通知對方之後的通訊將使用新協商的加密套件 5. SSL Alert Protocol - 通知對方告警訊息(包含嚴重級別及描述) - 底層 - SSL Record Protocol - 負責上層數據計算(添加MAC值、加密)，並將處理後的紀錄傳給對方 - SSL在通訊雙方間建立加密通道來保證傳輸的機密性 - 加密演算法: 主要支持DES、3DES、AES - 身分驗證: 利用數位簽章 (非對稱演算法) - MAC (Message Authentication Code): 基於MD5或SHA的MAC演算法 - MAC能將密鑰和任意長度的數據轉換成固定長度的數據 - 傳送方將MAC值加在message後傳給接收方，接收方收到之後會再次計算MAC值，與收到的比較，作為驗證是否有被改動(如果有就丟棄) ![](https://i.imgur.com/DX09zxX.png) - 在TCP三方交握建立連線之後，若要使用SSL加密通訊內容，就會進行SSL Handshake :::info 大致分成三個階段 1. Authentication Phase : 最開始到驗證certificate完成 (Handshake Protocol) 2. Key Exchange Phase : 到Server Finished (Handshake Protocol) 3. Encrypted Data Transfer Phase : 開始加密傳輸 (Record Protocol) ::: ![](https://i.imgur.com/ArXzorD.png) 1. Client通過Client Hello消息告知Server 1. 他支持的最高SSL版本 (ex. sslv3, tls1.0, tls1.1, tls1.2) 2. 希望使用的密鑰交換演算法 (身分驗證用 ex. RSA, DH, DHE, ...) 3. Certificate的PKI類型 (ex. RSA, DSS) 4. 希望使用的加密演算法 (實際對資料加密所使用的對稱式演算法 ex. RC4, 3DES, AES...) 5. 希望使用的加密演算法模式 (ex. CBC, CCM, GCM,...) 6. 希望使用的MAC演算法 (確保資料完整性 ex.MD5, SHA256) - 上述稱為一個Cipher Suites - ex. `TLS_ECDHE_RSA_WITH_AES256_CBC_SHA` 2. Server決定並透過Server Hello消息回應Client該次通訊要使用的SSL版本、加密演算法、密鑰交換演算法、MAC演算法 - 若Server運許Client之後重用本次Session, 同時分配並傳送session ID給client 3. Server傳送Certificate給Client，其中包含 - Server的公鑰 - Server的數位簽章 - [Optional] Server也可發送Certificate Request消息，要求Client傳送Certificate 4. Server發送Server Hello Done消息給Client, 用以通知Client協商結束，可以開始進行密鑰交換 5. Client驗證Server傳送過來的Certificate合法之後，利用公鑰加密一個隨機生成的premaster secret (密鑰交換，對稱式加密的密鑰), 並通過Client Key Exchange消息發送給Server - 如果不合法，會警告User - Server收到加密的premaster secret之後，利用他的私鑰進行解密，解密成功就可以獲得對稱式加密的密鑰 7. Client發送Change Cipher Spec消息，通知Server之後使用協商好的密鑰和加密套件進行加密及MAC計算 8. Client計算除了Change Cipher Spec之外的所有以交互消息的Hash值(加密並添加MAC值)，並傳送Finished消息給Server - Server這邊也會進行計算，並與收到的Finished消息中的MAC值與解密後的資料比較是否相同，證明協商成功 9. Server發送Change Cipher Spec消息給Client, 通知後續通訊使用協商好的密鑰、機密套件 10. Server計算已交互的握手訊息的Hash值(加密並計算MAC值)，並傳送Finished消息給Client進行比較 - Client需解密成功才能代表Server確實是數位簽章的擁有者(Server身分驗證成功) - 因為只有擁有私鑰的Server才能從Client Key Exchange消息解密得到premaster secret (對稱式加密的金鑰) - 比較成功才代表協商成功 :rightarrow: 至此handshake完成 - 恢復原有Session的SSL Handshake ![](https://i.imgur.com/5KerxxV.png) 1. Client發出Client Hello, 其中的Session ID設為要重用的Session ID 2. 若Server允許重用，向client發出Server Hello (Session ID設為同樣) - 之後不需要重新協商 3. Client發出Change Cipher Spec, 通知後續使用原本session協商好的方式 4. Client計算已交互的消息Hash值，並傳送Finished消息給Server驗證 5. Server也計算Hash值並傳送Finished消息給Client驗證 - [ref1](https://kknews.cc/zh-tw/code/o5m24lq.html) - [ref2](https://medium.com/@clu1022/%E9%82%A3%E4%BA%9B%E9%97%9C%E6%96%BCssl-tls%E7%9A%84%E4%BA%8C%E4%B8%89%E4%BA%8B-%E4%B9%9D-ssl-communication-31a2a8a888a6) ## SSH (Secure Shell) - 應用層(Layer 7)協定 - 通過在網路中建立Secure Tunnel實現Client與Server間的連接 - 遠端機器必須跑一個SSH Daemon - 會listen TCP Port 22進來的連線，經過認證後提供環境 - 本地機器則須要有個SSH Client Process - 負責使用SSH Protocol來傳送認證訊息及連線細節給遠端機器 - 遠端登入系統，使用SFTP(SSH File Transport)或SCP(Secure Copy)可以遠端傳輸檔案 - 利用非對稱式加密完成身分驗證(ex. RSA, DSA) - [ref](https://codecharms.me/posts/security-ssh) ## DHCP (Dynamic Host Configuration Protocol) - 在區域網路中自動派發IP與相關網路參數(Netmask, default gateway, DNS Server IP, etc) - 取得IP流程 | Client | direction | DHCP Server(s) | Comment | | -------- | :--------: | -------- | ----- | | DHCP Discover | :arrow_right: (Broadcast) | | 誰是DHCP Server | | | :arrow_left: | DHCP Offer | A : 我是，你需要這個IP嗎 B : 我也是，你需要這個IP嗎 C : ...| | DHCP Request | :arrow_right: (Broadcast) | | 我決定選擇A，我要這個IP | ||:arrow_left: | DHCP ACK | A : 這個IP(暫時)屬於你惹，我們來簽個合約吧| 1. DHCP Discover - Client透過Broadcast向整個網域中的主機發出封包，向負責這個網域的DHCP Server要求IP位址 - 因為此時還沒有IP Address，因此封包會帶上該Client的MAC Address - Client也可以透過封包中的`Ciaddr`欄位要求想要某個IP 3. DHCP Offer - 網域中的每台DHCP Server會到登錄檔中查詢該Client的MAC Address是否有使用過某個IP 1. 在靜態租約表中查詢 (是否分配固定IP，固定IP不能被其他人使用) 2. 在動態租約表中查詢 - 若Discover封包帶上`Ciaddr`，檢查該IP是否有人使用(且不可以是固定IP) - 若有，且該IP目前沒有人使用，則提供給Client - 若沒有，則向Client提供一個未被使用的IP，並記錄下來 - 封包中會帶有 1. Client的MAC地址 (`Chaddr`) 2. `XID` : 用來辨別是同個session 3. `Yiaddr` : 要分配給Client的IP位址 4. 租約期限的資訊(`Option` - ``) 4. DHCP Request - Client收到(多個)DHCP Server提供的IP(s)後，會選擇其中一個(通常是最早到的) - 透過**Broadcast**發出Request 1. 告訴該DHCP Server，表示想要使用該IP 2. 告知其他所有DHCP Server，自己已經選擇其他DHCP Server 6. DHCP ACK - DHCP Server收到Request封包後，會向Client傳送一個確認IP地址生效的封包 6. Client收到ACK後，會發出一個ARP封包，查詢該IP使否有被其他人使用 - 若有，向該DHCP發出DHCP Decline，並過一段時間之後再次嘗試獲取該地址 - 若依然無法使用，向DHCP發出DHCP Release放棄該地址 - 若成功獲取該地址，Client會將自己的TCP/IP協議與網路卡連結 - 更新租期 1. DHCP Request - Client在租約期限50%時，透過**Unicast**向DHCP Server要求要繼續使用同一個IP Address - Client在租約期限87.5%時，透過**Broadcast**向所有DHCP Server要求繼續使用同一個IP Address 2. DHCP ACK/NAK - Server收到後，若同意繼續使用，回傳ACK延長租期 - 若不同意繼續使用，回傳NAK - 但Client依舊可以繼續使用(因為租約還沒到嘛~) - 釋放IP - DHCP Release - 當租約到期後，Client會向Server發出DHCP Release封包來釋放IP地址 - 之後再重新要求分配 - refernece 1. [DHCP協議原理及應用](https://www.itread01.com/content/1548531570.html) 2. [DHCP原理](https://iter01.com/420435.html) 3. [DHCP原理和解釋](https://kknews.cc/zh-tw/code/4oelaoq.html) 4. [DHCP攻擊原理及防範](https://kknews.cc/zh-tw/code/q493b6r.html)

Read more

來拆一拆__libc_start_main

SOLACE PubSub+

Linux system call呼叫 & `fork()`

惡意程式分析 (ColdLock)