وقتی فایل سرور عوض شده اما کسی تغییر را به یاد نمی‌آورد
در یک سرویس حسابداری، صبح بعد از به روز رسانی سیستم عامل چند فایل پیکربندی تغییر کرده اند. بخشی از تغییرها حاصل نصب بسته جدید است، اما مجوز یک پوشه نیز بازتر شده و یک فایل اجرایی ناشناس کنار برنامه قرار گرفته است. مدیر سرور باید بفهمد چه چیزی تغییر کرده، کدام تغییر انتظار می رفته و کدام مورد به بررسی فوری نیاز دارد. AIDE برای پاسخ به بخش نخست این مسئله ساخته شده است. این برنامه از ویژگی های انتخاب شده فایل ها یک پایگاه مرجع می سازد و وضعیت بعدی را با آن مقایسه می کند.
نام کامل پروژه Advanced Intrusion Detection Environment است. معرفی رسمی آن بر پایش تغییرهای فایل سیستم تأکید دارد. مالک، گروه، مجوز، اندازه، زمان ها و چکیده محتوا از اطلاعاتی هستند که بسته به پیکربندی و قابلیت های ساخت می توان بررسی کرد. خروجی برنامه شواهد تغییر را ارائه می دهد. تبدیل این شواهد به نتیجه امنیتی به شناخت برنامه، تاریخچه نگهداری و بررسی انسان وابسته است. تغییر در یک کتابخانه ممکن است اصلاح امنیتی مورد انتظار باشد و ثابت ماندن تمام فایل های پایش شده نیز به تنهایی سلامت کل میزبان را ثابت نمی کند.
مرجع سالم را پیش از حادثه بسازید
ارزش پایگاه مرجع از زمانی آغاز می شود که بتوان به وضعیت ثبت شده اعتماد کرد. برای مثال، پس از نصب سیستم عامل از منبع معتبر، اعمال تنظیمات اولیه و آزمون سرویس، می توان نخستین مرجع را ساخت. اگر سرور از قبل مشکوک باشد، ثبت وضعیت فعلی ممکن است فایل آلوده را به عنوان وضعیت پذیرفته شده نگه دارد. در چنین شرایطی ابتدا باید وضعیت میزبان با بسته های معتبر و شواهد مستقل بررسی شود. AIDE گذشته ای را که ثبت نشده بازسازی نمی کند.
برای هر مرجع شناسه میزبان، تاریخ، نسخه برنامه، نسخه تنظیمات و شناسه تغییر عملیاتی را نگه دارید. این اطلاعات بعداً روشن می کنند چرا دو گزارش متفاوت هستند. در یک گروه سرور مشابه، نام یکسان فایل کافی نیست. نسخه بسته ها و نقش میزبان ممکن است متفاوت باشد. بهتر است برای هر میزبان مرجع مشخص داشته باشید یا فرایند ساخت ایمیج را چنان مستند کنید که ارتباط مرجع مشترک با هر نمونه نصب شده قابل اثبات باشد.
پایگاه مرجع و تنظیمات باید در برابر همان حسابی که ممکن است روی میزبان آسیب ببیند محافظت شوند. نسخه ای که فقط روی دیسک همان سرور قرار دارد، در صورت دسترسی گسترده مهاجم می تواند تغییر کند. نگهداری نسخه مستقل، کنترل دسترسی و ثبت چکیده فایل مرجع در محل جداگانه، امکان مقایسه بعدی را تقویت می کند. هدف عملی آن است که کسی نتواند هم فایل برنامه و هم سند وضعیت مورد انتظار آن را بی سر و صدا عوض کند.
دامنه پایش را بر اساس رفتار فایل انتخاب کنید
یک تنظیم عمومی که تمام دیسک را با یک قاعده بررسی کند معمولاً گزارش پرسر و صدایی تولید می کند. فایل اجرایی برنامه، تنظیمات وب سرور، گزارش روزانه و فایل موقت مرورگر رفتار یکسانی ندارند. فایل اجرایی باید فقط هنگام انتشار تغییر کند. گزارش سرویس به طور طبیعی رشد می کند. پوشه موقت نیز دائماً ایجاد و حذف فایل دارد. پیش از نوشتن قواعد، این گروه ها را جدا کنید و برای هر کدام انتظار مشخص بنویسید.
در مثال حسابداری، پوشه نصب برنامه و تنظیمات دسترسی اهمیت بالایی دارند. گزارش تراکنش و پوشه بارگذاری کاربران را باید جدا بررسی کرد، زیرا محتوای آنها بخشی از فعالیت عادی است. این جداسازی به معنای بی اهمیت دانستن داده های کاربران نیست. برای آن داده ها کنترل های دیگری مانند ثبت رویداد، نسخه بندی یا اعتبارسنجی برنامه مناسب تر است. AIDE هنگامی بیشترین فایده را دارد که تغییر غیرمنتظره از تغییر طبیعی قابل تفکیک باشد.
قواعد انتخاب مسیر در AIDE بر تطبیق مسیرها متکی هستند و دقت نوشتن الگو اهمیت دارد. یک استثنای بیش از حد گسترده می تواند زیرپوشه حساس را هم کنار بگذارد. پیش از اجرای سراسری، مجموعه کوچکی از مسیرهای نمونه بسازید. فایل مورد انتظار، فایل با نام مشابه و فایل در زیرپوشه مجاور را بررسی کنید. نتیجه باید نشان دهد که دامنه قاعده با قصد نویسنده مطابقت دارد. توضیح کوتاه کنار هر استثنا، بازبینی چند ماه بعد را بسیار آسان تر می کند.
از چکیده محتوا تا مجوز دسترسی
مقایسه محتوا تنها یکی از لایه های بررسی است. ممکن است محتوای یک فایل ثابت بماند اما مالک آن عوض شود یا مجوز نوشتن برای گروه دیگری باز شود. چنین تغییری می تواند مسیر تغییر بعدی برنامه را فراهم کند. به همین دلیل برای فایل های حساس، ویژگی های دسترسی و نوع فایل نیز باید در سیاست لحاظ شوند. انتخاب دقیق ویژگی ها به سیستم عامل، فایل سیستم و قابلیت های نسخه نصب شده وابسته است.
از سوی دیگر، تغییر زمان اصلاح به تنهایی به معنای تغییر محتوای خطرناک نیست. برخی فرایندهای نصب یا انتقال فایل، زمان ها را بازنویسی می کنند. گزارش را به صورت مجموعه ای از ویژگی ها بخوانید. اگر چکیده محتوا ثابت است ولی زمان تغییر کرده، پرسش تحقیق با حالتی که محتوای فایل اجرایی عوض شده متفاوت است. این تفکیک به تیم کمک می کند زمان خود را بر اختلاف هایی متمرکز کند که اثر بیشتری بر اعتماد به سرویس دارند.
برای انتخاب الگوریتم چکیده، گزینه های مستند نسخه جاری را بررسی کنید و از سیاست رمزنگاری سازمان پیروی کنید. نمونه های قدیمی مستندات ممکن است نام الگوریتم هایی را نشان دهند که برای تصمیم جدید مناسب نیستند. در متن تنظیمات، انتخاب الگوریتم و دلیل آن را ثبت کنید. همچنین بررسی کنید که بسته نصب شده واقعاً قابلیت مورد نظر را دارد. یک فایل تنظیمات مشترک نباید بی بررسی به میزبان هایی با ساخت متفاوت منتقل شود.
آزمون کوچک پیش از زمان بندی
نخست روی یک پوشه آزمایش چند فایل بسازید. وضعیت اولیه را ثبت کنید، محتوای یکی را عوض کنید، دیگری را حذف کنید و مجوز سومی را تغییر دهید. سپس مقایسه را اجرا کنید و ببینید هر تغییر در گزارش چگونه نمایش داده می شود. این تمرین هم صحت پیکربندی را نشان می دهد و هم خواندن گزارش را به مسئول شیفت آموزش می دهد. برای این آزمون نیازی به تغییر فایل واقعی سرویس نیست.
یک آزمون دیگر باید شکست فرایند را پوشش دهد. اگر فایل مرجع خوانده نشود، دیسک پر شود یا مسیر مورد نظر در دسترس نباشد، سامانه پایش مرکزی باید خطای اجرا را دریافت کند. نبود گزارش تغییر با اجرای موفق و بدون اختلاف یکسان نیست. در زمان بندی، وضعیت خروج و پیام خطا را نگه دارید تا سکوت ابزار به اشتباه نشانه سلامت تلقی نشود. زمان آغاز و پایان اسکن نیز برای تشخیص اجرای ناقص مفید است.
اسکن محتوای فایل های بزرگ هزینه ورودی و خروجی دارد. زمان اجرا را در شرایط واقعی اندازه بگیرید و آن را با بار سرویس مقایسه کنید. اگر عملیات شبانه دیگری مانند پشتیبان گیری همان دیسک را درگیر می کند، برنامه زمانی را هماهنگ کنید. هدف، داشتن بررسی منظم و قابل اتکا است. اسکن بسیار سنگینی که مرتب لغو می شود از بررسی محدود اما منظم ارزش عملی کمتری دارد.
گزارش تغییر را به درخواست بررسی تبدیل کنید
برای هر اختلاف مهم، یک پرونده کوتاه با مسیر فایل، ویژگی تغییر کرده، زمان مشاهده و شناسه میزبان ایجاد کنید. سپس آن را با تقویم انتشار و درخواست های نگهداری تطبیق دهید. اگر تغییر ناشی از بسته جدید است، نام و نسخه بسته و تأیید مسئول انتشار را ثبت کنید. عبارت کلی «احتمالاً به روز رسانی بوده» برای بستن پرونده کافی نیست، زیرا در بررسی بعدی قابل ارزیابی نخواهد بود.
هنگام مشاهده فایل اجرایی ناشناس، اجرای آن برای فهمیدن کاربردش انتخاب مناسبی نیست. ابتدا اطلاعات فایل را از یک محیط مورد اعتماد بررسی کنید و نسخه لازم برای تحلیل را با روش مصوب نگه دارید. اگر احتمال دستکاری ابزارهای خود میزبان وجود دارد، نتیجه فرمان های محلی را تنها شاهد قرار ندهید. گزارش AIDE می تواند نقطه شروع بررسی باشد، اما تصمیم درباره جداسازی میزبان و جمع آوری شواهد باید با روند پاسخ به رخداد سازمان هماهنگ شود.
بعضی تغییرها نتیجه اشتباه خود تیم هستند. برای نمونه، اسکریپت استقرار ممکن است پس از کپی فایل، مجوزها را به مقدار نادرست بازگرداند. در این حالت اصلاح فایل فعلی کافی نیست. باید اسکریپت نیز اصلاح و در انتشار بعدی آزموده شود. پیوند دادن اختلاف AIDE به علت عملیاتی، از تکرار همان هشدار جلوگیری می کند و ابزار را از تولیدکننده گزارش به بخشی از فرایند نگهداری قابل اعتماد تبدیل می کند.
به روز کردن مرجع یک تصمیم است
پس از انتشار مجاز، مرجع باید با وضعیت تأیید شده جدید هماهنگ شود. این کار را بعد از بررسی اختلاف ها انجام دهید. پذیرفتن خودکار همه تغییرهای مشاهده شده می تواند دقیقاً همان موردی را که باید بررسی می شد از دید خارج کند. بهتر است تغییر مرجع به شناسه انتشار متصل باشد و گزارش قبل از پذیرش نیز نگهداری شود. در این صورت می توان فهمید چه چیزی، چه زمانی و با تأیید چه فرایندی به وضعیت مورد انتظار تبدیل شده است.
اگر انتشار شکست خورد و برنامه به نسخه قبلی برگشت، مرجع نیز باید با نسخه واقعی سرویس سازگار باشد. این موضوع در استقرارهای رفت و برگشتی اهمیت دارد. نگهداری چند مرجع با نام و تاریخ روشن، مقایسه را آسان می کند. هیچگاه صرفاً به نام «آخرین مرجع» تکیه نکنید. شناسه ساخت برنامه و نسخه تنظیمات باید نشان دهند که مرجع برای کدام وضعیت تهیه شده است.
معیار موفقیت در بهره برداری
برای ارزیابی AIDE تعداد هشدار را تنها معیار نگذارید. ببینید چند تغییر غیرمنتظره به علت مشخص رسیده، چه مقدار از دامنه حساس واقعاً پوشش دارد و آیا گزارش ها در زمان تعیین شده بررسی می شوند. یک گزارش کوتاه و قابل پیگیری می تواند مفیدتر از هزاران اختلاف بی صاحب باشد. همچنین آزمون تغییر کنترل شده را به صورت دوره ای تکرار کنید تا مسیر کامل از فایل تا دریافت هشدار همچنان سالم باشد.
در پایان هر دوره نگهداری، استثناها، مسیرهای جدید برنامه و مسئول دریافت گزارش را بازبینی کنید. با جابه جایی سرویس ممکن است پوشه حساس تازه ای خارج از قواعد باقی بماند. با خروج یک همکار ممکن است اعلان ها به صندوقی بدون پاسخ بروند. کیفیت این سامانه به اندازه خود موتور مقایسه، به تازه ماندن همین ارتباط های عملیاتی وابسته است. AIDE وقتی به نتیجه می رسد که هر اختلاف مهم به تصمیم ثبت شده منتهی شود.
