ผู้ใช้ต่อโฮสต์เสมือนใน Nginx


31

เป็นไปได้ใน nginx กำหนดค่าผู้ใช้ที่แตกต่างกันต่อโฮสต์เสมือน?

สิ่งที่ต้องการ

 server {
     user myprojectuser myprojectgroup;
     ...
 }

คำตอบ:


7

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


2
ดังนั้นจะไม่มีวิธีซ่อนไฟล์ของผู้ใช้จากผู้ใช้รายอื่นหรือไม่? เนื้อหาทั้งหมดของผู้ใช้ควรอ่านได้จาก www-data?
Alex Netkachov

1
การทำให้ไฟล์สามารถเข้าถึง www-data ได้ (หรือสิ่งที่ผู้ใช้เว็บเซิร์ฟเวอร์เรียกใช้) ไม่ว่าในกรณีใดก็ตาม
womble

2
กำหนดกลุ่มของเอกสารwww-dataและ perms 0710เมื่อคุณตั้งค่า vhost (เนื่องจากจำเป็นต้องรูทเพื่อกำหนดค่า nginx จึงไม่ใช่ปัญหาที่ระบบอัตโนมัติของคุณจะตั้งค่าการอนุญาตที่จำเป็นด้วย) จากนั้นเนื้อหาของ docroot จะต้องเป็นo+xไดเรกทอรีและo+rไฟล์เท่านั้น
womble

13
ระวัง: หากสคริปต์ PHP (หรือกระบวนการ cgi-bin) ทำงานภายใต้www-dataผู้ใช้ทุกคนที่สามารถให้บริการสคริปต์ PHP หรือกระบวนการ cgi-bin สามารถเข้าถึงไฟล์ใด ๆ ที่www-dataผู้ใช้สามารถเข้าถึงได้ สิ่งนี้ดูเหมือนจะไม่ชัดเจนสำหรับทุกคนที่เก็บรหัสผ่านฐานข้อมูลในconfig.php.incหรือคล้ายกันบนเครื่องที่ใช้ร่วมกัน
Ivan Vučica

2
@Ricalsin โปรดจำไว้ว่า UNIX เป็นระบบปฏิบัติการหลายผู้ใช้และเซิร์ฟเวอร์สามารถมีผู้ใช้มากกว่าหนึ่งคน ยกตัวอย่างเช่นและpeter พวกเขามีพื้นที่หน้าเว็บของพวกเขาในjohn ~/public_htmlขาดวิธีการที่แตกต่างกันไม่ได้กล่าวถึงโดยใด ๆ ของคนที่คุยกันเรื่องนี้ข้างต้นสคริปต์ .php www-dataมีสิทธิ์เดียวกันเป็นเว็บเซิร์ฟเวอร์เป็นมันก็ยังดำเนินการภายใต้ ซึ่งหมายความว่าเหมือนกับเว็บเซิร์ฟเวอร์และล่าม PHP สามารถอ่านสคริปต์. php อื่น ๆ ได้
Ivan Vučica

9

ใช่. เป็นไปได้และแนะนำเพื่อความปลอดภัยเป็นพิเศษ (ดูสาเหตุด้านล่าง)

เมื่อพิจารณาว่าคุณใช้ PHP-FPM (คุณอาจเป็นเพราะเป็นเรื่องปกติ) คุณสามารถสร้างสปูลที่เป็นเจ้าของโดยผู้ใช้ที่แตกต่างกันสำหรับแต่ละโดเมน

PS:ฉันเขียนรายละเอียดการสอนทีละขั้นตอนที่นี่:

https://learnwithdaniel.com/2019/06/user-per-virtual-host-nginx/

1. สร้างสิ่งของ:

เพิ่มสปูลไปยัง/etc/php/7.0/fpm/pool.d/www.confหรือสร้าง.confไฟล์ใหม่สำหรับสปูลใหม่แต่ละอัน

สปูล # 1 (myuser1):

[myprojectuser1]
user = myuser1
group = myprojectgroup
..
listen = /run/php/myuser1.sock
...  
listen.owner = www-data
listen.group = www-data

สปูล # 2 (myuser2):

[myprojectuser2]
user = myuser2
group = myprojectgroup
..
listen = /run/php/myuser2.sock
...  
listen.owner = www-data
listen.group = www-data

PS: ทำให้ Listen.owner / Listen.group ของคุณเป็นผู้ใช้ nginx คนเดียวกัน (โดยปกติคือwww-data )

2. กำหนดแต่ละสปูลให้บล็อกเซิร์ฟเวอร์ (โฮสต์เสมือนสำหรับผู้ใช้ apache):

โฮสต์ 1:

server {
  ...
  location ~ \.php$ {
    fastcgi_pass unix:/run/php/myuser1.sock;
  }
  ...
}

โฮสต์ 2:

server {
  ...
  location ~ \.php$ {
    fastcgi_pass unix:/run/php/myuser2.sock;
  }
  ...
}

เริ่มบริการ FPM และ NGINX ใหม่

sudo /etc/init.d/php7.0-fpm restart
sudo service nginx restart

การทดสอบ:

สร้างไฟล์ pinfo.php (หรือชื่ออะไรก็ได้) ที่จะแสดงผู้ใช้กระบวนการปัจจุบัน:

<?php 
echo str_replace("\n", '<br>', shell_exec('ps -u -p '.getmypid()));

หรือสร้างไฟล์pinfo.phpผ่าน bash:

echo "<?php echo str_replace(\"\\n\", '<br>', shell_exec('ps -u -p '.getmypid()));" > pinfo.php

จากนั้นเปิด " http: //.../pinfo.php " บนเบราว์เซอร์ของคุณ


เหตุใดจึงต้องใช้ผู้ใช้หลายคน (เหตุผลด้านความปลอดภัย):

หากคุณใช้งานเว็บไซต์ทั้งหมดของคุณภายใต้ผู้ใช้เดียวกัน ( www-data ) การเรียก PHP ไปยังระบบ () / passthru () / exec () จะสามารถเข้าถึงเว็บไซต์ทั้งหมดได้! NGINX จะไม่ปกป้องคุณจากสิ่งนี้ PHP เป็นเพียงตัวอย่าง แต่ภาษาเว็บเซิร์ฟเวอร์ยอดนิยมใด ๆ มีการโทรที่คล้ายกัน ในฐานะที่เป็นแฮ็กเกอร์คุณสามารถ " ls .. " เพื่อสำรวจเว็บไซต์ทั้งหมดและ " cp / echo / mv " เพื่อเขียนรหัสของคุณเองในไฟล์ใด ๆ (รวมถึงไฟล์เว็บไซต์อื่น) แม้ว่าเว็บไซต์ทั้งหมดบนเซิร์ฟเวอร์จะเป็นเจ้าของโดยบุคคลเดียวกัน (เช่นคุณ) ขอแนะนำให้เรียกใช้แต่ละเว็บไซต์ด้วยผู้ใช้อื่นเนื่องจากจะป้องกันไม่ให้แฮกเกอร์ / ไวรัสในที่สุด (เช่นไวรัส Wordpress) เข้าถึงเว็บไซต์อื่นของคุณ


5

ในการตอบสนองต่อความคิดเห็นของ Ivan ข้างต้นและดูเหมือนว่าจะใช้กับ OP ได้ สองสิ่ง:

  1. รากเอกสารการประยุกต์ใช้จะเป็นสิ่งที่ชอบและ/blah/peterWeb/html /blah/johnWeb/htmlทั้ง NGINX และ Apache2 จะไม่อนุญาตให้หนึ่งอ่านหรือดำเนินการในไดเรกทอรีอื่นแม้ว่าพวกเขาทั้งสองกำลังเรียกใช้ข้อมูล www เป็นกลุ่ม

  2. การวางแผนผังไดเรกทอรีแต่ละรายการภายใต้การอนุญาตของผู้ใช้จะอนุญาตให้ผู้ใช้แต่ละรายสามารถ ssh / login เข้าสู่ระบบ UNIX และทำให้ไดเรกทอรีของพวกเขาเป็นส่วนตัวโดยไม่ต้องใส่ผู้ใช้แต่ละคนเข้าไปในกลุ่ม www-data ถ้าคุณเห็นด้วยประโยคของคุณ:

    ผู้ใช้ทุกคนที่สามารถให้บริการสคริปต์ PHP หรือกระบวนการ cgi-bin สามารถเข้าถึงไฟล์ใดก็ได้ที่ผู้ใช้ www-data สามารถเข้าถึงได้

    อาจถูกเขียนอย่างแม่นยำมากขึ้นเมื่อ:

    ผู้ใช้ทุกคนที่คุณใส่ในกลุ่มเดียวกันกับเซิร์ฟเวอร์ apache / nginx (www-data) สามารถทำสิ่งที่พวกเขาต้องการ (รวมถึงการเรียกใช้สคริปต์ php) ในไฟล์ใด ๆ ที่สามารถเข้าถึงได้ (ซึ่งจะเป็นทุกอย่างบนเว็บ เซิร์ฟเวอร์)

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


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

(นอกจากนี้การเพิ่มคำตอบแทนที่จะแสดงความคิดเห็นเป็นการละเมิดของเว็บไซต์ประเภท StackOverflow สร้างความประทับใจให้คุณจริง ๆ โปรดให้คำตอบโปรดหลีกเลี่ยงสิ่งนั้น)
Ivan Vučica

@ IvanVučicaอัปเดตและเพิ่มลิงก์ที่มีประโยชน์ซึ่งสนับสนุนคำแนะนำของคุณ ขอบคุณ
Ricalsin
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.