Câu trả lời:
Nó không hữu ích như một số người tuyên bố, nhưng ít nhất nó sẽ làm giảm tác động đến các tệp nhật ký của bạn vì nhiều lần thử đăng nhập mạnh mẽ chỉ sử dụng cổng mặc định thay vì quét để xem SSH có nghe ở nơi khác không. Một số cuộc tấn công sẽ quét SSH ở nơi khác, vì vậy nó không phải là viên đạn bạc.
Nếu máy chủ của bạn sẽ là một máy chủ được chia sẻ, thay vì chỉ phục vụ nhu cầu của các dự án của bạn, sử dụng một cổng không mặc định có thể gây khó khăn vì bạn sẽ phải giải thích nó nhiều lần và nhiều lần khi họ quên và các chương trình máy khách của họ không kết nối được với cổng 22!
Một vấn đề khác có thể xảy ra với SSH trên một cổng không chuẩn là nếu bạn gặp phải máy khách có bộ lọc ngoài hạn chế, người không thể kết nối với cổng tùy chỉnh của bạn vì bộ lọc của họ chỉ cho phép, ví dụ, cổng 22, 53, 80 và 443 là đích đến cho các kết nối mới. Điều này là không phổ biến, nhưng chắc chắn không phải là chưa từng nghe thấy. Trong một vấn đề tương tự, một số ISP có thể thấy lưu lượng được mã hóa trên một cổng khác với các cổng mà nó thường được mong đợi (cổng 443 hoặc HTTPS, 22 cho SSH, v.v.) như một nỗ lực để ẩn kết nối và điều tiết P2P (hoặc chặn) kết nối một cách bất tiện.
Cá nhân tôi giữ SSH trên cổng tiêu chuẩn để thuận tiện. Miễn là các biện pháp phòng ngừa thông thường được thực hiện (chính sách mật khẩu / khóa mạnh, hạn chế đăng nhập gốc, ...) không cần phải lo lắng và vấn đề tăng trưởng tệp nhật ký khi bạn bị tấn công bằng vũ lực có thể được giảm thiểu bằng cách sử dụng các công cụ như như fial2ban để tạm thời chặn các máy chủ cung cấp quá nhiều thông tin xác thực xấu trong một khoảng thời gian nhất định.
Dù bạn chọn cổng nào, nếu bạn di chuyển khỏi 22, hãy đảm bảo rằng nó ở dưới 1024. Trong hầu hết các thiết lập tương tự Unix trong cấu hình mặc định của họ, chỉ có root (hoặc người dùng trong nhóm gốc) có thể nghe trên các cổng dưới 1024, nhưng bất kỳ người dùng nào cũng có thể nghe trên các cổng cao hơn. Chạy SSH trên một cổng cao hơn sẽ tăng khả năng người dùng lừa đảo (hoặc bị hack) quản lý để đánh sập trình nền SSH của bạn và thay thế nó bằng proxy hoặc proxy của họ.
Đó là một hình thức bảo mật đơn giản (nhưng hiệu quả đáng ngạc nhiên) thông qua che khuất .
Nếu máy chủ SSH của bạn không có trên cổng 22 thì rất ít khả năng sẽ được tìm thấy bởi những người quét toàn bộ internet đang tìm kiếm mật khẩu yếu trên các tài khoản mặc định. Nếu bạn đang quét toàn bộ mạng, bạn không thể kiểm tra tất cả 64k cổng có thể để tìm máy chủ SSH.
Tuy nhiên, nếu ai đó chủ động nhắm mục tiêu vào bạn, điều đó không mang lại lợi ích gì, vì nmap
việc quét một lần đơn giản sẽ tiết lộ cổng mà nó thực sự đang chạy.
Để thực sự tránh các cuộc tấn công tàn bạo, điều quan trọng là phải tuân theo một số bước:
Vâng, nó rất hữu ích vì nó chỉ giúp tránh tất cả các cuộc tấn công vũ phu và giúp giữ cho các bản ghi rõ ràng :)
đối với số cổng tùy thuộc vào bạn, tôi đã thấy các công ty sử dụng 1291 khá thường xuyên. Tôi sử dụng một cái gì đó cao hơn mặc dù chỉ để giúp tránh một số các kịch bản.
Không cho phép đăng nhập ssh gốc và thay đổi số cổng và có lẽ một cái gì đó như fail2ban và bạn nên là vàng. thêm iptables cho các biện pháp tốt và giữ cho bạn cập nhật và bạn không nên có bất kỳ vấn đề nào.
Sử dụng cổng ssh không chuẩn sẽ yêu cầu giải thích và tài liệu nhiều hơn và trả lời email "Tôi không thể đăng nhập".
Tôi xem xét các lợi ích sau của việc chạy sshd trên một cổng không chuẩn hơn quan trọng hơn các vấn đề mà nó tạo ra:
Hơn nữa, nếu bạn muốn thực sự khó chịu, bạn luôn có thể chạy sshd giả (với DenyUsers * ) trên cổng tiêu chuẩn 22, trong khi sshd thông thường của bạn chạy trên cổng 54321. Điều này sẽ đảm bảo với bạn rằng tất cả các bot và kẻ xâm nhập sẽ vĩnh viễn cố gắng đăng nhập vào một dịch vụ từ chối tất cả các thông tin đăng nhập, bởi vì sẽ không có ai nghĩ đến việc cố gắng tìm dịch vụ sshd thực sự của bạn .
2 xu của tôi.
Làm điều này cho bất kỳ lý do "bảo mật" là không có thật. Đó là ví dụ tốt nhất về bảo mật bởi sự tối nghĩa không phải là bảo mật.
Nếu bạn muốn giữ nhật ký của mình nhẹ hơn và sạch hơn một chút, thì có, nó sẽ hữu ích vì bạn sẽ không nhận được nhiều nỗ lực gõ cổng / kịch bản kiddy.
Điều này hữu ích ở chỗ các bot kịch bản thử các cuộc tấn công đoán mật khẩu mạnh mẽ thường tập trung vào Cổng 22, vì vậy việc thay đổi các cổng thường khiến chúng bị loại bỏ. Bạn sẽ cần phải cân bằng giá trị giảm thiểu rủi ro đó với nỗi đau khi định cấu hình các máy khách ssh để kết nối với cổng không chuẩn (không phải là một nỗi đau quá lớn nếu bạn không có nhiều người dùng kết nối, thừa nhận).
Thay phiên, bạn có thể giảm thiểu rủi ro vũ phu bằng cách tắt xác thực mật khẩu và yêu cầu xác thực khóa RSA thay thế.
Tôi thường không thay đổi cổng trên SSHD, vì vậy tôi không thể đề xuất một số khác, nhưng kiểm tra danh sách các cổng thường được sử dụng để tìm một số khác (tức là một số không được sử dụng bởi một thứ khác và do đó có thể được quét) .
Tôi luôn thay đổi SSHd của mình để sử dụng cổng 2222, mọi người cần vào máy chủ của tôi đều biết điều này và không có gì bí mật. Hoàn toàn không có lợi ích bảo mật bằng cách làm điều này (trừ khi tin tặc sẽ là một kẻ biến thái tuyệt đối).
Lợi ích duy nhất tôi nhận được từ việc này là nhật ký xác thực không có một triệu lần đăng nhập thất bại cho 'root', 'alice', 'bob', 'sally', 'admin', v.v.
Bảo mật thông qua che khuất đã được chứng minh là vô dụng, thông thường tôi định cấu hình truy cập ssh với cổng tiêu chuẩn cho tất cả các lý do đã đề cập ở trên (các vấn đề của khách hàng trong việc cấu hình lại, các vấn đề về tường lửa và proxy, v.v.).
Thêm vào đó, tôi luôn vô hiệu hóa xác thực đăng nhập và mật khẩu gốc và như bước cuối cùng tôi sử dụng fail2ban để loại bỏ các tin nhắn gây phiền nhiễu đó trong syslog. Trong Debian / Ubuntu nó đơn giản như gõ aptitude install fail2ban
. Cấu hình mặc định hoạt động khá tốt, nhưng tôi thường điều chỉnh một số tham số để hạn chế hơn khi có thời gian cấm lâu hơn (ít nhất một ngày) và chỉ có 2 lần xác thực thất bại là kích hoạt lệnh cấm.
Tôi muốn nói rằng điều bạn tự bảo vệ mình nhất khi thay đổi cổng SSH là quét tự động sẽ thử và lấy quyền truy cập bằng tên người dùng / mật khẩu tiêu chuẩn, nếu chính sách mật khẩu của bạn chặt chẽ, bạn không phải lo lắng về họ
Nếu bạn vô hiệu hóa đăng nhập mật khẩu vào máy chủ của mình (rất được khuyến khích), thì việc thay đổi cổng SSH là hoàn toàn vô dụng. Bằng cách vô hiệu hóa thông tin đăng nhập mật khẩu (và yêu cầu xác thực dựa trên khóa), bạn loại bỏ khả năng thử mật khẩu mạnh mẽ, do đó bạn không đạt được bất cứ điều gì bằng cách sử dụng số cổng.
Nếu bạn tiếp tục cho phép xác thực cơ sở mật khẩu, thì bạn sẽ để ngỏ khả năng nỗ lực vũ phu thành công hoặc - thông thường hơn, theo kinh nghiệm của tôi - mật khẩu của bạn bị xâm phạm vì bạn nhập mật khẩu khi sử dụng hệ thống đang chạy một keylogger.
man ssh-keygen
để biết nhiều thông tin.
Không phải là một câu trả lời nhưng quá dài cho một nhận xét, vì vậy tôi sẽ thực hiện CW này.
Tôi đã suy nghĩ về điều này một thời gian và đã đi đến kết luận rằng có rất nhiều sự thật trong những gì Juliano nói trong các bình luận cho câu trả lời của Alnitak. Tuy nhiên, tôi thấy rằng bằng cách chạy SSH trên cổng 22, việc khởi chạy các cuộc tấn công dưới mọi hình thức chống lại nó quá dễ dàng.
Để giải quyết vấn đề này, tôi chạy các máy chủ SSH nội bộ của mình trên cổng 22 và sử dụng tường lửa để chuyển cổng cao sang 22 trên các máy đích. Điều này mang lại một số bảo mật thông qua sự tối nghĩa trong khi vẫn giữ được sự bảo mật của một cổng thấp, như Juliano đã chỉ ra.
Bảo mật thông qua che khuất không phải là một nguyên tắc tôi thường đăng ký và người ta thường chỉ ra rằng việc quét cổng đơn giản sẽ tiết lộ cổng mục tiêu, làm cho việc che khuất trở nên vô dụng. Để giải quyết vấn đề đó, tường lửa của tôi (Smoothwall Express), cả ở nơi làm việc và ở nhà, hãy sử dụng tập lệnh có tên là Phản hồi chủ động của người giám hộ, được kích hoạt bởi các cảnh báo Snort. Từ quan sát tôi có thể nói với bạn rằng khi bạn nhấn hơn 3 cổng khác nhau từ cùng một nguồn, các gói của bạn sẽ bị hủy cho đến thời gian đặt lại được đặt trước. Điều này làm cho việc quét cổng khá khó khăn và cực kỳ tốn thời gian, khiến cho việc che khuất thực sự có giá trị. Trên thực tế, điều này khiến tôi bị tắt nhiều lần trong quá khứ đến nỗi tôi đã đặt loại trừ cho địa chỉ IP nguồn (nhà hoặc văn phòng) của mình.
Vấn đề bạn gặp phải là tường lửa được thiết lập để chỉ cho phép một số IP nhất định kết nối và ông chủ mệt mỏi khi mở các IP cụ thể khi anh ta ra ngoài. Nếu bạn đang khóa một số IP nhất định tại tường lửa, đó có thể là một vấn đề khó khăn.
Hai điều tôi nghĩ về đây. Thay đổi cổng bảo vệ chống lại các cuộc tấn công tự động. Đó là về nó, nhưng đó là một phần lớn của lưu lượng tấn công trung bình ngoài kia ... các mạng quét tập lệnh tự động. Nếu bạn thay đổi cổng mặc định, các cuộc tấn công đó sẽ giảm xuống thành không có gì. Vì vậy, nó có ý nghĩa trong vấn đề đó. Nhưng nó không làm gì để chống lại một cuộc tấn công có hướng, vì kẻ tấn công chỉ có thể quét từ Nessus hoặc NMAP để xác định (các) cổng nào bạn đang sử dụng nếu bạn có một người bạn nhỏ đặc biệt ghét bạn đủ.
Thứ hai, nếu bạn đang sử dụng các máy chủ giống UNIX, bạn có thể cài đặt một tiện ích như Denyhosts để ngăn chặn các cuộc tấn công. Nếu bạn cài đặt denyhost, nó sẽ theo dõi các lần đăng nhập không chính xác và sau khi (bất cứ điều gì bạn xác định số) không thành công, nó sẽ cấm IP trong một khoảng thời gian bạn chỉ định. Denyhost cũng có thể nói chuyện với các máy chủ denyhost khác và chuyển qua danh sách cấm, vì vậy nếu kẻ tấn công bị khóa khỏi hệ thống Linux của Fred ở Montana, hệ thống của bạn cũng sẽ bị cấm IP đó. Rất hữu ích miễn là người dùng của bạn nhớ mật khẩu của họ.
Tất cả phụ thuộc vào kịch bản sử dụng của bạn. Bạn có bao nhiêu chương trình là một "nỗi đau ở mông" khi thay đổi cổng kết nối cho SSH / SCP (và nếu họ không cho phép hoặc làm cho nó đau, bạn thực sự cần phải xem xét việc thay đổi nhà cung cấp, cá nhân). Nếu đó chỉ là một nỗi sợ hãi tiềm tàng thì tôi nói đó không phải là vấn đề. Và đây là ông chủ của bạn, yêu cầu một cái gì đó không hoàn toàn lập dị vì rất nhiều sysadins đã lật cổng SSH (với một số từ những người ghét bất cứ thứ gì có mùi thậm chí mờ nhạt về bảo mật thông qua che khuất ... nhưng nó thực sự bị cắt giảm tiếng ồn nền cruft từ quét tự động.)
Luộc xuống - thay đổi cổng chặn các tập lệnh tự động và hầu hết lưu lượng xấu. Sẽ không ngừng những kẻ tấn công được chỉ đạo. Xem xét cài đặt một tiện ích cấm tự động là tốt. Bảo mật trong các lớp không làm tổn thương bạn nếu được thực hiện đúng cách và việc thay đổi cổng giúp ích nhiều hơn nó gây tổn thương trong hầu hết các tình huống.
Tôi đã chạy SSH trên cổng> 1024 trong hơn 5 năm nay. Kể từ đó, tôi không thấy bất kỳ nỗ lực portscan nào trong tệp nhật ký của mình (ngoại trừ từ chính tôi). Có những máy chủ mà tôi quản trị chạy bằng cổng> 1024.
Nhiều máy chủ SSH chạy trên cổng> 1024, có các trang web riêng khá phổ biến.
Nếu máy chủ SSH chạy trong công ty của riêng tôi, có lẽ tôi đã đăng địa chỉ IP của máy chủ đó vào đây để các bạn có thể cố gắng hack vào máy chủ. Thật không may, máy chủ SSH không phải của riêng tôi. ;-)
Nhưng có những thứ khác mà bạn sẽ phải thiết lập để làm cho nó an toàn. SSH> 1024 thôi là không đủ. Số cổng không được có trong / etc / services, phải sử dụng chuyển tiếp cổng (ví dụ: cổng 1124-> 22), quyền truy cập trực tiếp vào Root phải bị vô hiệu hóa và điều khác.
Vì vậy, nếu bạn muốn tranh luận, tốt hơn nên chạy SSH trên cổng> 1024 trong vài năm.
p / s: 1124 không phải là cổng SSH của tôi. Haha.
Việc chuyển SSH sang một cổng khác cũng có ý nghĩa, nó giúp bảo mật nhưng không lớn. Tất nhiên để làm như vậy, bạn phải kiểm soát tường lửa của mình nhưng đó không phải là vấn đề với bạn. Những gì tôi nghĩ sẽ làm giảm lợi ích của việc di chuyển cảng là mở ra phạm vi được chấp nhận - thực tế tôi nói rằng nó còn hơn cả lợi ích và giúp bạn tiếp tục phát triển hơn bạn hiện nay. Tôi chắc chắn rằng bạn có thể thuyết phục anh ấy di chuyển cả cổng VÀ giảm đáng kể phạm vi đến bằng cách đối chiếu danh sách các điểm nhập cảnh có khả năng thay vì chỉ mở tất cả chúng lên.
Thay đổi cổng ssh của bạn là một bài tập vô nghĩa chỉ mua cho bạn bảo mật hạn chế. Tốt hơn hết là bạn nên vô hiệu hóa xác thực mật khẩu, loại bỏ nguy cơ thử mật khẩu mạnh mẽ và chỉ dựa vào xác thực dựa trên khóa ssh. Nếu môi trường của bạn yêu cầu xác thực mật khẩu, hãy áp dụng một số cơ chế hai yếu tố, như SecurID hoặc Wikid.
Cả hai điều này đều mang đến cho bạn sự gia tăng thực sự về bảo mật, trong khi việc thay đổi cổng ssh chỉ mang đến cho bạn ảo tưởng về bảo mật.
Đây là POV thực tế: Tôi đã vận hành các máy chủ ssh riêng hiển thị công khai trong hơn bốn năm với cổng SSH đã thay đổi và tôi không có một lần quét mật khẩu nào. Vì lợi ích của QA này, tôi vừa kích hoạt trở lại 22 cho một trong số họ trong một ngày. Kết quả là tôi được quét khoảng 10 phút một lần với tần suất thử mật khẩu khoảng 5 mỗi giây. Ngoài ra, "quét kiddies" cũng tìm kiếm các máy chủ có lỗ hổng OpenSSH nhất định.
Vì chắc chắn đây là bảo mật bởi sự tối nghĩa không giúp ích gì nếu bạn có kẻ thù.
Nó hoạt động rất tốt, bất kể sự than vãn của đám đông "bảo mật thông qua che khuất".
Thỏ ngớ ngẩn, TẤT CẢ an ninh là an ninh thông qua tối nghĩa. Chỉ vì bạn tin rằng giao thức tiền điện tử tối nghĩa Z [yêu cầu kết hợp các mẫu DNA, khóa chung và không thể thực sự nhập bằng mật khẩu của con người] thực sự an toàn không làm cho nó trở nên như vậy. Sự thật là, bất kỳ và tất cả các biện pháp bảo mật đều dựa vào xác suất và giả định của người dùng. Quá tệ cho bạn nếu tôi biết cách khai thác giả định đó, nhưng nó có.
Dù sao,
Chúng tôi đã thực hiện điều này trong nhiều năm, cùng với việc a) hạn chế tốc độ thử kết nối (tuy nhiên, tôi không biết cách chúng tôi thiết lập nó, một cái gì đó trong cấu hình ssh) và b) một tập lệnh để cấm bất kỳ máy chủ nào chạy một cuộc tấn công từ điển với hơn X đoán sai trong Y phút. Chúng tôi cấm máy chủ thực hiện kết nối trong một khoảng thời gian và điều đó giúp dễ dàng thích nghi với cấu trúc liên kết của các mạng thay đổi.
Nếu mật khẩu của bạn đủ phức tạp và chúng chỉ có thể thực hiện 3 lần thử trong 15 phút, thì không có gì phải sợ. Không khó để theo dõi các cuộc tấn công phân tán, - chúng ta thường đối chiếu bằng mạng con và ip để loại trừ điều đó.
Cuối cùng, tất cả những gì bạn cần là một số phương pháp sóc bí mật để cho phép kết nối với cổng của bạn bằng cách sửa đổi quy tắc f / w. Nó có thể là bất cứ điều gì ... smtp, web, ma thuật truy vấn dns. Những thứ như SecurID hoặc Wikid chỉ trao thêm thông tin cho bên thứ ba. Và đừng để tôi bắt đầu chứng nhận an toàn thông qua bên thứ ba.