TeamPCP-কে এতদিন মূলত সফটওয়্যার সরবরাহব্যবস্থায় হামলা চালানো তুলনামূলক নতুন সাইবার অপরাধী গোষ্ঠী হিসেবে দেখা হতো। কিন্তু নতুন গবেষণায় তাদের সঙ্গে সম্পর্কিত কার্যক্রমের ইতিহাস অন্তত ২০২০ সাল পর্যন্ত পৌঁছানোর প্রমাণ পাওয়া গেছে।
Oligo Security এর নতুন গবেষণায় দেখা গেছে, TeamPCP-সংশ্লিষ্ট হামলাকারীরা শুরুর দিকে Redis, Docker, Ray ও React-এর মতো ইন্টারনেটে উন্মুক্ত অবকাঠামো লক্ষ্য করত। পরে তারা আরও জটিল কৌশলে যায়।
পরবর্তী সময়ে তাদের কার্যক্রম ছড়িয়ে পড়ে সফটওয়্যার সরবরাহব্যবস্থার হামলায়। এর মধ্যে ছিল GitHub Actions, চুরি করা গোপন টোকেন এবং ওপেন সোর্স প্রকল্পের মাধ্যমে ক্ষতিকর কোড ছড়িয়ে দেওয়া।
এ ধরনের আক্রমণ ঠেকাতে শুধু একটি সার্ভার সুরক্ষিত রাখলেই চলে না। সফটওয়্যার তৈরির পুরো প্রক্রিয়ায় Zero Trust ও DevSecOps ভিত্তিক নিরাপত্তা ব্যবহার করলে প্রবেশাধিকার ও গোপন তথ্যের ঝুঁকি আরও নিয়ন্ত্রণে রাখা যায়।
TeamPCP-এর ইতিহাস কি সত্যিই ২০২০ সাল থেকে
গবেষকেরা বলেননি যে ২০২০ সাল থেকেই TeamPCP নামটি ব্যবহার করা হতো। বরং TA NATALSTATUS নামে আগে শনাক্ত হওয়া কার্যক্রম এবং পরে IronErn ও ShadowRay 2.0 অভিযানের সঙ্গে উল্লেখযোগ্য মিল পাওয়া গেছে।
Oligo Security বিভিন্ন সময়ের হামলায় ব্যবহৃত ডোমেইন, ক্ষতিকর ফাইল রাখার পদ্ধতি, নিয়ন্ত্রণকারী সার্ভার, অবকাঠামো ও হামলার কৌশল তুলনা করেছে। তাতে বহু বছরের কার্যক্রমের মধ্যে একটি ধারাবাহিক সম্পর্ক ধরা পড়েছে।
তবে এই মিলকে শতভাগ নিশ্চিত পরিচয় হিসেবে দেখা ঠিক হবে না। এটি একই হামলাকারীদের ধারাবাহিক কাজ হতে পারে। আবার একই গোষ্ঠীর নাম বদল, ঘনিষ্ঠ সহযোগী গোষ্ঠী বা ভাগ করে নেওয়া অবকাঠামোর ফলও হতে পারে।
কীভাবে বদলেছে হামলার ধরন
Oligo-র বিশ্লেষণ অনুযায়ী, TeamPCP-সংশ্লিষ্ট কার্যক্রম শুরুতে তুলনামূলকভাবে বেশি নির্ভর করত ইন্টারনেটে সরাসরি উন্মুক্ত অবকাঠামো এবং পরিচিত নিরাপত্তা দুর্বলতার ওপর।
পরে তাদের কৌশল আরও বিস্তৃত হয়। GitHub Actions-এর মতো সফটওয়্যার তৈরির ব্যবস্থায় ঢোকা, চুরি করা টোকেন ব্যবহার এবং ওপেন সোর্স প্রকল্পে ক্ষতিকর কোড ঢোকানোর ঘটনাও সামনে আসে।
একটি দুর্বলতা কীভাবে সাধারণ ব্যবহারকারী বা প্রতিষ্ঠানের জন্য বড় ঝুঁকি হয়ে উঠতে পারে, তা Zoom এর Zoomsday নিরাপত্তা ত্রুটির ঘটনাতেও দেখা গেছে। সেখানে সফটওয়্যারের একটি দুর্বল অংশ পুরো ব্যবস্থার নিরাপত্তাকে প্রভাবিত করতে পারে।
সফটওয়্যার সরবরাহব্যবস্থার হামলায় ঝুঁকি আরও বড়। কারণ একটি ডেভেলপার অ্যাকাউন্ট বা একটি জনপ্রিয় প্রকল্প আক্রান্ত হলে সেই সফটওয়্যার ব্যবহারকারী বহু প্রতিষ্ঠান ও ব্যবহারকারীর কাছেও ক্ষতিকর কোড পৌঁছাতে পারে।
Redis সার্ভার কেন ঝুঁকিতে পড়ে
Redis নিজে অনিরাপদ ডাটাবেস নয়। বড় ঝুঁকি তৈরি হয় যখন এটি ভুলভাবে কনফিগার করা হয়, প্রয়োজনের চেয়ে বেশি নেটওয়ার্ক প্রবেশাধিকার দেওয়া হয় অথবা অবিশ্বস্ত নেটওয়ার্ক থেকে সরাসরি ব্যবহারযোগ্য রাখা হয়।
Redis এর অফিসিয়াল নিরাপত্তা নির্দেশনা অনুযায়ী, Redis সাধারণত বিশ্বস্ত পরিবেশে ব্যবহার করা উচিত। অবিশ্বস্ত ব্যবহারকারীর জন্য এর পোর্ট সরাসরি উন্মুক্ত রাখা নিরাপদ পদ্ধতি নয়।
Redis সাধারণত 6379 পোর্ট ব্যবহার করে। এই পোর্ট অকারণে ইন্টারনেটে উন্মুক্ত থাকলে, প্রবেশ নিয়ন্ত্রণ দুর্বল হলে অথবা জরুরি নিরাপত্তা সেটিং ভুলভাবে বদলে গেলে স্বয়ংক্রিয় স্ক্যানিং ও হামলার ঝুঁকি বাড়ে।
বাইরের অপ্রয়োজনীয় প্রবেশ বন্ধ করুন
ফায়ারওয়াল বা ক্লাউডের নেটওয়ার্ক রুল ব্যবহার করে Redis-এর 6379 পোর্ট শুধু প্রয়োজনীয় সার্ভার, অ্যাপ্লিকেশন বা বিশ্বস্ত নেটওয়ার্কের জন্য খোলা রাখা উচিত। ইন্টারনেট থেকে অকারণ প্রবেশ বন্ধ রাখাই এখানে সবচেয়ে বড় পদক্ষেপ।
একই সার্ভারে অ্যাপ আর Redis চললে প্রয়োজন অনুযায়ী Redis-কে স্থানীয় ইন্টারফেসে বাঁধা (bind) যেতে পারে। Redis-এর অফিসিয়াল ডকুমেন্টেশনে স্থানীয় ব্যবহারের উদাহরণ হিসেবে নিচের কনফিগারেশন দেখানো হয়েছে।
bind 127.0.0.1
তবে প্রতিটি সার্ভারের পরিবেশ এক নয়। তাই কনফিগারেশন সরাসরি কপি করার আগে নিজের নেটওয়ার্ক কাঠামো, অ্যাপ্লিকেশনের চাহিদা ও ডেপ্লয়মেন্ট পদ্ধতির সঙ্গে মিলিয়ে নেওয়া উচিত।
Protected mode চালু রাখুন
Redis-এর protected mode ভুল কনফিগারেশনের কারণে তৈরি হওয়া অননুমোদিত প্রবেশের ঝুঁকি কমাতে সাহায্য করে। ডিফল্ট কনফিগারেশন ভুলবশত বাইরের নেটওয়ার্কে উন্মুক্ত হয়ে গেলে এটি বাড়তি সুরক্ষা দিতে পারে।
সাধারণ কনফিগারেশনে নিচের সেটিং চালু থাকে:
protected-mode yes
তবে protected mode একা পুরো নিরাপত্তা দেয় না। ফায়ারওয়াল, নেটওয়ার্কে প্রবেশের সীমা, পরিচয় যাচাই এবং প্রয়োজন অনুযায়ী সীমিত অনুমতি একসঙ্গে ব্যবহার করলে Redis-এর সুরক্ষা অনেক বেশি কার্যকর হয়।
ACL ব্যবহার করে অনুমতি সীমিত করুন
Redis 6 থেকে অ্যাক্সেস কন্ট্রোল লিস্ট বা ACL ব্যবহার করে আলাদাভাবে ঠিক করা যায়, কোন ব্যবহারকারী কোন কমান্ড চালাতে পারবেন এবং কোন কী ব্যবহার করতে পারবেন।
Redis এর অফিসিয়াল ACL নির্দেশনায় নামযুক্ত ব্যবহারকারী তৈরি এবং নির্দিষ্ট কমান্ড ও কী-তে প্রবেশ সীমিত করার ব্যবস্থা রয়েছে। ফলে সব সংযোগকে একই রকম পূর্ণ ক্ষমতা দিতে হয় না।
এই পদ্ধতির মূল লক্ষ্য হলো প্রত্যেক ব্যবহারকারী বা অ্যাপ্লিকেশনকে শুধু প্রয়োজনীয় অনুমতি দেওয়া। এতে একটি ক্রেডেনশিয়াল ফাঁস হলেও আক্রমণকারীর হাতে পুরো Redis ইনস্ট্যান্সের নিয়ন্ত্রণ চলে যাওয়ার ঝুঁকি কমে।
একই নীতি সাধারণ অনলাইন অ্যাকাউন্টের বেলায়ও খাটে। Google Password Manager ও passkey নিরাপত্তা নিয়ে আমাদের প্রতিবেদনে পাসওয়ার্ড ও অ্যাকাউন্টে প্রবেশ শক্তিশালী রাখার প্রয়োজন ব্যাখ্যা করা হয়েছে।
নিয়মিত হালনাগাদ এবং নজরদারি জরুরি
Redis-এর পুরোনো সংস্করণ হালনাগাদ না করে দীর্ঘদিন চালানো উচিত নয়। নিরাপত্তা হালনাগাদ সময়মতো দিতে হবে। একই সঙ্গে সার্ভারের রিসোর্স ব্যবহার, চালু প্রসেস, নির্ধারিত টাস্ক এবং জরুরি কনফিগারেশন নিয়মিত খেয়াল রাখা দরকার।
প্রসেসরের ব্যবহার হঠাৎ অস্বাভাবিক বেড়ে যাওয়া, অচেনা প্রসেস চালু হওয়া, অপরিচিত নির্ধারিত টাস্ক তৈরি হওয়া অথবা জরুরি কনফিগারেশন বদলে যাওয়া সম্ভাব্য নিরাপত্তা সমস্যার লক্ষণ হতে পারে।
এমন আচরণ দেখা গেলে আক্রান্ত সার্ভার প্রয়োজন অনুযায়ী নেটওয়ার্ক থেকে বিচ্ছিন্ন করে তদন্ত করা উচিত। শুধু সন্দেহজনক ফাইল মুছে ফেললে হবে না, কারণ পাসওয়ার্ড, টোকেন বা অন্য ক্রেডেনশিয়াল চুরি হয়ে থাকতে পারে।
সফটওয়্যার সরবরাহব্যবস্থার হামলা কেন বেশি উদ্বেগের
সাধারণ সার্ভার হামলায় একটি নির্দিষ্ট সিস্টেম আক্রান্ত হতে পারে। কিন্তু সফটওয়্যার সরবরাহব্যবস্থার হামলায় ক্ষতিকর কোড এমন কোনো প্যাকেজ, রিপোজিটরি বা ডেভেলপমেন্ট প্রক্রিয়ায় ঢুকতে পারে, যা পরে বহু ব্যবহারকারীর কাছে পৌঁছে যায়।
TeamPCP নিয়ে Oligo-র গবেষণার একটি বড় দিক হলো, তাদের সঙ্গে সম্পর্কিত কার্যক্রম কীভাবে ইন্টারনেটে উন্মুক্ত অবকাঠামো লক্ষ্য করা থেকে GitHub, টোকেন চুরি এবং ওপেন সোর্স প্রকল্পভিত্তিক হামলার দিকে ছড়িয়েছে।
তাই প্রতিষ্ঠানগুলোর শুধু সার্ভার নয়, ডেভেলপার অ্যাকাউন্ট, GitHub workflow, গোপন টোকেন, ডিপেন্ডেন্সি এবং সফটওয়্যার তৈরির পুরো প্রক্রিয়ার নিরাপত্তায় নজর রাখা দরকার।
বাংলাদেশের প্রতিষ্ঠানগুলোর জন্য কেন গুরুত্বপূর্ণ
বাংলাদেশে ওয়েবসাইট, সফটওয়্যার প্রতিষ্ঠান, অনলাইন সেবা ও ক্লাউডভিত্তিক ব্যবসায় Redis-সহ বিভিন্ন ওপেন সোর্স প্রযুক্তি ব্যবহার করা হয়। কনফিগারেশনে ভুল থাকলে এসব সিস্টেমও স্বয়ংক্রিয় স্ক্যানিং ও হামলার লক্ষ্য হতে পারে।
ছোট প্রতিষ্ঠান বা ব্যক্তিগত সার্ভারে নিয়মিত নিরাপত্তা নজরদারি সীমিত থাকলে ইন্টারনেটে উন্মুক্ত কোনো সেবা দীর্ঘ সময় অরক্ষিত থেকে যেতে পারে। তাই শুরু থেকেই নেটওয়ার্কে প্রবেশের সীমা এবং অ্যাক্সেস কন্ট্রোল ঠিকভাবে ঠিক করে নেওয়া জরুরি।
সাধারণ প্রশ্ন
TeamPCP কি ২০২০ সাল থেকেই একই নামে সক্রিয় ছিল
না। TeamPCP নামটি পরে সামনে আসে। গবেষকেরা TA NATALSTATUS, IronErn ও ShadowRay 2.0 সম্পর্কিত পুরোনো অবকাঠামো এবং কাজের ধরনের সঙ্গে পরবর্তী TeamPCP কার্যক্রমের উল্লেখযোগ্য মিল পেয়েছেন।
শুধু পাসওয়ার্ড দিলেই কি Redis নিরাপদ থাকবে
না। পরিচয় যাচাই জরুরি, কিন্তু সঙ্গে ফায়ারওয়াল, সীমিত নেটওয়ার্ক প্রবেশ, ACL, protected mode ও নিয়মিত নিরাপত্তা হালনাগাদও ব্যবহার করা উচিত। ব্যবহারকারীকে প্রয়োজনের বাইরে অনুমতি না দেওয়াও নিরাপত্তার একটি বড় অংশ।
Redis কি সরাসরি ইন্টারনেটে রাখা উচিত
সাধারণভাবে Redis-কে অবিশ্বস্ত নেটওয়ার্ক থেকে সরাসরি প্রবেশযোগ্য রাখা উচিত নয়। শুধু প্রয়োজনীয় অ্যাপ্লিকেশন, সার্ভার বা বিশ্বস্ত নেটওয়ার্ক থেকে প্রবেশের সুযোগ দেওয়া Redis-এর অফিসিয়াল নিরাপত্তা নির্দেশনার সঙ্গে মেলে।
শেষ কথা
Oligo Security-র গবেষণা দেখায়, TeamPCP-সংশ্লিষ্ট কার্যক্রম হঠাৎ শুরু হয়নি। Redis, Docker, Ray ও React-এর মতো অবকাঠামো লক্ষ্য করা পুরোনো কার্যক্রমের সঙ্গে পরবর্তী বড় সরবরাহব্যবস্থার হামলার ধারাবাহিক সম্পর্ক পাওয়া গেছে।
তবে ২০২০ সালের সব হামলা একই TeamPCP সদস্যরাই করেছে, এমন নিশ্চিত সিদ্ধান্ত এখনো নেই। বহু বছরের অবকাঠামো, কৌশল ও আচরণের মধ্যে পাওয়া ধারাবাহিক মিলের ভিত্তিতেই গবেষণাটি এই সংযোগ তুলে ধরেছে।
সার্ভার পরিচালনাকারীদের জন্য মূল শিক্ষা হলো, Redis বা অন্য কোনো জরুরি সেবা ভুল কনফিগারেশনসহ সরাসরি ইন্টারনেটে উন্মুক্ত থাকলে স্বয়ংক্রিয় স্ক্যানিং, ক্রেডেনশিয়াল অপব্যবহার ও হামলার ঝুঁকি উল্লেখযোগ্যভাবে বেড়ে যেতে পারে।
সর্বশেষ আপডেট: ১২ অক্টোবর ২০২৬
