چگونه پنهان کردن وب سرور امنیت را بهبود میبخشد
پنهان کردن یا ناشناس کردن سرور عبارت است از حذف جزئیات هویتی که ممکن است به مهاجمین اینترنتی در شناسایی سیستم عامل و نوع وب سرور شما کمک کند. در حالی که اینگونه اطلاعات به درد یک کاربر عادی نمیخورند یا خیلی کم کاربرد هستند، معمولاً نقطهی شروع کار هکرها و نفوذ گرها و کسانی که دانش کافی در زمینه نفوذ ندارند و فقط از ابزارها برای نفوذ استفاده میکنند محسوب میشوند. در این مقاله به بررسی روشهایی برای کاهش خطر اینگونه شناسایی شدن میپردازیم. بدلیل آسیب پذیری زیاد وب سرور IIS (وب سرور مایکروسافت) اکثر مثالهای زیر بر روی وب سرور IIS متمرکز شدهاند ولی مقداری هم اقدامات تشخیص وب سرور آپاچی نیز پوشش داده شده است. با اینکه کاربران IIS از این پنهان سازی وب سرور سود میبرند اما ناشناس کردن وب سرور به مدیر وب سرور مرتبط هست .
چرا شما از جایی که یک هکر دست به کار میبرد، شروع نکنید؟
بهتر است به قضیه از دید یک هکر بنگریم: آسیب پذیریهای امنیتی معمولا به نسخه و سازندهی نرم افزار بستگی دارند. انجام عملیات هک بدون داشتن این اطلاعات بدلیل درخواستهای ارسالی اشتباه زیاد از طرف هکر بدلیل نداشتن اطلاعات صحیح ممکن است باعث شود که درخواستهای هکر رد شوند و یا اینکه سیستم بطور موقت از دسترس خارج شود. بنابراین دانستن جزئیات وب سرور ، موفقیت حملات را افزایش میدهد. اگر هکری بتواند اکسپلویتها و نقاط آسیب پذیر سیستم را هدف قرار دهد، احتمال موفق آمیز بودن هک قبل از شناسایی شدن بمراتب بالا میرود. هکرها میتوانند از اکسپلویتهای تازه شناسایی شده برای صدمه زدن بیشتر به سیستم هایی که اطلاعات شناسایی قابل دسترس دارند استفاده کنند. سیستمی که براحتی قابل شناسایی باشد، هکرها را به خود جذب میکند.
ماژولی بنام ServerMask برای وب سرور IIS ساخته شده است که میتواند با اکثر مشکلاتی که در مورد وب سرور ویندوز در اینجا مطرح میشوند، مبارزه کند.
هدر سرور همه اطلاعات را نمایش میدهد
اکثر وب سرورها براحتی مشخصات خود و سیستم عامل را برای هر کسی که مشتاق به دانستن باشد، فاش میکنند. استفاده از ابزار پرس و جوی شبکه مانند free ieHTTPHeaders و یا ابزار چک کننده هدر مثل Header Check، میتوانید بفهمید هدر سرور HTTP چیست. کافیست صفحهی اصلی یک وب سایت را باز کنید و سپس با استفاده از ابزار چک کننده هدر ،هدرها ی HTTP که توسط سرور فرستاده میشوند را بررسی کنید. در میان آنها، به احتمال بسیار زیاد چیزی شبیه به این خواهید یافت:
Server: Microsoft-IIS/5.0
در تنظیمات پیش فرض Apache نیز، سرور همانقدر قابل شناسایی است:
Server: Apache/2.0.41-dev (UNIX(
وابسته به پلتفرم مورد استفاده شما میتوانید این هدر HTTP سرور را به روشهای مختلف حذف و یا مبهم کنید. کاربران Apache 2.x که ماژول mod_headers را لود کرده اند میتوانند از یک دستور ساده در فایل httpd.conf خود، بصورت زیر، استفاده کنند:
“نام جدید سرور” Header set Server
متاسفانه در نسخههای قبلی Apache از طریق mod_headers نمیتوانید هدر سرور را تغییر دهید. کاربران IIS میتوانند IISLockDown را نصب و سپس از گزینهی تنظیمات در فایل INI در URLScan برای حذف و یا جایگزین کردن هدر استفاده کنند. در صورتی که از سرور اپلیکیشن Cold Fusion استفاده میکنید، حواستان به URLScan باشد زیرا این روش، هِدر سرور را در صفحات CFM به هم ریخته و جایگزین میکند. در اصل، وقتی از URLScan استفاده میکنید، حذف کردن هِدر بهترین گزینه است زیرا اگر سعی کنید آنرا با چیز دیگری جایگزین کنید، به پایین هِدر میرود. این باعث میشود که بقیه بدانند شما از URLScan بر روی IIS خود استفاده میکنید.
پسوند های فایل ناخوشایند
نمایش دادن پسوند هایی مانند .asp و یا .aspx بوضوح نشان دهندهی این است که در حال استفاده از سرور مایکروسافت هستید و در حالت کلی، پنهان کردن پسوند های فایل روش خوبی برای پنهان کردن تکنولوژی تولید صفحات پویا محسوب میشود. میتوانید مپینگ اپلیکیشن خود را تغییر دهید ( .asp به .htm، .foo و یا هر چیز دیگری تغییر پیدا میکند) اما مپینگهای یک به یک اینگونه ممکن است باعث سخت شدن ترکیب تکنولوژیهای سمتِ سرور (Server-side) و حتی بیشتر شدن دردسرهای انتقال سایت شود. استفاده نکردن از این پسوندها، هم از جنبهی امنیتی و هم از جنبهی راحتی در نقل و انتقالات سایت و تبادل محتوا ایدهی بسیار بهتری است. افرادی که از Apache استفاده میکنند بهتر است نگاهی به mod_negotiation بیاندازند. باید حواستان به هِدر Content-Location در پاسخِ سرور باشد زیرا این پاسخ میتواند پسوند فایلی را که در URL نمایش داده نمیشود و شما قصد پنهان کردن آنرا دارید لو بدهد. شاید نیاز باشد که این هِدر را بطور جداگانه از طریق mod_headers مدیریت کنید. درست به همین شکل، ابزاری بنام PageXchanger را به منظور پنهان سازی پسوند فایل کاربران IIS وجود دارد.
کوکیهای نیمه آماده
کوکیِ شناسه (ID) در session یا جلسه ASP ، که توسط شی ء Session برای تعیین وضعیت کلاینت استفاده میشود، یکی دیگر از راههای لو رفتن است:
Set-Cookie: ASPSESSIONIDQGQGGWFC=MGMLNKMDENPEOPIJHPOPEPPB;
میتوانید برای جلوگیری از قرار گرفتن این کوکی، ASP Session State را غیرفعال کنید اما با این کار دیگر نخواهید توانست از شی ء Session برای تعیین وضعیت کلاینت استفاده کنید. به علاوه میتوانید بمنظور تغییر نام هر شناسهی کوکی، یک فیلتر ISAPI ایجاد کنید. از طرف دیگر، session هایASP متمرکز بر منابع هستند و خاموش کردن آنها از طرفی مقیاس پذیری و عملکرد اپلیکیشن ASP شما را افزایش میدهد و از یک طرف نیز به گمنام سازی سرور شما کمک میکند.
اینها را دور بریزید
WebDAV: روش دیگر شناسایی سرورهای مایکروسافت، اجرای WebDAV (اکستنشنهای HTTP برای Distributed Authoring and Versioning یا “تالیف و نسخهی توزیع شده” ) توسط آنهاست. WebDAV مختص مایکروسافت و یا IIS نیست بلکه یک استاندارد پیشنهادی (RFC 2518) با گروهِ کار IETF است. با این حال، پشتیبانیِ WebDAV مایکروسافت، اطلاعات زیادی را به هِدرهای فرستاده شده توسط سرور اضافه میکنند بخصوص زمانی که درخواستی برای HTTP OPTIONS به سرور فرستاده میشود. اگر از WebDAV (برای پشتیبانی Outlook Web Access و یا Web Folders ) استفاده نمیکنید، میتوانید آنرا بطور کامل از طریق ویرایش رجیستری ،استفاده از IISLockDown و یا استفاده از URLScan غیرفعال کنید.
هِدرهای دیگر: برخی از وب سرورها ماهیت خود را با نشان دادن هِدرهای بخصوصی در جوابهای HTTP فاش میکنند و بهتر است چهار هِدر محبوب IIS حذف و یا بررسی شوند. هِدرهای X-Powered-By و X-AspNet-Version نشانههای بارز این هستند که شما از ASP.NET و بنحوی از IIS استفاده میکنید. تعداد بسیار کمی از سرورهای محبوب وب در پاسخ به درخواستهای OPTIONS ، هِدر Public میفرستند (در حالی که تقریباً تمامیِ سرورها یک هِدر Allow در پاسخ میفرستند). وجود Public بخوبی نشان دهندهی این است که به یک باکس IIS متصل هستید و باید به فکر پنهان سازی باشید. نکتهی آخر اما بسیار پر اهمیت این است که باید هِدر MicrosoftOfficeWebServer را پنهان کنید. در حالی که این کار بر روی انتشار FrontPage تاثیری نخواهد گذاشت اما اگر از این اکستنشنهای سرور برای هر منظور دیگری استفاده میکنید، بهتر است این روش را امتحان کنید.
Integrated Windows Authentication (احراز هویت یکپارچه ویندوز): کاربران IIS نباید به احراز هویت یکپارچه ویندوز ، بخصوص به عنوان راهی برای پنهان کردن چیزی در سرور، تکیه کنند. از طریق این روش ممکن است چیزی را که سعی در پنهان کردن آن دارید، لو بدهید زیرا یک هکر یا اسکریپت براحتی میتواند باکس ویندوز را از طریق هِدرهای WWW-Authenticate فرستاده شده از طرف سرور، شناسایی کند. وقتی یک فایل یا دیرکتوری توسط NT Challenge-Response Authentication (پاسخ احراز هویت) محافظت میشود، یکی از هِدرهای احراز هویت شامل رشتهی “NTLM” (NT LAN Manager)که یکی از روشهای احراز هویت مختص به مایکروسافت است، میشود.
حواستان به هِدرهایتان باشد
تعداد و ترتیب هِدرهای HTTP و وجود یا عدم وجود برخی از هِدرهای مختصِ پلتفرم، راههایی برای شناسایی سرور وب شما در اختیار هکرهای پیشرفتهتر میگذارد. برای کاربران IIS، یک فیلتر ISAPI میتواند ترتیبِ هدر مختص به مایکروسافت را طوری تغییر دهد که ، به عنوان مثال، از Apache تقلید کند. کاربران Apache میتوانند با دستکاری کردن محل و ترتیب دستورهای هِدر در mod_headers، به هر ترتیبی از هِدرها برسند.
صفحات پیش فرض:
صفحات، پیامها و انواع اسکریپتها ی پیش فرض معمولا حاوی سرنخهایی در مورد هویت سرور هستند و به همین دلیل باید حذف و یا اصلاح شوند. نرمافزار پشت یک سرور وب معمولاً پیامهای ارور را در چرخهی درخواست/ پاسخ HTTP پس میفرستد و ارورهای HTTP تغییر داده شده میتوانند هویت سرور اپلیکیشن، سرور دیتا بیس، سرور وب و همچنین سیستم عامل را مخفی کنند. در این مطلب نحوهی استفاده از ارورهای HTTP تغییر داده شده در Apache را خواهید دید. از انجام دادن این کار بر روی یک سرور توسعه بپرهیزید زیرا در صورتی که بدرستی انجام شود، باعث مخفی شدن ارورهای اسکریپتینگ سمتِ سرور و دیتابیس میشود و این کار، فرایند اشکال زدایی اپلیکیشنها را برای توسعه دهندگان دشوار میسازد. صفحات ، اسکریپتها و اسناد مربوط به مدیریت سرور اپلیکیشن و یا وب سرور را که در روت سرور وب شما نصب شده اند، حذف و یا پنهان کنید و فراموش نکنید که صفحات پیش فرض خانه را جایگزین کنید.
به هیچ سرویس اضافهای نیاز نیست
علاوه بر سرویس HTTP، بسیاری از کامپیوترهایی که از آنان به عنوان سرور وب استفاده میشود، سرویسهای شبکهی دیگری را نیز در خود دارند. معمولترین این سرویسها، FTP و SMTP هستند. بدلایل امنیتی در کل، از سرویسهای پیش فرض FTP و SMTP در IIS مایکروسافت پرهیز کنید. علی رغم راحتیای که سرویسهای یکپارچه به ارمغان میآورند، نیازی به داشتن همزمان و بههم پیوستهی سرویسهای وب، FTP و SMTP نیست. البته این مساله، در Apache مشکل ساز نیست زیرا سرور وب با سرویسهای FTP و SMTP از طریق یک سرویس مشترک مدیریتی در ارتباط نیستند. اگر از این دو سرویس استفاده میکنید، بدانید که آنها هویت سرور IIS شما را فاش میکنند.
وقتی اتصال با سرویس SMTP برقرار میشود، سرور گیرنده یک پیام خوشامدگویی قابل خواندن توسط انسان ( بنر SMTP) به کلاینت میفرستد. چیزی که در پیام خوشامدگویی دیده میشود، تاثیری در سرویس ایمیل ندارد اما درست مانند هِدر سرور HTTP، حاوی اطلاعاتی در مورد نرم افزارهای فعال در باکس میباشد. سرویس پیش فرض SMTP در ویندوز، این اطلاعات را در دسترس قرار میدهد.
سرور پیش فرض IIS FTP مایکروسافت نیز یک بنر شناخته شده را نمایش میدهد. از آنجایی که اصلاح کردن بنر FTP پروسهای پیچیدهتر از اصلاح بنر SMTP است، بهترین گزینهی پیش روی شما استفاده از یک سرور دیگرِ FTP مانند سرور Serv-U محصول RhinoSoft است که قادر به نمایش هر پیام متنی در بنر FTP باشد. از مزایای دیگر سرویسهای شخص ثالت FTP میتوان به این مورد اشاره کرد که این سرویسها، در موارد امنیتی و وقتی صحبت از اقدامات امنیتی مانند دادن دایرکتوری لاگین هر کاربر، به میان میآید، دست شما را برای انجام تغییرات و اقدامات مورد نیاز باز میگذارند.
ورودیهای ناسالم
بسیاری از اکسپلویتهای مختصِ پلتفرم از رشتههای URL پیچیده برای دسترسی پیدا کردن به یک شِل و یا برنامهی CGI استفاده میکنند که به نوبهی خود مورد استفادهی هکرها برای شناسایی ساختار پیش فرض فایل در یک سیستم عامل قرار میگیرد. به محض اینکه شِل و برنامهی CGI هک شوند و فایل سیستم آشکار شود، راه برای ورود هکرها باز است. بهترین دفاع در برابر این خطر، استفاده از یک فیلتر برای ورودیهای کاربران است که کاراکترهای غیرقابل قبول (مانند کاراکترهای متا و اینکدینگ احتمالیِ آنها) را از دادههای کاربر حذف میکند. استاندارد فعلی در مورد IIS، فیلتر IISLockDown/URLScan است. نسل جدیدی از فایروالهای اپلیکیشن، این محافظت را تا سطح لایهی اپلیکیشن در پشت سرور پیش میبرند. در دنیای Apache، پاکسازیِ ورودیهای کاربران یکی از وظایف نویسندگان CGI محسوب میشوند. اگر در حال آماده سازی یک باکس جدید هستید، بهتر است به فکر ایجاد تغییراتی درساختار پیش فرضِ فایل نیز باشید. پاکسازیِ ورودیها و ایجاد تغییرات در ساختار فایل، دو کار انجام میدهند: از طرفی به پنهان کردن باکس کمک و از طرف دیگر اکسپلویتهای معمول را خنثی میکنند.
جستجو در میان پشتهها (Stack)
حتی زمانی که تمامی نشانههای آشکار را از لایهی اپلیکیشن در وب سرور خود حذف کردید، ضعفهایی در لایههای پایینی شبکه باقی میمانند. هر سرور دارای اتصال شبکه، دارای پشتهِ پروتکل شبکه است که در معرض بررسی و شناسایی قرار دارد. بهترین اسکنرهای پشته (مانند NMAP از کمپانی insecure.org) میتوانند با استفاده از تکنیکهای مختلفی برای شناسایی پشتهی TCP، اکثر سیستمهای عامل را شناسایی کنند. پشتههای IP مختص به یک سیستم عامل نیز توسط پروتکل ICMP که توسط ابزار محبوب Ping مورد استفاده قرار میگیرد، قابل شناسایی است. اولین اقدام دفاعی در برابر چنین آسیب پذیری های مربوط به اسکن شبکه، استفاده از یک فایروال خوب است. با این وجود، با تحلیل دقیق شبکه، میتوان با بررسیِ بستههایی که در جواب به درخواستهای HTTP از فایروال اجازهی عبور از وب سرور را میگیرند، باکس را شناسایی کرد.
Netcraft در حال دید زدن شماست
نگاهی به ابزار “What’s that site running” در Netcraft بیاندازید. اگر ابزار پروفایلینگ سایت را روی وب سایت خودتان امتحان کنید، خواهید دید که به احتمال قوی، این ابزار اطلاعات درستی در مورد سیستم عامل و سرور وب در اختیارتان خواهد گذاشت. تغییر دادن هِدر HTTP باعث میشود که Netcraft مقادیری غلط و یا در صورتی که هِدر بطور کامل حذف شود، مقدار unknown از وب سرور بدست بیاورد. البته در نظر داشته باشید که این تغییرات بلافاصله بر عملکرد Netcraft تاثیر نمیگذارند زیرا این ابزار نتایج را تا مدتی cache میکند.
با تمامی این اوصاف، باز هم این احتمال وجود دارد که حتی با وجود یک فایروال خوب نیز، سیستم عامل شما شناسایی شود. برای اینکه Netcraft را مجبور کنید تا سیستم عامل شما را “ناشناس” گزارش کند، باید برخی از تنظیمات پیش فرض TCP/IP، مانند سایز پنجره (RWIN)، حداکثر واحدهای انتقالی (MTU)، حداکثر سایز سگمنت (MSS) و یا طول عمر هِدر IP (TTL)، را دستکاری کنید. تغییر دادن این تنظیمات عملکرد سرور شما را، بسته به شرایط شبکه، به طرق مختلف تحت الشعاع قرار میدهد. به همین دلیل پیشنهاد میشود که نهایت دقت را در اعمال این تغییرات داشته باشید. اما در دست یک مدیر شبکهی ماهر، این استراتژی اقدامی محکم در مقابله و پیشگیری از درز اطلاعات از طریق اسکن کردن پشتهها به حساب میآید.
بهتر است مراقب باشیم
هیچ ترکیبی از این اقدامات پیشگیرانه و یا حتی هیچ ترکیبی از فایروالها و IDSها، بطور کامل قادر به ناشناس کردن وب سرور شما و شکست دادن یک هکر حرفهای نیست. درست مانند ایمن سازی سرور، ناشناس کردن سرور نیز برای مقابله با اکثریت هکرها اقدام مناسبی است. و باز هم، درست مانند تمام جنبههای امنیت شبکه، این مساله جدالی تمام نشدنی برای یک قدم جلو ماندن از آدم بدهای داستان است.
ترجمه : شراره یعقوبی