حمله DDoS به خدمات RDP: شناسایی و مبارزه تجربه موفق از توچا

بیایید یک داستان جالب در مورد اینکه چگونه "اشخاص ثالث" سعی کردند در کار مشتریان ما دخالت کنند و چگونه این مشکل حل شد را برای شما تعریف کنیم.

چگونه همه چیز شروع شد

همه چیز از صبح 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 и پتیا?

در حالی که ما آن را مرتب می کردیم، درخواست های مشابهی از چندین مشتری و شریک دیگر دریافت کردیم.
در واقع در این ماشین ها چه اتفاقی می افتد؟

گزارش رویدادها مملو از پیام هایی در مورد تلاش برای حدس زدن رمز عبور است:

حمله DDoS به خدمات RDP: شناسایی و مبارزه تجربه موفق از توچا

به طور معمول، چنین تلاش هایی در تمام سرورهایی که در آن پورت استاندارد (3389) برای سرویس دسترسی از راه دور استفاده می شود و دسترسی از همه جا مجاز است، ثبت می شود. اینترنت پر از ربات‌هایی است که دائماً تمام نقاط اتصال موجود را اسکن می‌کنند و سعی می‌کنند رمز عبور را حدس بزنند (به همین دلیل است که ما قویاً توصیه می‌کنیم به جای «123» از رمزهای عبور پیچیده استفاده کنید). با این حال، شدت این تلاش ها در آن روز بسیار زیاد بود.

چه باید بکنم؟

توصیه می کنید که مشتریان زمان زیادی را صرف تغییر تنظیمات برای تعداد زیادی از کاربران نهایی کنند تا به پورت دیگری سوئیچ کنند؟ ایده خوبی نیست، مشتریان راضی نخواهند بود. توصیه می‌کنید فقط از طریق VPN اجازه دسترسی داشته باشید؟ با عجله و وحشت، افزایش اتصالات IPSec برای کسانی که آنها را بالا نمی برند - شاید چنین شادی به مشتریان نیز لبخند نمی زند. اگرچه باید بگویم در هر صورت این امر خداپسندانه ای است، اما ما همیشه توصیه می کنیم سرور را در یک شبکه خصوصی مخفی کنید و آماده کمک به تنظیمات هستیم و برای کسانی که دوست دارند خودشان آن را بفهمند دستورالعمل ها را به اشتراک می گذاریم. برای راه‌اندازی IPSec/L2TP در فضای ابری ما در حالت سایت به سایت یا حالت جاده -warrior، و اگر کسی بخواهد یک سرویس VPN را روی سرور ویندوز خود راه‌اندازی کند، همیشه آماده است نکاتی را در مورد نحوه راه‌اندازی یک سرور به اشتراک بگذارد. استاندارد RAS یا OpenVPN. اما، مهم نیست که چقدر باحال بودیم، این بهترین زمان برای انجام کار آموزشی در بین مشتریان نبود، زیرا باید با کمترین استرس برای کاربران، مشکل را در اسرع وقت برطرف کنیم.

راه حلی که ما اجرا کردیم به شرح زیر بود. ما تجزیه و تحلیل ترافیک عبوری را به گونه‌ای تنظیم کرده‌ایم که تمام تلاش‌ها برای برقراری اتصال TCP به پورت 3389 را زیر نظر داشته باشد و از بین آن آدرس‌هایی را انتخاب کنیم که در عرض 150 ثانیه تلاش می‌کنند با بیش از 16 سرور مختلف در شبکه ما ارتباط برقرار کنند. - اینها منابع حمله هستند (البته، اگر یکی از مشتریان یا شرکا نیاز واقعی به برقراری ارتباط با سرورهای زیادی از یک منبع داشته باشد، همیشه می توانید چنین منابعی را به "لیست سفید" اضافه کنید. اگر در یک شبکه کلاس C برای این 150 ثانیه، بیش از 32 آدرس شناسایی شود، منطقی است که کل شبکه را مسدود کنید. مسدودسازی برای 3 روز تنظیم می شود و اگر در این مدت هیچ حمله ای از منبع مشخصی انجام نشده باشد، این منبع به طور خودکار از "لیست سیاه" حذف می شود. لیست منابع مسدود شده هر 300 ثانیه به روز می شود.

حمله DDoS به خدمات RDP: شناسایی و مبارزه تجربه موفق از توچا

این لیست در این آدرس موجود است: https://secure.tucha.ua/global-filter/banned/rdp_ddos، می توانید ACL های خود را بر اساس آن بسازید.

ما آماده ایم کد منبع چنین سیستمی را به اشتراک بگذاریم؛ هیچ چیز بیش از حد پیچیده ای در آن وجود ندارد (اینها چندین اسکریپت ساده هستند که به معنای واقعی کلمه در چند ساعت روی زانو جمع آوری شده اند) و در عین حال می توان آن را تطبیق داد و از آن استفاده نکرد. فقط برای محافظت در برابر چنین حمله ای، بلکه برای شناسایی و مسدود کردن هرگونه تلاش برای اسکن شبکه: این لینک را دنبال کنید

علاوه بر این، ما تغییراتی در تنظیمات سیستم مانیتورینگ ایجاد کرده‌ایم که اکنون واکنش یک گروه کنترلی از سرورهای مجازی در فضای ابری ما به تلاش برای ایجاد یک اتصال RDP را با دقت بیشتری رصد می‌کند: اگر واکنش در یک مسیر انجام نشود. دوم، این دلیلی برای توجه است.

راه حل کاملاً مؤثر بود: دیگر هیچ شکایتی از طرف مشتریان و شرکا و سیستم نظارت وجود ندارد. آدرس‌های جدید و کل شبکه‌ها مرتباً به لیست سیاه اضافه می‌شوند، که نشان می‌دهد حمله ادامه دارد، اما دیگر بر کار مشتریان ما تأثیر نمی‌گذارد.

امنیت در گروه است

امروز فهمیدیم که سایر اپراتورها با مشکل مشابهی روبرو شده اند. هنوز کسی بر این باور است که مایکروسافت تغییراتی در کد سرویس دسترسی از راه دور ایجاد کرده است (اگر به خاطر داشته باشید، ما در روز اول به همین مورد مشکوک بودیم، اما خیلی سریع این نسخه را رد کردیم) و قول می دهد هر کاری ممکن است برای یافتن سریع راه حل انجام دهد. . برخی از افراد به سادگی مشکل را نادیده می گیرند و به مشتریان توصیه می کنند که خودشان از خود محافظت کنند (درگاه اتصال را تغییر دهید، سرور را در یک شبکه خصوصی پنهان کنید و غیره). و در همان روز اول، ما نه تنها این مشکل را حل کردیم، بلکه زمینه ای برای یک سیستم تشخیص تهدید جهانی تر که قصد توسعه آن را داریم ایجاد کردیم.

حمله DDoS به خدمات RDP: شناسایی و مبارزه تجربه موفق از توچا

تشکر ویژه از مراجعین و شرکایانی که ساکت ننشستند و در ساحل رودخانه ننشستند تا روزی جسد دشمنی در امتداد آن شناور شود، اما بلافاصله توجه ما را به این مشکل جلب کردند که این فرصت را به ما داد تا از بین ببریم. آن را در همان روز

منبع: www.habr.com

اضافه کردن نظر