در بخش اول اين مقاله به بررسي دو مورد از نقاط آسيپ پذير اشاره گرديد. در اين بخش به بررسي نقاط آسيب پذير Apache Web Server و روش هاي تائيد کاربران ، خواهيم پرداخت .

سومين نقطه آسيب پذير : Apache Web Server

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

سيستم هاي عامل در معرض تهديد

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

نحوه تشخيص آسيب پذيري سيستم

بمنظور آگاهي و کسب اطلاعات لازم در خصوص نحوه تشخيص آسيب پذيري سرويس دهنده وب آپاچي ، مي توان از آدرس هاي زير استفاده نمود :
• در رابطه با Apache 1.3.x را مي توان از آدرس http://www.apacheweek.com/features/security-13
• براي Apache 2.0.x مي توان از آدرس http://www.apacheweek.com/features/security-20
آدرس هاي اشاره شده ، داراي اطلاعات فني لازم بمنظور نحوه تشخيص آسيب پذيري سيستم و پيشنهادات لازم در خصوص ارتقاء وضعيت امنيتي مي باشند . استفاده از آدرس: http://httpd.apache.org نيز در اين زمينه مفيد است .

نحوه حفاظت در مقابل نقطه آسيب پذير

بمنظور حفاظت يک سرويس دهنده وب آپاچي ، پيشنهادات زير ارائه مي گردد :
• اطمينان از نصب آخرين patch ارائه شده
- در اين رابطه مي توان از آدرس http://httpd.apache.org بمنظور آگاهي از آخرين وضعيت نسخه ها و Patch levels استفاده نمود.
- بمنظور دستيابي به Source code اکثر نسخه هاي آپاچي، مي توان از آدرس http://httpd.apache.org/download.cgi استفاده نمود.
- بمنظور آگاهي و دريافت آخرين Patch هاي ارائه شده مي توان از آدرس http://www.apache.org/dist/httpd/patches/ استفاده نمود.
• اطمينان از patching عناصر کليدي سيستم عامل که آپاچي بعنوان مرجع از آنان استفاده مي نمايد .در اين رابطه لازم است که صرفا" ماژول هاي ضروري بمنظور صحت عملکرد سرويس دهنده ، در آپاچي کمپايل گردند .لازم است به اين نکته اشاره گردد که کرم( mod_ssl ( CA-2002-27 نمونه اي کامل در اين زمينه بوده که از نقاط آسيب پذير در( OpenSSL ( CA-2002-23 استفاده نموده است .
• از اجراي آپاچي بعنوان ريشه ، اجتناب و مي بايست بدين منظور ، کاربر و يا گروهي خاص با حداقل مجوز ايجاد گردد. ساير پردازه هاي سيستم ضرورتي به اجراء تحت کاربر و يا گروه فوق را نخواهند داشت .
• Chroot ، پتانسيلي است که باعث تعريف مجدد محدوده يک برنامه مي گردد . در حقيقت chroot ، باعث تعريف مجدد دايرکتوري ROOT" و يا "/" براي يک برنامه و يا يک Login session مي گردد .chroot مي تواند بعنوان يک لايه تدافعي استفاده گردد . مثلا" در صورتيکه فردي به کامپيوتر شما دستيابي پيدا نمايد ، قادر به مشاهده تمامي فايل هاي موجود بر روي سيستم نخواهد بود . علاوه بر محدوديت فوق ، محدوديت هائي در خصوص اجراي برخي از دستورات نيز بوجود مي آيد.در اين رابطه يک دايرکتوري با نام chroot/ ، ايجاد و تمامي سرويس هاي مورد نطر با يک انظباط خاص در آن مستقر مي گردند . مثلا" سرويس دهنده آپاچي در chroot/httpd / قرار مي گيرد. با توجه به موارد فوق ، مي بايست آپاچي را در يک محيط chroot اجراء نمود . درصورتيکه آپاچي بصورت chrooted اجراء و فعاليت خود را آغاز نمايد ، امکان دستيابي آن به ساير بخش هاي موجود در ساختار دايرکتوري سيستم عامل و خارج از chroot وجود نخواهد داشت . بدين ترتيب يک لايه تدافعي مناسب در خصوص سوء استفاده هاي احتمالي ايجاد مي گردد. بعنوان نمونه ، ممکن است يک shell فراخوانده شده و با توجه به اينکه bin/sky / در chroot قرار ندارد ، مي تواند زمينه سوء استفاده احتمالي را فراهم نمايد. لازم است به اين نکته مهم نيز اشاره گردد که Chrooting آپاچي مي تواند اثرات جا نبي نامطلوبي را در ارتباط با CGI,PHP ، بانک هاي اطلاعاتي و ساير ماژول ها و يا ارتباطاتي که محيط سرويس دهنده وب بمنظور سرويس دهي به آنان نيازمند دستيابي به توابع کتابخانه اي خارجي است را بدنبال داشته باشد .روش هاي متعددي بمنظور chrooting وجود داشته و مي بايست از مستندات نرم افزار مورد نظر ، بعنوان يک منبع اطلاعاتي مناسب در خصوص ارائه راهکارهاي مربوطه ، استفاده گردد
• بمنظور مديريت يک سرويس دهنده وب ، لازم است فيدبک هاي لازم در خصوص فعاليت و کارآئي سرويس دهنده و ساير مسائلي که ممکن است يک سرويس دهنده با آنان برخورد نمايد را اخذ و در ادامه با آناليز آنان تمهِيدات لازم در خصوص مسائل موجود را بکار گرفت . سرويس دهنده آپاچي ، قابليت ها و پتانسيل هاي انعطاف پذيري را در خصوص logging ارائه مي نمايد . بنابراين لازم است عمليات logging با دقت نظر بالا بصورت موثر و موشکافانه انجام تا امکان رديابي هر نوع فعاليت امنيتي غير مجاز و يا رفتار غير منطقي سرويس دهنده ، فراهم گردد .پيشنهاد مي گردد که با يک نظم خاص از اطلاعات موجود در فايل هاي لاگ ، آرشيو تهيه شود . بدين ترتيب ، امکان مديريت فايل هاي لاگ و بررسي آنان فراهم خواهد شد. بمنظور آشنائي با فرمت هاي متفاوت لاگ مي تواند از منابع زير استفاده نمود :
- براي Apache 1.3.x از آدرس http://httpd.apache.org/docs/logs.html استفاده شود .
- براي Apache 2.0.x از آدرس http://httpd.apache.org/docs-2.0/logs.html استفاده شود .
در موارد متفاوتي و با توجه به شرايط پيش آمده ممکن است محتوي فايل هاي لاگ بتنهائي کافي نباشد . وضعيت فوق در موارديکه از PHP ، CGI و يا ساير تکنولوژي هاي مبتني بر اسکريپت استفاده مي گردد ، تشديد و مي توان بمنظور افزايش توان آناليز يک تهاجم و سوءاستفاده از يک ضعف امنيتي ، اقدام به ثبت لاگ هاي مربوط به GET و POST نمود.لاگ نمودن عمليات مرتبط به GET و POST مي تواند از طريق mod_Security صورت پذيرد. ModSecurity يک سيستم تشخيص مزاحمين ( Intruder detection ) يوده و پيشگيري هاي لازم در خصوص يک برنامه وب را ارائه مي نمايد . سيستم فوق بهمراه سرويس دهنده وب مستقر و يک پوشش امنيتي مناسب را در جهت پيشگيري از يک تهاجم در ارتباط با برنامه هاي وب فراهم مي نمايد . ModSecurity ، از سرويس دهنده آپاچي حمايت مي نمايد .
- http://www.modsecurity.org
- http://www.securityfocus.com/infocus/17064.152.44.126 152.44.126
• PHP، CGI،SSI و ساير اسکريپت ها . در اين رابطه موارد زير پيشنهاد مي گردد :
- PHP,CGI,SSI و ساير زبان هاي اسکريپت را غير فعال نمائيد ( مگر اينکه ضرورتي جدي در رابطه با آنان وجود داشته باشد ).
- SSI يا Server Side Includes را که مي تواند زمينه مساعدي بمنظور سوء استفاده از سرويس دهنده و الزام آن در جهت اجراي کد ناخواسته گردد را غير فعال نمائيد .
- در صورتيکه ضروري است که از PHP,CGI,SSI و يا ساير زبان هاي اسکريپت استفاده گردد ، مي بايست از SuEXEC استفاده شود. suEXEC ، امکان اجراي اسکريپت ها تحت آپاچي بهمراه يک User Id در مقابل يک Apache User Id را فراهم مي نمايد در حقيقت suEXEC اين امکان را براي کاربران آپاچي فراهم مي نمايد که قادر به اجراي برنامه هاي SSI و CGI تحت يک User Id متفاوت نسبت به User Id مربوط به فراخواني سرويس دهنده وب باشند.بدين ترتيب تهديدات امنيـتي کاهش و امکان نوشتن و اجراي برنامه هاي SSI و CGI اختصاصي نوشته شده توسط مهاجمان ، حذف خواهد شد . استفاده از suEXEC ،مي بايست توام با آگاهي و دانش لازم باشد چراکه در صورت استفاده نادرست و يا عدم پيکربندي مناسب و شناخت نسبت به مديريت setupid Root ، خود باعث بروز حفره هاي امنيتي ديگر خواهد شد.. در اين رابطه و بمنظور آشنائي با نحوه عملکرد و استفاده از 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 متعلق به کارکنان و يا پيمانکاراني که سازمان را ترک نموده اند ، استفاده گردد .
در بخش سوم اين مقاله به بررسي ساير نقاط آسيب پذير يونيکس و لينوکس خواهيم پرداخت .