Ghi nhật ký các lần truy cập SSH


60

Tôi đã cấu hình một máy chủ Ubuntu với openssh để kết nối với nó và thực hiện các lệnh từ một hệ thống từ xa như điện thoại hoặc máy tính xách tay. Vấn đề là ... tôi có lẽ không phải là người duy nhất.

Có cách nào để biết tất cả các nỗ lực đăng nhập đã được thực hiện cho máy chủ không?


Bạn cũng nên xem xét việc chạy sshd trên một cổng không chuẩn. Ngoài ra, có thể thiết lập iptables để từ chối các lần thử kết nối mới nếu một IP cố gắng kết nối ssh mới X lần trong một phút.
ivanivan

Đối với tôi, vấn đề không phải là fail2ban mà là sshguard, điều mà tôi chưa bao giờ nghe nói đến
Ray Foss

Câu trả lời:


55

Trên máy chủ Ubuntu, bạn có thể tìm thấy ai đã đăng nhập khi (và từ đâu) trong tệp /var/log/auth.log. Ở đó, bạn tìm thấy các mục như:

May  1 16:17:02 owl CRON[9019]: pam_unix(cron:session): session closed for user root
May  1 16:17:43 owl sshd[9024]: Accepted publickey for root from 192.168.0.101 port 37384 ssh2
May  1 16:17:43 owl sshd[9024]: pam_unix(sshd:session): session opened for user root by (uid=0)

2
Ra khỏi tò mò, không Ubuntu có các lastblệnh ?
Bratchley

1
@JoelDavis Ubuntu 12.04 của tôi có, nhưng đầu ra là một dòng duy nhất trông không giống đầu ra của bạn. Có lẽ nó cần phải được cấu hình.
Anthon


Trên Ubuntu Server 14.04 trở lên, nên đọc/var/log/auth.log
Serge Stroobandt

29

Trên các bản phát hành dựa trên Red Hat như Fedora / CentOS / RHEL, bạn có thể kiểm tra người dùng đã đăng nhập trong tệp /var/log/secure.

Nếu bạn muốn biết thêm thông tin, hãy đọc Câu hỏi và trả lời SuperUser này có tiêu đề: Làm cách nào tôi có thể ghi nhật ký các lần truy cập SSH và theo dõi những gì người dùng SSH kết thúc trên máy chủ của tôi? .


1
Không có /var/log/securebất kỳ hệ thống Ubuntu nào của tôi.
Anthon

@Anthon, đáng ngạc nhiên là tôi không có /var/log/authtrong hệ thống của mình. Đó là lý do tại sao trước khi đăng câu trả lời, tôi đã kiểm tra xem tôi có /var/log/securetrong hệ thống của mình không, cũng là máy chủ Ubuntu :)
Ramesh

Tôi đã kiểm tra 14.04, 12.04 và máy cũ dưới 8.04. Phiên bản nào bạn đang chạy? Đã làm gì đặc biệt để có được tập tin đó?
Anthon

@Anthon, hóa ra máy chủ mà tôi đã thử nghiệm là RHEL. Tuy nhiên, câu trả lời trong liên kết mà tôi đã cung cấp là cho Ubuntu có vẻ kỳ lạ, vì bạn đã kiểm tra 3 biến thể của Ubuntu và không có /var/log/secure.
Ramesh

6
/var/log/securelà một đồng vị Fedora / CentOS / RHEL.
slm

8

Trên Ubuntu, bạn có thể đăng nhập qua SSH và sử dụng lệnh đuôi Linux để hiển thị số dòng x cuối cùng của /var/log/auth.logtệp. Khi bạn đăng nhập qua SSH, hãy sử dụng lệnh sau để xem 100 dòng cuối cùng của nhật ký SSH:

tail /var/log/auth.log -n 100

hoặc thậm chí sạch hơn

tail -100 /var/log/auth.log | grep 'sshd'

7

Lưu ý rằng cấu hình mặc định trên Ubuntu là KHÔNG đăng nhập thông tin đăng nhập ssh vào /var/log/authtệp. Đây là INFOcấp độ đăng nhập.

Nếu bạn muốn có nó bao gồm các lần thử đăng nhập trong tệp nhật ký, bạn sẽ cần chỉnh sửa /etc/ssh/sshd_configtệp (dưới dạng root hoặc bằng sudo) và thay đổi LogLeveltừ INFOthành VERBOSE.

Sau đó, khởi động lại daemon sshd với

sudo service rsyslog restart

Sau đó, các nỗ lực đăng nhập ssh sẽ được đăng nhập vào /var/log/auth.logtập tin.


4

Đề nghị của tôi là sử dụng audd . Đây là ghi nhật ký bằng hệ thống con kiểm toán của kernel linux và theo tôi là cách thích hợp để làm điều đó nếu bạn nghiêm túc. Và với bản chất của câu hỏi {bảo mật liên quan}, bạn cũng nên sử dụng PAM . Ở mức mặc định chỉ cần cài đặt auddPAM , bạn sẽ tự động nhận được tất cả các lần thử SSH thành công và không thành công được đăng nhập vào tệp aud.log của bạn. Vì vậy, bạn thực sự không phải cấu hình bất cứ điều gì, chỉ cần cài đặt auddPAM . Tôi biết tay đầu tiên này cho SLES. Và sẽ đặt cược RHEL và bất kỳ phiên bản doanh nghiệp nào khác của linux sẽ hoạt động tương tự.

http://manpages.ubfox.com/manpages/precise/man8/auditd.8.html

trong nhật ký kiểm toán liệu được tạo ra bởi auditd bạn có thể sử dụng hoặc sử dụng một cái gì đó giống như aureportđể lọc nó được mô tả trong các auditd trang người đàn ông, viết phân tích cú pháp văn bản của riêng bạn, hoặc chỉ sử dụng VI và tìm kiếm các từ khóa.

đây là một ngoại lệ của /var/log/audit/audit.logtập tin của tôi với tôi ssh'ing vào máy chủ linux của tôi.

node=shark type=CRED_DISP msg=audit(1480622612.317:2211277): user pid=117768 uid=0 auid=23456 ses=2201 msg='op=PAM:setcred acct="ron" exe="/usr/sbin/sshd" (hostname=abc415.mycompany.us, addr=172.16.152.5, terminal=ssh res=success)'
  • Từ trên, tên máy chủ của tôi là cá mập .
  • nhiều dòng như thế này nằm trong aud.log, tôi muốn dòng này dựa trên exe = "/ usr / sbin / sshd"
  • uid của tài khoản được ssh'd vào là giá trị của auid, là 23456 cho ví dụ này
  • tên của tài khoản người dùng được liên kết với auid được chỉ định bởi acct = "ron"
  • hầu hết các lần hệ thống kiểm toán sẽ ghi lại tên máy chủ dns của hệ thống đang cố gắng kết nối, nhưng nó luôn có địa chỉ IP
  • ngày của mục nhập trong thời gian kỷ nguyên, vì vậy bạn sẽ phải chuyển đổi thông qua mục đó giống như date --date @1480622612.317kết quả Thu Dec 1 15:03:32 EST 2016và là khi tôi vào máy chủ của mình.

Khi res=failednào bạn muốn điều tra các địa chỉ IP và tên máy chủ đó để xem hệ thống nào đang cố gắng kết nối, dưới tên người dùng đã thử. Và rõ ràng là ssh thành công cố gắng hiểu những gì đang xảy ra trên hệ thống của bạn - ví dụ: đồng nghiệp bob của bạn, người ngồi cùng bàn hàng ngày với tên máy chủ = bobscomputer và địa chỉ ip = 192.168.5.5; nếu bạn thấy một nỗ lực ssh thành công vào lúc 2 giờ sáng ngày hôm qua dưới tên người dùng của anh ấy từ địa chỉ ip 10.10.5.6 chẳng hạn thì có thể bạn nên nói chuyện với bob để điều tra. Có thể hack cố gắng của người khác? Và ngay sau đó có những nỗ lực để root trong nhật ký kiểm toán từ tài khoản của bob?

khi bạn nhìn thấy lặp đi lặp lại res=failedauid=0acct=rootsau đó đó là một ai đó cố gắng để ssh vào hộp của bạn vào tài khoản root, và là khi bạn sửa đổi /etc/hosts.denyvới địa chỉ IP cho sshd.


2

Tôi biết điều này đã cũ nhưng tôi đã viết một cái gì đó để theo dõi các kết nối / nỗ lực ssh thành công và thất bại. Cũng như IP bị cấm nếu bạn đang sử dụng sshguard. Phần mềm được viết bằng Python. Nó sẽ gửi email cho bạn khi ai đó kết nối thành công qua ssh, khi ai đó lấy nhầm mật khẩu ssh hoặc khi ai đó bị cấm do nhiều lần thử thất bại. Hy vọng rằng điều này sẽ giúp ai đó trong tương lai tìm kiếm vấn đề này và tìm thấy mã của tôi!

https://github.com/amboxer21/SSHMonitor

Đối với kịch bản python, tôi đã viết một tập lệnh bash để theo dõi quá trình. Nó kiểm tra nếu nó chạy mỗi phút thông qua tác vụ cron gốc. Nếu nó không chạy, nó bắt đầu một quá trình khác. Được gọi bởi một tác vụ cron gốc mỗi phút.


-2

Điều tốt nhất tôi từng gặp khi ghi nhật ký các lệnh SSH là rootsh công cụ này cho phép quản trị viên nhận mọi lệnh từ mỗi phiên với mức ghi nhật ký mở rộng.

Tôi đã viết một tập lệnh để cài đặt và định cấu hình ROOTSH trong ubfox và CentOS / RHEL

tải về từ github ở đây là liên kết

https://gist.githubusercontent.com/mansurali901/e1e3acc7dca13aeca25b68a69571c60f/raw/b1b16f73ec9a974486e4c0c0d65a7d41f2eca718/setup_rootssh.sh

chmod +x setup_rootssh.sh ; sudo ./setup_rootssh.sh

Tôi nghĩ rằng đây là một cách tồi để quảng bá hồ sơ github của bạn ... Về cơ bản, bạn đang yêu cầu tải xuống một tập lệnh từ web và thực thi nó bằng root. Downvote
UserK

Tôi không quảng bá hồ sơ github của mình, tôi chỉ cố gắng đơn giản hóa mọi thứ như mọi người ở trên nếu bạn bỏ phiếu cho tôi để quảng cáo hồ sơ xuống bỏ phiếu cho họ. hơn nữa, trong hướng dẫn quy tắc trao đổi ngăn xếp, không có gì được viết như thế mà chúng ta không thể chia sẻ các tệp mã từ kho lưu trữ cá nhân.
Mansur Ali

Xin hãy tha thứ cho khiếu hài hước của tôi. Trước hết cảm ơn bạn đã trả lời Mansur. Downvote xuất phát từ thực tế là bạn đang yêu cầu thực thi một loạt các lệnh chưa biết với tư cách là người dùng root. Lần trước tôi đã làm điều đó, có một 'rm -R slash' bên trong.
Người dùng

1
Bằng cách này, bằng cách trao đổi ngăn xếp sẽ không cho phép tôi mã dài như vậy đó là lý do tại sao tôi đặt tập lệnh đó vào câu trả lời của mình. Linux rất đơn giản.
Mansur Ali
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.