Apache, suexec, PHP, suPHP


13

แม้ว่าฉันจะรู้สึกสะดวกสบายในฐานะผู้ใช้ Linux แต่ Linux Admin-fu ของฉันนั้นค่อนข้างอ่อนแอ ดังนั้นฉันอยู่ที่นี่กำลังมองหาคำแนะนำกับเซิร์ฟเวอร์ CentOS ฉันกำลังจะสร้าง

ฉันต้องติดตั้งเว็บเซิร์ฟเวอร์ Apache2 สำหรับลูกค้าของเราสองสามคน ฉันต้องการให้เนื้อหาเว็บของลูกค้าแต่ละรายอยู่ในโฮมไดUSERDIRเร็กตอรี่ของพวกเขา ( ใน apache.conf ใช่ไหม?) สำหรับไซต์ HTML แบบคงที่ ฉันต้องการ Apache ให้ทำงานในฐานะลูกค้า ( suexec?) บางสิ่งของพวกเขาจะเป็นแอพ PHP และฉันก็รู้สึกว่าฉันจะมองsuphpเช่นกัน

ดังนั้นโดยทั่วไปฉันต้องการดูเหมือนเป็น บริษัท เล็ก ๆ ที่ใช้เว็บโฮสติ้งร่วมกัน พิจารณาวิธีการที่พบผู้ที่มีผมคิดว่าผมได้อย่างง่ายดายต้องการหาที่ดีในปัจจุบันวิธีการแนะนำในการตั้งค่าทั้งหมดนี้ขึ้นมา แต่จนถึงขณะนี้ผมได้มีโชคน้อยมาก ฉันสงสัยว่าคำค้นหาของฉันปิดอยู่

ดังนั้นคำถาม (อย่าลังเลที่จะตอบคำถามใด ๆ หรือทั้งหมด):

  1. ใครมีลิงค์ที่เป็นของแข็งไปยังไกด์ปัจจุบัน / ทันสมัยที่จะช่วยฉันตั้งค่าทั้งหมดนี้? ไม่ไซต์เอกสาร apache ไม่ใช่คู่มือ ;-)
  2. เนื่องจากฉันมีเว็บไซต์แบบสแตติกและแอพ PHP ผสมกันฉันต้องการ / ต้องการติดตั้ง suexec และ suphp หรือไม่ ถ้าเป็นเช่นนั้นนั่นจะนำไปสู่ความท้าทายใด ๆ ที่ฉันควรทราบหรือไม่?
  3. ฉันควรจะดูตัวเลือกอื่นแทน suexec และ suphp หรือไม่?

ฉันวางแผนที่จะให้ผู้ใช้ปลายทาง SSH, SFTP หรือ SCP เข้าถึงสิ่งของของพวกเขา (หากมีผลกระทบต่อสิ่งใดก็ตาม)

ขอบคุณล่วงหน้าสำหรับความช่วยเหลือของ.

[แก้ไข] ฉันควรจะพูดถึงเรื่องนี้ก่อนหน้านี้: เป้าหมายสำคัญอย่างหนึ่งของการแสวงหาของฉันเพื่อเลียนแบบผู้ให้บริการโฮสต์ที่ใช้ร่วมกันที่เกี่ยวข้องกับ perms ไฟล์และการเป็นเจ้าของ ฉันต้องการหลีกเลี่ยงการสอนผู้ใช้เกี่ยวกับความต้องการที่จะเปลี่ยนแปลงสิ่งต่าง ๆ เหล่านี้เพื่อดูการเพิ่ม / การเปลี่ยนแปลงของพวกเขา

คำตอบ:


15

การใช้ suexec และ suphp บังคับใช้การแยกประเภทของสิทธิพิเศษต่างจากค่าเริ่มต้น

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

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

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

ทั้ง suexec มิได้ suPHP จะมีผลต่อ Apache วิธีการให้บริการเนื้อหาแบบคงที่ กฎเก่าทั้งหมดยังคงมีผลอยู่ แต่ suexec และ suphp จะเปลี่ยนบัญชีภายใต้ CGI และ PHP (ตามลำดับ) แทน Suexec ทำให้ CGI ทำงานได้ภายใต้บัญชีของเจ้าของในขณะที่ SuPHP ทำให้สคริปต์ PHP ทำงานภายใต้บัญชีของเจ้าของ

suexec และ suPHP ไม่จำเป็นต้องดีกว่า พวกเขากำลังเพียงที่แตกต่างกัน พวกเขาจะไม่ป้องกันเว็บไซต์ที่ถูกแฮ็ก (และอาจทำให้ไซต์ง่ายต่อการแฮ็ก) แต่พวกเขาจะป้องกันการประนีประนอมในเว็บไซต์หนึ่งจากการแพร่กระจายไปยังเว็บไซต์อื่น ๆ สำหรับผู้ดูแลระบบไซต์การแยกนี้มีความสำคัญมากกว่าซึ่งเป็นสาเหตุที่ระบบโฮสติ้งที่ใช้ร่วมกันบางระบบทำให้ suexec และ suphp เป็นค่าเริ่มต้น

"gotcha" ที่พบได้ทั่วไปอย่างหนึ่งคือ SuPHP จะตรวจสอบความเป็นเจ้าของและการอนุญาตของสคริปต์ก่อนที่มันจะทำงานและจะส่งคืนข้อผิดพลาด 500 ถ้าสิทธิ์ไม่เหมาะสม

โดยเฉพาะอย่างยิ่ง:

  • เจ้าของและกลุ่มของไฟล์จะต้องตรงกับเจ้าของเว็บไซต์ (เป็นการตั้งค่าในการกำหนดค่า apache)
  • ไฟล์ต้องไม่สามารถเขียนได้ทั่วโลก
  • ไดเรกทอรีหลักจะต้องไม่สามารถเขียนได้ทั่วโลก

ดังนั้นเมื่อรู้ว่าฉันต้องการเลียนแบบโฮสติ้งแบบแชร์ (ตามที่คุณชี้ให้เห็นการรักษาผู้ใช้จากกันและกัน) คือโมเดล suexec / suphp ในแบบที่ฉันต้องการหรือคุณรู้สึกว่ามีตัวเลือกที่ดีกว่า ฉันได้แก้ไขโพสต์เพื่อระบุว่าเป้าหมายสำคัญอย่างหนึ่งคือเพื่อหลีกเลี่ยงการสอนผู้ใช้เกี่ยวกับการแก้ไขไฟล์หรือเจ้าของไฟล์เพียงเพื่อดูการเปลี่ยนแปลงหรือการเพิ่มเติม
Chris_K

2
suexec / suphp เป็นทางออกที่ดีสำหรับสิ่งที่คุณต้องการ
tylerl

ฉันต้องการ suphp เพื่อ suexec ฉันคิดว่าปลอดภัยกว่า
Vladislav Rastrusny

@FractalizeR: โดยปกติคุณจะใช้ทั้งสองอย่างพร้อมกัน SuPHP สำหรับ PHP, suexec สำหรับ CGI คุณสามารถเรียกใช้ PHP ผ่าน suexec ได้โดยเรียกใช้ PHP ในฐานะ CGI แต่นั่นเป็นสิ่งที่ไม่จำเป็นเพราะตัวเลือกที่ดีกว่า (ปลอดภัยกว่าและมีประสิทธิภาพมากกว่า) สำหรับ PHP มีอยู่
tylerl

@tylerl: ขอบคุณมากสำหรับคำตอบของคุณ อะไรคือโซลูชั่นที่ปลอดภัยและมีประสิทธิภาพมากขึ้นสำหรับ PHP ที่คุณอ้างถึง?
benjamin
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.