14.3.1. مانیتورینگ گزارش‌ها با استفاده از logcheck
برنامه logcheck به صورت پیشفرض در هر ساعت به فایل‌های گزارش نظارت کرده و پیام‌های گزارش غیر معمول را از طریق ایمیل به مدیر سیستم برای تحلیل بیشتر ارسال می‌کند.
فهرستی از فایل‌های نظارت شده در /etc/logcheck/logcheck.logfiles ذخیره‌سازی می‌گردد؛ مقادیر پیشفرض در صورتی کار می‌کنند که فایل /etc/rsyslog.conf به صورت کامل بازسازی نشده باشد.
logcheck می‌تواند در یکی از سه حالت موجود کار کند: paranoid، server و workstation. حالت اول شامل جزئیات بسیاری است که تنها باید در مورد سرورهایی نظیر فایروال استفاده گردد. حالت دوم (و پیشفرض) برای اکثر سرورها توصیه می‌شود. حالت آخر نیز در مورد رایانه‌های رومیزی کاربرد دارد که شامل جزئیات کمتری می‌شود (پیام‌های بیشتری را فیلتر می‌کند).
در هر سه مورد، logcheck به منظور پیشگیری از پیام‌های اضافی باید سفارشی‌سازی گردد (مبتنی بر سرویس‌های نصب شده)، مگر اینکه مدیر سیستم بخواهد به صورت ساعتی فهرستی از ایمیل‌های طولانی و ناخواسته را مشاهده کند. از آنجا که مکانیزم انتخاب پیام به قدری پیچیده است، مطالعه /usr/share/doc/logcheck-database/README.logcheck-database.gz به شدت توصیه می‌شود.
قوانین اعمال شده می‌توانند به چندین نوع تقسیم شوند:
آن‌هایی که صلاحیت یک پیام را به عنوان تلاش برای نفوذ در نظر می‌گیرند (که در دایرکتوری /etc/logcheck/cracking.d/ ذخیره‌سازی می‌شوند)؛
آن‌هایی که این صلاحیت را نادیده می‌گیرند (/etc/logcheck/cracking.ignore.d/)؛
آن‌هایی که یک پیام را به عنوان هشدار امنیتی طبقه‌بندی می‌کنند (/etc/logcheck/violations.d/)؛
آن‌هایی که این طبقه‌بندی را نادیده می‌گیرند (/etc/logcheck/violations.ignore.d/)؛
در نهایت، آن‌هایی که به پیام‌های باقیمانده اعمال می‌شوند (که به عنوان رویدادهای سیستمی شناخته می‌شوند).
یک رویداد سیستمی همیشه ارسال می‌شود مگر یکی از قوانین موجود در دایرکتوری‌های /etc/logcheck/ignore.d.{paranoid,server,workstation}/ بگوید که این رویداد نادیده گرفته شود. البته، تنها دایرکتوری‌هایی به حساب می‌آیند که سطح گزارش برابر یا بیشتر از حالت عملیاتی انتخابی داشته باشند.
14.3.2. فعالیت مانیتورینگ
top یک ابزار تعاملی است که فهرستی از فرآیندهای در حال اجرا را نمایش می‌دهد. مرتب‌سازی پیشفرض آن مبتنی بر میزان استفاده فعلی از پردازنده است که می‌تواند با کلید P مشخص گردد. سایر انواع مرتب‌سازی شامل حافظه مصرفی (کلید M)، زمان کلی پردازنده (کلید T) و شناسه فرآیند (کلید N) می‌باشند. کلید k اجازه نابودی یک فرآیند با وارد کردن شناسه‌اش را فراهم می‌کند. کلید r امکان renice یک فرآیند را فراهم می‌کند، که همان تغییر اولویت در اجرا است.
زمانی که سیستم به نظر سنگین میآید، top ابزار مناسبی برای شناسایی فرآیندهایی است که بیشترین زمان پردازنده یا بیشترین حافظه مصرفی را دارا می‌باشند. به طور مشخص، اغلب بررسی اینکه آیا فرآیندهای موجود با سرویس‌های متناظر در ماشین سازگاری دارند یا خیر کار جالبی است. یک فرآیند ناشناخته که به عنوان کاربر www-data اجرا شده است باید مورد بررسی و تحلیل قرار گیرد، چرا که به احتمال زیاد یک نمونه از نرم‌افزاری است که توسط آسیب‌پذیری موجود در یک برنامه وب نصب شده است.
top ابزار بسیار منعطفی است و صفحه راهنمای آن جزئیات بیشتری را درباره سفارشی‌کردن برای نیازهای خاص کاربر نمایش می‌دهد.
ابزار گرافیکی gnome-system-monitor مشابه با top بوده که تقریبا همان ویژگی‌ها را فراهم می‌کند.
بار پردازنده، ترافیک شبکه و فضای آزاد دیسک اطلاعاتی هستند که به صورت مداوم در حال تغییر می‌باشند. نگهداری تاریخچه‌ای از میزان مصرف آن‌ها درک خوبی از چگونگی کارکرد رایانه را در اختیار ما قرار می‌دهد.
ابزار اختصاصی متفاوتی برای این منظور وجود دارد. اغلب آن‌ها می‌توانند با استفاده از SNMP یا Simple Network Management Protocol اطلاعات را به صورت مرکزی دریافت کنند. یک مزیت اینکار دریافت داده از عناصر شبکه‌ای است که رایانه‌های همه منظوره به حساب نمی‌آیند، از جمله مسیریاب‌ها یا سوئیچ‌های شبکه.
این کتاب به Munin و برخی جزئیات آن (
قسمت 12.4.1, “راه‌اندازی Munin”
را مشاهده کنید) که قسمتی از
فصل 12: “مدیریت پیشرفته” است می‌پردازد. دبیان نیز ابزار مشابهی فراهم کرده است،
cacti. توسعه آن پیچیدگی خاص خود را دارد، چرا که به طور انحصاری بر اساس SNMP کار می‌کند. بر خلاف وجود رابط وب، درک مفاهیم موجود در پیکربندی آن به تلاش زیادی نیاز دارد. از این رو مطالعه مستندات آن (
/usr/share/doc/cacti/html/index.html) یک پیشنیاز به حساب میآید.
زمانی که سیستم نصب و پیکربندی می‌شود، با در نظر گرفتن بروزرسانی‌های امنیتی، دلیلی برای تغییر اکثر فایل‌ها و دایرکتوری‌ها، بجز آن‌ها که از نوع داده‌ای هستند، وجود ندارد. پس اطمینان حاصل کردن از اینکه فایل‌ها تغییر نمی‌کنند امری جالب است: هر تغییر ناخواسته باید مورد بررسی و تحقیق قرار بگیرد. این بخش برخی ابزار کاربردی را برای مانیتور کردن فایل‌ها و هشدار به مدیر سیستم در صورت تغییر ناگهانی آن‌ها معرفی می‌کند.
14.3.3.1. بازرسی بسته‌ها با استفاده از dpkg --verify
dpkg --verify یا dpkg -V ابزار جالبی است چرا که امکان جستجوی فایل‌های تغییر یافته از زمان نصب را فراهم می‌کند (که احتمالا توسط مهاجم تغییر یافته‌اند) اما اینکار باید با احتیاط بیشتری صورت پذیرد. برای اینکه بتواند کار خود را انجام دهد نیازمند checksum ذخیره‌سازی شده در پایگاه‌داده dpkg روی هارد دیسک می‌باشد (این فایل‌ها می‌توانند در /var/lib/dpkg/info/package.md5sums پیدا شوند)؛ یک مهاجم بالقوه با بروزرسانی این فایل‌ها از تشخیص فایل‌های تغییر یافته جلوگیری بعمل می‌آورد.
اجرای dpkg -V تمام بسته‌های نصب شده را مورد بررسی قرار داده و به ازای هر کدام که در این آزمون شکست بخورند در خط جداگانه‌ای نمایش داده می‌شود. قالب خروجی مشابه با rpm -V است که در آن هر کاراکتر بیانگر یک آزمون روی اطلاعات جانبی بسته است. متاسفانه dpkg اطلاعات جانبی مورد نیاز بسته را ذخیره‌سازی نمی‌کند و آن‌ها را به صورت علامت سوال در خروجی نمایش می‌دهد. در حال حاضر تنها آزمون checksum منجر به تولید "5" در سومین کاراکتر آن (زمانی که شکست بخورد) می‌شود.
# dpkg -V
??5?????? /lib/systemd/system/ssh.service
??5?????? c /etc/libvirt/qemu/networks/default.xml
??5?????? c /etc/lvm/lvm.conf
??5?????? c /etc/salt/roster
در نمونه بالا، dpkg یک تغییر در فایل سرویس SSH را گزارش می‌دهد که مدیر سیستم در مورد فایل بسته اعمال کرده است بجای تغییر در فایل پیکربندی آن واقع در /etc/systemd/system/ssh.service (که مانند هر فایل پیکربندی دیگر در /etc ذخیره‌سازی می‌شود). همچنین فهرستی از فایل‌های پیکربندی دیگر که به صورت قانونی تغییر یافته‌اند را با حرف "c" در فیلد دوم نمایش می‌دهد.
14.3.3.2. بازرسی بسته‌ها: debsums و محدودیت‌های آن
debsums جد dpkg -V به حساب میآید و از این رو منسوخ شده است. از همان محدودیت‌های dpkg نیز رنج می‌برد. خوشبختانه می‌توان به برخی محدودیت‌های آن غلبه کرد، با اینکه dpkg راهکاری برای آن‌ها ندارد.
از آنجا که نمی‌توان به داده روی دیسک اعتماد کرد، debsums پیشنهاد می‌کند که بجای پایگاه‌داده dpkg از فایل‌های .deb به منظور آزمون استفاده شود. برای دانلود فایل‌های .deb بسته‌های نصب شده، می‌توان روی مکانیزم احرازهویت APT حساب باز کرد. این عملیات می‌تواند کند و خسته‌کننده باشد، پس نباید به عنوان تکنیکی موثر به صورت روزانه مورد استفاده قرار گیرد.
# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package`
[ ... ]
# debsums -p /var/cache/apt/archives --generate=all
به یاد داشته باشید که در این مثال از دستور grep-status واقع در بسته dctrl-tools استفاده شده است، که به صورت پیشفرض نصب نمی‌باشد.
14.3.3.3. مانیتورینگ فایل‌ها: AIDE
ابزار AIDE یا Advanced Intrusion Detection Environment امکان بررسی جامعیت فایل را فراهم می‌کند و هرگونه تغییر مقابل image نسخه پیشین از سیستم معتبر را تشخیص می‌دهد. این image به عنوان یک پایگاه‌داده ذخیره‌سازی می‌شود (/var/lib/aide/aide.db) که شامل اطلاعات مرتبط درباره تمام فایل‌های سیستم است (اثرانگشت‌ّها، مجوزها، بازه‌های زمانی و از این قبیل). این پایگاه‌داده ابتدا توسط aideinit راه‌اندازی می‌شود؛ سپس به صورت روزانه توسط اسکریپت /etc/cron.daily/aide به منظور بررسی برای عدم تغییر فایل‌های مرتبط استفاده می‌گردد. زمانی که تغییر تشخیص داده شود، AIDE آن‌ها را در فایل‌های گزارش (/var/log/aide/*.log) ثبت کرده و مشاهدات خود ار از طریق ایمیل برای مدیر سیستم ارسال می‌کند.
گزینه‌های بسیاری در /etc/default/aide وجود دارد که می‌تواند برای تغییر عملکرد بسته aide مورد استفاده قرار گیرد. فایل‌های پیکربندی AIDE در /etc/aide/aide.conf و /etc/aide/aide.conf.d/ ذخیره‌سازی شده‌اند (در حقیقت، این فایل‌ها تنها توسط update-aide.conf برای تولید /var/lib/aide/aide.conf.autogenerated مورد استفاده قرار می‌گیرند). پیکربندی شامل ویژگی‌های خاص هر فایل می‌باشد که باید مورد بررسی قرار گیرند. برای نمونه، محتوای فایل‌های گزارش به صورت مداوم تغییر می‌یابد و اینگونه تغییرات مادامی که مجوزهای این فایل‌ها تغییر نکند می‌توانند نادیده گرفته شوند، اما هر دو محتوا و مجوزهای برنامه‌های اجرایی باید ثابت باقی بمانند. با اینکه ساختار پیچیده‌ای ندارد، شیوه نگارش پیکربندی آن نیز ساده نیست و مطالعه صفحه راهنمای aide.conf(5) توصیه می‌گردد.
یک نسخه جدید از پایگاه‌داده به صورت روزانه در /var/lib/aide/aide.db.new تولید می‌شود؛ اگر تمام تغییرات ثبت شده قانونی باشند، می‌تواند جایگزین پایگاه‌داده مرجع شود.
14.3.4. تشخیص نفوذ (IDS/NIDS)
suricata (در بسته‌ای با همین نام) یک NIDS که مخفف
Network Intrusion Detection System است یا سیستم تشخیص نفوذ شبکه‌ای به حساب میآید. وظیفه آن گوش دادن به شبکه و تشخیص تلاش‌های نفوذ احتمالی و/یا اقدامات خرابکارانه است (از جمله حملات DoS). تمام این رویدادها در فایل‌های گوناگون موجود در
/var/log/suricata به صورت گزارش ذخیره‌سازی می‌شوند. ابزار شخص ثالث دیگری مانند Kibana یا logstash وجود دارد که برای پیمایش بهتر این داده‌ها بکار می‌روند.
پیکربندی suricata شامل بازبینی و ویرایش فایل /etc/suricata/suricata-debian.yaml است، که بسیار طولانی بوده و هر پارامتر آن به صورت مفصل توضیح داده شده است. یک پیکربندی حداقلی نیازمند محدوده نشانی‌هایی است که شبکه محلی آن‌ها را پوشش می‌دهد (پارامتر HOME_NET). در عمل، این به معنی مجموعه اهداف قابل حمله است. اما استفاده از آن نیازمند درک کامل ویژگی‌ها و منطبق ساختن با وضعیت محلی است.
قبل از آن، باید فایل /etc/default/suricata را برای تعریف رابط شبکه به منظور مانیتورینگ ویرایش کرده و اسکریپت راه‌اندازی آن را فعال کنید (با تنظیم RUN=yes). البته شاید بخواهید LISTENMODE=pcap را انجام دهید چرا که تنظیم پیشفرض LISTENMODE=nfqueue نیازمند پیکربندی پیچیده‌تری است (فایروال netfilter باید طوری پیکربندی شود که بسته‌های فضای کاربر از طرف suricata و با استفاده از NFQUEUE مدیریت شوند).
برای تشخیص عملکرد بد، suricata نیازمند مجموعه‌ای از قوانین مانیتورینگ است: چنین قوانینی را می‌توانید در بسته snort-rules-default پیدا کنید. snort مرجع تاریخی در اکوسیستم IDS به حساب میآید و suricata می‌تواند از قوانین موجود آن استفاده کند. متاسفانه این بسته در نسخه Jessie از دبیان وجود نداشته و باید از طریق انتشار Testing یا Unstable بدست آید.
به صورت جایگزین از oinkmaster (در بسته‌ای با همین نام) می‌توان برای دانلود مجموعه قوانین Snort از منابع خارجی استفاده کرد.
