สแกน Web Server ด้วย Nikto เพื่อหา Misconfiguration ก่อนขึ้น Production
เรียนรู้การใช้ Nikto ตรวจหาการตั้งค่า Web Server ที่ไม่เหมาะสม พร้อมแนวทางอ่านผล ยืนยันความเสี่ยง และแก้ไขอย่างเป็นระบบก่อนนำเว็บไซต์ขึ้น production
Nikto เป็นเครื่องมือสแกน Web Server ที่ทำงานรวดเร็วและตรงไปตรงมา เหมาะสำหรับตรวจหาการตั้งค่าที่ไม่เหมาะสมหรือสิ่งที่ไม่ควรเปิดเผยก่อนนำระบบขึ้น production โดยเฉพาะปัญหาพื้นฐานที่อาจถูกมองข้ามระหว่างการพัฒนาและติดตั้งระบบ
Nikto ทำหน้าที่อะไร
Nikto ไม่ใช่เครื่องมือแบบ stealth และไม่ได้ออกแบบมาเพื่อหลบเลี่ยง IDS หรือระบบตรวจจับการโจมตี ระหว่างสแกนมันจะส่ง request จำนวนมากด้วยรูปแบบที่สังเกตได้ชัดเจน เป้าหมายหลักคือการถาม Web Server ว่ายังมีไฟล์ ฟังก์ชัน หรือการตั้งค่าใดที่ไม่ควรเปิดทิ้งไว้หรือไม่
สิ่งที่ Nikto รายงานไม่ได้เป็นคำตัดสินสุดท้ายว่าระบบมีช่องโหว่จริงทุกข้อ ผลลัพธ์ควรถูกใช้เป็น checklist สำหรับตรวจสอบต่อ เพราะบางรายการอาจเป็น false positive ขณะที่บางรายการอาจมีความเสี่ยงสูงเมื่อพิจารณาร่วมกับหน้าที่และข้อมูลของระบบ
เริ่มต้นสแกน Web Server
คำสั่งพื้นฐานที่สุดคือระบุ URL ของเว็บไซต์ด้วยตัวเลือก -h โดยต้องสแกนเฉพาะระบบของตนเอง ระบบทดสอบ หรือระบบที่ได้รับอนุญาตอย่างชัดเจนเท่านั้น
nikto -h https://example.com
ระหว่างการสแกน Nikto จะตรวจสอบลักษณะของ Web Server และเปรียบเทียบกับรายการไฟล์ เส้นทาง และการตั้งค่าที่อาจมีความเสี่ยง การสแกนอาจใช้เวลาต่างกันตามขนาดของระบบ การตอบสนองของเซิร์ฟเวอร์ และจำนวนรายการที่ต้องตรวจสอบ
Nikto มักช่วยค้นหาประเด็นเบื้องต้นต่อไปนี้ได้
- Server header ที่เปิดเผยชื่อซอฟต์แวร์หรือเวอร์ชันมากเกินไป
- ไฟล์หรือหน้าเริ่มต้นที่ติดมากับ Apache, Nginx หรือซอฟต์แวร์อื่น
- Directory ที่ไม่ควรเข้าถึงได้จากภายนอก
- HTTP method ที่เปิดใช้งานโดยไม่จำเป็น
- หน้า admin หรือเส้นทางสำคัญที่คาดเดาได้ง่าย
- ไฟล์สำรอง เช่น
.bak,.oldและ.zip - Security header ที่ขาดหายหรือกำหนดค่าไม่เหมาะสม
อ่านผลลัพธ์อย่างมีบริบท
เมื่อ Nikto แสดง finding ควรพิจารณาว่าทรัพยากรนั้นมีหน้าที่อะไร ใครสามารถเข้าถึงได้ และหากถูกนำไปใช้ในทางที่ผิดจะเกิดผลกระทบอย่างไร Finding เดียวกันอาจมีระดับความเสี่ยงต่างกันมากระหว่างหน้าเว็บสาธารณะกับหน้า login หรือหน้าที่ใช้อนุมัติธุรกรรม
อย่าแก้ปัญหาด้วยการปิดหรือเปลี่ยนค่าทุกอย่างตามรายงานทันที เพราะบางฟังก์ชันอาจจำเป็นต่อระบบ ควรยืนยันผลด้วยเครื่องมืออีกชนิด ตรวจสอบ configuration และทดสอบว่าการแก้ไขไม่ทำให้บริการส่วนอื่นเสียหาย
กรณีไม่พบ Header ป้องกัน Clickjacking
หากพบข้อความ The X-Frame-Options header is not set หมายความว่าหน้าเว็บอาจไม่มีข้อกำหนดป้องกันการถูกนำไปแสดงภายใน iframe ของเว็บไซต์อื่น ผู้โจมตีอาจใช้เงื่อนไขนี้ประกอบการทำ clickjacking โดยวางองค์ประกอบหลอกให้ผู้ใช้กดปุ่มหรือยืนยันรายการที่มองไม่เห็น
ความเสี่ยงจะสูงขึ้นเมื่อหน้าดังกล่าวเป็นหน้า login หน้าเปลี่ยนข้อมูลสำคัญ หรือหน้าอนุมัติรายการ แนวทางป้องกันคือกำหนด X-Frame-Options หรือใช้นโยบาย frame-ancestors ของ Content Security Policy ตามความต้องการของระบบ
X-Frame-Options: DENY
Content-Security-Policy: frame-ancestors 'none';
หากเว็บไซต์จำเป็นต้องถูกฝังในบางโดเมน ควรกำหนด frame-ancestors ให้เจาะจงแทนการปิดทั้งหมด หลังแก้ไขแล้วต้องตรวจสอบทั้ง response header และพฤติกรรมของหน้าที่เกี่ยวข้องอีกครั้ง
กรณีเปิด HTTP Method ที่ไม่จำเป็น
รายงานลักษณะ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, PUT ควรได้รับการตรวจสอบเพิ่มเติม โดยเฉพาะ PUT เพราะ Web Server ที่ตั้งค่าผิดอาจเปิดทางให้เขียนหรืออัปโหลดไฟล์ไปยังตำแหน่งที่เข้าถึงจากภายนอกได้ อย่างไรก็ตาม การพบชื่อ method ในผลสแกนยังไม่ยืนยันว่าเซิร์ฟเวอร์ยอมรับการเขียนไฟล์จริง
ควรตรวจสอบ configuration เอกสารของแอปพลิเคชัน และ access log เพื่อยืนยันว่า method ใดถูกใช้งาน หากจำเป็นต้องทดสอบพฤติกรรมของ PUT ต้องทำใน lab หรือระบบที่ได้รับอนุญาตเท่านั้น จากนั้นปิด method ที่ไม่จำเป็นทั้งใน Web Server, reverse proxy และแอปพลิเคชันตามจุดที่รับ request
กรณีพบ Directory Listing
Directory listing เกิดขึ้นเมื่อผู้ใช้เปิดเส้นทางอย่าง /uploads/ แล้วเห็นรายชื่อไฟล์ทั้งหมดภายในโฟลเดอร์ ปัญหานี้อาจเปิดเผยเอกสาร รูปภาพ debug log ไฟล์ชั่วคราว หรือไฟล์สำรองที่ผู้ดูแลระบบไม่ได้ตั้งใจเผยแพร่
บน Apache ปัญหานี้มักเกี่ยวข้องกับการเปิด Options Indexes ส่วน Nginx มักเกี่ยวข้องกับ autoindex on การแก้ไขควรปิด listing กำหนดสิทธิ์ของไฟล์และไดเรกทอรีให้เหมาะสม และตรวจสอบว่าไฟล์ที่ไม่ควรเป็นสาธารณะไม่ได้ถูกเก็บไว้ใต้ document root
ตัวเลือกคำสั่งที่ใช้บ่อย
หากต้องการบังคับให้ Nikto ตรวจสอบผ่าน HTTPS สามารถเพิ่มตัวเลือก -ssl ได้ แม้การระบุ URL แบบ https:// จะสื่อถึง HTTPS อยู่แล้ว ตัวเลือกนี้ยังช่วยให้เจตนาของคำสั่งชัดเจนเมื่อทำงานกับปลายทางหรือพอร์ตที่มีการตั้งค่าเฉพาะ
nikto -h https://example.com -ssl
ในระบบที่อยู่หลัง reverse proxy หรือใช้ virtual host หลายชื่อบน IP เดียวกัน ต้องกำหนด Host header ให้ตรงกับเว็บไซต์เป้าหมาย มิฉะนั้นอาจสแกนผิด virtual host และได้ผลลัพธ์ที่ไม่เกี่ยวข้องกับแอปพลิเคชันที่ต้องการตรวจสอบ
nikto -h https://1.2.3.4 -vhost app.example.com
หากต้องส่งผลให้ทีมพัฒนา ทีมระบบ หรือทีมความปลอดภัย สามารถบันทึกรายงานเป็น HTML เพื่อให้อ่านง่าย หรือใช้ CSV เพื่อนำไปจัดกลุ่มและเรียงลำดับความเสี่ยงต่อได้
nikto -h https://example.com -o nikto-report.html -Format html
nikto -h https://example.com -o nikto-report.csv -Format csv
รายงานควรระบุเป้าหมาย เวลาที่สแกน สภาพแวดล้อม และข้อจำกัดของการทดสอบไว้ด้วย ข้อมูลเหล่านี้ช่วยให้ทีมแยก finding ที่ยืนยันแล้วออกจากรายการที่ยังต้องตรวจสอบ และลดความสับสนเมื่อสแกนซ้ำหลังการแก้ไข
ยืนยัน Security Header ด้วย curl
Nikto ช่วยชี้ตำแหน่งที่ควรตรวจต่อ ส่วน curl เหมาะสำหรับดู response header จริงจากเซิร์ฟเวอร์ การใช้คำสั่งต่อไปนี้ช่วยให้เห็นสถานะการตอบกลับและ header ที่เว็บไซต์ส่งกลับมาโดยไม่ต้องดาวน์โหลดเนื้อหาทั้งหน้า
curl -I https://example.com
เมื่อตรวจผลลัพธ์ ควรพิจารณาประเด็นสำคัญดังนี้
Serverเปิดเผยชื่อหรือเวอร์ชันของซอฟต์แวร์มากเกินความจำเป็นหรือไม่- มี
Strict-Transport-Securityสำหรับบังคับใช้งาน HTTPS ตามนโยบายของระบบหรือไม่ - มี
X-Content-Type-Options: nosniffเพื่อป้องกันการคาดเดาชนิดเนื้อหาหรือไม่ - มี
Content-Security-Policyที่สอดคล้องกับทรัพยากรและพฤติกรรมของเว็บไซต์หรือไม่ - มีนโยบายควบคุมการฝังหน้าเว็บผ่าน
X-Frame-Optionsหรือframe-ancestorsหรือไม่
การมี header ไม่ได้หมายความว่ากำหนดค่าได้ถูกต้องเสมอไป ต้องตรวจสอบค่าของแต่ละ header และทดสอบกับพฤติกรรมจริงของแอปพลิเคชันด้วย ตัวอย่างเช่น CSP ที่กว้างเกินไปอาจแทบไม่ช่วยลดความเสี่ยง ขณะที่นโยบายที่เข้มเกินไปอาจทำให้สคริปต์หรือทรัพยากรที่จำเป็นทำงานไม่ได้
Workflow สำหรับตรวจสอบก่อนขึ้น Production
กระบวนการที่ดีควรเปลี่ยนรายงานสแกนให้เป็นงานตรวจสอบและแก้ไขที่ติดตามผลได้ ไม่ควรจบเพียงการเก็บไฟล์รายงานไว้โดยไม่มีผู้รับผิดชอบ
- สแกนระบบด้วย Nikto ภายในขอบเขตที่ได้รับอนุญาต
- อ่าน finding ทีละข้อและจัดลำดับตามผลกระทบกับระบบ
- ยืนยันผลด้วย
curl, browser, configuration และ log ที่เกี่ยวข้อง - แก้ไข Web Server, reverse proxy หรือ application configuration
- Reload หรือ restart service ตามวิธีที่ปลอดภัยของระบบ
- ทดสอบฟังก์ชันหลักเพื่อป้องกันผลกระทบจากการเปลี่ยนแปลง
- สแกนซ้ำและบันทึกหลักฐานว่า finding ได้รับการแก้ไขแล้ว
ในองค์กรควรแจ้งช่วงเวลาที่จะสแกน IP ต้นทาง ปริมาณทราฟฟิกที่คาด และรายชื่อผู้ประสานงานให้ทีมที่เกี่ยวข้องทราบล่วงหน้า เพราะ request ของ Nikto มีจำนวนมากและมีรูปแบบชัดเจน จึงปรากฏใน log และอาจกระตุ้นระบบแจ้งเตือนด้านความปลอดภัยได้
ขอบเขตของ Nikto
Nikto ไม่ได้ทดแทน OWASP ZAP, Burp Suite หรือการทำ penetration test แบบเต็มรูปแบบ เครื่องมือนี้ไม่ได้เข้าใจกระบวนการทางธุรกิจทั้งหมด และอาจไม่พบช่องโหว่ที่ต้องอาศัยสถานะผู้ใช้ ลำดับการทำงาน หรือการวิเคราะห์เชิงลึก
จุดแข็งของ Nikto คือการเป็น “ไฟฉายรอบแรก” ที่ช่วยค้นหาสิ่งพื้นฐานซึ่งทีมอาจลืมตรวจ เช่น ไฟล์เริ่มต้น header ที่ขาดหาย method ที่เปิดเกินจำเป็น และ directory listing เมื่อใช้ร่วมกับการยืนยันผลและกระบวนการแก้ไขที่ชัดเจน เครื่องมือที่เรียบง่ายนี้สามารถช่วยลดช่องโหว่จาก misconfiguration ได้อย่างมีประสิทธิภาพ
สรุป
ก่อนนำเว็บไซต์ขึ้น production ควรสแกนด้วย Nikto อย่างน้อยหนึ่งรอบภายใต้การอนุญาตและการประสานงานที่เหมาะสม ให้มองผลลัพธ์เป็นรายการชี้เป้าสำหรับตรวจสอบต่อ ไม่ใช่ข้อสรุปอัตโนมัติว่าระบบมีช่องโหว่ทุกข้อ
คุณค่าที่แท้จริงของการสแกนเกิดจากการอ่านบริบท ยืนยัน finding แก้ configuration และสแกนซ้ำจนมั่นใจว่าความเสี่ยงลดลง หากเครื่องมือตรวจสอบพื้นฐานยังพบสิ่งที่เปิดเผยโดยไม่จำเป็น ผู้โจมตีที่สำรวจระบบจริงก็มีโอกาสพบสิ่งเดียวกันได้เช่นกัน