HTTP തെളിവ് തിരച്ചിൽ: ഗേറ്റ്വേ രേഖകൾ അല്ലെങ്കിൽ ആപ്പ് ലോഗുകൾ

വെബ് നിരീക്ഷണം ലക്ഷ്യത്തിൽ നിന്ന് തുടങ്ങുന്നു, പിടികൂടുന്ന ബിന്ദുവിൽ നിന്നല്ല। സജീവ ക്ലയന്റുകളെ എണ്ണൽ, API കോളിന്റെ സമയം അളക്കൽ, സന്ദേശ ബോഡികൾ വായിക്കൽ എന്നിവയ്ക്ക് ഓരോന്നിനും വ്യത്യസ്ത തെളിവും വ്യത്യസ്ത സ്വകാര്യതാ തീരുമാനങ്ങളും വേണം। സംരക്ഷിത HTTPS കൈമാറുന്ന ഗേറ്റ്വേ പേജ് ഉള്ളടക്കമല്ല, കണക്ഷനുകളാണ് കാണുന്നത്। തെറ്റായ പാളി തിരഞ്ഞെടുത്താൽ സമ്പന്നമായി തോന്നുന്നതും ഒന്നിനും ഉത്തരം നൽകാത്തതുമായ ഡാറ്റ ലഭിക്കും।

ഡാറ്റാ ഉറവിടത്തിന് മുൻപ് ചോദ്യത്തിന് പേര് നൽകുക

ഡാറ്റ പിന്തുണയ്ക്കേണ്ട ഓപ്പറേഷണൽ തീരുമാനത്തിൽ നിന്ന് തുടങ്ങുക। ലഭ്യതാ ചോദ്യങ്ങൾക്ക് എണ്ണങ്ങളും സമയങ്ങളും വേണം, അഭ്യർത്ഥനാ ചോദ്യങ്ങൾക്ക് പാതകളും സ്റ്റാറ്റസ് കോഡുകളും വേണം, ഉള്ളടക്ക ചോദ്യങ്ങൾക്ക് സന്ദേശ ബോഡികളും വേണം। ഉള്ളിലേക്കുള്ള ഓരോ ചുവടും സംവേദനക്ഷമതയും എൻജിനീയറിംഗ് സങ്കീർണ്ണതയും കൂട്ടുന്നു। ശേഖരണം തുടങ്ങുന്നതിന് മുൻപ് സേവന ഉടമയും സുരക്ഷാ ഉടമയും പ്രേക്ഷകരെയും ലക്ഷ്യത്തെയും കൈകാര്യം ചെയ്യലിനെയും അംഗീകരിക്കട്ടെ, കാരണം ടണൽ പ്രവർത്തിപ്പിക്കുന്നത് ആ തീരുമാനമല്ല।

ചോദ്യം ഒരു വാക്യത്തിൽ എഴുതി ശേഖരണ പ്ലാനിന് അരികിൽ സൂക്ഷിക്കുക। അതാണ് പരിധിയുടെ ഏക വിശ്വസനീയ നിയന്ത്രണം।

ഗേറ്റ്വേക്ക് എന്ത് കാണിക്കാം, എന്ത് കാണിക്കാനാവില്ല

ശരിയായി സംരക്ഷിത HTTPS കൈമാറുന്ന ഗേറ്റ്വേ സാധാരണയായി വിലാസങ്ങൾ, പോർട്ടുകൾ, അളവുകൾ എന്നിവ കാണുന്നു, അഭ്യർത്ഥനാ വരികളോ ബോഡികളോ അല്ല।

conntrack -L -d 203.0.113.10 | head
tcpdump -ni vpn0 -c 20 'tcp port 443'

conntrack പട്ടിക പ്രവാഹങ്ങളും വിവർത്തനങ്ങളും കാണിക്കുന്നു, ചെറിയ പിടികൂടൽ വായിക്കാവുന്ന ആപ്പ് ഉള്ളടക്കമില്ലാത്ത പാക്കറ്റുകൾ കാണിക്കുന്നു। ട്രാഫിക് ഒഴുകുന്നുണ്ടോ, എത്ര, ഏത് അന്ത്യ ബിന്ദുക്കൾക്കിടയിൽ എന്നതിന് ഉത്തരം നൽകാൻ ഇത് മതി। ഇത് URL പട്ടികയല്ല, സാധാരണ CONNECT പ്രോക്സി ആപ്പിന്റെ TLS അവസാനിപ്പിക്കാതെ എൻക്രിപ്റ്റ് ചെയ്ത കൈമാറ്റം നടത്തുന്നു। ആ സ്ഥാനത്തുനിന്ന് ആരെങ്കിലും അഭ്യർത്ഥനാ പാതകൾ വാഗ്ദാനം ചെയ്താൽ, ഏത് ഘടകം ഡീക്രിപ്റ്റ് ചെയ്യുന്നു, ആരുടെ വിശ്വാസത്തിൽ എന്ന് ചോദിക്കുക।

ആപ്പ് ലോഗുകൾ മിക്ക അഭ്യർത്ഥനാ ചോദ്യങ്ങൾക്കും ഉത്തരം നൽകുന്നു

നിങ്ങൾ പ്രവർത്തിപ്പിക്കുന്ന ആപ്പിന്, അതിന്റെ സ്വന്തം പിന്തുണയുള്ള ലോഗിംഗ് സാധാരണയായി മറ്റുള്ളവരുടെ കണക്ഷനുകൾ ഡീക്രിപ്റ്റ് ചെയ്യാതെ അഭ്യർത്ഥനാ തലത്തിലുള്ള ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു।

curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://app.example.com/health
tail -n 5 /var/log/nginx/access.log

ആരോഗ്യ അഭ്യർത്ഥന ക്ലയന്റിന്റെ സ്ഥാനത്തുനിന്ന് ലഭ്യത അളക്കുന്നു, ആക്സസ് ലോഗ് സർവർ ഇതിനകം സൂക്ഷിക്കാൻ തിരഞ്ഞെടുത്ത ഫീൽഡുകൾ രേഖപ്പെടുത്തുന്നു। ജോലിക്ക് വേണ്ട ഫീൽഡുകൾ തിരഞ്ഞെടുത്ത് ബാക്കി പുറത്ത് നിർത്തുക, കാരണം URL പോലും സംവേദനക്ഷമമായ പാരാമീറ്ററുകൾ വഹിക്കാം। ലോഗ് വരി ആ സേവനത്തെക്കുറിച്ചുള്ള തെളിവാണ്, ഉപയോക്താവ് ടണലിലൂടെ എത്തിയ മറ്റേതൊരു സേവനത്തെക്കുറിച്ചുമല്ല। ശേഖരണം ഇടുങ്ങിയതായി സൂക്ഷിക്കുന്നത് സൂക്ഷിപ്പ് ചോദ്യവും ചെറുതായി സൂക്ഷിക്കുന്നു, അതിനാൽ ആവശ്യകത സൃഷ്ടിച്ച ചിന്താ പരീക്ഷണത്തേക്കാൾ ചെറിയ ജാലകം നിശ്ചയിക്കുക।

ഇടപെടൽ വേർതിരിച്ച വിശ്വാസ രൂപകൽപ്പനയാണ്

സന്ദേശ തലത്തിലുള്ള പരിശോധന ശരിക്കും ആവശ്യമാണെങ്കിൽ, TLS ഇടപെടൽ പുതിയ വിശ്വസ്ത അന്ത്യ ബിന്ദുവും വിതരണം ചെയ്യേണ്ടതും പരിപാലിക്കേണ്ടതുമായ ക്ലയന്റ് വിശ്വാസ ക്രമീകരണവും സൃഷ്ടിക്കുന്നു। സർട്ടിഫിക്കറ്റുകൾ പിൻ ചെയ്യുന്ന ആപ്പുകൾ തകരും, ഇപ്പോൾ ഓപ്പറേറ്ററുടെ കൈവശം ഏത് സർവർ കീയോളം പ്രധാനമായ സംരക്ഷണമുള്ള സ്വകാര്യ കീകളുണ്ട്। സർട്ടിഫിക്കറ്റ് സാധുത ദുർബലമാക്കിയോ, സർട്ടിഫിക്കറ്റുകൾ പിൻ ചെയ്യുന്ന ആപ്പ് പാച്ച് ചെയ്തോ ശേഖരണം നടത്തുന്നത് സുരക്ഷാ നിയന്ത്രണം ഒരു ലോഗ് വരിക്ക് പകരം വയ്ക്കുന്നു। വിശ്വാസ വിതരണം ഇതിനകം നിയന്ത്രിക്കപ്പെടുന്ന രേഖപ്പെടുത്തിയ പരിശോധനാ രൂപകൽപ്പന ഇഷ്ടപ്പെടുക, അധികാരിയുടെ സ്വകാര്യ കീ പങ്കിടുന്ന ഒന്നിൽ നിന്നും പുറത്ത് സൂക്ഷിക്കുക।

ശേഖരണ ജാലകത്തിന്റെ അവസാനം, ഉടമകളിലൂടെ കോൺഫിഗറേഷനും അതിന്റെ വിശ്വാസ വസ്തുവും നീക്കുക, സമ്മതിച്ച നയപ്രകാരം സൂക്ഷിച്ച തെളിവുകൾ നീക്കം ചെയ്യുക। പറഞ്ഞ ലക്ഷ്യത്തിന് മതിയായ വിശ്വസനീയ വിവരമാണ് വിജയത്തിന്റെ മാനദണ്ഡം, സാധ്യമായ ഏറ്റവും വലിയ പിടികൂടലല്ല।