ฉันกำลังพยายามทำความเข้าใจข้อโต้แย้งทางเทคนิค/ผลกระทบด้านความปลอดภัยระหว่าง ssh'ing กับรูทโดยตรง หรือสร้างผู้ใช้ sudo เสริมในบริบทของการดูแลเซิร์ฟเวอร์ เพื่อความชัดเจน เรากำลังพูดถึงเซิร์ฟเวอร์ที่เป็นของผู้ดูแลระบบคนเดียว สำหรับคนหลายคนที่ทำงานบนเครื่อง เห็นได้ชัดว่ามีประโยชน์ในการตรวจสอบของการมีผู้ใช้ที่ไม่ซ้ำกันสำหรับแต่ละบุคคลจริงและการอนุญาตแบบละเอียด
ความคิดของฉันคือ ถ้านี่เป็นสถานีเดสก์ท็อป ก็สมเหตุสมผลและแนะนำให้ใช้ผู้ใช้ที่ไม่ใช่รูทสำหรับสิ่งต่างๆ รายวัน แต่บนเซิร์ฟเวอร์ คุณมักจะลงชื่อเข้าใช้เพื่อบำรุงรักษา และ 99% ของจำนวนครั้งที่กิจกรรมทั้งหมดของคุณต้องใช้รูท สิทธิ์
ดังนั้นมีประโยชน์ด้านความปลอดภัยในการสร้างผู้ใช้ "พร็อกซี" ที่คุณจะ sudo เพื่อรูทต่อไปแทนที่จะให้สิทธิ์เข้าถึงรูท ssh โดยตรง
ข้อดีเพียงอย่างเดียวที่ฉันคิดได้คือความปลอดภัยผ่านความสับสน เช่น ปกติแล้วบอทจะพยายามตรวจสอบผู้ใช้ "รูท" แต่จากที่ฉันเห็น ถ้าผู้ใช้ sudoers ถูกบุกรุก มันก็เหมือนกับการประนีประนอมกับผู้ใช้รูท ดังนั้นจบเกม
นอกจากนี้ เฟรมเวิร์กการดูแลระบบระยะไกล, ระบบ NAS, ไฮเปอร์ไวเซอร์ส่วนใหญ่สนับสนุนการใช้ผู้ใช้รูทสำหรับการเข้าสู่ระบบเว็บ
สิ่งหนึ่งที่ควรพิจารณา: หากใช้คีย์ SSH สำหรับการตรวจสอบระยะไกล จะเกิดอะไรขึ้นหากคีย์ส่วนตัวถูกบุกรุก
หากรูท: การเข้าถึงรูทถูกบุกรุก หวังว่าคุณจะไม่ได้ใช้รหัสนั้นสำหรับการเข้าถึงรูทในหลาย ๆ เครื่อง
หากผู้ใช้: ผู้ใช้รายนั้นถูกบุกรุก อย่างไรก็ตามผู้โจมตีอาจไม่สามารถเรียกใช้ sudo เนื่องจากรหัสผ่านของผู้ใช้ไม่ได้ถูกบุกรุก ยัง. (สมมติว่าต้องใช้รหัสผ่านเพื่อใช้ sudo)
ยังคงเป็นสถานการณ์ที่เลวร้าย แต่อาจเป็นสถานการณ์ที่ดีกว่า (ยังดีกว่าถ้าคุณใช้ ข้อความรหัสผ่าน สำหรับคีย์ SSH ของคุณ)
ผู้ใช้รายอื่นได้กล่าวถึงจุดที่ดีมากแล้ว ฉันต้องการสรุปสิ่งที่ฉันคิดว่าสำคัญที่สุด...
/etc/ssh/sshd_config หรือผ่านทาง ซูโดเออร์ ไฟล์. (อย่าใช้โปรแกรมแก้ไขอื่นที่ไม่ใช่ visudo!)เริ่มต้น targetpw - เช่นเดียวกับเครื่องเดสก์ท็อปของฉันและบนเซิร์ฟเวอร์ของฉัน ดังนั้นเราต้องรู้รหัสผ่านที่แตกต่างกันสองรหัสจึงจะกลายเป็นรูทได้)เพื่อเพิ่มในประเด็นสุดท้าย: ฉันใช้ผู้ใช้แยกต่างหากสำหรับทุกงานบนเซิร์ฟเวอร์ของฉัน (ฉันเป็นผู้ดูแลระบบคนเดียว): เช่น ผู้ใช้หนึ่งรายสำหรับการสำรองข้อมูล มีการเข้าถึงไฟล์เพื่อสำรองและแยกการเข้าถึง ssh ไปยังเซิร์ฟเวอร์นอกสถานที่ ฉันมีผู้ใช้หนึ่งรายสำหรับการมอนิเตอร์ ซึ่งมีสิทธิ์เข้าถึงล็อกไฟล์และ API การมอนิเตอร์ที่จำกัดมาก เพียงกล่าวถึงบางตัวอย่าง...
แต่โดยส่วนตัวแล้ว สำหรับผมแล้ว ประเด็นสำคัญที่สุดก็คือ เราทุกคนต่างก็เป็นมนุษย์ คุณจะทำผิดพลาด ต้องพิมพ์ ซูโด ก่อนคำสั่งทุกคำสั่ง ที่อาจเปลี่ยนแปลงพฤติกรรมของระบบของคุณ อย่างน้อยเพิ่มสิ่งกีดขวาง 1 อัน ซึ่งกระตุ้นให้คุณคิดมากเกินไปเกี่ยวกับคำสั่งของคุณ
ดังนั้นฉันขอแนะนำ: ใช้ sudo แทนผู้ใช้รูท
จากมุมมองทางเทคนิค: มีสองวิธีทั่วไปในการใช้ผู้ใช้รูท เข้าสู่ระบบโดยตรงผ่าน ssh ในฐานะ root หรือเข้าสู่ระบบผ่าน ssh และพิมพ์ ซูโด ซู หรือ ซู - (...) เป็นคำสั่งแรก ทั้งสองวิธีนี้จะไม่ทำให้ฉันรู้สึกสบายใจ
ล็อกอินเกรซไทม์ และ MaxAuthTries เพื่อจำกัดการโจมตีแบบ BruteForceสิทธิ์รูทเข้าสู่ระบบ)ซูโด ก่อนทุกคำสั่ง ซึ่งทำให้คุณเกิดข้อผิดพลาดได้ง่าย
สำหรับการใช้งานทั้งหมด ผมขอแนะนำให้คุณ ไม่ใช้ ราก; แม้จะปิดการใช้งานถ้าเป็นไปได้ ฉันปิดการใช้งานรูทบนเซิร์ฟเวอร์ Linux/UNIX เป็นประจำ ไม่สามารถป้องกันผู้ใช้รูทได้ การดำเนินการจะไม่ถูกบันทึก อย่างน้อยที่สุด คำสั่ง sudo จะถูกบันทึก ซึ่งมีประโยชน์มากในกรณีที่ผู้ดูแลระบบจัดการผิดพลาด คุณยังสามารถปรับการอนุญาตแบบเกรนให้กับผู้ใช้ โดยให้สิทธิ์บางอย่างเท่านั้น แน่นอนว่าเมื่อปิดใช้งานรูท จะไม่สามารถบันทึก ssh โดยใช้รูทได้
จากประสบการณ์รูทจะพลาดในกรณีที่คุณต้องการบู๊ตในผู้ใช้คนเดียวหรือบู๊ตฉุกเฉินเท่านั้น สถานการณ์ที่หายากเมื่อเซิร์ฟเวอร์ไม่สามารถบู๊ตได้อย่างถูกต้อง แต่ถ้าเป็นกรณีนี้ คุณสามารถเปิดใช้งาน เปลี่ยนรหัสผ่าน และดำเนินการกู้คืนได้
อีกกรณีหนึ่งคือการคัดลอกไฟล์โดยใช้ sftp (หรือ ftp ซึ่งแน่นอนว่าควรหลีกเลี่ยง เว้นแต่ในเครือข่ายภายในเท่านั้น) ซึ่งคุณต้องคัดลอกโดยตรงไปยัง/จากไดเร็กทอรีที่มีสิทธิ์รูทเท่านั้น ในสถานการณ์นี้ คุณสามารถใช้ ACL เพื่อให้สิทธิ์แก่ผู้ใช้รายอื่นและดำเนินการต่อได้
บนเซิร์ฟเวอร์ คุณมักจะเข้าสู่ระบบเพื่อรักษาเซิร์ฟเวอร์ และ 99% ของเวลากิจกรรมทั้งหมดของคุณต้องการการอนุญาตรูท
ฉันอยากจะประกวดสิ่งนี้ มีงานประจำหลายอย่างที่เพียงแค่ค้นหาข้อมูลที่ผู้ใช้สามารถเห็นได้ "top", "ps", "df" ดูบันทึก ฯลฯ
ทำความคุ้นเคยกับการเรียกใช้เฉพาะคำสั่งที่ต้องการรูทเป็นรูท และตรวจสอบคำสั่งเหล่านั้นสามครั้งเพื่อให้คุณไม่ได้สะกดผิด
หากคุณเรียกใช้ทุกอย่างในฐานะรูท คุณจะเลอะเทอะ มันเกิดขึ้นกับทุกคน
เมื่อเลอะเทอะ คุณจะทำผิดพลาด มันเกิดขึ้นกับทุกคน
อย่าติดนิสัยนั้น
(ฉันยังเห็นด้วยกับสิ่งที่คนอื่นๆ พูดเกี่ยวกับการเป็นผู้ดูแลระบบคนเดียวในวันนี้ไม่ได้หมายความว่าคุณจะเป็นผู้ดูแลระบบคนเดียวในวันพรุ่งนี้)
ที่ปรึกษาด้านความปลอดภัย ที่นี่
แนวปฏิบัติที่ดีที่สุด ทั้งหมด แอปพลิเคชัน ระบบ โซลูชัน ระบบปฏิบัติการ และสิ่งอื่นๆ ที่คุณนึกออกคือใช้เฉพาะบัญชีรูทสำหรับตั้งค่าต่างๆ แล้วปิดการใช้งาน
โดยทั้งหมดสร้างบัญชีผู้ใช้แต่ละคนด้วยสิทธิ์ของผู้ดูแลระบบสำหรับการจัดการแบบวันต่อวัน แต่ควรปิดใช้งานบัญชีรูทไม่ว่าจะเป็นอะไรก็ตามเมื่อการตั้งค่าเสร็จสมบูรณ์
การทำให้บัญชีสับสนไม่ใช่ความคิดที่ดี เช่น อย่าตั้งชื่อบัญชีผู้ดูแลระบบของคุณเป็นผู้ดูแลระบบ แต่คุณค่าในโลกแห่งความเป็นจริงนั้นต่ำอย่างไม่น่าเชื่อ"การแฮ็ก" ส่วนใหญ่เกิดขึ้นในช่วงหลายสัปดาห์และหลายเดือนแทนที่จะเป็นวินาทีและนาทีเหมือนที่สื่อ/ภาพยนตร์/รายการทีวีต้องการนำเสนอ และใครก็ตามที่มีทักษะในการ "แฮ็ก" คุณจะมีทักษะในการตรวจสอบสิ่งต่างๆ เช่น SID ของผู้ดูแลระบบ windows (เป็น S-1-5-32-544 เสมอสำหรับผู้ดูแลระบบ windows ในตัว)
สำหรับบริษัทส่วนใหญ่ ข้อกังวลด้านความปลอดภัยที่สำคัญก็คือคุณต้องมีแนวทางการตรวจสอบและความรับผิดชอบส่วนบุคคล
บัญชีเริ่มต้น (ผู้ดูแลระบบ) เช่น ราก บัญชีตามคำนิยามแล้ว ไม่ใช่ส่วนบุคคล การปล่อยให้เปิดไว้นำไปสู่ (เทียบเท่ากับ) แนวทางปฏิบัติด้านความปลอดภัยที่ไม่ถูกต้องของรหัสผ่านที่ใช้ร่วมกันและไม่มีความรับผิดชอบส่วนบุคคล/รายบุคคล
โดยปกติเมื่อเพื่อนร่วมงานออกจากบริษัท คุณต้องปิดการใช้งานบัญชีของพวกเขาและทราบว่าจะล็อกการเข้าถึงของพวกเขา
คุณไม่ต้องการให้การออกของพวกเขาจำเป็นต้องรีเซ็ตรหัสผ่าน (และไฟล์ ~/.ssh/authorized_keys) ของทุกๆ รูทและบัญชีที่ใช้ร่วมกันอื่นๆ ซึ่งผู้ที่ออกไป (อาจ) มีสิทธิ์เข้าถึง นั่นคืองานธุรการ PITA ที่มักจะไม่เกิดขึ้น ดังนั้นคุณต้องป้องกันไม่ให้กลายเป็นปัญหาตั้งแต่แรก
ดังนั้นแม้ในแผนก IT ที่มีบุคคลคนเดียว โปรดตั้งค่าบัญชีส่วนตัวสำหรับคุณในฐานะผู้ดูแลระบบ และให้สิทธิ์ตัวคุณเอง ซูโด สิทธิ์หรือบทบาทผู้ดูแลระบบอื่น ๆ และอย่าเข้าสู่ระบบโดยตรงในฐานะรูทหรือบัญชีผู้ใช้ขั้นสูง / ผู้ดูแลระบบที่เป็นค่าเริ่มต้น
ดังนั้นเมื่อบริษัทของคุณเติบโตขึ้นและคุณกลายเป็นแผนกไอทีสองคนหรือเมื่อใดก็ตามที่คุณลาออก คุณจะไม่ปล่อยให้สิทธิพิเศษมากเกินไปที่ต้องสะสาง
ในงานใหม่ คุณไม่ต้องการใช้เวลาทำงานวันแรกของคุณในการทำความสะอาด "ทางเข้าประตูหลัง" ที่บรรพบุรุษคนก่อนทิ้งไว้ และคุณในฐานะคนลาออกก็ไม่จำเป็นต้องเสี่ยงกับการเข้าออกของคุณที่ไม่ได้อยู่เช่นกัน" ไม่ยกเลิกทำให้เกิดการละเมิดความปลอดภัย
เช่นเดียวกับคำถามเพื่อความปลอดภัยทั้งหมด เป็นคำถามที่ยอมรับความเสี่ยงได้ ดังที่คนอื่นๆ ได้กล่าวไว้ SSH เป็นผู้ใช้ที่ไม่ใช่รูทด้วยคีย์ จากนั้นยกระดับเป็นรูท หมายความว่ามีปัจจัยที่สองในการเล่น (คุณมีคีย์ คุณรู้รหัสผ่าน) ซึ่งสามารถจำกัดรัศมีการประนีประนอมได้ . มีด้านการตรวจสอบด้วยซึ่งคนอื่นพูดถึง
ถ้า คุณ พอใจกับการไม่มีการปกป้องอีกชั้นหนึ่ง (ไม่ว่าจะเล็กน้อยแค่ไหนก็ตาม) จากนั้นทำตามที่คุณต้องการ
คู่มือความปลอดภัยส่วนใหญ่แนะนำให้ปิดใช้งานรูท SSH เนื่องจากบังคับให้คุณอนุญาตรายการอนุญาตผู้ใช้เพื่อทำบางสิ่ง คุณต้องดำเนินการในเชิงบวกเพื่อให้สิทธิ์ sudo แก่ผู้ใช้ คุณสามารถควบคุมการกระทำที่ผู้ใช้สามารถทำได้เพิ่มเติม ดังนั้นคุณอาจมีผู้ใช้แยกกันสำหรับงานที่แยกจากกันด้วยซ้ำหรือผู้ใช้อัตโนมัติที่สามารถเรียกใช้คำสั่ง sudo บางคำสั่งได้ แต่ไม่สามารถเรียกใช้คำสั่งอื่นได้
ยังไงก็ตาม - เกณฑ์มาตรฐานด้านความปลอดภัยจำนวนมากแนะนำให้ไม่อนุญาต SSH และแม้แต่ไม่อนุญาตการรูทจากคอนโซลเอง ฉันจะทำสิ่งนี้ด้วยตัวเองก็ต่อเมื่อฉันมั่นใจในการสำรองข้อมูล/การสร้างใหม่/เครื่องมืออินฟราที่เปลี่ยนรูปไม่ได้ของฉัน มิฉะนั้นจะไม่มีทางกลับเข้าสู่เซิร์ฟเวอร์ได้หากไม่ได้ทำกลอุบายในการบูทแบบ live-CD
หากคุณใช้คีย์ ssh โดยปกติแล้วค่อนข้างปลอดภัยที่จะเพียงแค่ ssh ตรงไปที่รูทแทนที่จะทำให้ผู้ใช้ "พร็อกซี" สับสน
นี่เป็นคำถามเกี่ยวกับความปลอดภัยและความสะดวกสบายเท่านั้น
การเข้าสู่ระบบในฐานะรูทจะสะดวกกว่าแต่มีความปลอดภัยน้อยกว่ามาก ดังนั้นหากคุณตกลงกับคำเตือนเหล่านั้น คุณสามารถเข้าสู่ระบบในฐานะรูทได้
อย่างไรก็ตาม ยิ่งบริษัทของคุณมีขนาดใหญ่เท่าใด พวกเขาก็จะจริงจังกับความปลอดภัยมากขึ้นเท่านั้น
ตัวอย่างเช่น นายจ้างปัจจุบันของฉันคือบริษัทที่มีพนักงานมากกว่า 50,000 คนใน 5 ประเทศ การเข้าสู่ระบบ ROOT เป็นไปไม่ได้อย่างแน่นอน และการเข้าถึง SUDO ยังใช้เวลาประมาณ 2 สัปดาห์ โดยออกจากระบบจากระดับผู้อำนวยการ
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
