Cách theo dõi các hoạt động siêu người dùng


21

Tôi muốn biết các cách tiếp cận tốt nhất để theo dõi các hoạt động siêu người dùng trên môi trường Linux.

Cụ thể, tôi đang tìm kiếm các tính năng này:

  • A) Ghi nhật ký tổ hợp phím vào máy chủ nhật ký hệ thống được bảo mật
  • B) Khả năng phát lại các phiên shell (đại loại như kịch bản)
  • C) Lý tưởng nhất, đây là điều không thể (hoặc khá khó khăn) để phá vỡ mà không có quyền truy cập vật lý vào máy chủ.

Hãy suy nghĩ về điều này từ góc độ bảo mật / kiểm toán, trong một môi trường nơi các hệ thống khác nhau (hoặc thậm chí là bên thứ ba) cần được phép thực hiện các hoạt động đặc quyền trên máy chủ.

Mỗi quản trị viên sẽ có tài khoản danh nghĩa của riêng mình và mọi phiên tương tác phải được ghi lại đầy đủ, với khả năng phát lại nếu cần thiết (ví dụ: nếu ai đó sử dụng mc để xóa hoặc thay đổi các tệp quan trọng, thì sẽ không đủ biết rằng người đó đã ban hành lệnh mc, phải có cách để xem chính xác những gì đã được thực hiện sau khi khởi chạy mc).

Ghi chú bổ sung :

  1. Như womble đã chỉ ra, có thể là lựa chọn tốt nhất sẽ không có người đăng nhập bằng quyền root để thực hiện các thay đổi trên máy chủ, mà thay vào đó thực hiện điều đó thông qua hệ thống quản lý cấu hình. Vì vậy, hãy giả sử một tình huống trong đó chúng ta không có một hệ thống như vậy và chúng ta cần cấp quyền truy cập cấp gốc cho những người khác nhau trên cùng một máy chủ .
  2. Tôi hoàn toàn không hứng thú với việc này một cách lén lút: mọi người đăng nhập vào máy chủ có quyền root sẽ nhận thức đầy đủ rằng phiên sẽ được ghi lại (ví dụ như, ví dụ, các nhà điều hành trung tâm cuộc gọi biết rằng các cuộc hội thoại của họ được ghi lại)
  3. Không ai sẽ sử dụng tài khoản superuser chung ("root")
  4. Tôi biết về ttyrpld và nó dường như làm những gì tôi đang tìm kiếm. Nhưng trước khi đi theo cách đó, tôi muốn biết liệu điều này có thể được giải quyết hay không bằng cách sử dụng kernel chưa sửa đổi. Tôi muốn biết liệu có bất kỳ công cụ nào cho Debian nói riêng (hay nói chung là Linux) cho phép kiểm tra toàn bộ tài khoản siêu người dùng mà không cần vá vỏ hoặc kernel.

2
(lấy ghế và bỏng ngô) cái này sẽ tốt ...
Avery Payne

+1 ... đã suy nghĩ chính xác điều tương tự. LOL
KPWINC

Cũng lưu ý câu hỏi liên quan này: serverfault.com/questions/46614/ từ
sleske

Tôi vẫn nghĩ bạn nên sử dụng một hệ thống quản lý cấu hình. (con rối / cengine / đầu bếp / systemimager / đầu bếp / v.v ...)
KevinRae

Kevin, tôi đồng ý với bạn. Xem ví dụ bình luận của tôi để trả lời của womble: serverfault.com/questions/50710/ . Thật không may, đó không phải là một lựa chọn trên môi trường này và đó là lý do tại sao tôi yêu cầu đưa ra một kịch bản trong đó một hệ thống quản lý cấu hình không có sẵn. Dù sao, tôi muốn cảm ơn bạn đã phản hồi về chủ đề này.
mfriedman

Câu trả lời:


8

Đối với môi trường có nhiều quản trị viên, đừng sử dụng root - bao giờ nếu có thể.

Sử dụng sudo cho mọi thứ - sudo cực kỳ cấu hình và dễ dàng đăng nhập.

Đăng nhập bất kỳ / tất cả thông tin đăng nhập hoặc su để root và điều tra chúng như một người nào đó đang đi xung quanh các quy tắc được thiết lập của bạn.


3
Vâng, sudo đã đăng nhập tuyệt vời - tất cả các mục "womble ran / bin / sh as root" đều thực sự hữu ích. Nếu không có quản lý cấu hình, mọi người sẽ luôn trở thành root để thực hiện các tác vụ quản trị viên và ai đó muốn làm điều gì đó bất chính chỉ có thể thực hiện công việc của họ trong cùng một phiên root như thực hiện một tác vụ hợp lệ. Vỏ bọc hoàn hảo.
womble

Chính sách phải ngăn chặn đơn giản là loại bỏ căn nguyên để điều này trở nên tốt đẹp, và bạn sẽ không thể biết họ đã làm gì khi họ rời khỏi phòng, nhưng nó thu hẹp danh sách nghi phạm ...
dmckee

2
Chính sách: "sudo / bin / sh" = bị sa thải / điều tra. Khá rõ ràng, giải pháp khá dễ dàng.
Karl Katzke

5
có rất nhiều cách để lấy shell từ các chương trình mà mọi người sẽ cần phải chạy một cách hợp pháp (ví dụ từ sudo vi) đến mức có rất ít điểm chỉ trong việc chặn 'sudo /bin/sh'... cho dù bạn có thể chắc chắn rằng bạn đã chắc chắn rằng bạn đã đã chặn mọi phương thức có thể, bạn sẽ đưa ra một thách thức để tìm ra những cách tối nghĩa hơn. trong mọi trường hợp: a) đôi khi sudo / bin / sh là cần thiết và b) đó là vấn đề quản lý, không phải công nghệ.
cas

Chris đưa ra một quan điểm tuyệt vời: Vấn đề quản lý, không phải vấn đề công nghệ.
Karl Katzke

2

Đối với một, loại truy cập người dùng root mà bạn đang tìm kiếm để theo dõi? Lỗi quản trị ngu ngốc hay nội gián độc hại? Trước đây - bạn sẽ muốn một giải pháp quản lý cấu hình tốt, như đã được đề xuất. Điều thứ hai - nếu họ biết những gì họ đang làm, bạn chỉ có thể hy vọng nắm bắt đủ để chỉ ra điều gì đó đã xảy ra đáng để điều tra. Bạn chỉ muốn biết rằng một số hình thức hoạt động trái phép đã bắt đầu và được cảnh báo về thực tế đó. Nếu họ thông minh, họ sẽ vô hiệu hóa hầu hết việc đăng nhập mà bạn xây dựng (bằng cách thay đổi trạng thái máy chủ hoặc bằng cách đưa vào các công cụ của riêng họ) nhưng hy vọng bạn có thể nắm bắt được sự khởi đầu của sự cố.

Điều đó đang được nói, tôi đề nghị một vài công cụ bạn có thể sử dụng. Đầu tiên, bắt đầu với một chính sách sudo tốt (đã được đề xuất). Thứ hai, hãy kiểm tra sudoshell nếu bạn có nhu cầu cấp cho những quản trị viên quyền truy cập shell root. Thứ ba, có lẽ là đặt cược tốt nhất của bạn (mặc dù chuyên sâu nhất), hãy xem xét kiểm toán kernel linux.


+1 Cảm ơn bạn đã đề xuất sudoshell và đặc biệt là đã đo lường hệ thống kiểm toán của nhân Linux - đó có thể là sự bổ sung tuyệt vời cho những gì tôi đang cố gắng đạt được.
mfriedman

2

Những gì bạn có thể làm là sử dụng thư viện này cho sudo, cung cấp cho mọi người tài khoản người dùng của riêng họ và đưa sudo -i vào hồ sơ của mọi người. Bằng cách đó, họ có quyền truy cập root ngay lập tức và mọi lệnh họ sử dụng đang được ghi lại.


+1 Tôi không biết về thư viện đó. Cảm ơn bạn đã chia sẻ!
mfriedman

1

Họ đã root. Điều tốt nhất bạn có thể hy vọng là ít nhất là nhìn thấy khi họ quyết định thoát ra khỏi sự theo dõi không tưởng của bạn, nhưng ngoài ra những gì họ làm là đoán của bất cứ ai.

Tùy chọn "tốt nhất" mà tôi có thể nghĩ đến là bắt buộc sử dụng quản lý và tự động hóa cấu hình phổ biến và quản lý các bảng kê khai của bạn bằng hệ thống kiểm soát sửa đổi và triển khai các bản cập nhật thông qua đó. Sau đó ngăn chặn đăng nhập gốc thực tế đến các máy chủ. (Có thể cung cấp quyền truy cập khẩn cấp "oh noes I broken" bằng mật khẩu không được phân phối và thay đổi sau mỗi lần sử dụng và mọi người đều phải xem sysadmin đã vặn vít để đảm bảo họ không thay đổi bất cứ điều gì).

Vâng, điều này sẽ gây bất tiện và phiền toái, nhưng nếu bạn đủ hoang tưởng muốn theo dõi hành động của mọi người ở mức độ này, tôi đoán bạn đang ở trong một môi trường bất tiện và đủ khó chịu theo những cách khác mà điều này đã thắng Có vẻ như là một vấn đề lớn.


Tôi phải đồng ý với bạn. Tùy chọn tốt nhất sẽ không có người đăng nhập bằng quyền root để thực hiện các thay đổi trên máy chủ, mà thay vào đó thực hiện điều đó thông qua hệ thống quản lý cấu hình. Tôi thấy ý kiến ​​của bạn hữu ích cho việc tinh chỉnh và làm rõ câu hỏi của tôi.
mfriedman

1

Như những người khác đã nói rằng gần như không có cách nào để đăng nhập người dùng với quyền truy cập root đầy đủ theo cách họ không thể vô hiệu hóa, nhưng nếu bạn đang chạy debian / ub Ubuntu, hãy xem snoopy , gần với những gì bạn muốn

snoopy chỉ đơn thuần là một thư viện dùng chung được sử dụng như một trình bao bọc cho hàm execve () được cung cấp bởi libc để ghi nhật ký mọi cuộc gọi vào syslog (authpriv). Quản trị viên hệ thống có thể thấy snoopy hữu ích trong các tác vụ như giám sát hệ thống nhẹ / nặng, theo dõi hành động của quản trị viên khác cũng như cảm nhận tốt về những gì đang diễn ra trong hệ thống (ví dụ: apache chạy tập lệnh cgi).


Cảm ơn bạn đã trả lời. Nó có hỗ trợ ghi nhật ký gõ phím hay chỉ ghi nhật ký lệnh?
mfriedman

0

Tôi đồng ý với ý kiến ​​của người khuyết tật về việc sử dụng sudo cho mọi thứ. Nó chắc chắn làm cho mọi thứ dễ dàng hơn để đăng nhập.

Tôi cũng sẽ thêm sao lưu tệp lịch sử bash theo định kỳ. Dường như thường bị bỏ qua nhưng đôi khi có thể là một nguồn thông tin tuyệt vời ... chỉ cần hỏi Goldman Sachs. ;-)

http://www.guardian.co.uk/business/2009/jul/12/goldman-sachs-sergey-aleynikov


2
tôi có một tập lệnh .bash_logout tạo một bản sao có dấu thời gian của lịch sử thành /var/lib/history/$user.$tty-or-IP.$yymmddhhss nếu tôi quan tâm nhiều hơn, tôi sẽ thiết lập kế toán quy trình hoặc đúng công cụ kiểm toán ... nhưng nó không thực sự bảo mật, vì vậy tôi có thể tìm ra ai đã làm điều gì đó ngớ ngẩn và nói với họ a) không làm lại và b) làm thế nào để làm điều đó đúng. tăng mức độ đầu mối của đàn em là vấn đề ở đây nhiều hơn là sự tin tưởng.
cas

1
Nhắc tôi nhớ về câu chuyện mà một anh chàng bán hàng đàn em thổi thỏa thuận triệu đô. Anh ta hy vọng ông chủ sa thải anh ta và ông chủ nói, "Địa ngục không! Nó chỉ tiêu tốn của tôi một triệu đô la để ĐÀO TẠO BẠN!" Tôi có thể cảm thấy "cấp độ đầu mối" của đàn em ngày càng tăng khi chúng tôi nói chuyện. ;-)
KPWINC

0

Điều đó thật khó khăn ...

root có thể chạy các kịch bản được kiểm tra cẩn thận có thể vi phạm tất cả các biện pháp bảo mật (tiêu diệt các quy trình giám sát), cắt các tệp nhật ký / cắt xén chúng, v.v ... Nhưng vẫn ...

Giả sử nhiều quản trị viên được cấp đặc quyền root đang làm việc theo nhóm. Và root có thể giết bất kỳ quá trình giám sát là tốt. Và thật không may, thông tin đăng nhập / mật khẩu đó trở nên công khai. Hoặc họ nhận được công ty không mong muốn.

Tạo nhiều tài khoản root bằng UID 0 mặc dù không được khuyến nghị, có thể được áp dụng tại đây.

Trong / etc / ssh / sshd_config Thay đổi dòng thành: PermitRootLogin no

được khuyến khích. Vì vậy, ở đây, người dùng đăng nhập bằng tài khoản thông thường của mình (tem datetime được ghi cùng với (Địa chỉ IP giả mạo)) Sau đó chuyển sang root. sử dụng lệnh su

Và đăng nhập trực tiếp như root được ngăn chặn như thế này.

Chúng tôi phải suy nghĩ, những gì root không thể làm ở đây.

sudo nên tốt Sao lưu / etc thư mục Cấu hình tập tin nên được tốt. / var / thư mục Các tệp nhật ký nên được gửi qua email định kỳ hoặc được lưu trữ trên NFS riêng biệt.

Làm thế nào về việc Viết các Tập lệnh tích hợp API từ các công ty Cổng di động nhóm SMS tất cả các điện thoại di động của người dùng gốc, rằng một trong số họ không có việc để làm việc. Tôi biết điều đó sẽ gây khó chịu, nhưng vẫn còn.

Phá vỡ SSH chủ yếu là ra khỏi câu hỏi.


0

Chúng tôi có các thiết lập sau trên trang web của khách hàng:

  • Tương tự như vậy - mở để xác thực bằng kerberos trên AD (tài khoản cá nhân)
  • Chỉ ủy quyền cho một số nhóm quản trị viên Unix nhất định
  • nhóm sudoers == nhóm AD
  • Đại lý OSSEC HIDS trên mọi máy chủ và người quản lý trên máy chủ cứng
  • Giao diện người dùng web OSSEC
  • Splunk 3 với Splunk-for-OSSEC

Nó sẽ ghi nhật ký mọi sử dụng sudo trên máy chủ và cũng theo dõi mọi thay đổi đối với tệp, cài đặt gói, quy trình đáng ngờ, v.v.


0

Chúng tôi có một số máy chủ đầu cuối để truy cập vào tất cả các thiết bị của mình, điều đó có nghĩa là người ta có thể đăng nhập vào bất cứ thứ gì từ máy chủ đầu cuối hoặc nếu một máy chủ có quyền truy cập vật lý.

Sshd trên các máy chủ đầu cuối được vá bằng http://www.kdvelectronics.eu/ssh-logging/ssh-logging.html , hoạt động tốt, nhưng đã được cập nhật trong một thời gian dài. Tôi đã sửa đổi nó một chút để hoạt động trên openssh 4.7, nhưng không thể làm điều đó với 5.1. Các bản vá lỗi sshd được vá, và miễn là tôi không có đủ thời gian để sửa nó, tôi gần như đã chuyển sang ttyrpld.


0

Cho đến nay, đây là những gì tôi có:

  • sudosh : dường như hỗ trợ A và B (mặc dù không hoàn toàn chắc chắn về A)
  • Sudoscript : dường như hỗ trợ B (Sudoscript có một thành phần gọi là sudoshell, và nếu đó là những gì romandas đề xuất, cảm ơn vì tiền boa)
  • Snoopy Logger hoặc sudo_exetrace : không chính xác những gì tôi đang tìm kiếm, nhưng có thể là một bổ sung tốt (nhờ vào điều kiện nhiệt và blauwblaatje cho các liên kết đó)

Bạn có biết bất kỳ công cụ tương tự nào khác không liên quan đến việc vá kernel hoặc các thành phần hệ thống khác không?

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.