Suricata کی تقریباً ہر رہنمائی Elasticsearch، Logstash اور Kibana کی تنصیب پر ختم ہوتی ہے۔ ایک اکیلے VPS کے لیے یہ بری صلاح ہے: یہ ڈھیر چار گیگابائٹ میموری اور مسلسل توجہ مانگے گا، جبکہ آپ صرف یہ دیکھنا چاہتے تھے کہ IDS نے گزشتہ دن میں کیا پکڑا۔ Suricata ان کے بغیر بھی بخوبی کام کرتی ہے — مگر اس میں ایک خاصیت ہے جس کی وجہ سے لوگ اسے نصب کر کے ہفتہ بھر بعد ہٹا دیتے ہیں۔

طے شدہ ترتیبات میں چھپی بارودی سرنگ

ڈبے سے نکلتے ہی Suricata eve.json میں تیس سے زائد اقسام کے واقعات لکھتی ہے: صرف اطلاعات نہیں بلکہ ہر DNS استفسار، ہر TLS مصافحہ، ہر HTTP لین دین، ARP، DHCP، اور ایک کے بعد ایک بہاؤ۔ ساتھ ہی ہر آٹھ سیکنڈ بعد ایک الگ stats.log۔ اور Suricata اس دوران لاگ کی گردش مرتب نہیں کرتی — یہ منتظم کا کام ہے، اور کہیں بھی موٹے حروف میں نہیں لکھا۔

ایک حقیقی سرور کا عدد: دو دن میں 15 گیگابائٹ — نو eve.json میں اور تقریباً چھ stats.log میں۔ ڈسک بھرنے میں تقریباً پانچ دن باقی تھے۔ اُس سرور پر ٹریفک بھی زیادہ نہیں تھا؛ کسی مصروف نوڈ پر یہ چند گھنٹوں کی بات ہوتی۔

اپنا ابھی جانچیں:

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

صرف وہی رکھیں جو آپ پڑھتے ہیں

اگر آپ نیٹ ورک فارنزکس کے بجائے اطلاعات دیکھتے ہیں تو 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 کے بغیر کیسے پڑھیں

مختصر اطلاعات /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 خود ٹریفک کو دیکھتی ہے اور وہ دیکھتی ہے جو کبھی کسی لاگ میں نہیں ہوگا: پورٹ اسکیننگ، معلوم دستخطوں سے میل کھاتی استحصال کی کوششیں، اور آپ کی مشین کے اندر سے کمانڈ سرورز کی طرف کنکشن۔ آخری بات خاص طور پر قیمتی ہے: کسی اور کے کمانڈ اینڈ کنٹرول سرور کی طرف باہر جانے والا کنکشن اس بات کی سب سے ابتدائی علامت ہے کہ سرور پر پہلے سے کچھ ایسا چل رہا ہے جو آپ نے نہیں چلایا۔

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