Các cuộc tấn công SSH tiêu tốn 4GB trong 10 giờ. Khả thi?


10

Tôi đã được cảnh báo rằng máy chủ của tôi đã phá vỡ giới hạn chuyển tiền. Tôi tin rằng nút Tor của tôi đã trở nên phổ biến vì vậy tôi đã chọn vô hiệu hóa nó trong tháng này (không phải là lựa chọn tốt nhất cho cộng đồng nhưng tôi cần phải đi xuống). Sau đó, tôi nhận thấy rằng máy chủ đã chuyển khoảng 4GB trong đêm nay. Tôi đã kiểm tra nhật ký Apache bằng Awstats, không có lưu lượng liên quan (và tôi không lưu trữ các trang web phổ biến ở đó). Tôi đã kiểm tra nhật ký thư, không ai cố gửi rác. Tôi đã kiểm tra messagesnhật ký và tìm thấy hàng tấn

Apr 29 10:17:53 marcus sshd[9281]: Did not receive identification string from 85.170.189.156
Apr 29 10:18:07 marcus sshd[9283]: Did not receive identification string from 86.208.123.132
Apr 29 10:18:24 marcus sshd[9298]: Did not receive identification string from 85.170.189.156
Apr 29 10:18:39 marcus sshd[9303]: Did not receive identification string from 86.208.123.132
Apr 29 10:18:56 marcus sshd[9306]: Did not receive identification string from 85.170.189.156
Apr 29 10:19:11 marcus sshd[9309]: Did not receive identification string from 86.208.123.132
Apr 29 10:19:18 marcus sshd[9312]: Did not receive identification string from 101.98.178.92
Apr 29 10:19:27 marcus sshd[9314]: Did not receive identification string from 85.170.189.156
Apr 29 10:19:41 marcus sshd[9317]: Did not receive identification string from 86.208.123.132
Apr 29 10:20:01 marcus sshd[9321]: Did not receive identification string from 85.170.189.156
Apr 29 10:20:13 marcus sshd[9324]: Did not receive identification string from 86.208.123.132
Apr 29 10:20:32 marcus sshd[9327]: Did not receive identification string from 85.170.189.156
Apr 29 10:20:48 marcus sshd[9331]: Did not receive identification string from 86.208.123.132
Apr 29 10:21:07 marcus sshd[9336]: Did not receive identification string from 85.170.189.156
Apr 29 10:21:20 marcus sshd[9338]: Did not receive identification string from 86.208.123.132
Apr 29 10:21:35 marcus sshd[9341]: Did not receive identification string from 85.170.189.156
Apr 29 10:21:51 marcus sshd[9344]: Did not receive identification string from 86.208.123.132
Apr 29 10:22:06 marcus sshd[9349]: Did not receive identification string from 85.170.189.156
Apr 29 10:22:23 marcus sshd[9353]: Did not receive identification string from 86.208.123.132
Apr 29 10:22:39 marcus sshd[9359]: Did not receive identification string from 85.170.189.156
Apr 29 10:22:54 marcus sshd[9361]: Did not receive identification string from 86.208.123.132
Apr 29 10:23:10 marcus sshd[9367]: Did not receive identification string from 85.170.189.156
Apr 29 10:23:29 marcus sshd[9369]: Did not receive identification string from 86.208.123.132
Apr 29 10:23:45 marcus sshd[9375]: Did not receive identification string from 85.170.189.156
Apr 29 10:24:10 marcus sshd[9387]: Did not receive identification string from 86.208.123.132
Apr 29 10:24:16 marcus sshd[9388]: Did not receive identification string from 85.170.189.156

Cứ sau vài giây, một bot lại cố gắng hack SSH của tôi, điều này là không thể vì tôi yêu cầu xác thực pubkey. Câu hỏi của tôi là: lưu lượng truy cập này, ở tần số này, có thể tiêu tốn 4GB (giả sử là 3,5) trong 10 giờ tấn công liên tục không?

Tôi đã thay đổi cổng SSH và dừng các cuộc tấn công này, nhưng tôi không chắc về mức tiêu thụ mạng của mình. Tôi không có các dịch vụ ngoài tầm kiểm soát - tường lửa của tôi khá hạn chế - hoặc chia sẻ máy chủ với ai đó lạm dụng P2P hoặc bất cứ điều gì. Mối quan tâm của tôi là đi dưới 400GB / tháng.

Bất cứ lời khuyên?

Câu trả lời:


16

4 GB là có thể, nhưng rất khó có thể xem xét tỷ lệ tấn công. Tôi khuyên bạn nên cài đặt OSSEC, nó sẽ phát hiện các lần thử và tự động chặn IP trong một thời gian nhất định.


1
Tôi đã có fail2ban, nó đã chặn thành công các thông tin đăng nhập xấu nhưng dường như bỏ qua các thông báo này. Có lẽ tôi sẽ điều chỉnh nó lên.
usr-local-ΕΨΗΕΛΩΝ

1
Đã được chấp nhận. Fail2ban cần một số điều chỉnh để chấp nhận rằng các thông điệp tường trình là các nỗ lực đột nhập. +1 cho @lain cũng vì tôi không thể chấp nhận 2 câu trả lời
usr-local-ΕΨΗΕΛΩΝ

@djechelon: Xin vui lòng cho chúng tôi biết điều này không giải quyết được vấn đề. Bằng cách nào đó tôi nghi ngờ rằng nó sẽ như các gói bị bỏ sau khi đến hệ thống của bạn.
dùng9517

@ Tôi hầu hết những kẻ tấn công bỏ cuộc khi chúng bị rơi.
Lucas Kauffman

3
@LucasKaufman: 4Gb / 10 giờ là ~ 120Kb / giây. Tôi không thấy có nhiều thông lượng từ các lần thử thất bại và đoạn trích ở trên cho thấy tỷ lệ tấn công thấp hơn nhiều (26 trong ~ 7 phút).
dùng9517

14

Nếu đây là nguyên nhân của việc sử dụng băng thông thì băng thông đã bị tiêu tốn theo thời gian bạn xử lý chúng trên hệ thống của bạn. Bạn có thể sử dụng một công cụ như iptraf để phân tích những gì đang xảy ra trên mỗi giao diện / cổng và sau đó bạn có thể thực hiện hành động thích hợp dựa trên thực tế.


Rõ ràng tôi có thể nỗ lực ngăn chặn việc tiêu thụ băng thông trong tương lai, bắt đầu từ tháng sắp tới
usr-local-ΕΨΗΕΛΩΝ

1
Và ... câu trả lời rất hữu ích, nhưng iptraf không hoạt động với OpenVZ (tham khảo webhostingtalk.com/showthread.php?t=924814 ) và tôi đã không đề cập đến nó :)
usr-local-ΕΨΗΕΛΩΝ

Ý tưởng cơ bản vẫn như cũ. Tìm một cái gì đó sẽ cho bạn biết nơi sử dụng và sau đó giải quyết vấn đề. Bất cứ điều gì khác là phỏng đoán.
dùng9517

4

Không, những nỗ lực kết nối mỗi giây một lần này sẽ không tăng thêm 4GB trong mười giờ. Bạn có nghĩ rằng bạn có thể tải xuống một tệp 4GB trong 10 giờ bằng cách nhận một gói nhỏ mỗi giây một lần không? Có 3600 giây trong một giờ, vì vậy nếu bạn nhận được một kilobyte một giây trong mười giờ, đó sẽ là 36000 Kb, hoặc 36 megabyte.

Băng thông của bạn được đo theo những gì đi xuống từ nhà cung cấp đến bộ định tuyến bên ngoài của bạn, chứ không phải những gì đến máy chủ của bạn. Bạn phải nhìn vào những thứ nhảm nhí không đến được máy chủ của bạn, rằng hầu hết các thiết bị bên ngoài đang từ chối.

Theo như những gì đến máy chủ của bạn, bạn không thể dựa vào nhật ký ứng dụng. Ngay cả các gói được âm thầm loại bỏ bởi tường lửa cục bộ là băng thông. Thống kê giao diện (hiển thị bởi ifconfig) sẽ cho bạn biết các byte Tx / Rx.


Không chắc. Theo quan điểm của tôi, các thông điệp tường trình cho thấy khách hàng đã mở một ổ cắm đến cổng 22 nhưng bị từ chối vì "những gì họ truyền" không được công nhận là bắt tay SSH đúng cách. Tôi không muốn nghe lén cổng 22 để xem trọng tải thực tế mà các máy quét đã gửi, nhưng trên lý thuyết họ có thể gửi hàng tấn rác cho đến khi SSH giảm. Câu hỏi là: khi nào openSSH giảm một cái bắt tay không hợp lệ? Thứ hai, tôi đã trải qua một đêm với Tor bị vô hiệu hóa và lưu lượng truy cập vẫn tăng (Apache không hiển thị lưu lượng đáng kể), khi cấu hình lại lưu lượng fail2ban gần như dừng lại
usr-local-ΕΨΗΕΛΩΝ

1
Hãy để tôi nói lại một chút, chỉ trong trường hợp. Nếu tôi muốn rút 4GB băng thông từ máy chủ, tôi có thể tạo một mạng botnet mở các kết nối HTTP và gửi tải trọng POST không giới hạn cho mỗi yêu cầu. Nhật ký sẽ cho thấy các yêu cầu thất bại xảy ra với tỷ lệ thấp, nhưng mỗi yêu cầu là cực kỳ nặng. Nhưng điều này bắt đầu mất ý nghĩa. Tôi đã quen với quét SSH ("xác thực thất bại cho root, quản trị viên ...") vì mục tiêu của họ là kiểm soát nút. Tại sao kẻ tấn công lại quan tâm đến việc rút cạn băng thông qua SSH? Không có ý nghĩa. Trừ khi ai đó ghét các nút Tor ...
usr-local-ΕΨΗΕΛΩΝ
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.