উদ্ধারের জন্য DDoS: আমরা কীভাবে চাপ এবং লোড পরীক্ষা পরিচালনা করি

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

পাঠ্যটি পড়ার আগে, আপনি সংক্ষিপ্ত বিমূর্তগুলি পড়তে পারেন সম্মেলনের ওয়েবসাইটে.
এবং আপনি যদি পড়তে পছন্দ না করেন বা শুধু ভিডিওটি দেখতে চান তবে আমাদের প্রতিবেদনের রেকর্ডিংটি স্পয়লারের নীচে রয়েছে।

প্রতিবেদনের ভিডিও রেকর্ডিং

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

আমরা কিভাবে কাজ করছি

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

অনুমান করে

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

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

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

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

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

L7 আক্রমণের স্বতন্ত্র বৈশিষ্ট্য

আমরা সাধারণত L7 এবং L3 এবং 4 স্তরে লোডের ধরনগুলিকে ভাগ করি। L7 হল অ্যাপ্লিকেশন স্তরে একটি লোড, প্রায়শই এর অর্থ শুধুমাত্র HTTP, কিন্তু আমরা TCP প্রোটোকল স্তরে যেকোন লোডকে বোঝায়।
L7 আক্রমণের কিছু স্বতন্ত্র বৈশিষ্ট্য রয়েছে। প্রথমত, তারা সরাসরি অ্যাপ্লিকেশনে আসে, অর্থাৎ, তারা নেটওয়ার্কের মাধ্যমে প্রতিফলিত হওয়ার সম্ভাবনা কম। এই ধরনের আক্রমণ যুক্তি ব্যবহার করে, এবং এর কারণে, তারা খুব দক্ষতার সাথে এবং সামান্য ট্রাফিকের সাথে CPU, মেমরি, ডিস্ক, ডাটাবেস এবং অন্যান্য সংস্থানগুলি ব্যবহার করে।

HTTP বন্যা

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

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

কী সন্ধান করবেন

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

কোথায় খুঁজছেন

যখন আমরা পরীক্ষার আগে একটি সংস্থান স্ক্যান করি, তখন আমরা প্রথমে অবশ্যই সাইটের দিকে তাকাই। আমরা সব ধরণের ইনপুট ক্ষেত্র, ভারী ফাইল খুঁজছি - সাধারণভাবে, সবকিছু যা সম্পদের জন্য সমস্যা তৈরি করতে পারে এবং এর ক্রিয়াকলাপকে ধীর করে দিতে পারে। গুগল ক্রোম এবং ফায়ারফক্সের ব্যানাল ডেভেলপমেন্ট টুল এখানে সাহায্য করে, পৃষ্ঠার প্রতিক্রিয়ার সময় দেখায়।
আমরা সাবডোমেনগুলিও স্ক্যান করি। উদাহরণস্বরূপ, একটি নির্দিষ্ট অনলাইন স্টোর আছে, abc.com, এবং এটির একটি সাবডোমেন admin.abc.com আছে। সম্ভবত, এটি অনুমোদন সহ একটি অ্যাডমিন প্যানেল, তবে আপনি যদি এটিতে একটি লোড রাখেন তবে এটি মূল সংস্থানের জন্য সমস্যা তৈরি করতে পারে।
সাইটের একটি সাবডোমেন api.abc.com থাকতে পারে। সম্ভবত, এটি মোবাইল অ্যাপ্লিকেশনগুলির জন্য একটি সংস্থান। অ্যাপ্লিকেশনটি অ্যাপ স্টোর বা গুগল প্লেতে পাওয়া যাবে, একটি বিশেষ অ্যাক্সেস পয়েন্ট ইনস্টল করুন, এপিআই বিচ্ছিন্ন করুন এবং পরীক্ষার অ্যাকাউন্ট নিবন্ধন করুন। সমস্যা হল যে লোকেরা প্রায়শই মনে করে যে অনুমোদন দ্বারা সুরক্ষিত যে কোনও কিছু পরিষেবা আক্রমণ অস্বীকার করার জন্য অনাক্রম্য। অনুমিতভাবে, অনুমোদন হল সেরা ক্যাপচা, কিন্তু তা নয়। 10-20টি পরীক্ষামূলক অ্যাকাউন্ট তৈরি করা সহজ, কিন্তু সেগুলি তৈরি করে, আমরা জটিল এবং ছদ্মবেশী কার্যকারিতায় অ্যাক্সেস পাই।
স্বাভাবিকভাবেই, আমরা ইতিহাস দেখি, robots.txt এবং WebArchive, ViewDNS, এবং রিসোর্সের পুরানো সংস্করণগুলি সন্ধান করি। কখনও কখনও এটি ঘটে যে ডেভেলপাররা mail2.yandex.net চালু করেছে, কিন্তু পুরানো সংস্করণ, mail.yandex.net, রয়ে গেছে। এই mail.yandex.net আর সমর্থিত নয়, এটিতে উন্নয়ন সংস্থান বরাদ্দ করা হয় না, তবে এটি ডাটাবেস ব্যবহার করে চলেছে। তদনুসারে, পুরানো সংস্করণ ব্যবহার করে, আপনি ব্যাকএন্ডের সংস্থানগুলি এবং লেআউটের পিছনে থাকা সমস্ত কিছু কার্যকরভাবে ব্যবহার করতে পারেন। অবশ্যই, এটি সর্বদা ঘটে না, তবে আমরা এখনও প্রায়শই এটির মুখোমুখি হই।
স্বাভাবিকভাবেই, আমরা সমস্ত অনুরোধের পরামিতি এবং কুকির গঠন বিশ্লেষণ করি। আপনি, বলুন, কুকির ভিতরে একটি JSON অ্যারেতে কিছু মান ডাম্প করতে পারেন, প্রচুর নেস্টিং তৈরি করতে পারেন এবং অযৌক্তিকভাবে দীর্ঘ সময়ের জন্য সংস্থানকে কাজ করতে পারেন।

অনুসন্ধান লোড

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

যদি কোন খোঁজ নেই?

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

রেস্ট এপিআই

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

ভারী সামগ্রী লোড হচ্ছে

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

সার্ভার সেট আপ সম্পর্কে ভুলবেন না. আপনি প্রায়ই দেখতে পারেন যে একজন ব্যক্তি একটি ভার্চুয়াল মেশিন কিনেছেন, সেখানে অ্যাপাচি ইনস্টল করেছেন, ডিফল্টরূপে সবকিছু কনফিগার করেছেন, একটি পিএইচপি অ্যাপ্লিকেশন ইনস্টল করেছেন এবং নীচে আপনি ফলাফল দেখতে পাবেন।

এখানে লোডটি রুটে গিয়েছিল এবং মাত্র 10 আরপিএসের পরিমাণ ছিল। আমরা 5 মিনিট অপেক্ষা করেছি এবং সার্ভার ক্র্যাশ হয়ে গেছে। এটা সত্য যে তিনি কেন পড়েছিলেন তা সম্পূর্ণরূপে জানা যায়নি, তবে একটি ধারণা রয়েছে যে তার খুব বেশি স্মৃতিশক্তি ছিল এবং তাই প্রতিক্রিয়া দেওয়া বন্ধ করে দিয়েছিলেন।

তরঙ্গ ভিত্তিক

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

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

একা HTTP নয়

L7 এ HTTP ছাড়াও, আমরা অন্যান্য প্রোটোকল ব্যবহার করতে চাই। একটি নিয়ম হিসাবে, একটি নিয়মিত ওয়েবসাইট, বিশেষ করে একটি নিয়মিত হোস্টিং, মেইল ​​প্রোটোকল এবং মাইএসকিউএল স্টিকিং আউট আছে। মেল প্রোটোকলগুলি ডাটাবেসের তুলনায় কম লোডের বিষয়, তবে সেগুলি বেশ দক্ষতার সাথে লোড হতে পারে এবং সার্ভারে একটি ওভারলোডেড সিপিইউ দিয়ে শেষ হয়।
আমরা 2016 SSH দুর্বলতা ব্যবহার করে বেশ সফল ছিলাম। এখন এই দুর্বলতা প্রায় প্রত্যেকের জন্য সংশোধন করা হয়েছে, কিন্তু এর মানে এই নয় যে SSH-এ লোড জমা দেওয়া যাবে না। করতে পারা. অনুমোদনের একটি বিশাল লোড রয়েছে, SSH সার্ভারের প্রায় পুরো CPU খেয়ে ফেলে এবং তারপরে প্রতি সেকেন্ডে এক বা দুটি অনুরোধ থেকে ওয়েবসাইটটি ভেঙে পড়ে। তদনুসারে, লগের উপর ভিত্তি করে এই এক বা দুটি অনুরোধ একটি বৈধ লোড থেকে আলাদা করা যাবে না।
আমরা সার্ভারে খুলি এমন অনেক সংযোগও প্রাসঙ্গিক থাকে। পূর্বে, Apache এর জন্য দোষী ছিল, এখন nginx আসলে এর জন্য দোষী, যেহেতু এটি প্রায়শই ডিফল্টরূপে কনফিগার করা হয়। nginx খোলা রাখতে পারে এমন সংযোগের সংখ্যা সীমিত, তাই আমরা এই সংখ্যক সংযোগ খুলি, nginx আর একটি নতুন সংযোগ গ্রহণ করে না, এবং ফলস্বরূপ সাইটটি কাজ করে না।
আমাদের পরীক্ষার ক্লাস্টারে SSL হ্যান্ডশেক আক্রমণ করার জন্য পর্যাপ্ত CPU আছে। নীতিগতভাবে, অনুশীলন দেখায়, বটনেট কখনও কখনও এটি করতেও পছন্দ করে। একদিকে, এটা স্পষ্ট যে আপনি SSL ছাড়া করতে পারবেন না, কারণ Google ফলাফল, র‌্যাঙ্কিং, নিরাপত্তা। অন্যদিকে, দুর্ভাগ্যবশত SSL এর একটি CPU সমস্যা আছে।

এল৩ ও ৪

যখন আমরা L3 এবং 4 স্তরে আক্রমণের কথা বলি, তখন আমরা সাধারণত লিঙ্ক স্তরে আক্রমণের কথা বলি। এই ধরনের লোড প্রায় সবসময় একটি বৈধ থেকে আলাদা করা যায়, যদি না এটি একটি SYN-বন্যা আক্রমণ হয়। নিরাপত্তা সরঞ্জামের জন্য SYN-বন্যা আক্রমণের সমস্যা হল তাদের বড় আয়তন। সর্বোচ্চ L3 এবং 4 মান ছিল 1,5-2 Tbit/s। ওরাকল এবং গুগল সহ বড় কোম্পানিগুলির জন্যও এই ধরণের ট্র্যাফিক প্রক্রিয়া করা খুব কঠিন।
SYN এবং SYN-ACK হল প্যাকেট যা সংযোগ স্থাপন করার সময় ব্যবহৃত হয়। অতএব, SYN-বন্যাকে একটি বৈধ লোড থেকে আলাদা করা কঠিন: এটি একটি SYN যা সংযোগ স্থাপন করতে এসেছিল, নাকি বন্যার অংশ।

UDP-বন্যা

সাধারণত, আক্রমণকারীদের আমাদের ক্ষমতা নেই, তাই আক্রমণ সংগঠিত করতে পরিবর্ধন ব্যবহার করা যেতে পারে। অর্থাৎ, আক্রমণকারী ইন্টারনেট স্ক্যান করে এবং হয় দুর্বল বা ভুলভাবে কনফিগার করা সার্ভারগুলি খুঁজে পায় যেগুলি, উদাহরণস্বরূপ, একটি SYN প্যাকেটের প্রতিক্রিয়া হিসাবে, তিনটি SYN-ACK এর সাথে প্রতিক্রিয়া জানায়৷ টার্গেট সার্ভারের ঠিকানা থেকে উৎস ঠিকানা স্পুফ করার মাধ্যমে, একটি একক প্যাকেটের সাহায্যে তিনবার শক্তি বৃদ্ধি করা এবং শিকারের কাছে ট্রাফিক পুনঃনির্দেশ করা সম্ভব।

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

কঠিন SYN-বন্যা

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

যন্ত্র

L7 কাজের চাপের জন্য আমরা যে প্রধান সরঞ্জামগুলি ব্যবহার করি তার মধ্যে একটি হল ইয়ানডেক্স-ট্যাঙ্ক৷ বিশেষ করে, একটি ফ্যান্টম একটি বন্দুক হিসাবে ব্যবহৃত হয়, এছাড়াও কার্তুজ তৈরি করার জন্য এবং ফলাফল বিশ্লেষণের জন্য বেশ কয়েকটি স্ক্রিপ্ট রয়েছে।
Tcpdump নেটওয়ার্ক ট্র্যাফিক বিশ্লেষণ করতে ব্যবহৃত হয়, এবং Nmap সার্ভার বিশ্লেষণ করতে ব্যবহৃত হয়। L3 এবং 4 স্তরে লোড তৈরি করতে, OpenSSL এবং DPDK লাইব্রেরির সাথে আমাদের নিজস্ব কিছু জাদু ব্যবহার করা হয়। DPDK হল ইন্টেলের একটি লাইব্রেরি যা আপনাকে লিনাক্স স্ট্যাককে বাইপাস করে নেটওয়ার্ক ইন্টারফেসের সাথে কাজ করতে দেয়, যার ফলে দক্ষতা বৃদ্ধি পায়। স্বাভাবিকভাবেই, আমরা DPDK শুধুমাত্র L3 এবং 4 স্তরেই ব্যবহার করি না, L7 স্তরেও ব্যবহার করি, কারণ এটি আমাদের একটি মেশিন থেকে প্রতি সেকেন্ডে কয়েক মিলিয়ন অনুরোধের পরিসরের মধ্যে একটি খুব উচ্চ লোড প্রবাহ তৈরি করতে দেয়।
আমরা নির্দিষ্ট ট্রাফিক জেনারেটর এবং বিশেষ সরঞ্জামগুলিও ব্যবহার করি যা আমরা নির্দিষ্ট পরীক্ষার জন্য লিখি। যদি আমরা SSH-এর অধীনে দুর্বলতার কথা স্মরণ করি, তাহলে উপরের সেটটি কাজে লাগানো যাবে না। আমরা যদি মেল প্রোটোকল আক্রমণ করি, আমরা মেল ইউটিলিটিগুলি গ্রহণ করি বা কেবল তাদের উপর স্ক্রিপ্ট লিখি।

তথ্যও

উপসংহার হিসাবে আমি বলতে চাই:

• ক্লাসিক লোড টেস্টিং ছাড়াও, স্ট্রেস টেস্টিং করা প্রয়োজন। আমাদের কাছে একটি বাস্তব উদাহরণ রয়েছে যেখানে একজন অংশীদারের উপ-কন্ট্রাক্টর শুধুমাত্র লোড পরীক্ষা করে। এটি দেখিয়েছে যে সম্পদ স্বাভাবিক লোড সহ্য করতে পারে। কিন্তু তারপরে একটি অস্বাভাবিক লোড উপস্থিত হয়েছিল, সাইটের দর্শকরা রিসোর্সটিকে একটু ভিন্নভাবে ব্যবহার করতে শুরু করে এবং ফলস্বরূপ উপ-কন্ট্রাক্টর শুয়ে পড়ে। সুতরাং, আপনি ইতিমধ্যে DDoS আক্রমণ থেকে সুরক্ষিত থাকলেও দুর্বলতাগুলি সন্ধান করা মূল্যবান৷
• সিস্টেমের কিছু অংশ অন্যদের থেকে বিচ্ছিন্ন করা প্রয়োজন। আপনার যদি অনুসন্ধান থাকে তবে আপনাকে এটিকে আলাদা মেশিনে স্থানান্তর করতে হবে, অর্থাৎ ডকারেও নয়। কারণ অনুসন্ধান বা অনুমোদন ব্যর্থ হলে, অন্তত কিছু কাজ চলতে থাকবে। একটি অনলাইন স্টোরের ক্ষেত্রে, ব্যবহারকারীরা ক্যাটালগে পণ্যগুলি খুঁজে পেতে থাকবেন, অ্যাগ্রিগেটর থেকে যাবেন, তারা ইতিমধ্যে অনুমোদিত হলে কিনবেন বা OAuth2 এর মাধ্যমে অনুমোদন করবেন৷
• সব ধরনের ক্লাউড সার্ভিসে অবহেলা করবেন না।
• CDN ব্যবহার করুন কেবল নেটওয়ার্ক বিলম্বকে অপ্টিমাইজ করতে নয়, চ্যানেলের ক্লান্তি এবং স্থির ট্র্যাফিকের বন্যার বিরুদ্ধে আক্রমণ থেকে সুরক্ষার উপায় হিসাবেও।
• বিশেষ সুরক্ষা পরিষেবাগুলি ব্যবহার করা প্রয়োজন। আপনি চ্যানেল স্তরে L3 এবং 4 আক্রমণ থেকে নিজেকে রক্ষা করতে পারবেন না, কারণ সম্ভবত আপনার কাছে পর্যাপ্ত চ্যানেল নেই। আপনি L7 আক্রমণের বিরুদ্ধে লড়াই করার সম্ভাবনাও কম, কারণ সেগুলি খুব বড় হতে পারে। এছাড়াও, ছোট আক্রমণের অনুসন্ধান এখনও বিশেষ পরিষেবা, বিশেষ অ্যালগরিদমের অধিকার।
• নিয়মিত আপডেট করুন। এটি শুধুমাত্র কার্নেলের ক্ষেত্রেই নয়, SSH ডেমনের ক্ষেত্রেও প্রযোজ্য, বিশেষ করে যদি সেগুলি বাইরের দিকে খোলা থাকে। নীতিগতভাবে, সবকিছু আপডেট করা দরকার, কারণ আপনি নিজেরাই কিছু দুর্বলতা ট্র্যাক করতে সক্ষম হওয়ার সম্ভাবনা কম।

উত্স: www.habr.com