تو مقاله قبلی اهمیت و الزام وجود امنیت در LAN  را به خوبی درک کردیم و دیدیم برای جلوگیری از حملاتی مانند ARP Spoofing  باید از DAI  استفاده کرد که پیش نیاز آن  استفاده از DHCP Snooping  بود.

قبل از بررسی Dynamic ARP Inspection یا همان DAI  بریم خطراتی که پروتکل DHCP  برای ما ممکن است ایجاد کند را باز کنیم.

DHCP Attack

DHCP  یک سرویس Server/Client  ای می باشد و از چهار پیغام زیر استفاده میکند.

DHCP Discover

DHCP Offer

DHCP Request

DHCP ACK

که Client  توسط پیغام Discover  که به صورت Broadcast  است Server  را پیدا میکند.

باز سر و کله بسته Broadcast  پیدا شد وکلی خطر.

دو پیغام Discover  و Request  را کلاینت تولید می کند و پیغام های Offer  و ACK  را سرور.

DHCP  توسط UDP  حمل می شود و کلاینت با SRC Port 68  و DST Port 67 با سرور صحبت میکند و سرور با SRC Port 67  و DST Port 68  با کلاینت.

دقت داشته باشید که پیغام های DHCP هدر IP  دارند و مانند بسته های ARP  نیستند.

خب بریم ببنیم کجا مشکل ساز می شود این بسته Broadcast

اگر Client  درخواست DHCP  ارسال کند سوییچ آن را روی تمامی پورت های که تو Vlan  ارسال کننده هستند Flood  میکند حال اگر به جای اینکه Server  اصلی ما جواب کلاینت را دهد یک Attacker  این کار را کند و تنظیمات اشتباه به کلاینت میدهد و حتی می تواند Default Gateway  را خودش معرفی کند و Man In The Middle  بزند.

این Attack  معروف به DHCP Spoofing  میباشد.

راه جلوگیری از این Attack استفاده از DHCP Snooping  در سوییچ است ، کافیست پورت های سوییچ را در دو حالت Trust  و UNTrust  قرار دهیم و اینترفیس های که در وضعیت UNTrust  قرار دارند اگر بسته های DHCP Offer  یا DHCP ACK  دریافت کنند آن را دور می ریزند زیرا این پیغام ها مخصوص سرور است و فقط اینترفیسی که سرور ما روی آن قرار دارد را در وضعیت Trust  قرار میدهیم.

نکته : با فعال کردن DHCP Snooping  تمامی اینترفیس ها در وضعیت UNTrust  قرار میگیرند.

نکته : اگر DHCP Snooping  را در سوییچ فعال کنیم جدولی در سوییچ تشکیل می شود که آمار پروتکل DHCP  را دارد به عنوان مثال می داند که این IP  برای این MAC  در این مدت قرض داده شده است که یک جور Map  کردن IP to MAC  میباشد که این جدول کمک زیادی برای جلوگیری از Attack های ARP  را می کند زیرا سوییچ طبق این جدول می داند که این IP  برای این آدرس فیزیکی یا MAC  است و اگر Attacker  بسته gARP  به قصد Attack  بزند سوییچ به کمک این جدول متوجه Spoof  می شود و بسته را دور میریزد.

نکته : باید Dynamic ARP Inspection  را در سوییچ فعال کنیم.

ما تو این مقاله و قسمت یک این مقاله قصد تدریس نحوه Configuration مکانیزم های معرفی شده را نداریم.

یکی دیگر از معضلات پروتکل DHCP  این است که Attacker  می تواند با SRC Mac  های مختلف درخواست DHCP  ارسال کند و اتک DHCP Starvation  صورت بگیرد و Pool  سرور را خالی کند.

راه جلوگیری از این خطر استفاده از Port-Security  در سوییچ است زیرا سوییچ به صورت پیشفرض بینهایت آدرس MAC  را روی اینترفیس خود Learn  می کند و با استفاده از Port Security  می توان آن را کنترل کرد و با فعال کردن آن اگر Attacker  با SRC MAC  های مختلف درخواست ارسال کند روی اینترفیس Violation صورت گرفته و طبق تنظیماتی که در Port Security  انجام دادیم با آن برخورد می شود مانند Shutdown  شدن یا اینترفیس.

MAC Flood

بریم سر تهدید بعدی که MAC Flood  است.

در این روش Attacker  با ارسال بسته هایی با SRC MAC  های مختلف به اینترفیس سوییچ قصد دارد MAC Table  سوییچ را پر کند و اگر بتواند این کار را بکند سوییچ مانند یک HUB  عمل میکند و تمامی ترافیک های را Flood  می کند روی تمامی اینترفیس ها.

برای رهایی از این خطر باز Port Security  به ما کمک میکند.

Broadcast Storm

خب رسیدیم به Broadcast Flood  که در مواقعی می تواند بسیار خطر ساز شود.

اگر کلاینت بسته های Broadcast  بسیاری ارسال کند چه اتفاقی می افتد؟!

بسته های برادکست را همه دستگاه های شبکه تحلیل می کنند سوییچ ها ، روتر ها و کامپیوتر ها و…. و این اصلا جالب نیست.

بسته های برادکست در سیسکو مستقیم توسط CPU  پردازش میشود که این کار را خطرناک تر میکند.

اگر یک دریای از بسته های Broadcast  به همراه MAC Flood  در شبکه خود داشته باشید  می توانید با چشم خود پایین آمدن کارایی شبکه را مشاهده میکنید.

به این دسته از حملات Broadcast Storm  نیز گفته می شود که امروزه سوییچ های سیسکو توانایی تشخیص آن را دارند و می توانند یک نرخی را روی اینترفیس های خود مشخص کنند که اگر تعداد بسته های برادکست بیش از آن بود اینترفیس را به حالت Err-Disable  ببرند.

نمی توانید دریافت بسته های برادکست را روی اینترفیس ها به کل غیر فعال کنید زیرا بسته های مانند درخواست های DHCP  یا ARP Request  های کلاینت ها نیز برادکست هستند و با غیر فعال کردن دریافت بسته برادکست روی اینترفیس با کلی مشکل روبه رو می شوید.

 

VTP Attack

پروتکل VTP  در شبکه های بزرگ کمک بسیاری در Configuration ما میکند ولی از طرفی ممکن است باعث ایجاد خطر شوند.

ضعف های پروتکل VTP Version 1 & 2  باعث شد که امروزه ما از VTP Version 3  استفاده کنیم که خطرات را به حداقل و حتی به صفر برساند.

اشکالات VTP Version 1 & 2

۱- جا به جا شدن اسم Domain و پسوورد  به صورت Clear Text  که ممکن بود با Sniff  کردن و باز کردن بسته های VTP Summary Advertisement  به راحتی به این اطلاعات دست پیدا کنند و مشکل ساز شوند.

۲-عدم توانایی غیر فعال کردن VTP  روی اینترفیس.

۳-نداشتن Primary Server  و Secondary Server

مورد سوم بسیار خطرناک است.

چرا؟!

کلاینت ها و سرور توی بسته هایVTP  از نوع Summary  و Subset  همدیگر را از Revision Number  خود با خبر می کنند و هر تغییری روی Vlan Database  سرور، یک عدد به Revision Number اضافه میکند واگر کلاینت مقدار عدد خود را با سرور مچ نبیند بسته VTP Request  ارسال میکند تا Vlan Database  خود را با سرور Sync  کند.

فرض کنید که در سرور و کلاینت مقدار  Revisionبرابر با ۱۰ باشد و Vlan  های ۱۰،۲۰  و ۳۰  در هر دو سوییچ ساخته شده.

اشکال VTP Version 1 & 2  این است که اگر یک سوییچ جدیدی وارد بازی شود که قبلا VTP  روی آن کانفیگ شده یا حتی Attacker  آن سوییچ را وارد LAN  ما کرده است ( ممکن است Attacker  بسته های VTP  را توسط کامپیوتر شخصی خود شبیه سازی کند) و Attacker  ارتباط خود را با دیگر سوییچ ها برقرار کرده و به کمک ضعف کانفیگ پروتکل DTP  که به صورت پیشفرض روی اینترفیس های سوییچ در حالت مد Auto  قرار دارد، لینک بین خود و دیگر سوییچ ها را Trunk  کرد.

حالا فقط کافی است Attacker  شروع به فرستادن بسته های VTP Summary  با مقدار Revision  بالاتر از ۱۰ کند.

اگر کلاینت ها بسته های آن Attacker  را دریافت کنند خود را با سوییچ Attacker  همگام یا Sync  میکنند و Vlan Database  خود را از آن میگیرند و Vlan  های ۱۰،۲۰  و ۳۰  که از سرور اصلی دریافت کرده است را پاک میکند!!!

حال فرض کنید پورتی از سوییچ کلاینت در Vlan 10  قرار داشته و آن اینترفیس به یک سرور مهم ما وصل بوده ، حالا که Vlan 10  پاک شده است وضعیت آن اینترفیس نا مشخص است و دسترسی به آن سرور از بین میرود.

تمام این مشکلات از آن جا آمد که سوییچ کلاینت هر کسی که Revision بالاتری داشته باشد را به عنوان سرور قبول میکند و خود را با آن Sync  میکند.

این مشکل در VTP Version 3  برطرف شد به کمک ایجاد یک Primary Server  به همین علت است که امروزه پیشنهاد میشود از VTP Version 3  استفاده شود.

Spanning-Tree Attack

یکی از مهم ترین پروتکل های لایه دویی Spanning-Tree  می باشد ، که وظیفه جلوگیری از لوپ لایه دو را در کنار High Availability  را دارد.

Attacker  ها می توانند با استفاده از ضعف کانفیگ STP  در سوییچ ها در شبکه اختلال ایجاد کنند و حتی ترافیک ها را به سمت خود هدایت کنند.

می دانیم دربازی STP  مهمترین نقش را Root Bridge  دارد و اگر Attacker  بتواند خود را به عنوان Root Bridge  معرفی کند با قرار دادن پایین ترین Priority  و پایین ترین مقدار Base Mac  یا همان آدرس فیزیکی اینترفیس VLAN 1  و اعلام آن به دیگر سوییچ ها توسط بسته BPDU  می تواند خود را به عنوان Root Bridge  معرفی کند.

ما معمولا سوییچ های لایه Access  را Root Bridge  نمیکنیم و این وظیفه را به سوییچ های لایه Distribution واگذار میکنیم.

مکانیزم هایی که سیسکو در اختیار ما قرار داده تا STP  را امن کنیم Root Guard  ، BPDU Guard  و حتی BPDU Filter  می باشد.

چه لوزمی داره که اینترفیس سوییچ که مستقیم به کلاینت متصل است BPDU  دریافت کند و حتی چرا باید سوییچ روی آن پورت BPDU  ارسال کند؟!

پس بهتر است رو آن اینترفیس ها BPDU Guard  و BPDU Filter  را فعال کرد  با فعال کردن BPDU Guard روی اینترفیس اگر BPDU  دریافت کرد روی آن اینترفیس آن را دور میریزد.

اگر BPDU Guard  را روی اینترفیس های سمت کلاینت فعال کردید دیگر نیازی به فعال کردن Root Guard  روی آن اینترفیس ها را نیست.

معمولا Root Guard  را روی اینترفیس های سمت سوییچ های Access در سوییچ های Distribution فعال میکنند تا اگر سوییچی ادعای Root Bridge  شدن کرد ادعای آن رد شود.

سعی شد در این دو مقاله مباحث اولیه برای ایجاد شبکه امن در LAN را مطرح کنیم و البته مباحث مهمی مانند IP Source Guard  و حتی uRPF  یا Unicast Reverse Path Forwarding  را برای امنیت بیشتر در LAN باید پیاده سازی شوند که حتما در مقاله های بعدی این دو مبحث مهم نیز بررسی میشوند.

با ITNovin همراه باشید.

Leave a Comment