การโฮสต์หลายไซต์ - ช่องโหว่ที่สำคัญที่พลาดไม่ได้ที่จะทำให้ไซต์ปลอดภัยจากกันคืออะไร?

แก้ไข # 2 23 กรกฎาคม 2558: ค้นหาคำตอบใหม่ที่ระบุรายการความปลอดภัยที่สำคัญที่ไม่ได้รับในการตั้งค่าด้านล่างหรืออาจให้เหตุผลที่จะเชื่อว่าทุกอย่างครอบคลุม

แก้ไข # 3 29 กรกฎาคม 2015: ฉันกำลังมองหาการกำหนดค่าผิดพลาดโดยเฉพาะอย่างยิ่งโดยไม่ได้ตั้งใจอนุญาตให้บางสิ่งบางอย่างที่สามารถใช้ประโยชน์เพื่อหลีกเลี่ยงข้อ จำกัด ด้านความปลอดภัยหรือแย่ลง แต่ยังเปิดกว้าง

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

นี่คือสิ่งที่ฉันมี:

• ตรวจสอบให้แน่ใจว่าสคริปต์ PHP ทำงานเป็นบัญชีผู้ใช้และกลุ่ม Linux ของเว็บไซต์และถูกจำคุก (เช่นใช้ CageFS) หรืออย่างน้อยก็ถูก จำกัด อย่างถูกต้องโดยใช้สิทธิ์ระบบไฟล์ Linux
• ใช้ suexec เพื่อให้แน่ใจว่าสคริปต์ CGI ไม่สามารถทำงานได้ในฐานะผู้ใช้ Apache
• หากต้องการการสนับสนุนด้านเซิร์ฟเวอร์ (เช่นในไฟล์ shtml) ให้ใช้Options IncludesNOEXECเพื่อป้องกัน CGI ไม่ให้สามารถทำงานได้เมื่อคุณไม่คาดหวังให้ใช้ (แม้ว่าจะไม่ควรกังวลมากนักหากใช้ suexec)
• มีการป้องกันการโจมตี symlink ในสถานที่เพื่อให้แฮกเกอร์ไม่สามารถหลอก Apache ให้แสดงไฟล์ของเว็บไซต์อื่น ๆ ให้เป็นข้อความธรรมดาและเปิดเผยข้อมูลที่เป็นประโยชน์เช่นรหัสผ่านฐานข้อมูล
• กำหนดค่าAllowOverride/ AllowOverrideListอนุญาตเฉพาะคำสั่งที่แฮ็กเกอร์ไม่สามารถใช้ประโยชน์ได้ ฉันคิดว่านี่เป็นเรื่องน่ากังวลน้อยกว่าหากรายการด้านบนทำอย่างถูกต้อง

ฉันจะไปกับ MPM ITK ถ้ามันไม่ช้าและไม่ได้ทำงานในฐานะรูท แต่เราต้องการใช้ Apache ที่ใช้ร่วมกันโดยเฉพาะ

ฉันพบhttp://httpd.apache.org/docs/2.4/misc/security_tips.htmlแต่ไม่ครอบคลุมในหัวข้อนี้

หากมีประโยชน์ที่จะรู้เรากำลังวางแผนที่จะใช้ CloudLinux กับ CageFS และ mod_lsapi

มีอะไรอีกบ้างที่จะต้องทำหรือรู้เกี่ยวกับ?

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

ขอบคุณ!

ฉันเห็นด้วยกับรายการที่คุณมีจนถึงตอนนี้

ฉันเคยใช้งานการติดตั้งแบบผู้ใช้หลายคนเมื่อไม่กี่ปีที่ผ่านมาและโดยทั่วไปฉันพบการแลกเปลี่ยนที่เหมือนกัน: mod_php นั้นรวดเร็ว (ส่วนหนึ่งเป็นเพราะทุกอย่างทำงานในกระบวนการเดียวกัน) และ suexec ช้า แต่ปลอดภัย (เพราะทุกคำขอขอใหม่ กระบวนการ). ฉันไปกับ suexec เพราะต้องมีการแยกผู้ใช้

ขณะนี้มีตัวเลือกที่สามที่คุณอาจพิจารณา: มอบ php-fpm daemon ให้ผู้ใช้ทุกคน ไม่ว่าสิ่งนี้จะเป็นไปได้หรือไม่นั้นขึ้นอยู่กับจำนวนผู้ใช้เพราะทุกคนต้องได้รับ php-fpm อย่างน้อยหนึ่งกระบวนการโดยใช้บัญชีผู้ใช้ของพวกเขา (จากนั้นภูตก็ใช้ prefork เช่นกลไกในการปรับขนาดตามคำขอดังนั้นจำนวนกระบวนการและ การใช้หน่วยความจำอาจ จำกัด ปัจจัย) คุณจะต้องสร้างการกำหนดค่าอัตโนมัติบางอย่าง แต่ควรจะทำได้ด้วยสคริปต์เชลล์บางตัว

ฉันไม่ได้ใช้วิธีการนั้นในสภาพแวดล้อมขนาดใหญ่ แต่ IMHO เป็นโซลูชันที่ดีในการมอบประสิทธิภาพเว็บไซต์ PHP ที่ดีในขณะที่ยังแยกผู้ใช้ในระดับกระบวนการ

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

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

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

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

ฉันขอแนะนำให้แต่ละไซต์ทำงานภายใต้ Apache daemon ของตัวเองและ chrooting Apache ฟังก์ชัน php ของระบบทั้งหมดจะล้มเหลวเนื่องจากสภาพแวดล้อม Apache chroot จะไม่สามารถเข้าถึง / bin / sh นี่ก็หมายความว่าฟังก์ชั่น mail ของ php ยังไม่สามารถใช้งานได้ แต่หากคุณใช้ผู้ให้บริการอีเมลภายนอกเพื่อส่งอีเมลจากแอปพลิเคชันอีเมลของคุณสิ่งนี้ไม่ควรเป็นปัญหาสำหรับคุณ

SELinux mod_selinuxอาจจะเป็นประโยชน์กับ วิธีการอย่างรวดเร็วมีคุณลักษณะที่นี่:

ฉันจะใช้ SELinux เพื่อ จำกัด สคริปต์ PHP ได้อย่างไร

เนื่องจากคำแนะนำค่อนข้างล้าสมัยฉันจึงตรวจสอบว่าใช้งานได้กับ RHEL 7.1:

ฉันใช้เวอร์ชันของ Fedora 19และรวบรวมกับเยาะเย้ยกับ RHEL 7.1 + EPEL

YMMV ถ้าคุณใช้การจำลอง epel config พื้นฐานมาพร้อมกับ:

[mockbuild@fedora mod_selinux]$ mock -r rhel-7-x86_64 --rebuild \
    mod_selinux-2.4.3-2.fc19.src.rpm

อัพเกรดระบบเป้าหมายของคุณก่อนเพื่อให้แน่ใจว่าselinux-policyเป็นปัจจุบัน

ติดตั้งที่กล่องเป้าหมาย (หรือวางไว้บนกระจกในเครื่องของคุณก่อน):

yum localinstall mod_selinux-2.4.3-2.el7.x86_64.rpm

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

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host1
    ServerName host1.virtual
    selinuxDomainVal *:s0:c0
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host2
    ServerName host2.virtual
    selinuxDomainVal *:s0:c1 
</VirtualHost>

ถัดไปในรูทเอกสารสำหรับแต่ละโฮสต์ให้ติดฉลากรูทเอกสารของตนใหม่กับหมวดหมู่เดียวกับที่ติดป้ายกำกับไว้ใน httpd config

chcon -R -l s0:c0 /var/www/vhosts/host1
chcon -R -l s0:c1 /var/www/vhosts/host2

หากคุณต้องการให้การติดฉลากได้รับเกียรติหากคุณติดตั้งระบบใหม่คุณควรปรับปรุงนโยบายท้องถิ่นด้วย!

semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c0 '/var/www/vhosts/host1(/.*)?' 
semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c1 '/var/www/vhosts/host2(/.*)?'

มีคำตอบทางเทคนิคที่ดีให้ไว้มากมาย (โปรดดูที่นี่: https://security.stackexchange.com/q/77/52572และเคล็ดลับสำหรับการรักษาความปลอดภัยเซิร์ฟเวอร์ LAMP ) แต่ฉันยังอยากจะพูดถึงที่นี่ จุดสำคัญ (จากมุมมองอื่น ๆ ) เกี่ยวกับการรักษาความปลอดภัย: การรักษาความปลอดภัยเป็นกระบวนการ ฉันแน่ใจว่าคุณได้พิจารณาเรื่องนี้แล้ว แต่ฉันก็ยังหวังว่ามันอาจจะมีประโยชน์

ตัวอย่างเช่นในคำถามของคุณคุณจะเน้นไปที่มาตรการทางเทคนิคเป็นหลัก: "คำถามนี้มีเป้าหมายเฉพาะเกี่ยวกับความปลอดภัยของการตั้งค่า Apache ที่ใช้ร่วมกันโดยเฉพาะมีขั้นตอนการรักษาความปลอดภัยที่สำคัญที่จะต้องทำ Apache และ PHP "

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

1. ก่อนอื่นอย่าลืมว่าการรักษาความปลอดภัยนั้นเป็นกระบวนการและโดยเฉพาะอย่างยิ่งเกี่ยวกับวงจร "ทำ - ตรวจสอบ - ปฏิบัติตามกฎหมาย" ตามที่ได้รับการแนะนำโดยมาตรฐานหลายฉบับรวมถึง ISO 27001 ( http://www.isaca.org/ วารสาร / จดหมายเหตุ / 2011 / เล่มที่ 4 / หน้า / การวางแผนสำหรับและดำเนินการตามมาตรฐาน ISO27001.aspx ) โดยทั่วไปหมายความว่าคุณต้องแก้ไขมาตรการความปลอดภัยอัปเดตและทดสอบเป็นประจำ

2. อัปเดตระบบของคุณเป็นประจำ สิ่งนี้จะไม่ช่วยในการโจมตีเป้าหมายโดยใช้ช่องโหว่แบบ zero-day แต่จะช่วยต่อต้านการโจมตีอัตโนมัติเกือบทั้งหมด

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

   นี่คือสิ่งที่สถิติบอกเกี่ยวกับเรื่องนี้: "เวลาเฉลี่ยจากการแทรกซึมสู่การค้นพบคือ 173.5 วัน" ( http://www.triumfant.com/detection.html ), "205 จำนวนวันเฉลี่ยก่อนการตรวจจับ" ( https: // www2 .fireeye.com / rs / fireye / images / rpt-m-Trends-2015.pdf ) และฉันหวังว่าตัวเลขเหล่านี้ไม่ใช่สิ่งที่เราทุกคนต้องการ

   มีโซลูชั่นมากมาย (รวมถึงฟรี) ไม่เพียง แต่สำหรับการตรวจสอบสถานะของบริการ (เช่น Nagios) แต่ยังมีระบบตรวจจับการบุกรุก (OSSEC, Snort) และระบบ SIEM (OSSIM, Splunk) หากมันซับซ้อนเกินไปอย่างน้อยคุณสามารถเปิดใช้งานบางอย่างเช่น 'fail2ban' และ / หรือส่งต่อคุณบันทึกไปยังเซิร์ฟเวอร์ syslog แยกต่างหากและมีการแจ้งเตือนทางอีเมลเกี่ยวกับเหตุการณ์สำคัญ

   อีกครั้งจุดที่สำคัญที่สุดที่นี่ไม่ได้ระบบที่คุณเลือกการตรวจสอบที่สำคัญที่สุดคือการที่คุณมีการตรวจสอบและแก้ไขมันอย่างสม่ำเสมอตามที่ "Plan-Do-Check-Act ของคุณ" วงจร

4. ระวังช่องโหว่ เหมือนกับการตรวจสอบ เพียงสมัครสมาชิกรายการช่องโหว่ที่ต้องแจ้งเมื่อพบช่องโหว่ที่สำคัญสำหรับ Apache หรือบริการอื่น ๆ ที่สำคัญสำหรับการตั้งค่าของคุณ เป้าหมายจะได้รับแจ้งเกี่ยวกับสิ่งที่สำคัญที่สุดที่ปรากฏก่อนการอัพเดทครั้งต่อไปของคุณ

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

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

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

กรณีการใช้งานของคุณเหมาะสำหรับคอนเทนเนอร์นักเทียบท่า

แต่ละคอนเทนเนอร์สามารถเป็นตัวแทนลูกค้าหรือลูกค้าด้วย ID ผู้ใช้ที่ไม่ซ้ำกันซึ่งกำหนดให้กับแต่ละกลุ่มคอนเทนเนอร์ Apache เพื่อเพิ่มความปลอดภัย กุญแจสำคัญคือการปล่อยสิทธิ์รูทเมื่อเริ่มต้นคอนเทนเนอร์ก่อนเริ่ม apache stack ของคุณ ลูกค้าแต่ละรายจะได้รับบริการ DB ของตัวเองด้วยรหัสผ่านที่เป็นเอกลักษณ์ของตนเองโดยไม่ต้องปวดหัวในการยืนขึ้นเครื่องเสมือนหลายสิบเครื่องโดยแต่ละคนต้องใช้เมล็ดเกล็ดหิมะพิเศษและค่าใช้จ่ายอื่น ๆ ท้ายที่สุดหัวใจของนักเทียบท่าก็คือ chroot บริหารอย่างถูกต้องฉันจะนำสิ่งนั้นไปใช้กับคลัสเตอร์เสมือนทั่วไปทุกวัน

คำแนะนำที่ดีมากมายอยู่ที่นี่แล้ว มีสิ่งที่ไม่ได้รับในการสนทนาจนถึงแม้ว่า

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

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

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

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

ชัดเจนน้อยกว่าคือวิธี apache ตัดสินใจว่าเป็นไฟล์แบบคงที่อย่างไรก็ตาม เช่นมันจะมีอะไรทำอะไรกับ*.php.gifหรือ*.php.enไฟล์? หากกลไกนี้หรือคนอื่นโง่การแยกแยะเป็นไฟล์แบบคงที่เป็นไปได้ไหมที่ apache จะเรียกใช้ php จากนอกคุก? ฉันจะตั้งค่าเว็บเซิร์ฟเวอร์น้ำหนักเบาแยกต่างหากสำหรับเนื้อหาแบบสแตติกซึ่งไม่ได้กำหนดค่าด้วยโมดูลใด ๆ สำหรับการดำเนินการเนื้อหาแบบไดนามิกและมี load balancer ตัดสินใจว่าจะส่งคำขอใดไปยังเซิร์ฟเวอร์แบบสแตติกและแบบไดนามิก

เกี่ยวกับข้อเสนอแนะของนักเชื่อมต่อของสเตฟานมันเป็นไปได้ที่จะมีเว็บเซิร์ฟเวอร์เดียวที่อยู่นอกคอนเทนเนอร์และพูดคุยกับ php daemons ในแต่ละคอนเทนเนอร์สำหรับเนื้อหาแบบไดนามิกในขณะที่ยังมีเว็บเซิร์ฟเวอร์ที่สองซึ่งอยู่ในคอนเทนเนอร์ของนักเทียบท่า ซึ่งแบ่งปันปริมาณการใช้เนื้อหาของพวกเขาและจึงสามารถให้บริการเนื้อหาคงที่ซึ่งจะเหมือนกับในวรรคก่อน ฉันขอชมเชยนักเทียบท่าท่ามกลางวิธีการคุมขังแบบต่างๆ แต่ด้วยวิธีการคุมขังแบบนี้หรือแบบอื่น ๆ คุณจะมีปัญหาอื่น ๆ อีกมากมายให้จัดการ การอัปโหลดไฟล์ทำงานอย่างไร คุณใส่ daemons การถ่ายโอนไฟล์ในแต่ละคอนเทนเนอร์หรือไม่? คุณใช้วิธีการตามสไตล์คอมไพล์ PAAS? คุณสร้างบันทึกได้อย่างไรภายในคอนเทนเนอร์ที่เข้าถึงได้ และม้วนพวกเขามากกว่า? คุณจัดการและรันงาน cron ได้อย่างไร? คุณจะให้การเข้าถึงเชลล์แก่ผู้ใช้หรือไม่และหากเป็นเช่นนั้น daemon อื่นภายในคอนเทนเนอร์หรือไม่ ฯลฯ

สิ่งแรกที่ฉันไม่เห็นคือการจัดการกระบวนการดังนั้นกระบวนการหนึ่งจึงไม่สามารถอดกระบวนการ CPU หรือ RAM อื่น (หรือ I / O สำหรับเรื่องนั้นแม้ว่าระบบไฟล์ของคุณอาจได้รับการออกแบบมาเพื่อป้องกันไม่ให้เกิดปัญหา) ข้อได้เปรียบที่สำคัญอย่างหนึ่งของวิธี "คอนเทนเนอร์" สำหรับอินสแตนซ์ PHP ของคุณกับการพยายามเรียกใช้ทั้งหมดในอิมเมจ "OS" หนึ่งคือคุณสามารถ จำกัด การใช้ทรัพยากรได้ดีกว่า ฉันรู้ว่านั่นไม่ใช่การออกแบบของคุณ แต่เป็นสิ่งที่ต้องพิจารณา

อย่างไรก็ตามกลับไปที่กรณีการใช้งานของ PHP ที่ทำงานอยู่เบื้องหลัง Apache โดยทั่วไปจะทำหน้าที่เป็นพร็อกซี suexec ไม่ได้ป้องกันบางสิ่งบางอย่างจากการทำงานในฐานะผู้ใช้ apache - มันให้ความสามารถในการทำงานในฐานะผู้ใช้รายอื่น ดังนั้นหนึ่งในความกังวลเป็นไปได้เพื่อให้แน่ใจว่าจะทำทุกอย่างถูกต้อง - หน้าสำหรับ doc มันเรียกว่าอันตรายที่อาจเกิด: https://httpd.apache.org/docs/2.2/suexec.html ดังนั้นคุณรู้ไหมเม็ดเกลือและทุกสิ่ง

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

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

การจัดการบันทึกจะเป็นกุญแจสำคัญ ด้วยบริการหลายอย่างที่ทำงานในระบบไฟล์แยกการรวมกิจกรรมต่าง ๆ เข้าด้วยกันเมื่อมีปัญหาอาจเป็นปัญหาเล็กน้อยหากคุณไม่ได้ตั้งค่านั้นตั้งแต่ต้น

นั่นคือสมองของฉัน หวังว่าจะมีสิ่งที่มีประโยชน์ราง ๆ อยู่ในนั้น :)