💻 Hypervisor Type 1 vs Type 2

؛ تفاوت ESXi، Hyper-V و VMware Workstation
وقتی صحبت از مجازی‌سازی (Virtualization) می‌شه، یکی از مفاهیم مهمی که باید بشناسیم، Hypervisor هست. هایپروایزر نرم‌افزاریه که امکان اجرای چند ماشین مجازی (VM) رو روی یک سخت‌افزار فیزیکی فراهم می‌کنه. هر ماشین مجازی می‌تونه سیستم‌عامل، منابع پردازشی، حافظه و شبکه مجازی مخصوص خودش رو داشته باشه. هایپروایزرها به دو دسته اصلی Type 1 و Type 2 تقسیم می‌شن که تفاوت اصلی‌شون در نحوه اجرا و ارتباطشون با سخت‌افزار و سیستم‌عامل میزبان هست.

🔹 Hypervisor Type 1 یا Bare Metal
در این مدل، هایپروایزر مستقیماً روی سخت‌افزار فیزیکی نصب می‌شه و برای اجرای ماشین‌های مجازی به یک سیستم‌عامل میزبان عمومی مثل ویندوز یا لینوکس نیاز نداره. به همین دلیل، منابع سخت‌افزاری رو به شکل مستقیم‌تر مدیریت می‌کنه و برای محیط‌های سازمانی، دیتاسنترها و زیرساخت‌های مجازی‌سازی انتخاب مناسبیه.
از مزایای Type 1 می‌شه به مدیریت بهتر منابع، کارایی مناسب، قابلیت توسعه و امکانات پیشرفته مدیریتی اشاره کرد. البته امنیت و عملکرد نهایی فقط به نوع هایپروایزر وابسته نیست و تنظیمات، سخت‌افزار، به‌روزرسانی‌ها و معماری زیرساخت هم نقش مهمی دارن.
نمونه‌های معروف:
🔹 VMware ESXi
🔹 Microsoft Hyper-V در محیط Windows Server
🔹 Hypervisor Type 2 یا Hosted

در این مدل، هایپروایزر به‌صورت یک نرم‌افزار روی سیستم‌عامل میزبان نصب می‌شه. یعنی اول ویندوز یا لینوکس اجرا می‌شه و بعد نرم‌افزار مجازی‌سازی رو باز می‌کنی و ماشین‌های مجازی رو بالا میاری.
این مدل برای یادگیری، آزمایش سیستم‌عامل‌ها، ساخت آزمایشگاه شبکه، تست نرم‌افزارها و اجرای سناریوهای آموزشی خیلی کاربردیه. راه‌اندازی ساده‌تری داره، اما منابعش با سیستم‌عامل میزبان مشترکه و عملکردش می‌تونه تحت تأثیر بار کاری سیستم‌عامل اصلی قرار بگیره.
نمونه معروف:
🔹 VMware Workstation

🔹 تفاوت ESXi، Hyper-V و VMware Workstation

🔸 VMware ESXi: یک هایپروایزر Type 1 هست که مستقیماً روی سخت‌افزار نصب می‌شه و برای ساخت زیرساخت‌های مجازی‌سازی سرورها، دیتاسنترها و محیط‌های سازمانی کاربرد داره.
🔸 Microsoft Hyper-V: فناوری مجازی‌سازی مایکروسافته که در Windows Server و نسخه‌های پشتیبانی‌شده ویندوز در دسترسه. در Windows Server، معماری آن از نوع Type 1 محسوب می‌شه؛ حتی اگر از داخل ویندوز مدیریتش کنی، این موضوع به معنی Hosted بودنش نیست.
🔸 VMware Workstation: یک هایپروایزر Type 2 هست که روی سیستم‌عامل میزبان نصب می‌شه و برای اجرای هم‌زمان چند سیستم‌عامل روی کامپیوتر شخصی یا ساخت لابراتوارهای شبکه و امنیت استفاده می‌شه.

🔹 کدوم رو انتخاب کنیم؟
اگه می‌خوای روی یک سرور فیزیکی چندین ماشین مجازی بسازی و سرویس‌های سازمانی رو اجرا کنی، ESXi یا Hyper-V گزینه‌های مناسبی هستن.
اگه می‌خوای روی کامپیوتر شخصی خودت ویندوز سرور، لینوکس، فایروال مجازی یا سناریوهای شبکه رو آزمایش کنی، VMware Workstation انتخاب هوشمندانه تری هست.
💡 یه نکته مهم: تفاوت Type 1 و Type 2 فقط در سرعت نیست؛ معماری اجرا، مدیریت منابع، نحوه استقرار و کاربرد مورد انتظار هم اهمیت دارن. همچنین هر دو محصول ESXi و Hyper-V قابلیت اجرای ماشین‌های مجازی و مدیریت منابع رو دارن، اما امکانات پیشرفته‌ای مثل مهاجرت زنده، دسترس‌پذیری بالا و مدیریت متمرکز به نسخه، پیکربندی و زیرساخت وابسته هستن.

@ModernLAN

NGFW🔥
چطور ترافیک رو بر اساس Application شناسایی می‌کنه؟

توی فایروال‌های سنتی معمولاً بیشتر با IP، پورت و پروتکل سروکار داریم؛ مثلاً یه قانون می‌نویسیم که ترافیک TCP روی پورت 443 اجازه عبور داشته باشه. ولی مشکل اینجاست که پورت 443 فقط مخصوص یه برنامه نیست و کلی سرویس مثل وب‌سایت‌ها، APIها، سرویس‌های ابری و اپلیکیشن‌های مختلف از HTTPS استفاده می‌کنن. اینجاست که NGFW یا همون Next-Generation Firewall وارد ماجرا می‌شه و سعی می‌کنه بفهمه ترافیکی که داره از شبکه رد می‌شه واقعاً متعلق به چه اپلیکیشنیه، نه اینکه فقط به پورتش نگاه کنه.

حالا NGFW چطور این کار رو انجام می‌ده؟ یکی از روش‌های اصلیش DPI یا Deep Packet Inspection هست؛ یعنی فایروال علاوه بر بررسی اطلاعات اولیه بسته، بخش‌های بیشتری از ترافیک رو هم بررسی می‌کنه تا بتونه پروتکل و اپلیکیشن موردنظر رو تشخیص بده. روش بعدی استفاده از Application Signature هست؛ یعنی فایروال یه سری الگو و نشونه از پروتکل‌ها و رفتار اپلیکیشن‌های مختلف داره و با تطبیق این نشونه‌ها می‌تونه تشخیص بده ترافیک مربوط به چه سرویسیه. برای مثال، ممکنه یه اپلیکیشن از پورتی غیر از پورت معمول خودش استفاده کنه، ولی فایروال با بررسی الگوی ارتباطی و اطلاعات پروتکل همچنان بتونه اون رو شناسایی کنه. البته این تشخیص به نوع اپلیکیشن، نسخه پروتکل و قابلیت‌های خود فایروال بستگی داره.

حالا قضیه وقتی جالب‌تر می‌شه که ترافیک رمزگذاری شده باشه. امروزه بیشتر ارتباطات از HTTPS و TLS استفاده می‌کنن و فایروال دیگه نمی‌تونه به‌راحتی محتوای واقعی ارتباط رو ببینه. با این حال، ممکنه از اطلاعات قابل مشاهده‌ای مثل مشخصات TLS، نام سرور در صورت قابل مشاهده بودن SNI، الگوهای ارتباطی و اطلاعات جریان ترافیک برای شناسایی سرویس استفاده کنه. البته این اطلاعات همیشه برای تشخیص قطعی کافی نیستن؛ مخصوصاً وقتی قابلیت‌هایی مثل ECH فعال باشن یا اپلیکیشن از روش‌های ارتباطی خاصی استفاده کنه. بعضی NGFWها هم قابلیت SSL/TLS Inspection دارن که با تنظیمات مناسب و در چارچوب سیاست امنیتی سازمان، ترافیک رو رمزگشایی و بررسی می‌کنن و بعد دوباره به مسیرش می‌فرستن. این قابلیت محدودیت‌ها و ملاحظات امنیتی و حریم خصوصی خودش رو هم داره.

حالا فرض کنید‌ توی یه شرکت می‌خوای استفاده از یه اپلیکیشن خاص رو محدود کنی، ولی نمی‌خوای کل پورت 443 رو ببندی؛ چون با این کار کلی سرویس ضروری هم از دسترس خارج می‌شن. اینجا می‌تونی روی NGFW قانون Application Control تعریف کنی تا ترافیک اپلیکیشن موردنظر رو شناسایی کنه و بر اساس سیاستی که تنظیم کردی، اجازه عبور بده، مسدودش کنه یا براش محدودیت بذاره. حتی در بعضی محصولات می‌شه اپلیکیشن‌های خاص رو مجاز کرد، دسترسی به سرویس‌های پرریسک رو محدود کرد و برای بعضی ارتباطات هم گزارش‌گیری دقیق‌تری داشت.

پس تفاوت اصلی اینجاست که فایروال سنتی بیشتر می‌پرسه این ترافیک از کجا اومده، به کجا می‌ره و از چه پورتی استفاده می‌کنه؛ ولی NGFW علاوه بر این موارد تلاش می‌کنه بفهمه چه اپلیکیشنی پشت این ارتباط قرار داره. البته NGFW هم جادو نمی‌کنه و تشخیصش به امضاهای موجود، قابلیت‌های محصول، رمزگذاری و اطلاعات قابل مشاهده بستگی داره. به همین دلیل، توی شبکه‌های سازمانی شناسایی اپلیکیشن در کنار کنترل دسترسی، بازرسی ترافیک و مانیتورینگ می‌تونه دید خیلی دقیق‌تری از وضعیت شبکه به تیم امنیت بده.

#NetworkSecurity #NGFW #DPI #ApplicationControl #ModernLAN

@ModernLan

راهنمای جامع دستورات Nmap | از اسکن پورت تا شناسایی سرویس‌ها.

@ModernLan

وقتی صحبت از فایروال، روتر یا تجهیزات امنیتی شبکه می‌شه، یکی از چیزهایی که خیلی وقت‌ها باعث اختلال می‌شه، پر شدن Session Table هست. حالا اصلاً این جدول چیه؟

ببینید، هر بار که یه کاربر وارد سایتی می‌شه، یه برنامه به سرور وصل می‌شه یا یه ارتباط شبکه‌ای شکل می‌گیره، تجهیزاتی مثل فایروال‌های Stateful باید اطلاعات اون ارتباط رو نگه دارن؛ مثلاً IP مبدأ و مقصد، پورت‌ها، پروتکل و وضعیت اتصال. این اطلاعات داخل جدولی به اسم Session Table ذخیره می‌شن تا دستگاه بتونه تشخیص بده هر بسته مربوط به کدوم ارتباطه و باید چطور باهاش برخورد کنه. حالا مشکل از جایی شروع می‌شه که تعداد این ارتباط‌ها بیش از ظرفیت دستگاه بشه.
فرض کنید فایروال شما ظرفیت نگهداری یک میلیون Session رو داره و این ظرفیت کاملاً پر شده؛ توی این شرایط، ممکنه دستگاه دیگه نتونه برای ارتباط‌های جدید Session بسازه و در نتیجه کاربر هرچقدر تلاش کنه سایت جدید باز کنه یا به یه سرویس وصل بشه، با خطا یا Timeout مواجه بشه. نکته جالب اینجاست که ممکنه پهنای باند اینترنت هنوز کاملاً آزاد باشه، ولی شبکه درست کار نکنه؛ چون پهنای باند یه بحثه و تعداد ارتباط‌هایی که فایروال می‌تونه مدیریت کنه یه بحث دیگه.
مثلاً ممکنه لینک اینترنت یک گیگابیت ظرفیت داشته باشه، اما جدول Session فایروال پر شده باشه و اتصال‌های جدید به مشکل بخورن. حالا چی باعث می‌شه این جدول پر بشه؟ یکی از دلایلش تعداد زیاد ارتباط‌های هم‌زمانه؛ مثلاً تعداد زیادی کاربر از برنامه‌های مختلف استفاده می‌کنن یا یه سرویس در مدت کوتاهی هزاران اتصال ایجاد می‌کنه. از طرف دیگه، بعضی حملات مثل SYN Flood هم می‌تونن با ایجاد تعداد زیادی درخواست اتصال، منابع دستگاه رو تحت فشار بذارن؛ البته میزان تأثیرش به تنظیمات و مکانیزم‌های دفاعی تجهیز بستگی داره. حتی تنظیم نبودن Timeout هم می‌تونه مشکل‌ساز بشه، چون بعضی Sessionها بیشتر از زمان لازم توی جدول باقی می‌مونن و منابع رو اشغال می‌کنن. برای عیب‌یابی این وضعیت، نباید فقط به مصرف CPU یا پهنای باند نگاه کرد؛ باید تعداد Sessionهای فعال، ظرفیت کل جدول، نرخ ایجاد اتصال‌های جدید و لاگ‌های فایروال رو هم بررسی کرد.

اگه دیدی تعداد Sessionها مدام بالا میره، باید مشخص کنی کدوم سیستم‌ها یا سرویس‌ها دارن این حجم از اتصال رو ایجاد می‌کنن. در نهایت، پر شدن Session Table لزوماً به معنی قطع شدن تمام ارتباط‌های قبلی نیست؛ توی خیلی از تجهیزات، اتصال‌های موجود ممکنه همچنان کار کنن، اما ارتباط‌های جدید با مشکل مواجه بشن. پس اگه یه روز دیدی اینترنت وصله، پهنای باند هم مشکلی نداره، ولی کاربران نمی‌تونن به سرویس‌های جدید وصل بشن، یکی از چیزهایی که باید بررسی کنی همین ظرفیت Session دستگاهه؛ چون همیشه مشکل شبکه از کمبود پهنای باند نیست، بعضی وقت‌ها تجهیز دیگه ظرفیت مدیریت این همه ارتباط رو نداره.

@ModernLan

وقتی دو Route برای یک مقصد داریم، روتر چطور تصمیم می‌گیره؟

وقتی دو Route برای یک مقصد داریم، روتر چطور تصمیم می‌گیره؟

ببین، فرض کن روترت برای رسیدن به یه شبکه مشخص، مثلاً 192.168.10.0/24، دو تا مسیر مختلف داره. یکی از طریق یه روتر بالادستی و یکی از طریق یه مسیر دیگه. حالا سؤال اینه که روتر از کدوم مسیر استفاده می‌کنه؟ آیا مسیری که سریع‌تره رو انتخاب می‌کنه؟ یا مسیری که فاصله کمتری داره؟ 🤔

جواب اینه که روتر طبق یه سری اولویت مشخص تصمیم می‌گیره و این تصمیم همیشه بر اساس سرعت مسیر نیست.

۱. اول از همه، Longest Prefix Match

روتر اول بررسی می‌کنه کدوم Route دقیق‌تر با IP مقصد مطابقت داره. مثلاً اگه این دو مسیر رو داشته باشیم:

192.168.10.0/24  → Next-Hop A
192.168.10.0/25  → Next-Hop B

اگه بسته به مقصد 192.168.10.50 باشه، مسیر /25 انتخاب می‌شه؛ چون محدوده دقیق‌تری رو پوشش می‌ده. به این رفتار می‌گن Longest Prefix Match. حتی اگه مسیر /24 از نظر پروتکل مسیریابی اولویت بیشتری داشته باشه، باز هم Route دقیق‌تر انتخاب می‌شه.

۲. اگه Prefixها برابر باشن، Administrative Distance مهم می‌شه

فرض کن مقصد در دو Route با Prefix یکسان وجود داره؛ یکی از طریق Static Route و یکی از طریق OSPF. روتر باید تصمیم بگیره کدوم اطلاعات مسیریابی رو برای نصب در جدول Routing انتخاب کنه.

در سیسکو، به‌صورت پیش‌فرض:

Connected  → AD 0
Static     → AD 1
EIGRP      → AD 90
OSPF       → AD 110
RIP        → AD 120

عدد کمتر یعنی اولویت بیشتر بین منابع مختلف مسیریابی. پس اگه Static Route و OSPF Route با Prefix یکسان داشته باشیم، معمولاً Static Route انتخاب می‌شه؛ چون AD اون 1 هست و AD مربوط به OSPF برابر 110 است.

۳. اگه Routeها از یک پروتکل باشن، Metric وارد بازی می‌شه

حالا فرض کن دو مسیر از طریق OSPF به یک مقصد داریم. در این شرایط، OSPF با توجه به Metric خودش، یعنی Cost، مسیر مناسب رو انتخاب می‌کنه. Cost معمولاً بر اساس پهنای باند محاسبه می‌شه؛ البته تنظیمات دستی و جزئیات پیکربندی هم می‌تونن روی اون تأثیر بذارن.

در پروتکل‌های دیگه هم معیار فرق می‌کنه:

* OSPF: Cost

* RIP: تعداد Hop

* EIGRP: معیار ترکیبی که به‌طور پیش‌فرض عمدتاً بر اساس Bandwidth و Delay محاسبه می‌شه.

* BGP: مجموعه‌ای از Attributeها و سیاست‌های مسیریابی، مثل Local Preference و AS-PATH، با ترتیب تصمیم‌گیری مشخص.

پس نمی‌شه گفت همه پروتکل‌ها صرفاً کوتاه‌ترین یا سریع‌ترین مسیر رو انتخاب می‌کنن.

۴. اگه هر دو Route شرایط یکسان داشته باشن چی؟

اینجا ممکنه با قابلیتی به اسم ECMP (Equal-Cost Multi-Path) مواجه بشیم. اگه چند مسیر معتبر با هزینه برابر وجود داشته باشن و روتر و پروتکل اجازه بدن، روتر می‌تونه چند مسیر رو هم‌زمان در جدول Routing نصب کنه و ترافیک رو بین اون‌ها توزیع کنه.

مثلاً:

Destination: 192.168.10.0/24

Path A → Next-Hop 10.0.0.2
Path B → Next-Hop 10.0.0.6

در این حالت، روتر ممکنه بر اساس Hash فیلدهایی مثل IP مبدأ، IP مقصد و پورت‌های TCP/UDP، جریان‌های مختلف رو بین دو مسیر تقسیم کنه. بنابراین لزوماً هر بسته از یک مسیر متفاوت نمی‌ره و نحوه توزیع به پلتفرم و تنظیمات بستگی داره.

یه نکته مهم: اگر دو مسیر Cost متفاوت داشته باشن، در بعضی پروتکل‌ها و با تنظیمات مناسب امکان Load Balancing با هزینه‌های نابرابر هم وجود داره؛ مثلاً در EIGRP با قابلیت variance.

### جمع‌بندی

ترتیب کلی تصمیم‌گیری رو این‌طوری به خاطر بسپار:

* Longest Prefix Match: کدوم مسیر دقیق‌تر به IP مقصد می‌خوره؟

* Administrative Distance: اگر Prefix برابر باشه، کدوم منبع Route اولویت بیشتری داره؟

* Metric و سیاست‌های پروتکل: بین مسیرهای قابل‌مقایسه، کدوم مسیر طبق قواعد همون پروتکل ترجیح داده می‌شه؟

* ECMP: اگر چند مسیر هم‌ارزش قابل نصب باشن، ممکنه روتر از همه‌شون استفاده کنه.

در نهایت، انتخاب Route با ارسال واقعی بسته فرق داره؛ Routing Table مسیر منطقی رو مشخص می‌کنه و بعد جدول Forwarding و سخت‌افزار روتر تعیین می‌کنن بسته عملاً از کدوم خروجی ارسال بشه.

@ModernLan

کیفیت و سرعت اینترنت چطور دستکاری میشه؟

ببینید، وقتی از اینترنت حرف می‌زنیم، خیلی‌ها فکر می‌کنن سرعت اینترنت فقط به پهنای باند و قدرت مودم بستگی داره، ولی داستان خیلی پیچیده‌تر از این حرفاست. ترافیک اینترنت از چندین لایه و تجهیزات مختلف رد می‌شه و توی هر کدوم از این لایه‌ها، بسته به سیاست‌ها و تنظیمات شبکه، می‌شه روی نحوه عبور ترافیک تأثیر گذاشت. یعنی ممکنه اینترنت وصل باشه، سایت‌ها هم باز بشن، ولی وقتی می‌خوای یه فایل دانلود کنی یا ویدئو ببینی، همه‌چی کند و اعصاب‌خردکن بشه.

یکی از روش‌هایی که توی شبکه استفاده می‌شه، DPI یا همون بازرسی عمیق بسته‌هاست. این سیستم می‌تونه بعضی اطلاعات قابل مشاهده ترافیک رو بررسی کنه و از روی پروتکل‌ها، الگوهای اتصال یا اطلاعاتی مثل نام دامنه، تشخیص بده کاربر داره به چه سرویسی وصل می‌شه. بعد هم بسته به قوانینی که براش تعریف شده، ممکنه اجازه عبور بده، اتصال رو مسدود کنه یا روی ترافیک محدودیت اعمال کنه. البته وقتی ارتباط رمزگذاری شده باشه، DPI معمولی نمی‌تونه همین‌طوری محتوای اصلی پیام‌ها رو بخونه؛ ولی بعضی اطلاعات مربوط به برقراری اتصال همچنان ممکنه قابل مشاهده باشن.

روش بعدی Traffic Shaping و Rate Limiting هست. به زبان ساده، یعنی شبکه می‌تونه سرعت عبور بعضی ترافیک‌ها رو کنترل کنه. مثلاً ممکنه برای یه نوع ترافیک سقف سرعت تعیین بشه یا بسته‌ها توی صف منتظر بمونن. این تکنیک‌ها برای مدیریت عادی شبکه هم استفاده می‌شن، ولی اگر به‌صورت انتخابی روی سرویس‌ها یا مقصدهای خاص اعمال بشن، می‌تونن باعث بشن یه سرویس با سرعت معمولی کار کنه و یه سرویس دیگه به‌شدت کند بشه.

یه بخش مهم دیگه هم DNS هست؛ همون سیستمی که اسم سایت رو به آدرس IP تبدیل می‌کنه. حالا تصور کن آدرس یه سایت رو وارد می‌کنی، ولی درخواست DNS درست جواب نمی‌گیره یا آدرس متفاوتی برمی‌گردونه. نتیجه این می‌شه که سایت باز نمی‌شه یا اتصال به مقصد مورد انتظار برقرار نمی‌شه. البته هر جواب متفاوتی هم به معنی دستکاری نیست؛ کش DNS، نوع سرور DNS و شبکه توزیع محتوا هم می‌تونن باعث تفاوت جواب‌ها بشن.

از اون طرف، ماجرا به رمزگذاری HTTPS و پروتکل TLS هم می‌رسه. وقتی به یه سایت امن وصل می‌شی، قبل از انتقال اطلاعات اصلی، مرورگر و سرور باید درباره ارتباط رمزگذاری‌شده به توافق برسن. اگر این مرحله با اختلال مواجه بشه، ممکنه سایت اصلاً باز نشه، با خطای اتصال روبه‌رو بشی یا ارتباط بعد از چند بار تلاش برقرار بشه. توی بعضی شرایط، اطلاعاتی مثل نام دامنه در مرحله شروع اتصال قابل مشاهده‌ان و می‌تونن برای اعمال سیاست‌های شبکه استفاده بشن؛ هرچند فناوری‌هایی مثل ECH می‌تونن بخشی از این اطلاعات رو پنهان کنن.
اما همه‌چی هم فیلترینگ و محدودسازی نیست. گاهی مسئله از مسیریاب‌ها و پروتکل BGP میاد. اینترنت از شبکه‌های مستقل زیادی تشکیل شده و BGP تعیین می‌کنه این شبکه‌ها از چه مسیرهایی به هم برسن. اگر مسیر عوض بشه، یه لینک شلوغ بشه یا ظرفیت ارتباط بین‌المللی کافی نباشه، ممکنه اتصال به یه سرور خارجی کند بشه، در حالی که سرویس‌های داخلی همچنان با سرعت خوبی کار می‌کنن.

یه عامل دیگه هم Packet Loss و تأخیره. وقتی بسته‌های اطلاعاتی گم می‌شن یا دیر به مقصد می‌رسن، پروتکل TCP ممکنه سرعت ارسال داده رو کاهش بده تا ارتباط پایدار بمونه. این اتفاق می‌تونه دانلود رو کند کنه، بازی آنلاین رو با لگ مواجه کنه یا باعث بشه تماس تصویری مرتب قطع و وصل بشه. البته از روی افت سرعت یا چندتا Timeout نمی‌شه نتیجه گرفت که حتماً کسی عمداً بسته‌ها رو حذف کرده؛ ازدحام شبکه، وای‌فای ضعیف و مشکل سرور هم همین علائم رو ایجاد می‌کنن.

حالا سؤال اینه که چطور بفهمیم مشکل از کجاست؟

باید به‌جای اینکه فقط یه تست سرعت بگیریم، چند چیز رو کنار هم بررسی کنیم. مثلاً ببینیم DNS چه جوابی میده، اتصال به پورت ۴۴۳ برقرار می‌شه یا نه، مذاکره TLS چقدر طول می‌کشه، مسیر شبکه چه وضعیتی داره و سرعت دریافت اطلاعات از چند مقصد مختلف چقدره. اگه یه سرویس خاص همیشه مشکل داشته باشه ولی بقیه سرویس‌ها عادی باشن، این خودش یه سرنخه؛ اما برای اثبات محدودسازی عمدی، باید آزمایش‌ها رو چند بار تکرار کنیم و نتایج رو با مسیرها و شرایط متفاوت مقایسه کنیم.
در مورد ایران هم گزارش‌های فنی OONI در سال‌های گذشته مواردی از اختلال در دسترسی به سرویس‌ها و مداخله در بعضی ارتباطات شبکه رو مستند کردن. ولی برای اینکه بفهمیم یه اختلال مشخص الان دقیقاً از کجا میاد، باید داده‌های همون زمان، اپراتور و مقصد رو بررسی کنیم؛ چون هر کندی‌ای لزوماً نشونه دستکاری نیست.

لیست دستورات کاربردی curl

این ابزاری برای ارسال درخواست‌های شبکه‌ای از طریق ترمینال است که از پروتکل‌هایی مثل HTTP، HTTPS و FTP پشتیبانی می‌کند. برای تست API، بررسی هدرها، عیب‌یابی شبکه و دانلود فایل کاربرد دارد.

۱. دستورات پایه

# نمایش نسخه curl
curl --version

# ارسال درخواست GET
curl https://example.com

# نمایش فقط هدرهای پاسخ
curl -I https://example.com

# نمایش هدرها و محتوای پاسخ
curl -i https://example.com

# نمایش جزئیات اتصال و درخواست
curl -v https://example.com

# حالت بی‌صدا
curl -s https://example.com

# نمایش کد وضعیت HTTP
curl -s -o /dev/null -w "%{http_code}\n" https://example.com

# دنبال کردن ریدایرکت‌ها
curl -L https://example.com

۲. دانلود و آپلود فایل

# دانلود فایل
curl -O https://example.com/file.zip

# ذخیره با نام دلخواه
curl -o output.html https://example.com

# ادامه دانلود نیمه‌تمام
curl -C - -O https://example.com/file.zip

# محدود کردن سرعت دانلود
curl --limit-rate 500K -O https://example.com/file.zip

# آپلود فایل با PUT
curl -T file.txt https://example.com/upload

# ارسال فایل در قالب multipart
curl -F "file=@report.txt" https://example.com/upload

### ۳. متدهای HTTP و API

# درخواست GET
curl -X GET https://api.example.com/users

# درخواست POST با JSON
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name":"Ali","role":"admin"}'

# درخواست PUT
curl -X PUT https://api.example.com/users/1 \
  -H "Content-Type: application/json" \
  -d '{"name":"Ali"}'

# درخواست PATCH
curl -X PATCH https://api.example.com/users/1 \
  -H "Content-Type: application/json" \
  -d '{"name":"NewName"}'

# درخواست DELETE
curl -X DELETE https://api.example.com/users/1

# ارسال داده‌های فرم
curl -X POST https://example.com/login \
  -d "username=ali&password=test"

# ارسال هدر سفارشی
curl https://api.example.com/data \
  -H "X-API-Key: YOUR_API_KEY"

### ۴. هدرها، کوکی‌ها و احراز هویت

# مشاهده هدرهای پاسخ
curl -sS -D - -o /dev/null https://example.com

# ارسال User-Agent دلخواه
curl -A "Mozilla/5.0" https://example.com

# ارسال کوکی
curl -b "session=YOUR_SESSION" https://example.com

# ذخیره کوکی‌ها
curl -c cookies.txt https://example.com

# استفاده از کوکی ذخیره‌شده
curl -b cookies.txt https://example.com

# احراز هویت Basic
curl -u username:password https://example.com

# ارسال Bearer Token
curl -H "Authorization: Bearer YOUR_TOKEN" \
  https://api.example.com/profile

# تنظیم Referer
curl -e "https://example.com/" https://example.com/page

### ۵. پروکسی و شبکه

# اتصال از طریق HTTP Proxy
curl -x http://127.0.0.1:8080 https://example.com

# اتصال از طریق SOCKS5
curl --proxy socks5h://127.0.0.1:9050 https://example.com

# استفاده از پروکسی همراه احراز هویت
curl -x http://127.0.0.1:8080 \
  -U username:password https://example.com

# اجبار به استفاده از IPv4
curl -4 https://example.com

# اجبار به استفاده از IPv6
curl -6 https://example.com

# تعیین پورت اتصال
curl --connect-to example.com:443:127.0.0.1:8443 \
  https://example.com

# تعیین زمان پایان کل درخواست
curl --max-time 15 https://example.com

# تعیین مهلت برقراری اتصال
curl --connect-timeout 5 https://example.com

# نمایش زمان‌های اتصال و پاسخ
curl -sS -o /dev/null \
  -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTotal: %{time_total}s\n" \
  https://example.com

@ModernLan

💥حملات DDoS در لایه‌های مختلف شبکه؛ از TCP Flood تا HTTP Flood

حمله DDoS فقط این نیست که یه عالمه درخواست به یه سرور بفرستن و سرور از دسترس خارج بشه. بسته به اینکه حمله کدوم بخش شبکه رو هدف بگیره، روش اجرا و نحوه مقابله باهاش کاملاً فرق می‌کنه.

🔹 لایه ۳ | Network Layer

اینجا هدف اصلی زیرساخت IP و ظرفیت شبکه‌ست. حملاتی مثل ICMP Flood و بعضی حملات مبتنی بر IP می‌تونن باعث اشباع لینک، افزایش Packet Loss و اختلال در ارتباطات بشن. اگه پهنای باند ورودی شبکه پر بشه، حتی سرور سالم هم ممکنه برای کاربران از دسترس خارج بشه.

🔹 لایه ۴ | Transport Layer

اینجا پای پروتکل‌های TCP و UDP وسطه. در SYN Flood مهاجم سعی می‌کنه منابع مربوط به اتصال‌های نیمه‌باز رو درگیر کنه؛ در UDP Flood هم حجم بالای بسته‌ها می‌تونه ظرفیت شبکه یا تجهیزات پردازشی رو اشباع کنه. حملات Reflection و Amplification هم با سوءاستفاده از سرویس‌های واسط، حجم بیشتری از ترافیک رو به سمت قربانی هدایت می‌کنن.

🔹 لایه ۷ | Application Layer

این بخش داستان جالب‌تری داره؛ چون ممکنه ترافیک حمله از نظر ظاهری شبیه ترافیک واقعی کاربران باشه. حملاتی مثل HTTP Flood با فرستادن درخواست‌های زیاد به سایت یا API، منابع CPU، حافظه و دیتابیس رو درگیر می‌کنن. حتی ممکنه پهنای باند کاملاً عادی باشه، اما سرور به‌خاطر پردازش درخواست‌های سنگین از کار بیفته.

🔹 لایه ۲ | Data Link Layer

در شبکه‌های محلی هم حملات و اختلالاتی مثل MAC Flooding وجود دارن که می‌تونن جدول آدرس‌های MAC سوئیچ رو تحت فشار قرار بدن. این مورد لزوماً یک حمله DDoS توزیع‌شده نیست، اما نشون می‌ده اختلال در شبکه فقط محدود به اینترنت و سرورها نیست.

🔹 حملات DNS و NTP Amplification

در حملات تقویتی، مهاجم از سرویس‌هایی استفاده می‌کنه که پاسخ اون‌ها می‌تونه از درخواست اولیه بزرگ‌تر باشه. اگر مبدأ درخواست جعل شده باشه و پاسخ به سمت قربانی هدایت بشه، حجم زیادی از ترافیک ناخواسته به زیرساخت هدف می‌رسه. به همین دلیل، جلوگیری از جعل آدرس IP و محدودسازی پاسخ‌های سوءاستفاده‌پذیر اهمیت زیادی داره.

🛡 چطور با DDoS مقابله کنیم؟

برای حملات حجمی، ظرفیت شبکه، فیلترینگ بالادستی و سرویس‌های Anti-DDoS اهمیت دارن. برای حملات TCP باید تنظیمات سیستم‌عامل، فایروال و مدیریت اتصال‌ها بررسی بشه. در لایه ۷ هم Rate Limiting، محدودسازی درخواست‌های مشکوک، CDN، WAF و مانیتورینگ منابع برنامه نقش مهمی دارن.

نکته مهم اینه که فایروال به‌تنهایی همیشه کافی نیست؛ چون اگر لینک اینترنت قبل از رسیدن ترافیک به فایروال اشباع بشه، باید مقابله در سطح ISP یا شبکه بالادستی انجام بشه.

@ModernLan

📡 حملات Deauthentication در وای‌فای؛ چطور مهاجم کاربران رو از شبکه قطع می‌کنه؟

یکی از حملات جالب توی امنیت شبکه‌های وایرلس، حمله‌ی Wi-Fi Deauthentication هست. توی این حمله، مهاجم می‌تونه با ارسال فریم‌های مدیریتی جعلی، باعث قطع ارتباط دستگاه‌های متصل به یک شبکه وای‌فای بشه؛ یعنی گوشی یا لپ‌تاپت به وای‌فای وصله، ولی ناگهان اتصالش قطع می‌شه و ممکنه چند ثانیه بعد دوباره وصل بشه.

اما این اتفاق چطور می‌افته؟ 🤔

در استاندارد IEEE 802.11، علاوه بر فریم‌های مربوط به انتقال داده، فریم‌هایی هم برای مدیریت ارتباط بین کلاینت و اکسس‌پوینت وجود دارن. یکی از این فریم‌ها، Deauthentication Frame هست که برای پایان دادن به وضعیت احراز هویت دستگاه استفاده می‌شه.
مشکل از جایی شروع می‌شه که در شبکه‌های فاقد محافظت مناسب، مهاجم بتونه فریم‌های جعلی‌ای ارسال کنه که دستگاه اون‌ها رو معتبر تشخیص بده. در این حالت، کلاینت ممکنه ارتباطش رو قطع کنه و مجبور بشه دوباره به شبکه متصل بشه.

🎯 این حمله چه کاربردی برای مهاجم داره؟
🔹 ایجاد اختلال در اتصال کاربران به وای‌فای (DoS)
🔹 قطع‌ و وصل مکرر ارتباط گوشی‌ها و لپ‌تاپ‌ها
🔹 فراهم کردن شرایطی برای بررسی یا اجرای حملات دیگر در بعضی سناریوها
🔹 آزمایش امنیت شبکه‌های وایرلس در محیط آزمایشگاهی
نکته مهم اینه که حمله Deauthentication به‌تنهایی رمز وای‌فای رو به دست نمیاره؛ اما می‌تونه دسترسی کاربران به شبکه رو مختل کنه. همچنین این حمله به معنی شنود موفق یا سرقت اطلاعات نیست.

🛡 چطور از شبکه در برابر این حمله محافظت کنیم؟
مهم‌ترین راهکار، استفاده از قابلیت Protected Management Frames (PMF) هست که با استانداردهای IEEE 802.11w و قابلیت‌های امنیتی WPA3 ارتباط داره. این قابلیت می‌تونه از فریم‌های مدیریتی حیاتی در برابر جعل و دست‌کاری محافظت کنه.
✅ فعال کردن WPA3 در صورت پشتیبانی تجهیزات
✅ فعال کردن PMF یا 802.11w و ترجیحاً قرار دادن آن روی حالت Required در شبکه‌های سازگار
✅ به‌روزرسانی Firmware روتر و اکسس‌پوینت
✅ بررسی لاگ‌ها و شناسایی قطع و وصل‌های غیرعادی کلاینت‌ها
✅ انجام تست‌های امنیتی فقط روی شبکه‌ای که مالک اون هستیم یا مجوز تستش رو داریم
💡 نکته امنیتی: اگر وای‌فای مرتب قطع می‌شه، لزوماً به معنی حمله Deauthentication نیست؛ تداخل فرکانسی، ضعف سیگنال، مشکلات DHCP و ایرادات Firmware هم می‌تونن چنین رفتاری ایجاد کنن.

@ModernLAN

مفهوم Banner Grabbing در شناسایی سرویس‌ها

توی امنیت شبکه وقتی می‌خوای یه سرور رو بررسی کنی، فقط فهمیدن IP اون سرور کافی نیست. باید بدونی چه سرویس‌هایی روش اجرا می‌شن، از چه نرم‌افزاری استفاده می‌کنن و گاهی حتی نسخه اون نرم‌افزار چیه. اینجا دقیقاً همون جاییه که Banner Grabbing وارد بازی میشه.

فرض کن یک سرور داری که پورت‌های 22، 80 و 443 اون باز هستن. صرفاً باز بودن این پورت‌ها بهت نمی‌گه دقیقاً چه نرم‌افزاری پشتشون قرار داره.
* پورت 22 معمولاً برای SSH استفاده می‌شه.
* پورت 80 معمولاً برای HTTP هست.
* پورت 443 معمولاً برای HTTPS هست.

حالا با Banner Grabbing سعی می‌کنی اطلاعات بیشتری از سرویس‌های در حال اجرا به دست بیاری.
برای مثال، وقتی به یک سرویس SSH متصل می‌شی، ممکنه چنین پاسخی دریافت کنی:

SSH-2.0-OpenSSH_9.6

این پاسخ بهت می‌گه که سرویس از پروتکل SSH نسخه 2 استفاده می‌کنه و خودش رو به‌عنوان OpenSSH نسخه 9.6 معرفی می‌کنه.

البته این اطلاعات لزوماً تضمین نمی‌کنن که نسخه واقعی نرم‌افزار دقیقاً همینه؛ ممکنه Banner تغییر داده شده باشه یا سیستم از وصله‌های امنیتی خاصی استفاده کنه.

روش‌های انجام Banner Grabbing

۱. با ابزار Netcat

برای بررسی یک سرویس SSH روی سروری که مجاز به تستش هستی:

nc -nv 192.168.1.10 22

اگر سرویس اطلاعات خودش رو هنگام اتصال ارسال کنه، ممکنه Banner مربوط به SSH رو ببینی.

برای بررسی یک وب‌سرور هم می‌تونی درخواست HTTP بفرستی:

printf 'HEAD / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n' | nc example.com 80

ممکنه پاسخی شبیه این دریافت کنی:

HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html

در این مثال، هدر Server اطلاعاتی درباره نرم‌افزار وب‌سرور ارائه می‌ده؛ البته ممکنه این هدر حذف یا دستکاری شده باشه.

۲. با ابزار Nmap

یکی از ابزارهای کاربردی برای شناسایی سرویس‌ها، Nmap هست.

nmap -sV 192.168.1.10

پارامتر -sV تلاش می‌کنه سرویس‌های روی پورت‌های شناسایی‌شده رو تشخیص بده و نسخه احتمالی اون‌ها رو مشخص کنه.

مثلاً خروجی ممکنه چنین چیزی باشه:

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6
80/tcp open  http    nginx 1.24.0

این خروجی نمونه است و نسخه‌های نمایش‌داده‌شده الزاماً با نسخه واقعی هیچ سروری مطابقت ندارن.

۳. با ابزار Curl

برای مشاهده هدرهای HTTP:

curl -I http://example.com

یا برای مشاهده هدرهای پاسخ HTTPS:

curl -I https://example.com

به این ترتیب می‌تونی هدرهایی مثل Server و X-Powered-By رو بررسی کنی؛ البته وجود این هدرها به تنظیمات سرور بستگی داره.

چرا Banner Grabbing برای امنیت سایبری مهمه؟

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

اما یک نکته مهم: شناسایی نسخه، به معنی اثبات وجود آسیب‌پذیری نیست. برای ارزیابی دقیق باید وضعیت وصله‌های امنیتی، پیکربندی و شرایط واقعی سرویس هم بررسی بشه.

برای کاهش افشای اطلاعات هم می‌شه هدرهای غیرضروری رو حذف کرد، Banner سرویس‌ها رو محدود کرد و نرم‌افزارها رو به‌روز نگه داشت؛ هرچند مخفی کردن نسخه به‌تنهایی جایگزین به‌روزرسانی امنیتی نیست.
@ModernLan

🚀 QUIC و HTTP/3؛ چطور اینترنت رو سریع‌تر و هوشمندتر کردن؟
تا حالا شده اینترنتت سرعت خوبی داشته باشه، ولی سایت‌ها بازم دیر باز بشن؟ 🤔

یکی از دلایلش می‌تونه نحوه برقراری ارتباط بین مرورگر و سرور باشه. اینجاست که دو فناوری مهم وارد می‌شن: QUIC و HTTP/3
🔹 HTTP/1.1؛ روش قدیمی‌تر
ارتباط وب عمدتاً روی TCP انجام می‌شه و مدیریت تعداد زیادی درخواست می‌تونه سربار ایجاد کنه.

🔹 HTTP/2؛ چند درخواست، یک اتصال
HTTP/2
با قابلیتی به اسم Multiplexing اجازه می‌ده چند درخواست هم‌زمان روی یک اتصال TCP منتقل بشن؛ اما گم‌شدن یک بسته TCP می‌تونه تحویل داده‌های چند جریان رو به تأخیر بندازه.

🔹 HTTP/3؛ نسل جدید ارتباط وب
HTTP/3
به‌جای TCP از QUIC روی UDP استفاده می‌کنه. این یعنی تغییر اساسی در نحوه انتقال داده‌ها، نه صرفاً تغییر نسخه HTTP.

🔥 QUIC چه مزایایی داره؟
✅ اتصال سریع‌تر: ادغام فرایندهای برقراری اتصال و رمزنگاری، تأخیر شروع ارتباط رو کاهش میده.
✅ جریان‌های مستقل: اگه بسته‌ای از یک جریان گم بشه، لزوماً جریان‌های دیگه متوقف نمی‌شن؛ البته داده‌های بعدی همان جریان ممکنه منتظر بمونن.
✅ رمزنگاری داخلی: امنیت و محرمانگی ارتباط بخشی از طراحی QUIC هست و برای استفاده معمول از HTTP/3، ارتباط رمزنگاری‌شده لازمه.
✅ عملکرد بهتر در شبکه‌های ناپایدار: QUIC می‌تونه هنگام تغییر شبکه، مثل جابه‌جایی بین Wi-Fi و اینترنت موبایل، در شرایط مناسب اتصال رو حفظ کنه.
✅ کاهش تأخیر: به‌خصوص در اتصال‌های جدید، شبکه‌های پرتأخیر و شرایطی که بسته‌ها گم می‌شن، ممکنه تفاوت محسوسی ایجاد کنه.
🛡 از دید امنیت شبکه چه اهمیتی داره؟
چون HTTP/3 روی QUIC اجرا می‌شه، بخش زیادی از اطلاعات پروتکل در لایه انتقال رمزنگاری می‌شه. در نتیجه، تجهیزات شبکه نمی‌تونن مثل بعضی ارتباطات HTTP قدیمی، محتوای درخواست‌ها رو مستقیماً مشاهده کنن.
البته این به معنی نامرئی‌شدن کامل ترافیک نیست؛ آدرس‌های IP، حجم و زمان‌بندی ترافیک و برخی اطلاعات اتصال همچنان ممکنه قابل مشاهده باشن. همچنین فایروال‌ها و ابزارهای مانیتورینگ باید برای تحلیل QUIC و UDP سازگار باشن.
⚠️ یه نکته مهم: HTTP/3 همیشه سریع‌تر نیست. نتیجه به کیفیت شبکه، تأخیر، میزان Packet Loss، پیاده‌سازی سرور و کلاینت و شرایط اتصال بستگی داره.
💡 جمع‌بندی:
HTTP/2
انتقال وب رو با Multiplexing بهبود داد؛ QUIC با کاهش وابستگی به TCP، مدیریت مستقل جریان‌ها و راه‌اندازی سریع‌تر اتصال، زمینه HTTP/3 رو فراهم کرد.
📌 اینترنت فقط سرعت دانلود نیست؛ گاهی مهم‌ترین تفاوت، اینه که ارتباط چقدر سریع شروع می‌شه و در شرایط نامناسب چقدر خوب ادامه پیدا می‌کنه.

#شبکه #امنیت_شبکه #HTTP3 #QUIC #TCP #UDP #CyberSecurity #Networking

@ModernLan

🔥 دستورات کاربردی SQLmap برای تست امنیت SQL Injection

ابزار sqlmap یکی از ابزارهای معروف تست نفوذ وب است که برای شناسایی و بررسی آسیب‌پذیری SQL Injection در برنامه‌های تحت وب استفاده می‌شود.

این دستورات برای تست روی سایت یا محیط آزمایشگاهی خودت و سیستم‌هایی هستند که مجوز تست آن‌ها را داری.

1. نصب و اجرای اولیه

# نصب در کالی لینوکس
sudo apt update
sudo apt install sqlmap

# مشاهده نسخه
sqlmap --version

# مشاهده راهنما
sqlmap -hh

2. دستورات پایه

# بررسی یک URL دارای پارامتر
sqlmap -u "http://test.local/item.php?id=1"

# افزایش سطح جزئیات خروجی
sqlmap -u "http://test.local/item.php?id=1" -v 3

# بررسی پارامتر مشخص
sqlmap -u "http://test.local/item.php?id=1" -p id

# بررسی سطح و نوع تست
sqlmap -u "http://test.local/item.php?id=1" --level=3 --risk=1

# ذخیره خروجی در مسیر مشخص
sqlmap -u "http://test.local/item.php?id=1" -o

3. شناسایی دیتابیس

# تشخیص نوع دیتابیس
sqlmap -u "http://test.local/item.php?id=1" --banner

# بررسی دیتابیس فعلی
sqlmap -u "http://test.local/item.php?id=1" --current-db

# بررسی کاربر فعلی دیتابیس
sqlmap -u "http://test.local/item.php?id=1" --current-user

# بررسی سطح دسترسی کاربر دیتابیس
sqlmap -u "http://test.local/item.php?id=1" --is-dba

# شناسایی قابلیت‌های دیتابیس
sqlmap -u "http://test.local/item.php?id=1" --fingerprint

4. تست درخواست‌های POST و کوکی

# تست پارامتر POST
sqlmap -u "http://test.local/login.php" \
  --data="username=test&password=test"

# ارسال کوکی آزمایشی
sqlmap -u "http://test.local/item.php?id=1" \
  --cookie="session=YOUR_TEST_SESSION"

# استفاده از درخواست ذخیره‌شده در فایل
sqlmap -r request.txt

# تعیین پارامتر برای تست در درخواست ذخیره‌شده
sqlmap -r request.txt -p id

برای استفاده از -r می‌توانی درخواست HTTP مجاز و آزمایشی را در فایلی به نام request.txt ذخیره کنی.

5. تنظیم نوع تست

# فقط تست‌های مبتنی بر Boolean
sqlmap -u "http://test.local/item.php?id=1" --technique=B

# تست Boolean و Error-based
sqlmap -u "http://test.local/item.php?id=1" --technique=BE

# تست با سطح جزئیات بالاتر
sqlmap -u "http://test.local/item.php?id=1" --level=5 --risk=1

# تعیین زمان انتظار برای پاسخ
sqlmap -u "http://test.local/item.php?id=1" --timeout=10

@ModernLan

🔐 تفاوت Pass-the-Hash و Pass-the-Ticket چیه؟

توی شبکه‌های ویندوزی برای اینکه یه کاربر احراز هویت بشه، همیشه لازم نیست رمز عبورش مستقیم وارد بشه. بعضی وقت‌ها مهاجم می‌تونه از اطلاعات احراز هویتی که به دست آورده سوءاستفاده کنه و خودش رو جای کاربر جا بزنه. دو تا از تکنیک‌های معروف توی این زمینه Pass-the-Hash و Pass-the-Ticket هستن.

توی Pass-the-Hash یا همون PtH، مهاجم به‌جای اینکه رمز عبور واقعی کاربر رو داشته باشه، از هش NTLM اون استفاده می‌کنه. یعنی اگه هش به دستش رسیده باشه، توی شرایط مناسب می‌تونه بدون اینکه رمز اصلی رو بدونه، ازش برای احراز هویت استفاده کنه. پس اینجا چیزی که اهمیت داره هش رمز عبوره، نه خود رمز.

اما توی Pass-the-Ticket یا PtT داستان فرق می‌کنه. اینجا مهاجم سراغ بلیت‌های Kerberos میره که برای احراز هویت توی شبکه‌های ویندوزی، مخصوصاً محیط‌های Active Directory، استفاده می‌شن. اگه مهاجم بتونه یه بلیت معتبر رو به دست بیاره، بسته به نوع بلیت و دسترسی‌های مربوط به اون، ممکنه بتونه بدون وارد کردن رمز عبور، از هویت کاربر سوءاستفاده کنه.

حالا تفاوت اصلی این دوتا چیه؟
توی Pass-the-Hash با هش NTLM سروکار داریم، ولی توی Pass-the-Ticket با بلیت Kerberos. هر دو می‌تونن به مهاجم کمک کنن بدون دونستن رمز عبور اصلی به منابع شبکه دسترسی پیدا کنه، اما سازوکارشون متفاوته و نباید این‌طور تصور کنیم که هر هش یا هر بلیتی به‌تنهایی دسترسی ادمین می‌ده.

برای مقابله با این تکنیک‌ها هم باید دسترسی به اعتبارنامه‌ها رو محدود کرد، حساب‌های ادمین رو درست مدیریت کرد، در صورت امکان استفاده از NTLM رو کاهش داد، از قابلیت‌هایی مثل Credential Guard استفاده کرد و لاگ‌های احراز هویت ویندوز رو برای رفتارهای مشکوک بررسی کرد.

خلاصه بخوام بگم براتون، توی Pass-the-Hash مهاجم با هش رمز عبور کار می‌کنه، ولی توی Pass-the-Ticket با بلیت احراز هویت Kerberos. هدف هر دو سوءاستفاده از هویت کاربره، اما راهی که میرن با هم فرق داره. 🔥

#CyberSecurity #Windows #ActiveDirectory #NTLM #Kerberos #PassTheHash #PassTheTicket #امنیت_شبکه


@ModernLan