ClamAV چه مسئله‌ای را حل می‌کند؟
ClamAV مجموعه‌ای متن‌باز برای تشخیص محتوای مخرب در فایل است. استفاده شناخته‌شده آن در درگاه ایمیل است، اما می‌توان آن را در جریان دریافت اسناد، مخزن فایل و فرایند بررسی پیوست نیز به کار گرفت. این ابزار فایل را تحلیل می‌کند و نتیجه‌ای قابل مصرف برای برنامه دیگر می‌دهد. مدیر سامانه باید مشخص کند پس از تشخیص چه اتفاقی می‌افتد. نتیجه مثبت به تنهایی فایل را از همه مسیرهای دسترسی خارج نمی‌کند و نتیجه منفی نیز گواه بی‌خطر بودن محتوا نیست. این تفاوت برای طراحی درگاه بارگذاری اهمیت زیادی دارد: اسکن یک کنترل است و جای محدودیت نوع فایل، اعتبارسنجی ساختار یا جداسازی محل ذخیره را نمی‌گیرد.
در مستندات رسمی ClamAV میان ابزار اسکن خط فرمان، سرویس اسکن و برنامه به‌روزرسانی پایگاه تشخیص تفکیک شده است. برنامه clamscan برای اجرای مستقل مناسب است؛ clamd موتور را به صورت سرویس در حافظه نگه می‌دارد و برای بار تکراری مفید است؛ freshclam پایگاه تشخیص را به‌روز می‌کند. این نام‌ها سه نقش متفاوت را نشان می‌دهند. نصب شدن یکی از اجزا یا فعال بودن سرویس لزوماً به معنای تازه بودن امضاها یا موفق بودن آخرین اسکن نیست. پایش باید سلامت هر نقش را جداگانه نشان دهد.
طراحی جریان دریافت فایل
فرض کنید سامانه پشتیبانی، فایل‌های مشتری را دریافت می‌کند. طرح پیشنهادی این است که بارگذاری ابتدا به ناحیه‌ای با دسترسی محدود برود. فایل هنوز نباید در نشانی عمومی قرار گیرد و نباید توسط پردازشگرهای تولید اجرا یا باز شود. برنامه شناسه داخلی تولید می‌کند، اندازه و نوع مورد انتظار را ثبت می‌کند و کار اسکن را در صف می‌گذارد. پس از تکمیل بررسی، فقط نتیجه معتبر و قابل نسبت دادن به همان فایل اجازه انتشار می‌گیرد. این معماری فاصله زمانی میان دریافت فایل و رسیدن پاسخ اسکن را مدیریت می‌کند.
اگر اسکنر متوقف شد، برنامه نباید وضعیت نامعلوم را با نتیجه پاک اشتباه بگیرد. سیاست می‌تواند نگه داشتن فایل در انتظار، رد موقت درخواست یا ارجاع برای بررسی دستی باشد. انتخاب به نیاز کسب‌وکار وابسته است، اما باید آشکار و قابل آزمون باشد. استفاده از هش برای اتصال پاسخ به محتوای اسکن‌شده مفید است، زیرا نام فایل ممکن است دوباره استفاده شود یا فایل پیش از انتشار تغییر کند. تغییر محتوا پس از اسکن باید کار بررسی تازه‌ای ایجاد کند. ثبت شناسه کار، زمان، اندازه و نسخه پایگاه برای تحلیل خطا کافی‌تر از ثبت نام کاربر به تنهایی است.
در مسیر دریافت لازم است دسترسی حساب اسکنر محدود باشد. این حساب می‌تواند فایل مورد بررسی را بخواند، اما لزوماً به کل مخزن مشتریان، کلیدهای برنامه یا امکان اجرای فرایند جدید نیاز ندارد. اگر clamd از طریق سوکت محلی استفاده می‌شود، مجوز همان سوکت بخشی از مرز اعتماد است. اگر اتصال شبکه‌ای در نظر گرفته شده باشد، نباید فرض کرد سرویس اسکن یک رابط عمومی امن برای اینترنت است. اتصال را در شبکه کنترل‌شده و پشت محدودیت دسترسی نگه دارید و مستندات نسخه نصب‌شده را برای روش ارتباط بررسی کنید.
راه‌اندازی آزمایشی بدون آسیب به داده
آزمایش نخست باید روی پوشه‌ای از فایل‌های معمول و قابل بازتولید انجام شود. هدف این است که زمان اسکن، مصرف حافظه و رفتار گزارش را بفهمید. در مرحله اول گزینه حذف خودکار انتخاب مناسبی نیست. گزارش گرفتن یا انتقال کنترل‌شده به قرنطینه امکان بازگشت را حفظ می‌کند. فایل آزمایشی استاندارد EICAR می‌تواند برای بررسی مسیر هشدار استفاده شود، ولی باید از منبع رسمی دریافت شود و به مسئولان پایش اطلاع داده شود تا این آزمایش به عنوان رخداد واقعی تعبیر نشود. برای آزمودن جریان، نیازی به جمع‌آوری بدافزار زنده وجود ندارد.
یک آزمایش مفید شامل سه وضعیت است: فایل عادی، تشخیص آزمایشی و خطای اجرایی. وضعیت سوم اغلب فراموش می‌شود. می‌توان در محیط آزمایش یک مسیر غیرقابل خواندن یا فایل حذف‌شده پیش از اسکن را در نظر گرفت و دید برنامه چگونه پاسخ می‌دهد. اگر داشبورد فقط دو برچسب سالم و آلوده دارد، ممکن است خطای دسترسی را پنهان کند. وضعیت خطا باید مستقل باشد و دلیل قابل پیگیری داشته باشد. در آزمون صف نیز بررسی کنید که کار ناموفق دوباره اجرا می‌شود، اما بازاجرای نامحدود باعث پر شدن صف و مختل شدن درخواست‌های دیگر نمی‌شود.
پس از آزمون کوچک، مجموعه‌ای نماینده از فایل‌های واقعی با رعایت محرمانگی انتخاب کنید. میانگین زمان به تنهایی کافی نیست؛ چند فایل بزرگ یا آرشیو تو در تو می‌تواند تجربه کاربر را تعیین کند. اندازه فایل، عمق آرشیو و بودجه زمانی باید به سیاست روشن تبدیل شوند. محدود شدن تحلیل یک فایل نباید در گزارش نهایی محو شود. برنامه مصرف‌کننده باید بداند آیا تمام محتوای مورد انتظار بررسی شده یا بررسی در مرز تعیین‌شده متوقف شده است. توضیح قابل فهم برای کاربر نیز از تکرار بی‌فایده بارگذاری جلوگیری می‌کند.
تازه بودن امضا و تازه بودن موتور
به‌روزرسانی پایگاه تشخیص و ارتقای خود موتور دو عملیات متفاوت هستند. یک موتور قدیمی با پایگاه تازه لزوماً همه قابلیت‌های تحلیل نسخه جدید را ندارد. از سوی دیگر موتور تازه با پایگاه بسیار قدیمی نیز پوشش مناسبی ارائه نمی‌دهد. در عملیات روزمره، زمان آخرین به‌روزرسانی موفق، خطاهای دریافت و زمان آخرین اسکن موفق را ثبت کنید. قطع شبکه، خطای پراکسی یا مشکل ساعت سیستم می‌تواند مسیر دریافت را مختل کند. صرف روشن بودن فرایند freshclam اثبات نمی‌کند آخرین دریافت موفق بوده است.
برای محیط دارای محدودیت خروجی شبکه، ابتدا روش مورد پشتیبانی پروژه و توزیع را بررسی کنید. کپی دستی فایل امضا از یک منبع ناشناس راه‌حل قابل اعتماد نیست. اگر مخزن داخلی یا فرایند انتقال کنترل‌شده ساخته می‌شود، منشأ فایل و تاریخ دریافت باید حفظ شود. همچنین آزمون کنید وقتی پایگاه جدید بارگذاری می‌شود چه اثری روی حافظه، صف و زمان پاسخ ایجاد می‌کند. این موضوع در میزبان کوچک یا زمانی که چند کار هم‌زمان اجرا می‌شود اهمیت بیشتری پیدا می‌کند. ظرفیت‌سنجی باید پنجره به‌روزرسانی را نیز پوشش دهد.
خواندن تشخیص و کاهش خطای مثبت
یک نام تشخیص ممکن است به خانواده بدافزار، الگوی مشکوک یا محدودیت تحلیل اشاره کند. پاسخ مناسب از روی نام کوتاه به تنهایی تعیین نمی‌شود. مسئول بررسی باید فایل، منشأ دریافت، کاربرد ادعاشده و نتیجه سایر کنترل‌ها را کنار هم بگذارد. گاهی یک ابزار مدیریتی مجاز یا فایل آزمایش امنیتی با الگوی عمومی تطبیق پیدا می‌کند. در چنین وضعیتی استثنای گسترده برای کل پوشه یا همه فایل‌های یک مشتری راه‌حل مطلوبی نیست. استثنا باید حداقل دامنه، مسئول و تاریخ بازبینی داشته باشد تا یک تشخیص اشتباه به نقطه کور دائمی تبدیل نشود.
برای بررسی خطای مثبت، ابتدا نسخه موتور و پایگاه، هش فایل و متن کامل گزارش را نگه دارید. اگر گزارش به پروژه ارسال می‌شود، پیش از بارگذاری محتوا به سامانه بیرونی مالکیت و محرمانگی فایل را بررسی کنید. فایل قرارداد مشتری یا سند هویتی نباید صرفاً برای رفع یک هشدار به خدمات عمومی فرستاده شود. در بسیاری از موارد می‌توان با اطلاعات فنی غیرمحرمانه یا نمونه بازتولیدشده شروع کرد. نتیجه بررسی باید در یادداشت تصمیم ثبت شود تا تیم بعدی مجبور نباشد همان تحلیل را از ابتدا انجام دهد.
قرنطینه و بازیابی
قرنطینه صرفاً تغییر نام فایل نیست. محل قرنطینه باید از سرویس عمومی و مسیر اجرای برنامه جدا باشد، دسترسی محدودی داشته باشد و چرخه نگهداری آن معلوم باشد. بهتر است نام اصلی، شناسه درخواست و دلیل انتقال در فراداده نگه داشته شود، اما خود فایل با نام داخلی ذخیره شود تا کاربر با حدس زدن نشانی به آن دسترسی پیدا نکند. اگر تیم عملیات امکان بازیابی دارد، این عمل باید ثبت شود. بازیابی پس از تأیید نیز بهتر است به جریان بررسی برگردد، نه اینکه همه کنترل‌ها را دور بزند.
حذف قطعی باید سیاست مستقلی داشته باشد. برای فایل‌هایی که از نظر قانونی یا قراردادی نیاز به نگهداری دارند، پاک کردن خودکار پس از تشخیص ممکن است مشکل تازه ایجاد کند. در مقابل نگهداری بی‌پایان همه فایل‌های مشکوک نیز هزینه و خطر دسترسی ناخواسته دارد. تعیین بازه نگهداری، نقش مجاز برای بازبینی و روش پاک‌سازی قابل اثبات، بخش مدیریتی همین کنترل فنی است. ظرفیت قرنطینه باید پایش شود، زیرا پر شدن آن می‌تواند مسیر دریافت را از کار بیندازد یا برنامه را به رفتار پیش‌بینی‌نشده وادار کند.
معیارهای پذیرش و محدودیت واقعی
برای پذیرش عملیاتی، معیارهایی بنویسید که قابل مشاهده باشند: هیچ فایل پیش از تکمیل بررسی منتشر نشود؛ خطای موتور با نتیجه پاک یکی نشود؛ قطع به‌روزرسانی هشدار بدهد؛ بازگرداندن فایل از قرنطینه ثبت شود؛ و صف در بار معمول به زمان پاسخ مورد توافق برسد. این معیارها از ادعای کلی نصب آنتی‌ویروس مفیدتر هستند. یک تمرین ماهانه کوچک می‌تواند هر مسیر را دوباره بررسی کند. تغییر کتابخانه بارگذاری یا جابه‌جایی ذخیره‌ساز نیز باید باعث تکرار آزمون اتصال پاسخ اسکن به فایل شود.
ClamAV در راهکاری که ورودی فایل دارد ارزش مشخصی ایجاد می‌کند، اما ابزار جامع حفاظت دستگاه نیست. سرقت نشست، سوءاستفاده از مجوز برنامه، اجرای دستور از طریق نقص وب و بسیاری از رفتارهای دیگر ممکن است هیچ فایل قابل تشخیصی در مسیر اسکن ایجاد نکنند. بنابراین کنترل دسترسی، به‌روزرسانی نرم‌افزار و پایش رفتار همچنان ضروری هستند. تصمیم درست این است که مرز پوشش را مستند کنید و از خروجی موتور در کنار شواهد دیگر استفاده کنید. پروژه و کد رسمی در مخزن Cisco Talos قابل بررسی است؛ راهنمای نسخه نصب‌شده مرجع جزئیات اجرایی خواهد بود.
در ارزیابی نهایی، یک فایل بزرگ را هم‌زمان با چند فایل کوچک وارد صف کنید و ببینید آیا درخواست‌های کوتاه پشت آن متوقف می‌شوند. اگر چنین است، جداسازی صف بر اساس اندازه یا تعیین سهم منابع می‌تواند تجربه کاربر را بهتر کند. این تغییر باید دوباره با سیاست عدم انتشار پیش از اسکن آزمایش شود. بهینه‌سازی سرعت نباید ناخواسته مسیری ایجاد کند که فایل از کنترل عبور نکرده به دست مصرف‌کننده برسد. ثبت زمان انتظار و زمان پردازش به صورت جداگانه، علت کندی را روشن‌تر می‌کند.
