തന്റെ അക്കൗണ്ടിലെ എല്ലാ ഡൊമെയ്നുകളിലും Cloudflare-ന്റെ Bot Fight Mode ഓൺ ചെയ്തത് ഒരു മാസത്തോളം API ട്രാഫിക് തടസ്സപ്പെടുത്തിയെന്നും, ഇത് പണം നൽകി സേവനം ഉപയോഗിക്കുന്ന ഉപഭോക്താക്കൾക്ക് ഉൽപ്പന്നത്തിന്റെ പ്രധാന ഫീച്ചറുകൾ ഉപയോഗിക്കാൻ കഴിയാത്ത അവസ്ഥയുണ്ടാക്കിയെന്നും ഒരു SaaS ഡെവലപ്പർ കണ്ടെത്തി.
ഉപയോഗത്തിന്റെ അളവുകോലുകളിൽ (usage metrics) പെട്ടെന്നുണ്ടായ മാറ്റം ശ്രദ്ധിച്ചപ്പോഴാണ് ഡെവലപ്പർ ഈ പ്രശ്നം തിരിച്ചറിഞ്ഞത്. പുതിയ സൈൻ-അപ്പുകൾ വരുന്നുണ്ടെങ്കിലും, ആക്റ്റീവ് സെഷനുകൾ വർദ്ധിക്കുന്നത് നിലച്ചു. ആഴ്ചകൾ നീണ്ട കോഡ് മാറ്റങ്ങളും ഡീബഗ്ഗിംഗും നടത്തിയ ശേഷമാണ് ഒരു ചെറിയ സെക്യൂരിറ്റി ടോഗിൾ ആണ് ഇതിന് കാരണമായതെന്ന് മനസ്സിലായത്: Cloudflare-ന്റെ Bot Fight Mode, ആ SaaS-ന്റെ സ്വന്തം AWS Lambda എൻഡ്പോയിന്റിനെ ഒരു മാലീഷ്യസ് ബോട്ട് (malicious bot) ആയി കണക്കാക്കുകയും ബ്ലോക്ക് ചെയ്യുകയും ചെയ്തിരുന്നു.
ഒരു ചെറിയ സെറ്റിംഗ് എങ്ങനെ ഒരു സേവനത്തെ മുഴുവൻ തകരാറിലാക്കി
ഡെവലപ്പറുടെ സ്റ്റാക്ക് സെർവർ-ടു-സെർവർ കോളുകളെ (server-to-server calls) ആശ്രയിച്ചാണ് പ്രവർത്തിച്ചിരുന്നത്. ആധുനിക മൈക്രോ-സർവീസ് ആർക്കിടെക്ചറുകളിൽ സാധാരണയായി കാണപ്പെടുന്ന രീതിയിൽ, ഒരു ഇന്റേണൽ Lambda ഫംഗ്ഷൻ കൃത്യമായ ഇടവേളകളിൽ SaaS-ന്റെ പബ്ലിക് ഡൊമെയ്നിലേക്ക് ഡാറ്റ പോസ്റ്റ് ചെയ്യുന്നുണ്ടായിരുന്നു. ഡാറ്റാ ഹാർവെസ്റ്റിംഗിൽ നിന്ന് ഉള്ളടക്കങ്ങൾ അടങ്ങിയ സൈറ്റുകളെ സംരക്ഷിക്കുന്നതിനായി, ഓട്ടോമേറ്റഡ് സ്ക്രാപ്പർമാരെപ്പോലെ തോന്നിക്കുന്ന റിക്വസ്റ്റുകളെ Bot Fight Mode വെല്ലുവിളിക്കുകയോ ബ്ലോക്ക് ചെയ്യുകയോ ചെയ്യുന്നു.
എല്ലാ സോണുകളിലും ഈ മോഡ് ഓൺ ചെയ്തപ്പോൾ, Lambda-യുടെ ഔട്ട്ബൗണ്ട് റിക്വസ്റ്റിനെ മറ്റൊരു ഓട്ടോമേറ്റഡ് ക്ലയന്റായി Cloudflare കണക്കാക്കി. ആ റിക്വസ്റ്റ് ആപ്ലിക്കേഷനിൽ എത്തിയില്ല; ബ്ലോക്ക് നടന്നത് എഡ്ജിൽ (edge) ആയതുകൊണ്ട് SaaS-ന്റെ മോണിറ്ററിംഗ് ടൂളുകൾക്ക് ഒരു എററും കാണാൻ കഴിഞ്ഞില്ല - ട്രാഫിക് വെറുതെ അപ്രത്യക്ഷമായി. Cloudflare Workers-ലെ ഡെവലപ്പറുടെ CPU ഉപയോഗം വർദ്ധിച്ചത്, സ്വന്തം ബാക്കെൻഡിന് പകരം ഒരു എക്സ്റ്റേണൽ സ്ക്രാപ്പർ ആണ് പ്രശ്നമെന്ന് സംശയിക്കാൻ അദ്ദേഹത്തെ പ്രേരിപ്പിച്ചു.
Cloudflare ലോഗുകൾ പരിശോധിച്ചതിന് ശേഷം മാത്രമാണ് Lambda-യുടെ IP റേഞ്ചിനോട് സാമ്യമുള്ള എൻട്രികൾ "Bot Fight Mode" ബ്ലോക്ക് ചെയ്തതായി അദ്ദേഹം കണ്ടത്. ബാധിക്കപ്പെട്ട സോണുകളിൽ നിന്ന് അദ്ദേഹം ഈ ഫീച്ചർ ഓഫ് ചെയ്തു, ഉടൻ തന്നെ API ട്രാഫിക് പുനരാരംഭിക്കുകയും ഉപയോഗത്തിന്റെ അളവുകോലുകൾ സാധാരണ നിലയിലാവുകയും ചെയ്തു.
എന്തുകൊണ്ടാണ് ഈ തെറ്റ് SaaS ഓപ്പറേറ്റർമാർക്ക് പ്രധാനമാകുന്നത്
- API-കേന്ദ്രീകൃത ഉൽപ്പന്നങ്ങൾക്ക് തുറന്ന സെർവർ-ടു-സെർവർ ചാനലുകൾ ആവശ്യമാണ്. പ്രധാനപ്പെട്ട ട്രാഫിക് എന്നത് HTML, ചിത്രങ്ങൾ അല്ലെങ്കിൽ സ്റ്റാറ്റിക് അസറ്റുകൾ എന്നിവയ്ക്കായുള്ള മനുഷ്യർ നടത്തുന്ന ബ്രൗസർ റിക്വസ്റ്റുകൾ ആണെന്ന് Bot Fight Mode അനുമാനിക്കുന്നു. API-കൾ, വെബ്ഹുക്കുകൾ (webhooks), അല്ലെങ്കിൽ ഇന്റേണൽ കാൾബാക്കുകൾ എന്നിവ ഉപയോഗിക്കുന്ന SaaS പ്ലാറ്റ്ഫോമുകൾ, ആപ്ലിക്കേഷൻ ലെയറിൽ ഒരു എറർ കോഡ് പോലും കാണിക്കാതെ തന്നെ തടസ്സപ്പെടുകയോ ബ്ലോക്ക് ചെയ്യപ്പെടുകയോ ചെയ്തേക്കാം.
- ആഗോള സുരക്ഷാ ക്രമീകരണങ്ങൾ (Global security settings) എല്ലാ വർക്ക്ലോഡുകൾക്കും അനുയോജ്യമാകണമെന്നില്ല. എല്ലാ ഡൊമെയ്നുകളിലും ഒരേ Cloudflare കോൺഫിഗറേഷൻ പ്രയോഗിക്കുന്നത് എല്ലാ സൈറ്റുകളും ഒരേ രീതിയിലുള്ള ഭീഷണികൾ നേരിടുന്നവയാണെന്ന രീതിയിലാണ്. കണ്ടന്റ് സൈറ്റുകൾ, ഫോറങ്ങൾ, SaaS ബാക്കെൻഡുകൾ എന്നിവയ്ക്ക് തികച്ചും വ്യത്യസ്തമായ സുരക്ഷാ ആവശ്യങ്ങളാണുള്ളത്.
- നിശബ്ദമായ പരാജയങ്ങൾ വരുമാനത്തെ ബാധിക്കുന്നു. ബ്ലോക്ക് ചെയ്യപ്പെട്ട റിക്വസ്റ്റുകൾ ആപ്ലിക്കേഷനിൽ എത്തിത്തുടങ്ങിയതുകൊണ്ട് ഡെവലപ്പറുടെ അലേർട്ടിംഗ് സിസ്റ്റം പ്രവർത്തിച്ചില്ല. യൂസർ എൻഗേജ്മെന്റ് മെട്രിക്സിലെ കുറവ് മാത്രമാണ് പ്രശ്നത്തെക്കുറിച്ച് സൂചിപ്പിച്ചത്. എഡ്ജ്-ലെവൽ ലോഗുകൾ മുൻകൂട്ടി പരിശോധിച്ചില്ലെങ്കിൽ, സമാനമായ പ്രശ്നങ്ങൾ ശ്രദ്ധിക്കപ്പെടാതെ നിലനിൽക്കാം.
സമാനമായ അവസ്ഥ ഒഴിവാക്കാൻ ഡെവലപ്പർമാർക്ക് എന്ത് ചെയ്യാൻ കഴിയും
- ഓരോ സോണിന്റെയും ട്രാഫിക് പ്രൊഫൈൽ പരിശോധിക്കുക. Bot Fight Mode ഓൺ ചെയ്യുന്നതിന് മുമ്പ്, നിങ്ങളുടെ ഡൊമെയ്ൻ പ്രതീക്ഷിക്കുന്ന റിക്വസ്റ്റ് തരങ്ങൾ പട്ടികപ്പെടുത്തുക: മനുഷ്യർ ഉപയോഗിക്കുന്ന ബ്രൗസറുകൾ, API കോളുകൾ, വെബ്ഹുക്ക് കാൾബാക്കുകൾ, അല്ലെങ്കിൽ ഇന്റേണൽ സർവീസ് കോളുകൾ എന്നിവയാണോ എന്ന് നോക്കുക. ഇവയിൽ ഏതെങ്കിലും പ്രധാന പ്രവർത്തനങ്ങൾക്ക് അത്യാവശ്യമാണെങ്കിൽ, ആ സോണിനെ “API-first” ആയി പരിഗണിക്കുകയും ബോട്ട് മിറ്റിഗേഷൻ (bot-mitigation) ക്രമീകരണങ്ങൾ കുറയ്ക്കുകയുമാണ് വേണ്ടത്.
- മാറ്റങ്ങൾ ഒരു സ്റ്റേജിംഗ് എൻവയോൺമെന്റിൽ (staged environment) പരീക്ഷിക്കുക. ഒരു സബ്ഡൊമെയ്നിലോ സ്റ്റേജിംഗ് സോണിലോ മാത്രം സെറ്റിംഗുകൾ പ്രയോഗിക്കാൻ Cloudflare അനുവദിക്കുന്നു. മാറ്റങ്ങൾ ആഗോളതലത്തിൽ നടപ്പിലാക്കുന്നതിന് മുമ്പ്, നിയമാനുസൃതമായ ഓട്ടോമേഷൻ ഇപ്പോഴും പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പുവരുത്തുക.
- നിങ്ങളുടെ ഒബ്സർവബിലിറ്റി സ്റ്റാക്കിന്റെ (observability stack) ഭാഗമായി എഡ്ജ്-ലെവൽ ലോഗുകൾ നിരീക്ഷിക്കുക. Cloudflare-ന്റെ ഫയർവാൾ, ബോട്ട് മിറ്റിഗേഷൻ ലോഗുകൾ എന്നിവ ഒരു SIEM, Loki അല്ലെങ്കിൽ മറ്റേതെങ്കിലും അഗ്രഗേഷൻ സർവീസിലേക്ക് സ്ട്രീം ചെയ്യുക. നിശബ്ദമായ പരാജയങ്ങൾ നേരത്തെ കണ്ടെത്താൻ, ബ്ലോക്ക് ചെയ്യപ്പെട്ട റിക്വസ്റ്റുകളിലെ വർദ്ധനവും ആപ്ലിക്കേഷൻ മെട്രിക്സിലെ കുറവും തമ്മിൽ താരതമ്യം ചെയ്യുക.
- സുരക്ഷാ ക്രമീകരണങ്ങൾ മാറ്റാൻ കഴിയുന്നതാക്കുക. ഒരു ഡോക്യുമെന്റഡ് റോൾബാക്ക് പ്ലാൻ (rollback plan) സൂക്ഷിക്കുക. ഒരു പുതിയ റൂൾ അപ്രതീക്ഷിതമായ മാറ്റങ്ങൾ ഉണ്ടാക്കുന്നുണ്ടെങ്കിൽ, കോഡ് മാറ്റങ്ങൾക്കായി സമയം ചിലവഴിക്കുന്നതിന് മുമ്പ് അത് ആദ്യം ഡിസേബിൾ ചെയ്യുകയും മാറ്റം സ്ഥിരീകരിക്കുകയും ചെയ്യുക.
- ശരിയായ ചോദ്യം ചോദിക്കുക. “എനിക്ക് എങ്ങനെ സ്ക്രാപ്പർമാരെ തടയാം?” എന്ന് ചോദിക്കുന്നതിന് പകരം “ഞാൻ നേരിടുന്ന പ്രത്യേക പ്രശ്നം പരിഹരിക്കാൻ ഈ ടൂൾ സഹായിക്കുമോ?” എന്ന് ചോദിക്കുക. സ്ക്രാപ്പർമാരെ തടയുന്ന ഒരു സുരക്ഷാ ഫീച്ചർ, തുറന്ന API ആക്സസ് ആവശ്യമുള്ള ഒരു SaaS-ന് അനുയോജ്യമായ ഉത്തരമാകണമെന്നില്ല.
വിശാലമായ കാഴ്ചപ്പാട്
ആക്രമണകാരികളായ ക്രോളർമാരിൽ (crawlers) നിന്ന് സ്റ്റാറ്റിക് കണ്ടന്റ് സംരക്ഷിക്കേണ്ട സൈറ്റുകൾക്ക് Bot Fight Mode ഇപ്പോഴും മൂല്യമുള്ളതാണ്. എന്നാൽ, ഒരു ഹൊസ്റ്റൈൽ സ്ക്രാപ്പറിനെയും ഒരേ HTTP പാറ്റേണുകൾ പിന്തുടരുന്ന നിയമാനുസൃതമായ ഓട്ടോമേറ്റഡ് ക്ലയന്റിനെയും തിരിച്ചറിയാൻ ഇതിന് കഴിയില്ല എന്നതാണ് ഇതിന്റെ പോരായ്മ.
ചുരുക്കത്തിൽ
ഒരു സിംഗിൾ Cloudflare അക്കൗണ്ടിന് കീഴിൽ ഒന്നിലധികം ഡൊമെയ്നുകൾ മാനേജ് ചെയ്യുമ്പോൾ, ഓരോന്നിനെയും വ്യത്യസ്തമായ സുരക്ഷാ സോണുകളായി പരിഗണിക്കുക. ട്രാഫിക് പൂർണ്ണമായും മനുഷ്യർ നടത്തുന്നതാണെങ്കിൽ മാത്രം Bot Fight Mode ഓൺ ചെയ്യുക; API-കൾക്ക് പ്രാധാന്യമുള്ള SaaS വർക്ക്ലോഡുകൾക്കായി, ഈ സെറ്റിംഗ് ഓഫ് ചെയ്യുകയോ അല്ലെങ്കിൽ കസ്റ്റം ഫയർവാൾ റൂളുകൾ ഉപയോഗിച്ച് ക്രമീകരിക്കുകയോ ചെയ്യുക. ഒരു ക്ലിക്ക് കൊണ്ട് സ്ക്രാപ്പർമാരെ തടയുന്നതുപോലെ തന്നെ ഫലപ്രദമായി നിയമാനുസൃതമായ ട്രാഫിക്കിനെയും നിങ്ങൾക്ക് നിശബ്ദമാക്കാൻ സാധിക്കും.