Có phải là bình thường để có được hàng trăm nỗ lực đột nhập mỗi ngày?

196

Tôi vừa kiểm tra máy chủ của mình /var/log/auth.logvà thấy rằng tôi nhận được hơn 500 thông báo lỗi mật khẩu / lần đột nhập mỗi ngày! Trang web của tôi nhỏ và URL của nó tối nghĩa. Điều này có bình thường không? Tôi có nên dùng biện pháp nào không?

linux  security  ssh  firewall 
— Kyle
nguồn
2
Cho đến khi chúng tôi khóa tất cả các cổng bên ngoài không cần thiết, tôi nhớ rằng chúng tôi không chỉ nhận được rất nhiều nỗ lực hack, mà một ngày thật tệ khi chúng tôi bị hack từ hai quốc gia khác nhau - cùng một lúc! Vì vậy, có, 100 lần thử đột nhập là hoàn toàn bình thường.
— Django Reinhardt
91
Chúng tôi có các máy chủ trải nghiệm "trình tự" tấn công mới cứ sau 16 giây. Một chuỗi đơn thường là một đợt gồm khoảng 100 lần thử trên các cổng khác nhau. Chỉ vì một ngày nào đó, tôi đã bật một máy chủ chưa được vá bên ngoài tường lửa của chúng tôi; phải mất ít hơn 10 phút kể từ khi được bật nguồn để có được pwnd. Điểm là internet thực sự là một khu rừng; cố gắng không để bị ăn
— NotMe
2
Tôi có thể thấy tôi đã đăng câu hỏi của mình lên trang web sai: superuser.com/questions/200896/ Kẻ
— Justin C
6
trong khi tôi đồng ý với những người khác thì điều này là bình thường đối với các cổng phổ biến cần thiết (80, 443) Tôi thực tế đã loại bỏ những nỗ lực này đối với cổng SSH của mình bằng cách thay đổi cổng mặc định từ 22 sang một thứ gì đó tối nghĩa như 6022 chẳng hạn. Chỉ cần làm điều đó, một mình, gần như đã loại bỏ 99% kiểu tấn công đó.
— Kilo
2
Nếu bạn định thay đổi cổng SSH, có những lý do bảo mật để giữ cổng dưới cổng 1024 (chỉ root mới có thể mở cổng <1024, vì vậy nó bảo vệ bạn khỏi những người dùng khác chiếm quyền điều khiển SSH).
— Brendan Long

Câu trả lời:

207

Trong internet ngày nay điều này là khá bình thường đáng buồn. Có rất nhiều botnet cố gắng đăng nhập vào từng máy chủ mà họ tìm thấy trong toàn bộ mạng IP. Thông thường, họ sử dụng các cuộc tấn công từ điển đơn giản vào các tài khoản nổi tiếng (như tài khoản root hoặc ứng dụng nhất định).

Các mục tiêu tấn công không được tìm thấy thông qua các mục nhập của Google hoặc DNS, nhưng những kẻ tấn công chỉ thử mọi địa chỉ IP trong một mạng con nhất định (ví dụ: các công ty lưu trữ máy chủ gốc đã biết). Vì vậy, không có vấn đề gì khi URL của bạn (do đó mục DNS) khá tối nghĩa.

Đó là lý do tại sao nó rất quan trọng đối với:

  • không cho phép root-login vào SSH ( howto )
  • sử dụng mật khẩu mạnh ở mọi nơi (cũng trong các ứng dụng web của bạn)
  • cho SSH, sử dụng xác thực khóa công khai nếu có thể và vô hiệu hóa mật khẩu auth hoàn toàn ( howto )

Ngoài ra, bạn có thể cài đặt fail2ban để quét authlog và nếu nó tìm thấy một số lần thử đăng nhập thất bại nhất định từ IP, nó sẽ tiến hành thêm IP đó vào /etc/hosts.denyhoặc iptables / netfilter để khóa kẻ tấn công trong vài phút.

Ngoài các cuộc tấn công SSH, việc quét máy chủ web của bạn để tìm các ứng dụng web dễ bị tổn thương (một số ứng dụng viết blog, CMS, phpmyadmin, v.v.) cũng trở nên phổ biến. Vì vậy, hãy đảm bảo giữ cho những người cập nhật và được cấu hình an toàn quá!

— Holger chỉ
nguồn
21
Các ứng dụng như fail2ban có thể giúp "tạm thời" ngăn chặn các bot đó tấn công máy chủ của bạn vào thời điểm ngớ ngẩn vào buổi sáng :-) Tôi đã cài đặt để cấm 3 lần thử sai trong 24 giờ.
— emtunc
46
Và di chuyển cổng của ssh từ 22 đến 222. Điều đó hoạt động khá tốt.
— Tom O'Connor
40
+1, chỉ xác thực khóa công khai :)
— 0xC0000022L
3
@STATUS_ACCESS_DENIED: các hành động fail2ban thực hiện chỉ là danh sách các lệnh shell để chạy. Vì vậy, nó thực sự linh hoạt và dễ dàng để làm việc đúng với bất kỳ cấu hình tùy chỉnh nào. Tài liệu tham khảo tốt nhất là tải về và xem xét action.d/iptables.conf.
— mattdm
4
Chặn những kẻ tấn công như thế này là một sự lãng phí thời gian. Nếu bạn vô hiệu hóa đăng nhập root, rất có thể sẽ không có ai đoán được tên đăng nhập chính xác của bạn, chứ đừng nói đến mật khẩu. Bản thân SSH đã giới hạn tỷ lệ yêu cầu mật khẩu, vì vậy ngay cả khi họ biết tên người dùng của bạn (bot ngẫu nhiên sẽ không), nếu bạn có mật khẩu tốt, họ sẽ không bao giờ đoán được.
— Brendan Long
58

Một vài 100 là ổn ... Tháng trước tôi đã tìm thấy một trong những máy chủ của mình có 40k lần thử thất bại. Tôi đã vượt qua những rắc rối của âm mưu chúng: Bản đồ

Khi tôi thay đổi cổng ssh và thực hiện Port Knocking, số lượng giảm xuống 0 :-)

— Bart De Vos
nguồn
2
Bản đồ đẹp. Tôi rất thích biết làm thế nào để làm điều này!
— jftuga
9
@jftuga Tôi đã nhận được tất cả IP từ nhật ký đầu tiên. grep 'Failed password' /var/log/secure* | grep sshd | grep -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' | sort | uniq(xóa | uniq ở cuối nếu bạn muốn cho phép trùng lặp). Sau đó, bạn có thể đặt chúng vào CSV và tải nó lên zeemaps.com. Tôi đã thấy các bản đồ tốt hơn sau đó là của tôi, nơi họ sẽ sử dụng số đếm để tô màu bản đồ (màu xanh lá cây sang màu đỏ cho số lần thử trên mỗi hạt) nhưng tôi đã không nhận ra rằng nó đã xuất hiện
— Bart De Vos
3
Bạn có ý nghĩa gì khi 'thực hiện Port Knocking'? Có ứng dụng nào tôi có thể cài đặt qua apt-get để làm việc này không? Con số giảm xuống 0 nghe có vẻ hay
18
An ninh thông qua che khuất được một bọc xấu. Nó hoàn toàn tốt miễn là nó là một phần của chiến lược tổng thể chứ không phải là toàn bộ chiến lược. Rốt cuộc, một mật khẩu nào khác ngoài một chuỗi tối nghĩa?
— Joel Coel
5
@Joel Coel, đó là một chuỗi bí mật , trái ngược với hầu hết bảo mật thông qua các vấn đề tối nghĩa - một quá trình tối nghĩa, nhưng không nhất thiết là bí mật.
— tobyodavies
29

Tôi cho một người sử dụng một "tarpit" ngoài việc chỉ cho phép xác thực khóa công khai và không cho phép đăng nhập gốc.

Trong netfilterđó có một recentmô-đun, bạn có thể sử dụng với ( INPUTchuỗi):

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

Điều đó là, mọi nỗ lực kết nối với cổng 22 đều được recentmô-đun liệt kê với IP và một số nội dung khác dưới tên "tarpit" (nếu bạn tò mò, hãy nhìn vào /proc/net/xt_recent/tarpit). Rõ ràng bạn có thể sử dụng tên khác.

Để liệt kê hoặc hủy bỏ IP sử dụng:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

Tốc độ này giới hạn các nỗ lực xuống còn 5 trong 300 giây. Xin lưu ý rằng người dùng có kết nối hiện tại không bị làm phiền bởi giới hạn đó, vì họ đã có kết nối được thiết lập và được phép tạo thêm (thậm chí vượt quá giới hạn tốc độ).

Điều chỉnh các quy tắc theo ý thích của bạn nhưng đảm bảo rằng chúng được thêm vào theo thứ tự đó (nghĩa là khi thêm thì sử dụng chúng theo thứ tự này, khi chèn sau đó theo thứ tự ngược lại).

Điều này cắt giảm tiếng ồn vô cùng. Nó cũng cung cấp bảo mật thực tế (chống lại vũ phu) không giống như bảo mật nhận thức khi thay đổi cổng. Tuy nhiên, tôi vẫn khuyên bạn nên thay đổi cổng nếu điều đó khả thi trong môi trường của bạn. Nó cũng sẽ giảm mức độ tiếng ồn rất nhiều ...

Bạn vẫn có thể kết hợp điều này với fail2ban, mặc dù tôi đã chạy tốt mà không có nó và chỉ có các quy tắc trên.

BIÊN TẬP:

Bạn có thể tự khóa mình bằng cách này, vì vậy bạn có thể thêm một cái gì đó như sau cho phép bạn xóa lệnh cấm bằng cách gõ vào một cổng cụ thể:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove
— 0xC0000022L
nguồn
2
Tôi sử dụng điều này và thỉnh thoảng tự chặn mình, vì vậy muốn thiết lập một cổng khác để bạn có thể "gõ" để xóa lệnh cấm của mình.
— benlumley
@benlumley: điểm tốt. Việc gõ cổng có thể hữu ích tương tự với việc thay đổi cổng mặc định - hoặc thậm chí cả hai kết hợp cả hai ...
— 0xC0000022L
@benlumley: thấy bình luận của bạn (hiện đã bị Sam xóa). Tôi hoàn toàn không phiền nếu câu trả lời được chỉnh sửa / cải thiện;)
— 0xC0000022L
15

Bạn có thể triển khai fail2ban hoặc các phương thức tương tự như khóa SSH vào IP của bạn. Đáng buồn là các bot cố gắng truy cập bruteforce mọi lúc nên nó khá bình thường, bạn cần đảm bảo rằng bạn có một mật khẩu tốt.

— Gia-cốp
nguồn
3
Nếu bạn đang sử dụng SSH, hãy xem xét xác thực khóa công khai. Điều này an toàn hơn một chút so với xác thực mật khẩu.
— Piskvor
12

Có . Ngày nay nó khá bình thường.

Vui lòng chỉ sử dụng xác thực khóa công khai cho mục đích quản trị nếu có thể. Tạo khóa riêng trên máy trạm của bạn:

$ ssh-keygen -t dsa

Sao chép nội dung của ~ / .ssh / id_dsa.pub cho máy chủ của bạn ~ / .ssh / ủy quyền_key (và /root/.ssh/authorized_keys, nếu bạn yêu cầu đăng nhập root trực tiếp).

Định cấu hình máy chủ của bạn / etc / ssh / sshd_config để chỉ chấp nhận xác thực khóa chung:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

Nếu bạn có quá nhiều máy chủ, bạn có thể sử dụng Puppet để chạy các khóa công khai và cấu hình cho chúng.

Nhìn vào Denyhosts và fail2ban để chặn các lần đăng nhập SSH lặp đi lặp lại và xem Snort nếu bạn yêu cầu IDS / IPS đầy đủ.

— jkj
nguồn
2
Tôi không khuyên bạn nên sử dụng xác thực khóa chung trong SSH để truy cập shell vào máy chủ của bạn. Nếu máy trạm của bạn bị xâm phạm hoặc thậm chí tệ hơn là bị đánh cắp, thì giờ đây ai đó đã có quyền truy cập mở vào máy chủ của bạn mà không cần mật khẩu. Xác thực khóa công khai dành cho các tình huống bạn cần một cái gì đó như tập lệnh hoặc chương trình để có thể truy cập SSH vào hệ thống khác mà không cần mật khẩu để bạn không phải nhúng mật khẩu văn bản đơn giản vào tập lệnh / chương trình.
— Người dùng đã đăng ký
5
Tài khoản @ đã xóa: Bạn có thể đặt cụm mật khẩu cho khóa riêng SSH.
— Phil Cohen
2
Nhận xét "Người dùng đã đăng ký" bị nhầm lẫn. Chỉ cần làm rõ: Luôn đặt mật khẩu tốt trên khóa riêng của bạn và không lưu trữ khóa riêng trên bất kỳ máy chủ nào. Giữ khóa riêng trên máy trạm của riêng bạn. Khi bạn thêm khóa vào chương trình ssh-agent và nhập mật khẩu của mình, bạn có thể đăng nhập vào mọi hệ thống đã cài đặt khóa chung mà không cần phải nhập lại mật khẩu. Cho phép chuyển tiếp tác nhân trong máy khách ssh của bạn để bạn có thể đăng nhập từ máy chủ này sang máy chủ khác. Lấy khóa riêng của bạn bị đánh cắp là xấu, nhưng với một mật khẩu đàng hoàng trên đó, nó không tệ như mật khẩu bị đánh cắp.
— Martijn Heemels
Đúng, thậm chí không nghĩ để lưu trữ khóa riêng của quản trị viên không được mã hóa.
— yrk
6

Tôi chỉ nói rằng chỉ nhận được 500 là loại thấp.

Tại một chủ nhân trước đây, một trong những nhà nghiên cứu bảo mật máy tính đã gọi dòng đột phá liên tục là "internet tương đương với tiếng ồn vũ trụ ". Ông mô tả nó như một luồng lưu lượng độc hại liên tục, bình thường đang tìm kiếm các hệ thống trên internet và tự động khai thác các tập lệnh để cố gắng chiếm quyền điều khiển hệ thống. Bot-net và các hệ thống độc hại khác sẽ liên tục quét và quét lại internet cho các hệ thống dễ bị tổn thương giống như SETI.

— James Schek
nguồn
6

Đúng,

Điều này là phổ biến, nhưng điều đó không có nghĩa là bạn không nên chiến đấu với cuộc chiến tốt. Dưới đây là một số bước về cách bạn có thể làm cho máy chủ của mình an toàn hơn.

Tránh các địa chỉ IP liên quan đến DNS

Bạn có thể giảm đáng kể số này trong môi trường chia sẻ hoặc colocation bằng cách vô hiệu hóa quyền truy cập SSH trên bất kỳ địa chỉ IP nào được liên kết với tên miền. Các địa chỉ IP không thuộc miền không được liệt kê sẽ nhận được ít lưu lượng truy cập loại này, vì vậy hãy mua IP chưa niêm yết và chỉ sử dụng IP này để truy cập SSH.

Sử dụng VPN cho tất cả quyền truy cập SSH

Nếu bạn đang ở trong một môi trường mà bạn có thể triển khai IPsec / VPN đến một mạng riêng trong môi trường máy chủ của mình, thì điều này là lý tưởng. Vô hiệu hóa tất cả truy cập Internet SSH, đảm bảo bạn có giải pháp tắt đèn tích hợp. Thiết lập VPN của bạn và chỉ cho phép truy cập SSH từ VPN của bạn.

Thực hiện quy tắc địa chỉ IP để truy cập SSH

Nếu Vlan không phải là một tùy chọn cấu hình bộ định tuyến của bạn hoặc quy tắc tường lửa để chỉ cho phép kết nối SSH từ một dải địa chỉ IP đã biết.

Nếu bạn làm theo các bước này, bạn sẽ ngủ dễ dàng hơn nhiều vào ban đêm khi biết ai đó sẽ phải thỏa hiệp mạng công ty lưu trữ của bạn để có quyền truy cập vào máy chủ thông qua SSH.

— Ben DeMott
nguồn
5

Khá bình thường khi thấy hàng trăm kết nối SSH bị lỗi.

Nếu bạn có tùy chọn, tôi chỉ cần thay đổi cổng SSH của mình thành một cái gì đó không chuẩn. Nó không nhất thiết làm cho máy chủ của bạn an toàn hơn nữa, nhưng nó chắc chắn sẽ dọn sạch các bản ghi (và cho phép bạn thấy bất kỳ ai cố tình xâm nhập!)

— Adrian Macneil
nguồn
5

Ngoài việc sử dụng cơ chế khóa tự động như fail2ban, bạn còn có một tùy chọn khác: thực sự liên hệ với địa chỉ lạm dụng ISP của kẻ tấn công. Nó có vẻ hoàn toàn vô ích nhưng trong trường hợp kịch bản-kiddie, ISP của họ không sẵn sàng hành động với họ.

Để tìm địa chỉ lạm dụng, hãy bắt đầu với arin.net và tra cứu địa chỉ IP bằng whois. Bạn có thể được chuyển hướng đến một cơ quan đăng ký khu vực khác nhưng cuối cùng bạn có thể tìm thấy ISP chịu trách nhiệm cho khối IP có chứa địa chỉ. Tìm địa chỉ lạm dụng @ hoặc chỉ cần gửi thư liên hệ kỹ thuật.

Gửi cho họ một tin nhắn lịch sự với các mục nhập tệp nhật ký có liên quan (đảm bảo xóa mọi thông tin cá nhân) và yêu cầu họ thực hiện hành động chống lại máy chủ vi phạm.

— JR
nguồn
4
Chúng tôi đã từng làm điều này. Tuy nhiên, lượng thời gian dành cho lợi ích nhận được rất ít không thành vấn đề.
— NotMe
1
Một biến thể của chiến thuật này hiệu quả hơn, nhưng rủi ro hơn nhiều, là báo cáo ISP cho nút trung gian. Nhưng bạn PHẢI có bằng chứng báo cáo của bạn vững chắc. Tôi đã có một ISP toàn bộ gặp rắc rối nghiêm trọng khi làm điều này, bởi vì họ đã bỏ qua các báo cáo lạm dụng của họ.
— staticsan
1
Một lần tôi làm điều này, tin nhắn lạm dụng đã đến tay hacker thay vì ai đó phụ trách các máy chủ. Kể từ đó, tôi không làm phiền nữa, chỉ là quá nhiều rắc rối.
— wump
Điều này thực sự sẽ không giúp ích trong hầu hết các trường hợp và có thể tốn thời gian
— RichVel
4

Tôi khuyên bạn không nên sử dụng fail2ban mà chạy SSH (và những người khác) trên một cổng không chuẩn. Tôi không tin vào bảo mật bằng cách che khuất nhưng tôi nghĩ rằng đây là một cách tuyệt vời để giảm tiếng ồn trong nhật ký của bạn.

Đăng nhập thất bại trên các cổng không chuẩn sẽ có rất ít và xa và cũng có thể chỉ ra các cuộc tấn công được nhắm mục tiêu nhiều hơn.

Bạn thậm chí có thể tiến thêm một bước để cài đặt một honeypot SSH như Kippo để 'cho phép' các bệnh ung thư và xem họ sẽ làm gì khi có cơ hội.

— Andy Smith
nguồn
Haha, Kippo trông rất đẹp Tôi sẽ cài đặt nó trên một máy chủ chỉ để xem những gì họ đang cố gắng làm.
— wump
4

Vâng, đó là bình thường. Những gì tôi nói với khách hàng trong tình huống của bạn với các trang web nhỏ.

Luôn luôn sẵn sàng để bị hack.

Có một bản sao của trang web của bạn trên một máy chủ dev. Đây có thể là máy tính để bàn Windows của bạn bằng XAMPP mà bạn có thể nhận miễn phí.

LUÔN LUÔN thay đổi máy chủ dev của bạn sau đó tải chúng lên trang web trực tiếp của bạn. Nếu đó là một CMS như Wordpress, hãy tạo bài đăng của bạn trên máy chủ dev sau đó sao chép và dán chúng vào máy chủ trực tiếp.

KHÔNG BAO GIỜ tải xuống bất cứ thứ gì từ trang web trực tiếp của bạn đến máy chủ dev của bạn.

Theo dõi các trang web của bạn thường xuyên để biết bất kỳ thay đổi nào bạn không làm. Cụ thể, các liên kết ẩn với thuốc hoặc các sản phẩm 'tăng cường'. Bạn có thể tìm thấy rất nhiều trình duyệt và các chương trình sẽ làm điều này cho bạn.

Nếu bạn bị xâm phạm. Thông báo cho máy chủ của bạn, xóa mọi thứ, thay đổi tất cả mật khẩu và tải lên máy chủ dev sạch của bạn lên máy chủ web hiện đang trống. Làm việc với chủ nhà của bạn để ngăn ngừa tái phát.

Bạn không cần một nhóm bảo mật cho một trang web nhỏ. Đó là những gì chủ nhà của bạn có nghĩa vụ phải cung cấp. Nếu không, hãy lấy một máy chủ khác dễ thực hiện hơn khi bạn có máy chủ dev thay vì cố gắng di chuyển máy chủ trực tiếp.

Hi vọng điêu nay co ich.

— J Litten
nguồn
2
+1 cho "Luôn luôn sẵn sàng để bị hack."
— user78940
3

Một cách khác để ngăn chặn nó (vì cá nhân tôi không muốn di chuyển cổng SSH): quyết định xem bạn có thể liệt kê tất cả các mạng mà bạn muốn đăng nhập hay không, sau đó chỉ cho phép những mạng này truy cập vào cổng SSH của bạn.

Các mục WHOIS của các ISP địa phương đã giúp tôi giảm các cuộc tấn công xuống còn 1-2 lần đăng nhập mỗi tháng (hồi đó là khoảng 1k / ngày). Tôi đã phát hiện ra những người bằng cách vẫn sử dụng denyhosts .

— tuần trăng mật
nguồn
3

Ngoài các đề xuất tuyệt vời khác mà bạn đã nhận được, tôi cũng muốn sử dụng chỉ thị AllowUsers nếu phù hợp với máy chủ nhất định. Điều này chỉ cho phép người dùng được chỉ định đăng nhập qua SSH, giúp giảm đáng kể khả năng truy cập thông qua tài khoản khách / dịch vụ / hệ thống được định cấu hình không an toàn.

Thí dụ:

AllowUsers admin jsmith jdoe

Tùy chọn AllowUsers chỉ định và kiểm soát những người dùng nào có thể truy cập dịch vụ ssh. Nhiều người dùng có thể được chỉ định, cách nhau bởi khoảng trắng.

— Jay
nguồn
3

Vâng, đó là bình thường. Bạn có thể :

  • Giảm cơ hội tấn công bằng cách sử dụng fwknop

Fwknop là một trong những triển khai gõ cổng tốt hơn bởi vì nó không thể giả mạo và thực sự xác thực trái ngược với việc chỉ cho phép kết nối.

Điều này sẽ bảo vệ các cuộc tấn công dựa trên mật khẩu và khả năng kẻ tấn công được xác định / tấn công nhắm mục tiêu xâm phạm máy quản trị của bạn và đánh cắp tổ hợp ssh-key & password của bạn.

Chỉ cần nhìn vào comp pwn2own mới nhất để thấy kẻ tấn công lành nghề dễ dàng thỏa hiệp hộp quản trị được vá hoàn toàn của bạn dễ dàng như thế nào.

— Khách sạn
nguồn
1

Đáng buồn là điều này là khá bình thường. Bạn nên xem xét việc thêm một cái gì đó như fail2ban vào hệ thống của bạn để tự động phát hiện và cấm những kẻ tấn công. Nếu bạn chưa làm như vậy, bạn cũng nên xem xét chỉ sử dụng ssh với khóa chung và không cho phép đăng nhập root qua ssh. Nếu sử dụng ftp để truyền tệp vào hệ thống, hãy xem xét sử dụng scp / sftp thay thế.

— người dùng619714
nguồn
1

Tôi đã thực hiện gõ cổng, và có một vài thăm dò mỗi ngày. Họ không nhận được kết nối, vì vậy họ đi. Tôi đăng nhập và báo cáo tất cả các truy cập vào các cổng liên quan.

Tôi cũng đã chạy fail2ban với Shorewall như một tường lửa để tạm thời liệt vào danh sách đen những kẻ tấn công liên tục.

Nếu bạn không cần truy cập Internet để SSH vô hiệu hóa nó. Nếu bạn có một vài địa chỉ đã biết cần truy cập từ xa, hãy giới hạn quyền truy cập vào các địa chỉ đó.

Hạn chế quyền truy cập vào các khóa được ủy quyền cũng có thể hữu ích.

— BillThor
nguồn
0

Tôi sử dụng pam_ablđể tạm thời danh sách đen ung thư vũ phu, và nó hoạt động rất tốt. Tôi nghĩ sẽ tốt hơn khi có ủy quyền trong PAM bằng cơ sở dữ liệu riêng của mình thay vì phụ thuộc vào hosts.denyhoặc iptables.

Một điểm cộng nữa là pam_ablkhông phụ thuộc vào việc quét các tệp nhật ký.

— Christoffer Hammarström
nguồn
0

Nó hoàn toàn bình thường những ngày này.
Bạn có thể thiết lập giới hạn "nổ" trên tường lửa cho các kết nối mới đến trên cổng SSH
hoặc cài đặt một trong nhiều trình phân tích cú pháp nhật ký a'la fail2ban hoặc thay đổi cổng SSH;).

Cái cuối cùng là cái dễ nhất. Trên các máy tải nặng, những nỗ lực đột nhập như vậy có thể ảnh hưởng thực sự xấu đến toàn bộ hệ thống.

-
Trân trọng,
Robert

— Robert
nguồn
0

Vâng, đó là bình thường.

Tôi vừa thay đổi cổng ssh khỏi tiêu chuẩn 22. Máy chủ của tôi, quy tắc của tôi :) chỉ cần chỉnh sửa / etc / ssh / sshd_config, thay đổi cổng và khởi động lại dịch vụ. Mặt trái duy nhất là bạn phải nhớ thêm cổng đó vào cấu hình cho mọi máy khách ssh bạn sử dụng.

— John
nguồn
0

  • Vô hiệu hóa đăng nhập root (Trong mọi người dùng root hệ thống linux tồn tại để bot có thể dễ dàng đoán tên người dùng). Sau khi đăng nhập như người dùng bình thường, bạn có thể chuyển sang root bằng su hoặc sudo.

  • thay đổi cổng mặc định từ 22

  • Chỉ cho phép truy cập ssh từ ip đã biết

  • Sử dụng mật khẩu alpha-số mạnh cho người dùng có quyền truy cập ssh

— Kevin Parker
nguồn
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 cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.