Những ưu / nhược điểm của các phương pháp khác nhau để chặn các cuộc tấn công SSH vũ phu là gì?

Có một số gói khác nhau hiện có để tắt IP từ đó các cuộc tấn công SSH mạnh mẽ được khởi chạy trên hệ thống của bạn. Ví dụ:

Những ưu / nhược điểm của những điều này, hoặc bất kỳ khác là gì?

Giải pháp hiện tại của tôi là lấy email mà logwatch tạo ra mỗi ngày và kết xuất các địa chỉ IP quá lớn vào một tệp văn bản mà tôi đưa vào một tập lệnh để xây dựng lại iptables. Đó là hacky, tốn thời gian và thủ công, và tôi muốn một cách tốt hơn.

(Lưu ý rằng tôi đã không hỏi cách "tốt nhất" để giải quyết vấn đề là gì, bởi vì không có cách "tốt nhất" để làm bất cứ điều gì.)

ssh security

— Andy Lester
nguồn

Câu trả lời:

Tôi sử dụng Denyhost, vì vậy ít nhất tôi có thể trả lời cho điều đó:

Ưu

Nó hoàn toàn tự động
Nó có thể định cấu hình (có bao nhiêu lần thất bại trước khi đưa vào danh sách đen, đối với tên người dùng không tồn tại, tên người dùng tồn tại và mục nhập đặc biệt cho root)
Nó có thể gửi email cho bạn với một danh sách các máy chủ mới được đưa vào danh sách đen theo định kỳ và / hoặc chạy một chương trình nhất định mỗi khi một máy chủ mới được đưa vào danh sách đen
Nó hỗ trợ các máy chủ tự động hủy danh sách đen sau một thời gian

Nhược điểm

Tôi không có bất kỳ khuyết điểm nào không thể khắc phục, miễn là bạn sử dụng đúng cách:

Trong cấu hình mặc định, nó sẽ không cảnh báo bạn đến các máy chủ mới được liệt kê trong danh sách đen, vì vậy nếu ai đó đang tấn công mạng của bạn từ hàng trăm địa chỉ khác nhau, bạn có thể không nhận thấy ngay lập tức nếu bạn theo dõi nhật ký của mình theo cách thủ công, nhưng (như đã đề cập trong phần ưu điểm) nó có thể gửi email cho bạn hoặc chạy một tệp thực thi để thông báo cho bạn khi máy chủ mới được thêm vào
Theo mặc định, nó sẽ đưa vào danh sách đen các máy chủ của bạn giống như bất kỳ máy chủ nào khác, vì vậy bạn có thể muốn thêm chúng vào /etc/hosts.allow. Tôi đã tự khóa mình khi thất bại trong việc gõ mật khẩu và một khi ai đó trong công việc cố gắng đăng nhập vào tài khoản root của tôi như một trò đùa và đưa vào danh sách đen IP công việc của tôi, và tôi phải mất vài ngày để tìm ra lý do tại sao tôi đột nhiên không thể kết nối vào mạng của tôi từ công việc nữa

— Michael Mrozek
nguồn

Một cái khác là fail2ban , dựa trên iptables (vì vậy nó hoạt động với bất kỳ dịch vụ nào, không chỉ ssh). Với fail2ban, bạn có thể:

Chỉ định đường dẫn đến bất kỳ tệp nhật ký nào (apache, ssh, nginx, mail server, ...).
Chỉ định regex cho các mẫu tấn công (ví dụ: hơn 10 "lỗi 404" bởi cùng một ip trên nhật ký truy cập nginx trong 6 giây)
Chỉ định regex để bỏ qua các mẫu nhất định (rất hữu ích!)
Chỉ định thời gian cấm
Gửi email (hoặc bất kỳ cảnh báo nào khác ...)
Hoàn toàn tùy biến (bạn có thể viết cảnh báo và bộ lọc của riêng bạn)

Một "nhược điểm" của Denyhosts là nó yêu cầu trình bao bọc tcp, do đó, nó sẽ chỉ hoạt động với các dịch vụ xem tệp /etc/hosts.deny. Nhưng để công bằng với Denyhost, sshd được biên dịch để sử dụng TCP Wrappers trên hầu hết các bản phân phối Linux. Tôi cũng thấy Denyhost dễ dàng cấu hình ra khỏi hộp hơn fail2ban (nhưng kém mạnh mẽ hơn).

Tham chiếu đến một câu hỏi SF tương tự

— Barthelemy
nguồn

fail2ban, may mắn thay, cũng hoạt động với pf - không chỉ iptables

— Người tốt

Một cách đơn giản và trong thực tế bảo vệ hiệu quả chống lại các cuộc tấn công dựa trên quét là không sử dụng cổng tiêu chuẩn. 443 (cổng https) đưa bạn đến các cuộc tấn công vũ phu khác nhau sẽ không bẻ khóa mật khẩu yếu của bạn và có thể hoạt động thông qua nhiều tường lửa hơn cổng mặc định (22).

Hầu hết các phương pháp để ngăn chặn các cuộc tấn công vũ phu ssh là những cách tuyệt vời để tự làm DoS (rất tiếc, tôi đã làm hỏng cấu hình! Rất tiếc, tôi đã thực hiện một loạt các rsync nhanh chóng và hiện bị cấm trong ngày!) Hoặc tự hỗ trợ (Oops , kẻ tấn công đến từ / đã phá hỏng một máy trong cùng mạng con với tôi (dải IP động, mạng đại học ...) và tôi cũng bị cấm!).

Nếu bạn chỉ đăng nhập từ một vài nơi, bạn chỉ có thể liệt kê các địa chỉ IP nguồn. Điều đó rõ ràng là không tốt nếu bạn muốn ssh từ máy tính xách tay hoặc điện thoại di động của bạn khi đang di chuyển.

Có một daemon ssh chỉ nghe các kết nối IPv6 sẽ bảo vệ bạn khỏi các bản quét trong một vài năm. Nhưng nhiều tường lửa sẽ không cho phép bạn vận chuyển IPv6 theo bất kỳ cách hợp lý nào.

Một phương pháp khác bạn không đề cập đến là gõ cổng . Nó không gặp phải vấn đề tự làm (không phải là cấu hình sai), nhưng nó không vượt qua tường lửa tốt và có thể thêm độ trễ vài giây cho thiết lập kết nối.

Nếu bạn có mật khẩu tốt, hoặc bạn có thể sống mà không cần xác thực mật khẩu, hãy tắt xác thực mật khẩu. (Khóa và mật khẩu một lần là đủ cho hầu hết các trường hợp sử dụng: nếu bạn không tin tưởng máy khách đủ để lưu trữ khóa ssh, bạn cũng không tin rằng nó không có keylogger). Sau đó, các cuộc tấn công vũ phu sẽ tiêu tốn của bạn một chút CPU và băng thông nhưng không khiến bạn bị xâm nhập (miễn là bạn đã kiểm tra không có khóa nào của bạn đến từ OpenSSL entropy thấp của Debian ).

Nói chung, lưu ý rằng việc thay đổi cổng không làm giảm đáng kể mức độ phơi sáng của bạn. Bạn sẽ ít quét hơn , nhưng tất cả những gì bạn có thể cắt bỏ là trái cây treo thấp tìm cách khai thác các lỗ hổng cũ và mật khẩu yếu. Miễn là bạn luôn cập nhật trình nền của mình và thực thi các mật khẩu hợp lý hoặc giới hạn tỷ lệ thử hợp lý, việc chuyển đổi cổng là một trách nhiệm hơn là một biện pháp bảo mật.

— Gilles 'SO- ngừng là ác'
nguồn

Tôi đồng ý rằng cần có một số thực tiễn để không cấm chính mình ;-) Thay đổi cổng mặc định và không dựa vào mật khẩu nhưng dựa vào khóa được bảo vệ bằng mật khẩu cũng là lời khuyên tốt. Nhưng tôi thực sự không biết tại sao tôi nên để các mạng bot lấp đầy các tệp nhật ký truy cập của mình trong khi ssh và máy chủ web của tôi phải từ chối hàng ngàn yêu cầu mỗi giờ. Với fail2ban, nhật ký truy cập của tôi sạch sẽ và các ứng dụng máy chủ của tôi hoàn toàn không thấy lưu lượng truy cập này (ngoại trừ các yêu cầu xấu X đầu tiên :-)).

— Barthelemy

Sử dụng một cổng không chuẩn không bổ sung nhiều sự bảo vệ. Quét SSH trên một cổng không chuẩn chỉ mất vài phút sau đó quét SSH trên cổng 22 (Giả sử rằng trình bẻ khóa thực hiện quét và quét không bị chặn bởi IDS. Nhưng nếu bạn có IDS, thì việc ẩn giấu cổng có thể không cần thiết ). Nếu tôi là một kẻ bẻ khóa và tôi tìm thấy SSH trên một cổng không chuẩn, tôi thậm chí sẽ quan tâm nhiều hơn bởi vì tôi biết quản trị viên nghĩ rằng dịch vụ này đủ quý giá để che giấu và dựa vào bảo mật bằng cách che khuất.

— Stefan Lasiewski

@Stefan: Hầu hết các cuộc tấn công không nhằm vào một máy chủ nhất định mà chống lại một dịch vụ nhất định. Vì vậy, việc quét một cổng trên nhiều địa chỉ sẽ hiệu quả hơn nhiều cổng trên mỗi địa chỉ. Và nếu bạn thực sự có một kẻ tấn công nhắm mục tiêu vào bạn, bạn sẽ biết rõ hơn, vì vậy bạn sẽ muốn mật khẩu mạnh hoặc bị cấm và các cuộc tấn công được ghi lại.

— Gilles 'SO- ngừng trở thành ác quỷ'

@Stefan Tôi thấy các cổng không chuẩn là một giải pháp hiệu quả cho sự phiền toái (quét brute-force) và không thực sự là một biện pháp bảo mật (nghĩa là ngăn người khác kiểm soát máy chủ của tôi).

— Barthelemy

@sudown Chỉ định một cổng khác hầu như không gây phiền toái. Nó chỉ là một dòng trong .ssh/config. Khóa là một vấn đề nếu tường lửa không cho phép bạn vượt qua, và giải pháp đơn giản nhất là bám vào cổng 22 và cũng lắng nghe trên 443. Tôi đồng ý rằng việc chuyển đổi cổng không thực sự cải thiện bảo mật, có lẽ tôi nên làm rõ hơn . Tôi không biết lý do tại sao bạn không thể hỗ trợ xác thực SSH không hỗ trợ xác thực mật khẩu: đó chỉ là vấn đề thêm một dòng vào sshd_configOpenSSH, cách triển khai phổ biến nhất.

— Gilles 'SO- ngừng trở nên xấu xa'