Tại sao thay đổi cổng ssh mặc định? [đóng cửa]


Câu trả lời:


65

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ọ.


Tôi là người dùng duy nhất của máy chủ này. Cảm ơn đã làm rõ vấn đề 1024+. Tôi đã sử dụng cổng 48xxx nếu tôi chọn. Dù sao tại thời điểm này tôi vẫn không nhận được nếu nó hữu ích hay không = /
động

16
+1 cho> 1024 bit.
MattC

26

Đó 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ì nmapviệc quét một lần đơn giản sẽ tiết lộ cổng mà nó thực sự đang chạy.


3
"kiểm tra tất cả 64k cổng có thể" ... Chạy SSH ở bất kỳ cổng nào trên 1023 là sai. Nó làm cho hệ thống hơn dễ bị tổn thương hơn để lại cho nó chạy ở cổng mặc định của nó.
Juliano

3
@Juliano - hãy giải thích. Chỉ vì bạn phải root để nghe trên một cổng đặc quyền không (AFAIK) làm cho nó không an toàn khi chạy trên một cổng không có đặc quyền.
Alnitak

4
Nhân tiện, nó không bảo mật thông qua che khuất, nếu không, bạn cũng sẽ phải gọi xác thực mật khẩu giống nhau. Bảo mật thông qua che khuất là khi việc thực hiện không được tiết lộ. Ở đây, việc triển khai được nêu rõ (đó là "Tôi đã thay đổi cổng dịch vụ") và bí mật ("cổng nào?") Vẫn là bí mật.
Juliano

5
@ John - thực sự tôi thấy quan điểm của @ Juliano. Về bản chất, nó không làm cho daemon SSH trở nên kém an toàn hơn, nhưng trong trường hợp chung chạy trên một cổng không có đặc quyền sẽ làm mất đi giả định bình thường rằng root đã khởi động daemon. Vì vậy, nếu bạn bằng cách nào đó có thể dừng trình nền đó (ví dụ: bằng cách thực hiện), bạn có thể bắt đầu trình nền giả của mình ở vị trí của nó mà không cần khai thác root. Daemon giả đó sau đó có thể nắm bắt đủ các chi tiết để cho phép khai thác thêm.
Alnitak

2
@ John, điều đó đúng - nó vẫn yêu cầu kẻ tấn công phải có đủ quyền truy cập để tự bắt đầu một daemon mới. Điểm mấu chốt là họ không còn cần quyền truy cập root để bắt đầu nó.
Alnitak

21

Để 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:

  • Cài đặt denyhosts hoặc fail2ban
  • Giới hạn số lượng kết nối mỗi giây trên cổng ssh
  • Thay đổi cổng ssh
  • Từ chối đăng nhập root
  • Cho phép xác thực bằng khóa thay vì mật khẩu

11
Có vẻ như một danh sách tốt ngoại trừ phần thay đổi cổng mà tôi không thực sự đồng ý, điều đó quá tối nghĩa. Một máy quét cổng hiện đại sẽ tìm thấy nó trong vòng vài giây? (và nhiều mạng sẽ không cho phép lưu lượng truy cập cổng ngẫu nhiên, thường giới hạn ở 22, 80 và 443)
Oskar Duveborn

1
Các cuộc tấn công vũ lực giới hạn thay đổi cổng kiểm tra ssh chạy trên cổng mặc định, nếu cuộc tấn công nghiêm trọng hơn, chỉ trong trường hợp này, kẻ tấn công có thể thực hiện quét các cổng lỗ trong mạng / máy chủ của bạn.
Ali Mezgani

1
Trên thực tế, tôi nghĩ rằng đằng sau một tường lửa tốt, nếu bạn luôn cập nhật các dịch vụ của mình và nếu bạn thay đổi cài đặt mặc định của chúng, bạn có thể an toàn trước các cuộc tấn công của những kẻ độc hại. và có thể không phải từ khai thác 0 ngày hoặc các cuộc tấn công không xác định
Ali Mezgani

2
Sử dụng denyhosts / fail2ban giảm thiểu sự cần thiết phải chuyển đổi cổng hoặc yêu cầu khóa. Nếu bạn không cho phép mật khẩu thì sẽ không có ý nghĩa khi sử dụng denyhosts / fail2ban hoặc thay đổi cổng.
Jeremy L

1
Sử dụng denyhosts / fail2ban không nhất thiết giảm thiểu sự cần thiết phải có các biện pháp bảo mật bổ sung. Điểm quan trọng đối với bảo mật là tạo ra càng nhiều khối đường càng tốt cho người dùng cố gắng phá vỡ bảo mật. Chắc chắn bạn có thể không cần thay đổi cổng từ 22 thành 2222 nhưng nói rằng một quản trị viên khác xuất hiện và bật lại mật khẩu ... bạn vẫn sẽ có một số lần tăng tốc khác. Mỗi bước được liệt kê ở trên sẽ giúp quản trị viên một tỷ lệ phần trăm gần với khả năng bảo mật 100%.
Patrick R

12

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.


2
+1 cho "giữ nhật ký rõ ràng"
Lekensteyn

3
Nhưng hãy nhìn vào câu trả lời của David Spillett để biết tại sao cổng 1291 (lớn hơn 1024) có thể nguy hiểm.
Konerak

Nếu bạn sẽ khuyên bạn nên sử dụng một cổng không được ưu tiên trong 2 năm sau rất nhiều câu trả lời khác, tốt hơn - có lẽ nên chuẩn bị một lý do tốt hơn là 'Tôi đã thấy các công ty làm điều đó'. Tôi đã thấy các công ty làm rất nhiều thứ. Tôi hiếm khi muốn làm theo ví dụ của họ.
gạch dưới

11

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:

  • 99.9999% các cuộc tấn công vũ phu được thực hiện bởi các bot chỉ tìm kiếm cổng 22 và không bao giờ lãng phí thời gian để cố gắng khám phá cổng không chuẩn. Các cuộc tấn công vũ lực và các biện pháp đối phó như denyhost hoặc fail2ban tiêu tốn tài nguyên, bạn sẽ tiết kiệm được bằng cách chạy máy chủ ssh trên một cổng không chuẩn.
  • Bạn sẽ thoát khỏi tất cả các báo cáo vô ích về các bot đang cố xâm nhập vào hệ thống của bạn. Nếu bất kỳ IP nào xuất hiện trong báo cáo đăng nhập thất bại, rất có thể đây là con người.

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.


1
Điều này có thể dẫn đến các cuộc gọi hỗ trợ thậm chí nhiều hơn mặc dù.
Brad Gilbert

3
Điều này là đúng, nhưng bảo mật nâng cao có giá. :)
Sinh ra để đi xe

11

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.


1
Vâng. Khi tôi có ssh trên cổng 22, tôi đã có> 20000 lần thử mật khẩu thất bại hiển thị trong nhật ký của tôi mỗi ngày. Điều đó có nghĩa là tôi nhận được một email cảnh báo bảo mật mỗi ngày. Tôi đã vô hiệu hóa xác thực mật khẩu - bạn phải có một khóa riêng phù hợp để đăng nhập - vì vậy tôi không lo lắng về việc ai đó sẽ vào, nhưng tôi chỉ nhận được email cảnh báo bảo mật khi có chuyện gì đó thực sự xảy ra.
jdege

10

Tôi sẽ chạy ssh trên cổng tiêu chuẩn và sử dụng một cái gì đó như fail2ban hoặc denyhosts để hạn chế số lần tấn công từ điển.

Một tùy chọn khác là vô hiệu hóa đăng nhập bằng mật khẩu altogheter và chỉ cho phép đăng nhập bằng khóa ssh.


8

Bởi vì có rất nhiều người xấu ở ngoài đó quét tất cả IP máy chủ để tìm các cổng mở trong nỗ lực khai thác. Tôi đã từng tấn công búa vào cổng SSH của mình suốt cả ngày cho đến khi tôi chuyển nó sang một cổng khác và trên một IP không được liên kết với bất kỳ trang web nào của tôi nữa.


7

Đ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) .


6

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.


5

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.


4

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ọ


không đề cập đến việc một máy quét cổng cũng sẽ thử các cổng khác.
Jim Deville

4

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.


Nếu bạn / hoàn toàn vô dụng / hoàn toàn vô dụng vì bảo mật /, tôi sẽ đồng ý. Tuy nhiên, việc thay đổi cổng rất hữu ích để giảm tiếng ồn trong nhật ký xác thực.
Chris S

"Và yêu cầu xác thực dựa trên khóa"? cái gì đây
động

1
@ yes123, SSH có thể sử dụng các cặp khóa công khai để xác thực người dùng thay vì mật khẩu. Cặp khóa này cũng có thể được bảo vệ bằng mật khẩu, do đó cung cấp xác thực hai yếu tố (thứ bạn biết = mật khẩu; thứ bạn có = tệp chính). Nếu bạn thực hiện điều này, bạn có thể vô hiệu hóa đăng nhập mật khẩu (do đó ai đó biết mật khẩu cục bộ của bạn không thể truy cập bằng tệp chính và mật khẩu của tệp chính). Mật khẩu tương đối không an toàn so với các khóa, dễ dàng hơn hàng triệu lần so với các cặp khóa (mặc dù vẫn khó khăn thường). Xem man ssh-keygenđể biết nhiều thông tin.
Chris S

@ yes123, các trang man liên quan đến ssh khác nhau (sshd, sshd_config, ssh, ssh_config) là cách đọc hữu ích. Tài liệu này trông giống như một hướng dẫn tốt về xác thực khóa công khai với ssh.
larsks

2

Mặc dù trông giống như một "bảo mật bằng cách che khuất" điển hình, tôi ước tính nó có ý nghĩa vì việc quét tất cả các cổng có thể (~ 64k) là một cách tốn kém thời gian hơn so với chỉ một trong số chúng.

Nhưng tôi có thể thêm rằng "cổng gõ" là tốt hơn nhiều.


1

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.


Ý tưởng tốt với cổng phía trước, John! Tôi nghĩ rằng cả hai chúng tôi đã học được điều gì đó :)
Alnitak

1

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.


1

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.


0

Tôi đoán nếu bạn chưa khám phá cổng gõ tiện dụng của nó, khác, không.


0

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.


0

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.


0

Đâ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ù.


-3

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.


2
-1, Bạn dường như không hiểu được sự tối nghĩa là gì ... Làm một cái gì đó không rõ ràng không giống như đặt một khóa trên nó. Mặc dù đúng là không có bảo mật nào là tuyệt đối, nhưng chắc chắn có sự khác biệt và việc xác thực ba yếu tố với sự tối nghĩa không giúp được ai.
Chris S

1
Xin lỗi, Chris, đó là tôn giáo sùng bái hàng hóa. Có thể bạn không thể chọn một khóa, và do đó nghĩ rằng có một khóa giúp bạn an toàn, nhưng tất cả các khóa đều có thể được chọn. Hãy suy nghĩ bên ngoài hộp: Trong nhiều trường hợp, làm cho một cái gì đó "không rõ ràng" có thể vượt trội hơn so với sử dụng khóa. Mô hình / quan điểm bảo mật của bạn giống như để máy tính xách tay của bạn trong một chiếc xe bị khóa với bộ báo thức - một chiếc loa có đá và máy tính xách tay của bạn đã biến mất. Nhưng có lẽ đó không phải là một đôi giày, mà là một người khai thác 0 ngày và thời gian để giết ... Ôi, nhìn kìa! Chris có một mục tiêu "an toàn" và khá rõ ràng! Che khuất là một phần RẤT quan trọng của bảo mật.
joe ngẫu nhiên

Xin lỗi, nhưng sự so sánh và logic của bạn không theo kịp. Tôi biết làm thế nào để chọn ổ khóa, nó nhanh hơn để cắt chúng, phá vỡ một cửa sổ, đi xung quanh. Mỗi biện pháp bảo mật có một số lượng thời gian và nỗ lực cần thiết để có được xung quanh nó; che khuất mất ít thời gian và công sức, theo thứ tự từ vài phút đến vài giờ. Bảo mật thực sự, như tốc độ giới hạn mật khẩu, làm cho việc vượt qua mật khẩu mất một lượng thời gian đáng kể. Sự chênh lệch đáng kể về thời gian đó là sự khác biệt giữa bảo mật 'giả' và 'thực'; che khuất rơi vào trước đây.
Chris S
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.