Check Point fix لگ گیا؟ درست Jumbo Hotfix take اور policy integrity یوں جانچیں

Check Point management میں CVE-2026-93616 کا fix جانچنے کے لیے متعلقہ سرور کی release اور واقعی نصب Jumbo Hotfix take ملائیں؛ صرف پیکیج ڈاؤن لوڈ ہونا یا LivePatch لگا ہونا کافی نہیں۔ Check Point کی سکیورٹی ایڈوائزری کے مطابق یہ Security Management web service کی ایسی خرابی ہے جسے authentication سے پہلے استعمال کرکے script چلائی جا سکتی ہے، اور LivePatch Takes 28 اور 29 اس کا fix نہیں ہیں۔

اسی سرور پر درست fix ملنے کے بعد بھی کام ختم نہیں ہوتا: ممکنہ سابقہ compromise، management میں شائع ہونے والی تبدیلیوں اور gateways پر نصب policy کو الگ جانچیں۔ Check Point کے انتظامی نوٹس میں R82.10 کے لیے Jumbo Hotfix Take 45، R82 کے لیے Take 127، R81.20 کے لیے Take 170، R81.10 کے لیے Take 192 اور R82.20 کے لیے Security Hot Fix Take 1 درج ہیں؛ Smart-1 Cloud کو پہلے سے patched بتایا گیا ہے۔

کن management نظاموں کو جانچ میں شامل کریں؟

فہرست مرکزی Security Management Server سے شروع کریں، مگر وہیں نہ رکیں۔ الگ Log Server، Multi-Domain Management اور Multi-Domain Log Server، ثانوی management سرور، اور موجود ہو تو SmartEvent بھی درج کریں۔ ہر میزبان کے سامنے اس کا کردار، release، نصب take، متعلقہ domain اور اسے manage کرنے کا طریقہ لکھیں۔ ایک سرور کا درست take اسی ماحول کے دوسرے سرور کے لیے ثبوت نہیں بنتا۔

Quantum Force اور Quantum Spark firewall appliances اس CVE کے براہِ راست متاثرہ products نہیں بتائے گئے۔ تاہم firewall اور management ایک ہی standalone appliance پر ہوں تو اس کا management حصہ جانچ میں شامل ہوگا۔ الگ gateway پر خرابی نہ ہونا بھی وہاں پہنچی ہوئی policy کی سالمیت ثابت نہیں کرتا؛ یہ سوال تب خاص اہمیت رکھتا ہے جب management کے compromise کا شبہ ہو۔ Smart-1 Cloud کی patched حیثیت سے کسی الگ، مقامی management یا logging سرور کی حالت اخذ نہ کریں۔

اپنی release کے لیے کون سا fixed take درکار ہے؟

نیچے ہر release کو اس کے اپنے fix سے ملائیں۔ Jumbo Hotfix take کا نمبر دوسری release پر منتقل نہیں کیا جا سکتا، اور R82.20 کا مخصوص Security Hot Fix عام Jumbo Hotfix take سے الگ ہے۔ اگر کوئی private hotfix یا خاص upgrade ترتیب استعمال ہوئی ہے تو نصب پیکیج کی شناخت کو اسی release کی ہدایات سے ملائیں؛ محض «latest» دکھائی دینا کافی ثبوت نہیں۔

• R82.20: مخصوص Security Hot Fix Take 1 نصب ہونا چاہیے۔ صرف کسی Jumbo Hotfix کی موجودگی کو اس fix کا ثبوت نہ سمجھیں۔
• R82.10: Jumbo Hotfix Take 45 یا اس کے بعد کا متعلقہ take درکار ہے؛ Take 44 یا اس سے پہلے متاثرہ حد میں ہیں۔
• R82: Jumbo Hotfix Take 127 یا اس کے بعد کا متعلقہ take درکار ہے؛ Take 126 یا اس سے پہلے متاثرہ حد میں ہیں۔
• R81.20: Jumbo Hotfix Take 170 یا اس کے بعد کا متعلقہ take درکار ہے۔ متاثرہ حد Take 166 تک درج ہے، لیکن درمیان کے Takes 167 تا 169 کو اس بنا پر محفوظ فرض نہ کریں۔
• R81.10: Jumbo Hotfix Take 192 یا اس کے بعد کا متعلقہ take درج ہے۔ یہ end-of-support release ہے، اس لیے fix کے ساتھ supported release تک upgrade کی منصوبہ بندی بھی کریں۔
• R80، R80.10، R80.20، R80.30، R80.40 اور R81: یہ end-of-support branches متاثرہ فہرست میں ہیں۔ ان کے لیے خود سے کوئی موجودہ fixed take فرض کرنے کے بجائے Check Point Support سے supported upgrade path طے کریں۔

متاثرہ take کی بالائی حد اور پہلے نامزد fixed take کے درمیان فرق خاص طور پر R81.20 میں اہم ہے۔ کسی درمیانی take کو محض اس لیے پاس نہ کریں کہ اس کا نمبر متاثرہ حد سے بڑا ہے۔ اسی طرح LivePatch کا ورژن الگ لکھیں، لیکن اسے اس CVE کے لیے Jumbo Hotfix یا مخصوص Security Hot Fix کا متبادل نہ بنائیں۔

پیکیج واقعی نصب ہے، یہ کیسے ثابت کریں؟

1. ہر متعلقہ میزبان پر Gaia کے installed packages میں پیکیج کی حالت دیکھیں، یا Expert mode میں cpinfo -y all سے نصب hotfix کی شناخت پڑھیں۔ دستیاب، imported اور installed پیکیج میں فرق رکھیں؛ صرف فائل کا موجود ہونا تنصیب نہیں ہے۔
2. نصب take کو اسی میزبان کی release والی قطار سے ملائیں۔ اگر تنصیب کے عمل میں reboot درکار تھا تو اس کے مکمل ہونے کے بعد نتیجہ دوبارہ پڑھیں اور میزبان کی شناخت کے ساتھ محفوظ کریں۔
3. Management اور logging خدمات کی معمول کی دستیابی، SmartConsole سے رسائی اور مطلوبہ policy installation کی حالت دیکھیں۔ یہ عملی صحت کی جانچ ہے؛ کامیاب login اکیلا نہ fix ثابت کرتا ہے نہ سابقہ compromise کی نفی۔

اگر کسی میزبان کا نتیجہ دستیاب نہیں، پیکیج کی حالت غیر واضح ہے یا نصب take مطلوبہ fix سے کم ہے تو اسے verified نہ لکھیں۔ ہر سرور کا نتیجہ الگ رکھنا incident response میں بھی مدد دیتا ہے: بعد میں یہ واضح رہتا ہے کہ کس system پر vulnerability بند ہونے کا ثبوت ملا تھا اور کس پر مزید کارروائی باقی تھی۔

رسائی محدود کریں اور سابقہ سرگرمی دیکھیں

Patch کی تصدیق کے ساتھ management service تک TCP/19009 کی رسائی مطلوبہ trusted IPs تک محدود کریں۔ صرف انٹرنیٹ سے آنے والے راستے نہ دیکھیں؛ VPN، اندرونی نیٹ ورک اور انتظامی segments سے پہنچ بھی جانچیں۔ اگر کوئی gateway اس رسائی کو کنٹرول کرتا ہے تو اس کی مؤثر policy اور implied rules دیکھیں۔ وسیع internal subnet کو بلا جانچ trusted قرار دینا اس جانچ کا مقصد پورا نہیں کرتا۔

Compromise کا شبہ ہو تو logs اور متعلقہ system artifacts محفوظ کرکے مشتبہ مدت طے کریں۔ غیر معمولی login کوششوں، غیر متوقع paths، نئی فائلوں اور processes کو منظور شدہ administrator سرگرمی اور change records سے ملائیں۔ کسی علامت کا ملنا مزید تفتیش کا سبب ہے؛ صرف log search میں کچھ نہ ملنا صفائی کا حتمی ثبوت نہیں، کیونکہ retention، rotation یا log tampering ریکارڈ کو نامکمل بنا سکتے ہیں۔ Hotfix آئندہ اس خرابی کے استعمال کو روکتا ہے، مگر پہلے سے کی گئی تبدیلی خود واپس نہیں کرتا۔

Management اور gateway policy کی سالمیت الگ کیسے جانچیں؟

آخری قابلِ اعتماد baseline سے management کی شائع شدہ revisions کا فرق نکالیں۔ Objects، services، administrator permissions، Access Control اور Threat Prevention rules میں ہر غیر متوقع تبدیلی کو change ticket، ذمہ دار منتظم اور publication وقت سے ملائیں۔ کسی rule کا صرف نام نہ دیکھیں؛ source، destination، service، action اور installation targets بھی پڑھیں۔ اگر شبہ کسی domain تک محدود دکھائی دے تو بھی جانچ کے دائرے کا فیصلہ شواہد سے کریں، مفروضے سے نہیں۔

Management database میں تبدیلی شائع ہونا اور gateway پر policy نصب ہونا دو الگ واقعات ہیں۔ Check Point کی Policy Installation History ہدایات بتاتی ہیں کہ SmartConsole میں Security Policies سے Access Tools یا Threat Prevention Tools کے تحت Installation History کھول کر منتخب gateway پر نصب revisions، تبدیلیاں اور متعلقہ منتظم دیکھے جا سکتے ہیں۔ مشتبہ مدت کے ہر متعلقہ gateway کا installed revision منظور شدہ تبدیلیوں سے ملائیں۔ صرف موجودہ management policy صاف دکھائی دینے سے یہ معلوم نہیں ہوتا کہ پہلے gateway پر کیا نصب ہوا تھا۔

غیر مجاز تبدیلی یا exploitation کا معتبر اشارہ ملے تو شواہد محفوظ رکھتے ہوئے management رسائی محدود کریں اور incident response کے تحت قابلِ اعتماد baseline سے بحالی طے کریں۔ متاثرہ objects اور installation targets شناخت کرنے کے بعد منظور شدہ policy دوبارہ نصب کریں، پھر gateway کی Installation History اور audit trail سے نتیجہ ملائیں۔ اس طرح «fix نصب ہے» اور «policy integrity بحال ہے» کے فیصلے الگ شواہد پر قائم ہوں گے۔

یہ بھی پڑھیں:

• CVSS 10 اکیلا patch order نہیں، KEV اور affected version پہلے دیکھیں
• N-central کا CVSS 10 flaw: Hotfix 3 بھی کافی نہیں
• YouTube پر “free music” بھی claim لا سکتی ہے—license پہلے یوں جانچیں