rkhunter ইনোড পরিবর্তন সম্পর্কে সতর্ক করে তবে কোনও ফাইল পরিবর্তনের তারিখ পরিবর্তন হয় না

8

আমার কাছে সেন্টোস 6 চালিত বেশ কয়েকটি সিস্টেম রয়েছে যার সাথে rkunter ইনস্টল রয়েছে। আমার কাছে প্রতিদিন ক্রোন চলছে আরখুন্টার এবং ইমেলের মাধ্যমে ফিরে রিপোর্ট করা।

আমি প্রায়শই এই জাতীয় প্রতিবেদনগুলি পাই:

---------------------- Start Rootkit Hunter Scan ----------------------
Warning: The file properties have changed:
        File: /sbin/fsck
        Current inode: 6029384    Stored inode: 6029326
Warning: The file properties have changed:
        File: /sbin/ip
        Current inode: 6029506    Stored inode: 6029343
Warning: The file properties have changed:
        File: /sbin/nologin
        Current inode: 6029443    Stored inode: 6029531
Warning: The file properties have changed:
        File: /bin/dmesg
        Current inode: 13369362    Stored inode: 13369366

আমি যা বুঝতে পেরেছি সেখান থেকে rkhunter সাধারণত স্ক্যান করা ফাইলগুলিতে পরিবর্তিত হ্যাশ এবং / অথবা পরিবর্তনের তারিখের প্রতিবেদন করবে, সুতরাং এটি আমাকে ভাবতে পরিচালিত করে যে সত্যিকারের কোনও পরিবর্তন নেই।

আমার প্রশ্ন: মেশিনে এমন আরও কিছু ক্রিয়াকলাপ রয়েছে যা ইনোড পরিবর্তন করতে পারে (এক্সট 4 চলছে) বা এটি কি yumস্বাভাবিক সুরক্ষা আপডেটের অংশ হিসাবে এই ফাইলগুলিতে নিয়মিত (~ সপ্তাহে একবার) পরিবর্তন করে চলেছে ?

centos yum rkhunter

— নিক কট্রেল
সূত্র

8

ফাইলগুলি আপডেট করা প্রায়শই একই ডিরেক্টরিতে একটি নতুন ফাইল লিখে পুরানো ফাইলের উপরে ফাইলটির নাম পরিবর্তন করে করা হয়। এই পদ্ধতিটি সাধারণত প্যাকেজ ম্যানেজারের মাধ্যমে ইনস্টল করা সমস্ত কিছুর ক্ষেত্রে প্রয়োগ করা হয়, তবে এক্সিকিউটেবল এবং গ্রন্থাগারগুলিতে করা কোনও আপডেটে এমনকি অন্য কারণে আপডেট হলেও।

ফাইলগুলি আপডেট করার এই পদ্ধতিটি নিশ্চিত করে যে ফাইলটি খোলার যে কোনও প্রক্রিয়া পুরানো বা নতুনটি পাবে এবং তারা যে ফাইলটি খোলায় তাতে কোনও পরিবর্তন হবে না। এর অর্থ এই নয় যে প্রতিবার এটি আপডেট হওয়ার পরে আপনার কাছে একই নামের সাথে একটি নতুন ফাইল থাকবে, সুতরাং ইনোড নম্বরটি পরিবর্তিত হয়েছে।

আমি অনুমান করি যে এই ফাইলগুলির একটি নতুন ইনোড নম্বর থাকার কারণ।

সুরক্ষা আপডেটের একটি কারণ হতে পারে। তবে আরও একটি সম্ভাবনা রয়েছে, যা আমি প্রথম ফেডোরা কোর 1 এ পর্যবেক্ষণ করেছি এবং এটি খুব ভালভাবেই এটি কোনও সময়ে সেন্টোসে পরিণত করতে পারে।

এক্সিকিউটেবল এবং লাইব্রেরিগুলি এমনভাবে প্রিলিং করা হচ্ছে যাতে তারা দ্রুত শুরু করতে পারে এবং কম স্মৃতি ব্যবহার করতে পারে। এই প্রক্রিয়া চলাকালীন সুরক্ষা দুর্বলতাগুলি সামান্য কিছুটা শক্তিশালী করার জন্য লোড ঠিকানাটি এলোমেলোভাবে করা হয়। একটি ক্রোন জব পর্যায়ক্রমে নতুন এলোমেলো ঠিকানা সহ প্রক্রিয়াটির পুনরাবৃত্তি করবে যার ফলে সমস্ত প্রাক-লিঙ্কযুক্ত এক্সিকিউটেবল এবং গ্রন্থাগারগুলি আপডেট হতে পারে।

— kasperd
সূত্র

2

হ্যাঁ, প্রাক-লিঙ্কিং এখানে সম্ভবত সবচেয়ে সম্ভবত ব্যাখ্যা বলে মনে হচ্ছে।

— মাইকেল হ্যাম্পটন

যদিও এটি হ্যান্ডেল করার কোনও ভাল উপায় আছে? যদি আমার কাছে চালানোর জন্য কেবল ক্রোন থাকে rkhunter --propupdতবে আমি একটি হ্যাক মিস করতে পারি এবং rkhunter পুরো পয়েন্টটি অবৈধ করতে পারি, তাই না?

— নিক কোটারেল

1

@ নিকোলাসটলিকোটারেল rpmপ্রথমে prelinkএক্সিকিউটেবলের অখণ্ডতা যাচাই করে এটি পরিচালনা করেন , তারপরে এটি prelinkপ্রিলিংযুক্ত এক্সিকিউটেবল এবং আউটপুট থেকে স্টডআউটে ইনপুট দিয়ে প্রিলিংকিংকে ফিরিয়ে আনার পক্ষে যুক্তিযুক্তকে এক্সিকিউটেবল বলে। তারপরে rpmসেই আউটপুটটির অখণ্ডতা পরীক্ষা করতে পারে। যদি এই পদ্ধতির প্রয়োগ করা যায় তবে কোনও ধারণা নেই rkhunter।

— ক্যাস্পারড

1

চেকসাম কীভাবে পাবেন যেগুলি প্রায় লাফিয়ে উঠবে না তার জন্য এই থ্রেডটি দেখুন: linuxquestions.org/questions/linux-security-4/… । আমি ক্রোন ভিত্তিক সরঞ্জাম হিসাবে rkunter থেকে সরে এসেছি। এটিতে প্রচুর দরকারী চেক রয়েছে, তবে সেই পরিমাণটিকে মিথ্যা ধনাত্মক হিসাবে বন্ধ করতে অক্ষমতা এটির প্রয়োজনীয়তার দিকে মনোযোগ দেওয়ার জন্য এটি প্রায় অকেজো করে তোলে, কারণ আমি কেবল তার ইমেল করা প্রতিবেদনগুলি উপেক্ষা করার অভ্যস্ত হয়ে পড়েছি। আমি এখনও এটি নিজে হাতে চালিত সরঞ্জাম হিসাবে মাঝেমধ্যে দরকারী বলে মনে করি।

— mc0e

2

অন্য যে বিকল্পটি আমি পেয়েছি তা হ'ল এই বৈশিষ্ট্যগুলি পরীক্ষা সম্পূর্ণরূপে অক্ষম করা। আপনি যদি সম্পাদনা /etc/rkhunter.confকরে DISABLE_TESTSলাইনটি সন্ধান করেন এবং এটিকে পরিবর্তন করেন:

DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps apps properties"

propertiesপরীক্ষা এক পরীক্ষণ এবং ফাইল হ্যাশ উপর মিথ্যা positives ফিরে আসছে।

— নিক কট্রেল
সূত্র

1

পরিবর্তিত ইনোড নম্বরটির অর্থ সাধারণত ফাইলটি প্রতিস্থাপন করা হয়েছে। আপনি যেমনটি বলেছিলেন এটি প্রত্যাশিত আপডেটের কারণে হতে পারে। আমি এই ফাইলগুলির md5sums যাচাই করতাম বিতরণিত সংস্করণগুলির সাথে মেলে। আপনার কাছে যদি আরও একটি তুলনামূলক ব্যবস্থা থাকে তবে এর সাথে তুলনা করা সবচেয়ে সহজ হতে পারে।

ফাইলের বৈশিষ্ট্যগুলিতে পরিবর্তিত হওয়া রিপোর্টগুলির প্রতিবেদনে গৃহীত উত্তরটি একবার দেখুন , তবে আমি দেখতে পাচ্ছি না যে এই বাইনারিগুলি কোন প্যাকেজ থেকে এসেছে তা পরীক্ষা করে কীভাবে তারা ইউম দ্বারা আপডেট করা হয়েছিল y

যদি এই বাইনারিগুলি এমন কোনও বিতরণ থেকে আসে যা অন্য বাইনারি সংক্রান্ত কোনও সমস্যার কারণে আপডেট করা হয়েছিল তবে তা অবাক করা হয়নি, তবে আপনার তালিকাভুক্ত বাইনারিগুলি অপরিবর্তিত প্যাকেজের নতুন সংস্করণে অন্তর্ভুক্ত করা হয়েছিল। আপনার প্রতিবেদনে এমন কিছু বাইনারিও দেখা গেছে যেখানে সামগ্রীটি পরিবর্তন করা হয়েছিল ?

— mc0e
সূত্র

না, প্রকৃতপক্ষে, দেখে মনে হচ্ছে যে আমি কেবল কখনও পেয়েছি যে ফাইলের বৈশিষ্ট্যগুলি পরিবর্তিত হয়েছে - কখনও কখনও সামগ্রীগুলি থাকে না।

— নিক কোটারেল

-1

আমি একটি ড্রাইভকে বৃহত্তর ড্রাইভে ক্লোন করেছি এবং বিভিন্ন আইওনড সংখ্যা সহ ফাইলগুলির সতর্কতা পেয়েছি। আমি সিস্টেম থেকে আরখুন্টার সরিয়ে পুনরায় কল করলাম এবং স্ক্যানটি আবার চালিত করে ইনডসের সংখ্যা পরিবর্তনের বিষয়ে কোনও সতর্কতা না দিয়ে

— উইল স্মিথ
সূত্র