🛡️ فعال‌سازی HSTS؛ قفل‌کردن سایت روی HTTPS

خیلی وقت‌ها کاربر یک بار با HTTP به سایت وصل می‌شود و اگر وسط راه مهاجم وارد شود، می‌تواند ترافیک را به سمت خودش هدایت کند (SSL Stripping). با HSTS به مرورگر می‌گوییم از این به بعد فقط و فقط با HTTPS وصل شود. 🔐

📌 ایده: یک هدر ساده سمت وب‌سرور اضافه می‌شود و ریسک Downgrade Attack را کم می‌کند.

مثال برای Nginx:

add_header Strict-Transport-Security \
    "max-age=31536000; includeSubDomains; preload" always;

نکات مهم ✅
• فقط وقتی گواهی TLS درست و پایدار دارید این هدر را فعال کنید.
• مقدار max-age هرچه بزرگ‌تر باشد، مرورگر مدت بیش‌تری فقط روی HTTPS قفل می‌ماند.
• پارامتر includeSubDomains یعنی تمام ساب‌دامین‌ها هم باید HTTPS باشند.
• قبل از اضافه‌کردن preload حتما مطمئن باشید همه چیز روی HTTPS بدون خطاست، چون برگشت از آن سخت است.

برای جزئیات بیش‌تر:
MDN: Strict-Transport-Security

امتحان این هدر روی محیط تست، یک قدم کوچک ولی مؤثر برای بالا بردن Security سطح وب‌سرویس است. 🚀

🔖 #Security #امنیت #HSTS #HTTPS #Web_Security #Nginx #TLS

👤 Developix

💎 Channel: @DevelopixNetwork

☑️ RTP (Real-time Transport Protocol)

❓ پروتکل RTP چیه و چه نقشی داره؟!

☎️ در شبکه‌های VoIP، بعد از اینکه پروتکل SIP تماس را برقرار می‌کند، پروتکل RTP وظیفه انتقال صدا را بر عهده می‌گیرد.
طبق تصویر، داخل هدرِ پکت‌های RTP پارامترهای مهمی وجود دارد:
➖ Time Stamp
این پارامتر زمان‌بندی نمونه‌های صوتی را مشخص می‌کند تا گیرنده بتواند صدا را در زمان درست پخش کند. همچنین با کمک Jitter Buffer می‌توان اثر جیتر (اختلاف تأخیر بین رسیدن پکت‌ها) را کاهش داد.
➖ Sequence Number
به هر پکت یک شماره ترتیبی اختصاص داده می‌شود تا در مقصد:
• ترتیب پکت‌ها مشخص باشد
• پکت لاس تشخیص داده شود
• پکت‌ها به ترتیب صحیح کنار هم قرار بگیرند
➖ Payload Type
نوع Media و Codec استفاده‌شده را مشخص می‌کند؛ مثل:
• G.729
• Opus
• Video Codec
📞 مثال واقعی:
وقتی دو نفر شروع به مکالمه می‌کنند، RTP برای هر مسیر صدا یک Stream جدا ایجاد می‌کند.
یعنی:
یک جریان RTP برای ارسال صدای شخص اول به نفر دوم و یک جریان RTP دیگر برای برگشت صدا از نفر دوم به شخص اول
به همین دلیل RTP را عملاً Full Duplex در نظر می‌گیرند.
پروتکل RTP معمولاً روی UDP و پورت‌های داینامیک فعالیت می‌کند. در بسیاری از تجهیزات بازه‌ای مثل 10000 تا 20000 تعریف می‌شود.

📞 بعد از برقراری جریان RTP، پروتکل RTCP هم فعال می‌شود. RTCP معمولاً روی پورتی نزدیک به RTP کار می‌کند و وظیفه‌اش بررسی کیفیت تماس و جمع‌آوری آمار ارتباط است.
➖ Packet Count
تعداد پکت‌های رد و بدل شده
➖ Packet Delay
مدت زمانی که طول می‌کشد یک پکت از مبدا به مقصد برسد
➖ Packet Loss
تعداد پکت‌های از دست‌رفته در ارتباط
➖ Jitter
اختلاف تأخیر بین رسیدن پکت‌ها
🔻 یاداوری مفهوم Jitter:
فرض کنید پکت اول با تأخیر ۲۰۰ms به مقصد برسد و پکت دوم با تأخیر ۱۰۰ms دریافت شود. در این حالت میزان Jitter برابر اختلاف این دو مقدار، یعنی ۱۰۰ms خواهد بود.

📌 جمع‌بندی:
پروتکل SIP تماس را برقرار می‌کند، RTP صدا و تصویر را منتقل می‌کند و RTCP کیفیت ارتباط را بررسی می‌کند.
اگر RTP به‌درستی کار نکند یا کیفیت شبکه ضعیف باشد، مشکلاتی مثل:
• صدای رباتی
• قطع و وصل شدن صدا
• تأخیر در مکالمه
• صدای یک طرفه
• و حتی قطع کامل تماس
در ارتباط VoIP به وجود می‌آید.


🔖 #Network, #شبکه

👤 Drwcsi

💎 Channel: @DevelopixNetwork

🔐 جلوگیری از SQL Injection با Prepared Statement

یکی از ساده‌ترین و مؤثرترین کارها برای امن‌کردن برنامه‌ تحت شبکه (API, Web App) استفاده از Prepared Statement / Parameterized Query است. این کار جلوی خیلی از SQL Injectionها را می‌گیرد حتی اگر validation سمت کلاینت دور زده شود. ⚠️

ایده‌اش این است که query و دادهٔ ورودی کاربر از هم جدا شوند؛ دیتابیس ورودی را فقط به‌عنوان داده می‌بیند، نه بخشی از دستور SQL.

نمونهٔ ساده در Python با کتابخانهٔ psycopg2 برای PostgreSQL:

import psycopg2

conn = psycopg2.connect(...)
cur = conn.cursor()

# ❌ اشتباه (ساخت query با string)
username = input("username: ")
q_bad = f"SELECT * FROM users WHERE username = '{username}'"
cur.execute(q_bad)  # آسیب‌پذیر به SQL Injection

# ✅ درست (استفاده از placeholder)
q_ok = "SELECT * FROM users WHERE username = %s"
cur.execute(q_ok, (username,))  # پارامتر جدا ارسال می‌شود
rows = cur.fetchall()

نکته‌ها:
• همیشه از placeholder مخصوص همان driver استفاده شود (مثل %s در psycopg2 یا ? در بعضی driverها).
• حتی روی internal panelها و سرویس‌های داخلی هم این عادت را رعایت کنید؛ اغلب حمله‌ها از داخل شبکه شروع می‌شود. 🚪

مرجع معتبر 👇
OWASP - SQL Injection Prevention


🔖 #Security #امنیت #SQL_Injection #Prepared_Statement #OWASP #Database_Security #Application_Security #Network_Security

👤 Developix

💎 Channel: @DevelopixNetwork

🚧 تانل EoIP

🔻 یه نوعی از تانلینگه که برخلاف اکثر پروتکل‌های دیگه، لایه ۲ رو حمل می‌کنه. یعنی فریم‌های لایه ۲ رو داخل یه بسته IP می‌ذاریم، از روی شبکه لایه ۳ روتش می‌کنیم و آخر مسیر دوباره همون فریم لایه ۲ رو سالم تحویل می‌گیریم.

🌀 حالا شاید براتون سوال شه که خب به چه دردی میخوره؟ به‌هرحال ما که داریم بسته رو می‌رسونیم به مقصد، چه فرقی می‌کنه چه لایه‌ای باشه؟
عرضم به خدمتتون که خیلی فرق می‌کنه. یه مثال کوچیک بخوام بزنم:
در شبکه‌های مبتنی بر PPPoE، مثل خیلی از سرویس‌های xDSL، ارتباط بین کلاینت و PPPoE Server باید در نهایت در قالب لایه ۲ برقرار بشه، چون PPPoE ذاتاً یک پروتکل لایه ۲ هست. حالا ممکنه بین مسیر به هزار و یک دلیل، مثل مدیریت راحت‌تر یا وجود تجهیزات مسیریاب، مجبور باشیم ترافیک رو از روی یک شبکه لایه ۳ عبور بدیم. اینجاست که EoIP به کمکمون میاد؛ فریم‌های لایه ۲ رو داخل بسته‌های IP کپسوله می‌کنه، از مسیر لایه ۳ عبورشون میده و در سمت مقابل دوباره همون فریم‌های لایه ۲ رو تحویل میده، طوری که از دید PPPoE Server انگار کلاینت همچنان روی همون شبکه لایه ۲ قرار داره.

🔅البته EoIP فقط برای PPPoE نیست و هر جا که نیاز داشته باشیم دو شبکه لایه ۲ رو از طریق یک بستر IP به هم متصل کنیم یا Bridge رو بین دو نقطه گسترش بدیم، می‌تونه کاربرد داشته باشه. انتقال VLAN، عبور Broadcast و Multicast یا جابه‌جایی ترافیک وابسته به MAC Address از جمله کاربردهای رایج اون هستند.

❎ این پروتکل علیرغم امکاناتی که در اختیارمون قرار میده و سادگی در راه‌اندازی، معایبی هم داره؛ مثل اینکه اختصاصی تجهیزات MikroTik هست و اگه یک طرف ارتباطتون سیسکویی یا وندور دیگه‌ای باشه، عملاً نمی‌تونید ازش استفاده کنید. همچنین به صورت پیش‌فرض هیچ رمزنگاری‌ای انجام نمی‌ده، بنابراین اگر امنیت ارتباط براتون مهمه، بهتره اون رو همراه با IPsec یا یک VPN امن دیگه استفاده کنید. علاوه بر این، به دلیل سربار ناشی از کپسوله‌سازی، ممکنه MTU کاهش پیدا کنه و در بعضی سناریوها نیاز به تنظیم MTU یا MSS داشته باشید.


🔖 #Network, #شبکه

👤 Drwcsi

💎 Channel: @DevelopixNetwork

🏆آفرهای جام جهانی ۲۰۲۶ هاست‌ایران فعال شد!

با کمپین «ترکیب برنده سایتت»، زیرساخت سایتت رو برای روزهای پرترافیک آماده کن:

🔥 ۲۵٪ تخفیف روی پلن‌های ۳ ماهه هاست اشتراکی ایران
⚡ ۵۰٪ تخفیف روی پلن‌های یک‌ماهه سرویس ابری در دیتاسنترهای تهران، مشهد و اهواز

🧠 مشاوره رایگان زیرساخت توسط کارشناسان هاست‌ایران
فرصت استفاده از تخفیف‌ها و ثبت فرم مشاوره محدود است.

📌 برای کپی کدهای تخفیف و ثبت‌نام در فرم مشاوره، روی لینک زیر کلیک کنید:

📌صفحه فرم مشاوره
📌تلگرام هاست‌ایران
📌بله هاست‌ایران


#هاست_ایران #سرور_ابری_هاست_ایران #هاست_اشتراکی #دیتاسنتر #مشاوره_زیرساخت #جام_جهانی2026

🟪 مکانیزم BFD در OSPF چیست؟
مکانیزمی برای تشخیص خیلی سریع افتادن همسایگی.

👈🏻 یعنی چی؟ یعنی در حالت عادی قطعا یک روتینگ پروتکل داینامیک، روشی برای تشخیص قطعی داره که اگر سه تا پکت hello در یک بازه زمانی مشخص (dead timer) بیاد و جوابی از طرف همسایه داده نشه، یعنی ارتباط قطع شده و میره سراغ مسیر جایگزین. اما BFD روشی بسیار سریعه که علاوه بر مزیت کاهش تشخیص مسیر جایگرین از چند ثانیه به چند میلی ثانیه، باعث میشه بار رویِ دوشِ روتینگ پروتکلمون هم سبک تر بشه، چون بخشی از پردازش مورد نیازش در یک پروتکل خارجی در حال انجام هست.

♥️ کانفیگش در سیسکو چجوریه؟
زیر اینترفیس میزنید:
bfd interval 50 min_rx 50 multiplier 3
ip ospf bfd
همین.

⚙️ ترجمه کامندی که گفتیم؟ هر ۵۰ میلی ثانیه یک بسته bfd ارسال میشه، حداقل زمان دریافت ۵۰ میلی ثانیه است و اگر ۳ بسته متوالی دریافت نشه، لینک Down در نظر گرفته میشه.
پس در این مثال حدودا در ۱۵۰ میلی ثانیه تشخیص خرابی اتفاق میفته .

- البته در ios های xr و xe کانفیگش متفاوته.

میکروتیک هم میتونید برید سرچ کنید چون من دوست ندارم بریم میکروتیک کانفیگ کنیم :)))

😵‍💫 شاید براتون سوال شه خب چه کاریه، میایم همون مکانیزم hello/dead رو کاستومایز میکنیم و تایمش رو کاهش میدیم که زودتر قطعی رو بفهمیم. اما این مکانیزم روی اکثر دیوایس ها قابلیت تغییر به میلی ثانیه نداره و در حداقلی ترین حالت میتونی در ۳ ثانیه Down شدن لینک رو تشخیص بدی در حالی که با bfd در ۱۵۰ میلی ثانیه انجام میشه.
همچنین با استفاده از BFD بار روی OSPF کاهش پیدا میکنه. البته این به معنای حذف پکت های hello نیست، صرفا فرض کنید اگه بخوایم برای افزایش سرعت، زمان dead رو از ۱۰ ثانیه به ۱ ثانیه تغییر بدیم در واقع داریم پکت های helloمون رو ۱۰ برابر میکنیم، بجای این کار، کارش رو برون سپاری می‌کنیم.

🎴سوال بعدی‌ای که پیش میاد اینه که اگه PLR داشته باشیم باعث نمیشه دائما بین مسیرها سوئیچ بشیم و بهره‌وری پائین بیاد؟
در واقع سوال اینه که ممکنه ما تاخیر یا پکت لاس داشته باشیم و چون فرصت کوتاهی برای جواب گرفتن از همسایه‌ها داریم، سریع اعلام قطعی بشه و بریم سراغ مسیر بکاپ، و دوباره روی مسیر جدید همین اتفاق تکرار میشه و دچار flap میشیم؛ پس نباید تایم خیلی کم انتخاب کنیم.

🪴 پس اگر بتونیم کانفیگ صحیحی داشته باشیم، مکانیزم اعلامی میتونه خیلی روی سرعت نهائی شبکه‌هامون تاثیر گذار باشه✨

🔖 #Security #امنیت

👤 Drwcsi

💎 Channel: @DevelopixNetwork

🛡️ راه‌اندازی سریع و امن VPN با WireGuard روی لینوکس

WireGuard یکی از سبک‌ترین و امن‌ترین راه‌حل‌های VPN امروزیه؛ هم روی سرور خیلی کم‌حجم و ساده است، هم روی کلاینت‌هات (موبایل، دسکتاپ، روتر) عالی جواب می‌ده. برای سناریوهایی مثل دسترسی امن به پنل‌های داخلی، SSH از بیرون خونه/شرکت یا دور زدن محدودیت آی‌پی روی سرویس‌ها خیلی کاربردیه.

در این پست، بر اساس داکیومنت رسمی WireGuard و مستندات Debian/Ubuntu، یه راه‌اندازی عملی و واقعی روی لینوکس رو مرور می‌کنیم:

🔧 سناریو
فرض کن یه VPS لینوکسی داری (مثلاً Ubuntu Server) و می‌خوای از هر جایی با لپ‌تاپ یا موبایل، به صورت امن به شبکه داخلی یا سرویس‌های روی اون VPS وصل بشی.

۱️⃣ نصب WireGuard روی Ubuntu/Debian

روی سرور (و بعداً روی کلاینت لینوکسی) دستور زیر رو اجرا کن:

sudo apt update
sudo apt install wireguard -y

این بسته طبق داکیومنت رسمی Ubuntu از مخازن خودش میاد و ماژول کرنل WireGuard هم روی کرنل‌های جدید به صورت پیش‌فرض پشتیبانی می‌شه.

۲️⃣ ساخت key pair برای سرور

داخل سرور، توی مثلاً /etc/wireguard:

cd /etc/wireguard
umask 077
wg genkey | tee server_private.key | wg pubkey > server_public.key

۳️⃣ ساخت key pair برای کلاینت

روی سیستم خودت (یا حتی روی سرور و بعد انتقال امن به کلاینت):

wg genkey | tee client_private.key | wg pubkey > client_public.key

حواست باشه private keyها هیچ‌وقت لاگ یا share نشن؛ خیلی‌ها اشتباهشون اینه که همین key رو کپی/پیست می‌فرستن توی چت‌ها 🙂

۴️⃣ کانفیگ سرور: فایل ‎/etc/wireguard/wg0.conf‎

یه مثال مینیمال (با فرض این‌که آدرس داخلی VPN رو 10.0.0.1/24 برای سرور می‌ذاری و 10.0.0.2 برای کلاینت):

[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <server_private_key_here>

[Peer]
PublicKey = <client_public_key_here>
AllowedIPs = 10.0.0.2/32

پورت 51820/UDP رو توی فایروال و روی VPS باز کن (روی ufw یا فایروال provider).

۵️⃣ کانفیگ کلاینت (مثلاً روی Linux)

روی کلاینت، فایل مشابه بساز:

[Interface]
Address = 10.0.0.2/24
PrivateKey = <client_private_key_here>
DNS = 1.1.1.1

[Peer]
PublicKey = <server_public_key_here>
Endpoint = <your_server_ip>:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

اینجا با AllowedIPs = 0.0.0.0/0 همه ترافیکت از داخل تونل عبور می‌کنه؛ برای سناریو دسترسی فقط به شبکه داخلی، می‌شه یه subnet خاص ست کرد.

۶️⃣ بالا آوردن تونل

روی هر دو طرف:

sudo wg-quick up wg0

و برای فعال شدن خودکار بعد از reboot:

sudo systemctl enable wg-quick@wg0

حالا از روی کلاینت، یه ping ساده:

ping 10.0.0.1

اگر جواب گرفتی، تونل OK هست. بعد می‌تونی SSH رو فقط روی آدرس داخلی VPN باز بذاری و surface حمله رو شدیداً کم کنی.

✨ نکته‌ی مهم امنیتی

حتماً private key رو محدود به root کن، لاگ‌ها رو چک کن و روی سرور از fail2ban یا معادلش برای سرویس‌های دیگه استفاده کن. WireGuard به‌خودی‌خود امنه، ولی بقیه سرویس‌ها همچنان نیاز به hardening دارن.

امتحانش روی یه VPS تستی خیلی ساده است؛ یه بار راهش بندازی، احتمالاً برای خیلی از سناریوهای شبکه و امنیت، ابزار پیش‌فرضت می‌شه 🔐

🔖 #Security #امنیت #WireGuard #VPN #Linux #Ubuntu #Network_Security #Server #CLI

👤 Developix

💎 Channel: @DevelopixNetwork

توی خیلی از شبکه‌ها هنوز روی سرورهای SSH پسوردهای ضعیف استفاده می‌شه و همین، در عمل می‌تونه تبدیل بشه به ساده‌ترین راه نفوذ 👀

امروز یه آموزش خیلی کاربردی از Kali Linux و ابزار Hydra رو مرور می‌کنیم که توی دنیای واقعی برای تست password strength سرویس SSH استفاده می‌شه. این کار توی Penetration Test مجاز یا Internal Audit کمک می‌کنه زودتر از Attacker، پسوردهای ضعیف رو پیدا کنی.

آموزش مرجع اصلی از خود Kali و ابزار Hydra هست:
kali.org/tools/hydra

سناریو واقعی 🔍
فرض کن توی شبکه داخلی یه سرور Linux با SSH داری که یوزرهای زیادی روی اون Login می‌کنن. می‌خوای مطمئن شی هیچ یوزری از پسورد ساده مثل 123456 یا password استفاده نکرده.

اینجا Hydra بهت اجازه می‌ده با یه Wordlist مشخص، روی SSH Password Brute Force (قانون‌مند) انجام بدی و ببینی کدوم یوزرها پسورد ضعیف دارن.

نکته مهم ⚠️
این کار فقط روی سیستم‌هایی انجام می‌شه که اجازه مکتوب برای تست داری (شرکت خودت، لابراتوار، سرور تست و ...). روی سیستم دیگران بدون اجازه، کاملاً غیرقانونی‌ه.

نمونه دستور کاربردی Hydra روی SSH 🛠

hydra -L users.txt -P passwords.txt \
  -t 4 -W 3 -f -vV ssh://192.168.1.10

توضیح سریع سوییچ‌ها:

🔹 -L users.txt ⇒ لیست یوزرنیم‌ها (هر خط یه user)

🔹 -P passwords.txt ⇒ Wordlist پسوردها؛ می‌تونی از لیست‌های آماده مثل rockyou.txt (توی Kali در مسیر /usr/share/wordlists/) استفاده کنی یا خودت بسازی.

🔹 -t 4 ⇒ تعداد parallel tasks. مقدار خیلی بالا نذار که هم سرویس رو overload نکنه، هم لاگ‌هات مشکوک نشه.

🔹 -W 3 ⇒ Timeout برای هر تلاش (ثانیه). توی شبکه‌های کند، یه مقدار بالاتر کمک می‌کنه.

🔹 -f ⇒ به محض پیدا کردن اولین credential معتبر، کار رو متوقف می‌کنه (برای جلوگیری از فشار اضافه روی سرویس).

🔹 -vV ⇒ خروجی verbose و detailed؛ برای دیباگ و دیدن روند تست خیلی کمک می‌کنه.

نکات عملی و امنیتی 🧠

• قبل از اجرا، روی سرور SSH حتماً Account Lockout Policy و Fail2ban رو بررسی کن؛ اگه خیلی aggressive باشن، ممکنه یوزرهای واقعی قفل بشن.

• بهتره تست رو توی Maintenance Window یا زمانی که Load سیستم پایینه انجام بدی.

• بعد از پیدا شدن پسوردهای ضعیف، حتماً:
– User رو مجبور کن پسورد رو عوض کنه.
– روی SSH، Password Authentication رو به نفع Public Key تا حد ممکن محدود کن.
– اگه می‌شه، روی SSH از Port Knocking، AllowUsers و محدودیت IP استفاده کن.

• لاگ‌ها رو فراموش نکن. روی Linux معمولاً لاگ SSH توی:
/var/log/auth.log یا
/var/log/secure
ذخیره می‌شه؛ بعد از تست، اونا رو برای نشانه‌های رفتار غیرعادی مرور کن.

این مدل تست ساده، توی خیلی از شبکه‌ها با همون چند پسورد پیش‌فرض، چندین اکانت ضعیف رو لو می‌ده. دفعه بعد که روی سرور SSH کار می‌کنی، یه بار توی محیط مجاز این سناریو رو اجرا کن و نتیجه رو با تیمت به اشتراک بذار 🚀

🔖 #Security #امنیت #Hydra #SSH #Brute_Force #Kali_Linux #Password_Audit #Network_Security #PenTest

👤 Developix

💎 Channel: @DevelopixNetwork

با Migration Boost هاست‌ایران، برای مهاجرت به سرور ابری دوباره هزینه ترافیک نده! 🚀

با خرید اولین سرور ابری غیرساعتی از **هاست‌ایران**، بسته ترافیک هدیه مهاجرت به‌صورت خودکار برای سرویس شما فعال می‌شود:

✅ حداقل ۱۰۰ گیگابایت ترافیک هدیه مهاجرت
✅ افزایش حجم هدیه متناسب با ظرفیت دیسک اولیه
✅ ترافیک آپلود رایگان
✅ بدون محدودیت زمانی

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

👇 مشاهده پلن‌های سرور ابری هاست‌ایران
hostiran.club/Migration
hostiran.club/Migration

🗺 نقشه گنج | بهترین مسیرهای یادگیری بعد از +Network

دوره +Network فقط شروع مسیره؛ اما سوال خیلی‌ها بعد از گذروندن این دوره اینه که:
حالا کدوم مسیر رو ادامه بدم؟ 🤔

شبکه؟ امنیت؟ سرور؟ لینوکس؟ Cloud؟ DevOps؟

در ایونت آنلاین روز یکشنبه بررسی می‌کنیم:
🔹 بعد از +Network چه مسیرهایی پیش روی توئه
🔹 هر مسیر برای چه افرادی مناسب‌تره
🔹 برای ورود به هر حوزه چه مهارت‌هایی لازمه

پس اگر بعد از +Network نمی‌دونی قدم بعدی چیه، این ایونت می‌تونه مسیرت رو روشن‌تر کنه!📍

📅11 مرداد | ساعت 19:30
💻 آنلاین و رایگان
👤با استاد حسام‌الدین موسوی‌زاده

برای شرکت در ایونت جزو اولین نفرات رزرو کن:
(بدون VPN وارد شو)
🔗https://l.cando.ac/ev-net100

🌻 آموزشگاه مهندسی کندو | We CanDo IT
@cando_ac

آیا CCNA خوندی، اما هنوز با تجهیزات واقعی شبکه کار نکردی؟🔥

اگه مفاهیم CCNA رو بلدی اما هنوز با تجهیزات واقعی کار نکردی، این کارگاه برای توئه!
در کارگاه ۸ ساعته CCNA، به صورت عملی سناریوهای واقعی VLAN، Routing، NAT، ACL و OSPF رو اجرا می‌کنی، با خطاهای شبکه روبه‌رو می‌شی و عیب‌یابیشون می‌کنی.
✅ کاملا عملی
✅ کار با تجهیزات واقعی
✅ همراهی استاد و منتور

📌 پیش‌نیاز: آشنایی با CCNA

این کارگاه به‌دلیل استقبال دوره قبل، برای بار دوم برگزار می‌شه👇
حالا ثبت‌نام کن:
https://l.cando.ac/network-workshop4
(بدون VPN وارد شو!)

🌻 آموزشگاه مهندسی کندو | We CanDo IT
@cando_ac

🛡 هدرهای امنیتی HTTP؛ دفاع خط اول وب‌اپ

خیلی وقت‌ها اپ امن نوشته می‌شه، ولی با چند تا HTTP Security Header ساده می‌شه سطح حمله رو کلی کم کرد؛ بدون تغییر جدی توی کد. این هدرها جلوی کلی XSS، Clickjacking و حملات مشابه رو می‌گیرن. 🚫

چند هدر خیلی کاربردی برای هر وب‌سرور:

• Content-Security-Policy (یا CSP): محدودکردن سورس اسکریپت‌ها و استایل‌ها، کاهش ریسک XSS.
• X-Frame-Options: جلوگیری از نمایش سایت داخل iframe و کاهش Clickjacking.
• X-Content-Type-Options: nosniff: جلوگیری از MIME Sniffing.

نمونه تنظیم روی Nginx:

add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy \
  "default-src 'self'; script-src 'self'; object-src 'none'" always;

بعد از تنظیم، با ابزارهایی مثل SecurityHeaders.com می‌شه هدرها رو تست و بهینه کرد.

این تغییرها سبک، سریع و برای هر اپ تحت وب جدی، تقریبا ضروری هستن؛ حتی اگه هنوز وقت Harden کامل سرور رو نداشته باشی. 🔐

🔖 #Security #امنیت #HTTP_Headers #Web_Security #CSP #Nginx #Best_Practices

👤 Developix

💎 Channel: @DevelopixNetwork