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

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

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

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

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

در مثال زیر  ما میبینیم که یک درخواست پرس و جو جعلی از آی پی قربانی (10.100.101.102 ) بر روی پورت 80 را میبینیم که از DNS سرور 192.168.5.10 انجام شده است:

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 “553992721-5400647″
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 “178953544-4422001″
exampletest.xab. 3599 IN TXT “228406766-4422034″
exampletest.xab. 3599 IN TXT “299762315-4422055″
exampletest.xab. 3599 IN TXT “826318936-4422046″
exampletest.xab. 3599 IN TXT “598362127-4422061″
exampletest.xab. 3599 IN TXT “227933795-4422004″
exampletest.xab. 3599 IN TXT “691244312-4422022″
exampletest.xab. 3599 IN TXT “287893658-4422013″
exampletest.xab. 3599 IN TXT “186244776-4422028″
exampletest.xab. 3599 IN TXT “353675828-4422052″
exampletest.xab. 3599 IN TXT “782919862-4417942″
exampletest.xab. 3599 IN TXT “126353328-4422040″
exampletest.xab. 3599 IN TXT “294923881-4422049″
exampletest.xab. 3599 IN TXT “667921463-4422007″
exampletest.xab. 21599 IN NS ns2.exampletest.xab.
exampletest.xab. 21599 IN NS ns1.exampletest.xab.
exampletest.xab. 3599 IN TXT “764482656-4422025″
exampletest.xab. 3599 IN TXT “757973593-4422016″
exampletest.xab. 3599 IN TXT “MS=ms66433104″
exampletest.xab. 3599 IN TXT “714321871-4421998″
exampletest.xab. 3599 IN TXT “882369757-4422010″
exampletest.xab. 3599 IN TXT “ms=ms97244866″
exampletest.xab. 3599 IN TXT “321959687-4422031″
exampletest.xab. 3599 IN TXT “754510718-4422064″
exampletest.xab. 3599 IN TXT “319997471-4422043″
exampletest.xab. 3599 IN TXT “522183251-4422019″
exampletest.xab. 3599 IN TXT “688562515-4422037″
exampletest.xab. 3599 IN TXT “133466244-4422058″

;; 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

همانطور که مشاهده می کنید در مثال های بالا یک بسته به اندازه 64 بایت توسط مهاجم ارسال شده و بسته ای به اندازه 1175 بایت به عنوان پاسخ به آی پی قربانی ارسال شده است؛در این مورد قدرت تقویت فقط 18 برابر بوده است که البته این پاسخ با توجه به این که چه چیزی پرس و جو می شود می تواند تا 54 برابر بزرگتر باشد!

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

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

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

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

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