ตกลงเพื่อตั้งค่ารหัสผ่าน `sudo 'บนเซิร์ฟเวอร์คลาวด์หรือไม่?


58

ฉันชอบความคิดในการเข้าถึงเซิร์ฟเวอร์ผ่านกุญแจดังนั้นฉันไม่จำเป็นต้องพิมพ์รหัสผ่านทุกครั้งที่ฉันsshใส่กล่องฉันยังล็อคrootรหัสผ่านของผู้ใช้ (ไม่ใช่) ( passwd -l username) ดังนั้นจึงไม่สามารถเข้าสู่ระบบได้โดยไม่ต้องใช้รหัส

แต่ตัวแบ่งทั้งหมดนี้ถ้าฉันต้องป้อนรหัสผ่านสำหรับsudoคำสั่ง ดังนั้นฉันอยากจะตั้งค่ารหัสผ่านsudoเพื่อทำสิ่งต่าง ๆ ให้สอดคล้องกับการเข้าสู่ระบบแบบไม่มีรหัสผ่าน

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

ชี้แจง

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

ดังนั้นด้วยคำถามนี้ฉันต้องการเข้าใจความเสี่ยงข้อแม้และข้อตกลงการแลกเปลี่ยนที่เป็นไปได้ของการกำหนดค่าที่เป็นไปได้มากกว่าข้ออื่น

ติดตาม 1

คำตอบทั้งหมดบอกว่ารหัสผ่านsudoไม่มีความปลอดภัยเนื่องจากจะช่วยให้เพิ่มสิทธิ์ "ง่าย" หากบัญชีผู้ใช้ส่วนบุคคลของฉันถูกบุกรุก ฉันเข้าใจ. แต่ในทางกลับกันถ้าฉันใช้รหัสผ่านเรามีความเสี่ยงแบบคลาสสิกทั้งหมดกับรหัสผ่าน (สั้นเกินไปหรือสตริงทั่วไปซ้ำในบริการต่าง ๆ ฯลฯ ) แต่ฉันเดาว่าถ้าฉันปิดใช้งานการพิสูจน์ตัวตนด้วยรหัสผ่าน/etc/ssh/sshd_configเพื่อให้คุณยังต้องมีกุญแจในการเข้าสู่ระบบฉันสามารถใช้รหัสผ่านsudoที่ง่ายกว่าเพื่อให้พิมพ์ได้ง่ายขึ้นใช่ไหม นั่นเป็นกลยุทธ์ที่ถูกต้องหรือไม่?

ติดตาม 2

หากฉันมีรหัสเพื่อเข้าสู่ระบบrootผ่านทาง ssh หากใครบางคนสามารถเข้าถึงคอมพิวเตอร์ของฉันและขโมยกุญแจของฉันได้ (พวกเขายังคงได้รับการป้องกันด้วยรหัสผ่านของระบบปฏิบัติการ!) พวกเขาอาจเข้าถึงrootบัญชีได้โดยตรงข้ามsudoเส้นทาง นโยบายการเข้าถึงrootบัญชีควรเป็นอย่างไร


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

โปรดดูคำถามที่ตามมาของฉัน
Dmitry Pashkevich

1
sudo ไม่ควรไม่มีรหัสผ่าน รูทควรถูกปิดการใช้งานจากการเข้าสู่ระบบจากระยะไกลผ่าน SSH พอร์ต ssh ไม่ควรเป็นค่าเริ่มต้น (เพื่อทิ้งดัมบอท) และบัญชีใด ๆ ที่จำเป็นต้องใช้ sudo ควรถูก จำกัด ให้อยู่ในอำนาจ sudo ขั้นต่ำเพียงอย่างเดียว เท่านั้นและอื่น ๆ ) และยังมีรหัสผ่านที่แข็งแกร่งมาก
SnakeDoc

@SnakeDoc ขอบคุณนั่นเป็นคำตอบที่ฉันคาดหวัง สนใจที่จะเขียนคำตอบอย่างละเอียด? ฉันดีใจที่ได้เรียนรู้!
Dmitry Pashkevich

2
@EEAA จริงๆแล้วมันค่อนข้างง่ายใน linux บัญชีเดียวที่ควรได้รับอนุญาตให้ไม่มีรหัสผ่านใน sudo จะเป็นบัญชีระบบที่ไม่สามารถเข้าสู่ระบบดังนั้นจึงไม่สามารถยกระดับบัญชีดังกล่าวและใช้สิทธิ์เหล่านั้นกับคุณ ตั้งค่าเปลือกปลอมสำหรับบัญชีใน/etc/passwdเช่น nologin ตั้งรหัสผ่านไม่ได้แล้วตั้งรหัสผ่านใน visudo หากคุณทำเช่นนี้คุณควรตรวจสอบให้แน่ใจว่าการตั้งค่า visudo นั้นใช้สำหรับสิ่งที่บัญชีระบบต้องการอย่างแท้จริงเท่านั้นเช่นล็อคไว้กับคำสั่งเดียวที่ควรรัน
SnakeDoc

คำตอบ:


48

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

คุณกำลังจะปิดใช้งานการเข้าสู่ระบบด้วยรหัสผ่านในทางที่ผิด แทนการล็อกบัญชีผู้ใช้ตั้งในของคุณPasswordAuthentication no/etc/ssh/sshd_config

ด้วยชุดนั้นการตรวจสอบรหัสผ่านถูกปิดใช้งานสำหรับ ssh แต่คุณยังสามารถใช้รหัสผ่านสำหรับ sudo ได้

เพียงครั้งที่ผมแนะนำให้ตั้งค่าNOPASSWDใน sudo สำหรับบัญชีบริการที่กระบวนการจะต้องสามารถที่จะเรียกใช้คำสั่งผ่านทาง sudo โปรแกรม ในสถานการณ์เหล่านั้นตรวจสอบให้แน่ใจว่าคุณอนุญาตอย่างชัดเจนเฉพาะคำสั่งเฉพาะที่บัญชีต้องการใช้งาน สำหรับบัญชีแบบโต้ตอบคุณควรเสมอปล่อยให้เปิดใช้งานรหัสผ่าน

คำตอบสำหรับคำถามที่ตามมาของคุณ:

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

ใช่ที่ถูกต้อง. ฉันยังคงแนะนำให้ใช้รหัสผ่านบัญชีท้องถิ่นที่ค่อนข้างแข็งแกร่ง แต่ไม่แข็งแกร่งอย่างน่าขัน ~ 8 ตัวอักษรสร้างแบบสุ่มก็เพียงพอแล้ว

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

ควรปิดใช้งานการเข้าถึงรูทผ่าน ssh ระยะเวลา ตั้งในของคุณPermitRootLogin nosshd_config

นโยบายการเข้าถึงบัญชีรูทควรเป็นอย่างไร?

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


2
1 ควรปล่อยให้รหัสผ่าน ...
คริสเอส

6
1 รหัสผ่าน sudo ไม่ได้จริงๆมีสำหรับ secutiry (เท่าที่ผมสามารถมองเห็น) แต่มากขึ้นเช่นการตรวจสอบคนงี่เง่า ไม่ได้มีอาจก่อให้เกิด havok บอกเล่า
Boris the Spider

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

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

1
@DmitryPashkevich - เกี่ยวกับการPasswordAuthenticationส่งผลกระทบต่อผู้ใช้ทั้งหมดคุณสามารถใช้Matchส่วนต่างๆใน sshd_config เพื่อเปิดใช้งานอีกครั้งสำหรับผู้ใช้หรือกลุ่มบางกลุ่ม
Matt Thomason

11

โดยทั่วไปฉัน จำกัด การใช้NOPASSWORDคำสั่งเป็นซึ่งดำเนินการโดยกระบวนการอัตโนมัติ มันจะดีกว่าที่จะมีบัญชีบริการสำหรับคำสั่งเหล่านี้และ จำกัด การใช้ sudo กับคำสั่งที่จำเป็น

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

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


8

ฉันจะใช้สิ่งนี้ในสองสถานการณ์เท่านั้น:

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

โดยค่าเริ่มต้นsudoการกำหนดค่าส่วนใหญ่จะไม่ขอให้คุณอีกครั้งในช่วงเวลาเดียวกัน (ถ้าคุณเปิดเปลือกใหม่ที่ไม่มีผลใด ๆ ) คุณสามารถควบคุมพฤติกรรมนี้ได้ด้วยการtimestamp_timeoutตั้งค่า

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

เกี่ยวกับการติดตาม 2:

หากฉันยังมีกุญแจในการเข้าสู่ระบบในฐานะรูทผ่าน ssh

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


ขอขอบคุณที่แจ้งให้ฉันติดตาม # 2 ฉันยังสับสนอยู่: ฉันพยายามหลีกเลี่ยงการเข้าสู่ระบบrootโดยตรง แต่ฉันต้องการวิธีการเข้าถึงบัญชีบางอย่างใช่ไหม? แล้วฉันจะทำยังไงดีล่ะ? ด้วยรหัสผ่านไม่ใช่รหัส ssh หรือ แต่รหัสไม่ดีไปกว่ารหัสผ่านใช่ไหม
Dmitry Pashkevich

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

7

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

ฉันใช้สิ่งนี้ในการผลิตมานานกว่าห้าปีแล้ว

ในการกำหนดค่าให้ติดตั้งโมดูล PAM แล้วเพิ่มบรรทัด/etc/pam.d/sudoหรือเทียบเท่ากับระบบของคุณ:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys

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

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

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo

ว้าวฟังดูดีมาก! ดังนั้นฉันจะสร้างคีย์แยกต่างหากสำหรับการดำเนินการsudoคำสั่งหรือฉันใช้คีย์เดียวกับที่ใช้สำหรับการรับรองความถูกต้อง SSH
Dmitry Pashkevich

1
มันอัศจรรย์มาก. ฉันจะโหวตให้คุณหลายครั้งถ้าทำได้
nyuszika7h

คุณสามารถใช้รหัสเดียวกับที่คุณใช้สำหรับการรับรองความถูกต้องของ SSH ปกติหรือเพื่อความปลอดภัยที่เพิ่มขึ้นคุณสามารถเพิ่มรหัสที่คุณใช้สำหรับ sudo-ing ไปยังตัวแทนการตรวจสอบความถูกต้องของ SSH ชั่วคราว เรื่องนี้จะต้องที่คุณระบุไฟล์ที่แตกต่างกว่าที่~/.ssh/authorized_keysคุณสามารถจัดการไฟล์อื่นเช่นหรือ~/.ssh/authorized_keys_sudo /etc/ssh/authorized_keys_sudo
obscurerichard

6

เมื่อคุณถามต่อไปนี้เป็นคำแนะนำทั่วไปของฉันเกี่ยวกับวิธีsudoแก้ไขปัญหา

Sudo ไม่ได้ถูกออกแบบมาเพื่อเพิ่มความปลอดภัย (แม้ว่าจะสามารถนำไปใช้ได้ในบางประเด็น) ... แต่ให้แนวทางการตรวจสอบที่ดีว่าใครทำอะไรในระบบของคุณด้วยสิทธิพิเศษใดบ้าง

การตั้งค่าอย่างถูกต้อง Sudo จะไม่ใช้การALL=(ALL) ALLตั้งค่า แต่มีบางสิ่งบางอย่าง จำกัด มากขึ้นกว่าสิ่งที่ผู้ใช้ต้องการ ตัวอย่างเช่นหากคุณต้องการให้ผู้ใช้สามารถเข้าสู่ระบบและเริ่มบริการที่ค้างอยู่พวกเขาอาจไม่ต้องการความสามารถในการติดตั้งซอฟต์แวร์ใหม่หรือปิดเซิร์ฟเวอร์เปลี่ยนกฎไฟร์วอลล์ ฯลฯ

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

ฉันจะรักษาความปลอดภัยกล่องของฉันได้อย่างไร:

เปลี่ยนพอร์ต SSH เป็นอย่างอื่นนอกเหนือจากค่าเริ่มต้น นี่คือการหลีกเลี่ยงการโง่บอทที่มองหาหมายเลขพอร์ตแล้วทุบออกไปจนกว่าพวกเขาจะได้รับ (หรือไม่)

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

อนุญาตให้ผู้ใช้งาน SSH ที่ต้องใช้เท่านั้นใช้การAllowUsersตั้งค่าและการอธิบายอย่างชัดเจนว่าบัญชีใดต้องการการเข้าถึง SSH โดยค่าเริ่มต้นนี้จะบล็อกบัญชีอื่นทั้งหมดจาก SSH

แก้ไข Sudoers ผ่าน visudo และอนุญาตเฉพาะคำสั่งที่ผู้ใช้ต้องการเท่านั้น มีคำแนะนำในเชิงลึกมากมายเกี่ยวกับวิธีการทำเช่นนี้ดังนั้นฉันจะไม่ให้รายละเอียดที่นี่ นี่คือตัวเริ่มต้น: http://ubuntuforums.org/showthread.php?t=1132821

ส่วนสำคัญของสิ่งนี้คือการป้องกันไม่ให้บัญชีที่ถูกบุกรุกทำอันตรายต่อเครื่องของคุณ กล่าวคือ หากบัญชีของ Sally ถูกบุกรุกและ Sally สามารถใช้ sudo เพื่อรีสตาร์ทเว็บเซิร์ฟเวอร์ได้ดีผู้โจมตีอาจสนุกกับการรีสตาร์ทเว็บเซิร์ฟเวอร์ของคุณเป็นวง แต่อย่างน้อยพวกเขาก็ไม่สามารถrm -rf /your/webserver/directoryเปิดพอร์ตไฟร์วอลล์ทั้งหมดของคุณได้ ฯลฯ

ตั้งค่ากฎไฟร์วอลล์ที่ดีที่อนุญาตเฉพาะพอร์ตที่จำเป็นต่อการทำงานของกล่องของคุณ โดยทั่วไปคุณต้องการทิ้งทุกอย่างและอนุญาตเฉพาะสิ่งที่คุณต้องการอย่างชัดเจน มี iptables ที่ดีมากมายและไฟร์วอลล์อื่น ๆ เริ่มออนไลน์นี่คือสิ่งที่ฉันใช้ (เป็นตัวเริ่มต้นขั้นพื้นฐาน):

# Generated by iptables-save v1.4.7 on Mon Mar  3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar  3 17:55:02 2014

รหัสผ่านที่คาดเดายากก็เป็นกุญแจสำคัญเช่นกันแม้ว่าคุณจะใช้กุญแจ SSH สำหรับการเข้าถึงระยะไกลของคุณคุณควรยังคงต้องใช้รหัสผ่านสำหรับการใช้ Sudo นี่เป็นกรณีที่ sudo สามารถให้ความปลอดภัยเพิ่มเติมได้บ้าง หากมีใครบางคนขโมยกุญแจ ssh ของพวกเขาพวกเขาจะยังคงได้รับการป้องกันไม่ให้ทำอะไรที่สำคัญในกล่องของคุณหากพวกเขายังต้องเดรัจฉานบังคับให้รหัสผ่านบัญชีของคุณใช้ sudo รหัสผ่านไม่ควรเป็นคำ แต่เป็นวลีรหัสผ่าน คิดประโยคและใช้มัน โดยทั่วไปแล้วคุณจะได้รับความยาวมากกว่า 8 ตัวอักษรซึ่งให้เอนโทรปีมากมาย แต่ยังจำได้ง่ายกว่ารหัสผ่านแบบสุ่ม แน่นอนว่าการใช้รหัสผ่านที่ดีนั้นบอกว่าใช้รหัสผ่านแบบสุ่มที่สร้างด้วยเครื่องจักรเพื่อหลอกเครื่องมือถอดรหัสเช่น John the Ripper ซึ่งจะตัดผ่านข้อความรหัสผ่านและรหัสผ่านส่วนใหญ่ ไม่การเปลี่ยน E ด้วย 3 ไม่ได้ผลจอห์นได้รับการเรียงสับเปลี่ยนเช่นกัน


ขอบคุณสำหรับคำตอบที่ครอบคลุม! ฉันต้องใช้คำแนะนำเหล่านี้ทั้งหมดเพื่อรักษาความปลอดภัยกล่องของฉัน ฉันจะยังคงยอมรับคำตอบของ EEAA แต่เนื่องจากเป็นสิ่งที่เฉพาะเจาะจงกับสิ่งที่ฉันถาม
Dmitry Pashkevich

1
@DmitryPashkevich ไม่เป็นไร EEAA มีคำตอบที่ดีและเหมาะสม คุณขอให้ฉันให้รายละเอียดความคิดเห็นของฉันด้านบนดังนั้นฉันทำ ไม่ต้องกังวล :)
SnakeDoc

สำหรับsudo su -และรูปแบบsudoreplayอาจมีประโยชน์
nyuszika7h

3

ในบางกรณีจำเป็นต้องทำเช่นนี้ เช่นการเข้าสู่ระบบ passwordless จำเป็นบาง hypervisor API และ sudopasswordless แต่คุณยังสามารถ จำกัด ได้โดยไม่ทำลาย

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

นอกจากนี้หากคุณกำลังพิมพ์คำสั่งที่มีสิทธิ์ใช้งานรูทจำนวนมากและไม่ต้องการใส่ sudo ไว้ข้างหน้าพวกเขาตลอดเวลาคุณสามารถทำได้suหรือsudo -sจะได้รูทเชลล์ คุณจะต้องป้อนรหัสผ่านของคุณเพียงครั้งเดียวเท่านั้น


2

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

การพิมพ์ภาพ 'ทำ' และสคริปต์ที่ทำในส่วน 'sudo make install' ให้คุณโดยไม่ต้องตั้งค่าหรือแสดงเส้นทางหลักและสคริปต์ก็ถูกนำมาใช้ในครั้งแรกที่คุณไม่แน่ใจว่าพวกเขารู้เกี่ยวกับ / usr / local และคุณเริ่มตรวจสอบ / usr เพื่อแก้ไข ...

ฉันสาบานว่าจะไม่ใช้ NOPASSWD อีกครั้งและเปลี่ยนการตั้งค่าการหมดเวลาเป็น 0


1

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

จากหน้า man sudoers :

timestamp_timeout

จำนวนนาทีที่สามารถผ่านไปก่อนที่ sudo จะขอรหัสผ่านอีกครั้ง การหมดเวลาอาจรวมถึงส่วนประกอบที่เป็นเศษส่วนหากจำนวนนาทีไม่เพียงพอตัวอย่างเช่น 2.5 ค่าเริ่มต้นคือ 5 ตั้งค่านี้เป็น 0 เพื่อให้ใส่รหัสผ่านทุกครั้ง หากตั้งค่าเป็นน้อยกว่า 0 การประทับเวลาของผู้ใช้จะไม่หมดอายุ สามารถใช้เพื่ออนุญาตให้ผู้ใช้สร้างหรือลบการประทับเวลาของตนเองผ่าน "sudo -v" และ "sudo -k" ตามลำดับ

โพสต์บล็อกนี้แสดงตัวอย่างบางส่วนที่ใช้visudoเพื่อตั้งค่าการหมดเวลาเป็นนาทีเช่น:

Defaults timestamp_timeout=60

บางทีนี่อาจจะเป็นความสุขระหว่างการรักษาความปลอดภัยและความง่ายในการใช้งาน?


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

1

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

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

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