مهمترين نقاط آسيب پذير يونيکس و لينوکس ( بخش دوم )
مهمترين نقاط آسيب پذير يونيکس و لينوکس ( بخش دوم )
در بخش اول اين مقاله به بررسی دو مورد از نقاط آسيپ پذير اشاره گرديد. در اين بخش به بررسی نقاط آسيب پذير Apache Web Server و روش های تائيد کاربران ، خواهيم پرداخت .
سومين نقطه آسيب پذير : Apache Web Server
آپاچی ( Apache) يکی از متداولترين سرويس دهندگان وب بر روی اينترنت است . در مقايسه با سرويس دهنده وب مايکروسافت ( IIS ) ، آپاچی مسائل و مشکلات امنيتی کمتری را داشته ولی همچنان دارای آسيب پذيری خاص خود است .
علاوه بر وجود نقاط آسيب پذير در ماژول ها و کد آپاچی ( CA-2002-27 و CA-2002-17 ) ، تکنولوژی های CGI و PHP نيز دارای نقاط آسيب پذيری خاص خود بوده که ضعف های امنيتی آنان به سرويس دهنده وب نيز سرايت می گردد. در صورت وجود نقاط آسيب پذير در سرويس دهنده آپاچی و يا عناصر مرتبط به آن ، زمينه تهديدات زير فراهم می گردد :
  • غير فعال نمودن سرويس ( DoS )
  • نمايش و بمخاطره انداختن فايل ها و داده های حساس
  • دستيابی به سرويس دهنده از راه دور
  • بمخاطره افتادن سرويس دهنده ( دستکاری و خرابی سايت )

سيستم های عامل در معرض تهديد
تمامی سيستم های يونيکس قادر به اجراء آپاچی می باشند . آپاچی بصورت پيش فرض بر روی تعداد زيادی از نسخه های يونيکس و لينوکس ، نصب می گردد .علاوه بر امکان فوق ، آپاچی را می توان بر روی ميزبانی ديگر که از سيستم عاملی مختلف نظير ويندوز استفاده می نمايد نيز نصب نمود. اين نوع از نسخه های آپاچی نيز می تواند دارای نقاط آسيب پذير خاص خود باشد .
نحوه تشخيص آسيب پذيری سيستم
بمنظور آگاهی و کسب اطلاعات لازم در خصوص نحوه تشخيص آسيب پذيری سرويس دهنده وب آپاچی ، می توان از آدرس های زير استفاده نمود :

آدرس های اشاره شده ، دارای اطلاعات فنی لازم بمنظور نحوه تشخيص آسيب پذيری سيستم و پيشنهادات لازم در خصوص ارتقاء وضعيت امنيتی می باشند . استفاده از آدرس: http://httpd.apache.org نيز در اين زمينه مفيد است .
نحوه حفاظت در مقابل نقطه آسيب پذير
بمنظور حفاظت يک سرويس دهنده وب آپاچی ، پيشنهادات زير ارائه می گردد :

  • اطمينان از نصب آخرين patch ارائه شده
    - در اين رابطه می توان از آدرس http://httpd.apache.org بمنظور آگاهی از آخرين وضعيت نسخه ها و Patch levels استفاده نمود.
    - بمنظور دستيابی به Source code اکثر نسخه های آپاچی، می توان از آدرس Download - The Apache HTTP Server Project استفاده نمود.
    - بمنظور آگاهی و دريافت آخرين Patch های ارائه شده می توان از آدرس Index of /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 از آدرس Log Files - Apache HTTP Server استفاده شود .
    - برای Apache 2.0.x از آدرس Log Files - Apache HTTP Server استفاده شود .
    در موارد متفاوتی و با توجه به شرايط پيش آمده ممکن است محتوی فايل های لاگ بتنهائی کافی نباشد . وضعيت فوق در موارديکه از 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 ، خود باعث بروز حفره های امنيتی ديگر خواهد شد.. در اين رابطه و بمنظور آشنائی با نحوه عملکرد و استفاده از suEXEC می توان از آدرس های زير استفاده نمود:
    -- برای Apache 1.3.x از آدرس Apache suEXEC Support استفاده شود .
    -- برای Apache 2.0.x از آدرس suEXEC Support - Apache HTTP Server استفاده شود.
    - بررسی لازم در خصوص محتوی دايرکتوری cgi-bin و ساير دايرکتوری های شامل اسکريپت ها انجام و لازم است تمامی اسکريپت های پيش فرض نمونه ، حذف گردند.
    - ايمن سازی PHP . پرداختن به موضوع فوق با توجه به گستردگی مطالب از حوصله اين مقاله خارج بوده و صرفا" به دو نمونه مهم در اينخصوص اشاره می گردد :
    - غير فعال نمودن پارامترهائی که باعث ارائه اطلاعات در HTTP header می گردد .
    - حصول اطمينان از اجرای PHP در حالت safe
    برای دريافت اطلاعات تکميلی دراين خصوص می توان از آدرس http://www.securityfocus.com/printable/infocus/1706 استفاده نمود .
    - استفاده از ماژولهای اضافه بمنظوربهبود وضعيت امنيتی. مثلا"ماژول mod_Security می تواند باعث حفاظت در مقابل Cross Site Scripting: XSS ، شود . برای آشنائی و مشاهده اطلاعات تکميلی در اين خصوص می توان از آدرس http://www.modsecurity.org استفاده نمود.
    - مميزی و بررسی اسکريپت ها برای نقاط آسيب پذير شامل XSS & SQL Injection نيز حائز اهميت است . در اين رابطه می توان از ابزارهای متعددی استفاده نمود. نرم افزار Nikto ( قابل دسترس در آدرس http://www.cirt.net/code/nikto.shtml ) يکی از مناسبترين ابزارهای پويش و بررسی 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 و بعنوان يک روتين کنشگرايانه مستمر، استفاده نمايند. LC4 )l0phtcrack version 4) و John the Ripper ، نمونه هائی از برنامه های فوق ، می باشند. لازم است مجددا" به اين موضوع اشاره گردد که بدون کسب مجوز لازم از مديران ارشد سيستم در سازمان ، نمی بايست از برنامه های 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 متعلق به کارکنان و يا پيمانکارانی که سازمان را ترک نموده اند ، استفاده گردد .

در بخش سوم اين مقاله به بررسی ساير نقاط آسيب پذير يونيکس و لينوکس خواهيم پرداخت .