രക്ഷാപ്രവർത്തനത്തിന് DDoS: ഞങ്ങൾ എങ്ങനെയാണ് സമ്മർദ്ദവും ലോഡ് ടെസ്റ്റുകളും നടത്തുന്നത്

വാരിതി ബോട്ടുകൾക്കും DDoS ആക്രമണങ്ങൾക്കും എതിരായ സംരക്ഷണം വികസിപ്പിക്കുന്നു, കൂടാതെ സമ്മർദ്ദവും ലോഡ് പരിശോധനയും നടത്തുന്നു. HighLoad++ 2018 കോൺഫറൻസിൽ വിവിധ തരത്തിലുള്ള ആക്രമണങ്ങളിൽ നിന്ന് വിഭവങ്ങൾ എങ്ങനെ സുരക്ഷിതമാക്കാം എന്നതിനെക്കുറിച്ച് ഞങ്ങൾ സംസാരിച്ചു. ചുരുക്കത്തിൽ: സിസ്റ്റത്തിന്റെ ഭാഗങ്ങൾ ഒറ്റപ്പെടുത്തുക, ക്ലൗഡ് സേവനങ്ങളും CDN-കളും ഉപയോഗിക്കുക, പതിവായി അപ്ഡേറ്റ് ചെയ്യുക. എന്നാൽ പ്രത്യേക കമ്പനികളില്ലാതെ നിങ്ങൾക്ക് ഇപ്പോഴും സംരക്ഷണം കൈകാര്യം ചെയ്യാൻ കഴിയില്ല :)

വാചകം വായിക്കുന്നതിന് മുമ്പ്, നിങ്ങൾക്ക് ഹ്രസ്വ സംഗ്രഹങ്ങൾ വായിക്കാം കോൺഫറൻസ് വെബ്സൈറ്റിൽ.
നിങ്ങൾക്ക് വീഡിയോ വായിക്കാനോ കാണാനോ താൽപ്പര്യമില്ലെങ്കിൽ, ഞങ്ങളുടെ റിപ്പോർട്ടിന്റെ റെക്കോർഡിംഗ് സ്‌പോയിലറിന് താഴെയുണ്ട്.

റിപ്പോർട്ടിന്റെ വീഡിയോ റെക്കോർഡിംഗ്

ലോഡ് ടെസ്റ്റിംഗ് എങ്ങനെ ചെയ്യണമെന്ന് പല കമ്പനികൾക്കും ഇതിനകം അറിയാം, എന്നാൽ എല്ലാവരും സ്ട്രെസ് ടെസ്റ്റിംഗ് നടത്തുന്നില്ല. ഞങ്ങളുടെ ചില ഉപഭോക്താക്കൾക്ക് ഹൈലോഡ് സിസ്റ്റം ഉള്ളതിനാൽ അവരുടെ സൈറ്റ് അഭേദ്യമാണെന്ന് കരുതുന്നു, മാത്രമല്ല ഇത് ആക്രമണങ്ങളിൽ നിന്ന് നന്നായി സംരക്ഷിക്കുകയും ചെയ്യുന്നു. ഇത് പൂർണ്ണമായും ശരിയല്ലെന്ന് ഞങ്ങൾ കാണിക്കുന്നു.
തീർച്ചയായും, പരിശോധനകൾ നടത്തുന്നതിന് മുമ്പ്, ഞങ്ങൾ ഉപഭോക്താവിൽ നിന്ന് അനുമതി നേടുകയും ഒപ്പിടുകയും സ്റ്റാമ്പ് ചെയ്യുകയും ചെയ്യുന്നു, ഞങ്ങളുടെ സഹായത്തോടെ ആർക്കും ഒരു DDoS ആക്രമണം നടത്താൻ കഴിയില്ല. ഉപഭോക്താവ് തിരഞ്ഞെടുക്കുന്ന സമയത്താണ് പരിശോധന നടത്തുന്നത്, അവന്റെ റിസോഴ്സിലേക്കുള്ള ട്രാഫിക് വളരെ കുറവായിരിക്കും, കൂടാതെ ആക്സസ് പ്രശ്നങ്ങൾ ക്ലയന്റുകളെ ബാധിക്കില്ല. കൂടാതെ, ടെസ്റ്റിംഗ് പ്രക്രിയയിൽ എപ്പോഴും എന്തെങ്കിലും തെറ്റ് സംഭവിക്കാം എന്നതിനാൽ, ഞങ്ങൾക്ക് ഉപഭോക്താവുമായി നിരന്തരം സമ്പർക്കമുണ്ട്. നേടിയ ഫലങ്ങൾ റിപ്പോർട്ടുചെയ്യാൻ മാത്രമല്ല, പരിശോധനയ്ക്കിടെ എന്തെങ്കിലും മാറ്റാനും ഇത് നിങ്ങളെ അനുവദിക്കുന്നു. പരിശോധന പൂർത്തിയാകുമ്പോൾ, ഞങ്ങൾ എല്ലായ്പ്പോഴും ഒരു റിപ്പോർട്ട് തയ്യാറാക്കുന്നു, അതിൽ കണ്ടെത്തിയ പോരായ്മകൾ ചൂണ്ടിക്കാണിക്കുകയും സൈറ്റിന്റെ ബലഹീനതകൾ ഇല്ലാതാക്കുന്നതിനുള്ള ശുപാർശകൾ നൽകുകയും ചെയ്യുന്നു.

ഞങ്ങൾ എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത്

പരീക്ഷിക്കുമ്പോൾ, ഞങ്ങൾ ഒരു ബോട്ട്നെറ്റ് അനുകരിക്കുന്നു. ഞങ്ങളുടെ നെറ്റ്‌വർക്കുകളിൽ സ്ഥിതിചെയ്യാത്ത ക്ലയന്റുകളുമായി ഞങ്ങൾ പ്രവർത്തിക്കുന്നതിനാൽ, പരിമിതികളോ പരിരക്ഷയോ പ്രവർത്തനക്ഷമമാക്കുന്നതിനാൽ ടെസ്റ്റ് ആദ്യ മിനിറ്റിൽ അവസാനിക്കുന്നില്ലെന്ന് ഉറപ്പാക്കാൻ, ഞങ്ങൾ ലോഡ് നൽകുന്നത് ഒരു ഐപിയിൽ നിന്നല്ല, മറിച്ച് ഞങ്ങളുടെ സ്വന്തം സബ്‌നെറ്റിൽ നിന്നാണ്. കൂടാതെ, ഒരു കാര്യമായ ലോഡ് സൃഷ്ടിക്കുന്നതിന്, ഞങ്ങൾക്ക് സ്വന്തമായി ശക്തമായ ടെസ്റ്റ് സെർവർ ഉണ്ട്.

പോസ്റ്റുലേറ്റുകൾ

അമിതമായാൽ നല്ലത് എന്നല്ല അർത്ഥമാക്കുന്നത്
ഒരു വിഭവത്തെ പരാജയത്തിലേക്ക് കൊണ്ടുവരാൻ നമുക്ക് എത്രത്തോളം ലോഡ് ചെയ്യാൻ കഴിയും, അത്രയും നല്ലത്. സെക്കൻഡിൽ ഒരു അഭ്യർത്ഥനയിലോ മിനിറ്റിൽ ഒരു അഭ്യർത്ഥനയിലോ സൈറ്റിന്റെ പ്രവർത്തനം നിർത്താൻ നിങ്ങൾക്ക് കഴിയുമെങ്കിൽ, അത് വളരെ മികച്ചതാണ്. കാരണം, നീചതയുടെ നിയമമനുസരിച്ച്, ഉപയോക്താക്കളോ ആക്രമണകാരികളോ ആകസ്മികമായി ഈ പ്രത്യേക ദുർബലതയിലേക്ക് വീഴും.

പൂർണ്ണ പരാജയത്തേക്കാൾ ഭാഗിക പരാജയമാണ് നല്ലത്
സിസ്റ്റങ്ങളെ വൈവിധ്യപൂർണ്ണമാക്കാൻ ഞങ്ങൾ എപ്പോഴും ഉപദേശിക്കുന്നു. മാത്രമല്ല, അവയെ ഭൗതിക തലത്തിൽ വേർതിരിക്കുന്നത് മൂല്യവത്താണ്, അല്ലാതെ കണ്ടെയ്നറൈസേഷൻ വഴി മാത്രമല്ല. ശാരീരിക വേർതിരിവിന്റെ കാര്യത്തിൽ, സൈറ്റിൽ എന്തെങ്കിലും പരാജയപ്പെടുകയാണെങ്കിൽപ്പോലും, അത് പൂർണ്ണമായി പ്രവർത്തിക്കാതിരിക്കാനുള്ള ഉയർന്ന സംഭാവ്യതയുണ്ട്, കൂടാതെ ഉപയോക്താക്കൾക്ക് പ്രവർത്തനത്തിന്റെ ഒരു ഭാഗമെങ്കിലും ആക്സസ് ഉണ്ടായിരിക്കും.

നല്ല വാസ്തുവിദ്യയാണ് സുസ്ഥിരതയുടെ അടിസ്ഥാനം
ഒരു റിസോഴ്സിന്റെ തെറ്റ് സഹിഷ്ണുതയും ആക്രമണങ്ങളെയും ലോഡുകളെയും നേരിടാനുള്ള അതിന്റെ കഴിവ് ഡിസൈൻ ഘട്ടത്തിൽ, വാസ്തവത്തിൽ, ഒരു നോട്ട്പാഡിൽ ആദ്യത്തെ ഫ്ലോചാർട്ടുകൾ വരയ്ക്കുന്ന ഘട്ടത്തിൽ സ്ഥാപിക്കണം. കാരണം, മാരകമായ പിശകുകൾ ഇഴയുകയാണെങ്കിൽ, ഭാവിയിൽ അവ ശരിയാക്കാൻ കഴിയും, പക്ഷേ അത് വളരെ ബുദ്ധിമുട്ടാണ്.

കോഡ് മാത്രമല്ല, കോൺഫിഗറേഷനും മികച്ചതായിരിക്കണം
ഒരു നല്ല വികസന സംഘം തെറ്റ് സഹിഷ്ണുതയുള്ള സേവനത്തിന്റെ ഗ്യാരണ്ടിയാണെന്ന് പലരും കരുതുന്നു. ഒരു നല്ല വികസന ടീം ശരിക്കും ആവശ്യമാണ്, എന്നാൽ നല്ല പ്രവർത്തനങ്ങളും നല്ല DevOps ഉണ്ടായിരിക്കണം. അതായത്, ലിനക്സും നെറ്റ്‌വർക്കും ശരിയായി കോൺഫിഗർ ചെയ്യുന്ന, nginx-ൽ കോൺഫിഗറുകൾ ശരിയായി എഴുതുന്ന, പരിധികൾ സജ്ജമാക്കുന്ന സ്പെഷ്യലിസ്റ്റുകൾ ഞങ്ങൾക്ക് ആവശ്യമാണ്. അല്ലെങ്കിൽ, റിസോഴ്സ് പരിശോധനയിൽ മാത്രം നന്നായി പ്രവർത്തിക്കും, ചില ഘട്ടങ്ങളിൽ എല്ലാം ഉൽപ്പാദനത്തിൽ തകരും.

ലോഡും സമ്മർദ്ദ പരിശോധനയും തമ്മിലുള്ള വ്യത്യാസങ്ങൾ
സിസ്റ്റം പ്രവർത്തനത്തിന്റെ പരിധികൾ തിരിച്ചറിയാൻ ലോഡ് ടെസ്റ്റിംഗ് നിങ്ങളെ അനുവദിക്കുന്നു. സ്ട്രെസ് ടെസ്റ്റിംഗ് ഒരു സിസ്റ്റത്തിലെ ബലഹീനതകൾ കണ്ടെത്തുന്നതിന് ലക്ഷ്യമിടുന്നു, ഈ സിസ്റ്റം തകർക്കാനും ചില ഭാഗങ്ങളുടെ പരാജയ പ്രക്രിയയിൽ അത് എങ്ങനെ പ്രവർത്തിക്കുമെന്ന് കാണാനും ഉപയോഗിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, സ്ട്രെസ് ടെസ്റ്റിംഗ് ആരംഭിക്കുന്നതിന് മുമ്പ് ലോഡിന്റെ സ്വഭാവം സാധാരണയായി ഉപഭോക്താവിന് അജ്ഞാതമായിരിക്കും.

L7 ആക്രമണങ്ങളുടെ സവിശേഷ സവിശേഷതകൾ

ഞങ്ങൾ സാധാരണയായി ലോഡുകളുടെ തരങ്ങളെ L7, L3&4 ലെവലുകളിൽ ലോഡുകളായി വിഭജിക്കുന്നു. L7 എന്നത് ആപ്ലിക്കേഷൻ ലെവലിലുള്ള ഒരു ലോഡാണ്, മിക്കപ്പോഴും ഇത് അർത്ഥമാക്കുന്നത് HTTP മാത്രമാണ്, എന്നാൽ TCP പ്രോട്ടോക്കോൾ തലത്തിലുള്ള ഏത് ലോഡും ഞങ്ങൾ അർത്ഥമാക്കുന്നു.
L7 ആക്രമണങ്ങൾക്ക് ചില പ്രത്യേക സവിശേഷതകൾ ഉണ്ട്. ഒന്നാമതായി, അവർ നേരിട്ട് ആപ്ലിക്കേഷനിലേക്ക് വരുന്നു, അതായത്, നെറ്റ്വർക്ക് മാർഗങ്ങളിലൂടെ അവ പ്രതിഫലിപ്പിക്കാൻ സാധ്യതയില്ല. അത്തരം ആക്രമണങ്ങൾ യുക്തി ഉപയോഗിക്കുന്നു, ഇതുമൂലം, അവർ സിപിയു, മെമ്മറി, ഡിസ്ക്, ഡാറ്റാബേസ്, മറ്റ് വിഭവങ്ങൾ എന്നിവ വളരെ കാര്യക്ഷമമായും കുറച്ച് ട്രാഫിക്കിലും ഉപയോഗിക്കുന്നു.

HTTP വെള്ളപ്പൊക്കം

ഏതെങ്കിലും ആക്രമണത്തിന്റെ കാര്യത്തിൽ, കൈകാര്യം ചെയ്യുന്നതിനേക്കാൾ ലോഡ് സൃഷ്ടിക്കാൻ എളുപ്പമാണ്, കൂടാതെ L7 ന്റെ കാര്യത്തിലും ഇത് ശരിയാണ്. നിയമാനുസൃതമായ ട്രാഫിക്കിൽ നിന്ന് ആക്രമണ ട്രാഫിക്കിനെ വേർതിരിക്കുന്നത് എല്ലായ്പ്പോഴും എളുപ്പമല്ല, മിക്കപ്പോഴും ഇത് ആവൃത്തിയിലൂടെ ചെയ്യാൻ കഴിയും, എന്നാൽ എല്ലാം ശരിയായി ആസൂത്രണം ചെയ്തിട്ടുണ്ടെങ്കിൽ, ആക്രമണം എവിടെയാണെന്നും നിയമാനുസൃതമായ അഭ്യർത്ഥനകൾ എവിടെയാണെന്നും ലോഗുകളിൽ നിന്ന് മനസ്സിലാക്കാൻ കഴിയില്ല.
ആദ്യ ഉദാഹരണമായി, ഒരു HTTP വെള്ളപ്പൊക്ക ആക്രമണം പരിഗണിക്കുക. അത്തരം ആക്രമണങ്ങൾ സാധാരണയായി വളരെ ശക്തമാണെന്ന് ഗ്രാഫ് കാണിക്കുന്നു; ചുവടെയുള്ള ഉദാഹരണത്തിൽ, അഭ്യർത്ഥനകളുടെ പരമാവധി എണ്ണം മിനിറ്റിൽ 600 ആയിരം കവിഞ്ഞു.

ലോഡ് സൃഷ്ടിക്കാനുള്ള എളുപ്പവഴിയാണ് HTTP ഫ്ലഡ്. സാധാരണഗതിയിൽ, ഇത് ApacheBench പോലുള്ള ചില തരത്തിലുള്ള ലോഡ് ടെസ്റ്റിംഗ് ടൂൾ എടുക്കുകയും ഒരു അഭ്യർത്ഥനയും ലക്ഷ്യവും സജ്ജമാക്കുകയും ചെയ്യുന്നു. അത്തരമൊരു ലളിതമായ സമീപനത്തിലൂടെ, സെർവർ കാഷിംഗിലേക്ക് പ്രവർത്തിക്കാനുള്ള ഉയർന്ന സംഭാവ്യതയുണ്ട്, പക്ഷേ അത് മറികടക്കാൻ എളുപ്പമാണ്. ഉദാഹരണത്തിന്, അഭ്യർത്ഥനയിലേക്ക് ക്രമരഹിതമായ സ്ട്രിംഗുകൾ ചേർക്കുന്നത്, ഒരു പുതിയ പേജ് നിരന്തരം നൽകുന്നതിന് സെർവറിനെ പ്രേരിപ്പിക്കും.
കൂടാതെ, ഒരു ലോഡ് സൃഷ്ടിക്കുന്ന പ്രക്രിയയിൽ ഉപയോക്തൃ ഏജന്റിനെക്കുറിച്ച് മറക്കരുത്. ജനപ്രിയ ടെസ്റ്റിംഗ് ടൂളുകളുടെ പല ഉപയോക്തൃ ഏജന്റുമാരും സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാർ ഫിൽട്ടർ ചെയ്യുന്നു, ഈ സാഹചര്യത്തിൽ ലോഡ് ബാക്കെൻഡിൽ എത്തിയേക്കില്ല. ബ്രൗസറിൽ നിന്ന് കൂടുതലോ കുറവോ സാധുവായ തലക്കെട്ട് അഭ്യർത്ഥനയിലേക്ക് ചേർത്തുകൊണ്ട് നിങ്ങൾക്ക് ഫലം ഗണ്യമായി മെച്ചപ്പെടുത്താനാകും.
HTTP വെള്ളപ്പൊക്ക ആക്രമണങ്ങൾ പോലെ ലളിതമാണ്, അവയ്‌ക്കും അവയുടെ പോരായ്മകളുണ്ട്. ഒന്നാമതായി, ലോഡ് സൃഷ്ടിക്കാൻ വലിയ അളവിലുള്ള വൈദ്യുതി ആവശ്യമാണ്. രണ്ടാമതായി, അത്തരം ആക്രമണങ്ങൾ കണ്ടെത്തുന്നത് വളരെ എളുപ്പമാണ്, പ്രത്യേകിച്ചും അവ ഒരു വിലാസത്തിൽ നിന്നാണെങ്കിൽ. തൽഫലമായി, സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാർ അല്ലെങ്കിൽ ദാതാവിന്റെ തലത്തിൽ പോലും അഭ്യർത്ഥനകൾ ഉടനടി ഫിൽട്ടർ ചെയ്യാൻ തുടങ്ങുന്നു.

എന്താണ് അന്വേഷിക്കേണ്ടത്

കാര്യക്ഷമത നഷ്ടപ്പെടാതെ സെക്കൻഡിൽ അഭ്യർത്ഥനകളുടെ എണ്ണം കുറയ്ക്കുന്നതിന്, നിങ്ങൾ ഒരു ചെറിയ ഭാവന കാണിക്കുകയും സൈറ്റ് പര്യവേക്ഷണം ചെയ്യുകയും വേണം. അതിനാൽ, നിങ്ങൾക്ക് ചാനലോ സെർവറോ മാത്രമല്ല, ആപ്ലിക്കേഷന്റെ വ്യക്തിഗത ഭാഗങ്ങളും ലോഡ് ചെയ്യാൻ കഴിയും, ഉദാഹരണത്തിന്, ഡാറ്റാബേസുകൾ അല്ലെങ്കിൽ ഫയൽ സിസ്റ്റങ്ങൾ. വലിയ കണക്കുകൂട്ടലുകൾ നടത്തുന്ന സൈറ്റുകൾക്കായി നിങ്ങൾക്ക് തിരയാനും കഴിയും: കാൽക്കുലേറ്ററുകൾ, ഉൽപ്പന്ന തിരഞ്ഞെടുക്കൽ പേജുകൾ മുതലായവ. അവസാനമായി, സൈറ്റിന് ലക്ഷക്കണക്കിന് വരികളുടെ ഒരു പേജ് സൃഷ്ടിക്കുന്ന ഏതെങ്കിലും തരത്തിലുള്ള PHP സ്ക്രിപ്റ്റ് ഉണ്ടെന്ന് പലപ്പോഴും സംഭവിക്കാറുണ്ട്. അത്തരമൊരു സ്ക്രിപ്റ്റ് സെർവറിനെ ഗണ്യമായി ലോഡുചെയ്യുകയും ആക്രമണത്തിന് ഒരു ലക്ഷ്യമായി മാറുകയും ചെയ്യും.

എവിടെ നോക്കണം

പരിശോധനയ്‌ക്ക് മുമ്പ് ഞങ്ങൾ ഒരു ഉറവിടം സ്‌കാൻ ചെയ്യുമ്പോൾ, ഞങ്ങൾ ആദ്യം സൈറ്റ് തന്നെ നോക്കുന്നു. ഞങ്ങൾ എല്ലാത്തരം ഇൻപുട്ട് ഫീൽഡുകൾക്കും കനത്ത ഫയലുകൾക്കും വേണ്ടി തിരയുകയാണ് - പൊതുവേ, റിസോഴ്സിന് പ്രശ്നങ്ങൾ സൃഷ്ടിക്കാനും അതിന്റെ പ്രവർത്തനം മന്ദഗതിയിലാക്കാനും കഴിയുന്ന എല്ലാം. ഗൂഗിൾ ക്രോമിലെയും ഫയർഫോക്സിലെയും നിസാര വികസന ഉപകരണങ്ങൾ ഇവിടെ സഹായിക്കുന്നു, പേജ് പ്രതികരണ സമയം കാണിക്കുന്നു.
ഞങ്ങൾ ഉപഡൊമെയ്‌നുകളും സ്കാൻ ചെയ്യുന്നു. ഉദാഹരണത്തിന്, ഒരു നിശ്ചിത ഓൺലൈൻ സ്റ്റോർ ഉണ്ട്, abc.com, അതിന് admin.abc.com എന്ന സബ്ഡൊമെയ്ൻ ഉണ്ട്. മിക്കവാറും, ഇത് അംഗീകാരമുള്ള ഒരു അഡ്മിൻ പാനലാണ്, എന്നാൽ നിങ്ങൾ അതിൽ ഒരു ലോഡ് ഇടുകയാണെങ്കിൽ, അത് പ്രധാന ഉറവിടത്തിന് പ്രശ്നങ്ങൾ സൃഷ്ടിക്കും.
സൈറ്റിന് api.abc.com എന്ന ഉപഡൊമെയ്‌ൻ ഉണ്ടായിരിക്കാം. മിക്കവാറും, ഇത് മൊബൈൽ ആപ്ലിക്കേഷനുകൾക്കുള്ള ഒരു ഉറവിടമാണ്. ആപ്പ് സ്റ്റോറിലോ ഗൂഗിൾ പ്ലേയിലോ ആപ്ലിക്കേഷൻ കണ്ടെത്താം, ഒരു പ്രത്യേക ആക്സസ് പോയിന്റ് ഇൻസ്റ്റാൾ ചെയ്യുക, API വിഭജിച്ച് ടെസ്റ്റ് അക്കൗണ്ടുകൾ രജിസ്റ്റർ ചെയ്യുക. അംഗീകാരത്താൽ സംരക്ഷിക്കപ്പെടുന്ന എന്തും സേവന നിഷേധ ആക്രമണങ്ങളിൽ നിന്ന് മുക്തമാണെന്ന് ആളുകൾ പലപ്പോഴും ചിന്തിക്കുന്നു എന്നതാണ് പ്രശ്നം. അനുമാനിക്കപ്പെടുന്നു, അംഗീകാരമാണ് ഏറ്റവും മികച്ച CAPTCHA, പക്ഷേ അത് അങ്ങനെയല്ല. 10-20 ടെസ്റ്റ് അക്കൗണ്ടുകൾ നിർമ്മിക്കുന്നത് എളുപ്പമാണ്, എന്നാൽ അവ സൃഷ്ടിക്കുന്നതിലൂടെ, സങ്കീർണ്ണവും മറച്ചുവെക്കാത്തതുമായ പ്രവർത്തനത്തിലേക്ക് ഞങ്ങൾക്ക് പ്രവേശനം ലഭിക്കും.
സ്വാഭാവികമായും, ഞങ്ങൾ robots.txt, WebArchive, ViewDNS എന്നിവയിൽ ചരിത്രം നോക്കുകയും ഉറവിടത്തിന്റെ പഴയ പതിപ്പുകൾക്കായി നോക്കുകയും ചെയ്യുന്നു. ചിലപ്പോൾ അത് ഡവലപ്പർമാർ mail2.yandex.net പുറത്തിറക്കിയിട്ടുണ്ട്, പക്ഷേ പഴയ പതിപ്പായ mail.yandex.net അവശേഷിക്കുന്നു. ഈ mail.yandex.net ഇനി പിന്തുണയ്‌ക്കില്ല, വികസന ഉറവിടങ്ങൾ ഇതിന് അനുവദിച്ചിട്ടില്ല, പക്ഷേ ഇത് ഡാറ്റാബേസ് ഉപയോഗിക്കുന്നത് തുടരുന്നു. അതനുസരിച്ച്, പഴയ പതിപ്പ് ഉപയോഗിച്ച്, നിങ്ങൾക്ക് ബാക്കെൻഡിന്റെ ഉറവിടങ്ങളും ലേഔട്ടിന് പിന്നിലുള്ള എല്ലാ കാര്യങ്ങളും ഫലപ്രദമായി ഉപയോഗിക്കാൻ കഴിയും. തീർച്ചയായും, ഇത് എല്ലായ്പ്പോഴും സംഭവിക്കുന്നില്ല, പക്ഷേ ഞങ്ങൾ ഇപ്പോഴും ഇത് പലപ്പോഴും കണ്ടുമുട്ടുന്നു.
സ്വാഭാവികമായും, ഞങ്ങൾ എല്ലാ അഭ്യർത്ഥന പാരാമീറ്ററുകളും കുക്കി ഘടനയും വിശകലനം ചെയ്യുന്നു. നിങ്ങൾക്ക് ഒരു കുക്കിക്കുള്ളിൽ ഒരു JSON അറേയിലേക്ക് കുറച്ച് മൂല്യം ഇടുകയും ധാരാളം നെസ്റ്റിംഗ് സൃഷ്ടിക്കുകയും റിസോഴ്‌സ് യുക്തിരഹിതമായി ദീർഘനേരം പ്രവർത്തിക്കുകയും ചെയ്യാം.

തിരയൽ ലോഡ്

ഒരു സൈറ്റ് അന്വേഷിക്കുമ്പോൾ ആദ്യം മനസ്സിൽ വരുന്നത് ഡാറ്റാബേസ് ലോഡുചെയ്യുക എന്നതാണ്, കാരണം മിക്കവാറും എല്ലാവർക്കും ഒരു തിരയൽ ഉണ്ട്, മിക്കവാറും എല്ലാവർക്കും, നിർഭാഗ്യവശാൽ, ഇത് മോശമായി പരിരക്ഷിക്കപ്പെട്ടിരിക്കുന്നു. ചില കാരണങ്ങളാൽ, ഡെവലപ്പർമാർ തിരയുന്നതിന് വേണ്ടത്ര ശ്രദ്ധ നൽകുന്നില്ല. എന്നാൽ ഇവിടെ ഒരു ശുപാർശയുണ്ട് - നിങ്ങൾ ഒരേ തരത്തിലുള്ള അഭ്യർത്ഥനകൾ നടത്തരുത്, കാരണം HTTP വെള്ളപ്പൊക്കത്തിന്റെ കാര്യത്തിലെന്നപോലെ നിങ്ങൾക്ക് കാഷിംഗ് നേരിടാം.
ഡാറ്റാബേസിലേക്ക് ക്രമരഹിതമായ അന്വേഷണങ്ങൾ നടത്തുന്നത് എല്ലായ്പ്പോഴും ഫലപ്രദമല്ല. തിരയലിന് പ്രസക്തമായ കീവേഡുകളുടെ ഒരു ലിസ്റ്റ് സൃഷ്ടിക്കുന്നതാണ് നല്ലത്. ഞങ്ങൾ ഒരു ഓൺലൈൻ സ്റ്റോറിന്റെ ഉദാഹരണത്തിലേക്ക് മടങ്ങുകയാണെങ്കിൽ: സൈറ്റ് കാർ ടയറുകൾ വിൽക്കുകയും ടയറുകളുടെ ആരം, കാറിന്റെ തരം, മറ്റ് പാരാമീറ്ററുകൾ എന്നിവ സജ്ജമാക്കാൻ നിങ്ങളെ അനുവദിക്കുകയും ചെയ്യുന്നുവെന്ന് നമുക്ക് പറയാം. അതനുസരിച്ച്, പ്രസക്തമായ പദങ്ങളുടെ സംയോജനം കൂടുതൽ സങ്കീർണ്ണമായ സാഹചര്യങ്ങളിൽ പ്രവർത്തിക്കാൻ ഡാറ്റാബേസിനെ പ്രേരിപ്പിക്കും.
കൂടാതെ, പേജിനേഷൻ ഉപയോഗിക്കുന്നത് മൂല്യവത്താണ്: തിരയൽ ഫലങ്ങളുടെ അവസാന പേജ് ആദ്യത്തേതിനേക്കാൾ തിരികെ നൽകുന്നത് തിരയലിന് വളരെ ബുദ്ധിമുട്ടാണ്. അതായത്, പേജിനേഷന്റെ സഹായത്തോടെ നിങ്ങൾക്ക് ലോഡ് ചെറുതായി വൈവിധ്യവത്കരിക്കാനാകും.
ചുവടെയുള്ള ഉദാഹരണം തിരയൽ ലോഡ് കാണിക്കുന്നു. ഒരു സെക്കൻഡിൽ പത്ത് അഭ്യർത്ഥനകൾ എന്ന വേഗതയിൽ ടെസ്റ്റിന്റെ ആദ്യ സെക്കൻഡ് മുതൽ സൈറ്റ് ഡൌൺ ആയതും പ്രതികരിക്കാത്തതും കാണാൻ കഴിയും.

തിരച്ചിൽ ഇല്ലെങ്കിലോ?

തിരയൽ ഇല്ലെങ്കിൽ, സൈറ്റിൽ മറ്റ് ദുർബലമായ ഇൻപുട്ട് ഫീൽഡുകൾ അടങ്ങിയിട്ടില്ലെന്ന് ഇതിനർത്ഥമില്ല. ഈ ഫീൽഡ് അംഗീകാരമായിരിക്കാം. ഇക്കാലത്ത്, റെയിൻബോ ടേബിൾ ആക്രമണത്തിൽ നിന്ന് ലോഗിൻ ഡാറ്റാബേസിനെ സംരക്ഷിക്കാൻ സങ്കീർണ്ണമായ ഹാഷുകൾ നിർമ്മിക്കാൻ ഡെവലപ്പർമാർ ഇഷ്ടപ്പെടുന്നു. ഇത് നല്ലതാണ്, എന്നാൽ അത്തരം ഹാഷുകൾ ധാരാളം സിപിയു ഉറവിടങ്ങൾ ഉപയോഗിക്കുന്നു. തെറ്റായ അംഗീകാരങ്ങളുടെ ഒരു വലിയ ഒഴുക്ക് ഒരു പ്രോസസർ പരാജയത്തിലേക്ക് നയിക്കുന്നു, തൽഫലമായി, സൈറ്റ് പ്രവർത്തിക്കുന്നത് നിർത്തുന്നു.
അഭിപ്രായങ്ങൾക്കും ഫീഡ്‌ബാക്കിനുമായി എല്ലാത്തരം ഫോമുകളുടെയും സൈറ്റിലെ സാന്നിധ്യം വളരെ വലിയ ടെക്‌സ്റ്റുകൾ അവിടെ അയയ്‌ക്കാനോ ഒരു വലിയ വെള്ളപ്പൊക്കം സൃഷ്ടിക്കാനോ ഒരു കാരണമാണ്. ചിലപ്പോൾ സൈറ്റുകൾ gzip ഫോർമാറ്റിൽ ഉൾപ്പെടെ അറ്റാച്ച് ചെയ്ത ഫയലുകൾ സ്വീകരിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, ഞങ്ങൾ ഒരു 1TB ഫയൽ എടുത്ത് gzip ഉപയോഗിച്ച് നിരവധി ബൈറ്റുകളിലേക്കോ കിലോബൈറ്റുകളിലേക്കോ കംപ്രസ് ചെയ്ത് സൈറ്റിലേക്ക് അയയ്ക്കുന്നു. തുടർന്ന് അത് അൺസിപ്പ് ചെയ്യുകയും വളരെ രസകരമായ ഒരു പ്രഭാവം നേടുകയും ചെയ്യുന്നു.

ബാക്കിയുള്ള API

Rest API പോലുള്ള ജനപ്രിയ സേവനങ്ങളിൽ അൽപ്പം ശ്രദ്ധിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. ഒരു റെസ്റ്റ് API സുരക്ഷിതമാക്കുന്നത് ഒരു സാധാരണ വെബ്‌സൈറ്റിനേക്കാൾ വളരെ ബുദ്ധിമുട്ടാണ്. പാസ്‌വേഡ് ബ്രൂട്ട് ഫോഴ്‌സ്, മറ്റ് നിയമവിരുദ്ധ പ്രവർത്തനങ്ങൾ എന്നിവയ്‌ക്കെതിരായ സംരക്ഷണത്തിന്റെ നിസ്സാരമായ രീതികൾ പോലും റെസ്റ്റ് API-യിൽ പ്രവർത്തിക്കില്ല.
ഡാറ്റാബേസ് നേരിട്ട് ആക്സസ് ചെയ്യുന്നതിനാൽ റെസ്റ്റ് API തകർക്കാൻ വളരെ എളുപ്പമാണ്. അതേസമയം, അത്തരമൊരു സേവനത്തിന്റെ പരാജയം ബിസിനസ്സിന് ഗുരുതരമായ പ്രത്യാഘാതങ്ങൾ ഉണ്ടാക്കുന്നു. Rest API സാധാരണയായി പ്രധാന വെബ്‌സൈറ്റിന് മാത്രമല്ല, മൊബൈൽ ആപ്ലിക്കേഷനും ചില ആന്തരിക ബിസിനസ്സ് ഉറവിടങ്ങൾക്കും ഉപയോഗിക്കുന്നു എന്നതാണ് വസ്തുത. ഇതെല്ലാം വീണാൽ, ലളിതമായ ഒരു വെബ്‌സൈറ്റ് പരാജയത്തിന്റെ കാര്യത്തേക്കാൾ പ്രഭാവം വളരെ ശക്തമാണ്.

കനത്ത ഉള്ളടക്കം ലോഡ് ചെയ്യുന്നു

സങ്കീർണ്ണമായ പ്രവർത്തനക്ഷമതയില്ലാത്ത ചില സാധാരണ സിംഗിൾ-പേജ് ആപ്ലിക്കേഷൻ, ലാൻഡിംഗ് പേജ് അല്ലെങ്കിൽ ബിസിനസ് കാർഡ് വെബ്‌സൈറ്റ് പരീക്ഷിക്കാൻ ഞങ്ങൾ വാഗ്ദാനം ചെയ്താൽ, ഞങ്ങൾ കനത്ത ഉള്ളടക്കത്തിനായി നോക്കുന്നു. ഉദാഹരണത്തിന്, സെർവർ അയയ്ക്കുന്ന വലിയ ചിത്രങ്ങൾ, ബൈനറി ഫയലുകൾ, പിഡിഎഫ് ഡോക്യുമെന്റേഷൻ - ഇതെല്ലാം ഡൗൺലോഡ് ചെയ്യാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു. അത്തരം പരിശോധനകൾ ഫയൽ സിസ്റ്റത്തെ നന്നായി ലോഡ് ചെയ്യുകയും ചാനലുകൾ തടസ്സപ്പെടുത്തുകയും ചെയ്യുന്നു, അതിനാൽ ഫലപ്രദമാണ്. അതായത്, നിങ്ങൾ സെർവർ താഴെ വെച്ചില്ലെങ്കിലും, കുറഞ്ഞ വേഗതയിൽ ഒരു വലിയ ഫയൽ ഡൌൺലോഡ് ചെയ്യുകയാണെങ്കിൽ, നിങ്ങൾ ടാർഗെറ്റ് സെർവറിന്റെ ചാനൽ ക്ലോഗ് ചെയ്യും, തുടർന്ന് സേവന നിഷേധം സംഭവിക്കും.
അത്തരമൊരു പരിശോധനയുടെ ഒരു ഉദാഹരണം കാണിക്കുന്നത് 30 ആർപിഎസ് വേഗതയിൽ സൈറ്റ് പ്രതികരിക്കുന്നത് നിർത്തുകയോ 500-ാമത്തെ സെർവർ പിശകുകൾ സൃഷ്ടിക്കുകയോ ചെയ്തു.

സെർവറുകൾ സജ്ജീകരിക്കുന്നതിനെക്കുറിച്ച് മറക്കരുത്. ഒരു വ്യക്തി ഒരു വെർച്വൽ മെഷീൻ വാങ്ങി, അവിടെ അപ്പാച്ചെ ഇൻസ്റ്റാൾ ചെയ്തു, ഡിഫോൾട്ടായി എല്ലാം ക്രമീകരിച്ചു, ഒരു PHP ആപ്ലിക്കേഷൻ ഇൻസ്റ്റാൾ ചെയ്തു, ചുവടെ നിങ്ങൾക്ക് ഫലം കാണാൻ കഴിയും.

ഇവിടെ ലോഡ് റൂട്ടിലേക്ക് പോയി 10 RPS മാത്രമായിരുന്നു. ഞങ്ങൾ 5 മിനിറ്റ് കാത്തിരുന്നു, സെർവർ തകരാറിലായി. എന്തുകൊണ്ടാണ് അവൻ വീണതെന്ന് പൂർണ്ണമായി അറിയില്ല എന്നത് ശരിയാണ്, പക്ഷേ അദ്ദേഹത്തിന് വളരെയധികം ഓർമ്മയുണ്ടെന്നും അതിനാൽ പ്രതികരിക്കുന്നത് നിർത്തിയെന്നും ഒരു അനുമാനമുണ്ട്.

തരംഗത്തെ അടിസ്ഥാനമാക്കിയുള്ളത്

കഴിഞ്ഞ ഒന്നോ രണ്ടോ വർഷങ്ങളിൽ, തിരമാല ആക്രമണങ്ങൾ വളരെ ജനപ്രിയമായി. ആക്രമണം ഫിൽട്ടർ ചെയ്യാൻ ആരംഭിക്കുന്നതിന് സ്ഥിതിവിവരക്കണക്കുകൾ ശേഖരിക്കുന്നതിന് ഒരു നിശ്ചിത സമയം ആവശ്യമായി വരുന്ന DDoS സംരക്ഷണത്തിനായി പല ഓർഗനൈസേഷനുകളും ചില ഹാർഡ്‌വെയർ വാങ്ങുന്നു എന്നതാണ് ഇതിന് കാരണം. അതായത്, ആദ്യത്തെ 30-40 സെക്കൻഡിനുള്ളിൽ അവർ ആക്രമണം ഫിൽട്ടർ ചെയ്യില്ല, കാരണം അവർ ഡാറ്റ ശേഖരിക്കുകയും പഠിക്കുകയും ചെയ്യുന്നു. അതനുസരിച്ച്, ഈ 30-40 സെക്കൻഡിനുള്ളിൽ നിങ്ങൾക്ക് സൈറ്റിൽ വളരെയധികം സമാരംഭിക്കാൻ കഴിയും, എല്ലാ അഭ്യർത്ഥനകളും മായ്‌ക്കുന്നതുവരെ ഉറവിടം വളരെക്കാലം കിടക്കും.
താഴെയുള്ള ആക്രമണത്തിന്റെ കാര്യത്തിൽ, 10 മിനിറ്റ് ഇടവേള ഉണ്ടായിരുന്നു, അതിനുശേഷം ആക്രമണത്തിന്റെ പുതിയതും പരിഷ്കരിച്ചതുമായ ഒരു ഭാഗം എത്തി.

അതായത്, പ്രതിരോധം പഠിച്ചു, ഫിൽട്ടറിംഗ് ആരംഭിച്ചു, എന്നാൽ ആക്രമണത്തിന്റെ പുതിയ, തികച്ചും വ്യത്യസ്തമായ ഒരു ഭാഗം എത്തി, പ്രതിരോധം വീണ്ടും പഠിക്കാൻ തുടങ്ങി. വാസ്തവത്തിൽ, ഫിൽട്ടറിംഗ് പ്രവർത്തിക്കുന്നത് നിർത്തുന്നു, സംരക്ഷണം ഫലപ്രദമല്ല, സൈറ്റ് ലഭ്യമല്ല.
തരംഗ ആക്രമണങ്ങൾ ഏറ്റവും ഉയർന്ന മൂല്യങ്ങളാൽ സവിശേഷതയാണ്, ഇത് L7 ന്റെ കാര്യത്തിൽ സെക്കൻഡിൽ ഒരു ലക്ഷം അല്ലെങ്കിൽ ഒരു ദശലക്ഷം അഭ്യർത്ഥനകളിൽ എത്താം. നമ്മൾ L3 & 4 നെക്കുറിച്ച് സംസാരിക്കുകയാണെങ്കിൽ, നൂറുകണക്കിന് ഗിഗാബൈറ്റ് ട്രാഫിക് അല്ലെങ്കിൽ അതനുസരിച്ച്, നിങ്ങൾ പാക്കറ്റുകളിൽ കണക്കാക്കിയാൽ നൂറുകണക്കിന് mpps ഉണ്ടാകാം.
അത്തരം ആക്രമണങ്ങളുടെ പ്രശ്നം സമന്വയമാണ്. ആക്രമണങ്ങൾ ഒരു ബോട്ട്നെറ്റിൽ നിന്നാണ് വരുന്നത്, വളരെ വലിയ ഒറ്റത്തവണ സ്പൈക്ക് സൃഷ്ടിക്കുന്നതിന് ഉയർന്ന തോതിലുള്ള സിൻക്രൊണൈസേഷൻ ആവശ്യമാണ്. ഈ ഏകോപനം എല്ലായ്പ്പോഴും പ്രവർത്തിക്കില്ല: ചിലപ്പോൾ ഔട്ട്പുട്ട് ഒരുതരം പരാബോളിക് കൊടുമുടിയാണ്, അത് ദയനീയമായി തോന്നുന്നു.

HTTP മാത്രമല്ല

L7-ലെ HTTP കൂടാതെ, മറ്റ് പ്രോട്ടോക്കോളുകൾ പ്രയോജനപ്പെടുത്താൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ചട്ടം പോലെ, ഒരു സാധാരണ വെബ്‌സൈറ്റ്, പ്രത്യേകിച്ച് ഒരു സാധാരണ ഹോസ്റ്റിംഗ്, മെയിൽ പ്രോട്ടോക്കോളുകളും MySQL ഉം ഉണ്ട്. മെയിൽ പ്രോട്ടോക്കോളുകൾ ഡാറ്റാബേസുകളേക്കാൾ കുറഞ്ഞ ലോഡിന് വിധേയമാണ്, പക്ഷേ അവ വളരെ കാര്യക്ഷമമായി ലോഡുചെയ്യാനും സെർവറിൽ ഓവർലോഡ് ചെയ്ത സിപിയുവിൽ അവസാനിക്കാനും കഴിയും.
2016-ലെ SSH അപകടസാധ്യത ഉപയോഗിച്ച് ഞങ്ങൾ വിജയിച്ചു. ഇപ്പോൾ ഈ അപകടസാധ്യത മിക്കവാറും എല്ലാവർക്കും പരിഹരിച്ചിരിക്കുന്നു, എന്നാൽ SSH-ലേക്ക് ലോഡ് സമർപ്പിക്കാൻ കഴിയില്ലെന്ന് ഇതിനർത്ഥമില്ല. കഴിയും. അംഗീകാരങ്ങളുടെ ഒരു വലിയ ലോഡ് ഉണ്ട്, സെർവറിലെ മിക്കവാറും മുഴുവൻ സിപിയുവും SSH തിന്നുതീർക്കുന്നു, തുടർന്ന് സെക്കൻഡിൽ ഒന്നോ രണ്ടോ അഭ്യർത്ഥനകളിൽ നിന്ന് വെബ്‌സൈറ്റ് തകരുന്നു. അതനുസരിച്ച്, ലോഗുകളെ അടിസ്ഥാനമാക്കിയുള്ള ഈ ഒന്നോ രണ്ടോ അഭ്യർത്ഥനകൾ നിയമാനുസൃതമായ ലോഡിൽ നിന്ന് വേർതിരിച്ചറിയാൻ കഴിയില്ല.
സെർവറുകളിൽ ഞങ്ങൾ തുറക്കുന്ന പല കണക്ഷനുകളും പ്രസക്തമായി തുടരുന്നു. മുമ്പ്, അപ്പാച്ചെ ഇതിൽ കുറ്റക്കാരനായിരുന്നു, ഇപ്പോൾ nginx യഥാർത്ഥത്തിൽ ഇതിൽ കുറ്റക്കാരനാണ്, കാരണം ഇത് പലപ്പോഴും സ്ഥിരസ്ഥിതിയായി ക്രമീകരിച്ചിരിക്കുന്നു. nginx-ന് തുറന്ന് സൂക്ഷിക്കാൻ കഴിയുന്ന കണക്ഷനുകളുടെ എണ്ണം പരിമിതമാണ്, അതിനാൽ ഞങ്ങൾ ഈ കണക്ഷനുകൾ തുറക്കുന്നു, nginx ഇനി ഒരു പുതിയ കണക്ഷൻ സ്വീകരിക്കില്ല, അതിന്റെ ഫലമായി സൈറ്റ് പ്രവർത്തിക്കില്ല.
ഞങ്ങളുടെ ടെസ്റ്റ് ക്ലസ്റ്ററിന് SSL ഹാൻഡ്‌ഷേക്കിനെ ആക്രമിക്കാൻ ആവശ്യമായ സിപിയു ഉണ്ട്. തത്വത്തിൽ, പ്രാക്ടീസ് കാണിക്കുന്നതുപോലെ, ബോട്ട്നെറ്റുകൾ ചിലപ്പോൾ ഇത് ചെയ്യാൻ ഇഷ്ടപ്പെടുന്നു. ഒരു വശത്ത്, നിങ്ങൾക്ക് SSL ഇല്ലാതെ ചെയ്യാൻ കഴിയില്ലെന്ന് വ്യക്തമാണ്, കാരണം Google ഫലങ്ങൾ, റാങ്കിംഗ്, സുരക്ഷ. മറുവശത്ത്, SSL-ന് നിർഭാഗ്യവശാൽ ഒരു CPU പ്രശ്നമുണ്ട്.

L3&4

നമ്മൾ L3&4 ലെവലിൽ ഒരു ആക്രമണത്തെ കുറിച്ച് പറയുമ്പോൾ, നമ്മൾ സാധാരണയായി ലിങ്ക് തലത്തിലുള്ള ഒരു ആക്രമണത്തെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്. ഇത് ഒരു SYN-ഫ്ളഡ് ആക്രമണമല്ലെങ്കിൽ, അത്തരമൊരു ലോഡ് മിക്കവാറും എല്ലായ്‌പ്പോഴും നിയമാനുസൃതമായതിൽ നിന്ന് വേർതിരിച്ചറിയാൻ കഴിയും. സെക്യൂരിറ്റി ടൂളുകൾക്കായുള്ള SYN-ഫ്ളഡ് ആക്രമണങ്ങളുടെ പ്രശ്നം അവയുടെ വലിയ അളവാണ്. പരമാവധി L3&4 മൂല്യം 1,5-2 Tbit/s ആയിരുന്നു. ഒറാക്കിളും ഗൂഗിളും ഉൾപ്പെടെയുള്ള വലിയ കമ്പനികൾക്ക് പോലും ഇത്തരത്തിലുള്ള ട്രാഫിക് പ്രോസസ്സ് ചെയ്യുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്.
SYN, SYN-ACK എന്നിവ ഒരു കണക്ഷൻ സ്ഥാപിക്കുമ്പോൾ ഉപയോഗിക്കുന്ന പാക്കറ്റുകളാണ്. അതിനാൽ, SYN-ഫ്ളഡ് ഒരു നിയമാനുസൃത ലോഡിൽ നിന്ന് വേർതിരിച്ചറിയാൻ പ്രയാസമാണ്: ഇത് ഒരു കണക്ഷൻ സ്ഥാപിക്കാൻ വന്ന ഒരു SYN ആണോ അതോ വെള്ളപ്പൊക്കത്തിന്റെ ഭാഗമാണോ എന്ന് വ്യക്തമല്ല.

UDP- പ്രളയം

സാധാരണഗതിയിൽ, ആക്രമണകാരികൾക്ക് ഞങ്ങളുടെ പക്കലുള്ള കഴിവുകൾ ഇല്ല, അതിനാൽ ആക്രമണങ്ങൾ സംഘടിപ്പിക്കാൻ ആംപ്ലിഫിക്കേഷൻ ഉപയോഗിക്കാം. അതായത്, ആക്രമണകാരി ഇന്റർനെറ്റ് സ്കാൻ ചെയ്യുകയും ദുർബലമായതോ തെറ്റായി ക്രമീകരിച്ചതോ ആയ സെർവറുകൾ കണ്ടെത്തുന്നു, ഉദാഹരണത്തിന്, ഒരു SYN പാക്കറ്റിന് മറുപടിയായി, മൂന്ന് SYN-ACK-കൾ ഉപയോഗിച്ച് പ്രതികരിക്കുക. ടാർഗെറ്റ് സെർവറിന്റെ വിലാസത്തിൽ നിന്ന് ഉറവിട വിലാസം കബളിപ്പിക്കുന്നതിലൂടെ, ഒരൊറ്റ പാക്കറ്റ് ഉപയോഗിച്ച് മൂന്ന് തവണ വൈദ്യുതി വർദ്ധിപ്പിക്കാനും ഇരയിലേക്ക് ട്രാഫിക് റീഡയറക്‌ട് ചെയ്യാനും കഴിയും.

ആംപ്ലിഫിക്കേഷനുകളുടെ പ്രശ്നം അവ കണ്ടുപിടിക്കാൻ പ്രയാസമാണ് എന്നതാണ്. സമീപകാല ഉദാഹരണങ്ങളിൽ ദുർബലരായ മെംകാഷ്ഡ് സെൻസേഷണൽ കേസ് ഉൾപ്പെടുന്നു. കൂടാതെ, ഇപ്പോൾ ധാരാളം ഐഒടി ഉപകരണങ്ങൾ, ഐപി ക്യാമറകൾ ഉണ്ട്, അവ കൂടുതലും സ്ഥിരസ്ഥിതിയായി ക്രമീകരിച്ചിരിക്കുന്നു, സ്ഥിരസ്ഥിതിയായി അവ തെറ്റായി ക്രമീകരിച്ചിരിക്കുന്നു, അതിനാലാണ് ആക്രമണകാരികൾ മിക്കപ്പോഴും അത്തരം ഉപകരണങ്ങളിലൂടെ ആക്രമണങ്ങൾ നടത്തുന്നത്.

ബുദ്ധിമുട്ടുള്ള SYN-വെള്ളപ്പൊക്കം

ഒരു ഡെവലപ്പറുടെ വീക്ഷണകോണിൽ നിന്നുള്ള ഏറ്റവും രസകരമായ ആക്രമണമാണ് SYN-flood. സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാർ പലപ്പോഴും സംരക്ഷണത്തിനായി ഐപി തടയൽ ഉപയോഗിക്കുന്നു എന്നതാണ് പ്രശ്നം. കൂടാതെ, ഐപി തടയൽ സ്ക്രിപ്റ്റുകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്ന സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാരെ മാത്രമല്ല, നിർഭാഗ്യവശാൽ, ധാരാളം പണം നൽകി വാങ്ങുന്ന ചില സുരക്ഷാ സംവിധാനങ്ങളെയും ബാധിക്കുന്നു.
ഈ രീതി ഒരു ദുരന്തമായി മാറും, കാരണം ആക്രമണകാരികൾ ഐപി വിലാസങ്ങൾ മാറ്റിസ്ഥാപിക്കുകയാണെങ്കിൽ, കമ്പനി സ്വന്തം സബ്നെറ്റ് തടയും. ഫയർവാൾ സ്വന്തം ക്ലസ്റ്ററിനെ തടയുമ്പോൾ, ഔട്ട്പുട്ട് ബാഹ്യ ഇടപെടലുകളെ പരാജയപ്പെടുത്തുകയും റിസോഴ്സ് പരാജയപ്പെടുകയും ചെയ്യും.
മാത്രമല്ല, നിങ്ങളുടെ സ്വന്തം നെറ്റ്‌വർക്ക് തടയുന്നത് ബുദ്ധിമുട്ടുള്ള കാര്യമല്ല. ക്ലയന്റ് ഓഫീസിന് ഒരു Wi-Fi നെറ്റ്‌വർക്ക് ഉണ്ടെങ്കിൽ, അല്ലെങ്കിൽ വിവിധ മോണിറ്ററിംഗ് സിസ്റ്റങ്ങൾ ഉപയോഗിച്ച് വിഭവങ്ങളുടെ പ്രകടനം അളക്കുകയാണെങ്കിൽ, ഞങ്ങൾ ഈ മോണിറ്ററിംഗ് സിസ്റ്റത്തിന്റെ IP വിലാസം അല്ലെങ്കിൽ ക്ലയന്റിന്റെ ഓഫീസ് Wi-Fi എടുത്ത് അത് ഒരു ഉറവിടമായി ഉപയോഗിക്കുന്നു. അവസാനം, ഉറവിടം ലഭ്യമാണെന്ന് തോന്നുന്നു, പക്ഷേ ടാർഗെറ്റ് ഐപി വിലാസങ്ങൾ തടഞ്ഞു. അതിനാൽ, കമ്പനിയുടെ പുതിയ ഉൽപ്പന്നം അവതരിപ്പിക്കുന്ന ഹൈലോഡ് കോൺഫറൻസിന്റെ Wi-Fi നെറ്റ്‌വർക്ക് തടഞ്ഞേക്കാം, ഇത് ചില ബിസിനസ്സ്, സാമ്പത്തിക ചെലവുകൾ ഉൾക്കൊള്ളുന്നു.
പരിശോധനയ്ക്കിടെ, അനുവദനീയമായ IP വിലാസങ്ങളിലേക്ക് മാത്രം ട്രാഫിക് അയയ്‌ക്കുന്നതിനുള്ള കരാറുകൾ ഉള്ളതിനാൽ, ഏതെങ്കിലും ബാഹ്യ ഉറവിടങ്ങൾ ഉപയോഗിച്ച് മെംകാഷ് ചെയ്‌തത് വഴി ഞങ്ങൾക്ക് ആംപ്ലിഫിക്കേഷൻ ഉപയോഗിക്കാൻ കഴിയില്ല. അതനുസരിച്ച്, രണ്ടോ മൂന്നോ SYN-ACK-കൾ ഉപയോഗിച്ച് ഒരു SYN അയയ്‌ക്കുന്നതിന് സിസ്റ്റം പ്രതികരിക്കുമ്പോൾ, SYN, SYN-ACK എന്നിവയിലൂടെ ഞങ്ങൾ ആംപ്ലിഫിക്കേഷൻ ഉപയോഗിക്കുന്നു, കൂടാതെ ഔട്ട്‌പുട്ടിൽ ആക്രമണം രണ്ടോ മൂന്നോ തവണ കൊണ്ട് ഗുണിക്കപ്പെടുന്നു.

ഉപകരണങ്ങൾ

L7 വർക്ക്ലോഡിനായി ഞങ്ങൾ ഉപയോഗിക്കുന്ന പ്രധാന ഉപകരണങ്ങളിലൊന്നാണ് Yandex-tank. പ്രത്യേകിച്ചും, ഒരു ഫാന്റം ഒരു തോക്കായി ഉപയോഗിക്കുന്നു, കൂടാതെ വെടിയുണ്ടകൾ സൃഷ്ടിക്കുന്നതിനും ഫലങ്ങൾ വിശകലനം ചെയ്യുന്നതിനും നിരവധി സ്ക്രിപ്റ്റുകൾ ഉണ്ട്.
നെറ്റ്‌വർക്ക് ട്രാഫിക് വിശകലനം ചെയ്യാൻ Tcpdump ഉപയോഗിക്കുന്നു, കൂടാതെ സെർവർ വിശകലനം ചെയ്യാൻ Nmap ഉപയോഗിക്കുന്നു. L3&4 ലെവലിൽ ലോഡ് സൃഷ്‌ടിക്കുന്നതിന്, OpenSSL ഉം DPDK ലൈബ്രറിയുമൊത്തുള്ള ഞങ്ങളുടെ സ്വന്തം മാജിക്കും ഉപയോഗിക്കുന്നു. ലിനക്സ് സ്റ്റാക്കിനെ മറികടന്ന് നെറ്റ്‌വർക്ക് ഇന്റർഫേസുമായി പ്രവർത്തിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഇന്റലിൽ നിന്നുള്ള ഒരു ലൈബ്രറിയാണ് DPDK, അതുവഴി കാര്യക്ഷമത വർദ്ധിപ്പിക്കുന്നു. സ്വാഭാവികമായും, ഞങ്ങൾ L3&4 ലെവലിൽ മാത്രമല്ല, L7 ലെവലിലും DPDK ഉപയോഗിക്കുന്നു, കാരണം ഒരു മെഷീനിൽ നിന്ന് സെക്കൻഡിൽ നിരവധി ദശലക്ഷം അഭ്യർത്ഥനകളുടെ പരിധിക്കുള്ളിൽ വളരെ ഉയർന്ന ലോഡ് ഫ്ലോ സൃഷ്ടിക്കാൻ ഇത് ഞങ്ങളെ അനുവദിക്കുന്നു.
നിർദ്ദിഷ്ട ടെസ്റ്റുകൾക്കായി ഞങ്ങൾ എഴുതുന്ന ചില ട്രാഫിക് ജനറേറ്ററുകളും പ്രത്യേക ഉപകരണങ്ങളും ഞങ്ങൾ ഉപയോഗിക്കുന്നു. SSH-ന് കീഴിലുള്ള അപകടസാധ്യത ഞങ്ങൾ ഓർക്കുകയാണെങ്കിൽ, മുകളിലുള്ള സെറ്റ് പ്രയോജനപ്പെടുത്താൻ കഴിയില്ല. ഞങ്ങൾ മെയിൽ പ്രോട്ടോക്കോൾ ആക്രമിക്കുകയാണെങ്കിൽ, ഞങ്ങൾ മെയിൽ യൂട്ടിലിറ്റികൾ എടുക്കുകയോ അവയിൽ സ്ക്രിപ്റ്റുകൾ എഴുതുകയോ ചെയ്യും.

കണ്ടെത്തലുകൾ

ഒരു ഉപസംഹാരമായി ഞാൻ പറയാൻ ആഗ്രഹിക്കുന്നു:

• ക്ലാസിക് ലോഡ് ടെസ്റ്റിംഗിന് പുറമേ, സ്ട്രെസ് ടെസ്റ്റിംഗ് നടത്തേണ്ടത് ആവശ്യമാണ്. ഒരു പങ്കാളിയുടെ സബ് കോൺട്രാക്ടർ ലോഡ് ടെസ്റ്റിംഗ് മാത്രം നടത്തിയ ഒരു യഥാർത്ഥ ഉദാഹരണം ഞങ്ങളുടെ പക്കലുണ്ട്. റിസോഴ്സിന് സാധാരണ ലോഡിനെ നേരിടാൻ കഴിയുമെന്ന് ഇത് കാണിച്ചു. എന്നാൽ പിന്നീട് ഒരു അസാധാരണ ലോഡ് പ്രത്യക്ഷപ്പെട്ടു, സൈറ്റ് സന്ദർശകർ റിസോഴ്സ് അല്പം വ്യത്യസ്തമായി ഉപയോഗിക്കാൻ തുടങ്ങി, അതിന്റെ ഫലമായി സബ് കോൺട്രാക്ടർ കിടന്നു. അതിനാൽ, നിങ്ങൾ ഇതിനകം തന്നെ DDoS ആക്രമണങ്ങളിൽ നിന്ന് പരിരക്ഷിക്കപ്പെട്ടിട്ടുണ്ടെങ്കിലും കേടുപാടുകൾ അന്വേഷിക്കുന്നത് മൂല്യവത്താണ്.
• സിസ്റ്റത്തിന്റെ ചില ഭാഗങ്ങൾ മറ്റുള്ളവരിൽ നിന്ന് ഒറ്റപ്പെടുത്തേണ്ടത് ആവശ്യമാണ്. നിങ്ങൾക്ക് ഒരു തിരയൽ ഉണ്ടെങ്കിൽ, നിങ്ങൾ അത് പ്രത്യേക മെഷീനുകളിലേക്ക് നീക്കേണ്ടതുണ്ട്, അതായത്, ഡോക്കറിലേക്ക് പോലും. കാരണം തിരയലോ അംഗീകാരമോ പരാജയപ്പെടുകയാണെങ്കിൽ, കുറഞ്ഞത് എന്തെങ്കിലും പ്രവർത്തിക്കുന്നത് തുടരും. ഒരു ഓൺലൈൻ സ്റ്റോറിന്റെ കാര്യത്തിൽ, ഉപയോക്താക്കൾ കാറ്റലോഗിൽ ഉൽപ്പന്നങ്ങൾ കണ്ടെത്തുന്നത് തുടരും, അഗ്രഗേറ്ററിൽ നിന്ന് പോകുക, അവർക്ക് ഇതിനകം അംഗീകാരമുണ്ടെങ്കിൽ വാങ്ങുക, അല്ലെങ്കിൽ OAuth2 വഴി അംഗീകരിക്കുക.
• എല്ലാത്തരം ക്ലൗഡ് സേവനങ്ങളും അവഗണിക്കരുത്.
• നെറ്റ്‌വർക്ക് കാലതാമസം ഒപ്റ്റിമൈസ് ചെയ്യാൻ മാത്രമല്ല, ചാനൽ ക്ഷീണം, സ്റ്റാറ്റിക് ട്രാഫിക്കിലേക്ക് വെള്ളപ്പൊക്കം എന്നിവയ്‌ക്കെതിരായ ആക്രമണങ്ങളിൽ നിന്നുള്ള സംരക്ഷണ മാർഗ്ഗമായും CDN ഉപയോഗിക്കുക.
• പ്രത്യേക സംരക്ഷണ സേവനങ്ങൾ ഉപയോഗിക്കേണ്ടത് ആവശ്യമാണ്. നിങ്ങൾക്ക് ചാനൽ തലത്തിൽ L3&4 ആക്രമണങ്ങളിൽ നിന്ന് സ്വയം പരിരക്ഷിക്കാൻ കഴിയില്ല, കാരണം നിങ്ങൾക്ക് മതിയായ ചാനൽ ഇല്ലായിരിക്കാം. നിങ്ങൾക്ക് L7 ആക്രമണങ്ങളെ ചെറുക്കാൻ സാധ്യതയില്ല, കാരണം അവ വളരെ വലുതായിരിക്കും. കൂടാതെ, ചെറിയ ആക്രമണങ്ങൾക്കായുള്ള തിരയൽ ഇപ്പോഴും പ്രത്യേക സേവനങ്ങളുടെയും പ്രത്യേക അൽഗോരിതങ്ങളുടെയും പ്രത്യേകാവകാശമാണ്.
• പതിവായി അപ്ഡേറ്റ് ചെയ്യുക. ഇത് കേർണലിന് മാത്രമല്ല, എസ്എസ്എച്ച് ഡെമണിനും ബാധകമാണ്, പ്രത്യേകിച്ചും അവ പുറത്തേക്ക് തുറന്നിട്ടുണ്ടെങ്കിൽ. തത്വത്തിൽ, എല്ലാം അപ്ഡേറ്റ് ചെയ്യേണ്ടതുണ്ട്, കാരണം നിങ്ങൾക്ക് സ്വന്തമായി ചില കേടുപാടുകൾ ട്രാക്ക് ചെയ്യാൻ സാധ്യതയില്ല.

അവലംബം: www.habr.com