آموزش مانیتورینگ لاگ‌های احراز هویت سیستم در اوبونتو

پایش لاگ‌های احراز هویت سیستم در اوبونتو به شما کمک می‌کند رمزهای عبور سرقت‌شده، تلاش‌های حمله جستجوی فراگیر (Brute-Force) به SSH و استفاده‌های غیرمنتظره از sudo را شناسایی کنید. این راهنما نشان می‌دهد این رکوردها کجا ذخیره می‌شوند، چگونه آن‌ها را با فایل‌های کلاسیک و journalctl بخوانید و چگونه فیلتر کردن را با fail2ban و مبانی فایروال ترکیب کنید.

این آموزش روی اوبونتو 24.04 LTS و اوبونتو 22.04 LTS اعتبارسنجی شده است. دستورات روی نسخه‌های جدیدتر اوبونتو که از systemd استفاده می‌کنند هم باید بدون مشکل کار کنند.

می‌توانید این آموزش را روی یک سرور اوبونتوی LTS به‌روز دنبال کنید. اگر به سرور جدید نیاز دارید، ابتدا راهنمای راه‌اندازی اولیه سرور با اوبونتو در پارمین کلود را کامل کنید.

نکات کلیدی

• اوبونتو معمولاً رویدادهای احراز هویت ممتاز را در /var/log/auth.log می‌نویسد و نسخه‌های ساختاریافته آن‌ها را هم در ژورنال systemd ذخیره می‌کند (با journalctl کوئری بگیرید).
• دستورات last و lastlog خلاصه تاریخچه ورود را از /var/log/wtmp و /var/log/lastlog می‌خوانند، نه مسیرهای قدیمی و اشتباه زیر /etc/log/.
• خطوط PAM در auth.log رویدادهای باز و بسته شدن نشست را توصیف می‌کنند؛ تلاش‌های ناموفق رمز عبور و رد شدن‌های sudo الگوهای جداگانه و مهمی هستند که باید مراقب آن‌ها باشید.
• grep، awk و کوئری‌های زمان‌محدود journalctl روش‌های رایج برای شکار سوءاستفاده از SSH و ارتقای سطح دسترسی هستند؛ پیش از اینکه fail2ban یا لاگینگ متمرکز را اضافه کنید.

اوبونتو لاگ‌های احراز هویت را کجا ذخیره می‌کند

auth.log و پایپ‌لاین لاگینگ

روی بیشتر سرورهای اوبونتو، rsyslog پیام‌های syslog را دریافت می‌کند و خطوط مرتبط با امنیت را در /var/log/auth.log می‌نویسد. پشته ماژول‌های احراز هویت قابل اتصال (PAM) تعیین می‌کند که یک درخواست ورود یا sudo موفق شود یا نه؛ سپس PAM و SSH خطوطی از نوع syslog تولید می‌کنند که rsyslog آن‌ها را به این فایل هدایت می‌کند.

systemd-journald هم همین سرویس‌ها را ثبت می‌کند. یعنی می‌توانید رویدادهای اخیر را با فایل‌های متنی ساده یا با journalctl بررسی کنید؛ بسته به اینکه کدام ابزار با روند کاری شما سازگارتر است.

در اوبونتو 24.04 و 22.04، فایل /var/log/auth.log وقتی موجود است که rsyslog نصب و در حال اجرا باشد. در ایمیج‌های مینیمال ممکن است auth.log وجود نداشته باشد. در این صورت از journalctl استفاده کنید (بخش بعدی) یا rsyslog را نصب کنید:

ls -l /var/log/auth.log
sudo systemctl status rsyslog
sudo apt update
sudo apt install rsyslog
sudo systemctl enable --now rsyslog

مقایسه auth.log با syslog

لاگ	نقش معمول
/var/log/auth.log	خطوط مربوط به SSH، sudo، PAM و ورود
/var/log/syslog	ترافیک گسترده‌تر دیمن‌ها؛ میزان هم‌پوشانی به قوانین rsyslog بستگی دارد

اگر برای یک بازه زمانی به کل ماجرا نیاز دارید، از auth.log برای خطوط مرتبط با امنیت شروع کنید و وقتی سرویس‌هایی را عیب‌یابی می‌کنید که صرفاً احراز هویت نیستند، دامنه جستجو را به syslog گسترش دهید.

دیتابیس‌های باینری ورود

ابزارهایی مانند last فایل /var/log/wtmp را می‌خوانند (نه /etc/log/wtmp). دستور lastlog فایل /var/log/lastlog را می‌خواند (نه /etc/log/lastlog). این مسیرها به‌راحتی اشتباه تایپ می‌شوند؛ مکان‌های درست زیر /var/log/ قرار دارند.

بررسی تلاش‌های احراز هویت در auth.log

برای مرور صفحه‌به‌صفحه لاگ احراز هویت:

sudo less /var/log/auth.log

نمونه خطوط (نام هاست و زمان‌ها در سیستم شما متفاوت خواهد بود):

May  3 18:20:45 host sshd[585]: Server listening on 0.0.0.0 port 22.
May  3 18:23:56 host login[673]: pam_unix(login:session): session opened for root
Sep  5 13:49:07 host sshd[358]: Received signal 15; terminating.

برای خروج از less کلید q را بزنید.

مشاهده لاگ‌های احراز هویت به‌صورت زنده

رویدادهای جدید را هم‌زمان با ورودشان دنبال کنید:

sudo tail -f /var/log/auth.log

با Ctrl+C متوقف کنید. این سریع‌ترین راه برای تماشای یک حمله زنده SSH یا تست اینکه آیا ورود مبتنی بر کلید شما خطوط مورد انتظار را تولید می‌کند یا نه، است.

خواندن رویدادهای احراز هویت با journalctl

journalctl ژورنال systemd را می‌خواند. وقتی به یونیت‌های systemd، بوت‌ها یا بازه‌های زمانی فشرده نیاز دارید، درخشش می‌کند. برای SSH در اوبونتو، سرویس معمولاً ssh نام دارد:

journalctl -u ssh

همچنین می‌توانید به‌صورت صریح بر اساس یونیت فیلتر کنید:

journalctl _SYSTEMD_UNIT=ssh.service

اگر journalctl -u ssh هیچ ورودی‌ای برنگرداند، نام یونیت را روی سیستم خودتان تأیید کنید. برخی توزیع‌ها از sshd استفاده می‌کنند:

sudo systemctl status ssh
sudo systemctl status sshd

خروجی را به ساعت یا روز گذشته محدود کنید:

journalctl -u ssh --since "1 hour ago"
journalctl -u ssh --since today

برای راهنمای عمیق‌تر درباره گزینه‌ها، فیلترها و الگوهای خروجی، راهنمای «نحوه استفاده از journalctl برای مشاهده و مدیریت لاگ‌های systemd» را در پارمین کلود بخوانید.

نحوه استفاده از دستور last

دستور last ورودها و ریبوت‌های اخیر را با استفاده از داده‌های /var/log/wtmp نمایش می‌دهد:

last

نمونه خروجی:

demoer   pts/1        203.0.113.10 Thu Sep  5 19:37   still logged in
root     pts/0        203.0.113.10 Thu Sep  5 19:15   still logged in

علامت still logged in یعنی نشست هنوز فعال است. نشست‌های بسته‌شده، زمان شروع و پایان را نشان می‌دهند.

نحوه استفاده از دستور lastlog

دستور lastlog آخرین ورودِ هر کاربر محلی را با ترکیب /var/log/lastlog و /etc/passwd چاپ می‌کند:

lastlog

حساب‌های سیستمی اغلب عبارت Never logged in را نشان می‌دهند که وقتی از آن حساب‌ها برای ورود تعاملی استفاده نمی‌شود، کاملاً طبیعی است.

تشخیص ورودهای ناموفق و فعالیت حمله Brute-Force به SSH

تلاش‌های ناموفق رمز عبور SSH معمولاً—بسته به پیکربندی—شامل عبارات Failed password یا authentication failure هستند. بررسی‌های سریع:

sudo grep "Failed password" /var/log/auth.log
sudo grep "authentication failure" /var/log/auth.log

یا با ژورنال:

journalctl -u ssh --since today | grep -i "failed"

یک موج پایدار از خطاها از یک آدرس واحد، نشانه قوی ترافیک خودکار brute force است. بررسی لاگ را با کنترل‌های شبکه ترکیب کنید: راهنمای راه‌اندازی فایروال با UFW روی اوبونتو در پارمین کلود، فیلترینگ در سطح هاست روی سرور پارمین کلود شما را توضیح می‌دهد.

ردیابی ارتقای سطح دسترسی با sudo و su

هم sudo و هم su خطوطی تولید می‌کنند که می‌توانید ردیابی کنید.

الگوهای رایج:

sudo grep "sudo:" /var/log/auth.log
sudo grep "COMMAND=" /var/log/auth.log
sudo grep -E "su\[|su:" /var/log/auth.log

عبارت COMMAND= در بسیاری از پیکربندی‌های sudo ظاهر می‌شود و ثبت می‌کند کدام باینری اجرا شده است. کاربران، هاست‌ها یا باینری‌های غیرمنتظره را فوراً بررسی کنید.

درک ورودی‌های لاگ PAM

PAM بین اپلیکیشن‌هایی مانند sshd و دیتابیس حساب کاربری شما قرار می‌گیرد. یک خط نشست معمولی به این شکل است:

May  3 18:23:56 host sshd[12345]: pam_unix(sshd:session): session opened for demoer

نگاشت تقریبی فیلدها:

• تاریخ و هاست: رویداد کِی و کجا رخ داده است.
• پروسه: sshd با یک PID داخل براکت.
• پشته و نتیجه PAM: ماژول pam_unix یا ماژول‌های دیگر، به‌همراه session opened یا session closed.
• موضوع: کدام کاربر یونیکس نشست گرفته است.

خطاهای احراز هویت اغلب به‌جای باز شدن نشست، عباراتی مثل auth failure، Failed password یا authentication failure را نشان می‌دهند. زمینه PAM را با پیام‌های SSH در کنار هم ببینید تا یک نشست موفق را با رمز عبور ناموفق اشتباه نگیرید.

پارس و فیلتر کردن لاگ‌ها با grep و awk

برای بسیاری از جستجوها، grep کافی است:

sudo grep -E "sshd|sudo|su" /var/log/auth.log | tail -n 50

وقتی ستون‌ها اهمیت دارند، awk کمک می‌کند:

sudo awk '/Failed password/ {print $0}' /var/log/auth.log

ارجاع به /etc/passwd و گروه‌ها را فقط وقتی اضافه کنید که نیاز دارید UIDها را به نام‌ها نگاشت کنید؛ لاگ‌ها معمولاً نام‌ها را مستقیماً چاپ می‌کنند.

خودکارسازی جلوگیری از Brute-Force با fail2ban

fail2ban فایل auth.log (یا ژورنال، بسته به بک‌اند) را زیر نظر دارد و بعد از خطاهای مکرر، قوانین فایروال را به‌روزرسانی می‌کند.

سرویس را نصب و فعال کنید:

sudo apt update
sudo apt install fail2ban
sudo systemctl enable --now fail2ban

یک jail مینیمال برای SSH اغلب در /etc/fail2ban/jail.d/defaults-debian.conf یا یک فایل سفارشی زیر /etc/fail2ban/jail.d/ قرار دارد. مطمئن شوید jail مربوط به sshd روی enabled = true تنظیم شده است، سپس وضعیت را بررسی کنید:

sudo fail2ban-client status
sudo fail2ban-client status sshd

برای آموزش کامل همراه با مدت‌زمان‌های ban و اکشن‌های ایمیل، راهنمای «محافظت از SSH با Fail2Ban روی اوبونتو» را در پارمین کلود دنبال کنید. آن را با UFW ترکیب کنید تا هم سیاست شبکه و هم banهای خودکار هم‌راستا باشند.

مدیریت نگهداری لاگ‌های احراز هویت با logrotate

اوبونتو فایل /var/log/auth.log را از طریق logrotate می‌چرخاند که معمولاً از طریق /etc/logrotate.d/rsyslog اجرا می‌شود. تنظیمات معمول، فایل‌های قدیمی را فشرده می‌کند و چند هفته از آن‌ها را روی دیسک نگه می‌دارد؛ اما این پیش‌فرض‌ها ممکن است در توزیع‌های مختلف تغییر کرده باشند، پس همیشه فایل فعال را بخوانید:

cat /etc/logrotate.d/rsyslog

برای آشنایی با مفاهیم چرخش لاگ (Log Rotation)، راهنمای «مدیریت لاگ‌فایل‌ها با Logrotate» را در پارمین کلود ببینید؛ مفاهیم آن در نسخه‌های فعلی اوبونتو هم به‌طور کامل کاربرد دارند.

فوروارد کردن لاگ‌های احراز هویت

تیم‌های پروداکشن اغلب لاگ‌های auth را به یک SIEM مرکزی یا کلاستر بکاپ ارسال می‌کنند. در یک نگاه کلی می‌توانید:

• از فورواردینگ journald یا قوانین rsyslog برای ارسال پیام‌های syslog به یک کلکتور ریموت استفاده کنید.
• وقتی فقط به یک بسته شواهد (Evidence Bundle) نیاز دارید، اسنپ‌شات‌ها را با journalctl خروجی بگیرید.
• قبل از ارسال لاگ‌ها از طریق اینترنت عمومی، امنیت انتقال (VPN یا TLS) را برقرار کنید.

برای مفاهیم جامع لاگینگ در لینوکس، راهنمای «مشاهده و پیکربندی لاگ‌های لینوکس» را در پارمین کلود بخوانید.

مرجع سریع: دستورات مانیتورینگ لاگ‌های احراز هویت

کار	دستور پیشنهادی
مرور صفحه‌به‌صفحه لاگ auth	sudo less /var/log/auth.log
مشاهده زنده	sudo tail -f /var/log/auth.log
ژورنال یونیت SSH	journalctl -u ssh --since "1 hour ago"
رمزهای عبور ناموفق	sudo grep "Failed password" /var/log/auth.log
فعالیت sudo	sudo grep "COMMAND=" /var/log/auth.log
ورودهای اخیر	last
آخرین ورود هر کاربر	lastlog
وضعیت fail2ban	sudo fail2ban-client status sshd

سوالات متداول

۱. فایل لاگ احراز هویت در اوبونتو کجاست؟

فایل متنی اصلی /var/log/auth.log روی ایمیج‌های پیش‌فرض اوبونتو است که از rsyslog استفاده می‌کنند. همیشه روی هاست خودتان با ls -l /var/log/auth.log وجود آن را تأیید کنید.

۲. تفاوت auth.log و syslog در اوبونتو چیست؟

auth.log روی رویدادهای احراز هویت و دسترسی‌های ممتاز تمرکز دارد. /var/log/syslog بخش گسترده‌تری از پیام‌های دیمن‌ها و سیستم را جمع‌آوری می‌کند. میزان هم‌پوشانی به قوانین rsyslog بستگی دارد، اما بررسی‌های امنیتی معمولاً از auth.log شروع می‌شوند.

۳. چطور بفهمم چه کسی به سرور اوبونتوی من وارد شده است؟

برای نشست‌های تعاملی last و برای خلاصه هر حساب کاربری lastlog را اجرا کنید؛ و وقتی به جریان دقیق رویدادهای SSH نیاز دارید، auth.log یا journalctl -u ssh را جستجو کنید.

۴. چطور یک حمله brute force به SSH را در اوبونتو تشخیص بدهم؟

به دنبال موج‌هایی از پیام‌های Failed password یا authentication failure با بازه‌های زمانی و IPهای مبدأ مشابه بگردید. بررسی لاگ را با قوانین UFW و jailهای fail2ban ترکیب کنید.

۵. آیا اوبونتو 24.04 همچنان از auth.log استفاده می‌کند؟

بله؛ وقتی که rsyslog نصب و در حال اجرا باشد. اوبونتو همچنین رویدادهای احراز هویت را در ژورنال systemd ذخیره می‌کند؛ بنابراین کوئری‌های journalctl حتی وقتی auth.log در یک ایمیج مینیمال وجود ندارد هم کار می‌کنند.

۶. چطور جلوی تلاش‌های مکرر ورود ناموفق را به‌صورت خودکار بگیرم؟

fail2ban را نصب و پیکربندی کنید تا خطاهای مکرر باعث banهای موقت شوند. به‌موازات آن، SSH را هاردن کنید (استفاده از کلیدها، پورت غیرپیش‌فرض، AllowUsers).

۷. اوبونتو به‌طور پیش‌فرض داده‌های auth.log را چقدر نگه می‌دارد؟

مدت نگهداری به تنظیمات logrotate و فضای دیسک بستگی دارد. فایل /etc/logrotate.d/rsyslog و فایل‌های آرشیوشده مانند /var/log/auth.log.* را بررسی کنید تا ببینید چند نسخه چرخش‌یافته روی سرور شما باقی مانده است.

۸. چطور استفاده از دستور sudo را در اوبونتو ردیابی کنم؟

در /var/log/auth.log به دنبال عبارات sudo: و COMMAND= بگردید و اگر لاگینگ sudo روی ایمیج شما به ژورنال می‌رود، خروجی journalctl را هم بررسی کنید.

نتیجه‌گیری

وقتی لاگ‌های احراز هویت سیستم را در اوبونتو مانیتور می‌کنید، مسیرهای فایل، کوئری‌های ژورنال و فیلترهای متنی ساده را ترکیب می‌کنید تا بفهمید چه کسی به هاست دسترسی داشته و آیا استفاده از دسترسی‌ها طبیعی به نظر می‌رسد یا نه. با بالغ‌تر شدن محیط خود، لایه‌های خودکار مانند fail2ban، قوانین فایروال و فوروارد متمرکز لاگ‌ها را اضافه کنید.