ทำไม nginx เริ่มต้นกระบวนการเป็น root?

ฉันติดตั้งเซิร์ฟเวอร์ nginx แล้ว ฉันเพิ่งตรวจสอบพอร์ตการฟังและเห็นสิ่งต่อไปนี้:

$ sudo lsof -nP -i | grep LISTEN
sshd       614     root    3u  IPv4   7712      0t0  TCP *:22 (LISTEN)
nginx      822     root    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      827 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      828 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      829 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      830 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
.
.
.

และฉันแค่สนใจว่าเหตุใดจึงมีสี่กระบวนการ nginx ที่ทำงานเป็นผู้ใช้ 'www-data' และหนึ่งในนั้นเป็นผู้ใช้รูท

กระบวนการที่คุณสังเกตเห็นคือกระบวนการหลักกระบวนการที่เริ่มต้นกระบวนการ nginx อื่น ๆ ทั้งหมด กระบวนการนี้เริ่มต้นโดยสคริปต์ init ที่เริ่มต้น nginx เหตุผลที่กระบวนการนี้ทำงานในฐานะรูทนั้นเป็นเพราะคุณเริ่มใช้งานในฐานะรูท! คุณสามารถเริ่มต้นเป็นผู้ใช้อื่นได้ แต่คุณจะต้องตรวจสอบให้แน่ใจว่าผู้ใช้รายนี้ต้องการทรัพยากรทั้งหมดที่ nginx ต้องการ โดยทั่วไปจะเป็นอย่างน้อย / var / log / nginx และ pid-file ภายใต้ / var / run /

ที่สำคัญที่สุดคือ; กระบวนการรูทเท่านั้นที่สามารถรับฟังพอร์ตที่ต่ำกว่า 1024 โดยปกติแล้วเว็บเซิร์ฟเวอร์จะทำงานที่พอร์ต 80 และ / หรือ 443 นั่นหมายความว่าจำเป็นต้องเริ่มต้นเป็นรูท

โดยสรุปกระบวนการหลักที่ดำเนินการโดยรูทนั้นเป็นเรื่องปกติและในกรณีส่วนใหญ่จำเป็นสำหรับการทำงานปกติ

แก้ไข: การรันทุกอย่างในฐานะรูทมีความเสี่ยงด้านความปลอดภัยโดยปริยาย โดยทั่วไปแล้วผู้พัฒนาซอฟต์แวร์ประเภทนี้จะมีความรู้เกี่ยวกับเวกเตอร์ของการโจมตีและใช้ความระมัดระวังอย่างมากในการดำเนินการน้อยที่สุดเท่าที่จะเป็นไปได้ ในที่สุดคุณก็ต้องเชื่อว่าซอฟต์แวร์มีคุณภาพดี

หากคุณยังรู้สึกไม่สบายใจมีวิธีเรียกใช้ nginx ในฐานะผู้ใช้รายอื่นและยังคงใช้พอร์ตที่ต่ำกว่า 1024 คุณสามารถใช้ iptables เพื่อเปลี่ยนเส้นทางการรับส่งข้อมูลทั้งหมดบนพอร์ต 80 ไปยังพอร์ตอื่นเช่น 8080 และฟัง nginx บนพอร์ตนั้น

เซิร์ฟเวอร์ส่วนใหญ่ (Apache, Nginx ฯลฯ ) มีกระบวนการหลักที่เป็นเจ้าของโดย root ซึ่งจะทำการคัดลอกโหนดของผู้ปฏิบัติงานโดยใช้ผู้ใช้ที่ได้รับสิทธิน้อย www-dataในกรณีนี้มันเป็น

ตัวอย่าง

หากคุณดูที่nginxไฟล์/etc/nginx/nginx.confกำหนดค่าของคุณจะเห็นบรรทัดดังนี้:

user nginx;
worker_processes 2; #change to the number of your CPUs/Cores
worker_rlimit_nofile 8192;

เซิร์ฟเวอร์ส่วนใหญ่มีตัวเลือกที่คล้ายกับสิ่งนี้ซึ่งกำหนดว่าผู้ใช้รายใดที่จะเรียกใช้โหนดทาสเป็นและจำนวนของพวกเขา

ความปลอดภัย

การเปิดเผยบริการที่มีการเข้าถึงรูทมักถูกกล่าวถึงว่าเป็นความไม่มั่นคงที่อาจเกิดขึ้น อย่างไรก็ตามคุณมักจะต้องรูทเพื่อผูกกับพอร์ตที่มีช่วงตั้งแต่ 1-1024 ดังนั้นจึงไม่มีอะไรที่คุณสามารถทำได้ถ้าคุณต้องการให้เซิร์ฟเวอร์ฟังพอร์ต 80 หรือ 443

นอกจากนี้หากบริการถูกเขียนอย่างดีและกำหนดค่าอย่างเหมาะสมในตัวเองไม่จำเป็นต้องเป็นอันตรายต่อท่าทางความปลอดภัยของคุณ แอปพลิเคชันที่ทำงานบน Apache & Nginx เป็นแหล่งที่มาที่แท้จริงของการโอเวอร์โฟลว์บัฟเฟอร์หรือการโจมตีการฉีดเซิร์ฟเวอร์ SQL เนื่องจากแอปพลิเคชันเป็นบริการที่เปิดเผยจุดเข้าใช้งานสำหรับข้อมูลที่มีรูปแบบไม่ถูกต้อง

Apache & Nginx ด้วยตัวเองโดยทั่วไปจะไม่ยอมรับอินพุตใด ๆ นอกเหนือจากวิธีการ GET / POST ที่พวกเขายอมรับ

นี่เป็นวิธีที่แอปพลิเคชันจะถูกบรรจุ ส่วนใหญ่ * ระวังการตั้งค่าเริ่มต้นคือผู้ใช้ที่ไม่ได้รับสิทธิพิเศษไม่สามารถรับฟังพอร์ต <1024 และเว็บเซิร์ฟเวอร์ใช้ 80 และ 443

Linux 2.2+, Solaris 10+ และ FreeBSD ทั้งหมดอนุญาตให้ผู้ใช้ที่ไม่ใช่รูทฟังพอร์ตที่ต่ำกว่า 1024 แต่ไม่ใช่โดยค่าเริ่มต้น ส่วนใหญ่ยอมรับการใช้งานrootดังนั้นจึงยังคงใช้งานอยู่

นอกเหนือจากการเข้าถึงผูกพอร์ตพิเศษที่คุณต้องการเพื่อให้แน่ใจว่าผู้ใช้ที่เรียกใช้ nginx มีการเข้าถึงไฟล์ทั้งหมดที่ต้องการ คุณอาจไม่จำเป็นต้องไปไกลเท่านี้แต่เพียงกำหนดสิทธิ์ที่ถูกต้องในไฟล์ / ไดเรกทอรี คุณต้องตรวจสอบว่าสคริปต์เริ่มต้นไม่ได้ทำอะไรลับๆล่อๆเช่นulimitการเปลี่ยนแปลง (เช่น mysql มักจะดูเหมือน)

ความสามารถของ Linux

setcapและgetcapให้คุณเปลี่ยนหรือดูcap_net_bind_serviceความสามารถในการปฏิบัติการ สิ่งนี้จะมีผลสำหรับทุกคนที่รันไบนารี

setcap cap_net_bind_service=+ep /usr/sbin/nginx

SELinux มอบความสามารถในการกำหนดค่าและควบคุมความสามารถในระดับผู้ใช้

การตั้งค่าระบบ Freebsd

การตั้งค่าพอร์ตที่สงวนไว้นั้นเป็นแบบโกลบอลต่อระบบ

sysctl net.inet.ip.portrange.reservedhigh=0
sysctl net.inet.ip.portrange.reservedlow=0

สิทธิ์ Solaris

โซลาริสให้การควบคุมที่มีสิทธิ์พิเศษในระดับผู้ใช้ เหล่านี้เป็นสิทธิพิเศษสำหรับ apache แต่พวกเขาก็มีแนวโน้มที่จะทำงานให้กับ nginx เช่นกัน

/usr/sbin/usermod -K defaultpriv=basic,proc_exec,proc_fork,net_privaddr nginx

ฉันต้องการเพิ่มคำตอบให้กับทุกคน แม้ว่า nginx เริ่มต้นเป็นรูท แต่ไม่ได้รันเป็นรูท ผู้ใช้ (nginx, www-data และอื่น ๆ ) ที่มันกำลังทำงานอยู่โดยปกติคือการเข้าสู่ระบบแบบ จำกัด / จำคุก (คุณไม่สามารถเข้าสู่ระบบด้วยมันสามารถเข้าถึงไฟล์บางไฟล์เท่านั้น) นี่เป็นหนึ่งในข้อดีของการใช้ Linux สำหรับเว็บเซิร์ฟเวอร์ซึ่งต่างจาก Windows กระบวนการนี้เรียกว่า a fork( คุณสามารถหารายละเอียดเพิ่มเติมในบทความ Wikipedia นี้ ) และยังใช้setuidและ / หรือsetgid( ซึ่งอธิบายไว้ในบทความ Wikipedia) เพื่อเปลี่ยนผู้ใช้และ / หรือกลุ่ม ในการตั้งค่าที่ปลอดภัยแฮ็กเกอร์จะไม่สามารถเข้าถึงกระบวนการหลักและใช้บัญชีรูทได้ สิ่งนี้ไม่เป็นความจริงเสมอไปเนื่องจากแฮ็กเกอร์สามารถใช้ประโยชน์จากการโกงเพื่อเข้าถึงรูท (มีช่องโหว่ใน nginx 1.4.0 และต่ำกว่าซึ่งอนุญาตให้แฮกเกอร์เข้าถึงรูทได้)