شرکت Broadcom از راهکار امنیتی جدیدی با نام VMware HyperArmor رونمایی کرده که تمرکزش مستقیماً روی یکی از حساس‌ترین قسمت‌های زیرساخت مجازی است:
خود Hypervisor
ما معمولاً برای امن‌سازی زیرساخت VMware سراغ Firewall، Segmentation، محدودسازی Management Network، Hardening ماشین‌های مجازی و کنترل دسترسی می‌رویم.
اما یک سؤال مهم باقی می‌ماند:
اگر خود ESX آسیب‌پذیر باشد چه؟
یکی از چالش‌های همیشگی تیم‌های زیرساخت، فاصله زمانی بین شناسایی یک Vulnerability و نصب Patch رسمی است.
فرض کنید یک آسیب‌پذیری جدی برای ESX منتشر شده.
پچ هم وجود دارد، اما نصب آن ممکن است نیازمند Maintenance Window، انتقال Workloadها، ورود Host به Maintenance Mode، Reboot و انجام تست‌های بعد از Upgrade باشد.
در یک محیط بزرگ، این فرآیند ممکن است فوراً قابل انجام نباشد.
در نتیجه یک بازه خطرناک ایجاد می‌شود:
Vulnerability Disclosed
⬇️
Exposure Window
⬇️
Official Patch Applied
ایده HyperArmor این است که برای همین فاصله زمانی، یک لایه دفاعی اضافی در سطح Hypervisor ایجاد کند.
🔹 قابلیت اول: Virtual Patching
یکی از جذاب‌ترین بخش‌های HyperArmor همین قسمت است.
به‌جای اینکه برای کاهش ریسک حتماً منتظر Patch کامل Host بمانیم، این لایه می‌تواند تلاش برای سوءاستفاده از برخی آسیب‌پذیری‌ها را قبل از رسیدن به نقطه Exploit مسدود کند.
مزیت عملیاتی مهم این رویکرد چیست؟
کاهش Exposure Window بدون اینکه الزاماً همان لحظه مجبور به ایجاد اختلال در Workloadهای در حال اجرا باشیم.
اما یک نکته خیلی مهم:
⚠️ Virtual Patching جایگزین Patch رسمی نیست.
باید به آن به چشم یک Compensating Control نگاه کنیم؛ یعنی لایه‌ای موقت یا تکمیلی برای کاهش ریسک تا زمانی که Patch اصلی طبق فرآیند Change Management نصب شود.
🔹 قابلیت دوم: کنترل اجرای File و Script
سناریوی دیگری را تصور کنید.
مهاجم به هر روشی توانسته به سطح مدیریتی Host نزدیک شود و حالا می‌خواهد یک Binary یا Script غیرمجاز اجرا کند.
HyperArmor می‌تواند یک Security Baseline در سطح ESX ایجاد کند تا مشخص شود چه فایل‌ها و Scriptهایی اجازه اجرا دارند.
یعنی به‌جای اینکه فقط بپرسیم:
«چه کسی اجازه Login دارد؟»
یک سؤال دیگر هم اضافه می‌کنیم:
«بعد از Login چه چیزی اجازه اجرا دارد؟»
این موضوع در کاهش ریسک اجرای Payloadهای مخرب اهمیت زیادی دارد.
نکته جالب‌تر اینکه این کنترل در سطح Hypervisor انجام می‌شود و برای آن نیازی به نصب Agent داخل تک‌تک Guest VMها نیست.
🔹 قابلیت سوم: MFA برای دسترسی SSH
فرض کنیم Credential یکی از Administratorهای زیرساخت افشا شده است.
اگر Username و Password تنها سد دفاعی SSH باشند، مهاجم ممکن است بتواند مستقیماً وارد Command Line شود.
HyperArmor امکان اضافه‌کردن Multi-Factor Authentication به مسیر دسترسی SSH در سطح ESX را فراهم می‌کند.
در نتیجه داشتن Credential به‌تنهایی برای ورود کافی نیست و یک عامل احراز هویت دیگر هم موردنیاز خواهد بود.
این قابلیت مخصوصاً برای Management Plane اهمیت زیادی دارد؛ چون دسترسی مدیریتی به Hypervisor با دسترسی به یک Server معمولی قابل مقایسه نیست.
📌 اما HyperArmor دقیقاً کجای معماری امنیت VMware قرار می‌گیرد؟
اینجا مفهوم Defense in Depth مهم می‌شود.
راهکارهایی مثل VMware vDefend بیشتر روی Network Security، Segmentation و کنترل ترافیک تمرکز دارند.
در مقابل، HyperArmor یک لایه حفاظتی نزدیک‌تر به خود Hypervisor اضافه می‌کند.
در نتیجه معماری دفاعی می‌تواند چیزی شبیه این باشد:
Workload Security
⬇️
Network Security / vDefend
⬇️
Hypervisor Security / HyperArmor
⬇️
Hardware & Management Plane
و این دقیقاً نکته مهم این خبر برای تیم‌های زیرساخت است.
امنیت Virtualization فقط یعنی:
❌ Firewall داشته باشیم
❌ Management VLAN را جدا کنیم
❌ VMها را Hardening کنیم
❌ دسترسی vCenter را محدود کنیم
این‌ها لازم‌اند، اما کافی نیستند.
خود Hypervisor هم یک Security Boundary بسیار مهم است.
چون اگر این لایه Compromise شود، دیگر درباره امنیت یک VM صحبت نمی‌کنیم؛ ممکن است چندین Workload روی همان Host تحت تأثیر قرار بگیرند.
به‌نظرم پیام مهم HyperArmor همین تغییر نگاه است:
Hypervisor دیگر فقط بستری برای اجرای VM نیست؛ خودش باید به‌عنوان یک لایه مستقل امنیتی محافظت و پایش شود.
و البته حتی با چنین مکانیزم‌هایی، اصول اصلی همچنان سر جای خودشان هستند:

Patch Management، Hardening، MFA، Least Privilege، Segmentation، Logging و محدودسازی Management Plane.
HyperArmor قرار نیست این کنترل‌ها را حذف کند؛ قرار است یک لایه دیگر به Defense in Depth اضافه کند.
#VMware
#Broadcom
#HyperArmor
#Virtualization
#CyberSecurity
#InfrastructureSecurity
#ESX
#vSphere
#CloudSecurity
☁️ ابرپلاس | Cloud & Infrastructure

💾 یک تغییر جالب در Ceph؛ وقتی RocksDB از فضای سریع خودش بیرون می‌زند چه اتفاقی می‌افتد؟

یکی از موضوعاتی که در Performance کلاسترهای Ceph مبتنی بر BlueStore اهمیت زیادی دارد، محل قرارگیری Metadata و RocksDB است.

برای درک خبر جدید، اول باید معماری را خیلی کوتاه مرور کنیم.

در BlueStore هر OSD برای نگهداری Metadata خودش از RocksDB استفاده می‌کند.

در طراحی‌های Performance-oriented معمولاً Deviceهای OSD را از هم تفکیک می‌کنیم.

مثلاً:

block → HDD

block.db → NVMe / SSD

ایده مشخص است.

داده اصلی روی HDD قرار می‌گیرد، اما RocksDB و Metadataهایی که دسترسی زیادی دارند روی Device سریع‌تر قرار می‌گیرند.

اما مشکل از کجا شروع می‌شود؟

فرض کنید برای block.db مقدار ۳۰ گیگابایت NVMe در نظر گرفته‌ایم.

با رشد RocksDB ممکن است این فضا دیگر کافی نباشد.

اینجاست که اتفاقی به نام:
BlueFS Spillover

رخ می‌دهد.

یعنی BlueFS مجبور می‌شود بخشی از داده RocksDB را از DB Device سریع خارج کرده و روی Device اصلی OSD قرار دهد.

در یک OSD مبتنی بر HDD یعنی ممکن است بخشی از Metadata حساس به Performance از:

NVMe

به:

HDD

منتقل شود.

و نتیجه می‌تواند افزایش Latency و افت Performance باشد.

🔍 چطور Spillover را بررسی کنیم؟

برای مشاهده وضعیت BlueFS یک OSD می‌توان از ابزارهای مدیریتی Ceph استفاده کرد و در Troubleshooting عمیق‌تر سراغ Admin Socket همان OSD رفت.

مثلاً:

ceph daemon osd.10 bluefs stats

همچنین وضعیت کلی OSDها را بررسی می‌کنیم:

ceph osd df

و:

ceph osd tree

در کنار آن باید وضعیت Performance خود OSDها را هم ببینیم:

ceph osd perf

اگر Warning مربوط به BlueFS Spillover مشاهده شود، فقط پاک‌کردن Warning مشکل اصلی را حل نمی‌کند.

باید بفهمیم چرا DB Device دیگر فضای کافی ندارد.

🔹 اندازه block.db مناسب نبوده؟

🔹 RocksDB بیش از پیش‌بینی رشد کرده؟

🔹 طراحی Device Class مناسب نیست؟

🔹 تعداد OSDهای قرارگرفته روی NVMe درست محاسبه نشده؟

🔹 Workload کلاستر تغییر کرده؟

اینجا تغییر جدید Ceph جالب می‌شود.

در نسخه‌های جدید IBM Storage Ceph قابلیتی تحت عنوان:

BlueFS Spillover Cleaner

معرفی شده است.

هدف این مکانیزم، مدیریت بهتر داده‌های RocksDB در شرایط Spillover است.

به‌جای اینکه وضعیت Spillover را صرفاً به‌عنوان یک حالت باقی‌مانده در OSD بپذیریم، Cleaner تلاش می‌کند Placement داده‌های BlueFS را بهتر مدیریت کند تا فایل‌هایی که ارزش بیشتری برای قرارگیری روی Storage سریع دارند، دوباره به DB Device مناسب منتقل شوند.

📌 چرا این موضوع مهم است؟

چون در Ceph فقط داشتن NVMe کنار HDD تضمین نمی‌کند Metadata همیشه روی سریع‌ترین Storage باقی بماند.

Sizing اشتباه block.db می‌تواند بعداً خودش را به شکل:

Higher Latency

Slow OSD

RocksDB Pressure

BlueFS Spillover

نشان دهد.

پس هنگام طراحی OSD فقط این سؤال را نپرسیم:

«چند ترابایت Storage نیاز داریم؟»

باید بپرسیم:

برای DB/WAL هر OSD چقدر فضای سریع نیاز داریم و اگر RocksDB رشد کرد چه اتفاقی می‌افتد؟

این دقیقاً تفاوت بین صرفاً راه‌اندازی یک Ceph Cluster و طراحی درست آن برای Production است.

#Ceph
#BlueStore
#BlueFS
#RocksDB
#Storage
#OpenStack
#Linux
#Troubleshooting

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

🛠️ اگر برای Troubleshooting لینوکس فقط journalctl -xe می‌زنید، بخش بزرگی از قدرت Journal را استفاده نمی‌کنید!

در سیستم‌های مبتنی بر systemd، یکی از مهم‌ترین ابزارهای عیب‌یابی:

journalctl

است.

بیایید چند حالت کاربردی آن را ببینیم.

🔹 لاگ‌های یک سرویس خاص

فرض کنیم Nginx مشکل دارد:

journalctl -u nginx

گزینه -u یعنی فقط Logهای Unit مشخص‌شده نمایش داده شوند.

اگر فقط ۵۰ خط آخر را بخواهیم:

journalctl -u nginx -n 50

و اگر بخواهیم Logها را زنده ببینیم:

journalctl -u nginx -f

این حالت تقریباً مشابه:

tail -f

عمل می‌کند.

حالا سرویس را Restart کنید:

systemctl restart nginx

و همزمان Logها را ببینید.

---

🔹 فقط خطاهای مهم را ببینیم

یکی از قابلیت‌های خیلی کاربردی، فیلتر بر اساس Priority است:

journalctl -p err

سطوح مهم Log عبارت‌اند از:

0 → emerg

1 → alert

2 → crit

3 → err

4 → warning

5 → notice

6 → info

7 → debug

مثلاً:

journalctl -p warning

پیام‌های Warning و موارد شدیدتر را نمایش می‌دهد.

برای بررسی سریع مشکلات جدی:

journalctl -p err..alert

---

🔹 لاگ‌های یک بازه زمانی مشخص

مثلاً مشکلات یک ساعت اخیر:

journalctl --since "1 hour ago"

یا:

journalctl --since "2026-10-17 07:00:00"

تا:

journalctl --since "2026-10-17 07:00:00" --until "2026-10-17 08:00:00"

این قابلیت زمانی خیلی مهم می‌شود که کاربر می‌گوید:

«سرویس حدود ساعت ۷:۳۰ قطع شد.»

به‌جای خواندن هزاران Log، همان بازه را بررسی می‌کنیم.

---

🔹 فقط Kernel Logها

journalctl -k

این دستور برای Troubleshooting مواردی مثل:

Disk Error

NIC Problem

Driver

Memory

Kernel

Hardware

خیلی کاربردی است.

مثلاً فقط Warningهای Kernel:

journalctl -k -p warning

---

🔹 لاگ‌های Boot فعلی

journalctl -b

اما قابلیت جذاب‌تر:

journalctl --list-boots

مثلاً:

0

یعنی Boot فعلی.

-1

یعنی Boot قبلی.

-2

یعنی دو Boot قبل.

پس اگر سرور Crash کرده و بعد Reboot شده، فقط Logهای فعلی را بررسی نکنید.

بروید سراغ Boot قبلی:

journalctl -b -1

این دستور در Root Cause Analysis واقعاً ارزشمند است.

مثلاً:

journalctl -b -1 -p err

یعنی:

خطاهای Boot قبلی را نشان بده.

---

🔹 لاگ یک Process مشخص

اگر PID را بدانیم:

journalctl _PID=1842

یا براساس Executable:

journalctl /usr/sbin/sshd

Journal فقط یک فایل متنی ساده نیست؛ Metadata زیادی همراه هر Event نگه می‌دارد و می‌توانیم براساس آنها Query بزنیم.

---

🔹 خروجی جدیدترین Logها اول نمایش داده شود

journalctl -r

گزینه -r یعنی Reverse.

وقتی دنبال آخرین اتفاقات هستیم خیلی کاربردی است.

---

📌 حالا یک سناریوی واقعی:

کاربر می‌گوید:

«Nginx ساعت ۶ صبح Down شده ولی الان دوباره بالا آمده.»

به‌جای این:

journalctl

می‌توانیم دقیق‌تر برویم سراغ:

journalctl -u nginx --since "05:50" --until "06:10"

بعد خطاهای همان بازه:

journalctl -u nginx --since "05:50" --until "06:10" -p err

اگر احتمال می‌دهیم مشکل از Kernel یا OOM بوده:

journalctl -k --since "05:50" --until "06:10"

و برای بررسی OOM:

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

این یعنی Troubleshooting هدفمند.

نه اینکه:

journalctl

را بزنیم و بین ده‌ها هزار خط دنبال مشکل بگردیم. 😄

📌 یک Command ارزشمند برای جعبه‌ابزار Linux Admin:

journalctl -b -1 -p err

اگر سروری Crash یا Reboot شده، این یکی از اولین دستورهایی است که ارزش بررسی دارد.

در Troubleshooting حرفه‌ای سؤال فقط این نیست:

«چه خطایی رخ داده؟»

باید بدانیم:

چه زمانی، در کدام Service، در کدام Boot و با چه Priority رخ داده است؟

#Linux
#LPIC2
#Journalctl
#Systemd
#LinuxCommands
#Troubleshooting
#SysAdmin

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

@abrplusdocs

🥶 حمله سایبری به سوپرمارکت‌های فرانسه؛ هکرها دمای یخچال‌ها را تا 50 درجه بالا بردند!

‏🛒 هکرها به سامانه‌های تبرید صدها سوپرمارکت فرانسوی حمله کردند و با دستکاری تنظیمات یخچال‌ها و فریزرها، باعث فساد مواد غذایی شدند. فقط در فروشگاه‌های زنجیره‌ای Intermarché حدود ۱۵۰ شعبه تحت تأثیر قرار گرفتند.

‏🌡 گزارش‌ها از افزایش دما تا ۵۰ درجه سانتی‌گراد حکایت دارند! ظاهراً مهاجمان با فعال‌کردن چرخه یخ‌زدایی و جلوگیری از بازگشت عادی دستگاه‌ها به حالت سرمایش، عملکرد سامانه‌ها را مختل کرده‌اند.

‏🔓 اما اگر شما هم از خودتان در مورد مسیر نفوذ به این سیستم‌ها می‌پرسید باید بگوییم که ظاهراً پای تجهیزات قدیمی و به‌روزرسانی‌نشده شرکت Danfoss در میان است؛ هرچند مسیر دقیق نفوذ هنوز مشخص نشده. اما فروشگاه‌های زنجیره‌ای دیگری از جمله Carrefour و Monoprix نیز تحت تأثیر قرار گرفته‌اند.

‏⚠️ این حمله نشان می‌دهد هک فقط به سرقت اطلاعات یا قفل‌کردن فایل‌ها ختم نمی‌شود؛ نفوذ به تجهیزات صنعتی متصل به شبکه می‌تواند به فساد مواد غذایی و خسارت واقعی منجر شود.

@abrplusdocs

⭕️جالبه که OpenCode خبر داد که هک شدند !

لطفاً کلیدهای API خود را فوراً تغییر دهید.
تو پیامی که منتشر کردن گفتن ما به اونایی که هک شدن ایمیل زدیم اگه بهتون ایمیل نزدیم لازم نیست کاری بکنید.

https://www.notebookcheck.net/OpenCode-hacked-users-urged-to-revoke-their-API-keys.1426957.0.html

#Opencode #ai
@abrplusdocs

💡 دیسک پر شده؛ چی داره فضا رو میگیره؟

قبل از اینکه شروع به پاک‌کردن فایل‌ها کنی، اول مسیرهای حجیم رو پیدا کن:

du -xhd1 / | sort -h

🔹 گزینه -x فقط همان Filesystem را بررسی می‌کند
🔹 گزینه -h حجم‌ها را خوانا نمایش می‌دهد
🔹 گزینه -d1 فقط یک سطح پایین‌تر را بررسی می‌کند

مثلاً اگر /var مشکوک بود:

du -xhd1 /var | sort -h

برای پیدا کردن ۱۰ فایل حجیم:

find /var -xdev -type f -printf '%s %p\n' | sort -nr | head -10

📌 قبل از rm کردن فایل‌های بزرگ، حتماً بررسی کن فایل متعلق به چه Serviceای است؛ مخصوصاً Log و Databaseها.

گاهی پاک‌کردن فایل، مشکل Disk Space را حل می‌کند؛
گاهی هم یک مشکل بزرگ‌تر می‌سازد!

#Linux #LPIC #Troubleshooting #SysAdmin

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

🔍 یک پورت بازه؛ ولی نمی‌دونی کدوم سرویس بازش کرده؟
مثلاً می‌بینی پورت 8080 روی سرور بازه و می‌خوای بفهمی دقیقاً چه Processای پشتشه.
این دستور رو بزن:
ss -lntp | grep ':8080'
مثلاً خروجی می‌بینی:
users:(("java",pid=2841,fd=42))
حالا اطلاعات Process رو دربیار:
ps -fp 2841
و ببین فایل اجرایی واقعی از کجا اجرا شده:
readlink -f /proc/2841/exe
حتی می‌تونی Command کامل اجرای Process رو ببینی:
tr '\0' ' ' < /proc/2841/cmdline
📌 این چند دستور مخصوصاً وقتی روی یک سرور قدیمی با ده‌ها سرویس روبه‌رو می‌شی و هیچ‌کس نمی‌دونه «این پورت مال چیه؟» خیلی به‌درد می‌خوره 😄

#Linux
#LPIC
#Troubleshooting
#LinuxCommands
☁️ ابرپلاس | Cloud & Infrastructure
@abrplusdocs

از هوش مصنوعی پرسیدن؛

"چرا اکثر ما انسان‌ها احساس خوشبختی نمی‌کنیم؟"


+ جوابی که داد عجیب و جالب بود...

@abrplusdocs

طبق گزارش های منتشر شده هوش مصنوعی Chat gpt برای ایرانی ها به صورت کامل تحریم و فیلتر شد.


@abrplusdocs

🖥️ دستورات مشابه در Windows و Linux

اگه با Windows و Linux کار می‌کنی، خیلی از کارهایی که انجام میدی توی هر دو سیستم یه مفهوم دارن، فقط اسم دستورشون فرق می‌کنه. اینا یه سری از کاربردی‌ترین دستوراته که ارزش داره بلد باشی 👇
📁 مدیریت فایل و پوشه
نمایش فایل‌ها و پوشه‌ها
Windows → dir
Linux   → ls
ورود به یک پوشه
Windows → cd folder
Linux   → cd folder
برگشت به پوشه قبلی
Windows → cd ..
Linux   → cd ..
تغییر درایو در ویندوز
Windows → C:
Linux   → cd /mnt/c
نمایش محتوای فایل متنی
Windows → type file.txt
Linux   → cat file.txt
کپی کردن فایل
Windows → copy file.txt file2.txt
Linux   → cp file.txt file2.txt
جابجایی یا تغییر نام فایل
Windows → move file.txt new.txt
Linux   → mv file.txt new.txt
حذف فایل
Windows → del file.txt
Linux   → rm file.txt
ساخت پوشه
Windows → mkdir new_folder
Linux   → mkdir new_folder
حذف پوشه خالی
Windows → rmdir folder
Linux   → rmdir folder
نمایش ساختار پوشه‌ها
Windows → tree
Linux   → tree
🔎 جستجو و بررسی سیستم
جستجوی متن داخل فایل‌ها
Windows → find "text" file.txt
Linux   → grep "text" file.txt
نمایش آدرس IP
Windows → ipconfig
Linux   → ip addr
نمایش پردازش‌های در حال اجرا
Windows → tasklist
Linux   → ps aux
بستن یک پردازش
Windows → taskkill /PID <PID> /F
Linux   → kill -9 <PID>
نمایش کاربر فعلی
Windows → whoami
Linux   → whoami
🌐 دستورات شبکه
تست اتصال به یک مقصد
Windows → ping google.com
Linux   → ping google.com
نمایش جدول مسیریابی
Windows → route print
Linux   → ip route
نمایش اتصال‌های شبکه
Windows → netstat -ano
Linux   → ss -tuln
بررسی DNS
Windows → nslookup google.com
Linux   → nslookup google.com
بررسی مسیر رسیدن به مقصد
Windows → tracert google.com
Linux   → traceroute google.com
💽 دیسک و سیستم
نمایش فضای دیسک
Windows → wmic logicaldisk get size,freespace,caption
Linux   → df -h
اطلاعات سیستم
Windows → systeminfo
Linux   → uname -a
خاموش کردن سیستم
Windows → shutdown /s /t 0
Linux   → shutdown -h now
بررسی فایل‌های سیستمی ویندوز
Windows → sfc /scannow
Linux   → fsck
📦 مدیریت پکیج
در Windows معمولاً می‌تونی از winget استفاده کنی:
Windows → winget search <package>
Windows → winget install <package>
Windows → winget upgrade
در Debian/Ubuntu:
Linux → sudo apt update
Linux → sudo apt install <package>
Linux → sudo apt upgrade
چند نکته مهم
🔹 Windows
بیشتر با CMD / PowerShell سر و کار داره.

🔹 Linux بیشتر با Bash / Shell
کار می‌کنه.
🔹 بعضی دستورات اسم متفاوت دارن ولی کاری که انجام میدن تقریباً یکیه.
🔹 حواست باشه دستورها همیشه ۱۰۰٪ معادل هم نیستن؛ بعضی‌ها پارامترها و رفتار متفاوتی دارن.
🔹 توی Linux حروف بزرگ و کوچک مهمه؛ مثلاً File.txt با file.txt یکی نیست.
🔹 اگه شبکه کار می‌کنی، حداقل اینا رو باید خوب بلد باشی:
ping ، ip ، ipconfig ، traceroute ، tracert ، nslookup ، netstat ، ss و route
🚀 دو سیستم متفاوتن، ولی منطق کار با خط فرمان تقریباً یکیه.

@abrplusdocs

🔺برای حمله به زیرساخت ، همیشه Zero-Day لازم نیست.

گاهی یک Credential معتبر خیلی باارزش‌تره.

فرض کنیم مهاجم Username و Password یک Administrator رو به دست آورده.

اگه همون Account به چند بخش دسترسی داشته باشه:

vCenter

Backup

Active Directory

Storage

Monitoring

Server Management

دیگه مهاجم لازم نیست برای هر سیستم دنبال Vulnerability جدید بگرده.

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

اینجا فقط Password Policy مسئله نیست.

باید ببینیم یک Credential در صورت افشا شدن تا کجای زیرساخت قدرت مانور دادن داره

مثلاً آیا اکانتی که vCenter رو مدیریت می‌کنه واقعاً باید به Backup Server هم دسترسی Administrative داشته باشه؟

آیا Administrator با همون Account روزمره خودش وارد Management Plane میشه؟

آیا دسترسی‌های اضطراری و Privileged Accountها جدا شدن؟

آیا ورود Administrator به یک سیستم حساس از یک Workstation معمولی امکان‌پذیره؟

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

اگر قوی‌ترین اکانت ما دست مهاجم افتاد، چه چیزی هنوز جلوی اون رو می‌گیره؟

اگر جواب فقط «Password قوی» باشه، دفاعمون یک لایه بیشتر نداره.

اما اگه بعدش:

MFA

PAM

Network Segmentation

Separate Admin Accounts

Privileged Workstation

Session Logging

Least Privilege

وجود داشته باشه، سرقت یک Credential الزاماً به معنی در اختیار گرفتن کل زیرساخت نیست.

در امنیت، هدف این نیست که مطمئن باشیم هیچ Credentialی هیچ‌وقت لو نمی‌ره هدف اینه که لو رفتن یک Credential، کلید همه درها نباشه.

#CyberSecurity
#Banking
#InfrastructureSecurity
#PAM
#IdentitySecurity
#ZeroTrust
#SysAdmin

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

دوستان بخاطر لو رفتن کلیدهای خصوصی 8 گواهی eMudhra اکثر مرورگر ها ناامن شدن

لینک زیر رو باز کنید و باید همه موارد تیک سبز بخوره
emudhra.we-have-a-problem.com

@abrplusdocs

🔺 یه مشکل امنیتی خیلی حاد (بالاترین رده امتیازدهی مشکلات امنیتی که می شه ۱۰) وجود داره روی گیت لب
اگر گیت لبی دارین که خودتون نصب کردین یا مدیریت می کنین، سریعا آپدیت کنین.

اگر هم نمی تونین در لحظه آپدیت کنین، می تونین فعلا گیت لب رو بیارین پایین تا سر فرصت برین سراغ آپگرید:


sudo gitlab-ctl stop

https://thehackernews.com/2026/10/critical-gitlab-flaw-cvss-100-could.html

#امنیت

🐧 لازم نیست برای دیدن تغییرات، یه Command رو پشت‌سرهم اجرا کنیم.

در Linux دستور watch می‌تونه هر Command دیگه‌ای رو به‌صورت دوره‌ای اجرا کنه.

مثلاً می‌خوایم هر ۲ ثانیه وضعیت RAM رو ببینیم:

watch free -h

یا فضای Disk:

watch df -h

وضعیت Connectionهای یک Port:

watch 'ss -ant | grep :443'

اگه بخوایم تغییرات نسبت به اجرای قبلی Highlight بشن:

watch -d 'ss -s'

فاصله اجرا رو هم می‌تونیم تغییر بدیم:

watch -n 1 'ip -s link show eth0'

یعنی هر یک ثانیه Counterهای Interface رو ببینیم.

چند Option کاربردی:

-n → فاصله بین اجراها
-d → مشخص کردن تغییرات
-t → حذف Header
-g → وقتی خروجی تغییر کرد، خارج شو

مثلاً:

watch -g 'systemctl is-active nginx'

📌دستور watch ابزار پیچیده‌ای نیست؛ ولی موقع Troubleshooting خیلی وقت‌ها از باز کردن چند Dashboard سریع‌تر جوابمون رو میده.

یه Terminal باز می‌کنیم، Command موردنظر رو زیر نظر می‌گیریم و همزمان تغییرمون رو روی سیستم انجام می‌دیم.

#Linux #LPIC #LinuxCommands #Troubleshooting #SysAdmin

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

@abrplusdocs

شاهکار باورنکردنی هوش‌مصنوعی Claude و تولید پادزهر سم عقرب!

پژوهشگرا تونستن با استفاده از هوش‌مصنوعی Claude تو کمتر از 3 روز بیشتر از 318 هزار طرح پروتئین برای مقابله با زهر عقرب تولید کنن که از این تعداد، 17 پروتئین به صورت موفق تونستن زهر سم عقرب رو مهار کنن. البته تولید پادزهر نهایی هنوز به تست این 17 نمونه روی موجودات زنده نیاز داره.

نکته اینجاست که قبلا برای تولید پادزهرها باید یک نمونه آزمایشگاهی رو روی موجودات زنده مثل اسب آزمایش میکردن و ماه‌ها منتظر نتیجه نهایی میموندن اما با کمک هوش مصنوعی، تونستن 318 هزار نمونه رو طی 64 ساعت بسازن و بررسی کنن و 17 نمونه قطعی نهایی برای تست داشته باشن.



@abrplusdocs

.
🎯 برای آنان که امنیت را مدیریت می‌کنند!

🔐 در دنیایی که تهدیدها بی‌وقفه تکامل می‌یابند، مدیریت امنیت چیزی فراتر از ابزارهاست؛ این یک هنر است. هنری که نیازمند نگاه عمیق، دانش به‌روز و تصمیم‌های دقیق و به‌موقع است.

@abrplusdocs

اگه از ابزارهائی مثل Anydesk و نرم افزارهای مشابه خسته شده اید، یک ابزار حرفه ای، رایگان، متن باز، مالتی پلت فرم ( برای ویندوز، مک، اندروید و حتی FreeBSD ) وجود داره به نام MeshCentral
دسک تاپ کاربرانتون رو می تونید فقط با یک مرورگر ببینید و کنترل کنید و نیاز به id هم نداره.
از راه دور هر نوع مدیریت فایلی انجام بدین.
تکست چت و ویدئو چت بهتون میده.
از سرورش بعنوان فایل سرور میشه استفاده کرد.
وضعیت ها رو لاگ میگیره، سیستمهاتون رو توی LAN یا هر جای اینترنت به شکل Real Time نشون میده و خود سرورش هم Self Hosted هستش.
این سایتش:
https://meshcentral.com/
@abrplusdocs

میزان شناسایی آسیب پذیری بعد از AI میتونید ببینید
@abrplusdocs

⏺مراکز داده دستگاه‌های دولتی ملزم به اتصال به ابر یکپارچه دولت هستند

🔹 محمدمحسن صدر، رئیس سازمان فناوری اطلاعات ایران، از ارزیابی مراکز داده تمامی دستگاه‌های دولتی خبر داد و اعلام کرد: نتایج این ارزیابی طی هفته‌های آینده به دستگاه‌ها ابلاغ خواهد شد.

🔹 به گفته صدر، دستگاه‌ها براساس نتایج ارزیابی موظف خواهند شد مراکز داده خود را منتقل کنند، زیرساخت‌هایشان را مطابق استانداردها ارتقا دهند یا در صورت برخورداری از استانداردهای لازم، به زیرساخت ابری یکپارچه کشور متصل شوند.

🔹 او با اشاره به ایجاد یک زیرساخت ابری یکپارچه و توزیع‌شده در سراسر کشور گفت سازمان فناوری اطلاعات طی دو سال گذشته به تعداد زیادی از دستگاه‌های دولتی خدمات ابری ارائه کرده است.

#خبر

@abrplusdocs