Suricata पर लगभग हर मार्गदर्शिका Elasticsearch, Logstash और Kibana लगाने पर ख़त्म होती है। एक VPS के लिए यह बुरी सलाह है: यह ढेर चार गीगाबाइट मेमोरी और लगातार ध्यान माँगेगा, जबकि आप बस यह देखना चाहते थे कि IDS ने पिछले दिन क्या पकड़ा। Suricata उनके बिना बिल्कुल ठीक काम करता है — पर उसमें एक ख़ूबी है जिसकी वजह से लोग उसे लगाकर एक हफ़्ते बाद हटा देते हैं।

डिफ़ॉल्ट सेटिंग में छिपी बारूदी सुरंग

डिब्बे से निकलते ही Suricata eve.json में तीस से ज़्यादा प्रकार की घटनाएँ लिखता है: सिर्फ़ alert नहीं, बल्कि हर DNS अनुरोध, हर TLS handshake, हर HTTP लेनदेन, ARP, DHCP, एक के बाद एक flow। साथ में हर आठ सेकंड पर अलग stats.log। और ऐसा करते हुए Suricata लॉग रोटेशन सेट नहीं करता — यह प्रशासक का काम है, और कहीं बड़े अक्षरों में नहीं लिखा।

असली सर्वर का आँकड़ा: दो दिन में 15 गीगाबाइट — नौ eve.json में और लगभग छह stats.log में। डिस्क भरने तक क़रीब पाँच दिन बचे थे। उस सर्वर पर ट्रैफ़िक भी ज़्यादा नहीं था; व्यस्त नोड पर यह घंटों की बात होती।

अपना अभी जाँचें:

sudo du -sh /var/log/suricata/*

सिर्फ़ वही रखें जो आप पढ़ते हैं

अगर आप नेटवर्क फ़ोरेंसिक नहीं, alert देखते हैं, तो eve-log से ठीक एक ही प्रकार की घटना चाहिए। /etc/suricata/suricata.yaml में outputs ब्लॉक ढूँढ़ें और eve-log के types में alert छोड़कर बाकी टिप्पणी में डाल दें। वहीं आँकड़ों का आउटपुट भी बंद कर दें:

  - stats:
      enabled: no

संपादन के बाद कॉन्फ़िगरेशन की जाँच अनिवार्य है — सेवा दोबारा शुरू करने से पहले:

sudo suricata -T -c /etc/suricata/suricata.yaml -v

क्रम मायने रखता है: अगर नियम अभी लोड नहीं हुए तो जाँच पास नहीं होगी। पहले suricata-update, फिर कॉन्फ़िग की जाँच, फिर शुरू।

वह रोटेशन जो सचमुच काम करता है

फ़ाइल /etc/logrotate.d/suricata:

/var/log/suricata/*.log /var/log/suricata/*.json {
    daily
    rotate 7
    maxsize 200M
    missingok
    compress
    delaycompress
    create 0664 suricata suricata
    su suricata suricata
    postrotate
        systemctl kill -s HUP suricata
    endscript
}

यहाँ दो पंक्तियाँ ग़ैरज़ाहिर हैं और दोनों नाज़ुक हैं।

su suricata suricata — इसके बिना logrotate चुपचाप हर फ़ाइल छोड़ देता है। डायरेक्टरी /var/log/suricata root नहीं, समूह suricata की है, और logrotate ऐसी व्यवस्था को असुरक्षित मानता है। न मेल में कोई त्रुटि आएगी, न लॉग में; आप बस तब तक निश्चिंत रहेंगे कि रोटेशन है जब तक डिस्क ख़त्म न हो जाए। इसे पहले से पकड़ने का एकमात्र तरीक़ा सूखा रन है:

sudo logrotate -d /etc/logrotate.d/suricata

create 0664 suricata suricata — नई फ़ाइल की अनुमतियाँ। डिफ़ॉल्ट (0640) के साथ, लॉग को ग़ैर-root उपयोगकर्ता के रूप में पढ़ने वाला कोई भी पैनल या स्क्रिप्ट पहले ही रोटेशन के बाद कुछ नहीं देखेगा।

लॉग के अलावा क्या सेट करें

HOME_NET। यह बताता है कि Suricata किसे अपना मानता है। डिफ़ॉल्ट क़ीमत में सभी निजी श्रेणियाँ गिनाई गई हैं, जबकि VPS का पता सार्वजनिक होता है — इसलिए कुछ नियम चलते नहीं, या उल्टे चलते हैं। अपना नेटवर्क साफ़-साफ़ बताएँ।

नियम। Emerging Threats Open सेट suricata-update से आता है, जिसकी जगह दिन में एक बार cron में है। अलग-अलग शोर मचाने वाले हस्ताक्षर /etc/suricata/disable.conf में पहचानकर्ता से बंद किए जाते हैं — इसे इस्तेमाल करने से न डरें: यह सेट कॉर्पोरेट नेटवर्क के लिए बना है, और सामान्य वेब सर्वर पर दर्जन भर नियम लगातार और बेवजह चलते रहेंगे।

मोड। डिफ़ॉल्ट रूप से Suricata ट्रैफ़िक की नक़ल सुनता है और सिर्फ़ चेतावनी देता है (IDS)। एक ही सर्वर पर अवरोधन मोड (IPS, nfqueue के ज़रिये) मुख्यतः ख़ुद के लिए ख़तरा है: एक झूठा नतीजा और आपने ख़ुद को बाहर कर लिया। देखने से शुरू करें और एक महीना यह देखें कि क्या पकड़ में आता है।

Kibana के बिना इसे कैसे पढ़ें

छोटे alert /var/log/suricata/fast.log में रहते हैं — हर घटना की एक पंक्ति, आँख से पढ़ने लायक:

sudo tail -50 /var/log/suricata/fast.log

विस्तार eve.json में है, हर पंक्ति पर एक JSON वस्तु। Kibana जिसके लिए आमतौर पर लगाया जाता है, वह सब एक कमांड में सिमट जाता है:

sudo jq -r 'select(.event_type=="alert") | .alert.signature' \
    /var/log/suricata/eve.json | sort | uniq -c | sort -rn | head -20

यह बीस सबसे बार-बार आने वाले हस्ताक्षर हैं। एक हफ़्ते में ऐसी सूची ईमानदारी से बता देती है कि सर्वर के साथ क्या हो रहा है, और यह भी दिखाती है कि कौन से नियम बंद करने का समय आ गया है।

Fail2ban पहले से है तो इसकी क्या ज़रूरत

वे स्वभाव से अलग हैं। Fail2ban एप्लिकेशन के लॉग पढ़ता है और असफल लॉगिन पर प्रतिक्रिया देता है — यानी उस पर जो किसी सेवा तक पहुँच चुका। Suricata ख़ुद ट्रैफ़िक देखता है और वह देखता है जो किसी लॉग में कभी नहीं होगा: पोर्ट स्कैनिंग, जाने-पहचाने हस्ताक्षरों से मेल खाती शोषण की कोशिशें, आपकी मशीन के भीतर से कमांड सर्वरों तक कनेक्शन। आख़िरी वाला ख़ासतौर पर क़ीमती है: किसी और के कमांड सर्वर तक बाहर जाता कनेक्शन इस बात का सबसे शुरुआती संकेत है कि सर्वर पर पहले से कुछ ऐसा चल रहा है जो आपने शुरू नहीं किया।

दोनों रखना ठीक है, वे टकराते नहीं। सवाल सिर्फ़ यह है कि क्या उनका आउटपुट तिमाही में एक बार से ज़्यादा कोई पढ़ता है। वही alert एक पन्ने पर, श्रेणी और स्रोत के अनुसार बँटे हुए, कैसे दिखते हैं — नीचे डेमो पर।