വീഴ്ത്തപ്പെട്ട ഒരു വെബ് ഗേറ്റ്‌വേയ്ക്ക് ഇപ്പോഴും എവിടെവരെ എത്താനാകും?
വെബ് ഗേറ്റ്‌വേ സന്ദർശകൻ എന്ത് തുറക്കുന്നു എന്ന് പരിമിതപ്പെടുത്തുന്നു, വീഴ്ത്തപ്പെട്ട ഹോസ്റ്റിന് എവിടെ ബന്ധിപ്പിക്കാനാകും എന്നല്ല. രണ്ട് അവലോകനങ്ങൾ, ഒരു അധികാര പട്ടിക, എത്തിച്ചേരൽ അളക്കാനുള്ള കമാൻഡുകൾ.
ഗേറ്റ്‌വേ ഹോസ്റ്റിന്റെ സർട്ടിഫിക്കറ്റ് ഇപ്പോഴും സാധുവായിരിക്കെ അത് വീഴ്ത്തപ്പെട്ടു എന്ന് കരുതുക. സന്ദർശകന് ഏത് പേജുകൾ അഭ്യർത്ഥിക്കാം എന്ന് നിയന്ത്രിച്ച ഓരോ നിയമവും നിലവിലുണ്ട്, ആ നിയമങ്ങളിൽ ഒന്നും ആക്രമണകാരി ഇപ്പോൾ ആ ഹോസ്റ്റിൽ നിന്ന് ഡാറ്റാബേസ് സബ്നെറ്റിലേക്ക് തുറക്കുന്ന കണക്ഷനെ പരിമിതപ്പെടുത്തുന്നില്ല. ഈ വിടവാണ് വെബ്-മാത്ര പ്രവേശന കേന്ദ്രം വിഭജിത ശൃംഖലയല്ല എന്നതിന് കാരണം. രണ്ട് അവകാശവാദങ്ങൾക്കും വെവ്വേറെ അവലോകനങ്ങൾ വേണം, വ്യത്യസ്ത ആരംഭ പോയിന്റുകളിൽ നിന്ന്, അവയിലൊന്നും സത്യസന്ധമായി മുന്നോട്ടുവയ്ക്കാൻ.
രണ്ട് അവകാശവാദങ്ങൾ, അവയിൽ ഒന്ന് മാത്രമാണ് സന്ദർശകനിൽ നിന്ന് ആരംഭിക്കുന്നത്
ആദ്യ അവകാശവാദം ഒരു വ്യക്തിയെക്കുറിച്ചാണ്: ബ്രൗസറും സാധുവായ സെഷനുമുള്ള സന്ദർശകന് ഒരു ആപ്ലിക്കേഷൻ തുറക്കാം, മറ്റൊന്നുമില്ല. വെബ്-മാത്ര പ്രവേശന കേന്ദ്രം ആ അവകാശവാദത്തിന് നന്നായി ഉത്തരം നൽകുന്നു, കാരണം സന്ദർശകന് റൂട്ടല്ല, പേജാണ് ലഭിക്കുന്നത്. ആ ഉത്തരം വിലപ്പെട്ടതാണ്, കൂടാതെ മിക്ക ഡയഗ്രമുകളും രേഖപ്പെടുത്തുന്ന ഏക അവകാശവാദവുമാണത്.
രണ്ടാമത്തെ അവകാശവാദം ഒരു ഘടകത്തെക്കുറിച്ചാണ്: ഗേറ്റ്‌വേ അല്ലെങ്കിൽ അതിന് പിന്നിലെ ആപ്ലിക്കേഷൻ പ്രക്രിയ മറ്റൊരാളുടെ നിയന്ത്രണത്തിലാണെന്ന് അനുമാനിക്കുന്നു. ഈ അനുമാനത്തിൽ നിന്ന് ചോദ്യം ഏത് URL അനുവദനീയമാണ് എന്നതിൽ നിന്ന് പ്രക്രിയയ്ക്ക് ഇപ്പോഴും ഏത് ലക്ഷ്യസ്ഥാനങ്ങളിലേക്കും ഐഡന്റിറ്റികളിലേക്കും എത്താൻ കഴിയും എന്നതിലേക്ക് മാറുന്നു.
രണ്ട് അവകാശവാദങ്ങൾക്കും വ്യത്യസ്ത ഉടമകളുണ്ട്, വ്യത്യസ്ത തെളിവുകൾ നൽകുന്നു, സ്വതന്ത്രമായി പരാജയപ്പെടുന്നു. ഐഡന്റിറ്റി ടീമിന് സെഷൻ പരിശോധനയിലൂടെ ആദ്യത്തേത് കാണിക്കാം; രണ്ടാമത്തേതിന് നെറ്റ്‌വർക്ക് നയം, സേവന അക്കൗണ്ട് അവലോകനം, ഹോസ്റ്റ് നിയന്ത്രണങ്ങൾ എന്നിവ വേണം. സന്ദർശകന്റെ പകുതി മാത്രം രേഖപ്പെടുത്തുന്ന രൂപകൽപ്പന അവലോകന സ്ലൈഡിൽ പൂർണ്ണമായും സംഭവസമയത്ത് നേർത്തതുമായി തോന്നുന്നു, കാരണം വീഴ്ത്തലിന് ശേഷം പ്രധാനമായ നിയന്ത്രണങ്ങൾ ഒരിക്കലും പരിധിയിൽ ഉണ്ടായിരുന്നില്ല. ഏത് നിയന്ത്രണം ഏത് അവകാശവാദത്തെ പിന്തുണയ്ക്കുന്നു എന്ന് പേരിടുക, അല്ലെങ്കിൽ ഒരു ഗേറ്റ്‌വേ നിയമം രണ്ടിനും കണക്കാക്കും.
പ്രവർത്തിപ്പിച്ച ഒരു ചെലവ് സേവനം, അത് തോൽക്കുന്ന രണ്ട് വഴികൾ
ഒരു ചെലവ് സേവനം എടുക്കുക: 10.60.4.10-ലെ പൊതു ഗേറ്റ്‌വേ ജീവനക്കാരെ പ്രാമാണീകരിക്കുകയും അംഗീകരിച്ച അഭ്യർത്ഥനകൾ 8443 പോർട്ടിലെ ആപ്ലിക്കേഷൻ ശ്രോതാവിലേക്ക് അയയ്ക്കുകയും ചെയ്യുന്നു, ആ ആപ്ലിക്കേഷൻ expenses_app റോളായി 10.60.4.20:5432-ലെ ഒരു PostgreSQL ശ്രോതാവിനെ എത്തുന്നു. ജീവനക്കാർക്ക് പൊതുവായ ആന്തരിക പ്രവേശനം ലഭിക്കാൻ ഉദ്ദേശിക്കുന്നില്ല. സാധാരണ പ്രവർത്തനത്തിൽ ഡാറ്റാബേസ് ശ്രോതാവിനെ എവിടെയും പ്രസിദ്ധീകരിക്കാതെ ആപ്ലിക്കേഷൻ-നിർദ്ദിഷ്ട പ്രവേശനം രൂപകൽപ്പന യഥാർത്ഥത്തിൽ നൽകുന്നു. വിലാസങ്ങൾ പ്രധാനമാണ്, കാരണം ഈ ലേഖനത്തിലെ ഓരോ പരിശോധനയും അവ പേരിടുന്നു.
ഇപ്പോൾ ഗേറ്റ്‌വേയെ വിശ്വസ്ത ഗണത്തിൽ നിന്ന് നീക്കുക. 10.60.4.10-ന്റെ പ്രക്രിയ ആക്രമണകാരിയുടേതാകുമ്പോൾ അതിന് ഏത് ലക്ഷ്യസ്ഥാനങ്ങളിൽ എത്താനാകും? സന്ദർശകരെ പരിമിതപ്പെടുത്തിയ URL ഫിൽട്ടർ ഗേറ്റ്‌വേ ഹോസ്റ്റ് ഡാറ്റാബേസ് സബ്നെറ്റിലേക്ക് തുറക്കുന്ന കണക്ഷനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
പകരം ആപ്ലിക്കേഷൻ പ്രക്രിയ നീക്കുക, അധികാരം രൂപം മാറ്റുന്നു: expenses_app റോൾ, ആ സെർവറിന് എത്താനാകുന്ന സേവനങ്ങൾ, ആ അക്കൗണ്ടിന് വായിക്കാനാകുന്ന ഫയലുകൾ. രണ്ട് സന്ദർഭങ്ങളിലും മുൻവാതിൽ വെബ്-മാത്രമായി തുടരാം, എന്നാൽ ബാക്കെൻഡ് അതിർത്തി ഇല്ല. അതിനാൽ മുൻവാതിലിലെ ലേബൽ രണ്ട് ചോദ്യങ്ങളിൽ ഒന്നിനും ഉത്തരമല്ല.
ഓരോ കക്ഷിയും യഥാർത്ഥത്തിൽ വഹിക്കുന്ന അധികാരം മാപ്പ് ചെയ്യുക
ഉദ്ദേശിച്ച അനുമതികളായി എഴുതിയ ഒരു കരാർ രൂപകൽപ്പന നിങ്ങൾക്ക് തിരികെ ആവർത്തിക്കാൻ ശ്രമിക്കുന്നു. അത് കൈവശമുള്ള അധികാരം, അധികം നിഷേധിക്കുന്ന പരിശോധന, ആ പരിശോധനയുടെ ഉടമ എന്നിവയായി എഴുതുക, അപ്പോൾ ഓരോ വരിയും പരിശോധിക്കാവുന്നതാകും. ഈ പട്ടിക മുകളിലെ ഉദാഹരണത്തിനുള്ള നിർദ്ദേശമാണ്, ഉൽപ്പന്ന അവകാശവാദമല്ല:
| Component | Authority it actually holds | Check that proves the denial | Owner of the check |
|---|---|---|---|
| Identity provider | Issues assertions and session cookies, and holds no network path of its own | A request to the application URL without a session is redirected to the login page | Identity team |
| Public gateway host | TCP reachability to whatever its routing table and egress rules permit | An egress rule drops 10.60.4.20:5432 and the probe reports the port filtered | Network platform team |
| Application role | SQL privileges granted to expenses_app inside the expenses database | A privilege query shows no ownership or create right on any other schema | Application team |
| Database listener | Accepts connections only from the source ranges named in its host-based rules | A connection from an unlisted address is refused before authentication | Database administrator |
| Management path | Administrative access reserved for patching, monitoring and recovery | A staff workstation cannot reach the administrative port or jump through it | Platform owner |
ഉടമസ്ഥത അധികാരത്തെ പിന്തുടരുന്നു. ഐഡന്റിറ്റി ടീം അവകാശവാദങ്ങൾ, നെറ്റ്‌വർക്ക് പ്ലാറ്റ്ഫോം ടീം റൂട്ടുകൾ, ആപ്ലിക്കേഷൻ ടീം ഡാറ്റാബേസ് റോൾ, ഡാറ്റാബേസ് അഡ്മിനിസ്ട്രേറ്റർ ശ്രോതാവും അതിന്റെ ഹോസ്റ്റ് അടിസ്ഥാന നിയമങ്ങളും, പ്ലാറ്റ്ഫോം ഉടമ മാനേജ്മെന്റ് തലവും ഉടമസ്ഥാപ്പെടുന്നു. ഉടമയില്ലാത്ത നിഷേധം ഒരു രേഖയിലെ വാക്യമാണ്, നിയന്ത്രണമല്ല.
ഈ വിഭജനം ഇരട്ടി കണക്കെടുപ്പും തടയുന്നു. പോർട്ട് നിയന്ത്രണത്തിന് പട്ടിക അധികാരം പ്രകടിപ്പിക്കാനാകില്ല, ഡാറ്റാബേസ് റോളിന് ബന്ധമില്ലാത്ത സബ്നെറ്റിലേക്ക് ഹോസ്റ്റ് സോക്കറ്റ് തുറക്കുന്നത് തടയാനാകില്ല.
ഗേറ്റ്‌വേ എവിടെവരെ എത്താം എന്ന് അവകാശപ്പെടുന്നതിന് പകരം എണ്ണുക
അതിർത്തി അവകാശവാദം അതിന് പിന്നിലെ എണ്ണത്തോളം മാത്രമേ മികച്ചതാകൂ. ഗേറ്റ്‌വേ ഹോസ്റ്റിൽ മൂന്ന് കമാൻഡുകൾ റൂട്ട് തിരഞ്ഞെടുപ്പ്, തത്സമയ പരിശോധന, പുറത്തേക്കുള്ള നയം എന്നിവ ഉൾക്കൊള്ളുന്നു:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputആ ക്രമത്തിൽ ഔട്ട്പുട്ട് വായിക്കുക. 10.60.4.20 ആ ഹോസ്റ്റിൽ നിന്ന് ഒട്ടും തിരഞ്ഞെടുക്കപ്പെടുന്നുണ്ടോ എന്ന് റൂട്ട് പറയുന്നു; ശ്രോതാവ് പ്രതികരിക്കുന്നുണ്ടോ എന്ന് പരിശോധന പറയുന്നു; നിയമങ്ങളുടെ പട്ടിക നയം പാക്കറ്റ് നിർത്തുന്നുണ്ടോ അതോ അതിന്റെ വഴിയിൽ ഒരിക്കലും ഒന്നും ഉണ്ടായിരുന്നില്ലേ എന്ന് കാണിക്കുന്നു.
ആപ്ലിക്കേഷൻ ഹോസ്റ്റിൽ നിന്ന് എണ്ണം ആവർത്തിക്കുക. അവിടെ നിന്ന് ഡാറ്റാബേസ് ഭാഗം ആപ്ലിക്കേഷൻ റോളായി പ്രവർത്തിപ്പിക്കുന്ന ഒരു ക്വറിയാണ്:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'മറ്റൊരു സ്കീമ വായിക്കാനാകാത്ത റോളിന് കീഴിലുള്ള വിജയകരമായ കണക്ഷൻ ഉടമ റോളിന് കീഴിലുള്ള വിജയകരമായ കണക്ഷനിൽ നിന്ന് വ്യത്യസ്ത ഫലമാണ്. രണ്ടാമത്തേത് മാത്രമാണ് ഒരു കണ്ടെത്തൽ.
നിഷേധങ്ങൾ രേഖപ്പെടുത്തുക, തുടർന്ന് അവലോകനത്തിന് തീയതി നൽകുക
സ്വീകാര്യത ഉദ്ദേശ്യങ്ങളല്ല, ഫലങ്ങളായി എഴുതുന്നു: ജീവനക്കാരന്റെ സെഷന് ശ്രോതാവിൽ എത്താനാകില്ല, ഗേറ്റ്‌വേ ഹോസ്റ്റിന് ബന്ധമില്ലാത്ത സബ്നെറ്റിൽ എത്താനാകില്ല, ആപ്ലിക്കേഷൻ റോളിന് ഡാറ്റാബേസ് സൃഷ്ടിക്കാനാകില്ല. ഓരോന്നും പേരിട്ട ഉടമയും തീയതിയുമുള്ള വെവ്വേറെ പരിശോധനയാണ്.
നിരീക്ഷണം, പാച്ചിംഗ്, വീണ്ടെടുക്കൽ എന്നിവ അവയ്ക്കായി രൂപകൽപ്പന ചെയ്ത മാനേജ്മെന്റ് പാതയിലൂടെ എത്താവുന്നതായി നിലനിർത്തുക. സ്വന്തം ഉടമയെയും തടയുന്ന അതിർത്തി ഒരു തടസ്സമാകുന്നു, ആ തടസ്സത്തിനുള്ള സാധാരണ ആദ്യ പ്രതികരണം നിയമം വീണ്ടും വിശാലമാക്കുക എന്നതാണ്. CISA പരിധി മാർഗ്ഗനിർദ്ദേശം ന്യായീകരിക്കപ്പെട്ട പോർട്ടുകളിലേക്കും പ്രോട്ടോക്കോളുകളിലേക്കും ഇൻബൗണ്ട്, ഔട്ട്ബൗണ്ട് പ്രവേശനം പരിമിതപ്പെടുത്താൻ ആവശ്യപ്പെടുന്നു, ആന്തരിക ശൃംഖലകൾക്കിടയിലുള്ള ട്രാഫിക്ക് ഉൾപ്പെടെ, ഇത് ബാക്കെൻഡിൽ നിന്ന് ആരംഭിക്കുന്ന ദിശയാണ്, മിക്ക ഡയഗ്രമുകളും ഇത് ഒഴിവാക്കുന്നു.
അവലോകനത്തിന് തീയതി നൽകി അതിന്റെ ഉടമയെ പേരിടുക. ഗേറ്റ്‌വേ ഇമേജ്, റൂട്ടിംഗ് പട്ടിക അല്ലെങ്കിൽ ആപ്ലിക്കേഷൻ റോളിൽ ഏതെങ്കിലും മാറ്റത്തിന് ശേഷം എണ്ണവും അധികാര ക്വറിയും വീണ്ടും പ്രവർത്തിപ്പിക്കുക.