Network on Roduygo | Blog

IDS/IPS với Suricata & Cân bằng tải

Thu, 21 May 2026 23:00:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Ở bài viết trước, chúng ta đã xây dựng thành công Vành đai Tường lửa (Firewall) vững chắc, nhưng Firewall truyền thống chỉ kiểm tra được lớp vỏ bên ngoài của gói tin. Để phát hiện được những mã độc nằm sâu bên trong “thùng hàng” dữ liệu và điều phối lưu lượng mạng khổng lồ, hệ thống cần được trang bị thêm “con mắt ma thuật” và “bộ não” thông minh. Hôm nay, chúng ta sẽ đi sâu vào phân tích hệ thống phát hiện/ngăn chặn xâm nhập (IDS/IPS) với Suricata, đồng thời làm rõ nghệ thuật Cân bằng tải (Load Balancing) ở Layer 4 và Layer 7.

1. Ranh giới giữa “Quan sát” và “Hành động”: IDS vs IPS

IDS (Intrusion Detection System) và IPS (Intrusion Prevention System) đều là các công nghệ bảo mật giúp phát hiện và cảnh báo hoạt động trái phép dựa trên chữ ký, trí tuệ nhân tạo hoặc các hành vi bất thường. Tuy nhiên, vị trí đứng và quyền sinh sát của chúng trong mạng lưới lại hoàn toàn khác nhau.

1.1 Giám sát thụ động với IDS (Passive Monitoring)

IDS hoạt động theo cơ chế Promiscuous Mode (Chế độ hỗn tạp). Điều này có nghĩa là nó chỉ copy một bản sao dữ liệu từ Switch (thông qua cổng SPAN/Mirror) để phân tích mà không hề can thiệp vào luồng đi của gói tin gốc.

Ví dụ, khi bạn đang tải một file qua FTP không bảo mật, IDS sẽ soi gói tin và phát hiện nội dung Clear-text truyền đi. Lúc này, nó sẽ kích hoạt Signature-based Detection và bắn một Alert lên màn hình SOC: “Cảnh báo: Phát hiện truyền tin Clear-text trên cổng 21!”. Tuy nhiên, vì nó chỉ quan sát, tệp tin của bạn vẫn sẽ được tải về bình thường.

1.2 Kiểm tra trực diện với IPS (In-line Inspection)

Trái ngược với sự thụ động của IDS, IPS đứng ngay giữa đường truyền mạng giống như một trạm thu phí (In-line Inspection). Mọi gói tin bắt buộc phải đi xuyên qua thân xác nó. Nếu gói tin sạch thì được đi tiếp, còn gói tin “bẩn” chứa mã độc sẽ bị Drop (Hủy) ngay lập tức.

Trong thực tế, nếu kẻ xấu thực hiện Brute Force SSH với hàng trăm gói tin từ một IP lạ, IPS sẽ dùng Statistical Anomaly-based Detection để nhận diện bất thường. Nó không chỉ báo cáo mà còn tự động tạo một Rule trên tường lửa để Block/Deny IP đó ngay tức khắc, khiến kẻ tấn công chỉ nhận được thông báo Connection timed out.

Cảnh báo SOC: Việc triển khai IPS tuy an toàn tuyệt đối nhưng lại mang rủi ro “nghẽn cổ chai” mạng hoặc chặn nhầm (False Positive) lưu lượng hợp lệ. Trong thực tiễn vận hành SOC, các hệ thống giám sát mới sẽ luôn được chạy ở chế độ IDS (chỉ nhận cảnh báo) một thời gian dài để “học” hành vi mạng, trước khi được chuyển sang bật chế độ IPS (chặn cắt tự động).

2. Thực chiến cấu hình IPS Suricata chặn Ping

Để biến Suricata từ một “kẻ quan sát” thành một “vệ sĩ” thực thụ mang tính chất IPS, chúng ta phải dùng iptables để tóm các gói tin ICMP (Ping) và đẩy chúng vào một hàng chờ (Queue) để Suricata trực tiếp duyệt và ra lệnh hủy.

# Đẩy gói tin Ping (ICMP) chiều vào (INPUT) sang hàng chờ NFQUEUE số 0
sudo iptables -I INPUT -p icmp -j NFQUEUE --queue-num 0

# Đẩy gói tin Ping (ICMP) chiều ra (OUTPUT) sang hàng chờ NFQUEUE số 0
sudo iptables -I OUTPUT -p icmp -j NFQUEUE --queue-num 0

# Mở file rule của Suricata để thêm luật Drop ICMP
sudo nano /var/lib/suricata/rules/local.rules

# Khởi chạy Suricata trỏ vào file luật vừa tạo và lắng nghe trên card mạng enp7s0
sudo suricata -S /var/lib/suricata/rules/local.rules -i enp7s0

# Theo dõi log cảnh báo và hành động chặn (Drop) theo thời gian thực
sudo tail -f /var/log/suricata/fast.log

Sau khi cấu hình, nếu bạn thực hiện lệnh ping 8.8.8.8, gói tin sẽ bị tóm vào NFQUEUE. Thay vì nhận được phản hồi Ping thành công, màn hình của bạn sẽ báo Request Timeout, và trong file fast.log sẽ liên tục xuất hiện nhãn [wDrop] chứng tỏ IPS đã ra tay chặn đứng thành công.

3. Nghệ thuật Cân bằng tải (Load Balancer)

Bên cạnh bảo mật, Cân bằng tải (Load Balancing) là kỹ thuật sống còn để điều phối lưu lượng giao thông mạng, đảm bảo các máy chủ không bao giờ bị “nghẽn cổ chai” khi có lượng lớn người truy cập cùng lúc.

3.1 Cân bằng tải Lớp 4 (L4 Load Balancing)

Kiểu cân bằng này điều phối giao thông dựa trên giao thức TCP/UDP ở Tầng 4. Nó chỉ nhìn vào Địa chỉ IP Đích và Số cổng (Port) để ra quyết định — không cần quan tâm nội dung bên trong gói tin chứa cái gì. Nhờ việc không phải giải mã nội dung (Decapsulation), cách này có tốc độ xử lý cực kỳ nhanh (ví dụ: IPVS trên Linux, F5 Big-IP).

3.2 Cân bằng tải Lớp 7 (L7 Load Balancing)

Đây là kiểu cân bằng tải “thông minh” hoạt động ở Tầng Ứng dụng, thường dựa trên giao thức HTTP/HTTPS. L7 Load Balancer có khả năng “soi” sâu vào nội dung của URL, Header hoặc Cookie.

Nó cực kỳ linh hoạt và phù hợp cho kiến trúc Microservices. Ví dụ, nếu người dùng truy cập ezlearn.com/api/v1/chat, nó sẽ đẩy sang cụm máy ảo xử lý Chat; còn nếu truy cập ezlearn.com/static/images, nó lại đẩy sang cụm lưu trữ hình ảnh (ví dụ: Nginx, HAProxy).

3.3 Cân bằng tải mức DNS (DNS Load Balancing)

Đây là kiểu cân bằng nằm ở “vòng ngoài cùng” trước khi gói tin chạm tới hệ thống của bạn. Khi bạn gõ google.com, máy chủ DNS sẽ tự động xoay vòng (Round Robin) và trả về các địa chỉ IP khác nhau cho những người dùng khác nhau.

4. Demo thực chiến Nginx Load Balancer (Round Robin)

Để thấy rõ cách một L7 Load Balancer chia việc, chúng ta dùng Nginx thiết lập thuật toán Round Robin (Chia đều) cho 2 máy chủ Python.

# Bật máy chủ backend số 1 chạy nền ở cổng 8001
python3 -m http.server 8001 &

# Bật máy chủ backend số 2 chạy nền ở cổng 8002
python3 -m http.server 8002 &

# Sửa file cấu hình của Nginx để điều hướng tải giữa 2 máy chủ trên
sudo nano /etc/nginx/conf.d/lb.conf

# Kiểm tra xem file cấu hình Nginx có bị lỗi cú pháp không
sudo nginx -t

# Khởi động lại dịch vụ Nginx để áp dụng cấu hình Load Balancer
sudo systemctl restart nginx

# Gửi request kiểm tra đến Nginx ở cổng 8080
curl -I http://127.0.0.1:8080

Với cơ chế Round Robin, mỗi request curl mới sẽ được Nginx luân phiên gửi sang backend kế tiếp trong danh sách (gói thứ nhất vào 8001, gói thứ hai vào 8002). Nếu bạn dùng Wireshark với bộ lọc http && (tcp.port == 8001 || tcp.port == 8002), bạn sẽ thấy rõ sự phân tán luồng cực kỳ nhịp nhàng này.

Việc kết hợp IDS/IPS để thanh lọc mã độc và Load Balancer để điều phối luồng truy cập giúp hệ thống mạng doanh nghiệp đạt được cả hai yếu tố: Bảo mật vững chắc và Hiệu năng tối đa. Tuy nhiên, hacker luôn tìm cách lẩn trốn, và chúng có thể dùng Proxy hoặc VPN để mã hóa toàn bộ dữ liệu, khiến cả IDS lẫn IPS đều bị “mù”. Trong Bài 13 tiếp theo, chúng ta sẽ phân tích cách VPN hoạt động ở Tầng 3 và nghệ thuật Vượt rào & Ẩn danh (Proxy vs VPN). Hãy cùng đón đọc nhé!

Vành đai Tường lửa (Firewall) & NAT

Thu, 21 May 2026 22:58:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Trong 10 bài viết trước, chúng ta đã lột tả mọi góc khuất của các giao thức mạng từ Tầng 1 đến Tầng 7 và phân tích cách hacker thao túng chúng. Giờ là lúc chúng ta chuyển từ thế bị động sang chủ động: Xây dựng các công sự bảo vệ. Hôm nay, chúng ta sẽ bắt đầu với lớp giáp kiên cố nhất của mọi hệ thống: Vành đai Tường lửa (Firewall) và cơ chế ẩn danh nội bộ (NAT).

1. Tường lửa (Firewall) là gì và Vị trí hoạt động

Firewall là một hệ thống bảo mật mạng đóng vai trò như một “màng lọc” khắc nghiệt, kiểm soát toàn bộ lưu lượng dữ liệu đi ra (Outbound) và đi vào (Inbound) giữa mạng nội bộ an toàn và môi trường Internet đầy rẫy hiểm nguy.

Dưới góc độ triển khai, Firewall được chia thành hai loại chính:

Network Firewall: Thường là thiết bị phần cứng hoặc máy chủ chuyên dụng đặt tại Gateway/Router để bảo vệ cả một mạng doanh nghiệp.
Host-based Firewall: Chạy trực tiếp trên từng hệ điều hành (như Windows Defender Firewall hoặc firewalld trên Linux) để bảo vệ duy nhất chiếc máy tính đó.

Để chặn đứng các mối đe dọa, Firewall có thể hoạt động ở nhiều tầng khác nhau trong mô hình OSI:

Layer 3 (Network): Lọc dựa trên địa chỉ IP Nguồn/Đích (ví dụ: Chặn IP 157.240.199.35 của Facebook).
Layer 4 (Transport): Lọc dựa trên giao thức TCP/UDP và số Cổng (ví dụ: Cấm cổng 22 SSH).
Layer 7 (Application): Lọc dựa trên nội dung thực tế của ứng dụng (ví dụ: Chặn các truy vấn DNS độc hại hoặc các HTTP GET mang mã SQL Injection).

2. Nguyên lý hoạt động: ACL, Packet Filtering và Stateful Inspection

Sức mạnh của Firewall nằm ở một danh sách các quy tắc được định nghĩa từ trước gọi là ACL (Access Control List). Khi một gói tin bay tới, Firewall sẽ áp dụng các cơ chế kiểm tra sau:

2.1 Lọc gói tin (Packet Filtering)

Firewall sẽ “soi” trực tiếp vào các lớp vỏ Header (Lớp 3 và Lớp 4) mà chúng ta đã phân tích trên Wireshark ở các bài trước. Nó kiểm tra xem địa chỉ IP và Port này có nằm trong danh sách đen (Blacklist) hay không.

2.2 Kiểm tra trạng thái (Stateful Inspection)

Những thế hệ Firewall thông minh không chỉ soi từng gói tin rời rạc, mà nó còn “nhớ” trạng thái của cả một cuộc hội thoại. Ví dụ: Nếu nó nhớ rằng máy tính của bạn vừa gửi một gói SYN ngỏ lời ra ngoài, nó sẽ tự động cho phép gói SYN-ACK phản hồi từ Server đi xuyên qua tường lửa để trở về máy bạn.

2.3 Phán quyết (Actions)

Sau khi đối chiếu ACL, Firewall sẽ đưa ra một trong ba phán quyết đối với gói tin:

Allow / Accept: Cho phép gói tin đi qua bình thường.
Deny / Drop: Tiêu hủy gói tin trong im lặng. Kẻ gửi sẽ không biết gói tin đi đâu, dẫn đến việc Wireshark liên tục báo lỗi TCP Retransmission do chờ mãi không thấy phản hồi.
Reject: Hủy gói tin nhưng lịch sự gửi lại một thông báo lỗi (thường là gói tin ICMP) báo cho kẻ gửi biết rằng “Cửa đã bị khóa”.

3. Thực chiến Firewall và Bắt bệnh trên Wireshark

Để minh họa sự khác biệt của phán quyết, chúng ta dùng firewalld trên Linux để chặn cổng 22 (SSH) bằng cơ chế REJECT và xem hệ thống phản ứng ra sao.

# Kiểm tra danh sách các luật (rules) đang hoạt động trên Firewall
sudo firewall-cmd --list-all

# Thêm một Rich Rule để từ chối mọi kết nối TCP vào cổng 22
sudo firewall-cmd --add-rich-rule='rule family="ipv4" port port="22" protocol="tcp" reject'

# Reload để Tường lửa áp dụng luật mới ngay lập tức
sudo firewall-cmd --reload

Lúc này, nếu có kẻ cố tình truy cập vào cổng 22 của máy bạn (192.168.1.29), Wireshark sẽ không hiện lỗi gửi lại (Retransmission) mà sẽ chộp được ngay một gói tin phản hồi chí mạng ở Lớp 3:

# Gói tin ICMP trả về khi Firewall áp dụng cơ chế REJECT
# Hệ thống trực tiếp đóng sập cửa và thông báo "Host unreachable"

No. Time Source Destination Protocol Info
5 2.204045407 192.168.1.29 192.168.1.29 ICMP Destination unreachable (Host unreachable)

Góc nhìn SOC: Thông điệp Destination unreachable (Host unreachable) của ICMP chính là cách Firewall “trả lời” kẻ tấn công. Trong thực tế, Blue Team thường ưu tiên dùng quy tắc DROP thay vì REJECT. Việc Drop (hủy trong im lặng) sẽ làm công cụ quét mạng (Scanner) của hacker bị treo và chậm đi đáng kể do phải đợi Timeout, đồng thời không cung cấp cho chúng bất kỳ manh mối nào về việc hệ thống có Firewall hay không.

4. NAT (Network Address Translation): Người hùng giấu mặt

Firewall chặn đứng các cuộc tấn công từ bên ngoài, nhưng còn một kỹ thuật khác giúp hệ thống nội bộ trở nên vô hình trên Internet: NAT. NAT hoạt động chủ yếu ở Tầng 3 và Tầng 4, với nhiệm vụ thay đổi địa chỉ IP trong gói tin khi nó đi qua Router.

Hãy xem quá trình gói tin đi từ máy tính của bạn (IP nội bộ 192.168.1.29) ra máy chủ Facebook (157.240.199.35):

Gói tin đi ra (Outbound): Máy bạn gửi gói tin từ địa chỉ 192.168.1.29:56375 tới 157.240.199.35:443.
Tại Router (Quá trình dịch): Router không thể đẩy dải IP 192.168.x.x ra Internet vì đây là dải địa chỉ Private không được định tuyến. NAT sẽ “xóa” IP nguồn này và thay bằng IP Public của công ty (ví dụ: 113.161.x.x). Đồng thời, nó ghi vào NAT Table một dòng: “Port 56375 của máy nội bộ .29 đang được gán cho kết nối Facebook”.
Gói tin đi về (Inbound): Facebook phản hồi lại địa chỉ Public 113.161.x.x:56375. Router nhận gói tin, dò lại NAT Table, thấy khớp Port nên tự động “dịch” ngược lại IP đích thành 192.168.1.29 và đẩy vào máy bạn.

Nhờ NAT, dù công ty bạn có hàng nghìn nhân viên, tất cả chỉ cần dùng chung một vài địa chỉ IP Public để lướt web. Hacker đứng ngoài Internet sẽ không thể nào biết được kiến trúc địa chỉ IP thực sự bên trong mạng nội bộ của bạn.

Việc triển khai vững chắc Firewall và NAT giúp che giấu và bảo vệ hạ tầng mạng của tổ chức khỏi 90% các cuộc rà quét tự động của tin tặc. Tuy nhiên, Firewall chỉ có thể soi được lớp vỏ Header, vậy nếu hacker nhét một tệp chứa mã độc vào bên trong một gói tin HTTP hợp lệ thì sao? Ở Bài 12 tiếp theo, chúng ta sẽ lắp đặt thêm “con mắt ma thuật” cho mạng lưới: Phân tích sự khác biệt giữa IDS (Giám sát thụ động) và IPS (Ngăn chặn chủ động) với công cụ Suricata. Đừng bỏ lỡ nhé!

Hạ tầng Mạng (DNS & DHCP)

Thu, 21 May 2026 22:53:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Sau khi đã thiết lập xong “đường hầm” mã hóa vững chắc ở Tầng 6, chúng ta chính thức bước chân vào Lớp 7 (Application). Đây là nơi chứa đựng những giao thức nền tảng nhất giúp Internet vận hành, nhưng cũng là những “góc khuất ngây thơ” nhất vì mặc định chúng thiếu đi các cơ chế bảo mật cốt lõi. Hôm nay, chúng ta sẽ cùng bóc tách hệ thống phân giải tên miền (DNS) và quá trình xin cấp phát IP tự động (DHCP), đồng thời phân tích các đòn đánh hiểm hóc nhắm vào chúng.

1. DNS (Domain Name System) - Bản danh bạ của Internet

Hệ thống phân giải tên miền (DNS) là một giao thức cốt lõi thuộc Tầng 7 (Application Layer) hoạt động chủ yếu qua cổng UDP 53. Nhiệm vụ của nó là “dịch” các tên miền dễ nhớ đối với con người (như google.com) thành địa chỉ IP thực tế để máy tính có thể giao tiếp với nhau trên mạng.

Ví dụ, trước khi bạn thực sự truy cập vào trang Facebook, máy tính của bạn sẽ bắn một gói tin truy vấn DNS đến máy chủ phân giải (như 8.8.8.8) để hỏi IP của Facebook là gì. Sau khi DNS trả về địa chỉ IP và lưu nó vào bộ nhớ đệm (cache), trình duyệt của bạn mới bắt đầu thực hiện kết nối TCP 3 bước để trao đổi dữ liệu web.

2. Bắt tại trận các đòn tấn công nhắm vào DNS

DNS được thiết kế từ thời kỳ sơ khai của Internet nên nó rất “ngây thơ”: mặc định các truy vấn không được mã hóa và không có cơ chế xác thực danh tính mạnh mẽ. Hacker hiểu rất rõ điểm yếu này và thường xuyên tung ra các đòn tấn công sau:

DNS Spoofing / Poisoning (Lừa đảo/Đầu độc): Kẻ tấn công gửi một gói tin trả lời (Response) giả mạo chứa địa chỉ IP của máy hacker, cố gắng đến máy bạn nhanh hơn cả DNS Server thật. Nếu số định danh Transaction ID trong gói tin trùng khớp, máy tính của bạn sẽ tin tưởng tuyệt đối và truy cập thẳng vào trang web lừa đảo do hacker dựng sẵn.
DNS Tunneling (Đường hầm dữ liệu): Tường lửa của các doanh nghiệp thường luôn cho phép cổng 53 đi qua một cách tự do. Biết được kẽ hở này, hacker có thể nhồi nhét dữ liệu nhạy cảm (như mã nguồn dự án hoặc thông tin thẻ tín dụng) vào bên trong các truy vấn DNS thông thường để âm thầm tuồn dữ liệu ra ngoài (Data Exfiltration) mà không bị hệ thống IDS/IPS chặn lại.
DNS Hijacking (Chiếm quyền điều khiển): Kẻ gian trực tiếp thay đổi cài đặt máy chủ DNS trên hệ điều hành máy nạn nhân hoặc trên Router để trỏ mọi truy vấn phân giải về một DNS Server do chúng kiểm soát hoàn toàn.

Dưới đây là output Wireshark ghi lại một truy vấn DNS bình thường. Nếu bị DNS Spoofing, IP trả về ở gói số 2 sẽ là IP của kẻ tấn công thay vì IP thật:

# Máy khách 192.168.1.156 hỏi DNS Server 203.113.188.6 địa chỉ của google.com
# Bộ lọc Wireshark: dns && ip.addr == 192.168.1.156

No. Time Source Destination Protocol Info
1 0.000000 192.168.1.156 -> 203.113.188.6 DNS Standard query 0x24b7 A google.com
2 0.084123 203.113.188.6 -> 192.168.1.156 DNS Standard query response 0x24b7 A google.com A 142.250.198.46

3. DHCP (Dynamic Host Configuration Protocol) và Quy trình DORA

Trước khi máy tính có thể “hỏi đường” bằng DNS, nó phải làm thủ tục “xin hộ khẩu” để có một địa chỉ IP nội bộ hợp lệ nhằm gia nhập mạng. Quá trình tự động hóa này do giao thức DHCP đảm nhận, hoạt động ở Tầng 7 và sử dụng cổng UDP 67 cho Server, UDP 68 cho Client.

Khi bạn vừa cắm dây cáp mạng hoặc bật Wi-Fi, một quy trình 4 bước mang tên DORA sẽ lập tức diễn ra:

D — Discover (Khám phá): Máy tính của bạn lúc này chưa có IP, nó dùng địa chỉ 0.0.0.0 để “hét” lên toàn mạng bằng gói tin Broadcast: “Có ai là DHCP Server ở đây không? Tôi cần một địa chỉ IP!”.
O — Offer (Đề nghị): Router (đóng vai trò DHCP Server) nghe thấy và đáp lại: “Tôi đây! Tôi đang có sẵn địa chỉ 192.168.1.14 trống, cậu có muốn dùng không?”.
R — Request (Yêu cầu): Máy của bạn phản hồi lại toàn mạng: “Tuyệt quá! Tôi đồng ý dùng địa chỉ .14 đó. Làm ơn khóa địa chỉ đó lại cho tôi nhé!”.
A — Acknowledge (Xác nhận): Router chốt sổ và thông báo: “Ok, địa chỉ .14 là của cậu trong vòng 24 giờ tới. Đây là thông số DNS và Default Gateway để cậu vào mạng”.

4. DHCP Starvation và Rogue Server - Sự nguy hiểm của Broadcast

Điểm yếu chí mạng của DHCP là nó hoạt động hoàn toàn dựa trên niềm tin vào bất kỳ thiết bị nào phản hồi lại gói tin Broadcast (255.255.255.255). Kẻ tấn công đứng trong cùng một mạng LAN có thể dễ dàng khai thác niềm tin này:

DHCP Starvation (Tấn công làm cạn kiệt): Hacker sử dụng công cụ tự động để tạo ra hàng vạn gói tin Discover với các địa chỉ MAC giả mạo liên tục. Router sẽ ngây thơ cấp phát toàn bộ dải IP trống trong kho của nó (ví dụ từ .2 đến .254) cho các MAC ảo này. Hậu quả là khi một nhân viên thật kết nối vào mạng, Router sẽ báo “hết số” và họ không thể nhận được IP để vào mạng.
Rogue DHCP Server (Server giả mạo): Hacker chủ động dựng lên một DHCP Server giả ngay trong mạng công ty. Khi máy của nhân viên gửi gói tin Discover xin IP, Server giả này sẽ phản hồi nhanh hơn cả Router thật để cấp IP — nhưng nó sẽ cấp cho nạn nhân một Default Gateway giả mạo trỏ thẳng về máy của hacker. Lúc này, toàn bộ dữ liệu nạn nhân gửi ra Internet đều chảy xuyên qua máy kẻ tấn công, tạo nên một đòn Man-in-the-Middle (MitM) hoàn hảo.

Cảnh báo SOC: Để chống lại các cuộc tấn công hạ tầng này, quản trị viên mạng cần cấu hình tính năng DHCP Snooping trên các Switch vật lý. Tính năng này sẽ chỉ cho phép các cổng (Port) kết nối với Router thật mới được quyền gửi gói tin Offer và Acknowledge, chặn đứng mọi DHCP Server giả mạo.

Thấu hiểu cách DNS và DHCP vận hành giúp SOC Analyst phát hiện sớm các chiến dịch đánh cắp dữ liệu hoặc nghe lén mạng nội bộ trước khi chúng gây ra hậu quả. Sau khi gói tin của chúng ta đã có IP và tìm được đích đến, nó sẽ được chuyển giao cho các giao thức truyền tải văn bản và tệp tin. Trong Bài 9 tiếp theo, chúng ta sẽ phân tích sâu hơn về HTTP/HTTPS, cách FTP làm lộ mật khẩu trần trụi và kiến trúc đường hầm an toàn của SFTP. Hẹn gặp lại các bạn!

Lớp 5 (Session) & Ranh giới của Phiên làm việc

Thu, 21 May 2026 22:30:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Sau khi đã thiết lập xong “đường ống” vật lý vững chắc bằng giao thức TCP ở Tầng 4, hệ thống phải đối mặt với một bài toán mới: Làm sao để “nhớ mặt” người dùng mà không bắt họ phải đăng nhập lại sau mỗi cú click chuột? Đó chính là nhiệm vụ của Tầng 5 (Session Layer) — nơi ranh giới của các phiên làm việc được thiết lập và cũng là nơi hacker tung ra những đòn cướp quyền vô cùng hiểm độc.

1. Tầng 5 (Session) và Sự cần thiết của Phiên làm việc

Khi bạn mở trình duyệt web và thực hiện nhiều yêu cầu cùng lúc (như mở nhiều tab, tải nhiều ảnh), dữ liệu có nguy cơ bị lẫn lộn vào nhau. Tầng 5 (Lớp Phiên) sinh ra để giải quyết vấn đề này bằng cách thiết lập, quản lý và kết thúc các phiên kết nối. Nó đóng vai trò tạo ra một ranh giới độc nhất cho từng cuộc liên lạc.

Ở mức độ truyền tải, Tầng 5 quản lý “luồng” nói chuyện thông qua 3 chế độ:

Đơn công (Simplex): Dữ liệu chỉ đi một chiều (như bạn nghe radio).
Bán song công (Half-duplex): Hai bên nói chuyện luân phiên (như bộ đàm — người này nói xong người kia mới được nói).
Song công toàn phần (Full-duplex): Cả hai cùng nói và nghe cùng lúc (như gọi điện thoại di động).

Tuy nhiên, bài toán lớn nhất ở đây là hiệu năng. Việc bắt tay (Handshake) ở Tầng 4 (TCP) và Tầng 6 (TLS) cực kỳ tốn thời gian và làm “mệt” CPU của máy chủ. Để tối ưu hóa, Tầng 5 không bắt hai thiết bị phải chào hỏi lại từ đầu cho mỗi gói tin, mà sử dụng các cơ chế định danh đặc biệt.

2. Giải phẫu Session ID và Session Ticket trên Wireshark

Để duy trì trạng thái kết nối, Tầng 5 sử dụng hai công cụ chính là Session ID và Session Ticket. Bằng cách dùng Wireshark, chúng ta có thể dễ dàng bắt được những “tấm vé” này bay trên không gian mạng.

2.1 Định danh cuộc trò chuyện bằng Session ID

Sau lần bắt tay đầu tiên thành công, máy chủ sẽ cấp cho bạn một “mã số định danh” gọi là Session ID. Khi máy bạn gửi hàng nghìn khung dữ liệu tiếp theo, nó chỉ cần đính kèm ID này. Server nhìn vào ID sẽ biết ngay: “Đây là khách quen, đã kiểm tra an ninh xong rồi, cho dữ liệu đi thẳng lên Tầng 6 để xử lý!”.

# Lọc gói tin Server Hello để tìm Session ID do máy chủ cấp phát
# Cú pháp bộ lọc trên Wireshark: tls.handshake.type == 2

Handshake Protocol: Server Hello
 Handshake Type: Server Hello (2)
 Length: 118
 Version: TLS 1.2 (0x0303)
 Random: dc3aa089a0c8825e54cc0106c17a0cb90305776b2d49f405fe30dc0f2bfad484
 Session ID Length: 32
 Session ID: d451a3116057f79488abdba0e27371ef79b25a156fcd8afaf011b9aa5bdb900b
 Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)

Cái dãy số Hex dài đó (d451a311…) dùng để: Định danh cuộc trò chuyện: Khi máy Lenovo của bạn gửi hàng nghìn Frame dữ liệu tiếp theo (như các gói DATA của HTTP/2), nó không cần phải gửi lại toàn bộ thông tin chào hỏi. Nó chỉ cần gắn cái ID này vào (hoặc dùng trạng thái đã thiết lập từ ID này). Nhận diện người quen: Server nhìn vào ID này sẽ biết: “À, đây là gói tin tiếp theo của ông bạn ở IP 192.168.1.156, đã kiểm tra xong xuôi rồi, cho dữ liệu đi thẳng lên Tầng 6 để dịch luôn!”.

2.2 Vé phục hồi nhanh (Session Ticket)

Để đẩy nhanh tốc độ kết nối lại (0-RTT), máy chủ cung cấp một Session Ticket. Đây thực chất là một cái “vé” lưu trữ trạng thái bảo mật của phiên trước đó. Thay vì phải tính toán lại các thuật toán mã hóa nặng nề, máy khách chỉ cần trình chiếc vé này ra để nối lại phiên làm việc ngay lập tức.

# Lọc gói tin New Session Ticket để xem vé bảo mật được mã hóa
# Cú pháp bộ lọc trên Wireshark: tls.handshake.type == 4

TLSv1.3 Record Layer: Handshake Protocol: New Session Ticket
 Content Type: Application Data (23)
 Version: TLS 1.2 (0x0303)
 Handshake Protocol: New Session Ticket
 Handshake Type: New Session Ticket (4)
 Length: 53
 TLS Session Ticket
 Session Ticket Lifetime Hint: 600 seconds (10 minutes)
 Session Ticket Age Add: 3185912667
 Session Ticket Nonce Length: 8
 Session Ticket: af23cc7378d7440f6a6447726da2062b7d2198d9b8c7aaad6a71213fba0cbb97

3. Các đòn tấn công tử huyệt nhắm vào Phiên làm việc

Hacker hiểu rất rõ giá trị của những mã Session ID này. Vì Server hoàn toàn tin tưởng vào cái vé, nên kẻ nào cầm vé, kẻ đó có quyền. Dưới đây là 3 đòn tấn công kinh điển ở Tầng 5.

3.1 Cướp Phiên (Session Hijacking)

Đây là đòn đánh trực diện nhất. Kẻ địch hoàn toàn không cần biết mật khẩu của bạn.

Chúng chỉ cần “đánh cắp” được Session ID đang nằm trong Cookie hoặc bộ nhớ đệm trình duyệt thông qua các kỹ thuật như Sniffing (nghe lén mạng Wi-Fi không an toàn) hoặc tấn công Cross-Site Scripting (XSS). Khi có được ID này, chúng dùng nó để gửi gói tin lên Server. Server sẽ lầm tưởng hacker chính là bạn và cho phép truy cập thẳng vào tài khoản.

Cảnh báo SOC: Để chống lại Session Hijacking, hệ thống mạng bắt buộc phải mã hóa toàn bộ dữ liệu truyền tải bằng HTTPS/TLS và các Cookie phải được gắn cờ Secure cùng HttpOnly để ngăn mã độc JavaScript trích xuất Session ID.

3.2 Tấn công Phản hồi (Replay Attack)

Lỗ hổng này đánh thẳng vào cơ chế “vé phục hồi nhanh” (New Session Ticket / 0-RTT) mà chúng ta vừa soi trên Wireshark.

Vì cái vé này được thiết kế để kết nối nhanh mà không cần bắt tay lại, hacker có thể can thiệp ở giữa mạng (MitM), bắt lấy bản sao gói tin chứa Ticket của bạn và gửi lại cho Server nhiều lần. Nếu hệ thống ứng dụng không có cơ chế chống trùng lặp (ví dụ: dùng timestamp hoặc nonce), hacker có thể ép Server thực hiện lại một giao dịch nhạy cảm (như chuyển tiền) nhiều lần chỉ bằng cách “phát lại” cái vé cũ đó.

3.3 Cố định Phiên (Session Fixation)

Ngược lại với việc đi ăn cắp, trong kỹ thuật này hacker lại chủ động “tặng” cho bạn một cái ID.

Kẻ tấn công sẽ tạo ra một Session ID hợp lệ từ trước, sau đó lừa bạn click vào một đường link chứa sẵn ID đó để đăng nhập. Sau khi bạn đăng nhập thành công, hệ thống vô tình “đóng dấu xác thực” cho cái ID do hacker cung cấp. Lúc này, hacker chỉ cần ung dung nhập cái ID mà chúng đã biết trước đó vào trình duyệt — phiên làm việc lúc này trở thành “dùng chung” giữa bạn và hacker.

Việc thấu hiểu Tầng 5 giúp SOC Analyst nhận ra rằng: Không phải cứ đăng nhập xong là an toàn tuyệt đối, bởi nếu kẻ gian cướp được “tấm vé” Session, chúng nghiễm nhiên trở thành người chủ hợp pháp. Tuy nhiên, cái vé đó và toàn bộ dữ liệu ứng dụng thực chất được xáo trộn như thế nào để không ai đọc lén được trên mạng? Trong Bài 6 tiếp theo, chúng ta sẽ bước lên Tầng 6 (Presentation) để bóc tách lớp vỏ mã hóa SSL/TLS, giải phẫu thuật toán CHACHA20 và tìm hiểu lỗ hổng POODLE khét tiếng. Hãy cùng chờ đón nhé!

TCP và Nghệ thuật Bắt tay 3 Bước

Thu, 21 May 2026 09:00:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Ở bài trước, chúng ta đã thấy Tầng 2 và 3 chỉ biết tìm đường và “ném” gói tin đi mà không hề quan tâm đến sự sống chết của dữ liệu. Để đảm bảo thông tin không bị thất lạc hay lộn xộn trên môi trường Internet khắc nghiệt, chúng ta cần đến “trái tim” của sự ổn định: Giao thức TCP tại Tầng 4. Hôm nay, hãy cùng mổ xẻ cơ chế Bắt tay 3 bước kinh điển và cách dùng Wireshark để phát hiện các đòn tấn công mạng nguy hiểm.

1. Tầng 4 (Transport) và Sứ mệnh của TCP

Nhiệm vụ cốt lõi của Tầng 4 (Giao vận) là kiểm soát toàn bộ quá trình truyền tải dữ liệu. Khi nhận dữ liệu từ các tầng trên, Tầng 4 sẽ thực hiện phân đoạn (Segmentation) để chia nhỏ dữ liệu cho vừa với đường truyền, đánh số thứ tự (Sequencing) và dùng số Cổng (Port) để định tuyến đến đúng ứng dụng.

Tại đây, hai giao thức thống trị là TCP (Transmission Control Protocol) và UDP (User Datagram Protocol). Việc lựa chọn giao thức nào hoàn toàn phụ thuộc vào ứng dụng ở Tầng 7. Hệ điều hành sẽ dán một cái nhãn vào IP Header ở Tầng 3 (ví dụ nhãn số 6 cho TCP, 17 cho UDP) để Tầng 4 biết phải lôi “bộ máy” nào ra xử lý.

Trong khi UDP đề cao tốc độ bằng cách “cứ có là gửi, mất thì thôi”, thì TCP lại là biểu tượng của sự tin cậy. TCP đảm bảo mọi gói tin đều đến đúng nơi, đúng thứ tự, và nếu có bất kỳ dữ liệu nào bị mất, nó sẽ bắt buộc gửi lại (Retransmission).

2. Nghệ thuật Bắt tay 3 Bước (3-Way Handshake)

Trước khi truyền đi dù chỉ một byte dữ liệu ứng dụng, TCP yêu cầu hai thiết bị phải thiết lập một kết nối vững chắc thông qua quá trình Bắt tay 3 bước. Quá trình này diễn ra như sau:

Bước 1 — Gói SYN: Máy Client gửi một gói tin mang cờ SYN (Synchronize) với số thứ tự Sequence ban đầu để ngỏ lời kết nối. Gói này cũng khai báo Window Size, báo cho Server biết: “Tôi có thể nhận tối đa 64,240 bytes dữ liệu một lúc đấy nhé”.
Bước 2 — Gói SYN-ACK: Server đồng ý và đáp lại bằng gói SYN, ACK. Cờ ACK được bật để Server thông báo: “Tôi đã nhận được gói 0 của ông, tôi đang đợi gói 1 đây”.
Bước 3 — Gói ACK: Client gửi lại gói ACK cuối cùng để chốt hạ. Từ lúc này, “đường ống” đã thông suốt.

Dưới đây là output Wireshark bắt được khi Client 192.168.1.114 kết nối đến Server 72.34.249.208 qua cổng HTTPS (443):

# Lọc theo địa chỉ IP của Client và Server:
# Mẫu luồng gói tin trong Wireshark

No. Time Source Destination Protocol Info
1 0.000000 192.168.1.114 -> 72.34.249.208 TCP 47682 -> 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460
2 0.474661 72.34.249.208 -> 192.168.1.114 TCP 443 -> 47682 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0
3 0.474780 192.168.1.114 -> 72.34.249.208 TCP 47682 -> 443 [ACK] Seq=1 Ack=1 Win=64512 Len=0
4 0.476483 192.168.1.114 -> 72.34.249.208 TLSv1.3 Client Hello (SNI=apex.go.sonobi.com)

Ghi chú: Gói số 4 cho thấy ngay sau khi bắt tay 3 bước hoàn tất, Client lập tức gửi Client Hello của TLS để khởi động mã hóa. Đây là quy trình chuẩn của HTTPS.

3. Cơ chế Đảm bảo Toàn vẹn (Sequence & Acknowledgment)

Làm sao TCP biết một gói tin đã đến đích an toàn? Bí quyết nằm ở cách nó sử dụng hai con số: Sequence Number (Số thứ tự) và Acknowledgment Number (Số xác nhận).

Khi gửi dữ liệu, Tầng 4 sẽ tính toán dựa trên số lượng byte. Nếu gói tin thứ nhất mang 500 byte dữ liệu và có Seq=1, thì gói tin thứ hai sẽ được đánh số Seq=501.

Khi máy đích nhận được gói thứ nhất, nó sẽ phản hồi bằng một gói có Ack=501, mang hàm ý: “Tôi đã nhận đủ 500 byte, hãy gửi tiếp cho tôi dữ liệu từ byte 501 trở đi”. Nếu Server không gửi Acknowledgment phản hồi sau một khoảng thời gian chờ, máy gửi sẽ tự động thực hiện gửi lại gói tin đó (Fast Retransmit hoặc RTO).

4. Bắt bệnh Mạng và Cảnh báo SOC bằng Wireshark

Với cơ chế khắt khe của TCP, Wireshark cung cấp cho SOC Analyst các bộ lọc cực kỳ mạnh mẽ để “bắt bệnh” hệ thống khi mạng bị chậm hoặc gặp sự cố:

Mất gói (Retransmission): Bộ lọc tcp.analysis.retransmission sẽ hiển thị các dòng chữ màu đỏ cảnh báo gói tin phải gửi lại do không nhận được ACK.
Thiếu mảnh dữ liệu (Duplicate ACK): Dùng bộ lọc tcp.analysis.duplicate_ack. Bạn sẽ thấy máy nhận liên tục gửi các gói ACK có cùng một số hiệu để “gào thét” đòi mảnh dữ liệu bị rớt ở giữa luồng.
Hệ thống bị ngộp (Zero Window): Bộ lọc tcp.analysis.zero_window phát hiện khi thiết bị nhận đã cạn kiệt bộ nhớ đệm. Nó sẽ ném ra gói tin này để ép máy gửi phải dừng truyền ngay lập tức (cơ chế Flow Control).

Cảnh báo SOC — Tấn Công SYN Flood: Hacker rất thích lợi dụng sự “kỹ tính” trong quá trình Bắt tay 3 bước của TCP để thực hiện tấn công từ chối dịch vụ (DDoS). Bằng cách bắn hàng vạn gói SYN giả mạo vào Server nhưng tuyệt đối không bao giờ trả lời bằng gói ACK cuối cùng, Server sẽ bị treo cứng vì cạn kiệt tài nguyên để chờ đợi những cái “bắt tay” không bao giờ hoàn tất. Bộ lọc phát hiện nhanh: tcp.flags.syn == 1 && tcp.flags.ack == 0.

Như vậy, việc thấu hiểu nhịp đập của “Trái tim” TCP giúp chúng ta phân biệt được một sự cố mạng do đường truyền kém với một cuộc tấn công từ chối dịch vụ có chủ đích. Ở Tầng 4, chúng ta mới chỉ quản lý được các cổng (Port), nhưng để duy trì trạng thái đăng nhập liên tục của người dùng, chúng ta cần tiến lên một bậc nữa. Trong Bài 4 tiếp theo, hãy cùng khám phá Lớp 5 (Session) và các kỹ thuật cướp phiên (Session Hijacking) tinh vi của Hacker. Đừng bỏ lỡ nhé!

Một gói tin được cấu tạo thế nào

Wed, 20 May 2026 08:00:00 +0700

Chào mừng các bạn đến với Series Giải phẫu Mạng (Network Anatomy) & Packet Analysis! Nếu trong series trước, chúng ta đã trở thành những “bác sĩ pháp y” mổ xẻ nội tạng của hệ điều hành Windows, thì ở series này, chúng ta sẽ bước ra không gian bên ngoài: Hệ thống Mạng. Đối với một SOC Analyst, nếu bạn không biết cách đọc một gói tin (Packet), bạn sẽ bị mù hoàn toàn trước các cuộc tấn công nhắm vào máy chủ. Hãy cùng khởi động bằng việc tìm hiểu bộ khung xương sống của vạn vật trên Internet: Mô hình OSI và công cụ Wireshark.

1. Bức tranh toàn cảnh: Mô hình OSI và TCP/IP

Để các thiết bị từ các nhà sản xuất khác nhau (Apple, Lenovo, Cisco…) có thể nói chuyện được với nhau, Tổ chức Tiêu chuẩn hóa Quốc tế đã tạo ra một bộ quy tắc chung gọi là Mô hình OSI (Open Systems Interconnection). Nó chia quá trình mạng phức tạp thành 7 tầng riêng biệt.

Từ trên xuống dưới, 7 tầng này bao gồm:

Tầng 7 - Application (Ứng dụng): Nơi dữ liệu có ý nghĩa với con người (như giao thức HTTP, DNS, SSH, FTP). Hầu hết các cuộc tấn công hiện đại như SQL Injection đều nhắm vào tầng này.
Tầng 6 - Presentation (Trình bày): Làm nhiệm vụ thông dịch, nén và đặc biệt là Mã hóa (như SSL/TLS) để bảo mật dữ liệu.
Tầng 5 - Session (Phiên): Thiết lập, duy trì và quản lý phiên kết nối (Session ID) giữa 2 thiết bị.
Tầng 4 - Transport (Giao vận): Kiểm soát truyền tải bằng TCP (tin cậy) hoặc UDP (tốc độ). Nó chia dữ liệu thành các đoạn nhỏ và dùng số Cổng (Port) để định tuyến đến đúng ứng dụng.
Tầng 3 - Network (Mạng): Quản lý địa chỉ logic (IP) và tìm đường đi (Routing) tốt nhất trên môi trường Internet.
Tầng 2 - Data Link (Liên kết dữ liệu): Quản lý địa chỉ vật lý (MAC) để các thiết bị nói chuyện trực tiếp với nhau trong cùng một mạng LAN.
Tầng 1 - Physical (Vật lý): Chuyển đổi dữ liệu nhị phân (0 và 1) thành các xung điện, ánh sáng hoặc sóng vô tuyến (Wi-Fi) truyền trên dây cáp vật lý.

Trong thực tế triển khai, người ta thường gộp mô hình này lại cho gọn nhẹ thành Mô hình TCP/IP (4 Lớp): Lớp Ứng dụng (gộp tầng 5,6,7), Lớp Giao vận (tầng 4), Lớp Internet (tầng 3), và Lớp Giao diện mạng (gộp tầng 1,2).

2. Hành trình của một dữ liệu: Đóng gói (Encapsulation)

Khi bạn bấm nút “Gửi” một tin nhắn, dữ liệu không bay thẳng vèo sang máy bên kia. Nó phải trải qua quá trình Đóng gói (Encapsulation) - nghĩa là đi qua mỗi tầng sẽ bị bọc thêm một lớp vỏ (Header) mới.

Dữ liệu thô (Data): Được sinh ra ở tầng Ứng dụng.
Segment / Datagram: Xuống Tầng 4, nó được dán thêm Header của TCP hoặc UDP chứa thông tin Cổng (Port).
Packet (Gói tin): Xuống Tầng 3, nó được bọc thêm IP Header chứa IP Nguồn và IP Đích.
Frame (Khung): Xuống Tầng 2, nó tiếp tục được dán thêm địa chỉ MAC Nguồn và MAC Đích.
Bits: Cuối cùng, chiếc card mạng (NIC) biến toàn bộ Frame đó thành các tia điện hoặc sóng Wi-Fi đẩy ra ngoài (Lớp 1).

Khi đến máy nhận, quá trình ngược lại gọi là Mở gói (Decapsulation) sẽ diễn ra: Lột dần từng lớp vỏ từ dưới lên trên để lấy dữ liệu thực.

3. Đặt gói tin lên “bàn mổ” Wireshark

Wireshark chính là kính hiển vi của SOC Analyst. Nó bắt được chính xác cấu trúc đóng gói mà ta vừa học. Khi bạn click vào một gói tin bất kỳ trên Wireshark, giao diện chi tiết ở khung bên dưới sẽ phản ánh đúng thứ tự của mô hình OSI.

Hãy cùng giải phẫu các thành phần cốt lõi của một gói tin:

3.1 Lớp 1 (Physical) - Mục Frame

Đây là các siêu dữ liệu vật lý mà card mạng ghi nhận được:

Frame Length: Kích thước thực sự của gói tin khi chạy trên dây cáp (ví dụ: 96 bytes (768 bits)).
Arrival Time: Thời gian chính xác đến từng micro giây mà gói tin chạm vào card mạng.
Interface id: Tên card mạng đang bắt gói tin (ví dụ: wlp8s0 trên Linux).
Protocols in frame: Wireshark tóm tắt luôn các lớp vỏ bên trong: eth:ethertype:ip:tcp:dns (Gói DNS chạy trên TCP, bọc bởi IP và Ethernet).

3.2 Lớp 2 (Data Link) - Mục Ethernet II

Đây là nơi địa chỉ vật lý (MAC Address) làm chủ cuộc chơi:

Source (Src) & Destination (Dst): Địa chỉ MAC (gồm 48 bit) của máy gửi và máy nhận (thường là Router để đi ra Internet).
Type: Một ID cực kỳ quan trọng báo hiệu cho card mạng biết lớp vỏ tiếp theo là gì. Nếu là IPv4 (0x0800), nó sẽ chuyển lên cho giao thức IPv4 xử lý. Nếu là 0x86dd, đó là IPv6.

3.3 Lớp 3 (Network) - Mục IPv4

Bóc lớp Ethernet ra, chúng ta thấy bộ định tuyến Internet:

Source Address & Destination Address: Địa chỉ IP logic của máy gửi và máy đích.
Time to Live (TTL): “Tuổi thọ” của gói tin. Mỗi khi đi qua một con Router, số này bị trừ đi 1 để tránh gói tin chạy vòng vòng mãi mãi. Nếu thấy TTL = 64, hệ thống nguồn có khả năng cao là chạy nhân Linux.
Flags: Các lá cờ điều khiển. Ví dụ cờ 0x2, Don't fragment dặn các thiết bị mạng rằng: “Tuyệt đối không xé nhỏ gói tin này ra”.
Protocol: Giống như Type ở Lớp 2, trường này (ví dụ: TCP (6) hoặc UDP (17)) sẽ ra lệnh cho hệ điều hành biết giao thức Tầng 4 nào sẽ phải xử lý tiếp theo.
Header Checksum: Dãy mã (như 0xe861) dùng để đảm bảo các thông tin (IP, TTL) không bị hỏng hóc hay thay đổi bit trong quá trình truyền.

3.4 Lớp 4 (Transport) - Transmission Control Protocol (TCP)

Bên trong cùng, chúng ta sẽ thấy cổng giao tiếp và luật chơi:

Source Port & Destination Port: Ví dụ máy bạn dùng cổng ngẫu nhiên 58610 để gõ cửa cổng HTTPS (443) của Facebook.
Sequence & Acknowledgment: Các con số giúp TCP sắp xếp lại thứ tự dữ liệu cho đúng và đảm bảo không gói tin nào bị rơi rớt.

3.5 Tầng 5, 6, 7: Nơi “Gói tin” biến mất và nhường chỗ cho “Dữ liệu” (Application Data)

Nếu bạn tinh mắt quan sát trên Wireshark, bạn sẽ thấy sau khi đi qua lớp TCP/UDP (Tầng 4), các lớp phía trên (Tầng 5 - Session, Tầng 6 - Presentation, Tầng 7 - Application) thường không được chia thành các mục riêng biệt rõ ràng như lớp MAC hay lớp IP, mà chúng hòa quyện lại thành một mục gọi là Application Data (như DNS, HTTP, TLS) Quá trình Wireshark “Giải mã” và hiển thị: Khi Wireshark bắt được luồng điện từ card mạng, nó thực hiện quá trình Decapsulation (Mở gói) đi ngược từ dưới lên trên. Nó bóc lớp vỏ Ethernet (Tầng 2) để lấy địa chỉ MAC, bóc tiếp lớp IP (Tầng 3) để lấy địa chỉ IP, và bóc lớp TCP (Tầng 4) để lấy số Port. Khi bóc đến Tầng 4 xong, phần lõi còn lại được đẩy thẳng lên Tầng Ứng dụng (Layer 7). Lúc này:

Nếu là giao thức không mã hóa (như HTTP, DNS, FTP): Wireshark sẽ “đọc hiểu” và phơi bày trần trụi toàn bộ văn bản, tài khoản, mật khẩu (Clear-text) cho bạn xem.
Nếu dữ liệu đã đi qua Tầng 6 (Presentation) và bị mã hóa bởi SSL/TLS: Wireshark sẽ gom lại và hiển thị dưới dạng một khối Encrypted Application Data chứa toàn các ký tự rác mà con người (và cả hacker) không thể đọc được

Như vậy, chúng ta đã nắm được “bản đồ kho báu” của mạng máy tính và biết cách sử dụng Wireshark để đọc những lớp vỏ cơ bản nhất. Bất kỳ một công cụ bảo mật nào (Firewall, IDS/IPS) cũng đều dựa trên nguyên lý đọc các lớp Header này để chặn/mở. Ở Bài 2 tiếp theo, chúng ta sẽ lặn sâu hơn vào Tầng 2 & 3, phân tích các giao thức kết nối nền tảng (ARP, ICMP) và trực tiếp đóng vai Hacker để thực hiện đòn tấn công mạo danh MAC (MAC Spoofing). Hẹn gặp lại các bạn!