Điểm:17

Server

Làm cách nào để bảo vệ SSH?

Ali

09:38, 09/11/2022

Tôi kiểm tra /var/log/secure và tôi có những nhật ký này:

Ngày 9 tháng 7 13:02:56 sshd localhost [30624]: Quản trị viên người dùng không hợp lệ từ cổng 223.196.172.1 37566
Ngày 9 tháng 7 13:02:57 sshd localhost [30624]: Kết nối bị đóng bởi quản trị viên người dùng không hợp lệ 223.196.172.1 cổng 37566 [preauth]
Ngày 9 tháng 7 13:03:05 sshd localhost [30626]: Quản trị viên người dùng không hợp lệ từ cổng 223.196.174.150 61445
Ngày 9 tháng 7 13:03:05 sshd localhost [30626]: Kết nối bị đóng bởi quản trị viên người dùng không hợp lệ 223.196.174.150 cổng 61445 [preauth]
Ngày 9 tháng 7 13:03:16 sshd localhost [30628]: Quản trị viên người dùng không hợp lệ từ cổng 223.196.169.37 62329
Ngày 9 tháng 7 13:03:24 sshd máy chủ cục bộ [30628]: Kết nối bị đóng bởi quản trị viên người dùng không hợp lệ 223.196.169.37 cổng 62329 [preauth]
Ngày 9 tháng 7 13:03:29 sshd localhost [30630]: Quản trị viên người dùng không hợp lệ từ 223.196.169.37 cổng 64099
Ngày 9 tháng 7 13:03:30 sshd localhost [30630]: Kết nối bị đóng bởi quản trị viên người dùng không hợp lệ 223.196.169.37 cổng 64099 [preauth]
Ngày 9 tháng 7 13:03:45 sshd localhost [30632]: Quản trị viên người dùng không hợp lệ từ cổng 223.196.174.150 22816
Ngày 9 tháng 7 13:03:46 sshd localhost [30632]: Kết nối bị đóng bởi quản trị viên người dùng không hợp lệ 223.196.174.150 cổng 22816 [preauth]
Ngày 9 tháng 7 13:06:17 sshd localhost [30637]: Quản trị viên người dùng không hợp lệ từ cổng 223.196.168.33 33176
Ngày 9 tháng 7 13:06:17 sshd máy chủ cục bộ [30637]: Kết nối bị đóng bởi quản trị viên người dùng không hợp lệ 223.196.168.33 cổng 33176 [preauth]
Ngày 9 tháng 7 13:07:09 sshd localhost [30639]: Quản trị viên người dùng không hợp lệ từ 223.196.173.152 cổng 61780
Ngày 9 tháng 7 13:07:25 sshd localhost [30641]: Quản trị viên người dùng không hợp lệ từ cổng 223.196.168.33 54200
Ngày 9 tháng 7 13:07:26 sshd máy chủ cục bộ [30641]: Kết nối bị đóng bởi quản trị viên người dùng không hợp lệ 223.196.168.33 cổng 54200 [preauth]
...

Có vẻ như ai đó đang cố đăng nhập bằng SSH. Tôi tắt đăng nhập bởi người dùng root và bật đăng nhập khóa công khai/riêng tư, nhưng đây có phải là một cuộc tấn công DDoS không? Và nó có sử dụng RAM/CPU không?

Tôi nên làm gì?

4074

7 + 2

linux

ddos

marcelm

08:23, 10/11/2022

_"Tôi [...] bật đăng nhập khóa công khai/riêng tư,..."_ - Nhưng bạn cũng đã tắt tính năng đăng nhập bằng mật khẩu phải không?

10

Hồi đáp

marcelm

08:28, 10/11/2022

[Câu trả lời này](https://unix.stackexchange.com/a/503346/109651) cũng có thể được quan tâm.

0

Hồi đáp

Điểm:45

Server

Simon Richter

10:29, 09/11/2022

Đó chỉ là tiếng ồn nền Internet bình thường của những người đang quét các máy chủ dễ bị tấn công.

Bạn có thể thêm quy tắc iptables để xếp hạng giới hạn kết nối đến (ví dụ: bốn trong bốn phút) để khắc phục đơn giản (nhưng điều đó cũng sẽ khóa bạn nếu bạn mở quá nhiều kết nối hoặc ai đó giả mạo các gói SYN bắt nguồn từ địa chỉ của bạn):

iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 240 --hitcount 4 --name ssh-v4 --mask 255.255.255.255 --rsource -j TỪ CHỐI --từ chối-với tcp-reset
iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name ssh-v4 --mask 255.255.255.255 --rsource -j ACCEPT

Giải pháp thích hợp là sử dụng một công cụ như fail2ban phân tích tệp nhật ký cho các lần đăng nhập không thành công và tạo các quy tắc tường lửa theo yêu cầu -- cần thêm một chút công việc để thiết lập, nhưng nó yêu cầu kết nối được thiết lập và xác thực không thành công để kích hoạt, do đó, nó sẽ không phản ứng với các nỗ lực kết nối giả mạo hoặc đăng nhập thành công như cách tiếp cận đơn giản làm.

0 + 19

njzk2

21:43, 09/11/2022

làm thế nào về việc thay đổi cổng ssh?

4

Hồi đáp

Michael Hampton

00:37, 10/11/2022

@njzk2 Nó chỉ gây bất tiện cho bạn thôi. Các bot sẽ tìm thấy cổng ssh thay thế của bạn sớm hay muộn.

11

Hồi đáp

Jasen

04:46, 10/11/2022

Thêm công việc để thiết lập? Trên Debian `apt-get install fail2ban` sẽ bảo vệ bạn với các giá trị mặc định hợp lý

3

Hồi đáp

LinuxSecurityFreak

08:36, 10/11/2022

@MichaelHampton Có 65535 cổng, bằng cách nào đó tôi nghi ngờ các bot sẽ chiếm phạm vi như vậy, nhưng tôi có thể nhầm. Bạn có biết điều này cho một thực tế?

3

Hồi đáp

Simon Richter

08:37, 10/11/2022

@LinuxSecurityFreak, có [shodan](https://shodan.io).

7

Hồi đáp

Michael Hampton

10:03, 10/11/2022

@LinuxSecurityFreak Cá nhân tôi không thay đổi cổng ssh, nhưng tôi đã nghe rất nhiều lời phàn nàn từ những người đã làm trong nhiều năm và _still_ đã khiến các bot thử ssh trên cổng mới mà họ chọn, ngay cả khi đó không phải là điều hiển nhiên như 2222.Và tất nhiên shodan quét mọi thứ. Bạn có thể chắc chắn rằng họ không phải là những người duy nhất.

1

Hồi đáp

Jon Bentley

10:59, 10/11/2022

@MichaelHampton Thay đổi cổng sẽ loại bỏ *một số* bot. Ngoài ra, nó bất tiện theo cách nào (ngoài thiết lập ban đầu)?

1

Hồi đáp

hardillb

14:21, 10/11/2022

@jonbentley phải nhớ thay đổi nó trong mọi ứng dụng khách bạn muốn sử dụng để kết nối. Bảo mật bởi Obscurity hoàn toàn không phải là bảo mật, bạn có thể thuê một vài máy AWS với giá dưới 50 đô la sẽ quét toàn bộ không gian địa chỉ IPv4 trong vài giờ. Tốt hơn là chỉ chặn những kẻ phạm tội hơn là cố gắng trốn tránh chúng

3

Hồi đáp

Jon Bentley

14:58, 10/11/2022

@hardilb "phải nhớ" - điều đó có vẻ rất cụ thể cho từng trường hợp sử dụng. Tôi nghĩ rằng hầu hết mọi người không chuyển sang ứng dụng khách mới quá thường xuyên (hoặc nếu có thì việc cung cấp có thể nằm trong tầm kiểm soát của họ) và có thể chỉ cần lưu trữ cài đặt một lần rồi quên nó đi (ví dụ: sử dụng Ansible hoặc Stow nếu bạn cung cấp máy mới thường xuyên). "Bảo mật bằng cách che khuất là không có bảo mật" là một quan niệm sai lầm phổ biến. *Bản thân nó* nó không phải là bảo mật, nhưng nó là một phần hợp lệ để bảo vệ chiều sâu và có thể mang lại một số lợi ích nhẹ khi được sử dụng đúng cách.

2

Hồi đáp

Jason

00:32, 11/11/2022

@LinuxSecurityFreak re: "Có 65535 cổng, bằng cách nào đó tôi nghi ngờ các bot sẽ chiếm phạm vi như vậy" - Tôi cũng nghi ngờ điều đó, cho đến khi tôi thấy một khách hàng đã chuyển cổng sang thứ gì đó giống như 20502. Nó đã được xuất bản trên shodan.io dưới dạng một cổng mở và dịch vụ đã được xác định chính xác. Ấn tượng. Và tỉnh táo.

1

Hồi đáp

Christopher Schultz

02:37, 11/11/2022

Tôi đã được một nhà điều hành cơ sở hạ tầng khuyên rằng tôi nên thay đổi cổng sshd từ lâu và tôi nghĩ đó hoàn toàn là rác, giống như nhiều nhận xét ở đây, nhưng tôi vẫn làm. Và chúng tôi vẫn nhận được rác. Nhưng so với các máy chủ mà chúng tôi _chưa_ thay đổi, các cổng, chúng thực tế không hoạt động.Đã 15 năm trôi qua và chưa có Shodan-fu nào hướng một số lượng lớn bot vào máy chủ của chúng tôi. YMMV. Đây là *không phải* bảo mật bằng che khuất. Nó chỉ đơn thuần là tối nghĩa. Bảo mật đến từ việc sử dụng các khóa ssh mạnh để xác thực chứ không phải mật khẩu. Cũng +1 cho fail2ban :)

11

Hồi đáp

slebetman

03:32, 12/11/2022

@LinuxSecurityFreak Hãy xem câu hỏi. Bot đó đã thử trên các cổng khác nhau. Không phải cổng 22. Vì vậy, đối với OP, anh ấy đã phải đối mặt với một bot đang quét các cổng cụ thể và không cố ssh trên cổng 22

0

Hồi đáp

Pelle

09:38, 12/11/2022

Tôi sẽ không sử dụng giới hạn tốc độ mù được hiển thị, điều này giúp bạn dễ dàng thoát khỏi DoS-ed khỏi máy chủ của mình, ngay cả khi quét ngẫu nhiên.

0

Hồi đáp

John Mee

10:52, 12/11/2022

Kinh nghiệm cá nhân thực tế ở đây: thay đổi số cổng trong khi không phải là một giải pháp thực sự chắc chắn có hiệu quả để giảm rủi ro... ít nhất là trên các máy chủ nhỏ. Kết hợp với xác thực Khóa là tỷ lệ phần thưởng ít nỗ lực nhất - hai dòng đã thay đổi và khởi động lại một cách lo lắng.

0

Hồi đáp

Simon Richter

11:51, 12/11/2022

@Pelle, giới hạn tốc độ là trên mỗi IP nguồn, do đó, nó "chỉ" dễ bị tấn công từ chối dịch vụ được nhắm mục tiêu.

0

Hồi đáp

Austin Hemmelgarn

12:45, 12/11/2022

@hardillb Vâng, đó chỉ là sự tối nghĩa, nhưng sự tối nghĩa thường đủ để ngăn chặn một tỷ lệ phần trăm không cần thiết các cuộc tấn công ở đây. Trừ khi bạn đang chủ động trở thành mục tiêu, hầu hết các bot sẽ không thử bất kỳ cổng thay thế nào (nói từ hơn một thập kỷ kinh nghiệm ở đây), vì vậy, chỉ cần thay đổi cổng, ngay cả khi đó là thay đổi thành â Cổng thay thế obviousâ, đủ để cắt giảm đáng kể số lượng kẻ tấn công thực sự là mối đe dọa.

0

Hồi đáp

user

12:49, 12/11/2022

@slebetman Đó là cổng máy khách, nó không liên quan gì đến cổng máy chủ vì nếu nó đang kiểm tra các cổng khác nhau cho máy chủ, thì nó sẽ không hiển thị trong nhật ký SSH.

0

Hồi đáp

Pelle

14:29, 12/11/2022

@SimonRichter: Trong trường hợp đó, hãy tiếp tục :-)

0

Hồi đáp

canton7

16:20, 12/11/2022

Một chút kinh nghiệm cá nhân khác: fail2ban hầu như không đạt được gì trong thực tế ở đây. Tất cả quá trình quét SSH tôi nhận được là từ botnet, trong đó mỗi máy chủ từ xa chỉ thử 1 hoặc 2 lần đăng nhập, điều này không đủ để kích hoạt fail2ban (bạn cũng có thể thấy điều này trong nhật ký của OP). Vô hiệu hóa mật khẩu đăng nhập và chỉ sử dụng auth khóa công khai.

0

Hồi đáp

Điểm:9

Server

Samuel Prevost

16:21, 10/11/2022

Như @Simon Richter đã đề cập, đó chỉ là tiếng ồn xung quanh internet và bạn không nên lo lắng. Một vài điều bạn phải chắc chắn rằng:

Bạn không cho phép xác thực dựa trên mật khẩu mà chỉ cho phép xác thực khóa công khai
Bạn có thể vô hiệu hóa các mật mã không an toàn và được thiết kế kém, loại bỏ các mô đun Diffie-Hellman nhỏ và các cải tiến mật mã khác
Bạn có thể cài đặt fail2ban

Thay đổi cổng sẽ làm cho vấn đề biến mất, nhưng đó là An ninh thông qua sự tối tăm và nó có thể tạo ra ảo tưởng về sự an toàn trong khi không mang lại điều gì.

Dưới đây là một vài khuyến nghị khác xung quanh SSH, cũng như phản đối các lập luận đối với các lập luận "thực tiễn tốt nhất" chính thống.

0 + 0

Điểm:3

Server

Criggie

13:01, 11/11/2022

Bạn đang ở Ấn Độ? Tất cả những địa chỉ IP được liệt kê đều nằm trong khối:

223.196.160.0 - 223.196.191.255

mà theo cơ sở dữ liệu WHOIS được phân bổ cho

mô tả: Andhra Pradesh State FiberNet Limited
địa chỉ: 10-2-1,Tầng III, Khu phức hợp FDC,AC Guards,Hyderabad,Andhra Pradesh-500028

Một giải pháp ngắn hạn là chặn toàn bộ khối 223.196.160.0/19 tại tường lửa, nhưng đó là việc quản lý vi mô các địa chỉ IP và trở thành một cuộc chiến khó khăn.

Thay vào đó, bạn có thể từ chối TẤT CẢ ssh ngoại trừ các IP nguồn mà bạn biết là đáng tin cậy. Chỉ cần cẩn thận để không khóa bản thân khỏi máy chủ của chính bạn. Nếu bạn không có IP tĩnh, bạn có thể cho phép chặn hoặc có thể xem việc chạy máy chủ VPN trên máy chủ.

Hoặc nếu bạn không cần cho phép các kết nối SSH từ internet, chỉ cần từ chối chúng và chỉ bật lại khi được yêu cầu.

0 + 1

user10489

13:50, 11/11/2022

Hoặc sử dụng tính năng gõ cổng để tự đưa vào danh sách trắng khi IP của bạn thay đổi.

1

Hồi đáp

Điểm:1

Server

HatLess

13:48, 11/11/2022

Đây là một tập lệnh đơn giản mà tôi đã viết để chặn tất cả các nỗ lực đăng nhập trái phép vào máy chủ nhà phát triển của mình.

#!/bin/bash

ban=$HOME/banned.txt
b_log=/var/log/banned.log

nhật ký () {
mèo $cấm | uniq >> $b_log
}

l_log() {
cuối cùng | awk '{ in $3 }' | sed -r '/(Thứ Hai|Thứ Ba|Thứ Tư|Thứ Năm|Thứ Sáu|Thứ Bảy|CN|boot|tty2)/d' | sắp xếp | sed '/^$/d' | duy nhất | tee $ban
}

rơi vãi () {
cho x bằng $(cat $ban); làm iptables -A INPUT -s $x -j DROP; xong
}

l_log
rơi vãi
đăng nhập
rm -f $ban
tiếng vang > /var/log/btmp
iptables-save

Nếu bạn đặt tập lệnh chạy qua cron mỗi phút, nó sẽ giảm đáng kể tiếng ồn trong nhật ký của bạn và chặn các IP vi phạm, khiến chúng chỉ có 1 phút để thử dùng vũ lực trước khi bị chặn.

Bạn nên chèn IP của mình và bất kỳ IP nào khác mà bạn truy cập vào máy chủ của mình vào tường lửa của bạn iptables -I INPUT -s xxx.xx.xxx.xx -j CHẤP NHẬN

Nhật ký của tất cả các IP bị cấm sẽ được tạo.

0 + 3

Criggie

19:35, 11/11/2022

Vì vậy, bạn đang lấy nhật ký đầu ra của fail2ban và xóa vĩnh viễn các IP nguồn đó bằng quy tắc iptables? Tại sao không chỉ chỉnh sửa iptables để chặn các địa chỉ xấu lâu hơn? Bạn cũng có nguy cơ bị chặn các IP cục bộ của mình nếu nhập sai mật khẩu hoặc tương tự, trong khi fail2ban có các tùy chọn "không bao giờ chặn các phạm vi này".

0

Hồi đáp

HatLess

19:45, 11/11/2022

Không. Tôi không sử dụng fail2ban, chỉ iptables. Tôi đang lấy thông tin đầu vào của mình từ `lastb`, lần đăng nhập thất bại cuối cùng, sau đó chỉ trích xuất các IP và loại bỏ chúng.

1

Hồi đáp

iBug

17:02, 12/11/2022

Có vẻ như bạn đang phát minh lại fail2ban. F2B đã là một công cụ toàn diện cho nhiệm vụ này, không có lý do gì để từ chối nó.

2

Hồi đáp

Điểm:1

Server

cyqsimon

13:49, 12/11/2022

1. Thay đổi của bạn `sshd` cổng nghe

Nghe có vẻ đơn giản, thay đổi cổng của bạn từ mặc định 22 thành một giá trị tùy chỉnh (ví dụ: 2200) trên một IP công cộng có thể giảm số lần quét cổng từ hàng nghìn lần mỗi ngày xuống còn vài chục lần. Đối với một hướng dẫn xem đây.

Điều đó đang được nói, trong khi điều này làm giảm sự khó chịu khi bị quét cổng, nó KHÔNG LÀM cung cấp bảo mật thực sự. "Bảo mật bằng cách che khuất" là một huyền thoại và không có gì hơn thế.

2. Sử dụng đăng nhập khóa công khai và vô hiệu hóa đăng nhập mật khẩu

Các bot có thể đoán đúng mật khẩu, nhưng chúng chẳng bao giờ sẽ đoán đúng một khóa riêng. Miễn là bạn sử dụng các thuật toán hiện đại và không vô tình làm rò rỉ khóa của mình. Đối với một hướng dẫn xem đây.

Lưu ý rằng điều này không có nghĩa là bạn sẽ không thể đăng nhập từ bất kỳ máy ngẫu nhiên nào, trừ khi bạn mang theo chìa khóa bên mình (bạn cần bảo mật thông qua một số cách khác).

3. Sử dụng fail2ban

Nếu họ thất bại 5 lần, cấm họ thử lại trong một ngày hoặc đại loại như vậy. Điều đó sẽ cho họ thấy. Rất hiệu quả chống lại các nỗ lực vũ phu. Đối với một hướng dẫn xem đây.

Nhược điểm là bạn có thể tự nhốt mình nếu một ngày nào đó bạn bị run tay (say rượu hay gì đó, tôi không biết).

4. Cấm trước danh sách các IP được biết đến với mục đích lạm dụng

Các nguồn như Lạm dụngIPDB duy trì danh sách lớn các IP độc hại đã biết có thể truy cập qua API. Bạn sẽ cần một khóa API để sử dụng nó, nhưng bạn có thể đăng ký một tài khoản miễn phí đủ dễ dàng. Kéo danh sách và sử dụng một cái gì đó như iptables để cấm hàng loạt các IP đã biết đó. Thiết lập một công việc định kỳ để tự động hóa nó theo định kỳ để có hiệu quả tốt nhất. Đây là một kịch bản rất đơn giản tôi đã viết (và cá nhân tôi đang sử dụng) để làm điều đó. Vui lòng sử dụng nó làm tài liệu tham khảo, nhưng KHÔNG SỬ DỤNG NÓ TRONG SẢN XUẤT.

Theo kinh nghiệm cá nhân của tôi, phương pháp này cũng hiệu quả không kém (nếu không muốn nói là hơn) phương pháp #3.

Cá nhân tôi sử dụng tất cả 4 phương pháp được liệt kê ở trên và VPS của tôi có thể nhận được một hoặc hai lần thử đăng nhập độc hại vào nhật ký bảo mật của tôi trong một tháng tồi tệ. Đây là lịch sử đánh chặn của iptables thông qua phương pháp #4:

$ abip-hist
Chuỗi abip-ban (1 tài liệu tham khảo)
 pkts byte đích prot chọn không tham gia đích nguồn
  362 14480 THẢ tất cả -- * * 45.143.200.6 0.0.0.0/0
  307 12280 THẢ tất cả -- * * 185.156.73.104 0.0.0.0/0
  288 12672 THẢ tất cả -- * * 212.133.164.75 0.0.0.0/0
  277 19911 THẢ tất cả -- * * 146.88.240.4 0.0.0.0/0
  250 11000 THẢ tất cả -- * * 212.133.164.14 0.0.0.0/0
  230 9200 THẢ tất cả -- * * 45.146.164.213 0.0.0.0/0
  215 8600 THẢ tất cả -- * * 185.156.73.67 0.0.0.0/0
  214 8560 THẢ tất cả -- * * 5.188.206.18 0.0.0.0/0
  202 8080 THẢ tất cả -- * * 193.27.228.63 0.0.0.0/0
  201 8040 THẢ tất cả -- * * 193.27.228.64 0.0.0.0/0
  199 7960 THẢ tất cả -- * * 193.27.228.59 0.0.0.0/0
  197 7880 THẢ tất cả -- * * 193.27.228.65 0.0.0.0/0
  197 7880 THẢ tất cả -- * * 193.27.228.61 0.0.0.0/0
  196 7840 THẢ tất cả -- * * 45.135.232.119 0.0.0.0/0
  196 7840 THẢ tất cả -- * * 193.27.228.60 0.0.0.0/0
  196 7840 THẢ tất cả -- * * 193.27.228.58 0.0.0.0/0
  189 7560 THẢ tất cả -- * * 45.146.165.149 0.0.0.0/0
  184 7360 THẢ tất cả -- * * 45.155.205.247 0.0.0.0/0
  184 7360 THẢ tất cả -- * * 195.54.160.228 0.0.0.0/0
  182 7280 THẢ tất cả -- * * 45.143.203.12 0.0.0.0/0
  181 7240 THẢ tất cả -- * * 45.141.84.57 0.0.0.0/0
  180 7200 THẢ tất cả -- * * 45.135.232.85 0.0.0.0/0
  176 7040 THẢ tất cả -- * * 45.146.165.148 0.0.0.0/0
...
điều này diễn ra trong 1700 dòng ...

$ thời gian hoạt động
06:36:49 lên 16 ngày, 15:24

0 + 1

Z4-tier

16:56, 12/11/2022

+1 cho "thay đổi cổng của bạn". Chỉ cần không thay đổi nó thành thứ gì đó hấp dẫn không kém (hoặc hơn) đối với kẻ tấn công. Sử dụng một cổng tối nghĩa, chưa được chỉ định, được đánh số cao hơn; một cái gì đó trên 10000. Tôi đã từng chạy ssh trên 23 (cổng telnet) chỉ dành cho *ha-ha's* và wow điều đó đã nhận được rất nhiều kết nối.

0

Hồi đáp

Điểm:1

Server

user996142

00:17, 12/11/2022

Chỉ sử dụng xác thực dựa trên khóa. Nhiều bot chỉ tấn công các hệ thống dựa trên mật khẩu. Dù sao thì việc sử dụng xác thực dựa trên mật khẩu cũng là một ý tưởng tồi.
Sử dụng https://www.sshguard.net/ : nó chặn IP sau một vài lần đăng nhập không thành công.
Sử dụng cổng ngẫu nhiên (không phải 22), nó sẽ dừng một số bot.
Đảm bảo hệ thống của bạn không cho phép đăng nhập root
Nếu bạn chỉ đăng nhập từ nhà của mình, hãy xem xét chỉ mở SSH cho IP/ISP hoặc quốc gia của bạn.

0 + 0

Điểm:0

Server

lev

13:07, 12/11/2022

Như các câu trả lời khác đã đề cập, bạn không cần phải lo lắng nhiều về điều đó, nhưng nếu bạn muốn thêm một lớp bảo mật khác, bạn có thể thử sử dụng tính năng gõ cổng.

Ý tưởng là giữ cho cổng ssh luôn đóng và chỉ mở nó cho ips thực hiện một chuỗi hoạt động cụ thể trước đó, chẳng hạn như:

cổng đồng bộ 1000
cổng đồng bộ 2000
cổng đồng bộ 3000
# cổng ssh hiện đang mở
suỵt...

có thể biết thêm chi tiết tại đây: https://www.rapid7.com/blog/post/2017/10/04/how-to-secure-ssh-server-using-port-knocking-on-ubuntu-linux/

0 + 0

Phan Văn Trường

Câu hỏi này là trong các ngôn ngữ khác: