'বিন' ব্যবহারকারীর লগইন শেলটির প্রয়োজন কেন?

Question

/var/log/auth.logআমার পাবলিক ওয়েবসভারগুলির একটিতে নিরীক্ষণের সময় আমি এটি পেয়েছি:

Jan 10 03:38:11 Bucksnort sshd[3571]: pam_unix(sshd:auth): authentication failure; 
    logname= uid=0 euid=0 tty=ssh ruser= rhost=61.19.255.53  user=bin
Jan 10 03:38:13 Bucksnort sshd[3571]: Failed password for bin from 61.19.255.53 
    port 50647 ssh2

প্রথম ব্লাশ এ, sshএলোমেলো হ্যাকারদের থেকে সাধারণ লগইন স্প্যামের মতো মনে হচ্ছে ; যাইহোক, আমি কাছাকাছি তাকানোর সময় আমি অন্য কিছু লক্ষ্য করেছি। বেশিরভাগ ব্যর্থ /var/log/auth.logএন্ট্রি invalid userতাদের মধ্যে এই মত বলে :

Jan  9 10:45:23 Bucksnort sshd[3006]: Failed password for invalid user sales 
    from 123.212.43.5 port 10552 ssh2

যে ব্যর্থ লগইন বার্তা সম্পর্কে মন মোটেই সায় দিচ্ছে জিনিস binযে এটি একটি হল বৈধ ব্যবহারকারীর মধ্যে /etc/passwdযে এমনকি হয়েছে একটি লগইন শেল:

[mpenning@Bucksnort ~]$ grep ^bin /etc/passwd
bin:x:2:2:bin:/bin:/bin/sh

আমি সব ডিফল্ট ব্যবহারকারীর নাম যে দূরবর্তী অবস্থান থেকে লগ-ইন করতে পারে যখন আমি অক্ষম ওড়না দিয়ে ঢাকা ছিল PermitRootLoginমধ্যে /etc/ssh/sshd_config; এই এন্ট্রিটি আবিষ্কার করা আমার মায়াময় মনে নতুন সম্ভাবনা খুলেছে। যদি কোনও উপায়ে পরিষেবাগুলি চলতে থাকে binতবে এটি দূরবর্তীভাবে সম্ভব যে কেউ কোনওভাবে কোনও কোনও binবাক্সের চলমান পরিষেবা থেকে ব্যবহারকারীর ডিরেক্টরিতে একটি ssh কী sertোকাতে পারে , তাই আমি binযদি সম্ভব হয় তবে ব্যবহারকারীর জন্য লগইন সম্পূর্ণভাবে অক্ষম করতে চাই ।

প্রশ্নাবলি

• এই সার্ভারটি দূরবর্তী, এবং এটি ঠিক করা ব্যয়বহুল (অর্থাত্ আমি কেভিএম হুক করার জন্য দূরবর্তী হাতের জন্য অর্থ প্রদান করব, আরও কেভিএম ভাড়া)। আমি যদি /etc/passwdএন্ট্রিটি পরিবর্তন করার জন্য প্রবেশদ্বারটি পরিবর্তন করি তবে আমি কী ভাঙ্গতে পারি তা বের করার চেষ্টা করছি bin:

  bin:x:2:2:bin:/bin:/bin/false

• আমি কী binপ্রয়োজন তা নির্ধারণ করার জন্য নিম্নলিখিত কমান্ডগুলি চালিত করেছি ... তবে, এই আদেশগুলি কোনও ফাইল নিয়ে আসে নি এবং আমি মালিকানাধীন কোনও প্রক্রিয়া খুঁজে পাইনি bin। কী binব্যবহারকারী যাহাই হউক না কেন না?

  $ sudo find / -group bin

  $ sudo find / -user bin

• অন্য কোনও ব্যবহারকারীর কি তাদের লগইন শেলগুলি সেট করা উচিত /bin/false? অবগতির জন্য, আমি আছে আগে থেকেই আছে /bin/falseউপর www-data।

• আমি কি খুব ভৌতিক?

আমি ডেবিয়ান চালাচ্ছি, যদি এটি গুরুত্বপূর্ণ হয়।

Comments

সম্পর্কিত সম্পর্কিত প্রশ্ন হ'ল unix.stackexchange.com/questions/485505 ।

— JdeBP

Answer 1

কোনও ব্যবহারকারী যার বৈধ শেল এবং কোনও পাসওয়ার্ড নেই এখনও নন-পাসওয়ার্ড-ভিত্তিক পদ্ধতিতে লগ ইন করতে পারেন, এটি স্যাশ কী most ক্রোন জব চালানোর জন্য একটি বৈধ শেল প্রয়োজনীয়। su bin -c 'wibble'কাজ করার জন্য একটি বৈধ শেলও প্রয়োজনীয় (কমপক্ষে লিনাক্স- su bin -s /bin/sh -c 'wibble'এও কাজ করবে)।

এর ক্ষেত্রে bin, বেশিরভাগ সিস্টেমগুলি কখনও কখনও binসাধারণ ক্রিয়াকলাপ হিসাবে কমান্ড চালায় না , সুতরাং শেলটি /bin/falseঠিক করা ঠিক হবে।

binএসএসএইচ-এর মাধ্যমে লগ ইন করার অনুমতি দেওয়ার কোনও প্রত্যক্ষ আক্রমণের ঝুঁকি নেই , কারণ এটির /bin/.ssh/authorized_keysজন্য ব্যবহারকারী binবা মূল হিসাবে তৈরি হওয়া প্রয়োজন । অন্য কথায়, প্রবেশের একমাত্র উপায়টি হ'ল তবে, একটি বৈধ শেল থাকা ভুল কনফিগারেশনের ঝুঁকি বাড়ায়। এটি এসএসএইচ ব্যতীত পরিষেবাগুলির সাথে কিছু দূরবর্তী হামলার অনুমতিও দিতে পারে; উদাহরণস্বরূপ কোনও ব্যবহারকারী রিপোর্ট করেছেন যে কোনও আক্রমণকারী daemonসাম্বার মাধ্যমে দূরবর্তী অবস্থানের জন্য একটি পাসওয়ার্ড সেট করতে পারে , তারপরে এসএসএইচ-এর মাধ্যমে লগ ইন করতে সেই পাসওয়ার্ডটি ব্যবহার করুন।

DenyUsersনির্দেশিকায় সিস্টেম ব্যবহারকারীদের নাম তালিকাভুক্ত করে আপনি এসএসএইচ হোলটি প্লাগ করতে পারেন /etc/ssh/sshd_config(দুর্ভাগ্যক্রমে, আপনি একটি সংখ্যার ব্যাপ্তি ব্যবহার করতে পারবেন না)। অথবা, বিপরীতে, আপনি একটি AllowGroupsনির্দেশিকা রাখতে পারেন এবং কেবলমাত্র সেই গোষ্ঠীগুলিকেই অনুমতি usersদিতে পারেন যা শারীরিক ব্যবহারকারী রয়েছে (যেমন আপনি যদি আপনার সমস্ত শারীরিক ব্যবহারকারীকে সেই গ্রুপের সদস্যপদ দেন)।

ডেবিয়ানে এই ইস্যুতে বাগগুলি ফাইল করা আছে ( # 274229 , # 330882 , # 581899 ), বর্তমানে উন্মুক্ত এবং "ইচ্ছা তালিকা" হিসাবে শ্রেণিবদ্ধ করা হয়েছে। আমি একমত হতে চাই যে এগুলি বাগ এবং সিস্টেম ব্যবহারকারীদের /bin/falseশেল হিসাবে থাকা উচিত অন্যথায় না করার প্রয়োজন দেখা দিলে।

Answer 2

আপনার ব্যবহারকারী হিসাবে তাদের সম্পর্কে চিন্তা করার দরকার নেই। তারা সুরক্ষা গোষ্ঠীগুলির অর্থে "ব্যবহারকারী", "লগইন এবং ব্যবহার" লোকের অর্থে ব্যবহারকারী নয়। আপনি যদি "/ ইত্যাদি / ছায়া" দেখুন, আপনি দেখতে পাবেন যে এই সমস্ত "ব্যবহারকারীর" পাসওয়ার্ড নেই (লম্বা লবণযুক্ত হ্যাশের পরিবর্তে "x" বা "!") এর অর্থ এই ব্যবহারকারীরা লগইন করতে পারবেন না, তা যাই হোক না কেন।

এটি বলেছিল, আমি জানি না যে এই সমস্ত ব্যবহারকারীর জন্য "/ বিন / শ" পরিবর্তন করে "/ বিন / মিথ্যা" পরিবর্তন করা ভাল ধারণা কিনা। যেহেতু প্রোগ্রামগুলি এই গোষ্ঠীগুলির অধীনে চলছে, এটি তাদের প্রয়োজনীয় কমান্ডগুলি কার্যকর করতে দেয় না। আমি তাদের "/ বিন / শ" হিসাবে রেখে দেব

এই ব্যবহারকারীদের সম্পর্কে আপনার চিন্তার দরকার নেই। কেবলমাত্র আপনি তৈরি করা ব্যবহারকারীদের নিয়েই উদ্বেগ করুন (এবং "/ etc / ছায়া" তে হ্যাশযুক্ত)

Comments

কোনও হ্যাশ ইন সম্পর্কে ন্যায্য পয়েন্ট /etc/shadow, তবে কোনও পরিষেবা যদি ব্যবহারকারী হিসাবে চলতে থাকে তবে কারও পক্ষে sshলগইন কী inোকানো তাত্ত্বিকভাবে সম্ভব , না?

— মাইক পেনিংটন

কেবলমাত্র যদি তারা ইতিমধ্যে আপনার অ্যাকাউন্টে মূল সুযোগগুলি দিয়ে লগইন করে থাকে ... এই ক্ষেত্রে, এই ব্যবহারকারীরা আপনার উদ্বেগের মধ্যে সবচেয়ে কম :

— ক্রিস

আমি নিশ্চিত নই যে আপনি সবে তালিকাভুক্ত সমস্ত প্রতিবন্ধকতার সাথে আমি একমত। যদি এটি সত্য হয় তবে খোলা rpcdপোর্টগুলি কোনও সমস্যা হবে না; তবে, ব্যক্তিগতভাবে আমি একটি পুরানো সোলারিস মেশিনে রিমোট শোষণের ফলাফল প্রত্যক্ষ করেছি যেখানে আক্রমণকারীটি rpcবাক্সে শোষণের মাধ্যমে অ্যাক্সেস অর্জন করেছিল। rhostsসক্ষম হয়েছিলেন এবং সেই rpcব্যবহারকারী দ্বারা লিখিতযোগ্য ছিল (এটি আর কোনও নির্দিষ্ট বৈশিষ্ট্য মনে করতে পারে না ... এটি বহু বছর আগে ছিল) ... তেমনি তারা যদি ~/.ssh/authorized_keysলগইন করতে পারে এমন কোনও ব্যবহারকারীর জন্য তৈরি করতে পারে তবে এটি এখনও ঝুঁকির মতো বলে মনে হয় (এমনকি এটি ছাড়াও) পাসওয়ার্ডে /etc/shadow)

— মাইক পেনিংটন

হ্যাঁ, তবে সেই শোষণটি এসএসএইচের মাধ্যমে হয়নি। প্রোগ্রামগুলি সাধারণত তাদের নিজস্ব ব্যবহারকারীর অধীনে চলে (যেমন আপনি বলেছেন)। কোনও প্রোগ্রামের শোষণ (উদাহরণস্বরূপ, একটি বাফার ওভারফ্লো শোষণ) দূষিত ব্যবহারকারীকে সেই প্রোগ্রামটিতে অ্যাক্সেস করা শেল অ্যাক্সেস করতে পারে। যাইহোক, সেই প্রোগ্রামটির যা প্রয়োজন তা করতে সেই অ্যাক্সেসের প্রয়োজন হয় (অন্যথায় এটি যা প্রয়োজন তা অ্যাক্সেস করতে পারে না)। অনুমতিগুলি সঠিকভাবে সেট করা আছে তা নিশ্চিত করা কেন এটি গুরুত্বপূর্ণ। আরপিসি ডেমনটিতে একটি এক্সপ্লিট বেশ বড় সমস্যা, যা সফ্টওয়্যার আপডেট করে (বা এটি সীমাবদ্ধ করে) সমাধান করা যেতে পারে।

— ক্রিস

দুঃখিত, ঘর থেকে দৌড়ে গেছে। কোনও প্রোগ্রাম অ্যাক্সেস করতে পারে এমন শেল পরিবর্তন করা সেই সমস্যাটিকে ঠিক করে দেয় তবে প্রোগ্রামটি আসলে যা করায় তা আরও সমস্যা তৈরি করে। আমি ভেবেছিলাম আপনার মূলত বোঝা গেল যে কোনও দূষিত ব্যবহারকারী সেই ব্যবহারকারীর মাধ্যমে এসএসএইচ করতে পারে, যা তারা পারবেন না (যতক্ষণ না তারা কোনও চাবি সেট না করে, আমি বিশ্বাস করি, যেমন আপনি বলেছেন)। আপনি এই ছোট সমস্যাটি সমাধান করতে পারেন sshd_config- এ, "নির্দিষ্ট ব্যবহারকারীদের এসএসএইচ অ্যাক্সেসের অনুমতি দেওয়ার জন্য" অনুমতিপ্রাপ্ত ব্যবহারকারীদের <ব্যবহারকারীর নাম <ব্যবহারকারীর নাম ... "লিখুন।

— ক্রিস

Answer 3

আমি বিশ্বাস করি এটি একটি নন-ইস্যু, যেমন bin'হোম ডিরেক্টরি ( /bin) এর হোম ডিরেক্টরিতে ( ) একটি এসএসএইচ পাবলিক কী সেট আপ করার জন্য , আক্রমণকারীটির ফাইল সিস্টেমে রুট অ্যাক্সেস থাকতে হবে, যার অর্থ আপনি যেভাবেই ত্রুটিযুক্ত হয়ে গেছেন।

আপনি যদি চান binতবে MatchUserব্লকটি ব্যবহার করে আপনি sshd এর কনফিগারেশনে ব্যবহারকারীর জন্য সমস্ত প্রমাণীকরণ পদ্ধতি অক্ষম করতে পারেন ।

এটি বলেছিল, দেখে মনে হচ্ছে যে বিন ব্যবহারকারীর আধুনিক ডেবিয়ান উদ্ভূত সিস্টেমে অব্যবহৃত এবং নিখুঁতভাবে traditionতিহ্যের নীতি বা কিছু মান মেনে চলার জন্য এটি রয়েছে।