Mr. Nothing
Soon... ∆ Join VOID ∆
V0IDNETWORK is an ongoing, open research effort to document — rigorously and accurately — how the modern Internet's circumvention and surveillance technologies actually work at the protocol level, in support of a more open and resilient Internet.
🌐 Website
https://voidnetwork.ir
💻 GitHub
https://github.com/V0IDNETWORK
https://linkedin.com/in/ilianothing
📦 PyPI
https://pypi.org/user/ilianothing/
🔐 TryHackMe
https://tryhackme.com/p/ilianothingg
✍️ Medium
https://medium.com/@ilianothingg
▶️ YouTube
https://youtube.com/@locailife
https://instagram.com/ilianothing
💬 Telegram
https://t.me/voidxMaster
🖼 Gravatar
https://gravatar.com/profound851a01b866
💼Myket
https://myket.ir/developer/dev-97436
ilianothingg@gmail.com
GitHub
V0IDNETWORK - Overview
V0IDNETWORK is an ongoing, open research effort to document — rigorously and accurately - V0IDNETWORK
❤3
# Active Directory و Kerberos
# مهندسی معکوس اعتماد؛ پیچیدهترین میدان نبرد در Offensive Security مدرن
سطح: Advanced / Enterprise / Red Team / Identity Security
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
مقدمه
در دنیای کلاسیک امنیت، مهارت فنی معمولاً با توانایی یافتن یک RCE، توسعه Exploit، دور زدن مکانیزمهای دفاعی حافظه یا سوءاستفاده از آسیبپذیریهای روز صفر سنجیده میشد.
اما معماری سازمانی مدرن، قواعد بازی را تغییر داده است.
امروزه در بزرگترین رخدادهای امنیتی جهان، مهاجمان موفق الزاماً کسانی نیستند که بهترین اکسپلویتها را مینویسند.
بلکه کسانی هستند که بهتر از همه «اعتماد» را درک میکنند.
زیرا در Enterpriseهای مدرن، قدرت واقعی در اختیار سیستمی قرار دارد که هویت را تعریف میکند.
سیستمی که مشخص میکند:
چه کسی هستید؟
به چه چیزی دسترسی دارید؟
چه کسی به شما اعتماد میکند؟
و از طرف چه کسی میتوانید عمل کنید؟
نام این سیستم:
Active Directory
است.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل اول
Active Directory یک دیتابیس نیست؛ یک سیستم عامل هویت است
بزرگترین سوءبرداشت موجود درباره Active Directory این است که آن را صرفاً یک Directory Service یا مخزن کاربران تصور کنیم.
در واقع Active Directory چیزی بسیار بزرگتر است.
AD در عمل:
Identity Operating System
سازمان است.
همانطور که سیستم عامل منابع CPU، Memory و Processها را مدیریت میکند، Active Directory نیز مدیریت میکند:
Identity
Authentication
Authorization
Trust
Privilege
Delegation
Policy
Governance
و Boundaryهای امنیتی
را.
به همین دلیل است که سقوط Active Directory معمولاً به معنی سقوط کل سازمان است.
نه صرفاً چند سرور.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل دوم
هویت؛ دارایی اصلی قرن بیست و یکم
در گذشته مهاجم برای کنترل یک شبکه باید:
Serverها را تصرف میکرد.
امروزه کافی است:
Identityها را تصرف کند.
زیرا اگر بتوانید هویت را کنترل کنید:
نیازی به شکستن سیستمها ندارید.
سیستمها خودشان در را باز خواهند کرد.
این دقیقاً فلسفه حملات مدرن Identity-Centric است.
هدف نهایی دیگر:
Server Compromise
نیست.
بلکه:
Identity Dominance
است.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل سوم
گراف پنهان اعتماد
چیزی که Active Directory را پیچیده میکند تعداد ماشینها نیست.
بلکه تعداد روابط است.
هر Object در Active Directory دهها رابطه امنیتی با سایر Objectها دارد.
نمونه:
User
↓
Group
↓
Nested Group
↓
ACL
↓
Delegation
↓
Trust
↓
Certificate
↓
Tier-0
در ظاهر هیچ آسیبپذیری بحرانی وجود ندارد.
اما ترکیب همین روابط میتواند به کنترل کامل Forest ختم شود.
اینجاست که مفهوم مهمی متولد میشود:
Attack Path
در بسیاری از سازمانها:
هیچ آسیبپذیری بحرانی وجود ندارد.
اما صدها مسیر حمله بحرانی وجود دارد.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل چهارم
Kerberos؛ ماشین حالت اعتماد
اکثر متخصصان Kerberos را اینگونه میشناسند:
User
↓
TGT
↓
TGS
↓
Service
اما این فقط سطح بیرونی ماجراست.
در لایه عمیقتر Kerberos یک Security State Machine است.
هر Ticket حاوی مجموعهای از ویژگیهای امنیتی است:
PAC
Claims
SID
Group Membership
Delegation State
Authorization Data
Ticket Flags
Renewal Metadata
Trust Metadata
در نتیجه Kerberos صرفاً یک مکانیزم احراز هویت نیست.
بلکه یک موتور تصمیمگیری اعتماد است.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
نکته کلیدی
بیشتر حملات Kerberos حمله به رمزنگاری نیستند.
حمله به منطق هستند.
مهاجم معمولاً الگوریتم را نمیشکند.
بلکه منطق طراحی شده را به نفع خود بازنویسی میکند.
Golden Ticket
Silver Ticket
S4U Abuse
Delegation Abuse
Shadow Credentials
همگی مثالهایی از سوءاستفاده از منطق اعتماد هستند.
نه شکست رمزنگاری.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل پنجم
Delegation؛ خطرناکترین قابلیت مایکروسافت
اگر قرار باشد فقط یک قابلیت در اکوسیستم مایکروسافت انتخاب شود که بیشترین سهم را در حملات Enterprise داشته باشد، احتمالاً آن قابلیت Delegation خواهد بود.
دلیل طراحی:
حل مشکل Double-Hop Authentication
نتیجه عملی:
خلق پیچیدهترین زنجیرههای Impersonation در تاریخ Active Directory
انواع مهم:
Unconstrained Delegation
Constrained Delegation
Resource-Based Constrained Delegation
Protocol Transition
S4U2Self
S4U2Proxy
مشکل از جایی شروع میشود که:
Trust + Delegation + ACL
در کنار هم قرار میگیرند.
در این لحظه مهاجم میتواند از یک User عادی به سمت Tier-0 حرکت کند بدون آنکه حتی Exploit جدیدی اجرا کند.
# مهندسی معکوس اعتماد؛ پیچیدهترین میدان نبرد در Offensive Security مدرن
سطح: Advanced / Enterprise / Red Team / Identity Security
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
مقدمه
در دنیای کلاسیک امنیت، مهارت فنی معمولاً با توانایی یافتن یک RCE، توسعه Exploit، دور زدن مکانیزمهای دفاعی حافظه یا سوءاستفاده از آسیبپذیریهای روز صفر سنجیده میشد.
اما معماری سازمانی مدرن، قواعد بازی را تغییر داده است.
امروزه در بزرگترین رخدادهای امنیتی جهان، مهاجمان موفق الزاماً کسانی نیستند که بهترین اکسپلویتها را مینویسند.
بلکه کسانی هستند که بهتر از همه «اعتماد» را درک میکنند.
زیرا در Enterpriseهای مدرن، قدرت واقعی در اختیار سیستمی قرار دارد که هویت را تعریف میکند.
سیستمی که مشخص میکند:
چه کسی هستید؟
به چه چیزی دسترسی دارید؟
چه کسی به شما اعتماد میکند؟
و از طرف چه کسی میتوانید عمل کنید؟
نام این سیستم:
Active Directory
است.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل اول
Active Directory یک دیتابیس نیست؛ یک سیستم عامل هویت است
بزرگترین سوءبرداشت موجود درباره Active Directory این است که آن را صرفاً یک Directory Service یا مخزن کاربران تصور کنیم.
در واقع Active Directory چیزی بسیار بزرگتر است.
AD در عمل:
Identity Operating System
سازمان است.
همانطور که سیستم عامل منابع CPU، Memory و Processها را مدیریت میکند، Active Directory نیز مدیریت میکند:
Identity
Authentication
Authorization
Trust
Privilege
Delegation
Policy
Governance
و Boundaryهای امنیتی
را.
به همین دلیل است که سقوط Active Directory معمولاً به معنی سقوط کل سازمان است.
نه صرفاً چند سرور.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل دوم
هویت؛ دارایی اصلی قرن بیست و یکم
در گذشته مهاجم برای کنترل یک شبکه باید:
Serverها را تصرف میکرد.
امروزه کافی است:
Identityها را تصرف کند.
زیرا اگر بتوانید هویت را کنترل کنید:
نیازی به شکستن سیستمها ندارید.
سیستمها خودشان در را باز خواهند کرد.
این دقیقاً فلسفه حملات مدرن Identity-Centric است.
هدف نهایی دیگر:
Server Compromise
نیست.
بلکه:
Identity Dominance
است.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل سوم
گراف پنهان اعتماد
چیزی که Active Directory را پیچیده میکند تعداد ماشینها نیست.
بلکه تعداد روابط است.
هر Object در Active Directory دهها رابطه امنیتی با سایر Objectها دارد.
نمونه:
User
↓
Group
↓
Nested Group
↓
ACL
↓
Delegation
↓
Trust
↓
Certificate
↓
Tier-0
در ظاهر هیچ آسیبپذیری بحرانی وجود ندارد.
اما ترکیب همین روابط میتواند به کنترل کامل Forest ختم شود.
اینجاست که مفهوم مهمی متولد میشود:
Attack Path
در بسیاری از سازمانها:
هیچ آسیبپذیری بحرانی وجود ندارد.
اما صدها مسیر حمله بحرانی وجود دارد.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل چهارم
Kerberos؛ ماشین حالت اعتماد
اکثر متخصصان Kerberos را اینگونه میشناسند:
User
↓
TGT
↓
TGS
↓
Service
اما این فقط سطح بیرونی ماجراست.
در لایه عمیقتر Kerberos یک Security State Machine است.
هر Ticket حاوی مجموعهای از ویژگیهای امنیتی است:
PAC
Claims
SID
Group Membership
Delegation State
Authorization Data
Ticket Flags
Renewal Metadata
Trust Metadata
در نتیجه Kerberos صرفاً یک مکانیزم احراز هویت نیست.
بلکه یک موتور تصمیمگیری اعتماد است.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
نکته کلیدی
بیشتر حملات Kerberos حمله به رمزنگاری نیستند.
حمله به منطق هستند.
مهاجم معمولاً الگوریتم را نمیشکند.
بلکه منطق طراحی شده را به نفع خود بازنویسی میکند.
Golden Ticket
Silver Ticket
S4U Abuse
Delegation Abuse
Shadow Credentials
همگی مثالهایی از سوءاستفاده از منطق اعتماد هستند.
نه شکست رمزنگاری.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل پنجم
Delegation؛ خطرناکترین قابلیت مایکروسافت
اگر قرار باشد فقط یک قابلیت در اکوسیستم مایکروسافت انتخاب شود که بیشترین سهم را در حملات Enterprise داشته باشد، احتمالاً آن قابلیت Delegation خواهد بود.
دلیل طراحی:
حل مشکل Double-Hop Authentication
نتیجه عملی:
خلق پیچیدهترین زنجیرههای Impersonation در تاریخ Active Directory
انواع مهم:
Unconstrained Delegation
Constrained Delegation
Resource-Based Constrained Delegation
Protocol Transition
S4U2Self
S4U2Proxy
مشکل از جایی شروع میشود که:
Trust + Delegation + ACL
در کنار هم قرار میگیرند.
در این لحظه مهاجم میتواند از یک User عادی به سمت Tier-0 حرکت کند بدون آنکه حتی Exploit جدیدی اجرا کند.
❤3
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
مثال واقعی
فرض کنید مهاجم:
GenericWrite
روی یک Computer Object داشته باشد.
در نگاه اول:
Low Risk
به نظر میرسد.
اما همین مجوز میتواند منجر شود به:
Computer Takeover
↓
RBCD
↓
Kerberos Impersonation
↓
Service Takeover
↓
Domain Escalation
یک ACL ساده.
یک Forest نابود شده.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل ششم
چرا BloodHound انقلابی ایجاد کرد؟
قبل از BloodHound تحلیل AD تقریباً غیرممکن بود.
زیرا ذهن انسان توان تحلیل میلیونها رابطه را ندارد.
BloodHound برای اولین بار نشان داد:
امنیت Active Directory
=
مسئله Graph Theory
است.
سؤال اصلی دیگر این نبود:
آیا آسیبپذیری وجود دارد؟
بلکه:
آیا مسیر وجود دارد؟
بود.
و تقریباً همیشه پاسخ:
بله
است.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل هفتم
AD CS؛ کابوس جدید مدافعان
سالها تصور میشد Kerberos بزرگترین Attack Surface هویتی است.
اما کشف حملات ESC نشان داد:
PKI از بسیاری جهات خطرناکتر است.
چرا؟
زیرا Password قابل تغییر است.
Hash قابل چرخش است.
Ticket منقضی میشود.
اما Certificate میتواند هویت را بازتعریف کند.
زمانی که مهاجم بتواند:
Enrollment Policy
Template
CA Configuration
Certificate Mapping
را تحت کنترل بگیرد، عملاً میتواند:
Identity Forge
انجام دهد.
یعنی خلق هویت معتبر بدون نیاز به Credential واقعی.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
نمونه حملات مشهور AD CS
ESC1
ESC3
ESC4
ESC8
ESC13
ESC16
هر کدام نمونهای از سوءاستفاده از زنجیره اعتماد PKI هستند.
نکته ترسناک:
بسیاری از این حملات حتی نیازمند Domain Admin نیستند.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل هشتم
Trust؛ میدان واقعی جنگ
بیشتر تیمهای دفاعی در سطح Domain فکر میکنند.
اما مهاجم حرفهای در سطح Forest فکر میکند.
زیرا Forest واحد واقعی اعتماد است.
مفاهیم کلیدی:
Parent-Child Trust
Forest Trust
External Trust
SID Filtering
Selective Authentication
Cross Forest Kerberos
Trustها تعیین میکنند:
یک نفوذ محلی
چگونه
به یک بحران سازمانی
تبدیل شود.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل نهم
Tier-0؛ تاج پادشاهی
بسیاری تصور میکنند:
Domain Admin
بالاترین سطح دسترسی است.
اما در معماری مدرن مایکروسافت این تصور اشتباه است.
هدف واقعی:
Tier-0
است.
Tier-0 شامل:
Domain Controllers
Enterprise CA
ADFS
Entra Connect
Azure AD Connect
Privileged Access Workstations
Identity Management Systems
است.
کنترل Tier-0 یعنی:
کنترل اعتماد
کنترل اعتماد یعنی:
کنترل سازمان
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل دهم
چرا AD از Exploit Development سختتر است؟
Exploit Development معمولاً ساختار مشخصی دارد:
Bug
↓
Primitive
↓
Weaponization
↓
Exploit
اما Active Directory هیچ ساختار ثابتی ندارد.
هر سازمان:
Trust متفاوت
PKI متفاوت
Delegation متفاوت
ACL متفاوت
Tiering متفاوت
Architecture متفاوت
دارد.
بنابراین هیچ Playbook جهانی وجود ندارد.
هر عملیات نیازمند:
Threat Modeling
Identity Mapping
Trust Analysis
Graph Traversal
Privilege Correlation
است.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فرمول ذهنی Red Teamهای سطح بالا
Initial Access
+
Identity Intelligence
+
Trust Analysis
+
Graph Traversal
+
Privilege Escalation Primitive
+
Tier-0 Path Discovery
=
Enterprise Compromise
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
جمعبندی نهایی
Active Directory درباره هک کردن سیستمها نیست.
درباره فهمیدن اعتماد است.
Kerberos درباره Ticket نیست.
درباره جریان اعتماد است.
PKI درباره Certificate نیست.
درباره حاکمیت هویت است.
Trustها درباره اتصال Domainها نیستند.
درباره گسترش مرزهای نفوذ هستند.
و Tier-0 درباره Administratorها نیست.
درباره مالکیت کامل Fabric هویتی سازمان است.
اپراتوری که بتواند:
• Kerberos را در سطح State Machine تحلیل کند
• Graphهای دسترسی را مدلسازی کند
• Delegation Chainها را کشف کند
• PKI را بهعنوان Attack Surface مستقل بررسی کند
• Trust Boundaryها را مهندسی معکوس کند
• و Tier-0 را از منظر معماری امنیتی درک کند
دیگر صرفاً یک Pentester یا Red Teamer نیست.
او در حال تحلیل و تسخیر پیچیدهترین دارایی امنیتی سازمان است:
Identity Fabric
لایهای که امروز ارزشمندتر از سرورها،
حساستر از دادهها،
و حیاتیتر از زیرساخت فیزیکی محسوب میشود.
زیرا در نهایت:
کسی که هویت را کنترل میکند،
سازمان را کنترل میکند.
مثال واقعی
فرض کنید مهاجم:
GenericWrite
روی یک Computer Object داشته باشد.
در نگاه اول:
Low Risk
به نظر میرسد.
اما همین مجوز میتواند منجر شود به:
Computer Takeover
↓
RBCD
↓
Kerberos Impersonation
↓
Service Takeover
↓
Domain Escalation
یک ACL ساده.
یک Forest نابود شده.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل ششم
چرا BloodHound انقلابی ایجاد کرد؟
قبل از BloodHound تحلیل AD تقریباً غیرممکن بود.
زیرا ذهن انسان توان تحلیل میلیونها رابطه را ندارد.
BloodHound برای اولین بار نشان داد:
امنیت Active Directory
=
مسئله Graph Theory
است.
سؤال اصلی دیگر این نبود:
آیا آسیبپذیری وجود دارد؟
بلکه:
آیا مسیر وجود دارد؟
بود.
و تقریباً همیشه پاسخ:
بله
است.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل هفتم
AD CS؛ کابوس جدید مدافعان
سالها تصور میشد Kerberos بزرگترین Attack Surface هویتی است.
اما کشف حملات ESC نشان داد:
PKI از بسیاری جهات خطرناکتر است.
چرا؟
زیرا Password قابل تغییر است.
Hash قابل چرخش است.
Ticket منقضی میشود.
اما Certificate میتواند هویت را بازتعریف کند.
زمانی که مهاجم بتواند:
Enrollment Policy
Template
CA Configuration
Certificate Mapping
را تحت کنترل بگیرد، عملاً میتواند:
Identity Forge
انجام دهد.
یعنی خلق هویت معتبر بدون نیاز به Credential واقعی.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
نمونه حملات مشهور AD CS
ESC1
ESC3
ESC4
ESC8
ESC13
ESC16
هر کدام نمونهای از سوءاستفاده از زنجیره اعتماد PKI هستند.
نکته ترسناک:
بسیاری از این حملات حتی نیازمند Domain Admin نیستند.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل هشتم
Trust؛ میدان واقعی جنگ
بیشتر تیمهای دفاعی در سطح Domain فکر میکنند.
اما مهاجم حرفهای در سطح Forest فکر میکند.
زیرا Forest واحد واقعی اعتماد است.
مفاهیم کلیدی:
Parent-Child Trust
Forest Trust
External Trust
SID Filtering
Selective Authentication
Cross Forest Kerberos
Trustها تعیین میکنند:
یک نفوذ محلی
چگونه
به یک بحران سازمانی
تبدیل شود.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل نهم
Tier-0؛ تاج پادشاهی
بسیاری تصور میکنند:
Domain Admin
بالاترین سطح دسترسی است.
اما در معماری مدرن مایکروسافت این تصور اشتباه است.
هدف واقعی:
Tier-0
است.
Tier-0 شامل:
Domain Controllers
Enterprise CA
ADFS
Entra Connect
Azure AD Connect
Privileged Access Workstations
Identity Management Systems
است.
کنترل Tier-0 یعنی:
کنترل اعتماد
کنترل اعتماد یعنی:
کنترل سازمان
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فصل دهم
چرا AD از Exploit Development سختتر است؟
Exploit Development معمولاً ساختار مشخصی دارد:
Bug
↓
Primitive
↓
Weaponization
↓
Exploit
اما Active Directory هیچ ساختار ثابتی ندارد.
هر سازمان:
Trust متفاوت
PKI متفاوت
Delegation متفاوت
ACL متفاوت
Tiering متفاوت
Architecture متفاوت
دارد.
بنابراین هیچ Playbook جهانی وجود ندارد.
هر عملیات نیازمند:
Threat Modeling
Identity Mapping
Trust Analysis
Graph Traversal
Privilege Correlation
است.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
فرمول ذهنی Red Teamهای سطح بالا
Initial Access
+
Identity Intelligence
+
Trust Analysis
+
Graph Traversal
+
Privilege Escalation Primitive
+
Tier-0 Path Discovery
=
Enterprise Compromise
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
جمعبندی نهایی
Active Directory درباره هک کردن سیستمها نیست.
درباره فهمیدن اعتماد است.
Kerberos درباره Ticket نیست.
درباره جریان اعتماد است.
PKI درباره Certificate نیست.
درباره حاکمیت هویت است.
Trustها درباره اتصال Domainها نیستند.
درباره گسترش مرزهای نفوذ هستند.
و Tier-0 درباره Administratorها نیست.
درباره مالکیت کامل Fabric هویتی سازمان است.
اپراتوری که بتواند:
• Kerberos را در سطح State Machine تحلیل کند
• Graphهای دسترسی را مدلسازی کند
• Delegation Chainها را کشف کند
• PKI را بهعنوان Attack Surface مستقل بررسی کند
• Trust Boundaryها را مهندسی معکوس کند
• و Tier-0 را از منظر معماری امنیتی درک کند
دیگر صرفاً یک Pentester یا Red Teamer نیست.
او در حال تحلیل و تسخیر پیچیدهترین دارایی امنیتی سازمان است:
Identity Fabric
لایهای که امروز ارزشمندتر از سرورها،
حساستر از دادهها،
و حیاتیتر از زیرساخت فیزیکی محسوب میشود.
زیرا در نهایت:
کسی که هویت را کنترل میکند،
سازمان را کنترل میکند.
∆ Join VOID ∆
❤2🔥1
چرا امنیت BGP یکی از پیچیدهترین مباحث شبکه محسوب میشود؟
بیشتر متخصصان شبکه در طول فعالیت حرفهای خود با VLAN، OSPF، VPN و حتی MPLS کار میکنند، اما تعداد بسیار کمی از مهندسان وارد لایهای میشوند که اینترنت جهانی بر روی آن ساخته شده است.
در این لایه، صحبت از یک سازمان یا یک دیتاسنتر نیست؛ صحبت از هزاران Autonomous System، میلیونها Prefix و صدها هزار Policy Routing است که به صورت همزمان اینترنت را زنده نگه میدارند.
BGP صرفاً یک پروتکل مسیریابی نیست؛ بلکه یک سیستم توزیع اعتماد در مقیاس جهانی است.
---
مشکل اصلی BGP: اعتماد پیشفرض
برخلاف تصور بسیاری از افراد، BGP در طراحی اولیه تقریباً هیچ مکانیزم ذاتی برای اعتبارسنجی مسیرها نداشت.
زمانی که یک AS اعلام میکند:
> من مالک این Prefix هستم.
همسایهها معمولاً این ادعا را قبول میکنند.
این مدل اعتماد باعث شکلگیری یکی از خطرناکترین حملات تاریخ اینترنت شده است:
Route Hijacking
در این سناریو یک Autonomous System مسیرهایی را اعلام میکند که در واقع متعلق به آن نیست.
در نتیجه:
ترافیک منحرف میشود.
اطلاعات رهگیری میشوند.
سرویسها از دسترس خارج میشوند.
مسیرهای اینترنت تغییر میکنند.
---
Route Leak؛ حملهای که همیشه عمدی نیست
یکی از پیچیدهترین مشکلات اینترنت مدرن Route Leak است.
در این حالت یک اپراتور یا ISP به اشتباه Routeهایی را منتشر میکند که نباید منتشر شوند.
نتیجه میتواند شامل موارد زیر باشد:
افزایش شدید Latency
Congestion
قطع ارتباط بین قارهها
Blackholing ترافیک
برخی از بزرگترین اختلالهای اینترنت در دهه گذشته ناشی از Route Leak بودهاند، نه حملات سایبری کلاسیک.
---
Traffic Engineering؛ هنر کنترل اینترنت
در شبکههای سازمانی معمولاً مسیر کوتاهتر انتخاب میشود.
اما در BGP موضوع متفاوت است.
مهندسان Carrier-Level دائماً با Attributeهایی مانند:
Local Preference
MED
AS Path
Community
Extended Community
کار میکنند تا رفتار ترافیک را کنترل کنند.
هدف همیشه کوتاهترین مسیر نیست.
گاهی اوقات:
ارزانترین مسیر
پایدارترین مسیر
کمترافیکترین مسیر
امنترین مسیر
اولویت بالاتری دارد.
---
RPKI؛ تلاش برای حل بحران اعتماد
با افزایش حملات BGP، مکانیزمی به نام Resource Public Key Infrastructure ایجاد شد.
RPKI تلاش میکند مشخص کند:
کدام Autonomous System مجاز است یک Prefix خاص را Advertise کند.
اما پیادهسازی RPKI در مقیاس جهانی چالشهای متعددی دارد:
پیچیدگی عملیاتی
وابستگی به Trust Anchorها
ناسازگاری برخی تجهیزات قدیمی
مشکلات سیاستگذاری بین اپراتورها
به همین دلیل هنوز هم اینترنت کاملاً در برابر Hijack ایمن نشده است.
---
BGP در محیطهای Red Team
بیشتر افراد BGP را صرفاً موضوعی برای مهندسان ISP میدانند.
اما تیمهای Red Team پیشرفته و گروههای APT به خوبی میدانند که کنترل مسیرهای شبکه گاهی از نفوذ به یک سرور ارزشمندتر است.
زیرا در صورت کنترل مسیر:
امکان رهگیری ترافیک فراهم میشود.
حملات Man-in-the-Middle سادهتر میشوند.
سامانههای امنیتی دور زده میشوند.
Visibility مدافعان کاهش مییابد.
به همین دلیل امنیت Routing Infrastructure یکی از بخشهای حیاتی دفاع سایبری در سطح ملی محسوب میشود.
---
چرا یادگیری این حوزه دشوار است؟
زیرا برای درک واقعی آن باید همزمان بر چند حوزه مسلط باشید:
Routing پیشرفته
Architecture اینترنت
MPLS
Carrier Networking
Internet Exchange Point
PKI
Cryptography
Traffic Engineering
Incident Response
این حجم از دانش باعث شده امنیت BGP و Routing Infrastructure یکی از معدود حوزههایی باشد که حتی بسیاری از متخصصان ارشد امنیت نیز در آن تجربه عملی محدودی دارند.
---
نتیجه
اگر Active Directory را قلب شبکههای سازمانی بدانیم، BGP قلب اینترنت است.
درک عمیق BGP دیگر صرفاً یک مهارت شبکه نیست؛ بلکه شناخت مکانیزمی است که کل اینترنت بر پایه آن تصمیم میگیرد هر بسته داده از کدام مسیر عبور کند. به همین دلیل امنیت BGP، Route Hijacking، Route Leak و RPKI از پیچیدهترین و تخصصیترین مباحث دنیای شبکه و امنیت سایبری محسوب میشوند.
بیشتر متخصصان شبکه در طول فعالیت حرفهای خود با VLAN، OSPF، VPN و حتی MPLS کار میکنند، اما تعداد بسیار کمی از مهندسان وارد لایهای میشوند که اینترنت جهانی بر روی آن ساخته شده است.
در این لایه، صحبت از یک سازمان یا یک دیتاسنتر نیست؛ صحبت از هزاران Autonomous System، میلیونها Prefix و صدها هزار Policy Routing است که به صورت همزمان اینترنت را زنده نگه میدارند.
BGP صرفاً یک پروتکل مسیریابی نیست؛ بلکه یک سیستم توزیع اعتماد در مقیاس جهانی است.
---
مشکل اصلی BGP: اعتماد پیشفرض
برخلاف تصور بسیاری از افراد، BGP در طراحی اولیه تقریباً هیچ مکانیزم ذاتی برای اعتبارسنجی مسیرها نداشت.
زمانی که یک AS اعلام میکند:
> من مالک این Prefix هستم.
همسایهها معمولاً این ادعا را قبول میکنند.
این مدل اعتماد باعث شکلگیری یکی از خطرناکترین حملات تاریخ اینترنت شده است:
Route Hijacking
در این سناریو یک Autonomous System مسیرهایی را اعلام میکند که در واقع متعلق به آن نیست.
در نتیجه:
ترافیک منحرف میشود.
اطلاعات رهگیری میشوند.
سرویسها از دسترس خارج میشوند.
مسیرهای اینترنت تغییر میکنند.
---
Route Leak؛ حملهای که همیشه عمدی نیست
یکی از پیچیدهترین مشکلات اینترنت مدرن Route Leak است.
در این حالت یک اپراتور یا ISP به اشتباه Routeهایی را منتشر میکند که نباید منتشر شوند.
نتیجه میتواند شامل موارد زیر باشد:
افزایش شدید Latency
Congestion
قطع ارتباط بین قارهها
Blackholing ترافیک
برخی از بزرگترین اختلالهای اینترنت در دهه گذشته ناشی از Route Leak بودهاند، نه حملات سایبری کلاسیک.
---
Traffic Engineering؛ هنر کنترل اینترنت
در شبکههای سازمانی معمولاً مسیر کوتاهتر انتخاب میشود.
اما در BGP موضوع متفاوت است.
مهندسان Carrier-Level دائماً با Attributeهایی مانند:
Local Preference
MED
AS Path
Community
Extended Community
کار میکنند تا رفتار ترافیک را کنترل کنند.
هدف همیشه کوتاهترین مسیر نیست.
گاهی اوقات:
ارزانترین مسیر
پایدارترین مسیر
کمترافیکترین مسیر
امنترین مسیر
اولویت بالاتری دارد.
---
RPKI؛ تلاش برای حل بحران اعتماد
با افزایش حملات BGP، مکانیزمی به نام Resource Public Key Infrastructure ایجاد شد.
RPKI تلاش میکند مشخص کند:
کدام Autonomous System مجاز است یک Prefix خاص را Advertise کند.
اما پیادهسازی RPKI در مقیاس جهانی چالشهای متعددی دارد:
پیچیدگی عملیاتی
وابستگی به Trust Anchorها
ناسازگاری برخی تجهیزات قدیمی
مشکلات سیاستگذاری بین اپراتورها
به همین دلیل هنوز هم اینترنت کاملاً در برابر Hijack ایمن نشده است.
---
BGP در محیطهای Red Team
بیشتر افراد BGP را صرفاً موضوعی برای مهندسان ISP میدانند.
اما تیمهای Red Team پیشرفته و گروههای APT به خوبی میدانند که کنترل مسیرهای شبکه گاهی از نفوذ به یک سرور ارزشمندتر است.
زیرا در صورت کنترل مسیر:
امکان رهگیری ترافیک فراهم میشود.
حملات Man-in-the-Middle سادهتر میشوند.
سامانههای امنیتی دور زده میشوند.
Visibility مدافعان کاهش مییابد.
به همین دلیل امنیت Routing Infrastructure یکی از بخشهای حیاتی دفاع سایبری در سطح ملی محسوب میشود.
---
چرا یادگیری این حوزه دشوار است؟
زیرا برای درک واقعی آن باید همزمان بر چند حوزه مسلط باشید:
Routing پیشرفته
Architecture اینترنت
MPLS
Carrier Networking
Internet Exchange Point
PKI
Cryptography
Traffic Engineering
Incident Response
این حجم از دانش باعث شده امنیت BGP و Routing Infrastructure یکی از معدود حوزههایی باشد که حتی بسیاری از متخصصان ارشد امنیت نیز در آن تجربه عملی محدودی دارند.
---
نتیجه
اگر Active Directory را قلب شبکههای سازمانی بدانیم، BGP قلب اینترنت است.
درک عمیق BGP دیگر صرفاً یک مهارت شبکه نیست؛ بلکه شناخت مکانیزمی است که کل اینترنت بر پایه آن تصمیم میگیرد هر بسته داده از کدام مسیر عبور کند. به همین دلیل امنیت BGP، Route Hijacking، Route Leak و RPKI از پیچیدهترین و تخصصیترین مباحث دنیای شبکه و امنیت سایبری محسوب میشوند.
∆ Join VOID ∆
❤2🔥1
مطالب بالا آماده سازیشون یکم طول کشید، احتمالا چند وقت دیگه یکسری مطلب از اثراتی که وایب کدینگ و استفاده از Ai برای برنامه نویسی روی جامعه گذاشته آماده کنم و بزارم ❤️
∆ Join VOID ∆
Telegram
VOID
Freedom through power. Power through intelligence.| voidNetwork.ir
❤2
لینوکس در معنای دقیقش کرنل است، نه کل سیستمعامل. کرنل مسئول مدیریت سختافزار، منابع سیستم و سرویسهای پایهای برای نرمافزارهای دیگر است؛ به همین دلیل هم اسناد رسمی کرنل، آن را «هستهٔ هر سیستمعامل لینوکسی» توصیف میکنند. خود پروژهٔ کرنل هم بسیار بزرگ است: در مستندات رسمی از بیش از ۸ میلیون خط کد و بیش از ۱۰۰۰ مشارکتکننده برای هر انتشار صحبت میشود. این اندازه و پیچیدگی باعث میشود که لینوکس را بهتر است نه یک محصول واحد، بلکه یک اکوسیستم مهندسیشده ببینیم.
از نظر فنی، کرنل لینوکس به زیرسامانههای مشخصی مثل شبکه، حافظه، پشتیبانی معماریها و درایورها تقسیم شده و هر زیرسامانه معمولاً نگهدارندهٔ مخصوص خودش را دارد. در نتیجه، توسعهٔ کرنل «یک تکه کد عظیم» نیست؛ یک ساختار لایهدار با فرایند merge window، بازبینی، و نگهداری زیرسامانهای است. همینطور، کد کرنل عمدتاً با C نوشته میشود و بهطور معمول با گویش GNU C11 کامپایل میشود، با بخشهایی هم به اسمبلی وابسته به معماری.
شاخهبندی انتشار هم مهم است: upstream لینوکس فقط «mainline» نیست، بلکه شاخههای stable و longterm هم دارد. در عین حال، خود kernel.org صریح میگوید کرنلهایی که توزیعها با backport و patch نگه میدارند ممکن است بر پایهٔ شاخههای رسمی باشند یا نباشند، و این کرنلهای توزیعی لزوماً تحت پشتیبانی مستقیم توسعهدهندگان kernel.org نیستند. این نکته برای درک تفاوت «کرنلِ upstream» با «کرنلِ توزیع» حیاتی است.
اینجا به نقطهٔ اصلی میرسیم: توزیع فقط «لینوکس» نیست، بلکه یک بستهٔ کامل از سیاستها، ابزارها، مخازن، مدیر بسته، انتخاب کرنل، سیکل انتشار، و سطح نگهداری است. بنابراین وقتی میگوییم «Debian بهتر است» یا «Arch بهتر است»، در واقع داریم دربارهٔ یک مدل عملیاتی حرف میزنیم: چهقدر تازگی بستهها مهم است، چهقدر پایداری مهم است، و چهقدر میخواهی خودت مدیر سیستم باشی.
دستهبندی حرفهای توزیعها
Debian Stable نمایندهٔ کلاس «پایداری محافظهکارانه» است. طبق مستند رسمی، هر انتشار stable در مجموع پنج سال چرخهٔ عمر دارد: سه سال پشتیبانی کامل و دو سال LTS. این مدل برای سرور، زیرساخت، و سیستمهایی که تغییر کم و پیشبینیپذیری بالا میخواهند بسیار مناسب است؛ اما بهایش این است که بستهها معمولاً از نوترین نسخهها عقبتر میمانند.
Ubuntu LTS نسخهٔ «تعادل میان دسترسیپذیری و پایداری» است. مستند رسمی اوبونتو میگوید LTSها هر دو سال منتشر میشوند، ۵ سال پشتیبانی استاندارد امنیتی دارند، و در مجموع ۱۰ سال نگهداری میشوند؛ با Ubuntu Pro و Legacy support حتی میتواند بیشتر هم بشود. به همین دلیل Ubuntu LTS برای دسکتاپ عمومی، سرور، و محیطهایی که هم اکوسیستم بزرگ میخواهند هم دردسر کم، بسیار محبوب است.
Fedora توزیعی است که عمداً سریع حرکت میکند. مستندات رسمی فدورا میگویند انتشارها تقریباً هر شش ماه یکبار انجام میشود و هر انتشار حدود ۱۳ ماه پشتیبانی میگیرد. فلسفهٔ فدورا این است که فناوریهای جدید را زودتر وارد چرخه کند؛ برای توسعهدهندهها، تسترها، و کسانی که سختافزار یا نرمافزار جدید دارند، این مزیت بزرگی است. اما همین سرعت، آن را برای کسانی که هر چند سال یکبار سیستم را «راه بینداز و فراموش کن» میخواهند، کمتر مناسب میکند.
Arch Linux نمایندهٔ مدل rolling release است. سایت رسمی Arch میگوید این توزیع lightweight و flexible است و با مدل «rolling release» نصب یکباره و بهروزرسانی پیوسته را دنبال میکند. این یعنی بعد از نصب اولیه، قرار نیست از نسخهای به نسخهٔ دیگر مهاجرت بزرگ داشته باشی؛ سیستم دائماً جلو میرود. این مدل برای کاربرانی که کنترل دقیق، بستههای تازه، و حداقل تزئینات پیشفرض میخواهند عالی است، اما به همان اندازه هم انتظار میرود که نگهداری و مطالعهٔ سیستم را جدی بگیری.
openSUSE Tumbleweed یکی از حرفهایترین rolling releaseهاست، چون rolling بودن را با کنترل کیفی جدی ترکیب میکند. صفحهٔ رسمی Tumbleweed میگوید که این توزیع «latest stable versions» را ارائه میکند، با تستهای گسترده و حتی امکان rollback با snapshot. این یعنی اگر rolling release میخواهی ولی از ایدهٔ «rolling بیمهار» میترسی، Tumbleweed یک گزینهٔ بسیار بالغ است.
openSUSE Leap در سوی دیگر این طیف است: نسخهای با تمرکز قوی بر ثبات و lifecycle طولانی. مستندات رسمی Leap 16 از چرخهٔ ۲۴ ماهه برای هر minor release و رویکرد هیبریدیِ مبتنی بر SLE و توسعهٔ جامعه صحبت میکنند. Leap برای کسانی که از پایداری سطح enterprise خوششان میآید ولی فضای open-source و ابزارهای openSUSE را ترجیح میدهند، بسیار جذاب است.
از نظر فنی، کرنل لینوکس به زیرسامانههای مشخصی مثل شبکه، حافظه، پشتیبانی معماریها و درایورها تقسیم شده و هر زیرسامانه معمولاً نگهدارندهٔ مخصوص خودش را دارد. در نتیجه، توسعهٔ کرنل «یک تکه کد عظیم» نیست؛ یک ساختار لایهدار با فرایند merge window، بازبینی، و نگهداری زیرسامانهای است. همینطور، کد کرنل عمدتاً با C نوشته میشود و بهطور معمول با گویش GNU C11 کامپایل میشود، با بخشهایی هم به اسمبلی وابسته به معماری.
شاخهبندی انتشار هم مهم است: upstream لینوکس فقط «mainline» نیست، بلکه شاخههای stable و longterm هم دارد. در عین حال، خود kernel.org صریح میگوید کرنلهایی که توزیعها با backport و patch نگه میدارند ممکن است بر پایهٔ شاخههای رسمی باشند یا نباشند، و این کرنلهای توزیعی لزوماً تحت پشتیبانی مستقیم توسعهدهندگان kernel.org نیستند. این نکته برای درک تفاوت «کرنلِ upstream» با «کرنلِ توزیع» حیاتی است.
اینجا به نقطهٔ اصلی میرسیم: توزیع فقط «لینوکس» نیست، بلکه یک بستهٔ کامل از سیاستها، ابزارها، مخازن، مدیر بسته، انتخاب کرنل، سیکل انتشار، و سطح نگهداری است. بنابراین وقتی میگوییم «Debian بهتر است» یا «Arch بهتر است»، در واقع داریم دربارهٔ یک مدل عملیاتی حرف میزنیم: چهقدر تازگی بستهها مهم است، چهقدر پایداری مهم است، و چهقدر میخواهی خودت مدیر سیستم باشی.
دستهبندی حرفهای توزیعها
Debian Stable نمایندهٔ کلاس «پایداری محافظهکارانه» است. طبق مستند رسمی، هر انتشار stable در مجموع پنج سال چرخهٔ عمر دارد: سه سال پشتیبانی کامل و دو سال LTS. این مدل برای سرور، زیرساخت، و سیستمهایی که تغییر کم و پیشبینیپذیری بالا میخواهند بسیار مناسب است؛ اما بهایش این است که بستهها معمولاً از نوترین نسخهها عقبتر میمانند.
Ubuntu LTS نسخهٔ «تعادل میان دسترسیپذیری و پایداری» است. مستند رسمی اوبونتو میگوید LTSها هر دو سال منتشر میشوند، ۵ سال پشتیبانی استاندارد امنیتی دارند، و در مجموع ۱۰ سال نگهداری میشوند؛ با Ubuntu Pro و Legacy support حتی میتواند بیشتر هم بشود. به همین دلیل Ubuntu LTS برای دسکتاپ عمومی، سرور، و محیطهایی که هم اکوسیستم بزرگ میخواهند هم دردسر کم، بسیار محبوب است.
Fedora توزیعی است که عمداً سریع حرکت میکند. مستندات رسمی فدورا میگویند انتشارها تقریباً هر شش ماه یکبار انجام میشود و هر انتشار حدود ۱۳ ماه پشتیبانی میگیرد. فلسفهٔ فدورا این است که فناوریهای جدید را زودتر وارد چرخه کند؛ برای توسعهدهندهها، تسترها، و کسانی که سختافزار یا نرمافزار جدید دارند، این مزیت بزرگی است. اما همین سرعت، آن را برای کسانی که هر چند سال یکبار سیستم را «راه بینداز و فراموش کن» میخواهند، کمتر مناسب میکند.
Arch Linux نمایندهٔ مدل rolling release است. سایت رسمی Arch میگوید این توزیع lightweight و flexible است و با مدل «rolling release» نصب یکباره و بهروزرسانی پیوسته را دنبال میکند. این یعنی بعد از نصب اولیه، قرار نیست از نسخهای به نسخهٔ دیگر مهاجرت بزرگ داشته باشی؛ سیستم دائماً جلو میرود. این مدل برای کاربرانی که کنترل دقیق، بستههای تازه، و حداقل تزئینات پیشفرض میخواهند عالی است، اما به همان اندازه هم انتظار میرود که نگهداری و مطالعهٔ سیستم را جدی بگیری.
openSUSE Tumbleweed یکی از حرفهایترین rolling releaseهاست، چون rolling بودن را با کنترل کیفی جدی ترکیب میکند. صفحهٔ رسمی Tumbleweed میگوید که این توزیع «latest stable versions» را ارائه میکند، با تستهای گسترده و حتی امکان rollback با snapshot. این یعنی اگر rolling release میخواهی ولی از ایدهٔ «rolling بیمهار» میترسی، Tumbleweed یک گزینهٔ بسیار بالغ است.
openSUSE Leap در سوی دیگر این طیف است: نسخهای با تمرکز قوی بر ثبات و lifecycle طولانی. مستندات رسمی Leap 16 از چرخهٔ ۲۴ ماهه برای هر minor release و رویکرد هیبریدیِ مبتنی بر SLE و توسعهٔ جامعه صحبت میکنند. Leap برای کسانی که از پایداری سطح enterprise خوششان میآید ولی فضای open-source و ابزارهای openSUSE را ترجیح میدهند، بسیار جذاب است.
❤3
Red Hat Enterprise Linux (RHEL) کلاس enterprise را نمایندگی میکند. مستند سیاست چرخهٔ حیات RHEL برای نسخههای ۸، ۹ و ۱۰ چرخهٔ ۱۰ سالهٔ Full Support و Maintenance Support را اعلام میکند، و Red Hat حتی برای برخی سناریوها Extended Life Cycle تا ۱۴ سال را هم ارائه کرده است. این مدل برای سازمانهایی که ثبات، پشتیبانی قراردادی، و مهاجرتهای برنامهریزیشده میخواهند، از نظر مهندسی بسیار معنیدار است.
چرا بعضی انتخابها «خوب نیستند»
بدیِ یک توزیع معمولاً مطلق نیست؛ بد بودن وقتی رخ میدهد که مدل توزیع با نیاز واقعی تو همراستا نباشد. برای مثال، rolling release برای کسی که هر روز سیستم را نگهداری میکند و snapshot/rollback و حوصلهٔ مطالعه دارد، عالی است؛ اما برای تیمی که downtime گران است و تغییرات باید از قبل آزموده و زمانبندی شوند، مدل rolling میتواند ریسک عملیاتی اضافه کند. این نتیجهگیری از خودِ فلسفهٔ Arch و Tumbleweed و در برابر مدلهای چرخهدار مثل Debian/Ubuntu/RHEL بهدست میآید.
برعکس، انتخاب یک توزیع بسیار محافظهکار برای کسی که سختافزار جدید، درایور تازه، گرافیک نو، یا ابزارهای توسعهٔ جدید میخواهد، میتواند به معنی «عقب ماندن از اکوسیستم» باشد. Fedora با چرخهٔ سریعش دقیقاً برای همین شکاف طراحی شده، و Arch/Tumbleweed هم با هدف رساندن بستههای جدیدتر وارد عمل میشوند. بنابراین انتخاب Debian Stable یا RHEL برای یک workstation که نیازمند آخرین toolchain یا driver است، از نظر نیازمندی فنی ممکن است انتخاب ضعیفی باشد، حتی اگر از نظر پایداری عالی باشد.
یک خطای رایج دیگر این است که توزیع را فقط بر اساس «معروف بودن» انتخاب کنیم. شهرت لزوماً معادل تناسب نیست. Ubuntu بهخاطر اکوسیستم و LTS عالی است، Debian برای پایداری ممتاز است، Fedora برای تکنولوژی جدید عالی است، Arch برای کنترل و یادگیری عمیق است، Tumbleweed برای rolling پایدارتر عالی است، و RHEL برای سازمانها تقریباً یک معیار صنعتی است. هیچکدام «بهترینِ مطلق» نیستند؛ بهترین، تابعِ workload، تیم، و سطح تحمل ریسک است.
باورهای غلطِ خیلی رایج
یکی از مهمترین سوءبرداشتها این است که «لینوکس همان کرنل است، پس هر توزیعی یکی است». در واقع توزیعها از نظر چرخهٔ انتشار، سیاست پشتیبانی، بستهبندی، کرنل توزیعی، و حتی تجربهٔ نگهداری تفاوتهای عمیق دارند. kernel.org هم صریحاً میان upstream kernel و kernelهای توزیعی تمایز میگذارد.
باور غلط دوم این است که «rolling release یعنی unstable». این گزاره دقیق نیست. rolling release فقط یعنی انتشار نقطهای و نسخهمحورِ کلاسیک نداری؛ اما کیفیت میتواند از بسیار خوب تا ضعیف متغیر باشد. Tumbleweed با تستهای گسترده و snapshot/rollback rolling را با انضباط عملیاتی ترکیب میکند، و Arch هم هرچند rolling است، خود را یک نصب یکباره با آپدیت دائمی معرفی میکند، نه یک سیستم بیقانون.
باور غلط سوم این است که «توزیعهای enterprise کند و مردهاند». برعکس، فلسفهٔ آنها این است که patch و backport و lifecycle بلند داشته باشند تا زیر بار production قابل اتکا بمانند. چرخهٔ ۱۰سالهٔ RHEL و ۵سالهٔ Debian stable و ۱۰سالهٔ Ubuntu LTS دقیقاً برای همین ساخته شدهاند: نه برای هیجانِ نو بودن، بلکه برای پیشبینیپذیری و کاهش هزینهٔ تغییر.
باور غلط چهارم این است که «Fedora فقط یک بتاست». Fedora واقعاً fast-moving است، اما از نظر فرایند انتشار، چرخهٔ مشخص، نگهداری رسمی، و طول عمر قابلتعریف دارد. فرقش با توزیعهای محافظهکار این نیست که «ناتمام» است؛ فرقش این است که عمداً در مرزِ جدیدتر بودن حرکت میکند.
جمعبندی کاربردی
اگر هدف سرور پایدار و کمدردسر است، Debian Stable، Ubuntu LTS، RHEL، و در دنیای openSUSE، Leap انتخابهای منطقیاند. اگر هدفت دسکتاپ مدرن با اکوسیستم بزرگ است، Ubuntu LTS و Fedora معمولاً انتخابهای خیلی خوبیاند. اگر هدف تجربهٔ بهروزِ عمیق، کنترل کامل، و یادگیری جدی است، Arch یا Tumbleweed منطقیترند. و اگر هدفت چرخهٔ حیات طولانی و پشتیبانی سازمانی است، RHEL و Ubuntu LTS و Debian Stable در صدر قرار میگیرند. اینها رتبهبندی مطلق نیستند؛ نقشهٔ تناسباند.
کرنل همان موتور است، توزیع همان شاسی و سیاست رانندگی؛ و «بهترین» همیشه یعنی مناسبترین برای مسیر، نه قدرتمندترین روی کاغذ.
چرا بعضی انتخابها «خوب نیستند»
بدیِ یک توزیع معمولاً مطلق نیست؛ بد بودن وقتی رخ میدهد که مدل توزیع با نیاز واقعی تو همراستا نباشد. برای مثال، rolling release برای کسی که هر روز سیستم را نگهداری میکند و snapshot/rollback و حوصلهٔ مطالعه دارد، عالی است؛ اما برای تیمی که downtime گران است و تغییرات باید از قبل آزموده و زمانبندی شوند، مدل rolling میتواند ریسک عملیاتی اضافه کند. این نتیجهگیری از خودِ فلسفهٔ Arch و Tumbleweed و در برابر مدلهای چرخهدار مثل Debian/Ubuntu/RHEL بهدست میآید.
برعکس، انتخاب یک توزیع بسیار محافظهکار برای کسی که سختافزار جدید، درایور تازه، گرافیک نو، یا ابزارهای توسعهٔ جدید میخواهد، میتواند به معنی «عقب ماندن از اکوسیستم» باشد. Fedora با چرخهٔ سریعش دقیقاً برای همین شکاف طراحی شده، و Arch/Tumbleweed هم با هدف رساندن بستههای جدیدتر وارد عمل میشوند. بنابراین انتخاب Debian Stable یا RHEL برای یک workstation که نیازمند آخرین toolchain یا driver است، از نظر نیازمندی فنی ممکن است انتخاب ضعیفی باشد، حتی اگر از نظر پایداری عالی باشد.
یک خطای رایج دیگر این است که توزیع را فقط بر اساس «معروف بودن» انتخاب کنیم. شهرت لزوماً معادل تناسب نیست. Ubuntu بهخاطر اکوسیستم و LTS عالی است، Debian برای پایداری ممتاز است، Fedora برای تکنولوژی جدید عالی است، Arch برای کنترل و یادگیری عمیق است، Tumbleweed برای rolling پایدارتر عالی است، و RHEL برای سازمانها تقریباً یک معیار صنعتی است. هیچکدام «بهترینِ مطلق» نیستند؛ بهترین، تابعِ workload، تیم، و سطح تحمل ریسک است.
باورهای غلطِ خیلی رایج
یکی از مهمترین سوءبرداشتها این است که «لینوکس همان کرنل است، پس هر توزیعی یکی است». در واقع توزیعها از نظر چرخهٔ انتشار، سیاست پشتیبانی، بستهبندی، کرنل توزیعی، و حتی تجربهٔ نگهداری تفاوتهای عمیق دارند. kernel.org هم صریحاً میان upstream kernel و kernelهای توزیعی تمایز میگذارد.
باور غلط دوم این است که «rolling release یعنی unstable». این گزاره دقیق نیست. rolling release فقط یعنی انتشار نقطهای و نسخهمحورِ کلاسیک نداری؛ اما کیفیت میتواند از بسیار خوب تا ضعیف متغیر باشد. Tumbleweed با تستهای گسترده و snapshot/rollback rolling را با انضباط عملیاتی ترکیب میکند، و Arch هم هرچند rolling است، خود را یک نصب یکباره با آپدیت دائمی معرفی میکند، نه یک سیستم بیقانون.
باور غلط سوم این است که «توزیعهای enterprise کند و مردهاند». برعکس، فلسفهٔ آنها این است که patch و backport و lifecycle بلند داشته باشند تا زیر بار production قابل اتکا بمانند. چرخهٔ ۱۰سالهٔ RHEL و ۵سالهٔ Debian stable و ۱۰سالهٔ Ubuntu LTS دقیقاً برای همین ساخته شدهاند: نه برای هیجانِ نو بودن، بلکه برای پیشبینیپذیری و کاهش هزینهٔ تغییر.
باور غلط چهارم این است که «Fedora فقط یک بتاست». Fedora واقعاً fast-moving است، اما از نظر فرایند انتشار، چرخهٔ مشخص، نگهداری رسمی، و طول عمر قابلتعریف دارد. فرقش با توزیعهای محافظهکار این نیست که «ناتمام» است؛ فرقش این است که عمداً در مرزِ جدیدتر بودن حرکت میکند.
جمعبندی کاربردی
اگر هدف سرور پایدار و کمدردسر است، Debian Stable، Ubuntu LTS، RHEL، و در دنیای openSUSE، Leap انتخابهای منطقیاند. اگر هدفت دسکتاپ مدرن با اکوسیستم بزرگ است، Ubuntu LTS و Fedora معمولاً انتخابهای خیلی خوبیاند. اگر هدف تجربهٔ بهروزِ عمیق، کنترل کامل، و یادگیری جدی است، Arch یا Tumbleweed منطقیترند. و اگر هدفت چرخهٔ حیات طولانی و پشتیبانی سازمانی است، RHEL و Ubuntu LTS و Debian Stable در صدر قرار میگیرند. اینها رتبهبندی مطلق نیستند؛ نقشهٔ تناسباند.
کرنل همان موتور است، توزیع همان شاسی و سیاست رانندگی؛ و «بهترین» همیشه یعنی مناسبترین برای مسیر، نه قدرتمندترین روی کاغذ.
∆ Join VOID ∆
❤3
Mr. Nothing
Red Hat Enterprise Linux (RHEL) کلاس enterprise را نمایندگی میکند. مستند سیاست چرخهٔ حیات RHEL برای نسخههای ۸، ۹ و ۱۰ چرخهٔ ۱۰ سالهٔ Full Support و Maintenance Support را اعلام میکند، و Red Hat حتی برای برخی سناریوها Extended Life Cycle تا ۱۴ سال را هم…
و اگرم دیدین شخصی بشدت بر روی یک توزیع تعصب دارد
نمونه های مانند کالی لینوکس و بلک ارچ
بهش سخت نگیرید
نمونه های مانند کالی لینوکس و بلک ارچ
بهش سخت نگیرید
❤3
در کل نباید بر سیستم ها و ابزار ها تعصب داشت
آنها توسعه دیدن که مورد استفاده قرار گیرند و نیازی به تعصب ندارند
خوده بنده به شخصه ویندوز و گاها ارچ استفاده میکنم
آنها توسعه دیدن که مورد استفاده قرار گیرند و نیازی به تعصب ندارند
خوده بنده به شخصه ویندوز و گاها ارچ استفاده میکنم
❤3
part ۰
شبکه (Networking)
در مدل مرجع OSI، دادهها از لایه کاربرد (مانند HTTP، DNS) به ترتیب به لایههای انتقال (TCP/UDP)، شبکه (IP)، پیوند داده (Ethernet) و فیزیکی منتقل میشوند. برای مثال یک بسته HTTP ابتدا در لایه کاربرد ساخته شده، در لایه انتقال با سرآیند TCP یا UDP کپسوله میشود، سپس در لایه شبکه آدرسدهی IP میگردد، در لایه پیوند داده فریم Ethernet (یا Wi-Fi) را تشکیل میدهد و در نهایت به صورت سیگنال الکتریکی یا نوری منتقل میشود. به صورت ساده میتوان این مسیر را نمایش داد:
در مدل TCP/IP کاربردی هم مشابه عمل میکند با لایههای کاربرد، انتقال و اینترنت (معادل IP) و لایه لینک. تفاوت اصلی در مدل OSI، وجود لایههای «ارائه» و «نشست» است که در TCP/IP ادغام شدهاند. بسته (Packet) به واحد داده در لایه شبکه (IP Packet) و فریم (Frame) به واحد داده در لایه پیوند (مثلاً Ethernet) گفته میشود. در مسیر یابی (Routing)، روترها با بررسی آدرسهای IP مقصد، بستهها را بین شبکهها هدایت میکنند. سوئیچینگ (Switching) در لایه پیوند داده عمل میکند و بر اساس آدرسهای MAC فریمها، داده را درون شبکه محلی جابهجا میکند.
NAT/CGNAT: ترجمه آدرس شبکه (NAT) تکنیکی است که در لایه شبکه اجرا میشود تا چند میزبان خصوصی پشت یک آدرس IP عمومی قرار گیرند. CGNAT (NAT همزمان با گستره بزرگ) نسخهای از NAT است که در مقیاس اپراتورهای اینترنتی به کار میرود و چند هزار کاربر را پشت آدرسهای محدود IPv4 مشترک میکند. این فرایند شامل بازنویسی آدرس و پورت در سرآیند بستهها است و باعث میشود بستههای بازگشتی به میزبان صحیح هدایت شوند. BGP: پروتکل مسیریابی مرزها (BGP) پروتکل اصلی تبادل اطلاعات مسیریابی بین شبکههای بزرگ (AS) است. هر مسیریاب BGP فهرست پیشوندهای IP که میتواند به آنها برسد و AS راهنمای آنها را به روترهای همسایه اعلام میکند. جدول مسیریابی BGP، مسیر بهینه را بر اساس سیاستها، طول مسیر و سایر معیارها انتخاب میکند.
DNS: سامانه نام دامنه (DNS) نامهای متنی (مثلاً
TLS (نسلکار امنیت لایه حمل و نقل): در TLS 1.2 و قبل، پیام ClientHello (شامل SNI) به صورت متن ساده ارسال میشد. در TLS 1.3، بخش اعظم دستدهی (ClientHello) رمزنگاری شدهاست، اما برخی پارامترهای اولیه (مانند ورژنها) از مقادیری مشتق شده از اطلاعات قابل مشاهده است. در دستدهی TLS 1.3، مشتری پارامترهای رمزگذاری، و نام دامنه (در صورت فعال بودن ECH غیرمعمول) را ارسال میکند. یک تجهیزات DPI میتواند پارامترهایی چون نسخه TLS، فهرست Cipher Suiteها و فرمت ClientHello را تحلیل کند (معروف به اثر انگشت TLS یا JA3) و حدس بزند از چه نرمافزار/سیستمی استفاده میشود. TLS به طور کلی بر بستر TCP یا QUIC (TLS 1.3 روی QUIC) کار میکند. در TLS 1.3، برای رزومه جلسه نیز بلیتی مبادله میشود که در بازگشایی مجدد ارتباط مفید است.
شبکه (Networking)
در مدل مرجع OSI، دادهها از لایه کاربرد (مانند HTTP، DNS) به ترتیب به لایههای انتقال (TCP/UDP)، شبکه (IP)، پیوند داده (Ethernet) و فیزیکی منتقل میشوند. برای مثال یک بسته HTTP ابتدا در لایه کاربرد ساخته شده، در لایه انتقال با سرآیند TCP یا UDP کپسوله میشود، سپس در لایه شبکه آدرسدهی IP میگردد، در لایه پیوند داده فریم Ethernet (یا Wi-Fi) را تشکیل میدهد و در نهایت به صورت سیگنال الکتریکی یا نوری منتقل میشود. به صورت ساده میتوان این مسیر را نمایش داد:
diff
+-----------------------------+
| لایه کاربرد (HTTP, DNS...) |
+-----------------------------+
| لایه انتقال (TCP/UDP) |
+-----------------------------+
| لایه شبکه (IP) |
+-----------------------------+
| لایه پیوند داده (فریمها) |
+-----------------------------+
| لایه فیزیکی (بیتها) |
+-----------------------------+
در مدل TCP/IP کاربردی هم مشابه عمل میکند با لایههای کاربرد، انتقال و اینترنت (معادل IP) و لایه لینک. تفاوت اصلی در مدل OSI، وجود لایههای «ارائه» و «نشست» است که در TCP/IP ادغام شدهاند. بسته (Packet) به واحد داده در لایه شبکه (IP Packet) و فریم (Frame) به واحد داده در لایه پیوند (مثلاً Ethernet) گفته میشود. در مسیر یابی (Routing)، روترها با بررسی آدرسهای IP مقصد، بستهها را بین شبکهها هدایت میکنند. سوئیچینگ (Switching) در لایه پیوند داده عمل میکند و بر اساس آدرسهای MAC فریمها، داده را درون شبکه محلی جابهجا میکند.
NAT/CGNAT: ترجمه آدرس شبکه (NAT) تکنیکی است که در لایه شبکه اجرا میشود تا چند میزبان خصوصی پشت یک آدرس IP عمومی قرار گیرند. CGNAT (NAT همزمان با گستره بزرگ) نسخهای از NAT است که در مقیاس اپراتورهای اینترنتی به کار میرود و چند هزار کاربر را پشت آدرسهای محدود IPv4 مشترک میکند. این فرایند شامل بازنویسی آدرس و پورت در سرآیند بستهها است و باعث میشود بستههای بازگشتی به میزبان صحیح هدایت شوند. BGP: پروتکل مسیریابی مرزها (BGP) پروتکل اصلی تبادل اطلاعات مسیریابی بین شبکههای بزرگ (AS) است. هر مسیریاب BGP فهرست پیشوندهای IP که میتواند به آنها برسد و AS راهنمای آنها را به روترهای همسایه اعلام میکند. جدول مسیریابی BGP، مسیر بهینه را بر اساس سیاستها، طول مسیر و سایر معیارها انتخاب میکند.
DNS: سامانه نام دامنه (DNS) نامهای متنی (مثلاً
example.com) را به آدرسهای IP متناظر تبدیل میکند. در شبکههای امروزی، انواع جدیدی از DNS رمزنگاریشده رایج شدهاند: DNS-over-UDP/TCP سنتی روی پورت 53 (متن ساده)، DNS-over-TLS (DoT) روی پورت 853، DNS-over-HTTPS (DoH) روی پورت 443 (که درون ترافیک HTTPS پنهان میشود) و DNS-over-QUIC (DoQ) که در پروتکل QUIC انجام میشود. علاوه بر این، در TLS 1.3 فنّاوری ECH (Encrypted Client Hello) معرفی شده که امکان رمزکردن کاملاً کلاینتهلوی TLS (به جز بخش ثابت اولیه) را فراهم میکند. SNI (Server Name Indication) بخشی از Client Hello در TLS 1.3 و پیشتر بود که نام دامنه مقصد (میزبان) را به صورت شفاف ارسال میکرد. نسخههای اولیه ESNI (Encrypted SNI) و سپس ECH کوشیدند این نشت اطلاعات را بپوشانند. بدون ECH، SNI به صورت متن ساده ارسال میشود و فایروالهای سازمانی یا دولتی میتوانند بر اساس آن دامنهها را فیلتر کنند.TLS (نسلکار امنیت لایه حمل و نقل): در TLS 1.2 و قبل، پیام ClientHello (شامل SNI) به صورت متن ساده ارسال میشد. در TLS 1.3، بخش اعظم دستدهی (ClientHello) رمزنگاری شدهاست، اما برخی پارامترهای اولیه (مانند ورژنها) از مقادیری مشتق شده از اطلاعات قابل مشاهده است. در دستدهی TLS 1.3، مشتری پارامترهای رمزگذاری، و نام دامنه (در صورت فعال بودن ECH غیرمعمول) را ارسال میکند. یک تجهیزات DPI میتواند پارامترهایی چون نسخه TLS، فهرست Cipher Suiteها و فرمت ClientHello را تحلیل کند (معروف به اثر انگشت TLS یا JA3) و حدس بزند از چه نرمافزار/سیستمی استفاده میشود. TLS به طور کلی بر بستر TCP یا QUIC (TLS 1.3 روی QUIC) کار میکند. در TLS 1.3، برای رزومه جلسه نیز بلیتی مبادله میشود که در بازگشایی مجدد ارتباط مفید است.
❤2
HTTP/2 و HTTP/3: HTTP/2 یک پروتکل باینری روی TCP/ TLS است که امکان چندکارگی (multiplexing) و فشردهسازی هدر را دارد. HTTP/3 عملاً HTTP/2 روی QUIC است و از قابلیتهای QUIC مانند تأخیر یک مرحلهای (0-RTT) و بهبود سرعت ارتباط بهره میبرد. در HTTP/3، کل دستدادها رمزنگاری است ولی همچنان SNI میتواند نشت شود (مگر از ECH استفاده شود). به دلیل رمزنگاری سرآیندها، DPIها دیگر نمیتوانند مستقیم محتوا یا URLها را ببینند؛ تنها فیلدهای اولیه نظیر SNI یا الگوهای ترافیکی (اندازه بسته، و تعداد پکت) باقی میماند.
UDP و TCP: در TCP برقراری اتصال سهمرحلهای (سهراهه: SYN, SYN/ACK, ACK) وجود دارد و تضمین تحویل دادهها با مکانیزم بازفرست (RETRANSMISSION) انجام میشود. UDP پروتکلی بدون اتصال و فاقد کنترل خطاست؛ در UDP هر بستهی مستقل فرستاده میشود و ترتیب یا تضمین رسیدن آن بر عهده پروتکل اپلیکیشن یا بالاسری است. جریانهای TCP میتوانند توسط DPI مانیتور و با TCP RST (قطع ارتباط) مسدود شوند، ولی UDP در برابر RST بیتاثیر است (مگر پکتهای UDP خود مسدود شوند).
مهندسی ترافیک (Traffic Engineering): در شبکههای بزرگ از تکنیکهای TE استفاده میشود تا ترافیک از مسیرهای مطلوب عبور کند (مثلاً MPLS-TE، RSVP-TE) تا سربار شبکه متعادل شود. در این زمینه ممکن است مسیرهای از پیش تعیین شده یا سوئیچینگ مبتنی بر MPLS به کار رود. اشاره به این موضوع فراتر از بحث DPI/فیلترینگ است، ولی در اینجا باید دانست که شبکههای ISP و CDNها (محتوا) مسیر ترافیک را بهینه میکنند تا تاخیر و ترافیک را کاهش دهند. DPIهای مدرن نیز گاهی در کنار سیستمهای TE قرار میگیرند تا ترافیکهای حساس را کنترل کنند بدون آنکه کل لینک اشباع شود.
Fingerprinting (اثر انگشت ترافیک): در سطوح مختلف شبکه میتوان ترافیک را با الگوهای خاص شناسایی کرد. برای مثال، ترکیبهای نسخه و Cipher Suite در دستدهی TLS میتواند اپلیکیشن یا سیستمعامل را حدس بزند. همینطور، الگوریتمهای شناسایی آماری و رفتاری روی حجم، الگوی زمانی و جهت بستهها، روش دیگری برای ردیابی خدمات است. در لایه TCP/IP هم نوع بسته (TCP vs UDP)، پورتهای غیرمعمول یا اجزای ثابت سرآیند میتواند به عنوان اثرانگشت عمل کند؛ برای نمونه Wireshark میتواند با تحلیل توالی دستدادهای TCP کاسته نشده، تفاوت سیستم عاملها را تشخیص دهد. این تکنیکها پایه DPI اند تا پروتکلها یا برنامهها را «اثر انگشت» بزنند و در صورت لزوم مسدود یا محدود کنند.
VPN
PPTP: یک پروتکل قدیمی VPN که از PPP و تونلسازی GRE (پروتکل 47) استفاده میکند. پس از برقراری ارتباط TCP روی پورت 1723 برای فرماندهی، ترافیک کاربر در تونل GRE عبور میکند و با رمزنگاری MPPE (معمولاً RC4 128) حفاظت میشود. معماری سادهای دارد، اما امنیت ضعیفی دارد (MPPE تراست ندارد و آسیبپذیریهای متعددی دارد). DPI به راحتی PPTP را تشخیص میدهد چون بستههای GRE مشخصاند و به سختی پنهان میشوند. PPTP در برابر فیلترینگ مقاوم نیست و در بسیاری نقاط (از جمله چین و ایران) بدون مشکل مسدود میشود.
L2TP/IPsec: شامل دو بخش است: L2TP خود تنها ارتباط نقطهبهنقطه را روی UDP (پورت 1701) فراهم میکند و معمولاً با IPsec ترکیب میشود تا رمزنگاری لازم فراهم آید. معماری معمولاً از IKE (پورت 500 UDP) برای تبادل کلید استفاده میکند و پس از آن مجموعه SA (اهداف امنیتی) برای ESP (پروتکل 50 IP) و AH (51 IP) برقرار میشود. رمزنگاری قوی (AES, 3DES) به کار میرود. DPI میتواند L2TP/IPsec را با نگاه به بستههای IKE (تبادل پورتها و پیامهای شناختهشده) تشخیص دهد. مقاومت در برابر فیلترینگ متوسط است؛ چون ترافیک رمزنگاریشده است، اما پروتکلها و پورتهای خاص قابل شناساییاند. حملات فعال یا پیکربندی نادرست ممکن است منجر به ردیابی شود.
UDP و TCP: در TCP برقراری اتصال سهمرحلهای (سهراهه: SYN, SYN/ACK, ACK) وجود دارد و تضمین تحویل دادهها با مکانیزم بازفرست (RETRANSMISSION) انجام میشود. UDP پروتکلی بدون اتصال و فاقد کنترل خطاست؛ در UDP هر بستهی مستقل فرستاده میشود و ترتیب یا تضمین رسیدن آن بر عهده پروتکل اپلیکیشن یا بالاسری است. جریانهای TCP میتوانند توسط DPI مانیتور و با TCP RST (قطع ارتباط) مسدود شوند، ولی UDP در برابر RST بیتاثیر است (مگر پکتهای UDP خود مسدود شوند).
مهندسی ترافیک (Traffic Engineering): در شبکههای بزرگ از تکنیکهای TE استفاده میشود تا ترافیک از مسیرهای مطلوب عبور کند (مثلاً MPLS-TE، RSVP-TE) تا سربار شبکه متعادل شود. در این زمینه ممکن است مسیرهای از پیش تعیین شده یا سوئیچینگ مبتنی بر MPLS به کار رود. اشاره به این موضوع فراتر از بحث DPI/فیلترینگ است، ولی در اینجا باید دانست که شبکههای ISP و CDNها (محتوا) مسیر ترافیک را بهینه میکنند تا تاخیر و ترافیک را کاهش دهند. DPIهای مدرن نیز گاهی در کنار سیستمهای TE قرار میگیرند تا ترافیکهای حساس را کنترل کنند بدون آنکه کل لینک اشباع شود.
Fingerprinting (اثر انگشت ترافیک): در سطوح مختلف شبکه میتوان ترافیک را با الگوهای خاص شناسایی کرد. برای مثال، ترکیبهای نسخه و Cipher Suite در دستدهی TLS میتواند اپلیکیشن یا سیستمعامل را حدس بزند. همینطور، الگوریتمهای شناسایی آماری و رفتاری روی حجم، الگوی زمانی و جهت بستهها، روش دیگری برای ردیابی خدمات است. در لایه TCP/IP هم نوع بسته (TCP vs UDP)، پورتهای غیرمعمول یا اجزای ثابت سرآیند میتواند به عنوان اثرانگشت عمل کند؛ برای نمونه Wireshark میتواند با تحلیل توالی دستدادهای TCP کاسته نشده، تفاوت سیستم عاملها را تشخیص دهد. این تکنیکها پایه DPI اند تا پروتکلها یا برنامهها را «اثر انگشت» بزنند و در صورت لزوم مسدود یا محدود کنند.
VPN
PPTP: یک پروتکل قدیمی VPN که از PPP و تونلسازی GRE (پروتکل 47) استفاده میکند. پس از برقراری ارتباط TCP روی پورت 1723 برای فرماندهی، ترافیک کاربر در تونل GRE عبور میکند و با رمزنگاری MPPE (معمولاً RC4 128) حفاظت میشود. معماری سادهای دارد، اما امنیت ضعیفی دارد (MPPE تراست ندارد و آسیبپذیریهای متعددی دارد). DPI به راحتی PPTP را تشخیص میدهد چون بستههای GRE مشخصاند و به سختی پنهان میشوند. PPTP در برابر فیلترینگ مقاوم نیست و در بسیاری نقاط (از جمله چین و ایران) بدون مشکل مسدود میشود.
L2TP/IPsec: شامل دو بخش است: L2TP خود تنها ارتباط نقطهبهنقطه را روی UDP (پورت 1701) فراهم میکند و معمولاً با IPsec ترکیب میشود تا رمزنگاری لازم فراهم آید. معماری معمولاً از IKE (پورت 500 UDP) برای تبادل کلید استفاده میکند و پس از آن مجموعه SA (اهداف امنیتی) برای ESP (پروتکل 50 IP) و AH (51 IP) برقرار میشود. رمزنگاری قوی (AES, 3DES) به کار میرود. DPI میتواند L2TP/IPsec را با نگاه به بستههای IKE (تبادل پورتها و پیامهای شناختهشده) تشخیص دهد. مقاومت در برابر فیلترینگ متوسط است؛ چون ترافیک رمزنگاریشده است، اما پروتکلها و پورتهای خاص قابل شناساییاند. حملات فعال یا پیکربندی نادرست ممکن است منجر به ردیابی شود.
❤2
part2
SSTP: پروتکل VPN مایکروسافت که از TLS 1.x (روی TCP/443) برای تونلسازی استفاده میکند. پس از برقراری TCP، handshake TLS انجام میشود، و سپس ترافیک PPP/PPPoe یا IPSec tunneled درون TLS. از نظر معماری، SSTP از پورت امن HTTPS بهره میبرد. نحوه رمزنگاری و تبادل کلید همان TLS است (گواهیهای X.509، RSA/DH). مزیت بزرگ SSTP امکان عبور از فایروالهای بسته به پورت است (چون مشابه HTTPS است). معایب: صرفاً ویندوزی است (مایکروسافت) و در بین جامعه open-source کم استفاده است. DPI به سختی SSTP را از HTTPS واقعی تشخیص میدهد (مثل Trojan)، مگر اینکه گواهی/سرآیند غیرمعمولی داشته باشد. بنابراین مقاومت خوبی در برابر فیلترینگ دارد (در عمل گاهی سانسورها SSTP را به عنوان HTTPS باز میگذارند).
OpenVPN: یکی از محبوبترین VPNهای متنباز. معماری معمولاً بر پایه TLS (نسخه 1.2 یا 1.3) است، استفاده از UDP یا TCP (پورت پیشفرض UDP 1194 یا TCP 443). کلیدها توسط TLS DHE/ECDHE مبادله شده و دادهها با AES/GCM (یا BF/CBC) رمز میشود. handshake اولیه TLS، به علاوه تبادل کلید (Certificate) صورت میگیرد. مزایا: امنیت بالا (بسته به تنظیمات)، پیکربندی انعطافپذیر، جامعه بزرگ، پشتیبانی از چند پلتفرم. معایب: سربار TLS و مدیریت گواهیها. DPI معمولاً OpenVPN را شناسایی میکند: محققان نشان دادهاند که بستههای اولیه و اندازه پاسخها الگو دارد و میتوان پروتکل را اثرانگشتگذاری کرد (مثلاً یک مطالعه USENIX نشان داد با تحلیل الگوها >85% اتصالات OpenVPN شناسایی میشوند). همچنین چون سرآیند TLS و حداکثر طول بسته مشخصی دارد، DPI میتواند دستورات خاص OpenVPN (opcode patterns) را ببیند. به دلیل استفاده از TLS و امکان فعالیت روی پورت 443، مقاومت OpenVPN در برابر فیلترینگ متوسط است: اگر DPI را قانع کنیم یا ترافیک را تغییر دهیم (مثلاً پراکسی کردن در پشت HTTPS) بهتر میشود، اما در حالت عادی ممکن است مسدود شود.
WireGuard: یک VPN جدید و سبکوزن مبتنی بر کرنل (که از UDP 51820 پیشفرض استفاده میکند). معماری دارای جفت کلیدهای عمومی/خصوصی است و بر پایه مبادله پیامهای کلاینت و سرور (handshake Noise Protocol) عمل میکند. دستداد اول شامل یک مقدار ثابت 4 بایتی، و دو MAC 16 بایتی (MAC1، MAC2) است (که در ابتدا صفر هستند). مزایا: ساده، سریع، رمزنگاری مدرن (ChaCha20+Poly1305)، احراز هویت کلید عموم، تأخیر کم. معایب: اتصال فقط UDP، قابلیت NAT traversal نیازمند کار اضافی (دانگلها)، سرویس رایگان DNS ندارد. DPI به راحتی WireGuard را شناسایی میکند: هر دستداد WireGuard یک بسته UDP با 3 بایت رزرو صفر و دو فیلد MAC صفر در ابتدای آن دارد؛ همین الگوی یکتا باعث میشود دستگاههای DPI شناسایی آسانی از آن داشته باشند. مقاومت در برابر فیلترینگ ضعیف است؛ به عبارتی بدون روشهای مسدود سازی (مثلاً obfuscation) فیلترها بهراحتی با شناسایی بایتهای خاص WireGuard میتوانند آن را مسدود کنند.
SoftEther: یک سویت VPN چندپروتکل (موسوم VPN Gate) است که میتواند جایگزین پروتکلهای مختلف شود. میتواند به صورت HTTPS ترافیک را تونل کند یا پروتکلهای VPN سنتی را فراهم کند. مزایا: بسیار چندمنظوره (پشتیبانی از L2TP/IPsec, OpenVPN, SSTP و …)، گرافیک کاربرپسند، OSS و پرتوان. معایب: تقریباً شناساییپذیر از طریق اثرانگشت TLS است. مایکروسافت گزارش داد به سختی میتوان ترافیک SoftEther را از HTTPS تمییز داد، اما تحقیقات اخیر نشان میدهد SoftEther بهخاطر نحوه ساخت گواهیهای TLS خود یک اثرانگشت JA4X منحصربهفرد دارد که میتواند باعث شناسایی آن شود. بنابراین DPIهای پیشرفته میتوانند با استفاده از همین اثر انگشت خاص، ترافیک SoftEther را تشخیص داده و مسدود کنند.
Outline: فریمورک VPN توسط Jigsaw است که در پسزمینه از پروتکل Shadowsocks استفاده میکند. ساختار ساده دارد: یک سرور Shadowsocks و مدیریت سرور (Outline Manager) برای پیکربندی. نحوه رمزنگاری و کلید مشابه Shadowsocks است. مزایا: سادگی نصب برای کاربران معمولی، متن باز. معایب: وابسته به Shadowsocks (بنابراین معایب Shadowsocks را دارد). DPI میتواند Outline را مثل Shadowsocks تشخیص دهد. مثلاً گزارش شده که GFW چین Shadowsocks و Outline را در کنار هم آزموده است (چون هر دو پروتکل مشابهی دارند). مقاومت Outline در برابر فیلترینگ مشابه Shadowsocks است: اگر فعال probing Shadowsocks کار کند، Outline هم در خطر است.
OpenConnect (دلیل ذکر): اشاره شده که Active probing در ایران مثلاً برای OpenConnect (پروتکل شرکت سیسکو) دیده نشده؛ اینجا لازم نیست چون موضوع اصلی VPNهای بالا بود.
برای هر VPN، روش تشخیص DPI به الگوی ارتباطی آن بستگی دارد. به طور خلاصه:
SSTP: پروتکل VPN مایکروسافت که از TLS 1.x (روی TCP/443) برای تونلسازی استفاده میکند. پس از برقراری TCP، handshake TLS انجام میشود، و سپس ترافیک PPP/PPPoe یا IPSec tunneled درون TLS. از نظر معماری، SSTP از پورت امن HTTPS بهره میبرد. نحوه رمزنگاری و تبادل کلید همان TLS است (گواهیهای X.509، RSA/DH). مزیت بزرگ SSTP امکان عبور از فایروالهای بسته به پورت است (چون مشابه HTTPS است). معایب: صرفاً ویندوزی است (مایکروسافت) و در بین جامعه open-source کم استفاده است. DPI به سختی SSTP را از HTTPS واقعی تشخیص میدهد (مثل Trojan)، مگر اینکه گواهی/سرآیند غیرمعمولی داشته باشد. بنابراین مقاومت خوبی در برابر فیلترینگ دارد (در عمل گاهی سانسورها SSTP را به عنوان HTTPS باز میگذارند).
OpenVPN: یکی از محبوبترین VPNهای متنباز. معماری معمولاً بر پایه TLS (نسخه 1.2 یا 1.3) است، استفاده از UDP یا TCP (پورت پیشفرض UDP 1194 یا TCP 443). کلیدها توسط TLS DHE/ECDHE مبادله شده و دادهها با AES/GCM (یا BF/CBC) رمز میشود. handshake اولیه TLS، به علاوه تبادل کلید (Certificate) صورت میگیرد. مزایا: امنیت بالا (بسته به تنظیمات)، پیکربندی انعطافپذیر، جامعه بزرگ، پشتیبانی از چند پلتفرم. معایب: سربار TLS و مدیریت گواهیها. DPI معمولاً OpenVPN را شناسایی میکند: محققان نشان دادهاند که بستههای اولیه و اندازه پاسخها الگو دارد و میتوان پروتکل را اثرانگشتگذاری کرد (مثلاً یک مطالعه USENIX نشان داد با تحلیل الگوها >85% اتصالات OpenVPN شناسایی میشوند). همچنین چون سرآیند TLS و حداکثر طول بسته مشخصی دارد، DPI میتواند دستورات خاص OpenVPN (opcode patterns) را ببیند. به دلیل استفاده از TLS و امکان فعالیت روی پورت 443، مقاومت OpenVPN در برابر فیلترینگ متوسط است: اگر DPI را قانع کنیم یا ترافیک را تغییر دهیم (مثلاً پراکسی کردن در پشت HTTPS) بهتر میشود، اما در حالت عادی ممکن است مسدود شود.
WireGuard: یک VPN جدید و سبکوزن مبتنی بر کرنل (که از UDP 51820 پیشفرض استفاده میکند). معماری دارای جفت کلیدهای عمومی/خصوصی است و بر پایه مبادله پیامهای کلاینت و سرور (handshake Noise Protocol) عمل میکند. دستداد اول شامل یک مقدار ثابت 4 بایتی، و دو MAC 16 بایتی (MAC1، MAC2) است (که در ابتدا صفر هستند). مزایا: ساده، سریع، رمزنگاری مدرن (ChaCha20+Poly1305)، احراز هویت کلید عموم، تأخیر کم. معایب: اتصال فقط UDP، قابلیت NAT traversal نیازمند کار اضافی (دانگلها)، سرویس رایگان DNS ندارد. DPI به راحتی WireGuard را شناسایی میکند: هر دستداد WireGuard یک بسته UDP با 3 بایت رزرو صفر و دو فیلد MAC صفر در ابتدای آن دارد؛ همین الگوی یکتا باعث میشود دستگاههای DPI شناسایی آسانی از آن داشته باشند. مقاومت در برابر فیلترینگ ضعیف است؛ به عبارتی بدون روشهای مسدود سازی (مثلاً obfuscation) فیلترها بهراحتی با شناسایی بایتهای خاص WireGuard میتوانند آن را مسدود کنند.
SoftEther: یک سویت VPN چندپروتکل (موسوم VPN Gate) است که میتواند جایگزین پروتکلهای مختلف شود. میتواند به صورت HTTPS ترافیک را تونل کند یا پروتکلهای VPN سنتی را فراهم کند. مزایا: بسیار چندمنظوره (پشتیبانی از L2TP/IPsec, OpenVPN, SSTP و …)، گرافیک کاربرپسند، OSS و پرتوان. معایب: تقریباً شناساییپذیر از طریق اثرانگشت TLS است. مایکروسافت گزارش داد به سختی میتوان ترافیک SoftEther را از HTTPS تمییز داد، اما تحقیقات اخیر نشان میدهد SoftEther بهخاطر نحوه ساخت گواهیهای TLS خود یک اثرانگشت JA4X منحصربهفرد دارد که میتواند باعث شناسایی آن شود. بنابراین DPIهای پیشرفته میتوانند با استفاده از همین اثر انگشت خاص، ترافیک SoftEther را تشخیص داده و مسدود کنند.
Outline: فریمورک VPN توسط Jigsaw است که در پسزمینه از پروتکل Shadowsocks استفاده میکند. ساختار ساده دارد: یک سرور Shadowsocks و مدیریت سرور (Outline Manager) برای پیکربندی. نحوه رمزنگاری و کلید مشابه Shadowsocks است. مزایا: سادگی نصب برای کاربران معمولی، متن باز. معایب: وابسته به Shadowsocks (بنابراین معایب Shadowsocks را دارد). DPI میتواند Outline را مثل Shadowsocks تشخیص دهد. مثلاً گزارش شده که GFW چین Shadowsocks و Outline را در کنار هم آزموده است (چون هر دو پروتکل مشابهی دارند). مقاومت Outline در برابر فیلترینگ مشابه Shadowsocks است: اگر فعال probing Shadowsocks کار کند، Outline هم در خطر است.
OpenConnect (دلیل ذکر): اشاره شده که Active probing در ایران مثلاً برای OpenConnect (پروتکل شرکت سیسکو) دیده نشده؛ اینجا لازم نیست چون موضوع اصلی VPNهای بالا بود.
برای هر VPN، روش تشخیص DPI به الگوی ارتباطی آن بستگی دارد. به طور خلاصه:
❤2
VPNهای TCP/TLS (OpenVPN, SSTP, SoftEther): DPI با تحلیل TLS یا الگوی دستداد میتواند آنها را شناسایی کند، مگر اینکه ترافیک را با روشهایی چون obfsproxy مخفی کنند.
VPNهای UDP (WireGuard، OpenVPN UDP): بایتهای ثابت پیامها (WireGuard) یا سرآیند UDP خاص (OpenVPN 59-byte جهت کلاینتHello) اثرانگشت ایجاد میکنند.
VPNهای قدیمی (PPTP, L2TP): چون از پروتکلهای متفاوتی (GRE و ESP) استفاده میکنند، DPI میتواند آنها را سریع تشخیص دهد.
استقامت در برابر فیلترینگ: PPTP و L2TP که بر استانداردهای قدیمی متکیاند تقریباً مسدود میشوند. OpenVPN/TCP و SSTP از پورت 443 استفاده میکنند و اگر ترافیک TLS آنها عادی به نظر برسد معمولاً عبور میکنند، ولی فیلترهای عمیق ممکن است بستههای خاص آنها را تشخیص داده و ببندند. WireGuard و پروتکلهای جدید UDP به طور پیشفرض ضعیفاند مگر آنکه راههای حفاظت اضافی (مانند UDP سادهتر یا پوشاندن ترافیک) اعمال شود.
DNS و رمزنگاری آن
DNS سنتی: درخواستهای DNS معمولاً روی پورت 53/UDP ارسال میشوند و نام و پرسش به صورت متن ساده در بسته درج میشود. سانسورها میتوانند این بستهها را سوزانده، پاسخهای جعلی (cache poisoning) برگردانند یا دامنهها را در مسیریابها تغییر دهند. روشهایی مانند DNS poisoning (بازنویسی پاسخ) یا DNS Hijacking (ارسال پاسخ به سرور تقلبی) استفاده میشود تا به دامنههای مسدود شده پاسخ نادرست داده شود.
DNS-over-TLS (DoT): در این روش، پرسش DNS در یک جلسه TLS معمولاً روی پورت TCP/853 ارسال میشود. رمزنگاری بالای UDP سنتی قرار میگیرد. DPI میتواند با مشاهده پورت 853 یا SNI در آغاز TLS آن را تشخیص دهد (معمولاً دامنهای ثابت مثل
DNS-over-HTTPS (DoH): DNS پرسشها را در قالب درخواست HTTPS (HTTP/2 یا HTTP/3) روی پورت 443 میفرستد. محتوای آن رمزنگاری است و حتی SNI ممکن است به نام DNS معمول نباشد. در عمل، DoH معمولاً به سرویسی خاص اشاره میکند (مثلاً Google
DNS-over-QUIC (DoQ): مشابه DoH اما روی پروتکل QUIC. چون QUIC پیام دستدهی خود را رمز میکند (بجای TLS روی TCP)، ترافیک DoQ نیز در نگاه اول شبیه HTTP/3 روی UDP است. با این حال، میتوان پورت 853 (QUIC DoT) یا فرآیندهای ویژهی دستدهی QUIC را برای تشخیص به کار برد.
Encrypted Client Hello (ECH): تکنیکی برای رمز کردن کلاینتهلوی TLS است (از جمله SNI). برای شروع ارتباط ECH، کلاینت نیاز به دریافت ECH Config از DNS دارد (مثلاً دامنهای مثل
VPNهای UDP (WireGuard، OpenVPN UDP): بایتهای ثابت پیامها (WireGuard) یا سرآیند UDP خاص (OpenVPN 59-byte جهت کلاینتHello) اثرانگشت ایجاد میکنند.
VPNهای قدیمی (PPTP, L2TP): چون از پروتکلهای متفاوتی (GRE و ESP) استفاده میکنند، DPI میتواند آنها را سریع تشخیص دهد.
استقامت در برابر فیلترینگ: PPTP و L2TP که بر استانداردهای قدیمی متکیاند تقریباً مسدود میشوند. OpenVPN/TCP و SSTP از پورت 443 استفاده میکنند و اگر ترافیک TLS آنها عادی به نظر برسد معمولاً عبور میکنند، ولی فیلترهای عمیق ممکن است بستههای خاص آنها را تشخیص داده و ببندند. WireGuard و پروتکلهای جدید UDP به طور پیشفرض ضعیفاند مگر آنکه راههای حفاظت اضافی (مانند UDP سادهتر یا پوشاندن ترافیک) اعمال شود.
DNS و رمزنگاری آن
DNS سنتی: درخواستهای DNS معمولاً روی پورت 53/UDP ارسال میشوند و نام و پرسش به صورت متن ساده در بسته درج میشود. سانسورها میتوانند این بستهها را سوزانده، پاسخهای جعلی (cache poisoning) برگردانند یا دامنهها را در مسیریابها تغییر دهند. روشهایی مانند DNS poisoning (بازنویسی پاسخ) یا DNS Hijacking (ارسال پاسخ به سرور تقلبی) استفاده میشود تا به دامنههای مسدود شده پاسخ نادرست داده شود.
DNS-over-TLS (DoT): در این روش، پرسش DNS در یک جلسه TLS معمولاً روی پورت TCP/853 ارسال میشود. رمزنگاری بالای UDP سنتی قرار میگیرد. DPI میتواند با مشاهده پورت 853 یا SNI در آغاز TLS آن را تشخیص دهد (معمولاً دامنهای ثابت مثل
cloudflare-dns.com). اگر SNI رمزنگاری نشده باشد، فیلتر میتواند نام سرویس DNS را مسدود کند. البته روی HTTPS معمولی امکان مانع است.DNS-over-HTTPS (DoH): DNS پرسشها را در قالب درخواست HTTPS (HTTP/2 یا HTTP/3) روی پورت 443 میفرستد. محتوای آن رمزنگاری است و حتی SNI ممکن است به نام DNS معمول نباشد. در عمل، DoH معمولاً به سرویسی خاص اشاره میکند (مثلاً Google
dns.google یا Cloudflare). چون همه ترافیک روی پورت 443 است، DPI دشوار است مگر اینکه SNI و URL پنهان را بشناسد. اگر شرکتها SNI پیشفرضِ DNS (مثلاً mozilla.cloudflare-dns.com) استفاده کنند، سانسورها میتوانند آن را مسدود کنند؛ اما اگر از دامنه غیرمعمول یا ECH استفاده شود، تشخیص دشوارتر میشود. یک چالش این است که مرورگرها معمولاً برای شروع DoH نیاز به یک پرسش DNS اولیه (غیر رمز) دارند تا آدرس resolver را بیابند؛ این پرسش اولیه خود ممکن است مسدود شود.DNS-over-QUIC (DoQ): مشابه DoH اما روی پروتکل QUIC. چون QUIC پیام دستدهی خود را رمز میکند (بجای TLS روی TCP)، ترافیک DoQ نیز در نگاه اول شبیه HTTP/3 روی UDP است. با این حال، میتوان پورت 853 (QUIC DoT) یا فرآیندهای ویژهی دستدهی QUIC را برای تشخیص به کار برد.
Encrypted Client Hello (ECH): تکنیکی برای رمز کردن کلاینتهلوی TLS است (از جمله SNI). برای شروع ارتباط ECH، کلاینت نیاز به دریافت ECH Config از DNS دارد (مثلاً دامنهای مثل
ech-alpn.cloudflare.com) که نشان میدهد سرویسدهنده از ECH پشتیبانی میکند. اگر DNS مسدود باشد، ECH شکست میخورد. پژوهشی در PETS نشان داد که برای برقراری ECH، کاربر باید DNS رمزنگاریشده (DoH/DoT/DoQ) برای پرسش ECH config استفاده کند؛ DoT/DoQ به دلیل پورت 853 قابل شناسایی هستند، اما DoH روی 443 معمولی است. علاوه بر این، در TLS/TCP (HTTP/2) نام SNI در ClientHello معمولاً به صورت متن ساده ارسال میشود. قبل از ECH، تلاشهایی تحت عنوان ESNI انجام شده که صرفاً بخش SNI را رمز میکرد، اما چین از سال 2020 شروع به مسدودسازی ESNI کرد (بدون توجه به اینکه دامنه چه هست).❤2
part3:
مسدودسازی توسط سانسورها: سیستمهای سانسور میتوانند DNS را با روشهای زیر محدود کنند: در لایه شبکه، ترافیک DNS را مقایسه یا دستکاری میکنند (DNS Poisoning/Manipulation)، یا در لایه IP مسیرها را مسدود میکنند تا بستههای DNS اصلاً به بیرون نرسند. ASN یا بلوکهای IP ارائهدهندگان DNS عمومی (مانند گوگل یا کلودفلر) ممکن است کلی مسدود شود. علاوه بر این، با فعال کردن DPI روی ترافیک TLS، نام SNI و حتا برخی متادیتای پنهان TLS بررسی میشود تا ارتباطات مشکوک مسدود شود. در نهایت، حجم زیادی از مسدودسازیهای زبانی قدیمی مانند DNS-to-HTTP or TCP-resetها میتواند منجر به جلوگیری از دسترسی به resolverها شود.
V2Ray و Xray
معماری کلی V2Ray/Xray: پلتفرم V2Ray (و شاخه پیشرفتهتر Xray با توسعههای جدید) معماری مدولار دارد: چند پروتکل ورودی (Inbound) میتواند همزمان اجرا شود (مثلاً یک سرور همزمان پروتکلهای VMess و Shadowsocks و SOCKS را بپذیرد) و هر کدام یک یا چند لایه ترنسپورت (TCP, UDP, QUIC, WS, gRPC و…) دارد. سپس مولفه Routing تصمیم میگیرد ترافیک ورودی چگونه به خروجی (Outbound) هدایت شود (مثلاً بر اساس دامنه، IP مقصد، موقعیت جغرافیایی، یا قواعد کاربر). به طور کلی V2Ray دارای سه بلوک اصلی است: Inbounds (پروکسیهایی که ترافیک را دریافت میکنند)، Outbounds (ترافیکی که به شبکه میفرستند)، و Routing که بین آنها وصل میکند. هر مؤلفه قابل پیکربندی جداگانه است. برای مثال، مستند V2Fly ذکر میکند یک فرآیند V2Ray میتواند به طور همزمان چندین پروتکل ورودی/خروجی داشته باشد و ترافیک را بر اساس پیکربندی (مثل تقسیم بر اساس منطقه یا دامنه) مسیریابی کند. همچنین اشاره شده که نودهای V2Ray میتوانند ترافیک خود را شبیه به وبسایتهای عادی (HTTPS) استتار کنند.
در زیر لایه مبنای پروتکل (که گاهی Security Layer یا TLS Layer خوانده میشود) میتوان از TLS معمولی یا XTLS استفاده کرد (XTLS نسخه خاصی از TLS است که چند لایه رمزگذاری را با هم ادغام میکند تا سربار کمتر باشد). لایه Transport (حمل و نقل) میتواند TCP خام، WebSocket (که بستهها را در فریمهای HTTP میفرستد)، gRPC (که پروتوکلی بر پایه HTTP/2 است)، HTTP/2 Upgrade، KCP (نسخهای از UDP با کنترل خطا) و یا QUIC باشد. جریان داده (Stream Settings) مثل اجازه به دتاگ فشرده، رمزنگاری ثانویه یا تکثیر (Multiplexing) هم قابل تنظیم است.
مهمترین بخشهای پیکربندی V2Ray/Xray:
Inbound: نقطه آغاز ترافیک، مثلاً یک درگاه TCP برای پروتکل VMess با TLS.
Outbound: جایی که ترافیک فرعی به اینترنت فرستاده میشود، مثلاً به صورت مستقیم (Direct) یا به یک DNS خاص (Blackhole یا DNS) یا به یک سرور دیگر (با VMess/VLESS/Trojan...).
Routing: قوانین انتقال ترافیک از Inboundهای مختلف به Outboundهای مناسب، بر اساس فیلترهای مبتنی بر IP، دامنه، GeoIP، یا انواع دیگر.
Stream Settings: تنظیمات مربوط به چگونگی بستهبندی داده در هر لایه انتقال (مانند فعالسازی KeepAlive، TLS، or XTLS).
Transport Layer: پروتکل انتقال واقعی (TCP، UDP/KCP، QUIC، WS، gRPC، HTTPUpgrade).
Security Layer: معمولاً TLS یا XTLS برای رمزنگاری لایه اتصال. XTLS به عنوان جایگزینی برای TLS عادی توسط Xray ارائه شده که بهینهسازیهایی مثل Splice دارد (جلوگیری از رمزگذاری دوگانه).
فناوریهای نوین: مثل Reality (استتفاده از رمزنگاری نسل بعد همراه با پروفایل QUIC شباهت به دستدهی TLS و SPDY برای مخفیسازی)، Vision Flow (XTLS) (یک حالت از XTLS برای پوشش ترافیک)، و FinalMask (Padding و obfuscation پس از دستدهی). این فناوریها طراحی شدهاند تا اثرانگشت پروکسی را مخفی کنند و شناسایی ترافیک سختتر گردد.
پروتکلهای مهم:
مسدودسازی توسط سانسورها: سیستمهای سانسور میتوانند DNS را با روشهای زیر محدود کنند: در لایه شبکه، ترافیک DNS را مقایسه یا دستکاری میکنند (DNS Poisoning/Manipulation)، یا در لایه IP مسیرها را مسدود میکنند تا بستههای DNS اصلاً به بیرون نرسند. ASN یا بلوکهای IP ارائهدهندگان DNS عمومی (مانند گوگل یا کلودفلر) ممکن است کلی مسدود شود. علاوه بر این، با فعال کردن DPI روی ترافیک TLS، نام SNI و حتا برخی متادیتای پنهان TLS بررسی میشود تا ارتباطات مشکوک مسدود شود. در نهایت، حجم زیادی از مسدودسازیهای زبانی قدیمی مانند DNS-to-HTTP or TCP-resetها میتواند منجر به جلوگیری از دسترسی به resolverها شود.
V2Ray و Xray
معماری کلی V2Ray/Xray: پلتفرم V2Ray (و شاخه پیشرفتهتر Xray با توسعههای جدید) معماری مدولار دارد: چند پروتکل ورودی (Inbound) میتواند همزمان اجرا شود (مثلاً یک سرور همزمان پروتکلهای VMess و Shadowsocks و SOCKS را بپذیرد) و هر کدام یک یا چند لایه ترنسپورت (TCP, UDP, QUIC, WS, gRPC و…) دارد. سپس مولفه Routing تصمیم میگیرد ترافیک ورودی چگونه به خروجی (Outbound) هدایت شود (مثلاً بر اساس دامنه، IP مقصد، موقعیت جغرافیایی، یا قواعد کاربر). به طور کلی V2Ray دارای سه بلوک اصلی است: Inbounds (پروکسیهایی که ترافیک را دریافت میکنند)، Outbounds (ترافیکی که به شبکه میفرستند)، و Routing که بین آنها وصل میکند. هر مؤلفه قابل پیکربندی جداگانه است. برای مثال، مستند V2Fly ذکر میکند یک فرآیند V2Ray میتواند به طور همزمان چندین پروتکل ورودی/خروجی داشته باشد و ترافیک را بر اساس پیکربندی (مثل تقسیم بر اساس منطقه یا دامنه) مسیریابی کند. همچنین اشاره شده که نودهای V2Ray میتوانند ترافیک خود را شبیه به وبسایتهای عادی (HTTPS) استتار کنند.
در زیر لایه مبنای پروتکل (که گاهی Security Layer یا TLS Layer خوانده میشود) میتوان از TLS معمولی یا XTLS استفاده کرد (XTLS نسخه خاصی از TLS است که چند لایه رمزگذاری را با هم ادغام میکند تا سربار کمتر باشد). لایه Transport (حمل و نقل) میتواند TCP خام، WebSocket (که بستهها را در فریمهای HTTP میفرستد)، gRPC (که پروتوکلی بر پایه HTTP/2 است)، HTTP/2 Upgrade، KCP (نسخهای از UDP با کنترل خطا) و یا QUIC باشد. جریان داده (Stream Settings) مثل اجازه به دتاگ فشرده، رمزنگاری ثانویه یا تکثیر (Multiplexing) هم قابل تنظیم است.
مهمترین بخشهای پیکربندی V2Ray/Xray:
Inbound: نقطه آغاز ترافیک، مثلاً یک درگاه TCP برای پروتکل VMess با TLS.
Outbound: جایی که ترافیک فرعی به اینترنت فرستاده میشود، مثلاً به صورت مستقیم (Direct) یا به یک DNS خاص (Blackhole یا DNS) یا به یک سرور دیگر (با VMess/VLESS/Trojan...).
Routing: قوانین انتقال ترافیک از Inboundهای مختلف به Outboundهای مناسب، بر اساس فیلترهای مبتنی بر IP، دامنه، GeoIP، یا انواع دیگر.
Stream Settings: تنظیمات مربوط به چگونگی بستهبندی داده در هر لایه انتقال (مانند فعالسازی KeepAlive، TLS، or XTLS).
Transport Layer: پروتکل انتقال واقعی (TCP، UDP/KCP، QUIC، WS، gRPC، HTTPUpgrade).
Security Layer: معمولاً TLS یا XTLS برای رمزنگاری لایه اتصال. XTLS به عنوان جایگزینی برای TLS عادی توسط Xray ارائه شده که بهینهسازیهایی مثل Splice دارد (جلوگیری از رمزگذاری دوگانه).
فناوریهای نوین: مثل Reality (استتفاده از رمزنگاری نسل بعد همراه با پروفایل QUIC شباهت به دستدهی TLS و SPDY برای مخفیسازی)، Vision Flow (XTLS) (یک حالت از XTLS برای پوشش ترافیک)، و FinalMask (Padding و obfuscation پس از دستدهی). این فناوریها طراحی شدهاند تا اثرانگشت پروکسی را مخفی کنند و شناسایی ترافیک سختتر گردد.
پروتکلهای مهم:
❤2
VMess: پروتکل اصلی قدیمی V2Ray که بر بستر TCP کار میکند. در مسیریابی این پروتکل، «EAuID» (کد شناسایی کاربر رمزگذاریشده) ارسال میشود که شامل UUID کاربر و زمان و CRC32 است. فیلدهای دیگر در پیام درخواست (Client Request) شامل طول رمزگذاریشده سرآیند، یک مقدار تصادفی (Nonce) و خود داده میشوند. VMess دارای دو حالت احراز هویت است: حالت جدید AEAD (استفاده از AES-128-GCM برای صحتسنجی هدر) و حالت قدیمی MD5+AES-128 (فعلاً منسوخ). از نقاط قوت VMess این است که یک ساختار رمزگذاریشده و استیتلس (بیحالت) دارد؛ سرورها پس از دریافت درخواست، هویت کاربر را بررسی میکنند و در صورت تأیید، آن را به مقصد هدایت میکنند. ضعفی که دارد این است که چون پیچیده و منحصربهفرد است، ممکن است اثرانگشت ترافیک آن توسط DPI قابل شناسایی باشد (مثلاً طول خاص بستههای شروع). بهعلاوه، برای حملاتی مانند اجرای زمان محدود (timing attacks)، وابسته به زمان بودن (در حالت MD5 قدیمی) میتواند مشکلساز باشد؛ VLESS این مشکل را ندارد.
VLESS: نسخه جدیدتر VMess در Xray/V2Ray که سبکتر است. مستندات آن میگویند VLESS «بیحالت، سبک و بدون وابستگی به زمان سیستم است» و از یک UUID ثابت برای احراز هویت استفاده میکند. برخلاف VMess، هیچ CRC زمانبندی یا MD5ی در کار نیست. فقط UUID کاربر به طور خام (در چت TLS) احراز هویت میشود. این سادگی باعث میشود پیادهسازی و اثرانگشتپذیری آن کمتر شود. در عمل ساختار فنی VMess و VLESS شبیهاند، تفاوت عمده در حذف زمان و روش احراز است. چون VLESS هم معمولاً بر بستر TLS اجرا میشود (مثلاً XTLS یا ساده TLS)، دستدهی آن مثل یک TLS عادی به نظر میرسد. به طور خلاصه: ساختار بسته سادهتر و handshake کوتاهتر از VMess دارد.
Shadowsocks: پروتکل پراکسی سبک بر پایه رمزنگاری. معماری آن به طور ساده شامل یک سرور و کلاینت است، بدون handshake تعریفشده; کلاینت پس از برقراری TCP (یا UDP) اولین بسته را به صورت رمز شده به سرور ارسال میکند. در نسخههای قدیمی، اولین بسته شامل ۱ بایت نوع آدرس (IPv4/دامنه/IPv6)، آدرس مقصد و پورت (۲ بایت) بود. این حداقل handshake باعث میشد فایروال بتواند از حملات فعال پروبینگ استفاده کند: مثلاً یکی میتواند ۲۵۶ اتصال با یک بایتهای اول متفاوت ایجاد کند، و در ۳۲ بایت مقدار قانونی (۱ یا ۳) سرور منتظر میماند و بقیه موارد را قطع میکند؛ این الگو به فایروال میگوید که سرور Shadowsocks است. در نسخههای امروزی با استفاده از رمزنگاریهای AEAD این نوع حمله خنثی شده است (مگر کلید را حدس بزند). Shadowsocks عموماً به دلیل تشابه ترافیک با جریانهای تصادفی قوی شناخته میشود، ولی DPIهای پیشرفته و probing فعال (مثلاً تزریق محتوی غیرقانونی و دیدن پاسخ رمز شده بزرگ) میتواند آن را تشخیص دهد. مقاومت در برابر فیلترینگ آن متوسط است؛ اگر ترافیک منتظر پکتها شود و پاسخهای رمز شده حجیم بدهد، نشانهی سرور Shadowsocks خواهد بود.
SOCKS: پروتکل پراکسی استاندارد بدون رمزنگاری که کلاینت میتواند روی آن پورتها را فوروارد کند. شناسایی آن بسیار آسان است زیرا فرمت مشخص (مثلاً نسخه 5 در اول بسته و سپس درخواست TCP Connect) دارد. طبیعتاً رمزنگاری ندارد، پس به خودی خود مقاومتی در برابر سانسور ندارد و بر اساس قوانین محتوا توسط DPI مسدود میشود (اگر DNS یا IP مقصد حساس باشد).
HTTP Proxy (CONNECT): پروتکلی که به کلاینت امکان میدهد درخواست CONNECT به یک سرور HTTP بدهد تا یک تونل TCP ساده ایجاد کند. درخواست شامل خطی شبیه «CONNECT domain:port HTTP/1.1» است که بهوضوح قابل تشخیص است. از آنجا که متن ساده است، DPI میتواند به راحتی این رشته را پیدا کرده و مسدود کند یا محدودیت بگذارد (مگر TLS روی آن برقرار شود). البته اگر روی TLS (HTTPS) اجرا شود، به صورت HTTPS عادی درآمده و فقط بستههای TLS دیده میشوند.
ترنسپورتهای V2Ray/Xray:
TCP: معمولترین ترنسپورت. اگر از TLS روی TCP استفاده شود، شبیه HTTPS حرکت میکند. بستههای TCP دارای سرآیند طول، شماره ترتیب، پرچم ACK/SYN و ... هستند. DPI به راحتی میتواند سرآیند و محتوای پلینتکست یا TLS (مثل SNI) را ببیند.
WebSocket (WS): لایهای روی HTTP است که پس از یک درخواست Upgrade، اتصال دوطرفه «فریم» شده ایجاد میکند. هر فریم WS چند بایت سربرگ دارد (بین 2 تا 14 بایت سربرگ) و سپس داده باینری. چون ابتدا روی HTTP 1.1 و پورت 80/443 برقرار میشود، میتوان آن را بهعنوان ترافیک وب پنهان کرد. معایب: سربرگهای پیدرپی قابل تشخیص و راهاندازی HTTP برای آن لازم است.
VLESS: نسخه جدیدتر VMess در Xray/V2Ray که سبکتر است. مستندات آن میگویند VLESS «بیحالت، سبک و بدون وابستگی به زمان سیستم است» و از یک UUID ثابت برای احراز هویت استفاده میکند. برخلاف VMess، هیچ CRC زمانبندی یا MD5ی در کار نیست. فقط UUID کاربر به طور خام (در چت TLS) احراز هویت میشود. این سادگی باعث میشود پیادهسازی و اثرانگشتپذیری آن کمتر شود. در عمل ساختار فنی VMess و VLESS شبیهاند، تفاوت عمده در حذف زمان و روش احراز است. چون VLESS هم معمولاً بر بستر TLS اجرا میشود (مثلاً XTLS یا ساده TLS)، دستدهی آن مثل یک TLS عادی به نظر میرسد. به طور خلاصه: ساختار بسته سادهتر و handshake کوتاهتر از VMess دارد.
Shadowsocks: پروتکل پراکسی سبک بر پایه رمزنگاری. معماری آن به طور ساده شامل یک سرور و کلاینت است، بدون handshake تعریفشده; کلاینت پس از برقراری TCP (یا UDP) اولین بسته را به صورت رمز شده به سرور ارسال میکند. در نسخههای قدیمی، اولین بسته شامل ۱ بایت نوع آدرس (IPv4/دامنه/IPv6)، آدرس مقصد و پورت (۲ بایت) بود. این حداقل handshake باعث میشد فایروال بتواند از حملات فعال پروبینگ استفاده کند: مثلاً یکی میتواند ۲۵۶ اتصال با یک بایتهای اول متفاوت ایجاد کند، و در ۳۲ بایت مقدار قانونی (۱ یا ۳) سرور منتظر میماند و بقیه موارد را قطع میکند؛ این الگو به فایروال میگوید که سرور Shadowsocks است. در نسخههای امروزی با استفاده از رمزنگاریهای AEAD این نوع حمله خنثی شده است (مگر کلید را حدس بزند). Shadowsocks عموماً به دلیل تشابه ترافیک با جریانهای تصادفی قوی شناخته میشود، ولی DPIهای پیشرفته و probing فعال (مثلاً تزریق محتوی غیرقانونی و دیدن پاسخ رمز شده بزرگ) میتواند آن را تشخیص دهد. مقاومت در برابر فیلترینگ آن متوسط است؛ اگر ترافیک منتظر پکتها شود و پاسخهای رمز شده حجیم بدهد، نشانهی سرور Shadowsocks خواهد بود.
SOCKS: پروتکل پراکسی استاندارد بدون رمزنگاری که کلاینت میتواند روی آن پورتها را فوروارد کند. شناسایی آن بسیار آسان است زیرا فرمت مشخص (مثلاً نسخه 5 در اول بسته و سپس درخواست TCP Connect) دارد. طبیعتاً رمزنگاری ندارد، پس به خودی خود مقاومتی در برابر سانسور ندارد و بر اساس قوانین محتوا توسط DPI مسدود میشود (اگر DNS یا IP مقصد حساس باشد).
HTTP Proxy (CONNECT): پروتکلی که به کلاینت امکان میدهد درخواست CONNECT به یک سرور HTTP بدهد تا یک تونل TCP ساده ایجاد کند. درخواست شامل خطی شبیه «CONNECT domain:port HTTP/1.1» است که بهوضوح قابل تشخیص است. از آنجا که متن ساده است، DPI میتواند به راحتی این رشته را پیدا کرده و مسدود کند یا محدودیت بگذارد (مگر TLS روی آن برقرار شود). البته اگر روی TLS (HTTPS) اجرا شود، به صورت HTTPS عادی درآمده و فقط بستههای TLS دیده میشوند.
ترنسپورتهای V2Ray/Xray:
TCP: معمولترین ترنسپورت. اگر از TLS روی TCP استفاده شود، شبیه HTTPS حرکت میکند. بستههای TCP دارای سرآیند طول، شماره ترتیب، پرچم ACK/SYN و ... هستند. DPI به راحتی میتواند سرآیند و محتوای پلینتکست یا TLS (مثل SNI) را ببیند.
WebSocket (WS): لایهای روی HTTP است که پس از یک درخواست Upgrade، اتصال دوطرفه «فریم» شده ایجاد میکند. هر فریم WS چند بایت سربرگ دارد (بین 2 تا 14 بایت سربرگ) و سپس داده باینری. چون ابتدا روی HTTP 1.1 و پورت 80/443 برقرار میشود، میتوان آن را بهعنوان ترافیک وب پنهان کرد. معایب: سربرگهای پیدرپی قابل تشخیص و راهاندازی HTTP برای آن لازم است.
❤1