سوالات عمومی کنسول سازمانی
شیوه تشخیص و برخورد با موارد Access Denied و Ignore در لاگ Threats
مساله
- در لاگ تشخیص بدافزار پادویش (Threats) با مواردی مواجه شدید که Ignore یا Access Denied برای آنها درج شده است و میخواهید علت این موضوع را مشخص کنید.
شرح مختصر
به طور خلاصه عدم حذف بدافزار میتواند به یکی از دلایل زیر باشد:
- فایلهای مشکوک به بدافزار که – بنا به تنظیمات مدیر سیستم – پاکسازی آنها خودکار نبوده و در وضعیت تصمیمگیری دستی قرار دارند. (تشخیصهای از نوع PUA و Heur در این دسته قرار میگیرند) در این موارد پادویش جلوی اجرای فایل مشکوک را میگیرد، اما بدون دخالت کاربر آنرا حذف/پاکسازی نمیکند.
- بدافزارهایی که در رسانه ذخیرهساز فقط خواندنی مانند سیدی یا دیویدی انجام شدهاند و بنا به فقط خواندنی بودن رسانه قابل حذف/پاکسازی نبوده و صرفا جلوگیری میشوند.
- بدافزارهایی که درون فایل فشرده با شرایط خاصی (مانند فایلهای solid) قرار دارند که امکان حذف آنها و بازسازی فایل فشرده وجود نداشته یا بسیار زمانبر خواهد بود. در این موارد تشخیص به کاربر اعلام میگردد و در صورت تصمیم وی، امکان حذف کل فایل فشرده وجود دارد.
- فایلهای آلوده به ویروس (File Infector) که نیاز به پاکسازی کد مخرب از درون فایل دارند، اما ساختار فایل خراب بوده و امکان تعمیر آن وجود ندارد. این فایلها معمولا به علت خرابی اصلا قابل اجرا نیز نیستند و صرفا حاوی امضای بدافزار هستند. در این موارد نیز پادویش جهت جلوگیری از حذف ناخواسته اطلاعات کاربر، تشخیص بدافزار را اعلام نموده و حذف فایل را به تصمیم کاربر میگذارد.
توضیح بیشتر در مورد هر یکی از موارد بالا و نیز روش برخورد با آن از طریق ضدویروس پادویش را در زیر مطالعه میکنید.
در صورتیکه بعد از بررسی، مشخص گردید که موضوع شما با موارد زیر متفاوت است و از نوع دیگری میباشد، لطفا با پشتیبانی پادویش جهت بررسی موضوع تماس بگیرید تا سیستم شما بررسی گردد.
تشخیصهای از نوع PUA (Potentially Unwanted Application)
برنامه PUA یا Potentially Unwanted Application که به «برنامه احتمالا ناخواسته» نیز مشهور هستند، دستهای از برنامهها است که در مرز نرمافزار سالم و بدافزار قرار دارد. این برنامهها به خودی خود بدافزار نیستند و دارای کاربردهای سالم و معقول روزمره هستند، اما به علت امکانات و قابلیتهایی که دارند ممکن است وجود آنها در سیستم ناخواسته و مضر باشد.
به عنوان مثال:
- نرمافزارهای Sniffer ترافیک شبکه یا کیلاگرها. این نوع برنامهها ممکن است توسط مدیر شبکه جهت عیبیابی به کار بروند، یا توسط والدین به عنوان پرنتال کنترل نصب شده باشند، اما در طرف مقابل ممکن است توسط فرد دیگری در سیستم و به منظور ابزار نفوذ استفاده گردند. لذا ضدویروس در این نوع موارد کاربر را از وجود نرمافزار مطلع کرده و تصمیم را به وی واگذار میکند.
- نرمافزارهای ریموت که بدون پیام یا رابط کاربری اجرا میشوند. چنین نرمافزاری در صورتیکه کاربر از وجود آن مطلع باشد و از آن استفاده کند بیخطر است، اما اگر توسط یک نفوذگر روی سیستم نصب شده باشد لازم است وجود برنامه به کاربر اطلاع داده شود.
- نرمافزارهای سالم دارای تبلیغات که توسط برخی کاربران استفاده میشوند و از نظر آنها مشکلی ندارند، اما برخی کاربران دیگر ممکن است از حضور آنها نامطلع بوده و از تبلیغات نمایش داده شده ناراضی باشند.
- و …
روش یافتن تشخیصهای از این نوع
در پادویش همه تشخیصهایی که با کلمه PUA. آغاز میشوند از این دسته هستند.
روش برخورد
در این مورد به چند صورت میتوانید برنامههای ناخواسته را حذف نمایید:
- پاسخگویی به هشدار ضدویروس (محافظت مستمر یا پویشگر) و انتخاب گزینه حذف/پاکسازی بر روی سیستم مربوطه
- تغییر تنظیمات پویشگر در کنسول مدیریتی پادویش (Change Client Settings > Padvish AV > Scanner) به حالت Automatic و انجام پویش بر روی کلاینت مربوطه
- راست کلیک بر روی لاگ تشخیص در کنسول مدیریتی پادویش و انتخاب گزینه Run Disinfection For Selected Item را انتخاب نمایید. (سری ۱.۱۴ کنسول مدیریتی پادویش به بعد)
فایلهای مشکوک به بدافزار Heur
پادویش علاوه بر روشهای تشخیصی مبتنی بر امضا و شبهاجرا، دارای یک موتور هوش مصنوعی مبتنی بر یادگیری ماشین (Machine Learning – ML) میباشد که امکان تشخیص انواع جدید و ناشناخته بدافزار را که توسط هیچ ضدویروسی دیده نشدهاند را فراهم میکند. تشخیصهای مبتنی بر موتور هوشمند پادویش با نام Heur شروع شده و از نوع تشخیصهای مشکوک (غیرقطعی) محسوب میشوند.
کاربر میتواند با تغییر درجه حساسیت موتور هوشمند، میزان دقت و سختگیری آن در تشخیص بدافزارهای جدید را تغییر دهد. به نحوی که انتخاب حساسیتهای بالاتر، امکان تشخیص بدافزارهای بیشتری را فراهم میکند، اما احتمال تشخیص نرمافزارهای سالم که از روشهای فرار از مهندسی معکوس استفاده کرده یا ساختار و رفتارهای نزدیک به بدافزار دارند نیز بیشتر میشود.
به علاوه این تشخیصها نیز – مشابه برنامههای ناخواسته PUA – از نوع تشخیص مشکوک به بدافزار محسوب شده و برخورد با آنها تابع تنظیمات انجام شده در این بخش میباشد.
روش یافتن تشخیصهای از این نوع
در پادویش همه تشخیصهایی که با کلمه HEUR. آغاز میشوند از این دسته هستند.
روش برخورد
روش برخورد با این نوع بدافزارها مشابه روش برخورد با PUA میباشد.
رسانههای فقط خواندنی
در صورتی که تشخیص بدافزار در یک رسانه فقط خواندنی مانند سیدی/دیویدی، فلش فقط خواندنی، یا فولدر اشتراکی رخ دهد، طبیعتا امکان تغییر در فایل بدافزار یا حذف آن وجود ندارد. لذا در این نوع تشخیصها پادویش صرفا از اجرای بدافزار و آلودگی سیستم جلوگیری کرده (منع دسترسی Access Denied) و لاگ آن را ثبت مینماید.
روش یافتن تشخیصهای از این نوع
تشخیصهایی که در رسانه فقط خواندنی هستند از این نوع هستند. جهت تمیز دادن این موارد از سایر لاگهای تشخیص بدافزار، به ستون DeviceID که نشانگر شناسه سختافزاری رسانه مربوطه است توجه نمایید.
روش برخورد
در این مورد به علت اینکه رسانه فاقد امکان بازنویسی است، راهی برای رفع مساله به جز رونویسی از رسانه مربوطه وجود ندارد.
حذف بدافزار از درون فایل فشرده
پادویش دارای امکان تشخیص بدافزارهای درون فایلهای فشرده میباشد و در حین پویش، محتویات این فایلها را پویش کرده و در صورت وجود بدافزار آن را اعلام میکند. لازم به ذکر است که بدافزارهای درون فایل فشرده در واقع بدافزار غیرزنده و آرشیو شده هستند و امکان اجرا ندارند، بلکه قبل از اجرا باید از فایل فشرده خارج شوند که در چنین صورتی بلافاصله توسط محافظت مستمر پادویش شناسایی و پاکسازی خواهند شد. لذا هدف از پویش فایلهای فشرده در واقع کشف بدافزارهایی است که در بکاپها و مانند آن آرشیو شدهاند و نیازمند یک واکنش فوری نمیباشد.
در صورتیکه بدافزاری در فایل فشرده کشف شود، پادویش برای راحتی کاربر با شرایطی امکان حذف خودکار بدافزار از درون فایل فشرده را نیز ارائه میدهد. این امکان برای انواع متداولی مانند zip و ۷z تعبیه شده است و یکی از محدودیتهای آن، این است که فایل فشرده از نوع Solid نباشد. چرا که نحوه فشردهسازی فایلهای Solid به صورتی است که جهت حذف یک فایل، باید کل فایلها ابتدا استخراج و سپس دوباره فشرده شوند که ممکن است به دلایل مختلف کاری بسیار زمانبر بوده و نیاز به فضای آزاد دیسک و … داشته باشد.
در صورتیکه به هر علتی امکان حذف فایل از درون فایل فشرده به صورت خودکار وجود نداشته باشد، پادویش وجود بدافزار را اعلام کرده از کاربر در مورد نحوه برخورد کسب تکلیف میکند.
روش یافتن تشخیصهای از این نوع
برای تمیز دادن این نوع تشخیصها، به اسم فایل درج شده در لاگ توجه کنید. تشخیصهایی درون فایل فشرده رخ دادهاند با اسم فایل، کاراکتر دو نقطه (:) و سپس مسیر درون فایل فشرده مشخص میشوند. (به عنوان مثال c:\path\file.zip:somefile.exe)
روش برخورد
به دو روش میتوان کل فایل فشرده را حذف نمود:
- بر روی سیستم مربوطه، در پایان پویش، بر روی لینک «برخی موارد نیازمند توجه شما هستند» کلیک کرده و از لیست نمایش داده شده گزینه حذف فایل فشرده را انتخاب کنید. پیامی مبنی بر اطمینان از حذف کل فایل فشرده ظاهر میشود که با پاسخ به آن فایل حذف خواهد شد.
- راست کلیک بر روی لاگ تشخیص در کنسول مدیریتی پادویش و انتخاب گزینه Run Disinfection For Selected Item را انتخاب نمایید. (سری ۱.۱۴ کنسول مدیریتی پادویش به بعد)
فایلهای آلوده به ویروس
ویروس (در کنار کرم و تروجان) نوع خاصی از بدافزار است که کد مخرب خود را درون فایل اجرایی سالم پنهان میکند. جهت پاکسازی ویروس، حذف فایل راهکار نبوده و منجر به حذف فایل اجرایی و از کار افتادن سیستم میشود، لذا باید کد مخرب ویروس از درون فایل اجرایی استخراج شده و طی یک عملیات پیچیده فایل سالم بازتولید گردد. ضدویروس پادویش قادر به پاکسازی کد مخرب و بازتولید فایل سالم از فایل ویروسی بوده و این عملیات را به صورت خودکار در مورد ویروسها انجام میدهد.
در مواردی، به علت وجود خطا در کد ویروس، یا اتفاقات نرمافزاری/سختافزاری، ممکن است ساختار فایل اجرایی خراب شده و به همین علت قابل پاکسازی و بازگردانی نباشد. این نوع فایلها در بسیاری موارد قابل اجرا نیز نیستند، و محتوای آنها در حدی بهم ریخته که دیگر قابل استفاده نیست. به علاوه برخی ضدویروسها هنگام پاکسازی ویروس، کلیه نشانههای ویروس را حذف نمیکنند و حتی پس از پاکسازی، امضای ویروس در این فایلها توسط سایر ضدویروسها تشخیص داده میشود. پادویش در حین پروسه پاکسازی فایل ویروسی، این نوع فایلها را تشخیص داده و در راستای حفظ اطلاعات کاربر، عملیات پاکسازی را بدون تغییر فایل متوقف میکند. در این موارد عملیات حذف فایل نیز توسط پادویش انجام نمیگیرد، چرا که فایل حاوی کد مخرب و کد سالم است، لذا صرفا از اجرای فایل و آلودگی سیستم ممانعت شده (منع دسترسی Access Denied) و تصمیمگیری درباره حذف این فایلها به کاربر واگذار میگردد.
روش یافتن تشخیصهای از این نوع
تمام تشخیصهای از نوع ویروس با کلمه Virus. آغاز میشوند. در صورتیکه تشخیص داده شده از انواع قبلی نباشد (بر روی رسانه فقط خواندنی قرار نگرفته باشد) مشخص است که علت عدم پاکسازی مربوط به خراب شدن ساختار فایل اجرایی است. (در این موارد احتمال خوبی وجود دارد فایل اصلا قابل اجرا نباشد)
روش برخورد
به دو روش میتوان فایل آلوده را حذف نمود:
- بر روی سیستم مربوطه، در پایان پویش، بر روی لینک «برخی موارد نیازمند توجه شما هستند» کلیک کرده و از لیست نمایش داده شده گزینه حذف را انتخاب کنید.
- راست کلیک بر روی لاگ تشخیص در کنسول مدیریتی پادویش و انتخاب گزینه Run Disinfection For Selected Item را انتخاب نمایید. (سری ۱.۱۴ کنسول مدیریتی پادویش به بعد)
راهنمای اتصال کنسول مدیریتی پادویش به نرمافزار Splunk و مشابه
مساله
اگر قصد ارسال لاگهای پادویش به یک نرمافزار مشاهده و آنالیز لاگ مانند Splunk را دارید این راهنما به شما کمک میکند.
دستورالعمل
قبل از استفاده از این دستورات باید با استفاده از «راهنمای راهاندازی Syslog در کنسول مدیریتی پادویش» کنسول پادویش را به Splunk متصل نموده باشید. بهتر است قبل از ادامه مقداری لاگ در نرمافزار دریافت شده باشد تا هنگام افزودن قواعد زیر، تاثیر آن را ببینید.
بسته به نسخه Splunk ممکن است روش کار اندکی متفاوت باشد، اما به طور کلی از قاعده زیر پیروی میکند:
- به صفحه Extract Fields بروید.
- گزینه I prefer to write the regular expression myself را انتخاب کنید.
- هر یک از قواعد زیر را وارد کرده و آن را ذخیره نمایید. (هنگام ورود دقت کنید که هر بار یک سطر را کپی و استفاده کنید. هیچ کاراکتر اضافی فاصله یا اینتر نباید کپی شود)
- مراحل بالا را برای تمامی قواعد تکرار نمایید.
قواعد
(?<logtype>\S+) \[(?<clienttime>.*)\] Malware '(?<malwarename>.*)' found in client (?<clientname>.*) \[(?<clientip>.*)\] on path '(?<filepath>.*)', action=(?<action>.*), result=(?<result>.*)
(?<logtype>\S+) \[(?<clienttime>.*)\] (?<protection>.*) turned (?<onoff>on|off) by '(?<username>.*)' on client (?<clientname>.*) \[(?<clientip>.*)\] user (?<consoleusername>.*)
(?<logtype>\S+) \[(?<clienttime>.*)\] File '(?<filepath>.*)' restored from quarantine by '(?<username>.*)' on client (?<clientname>.*) \[(?<clientip>.*)\] user (?<consoleusername>.*)
(?<logtype>\S+) \[(?<clienttime>.*)\] Restore of file '(?<filepath>.*)' from quarantine failed by '(?<username>.*)' on client (?<clientname>.*) \[(?<clientip>.*)\] user (?<consoleusername>.*)
(?<logtype>\S+) \[(?<clienttime>.*)\] Successfuly updated by '(?<username>.*)' on client (?<clientname>.*) \[(?<clientip>.*)\] user (?<consoleusername>.*)
(?<logtype>\S+) \[(?<clienttime>.*)\] Update by '(?<username>.*)' failed on client (?<clientname>.*) \[(?<clientip>.*)\] user (?<consoleusername>.*)
(?<logtype>\S+) \[(?<clienttime>.*)\] A scan was performed on client (?<clientname>.*) \[(?<clientip>.*)\] by '(?<username>.*)'. Result='(?<result>.*)', Scanned files='(?<filecount>\d+)', Threats found='(?<threatcount>\d+)', Start Date='(?<scanstart>.*)', End Date='(?<scanend>.*)'
(?<logtype>\S+) \[(?<clienttime>.*)\] (?<action>.*) connection on client (?<clientname>.*) \[(?<clientip>.*)\] user (?<consoleusername>.*). \[Direction='(?<direction>.*)', Remote Address='(?<remoteip>.*):(?<remoteport>.*)', Local Address=':(?<localport>.*)', Protocol='(?<ipprotocol>\d+)'\]
(?<logtype>\S+) \[(?<clienttime>.*)\] Device '(?<devicetype>.*)' with ID '(?<deviceserial>.*)' connected and was '(?<action>.*)' on client (?<clientname>.*) \[(?<clientip>.*)\], user (?<consoleusername>.*)
(?<logtype>\S+) \[(?<clienttime>.*)\] IDS detected '(?<attackname>.*)' on (?<direction>.*) connection (from|to) (?<remoteip>.*) on client (?<clientname>.*) \[(?<clientip>.*)\] user (?<consoleusername>.*) and (?<action>.*) it --------------------------
سناریوهای اتصال کنسولهای مدیریتی پادویش به یکدیگر
مساله
شما چند کنسول مدیریتی پادویش در سازمان خود دارید که میخواهید به نوعی با یکدیگر ارتباط داشته باشند و مایلید سناریوهای مختلف ممکن جهت این ارتباط را بشناسید.
راهکارها
راهکار پیشنهادی (تمام امکانات)
روش پیشنهادی در اتصال کنسولهای مدیریتی به صورت ساختار سلسله مراتبی (مستر/اسلیو Master/Slave) میباشد.
در این حالت تمامی امکانات زیر فعال خواهند بود:
- دریافت بهروزرسانی: سرور پاییندست (Slave) فایل بهروزرسانی ضدویروس خود را از سرور بالادست (Master) دریافت میکند. شما میتوانید در بخش تنظیمات این موضوع را تغییر دهید.
- توزیع لایسنس: سرور بالادست میتواند لایسنس خود یا بخشی از آن را به سرور پاییندست اختصاص دهد. انجام این کار در حوزه اختیارات ادمین سرور بالادست خواهد بود.
- دریافت گزارش تجمیعی: سرور بالادست قادر خواهد بود گزارشهای سفارشی و آماری از کل زیرمجموعههای پاییندست خود تهیه نماید.
- کنترل کامل کنسول پاییندست: مشاهده وضعیت کلاینتها، تغییر تنظیمات و سیاستها، و همه اموری که از طریق کنسول قابل انجام است توسط سرور بالادست روی سرورهای پاییندست امکانپذیر خواهد بود.
- ضمنا مدیر کنسول بالادست میتواند به کاربران کنسول خود اجازه دسترسی محدود (مثلا تنها دسترسی به گزارشها، یا بخش تنظیمات یا …) را اعطا کند. تمامی موارد و دسترسیها لاگ خواهد شد. به علاوه هر کنسول زیردست میتواند مدیر خود را داشته باشد که بر روی کنسول خود کنترل کامل دارد.
راهکار دوم (نظارت از دور)
روش پیشنهادی به مدیر کنسول بالادست اجازه میدهد کنترل کاملی روی سرورهای پاییندست خود داشته باشد. در برخی سازمانها و سناریوها، دادن چنین دسترسی کنترلی به مدیر کنسول بالادست مطلوب نمیباشد؛ اما وجود روشی برای نظارت بر کنسولهای پاییندست یا توزیع لایسنس مورد نیاز میباشد. در این حالت میتوان از راهکار دوم استفاده نمود.
در این حالت تمامی امکانات زیر فعال خواهند بود:
- دریافت بهروزرسانی: سرور پاییندست (Slave) فایل بهروزرسانی ضدویروس خود را از سرور بالادست (Master) دریافت میکند. شما میتوانید در بخش تنظیمات این موضوع را تغییر دهید.
- توزیع لایسنس: سرور بالادست میتواند لایسنس خود یا بخشی از آن را به سرور پاییندست اختصاص دهد. انجام این کار در حوزه اختیارات ادمین سرور بالادست خواهد بود.
- دریافت گزارش تجمیعی: سرور بالادست قادر خواهد بود گزارشهای سفارشی و آماری از کل زیرمجموعههای پاییندست خود تهیه نماید.
- کنترل کامل کنسول پاییندست وجود نخواهد داشت.
راهکار سوم (صرفا بهروزرسانی)
این راهکار در واقع یک راهکار ارتباطی نبوده و در آن تنها سرورهای مدیریتی پادویش میتوانند بهروزرسانی ضدویروس را با یکدیگر به اشتراک بگذارند. در این راهکار مفهومی به عنوان ساختار سلسله مراتبی یا Master/Slave وجود نداشته و شما صرفا کنسول را برای دریافت آپدیت از یک مسیر فولدر اشتراکی تنظیم میکنید. هر سرور میتواند از هر تعداد سرور دیگر فایل بهروزرسانی را چک کرده و جدیدترین فایل را بردارد.
در این حالت تنها امکان زیر فعال خواهند بود:
- دریافت بهروزرسانی: سرور فایل بهروزرسانی را از مسیر اشتراکی که توسط سرور دیگری ساخته شده است برمیدارد.
- توزیع لایسنس امکانپذیر نیست.
- دریافت گزارش تجمیعی امکانپذیر نیست.
- کنترل کامل کنسول پاییندست وجود نخواهد داشت.
روش پیادهسازی راهکارها
راهکار پیشنهادی (تمام امکانات)
جهت پیادهسازی راهکار پیشنهادی، کافی است در کنسولی که به عنوان پاییندست (Slave) انتخاب کردهاید لاگین کرده و در بخش Change Server Settings > Server Hierarchy اطلاعات سرور بالادست (Master) را معرفی نمایید. تمامی امکانات برای شما فعال خواهد شد:
- بهروزرسانی به صورت پیشفرض توسط سرور بالادست توزیع خواهد شد.
- در بخش مدیریت لایسنس گزینه Change Distribution فعال شده و اجازه توزیع لایسنس را میدهد.
- دریافت گزارش تجمیعی از سرورهای زیردست در بخش Custom Reports با ویرایش یک گزارش و انتخاب برگه Advanced گزینه Generate report for slave servers انجام میگیرد.
- کنترل کامل از طریق باز کردن گزینه Slave Servers و انتخاب کنسول مدنظر امکانپذیر است.
راهکار دوم (نظارت از دور)
در صورتیکه تمایل ندارید کنترل کامل کنسولهای پاییندست را به مدیر کنسول بالادست بدهید، کافیست از همان روش گفته شده در راهکار قبلی استفاده کنید و سرورها را Master/Slave کنید؛ اما تنها تفاوت این راهکار در بستن پورت ۱۳۹۱۱ سرور پاییندست خواهد بود. به نحوی که سرور پاییندست پورت ۱۳۹۱۱ سرور بالادست را ببیند، اما ارتباط برعکس (Master به Slave) مقدور نباشد.
به این ترتیب تمامی امکانات به جز کنترل کنسول پاییندست فعال خواهند شد.
راهکار سوم (صرفا بهروزرسانی)
به صورت پیشفرض سرور مدیریتی پادویش یک فولدر اشتراکی به نام PadvishUpdate ساخته و آخرین فایل بهروزرسانی خود را در آن قرار میدهد.
بنابراین برای راهاندازی دریافت خودکار بهروزرسانی بین سرورها (در حالتی که Master/Slave پیاده نشده باشد) شما تنها به بخش تنظیمات Change Server Settings بخش Server Update Settings رفته و آدرس فولدر اشتراکی سرور مقصد را در لیست وارد میکنید. به این ترتیب سرور شما فایل بهروزرسانی را از طریق این فولدر اشتراکی دریافت خواهد نمود.
نحوه پشتیبانگیری و زمان نگهداری پشتیبانها در کنسول مدیریتی پادویش
سوال
نحوه پشتیبانگیری خودکار از پایگاه داده کنسول مدیریتی پادویش چگونه است و این پشتیبانها در چه مسیری و تا چه زمانی نگهداری میشوند؟
پاسخ
- به صورت پیشفرض، کنسول مدیریتی پادویش روزانه و در ساعت دو بامداد از پایگاه اطلاعات خود (شامل اطلاعات کلاینتها و گروهها، لاگها و تنظیمات و …) پشتیبان تهیه میکند.
- محل پیشفرض ذخیرهسازی پشتیبانها
C:\Program Files (x86)\Amnpardaz\Server\DBBackup
است. - ساعت پشتیبانگیری و محل ذخیره پشتیبانها در بخش Server Settings برگه Backup Settings قابل تغییر میباشد.
- در مورد حذف پشتیبانهای قدیمی کنسول مدیریتی پادویش از الگوریتم زیر بهره میبرد:
- تا دو هفته، هیچ پشتیبانی حذف نمیشود. در نتیجه تا دو هفته پشتیبان به صورت روزانه وجود خواهد داشت.
- پس از دو هفته، به مدت یک ماه بکاپها به صورت هفتگی نگهداری میشوند. (از پایان هفته دوم تا پایان هفته ششم، هر هفته تنها یک بکاپ نگهداری میشود)
- پس از دو هفته + یک ماه، تا مدت یکسال پس از آن بکاپها به صورت ماهانه نگهداری میشوند.
- به این ترتیب مجموعا چهارده بکاپ روزانه، چهار بکاپ هفتگی و دوازده بکاپ ماهانه نگهداری میشود.
- علاوه بر مکانیزم بالا، یک سقف حجمی برای نگهداری بکاپها نیز وجود دارد که در صورت افزایش حجم بکاپها از این سقف، بکاپها حذف خواهند شد.
- به صورت پیشفرض این سقف معادل ۲۵ گیگابایت تنظیم شده است.
- این سقف از طریق کلید رجیستری زیر قابل تعیین است:
- کلید:
HKEY_LOCAL_MACHINE\SOFTWARE\AmnPardaz\Server
- مقدار:
BackupSizeSoftLimitGB
از نوعDWORD
- عدد تنظیم شده در این کلید سقف نگهداری بکاپها در مقیاس گیگابایت میباشد. (عدد ۲۵ به معنی ۲۵ گیگابایت تلقی خواهد شد)
چگونه نمایش کنسول مدیریتی پادویش را به حالت پیشفرض بازگردانم؟
مساله
- ستونهای جدول Managed Computers (یا هر جدول دیگری) در کنسول مدیریتی پادویش بهم ریخته یا جابجا شده است. چگونه میتوانم کنسول را به حالت پیشفرض بازگردانم؟
- یکی از ستونها نمایش داده نمیشود. چگونه میتوان این مساله را حل نمود؟
راهکار
نحوه و ترتیب نمایش ستونهای جداول مختلف در کنسول مدیریتی پادویش، در پروفایل کاربری شما در ویندوز ذخیره میشود تا هر بار کنسول را باز میکنید با ظاهر و چینشی که ترجیح دادهاید کنسول را ببینید.
اگر به هر علتی قصد بازگردانی کنسول به حالت پیشفرض را دارید، کافیست این اطلاعات را در رجیستری ویندوز حذف نمایید:
- اگر کنسول مدیریتی پادویش باز است، آن را ببندید.
- برنامه رجیستری ویندوز
regedit
را اجرا نمایید. - به کلید زیر بروید:
HKEY_CURRENT_USER\SOFTWARE\AmnPardaz\Padvish Management Console\UI
- در زیر این کلید، تعدادی کلید با نامهای
ProfileSetting.0
و … خواهید دید. همه این زیرکلیدها که با عبارتProfileSetting
آغاز میشوند را حذف نمایید. - کنسول مدیریتی پادویش را باز کنید. اکنون نمایش ستونها و رابط کاربری به حالت پیشفرض بازگشته است.
در صورت بستن CDROM پرینترهای HP LaserJet 1100 نیز بسته میشوند.
مساله
- کنترل ابزار پادویش اجازه کار به پرینتر HP LaserJet 1102 را نمیدهد. چه باید کرد؟ این دستگاه به عنوان CDROM شناخته میشود و تا CDROM باز نشود پرینت انجام نمیگیرد.
علت مساله
این مساله در مورد پرینترهای HP سری ۱۱xx در مورد انواع DLPهای نرمافزاری منجمله پادویش رخ میدهد.
علت این است که درایور این پرینترها اتصال دستگاه مجازی سیدیرام خود را چک کرده و اگر متصل نباشد به خیال اینکه پرینتر به دستگاه متصل نیست اجازه پرینت را نمیدهد.
توضیح بیشتر:
این پرینترها مانند بسیاری از مدلهای دیگر، هنگام اتصال به سیستم چندین دستگاه مختلف را به سیستم معرفی میکنند. به عنوان مثال یک پرینتر/اسکنر ممکن است دستگاههای زیر را متصل کند: پرینتر، اسکنر، سیدیرام، فلش. از سیدیرام و فلش جهت نصب درایور پرینتر استفاده میشود. در این سری از پرینترهای HP، درایور پرینتر به جای تست اتصال خود پرینتر، از اتصال/عدم اتصال سیدیرام برای فهمیدن اینکه دستگاه متصل است یا خیر استفاده میکند.
راهکار اول – بهروزرسانی درایور پرینتر
از آنجاییکه این مساله در مورد انواع DLPهای نرمافزاری رخ میدهد، شرکت سازنده پرینتر درایور خود را بهروز کرده و این نقیصه را برطرف کرده است.
جهت آپدیت درایور میتوانید به سایت HP مراجعه کرده و آخرین درایور مربوطه را دانلود کنید.
راهکار دوم – استثنا کردن پرینتر در پادویش
در صورتیکه آپدیت درایور ممکن نبوده یا به علت گستردگی کلاینتها دشوار باشد، میتوانید دستگاه سیدیرام پرینتر را در کنترل ابزار پادویش مجاز نمایید.
برای این کار از دو روش میتوانید استفاده کنید:
- استفاده از بخش ابزارهای مورد اعتماد (Trusted Devices) در کنترل ابزار، همه سیدیرامهای مربوط به این دستگاهها را یافته و استثنا کنید.
این روش امنتر و سادهتر است، اما اشکالش این است که اگر سیستمی دارای پرینتر بعدا به جمع کلاینتهای شما اضافه شود باید این کار را برای آن تکرار کنید. - از روش استثنا برحسب VendorID و ProductID استفاده نمایید. (روش انجام این کار)
در این روش سیدیرامها بر اساس مولفه VendorID و ProductID استثنا میشوند و اگر بعدا پرینتری از این نوع اضافه شود نیز به صورت خودکار در همین قاعده قرار خواهد گرفت.
تهدید Miner.JS.CoinHive.a به چه معناست و چگونه با آن برخورد کنیم؟
مساله
- در لاگهای سامانه تشخیص و جلوگیری نفوذ پادویش (IPS) تهدیدی با عنوان Miner.JS.CoinHive.a یا CoinHive.MinerScript مشاهده میشود. معنی این تشخیص چیست و چگونه باید با آن برخورد نمایم؟
- پادویش من حملهای را از آدرس DNS سرور و روی پورت ۵۳ (یا سرور پراکسی روی پورت مربوطه) تشخیص داده است. نام تهدید Miner.JS.CoinHive.a است.
مفهوم پیام
مرورگر شما به سایتی متصل شده است که حاوی اسکریپت استخراج رمزارز بوده است.
امروزه برخی سایتها (حتی سایتهای فارسی، خبرگزاریها و …) بدون اجازه کاربران، اسکریپتهای استخراج رمزارزهای دیجیتال را روی صفحات خود قرار میدهند، و در نتیجه بدون اینکه شما اطلاع داشته باشید، هنگام مشاهده سایت سیپییوی سیستم یا گوشی شما درگیر شده و برای مدیر سایت درآمد کسب میکند. همچنین برخی حملات میتوانند باعث آلوده شدن یک سایت به این اسکریپتها یا روشهای دیگری شوند که در ادامه شرح داده میشود.
پادویش این نوع اسکریپتها را تشخیص داده و از بارگزاری آن روی سیستم شما جلوگیری میکند. تشخیص Miner.JS.CoinHive.a یکی از همین انواع تشخیص است که توسط سامانه جلوگیری از نفوذ (Intrusion Prevention System) پادویش تشخیص و خنثی میشود. این مولفه وظیفه محافظت از سیستم شما در برابر حملات شبکهای را برعهده دارد.
برخورد با این پیام
توجه کنید که در هنگام مواجه با این پیام، سه حالت کلی امکانپذیر است:
- سایت هک شده و بدون اطلاع مدیر سایت اسکریپت روی آن قرار گرفته است – در سمت کلاینت شما نیازی به کاری نیست. (میتوانید به مدیر سایت آلوده اطلاع دهید).
- مدیر سایت تعمدا اسکریپت رمزارز را روی صفحات خود قرار داده است – در سمت کلاینت شما نیازی به کاری نیست. (میتوانید به مدیر سایت مزبور اطلاع دهید).
- یکی از تجهیزات شبکه در میانه راه، اسکریپت را در سایتها درج میکند – این یک مساله جدی است. اگر روتر میکروتیک در شبکه خود دارید حتما آن را بررسی کنید.
ضمنا خوب است به خاطر داشته باشید که این پیام یک تهدید یا حمله کلاسیک نیست و سیستم شما در خطر نیست. پادویش جلوی دریافت و اجرای اسکریپت استخراج را نیز گرفته و در نتیجه سیپییوی سیستم شما درگیر نیست. بنابراین – به جز حالت خاص سوم که تجهیز شبکه شما آلوده است – نیازی به کار دیگری ندارید.
تجهیزات میکروتیک و حمله استخراج رمزارز
این بخش برای مدیران شبکه نوشته شده است.
تجهیزات میکروتیک با شماره نسخه سیستم عامل ۶.۴۲ و پایینتر، یک آسیبپذیری خطرناک دارند (CVE-2018-14847) که به هر کسی که بتواند به پورت کنترل دستگاه متصل شود، دسترسی ادمین جهت تغییر تنظیمات دستگاه را میدهد.
در حال حاضر حملاتی در دنیا (و در ایران) در جریان است که با استفاده از این آسیبپذیری، کنترل دستگاه میکروتیک را در اختیار میگیرد و از این پس، دستگاه شما در آدرس تمام وبسایتهایی که کاربران مشاهده میکنند اسکریپت استخراج رمزارز را تزریق میکند.
سیستم جلوگیری از نفوذ پادویش، جلوی اجرای اسکریپت استخراج رمزارز بر روی کلاینت را میگیرد. اما کنترل میکروتیک شما میتواند تبعات جدیتری به دنبال داشته و باعث اختلال یا هک کامل شبکه شما شود و باید هرچه سریعتر برطرف گردد:
- تمام تجهیزات میکروتیک را بررسی و آنها را به آخرین نسخه ارتقا دهید – ضمنا بهتر است قبل از ارتقا حتما از تنظیمات بکاپ بگیرید.
- فایروالهای شبکه و تنظیمات میکروتیک را تصحیح کنید – پورت کنترل تجهیزات شبکه شما نباید برای عموم رایانهها قابل دسترسی باشند. با تعریف vlan مناسب، دسترسی را به صرف سیستمهای مدیریتی و ادمین محدود کنید.
مفهوم پیام Unregistered client (%computerName%) login rejected در کنسول مدیریتی پادویش و نحوه برخورد با آن
مساله
در کنسول مدیریتی پادویش، در بخش Logs and Reports > Server Logs
لاگهایی با MessageID=9 با پیام Unregistered client (%computerName%) login rejected
مشاهده میکنید. مفهوم این پیام و نحوه برخورد با آن در ادامه توضیح داده شده است.
مفهوم پیام
برای درک مفهوم پیام و شرایط رخداد آن باید با مفهوم رجیستر و اتصال کلاینت آشنا شوید.
هر کلاینتی که به سرور مدیریتی پادویش متصل میشود باید قبلا در سرور رجیستر شده باشد. این کار به صورت خودکار در شرایط زیر انجام میگیرد:
برای کلاینتهایی که به صورت نصب از راه دور نصب میشوند، یا از فایل کانفیگ rgc استفاده میکنند در همان زمان نصب انجام میگیرد. برای کلاینتهایی که به صورت دستی و از طریق مدیریت مجوز به سرور اضافه میشوند نیز در زمان اولین اتصال به سرور این کار انجام میگیرد.
پس از این، هر بار که کلاینت به سرور متصل میشود (مثلا پس از ریستارت سیستم) در ابتدا خود را – با توجه به رجیستر قبلی – به سرور معرفی میکند. اگر کلاینت در سرور رجیستر شده و در دیتابیس سرور موجود باشد این اتصال موفقیت آمیز بوده و پیام MessageID=8 با محتوای Client %computerName% connected.
ثبت خواهد شد.
اما اگر کلاینت برای سرور ناشناس باشد پیام MessageID=9 یعنی Unregistered client (%computerName%) login rejected
در لاگ ثبت شده و سرور اتصال را قطع میکند.
بنابراین این پیام در شرایطی رخ میدهد که کلاینت فکر میکند لایسنس تحت سرور شما فعال است، ولی سرور کلاینت را در لیست خود نمیشناسد. چنین اتفاقی ممکن است در یکی از حالات زیر رخ دهد:
- انتخاب عمل Unregister کلاینت توسط ادمین کنسول: اگر یک کلاینت از طریق کنسول مدیریتی پادویش Unregister شود (کلیک راست روی کلاینت و انتخاب گزینه Unregister Client) این لاگ یکبار و فقط یکبار در لاگ سرور درج خواهد شد. دقت کنید که اگر لاگ تکرار میشود علت مربوط به یکی از موارد زیر است.
- بازگردانی بکاپ دیتابیس سرور به قبل از رجیستر شدن کلاینت: معمولترین دلیل برای این اتفاق، این است که شما بکاپ دیتابیس سرور را به زمانی بازگردانی کردهاید که کلاینت مزبور در دیتابیس سرور وجود نداشته است. به عنوان مثال شرایطی را در نظر بگیرید که سرور روز شنبه بکاپ گرفته شده، سپس روز یکشنبه کلاینت به سرور اضافه شده، و نهایتا در روز دوشنبه دیتابیس را به بکاپ شنبه بازگردانی کردهاید. در این شرایط، تا جایی که کلاینت مطلع است تحت سرور فعال است، اما سرور به علت بازگردانی دیتابیس از وجود چنین کلاینتی بیاطلاع است و این پیام رخ میدهد.
- بازگردانی اسنپشات روی سیستم کلاینت: در یک حالت نادر ولی مشابه، ممکن است سناریو به صورت برعکس رخ دهد. یعنی کلاینت ابتدا تحت سرور فعال بوده و سپس منفک (Unregister) شده است. اگر اکنون بکاپی روی سیستم کلاینت بازگردانی شود (مانند بازگردانی کلاینت در ماشین مجازی به یک اسنپشات قدیمی) که در آن کلاینت تحت سرور فعال بوده، بازهم شرایط بالا رخ خواهد داد.
نحوه برخورد و رفع این پیغام
در این شرایط منطقی است که کلاینت مجددا به کنسول مدیریتی پادویش افزوده شود. این کار قاعدتا به اجازه شما به عنوان مدیر کنسول نیاز دارد و از یکی از طرق زیر قابل انجام است:
راهکار اول – انجام Push Install
سادهترین روش حل مساله این است که از روی سرور مدیریتی پادویش بر روی کلاینتهای یتیم یکبار Push Install انجام دهید. این کار با انتخاب سیستمها در بخش Discovered Computers و کلیک راست روی نام سیستم یا ساخت جداگانه یک تسک Push Install قابل انجام است.
راهکار دوم – حذف مجوز استفاده و فعالسازی مجدد کلاینت
اگر پای سیستم کلاینت هستید میتوانید در بخش مدیریت مجوز استفاده، گزینه غیرفعالسازی را انتخاب کرده و سپس کلاینت را مجددا تحت سرور مدیریتی فعال نمایید.
راهکار سوم – تنظیم سرور برای افزودن خودکار کلاینتهای یتیم
این روش هنگامی که تعداد کلاینتهای یتیم بالا بوده و امکان Push Install نیز وجود ندارد کاربرد دارد. در این روش شما سرور مدیریتی را طوری تنظیم میکنید که به محض رویت کلاینت جدید آن را بدون احراز هویت به دیتابیس خود اضافه کند. در نتیجه توصیه میشود که این روش به مدت محدود استفاده شده و بعد از رفع مشکل تنظیمات را به حالت اول بازگردانید.
- سرویس سرور مدیریتی امنپرداز را متوقف کنید. (این کار با مراجعه به بخش services.msc ویندوز و Stop کردن سرویس «سرور امنپرداز» انجام میشود)
- برنامه regedit را باز نمایید.
- به آدرس
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AmnPardazServerWinService
بروید. - در سمت راست بر روی مقدار
ImagePath
دوبار کلیک کنید. - در انتهای عبارت موجود و بعد از کاراکتر (“)، یک فاصله گذاشته و یکی از دو عبارت
/import_eps
(برای ضدویروس پادویش نسخه امنیت پیشرفته یا امنیت کامل) یا/import_pcp
(برای ضدباجگیر پادویش) را اضافه کنید.- مثلا:
"C:\Program Files (x86)\AmnPardaz\Server\x64\AmnPardazServer.exe" /import_eps
- مثلا:
- سرویس سرور مدیریتی را مجددا Start نمایید.
- از این به بعد کلاینتهای یتیم به طور خودکار به لیست Managed Computers شما افزوده خواهند شد.
نکته: دقت کنید که این راهکار فقط در صورتی قابل استفاده است که شما بکاپ سرور مدیریتی خود را داشته و برگردانده باشید. اگر بکاپ سرور مدیریتی را نداشته و آن را از دست دادهاید و اکنون یک سرور مدیریتی جدید راهاندازی نمودهاید، فقط میتوانید از یکی از راهکارهای اول و دوم استفاده نمایید.
علت این مساله این است که کلاینتها سرور مدیریتی را با کمک کلید عمومی آن شناسایی مینمایند که در دیتابیس سرور وجود دارد. اگر این کلید از دست برود، کلاینتها سرور مدیریتی جدید را شناسایی نکرده و به همین علت تحت آن اضافه نخواهند شد و فرامین آن را نمیپذیرند.
نکات مربوط به فعالسازی گزینه Prevent DNS changes در بخش IPS ضدویروس پادویش
علائم و نشانهها
- در کنترل پنل ویندوز، بخش Change adapter settings، روی کارت شبکه امکان تعریف و تغییر تنظیمات DNS وجود ندارد.
- کلاینت برای دریافت آیپی خودکار (DHCP) تنظیم شده است اما این کار انجام نشده و شبکه وصل نمیشود.
- در هنگام اتصال به VPN، اتصال به درستی انجام میشود اما ارتباط برقرار نمیشود. پس از بررسی مشخص میشود که کلاینت شما IP نگرفته است.
- در هنگام نصب برخی نرمافزارهای VPN مانند کیهان دچار خطا میشوید.
علت مساله
علت این اتفاقات این است که گزینه «Prevent applications from changing DNS settings(Not Recommended)
» اشتباها روی سرور ضدویروس شما فعال شده است.
کاربرد این گزینه جلوگیری از تغییر تنظیمات DNS در روی کلاینتها میباشد، تا از دستکاری غیرمجاز تنظیمات توسط کاربران یا برنامهها جلوگیری شود. (به عنوان مثال برخی برنامههایی که به عنوان نرمافزار رایگان از اینترنت قابل دریافت هستند بدون اجازه کاربر تنظیمات وی را تغییر میدهند و موجب عدم اتصال وی به پورتالهای سازمانی میشوند) با توجه به کارکرد آن، این گزینه فقط باید در شبکههایی که از تنظیمات آیپی غیرخودکار (شبکههای بدون DHCP) استفاده میکنند فعال شود.
همانگونه که در توضیحات این گزینه آورده شده است، فعال کردن آن بدون رعایت پیشنیازها میتواند جلوی عملکرد DHCP و موارد مشابه (مانند دریافت IP در اتصال VPN) را بگیرد و حتی موجب اختلال در اتصال کلاینتها به شبکه گردد.
راهحل
- در صورتیکه این گزینه به اشتباه فعال شده است:
- در کنسول پادویش روی گروه کلاینت مربوطه کلیک راست کرده و گزینه
Change Client Settings > Padvish Antivirus
را انتخاب نمایید. - به بخش
Firewall and IPS
بروید. - گزینه
Prevent applications from changing DNS settings(Not Recommended)
را غیرفعال نمایید. - پنجره را با
OK
ببندید. - در صورت لزوم سایر گروههای کلاینتی تعریف شده را بررسی کرده و مراحل بالا را برای آنها تکرار نمایید.
- پس از انجام کار، اطمینان حاصل کنید که کلاینتها یکبار به سرور متصل شده و تنظیمات را دریافت کردهاند تا مساله برطرف شود.
کد پیغامهای لاگهای سرور مدیریتی و نظارتی پادویش
جدول زیر شامل کد پیغامهایی است که در بخش Server logs در کنسول مدیریتی/نظارتی پادویش قابل مشاهده است.
Message ID | Message |
---|---|
۱ | IP discovery manager started. |
۲ | Active directory discovery manager started. |
۳ | Agent not found at path “%agent%”. |
۴ | Impersonate logged on user failed for account %domain%\%user% with error: %win32ErrorCode%. |
۵ | Discovering %target% failed with error: %win32ErrorCode%. |
۶ | Discovering %target% succeeded. |
۷ | Active directory login of user %user% failed on %domain% with error: %win32ErrorCode%. |
۸ | Client %computerName% connected. |
۹ | Unregistered client (%computerName%) login rejected. |
۱۰ | Console login with user %username% accepted. |
۱۱ | Console login with user %givenUsername% rejected, %rejectReason%. |
۱۲ | Unidentified client disconnected. |
۱۳ | Client %clientName% disconnected. |
۱۴ | Console logout of user %username%. |
۱۵ | Client %clientName% removed by user %username%. |
۱۶ | Report %reportName% removed by user %username%. |
۱۷ | Signature version %version% added by user %username%. |
۱۸ | Default config of client type %clientType% changed on group “%groupName%” by user %username%. |
۱۹ | Serial number %serialNumber% activated online by user %username%. |
۲۰ | Serial number %serialNumber% activated offline by user %username%. |
۲۱ | User %addedUsername% added by user %username%. |
۲۲ | User %removedUsername% removed by user %username%. |
۲۳ | User %updatedUsername% updated by user %username%. |
۲۴ | Group %groupName% added by user %username%. |
۲۵ | Group %groupName% updated by user %username%. |
۲۶ | Group %groupName% removed by user %username%. |
۲۷ | Client %clientName% moved from group %oldGroupName% to group %groupName% by user %username%. |
۲۸ | Padvish antivirus password changed on group %groupName% by user %username%. |
۲۹ | Push install failed because agent type “%agentType%” was not supported. |
۳۰ | Begin discovery from active directory settings. |
۳۱ | Starting to discover computers from domain %domain% on dc %domainController%. |
۳۲ | Finished discovering computers from domain %domain% on dc %domainController%. |
۳۳ | Auto install manager started. |
۳۴ | Starting to discover IP range %target%. |
۳۵ | Finished discovering IP range %target%. |
۳۶ | Going to discover single IP %target%. |
۳۷ | Begin discovery from IP settings. |
۳۸ | Starting to discover IP subnet %target%. |
۳۹ | Finished discovering IP subnet %target%. |
۴۰ | Login of user %domain%\%user% to share %share% failed with error %win32ErrorCode%. |
۴۱ | Login of user %domain%\%user% to share %share% succeeded. |
۴۲ | Install agent [%agentName%] failed. %agentResult%. |
۴۳ | Install agent [%agentName%] succeeded. |
۴۴ | Could not create agent config file in %configPath%. |
۴۵ | Copy of %source% to remote %destination% failed with error %win32ErrorCode%. |
۴۶ | Could not create service %serviceName% on %computerName% with error %win32ErrorCode%. |
۴۷ | Could not delete service %serviceName% on %computerName% with error %win32ErrorCode%. |
۴۸ | Could not open service %serviceName% on %computerName% with error %win32ErrorCode%. |
۴۹ | Preparing to create service %serviceName% with path %servicePath% on %computerName%. |
۵۰ | Could not query service %serviceName% on %computerName% with error %win32ErrorCode%. |
۵۱ | Could not connect to remote service manager with error %win32ErrorCode%. |
۵۲ | Service %serviceName% already running on %computerName%. |
۵۳ | Could not start service %serviceName% on %computerName% with error %win32ErrorCode%. |
۵۴ | Scheduling %computerName% for automatic installation of product type %productType% because of rule %ruleName%. |
۵۵ | Automatic install rule %ruleName% ignored for %computerName% because of field [%fieldName%]. |
۵۶ | Going to check if product %productType% needs to be install on %computerName% due to rule %ruleName%. |
۵۷ | Agent [%agentName%] successfully started on %computerName%, waiting for results. |
۵۸ | Discovery from IP settings cancelled. |
۵۹ | Discovery from active directory settings cancelled. |
۶۰ | Discovery from IP settings finished. |
۶۱ | Discovery from active directory settings finished. |
۶۲ | Going to push install product %productType% on %computerName%. |
۶۳ | Failed to read push install agent [%agentName%] result file at %path% with error %errnostr% (%errno%). |
۶۴ | Failed to read discovery result file at %path% with error %errnostr% (%errno%). |
۶۵ | Cleanup completed for “%recordType%”: %deletedsCount% records older than %thresholdValue% days were removed. Current record count is %remainingsCount% |
۶۶ | Cleanup failed for “%recordType%”, records older than %thresholdValue% days should be removed. Current record count is %remainingsCount% |
۶۷ | Supervisor server certificate was received and stored from %IP% Thumbprint: %thumbprint% |
۶۸ | Supervisor server connection was attempted and rejected from %IP% and the reject reason is %reason%, Thumbprint: %thumbprint% |
۶۹ | Supervisor server connection was accepted from %IP% Thumbprint: %thumbprint% |
۷۰ | Supervisor server certificate (%removingTime%) was removed. Thumbprint: %thumbprint% |
۷۲ | Connected to management server. |
۷۳ | Management server certificate thumbprint mismatch. Expected: %expectedThumbprint%, Got: %gotThumbprint% |
۷۴ | Management Server certificate was removed. Thumbprint: %thumbprint% |
۷۵ | Management server certificate was received and stored. Thumbprint: %thumbprint% |
۷۶ | Account password changed by user %username%. |
۷۷ | Connection to management server %serverAddress% has been deleted by %adminName%. |
۷۸ | New connection to management server %serverAddress% created by %adminName%. |
۷۹ | Unable to connect to Management Server. (error code: %connectionErrorCode% – %connectionErrorMessage%) |
۸۰ | Remote uninstall of %productName% on %clientName% requested by %adminName%. |
۸۱ | Client %computerName% registered by user %username%. |
۸۲ | Client %computerName% requested to be unregistered. |
۸۳ | Signature version %version% activate by user %username%. |
۸۴ | Signature version %version% staged by user %username%. |
۱۰۰۰ | Successfully registered slave server %serverName%, Slave Thumbprint: %slaveThumbprint% |
۱۰۰۱ | Slave server %serverName% registration failed, Error: %errorText%, Slave Thumbprint: %slaveThumbprint% |
۱۰۰۲ | Slave server %serverName% successfully connected |
۱۰۰۳ | Slave server %serverName% login failed, Error: %errorText% |
۱۰۰۴ | Slave server %serverName% disconnected |
۱۰۰۵ | Slave server %serverName% unregistered, Slave Thumbprint: %slaveThumbprint% |
۱۰۰۶ | Slave server %serverName% unregister failed, Error: %errorText%, Slave Thumbprint: %slaveThumbprint% |
۱۰۰۷ | Slave requested update for timestamp %timestamp%, Result: %resultText% |
۱۰۰۸ | Slave upgrade from %slaveVersion% to %targetVersion% failed, Reason: %reason$ |
۱۰۰۹ | Slave is already up to date with version %targetVersion% |
۱۰۱۰ | Slave upgrade from %slaveVersion% to %targetVersion% requested by %username% |
۱۰۱۱ | Upgrade file sent to slave. |
۱۰۱۲ | Received and executed an upgrade file for Padvish Management Server. |
۱۵۰۰ | Successfully registered under master server %serverAddress%, Master Thumbprint: %masterThumbprint% |
۱۵۰۱ | Cannot register under master server %serverAddress%, Error: %errorText% |
۱۵۰۲ | Successfully logged in to master server %serverAddress% |
۱۵۰۳ | Login to master server %serverAddress% failed, Error: %errorText% |
۱۵۰۴ | Successfully changed master server address from %oldServerAddress% to %newServerAddress%, Master Thumbprint: %masterThumbprint% |
۱۵۰۵ | Master server address change from %oldServerAddress% to %newServerAddress% failed, Error: %errorText% |
۱۵۰۶ | Disconnected from master server %serverAddress% |
۱۵۰۷ | Successfully unregistered from master server %serverAddress% |
۱۵۰۸ | Forcefully unregistered from master server %serverAddress% |
۱۵۰۹ | Unregister from master server %serverAddress% failed, Error: %errorText% |
۲۵۰۰ | Supervisor server disconnected.Thumbprint: %thumbprint% |
راهنمای راهاندازی Syslog در کنسول مدیریتی پادویش
مقدمه
در این سند ماژول Syslog در کنسول مدیریتی پادویش و تنظیمات و امکانات موجود در آن تشریح شده است.
پس از مطالعه این سند، خواننده معماری این ماژول را درک نموده و قادر خواهد بود که کنسول مدیریتی پادویش را برای ارسال لاگ مطابق پروتکل Syslog به یک لاگسرور یا سامانه SIEM و مانند آن پیکربندی کند. همچنین لیست پیغامهای ضدویروس پادویش به همراه شیوه پردازش آنها در انتهای سند آورده شده است.
درباره پروتکل Syslog
پروتکل Syslog پروتکل ارسال و جمعآوری لاگهای متنی از انواع تجهیزات مختلف در شبکه است. این لاگها میتوانند همه نوع محتوایی از عملکرد سیستم، رخدادهای ارتباطی، وقایع امنیتی و غیره را در بر بگیرند و اصولا پیغامهایی متنی با اندکی فراداده ثابت (مانند تاریخ و محل و درجه اهمیت رخداد) هستند که برای هر تجهیز یا سامانه باید مطابق الگوی خاص آن پردازش شوند.
پیشفرض پروتکل Syslog ارسال پکت از نوع UDP بر روی پورت ۵۱۴ است ولی انواع دیگر مبتنی بر TCP و رمزنگاری نیز دارد. در حال حاضر کنسول مدیریتی پادویش از ارسال اطلاعات مبتنی بر UDP پشتیبانی میکند.
از آنجاییکه هدف این پروتکل جمعآوری کل اطلاعات در یک محل واحد و پردازش آنهاست، قبل از ادامه باید شما یک Syslog Server یا سامانهای که قابلیت دریافت این پیغامها را داشته باشد در شبکه خود مستقر کرده و یک IP و آدرس مشخص قابل دسترس برای آن تعیین کرده باشید.
ماژول Syslog در کنسول مدیریتی پادویش
معماری ارتباطی
با انجام تنظیمات زیر در سرور مدیریتی پادویش، میتوانید این لاگها را که شامل رخدادهای سیستمهای کلاینت است را از طریق پروتکل Syslog دریافت نمایید.
مکانیزم ارسال به این شکل است که کلاینتهای پادویش مرتبا گزارشها و لاگهای خود را به سرور مدیریتی پادویش ارسال میکنند. به محض دریافت این لاگها، سرور مدیریتی لاگ را به فرمت مناسب توسط پروتکل Syslog به یک یا چند سرور ارسال میکند. بدین ترتیب کلاینتها به صورت مستقیم با سرور Syslog در ارتباط نیستند و تنها لازم است سرور مدیریتی پادویش قادر به ارسال پکت به سمت این سرور باشد.
روش انجام تنظیمات Syslog در کنسول مدیریتی پادویش
جهت انجام تنظیمات، باید یک فایل log.cfg در مسیر اصلی نصب سرور پادویش – معمولا C:\Program Files (x86)\Amnpardaz\Server\log.cfg
– ایجاد نموده و تنظیمات زیر را در آن انجام دهید:
rootCategory=DEBUG,Syslog appender.Syslog=SyslogAppender appender.Syslog.syslogName=Padvish appender.Syslog.syslogHost=۱۹۲.۱۶۸.۰.۱ appender.Syslog.portNumber=۵۱۴ appender.Syslog.facility=1 appender.Syslog.layout=PatternLayout appender.Syslog.layout.ConversionPattern=1 %d{%Y-%m-%dT%H:%M:%S,%lZ} PadvishManagementServer PMS - - - %-5p %c{2} %m%n
در این تنظیمات آیپی سرور syslog و پورت مربوطه (پیشفرض ۵۱۴ استاندارد) جهت دریافت لاگها قابل تغییر است.
در موارد معدودی که نیاز به ارسال لاگ به صورت همزمان به چندین لاگ سرور مقصد باشد میتوان از تنظیمات به شکل زیر استفاده نمود و تعداد سرورهای جدید را معرفی نمود:
rootCategory=DEBUG,Syslog1,Syslog2 appender.Syslog1=SyslogAppender appender.Syslog1.syslogName=Padvish appender.Syslog1.syslogHost=۱۹۲.۱۶۸.۰.۱ appender.Syslog1.portNumber=۵۱۴ appender.Syslog1.facility=1 appender.Syslog1.layout=PatternLayout appender.Syslog1.layout.ConversionPattern=1 %d{%Y-%m-%dT%H:%M:%S,%lZ} PadvishManagementServer PMS - - - %-5p %c{2} %m%n appender.Syslog2=SyslogAppender appender.Syslog2.syslogName=Padvish appender.Syslog2.syslogHost=۱۹۲.۱۶۸.۰.۲ appender.Syslog2.portNumber=۵۱۴ appender.Syslog2.facility=1 appender.Syslog2.layout=PatternLayout appender.Syslog2.layout.ConversionPattern=1 %d{%Y-%m-%dT%H:%M:%S,%lZ} PadvishManagementServer PMS - - - %-5p %c{2} %m%n
راهنمای پیغامهای Syslog کنسول مدیریتی پادویش
همانند اکثر محصولات، پیغامهای Syslog در کنسول مدیریتی پادویش با قالبی ارسال میشوند که برای کاربران و مدیران شبکه قابل فهم باشند. جهت پردازش ماشینی لازم است این پیغامها parse شوند.
در ادامه لیست مجموعه این پیغامها به همراه نکات مربوط به آنها خواهد آمد:
انواع پیغام های سرور پادویش | نوع لاگ | |
---|---|---|
۱. | [%datetime%] Malware '%malwarename%' found in client %computername% [%ip%] on path '%malwarepath%', action={Ignore/Delete/Quarantine/Disinfect/Deny}, result={Fail/Success} |
تشخیص بدافزار |
۲. | [%datetime%] Device Control turned on by '%username%' on client %computername% [%ip%] user %consoleusername% |
روشن/خاموش کنترل ابزار |
۳. | [%datetime%] Device Control turned off by '%username%' on client %computername% [%ip%] user %consoleusername% |
|
۴. | [%datetime%] Firewall turned on by '%username%' on client %computername% [%ip%] user %consoleusername% |
روشن/خاموش فایروال |
۵. | [%datetime%] Firewall turned off by '%username%' on client %computername% [%ip%] user %consoleusername% |
|
۶. | [%datetime%] File '%filepath%' restored from quarantine by '%username%' on client %computername% [%ip%] user %consoleusername% |
بازگرداندن فایل از قرنطینه |
۷. | [%datetime%] Restore of file '%filepath%' from quarantine failed by '%username%' on client %computername% [%ip%] user %consoleusername% |
|
۸. | [%datetime%] System Guard turned on by '%username%' on client %computername% [%ip%] user %consoleusername% |
روشن/خاموش محافظت مستمر |
۹. | [%datetime%] System Guard turned off by '%username%' on client %computername% [%ip%] user %consoleusername% |
|
۱۰. | [%datetime%] Successfuly updated by '%username%' on client %computername% [%ip%] user %consoleusername% |
بروزرسانی پایگاه امضا |
۱۱. | [%datetime%] Update by '%username%' failed on client %computername% [%ip%] user %consoleusername% |
|
۱۲. | [%datetime%] Self Protection turned on by '%username%' on client %computername% [%ip%] user %consoleusername% |
روشن/خاموش محافظت از خود |
۱۳. | [%datetime%] Self Protection turned off by '%username%' on client %computername% [%ip%] user %consoleusername% |
|
۱۴. | [%datetime%] A scan was performed on client %computername% [%ip%] by '%username%'. Result='{Finished successfully/Aborted by user/Failed}', Scanned files='%d', Threats found='%d', Start Date='%datetime%', End Date='%datetime%' |
انجام پویش |
۱۵. | [%datetime%] {Allowed/Denied} connection on client %computername% [%ip%] user %consoleusername%. [Direction='{In/Out}', Remote Address='%ip%:%port%', Local Address=':%port%', Protocol='%d'] |
لاگ فایروال |
۱۶. | [%datetime%] Device Connected, Vendor='%vendor%', Product='%product%', Serial='%serial%', Action='{allowed/denied/allowed read-only}', Client='%computername% [%ip%]' |
اتصال ابزار (نسخ قدیمی) |
۱۷. | [%datetime%] Device '%type%' with ID '%serial%' connected and was '{allowed/denied/allowed read-only}' on client %computername% [%ip%], user %consoleusername% |
اتصال ابزار
(نسخ جدید) |
۱۸. | [%datetime%] IDS detected '%attackname%' on {incoming/outgoing} connection {from/to} %ip% on client %computername% [%ip%] user %consoleusername% and {allowed/denied} it |
تشخیص نفوذ |
نکات:
- در ابتدای تمامی لاگها تاریخ رخداد لاگ (مطابق تاریخ سیستم کلاینت تولید کننده رخداد) قرار میگیرد.
- عبارات درون
%%
به معنی مقدار رشتهای است که توسط سیستم جایگزین میشود. - عبارات درون
{xxx/yyy/zzz}
به معنی جایگزینی یکی از چند عبارت است. - عبارت
%d
به معنی مقدار عددی است. - عبارت
%datetime%
به معنی تاریخ به فرمت۲۰۱۸-۰۱-۲۹ ۱۳:۱۴:۱۵
است. - عبارت
%consoleusername%
در لاگها به معنی کاربری است که در لحظه رخداد لاگ، در کلاینت مزبور لاگین بوده است. این کاربر کنسول ویندوز محسوب میشود. - عبارت
%username%
به معنی کاربری است که عمل را انجام داده است. در مواردی که عملیات توسط سیستم یا از طریق سرور انجام شده باشد، این کاربر خالی یا خط فاصله (-) یا system درج میشود. (همه موارد به یک معنی است) - در لاگ فایروال، شماره پروتکل مربوط به شماره پروتکل پکت IP است. (۶ به معنی TCP و ۱۷ به معنی UDP و …)
قواعد پردازش لاگهای پادویش
جهت مشاهده قواعد regex یا Regular Expression و اتصال به نرمافزارهای آنالیز لاگ، این صفحه را مطالعه کنید:
راهنمای اتصال کنسول مدیریتی پادویش به نرمافزار Splunk و مشابه
جستجو و قاعدهگذاری کنترل ابزار از روی سازنده و محصول (VID و PID) در DeviceID
نیازمندی
- کنترل ابزار پادویش اتصال یک ابزار به رایانهای را ثبت کرده و شما میخواهید مدل و نوع ابزار را شناسایی کنید.
- شما میخواهید با استفاده از کنترل ابزار پادویش همه ابزارهای از مدل یا نوع خاصی را بلوکه یا مجاز نمایید.
راهکار
برای رفع این نیازمندی باید با ساختار شناسه ابزار یا همان Device ID آشنا شوید.
شناسه Device ID همان چیزی است که کنترل ابزار پادویش به عنوان شناسه یکتای ابزارهای جانبی لاگبرداری کرده و همچنین امکان تعریف قواعد را به شما بر این اساس میدهد.
در اوائل هر Device ID، دو بخش به نامهای Vendor ID و Product ID (یا VID و PID) دارد که شامل یک کد ۴ حرفی مشخص کننده شرکت تولیدکننده و رده محصول مربوطه است:
VID_04E8&PID_6866\3423047123&12&332
در عبارت بالا رنگ قرمز VID است که نشانگر تولیدکننده محصول و رنگ سبز PID است که نشانگر رده محصول میباشد. با جستجوی این اطلاعات در دیتابیسهای موجود در اینترنت میتوان این اعداد رمزی را به نام تولیدکننده و محصول مرتبط نمود. به عنوان مثال دو دیتابیس زیر معمولا مناسب هستند:
- https://www.the-sz.com/products/usbid/index.php?v=04E8&p=6866
- https://devicehunt.com/search/type/usb/vendor/04E8/device/6866
با استفاده از اطلاعات بالا مشخص میشود که دستگاه توسط شرکت سامسونگ تولید شده و از رده محصولات Samsung Galaxy این شرکت میباشد.
نکته ۱: در مورد برخی دستگاهها مانند Huawei یا برخی شرکتهای دیگر، ممکن است اطلاعات رده محصول پیدا نشود. چرا که اعداد PID برای رده محصول توسط هر تولیدکننده جداگانه اختصاص مییابند و دیتابیسهای عمومی این دستگاهها را ممکن است ندیده و این اطلاعات را نداشته باشند. ولی اعداد VID اصولا برای شرکتهای جهانی معتبر همواره پیدا میشود، چرا که به صورت مرکزی و توسط سازمان USB اختصاص یافته و دیتابیس آن موجود است.
نکته ۲: در مورد برخی دیوایسها (مثلا فلشهای چینی گمنام، یا دستگاههایی که استاندارد USB را رعایت نکردهاند) ممکن است اطلاعات VID نیز پیدا نشود. به هر صورت این اطلاعات چیزی است که توسط دیوایس به سیستم اعلام شده و جهت یافتن و نصب درایور استفاده میشود. در نتیجه در کاربردهای عمومیای مانند فلش و هارد که درایور خاصی نیاز ندارد احتمال اینکه دیوایس اطلاعات صحیحی به سیستم ندهد وجود دارد و نمیتوان به طور کامل به این اطلاعات اتکا نمود.
تعریف قواعد پیشرفته کنترل ابزار
برای تعریف قاعده پیشرفته کنترل ابزار که برای مدل خاصی از ابزارهای جانبی عمل کند از روش زیر استفاده کنید:
- در بخش Change Client Settings > Padvish Antivirus به برگه Device Control بروید.
- نوع ابزار مربوطه را انتخاب و آن را در حالت Advanced Rules قرار دهید. لینک You have * Advanced Rules را کلیک نمایید.
- در پنجره باز شده قاعده جدیدی اضافه کنید. (دکمه Add)
- برای فیلد Device ID گزینه Containing را انتخاب نمایید و در کادر جلویی بخشی از DeviceID را که شامل VID و PID دستگاه میشود قرار دهید. در مثال بالا:
VID_04E8&PID_6866\
- برای قاعده خود یک نام انتخاب کرده و تصمیم را بر حسب مورد روی Block یا Allow یا هر مورد دیگری قرار دهید.
- به این ترتیب این قاعده فقط با ابزارهای تعیین شده تطبیق خواهد یافت.
- توجه کنید که در حالت Advanced Rule قواعد از بالا به پایین اعمال میشوند و اولین قاعدهای که با ابزار تطبیق یابد اعمال خواهد شد. ضمنا اگر آخرین قاعده از نوع Block All نباشد همه ابزارهایی که با هیچیک از قواعد تطبیق نیافتهاند مجاز شمرده میشوند.
نکات فعالسازی Fragmented Packet در سیستم جلوگیری از نفوذ
ملاحظات فعالسازی Fragmented Packet
یکی از گزینههای موجود در سیستم جلوگیری از نفوذ پادویش (IDS/IPS) گزینه Fragmented Packet میباشد. این گزینه به صورت پیشفرض غیرفعال است.
فعال کردن این گزینه مستلزم در نظر گرفتن ملاحظاتی است:
- فعال کردن این گزینه موجب بلوکه شدن کلیه پکتهای IP که فلگ Fragment آنها روشن است خواهد شد.
- در نتیجه اگر معماری تجهیزات شبکه شما به نوعی است که بخشهای مختلف شبکه MTU های متفاوتی دارند و در نتیجه پکتها در شبکه Fragment میشوند، فعال کردن این گزینه موجب بلوکه شدن این ارتباطات خواهد شد. (نحوه رفع این موضوع در این مقاله تشریح شده است)
- همچنین برنامههایی که بر پایه ارسال بستههای بزرگ با پروتکل خام UDP یا پروتکل مشابهی نوشته شدهاند و در نتیجه پکت Fragment استفاده میکنند نیز ارتباط خود را از دست خواهند داد.
- در نتیجه فعال کردن این گزینه بدون احتیاط لازم توصیه نمیشود.
کاربرد گزینه Fragmented Packet
این گزینه برای کاربرد در شبکههای بسیار خاصی طراحی شده است.
توضیح اینکه Fragmented Packet برخلاف سایر گزینههای موجود در IPS به خودی خود نوعی حمله به شمار نمیرود. در شبکههایی که از یک تجهیز NIDS مرکزی جهت مقابله با حملات شبکه استفاده میکنند، گاهی یک مهاجم قادر است با تکهتکه کردن (اصطلاحا Fragment کردن) پکتهای حمله خود از دید NIDS مرکزی دور بماند. در چنین شبکههایی و با وجود این پیششرط که پکت Fragment شده در حالت عادی رخ ندهد میتوان از این گزینه جهت پیشگیری از این مساله استفاده نمود.
نحوه انجام کانفیگ صحیح شبکه برای جلوگیری از Fragmented Packet
همانطور که گفته شد یکی از دلایل برخورد با Packet Fragmentation وجود اشکالات در کانفیگ شبکه میباشد.
در صورتیکه شبکه شما به چنین دلیلی (مانند تفاوت MTU در لینکهای مختلف بین راه) دچار Packet Fragmentation است، با کاهش دستی MTU میتوانید این مساله را اصلاح نمایید.
در سیستمعامل ویندوز امکان تعریف MTU روی کارت شبکه از طریق خط فرمان وجود دارد:
netsh interface ipv4 set subinterface "Local Area Connection" mtu=۱۴۰۰ store=persistent
- توجه کنید که در دستور بالا، عبارت Local Area Connection باید با نام کارت شبکه جایگزین شود. جهت رویت نام کارتهای شبکه از دستور زیر استفاده کنید:
netsh interface ipv4 show subinterface
- دستور بالا MTU را معادل ۱۴۰۰ قرار میدهد که در اغلب موارد باید کافی باشد، اما در شبکههای مختلف باید با توجه به ظرفیت MTU لینکها احراز شود