Nền tảng Networking cho Bảo mậtNetworking Fundamentals for Security
Thuộc bộ kiến thức DevSecOps Roadmap.
Tổng quan
Mọi biện pháp bảo mật cuối cùng đều nằm trên nền của network: một firewall rule, một TLS handshake, một ranh giới segmentation, một DNS query trả về IP của service của bạn hoặc IP của server kẻ tấn công. Nếu không hiểu packet thực sự di chuyển thế nào — flag SYN nghĩa là gì, tại sao TTL bằng 1 lại quan trọng, resolver làm gì khi không tìm thấy bản ghi trong cache — bạn sẽ không thể lý giải tại sao một cuộc tấn công thành công hay tại sao một biện pháp phòng thủ lại chặn được nó. Attack surface phần lớn chính là network surface: mỗi port mở, mỗi protocol bị lộ ra ngoài, mỗi mối quan hệ tin cậy (trust) giữa các network zone đều là một nơi có thể xảy ra sự cố.
Note này là một bản refresher theo góc nhìn bảo mật, không phải một khóa học networking đầy đủ. Nó giả định bạn đã biết OSI layer và IP addressing từ trước, và diễn giải lại chúng xoay quanh câu hỏi “cái này có thể bị tấn công ở đâu, và chúng ta phòng thủ như thế nào?” Để tìm hiểu sâu hơn về networking (routing protocol, switching, wireless, QoS, network automation, chứng chỉ), xem Network Engineer knowledge base. Về mật mã học đằng sau TLS, xem Nền tảng Mật mã học. Về cách thiết kế zone và Zero Trust architecture, xem Bảo mật mạng & Zero Trust. Về công cụ packet capture thực hành, xem Công cụ kiểm thử bảo mật.
Tại sao điều này quan trọng hàng ngày với một DevSecOps engineer:
- Bạn review firewall/security-group rule và cần biết một port và protocol thực sự expose ra điều gì.
- Bạn triage một alert “DNS query đến một domain đáng ngờ” và cần biết điều đó có thể mang ý nghĩa gì.
- Bạn review một cấu hình ingress/TLS và cần phát hiện chứng chỉ hết hạn hoặc cipher yếu trước khi ship.
- Bạn thiết kế network segmentation cho một Kubernetes cluster hoặc VPC và cần lý giải về blast radius.
- Bạn đọc một pcap hoặc bản capture
tcpdumptrong lúc điều tra sự cố và cần nhận ra đâu là bình thường, đâu là dấu hiệu exfiltration.
Kiến thức nền tảng
OSI và TCP/IP model, nhìn tổng quan
| OSI Layer | Tên | TCP/IP Layer | Ví dụ | Ý nghĩa bảo mật |
|---|---|---|---|---|
| 7 | Application | Application | HTTP, DNS, SMTP, SSH | Nơi phần lớn tấn công hiện đại xảy ra (injection, bypass auth, malware C2) |
| 6 | Presentation | Application | TLS/SSL, encoding | Encryption/decryption, xác thực chứng chỉ |
| 5 | Session | Application | Session, TLS handshake | Session hijacking, đánh cắp token |
| 4 | Transport | Transport | TCP, UDP | Port scanning, SYN flood, giả mạo segment |
| 3 | Network | Internet | IP, ICMP, routing | IP spoofing, tấn công routing, subnetting/segmentation |
| 2 | Data Link | Network Access | Ethernet, VLAN, ARP | ARP spoofing, VLAN hopping, MAC flooding |
| 1 | Physical | Network Access | Cáp, sóng radio, cáp quang | Đấu nối trộm vật lý (physical tapping), wiretapping, jamming |
Thói quen liên quan đến bảo mật: khi thấy một alert hay một rule, hãy lập tức hỏi “cái này ở layer nào?” Một WAF rule hoạt động ở layer 7. Một security group rule thường ở layer 3–4 (IP + port). Một lỗi cấu hình VLAN nằm ở layer 2. Biết được layer sẽ cho bạn biết công cụ và biện pháp khắc phục nào là phù hợp.
IP addressing và subnetting, tóm tắt
- Một địa chỉ IPv4 dài 32 bit, viết thành bốn octet (
10.0.1.15). Subnet mask (hoặc hậu tố CIDR, ví dụ/24) chia nó thành phần network và phần host. 10.0.1.0/24nghĩa là 24 bit đầu là network; 256 địa chỉ (254 dùng được) thuộc về subnet đó.- Dải private (RFC 1918):
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16— không định tuyến được trên internet công cộng, thường dùng bên trong VPC và mạng nội bộ. - Tại sao điều này quan trọng với bảo mật: ranh giới subnet là hình thức network segmentation lâu đời và rẻ nhất. Một host ở subnet này không thể tiếp cận host ở subnet khác trừ khi router/firewall cho phép rõ ràng. Cấu hình subnetting sai (ví dụ đặt database và web server public trong cùng một
/24mà không có ACL ở giữa) âm thầm loại bỏ đi một lớp phòng thủ. - IPv6 dùng địa chỉ 128 bit và không có NAT theo thiết kế — mọi thiết bị đều có thể được tiếp cận toàn cầu (globally reachable), điều này thay đổi cách tính toán bảo mật: firewall ở perimeter và filtering trên từng host trở nên quan trọng hơn là “trốn sau NAT.”
Note này cố tình dừng lại ở đây — toán học subnetting đầy đủ, VLSM, routing table, và switching được trình bày chi tiết trong Network Engineer — IP Addressing and Subnetting và Network Engineer — Network Models and Layers.
TCP vs UDP — góc nhìn bảo mật nhanh
| TCP | UDP | |
|---|---|---|
| Kết nối | Hướng kết nối (3-way handshake: SYN, SYN-ACK, ACK) | Không kết nối (connectionless) |
| Độ tin cậy | Đảm bảo gửi đến, đúng thứ tự | Best-effort, không đảm bảo |
| Ứng dụng phổ biến | HTTP/HTTPS, SSH, kết nối database | DNS, VoIP, QUIC/HTTP3, streaming |
| Tấn công phổ biến | SYN flood, TCP hijacking, port scanning | UDP flood, amplification attack (DNS/NTP/memcached) |
Vì UDP không có handshake, kẻ tấn công có thể dễ dàng giả mạo source IP và dùng các request nhỏ để buộc server gửi response lớn đến nạn nhân — đây chính là cơ chế nền tảng của phần lớn tấn công DDoS amplification (DNS amplification, NTP amplification, memcached amplification).
Khái niệm chính
DNS qua góc nhìn bảo mật
DNS là cuốn danh bạ (phonebook) của internet — và danh bạ thì có thể bị can thiệp.
Cách hoạt động (đơn giản hóa quá trình resolution):
- Client hỏi một recursive resolver (ví dụ resolver của ISP, 8.8.8.8, hoặc resolver nội bộ của công ty) về
app.example.com. - Nếu chưa có trong cache, resolver hỏi một root server → được chuyển đến TLD server của
.com→ được chuyển đến authoritative name server củaexample.com. - Authoritative server trả về IP (bản ghi A/AAAA, hoặc chuỗi CNAME cuối cùng dẫn tới một IP).
- Resolver cache lại câu trả lời trong khoảng TTL của bản ghi rồi trả về cho client.
Các kiểu tấn công dựa trên DNS phổ biến:
| Tấn công | Diễn ra như thế nào | Phòng thủ |
|---|---|---|
| DNS spoofing / cache poisoning | Kẻ tấn công chèn response giả vào cache của resolver, chuyển hướng một domain đến IP do kẻ tấn công kiểm soát | DNSSEC, ngẫu nhiên hóa query ID/source port, resolver có xác thực response |
| DNS tunneling (exfiltration/C2) | Dữ liệu được mã hóa vào trong DNS query/response (ví dụ subdomain dạng <base64-chunk>.exfil.attacker.com) để vượt qua firewall vốn mặc định cho phép outbound DNS | Giám sát khối lượng query cao bất thường, độ dài/entropy query bất thường, TLD hiếm gặp, đột biến NXDOMAIN; hạn chế host nào được phép resolve ra ngoài |
| Domain hijacking / chiếm quyền registrar | Kẻ tấn công chiếm quyền kiểm soát chính việc đăng ký domain và trỏ lại DNS | Registry lock, MFA cho tài khoản registrar, giám sát WHOIS/registration |
| Typosquatting / homoglyph domain | Domain giả dạng gần giống dùng cho phishing hoặc phát tán malware | Giám sát thương hiệu, blocklist, DMARC/SPF/DKIM chống giả mạo mail |
| NXDOMAIN / DNS-based DDoS | Flood resolver với query cho các domain không tồn tại để làm cạn kiệt cache/CPU | Rate limiting, response rate limiting (RRL) trên authoritative server |
DNSSEC thêm một chuỗi chữ ký mật mã (RRSIG, DNSKEY, DS record) từ root xuống đến authoritative zone để resolver có thể xác minh response không bị giả mạo trong quá trình truyền. Nó bảo vệ tính toàn vẹn (integrity) và tính xác thực (authenticity), không bảo vệ tính bảo mật (confidentiality) — DNS query vẫn hiển thị dưới dạng plaintext trừ khi kết hợp với DNS over HTTPS (DoH) hoặc DNS over TLS (DoT).
Giám sát DNS log để bảo mật là một trong những kỹ thuật phát hiện có giá trị cao và chi phí thấp nhất:
- Tìm các mẫu beaconing: một host query cùng một domain bên ngoài theo chu kỳ cố định là dấu hiệu C2 kinh điển.
- Tìm entropy cao / subdomain label dài bất thường — dấu hiệu của DNS tunneling mã hóa dữ liệu.
- Theo dõi các domain mới xuất hiện và các domain mới đăng ký (Newly Registered Domains - NRD) — hạ tầng độc hại thường mới được đăng ký gần đây.
- Đối chiếu DNS query log với proxy/firewall log — một IP được resolve nhưng không bao giờ nhận được kết nối tiếp theo là điều đáng ngờ (có thể là exfiltration chỉ qua DNS hoặc pre-staging).
- So sánh khối lượng query trên mỗi host với baseline; đột biến thường là dấu hiệu của malware hoặc phần mềm cấu hình sai.
HTTP qua góc nhìn bảo mật
HTTP là protocol tầng application chuyên chở phần lớn traffic web, và phần lớn tấn công vào web app đều đi qua nó.
Các method và ý nghĩa bảo mật:
| Method | Mục đích | Lưu ý bảo mật |
|---|---|---|
GET | Lấy resource | Nên là safe/idempotent; không bao giờ dùng để thay đổi state (tránh state-changing GET, vốn cho phép CSRF qua thẻ image/link) |
POST | Gửi dữ liệu / tạo resource | Mục tiêu chính của CSRF; cần CSRF token hoặc cookie SameSite |
PUT / DELETE | Cập nhật / xóa resource | Cần yêu cầu authorization đúng đắn; thường bị bỏ sót khi review access-control |
OPTIONS | Khám phá method được phép/CORS preflight | Cấu hình CORS sai ở đây có thể làm lộ quyền truy cập cross-origin |
TRACE | Echo lại request | Trước đây từng bị lợi dụng cho Cross-Site Tracing (XST) để đánh cắp cookie đánh dấu HttpOnly; nên disable trên server production |
HEAD | Giống GET nhưng không có body | Hữu ích cho reconnaissance (kiểm tra resource có tồn tại mà không cần tải về) |
Các header liên quan đến bảo mật:
| Header | Mục đích |
|---|---|
Strict-Transport-Security (HSTS) | Buộc trình duyệt chỉ dùng HTTPS cho domain, ngăn chặn tấn công downgrade/sslstrip |
Content-Security-Policy (CSP) | Hạn chế script/style/origin nào được phép thực thi, giảm thiểu XSS |
X-Content-Type-Options: nosniff | Ngăn MIME-sniffing có thể biến một file upload thành nội dung có thể thực thi |
X-Frame-Options / frame-ancestors (CSP) | Ngăn clickjacking qua nhúng iframe |
Set-Cookie: ... Secure; HttpOnly; SameSite=Strict | Giới hạn cookie chỉ truyền qua HTTPS, chặn JS truy cập, giới hạn gửi cross-site |
Referrer-Policy | Kiểm soát lượng thông tin URL bị lộ ra bên thứ ba khi điều hướng |
Access-Control-Allow-Origin (CORS) | Kiểm soát truy cập cross-origin; * kết hợp với credentials là lỗi cấu hình phổ biến |
Tại sao HTTP plaintext là một rủi ro: không có TLS, mọi thứ — header, cookie, dữ liệu form, session token — đều truyền dưới dạng cleartext qua mọi chặng giữa client và server (access point Wi-Fi, ISP, transparent proxy, router độc hại). Điều này cho phép:
- Nghe lén thụ động (passive eavesdropping) — bất kỳ ai có khả năng quan sát đường truyền đều có thể đọc được session token và credential.
- Can thiệp chủ động (active tampering) — một kẻ tấn công man-in-the-middle có thể chèn JavaScript độc hại, chuyển hướng request, hoặc downgrade các security header (đây chính xác là điều mà các công cụ như
sslstriptừng khai thác trước khi HSTS preload list trở nên phổ biến). - Không có đảm bảo về tính toàn vẹn — một ISP hay router quán cà phê có thể âm thầm chèn quảng cáo hoặc tracker vào trang không mã hóa.
Đây là lý do “HTTPS everywhere” là một chuẩn cơ bản chứ không phải một tùy chọn, và tại sao HSTS preload list tồn tại để ngăn chặn ngay cả request plaintext đầu tiên.
TLS qua góc nhìn bảo mật
TLS (Transport Layer Security, kế thừa SSL) cung cấp tính bảo mật (confidentiality), tính toàn vẹn (integrity), và tính xác thực (authentication) cho dữ liệu khi truyền. Cơ chế mật mã học chi tiết (thuật toán symmetric/asymmetric, toán học key exchange, hashing) được trình bày trong Nền tảng Mật mã học; ở đây ta tập trung vào góc nhìn ở tầng network.
TLS thực sự bảo vệ điều gì:
- Confidentiality: payload được mã hóa nên người quan sát mạng không đọc được.
- Integrity: bất kỳ can thiệp nào vào dữ liệu đã mã hóa đều có thể bị phát hiện (thông qua authenticated encryption/MAC).
- Authentication: client có thể xác minh bằng mật mã rằng nó đang nói chuyện với đúng server dự định (qua xác thực chứng chỉ), và tùy chọn ngược lại (mutual TLS / mTLS).
- Điều TLS không bảo vệ: nó không che giấu việc có một kết nối xảy ra, IP đích, khối lượng/thời điểm dữ liệu gần đúng, hoặc (trước khi có ECH) tên host SNI trong hầu hết các triển khai — traffic analysis và rò rỉ metadata vẫn có thể xảy ra.
TLS 1.3 handshake đơn giản hóa:
- ClientHello — client gửi các phiên bản TLS hỗ trợ, cipher suite, và một key share.
- ServerHello — server chọn một cipher suite, gửi key share của mình, chứng chỉ, và một chữ ký chứng minh nó nắm giữ private key tương ứng với chứng chỉ đó.
- Cả hai bên tự tính ra một shared symmetric session key (qua Diffie-Hellman key exchange) mà không bao giờ truyền key đó qua mạng.
- Xác thực chứng chỉ (phía client): chứng chỉ có được ký bởi một CA đáng tin cậy không? Có nằm trong thời hạn hiệu lực không? Hostname có khớp với Subject Alternative Name (SAN) không? Đã bị thu hồi (revoke) chưa (kiểm tra qua CRL hoặc OCSP)?
- Sau khi xác thực xong, dữ liệu application được truyền dưới dạng mã hóa bằng session key đã tính ra (symmetric encryption, vì nhanh hơn nhiều so với asymmetric cho dữ liệu lớn).
TLS 1.3 (RFC 8446) đơn giản hóa so với TLS 1.2 — ít round trip hơn, loại bỏ hỗ trợ các cipher yếu đã lỗi thời, và bắt buộc forward secrecy (key của mỗi session không thể khôi phục được ngay cả khi private key dài hạn của server sau này bị lộ).
Các lỗi cấu hình TLS thường gặp cần phát hiện khi review:
| Lỗi cấu hình | Rủi ro | Cách khắc phục |
|---|---|---|
| Chứng chỉ hết hạn hoặc sắp hết hạn | Trình duyệt/client từ chối kết nối; gây outage | Tự động hóa gia hạn (ví dụ ACME/Let’s Encrypt, cert-manager trong Kubernetes), giám sát ngày hết hạn với alert |
| Chứng chỉ self-signed trên production | Không có chain tin cậy; tập cho người dùng/hệ thống thói quen bỏ qua cảnh báo | Dùng CA hợp lệ; CA nội bộ cho service chỉ dùng nội bộ với trust anchor được phân phối đúng cách |
| Bật các phiên bản protocol cũ/yếu (SSLv3, TLS 1.0/1.1) | Dễ bị tấn công đã biết (POODLE, BEAST) | Tắt mọi thứ dưới TLS 1.2, ưu tiên TLS 1.3 |
| Cipher suite yếu (RC4, export cipher, NULL cipher) | Mã hóa yếu hoặc không mã hóa dù đã dùng “HTTPS” | Giới hạn ở các cipher suite AEAD hiện đại (AES-GCM, ChaCha20-Poly1305) |
| Thiếu certificate chain (không phục vụ intermediate cert) | Một số client không xác thực được dù leaf cert hợp lệ | Phục vụ đầy đủ chain (leaf + intermediate) |
| Sai hostname / thiếu entry trong SAN | Xác thực thất bại, hoặc tệ hơn, tắt xác thực để “sửa” lỗi | Đảm bảo SAN bao phủ mọi hostname được phục vụ, kể cả wildcard nếu cần |
| Dùng sai certificate pinning / không pin khi cần | Hoặc quá dễ vỡ (pin cert xoay vòng → app hỏng) hoặc mobile app dễ bị MITM | Dùng pinning cẩn trọng với backup pin, hoặc dựa vào CA trust + giám sát Certificate Transparency |
| Không kiểm tra revocation (hoặc OCSP soft-fail) | Chứng chỉ đã bị compromise vẫn tiếp tục được tin tưởng | Dùng OCSP stapling, giám sát log Certificate Transparency |
Traffic capture và analysis, nhìn tổng quan
Khả năng đọc traffic mạng là thiết yếu trong incident response, debug, và threat hunting:
tcpdump— công cụ capture packet dạng dòng lệnh; phù hợp để filter nhanh trên server (tcpdump -i eth0 port 443).- Wireshark — công cụ deep packet inspection dạng GUI, phân tích protocol, và giải mã TLS (với session key log) phục vụ troubleshooting và forensics.
- Công cụ dựa trên flow (NetFlow/sFlow/VPC Flow Logs) — tóm tắt ai nói chuyện với ai mà không cần payload packet đầy đủ, chi phí lưu trữ rẻ hơn ở quy mô lớn, hữu ích để baseline và phát hiện bất thường.
- IDS/IPS (Suricata, Snort, Zeek) — phát hiện dựa trên signature và hành vi, chạy liên tục trên traffic.
Đây chỉ là điểm tham chiếu nhanh — cách sử dụng thực hành, cú pháp filter, và bài lab nằm trong Công cụ kiểm thử bảo mật.
VLAN và network segmentation
Tại sao segmentation quan trọng
Mạng phẳng (flat network) — nơi mọi host có thể tiếp cận mọi host khác — nghĩa là chỉ cần compromise bất kỳ một máy nào là kẻ tấn công có bàn đạp để tiếp cận mọi thứ. Segmentation giới hạn blast radius: nếu một workstation trong VLAN marketing bị compromise, nó không nên có đường đi trực tiếp đến VLAN database hay domain controller.
VLAN (Virtual LAN) cho phép một hạ tầng switch vật lý duy nhất được phân vùng logic thành nhiều broadcast domain. Traffic giữa các VLAN phải đi qua router hoặc switch Layer 3, và đó chính xác là nơi bạn có thể áp dụng ACL/firewall rule.
| Cơ chế segmentation | Layer | Trường hợp sử dụng |
|---|---|---|
| VLAN | 2 | Tách biệt broadcast domain trong cùng một LAN vật lý (ví dụ corp / guest / IoT / server) |
| Subnet/CIDR block | 3 | Tách biệt dải IP theo môi trường hoặc tầng (ví dụ 10.0.1.0/24 cho web tier, 10.0.2.0/24 cho data tier) |
| Security group / firewall rule | 3–4 | Allow-list chi tiết giữa các subnet hoặc instance (segmentation kiểu cloud-native) |
| Network namespace / CNI policy | 3–4 (ảo hóa) | Segmentation giữa các container/pod trong Kubernetes |
| Micro-segmentation / service mesh mTLS | 4–7 | Segmentation theo identity của từng workload, bất kể IP/subnet, nền tảng cốt lõi của Zero Trust |
VLAN hopping — rủi ro, và cách phòng ngừa
VLAN hopping là một kiểu tấn công trong đó một host thuộc một VLAN chiếm được quyền truy cập trái phép vào traffic của một VLAN khác mà lẽ ra nó không thể tiếp cận. Nội dung này được mô tả thuần túy để phục vụ phòng thủ, không nhằm cung cấp playbook tấn công.
Hai cơ chế kinh điển:
- Switch spoofing: host của kẻ tấn công đàm phán một trunk link với switch bằng cách giả dạng một switch (lợi dụng các giao thức auto-trunking như Dynamic Trunking Protocol). Sau khi trở thành trunk, host của kẻ tấn công thấy được traffic đã tag của tất cả VLAN trên trunk đó.
- Double tagging: kẻ tấn công gắn thêm hai tag VLAN 802.1Q vào một frame. Switch đầu tiên bóc lớp tag ngoài (khớp với native VLAN) rồi forward frame, mà tag thứ hai của nó giờ đây định tuyến frame vào một VLAN khác với dự định ban đầu — cách này chỉ hoạt động khi port của kẻ tấn công chia sẻ chung native VLAN với trunk.
Biện pháp phòng thủ:
- Tắt auto-trunking/DTP trên access port; cấu hình rõ ràng port là access hoặc trunk, không bao giờ để “auto negotiate.”
- Không bao giờ dùng VLAN 1 (native/default VLAN trên hầu hết switch) cho bất kỳ traffic thực nào; đổi native VLAN trên trunk sang một ID không sử dụng.
- Đảm bảo native VLAN trên trunk port không trùng với bất kỳ VLAN nào mang traffic người dùng (ngăn double-tagging).
- Prune (loại bỏ) các VLAN không sử dụng khỏi trunk link (không cho phép mọi VLAN đi qua mọi trunk theo mặc định).
- Dùng port security (giới hạn/khóa địa chỉ MAC theo từng port) để giảm cơ hội giả mạo.
- Xem VLAN như một ranh giới tiện lợi, không phải một ranh giới bảo mật vững chắc tự thân — kết hợp chúng với ACL/firewall Layer 3 và, nếu khả thi, micro-segmentation hoặc service mesh, vì tag VLAN không mang bất kỳ đảm bảo mật mã nào.
Network zone — góc nhìn liên quan đến bảo mật
| Zone | Mô tả | Nội dung điển hình | Mức độ tin cậy |
|---|---|---|---|
| Perimeter | Ranh giới giữa mạng của bạn và internet | Edge router, firewall perimeter, DDoS scrubbing | Không tin cậy bên ngoài, kiểm soát bên trong |
| DMZ (Demilitarized Zone) | Một segment đệm, lộ ra internet nhưng cách ly khỏi mạng nội bộ | Web server public, reverse proxy, mail relay, VPN endpoint | Bán tin cậy; giả định bị tấn công trực tiếp |
| Internal / trusted network | Nơi các service nội bộ, workstation nhân viên, và hệ thống back-office hoạt động | App server, internal API, endpoint doanh nghiệp | Tin cậy, nhưng không tin tuyệt đối (xem Zero Trust bên dưới) |
| Restricted / data tier | Segment nhạy cảm cao nhất | Database, secrets store, HSM, domain controller | Rất tin cậy, hạn chế truy cập trực tiếp, audit kỹ lưỡng |
Kiến trúc kinh điển đặt các service hướng ra internet trong DMZ, với firewall giữa internet↔DMZ và DMZ↔internal, để một host DMZ bị compromise không thể trực tiếp tiếp cận mạng nội bộ hay data tier. Thực tiễn hiện đại ngày càng thay thế mô hình tin cậy dựa trên perimeter (“nếu bạn ở trong mạng, bạn được tin cậy”) bằng Zero Trust — xác minh mọi request bất kể vị trí mạng, dựa trên identity và tình trạng thiết bị (device posture) thay vì bạn đang ở subnet nào. Nội dung đầy đủ về thiết kế zone, micro-segmentation, và kiến trúc Zero Trust nằm trong Bảo mật mạng & Zero Trust.
Best Practices
- Default deny: firewall, security group, và network ACL nên mặc định từ chối mọi traffic và chỉ cho phép các luồng được yêu cầu rõ ràng — cho cả ingress và egress.
- Segment theo mức độ tin cậy và độ nhạy cảm, không phải theo sự tiện lợi: đừng đặt web tier public và database production trong cùng một subnet chỉ vì deploy dễ hơn.
- Xem DNS log là một nguồn telemetry bảo mật hạng nhất — thu thập rẻ, tín hiệu cao để phát hiện C2/exfiltration.
- Bật DNSSEC cho các domain bạn sở hữu và xác thực nó trên các resolver bạn kiểm soát, nếu khả thi.
- Bắt buộc HTTPS everywhere: redirect HTTP sang HTTPS, đặt HSTS với max-age dài, và đăng ký các domain đủ điều kiện vào HSTS preload list.
- Tự động hóa vòng đời chứng chỉ TLS: dùng cấp phát dựa trên ACME (Let’s Encrypt, ACME CA nội bộ) và cert-manager (Kubernetes) thay vì gia hạn thủ công, và cảnh báo sớm trước khi hết hạn.
- Tắt các protocol và cipher lỗi thời: không SSLv3/TLS 1.0/1.1, không cipher RC4/export/NULL; ưu tiên TLS 1.3 với cipher AEAD.
- Không bao giờ chỉ dựa vào VLAN như một ranh giới bảo mật duy nhất — kết hợp với ACL Layer 3/4 và, với các segment giá trị cao, micro-segmentation dựa trên identity.
- Tắt VLAN auto-negotiation trên access port và không bao giờ dùng VLAN mặc định/native cho traffic production.
- Trang bị flow log (VPC Flow Logs, NetFlow) qua các ranh giới zone để traffic cross-zone luôn có thể quan sát được, ngay cả khi không có full packet capture.
- Review cả egress, không chỉ ingress: các đường exfiltration (DNS tunneling, outbound HTTPS không giới hạn đến host tùy ý) thường bị bỏ ngỏ trong khi ingress lại được chú ý hết mức.
- Ánh xạ mỗi port/protocol mở với một lý do nghiệp vụ cụ thể: nếu không thể giải thích tại sao một port đang mở, nó nên được đóng lại.
Tài liệu tham khảo
- RFC 1918 — Address Allocation for Private Internets
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
- RFC 4033 — DNS Security Introduction and Requirements (DNSSEC)
- RFC 6960 — Online Certificate Status Protocol (OCSP)
- Cloudflare Learning Center — What Happens in a TLS Handshake?
- Cloudflare Learning Center — What is DNS?
- Cloudflare Learning Center — What is DNS Tunneling?
- Cloudflare Learning Center — VLAN Hopping
Xem thêm: Network Engineer knowledge base · Nền tảng Mật mã học · Bảo mật mạng & Zero Trust · Công cụ kiểm thử bảo mật
Part of the DevSecOps Roadmap knowledge base.
Overview
Every security control eventually sits on top of a network: a firewall rule, a TLS handshake, a segmentation boundary, a DNS query that either resolves to your service or to an attacker’s server. If you don’t understand how packets actually move — what a SYN flag means, why a TTL of 1 matters, what a resolver does when it can’t find a cached record — you cannot reason about why an attack works or why a control stops it. Attack surface is, in large part, network surface: every open port, every exposed protocol, every trust relationship between network zones is a place where something can go wrong.
This note is a security-lens refresher, not a full networking course. It assumes you’ve seen OSI layers and IP addressing before and re-frames them around the question “where can this be attacked, and how do we defend it?” For networking depth (routing protocols, switching, wireless, QoS, network automation, certifications), see Network Engineer knowledge base. For the cryptography behind TLS, see Cryptography Fundamentals. For designing zones and Zero Trust architectures, see Network Security & Zero Trust. For hands-on packet capture tools, see Security Testing Tools.
Why this matters day-to-day for a DevSecOps engineer:
- You review firewall/security-group rules and need to know what a port and protocol actually expose.
- You triage an alert that says “DNS query to a suspicious domain” and need to know what that could mean.
- You review an ingress/TLS configuration and need to spot an expired cert or a weak cipher before it ships.
- You design network segmentation for a Kubernetes cluster or VPC and need to reason about blast radius.
- You read a pcap or a
tcpdumpcapture during an incident and need to recognize what’s normal versus what’s an exfiltration attempt.
Fundamentals
OSI and TCP/IP models, at a glance
| OSI Layer | Name | TCP/IP Layer | Examples | Security relevance |
|---|---|---|---|---|
| 7 | Application | Application | HTTP, DNS, SMTP, SSH | Where most modern attacks live (injection, auth bypass, malware C2) |
| 6 | Presentation | Application | TLS/SSL, encoding | Encryption/decryption, certificate validation |
| 5 | Session | Application | Sessions, TLS handshake | Session hijacking, token theft |
| 4 | Transport | Transport | TCP, UDP | Port scanning, SYN floods, segment spoofing |
| 3 | Network | Internet | IP, ICMP, routing | IP spoofing, routing attacks, subnetting/segmentation |
| 2 | Data Link | Network Access | Ethernet, VLAN, ARP | ARP spoofing, VLAN hopping, MAC flooding |
| 1 | Physical | Network Access | Cables, radio, fiber | Physical tapping, wiretapping, jamming |
Security-relevant habit: when you see an alert or a rule, immediately ask “which layer is this?” A WAF rule operates at layer 7. A security group rule is usually layers 3–4 (IP + port). A VLAN misconfiguration is layer 2. Knowing the layer tells you which tool and which mitigation is relevant.
IP addressing and subnetting, in brief
- An IPv4 address is 32 bits, written as four octets (
10.0.1.15). A subnet mask (or CIDR suffix, e.g./24) splits it into a network portion and a host portion. 10.0.1.0/24means the first 24 bits are the network; 256 addresses (254 usable) belong to that subnet.- Private ranges (RFC 1918):
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16— not routable on the public internet, commonly used inside VPCs and internal networks. - Why this matters for security: subnet boundaries are the cheapest, oldest form of network segmentation. A host in one subnet cannot reach a host in another subnet unless a router/firewall explicitly allows it. Getting subnetting wrong (e.g., putting a database and a public web server in the same
/24with no ACL between them) silently removes a layer of defense. - IPv6 uses 128-bit addresses and no NAT by design — every device can be globally reachable, which changes the security calculus: perimeter firewalls and host-based filtering become more important than “hiding behind NAT.”
This note deliberately stops here — full subnetting math, VLSM, routing tables, and switching are covered in depth in Network Engineer — IP Addressing and Subnetting and Network Engineer — Network Models and Layers.
TCP vs UDP — quick security framing
| TCP | UDP | |
|---|---|---|
| Connection | Connection-oriented (3-way handshake: SYN, SYN-ACK, ACK) | Connectionless |
| Reliability | Guaranteed delivery, ordering | Best-effort, no guarantees |
| Common uses | HTTP/HTTPS, SSH, database connections | DNS, VoIP, QUIC/HTTP3, streaming |
| Common attacks | SYN flood, TCP hijacking, port scanning | UDP flood, amplification attacks (DNS/NTP/memcached) |
Because UDP has no handshake, an attacker can trivially spoof the source IP and use tiny requests to make a server send large responses to a victim — this is the basis of most DDoS amplification attacks (DNS amplification, NTP amplification, memcached amplification).
Key Concepts
DNS through a security lens
DNS is the phonebook of the internet — and phonebooks can be tampered with.
How it works (simplified resolution path):
- Client asks a recursive resolver (e.g., an ISP resolver, 8.8.8.8, or an internal corporate resolver) for
app.example.com. - If not cached, the resolver asks a root server → gets referred to the
.comTLD server → gets referred toexample.com’s authoritative name server. - The authoritative server returns the IP (an A/AAAA record, or a CNAME chain that eventually resolves to one).
- The resolver caches the answer for the record’s TTL and returns it to the client.
Common DNS-based attacks:
| Attack | What happens | Defense |
|---|---|---|
| DNS spoofing / cache poisoning | Attacker injects a forged response into a resolver’s cache, redirecting a domain to an attacker-controlled IP | DNSSEC, randomized query IDs/source ports, resolvers that validate responses |
| DNS tunneling (exfiltration/C2) | Data is encoded into DNS queries/responses (e.g., subdomains like <base64-chunk>.exfil.attacker.com) to bypass firewalls that allow outbound DNS by default | Monitor for high query volume, unusual query length/entropy, rare TLDs, NXDOMAIN spikes; restrict which hosts may resolve externally |
| Domain hijacking / registrar takeover | Attacker gains control of the domain registration itself and repoints DNS | Registry lock, MFA on registrar accounts, WHOIS/registration monitoring |
| Typosquatting / homoglyph domains | Look-alike domains used for phishing or malware distribution | Brand monitoring, blocklists, DMARC/SPF/DKIM for mail spoofing |
| NXDOMAIN / DNS-based DDoS | Flooding resolvers with queries for non-existent domains to exhaust cache/CPU | Rate limiting, response rate limiting (RRL) on authoritative servers |
DNSSEC adds a chain of cryptographic signatures (RRSIG, DNSKEY, DS records) from the root down to the authoritative zone so a resolver can verify a response wasn’t forged in transit. It protects integrity and authenticity, not confidentiality — DNS queries are still visible in plaintext unless combined with DNS over HTTPS (DoH) or DNS over TLS (DoT).
Monitoring DNS logs for security is one of the highest-value, lowest-cost detections available:
- Look for beaconing patterns: a host that queries the same external domain at a fixed interval is a classic C2 signature.
- Look for high entropy / long subdomain labels — a sign of DNS tunneling encoding data.
- Track newly observed domains and newly registered domains (NRDs) — malicious infrastructure is often very recently registered.
- Correlate DNS query logs with proxy/firewall logs — a resolved IP that never receives a follow-up connection is suspicious (could indicate DNS-only exfiltration or pre-staging).
- Compare query volume per host against a baseline; sudden spikes often indicate malware or misconfigured software.
HTTP through a security lens
HTTP is the application-layer protocol carrying most web traffic, and most attacks against web apps ride on top of it.
Methods and their security implications:
| Method | Purpose | Security note |
|---|---|---|
GET | Retrieve a resource | Should be safe/idempotent; never used to mutate state (avoid state-changing GETs, which enable CSRF via image tags/links) |
POST | Submit data / create resource | Primary CSRF target; needs CSRF tokens or SameSite cookies |
PUT / DELETE | Update / remove resource | Should require proper authorization; often forgotten in access-control reviews |
OPTIONS | Discover allowed methods/CORS preflight | Misconfigured CORS here can leak cross-origin access |
TRACE | Echoes the request back | Historically enabled Cross-Site Tracing (XST) to steal cookies marked HttpOnly; should be disabled on production servers |
HEAD | Like GET, no body | Useful for reconnaissance (checking resource existence without downloading it) |
Security-relevant headers:
| Header | Purpose |
|---|---|
Strict-Transport-Security (HSTS) | Forces browsers to only use HTTPS for the domain, preventing downgrade/sslstrip attacks |
Content-Security-Policy (CSP) | Restricts which scripts/styles/origins can execute, mitigating XSS |
X-Content-Type-Options: nosniff | Prevents MIME-sniffing that can turn a data upload into executable content |
X-Frame-Options / frame-ancestors (CSP) | Prevents clickjacking via iframe embedding |
Set-Cookie: ... Secure; HttpOnly; SameSite=Strict | Restricts cookie transmission to HTTPS, blocks JS access, limits cross-site sending |
Referrer-Policy | Controls how much URL information leaks to third parties on navigation |
Access-Control-Allow-Origin (CORS) | Controls cross-origin access; * combined with credentials is a common misconfiguration |
Why plaintext HTTP is a risk: without TLS, everything — headers, cookies, form data, session tokens — travels as cleartext over every hop between client and server (Wi-Fi access points, ISPs, transparent proxies, malicious routers). This enables:
- Passive eavesdropping — anyone with visibility into the path can read session tokens and credentials.
- Active tampering — a man-in-the-middle can inject malicious JavaScript, redirect requests, or downgrade security headers (this is exactly what tools like
sslstriphistorically exploited before HSTS preload lists became widespread). - No integrity guarantee — an ISP or coffee-shop router can silently inject ads or trackers into unencrypted pages.
This is why “HTTPS everywhere” is a baseline, not a nice-to-have, and why HSTS preload lists exist to prevent even the very first plaintext request.
TLS through a security lens
TLS (Transport Layer Security, successor to SSL) provides confidentiality, integrity, and authentication for data in transit. Deep cryptographic mechanics (symmetric/asymmetric algorithms, key exchange math, hashing) are covered in Cryptography Fundamentals; here we focus on the network-level view.
What TLS actually protects:
- Confidentiality: payload is encrypted so a network observer can’t read it.
- Integrity: any tampering with the encrypted data is detectable (via authenticated encryption/MACs).
- Authentication: the client can cryptographically verify it’s talking to the server it intended to (via certificate validation), and optionally vice versa (mutual TLS / mTLS).
- What TLS does not protect: it does not hide that a connection happened, the destination IP, approximate data volume/timing, or (pre-ECH) the SNI hostname in most deployments — traffic analysis and metadata leakage are still possible.
Simplified TLS 1.3 handshake:
- ClientHello — client sends supported TLS versions, cipher suites, and a key share.
- ServerHello — server picks a cipher suite, sends its key share, certificate, and a signature proving it holds the private key for that certificate.
- Both sides derive a shared symmetric session key (via Diffie-Hellman key exchange) without ever transmitting it.
- Certificate validation (client-side): is the cert signed by a trusted CA? Is it within its validity window? Does the hostname match the Subject Alternative Name (SAN)? Has it been revoked (checked via CRL or OCSP)?
- Once validated, application data flows encrypted using the derived session key (symmetric encryption, since it’s much faster than asymmetric for bulk data).
TLS 1.3 (RFC 8446) simplified this compared to TLS 1.2 — fewer round trips, removed support for legacy weak ciphers, and made forward secrecy mandatory (each session’s key can’t be recovered even if the server’s long-term private key is later compromised).
Common TLS misconfigurations to catch in review:
| Misconfiguration | Risk | Fix |
|---|---|---|
| Expired or soon-to-expire certificate | Browsers/clients reject connections; outages | Automate renewal (e.g., ACME/Let’s Encrypt, cert-manager in Kubernetes), monitor expiry with alerts |
| Self-signed cert in production | No trust chain; trains users/systems to ignore warnings | Use a proper CA; internal CA for internal-only services with distributed trust anchors |
| Weak/legacy protocol versions enabled (SSLv3, TLS 1.0/1.1) | Vulnerable to known attacks (POODLE, BEAST) | Disable everything below TLS 1.2, prefer TLS 1.3 |
| Weak cipher suites (RC4, export ciphers, NULL ciphers) | Weak or no encryption despite “HTTPS” | Restrict to modern AEAD cipher suites (AES-GCM, ChaCha20-Poly1305) |
| Missing certificate chain (intermediate cert not served) | Some clients fail to validate even though the leaf cert is valid | Serve the full chain (leaf + intermediates) |
| Hostname mismatch / missing SAN entries | Validation failures, or worse, disabled validation to “fix” it | Ensure SAN covers all served hostnames, including wildcards where needed |
| Certificate pinning misuse / no pinning where needed | Either overly brittle (pinned cert rotates → app breaks) or MITM-susceptible mobile apps | Use pinning judiciously with backup pins, or rely on CA trust + CT monitoring |
| No revocation checking (or soft-fail OCSP) | A compromised cert continues to be trusted | Use OCSP stapling, monitor Certificate Transparency logs |
Traffic capture and analysis, at a glance
Being able to read network traffic is essential during incident response, debugging, and threat hunting:
tcpdump— command-line packet capture; good for quick filters on a server (tcpdump -i eth0 port 443).- Wireshark — GUI-based deep packet inspection, protocol dissection, and TLS decryption (with session key logs) for troubleshooting and forensics.
- Flow-based tools (NetFlow/sFlow/VPC Flow Logs) — summarize who talked to whom without full packet payloads, cheaper to store at scale, useful for baselining and anomaly detection.
- IDS/IPS (Suricata, Snort, Zeek) — signature- and behavior-based detection running continuously against traffic.
This is only an at-a-glance pointer — hands-on usage, filter syntax, and lab exercises live in Security Testing Tools.
VLANs and network segmentation
Why segmentation matters
Flat networks — where every host can reach every other host — mean that compromising any single machine gives an attacker a launching pad to reach everything. Segmentation limits blast radius: if a workstation in the marketing VLAN is compromised, it should not have a direct path to the database VLAN or the domain controller.
VLANs (Virtual LANs) let a single physical switch infrastructure be logically partitioned into multiple broadcast domains. Traffic between VLANs must pass through a router or Layer 3 switch, which is exactly where you can enforce ACLs/firewall rules.
| Segmentation mechanism | Layer | Use case |
|---|---|---|
| VLAN | 2 | Separate broadcast domains within the same physical LAN (e.g., corp / guest / IoT / servers) |
| Subnet/CIDR block | 3 | Separate IP ranges per environment or tier (e.g., 10.0.1.0/24 for web tier, 10.0.2.0/24 for data tier) |
| Security group / firewall rule | 3–4 | Fine-grained allow-lists between subnets or instances (cloud-native segmentation) |
| Network namespace / CNI policy | 3–4 (virtualized) | Segmentation between containers/pods in Kubernetes |
| Micro-segmentation / service mesh mTLS | 4–7 | Per-workload identity-based segmentation regardless of IP/subnet, core to Zero Trust |
VLAN hopping — the risk, and how to prevent it
VLAN hopping is an attack where a host on one VLAN gains unauthorized access to traffic on another VLAN it should not be able to reach. It is described here purely to inform defense, not to provide an attack playbook.
The two classic mechanisms:
- Switch spoofing: an attacker’s host negotiates a trunk link with a switch by mimicking a switch (abusing auto-trunking protocols like Dynamic Trunking Protocol). Once trunked, the attacker’s host sees tagged traffic for all VLANs on that trunk.
- Double tagging: an attacker prepends two 802.1Q VLAN tags to a frame. The first switch strips the outer tag (matching the native VLAN) and forwards the frame, whose second tag now routes it into a different VLAN than intended — this only works when the attacker’s port shares a native VLAN with the trunk.
Defensive measures:
- Disable auto-trunking/DTP on access ports; explicitly configure ports as access or trunk, never “auto negotiate.”
- Never use VLAN 1 (the default/native VLAN on most switches) for any real traffic; change the native VLAN on trunks to an unused ID.
- Ensure the native VLAN on trunk ports is not the same as any VLAN carrying user traffic (prevents double-tagging).
- Prune unused VLANs from trunk links (don’t allow every VLAN across every trunk by default).
- Use port security (limit/lock MAC addresses per port) to reduce spoofing opportunities.
- Treat VLANs as a convenience boundary, not a hard security boundary on their own — pair them with Layer 3 ACLs/firewalls and, where feasible, micro-segmentation or a service mesh, since VLAN tags carry no cryptographic guarantee.
Network zones — a security-relevant view
| Zone | Description | Typical contents | Trust level |
|---|---|---|---|
| Perimeter | The boundary between your network and the internet | Edge routers, perimeter firewalls, DDoS scrubbing | Untrusted outside, controlled inside |
| DMZ (Demilitarized Zone) | A buffer segment exposed to the internet but isolated from the internal network | Public-facing web servers, reverse proxies, mail relays, VPN endpoints | Semi-trusted; assumed to be attacked directly |
| Internal / trusted network | Where internal services, employee workstations, and back-office systems live | App servers, internal APIs, corporate endpoints | Trusted, but not blindly (see Zero Trust below) |
| Restricted / data tier | Highest-sensitivity segment | Databases, secrets stores, HSMs, domain controllers | Highly trusted, minimal direct access, heavily audited |
The classic architecture places internet-facing services in the DMZ, with firewalls between internet↔DMZ and DMZ↔internal, so that a compromised DMZ host cannot directly reach the internal network or data tier. Modern practice increasingly replaces perimeter-based trust (“if you’re inside the network, you’re trusted”) with Zero Trust — verify every request regardless of network location, based on identity and device posture rather than which subnet you’re sitting in. Full coverage of zone design, micro-segmentation, and Zero Trust architecture is in Network Security & Zero Trust.
Best Practices
- Default deny: firewalls, security groups, and network ACLs should deny all traffic by default and allow only explicitly required flows — for both ingress and egress.
- Segment by trust and sensitivity, not convenience: don’t put a public web tier and a production database in the same subnet just because it’s simpler to deploy.
- Treat DNS logs as a first-class security telemetry source — cheap to collect, high signal for C2/exfiltration detection.
- Enable DNSSEC on domains you own and validate it on resolvers you control, where feasible.
- Enforce HTTPS everywhere: redirect HTTP to HTTPS, set HSTS with a long max-age, and submit eligible domains to HSTS preload lists.
- Automate TLS certificate lifecycle: use ACME-based issuance (Let’s Encrypt, internal ACME CAs) and cert-manager (Kubernetes) rather than manual renewal, and alert well before expiry.
- Disable legacy protocols and ciphers: no SSLv3/TLS 1.0/1.1, no RC4/export/NULL ciphers; prefer TLS 1.3 with AEAD ciphers.
- Never rely on VLANs alone as a security boundary — pair with Layer 3/4 ACLs and, for high-value segments, identity-based micro-segmentation.
- Disable VLAN auto-negotiation on access ports and never use the default/native VLAN for production traffic.
- Instrument flow logs (VPC Flow Logs, NetFlow) across zone boundaries so cross-zone traffic is always observable, even without full packet capture.
- Review egress, not just ingress: exfiltration paths (DNS tunneling, unrestricted outbound HTTPS to arbitrary hosts) are often left wide open while ingress gets all the attention.
- Map every open port/protocol to a business justification: if you can’t say why a port is open, it should be closed.
References
- RFC 1918 — Address Allocation for Private Internets
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
- RFC 4033 — DNS Security Introduction and Requirements (DNSSEC)
- RFC 6960 — Online Certificate Status Protocol (OCSP)
- Cloudflare Learning Center — What Happens in a TLS Handshake?
- Cloudflare Learning Center — What is DNS?
- Cloudflare Learning Center — What is DNS Tunneling?
- Cloudflare Learning Center — VLAN Hopping
See also: Network Engineer knowledge base · Cryptography Fundamentals · Network Security & Zero Trust · Security Testing Tools