حمله DNS Amplification Attack را بیشتر بشناسید

تا به امروز در خصوص متود ها مختلف حملات TCP توضیح داده ایم؛ اما امروز قصد داریم یک متود متفاوت از حملات را کالبد شکافی کنیم؛ حملاتی غول آسا و غیر قابل کنترل و البته معروف با نام DNS Amplification Attack .

یک حمله DNS amplification بر پایه هدایت ترافیک بدون اتصال از پروتکل UDP استفاده می شود. مهاجم با استفاده از DNS سرور های باز عمومی سعی در هدایت ترافیک بالا به آی پی قربانی است.در روش اولیه مهاجم یک درخواست DNS name lookup به یک سرور DNS عمومی ارسال می کند اما از IP جعلی ( که همان آی پی قربانی می باشد) جهت ارسال استفاده می کند و DNS سرور پاسخ را به همین آی پی ارسال می کند.

عامل تقویت بخش اصلی این حمله است؛ تقویت در این نوع حملات ۵۴X است؛ یعنی هر بایت ترافیک که توسط مهاجم به سرور  DNS ارسال می شود؛ پاسخی به اندازه ۵۴ بایت از سمت DNS سرور برای آی پی قربانی به همراه خواهد داشت.

اکثر حملات مشاهده شده از این نوع توسط US-CERT انجام شده؛درخواست های جعلی ارسال شده توسط هکر ها از نوع  “ANY” هستند که تمامی اطلاعات شناخته شده در خصوص ناحیه DNS را به آی پی قربانی بازگشت می دهد که به طور قابل توجهی بسیار بزرگتر از درخواست ارسال شده توسط مهاجم می باشد.

با استفاده از بات نت ها برای تولید تعداد زیادی از درخواست های DNS با آی پی های جعلی , مهاجم می تواند با کمترین تلاش بیشترین ترافیک را به سمت آی پی قربانی هدایت کند و از طرفی چون ترافیک به صورت مشروع از سرور های معتبر ارسال می شود؛ مهار و مسدود سازی آن مشکل خواهد بود.

در مثال زیر  ما میبینیم که یک درخواست پرس و جو جعلی از آی پی قربانی (۱۰٫۱۰۰٫۱۰۱٫۱۰۲ ) بر روی پورت ۸۰ را میبینیم که از DNS سرور ۱۹۲٫۱۶۸٫۵٫۱۰ انجام شده است:

root@linuxbox:~# dig ANY exampletest.xab @192.168.5.10 +edns=0

 

و حال در زیر پاسخ این درخواست را میبینیم:

; <<>> DiG 9.8.1-P1 <<>> ANY exampletest.xab @192.168.5.10 +edns=0
;; global options: +cmd
;; Got answer:
;; ->>HEADER< ;; flags: qr rd ra; QUERY: 1, ANSWER: 39, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;exampletest.xab. IN ANY

;; ANSWER SECTION:
exampletest.xab. 3599 IN TXT “۵۵۳۹۹۲۷۲۱-۵۴۰۰۶۴۷″
exampletest.xab. 3599 IN SOA ns1.exampletest.xab. 2015062301 28800 7200 604800 3600
exampletest.xab. 299 IN MX 10 abcmail1.exampletest.xab.
exampletest.xab. 299 IN MX 10 defmail5.exampletest.xab.
exampletest.xab. 299 IN MX 10 defmail3.exampletest.xab.
exampletest.xab. 299 IN MX 10 ghimail1.exampletest.xab.
exampletest.xab. 299 IN MX 10 abcmail2.exampletest.xab.
exampletest.xab. 21599 IN NS ns1.exampletest.xab.
exampletest.xab. 21599 IN NS ns3.exampletest.xab.
exampletest.xab. 299 IN A 192.168.22.167
exampletest.xab. 299 IN A 192.168.22.166
exampletest.xab. 3599 IN TXT “۱۷۸۹۵۳۵۴۴-۴۴۲۲۰۰۱″
exampletest.xab. 3599 IN TXT “۲۲۸۴۰۶۷۶۶-۴۴۲۲۰۳۴″
exampletest.xab. 3599 IN TXT “۲۹۹۷۶۲۳۱۵-۴۴۲۲۰۵۵″
exampletest.xab. 3599 IN TXT “۸۲۶۳۱۸۹۳۶-۴۴۲۲۰۴۶″
exampletest.xab. 3599 IN TXT “۵۹۸۳۶۲۱۲۷-۴۴۲۲۰۶۱″
exampletest.xab. 3599 IN TXT “۲۲۷۹۳۳۷۹۵-۴۴۲۲۰۰۴″
exampletest.xab. 3599 IN TXT “۶۹۱۲۴۴۳۱۲-۴۴۲۲۰۲۲″
exampletest.xab. 3599 IN TXT “۲۸۷۸۹۳۶۵۸-۴۴۲۲۰۱۳″
exampletest.xab. 3599 IN TXT “۱۸۶۲۴۴۷۷۶-۴۴۲۲۰۲۸″
exampletest.xab. 3599 IN TXT “۳۵۳۶۷۵۸۲۸-۴۴۲۲۰۵۲″
exampletest.xab. 3599 IN TXT “۷۸۲۹۱۹۸۶۲-۴۴۱۷۹۴۲″
exampletest.xab. 3599 IN TXT “۱۲۶۳۵۳۳۲۸-۴۴۲۲۰۴۰″
exampletest.xab. 3599 IN TXT “۲۹۴۹۲۳۸۸۱-۴۴۲۲۰۴۹″
exampletest.xab. 3599 IN TXT “۶۶۷۹۲۱۴۶۳-۴۴۲۲۰۰۷″
exampletest.xab. 21599 IN NS ns2.exampletest.xab.
exampletest.xab. 21599 IN NS ns1.exampletest.xab.
exampletest.xab. 3599 IN TXT “۷۶۴۴۸۲۶۵۶-۴۴۲۲۰۲۵″
exampletest.xab. 3599 IN TXT “۷۵۷۹۷۳۵۹۳-۴۴۲۲۰۱۶″
exampletest.xab. 3599 IN TXT “MS=ms66433104″
exampletest.xab. 3599 IN TXT “۷۱۴۳۲۱۸۷۱-۴۴۲۱۹۹۸″
exampletest.xab. 3599 IN TXT “۸۸۲۳۶۹۷۵۷-۴۴۲۲۰۱۰″
exampletest.xab. 3599 IN TXT “ms=ms97244866″
exampletest.xab. 3599 IN TXT “۳۲۱۹۵۹۶۸۷-۴۴۲۲۰۳۱″
exampletest.xab. 3599 IN TXT “۷۵۴۵۱۰۷۱۸-۴۴۲۲۰۶۴″
exampletest.xab. 3599 IN TXT “۳۱۹۹۹۷۴۷۱-۴۴۲۲۰۴۳″
exampletest.xab. 3599 IN TXT “۵۲۲۱۸۳۲۵۱-۴۴۲۲۰۱۹″
exampletest.xab. 3599 IN TXT “۶۸۸۵۶۲۵۱۵-۴۴۲۲۰۳۷″
exampletest.xab. 3599 IN TXT “۱۳۳۴۶۶۲۴۴-۴۴۲۲۰۵۸″

;; Query time: 254 msec
;; SERVER: 192.168.5.10#53(192.168.5.10)
;; WHEN: Thu Jul 9 14:10:14 2015
;; MSG SIZE rcvd: 1175

 

همانطور که مشاهده می کنید در مثال های بالا یک بسته به اندازه ۶۴ بایت توسط مهاجم ارسال شده و بسته ای به اندازه ۱۱۷۵ بایت به عنوان پاسخ به آی پی قربانی ارسال شده است؛در این مورد قدرت تقویت فقط ۱۸ برابر بوده است که البته این پاسخ با توجه به این که چه چیزی پرس و جو می شود می تواند تا ۵۴ برابر بزرگتر باشد!

دلیل محبوبیت این حملات وجود تعداد بسیار زیاد resolvers DNS باز بوده که امکان هدایت ترافیک زیادی را به سمت قربانیان فراهم می کرده.

در سال ۲۰۱۲ اوج این حملات بوده و در آن زمان تقریبا هیچ راه حلی برای این حملات وجود نداشت اما گروهی تصمیم به ایجاد پروژه ای عظیم گرفتند و نام آن را Open Resolver Project گذاشتند که در قالب تاسیس سایتی شروع به فعالیت کرد؛( جهت نمایش سایت اینجا کلیک کنید)

همانطور که مشخص است وظیفه این سایت شناسایی و معرفی  DNS resolvers های باز بود که مورد سو استفاده قرار می گرفتند؛ این حرکت در نگاه اول یک راه حل آسان برای هکر هایی بود که به دنبال سرور های DNS برای ایجاد حملات عظیم DNS Amplification می گشتند و یک لیست راحت و کار آمد برایشان مهیا شده بود؛ اما به مرور زمان این سایت به هدف نهایی خود رسید؛ افراد و شرکت هایی که مسئول این سرور ها بودند توسط این سایت و گزارش های کاربران متوجه وجود باگ های خود شدند آنها را برطرف نمودند و بعد از مدتی به صورت چشم گیری این حملات کاهش یافت.

اما یک مساله جالب در خصوص دیتا سنتر ها و ISP هایی که مورد حمله DDoS قرار می گرفتند این بود که با مدیران و کارشناسان سرور های resolvers DNS تماس می گرفتند و از آنها می خواستند سرور خود را پتچ کنند تا از طریق آنها مورد حمله قرار نگیرند اما مدیران DNS سرور ها عقیده داشتند که برعکس خودشان مورد حمله توسط این دیتا سنتر ها قرار گرفته اند و دلیل آنها هم درخواست های مکرر از طریق آی پی های این دیتا سنتر ها بود! در صورتی که اطلاع نداشتند کلیه این درخواست ها جعلی است و توسط هکر ها ارسال شده؛ اما این سایت باعث شد مدیران سرور های resolvers DNS متوجه اشتباه خود بشوند و با افزایش امنیت سرور ها؛ خود را از چرخه ی انجام حملات DDoS خارج نمایند.

هرچند حملات DNS Amplification دیگر همانند سال های گذشته یک کابوس به حساب نمی آیند و از قدرتشان کم شده اما هنوز در خصوص دیتا سنتر های ضعیف و با پهنای باند کم کار آمد و موثر هستند.