FortiGate VPN ناکامی کی ای میل: لاگ نہیں، فیلڈز فلٹر کریں

«جب VPN لاگ اِن ناکام ہو تو مجھے ای میل بھیجیں» کے جملے میں دو فیصلے چھپے ہیں۔ پہلا یہ کہ اطلاع کیسے پہنچائی جاتی ہے: ہر واقعے کے لیے ایک میل، وقفے وقفے سے خلاصہ، یا جمع کرنے والے کی طرف سے انتباہ۔ دوسرا یہ کہ پیغام میں کیا ہے۔ پہلے میں غلطی میل باکس کو بھر دیتی ہے، اور دوسرے میں غلطی ان فیلڈز کو مٹا دیتی ہے جو انتباہ کو قابلِ عمل بناتے ہیں۔ دونوں میں سے کسی فیصلے کے لیے VPN لاگ زمرہ دبانے کی ضرورت نہیں، اور یہی وہ شارٹ کٹ ہے جو آڈٹ ٹریل کو خاموشی سے تباہ کرتا ہے۔

ترسیل کی تین شکلیں اور کون کب موزوں ہے

اس بنیاد پر منتخب کریں کہ کون جواب دیتا ہے اور کتنی تیزی سے دے سکتا ہے، اس بنیاد پر نہیں کہ کون سا آپشن ترتیب دینا سب سے آسان ہے۔ ایک دفتر کی حفاظت کرنے والا اکیلا FortiGate فی واقعہ میل کو جائز ٹھہرا سکتا ہے۔ چوری شدہ اسناد بھرنے کی کوششیں وصول کرنے والے گیٹ وے پر وہی ترتیب روزانہ ہزاروں پیغامات پیدا کرتی ہے اور ایسے فولڈر میں فلٹر ہو جاتی ہے جسے کوئی نہیں پڑھتا۔

واقعے کے ریکارڈ سے شروع کریں، موضوع کی سطر سے نہیں

جس ریلیز پر آپ واقعی چلتے ہیں اس پر نمائندہ محفوظ واقعہ پڑھیں۔ FortiOS 7.4.8 لاگ حوالہ SSL VPN پر لاگ اِن ناکامی کو واقعہ 39426 کے طور پر شناخت کرتا ہے، اور اس کے فیلڈز میں شامل ہیں action، user، remip، reason، tunneltype اور vd۔ فارورڈ کیے گئے ای میل کے موضوع سے اُس ریکارڈ کے بجائے فلٹر ڈیزائن کرنا ہی وہ راستہ ہے جس میں لوگ اپنے فرم ویئر کے مختلف انداز میں لکھے گئے فیلڈ نام سے مطابقت کرنے لگتے ہیں۔ دو یا تین حقیقی ناکامیاں کھولیں اور ٹرگر لکھنے سے پہلے تصدیق کریں کہ شناخت کنندہ مطابقت رکھتے ہیں۔ اس میں لگنے والے پانچ منٹ غلط واقعے پر چلنے والے ایک ہفتے کے انتباہات سے چھوٹے ہیں۔

آٹومیشن سلائی ایونٹ لاگ ٹرگر کو کسی عمل سے جوڑتی ہے، اور ٹرگر ہی وہ جگہ ہے جہاں واقعے کا انتخاب ہونا چاہیے۔ صرف وہ اضافی فیلڈ شرطیں شامل کریں جن کی آپ کی ضرورت کو حاجت ہے؛ چند فیلڈز پر فلٹر کرنے والا ٹرگر باقی کے لیے پھر بھی غیر آزمودہ رویہ دیتا ہے۔

معاون تبدیلیوں سے مختصر باڈی بنائیں

وہ ریلیزیں جو ای میل اعمال کے لیے لاگ فیلڈ کی تبدیلی کی دستاویز کرتی ہیں، ان میں باڈی مختصر ہو سکتی ہے اور پھر بھی مفید ہے۔ نیچے دی گئی شکل مثال ہے؛ لاگو کرنے سے پہلے خصوصیات کے نام اور تبدیلی کا نحو اپنے فرم ویئر ورژن سے جانچیں۔

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 سیشن نہیں ہے، اور واقعے میں صارف نام کسی شخص سے تصدیق شدہ نسبت نہیں ہے۔ اکاؤنٹ کے متاثر ہونے کا اعلان کرنے سے پہلے وجہ کو کامیاب لاگ اِن، معلوم صارف سرگرمی اور بار بار کوششوں سے جوڑیں، اور انتباہ میں بتائیں کہ ان میں سے کون سی آپ نے جانچیں۔

اطلاع صرف مجاز وصول کنندگان کو بھیجیں۔ اکاؤنٹ نام، اندرونی ڈیوائس شناخت کنندگان اور منبع پتے عملی طور پر حساس ہیں، اور سہولت کے لیے بڑھتی تقسیم کی فہرست لیک ہونے کا راستہ بن جاتی ہے۔ ایک قابلِ عمل راستہ اور مکمل آڈٹ ٹریل ہی پورا مقصد ہے۔