ایمیل خطای VPN در FortiGate: فیلدها را فیلتر کنید، نه گزارش‌ها

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

دو تصمیم در عبارت «وقتی ورود به VPN شکست خورد برایم ایمیل بفرست» پنهان است. اولی این است که اعلان چگونه تحویل شود: یک ایمیل به‌ازای هر رویداد، خلاصه دوره‌ای، یا هشداری از یک جمع‌کننده. دومی این است که پیام چه چیزی داشته باشد. اشتباه در اولی صندوق پستی را سیل می‌کند، و اشتباه در دومی فیلدهایی را حذف می‌کند که هشدار را قابل اقدام می‌سازند. هیچ‌یک از دو تصمیم نیازی به سرکوب دسته گزارش VPN ندارد؛ این همان میان‌بری است که بی‌صدا ردپای حسابرسی را نابود می‌کند.

سه شکل تحویل و اینکه هرکدام کجا مناسب است

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

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

از رکورد رویداد شروع کنید، نه از خط موضوع

یک رویداد ذخیره‌شده نماینده را در نسخه‌ای که واقعاً اجرا می‌کنید بخوانید. مرجع گزارش‌های FortiOS 7.4.8 شکست ورود به SSL VPN را رویداد 39426 شناسایی می‌کند و فیلدهای آن شامل action، user، remip، reason، tunneltype و vd است. طراحی فیلتر از موضوع ایمیل ارسال‌شده به‌جای آن رکورد، همان راهی است که مردم در نهایت روی نام فیلدی که firmware‌شان متفاوت می‌نویسد تطبیق می‌دهند. دو یا سه شکست واقعی را باز کنید و پیش از نوشتن تریگر تأیید کنید که شناسه‌ها مطابقت دارند. پنج دقیقه‌ای که این کار می‌گیرد، از یک هفته هشداری که روی رویداد اشتباه شلیک می‌شود کوتاه‌تر است.

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

بدنه‌ای فشرده از جایگزینی‌های پشتیبانی‌شده بسازید

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

config system automation-trigger
    edit "ssl-vpn-login-fail"
        set event-type event-log
        set logid 39426
    next
end

config system automation-action
    edit "mail-vpn-fail"
        set action-type email
        set email-to "[email protected]"
        set email-subject "SSL-VPN login failed"
        set message "Account: %%log.user%% | Source: %%log.remip%% | Reason: %%log.reason%%"
    next
end

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

حجم را کم کنید بدون حذف رکورد

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

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

یک شکست را به‌عنوان شکست بخوانید

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

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

مقالات مرتبط