ผู้ใช้และระดับการอนุญาตที่เหมาะสมที่สุดสำหรับไซต์ Drupal บนโฮสติ้งที่ใช้ร่วมกันคืออะไร


14

แม้ว่าไซต์ Drupal จะมีรายละเอียดที่ดีเกี่ยวกับการอนุญาตและความปลอดภัย แต่มีการอ้างอิงที่คลุมเครือ / ไม่ชัดเจนในการแชร์โฮสติ้ง จากมุมมองของ Drupal การตั้งค่าที่ปลอดภัยที่สุด (ระดับความเป็นเจ้าของและการอนุญาต) สำหรับไซต์บนโฮสติ้งที่ใช้ร่วมกันคืออะไร

เป็นตัวอย่างของข้อมูลที่ฉันกำลังมองหา WordPress แนะนำการตั้งค่าโฮสติ้งที่ใช้ร่วมกันต่อไปนี้:

  • ไฟล์ทั้งหมดควรเป็นของบัญชีผู้ใช้จริงไม่ใช่บัญชีผู้ใช้ที่ใช้สำหรับกระบวนการ httpd
  • ความเป็นเจ้าของกลุ่มไม่เกี่ยวข้องยกเว้นว่ามีข้อกำหนดเฉพาะของกลุ่มสำหรับการตรวจสอบสิทธิ์กระบวนการของเว็บเซิร์ฟเวอร์ นี่ไม่ใช่กรณีปกติ
  • ไดเรกทอรีทั้งหมดควรเป็น 755 หรือ 750
  • ไฟล์ทั้งหมดควรเป็น 644 หรือ 640 ข้อยกเว้น: wp-config.php ควรเป็น 600 เพื่อป้องกันผู้ใช้รายอื่นบนเซิร์ฟเวอร์ไม่ให้อ่าน
  • ไม่ควรให้ไดเรกทอรี 777 แม้แต่อัปโหลดไดเรกทอรี เนื่องจากกระบวนการ php ทำงานเป็นเจ้าของไฟล์จึงได้รับสิทธิ์จากเจ้าของและสามารถเขียนไปยังไดเรกทอรี 755

2
ฉันคิดว่าคุณได้พบกับการแฮ็กใน Wordpress;) มีความเป็นไปได้น้อยกว่าในสิ่งต่างๆใน Drupal
niksmac


ยังไม่เข้าใจจริงๆ หากชื่อของคุณคือ Johnny และผู้ให้บริการโฮสต์ที่ใช้ร่วมกันของคุณระบุชื่อผู้ใช้ johnny99 หมายความว่าคุณควรจะ chown ไฟล์ไปที่ "johnny99: www-data" ก่อนทำการอัพโหลด? หรือไม่เกี่ยวข้องกับโฮสติ้งที่ใช้ร่วมกัน?
Simon Hoare

คำตอบ:


9

ตัวเลือกโฮสติ้ง

ตัวเลือกการโฮสต์สำหรับเว็บไซต์เว็บไซต์โดยทั่วไปมีอย่างใดอย่างหนึ่งต่อไปนี้:

  • เซิร์ฟเวอร์เฉพาะ
  • เซิร์ฟเวอร์ส่วนตัวเสมือน (VPS)
  • แชร์โฮสติ้ง

ด้วยเซิร์ฟเวอร์เฉพาะเว็บไซต์เดียวเท่านั้นโฮสต์บนคอมพิวเตอร์ที่มีอยู่จริงและการกำหนดค่ามีความปลอดภัยเท่ากับคอมพิวเตอร์เอง

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

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

สิ่งแวดล้อม

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

ในตัวอย่างต่อไปนี้จะถือว่าบัญชีเจ้าของเป็น "ทอม" และไฟล์การตั้งค่า (เก็บข้อมูลรับรองฐานข้อมูล) ชื่อ "settings.php"

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

นอกจากนี้จะถือว่าสภาพแวดล้อม Gnu / Linux หรือ Unix มาตรฐานและสันนิษฐานว่าผู้อ่านเข้าใจระบบควบคุมการเข้าถึง Unix โดยแยกการอ่าน (r) เขียน (w) และเรียกใช้ / เข้าถึงไดเรกทอรี (x) แยกออกเป็นสามช่วงตึก (ผู้ใช้กลุ่มอื่น ๆ )

ก่อนที่ฉันจะหารือเกี่ยวกับการตั้งค่าเฉพาะอาจเป็นประโยชน์ในการแสดงรายการเงื่อนไขที่เราต้องการ:

  1. เพื่อให้เว็บไซต์ทำงานได้เว็บเซิร์ฟเวอร์ต้องมีสิทธิ์อ่านเพื่อเข้าถึงไฟล์ทั้งหมดที่ประกอบขึ้นเป็นเว็บไซต์และเข้าถึงการเข้าถึงไดเรกทอรีไปยังไดเรกทอรีทั้งหมดที่สร้างเว็บไซต์
  2. เพื่อการทำงานที่ปลอดภัยเว็บเซิร์ฟเวอร์จะต้องไม่มีสิทธิ์ในการเขียนไฟล์ใด ๆ ที่จัดการ
  3. สำหรับการดำเนินการที่ปลอดภัยเว็บสคริปต์ที่ดำเนินการโดยผู้ใช้ที่หลอกลวงจะต้องไม่มีสิทธิ์ในการอ่านไฟล์ของผู้ใช้รายอื่น
  4. เพื่อให้เจ้าของทำงานบนไซต์ของเขาเองโดยใช้ CLI ผู้ใช้จะต้องมีสิทธิ์ในการอ่านและเขียนไฟล์ของตัวเอง
  5. เพื่อป้องกันไฟล์จากการถูกเข้าถึงโดยผู้ใช้อื่น ๆ ที่ใช้ CLI ที่บล็อก "อื่น ๆ" ควรจะมีไม่มีสิทธิ์ตั้ง

แต่น่าเสียดายที่ในพื้นที่ที่ใช้ร่วมกันคุณสามารถมีเพียง 4 จาก 5 ฉันรู้ว่าไม่มีทางที่คุณสามารถตอบสนองทุกห้าเงื่อนไขในการเป็นเจ้าภาพร่วมกัน

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

กำหนดค่า 1: เว็บเซิร์ฟเวอร์ทำงานเป็นเจ้าของ

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

อย่างไรก็ตามก็หมายความว่าเราไม่สามารถแยกสิทธิ์สำหรับเจ้าของและเว็บเซิร์ฟเวอร์ได้ ในการปฏิบัติตามเงื่อนไขที่ 2 ด้วยการตั้งค่าประเภทนี้คุณจะต้อง จำกัด สิทธิ์การเขียนสำหรับเจ้าของเพื่อป้องกันการเข้าถึงการเขียนสำหรับเว็บเซิร์ฟเวอร์ทุกอย่างยกเว้นไดเรกทอรีอัปโหลด

สิทธิ์:

Directories:  500 r-x --- --- tom.tom
Files:        400 r-- --- --- tom.tom
settings.php: 400 r-- --- --- tom.tom
Upload Dir.:  700 rwx --- --- tom.tom

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

กำหนดค่า 2: เว็บเซิร์ฟเวอร์กำลังทำงานในฐานะสมาชิกของกลุ่ม www

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

สิทธิ์:

Directories:  750 rwx r-x --- tom.www
Files:        640 rw- r-- --- tom.www
settings.php: 640 rw- r-- --- tom.www
Upload Dir.:  770 rwx rwx --- tom.www

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

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

คำแนะนำของฉันคือการหลีกเลี่ยงการกำหนดค่าประเภทนี้

ภาคผนวก: อันตรายแค่ไหนที่จะใช้โฮสต์ที่ใช้ร่วมกัน

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

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

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

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

คุณอาจต้องการดูคู่มือนี้เพื่อการรักษาความปลอดภัยการอนุญาตไฟล์และการเป็นเจ้าของที่ Drupal.org


ตกลงฉันให้ 50 คะแนนกับคุณ ขอบคุณสำหรับคำตอบโดยละเอียดของคุณ นี่หมายความว่าโฮสติ้งที่ใช้ร่วมกันนั้นต้องหลีกเลี่ยงเพราะมันไม่ปลอดภัย
Simon Hoare

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