Cyber 101 · บทที่ 8
การป้องกันและ Hardening (Blue Team)
Blue Team คือใคร ต่างจาก Red Team อย่างไร
ตลอดเจ็ดบทที่ผ่านมาเราฝึกมองระบบด้วยสายตาของผู้โจมตี เพื่อจะได้อุดช่องก่อนถูกเจาะ บทนี้เราสลับหมวก มาสวมบทบาทของคนที่ต้อง "ตั้งรับ" และดูแลระบบให้ปลอดภัยในระยะยาว ในวงการความปลอดภัยเราแบ่งทีมออกเป็นสองสีหลักตามหน้าที่ และการเข้าใจว่าแต่ละฝั่งคิดอย่างไรจะทำให้คุณเป็นทั้งผู้โจมตีและผู้ป้องกันที่เก่งขึ้นพร้อมกัน
Red Team (สายบุก)
จำลองเป็นผู้โจมตีจริง หาช่องโหว่ ทดสอบเจาะระบบตามขอบเขตที่ตกลงไว้ เพื่อพิสูจน์ว่าเกราะป้องกันเอาอยู่จริงไหม ทำเมื่อได้รับอนุญาตเป็นลายลักษณ์อักษรเท่านั้น
Blue Team (สายรับ)
ฝ่ายป้องกัน คอยเฝ้าระวัง อ่าน log ตรวจจับความผิดปกติ อุดช่องโหว่ ทำ hardening และรับมือเมื่อเกิดเหตุ งานส่วนใหญ่ในองค์กรจริงคืองานสายนี้
Purple Team (สายผสาน)
ไม่ใช่ทีมถาวร แต่เป็นวิธีทำงานที่ให้สายบุกและสายรับแลกความรู้กัน สายบุกโจมตี สายรับดูว่าจับได้ไหม แล้วปรับเกราะให้ดีขึ้นเป็นวงจร
งานประจำวันของ Blue Team
คนสายป้องกันทำงานเชิงรุกทุกวัน ได้แก่ เฝ้าดู log และการแจ้งเตือน (monitoring), ดูว่าระบบอัปเดตครบไหม (patching), ทำ hardening ปิดสิ่งที่ไม่จำเป็น, ซ้อมแผนรับเหตุ (incident response) และทบทวนสิทธิการเข้าถึงให้เหลือเท่าที่จำเป็น หัวใจของสายนี้คือ ผู้โจมตีพลาดกี่ครั้งก็ได้ แต่ผู้ป้องกันพลาดครั้งเดียวก็เสียหาย เราจึงต้องคิดเป็นระบบ ไม่ฝากความปลอดภัยไว้กับกำแพงชั้นเดียว
⚠️ จริยธรรมและกฎหมาย
งานสายป้องกันดูปลอดภัยกว่าสายบุก แต่ก็มีเส้นที่ต้องระวัง เครื่องมือเฝ้าระวัง อ่าน log หรือสแกนช่องโหว่ ต้องใช้กับระบบที่คุณเป็นเจ้าของหรือได้รับมอบหมายให้ดูแลเท่านั้น การไปเฝ้าระวังหรือสแกนระบบของคนอื่นโดยไม่ได้รับอนุญาตก็ยังเข้าข่ายเข้าถึงระบบโดยมิชอบตาม พ.ร.บ.ว่าด้วยการกระทำผิดเกี่ยวกับคอมพิวเตอร์ เช่นกัน ข้อความนี้เป็นความรู้ทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย
อ่าน Log ตรวจจับความผิดปกติ และรับมือเมื่อเกิดเหตุ
ผู้บุกรุกมักทิ้งร่องรอยไว้ใน log เสมอ ทักษะแรกของ blue team คือเปลี่ยน log ดิบจำนวนมหาศาลให้กลายเป็นสัญญาณที่คนอ่านออก เพื่อจับความผิดปกติให้ทันก่อนความเสียหายจะบานปลาย และเมื่อจับได้จริงแล้ว ต้องรู้ด้วยว่าจะรับมืออย่างเป็นขั้นตอนอย่างไร
สัญญาณผิดปกติที่ควรจับตาใน log
เราต้องรู้ว่า "หน้าตาของการโจมตีใน log" เป็นอย่างไร ที่พบบ่อยได้แก่ การล็อกอินล้มเหลวจำนวนมากในเวลาสั้นจาก IP เดียว (สัญญาณ brute force), การเข้าถึงไฟล์หรือหน้าที่ผู้ใช้ทั่วไปไม่ควรแตะ, คำสั่งแปลก ๆ ที่โผล่ในเวลาที่ไม่มีใครทำงาน และที่ร้ายที่สุดคือ log ที่หายเป็นช่วงหรือถูกลบ เพราะสิ่งแรก ๆ ที่ผู้บุกรุกทำหลังเข้าได้คือลบร่องรอยตัวเอง
สรุปการล็อกอินล้มเหลวแยกตาม IP จาก log ของเครื่องเราเอง
from collections import Counter
fails = Counter()
for line in open("auth.log"):
if "Failed password" in line:
ip = line.split("from ")[1].split()[0]
fails[ip] += 1
for ip, n in fails.most_common(5):
print(ip, n) # IP ที่พลาดถี่ผิดปกติ = ควรสงสัย🛡️ วิธีป้องกัน: ทำให้ log เชื่อถือได้และมีคนดู
log จะมีค่าก็ต่อเมื่อครบถ้วนและมีคนเฝ้า ทำสี่อย่างนี้: (1) ส่ง log ออกไปเก็บที่ส่วนกลางที่ผู้บุกรุกในเครื่องต้นทางแก้ไม่ได้ เพื่อกันการลบร่องรอย (2) ตั้ง baseline ว่า "ปกติ" หน้าตาเป็นอย่างไร ความผิดปกติจะได้เด่นขึ้นมาเอง (3) ตั้งการแจ้งเตือนอัตโนมัติเมื่อค่าทะลุเกณฑ์ เช่น ล็อกอินพลาดเกิน N ครั้ง (4) ตั้งเวลาให้ตรงกันทุกเครื่อง (NTP) เพื่อให้ไล่ลำดับเหตุการณ์ข้ามเครื่องได้ถูกต้อง
Incident Response: ขั้นตอนรับมือเมื่อเกิดเหตุ
เมื่อสงสัยว่าถูกเจาะ อย่าเพิ่งลนลานปิดเครื่อง กรอบมาตรฐานที่ใช้กันทั่วโลกมีหกขั้นเรียงกัน จำง่าย ๆ ว่า เตรียม จับ กัน กำจัด กู้ ทบทวน
| ขั้น | ทำอะไร |
|---|---|
| 1. เตรียมพร้อม (Preparation) | มีแผน มีทีม มี log และเครื่องมือพร้อมก่อนเกิดเหตุ |
| 2. ตรวจจับและวิเคราะห์ (Identification) | ยืนยันว่าเกิดเหตุจริง ขอบเขตแค่ไหน กระทบอะไรบ้าง |
| 3. จำกัดวง (Containment) | ตัดการลุกลาม เช่น แยกเครื่องออกจากเครือข่าย โดยยังเก็บหลักฐานไว้ |
| 4. กำจัด (Eradication) | ถอนสิ่งแปลกปลอมและอุดช่องโหว่ต้นเหตุออกให้หมด |
| 5. กู้คืน (Recovery) | นำระบบกลับมาใช้อย่างระวัง พร้อมเฝ้าดูว่าจะกลับมาอีกไหม |
| 6. ถอดบทเรียน (Lessons learned) | ทบทวนว่าเกิดได้อย่างไร แล้วปรับปรุงเพื่อไม่ให้ซ้ำ |
จุดที่มือใหม่มักพลาดคือรีบ "กู้คืน" ก่อน "จำกัดวง" ทำให้ผู้บุกรุกยังอยู่ในระบบ หรือรีบล้างเครื่องจนหลักฐานหายหมด สองขั้นนี้ต้องระวังเป็นพิเศษ
🧪 ลองในแล็บของคุณ
ใน VM แล็บของคุณ ลองเปิด log จริงของเครื่องตัวเอง เช่น auth.log บน Linux แล้วรันสคริปต์นับ IP ด้านบน จากนั้นจงใจล็อกอิน SSH ผิดหลาย ๆ ครั้งเข้าเครื่องแล็บของคุณเอง แล้วดูว่าบรรทัดใหม่โผล่ใน log อย่างไร และสคริปต์จับ IP ของคุณได้ไหม ต่อยอดด้วยการเขียนเงื่อนไขให้พิมพ์คำเตือนเมื่อ IP ใดพลาดเกินสิบครั้ง ทำทั้งหมดบนเครื่องของคุณเองเท่านั้น
⚠️ จริยธรรมและกฎหมาย
log มักมีข้อมูลส่วนบุคคล เช่น IP ชื่อผู้ใช้ หรือเวลาเข้าใช้งาน จึงอยู่ภายใต้ พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล (PDPA) ให้เก็บเท่าที่จำเป็น กำหนดอายุการเก็บ และจำกัดคนที่เข้าถึงได้ การนำ log ของผู้อื่นมาวิเคราะห์โดยไม่มีสิทธิ หรือเปิดเผยข้อมูลในนั้น อาจผิดทั้ง PDPA และกฎหมายคอมพิวเตอร์ เป็นความรู้ทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย
Secure Coding, Dependency และการจัดการ Secret
ช่องโหว่จำนวนมากไม่ได้เกิดตอนถูกโจมตี แต่เกิดตั้งแต่ตอนเขียนโค้ด สายป้องกันที่ดีจึงต้องขยับเข้าไปช่วยตั้งแต่ต้นน้ำ ทั้งเช็กลิสต์ตอนเขียน การดูแลไลบรารีที่เราหยิบมาใช้ และการเก็บความลับให้ไม่หลุด
Secure Coding Checklist ฉบับย่อ
รวมบทก่อน ๆ เป็นรายการที่ควรตรวจก่อนปล่อยโค้ด: กรอง input ทุกทางเข้า, ใช้ parameterized query กัน SQL injection, encode output กัน XSS, ตรวจสิทธิฝั่งเซิร์ฟเวอร์เสมอไม่เชื่อฝั่งผู้ใช้, เก็บรหัสผ่านด้วย bcrypt หรือ argon2, ไม่ปล่อยข้อความ error ละเอียดออกไปหาผู้ใช้ และตั้งค่าพื้นฐานให้ปลอดภัยไว้ก่อน (secure by default) การมีเช็กลิสต์ทำให้ความปลอดภัยไม่ขึ้นกับว่าวันนั้นใครเป็นคนเขียน
Dependency: ช่องโหว่ที่มากับของที่เรายืมมาใช้
โปรเจกต์สมัยนี้ประกอบด้วยไลบรารีของคนอื่นเป็นร้อยตัว ถ้าตัวใดมีช่องโหว่ที่ประกาศต่อสาธารณะแล้ว (CVE) ผู้โจมตีก็แค่รอเจอเว็บที่ยังใช้เวอร์ชันเก่า นี่คือความเสี่ยงสาย supply chain เราไม่ต้องรู้วิธีเจาะ แค่ต้องรู้ว่าของเรามีตัวไหนเก่าและเสี่ยง
คำสั่งตรวจไลบรารีเสี่ยงในโปรเจกต์ของเราเอง
npm audit # โปรเจกต์ Node.js
pip-audit # โปรเจกต์ Python
# อ่านผลแล้วอัปเดตตัวที่มีช่องโหว่ตามที่เครื่องมือแนะนำ🛡️ วิธีป้องกัน: ดูแล dependency ให้เป็นวินัย
(1) รัน npm audit หรือ pip-audit เป็นประจำ และเสียบเข้าไปในขั้นตอน build อัตโนมัติ (2) ล็อกเวอร์ชันด้วยไฟล์ lock เพื่อให้ทุกเครื่องได้ของชุดเดียวกัน (3) อัปเดตสม่ำเสมอทีละน้อย ดีกว่ารอค้างจนต้องกระโดดข้ามหลายเวอร์ชันทีเดียว (4) หยิบไลบรารีเท่าที่จำเป็น เพราะยิ่งพึ่งของนอกน้อย พื้นที่เสี่ยงยิ่งเล็ก (5) เก็บรายการส่วนประกอบซอฟต์แวร์ (SBOM) ไว้ จะได้รู้ทันทีว่าเมื่อมี CVE ใหม่ เรากระทบไหม
การจัดการ Secret และ Environment
secret คือกุญแจของระบบ เช่น รหัสฐานข้อมูล คีย์ API หรือ token ความผิดพลาดคลาสสิกคือเขียนค่าพวกนี้ลงในโค้ดตรง ๆ แล้ว push ขึ้น git เมื่อหลุดขึ้น repo สาธารณะ บอตของผู้โจมตีจะกวาดเจอภายในไม่กี่นาที
แบบผิด อย่าทำ: ฝัง secret ไว้ในโค้ดแล้วขึ้น git
DB_PASSWORD = "SuperSecret123" # หลุดขึ้น repo เมื่อไรคือจบ
api_key = "sk_live_abc123..."แบบถูก: อ่านจาก environment และกัน .env ไม่ให้ขึ้น git
import os
db_password = os.environ["DB_PASSWORD"] # ค่าจริงอยู่ในไฟล์ .env
# .gitignore
.env🛡️ วิธีป้องกัน: เก็บความลับให้ไม่หลุด
(1) ห้ามฝัง secret ในโค้ด ใช้ environment variable หรือระบบเก็บความลับ (secret manager) (2) ใส่ .env ลง .gitignore ตั้งแต่วันแรก (3) วางเครื่องมือสแกน secret ในขั้นตอน commit เพื่อดักก่อนหลุด (4) ถ้าเผลอ push secret ขึ้นไปแล้ว ให้ถือว่ามันรั่วทันที ต้องเพิกถอนและออกใหม่ (rotate) ไม่ใช่แค่ลบ commit เพราะประวัติ git ยังกู้กลับได้ (5) ให้แต่ละ secret มีสิทธิเท่าที่จำเป็น และหมุนเปลี่ยนตามรอบ
🧪 ลองในแล็บของคุณ
เปิดโปรเจกต์ของคุณเอง (หรือโปรเจกต์เปล่าที่สร้างขึ้นเพื่อฝึก) แล้วรัน npm audit หรือ pip-audit อ่านว่ามีตัวไหนเสี่ยง แล้วลองอัปเดตตาม จากนั้นฝึกย้าย secret สมมติออกจากโค้ดไปไว้ในไฟล์ .env พร้อมเพิ่มบรรทัด .env ใน .gitignore ยืนยันด้วย git status ว่าไฟล์ .env ไม่ถูกนับจะขึ้น commit ทั้งหมดนี้ทำในโปรเจกต์ของคุณเอง
Hardening เว็บจริง: HTTPS, Headers, Rate Limiting และการอัปเดต
เว็บที่เพิ่งเปิดใช้มักตั้งค่าแบบ "พอใช้งานได้" ซึ่งยังเปิดช่องไว้หลายจุด hardening คือการเก็บงานตรงนี้ ปิดสิ่งที่ไม่จำเป็นและเปิดเกราะที่ควรมี เราจะดูทีละแนวคิดโจมตีคู่กับวิธีอุด โดยยกตัวอย่างเป็นเว็บทั่วไปที่คุณดูแลเอง
ปัญหา 1: ข้อมูลถูกดักระหว่างทาง (ยังใช้ HTTP)
ถ้าเว็บยังวิ่งบน HTTP ธรรมดา ข้อมูลทุกอย่างรวมถึงรหัสผ่านและ cookie เดินทางเป็นข้อความเปล่า ใครที่อยู่ระหว่างทาง เช่น บนไวไฟสาธารณะ สามารถอ่านหรือแก้ไขได้ (man in the middle) นี่เป็นปัญหาระดับพื้นฐานที่สุดที่ต้องปิดก่อน
🛡️ วิธีป้องกัน: บังคับ HTTPS
ติดตั้งใบรับรอง TLS (ขอฟรีได้จาก Let's Encrypt) แล้วบังคับให้ทุก request วิ่งบน HTTPS โดย redirect จาก HTTP อัตโนมัติ เพิ่ม header Strict-Transport-Security (HSTS) เพื่อสั่งให้เบราว์เซอร์จำไว้ว่าเว็บนี้ต้องเข้าแบบ HTTPS เท่านั้นในครั้งต่อ ๆ ไป และตั้ง cookie ให้ติดแฟล็ก Secure กับ HttpOnly
ปัญหา 2: ขาด Security Headers (เปิดช่อง XSS และ clickjacking)
เบราว์เซอร์มีเกราะในตัวหลายชั้น แต่จะทำงานก็ต่อเมื่อเว็บสั่งเปิด ถ้าไม่ส่ง header ที่ควรมี ผู้โจมตีอาจฝังสคริปต์ (XSS) หรือครอบเว็บของเราด้วย iframe ใส ๆ เพื่อหลอกให้ผู้ใช้กดโดยไม่รู้ตัว (clickjacking) ได้ง่ายขึ้น
ตัวอย่าง header ฝั่งป้องกันที่ควรส่งกลับไปกับทุกหน้า
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: no-referrer🛡️ วิธีป้องกัน: เปิดเกราะของเบราว์เซอร์ให้ครบ
Content-Security-Policy จำกัดว่าสคริปต์/ทรัพยากรโหลดจากที่ไหนได้บ้าง เป็นด่านสำคัญกัน XSS, X-Content-Type-Options: nosniff กันเบราว์เซอร์เดาชนิดไฟล์ผิด, X-Frame-Options: DENY กันการนำเว็บไปครอบใน iframe (clickjacking), Referrer-Policy กันข้อมูล URL รั่วไปเว็บอื่น ตั้งครั้งเดียวที่ระดับเซิร์ฟเวอร์หรือ framework ก็คุ้มทุกหน้า
ปัญหา 3: ยิงคำขอถี่ ๆ (brute force และ DoS)
ถ้าเว็บรับคำขอไม่จำกัด ผู้โจมตีสามารถยิงรหัสผ่านทีละล้านค่าที่หน้า login หรือถล่มคำขอจนเครื่องล่ม เราจับความคิดนี้ได้จากบทก่อน สิ่งที่ต้องทำคือใส่เพดานให้กับคำขอ
🛡️ วิธีป้องกัน: Rate Limiting และตั้งเพดาน
จำกัดจำนวนคำขอต่อ IP ต่อช่วงเวลา (rate limiting), เพิ่มดีเลย์หรือล็อกชั่วคราวหลังล็อกอินพลาดหลายครั้ง, ใส่ CAPTCHA เมื่อสงสัย, และวาง WAF หรือบริการกรองทราฟฟิกไว้หน้าเว็บสำหรับกรณีถูกถล่มหนัก การตั้งเพดานยังช่วยกันบั๊กจากฝั่งเราเองที่เผลอยิงซ้ำด้วย
ปัญหา 4: ซอฟต์แวร์เก่าที่มีช่องโหว่ประกาศแล้ว
ระบบปฏิบัติการ เว็บเซิร์ฟเวอร์ ภาษา และไลบรารี ล้วนมีการประกาศช่องโหว่ (CVE) เรื่อย ๆ เมื่อประกาศออกมา ผู้โจมตีจะไล่หาเครื่องที่ยังไม่อัปเดต การปล่อยของเก่าค้างไว้จึงเท่ากับแขวนป้ายเชิญ
🛡️ วิธีป้องกัน: อัปเดตอย่างมีระบบ
ตั้งรอบอัปเดตสม่ำเสมอ, เปิดอัปเดตความปลอดภัยอัตโนมัติสำหรับตัวที่ปลอดภัยพอจะทำได้, ทดสอบบน staging ก่อนขึ้นจริงสำหรับตัวใหญ่, และเลิกใช้ซอฟต์แวร์ที่หมดการซัพพอร์ต (end of life) เพราะจะไม่มีแพตช์ให้อีก ปิดพอร์ตและบริการที่ไม่ได้ใช้ทิ้งด้วย ยิ่งเปิดน้อยยิ่งเสี่ยงน้อย
🧪 ลองในแล็บของคุณ
รันเว็บของคุณเองบน localhost หรือบนโดเมนที่คุณเป็นเจ้าของ แล้วดู header ที่มันส่งกลับด้วย curl -I https://localhost:PORT เทียบกับรายการ header ด้านบนว่าขาดตัวไหน จากนั้นลองเพิ่ม security headers ในการตั้งค่าเว็บเซิร์ฟเวอร์หรือ framework ของคุณ แล้ว curl -I ซ้ำเพื่อยืนยันว่ามันโผล่มาแล้ว ทดสอบเฉพาะเว็บที่คุณเป็นเจ้าของเท่านั้น
⚠️ จริยธรรมและกฎหมาย
เครื่องมือตรวจ header หรือสแกนช่องโหว่เว็บ ใช้ได้กับเว็บของคุณเองหรือที่ได้รับอนุญาตเป็นลายลักษณ์อักษรเท่านั้น การยิงสแกนใส่เว็บของผู้อื่นแม้ "แค่ดูว่ามีช่องโหว่ไหม" ก็อาจเข้าข่ายเข้าถึงหรือรบกวนระบบโดยมิชอบตามกฎหมายคอมพิวเตอร์ไทย ถ้าอยากฝึกกับเป้าที่ตั้งใจให้เจาะ ใช้ OWASP Juice Shop, DVWA, picoCTF หรือ PortSwigger Web Security Academy เป็นความรู้ทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย
Defense in Depth, Least Privilege และสรุปบท
เทคนิค hardening ทั้งหมดในบทนี้ยืนอยู่บนสองหลักคิดใหญ่ ถ้าจับสองอย่างนี้ได้ คุณจะออกแบบการป้องกันเองเป็น ไม่ใช่แค่ทำตามเช็กลิสต์
Defense in Depth (ป้องกันหลายชั้น)
อย่าฝากความปลอดภัยไว้กับกำแพงเดียว วางเกราะซ้อนกันหลายชั้น เช่น HTTPS + security headers + rate limiting + ตรวจสิทธิฝั่งเซิร์ฟเวอร์ + เฝ้า log ถ้าชั้นหนึ่งพลาด ยังมีชั้นถัดไปรับไว้ เหมือนปราสาทที่มีทั้งคูน้ำ กำแพง และยาม
Least Privilege (สิทธิเท่าที่จำเป็น)
ให้ทุกคนและทุกโปรแกรมมีสิทธิน้อยที่สุดเท่าที่งานต้องการ เช่น บัญชีฐานข้อมูลของเว็บอ่านเขียนได้เฉพาะตารางที่ใช้ ไม่ให้สิทธิแอดมิน ถ้าจุดนั้นถูกเจาะ ความเสียหายก็จำกัดวงอยู่แค่สิทธิเล็ก ๆ นั้น
สองหลักนี้ทำงานร่วมกัน
defense in depth ลดโอกาสที่ผู้โจมตีจะทะลุถึงของสำคัญ ส่วน least privilege ลดความเสียหายเมื่อเขาทะลุมาได้จริง รวมกันคือสมมติเสมอว่า "สักวันจะมีชั้นหนึ่งพลาด" แล้วออกแบบให้ระบบยังเอาตัวรอดได้ นี่คือกรอบคิดของ blue team ที่โตแล้ว ไม่ใช่หวังว่าจะไม่ถูกโจมตี แต่เตรียมให้พร้อมว่าเมื่อถูกโจมตีจะเจ็บน้อยที่สุดและฟื้นเร็วที่สุด
สรุปบท
บทนี้เราสวมหมวกสายป้องกัน เริ่มจากรู้จัก blue team เทียบกับ red team แล้วฝึกอ่าน log จับความผิดปกติ และรับมือเหตุตามหกขั้นของ incident response ต่อด้วยการดูแลความปลอดภัยตั้งแต่ตอนเขียนโค้ด ทั้ง secure coding checklist การสแกน dependency และการเก็บ secret ให้ไม่หลุด ปิดท้ายด้วย hardening เว็บจริงทั้ง HTTPS, security headers, rate limiting และการอัปเดต โดยมี defense in depth และ least privilege เป็นเสาหลัก ทั้งหมดฝึกได้เต็มที่กับระบบของคุณเองและเว็บฝึกที่ถูกกฎหมาย