دستورالعمل‌ها و پیشنهادهای زیر Best Practiceهای کاهش Spamهای عبوری از Cisco Email Security Appliance یا ESA با قابلیت Anti-Spam می باشد، اما باید به خاطر داشت که هر کدام منحصر به فرد بوده و ممکن است برخی از این پیشنهادات تعداد ایمیل‌های معتبری که به عنوان Spam جمع‌آوری می‌شوند را افزایش دهد.
تنظیمات اولیه
1- باید اطمینان داشت که قابلیت Anti-Spam فعال است:
تمامی رکوردهای MX از جمله آنهایی که الویت کمتری دارند باید ایمیل‌ها را از طریق ESAها Relay کنند. تمامی تجهیزات مستلزم به داشتن قابلیت Anti-Spam هستند و باید اطمینان حاصل نمود که در تمامی Policyهای دریافت ایمیل Anti-Spam فعال است.
همواره بروزرسانی Anti-Spam باید فعال باشد و بدین جهت، لازم است بررسی شود که آخرین زمان رخداد بروزرسانی در دو ساعت اخیر بوده است.
2- باید مطمئن شد که پیام‌ها از طریق قابلیت Anti-Spam اسکن می‌شوند:
باید یک نمونه از پیام‌های Spam گم شده را برای این Header بررسی نمود: X-IronPort-Anti-Spam Result
اگر Header پیدا نشود باید اطمینان حاصل نمود که هیچ درگاه یا فیلتر Allowlist یا پیام‌های مجاز وجود نداشته باشد که Spamها مرحله اسکن‌کردن را رد کنند. نباید پیام‌ها بخاطر پرشدن حجم قابل اسکن از این مرحله گذر کنند، حجم پیش‌فرض 262144 Byte است. کاهش این تنظیمات باعث بهبود محسوس عملکرد نمی‌شود و ممکن است باعث Scamهای از دست رفته گردد. در طی ارزیابی باید از یکسان بودن تنظیمات IPAS با سایر محصولات تست شده کسب اطمینان کرد. لازم است به سراغ تمامی درگاه‌های HAT رفت تا از روشن بودنSpam Check برای تمامی جریان‌های ورودی پیام‌ها اطمینان حاصل نمود.
قابلیت‌های جدید Cisco Email Security پس از به‌روزرسانی
ویدیوهای بیشتر درباره Cisco Email
از آنجایی که Spam Check درحالت پیش‌فرض روشن است و هیچ کدام از Policyهای پیام‌های ورودی آن را خاموش نمی‌کنند، پیکربندی این قابلیت به درستی انجام شده است. تنظیمات TRUSTED/AllowLIST از اهمیت بسزایی برخوردار است. بیشتر اوقات مشترکان بطور غیر عمد یک Sender به لیست مجاز یا Allowlist خود اضافه می‌کنند که Spam را ازسال می‌کند، به عنوان مثال، با اضافه کردن دامین یک ISP یا جفت که هم Spam و هم پیام‌های متعارف را به گروه Sender لیست مجاز ارسال می‌کند.
3- باید تمامی فیلترهای پیام‌ها بازبینی شوند تا گزینه Skip Spam Check یا لغو بررسی فعال نباشد به یاد داشته باشیم که هماهنگ‌کردن یک rcpt-to واحد می‌تواند پیام‌های بیش از 30 نفر دریافت‌کننده را تنظیم نماید. می‌توان یک Spam اخیر را یافته و Logهای پیام زمان، تاریخ، rcpt و غیره را ارجاع داد تا از آنچه رخ داده با خبر شد. باید پذیرفت که قابلیت Anti-Spam حکم منفی برای Spam صادر کرده و هدف انجام اقدامات لازم جهت دریافت پیام‌های مثبت است. Mail Policyهای دریافتی باید برای بازبینی چگونگی صدور حکم بررسی شوند. باید اطمینان حاصل نمود که پیام‌های مشکوک و آنهایی که Spam بودن آنها مثبت می‌شود خارج شده و یا طبق Policy پیش‌فرض قرنطینه می‌شوند و علاوه بر آن، سایر Policyها یا از رفتار پیش‌فرض پیروی می‌نمایند یا بطور عمد مانع آن می‌شوند.
بیشتر بخوانید: شرح و بررسی Cisco Secure Web Appliance، ویژگی ها و قابلیت های آن – قسمت اول
4- اگر پیام‌هایی که به اشتباه Spam تشخیص داده شده‌اند از Spamهای واقعی که گم شده‌اند اهمیت کمتری دارند، باید آستانه‌های سخت‌گیرانه‌تری را اتخاذ نمود. اگر در آستانه Certain ،Spamهای اشتباه اهمیتی ندارند باید Positive Spam Threshold به 80 کاهش یابد، پیش‌فرض 90 است. درصورتی که در آستانه Suspect ،Spamهای اشتباه اهمیتی ندارند بایدSuspected Spam Threshold به 40 کاهش یابد ولی پیش‌فرض 50 است. اگر بیشتر شکایات مربوط به دریافت Spam از سوی یکی از زیرمجموعه‌های مشترکان است، می‌توان یک Policy دریافت پیام جداگانه برای این کاربران با آستانه کمتر درنظر گرفت تا فیلتر شدیدتری صورت گیرد. تغییر این مقادیر نباید بدون حساسیت و اطلاعات موثق صورت گیرد تا بتوان عواقب آن را مشخص نمود و علاوه بر آن، نباید لزوما بخاطر کاهش میزان False Positivesها مقادیر را افزایش داد. باید اطمینان داشت که False Positivesها و False Negativeها به TAC ارسال می‌گردند.
5- باید تنظیمات SBRS و Policyهای HAT بهبود یابند:
بیشتر سازمان‌ها با اضافه کردن SBRS -10 تا -3 به Blocklist خود و SBRS -3 تا -1 به Suspectlist خود مشکلی ندارند و مشترکانی که محدودیت بیشتری را طلب می‌کنند می‌توانند در Blocklist خود مقادیر SBRS -10 تا -2 و در Suspectlist مقادیر SBRS -2 تا -0.6 را اضافه نمایند. در برخی موارد اینکه شخص ارسال کننده هنوز دارای یک SenderBase Reputation Score نیست خود مدرکی برای احتمال کلاهبرداری او است. می‌توان مقدار SBRS None را بطور مستقیم به یک گروه ارسال کننده که Policy Throttled را دریافت می‌کند اضافه نمود مانند گروه ارسال‌کننده Suspect.
بیشتر بخوانید: آشنایی با راهکارهای جامع Cisco Email Security – قسمت اول
باید حداکثر تعداد دریافت‌کنندگان در هر ساعت را به 5 نفر در Policy Throttled تغییر داد و بیش از یک Policy Throttled برای اعمال به دریافت کنندگان مختلف در هر ساعت ایجاد نمود، به عنوان مثال باید برای ارسال کنندگان با محدوده SBRS بین -2 و -1 تا 5 دریافت کننده در ساعت تعریف نموده و برای ارسال کنندگان با محدوده SBRS بین 0 و -1 تا 20 دریافت کننده در ساعت تعریف کرد.
6- فعال‌سازی Sender Verification برای Policy Throttled
مشترکان ممکن است Senderهایی بدون DNS یا با پیکربندی اشتباه DNS به گروه Suspectlist اضافه کنند. اتصال رکورد Host PTR در DNS وجود ندارد و جستجوی آن بخاطر خرابی موقت DNS با خطا مواجه می‌شود. اتصال جستجوی DNS معکوس Host یا PTR با جستجوی DNS ارسالی همخوانی ندارد. ریسک False-Positive در Senderهایی که DNS آنها دارای پیکربندی اشتباه است وجود دارد بنابراین ممکن است مشترکان بخواهند یک Policy جداگانه که یک پاسخ قابل تنظیم 4xx ارسال می‌کند و بیان‌گر دلیل رد پیام‌هاست را تنظیم نمایند.
7- فعال‌سازی LDAP و Directory Harvest Attack Protection:
بسیاری از کلاهبرداران ایمیل‌ها را به تعداد بسیاری از آدرس‌های نامعتبر می‌فرستند، بنابراین بلاک‌کردن ارسال کنندگانی که به افراد نامعتبر ایمیل می‌فرستند می‌تواند Spamها را کاهش دهد. اگر LDAP از قبل روشن باشد باید اطمینان حاصل نمود که Directory Harvest Protection یا DHAP نیز برای هر ورودی با حداکثر بین 5 تا 10 اقدام نامعتبر در هر IP پیکربندی شده است.
8- فعال‌سازی دیکشنری‌های محتوا
ESA با دو دیکشنری محتوا همراه است: Profanity.txt و Sexual_content.txt. با وجود اینکه استفاده از این دیکشنری‌ها ممکن است False Positive ایجاد نماید، برخی مشترکان به این نتیجه رسیده‌اند که فیلترکردن لغات نامناسب ریسک دریافت «ایمیل اشتباه» را برای «شخص اشتباه» کاهش می‌دهد. این فیلترها ممکن است فقط برای آنهایی که بیشتر در این دردسر گرفتار هستند استفاده شود بطوری که فیلترها برای گروهی از کاربران در یک Mail Policy مشخص فعال می‌شوند.
9- پیام‌هایی که دسته‌بندی نشده‌اند باید به Cisco TAC گزارش شوند. برای جلوگیری از حجم زیاد False Positiveها، SBRS باید برای اسکن‌کردن خروجی‌ها غیرفعال گردد و علت این امر این است که SBRS به اعتبار IPهای ورودی دقت می‌کند و در یک شبکه داخلی بیشتر این IPها پویا هستند. دقت بعد اقدامات دنبال شوند
فعال‌سازی SBNP
- باید اطمینان حاصل نمود که پیام‌های ورودی و خروجی در Listenerهای جداگانه هستند و جستجوی SenderBase باید در پیام‌های خروجی غیرفعال گردد. برای انجام این کار از GUI، باید به Network و سپس به Listener رفت، سپس هرکدام از Listenerهای خروجی را انتخاب نموده و گزینه Advanced را انتخاب می‌کنیم و تیک درون باکس کنار «Use SenderBase IP Profiling» را بر می‌داریم.
- SenderBase Network Participation یا SBNP می‌تواند بطور قابل توجهی تاثیرگذاری فیلترهای Reputation ،Anti-Spam و Virus Outbreak را افزایش دهد و در صورت استفاده از قابلیت Anti-Spam هیچ اثر محسوسی بر عملکرد نداشته و به شدت ایمن است.
توجه: حجم Spamهایی که یک سازمان دریافت می‌کند با گذر زمان تغییر می‌کند. ممکن است Spam بیشتری از طریق ESAها دریافت شود صرفا به دلیل اینکه در آن دوره زمانی Spamهای بیشتری نسبت به قبل ارسال می‌گردد. می‌توان با نگاهی در صفحه Incoming Mail Overview و اضافه نمودن موارد «Stopped By Reputation Filtering» و «Spam Messages Detected» این مقادیر را در طی زمان اندازه گرفت.
اصول SBRS
مسئله بزرگ False Positiveها این است که احتمال مفقود شدن ایمیل‌های مهم وجود دارد و در این ساختار، اقدام به قرنطینه کردن یا Drop کردن ایمیل‌های Spam مثبت مشکل ساز است. اگر یک ایمیل مجاز به قرنطینه یا پوشه Spam برود، جستجوی فعال و پیش‌گیرانه نیاز است تا متوجه شد که یک پیام پر زرق و برق به عنوان Spam شناخته شده است.
از سوی دیگر، Blocklist و ایمیل‌های Rate-Limit شده طوری بلاک شده‌اند که شخص فرستنده فورا آگاه می‌شود. اگر شخص ارسال‌کننده کلاه‌بردار نباشد سعی می‌کند تا از طرق دیگری ارتباط برقرار نماید. در واقع به عنوان یک Policy کلی، بلاک کردن بطور پیش‌فرض و سپس پذیرش شرکای مورد اعتماد پس از درخواست برای برخی کسب‌وکارها بهتر است. Throttling اگر به خوبی تنظیم شده باشد به ندرت شرکا را هدف قرار می‌دهد اما دربرابر دامین‌هایی که توسط ویروس‌ها آلوده شده‌اند محافظت به عمل می‌آورد. همچنین Throttling برای کلاهبرداران ناخوشایند است. تکنیک آنها این است که تعداد زیادی IP خریداری کنند و ایمیل‌های قابل قبولی برای دریافت امتیاز کافی SBRS بنویسند تا کار خود را آغاز نمایند. یک لیست Suspect بزرگ باید این موارد را مهار کند و خسارت آنها را به حداقل برساند و در نهایت کلاهبرداران را از ارسال Spam به دامین مورد نظر باز دارد.
