بخشی از مقاله
مهمترين نقاط آسيب پذير يونيکس و لينوکس
سيستم عامل، يکی از عناصر چهار گانه در يک سيستم کامپيوتری است که دارای نقشی بسيار مهم و حياتی در نحوه مديريت منابع سخت افزاری و نرم افزاری است . پرداختن به مقوله امنيت سيستم های عامل ، همواره از بحث های مهم در رابطه با ايمن سازی اطلاعات در يک سيستم کامپيوتری بوده که امروزه با گسترش اينترنت ، اهميت آن مضاعف شده است .
بررسی و آناليز امنيت در سيستم های عامل می بايست با ظرافت و در چارچوبی کاملا" علمی و با در نظر گرفتن تمامی واقعيت های موجود ، انجام تا از يک طرف تصميم گيرندگان مسائل استراتژيک در يک سازمان قادر به انتخاب مستند و منطقی يک سيستم عامل باشند و از طرف ديگر امکان نگهداری و پشتيبانی آن با در نظر گرفتن مجموعه تهديدات موجود و آتی ، بسرعت و بسادگی ميسر گردد .
اکثر کرم ها و ساير حملات موفقيت آميز در اينترنت ، بدليل وجود نقاط آسيب پذير در تعدادی اندک از سرويس های سيستم های عامل متداول است . مهاجمان ، با فرصت طلبی خاص خود از روش های متعددی بمنظور سوء استفاده از نقاط ضعف امنيتی شناخته شده ، استفاده نموده و در اين راستا ابزارهای متنوع ، موثر و گسترده ای را بمنظور نيل به اهداف خود ، بخدمت می گيرند .
مهاجمان ، در اين رهگذر متمرکز بر سازمان ها و موسساتی می گردند که هنوز مسائل موجود امنيتی ( حفره ها و نقاط آسيب پذير ) خود را برطرف نکرده و بدون هيچگونه تبعيضی آنان را بعنوان هدف ، انتخاب می نمايند . مهاجمان بسادگی و بصورت مخرب ، کرم هائی نظير : بلستر ، اسلامر و Code Red را در شبکه منتشر می نمايند. آگاهی از مهمترين نقاط آسيب پذير در سيستم های عامل ، امری ضروری است . با شناسائی و آناليز اينگونه نقاط آسيب پذير توسط کارشناسان امنيت اطلاعات ، سازمان ها و موسسات قادر به استفاده از مستندات علمی تدوين شده بمنظور برخورد منطقی با مشکلات موجود و ايجاد يک لايه حفاظتی مناسب می باشند.
در مجموعه مقالاتی که ارائه خواهد شد ، به بررسی مهمترين نقاط آسيب پذير يونيکس و لينوکس خواهيم پرداخت . در اين راستا ، پس از معرفی هر يک از نقاط آسيب پذير ، علت وجود ضعف امنيتی ، سيستم های عامل در معرض تهديد ، روش های تشخيص آسيب پذيری سيستم و نحوه مقابله و يا پيشگيری در مقابل هر يک از نقاط آسيب پذير ، بررسی می گردد .همزمان با ارائه مجموعه مقالات مرتبط با يونيکس ( پنج مقاله ) ، به بررسی مهمترين نقاط آسيب پذير در ويندوز ، طی مقالات جداگانه ای خواهيم پرداخت .
همانگونه که اشاره گرديد ، اغلب تهديدات و حملات ، متاثر از وجود نقاط آسيب پذير در سيستم های عامل بوده که زمينه تهاجم را برای مهاجمان فراهم می آورد . شناسائی و آناليز نقاط آسيب پذير در هر يک از سيستم های عامل ، ماحصل تلاش و پردازش دهها کارشناس امنيتی ورزيده در سطح جهان است و می بايست مديران سيستم و شبکه در يک سازمان بسرعت با آنان آشنا و اقدامات لازم را انجام دهند.
نقاط آسيب پذير موجود در هر سيستم عامل که در ادامه به آنان اشاره می گردد ، سندی پويا و شامل دستورالعمل های لازم بمنظور برخورد مناسب با هر يک از نقاط آسيب پذير و لينک هائی به ساير اطلاعات مفيد و تکميلی مرتبط با ضعف امنيتی است .
مهمترين نقاط آسيب پذير يونيکس:
يونيکس ، يکی از سيستم های عامل رايج در جهان بوده که امروزه در سطح بسيار وسيعی استفاده می گردد . تا کنون حملات متعددی توسط مهاجمين متوجه سيستم هائی بوده است که از يونيکس ( نسخه های متفاوت ) بعنوان سيستم عامل استفاده می نمايند . با توجه به حملات متنوع و گسترده انجام شده ، می توان مهمترين نقاط آسيب پذير يونيکس را به ده گروه عمده تقسيم نمود :
• BIND Domain Name System
• Remote Procedure Calls (RPC)
• Apache Web Server
• General UNIX Authentication Accounts with No Passwords or Weak Passwords
• Clear Text Services
• Sendmail
• Simple Network Management Protocol (SNMP)
• Secure Shell (SSH)
• Misconfiguration of Enterprise Services NIS/NFS
• Open Secure Sockets Layer (SSL)
در بخش اول اين مقاله ، به بررسی BIND Domain Name System وRemote Procedure Calls (موارد يک و دو) ، خواهيم پرداخت .
اولين نقطه آسيب پذير : BIND Domain Name System
نرم افزار BIND ) Berkeley Internet Name Domain) ، در مقياس گسترده ای و بمنظور پياده سازی DNS)Domain Name Service) ، استفاده می گردد. BIND ، سيستمی حياتی است که از آن بمنظور تبديل اسامی ميزبان ( نظير : www.srco.ir ) به آدرس IP ريجستر شده ،استفاده می گردد .با توجه به استفاده وسيع از BIND و جايگاه حياتی آن در يک شبکه کامپيوتری ، مهاجمان آن را بعنوان يک هدف مناسب بمنظور انجام حملات ، خصوصا" از نوع DoS)Denila Of Service) انتخاب و حملات متنوعی را در ارتباط با آن انجام داده اند.
حملات فوق،از کارافتادن سرويس DNS و عدم دستيابی به اينترنت برای سرويس های مربوطه و ميزبانان را می تواند بدنبال داشته باشد. با اينکه پياده کنندگان BIND ، تلاشی مستمر را از گذشته تا کنون بمنظور برطرف نمودن نقاط آسيب پذير انجام داده اند ، ولی هنوز تعداد زيادی از نقاط آسيب پذير قديمی ، بدرستی پيکربندی نشده و سرويس دهندگان آسيب پذير در آن باقی مانده است .
عوامل متعددی در بروز اينگونه حملات نقش دارد: عدم آگاهی لازم مديران سيستم در خصوص ارتقاء امنيتی سيستم هائی که بر روی آنان Bind deamon بصورت غير ضروری اجراء می گردد و پيکربندی نامناسب فايل ها ، نمونه هائی از عوامل فوق بوده و می تواند زمينه يک تهاجم از نوع DoS ، يک Buffer Overflow و يا بروز اشکال در DNS Cache را بدنبال داشته باشد.از جمله موارديکه اخيرا" در رابطه با ضعف امنيتی BIND کشف شده است مربوط به يک تهاجم از نوع DoS است . مقاله CERT Advisory CA-2002-15 جزئيات بيشتری را در اين رابطه ارائه می نمايد.
از ديگر حملات اخير ، تهاجمی از نوع Buffer Overflow است . مقاله CERT Advisory CA-2002-19 جزئيات بيشتری را در اين رابطه در اختيار قرار می دهد. درتهاجم فوق ، يک مهاجم از نسخه آسيب پذير پياده سازی توابع Resolver مربوط به DNS استفاده و با ارسال پاسخ های مخرب به DNS و اجرای کد دلخواه ، امکان سوء استفاده از نقطه آسيب پذير فوق را فراهم و حتی دربرخی موارد می تواند زمينه بروز يک تهاجم از نوع DoS را باعث گردد .
تهديدی ديگر که می تواند در اين رابطه وجود داشته باشد ، حضور يک سرويس دهنده BIND آسيب پذير در شبکه است .
در چنين مواردی ، مهاجمان از وضعيت فوق استفاده و از آن بمنزله مکانی جهت استقرار داده های غير معتبر خود و بدون آگاهی مديرسيستم استفاده می نمايند. بدين ترتيب ، مهاجمان از سرويس دهنده بعنوان پلات فرمی بمنظور فعاليت های آتی مخرب خود بهره برداری خواهند کرد .
سيستم های عامل در معرض تهديد :
تقريبا" تمامی سيستم های عامل يونيکس و لينوکس بهمراه يک نسخه از BIND ارائه شده اند .در صورت پيکربندی ميزبان بعنوان سرويس دهنده ، نسخه ای از BIND بر روی آن نصب خواهد شد.
نحوه تشخيص آسيب پذيری سيستم
در صورت دارا بودن نسخه خاصی از BIND که بهمراه سيستم عامل ارائه و بر روی سيستم نصب شده است ، می بايست عمليات بهنگام سازی آن را با استفاده از آخرين Patch های ارائه شده توسط توليد کننده ( عرضه کننده ) انجام داد. در صورت استفاده از نسخه BIND مربوط به ISC: Internet Software Consortium ، می بايست از نصب آخرين نسخه BIND ، اطمينان حاصل نمود . در صورتيکه BIND نصب شده بر روی سيستم ، نسخه ای قديمی بوده و يا بطور کامل Patch نشده باشد ، احتمال آسيب پذيری سيستم وجود خواهد داشت .
در اکثر سيستم ها ، دستور : "named - v " ، اطلاعات لازم در خصوص نسخه BIND نصب شده بر روی سيستم را بصورت X.Y.Z نمايش خواهد داد . X ، نشاندهنده نسخه اصلی ، Y ،نشاندهنده جزئيات نسخه و Z نشاندهنده يک Patch Level است . پيشنهاد می گردد ، آخرين نسخه BIND ارائه شده توسط ISC را دريافت و آن را بر روی سيستم نصب نمود. آخرين نسخه موجود Version 9.2.2 بوده و می توان آن را از سايت ISC دريافت نمود. يکی ديگر از رويکردهای کنشگرايانه مرتبط با نگهداری امنيت BIND ، عضويت در گروه های خبری نظير Symantec برای آگاهی از آخرين هشدارهای امنيتی است . در اين راستا می توان از يک برنامه پويشگر بهنگام شده که قادر به بررسی دقيق سيستم های DNS بمنظور تشخيص نقاط آسيب پذيراست ، نيز استفاده گردد .
نحوه حفاظت در مقابل نقطه آسيب پذير
بمنظور حفاظت در مقابل نقاط آسيب پذير مرتبط با BIND موارد زير پيشنهاد می گردد :
• غير فعال نمودن BIND deamon ( به آن named نيز اطلاق می گردد ) بر روی سيستم هائی که بعنوان يک سرويس دهنده DNS در نظر گرفته نشده اند . بمنظور پيشگيری ازاعمال برخی تغييرات خاص ( نظير فعال نمودن مجدد آن ) ، می توان نرم افزار BIND را از روی اينگونه سيستم ها حذف نمود.
• بمنظور بهنگام سازی سرويس دهنده DNS ، از تمامی Patch های ارائه شده توسط توليد کنندگان استفاده و در صورت امکان آن را به آخرين نسخه موجود ارتقاء دهيد . برای دريافت اطلاعات تکميلی در رابطه با نصب مطمئن تر BIND ، از مقالات ارائه شده درسايت CERT و بخش UNIX Security Checklist ، استفاده نمائيد .
• بمنظور پيچيده تر نمودن حملات اتوماتيک و يا پويش سيستم مورد نظر ، Banner مربوط به " Version String " را از BIND حذف و نسخه واقعی BIND را با يک شماره نسخه غيرواقعی در فايل named.conf ، جايگزين نمائيد .
• امکان ارسال انتقالات Zone را صرفا" برای سرويس دهندگان ثانويه DNS در Domain فراهم نمائيد ( secondary DNS servers) . امکان انتقالات Zone در ارتباط با Domain های Parent و Child را غير فعال و در مقابل از امکان Delegation ( واگذاری مسئوليت ) و فورواردينگ ( Forwarding ) استفاده نمائيد .
• امکان Recursion و glue fetching را بمنظور حفاظت در مقابل عماکرد ناصحيح DNS Cache ، غير فعال نمائيد .
• بمنظور حفاظت در رابطه با استفاده از "named" و تحت تاثير قرار دادن تمامی سيستم ، BIND را محدود نمائيد . بنابراين BIND بعنوان يک کاربر non-privilage در دايرکتوری Chroot اجراء می گردد. برای نسخه شمازه نه BIND از آدرس http://www.losurs.org/docs/howto/Chroot-BIND.html استفاده نمائيد .
بمنظور حفاظت در مقابل حملات اخير و مرتبط با نقاط آسيب پذير کشف شده BIND می توان از منابع زير استفاده نمود:
• برای نقطه آسيب پذير DoS در رابطه با ISC BIND 9 از آدرس http//www.cert.org/advisories/CA-2002-15.html استفاده گردد.
• چندين نقطه آسيب پذير DoS در رابطه با ISC BIND 8 از آدرس http://www.isc.org/products/BIND/bind-security.html استفاده گردد .
برای آگاهی و استفاده از پيشنهادات لازم بمنظور نصب ايمن تر BIND بر روی سيستم های سولاريس ، می توان از آدرس : Running the BIND9 DNS Server Securely و آرشيو مقالات ارائه شده در آدرس Afentis استفاده نمود.
دومين نقطه آسيب پذير : ( Remote Procedure Calls (RPC
با استفاده از RPC برنامه های موجود بر روی يک کامپيوتر قادر به اجرای روتين هائی در کامپيوتر دوم از طريق ارسال داده و بازيابی نتايج می باشند . با توجه به جايگاه عملياتی RPC ، استفاده از آن بسيار متداول بوده و درموارد متعددی از آن بمنظور ارائه سرويس های توزيع شده شبکه نظير مديريت از راه دور ، اشتراک فايل NFS و NIS استفاده می گردد.وجود ضعف های امنيتی متعدد در RPC باعث بهره برداری مهاجمان بمنظور انجام حملات مختلفی شده است .دراکثر موارد ، سرويس های RPC با مجوزهای بيش از حد معمول ، اجراء می گردند .
بدين ترتيب يک مهاجم غير مجاز قادر به استفاده از سيستم های آسيب پذير در جهت اهداف خود خواهد بود.اکثر حملات از نوع DoS در سال 1999 و اوايل سال 2000 در ارتباط با سيستم هائی بود که دارای ضعف امنيـتی و نقظه آسيب پذير RPC بودند. مثلا" حملات گشترده و موفقيت آميز در رابطه با سيستم های نظامی امريکا ، بدليل نقطه آسيب پذير RPC کشف شده در صدها دستگاه کامپيوتر مربوط به وزارت دفاع امريکا بوده است . اخيرا" نيز وجود يک ضعف امنيتی DCOM RPC در ويندوز ، باعث انتشار گسترده يک کرم در سطح اينترنت گرديد .
سيستم های عامل در معرض تهديد :
تمامی نسخه های يونيکس و لينوکس که بر روی آنان سرويس های RPC نصب شده است در معرض اين آسيب می باشند .
نحوه تشخيص آسيب پذيری سيستم
با استفاده از يک پويشگر نقاط آسيب پذير و يا دستور " rpcinfo" ، می توان از اجراء يکی از سرويس های متداول RPC بر روی سيستم آگاه گريد :
RPC Service RPC Program Number
rpc.ttdbserverd 100083
rpc.cmsd 100068
rpc.statd 100024
rpc.mountd 100005
sadmind 100232
cachefsd 100235
snmpXdmid 100249
سرويس های RPC ، عموما" از طريق حملات buffer Overflow ، مورد سوء استفاده قرار می گيرند .علت اين امر ، عدم انجام بررسی لازم و کافی در خصوص خطاها و يا اعتبار داده های ورودی توسط برنامه های RPC است . نقاط آسيب پذير Buffer overflow ، اين امکان را برای يک مهاجم فراهم می نمايد که داده غير قابل پيش بينی را ( اغلب بصورت کد مخرب ) به درون حافظه برنامه ، ارسال نمايد .
با توجه به ضعف موجود در رابطه با بررسی خطاء و صحت داده ، داده ارسالی مکان هائی حساس و کليدی که مورد استفاده پردازنده می باشند را بازنويسی می نمايد.در يک تهاجم موفقيت آميز Overflow ، کد مخرب ارسالی ،در ادامه توسط سيستم عامل اجراء می گردد . با توجه به اينکه تعداد زيادی از سرويس های RPC ، با مجوزهای بيش از حد معمول ، اجراء می گردند ، استفاده موفقيت آميز از نقاط آسيب پذير فوق می تواند امکان دسـيابی غير مجاز و از راه دور را به سيستم فراهم می نمايد.
نحوه حفاظت در مقابل نقطه آسيب پذير
بمنظور حفاظت سيستم در مقابل حملات مبتنی بر RPC ، موارد زير پيشنهاد می گردد :
• غير فعال نمودن و يا حذف هر يک از سرويس های RPC که ضرورتی به استفاده از آن بر روی شبکه نمی باشد .
• نصب آخرين Patch ارائه شده در رابطه با سرويس هائی که امکان حذف آنان وجود ندارد:
- برای نرم افزار سولاريس از آدرس ( http://sunsolve.sun.com ) استفاده گردد.
- برای IBM AIX از آدرس : http://www.ibm.com/support/us و http://techsupport.services.ibm.com/server/fixes استفاده گردد.
- برای نرم افزار SGI از آدرس : http://support.sgi.com استفاده گردد .
- برای کامپک ( Digital Unix ) از آدرس http://www.compaq.com/support
- برای لينوکس از آدرس : http://www.redhat.com/apps/support/errata و http://www.debian.org./security استفاده گردد .
• عمليات جستجو بمنظور آگاهی و نصب آخرين Patch مربوطه می بايست بصورت مستمر انجام شود.
• پورت 111 ( TCP و UDP ) مربوط به RPC portmapper و پورت 135 ( TCP و UDP ) مربوط به Windows RPC را در سطح روتر و يا فايروال بلاک نمائيد .
• پورت های Loopback 32770 ، 32789 مربوط بهTCP و UDP را بلاک نمائيد .
• فعال نمودن يک پشته غيراجرائی بر روی سيستم های عاملی که از ويژگی فوق ، حمايت می نمايند. استفاده از يک پشته غيراجرائی ، لايه ای حفاظتی در مقابل تمامی حملات Buffer overflows نبوده ولی می تواند عاملی موثر در جهت مقابله با برخی از حملات استاندارد گردد.
• در ارتباط با سيستم های فايل NFS صادراتی ، مراحل زير می بايست دنبال گردد :
- استفاده از ميزبان / IP مبتنی بر ليست های صادراتی
- پيکربندی سيستم های فايل صادراتی بصورت فقط خواندنی
- استفاده از "nfsbug" برای پويش نقاط آسيب پذير
برای اخذ اطلاعات تکميلی در رابطه با نقاط آسيب پذير RPC ، می توان از آدرس های زير استفاده نمود :
• http://www.cert.org/advisories/CA-2000-17.html
• http://www.cert.org/advisories/CA-1999-05.html
• http://www.cert.org/advisories/CA-1997-26.html
• http://www.cert.org/advisories/CA-2002-26.html
• http://www.cert.org/advisories/CA-2002-20.html
• http://www.cert.org/advisories/CA-2001-27.html
• http://www.cert.org/advisories/CA-2002-25.html
• http://www.cert.org/advisories/CA-1999-08.html
• http://www.cert.org/advisories/CA-2002-11.html
• http://www.cert.org/advisories/CA-1999-16.html
• http://www.cert.org/advisories/CA-2001-11.html
• http://www.cert.org/advisories/CA-1998-12.html
• http://www.cert.org/advisories/CA-2001-05.html
• http://www.cert.org/advisories/CA-2002-10.html
• http://www.cert.org/advisories/CA-2003-10.html
• http://www.cert.org/advisories/CA-2003-16.html
• http://www.cert.org/advisories/CA-2003-19.html
در بخش دو م اين مقاله به بررسی ساير نقاط آسيب پذير يونيکیس و لينوکس خواهيم پرداخت .
مهمترين نقاط آسيب پذير يونيکس و لينوکس ( بخش دوم )
در بخش اول اين مقاله به بررسی دو مورد از نقاط آسيپ پذير اشاره گرديد. در اين بخش به بررسی نقاط آسيب پذير Apache Web Server و روش های تائيد کاربران ، خواهيم پرداخت .
سومين نقطه آسيب پذير : Apache Web Server
آپاچی ( Apache) يکی از متداولترين سرويس دهندگان وب بر روی اينترنت است . در مقايسه با سرويس دهنده وب مايکروسافت ( IIS ) ، آپاچی مسائل و مشکلات امنيتی کمتری را داشته ولی همچنان دارای آسيب پذيری خاص خود است .
علاوه بر وجود نقاط آسيب پذير در ماژول ها و کد آپاچی ( CA-2002-27 و CA-2002-17 ) ، تکنولوژی های CGI و PHP نيز دارای نقاط آسيب پذيری خاص خود بوده که ضعف های امنيتی آنان به سرويس دهنده وب نيز سرايت می گردد. در صورت وجود نقاط آسيب پذير در سرويس دهنده آپاچی و يا عناصر مرتبط به آن ، زمينه تهديدات زير فراهم می گردد :
• غير فعال نمودن سرويس ( DoS )
• نمايش و بمخاطره انداختن فايل ها و داده های حساس
• دستيابی به سرويس دهنده از راه دور
• بمخاطره افتادن سرويس دهنده ( دستکاری و خرابی سايت )
سيستم های عامل در معرض تهديد
تمامی سيستم های يونيکس قادر به اجراء آپاچی می باشند . آپاچی بصورت پيش فرض بر روی تعداد زيادی از نسخه های يونيکس و لينوکس ، نصب می گردد .علاوه بر امکان فوق ، آپاچی را می توان بر روی ميزبانی ديگر که از سيستم عاملی مختلف نظير ويندوز استفاده می نمايد نيز نصب نمود. اين نوع از نسخه های آپاچی نيز می تواند دارای نقاط آسيب پذير خاص خود باشد .
نحوه تشخيص آسيب پذيری سيستم
بمنظور آگاهی و کسب اطلاعات لازم در خصوص نحوه تشخيص آسيب پذيری سرويس دهنده وب آپاچی ، می توان از آدرس های زير استفاده نمود :
• در رابطه با Apache 1.3.x را می توان از آدرس http://www.apacheweek.com/features/security-13
• برای Apache 2.0.x می توان از آدرس http://www.apacheweek.com/features/security-20
آدرس های اشاره شده ، دارای اطلاعات فنی لازم بمنظور نحوه تشخيص آسيب پذيری سيستم و پيشنهادات لازم در خصوص ارتقاء وضعيت امنيتی می باشند . استفاده از آدرس: http://httpd.apache.org نيز در اين زمينه مفيد است .
نحوه حفاظت در مقابل نقطه آسيب پذير
بمنظور حفاظت يک سرويس دهنده وب آپاچی ، پيشنهادات زير ارائه می گردد :
• اطمينان از نصب آخرين patch ارائه شده
- در اين رابطه می توان از آدرس http://httpd.apache.org بمنظور آگاهی از آخرين وضعيت نسخه ها و Patch levels استفاده نمود.
- بمنظور دستيابی به Source code اکثر نسخه های آپاچی، می توان از آدرس http://httpd.apache.org/download.cgi استفاده نمود.
- بمنظور آگاهی و دريافت آخرين Patch های ارائه شده می توان از آدرس http://www.apache.org/dist/httpd/patches/ استفاده نمود.
• اطمينان از patching عناصر کليدی سيستم عامل که آپاچی بعنوان مرجع از آنان استفاده می نمايد .در اين رابطه لازم است که صرفا" ماژول های ضروری بمنظور صحت عملکرد سرويس دهنده ، در آپاچی کمپايل گردند .لازم است به اين نکته اشاره گردد که کرم( mod_ssl ( CA-2002-27 نمونه ای کامل در اين زمينه بوده که از نقاط آسيب پذير در( OpenSSL ( CA-2002-23 استفاده نموده است .
• از اجرای آپاچی بعنوان ريشه ، اجتناب و می بايست بدين منظور ، کاربر و يا گروهی خاص با حداقل مجوز ايجاد گردد. ساير پردازه های سيستم ضرورتی به اجراء تحت کاربر و يا گروه فوق را نخواهند داشت .
• Chroot ، پتانسيلی است که باعث تعريف مجدد محدوده يک برنامه می گردد . در حقيقت chroot ، باعث تعريف مجدد دايرکتوری ROOT" و يا "/" برای يک برنامه و يا يک Login session می گردد .chroot می تواند بعنوان يک لايه تدافعی استفاده گردد . مثلا" در صورتيکه فردی به کامپيوتر شما دستيابی پيدا نمايد ، قادر به مشاهده تمامی فايل های موجود بر روی سيستم نخواهد بود .
علاوه بر محدوديت فوق ، محدوديت هائی در خصوص اجرای برخی از دستورات نيز بوجود می آيد.در اين رابطه يک دايرکتوری با نام chroot/ ، ايجاد و تمامی سرويس های مورد نطر با يک انظباط خاص در آن مستقر می گردند . مثلا" سرويس دهنده آپاچی در chroot/httpd / قرار می گيرد. با توجه به موارد فوق ، می بايست آپاچی را در يک محيط chroot اجراء نمود . درصورتيکه آپاچی بصورت chrooted اجراء و فعاليت خود را آغاز نمايد ، امکان دستيابی آن به ساير بخش های موجود در ساختار دايرکتوری سيستم عامل و خارج از chroot وجود نخواهد داشت . بدين ترتيب يک لايه تدافعی مناسب در خصوص سوء استفاده های احتمالی ايجاد می گردد.
بعنوان نمونه ، ممکن است يک shell فراخوانده شده و با توجه به اينکه bin/sky / در chroot قرار ندارد ، می تواند زمينه سوء استفاده احتمالی را فراهم نمايد. لازم است به اين نکته مهم نيز اشاره گردد که Chrooting آپاچی می تواند اثرات جا نبی نامطلوبی را در ارتباط با CGI,PHP ، بانک های اطلاعاتی و ساير ماژول ها و يا ارتباطاتی که محيط سرويس دهنده وب بمنظور سرويس دهی به آنان نيازمند دستيابی به توابع کتابخانه ای خارجی است را بدنبال داشته باشد .روش های متعددی بمنظور chrooting وجود داشته و می بايست از مستندات نرم افزار مورد نظر ، بعنوان يک منبع اطلاعاتی مناسب در خصوص ارائه راهکارهای مربوطه ، استفاده گردد
• بمنظور مديريت يک سرويس دهنده وب ، لازم است فيدبک های لازم در خصوص فعاليت و کارآئی سرويس دهنده و ساير مسائلی که ممکن است يک سرويس دهنده با آنان برخورد نمايد را اخذ و در ادامه با آناليز آنان تمهِيدات لازم در خصوص مسائل موجود را بکار گرفت . سرويس دهنده آپاچی ، قابليت ها و پتانسيل های انعطاف پذيری را در خصوص logging ارائه می نمايد . بنابراين لازم است عمليات logging با دقت نظر بالا بصورت موثر و موشکافانه انجام تا امکان رديابی هر نوع فعاليت امنيتی غير مجاز و يا رفتار غير منطقی سرويس دهنده ، فراهم گردد .پيشنهاد می گردد که با يک نظم خاص از اطلاعات موجود در فايل های لاگ ، آرشيو تهيه شود . بدين ترتيب ، امکان مديريت فايل های لاگ و بررسی آنان فراهم خواهد شد. بمنظور آشنائی با فرمت های متفاوت لاگ می تواند از منابع زير استفاده نمود :
- برای Apache 1.3.x از آدرس http://httpd.apache.org/docs/logs.html استفاده شود .
- برای Apache 2.0.x از آدرس http://httpd.apache.org/docs-2.0/logs.html استفاده شود .
در موارد متفاوتی و با توجه به شرايط پيش آمده ممکن است محتوی فايل های لاگ بتنهائی کافی نباشد . وضعيت فوق در موارديکه از PHP ، CGI و يا ساير تکنولوژی های مبتنی بر اسکريپت استفاده می گردد ، تشديد و می توان بمنظور افزايش توان آناليز يک تهاجم و سوءاستفاده از يک ضعف امنيتی ، اقدام به ثبت لاگ های مربوط به GET و POST نمود.لاگ نمودن عمليات مرتبط به GET و POST می تواند از طريق mod_Security صورت پذيرد. ModSecurity يک سيستم تشخيص مزاحمين ( Intruder detection ) یوده و پيشگيری های لازم در خصوص يک برنامه وب را ارائه می نمايد . سيستم فوق بهمراه سرويس دهنده وب مستقر و يک پوشش امنيتی مناسب را در جهت پيشگيری از يک تهاجم در ارتباط با برنامه های وب فراهم می نمايد . ModSecurity ، از سرويس دهنده آپاچی حمايت می نمايد .
- http://www.modsecurity.org
- http://www.securityfocus.com/infocus/17064.152.44.126 152.44.126
• PHP، CGI،SSI و ساير اسکريپت ها . در اين رابطه موارد زير پيشنهاد می گردد :
- PHP,CGI,SSI و ساير زبان های اسکريپت را غير فعال نمائيد ( مگر اينکه ضرورتی جدی در رابطه با آنان وجود داشته باشد ).
- SSI یا Server Side Includes را که می تواند زمينه مساعدی بمنظور سوء استفاده از سرويس دهنده و الزام آن در جهت اجرای کد ناخواسته گردد را غير فعال نمائيد
.
- در صورتيکه ضروری است که از PHP,CGI,SSI و يا ساير زبان های اسکريپت استفاده گردد ، می بايست از SuEXEC استفاده شود. suEXEC ، امکان اجرای اسکريپت ها تحت آپاچی بهمراه يک User Id در مقابل يک Apache User Id را فراهم می نمايد در حقيقت suEXEC اين امکان را برای کاربران آپاچی فراهم می نمايد که قادر به اجرای برنامه های SSI و CGI تحت يک User Id متفاوت نسبت به User Id مربوط به فراخوانی سرويس دهنده وب باشند.بدين ترتيب تهديدات امنيـتی کاهش و امکان نوشتن و اجرای برنامه های SSI و CGI اختصاصی نوشته شده توسط مهاجمان ، حذف خواهد شد . استفاده از suEXEC ،می بايست توام با آگاهی و دانش لازم باشد چراکه در صورت استفاده نادرست و يا عدم پيکربندی مناسب و شناخت نسبت به مديريت setupid Root ، خود باعث بروز حفره های امنيتی ديگر خواهد شد..
