چالش‌ها شامل وابستگی به لاگ‌های ساختاریافته (JSON/Syslog)، حساسیت به تنظیمات محیط و نیاز به به‌روزرسانی مستمر است. در مجموع، سیگما با ساختار شفاف و انعطاف‌پذیر، راهکاری کارآمد برای پیاده‌سازی قواعد تشخیص تهدید در محیط‌های مختلف فراهم می‌کند که تطبیق با ساختار لاگ‌های هدف و به‌روزرسانی منظم برای اثربخشی پایدار ضروری است.

شناسایی نوع سیستم فایل یکی از اقدامات پایه‌ای در مدیریت ذخیره‌سازی و تحلیل امنیتی محسوب می‌شود و روش‌های آن بسته به دسترسی به سیستم به دو شاخه پاسخ‌دهی زنده و بررسی آف‌لاین تقسیم می‌گردد. در حالت دسترسی زنده، سه دستور اصلی کاربرد دارند: دستور lsblk -f که اطلاعات ساختاریافته‌ای از تمام بلاک‌دستگاه‌ها شامل نوع سیستم فایل، UUID، اندازه و نقطه‌اتصال را به صورت ستون‌بندی و خوانا نمایش می‌دهد و در سیستم‌هایی مانند CentOS به وضوح پارتیشن‌های xfs برای /boot و ریشه و همچنین حضور LVM2_member را مشخص می‌کند؛ دستور df -Th که علاوه بر نوع سیستم فایل، اطلاعات استفاده از دیسک مانند فضای کل، استفاده‌شده، موجود و درصد استفاده را به همراه نقطه‌اتصال هر پارتیشن نشان می‌دهد، اما در سیستم‌های دارای سرویس‌هایی مانند Docker خروجی آن شلوغ شده و تشخیص نوع اصلی سیستم فایل را دشوار می‌سازد، در حالی که در همین شرایط lsblk -f خروجی تمیزتری ارائه کرده و به عنوان مثال در سیستم اوبونتو به روشنی بخش بوت را از نوع FAT32 و سیستم فایل اصلی را EXT4 معرفی می‌کند؛

و دستور cat /etc/fstab که فایل شامل اطلاعات سیستم فایل‌های ثابت mount شونده در زمان بوت را نمایش داده و در سیستم‌های زنده نمای کلی از پارتیشن‌های دائمی و نوع آن‌ها ارائه می‌دهد. در حالت بررسی آف‌لاین یا Deadbox Forensics که به Image دیسک دسترسی وجود دارد، معمولاً از دستور cat /etc/fstab بر روی Image مونت‌شده استفاده می‌شود تا جدول سیستم فایل بررسی گردد و این روش حتی در صورت عدم اجرای سیستم عامل نیز قابل انجام است و اطلاعات دقیقی از نوع و نقاط اتصال پارتیشن‌ها در اختیار تحلیلگر قرار می‌دهد. از مقایسه این روش‌ها برمی‌آید که lsblk -f به دلیل خروجی ساختاریافته و سطح پایین‌تر هسته، گزینه اولیه در پاسخ‌دهی زنده محسوب می‌شود؛ df -Th برای تحلیل فضای مصرفی و شناسایی سریع نقاط اتصال مفید است هرچند در محیط‌های مجازی‌سازی شده نویز ایجاد می‌کند؛ و cat /etc/fstab در هر دو حالت زنده و مرده نمای پایداری از سیستم فایل‌های دائمی ارائه می‌دهد که برای تأیید تنظیمات و تحلیل پس از حمله حیاتی است و ترکیب این سه روش، شناسایی کامل نوع سیستم فایل از xfs و ext4 تا FAT32 و LVM را با دقت بالا ممکن می‌سازد و برای عملیات‌هایی نظیر بازیابی داده، تحلیل بدافزار و مهندسی معکوس زیرساخت ضروری می‌باشد.

بررسی فاجعه امنیتی Equifax در سال ۲۰۱۷ همچنان یکی از تلخترین و در عین حال آموزنده ترین نمونه های شکست در زنجیره مدیریت امنیت سایبری محسوب میشود؛ پروندهای که در آن یک آسیبپذیری شناخته شده با نمره خطر ۱۰ از ۱۰، به دلیل مجموعهای از خطاهای ساده اما زنجیروار، به فاجعه بارترین نقض داده های تاریخ تبدیل شد. ماجرا از سیستم تحت وب ACIS شروع شد، اپلیکیشنی که کاربران برای اعتراض به اطلاعات نادرست گزارش اعتباری خود از آن استفاده میکردند و شامل دو وبسرور، دو اپلیکیشن سرور و سه دیتابیس پشتیبان بود. در مارس ۲۰۱۷، بنیاد Apache آسیبپذیری بحرانی CVE-2017-5638 را در فریمورک Struts اعلام کرد که به مهاجم اجازه میداد بدون نیاز به احراز هویت، به سادگی کد دلخواه خود را روی سرور اجرا کند و کنترل کامل سیستم را در دست بگیرد. باوجود هشدار جدی US-CERT و تأکید بر لزوم وصله زنی ظرف ۴۸ ساعت، تیم امنیت Equifax طی یک اسکن سطحی، این آسیب پذیری را پیدا نکرد، چون اسکنر را روی ریشه دایرکتوری اجرا کرده بودند درحالیکه فایلهای Struts در زیرشاخهای دیگر قرار داشت و اسکن بعدی روی ۹۵۸ آیپی عمومی هم هیچ نتیجهای دربرنداشت.

مهاجمان اگرچه احتمالاً از همان روزهای اول افشا از وجود این روزنه باخبر شدند، اما تا دو ماه بعد یعنی مه ۲۰۱۷ دست نگه داشتند و سپس با بهره برداری از همان نقطه کور، حدود ۳۰ وب شل را روی سرورها آپلود کردند تا دسترسی دائمی و پنهان برای خود ایجاد کنند و اینجاست که دومین اشتباه بزرگ نمایان شد؛ نبود هرگونه سیستم پایش یکپارچگی فایل ها باعث شد نصب ده ها فایل مشکوک ماه ها بی درنگ بماند و مهاجم بدون کوچکترین مزاحمتی به کندوکاو در شبکه و استخراج اطلاعات حساس بیش از ۱۴۷ میلیون نفر بپردازد. این پرونده به خوبی ثابت میکند که در امنیت سایبری، داشتن ابزارهای گران قیمت یا تدوین سیاست های سنگین کافی نیست، بلکه اجرای دقیق فرایندها، پیکربندی درست اسکن ها، و داشتن سیستم های مانیتورینگ پیوسته است که میتواند یک تیم را از پرتگاه سقوط نجات دهد و غفلت از هرکدام از این حلقه ها، کل زنجیره را به شکستی جبران ناپذیر تبدیل میکند.

بیشتر چیز هایی که امروز به اسم network programming میشناسیم، ریشه‌ شون برمیگرده به 4.2BSD جایی که برای اولین بار شبکه به عنوان یک مفهوم خیلی آشنا دیده شد. ایده این بود که اگه بتونی با فایل حرف بزنی، باید بتونی با شبکه هم دقیقاً به همون شکل حرف بزنی. همین نگاه ساده باعث شد read و write بشن هسته‌ ارتباطات شبکه ای در یونیکس.

همه‌ چیز از ()socket شروع میشه این فراخوانی در واقع هیچ ارتباطی رو برقرار نمیکنه، فقط از کرنل میخوای یه اندپوینت خام بهت بده. چیزی شبیه باز کردن یک فایل، با این تفاوت که هنوز نه آدرسی داره و نه مقصدی. فقط یه فایل دیسکریپتور تحویل میگیری که قراره بعدا معنای شبکه‌ای پیدا کنه.

بعد از اون باید به این اندپوینت هویت بدی. اینجاست که ساختار sockaddr_in میاد وسط وقتی میگی IPv4 هست، پورت 8081 رو میخوام و روی همه‌ اینترفیس‌ ها گوش بده، در واقع داری به کرنل میگی این فایل قراره نماینده‌ کدوم نقطه از شبکه باشه. با ()bind این هویت به سوکت چسبونده میشه. هنوز هیچ ارتباطی وجود نداره، فقط آدرس رزرو شده.

.تا اینجا سوکت فقط میدونه کیه، نه اینکه چه کاری باید بکنه. ()listen دقیقاً همین‌ جا معنی پیدا میکنه با این فراخوانی، سوکت از حالت عادی خارج میشه و وارد حالت گوش دادن میشه. یعنی کرنل شروع میکنه به گرفتن SYN ها، صف اتصال درست میکنه و آماده میشه برای اینکه کسی واقعاً وصل بشه. این لحظه‌ ایه که برنامه از «یه فایل معمولی» تبدیل میشه به «یه سرور»

وقتی کلاینتی وصل میشه، ()accept صدا زده میشه. نکته‌ خیلی مهم اینه که ()accept همون سوکت قبلی رو برنمیگردونه. یک file descriptor جدید ساخته میشه که نماینده‌ی دقیقاً همون اتصال مشخصه. سوکت اصلی همچنان فقط گوش میده. این جدا شدن listening socket از connected socket یکی از پایه‌ای ترین مفاهیم TCP server هاس و خیلی‌ ها دقیقاً همین‌ جا گیج میشن نمیدونن...

از این به بعد دیگه هیچ چیز خاصی وجود نداره. ارتباط برقرار شده و فقط با یک file descriptor در ارتباطی ()read میکنی دیتا میاد. ()write میکنی دیتا میره. نه تابع خاص شبکه، نه تفاوت مفهومی با فایل. همون چیزی که 4.2BSD کانسپتش رو از اول میخواست همینه

سمت کلاینت هم داستان کوتاه‌ تره ولی همون استراکچر رو داره. ()socket ساخته میشه، با ()connect به یک آدرس مشخص وصل میشه، و بعدش همه‌ چیز دوباره به read و write ختم میشه. ()connect در واقع فقط handshake TCP رو کامل میکنه و به اون file descriptor معنی اتصال میده همین.

جذابش رو ما تو لینوکس epoll رو داریم که حالا بماند برای بحث آینده. :)
⚝

تو شبکه مفاهیم شمالی – جنوبی و شرقی – غربی فقط جهت ترافیک نیستن در واقع دو طرز فکر کاملا متفاوت تو دیزاین زیرساخت رو نشون میدن ترافیک شمالی – جنوبی همون تصویریه که همه مون با اون آشنایم کاربر یا سیستم بیرونی که از اینترنت وارد میشه از چند لایه‌ امنیتی عبور میکنه و به سرویس میرسه این مسیر واضحه مرز داره نقطه‌ کنترل داره و به همین دلیل هم سال ها تمرکز اصلی امنیت و طراحی روی اون بوده/هستش ولی این فقط بخش کوچیکی از واقعیت شبکه‌ های امروزیه

تو معماری های مدرن اون چیزی که سیستم رو واقعا زنده نگه میداره ترافیک شرقی – غربیه ارتباطاتی که بی وقفه داخل کلاستر، بین سرویس ها، دیتابیس ها، کش ها و کامپوننت ها جریان داره این ترافیک معمولا دیده نمیشه، لاگ و متریک درستی ندارن و اغلب بر پایه‌ اعتماد ضمنی طراحی شده همین موضوع باعث میشه بیشترین خرابی ها، بیشترین latency های غیرمنتظره و سناریوهای امنیتی دقیقا از همین مسیر شکل بگیرن وقتی یه سرویس کند میشه وقتی retry ها زنجیره‌ ای از آب در میان یا وقتی یه کامپوننت کامپرومایز میشه مسیر تخریب در واقع از شرق به غربه

تفاوت اصلی اینجاس که شمالی – جنوبی درباره‌ محافظت از ورودیه اما شرقی – غربی درباره‌ کنترل رفتار داخلی سیستمه در اولی سوال اینه که چه کسی وارد میشه در دومی، اینه که هر سرویس دقیقا با کی؟ چرا؟ و چگونه؟ صحبت میکنه به همین دلیل مفاهیمی مثل zero trust، mtls، network policy و سرویس مش اهمیت پیدا میکنه اینا به عنوان پاسخ طبیعی به واقعیت ترافیک داخلییه

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

این نقشه یک دیاگرام تک‌خطی از سیستم توزیع برق صنعتی با برند زیمنس مربوط به یک کنسرن تولیدی روسیه است. ساختار کلی شامل چندین واحد مجزا به نام "Молновый комбинат" است که هر واحد دارای دو ورودی برق جداگانه (Ввод1 و Ввод2)، چهار مصرف‌کننده مجزا (Потребитель 01 تا 04) و چهار خط تولید (Продукция 01 تا 04) میباشد. همچنین بخش جداگانه‌ای برای تولید بخار و آب گرم (ТЭ/ЭВ в горючей воде и паре) با یک ورودی آماده‌به‌کار (Стоячее воды) در نظر گرفته شده است. از منظر امنیت سایبری سطح ICS، اولین آسیب‌پذیری قابل شناسایی عدم وجود مکانیزم سنکرون‌سازی بین دو ورودی است که در صورت افت ولتاژ یا تغییر فاز، منطق سوئیچ خودکار (ATS) ممکن است دچار نوسان شده و قطعی ناخواسته ایجاد کند. دومین ضعف ساختاری، وابستگی کامل کارگاه شماره ۲ به کارگاه شماره ۱ بدون ورودی مستقل است که این نقطه را به یک Single Point of Failure تبدیل میکند به طوری که هر گونه حمله یا خرابی در کارگاه ۱ مستقیماً کل کارگاه ۲ را از مدار خارج میسازد

سومین مسئله، عدم جداسازی فیزیکی شبکه بین بخش برق و بخش بخار است که هر دو از یک سوئیچ صنعتی مشترک تغذیه میشوند و این امکان را برای مهاجم فراهم میکند که از طریق نفوذ به شبکه بخار (که معمولاً از پروتکل Modbus/TCP استفاده میکند) به شبکه برق دسترسی پیدا کند. برای رفع این موارد، اقدامات عملی شامل تفکیک VLAN با ACL سخت‌افزاری بین ورودی‌ها و مصرف‌کننده‌ها، فعال‌سازی امضای دیجیتال برای فرامین نوشتن در حافظه PLCهای سری S7-1500 زیمنس، نصب ثبت‌کننده رویداد صنعتی از نوع SEL-2440 یا معادل آن برای پایش پیوسته فرکانس و ولتاژ، و تغییر توپولوژی از حالت دو ورودی موازی به حلقه افزونه با پروتکل PRP پیشنهاد میشود. همچنین در سطح نرم‌افزار، یک اسکریپت مانیتورینگ ساده با پایتون میتواند افت همزمان هر دو ورودی را تشخیص داده و هشدار قطعی قریب‌الوقوع را صادر کند که در محیط شبیه‌سازی با اعمال نویز تصادفی ±۵ ولت بر روی هر دو فیدر، آستانه هشدار روی ۱۹۰ ولت تنظیم میشود. این تحلیل مبتنی بر استاندارد ISA-99 (IEC 62443) و راهنمای NIST SP 800-82 است

در Kerberos، بعد از اینکه کاربر نام کاربری و رمز عبورش را وارد می‌کند، رمز عبور مستقیماً روی شبکه ارسال نمی‌شود. کلاینت از روی رمز عبور یک کلید رمزنگاری تولید می‌کند و درخواست AS-REQ را به KDC می‌فرستد. اگر احراز هویت موفق باشد، KDC در پاسخ AS-REP را همراه با Ticket Granting Ticket (TGT) ارسال می‌کند. این TGT با کلید حساب krbtgt رمز شده و فقط KDC قادر به خواندن و اعتبارسنجی آن است. داخل TGT اطلاعاتی مانند نام کاربر، SID، گروه‌های امنیتی، زمان اعتبار، Session Key و همچنین PAC (Privilege Attribute Certificate) قرار دارد که شامل اطلاعات دسترسی و مجوزهای کاربر است. پس از دریافت TGT، کاربر برای هر سرویس دیگر نیازی به ارسال مجدد رمز عبور ندارد و با ارسال TGS-REQ به KDC، یک Service Ticket مخصوص همان سرویس دریافت می‌کند. این مکانیزم علاوه بر پیاده‌سازی Single Sign-On (SSO)، امنیت را نیز افزایش می‌دهد؛ زیرا رمز عبور هرگز بین سرویس‌ها جابه‌جا نمی‌شود. همچنین به دلیل اینکه اعتبار TGT به حساب krbtgt وابسته است، محافظت از این حساب اهمیت بسیار بالایی دارد

و در صورت افشای کلید آن، امکان ایجاد Golden Ticket برای دور زدن فرآیند احراز هویت وجود خواهد داشت.

یکی از رایج‌ترین معماری‌های شبکه‌های صنعتی را بر اساس مدل Purdue نشان می‌دهد. در این مدل، تجهیزات و سیستم‌های کنترلی در چند لایه مجزا قرار می‌گیرند تا هم مدیریت شبکه ساده‌تر باشد و هم امنیت به شکل بهتری تأمین شود. در پایین‌ترین لایه (Level 0) خودِ فرآیند صنعتی قرار دارد؛ یعنی تجهیزاتی مثل ربات‌ها، خطوط تولید، مخازن و ماشین‌آلات. یک لایه بالاتر (Level 1) سنسورها، عملگرها، درایوها و ماژول‌های I/O قرار دارند که اطلاعات را از فرآیند جمع‌آوری کرده و فرمان‌های کنترلی را اجرا می‌کنند. در Level 2، PLCها، HMIها و کنترلرهای هر خط تولید قرار گرفته‌اند و وظیفه کنترل و مانیتورینگ هر بخش از کارخانه را بر عهده دارند. در بالاترین لایه این تصویر (Level 3) نیز سرورهای SCADA، Historian، ایستگاه‌های مهندسی و سرویس‌های پشتیبان کارخانه قرار دارند که مدیریت و نظارت بر کل سایت را انجام می‌دهند.

ارتباط بین این لایه‌ها از طریق سوئیچ‌های هسته و توزیع صنعتی انجام می‌شود و هدف اصلی این طراحی، جداسازی بخش‌های مختلف شبکه است تا در صورت بروز خرابی یا حمله سایبری، مشکل به کل مجموعه گسترش پیدا نکند. به همین دلیل، مدل Purdue هنوز هم یکی از مهم‌ترین مراجع برای طراحی شبکه‌های OT و پیاده‌سازی امنیت در محیط‌های صنعتی به شمار می‌رود.

این شکل، نمای کلی یک معماری SCADA رو نشون می‌ده. در مرکز کنترل، سرور SCADA/MTU داده‌ها رو از سایت‌های مختلف جمع‌آوری می‌کنه، اپراتورها از طریق HMI فرآیند رو مانیتور و کنترل می‌کنن، Data Historian اطلاعات رو ذخیره می‌کنه و Engineering Workstation برای پیکربندی و برنامه‌نویسی تجهیزات استفاده می‌شه.
در لایه پایین، PLC داده‌های سنسورهایی مثل فشار، دبی و سطح رو دریافت می‌کنه و بر اساس منطق کنترلی، تجهیزاتی مثل پمپ و شیرها رو کنترل می‌کنه. ارتباط بین مرکز کنترل و سایت‌های راه دور هم از طریق شبکه WAN، لینک‌های رادیویی یا سایر بسترهای مخابراتی برقرار می‌شه.
نکته مهم این معماری، تفکیک صحیح شبکه IT و OT و ایمن‌سازی مسیرهای ارتباطیه؛ چون هر ارتباط بین این دو شبکه، یک نقطه بالقوه برای حملات سایبری محسوب می‌شه. به همین دلیل استفاده از فایروال، DMZ، کنترل دسترسی و مانیتورینگ مداوم، جزو اصول اصلی امنیت شبکه‌های صنعتی است

در تحلیل جرم‌شناسی دیجیتال (Digital Forensics)، بررسی Timestamp‌های فایل یکی از مهم‌ترین مراحل بازسازی Timeline رخدادهاست. چهار Timestamp اصلی شامل M (Modified) برای آخرین تغییر محتوای فایل، A (Accessed) برای آخرین دسترسی، C (Metadata Change) برای آخرین تغییر در متادیتای inode مثل Permission، مالک یا Rename و B (Birth/Creation) برای زمان ایجاد واقعی فایل هستند که به آن MACB گفته می‌شود.
همه فایل‌سیستم‌ها از MACB پشتیبانی نمی‌کنند؛ EXT3 فقط MAC را ذخیره می‌کند، اما EXT4، XFS و Btrfs قابلیت ثبت Birth Time را دارند. با این حال، همان‌طور که در تصویر مشخص است، فلش اول نشان می‌دهد دستور stat همیشه زمان ایجاد فایل را نمایش نمی‌دهد و نبودن Birth در خروجی، لزوماً به معنی نبودن آن در فایل‌سیستم نیست.
در فلش دوم ابتدا با دستور ls -li شماره inode فایل استخراج شده و سپس با ابزار xfs_db تمام Timestampها از inode خوانده می‌شود که مقدار crtime (Creation Time) نیز نمایش داده می‌شود. فلش سوم همین فرآیند را برای EXT4 با ابزار debugfs انجام می‌دهد

ابتدا inode با

ls -li

به دست می‌آید و سپس با

debugfs

و دستور

stat <inode>

تمام Timestampها از جمله crtime استخراج می‌شوند.
نکته مهم این است که ctime به معنی Creation Time نیست؛ بلکه فقط زمان آخرین تغییر متادیتای inode را نشان می‌دهد. به همین دلیل در تحلیل‌های حرفه‌ای نباید صرفاً به خروجی

stat

اکتفا کرد و برای استخراج دقیق Timestampها باید متناسب با نوع File System از ابزارهایی مانند debugfs و xfs_db استفاده کرد. این تفاوت‌ها در Incident Response و Digital Forensics می‌توانند نقش مهمی در تحلیل صحیح رخدادها داشته باشند.

حمله TrojPix؛ نفوذ به سیستم‌های Air-Gap از فاصله ۲۰۸ متری: محققان دانشگاه شاندونگ روشی به نام TrojPix ابداع کرده‌اند که با استفاده از امواج الکترومغناطیسی ساطع‌شده از کابل HDMI، می‌تواند داده‌ها را از سیستم‌های کاملاً ایزوله (Air-Gap) سرقت کند. این حمله با سرعت ۸.۱ مگابیت بر ثانیه (حدود ۲۷ برابر سریع‌تر از روش‌های قبلی) و از پشت دیوار بتنی کار می‌کند و برای چشم انسان نامرئی است 📡🔓🖥️
منبع: https://healsecurity.com/new-trojpix-attack-lets-attackers-access-air-gapped-computers-from-208-meters/

thehackernews.com/2026/07/new-trojpix-attack-leaks-data-from-air.html

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