DDoS ആക്രമണത്തിന്റെ സമയത്ത് സൈറ്റിനെ സംരക്ഷിക്കുന്നതിനായി Cloudflare Under Attack മോഡ് ഉപയോഗിക്കുന്നത് അത്യാവശ്യമുള്ള ഒരു സുരക്ഷാ ക്രമീകരണമാണ്. ഇത് സന്ദർശകർക്കു ചെറിയൊരു സുരക്ഷാ പരിശോധന കാണിച്ച് ബോട്ട് ട്രാഫിക് ഫിൽട്ടർ ചെയ്യുന്നു. Cloudflare പാനലിൽ നിങ്ങളുടെ സൈറ്റ് തിരഞ്ഞെടുക്കുകയും Security വിഭാഗത്തിൽ നിന്ന് Under Attack Mode ആക്റ്റിവേറ്റ് ചെയ്യുകയും ചെയ്താൽ, HTTP/HTTPS നിലയിലെ ഭൂരിപക്ഷമായ അപേക്ഷകൾ കുറച്ച് നിമിഷങ്ങളിൽ മന്ദഗതിയാക്കുകയും യഥാർത്ഥ ഉപയോക്താക്കൾക്ക് സൈറ്റിൽ പ്രവേശനം ഉറപ്പാക്കുകയും സെർവർ ലോഡ് കുറയ്ക്കുകയും ചെയ്യാം. എന്നാൽ ഈ മോഡ് സ്ഥിരതയുള്ള പരിഹാരം അല്ല; ശരിയായ DNS പ്രോക്സി ക്രമീകരണങ്ങൾ, WAF നിയമങ്ങൾ, റേറ്റ് ലിമിറ്റിംഗ്, കാഷെ ക്രമീകരണങ്ങൾ, ഒറിജിൻ സെർവർ സുരക്ഷ എന്നിവയോടൊപ്പം ചേർന്നാണ് ഉപയോഗിക്കേണ്ടത്.
ഈ ഗൈഡിൽ നാം Cloudflare Under Attack മോഡ് എങ്ങനെ ഓണാക്കാം, ഏതു സമയത്ത് ഉപയോഗിക്കണം, ഏതു ക്രമീകരണങ്ങളാൽ പിന്തുണയ്ക്കണം, ആക്രമണം കഴിഞ്ഞ് എങ്ങനെ സുരക്ഷിതമായി സാധാരണ നിലയിലേക്ക് മടങ്ങാം എന്നതിനെ പടിയടി വിശദീകരിക്കും. ഉദ്ദേശ്യം അതിവേഗം പ്രയോഗിക്കാവുന്ന ഒരു നിയന്ത്രണ പട്ടിക നൽകുകയും നിങ്ങളുടെ സൈറ്റിന്റെ ലഭ്യത എത്രയും പെട്ടെന്ന് പുനസ്ഥാപിക്കാനും സഹായിക്കുക എന്നതാണ്.
Cloudflare Under Attack മോഡ് എന്താണ്?
Cloudflare Under Attack മോഡ് Cloudflare നൽക്കുന്ന അടിയന്തര സുരക്ഷാ നിലവാരമാണ്. ഇത് സജീവമാക്കുമ്പോൾ, സൈറ്റിലെ സന്ദർശകർക്ക് അവരുടെ ബ്രൗസർ വഴി ചെറിയൊരു പരിശോധന നടത്തുകയും ബോട്ടുകൾ, ലളിത HTTP ഫ്ലഡ് ഉപകരണങ്ങൾ, ദുഷ്ടമായ ബ്രൗസറല്ലാത്ത ക്ലയന്റുകൾ നേരിട്ട് സൈറ്റിൽ ഭാരം ചെലുത്തുന്നത് തടയുകയും ചെയ്യുന്നു. സാധാരണയായി ഈ പരിശോധന കുറച്ച് സെക്കൻഡുകൾ മാത്രം നീളും.
ഈ മോഡിന്റെ പ്രധാന ലക്ഷ്യം ലെയർ 7 അഥവാ ആപ്ലിക്കേഷൻ ലെയർ തലത്തിലുള്ള ആക്രമണങ്ങൾ കുറയ്ക്കുകയാണ്. ഉദാഹരണത്തിന്, പ്രധാന പേജിലേക്ക് സെക്കൻഡിൽ ആയിരക്കണക്കിന് GET അഭ്യർത്ഥനകൾ, WordPress ലോഗിൻ പേജിലേക്ക് POST ശ്രമങ്ങൾ, സർച്ച് പേജിലേക്ക് ഭാരമുള്ള ക്വറി അല്ലെങ്കിൽ കാർട്ട് പേജിലേക്ക് വ്യാജ ട്രാഫിക് അയയ്ക്കുന്നപ്പോൾ Under Attack മോഡ് വേഗത്തിൽ പ്രാരംഭ പ്രതിരോധം നൽകുന്നു.
ഇവിടെ ശ്രദ്ധിക്കേണ്ടത്, Under Attack മോഡ് വെബ് അഭ്യർത്ഥനകൾ ഫിൽട്ടർ ചെയ്യുമ്പോഴും, സെർവറിന്റെ IP വിലാസം നേരിട്ട് ലക്ഷ്യമാക്കപ്പെടുകയാണെങ്കിൽ, Cloudflare പ്രോക്സി പുറത്തുള്ള സേവനങ്ങൾ തുറന്നിരിക്കുകയാണെങ്കിൽ അല്ലെങ്കിൽ Layer 3/4 തലത്തിലുള്ള ആക്രമണം ഉണ്ടാകുമ്പോൾ അധിക സുരക്ഷാ ക്രമീകരണങ്ങൾ ആവശ്യമാകും. അതിനാൽ DNS റെക്കോർഡുകൾ Cloudflare വഴി പ്രോക്സി ചെയ്തിരിക്കണം, ഒറിജിൻ IP വിലാസം മറച്ചിരിക്കണം, ഹോസ്റ്റിംഗ് ഭാഗത്തു ശരിയായ സുരക്ഷാ നടപടികൾ സ്വീകരിക്കണം. സുരക്ഷിതമായ ഇന്ഫ്രാസ്ട്രക്ചർ തിരഞ്ഞെടുക്കുന്നതിന് സുരക്ഷിത വെബ് ഹോസ്റ്റിംഗ് സേവനങ്ങൾനും SSL സർട്ടിഫിക്കറ്റിന്റെ ഇൻസ്റ്റലേഷൻനും സന്ദർശിക്കാം.
DDoS ആക്രമണ ലക്ഷണങ്ങൾ: Under Attack മോഡിലേക്ക് മാറുന്നതിന് മുമ്പ് പരിശോധിക്കേണ്ടത്
ഓരോ സൈറ്റ് മന്ദഗതിയാകലും DDoS ആക്രമണമല്ല. ചിലപ്പോൾ തെറ്റായ പ്ലഗിനുകൾ, ഡാറ്റാബേസ് ലോക്കുകൾ, ഉയർന്ന CPU ഉപയോഗിക്കുന്ന ക്രോൺ ജോലികൾ, തെറ്റായ കാഷെ ക്രമീകരണങ്ങൾ പോലുള്ള കാര്യങ്ങളും സമാന പ്രശ്നങ്ങൾ സൃഷ്ടിക്കാൻ ഇടയുണ്ട്. അതിനാൽ Under Attack മോഡ് ഓണാക്കുന്നതിന് മുമ്പ് വേഗത്തിൽ പ്രശ്നം തിരിച്ചറിയുന്നത് നല്ലതാണ്. എന്നാൽ സെർവർ പ്രതികരിക്കാൻ ബുദ്ധിമുട്ടുകയാണെങ്കിൽ, ഉപയോക്താക്കൾക്ക് 502, 503, 504 പിശകുകൾ ലഭിക്കുന്നുവെങ്കിൽ, ലോഗുകളിൽ അസാധാരണമായ അഭ്യർത്ഥനകളുടെ പൊട്ടിപ്പ് കാണുകയാണെങ്കിൽ, അടിയന്തരമായി മോഡ് ഓണാക്കേണ്ടതാണ്.
സാധാരണ DDoS സൂചനകൾ
- സാധാരണ ട്രാഫിക്കിന്റെ 5, 10 അല്ലെങ്കിൽ 50 മടങ്ങ് കുത്തനെ വർധനവ് കുറച്ച് സമയത്തിനുള്ളിൽ കാണുക.
- ഒരു പേജിലോ എന്റ്പോയിന്റിലോ സെക്കൻഡിൽ നൂറുകണക്കിന് അഭ്യർത്ഥനകൾ എത്തുക.
- വിവിധ രാജ്യങ്ങളിൽ നിന്നുള്ള ഉപയോക്താക്കൾ സമാനമായ user-agent മൂല്യങ്ങളോടെ എത്തുക.
- WordPress, WooCommerce, OpenCart, അല്ലെങ്കിൽ കസ്റ്റം സോഫ്റ്റ്വെയറിൽ അഡ്മിൻ, ലോഗിൻ, സർച്ച്, കാർട്ട് പോലുള്ള അധിക ലോഡ് ഉണ്ടാക്കുന്ന URLകൾ ലക്ഷ്യമാക്കുക.
- സെർവറിൽ CPU, RAM, PHP-FPM വർക്കർ, MySQL കണക്ഷൻ പരിധികൾ നിറഞ്ഞുകിടക്കുക.
- Cloudflare Analytics-ൽ 4xx, 5xx പിശകുകൾ അപ്രതീക്ഷിതമായി ഉയരുക.
- യഥാർത്ഥ ഉപയോക്താക്കൾക്ക് ഇടയ്ക്കിടെ സൈറ്റിൽ പ്രവേശനം ലഭിക്കുമ്പോഴും ബോട്ട് ട്രാഫിക് തുടർച്ചയായി അഭ്യർത്ഥനകൾ അയയ്ക്കുക.
ഉദാഹരണത്തിന്, സാധാരണയായി മിനിറ്റിൽ 2,000 അഭ്യർത്ഥനകൾ സ്വീകരിക്കുന്ന ഒരു ഇ-കൊമേഴ്സ് സൈറ്റ് 10 മിനിറ്റിനുള്ളിൽ മിനിറ്റിൽ 80,000 അഭ്യർത്ഥനകളിലേക്ക് ഉയർന്നാൽ, ഇവയിൽ 70% കാർട്ട് അല്ലെങ്കിൽ സർച്ച് പേജിലേക്ക് പോകുകയാണെങ്കിൽ, ഇത് ലെയർ 7 ആക്രമണത്തിന്റെ വ്യക്തമായ സൂചനയാണ്. ഈ സാഹചര്യത്തിൽ Under Attack മോഡ് ആദ്യ 5 മിനിറ്റിനുള്ളിൽ ഓണാക്കുകയും ശേഷം ലക്ഷ്യമിട്ട URLകൾക്കായി WAF, റേറ്റ് ലിമിറ്റിംഗ് നിയമങ്ങൾ ചേർക്കുകയും വേണം.
Cloudflare Under Attack മോഡ് എപ്പോൾ ഉപയോഗിക്കണം?
Cloudflare Under Attack മോഡ് സ്ഥിരമായി ഓണാക്കിയിരിക്കേണ്ട സാധാരണ സുരക്ഷാ ക്രമീകരണമല്ല. കാരണം ഇത് യഥാർത്ഥ സന്ദർശകർക്കും ചെറിയ ഒരു കാത്തിരിപ്പ് സ്ക്രീൻ കാണിക്കുന്നു. പ്രത്യേകിച്ച് കൺവർഷൻ ലക്ഷ്യമിട്ട പേജുകളിൽ, പേയ്മെന്റ് ഘട്ടങ്ങളിൽ, API ഉപയോഗിക്കുന്ന ഘടനകളിൽ ഉപയോക്തൃ പരിചയത്തെ ബാധിക്കാം. അതിനാൽ ഏറ്റവും ഉചിതമായ ഉപയോഗം, ആക്രമണ സമയത്ത് താൽക്കാലികമായി സജീവമാക്കുകയും ട്രാഫിക് സാധാരണ നിലയിലേക്ക് മടങ്ങുമ്പോൾ സുരക്ഷാ നില പുനഃക്രമീകരിക്കുകയും ചെയ്യുകയാണ്.
ഉപയോഗത്തിന് അനുയോജ്യമായ സാഹചര്യങ്ങൾ
- സൈറ്റിലേക്ക് അസാധാരണമായ, ഭാരമുള്ള HTTP/HTTPS അഭ്യർത്ഥനകൾ വരുമ്പോൾ.
- സെർവർ വിഭവങ്ങൾ വേഗത്തിൽ തീരുമ്പോൾ, 502/503 പിശകുകൾ വർദ്ധിക്കുമ്പോൾ.
- Cloudflare WAF പ്രത്യേക നിയമങ്ങളോടെ ക്രമീകരിക്കപ്പെടാത്തപ്പോൾ വേഗത്തിലുള്ള പ്രതിരോധം ആവശ്യമായപ്പോൾ.
- ബോട്ട് ട്രാഫിക് യഥാർത്ഥ ഉപയോക്തൃ ട്രാഫിക്കിനെക്കാൾ ഗണ്യമായി കൂടുതലായിരിക്കുമ്പോൾ.
- ആക്രമണം വെബ് പേജുകൾ, ഫോമുകൾ, ലോഗിൻ സ്ക്രീനുകൾ, സർച്ച് എന്റ്പോയിന്റുകൾ എന്നിവയെ ലക്ഷ്യമിട്ടിരിക്കുമ്പോൾ.
ജാഗ്രതാപൂർവം ഉപയോഗിക്കേണ്ട സാഹചര്യങ്ങൾ
- മൊബൈൽ ആപ്ലിക്കേഷൻ, പേയ്മെന്റ് പ്രൊവൈഡർ, webhook, API ട്രാഫിക് ഭാരമുള്ളപ്പോൾ.
- സെർച്ച് എഞ്ചിൻ ബോട്ടുകൾ നിർണായകമായ ക്രോൾ പ്രവർത്തനത്തിലാണ്.
- കോർപ്പറേറ്റ് ഉപയോക്താക്കൾ പഴയ ബ്രൗസറുകൾ അല്ലെങ്കിൽ നിയന്ത്രിത നെറ്റ്വർക്ക് പരിസ്ഥിതിയിൽ നിന്നാണ് സൈറ്റ് സന്ദർശിക്കുന്നത്.
- സൈറ്റിൽ Cloudflare പ്രോക്സി പുറത്ത് ഉള്ള സബ് ഡൊമെയ്നുകൾ ഉണ്ടായാൽ.
API ട്രാഫിക് ഉള്ള സൈറ്റുകളിൽ Under Attack മോഡ് മുഴുവൻ ഡൊമെയ്നിലേക്കും പ്രയോഗിച്ചാൽ ചില ഇന്റഗ്രേഷനുകൾ പരാജയപ്പെടാം. അതിനാൽ API സബ് ഡൊമെയ്നുകൾക്കായി പ്രത്യേക WAF നിയമങ്ങൾ, allowlist, അല്ലെങ്കിൽ വ്യത്യസ്ത സുരക്ഷാ നില നിർദ്ദേശിക്കണം. API സുരക്ഷ സംബന്ധിച്ച കൂടുതൽ വിവരങ്ങൾക്ക് API സുരക്ഷയും നിരക്ക് പരിധികളും മാർഗ്ഗദർശകൻ സന്ദർശിക്കാം.
Cloudflare Under Attack മോഡ് എങ്ങനെ ഓണാക്കാം? പടിയടി പ്രക്രിയ
താഴെ നൽകിയിട്ടുള്ള ഘട്ടങ്ങൾ ആക്രമണ സമയത്ത് വേഗത്തിൽ പ്രവർത്തിക്കാൻ സഹായിക്കുന്ന പ്രായോഗിക നിയന്ത്രണ പട്ടികയാണ്. Cloudflare ഇന്റർഫേസ് ചെറിയ മാറ്റങ്ങൾ കാണിച്ചേക്കാം, എന്നാൽ പ്രക്രിയ തത്വപരമായും ഒരുപോലെയാണ്: ഡൊമെയ്ൻ തിരഞ്ഞെടുക്കുക, സുരക്ഷാ നില ഉയർത്തുക, Cloudflare വഴി ട്രാഫിക് പരിശോധന നടത്തുക.
1. Cloudflare അക്കൗണ്ടിൽ ലോഗിൻ ചെയ്യുക
ആദ്യം Cloudflare അക്കൗണ്ടിൽ പ്രവേശിച്ച് ആക്രമണത്തിലുള്ള ഡൊമെയ്ൻ തിരഞ്ഞെടുക്കുക. നിങ്ങൾക്ക് ഒന്നിലധികം ഡൊമെയ്ൻ ഉണ്ടെങ്കിൽ ശരിയായ സോണിൽ പ്രവർത്തിക്കുകയാണെന്ന് ഉറപ്പാക്കുക. തെറ്റായ ഡൊമെയ്ൻ തിരഞ്ഞെടുക്കുന്നത് സമയം കളയുകയും, ആക്രമണം തുടരുമെന്നും കാരണമാകുന്നു.
2. DNS റെക്കോർഡുകൾ proxied ആണെന്ന് ഉറപ്പാക്കുക
Under Attack മോഡ് ഫലപ്രദമാകാൻ വെബ് ട്രാഫിക് Cloudflare വഴി കടക്കേണ്ടതാണ്. DNS സെക്ഷനിൽ A, AAAA, CNAME റെക്കോർഡുകൾക്കു മുന്നിൽ ഓറഞ്ച് മേഘം (proxied) കാണണം. ഗ്രേ മേഘം ഉള്ള DNS only റെക്കോർഡുകൾ Cloudflare സുരക്ഷാ ലെയറിൽ കടക്കില്ല. പ്രത്യേകിച്ച് www, റൂട്ടും ഉപയോഗിക്കുന്ന സബ് ഡൊമെയ്നുകളും പരിശോധിക്കണം.
ഒറിജിൻ IP വിലാസം വെബിൽ തുറന്നിരിക്കുകയാണെങ്കിൽ, ആക്രമകർ Cloudflare ഒഴിവാക്കിയിട്ട് നേരിട്ട് സെർവറിനെ ലക്ഷ്യമാക്കും. അതിനാൽ സെർവർ ഫയർവാളിൽ Cloudflare IP റേഞ്ചുകളിൽനിന്നുള്ള HTTP/HTTPS ട്രാഫിക് മാത്രം അനുവദിക്കുക എന്നത് ശക്തമായ സുരക്ഷാ നടപടിയാണ്. ഹോസ്റ്റിംഗ് പ്രൊവൈഡറിൽ നിന്നും സഹായം തേടുക അല്ലെങ്കിൽ Cloudflare DNS ക്രമീകരണങ്ങൾ എങ്ങനെയായിരിക്കും എന്ന ഗൈഡ് കാണുക.
3. Security വിഭാഗത്തിൽ നിന്നും Under Attack Mode സജീവമാക്കുക
Cloudflare പാനലിൽ ബന്ധപ്പെട്ട ഡൊമെയ്ൻ തുറന്ന് Security അല്ലെങ്കിൽ Overview പേജിൽ Under Attack Mode ഓപ്ഷൻ കണ്ടെത്തുക. ഇത് സജീവമാക്കിയാൽ Cloudflare സന്ദർശകർക്ക് ചെറിയ പരിശോധന പേജ് കാണിക്കും. ചില പാനലുകളിൽ ഇത് "I am Under Attack" എന്ന പേരിൽ കാണാം.
സജീവമാക്കിയതിന് ശേഷം മാറ്റങ്ങൾ സാധാരണയായി വേഗത്തിൽ പ്രാബല്യത്തിൽ വരും. ആദ്യ മിനിറ്റുകളിൽ Cloudflare Analytics, Security Events, സെർവർ വിഭവങ്ങളുടെ ഉപയോഗം നിരീക്ഷിക്കുക. CPU, കണക്ഷൻ എണ്ണം കുറയാൻ തുടങ്ങുകയാണെങ്കിൽ മോഡ് ഫലപ്രദമാണ്. എന്നാൽ പിശകുകൾ തുടരുകയാണെങ്കിൽ അധിക നിയമങ്ങൾ ചേർക്കേണ്ടതുണ്ട്.
4. യഥാർത്ഥ ഉപയോക്തൃ അനുഭവം പരിശോധിക്കുക
മോഡ് ഓണാക്കിയ ശേഷം വ്യത്യസ്ത നെറ്റ്വർക്കുകളിൽ നിന്നുള്ള സൈറ്റ് പരിശോധന നടത്തുക. മൊബൈൽ ഇന്റർനെറ്റ്, ഓഫീസ് നെറ്റ്വർക്ക്, മറ്റൊരു ഭൗതിക സ്ഥലം എന്നിവയിൽ പ്രധാന പേജ്, ഉൽപ്പന്ന പേജ്, ലോഗിൻ പേജ്, പേയ്മെന്റ് പ്രക്രിയ എന്നിവ പരിശോധിക്കുക. ഉപയോക്താക്കൾ പരിശോധന പേജ് കഴിഞ്ഞ് സൈറ്റിൽ പ്രവേശിക്കുകയാണെങ്കിൽ ഇത് സാധാരണമായ പെരുമാറ്റമാണ്. എന്നാൽ ഉപയോക്താക്കൾ അനന്ത പരിശോധന ചക്രത്തിൽ പെട്ടാൽ, കുക്കി തടയൽ, ബ്രൗസർ പൊരുത്തക്കേടുകൾ, Cloudflare സുരക്ഷാ നിയമം കൂട്ടിയിടിച്ചൽ എന്നിവ പരിശോധിക്കണം.
5. ആക്രമണ ലക്ഷ്യമിട്ട URLകൾ തിരിച്ചറിയുക
Under Attack മോഡ് പൊതുവായൊരു പ്രതിരോധം നൽകുമ്പോൾ, ലക്ഷ്യമിട്ട URLകൾക്കായി പ്രത്യേക നിയമങ്ങൾ ഉപയോഗിച്ചും കൂടുതൽ ഫലപ്രദമാക്കാം. Cloudflare Security Events, വെബ് അനലിറ്റിക്സ്, ഹോസ്റ്റിംഗ് ലോഗുകൾ, ആപ്ലിക്കേഷൻ ലോഗുകൾ എന്നിവയിൽ ഏറ്റവും കൂടുതൽ അപേക്ഷ ലഭിക്കുന്ന പാതകൾ കണ്ടെത്തുക. ഉദാഹരണത്തിന് /wp-login.php, /xmlrpc.php, /search, /cart, /api/login, /checkout തുടങ്ങിയവ ആക്രമണത്തിന് ഇരയായിരിക്കും.
ലക്ഷ്യമിട്ട URL കണ്ടെത്തിയാൽ WAF Custom Rules ഉപയോഗിച്ച് രാജ്യങ്ങൾ, user-agent, അഭ്യർത്ഥന രീതി, URI പാത്ത്, ബോട്ട് സ്കോർ എന്നിവ അടിസ്ഥാനമാക്കി നടപടികൾ സ്വീകരിക്കാം. ഉദാഹരണത്തിന് ഒരു ലോഗിൻ എന്റ്പോയിന്റിലേക്ക് മിനിറ്റിൽ സാധാരണക്കാൾ അധികം അഭ്യർത്ഥന അയക്കുന്ന IP-കളെ managed challenge-ൽ ഇടാം. WordPress സൈറ്റുകൾക്കായി WordPress സുരക്ഷാ മുൻകൂറുകൾ പ്രകൃതമായ ഒരു ഇന്റർലിങ്ക് അവസരമാണ്.
Under Attack മോഡും മറ്റു Cloudflare സുരക്ഷാ ഓപ്ഷനുകളുമായുള്ള വ്യത്യാസം
Cloudflare സുരക്ഷാ ഉപകരണങ്ങൾ വിവിധ ആവശ്യങ്ങൾക്കായി രൂപകൽപ്പന ചെയ്തതാണ്. Under Attack മോഡ് വേഗത്തിലുള്ള പൊതു അടിയന്തര ഫിൽറ്റർ ആണ്; WAF, Rate Limiting എന്നിവ കൂടുതൽ ലക്ഷ്യമിട്ട, ദീർഘകാലം നിലനിൽക്കുന്ന, ഉപയോക്തൃ അനുഭവം മെച്ചപ്പെടുത്തുന്ന പരിഹാരങ്ങളാണ്.
| സവിശേഷത | എന്തിന് ഉപയോഗിക്കുന്നു? | എപ്പോൾ ഉപയോഗിക്കണം? | ഉപയോക്തൃ സ്വാധീനം |
|---|---|---|---|
| Under Attack മോഡ് | എല്ലാ സന്ദർശകർക്കും സുരക്ഷാ പരിശോധന നടപ്പിലാക്കുന്നു, ബോട്ട് ട്രാഫിക് കുറയ്ക്കുന്നു. | സജീവ DDoS അല്ലെങ്കിൽ ഭാരമുള്ള HTTP ഫ്ലഡ് ആക്രമണത്തിൽ. | യഥാർത്ഥ ഉപയോക്താവ് ചെറിയ കാത്തിരിപ്പ് സ്ക്രീൻ കാണും. |
| WAF Custom Rules | നിശ്ചിത URL, രാജ്യങ്ങൾ, IP, അഭ്യർത്ഥന രീതി, user-agent എന്നിവയ്ക്ക് നിയമങ്ങൾ സൃഷ്ടിക്കുന്നു. | ആക്രമണ മാതൃക അറിയാമെങ്കിൽ ലക്ഷ്യമിട്ട തടയലിന്. | ശരിയായി എഴുതിയാൽ കുറവായ സ്വാധീനം. |
| Rate Limiting | ഒരു സമയപരിധിയിൽ അധികം അഭ്യർത്ഥന അയക്കുന്ന ക്ലയന്റുകളെ നിയന്ത്രിക്കുന്നു. | ലോഗിൻ, സർച്ച്, API, കാർട്ട് പോലുള്ള ഭാരമുള്ള എൻഡ്പോയിന്റുകളിൽ. | പരിധികൾ തെറ്റായാൽ യഥാർത്ഥ ഉപയോക്തൃ ബാധിതർ. |
| Bot Fight Mode | ലളിതമായ ബോട്ട് പെരുമാറ്റങ്ങൾ കുറയ്ക്കാൻ സഹായിക്കുന്നു. | താഴ്ന്നതോ മധ്യമനിലയിലെ ബോട്ട് ട്രാഫിക്കിൽ സ്ഥിരമായി. | പലപ്പോഴും കുറവായ സ്വാധീനം. |
| Cache Rules | സ്റ്റാറ്റിക് അല്ലെങ്കിൽ അനുയോജ്യമായ ഡൈനാമിക് ഉള്ളടക്കം എഡ്ജ് സർവറുകളിൽ നിന്ന് സർവ്വ് ചെയ്യുന്നു. | സെർവർ ഭാരം സ്ഥിരമായി കുറയ്ക്കാൻ. | ശരിയായി ക്രമീകരിച്ചാൽ നല്ല സ്വാധീനം. |
പ്രായോഗികമായി നല്ല പ്രതിരോധം ഇങ്ങനെ നടക്കും: ആദ്യം Under Attack മോഡ് ഉപയോഗിച്ച് അടിയന്തര ഭാരം കുറയ്ക്കാം, തുടർന്ന് ആക്രമണ മാതൃക പരിശോധിച്ച് WAF, Rate Limiting നിയമങ്ങൾ ചേർക്കാം, അവസാനം കാഷെ, ഒറിജിൻ ഫയർവാൾ ക്രമീകരണങ്ങൾ ഉപയോഗിച്ച് സ്ഥിരത ഉറപ്പാക്കാം.
ആക്രമണ സമയത്ത് ശുപാർശ ചെയ്യുന്ന മറ്റ് Cloudflare ക്രമീകരണങ്ങൾ
Under Attack മോഡ് ഒരു ബട്ടൺ അമർത്തി സജീവമാക്കാവുന്നെങ്കിലും, DDoS പ്രതിരോധത്തിന്റെ വിജയത്തിന് പിന്തുണയുള്ള ക്രമീകരണങ്ങൾ അനിവാര്യമാണ്. താഴെ കൊടുത്തിരിക്കുന്നത് യഥാർത്ഥ പ്രവർത്തനങ്ങളിൽ ഏറ്റവും ഫലപ്രദമായ മാർഗ്ഗങ്ങളാണ്.
WAF നിയമങ്ങളിലൂടെ ലക്ഷ്യമിട്ട സംരക്ഷണം
Cloudflare WAF നിന്റെ വ്യത്യസ്ത സാഹചര്യങ്ങളിൽ നടപടികൾ എടുക്കാൻ സഹായിക്കുന്നു. ഉദാഹരണത്തിന് /wp-login.php പേജിലേക്ക് മാത്രം പോസ്റ്റ് അഭ്യർത്ഥനകൾക്ക് നിശ്ചിത രാജ്യങ്ങളിൽ നിന്നുള്ളവയ്ക്ക് മാത്രം challenge നല്കാം. ഇതിലൂടെ സൈറ്റ് മുഴുവൻ ഭാരം കൂടാതെ ആക്രമണ ലക്ഷ്യം വേർതിരിക്കാം.
- അഡ്മിൻ, ലോഗിൻ പേജുകൾ നിശ്ചിത രാജ്യങ്ങൾക്കും IP ശ്രേണികൾക്കും മാത്രം തുറക്കുക.
- ഉപയോഗിക്കാത്ത XML-RPC പോലുള്ള എൻഡ്പോയിന്റുകൾ അടയ്ക്കുക.
- ശങ്കാസ്പദമായ user-agent മൂല്യങ്ങൾക്ക് managed challenge നൽകുക.
- നിശ്ചിത URI പാത്തിൽ ആവർത്തിച്ച് അഭ്യർത്ഥനയുള്ള ക്ലയന്റുകൾക്ക് rate limit ഏർപ്പെടുത്തുക.
കാഷെ നില ശരിയായി ക്രമീകരിക്കുക
DDoS സമയത്ത് ഒറിജിൻ സെർവർ ഓരോ അഭ്യർത്ഥനയ്ക്കും പ്രതികരിക്കേണ്ടതായാൽ വിഭവങ്ങൾ വേഗം തീരും. സ്റ്റാറ്റിക് ഫയലുകൾ, ചിത്രങ്ങൾ, CSS, ജാവാസ്ക്രിപ്റ്റ്, കാഷെ ചെയ്യാവുന്ന പേജുകൾ Cloudflare എഡ്ജിലൂടെ സർവ്വ് ചെയ്യണം. WordPress പോലുള്ള ഡൈനാമിക് സൈറ്റുകളിൽ പേജുകൾ ക്യാഷെ ചെയ്യാനുള്ള പ്ലഗിനുകൾ, Cloudflare Cache Rules, cache-control ഹെഡറുകൾ എന്നിവ ചേർന്ന് ഉപയോഗിക്കാം.
ഉദാഹരണത്തിന് വാർത്ത, ബ്ലോഗ് ആധാരിത സൈറ്റുകളിൽ അനോണിമസ് ഉപയോക്താക്കൾക്ക് കാണിക്കുന്ന പേജുകൾ 5 മുതൽ 30 മിനിറ്റ് വരെ ക്യാഷെ ചെയ്യാം. ഈ ക്രമീകരണം ആക്രമണത്തിന് പുറമെ TTFB മൂല്യം കുറയ്ക്കുകയും ഹോസ്റ്റിംഗ് വിഭവങ്ങൾ ലഘൂകരിക്കുകയും ചെയ്യും. പ്രകടന മെച്ചപ്പെടുത്തലുകൾക്കായി വെബ് സൈറ്റിന്റെ വേഗം വർദ്ധിപ്പിക്കാൻ മാർഗ്ഗനിർദ്ദേശം കാണാവുന്നതാണ്.
Rate limiting പരിധികൾ യഥാർത്ഥപരമായി നിശ്ചയിക്കുക
Rate limiting പ്രത്യേകിച്ച് ഭാരമുള്ള എൻഡ്പോയിന്റുകളിൽ വളരെ ഫലപ്രദമാണ്. എന്നാൽ പരിധികൾ അനിയന്ത്രിതമായി നിശ്ചയിച്ചാൽ യഥാർത്ഥ ഉപയോക്താക്കളും തടയപ്പെടും. ഉദാഹരണത്തിന് ഒരു ഉൽപ്പന്ന സർച്ച് പേജിൽ സാധാരണ ഉപയോക്താവ് മിനിറ്റിൽ 5-15 സർച്ച് ചെയ്യാം; 100 സർച്ച് മിനിറ്റിൽ അസാധാരണമാണ്. ലോഗിൻ പേജിൽ 5 മിനിറ്റിൽ 10 പരാജയപ്പെട്ട ശ്രമങ്ങൾ പലപ്പോഴും സംശയാസ്പദമാണ്.
ഉദാഹരണമായി: /wp-login.php-യ്ക്ക് മിനിറ്റിൽ 10-ലധികം അഭ്യർത്ഥന ചെയ്യുന്ന IP-കൾക്ക് managed challenge, 5 മിനിറ്റിൽ 50-ലധികം അഭ്യർത്ഥന ചെയ്യുന്ന IP-കൾക്ക് താൽക്കാലിക ബ്ലോക്ക് നൽകാം. API എൻഡ്പോയിന്റുകൾക്ക് ഉപയോക്തൃ സെഷൻ, IP, ടോക്കൺ, മെത്തഡ് എന്നിവ അടിസ്ഥാനമാക്കി കൂടുതൽ സൂക്ഷ്മമായ പരിധികൾ നിശ്ചയിക്കണം.
ഒറിജിൻ IP വിലാസം മറച്ചുവെച്ച് ഫയർവാൾ ക്രമീകരിക്കുക
Cloudflare ഉപയോഗിക്കുമ്പോൾ ഏറ്റവും വലിയ പിഴവ് ഒറിജിൻ IP വിലാസം വെളിപ്പെടുത്തുക എന്നതാണ്. പഴയ DNS റെക്കോർഡുകൾ, നേരിട്ട് IP ഉപയോഗിക്കുന്ന സബ് ഡൊമെയ്നുകൾ, മെയിൽ റെക്കോർഡുകൾക്കൊപ്പം പ്രവർത്തിക്കുന്ന വെബ് സേവനങ്ങൾ, തെറ്റായ കോൺഫിഗറേഷനുകൾ എന്നിവ ആക്രമകർക്ക് Cloudflare ഒഴികെയുള്ള വഴികളിലൂടെ സെർവറിലേക്ക് പ്രവേശിക്കാൻ അവസരം നൽകും.
സെർവർ ഭാഗത്ത് 80, 443 പോർട്ടുകൾ Cloudflare IP ശ്രേണികൾക്ക് മാത്രമായി തുറക്കുക ശക്തമായ സംരക്ഷണം നൽകും. SSH, പാനൽ, ഡാറ്റാബേസ്, അഡ്മിനിസ്ട്രേഷൻ പോർട്ടുകൾ ഇന്റർനെറ്റിൽ തുറന്നിരിക്കരുത്; IP നിയന്ത്രണം, ശക്തമായ പാസ്വേഡ്, 2FA, VPN എന്നിവ ഉപയോഗിക്കുക. ഹോസ്റ്റിംഗ് സുരക്ഷയുമായി ബന്ധപ്പെട്ട് cPanel സുരക്ഷാ ക്രമീകരണങ്ങൾയും വിപിഎസ് ഫയർവാൾ നിർമ്മാണംയും കാണാവുന്നതാണ്.
WordPress, WooCommerce, കോർപ്പറേറ്റ് സൈറ്റുകളിൽ പ്രത്യേക ശ്രദ്ധ
ഓരോ വെബ് സൈറ്റിന്റെയും ട്രാഫിക് ഘടന ഒരുപോലെയല്ല. ഒരു ബ്ലോഗ് സൈറ്റ്, WooCommerce സ്റ്റോർ, SaaS പാനൽ എന്നിവയ്ക്ക് Cloudflare Under Attack മോഡിന്റെ ഫലങ്ങൾ വ്യത്യസ്തമായിരിക്കും. അതിനാൽ സൈറ്റ് തരം അനുസരിച്ച് പ്രധാന പാതകൾ നിർണയിക്കണം.
WordPress സൈറ്റുകൾ
WordPress-ൽ ഏറ്റവും കൂടുതൽ ലക്ഷ്യമാകുന്ന പാതകൾ /wp-login.php, /xmlrpc.php എന്നിവയാണ്. XML-RPC ഉപയോഗിക്കാത്ത പക്ഷം അത് തടയുന്നത് സാധാരണ സുരക്ഷയാണെന്ന് പരിഗണിക്കാം. അഡ്മിൻ പാനലിന് നിശ്ചിത രാജ്യങ്ങൾക്കും IP ശ്രേണികൾക്കുമാത്രം പ്രവേശനം അനുവദിക്കുക. കൂടാതെ സുരക്ഷാ പ്ലഗിനുകളും Cloudflare നിയമങ്ങളും തമ്മിൽ കൂട്ടിയിടിക്കാതിരിക്കണം; അധിക challenge സംവിധാനം ഉപയോക്താവിനെ അനന്ത പരിശോധനയിൽ കുടുക്കും.
WooCommerce സ്റ്റോറുകൾ
WooCommerce-ൽ കാർട്ട്, പേയ്മെന്റ്, അക്കൗണ്ട് പേജുകൾ ശ്രദ്ധിക്കണം. ഈ പേജുകൾ ഡൈനാമിക് ആയതിനാൽ അധിക കാഷെ ഉപയോഗിക്കരുത്. Under Attack മോഡ് സജീവമാക്കിയപ്പോൾ പേയ്മെന്റ് പ്രൊവൈഡറിന്റെ callback, webhook URLകൾ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക. ആവശ്യമെങ്കിൽ പേയ്മെന്റ് പ്രൊവൈഡറിന്റെ IP ശ്രേണികൾ allowlist-ൽ ചേർക്കുക അല്ലെങ്കിൽ പ്രത്യേക നിയമങ്ങൾ ഉപയോഗിക്കുക.
കോർപ്പറേറ്റ്, API ഉപയോഗിക്കുന്ന സൈറ്റുകൾ
കോർപ്പറേറ്റ് പോർട്ടലുകൾ, CRM ഇന്റഗ്രേഷനുകൾ, മൊബൈൽ ആപ്ലിക്കേഷൻ API-കൾ ജാവാസ്ക്രിപ്റ്റ് challenge സ്ക്രീനുകൾ കൈകാര്യം ചെയ്യാൻ കഴിയില്ല. ഇത്തരത്തിലുള്ള സൈറ്റുകളിൽ മുഴുവൻ ഡൊമെയ്നിലും Under Attack മോഡ് പ്രയോഗിക്കുന്നത് ബുദ്ധിമുട്ട് സൃഷ്ടിക്കും. www.example.com-ൽ Under Attack ഓണാക്കിയപ്പോൾ api.example.com-ക്കായി ടോക്കൺ അടിസ്ഥാനമാക്കി സുരക്ഷ, റേറ്റ് ലിമിറ്റിംഗ്, allowlist എന്നിവ വേറിട്ടു ക്രമീകരിക്കണം.
Under Attack മോഡ് ഓണാക്കിയതിനുശേഷം നിരീക്ഷിക്കേണ്ട മെട്രിക്സ്

സുരക്ഷാ ക്രമീകരണം ഫലപ്രദമാണോ എന്നറിയാൻ സംഖ്യാത്മക നിരീക്ഷണം ആവശ്യമാണ്. സൈറ്റ് തുറങ്ങുന്നത് മാത്രം മതിയല്ല; പിശകുകളുടെ നിരക്ക്, സെർവർ ലോഡ്, യഥാർത്ഥ ഉപയോക്തൃ പെരുമാറ്റം എന്നിവ കൂടി വിലയിരുത്തണം.
- Cloudflare Security Events: ഏത് നിയമം എത്ര അഭ്യർത്ഥന challenge അല്ലെങ്കിൽ block ചെയ്തുവെന്ന് കാണിക്കുന്നു.
- HTTP സ്റ്റാറ്റസ് കോഡുകൾ: 403, 429, 502, 503, 504 പിശകുകളുടെ മാറ്റം നിരീക്ഷിക്കുക.
- സെർവർ CPU, RAM ഉപയോഗം: Under Attack മോഡിനു ശേഷം കുറവ് പ്രതീക്ഷിക്കാം.
- PHP-FPM, MySQL കണക്ഷനുകൾ: ആപ്ലിക്കേഷൻ ലെയറിൽ ആശ്വാസം കാണിക്കുന്നു.
- ബാൻഡ്വിഡ്ത്തും അഭ്യർത്ഥന സംഖ്യയും: ട്രാഫിക് വോളിയം ഫിൽട്ടർ ചെയ്ത അഭ്യർത്ഥനകളുമായി താരതമ്യം ചെയ്യുക.
- യഥാർത്ഥ ഉപയോക്തൃ കൺവർഷനുകൾ: ഫോം സമർപ്പിക്കൽ, ഓർഡർ, ലോഗിൻ, പേയ്മെന്റ് ഘട്ടങ്ങൾ പരിശോധിക്കുക.
ഉദാഹരണത്തിന് Under Attack മോഡ് ഓണാക്കിയതിന് ശേഷം മൊത്തം അഭ്യർത്ഥനകൾ ഒരുപോലെയുണ്ടെങ്കിലും ഒറിജിനിലേക്ക് എത്തുന്ന അഭ്യർത്ഥന 60% കുറയുകയാണെങ്കിൽ Cloudflare ലെയർ പ്രധാന ഭാരം കൈകാര്യം ചെയ്യുന്നു. എന്നാൽ MySQL CPU ഉപയോഗം ഉയർന്നിരിക്കുകയാണെങ്കിൽ, ആക്രമണം പ്രത്യേകമായി ഒരു ഡൈനാമിക് ക്വറി ഉണർത്തിയിരിക്കാം; ആപ്ലിക്കേഷൻ ലോഗുകൾ പരിശോധിക്കുക.
ആക്രമണം കഴിഞ്ഞ് Under Attack മോഡ് എങ്ങനെ ഓഫ് ചെയ്യാം?
ആക്രമണ ട്രാഫിക് സാധാരണ നിലയിലേക്ക് മടങ്ങുമ്പോൾ Under Attack മോഡ് സ്ഥിരമായി ഓണാക്കിയിരിക്കുന്നത് സാധാരണ സൈറ്റുകൾക്ക് ശുപാർശിക്കപ്പെടുന്നില്ല. എല്ലാ സന്ദർശകർക്കും അധിക പരിശോധന കാണിക്കുന്നത് കൺവർഷൻ നിരക്ക്, ക്രോൾ ഫലപ്രദത, ഉപയോക്തൃ സംതൃപ്തി എന്നിവയെ ബാധിക്കും. ഓഫ് ചെയ്യുന്നതും ഓണാക്കുന്നതുപോലെയാണ് സൂക്ഷ്മമായി നടത്തേണ്ടത്.
സുരക്ഷിതമായ സാധാരണ നിലയിലേക്ക് മടങ്ങൽ ഘട്ടങ്ങൾ
- കുറഞ്ഞത് 30-60 മിനിറ്റ് ട്രാഫിക് സാധാരണ നിലയിലേക്ക് മടങ്ങാൻ കാത്തിരിക്കുക.
- Cloudflare Security Events-ൽ challenge, block എണ്ണങ്ങൾ കുറയുന്നത് സ്ഥിരീകരിക്കുക.
- Under Attack മോഡ് ഓഫ് ചെയ്യുന്നതിന് മുമ്പ് ലക്ഷ്യമിട്ട WAF, Rate Limiting നിയമങ്ങൾ സജീവമാണെന്ന് ഉറപ്പാക്കുക.
- സുരക്ഷാ നിലവാരം High അല്ലെങ്കിൽ Medium പോലുള്ള ബാലൻസഡ് നിലയിലേക്ക് കുറയ്ക്കുക.
- വിവിധ ഉപകരണങ്ങളിൽ സൈറ്റ് പരീക്ഷിച്ച് 5xx പിശകുകളുടെ നിരക്ക് പരിശോധിക്കുക.
- 24 മണിക്കൂർ ലോഗുകൾ നിരീക്ഷിച്ച് ആക്രമണം വീണ്ടും തുടങ്ങുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക.
നല്ല പ്രാക്ടീസ് ആയി, ആക്രമണത്തിന് ശേഷം ഒരു സംഭവ റിപ്പോർട്ട് തയ്യാറാക്കണം. അതിൽ ആക്രമണ ആരംഭ സമയം, ലക്ഷ്യമിട്ട URLകൾ, അഭ്യർത്ഥന പരമാവധി എണ്ണം, സ്വീകരിച്ച നടപടികൾ, ഫലപ്രദമായ നിയമങ്ങൾ, സ്ഥിരത ഉറപ്പാക്കുന്ന മെച്ചപ്പെടുത്തലുകൾ എന്നിവ രേഖപ്പെടുത്തണം. ഇത് അടുത്ത സംഭവത്തിൽ ഇടപെടൽ സമയം വളരെ കുറയ്ക്കും.
പൊതുവായ പിശകുകൾ ഒപ്പം അവ ഒഴിവാക്കേണ്ടത്
DDoS സമയത്ത് വേഗത്തിലുള്ള തീരുമാനം എടുക്കണമെന്ന് തോന്നും; എന്നാൽ തെറ്റായ ക്രമീകരണങ്ങൾ യഥാർത്ഥ ഉപയോക്താക്കളേയും തടയാനിടയുണ്ട്. ഈ പിശകുകൾ പ്രത്യേകിച്ച് സമ്മർദ്ദത്തിലുള്ളപ്പോൾ സംഭവിക്കുന്നു.
- DNS റെക്കോർഡുകൾ proxied ആക്കാതെ Under Attack മോഡ് സംരക്ഷണം നൽകുമെന്ന് തെറ്റായി കരുതുക.
- ഒറിജിൻ IP വിലാസം തുറന്നുവെച്ച് ഫയർവാൾ ക്രമീകരിക്കാതെ Cloudflare IPകൾക്ക് മാത്രമല്ലാത്ത ആക്സസ് അനുവദിക്കുക.
- API, webhook, പേയ്മെന്റ് callback URLകൾ പരിശോധിക്കാതെ മുഴുവൻ ഡൊമെയ്നിലേക്കും challenge പ്രയോഗിക്കുക.
- വളരെ വ്യാപകമായ WAF block നിയമങ്ങൾ എഴുതിച്ച് യഥാർത്ഥ ഉപയോക്താക്കളെ തടയുക.
- കാർട്ട്, പേയ്മെന്റ്, ഉപയോക്തൃ പാനൽ പേജുകൾ കാഷെ ചെയ്യേണ്ട കാര്യമില്ലെന്നത് മറക്കുക.
- ആക്രമണം കഴിഞ്ഞ് മോഡ് ആഴ്ചകളോളം അടച്ചിടാതെ വയ്ക്കുക.
- സെർവർ ലോഗുകൾ പരിശോധിക്കാതെ മാത്രം Cloudflare ഡാഷ്ബോർഡ് നോക്കി തീരുമാനമെടുക്കുക.
പ്രത്യേകിച്ച് ഇ-കൊമേഴ്സ് സൈറ്റുകളിൽ പേയ്മെന്റ് callback തടയൽ വലിയ വരുമാന നഷ്ടത്തിന് കാരണമാകാം. അതിനാൽ സുരക്ഷാ നിയമങ്ങൾ എഴുതുമ്പോൾ ആദ്യം ലോക്ക് അല്ലെങ്കിൽ managed challenge ഉപയോഗിച്ച് പരീക്ഷിച്ച്, ഫലങ്ങൾ കണ്ടു ശേഷം ശക്തമായ നടപടി സ്വീകരിക്കുക.
Hostragons ഇന്ഫ്രാസ്ട്രക്ചറിൽ കൂടുതൽ ശക്തമായ പ്രതിരോധം രൂപപ്പെടുത്തൽ
Cloudflare ശക്തമായ ഒരു മുൻനിര പാളി നൽകുന്നു; എന്നാൽ വിജയകരമായ DDoS പ്രതിരോധം CDN ഭാഗത്തേ മാത്രം ഒതുങ്ങുന്നില്ല. ഹോസ്റ്റിംഗ് ഇന്ഫ്രാസ്ട്രക്ചർ, സോഫ്റ്റ്വെയർ ഓപ്റ്റിമൈസേഷൻ, SSL ക്രമീകരണം, DNS മാനേജുമെന്റ്, ബാക്കപ്പ് തന്ത്രങ്ങൾ എന്നിവ ഒരുമിച്ച് പരിഗണിക്കണം. Hostragons-ൽ ഹോസ്റ്റുചെയ്യുന്ന സൈറ്റിനായി അടിസ്ഥാന സമീപനം ഇങ്ങനെ ആയിരിക്കണം: Cloudflare ട്രാഫിക് ഫിൽട്ടർ ചെയ്യുക, ഹോസ്റ്റിംഗ് പാളി ശുദ്ധമായ ട്രാഫിക്ക് മാത്രം സ്വീകരിക്കുക, ആപ്ലിക്കേഷൻ അനാവശ്യ ഡാറ്റാബേസ് ഭാരം ഉണ്ടാക്കാതെ ഓപ്റ്റിമൈസ് ചെയ്യുക.
പുതിയ പ്രൊജക്ട് ആരംഭിക്കുന്നതിന് മുമ്പ് ഡൊമെയ്ൻ ശരിയായ DNS റെക്കോർഡുകളോടെ നിയന്ത്രിക്കുക, SSL സർട്ടിഫിക്കറ്റ് പ്രശ്നമില്ലാതെ ഇൻസ്റ്റാൾ ചെയ്യുക, വെബ് സെർവർ വിഭവങ്ങൾ ട്രാഫിക് പ്രൊഫൈലിനനുസരിച്ച് തിരഞ്ഞെടുക്കുക പ്രധാനമാണ്. ഈ ഘട്ടത്തിൽ ഡൊമെയ്ൻ പരിശോധനയും ഡൊമെയ്ൻ രജിസ്റ്റർ, വെബ് ഹോസ്റ്റിംഗ് പാക്കേജുകൾ, കോർപ്പറേറ്റ് ഹോസ്റ്റിംഗ് പരിഹാരങ്ങൾ, ഊർജ്ജിത SSL സർട്ടിഫിക്കറ്റ് എന്നിവ ഉപകാരപ്രദമാണ്.
ഉയർന്ന ട്രാഫിക് അല്ലെങ്കിൽ ആക്രമണ സാധ്യതയുള്ള പ്രൊജക്ടുകളിൽ സ്റ്റാൻഡേഡ് ഷെയർഡ് ഹോസ്റ്റിംഗിനുപകരം നിയന്ത്രിത VPS അല്ലെങ്കിൽ മാനേജുചെയ്ത സെർവർ ഓപ്ഷനുകൾ പരിഗണിക്കുക. ഇതിലൂടെ ഫയർവാൾ, വെബ് സെർവർ, PHP-FPM, Redis, ഒബ്ജക്ട് കാഷെ, ഡാറ്റാബേസ് ക്രമീകരണങ്ങൾ കൂടുതൽ მოქലമായ രീതിയിൽ ചെയ്യാവുന്നതാണ്. എന്നാൽ ഏത് ഇന്ഫ്രാസ്ട്രക്ചർ തിരഞ്ഞെടുക്കുകയായാലും Cloudflare Under Attack മോഡ് അടിയന്തര ഉപകരണമായി മാത്രം കാണണം; സ്ഥിരതയുള്ള സുരക്ഷ WAF, ലോഗ് വിശകലനം, പതിവ് അപ്ഡേറ്റുകൾ എന്നിവകൊണ്ടു നൽകണം.
വേഗത്തിലുള്ള പരിശോധന പട്ടിക: DDoS ആക്രമണത്തിന്റെ ആദ്യ 15 മിനിറ്റ്
ആക്രമണ സമയത്ത് സമയം വളരെ വിലപ്പെട്ടതാണ്. താഴെ നൽകിയിരിക്കുന്ന പട്ടിക ടെക്നിക്കൽ ടീം അല്ലെങ്കിൽ സൈറ്റ് ഉടമ ആദ്യ 15 മിനിറ്റിൽ ചെയ്യേണ്ട കാര്യങ്ങൾ സംഗ്രഹിക്കുന്നു.
- Cloudflare പാനലിൽ പ്രവേശിച്ച് ശരിയായ ഡൊമെയ്ൻ തിരഞ്ഞെടുക്കുക.
- DNS റെക്കോർഡുകൾ proxied (ഓറഞ്ച് മേഘം) ആണെന്ന് പരിശോധിക്കുക.
- Under Attack മോഡ് സജീവമാക്കുക.
- പ്രധാന പേജ്, ലോഗിൻ, കാർട്ട്, പേയ്മെന്റ്, API എൻഡ്പോയിന്റുകൾ പരിശോദിക്കുക.
- Cloudflare Security Events-ൽ ലക്ഷ്യമിട്ട URLകൾ കണ്ടെത്തുക.
- ഏറ്റവും അധികം ആക്രമണമേറ്റ പാതകൾക്ക് WAF അല്ലെങ്കിൽ Rate Limiting നിയമങ്ങൾ ചേർക്കുക.
- സെർവർ CPU, RAM, PHP-FPM, MySQL നില പരിശോധിക്കുക.
- ഒറിജിൻ IP-യുടെ നേരിട്ടുള്ള ആക്സസ് ഉണ്ടോ എന്ന് പരിശോധിക്കുക.
- പേയ്മെന്റ് പ്രൊവൈഡർ, webhook, മറ്റു നിർണായക ഇന്റഗ്രേഷനുകൾക്ക് allowlist ആവശ്യമുണ്ടോ പരിശോധിക്കുക.
- എല്ലാ നടപടികളും സമയത്തോടുകൂടി രേഖപ്പെടുത്തുക.
ഈ പട്ടിക നിത്യമായി പരിശീലിച്ചാൽ യഥാർത്ഥ ആക്രമണം സമയത്ത് പാനിക് കുറയും, ഇടപെടൽ ഗുണമേന്മ ഉയരും. വലിയ സൈറ്റുകളിൽ ഇത് ഒരു സമഗ്രമായ സംഭവം ഇടപെടൽ പദ്ധതിയായി രേഖപ്പെടുത്തുന്നത് ശുപാർശ ചെയ്യപ്പെടുന്നു.
തടഞ്ഞുപോന്ന ചോദ്യങ്ങൾ
Cloudflare Under Attack മോഡ് സൈറ്റിനെ പൂർണ്ണമായി സംരക്ഷിക്കുമോ?
ഇല്ല. Cloudflare Under Attack മോഡ് HTTP/HTTPS തലത്തിലുള്ള ബോട്ട്, ഫ്ലഡ് ട്രാഫിക് കുറയ്ക്കുന്നതിൽ ഫലപ്രദമാണ്; പക്ഷേ ഒറ്റയ്ക്ക് പൂർണ്ണ സംരക്ഷണം നൽകുന്നില്ല. DNS proxied ആയിരിക്കണം, ഒറിജിൻ IP മറച്ചിരിക്കണം, WAF, Rate Limiting, Cache, സെർവർ ഫയർവാൾ ക്രമീകരണങ്ങൾ എന്നിവയോടൊപ്പം ഉപയോഗിക്കണം.
Under Attack മോഡ് SEOയെ ബാധിക്കുമോ?
തൽക്കാലികമായി ഉപയോഗിക്കുമ്പോൾ വലിയ SEO പ്രശ്നങ്ങൾ ഉണ്ടാകില്ല. പക്ഷേ മോഡ് നീണ്ടകാലം ഓണാക്കിയാൽ സെർച്ച് എഞ്ചിൻ ക്രോളിംഗ് കാര്യക്ഷമതയും ഉപയോക്തൃ അനുഭവവും ബാധിക്കാം. അതിനാൽ ആക്രമണം കഴിഞ്ഞ് മോഡ് ഓഫ് ചെയ്ത് ലക്ഷ്യമിട്ട സുരക്ഷാ നിയമങ്ങൾക്കൊപ്പം തുടരണം.
Under Attack മോഡ് എത്രകാലം ഓണാവണം?
ആക്രമണം കുറഞ്ഞു സാധാരണ ട്രാഫിക് നിലയിലേക്ക് മടങ്ങുന്നത് വരെ ഓണാവാം; സാധാരണയായി ട്രാഫിക് സാധാരണയാകുന്നതിനു ശേഷം കുറഞ്ഞത് 30-60 മിനിറ്റ് നിരീക്ഷിച്ച് ശേഷം ക്രമീകരണം പടിപടിയായി ഓഫ് ചെയ്യുക ഉത്തമം. മോഡ് ഓഫ് ചെയ്യുന്നതിന് മുമ്പ് WAF, Rate Limiting പോലുള്ള സ്ഥിരതയുള്ള നിയമങ്ങൾ ഒരുക്കിയിരിക്കണം.
Under Attack മോഡ് API അല്ലെങ്കിൽ പേയ്മെന്റ് സിസ്റ്റങ്ങൾ ബാധിക്കുമോ?
അതെ, ചില API ക്ലയന്റുകൾ, webhook സേവനങ്ങൾ, പേയ്മെന്റ് callback സിസ്റ്റങ്ങൾ ബ്രൗസർ അടിസ്ഥാനത്തിലുള്ള സുരക്ഷാ പരിശോധന പൂർത്തിയാക്കാൻ കഴിയാതെ പരാജയപ്പെടാൻ സാധ്യതയുണ്ട്. അതിനാൽ നിർണായക എൻഡ്പോയിന്റുകൾ പരിശോധിച്ച് allowlist അല്ലെങ്കിൽ പ്രത്യേക Cloudflare നിയമങ്ങൾ സജ്ജമാക്കണം.
Cloudflare ഉപയോഗിക്കുമ്പോൾ ഹോസ്റ്റിംഗ് ഭാഗത്ത് അധിക സുരക്ഷാ നടപടികൾ ആവശ്യമാണ്?
അതെ. Cloudflare മുൻനിര സുരക്ഷ നൽകുന്നെങ്കിലും ഒറിജിൻ സെർവറിന്റെ IP വിലാസം മറച്ചുവെക്കണം, ഫയർവാൾ ആവശ്യമായ ട്രാഫിക്കിനുതന്നെ അനുമതി നൽകണം, സോഫ്റ്റ്വെയർ അപ്ഡേറ്റ് ചെയ്യണം, കാഷെ ശരിയായി ക്രമീകരിക്കണം. സുരക്ഷിതമായ ഹോസ്റ്റിംഗ് ഇൻഫ്രാസ്ട്രക്ചർ DDoS പ്രതിരോധത്തിന് അനിവാര്യമാണ്.
സംക്ഷേപം
Cloudflare Under Attack മോഡ് DDoS ആക്രമണത്തിൽപ്പെട്ട സൈറ്റിന് വേഗത്തിലുള്ള, ഫലപ്രദമായ ഒരു അടിയന്തര സുരക്ഷാ ഉപാധിയാണ്. ശരിയായ DNS പ്രോക്സി ക്രമീകരണത്തോടെ ഇത് ബോട്ട് ട്രാഫിക് കുറയ്ക്കുകയും സെർവർ ലോഡ് മന്ദഗതിയാക്കുകയും യഥാർത്ഥ ഉപയോക്താക്കളുടെ സൈറ്റിലേക്കുള്ള പ്രവേശനം ഉറപ്പാക്കുകയും ചെയ്യുന്നു. മികച്ച ഫലം ലഭിക്കാൻ ഈ മോഡ് WAF നിയമങ്ങൾ, Rate Limiting, കാഷെ ഓപ്റ്റിമൈസേഷൻ, ഒറിജിൻ ഫയർവാൾ സുരക്ഷ എന്നിവയോടൊപ്പം ചേർന്ന് ഉപയോഗിക്കണം.
നിങ്ങളുടെ വെബ് സൈറ്റ് ആക്രമണങ്ങളിൽ നിന്നും കൂടുതൽ പ്രതിരോധശേഷിയുള്ളതായിരിക്കാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ, DNS മാനേജുമെന്റ്, SSL ക്രമീകരണങ്ങൾ എന്നിവ സ്ഥിരമായി പരിശോധിക്കുക. Hostragons-ന്റെ ഹോസ്റ്റിംഗ്, ഡൊമെയ്ൻ, SSL പരിഹാരങ്ങൾ പരിശോധിച്ച് നിങ്ങളുടെ സൈറ്റിന് കൂടുതൽ സുരക്ഷിതവും സ്ഥിരതയുള്ളതുമായ അടിസ്ഥാനവും സൃഷ്ടിക്കാം.