11. LDAP
برای LDAP:

nmap -p 389 --script=ldap-rootdse 192.168.1.10

در محیط Active Directory، LDAP Enumeration می‌تونه اطلاعات مهمی درباره Domain Controller و Directory Service بده.

12. MySQL
اطلاعات MySQL:

nmap -p 3306 --script=mysql-info 192.168.1.10

بررسی Authentication:

nmap -p 3306 --script=mysql-empty-password 192.168.1.10

این نوع اسکریپت‌ها برای بررسی Configuration اشتباه در محیط Lab مفیدن.

13. Redis
اطلاعات Redis:

nmap -p 6379 --script=redis-info 192.168.1.10

14. MongoDB
برای MongoDB:

nmap -p 27017 --script=mongodb-info 192.168.1.10

15. Vulnerability Scanning
یکی از جذاب‌ترین قابلیت‌های NSE:

nmap --script=vuln 192.168.1.10

ولی بهتره قبلش Port و Version رو مشخص کنی:

nmap -sV --script=vuln 192.168.1.10

یا:

nmap -sV -p 80,443 --script=vuln 192.168.1.10

Category vuln برای بررسی آسیب‌پذیری‌های شناخته‌شده طراحی شده و معمولاً نتیجه را زمانی گزارش می‌کند که شرایط آسیب‌پذیری پیدا شود.

16. Vulners
یکی از اسکریپت‌های معروف:

nmap -sV --script=vulners 192.168.1.10

یا:

nmap -sV -p 22,80,443 --script=vulners 192.168.1.10

این Script بر اساس Service/Version و CPEهای شناسایی‌شده، اطلاعات Vulnerability و CVSS مرتبط را از سرویس Vulners دریافت می‌کند.
یعنی مثلاً:

OpenSSH 8.x
       ↓
CPE
       ↓
Vulnerability Database
       ↓
CVE / CVSS

17. Discovery
برای Discovery می‌تونی Category رو مستقیم اجرا کنی:

nmap --script=discovery 192.168.1.10

البته برای یک اسکن واقعی بهتره Scriptهای مورد نیاز رو انتخاب کنی، چون discovery می‌تونه تعداد زیادی Script را شامل بشه.

18. Broadcast Discovery
در شبکه داخلی:

nmap --script=broadcast

مثلاً DHCP:

nmap --script=broadcast-dhcp-discover

این Script یک DHCP Request به Broadcast می‌فرسته و اطلاعات پاسخ DHCP Server رو گزارش می‌کنه.
برای بعضی محیط‌های LAN:

nmap --script=broadcast-ping

می‌تونه Hostهای پاسخ‌دهنده را در شبکه Local پیدا کنه.

19. Script Arguments
یکی از قسمت‌های مهم NSE اینه که Scriptها می‌تونن Argument بگیرن.
ساختار:

--script-args name=value

مثلاً:

nmap --script dns-brute \
--script-args dns-brute.threads=10 \
example.com

چند Argument:

nmap --script dns-brute \
--script-args dns-brute.threads=10,dns-brute.srv=true \
example.com

Nmap برای Script Arguments از ساختار name=value استفاده می‌کنه و میشه چند Argument رو با کاما جدا کرد.

20. پیدا کردن Scriptها
برای دیدن Scriptهای نصب‌شده:
Linux:

ls /usr/share/nmap/scripts/

مثلاً:

ls /usr/share/nmap/scripts/ | grep http

یا:

ls /usr/share/nmap/scripts/ | grep smb

در ویندوز معمولاً Scriptها داخل دایرکتوری نصب Nmap قرار دارن.

21. NSE Script Database
Nmap یک فایل Database برای Scriptها داره:

/usr/share/nmap/scripts/script.db

برای جستجو:

grep http /usr/share/nmap/scripts/script.db

22. آپدیت Script Database
اگر Script جدیدی اضافه کردی:

sudo nmap --script-updatedb

این دستور Database مربوط به NSE رو دوباره می‌سازه.

23. دیدن مستندات یک Script
مثلاً:

nmap --script-help http-title

یا:

nmap --script-help dns-brute

برای چند Script:

nmap --script-help "http-*"

این یکی از بهترین راه‌ها برای فهمیدن دقیقاً هر Script چه کاری انجام میده و چه Argumentهایی داره.

24. Wildcard
مثلاً تمام Scriptهایی که با http- شروع میشن:

nmap --script="http-*" 192.168.1.10

یا:

nmap --script="ssh-*" 192.168.1.10

یا:

nmap --script="smb-*" 192.168.1.10

25. ترکیب Scriptها
مثلاً یک Web Assessment نسبتاً خوب:

nmap -sV -p 80,443 \
--script="http-title,http-headers,http-methods,ssl-cert,ssl-enum-ciphers" \
192.168.1.10

برای SSH:

nmap -sV -p 22 \
--script="ssh-hostkey,ssh2-enum-algos,ssh-auth-methods" \
192.168.1.10

برای Windows/SMB:

nmap -sV -p 445 \
--script="smb-os-discovery,smb-protocols,smb-security-mode" \
192.168.1.10

26. ترکیب NSE با Scan کامل‌تر
یک دستور کاربردی برای Lab:

nmap -sS -sV -sC -O 192.168.1.10

یعنی:

-sS    → TCP SYN Scan
-sV    → Service/Version Detection
-sC    → Default NSE Scripts
-O     → OS Detection

اگر بخوای خروجی خیلی کامل‌تری بگیری:

nmap -A 192.168.1.10

-A مجموعه‌ای از قابلیت‌های تشخیص Version، OS، Traceroute و NSE را فعال می‌کند.

دسته‌بندی مهم NSE
به‌صورت ذهنی اینطوری حفظش کن:

NSE
│
├── discovery     → جمع‌آوری اطلاعات
├── default       → اسکریپت‌های پیش‌فرض
├── safe          → بررسی‌های کم‌خطرتر
├── version       → کمک به تشخیص Version
├── vuln          → بررسی آسیب‌پذیری
├── auth          → Authentication
├── brute         → Password Guessing
├── broadcast     → Discovery در LAN
├── intrusive     → تست‌های تهاجمی‌تر
├── exploit       → Exploitation
├── dos           → تست‌های DoS
├── malware       → بررسی نشانه‌های Malware
├── fuzzer        → Fuzzing
└── external      → استفاده از سرویس‌های خارجی

این دسته‌بندی رسمی NSE است.
چند دستور طلایی برای Lab

# Default Enumeration
nmap -sC -sV 192.168.1.10

# Banner
nmap --script=banner 192.168.1.10

# HTTP
nmap -p80,443 --script=http-title,http-headers 192.168.1.10

# SSL/TLS
nmap -p443 --script=ssl-cert,ssl-enum-ciphers 192.168.1.10

# SSH
nmap -p22 --script=ssh-hostkey,ssh2-enum-algos 192.168.1.10

# SMB
nmap -p445 --script=smb-os-discovery,smb-protocols 192.168.1.10

# DNS
nmap -p53 --script=dns-recursion 192.168.1.10

# Vulnerability
nmap -sV --script=vuln 192.168.1.10

# Vulners
nmap -sV --script=vulners 192.168.1.10

# DHCP Discovery - LAN Lab
nmap --script=broadcast-dhcp-discover

# Help
nmap --script-help http-title

# Update NSE database
sudo nmap --script-updatedb

@ModernLan

وزیر ارتباطات و فناوری اطلاعات گفته محدودیت‌های مربوط به IPv6 به‌زودی تعیین تکلیف میشه. طبق گفته ایشون، با توجه به اینکه شبکه ملی اطلاعات داره بیشتر با تحولات فناوری جلو میره، موضوع استفاده از IPv6 هم باید جدی‌تر دنبال بشه و محدودیت‌هایی که الان سر راهش وجود داره مشخص بشه. IPv6 همون نسل جدید پروتکل IP هست که برای حل مشکل کمبود آدرس‌های IPv4 طراحی شده و با فضای آدرس‌دهی بسیار بزرگ‌تر، امکانات بهتری برای توسعه شبکه‌ها، اینترنت اشیا، دیتاسنترها و سرویس‌های جدید فراهم می‌کنه. در واقع بحث فقط عوض کردن IPv4 با IPv6 نیست؛ پیاده‌سازی درستش روی ISP، روترها، دیتاسنترها، DNS، فایروال‌ها و تجهیزات شبکه نیاز به برنامه‌ریزی و هماهنگی داره. حالا باید دید تصمیم نهایی درباره محدودیت‌های IPv6 چی خواهد بود و این موضوع در عمل چقدر روی توسعه زیرساخت شبکه کشور تأثیر میزاره.

@ModernLan

#IPv6 #Networking #NetworkSecurity #ModernLAN

🛡️ WAF چیه و کجا قرار می‌گیره؟

WAF مخفف Web Application Firewall
یعنی یه فایروال تخصصی برای محافظت از برنامه‌ها و سایت‌های تحت وبه. اگه خیلی خودمونی بخوایم نگاه کنیم، فایروال معمولی بیشتر حواسش به ترافیک شبکه، IP، Port و Connectionهاست، ولی WAF میاد خود درخواست‌های HTTP/HTTPS رو نگاه می‌کنه و بررسی می‌کنه ببینه داخل درخواست چیزی مشکوک یا مخرب وجود داره یا نه؛ مثلاً حملاتی مثل SQL Injection، XSS، Path Traversal، Command Injection و بعضی الگوهای غیرعادی دیگه.


حالا WAF معمولاً کجا قرار می‌گیره؟ بین اینترنت و Web Server؛ یعنی کاربر وقتی می‌خواد به سایت وصل بشه، درخواستش اول به WAF می‌رسه، WAF درخواست رو بررسی می‌کنه و اگه سالم باشه می‌فرستتش سمت سرور، ولی اگه مخرب تشخیص داده بشه همون‌جا جلوی درخواست رو می‌گیره و اجازه نمی‌ده به Application برسه.

مثلاً فرض کن مهاجم یه درخواست این شکلی بفرسته:
GET /search?q=' OR 1=1--، WAF
می‌تونه این Request رو بررسی کنه و با توجه به Ruleها و الگوهای تشخیص حمله، اون رو مشکوک تشخیص بده و Block کنه. در معماری‌های واقعی هم ممکنه WAF قبل یا بعد از Load Balancer قرار بگیره و حتی خودش نقش Reverse Proxy رو داشته باشه.

مثلاً مسیر ترافیک می‌تونه این شکلی باشه:

Internet → Firewall → WAF → Load Balancer → Web Server → Application → Database. البته WAF

قرار نیست جای فایروال شبکه رو بگیره؛ این دوتا مکمل همدیگه‌ان. فایروال شبکه بیشتر از خود زیرساخت و ترافیک شبکه محافظت می‌کنه و WAF تمرکزش روی لایه Web و درخواست‌هایی مثل HTTP/HTTPS.

یه نکته مهم دیگه هم اینه که WAF می‌تونه به شکل Appliance، نرم‌افزاری یا Cloud ارائه بشه و تو مدل Cloud حتی ممکنه DNS دامنه رو طوری تنظیم کنیم که درخواست کاربر اول وارد سرویس WAF بشه و بعد از بررسی به سرور اصلی برسه.

@ModernLan

نسخه جدید هسته متن‌باز و رایگان Aether منتشر شده و این بار قابلیت‌های Tor هم بهش اضافه شده. یعنی الان می‌تونین از Tor به چند حالت مختلف استفاده کنین؛ اتصال مستقیم به Tor، اتصال Tor از طریق WARP و حتی حالت معکوس. جالب‌تر اینکه Bridgeهای Tor هم می‌تونن به‌صورت خودکار از BridgeDB دریافت بشن و Aether امکان امتحان کردن Bridgeهایی مثل Snowflake و WebTunnel رو هم داره. یه قابلیت دیگه‌ای که اضافه شده MASQUE-in-MASQUE هست؛ یعنی به‌جای اینکه فقط یه لایه MASQUE داشته باشین، دو لایه MASQUE پشت سر هم برقرار میشه. این کار می‌تونه باعث بشه مسیر و رنج IP خروجی با حالت MASQUE معمولی متفاوت باشه و طبق توضیحات پروژه، در این حالت دیگه خروجی الزاماً از رنج IP ایران Cloudflare نمیاد و رفتار اتصال تا حدی شبیه متد Gool میشه. خلاصه Aether توی این نسخه یه قدم جدی‌تر رفته سمت ترکیب روش‌های مختلف تونل و مسیریابی برای شرایطی که اتصال معمولی جواب نمیده.


👉 github.com/CluvexStudio/Aether/releases



@ModernLan

چین و مهندسی فیلترینگ در ایران؛ از DPI تا اختلال سیستماتیک اینترنت!

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

یکی از قطعات مهم این داستان DPI یا Deep Packet Inspection ـه. DPI رو می‌تونی مثل یه سیستم بازرسی خیلی پیشرفته در مسیر ترافیک تصور کنی. وقتی ترافیک کاربر از شبکه ISP یا اپراتور رد میشه، تجهیزات می‌تونن مشخصات جریان ارتباطی رو بررسی کنن؛ مثلاً IP مقصد، پورت، پروتکل، مشخصات TLS و در بعضی شرایط اطلاعات قابل مشاهده داخل ترافیک. بعد بر اساس Policy تصمیم گرفته میشه که این ارتباط عبور کنه، Drop بشه، Reset بشه یا سرعتش محدود بشه. گزارش‌های منتشرشده درباره ایران، فناوری DPI ارائه‌شده یا مرتبط با شرکت‌هایی مثل Huawei و ZTE رو یکی از اجزای مهم این معماری معرفی می‌کنن.

حالا قسمت مهم‌تر ماجرا اینه که فیلترینگ فقط «بلاک کردن یه IP» نیست. فرض کن کاربر می‌خواد به یک سرویس خارجی وصل بشه. درخواست DNS میره، آدرس IP گرفته میشه، بعد ارتباط TCP یا UDP برقرار میشه و در HTTPS هم TLS Handshake اتفاق میفته. سیستم کنترل شبکه می‌تونه در چند نقطه مختلف روی این زنجیره دخالت کنه. حتی وقتی محتوای اصلی HTTPS رمزنگاری شده، بعضی Metadataها و مشخصات ارتباط، مثل SNI در TLS، در معماری‌های خاص می‌تونن برای اعمال Policy استفاده بشن. مطالعات فنی منتشرشده درباره فیلترینگ ایران، دخالت در DNS، HTTP، SNI در HTTPS و حتی ترافیک UDP/QUIC رو گزارش کرده‌اند.

یعنی ممکنه تو مرورگرت ببینی اینترنت «وصله»، ولی یک سایت خاص باز نمیشه؛ بعد فکر کنی مشکل DNS یا اینترنت خودته. در حالی که ممکنه اتصال عمداً در یکی از مراحل ارتباط قطع شده باشه. حتی میشه کاری کرد که ارتباط TCP شروع بشه ولی قبل از کامل شدن Session، اتصال با Packetهای Reset مختل بشه. نتیجه برای کاربر ساده است: «اینترنت خرابه»، ولی از دید شبکه یک Policy عمداً اجرا شده.

یه مرحله بالاتر، بحث Throttling یا کاهش عمدی کیفیت ارتباطه. لازم نیست همیشه سرویس رو کامل Block کنی. میشه با ایجاد Packet Loss، افزایش Latency، محدود کردن Bandwidth یا دستکاری مسیر، کیفیت سرویس رو آن‌قدر پایین آورد که عملاً استفاده ازش سخت یا غیرممکن بشه. این مدل از نظر فنی خیلی متفاوت از قطع کامل اینترنت به نظر میاد، ولی نتیجه برای کاربر می‌تونه تقریباً همون باشه: سرویس باز میشه اما ویدیو لود نمیشه، VPN ناپایدار میشه، تماس تصویری قطع میشه یا اتصال مرتب Timeout میخوره.

حالا می‌رسیم به قسمت خیلی مهم‌تر یعنی «اختلال سیستماتیک». وقتی کنترل فقط روی یک فایروال کوچک نیست و در لایه‌های مختلف ISP، اپراتور، Gatewayهای بین‌المللی و زیرساخت داخلی توزیع شده باشه، دولت می‌تونه به جای اینکه تک‌تک سایت‌ها رو ببنده، خودِ مسیر دسترسی به اینترنت جهانی رو کنترل کنه.

اینجاست که NIN یا شبکه ملی اطلاعات اهمیت پیدا می‌کنه. ایده فنی اینه که یک بخش بزرگ از سرویس‌های داخلی داخل یک فضای شبکه‌ای داخلی قابل دسترس باقی بمونن، حتی وقتی دسترسی به اینترنت بین‌المللی محدود شده. بنابراین «قطع اینترنت» لزوماً به معنی خاموش شدن همه شبکه‌ها نیست؛ میشه مسیر Global Internet رو محدود کرد ولی سرویس‌های داخلی، بانک‌ها، سامانه‌های دولتی و بعضی سرویس‌های مجاز همچنان کار کنن. گزارش Financial Times هم توضیح داده که ساختار شبکه کنترل‌شده داخلی ایران، امکان جدا کردن ارتباطات خارجی از سرویس‌های داخلی رو آسان‌تر کرده است.

این مدل از نظر معماری خیلی شبیه یک شبکه Enterprise فوق‌العاده بزرگه که مدیر شبکه تصمیم گرفته چه VLAN یا Segmentهایی به بیرون دسترسی داشته باشن و چه Segmentهایی فقط داخل شبکه خودشون کار کنن؛ با این تفاوت که اینجا مقیاسش یک کشوره.

حالا نقش چین دقیقاً کجاست؟ بخشی از شرکت‌های چینی، مخصوصاً Huawei و ZTE، سال‌ها در زیرساخت مخابرات و شبکه ایران حضور داشته‌اند و طبق گزارش‌های منتشرشده، فناوری‌های DPI و تجهیزات مرتبط با پایش و کنترل ترافیک نیز در این همکاری‌ها مطرح بوده‌اند. در کنار اون، شرکت‌هایی مثل Tiandy و Hikvision بیشتر در حوزه نظارت تصویری و تشخیص چهره مطرح‌اند؛ یعنی این همکاری فقط محدود به Packet و Router نیست و یک اکوسیستم گسترده‌تر نظارت دیجیتال شکل میده.

یه نکته خیلی مهم هم این وسط وجود داره: اینکه بگیم «چین کل فیلترینگ ایران رو ساخته» دقیق نیست. ایران خودش شرکت‌ها، سامانه‌ها و سیاست‌های داخلی زیادی داره و معماری نهایی حاصل ترکیب فناوری خارجی، تجهیزات داخلی، اپراتورها و تصمیمات حکومتیه. چیزی که درباره چین مهمه، فراهم کردن بخشی از فناوری و همچنین انتقال یک مدل فکریه که بهش Cyber Sovereignty یا حاکمیت سایبری گفته میشه؛ یعنی اینترنت داخل مرزهای کشور باید تا حد زیادی تحت کنترل حاکمیت باشه. ARTICLE 19 این شباهت فکری و فنی بین مدل چین و ایران رو یکی از محورهای اصلی همکاری دو کشور می‌دونه.

در واقع اگر کل داستان رو توی یک دیاگرام ببینی، تقریباً با چنین معماری‌ای طرفی:

User
↓
Mobile / ISP
↓
DNS / Filtering
↓
DPI / Traffic Classification
↓
Firewall / Policy Enforcement
↓
National Network ─────→ Domestic Services
│
↓
International Gateway
│
↓
Global Internet

در حالت عادی، ترافیک از User به سمت اینترنت جهانی میره؛ ولی در یک معماری کنترل‌شده، چند نقطه وجود داره که میشه روی اون‌ها Policy اعمال کرد. یکی DNS، یکی Gateway، یکی DPI، یکی Routing و یکی هم خود اپراتور.

و اینجاست که «اختلال سیستماتیک» معنی واقعی پیدا می‌کنه. لازم نیست یک نفر بشینه تک‌تک سایت‌ها رو خاموش کنه. اگر کنترل در سطح زیرساخت باشه، میشه Policy رو روی میلیون‌ها Connection اعمال کرد. مثلاً یک دسته IP Block بشن، یک Protocol محدود بشه، یک Domain از طریق DNS مختل بشه، یک نوع TLS Session قطع بشه، ترافیک UDP محدود بشه یا مسیر بین‌المللی تغییر کنه.

حتی میشه دسترسی کاربران رو به صورت Selective مدیریت کرد؛ یعنی یک کاربر یا سازمان دسترسی داشته باشه ولی کاربر عادی نداشته باشه. گزارش‌های مربوط به معماری جدید کنترل اینترنت ایران از حرکت به سمت مدل‌هایی صحبت می‌کنن که دسترسی عمومی بیشتر شبیه «Whitelist» میشه؛ یعنی به جای اینکه همه چیز آزاد باشه و چند مورد Block بشن، پیش‌فرض می‌تونه محدود باشه و فقط سرویس‌های مشخص اجازه عبور داشته باشن.

پس اگر بخوام خیلی خلاصه بگم، نقش چین رو باید در سه لایه ببینی:

لایه اول: تجهیزات؛ تجهیزات مخابراتی، شبکه، مانیتورینگ و فناوری‌های مرتبط.

لایه دوم: فناوری کنترل؛ DPI، Traffic Classification، Filtering، Monitoring و مدیریت متمرکز ترافیک.

لایه سوم که شاید از همه مهم‌تر باشه: مدل معماری؛ اینکه اینترنت به جای یک شبکه آزاد و End-to-End، تبدیل بشه به یک شبکه تحت Policy که حاکمیت بتونه تعیین کنه چه کسی، از کجا، با چه پروتکلی و به چه سرویسی وصل بشه.


@ModernLan

اگر بخوام خیلی فنی براتون توضیح بدم، Load Balancer وسط کاربر و چند تا سرور قرار می‌گیره و تصمیم می‌گیره هر درخواست بره سمت کدوم سرور.
مثلاً این معماری رو داشته باش:

کاربران
                │
                ▼
        ┌────────────────┐
        │  Load Balancer │
        └───────┬────────┘
          ┌─────┼─────┐
          ▼     ▼     ▼
       Server1 Server2 Server3
       10.0.0.11  .12    .13

کاربر مثلاً به این آدرس می‌زنه:

https://example.com

DNS
معمولاً IP مربوط به Load Balancer رو برمی‌گردونه، نه IP مستقیم سرورها. درخواست میاد روی LB و اون بررسی می‌کنه کدوم Backend شرایط بهتری برای دریافت این Request داره.
روش‌های اصلی تقسیم ترافیک
1. Round Robin
خیلی ساده درخواست‌ها رو به ترتیب پخش می‌کنه:

Request 1 → Server 1
Request 2 → Server 2
Request 3 → Server 3
Request 4 → Server 1
Request 5 → Server 2

برای زمانی خوبه که سرورها تقریباً قدرت مشابهی داشته باشن.
2. Weighted Round Robin
به هر سرور وزن می‌دی:

Server 1 → Weight 5
Server 2 → Weight 3
Server 3 → Weight 1

پس Server 1 درخواست بیشتری می‌گیره، چون قوی‌تره.
3. Least Connections
Load Balancer
تعداد Connectionهای فعال هر سرور رو بررسی می‌کنه و درخواست جدید رو معمولاً می‌فرسته سمت سروری که Connection کمتری داره:

Server 1 → 80 connections
Server 2 → 25 connections  ← Request جدید
Server 3 → 60 connections

برای سرویس‌هایی که Connectionها مدت‌زمان متفاوتی دارن خیلی کاربردیه.
4. IP Hash / Consistent Hashing
بر اساس IP کاربر تصمیم می‌گیره درخواست به کدوم Backend بره:

Client A → Server 1
Client B → Server 3
Client C → Server 2

این روش می‌تونه باعث بشه یک Client تا حد زیادی به یک Backend مشخص هدایت بشه؛ مخصوصاً وقتی Session Persistence / Sticky Session لازم داری.

اما Load Balancer فقط «تقسیم» نمی‌کنه
یکی از مهم‌ترین قسمت‌ها Health Check هست.
فرض کن سه سرور داریم:

Server 1 → UP
Server 2 → UP
Server 3 → DOWN

LB مرتب Backendها رو Check می‌کنه؛ مثلاً:

GET /health

یا حتی TCP Connection روی پورت خاص:

TCP/443 → Server

اگر Server 3 جواب نده، Load Balancer اون رو از Pool خارج می‌کنه:

Load Balancer
                  /       \
                 ▼         ▼
             Server 1   Server 2
                 X
             Server 3
              DOWN

در نتیجه کاربر حتی ممکنه اصلاً متوجه خراب شدن Server 3 نشه.
یک نکته مهم‌تر: L4 و L7
Load Balancerها معمولاً در دو سطح معروف کار می‌کنن:
L4 Load Balancer
بر اساس اطلاعاتی مثل:

Source IP
Destination IP
Source Port
Destination Port
TCP/UDP

تصمیم می‌گیره.
مثلاً:

TCP :443 → Backend Pool

سریع‌تره چون لازم نیست محتوای HTTP رو بررسی کنه.
L7 Load Balancer
تا سطح Application میاد و می‌تونه چیزهایی مثل این‌ها رو ببینه:

HTTP Method
URL
Host Header
Cookie
HTTP Header

مثلاً:

example.com/api/*  → API Servers

example.com/images/* → Image Servers

example.com/shop/* → Shop Servers

پس L7 می‌تونه خیلی هوشمندتر Route کنه.
در عمل، Load Balancer می‌تونه علاوه بر تقسیم بار، Health Check، SSL/TLS Termination، Session Persistence، Routing، Rate Limiting و حتی بعضی قابلیت‌های امنیتی رو هم انجام بده.


@ModernLan

🔹 iSCSI چیست و چطور کار می‌کند؟

فناوری iSCSI مخفف Internet Small Computer Systems Interface هست و یه پروتکله برای اینکه بتونیم Storage رو از طریق شبکه IP در اختیار سرورها قرار بدیم؛ یعنی به‌جای اینکه هارد مستقیماً داخل خود سرور باشه، سرور از طریق شبکه به یک Storage مرکزی وصل میشه و یک فضای ذخیره‌سازی رو مثل یک دیسک در اختیار می‌گیره.
در iSCSI دو طرف اصلی داریم: Initiator و Target. Initiator معمولاً روی سروری قرار داره که می‌خواد به Storage دسترسی داشته باشه و Target سمت Storage قرار داره و فضای ذخیره‌سازی رو ارائه می‌کنه. Storage می‌تونه یک LUN بسازه و اون LUN رو از طریق iSCSI در اختیار سرور قرار بده.
مثلاً فرض کن یه شرکت چندتا سرور VMware داره و یک Storage مرکزی با ظرفیت چند ترابایت. به‌جای اینکه روی هر سرور کلی هارد نصب کنیم، Storage رو به شبکه وصل می‌کنیم و سرورها از طریق iSCSI به LUNهای اون دسترسی پیدا می‌کنن.
مسیر ارتباطی تقریباً این شکلیه:

Server
  │
  │ iSCSI Initiator
  │
  ▼
Ethernet / IP Network
  │
  ▼
Switch
  │
  ▼
Storage
  │
  │ iSCSI Target
  ▼
LUN

نکته مهم اینه که iSCSI روی TCP/IP کار می‌کنه و پورت استانداردش TCP 3260 هست. بنابراین برخلاف تکنولوژی‌هایی مثل Fibre Channel، می‌تونه روی زیرساخت Ethernet و شبکه IP پیاده‌سازی بشه.

حالا LUN چیه؟ LUN رو می‌تونی مثل یه فضای Block-Level در نظر بگیری که Storage به سرور ارائه میده. سیستم‌عامل سرور اون رو به شکل یک Disk می‌بینه و می‌تونه روش Partition و File System ایجاد کنه.

اینجا تفاوت iSCSI با چیزهایی مثل SMB و NFS هم مهم میشه. SMB/NFS بیشتر برای File-Level Access استفاده میشن؛ یعنی سیستم‌عامل از یک Share به فایل‌ها دسترسی پیدا می‌کنه، ولی iSCSI در سطح Block Storage کار می‌کنه و سیستم‌عامل مقصد می‌تونه LUN رو مثل یک دیسک مدیریت کنه.

در محیط‌های حرفه‌ای معمولاً iSCSI رو با Multipathing هم پیاده‌سازی می‌کنن؛ یعنی بین سرور و Storage چند مسیر شبکه وجود داره تا اگر یک لینک یا مسیر قطع شد، ارتباط از مسیر دیگه ادامه پیدا کنه و Availability بالاتر بره.

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

iSCSI
یعنی ارائه Storage در سطح Block از طریق شبکه IP، با استفاده از TCP/IP.
📌 مفاهیم مهمی که کنار iSCSI باید بلد باشی:
Initiator | Target | LUN | IQN | TCP/3260 | CHAP | Multipathing | Block Storage
#NetworkPlus #Networking #iSCSI #Storage #SAN #VMware #NetworkSecurity

🔗 @ModernLAN

Anycast چیست؟

Anycast چیست؟


یک روش آدرس‌دهی و مسیریابی در شبکه است که در آن یک IP یکسان روی چند سرور یا چند نقطه مختلف شبکه استفاده می‌شود. وقتی کاربر به آن IP متصل می‌شود، ترافیک معمولاً به سمتی هدایت می‌شود که از دید پروتکل مسیریابی، بهترین یا نزدیک‌ترین مسیر را دارد.

مثلاً فرض کن یک سرویس DNS سه سرور دارد:

DNS Server 1 → 8.8.8.8 → اروپا
DNS Server 2 → 8.8.8.8 → آمریکا
DNS Server 3 → 8.8.8.8 → آسیا

کاربر در آسیا وقتی به 8.8.8.8 درخواست می‌فرستد، قرار نیست درخواستش به‌صورت تصادفی بین این سرورها پخش شود؛ Routing شبکه، مخصوصاً BGP در اینترنت، مسیر مناسب را انتخاب می‌کند.
Anycast چطور کار می‌کند؟
فرض کن یک شرکت در سه دیتاسنتر مختلف سرویس یکسانی دارد:

Internet
                  |
          +-------+-------+
          |       |       |
        BGP     BGP     BGP
          |       |       |
       London   Dubai   Tokyo
          |       |       |
       Server   Server  Server
       1.2.3.4 1.2.3.4 1.2.3.4

هر سه دیتاسنتر همان IP Prefix را از طریق BGP اعلام می‌کنند. روترهای اینترنت با توجه به جدول Routing و معیارهای BGP تصمیم می‌گیرند ترافیک را از کدام مسیر بفرستند.
بنابراین ممکن است یک کاربر در اروپا به سرور لندن برسد، درحالی‌که کاربر دیگری با همان IP به سرور دبی یا توکیو برسد.
Anycast چه مزیتی دارد؟
کاهش Latency:

کاربر معمولاً به یک نقطه نسبتاً نزدیک‌تر هدایت می‌شود.
High Availability:

اگر یکی از سایت‌ها از دسترس خارج شود، می‌توان Route مربوط به آن را Withdraw کرد تا ترافیک به سایت‌های دیگر برود.
مقاومت بهتر در برابر DDoS:

ترافیک حمله می‌تواند بین چند نقطه توزیع شود؛ به همین دلیل Anycast در سرویس‌های بزرگ مثل DNS و CDN بسیار رایج است.
مقیاس‌پذیری:

به‌جای اینکه تمام کاربران جهان به یک دیتاسنتر متصل شوند، سرویس در چند نقطه ارائه می‌شود.
Anycast با Unicast چه فرقی دارد؟
در Unicast معمولاً یک IP به یک مقصد مشخص اشاره می‌کند:

Client ───────→ Server
             10.10.10.10

ولی در Anycast چند مقصد مختلف می‌توانند همان IP را داشته باشند:

┌→ Server A
Client → 10.10.10.10├→ Server B
                    └→ Server C

البته انتخاب مقصد توسط Routing انجام می‌شود، نه اینکه خود IP تشخیص دهد کدام سرور نزدیک‌تر است.
یک نکته خیلی مهم
Anycast
الزاماً به معنی نزدیک‌ترین سرور از نظر جغرافیایی نیست.

روترها بر اساس مسیری که Routing Protocol انتخاب می‌کند تصمیم می‌گیرند. بنابراین ممکن است یک سرور از نظر جغرافیایی نزدیک‌تر باشد ولی به دلیل سیاست‌های BGP یا ساختار مسیرهای اینترنت، ترافیک به نقطه دیگری برود.

@ModernLan

🔎 از روی یک Packet مشکوک چطور بفهمیم حمله در حال رخ دادنه؟

تو Wireshark صرفاً با دیدن یک Packet نمی‌شه با قطعیت گفت حمله اتفاق افتاده؛ چیزی که مهمه Context و الگوی ترافیکه. یعنی باید ببینی این Packet از کجا اومده، به کجا میره، چه Flagهایی داره و در کنار Packetهای دیگه چه رفتاری ایجاد می‌کنه.
1️⃣ Source / Destination

اول Source IP و Destination IP رو بررسی کن. مثلاً اگر یک IP ناشناس داره در مدت کوتاه تعداد زیادی Connection به یک Server داخلی می‌زنه، می‌تونه نشونه‌ی Scan یا حمله باشه. مخصوصاً وقتی یک Source به تعداد زیادی Port مختلف روی یک سیستم درخواست می‌فرسته.
2️⃣ TCP Flags

TCP Flag
ها خیلی چیزها رو مشخص می‌کنن. مثلاً تعداد زیادی SYN بدون اینکه SYN, ACK مناسب از سمت مقصد برگرده، می‌تونه نشونه‌ی SYN Scan یا SYN Flood باشه. تعداد زیاد RST هم می‌تونه در کنار سایر شواهد نشون‌دهنده‌ی Scan یا Connectionهای ناموفق باشه. پس Flag رو باید به‌صورت Pattern بررسی کرد، نه یک Packet منفرد.

3️⃣ DNS

در DNS دنبال رفتارهای غیرعادی بگرد؛ مثلاً تعداد زیادی Query در مدت کوتاه، درخواست برای Domainهای تصادفی و طولانی، تعداد زیادی NXDOMAIN یا Subdomainهای غیرمعمول. این رفتارها می‌تونن در بعضی سناریوها با DNS Tunneling، Malware یا Domain Generation Algorithm (DGA) دیده بشن.
4️⃣ HTTP

اگر HTTP بدون رمزنگاری باشه، می‌تونی Requestها رو مستقیم بررسی کنی. دنبال چیزهایی مثل GET/POSTهای غیرعادی، تعداد زیاد Request به یک Endpoint، URIهای خیلی طولانی، پارامترهای مشکوک یا الگوهایی مثل تلاش برای دستکاری ورودی‌ها باش. البته وجود یک رشته مشکوک به‌تنهایی اثبات حمله نیست.
5️⃣ الگوی زمانی و حجم ترافیک

یکی از مهم‌ترین چیزها اینه که Packet رو تنها نبینی. مثلاً:
1 Request → Response → تمام
خیلی متفاوت از این حالته:
1000 SYN → یک Destination → در چند ثانیه
یا:
یک Client → تعداد زیادی DNS Query تصادفی → چندین Domain ناشناس
این‌جا احتمال یک رفتار غیرعادی خیلی بیشتره.
6️⃣ چند نشونه را کنار هم بگذار

مثلاً اگر ببینی:
Unknown IP → SYN → Port 22

Unknown IP → SYN → Port 80

Unknown IP → SYN → Port 443

Unknown IP → SYN → Port 445

Unknown IP → SYN → Port 3389
و این روند برای تعداد زیادی Port تکرار بشه، الگوی رفتاری بیشتر به Port Scanning شبیهه تا یک اتصال عادی.
در Wireshark می‌تونی از فیلترهایی مثل این‌ها برای شروع استفاده کنی:

tcp.flags.syn == 1 && tcp.flags.ack == 0

برای دیدن SYNهای بدون ACK.

tcp.flags.reset == 1

برای بررسی RSTها.

dns

برای مشاهده DNS Traffic.

http.request

برای HTTP Requestها.

ip.addr == 192.168.1.10

برای محدود کردن بررسی به یک IP خاص.

نکته مهم: تشخیص واقعی حمله معمولاً با یک Packet انجام نمی‌شه؛ باید Source/Destination + Flags + Port + Frequency + Payload + Sequence رفتارها رو کنار هم گذاشت. Wireshark بهت شواهد شبکه‌ای می‌ده، ولی برای تشخیص دقیق‌تر معمولاً باید این شواهد رو با لاگ‌های Firewall، IDS/IPS، DNS Server و سیستم مقصد هم تطبیق بدی.

@ModernLan

🔥 Reverse Proxy vs Forward Proxy فرقشون چیه؟


اگه بخوای خیلی ساده تفاوت Forward Proxy و Reverse Proxy رو بفهمی، باید بدونی که Forward Proxy نماینده‌ی Client هست ولی Reverse Proxy نماینده‌ی Server. توی Forward Proxy داستان از سمت کاربر شروع میشه؛ یعنی کاربر به‌جای اینکه مستقیم به اینترنت یا یک Server مقصد وصل بشه، درخواستش رو می‌فرسته سمت Proxy و Proxy اون درخواست رو از طرف کاربر به مقصد می‌رسونه.

ساختار کلیش میشه Client → Forward Proxy → Internet/Server. مثلاً توی یک شرکت ممکنه سیستم‌های کارمندان مستقیماً به اینترنت دسترسی نداشته باشن و تمام درخواست‌ها اول از یک Proxy سازمانی رد بشن. اونجا Proxy می‌تونه روی درخواست‌ها Policy اعمال کنه، دسترسی بعضی سایت‌ها رو محدود کنه، ترافیک رو Log کنه، Cache انجام بده و حتی باعث بشه مقصد به‌جای IP واقعی Client، IP مربوط به Proxy رو ببینه. پس Forward Proxy بیشتر برای کنترل و مدیریت دسترسی کاربران استفاده میشه.


حالا Reverse Proxy دقیقاً از اون طرف قضیه وارد میشه. اینجا Proxy جلوی Server قرار می‌گیره و Client معمولاً اصلاً خبر نداره پشت این Proxy چند تا Server وجود داره.

ساختارش میشه Client → Reverse Proxy → Backend Server. مثلاً کاربر وارد یک سایت میشه و درخواستش به Reverse Proxy می‌رسه؛ Reverse Proxy بررسی می‌کنه درخواست برای کدوم سرویس یا Server هست و بعد اون رو به یکی از Backend Serverها می‌فرسته. حتی ممکنه پشت Reverse Proxy ده‌ها Server وجود داشته باشه و Reverse Proxy درخواست‌ها رو بین اون‌ها تقسیم کنه؛ اینجاست که بحث Load Balancing مطرح میشه. علاوه بر این، Reverse Proxy می‌تونه TLS/SSL رو Terminate کنه، درخواست‌های مشکوک رو فیلتر کنه، Rate Limiting انجام بده، Cache داشته باشه و جلوی دسترسی مستقیم به Backend Serverها رو بگیره.

مثلاً فرض کن یک سایت بزرگ داری و سه تا Web Server پشتش هست. کاربر فقط Reverse Proxy رو می‌بینه و درخواستش میاد روی Reverse Proxy؛ بعد Proxy بر اساس الگوریتم Load Balancing مثل Round Robin یا Least Connections تصمیم می‌گیره درخواست رو به Server 1 یا Server 2 یا Server 3 بفرسته. در این حالت اگر یکی از Serverها Down بشه، Reverse Proxy می‌تونه درخواست‌ها رو به Serverهای سالم هدایت کنن.

پس اگه بخوای خیلی راحت تو ذهنت بمونه، Forward Proxy یعنی «من به جای Client میرم سمت اینترنت» و Reverse Proxy یعنی «من جلوی Server وایسادم و درخواست Client رو می‌گیرم و تصمیم می‌گیرم به کدوم Backend بفرستم». Forward Proxy بیشتر سمت کاربران و شبکه‌ی داخلی دیده میشه، ولی Reverse Proxy بیشتر سمت سرویس‌ها و Web Serverها قرار می‌گیره و چیزهایی مثل Load Balancer، WAF، TLS Termination، Cache و کنترل دسترسی معمولاً اونجا دیده میشن.

@ModernLan