সার্ভার এনভায়রনমেন্ট ভেরিয়েবলে সমালোচনামূলক পাসওয়ার্ড সংরক্ষণ করা কি নিরাপদ?

Question

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

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

প্লেইন-পাঠ্য কনফিগারেশন ফাইলগুলিতে পাসওয়ার্ডগুলি এড়াতে এটি কি সর্বোত্তম উপায়, না এর থেকে আরও ভাল উপায় আছে?

Comments

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

— ফ্র্যাঙ্ক থমাস

ভাল চিন্তা, ফ্র্যাঙ্ক। আপনি যদি ক্রিপ্টো ব্যবহার করেন তবে আপনি কোন ধরণের সিস্টেম ব্যবহার করবেন? কোনও আরএসএ / এসএসএইচ কী, কীচেইন সরঞ্জাম, বা অন্য কোনও কিছুর উপর ভিত্তি করে কিছু? আমরা বর্তমানে সেন্টোস এবং অ্যামাজনের মতো লিনাক্স> 2.6 সিস্টেম ব্যবহার করি।

— স্টিভ এইচএইচএইচ

Answer 1

আপনি যদি লিনাক্স সিস্টেমে থাকেন তবে / proc / * / এনভায়রনমেন্টটি দেখুন এবং সিদ্ধান্ত নিন যে পরিবেশের ভেরিয়েবলগুলি সংবেদনশীল তথ্য সংরক্ষণের জন্য ভাল জায়গা কিনা। / proc / স্ব বর্তমান প্রক্রিয়া:

$ tr '\0' '\n' < /proc/self/environ
USER=me
LOGNAME=me
HOME=/home/me
PATH=/usr/bin:/bin:/usr/sbin:/sbin
MAIL=/var/mail/me
SHELL=/usr/bin/sh
SSH_CLIENT=1.2.3.4 58195 22
SSH_CONNECTION=1.2.3.4 58195 7.8.9.0 22
SSH_TTY=/dev/pts/1
TERM=xterm

পরিবেশ ভেরিয়েবলটি সেট করে জিনিসটি সম্ভবত কোথাও একটি ফাইল পড়ছে তা মনে করবেন না।

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

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

Comments

লিনাক্সের সাম্প্রতিক সংস্করণগুলির জন্য, পরিবেশের ভেরিয়েবলগুলি সম্ভবত ফাইলের মতোই নিরাপদ ।

— কেনি এভিট

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

— dannysauer

আপনি যে টিআর কমান্ড দিয়েছেন তা আমার পক্ষে কার্যকর হয়নি - এটি করেছে:cat /proc/self/environ | tr '\0' '\n'

— রোবোক্যাট

আমি আমার ফোনে আছি তাই বলা শক্ত ... এটি জিরো হওয়া উচিত; আপনি "ও" চিঠিটি টাইপ করেছেন?

— dannysauer

Answer 2

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

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

আমি যদি সত্যিই একটি মিশন-সমালোচনামূলক সিস্টেমে কিছু তথ্য রক্ষা করতে চাইতাম তবে আমি কী করব:

1. সম্পূর্ণ ডিস্ক এনক্রিপশন ব্যবহার করুন, যাতে সম্পূর্ণ অবিচ্ছিন্ন স্টোরেজের সামগ্রীগুলি এনক্রিপ্ট করা হয়।

2. মেশিনগুলিতে শারীরিক অ্যাক্সেসকে সীমাবদ্ধ করুন। সুরক্ষিত লকিং মেকানিজম দিয়ে মেশিনের চ্যাসিটি লক করুন এবং কীগুলিতে শারীরিক অ্যাক্সেস নিয়ন্ত্রণ করুন। অ্যাক্সেসের জন্য দারোয়ান হওয়ার জন্য পেশী (সশস্ত্র প্রহরী) ভাড়া করুন।

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

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

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

এটি একটি সম্পূর্ণ তালিকা নয়, তবে বিশেষত পয়েন্ট 4 সম্ভবত আপনার জন্য প্রাসঙ্গিক, যদিও আপনি কমপক্ষে 1 থেকে 3 পদক্ষেপ না করেন তবে পয়েন্ট 4 এবং পয়েন্ট 5 বিবেচনা আপনাকে খুব বেশি সাহায্য করবে না, কারণ আপনার সিস্টেমটি মোটামুটি মৌলিক স্তরে সুরক্ষিত নয়।

Comments

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

— ড্যানিসাউয়ার

"এটি সিস্টেম সুরক্ষা বনাম সুবিধার মূল প্রশ্নে উত্সাহিত করে" - আমার উত্তর থেকে উদ্ধৃত - যা আপনার মন্তব্যে সমানভাবে প্রযোজ্য। আপনি একই সাথে সুরক্ষা এবং সুবিধাকে আরও বাড়িয়ে তুলতে পারবেন না ।

— allquixotic

# 1 এই ক্ষেত্রে গুরুত্বপূর্ণ যে মেষটির কিছু অংশ ডিস্কে বদলে যায় (অদলবদল করে) বা যদি এটি কোনও এসএসডি সেক্টরে আঘাত করে যা পরে "খারাপ" হয়ে যায় এবং ওএস থেকে দূরে সরে যায় তবে এখনও সেই টুকরোটি র‌্যামটি ধারণ করে। এমনকি যখন ডিস্কটি আনলক করা থাকে তখনও সেই ফলকগুলিতে ডেটা খণ্ডটি শেষ হয়।

— আকিরা

Answer 3

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

নোট করুন যে কমান্ড লাইনে পাসওয়ার্ড দেওয়ার চেয়ে এটি আলাদা। কমান্ড লাইন আর্গুমেন্টগুলি একই মেশিনে চলমান সমস্ত প্রক্রিয়া (কঠোর ব্যবস্থা গ্রহণ ব্যতীত) পঠনযোগ্য, কেবল একই ব্যবহারকারীর মতো চলমান প্রক্রিয়াগুলি নয়।

আপনি যদি পরিবেশের মাধ্যমে কোনও ভেরিয়েবল পাস করেন তবে প্রোগ্রামটি অন্যান্য প্রোগ্রাম চালু করলে সাবধান হন। এই অন্যান্য প্রোগ্রামগুলি তাদের পিতামাতার পরিবেশের উত্তরাধিকারী হবে। সুতরাং যদি আপনি আশঙ্কা করেন যে অন্যান্য প্রোগ্রামগুলি ঘটনাক্রমে তাদের পরিবেশের বিষয়বস্তু ফাঁস করে দেয় this

আপনার দৃশ্যের ত্রুটিটি হ'ল "সার্ভার সিস্টেমটি সেট আপ হওয়ার পরে উপযুক্ত পরিবেশের পরিবর্তনশীল তৈরি করুন"। পরিবেশের পরিবর্তনশীল একটি প্রক্রিয়াটির গতিশীল সম্পত্তি। সিস্টেম সেটআপ করার সময় আপনি এটি তৈরি করতে পারবেন না, সেট আপ করে আপনি এমন কিছু বোঝাচ্ছেন যা পুনরায় বুট থেকে বেঁচে থাকে। কি আপনি কি বোঝাতে চেয়েছেন সম্ভবতঃ সেই প্রশাসকের এই পরিবর্তনশীল ব্যবস্থা যখন। এই একটি নির্দিষ্ট ব্যবহারকারী লগ (সাধারণত একটি কনফিগারেশন ফাইল মাধ্যমে সম্পন্ন করা হয় পরিবেশ উপস্থিত হতে হয় ~/.pam_environmentবা ~/.profileঅথবা একটি ফাইল থেকে পড়া ~/.profile)। সুতরাং এই সমাধানটি আসলে কনফিগারেশন ফাইলগুলির বাইরে পাসওয়ার্ড সরিয়ে দেয় না।

জিনিসগুলি সেট আপ করা যাতে পাসওয়ার্ডগুলি ব্যবহারকারীর লগইন-সময় পরিবেশে থাকে কোনও ভাল ধারণা নয়। এর অর্থ হ'ল যে ব্যবহারকারী হিসাবে চলমান প্রতিটি প্রক্রিয়াটির গোপনীয়তা থাকবে তাই এটি যে কোনও জায়গায় ফাঁস হওয়ার ঝুঁকিপূর্ণ।

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