https://virgool.ir/feed/@KazemMortazaviمشاور مستقل امنیت شبکه با بیش از ۲۵ سال تجربه در فناوری اطلاعات و ارتباطات | تحلیل روزانهٔ تهدیدها و مقایسهٔ بی‌طرفانهٔ راهکارهای امنیتی | symantecland.comfa2026-11-11 20:08:45https://files.virgool.ir/upload/users/4953752/avatar/0FvaYn.jpghttps://virgool.ir/@KazemMortazavihttps://virgool.ir/@KazemMortazavi/پاسخ-به-حادثه-امنیتی-برنامهٔ-۷۲-ساعت-اول-بعد-از-کشف-نفوذ-ml3rb2rajynw‏پاسخ به حادثه امنیتی در بیشتر سازمان‌ها روی کاغذ وجود دارد، اما در لحظهٔ واقعی کمتر کسی می‌داند اول چه کند. چند وقت پیش یکی از همکارانم با سازمانی کار می‌کرد که EDR روی فایل‌سرورش هشدار رمزگذاری مشکوک داده بود. مدیر شبکه با نیت خیر سرور را خاموش کرد، دیسک را فرمت کرد و ویندوز را از نو نصب کرد. دو هفته بعد همان مهاجم با همان حساب VPN برگشت.‏مشکل سرعت نبود؛ نبودِ نقشه بود. هیچ‌کس نپرسیده بود مهاجم از کجا آمده و به کجاهای دیگر رسیده است.‏چرا ساعت‌های اول مهم‌اند‏طبق گزارش هزینهٔ نشت داده ۲۰۲۵ شرکت IBM، میانگین زمان شناسایی و مهار نفوذ ۲۴۱ روز بود: ۱۸۱ روز تا شناسایی و ۶۰ روز دیگر تا مهار. آن ۶۰ روز همان جایی است که یک برنامهٔ آماده بیشترین اثر را دارد.‏پیش از حادثه‏نقش‌ها روشن باشد: چه کسی دستور ایزوله کردن سرور حیاتی را می‌دهد.‏کانال ارتباطی خارج از شبکه داشته باشید؛ ایمیل سازمانی ممکن است در دسترس مهاجم باشد.‏لاگ ورود، VPN، فایروال و DNS دست‌کم ۹۰ روز در یک سامانهٔ متمرکز بماند.‏EDR بتواند دستگاه را ایزوله کند و ارتباط با کنسول را نگه دارد.‏پشتیبان ایزوله و آزمون‌شده داشته باشید.‏ساعت ۰ تا ۴: مهار‏خاموش نکنید؛ ایزوله کنید. نشانه‌های فرمان و کنترل را روی فایروال و DNS ببندید، حساب‌های آلوده را غیرفعال کنید و ثبت‌نام MFA آن‌ها را بازبینی کنید. یک دفتر زمانی از همهٔ کارها نگه دارید.‏ساعت ۴ تا ۲۴: تعیین دامنه‏با خط زمانی SIEM، شکار نشانه‌ها با EDR در همهٔ نقاط پایانی و بررسی حساب‌ها و گروه‌های مدیریتی تازه، به سه سؤال جواب دهید: راه ورود، دامنهٔ نفوذ و داده‌ای که خارج شده است. تا این فهرست کامل نشده، پاک‌سازی را شروع نکنید.‏ساعت ۲۴ تا ۷۲: ریشه‌کنی و بازیابی‏راه ورود را ببندید، اگر مهاجم به سطح مدیر دامنه رسیده رمز krbtgt را دو بار بازنشانی کنید، سرورهای آلوده را از تصویر سالم بازسازی کنید، پشتیبان را پیش از برگرداندن در محیط جدا بررسی کنید و هر سیستم را پیش از اتصال دوباره اسکن کنید. سی روز هم پایش تشدیدشده داشته باشید.‏بعد از حادثه‏یک جلسهٔ مرور بدون مقصرتراشی، تمرین رومیزی هر شش ماه و آزمون بازیابی پشتیبان هر سه ماه، حادثهٔ امروز را به آمادگی فردا تبدیل می‌کند.‏نسخهٔ کامل این راهنما، با اشتباه‌های رایج و نقش هر ابزار، در سایت است: پاسخ به حادثهٔ امنیتی؛ ۷۲ ساعت اول بعد از کشف نفوذ‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویThu, 05 Nov 2026 15:45:06 +0330https://virgool.ir/@KazemMortazavi/وقتی-وصله-هم-نجات-تان-نمی-دهد-درس-های-زیرو-دی-سوئیچ-های-zyxel-gs1900-iitsowljhy4t‏خیلی از تیم‌های شبکه پس از نصب یک وصلهٔ امنیتی پرونده را می‌بندند. ماجرای تازهٔ سوئیچ‌های Zyxel GS1900 نشان می‌دهد این کار همیشه کافی نیست. Zyxel روز ۳ نوامبر ۲۰۲۶ آسیب‌پذیری CVE-2026-107441 را اعلام کرد؛ نقصی که اکسپلویت آن پیش از این روی سوئیچ‌هایی کار می‌کرد که مدیرانشان فکر می‌کردند وصله شده‌اند.‏چه اتفاقی افتاد؟‏در سپتامبر، GreyNoise گزارش داد یک گروه مشکوک چینی‌زبان از حدود ۱۷ اوت تنظیمات، هش رمز root و اطلاعات شبکهٔ ۹۹۶ سوئیچ GS1900 را در ۴۸ کشور جمع کرده است. این حملات به نقص قبلی، CVE-2026-7273، نسبت داده شد که وصله‌اش از ژوئن منتشر شده بود. اما پژوهشگران Binarly اکسپلویت مهاجمان را پیدا کردند و ۲۸ سپتامبر تأیید کردند روی هر ده نسخهٔ وصله‌شده هم کار می‌کند. مهاجم شمارندهٔ پارامترها را پیش از بررسی خراب می‌کرد و از کنترل‌های تازه رد می‌شد.‏چند واقعیت کلیدی:‏ده مدل GS1900 با نسخهٔ 2.90(xxxx.2)C0 و قدیمی‌تر آسیب‌پذیرند و اصلاح در نسخهٔ 2.90(xxxx.3)C0 آمده است.‏حمله بدون رمز و با یک درخواست HTTP دست‌کاری‌شده به رابط وب سوئیچ انجام می‌شود.‏Zyxel مهاجم را در شبکهٔ محلی می‌داند، اما Binarly می‌گوید هر شبکه‌ای که به رابط وب دسترسی دارد کافی است.‏از ۹۹۶ قربانی، ۵۶۴ سوئیچ هنوز رمز پیش‌فرض کارخانه داشتند.‏چه باید کرد؟‏همهٔ سوئیچ‌های GS1900، به‌خصوص در شعب، را پیدا و نسخهٔ آن‌ها را ثبت کنید.‏نسخهٔ .3 را نصب و پس از راه‌اندازی مجدد بررسی کنید.‏رابط مدیریت را فقط در یک VLAN مدیریتی در دسترس بگذارید.‏رمز root، رشته‌های SNMP و رمزهای تکراری را عوض کنید و سوئیچ در دسترس را افشاشده فرض کنید.‏لاگ‌ها را برای ترافیک TFTP خروجی از سوئیچ بگردید.‏درس بزرگ‌تر‏در ارزیابی‌هایی که انجام داده‌ام، سوئیچ‌های دسترسی تقریباً همیشه آخرین تجهیزاتی هستند که کسی به‌روزشان می‌کند. نه عامل امنیتی رویشان نصب است و نه کسی لاگشان را نگاه می‌کند. وصله فقط یک گام است؛ شبکهٔ مدیریت جدا، رمزهای یکتا و پایش لاگ چیزی است که وقتی وصله ناقص از آب درمی‌آید، شما را نجات می‌دهد.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در این نشانی منتشر شده است؛ آن را در نوار آدرس مرورگر وارد کنید: symantecland.​com/zyxel-gs1900‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویThu, 05 Nov 2026 08:19:59 +0330https://virgool.ir/@KazemMortazavi/خرید-لایسنس-تنابل-tenable-کافی-نیست-اولویت-بندی-آسیب-پذیری-از-ده-هزار-یافته-به-بیست-اقدام-qsoiq6st6ynv‏مدیریت آسیب‌پذیری در بیشتر سازمان‌ها با یک گزارش اسکن طولانی شروع می‌شود و همان‌جا گیر می‌کند. فهرست ده هزار ردیفی، دو هزار مورد «بحرانی» و تیمی که نمی‌داند از کجا شروع کند. خرید لایسنس تنابل یا هر اسکنر دیگری فقط نیمی از کار است؛ نیم دیگر این است که بدانید این هفته کدام بیست مورد را ببندید.‏چرا ترتیب CVSS جواب نمی‌دهد‏امتیاز CVSS شدت فنی نقص را می‌گوید، نه احتمال سوءاستفاده را. بسیاری از آسیب‌پذیری‌ها امتیاز بالا می‌گیرند، اما فقط بخش کوچکی از آن‌ها واقعاً هدف حمله می‌شوند. در یکی از پروژه‌ها تیم سه ماه به ترتیب CVSS وصله زده بود و هنوز نقص دروازهٔ VPN که در فهرست آسیب‌پذیری‌های در حال سوءاستفاده بود باز مانده بود.‏طبق گزارش DBIR ۲۰۲۵ شرکت Verizon، سازمان‌ها فقط ۵۴ درصد آسیب‌پذیری‌های تجهیزات لبه را کامل رفع کردند و میانهٔ زمان رفع ۳۲ روز بود.‏چهار سیگنال در کنار هم‏فهرست KEV: سوءاستفاده تأییدشده در دنیای واقعی.‏EPSS: احتمال سوءاستفاده در ۳۰ روز آینده، بین صفر و یک.‏VPR: امتیاز پویای اولویت در محصولات Tenable، از ۰٫۱ تا ۱۰.‏اهمیت دارایی: اینترنتی بودن، کنترلر دامنه، سرور پرداخت.‏چهار ردیف با مهلت مکتوب‏۱. اضطراری، ۴۸ تا ۷۲ ساعت: موارد KEV یا VPR نه و بالاتر روی دارایی اینترنتی یا حیاتی.‏۲. فوری، ۱۴ روز: EPSS بالا یا VPR هفت تا نه روی سرورهای مهم.‏۳. برنامه‌ریزی‌شده، ۳۰ تا ۴۵ روز: بقیهٔ موارد بالا روی شبکهٔ داخلی.‏۴. چرخهٔ عادی: باقی یافته‌ها یا پذیرش ریسک با تاریخ انقضا.‏با همین روش، از یازده هزار یافته کمتر از چهل مورد در ردیف یک ماند؛ فهرستی که در یک هفته تمام می‌شد.‏وقتی وصله ممکن نیست‏ردیف یک نباید منتظر بماند. قاعدهٔ محدود روی WAF برای برنامه‌های وب، امضای IPS روی فایروال و بستن رابط مدیریتی به شبکهٔ مدیریت، فاصلهٔ تا وصله را پوشش می‌دهند. هر استثنا یک مالک و یک تاریخ انقضا دارد.‏سه شاخص که ارزش گزارش دارند‏میانگین زمان رفع ردیف یک، تعداد موارد KEV اینترنتی که از مهلت گذشته‌اند، و درصد دارایی‌هایی که با حساب معتبر اسکن شده‌اند. اگر این سه عدد هر ماه بهتر شوند، ریسک واقعاً کم شده است؛ نه فقط تعداد تیکت‌ها.‏نسخهٔ کامل این راهنما، با اشتباه‌های رایج و برنامهٔ ۳۰ روزه، در سایت است: اولویت‌بندی آسیب‌پذیری؛ از ده هزار یافته به بیست اقدام‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویWed, 04 Nov 2026 15:41:07 +0330https://virgool.ir/@KazemMortazavi/ده-سال-پنهان-۵۳-دقیقه-تا-روت-نقص-tcp-هستهٔ-لینوکس-چه-درسی-برای-تیم-زیرساخت-دارد-keiegogiqqqm‏کدی که از ژانویهٔ ۲۰۱۶ در هستهٔ لینوکس بود، هر روز میلیون‌ها اتصال TCP را مدیریت می‌کرد و کسی متوجه ایرادش نشد. حالا این ایراد شناسهٔ CVE-2026-98432 و امتیاز ۹٫۸ گرفته است و Anthropic می‌گوید یک مدل هوش مصنوعی آزمایشی در حدود ۵۳ دقیقه با آن از راه دور دسترسی روت گرفته است.‏ماجرا در چند خط‏هنگام ساختن سوکت فرزند از یک درخواست اتصال، گزینه‌های IP بدون کپی به سوکت جدید سپرده می‌شوند. اگر هم‌زمان یک SYN تکراری روی هستهٔ دیگری از پردازنده برسد، پاسخ SYNACK ممکن است حافظهٔ آزادشده را بخواند. نتیجه یک نقص «استفاده پس از آزادسازی» است که بدون رمز و فقط با ترافیک شبکه فعال می‌شود.‏اکسپلویت Anthropic روی سروری با شنوندهٔ MPTCP نشان داده شده و منتشر نشده است. تا ۳۰ اکتبر حملهٔ واقعی گزارش نشده، اما زبان Go از نسخهٔ 1.24 روی لینوکس MPTCP را به‌طور پیش‌فرض روشن می‌کند و همین دامنهٔ خطر را بزرگ‌تر از چیزی می‌کند که به نظر می‌رسد.‏وضعیت وصله‏وصله‌شده: Debian 12 و 13، بیشتر نسخه‌های SUSE، Oracle UEK و هسته‌های جدید Amazon Linux 2023.‏در انتظار: RHEL 8، 9 و 10 و هم‌خانواده‌ها، و Ubuntu 22.04 تا 26.10.‏آسیب‌پذیر نیست: RHEL 7 و CentOS 7.‏تا رسیدن وصله چه کنیم؟‏با ss -H -lMn شنونده‌های MPTCP را پیدا کنید و اگر لازم نیست خاموششان کنید؛ اما بدانید این کار به‌تنهایی کافی نیست.‏بسته‌های TCP دارای گزینهٔ IP را روی فایروال یا با nftables حذف کنید؛ ترافیک عادی تقریباً به آن نیاز ندارد.‏سرویس‌های غیرضروری را از اینترنت جدا کنید و پشت VPN یا پروکسی ببرید.‏بعد از نصب هستهٔ جدید حتماً ریبوت کنید؛ بستهٔ نصب‌شده بدون راه‌اندازی دوباره اثری ندارد.‏نکتهٔ میدانی‏در ارزیابی‌ها بارها دیده‌ایم که ماشین‌های مجازی جانبی، از مانیتورینگ تا API داخلی، ماه‌ها ریبوت نشده‌اند. وقتی ساخت اکسپلویت به یک ساعت می‌رسد، فهرست دقیق نسخهٔ هستهٔ هر سرور دیگر یک کار لوکس نیست.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در این نشانی منتشر شده است؛ آن را در نوار آدرس مرورگر وارد کنید: symantecland.​com/linux-kernel-tcp‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویWed, 04 Nov 2026 10:03:50 +0330https://virgool.ir/@KazemMortazavi/امنیت-exchange-server-حالا-که-2016-و-2019-دیگر-وصله-نمی-گیرند-چه-کنیم-o8e7diir00iz‏اگر سازمان شما هنوز Exchange 2016 یا 2019 دارد، این هفته وقت تصمیم است. امنیت Exchange Server داخلی از اول نوامبر ۲۰۲۶ شکل دیگری پیدا کرده: دورهٔ دوم برنامهٔ ESU با پایان اکتبر بسته شد و مایکروسافت گفته هیچ تمدید دیگری در کار نیست. یعنی هر آسیب‌پذیری تازه‌ای که از این به بعد در این دو نسخه پیدا شود، برای همیشه باز می‌ماند.‏چیزی که در ارزیابی‌ها زیاد می‌بینم‏در بیشتر ارزیابی‌های امنیت ایمیل، مشکل اصلی خود Exchange نیست، بلکه نحوهٔ انتشار آن است: صفحهٔ مدیریت ECP مستقیم روی اینترنت، SMTP بدون دروازه و آخرین به‌روزرسانی تجمعی که دو سال قدیمی است. این‌ها تصمیم‌های پیکربندی‌اند و در چند هفته اصلاح می‌شوند.‏پنج لایه، به ترتیب اولویت‏دروازهٔ ایمیل جلوی SMTP: هرزنامه، فیشینگ و پیوست مخرب باید پیش از رسیدن به Exchange حذف شوند. راهنمای مشترک CISA و NSA هم صریحاً همین را توصیه می‌کند.‏پیش‌احراز هویت جلوی OWA: هیچ درخواست ناشناسی نباید به IIS برسد؛ MFA را همین‌جا اجباری کنید.‏حفاظت سطح صندوق روی سرور: آنتی‌ویروس فایل محتوای ایمیل و پیوست را نمی‌بیند.‏محدود کردن ECP و Remote PowerShell فقط به شبکهٔ مدیریتی.‏دید و بازیابی: لاگ IIS در SIEM، اسکن ماهانهٔ آسیب‌پذیری و پشتیبانی که بازیابی‌اش آزموده شده باشد.‏سخت‌سازی و مهاجرت‏اجرای Exchange Health Checker بهترین نقطهٔ شروع است. بعد Extended Protection، یکپارچگی AMSI، TLS 1.2 به بالا و سرویس Emergency Mitigation را بررسی کنید. اگر روی Exchange 2019 با CU14 یا CU15 هستید، ارتقا به Exchange SE درجا و شبیه نصب یک CU است؛ برای 2016 باید سرور جدید کنار آن بگذارید و صندوق‌ها را جابه‌جا کنید.‏یک عدد نشان می‌دهد چرا این موضوع جدی است: در اسکن ۱۰ اوت ۲۰۲۵ بنیاد Shadowserver، ۲۹٬۰۹۸ سرور Exchange در دسترس از اینترنت هنوز در برابر آسیب‌پذیری هیبریدی CVE-2025-53786 وصله نشده بودند؛ آن هم وقتی وصله وجود داشت. اگر محیط شما هیبرید است و به Exchange Online هم وصل است، برنامهٔ اختصاصی Hybrid را هم جدا کنید.‏یک یادآوری صادقانه: دروازه و WAF جای وصله را نمی‌گیرند، فقط زمان می‌خرند. پس در کنار این لایه‌ها، یک تاریخ قطعی برای مهاجرت بنویسید.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در این نشانی منتشر شده است؛ آن را در نوار آدرس مرورگر وارد کنید: symantecland.​com/exchange-server‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویWed, 04 Nov 2026 10:02:53 +0330https://virgool.ir/@KazemMortazavi/وقتی-وصله-دو-هفته-منتظر-ماند-نقص-gitlab-از-هشدار-به-حملهٔ-واقعی-رسید-qypj5mocpw83‏دوازدهم اکتبر GitLab نقصی با امتیاز کامل ۱۰ را وصله کرد و آن روز هنوز هیچ حمله‌ای گزارش نشده بود. برای خیلی از تیم‌ها همین یعنی «فرصت داریم». هفده روز بعد، سازمان امنیت سایبری آمریکا (CISA) همین نقص، یعنی CVE-2026-97229، را به فهرست آسیب‌پذیری‌های دارای سوءاستفادهٔ فعال اضافه کرد و فقط سه روز مهلت داد.‏نقص در چند خط‏مشکل یک سرریز عدد صحیح در کامپایلر عبارت منظم CI/CD است؛ بخشی که الگوهای Regex فایل‌های پیکربندی Pipeline را پردازش می‌کند. به گفتهٔ GitLab، کاربر بدون احراز هویت در شرایط خاص می‌تواند با یک عبارت منظم دستکاری‌شده روی سرور کد اجرا کند. GitLab اکنون تلاش‌های سوءاستفاده را شناسایی کرده و برای نسخه‌های Self-Managed قواعد تشخیص منتشر کرده است.‏ریشهٔ نقص در موتور Regexp خود زبان Ruby است. تیم Ruby روز ۲۳ اکتبر نسخه‌های 4.0.9، 3.4.12 و 3.3.13 را منتشر کرد و CISA هشدار داده که محصولات دیگری با همین موتور هم ممکن است آسیب‌پذیر باشند.‏چه باید کرد؟‏ارتقا: نسخه‌های امن GitLab شامل 19.4.2، 19.3.5 و 19.2.8 است؛ بهتر است به آخرین وصلهٔ شاخهٔ خود بروید، چون نقص هم‌خانوادهٔ CVE-2026-110264 در 19.5.1 اصلاح شده است.‏محدودسازی موقت: تا زمان ارتقا، دسترسی اینترنتی سرور را به VPN و آدرس‌های شناخته‌شده محدود کنید.‏بررسی نفوذ: CISA برای این مورد بررسی جرم‌شناسی را الزامی کرده است. فرایندهای ناشناس، Runner و توکن تازه و اتصال خروجی غیرعادی را بگردید.‏چرخش رازها: اگر سرور پیش از وصله روی اینترنت بوده، متغیرهای محرمانه و توکن‌های استقرار را عوض کنید.‏برنامه‌های Ruby: هر کدی که از ورودی کاربر عبارت منظم می‌سازد، باید روی نسخهٔ اصلاح‌شدهٔ Ruby برود.‏یک نکتهٔ میدانی‏در یکی از ارزیابی‌ها دیدیم سرور GitLab چون «ابزار داخلی تیم توسعه» حساب می‌شد، در هیچ فهرست دارایی و برنامهٔ وصله‌ای نبود؛ در حالی که کلید همهٔ سرورهای تولید در متغیرهایش بود. ابزارهای DevOps سرور حیاتی‌اند و باید مثل فایروال و ایمیل پایش شوند.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در این نشانی منتشر شده است؛ آن را در نوار آدرس مرورگر وارد کنید: symantecland.​com/gitlab-cve‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویWed, 04 Nov 2026 10:01:55 +0330https://virgool.ir/@KazemMortazavi/خرید-لایسنس-f5-big-ip-چرا-پهنای-باند-تنها-عدد-مهم-نیست-xyqxua6jeiwr‏بیشتر درخواست‌هایی که برای خرید لایسنس F5 BIG-IP به دستم می‌رسد با یک سؤال شروع می‌شود: «چند گیگابیت بگیریم؟» اما در تجربهٔ من، کمتر پیش آمده که گلوگاه واقعی یک ADC پهنای باند باشد. پیش از خرید لایسنس F5 BIG-IP باید بدانید دستگاه دقیقاً قرار است چه کاری انجام دهد.‏سازمانی را دیدم که پرتالش هر روز اول وقت کند می‌شد. لایسنس Virtual Edition یک‌گیگابیتی داشت و ترافیک واقعی حدود سیصد مگابیت بود، اما پردازنده در اوج صد درصد می‌شد. دلیلش گواهی با کلید RSA 4096 و دست‌دهی‌های کامل TLS بود که هر کاربر موبایلی دوباره تکرارشان می‌کرد.‏چهار عددی که باید اندازه بگیرید‏درخواست در ثانیه در اوج: شلوغ‌ترین پنج دقیقهٔ ماه، نه میانگین روز.‏اتصال جدید در ثانیه: برای برنامه‌های موبایل و API معمولاً از پهنای باند مهم‌تر است.‏دست‌دهی کامل SSL در ثانیه: نوع کلید را بنویسید؛ ECDSA بسیار سبک‌تر از RSA بزرگ است.‏پهنای باند با ماژول‌های روشن: WAF و کنترل دسترسی ظرفیت را پایین می‌آورند.‏نسخهٔ مجازی یا سخت‌افزار؟‏نسخهٔ مجازی برای محیط‌های مجازی‌شده و ترافیک چندگیگابیتی انعطاف خوبی دارد و لایسنسش پله‌ای قابل ارتقاست. اما اگر پرتال عمومی پرمراجعه، درگاه پرداخت یا چند تیم مستقل روی یک دستگاه دارید، سخت‌افزار با شتاب‌دهندهٔ SSL و جداسازی Tenant منطقی‌تر است. یادتان باشد در خوشهٔ HA هر دستگاه باید کل بار را تنها حمل کند.‏پیش از امضای قرارداد‏یک پایلوت دوهفته‌ای با همان گواهی و همان ماژول‌ها بگذارید، اوج صبحگاهی را بازسازی کنید و یک بار هم با گواهی ECDSA بسنجید. گاهی همین تغییر یک پله لایسنس را صرفه‌جویی می‌کند.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در این نشانی منتشر شده است؛ آن را در نوار آدرس مرورگر وارد کنید: symantecland.​com/f5-big-ip-sizing‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویWed, 04 Nov 2026 10:00:57 +0330https://virgool.ir/@KazemMortazavi/فایروال-سیسکو-و-زیرو-دی-ssl-vpn-وقتی-یک-لایهٔ-امنیتی-اضافه-در-ورود-حمله-می-شود-twdaobcu3uha‏معمولاً فکر می‌کنیم هر لایهٔ احراز هویت که اضافه کنیم، VPN امن‌تر می‌شود. نقص تازهٔ فایروال‌های سیسکو نشان داد گاهی همان لایهٔ اضافه، مسیر حمله را باز می‌کند. سیسکو این هفته نقص CVE-2026-76418 با امتیاز 8.6 را در سرویس SSL VPN نرم‌افزارهای ASA و FTD وصله کرد و گفت مهاجمان پیش از وصله از آن استفاده کرده‌اند.‏ماجرا در چند خط‏مهاجم بدون نام کاربری و رمز، هنگام اتصال به SSL VPN یک درخواست دستکاری‌شده می‌فرستد و فایروال ری‌استارت می‌شود. شرط آسیب‌پذیری این است که احراز هویت ثانویه (Secondary Authentication) روی یک Tunnel Group تنظیم شده باشد. نتیجه، منع سرویس است: VPN و ترافیک عبوری تا بالا آمدن دستگاه قطع می‌شود. سیسکو نگفته حملات کار چه کسی است و نشانهٔ نفوذی هم منتشر نکرده است.‏به گزارش BleepingComputer، بنیاد Shadowserver بیش از ۵۱ هزار SSL VPN سیسکو ASA را روی اینترنت می‌بیند. این دومین زیرو-دی منع سرویس در VPN این فایروال‌ها از اوت ۲۰۲۶ است.‏چه باید کرد؟‏ارتقای فوری: نخستین نسخه‌های امن ASA شامل 9.18.4.96، 9.20.4.50، 9.22.3.200 و 9.23.1.48 است و در FTD نسخه‌های 7.2.13، 7.4.9، 7.6.7 و 10.0.3.‏راهکار موقت: تا زمان ارتقا، احراز هویت ثانویه را روی DefaultWEBVPNGroup و Tunnel Groupهای دیگر بررسی و در صورت امکان موقتاً بردارید. غیرفعال کردن فهرست Tunnel Group به‌تنهایی کافی نیست.‏پایش ری‌استارت: ری‌استارت ناگهانی فایروال باید در سامانهٔ پایش رویدادها هشدار فوری بسازد، نه اینکه از تماس کاربران متوجه شوید.‏SD-WAN را فراموش نکنید: تیم Talos همزمان گزارش داد گروه UAT-11473 با نقص CVE-2026-20127 در Catalyst SD-WAN بدافزار KeyDrift را برای سرقت مادهٔ کلید رمزنگاری نصب کرده است.‏یک نکتهٔ میدانی‏در یکی از ارزیابی‌ها دیدیم فایروال اصلی یک سازمان دو سال ارتقا نیافته بود، چون کسی پنجرهٔ نگهداری را تأیید نمی‌کرد. خوشهٔ HA درست‌طراحی‌شده همین بهانه را از بین می‌برد: یک عضو ارتقا می‌یابد و دیگری ترافیک را نگه می‌دارد.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در این نشانی منتشر شده است؛ آن را در نوار آدرس مرورگر وارد کنید: symantecland.​com/cisco-asa-ftd-zero‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویWed, 04 Nov 2026 09:59:57 +0330https://virgool.ir/@KazemMortazavi/خرید-hsm-کلید-ca-داخلی-و-امضای-کد-را-کجا-نگه-داریم-svz4okt0vxjl‏کلید ریشهٔ CA داخلی سازمان شما الان کجاست؟ در بیشتر بازدیدهایی که داشته‌ایم، پاسخ دقیقی برای این سؤال نبود. پیش از خرید HSM، باید بدانید کدام کلیدها را می‌خواهید از دیسک سرورها بیرون بیاورید. در یکی از همین بازدیدها، فایل کلید ریشه در پوشهٔ پشتیبان یک ماشین مجازی بود و کلید امضای کد روی سرور Build.‏ماجرای این هفتهٔ eMudhra، که کلیدهای ضعیف هشت CA میانی‌اش از فهرست اعتماد حذف شد، یک یادآوری جدی بود: اعتماد به گواهی، به اندازهٔ امنیت کلید خصوصی آن است.‏سه لایه برای PKI داخلی‏ریشهٔ آفلاین: سرور ریشه خاموش و جدا از شبکه، کلید داخل HSM و فقط در مراسم کلید مستند روشن شود.‏CA صادرکننده روی HSM شبکه‌ای: AD CS از طریق KSP به HSM وصل شود؛ کلید هیچ‌وقت بیرون نمی‌آید. دو دستگاه به‌صورت HA.‏جداسازی وظایف: مدیر CA، مدیر HSM و ممیز سه نفر جدا؛ کارهای حساس با سهمیهٔ چندنفره.‏امضای کد و گواهی‌های کوتاه‌عمر‏از ژوئن ۲۰۲۳ کلید گواهی‌های امضای کد عمومی باید در سخت‌افزاری با سطح حداقل FIPS 140-2 Level 2 باشد. برای کلیدهای داخلی هم همین منطق درست است: سرور Build فقط هش فایل را برای امضا بفرستد و هر امضا لاگ شود.‏سقف عمر گواهی TLS عمومی امسال ۲۰۰ روز شد، سال بعد ۱۰۰ روز و از ۲۰۲۹ فقط ۴۷ روز است. دو کار را از همین حالا شروع کنید:‏رمزگشایی TLS را روی ADC متمرکز کنید تا کلید در جاهای کمتری باشد.‏صدور و تمدید را با ثبت‌نام خودکار AD CS و پروتکل ACME خودکار کنید.‏یک تمرین ساده‏هر سال فرض کنید کلید CA صادرکننده لو رفته است. ابطال، صدور دوباره و به‌روزرسانی CRL چقدر طول می‌کشد؟ پاسخ این سؤال، میزان آمادگی واقعی شماست.‏یک اشتباه رایج را هم جدی بگیرید: بسیاری از سازمان‌ها HSM می‌خرند، اما کلید قدیمی را فقط وارد دستگاه می‌کنند و فایل اصلی را روی سرور نگه می‌دارند. در این حالت عملاً چیزی عوض نشده است. بهتر است کلید تازه داخل خود HSM ساخته شود و گواهی‌ها با آن دوباره صادر شوند. یک HSM تنها بدون پشتیبان هم خطرناک است؛ خرابی آن یعنی از دست رفتن کلید CA.‏در نسخهٔ کامل، فهرست پنج دسته کلید، معیارهای انتخاب HSM، چهار اشتباه رایج و یک چک‌لیست هشت‌مرحله‌ای را آورده‌ام.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در این نشانی منتشر شده است؛ آن را در نوار آدرس مرورگر وارد کنید: symantecland.​com/enterprise-pki‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویWed, 04 Nov 2026 09:56:43 +0330https://virgool.ir/@KazemMortazavi/وقتی-خودِ-آپدیت-در-ورود-مهاجم-است-درس-های-نقص-تازهٔ-هستهٔ-وردپرس-su4szehlqjfc‏یک باور رایج بین مدیران سایت این است که «به‌روزرسانی یعنی امنیت». آسیب‌پذیری تازهٔ هستهٔ وردپرس با شناسهٔ CVE-2026-119977 نشان می‌دهد خودِ لحظهٔ به‌روزرسانی هم می‌تواند در ورود مهاجم باشد. CISA روز ۳ نوامبر ۲۰۲۶ این نقص را بر پایهٔ شواهد بهره‌برداری فعال در فهرست KEV گذاشت.‏مشکل کجاست؟‏وردپرس هنگام به‌روزرسانی با بستهٔ کامل، فایل‌های نسخهٔ جدید را موقتاً در پوشه‌ای زیر wp-content/upgrade باز می‌کند. نام این پوشه قابل حدس بود و از وب هم در دسترس قرار داشت. در این نسخهٔ موقت، نصب‌کنندهٔ وردپرس وجود دارد اما فایل پیکربندی نه؛ پس نصب‌کننده فکر می‌کند با یک سایت تازه روبه‌روست. مهاجمی که در همان چند ثانیه به آن برسد، بدون هیچ رمزی می‌تواند به اجرای کد روی سرور برسد.‏چند واقعیت کلیدی:‏نسخه‌های 4.7.0 تا 7.1.3 آسیب‌پذیرند و اصلاح در 7.1.4 (۲۸ اکتبر) و وصله‌های شاخه‌ای مثل 7.0.8، 6.9.11 و 6.8.12 آمده است.‏Wordfence امتیاز CVSS 8.1 داده، در حالی که وردپرس شدت را «کم» اعلام کرده بود.‏Wordfence در ۲۱ ساعت نخست بیش از ۱۸٬۵۰۰ درخواست به مسیرهای نصب‌کنندهٔ موقت ثبت کرد.‏چون درخواست مستقیم به یک فایل PHP می‌رود، افزونه‌های امنیتی داخل وردپرس ممکن است آن را نبینند.‏ترتیب درست کار‏نکته‌ای که کمتر به آن توجه می‌شود این است که نصب وصله هم با کد قدیمی انجام می‌شود. پس ترتیب درست این است:‏اول دسترسی وب به پوشهٔ wp-content/upgrade را در خود وب‌سرور ببندید.‏بعد به نسخهٔ اصلاح‌شدهٔ شاخهٔ خود بروید و نسخه را واقعاً بررسی کنید.‏هر فایل PHP باقی‌مانده در این پوشه به‌جز index.​php را بررسی کنید.‏لاگ وب‌سرور را برای درخواست‌های setup-config.​php زیر این مسیر بگردید.‏حساب‌های مدیر و افزونه‌های ناآشنا را بازبینی کنید.‏درسی فراتر از وردپرس‏در ارزیابی‌هایی که انجام داده‌ام، بیشتر تیم‌ها برای روز حمله برنامه دارند اما برای روز نگه‌داری نه. هر عملیات نگه‌داری، از به‌روزرسانی تا پشتیبان‌گیری، فایل‌ها و مسیرهای موقتی می‌سازد که باید از بیرون دیده نشوند. فیلتر کردن مسیرهای حساس در لایهٔ جلوی وب‌سرور و پایش لاگ در همان ساعت‌ها، ارزان‌ترین بیمه است.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در این نشانی منتشر شده است؛ آن را در نوار آدرس مرورگر وارد کنید: symantecland.​com/wordpress-core-upgrade‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویWed, 04 Nov 2026 08:20:08 +0330https://virgool.ir/@KazemMortazavi/نشت-اطلاعات-از-داخل-سازمان-چرا-بیش-از-۶۰-درصد-نشت-ها-کار-خودی-هاست-zcznn6pqkf2b‏بیشتر سازمان‌ها وقتی به نشت اطلاعات فکر می‌کنند، تصویر یک هکر ناشناس در آن سوی اینترنت را در ذهن دارند. اما آمار جهانی چیز دیگری می‌گوید: بیش از ۶۰ درصد نشت‌های اطلاعاتی کار افراد داخلی است؛ گاهی عمدی و بیشتر وقت‌ها ناخواسته. تنها حدود ۴۰ درصد به حملهٔ مهاجم بیرونی برمی‌گردد. یعنی بخش بزرگی از بودجهٔ دفاع مرزی، سراغ بخش کوچک‌تر مشکل می‌رود.‏داده از کجا بیرون می‌رود؟‏نشت اطلاعات یعنی هر خروج یا افشای غیرمجاز دادهٔ حساس، چه از روی عمد و چه تصادفی. مسیرهای رایج آن ساده‌تر از چیزی است که تصور می‌شود:‏ایمیلی که فایل حساس را به گیرندهٔ اشتباه می‌فرستد؛ پرتکرارترین مسیر‏کپی اطلاعات روی فلش یا دستگاه شخصی‏بارگذاری ناخواستهٔ فایل روی سرویس‌های ابری عمومی‏کارمند ناراضی که داده را با خود می‌برد‏بدافزاری که داده را به سرور فرماندهی مهاجم می‌فرستد‏چرا مشکل هر سال بزرگ‌تر می‌شود‏سه عامل با هم جمع شده‌اند. کار از راه دور، دستگاه‌های شخصی و شبکه‌های خانگی را وارد چرخهٔ کار کرده است. مسیرهای انتقال داده (پیام‌رسان، فضای ابری، VPN و API) مدام بیشتر می‌شوند، در حالی که کنترل‌ها اغلب همان‌هایی‌اند که سال‌ها پیش تعریف شده‌اند. و کارکنان، پیمانکاران و کاربران با دسترسی بالا به‌طور قانونی به دادهٔ حساس دسترسی دارند. در کنار این‌ها، چارچوب‌هایی مثل GDPR و PCI-DSS نشت را به جریمه و آسیب اعتبار تبدیل می‌کنند.‏برنامهٔ مؤثر چه لایه‌هایی دارد‏کنترل نقاط خروج: فناوری DLP مسیرهای خروج داده را شناسایی و مهار می‌کند.‏پوشش ایمیل و ابر: درگاه امن ایمیل و CASB دو مسیر پرتردد را قابل دیدن و کنترل‌پذیر می‌کنند.‏دیدن رفتار کاربر: الگوهای غیرعادی انتقال داده را باید پیش از وقوع حادثه دید.‏رمزنگاری: در بدترین حالت، دادهٔ خارج‌شده بدون کلید ارزشی ندارد.‏مهار بدافزار: سهم ۴۰ درصدی تهدید بیرونی هم با EDR پوشش داده می‌شود.‏خلاصه این است: وقتی بیشتر نشت‌ها از داخل شروع می‌شود، دیوار بلندتر به‌تنهایی جواب نیست؛ باید مسیر داده و رفتار کاربر را هم دید.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در سایت symantecland دات کام منتشر شده است؛ برای رسیدن مستقیم به آن، بعد از نام سایت در نوار آدرس مرورگر بنویسید: /data-leakage‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویSat, 24 Oct 2026 20:45:04 +0330https://virgool.ir/@KazemMortazavi/xdr-چیست-و-چرا-سه-هشدار-کوچک-می-تواند-یک-حملهٔ-کامل-باشد-qlayrylfkviu‏فرض کنید در یک روز کاری سه اتفاق کوچک می‌افتد: کاربری روی لینک یک ایمیل کلیک می‌کند، یک حساب کاربری ساعت غیرعادی وارد سیستم می‌شود و ترافیکی نامعمول بین دو سرور داخلی دیده می‌شود. هر کدام در کنسول خودش یک هشدار کم‌اهمیت است و در نویز روزانه گم می‌شود. اما کنار هم، این سه رویداد داستان یک حملهٔ کامل را تعریف می‌کنند. XDR یا تشخیص و پاسخ گسترده دقیقاً برای دیدن همین داستان ساخته شده است.‏تفاوت XDR با EDR در یک جمله‏EDR فقط نقطهٔ پایانی را می‌بیند؛ XDR داده‌های نقطهٔ پایانی، شبکه، ایمیل، ابر و سرورها را کنار هم می‌گذارد. حمله‌های امروز چندمرحله‌ای‌اند: از مهندسی اجتماعی شروع می‌شوند، با بدافزار بدون فایل ادامه پیدا می‌کنند و گاهی از مسیر سرویس‌های ابری وارد می‌شوند. ابزاری که فقط یک لایه را می‌بیند، الگوی مشترک را تشخیص نمی‌دهد.‏ارزش اصلی XDR تطبیق امضا نیست؛ تحلیل رفتار و همبسته‌سازی خودکار رویدادهاست. به همین دلیل بار تیم امنیتی کمتر می‌شود: به‌جای ده‌ها هشدار پراکنده، یک رخداد با زمینهٔ کامل روی میز قرار می‌گیرد و پاسخ هم به‌جای اقدام جداگانه در هر ابزار، در کل زیرساخت هماهنگ اجرا می‌شود.‏دو سناریوی واقعی‏سازمان مالی: جایی که باج‌افزار هدف مکرر است، مهم‌ترین اثر XDR کوتاه شدن فاصلهٔ نفوذ اولیه تا تشخیص است. قرنطینهٔ خودکار دستگاه آلوده جلوی رسیدن مهاجم به داده‌های حساس و پشتیبان‌ها را می‌گیرد.‏سازمان صنعتی: حمله معمولاً از شبکهٔ اداری شروع می‌شود و به سمت شبکهٔ صنعتی می‌رود. وقتی دادهٔ ایمیل و دادهٔ شبکه در یک داشبورد ترکیب شود، حرکت جانبی پیش از رسیدن به تجهیزات تولید دیده می‌شود.‏پیش از رفتن به سمت XDR‏منابع داده را فهرست کنید: کدام لایه‌ها امروز لاگ و دادهٔ رفتاری تولید می‌کنند و کدام نه؟‏ایمیل را جدی بگیرید؛ نقطهٔ شروع بیشتر زنجیره‌های حمله همین‌جاست.‏برای همبسته‌سازی رویدادها یک لایهٔ تحلیل مرکزی در نظر بگیرید، نه چند کنسول جدا.‏مشخص کنید چه کسی هشدارها را شبانه‌روز می‌بیند؛ XDR بدون رصد مستمر نیمی از راه است.‏سازمانی که ابزارهایش را جدا از هم نگه می‌دارد، در عمل از تیم امنیتی می‌خواهد کاری را دستی انجام دهد که باید خودکار باشد.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در سایت symantecland دات کام منتشر شده است؛ برای رسیدن مستقیم به آن، بعد از نام سایت در نوار آدرس مرورگر بنویسید: /xdr-extended‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویSat, 24 Oct 2026 19:43:54 +0330https://virgool.ir/@KazemMortazavi/itdr-چیست-وقتی-مهاجم-با-رمز-عبور-معتبر-وارد-می-شود-iam-کافی-نیست-xrscpxppe0ka‏مهاجمی که رمز عبور یک مدیر سیستم را در دست دارد، لازم نیست هیچ دیواری را بشکند؛ کافی است وارد شود. از دید فایروال، EDR و حتی سامانهٔ مدیریت هویت، یک کاربر مجاز وارد شده و کاری انجام داده است. به همین دلیل امروز هویت دیجیتال را مرز امنیتی جدید می‌دانند و ITDR یا «تشخیص و پاسخ به تهدیدهای هویتی» برای پوشش همین نقطهٔ کور شکل گرفته است.‏فرق ITDR با IAM در یک جمله‏IAM تعیین می‌کند چه کسی به چه چیزی دسترسی دارد. ITDR زمانی وارد عمل می‌شود که همان «چه کسی» یا همان دسترسی به خطر افتاده باشد. تمرکز آن بر رفتارهای غیرعادی هویتی است:‏سوءاستفاده از دسترسی‌های موجود‏ارتقای غیرمجاز مجوزها‏حرکت جانبی در شبکه با حساب‌های کاملاً معتبر‏پس ITDR جایگزین IAM، PAM یا EDR نیست؛ لایه‌ای است که روی رفتار هویت‌ها نظارت می‌کند و دادهٔ آن به ابزارهایی مثل XDR و SIEM دید عمیق‌تری از حملات چندمرحله‌ای می‌دهد.‏سه شکافی که بدون ITDR باز می‌ماند‏در ارزیابی‌ها معمولاً سه مشکل تکرار می‌شود. اول، نفوذ با حساب معتبر هیچ هشداری تولید نمی‌کند. دوم، هویت‌ها بین شبکهٔ محلی، چند ابر و سرویس‌های SaaS پراکنده‌اند و کسی تصویر یکپارچه‌ای از آن‌ها ندارد. سوم، ابزارهای سنتی این لایه را یا نمی‌بینند یا خیلی دیر واکنش نشان می‌دهند.‏از کجا شروع کنیم‏سیاههٔ هویت‌ها: همهٔ حساب‌ها را فهرست کنید، از جمله هویت‌های غیرانسانی مثل حساب‌های سرویس که معمولاً از قلم می‌افتند.‏بازبینی دوره‌ای دسترسی: حساب‌های بلااستفاده و دسترسی‌های بیش از حد را پیش از سوءاستفاده پیدا کنید.‏تحلیل رفتاری: به‌جای تکیه بر قواعد ثابت، الگوهای غیرعادی را تشخیص دهید.‏پاسخ خودکار: برای قرنطینهٔ حساب، احراز هویت مجدد یا محدودسازی دسترسی از پیش جریان واکنش تعریف کنید.‏یکپارچگی: ITDR را به SIEM، PAM و IAM موجود وصل کنید تا تیم هویت و تیم عملیات امنیت یک تصویر مشترک داشته باشند.‏مدیریت هویت می‌گوید چه کسی اجازهٔ ورود دارد؛ ITDR می‌گوید چه زمانی آن اجازه به دست فرد اشتباهی افتاده است.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در سایت symantecland دات کام منتشر شده است؛ برای رسیدن مستقیم به آن، بعد از نام سایت در نوار آدرس مرورگر بنویسید: /itdr-identity‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویSat, 24 Oct 2026 17:44:33 +0330https://virgool.ir/@KazemMortazavi/دفاع-چندلایه-در-عمل-اگر-مهاجم-از-فایروال-گذشت-چه-چیزی-جلویش-است-zxilo36z5h4n‏اگر از مدیران فناوری بپرسید امنیت شبکه‌شان به چه چیزی تکیه دارد، بیشترشان نام یک فایروال یا یک آنتی‌ویروس را می‌آورند. مشکل همین‌جاست: هیچ نقطه‌ای از شبکه به‌تنهایی امن نیست. دفاع چندلایه یا Defense in Depth یعنی طوری طراحی کنیم که اگر مهاجم از یک سد گذشت، سد بعدی جلویش باشد، نه اینکه کل سازمان پشت یک دیوار منتظر بماند.‏شش لایه‌ای که باید دیده شوند‏نقشهٔ ساده‌ای که در ارزیابی‌ها به کار می‌برم شش لایه دارد:‏نقطهٔ پایانی: لپ‌تاپ، موبایل و دستگاه کاربر؛ خط مقدم تماس با تهدید. پایش رفتار با EDR و XDR، رمزنگاری دیسک و احراز هویت چندعاملی‏شبکه: فایروال نسل جدید، پیشگیری از نفوذ، کنترل دسترسی و مهم‌تر از همه تفکیک شبکه بر اساس نقش و حساسیت‏سرور و زیرساخت: مدیریت وصله، اسکن مستمر آسیب‌پذیری و کنترل اجرای برنامه‌ها روی سرورها و ماشین‌های مجازی‏سرویس‌ها و ابر: دید روی رفتار کاربران و پیکربندی سرویس‌های SaaS و IaaS با ابزارهایی مثل CASB و CSPM‏مرز اینترنت: دروازهٔ امن وب، فیلترینگ DNS و امنیت ایمیل برای مهار فیشینگ و بدافزار‏هویت: لایه‌ای که در همهٔ لایه‌های دیگر حضور دارد و به همین دلیل باید جداگانه مدیریت شود‏خطای رایج: سرمایه‌گذاری نامتوازن‏در بسیاری از سازمان‌ها بودجه روی مرز اینترنت متمرکز است و داخل شبکه تخت و بدون تفکیک می‌ماند. نتیجه این است که یک ایمیل فیشینگ موفق یا یک لپ‌تاپ آلوده کافی است تا مهاجم آزادانه به سرورها برسد. تفکیک شبکه و معماری Zero Trust در سطح سرور همان چیزی است که جلوی این حرکت جانبی را می‌گیرد؛ یعنی حتی دسترسی‌های داخلی هم باید کنترل‌شده باشند.‏از کجا شروع کنیم‏یک تمرین عملی: فرض کنید فردا مهاجم از فایروال شما عبور کرده است. برای هر کدام از شش لایه بنویسید چه کنترلی جلوی او قرار دارد و چه کسی هشدار را می‌بیند. هر لایه‌ای که جوابش «هیچ» یا «نمی‌دانم» بود، اولویت بعدی شماست. امنیت یک محصول نیست؛ فرایندی است که از کاربر تا زیرساخت ادامه دارد.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در سایت symantecland دات کام منتشر شده است؛ برای رسیدن مستقیم به آن، بعد از نام سایت در نوار آدرس مرورگر بنویسید: /defense-in‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویSat, 24 Oct 2026 16:46:20 +0330https://virgool.ir/@KazemMortazavi/خرید-fortisiem-پیش-از-خرید-siem-این-سه-عدد-را-حساب-کنید-تا-لاگ-ها-زود-پاک-نشوند-dzgztc4f9xbm‏در بیشتر پروژه‌های خرید FortiSIEM و دیگر SIEMها که بعد از چند ماه به نارضایتی می‌رسند، ریشهٔ مشکل یکی است: سامانه بر اساس تعداد دستگاه خریده شده، نه بر اساس حجم واقعی لاگ. نتیجه هم معمولاً همین است: دیسک زود پر می‌شود، لاگ‌های قدیمی پاک می‌شوند و تیم برای ماندن زیر سقف لایسنس، منابع پرحجم را خاموش می‌کند.‏در یکی از بازدیدها، جستجو در لاگ‌های قدیمی‌تر از ۴۵ روز جواب نمی‌داد. این در حالی است که طبق گزارش هزینهٔ نشت داده IBM در سال ۲۰۲۵، کشف و مهار یک نفوذ به‌طور میانگین ۲۴۱ روز طول می‌کشد؛ یعنی وقتی نفوذ پیدا شود، ردپای شروعش مدت‌هاست از بین رفته است.‏سه عدد پیش از هر خرید‏EPS اوج: دو تا چهار هفته لاگ منابع اصلی را به یک Collector آزمایشی بفرستید و اوج را ثبت کنید، نه میانگین را.‏حجم روزانه: EPS ضرب در اندازهٔ متوسط رویداد ضرب در ۸۶٬۴۰۰. با ۲٬۰۰۰ EPS و رویدادهای حدود ۵۰۰ بایتی، روزانه نزدیک ۸۶ گیگابایت لاگ خام دارید.‏مدت نگهداری: چند روز داغ و قابل جستجوی سریع، چند ماه در آرشیو. این عدد را ممیزی تعیین می‌کند، نه دیسک موجود.‏لایسنس را با اعداد تطبیق دهید‏در FortiSIEM، اشتراک دستگاهی برای هر دستگاه ۱۰ EPS همراه دارد و اگر اوج شما بیشتر باشد، EPS اضافه جدا خریده می‌شود. لایسنس دائمی All-in-One از ۵۰ دستگاه و ۵۰۰ EPS شروع می‌شود، و از نسخهٔ 7.2.2 برای استقرار در محل، مدل حجم روزانه (GB در روز) هم وجود دارد. عامل‌های پیشرفته، UEBA و High Availability جدا حساب می‌شوند.‏سه توصیهٔ عملی‏لاگ ترافیک مجاز فایروال را کامل قطع نکنید؛ روی سیاست‌های مهم نگه دارید.‏ذخیره‌سازی را دو لایه کنید: لاگ داغ روی دیسک سریع، آرشیو روی ذخیره‌ساز ارزان‌تر.‏فشرده‌سازی را با لاگ خودتان آزمایش کنید، نه با عدد دیتاشیت.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در سایت symantecland دات کام منتشر شده است؛ برای رسیدن مستقیم به آن، بعد از نام سایت در نوار آدرس مرورگر بنویسید: /siem-sizing‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویSat, 24 Oct 2026 15:41:30 +0330https://virgool.ir/@KazemMortazavi/مدیریت-حقوق-دیجیتال-drm-وقتی-کنترل-فایل-با-ارسال-آن-تمام-نمی-شود-ys2qvxvrpmt8‏یک فایل طراحی که برای پیمانکار فرستاده‌اید، یک گزارش مالی که با شریک تجاری به اشتراک گذاشته‌اید یا یک دورهٔ آموزشی که برای کارکنان ساخته‌اید؛ همهٔ این‌ها با چند کلیک قابل کپی و انتشارند. مدیریت حقوق دیجیتال یا DRM برای همین ساخته شده است: کنترل اینکه محتوای دیجیتال، حتی پس از خروج از دست شما، چگونه و توسط چه کسی استفاده شود.‏مسئلهٔ اصلی: کپی دیجیتال هزینه ندارد‏در دنیای فیزیکی، تکثیر یک سند یا کتاب زحمت و هزینه داشت. در دنیای دیجیتال، هر کاربر یک ناشر بالقوه است و کپی برای کسی که آن را می‌سازد تقریباً رایگان است. نتیجه‌اش هم روشن است: از انتشار غیرقانونی فیلم و نرم‌افزار تا نشت اسناد داخلی و مستندات تحقیق و توسعه. سازمان‌ها، به‌ویژه وقتی با شرکا و پیمانکاران بیرونی کار می‌کنند، به ابزاری نیاز دارند که پس از اشتراک‌گذاری هم کنترل را از دست ندهند. الزامات حقوقی و قراردادی حق نشر هم همین را می‌طلبد.‏DRM با چه سازوکارهایی کار می‌کند‏رمزگذاری محتوا: فایل فقط با احراز هویت و مجوز معتبر باز می‌شود‏مدیریت کلیدهای دسترسی: تعیین اینکه چه کسی بتواند فایل را باز، کپی، دانلود یا چاپ کند یا از صفحه تصویر بگیرد‏سیاست استفاده: فرستنده مشخص می‌کند محتوا چگونه و تا چه زمانی قابل استفاده است‏اعتبارسنجی دستگاه: محدود کردن استفاده به تعداد معینی دستگاه و جلوگیری از باز شدن در محیط مشکوک‏ردگیری و نشانه‌گذاری: ثبت باز شدن و تلاش برای کپی، به‌همراه واترمارک و اثرانگشت دیجیتال برای یافتن منبع نشت‏DRM جای DLP را نمی‌گیرد‏این دو اغلب با هم اشتباه گرفته می‌شوند. DLP مراقب است چه داده‌ای از سازمان خارج می‌شود و جلوی خروج غیرمجاز را می‌گیرد. DRM از لحظه‌ای وارد کار می‌شود که فایل بیرون رفته است. به بیان ساده، DLP مرز را می‌بندد و DRM فرض می‌کند روزی مرز شکسته می‌شود. هر دو هم به یک لایهٔ هویت قابل اتکا نیاز دارند؛ بدون احراز هویت محکم، هیچ سیاست کنترل استفاده‌ای معنا ندارد.‏یک قدم عملی برای شروع: فایل‌هایی را که مرتب با بیرون از سازمان به اشتراک می‌گذارید فهرست کنید و بپرسید اگر فردا یکی از آن‌ها نشت کند، آیا می‌توانید بفهمید از کجا بیرون رفته است؟‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در سایت symantecland دات کام منتشر شده است؛ برای رسیدن مستقیم به آن، بعد از نام سایت در نوار آدرس مرورگر بنویسید: /drm-digital‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویSat, 24 Oct 2026 14:44:43 +0330https://virgool.ir/@KazemMortazavi/مدیریت-حقوق-اطلاعات-irm-وقتی-فایل-بعد-از-خروج-از-سازمان-هم-تحت-کنترل-می-ماند-dmdzhwvabprm‏قراردادی که با ایمیل برای یک شریک تجاری فرستاده‌اید، از لحظهٔ ارسال دیگر در شبکهٔ شما نیست. ممکن است دانلود شود، دوباره فوروارد شود یا روی گوشی شخصی کسی باز شود که هرگز قرار نبود آن را ببیند. مدیریت حقوق اطلاعات یا IRM پاسخ همین مسئله است: به‌جای اینکه فقط از مسیر و محیط محافظت کنیم، سیاست امنیتی را روی خود فایل می‌گذاریم تا هر جا برود، همراهش باشد.‏چرا کنترل محیط دیگر کافی نیست‏فایروال، کنترل دسترسی شبکه و حتی جلوگیری از خروج داده همه یک فرض مشترک دارند: داده داخل مرزهای سازمان می‌ماند. اما کار روزمره این فرض را می‌شکند. اسناد بین تیم‌ها، پیمانکاران و مشتریان دست‌به‌دست می‌شوند و روی دستگاه‌هایی باز می‌شوند که سازمان هیچ کنترلی رویشان ندارد. از لحظه‌ای که فایل بیرون رفت، ابزارهای مبتنی بر محیط دیگر چیزی نمی‌بینند.‏IRM روی خود فایل چه می‌کند‏در IRM هر بار باز کردن فایل یک تصمیم امنیتی تازه است. چند سازوکار این کار را ممکن می‌کنند:‏رمزنگاری دائمی: رمزنگاری با فایل می‌ماند، نه فقط در مسیر انتقال یا روی دیسک‏احراز هویت پیش از باز شدن: فقط کاربر مجاز و پس از ورود می‌تواند محتوا را ببیند‏محدودیت عملیات: کپی، چاپ، ارسال مجدد و تصویربرداری از صفحه را می‌توان بست‏انقضا و محیط مجاز: محتوا می‌تواند پس از مدتی منقضی شود یا در ماشین مجازی و دستگاه Jailbreak‌شده باز نشود‏ابطال از راه دور: حتی پس از ارسال یا دانلود، دسترسی قابل لغو است؛ همین تفاوت اصلی IRM با رمزنگاری ساده است‏ثبت دقیق اینکه چه کسی، کی و از کجا فایل را باز کرده هم به تیم امنیت دیدی می‌دهد که پیش‌تر وجود نداشت.‏جایگاه IRM کنار DLP و DRM‏این سه را نباید با هم اشتباه گرفت. DRM بیشتر برای محتوای دارای حق نشر است؛ IRM برای اسناد کاری سازمان. DLP جلوی خروج داده را می‌گیرد و IRM از داده‌ای محافظت می‌کند که به هر دلیل بیرون رفته است. بهترین نتیجه از ترکیب این دو به دست می‌آید، به‌شرط آنکه یک لایهٔ هویت قابل اتکا هم پشتشان باشد؛ IRM بدون احراز هویت محکم معنایی ندارد.‏یک قدم عملی برای شروع: سه دسته سندی را که اگر امروز به دست نادرست برسند بیشترین آسیب را می‌زنند فهرست کنید و ببینید آیا پس از ارسال، هنوز می‌توانید دسترسی به آن‌ها را پس بگیرید یا نه.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در سایت symantecland دات کام منتشر شده است؛ برای رسیدن مستقیم به آن، بعد از نام سایت در نوار آدرس مرورگر بنویسید: /irm-information‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویSat, 24 Oct 2026 13:44:47 +0330https://virgool.ir/@KazemMortazavi/دستورالعمل-nis-2-و-فاصلهٔ-ما-چرا-مشکل-امنیت-سازمان-ها-سند-نیست-اجراست-qzatj2yvvilq‏اگر فردا حادثه‌ای امنیتی در سازمان شما رخ دهد، چه کسی شخصاً پاسخ‌گو است؟ و آیا هیچ سازمان دیگری تا یک روز بعد از آن باخبر می‌شود؟ دستورالعمل NIS 2 اتحادیهٔ اروپا دقیقاً به همین دو پرسش جواب روشن داده است؛ و مقایسهٔ آن با الزامات داخلی نشان می‌دهد که مشکل ما کمبود سند نیست.‏سه جایی که NIS 2 سخت‌گیرتر است‏پاسخ‌گویی فردی، نه سازمانی: در NIS 2 مدیر ارشدی که کوتاهی کند، می‌تواند شخصاً جریمه یا از سمتش کنار گذاشته شود. وقتی هزینهٔ بی‌توجهی به نام هیچ فردی نوشته نشود، امنیت همیشه اولویت دوم می‌ماند.‏زنجیرهٔ تأمین با معیار فرایند: نگاه اروپایی می‌پرسد تأمین‌کننده چقدر شفاف و ارزیابی‌شده است؛ نگاه داخلی بیشتر می‌پرسد محصول بومی است یا نه. اما بومی بودن جای فرایند امن را نمی‌گیرد.‏جریمه‌ای که واقعاً درد دارد: سقف جریمه در NIS 2 حدود ۲ درصد گردش مالی سالانه است. الزامی که پشتوانهٔ مالی بازدارنده نداشته باشد، به‌راحتی به تشریفات اداری تبدیل می‌شود.‏شکاف اصلی: پنهان‌کاری‏بزرگ‌ترین فاصله در گزارش‌دهی است. در مدل اروپایی، حادثه باید ظرف ۲۴ ساعت گزارش شود تا بقیه هم در برابر همان تهدید آماده شوند. در فرهنگ سازمانی ما، حادثه برای حفظ آبرو پنهان می‌ماند؛ نتیجه این است که هر سازمان همان اشتباه را از صفر تجربه می‌کند و تاب‌آوری جمعی هیچ‌وقت شکل نمی‌گیرد. گزارش‌دهی شفاف، نشانهٔ ضعف نیست؛ نشانهٔ بلوغ است.‏از کجا شروع کنیم؟‏۱. فهرست دارایی و ارزیابی ریسک: بدون دانستن اینکه چه چیزی دارید، هیچ ارزیابی ریسکی معتبر نیست.‏۲. توان تشخیص سریع: گزارش ۲۴ ساعته بدون رصد مستمر و تشخیص به‌موقع ممکن نیست.‏۳. ثبت دقیق اقدامات دسترسی‌های ممتاز: مسئولیت شخصی فقط وقتی معنا دارد که معلوم باشد چه کسی چه کاری کرده است.‏۴. برنامهٔ تداوم کسب‌وکار و حفاظت از داده: بازیابی آزموده‌شده و کنترل نشت اطلاعات، دو ستون تاب‌آوری‌اند.‏امنیت سایبری ما در سندنویسی از دنیا عقب نیست؛ عقب‌ماندگی در اجرا و پذیرش مسئولیت در سطح مدیریت ارشد است. تا وقتی امنیت چک‌لیست اداری بماند و فرهنگ سازمانی نشود، فاصله باقی است.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در سایت symantecland دات کام منتشر شده است؛ برای رسیدن مستقیم به آن، بعد از نام سایت در نوار آدرس مرورگر بنویسید: /nis2-compliance‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویSat, 24 Oct 2026 12:46:55 +0330https://virgool.ir/@KazemMortazavi/لایسنس-فورتی-گیت-و-وصلهٔ-اضطراری-اکتبر-نقص-هایی-که-هوش-مصنوعی-پیدا-کرد-و-cve-ندارند-u3dhcn2fbqlr‏این هفته فورتی‌نت کاری کرد که کمتر از یک فروشندهٔ بزرگ دیده‌ایم: وصله را منتشر کرد، اما گفت چه چیزی را وصله کرده است، تا سه هفتهٔ دیگر نمی‌گوید. برای هر سازمانی که لایسنس فورتی گیت و پشتیبانی فعال دارد، این یعنی ارتقا همین حالا، نه وقتی CVE آمد.‏ماجرا چه بود‏فورتی‌نت روزهای ۲۱ و ۲۲ اکتبر ۲۰۲۶ نسخه‌های تازهٔ FortiOS، FortiManager، FortiAnalyzer، FortiMail و FortiAuthenticator را منتشر کرد. این نسخه‌ها چند نقص بحرانی و پرخطر را می‌بندند که خود فورتی‌نت با کمک مدل‌های پیشرفتهٔ هوش مصنوعی در آزمون امنیتی محصولاتش پیدا کرده است. شناسهٔ CVE، امتیاز CVSS و نوع نقص‌ها تا ۱۰ نوامبر منتشر نمی‌شود.‏نسخه‌های امن FortiOS این‌ها هستند: 8.0.2، 7.6.8، 7.4.13 و 7.2.14. برای FortiManager و FortiAnalyzer نسخه‌های 8.0.2، 7.6.8، 7.4.12 و 7.2.13 امن‌اند. FortiOS 7.0 و قدیمی‌تر در این انتشار وصله ندارد. تا روز جمعه گزارشی از بهره‌برداری منتشر نشده بود.‏چرا منتظر CVE نمانیم‏دلیل فورتی‌نت برای پنهان نگه داشتن جزئیات ساده است: هوش مصنوعی مقایسهٔ نسخهٔ قدیم و جدید و ساخت اکسپلویت را چند ساعته کرده است. اما همین منطق برعکس هم کار می‌کند؛ فایل نسخهٔ جدید از همین امروز در دسترس مهاجم هم هست. طبق تحلیل Mandiant، میانگین فاصلهٔ افشا تا بهره‌برداری در سال ۲۰۲۳ فقط ۵ روز بود.‏پنج کار برای این هفته‏همهٔ دستگاه‌ها و نسخه‌ها را فهرست کنید و از پیکربندی پشتیبان بگیرید.‏اول فایروال‌ها و دروازه‌های ایمیل رو به اینترنت را ارتقا دهید.‏FortiManager و FortiAnalyzer را پیش از FortiGateها ارتقا دهید و مسیر ارتقا را بررسی کنید.‏تا زمان ارتقا، دسترسی مدیریتی HTTPS و SSH را از اینترنت ببندید و برای مدیران احراز هویت چندعاملی بگذارید.‏مطمئن شوید پشتیبانی همهٔ دستگاه‌ها فعال است؛ بدون آن، فرم‌ور جدید را نمی‌توانید دانلود کنید.‏به تجربهٔ من، در روز وصلهٔ اضطراری، کندترین بخش کار فنی نیست؛ پیدا کردن دستگاهی است که تمدید پشتیبانی‌اش فراموش شده بود.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در سایت symantecland دات کام منتشر شده است؛ برای رسیدن مستقیم به آن، بعد از نام سایت در نوار آدرس مرورگر بنویسید: /fortinet-ai‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویSat, 24 Oct 2026 10:40:09 +0330https://virgool.ir/@KazemMortazavi/زیرو-دی-velocloud-orchestrator-وقتی-یک-حساب-فقط-خواندنی-کلید-کل-شبکهٔ-شعب-می-شود-xjtgbzxizwur‏این هفته یک یادآوری تلخ برای تیم‌های شبکه داشت: در کنسول مرکزی SD-WAN، حتی حسابی که فقط اجازهٔ «دیدن» دارد، می‌تواند در دست مهاجم به کلید کل شبکهٔ شعب تبدیل شود.‏ماجرا چه بود‏شرکت Arista روز ۲۲ اکتبر ۲۰۲۶ برای نقص CVE-2026-114625 در VeloCloud Orchestrator نسخهٔ On-Prem وصلهٔ فوری منتشر کرد. این نقص از نوع تزریق SQL است، امتیاز 9.9 دارد و به گفتهٔ خود Arista در حمله‌ها به کار رفته است. مهاجمی که فقط یک نشست معتبر با پایین‌ترین نقش، یعنی Enterprise Read Only، داشته باشد، می‌تواند دسترسی اپراتور بگیرد و خود را جای کاربر superuser operator جا بزند.‏نسخه‌های امن 5.2.3.18، 6.1.3.10 و 6.4.2.12 هستند. شاخهٔ 7.0 در فهرست آسیب‌پذیر نیست و کنسول‌های Hosted و Dedicated را خود Arista وصله کرده است. تجهیزات Edge و Gateway هم درگیر نیستند.‏چرا این بار جدی‌تر است‏این سومین زیرو-دی بهره‌برداری‌شده در همین کنسول از اواخر ژوئیه است. نکتهٔ مهم‌تر این‌که نسخه‌هایی که دو نقص قبلی (ژوئیه و سپتامبر) را بستند، هنوز در برابر نقص تازه باز هستند. یعنی تیمی که ماه گذشته با عجله وصله کرده و پرونده را بسته، باید دوباره سراغ کنسول برود.‏مشکل دوم، حساب‌های فراموش‌شده است. در بیشتر سازمان‌ها برای پیمانکار پشتیبانی یا تیم پایش حساب فقط‌خواندنی ساخته می‌شود و کسی رمز آن را جدی نمی‌گیرد. حالا همین حساب‌ها نقطهٔ شروع حمله‌اند.‏پنج کار برای امروز‏کنسول را به یکی از نسخه‌های امن ارتقا دهید و نسخه‌های خارج از پشتیبانی را با پشتیبانی Arista بررسی کنید.‏رابط وب کنسول را فقط از شبکهٔ مدیریتی در دسترس بگذارید.‏دو نشانی 74.82.197.86 و 38.54.50.151 را مسدود کنید و لاگ‌های گذشته را برایشان جست‌وجو کنید.‏حساب‌های فقط‌خواندنی و پیمانکاران را بازبینی و رمزها را عوض کنید.‏لاگ وب کنسول را برای نویسه‌های کدشده، ارجاع به سرویس‌های داخلی و نرخ بالای درخواست بررسی کنید و پیش از هر اصلاح، شواهد را نگه دارید.‏به تجربهٔ من، کنسول‌های مدیریت مرکزی معمولاً آخرین چیزی هستند که در فهرست دارایی‌ها و برنامهٔ وصله دیده می‌شوند، در حالی که ارزشمندترین هدف شبکه‌اند.‏نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در سایت symantecland دات کام منتشر شده است؛ برای رسیدن مستقیم به آن، بعد از نام سایت در نوار آدرس مرورگر بنویسید: /velocloud-orchestrator‏— کاظم مرتضوی، مشاور مستقل امنیت شبکهکاظم مرتضویکاظم مرتضویFri, 23 Oct 2026 07:38:55 +0330