🌐 Autonomous System یا AS چیست؟

وقتی از اینترنت صحبت می‌کنیم، شاید تصور کنیم همه شبکه‌های دنیا به‌صورت مستقیم و بدون واسطه به هم وصل هستن؛ ولی واقعیت اینه که اینترنت از هزاران شبکه مستقل تشکیل شده که با همکاری هم، ارتباط بین کاربران و سرویس‌های مختلف رو برقرار می‌کنن. به هر مجموعه از شبکه‌ها و روترهای IP که تحت مدیریت یک مجموعه مشخص قرار دارن و سیاست مسیریابی مشترکی رو دنبال می‌کنن، می‌گیم Autonomous System یا به‌اختصار AS.

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

هر AS معمولاً با یک شماره منحصربه‌فرد به نام ASN یا Autonomous System Number شناسایی می‌شه. برای مثال، AS15169 متعلق به Google و AS13335 متعلق به Cloudflare هستن. این شماره‌ها کمک می‌کنن شبکه‌های مستقل در اینترنت از هم تشخیص داده بشن.

اما AS چطور با بقیه شبکه‌های اینترنت ارتباط برقرار می‌کنه؟
اینجا پای پروتکلی به اسم BGP یا Border Gateway Protocol وسط میاد. BGP پروتکل اصلی مسیریابی بین ASهای مختلفه. هر AS می‌تونه از طریق BGP به شبکه‌های دیگه اعلام کنه که چه محدوده‌هایی از آدرس‌های IP رو می‌تونه در دسترس قرار بده. مثلاً یک اپراتور اعلام می‌کنه که برای رسیدن به یک سری Prefix مشخص، مسیر ارتباطی از شبکه اون عبور می‌کنه.

فرض کن کاربری در ایران می‌خواد وارد یک سرور در اروپا بشه. بسته‌های اطلاعاتی ممکنه از شبکه اپراتور کاربر عبور کنن، بعد از چند AS مختلف در مسیر ترانزیت اینترنت رد بشن و در نهایت به AS میزبان سرور برسن. البته مسیر واقعی به سیاست‌های مسیریابی، ارتباطات بین اپراتورها و وضعیت شبکه بستگی داره و لزوماً کوتاه‌ترین مسیر جغرافیایی نیست.

نکته مهم اینه که AS با یک شبکه محلی یا یک Subnet فرق داره. Subnet محدوده‌ای از آدرس‌های IP رو مشخص می‌کنه؛ اما AS یک دامنه مدیریتی و مسیریابیه که می‌تونه تعداد زیادی شبکه و Prefix مختلف رو شامل بشه. همچنین هر AS الزاماً متعلق به یک کشور نیست و ممکنه زیرساختش در چند کشور گسترده شده باشه.
از نظر ارتباط بین شبکه‌ها، معمولاً با دو اصطلاح روبه‌رو می‌شیم: Intra-AS و Inter-AS. مسیریابی Intra-AS مربوط به داخل یک سیستم خودمختاره و می‌تونه با پروتکل‌هایی مثل OSPF یا IS-IS انجام بشه. در مقابل، مسیریابی Inter-AS ارتباط بین سیستم‌های خودمختار مختلف رو پوشش می‌ده که BGP نقش اصلی رو در اون ایفا می‌کنه.

اهمیت AS فقط به مسیریابی محدود نمی‌شه. در تحلیل اختلالات اینترنت، بررسی مسیرهای BGP، شناسایی تغییرات غیرعادی در Routeها، تحلیل وابستگی اپراتورها به یکدیگر و بررسی اتفاقاتی مثل Route Leak یا BGP Hijacking، شناخت ASها اهمیت زیادی داره. برای مثال، اگر یک Prefix به‌اشتباه از یک AS اعلام بشه و شبکه‌های دیگر این مسیر رو بپذیرن، ممکنه بخشی از ترافیک به مسیر اشتباه هدایت بشه؛ اتفاقی که بسته به شرایط می‌تونه باعث اختلال یا حتی رهگیری ترافیک بشه.
#Network #BGP #ASN #AutonomousSystem #NetworkSecurity

📌 @ModernLAN

🔐 دستورات کاربردی SSH در شبکه و لینوکس
🔹 ۱. اتصال به سرور با SSH
اتصال معمولی به سرور:

ssh username@192.168.1.10

اتصال به سرور با IP عمومی:

ssh admin@203.0.113.10

اتصال با پورت اختصاصی:

ssh -p 2222 admin@192.168.1.10

فعال کردن حالت دیباگ برای بررسی خطاهای اتصال:

ssh -v admin@192.168.1.10

نمایش جزئیات بیشتر برای عیب‌یابی:

ssh -vvv admin@192.168.1.10

🔹 ۲. مدیریت کلیدهای SSH
ساخت کلید SSH با الگوریتم Ed25519:

ssh-keygen -t ed25519

ساخت کلید RSA با طول 4096 بیت:

ssh-keygen -t rsa -b 4096

نمایش کلید عمومی:

cat ~/.ssh/id_ed25519.pub

کپی کردن کلید عمومی روی سرور برای احراز هویت با کلید:

ssh-copy-id admin@192.168.1.10

اتصال با استفاده از یک کلید خصوصی مشخص:

ssh -i ~/.ssh/id_ed25519 admin@192.168.1.10

نکته امنیتی: کلید خصوصی مثل رمز عبورته و نباید در اختیار دیگران قرار بگیره. فقط کلید عمومی رو روی سرور مقصد قرار بده.
🔹 ۳. انتقال فایل با SSH و SCP
ارسال فایل به سرور:

scp file.txt admin@192.168.1.10:/home/admin/

دریافت فایل از سرور:

scp admin@192.168.1.10:/home/admin/file.txt .

انتقال یک پوشه به‌صورت بازگشتی:

scp -r backup/ admin@192.168.1.10:/home/admin/

انتقال فایل با پورت SSH اختصاصی:

scp -P 2222 file.txt admin@192.168.1.10:/home/admin/

کپی فایل با حفظ ویژگی‌های زمانی فایل:

scp -p file.txt admin@192.168.1.10:/home/admin/

🔹 ۴. انتقال فایل با SFTP
اتصال به سرور SFTP:

sftp admin@192.168.1.10

مشاهده فایل‌های مسیر فعلی سرور:

ls

مشاهده مسیر فعلی سیستم مقصد:

pwd

دانلود فایل:

get backup.zip

آپلود فایل:

put backup.zip

دانلود یک پوشه به‌صورت بازگشتی:

get -r backup/

خروج از محیط SFTP:

exit

🔹 ۵. اجرای دستورات روی سرور از راه دور
نمایش فضای دیسک سرور:

ssh admin@192.168.1.10 "df -h"

بررسی میزان مصرف حافظه:

ssh admin@192.168.1.10 "free -h"

بررسی وضعیت سرویس SSH:

ssh admin@192.168.1.10 "sudo systemctl status ssh"

مشاهده آدرس‌های IP سرور:

ssh admin@192.168.1.10 "ip addr"

بررسی زمان روشن بودن سرور:

ssh admin@192.168.1.10 "uptime"

این روش برای اجرای سریع دستورات مدیریتی بدون ورود تعاملی به سرور کاربرد داره.
🔹 ۶. مدیریت تونل SSH (SSH Tunneling)
یکی از کاربردهای مهم SSH، ایجاد تونل رمزنگاری‌شده برای انتقال ترافیکه.
Local Port Forwarding:

ssh -L 8080:127.0.0.1:80 admin@192.168.1.10

در این مثال، اتصال به پورت 8080 روی سیستم خودت از طریق SSH به پورت 80 سیستم مقصد هدایت می‌شه.
Remote Port Forwarding:

ssh -R 9000:localhost:3000 admin@192.168.1.10

این دستور پورت 9000 روی سمت سرور SSH رو به سرویس پورت 3000 روی سیستم کلاینت متصل می‌کنه؛ البته برقراری این نوع دسترسی به تنظیمات سرور و محدودیت‌های امنیتی بستگی داره.
Dynamic Port Forwarding:

ssh -D 1080 admin@192.168.1.10

این دستور یک پراکسی SOCKS محلی روی پورت 1080 ایجاد می‌کنه که برنامه‌های سازگار می‌تونن ترافیکشون رو از طریق اون ارسال کنن.
🔹 ۷. دستورات عیب‌یابی SSH
بررسی دسترسی به پورت SSH در لینوکس:

nc -zv 192.168.1.10 22

بررسی اثر انگشت کلید میزبان:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

نمایش تنظیمات مؤثر کلاینت SSH:

ssh -G admin@192.168.1.10

بررسی پورت‌های در حال گوش دادن روی لینوکس:

sudo ss -tlnp

بررسی لاگ‌های سرویس SSH در سیستم‌های مبتنی بر systemd:

sudo journalctl -u ssh -n 50

در بعضی توزیع‌ها نام سرویس sshd است:

sudo journalctl -u sshd -n 50

🔹 ۸. مدیریت SSH در لینوکس
بررسی وضعیت سرویس SSH:

sudo systemctl status ssh

راه‌اندازی سرویس:

sudo systemctl start ssh

راه‌اندازی مجدد سرویس:

sudo systemctl restart ssh

فعال کردن اجرای خودکار سرویس هنگام بوت:

sudo systemctl enable ssh

بررسی فایل پیکربندی SSH Server:

sudo nano /etc/ssh/sshd_config

بررسی صحت پیکربندی قبل از اعمال تغییرات:

sudo sshd -t

نکته: در توزیع‌های مختلف لینوکس ممکنه نام سرویس یا مسیر فایل‌ها متفاوت باشه. قبل از تغییر تنظیمات SSH روی سرور ریموت، یک نشست مدیریتی فعال نگه دار تا در صورت بروز خطا دسترسی‌ات قطع نشه.
🔹 ۹. دستورات SSH در سیسکو
برای اتصال SSH به روتر یا سوئیچ سیسکو:

ssh -l admin 192.168.1.1

اگر کلاینت از قالب username@host پشتیبانی کنه، معمولاً این شکل هم قابل استفاده است:

ssh admin@192.168.1.1

در صورت استفاده از پورت غیر پیش‌فرض، امکان مشخص کردن پورت به گزینه‌های کلاینت SSH بستگی داره.

🛠️ دستورات تعمیر و ریپیر ویندوز با CMD
اگه ویندوزت مشکل پیدا کرده، فایل‌های سیستمی خراب شدن، آپدیت نصب نمیشه یا بعضی از قابلیت‌های ویندوز درست کار نمی‌کنن، یه سری دستور کاربردی توی CMD داریم که می‌تونن بدون نصب مجدد ویندوز مشکلات رو بررسی و برطرف کنن.
نکته: CMD رو با گزینه Run as administrator اجرا کن، مگر اینکه گفته باشم دستور در محیط ریکاوری اجرا بشه.
1️⃣ تعمیر فایل‌های سیستمی ویندوز (SFC)
این دستور فایل‌های سیستمی ویندوز رو بررسی می‌کنه و اگه فایل خراب یا دست‌کاری‌شده‌ای پیدا کنه، سعی می‌کنه اون رو تعمیر کنه.

sfc /scannow

برای بررسی و تعمیر فایل‌های محافظت‌شده ویندوز استفاده می‌شه. بعد از اتمام اسکن، نتیجه رو بررسی کن.
2️⃣ تعمیر ایمیج ویندوز با DISM
اگه SFC نتونه فایل‌ها رو تعمیر کنه، بهتره از DISM استفاده کنی. این ابزار وضعیت Component Store ویندوز رو بررسی و در صورت نیاز تعمیر می‌کنه.
بررسی سلامت ایمیج:

DISM /Online /Cleanup-Image /CheckHealth

اسکن دقیق‌تر برای پیدا کردن خرابی‌ها:

DISM /Online /Cleanup-Image /ScanHealth

تعمیر ایمیج ویندوز:

DISM /Online /Cleanup-Image /RestoreHealth

بعد از اتمام DISM، دوباره این دستور رو اجرا کن:

sfc /scannow

📌 معمولاً ترتیب مناسب برای تعمیر ویندوزی که بالا میاد، اجرای DISM و بعد SFC هست. دستور RestoreHealth ممکنه برای دریافت فایل‌های لازم به Windows Update نیاز داشته باشه.
3️⃣ بررسی و تعمیر هارد دیسک (CHKDSK)
اگه ویندوز هنگ می‌کنه، فایل‌ها باز نمی‌شن یا خطاهای مربوط به فایل‌سیستم داری، این دستورات می‌تونن کمک کنن.
بررسی سریع فایل‌سیستم:

chkdsk C:

بررسی و اصلاح خطاهای فایل‌سیستم:

chkdsk C: /f

بررسی سکتورهای خراب و تلاش برای بازیابی اطلاعات قابل خواندن:

chkdsk C: /r

توضیح پارامترها:
/f خطاهای منطقی فایل‌سیستم رو اصلاح می‌کنه.
/r سکتورهای خراب رو بررسی می‌کنه و تلاش می‌کنه داده‌های قابل خواندن رو بازیابی کنه؛ این گزینه عملکرد /f رو هم شامل می‌شه.
اگه درایو C در حال استفاده باشه، ممکنه ویندوز پیشنهاد بده بررسی در راه‌اندازی بعدی انجام بشه.
⚠️ اجرای /r روی هاردهای بزرگ زمان‌بره. اگه احتمال خرابی فیزیکی هارد وجود داره، اول از اطلاعات مهم نسخه پشتیبان بگیر.
4️⃣ تعمیر فایل‌های بوت ویندوز
اگه ویندوز بالا نمیاد یا با خطاهای بوت مواجه می‌شی، اول باید مشخص کنی مشکل از کجاست.
بررسی پارتیشن‌ها:

diskpart
list disk
list volume
exit

در محیط ریکاوری، حرف درایو ویندوز ممکنه C نباشه.
برای پیدا کردن درایو ویندوز می‌تونی این دستور رو اجرا کنی:

diskpart
list volume
exit

سپس درایوهای احتمالی رو بررسی کن. مثلاً:

dir C:\Windows
dir D:\Windows
dir E:\Windows

اگه پوشه ویندوز در D قرار داشت، در دستورات بعدی باید مسیر درست رو در نظر بگیری.
بازسازی فایل‌های بوت در سیستم‌های UEFI:
در بسیاری از سیستم‌های UEFI، ابزار bcdboot برای بازسازی فایل‌های بوت کاربرد داره. ابتدا باید پارتیشن EFI رو به‌درستی شناسایی کنی و به اون یک حرف اختصاص بدی. این عملیات به شناسایی صحیح پارتیشن‌ها نیاز داره و اجرای اشتباه دستورات می‌تونه باعث مشکل در بوت بشه.
برای سیستم UEFI، نمونه دستور بعد از شناسایی درست پارتیشن‌ها:

bcdboot C:\Windows /s S: /f UEFI

در این مثال فرض شده ویندوز روی C و پارتیشن EFI روی S قرار داره. این حروف صرفاً نمونه هستن؛ قبل از اجرا باید مسیرهای واقعی رو مشخص کنی.
5️⃣ تعمیر شبکه ویندوز
اگه اینترنت وصل نمی‌شه، DNS مشکل داره یا تنظیمات شبکه به‌هم ریخته، دستورات زیر رو امتحان کن.
پاک‌کردن کش DNS:

ipconfig /flushdns

دریافت مجدد IP از DHCP:

ipconfig /release
ipconfig /renew

نمایش تنظیمات شبکه:

ipconfig /all

بازنشانی Winsock:

netsh winsock reset

بازنشانی تنظیمات TCP/IP:

netsh int ip reset

بعد از اجرای دو دستور آخر، ویندوز رو Restart کن. توجه داشته باش که بازنشانی تنظیمات شبکه ممکنه روی بعضی تنظیمات سفارشی اثر بذاره.
6️⃣ تعمیر سرویس Windows Update
اگه Windows Update خطا می‌ده یا آپدیت‌ها نصب نمی‌شن، می‌تونی کش دانلود آپدیت رو بازسازی کنی.
CMD رو با دسترسی Administrator اجرا کن:

net stop wuauserv
net stop bits

سپس پوشه کش دانلود آپدیت رو تغییر نام بده:

ren %systemroot%\SoftwareDistribution SoftwareDistribution.old

بعد سرویس‌ها رو دوباره اجرا کن:

net start bits
net start wuauserv

این کار باعث می‌شه ویندوز پوشه جدیدی برای کش آپدیت بسازه. ممکنه تاریخچه نمایش داده‌شده آپدیت‌ها تغییر کنه؛ این کار به معنی حذف آپدیت‌های نصب‌شده نیست.

اگر سرویسی متوقف نشد یا پوشه قابل تغییر نام نبود، خطا رو بررسی کن و دستورات رو پشت سر هم و بدون بررسی اجرا نکن.
7️⃣ بررسی خطاهای ویندوز از طریق Event Log
برای بررسی رخدادهای سیستمی، می‌تونی از wevtutil استفاده کنی.
نمایش آخرین خطاهای ثبت‌شده در System Log:

wevtutil qe System /q:"*[System[(Level=2)]]" /c:20 /rd:true /f:text

نمایش خطاهای Application Log:

wevtutil qe Application /q:"*[System[(Level=2)]]" /c:20 /rd:true /f:text

این دستورات تا ۲۰ رخداد با سطح Error رو نمایش می‌دن و برای عیب‌یابی اولیه مفیدن.
8️⃣ بررسی فایل‌های خراب در ویندوز آفلاین
اگه ویندوز بالا نمیاد و از طریق محیط Recovery وارد CMD شدی، دستور معمول SFC با /Online لزوماً برای تعمیر ویندوز نصب‌شده مناسب نیست.
در این شرایط می‌تونی از نمونه زیر استفاده کنی:

sfc /scannow /offbootdir=D:\ /offwindir=D:\Windows

مهم: این دستور فقط یک مثال هست. باید مسیر واقعی پارتیشن بوت و پوشه ویندوز رو در محیط ریکاوری مشخص کنی؛ ممکنه حروف درایو با حالت عادی ویندوز متفاوت باشن.

9️⃣ بررسی و تعمیر با یک ترتیب پیشنهادی
اگه ویندوز بالا میاد ولی ناپایداره، فایل‌های سیستمی خطا دارن یا بعضی قابلیت‌ها درست کار نمی‌کنن، این ترتیب معمولاً نقطه شروع مناسبیه:

DISM /Online /Cleanup-Image /RestoreHealth

بعد:

sfc /scannow

سپس بررسی فایل‌سیستم:

chkdsk C: /scan

در پایان، در صورت نیاز سیستم رو Restart کن.
نکته حرفه‌ای: این دستورات همه مشکلات ویندوز رو تعمیر نمی‌کنن. خرابی سخت‌افزار، SSD معیوب، مشکلات RAM، درایور ناسازگار یا خرابی جدی بوت ممکنه به روش عیب‌یابی متفاوتی نیاز داشته باشه.
🔧 اگه بخوای دقیق‌تر تعمیرش کنیم، بگو مشکل ویندوزت کدومه:
۱. ویندوز اصلاً بالا نمیاد و روی لوگو گیر می‌کنه.۲. صفحه آبی (BSOD) می‌ده.۳. ویندوز بالا میاد ولی کند شده یا هنگ می‌کنه.۴. اینترنت و شبکه مشکل دارن.۵. فایل‌های سیستمی خراب شدن یا خطای SFC/DISM می‌گیری.۶. می‌خوای مجموعه کامل دستورات تعمیر ویندوز با CMD رو برای استفاده در کار فنی و عیب‌یابی داشته باشی.

@ModernLan

سه بخش اصلی کابل فیبر نوری

1-Core

2-Cladding

3-Jacket


@ModernLan

نصب Apache روی Ubuntu.

📍نصب و راه‌اندازی Apache روی Ubuntu📍

۱. آپدیت مخازن Ubuntu

sudo apt update

۲. نصب Apache

sudo apt install apache2 -y

۳. فعال‌سازی و اجرای سرویس
برای اجرای Apache و فعال شدن خودکارش بعد از روشن شدن سرور:

sudo systemctl enable --now apache2

۴. بررسی وضعیت Apache

sudo systemctl status apache2

اگر عبارت active (running) رو دیدی، یعنی سرویس با موفقیت اجرا شده.
برای خروج از صفحه وضعیت، کلید q رو بزن.
۵. اجازه دسترسی در فایروال
اگر از فایروال UFW استفاده می‌کنی، ابتدا وضعیتش رو بررسی کن:

sudo ufw status

اگر UFW فعاله، برای باز کردن پورت‌های HTTP و HTTPS اجرا کن:

sudo ufw allow 'Apache Full'

این پروفایل پورت‌های زیر رو باز می‌کنه:
80/TCP برای HTTP
443/TCP برای HTTPS
۶. تست Apache
برای پیدا کردن IP سرور:

hostname -I

حالا IP سرور رو داخل مرورگر وارد کن:

http://SERVER_IP

به‌جای SERVER_IP، آدرس IP سرورت رو قرار بده.
اگر صفحه پیش‌فرض Apache نمایش داده شد، یعنی وب‌سرور درست کار می‌کنه. ✅
۷. مسیر فایل‌های وب‌سایت
مسیر پیش‌فرض فایل‌های سایت در Ubuntu:

/var/www/html/

برای مشاهده محتویات این پوشه:

ls -lah /var/www/html/

برای ساخت یک صفحه HTML آزمایشی:

echo '<h1>Welcome to Apache Server!</h1>' | sudo tee /var/www/html/index.html

حالا صفحه رو دوباره در مرورگر باز کن.
۸. دستورات مدیریتی Apache

📌 نکته برای مدیریت سرور
اگر هدفت راه‌اندازی یک VPS برای میزبانی وب‌سایت است، پیشنهاد می‌کنم بعد از نصب Apache این موارد رو هم یاد بگیری:
Virtual Hosts: میزبانی چند دامنه روی یک سرور.
DNS: اتصال دامنه به IP سرور.
SSL/TLS: فعال‌سازی HTTPS با گواهی معتبر.
PHP: اجرای سایت‌های PHP و وردپرس.
Firewall: مدیریت دسترسی به پورت‌های سرور.
Log Analysis: بررسی لاگ‌های Apache برای عیب‌یابی.


@ModernLan

💻 تفاوت VPS و VDS چیه؟

خیلی‌ها موقع خرید سرور مجازی با اسم‌های VPS و VDS مواجه می‌شن و فکر می‌کنن این دوتا کاملاً با هم فرق دارن، ولی قضیه اون‌قدرها هم پیچیده نیست. VPS مخفف Virtual Private Server و VDS مخفف Virtual Dedicated Server هست. هر دو در واقع سرور مجازی هستن که روی یه سرور فیزیکی اجرا می‌شن، اما تفاوتشون معمولاً توی نحوه تخصیص منابع و سیاست شرکت ارائه‌دهنده‌ست. مثلاً یه سرور فیزیکی رو تصور کن که منابعش بین چندین ماشین مجازی تقسیم شده؛ توی VPS ممکنه منابع پردازنده بین چند کاربر به اشتراک گذاشته بشه، اما توی VDS معمولاً منابعی مثل CPU و RAM با محدودیت و تضمین بیشتری به هر سرور اختصاص داده می‌شن.

البته این موضوع به شرکت ارائه‌دهنده بستگی داره و صرفاً اسم VDS تضمین نمی‌کنه که منابع کاملاً اختصاصی باشن. از نظر کاربرد هم هر دو برای راه‌اندازی سایت، VPN، سرور لینوکس، ویندوز سرور و سرویس‌های مختلف استفاده می‌شن، اما اگه دنبال عملکرد پایدارتر و منابع تضمین‌شده باشی، یه VDS با مشخصات مناسب می‌تونه انتخاب بهتری باشه. یه نکته مهم دیگه هم فناوری مجازی‌سازیه؛ مثلاً KVM امکان اجرای سیستم‌عامل مستقل رو فراهم می‌کنه و معمولاً برای کارهای سروری گزینه مناسبیه. در نهایت، موقع خرید بیشتر از اینکه به اسم VPS یا VDS توجه کنی، باید مشخصات CPU، مقدار RAM، نوع دیسک، کیفیت شبکه و نحوه تخصیص منابع رو بررسی کنی؛ چون ممکنه یه VPS قوی از یه VDS ضعیف عملکرد بهتری داشته باشه.

@ModernLan

🔴 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