Security Monitoring with Wazuh.pdf
7.5 MB
Title: Security Monitoring with Wazuh
Edition: First
Year: 2024
Author(s): Rajneesh Gupta
Publisher: Packt
Language: English
@abrplusdocs
Edition: First
Year: 2024
Author(s): Rajneesh Gupta
Publisher: Packt
Language: English
@abrplusdocs
❤1
بزنامه WinRARرو خیلیا بهش میخندن و میگن بدون پرداخت هم میشه بعد از تموم شدن دوره 40 روزه رایگان ازش استفاده کرد
ولی من واقعا اون کسی که همچین کاری رو عمدا انجام داده رو واقعا تحسین میکنم چون فهمیده هیچکس حاضر نیست بابت WinRAR پول بده استراتژی رو گذاشته روی هرکی داد هرکی نداد و داره یه درامدی هم کسب میکنه ولی اگر پولی میبود هیچ وقت معروف نمیشد و شکست میخورد الان داره هم از مزیت رایگان بودنش استفاده میکنه هم الان یه عده محدودی دارن پرداخت میکنن در واقع توسعه دهنده هاش سود شرکت رو به نحوه خودشون ماکسیمایز کردن درصورتی که اگه کاملا رایگان بود هیچ سودی نداشتن.
@abrplusdocs
ولی من واقعا اون کسی که همچین کاری رو عمدا انجام داده رو واقعا تحسین میکنم چون فهمیده هیچکس حاضر نیست بابت WinRAR پول بده استراتژی رو گذاشته روی هرکی داد هرکی نداد و داره یه درامدی هم کسب میکنه ولی اگر پولی میبود هیچ وقت معروف نمیشد و شکست میخورد الان داره هم از مزیت رایگان بودنش استفاده میکنه هم الان یه عده محدودی دارن پرداخت میکنن در واقع توسعه دهنده هاش سود شرکت رو به نحوه خودشون ماکسیمایز کردن درصورتی که اگه کاملا رایگان بود هیچ سودی نداشتن.
@abrplusdocs
❤1
ابرپلاس | Cloud & Security🔵
Photo
🔺کدوم دیسک برای کدوم VM بهتره؟Thin یا Thick
یکی از تصمیمهای مهم موقع ساخت VM در VMware انتخاب نوع Virtual Disk هست.
دو انتخاب رایج:
Thin Provision
Thick Provision
تفاوت اصلیشون چیه؟
🔹 Thin Provision
اگر یک دیسک 500 GB بسازی، از همون ابتدا کل 500 GB روی Datastore اشغال نمیشه.
فضا بهمرور و با افزایش اطلاعات VM مصرف میشه.
مزیت اصلی:
✅ استفاده بهینهتر از Storage
✅ مناسب برای محیطهایی که تعداد VM زیاد هست
✅ امکان Overprovisioning
اما باید حواست به فضای آزاد Datastore باشه.
🔹 Thick Provision
اگر یک دیسک 500 GB بسازی، فضا از ابتدا روی Datastore رزرو میشه.
مزیتش اینه که ظرفیت موردنیاز VM از ابتدا مشخص و رزرو شده.
❓خب کدوم VM رو روی کدوم بذاریم؟
اینجا جواب کاملاً به Workload و Storage بستگی داره، اما بهصورت کلی:
🟢 Thin
Web Server
Application Server
Development / Test VM
VDI
VMهایی که رشد Storage قابل پیشبینی دارن
🔵 Thick
دیتاهای حساس و پرترافیک
High I/O Workload
ماشین هایی که حساس به Performance
محیطهایی که نمیخوای ریسک Datastore Overcommit داشته باشی
اما یک نکته مهم:
اینطور نیست که Thick همیشه سریعتر از Thin باشه.
در بسیاری از محیطها، مخصوصاً با Storageهای مدرن، تفاوت Performance میتونه خیلی کمتر از چیزی باشه که تصور میکنیم.
🔄بنابراین فقط به خاطر اینکه یک VM مهمه، سریع سراغ Thick نرو.
قبل از تصمیمگیری، نوع Storage، نرخ رشد اطلاعات، I/O و سیاستهای Backup رو هم در نظر بگیر.
📌 اگر بخوایم یه جمع بندی کنیم
Thin → انعطاف و استفاده بهتر از ظرفیت
Thick → رزرو ظرفیت از ابتدا و کنترل بهتر روی فضای اختصاصیافته
@abrplusdocs
یکی از تصمیمهای مهم موقع ساخت VM در VMware انتخاب نوع Virtual Disk هست.
دو انتخاب رایج:
Thin Provision
Thick Provision
تفاوت اصلیشون چیه؟
🔹 Thin Provision
اگر یک دیسک 500 GB بسازی، از همون ابتدا کل 500 GB روی Datastore اشغال نمیشه.
فضا بهمرور و با افزایش اطلاعات VM مصرف میشه.
مزیت اصلی:
✅ استفاده بهینهتر از Storage
✅ مناسب برای محیطهایی که تعداد VM زیاد هست
✅ امکان Overprovisioning
اما باید حواست به فضای آزاد Datastore باشه.
🔹 Thick Provision
اگر یک دیسک 500 GB بسازی، فضا از ابتدا روی Datastore رزرو میشه.
مزیتش اینه که ظرفیت موردنیاز VM از ابتدا مشخص و رزرو شده.
❓خب کدوم VM رو روی کدوم بذاریم؟
اینجا جواب کاملاً به Workload و Storage بستگی داره، اما بهصورت کلی:
🟢 Thin
Web Server
Application Server
Development / Test VM
VDI
VMهایی که رشد Storage قابل پیشبینی دارن
🔵 Thick
دیتاهای حساس و پرترافیک
High I/O Workload
ماشین هایی که حساس به Performance
محیطهایی که نمیخوای ریسک Datastore Overcommit داشته باشی
اما یک نکته مهم:
اینطور نیست که Thick همیشه سریعتر از Thin باشه.
در بسیاری از محیطها، مخصوصاً با Storageهای مدرن، تفاوت Performance میتونه خیلی کمتر از چیزی باشه که تصور میکنیم.
🔄بنابراین فقط به خاطر اینکه یک VM مهمه، سریع سراغ Thick نرو.
قبل از تصمیمگیری، نوع Storage، نرخ رشد اطلاعات، I/O و سیاستهای Backup رو هم در نظر بگیر.
📌 اگر بخوایم یه جمع بندی کنیم
Thin → انعطاف و استفاده بهتر از ظرفیت
Thick → رزرو ظرفیت از ابتدا و کنترل بهتر روی فضای اختصاصیافته
@abrplusdocs
❤3
🔹️سرویس Nova چیکار میکنه؟
اگر بخوایم خیلی ساده بگیم:
سرویس Nova مسئول Compute در OpenStack هست.
یعنی وقتی کاربر درخواست میکنه:
«یک ماشین مجازی برام بساز»
یکی از اصلیترین سرویسهایی که وارد عمل میشه، Nova هست.
اما Nova خودش ماشین مجازی رو اجرا نمیکنه.
کار Nova بیشتر اینه که منابع موردنیاز VM رو مدیریت و هماهنگ کنه؛ مثل:
🔹 CPU
🔹 RAM
🔹 Compute Host
🔹 محل اجرای VM
🔹 ارتباط با Hypervisor
مثلاً وقتی یک VM با مشخصات زیر درخواست میکنی:
سرویس Nova بررسی میکنه این VM روی کدوم Compute Host قرار بگیره و فرآیند ایجاد و مدیریت اون رو هماهنگ میکنه.
اما برای Disk و Network، سرویسهای دیگه هم وارد ماجرا میشن:
Nova → Compute
Neutron → Network
Cinder → Block Storage
Glance → Image
یعنی OpenStack یک سرویس واحد نیست؛ چندین سرویس کنار هم کار میکنن تا در نهایت یک VM در اختیار کاربر قرار بگیره.
یک نکته مهم:
Nova ≠ Hypervisor
سرویسNova مدیریت Compute رو انجام میده و میتونه از Hypervisorهایی مثل KVM برای اجرای VMها استفاده کنه.
@AbrPlusDocs
اگر بخوایم خیلی ساده بگیم:
سرویس Nova مسئول Compute در OpenStack هست.
یعنی وقتی کاربر درخواست میکنه:
«یک ماشین مجازی برام بساز»
یکی از اصلیترین سرویسهایی که وارد عمل میشه، Nova هست.
اما Nova خودش ماشین مجازی رو اجرا نمیکنه.
کار Nova بیشتر اینه که منابع موردنیاز VM رو مدیریت و هماهنگ کنه؛ مثل:
🔹 CPU
🔹 RAM
🔹 Compute Host
🔹 محل اجرای VM
🔹 ارتباط با Hypervisor
مثلاً وقتی یک VM با مشخصات زیر درخواست میکنی:
4 vCPU8 GB RAM100 GB Disk
سرویس Nova بررسی میکنه این VM روی کدوم Compute Host قرار بگیره و فرآیند ایجاد و مدیریت اون رو هماهنگ میکنه.
اما برای Disk و Network، سرویسهای دیگه هم وارد ماجرا میشن:
Nova → Compute
Neutron → Network
Cinder → Block Storage
Glance → Image
یعنی OpenStack یک سرویس واحد نیست؛ چندین سرویس کنار هم کار میکنن تا در نهایت یک VM در اختیار کاربر قرار بگیره.
یک نکته مهم:
Nova ≠ Hypervisor
سرویسNova مدیریت Compute رو انجام میده و میتونه از Hypervisorهایی مثل KVM برای اجرای VMها استفاده کنه.
@AbrPlusDocs
👍2❤1
🔹️آیا Veeam از OpenStack بکاپ میگیرد؟
اینجا باید یک نکته مهم رو روشن کنیم:
در نسخههای فعلی Veeam، برای oVirt KVM / RHV / OLVM پلاگین رسمی وجود داره و Veeam میتونه VMها رو Backup و Restore کنه. حتی معماری Backup شامل Worker، Snapshot و انتقال داده به Repository میشه.
اما درباره OpenStack داستان فرق داره.
در حال حاضر Veeam پشتیبانی مستقیم و Agentless برای Backup کردن VMهای OpenStack ارائه نمیکنه. حتی در انجمن رسمی Veeam هم درباره این موضوع صراحتاً گفته شده که OpenStack پشتیبانی مستقیم ندارد.
✅️پس راه کار چیه؟
🔹 Veeam Agent داخل Guest OS
🔹 Backup در سطح Storage / Snapshot
🔹 راهکارهای Backup اختصاصی OpenStack
🔹 و طراحی Backup مستقل از Hypervisor
میتونن وارد معماری بشن و اینجا یک نکته خیلی مهم وجود داره:
بکاپ Strategy باید قبل از Migration طراحی بشه، نه بعد از اون
چون ممکنه VM شما با موفقیت:
VMware → OpenStack
مهاجرت کنه...
ولی روز بعد متوجه بشید:
❌ Backup ندارید
❌ Restore Point معتبر ندارید
❌ RPO شما قابل دستیابی نیست
❌ و مهمتر از همه، Recovery Plan تست نشده!
توی پست بعدی میریم سراغ اینکه
اگه Veeam مستقیم OpenStack رو پشتیبانی نمیکنه ، برای یک سازمان بزرگ چه معماری Backupای برای OpenStack منطقی تره و بهتره؟
@abrplusdocs
اینجا باید یک نکته مهم رو روشن کنیم:
در نسخههای فعلی Veeam، برای oVirt KVM / RHV / OLVM پلاگین رسمی وجود داره و Veeam میتونه VMها رو Backup و Restore کنه. حتی معماری Backup شامل Worker، Snapshot و انتقال داده به Repository میشه.
اما درباره OpenStack داستان فرق داره.
در حال حاضر Veeam پشتیبانی مستقیم و Agentless برای Backup کردن VMهای OpenStack ارائه نمیکنه. حتی در انجمن رسمی Veeam هم درباره این موضوع صراحتاً گفته شده که OpenStack پشتیبانی مستقیم ندارد.
✅️پس راه کار چیه؟
🔹 Veeam Agent داخل Guest OS
🔹 Backup در سطح Storage / Snapshot
🔹 راهکارهای Backup اختصاصی OpenStack
🔹 و طراحی Backup مستقل از Hypervisor
میتونن وارد معماری بشن و اینجا یک نکته خیلی مهم وجود داره:
بکاپ Strategy باید قبل از Migration طراحی بشه، نه بعد از اون
چون ممکنه VM شما با موفقیت:
VMware → OpenStack
مهاجرت کنه...
ولی روز بعد متوجه بشید:
❌ Backup ندارید
❌ Restore Point معتبر ندارید
❌ RPO شما قابل دستیابی نیست
❌ و مهمتر از همه، Recovery Plan تست نشده!
توی پست بعدی میریم سراغ اینکه
اگه Veeam مستقیم OpenStack رو پشتیبانی نمیکنه ، برای یک سازمان بزرگ چه معماری Backupای برای OpenStack منطقی تره و بهتره؟
@abrplusdocs
❤5👍1🙏1
ابرپلاس | Cloud & Security🔵
Photo
🔹️حالا که فهمیدیم Veeam بهصورت Native مثل VMware با OpenStack یکپارچه نیست، سؤال اصلی اینه:
پس برای OpenStack چطور Backup بگیریم؟
🧩 Cinder Backup
اگر VMهای شما از Cinder Volume استفاده کنند، سرویس Cinder امکان ایجاد Backup از Volume را دارد.
حتی میتوان:
🔹 Full Backup گرفت
🔹 Incremental Backup گرفت
🔹 بکاپ را روی Backend مناسب ذخیره کرد
🔹 بکاپ را روی Volume جدید Restore کرد
اوپن استک بهصورت رسمی API و سرویس Backup برای Cinder دارد.
اما یک نکته خیلی مهم:
پس اگر فقط از Volume بکاپ بگیریم، باید برای موارد دیگری مثل:
• Configuration
• Metadata
• Instance Definition
• Network Configuration
• Security Groups
• OpenStack Database
• و در بعضی سناریوها Imageها
هم فکری کنیم.
حتی مستندات OpenStack تأکید میکنند که برای Recovery صحیح Cinder Backup، اطلاعات مرتبط با Block Storage Database یا Metadata Backup نیز باید حفظ شود.
@abrplusdocs
پس برای OpenStack چطور Backup بگیریم؟
🧩 Cinder Backup
اگر VMهای شما از Cinder Volume استفاده کنند، سرویس Cinder امکان ایجاد Backup از Volume را دارد.
حتی میتوان:
🔹 Full Backup گرفت
🔹 Incremental Backup گرفت
🔹 بکاپ را روی Backend مناسب ذخیره کرد
🔹 بکاپ را روی Volume جدید Restore کرد
اوپن استک بهصورت رسمی API و سرویس Backup برای Cinder دارد.
اما یک نکته خیلی مهم:
پس اگر فقط از Volume بکاپ بگیریم، باید برای موارد دیگری مثل:
• Configuration
• Metadata
• Instance Definition
• Network Configuration
• Security Groups
• OpenStack Database
• و در بعضی سناریوها Imageها
هم فکری کنیم.
حتی مستندات OpenStack تأکید میکنند که برای Recovery صحیح Cinder Backup، اطلاعات مرتبط با Block Storage Database یا Metadata Backup نیز باید حفظ شود.
@abrplusdocs
❤2
This media is not supported in your browser
VIEW IN TELEGRAM
♦️ربات پینگپنگ باز هم از راه رسید🤖🏓
🔹واکنش زیر ۲۰۰ میلیثانیه؛ هوش مصنوعی حالا پشت میز پینگپنگ هم حریف میطلبد!
🔹واکنش زیر ۲۰۰ میلیثانیه؛ هوش مصنوعی حالا پشت میز پینگپنگ هم حریف میطلبد!
👎1🥰1😨1
🔴 آسیبپذیری Critical در VMware vCenter؛ وقتی خودِ Management Plane هدف قرار میگیرد
🔺یک آسیبپذیری با شناسه CVE-2026-59310 در VMware vCenter شناسایی شده که شدت آن 9.8 از 10 (Critical) اعلام شده.
موضوع فقط شدت آسیبپذیری نیست.
این مورد حالا در فهرست Known Exploited Vulnerabilities (KEV) سازمان CISA هم قرار گرفته؛ یعنی با یک آسیبپذیری صرفاً تئوری طرف نیستیم و سوءاستفاده از آن در دنیای واقعی گزارش شده است.
این آسیبپذیری مربوط به vCenter Server Syslog Service است و از نوع Directory Traversal محسوب میشود. در شرایطی که مهاجم دسترسی لازم را داشته باشد، امکان سوءاستفاده و در نهایت اجرای کد روی سیستم وجود دارد.
اما چرا برای تیم زیرساخت مهم است؟
چون vCenter یکی از مهمترین نقاط مدیریتی در محیط VMware است.
اگر یک Workload معمولی آسیبپذیر شود، محدوده تأثیر ممکن است همان سیستم باشد؛ اما وقتی نقطه مدیریت زیرساخت درگیر میشود، داستان متفاوت است.
ویسنتر معمولاً به تعداد زیادی از Hostها، VMها و سرویسهای مدیریتی دسترسی دارد.
بنابراین یک سناریوی حمله میتواند از اینجا شروع شود و بعد مهاجم به دنبال Credential، دسترسی بیشتر، ایجاد Persistence یا دستکاری منابع زیرساخت برود.
به همین دلیل، در چنین مواردی فقط Patch کردن کافی نیست.
اگر vCenter شما در معرض این آسیبپذیری بوده، دو سؤال باید همزمان بررسی شود:
آیا Patch شده؟
و مهمتر:
قبل از Patch شدن، آیا نشانهای از سوءاستفاده وجود داشته؟
برای محیطهای Production بهتر است علاوه بر بررسی Version و اعمال Patch، لاگهای vCenter و Syslog و همچنین Authenticationهای غیرعادی هم بررسی شوند.
یک نکته دیگر هم مهم است:
ویسنتر را نباید مثل یک Server معمولی در نظر گرفت.
این سیستم بخشی از Management Plane زیرساخت است و دسترسی به آن میتواند مسیر حمله به بخشهای مختلف Virtual Infrastructure را باز کند.
📌 اگر VMware دارید، وضعیت vCenterهای خودتان را بررسی کنید.
منبع اصلی:
Broadcom VMware Security Advisory
VMSA-2026-0006.2
NIST / NVD — CVE-2026-59310
CISA — Known Exploited Vulnerabilities Catalog
#VMware #vCenter #CyberSecurity #Virtualization #Infrastructure
@abrplusdocs
🔺یک آسیبپذیری با شناسه CVE-2026-59310 در VMware vCenter شناسایی شده که شدت آن 9.8 از 10 (Critical) اعلام شده.
موضوع فقط شدت آسیبپذیری نیست.
این مورد حالا در فهرست Known Exploited Vulnerabilities (KEV) سازمان CISA هم قرار گرفته؛ یعنی با یک آسیبپذیری صرفاً تئوری طرف نیستیم و سوءاستفاده از آن در دنیای واقعی گزارش شده است.
این آسیبپذیری مربوط به vCenter Server Syslog Service است و از نوع Directory Traversal محسوب میشود. در شرایطی که مهاجم دسترسی لازم را داشته باشد، امکان سوءاستفاده و در نهایت اجرای کد روی سیستم وجود دارد.
اما چرا برای تیم زیرساخت مهم است؟
چون vCenter یکی از مهمترین نقاط مدیریتی در محیط VMware است.
اگر یک Workload معمولی آسیبپذیر شود، محدوده تأثیر ممکن است همان سیستم باشد؛ اما وقتی نقطه مدیریت زیرساخت درگیر میشود، داستان متفاوت است.
ویسنتر معمولاً به تعداد زیادی از Hostها، VMها و سرویسهای مدیریتی دسترسی دارد.
بنابراین یک سناریوی حمله میتواند از اینجا شروع شود و بعد مهاجم به دنبال Credential، دسترسی بیشتر، ایجاد Persistence یا دستکاری منابع زیرساخت برود.
به همین دلیل، در چنین مواردی فقط Patch کردن کافی نیست.
اگر vCenter شما در معرض این آسیبپذیری بوده، دو سؤال باید همزمان بررسی شود:
آیا Patch شده؟
و مهمتر:
قبل از Patch شدن، آیا نشانهای از سوءاستفاده وجود داشته؟
برای محیطهای Production بهتر است علاوه بر بررسی Version و اعمال Patch، لاگهای vCenter و Syslog و همچنین Authenticationهای غیرعادی هم بررسی شوند.
یک نکته دیگر هم مهم است:
ویسنتر را نباید مثل یک Server معمولی در نظر گرفت.
این سیستم بخشی از Management Plane زیرساخت است و دسترسی به آن میتواند مسیر حمله به بخشهای مختلف Virtual Infrastructure را باز کند.
📌 اگر VMware دارید، وضعیت vCenterهای خودتان را بررسی کنید.
منبع اصلی:
Broadcom VMware Security Advisory
VMSA-2026-0006.2
NIST / NVD — CVE-2026-59310
CISA — Known Exploited Vulnerabilities Catalog
#VMware #vCenter #CyberSecurity #Virtualization #Infrastructure
@abrplusdocs
❤1
ابرپلاس | Cloud & Security🔵
Photo
🔴 آسیبپذیری جدید در Veeam Backup & Replication
شرکت Veeam در ۲۵ آگوست ۲۰۲۶ جزئیات آسیبپذیری زیر رو منتشر کرده:
CVE-2026-58070
این آسیبپذیری باعث میشه Credentialهای سیستمعامل Guest که برای قابلیت Application-Aware Processing استفاده میشن، بهصورت Cleartext داخل Logهای ماشین Guest ثبت بشن.
🔸 Severity: Medium
🔸 CVSS v4: 6.8
🔻 نسخههای تحت تأثیر
Veeam Backup & Replication 13.0.2.29
و تمام Buildهای قبلی نسخه 13.
📌 طبق اعلام Veeam، نسخههای 12.x تحت تأثیر این آسیبپذیری نیستند.
🛠 راهکار
این مشکل در نسخههای زیر برطرف شده:
✅ Veeam Backup & Replication 13.1
Build 13.1.0.411
یا
✅ Veeam Backup & Replication 13.0.3
Build 13.0.3.63
چرا مهمه؟
بکاپ Server یکی از حساسترین بخشهای زیرساخته.
اگر Credentialهای مورد استفاده برای سرویسهای Backup داخل Logها به شکل قابل خواندن ذخیره بشن، در صورت دسترسی غیرمجاز به Guest یا Logها، احتمال افشای Credential وجود داره.
پس اگر از Veeam 13 استفاده میکنید:
🔎 اول Build نسخهتون رو بررسی کنید.
بعد ببینید آیا در محدوده نسخههای آسیبپذیر قرار دارید یا نه.
📌 یک نکته مهم:
در زیرساخت Backup، فقط خود Backup Server مهم نیست؛ Logها، Credentialها و دسترسیهای سرویس Backup هم بخشی از سطح حمله هستن.
@abrplusdocs
شرکت Veeam در ۲۵ آگوست ۲۰۲۶ جزئیات آسیبپذیری زیر رو منتشر کرده:
CVE-2026-58070
این آسیبپذیری باعث میشه Credentialهای سیستمعامل Guest که برای قابلیت Application-Aware Processing استفاده میشن، بهصورت Cleartext داخل Logهای ماشین Guest ثبت بشن.
🔸 Severity: Medium
🔸 CVSS v4: 6.8
🔻 نسخههای تحت تأثیر
Veeam Backup & Replication 13.0.2.29
و تمام Buildهای قبلی نسخه 13.
📌 طبق اعلام Veeam، نسخههای 12.x تحت تأثیر این آسیبپذیری نیستند.
🛠 راهکار
این مشکل در نسخههای زیر برطرف شده:
✅ Veeam Backup & Replication 13.1
Build 13.1.0.411
یا
✅ Veeam Backup & Replication 13.0.3
Build 13.0.3.63
چرا مهمه؟
بکاپ Server یکی از حساسترین بخشهای زیرساخته.
اگر Credentialهای مورد استفاده برای سرویسهای Backup داخل Logها به شکل قابل خواندن ذخیره بشن، در صورت دسترسی غیرمجاز به Guest یا Logها، احتمال افشای Credential وجود داره.
پس اگر از Veeam 13 استفاده میکنید:
🔎 اول Build نسخهتون رو بررسی کنید.
بعد ببینید آیا در محدوده نسخههای آسیبپذیر قرار دارید یا نه.
📌 یک نکته مهم:
در زیرساخت Backup، فقط خود Backup Server مهم نیست؛ Logها، Credentialها و دسترسیهای سرویس Backup هم بخشی از سطح حمله هستن.
@abrplusdocs
❤2
This media is not supported in your browser
VIEW IN TELEGRAM
🔹 مدیرعامل شرکت خدمات انفورماتیک: حمله سایبری به بانکها بسیار گسترده بود
حمله سایبری به بانکهایی که دادههای آنها در شرکت خدمات انفورماتیک میزبانی میشدند، شاید بزرگترین حمله سایبری به شبکه بانکی کشور تاکنون بود. آن هم در دورهای که حملاتی از این دست کمتعداد نیستند.
محمدسعید طباطبایی، مدیرعامل شرکت خدمات انفورماتیک میگوید این شرکت توانسته است بدافزاری که به دادههای بانکها حمله کرده بود را شناسایی کرده و برای آنتیویروس نوشتهاند. او حمله انجام شده به بانکها را بسیار گسترده و در لایههای زیرین توصیف میکند.
#حمله_سایبری
@abrplusdocs
حمله سایبری به بانکهایی که دادههای آنها در شرکت خدمات انفورماتیک میزبانی میشدند، شاید بزرگترین حمله سایبری به شبکه بانکی کشور تاکنون بود. آن هم در دورهای که حملاتی از این دست کمتعداد نیستند.
محمدسعید طباطبایی، مدیرعامل شرکت خدمات انفورماتیک میگوید این شرکت توانسته است بدافزاری که به دادههای بانکها حمله کرده بود را شناسایی کرده و برای آنتیویروس نوشتهاند. او حمله انجام شده به بانکها را بسیار گسترده و در لایههای زیرین توصیف میکند.
#حمله_سایبری
@abrplusdocs
🙏1