మెషిన్పై దాడులు: మేము ఏమి చేస్తాము మరియు మీరు ఏమి చేయగలరు
ఛానెల్పై మరియు యాప్లికేషన్పై దాడి ఎలా ఉంటుంది, అవి ఎలా భిన్నంగా ఉంటాయి, మీ వైపు ఏమి కాన్ఫిగర్ చేయవచ్చు మరియు ఇది దాడి కాదని ఎలా గుర్తించాలి.
23 ఆగస్టు, 2026న నవీకరించబడింది
“అటాక్” అనే పదం రెండు పూర్తిగా భిన్నమైన సందర్భాలలో ఒకేలా వినిపిస్తుంది: మీ ఛానెల్లో చెత్త ట్రాఫిక్ నిండిపోయినప్పుడు మరియు సెకనుకు కొన్ని వందల రిక్వెస్ట్లు మీ అప్లికేషన్ను డౌన్ చేసినప్పుడు. వీటిని వేర్వేరుగా పరిగణిస్తారు, మరియు మొదట చేయవలసిన పని మీరు ఏది ఎదుర్కొంటున్నారో గుర్తించడం.
ఒకదానిని మరొకదాని నుండి వేరు చేయడం
| సంకేతం | ఛానెల్ సంతృప్తం | అప్లికేషన్ ఓవర్లోడ్ |
|---|---|---|
| “Overview”లో ట్రాఫిక్ గ్రాఫ్ | పరిమితిని తాకుతోంది | సాధారణ విలువలు |
| ప్రాసెసర్ | లోడ్ కాలేదు | పూర్తిగా లోడ్ అయింది |
| SSH | కనెక్ట్ అవ్వదు | పనిచేస్తుంది, కానీ నెమ్మదిగా |
| వెబ్ సర్వర్ లాగ్లు | ఖాళీగా | వేలాది ఒకేలాంటి రిక్వెస్ట్లు |
గత 24 గంటల /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విలువలను ట్యూన్ చేయలేరు: మీరు కాన్ఫిగ్ను చీకటిలో, ముక్కలు ముక్కలుగా ఎడిట్ చేస్తుంటారు.