অখণ্ডতার নজরদারির একটা অস্বস্তিকর বৈশিষ্ট্য আছে: তার এমন মানদণ্ড দরকার যা পরিষ্কার বলে জানা সিস্টেম থেকে নেওয়া। সার্ভার তিন বছর ধরে চলছে আর সিঁধ কাটার প্রশ্ন আজই উঠলে সেই মানদণ্ড নেওয়ার সময় পেরিয়ে গেছে — আপনি যা আছে তাকেই স্বাভাবিক হিসেবে নথিভুক্ত করবেন।
তবে 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» জোড়া দুই দিকই ঢাকে: সিস্টেম ফাইলের জন্য ডিস্ট্রিবিউশনের তৈরি মানদণ্ড, আর বাকির জন্য আপনার নিজের স্ন্যাপশট।
যথারীতি, কথাটা চালানোর নয়, বরং সর্বশেষ ফল তার তারিখসহ চোখের সামনে থাকার। সেটা কেমন দেখায় তা নিচের ডেমোতে।