لیست کامل منابع CVE و PoC🧨

CVE Official List
https://github.com/CVEProject/cvelistV5

CVE Project
https://github.com/CVEProject

CVE PoC Index
https://github.com/0xMarcio/pocindex

CVE PoC Search Engine
https://github.com/secnotes/searchpoc

CVE PoC Repository Index
https://github.com/tg12/PoC_CVEs

CVE 2026 PoC
https://github.com/SecureWithUmer/CVE-2026-PoCs

Vulnerability PoC
https://github.com/fankh/vulnerability-poc

Exploit Intel CVE/PoC
https://github.com/exploitintel/eip-pocs-and-cves

CVE PoC Collection
https://github.com/d2cy/CVEs

CVE PoC Monitor
https://github.com/zulloper/cve-poc


@ModernLan

حس رضایت محض مدیریت کابلِ تمیز و مرتب. کارِ تمیز و بی‌نقص همیشه بهترین جلوه را دارد!

🔐 TLS Handshake چیه و موقع باز کردن یک سایت امن چه اتفاقی می‌افته؟

وقتی وارد سایتی مثل HTTPS می‌شیم، قبل از اینکه اطلاعاتی مثل رمز عبور، کوکی یا محتوای صفحه بین مرورگر و سرور رد و بدل بشه، مرورگر و سرور باید با هم یک ارتباط امن ایجاد کنن. به این فرآیند میگن TLS Handshake.

اول مرورگر یک پیام به اسم ClientHello برای سرور می‌فرسته و داخلش اطلاعاتی مثل نسخه‌های TLS قابل پشتیبانی، Cipher Suiteهای مورد قبول و در TLS 1.3 یک Key Share قرار می‌ده. سرور این اطلاعات رو بررسی می‌کنه و در ServerHello مشخص می‌کنه که از چه پارامترهایی برای ارتباط استفاده بشه و Key Share خودش رو هم ارسال می‌کنه.

بعد سرور Certificate خودش رو می‌فرسته. این Certificate شامل کلید عمومی سروره و توسط یک CA معتبر امضا شده تا کلاینت بتونه بررسی کنه واقعاً با همون سروری که ادعا می‌کنه در ارتباطه. بعد از اون CertificateVerify ارسال می‌شه که سرور با استفاده از Private Key خودش ثابت می‌کنه مالک Certificate مربوطه است.

حالا با استفاده از Key Exchange، معمولاً ECDHE، کلاینت و سرور می‌تونن به یک Secret مشترک برسن؛ بدون اینکه خود Secret رو مستقیم روی شبکه ارسال کنن. از این Secret، کلیدهای Session برای رمزنگاری ارتباط ساخته می‌شن.

در مرحله بعد پیام Finished رد و بدل می‌شه. این پیام عملاً به طرف مقابل می‌گه که مراحل Handshake با موفقیت انجام شده و از اینجا به بعد ارتباط با کلیدهای Session رمزنگاری می‌شه.

پس خیلی خلاصه، TLS Handshake سه کار اصلی انجام می‌ده:

🔹 احراز هویت سرور با Certificate
🔹 توافق روی کلیدهای رمزنگاری
🔹 آماده‌سازی یک کانال امن برای انتقال داده

در TLS 1.3 این فرآیند نسبت به TLS 1.2 ساده‌تر و سریع‌تر شده و معمولاً برای تکمیل Handshake به یک Round Trip نیاز داره.

یعنی وقتی مرورگرت HTTPS رو می‌بینه، قبل از اینکه اطلاعات حساس رو امن ارسال کنه، یک مذاکره رمزنگاری‌شده بین Client و Server انجام می‌شه تا مشخص بشه «با چه الگوریتمی ارتباط برقرار کنیم، سرور واقعاً کیه و کلیدهای رمزنگاری این ارتباط چی باشن.»

@ModernLAN

سوئیچ برای اینکه بفهمه یک Frame رو باید از کدوم Port خارج کنه، از MAC Address Table یا همون CAM Table استفاده می‌کنه.

مثلاً فرض کن این شبکه رو داریم:

PC-A ── Fa0/1 ──┐
                │
PC-B ── Fa0/2 ──┤ Switch
                │
PC-C ── Fa0/3 ──┘

وقتی PC-A برای PC-B فریم می‌فرسته، داخل Ethernet Frame یک Destination MAC وجود داره:

Destination MAC: BB:BB:BB:BB:BB:BB
Source MAC:      AA:AA:AA:AA:AA:AA

سوئیچ این کارها رو انجام میده:
1. یادگیری MACها
وقتی Frame از Fa0/1 وارد می‌شه، سوئیچ به Source MAC نگاه می‌کنه:

AA:AA:AA:AA:AA:AA → Fa0/1

یعنی می‌فهمه MAC مربوط به PC-A روی Port شماره 1 قرار داره.
بعد اگر از Port 2 فریمی با Source MAC مربوط به PC-B وارد بشه:

BB:BB:BB:BB:BB:BB → Fa0/2

سوئیچ کم‌کم یک جدول مثل این می‌سازه:

MAC Address              Port
--------------------------------
AA:AA:AA:AA:AA:AA        Fa0/1
BB:BB:BB:BB:BB:BB        Fa0/2
CC:CC:CC:CC:CC:CC        Fa0/3

2. بررسی Destination MAC
حالا Frame از PC-A وارد می‌شه:

Destination:
BB:BB:BB:BB:BB:BB

سوئیچ MAC Table رو نگاه می‌کنه:

BB:BB:BB:BB:BB:BB → Fa0/2

پس Frame رو فقط از Fa0/2 خارج می‌کنه.
یعنی سوئیچ برخلاف Hub، معمولاً Frame رو برای همه Portها نمی‌فرسته.
اگر MAC مقصد را نشناسد چی؟
اینجا قضیه جالب می‌شه.
اگر سوئیچ Destination MAC رو داخل جدولش پیدا نکنه، Frame رو Flood می‌کنه؛ یعنی از تمام Portهای مربوط به همان VLAN، به‌جز پورتی که Frame از آن وارد شده، می‌فرسته.
مثلاً:

PC-A ── Fa0/1 ── Switch
                  ├── Fa0/2 → PC-B
                  ├── Fa0/3 → PC-C
                  └── Fa0/4 → PC-D

اگر مقصد ناشناخته باشه:

Fa0/1 → Switch
          ↓
     ┌────┼────┐
     ↓    ↓    ↓
   Fa0/2 Fa0/3 Fa0/4

بعد که مقصد پاسخ بده، سوئیچ MAC اون دستگاه رو یاد می‌گیره و دفعات بعد Frame رو مستقیم به Port درست می‌فرسته.
یک نکته خیلی مهم
سوئیچ برای تصمیم‌گیری به Destination MAC نگاه می‌کنه، ولی برای یادگیری اینکه یک MAC روی کدام Port قرار دارد، به Source MAC فریم نگاه می‌کنه.
پس خلاصه‌اش:

Source MAC      → یادگیری
Destination MAC → تصمیم‌گیری برای Forward کردن
MAC Table       → MAC کجاست؟
Port            → Frame از کجا خارج شود؟

و این فرآیند یکی از پایه‌ای‌ترین مفاهیم Ethernet Switching محسوب میشه.

@ModernLan

کتاب آموزش فایروال Kerio Control | از صفر تا
پیاده‌سازی حرفه‌ای.


#KerioControl #Kerio #Firewall #UTM #NetworkSecurity #CyberSecurity #امنیت_شبکه #فایروال #کریو_کنترل #شبکه #Network #NetworkPlus #آموزش_شبکه #امنیت_سایبری #مدیریت_شبکه #ModernLAN

@ModernLan

Password 🔑 @ModernLan

NAT
معمولاً روی روتر یا فایروالِ مرزی شبکه (Edge/Gateway) انجام می‌شود؛ یعنی جایی که ترافیک از شبکه داخلی به شبکه خارجی می‌رود.
مثلاً:

PC
192.168.1.10
   │
   ▼
Switch
   │
   ▼
Router / Firewall
Inside: 192.168.1.1
Outside: 185.x.x.x
   │
   │  ← NAT اینجا اتفاق می‌افتد
   ▼
Internet

فرض کن PC این درخواست را بفرستد:

192.168.1.10:52341
        ↓
8.8.8.8:443

وقتی Packet به روتر می‌رسد، NAT آدرس خصوصی را به آدرس عمومی تبدیل می‌کند:

Before NAT:
192.168.1.10:52341 → 8.8.8.8:443

After NAT:
185.10.20.30:52341 → 8.8.8.8:443

روتر هم یک جدول NAT نگه می‌دارد تا وقتی پاسخ برگشت:

8.8.8.8:443
      ↓
185.10.20.30:52341
      ↓
192.168.1.10:52341

نکته مهم
NAT الزاماً فقط «داخل روتر» نیست؛ می‌تواند روی Firewall، Router، NAT Gateway یا تجهیزات ISP/CGNAT هم انجام شود.
مثلاً در اینترنت موبایل ممکن است چندین کاربر یک IP عمومی مشترک داشته باشند:

Phone A ─┐
Phone B ─┼──> ISP CGNAT ──> Internet
Phone C ─┘

اینجا NAT در سمت ISP انجام می‌شود، نه لزوماً روی مودم کاربر.

پس به‌صورت خلاصه: NAT در نقطه‌ای انجام می‌شود که دستگاه NATکننده بین دو فضای آدرس‌دهی قرار گرفته؛ معمولاً Gateway شبکه داخلی ↔ شبکه خارجی.

@ModernLan

​بدون فیبر نوری؟ این لینک مایکروویو چگونه داده‌ها را ارسال می‌کند!

چهار روش اصلی ارسال داده در شبکه؛ Unicast، Broadcast، Multicast و Anycast

Broadcast / Unicast / Multicast / Anycast
در شبکه وقتی یک دستگاه می‌خواد داده‌ای رو برای یک یا چند مقصد بفرسته، بسته بر اساس نوع آدرس‌دهی می‌تونه به شکل Unicast، Broadcast، Multicast یا Anycast ارسال بشه.

Unicast یعنی ارتباط یک به یک (1→1). فرستنده مشخصاً
یک مقصد رو انتخاب می‌کنه و بسته فقط برای همون مقصد ارسال میشه. مثلاً وقتی سیستم شما به IP یک Web Server وصل میشه، ترافیک بین کلاینت و همون سرور به صورت Unicast رد و بدل میشه. بیشتر ارتباطات معمول شبکه همین حالت رو دارن.

Broadcast
یعنی یک به همه (1→All). فرستنده بسته رو برای تمام دستگاه‌های یک Broadcast Domain ارسال می‌کنه و همه دستگاه‌ها بسته رو دریافت می‌کنن، حتی اگر برای بعضی‌ها کاربردی نداشته باشه. مثلاً در IPv4 آدرس 255.255.255.255 یک Local Broadcast محسوب میشه. یکی از نمونه‌های معروفش DHCP Discover هست؛ کلاینت هنوز IP نداره و برای پیدا کردن DHCP Server درخواست رو Broadcast می‌کنه. نکته مهم اینکه Router معمولاً Broadcast را از یک شبکه به شبکه دیگر Forward نمی‌کند.


Multicast
یعنی یک به چند عضو مشخص (1→Many). اینجا فرستنده بسته رو برای یک گروه خاص می‌فرسته و فقط دستگاه‌هایی که عضو اون Multicast Group هستن، ترافیک رو دریافت می‌کنن. مثلاً اگر 100 سیستم داخل شبکه باشن ولی فقط 10 سیستم عضو یک Multicast Group باشن، بسته برای همون 10 سیستم ارسال میشه، نه هر 100 دستگاه. پروتکل‌هایی مثل IGMP برای مدیریت عضویت کلاینت‌ها در گروه‌های Multicast استفاده میشن.

Anycast
کمی متفاوت‌تره و بیشتر در طراحی سرویس‌های توزیع‌شده دیده میشه. چند سرور می‌تونن یک آدرس مقصد مشترک داشته باشن و شبکه معمولاً بسته رو به یکی از نزدیک‌ترین/مناسب‌ترین مقصدها بر اساس Routing هدایت می‌کنه. مثلاً در زیرساخت DNS و CDN از Anycast استفاده میشه تا کاربر به یکی از نقاط سرویس‌دهنده که از نظر مسیر شبکه مناسب‌تره برسونه. بنابراین Anycast رو میشه به شکل یک به نزدیک‌ترین/مناسب‌ترین عضو (1→Nearest) در نظر گرفت.

خلاصه‌ اگر بخوای خیلی راحت تو ذهنت بمونه:

Unicast    → 1 → 1       یک فرستنده → یک مقصد
Broadcast  → 1 → All     یک فرستنده → همه
Multicast  → 1 → Many    یک فرستنده → اعضای یک گروه
Anycast    → 1 → Nearest یک فرستنده → یکی از چند مقصد مشابه

تفاوت اصلی Multicast و Broadcast اینه که Broadcast به کل Broadcast Domain میره، ولی Multicast فقط به اعضای یک گروه مشخص می‌رسه؛ در نتیجه Multicast برای توزیع ترافیک به تعداد زیادی گیرنده می‌تونه بهینه‌تر باشه.

@ModernLan

تاریخچه نسخه‌های ویندوز.

tcpdump🧨
یکی از ابزارهای مهم برای Capture و تحلیل ترافیک شبکه‌ست.

دستورات کاربردی tcpdump

# نمایش تمام ترافیک یک Interface
tcpdump -i eth0

# نمایش Interfaceهای موجود
tcpdump -D

# نمایش IP و Port به‌صورت عددی
tcpdump -i eth0 -n

# نمایش جزئیات بیشتر
tcpdump -i eth0 -nn -v

# گرفتن تعداد مشخصی Packet
tcpdump -i eth0 -c 100

# فقط ترافیک یک IP
tcpdump -i eth0 host 192.168.1.10

# ترافیک ورودی/خروجی مربوط به یک IP
tcpdump -i eth0 src host 192.168.1.10
tcpdump -i eth0 dst host 192.168.1.10

# فقط TCP
tcpdump -i eth0 tcp

# فقط UDP
tcpdump -i eth0 udp

# فقط ICMP
tcpdump -i eth0 icmp

# ترافیک یک Port
tcpdump -i eth0 port 80

# فقط Source Port
tcpdump -i eth0 src port 443

# فقط Destination Port
tcpdump -i eth0 dst port 53

# ترافیک بین دو IP
tcpdump -i eth0 host 192.168.1.10 and host 192.168.1.20

# ترکیب شرط‌ها
tcpdump -i eth0 tcp and port 443

# HTTP
tcpdump -i eth0 tcp port 80

# DNS
tcpdump -i eth0 udp port 53

# SSH
tcpdump -i eth0 tcp port 22

# نمایش Payload به‌صورت ASCII
tcpdump -i eth0 -A

# نمایش Hex و ASCII
tcpdump -i eth0 -XX

# ذخیره Capture برای Wireshark
tcpdump -i eth0 -w capture.pcap

# خواندن فایل Capture
tcpdump -r capture.pcap

# Capture ترافیک یک Subnet
tcpdump -i eth0 net 192.168.1.0/24

# نمایش فقط Packetهای TCP SYN
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'

# نمایش SYN و ACK
tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0'

چند ترکیب خیلی کاربردی

tcpdump -i eth0 -nn 'host 192.168.1.10 and tcp port 443'

tcpdump -i eth0 -nn 'src 192.168.1.10 and dst port 22'

tcpdump -i eth0 -nn 'not arp and not icmp'

tcpdump -i eth0 -nn -s 0 -w traffic.pcap

نکته مهم: برای Capture روی Interface معمولاً باید با sudo اجراش کنی:

sudo tcpdump -i eth0

اگر اسم کارت شبکه‌ات eth0 نیست، اول tcpdump -D یا ip link بزن و اسم Interface را پیدا کن.

@ModernLan

استار لینک چگونه حکمرانی فضای سایبری در ایران را بی اثر کرد؟

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

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

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


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

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


@ModernLan

ترتیب رنگ سیم‌های کابل شبکه (استاندارد T568B)

ترتیب رنگ سیم‌های کابل شبکه؛ استاندارد T568A