«जब VPN लॉगिन विफल हो तो मुझे ईमेल भेजो» इस वाक्य में दो निर्णय छिपे हैं। पहला यह कि सूचना कैसे पहुँचाई जाए: प्रति घटना एक मेल, आवधिक सारांश, या किसी संग्राहक से चेतावनी। दूसरा यह कि संदेश में क्या हो। पहले में गलती डाकपेटी को भर देती है, और दूसरे में गलती उन फ़ील्ड को मिटा देती है जो चेतावनी को कार्रवाई-योग्य बनाते हैं। दोनों में से किसी निर्णय के लिए VPN लॉग श्रेणी को दबाना ज़रूरी नहीं है — वही वह शॉर्टकट है जो ऑडिट ट्रेल को चुपचाप नष्ट कर देता है।

तीन वितरण स्वरूप और कब कौन सा उपयुक्त है

स्वरूपकब उपयुक्तलागत
प्रति घटना ऑटोमेशन ईमेलकम वॉल्यूम, एक टीम प्रतिक्रिया देती हैप्रयासों का झोंका डाकपेटी में बाढ़ बन जाता है
निर्धारित सारांशनियमित समीक्षा, रुझान निगरानीचल रहे प्रयास को कोई नहीं देखता
सहसंबंध के साथ संग्राहक चेतावनीउच्च वॉल्यूम, साझा SOCखिलाने और ट्यून करने के लिए एक और सिस्टम

यह चुनें कि कौन प्रतिक्रिया देता है और कितनी जल्दी दे सकता है, न कि यह कि कौन सा विकल्प कॉन्फ़िगर करना सबसे आसान है। एक कार्यालय की रक्षा करने वाला अकेला 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 सत्र नहीं है, और किसी घटना में उपयोगकर्ता नाम किसी व्यक्ति को सत्यापित आरोपण नहीं है। खाते को समझौता-ग्रस्त घोषित करने से पहले कारण को सफल लॉगिन, ज्ञात उपयोगकर्ता गतिविधि और बार-बार किए गए प्रयासों से सहसंबंधित करें, और चेतावनी में बताएँ कि इनमें से क्या आपने जाँचा।

सूचना केवल अधिकृत प्राप्तकर्ताओं को भेजें। खाता नाम, आंतरिक डिवाइस पहचानकर्ता और स्रोत पते संचालनात्मक रूप से संवेदनशील हैं, और सुविधा के लिए बढ़ती वितरण सूची लीक का मार्ग बन जाती है। एक कार्रवाई-योग्य पथ और एक अक्षत ऑडिट ट्रेल ही पूरा लक्ष्य है।

संबंधित लेख