راځئ چې تاسو ته په زړه پورې کیسه ووایم چې څنګه "دریم ګوند" زموږ د پیرودونکو په کار کې د مداخلې هڅه وکړه، او دا ستونزه څنګه حل شوه.
دا ټول څنګه پیل شول
دا ټول د اکتوبر په 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
دا پدې مانا ده چې ستونزه په ښکاره ډول د زیربنا په عملیاتو کې د کومې ستونزې له امله نه رامینځته کیږي ، مګر د بل څه له امله. شاید ټول کاروونکي د لیرې ډیسټاپ جواز ورکولو سره ستونزې ولري؟ شاید یو ډول مالویر د دوی سیسټمونو ته د ننوتلو اداره کړي، او نن ورځ دا فعاله شوې، لکه څنګه چې دا څو کاله وړاندې وه XData и پیټیا?
پداسې حال کې چې موږ دا ترتیب کول، موږ د ډیرو نورو پیرودونکو او شریکانو څخه ورته غوښتنې ترلاسه کړې.
په دې ماشینونو کې واقعا څه پیښیږي؟
د پیښې لاګونه د پټنوم اټکل کولو هڅو په اړه له پیغامونو ډک دي:
عموما، دا ډول هڅې په ټولو سرورونو کې ثبت شوي چیرې چې معیاري بندر (3389) د ریموټ لاسرسي خدمت لپاره کارول کیږي او له هر ځای څخه د لاسرسي اجازه لري. انټرنیټ د بوټونو څخه ډک دی چې په دوامداره توګه د ارتباط ټول موجود ټکي سکین کوي او د پټنوم اټکل کولو هڅه کوي (له همدې امله موږ په کلکه د "123" پرځای پیچلي پاسورډونو کارولو وړاندیز کوو). په هرصورت، د دې هڅو شدت هغه ورځ خورا لوړ و.
څنګه پرمخ لاړ شو؟
وړاندیز وکړئ چې پیرودونکي د ډیری پای کاروونکو لپاره مختلف بندر ته د بدلولو لپاره د ترتیباتو بدلولو لپاره ډیر وخت مصرفوي؟ ښه نظر نه دی، پیرودونکي به خوشحاله نه وي. یوازې د VPN له لارې لاسرسي ته اجازه ورکړئ؟ په بیړه او ویره کې، د هغو کسانو لپاره د IPSec اړیکو لوړول چې دوی یې ندي پورته کړي - شاید دا ډول خوښۍ په پیرودونکو باندې مسکا نه کوي. که څه هم، زه باید ووایم، دا په هر حالت کې یو خدایی شی دی، موږ تل په شخصي شبکه کې د سرور پټولو وړاندیز کوو او د ترتیباتو سره مرستې ته چمتو یو، او د هغو کسانو لپاره چې غواړي دا پخپله معلومه کړي، موږ لارښوونې شریکوو. زموږ په کلاوډ کې د سایټ څخه سایټ یا د سړک حالت -واریر کې د IPSec/L2TP تنظیم کولو لپاره ، او که څوک غواړي په خپل وینډوز سرور کې د VPN خدمت تنظیم کړي ، دوی تل چمتو دي چې څنګه د تنظیم کولو څرنګوالي په اړه لارښوونې شریکې کړي. معیاري RAS یا OpenVPN. مګر، مهمه نده چې موږ څومره ښه وو، دا د پیرودونکو ترمنځ د تعلیمي کار ترسره کولو لپاره غوره وخت نه و، ځکه چې موږ د کاروونکو لپاره د لږترلږه فشار سره ژر تر ژره ستونزه حل کولو ته اړتیا درلوده.
هغه حل چې موږ یې پلي کړی په لاندې ډول و. موږ د ټرافیک تیریدو تحلیل په داسې ډول ترتیب کړی چې د 3389 پورټ ته د TCP پیوستون رامینځته کولو ټولې هڅې وڅیړئ او له هغې څخه پته وټاکئ چې په 150 ثانیو کې زموږ په شبکه کې د 16 څخه ډیرو مختلف سرورونو سره د اړیکې رامینځته کولو هڅه وکړئ. - دا د برید سرچینې دي (البته ، که چیرې یو پیرودونکي یا شریکان د ورته سرچینې څخه د ډیری سرورونو سره اړیکې رامینځته کولو ته واقعیا اړتیا ولري ، تاسو کولی شئ تل دا ډول سرچینې په "سپینه لیست" کې اضافه کړئ. که د دې 150 ثانیو لپاره په یوه ټولګي C شبکه کې له 32 څخه ډیر ادرسونه وپیژندل شي، نو دا معنی لري چې ټوله شبکه بنده کړي، بلاک کول د 3 ورځو لپاره ټاکل شوي، او که په دې وخت کې د یوې سرچینې څخه هیڅ برید نه وي شوی، دا سرچینه په اوتومات ډول د "تور لیست" څخه لرې کیږي. د بند شوي سرچینو لیست په هر 300 ثانیو کې تازه کیږي.
دا لیست په دې پته شتون لري: تاسو کولی شئ د دې پر بنسټ خپل ACLs جوړ کړئ.
موږ چمتو یو چې د داسې سیسټم سرچینې کوډ شریک کړو؛ پدې کې هیڅ پیچلي شتون نلري (دا څو ساده سکریپټونه دي چې په لفظي ډول په څو ساعتونو کې په زنګون کې راټول شوي) ، او په ورته وخت کې دا تطبیق کیدی شي او نه کارول کیدی شي. یوازې د داسې برید په وړاندې د ساتنې لپاره، بلکه د شبکې سکین کولو لپاره د هرې هڅې کشف او بندول:
سربیره پردې ، موږ د نظارت سیسټم تنظیماتو کې ځینې بدلونونه رامینځته کړي ، کوم چې اوس زموږ په بادل کې د مجازی سرورونو د کنټرول ډلې عکس العمل ډیر نږدې څاري ترڅو د RDP اتصال رامینځته کولو هڅه وکړي: که عکس العمل د یو دننه تعقیب نشي. دوهم، دا د پام وړ دلیل دی.
د حل لاره خورا اغیزمنه وه: د پیرودونکو او شریکانو او د څارنې سیسټم څخه نور شکایتونه شتون نلري. نوي ادرسونه او ټولې شبکې په منظم ډول په تور لیست کې اضافه کیږي، کوم چې دا په ګوته کوي چې برید دوام لري، مګر نور زموږ د مراجعینو کار اغیزه نه کوي.
په شمیر کې خوندیتوب شتون لري
نن ورځ موږ پوهیږو چې نور چلونکي د ورته ستونزې سره مخ شوي. یو څوک لاهم پدې باور دي چې مایکروسافټ د ریموټ لاسرسي خدماتو کوډ کې ځینې بدلونونه کړي (که تاسو په یاد ولرئ ، موږ په لومړۍ ورځ ورته شی شک درلود ، مګر موږ په چټکۍ سره دا نسخه رد کړه) او ژمنه یې وکړه چې د ګړندي حل موندلو لپاره هرڅه ممکنه کړي. . ځینې خلک په ساده ډول ستونزه له پامه غورځوي او پیرودونکو ته مشوره ورکوي چې خپل ځان وساتي (د اتصال بندر بدل کړئ ، سرور په شخصي شبکه کې پټ کړئ ، او داسې نور). او په لومړۍ ورځ، موږ نه یوازې دا ستونزه حل کړه، بلکې د نړیوال ګواښ د کشف سیسټم لپاره یو څه زمینه هم جوړه کړه چې موږ یې د پراختیا پلان لرو.
د مراجعینو او همکارانو څخه ځانګړې مننه چې غلي پاتې نه شول او د سیند په غاړه کې ناست نه و چې یوه ورځ یې د دښمن جسد په لاره کې تیر کړي، مګر سمدستي یې زموږ پام دې ستونزې ته راواړولو چې موږ ته یې د لرې کولو فرصت راکړ. په همدې ورځ.
سرچینه: www.habr.com