Máy chủ SSH khai thác 0 ngày - Gợi ý bảo vệ chính chúng ta


13

Theo Trung tâm Bão Internet , dường như có một khai thác không ngày SSH ngoài kia.

Có một số bằng chứng về mã khái niệm ở đây và một số tài liệu tham khảo:

Đây có vẻ là một vấn đề nghiêm trọng, vì vậy mọi quản trị viên hệ thống Linux / Unix nên cẩn thận.

Làm thế nào để chúng ta bảo vệ chính mình nếu vấn đề này không được vá kịp thời? Hoặc làm thế nào để bạn xử lý khai thác zero-day nói chung?

* Tôi sẽ gửi đề nghị của tôi trong các câu trả lời.


Làm thế nào là thực tế này? Một chút googletrolling bật lên seclists.org/fulldisclosure/2009/Jul/0028.html như là nguồn gốc của hầu hết các tin đồn này. Bất cứ ai có xác minh độc lập về điều này?
chris

Rất nhiều bình luận tốt về Hacker News về vấn đề này: news.ycombinator.com/item?id=692036
sucuri

Câu trả lời:


6

Nhận xét từ Damien Miller (nhà phát triển OpenSSH): http://lwn.net/Articles/340483/

Cụ thể, tôi đã dành một chút thời gian để phân tích một dấu vết gói mà anh ta cung cấp, nhưng dường như nó bao gồm các cuộc tấn công vũ phu đơn giản.

Vì vậy, tôi không theo đuổi rằng 0day tồn tại cả. Bằng chứng duy nhất cho đến nay là một số tin đồn ẩn danh và bảng điểm xâm nhập không thể kiểm chứng.


Tôi nghĩ chúng ta có thể tin lời anh ấy ngay bây giờ ...
sucuri

11

Đề nghị của tôi là chặn truy cập SSH trên tường lửa cho mọi người khác ngoài ip của bạn. Trên iptables:

/sbin/iptables -A INPUT --source <yourip> -p tcp --dport 22 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -j DROP

5

Theo bài đăng Sans, khai thác này does not work against current versions of SSH, và do đó không thực sự là 0 ngày. Vá máy chủ của bạn, và bạn sẽ ổn thôi.


2
về mặt kỹ thuật, đây là một khai thác 0 ngày (không được công bố và chưa biết) nhưng chỉ hoạt động trên các phiên bản SSH cũ hơn. Tuy nhiên, phiên bản mặc định trên RHEL, Fedora dễ bị tổn thương (theo bài đăng thứ hai). Vì vậy, sẽ là một vấn đề lớn nếu không có bản vá từ bản phân phối của bạn (trừ khi bạn sử dụng ssh từ nguồn không phổ biến) ...
sucuri

1
Họ đang suy đoán rằng dựa trên nhật ký tấn công. Không ai biết chắc chắn ... Ngay cả phiên bản mới nhất cũng có thể dễ bị tấn công
sucuri

3

Khiếu nại với các nhà cung cấp của bạn

Bằng cách đó, mọi người đều có phiên bản mới hơn.


3

FYI, nguồn gốc của câu chuyện: http://romeo.copyandpaste.info/txt/ssanz-pwned.txt

Ngoài ra còn có hai câu chuyện tương tự (hack astalavista.com và một trang web khác): romeo.copyandpaste.info/txt/astalavista.txt
romeo.copyandpaste.info/txt/nowayout.txt

Có vẻ như ai đó có một chương trình nghị sự: romeo.copyandpaste.info/ ("Giữ 0 ngày riêng tư")


Đã đồng ý. Nhóm đằng sau các bản ghi ban đầu đã bắt đầu điều này có một tuyên bố sứ mệnh để gây rối với "ngành công nghiệp bảo mật" - và cách nào tốt hơn để làm điều đó hơn là khiến mọi người náo động về "omg! Openssh 0day?! Làm thế nào để tôi tìm thấy / dừng lại nó / hack với nó? "
cji

Đây không phải là lần đầu tiên những tin đồn và sự cường điệu như vậy trở thành sai.
Dan Carley

2

Tôi biên dịch SSH để sử dụng tcprules và có một số lượng nhỏ các quy tắc cho phép, từ chối tất cả các quy tắc khác.

Điều này cũng đảm bảo rằng các lần thử mật khẩu gần như bị loại bỏ và khi tôi được gửi báo cáo về các lần thử breakin, tôi có thể thực hiện chúng một cách nghiêm túc.


2

Tôi không chạy ssh trên cổng 22. Vì tôi thường đăng nhập từ các máy khác nhau, tôi không muốn ngăn truy cập qua iptables .

Đây là sự bảo vệ tốt chống lại các cuộc tấn công zero-day - chắc chắn sẽ đi sau cấu hình mặc định. Nó kém hiệu quả đối với người đang cố gắng thỏa hiệp với máy chủ của tôi. Quét cổng sẽ hiển thị cổng nào tôi đang chạy ssh, nhưng tập lệnh tấn công các cổng SSH ngẫu nhiên sẽ bỏ qua máy chủ của tôi.

Để thay đổi cổng của bạn, chỉ cần thêm / sửa đổi Cổng trong tệp / etc / ssh / sshd_config .


Chạy SSH trên một cổng không chuẩn dường như làm giảm số lượng các cuộc tấn công vũ phu mà nó phải chịu, và có thể sẽ bảo vệ bạn khỏi hầu hết các loại sâu. Tuy nhiên, đây không phải là biện pháp chống lại ai đó quét mọi thứ theo cách thủ công và một con sâu có thể chỉ quét cổng mọi cổng để tìm ssh (rất dễ, chỉ tốn thời gian)
MarkR

@MarkR: Nó có thể không ngăn được một 'cracker / kiddie / hacker' đã xác định nhưng nó sẽ giữ cho các bot hoạt động cho đến khi sửa lỗi được phát hành. Đó là imho quan trọng nhất.
Andrioid

2

Tôi sẽ tường lửa và chờ đợi. Bản năng ruột của tôi là một trong hai điều:

A> Chơi khăm. Bởi rất ít thông tin bị bỏ lỡ cho đến nay, đây là ..

hoặc là...

B> Đây là một nỗ lực "hút thuốc và lừa dối", để gây lo ngại hơn 4.3. Tại sao? Điều gì sẽ xảy ra nếu bạn, một số tổ chức tin tặc, tìm thấy một khai thác zero-day thực sự tuyệt vời trong sshd 5.2.

Quá tệ chỉ phát hành tiên tiến (Fedora) kết hợp phiên bản này. Không có thực thể đáng kể sử dụng điều này trong sản xuất. Sử dụng nhiều RHEL / CentOS. Mục tiêu lớn. Nó nổi tiếng là backport RHEL / CentOS tất cả các bản sửa lỗi bảo mật của họ để giữ lại một số loại kiểm soát phiên bản cơ bản. Các đội đằng sau này không được hắt hơi vào. RHEL đã đăng (tôi đọc, sẽ phải khai thác liên kết) rằng họ đã cạn kiệt mọi nỗ lực để tìm bất kỳ lỗ hổng nào trong 4.3. Từ để không được xem nhẹ.

Vì vậy, trở lại ý tưởng. Một tin tặc quyết định bằng cách nào đó gây ra sự khuấy động khoảng 4.3, gây ra sự cuồng loạn hàng loạt cho UG đến 5,2p1. Tôi hỏi: bạn đã có bao nhiêu người rồi?

Để tạo ra một số "bằng chứng" cho việc chuyển hướng sai, tất cả "nhóm đã nói" sẽ phải làm bây giờ là chiếm lấy một số hệ thống bị xâm nhập trước đó ( WHMCS ? SSH trước?), Tạo một số nhật ký với một số sự thật nửa vời (tấn công-ee đã xác minh "một cái gì đó" đã xảy ra, nhưng một số điều không thể kiểm chứng bởi mục tiêu) hy vọng ai đó sẽ "cắn". Tất cả chỉ cần một thực thể lớn hơn để làm một cái gì đó quyết liệt (... HostGator ...) để làm cho nó nghiêm trọng hơn một chút, giữa sự lo lắng và bối rối ngày càng tăng.

Nhiều thực thể lớn có thể backport, nhưng một số có thể chỉ cần nâng cấp. Những người nâng cấp, hiện đang mở cho cuộc tấn công zero-day thực sự mà chưa có tiết lộ nào.

Tôi đã thấy những điều kỳ lạ xảy ra. Giống như, một loạt những người nổi tiếng chết liên tiếp ...


0

Chuyển sang Telnet? :)

Đùa qua một bên, nếu bạn có cấu hình tường lửa của mình, nó chỉ cho phép truy cập SSH vào một vài máy chủ. Vì vậy, bạn được an toàn.

Cách khắc phục nhanh có thể là cài đặt SSH từ nguồn (tải xuống từ openssh.org), thay vì sử dụng các phiên bản cũ có trên các bản phân phối Linux mới nhất.


Kernetized telnet thực sự an toàn hợp lý. Điều thú vị về kerberos là bạn có thể thu hồi một cách tập trung một khóa nếu bạn muốn, không giống như ssh nơi bạn phải truy cập từng máy chủ và xóa một khóa khỏi mỗi tệp ủy quyền.
chris
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.