কন্টেন্ট ইন্ডেক্স করার জন্য সার্চ ইঞ্জিন তৈরি করা হয়েছিল। কিন্তু, আক্রমণকারীরা আপনার ভুলগুলো ইন্ডেক্স করার জন্য এগুলো ব্যবহার করে। কোয়েরিটি allintext:login ফাইলের ধরণ: লগ দেখতে নিরীহ মনে হতে পারে। বাস্তবে, এটি প্রমাণীকরণ প্রবাহ, পরিচয়পত্র, টোকেন এবং অভ্যন্তরীণ অবকাঠামোগত তথ্য ধারণকারী উন্মুক্ত লগ ফাইলগুলি খুঁজে বের করার অন্যতম সহজ উপায়।
গুগল যদি সেই লগগুলো দেখতে পারে, তবে আক্রমণকারীরাও তা দেখতে পাবে। একবার ইনডেক্স হয়ে গেলে, তথ্য ফাঁস হওয়া অনিবার্য হয়ে ওঠে। অধিকন্তু, যখন ক্রেডেনশিয়ালগুলো সর্বজনীনভাবে প্রবেশযোগ্য কোনো ফাইলে প্রকাশিত হয়, তখন নিরাপত্তা লঙ্ঘনের প্রক্রিয়াটি ইতোমধ্যেই শুরু হয়ে যায়।
১. কেন অলইনটেক্সট:login filetype:log দেখতে যতটা বিপজ্জনক মনে হয়, তার চেয়েও বেশি বিপজ্জনক।
গুগল ডর্ক হলো এমন একটি সার্চ কোয়েরি যা সার্চ ইঞ্জিন দ্বারা ইনডেক্স করা সংবেদনশীল বা ভুলভাবে কনফিগার করা কন্টেন্ট খুঁজে বের করার জন্য অ্যাডভান্সড অপারেটর ব্যবহার করে। এটি গুগলকে শোষণ করে না। বরং, এটি আপনার অরক্ষিত অবস্থাকে কাজে লাগায়।
এই কোয়েরিটি দুটি অপারেটরকে একত্রিত করে:
- allintext: যেসব পৃষ্ঠায় সমস্ত পদ মূল পাঠ্যে উপস্থিত থাকে, সেগুলি ফেরত দেয়।
- ফাইলের ধরণ: লগ ফলাফল সীমাবদ্ধ করে
.logনথি পত্র
অতএব:
মানে: “আমাকে সেই লগ ফাইলগুলি দেখান যেগুলিতে শব্দটি রয়েছে login. "
প্রথম দৃষ্টিতে, বিষয়টি তুচ্ছ মনে হতে পারে। তবে, বাস্তবে এর ফল প্রায়শই দাঁড়ায়:
- সর্বজনীনভাবে প্রকাশিত ওয়েব সার্ভার লগ
- CI/CD আর্টিফ্যাক্ট হিসাবে আপলোড করা লগ
- ডিবাগ লগগুলি দুর্ঘটনাক্রমে commitসংগ্রহস্থলে টেড
- প্লেইনটেক্সট ক্রেডেনশিয়াল সহ অ্যাপ্লিকেশন লগ
এটি সার্চ ইঞ্জিনের কোনো ত্রুটি নয়। বরং, এটি একটি ডেটা প্রকাশের ঝুঁকি ভুল কনফিগারেশনের কারণে এটি ঘটেছে। গুগল কেবল সর্বজনীনভাবে প্রবেশযোগ্য বিষয়গুলোকেই সূচীবদ্ধ করেছে।
২. আক্রমণকারীরা উন্মুক্ত লগ ফাইলগুলিতে আসলে কী খুঁজে পায়
যখন আক্রমণকারীরা দৌড়ায় allintext:login ফাইলের ধরণ: লগতারা এলোমেলোভাবে ব্রাউজ করছে না। তারা প্রমাণীকরণের চিহ্ন খুঁজছে।
২.১ প্লেইনটেক্সট ক্রেডেনশিয়াল
লগগুলিতে প্রায়শই এই ধরনের এন্ট্রি থাকে:
or
অথবা এমনকি SMTP ক্রেডেনশিয়াল:
অথেনটিকেশন পেলোড লগ করা প্রোডাকশন ক্রেডেনশিয়াল ফাঁস হওয়ার অন্যতম দ্রুততম উপায়। ফলস্বরূপ, ফাঁস হওয়া একটিমাত্র লগ ফাইল আপনার সম্পূর্ণ অ্যাক্সেস কন্ট্রোল মডেলকে অকার্যকর করে দিতে পারে।
২.২ সেশন টোকেন এবং JWT
পাসওয়ার্ড লগ করা না হলেও, টোকেন প্রায়শই লগ করা থাকে।
উদাহরণ স্বরূপ:
একটি বৈধ JWT বা সেশন কুকির ভিতরে .log ফাইলটি সক্ষম করতে পারে:
- সেশন হাইজ্যাকিং
- প্রিভিলেজ বৃদ্ধি
- অভ্যন্তরীণ সিস্টেম জুড়ে পার্শ্বীয় চলাচল
অন্য কথায়, লগ-এ থাকা টোকেনগুলো ডিবাগিং আউটপুটকে অথেনটিকেশন বাইপাস করার একটি মাধ্যমে পরিণত করে।
2.3 CI/CD হস্তনির্মিত
বিল্ড লগগুলো বিশেষভাবে বিপজ্জনক। প্রকৃতপক্ষে, CI/CD সিস্টেমগুলো প্রায়শই বিল্ড স্টেপ চলাকালীন এনভায়রনমেন্ট ভেরিয়েবল প্রিন্ট করে।
আক্রমণকারীরা প্রায়শই আবিষ্কার করে:
এই ধরনের লাইন ধারণকারী:
If CI/CD প্রত্নবস্তু যখন সর্বজনীন, তখন গোপনীয় বিষয়ও সর্বজনীন। গুগলের এই বিশেষ কৌশলটি কেবল আবিষ্কারের প্রক্রিয়াকে ত্বরান্বিত করে।
২.৪ ক্লাউড ও অবকাঠামোগত ডেটা
প্রকাশিত লগগুলিতে প্রায়শই যা প্রকাশ পায়:
- AWS অ্যাক্সেস কী
- অ্যাজুর স্টোরেজ সংযোগ স্ট্রিং
- অভ্যন্তরীণ পরিষেবা URL
- ডাটাবেস শংসাপত্র
- রেডিস এন্ডপয়েন্ট
পরবর্তীতে ক্রেডেনশিয়াল পরিবর্তন করা হলেও, আক্রমণকারীর কাছে এখন থাকবে:
- অবকাঠামো ম্যাপিং
- নামকরণ অনুষ্ঠান
- ভবিষ্যৎ আক্রমণের জন্য লক্ষ্যবস্তু সংক্রান্ত গোয়েন্দা তথ্য
সুতরাং, ফাঁস হওয়া লগগুলো প্রবেশাধিকার এবং তথ্য সংগ্রহ উভয়ই প্রদান করে।
৩. কীভাবে এই লগগুলো প্রথমত সর্বজনীন হয়ে যায়
লগগুলো গুগলে এমনি এমনি চলে আসে না। সেগুলো ইনডেক্সড হয় কারণ সেগুলো সর্বসাধারণের জন্য সহজলভ্য ছিল।
৩.১ ত্রুটিপূর্ণভাবে কনফিগার করা ওয়েব সার্ভার
সাধারণ প্যাটার্নগুলির মধ্যে রয়েছে:
/logs/প্রমাণীকরণ ছাড়াই ডিরেক্টরিগুলি অ্যাক্সেসযোগ্য- ডিরেক্টরি তালিকা সক্রিয় করা হয়েছে
- Nginx বা Apache কাঁচা পরিবেশন করছে
.logনথি পত্র
যদি কোনো লগ HTTP-এর মাধ্যমে অ্যাক্সেসযোগ্য হয়, তবে তা ইনডেক্সযোগ্য।
3.2 CI/CD আর্টিফ্যাক্ট এক্সপোজার
সাধারণ ভুল:
- সর্বজনীন নিদর্শনগুলি সক্রিয় করা হয়েছে গিটহাব অ্যাকশন
- খোলা S3 বাকেটগুলিতে লগ আপলোড করা হয়েছে
- Pipeline প্রমাণীকরণ ছাড়াই অ্যাক্সেসযোগ্য ট্রেস
A pipeline যেটি একটি পাবলিক বাকেটে লগ সংরক্ষণ করে, সেটি কার্যত তার গোপনীয় তথ্য প্রকাশ করে দেয়।
৩.৩ প্রোডাকশনে ডিবাগ মোড
ফ্রেমওয়ার্কের ডিফল্টগুলো বিপজ্জনক হতে পারে:
এছাড়াও, অতিরিক্ত অনুরোধ লগিংয়ের ফলে নিম্নলিখিত আউটপুট আসতে পারে:
- শিরোলেখ
- টোকেন
- সম্পূর্ণ অনুরোধ বডি
প্রোডাকশনে ডিবাগ লগিং আপনার অ্যাপ্লিকেশনকে একটি ক্রেডেনশিয়াল এক্সপোর্টারে রূপান্তরিত করে।
৩.৪ ডকার এবং কন্টেইনার লগ
কন্টেইনারাইজড পরিবেশ নতুন এক্সপোজার পাথ তৈরি করে:
- লগগুলি শেয়ার্ড ভলিউমে মাউন্ট করা হয়েছে
- সাইডকারগুলি অসুরক্ষিত এন্ডপয়েন্টগুলিতে লগ রপ্তানি করছে
- লগিন dashboardসর্বসাধারণের প্রবেশাধিকার সহ
কন্টেইনার লগগুলো HTTP বা ওপেন স্টোরেজের মাধ্যমে প্রকাশ করা হলে, সেগুলো অনুসন্ধানযোগ্য হয়। অবশেষে, সেগুলোকে ইনডেক্স করা হয়।
৪. বাস্তবসম্মত আক্রমণ প্রবাহ: ডর্ক থেকে ব্রীচ পর্যন্ত
একটি সাধারণ আক্রমণ শৃঙ্খল দেখতে এইরকম হয়:
আক্রমণকারী চালায়:
- প্রকাশিত তথ্য
.logফাইল - নিষ্কাশন:
- JWT টোকেন
- বেসিক অথেন্টিকেশন হেডার
- ডাটাবেস সংযোগ স্ট্রিং
এর বিরুদ্ধে প্রমাণীকরণের চেষ্টা করা হয়:
- এপিআই শেষ পয়েন্ট
- অ্যাডমিন প্যানেল
- অভ্যন্তরীণ পরিষেবা
প্রমাণীকরণ সফল হলে, আক্রমণকারী যা করতে পারে:
- বিশেষাধিকার বৃদ্ধি
- পার্শ্বীয়ভাবে সরান
- প্রবেশ CI/CD
- সরবরাহ শৃঙ্খলের সাথে আপস করা
যা অনুসন্ধান ক্যোয়ারি হিসেবে শুরু হয়েছিল, তা হয়ে ওঠে:
- সেশন হাইজ্যাকিং
- অভ্যন্তরীণ শংসাপত্র ভরা
- Pipeline টেকওভারের
- প্রত্নবস্তু বিষক্রিয়া
সবকিছু একটি সর্বজনীনভাবে সূচীবদ্ধ লগ ফাইল থেকে নেওয়া।
৫. কেন অতিরিক্ত লগিং একটি অ্যাপসিকিউরিটি সমস্যা
লগিং নিরপেক্ষ নয়। বরং, এটি একটি সেকেন্ডারি ডেটা স্টোর.
সংবেদনশীল তথ্য সংরক্ষণ করলে, আপনি কার্যত আপনার গোপনীয় তথ্যের একটি দ্বিতীয় অনুলিপি তৈরি করেন।
তবে, থ্রেট মডেলিং থেকে প্রায়শই লগ বাদ দেওয়া হয়। STRIDE-এর অধীনে, এটি স্পষ্টভাবে নির্দেশ করে:
প্রকাশের তথ্য
অতএব, সুরক্ষিত SDLC অনুশীলনগুলিতে লগগুলিকে নিম্নরূপ বিবেচনা করা উচিত:
- নিরাপত্তা-সম্পর্কিত নিদর্শন
- সংবেদনশীল সম্পদ
- সুরক্ষা প্রয়োজন এমন অবকাঠামোগত উপাদান
আপনার থ্রেট মডেল যদি লগ উপেক্ষা করে, তবে তা অসম্পূর্ণ।
৬. লগ ফাইলে ক্রেডেনশিয়াল ফাঁস কীভাবে প্রতিরোধ করবেন
৬.১ গোপনীয় তথ্য লগ করা বন্ধ করুন
কখনো লগ করবেন না:
- পাসওয়ার্ড
- টোকেন
- API কী
- সেশন আইডি
- অনুমোদন হেডার
এমনকি ডিবাগ মোডেও।
যখনই সম্ভব, স্বয়ংক্রিয়ভাবে তথ্য গোপনের ব্যবস্থা করুন।
৬.২ কাঠামোগত ও নিরাপদ লগিং
মাস্কিং এবং ফিল্টারিং সহ স্ট্রাকচার্ড লগিং ব্যবহার করুন।
উদাহরণ (নোড.জেএস):
উদাহরণ (পাইথন):
মূল নীতিটি সহজ: গোপনীয় তথ্য কখনোই লগ সিঙ্কে পৌঁছানো যাবে না।
৬.৩ কাঠের গুঁড়ি রাখার স্থান লক ডাউন
নিরাপত্তা নিয়ন্ত্রণের মধ্যে নিম্নলিখিত বিষয়গুলো অন্তর্ভুক্ত থাকা উচিত:
- ডিরেক্টরি তালিকা নিষ্ক্রিয় করুন
- রক্ষা করা
/logs/প্রমাণীকরণ সহ পথ - বালতির অ্যাক্সেস সীমাবদ্ধ করুন
- ধরে রাখার নীতি প্রয়োগ করুন
- সংরক্ষিত লগ এনক্রিপ্ট করুন
লগ ফাইল কখনোই HTTP-এর মাধ্যমে সর্বজনীনভাবে প্রবেশযোগ্য হওয়া উচিত নয়।
6.4 CI/CD Guardrails
ম্যানুয়াল পর্যালোচনা যথেষ্ট নয়। এর পরিবর্তে, স্বয়ংক্রিয় নিয়ন্ত্রণ ব্যবস্থা প্রয়োগ করুন:
- প্রত্নবস্তু প্রকাশের আগে লগগুলির গোপন স্ক্যানিং
- টোকেন শনাক্ত হলে বিল্ড ব্যর্থ হবে।
- ক্রেডেনশিয়ালযুক্ত আর্টিফ্যাক্ট আপলোড প্রতিরোধ করুন
- আর্টিফ্যাক্টগুলির জন্য হ্যাশ যাচাইকরণ
CI/CD ইনডেক্সিং হওয়ার আগেই এক্সপোজার ব্লক করা উচিত।
৭. জাইজেনি কীভাবে অলইনটেক্সট প্রতিরোধ করে:login ফাইলের ধরণ: লগ ঘটনা
সমস্যাটা গুগলের অদ্ভুত আচরণ নয়। সমস্যাটা হলো পরিচিতি। তাই, ইন্ডেক্স করার আগেই প্রতিরোধমূলক ব্যবস্থা নিতে হবে।
৭.১ লগ এবং আর্টিফ্যাক্টে গোপনীয় তথ্য সনাক্তকরণ
জাইজেনি স্ক্যান:
- অ্যাপ্লিকেশন লগ
- CI/CD কাজের চিহ্ন
- নিদর্শন তৈরি করুন
- ডকার স্তরগুলি
- ক্রমিক আউটপুট
যদি পরিচয়পত্র, টোকেন, বা সংবেদনশীল মান প্রদর্শিত হয় .log ফাইলগুলোকে Xygeni সাথে সাথে চিহ্নিত করে।
7.2 CI/CD Guardrails সেই ব্লক এক্সপোজার
ম্যানুয়াল পর্যালোচনার উপর নির্ভর করার পরিবর্তে, জাইজেনি নিরাপত্তা জোরদার করে pipeline স্তর:
এই:
- লগে গোপনীয় তথ্য দেখা গেলে বিল্ড ব্যর্থ হয়।
- ব্লক আর্টিফ্যাক্ট প্রকাশনা
- দুর্ঘটনাবশত জনসমক্ষে প্রকাশ রোধ করে
- মেইন-এ পৌঁছানোর আগে অনিরাপদ মার্জ বন্ধ করে দেয়।
যদি একটি CI জব একটি টোকেন প্রিন্ট করে, তাহলে pipeline ব্যর্থ।
কোনো সূচীকরণ নেই।
কোনো সংস্পর্শ নেই।
কোনো ঘটনা ঘটেনি।
৭.৩ গুগলের চোখে পড়ার আগেই শিফট-লেফট থেকে সুরক্ষা
সময় গুরুত্বপূর্ণ।
প্রতিক্রিয়া দেখানোর পরিবর্তে:
জাইজেনি সমস্যাটি সমাধান করে:
- At commit সময়
- সময় pull request বৈধতা
- সময় pipeline ফাঁসি
- প্রত্নবস্তু প্রকাশের আগে
লগটি যদি কখনো সর্বজনীন না হয়, গুগল তা কখনো ইনডেক্স করে না।
চূড়ান্ত কথা: গুগল যদি এটি ইন্ডেক্স করতে পারে, তবে আক্রমণকারীরা ইতিমধ্যেই তা করে ফেলেছে।
লগ ফাইলগুলো নিরীহ নয়। প্রকৃতপক্ষে, এগুলো খুব কমই অস্থায়ী হয়। স্বাভাবিকভাবেই, এগুলো গোপনীয় থাকে না। তাই, প্রতিটি লগ ফাইলকে শুধুমাত্র ডিবাগিং আউটপুট হিসেবে নয়, বরং একটি নিরাপত্তা-সংশ্লিষ্ট সম্পদ হিসেবে বিবেচনা করা উচিত।
যদি সংবেদনশীল তথ্য একটিতে পৌঁছায় .log ফাইলটি সর্বজনীনভাবে প্রবেশযোগ্য হয়ে ওঠে, এটি তাৎক্ষণিকভাবে একটি আক্রমণ পৃষ্ঠে পরিণত হয়। তাছাড়া, একবার কোনো সার্চ ইঞ্জিনে তালিকাভুক্ত হয়ে গেলে, এর প্রভাব আপনার নিয়ন্ত্রণের বাইরে চলে যায়।
সমাধানটি লগিং বন্ধ করা নয়। বরং, দায়িত্বের সাথে লগ করা এবং এর সংরক্ষণ ও বিতরণের ক্ষেত্রে কঠোর নিয়ন্ত্রণ আরোপ করা। অন্য কথায়, নিরাপত্তাকে অবশ্যই অ্যাপ্লিকেশনটির বাইরে গিয়ে পর্যবেক্ষণ স্তর পর্যন্ত বিস্তৃত হতে হবে।
পরিবর্তে:
- গোপনীয় তথ্য লগ করা বন্ধ করুন
- লগ স্টোরেজ লক ডাউন করুন
- জোরদার করা pipeline guardrails
- স্বয়ংক্রিয় সনাক্তকরণ এবং নীতি প্রয়োগ
পরিণামে, প্রতিরোধের মূল চাবিকাঠি হলো সঠিক সময়। কারণ একবার allintext:login ফাইলের ধরণ: লগ আপনার ডোমেইন ফেরত দিলে, ঘটনাটি ইতিমধ্যে শুরু হয়ে গেছে।
