🔴 از VPN تا کنترل کامل هایپروایزر

◀️ تحقیقات تازه نشون میده مهاجم‌های چینی از یه زنجیره واقعی و کامل برای رسیدن به کنترل هایپروایزر ESXi استفاده کردن نه یه اکسپلویت ساده، بلکه ترکیبی از چند تکنیک که با هم یه مسیر کامل رو می‌سازن.
◀️ نقطه ورود، یه دستگاه VPN متعلق به SonicWall بوده که از قبل به آسیب پذیری داشت. از همون مسیر، مهاجم‌ها به سراغ سه آسیب‌پذیری ESXi رفتن: CVE-2025-22224 (امتیاز ۹.۳)، CVE-2025-22225 (امتیاز ۸.۲) و CVE-2025-22226 (امتیاز ۷.۱).
◀️ بخش فنی جالب ماجرا اینه که اول از HGFS (یعنی سیستم اشتراک‌گذاری فایل بین مهمان و میزبان) برای نشت اطلاعات حافظه استفاده کردن، بعد از VMCI (کانال ارتباطی بین VM و هاست) برای خراب کردن حافظه و دستکاری یه Pointer. وقتی VMX این پیام رو پردازش می‌کنه، به‌جای مسیر درست، به سمت Shellcode مهاجم هدایت می‌شه این دقیقاً همون لحظه‌ایه که مرز Sandbox شکسته می‌شه.

◀️ نکته : طبق شواهد، این Exploit احتمالاً از فوریه ۲۰۲۴ در حال توسعه بوده، یعنی ماه‌ها قبل از افشای عمومی این باگ‌ها (مارس ۲۰۲۵) آماده بوده.

🔐 هر سه این باگ‌ها سال‌هاست پچ شدن، ولی چون نقطه ورود یه VPN جداگونه بوده، خیلی از تیم‌ها حتی فکرشو نمی‌کردن که یه آسیب‌پذیری VPN بتونه نهایتاً به کنترل کامل ESXi ختم بشه. امنیت لایه‌ای یعنی دقیقاً همین: فرض نکنید چون VPN شما جداست، اثرش روی هایپروایزر هم جدا می‌مونه.

#VMware #ESXi #VMEscape #CVE #CloudSecurity

📱 @Abrplusdocs
t.me/abrplusdocs

🛡 ۵۰ اصطلاح مهم دنیای امنیت سایبری که در 2026 باید بلد باشید!

✅ مفاهیم پایه امنیت:

🔸 CIA – محرمانگی، یکپارچگی، دسترس‌پذیری
🔸 APT – تهدید ماندگار پیشرفته
🔸 SOC – مرکز عملیات امنیت
🔸 SIEM – مدیریت اطلاعات و رویدادهای امنیتی
🔸 DLP – جلوگیری از نشت اطلاعات

🌐 امنیت شبکه و نقطه پایانی:

🔸 IDS – سیستم تشخیص نفوذ
🔸 IPS – سیستم جلوگیری از نفوذ
🔸 EDR – تشخیص و پاسخ نقطه پایانی
🔸 NAC – کنترل دسترسی به شبکه
🔸 UEBA – تحلیل رفتار کاربران و نهادها

🔐 مدیریت هویت و دسترسی:

🔸 IAM – مدیریت هویت و دسترسی
🔸 MFA – احراز هویت چندمرحله‌ای
🔸 SSO – ورود یکپارچه
🔸 RBAC – کنترل دسترسی مبتنی بر نقش
🔸 PAM – مدیریت دسترسی ممتاز

🧠 اطلاعات تهدید و بدافزار:

🔸 IOC – نشانگرهای نفوذ
🔸 TTP – تاکتیک‌ها، تکنیک‌ها، روش‌ها
🔸 MITRE ATT&CK – پایگاه دانش رفتارهای مهاجم
🔸 C2 – فرمان و کنترل
🔸 RAT – تروجان دسترسی از راه دور

☁️ امنیت وب، اپلیکیشن و فضای ابری:

🔸 WAF – فایروال اپلیکیشن وب
🔸 CASB – واسط امنیتی دسترسی به فضای ابری
🔸 SAST – تست امنیت ایستای کد
🔸 DAST – تست امنیت پویا
🔸 CSPM – مدیریت وضعیت امنیت فضای ابری

📋 ریسک و تطابق با قوانین:

🔸 GRC – حاکمیت، ریسک و انطباق
🔸 PII – اطلاعات شناسایی شخصی
🔸 GDPR – مقررات حفاظت از داده اتحادیه اروپا
🔸 HIPAA – قانون حفاظت اطلاعات سلامت
🔸 SOX – قانون ساربنز-آکسلی

🚨 واکنش به رخداد و تداوم کسب‌وکار:

🔸 IR – پاسخ به رخداد
🔸 BCP – برنامه تداوم کسب‌وکار
🔸 DRP – برنامه بازیابی از فاجعه
🔸 MTTR – میانگین زمان بازیابی
🔸 RTO – هدف زمان بازیابی

🧩 چارچوب‌های امنیت سایبری:

🔸 NIST – مؤسسه استانداردهای ملی آمریکا
🔸 ISO – سازمان بین‌المللی استانداردسازی
🔸 CIS – مرکز امنیت اینترنت
🔸 CMMC – گواهی بلوغ امنیت سایبری
🔸 COBIT – اهداف کنترلی برای فناوری اطلاعات

💣 تهدیدات و اکسپلویت‌ها:

🔸 DoS – حمله محروم‌سازی از سرویس
🔸 DDoS – حمله توزیع‌شده محروم‌سازی
🔸 XSS – اسکریپت‌نویسی بین سایتی
🔸 SQLi – تزریق SQL
🔸 MITM – مرد میانی

🚀 فناوری‌های نوظهور و ابزارهای امنیتی:

🔸 SOAR – ارکستراسیون و خودکارسازی امنیت
🔸 XDR – تشخیص و پاسخ گسترده
🔸 ZTA – معماری اعتماد صفر
🔸 SASE – دسترسی ایمن به لبه سرویس
🔸 CNAPP – پلتفرم حفاظت از اپلیکیشن‌های ابری بومی

@abrplusdocs

دستورات کمتر دیده‌شده در لینوکس

دستور inxi ابزاری قدرتمند برای نمایش اطلاعات سخت‌افزار، سیستم، شبکه و وضعیت منابع لینوکس است.
🔹 اطلاعات سخت‌افزار
🔹 سیستم و نرم‌افزار
🔹 شبکه
🔹 پردازنده و منابع
🔹 دیسک و پارتیشن
🔹 سنسورها و دما
چند سویچ کاربردی:
inxi -v7 # اطلاعات کامل سیستم
inxi -F # خلاصه کامل اطلاعات سیستم
inxi -C # اطلاعات CPU
inxi -G # اطلاعات GPU و درایور
inxi -Nxx # اطلاعات دقیق شبکه
inxi -Mxxx # اطلاعات مادربرد
inxi -D # اطلاعات دیسک‌ها
inxi -p # پارتیشن‌ها
inxi -r # مخازن سیستم
inxi -A # تجهیزات صوتی
inxi -B # باتری
inxi -t cpu # پردازش‌های CPU
inxi -I 5 # اطلاعات سیستم با فاصله ۵ ثانیه
inxi -MCGST # اطلاعات فشرده سخت‌افزار و دما


@abrplusdocs

دوستان اگه پروژه اوپن سورس تو GitHub دارید وارد این لینک شید ChatGPT بهتون ۶ ماه اشتراک پرو + کدکس میده 🩵
https://openai.com/form/codex-for-oss/?utm_source=sp_auto_dm&fbclid=PAVERFWAUu1qFleHRuA2FlbQIxMABwZG9mAnNydGMGYXBwX2lkDzU2NzA2NzM0MzM1MjQyNwABp8FwEeipZUovEAK4ZucffFvEKRGFmGKYUdmf_zu66KwKh6Zd-dSD36p1RAU__aem_U207MXv65Lyp1cdTJuKBGw

⚙️ فرق Reservation، Limit و Shares که خیلیا قاطی می‌کنن

◀️ تو VMware، سه تا مفهوم برای کنترل منابع (CPU/Memory) وجود داره که خیلی وقتا با هم اشتباه گرفته می‌شن، درحالی‌که هرکدوم کار کاملاً متفاوتی می‌کنن.
◀️ قابلیت Reservation یعنی حداقل تضمین‌شده؛ یه مقدار منبع که همیشه برای اون VM کنار گذاشته می‌شه، حتی اگه کل محیط تحت فشار باشه. اگه این مقدار رو آزاد نذارید، ممکنه VM اصلاً Power On نشه چون هاست نمی‌تونه این تضمین رو بده.
◀️ قابلیت Limit دقیقاً برعکسه؛ یعنی سقف مصرف. حتی اگه منابع آزاد فراوون باشه، VM نمی‌تونه از این مرز رد بشه. خیلی وقتا ادمین‌ها Limit می‌ذارن و بعد نمی‌فهمن چرا VM با وجود منابع آزاد، کند شده.
◀️ قابلیت Shares فرق اساسی داره: فقط وقتی به‌کار میاد که منابع کمه و باید بین VM ها تقسیم بشه؛ یعنی یه وزن نسبیه، نه یه عدد مطلق. اگه منابع آزاد کافیه، Shares اصلاً اثری نداره.

✅ نکته : از Limit فقط وقتی استفاده کنید که واقعاً می‌خواید یه VM رو عمداً محدود کنید (مثلاً تو محیط تست). برای محیط Production، معمولاً بهتره فقط رو Reservation و Shares تمرکز کنید، نه Limit.

#VMware #vSphere #آموزش #مدیریت_منابع

📱 @Abrplusdocs
t.me/abrplusdocs

گوگل می‌خواهد دیتاسنتر را به فضا ببرد!
‌
اکتبر ۲۰۲۶ گوگل با پروژه Suncatcher اولین ماهواره آزمایشی خود را به اندازه یک یخچال‌فریز با ۴ تراشه TPUبه فضا فرستاد، قرار است به یک سؤال جواب بدهد:
‌
آیا پروژه دیتاسنتر و تراشه هوش مصنوعی در فضا میتواند موفق شود؟
‌
هوش مصنوعی تشنه برق است و در مدار خورشید، پنل خورشیدی تا ۸ برابر زمین انرژی می‌دهد؛ بدون شب، بدون ابر، بدون شبکه برق.
‌
اما تناقض جذاب اینجاست که فضا با همه سرمایش، داغ است.
‌
در خلأ هوا نیست که گرما را ببرد. گرمای TPU باید با لوله حرارتی و رادیاتور به تابش مادون قرمز تبدیل شود پس تراشه‌ها فقط در بازه‌های ۱۵ دقیقه‌ای روشن می‌مانند و بعد برای دفع گرما خاموش می‌شوند.
‌
چالش‌های بعدی بزرگ‌ترند: تابش فضایی، تعمیر پرچالش در مدار، زباله فضایی، آلودگی نوری آسمان و مهم‌تر از همه هزینه بسیار بالای پرتاب. دیتاسنتر فضایی با زمین رقابت نمی‌کند. به نظر تو، Suncatcher راه نجات انرژی دیتاسنتر و هوش مصنوعی است یا بلندپروازانه‌ترین آزمایش مهندسی دهه؟

#تیام_شبکه #مرکز_داده #دیتاسنتر #هوش_مصنوعی

@abrplusdocs

یه مینی‌اپ داخل تلگرام که کارای کوچیک رو یادت میندازه و پیشرفتت رو ثبت می‌کنه 💻

• مستقیم داخل تلگرام بهت ریمایندر و یادآور می‌فرسته
• با کامل کردن عادت‌ها به‌صورت روزانه، استریکت حفظ میشه و بعد یه مدت می‌تونی ببینی چند روز واقعاً پای علاقه‌ت وقت گذاشتی
• عادت‌هات رو خودت می‌سازی و برای هرکدوم زمان یادآوری مشخص می‌کنی

برای ورود به مینی اپ👇🏻
🔗 https://t.me/routyappbot/open

☁️ اسنپ شات بکاپ نیست!

یکی از اشتباهاتی که هنوز در بعضی زیرساخت‌ها دیده میشه، استفاده از اسنپ شات به‌عنوان Backup هست.

اسنپ شات برای این ساخته شده که وضعیت یک VM یا Volume را در یک نقطه زمانی ثبت کنیم تا در صورت نیاز بتوانیم به آن وضعیت برگردیم.

مثلاً قبل از:

🔹 آپدیت سیستم‌عامل
🔹 نصب یک نرم‌افزار مهم
🔹 تغییر Configuration
🔹 انجام یک عملیات پرریسک

گرفتن Snapshot می‌تونه تصمیم خوبی باشه.

اما مشکل از جایی شروع میشه که Snapshot را جایگزین Backup کنیم.

فرض کنید Storage اصلی دچار خرابی جدی بشه.

اگر VM و Snapshot هر دو روی همان Storage باشند، داشتن Snapshot لزوماً کمکی به بازیابی اطلاعات نمی‌کند.

بکاپ داستان متفاوتی دارد.

یک Backup درست باید نسخه‌ای مستقل از داده ایجاد کند و بر اساس سیاست‌های نگهداری، در Repository یا حتی موقعیت دیگری نگهداری شود.

به زبان ساده:

📸 Snapshot
برای برگشت سریع به وضعیت قبلی

💾 Backup
برای بازیابی اطلاعات بعد از خرابی، حذف، Corruption یا Disaster

پس اگر روی یک VM چند Snapshot دارید، به این معنی نیست که از آن VM چند Backup دارید.

گاهی همین تفاوت ساده، روز حادثه تفاوت بین چند دقیقه Downtime و از دست رفتن اطلاعات است.

#Cloud #Backup #Snapshot #Virtualization #DisasterRecovery #Infrastructure

☁️ ابرپلاس | Cloud & Infrastructure

@abrplusdocs

🖥️ چطور یک سرور با ۱۲۸ گیگ RAM می‌تونه بیشتر از ۱۲۸ گیگ RAM به ماشین‌ها بده؟

یکی از قابلیت‌های مهم مجازی‌سازی، مفهومی به نام Overcommitment هست.

فرض کنید یک Host داریم با:

"128 GB RAM"

اما مجموع RAM اختصاص داده‌شده به VMهای روی آن شده:

"180 GB"

در نگاه اول عجیب به نظر می‌رسه؛ چیزی که وجود نداره چطور اختصاص داده شده؟

دلیلش اینه که معمولاً همه VMها به‌صورت همزمان از تمام منابعی که بهشون اختصاص داده شده استفاده نمی‌کنن.

هایپروایزور از همین موضوع استفاده می‌کنه و اجازه میده مجموع منابع تخصیص‌یافته از منابع فیزیکی Host بیشتر باشه.

این موضوع فقط درباره RAM نیست و در CPU هم بسیار رایجه.

مثلاً ممکنه یک Host دارای 32 Core فیزیکی باشه ولی مجموع vCPU ماشین‌های آن بسیار بیشتر از 32 باشه.

اما اینجا یک نکته مهم وجود داره:

اگر تعداد زیادی VM همزمان منابع خودشون رو مصرف کنن، Host وارد Contention میشه و Performance ماشین‌ها افت می‌کنه.

در Memory فشار زیاد می‌تونه باعث استفاده از مکانیزم‌هایی مثل Ballooning یا Swap بشه و در CPU هم VMها برای دریافت CPU Time بیشتر منتظر می‌مونن.

بنابراین Overcommit اگر درست ظرفیت‌سنجی بشه:

✅ استفاده بهتر از سخت‌افزار
✅ افزایش Consolidation
✅ کاهش منابع بلااستفاده

اما اگر بدون Monitoring و Capacity Planning انجام بشه:

❌ افت Performance
❌ افزایش Latency
❌ ایجاد Bottleneck

📌 در مجازی‌سازی، مهم نیست فقط «چقدر Resource اختصاص داده‌ایم»؛ مهم‌تر اینه که ماشین‌ها واقعاً چقدر از آن Resource را مصرف می‌کنند.

#Virtualization #VMware #KVM #Performance #Infrastructure #Cloud

☁️ ابرپلاس | Cloud & Infrastructure
@abrplusdocs

🚨 هشدار مهم VMware؛ قبل از ارتقا به vCenter 9.1.x دست نگه دارید

شرکت VMware یک هشدار مهم برای کارشناسان زیرساخت منتشر کرده که مخصوص محیط‌هایی است که از vSphere Supervisor یا VMware vSphere Kubernetes Service (VKS) استفاده می‌کنند.

طبق اعلام VMware، در شرایط خاص ارتقا به:

"vCenter Server 9.1.0"
یا
"vCenter Server 9.1.1"

می‌تواند منجر به حذف و از دست رفتن Supervisor Control Plane VMها و Foundation Load Balancerها شود.

⚠️ اما همه محیط‌ها درگیر این مشکل نیستند.

ریسک مربوط به محیط‌هایی است که قبلاً برای رفع مشکلات Repository یا Sync، عملیات Reset دیتابیس vLCM/VUM را انجام داده‌اند.

ای شرکت اعلام کرده این Reset در برخی نسخه‌های قبلی می‌تواند باعث ایجاد ناسازگاری در Schema دیتابیس شود.

مشکل اصلی هنگام Upgrade خودش را نشان می‌دهد؛ جایی که سیستم جدید Lifecycle Management برای شناسایی System VMها به همین اطلاعات دیتابیس وابسته است.

نسخه‌های مبدأیی که باید مورد توجه قرار بگیرند:

🔹 vCenter 8.0 Update 3 و بالاتر
🔹 vCenter 9.0.0
🔹 vCenter 9.0.1
🔹 vCenter 9.0.2

و مقصد:

🔴 vCenter 9.1.0 / 9.1.1

این کمپانی برای بررسی و اصلاح این وضعیت، اسکریپت Validation و Remediation ارائه کرده و تأکید کرده قبل از Upgrade باید Consistency دیتابیس بررسی شود.


منبع: VMware Cloud Foundation Blog – 9 October 2026

#VMware #vCenter #vSphere #VKS #Kubernetes #Virtualization #Infrastructure

☁️ ابرپلاس | Cloud & Infrastructure

@abrplusdocs

📊 آیا سازمان‌ها واقعاً در حال ترک VMware هستند؟

یک نظرسنجی جدید از ۳۰۰ مشتری VMware عدد قابل‌توجهی را نشان می‌دهد:

حدود ۹۰٪ پاسخ‌دهندگان گفته‌اند در حال بررسی گزینه‌های جایگزین VMware هستند.

اما قسمت جالب ماجرا این عدد نیست.

حدود ۶۰٪ سازمان‌ها به Multi-Hypervisor فکر می‌کنند.

یعنی به‌جای اینکه VMware را یک‌شبه خاموش کنند و همه Workloadها را روی پلتفرم دیگری ببرند، احتمالاً با چنین معماری‌هایی بیشتر روبه‌رو خواهیم شد:

VMware + OpenStack

VMware + Proxmox

VMware + Nutanix

یا ترکیبی از Virtual Machine و Container Platformها.

چرا؟

چون مهاجرت صدها یا هزاران VM فقط مسئله تبدیل VMDK به QCOW2 نیست.

شبکه، Backup، Monitoring، DR، Automation، مهارت تیم، عملیات روزانه و حتی Runbookهای سازمان طی سال‌ها حول یک پلتفرم شکل گرفته‌اند.

به همین دلیل شاید تغییر اصلی بازار Virtualization این نباشد که:

«چه چیزی جای VMware را می‌گیرد؟»

بلکه سؤال مهم‌تر این باشد:

«چطور وابستگی کامل به یک Hypervisor را از بین ببریم؟»

البته یک نکته مهم درباره این آمار وجود دارد:

این Survey توسط Rimini Street انجام شده؛ شرکتی که خودش خدمات Third-Party Support ارائه می‌دهد.

بنابراین عدد ۹۰٪ را نباید به معنی «۹۰٪ مشتریان VMware در حال مهاجرت هستند» تفسیر کرد.

اما افزایش توجه به Multi-Hypervisor و کاهش Vendor Lock-in، روندی است که مدیران زیرساخت بهتر است جدی بگیرند.

شاید معماری آینده Datacenter دیگر برنده‌ای با عنوان «تنها Hypervisor سازمان» نداشته باشد.

#VMware #OpenStack #Proxmox #Virtualization #PrivateCloud #Infrastructure #Cloud

☁️ ابرپلاس | Cloud & Infrastructure

@abrplusdocs

#fun
Migrate from VMware 🫢
@abrplusdocs

🔴 تغییر مهم دیگری در اکوسیستم VMware؛ این بار پای IBM در میان است
شرکت IBM توافق کرده بخشی از کسب‌وکار VMware Cloud خود را به شرکت 11:11 Systems منتقل کند؛ معامله‌ای که صدها مشتری سازمانی VMware را شامل می‌شود.
طبق گزارش The Register، این انتقال در شرایطی انجام می‌شود که Broadcom در حال تغییر ساختار برنامه VMware Cloud Service Provider است و ارائه‌دهندگان این حوزه باید خودشان را با مدل جدید تطبیق دهند.
اما چیزی که این خبر را مهم می‌کند فقط IBM نیست.
ماجرا بخشی از تغییر بزرگ‌تری است که بعد از خرید VMware توسط Broadcom در اکوسیستم Virtualization شکل گرفته.
تغییر مدل Licensing، بازطراحی Partner Program، افزایش هزینه در برخی قراردادها و تغییر شرایط Service Providerها باعث شده بسیاری از سازمان‌ها دوباره درباره استراتژی مجازی‌سازی خود فکر کنند.
نکته مهم اینجاست:
مهاجرت از VMware الزاماً به معنی «حذف VMware» نیست.
بعضی سازمان‌ها به سمت مدل‌های ترکیبی می‌روند و در کنار VMware، پلتفرم‌های دیگری را وارد زیرساخت می‌کنند.
در چنین شرایطی مفاهیمی مثل:
🔹 Multi-Hypervisor
🔹 Private Cloud
🔹 KVM
🔹 OpenStack
🔹 Proxmox
🔹 Kubernetes
بیشتر از گذشته وارد تصمیم‌های معماری می‌شوند.
📌 به نظر می‌رسد سؤال مدیران زیرساخت کم‌کم از:
«آیا VMware را عوض کنیم؟»
به این سؤال تغییر کرده:
«اگر روزی مجبور شدیم VMware را عوض کنیم، آیا زیرساخت ما برای این مهاجرت آماده است؟»
و این دو سؤال تفاوت بسیار بزرگی دارند.

منبع: The Register
#VMware #Broadcom #IBM #Virtualization #PrivateCloud #Cloud #Infrastructure
☁️ ابرپلاس | Cloud & Infrastructure
@abrplusdocs

🧩 بخشی از اینترنت روی دوش چند نفر می‌چرخد!

وقتی می‌گوییم Open Source، معمولاً پروژه‌هایی مثل Linux و Kubernetes با هزاران مشارکت‌کننده به ذهن می‌آیند.

اما پشت بسیاری از نرم‌افزارها و Libraryهایی که هر روز در سرورها، Cloud، Containerها و نرم‌افزارهای سازمانی استفاده می‌کنیم، واقعیت دیگری وجود دارد:

گاهی یک پروژه مهم فقط توسط یک یا دو Maintainer اصلی نگهداری می‌شود.

حالا تصور کنید همان پروژه به‌صورت مستقیم یا غیرمستقیم Dependency صدها پروژه دیگر باشد.

یک آسیب‌پذیری امنیتی کشف می‌شود.

Issueها زیاد می‌شوند.

نسخه جدید Runtime منتشر می‌شود.

Maintainer هم دیگر زمان یا انگیزه ادامه پروژه را ندارد.

ناگهان چیزی که برای هزاران سازمان یک Dependency کوچک به نظر می‌رسید، تبدیل به یک Supply Chain Risk می‌شود.

اتفاق‌هایی مثل آسیب‌پذیری Log4Shell قبلاً نشان داده‌اند که یک Component به‌ظاهر کوچک تا چه اندازه می‌تواند در عمق زیرساخت‌های دنیا حضور داشته باشد.

مشکل Open Source بودن نیست.

مشکل زمانی شروع می‌شود که سازمان حتی نمی‌داند نرم‌افزارهایش به چه Componentهایی وابسته‌اند.

برای همین مفاهیمی مثل:

🔹 Software Bill of Materials یا SBOM
🔹 Dependency Management
🔹 Vulnerability Scanning
🔹 Software Supply Chain Security

دیگر فقط موضوع تیم Developer نیستند.

تیم‌های Cloud، DevOps و Security هم باید بدانند چه چیزی واقعاً داخل Stack سازمان در حال اجراست.

📌 شاید سؤال مهم دیگر این نباشد که:

«این نرم‌افزار Open Source هست یا نه؟»

بلکه باید بپرسیم:

چه کسانی آن را نگهداری می‌کنند، چقدر فعال است و اگر فردا رها شود، Plan B ما چیست؟

Open Source رایگان است؛ اما مدیریت ریسک آن رایگان نیست.

#OpenSource #CyberSecurity #DevOps #SupplyChain #CloudSecurity #Infrastructure

☁️ ابرپلاس | Cloud & Infrastructure
@abrplusdocs

#fun
#Security
@abrplusdocs

لایسنس مربوط به VDOM هم روی فایروال اعمال شد و با این فایل میتونید این قابلیت رو فعال کنید و در محیط لابراتوار استفاده کنید.

username:admin
password:123

🐧 ۷ دستور خطرناک لینوکس که می‌تونن سیستم رو نابود کنن!

این دستورات رو باید بشناسی، ولی *هیچ‌وقت روی سیستم اصلی بدون اینکه دقیق بدونی چه کاری انجام میدن اجراشون نکن!* ⚠️

━━━━━━━━━━━━━━━━━━

☠️ 1. حذف کل فایل‌سیستم
rm -rf / --no-preserve-root
کل فایل‌های سیستم رو از ریشه حذف می‌کنه و در حالت عادی عملاً راه برگشتی نداره.

━━━━━━━━━━━━━━━━━━

💣 2. Fork Bomb
:(){ :|:& };:
با ساختن تعداد بسیار زیادی پردازش، جدول پردازش‌ها رو پر می‌کنه و می‌تونه باعث هنگ یا از کار افتادن سیستم بشه.

━━━━━━━━━━━━━━━━━━

💾 3. نابودی اطلاعات دیسک
dd if=/dev/zero of=/dev/sda
روی دیسک صفر می‌نویسه و می‌تونه سیستم‌عامل، پارتیشن‌ها و اطلاعات رو از بین ببره.

━━━━━━━━━━━━━━━━━━

🗑️ 4. فرمت کردن پارتیشن
mkfs.ext4 /dev/sda1
پارتیشن مشخص‌شده رو با فایل‌سیستم جدید فرمت می‌کنه و اطلاعات قبلی اون پارتیشن از بین میره.

━━━━━━━━━━━━━━━━━━

⚠️ 5. نوشتن مستقیم روی دیسک
> /dev/sda
می‌تونه داده‌های مربوط به دیسک رو خراب کنه و باعث بشه سیستم دیگه بوت نشه.

━━━━━━━━━━━━━━━━━━

🔓 6. نابود کردن Permissionها
chmod -R 777 /
مجوزهای کل سیستم رو تغییر میده و می‌تونه باعث خراب شدن Permissionهای حیاتی، مشکل در
sudo
و سرویس‌هایی مثل
sshd
بشه.

━━━━━━━━━━━━━━━━━━

🕳️ 7. انتقال فایل‌ها به /dev/null
mv /* /dev/null
سعی می‌کنه محتویات مسیرهای سیستم رو به
/dev/null
منتقل کنه و می‌تونه باعث از بین رفتن فایل‌های مهم بشه.

━━━━━━━━━━━━━━━━━━

🚨 نکته مهم:

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

قبل از اجرای هر دستور با
sudo
یا دسترسی
root
، دقیقاً بدون که روی چه مسیری و چه دیسکی داری کار می‌کنی.

@abrplusdocs

🚨 یک CVE ده‌ساله دوباره برگشته؛ قدیمی بودن آسیب‌پذیری یعنی امن بودن نیست!

یک آسیب‌پذیری قدیمی درApache Struts با شناسه:
CVE-2016-3081

دوباره به دلیل مشاهده سوءاستفاده در حملات واقعی مورد توجه قرار گرفته و CISA آن را به فهرست Known Exploited Vulnerabilities (KEV) اضافه کرده است.

نکته جالب؟

این CVE مربوط به سال ۲۰۱۶ است!

یعنی آسیب‌پذیری تقریباً یک دهه است که شناخته شده، اما هنوز سیستم‌هایی در اینترنت وجود دارند که شرایط Exploit شدن آن را فراهم می‌کنند.

و این دقیقاً یکی از مشکلات محیط‌های Enterprise است:

ممکنه یک Application سال‌ها بدون مشکل کار کند و کسی هم جرئت Upgrade کردنش را نداشته باشد.

📌 نکته مهم برای تیم‌های Infrastructure و Security:

Vulnerability Management فقط دنبال کردن آسیب‌پذیری جدید نیست

اگر هنوز Applicationهایی مبتنی بر نسخه‌های قدیمی Apache Struts در سازمان دارید، شاید وقتش رسیده دوباره سراغ Inventory آنها بروید.

#CyberSecurity #ApacheStruts #CVE #CISA #VulnerabilityManagement #PatchManagement #Infrastructure

☁️ ابرپلاس | Cloud & Infrastructure
@abrplusdocs

🚨 هشدار امنیتی؛ مهاجمان فقط دنبال یک CVE نیستند

سازمان های NSA، FBI و شرکای امنیتی بین‌المللی درباره فعالیت مهاجمان سایبری مرتبط با دولت چین هشدار داده‌اند.

نکته مهم گزارش، روش حمله آنهاست.

مهاجمان از ترکیبی از:

🔹 Automated Scanning
🔹 Botnetهای بزرگ
🔹 Exploitation دستی
🔹 ابزارهای مدیریتی موجود در شبکه
🔹 زیرساخت VPN
🔹 و تکنیک‌های Living-off-the-Land

برای شناسایی و نفوذ به شبکه سازمان‌ها استفاده می‌کنند.

طبق گزارش، شرکت چینیIntegrity Technology Group در فراهم‌کردن ابزار و زیرساخت برای بخشی از این فعالیت‌ها نقش داشته و TTPهای مشاهده‌شده با گروه‌هایی که با نام‌هایی مثل:

Flax Typhoon

Ethereal Panda

Red Juliett

شناخته می‌شوند، هم‌خوانی دارد.

اهداف هم فقط شرکت‌های فناوری نیستند.

بخش‌هایی از:

Critical Manufacturing
Healthcare
Government
Information Technology

در میان اهداف گزارش‌شده قرار دارند.

اما برای یک مدیر زیرساخت، مهم‌ترین قسمت این گزارش اسم گروه هکری نیست.

پیام اصلی اینه:

Internet-facing Infrastructure همچنان یکی از مهم‌ترین نقاط ورود مهاجمان است.
Firewall، VPN Gateway، Router، Load Balancer و سایر Edge Deviceها اگر Patch نشده یا End-of-Support باشند، می‌توانند همان نقطه‌ای باشند که مهاجم برای ورود به شبکه منتظرش بوده.

📌 دفاع فقط یعنی «Firewall داریم» نیست.

Asset Inventory، Patch Management، MFA، Log Monitoring، محدودکردن Management Interfaceها و بررسی رفتارهای غیرعادی باید کنار هم قرار بگیرند.

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

منبع: NSA / FBI Joint Cybersecurity Advisory

#CyberSecurity #CISA #NSA #FBI #NetworkSecurity #SOC #InfrastructureSecurity

☁️ ابرپلاس | Cloud & Infrastructure
@abrplusdocs