ไฟล์ / โฟลเดอร์เว็บไซต์ของฉันควรได้รับการอนุญาตบนเว็บเซิร์ฟเวอร์ Linux?

นี่เป็นคำถามที่ยอมรับได้เกี่ยวกับการอนุญาตไฟล์ในเว็บเซิร์ฟเวอร์ Linux

ฉันมีเว็บเซิร์ฟเวอร์ Linux ที่ใช้ Apache2 ซึ่งโฮสต์เว็บไซต์หลายแห่ง แต่ละเว็บไซต์มีโฟลเดอร์ของตัวเองใน / var / www /

/var/www/contoso.com/
/var/www/contoso.net/
/var/www/fabrikam.com/

ไดเรกทอรีฐาน / var / www / เป็นของ root: root Apache ทำงานเป็น www-data: www-data เว็บไซต์ Fabrikam ดูแลโดยสองนักพัฒนาคืออลิซและบ๊อบ ทั้งเว็บไซต์ Contoso ได้รับการดูแลโดยนักพัฒนาซอฟต์แวร์หนึ่งคน เว็บไซต์ทั้งหมดอนุญาตให้ผู้ใช้อัปโหลดภาพ หากเว็บไซต์ถูกบุกรุกผลกระทบควรมี จำกัด มากที่สุด

ฉันต้องการทราบวิธีที่ดีที่สุดในการตั้งค่าการอนุญาตเพื่อให้ Apache สามารถให้บริการเนื้อหาเว็บไซต์นั้นปลอดภัยจากการโจมตีและนักพัฒนายังคงสามารถเปลี่ยนแปลงได้ หนึ่งในเว็บไซต์มีโครงสร้างดังนี้:

/var/www/fabrikam.com
    /cache
    /modules
    /styles
    /uploads
    /index.php

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

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

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

ผู้ใช้ที่ไม่ระบุชื่อคือผู้เข้าชมเว็บไซต์ของคุณ แม้ว่าพวกเขาจะไม่มีสิทธิ์ในการเข้าถึงไฟล์โดยตรง แต่พวกเขาสามารถร้องขอเว็บเพจและเว็บเซิร์ฟเวอร์ทำหน้าที่แทน คุณสามารถ จำกัด การเข้าถึงของผู้ใช้ที่ไม่ระบุชื่อด้วยความระมัดระวังเกี่ยวกับสิทธิ์ที่กระบวนการเซิร์ฟเวอร์เว็บมี ในลีนุกซ์หลายรุ่น, Apache ทำงานเป็นwww-dataผู้ใช้ แต่อาจแตกต่างกันได้ ใช้ps aux | grep httpdหรือps aux | grep apacheเพื่อดูว่า Apache ใช้งานอะไรในระบบของคุณ

หมายเหตุเกี่ยวกับการอนุญาต linux

Linux และระบบที่สอดคล้องกับ POSIX อื่น ๆ ใช้สิทธิ์ unix แบบดั้งเดิม มีบทความที่ยอดเยี่ยมเกี่ยวกับ Wikipedia เกี่ยวกับการอนุญาตของระบบไฟล์ดังนั้นฉันจะไม่ทำซ้ำทุกอย่างที่นี่ แต่มีบางสิ่งที่คุณควรระวัง

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

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

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

ปัญหากับ 777

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

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

กำหนดข้อกำหนด

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

ปรับปรุงโดยผู้ใช้คนเดียว

หากผู้ใช้เพียงรายเดียวเท่านั้นที่รับผิดชอบในการดูแลไซต์ให้ตั้งค่าเป็นเจ้าของผู้ใช้ในไดเรกทอรีเว็บไซต์และให้สิทธิ์ผู้ใช้แบบเต็ม rwx Apache ยังต้องการการเข้าถึงเพื่อให้สามารถให้บริการไฟล์ได้ดังนั้นให้ตั้งค่า www-data เป็นเจ้าของกลุ่มและให้สิทธิ์กลุ่ม rx

ในกรณีของคุณอีฟซึ่งมีชื่อผู้ใช้อาจeveเป็นผู้ใช้รายเดียวที่ดูแลcontoso.com:

chown -R eve contoso.com/
chgrp -R www-data contoso.com/
chmod -R 750 contoso.com/
chmod g+s contoso.com/
ls -l
drwxr-s--- 2 eve      www-data   4096 Feb  5 22:52 contoso.com

หากคุณมีโฟลเดอร์ที่ต้องเขียนโดย Apache คุณสามารถแก้ไขค่าสิทธิ์สำหรับเจ้าของกลุ่มเพื่อให้ข้อมูล www มีการเข้าถึงการเขียน

chmod g+w uploads
ls -l
drwxrws--- 2 eve      www-data   4096 Feb  5 22:52 uploads

ประโยชน์ของการกำหนดค่านี้คือมันจะกลายเป็นยากขึ้น (แต่ไม่ใช่เป็นไปไม่ได้ *) สำหรับผู้ใช้อื่น ๆ ในระบบที่จะสอดแนมเนื่องจากมีเพียงผู้ใช้และเจ้าของกลุ่มเท่านั้นที่สามารถเรียกดูไดเรกทอรีเว็บไซต์ของคุณ สิ่งนี้มีประโยชน์หากคุณมีข้อมูลลับในไฟล์กำหนดค่าของคุณ ระวังเกี่ยวกับ umask ของคุณ! หากคุณสร้างไฟล์ใหม่ที่นี่ค่าอนุญาตอาจเป็นค่าเริ่มต้นที่ 755 คุณสามารถเรียกใช้umask 027เพื่อให้ไฟล์ใหม่เริ่มต้นที่ 640 ( rw- r-- ---)

ดูแลโดยกลุ่มผู้ใช้

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

groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob

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

chown -R root fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 775 fabrikam.com
chmod g+s fabrikam.com
ls -l
drwxrwxr-x 2 root     dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

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

chown -R www-data uploads
ls -l
drwxrwxr-x 2 www-data     dev-fabrikam   4096 Feb  5 22:52 uploads

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

คุณสามารถมีเค้กของคุณและกินมันด้วย

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

chown -R www-data fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 570 fabrikam.com
chmod g+s fabrikam.com
ls -l
dr-xrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

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

chmod u+w uploads
ls -l
drwxrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

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

* การแยกสิทธิ์ Apache

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

เพื่อต่อสู้กับปัญหานี้มีหลายวิธีในการแยกสิทธิพิเศษใน Apache อย่างไรก็ตามแต่ละวิธีมาพร้อมกับประสิทธิภาพและข้อบกพร่องด้านความปลอดภัยที่หลากหลาย ในความคิดของฉันเว็บไซต์ใด ๆ ที่มีข้อกำหนดด้านความปลอดภัยที่สูงกว่าควรรันบนเซิร์ฟเวอร์เฉพาะแทนที่จะใช้ VirtualHosts บนเซิร์ฟเวอร์ที่ใช้ร่วมกัน

ข้อควรพิจารณาเพิ่มเติม

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

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

สำหรับเว็บไซต์ที่มีความต้องการที่ซับซ้อนมากขึ้นคุณอาจต้องการที่จะมองเข้าไปในการใช้งานของรายการควบคุมการเข้าถึง สิ่งเหล่านี้ช่วยให้การควบคุมสิทธิพิเศษมีความซับซ้อนยิ่งขึ้น

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

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

แนวทางของฉันมีดังต่อไปนี้:

• ฉันสร้างผู้ใช้ที่แยกกันสองคน หนึ่งรายการสำหรับการเข้าถึง SSH / SFTP (หากจำเป็น) ซึ่งจะเป็นเจ้าของไฟล์ทั้งหมดและอีกไฟล์หนึ่งสำหรับผู้ใช้ PHP FastCGI (ผู้ใช้เว็บไซต์จะเรียกใช้เป็น) ขอเรียกผู้ใช้เหล่านี้ตามลำดับbobและบ๊อบ-www
• bobจะมีสิทธิ์แบบเต็ม ( rwxในโฟลเดอร์, rw-บนไฟล์) เพื่อให้เขา / เธอสามารถอ่านและแก้ไขทั้งเว็บไซต์ได้
• กระบวนการ PHP FastCGI ต้องการสิทธิ์rxในโฟลเดอร์และสิทธิ์r -บนไฟล์ยกเว้นสำหรับโฟลเดอร์ที่เฉพาะเจาะจงเช่นcache/หรือuploads/ที่จำเป็นต้องได้รับอนุญาต "เขียน" เพื่อให้ PHP FastCGI มีความสามารถนี้มันจะทำงานเป็นbob-wwwและbob-wwwจะถูกเพิ่มในกลุ่มbob ที่สร้างขึ้นโดยอัตโนมัติ
• ตอนนี้เราให้แน่ใจว่าเจ้าของและกลุ่มของไดเรกทอรีทั้งหมดและไฟล์บ๊อบบ๊อบ
• บางสิ่งบางอย่างขาดหายไป: แม้เราจะใช้ FastCGI แต่ Apache ยังคงต้องการการเข้าถึงแบบอ่านสำหรับเนื้อหาแบบคงที่หรือ htaccess ไฟล์ว่ามันจะพยายามที่จะอ่านถ้ามีการตั้งค่าอย่างอื่นมากกว่าAllowOverride Noneเพื่อหลีกเลี่ยงการใช้oส่วนหนึ่งของสิทธิฉันจะเพิ่มwww ข้อมูลของผู้ใช้ในผมบ๊อบกลุ่ม

ขณะนี้:

• ในการควบคุมสิ่งที่นักพัฒนาสามารถทำเราสามารถเล่นกับยูเป็นส่วนหนึ่งของสิทธิมนุษยชน ( แต่นี้หมายเหตุด้านล่าง)
• จะควบคุมสิ่ง Apache และ PHP สามารถทำเราสามารถเล่นกับกรัมส่วนหนึ่งของสิทธิมนุษยชน
• oส่วนที่มีการตั้งค่าเป็น 0 เสมอเพื่อให้คนอื่นบนเซิร์ฟเวอร์สามารถอ่านหรือแก้ไขเว็บไซต์
• ไม่มีปัญหาเมื่อผู้ใช้bobสร้างไฟล์ใหม่เนื่องจากมันจะเป็นของกลุ่มหลัก ( bob ) โดยอัตโนมัติ

นี่คือการสรุป แต่ในสถานการณ์นี้บ๊อบได้รับอนุญาตให้ SSH หากไม่มีผู้ใช้ที่ได้รับอนุญาตให้แก้ไขเว็บไซต์ (เช่นลูกค้าปรับเปลี่ยนเว็บไซต์ผ่านแผงการดูแลระบบ CMS และไม่มีความรู้เกี่ยวกับ Linux) ให้สร้างผู้ใช้สองคนต่อไป แต่ให้/bin/falseเปลือกสำหรับบ็อบเช่นกันและ ปิดใช้งานการเข้าสู่ระบบ

    adduser --home /var/www/bobwebsite --shell /bin/bash bob
    adduser --no-create-home --shell /bin/false --disabled-login --ingroup bob bob-www
    adduser www-data bob
    cd /var/www/bobwebsite
    chown -R bob:bob .
    find -type d -exec chmod 750 {} \;
    find -type f -exec chmod 640 {} \;

หมายเหตุ:คนมักจะลืมว่าการ จำกัด สิทธิ์u (เจ้าของ) เป็นส่วนใหญ่เวลาไร้ประโยชน์และไม่ปลอดภัยเนื่องจากเจ้าของไฟล์สามารถเรียกใช้chmodคำสั่งแม้สิทธิ์เป็น 000

บอกฉันว่าวิธีการของฉันมีปัญหาด้านความปลอดภัยหรือไม่เพราะฉันไม่แน่ใจ 100% แต่เป็นสิ่งที่ฉันใช้

ฉันคิดว่าการกำหนดค่านี้มีปัญหา: เมื่อ PHP / Apache สร้างไฟล์ใหม่ (เช่นอัปโหลด) มันจะเป็นของbob-www: bobและbobจะสามารถอ่านได้เท่านั้น บางที setuid ในไดเรกทอรีสามารถแก้ปัญหาได้

เมื่อพิจารณาจากอันดับที่ google ในคำตอบที่ดีเลิศฉันคิดว่ามีสิ่งหนึ่งที่ควรสังเกตและฉันไม่สามารถทิ้งโน้ตไว้หลังคำตอบได้

หากคุณวางแผนที่จะใช้ www-data ในฐานะเจ้าของและ dev-fabrikam เป็นกลุ่มที่มีสิทธิ์ 570 ในไดเรกทอรี (หรือไฟล์) เป็นสิ่งสำคัญที่จะต้องทราบว่าLinux จะไม่สนใจ setuidดังนั้นไฟล์ใหม่ทั้งหมดจะเป็นของ ผู้ใช้ที่สร้างพวกเขา ซึ่งหมายความว่าหลังจากสร้างไดเรกทอรีและไฟล์ใหม่คุณจะต้องใช้สิ่งที่คล้ายกับ:

chown -R www-data /newdirectory/
chmod -R 570 /newdirectory/

ใน Ubuntu 12.04 สำหรับ Rackspace OpenStack ฉันมีปัญหาแปลก ๆ ที่ฉันไม่สามารถได้รับอนุญาต 570 ให้ทำงานจนกว่าฉันจะรีบูตเซิร์ฟเวอร์ซึ่งแก้ไขปัญหาได้อย่างน่าอัศจรรย์ การสูญเสียเส้นผมในอัตราที่เพิ่มขึ้นมากกว่าปัญหาที่ดูเหมือนง่าย ๆ ....

ฉันจะใช้การกำหนดค่านี้:

1. ไดเรกทอรีทั้งหมดยกเว้นการอัปโหลดหนึ่งชุดให้กับเจ้าของrootและกลุ่มสิทธิ์ที่จะroot0755
2. ไฟล์ทั้งหมดที่ตั้งให้กับเจ้าของrootและกลุ่มสิทธิ์ที่จะroot0644
3. ไดเรกทอรีอัปโหลดไปยังเจ้าของตั้งrootกลุ่มสิทธิ์ที่จะwww-data 1770หมุดเล็ก ๆ ไม่อนุญาตให้เจ้าของกลุ่มลบหรือเปลี่ยนชื่อไดเรกทอรีและไฟล์ภายใน
4. ภายในโฟลเดอร์อัปโหลดไดเรกทอรีใหม่ที่มีwww-dataผู้ใช้และกลุ่มเจ้าของและ0700สิทธิ์สำหรับwww-dataผู้ใช้แต่ละรายที่อัปโหลดไฟล์
5. การกำหนดค่า Apache:

ปฏิเสธAllowOverrideและIndexในไดเรกทอรีอัปโหลดเพื่อให้ Apache ไม่อ่าน.htaccessไฟล์และผู้ใช้ Apache ไม่สามารถจัดทำดัชนีเนื้อหาของโฟลเดอร์อัพโหลดได้:

<Directory /siteDir>
   Options -Indexes
</Directory>

<Directory /siteDir/uploadDir>
   AllowOverride none
</Directory>

6. php.iniการกำหนดค่า:

open_basedir = /siteDir:/tmp:/usr/share/phpmyadmin
post_max_size = 5M
file_uploads = On
upload_max_filesize = 3M
max_file_uploads = 20

กับการกำหนดค่านี้www-dataผู้ใช้จะไม่สามารถที่จะได้รับไดเรกทอรีภายในอื่น ๆ กว่าและsiteDir/ /tmp /usr/share/phpmyadminนอกจากนี้คุณสามารถควบคุมขนาดไฟล์สูงสุดขนาดโพสต์สูงสุดและไฟล์สูงสุดที่จะอัปโหลดในคำขอเดียวกัน

เมื่อคุณมีผู้ใช้ FTP ชื่อ "leo" จำเป็นต้องอัปโหลดไฟล์ไปยัง example.com เว็บไดเรกทอรีและคุณต้องการให้ผู้ใช้ "apache" ของคุณเพื่อสร้างไฟล์ uploa-files / session / cache ในแคชไดเรกทอรีจากนั้นทำดังนี้:

คำสั่งนี้กำหนดให้ leo เป็นเจ้าของและกลุ่มเป็น apache ให้กับ example.com ผู้ใช้ apache เป็นส่วนหนึ่งของกลุ่ม apache ดังนั้นมันจะสืบทอดสิทธิ์ของกลุ่ม apache

chown -R leo: apache example.com

คำสั่งอื่นที่รับประกันสิทธิ์ที่ถูกต้องและตอบสนองความกังวลด้านความปลอดภัยเช่นกัน

chmod -R 2774 example.com

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

ต่อไปนี้เป็นประโยชน์ในการทำความเข้าใจหมายเลขการอนุญาต

Number  Octal Permission Representation
0   No permission
1   Execute permission
2   Write permission
3   Execute and write permission: 1 (execute) + 2 (write) = 3
4   Read permission
5   Read and execute permission: 4 (read) + 1 (execute) = 5
6   Read and write permission: 4 (read) + 2 (write) = 6
7   All permissions: 4 (read) + 2 (write) + 1 (execute) = 7

IMO ต้องคำนึงถึง:

• คุณเชื่อถือกระบวนการที่อ่านไฟล์ของคุณหรือไม่? เช่น. PHP?

สมมติว่าคุณมีเซิร์ฟเวอร์ที่มีข้อมูลต่าง ๆ ภายใต้การทดสอบของผู้ใช้

ผู้ใช้ 'ทดสอบ' มี:

• ข้อมูลของเขาใน $HOMEDIR
• จดหมายของเขาใน $MAIL
• ข้อมูลของเขาสำหรับเว็บใน /var/www/test

ตอนนี้ลองคิดถึง:

• เว็บแอปทำงานภายใต้testผู้ใช้ (PHP-FPM) - มันสามารถลบไฟล์ใด ๆ ของเขา!
• เว็บแอปทำงานภายใต้testกลุ่ม (PHP-FPM) - มันสามารถลบไฟล์ใด ๆ ที่ไดเรกทอรีมี 'w' สำหรับกลุ่มและสามารถแก้ไขไฟล์ใด ๆ ที่มี 'r' สำหรับกลุ่ม; และมันยังสามารถอ่านได้ - ปุ่ม ssh ของคุณเช่น!

สมมติว่า PHP นั้นผิดพลาดและคุณเชื่อมั่นopen_basedirหรือไม่? คุณทำchrootกระบวนการ PHP ของคุณหรือไม่ คุณทำอะไรไม่ได้คุณต้องการให้มันรวบรวมข้อมูลผ่านระบบไฟล์ทั้งหมดหรือไม่?

กระบวนการแอปบนเว็บของคุณเช่น PHP-FPM ดังนั้นควร:

• จำกัด เฉพาะเส้นทางที่ต้องการผ่าน chroot
• ไม่ควรทำงานภายใต้สิทธิ์ผู้ใช้หลักหรือสิทธิ์กลุ่มหลักของเจ้าของข้อมูล

ดังนั้นคุณสามารถทำ:

• ผู้ใช้ทดสอบคือ: test:test
• ผู้ใช้ทดสอบอยู่ในกลุ่มรองเช่น test-www
• เว็บแอป (PHP-FPM) ทำงานภายใต้ test-www:test-www
• ทดสอบผู้ใช้หากเขาต้องการให้เว็บแอปอ่านไฟล์ของเขาได้: chmod u=rwX,g=rX,o= /var/www/test/public
• ทดสอบผู้ใช้หากเขาต้องการให้เว็บแอปสามารถเขียนลงในพา ธ ข้อมูลเว็บของเขา chmod u=rwX,g=rwXs,o= /var/www/test/public/upload (ดังนั้นแอปจะสร้างไฟล์ใหม่เป็น: test-www:test-www- จะมีกลุ่มทดสอบ www เนื่องจาก setgid ในไดเรกทอรี!)

ดังนั้นหากขั้นตอนการตรวจสอบเว็บจะปลอมมันก็จะอ่านไฟล์เฉพาะที่จะมีกลุ่มอ่านและมันจะสามารถเขียนถึงuploaddir เท่านั้น ฉันอยากจะแนะนำให้มีuploaddir บนระบบไฟล์ที่มีnoexec,nodev,nosuid mountตัวเลือกและมีการตรวจสอบอย่างต่อเนื่องสำหรับไฟล์ bizzare ใหม่ในไดเรกทอรีนั้นรวมทั้งตรวจสอบกระบวนการใหม่ภายใต้test-www uid

บน Linux สามารถใช้ ACL เพื่อปรับแต่งการอนุญาตที่ดีขึ้น หากมีมากกว่าหนึ่งคนที่จะอัปโหลดข้อมูลบนเว็บควรแยกบัญชีบุคคลออกจากบัญชีที่ใช้ในการอัปโหลดไฟล์ข้อมูลบนเว็บเช่น เพื่อสร้างบัญชีใหม่เช่น test-uploadและผู้ใช้ทดสอบจะจัดการคีย์ ssh เพื่อ จำกัด บุคคลที่สามารถ ssh / sftp ที่นั่น sshd_configรู้ตัวExposeAuthInfoเลือกจึงสามารถกำหนดค่าให้เข้าสู่ระบบได้ว่าจะใช้คีย์ ssh ใดในการอัพโหลดข้อมูล

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