เหตุใดจึงเปลี่ยนพอร์ต ssh เริ่มต้น

19

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

ssh security

3

FWIW คำถามเดียวกันแน่นอนบนเซิร์ฟเวอร์ Fault: serverfault.com/questions/189282/why-change-default-ssh-port

— Jonik

27

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

sshd[16359]: Invalid user test from 92.241.180.96
sshd[16428]: Invalid user oracle from 92.241.180.96
sshd[16496]: Invalid user backup from 92.241.180.96
sshd[16556]: Invalid user ftpuser from 92.241.180.96
sshd[16612]: Invalid user nagios from 92.241.180.96
sshd[16649]: Invalid user student from 92.241.180.96
sshd[16689]: Invalid user tomcat from 92.241.180.96
sshd[16713]: Invalid user test1 from 92.241.180.96
sshd[16742]: Invalid user test from 92.241.180.96
sshd[16746]: Invalid user cyrus from 92.241.180.96
sshd[16774]: Invalid user temp from 92.241.180.96
sshd[16790]: Invalid user postgres from 92.241.180.96
sshd[16806]: Invalid user samba from 92.241.180.96

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

— Michael Mrozek
แหล่งที่มา

15

ไม่มันเป็นความปลอดภัยโดยชั้นเชิงที่คลุมเครือ

หากการตั้งค่า sshd ของคุณไม่พอดีพอที่จะเผชิญกับสคริปต์ตัวเล็ก ๆ ที่พยายามพอร์ต 22 คุณก็มีปัญหาอยู่ดี

ปฏิกิริยาที่มีเหตุผลมากกว่านี้คือ:

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

บางคนอาจรำคาญด้วยเสียง sshd ที่เขียนลงในบันทึกของระบบเช่น:

Jan 02 21:24:24 example.org sshd[28396]: Invalid user guest from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28396]: input_userauth_request: invalid user guest [preauth]
Jan 02 21:24:24 example.org sshd[28396]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Jan 02 21:24:24 example.org sshd[28398]: Invalid user ubnt from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28398]: input_userauth_request: invalid user ubnt [preauth]
Jan 02 21:24:24 example.org sshd[28398]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth

อาจเป็นการปิดบังพอร์ต sshd หรือใช้โซลูชันการบล็อกอัตโนมัติ (เช่น DenyHosts, Fail2ban หรือ BlockHosts) เพื่อเพิ่มอัตราส่วนสัญญาณต่อสัญญาณรบกวนอีกครั้ง

แต่มีทางเลือกที่ดีกว่า ตัวอย่างเช่นคุณสามารถกำหนดค่า syslog daemon ของคุณเพื่อให้สัญญาณเสียง sshd นั้นถูกเขียนเป็น - พูด - /var/log/sshd-attempts.logและสัญญาณ (เช่นข้อความบันทึก sshd ที่เหลือ) จะถูกเขียนไป/var/log/messagesเป็นต้น

การใช้งานของเครื่องมือปิดกั้นอัตโนมัติควรพิจารณาอย่างรอบคอบเพราะการเพิ่มความซับซ้อนมากขึ้นในการรักษาความปลอดภัยระบบวิธีการที่เกี่ยวข้องยังเพิ่มความเสี่ยงของการแสวงหาผลประโยชน์ และแน่นอนปีที่ผ่านมามีหลายช่องโหว่ DoSรายงานสำหรับแต่ละDenyHosts , fail2banและBlockHosts

— maxschlepzig
แหล่งที่มา

4

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

— xenoterracide

1

@xenoterracide: หากคุณกังวลเกี่ยวกับความสามารถในการอ่านไฟล์บันทึกของคุณเท่านั้นมีทางเลือกอื่นที่ดีกว่าในการแยกสัญญาณรบกวนแทนที่จะเปลี่ยนพอร์ตเป็นกลยุทธ์ที่สับสนซึ่งเป็นคำถาม เกี่ยวกับการบล็อคไอพีซึ่งไม่ได้เป็นส่วนหนึ่งของคำถาม: โปรดทราบว่าการเพิ่มความซับซ้อนให้กับระบบรักษาความปลอดภัยนั้นหมายถึงการเพิ่มความเสี่ยงของการถูกเอารัดเอาเปรียบ พิจารณาเช่นseclists.org/fulldisclosure/2007/Jun/121 ossec.net/main/attacking-log-analysis-tools ใช่ DenyHosts ได้รับผลกระทบจากสิ่งนี้

— maxschlepzig

1

มีมากกว่าการอ่านในใจ การเปลี่ยนแปลงพอร์ตที่ทำเป็นเอกสารอย่างถูกต้องไม่ใช่ความปลอดภัยโดยความสับสน

— xenoterracide

4

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

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

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

การเปลี่ยนพอร์ตเริ่มต้นมีข้อเสียที่สำคัญ: ทำให้คุณมีโอกาสน้อยที่จะสามารถเข้าสู่ระบบจากด้านหลังไฟร์วอลล์ ไฟร์วอลล์มีแนวโน้มที่จะให้บริการผ่านทางพอร์ตเริ่มต้นของพวกเขามากกว่าในบางพอร์ตแบบสุ่ม หากคุณไม่ได้ใช้เซิร์ฟเวอร์ HTTPS ให้ลองฟัง SSH ฟังที่พอร์ต 443 เช่นกัน (หรือเปลี่ยนเส้นทางคำขอ TCP ขาเข้าจากพอร์ต 443 ไปที่พอร์ต 22) เนื่องจากไฟร์วอลล์บางตัวอนุญาตการรับส่งข้อมูลที่ไม่สามารถถอดรหัสพอร์ต 443 ได้เนื่องจากดูเหมือนว่า เช่น HTTPS

— Gilles 'หยุดความชั่วร้าย'
แหล่งที่มา