RDP ဝန်ဆောင်မှုများအပေါ် DDoS တိုက်ခိုက်မှု- အသိအမှတ်ပြုပြီး တိုက်ခိုက်ပါ။ Tucha မှအောင်မြင်သောအတွေ့အကြုံ

ကျွန်ုပ်တို့၏ဖောက်သည်များ၏အလုပ်ကို "တတိယပါတီများ" က ဝင်ရောက်စွက်ဖက်ရန် ကြိုးစားပုံနှင့် ဤပြဿနာကို ဖြေရှင်းပုံအကြောင်း ဇာတ်လမ်းကောင်းတစ်ခု ပြောပြကြပါစို့။

အားလုံးဘယ်လိုစတင်ခဲ့တာလဲ။

လ၏နောက်ဆုံးနေ့ဖြစ်သော အောက်တိုဘာ ၃၁ ရက် နံနက်တွင် လူများစွာသည် အရေးတကြီးနှင့် အရေးကြီးသောပြဿနာများကို ဖြေရှင်းရန် အလွန်အမင်းအချိန်လိုအပ်နေချိန်ဖြစ်သည်။

ကျွန်ုပ်တို့၏ cloud တွင် ဝန်ဆောင်မှုပေးနေသော သုံးစွဲသူများ၏ virtual machines အများအပြားကို ထိန်းသိမ်းထားသည့် ပါတနာတစ်ဦးမှ 9:10 မှ 9:20 အတွင်း ကျွန်ုပ်တို့၏ ယူကရိန်းဆိုက်ပေါ်တွင် လုပ်ဆောင်နေသော Windows ဆာဗာအများအပြားသည် အဝေးမှဝင်ရောက်ခွင့်ဝန်ဆောင်မှုသို့ ချိတ်ဆက်မှုများကို လက်မခံနိုင်ကြောင်း အစီရင်ခံတင်ပြခဲ့သည်၊ အသုံးပြုသူများသည် မရနိုင်ပါ။ ၎င်းတို့၏ desktop များကို login လုပ်ရန်၊ သို့သော် မိနစ်အနည်းငယ်ကြာပြီးနောက် ပြဿနာက သူ့အလိုလို ဖြေရှင်းသွားပုံရသည်။

ဆက်သွယ်ရေးလမ်းကြောင်းများ လည်ပတ်မှုဆိုင်ရာ စာရင်းဇယားများကို ထုတ်ပြန်ခဲ့သော်လည်း ယာဉ်အသွားအလာများ မြင့်တက်လာခြင်း သို့မဟုတ် ပျက်ကွက်မှုများ မတွေ့ရှိခဲ့ပါ။ တွက်ချက်မှုဆိုင်ရာ အရင်းအမြစ်များပေါ်ရှိ စာရင်းဇယားများကို ကြည့်ရှုခဲ့သည် - ကွဲလွဲချက်များမရှိပါ။ အဲဒါ ဘာလဲ။

ထို့နောက် ကျွန်ုပ်တို့၏ cloud တွင် ဆာဗာတစ်ရာခန့်ကို လက်ခံဆောင်ရွက်ပေးသည့် အခြားလုပ်ဖော်ကိုင်ဖက်က ၎င်းတို့၏ client အချို့မှတ်သားထားသည့် အလားတူပြဿနာများကို သတင်းပို့ခဲ့ပြီး ယေဘုယျအားဖြင့် ဆာဗာများကို အသုံးပြု၍ရနိုင်သည် (ping test နှင့် အခြားတောင်းဆိုမှုများကို မှန်ကန်စွာတုံ့ပြန်ခြင်း)၊ သို့သော်၊ ဤဆာဗာများပေါ်ရှိ ဝန်ဆောင်မှုအဝေးမှဝင်ရောက်ခွင့်သည် ချိတ်ဆက်မှုအသစ်များကို လက်ခံသည် သို့မဟုတ် ၎င်းတို့ကို ငြင်းပယ်သည်ဖြစ်စေ ကျွန်ုပ်တို့သည် မတူညီသောဆိုက်များရှိ ဆာဗာများအကြောင်း၊ မတူညီသောဒေတာထုတ်လွှင့်မှုလမ်းကြောင်းများမှလာသောလမ်းကြောင်းများကို ကျွန်ုပ်တို့ပြောနေပါသည်။

ဒီလမ်းကြောင်းကို ကြည့်ရအောင်။ ချိတ်ဆက်မှုတောင်းဆိုချက်ပါသော ပက်ကတ်တစ်ခုသည် ဆာဗာသို့ရောက်ရှိသည်-

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

ဆိုလိုသည်မှာ အဆိုပါပြဿနာသည် အခြေခံအဆောက်အအုံ၏လည်ပတ်မှုတွင် ပြဿနာတစ်စုံတစ်ရာကြောင့်မဟုတ်ဘဲ အခြားအရာတစ်ခုခုကြောင့်ဖြစ်ရခြင်းဖြစ်သည်ဟု ရှင်းရှင်းလင်းလင်းသိရသည်။ အသုံးပြုသူအားလုံးသည် အဝေးထိန်း ဒက်စ်တော့လိုင်စင်ဖြင့် ပြဿနာများ ရှိနေနိုင်ပါသလား။ အချို့သော malware များသည် ၎င်းတို့၏စနစ်များကို ထိုးဖောက်ဝင်ရောက်နိုင်ခဲ့ပြီး ယနေ့တွင် ၎င်းသည် လွန်ခဲ့သောနှစ်အနည်းငယ်ကကဲ့သို့ပင် စတင်အသုံးပြုနိုင်ပြီဖြစ်သည်။ XData и ကြက်ဥ?

ကျွန်ုပ်တို့ ၎င်းကို စီစဥ်စဉ်တွင်၊ ကျွန်ုပ်တို့သည် နောက်ထပ် သုံးစွဲသူများနှင့် ပါတနာများစွာထံမှ အလားတူ တောင်းဆိုမှုများကို လက်ခံရရှိခဲ့ပါသည်။
ဒီစက်တွေမှာ တကယ်ဖြစ်ပျက်နေတာလား။

စကားဝှက်ကို ခန့်မှန်းရန် ကြိုးပမ်းမှုများအကြောင်း ဖြစ်ရပ်မှတ်တမ်းများတွင် မက်ဆေ့ခ်ျများ ပြည့်နေပါသည်-

ပုံမှန်အားဖြင့်၊ ထိုသို့သောကြိုးပမ်းမှုများကို အဝေးထိန်းဝင်ရောက်ခြင်းဝန်ဆောင်မှုအတွက် အသုံးပြုသည့် standard port (3389) ကို နေရာတိုင်းမှဝင်ရောက်ခွင့်ပြုထားသည့် ဆာဗာများအားလုံးတွင် မှတ်ပုံတင်ထားပါသည်။ အင်တာနက်တွင် ရရှိနိုင်သောချိတ်ဆက်မှုအချက်များအားလုံးကို အဆက်မပြတ်စကင်န်ဖတ်ပြီး စကားဝှက်ကို ခန့်မှန်းရန်ကြိုးစားသည့် ဘော့တ်များပြည့်နေပါသည် (ဒါကြောင့် “123” အစား ရှုပ်ထွေးသောစကားဝှက်များကို အသုံးပြုရန် ပြင်းပြင်းထန်ထန် အကြံပြုအပ်ပါသည်။ သို့သော် ထိုနေ့၏ ပြင်းထန်မှုမှာ ပြင်းထန်လွန်းလှသည်။

ဘယ်လိုဆက်လုပ်ရမလဲ။

သုံးစွဲသူများသည် အခြား port သို့ပြောင်းရန် အသုံးပြုသူအများအပြားအတွက် ဆက်တင်များကို အချိန်အတော်ကြာ ပြောင်းလဲရန် အကြံပြုလိုပါသလား။ အကြံကောင်းမဟုတ်ပါ၊ ဖောက်သည်များ ပျော်ရွှင်မည်မဟုတ်ပါ။ VPN မှတဆင့်သာ ဝင်ရောက်ခွင့်ပြုရန် အကြံပြုလိုပါသလား။ အလျင်စလို ထိတ်လန့်တကြားဖြင့်၊ ၎င်းတို့မရှိသူများအတွက် IPSec ချိတ်ဆက်မှုများကို မြှင့်တင်ပေးခြင်း - ထိုသို့သောပျော်ရွှင်မှုသည် ဖောက်သည်များအတွက်လည်း မပြုံးနိုင်ပါ။ ငါပြောရမည်ဆိုလျှင်၊ ဤအရာသည် မည်သည့်ကိစ္စတွင်မဆို ဘုရားတရားတစ်ခုဖြစ်သည်၊ ကျွန်ုပ်တို့သည် ဆာဗာကို သီးသန့်ကွန်ရက်တွင် ဝှက်ထားရန် အမြဲအကြံပြုထားပြီး ဆက်တင်များနှင့်ပတ်သက်၍ ကူညီရန် အသင့်ရှိပြီး ၎င်းကို ၎င်းတို့ဘာသာရှာဖွေလိုသူများအတွက် ကျွန်ုပ်တို့သည် ညွှန်ကြားချက်များကို မျှဝေပါသည်။ site-to-site သို့မဟုတ် road mode -warrior တွင် ကျွန်ုပ်တို့၏ cloud တွင် IPSec/L2TP ကို ​​စနစ်ထည့်သွင်းရန်နှင့်၊ မည်သူမဆို ၎င်းတို့၏ကိုယ်ပိုင် Windows server တွင် VPN ဝန်ဆောင်မှုကို စနစ်ထည့်သွင်းလိုပါက၊ ၎င်းတို့သည် စနစ်ထည့်သွင်းနည်းဆိုင်ရာ အကြံပြုချက်များကို မျှဝေရန် အမြဲအသင့်ရှိနေပါသည်။ ပုံမှန် RAS သို့မဟုတ် OpenVPN။ သို့သော် ကျွန်ုပ်တို့သည် မည်မျှပင်အေးနေပါစေ၊ သုံးစွဲသူများကြားတွင် ဖိအားအနည်းဆုံးဖြင့် ပြဿနာကို တတ်နိုင်သမျှ မြန်မြန်ဖြေရှင်းရန် လိုအပ်သောကြောင့် ဤအချိန်သည် သုံးစွဲသူများအကြား ပညာပေးလုပ်ငန်းလုပ်ဆောင်ရန် အကောင်းဆုံးအချိန်မဟုတ်ပေ။

ကျွန်ုပ်တို့ အကောင်အထည်ဖော်ခဲ့သည့် ဖြေရှင်းချက်မှာ အောက်ပါအတိုင်းဖြစ်သည်။ ပို့တ် 3389 သို့ TCP ချိတ်ဆက်မှု ထူထောင်ရန် ကြိုးပမ်းမှုအားလုံးကို စောင့်ကြည့်ရန်နှင့် စက္ကန့် 150 အတွင်း ကျွန်ုပ်တို့ကွန်ရက်ပေါ်ရှိ မတူညီသော ဆာဗာ 16 ခုထက်မနည်းနှင့် ချိတ်ဆက်မှုတည်ဆောက်ရန် ကြိုးပမ်းမှုတို့မှ လိပ်စာများကို ရွေးချယ်ရန် ဖြတ်သန်းသွားလာမှုဆိုင်ရာ ခွဲခြမ်းစိတ်ဖြာမှုအား ကျွန်ုပ်တို့ ဖန်တီးထားပါသည်။ - ဤအရာများသည် တိုက်ခိုက်မှု၏ရင်းမြစ်များဖြစ်သည် (အမှန်ပင်၊ ဖောက်သည်များ သို့မဟုတ် ပါတနာများထဲမှ တစ်ဦးသည် တူညီသောအရင်းအမြစ်မှ ဆာဗာများစွာနှင့် ချိတ်ဆက်မှုများပြုလုပ်ရန် အမှန်တကယ်လိုအပ်ပါက၊ သင်သည် ထိုအရင်းအမြစ်များကို "အဖြူစာရင်းတွင် အမြဲထည့်နိုင်သည်။" ထို့အပြင်၊ အကယ်၍ class C ကွန်ရက်တစ်ခုတွင် အဆိုပါ 150 စက္ကန့်အတွင်း လိပ်စာ 32 ခုထက်ပိုသည်ကို တွေ့ရှိပါက၊ ကွန်ရက်တစ်ခုလုံးကို ပိတ်ဆို့ရန် သင့်လျော်ပါသည်။ ပိတ်ဆို့ခြင်းအား 3 ရက်သတ်မှတ်ထားပြီး ဤအချိန်အတွင်း ပေးထားသည့်အရင်းအမြစ်မှ တိုက်ခိုက်မှုများကို မလုပ်ဆောင်ပါက၊ ဤရင်းမြစ်ကို "အမည်မည်းစာရင်းမှ အလိုအလျောက်ဖယ်ရှားပါသည်။" ပိတ်ဆို့ခံထားရသောရင်းမြစ်များစာရင်းကို စက္ကန့် 300 တိုင်း အပ်ဒိတ်လုပ်ပါသည်။

ဤစာရင်းကို ဤလိပ်စာတွင် ရနိုင်သည်- https://secure.tucha.ua/global-filter/banned/rdp_ddos၎င်းကိုအခြေခံ၍ သင်၏ ACLs ကို သင်တည်ဆောက်နိုင်သည်။

ထိုကဲ့သို့သောစနစ်၏အရင်းအမြစ်ကုဒ်ကိုမျှဝေရန်ကျွန်ုပ်တို့အဆင်သင့်ဖြစ်နေပါပြီ; ၎င်းတွင်လွန်စွာရှုပ်ထွေးမှုမရှိပါ (ဤအရာများသည်စာသားအရနာရီအနည်းငယ်ကြာအောင်ဒူးတွင်စုစည်းထားသောရိုးရှင်းသောစာတိုများဖြစ်သည်) နှင့်တစ်ချိန်တည်းတွင်၎င်းကိုလိုက်လျောညီထွေဖြစ်စေနိုင်ပြီးအသုံးမပြုနိုင်ပါ။ ထိုသို့သော တိုက်ခိုက်မှုကို ကာကွယ်ရန်သာမက ကွန်ရက်ကို စကင်န်ဖတ်ရန် ကြိုးပမ်းမှုတိုင်းကို ရှာဖွေပြီး ပိတ်ဆို့ခြင်းလည်း ဖြစ်သည်- ဤ link ကိုလိုက်နာပါ။

ထို့အပြင်၊ ကျွန်ုပ်တို့သည် RDP ချိတ်ဆက်မှုကို ထူထောင်ရန် ကြိုးပမ်းမှုတစ်ခုအဖြစ် ယခု ကျွန်ုပ်တို့၏ cloud ရှိ virtual servers ထိန်းချုပ်မှုအုပ်စု၏ တုံ့ပြန်မှုကို ပိုမိုနီးကပ်စွာ စောင့်ကြည့်သည့် စောင့်ကြည့်ရေးစနစ်၏ ဆက်တင်များကို အပြောင်းအလဲအချို့ ပြုလုပ်ထားပါသည်။ ဒုတိယအချက်မှာ ဤအချက်သည် သတိပြုရမည့်အချက်ဖြစ်သည်။

ဖြေရှင်းချက်သည် အတော်လေး ထိရောက်သည်- ဖောက်သည်များနှင့် လုပ်ဖော်ကိုင်ဖက်များထံမှ တိုင်ကြားချက်များနှင့် စောင့်ကြည့်ရေးစနစ်မှ တိုင်ကြားမှုများ မရှိတော့ပါ။ လိပ်စာအသစ်များနှင့် ကွန်ရက်တစ်ခုလုံးကို အမည်ပျက်စာရင်းတွင် ပုံမှန်ထည့်သွင်းထားသည်၊ ၎င်းသည် တိုက်ခိုက်မှုဆက်လက်ဖြစ်ပွားနေကြောင်း ညွှန်ပြသော်လည်း ကျွန်ုပ်တို့၏ဖောက်သည်များ၏အလုပ်အပေါ် သက်ရောက်မှုမရှိတော့ပါ။

နံပါတ်တွေ လုံခြုံမှုရှိတယ်။

ယနေ့တွင် အခြားသော အော်ပရေတာများသည် အလားတူပြဿနာမျိုး ကြုံတွေ့ခဲ့ရကြောင်း ကျွန်ုပ်တို့ သိရှိရပါသည်။ Microsoft သည် အဝေးထိန်းဝင်ရောက်ခြင်းဝန်ဆောင်မှု၏ကုဒ်ကို အပြောင်းအလဲအချို့ပြုလုပ်ခဲ့သည်ဟု တစ်စုံတစ်ယောက်က ယုံကြည်ဆဲဖြစ်သည် (သင်မှတ်မိပါက၊ ကျွန်ုပ်တို့သည် ပထမနေ့တွင် အလားတူသံသယရှိသော်လည်း ဤဗားရှင်းကို ကျွန်ုပ်တို့ အမြန်ပယ်ချခဲ့သည်) နှင့် အဖြေအမြန်ရှာရန် ဖြစ်နိုင်သမျှအားလုံးကို လုပ်ဆောင်မည်ဟု ကတိပြုပါသည်။ . အချို့သောလူများသည် ပြဿနာကို ရိုးရိုးရှင်းရှင်း လျစ်လျူရှုပြီး ၎င်းတို့ကိုယ်တိုင် ကာကွယ်ရန် ဖောက်သည်များအား အကြံပေးသည် (ချိတ်ဆက်မှု ပို့တ်ကို ပြောင်းလဲပါ၊ သီးသန့်ကွန်ရက်တွင် ဆာဗာကို ဝှက်ထားရန် စသည်ဖြင့်)။ ပထမနေ့တွင်၊ ကျွန်ုပ်တို့သည် ဤပြဿနာကို ဖြေရှင်းရုံသာမက၊ ကျွန်ုပ်တို့ တီထွင်ရန် စီစဉ်ထားသည့် ကမ္ဘာလုံးဆိုင်ရာ ခြိမ်းခြောက်မှု ထောက်လှမ်းခြင်းစနစ်အတွက် အခြေခံအချက်များကို ဖန်တီးခဲ့သည်။

တိတ်တိတ်ဆိတ်ဆိတ်မနေဘဲ မြစ်ကမ်းပေါ်တွင် မထိုင်ဘဲ ရန်သူ၏အလောင်းကို တစ်နေ့တွင် မျောပါလာစေရန် စောင့်မျှော်နေကြသော ဖောက်သည်များနှင့် မိတ်ဖက်များအား အထူးပင်ကျေးဇူးတင်ရှိပါသည်။ ထိုနေ့တွင်၊

source: www.habr.com