حملوں کے نقشے پر گہرا دھبہ: اپنے سرور پر اس کا کیا کریں

حملوں کے نقشے پر ایک ملک کے اوپر گہرا دھبہ ہے، اور «پورے ملک ہی پر پابندی لگا دو» والا اصول خود بخود ذہن میں آتا ہے۔ اس سے تقریباً کچھ حاصل نہیں ہوگا: اخراج کا ملک بدلنے میں حملہ آور کے چند منٹ لگتے ہیں، جبکہ پابندی کی زد میں آپ کے اپنے مہمان آئیں گے اور سفر میں خود آپ۔ اس سے بھی برا یہ کہ ایک ہی بادل سے آنے والا نظر آنے والا کرالر بندش کے بعد گھریلو پتوں پر منتقل ہو جائے گا اور لوگوں سے الگ پہچانا ہی نہیں جا سکے گا۔

نیچے پانچ مراحل ہیں جو اسی سرور پر واقعی نتیجہ دیتے ہیں: اسکینروں کو کاٹنا، رفتار محدود کرنا، ضروری چیز نہ کاٹنا اور، اگر پھر بھی ضرورت ہو، درست طریقے سے بند کرنا۔ یہ سب ایک ہی نشست میں جانچا اور لگایا جا سکتا ہے۔

مرحلہ ۱۔ دیکھیے کہ دھبہ اصل میں کون بنا رہا ہے

پہلے درخواستوں کا لاگ تلاش کریں۔ کئی سائٹوں والے سرور پر access.log اکثر خالی رہتا ہے، جبکہ اندراجات متعلقہ ورچوئل ہوسٹ کے لاگ میں جاتے ہیں:

sudo ls -lS /var/log/apache2/*access*.log /var/log/apache2/*requests*.log 2>/dev/null

آگے کی تمام کمانڈوں میں وہی فائل رکھیں جو اس فہرست میں سب سے اوپر آئی۔ پہلے دن بھر کے سرفہرست پتے، پھر یہ کہ سب سے اوپر والا مانگ کیا رہا ہے:

sudo awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -20
sudo grep '^203\.0\.113\.' /var/log/apache2/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

دوسری کمانڈ بنیادی سوال کا جواب دیتی ہے۔ اگر نتیجے میں آپ ہی کی سائٹ کے درجنوں مختلف صفحات ہوں تو یہ مواد جمع کرنے والا ہے: بے ضرر، اور اتنا کافی ہے کہ اسے مہمان شمار نہ کیا جائے۔ اگر وہاں /wp-login.php، /.env، /phpmyadmin اور ایسی چیزیں ہوں جو آپ کے پاس ہیں ہی نہیں، تو یہ اسکینر ہے، اور اس سے مرحلہ ۲ نمٹتا ہے۔ nginx میں لاگ /var/log/nginx/ میں ہوتے ہیں، خانے وہی ہیں۔

مرحلہ ۲۔ ان درخواستوں پر jail جو آپ کے پاس ہے ہی نہیں

درخواست کا راستہ جعلی نہیں بنایا جا سکتا — پتے اور User-Agent کے برعکس وہی تو نیت ہے۔ فلٹر /etc/fail2ban/filter.d/web-probes.local:

[Definition]
failregex = ^<HOST> .* "(GET|POST|HEAD) /(wp-login\.php|wp-admin|xmlrpc\.php|\.env|\.git/|phpmyadmin|administrator/)
ignoreregex =

Jail /etc/fail2ban/jail.d/web-probes.local:

[web-probes]
enabled  = true
port     = http,https
filter   = web-probes
logpath  = /var/log/apache2/*access.log
maxretry = 1
findtime = 1h
bantime  = 1d

یہاں maxretry = 1 بجا ہے: کسی اور کے انتظامی صفحے پر اتفاقاً کوئی نہیں پہنچتا۔ اسے نافذ کریں اور یقین کر لیں کہ فلٹر آپ کے اپنے لاگ کی سطریں پکڑ رہا ہے:

sudo fail2ban-regex /var/log/apache2/access.log /etc/fail2ban/filter.d/web-probes.local
sudo systemctl reload fail2ban && sudo fail2ban-client status web-probes

مرحلہ ۳۔ رفتار محدود کریں

اسکینر اور کرالر اپنی رفتار سے پکڑے جاتے ہیں، چاہے وہ کسی بھی ملک سے ہوں۔ ایک ہی پتے سے فی منٹ تیس صفحات وہ حد ہے جو فہرست الٹتے پلٹتے انسان کو نہیں چھوتی:

[http-flood]
enabled  = true
port     = http,https
filter   = apache-overflows
logpath  = /var/log/apache2/site_access.log
maxretry = 30
findtime = 60
bantime  = 1h

فیصلہ کن بات یہ ہے کہ logpath میں کون سا لاگ لکھا ہے۔ اگر اس سانچے کی زد میں خود کنٹرول پینل یا انتظامی حصے کا لاگ آ گیا تو آپ خود کو ہی بند کر لیں گے: وہاں کا ایک ہی صفحہ اسٹائلوں اور اسکرپٹوں کے لیے درجن بھر درخواستیں کھینچتا ہے، اور تیس دو کلک میں پوری ہو جاتی ہیں۔ اسی لیے پینل کو الگ لاگ فائل دی جاتی ہے جو jail کے سانچے سے میل نہ کھائے، اور ساکن فائلوں کو طویل کیش مدت، تاکہ براؤزر ہر صفحہ بدلنے پر انہیں دوبارہ نہ مانگے۔ اگر پھر بھی ایسا ہو جائے تو علامت: HTML آ جاتا ہے، ظاہری ترتیب نہیں آتی، صفحہ اٹک جاتا ہے۔ بندش ہٹانا:

sudo fail2ban-client set http-flood unbanip 203.0.113.10

مرحلہ ۴۔ اس کی حفاظت کریں جسے کاٹنا نہیں چاہیے

بندشیں چالو کرنے سے پہلے استثناء لکھ لیں — ورنہ ان کی زد میں سب سے پہلے ضروری چیز ہی آئے گی:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 203.0.113.0/24 66.249.64.0/19

اس سطر میں لازماً کیا ہونا چاہیے اور کیوں:

• آپ کا اپنا پتہ یا دفتر کا ذیلی نیٹ ورک۔ سرور تک رسائی کھونے کی سب سے عام وجہ حملہ نہیں، اپنا ہی بنایا ہوا اصول ہوتا ہے؛
• حد 66.249.64.0/19۔ Google کا تلاش روبوٹ User-Agent سے پہچانا جاتا ہے، مگر اس کا وہ حصہ جو JavaScript چلاتا ہے عام Chrome/Linux بن کر آتا ہے اور اپنا نام نہیں بتاتا۔ «ڈیٹا سینٹروں سے آنے والی ٹریفک روکو» جیسا کوئی بھی اصول ٹھیک اسی پر لگتا ہے، جس کے بعد صفحات خاموشی سے اشاریے سے باہر ہو جاتے ہیں۔ مشکوک پتے کی جانچ الٹی استفسار سے ہو سکتی ہے: dig -x 66.249.66.1 +short کو googlebot.com علاقے کا نام لوٹانا چاہیے؛
• ادائیگی کی اطلاعات کے پتے۔ ادائیگی کے نظاموں کے webhook، AWS اور Azure سرورز سے آتے ہیں۔ اگر آپ ان بادلوں کو پورا بند کر دیں گے تو ادائیگی کی تصدیقیں آنا بند ہو جائیں گی، اور آپ کو اس کا علم تب ہوگا جب گاہک لکھے گا کہ رقم کٹ گئی مگر رسائی نہیں ملی۔ حدیں آپ کے ادائیگی فراہم کنندہ کی دستاویزات سے لی جاتی ہیں۔

مرحلہ ۵۔ اگر بندش پھر بھی ضروری ہو — ذیلی نیٹ ورک بند کریں، ملک نہیں

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

sudo ufw deny from 198.51.100.0/22 to any
sudo ufw status numbered

دوسری کمانڈ سے اصول کا نمبر یاد کر لیں: بندش بعد میں اسی کے ذریعے ہٹانی ہوگی، sudo ufw delete <نمبر>۔ اپنے ساتھ ایک مدت طے کریں — مثلاً ایک مہینہ — اور ہٹانے کی تاریخ کیلنڈر میں لکھ لیں۔ «ہمیشہ کے لیے» لگائے گئے اصول ایک سال بعد ایسی فہرست بن جاتے ہیں جسے چھونے کی ہمت کوئی نہیں کرتا، کیونکہ کسی کو یاد نہیں رہتا کہ وہ پتے وہاں کس سبب پہنچے تھے۔

کون سا ذیلی نیٹ ورک بند کرنا ہے، یہ پہلے مرحلے کے پتے سے معلوم ہوتا ہے: whois 198.51.100.17 | grep -iE 'route|cidr|netname'۔

ان پانچ مراحل کے بعد کیا بدلتا ہے

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

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