কিভাবে "তৃতীয় পক্ষ" আমাদের গ্রাহকদের সাথে হস্তক্ষেপ করার চেষ্টা করেছিল এবং কীভাবে এই সমস্যাটি সমাধান করা হয়েছিল সে সম্পর্কে আপনাকে একটি দুর্দান্ত গল্প বলি।
কিভাবে এটা সব শুরু
এটি সবই 31 অক্টোবর, মাসের শেষ দিন সকালে শুরু হয়েছিল, যখন অনেকের জরুরী এবং গুরুত্বপূর্ণ বিষয়গুলি বন্ধ করার জন্য নিদারুণভাবে সময় প্রয়োজন।
একজন অংশীদার, যিনি আমাদের ক্লাউডে পরিবেশন করা ক্লায়েন্টদের বেশ কয়েকটি ভার্চুয়াল মেশিন রাখেন, রিপোর্ট করেছেন যে 9:10 থেকে 9:20 পর্যন্ত, আমাদের ইউক্রেনীয় সাইটে চলমান বেশ কয়েকটি উইন্ডোজ সার্ভার একবারে রিমোট অ্যাক্সেস পরিষেবার সাথে সংযোগ গ্রহণ করেনি, ব্যবহারকারীরা তাদের ডেস্কটপ অ্যাক্সেস করতে পারেনি, কিন্তু কয়েক মিনিট পরে সমস্যাটি নিজেই অদৃশ্য হয়ে গেছে বলে মনে হচ্ছে।
আমরা যোগাযোগ চ্যানেলের পরিসংখ্যান উত্থাপন করেছি, কিন্তু ট্র্যাফিক বা ব্যর্থতার কোনো বিস্ফোরণ খুঁজে পাইনি। আমরা কম্পিউটিং সংস্থানগুলিতে লোডের পরিসংখ্যান দেখেছি - কোনও অসঙ্গতি নেই। এবং এটা কি ছিল?
তারপরে অন্য একজন অংশীদার, যিনি আমাদের ক্লাউডে আরও একশত সার্ভার হোস্ট করেন, একই সমস্যাগুলি রিপোর্ট করেছেন যা তাদের কিছু ক্লায়েন্ট উল্লেখ করেছে, যখন দেখা গেল যে সাধারণভাবে সার্ভারগুলি উপলব্ধ (সঠিকভাবে পিং-টেস্ট এবং অন্যান্য অনুরোধগুলিতে প্রতিক্রিয়া জানায়), তবে পরিষেবাটি এই সার্ভারগুলিতে দূরবর্তী অ্যাক্সেস হয় নতুন সংযোগ গ্রহণ করে বা সেগুলিকে প্রত্যাখ্যান করে, যখন আমরা বিভিন্ন সাইটে সার্ভার সম্পর্কে কথা বলছিলাম, বিভিন্ন ডেটা ট্রান্সমিশন চ্যানেল থেকে ট্রাফিক আসে।
আসুন এই ট্রাফিক কটাক্ষপাত করা যাক. একটি সংযোগ স্থাপনের অনুরোধ সহ একটি প্যাকেট সার্ভারে আসে:
xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
সার্ভার এই প্যাকেট গ্রহণ করে, কিন্তু সংযোগ প্রত্যাখ্যান করা হয়:
xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0
এর মানে হল যে সমস্যাটি স্পষ্টতই পরিকাঠামোর কোনো ত্রুটির কারণে নয়, অন্য কিছুর কারণে। হতে পারে সমস্ত ব্যবহারকারীদের দূরবর্তী ডেস্কটপ লাইসেন্সিং নিয়ে সমস্যা আছে? হয়তো কোনো ধরনের ম্যালওয়্যার তাদের সিস্টেমে অনুপ্রবেশ করতে পেরেছে, এবং আজ এটি সক্রিয় হয়েছে, যেমনটি কয়েক বছর আগে ছিল। এক্সডেটা и Petya?
এটি বাছাই করার সময়, আমরা আরও অনেক ক্লায়েন্ট এবং অংশীদারদের কাছ থেকে অনুরূপ অনুরোধ পেয়েছি।
এই মেশিনে আসলে কি হয়?
ইভেন্ট লগ একটি পাসওয়ার্ড অনুমান করার চেষ্টা সম্পর্কে বার্তা পূর্ণ:
সাধারণত, এই ধরনের প্রচেষ্টাগুলি সমস্ত সার্ভারে লগ করা হয় যেখানে দূরবর্তী অ্যাক্সেস পরিষেবার জন্য স্ট্যান্ডার্ড পোর্ট (3389) ব্যবহার করা হয় এবং যে কোনও জায়গা থেকে অ্যাক্সেস অনুমোদিত। ইন্টারনেট এমন সব বট দ্বারা পরিপূর্ণ যেগুলি ক্রমাগত সমস্ত উপলব্ধ সংযোগ পয়েন্টগুলি স্ক্যান করে এবং পাসওয়ার্ড অনুমান করার চেষ্টা করে (এই কারণেই আমরা দৃঢ়ভাবে "123" এর পরিবর্তে জটিল পাসওয়ার্ড ব্যবহার করার পরামর্শ দিই)। যাইহোক, এই প্রচেষ্টার তীব্রতা সেদিন খুব বেশি ছিল।
কি করতে হবে?
সুপারিশ করুন যে গ্রাহকরা একটি ভিন্ন পোর্টে স্যুইচ করার জন্য বিপুল সংখ্যক শেষ ব্যবহারকারীর সেটিংস পরিবর্তন করতে অনেক সময় ব্যয় করেন? একটি ভাল ধারণা নয়, গ্রাহকরা খুশি হবে না। শুধুমাত্র VPN এর মাধ্যমে অ্যাক্সেসের অনুমতি দেওয়ার সুপারিশ করবেন? তাড়াহুড়ো করে এবং আতঙ্কিত হয়ে, যারা তাদের বাড়ায়নি তাদের জন্য IPSec সংযোগ উত্থাপন করা - সম্ভবত এই ধরনের খুশি গ্রাহকদেরও হাসে না। যদিও, আমি অবশ্যই বলব, এটি যে কোনও ক্ষেত্রেই একটি দাতব্য বিষয়, আমরা সর্বদা একটি ব্যক্তিগত নেটওয়ার্কে সার্ভারটি লুকিয়ে রাখার পরামর্শ দিই এবং সেটিংসে সাহায্য করার জন্য প্রস্তুত, এবং যারা নিজেরাই এটি বের করতে চান তাদের জন্য আমরা নির্দেশাবলী ভাগ করি। সাইট-টু-সাইট বা রোড মোডে আমাদের ক্লাউডে IPSec/L2TP সেট আপ করার জন্য, এবং যদি কেউ তাদের নিজস্ব উইন্ডোজ সার্ভারে একটি VPN পরিষেবা সেট আপ করতে চায়, তারা কীভাবে সেট আপ করতে হয় সে সম্পর্কে টিপস শেয়ার করতে সর্বদা প্রস্তুত থাকে। স্ট্যান্ডার্ড RAS বা OpenVPN। কিন্তু আমরা যতটা শান্ত ছিলাম, এটি গ্রাহক শিক্ষা করার সর্বোত্তম সময় ছিল না কারণ আমাদের ব্যবহারকারীদের যতটা সম্ভব কম বাধা দিয়ে যত তাড়াতাড়ি সম্ভব সমস্যার সমাধান করতে হবে।
আমরা যে সমাধানটি বাস্তবায়ন করেছি তা নিম্নরূপ ছিল। আমরা ট্রাফিক পাস করার বিশ্লেষণটি এমনভাবে সেট আপ করি যাতে পোর্ট 3389-এ একটি TCP সংযোগ স্থাপনের সমস্ত প্রচেষ্টা ট্র্যাক করা যায় এবং এটি থেকে ঠিকানাগুলি নির্বাচন করা যায় যা আমাদের নেটওয়ার্কে 150 সেকেন্ডের জন্য 16টিরও বেশি বিভিন্ন সার্ভারের সাথে সংযোগ স্থাপন করার চেষ্টা করে - এইগুলি হল আক্রমণের উত্স (অবশ্যই, যদি ক্লায়েন্ট বা অংশীদারদের মধ্যে একজনের একই উত্স থেকে এতগুলি সার্ভারের সাথে সংযোগ স্থাপনের সত্যিকারের প্রয়োজন থাকে তবে আপনি সর্বদা এই জাতীয় উত্সগুলিকে "সাদা তালিকায়" যুক্ত করতে পারেন৷ তাছাড়া, যদি একটি শ্রেণিতে থাকে এই 150 সেকেন্ডের জন্য সি নেটওয়ার্ক, 32 টিরও বেশি ঠিকানা চিহ্নিত করা হয়েছে, পুরো নেটওয়ার্কটি ব্লক করা অর্থপূর্ণ। ব্লকটি 3 দিনের জন্য সেট করা হয়েছে এবং যদি এই সময়ের মধ্যে এই উত্স থেকে কোনও আক্রমণ না করা হয় তবে এই উত্সটি থেকে সরানো হয় স্বয়ংক্রিয়ভাবে "কালো তালিকা"। অবরুদ্ধ উৎসের তালিকা প্রতি 300 সেকেন্ডে আপডেট করা হয়।
এই তালিকা এখানে উপলব্ধ: , আপনি এটির উপর ভিত্তি করে আপনার ACLs তৈরি করতে পারেন।
আমরা এই জাতীয় সিস্টেমের উত্স কোড ভাগ করতে প্রস্তুত, এতে খুব জটিল কিছু নেই (এগুলি "হাঁটুতে" মাত্র কয়েক ঘন্টার মধ্যে সংকলিত কয়েকটি সাধারণ স্ক্রিপ্ট), এবং একই সাথে এটি মানিয়ে নেওয়া যেতে পারে এবং শুধুমাত্র এই ধরনের আক্রমণ থেকে রক্ষা করার জন্যই নয়, নেটওয়ার্ক স্ক্যান করার যেকোনো প্রচেষ্টা সনাক্ত ও ব্লক করতেও ব্যবহৃত হয়:
উপরন্তু, আমরা মনিটরিং সিস্টেমের সেটিংসে কিছু পরিবর্তন করেছি, যা এখন আমাদের ক্লাউডে ভার্চুয়াল সার্ভারের কন্ট্রোল গ্রুপের প্রতিক্রিয়া একটি RDP সংযোগ স্থাপনের প্রয়াসে আরও ঘনিষ্ঠভাবে পর্যবেক্ষণ করে: যদি প্রতিক্রিয়াটি এক সেকেন্ডের মধ্যে অনুসরণ না করে , এই মনোযোগ দিতে একটি কারণ.
সমাধানটি বেশ কার্যকর বলে প্রমাণিত হয়েছে: উভয় ক্লায়েন্ট এবং অংশীদার এবং মনিটরিং সিস্টেম থেকে আর কোন অভিযোগ নেই। নতুন ঠিকানা এবং সম্পূর্ণ নেটওয়ার্ক নিয়মিতভাবে কালো তালিকাভুক্ত হয়, যা ইঙ্গিত করে যে আক্রমণ অব্যাহত রয়েছে, কিন্তু আমাদের ক্লায়েন্টদের কাজকে আর প্রভাবিত করে না।
মাঠে কোন যোদ্ধা নেই
আজ আমরা শিখেছি যে অন্যান্য অপারেটরগুলি একই রকম সমস্যার সম্মুখীন হয়েছে৷ কেউ এখনও বিশ্বাস করে যে মাইক্রোসফ্ট রিমোট অ্যাক্সেস পরিষেবার কোডে কিছু পরিবর্তন করেছে (যদি আপনার মনে থাকে, আমরা প্রথম দিনে একই জিনিসটি সন্দেহ করেছিলাম, তবে আমরা খুব শীঘ্রই এই সংস্করণটি প্রত্যাখ্যান করেছি) এবং সমাধানের পরিবর্তে সম্ভাব্য সবকিছু করার প্রতিশ্রুতি দেয়। . কেউ কেবল সমস্যাটিকে উপেক্ষা করে এবং ক্লায়েন্টদের নিজেদের রক্ষা করার পরামর্শ দেয় (সংযোগ পোর্ট পরিবর্তন করুন, একটি ব্যক্তিগত নেটওয়ার্কে সার্ভারটি লুকিয়ে রাখুন এবং আরও অনেক কিছু)। এবং প্রথম দিনেই, আমরা কেবল এই সমস্যার সমাধানই করিনি, বরং আরও বিশ্বব্যাপী হুমকি সনাক্তকরণ ব্যবস্থার জন্য কিছু ভিত্তি তৈরি করেছি যা আমরা বিকাশ করার পরিকল্পনা করছি।
গ্রাহক এবং অংশীদারদের বিশেষ ধন্যবাদ যারা নীরব থাকেননি এবং নদীর তীরে একদিন শত্রুর মৃতদেহ ভেসে আসার অপেক্ষায় বসে থাকেননি, কিন্তু অবিলম্বে সমস্যাটির দিকে আমাদের দৃষ্টি আকর্ষণ করেছিলেন, যা আমাদের সুযোগ দিয়েছিল। একই দিনে এটি নির্মূল করুন।
উত্স: www.habr.com