سالمیت کی نگرانی میں ایک ناخوشگوار خاصیت ہے: اسے ایسے نظام سے لیا گیا معیار درکار ہے جس کے صاف ہونے کا یقین ہو۔ اور اگر سرور تین سال سے چل رہا ہو اور نقب زنی کا سوال آج ہی اٹھا ہو تو وہ معیار اب لینا دیر ہو چکی — آپ وہی درج کر لیں گے جو وہاں موجود ہے، بطور معمول۔
مگر Debian اور Ubuntu پر معیار پہلے سے موجود ہے، اور وہ آپ کا نہیں: ہر نصب شدہ پیکج اپنی فائلوں کے چیک سم اپنے ساتھ رکھتا ہے۔ ان سے موازنے کے لیے نہ ترتیبات چاہئیں نہ پہلے سے کوئی عکس، اور یہ ہر نظام پر ہر لمحے کام کرتا ہے۔ اس اوزار کا نام debsums ہے۔
استعمال
sudo apt install debsums
sudo debsums -c-c جھنڈا صرف وہ فائلیں چھاپتا ہے جو معیار سے میل نہ کھائیں۔ اس کے بغیر نتیجہ نظام کی ہر فائل کی سطر بہ سطر رپورٹ ہوتا ہے، دسیوں ہزار سطریں۔
جانچ چند منٹ لیتی ہے اور ڈسک پر بوجھ ڈالتی ہے، اس لیے چلتے ہوئے سرور پر اسے کم ترجیح کے ساتھ چلانا چاہیے:
sudo ionice -c3 nice -n19 debsums -cنتیجہ کیسے پڑھیں
خالی نتیجہ کا مطلب ہے کہ جانچی گئی ہر فائل اُس سے میل کھاتی ہے جو ڈسٹری بیوشن نے نصب کی۔ غیر خالی نتیجہ جانچنا پڑتا ہے، اور نتائج دو بہت مختلف طبقوں میں آتے ہیں۔
/etc میں ترتیبات کی فائلیں۔ انہیں بدلنا معمول کا کام ہے: آپ نے sshd_config ترمیم کیا، nginx مرتب کیا، کرنل کے پیرامیٹر جوڑے۔ ایسے فرق متوقع ہیں۔ اور یہ پاؤں میں نہ الجھیں، اس کے لیے ایک الگ وضع ہے:
sudo debsums -e -c-e صرف ترتیبات کی فائلیں جانچتا ہے — کبھی کبھار یہ دیکھنے کے لیے مفید کہ آپ نے اس مشین پر کیا کچھ بدلا ہے۔
قابلِ عمل فائلیں اور لائبریریاں۔ /usr/bin، /usr/sbin، /bin یا /usr/lib میں فرق وہی چیز ہے جس کے لیے جانچ چلائی گئی تھی۔ جائز وجوہ ہیں مگر زیادہ نہیں: خرابی دور کرتے وقت فائل ہاتھ سے ترمیم ہوئی، کسی فریقِ ثالث کا پیوند لگا، یا جانچ کے دوران پیکج اپ گریڈ ہو رہا تھا۔ اگر ان میں سے کوئی بھی نہ بیٹھے تو سنجیدگی سے جانچنے کا وقت ہے۔
تبدیلی کے کلاسیکی نشانے ls، ps، netstat، ss، find، sshd ہیں۔ بدلا ہوا نسخہ اپنے نتیجے سے وہ سطریں چھپا لیتا ہے جو اہم ہیں، اور اس کے بعد آپ کی ہر جانچ سچ بولنا چھوڑ دیتی ہے۔
احاطہ نامکمل ہے — اور یہ جاننا ضروری ہے
ایک ایسی حد جس کا عموماً ذکر نہیں ہوتا: ہر پیکج چیک سم فراہم نہیں کرتا۔ ایسے پیکجوں کی فائلیں سرے سے جانچی ہی نہیں جاتیں اور کسی بھی صورت رپورٹ میں نہیں آئیں گی۔ فہرست یوں دیکھی جا سکتی ہے:
sudo debsums -lاس لیے صاف debsums رپورٹ کا مطلب ہے «جو حصہ جانچا گیا اس میں سب ٹھیک ہے»، نہ کہ «نظام میں کوئی تبدیلی نہیں ہوئی»۔ یہی بات پیکج مینیجر سے باہر نصب کی گئی ہر چیز پر لاگو ہے: جو ماخذ سے مرتب ہوئی، جو بائنری کے طور پر اتاری گئی، جو ڈویلپر کی سائٹ کے اسکرپٹ سے نصب ہوئی — debsums بالتعریف ان میں سے کسی پر نظر نہیں رکھتا، اور عین یہیں AIDE درکار ہے۔
باقاعدہ چلانا
پیکج ایک تیار کام فراہم کرتا ہے، جو /etc/default/debsums میں فعال ہوتا ہے:
CRON_CHECK=weeklyہفتے میں ایک بار معقول تعدد ہے: جانچ ڈسک پر نمایاں بوجھ ڈالتی ہے، اور نظامی فائلیں تازہ کاریوں کے درمیان شاذ ہی بدلتی ہیں۔ روزانہ چلانے سے بوجھ کے سوا کچھ نہیں بڑھتا۔
اگر فائل واقعی بدل دی گئی ہو
پہلا ردعمل یہ ہوتا ہے کہ پیکج دوبارہ نصب کر کے اصل واپس لے آئیں:
sudo apt install --reinstall coreutilsکمانڈ درست ہے، مگر پہلے قدم کے طور پر نہیں۔ بدلی ہوئی نظامی بائنری کا مطلب ہے کہ کسی کے پاس root تھا، اور فائل بحال کرنا اس مسئلے کو حل نہیں کرتا — بس نشانات مٹا دیتا ہے۔ ترتیب الٹ ہونی چاہیے: پہلے مشکوک فائل اور اس کی تبدیلی کے وقت کی نقل محفوظ کریں، دیکھیں کہ اسی مدت میں اور کیا بدلا، اور cron کے کام، SSH کی کلیدیں اور صارفین کی فہرست جانچیں۔ بحالی صرف اس کے بعد۔
اور طریقے کی حدود بھی یاد رکھنے کے قابل ہیں: اگر نظام گہرائی تک سمجھوتہ شدہ ہو تو خود debsums اور اس کی استعمال کردہ لائبریریاں بھی باقی سب کے ساتھ بدلی جا چکی ہو سکتی ہیں۔ اندر سے کی گئی جانچ مطلق ضمانت نہیں دیتی — وہ بیرونی میڈیا سے بوٹ کرنے سے ملتی ہے۔ روزمرہ کام کے لیے پھر بھی یہ کافی ہے: حملوں کی بھاری اکثریت خودکار ہے اور اتنی پیچیدہ نہیں۔
مجموعی تصویر میں اس کی جگہ
debsums اس لیے اچھا ہے کہ اسے کچھ درکار نہیں اور یہ فوراً کام کرتا ہے — اور یہی اسے ایسے سرور کے لیے آسان نقطۂ آغاز بناتا ہے جس کی تاریخ آپ نہیں جانتے۔ اس کی کمزوری نامکمل احاطہ اور پیکجوں سے باہر نصب ہر چیز سے لاعلمی ہے۔ اور «debsums کے ساتھ AIDE» کی جوڑی دونوں پہلو ڈھانپ لیتی ہے: نظامی فائلوں کے لیے ڈسٹری بیوشن کا تیار معیار، اور باقی سب کے لیے آپ کا اپنا عکس۔
اور ہمیشہ کی طرح، مقصد اسے چلانا نہیں بلکہ یہ ہے کہ تازہ ترین نتیجہ اپنی تاریخ کے ساتھ نظر کے سامنے ہو۔ یہ کیسا لگتا ہے، نیچے ڈیمو دکھاتا ہے۔