منع جهاز من اخذ Ip من ال Dhcp

هناك طريقة اخي موجوده وتنفع مع windows 2003

طبقتها لدي في الشركه وهي ناجحه جدا ومجانا

سأزودك بالتفاصيل لاحقا

عموما يمكنك ان تبحث عن

Callout for DHCP

وهي عباره عن تسجيل MAC لكل الاجهزه في ملف ومن ثم لا يعطى اي ايبي الا للاجهزه الموجوده في الملف

لو احتجت المزيد من التفاصيل ف مرحبا بك

السلام عليكــم ورحمـة الله وبركاتــه ،،

شكراً اخى عياض على ردك

سوف اقوم بالبحث عن callout for DHCP

ان شاء الله

شكراً للمساعده

السلام عليكــم ورحمـة الله وبركاتــه ،،

أخى عياض

لقد قمت بتحميل برنامج Callout وقرأت التعليمات الخاصة به، ولكن لى استفسار.

ما هو الملف الذى سوف اضيف فيه قائمة عناوين الماك الخاصة بالاجهزة؟؟

هل من المفترض ان اقوم انا بإنشاء ملف TXT ولكن اين اضع الملف ؟؟ وما هو الاسم الذى يفترض ان يسمى به الملف؟؟

اسف على التاخير اخي

الملف يجب ان يكون TXT

واسمه

callout.txt

يجب ان تضعه على ملف مشاركه على نفس السيرفر او سيرفر اخر

وسم المشاركه callout

وستجد في الاعداد انك تضع عنوان المشاركه ليستدل عليه البرنامج ،

مثال \\server\callout

وبالمناسبه يمكنك ان تصنع ملف واحد وتستفيد منه لأكثر من سيرفر

ملاحظه مهمه جدا ، يحب ان تكون العناوين بالاحرف الانجليزيه الصغيره وليس بالاحرف الكبير

وجاهزينلك لأي استفسارات اضافيه

اعطاء وتوزيع آي بيهات مختلفة في نفس الـbroadcast domain _لا_ يزيد من مستوى الأمان اطلاقا، والبرودكاستس ستصل وبإمكانه تطبيق طرق هاكينج كـarp spoofing حتى لو كان رقمه مختلف، كما ان الزائر إذا غير الـip يدويا سيكون موظف جميل مثل البقية. الخاصية التي تستخدمونها لا تغير الـvlans اطلاقا.

هكذا أنتم قتلتم الفكرة الأساسية من الـdhcp ألا وهو راحة البال وتوزيع أرقام ديناميكيا دون انشاء أي ملف استاتيك. عدتم للوراء إلى عالم bootp سنة 1985 عندما كان البشر يسجلون قائمة بالماكات وأرقامها كما أنتم تفعلون الآن.

كما أن انه ممكن للزائر أن يتجسس بواسطة wireshark ويمسك شظايا برودكاست ويسجل الماك الي فيه، وثم يضعه في جهازه وهكذا يصبح مستخدم طبيعي مثل أي حد. يعني القضية سهلة جدا اختراقها. وبتطبيقكم هذا في بيئة عمل فالأمان الذي توفرونه مبني فقط على فرضية أن الزائر جاهل.

الحل المثالي هو 802.1x واستخدام خاصية guest vlan و restricted vlan وتوجيههم إلى vlan جديد. الفرق بينهم أن guest vlan هو كلاينت لا يدعم 802.1x بينما الـrestricted vlan هو لكلاينت فشل عملية التعريف او الـauthentication. هنا ستحصل على أمان حقيقي وليس وهمي مبني على جهل الزائر.

eech55 كتب:

الحل المثالي هو 802.1x واستخدام خاصية guest vlan و restricted vlan وتوجيههم إلى vlan جديد. الفرق بينهم أن guest vlan هو كلاينت لا يدعم 802.1x بينما الـrestricted vlan هو لكلاينت فشل عملية التعريف او الـauthentication. هنا ستحصل على أمان حقيقي وليس وهمي مبني على جهل الزائر.

الأمر لم يتضح لي بعد

على أي أساس سيتمكن السويتش من تحديد الضيف من الموظف ؟! ليقوم بتحويله إلى vlan خاصة بالزائرين ?

ولنضع في حساباتنا أن هذا الزائر قد يكون موصولاً على الشبكة عن طريق بورت بكابل أو في الغالب عن طريق الشبكة اللاسلكية

4 up ??

اعذرني ياسين على التأخير. أنا لا أراقب بريدي الإلكتروني وارد بناء على ما أشاهده.

Yassean كتب:

الأمر لم يتضح لي بعد

على أي أساس سيتمكن السويتش من تحديد الضيف من الموظف ؟! ليقوم بتحويله إلى vlan خاصة بالزائرين ?

ولنضع في حساباتنا أن هذا الزائر قد يكون موصولاً على الشبكة عن طريق بورت بكابل أو في الغالب عن طريق الشبكة اللاسلكية

كل جهاز يحتوي على dot1x client. اجهزة وندوز يوجد به هذا الشيء مثبت.

عندما تقوم بتفعيل هذه الخاصية يحدث الآتي:

• السوتش لا يمرر أي شي سوى بروتوكول EAP
  
• بواسطة بروتوكول EAP سيقوم المستخدمين بالتعريف بأنفسهم
  
• طرق التعريف مختلفة، من ضمنها single sign on بواسطة حساب المستخدم الذي قام بالولوج في الجهاز
  
• أنظمة التشغيل لا تقوم بإستخدام dot1x تلقائيا، لذا يجب عليك اعداده. كلك يمين على منفذ الإيثرنت، ثم خصائص ثم لسان أوثنتكيشن.
  
• في حال لم يقم الجهاز بالإشتراك في التحاور بواسطة EAP سیعتبره السوتش داخل guest vlan
  
• في حال قام الجهاز بالإشتراك في التحاور بواسطة EAP لكن فشلت عملية التعريف، سيضعه السوتش داخل restricted vlan
  

هذا الكلام يحدث بين السوتش، وجهاز العميل مباشرة. يعني حتى الآن لم يحدث شيء بعيد، فقط من منفذ إلى منفذ.

لكن كيف يقوم السوتش بالتأكد من هذه الصلاحيات؟ كإسم المستخدم وكلمة السر؟

• عندما يقوم السوتش بالتخاطب مع جهاز العميل، بواسطة EAP سيحصل على كلمة السر واسم المستخدم
  
• بعدها سيمرر السوتش هذه البيانات (كلمة سر + اسم مستخدم) إلى خادم RADIUS والذي بدوره سيقوم بالتحقق من هذه الصلاحيات.
  
• بما أن خادم RADIUS سيقوم بالتحقق، يجب عليه دعم بروتوكول LDAP ويسأل خادم أكتف دايركتوري ولا أوبن إلداب ولا شو ماكان
  
• خادم الراديس، عندما يحصل على الجواب، سيقوم بالرد على السوتش ويقوله "نجاح" ولا "سقوط" والسوتش سيتعامل مع ذلك المنفذ كما يجب ويضعه في الفيلان المطلوبة.
  

خلاصة الكلام: هنا فصل _حقيقي_ بناءا على الفيلان، وهذا الفصل مبني على تعريف أفضل بكثير من عنوان الماك.

صحيح أنني ضربت مثال التعريف بواسطة اسم مستخدم وكلمة مرور، لكنها ليست شرطا، هناك عدة طرق من ضمنها اسمارت كارد، وssl certificates.

القضية ربما تبدو معقدة للوهلة الأولى لكنها سهلة. كإعدادات على سوتش ستحتاج تقريبا (اذا لم تخني الذاكرة) سطرين أو ثلاثة أوامر على السوتش. مع اعداد خادم راديس. إن شاء الله، سأضع شرحا لهذا خاصة أنه تكرر عدة مرات + طريقة اعداد خادم FreeRadius الشهير الذي يتم استخدامه بواسطة الملايين من المستخدمين دون أن يشعروا، حيث أن العديد من مزودات الخدمة تستخدمه أيضا لتوثيق عمليات الولوج بواسطة ppp المستخدم للديل أب أو الإي دي إس إل.

السلام عليكــم ورحمـة الله وبركاتــه ،،

شكرا eech55

حتى في IAS بامكانك تجد هناك تفاصيل كثيرة فيما يخص التعامل مع Vlans باستخدام 802.1x يمكنك جعل المستخدمين يضافون تلقائيا الى الـ Vlan

التي ينتمون اليها بدل ان يدخلو جميعا الى Vlan واحد

نفس الشئ يمكن تطبيقه على Ethernet

وعليكم السلام ورحمة الله وبركاته،،

لا شكر على واجب يا سيدي.

802.1x يجب توفره في السوتش حتى يتم تغيير الـVLAN. وغيره مستحيل.

بنسبة لخادم IAS من ميكو فما هو إلا تطبيق لـRADIUS في هذا السيناريو. حاله حال Cisco ACS ولا FreeRadius.

هناك ثلاثة أعضاء في 802.1x

supplicant: كلاينت، لابتوب، مثلا يعمل على نظام تشغيل وندوز.

authenticator: سوتش أو أكسس بوينت.

authentication server: اختصارا AS، هذا هو RADIUS. ممكن يكون IAS ولا Freeradios ولا ACS او غيرهم.

الذي يحدث أن الـsupplicant يتخاطب مع authenticator بواسطة بروتوكول EAP

الـauthenticator يقوم ببلوك كل ماهو دون EAP وهذا يشمل DHCP. ولو تقوم بـsniffing ستجد أن الـEAP يتم إرساله هكذا عاريا في الـethernet header من دون IP كما توضح هذه الصورة. فالفكرة أن التخاطب هو مباشر مع السوتش، وليس مع خادم بعيد.

عندما يستقبل الـسوتش او الأكسس بوينت الـEAP وبيانات التوثيق، يروح يكلم الـAS سواءا IAS ولا ACS ولا Freeradius، وثم يستقبل منه الجواب بواسطة بروتوكول Radius

بعدما يستقبل الجواب يقوم بإتخاذ القرار المناسب: إما ابقاء المنفذ مغلقا، أو وضعه في guest/restricted vlan أو فتحه. وهذا القرار يتخذه الـswitch.

فإذا لم يدعم السوتش هذه الخاصية، لن يتم تطبيق 802.1x وفصل الفيلان.

وعليكــم السـلام ورحمة الله وبركاتـه..

اقتباس

802.1x يجب توفره في السوتش حتى يتم تغيير الـVLAN. وغيره مستحيل.

نعم هذا مؤكد

كنت اشير الى سهولة التطبيق في IAS وهو جانب بعيد عن الإهتمام , عموما في هذا الموضوع فيه تفاصيل كثيرة سهلة التطبيق والمتابعة

في مقدور الـ IAS او غيره ان يخبر authenticator ليس فقط بيانات التوثيق وانما بمقدوره ان يضيف اليها ما يرشد authenticator الى vlan محددة سلففا لليوز

صحيح. شكرا للإضافة القيمة.

الخاصية اسمها dynamic vlans. وتصلح لتقسيم فيلان الموظفين. بينما الزائرين مازالوا statically في السوتش، إما restricted أو guest دون تدخل radius.

بسم الله الرحمن الرحيم

كلامك سليم 100/100 أخي eech55

شكراً لك وللمعلومات المفيدة

رزقك الله ووالديك الصحة والعافية والجنة

................

آمين أجمعين، الله يسمع منك.

للعلم كلام أخي newbie أيضا 100% سليم لكنني في البداية ظننته يتحدث عن شيء آخر.