پایش یکپارچگی ویژگی ناخوشایندی دارد: به مرجعی نیاز دارد که از سامانهای گرفته شده باشد که پاکبودنش دانسته است. و اگر سرور سه سال است کار میکند و پرسش نفوذ تازه امروز پیش آمده، برای گرفتن آن مرجع دیر شده است — آنچه را آنجاست همچون وضع عادی ثبت خواهید کرد.
اما روی Debian و Ubuntu مرجع از پیش هست، و از آنِ شما نیست: هر بسته نصبشده جمعهای کنترلی فایلهای خودش را با خود دارد. سنجیدن با آنها نه پیکربندی میخواهد و نه تصویر لحظهای پیشین، و روی هر سامانهای در هر لحظهای کار میکند. نام این ابزار debsums است.
کاربرد
sudo apt install debsums
sudo debsums -cپرچم -c تنها فایلهایی را چاپ میکند که با مرجع همخوان نبودهاند. بدون آن خروجی گزارشی سطربهسطر از هر فایل سامانه است، دهها هزار سطر.
بررسی چند دقیقه طول میکشد و دیسک را بار میگذارد، پس روی سروری که کار میکند ارزش دارد با اولویت پایین اجرا شود:
sudo ionice -c3 nice -n19 debsums -cنتیجه را چگونه بخوانیم
خروجی تهی یعنی هر فایل بررسیشده با آنچه توزیع نصب کرده همخوان است. خروجی ناتهی نیاز به بررسی دارد، و یافتهها در دو دسته بسیار متفاوت جای میگیرند.
فایلهای پیکربندی در /etc. تغییردادنشان کار عادی است: sshd_config را ویرایش کردهاید، nginx را تنظیم کردهاید، پارامترهای هسته افزودهاید. چنین تفاوتهایی انتظار میرود. و برای اینکه زیر پایتان نپیچند حالتی جداگانه هست:
sudo debsums -e -c-e تنها فایلهای پیکربندی را بررسی میکند — گاهی برای دیدن فهرست همه آنچه روی این ماشین تغییر دادهاید سودمند است.
فایلهای اجرایی و کتابخانهها. تفاوت در /usr/bin، /usr/sbin، /bin یا /usr/lib همان است که بررسی برایش اجرا شده. علتهای مشروع هست اما نه چندان: فایل هنگام عیبیابی با دست ویرایش شده، وصلهای از شخص ثالث اعمال شده، یا بسته هنگام بررسی در حال ارتقا بوده. اگر هیچکدام نمیخواند، وقت بررسی جدی است.
هدفهای کلاسیک جایگزینی ls، ps، netstat، ss، find و sshd هستند. نسخه جایگزینشده سطرهای مهم را از خروجی خودش پنهان میکند، و هر بررسی بعدی شما از گفتن حقیقت بازمیماند.
پوشش ناقص است — و باید این را بدانید
محدودیتی که معمولاً از آن یاد نمیشود: همه بستهها جمع کنترلی نمیفرستند. فایلهای چنین بستههایی اصلاً بررسی نمیشوند و تحت هیچ شرایطی در گزارش پیدا نخواهند شد. فهرست را چنین میبینید:
sudo debsums -lپس گزارش پاک debsums یعنی «در بخشی که بررسی شد همهچیز خوب است»، نه «سامانه دستکاری نشده». همین درباره هر چیزی که بیرون از مدیر بسته نصب شده صادق است: آنچه از کد منبع کامپایل شده، آنچه همچون فایل دودویی دانلود شده، آنچه با اسکریپتی از سایت توسعهدهنده نصب شده — debsums بنا بر تعریف هیچکدام را پایش نمیکند، و AIDE دقیقاً اینجا لازم است.
اجرای منظم
این بسته وظیفهای آماده دارد که در /etc/default/debsums فعال میشود:
CRON_CHECK=weeklyهفتهای یکبار بسامد معقولی است: بررسی دیسک را آشکارا بار میگذارد و فایلهای سامانه میان بهروزرسانیها بهندرت تغییر میکنند. اجرای روزانه جز بار چیزی نمیافزاید.
اگر فایلی واقعاً جایگزین شده باشد
نخستین انگیزه نصب دوباره بسته و بازگرداندن نسخه اصلی است:
sudo apt install --reinstall coreutilsاین فرمان درست است، اما نه همچون نخستین کار. فایل دودویی سامانهای جایگزینشده یعنی کسی root داشته است، و بازگرداندن فایل آن مسئله را حل نمیکند — تنها ردها را نابود میکند. ترتیب باید وارونه باشد: نخست رونوشتی از فایل مشکوک و زمان تغییرش نگه دارید، ببینید در همان بازه چه چیز دیگری تغییر کرده، و وظایف cron و کلیدهای SSH و فهرست کاربران را بررسی کنید. بازگرداندن تنها پس از اینهاست.
و ارزش دارد مرزهای این روش را هم به یاد داشته باشید: اگر سامانه عمیقاً به خطر افتاده باشد، خود debsums و کتابخانههایی که به کار میبرد نیز ممکن است همراه بقیه جایگزین شده باشند. بررسی از درون تضمین مطلق نمیدهد — آن را راهاندازی از رسانه بیرونی میدهد. با این حال برای کار روزمره همین بس است: اکثریت قاطع حملهها خودکارند و چندان پیچیده نیستند.
جایگاهش در تصویر کلی
debsums از آن رو خوب است که چیزی نمیخواهد و بیدرنگ کار میکند — و همین آن را نقطه آغاز مناسبی برای سروری میکند که تاریخچهاش را نمیدانید. ضعفش پوشش ناقص و ناآگاهی از هر چیزی است که بیرون از بستهها نصب شده. و جفتِ «debsums بهعلاوه AIDE» هر دو سو را میبندد: مرجع آماده توزیع برای فایلهای سامانه، و تصویر لحظهای خودتان برای بقیه.
و چون همیشه، معنا در اجراکردنش نیست بلکه در آن است که آخرین نتیجه همراه تاریخش پیش چشم باشد. شکل این را نمایش پایین نشان میدهد.