Tại sao thay đổi cổng ssh mặc định?


Câu trả lời:


27

Lý do rất có thể là làm cho mọi người khó khăn hơn khi cố gắng vũ phu bất kỳ thông tin đăng nhập SSH nào họ có thể tìm thấy. Máy phải đối mặt với internet của tôi sử dụng cổng SSH mặc định và nhật ký của tôi được sử dụng để chứa đầy những thứ như thế này (trích từ tệp nhật ký thực tế):

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

Ngày nay, tôi sử dụng Denyhost để chặn các IP không xác thực quá nhiều lần, nhưng có lẽ chỉ đơn giản là chuyển đổi cổng; Hầu như tất cả các cuộc tấn công vũ phu thuộc loại này sẽ không làm phiền việc quét để xem nếu sshd của bạn đang lắng nghe trên một cổng khác, họ sẽ cho rằng bạn không chạy một cái và tiếp tục


15

Không, đó là một bảo mật bằng chiến thuật tối nghĩa .

Nếu thiết lập sshd của bạn không đủ phù hợp để đối mặt với những đứa trẻ kịch bản ngu ngốc chỉ thử cổng 22, dù sao bạn cũng có vấn đề.

Một phản ứng hợp lý hơn sẽ là:

  • đảm bảo rằng người dùng của bạn đang sử dụng các mật khẩu tốt, khó đoán / bạo lực
  • vô hiệu hóa xác thực mật khẩu (ít nhất là đối với các tài khoản quan trọng) và chỉ sử dụng xác thực khóa công khai
  • xem ra các vấn đề an ninh và nâng cấp ssh

Một số người cũng có thể khó chịu vì tiếng ồn sshd ghi vào nhật ký hệ thống, ví dụ:

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

Sau đó, có thể che khuất cổng sshd hoặc sử dụng giải pháp chặn tự động (như Denyhost, Fail2ban hoặc Blockhost) để tăng tỷ lệ tín hiệu trên tạp âm một lần nữa.

Nhưng sự thay thế tốt hơn tồn tại. Ví dụ: bạn có thể định cấu hình trình nền syslog của mình sao cho nhiễu nhật ký sshd chỉ được ghi thành - nói - /var/log/sshd-attempts.logvà tín hiệu (tức là các thông điệp nhật ký sshd còn lại) được ghi vào /var/log/messagesvv như trước đây.

Việc triển khai các công cụ ngăn chặn tự động cần được xem xét một cách cẩn thận vì bổ sung thêm tính phức tạp về an ninh hệ thống phương tiện có liên quan cũng tăng nguy cơ của việc khai thác . Và trên thực tế, trong những năm qua, có một số lỗ hổng DoS báo cáo cho mỗi denyhosts , Fail2banBlockHosts .


4
Tôi thực sự không đồng ý với điều đó "đó là bảo mật bởi sự tối nghĩa" Tôi nghĩ rằng, câu trả lời đó là một lời ngụy biện phổ biến trong trường hợp này. Lý luận của Michael nói chung cho thấy một lý do tốt hơn để có nó ở nơi khác. Nó chủ yếu chỉ để loại bỏ tất cả các cuộc tấn công đóng chai theo kịch bản. Không nhất thiết có nghĩa là bạn sợ chúng, hoặc coi nó có hiệu quả trước kẻ tấn công quyết tâm. Tôi biết tôi không bao giờ lo lắng họ thực sự vào được. Nhưng tất cả các hành trình đăng nhập đều gây phiền nhiễu.
xenoterracide

1
@xenoterracide: Nếu bạn chỉ quan tâm đến khả năng đọc các tệp nhật ký của mình thì có những cách khác tốt hơn để loại trừ nhiễu thay vì thay đổi cổng như một chiến thuật tối nghĩa, đó là câu hỏi. Liên quan đến việc chặn IP, vốn không phải là một phần của câu hỏi: Xin lưu ý rằng việc thêm phức tạp hơn vào các hệ thống liên quan đến bảo mật cũng đồng nghĩa với việc tăng nguy cơ khai thác. Hãy xem xét ví dụ seclists.org/fulldisclosure/2007/Jun/121 ossec.net/main/attacking-log-analysis-tools . Có, Denyhosts đã bị ảnh hưởng bởi điều này.
maxschlepzig

1
Có nhiều thứ hơn là chỉ đọc trong tâm trí. Một sự thay đổi cổng được ghi lại đúng cách không phải là bảo mật bởi sự tối nghĩa.
xenoterracide

4

Thay đổi cổng SSH chủ yếu là bảo mật nhà hát . Nó cho bạn một cảm giác mờ nhạt khi đã làm một cái gì đó. Bạn đã ẩn cổng SSH dưới thảm chùi chân.

Nếu bạn chạy một máy chủ SSH trên Internet, bạn sẽ thấy rất nhiều lần đăng nhập thất bại trong nhật ký của mình, từ các bot đang tìm kiếm mật khẩu yếu , khóa yếu và khai thác đã biết trong các phiên bản cũ hơn của máy chủ. Những lần thử thất bại chỉ là: những lần thất bại . Theo như đánh giá mức độ dễ bị tổn thương của bạn, chúng hoàn toàn không liên quan. Điều bạn cần lo lắng là những nỗ lực xâm nhập thành công và bạn sẽ không thấy những điều đó trong nhật ký của mình.

Thay đổi cổng mặc định sẽ giảm số lần truy cập của các bot như vậy, nhưng điều đó chỉ cho phép những kẻ tấn công tinh vi nhất bị chặn bởi bất kỳ bảo mật tốt nào (cập nhật bảo mật được áp dụng thường xuyên, mật khẩu mạnh hoặc xác thực mật khẩu bị vô hiệu hóa). Ưu điểm duy nhất là giảm khối lượng của các bản ghi. Nếu đó là một vấn đề, hãy xem xét một cái gì đó như Denyhosts hoặc Fail2ban để hạn chế tốc độ kết nối thay vào đó, nó cũng sẽ giúp băng thông của bạn hoạt động tốt.

Thay đổi cổng mặc định có một nhược điểm lớn: nó khiến bạn ít có khả năng đăng nhập từ phía sau tường lửa. Tường lửa có nhiều khả năng cho phép các dịch vụ đi qua trên cổng mặc định của chúng hơn là trên một số cổng ngẫu nhiên khác. Nếu bạn không chạy máy chủ HTTPS, hãy xem xét việc nghe SSH trên cổng 443 (hoặc chuyển hướng các yêu cầu TCP đến từ cổng 443 sang cổng 22), vì một số tường lửa cho phép lưu lượng truy cập mà chúng không thể giải mã trên cổng 443 vì nó trông giống như HTTPS.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.