จะทำให้เซิร์ฟเวอร์ SSH แข็งแกร่งขึ้นได้อย่างไร


128

ฉันสามารถใช้มาตรการใดได้บ้างเพื่อให้แน่ใจว่าการรักษาความปลอดภัยรอบ ๆ เซิร์ฟเวอร์ SSH ของฉันนั้นผ่านไม่ได้อย่างสมบูรณ์

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


44
การซึมผ่านที่ไม่สมบูรณ์นั้นต้องปิดกล่อง
Thorbjørn Ravn Andersen

ถ้าคุณใช้ Wake-on-LAN
rebus

ปัญหาน่าจะเป็นส่วน LAN ... แพ็คเกจของ Wake-on-LAN ไม่ได้ถูกกำหนดเส้นทางดังนั้นคุณจะต้องเข้าถึงเครื่องภายใน LAN เพื่อส่งแพ็คเกจ WOL ...
LassePoulsen

สำหรับการรับรองความถูกต้องของคีย์คุณอาจ จำกัด Ciphers ไว้ที่ ciphers ที่คุณต้องการจริงๆ

คำตอบ:


108

ใช้คู่คีย์สาธารณะ / ส่วนตัวสำหรับการตรวจสอบสิทธิ์แทนรหัสผ่าน

  1. สร้างคีย์ SSH ที่มีการป้องกันวลีรหัสผ่านสำหรับคอมพิวเตอร์ทุกเครื่องที่ต้องการเข้าถึงเซิร์ฟเวอร์:

    ssh-keygen

  2. อนุญาตให้ใช้รหัสสาธารณะ SSH จากคอมพิวเตอร์ที่อนุญาต:

    คัดลอกเนื้อหาของ~/.ssh/id_rsa.pubคอมพิวเตอร์แต่ละเครื่องลงในแต่ละบรรทัดของ~/.ssh/authorized_keysเซิร์ฟเวอร์หรือทำงานssh-copy-id [server IP address]บนคอมพิวเตอร์ทุกเครื่องที่คุณอนุญาตให้เข้าถึง (คุณจะต้องป้อนรหัสผ่านเซิร์ฟเวอร์ที่พรอมต์)

  3. ปิดใช้งานการเข้าถึงรหัสผ่าน SSH:

    เปิด/etc/ssh/sshd_configพบบรรทัดที่ระบุว่า#PasswordAuthentication yes, PasswordAuthentication noและเปลี่ยนเป็น รีสตาร์ทเซิร์ฟเวอร์ SSH daemon เพื่อใช้การเปลี่ยนแปลง ( sudo service ssh restart)

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


5
-1: โดยทั่วไปการเข้าถึงนั้นมอบให้แก่บุคคลที่ไม่ใช่คอมพิวเตอร์การสร้างคีย์สำหรับคอมพิวเตอร์ไคลเอนต์ที่มีศักยภาพแต่ละเครื่องที่เชื่อมต่อกับเซิร์ฟเวอร์นั้นไม่มีเหตุผล คำสั่งสุดท้ายของคุณไม่ถูกต้องตามความต้องการของคุณและเนื่องจากคุณไม่แนะนำให้ตั้งข้อความรหัสผ่านสำหรับคีย์ส่วนตัวที่มีการเข้าถึง / การประนีประนอมของระบบไคลเอนต์ใด ๆ จะให้สิทธิ์การเข้าถึงเซิร์ฟเวอร์ SSH โดยอัตโนมัติ ขอแนะนำให้ใช้การรับรองความถูกต้องของคีย์ SSH แต่ต้องมีการปกป้องคีย์ส่วนตัวอย่างถูกต้องและควรใช้เป็นรายบุคคลไม่ใช่แบบกระจายดังที่อธิบายไว้
João Pinto

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

5
"เป็นไปไม่ได้" อาจจะทำมากไปหน่อย
Thorbjørn Ravn Andersen

9
นี่คือเหตุผลที่ฉันพูดว่า "เป็นไปไม่ได้" ไม่มีใครมีคอมพิวเตอร์เร็วขนาดนี้ขนาดเล็กนี้มากหรือเวลามาก ลองจินตนาการถึงคอมพิวเตอร์ที่มีขนาดเท่าเม็ดทรายที่สามารถทดสอบกุญแจกับข้อมูลที่เข้ารหัสบางอย่างและลองจินตนาการว่ามันสามารถทดสอบกุญแจได้ในระยะเวลาที่ต้องใช้แสงในการข้ามมันจากนั้นให้พิจารณากลุ่มคอมพิวเตอร์เหล่านี้ ถ้าคุณปกคลุมโลกด้วยพวกมันจะครอบคลุมทั่วทั้งดาวเคราะห์ด้วยความสูง 1 เมตรกลุ่มคอมพิวเตอร์จะถอดรหัสคีย์ 128- บิตโดยเฉลี่ยใน 1,000 ปี "
Asa Ayers

@ ThorbjørnRavnAndersen "Impossible" ไม่ได้ใช้งานเกินจริงจริง ๆ ตราบใดที่คุณใช้คีย์ที่แข็งแกร่ง ฉันไม่สามารถหาคำพูดได้ในขณะนี้ แต่ด้วยความยาวของคีย์ปัจจุบันการโจมตีด้วยกำลังดุร้ายนั้นเป็นไปไม่ได้ "จนกว่าคอมพิวเตอร์จะประกอบด้วยสิ่งอื่นนอกเหนือจากสสารและครอบครองสิ่งอื่นที่ไม่ใช่พื้นที่"
Maximillian Laumeister

72

ฉันจะแนะนำ:

  • การใช้fail2banเพื่อป้องกันการพยายามล็อกอินที่ดุร้าย

  • ปิดการใช้งานการเข้าสู่ระบบในฐานะรูทผ่าน SSH ซึ่งหมายความว่าผู้โจมตีต้องเข้าใจทั้งชื่อผู้ใช้และรหัสผ่านทำให้การโจมตียากขึ้น

    เพิ่มที่คุณPermitRootLogin no/etc/ssh/sshd_config

  • การ จำกัด ผู้ใช้ที่สามารถ SSH ไปยังเซิร์ฟเวอร์ ไม่ว่าจะเป็นกลุ่มหรือเฉพาะผู้ใช้

    เพิ่มAllowGroups group1 group2หรือAllowUsers user1 user2จำกัด ผู้ที่สามารถ SSH ไปยังเซิร์ฟเวอร์


2
AllowUsersและAllowGroupsไม่ยอมรับเครื่องหมายจุลภาค,เป็นตัวคั่น ตรวจสอบให้แน่ใจว่าคุณไม่ลองสิ่งนี้จากระยะไกล ฉันถูกล็อคจาก NAS ของฉันโดยทำสิ่งนี้อย่างไม่ถูกต้อง
เสียงอึกทึก

4
ตรวจสอบความถูกต้องของการตั้งค่าของคุณให้sshdถูกต้องก่อนที่คุณจะรีสตาร์ท sshd เพื่อหลีกเลี่ยงการล็อคตัวเองออกจากเครื่อง ดูบล็อกนี้สำหรับรายละเอียด - เพียงแค่ใช้หลังจากการเปลี่ยนแปลงการตั้งค่าก่อนที่จะเริ่มต้นใหม่หลักsshd -T sshdนอกจากนี้ให้เปิดเซสชัน SSHบนเครื่องเมื่อคุณทำการเปลี่ยนแปลงการกำหนดค่าและอย่าปิดสิ่งนี้จนกว่าคุณจะตรวจสอบการกำหนดค่าตามที่กล่าวไว้และอาจทำการล็อกอิน SSH แล้ว
RichVel

24

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

ย้ายเซิร์ฟเวอร์จากพอร์ต 22 ไปยังเซิร์ฟเวอร์อื่น ทั้งที่เกตเวย์ของคุณหรือบนเซิร์ฟเวอร์

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


1
สำหรับผู้ที่เชื่อในความปลอดภัยโดยความสับสน ( en.wikipedia.org/wiki/Security_through_obscurity ) ทำให้รู้สึกถึงการใช้พอร์ตอื่น ฉันไม่ได้ ..
LassePoulsen

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

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

Shodan ไม่ได้คว้าพอร์ต 65k ทั้งหมดดังนั้นการเปลี่ยนเป็นพอร์ตสูงอาจจะลบออกจากการสแกนของพวกเขา นอกจากนี้หากคุณย้ายไปที่พอร์ตสูงแบบสุ่มผู้โจมตีจะต้องทำการสแกน 65K TCP (มีเสียงดังมาก) เพื่อค้นหาบริการของคุณเพื่อเริ่มโจมตี ทั้งสองอย่างนี้ชนะจากมุมมองด้านความปลอดภัยดังนั้นการย้ายไปที่พอร์ตสูงมักเป็นแผนการที่ดี อีกอย่างหนึ่งคือการย้ายไปยังพอร์ตที่สูงคุณสามารถมีความคิดที่ดีกว่าว่าใครบางคนที่โจมตีคุณกำลังกำหนดเป้าหมายระบบของคุณโดยเฉพาะเมื่อเทียบกับเสียงพื้นหลังทั่วไปทั่วไปเท่านั้น
Rоry McCune

23

เปิดใช้งานการตรวจสอบปัจจัยที่สองกับHOTPหรือTOTP สามารถใช้ได้ตั้งแต่ 13.10 เป็นต้นไป

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

สรุป:

  1. sudo apt-get install libpam-google-authenticator

  2. ให้ผู้ใช้แต่ละคนเรียกใช้google-authenticatorคำสั่งซึ่งสร้าง~/.google-authenticatorและช่วยให้พวกเขากำหนดค่าอุปกรณ์ตัวประกอบสองตัว (เช่นแอป Google Authenticator Android)

  3. แก้ไข/etc/ssh/sshd_configและตั้งค่า:

    ChallengeResponseAuthentication yes
    PasswordAuthentication no
    AuthenticationMethods publickey,keyboard-interactive
    
  4. เรียกใช้ที่จะรับการเปลี่ยนแปลงของคุณsudo service ssh reload/etc/ssh/sshd_config

  5. แก้ไข/etc/pam.d/sshdและแทนที่บรรทัด:

    @include common-auth
    

    ด้วย:

    auth required pam_google_authenticator.so
    

รายละเอียดเพิ่มเติมเกี่ยวกับการตั้งค่าตัวเลือกที่แตกต่างกันโพสต์บล็อกของฉันจากปีที่ผ่านมาการตรวจสอบ SSH สองปัจจัยที่ดีขึ้นบน Ubuntu


21

ทำให้ sshd block IP ของลูกค้าที่ล้มเหลวในการจัดหาข้อมูลการเข้าสู่ระบบที่ถูกต้อง " DenyHØsts " สามารถทำงานนี้ได้อย่างมีประสิทธิภาพ ฉันมีสิ่งนี้ติดตั้งอยู่ในกล่อง Linux ทั้งหมดของฉันซึ่งเข้าถึงได้จากด้านนอกอย่างยิ่ง

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


2
มีตัวเลือกเช่น 10 ครั้งล้มเหลวในการเข้าสู่ระบบก่อนที่จะห้ามที่อยู่ IP หรือไม่?
sayantankhan

20

นี่คือสิ่งหนึ่งที่ต้องทำ: ติดตั้งufw ("ไฟร์วอลล์ที่ไม่ซับซ้อน") และใช้อัตราการ จำกัด การเชื่อมต่อขาเข้า

จากพรอมต์คำสั่งพิมพ์:

$ sudo ufw limit OpenSSH 

หากไม่ได้ติดตั้งufwให้ทำเช่นนี้แล้วลองอีกครั้ง:

$ sudo aptitude install ufw 

ผู้โจมตีหลายคนจะพยายามใช้เซิร์ฟเวอร์ SSH ของคุณเพื่อบังคับใช้รหัสผ่านที่ดุร้าย ซึ่งจะอนุญาตให้มีการเชื่อมต่อ 6 ครั้งทุก ๆ 30 วินาทีจากที่อยู่ IP เดียวกัน


+1 สามารถใช้ขีด จำกัด ได้ดี อย่างไรก็ตามควรชี้ให้เห็นฉันพบปัญหาเมื่อใช้เซิร์ฟเวอร์ในตัว sftp เพราะมัน จำกัด การเชื่อมต่อสำหรับเรื่องนี้เช่นกัน
Mark Davidson

2
@ Mark - เป็นจุดที่ดี แต่นั่นฟังดูเหมือนลูกค้า SFTP ที่เขียนไม่ดีใช่มั้ย เหตุใดพวกเขาจะทำการเชื่อมต่อกับพอร์ต SSH อีกครั้งเมื่อพวกเขาสามารถเปิดช่อง SSH เพิ่มเติมได้
mpontillo

12

ถ้าผมต้องการให้มีการรักษาความปลอดภัยเพิ่มเติมบางส่วนหรือจำเป็นต้องเข้าถึงเซิร์ฟเวอร์ SSH ลึก ๆ ข้างในบางส่วนติดตั้งเครือข่ายฉันองค์กรบริการที่ซ่อนอยู่โดยใช้ซอฟต์แวร์ anonymisation Tor

  1. ติดตั้ง Tor และตั้งค่าเซิร์ฟเวอร์ SSH เอง
  2. ตรวจสอบให้แน่ใจ sshd localhostเท่านั้นที่ฟัง
  3. /etc/tor/torrcเปิด ตั้งค่าและHiddenServiceDir /var/lib/tor/sshHiddenServicePort 22 127.0.0.1:22
  4. var/lib/tor/ssh/hostnameดู d6frsudqtx123vxf.onionมีชื่อเหมือน นี่คือที่อยู่ของบริการที่ซ่อนอยู่
  5. เปิด$HOME/.ssh/configและเพิ่มบางบรรทัด:

    Host myhost
    HostName d6frsudqtx123vxf.onion
    ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
    

นอกจากนี้ฉันต้องการทอร์กับโฮสต์ในพื้นที่ของฉัน หากมีการติดตั้งฉันสามารถป้อนssh myhostและ SSH เปิดการเชื่อมต่อผ่าน Tor เซิร์ฟเวอร์ SSH ในอีกด้านหนึ่งเปิดพอร์ตเฉพาะบนโลคัลโฮสต์ ดังนั้นไม่มีใครสามารถเชื่อมต่อผ่าน "อินเทอร์เน็ตปกติ"


10
ความปลอดภัยจากความสับสนขั้นสูง แต่น่าสนใจมาก
โยฮันเนส

8

มีบทความ Debian Administration ในหัวข้อนี้ ครอบคลุมการกำหนดค่าเซิร์ฟเวอร์ SSH พื้นฐานและกฎไฟร์วอลล์ สิ่งนี้อาจเป็นที่สนใจเช่นกันที่ทำให้เซิร์ฟเวอร์ SSH แข็งตัวขึ้น

ดูบทความที่นั่นรักษา SSH สามารถเข้าถึงการรักษาความปลอดภัย


3
ช้าหน่อย แต่เมื่อตอบคำถามให้คัดลอกส่วนที่สำคัญจากลิงค์เพื่อที่ว่าหากลิงค์ยังคงอยู่ข้อมูลก็ยังอยู่ที่นี่
umop aplsdn

1
ความคิดที่ดี. แม้ว่าฉันจะผ่านช่วงเวลาที่มีเวลาน้อยกว่าที่จะเข้าร่วม คำตอบของฉันคือ "community wiki" ดังนั้นอย่าลังเลที่จะเพิ่มข้อมูลลิงก์หากคุณมีเวลา
Huygens

6

วิธีการของฉันในการชุบแข็ง SSH คือ ... ซับซ้อน รายการต่อไปนี้เป็นวิธีการที่ฉันทำจากขอบสุดของเครือข่ายของฉันไปยังเซิร์ฟเวอร์ด้วยตนเอง

  1. การกรองการรับส่งข้อมูลระดับชายแดนผ่าน IDS / IPS พร้อมบริการสแกนเนอร์และลายเซ็นที่รู้จักในบล็อกลิสต์ ฉันทำสิ่งนี้ได้ด้วย Snort ผ่านไฟร์วอลล์ชายแดน (นี่คือวิธีการของฉันซึ่งเป็นอุปกรณ์ pfSense) บางครั้งฉันทำสิ่งนี้ไม่ได้เช่นกับ VPS ของฉัน

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

  3. ร่วมกับ pfSense ของฉันหรือไฟร์วอลล์ชายแดน NAT-ing เครือข่ายภายในและแยกออกจากอินเทอร์เน็ตและระบบการเข้าถึง VPN ไปยังเซิร์ฟเวอร์เท่านั้น ต้อง VPN เข้าสู่เครือข่ายของฉันเพื่อไปยังเซิร์ฟเวอร์เพราะไม่มีพอร์ตที่เชื่อมต่ออินเทอร์เน็ตเช่นนี้ สิ่งนี้ไม่ได้ผลสำหรับ VPS ของฉันทั้งหมด แต่เมื่อใช้ร่วมกับ # 2 ฉันสามารถมี VPS หนึ่งอันให้เป็น 'เกตเวย์' โดย VPNing ในเซิร์ฟเวอร์นั้นและจากนั้นอนุญาต IP ของกล่องอื่น ๆ ด้วยวิธีนี้ฉันรู้แน่ชัดว่า SSH สามารถหรือไม่ - กล่องเดียวของฉันคือ VPN (หรือในเครือข่ายภายในบ้านของฉันที่อยู่เบื้องหลัง pfSense การเชื่อมต่อ VPN ของฉันและฉันเป็นผู้เดียวที่เข้าถึง VPN ได้)

  4. ในกรณีที่ # 3 ไม่สามารถทำได้fail2ban กำหนดค่าให้บล็อกหลังจากพยายาม 4 ครั้งที่ล้มเหลวและปิดกั้น IP เป็นเวลาหนึ่งชั่วโมงหรือมากกว่านั้นเป็นการป้องกันที่ดีต่อผู้คนที่โจมตีด้วย bruteforcing ตลอดเวลา - เพียงแค่บล็อก em ที่ไฟร์วอลล์โดยอัตโนมัติด้วย fail2ban และ meh การกำหนดค่า fail2ban เป็นความเจ็บปวดแม้ว่า ...

  5. พอร์ตทำให้งงงวยโดยการเปลี่ยนพอร์ต SSH อย่างไรก็ตามนี่ไม่ใช่ความคิดที่ดีที่จะทำโดยไม่มีมาตรการรักษาความปลอดภัยเพิ่มเติมเช่นกัน - มนต์ของ "ความปลอดภัยผ่านความสับสน" ได้รับการข้องแวะและโต้แย้งในหลาย ๆ กรณีแล้ว ฉันได้ทำสิ่งนี้ร่วมกับ IDS / IPS และการกรองเครือข่ายแล้ว แต่ก็ยังเป็นเรื่องที่แย่มากที่ต้องทำด้วยตัวเอง

  6. บังคับตรวจสอบสองปัจจัยผ่านโซลูชั่น Two-Factor Authentication Duo การรักษาความปลอดภัยของ เซิร์ฟเวอร์ SSH ของฉันทุกตัวมีการกำหนดค่า Duo ไว้เพื่อให้ได้รับข้อความแจ้งเตือน 2FA เกิดขึ้นและฉันต้องยืนยันการเข้าถึงแต่ละครั้ง (นี่เป็นคุณสมบัติที่มีประโยชน์ที่สุด - แม้ว่าบางคนมีข้อความรหัสผ่านหรือตัวแบ่งฉันก็ไม่สามารถผ่านปลั๊กอิน Duo PAM ได้) นี่เป็นหนึ่งในการป้องกันที่ใหญ่ที่สุดในเซิร์ฟเวอร์ SSH ของฉันจากการเข้าถึงที่ไม่ได้รับอนุญาต - การเข้าสู่ระบบของผู้ใช้แต่ละคนจะต้องผูกกลับไปยังผู้ใช้ที่กำหนดค่าใน Duo และเนื่องจากฉันมีชุดที่เข้มงวด

สองเซ็นต์ของฉันเพื่อรักษาความปลอดภัย SSH หรืออย่างน้อยความคิดของฉันเกี่ยวกับวิธีการ


1

คุณอาจต้องการเช็คเอาท์แอป FreeOTP จาก RedHat แทนที่จะใช้ Google Authenticator บางครั้งเมื่ออัปเดตแอปพวกเขาล็อคคุณ! ;-)

หากคุณต้องการใช้โทเค็นฮาร์ดแวร์อื่น ๆ เช่น Yubikey หรือ eToken PASS หรือ NG หรือหากคุณมีผู้ใช้จำนวนมากหรือเซิร์ฟเวอร์จำนวนมากคุณอาจต้องการใช้แบ็กเอนด์การรับรองความถูกต้องสองระดับของ opensource

เมื่อเร็ว ๆ นี้ผมเขียนHOWTO เกี่ยวกับเรื่องนี้


0

ฉันเขียนบทช่วยสอนเล็ก ๆ เกี่ยวกับการทำสิ่งนี้เมื่อเร็ว ๆ นี้ โดยทั่วไปคุณต้องใช้ PKI และบทช่วยสอนของฉันยังแสดงวิธีใช้การรับรองความถูกต้องแบบสองปัจจัยเพื่อความปลอดภัยที่มากยิ่งขึ้น แม้ว่าคุณจะไม่ใช้สิ่งเหล่านั้น แต่ก็มีเกร็ดความรู้บางอย่างเกี่ยวกับการรักษาความปลอดภัยเซิร์ฟเวอร์โดยการลบชุดตัวเลขอ่อนและพื้นฐานอื่น ๆ https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/


0

สำหรับผู้ใช้ / ใบรับรองจำนวนมากให้พิจารณาการรวม LDAP องค์กรขนาดใหญ่ใช้ LDAP เป็นที่เก็บสำหรับข้อมูลรับรองผู้ใช้และใบรับรองที่เก็บไว้ในป้ายหรือ fobs ไม่ว่าจะเป็นใบรับรองที่ใช้สำหรับการรับรองความถูกต้องหรือการลงนามอีเมล ตัวอย่างเช่น openLDAP, openDJ, Active Directory, Oracle Universal Directory, IBM Directory Server, snareWorks ...

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

นี่คือลิงก์สำหรับการรวม CentOS: http://itdavid.blogspot.com/2013/11/howto-configure-openssh-to-fetch-public.html


0

คุณสามารถบล็อกตามประเทศต้นกำเนิดโดยใช้ฐานข้อมูล geoIP

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

สคริปต์สามารถพบได้ที่นี่: https://www.axllent.org/docs/view/ssh-geoip/

คุณยังสามารถเพิ่มคำสั่ง iptables ได้ (ฉันทำเพื่อหยดละอองของฉัน) เพื่อลดทราฟฟิกทั้งหมดไปยัง / จาก IP เหล่านั้น


1
บางครั้งฐานข้อมูล GeoIP อาจผิด - ฉันถูกถามว่าฉันอยู่ในมอสโกเมื่อวานนี้ ... ใช่แล้ว! :)
Sean
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.