افزایش امنیت سرویس ها در سرور مجازی

در سالهای اخیر که سرور های مجازی را به کاربران ارائه میکنیم بسیار پیش آمده است که مجبور شدیم سرور مجازی را به دلیل مشکلات ایجاد کرده در شبکه دیتاسنتر و یا سو استفاده از سرور به دلیل حمله به IP های اینترنتی و ….مسدود کنیم ، اگر چه در غالب موارد کاربران خودشان مسبب این مشکلات نبوده و صرفا به دلیل کمبود آگاهی از شرایط و حساسیت های سرورهای پرسرعت متصل به ارتباط های گیگابیتی چنین مشکلاتی برای آنها ایجاد می‎شود.
مسدود کردن سروها یا شبکه آنها هم هم در وهله اول برای محافظت از سرور کاربران و جلوگیری از بسته شدن و یا حذف دائمی IP آنها بود و در وهله دوم برای جلوگیری از بروز مشکلات برای دیگران کاربران روی سرورهای مجازی و یا اکانت ما در دیتاسنتر ها

در همین راستا تصمیم گرفتم که امروز یک مطلب جامع در خصوص ریسک های مختلف به واسطه راه اندازی سروهای مختلف سرور مجازی را آغاز کنم و به مرور آن را با موارد جدیدتر آپدیت کنم.

در این مقاله همراه بلاگ رسانگار باشید

آسیب‌پذیری portmapper و نحوه امن‌سازی آن

گستردگی : زیاد

مربوط به OS : ویندوز یا

لینوکس

نوع تهدید : امکان سوء استفاده از حملات DOS/DDoS

معرفی RPC

RPC پروتکلی است که توسط آن یک برنامه می­تواند از یک برنامه موجود در یک سیستم دیگر که در شبکه قرار دارد، درخواست سرویس نماید بدون آن‌که نیاز به دانستن جزئیات شبکه داشته باشد. RPC از مدل کلاینت-سرور استفاده می­کند. برنامه­ای که درخواست سرویس میدهد، کلاینت و برنامه­ای که در طرف دیگر به این درخواست پاسخ می­دهد و سرویس مورد نظر را فراهم می­کند، سرور می­باشد. RPC همانند یک روند فراخوانی معمولی، عملیاتی سنکرون می­باشد بدین معنی که برنامه­ای که درخواست سرویس می­دهد باید تا بازگشت نتیجه از سرور راه دور، به صورت معطل باقی بماند. البته استفاده از پردازنده‎­هایی که یک فضای آدرس مشابه از حافظه را به اشتراک می­‎گذارند، موجب می­شود که چندین RPC بتوانند به طور همزمان اجرا شوند.

بر اساس مدل OSI، RPC یک پروتکل لایه Application (و نه پروتکل لایه Transmition ) می‎باشد. البته RPC از ویژگی­های ارتباطی موجود در لایه انتقال نیز استفاده می­‎کند. با استفاده از RPC می­توان برنامه‎­های کاربردی که شامل چندین برنامه توزیع ­شده در سطح شبکه می ­باشند را به آسانی تولید کرد.

در سرورهایی که دارای سیستم ­عامل­های مبتنی بر Unix می ­باشند، برنامه­هایی مانند lock manager، NFS daemons و license manager ها از RPC استفاده می­کنند. همچنین اکسپلویت­های بسیاری برای آن وجود دارد و هر روز هم به تعداد آن­ها افزوده می­شود. اولین گام برای بهره‌برداری و سوء استفاده از یک سرویس آن است که ابتدا تشخیص داده شود که سرویس بر روی سیستم هدف در حال اجرا می­باشد. در این مرحله portmapper و rpcbind و پورت شناخته شده 111 نیز وارد ماجرا می­شوند.

Portmapper و rpcbind

portmapper یک برنامه RPC و شماره نسخه آن را به یک شماره پورت خاص در لایه انتقال نگاشت می­کند. portmapper برای ثبت یک RPC از شناسه ­هایی مانند شماره سرویس RPC، شماره نسخه، پروتکل مورد استفاده و پورت TCP یا UDP استفاده می­کند. portmapper امکان نگاشت برنامه­های راه دور را به صورت پویا فراهم می­کند. همچنین portmapper همیشه بر روی پورت 111 پروتکل TCP یا UDP اجرا می­شود. برنامه‌هایی که در مکانیزم RPC به عنوان سرور عمل می­کنند، از پورت­های ناشناخته و موقتی استفاده می­کنند و بنابراین کلاینت­ها برای برقراری ارتباط با این برنامه­ها نیاز به دانستن یک شماره پورت شناخته شده از طرف آن­ها دارند تا بتوانند ارتباط برقرار کنند. بنابراین زمانی که یک کلاینت بخواهد به سرویسی دسترسی داشته باشد، باید ابتدا با portmapper ارتباط برقرار کند و پس از آن portmapper شماره پورت مورد نظر برای دسترسی کلاینت به سرویس مورد درخواست را در اختیارش قرار می­دهد. بنابراین دسترسی به پورت 111 به برنامه­هایی که به عنوان کلاینت عمل می­کنند اجازه می­دهد تا بتوانند پورت­های ناشناخته­ای که توسط سرور تعریف شده است را تشخیص دهند. اگر portmapper وجود نداشته باشد یا در دسترس نباشد، درخواست کلاینت رد می­شود.

متاسفانه RPC امنیت بسیار پائینی دارد. ضمناً به این دلیل که سرویس­های مبتنی بر RPC برای برقراری ارتباط نیاز به rpcbind دارند، باید قبل از شروع سرویس­های مورد نظر، ابتدا rpcbind در دسترس باشد.

زمانی که یک کلاینت از طریق مکانیزم RPC یک شماره برنامه را فراخوانی می­کند، ابتدا به منظور تشخیص آدرسی که باید درخواست RPC را به آن ارسال کند، به rpcbind متصل می­شود. اگر پورت 111 فعال باشد، لیستی از تمام سرویس­های فعال مهیا بوده و به این ترتیب می­تواند آدرسی که کلاینت باید به آن متصل شود را در اختیارش قرار دهد. البته در بعضی از نسخه­های Unix و Solaris، rpcbind نه تنها به پورت 111 از نوع TCP و UDP گوش می­کند، بلکه به پورت­های UDP بزرگتر از 32770 نیز گوش می­دهد. شماره­های دقیق پورت­ها به ساختار سیستم­عامل و نسخه آن بستگی دارد. بنابراین تجهیزات فیلترینگ و ACL های استفاده شده در روترها و فایروال­ها که برای عدم دسترسی به rpcbind یا portmapper بر روی شماره پورت 111 تنظیم شده­اند، می‌توانند با ارسال یک درخواست UDP به rpcbind و به شماره پورت­های بالاتر از 32770 دور زده شوند. کاربران غیرمجاز با سوء استفاده از این آسیب­پذیری می‌توانند اطلاعات RPC یک سیستم راه دور را به‌دست آورند (حتی در صورتی که پورت 111 مسدود شده باشد).

با توجه به اطلاعات RPC که از طریق پورت 111 به‌دست می­آید، می­توان فهمید که چه سرویس­هایی در حال اجرا می­باشند. در این رابطه تعداد زیادی آسیب­پذیری وجود دارد که اکسپلویت­های مرتبط با آن­ها هم قابل دسترسی است. بر روی سیستم­هایی که به طور کامل از آن­ها محافظت نمی­شود و portmapper بر روی آن­ها درحال اجراست، با اجرای یک دستور ساده rpcinfo می­توان لیستی از تمام سرویس­هایی که در حال اجرا می‌باشند را به‌دست آورد.

نحوه امن­‎سازی portmapper

برای رفع این مشکل کافی است اگر این سرویسها استفاده نمی کنید آن را از سرور خود حذف کنید و یا تمامی ترافیک های ارسالی ورودی و خروجی روی پورت 111 TCP و UDP را روی شبکه متصل به اینترنت سرور خود مسدود کنید

نحوه احراز اصالت در portmapper ضعیف می­باشد و به دلیل اینکه portmapper می­تواند تعداد زیادی از شماره پورت­ها را به سرویس­های تحت کنترلش اختصاص دهد، امن­سازی آن مشکل می­باشد. به هر حال، اگر سرویس RPC در حال اجرا می­باشد می­توان مراحل زیر را انجام داد:

امن­‎سازی portmapper با استفاده از TCP Wrappers

با استفاده از TCP Wrappers می­توان تعیین کرد که کدام شبکه­ ها و یا سیستم­ ها مجاز به دسترسی به سرویس portmap می­باشند. بنابراین هنگامی که قصد محدود کردن دسترسی به سرویس وجود داشته باشد، باید فقط از آدرس­های IP استفاده کرد و نباید از نام سیستم (hostname) در این حالت استفاده شود، چون نام­ها می­توانند با حملاتی مانند DNS poisoning و یا مشابه آن جعل شوند.

امن‎سازی portmapper با استفاده از IPTables در *nix

برای محدود کردن دسترسی به سرویس portmap به یک شبکه خاص، می‌توان rule های زیر را به iptables اضافه کرد. در این دو rule فقط به درخواست­­های اتصال TCP برای سرویس portmap از طرف شبکه­های 192.168.0.0/24 و localhost اجازه داده شده و بقیه بسته­ها drop می‌شوند:

iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 111 -j DROP
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT

برای محدود کردن ترافیک UDP نیز می‌توان از دستور زیر استفاده کرد:

iptables -A INPUT -p udp -s! 192.168.0.0/24 --dport 111 -j DROP

آسیب پذیری NetBIOS

معرفی NetBIOS

در اصل، NetBIOS یک رابط برنامه‌نویسی (API) است که با سرویس‌های ارائه شده امکان تبادل داده میان برنامه‌های نصب شده بر روی تجهیزات مختلف را درون شبکه LAN مهیا می‌سازد (برنامه‌های مختلف با استفاده از آن به منابع موجود بر روی LAN دسترسی می‌یابند). این برنامه ابتدا برای شبکه اختصاصی IBM نوشته شده و سپس توسط مایکروسافت توسعه داده شده است. NetBIOS به خودی خود قادر به مسیریابی در شبکه نیست و در شبکه‌های محلی مورد استفاده قرار می‌گیرد. در شبکه‌های امروزی، NetBIOS بر روی TCP/IP هم اجرا می‌گردد و سه سرویس مجزای نام (NS)، توزیع دیتاگرام (DGM) و نشست (SSN) را به ترتیب از طریق شماره پورت‌های پیش فرض 137، 138 و 139 ارائه می‌نماید (هم UCP و هم UDP). امروزه از پروتکل مستقل دیگری به نام SMB نیز استفاده می‌شود که از پورت‌های TCP با شماره‌های 139 و 445 استفاده می‌نماید.

مسدود کردن آسب پذیری NetBIOS

برای رفع این آسیب‌پذیری، پیشنهاد می‌گردد کاربران ویندوز وصله به‌روزرسانی را نصب و یا پورت ,138,139,137 TCP و UDP و پورت 445 TCP مربوط به SMB را مسدود نمائید.

آسیب پذیری سرویس mDNS

mDNS به منظور تبدیل نام به آدرس IP در شبکه­های کوچک که فاقد یک سرور نام محلی می باشند، استفاده می­شود (در برخی از چاپگرها، تلفن‌های IP، ذخیره‌گاه‌های NAS و … پیاده‌سازی شده و دایمون‌های آن برای سیستم عامل ویندوز و لینوکس نیز وجود دارد). ساختار بسته­های mDNS همانند بسته­های DNS می­باشد. mDNS از پروتکل UDP و شماره پورت 5353 و آدرس IP های چندپخشی زیر استفاده می­کند:

IPv4: 224.0.0.251

IPv6: FF02::FB

زمانی که یک کلاینت mDNS نیاز به ترجمه یک نام دارد، یک پیام درخواست به صورت چندپخشی در طول شبکه ارسال می­کند و از سیستمی که دارای این نام می­باشد درخواست می­کند تا خودش را معرفی کند. پس از آن سیستم مورد نظر در پاسخ یک پیام که شامل آدرس IP خودش می­باشد، در طول شبکه به صورت چندپخشی ارسال می­کند. تمام سیستم­های موجود در این زیرشبکه می­توانند از این اطلاعات برای به­روز رسانی mDNS cache مربوط به خودشان استفاده کنند.

آسیب پذیری Open DNS Resolver

غیر فعال سازی Recursive DNS بر روی سرورهای لینوکس

/etc/named.conf
/var/named/chroot/etc/named.conf
/etc/bind/named.conf

recursion no;

service named restart

غیر فعال سازی Recursive DNS بر روی سرورهای ویندوز

آموزش رفع این مشکل در سیستم عامل ویندوز در پست دیگری شرح داده شده است

آموزش غیرفعال کردن Recursion در Windows DNS Server