🔴 NTLM Relay؛ چطور میشه از احراز هویت ویندوز علیه خودش استفاده کرد؟

یکی از حملات جالب توی شبکه‌های ویندوزی و Active Directory، حمله NTLM Relay هست. نکته جالبش اینه که مهاجم برای انجام این حمله لزوماً نیازی به دونستن رمز عبور قربانی یا استخراج هش پسوردش نداره؛ بلکه می‌تونه از فرایند احراز هویت خود کاربر سوءاستفاده کنه!

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

حالا چرا این حمله خطرناکه؟ چون اگه سرویس مقصد در برابر Relay محافظت نشده باشه و حساب قربانی هم دسترسی مناسبی داشته باشه، مهاجم ممکنه بتونه به فایل‌های اشتراکی، سرویس‌های داخلی یا حتی بعضی امکانات مدیریتی دسترسی پیدا کنه. البته این به معنی دسترسی خودکار به کل شبکه یا Domain Admin شدن نیست و همه‌چیز به سطح دسترسی کاربر و تنظیمات امنیتی شبکه بستگی داره.

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

برای مقابله با این حمله، مدیر شبکه باید سراغ راهکارهایی مثل فعال‌سازی SMB Signing، استفاده از Extended Protection for Authentication یا EPA، محدود کردن NTLM در صورت امکان و بررسی لاگ‌های احراز هویت بره. در کنار این‌ها، محدود کردن دسترسی حساب‌های کاربری و جلوگیری از استفاده روزمره از حساب‌های ادمین هم اهمیت زیادی داره.

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

#CyberSecurity #NTLM #ActiveDirectory #WindowsSecurity #NetworkSecurity

@ModernLan

🔐 RADIUS vs TACACS+
؛ تفاوت در احراز هویت و مدیریت دسترسی تجهیزات شبکه

وقتی تعداد تجهیزات شبکه زیاد می‌شه، دیگه نمی‌تونیم برای هر سوئیچ، روتر یا فایروال یه سری یوزر و پسورد جداگانه تعریف کنیم و انتظار داشته باشیم مدیریت دسترسی‌ها هم راحت و امن باقی بمونه. اینجاست که پروتکل‌های AAA وارد ماجرا می‌شن؛ یعنی Authentication برای احراز هویت، Authorization برای تعیین سطح دسترسی و Accounting برای ثبت فعالیت‌ها. دو تا از پروتکل‌های مهمی که توی این حوزه استفاده می‌شن RADIUS و TACACS+ هستن، اما با اینکه هر دو برای مدیریت متمرکز دسترسی کاربرد دارن، دقیقاً یکسان نیستن.

🔹 RADIUS چیه؟
پروتکل RADIUS مخفف Remote Authentication Dial-In User Service هست و برای احراز هویت کاربران و مدیریت دسترسی اون‌ها به شبکه استفاده می‌شه. مثلاً فرض کن توی یه سازمان چندین اکسس‌پوینت وایرلس داری و می‌خوای فقط کاربرهایی که اطلاعات معتبر دارن بتونن به شبکه وصل بشن. به‌جای اینکه روی تک‌تک تجهیزات اطلاعات کاربران رو تعریف کنی، درخواست احراز هویت به یک سرور مرکزی RADIUS ارسال می‌شه. سرور اطلاعات کاربر رو بررسی می‌کنه و بر اساس سیاست‌های تعریف‌شده، اجازه دسترسی می‌ده یا درخواست رو رد می‌کنه. این مدل برای شبکه‌های Wi-Fi سازمانی، دسترسی کابلی مبتنی بر 802.1X، VPN و سناریوهای دسترسی متمرکز کاربرد زیادی داره.

🔹 TACACS+ چیه؟

TACACS+
مخفف Terminal Access Controller Access-Control System Plus هست و بیشتر برای مدیریت متمرکز دسترسی ادمین‌ها به تجهیزات زیرساختی مثل روترها، سوئیچ‌ها و فایروال‌ها استفاده می‌شه. فرض کن چندین ادمین به تجهیزات سیسکو دسترسی دارن، اما نمی‌خوای همه بتونن تمام دستورات رو اجرا کنن. با TACACS+ می‌تونی مشخص کنی چه کسی اجازه ورود به دستگاه رو داره، چه سطح دسترسی‌ای دریافت می‌کنه و چه دستوراتی رو می‌تونه اجرا کنه. مثلاً یک ادمین فقط اجازه مشاهده تنظیمات رو داشته باشه، ولی ادمین ارشد بتونه تنظیمات رو تغییر بده. البته اجرای دقیق این سیاست‌ها به قابلیت تجهیزات و نحوه پیکربندی AAA بستگی داره.

🔸 تفاوت فنی RADIUS و TACACS+

مهم‌ترین تفاوت این دو پروتکل در نحوه تفکیک وظایف AAA و مدل حفاظت از اطلاعاته. RADIUS به‌صورت استاندارد از UDP استفاده می‌کنه و پورت‌های رایجش 1812 برای Authentication و Authorization و 1813 برای Accounting هستن. در مقابل، TACACS+ از TCP استفاده می‌کنه و معمولاً روی پورت 49 ارتباط برقرار می‌کنه.

در RADIUS، اطلاعات رمز عبور کاربر در روش کلاسیک پروتکل به شکل مشخصی محافظت می‌شه، اما تمام محتوای پیام‌ها رمزنگاری نمی‌شه. در TACACS+، محتوای بدنه پیام‌ها به‌صورت رمزنگاری‌شده منتقل می‌شه، هرچند این سازوکار رو نباید با رمزنگاری سرتاسری مدرن اشتباه گرفت.

از طرف دیگه، RADIUS در معماری کلاسیک خودش Authentication و Authorization رو در یک تبادل پروتکلی ترکیب می‌کنه، در حالی که TACACS+ این دو رو به‌صورت مستقل‌تری مدیریت می‌کنه. همین ویژگی باعث می‌شه TACACS+ برای کنترل دقیق دستورات مدیریتی تجهیزات شبکه انتخاب مناسبی باشه.

🔹 مقایسه کاربردی
▪️ RADIUS: مناسب برای احراز هویت کاربران شبکه، وایرلس سازمانی، 802.1X و VPN.
▪️ TACACS+: مناسب برای مدیریت دسترسی ادمین‌ها به تجهیزات شبکه و کنترل اجرای دستورات مدیریتی.
▪️ RADIUS: معمولاً از UDP استفاده می‌کنه؛ پورت‌های رایج 1812 و 1813.
▪️ TACACS+: از TCP استفاده می‌کنه؛ پورت رایج 49.
▪️ RADIUS: در روش کلاسیک، حفاظت از فیلد رمز عبور با رمزنگاری کل پیام تفاوت داره.
▪️ TACACS+: بدنه پیام‌ها رو رمزنگاری می‌کنه و امکان تفکیک بهتر Authentication، Authorization و Accounting رو فراهم می‌کنه.
▪️ RADIUS: در بسیاری از زیرساخت‌های سازمانی برای کنترل دسترسی کاربران به شبکه استفاده می‌شه.
▪️ TACACS+: در بسیاری از محیط‌های مدیریتی سیسکو برای کنترل دسترسی ادمین‌ها و ثبت دستورات اجراشده استفاده می‌شه.
یه سناریوی واقعی
فرض کن یه سازمان ۵۰ تا سوئیچ سیسکو، ۱۰ تا روتر و چندین اکسس‌پوینت داره. کاربران برای اتصال به وای‌فای سازمانی باید با اطلاعات معتبر احراز هویت بشن و ادمین‌ها هم باید بتونن تجهیزات رو مدیریت کنن.
اینجا می‌تونی از RADIUS برای احراز هویت کاربران وایرلس و دسترسی مبتنی بر 802.1X استفاده کنی و TACACS+ رو برای مدیریت متمرکز دسترسی ادمین‌ها به تجهیزات شبکه در نظر بگیری. در نتیجه، مدیریت حساب‌ها متمرکزتر می‌شه، دسترسی‌ها بر اساس نقش افراد کنترل می‌شن و بررسی فعالیت‌های مدیریتی هم ساده‌تر خواهد بود.

🔴 چرا ترافیک سرور از Interface اشتباه خارج می‌شه؟

فرض کن یه سرور ویندوزی یا لینوکسی داری که دو یا چند تا کارت شبکه روش نصبه. مثلاً کارت شبکه اول به شبکه داخلی وصله و کارت شبکه دوم به اینترنت. همه‌چیز ظاهراً درسته، IPها تنظیم شدن، Gateway هم داری، اما وقتی سرور می‌خواد به یه مقصد مشخص وصل بشه، ترافیک از کارت شبکه‌ای خارج می‌شه که اصلاً انتظارش رو نداری! اینجا اولین چیزی که به ذهن می‌رسه Routing Metric هست، ولی ماجرا همیشه به همین سادگی نیست.
1️⃣ Routing Metric؛ اولویت مسیرها
هر Route یه Metric داره که برای انتخاب بین مسیرهای قابل‌استفاده، یکی از معیارهای مهم محسوب می‌شه. معمولاً مسیر با Metric پایین‌تر ترجیح داده می‌شه، البته به شرطی که مقصد و Prefix مسیرها شرایط مقایسه مناسبی داشته باشن. در ویندوز، Interface Metric هم می‌تونه در محاسبه اولویت مسیرها نقش داشته باشه.
مثلاً فرض کن دو کارت شبکه داری و هر دو به Default Gateway دسترسی دارن. اگر Routeهای پیش‌فرض از نظر اولویت قابل‌مقایسه باشن، ممکنه ویندوز مسیری رو انتخاب کنه که از نظر تو اشتباهه، ولی از دید Routing Table اولویت بیشتری داره.
2️⃣ وجود چند Default Gateway
یکی از اشتباهات رایج، تنظیم Default Gateway روی چند کارت شبکه بدون نیاز مشخصه. وقتی چند مسیر پیش‌فرض وجود داشته باشه، سیستم‌عامل باید بر اساس Routeها و Metric تصمیم بگیره ترافیک مقصدهایی رو که Route اختصاصی ندارن از کدوم مسیر بفرسته.
البته چند Default Gateway همیشه اشتباه نیست؛ در بعضی طراحی‌ها استفاده از چند مسیر پیش‌فرض کاملاً منطقیه. مسئله اینه که مسیرها باید مطابق طراحی شبکه تنظیم شده باشن.
3️⃣ Routing Table؛ چیزی که واقعاً باید بررسی کنی
قبل از تغییر Metric، باید ببینی سیستم‌عامل در حال حاضر چه مسیرهایی رو می‌شناسه. ممکنه یه Route اختصاصی برای مقصد موردنظر وجود داشته باشه که از Default Route اولویت بیشتری داشته باشه.
در ویندوز:

route print

برای مشاهده مسیرهای IPv4:

Get-NetRoute -AddressFamily IPv4

برای بررسی Metric کارت‌های شبکه:

Get-NetIPInterface -AddressFamily IPv4

در لینوکس هم می‌تونی از این دستورات استفاده کنی:

ip route
ip rule
ip route get 8.8.8.8

دستور آخر نشون می‌ده سیستم لینوکسی برای رسیدن به مقصد 8.8.8.8 از چه مسیری استفاده می‌کنه و معمولاً کدوم Interface و Source IP رو انتخاب می‌کنه.
4️⃣ Source IP و Multi-Homing
گاهی مشکل فقط انتخاب کارت شبکه نیست، بلکه آدرس IP مبدأ هم اشتباه انتخاب می‌شه. فرض کن سرور دو کارت شبکه داره و هرکدوم IP متفاوتی دارن. برنامه‌ای که روی سرور اجرا می‌شه ممکنه با Source IP یکی از کارت‌ها ارتباط برقرار کنه، درحالی‌که مسیر برگشت شبکه برای اون آدرس مناسب نیست.
این وضعیت می‌تونه باعث بشه ارتباط برقرار نشه، اتصال TCP ناقص بمونه یا فقط بعضی سرویس‌ها مشکل داشته باشن.
در ویندوز می‌تونی آدرس‌های IP رو با دستور زیر بررسی کنی:

Get-NetIPAddress -AddressFamily IPv4

در لینوکس:

ip addr
ip route get 8.8.8.8

5️⃣ Asymmetric Routing؛ مسیر رفت و برگشت متفاوت
یکی از علت‌های مهم، Asymmetric Routing هست. یعنی بسته از Interface اول خارج می‌شه، ولی پاسخ از مسیر یا Interface دیگه‌ای برمی‌گرده.
این حالت لزوماً مشکل نیست، اما اگر فایروال Stateful، تجهیزات امنیتی یا تنظیمات شبکه با این مسیر نامتقارن سازگار نباشن، ممکنه ارتباط Drop بشه. در لینوکس، تنظیمات Reverse Path Filtering هم در بعضی سناریوها می‌تونه روی دریافت بسته‌ها اثر بذاره.
6️⃣ Policy-Based Routing یا تنظیمات خاص سیستم‌عامل
در بعضی شبکه‌ها، انتخاب مسیر فقط براساس مقصد و Metric نیست. ممکنه بر اساس Source IP، جدول مسیریابی جداگانه یا Policyهای مشخص، مسیر متفاوتی انتخاب بشه.
در لینوکس، دستورهای ip rule و ip route برای بررسی این وضعیت مفیدن. در ویندوز هم باید Routeها، تنظیمات Interface و در صورت استفاده، سیاست‌های مسیریابی یا نرم‌افزارهای شبکه‌ای جانبی بررسی بشن.
7️⃣ چطور مشکل رو اصولی پیدا کنیم؟
برای عیب‌یابی، این ترتیب معمولاً منطقیه:
🔹 اول IP، Subnet Mask و Gateway هر کارت شبکه رو بررسی کن.
🔹 بعد Routing Table رو ببین و مسیر مقصد موردنظر رو پیدا کن.
🔹 Metric مسیرها و Interfaceها رو مقایسه کن.
🔹 Source IP انتخاب‌شده رو بررسی کن.
🔹 با ابزارهایی مثل tracert در ویندوز یا traceroute در لینوکس مسیر رو بررسی کن؛ البته این ابزارها همیشه Interface خروجی و مسیر واقعی تمام بسته‌ها رو به‌طور قطعی مشخص نمی‌کنن.

🧠 DNS Caching؛ کش DNS چه زمانی مفیده و چه زمانی دردسر ایجاد می‌کنه؟

وقتی آدرس یه سایت رو وارد می‌کنی، مثلاً google.com، سیستم باید از طریق DNS آدرس IP مربوط به اون دامنه رو پیدا کنه. حالا اگه قرار باشه هر بار که وارد یه سایت می‌شی، این فرایند از اول انجام بشه، هم درخواست‌های DNS بیشتر می‌شن و هم زمان اضافه‌ای برای پیدا کردن IP صرف می‌شه. اینجاست که DNS Caching وارد بازی می‌شه.

🔹 DNS Cache دقیقاً چیه؟
کش DNS یه حافظه موقته که نتیجه پاسخ‌های DNS رو نگه می‌داره تا اگه دوباره به همون دامنه درخواست دادی، سیستم مجبور نباشه تمام مراحل Resolve کردن دامنه رو از اول انجام بده. این کش می‌تونه روی سیستم‌عامل، مرورگر، سرویس DNS شبکه یا حتی سرورهای واسط وجود داشته باشه. هر رکورد DNS هم معمولاً یه مقدار TTL داره که مشخص می‌کنه پاسخ تا چه مدت می‌تونه معتبر در نظر گرفته بشه.
🔹 کش DNS چه زمانی مفیده؟
اولین مزیتش کاهش تأخیر در Resolve کردنه. وقتی یه دامنه قبلاً Resolve شده و پاسخ معتبرش هنوز توی کش وجود داره، سیستم می‌تونه سریع‌تر IP رو به دست بیاره. از طرفی، کش کردن پاسخ‌ها باعث کاهش تعداد درخواست‌ها به DNS Resolver می‌شه و در شبکه‌های پرترافیک، بار پردازشی و ترافیک DNS رو پایین میاره.
برای مثال، فرض کن توی یه شرکت ۵۰۰ تا سیستم کار می‌کنن و تعداد زیادی از اون‌ها مرتب به سرویس‌های داخلی و خارجی یکسانی وصل می‌شن. اگه پاسخ‌های DNS به‌درستی کش بشن، لازم نیست تمام درخواست‌ها هر بار از مسیر کامل DNS عبور کنن. البته میزان صرفه‌جویی به نوع کش، مدت TTL و الگوی درخواست‌ها بستگی داره.
🔹 پس مشکل کش DNS کجاست؟
مشکل اصلی زمانی شروع می‌شه که اطلاعات ذخیره‌شده دیگه با وضعیت واقعی شبکه مطابقت نداشته باشه.
فرض کن IP یه سرور از 192.168.1.10 به 192.168.1.20 تغییر کرده، اما سیستم کاربر هنوز IP قبلی رو توی کش خودش نگه داشته. در این شرایط ممکنه کاربر همچنان به آدرس قدیمی وصل بشه و با خطای اتصال، باز نشدن سایت یا دسترسی به سرویس اشتباه مواجه بشه.
این اتفاق به‌خصوص موقع جابه‌جایی سرورها، تغییر رکوردهای DNS، مهاجرت سرویس‌ها و تغییر زیرساخت شبکه می‌تونه دردسرساز بشه.
🔹 TTL چه نقشی توی این ماجرا داره؟

مشخص می‌کنه یک رکورد DNS چه مدت می‌تونه در کش نگه داشته بشه. مثلاً اگه TTL یه رکورد ۳۰۰ ثانیه باشه، یعنی پاسخ DNS برای مدت ۵ دقیقه قابل کش شدنه.


کوتاه‌تر معمولاً باعث می‌شه تغییرات DNS زودتر در درخواست‌های بعدی دیده بشن، اما ممکنه تعداد Queryهای DNS رو افزایش بده. در مقابل، TTL طولانی‌تر معمولاً باعث کاهش Queryها می‌شه، ولی ممکنه تغییر IP دیرتر در کش‌های موجود منعکس بشه

یه نکته مهم هم اینه که کاهش TTL درست قبل از تغییر IP، لزوماً باعث نمی‌شه تمام کلاینت‌ها فوراً رکورد جدید رو دریافت کنن؛ چون ممکنه پاسخ قبلی از قبل کش شده باشه و تا پایان اعتبارش باقی بمونه.

🔹 DNS Cache Poisoning؛ وقتی کش به مشکل امنیتی تبدیل می‌شه

یکی از خطرات امنیتی DNS، مسموم‌سازی کش یا DNS Cache Poisoning هست. در این سناریو، مهاجم تلاش می‌کنه یک پاسخ DNS جعلی رو وارد کش Resolver کنه تا درخواست‌های بعدی به آدرس اشتباه هدایت بشن.
برای مثال، کاربر تصور می‌کنه وارد سایت اصلی یه سرویس شده، اما به‌دلیل Resolve شدن دامنه به IP جعلی، ممکنه به سرور مهاجم هدایت بشه.
البته این اتفاق صرفاً با وجود کش DNS رخ نمی‌ده؛ مهاجم باید بتونه از یک آسیب‌پذیری یا شرایط مناسب برای تزریق پاسخ جعلی سوءاستفاده کنه. استفاده از DNSSEC در Resolverها، به‌روزرسانی نرم‌افزارهای DNS و پیکربندی امن می‌تونن به کاهش این ریسک کمک کنن.

🔹 چطور کش DNS رو در ویندوز بررسی یا پاک کنیم؟
برای مشاهده رکوردهای موجود در کش DNS ویندوز، CMD رو با دسترسی مناسب باز کن و این دستور رو اجرا کن:
ipconfig /displaydns
برای پاک کردن کش DNS کلاینت ویندوز:
ipconfig /flushdns
این دستور می‌تونه زمانی مفید باشه که IP یک دامنه تغییر کرده یا احتمال می‌دی پاسخ قدیمی در کش سیستم باقی مونده باشه.
اما حواست باشه که این دستور فقط کش DNS کلاینت ویندوز رو پاک می‌کنه؛ کش مرورگر، Resolver شبکه یا سرور DNS رو لزوماً پاک نمی‌کنه. پس اگه مشکل از یکی از این لایه‌ها باشه، ممکنه با اجرای این دستور به‌تنهایی حل نشه.

📡 @ModernLAN

💻 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