เครื่องมือตรวจสอบการตั้งค่า Nginx
วาง nginx.conf เพื่อตรวจหาข้อผิดพลาดทางไวยากรณ์ directive ที่วางผิดที่ และข้อผิดพลาดด้านความปลอดภัยที่พบบ่อย ก่อนที่คุณจะ reload nginx จริง
ลากไฟล์ .conf มาวางที่นี่ หรือวางข้อความการตั้งค่าด้านบน
ทุกอย่างประมวลผลในเบราว์เซอร์ของคุณ — การตั้งค่าจะไม่ถูกอัปโหลดไปยังเซิร์ฟเวอร์ใดๆ เลย
วางคอนฟิก nginx ด้านบน (หรือโหลดตัวอย่าง) แล้วผลการตรวจสอบจะแสดงที่นี่
ใช้ regex engine ของ JavaScript ไม่ใช่ PCRE engine จริงของ nginx — ใกล้เคียงกันมากแต่ไม่เหมือนกันทุกประการ (ไม่มี possessive quantifier/atomic group)
จับข้อผิดพลาดของคอนฟิก nginx ก่อนถึง production
nginx.conf ที่พังมักประกาศตัวเองด้วยวิธีที่ไม่น่าพอใจอย่างใดอย่างหนึ่ง คือ `nginx -t` ปฏิเสธการ reload พร้อมข้อผิดพลาดบอกเลขบรรทัดที่เข้าใจยาก หรือที่แย่กว่านั้น คือ `reload` เงียบ ๆ แล้วเก็บคอนฟิกเก่า (ที่ใช้งานได้) ไว้ในหน่วยความจำ ในขณะที่คอนฟิกใหม่ที่พังค้างอยู่บนดิสก์ ทำให้ดูเหมือนไม่มีอะไรผิดปกติจนกว่าจะรีสตาร์ทเต็มรูปแบบครั้งถัดไป ทั้งสองกรณีหลีกเลี่ยงได้ด้วยการจับข้อผิดพลาดประเภทเดียวกันให้เร็วขึ้น ขณะที่ยังแก้ไขอยู่
ข้อผิดพลาดที่พบบ่อยที่สุดของ nginx.conf ในโลกจริงไม่ได้แปลกอะไร คือลืมเซมิโคลอน เพราะไวยากรณ์ของ nginx สนใจแค่ `;`, `{` และ `}` (ไม่สนใจการขึ้นบรรทัดใหม่) เซมิโคลอนที่ขาดจึงไม่ขึ้นข้อผิดพลาดชัดเจนแบบ "line 12: expected ;" อย่างที่ตัวแยกวิเคราะห์สมัยใหม่ส่วนใหญ่ทำ แต่ชื่อและอาร์กิวเมนต์ของ directive ถัดไปจะถูกดูดเป็นอาร์กิวเมนต์เพิ่มของ directive ก่อนหน้าไปเงียบ ๆ บางครั้งไม่มีข้อผิดพลาดเลยจนกว่าบางอย่างด้านล่างจะทำงานแปลก ๆ การตรวจจับด้วยการเว้นบรรทัดของเครื่องมือนี้เฝ้าดูรูปแบบนั้นโดยเฉพาะ คือชื่อ directive ที่รู้จักปรากฏกลางรายการอาร์กิวเมนต์ในบรรทัดต้นฉบับใหม่ และแจ้งเตือนก่อนจะกลายเป็นเรื่องที่ต้องแจ้งซัปพอร์ต
การวาง directive ผิดบริบทเป็นกับดักอันดับสอง `proxy_pass` ใช้ได้เฉพาะในบล็อก `location` (หรือ `if`) `listen`/`server_name` ใช้ได้เฉพาะใน `server` และอื่น ๆ แต่ตัวแยกวิเคราะห์ของ nginx เองไม่ปฏิเสธ directive เพียงเพราะอยู่ในที่แปลก หากชื่อ directive นั้นเป็นสิ่งที่มันรู้จักในความหมายที่กว้างกว่า และข้อความผิดพลาดก็ชี้ไปที่ทะเบียน directive ภายในของ nginx ไม่ใช่ "คุณซ้อนผิด" ตัวตรวจสอบนี้ตรวจตารางความสัมพันธ์ระหว่าง directive กับบริบทโดยตรง `proxy_pass` ที่เผลอทิ้งไว้ระดับ `http` (นอก `server`/`location`) จึงถูกแจ้งพร้อมบรรทัดที่แน่นอน ไม่ใช่แค่ "โหลดคอนฟิกไม่สำเร็จ"
นอกจากไวยากรณ์ การตั้งค่าเล็ก ๆ ไม่กี่อย่างส่งผลต่อความปลอดภัยเกินตัว การปล่อย `server_tokens` เป็นค่าเริ่มต้น (`on`) จะเปิดเผยเวอร์ชัน nginx ที่แน่นอนในทุก header ตอบกลับและหน้าข้อผิดพลาดเริ่มต้น ซึ่งเป็นการสอดแนมฟรีสำหรับคนที่กำลังหา CVE เฉพาะเวอร์ชัน และการใช้ตัวแปร `$uri` ที่ถอดรหัส URL แล้วใน `return`/`rewrite`/`add_header` (แทน `$request_uri` ดิบ) อาจทำให้ผู้โจมตีแทรกอักขระลงในปลายทาง redirect ได้ในบางคอนฟิก ทั้งสองอย่างไม่ทำให้อะไรพังให้เห็นระหว่างการทดสอบปกติ นั่นคือเหตุผลที่ควรตรวจโดยเฉพาะ แทนที่จะหวังว่าจะสังเกตเห็นด้วยตาในคอนฟิก 200 บรรทัด
คำถามที่พบบ่อย
เครื่องมือนี้ใช้แทน `nginx -t` ได้ไหม
ไม่ได้ `nginx -t` เป็นเครื่องมือเดียวที่ตรวจคอนฟิกของคุณกับ nginx บิลด์และโมดูลที่ติดตั้งจริงบนเซิร์ฟเวอร์ และเป็นคำตัดสินสุดท้ายก่อน reload ตัวตรวจสอบนี้จับข้อผิดพลาดประเภทเดียวกัน (ข้อผิดพลาดไวยากรณ์ directive ที่วางผิดที่ และข้อสังเกตด้านความปลอดภัยบางข้อ) ก่อนที่คุณจะไปถึงเซิร์ฟเวอร์ที่ติดตั้ง nginx ซึ่งมีประโยชน์ขณะแก้ไขในเครื่อง ในขั้นตอน CI หรือเมื่อยังไม่มีสิทธิ์เชลล์บนเครื่องปลายทาง
เช็กลิสต์ความปลอดภัยครบถ้วนหรือไม่
ไม่ครบ ครอบคลุมเพียงชุดการตรวจเล็ก ๆ ที่เลือกมาโดยเจตนา (ไม่มี `server_tokens off;`, `autoindex on;` และการใช้ `$uri` แทนที่ `$request_uri` ที่ปลอดภัยกว่า) โดยได้แรงบันดาลใจคร่าว ๆ จาก Gixy ตัวตรวจสอบคอนฟิก nginx แบบโอเพนซอร์ส จึงไม่ใช่สิ่งทดแทน Gixy หรือการตรวจสอบความปลอดภัยฉบับเต็ม
ทำไมตัวทดสอบ regex จึงทำงานต่างจาก nginx จริงเล็กน้อย
การจับคู่ `location ~` และ `location ~*` ของ nginx ใช้ PCRE (ผ่านไลบรารี PCRE ที่รวมอยู่ในไบนารี nginx) เครื่องมือนี้ทำงานในเบราว์เซอร์ทั้งหมด จึงใช้เอนจิน RegExp ในตัวของ JavaScript แทน ทั้งสองใกล้เคียงกันมากสำหรับรูปแบบทั่วไป แต่ฟีเจอร์เฉพาะ PCRE เช่น possessive quantifier หรือ atomic group จะทำงานไม่เหมือนกันที่นี่
คอนฟิกของฉันออกจากเบราว์เซอร์หรือไม่
ไม่ การแยกวิเคราะห์ การตรวจสอบ และตัวจำลองทั้งสองทำงานด้วย JavaScript ล้วนในแท็บนี้ ไม่มีการอัปโหลด บันทึก หรือส่งไปที่ใด คุณตัดการเชื่อมต่ออินเทอร์เน็ตหลังหน้าเว็บโหลดเสร็จแล้วก็ยังใช้งานได้