মেশিনে আক্রমণ: আমরা কী করি ও আপনি কী করতে পারেন
চ্যানেল ও অ্যাপ্লিকেশনে আক্রমণ কেমন দেখায়, এরা কীভাবে আলাদা, আপনার পক্ষে কী কনফিগার করা যায় এবং কীভাবে বুঝবেন এটি আদৌ আক্রমণ নয়।
আপডেট: ২৩ আগস্ট, ২০২৬
“অ্যাটাক” শব্দটি দুটি সম্পূর্ণ ভিন্ন পরিস্থিতিতে একই রকম শোনায়: যখন আপনার চ্যানেল জাঙ্ক ট্রাফিকে ভরে যায় এবং যখন প্রতি সেকেন্ডে কয়েকশো রিকোয়েস্ট আপনার অ্যাপ্লিকেশনকে ডাউন করে দেয়। এদের ভিন্নভাবে দেখা হয়, এবং প্রথম কাজ হলো আপনি কোনটির মুখোমুখি হয়েছেন তা নির্ধারণ করা।
একটির থেকে অন্যটি আলাদা করা
| লক্ষণ | চ্যানেল স্যাচুরেটেড | অ্যাপ্লিকেশন ওভারলোডেড |
|---|---|---|
| “Overview”-তে ট্রাফিক গ্রাফ | সিলিংয়ে পৌঁছাচ্ছে | স্বাভাবিক মান |
| প্রসেসর | লোড হয়নি | সম্পূর্ণ লোডেড |
| SSH | সংযোগ হবে না | কাজ করে, তবে ধীরে |
| ওয়েব সার্ভার লগ | খালি | হাজার হাজার অভিন্ন রিকোয়েস্ট |
গত ২৪ ঘণ্টার জন্য /hosting/vds/m/<id>-এ “Overview”-তে প্রসেসর, মেমরি এবং ট্রাফিক গ্রাফ দেখুন। যদি ট্রাফিক স্বাভাবিক থাকে কিন্তু প্রসেসর সিলিংয়ে আটকে থাকে, তাহলে এটি অ্যাপ্লিকেশন লোড, এবং আপনাকে আপনার দিক থেকে এটি মোকাবেলা করতে হবে।
আপনি যা করতে পারেন
nginx-এ রিকোয়েস্ট রেট লিমিটিং:
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;
server {
limit_req zone=perip burst=20 nodelay;
limit_conn conn 20;
client_body_timeout 10s;
client_header_timeout 10s;
}
ফায়ারওয়ালে সংযোগ সীমিত করা:
ufw limit 22/tcp
আরও নমনীয় নিয়ম nftables নিবন্ধে রয়েছে: সেখানে আপনি নতুন সংযোগও রেট-লিমিট করতে পারেন এবং একটি টাইম টু লাইভসহ ব্লক করা ঠিকানার তালিকা রাখতে পারেন।
লগে সোর্স খুঁজুন:
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head
একবারে একটি ঠিকানা বা নেটওয়ার্ক ব্লক করা:
ufw deny from 203.0.113.0/24
fail2ban লগের ভিত্তিতে ব্লকিং স্বয়ংক্রিয় করতে পারে।
আমরা যা করি
আমাদের ইনফ্রাস্ট্রাকচার নোডের দিকে যাওয়ার পথে জাঙ্ক ট্রাফিক ফিল্টার করে — এটি আপনার ব্যান্ডউইথ ব্যবহার করার আগেই। এটি চ্যানেলে ভলিউমেট্রিক অ্যাটাকের বিরুদ্ধে কাজ করে এবং আপনার দিক থেকে কোনো কনফিগারেশনের প্রয়োজন নেই।
নোড-লেভেল সুরক্ষা যা করে না: এটি আপনার অ্যাপ্লিকেশনের লজিক বিশ্লেষণ করে না। বাইরে থেকে স্বাভাবিক দেখায় এমন রিকোয়েস্ট আপনার মেশিনে পৌঁছায়, এবং শুধুমাত্র আপনার নিজের কনফিগারেশনই সেগুলোর বিরুদ্ধে সুরক্ষা দেয়।
যদি আপনার মেশিন নিজেই অ্যাটাকের উৎস হয়ে ওঠে — উদাহরণস্বরূপ, এটি কম্প্রোমাইজ হয়েছে এবং অন্য কারও স্প্যাম ক্যাম্পেইনে অংশ নিচ্ছে — তাহলে গ্রহণযোগ্য ব্যবহার নীতি অনুযায়ী অ্যাক্সেস সীমিত করা হবে। কম্প্রোমাইজের লক্ষণ অনুযায়ী আপনার মেশিন পরীক্ষা করুন।
ক্যাশিং এবং স্ট্যাটিক ফাইল
রিকোয়েস্টের বন্যার বিরুদ্ধে সবচেয়ে কার্যকর কৌশল হলো একই জিনিস দুবার গণনা না করা:
location /static/ {
expires 30d;
add_header Cache-Control "public";
}
অ্যাপ্লিকেশনের দিকে ভারী পেজ ক্যাশ করুন। ক্যাশ থেকে পরিবেশিত একটি রিকোয়েস্ট শতগুণ কম খরচ করে।
সাধারণ ভুল
burstছাড়াlimit_reqসেট করা — সাধারণ ব্যবহারকারীরা, যাদের পেজ দুই ডজন ফাইল টানে, কেটে ফেলা হয়।- ডিস্ট্রিবিউটেড অ্যাটাকের সময় হাতে একে একে ঠিকানা ব্লক করা: সেগুলো হাজার হাজার, এবং আপনি তাল মিলিয়ে চলতে পারবেন না।
- সম্পূর্ণভাবে ICMP ব্লক করা — এটি প্যাকেট সাইজ নেগোশিয়েশন ভেঙে দেয়, দেখুন MTU।
- নিজের বাগকে অ্যাটাক ভাবা: কোডে একটি লুপ, একটি সার্চ বট এমন একটি ডিরেক্টরি ক্রল করছে যা আপনি বাদ দিতে ভুলে গেছেন, ক্লায়েন্টের অন্তহীন রিট্রাই।
আগে থেকেই, একটি শান্ত মেশিনে আপনার লিমিট সেট করুন। রিকোয়েস্টের বন্যার সময় আপনি
rateএবংburstমান টিউন করতে পারবেন না: আপনি অন্ধভাবে এবং টুকরো টুকরো করে কনফিগ এডিট করবেন।