رفتن به محتوا
IROSG.
اپلیکیشن‌های امنیتی

YARA؛ ساخت قواعد قابل اعتماد برای شناسایی فایل

از انتخاب رشته و شرط تا آزمون خطای مثبت و نگهداری قواعد؛ راهنمای دفاعی و عملی YARA.

نشان یا نمای رسمی YARA
سازندهYARA Authors / VirusTotal
حوزهتطبیق الگو و تحلیل فایل
پلتفرم‌هاLinux · Windows · macOS
مجوز / مدلBSD-3-Clause
صفحهٔ رسمی ↗دانلود رسمی ↓

نقش YARA در تحلیل امنیتی

YARA ابزاری برای توصیف الگو و جست‌وجوی آن در داده است. تحلیلگر به جای جست‌وجوی دستی چند رشته در هزاران فایل، منطق مورد نظر را به یک قاعده تبدیل می‌کند و موتور آن را ارزیابی می‌کند. کاربرد شناخته‌شده آن دسته‌بندی نمونه‌های بدافزار است، اما همین روش برای یافتن قالب اختصاصی فایل، آثار یک ابزار داخلی یا مجموعه‌ای از نشانه‌های محتوایی نیز مفید است. تطبیق یک قاعده فقط می‌گوید شرط تعریف‌شده برقرار بوده است؛ معنای امنیتی آن را کیفیت قاعده و زمینه فایل تعیین می‌کند. به همین دلیل عبارت «YARA تشخیص داد» بدون نام و نسخه قاعده توضیح کافی نیست.

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

از فرضیه تا قاعده

کار را با یک فرضیه قابل آزمون آغاز کنید. برای مثال می‌خواهید اسناد خروجی یک ابزار داخلی را از بقیه فایل‌ها جدا کنید. یک رشته عمومی مانند نام شرکت ممکن است در هزاران سند دیگر وجود داشته باشد. بهتر است چند نشانه مستقل انتخاب شوند: عنوان خاص قالب، شناسه ساختار و بخش ثابتی از سرآیند. سپس مشخص کنید آیا وجود همه نشانه‌ها ضروری است یا بعضی از آنها اختیاری هستند. این مرحله یک تصمیم تحلیلی است و قبل از نوشتن عبارت منطقی باید انجام شود. قاعده‌ای که فرضیه روشن ندارد معمولاً با افزودن استثناهای پی‌درپی پیچیده می‌شود.

در پژوهش بدافزار نیز انتخاب رشته باید بر ویژگی متمایز و نسبتاً پایدار تکیه کند. متن خطای عمومی یک کتابخانه یا عبارت رایج سیستم‌عامل، شواهد قوی نیست. اگر یک نشانه فقط در یک نمونه مشاهده شده، آن را به همه خانواده تعمیم ندهید. می‌توان قاعده را با عنوان محدودتری منتشر کرد و دامنه ادعا را در توضیح نوشت. هدف این نیست که قاعده همیشه تعداد زیادی فایل پیدا کند؛ هدف این است که نتیجه آن برای تحلیلگر بعدی معنا داشته باشد و بتواند احتمال‌های متفاوت را از هم جدا کند.

تفاوت پوشش و دقت

قانون بسیار سخت ممکن است فقط نمونه اولیه را پیدا کند و تغییر کوچک در فایل باعث از دست رفتن تطبیق شود. قانون بسیار آزاد ممکن است فایل‌های سالم زیادی را گزارش کند. این دو هزینه باید جداگانه اندازه‌گیری شوند. مجموعه مثبت شامل مواردی است که انتظار دارید قاعده پیدا کند؛ مجموعه منفی شامل فایل‌هایی است که نباید تطبیق بخورند. هر دو مجموعه باید از نمونه‌های واقعی و متنوع ساخته شوند. چند فایل تکراری با نام متفاوت، تنوع واقعی ایجاد نمی‌کند و ممکن است ارزیابی را بهتر از واقع نشان دهد.

تفکیک داده ساخت و داده ارزیابی کمک می‌کند قاعده فقط ویژگی‌های نمونه‌های دیده‌شده را حفظ نکند. بخشی از نمونه‌ها را برای آزمون نهایی کنار بگذارید و هنگام هر تغییر شرط به آن‌ها نگاه نکنید. برای یک تیم کوچک این کار می‌تواند ساده باشد: یک پوشه برای توسعه و یک مجموعه بازبینی‌شده برای آزمون انتشار. نتیجه باید شامل تعداد تطبیق صحیح، موارد از دست رفته و خطاهای مثبت باشد. ذکر درصد بدون اندازه مجموعه و روش انتخاب نمونه‌ها برای تصمیم عملیاتی کافی نیست.

آزمایش بی‌خطر و قابل بازتولید

برای یادگیری زبان قواعد نیازی به فایل مخرب نیست. می‌توانید چند فایل متنی آزمایشی بسازید که ترکیب‌های مختلفی از نشانه‌های فرضی را دارند. یک فایل همه نشانه‌ها، فایل دیگر فقط یکی و فایل سوم هیچ‌کدام را داشته باشد. سپس قاعده را اجرا کنید و تفاوت شرط‌های «و» و «یا» را مشاهده کنید. این تمرین کوچک به‌خصوص زمانی مفید است که قاعده چند زیرشرط دارد و چشم انسان به راحتی تقدم عملگرها را اشتباه می‌خواند. استفاده از پرانتز خوانایی را بیشتر می‌کند، حتی وقتی زبان بدون آن نیز نتیجه مورد انتظار را می‌دهد.

آزمون باید حالت‌های مرزی را نیز پوشش دهد: فایل خالی، فایل بسیار کوچک، داده باینری و فایل با متن مشابه اما متفاوت. اگر از عبارت منظم استفاده می‌شود، نمونه‌ای با رشته طولانی و تکراری در نظر بگیرید تا هزینه اجرا مشخص شود. هدف از این آزمایش، کشف خطای منطقی و مشکل کارایی پیش از ورود به مجموعه بزرگ است. نسخه موتور و شناسه مجموعه قواعد را در گزارش بنویسید تا شخص دیگری بتواند همان آزمایش را تکرار کند. بدون این اطلاعات، اختلاف نتیجه میان دو میزبان ممکن است به اشتباه به تغییر تهدید نسبت داده شود.

کارایی بخشی از کیفیت قاعده است

قاعده‌ای که روی یک فایل سریع است ممکن است در مخزن بزرگ هزینه زیادی داشته باشد. تعداد رشته‌ها، عمومیت الگوها و پیچیدگی شرط روی زمان تحلیل اثر می‌گذارد. محدود کردن دامنه به نوع و اندازه مناسب فایل می‌تواند مفید باشد، اما باید با فرضیه سازگار بماند. اگر محدودیت اندازه صرفاً برای کاهش زمان اضافه می‌شود، موارد بیرون از آن باید به عنوان خارج از پوشش مستند شوند. نباید گزارش نهایی وانمود کند همه فایل‌ها با عمق یکسان بررسی شده‌اند.

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

قواعد بیرونی و زنجیره اعتماد

مجموعه قواعد عمومی نقطه شروع ارزشمندی است، ولی کپی مستقیم آن به سامانه تولید تصمیم مناسبی نیست. مجوز استفاده، دامنه هدف و نیازمندی نسخه را بررسی کنید. قاعده‌ای که برای شکار گسترده در آزمایشگاه نوشته شده ممکن است برای مسدودسازی خودکار نامناسب باشد. بعضی قواعد عمداً حساسیت بالا دارند تا تحلیلگر نمونه‌های احتمالی را ببیند. اگر همین خروجی باعث حذف فایل مشتری شود، هزینه خطای مثبت بسیار بیشتر خواهد بود. نقش قاعده باید در سیاست اجرای آن حفظ شود.

قواعد را مانند کد در کنترل نسخه نگه دارید. هر تغییر باید دلیل، نویسنده و نتیجه آزمون داشته باشد. پیش از انتشار مجموعه جدید، آن را روی نمونه‌های سالم سازمان اجرا کنید و اختلاف خروجی را بررسی کنید. اگر یک به‌روزرسانی ناگهان هزاران تطبیق تازه ایجاد کرد، این اتفاق می‌تواند ناشی از تهدید جدید یا خطای قاعده باشد؛ بدون مقایسه نمی‌توان تصمیم گرفت. امکان برگشت به نسخه پیشین نیز لازم است. وابستگی به دریافت زنده و بدون بازبینی قواعد، قابلیت بازتولید تحلیل را کاهش می‌دهد.

تحلیل نتیجه و حفظ شواهد

وقتی تطبیق رخ داد، نام قاعده، هش فایل، مسیر مشاهده و زمان تحلیل را ثبت کنید. مسیر به تنهایی هویت فایل نیست، زیرا محتوا ممکن است عوض شود. در بررسی رخداد، نگهداری نسخه قاعده به اندازه نگهداری خود نمونه اهمیت دارد. اگر پس از چند هفته قاعده اصلاح شده باشد، اجرای مجدد شاید نتیجه متفاوت بدهد. گزارش حرفه‌ای توضیح می‌دهد نتیجه اولیه با چه منطق و چه نسخه‌ای به دست آمده و چرا برداشت بعدی تغییر کرده است. این شفافیت نشانه ضعف ابزار نیست؛ بخشی از تحلیل قابل دفاع است.

نمایش رشته‌های تطبیق‌خورده به تحلیلگر کمک می‌کند دلیل نتیجه را بفهمد، اما ممکن است محتویات محرمانه را وارد گزارش کند. در سامانه دارای داده مشتری، خروجی خام نباید بی‌محابا به پیام‌رسان یا سامانه عمومی رخداد ارسال شود. می‌توان گزارش عملیاتی را به شناسه و خلاصه محدود کرد و جزئیات را در مخزن کنترل‌شده نگه داشت. همچنین نمونه مشکوک را برای مشاهده مستقیم روی رایانه کاری باز نکنید. YARA برای تطبیق محتوا طراحی شده و مجوز اجرای فایل را صادر نمی‌کند.

ادغام با فرایند پاسخ

بهتر است در آغاز خروجی YARA فقط برای اولویت‌بندی تحلیل استفاده شود. پس از شناخت میزان خطا و اهمیت قواعد، بعضی نتایج می‌توانند به اقدام محدود و قابل بازگشت متصل شوند. برای مثال فایل تطبیق‌خورده وارد صف بررسی شود و دسترسی عمومی آن موقتاً متوقف گردد. حذف قطعی یا خاموش کردن میزبان تصمیم دیگری است و به شواهد بیشتر نیاز دارد. این تفکیک کمک می‌کند یک خطای منطقی کوچک در قاعده، پیامد عملیاتی بزرگی ایجاد نکند.

در تمرین تیمی، یک سناریوی کامل تعریف کنید: قاعده تازه اضافه می‌شود، فایل آزمایشی تطبیق می‌خورد، هشدار به مسئول می‌رسد، تحلیل انجام می‌شود و پرونده با توضیح بسته می‌شود. زمان هر مرحله و نقاط ابهام را ثبت کنید. شاید ابزار درست کار کند اما کسی مسئول بررسی هشدار نباشد. شاید نام قاعده برای تیم پشتیبانی قابل فهم نباشد. چنین مشکلاتی با نصب بسته حل نمی‌شوند و باید در دستورالعمل پاسخ اصلاح شوند. نتیجه تمرین می‌تواند معیار پذیرش هر مجموعه قاعده جدید باشد.

انتخاب آگاهانه

YARA برای تیمی مناسب است که می‌خواهد دانش تحلیل را به الگوهای قابل اجرا تبدیل کند و برای آزمون و نگهداری آن وقت دارد. این ابزار به تنهایی منبع جامع اطلاعات تهدید، سامانه رفتارشناسی یا تضمین تشخیص همه بدافزارها نیست. محتوای رمز‌شده یا داده‌ای که پیش از بررسی آماده نشده ممکن است نشانه مورد انتظار را آشکار نکند. روش آماده‌سازی فایل نیز باید در دامنه تحلیل ثبت شود. راهنمای رسمی نوشتن قواعد مرجع نحو و محدودیت‌هاست و مخزن پروژه محل بررسی انتشار و مجوز است. ارزش عملی ابزار زمانی آشکار می‌شود که هر نتیجه قابل توضیح، هر تغییر قابل آزمون و هر تصمیم قابل بازبینی باشد.

برای نگهداری بلندمدت، قواعد بدون مالک را نیز بازبینی کنید. اگر نویسنده از تیم خارج شده یا منبع اولیه دیگر در دسترس نیست، هدف قاعده باید از روی مستندات قابل فهم باشد. قاعده مبهم را نمی‌توان صرفاً به دلیل قدیمی بودن قابل اعتماد دانست. حذف یا محدود کردن آن پس از بررسی، گاهی کیفیت مجموعه را بیش از افزودن قواعد تازه افزایش می‌دهد.

TRACEABLE KNOWLEDGE

منابع و مطالعهٔ بیشتر

01
وب‌سایت YARAhttps://virustotal.github.io/yara/
02
راهنمای قواعدhttps://github.com/VirusTotal/yara/blob/master/docs/writingrules.rst
03
مخزن رسمیhttps://github.com/VirusTotal/yara

آخرین بررسی تحریریه:

IROSG / EDITORIAL

خبرها و معرفی مشاهیر با نگارش مستقل و ذکر منبع تهیه شده‌اند. اعتبار و مجوز تصاویر در بخش منابع همین صفحه نگه‌داری می‌شود تا متن زیر عکس‌ها شلوغ نشود. داده‌های مرجع CVE با اعتباردهی به منابع اصلی ارائه می‌شوند.

سیاست تألیف و حقوق تصاویر ↗