با سلام به کلیه دوستان عزیز........ انشالله که به دردتون بخوره..
اگه ایرادی داره هم بهم بگین ....
:wink: :wink: :wink:
مقدمه :
سرویس احرازهویت ازراه دور radius معمولا برای احرازهویت وبررسی حدود اختیارات و حساب کاربران dial up درشبکه های خصوصی مجازی واخیرا برای دسترسی درشبکه های بی سیم فراهم آمده است.
این مقاله نگاهی داردبه radius و پروتکل eap و درمورد به حداقــــل رساندن یا حل کردن پیامدهای مختلف امنیت این پروتکل و همچنین پیاده سازی و گسترش آن به بهترین نحو بحث می کند.
نگاهی به RADIUS :
radius یک قرارداد گسترش یافته با توانائی متمرکز کردن احرازهویت ، تعیین حدود اختیارات و مدیریت حسابهای کاربران برای دسترسی درشبکه بکار می‌رود. عموما برای دسترسی راه دور توسعه پیدا کرد ولی درحال حاضر بوسیله شبکه های *** ،نقاطی که از طریق بی سیم بهم متصل هستند ، احرازهویت سوئیچهای اترنت ،خطوط دستیابی dsl و انواع شبکه هایی که دسترسیهای مختلف پشتیبانی میشود.
Radius با استاندارد RFC 2865 تشریح شده است.
یک سرویس گیرنده RADIUS (نوعا یک ACCESS SERVER،مانند یک سرور DIAL UP ، سرور*** یا WIRE LESS ACCESS POINT) یک دسته از اطلاعات و پارامترهای مربوط به اتصال تحت عنوان RADIUS MESSAGE، به سرور ارسال می کند.
سرور، هویت سرویس گیرنده را تعیین و حدود اختیارات آنرا مشخص می کند و در پاسخ یک RADIUS MESSAGE برای سرویس گیرنده ارسال می کند.سرویس گیرنده های RADIUS همچنین RADIUS ACCOUNTING MESSAGE را به سرورهای RADIUS ارسال می کنند.
بعلاوه استانداردهای RADIUS ازپروکسی های RADIUS پشتیبانی می کند.
یک پروکسیRADIUS یک کامپیوتر است که پیامها را مابین سرویس گیرنده ها و دیگر پروکسی هائی که از RADIUS استفاده می کنند ، پیش می برد.
پیامها هرگز ازسوی ACCESS CLIENT و ACCESS SERVER ارسال نمی شوند.این پیامها بصورت پیامهای UDP ارسال می شوند.
پورت1812UDP ، برای پیامهای احراز هویت استفاده می شود و پورت1813 برای ACCOUNTING MESSAGE استفاده می شود.برخی خدمات دسترسی باید از پورت 1645 برای پیامهای احرازهویت و پورت 1646 برای پیامهای ACCOUNTING ارائه شوند.
فقط یک RADIUS MESSAGE شامل UDP PAYLOAD یک بسته می باشد.
RFCهای 2865و2866 انواع پیامهای زیر را تعریف می کند:
ACCESS REQUEST :
این درخواست از طرف سرویس گیرنده به منظور تلاش برای برقراری ارتباط با شبکه ، جهت احراز هویت و تعیین حدود اختیارات فرستاده می شود.
ACCESS ACEPT :
بوسیله یک سرور در پاسخ به ACCESS REQUEST فرستاده میشود این پیام نشان می دهد که سرویس گیرنده موردنظر در تلاش برای برقراری ارتباط،ATHENTICAT و AUTHORIZE شده است.
ACCESS REJECT :
در پاسخ به یک ACCESS REQUEST توسط سرور فرستاده میشود. این پیام نشان می دهد که سرویس گیرنده موردنظر در تلاش برای اتصال به شبکه صلاحیت نداشته است. یک سرور زمانی این پیام را می فرستد که گواهینامه سرویس گیرنده برای تلاش به برقراری اتصال، صلاحیت احراز هویت و یا تعیین حدود اختیارات لازم را ندارد.
ACCESS CHALLENGE:
توسط یک سرور در پاسخ به یک ACCESS REQUEST فرستاده میشود این پیام یک نوع رقابت بین سرویس گیرنده ها است که میخواهند پاسخ خود را دریافت کنند.
ACCOUNTING REQUEST:
پس ازبرقراری یک اتصال یکسری اطلاعات درمورد حسابهای کاربری ازسوی سرویس گیرنده فرستاده می شود.
ACCOUNTING RESPONSE :
توسط یک سرور در پاسخ به پیام ACCOUNTIG REQUEST فرستاده میشود.
یک پیام RADIUS شامل دو بخش HEADER و ATTRIBUTES می باشد. هر خصوصیت یک بخشی از اطلاعات درباره تلاش برای ایجاد اتصال را مشخص می کند.
برای نمونه ، خصوصیاتی مانند : نام کاربر،کلمه عبوراو،نوع خدمات خواسته شده توسط کاربر،آدرس IP دسترسی به سرور دراین قسمت وجوددارند.
خصوصیات به منظور ردوبدل کردن اطلاعات بین سرویس گیرنده ها و پروکسیها وسرور RADIUS استفاده میشوند.
برای مثال، لیست خصوصیات لازم جهت برقراری اتصال ، در پیام ACCESS REQUEST شامل اطلاعاتی درباره اختیارات کاربرو پارامترهای لازم دیگر می باشد.
درواقع لیست خصوصیات مربوط به ACCESS ACCEPT شامل اطلاعاتی درباره نوع اتصــــــــالی که
می تواند ایجاد شود و محدودیتهای اتصال می باشد.
خصیصه‌هایRADIUS،بوسیله‌استا نداردهای 2865،2866،2846،2868،2869و3162 تشریح شده اند.
این RFCها و طرح هائی که سرویس دهنده ها آنها را لازم الجرا می دانند و باید از سوی سرویس گیرنده رعایت شوند،درمجموع خصیصه های RADIUS را تعریف می کنند.
در پروتکل های نقطه به نقطه مانند:PAP،CHAP،MS CHAP،MS CHAP V2نتایج تصدیق هویت ردوبدل شده میان ACCESS SERVER و ACCESS CLIENT به منظور بررسی به RADIUS SERVER فرستاده می شوند.
به منظور فراهم آوردن امنیت برای پیامهای RADIUS سرویس گیرنده و سرور براساس کلیدمشترک عمومی هماهنگ میشوند.کلیدمشترک برای ایجاد امنیت درردوبدل کردن اطلاعات است و بطور معمول بصورت یک رشته متنی روی سرویس گیرنده و سرور می باشد.
نگاهی به پروتکل الحاقی تصدیق هویت
EAPبه پروتکل PPP جهت گسترش مکانیزمهای تصدیق هویت به منظور دسترسی به شبکه،اضافه گردید. با پروتکلهای تصدیق هویت PPP مانند: CHAP،MS CHAP،MS CHAP V2 یکسری مکانیزمهای خاصی در طول فاز برقراری اتصال انتخاب میشوند.درمدتی که تصدیق هویت اتصال بررسی میشود پروتکل تصدیق هویت محاوره ای به منظور تائید اعتبار اتصال مورداستفاده قرار میگیرد.
پروتکل تصدیق هویت یک رشته ثابت ازپیامها را باتوجه به درخواست خاص می فرستد.با EAP مکانیزمهای تصدیق هویت خاصی درطول فاز برقراری پیوندPPP انتخاب نمی شوند. درعوض هرطرف برای اجرای EAP درطول فاز تصدیق هویت اتصال محاوره می کند.
زمانیکه فازتصدیق CONNECTION فرا می رسد،دوطرف ارتباط درمورد شمای تصدیق هویت موردنظرشان محاوره می کنند که EAP TYPE نامیده می شود.بمحض اینکه EAP TYPE مشخص شد،اجازه ردوبدل کردن پیامها میان سرویس گیرنده و سرور داده میشود که می تواند براساس پارامترهای اتصال متفاوت باشد،این محاوره شامل درخواستهایی برای تصدیق هویت و پاسخ آنها می باشد .جزئیات و طول این محاوره بستگی به نوع EAP دارد.
بانصب فایل کتابخانه ای نوع EAP برروی سرویس گیرنده و سرور، آن نوع EAP جدید می تواند ،پشتیبانی شود.
EAP انعطاف بسیارخوبی برای بیشترمتدهای تصدیق هویت امنیتی فراهم می کند.شما می توانید از EAP برای پشتیبانی ازطرح های تصدیق هویت مانند: کارت رمزعمومی،OTP،MD5 CHALLENGE،امنیت لایه انتقال برای کارت هوشمند استفاده کنید.
(بخوبی هر تکنولوژی تصدیق هویتی که درآینده می آید.)
درمجموع برای پشتیبانی شدن توسط پروتکلPPP،EAP توسط لایه پیــــــوند IEEE802هم پشتیبــانی
می شود.
IEEE802.1X یک استاندارد IEEE برای تصدیق هویت پورت شبکه است،که تعریف می کند ،چطور EAP برای تصدیق هویت از ابزارهای IEEE802،شامل IEEE802.11B نقاط دسترسی بی سیم و سوئیچهای اترنت استفاده می شود.
IEEE802.1X با پروتکل PPP که فقط متدهای تصدیق هویت EAP را پشتیبانی می کند،متفاوت است . در نتیجه امکان استفاده از PAP بصورت محاوره ای برای آن وجود ندارد.
EAP OVER RADIUS:
EAP OVER RADIUS یک نوع EAP نیست،اما پیامهای EAP هرنوعEAP رابوسیله ACCESS SERVER به سرور RADIUS به منظور تصدیق هویت عبور میدهد.
یک پیام EAP بین ACCESS CLIENT و ACCESS SERVER به شکل یک پیام EAP با خصوصیات RADIUS(RFC2869) فرستاده میشود.
ACCESS SERVER یک ابزار برای عبوردادن پیامهای EAP میان ACCESS CLIENT و سرورRADIUS می باشد.پردازش پیامهای EAP،توسط سرورRADIUS و ACCESS CLIENT
می باشد نه ACCESS SERVER.
Eap over radius درمحیطهایی که radius عمل تصدیق هویت رابرعهده دارد استفاده میشود.یک مزیت استفاده از eap over radius این است که نیازی به نصب انواع eap روی access server نمی باشد،تنها نصب آن روی سرور radius کافی میباشد.
Access server باید از انتقالات eap بعنوان پروتکل تصدیق هویت پشتیبانی کند و پیامهای eap رابه سرور انتقال دهد.
در یک eap over radius ،access server برای استفاده از eap و radius،بعنوانprovider تصدیق هویت تنظیم شده است.
زمانیکه تلاش برای برقراری اتصالا صورت می گیرد،access client درموردeap با access server گفتگو می کند.
زمانیکه سرویس گیرنده یک پیامeapبه access server می فرستد،access server پیام را مانند یک پیامradius بسته بندی کرده و آنرا به سروری که بااو هماهنگ شده می فرستد. سرورپیام را پردازش می کند وبهACCESS SERVERبرمیگرداند. سپس ACCESS SERVER پیام EAP را به ACCESS CLIENT می فرستد.
RADIUS SECURITY ISSUES AND SOLUTIONS:
درادامه عملکردهای امنیتی و حملات احتمالی به سرورهای RADIUS توضیح داده خواهد شد. این عملکردها بسته به توانائی مهاجم درگرفتن پیامهای RADIUSمیان ACCESS SERVER و سرور RADIUS متفاوت می باشد.
این موضوع نشان می دهد که مهاجم دسترسی فیزیکی به شبکه دارد و درمسیرمیان سرور و ACCESS SERVER می باشد.
پیامهای ACCESS REQUEST که تصدیق نمیشوند:
فرض کنیم که هیچ گونه نظارتی روی پیامهای ACCESS REQUEST واردشده به سرور وجودندارد. سرور پیامی را که از آدرس IP یک سرویس گیرنده سرچشمه گرفته ،بررسی می کند،اما آدرسهای IP مبدا برای اینکه همراه پیام فرستاده می شوند براحتی ربوده میشوند.
یک راه حل این است که سرور خصیصه تصدیق کننده پیام را روی همه پیامهای ACCESS REQUESTدرخواست کند.این خصیصه یک پیامMD5شده ازپیامACCESS REQUESTبی نقص است که از رمز مشترکی که کلید خوانده می شود،استفاده می کند.
ACCESS SERVER باید پیامهای ACCESS REQUEST را باخصیصه تصدیق کننده پیام بفرستد و اگرخصیصه تصدیق کننده پیام وجودنداشته باشدیا اشتباه باشد،سرور باید آن پیام را دور بیاندازد.معمولا خصیصه تصدیق کننده پیام تنها توسط پیامهایEAP OVER RADIUS درخواست میشوند.
برای مثال شما میتوانیدRASوROUTING را در سیستم عامل WIN2000 تنظیم کنید و خصیصه تصدیق کننده پیام را برای هرپیامACCESS REQUEST بفرستید.البته اینکاروابسته به این موضوع است که شما درتنظیمات خصوصیات سرورRADIUS،گزینه ALWAYS USE DIGITAL SIGNATURES راانتخاب کنید.
شما میتوانید سرویس تصدیق هویت اینترنت WIN2000(IAS) راطوری تنظیم کنیدکه از هرپیام ACCESS REQUEST خصیصه تصدیق کننده پیام را درخواست کند و اینکارازطریق انتخاب گزینه CLIENT MUST ALWAYS SEND THE SIGNATURE ATTRIBUTE IN THE REQUESSTکه درمجموعه خصوصیات سرویس گیرنده هست،میسر میشود.
اگرخصوصیت تصدیق کننده پیام برای هم پیامهای ACCESS REQUEST قابل استفاده نباشد،ازمکانیزم تحریم و شمارش تصدیق هویت استفاده میشود.یکی از نمونه های دسترسی بااستفاده از تحریم و شمارش راه دور درWIN2000 این است که بعداز برقراری اتصال راه دور چنانچه بیش از چندبار(معین شده) تلاش جهت تصدیق هویت صورت گرفت،ازکاربر ممانعت بعمل آید.
دربعضی مواقع کلید رمزعمومی به اندازه کافی تصادفی نیست که بتواند جلوی حمله دیکشنری را بگیرد و به همین خاطر اگر کلید عمومی کشف شود ، فیلد تصدیق کننده ACCESS RESPONSE ودر پی آن محتوای پیام هم براحتی لو می رود.
این وضعیت درسرورها و سرویس گیرنده هائی که اندازه رمزعمومی آنها محدود است و کلید عمومی آنها فقط شامل کاراکترهائی میشود که توسط صفحه کلید زده میشوند و تنها میتوانند 94تا256 کاراکتراسکی را استفاده کنند،بدتر است.
راه حل این پیامد:
• اگر رمزعمومی بایدترتیبی ازکاراکترهای صفحه کلید باشد،آنراطوری انتخاب کنیدکه طول کاراکترها حداقل22 باشد و شامل حروف بزرگ و کوچک ،اعداد و علائم نقطه گذاری باشد.اگررمزعمومی براساس ترتیبی از ارقام هگزادسیمال باشد،ازارقام هگزادسیمال تصادفی باحداقل طول 32 استفاده کنید.
RFC2865 رمزهای عمومی با طول حداقل 16 کاراکتررا معرفی میکند.امابرای رمزهای 128 کاراکتری ،هرکاراکتربایدشامل8بیت کامل باشد.اگررمزعمومی محدود به کاراکترهای صفحه کلید باشد(مخالف اعدادهگزادسیمال باشد)،هرکاراکترتنها5.8بیت دارد.برای فراهم کردن 128بیت،سرویس گیرنده،سروروپروکسی بایدبراساس رمزهای عمومی باطول حداقل22کاراکترتنظیم شوند.بعنوان مثال،رمزهای عمومی برایIAS ویندوز2000 میتواند طول بیش از64 کاراکترداشته باشد.
برای اطمینان ازرمزعمومی تصادفی ازیک برنامه برای تولید رمزهای باطول حداقل22کاراکتر استفاده میشود.
• استفاده از رمزهای عمومی متفاوت برای هرزوج سرور-سرویس گیرنده.
خصیصه های رمزشده ،بوسیله مکانیزمهای مخفی سازی radius استفاده میشوند:
مکانیزم پنهان سازیRADIUS ،ازرمزعمومیRADIUS،تعیین کننده هویت درخواست،الگوریتمMD5 HASHING برای رمزگذاری رمزعبورکاربر ودیگرخصیصه ها مانندTUNNEL PASSWORD و MS CHAP MPPE KEYS استفاده می کند.
درزیرعملکرد و وضعیت های RFC2865 آمده است :
استفاده از یک روند رمزکردن و MD5 به عنوان روش رمزکردن ،از بخشهای ویژه RADIUS هستند.تنها راه استاندارد که به حفاظت از خصیصه ها کمک می کند این است که ازIPSECبهمراهESP و یک الگوریتم رمزکردن مانند3DES،برای فراهم کردن داده های مطمئن برای کل پیامهای RADIUS استفاده شود.
اگراستفاده ازIPSECبهمراهESPو الگوریتم رمزکردن ممکن نباشد،مدیران شبکه می توانندبا انجام کارهای زیرمیزان آسیب پذیری را به حداقل برسانند:
- درخواست استفاده از خصیصه تصدیق کننده پیام(MESSAGE AUTHENTICATOR ATTRIBUTE)درهمه پیامهای ACCESS REQUEST.
- استفاده از الگوریتم های رمزنگاری قدرتمند جهت تصدیق هویت.
- استفاده از رمزعبورهای قوی.
- استفاده از یک مکانیزم شمارش و تحریم برای مقابله با حمله دیکشنری ONLINE.
- استفاده از کلید عمومی 128بیتی.
Poor request authenticator values can be used to decrypt encrypted attributes:
همان طور که درRFC2865اشاره شد،یک تصدیق گردرخواست باید موقتی و درعین حال یکتا باشد. کلید خصوصی و کلید عمومی باهم ترکیب شده و KEY STREAM را تعریف میکنند که برای رمزنگاری رمزعبور کاربرو دیگرخصیصه ها استفاده می شود.
این موضوع ممکن است به یک مهاجم( که توانائی گرفتن اطلاعات ردوبدل شده میان سرویس گیرنده RADIUS و سرور را دارد وتلاش می کند که وارد شبکه شود)اجازه ساختن یک دیکشنری از کلیدهای خصوصی ومتناظرباKEY STREAM را بدهد.اگرمقدار REQUEST AUTHENTICATOR همواره بوسیله ACCESS SERVER(که از رمزعمومی مشابه استفاده می کند)تکرارشود،پس رمزعبورودیگرخصیصه ها که دراین میان ردوبدل می شوند،براحتی تعیین می شوند.
اگر REQUEST AUTHENTICATORبه اندازه کافی تصادفی نباشد،براحتی تشخیص داده میشود.
تولیدکنندهREQUEST AUTHENTICATORبایدازمکانیزم رمزنگاری بالائی برخوردارباشد،درغیراینصورت ،میتوان ازیک الگوریتم رمزنگاری مانند3DES و همینطورIPSEC بهمراه ESP استفاده کرد،که داده های مطلوب برای کل پیامهایRADIUS فراهم کند،همانگونه که درRFC3162 تشریح شده است.
Radius implementation and deployment best practices:
برای نشان دادن عملکردهای امنیتی radius بایددرموردپیاده سازی و انتشار این پروتکل ،دقت و تمرین زیادی کرد.
به منظور فراهم کردن داده مطمئن برای کل پیامهای radius ،باید IPSEC بهمراه ESP و یک الگوریتم رمزنگاری مانند3DES را پیاده سازی کنیم.
این موضوع درRFC3162 توضیح داده شده است.زمانیکه کل پیامهای RADIUS با IPSEC رمزنگاری می شوند،فیلدهای حساس RADIUS (مانند:فیلد تصدیق گردرخواست درACCESS REQUEST)وخصوصیاتی‌مانند‌رمزع بور،TUNNEL PASSWORD،MPPE KEY ATTRIBUTES)محافظت می شوند.یک مهاجم ابتداESP PROTECTEDیک پیام را رمزگشائی میکند قبل از اینکه بتواندمحتوای پیام را تحلیل کند.
دریک اتصال که از IPSEC استفاده می شود باید روند زیر انجام شود:
• اجازه تنظیم و استفاده از رمزهای عمومی باحداقل طول32هگزادسیمال یا کاراکترهای صفحه کلید با حداقل طول 22.
• استفاده‌از‌تصدیق‌گرپیام (MESSAGE AUTHENTICATOR)برای تمام‌پیامهای ACCESS REQUEST.
برای یک سرویس گیرنده،مکانیزم استفاده از تصدیق گر پیام‌رابرای همه پیامهای ACCESS REQUEST پیاده سازی کنید .یک سرور یا پروکسی باید طوری پیاده سازی شود که تصدیق گرپیام را از همه پیامهای ACCESS REQUEST درخواست کند.
• پیاده سازی‌یک‌تولیدکننده CRYPTOGRAPHIC QUALITY RANDOM برای تصدیق گر پیام.
برای اینکه حفاظت بیشتری درمورد احرازهویت سرویس گیرنده داشته باشیم،ازروشهای زیراستفاده میکنیم:
• پیاده سازی EAP و انواع آن و استفاده از روشهای احرازهویت قدرتمند دراین زمینه.
• یک نمونه خوب دراین زمینه EAP TLS است که مجوزهای ردوبدل شده میان ACCESS CLIENT و ACCESS SERVER را درخواست می کند. همه پیامهای EAP،خصیصه تصدیق گر پیام را (که برای محافظت از ACCESS REQUESTها زمانیکه از IPSEC استفاده نمی شود ،بکارمی رود)درخواست می کنند.
• پیاده سازی روشهای احرازهویت دوطرفه.
بااستفاده ازاحرازهویت دوطرفه،دوطرف ارتباط هویت یکدیگررا بررسی‌میکنند.اگراحرازهویت هرکدام منجربه شکست شود،تلاشی که برای برقراری ارتباط صورت گرفته،REJECT میشود.به عنوان نمونه،EAP TLSو MS CHAP V2 روشهائی ازاحرازهویت دوطرفه می باشند.بااستفاده از EAP TLS ،سرور گواهینامه کاربر را که از طرف ACCESS CLIENT می آیدتائیداعتبار می کندو همینطورACCESS CLIENTگواهینامه‌سرور را تاییداعتبارمی کند.بااستفاده زاMS CHAP V2 هردوی ACCESS CLIENT و ACCESS SERVER گواهی رمزعبور کاربررا بررسی می کنند.
• اگرپروتکل PPPپیاده‌سازی‌شود،استفاد ه‌ازروش‌پیش‌فرض مقدورنیست. بـــرای‌مثـــــالOTP/TOKENCARDازPAPبمنظورفرستادن‌اط اعات‌احرازهویت استفاده میکند.اگـرشما‌بایدPAP راپیاده سازی کنید،USE BY DEFULTرا غیرفعال کنید ازرمزهای طولانی و تصدیق کننده های رمزشده استفاده کنید،بدلیل اینکه IEEE802.1X،PAP راپشتیبانی نمی کند، این روندتنها برای ارتباطات نقطه به نقطه کاربرد دارد.
• اگرCHAPرا‌پیاده‌سازی‌می‌ک نید،ازیکCHAP CHALLENGE قوی استفاده کنید.
• اگرMS CHAP را پیاده سازی می کنید، این روش رمزعبورهای تغییریافته و یاپاسخهای رقابتی رمزشده را برای LAN MANAGER پشتیبانی نمی کند.
DEPLOYMENT BEST PRACTICES:
به منظور فراهم کردن داده مطمئن برای کل پیامها،سرویس گیرنده ها و سرورهارابایدبراساس IPSECوESPو3DES تنظیم کنید.
تنظیم IPSEC ESPبهمراه 3DES برای RADIUSبه پیاده سازیIPSEC بستگی دارد.برای مثال،اگرشما ازRRAS WIN2000،برای ACCESS SERVER و IAS WIN2000 برای RADIUS SERVERو محیط ACTIVE DIRECTORY استفاده میکنید،میتوانید ACTIVE IPSEC POLICY برای یک سیستم مناسب (که ازقانونESP و الگوریتم رمزکردن 3DES برای همه تبادلات از و به پورتهای UDP 1812,1813 استفاده می کند)تنظیم کنید.برای دسترسی به اطلاعات بیشتر میتوانید از HELP ویندوز2000 استفاده کنید.
درصورت استفاده از IPSEC در اتصال باید روال زیرانجام شود:
• استفاده از رمزهای عمومی که شامل یک ترتیب تصادفی ازاعداد هگزادسیمال باطول حداقل32رقم یایک ترتیب تصادفی ازحروف بزرگ و کوچک ،اعدادوعلائم نقطه گذاری باطول حداقل22کاراکتر.بهتراست‌رمز عمومی‌توسط‌کامپیوترتولید شود.
• استفاده ازرمزعمومی متفاوت برای هرجفت سرویس‌گیرنده-سرور.هرسرویس‌گیرنده را طوری تنظیم کنیدکه تصدیق‌گرپیام را با همه پیامهای ACCESS REQUEST ارسال کند.هرسرور راهم طوری تنظیم کنیدکه ازهرسرویس‌گیرنده تصدیق‌گرپیام رابه همراه ACCESS REQUEST درخواست کند.
• استفاده سرویس‌گیرنده ها،سرورهاوپروکسی هاازیک روش رمزنگاری احرازهویت قوی.برای فراهم کردن حفاظت بیشترازهویت‌سرویس‌گیرنــ ـده،ازروشـــهای‌زیراستفـ ـاده میشود:
اگرازروشPAPاستفاده‌نمیشود، استفاده‌ازاین‌روش‌رادرACC ESS-SERVERوRADIUS-SERVERغیرفعال‌کنید.
تنهــاکاربـــردقــابل‌قب ل ازPAPبعنوان اتصال ایمن OTPوTOCKEN CARD AUTHENTICATIONاست که رمزعبورازENTROPY بالائی برخوردار است و برای هرباراستفاده رمزعبورتغییرمی کند.فعال کردن PAP باعث میشود که سرویس گیرنده و ACCESS SERVERبصورت‌محاوره‌ای‌عمل نکنندوسرویس‌گیرنده‌رمز بــــــوررابدون اعمال هرگونه حفاظتی بفرستد.یک راه‌حل بهتراستفاده ازEAP وانواع آن برایOTP و TOKEN CARD AUTHENTICATIONمی باشد.
اگرازMS CHAP استفاده میکنید،USE OF LAN MANAGER راغیرفعال کنید.
اگرازIASویندوز2000 استفاده میکنید،مقدارکلیدرجستری زیررا درIASسرور صفرکنید.
HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\
SERVICES\REMOTACCESS\POLICY\
ALLOW LM AUTHENTICATION
• استفاده از EAP وانواع آن به همراه روشهای احرازهویت قوی.
احرازهویت IEEE802.1X برای نقاط با دسترسی بی سیم با استفاده ازEAP،خصیصه تصدیق‌گرپیام رابرای محافظت ازهرACCESS REQUESTنیازداردوهمچنین PAPراپشتیبانی نمی کند.
• استفاده از تصدیق هویت دوطرفه مانندEAP TLSوMS CHAP V2.
اگه اطلاعاتی درمورد نقاط ضعف این پروتکل میدونید ممنون میشم به منم بگین.
با تشکر.
بای
