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

سومین نقطه آسیب پذیر :  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%20152.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 از آدرس http://httpd.apache.org/docs/suexec.html   استفاده شود .
  -- برای Apache 2.0.x  از آدرس   http://httpd.apache.org/docs-2.0/suexec.html   استفاده شود. 
  - بررسی لازم در خصوص محتوی دایرکتوری 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 متعلق به کارکنان و یا پیمانکارانی که سازمان را ترک نموده اند ، استفاده گردد .

منبع:srco.ir