ഞങ്ങളുടെ ക്ലയന്റുകളുടെ പ്രവർത്തനത്തിൽ "മൂന്നാം കക്ഷികൾ" എങ്ങനെ ഇടപെടാൻ ശ്രമിച്ചു, ഈ പ്രശ്നം എങ്ങനെ പരിഹരിച്ചു എന്നതിനെക്കുറിച്ചുള്ള ഒരു രസകരമായ കഥ നമുക്ക് പറയാം.
എല്ലാം എങ്ങനെ ആരംഭിച്ചു
മാസത്തിന്റെ അവസാന ദിവസമായ ഒക്ടോബർ 31 ന് രാവിലെയാണ് ഇതെല്ലാം ആരംഭിച്ചത്, അടിയന്തിരവും പ്രധാനപ്പെട്ടതുമായ പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ പലർക്കും സമയം ആവശ്യമാണ്.
ഞങ്ങളുടെ ക്ലൗഡിൽ സേവനമനുഷ്ഠിക്കുന്ന ക്ലയന്റുകളുടെ നിരവധി വെർച്വൽ മെഷീനുകൾ സൂക്ഷിക്കുന്ന പങ്കാളികളിൽ ഒരാൾ, 9:10 മുതൽ 9:20 വരെ ഞങ്ങളുടെ ഉക്രേനിയൻ സൈറ്റിൽ പ്രവർത്തിക്കുന്ന നിരവധി വിൻഡോസ് സെർവറുകൾ റിമോട്ട് ആക്സസ് സേവനത്തിലേക്കുള്ള കണക്ഷനുകൾ സ്വീകരിക്കുന്നില്ലെന്ന് റിപ്പോർട്ട് ചെയ്തു, ഉപയോക്താക്കൾക്ക് കഴിഞ്ഞില്ല അവരുടെ ഡെസ്‌ക്‌ടോപ്പുകളിലേക്ക് ലോഗിൻ ചെയ്യാൻ, എന്നാൽ കുറച്ച് മിനിറ്റുകൾക്ക് ശേഷം പ്രശ്നം സ്വയം പരിഹരിച്ചതായി തോന്നി.
ആശയവിനിമയ ചാനലുകളുടെ പ്രവർത്തനത്തെക്കുറിച്ചുള്ള സ്ഥിതിവിവരക്കണക്കുകൾ ഞങ്ങൾ ഉയർത്തി, പക്ഷേ ട്രാഫിക് കുതിച്ചുചാട്ടങ്ങളോ പരാജയങ്ങളോ കണ്ടെത്തിയില്ല. കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങളിലെ ലോഡിനെക്കുറിച്ചുള്ള സ്ഥിതിവിവരക്കണക്കുകൾ ഞങ്ങൾ പരിശോധിച്ചു - അപാകതകളൊന്നുമില്ല. അതെന്തായിരുന്നു?
ഞങ്ങളുടെ ക്ലൗഡിൽ നൂറോളം സെർവറുകൾ കൂടി ഹോസ്റ്റുചെയ്യുന്ന മറ്റൊരു പങ്കാളി, അവരുടെ ചില ക്ലയന്റുകൾ രേഖപ്പെടുത്തിയ അതേ പ്രശ്നങ്ങൾ റിപ്പോർട്ടുചെയ്‌തു, കൂടാതെ പൊതുവെ സെർവറുകൾ ആക്സസ് ചെയ്യാവുന്നതാണെന്ന് തെളിഞ്ഞു (പിംഗ് ടെസ്റ്റിനോടും മറ്റ് അഭ്യർത്ഥനകളോടും ശരിയായി പ്രതികരിക്കുന്നു), പക്ഷേ ഈ സെർവറുകളിലെ സർവീസ് റിമോട്ട് ആക്സസ് ഒന്നുകിൽ പുതിയ കണക്ഷനുകൾ സ്വീകരിക്കുകയോ നിരസിക്കുകയോ ചെയ്യുന്നു, ഞങ്ങൾ വ്യത്യസ്ത സൈറ്റുകളിലെ സെർവറുകളെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്, വ്യത്യസ്ത ഡാറ്റാ ട്രാൻസ്മിഷൻ ചാനലുകളിൽ നിന്നുള്ള ട്രാഫിക്.
ഈ ട്രാഫിക്ക് നോക്കാം. കണക്ഷൻ അഭ്യർത്ഥനയുള്ള ഒരു പാക്കറ്റ് സെർവറിൽ എത്തുന്നു:
xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
സെർവറിന് ഈ പാക്കറ്റ് ലഭിക്കുന്നു, പക്ഷേ കണക്ഷൻ നിരസിക്കുന്നു:
xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0
ഇതിനർത്ഥം, അടിസ്ഥാന സൗകര്യങ്ങളുടെ പ്രവർത്തനത്തിലെ എന്തെങ്കിലും പ്രശ്നങ്ങൾ കൊണ്ടല്ല, മറിച്ച് മറ്റെന്തെങ്കിലും കാരണമാണ് പ്രശ്നം ഉണ്ടാകുന്നത്. ഒരുപക്ഷേ എല്ലാ ഉപയോക്താക്കൾക്കും റിമോട്ട് ഡെസ്ക്ടോപ്പ് ലൈസൻസിംഗിൽ പ്രശ്നങ്ങളുണ്ടോ? ഒരുപക്ഷേ ഏതെങ്കിലും തരത്തിലുള്ള ക്ഷുദ്രവെയറുകൾ അവരുടെ സിസ്റ്റങ്ങളിൽ തുളച്ചുകയറാൻ കഴിഞ്ഞു, രണ്ട് വർഷങ്ങൾക്ക് മുമ്പുള്ളതുപോലെ ഇന്ന് അത് സജീവമാക്കി. എക്സ്ഡാറ്റ и പെത്യ?
ഞങ്ങൾ ഇത് പരിഹരിക്കുന്നതിനിടയിൽ, നിരവധി ക്ലയന്റുകളിൽ നിന്നും പങ്കാളികളിൽ നിന്നും ഞങ്ങൾക്ക് സമാനമായ അഭ്യർത്ഥനകൾ ലഭിച്ചു.
ഈ മെഷീനുകളിൽ യഥാർത്ഥത്തിൽ എന്താണ് സംഭവിക്കുന്നത്?
ഇവന്റ് ലോഗുകളിൽ പാസ്‌വേഡ് ഊഹിക്കാനുള്ള ശ്രമങ്ങളെക്കുറിച്ചുള്ള സന്ദേശങ്ങൾ നിറഞ്ഞിരിക്കുന്നു:
സാധാരണഗതിയിൽ, വിദൂര ആക്സസ് സേവനത്തിനായി സ്റ്റാൻഡേർഡ് പോർട്ട് (3389) ഉപയോഗിക്കുന്ന എല്ലാ സെർവറുകളിലും ഇത്തരം ശ്രമങ്ങൾ രജിസ്റ്റർ ചെയ്യപ്പെടുകയും എല്ലായിടത്തുനിന്നും ആക്സസ് അനുവദിക്കുകയും ചെയ്യുന്നു. ലഭ്യമായ എല്ലാ കണക്ഷൻ പോയിന്റുകളും നിരന്തരം സ്കാൻ ചെയ്യുകയും പാസ്‌വേഡ് ഊഹിക്കാൻ ശ്രമിക്കുകയും ചെയ്യുന്ന ബോട്ടുകൾ ഇന്റർനെറ്റിൽ നിറഞ്ഞിരിക്കുന്നു (അതുകൊണ്ടാണ് "123" എന്നതിന് പകരം സങ്കീർണ്ണമായ പാസ്‌വേഡുകൾ ഉപയോഗിക്കാൻ ഞങ്ങൾ ശക്തമായി ശുപാർശ ചെയ്യുന്നത്). എന്നിരുന്നാലും, അന്ന് ഈ ശ്രമങ്ങളുടെ തീവ്രത വളരെ കൂടുതലായിരുന്നു.
എങ്ങനെ മുന്നോട്ട് പോകും?
നിരവധി അന്തിമ ഉപയോക്താക്കൾക്ക് മറ്റൊരു പോർട്ടിലേക്ക് മാറുന്നതിനായി ഉപഭോക്താക്കൾ ക്രമീകരണങ്ങൾ മാറ്റാൻ ധാരാളം സമയം ചെലവഴിക്കണമെന്ന് ശുപാർശ ചെയ്യുന്നുണ്ടോ? ഒരു നല്ല ആശയമല്ല, ഉപഭോക്താക്കൾ സന്തുഷ്ടരായിരിക്കില്ല. VPN വഴി മാത്രം ആക്സസ് അനുവദിക്കാൻ ശുപാർശ ചെയ്യുന്നുണ്ടോ? തിരക്കിലും പരിഭ്രാന്തിയിലും, IPSec കണക്ഷനുകൾ ഉയർത്താത്തവർക്കായി ഉയർത്തുന്നു - ഒരുപക്ഷേ അത്തരം സന്തോഷം ക്ലയന്റുകളിലും പുഞ്ചിരിക്കില്ല. എന്തായാലും, ഇത് ഒരു ദൈവിക കാര്യമാണെങ്കിലും, ഒരു സ്വകാര്യ നെറ്റ്‌വർക്കിൽ സെർവർ മറയ്ക്കാൻ ഞങ്ങൾ എപ്പോഴും ശുപാർശ ചെയ്യുന്നു, കൂടാതെ ക്രമീകരണങ്ങളിൽ സഹായിക്കാൻ ഞങ്ങൾ തയ്യാറാണ്, കൂടാതെ ഇത് സ്വന്തമായി മനസിലാക്കാൻ ആഗ്രഹിക്കുന്നവർക്കായി ഞങ്ങൾ നിർദ്ദേശങ്ങൾ പങ്കിടുന്നു. ഞങ്ങളുടെ ക്ലൗഡിൽ IPSec/L2TP സജ്ജീകരിക്കുന്നതിന് സൈറ്റ്-ടു-സൈറ്റ് അല്ലെങ്കിൽ റോഡ് മോഡ് -വാരിയർ, കൂടാതെ ആരെങ്കിലും സ്വന്തം വിൻഡോസ് സെർവറിൽ ഒരു VPN സേവനം സജ്ജീകരിക്കാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, എങ്ങനെ സജ്ജീകരിക്കാം എന്നതിനെക്കുറിച്ചുള്ള നുറുങ്ങുകൾ പങ്കിടാൻ അവർ എപ്പോഴും തയ്യാറാണ്. സാധാരണ RAS അല്ലെങ്കിൽ OpenVPN. പക്ഷേ, ഞങ്ങൾ എത്ര ശാന്തരായിരുന്നാലും, ഉപയോക്താക്കൾക്ക് കുറഞ്ഞ സമ്മർദത്തോടെ കഴിയുന്നത്ര വേഗത്തിൽ പ്രശ്നം പരിഹരിക്കേണ്ടതിനാൽ, ക്ലയന്റുകൾക്കിടയിൽ വിദ്യാഭ്യാസ പ്രവർത്തനങ്ങൾ നടത്താനുള്ള ഏറ്റവും നല്ല സമയമായിരുന്നില്ല ഇത്.
ഞങ്ങൾ നടപ്പിലാക്കിയ പരിഹാരം ഇപ്രകാരമായിരുന്നു. പോർട്ട് 3389-ലേക്ക് ഒരു TCP കണക്ഷൻ സ്ഥാപിക്കാനുള്ള എല്ലാ ശ്രമങ്ങളും നിരീക്ഷിക്കാനും അതിൽ നിന്ന് 150 സെക്കൻഡിനുള്ളിൽ, ഞങ്ങളുടെ നെറ്റ്‌വർക്കിലെ 16-ലധികം വ്യത്യസ്ത സെർവറുകളുമായി കണക്ഷനുകൾ സ്ഥാപിക്കാൻ ശ്രമിക്കുന്ന വിലാസങ്ങൾ തിരഞ്ഞെടുക്കാനും കഴിയുന്ന തരത്തിൽ ട്രാഫിക് കടന്നുപോകുന്നതിന്റെ ഒരു വിശകലനം ഞങ്ങൾ സജ്ജമാക്കിയിട്ടുണ്ട്. - ഇവയാണ് ആക്രമണത്തിന്റെ ഉറവിടങ്ങൾ ( തീർച്ചയായും, ക്ലയന്റുകളിലോ പങ്കാളികളിലോ ഒരാൾക്ക് ഒരേ ഉറവിടത്തിൽ നിന്ന് നിരവധി സെർവറുകളുമായി കണക്ഷനുകൾ സ്ഥാപിക്കാൻ യഥാർത്ഥ ആവശ്യമുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് എല്ലായ്പ്പോഴും അത്തരം ഉറവിടങ്ങൾ "വൈറ്റ് ലിസ്റ്റിലേക്ക്" ചേർക്കാൻ കഴിയും. ഈ 150 സെക്കൻഡിനുള്ളിൽ ഒരു ക്ലാസ് C നെറ്റ്‌വർക്കിൽ, 32-ലധികം വിലാസങ്ങൾ തിരിച്ചറിഞ്ഞിട്ടുണ്ടെങ്കിൽ, മുഴുവൻ നെറ്റ്‌വർക്കിനെയും തടയുന്നതിൽ അർത്ഥമുണ്ട്. തടയൽ 3 ദിവസത്തേക്ക് സജ്ജീകരിച്ചിരിക്കുന്നു, ഈ സമയത്ത് തന്നിരിക്കുന്ന ഉറവിടത്തിൽ നിന്ന് ആക്രമണങ്ങളൊന്നും നടത്തിയിട്ടില്ലെങ്കിൽ, ഈ ഉറവിടം "ബ്ലാക്ക് ലിസ്റ്റിൽ നിന്ന്" സ്വയമേവ നീക്കം ചെയ്യപ്പെടും. തടയപ്പെട്ട ഉറവിടങ്ങളുടെ ലിസ്റ്റ് ഓരോ 300 സെക്കൻഡിലും അപ്ഡേറ്റ് ചെയ്യപ്പെടും.
ഈ ലിസ്റ്റ് ഈ വിലാസത്തിൽ ലഭ്യമാണ്: , അതിനെ അടിസ്ഥാനമാക്കി നിങ്ങൾക്ക് നിങ്ങളുടെ ACL-കൾ നിർമ്മിക്കാൻ കഴിയും.
അത്തരമൊരു സിസ്റ്റത്തിന്റെ സോഴ്സ് കോഡ് പങ്കിടാൻ ഞങ്ങൾ തയ്യാറാണ്; അതിൽ അമിതമായി സങ്കീർണ്ണമായ ഒന്നും തന്നെയില്ല (ഇവ അക്ഷരാർത്ഥത്തിൽ മുട്ടിൽ രണ്ട് മണിക്കൂറിനുള്ളിൽ സമാഹരിച്ച നിരവധി ലളിതമായ സ്ക്രിപ്റ്റുകളാണ്), അതേ സമയം അത് പൊരുത്തപ്പെടുത്താനും ഉപയോഗിക്കാനും കഴിയില്ല. അത്തരമൊരു ആക്രമണത്തിൽ നിന്ന് പരിരക്ഷിക്കുന്നതിന് മാത്രമല്ല, നെറ്റ്‌വർക്ക് സ്കാൻ ചെയ്യാനുള്ള ശ്രമങ്ങൾ കണ്ടെത്താനും തടയാനും:
കൂടാതെ, മോണിറ്ററിംഗ് സിസ്റ്റത്തിന്റെ ക്രമീകരണങ്ങളിൽ ഞങ്ങൾ ചില മാറ്റങ്ങൾ വരുത്തിയിട്ടുണ്ട്, ഒരു RDP കണക്ഷൻ സ്ഥാപിക്കാനുള്ള ശ്രമത്തോടുള്ള ഞങ്ങളുടെ ക്ലൗഡിലെ വെർച്വൽ സെർവറുകളുടെ ഒരു നിയന്ത്രണ ഗ്രൂപ്പിന്റെ പ്രതികരണം ഇപ്പോൾ കൂടുതൽ സൂക്ഷ്മമായി നിരീക്ഷിക്കുന്നു: പ്രതികരണം ഒരു പരിധിക്കുള്ളിൽ പിന്തുടരുന്നില്ലെങ്കിൽ രണ്ടാമതായി, ഇത് ശ്രദ്ധിക്കാനുള്ള ഒരു കാരണമാണ്.
പരിഹാരം വളരെ ഫലപ്രദമായി മാറി: ക്ലയന്റുകളിൽ നിന്നും പങ്കാളികളിൽ നിന്നും മോണിറ്ററിംഗ് സിസ്റ്റത്തിൽ നിന്നും കൂടുതൽ പരാതികളൊന്നുമില്ല. പുതിയ വിലാസങ്ങളും മുഴുവൻ നെറ്റ്‌വർക്കുകളും പതിവായി ബ്ലാക്ക്‌ലിസ്റ്റിലേക്ക് ചേർക്കുന്നു, ഇത് ആക്രമണം തുടരുന്നുവെന്ന് സൂചിപ്പിക്കുന്നു, പക്ഷേ ഞങ്ങളുടെ ക്ലയന്റുകളുടെ പ്രവർത്തനത്തെ മേലിൽ ബാധിക്കില്ല.
എണ്ണത്തിൽ സുരക്ഷിതത്വമുണ്ട്
മറ്റ് ഓപ്പറേറ്റർമാർക്കും സമാനമായ ഒരു പ്രശ്നം നേരിട്ടതായി ഇന്ന് ഞങ്ങൾ മനസ്സിലാക്കി. വിദൂര ആക്സസ് സേവനത്തിന്റെ കോഡിൽ Microsoft ചില മാറ്റങ്ങൾ വരുത്തിയതായി ആരോ ഇപ്പോഴും വിശ്വസിക്കുന്നു (നിങ്ങൾ ഓർക്കുന്നുണ്ടെങ്കിൽ, ആദ്യ ദിവസം തന്നെ ഞങ്ങൾ അതേ കാര്യം സംശയിച്ചു, പക്ഷേ ഞങ്ങൾ ഈ പതിപ്പ് വളരെ വേഗം നിരസിച്ചു) കൂടാതെ ഒരു പരിഹാരം വേഗത്തിൽ കണ്ടെത്താൻ സാധ്യമായതെല്ലാം ചെയ്യുമെന്ന് വാഗ്ദാനം ചെയ്യുന്നു . ചില ആളുകൾ പ്രശ്നം അവഗണിക്കുകയും സ്വയം പരിരക്ഷിക്കാൻ ക്ലയന്റുകളെ ഉപദേശിക്കുകയും ചെയ്യുന്നു (കണക്ഷൻ പോർട്ട് മാറ്റുക, ഒരു സ്വകാര്യ നെറ്റ്‌വർക്കിൽ സെർവർ മറയ്ക്കുക തുടങ്ങിയവ). ആദ്യ ദിവസം തന്നെ, ഞങ്ങൾ ഈ പ്രശ്നം പരിഹരിക്കുക മാത്രമല്ല, ഞങ്ങൾ വികസിപ്പിക്കാൻ ഉദ്ദേശിക്കുന്ന കൂടുതൽ ആഗോള ഭീഷണി കണ്ടെത്തൽ സംവിധാനത്തിനായി ചില അടിത്തറ സൃഷ്ടിക്കുകയും ചെയ്തു.
നിശ്ശബ്ദത പാലിക്കാതെ, ഒരു ശത്രുവിന്റെ മൃതദേഹം ഒഴുകുന്നത് കാത്ത് നദിക്കരയിൽ ഇരിക്കാതെ, പക്ഷേ ഉടൻ തന്നെ പ്രശ്നത്തിലേക്ക് ഞങ്ങളുടെ ശ്രദ്ധ ആകർഷിച്ചു, അത് ഇല്ലാതാക്കാൻ ഞങ്ങൾക്ക് അവസരം നൽകിയ ക്ലയന്റുകൾക്കും പങ്കാളികൾക്കും പ്രത്യേക നന്ദി. അത് അതേ ദിവസം തന്നെ.
അവലംബം: www.habr.com