مهمترين نقاط آسيب پذير يونيکس و لينوکس ( بخش اول ) سيستم عامل، يکی از عناصر چهار گانه در يک سيستم کامپيوتری است که دارای نقشی بسيار مهم و حياتی در نحوه مديريت منابع سخت افزاری و نرم افزاری است . پرداختن به مقوله امنيت سيستم های عامل ، همواره از بحث های مهم در رابطه با ايمن سازی اطلاعات در يک سيستم کامپيوتری بوده که امروزه با گسترش اينترنت ، اهميت آن مضاعف شده است . بررسی و آناليز امنيت در سيستم های عامل می بايست با ظرافت و در چارچوبی کاملا" علمی و با در نظر گرفتن تمامی واقعيت های موجود ، انجام تا از يک طرف تصميم گيرندگان مسائل استراتژيک در يک سازمان قادر به انتخاب مستند و منطقی يک سيستم عامل باشند و از طرف ديگر امکان نگهداری و پشتيبانی آن با در نظر گرفتن مجموعه تهديدات موجود و آتی ، بسرعت و بسادگی ميسر گردد . اکثر کرم ها و ساير حملات موفقيت آميز در اينترنت ، بدليل وجود نقاط آسيب پذير در تعدادی اندک از سرويس های سيستم های عامل متداول است . مهاجمان ، با فرصت طلبی خاص خود از روش های متعددی بمنظور سوء استفاده از نقاط ضعف امنيتی شناخته شده ، استفاده نموده و در اين راستا ابزارهای متنوع ، موثر و گسترده ای را بمنظور نيل به اهداف خود ، بخدمت می گيرند . مهاجمان ، در اين رهگذر متمرکز بر سازمان ها و موسساتی می گردند که هنوز مسائل موجود امنيتی ( حفره ها و نقاط آسيب پذير ) خود را برطرف نکرده و بدون هيچگونه تبعيضی آنان را بعنوان هدف ، انتخاب می نمايند . مهاجمان بسادگی و بصورت مخرب ، کرم هائی نظير : بلستر ، اسلامر و 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 ، سيستمی حياتی است که از آن بمنظور تبديل اسامی ميزبان ( نظير : ) به آدرس 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 بوده و می توان آن را از سايت دريافت نمود. يکی ديگر از رويکردهای کنشگرايانه مرتبط با نگهداری امنيت BIND ، عضويت در گروه های خبری نظير برای آگاهی از آخرين هشدارهای امنيتی است . در اين راستا می توان از يک برنامه پويشگر بهنگام شده که قادر به بررسی دقيق سيستم های DNS بمنظور تشخيص نقاط آسيب پذيراست ، نيز استفاده گردد . نحوه حفاظت در مقابل نقطه آسيب پذير بمنظور حفاظت در مقابل نقاط آسيب پذير مرتبط با BIND موارد زير پيشنهاد می گردد : غير فعال نمودن BIND deamon ( به آن named نيز اطلاق می گردد ) بر روی سيستم هائی که بعنوان يک سرويس دهنده DNS در نظر گرفته نشده اند . بمنظور پيشگيری ازاعمال برخی تغييرات خاص ( نظير فعال نمودن مجدد آن ) ، می توان نرم افزار BIND را از روی اينگونه سيستم ها حذف نمود. بمنظور بهنگام سازی سرويس دهنده DNS ، از تمامی Patch های ارائه شده توسط توليد کنندگان استفاده و در صورت امکان آن را به آخرين نسخه موجود ارتقاء دهيد . برای دريافت اطلاعات تکميلی در رابطه با نصب مطمئن تر BIND ، از مقالات ارائه شده درسايت CERT و بخش ، استفاده نمائيد . بمنظور پيچيده تر نمودن حملات اتوماتيک و يا پويش سيستم مورد نظر ، 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 از آدرس استفاده نمائيد . بمنظور حفاظت در مقابل حملات اخير و مرتبط با نقاط آسيب پذير کشف شده BIND می توان از منابع زير استفاده نمود: برای نقطه آسيب پذير DoS در رابطه با ISC BIND 9 از آدرس استفاده گردد. چندين نقطه آسيب پذير DoS در رابطه با ISC BIND 8 از آدرس استفاده گردد . برای آگاهی و استفاده از پيشنهادات لازم بمنظور نصب ايمن تر BIND بر روی سيستم های سولاريس ، می توان از آدرس : و آرشيو مقالات ارائه شده در آدرس استفاده نمود. دومين نقطه آسيب پذير : ( 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 ارائه شده در رابطه با سرويس هائی که امکان حذف آنان وجود ندارد: - برای نرم افزار سولاريس از آدرس ( ) استفاده گردد. - برای IBM AIX از آدرس : و استفاده گردد. - برای نرم افزار SGI از آدرس : استفاده گردد . - برای کامپک ( Digital Unix ) از آدرس - برای لينوکس از آدرس : و استفاده گردد . عمليات جستجو بمنظور آگاهی و نصب آخرين Patch مربوطه می بايست بصورت مستمر انجام شود. پورت 111 ( TCP و UDP ) مربوط به RPC portmapper و پورت 135 ( TCP و UDP ) مربوط به Windows RPC را در سطح روتر و يا فايروال بلاک نمائيد . پورت های Loopback 32770 ، 32789 مربوط بهTCP و UDP را بلاک نمائيد . فعال نمودن يک پشته غيراجرائی بر روی سيستم های عاملی که از ويژگی فوق ، حمايت می نمايند. استفاده از يک پشته غيراجرائی ، لايه ای حفاظتی در مقابل تمامی حملات Buffer overflows نبوده ولی می تواند عاملی موثر در جهت مقابله با برخی از حملات استاندارد گردد. در ارتباط با سيستم های فايل NFS صادراتی ، مراحل زير می بايست دنبال گردد : - استفاده از ميزبان / IP مبتنی بر ليست های صادراتی - پيکربندی سيستم های فايل صادراتی بصورت فقط خواندنی - استفاده از "nfsbug" برای پويش نقاط آسيب پذير برای اخذ اطلاعات تکميلی در رابطه با نقاط آسيب پذير RPC ، می توان از آدرس های زير استفاده نمود : در بخش دو م اين مقاله به بررسی ساير نقاط آسيب پذير يونيکیس و لينوکس خواهيم پرداخت . مهمترين نقاط آسيب پذير يونيکس و لينوکس ( بخش دوم ) در بخش اول اين مقاله به بررسی دو مورد از نقاط آسيپ پذير اشاره گرديد. در اين بخش به بررسی نقاط آسيب پذير Apache Web Server و روش های تائيد کاربران ، خواهيم پرداخت . سومين نقطه آسيب پذير : Apache Web Server آپاچی ( Apache) يکی از متداولترين سرويس دهندگان وب بر روی اينترنت است . در مقايسه با سرويس دهنده وب مايکروسافت ( IIS ) ، آپاچی مسائل و مشکلات امنيتی کمتری را داشته ولی همچنان دارای آسيب پذيری خاص خود است . علاوه بر وجود نقاط آسيب پذير در ماژول ها و کد آپاچی ( و ) ، تکنولوژی های CGI و PHP نيز دارای نقاط آسيب پذيری خاص خود بوده که ضعف های امنيتی آنان به سرويس دهنده وب نيز سرايت می گردد. در صورت وجود نقاط آسيب پذير در سرويس دهنده آپاچی و يا عناصر مرتبط به آن ، زمينه تهديدات زير فراهم می گردد : غير فعال نمودن سرويس ( DoS ) نمايش و بمخاطره انداختن فايل ها و داده های حساس دستيابی به سرويس دهنده از راه دور بمخاطره افتادن سرويس دهنده ( دستکاری و خرابی سايت ) سيستم های عامل در معرض تهديد تمامی سيستم های يونيکس قادر به اجراء آپاچی می باشند . آپاچی بصورت پيش فرض بر روی تعداد زيادی از نسخه های يونيکس و لينوکس ، نصب می گردد .علاوه بر امکان فوق ، آپاچی را می توان بر روی ميزبانی ديگر که از سيستم عاملی مختلف نظير ويندوز استفاده می نمايد نيز نصب نمود. اين نوع از نسخه های آپاچی نيز می تواند دارای نقاط آسيب پذير خاص خود باشد . نحوه تشخيص آسيب پذيری سيستم بمنظور آگاهی و کسب اطلاعات لازم در خصوص نحوه تشخيص آسيب پذيری سرويس دهنده وب آپاچی ، می توان از آدرس های زير استفاده نمود : در رابطه با Apache 1.3.x را می توان از آدرس برای Apache 2.0.x می توان از آدرس آدرس های اشاره شده ، دارای اطلاعات فنی لازم بمنظور نحوه تشخيص آسيب پذيری سيستم و پيشنهادات لازم در خصوص ارتقاء وضعيت امنيتی می باشند . استفاده از آدرس: نيز در اين زمينه مفيد است . نحوه حفاظت در مقابل نقطه آسيب پذير بمنظور حفاظت يک سرويس دهنده وب آپاچی ، پيشنهادات زير ارائه می گردد : اطمينان از نصب آخرين patch ارائه شده - در اين رابطه می توان از آدرس بمنظور آگاهی از آخرين وضعيت نسخه ها و Patch levels استفاده نمود. - بمنظور دستيابی به Source code اکثر نسخه های آپاچی، می توان از آدرس استفاده نمود. - بمنظور آگاهی و دريافت آخرين Patch های ارائه شده می توان از آدرس استفاده نمود. اطمينان از patching عناصر کليدی سيستم عامل که آپاچی بعنوان مرجع از آنان استفاده می نمايد .در اين رابطه لازم است که صرفا" ماژول های ضروری بمنظور صحت عملکرد سرويس دهنده ، در آپاچی کمپايل گردند .لازم است به اين نکته اشاره گردد که کرم( mod_ssl ( نمونه ای کامل در اين زمينه بوده که از نقاط آسيب پذير در( OpenSSL ( استفاده نموده است . از اجرای آپاچی بعنوان ريشه ، اجتناب و می بايست بدين منظور ، کاربر و يا گروهی خاص با حداقل مجوز ايجاد گردد. ساير پردازه های سيستم ضرورتی به اجراء تحت کاربر و يا گروه فوق را نخواهند داشت . 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 از آدرس استفاده شود . - برای Apache 2.0.x از آدرس استفاده شود . در موارد متفاوتی و با توجه به شرايط پيش آمده ممکن است محتوی فايل های لاگ بتنهائی کافی نباشد . وضعيت فوق در موارديکه از PHP ، CGI و يا ساير تکنولوژی های مبتنی بر اسکريپت استفاده می گردد ، تشديد و می توان بمنظور افزايش توان آناليز يک تهاجم و سوءاستفاده از يک ضعف امنيتی ، اقدام به ثبت لاگ های مربوط به GET و POST نمود.لاگ نمودن عمليات مرتبط به GET و POST می تواند از طريق mod_Security صورت پذيرد. ModSecurity يک سيستم تشخيص مزاحمين ( Intruder detection ) یوده و پيشگيری های لازم در خصوص يک برنامه وب را ارائه می نمايد . سيستم فوق بهمراه سرويس دهنده وب مستقر و يک پوشش امنيتی مناسب را در جهت پيشگيری از يک تهاجم در ارتباط با برنامه های وب فراهم می نمايد . ModSecurity ، از سرويس دهنده آپاچی حمايت می نمايد . - - 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 ، خود باعث بروز حفره های امنيتی ديگر خواهد شد.. در اين رابطه و بمنظور آشنائی با نحوه عملکرد و استفاده از suEXEC می توان از آدرس های زير استفاده نمود: -- برای Apache 1.3.x از آدرس استفاده شود . -- برای Apache 2.0.x از آدرس استفاده شود. - بررسی لازم در خصوص محتوی دايرکتوری cgi-bin و ساير دايرکتوری های شامل اسکريپت ها انجام و لازم است تمامی اسکريپت های پيش فرض نمونه ، حذف گردند. - ايمن سازی PHP . پرداختن به موضوع فوق با توجه به گستردگی مطالب از حوصله اين مقاله خارج بوده و صرفا" به دو نمونه مهم در اينخصوص اشاره می گردد : - غير فعال نمودن پارامترهائی که باعث ارائه اطلاعات در HTTP header می گردد . - حصول اطمينان از اجرای PHP در حالت safe برای دريافت اطلاعات تکميلی دراين خصوص می توان از آدرس استفاده نمود . - استفاده از ماژولهای اضافه بمنظوربهبود وضعيت امنيتی. مثلا"ماژول mod_Security می تواند باعث حفاظت در مقابل Cross Site Scripting: XSS ، شود . برای آشنائی و مشاهده اطلاعات تکميلی در اين خصوص می توان از آدرس استفاده نمود. - مميزی و بررسی اسکريپت ها برای نقاط آسيب پذير شامل XSS & SQL Injection نيز حائز اهميت است . در اين رابطه می توان از ابزارهای متعددی استفاده نمود. نرم افزار Nikto ( قابل دسترس در آدرس ) يکی از مناسبترين ابزارهای پويش و بررسی CGI است . چهارمين نقطه آسيب پذير : account هائی با رمز عبور ضعيف و يا فاقد رمز عبور استفاده از رمزعبور، روش های تائيد کاربر و کدهای امنيتی در هر گونه تعامل ارتباطی بين کاربران وسيستم های اطلاعاتی ، امری متداول و رايج است . اکثر روش ها ی تائيد کاربران ، نظير حفاظت فايل و داده ، مستقيما" به رمزهای عبور ارائه شده توسط کاربران ، بستگی خواهد داشت . پس از تائيد کاربران ، امکان دستيابی آنان به منابع مشخص شده فراهم و هر يک از آنان با توجه به امتيازات و مجوزهای نسبت داده شده ، قادر به استفاده از منابع موجودخواهند بود. در اغلب موارد ، فعاليت کاربرانی که مجاز بودن آنان برای دستيابی به منابع ، تائيد شده است ، لاگ نشده و يا در صورتيکه فعاليت آنان ثبت گردد ، کمتر سوء ظنی به آنان می تواند وجود داشته باشد . ( آنان پس از تائيد وارد ميدانی شده اند که بدون هيچگونه رديابی ، قادر به انجام فعاليت های گسترده ای خواهند بود) . بنابراين ، رمز عبور دارای نقشی حياتی و اساسی در ايجاد اولين سطح دفاع در يک سيستم اطلاعاتی بوده و از دست رفتن رمز عبور و يا ضعف آن می تواند سيستم را در معرض تهديدات جدی قرار دهد . مهاجمان پس از دستيابی به رمز عبور کاربران تائيد شده ( استفاده از مکانيزم های متفاوت ) قادر به دستيابی منابع سيستم و حتی تغيير در تنظيمات ساير account های تعريف شده و موجود بر روی سيستم خواهند بود،عملياتی که می تواند پيامدهای بسيار منفی را بدنبال داشته باشد . پس می بايست بپذيريم که وجود يک account ضعيف و يا فاقد رمز عبور می تواند تهديدی جدی در يک سازمان باشد . در اين راستا علاوه بر اينکه می بايست از پتانسيل های ارائه شده توسط سيستم عامل با دقت استفاده نمود ، ضروری است ، تابع يک سياست امنيتی تدوين شده در رابطه با رمز عبور در سازمان متبوع خود باشيم . تعريف و نگهداری يک account بهمراه رمز عبور مربوطه در سازمان ما تابع چه سياست امنيتی است ؟ مهمترين و متداولترين نقاط آسيب پذير در ارتباط با رمز عبور شامل موارد زير است : Account تعريف شده دارای رمز عبور ضعيف و يا فاقد رمز عبور است . عدم حفاظت مناسب کاربران از رمزهای عبور ،صرفنظر از استحکام رمزهای عبور تعريف شده . سيستم عامل و يا ساير نرم افزارهای موجود ، امکان ايجاد account مديريتی ضعيف و فاقد رمز عبور را فراهم می نمايند . الگوريتم های Hashing رمز عبور( رمزنگاری مبتنی بر کليد عمومی بر پايه يک مقدار hash ، استوار بوده و بر اساس يک مقدار ورودی که دراختيار الگوريتم hashing گذاشته می گردد ، ايجاد می گردد. در حقيقت مقدار hash ، فرم خلاصه شده و رمز شده ای از مقدار اوليه خود است ) ، شناخته شده بوده و در اغلب موارد مقدار Hashe بدست آمده ، بگونه ای ذخيره می گردد که امکان مشاهده آن توسط سايرين وجود خواهد داشت. مناسبترين نوع حفاظت در اين راستا ، تبعيت از يک سياست رمز عبور قدرتمند بوده که در آن دستورالعمل ها ی لازم برای تعريف يک رمز عبورمناسب مشخص و در ادامه با استفاده از ابزارهای موجود، بررسی لازم در خصوص استحکام و بی نقص بودن رمز عبور صورت گيرد. سيستم ها ی در معرض آسيب پذير هر سيستم عامل و يا برنامه ای که فرآيند تائيد کاربران آن براساس يک User ID و رمز عبور باشد ، در معرض اين تهديد خواهد بود. نحوه تشخيص آسيب پذيری سيستم در صورتيکه از account هائی استفاده می شود که بين کاربران متعدد و يا کارکنان موقت يک سازمان به اشتراک گذاشته شده و يا کاربران از رمزهای عبور بدرستی حفاظت ننمايند، پتانسيل نفوذ به شبکه توسط يک مهاجم فراهم می گردد.پيکربندی account های جديد کاربران با يک رمز عبور مشابه و يا رمز عبوری که بسادگی قابل حدس باشد نيز فرصتی مناسب را در اختيار مهاجمان بمنظور دستيابی به منابع اطلاعاتی موجود در يک سازمان قرار خواهد داد . لازم است در خصوص ذخيره سازی رمز عبور hashes تصميم گيری و مشخص شود که محل استقرار و ذخيره سازی آنان در etc/passwd / و يا etc/shadow / می باشد.قابليت خواندن فايل etc/passwd /، می بايست توسط تمامی کاربران شبکه وجود داشته تا زمينه و امکان تائيد کاربران فراهم گردد. در صورتيکه فايل فوق ، شامل رمزعبور hashed نيز باشد ، در ادامه و پس از دستيابی کاربران به سيستم ، امکان خواندن مقادير hash فراهم و مهاجمان می توانند با استفاده از يک برنامه cracker ، تلاش خود را جهت شکستن و تشخيص رمز عبور آغاز و به سرانجام برسانند . فايل etc/shadow/ ، صرفا" برای root قابل خواندن بوده و مکانی مناسب بمنظور ذخيره نمودن مقادير hashes است . در صورتيکه account های محلی ، توسط /etc/shadow حفاظت نشود ، ريسک رمزهای عبور افزايش خواهد يافت . اکثر سيستم های عامل جديد بصورت پيش فرض از etc/shadow / بمنظور ذخيره سازی رمز عبور hashes استفاده می نمايند ( مگر اينکه شرايط فوق توسط نصب کننده تغيير يابد ). در اين رابطه می توان از الگوريتم MD5 بمنظور hash نمودن رمزهای عبور نيز استفاده نمود. الگوريتم فوق، بمراتب از الگوريتم قديمی crypt ايمن تر است . NIS)Network Information System) ، يک بانک اطلاعاتی توزيع شده بمنظور مديريت يک شبکه است . در حقيقت NIS ، استانداردی برای اشتراک فايل ها بين سيستم های کامپيوتری متعدد را فراهم و شامل مجموعه ای از سرويس هائی است که بمنزله يک بانک اطلاعاتی از سرويس ها عمل نموده و اطلاعات مربوط به مکان سرويس ( Mapping ) را در اختيار ساير سرويس های شبکه نظير( Network File System (NFS) ، قرار می دهد. با توجه به ماهيت طراحی بعمل آمده ، فايل های پيکربندی NIS ، شامل رمزهای عبور hash بوده و اين امر می تواند امکان خواندن آنان را برای تمامی کاربران فراهم و عملا" رمزهای عبور در معرض تهديد قرار گيرند .نسخه های جديد پياده سازی شده از NIS ، نظير +NIS و يا LDAP عموما" دارای استحکام لازم در ارتباط با رمزهای عبور hashes می باشند( مگر اينکه شرايط فوق توسط نصب کننده تغيير يابد). تنظيم و پيکربندی نسخه های فوق ( نسخه های جديد ) ، مشکل تر بوده و همين امر می تواند استفاده از آنان را با ترديد و مشکل مواجه نمايد . حتی اگر رمزهای عبور hashes توسط /etc/shadow و يا امکانات پياده سازی شده ، محافظت گردند ، امکان حدس و تشخيص رمزهای عبور توسط ساير افراد وجود خواهد داشت . در اين رابطه می توان به موارد متعدد ديگری نظير : ضعف رمز عبور ، وجود account های غير استفاده مربوط به کارکنانی که سازمان خود را ترک نموده اند ، اشاره نمود .سازمان ها معمولا" در رابطه با غير فعال نمودن account مربوط به کاربران قديمی کوتاهی نموده و لازم است در اين رابطه از روش های خاصی استفاده گرد. نصب های پيش فرض سيستم های عامل و يا شبکه توسط سازندگان و يا مديران سيستم و يا شبکه ، می تواند نصب مجموعه ای از سرويس های غيرضروری را نيز بدنبال داشته باشد. رويکرد فوق،با اينکه عمليات نصب سيستم عامل و سرويس ها ی مربوطه را تسهيل می نمايد ولی مجموعه ای از سرويس های غير ضروری و account هائی که بصورت پيش فرض ضعيف ويا فاقد رمز عبور می باشند را بهمراه بر روی سيستم مستقر و پيکربندی می نمايد. نحوه حفاظت در مقابل نقطه آسيب پذير بهترين و مناسبترين دفاع در مقابل ضعف رمزهای عبور ، تبعيت از يک سياست امنيتی مستحکم بوده که دستورالعمل های لازم کهه موجب می شود رمزهای عبور مناسب و مستحکمی توسط کاربران تعريف و توسط مديران سيستم بصورت مستمر پيوستگی و استحکام آنان بررسی می گردد با حمايت کامل سازمان . مراحل زير توصيه های لازم برای ارائه يک سياست امنيتی مناسب می باشد : اطمينان ازاستحکام و انسجام رمز های عبور . با استفاده از سخت افزار مناسب و اختصاص زمان کافی ، می توان هر رمز عبوری را crack نمود. در اين راستا می توان با استفاده ازروش های ساده و در عين حال موفقيت آميز، عمليات تشخيص رمز عبور را انجام داد . اغلب برنامه های تشخيص دهنده رمزعبوراز روشی موسوم به "حملات مبتنی بر سبک ديکشنری " ، استفاده می نمايند. با توجه به اينکه روش های رمز نگاری تا حدود زيادی شناخته شده می باشند ، برنامه های فوق ، قادر به مقايسه شکل رمز شده يک رمز عبور در مقابل شکل های رمز شده کلمات ديکشنری می باشند( در زبان های متعدد و استفاده از اسامی مناسب بهمراه جايگشت های مختلف آنان ) . بنابراين ، رمز عبوری که ريشه آن در نهايت يک کلمه شناخته شده باشد ، دارای استعداد ذاتی در رابطه با اين نوع از حملات خواهد بود . تعداد زيادی از سازمان ها ، آموزش های لازم در خصوص نحوه تعريف رمزهای عبور را به کارکنان خود داده و به آنان گفته شده است که رمزهای عبور مشتمل بر ترکيبی از حروف الفبائی و کاراکترهای ويژه را برای خود تعريف نمايند.متاسفانه اکثر کاربران اين موضوع را رعايت ننموده و بمنظور تعريف يک رمز عبور با نام "password" ، صرفا" اقدام به تبديل حروف به اعداد و يا حروف ويژه می نمايند ( pa$$w0rd) . چنين جايگشت هائی نيز قادر به مقاومت در مقابل يک تهاجم مبتنی بر ديکشنری نبوده و "pa$$w0rd" به روش مشابهی که "password" تشخیص داده می شود ، crack خواهد شد . يک رمز عبور خوب ، نمی بايست از ريشه يک کلمه و يا نام شناخته شده ای اقتباس شده باشد .در اين راستا لازم است به کاربران آموزش لازم در خصوص انتخاب و ايجاد رمزهای عبور از موارد تصادفی نظير يک عبارت ، عنوان يک کتاب ،نام يک آواز و يا نام يک فيلم داده شود. با انتخاب يک رشته طولانی که بر اساس رويکردهای خاصی می تواند انتخاب گردد( گرفتن اولين حرف هر کلمه ، جايگزينی يک کاراکتر خاص برای يک کلمه ، حذف تمامی حروف صدادارو ساير موارد ) ، کاربران قادر به ايجاد رمزهای عبور مشتمل بر ترکيبی از حروف الفبائی و حروف ويژه بوده که در صورت مواجه شدن با حملات مبتنی بر ديکشنری ، تشخيص آنان بسختی انجام می شود. لازم است به اين نکته نيز اشاره گردد که رمزعبور می بايست براحتی بخاطر سپرده شده و بازيابی ( يادآوری)آن مشکل نباشد ( هدف از ذخيره سازی ، بازيابی است اگر چيزی را ذخيره نمائيم ولی در زمان مورد نظر قادر به بازيابی آن نباشيم ، سيستم ذخيره و بازيابی ما با اشکال مواجه شده است ! ). پس از تدوين دستورالعمل لازم بمنظور توليد رمزهای عبور مناسب و آموزش کاربران بمنظور پايبندی به اصول امنيتی تعريف شده ، می بايست از روتين ها ی جانبی متعددی بمنظور اطمينان از پيروی کاربران از دستوراالعمل های اعلام شده ، استفاده گردد. بهترين گزينه در اين راستا ، بررسی صحت رمزهای عبور پس از اعمال تغييرات توسط کاربران است . پس از ارائه دستورالعمل ها ی لازم و مناسب برای ايجاد رمزهای عبور ، روتين های تکميلی خاصی می بايست ايجاد تا اين اطمينان حاصل گردد که کاربران پايبند به دستورالعمل های ارائه شده بوده اند. بهترين روش در اين زمينه ، بررسی صحت اعتبار رمزهای عبور پس از اعمال تغييرات توسط کاربران است . اکثر نمونه های يونيکس و لينوکس می توانند از Npasswd بمنظور بررسی رمز عبور در مقابل سياست امنيتی موجود استفاده نمايند. سيستم های PAM-Enabled نيز می توانند از Cracklib ( کتابخانه لازم بمنظور هماهنگی با Crack ) بمنظور بررسی رمزهای عبور ايجاد شده ، استفاده نمايند.اکثر سيستم های PAM-enabled را می توان بگونه ای پيکربندی نمود که رمزهای عبوری را که با سياست های مشخص شده مطابقت ندارد ، رد نمايند . درموارديکه امکان استفاده از ابزارهائی نظير Npasswd و يا کتابخانه های PAM-Enabled ، وجود ندارد، مديران سيستم و شبکه می توانند از برنامه های کاربردی Cracking در حالت stand-alone و بعنوان يک روتين کنشگرايانه مستمر، استفاده نمايند. و ، نمونه هائی از برنامه های فوق ، می باشند. لازم است مجددا" به اين موضوع اشاره گردد که بدون کسب مجوز لازم از مديران ارشد سيستم در سازمان ، نمی بايست از برنامه های cracking استفاده گردد.پس از کسب مجوزهای لازم ، می توان عمليات فبررسی رمزهای عبور را بر روی يک ماشين حفاظت شده انجام داد. به کاربرانی که رمزهای عبور آنان crack می گردد، بصورت محرمانه وضعيت فوق گزارش و دستورالعمل های لازم در خصوص نحوه انتخاب يک رمز عبور مناسب نيز به آنان ارائه گردد .اخيرا" و در پاسخ به رمزهای عبور ضعيف ، استفاده از روش هائی ديگر بمنظور تائيد کاربران، نظير بيومتريک (زيست سنجی ) ، نيز مورد توجه واقع شده است . حفاظت رمزهای عبور مستحکم. در صورتيکه رمزهای عبور hashes در etc/passwd / ذخيره می گردند ، سيستم را بهنگام نموده تا از /etc/shadow استفاده گردد . در صورتيکه بر روی سيتستم NIS و يا LDAP اجراء که امکان حفاظت hashes وجود نداشته باشد ، هر کاربری قادر به خواندن رمزهای عبور hashes و تلاش بمنظور cracking آنان ، خواهد بود.در اين رابطه می بايست بررسی لازم در خصوص استفاده از گزينه های ايمن تری از نسخه های NIS و LDAP را انجام داد. تا زمانيکه اين نوع برنامه های غير ايمن وجود داشته و با نمونه های ايمن جايگزين نشده اند، می بايست مجوزهای مربوطه را ايمن و از ابزارهای کنشکرايانه بصورت مستمر استفاده گردد.در اين رابطه پيشنهاد می گردد که در مقابل استفاده از الگوريتم قديمی Crypt بمنظورhash نمودن رمزهای عبور از الگوريتم MD5 استفاده گردد. حتی اگر رمزهای عبور ، مستحکم و قدرتمند باشند ، در صورت عدم حفاظت آنان توسط کاربران ، سيستم های موجود در يک سازمان در معرض تهديد قرار خواهند گرفت . يک سياست امنيتی مناسب ، می بايست شامل دستورالعمل های لازم بمنظور آموزش کاربران در رابطه با حفاظت رمزهای عبور می باشد.عدم ارائه رمز عبور به افراد ديگر، عدم نوشتن رمز عبور در محلی که امکان خواندن آن برای ديگران وجود داشته باشد و حفاظت اتوماتيک فايل هائی که رمزهای عبور در آن ذخيره شده اند ، از جمله مواردی می باشند که می بايست به کاربران آموزش داده شود. اغلب کاربران در مواجهه با پيامی مشابه "Your password has expired" که نشاندهنده اتمام عمر مفيد يک رمز عبور است ، يک رمز عبور ضعيف را برای خود انتخاب می نمايند ، بنابراين لازم است در فرصت مناسب و قبل از برخورد با اينچنين پيام هائی ، به کاربران آموزش های لازم ارائه گردد. کنترل دائم و پيوسته accounts. هر account مديريتی و يا مبتنی بر سرويس که از آن استفاده نمی گردد، می بايست غير فعال و يا در صورت امکان از روی سيستم حذف گردد. هر account مديريتی و يا مبتنی بر سرويس که از آن استفاده می گردد ، می بايست دارای رمزعبورجديد و مستحکمی باشد. پيکربندی account های جديد کاربران با رمزهای عبور اوليه (توليده شده بصورت تصادفی) و ضرورت تغيير رمزهای عبور توسط کاربران و در اولين log in نيز می تواند در اين زمينه مفيد واقع شود. ممیزی account ها بر روی سيستم را انجام و لازم است در اين رابطه يک ليستی اصلی ايجاد گردد .در اين رابطه می بايست رمزهای عبور در ارتباط با سيستم هائی نظير روترها ، چاپگرهای ديجيتالی متصل شده به اينترنت و ساير موارد ديگر نيز مورد بررسی قرار گرفته و روتين هائی خاص بمنظور افزودن account های تائيد شده به ليست و يا حذف account هائی که ضرورتی به استفاده از آنان نمی باشد ، پياده سازی و همواره خود را پايبند به آن بدانيم .اعتبار ليست را در فواصل زمانی خاصی بررسی تا از بهنگام بودن آن اطمينان حاصل گردد.از روتين های خاصی بمنظورحذف account متعلق به کارکنان و يا پيمانکارانی که سازمان را ترک نموده اند ، استفاده گردد . در بخش سوم اين مقاله به بررسی ساير نقاط آسيب پذير يونيکس و لينوکس خواهيم پرداخت . مهمترين نقاط آسيب پذير يونيکس و لينوکس ( بخش سوم ) پنجمين نقطه آسيب پذير : :Clear Text Services تعداد زيادی از سرويس های شبکه استفاده شده توسط سيستم های مبتنی بر يونيکس ، بصورت plain text بوده و از رمزنگاری خاصی استفاده نمی نمايند. ضعف در رمزنگاری ، امکان شنود اطلاعاتی ( مشاهده ترافيک شبکه ) را فراهم و مهاجمان در ادامه امکان دستيابی به محتویات ارتباط ايجاد شده و يا اطلاعات حساس کاربران نظير داده های مرتبط با رمز عبور را بدست خواهند آورد. مثلا" بمنظور تشخيص اطلاعات مرتبط با FTP و يا telnet ( اطلاعات login ) ، يک مهاجم ، می تواند يک sniffer را در شبکه و در محلی بين مسير ارتباطی، مستقر نمايد (بعنوان سرويس دهنده FTP و يا يا Client LAN ) . تبادل اطلاعات بين دستورات ورودی توسط سرويس گيرندگان و پاسخ های ارائه شده توسط سرويس های موجود بر روی سرويس دهنده ، بصورت plain-text خواهد بود. بدين ترتيب ،امکان رديابی ( رهگيری ) داده و يا کليدهای فشرده شده توسط کاربر بسادگی فراهم می گردد. اغلب مهاجمان در حملات اخير خود از برنامه های مختص شنود اطلاعاتی استفاده و عمدتا" اينگونه برنامه ها را بر روی دستگاهها ی آسيیب پذير نصب می نمايند. در چنين مواردی ، تشخيص نام و رمز عبور کاربر در داده های جمع آوری شده ( شنود اطلاعاتی ) ، بسادگی ميسر خواهد شد.جدول زير، ليست برخی از سرويس های شبکه يونيکس را که اطلاعات را بصورت Clear Text ، مبادله می نمايند ، نشان می دهد : آيتم ارسالی Clear Auth Clear Content پورت سرويس متن ، باينری Yes Yes 21 , 20 FTP متن ، باينری N/A Yes 69 TFTP متن Yes Yes 23 telnet متن ، باينری N/A Yes 25 SMTP متن ، باينری Yes Yes 110 POP3 متن ، باينری Yes Yes 143 IMAP متن Yes Yes 513 rlogin متن Yes Yes 514 rsh متن ، باينری Yes Yes 80 HTTP سرويس هائی نظير Telnet و FTP که شامل اطلاعات مربوط به تائيد هويت کاربران می باشند ، اطلاعات مورد نظر را بصورت متن ارسال که بالاترين ريسک را بدنبال خواهد داشت . در چنين مواردی مهاجمان می توانند با استفاده مجدد از داده های حساس کاربران نظير نام و رمز عبور، با خيال راحت ! به سيستم دستيابی نمايند .علاوه براين ، اجرای دستورات بصورت clear text می تواند توسط مهاجمان استفاده تا با استفاده از آنان دستورات دلخواه خود را بدون الزامی برای تائيد ، اجراء نمايند. سرويس های Clear text ، می توانند زمينه تهديدات مختلفی نظير : تسهيل در انجام حملات ، دستيابی از راه دور ، اجرای دستورات بر روی يک سيستم مقصد ، شنود و تشخيص اطلاعات را بدنبال داشته باشد . سيستم های عامل در معرض تهديد تمامی نمونه های يونيکس ارائه شده ، از سرويس ها ی Clear text استفاده می نمايند. ( telnet و FTP دو نمونه متدواول در اين زمينه می باشند ) . تمامی نمونه نسخه های ارائه شده يونيکس و لينوکس ( تنها استنثاء در اين رابطه، مربوط به آخرين ويرايش Free/OpenBSD می باشد ) ، بصورت پيش فرض ، برخی از سرويس های فوق را نصب می نمايند . نحوه تشخيص آسيب پذيری سيستم موثرترين و مطمئن ترين روش بمنظور تشخيص نقطه آسيب پذير فوق (سرويس های clear text ) ، بکارگيری نرم افزاری مشابه با ابزارهای استفاده شده (sniffer) توسط مهاجمان است. متداولترين برنامه موجود در اين زمينه ، tcpdump می باشد. برای دريافت برنامه "tcpdump " می توان از آدرس ، استفاده نمود . نحوه فعال نمودن برنامه فوق،بمنظور تشخيص هر گونه ارتباط clear text ، بصورت زير است : # tcpdump -X -s 1600 دراين راستا می توان از برنامه های ديگر نظير : "ngrep" نيز استفاده نمود. برنامه فوق،امکان جستجوی الگوئی خاص نظير "sername " و يا " assword " را در شبکه فراهم می نمايد. ( اولين حروف، بمنظور سازگاری با حروف بزرگ احتمالی ، در نظر گرفته نشده است ) . برای دريافت برنامه فوق ، می توان از آدرس استفاده نمود . نحوه فعال نمودن برنامه فوق ، بصورت زير است : # ngrep assword در اين رابطه می توان از ابزارهای متنوع ديگری بمنظور تشخيص داده های حساس کاربران ( نام و رمز عبور ) استفاده نمود . Dsniff ، متداولترين ابزار در اين زمينه است . برنامه فوق ، بررسی لازم در خصوص تمامی زوج نام و رمزعبور بر روی پروتکل های Plain text حجيم، نظير FTP ، Telnet و POP3 را انجام و پس از تشخيص، آنان را نمايش خواهد داد. برای بدست آوردن برنامه فوق می توان از آدرس استفاده نمود . نحوه فعال نمودن برنامه فوق ، بصورت زير است : # /usr/sbin/dsniff نحوه حفاظت در مقابل نقطه آسيب پذير استفاده از رمزنگاری End-To-End و يا حداقل رمزنگاری Link-level می تواند در اين زمينه مفيد واقع گردد. برخی پروتکل ها از لحاظ رمزنگاری معادل يکديگر می باشند( نظير : POP3S و HTTPS ) . برای پروتکل هائی که دارای قابليت ها و امکانات , ذاتی رمزنگاری نمی باشند ، می توان آنان را از طريق SSH : Secure Shell ، و يا SSL connection انجام داد( tunneling ) . OpenSSH يک نمونه پياده سازی شده متداول و انعطاف پذير ازSSH است.( قابل دسترس در آدرس ) . برنامه فوق، در اکثر نسخه های يونيکس اجراء و می توان از آن بمنظور ارتباطات از راه دور ( replaces telnet ,rlogin ,rsh ) و tunneling ( پروتکل هائی نظير POP3,SMTP و X11 ) استفاده گردد . دستور زير نحوه tunnel نمودن POP3 را بر روی SSH connection نشان می دهد. بر روی سرويس دهنده POP3 ، می بايست سرويس دهنده SSH نيز اجراء گردد. در ابتدا آن را بر روی ماشين سرويس گيرنده اجراء می نمائيم : # ssh -L 110op3.mail.server.com:110 username@pop3.mail.server.com آدرس ایمیل جهت جلوگیری از رباتهای هرزنامه محافظت شده اند، جهت مشاهده آنها شما نیاز به فعال ساختن جاوا اسكریپت دارید در ادامه ، برنامه سرويس گيرنده پست الکترونيکی را به localhost اشاره می دهيم ، پورت TCP 110 ( برخلاف روال معمول که بصورت : pop3.mail.server.com ، پورت 110 است ) . بدين ترتيب ، تمامی ارتباطات بين ماشين و سرويس دهنده پست الکترونيکی بصورت رمز شده انجام خواهد شد ( tunneled over SSH ) . يکی ديگر از راه حل های متداول رمزنگاری مبتنی بر tunneling ، استفاده از stunnel است . روش فوق ، پروتکل SSL را پياده سازی( با استفاده از OpenSSL Toolkit ) و می توان آن را بمنظور tunel نمودن پروتکل های متفاوت plain text بخدمت گرفت . برای دريافت برنامه فوق ، می توان از آدرس استفاده نمود. ششمين نقطه آسيب پذير : : Sendmail Sendmail ، برنامه ای است که از آن بمنظور ارسال ، دريافت و فوروارد نمودن نامه های الکترونيکی در اغلب سيستم های يونيکس و لينوکس استفاده می گردد. Sendmail ، يکی از متداولترین MTA : Mail Transfer Agent در اينترنت بوده که بطور گسترده ای از آن بعنوان "آژانش توزيع نامه های الکترونيکی" بهمراه سرويس دهندگان پست الکترونيکی ، استفاده می گردد . Sendmail ، يکی از اهداف اوليه مهاجمان در ساليان اخير بوده و تاکنون حملات متعددی را در ارتباط با آن شاهد بوده ايم. اکثر حملات انجام شده بدليل قديمی بودن و يا عدم patch مناسب نسخه های نصب شده ، با موفقيت همراه بوده است .در اين رابطه می توان به چندين نمونه از حملات اخير اشاره نمود : - - - خطرات و تهديدات مرتبط با Sendmail را می توان به دو گروه عمده تقسيم نمود : از دست رفتن امتيازات که علت آن buffer overflow خواهد بود و پيکربندی نادرست سيستم که می تواند تبعات منفی را بدنبال داشته باشد ( مثلا" تبديل يک سيستم به مرکزی آلوده برای توزيع نامه های الکترونيکی ) .عامل اصلی در بروز تهديدات نوع اول ، عمدتا" به استفاده از نسخه های قديمی و يا عدم patching مناسب سيستم برمی گردد.علت اصلی تهديدات نوع دوم ، به استفاده از فايل های پيکربندی پيش فرض و نادرست برمی گردد . سيستم های عامل در معرض تهديد تقريبا" تمامی نسخه های لينوکس و يونيکس بهمراه يک نسخه نصب شده از Sendmail عرضه می گردند. سرويس فوق، بصورت پيش فرض فعال می باشد . نحوه تشخيص آسيب پذيری سيستم Sendmail ، در گذشته دارای نقاط آسيب پذير فراوانی بوده که بتدريج وبا ارائه نسخه های جديدتر و patch های مربوطه ، ميزان آسيب پذيری آن کاهش يافته است .هر نسخه قديمی و يا Patch نشده نرم فزار فوق در معرض آسيب قرار خواهد داشت . بمنطور مشخص نمودن شماره نسخه برنامه sendmail ، می توان از دستور زير استفاده نمود : echo \$Z | /usr/lib/sendmail -bt -d0 مسير مشخص شده sendmail در دستور فوق ، با توجه به پيکربندی سيستم ، می تواند متفاوت باشد. برای آگاهی از آخرين نسخه ارائه شده Sendmail می توان از آدرس استفاده نمود . نحوه حفاظت در مقابل نقطه آسيب پذير مراحل زير بمنظور ايمن سازی و حفاظت Sendmail پيشنهاد می گردد : [*] نسخه موجود را به آخرين نسخه ارتقاء و از آخرين patch های موجود ، استفاده گردد . برای دريافت source code می توان از آدرس استفاده نمود. در صورتيکه نسخه sendmail بهمراه سيستم عامل ارائه شده است ( يک Package ) ، می توان برای دريافت patch مربوطه به سايت عرضه کنندگان سيستم عامل مراجعه نمود. [*] برنامه sendmail عموما" بصورت پيش فرض در اکثر سيستم های يونيکس و لينوکس ( حتی آنانی که بعنوان سرويس دهنده mail مورد نظر نبوده و فعاليت آنان در ارتباط با mail نخواهد بود) نصب می گردد. برنامه Sendmail را در حالت daemon بر روی ماشين های فوق ، اجراء ننمائيد ( غير فعال نمودن سوئيچ bd - ) . امکان ارسال نامه الکترونيکی توسط سيستم های فوق ، همچنان وجود خواهد داشت . در اين رابطه می بايست پيکربندی سيستم بگونه ای انجام شود که به يک mail relay در فايل پيکربندی sendmail ، اشاره گردد.فايل پيکربندی، sendmail.cf نام داشته و معمولا" در آدرس etc/mail/sendmail.cf قرار دارد . [*] در صورتيکه لازم است sendmail در حالت daemon اجراء گردد، می بايست از صحت پيکربندی انجام شده اطمينان حاصل گردد. در اين رابطه می توان از منابع اطلاعاتی زير استفاده نمود : در نسخه Sendmail 8.9.0 ، امکان open relay بصورت پيش فرض غيرفعال می باشد.تعداد زيادی از عرضه کنندگان سيستم های عامل ، مجددا" آن رادر پيکربندی پيش فرض خود فعال می نمايند. در صورت استفاده از نسخه Sendmail ارائه شده بهمراه سيستم عامل ، می بايست دقت لازم در اينخصوص را انجام داد ( عدم استفاده سرويس دهنده برای realying ). [*] در زمان استفاده از نسخه جديد sendmail ( سوئيچ نمودن به يک نسخه ديگر ) ، لازم است تدابير لازم در خصوص تغيير فايل های پيکربندی ارائه شده توسط نسخه قديمی ، انديشيده گردد . برای آگاهی از جزئيات بيشتر در ارتباط با پيکربندی Sendmail ، می توان از آدرس استفاده نمود. [*] در موارديکه برنامه Sendmail از منابع موجود بر روی اينترنت Download می گردد ، می بايست بمنظور اطمينان از مجاز بودن نسخه تکثيری از PGP signature استفاده نمود. در اين رابطه لازم است به اين نکته دقت شود که بدون بررسی integrity مربوطه به source code برنامه Sendmail ، نمی بايست از آن استفاده شود. در گذشته ، نسخه هائی از Trojan ها در Sendmail مستقر تا در زمان مناسب حرکت مخرب خود را آغاز نمايند . بمنظور دريافت اطلاعات تکميلی در اين رابطه می توان از آدرس استفاده نمود. کليدهای استفاده شده بمنظور sign نمودن برنامه Sendmail دريافتی را می توان از آدرس بدست آورد . در صورت فقدان PGP ، می بايست از MD5 Checksum بمنظور بررسی integrity کد منبع Sendmail ، استفاده گردد. برای کسب اطلاعات بيشتر می توان از منابع اطلاعاتی زير استفاده نمود : در بخش چهارم اين مقاله به بررسی ساير نقاط آسيب پذير يونيکس و لينوکس خواهيم پرداخت . مهمترين نقاط آسيب پذير يونيکس و لينوکس ( بخش چهارم ) هفتمين نقطه آسيب پذير : ( Simple Network Management Protocol (SNMP از پروتکل SNMP بمنظور کنترل ، مانيتورينگ از راه دور و پيکربندی تمامی دستگاه های پيشرفته مبتنی بر TCP/IP در ابعاد گسترده ای استفاده می شود.با اينکه استفاده از SNMP در بين پلات فرم های متفاوت شبکه استفاده می گردد، ولی در اغلب موارد از آن بمنظور پيکربندی و مديريت دستگاههائی نظير چاپگر ، روترها ، سوئيچ ها ، Access point ها و دريافت داده های مورد نياز دستگاههای مانيتورينگ شبکه ، استفاده می شود . SNMP ، از روش های متفاوتی بمنظور مبادله پيام بين ايستگاههای مديريت SNMP و دستگاههای شبکه ای استفاده می نمايد . روش های استفاده شده بمنظور برخورد با پيام های مبادله شده و مکانيزم تائيد و معتبر سازی پيا م ها، از جمله عوامل اصلی در رابطه با نقاط آسيب پذير SNMP می باشند . نقاط آسيب پذير مرتبط با روش های استفاده شده در SNMP ( نسخه يک ) بهمراه جزئيات مربوطه را می توان در آدرس ، مشاهده نمود . نقاط آسيب پذير متعددی در SNMP متاثر از روش برخورد با پيام ها توسط ايستگاه های مديريتی است . نقاط آسيب پذير فوق، به نسخه ای خاص از SNMP محدود نبوده و محصولات متعدد ارائه شده توسط توليد کنندگان را نيز شامل می گردد . مهاجمان با استفاده از نقاط آسيب پذير فوق ، قادر به انجام حملات متفاوت از نوع DoS ( از کار افتادن يک سرويس ) تا پيکربندی و مديريت ناخواسته ماشين آلات و تجهيزات مبتنی بر SNMP ، می باشند . برخی از نقاط آسيب پذير در ارتباط با SNMP متاثر از روش های استفاده شده بمنظور تائيد و معتبر سازی پيام ها در نسخه های قديمی SNMP است ( توارث مشکلات ) . نسخه های يک و دو SNMP ، از يک " رشته مشترک " غيررمز شده بعنوان تنها گزينه موجود برای تائيد پيام ها استفاده می نمايند . عدم استفاده از روش های مناسب رمزنگاری ، می تواند عاملی مهم در پيدايش نقاط آسيب پذير باشد. نگرش پيش فرض نسبت به " رشته مشترک " که توسط تعداد زيادی از دستگاههای SNMP استفاده می گردد ، از ذيگر عوامل مهم در ارتباط با عرضه نقاط آسيب پذير است( برخی از توليد کنندگان بمنظور افزايش سطح ايمنی مربوط به داده های حساس ، رشته را بصورت "اختصاصی " تغيير و استفاده می نمايند ) . شنود اطلاعاتی و ترافيک SNMP ، می تواند افشاء اطلاعات و ساختار شبکه ( سيستم ها و دستگاههای متصل شده به آن ) را بدنبال داشته باشد . مهاجمين با استفاده از اطلاعات فوق ، قادر به انتخاب مناسب و دقيق هدف خود بمنظور برنامه ريزی حملات خود می باشند . اکثر توليد کنندگان بصورت پيش فرض نسخه يک SNMP را فعال و تعدادی ديگر، محصولاتی را ارائه می نمايند که قادر به استفاده ازمدل های امنيتی نسخه شماره سه SNMP نمی باشند. ( با استفاده از مدل های امنيـی ارائه شده در نسخه شماره سه SNMP ، می توان پيکربندی لازم در خصوص روش های تائيد را بهبود بخشيد ) . SNMP ، مختص يونيکس نمی باشد و در ابعاد وسيعی در ويندوز ، در تجهيزات شبکه ای ، در چاپگرها ، access point ها و Bridges ، استفاده می گردد. با توجه به نتايج حاصل از آناليز حملات مبتنی بر SNMP ، مشخص شده است که اکثر حملات در اين رابطه بدليل ضعف در پيکربندی SNMP در سيستم های يونيکس است . سيستم های عامل در معرض تهديد تقريبا" بر روی تمامی سيستم های يونيکس و لينوکس يک نسخه SNMP نصب و بهمراه آن عرضه می گردند. در اغلب موارد پروتکل فوق ، بصورت پيش فرض فعال می باشد. اکثر دستگاه ها و سيستم های عامل شبکه ای مبتنی بر SNMP دارای نقطه آسيب پذير فوق بوده و در معرض تهديد قرار خواهند داشت . نحوه تشخيص آسيب پذيری سيستم بمنظور بررسی نصب SNMP بر روی دستگاههای موجود و متصل شده در شبکه ، می توان از يک برنامه کمکی و يا روش دستی استفاده نمود. برنامه پويشگر SNScan ، نمونه ای در اين زمينه بوده که می توان آن را از طريق آدرس دريافت نمود. در موارديکه امکان استفاده از ابزارهای پويشگر وجود ندارد ، می توان بررسی لازم در خصوص نصب و اجراء SNMP را بصورت دستی انجام داد. در اين راستا می توان به مستندات سيستم عامل مربوطه مراجعه تا پس از آگاهی از نحوه پياده سازی SNMP ، عمليات لازم بمنظور تشخيص فعال بودن SNMP را انجام داد . در اين رابطه می توان ، جستجوی لازم در ليست پردازه ها برای يافتن "snmp" در حال اجراء بر روی پورت های 161 و 162 را انجام داد . وجود صرفا " يک نمونه SNMP ، دليلی بر آسيب پذيری سيستم است . بمنظور آگاهی از جزيئات لازم در اينخصوص می توان از آدرس استفاده نمود . در صورت تحقق يکی از شرايط زير و نصب SNMP ، سيستم در معرض آسيب و تهديد قرار خواهد داشت : وجود اسامی SNMP Community پيش فرض و يا خالی ( اسامی استفاده شده بعنوان رمزهای عبور ) وجود اسامی SNMP Community قابل حدس وجود رشته های مخفی SNMP Community نحوه حفاظت در مقابل نقطه آسيب پذير بمنظور حفاظت در مقابل نقطه آسيب پذير فوق ،در دو زمينه می توان اقدامات حفاظتی را سازماندهی نمود . حفاظت در مقابل درخواست های آسيب رسان و تهديد کننده : غير فعال نمودن SNMP در صورت عدم ضرورت استفاده از آن استفاده از يک مدل امنيتی مبتنی بر کاربر SNMPv3 ، بمنظور تائيد پيام ها و رمزنگاری داده ها ( در صورت امکان ) در صورت استفاده از SNMP نسخه يک و يا دو ، می بايست آخرين نسخه Patch ارائه شده توسط توليد کننده ، نصب گردد برای آگاهی از مشخصات توليدکننگان، می توان به بخش ضميمه ، مراجعه نمود . SNMP را در گلوگاه های ورودی شبکه فيلتر نمائيد ( پورت 161 مربوط به TCP/UDP و پورت 162 مربوطه به TCP/UDP ) . عمليات فوق را در موارديکه ضرورتی به مديريت دستگاهها بصورت خارجی وجود ندارد ، می بايست انجام داد . از کنترل دستيابی مبتنی بر ميزبان بر روی سيستم های SNMP agent استفاده گردد . ويژگی فوق ممکن است توسط SNMP agent سيستم های عامل دارای محدوديت هائی باشد ، ولی می توان کنترل لازم در خصوص پذيرش درخواست ها توسط agent مربوطه را انجام داد. در اکثر سيستم های يونيکس ، می توان عمليات فوق را توسط يک TCP-Wrapper و يا پيکربندی Xined انجام داد . استفاده از يک فايروال فيلترينگ بسته های اطلاعاتی مبتنی بر agent بر روی يک ميزبان نيز می تواند در بلاک نمودن درخواست های ناخواسته SNMP موثر واقع شود . حفاظت در مقابل رشته های قابل حدس غير فعال نمودن SNMP در صورت عدم ضرورت استفاده از آن استفاده از يک مدل امنيتی مبتنی بر کاربر SNMPv3 ، بمنظور تائيد پيام ها و رمزنگاری داده ها ( در صورت امکان ) در صورت استفاده از SNMP نسخه يک و يا دو ، می بايست از يک سياست خاص بمنظور اسامی community ( استفاده شده بعنوان رمزهای عبور ) استفاده گردد. در اين راستا لازم است اسامی بگونه ای انتخاب گردند که غير قابل حدس بوده و بصورت ادواری و در محدوده های خاص زمانی نيز تغيير داده شوند . با استفاده از امکانات موجود می بايست بررسی لازم در خصوص استحکام اسامی در نظر گرفته شده برای رمزهای عبور راانجام داد.در اين رابطه می توان از خودآموز و ابزار ارائه شده در آدرس ، استفاده کرد. SNMP را در گلوگاه های ورودی شبکه فيلتر نمائيد ( پورت 161 مربوط به TCP/UDP و پورت 162 مربوطه به TCP/UDP ) . عمليات فوق را در موارديکه ضرورتی به مديريت دستگاهها بصورت خارجی وجود ندارد ، می بايست انجام داد . پيکربندی فيلترينگ را صرفا" بمنظور ترافيک مجاز SNMP بين subnet های مميزی شده ، انجام دهيد. هشتمين نقطه آسيب پذير : Secure Shell (SSH SSH ، يک سرويس عمومی برای ايمن سازی Login ، اجرای دستورات و ارسال فايل در يک شبکه است .اکثر سيستم های مبتنی بر يونيکس از بسته نرم افزاری ( نسخه فوق بصورت open-source است ) و يا نسخه تجاری ، استفاده می نمايند . با اينکه SSH دارای ايمنی مناسبتری نسبت به telnet,ftp و برنامه های R-Command می باشد ، ولی همچنان در هر دو نسخه اشاره شده ، ضعف های امنيتی متعددی وجود دارد . اکثر ضعف های موجود صرفا" اشکالات جزئی بوده و تعداد اندکی از آنان ، حائز اهميت بوده و می بايست بلافاصله نسبت به برطرف نموودن آنان اقدام گردد . مهمترين تهديد مرتبط با ضعف های امنيتی SSH ، امکان دستيابی (سطح ريشه) به ماشين آسيب پذير توسط مهاجمان است . با توجه به رشد چشمگير استفاده از سرويس گيرندگان و سرويس دهندگان SSH در محيط های ويندوز، اکثر اطلاعات ارائه شده در رابطه با نقطه آسيب پذير فوق ، به نسخه های پياده سازی شده SSH در ويندوز و nix * ( يونيکس ، لينوکس ) بر می گردد .عدم مديريت مناسب SSH ، خصوصا" در ارتباط با پيکربندی و بکارگيری patch ها و بهنگام سازی لازم ، می تواند مسائل و مشکلات خاص خود را بدنبال داشته باشد . SSH2 ، ابزاری قدرتمند تعداد زيادی از نقاط آسيیب پذير تشخيص داده شده در پروتکل هائی نظير POP3 ( جايگزين با SSH2 SFTP ) ، برنامه Telnet ، سرويس HTTP , و ابزارهای مبتنی بر rhost ( نظير : روش های تائيد ,rsh , rlogin ,rcp ) باعث ارسال اطلاعات بصورت clear text و يا عدم پردازش مناسب session های سرويس گيرنده - سرويس دهنده می گردد. پروتکل SSH1 ، دارای پتانسيل آسيب پذيری بالائی خصوصا" در ارتباط با session موقتی رمزنشده می باشد . بدين دليل مديران سيستم و شبکه ، استفاده از پروتکل SSH2 را گزينه ای شايسته در اينخصوص می دانند( در موارديکه امکان آن وجود دارد) . لازم است به اين نکته مهم اشاره گردد که SSH1 و SSH2 با يکديگر سازگار نبوده و لازم است نسخه SSH بر روی سرويس گيرنده و سرويس دهنده يکسان باشند (در اين رابطه موارد استثنا ء نيز وجود دارد ) . کاربران OpenSSH می بايست به اين نکته توجه نمايند که کتابخانه های OpenSSH در مقابل پتانسيل های ايجاد شده توسط OpenSSH ، دارای نرم افزارهای آسيب پذير مختص خود می باشند. بمنظور آگاهی از جزئيات مربوطه ، می توان از آدرس استفاده نمود .در سال 2002 يک نسخه آلوده از OpenSSH ( نسخه فوق دارای يک trojan-horse بود ) در زمان کوتاهی گسترش و باعث آسيب های فراوانی گرديد. بمنظور کسب اطلاعات بيشتر در اين رابطه و اطمينان از عدم آسيب پذيری سيستم خود در مقابل نسخه آلوده فوق ، می توان از آدرس استفاده نمود . سيستم های عامل در معرض تهديد هر نسخه يونيکس و يا لينوکس که بر روی آن OpenSSH 3.3 و يا بعد از آن ( نسخه ارائه شده در سال 2003 ،version 3.6.1) و يا SSH Communication Security's SSH 3.0.0 و يا بعد از آن ( نسخه ارائه شده در سال 2003 شماره version 3.5.2 ) نصب واجراء می گردد ، در معرض اين آسيب قرار خواهد داشت . نحوه تشخيص آسيب پذيری سيستم با استفاده از يک پويشگر مناسب ، می توان بررسی لازم در خصوص آسيب پذيری يک نسخه را انجام داد . در اين رابطه می توان با اجرای دستور " ssh -V " ، از شماره نسخه نصب شده بر روی سيستم آگاه گرديد. ScanSSH ، ابزاری مفيد بمنظور تشخيص از راه دور سرويس دهندگان SSH آسيب پذير بدليل عدم Patching ، می باشد. دستور خطی ScanSSH ، ليستی از آدرس های شبکه را برای سرويس دهندگان پويش و گزارشی در ارتباط با شماره نسخه های آنان را ارائه می نمايد . آخرين نسخهScanSSH که در سال 2001 ارائه شده است را می توان از آدرس دريافت نمود . نحوه حفاظت در مقابل نقطه آسيب پذير بمنظور حفاظت در مقابل نقطه آسيب پذير فوق ، موارد زير پيشنهاد می گردد : نسخه و يا را به آخرين نسخه موجود ارتقاء دهيد . درصورتيکه SSH و يا OpenSSH بهمراه سيستم عامل ، نصب شده باشد ، می بايست آخرين Patchمربوطه را از سايت ارائه دهنده سيستم عامل دريافت و آن را برروی سيستم نصب نمود. در صورت استفاده از OpenSSL ، از نصب آخرين نسخه آن مطمئن شويد . حتی المقدور سعی گردد، نسخه SSH1 به SSH2 ارتقاء يابد .در رابطه با توسعه SSH1 در آينده تصميم خاصی وجود نداشته و توسعه SSH2 مورد نظر می باشد . دو نسخه پياده سازی شده SSH ، دارای مجموعه ای از گزينه های انتخابی بوده که مديران سيستم با استفاده از آنان و با توجه به سياست های موجود می توانند پيکربندی مناسبی در اينخصوص را انجام دهند. امکان محدوديت در دستيابی به ماشين مورد نظر و اتصال به آن ، روش های تائيد کاربران و ماهيت کاربران مجاز ، نمونه هائی از گزينه های انتخابی بوده که می توان از آنان بمنظور پيکربندی مطلوب استفاده گردد. پيکربندی مناسب سرويس گيرندگان SSH در زمان اتصال به سرويس دهنده ای که SSH را حمايت نمی نمايد . در چنين مواردی سرويس گيرنده ممکن است به عقب برگشته و استفاده از rsh را در اين رابطه مفيد تشخيص دهد . بمنظور پيشگيری از مواردی اينچنين می بايست به کليد FallBackToRsh در فايل پيکربندی SSH ، مقدار NO را نسبت داد . از رمزنگاری blowfish در مقابل 3DES استفاده گردد (روش 3DES ، ممکن است بصورت پيش فرض در نسخه مربوطه در نظر گرفته شده باشد ). بدين ترتيب علاوه بر افزايش سرعت در عمليات ، رمزنگاری انجام شده نيز از استحکام مناسبی برخوردار خواهد بود.
