osquery چه کاری انجام می‌دهد؟
osquery اطلاعات سیستم‌عامل را به شکل جدول‌هایی عرضه می‌کند که می‌توان با زبان SQL از آن‌ها پرسش کرد. برای کسی که مدیریت چند نوع سیستم را انجام می‌دهد، این ایده جذاب است: به جای حفظ کردن خروجی چندین فرمان متفاوت، می‌توان درباره فرایندها، کاربران یا بعضی تنظیمات با روشی نسبتاً یکپارچه سؤال کرد. البته همه جدول‌ها روی همه سیستم‌عامل‌ها یکسان نیستند. وجود نام یک جدول در مستندات، تضمین نمی‌کند همان جدول روی هر میزبان داده داشته باشد. نسخه برنامه، سیستم‌عامل، مجوز اجرا و فعال بودن قابلیت مرتبط در نتیجه اثر دارند.
این ابزار را می‌توان به چشم راهی برای مشاهده وضعیت میزبان دید. برای مثال، مدیر می‌خواهد بداند چه فرایندی در حال اجراست یا یک نرم‌افزار روی کدام دستگاه‌ها نصب شده است. پرسش خوب از نیاز مشخص آغاز می‌شود و ستون‌های مورد نیاز را برمی‌گرداند. جمع‌آوری بی‌هدف همه چیز می‌تواند هزینه پردازش، حجم گزارش و حساسیت داده را بالا ببرد. اگر سؤال شما فقط نام و شناسه فرایند است، نیازی نیست تمام جزئیات آن را به سامانه مرکزی بفرستید. این انتخاب ساده، هم تحلیل را آسان‌تر می‌کند و هم از جمع شدن اطلاعات غیرضروری جلوگیری می‌کند.
جدول مجازی با پایگاه داده معمولی فرق دارد
در بسیاری از جدول‌های osquery، داده هنگام پرسش از رابط‌های سیستم‌عامل به دست می‌آید. بنابراین نباید تصور کرد همه جدول‌ها یک نسخه تاریخی دائمی از دستگاه هستند. اگر فرایندی پیش از پرسش تمام شده باشد، جدول وضعیت جاری ممکن است آن را نشان ندهد. از طرف دیگر، داده رویدادی می‌تواند با سازوکار متفاوتی جمع‌آوری شود و به تنظیمات خاص نیاز داشته باشد. هنگام نوشتن یک بررسی امنیتی، مشخص کنید به تصویر لحظه‌ای نیاز دارید یا به سابقه رخدادها. این تفاوت تعیین می‌کند پرسش دوره‌ای کافی است یا باید جمع‌آوری رویداد مناسب طراحی شود.
SQL در اینجا وسیله بیان سؤال است، نه دعوت به تغییر سیستم از طریق فرمان‌های پایگاه داده. مسیر معمول استفاده، خواندن داده با SELECT است. بهتر است ذهنیت کاربر تازه‌کار این باشد که می‌خواهد مشاهده کند و نتیجه را با شواهد دیگر تطبیق دهد. برای مثال، پیدا کردن یک فرایند با نام آشنا به معنی سالم بودن آن نیست؛ مسیر فایل، مالک و زمینه اجرای آن نیز اهمیت دارند. همچنین نبود نتیجه را نباید فوراً نبود فعالیت دانست. ممکن است دسترسی کافی نباشد، جدول مناسب انتخاب نشده باشد یا زمان مشاهده با زمان رخداد فاصله داشته باشد.
تفاوت osqueryi و osqueryd
محیط تعاملی osqueryi برای نوشتن و آزمایش پرسش روی همان دستگاه مناسب است. می‌توانید ساختار جدول را ببینید، یک پرسش کوچک اجرا کنید و نتیجه را بررسی کنید. این محیط به طور پیش‌فرض یک کنسول مدیریت تمام رایانه‌های شبکه نیست. در مقابل، osqueryd برای اجرای پرسش‌های زمان‌بندی‌شده و تولید خروجی در طول زمان استفاده می‌شود. در استقرار سازمانی، مدیریت تنظیمات و دریافت نتیجه‌ها نیز باید طراحی شود. نصب عامل روی میزبان تنها یکی از بخش‌های این مسیر است و به تنهایی داشبورد کامل مدیریت ناوگان ایجاد نمی‌کند.
برای آغاز، ابتدا پرسش را در محیط تعاملی روی دستگاه آزمایش بنویسید. وقتی نتیجه و هزینه آن روشن شد، درباره زمان‌بندی تصمیم بگیرید. این ترتیب مانع می‌شود یک پرسش پرهزینه یا نادرست روی تعداد زیادی میزبان منتشر شود. همچنین تفاوت مجوز محیط آزمایش و سرویس را در نظر بگیرید؛ ممکن است پرسشی با حساب شما داده‌ای نشان دهد که سرویس با سطح دسترسی دیگر نمی‌بیند. آزمون نهایی باید در شرایطی نزدیک به اجرای واقعی انجام شود و نتیجه از مسیر گزارش همان سرویس بررسی شود.
اولین پرسش و خواندن ساختار جدول
در محیط تعاملی، ابتدا فهرست جدول‌ها و ساختار جدول مورد نظر را ببینید. نام ستون‌ها را حدس نزنید. یک پرسش کوچک مانند نمونه زیر برای مشاهده تعداد محدودی فرایند مناسب است:
SELECT pid, name, path
FROM processes
LIMIT 10;
این نمونه آموزشی ترتیب خاصی برای فرایندها تضمین نمی‌کند. اگر به جدیدترین یا یک نام مشخص نیاز دارید، باید شرط و ترتیب مناسب اضافه کنید. مشاهده چند ردیف به شما کمک می‌کند معنای ستون‌ها را بفهمید و سپس پرسش اصلی را بسازید. بهتر است خروجی را با ابزار معمول سیستم‌عامل مقایسه کنید تا مطمئن شوید تفسیرتان درست است. اختلاف جزئی ممکن است ناشی از تغییر وضعیت بین دو مشاهده باشد، به‌ویژه وقتی فرایندهای کوتاه‌عمر وجود دارند.
پس از این مرحله، به جای افزودن همه ستون‌ها، سؤال واقعی را مشخص کنید. مثلاً «مسیر اجرایی فرایندی با این نام چیست؟» یا «کدام کاربر مالک آن است؟». هر سؤال به داده محدود و قابل تفسیر نیاز دارد. اگر از اتصال جدول‌ها استفاده می‌کنید، کلید اتصال و امکان چند ردیف شدن نتیجه را بررسی کنید. زیاد شدن ردیف‌ها همیشه به معنی زیاد شدن موجودیت‌های واقعی نیست؛ یک فرایند می‌تواند چند اتصال یا فایل باز داشته باشد. بدون درک این رابطه، شمارش خروجی ممکن است گزارش اشتباهی از تعداد فرایندها ایجاد کند.
پرسش درباره فایل‌ها و محدود کردن دامنه
بعضی جدول‌ها برای اجرا به شرطی روی مسیر یا ستون مشخص نیاز دارند. این رفتار منطقی است؛ یک پرسش بی‌قید نباید ناخواسته همه فایل‌سیستم را پیمایش کند. برای بررسی یک فایل آزمایشی، مسیر دقیق را مشخص کنید و ابتدا اطلاعات ساده مانند اندازه یا زمان تغییر را بخوانید. اگر به هش فایل نیاز دارید، هزینه خواندن محتوای آن را نیز در نظر بگیرید. هش گرفتن از یک فایل کوچک تنظیمات با هش گرفتن دوره‌ای از مجموعه بزرگی از فایل‌های حجیم یکسان نیست. طراحی پرسش باید با اندازه و سرعت تغییر داده هماهنگ باشد.
زمان‌های فایل نیز باید درست تفسیر شوند. تغییر یک زمان لزوماً نشان‌دهنده فعالیت مخرب نیست و مفهوم هر فیلد به سیستم‌عامل و فایل‌سیستم وابسته است. به‌روزرسانی نرم‌افزار، بازیابی نسخه پشتیبان یا عملیات مدیریتی می‌تواند تغییر ایجاد کند. برای تمرین، یک فایل متعلق به خودتان بسازید، محتوای آن را تغییر دهید و نتیجه پرسش را قبل و بعد مقایسه کنید. سپس مجوز یا نام فایل را تغییر دهید و ببینید کدام فیلدها عوض می‌شوند. این آزمایش کوچک از حفظ کردن نام ستون‌ها مفیدتر است، زیرا رابطه میان عملیات و خروجی را آشکار می‌کند.
زمان‌بندی و معنی خروجی تفاضلی
در اجرای دوره‌ای، می‌توان نتیجه فعلی را با نتیجه قبلی مقایسه کرد و تغییرها را گزارش داد. به این ترتیب، خروجی تازه الزاماً نماینده تمام وضعیت میزبان نیست؛ ممکن است فقط ردیف‌های افزوده یا حذف‌شده باشد. در اولین اجرا، چون نتیجه قبلی وجود ندارد، داده‌ها می‌توانند به عنوان افزوده ثبت شوند. این نکته برای خواندن گزارش مهم است. دیدن تعداد زیادی ردیف افزوده بلافاصله پس از نصب عامل، لزوماً به معنی ایجاد هم‌زمان همه آن موارد در سیستم نیست؛ ممکن است فقط نخستین مشاهده باشد.
برای توضیح این رفتار به تیم، یک آزمایش ساده با داده بی‌خطر طراحی کنید. وضعیت را یک بار ثبت کنید، سپس تغییری محدود ایجاد کنید و اجرای بعدی را ببینید. خروجی کامل و خروجی تغییرات را با هم مقایسه کنید. اگر سامانه دریافت‌کننده تفاضل‌ها را نگهداری می‌کند، باید معلوم باشد چگونه وضعیت فعلی از آن‌ها ساخته می‌شود. قطع شدن مسیر گزارش می‌تواند این بازسازی را ناقص کند. بنابراین سلامت دریافت داده، زمان آخرین تماس و خطاهای عامل باید کنار نتیجه‌های محتوایی دیده شوند؛ سکوت یک میزبان همیشه به معنی بدون تغییر بودن آن نیست.
فاصله نمونه‌برداری و از دست رفتن رخداد کوتاه
فرض کنید هر چند دقیقه از فهرست فرایندها پرسش می‌کنید. برنامه‌ای که در فاصله میان دو مشاهده اجرا و تمام شده، ممکن است در هیچ نتیجه‌ای دیده نشود. کوتاه کردن فاصله می‌تواند شانس مشاهده را بیشتر کند، اما هزینه را نیز بالا می‌برد و هنوز همان مفهوم جمع‌آوری رویداد نیست. ابتدا مشخص کنید هدف پرسش موجودی‌گیری است یا تشخیص اجرای کوتاه. برای موجودی نرم‌افزار، فاصله طولانی‌تر ممکن است کافی باشد؛ برای رخدادهای گذرا، باید روش مناسب همان نوع داده بررسی شود. انتخاب فاصله بدون تعریف هدف، معمولاً به جمع‌آوری پرهزینه و ناکافی منتهی می‌شود.
دستگاه‌های کاربر نیز همیشه روشن و متصل نیستند. خواب لپ‌تاپ، قطع شبکه یا خاموش بودن عامل می‌تواند زمان دریافت را تغییر دهد. در گزارش، زمان مشاهده و زمان دریافت را در صورت وجود جدا نگه دارید. اگر فقط زمان ورود به سرور مرکزی دیده شود، داده قدیمی ممکن است تازه به نظر برسد. برای مقایسه چند میزبان نیز هماهنگی ساعت اهمیت دارد. یک اختلاف زمانی کوچک در بررسی ترتیب رخدادها می‌تواند تحلیل را منحرف کند. بهتر است هر نتیجه با شناسه میزبان، نسخه عامل و زمان مرتبط همراه باشد تا بعداً قابل بررسی بماند.
کارایی و حفاظت از میزبان
هر پرسش هزینه‌ای دارد، حتی اگر خواندنی باشد. اتصال چند جدول، بررسی مسیرهای زیاد یا محاسبه هش می‌تواند مصرف پردازنده و دیسک را بالا ببرد. پیش از انتشار پرسش روی ناوگان، آن را روی چند میزبان نماینده بسنجید. دستگاه توسعه پرقدرت نماینده مناسبی برای همه لپ‌تاپ‌های قدیمی نیست. معیار باید علاوه بر زمان پاسخ، اثر روی کار عادی کاربر و حجم خروجی را هم بسنجد. یک پرسش که هر بار چندین هزار ردیف بی‌استفاده تولید می‌کند، در مقیاس سازمان مشکل انتقال و نگهداری نیز ایجاد خواهد کرد.
اگر هدف با پرسشی ساده‌تر حاصل می‌شود، از همان استفاده کنید. انتخاب ستون‌های کمتر، شرط دقیق‌تر و فاصله متناسب می‌تواند هزینه را کاهش دهد، ولی باید بعد از تغییر پوشش را دوباره بررسی کرد. حذف داده برای سریع‌تر شدن نباید پنهانی معنای سؤال را عوض کند. برای مثال، بررسی فقط یک مسیر ممکن است دیگر همه نصب‌های نرم‌افزار را پوشش ندهد. این محدودیت باید در نام یا توضیح پرسش ثبت شود. مجموعه پرسش‌ها بهتر است مالک داشته باشد تا موارد قدیمی یا بی‌مصرف پس از مدتی حذف یا بازنویسی شوند.
حریم خصوصی و مدیریت نتیجه‌ها
اطلاعات فرایند و خط فرمان می‌تواند شامل مسیر شخصی، نام فایل یا حتی داده حساسی باشد که برنامه دیگری به اشتباه در آرگومان قرار داده است. بنابراین جمع‌آوری این ستون‌ها باید هدف روشن داشته باشد. دسترسی به نتایج مرکزی را محدود کنید و مدت نگهداری را متناسب با نیاز تعیین کنید. برای آموزش و آزمایش، خروجی ساختگی یا حذف‌شده از اطلاعات شخصی مناسب‌تر است. اشتراک یک فایل نتیجه در گروه عمومی ممکن است اطلاعاتی را آشکار کند که در نگاه اول فقط «فهرست فرایندها» به نظر می‌رسد.
همچنین تنظیمات عامل بخشی از سطح اعتماد محیط است. کسی که می‌تواند پرسش‌های ناوگان را تغییر دهد، درباره نوع داده جمع‌آوری‌شده تصمیم می‌گیرد. تغییرات تنظیمات باید قابل پیگیری باشند و پیش از انتشار گسترده بررسی شوند. در استقرار مرکزی، اعتبار مقصد دریافت تنظیمات و گزارش‌ها اهمیت دارد. هدف این نیست که هر پرسش ساده به فرایند پیچیده تبدیل شود، بلکه باید روشن باشد چه کسی چه داده‌ای را برای چه منظوری جمع می‌کند. شفافیت در این بخش، همکاری تیم عملیات و کاربران را آسان‌تر می‌کند.
عیب‌یابی و تفسیر حرفه‌ای
وقتی نتیجه خالی است، پرسش را به کوچک‌ترین شکل کاهش دهید و وجود جدول و ستون را بررسی کنید. سپس سطح دسترسی، سیستم‌عامل و وضعیت قابلیت مربوط را ببینید. اگر در محیط تعاملی نتیجه دارید ولی در گزارش مرکزی ندارید، مسیر اجرای زمان‌بندی، تولید لاگ و انتقال را جدا آزمایش کنید. لاگ وضعیت ابزار با نتیجه پرسش یکی نیست؛ ممکن است سرویس فعال باشد اما یک پرسش خطا داشته باشد. بررسی یک نمونه مشخص با زمان معلوم، از نگاه کردن صرف به سبز بودن وضعیت سرویس مفیدتر است.
osquery زمانی ارزشمند است که سؤال خوب، جمع‌آوری متناسب و تحلیل مسئولانه در کنار هم قرار گیرند. آن را جایگزین کامل ثبت رخداد، بررسی تخصصی یا ابزار پاسخ‌گویی فرض نکنید. با چند پرسش روشن درباره دارایی‌های خود شروع کنید و برای هر پرسش، نتیجه مورد انتظار و محدودیت آن را بنویسید. سپس همان نتیجه را در یک تصمیم عملیاتی به کار ببرید، مثل پیدا کردن نصب ناسازگار یا بررسی یک تغییر تنظیمات. این چرخه باعث می‌شود ابزار به منبع دید قابل اعتماد تبدیل شود و تیم بداند هر عدد یا ردیف دقیقاً چه چیزی را ثابت می‌کند.
