အေးဂျင့် "စစ်ဆေးရေးမှူး" ကို ရေတွက်ကြည့်ရအောင်။

ရုရှားနိုင်ငံရှိ တားမြစ်ထားသော အချက်အလက်စာရင်းတွင် ပိတ်ဆို့ထိန်းချုပ်မှုကို အလိုအလျောက်စနစ် “စစ်ဆေးရေးမှူး” က စောင့်ကြည့်နေသည်မှာ လျှို့ဝှက်ထားခြင်းမရှိပါ။ ဘယ်လိုအလုပ်လုပ်တယ်ဆိုတာ ဒီထဲမှာ ကောင်းကောင်းရေးထားတယ်။ Habr ဆောင်းပါးတစ်နေရာတည်းမှပုံ၊

ဝန်ဆောင်မှုပေးသူထံ တိုက်ရိုက်ထည့်သွင်းထားသည်။ module "Agent Inspector":

"Agent Inspector" module သည် အလိုအလျောက်စနစ် "Inspector" (AS "Inspector") ၏ ဖွဲ့စည်းပုံဆိုင်ရာ အစိတ်အပိုင်းတစ်ခုဖြစ်သည်။ ဤစနစ်ကို ဇူလိုင်လ ၂၇ ရက်၊ ၂၀၀၆ ခုနှစ် ဇူလိုင်လ ၂၇ ရက်၊ ၂၀၀၆ ခုနှစ် ဖက်ဒရယ်ဥပဒေအမှတ် 15.1-FZ “သတင်းအချက်အလက်၊ သတင်းအချက်အလက်နည်းပညာနှင့် သတင်းအချက်အလက် ကာကွယ်ရေးဆိုင်ရာ ပုဒ်မ 15.4-27 မှ ပြဋ္ဌာန်းချက်များဘောင်အတွင်း ဝင်ရောက်ခွင့် ကန့်သတ်ချက်များ လိုအပ်ချက်များရှိသည့် တယ်လီကွန်းအော်ပရေတာများမှ လိုက်နာမှုကို စောင့်ကြည့်ရန် ဒီဇိုင်းထုတ်ထားသည်။ ”

AS "Revizor" ကို ဖန်တီးခြင်း၏ အဓိကရည်ရွယ်ချက်မှာ တယ်လီကွန်းအော်ပရေတာများ၏ လိုက်နာမှုအား ဖက်ဒရယ်ဥပဒေ ပုဒ်မ 15.1-15.4 မှ 27 ခုနှစ် ဇူလိုင်လ 2006 ရက်၊ 149 ခုနှစ် ဇူလိုင်လ XNUMX ရက်နေ့တွင် အမှတ် XNUMX-FZ "သတင်းအချက်အလက်၊ သတင်းအချက်အလက်နည်းပညာများနှင့် သတင်းအချက်အလက် ကာကွယ်ရေးဆိုင်ရာ၊ တားမြစ်ထားသော သတင်းအချက်အလက်ရယူခွင့်ဆိုင်ရာ အချက်အလက်များကို ဖော်ထုတ်ခြင်းနှင့် တားမြစ်ထားသော သတင်းအချက်အလက်များ ဝင်ရောက်ခွင့်ကို ကန့်သတ်ရန် ချိုးဖောက်မှုများနှင့်ပတ်သက်၍ အထောက်အကူပြုပစ္စည်းများ (ဒေတာ) ရယူခြင်း။

အားလုံးမဟုတ်ပါက၊ ပံ့ပိုးပေးသူအများအပြားသည် ဤစက်ပစ္စည်းကို ထည့်သွင်းထားသောကြောင့်၊ ကြီးမားသော beacon probes ကဲ့သို့သော ကွန်ရက်ကြီးတစ်ခု ရှိသင့်သည်။ မှည့် Atlas နှင့် ပို၍ပင်၊ သို့သော် ပိတ်ထားခြင်းဖြင့် ဝင်ရောက်နိုင်သည်။ သို့သော်၊ မီးရှူးတန်ဆောင်သည် လမ်းကြောင်းအရပ်ရပ်သို့ အချက်ပြမှုများကို ပေးပို့ရန် မီးရှူးတန်ဆောင်တစ်ခုဖြစ်သော်လည်း ၎င်းတို့ကို ဖမ်းမိပြီး မည်မျှဖမ်းမိသည်ကို ကြည့်ပါက အဘယ်နည်း။

မရေတွက်မီ၊ ဘာကြောင့် ဖြစ်နိုင်သလဲ ဆိုတာ ကြည့်ရအောင်။

သီအိုရီ၏တစ်ဦးကနည်းနည်း

ဤအရာကဲ့သို့သော HTTP(S) တောင်းဆိုမှုများမှတစ်ဆင့် အရင်းအမြစ်တစ်ခု၏ရရှိနိုင်မှုကို အေးဂျင့်များက စစ်ဆေးသည်-

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

HTTP, "GET /somepage HTTP/1.1"
TCP, 80  >  14678, "[ACK] Seq=1 Ack=71"
HTTP, "HTTP/1.1 302 Found"

TCP, 14678  >  80, "[FIN, ACK] Seq=71 Ack=479"
TCP, 80  >  14678, "[FIN, ACK] Seq=479 Ack=72"
TCP, 14678  >  80, "[ACK] Seq=72 Ack=480"

ဝန်ဆောင်ခအပြင်၊ တောင်းဆိုချက်တွင် ချိတ်ဆက်မှုတည်ဆောက်မှုအဆင့်- လဲလှယ်မှုလည်း ပါဝင်ပါသည်။ SYN и SYN-ACKနှင့် ချိတ်ဆက်မှု ပြီးစီးမှု အဆင့်များ- FIN-ACK.

တားမြစ်ထားသော အချက်အလက်စာရင်းတွင် ပိတ်ဆို့ခြင်းအမျိုးအစားများစွာ ပါရှိသည်။ အရင်းအမြစ်တစ်ခုအား IP လိပ်စာ သို့မဟုတ် ဒိုမိန်းအမည်ဖြင့် ပိတ်ဆို့ထားပါက၊ မည်သည့်တောင်းဆိုမှုများကိုမျှ ကျွန်ုပ်တို့ မြင်တွေ့မည်မဟုတ်ပါ။ ၎င်းတို့သည် အဖျက်အဆီးအခံရဆုံး အမျိုးအစားများဖြစ်ပြီး IP လိပ်စာတစ်ခုရှိ အရင်းအမြစ်အားလုံး သို့မဟုတ် ဒိုမိန်းတစ်ခုရှိ အချက်အလက်အားလုံးတွင် အရင်းအမြစ်အားလုံးကို သုံးစွဲနိုင်မှုဆီသို့ ဦးတည်သွားစေသည်။ ပိတ်ဆို့ခြင်း “by URL” အမျိုးအစားလည်း ရှိပါသည်။ ဤကိစ္စတွင်၊ စစ်ထုတ်စနစ်သည် ပိတ်ဆို့ရမည့်အရာကို အတိအကျဆုံးဖြတ်ရန် HTTP တောင်းဆိုချက် ခေါင်းစီးကို ပိုင်းခြားရပါမည်။ ၎င်းမတိုင်မီတွင်၊ အထက်တွင်တွေ့မြင်နိုင်သကဲ့သို့၊ စစ်ထုတ်ခြင်းမှလွဲချော်နိုင်ခြေများသောကြောင့်သင်ခြေရာခံရန်ကြိုးစားနိုင်သည့်ချိတ်ဆက်မှုတည်ဆောက်မှုအဆင့်တစ်ခုရှိသင့်သည်။

၎င်းကိုလုပ်ဆောင်ရန်၊ အေးဂျင့်များမှလွဲ၍ ပြင်ပအသွားအလာများဝင်ရောက်မှုကို လျှော့ချရန်အတွက် စစ်ထုတ်စနစ်၏လုပ်ဆောင်မှုကို လွယ်ကူချောမွေ့စေရန်အတွက်၊ သင်သည် "URL" နှင့် HTTP ပိတ်ဆို့ခြင်းအမျိုးအစားပါရှိသော သင့်လျော်သောအခမဲ့ဒိုမိန်းတစ်ခုကို ရွေးချယ်ရန်လိုအပ်ပါသည်။ ဤတာဝန်သည် လုံးဝခက်ခဲသည်မဟုတ်ပါ၊ တားမြစ်ထားသောအချက်အလက်စာရင်းသွင်းခြင်းနှင့် အရသာတိုင်းအတွက် အခမဲ့ဒိုမိန်းများစွာရှိသည်။ ထို့ကြောင့်၊ ဒိုမိန်းအား ဝယ်ယူပြီး VPS လုပ်ဆောင်နေသည့် IP လိပ်စာများနှင့် ချိတ်ဆက်ထားသည်။ tcpdump ရေတွက်ခြင်းစတင်ခဲ့သည်။

စာရင်းစစ် "စာရင်းစစ်"

ထိန်းချုပ်ထားသော လုပ်ဆောင်ချက်ကို ညွှန်ပြမည့် ကျွန်ုပ်၏ထင်မြင်ယူဆချက်တွင် အချိန်အခါအလိုက် ပေါက်ကြားလာသော တောင်းဆိုမှုများကို မြင်တွေ့ရမည်ဟု မျှော်လင့်ပါသည်။ လုံးဝ မမြင်ဘူး လို့ ပြောဖို့ မဖြစ်နိုင်ပေမယ့် ရှင်းရှင်းလင်းလင်း ပုံမျိုးတော့ မရှိပါဘူး။

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

သေးငယ်သော ကဗျာဆန်သော သဘောထားကွဲလွဲမှု။ တစ်ရက်ကျော်အကြာတွင်၊ ကျွန်ုပ်၏ hosting ဝန်ဆောင်မှုပေးသူသည် သင့်အဆောက်အအုံများတွင် RKN တားမြစ်ထားသောစာရင်းမှ ရင်းမြစ်တစ်ခုပါရှိသောကြောင့် ၎င်းကို ပိတ်ဆို့ထားသည်ဟု ဆိုကာ ရိုးရှင်းသော အကြောင်းအရာတစ်ခုဖြင့် စာတစ်စောင်ပေးပို့ခဲ့သည်။ ပထမတော့ ကျွန်တော့်အကောင့်ကို ပိတ်ဆို့ထားသည်ဟု ထင်ခဲ့သော်လည်း၊ ထိုသို့ မဟုတ်ခဲ့ပါ။ အဲဒီအခါမှာ သူတို့က ကျွန်မကို သိပြီးသားအရာတွေကို ရိုးရိုးရှင်းရှင်း သတိပေးနေတာလို့ ကျွန်မထင်ခဲ့တယ်။ သို့သော် hoster သည် ကျွန်ုပ်၏ဒိုမိန်းရှေ့တွင် ၎င်း၏ filter ကိုဖွင့်လိုက်သဖြင့် ရလဒ်အနေဖြင့်၊ ဝန်ဆောင်မှုပေးသူများနှင့် hoster ထံမှ နှစ်ဆစစ်ထုတ်ခြင်းခံနေရပါသည်။ စစ်ထုတ်မှုသည် တောင်းဆိုမှုများ၏ အဆုံးကိုသာ ကျော်လွန်သွားသည်- FIN-ACK и RST တားမြစ်ထားသော URL တွင် HTTP အားလုံးကို ဖြတ်တောက်ခြင်း အထက်ဖော်ပြပါဂရပ်မှ သင်တွေ့မြင်ရသည့်အတိုင်း၊ ပထမနေ့တွင် ကျွန်ုပ်သည် ဒေတာနည်းသွားသည်ကို စတင်လက်ခံရရှိခဲ့သော်လည်း၊ တောင်းဆိုမှုရင်းမြစ်များကို ရေတွက်ခြင်းလုပ်ငန်းအတွက် အတော်လေး လုံလောက်နေပြီဖြစ်သည်။

အမှတ်ရပါ။ ကျွန်တော့်အမြင်အရတော့ ပေါက်ကွဲမှုနှစ်ခုကို နေ့တိုင်းရှင်းရှင်းလင်းလင်းမြင်ရပြီး ပထမအသေးက ညသန်းခေါင်နောက်ပိုင်း မော်စကိုအချိန်၊ ဒုတိယတစ်ခုက မနက် ၆ နာရီနဲ့ မွန်းတည့် ၁၂ နာရီအထိ အမြီးနဲ့နီးပါတယ်။ အထွတ်အထိပ်သည် တစ်ချိန်တည်းတွင် ဖြစ်ပေါ်လာခြင်းမဟုတ်ပါ။ ပထမတော့၊ အေးဂျင့်များ၏ စစ်ဆေးမှုများသည် အခါအားလျော်စွာ လုပ်ဆောင်သည်ဟု ယူဆချက်အပေါ် အခြေခံ၍ ဤကာလများတွင်သာ ကျဆင်းသွားသော IP လိပ်စာများကို ရွေးချယ်လိုပါသည်။ ဒါပေမယ့် သေချာသုံးသပ်ကြည့်တဲ့အခါ နာရီတိုင်း တောင်းဆိုချက်တစ်ခုအထိ တခြားကြိမ်နှုန်းတွေနဲ့ တခြားအချိန်အပိုင်းအခြားတွေထဲကို ကျသွားတာကို အမြန်တွေ့ရှိခဲ့ပါတယ်။ ထို့နောက် အချိန်ဇုန်များအကြောင်း တွေးခဲ့ပြီး ၎င်းတို့နှင့် ပတ်သက်မှုတစ်ခု ရှိကောင်းရှိနိုင်သည်၊ ထို့နောက် ယေဘူယျအားဖြင့် စနစ်သည် တစ်ကမ္ဘာလုံးနှင့် တစ်ပြိုင်နက် လုပ်ဆောင်နိုင်မည်မဟုတ်ဟု တွေးလိုက်မိသည်။ ထို့အပြင်၊ NAT သည် အခန်းကဏ္ဍတစ်ခုမှ ပါဝင်မည်ဖြစ်ပြီး တူညီသော အေးဂျင့်သည် မတူညီသော အများသူငှာ IP များမှ တောင်းဆိုမှုများကို ပြုလုပ်နိုင်သည်။

ကျွန်တော့်ရဲ့ကနဦးရည်မှန်းချက်က အတိအကျမဟုတ်တာကြောင့် တစ်ပတ်အတွင်းတွေ့ခဲ့ရတဲ့ လိပ်စာအားလုံးကို ရေတွက်ပြီး ရခဲ့ပါတယ်- 2791. လိပ်စာတစ်ခုမှသတ်မှတ်ထားသော TCP စက်ရှင်အရေအတွက်သည် ပျမ်းမျှ 4 ခုဖြစ်ပြီး ပျမ်းမျှအားဖြင့် 2 ခုဖြစ်သည်။ လိပ်စာတစ်ခုလျှင် ထိပ်တန်းဆက်ရှင်များ- 464၊ 231၊ 149၊ 83၊ 77။ နမူနာ၏ 95% မှ အများဆုံးသည် လိပ်စာတစ်ခုလျှင် 8 sessions ဖြစ်သည်။ ပျမ်းမျှသည် အလွန်မြင့်မားသည်မဟုတ်ပါ၊ ဂရပ်သည် နေ့စဉ်အချိန်အပိုင်းအခြားကို ရှင်းရှင်းလင်းလင်းပြသထားသောကြောင့် ၇ ရက်အတွင်း 4 မှ 8 အထိ တစ်စုံတစ်ခုကို မျှော်လင့်နိုင်ပါသည်။ တစ်ကြိမ်ဖြစ်ပေါ်သော sessions အားလုံးကို ဖယ်ထုတ်ပါက၊ 7 နှင့် ညီမျှသော ပျမ်းမျှကို ရရှိမည်ဖြစ်သည်။ သို့သော် ရှင်းရှင်းလင်းလင်း စံနှုန်းတစ်ခုအပေါ် အခြေခံ၍ ၎င်းတို့ကို မဖယ်ထုတ်နိုင်ပါ။ ဆန့်ကျင်ဘက်တွင်၊ ကျပန်းစစ်ဆေးမှုတစ်ခုက ၎င်းတို့သည် တားမြစ်ထားသော အရင်းအမြစ်တစ်ခုအတွက် တောင်းဆိုမှုများနှင့် သက်ဆိုင်ကြောင်း ပြသခဲ့သည်။

လိပ်စာများသည် လိပ်စာများဖြစ်သော်လည်း အင်တာနက်တွင် ပို၍အရေးကြီးသည်ဟု ပေါ်ထွက်လာသော ကိုယ်ပိုင်အုပ်ချုပ်ခွင့်ရစနစ်များ - AS 1510ပျမ်းမျှအားဖြင့် 2 နှင့် AS တစ်ခုလျှင် လိပ်စာ 1 ခုရှိသည်။ AS တစ်ခုလျှင် ထိပ်တန်းလိပ်စာများ- 288၊ 77၊ 66၊ 39၊ 27။ နမူနာ၏ အများဆုံး 95% သည် AS တစ်ခုလျှင် လိပ်စာ 4 ခုဖြစ်သည်။ ဤတွင် ပျမ်းမျှအား မျှော်လင့်ထားသည် - ဝန်ဆောင်မှုတစ်ခုလျှင် ကိုယ်စားလှယ်တစ်ဦး။ ကျွန်တော်တို့လည်း ထိပ်တန်းကို မျှော်လင့်ထားပါတယ် - အဲဒီထဲမှာ ကြီးမားတဲ့ ကစားသမားတွေ ရှိပါတယ်။ ကွန်ရက်ကြီးတစ်ခုတွင်၊ အေးဂျင့်များသည် အော်ပရေတာ၏ရောက်ရှိမှု၏ ဒေသတစ်ခုစီတွင် တည်ရှိသင့်ပြီး NAT ကို မမေ့ပါနှင့်။ နိုင်ငံအလိုက်ယူပါက အမြင့်ဆုံး 1409 - RU၊ 42 - UA၊ 23 - CZ၊ RIPE NCC မဟုတ်ဘဲ အခြားဒေသများမှ 36 ဖြစ်သည်။ ရုရှားနိုင်ငံပြင်ပမှ တောင်းဆိုမှုများသည် အာရုံစူးစိုက်မှုကို ဆွဲဆောင်သည်။ ၎င်းကို ဒေတာဖြည့်သည့်အခါ ပထဝီတည်နေရာ အမှားများ သို့မဟုတ် မှတ်ပုံတင်အရာရှိ အမှားများဖြင့် ရှင်းပြနိုင်သည်။ သို့မဟုတ် ရုရှားကုမ္ပဏီတစ်ခုတွင် ရုရှားရင်းမြစ်များမရှိနိုင်ခြင်း၊ သို့မဟုတ် နိုင်ငံခြားကိုယ်စားလှယ်ရုံးတစ်ခုရှိရခြင်းမှာ နိုင်ငံခြားအဖွဲ့အစည်း RIPE NCC နှင့်ဆက်ဆံရာတွင် ပိုမိုလွယ်ကူသောကြောင့် သဘာဝကျပါသည်။ အချို့သော အစိတ်အပိုင်းသည် သံသယဖြစ်စရာ မလိုအပ်ဘဲ၊ အရင်းအမြစ်ကို ပိတ်ဆို့ခြင်းခံနေရပြီး ဒုတိယနေ့မှစ၍ နှစ်ဆပိတ်ဆို့နေသောကြောင့် ၎င်းကို ခွဲထုတ်ရန် စိတ်ချယုံကြည်ရခက်ပါသည်။ ဒါက သေးငယ်တဲ့ အပိုင်းဖြစ်တယ်လို့ သဘောတူလိုက်ကြရအောင်။

ဤနံပါတ်များကို ရုရှားရှိ ဝန်ဆောင်မှုပေးသူအရေအတွက်နှင့် နှိုင်းယှဉ်နိုင်ပါပြီ။ RKN အရ သိရသည်။ "စကားသံမှလွဲ၍ ဒေတာပေးပို့ခြင်းဆိုင်ရာ ဆက်သွယ်ရေးဝန်ဆောင်မှုများအတွက် လိုင်စင်များ - 6387"၊ သို့သော် ၎င်းသည် အထက်မှခန့်မှန်းချက်ဖြစ်ပြီး၊ ဤလိုင်စင်များအားလုံးသည် အေးဂျင့်တပ်ဆင်ရန်လိုအပ်သော အင်တာနက်ဝန်ဆောင်မှုပေးသူများနှင့် အထူးသက်ဆိုင်မည်မဟုတ်ပေ။ RIPE NCC ဇုန်တွင် ရုရှားနိုင်ငံတွင် မှတ်ပုံတင်ထားသော အလားတူ ASE အရေအတွက် 6230 ရှိပြီး ၎င်းတို့အားလုံးသည် ဝန်ဆောင်မှုပေးသူများမဟုတ်ပေ။ UserSide သည် ပိုမိုတင်းကျပ်သော တွက်ချက်မှုကို ပြုလုပ်ခဲ့သည်။ 3940 ခုနှစ်တွင် ကုမ္ပဏီပေါင်း 2017 ကို လက်ခံရရှိခဲ့ပြီး ၎င်းသည် အထက်မှ ခန့်မှန်းချက်တစ်ခုဖြစ်သည်။ မည်သို့ပင်ဆိုစေ၊ ကျွန်ုပ်တို့တွင် တောက်ပသော AS အရေအတွက် နှစ်ဆခွဲရှိသည်။ သို့သော် ဤနေရာတွင် AS သည် ပံ့ပိုးသူနှင့် တင်းကြပ်စွာ တန်းတူညီမျှမဟုတ်ကြောင်း နားလည်ရကျိုးနပ်ပါသည်။ အချို့သောဝန်ဆောင်မှုပေးသူများတွင် ၎င်းတို့၏ကိုယ်ပိုင် AS မရှိပါ၊ အချို့တွင် တစ်ခုထက်ပိုပါသည်။ လူတိုင်းတွင် အေးဂျင့်များရှိနေသေးသည်ဟု ကျွန်ုပ်တို့ယူဆပါက၊ တစ်စုံတစ်ဦးသည် အခြားသူများထက် ပိုမိုပြင်းထန်စွာ စစ်ထုတ်သည်၊ ထို့ကြောင့် ၎င်းတို့တောင်းဆိုချက်များသည် ၎င်းတို့ထံရောက်ရှိပါက အမှိုက်နှင့် ခွဲခြား၍မရပေ။ ဒါပေမယ့် အကြမ်းဖျဉ်း အကဲဖြတ်ချက်တစ်ခုအတွက် တစ်စုံတစ်ခု ဆုံးရှုံးသွားရင်တောင် သည်းခံနိုင်လောက်ပါတယ်။

DPI အကြောင်း

ကျွန်ုပ်၏ hosting ဝန်ဆောင်မှုပေးသူသည် ဒုတိယနေ့မှစတင်၍ ၎င်း၏ filter ကိုဖွင့်ထားသော်လည်း၊ ပထမနေ့မှစ၍ အချက်အလက်များအပေါ်အခြေခံ၍ blocking သည်အောင်မြင်စွာလုပ်ဆောင်နေသည်ဟုကျွန်ုပ်တို့ကောက်ချက်ချနိုင်သည်။ ရင်းမြစ် 4 ခုသာ ဖြတ်ကျော်နိုင်ခဲ့ပြီး HTTP နှင့် TCP ဆက်ရှင်များ ပြီးမြောက်ခဲ့သည် (အထက်ပါဥပမာအတိုင်း)။ နောက်ထပ် 460 ပို့နိုင်တယ်။ GETဒါပေမယ့် session ကိုချက်ချင်းအားဖြင့်ရပ်စဲသည်။ RST. အာရုံစိုက်ပါ။ TTL:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

HTTP, "GET /filteredpage HTTP/1.1"
TTL 64, TCP, 80  >  14678, "[ACK] Seq=1 Ack=294"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"

HTTP, "HTTP/1.1 302 Found"

#А это попытка исходного узла получить потерю
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[ACK] Seq=294 Ack=145"

TTL 50, TCP, 14678  >  80, "[FIN, ACK] Seq=294 Ack=145"
TTL 64, TCP, 80  >  14678, "[FIN, ACK] Seq=171 Ack=295"

TTL 50, TCP Dup ACK 14678 > 80 "[ACK] Seq=295 Ack=145"

#Исходный узел понимает что сессия разрушена
TTL 50, TCP, 14678  >  80, "[RST] Seq=294"
TTL 50, TCP, 14678  >  80, "[RST] Seq=295"

ကွဲပြားမှုများသည် ကွဲပြားနိုင်သည်- နည်းသည်။ RST သို့မဟုတ် ပိုများသော ပြန်လည်ပေးပို့ခြင်း - စစ်ထုတ်မှုမှ အရင်းအမြစ် node သို့ပေးပို့သည့်အပေါ်မူတည်ပါသည်။ မည်သို့ပင်ဆိုစေ၊ ၎င်းသည် တောင်းဆိုထားသည့် တားမြစ်ထားသော အရင်းအမြစ်တစ်ခုဖြစ်ကြောင်း ရှင်းရှင်းလင်းလင်း သိသာထင်ရှားသော၊ ဤသည်မှာ ယုံကြည်စိတ်ချရဆုံး ပုံစံဖြစ်သည်။ ထို့အပြင် session တွင်ပေါ်လာသောအဖြေတစ်ခုအမြဲရှိသည်။ TTL ယခင်နှင့် နောက်ဆက်တွဲ ပက်ကေ့ဂျ်များထက် ကြီးသည်။

ကျန်တာတောင် မမြင်ရဘူး။ GET:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST] Seq=1"

သို့မဟုတ်ဤ:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST, PSH] Seq=1"

TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"

#Опять фильтр, много раз
TTL 53, TCP, 14678  >  80, "[RST, PSH] Seq=1"
...

ခြားနားချက်ကို သေချာပေါက် မြင်နိုင်ပါတယ်။ TTL filter မှ တစ်ခုခု ထွက်လာရင် သို့သော် များသောအားဖြင့် မည်သည့်အရာမှ မရောက်နိုင်ပါ။

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP Retransmission, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
...

သို့မဟုတ်ဤ:

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

#Прошло несколько секунд без трафика

TCP, 80  >  14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...

ဤအရာအားလုံးကို ဂရပ်ပေါ်တွင်မြင်နိုင်သကဲ့သို့၊ တစ်ကြိမ်ထက်ပို၍ နေ့စဉ်၊

IPv6 အကြောင်း

ရှိနေကြောင်း သတင်းကောင်းပါးအပ်ပါသည်။ တားမြစ်ထားသော ရင်းမြစ်သို့ အချိန်အခါအလိုက် တောင်းဆိုမှုများသည် မတူညီသော IPv5 လိပ်စာ ၅ ခုမှ ဖြစ်ပေါ်ကြောင်း စိတ်ချယုံကြည်ရနိုင်ပြီး၊ ၎င်းသည် ကျွန်ုပ်မျှော်လင့်ထားသည့် အေးဂျင့်များ၏ အပြုအမူနှင့် အတိအကျဖြစ်သည်။ ထို့အပြင်၊ IPv6 လိပ်စာများထဲမှ တစ်ခုသည် စစ်ထုတ်ခြင်းအောက်တွင် မကျဘဲ session အပြည့်အစုံကို ကျွန်ုပ်တွေ့မြင်ရသည်။ နောက်ထပ် နှစ်ခုမှ မပြီးပြတ်သေးသော session တစ်ခုသာ တွေ့ခဲ့ရပြီး တစ်ခုမှာ အနှောင့်အယှက် ဖြစ်နေပါသည်။ RST filter မှ၊ ဒုတိယအချိန်။ စုစုပေါင်းတန်ဘိုး 7.

လိပ်စာအနည်းငယ်သာရှိသောကြောင့် ၎င်းတို့အားလုံးကို အသေးစိတ်လေ့လာခဲ့ရာတွင် ဝန်ဆောင်မှုပေးသူ 3 ဦးသာရှိသဖြင့် ၎င်းတို့ကို ဂုဏ်ပြုစကားလက်ဆောင်ပေးနိုင်ပါသည်။ အခြားလိပ်စာမှာ ရုရှားတွင် cloud hosting ဖြစ်သည် (စစ်ထုတ်ခြင်းမပြုပါ)၊ နောက်တစ်ခုသည် ဂျာမနီရှိ သုတေသနစင်တာတစ်ခု ( filter တစ်ခုရှိပါသည်၊ မည်သည့်နေရာတွင်ရှိသနည်း။) သို့သော် တားမြစ်ထားသော အရင်းအမြစ်များ ရရှိနိုင်မှုကို အချိန်ဇယားအရ အဘယ်ကြောင့် စစ်ဆေးကြသနည်းဆိုသည်မှာ မေးခွန်းကောင်းတစ်ခုဖြစ်သည်။ ကျန်နှစ်ခုသည် တောင်းဆိုချက်တစ်ခုပြုလုပ်ပြီး ရုရှားနိုင်ငံပြင်ပတွင်တည်ရှိပြီး ၎င်းတို့ထဲမှတစ်ခုကို စစ်ထုတ်ခြင်းဖြစ်သည် (အကူးအပြောင်းတွင်၊ အားလုံးပြီးနောက်?)။

ပိတ်ဆို့ခြင်းနှင့် အေးဂျင့်များသည် IPv6 အတွက် ကြီးမားသောအတားအဆီးတစ်ခုဖြစ်ပြီး အကောင်အထည်ဖော်မှုသည် အလွန်လျင်မြန်စွာမရွေ့လျားပါ။ ဝမ်းနည်းစရာပါ။ ဒီပြဿနာကို ဖြေရှင်းနိုင်သူတွေဟာ ကိုယ့်ကိုယ်ကို ဂုဏ်ယူနိုင်ပါတယ်။

နိဂုံးချုပ်

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

တခြားဘာတွေလုပ်လို့ရနိုင်လဲ၊ ငါလုပ်ဖို့အရမ်းပျင်းတာက DNS တောင်းဆိုမှုတွေကို ရေတွက်တာပါ။ ၎င်းတို့ကို စစ်ထုတ်ခြင်း မပြုသော်လည်း ၎င်းတို့သည် ဒိုမိန်းအတွက်သာ လုပ်ဆောင်ပြီး URL တစ်ခုလုံးအတွက် မဟုတ်သောကြောင့် ၎င်းတို့သည် တိကျမှုများစွာကို မပေးစွမ်းနိုင်ပေ။ ကြိမ်နှုန်းကို မြင်နိုင်ရမည်။ ၎င်းကို မေးမြန်းချက်များတွင် တိုက်ရိုက်မြင်နိုင်သည့်အရာနှင့် ပေါင်းစပ်ပါက၊ ၎င်းသည် မလိုအပ်သောအရာများကို ခွဲထုတ်နိုင်ပြီး အချက်အလက်များ ပိုမိုရရှိစေမည်ဖြစ်သည်။ ဝန်ဆောင်မှုပေးသူများအသုံးပြုသော DNS ၏ developer များနှင့် အခြားအရာများစွာကို ဆုံးဖြတ်ရန်ပင် ဖြစ်နိုင်သည်။

hoster သည် ကျွန်ုပ်၏ VPS အတွက် ၎င်း၏ကိုယ်ပိုင် filter များပါ၀င်မည်ဟု လုံးဝမမျှော်လင့်ခဲ့ပါ။ ဒါက လုပ်ရိုးလုပ်စဉ်တစ်ခု ဖြစ်နိုင်တယ်။ နောက်ဆုံးတွင်၊ RKN သည် အရင်းအမြစ်ကို hoster သို့ ဖျက်ရန် တောင်းဆိုချက်တစ်ခု ပေးပို့သည်။ ဒါပေမယ့် ဒါက ကျွန်မကို အံ့သြစရာမဟုတ်သလို တချို့နည်းလမ်းတွေက ကျွန်မအတွက် အကျိုးရှိအောင်တောင် လုပ်ဆောင်ခဲ့ပါတယ်။ စစ်ထုတ်မှုသည် တားမြစ်ထားသော URL သို့ မှန်ကန်သော HTTP တောင်းဆိုမှုများအားလုံးကို ဖြတ်တောက်ကာ အလွန်ထိရောက်စွာ လုပ်ဆောင်ခဲ့သည်၊ သို့သော် ၎င်းတို့ထံ ယခင်က ဝန်ဆောင်မှုပေးသူများ၏ စစ်ထုတ်မှုမှတစ်ဆင့် ၎င်းတို့ထံရောက်ရှိသွားသော အဆုံးသတ်ပုံစံဖြင့်သာ ပြုလုပ်ထားသော်လည်း၊ FIN-ACK и RST - အနှုတ်သည် အနုတ်ဖြစ်ပြီး၊ ၎င်းသည် အပေါင်းဖြစ်လုနီးပါး ဖြစ်သွားသည်။ စကားမစပ်၊ IPv6 ကို hoster မှ စစ်ထုတ်မထားပါ။ ဟုတ်ပါတယ်၊ ဒါက စုဆောင်းထားတဲ့ ပစ္စည်းရဲ့ အရည်အသွေးကို ထိခိုက်စေပေမယ့် အကြိမ်ရေကို မြင်နိုင်ပါသေးတယ်။ အရင်းအမြစ်များနေရာချရန်အတွက် ဝဘ်ဆိုက်တစ်ခုကို ရွေးချယ်ရာတွင် ဤအချက်သည် အရေးကြီးသောအချက်ဖြစ်ကြောင်း ထင်ရှားလာပါသည်။ တားမြစ်ထားသောဆိုက်များစာရင်းနှင့် RKN မှ တောင်းဆိုချက်များနှင့်အတူ အလုပ်စီစဉ်ခြင်းကိစ္စကို စိတ်ဝင်စားရန်မမေ့ပါနှင့်။

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

နောက်တစ်ခုပြောချင်တာက ကိရိယာတိုင်းဟာ လက်နက်တစ်ခုပါပဲ။ AS "Inspector" သည် ပိတ်ထားသောကွန်ရက်တစ်ခုဖြစ်သော်လည်း အေးဂျင့်များသည် တားမြစ်စာရင်းမှ အရင်းအမြစ်အားလုံးအတွက် တောင်းဆိုမှုများကို ပေးပို့ခြင်းဖြင့် လူတိုင်းကို လွှဲပြောင်းပေးသည်။ ထိုကဲ့သို့သော အရင်းအမြစ်တစ်ခုရှိခြင်းသည် မည်သည့်ပြဿနာမျှ မရှိပါ။ စုစုပေါင်း၊ အေးဂျင့်များမှတစ်ဆင့် ဝန်ဆောင်မှုပေးသူများသည် မရည်ရွယ်ဘဲ၊ ၎င်းတို့၏ကွန်ရက်အကြောင်း များများပြောပြခြင်းသည် တန်ဖိုးရှိနိုင်သည်- DPI နှင့် DNS အမျိုးအစားများ၊ Agent ၏တည်နေရာ (central node နှင့် service network?)၊ နှောင့်နှေးမှုများနှင့် ဆုံးရှုံးမှုများ၏ ကွန်ရက်အမှတ်အသားများ - ၎င်းသည် အထင်ရှားဆုံးသာ။ တစ်စုံတစ်ယောက်သည် ၎င်းတို့၏ အရင်းအမြစ်များ ရရှိနိုင်မှုကို မြှင့်တင်ရန် အေးဂျင့်များ၏ လုပ်ဆောင်ချက်များကို စောင့်ကြည့်နိုင်သကဲ့သို့၊ တစ်စုံတစ်ယောက်သည် ၎င်းကို အခြားရည်ရွယ်ချက်များအတွက် လုပ်ဆောင်နိုင်ပြီး ၎င်းအတွက် အတားအဆီးမရှိပါ။ ရလဒ်သည် အစွန်းနှစ်ဖက်ရှိပြီး အလွန်ဘက်စုံသော တူရိယာတစ်ခုဖြစ်ပြီး မည်သူမဆို ဤအရာကို မြင်နိုင်သည်။

source: www.habr.com