🛡 هدرهای امنیتی HTTP واقعاً چه کمکی به امنیت سایت می‌کنن؟

هدرهایی مثل CSP، HSTS، X-Content-Type-Options، Referrer-Policy و Permissions-Policy می‌تونن بخش مهمی از حملات سمت مرورگر مثل XSS، MIME Sniffing و Clickjacking رو محدود کنن؛ اما اگر اشتباه تنظیم بشن، حتی ممکنه بخشی از سایت رو از کار بندازن.

تو آموزش جدید آکادمی وان‌سرور، تنظیم امن این هدرها روی NGINX و Apache رو مرحله‌به‌مرحله با نمونه کانفیگ، روش تست و خطاهای رایج بررسی کردیم.

اگر VPS یا وب‌سرور مدیریت می‌کنید، این چک‌لیست رو از دست ندید. 👇

#آکادمی_وان_سرور #امنیت_وب #NGINX #Apache #HTTP

امشب بریم سراغ یه ابزار خیلی به‌دردبخور برای جابه‌جایی و بکاپ فایل بین سرورها: rsync؛ هم سریع‌تر از کپی کورکورانه‌ست، هم فقط تغییرات رو منتقل می‌کنه. 😄

ولی قبل از اینکه یه مسیر اشتباه بزنی و بعد با نگاه خیره به ترمینال بگی «من چی کار کردم؟»، اول --dry-run رو اجرا کن:

rsync -avh --dry-run /var/www/ user@SERVER:/backup/www/

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

rsync -avh /var/www/ user@SERVER:/backup/www/

یه نکته ریز ولی مهم: اسلش آخر مسیر فرق دارد. /var/www/ یعنی محتویات پوشه را منتقل کن؛ ولی /var/www می‌تواند خود پوشه www را هم داخل مقصد بسازد.

برای بکاپ‌های واقعی، مخصوصاً وقتی پای --delete وسطه، اول dry-run، بعد اجرا؛ این یکی از اون عادت‌هاییه که یه روز واقعاً نجاتت می‌ده. 😉

🔗 کانال وان سرور

#یک_دقیقه_سرور #VPS

گاهی سایت از بیرون کاملاً سالمه، ولی داخل VPS هر چی می‌زنی اسم دامنه resolve نمی‌شه. قبل از اینکه DNS دامنه رو زیر و رو کنی، اول مشخص کن مشکل از خود دامنه‌ست یا resolver سرور. 😄

اول پاسخ DNS رو مستقیم از یک resolver مشخص بگیر:

dig @1.1.1.1 example.com

بعد همون دامنه رو بدون تعیین resolver تست کن:

dig example.com

اگر دستور اول جواب درست می‌ده ولی دومی timeout یا خطای عجیب می‌ده، احتمال زیاد رکوردهای دامنه سالم‌اند و باید resolver خود VPS رو بررسی کنی. روی سیستم‌هایی که systemd-resolved دارند این دستور خیلی سریع وضعیت رو نشون می‌ده:

resolvectl status

به DNS Server فعال، اینترفیس شبکه و DefaultRoute دقت کن. برای یک تست تکمیلی هم می‌تونی بزنی:

resolvectl query example.com

اما اگر حتی dig @1.1.1.1 هم رکورد مورد انتظار رو برنمی‌گردونه، دیگه فقط گردن VPS ننداز 😅؛ رکورد DNS، nameserverها یا انتشار تغییرات دامنه رو بررسی کن.

خلاصه مسیر عیب‌یابی: اول resolver عمومی، بعد resolver خود VPS. همین مقایسه ساده خیلی وقت‌ها چند دقیقه حدس‌زدن رو حذف می‌کنه.

🔗 کانال وان سرور

#یک_دقیقه_سرور #VPS

گاهی سایت باز نمی‌شه و اولین مظنون هم طبق معمول Nginx یا اپلیکیشنه؛ ولی قبل از اینکه نصف سرویس‌ها رو restart کنی، با دو دستور ساده می‌تونی بفهمی داستان از کجاست. 😄

اول فقط هدرهای پاسخ رو ببین:

curl -I https://example.com

اینجا سریع status code و redirectها رو می‌بینی. مثلاً 200 یعنی پاسخ رسیده، 301/302 مسیر redirect رو نشون می‌ده و 502 معمولاً سرنخ خوبی برای بررسی upstream یا اپلیکیشن پشت وب‌سروره.

اگر هنوز معلوم نیست مشکل کجاست، حالت verbose رو اجرا کن:

curl -v https://example.com

این خروجی جزئیات اتصال، DNS resolve، برقراری TCP، مذاکره TLS و هدرهای درخواست و پاسخ رو نشون می‌ده. پس می‌تونی تشخیص بدی درخواست اصلاً به سرور می‌رسه، روی SSL گیر می‌کنه یا وب‌سرور جواب نامناسب می‌ده.

یه تست کاربردی دیگه وقتی پشت Nginx یا Reverse Proxy هستی اینه که upstream محلی رو مستقیم صدا بزنی:

curl -I http://127.0.0.1:8000

اگر این یکی 200 می‌ده ولی دامنه 502 برمی‌گردونه، مسیر عیب‌یابی خیلی کوتاه‌تر می‌شه؛ تنظیمات proxy و اتصال وب‌سرور به upstream رو بررسی کن، نه اینکه بی‌هدف همه‌چی رو خاموش روشن کنی. 😅

🔗 کانال وان سرور

#یک_دقیقه_سرور #VPS

گاهی یک فایل لاگ چند گیگی رو پاک می‌کنی، ls هم دیگه نشونش نمی‌ده، ولی df -h می‌گه فضای دیسک هنوز پره. اینجا معمولاً فایل واقعاً از دید فایل‌سیستم حذف شده، اما یک پردازش هنوز file descriptor اون رو باز نگه داشته. 😄

برای پیدا کردنش اول این دستور رو بزن:

sudo lsof +L1

یا اگر دنبال موارد حذف‌شده می‌گردی:

sudo lsof | grep '(deleted)'

به ستون‌های COMMAND، PID و SIZE/OFF دقت کن. مثلاً اگر یک لاگ حذف‌شده چند گیگی هنوز دست nginx یا یک سرویس اپلیکیشن باز مونده، تا وقتی اون پردازش descriptor رو نبنده فضا آزاد نمی‌شه.

نکته مهم: صرفاً چون PID رو پیدا کردی، مستقیم kill -9 نزن. اول مشخص کن پردازش مربوط به کدوم سرویسه و اگر امکانش هست با روش امن خودش reload یا restart کن؛ مخصوصاً روی سرور Production که یک kill عجولانه می‌تونه دردسر بزرگ‌تری از کمبود فضا بسازه.

بعد از بستن descriptor دوباره df -h رو چک کن. خیلی وقت‌ها همون چند گیگ گمشده همون لحظه برمی‌گرده.

🔗 کانال وان سرور

#یک_دقیقه_سرور #VPS

هشدار امنیتی برای مدیران سرورهای cPanel ⚠️

آسیب‌پذیری CVE-2026-67402 در سرویس MESSENGER مربوط به CSF می‌تواند در شرایطی به مهاجمِ بدون احراز هویت اجازه اجرای کد با سطح دسترسی کاربر Apache را بدهد. نسخه‌های CSF تا 16.30 در معرض خطرند، به‌خصوص وقتی Messenger v3 فعال باشد.

راهکار اصلی، به‌روزرسانی CSF به نسخه 16.31 یا جدیدتر است. اگر فعلاً امکان آپدیت ندارید، موقتاً گزینه MESSENGERV3 را در فایل تنظیمات CSF روی 0 بگذارید و سرویس‌های csf و lfd را restart کنید. جزئیات بررسی شرایط آسیب‌پذیری و دستورات لازم را در آموزش کامل بخوانید.

#امنیت_سرور

گاهی سرور ظاهراً اینترنت داره، پینگ هم جواب می‌ده، ولی یک سایت نصفه باز می‌شه، دانلود وسط کار می‌ایسته یا اتصال از داخل VPN/Tunnel رفتار عجیب پیدا می‌کنه. یکی از متهم‌های همیشگی این سناریو MTU و Fragmentation ـه. 😄

برای یک تست سریع روی لینوکس می‌تونی ارسال بسته بدون Fragment شدن رو امتحان کنی:

ping -M do -s 1472 1.1.1.1

روی Ethernet با MTU استاندارد 1500، عدد 1472 به‌اضافه 28 بایت هدر IP و ICMP می‌شه 1500. اگر پیام‌هایی مثل message too long یا Frag needed دیدی، اندازه رو کم‌کم پایین بیار تا بزرگ‌ترین مقداری که سالم رد می‌شه پیدا کنی.

مثلاً اگر 1472 رد نشد ولی 1400 بدون مشکل جواب داد، احتمالاً جایی در مسیر MTU کوچک‌تری داری؛ چیزی که روی GRE، VPN و بعضی مسیرهای تونلی خیلی بیشتر خودش رو نشان می‌ده.

نکته: پایین آوردن کورکورانه MTU راه‌حل عیب‌یابی نیست. اول مسیر و مقدار واقعی رو پیدا کن؛ بعد سراغ تنظیم MTU یا در سناریوهای TCP، MSS Clamping برو.

🔗 کانال وان سرور

#شبکه #VPS

گاهی پورت بازه، فایروال هم چیزی رو نبسته، ولی سرویس جواب درست نمی‌ده؛ اینجا بهتره به‌جای ری‌استارت‌های شانسی، از بیرون به داخل جلو بری.

اول ببین واقعاً چه پردازشی روی پورت گوش می‌ده:

sudo ss -lntp | grep ':443'

اگر Listener وجود داشت، خود سرویس رو از همان سرور تست کن:

curl -v http://127.0.0.1:8080/

اگر curl محلی جواب داد ولی از بیرون نه، احتمال مشکل بیشتر سمت Firewall، NAT، Reverse Proxy یا مسیر شبکه است. اگر همان تست محلی هم خطا داد، برو سراغ لاگ سرویس:

sudo journalctl -u nginx -n 50 --no-pager

مسیر سریع عیب‌یابی:
در ss می‌گه «کسی روی پورت گوش می‌ده؟»
در curl می‌گه «سرویس واقعاً جواب می‌ده؟»
در journalctl می‌گه «اگر جواب نمی‌ده، خودش چه خطایی ثبت کرده؟»

این سه مرحله معمولاً خیلی سریع‌تر از یک systemctl restart بی‌هدف، متهم اصلی رو پیدا می‌کنه.

🔗 کانال وان سرور

#لینوکس #VPS

اگر DNS رو هنوز فقط یک درخواست ساده روی پورت 53 می‌بینی، DoH یه لایه مهم به ماجرا اضافه می‌کنه. در MikroTik می‌تونی درخواست‌های DNS رو از داخل HTTPS عبور بدی تا مسیر بین روتر و Resolver رمزگذاری بشه؛ اما فقط گذاشتن آدرس DoH کافی نیست.

نکته مهم مقاله امروز اینه که قبل از تغییر، از تنظیمات DNS بکاپ بگیری، CA/Certificate معتبر رو وارد کنی، use-doh-server رو درست ست کنی و verify-doh-cert رو روشن نگه داری. بعد هم با cache، resolve و لاگ‌ها مطمئن بشی واقعاً DoH کار می‌کنه. اگر Certificate یا زمان سیستم مشکل داشته باشه، اتصال می‌تونه بی‌سروصدا fail بشه.

#آکادمی_وان_سرور

گاهی GRE رو می‌سازی، اینترفیس هم UP ـه و دو سر تونل ظاهراً همه‌چیز مرتب به نظر می‌رسه؛ ولی ترافیک ازش رد نمی‌شه. اینجا معمولاً خود GRE آخرین متهمه، نه اولین نفر. 😄

برای عیب‌یابی سریع، این سه مورد رو به‌ترتیب چک کن:

۱) Route واقعاً از تونل رد می‌شه؟

ip route get 10.20.0.10

اگر خروجی مسیر یا اینترفیس دیگری را نشان داد، اول Route را درست کن.

۲) اگر قرار است سرور ترافیک را عبور دهد، Forwarding روشن است؟

sysctl net.ipv4.ip_forward

مقدار 1 یعنی فعال است.

۳) rp_filter بسته برگشتی را دور نمی‌اندازد؟

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.gre1.rp_filter

روی مسیرهای نامتقارن و بعضی سناریوهای Tunnel، Reverse Path Filtering می‌تواند بسته سالم را مشکوک تشخیص دهد و Drop کند.

قبل از اینکه rp_filter را کورکورانه خاموش کنی، Route رفت و برگشت و Firewall را بررسی کن؛ چون خاموش‌کردنش بدون دلیل می‌تواند کنترل ضد spoofing را ضعیف کند.

اگر GRE بالا بود ولی پکت رد نمی‌شد، ترتیب ذهنی خوب اینه:
Route → Forwarding → Firewall → rp_filter.

🔗 کانال وان سرور

#شبکه #GRE

هشدار امنیتی جدید برای کاربران MikroTik جدی است. زنجیره MikroTrick در RouterOS می‌تواند روی دستگاه‌هایی که SSH آن‌ها از اینترنت در دسترس است، در شرایط مشخص به تصرف کامل روتر منجر شود.

نسخه‌های اصلاح‌شده شامل 7.24.2، 7.23.4، 7.25 beta 3 و 6.49.21 هستند.

اقدام فوری این است که RouterOS را به نسخه اصلاح‌شده ارتقا بدهید و دسترسی SSH را فقط به IPهای مورد اعتماد، شبکه مدیریت یا VPN محدود کنید. بعد از آپدیت هم کاربران، Scriptها، Scheduler، Firewall و Logها را برای نشانه‌های مشکوک بررسی کنید.

🔗 کانال وان سرور

#هشدار_وان_سرور

گاهی سرور زیر بار شبکه هنوز CPU و RAM بدی نداره، ولی اتصال‌های جدید Timeout می‌شن، بعضی درخواست‌ها رندوم می‌پرن یا NAT رفتار عجیب پیدا می‌کنه. اینجا یکی از چیزهایی که ارزش چک‌کردن داره conntrack ـه.

کرنل لینوکس برای Connection Tracking تعداد اتصال‌های در حال رهگیری رو نگه می‌داره. اول ببین الان چند Entry داری و سقف چقدره:

sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

مثلاً اگر nf_conntrack_count مدام خیلی نزدیک nf_conntrack_max باشه، احتمالاً جدول تحت فشاره. برای دیدن هشدارهای کرنل هم این تست سریع بد نیست:

dmesg | grep -i conntrack

اگر پیامی مثل nf_conntrack: table full, dropping packet دیدی، دیگه سرنخ خیلی جدی داری؛ پکت‌های جدید واقعاً دارن Drop می‌شن.

نکته: سریع nf_conntrack_max رو چند برابر نکن و خیال خودت رو راحت نکن 😄 اول ببین این حجم اتصال طبیعیه یا یک سرویس، NAT شلوغ، اسکن یا ترافیک غیرعادی جدول رو پر کرده. بالا بردن سقف، مصرف RAM رو هم بیشتر می‌کنه و ممکنه فقط اصل مشکل رو عقب بندازه.

🔗 کانال وان سرور

#لینوکس #شبکه

گاهی دیسک VPS بی‌سروصدا پر می‌شه و وقتی سراغ فایل‌های معمولی می‌ری چیز عجیبی پیدا نمی‌کنی؛ یکی از جاهایی که ارزش بررسی داره لاگ‌های systemd journal ـه.

اول ببین journal واقعاً چقدر فضا گرفته:

journalctl --disk-usage

اگر حجمش غیرعادی بود، به‌جای پاک‌کردن دستی فایل‌های /var/log/journal می‌تونی خود journal رو کنترل‌شده جمع‌وجور کنی. مثلاً نگه داشتن حداکثر ۷ روز اخیر:

journalctl --vacuum-time=7d

یا محدود کردن حجم آرشیوها به حدود 500 مگابایت:

journalctl --vacuum-size=500M

نکته: قبل از vacuum کردن، اگر سرور مشکل یا سرویس ناپایداری داره اول لاگ موردنیازت رو بررسی یا ذخیره کن؛ چون لاگی که حذف شد برای عیب‌یابی بعدی برنمی‌گرده. 😄

اگر journal دوباره خیلی سریع بزرگ شد، پاکسازی درمان اصلی نیست؛ باید ببینی کدام سرویس مدام خطا می‌نویسه و ریشه همون رو درست کنی.

🔗 کانال وان سرور

#لینوکس #VPS

خیلی وقت‌ها Fail2ban نصب شده و همه خیال‌شون راحته؛ ولی چند ماه بعد می‌بینی سرویس بالا بوده و عملاً هیچ IPای را Ban نمی‌کرده.

برای یک چک سریع اول وضعیت Jail مربوط به SSH رو ببین:

fail2ban-client status sshd

بعد حتماً Backend فایروال رو هم بررسی کن؛ روی سیستم‌های جدید ممکنه انتظار iptables داشته باشی ولی سرور با nftables کار کنه. برای دیدن Ruleهای فعال:

nft list ruleset | grep -i f2b

نکته مهم اینه که «Active بودن سرویس» با «واقعاً Block شدن مهاجم» یکی نیست. بعد از هر تغییر فایروال یا مهاجرت سیستم‌عامل، مسیر Ban رو دوباره تست کن.

🔗 کانال وان سرور

#امنیت #VPS

گاهی بعد از ریبوت VPS می‌بینی سرور بالا آمده، ولی یکی از سرویس‌ها با تأخیر آماده می‌شود و کل استک چند ده ثانیه منتظر می‌ماند. به‌جای حدس‌زدن، زنجیره بوت systemd را ببین.

برای پیدا کردن سرویس‌هایی که مسیر بوت را کند کرده‌اند این دو دستور خیلی کاربردی‌اند:

systemd-analyze blame
systemd-analyze critical-chain

نکته اینجاست که blame فقط زمان هر واحد را نشان می‌دهد؛ اما critical-chain وابستگی‌هایی را پیدا می‌کند که واقعاً مسیر بوت را عقب انداخته‌اند. پس صرفاً طولانی‌ترین عدد را مقصر اعلام نکن؛ اول زنجیره وابستگی را ببین، بعد سراغ همان سرویس برو.

🔗 کانال وان سرور

#Linux #VPS

گاهی روی نودهای VLESS/REALITY همه‌چیز از نظر کانفیگ درست به‌نظر می‌رسه، ولی بخشی از اتصال‌ها ناپایدار می‌شن. قبل از دست‌کاری Core، مقصدی که برای Reality انتخاب کردی رو از خود سرور بررسی کن؛ چون مسیر، SNI و TLS مقصد باید واقعاً قابل اتکا باشن.

برای یک چک ساده، هندشیک TLS و گواهی مقصد رو از همان نود ببین:

openssl s_client -connect example.com:443 -servername example.com </dev/null

اگر اتصال به مقصد timeout می‌شه، گواهی غیرمنتظره می‌بینی یا مسیر آن از دیتاسنتر ناپایداره، عوض‌کردن UUID و پورت معمولاً درمان مسئله نیست. اول خود مقصد و دسترسی نود به آن را پایدار کن، بعد سراغ تنظیمات Reality برو.

🔗 کانال وان سرور

#VLESS #Reality

گاهی کش Cloudflare روشنه، ولی صفحه هنوز هر بار مستقیم از سرور جواب می‌گیره. قبل از اینکه سراغ Purge و تنظیمات عجیب بری، هدر پاسخ رو ببین؛ معمولاً خودش سرنخ رو لو می‌ده.

برای بررسی سریع این دستور کافیه:

curl -I https://example.com

اگر CF-Cache-Status: HIT دیدی، پاسخ از کش لبه آمده. مقدار MISS یعنی این درخواست در کش نبوده و DYNAMIC معمولاً یعنی Cloudflare آن پاسخ را برای کش‌کردن واجد شرایط ندیده.

نکته مهم اینه که قبل از دست‌کاری Cache Rules، کوکی‌ها، Cache-Control و نوع URL رو هم بررسی کنی؛ وگرنه Purge کردن فقط چند دقیقه حس پیروزی می‌ده! 😄

🔗 کانال وان سرور

#Cloudflare #هاستینگ

گاهی VPS ظاهراً بدون دلیل یک سرویس رو می‌کُشه؛ نه CPU پره، نه دیسک مشکل داره، ولی پروسه ناگهان ناپدید می‌شه. یکی از مظنون‌های اصلی OOM Killer لینوکسه؛ وقتی RAM و Swap جواب نمی‌دن، کرنل برای زنده نگه داشتن سیستم یک پروسه رو قربانی می‌کنه. 😅

برای چک سریع، این لاگ‌ها رو ببین:

journalctl -k | grep -Ei 'oom|out of memory|killed process'

بعد مصرف حافظه رو با این دو دستور بررسی کن:

free -h
ps aux --sort=-%mem | head

نکته مهم اینه که صرفاً RAM رو بیشتر نکنی؛ اول ببین کدوم سرویس نشت حافظه داره، Swap اصلاً فعاله یا نه و محدودیت Memory سرویس/کانتینر درست تنظیم شده یا نه.

🔗 کانال وان سرور

#VPS #Linux

گاهی تو معماری چندنودی VPN تونل سالمه و حتی Ping هم رد می‌شه، ولی ترافیک بعضی کاربرها از Exit اشتباه بیرون می‌ره. اینجا معمولاً مشکل خود تونل نیست؛ Policy Routing و markها رو باید چک کرد.

برای شروع ببین Rule و Route واقعاً با mark موردنظر هماهنگ‌اند یا نه:

ip rule show
ip route show table all | grep -E 'default|wg|tun'
nft list ruleset | grep -i mark

نکته مهم اینه که mark کردن Packet به‌تنهایی کافی نیست؛ باید Rule متناظر به جدول درست اشاره کنه و مسیر برگشت هم با معماری Entry/Exit سازگار باشه. وگرنه تونل Up می‌مونه ولی بخشی از Sessionها نامتقارن می‌شن و بی‌دلیل Drop می‌خورند.

🔗 کانال وان سرور

#VPN #Routing

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

برای یک بررسی سریع، دسترسی‌های sudo رو این‌طور ببین:

sudo -l -U USERNAME
grep -R "NOPASSWD" /etc/sudoers /etc/sudoers.d 2>/dev/null

بهتره به‌جای دسترسی کلی، فقط همان command لازم را با مسیر کامل مجاز کنی و بعد از تغییر هم فایل را با visudo -c اعتبارسنجی کنی. دسترسی موقت اگر جمع نشه، خیلی راحت تبدیل به مسیر دائمی Privilege Escalation می‌شه.

🔗 کانال وان سرور

#امنیت #Linux

فرض کن ساعت دو شب مانیتورینگ هشدار می‌ده و یک VPS ناگهان کند شده؛ هنوز نمی‌دونی مشکل از CPU، RAM، دیسک یا شبکه است. اولین دستوری که می‌زنی کدومه؟ 👇

گزینه خودت رو انتخاب کن و بعد با این چک سریع مقایسه کن:

uptime
free -h
vmstat 1 5
df -h

نکته اینجاست که از روی یک عدد نباید حکم بدی؛ Load بالا می‌تونه از CPU باشه، ولی I/O wait یا فشار حافظه هم می‌تونه همون ظاهر رو بسازه. برای Incident واقعی، اول وضعیت کلی رو بگیر و بعد برو سراغ ابزار تخصصی‌تر.

🔗 کانال وان سرور

#Linux #VPS