/ usr / sbin / nologin เป็นเชลล์ล็อกอินให้บริการเพื่อความปลอดภัยหรือไม่

ใน/etc/passwdไฟล์ของฉันฉันจะเห็นว่าwww-dataผู้ใช้ที่ Apache ใช้รวมถึงผู้ใช้ระบบทุกประเภทมีเปลือกล็อกอิน/usr/sbin/nologinหรืออย่างใดอย่างหนึ่ง /bin/falseตัวอย่างเช่นนี่คือการเลือกบรรทัด:

daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
games:x:5:60:games:/usr/games:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
syslog:x:101:104::/home/syslog:/bin/false
whoopsie:x:109:116::/nonexistent:/bin/false
mark:x:1000:1000:mark,,,:/home/mark:/bin/bash

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

mark@lunchbox:~$ sudo su www-data
This account is currently not available.
mark@lunchbox:~$ sudo su syslog
mark@lunchbox:~$ 

แน่นอนว่ามันไม่สะดวกนักเพราะฉันยังสามารถเปิดตัวเชลล์สำหรับพวกเขาผ่านวิธีการเช่นนี้:

mark@lunchbox:~$ sudo -u www-data /bin/bash
www-data@lunchbox:~$ 

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

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

- https://serverfault.com/a/559315/147556

เชลล์สำหรับผู้ใช้ www-data ถูกตั้งค่าเป็น / usr / sbin / nologin และมันถูกตั้งค่าด้วยเหตุผลที่ดีมาก

- https://askubuntu.com/a/486661/119754

[บัญชีระบบ] อาจเป็นช่องโหว่ด้านความปลอดภัยโดยเฉพาะหากเปิดใช้งานเชลล์:

• ไม่ดี

  bin:x:1:1:bin:/bin:/bin/sh

• ดี

  bin:x:1:1:bin:/bin:/sbin/nologin

- https://unix.stackexchange.com/a/78996/29001

เพื่อเหตุผลด้านความปลอดภัยฉันได้สร้างบัญชีผู้ใช้โดยไม่มีเชลล์ล็อกอินสำหรับเรียกใช้เซิร์ฟเวอร์ Tomcat:

# groupadd tomcat
# useradd -g tomcat -s /usr/sbin/nologin -m -d /home/tomcat tomcat

- http://www.puschitz.com/InstallingTomcat.html

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

การโจมตีใดที่เราพยายามปกป้องตนเองโดยไม่ให้เชลล์ล็อกอินจริงแก่ผู้ใช้

หากคุณดูที่nologinหน้าคนคุณจะเห็นคำอธิบายต่อไปนี้

สิ่งที่สกัดมา

nologin แสดงข้อความว่าบัญชีไม่สามารถใช้งานได้และออกจากที่ไม่เป็นศูนย์ มันมีจุดมุ่งหมายเพื่อเป็นช่องเชลล์การแทนที่เพื่อปฏิเสธการเข้าสู่บัญชี

หากไฟล์/etc/nologin.txtมีอยู่nologinแสดงเนื้อหาให้กับผู้ใช้แทนข้อความเริ่มต้น

รหัสทางออกที่ส่งคืนโดยnologinเป็น 1 เสมอ

ดังนั้นจุดประสงค์ที่แท้จริงของnologinมันก็เพื่อที่ว่าเมื่อผู้ใช้พยายามที่จะเข้าสู่ระบบด้วยบัญชีที่ใช้ใน/etc/passwdนั้นเพื่อให้พวกเขามีข้อความที่เป็นมิตรกับผู้ใช้และสคริปต์ / คำสั่งใด ๆ ที่พยายามใช้ การเข้าสู่ระบบนี้ได้รับรหัสทางออก 1

ความปลอดภัย

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

เหตุใดจึงถือว่ามีค่าด้วยความเคารพต่อความปลอดภัย

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

ใช้อย่างใดอย่างหนึ่งnologinหรือ/bin/falseบรรลุสิ่งนี้ การ จำกัด พื้นผิวการโจมตีของระบบของคุณเป็นเทคนิคทั่วไปในโลกความปลอดภัยไม่ว่าจะเป็นการปิดใช้งานบริการบนพอร์ตเฉพาะหรือ จำกัด ลักษณะของการเข้าสู่ระบบในระบบของตน

ยังคงมีลบล้างอื่น ๆ nologinสำหรับการใช้ ตัวอย่างเช่นscpจะไม่ทำงานกับบัญชีผู้ใช้ที่ไม่ได้กำหนดเชลล์จริงอีกต่อไปตามที่อธิบายไว้ในคำถาม & คำตอบของ ServerFault นี้: อะไรคือความแตกต่างระหว่าง / sbin / nologin และ / bin / false? .

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

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

ฉันขอแนะนำให้คุณอ่านคำตอบที่ยอดเยี่ยมนี้โดย Gilles ที่ซึ่งเขาได้ให้ลิงก์ไปยังข้อบกพร่องบางอย่างเช่นกัน

มีข้อผิดพลาดเกี่ยวกับปัญหานี้ใน Debian (274229, 330882, 581899) ซึ่งปัจจุบันเปิดและจัดประเภทเป็น "สิ่งที่ปรารถนา" ฉันมักจะยอมรับว่าสิ่งเหล่านี้เป็นข้อบกพร่องและผู้ใช้ระบบควรมี / bin / false เป็นเปลือกของพวกเขาเว้นแต่จะจำเป็นต้องทำอย่างอื่น

หากต้องการเพิ่มคำตอบที่ยอดเยี่ยมของ @slm และ @ramesh:

ใช่ดังที่คุณได้ชี้ให้เห็นคุณยังคงสามารถเปลี่ยนไปใช้ผู้ใช้ที่มี nologin เป็นเชลล์เริ่มต้นได้โดยการรันsudoด้วยเชลล์ที่กำหนดไว้ แต่ในกรณีนี้คุณต้อง:

1. เข้าสู่ระบบในฐานะผู้ใช้รายอื่นที่มีเชลล์ที่ถูกต้อง
2. กำหนดสิทธิ์ sudo ไว้ให้ผู้ใช้นั้นเพื่อเรียกใช้suคำสั่งและ
3. มีความพยายามของคุณในการบันทึกลงในบันทึก sudoers (สมมติว่าเปิดใช้งานการบันทึก sudo)

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

นอกเหนือจากคำตอบที่ยอดเยี่ยมที่ได้รับแล้วมันยังมีวัตถุประสงค์อีกอย่างหนึ่ง

หากคุณรัน FTP daemon บนเซิร์ฟเวอร์ของคุณจะทำการตรวจสอบเชลล์ล็อกอินของผู้ใช้ที่พยายามเข้าสู่ระบบ หากเชลล์ไม่อยู่ในรายการ/etc/shellsมันจะไม่อนุญาตให้พวกเขาเข้าสู่ระบบ ดังนั้นการให้บัญชี daemon เชลล์พิเศษป้องกันไม่ให้ใครบางคนแก้ไขบัญชีผ่านทาง FTP

ถัดจากคำตอบที่ยอดเยี่ยมที่ได้รับแล้วฉันสามารถคิดถึงสถานการณ์ต่อไปนี้

ข้อบกพร่องด้านความปลอดภัยในบริการที่ทำงานในฐานะผู้ใช้ที่ จำกัด อนุญาตให้เขียนไฟล์ในฐานะผู้ใช้นั้น ไฟล์นี้สามารถเป็น ~ / .ssh / authorized_keys

วิธีนี้ช่วยให้ผู้โจมตีเข้าสู่ระบบโดยตรงในเชลล์ซึ่งจะทำให้การเพิ่มสิทธิพิเศษทำได้ง่ายขึ้นมาก

การไม่อนุญาตเชลล์การเข้าสู่ระบบจะทำให้ตัวเลือกนี้ยากขึ้นมาก

โดยทั่วไปฉันจะบอกว่า / bin / false และ / sbin / nologin เหมือนกัน - แต่ฉันคิดว่ามันขึ้นอยู่กับเซิร์ฟเวอร์ SSH ที่คุณใช้

มันจะเป็นการระมัดระวังสำหรับฉันที่จะชี้ให้เห็นว่าการหาประโยชน์ล่าสุดนี้ใน OpenSSH ดูเหมือนจะส่งผลกระทบต่อ / bin / การเข้าสู่ระบบที่ผิดพลาด แต่ไม่ใช่ / sbin / nologin อย่างไรก็ตามมันระบุว่า Dropbear นั้นแตกต่างกันในลักษณะนี้ (รวมถึงการหาประโยชน์โดยเฉพาะนั้นใช้กับ OpenSSH)

การใช้ประโยชน์มีผลต่อเวอร์ชันส่วนใหญ่:

7.2p1 และต่ำกว่า (ทุกรุ่น; ย้อนหลังไป ~ 20 ปี) ด้วยการเปิดใช้งานการส่งต่อ X11

https://www.exploit-db.com/exploits/39569/

ดังนั้นตามนี้ - ฉันเองจะทำ / sbin / nologin แต่ฉันไม่แน่ใจว่าสิ่งนี้อาจส่งผลกระทบต่อบริการที่สร้างรายการ / bin / false ใน / etc / passwd คุณสามารถทดลองและดูผลลัพธ์ของคุณได้ แต่ต้องยอมรับความเสี่ยงเอง! ฉันคิดว่ากรณีที่เลวร้ายที่สุดคุณสามารถเปลี่ยนกลับมาและเริ่มบริการใด ๆ ที่ส่งผลกระทบต่อ โดยส่วนตัวฉันมีบางรายการที่ใช้ / bin / false - ไม่แน่ใจว่าฉันต้องการรบกวนสิ่งนี้เนื่องจากการส่งต่อ X11 ไม่ใช่สิ่งที่ฉันได้เปิดใช้งาน)

หากคุณใช้ OpenSSH (ฉันคิดว่าหลายคน ... ) และเปิดใช้งานการส่งต่อ X11 - คุณอาจต้องการพิจารณา / sbin / nologin (หรืออาจเปลี่ยนเป็น Dropbear)

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

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

ใช่มันมีจุดประสงค์ด้านความปลอดภัย มันเป็นมาตรการป้องกันในเชิงลึก

เหตุผลหลักที่มีจุดประสงค์คือมีซอฟต์แวร์หลายบิตที่จะตรวจสอบข้อมูลการเข้าสู่ระบบบางรูปแบบสำหรับผู้ใช้ที่ระบุจากนั้นใช้ล็อกอินเชลล์ของผู้ใช้นั้นเพื่อรันคำสั่ง บางทีตัวอย่างที่เด่นที่สุดคือ SSH หากคุณพิสูจน์ตัวตนในฐานะผู้ใช้ผ่าน SSH ได้สำเร็จ SSH จะเรียกใช้ล็อกอินเชลล์ของผู้ใช้ (หรือใช้เพื่อเรียกใช้คำสั่งที่คุณระบุหากคุณใช้ssh someuser@example.com 'command to run'ไวยากรณ์)

แน่นอนว่าผู้โจมตีจะไม่สามารถตรวจสอบสิทธิ์ในฐานะผู้ใช้ได้เลย แต่สมมติว่าสถานการณ์ต่อไปนี้เกิดขึ้น:

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

ตอนนี้ผู้โจมตีของคุณสามารถเขียนรหัสสาธารณะ SSH ไป~/.ssh/authorized_keysแล้วจากนั้นเข้าสู่ SSH และ - บูม! - พวกเขามีสิทธิ์เข้าถึงเชลล์ไปยังเซิร์ฟเวอร์ของคุณ

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

ในกรณีที่สถานการณ์นี้น่าสมมุติมากผมต้องการที่จะทราบว่าผมได้รับการกำหนดเป้าหมายโดยแม่นยำการโจมตีครั้งนี้ในบางจุดในปี 2015 ประมาณหนึ่งปีหลังจากที่ผมถามคำถามนี้ เหมือนคนงี่เง่าที่ถูกทิ้งร้างฉันจะทิ้งอินสแตนซ์ของ Redis โดยไม่มีรหัสผ่านที่เปิดให้คนทั่วโลก มันได้รับการกำหนดเป้าหมายจากการโจมตีรอยแตก Redis ซึ่งผู้โจมตีแทรกกุญแจสาธารณะ SSH ลงในฐานข้อมูล Redis ของคุณจากนั้นส่งคำสั่งที่บอกให้ Redis เขียนเนื้อหาของฐานข้อมูล.ssh/authorized_keysแล้วพยายาม SSH เข้าฉันถูกบันทึกไว้จากผลที่ตามมา ของความสามารถของฉันเท่านั้นโดยข้อเท็จจริงที่ว่าผู้ดูแลredis-serverแพคเกจ Apt (ซึ่งฉันเคยติดตั้ง Redis) มีภูมิปัญญาที่จะทำให้มันทำงาน Redis เป็นredisผู้ใช้ที่ไม่มีโฮมไดเร็กทอรีหรือล็อกอินเชลล์ หากไม่ใช่สำหรับพวกเขาเซิร์ฟเวอร์ของฉันน่าจะถูกเรียกคืนหรือจบลงด้วยการเป็นส่วนหนึ่งของบ็อตเน็ตของแฮ็กเกอร์บางคน

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