اینم یه ادیتور تحت وب برای ساخت دیاگرام‌ها و صحنه‌های 3D معماری/سیستمی هستش. یعنی به جای اینکه فقط با شکل‌های 2 بعدی مثل draw.io یا Visio دیاگرام بکشی، می‌تونی یک محیط سه‌بعدی بسازی و اجزا رو داخلش بچینی

تست آنلاین :
icraft.design/app/editor

سورس کد :
github.com/gantFDT/icraft


@Linuxor

بررسی یک وضعیت واقعی در HMI سیستم هوای فشرده
این تصویر مربوط به HMI یک سیستم هوای فشرده و وضعیت دو کمپرسور هست.
در سمت چپ، Compressor 1 در وضعیت General Fault قرار گرفته و در قسمت آلارم، خطای Modbus Disconnect دیده میشه. یعنی ارتباط کنترلی/مانیتورینگ این کمپرسور با سیستم HMI یا کنترلر از طریق Modbus دچار مشکل شده و به همین دلیل کمپرسور از نظر سیستم در وضعیت Fault قرار گرفته.
در سمت راست، Compressor 2 وضعیت عادی‌تری داره و هم‌زمان وضعیت‌های RUN و LOAD فعال هستن؛ یعنی کمپرسور در حال کار بوده و تحت بار قرار داشته
فشار نمایش داده‌شده هم حدود 7.6 bar هست. نکته جالب تصویر اینه که در کنار وضعیت تجهیزات، پارامترهایی مثل Pressure و Temperature و همچنین وضعیت Local Start و Sequence Mode / Local Mode هم در HMI قابل مشاهده هستن.

از دید امنیت و اتوماسیون صنعتی، قسمت Modbus Disconnect مهمه؛ چون اینجا فقط با یک آلارم ساده طرف نیستیم. قطع شدن ارتباط بین تجهیزات و سیستم کنترل می‌تونه باعث از دست رفتن Visibility، دریافت نشدن صحیح وضعیت تجهیز و در بعضی سناریوها حتی ایجاد مشکل در منطق کنترلی سیستم بشه.

نکته مهم اینه که در یک محیط صنعتی واقعی، صرفاً برطرف کردن آلارم کافی نیست. باید مشخص بشه قطع ارتباط دقیقاً از کجا اتفاق افتاده؛ از شبکه، سوئیچ، کابل، Gateway، تنظیمات Modbus، خود PLC/Controller یا تجهیز Field.

همین جزئیات به ظاهر ساده روی HMI، وقتی از دید OT/ICS Security و Reliability بررسی بشن، می‌تونن اطلاعات خیلی خوبی درباره وضعیت واقعی سیستم و نقاط حساس معماری کنترل در اختیارمون بذارن

این تصویر در واقع یک نقشهٔ راه از سطوح حمله در دو لایهٔ پایینی مدل پوردو (سطح ۰ و ۱) رو برای ما ترسیم میکنه که بیشتر معطوف به تجهیزات میدانی مثل PLCها و سنسورهاست. قضیه از درگاه‌های شبکه شروع میشه؛ جایی که مهاجم از طریق پورت‌های باز صنعتی می‌تونه سه عمل اصلی رو انجام بده: یا داده‌ها رو از PLC بارگذاری کنه، یا فریم‌ور رو فاسد کنه، یا اطلاعات رو از دستگاه خارج کنه. این دسترسی به شبکه، زمینه‌ساز حمله از طریق زنجیره تأمین هم هست، یعنی وقتی یک به‌روزرسانی فریم‌ور انجام میشه، امکان تزریق کد ناشناس به بستهٔ به‌روزرسانی وجود داره که می‌تونه بدون اینکه کسی متوجه بشه، جایگزین فریم‌ور معتبر بشه. در سطح پروتکل‌های ارتباطی هم مهاجم سه کارکرد اساسی رو هدف میگیره: نوشتن مستقیم روی رجیسترهای PLC برای تغییر پارامترهای فرآیند، اجرای حملات انکار سرویس با ارسال پکت‌های سنگین یا غیرمنتظره که باعث اختلال در پاسخ‌دهی دستگاه میشه، و خواندن حافظه و منطق PLC برای شناسایی ضعف‌ها و برنامه‌ریزی حملات بعدی. از اینجا به بعد قضیه وارد لایهٔ ورودی و خروجی میشه

در بخش ورودی، مهاجم می‌تونه با جعل هویت یک سنسور یا دستگاه ورودی، داده‌های ساختگی رو به PLC تحمیل کنه تا الگوریتم کنترلی بر اساس اطلاعات غلط تصمیم‌گیری کنه، و در بخش خروجی، این نفوذ به سه سطح عمق پیدا میکنه: ابتدا نمای مانیتورینگ رو دستکاری میکنه تا اپراتور اطلاعات اشتباه ببینه، سپس به لایهٔ تصمیم‌گیری الگوریتم نفوذ میکنه و منطق کنترل رو تغییر میده، و در نهایت مستقیماً فرمان‌های خروجی به عملگرها رو کنترل میکنه تا رفتار فیزیکی تجهیزات رو تغییر بده. جالب اینجاست که حملات اسپوفینگ می‌تونند دوطرفه باشند؛ یعنی مهاجم هم می‌تونه هویت PLC رو جعل کنه و داده‌های جعلی به سیستم بالادستی بفرسته، و هم هویت یک ایستگاه بالادستی رو جعل کنه تا فرمان‌های غلط به PLC بده، که این یعنی ارتباط عمودی در هر دو جهت در معرض خطر قرار داره. اما قضیه به شبکه ختم نمیشه، چون درگاه‌های عیب‌یابی مثل JTAG یا UART که برای تعمیر و توسعه در نظر گرفته شدن، مسیر مستقیمی برای دسترسی به فریم‌ور فراهم می‌کنند و مهاجم با دسترسی به این پورت‌ها می‌تونه بدون نیاز به احرازهویت استاندارد، محتویات حافظه رو بخونه یا بازنویسی کنه. حتی فراتر از این، اگر مهاجم به بک‌پلن سخت‌افزاری دسترسی پیدا کنه – یعنی همان باس پشتیبان که ماژول‌های مختلف رو در رک به هم متصل میکنه – می‌تونه ارتباط بین ماژول‌ها رو شنود یا تغییر بده، که این کار نیاز به دسترسی فیزیکی داره ولی همهٔ لایه‌های امنیتی نرم‌افزاری رو بی‌اثر میکنه. نهایتاً پایین‌ترین و خطرناک‌ترین سطح، دسترسی مستقیم به خود تراشه‌ها و کارت‌های مدار هست؛ جایی که مهاجم با ابزارهای سخت‌افزاری مثل پروگرامر یا آنالایزر منطقی، می‌تونه کلیدهای رمزنگاری رو استخراج کنه، کد مخرب رو مستقیماً روی فلش بنویسه یا حتی میکروکنترلر رو دوباره برنامه‌ریزی کنه، و این سطح از حمله دیگه با وصلهٔ نرم افزاری قابل رفع نیست و تا تعویض سخت‌افزار، اثرش موندگار خواهد بود. در کل این تصویر یک زنجیرهٔ نفوذ از شبکه تا تراشه رو نشون میده که هرچه پایین‌تر میریم، حملات پرهزینه‌تر و تخصصی‌تر میشن، اما تأثیرشون عمیق‌تر، ماندگارتر و از دید سیستم‌های نظارتی پنهان‌تره، بنابراین دفاع مؤثر باید همزمان در لایه‌های شبکه، پروتکل، فریم‌ور، دسترسی فیزیکی و یکپارچگی سخت‌افزار طراحی بشه تا تمام این مسیرهای حمله پوشش داده بشن.

یه چیزی که این روزا درباره هوش مصنوعی و ربات‌ها خیلی جالبه اینه که دیگه قضیه فقط این نیست که یه ربات بسازیم که راه بره یا یه هوش مصنوعی داشته باشیم که باهامون حرف بزنه. اتفاقی که واقعاً داره میفته اینه که AI کم‌کم داره از حالت «فقط جواب دادن» میاد سمت «انجام دادن کار». مثلاً OpenAI یه سیستم به اسم Computer-Using Agent ساخته که می‌تونه چیزی که روی صفحه کامپیوتره رو ببینه و با موس و کیبورد باهاش کار کنه؛ یعنی کلیک کنه، تایپ کنه، بین سایت‌ها جابه‌جا بشه و یه کار چندمرحله‌ای رو خودش جلو ببره. البته هنوز اصلاً بی‌نقص نیست؛ توی تست OSWorld موفقیتش ۳۸.۱ درصد بوده، در حالی که عملکرد انسان‌ها در همون تست ۷۲.۴ درصد گزارش شده، پس هنوز خیلی جا داره تا بتونه مثل یه انسان مطمئن کار کنه.

ولی چیزی که برای من جالبه اینه که حتی با همین محدودیت‌ها، داریم کم‌کم به جایی می‌رسیم که به جای اینکه برای تک‌تک کارها به AI دستور بدیم، یه هدف کلی بهش می‌دیم و خودش مراحل رسیدن به اون هدف رو انجام می‌ده

مثلاً به جای اینکه بگی «این صفحه رو باز کن»، می‌تونی بگی «این اطلاعات رو پیدا کن و داخل این فایل قرار بده» و سیستم سعی می‌کنه خودش مسیر انجام کار رو پیدا کنه. البته ممکنه اشتباه هم بکنه و دقیقاً همین‌جا بحث امنیت و کنترل خیلی مهم می‌شه.

جالب‌تر اینکه Anthropic روی میلیون‌ها تعامل واقعی انسان و AI بررسی انجام داده و گفته طولانی‌ترین sessionهای Claude Code طی چند ماه تقریباً دو برابر شده؛ یعنی در بالاترین بخش استفاده، مدت زمانی که مدل بدون توقف کار می‌کرد از کمتر از ۲۵ دقیقه به بیشتر از ۴۵ دقیقه رسیده. این به معنی «۴۵ دقیقه هوش مستقل مثل انسان» نیست، ولی نشون می‌ده مردم دارن کارهای طولانی‌تر و پیچیده‌تر رو به Agentها می‌سپارن.

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

ولی اینجا هم نباید جوگیر بشیم و بگیم «ربات‌ها الان مثل انسان شدن». هنوز فاصله خیلی زیاده. ربات‌های انسان‌نما هنوز در خیلی از کارهای روزمره و محیط‌های ناشناخته محدودیت جدی دارن و حتی Agentهای کامپیوتری فعلی هم اشتباه زیاد دارن.

چیزی که واقعاً داره تغییر می‌کنه اینه که کامپیوتر داره از یه ابزار منفعل تبدیل می‌شه به یه ابزار فعال؛ یعنی قبلاً ما می‌رفتیم پشت کامپیوتر و همه کارها رو خودمون انجام می‌دادیم، الان داریم به سیستم‌هایی می‌رسیم که می‌تونن بخشی از اون کارها رو خودشون انجام بدن.

به نظرم قسمت عجیب ماجرا هم دقیقاً همینجاست. نه اینکه فردا ربات‌ها بیان انسان‌ها رو نابود کنن؛ این حرفا بیشتر فیلمه. چیز واقعی اینه که هرچی AI توانایی بیشتری برای استفاده از کامپیوتر، اینترنت، نرم‌افزارها و در آینده ربات‌های فیزیکی پیدا کنه، نقش انسان از «انجام‌دهنده مستقیم کار» بیشتر می‌ره سمت «تعیین هدف، دادن دسترسی و نظارت کردن».

و این تغییر، همین الان شروع شده؛ فقط هنوز به اون مرحله‌ای که تو فیلم‌ها می‌بینیم نرسیدیم.

چند روز پیش داشتم یه فایل خیلی فنی خوندم راجع به یه پردازنده مخفی که توی تمام چیپست‌های اینتل کار گذاشتن، اسمش اینتل منیجمنت انجینه یا همون ME که از سال ۲۰۰۸ به بعد توی تمام کامپیوترهایی که پردازنده اینتل دارن وجود داره، این پردازنده کاملاً مستقل از سیپییوی اصلیه و حتی وقتی کامپیوتر رو خاموش می‌کنی بازم روشن می‌مونه، به شرطی که به برق وصل باشه، یعنی می‌تونه توی خواب یا خاموشی هم کار کنه، جالبتر اینکه دسترسی مستقیم به کارت شبکه داره، پس می‌تونه اطلاعات رو بدون اینکه سیستمعامل یا شما متوجه بشید بفرسته یا دریافت کنه، در واقع یه راه پشتی سخت‌افزاریه که هیچ آنتی‌ویروسی نمی‌تونه بفهمه، تازه بدتر اینکه این پردازنده قابلیت اجرای کد از راه دور داره، یعنی یه نفر می‌تونه از اون طرف دنیا بیاد به سیستمت وصل بشه و هر کاری دوست داره بکنه، حتی اگه ویندوزت کلاً هنگ کرده باشه، قابلیت دیگه‌ش اینه که می‌تونه سیستم رو قفل کنه یا اطلاعات رو پاک کنه، اگه مثلاً شرکتت یه لپ‌تاپ گم کنه و بخوای جلوی دسترسی به اطلاعاتو بگیری، ولی خوب این یه شمشیر دو لبه‌ست، چون ممکنه خودشون هم ازش استفاده کنن

حالا بریم سر اصل ماجرا، چیزی که منو بیشتر از همه بیشتر تو فکر فرو برد این بود که کدهای این پردازنده رو شرکت اینتل امضا کرده، یعنی هیچکس نمی‌تونه ببینه داخلش چیه، یه جعبه سیاه کامل، و بدتر اینکه از نسخه ۷ به بعد یه قابلیت جدید به اسم داینامیک اپلیکیشن لودر گذاشتن که یعنی هر اپلیکیشنی که امضای معتبر داشته باشه می‌تونه توی این پردازنده اجرا بشه، مثلاً الان از این قابلیت برای احرازهویت دو مرحله‌ای استفاده می‌کنن، ولی خب اگه یه هکر بتونه یه راهی پیدا کنه می‌تونه کد خودش رو هم روش اجرا کنه و این دقیقاً همون چیزیه که سال ۲۰۱۷ اتفاق افتاد و اینتل یه باگ بزرگ رو تأیید کرد که میشد ازش سوءاستفاده کرد، حالا بیایم اینجا توی ایران، ما با یه مشکل بزرگتر مواجهیم، چون عملاً تمام سیستم‌هامون خارجی هست و کنترلش دست خودمون نیست، ما نمی‌تونیم این پردازنده رو غیرفعال کنیم یا حتی بررسی کنیم که داره چیکار می‌کنه، تازه تلاشایی هم که محققا کردن برای نفوذ بهش اکثراً شکست خورده، مثلاً یه محقق سعی کرد قفل حافظه‌اش رو بشکنه که باعث شد برد کاملاً بسوزه، یکی دیگه سعی کرد با جا به جا کردن رم توی حالت سرد اطلاعاتش رو بخونه که نشد، چون رم scramble شده، پس عملاً این پردازنده یه موجودیت جداست، و اگه سازمان حساسی باشی، مثلاً نظامی، هسته‌ای، بانکی یا هر جای دیگه‌ای که اطلاعات محرمانه داری، این یعنی یه تهدید دائمی، راستش راه حل زیادی هم نداریم، چندتا پیشنهاد هست، یکی اینکه اگه می‌تونی از پردازنده‌های بدون این قابلیت استفاده کنی، مثل بعضی مدل‌های AMD یا پردازنده‌های جدید RISC-V، دوم اینکه سیستم‌های حساست رو از اینترنت جدا کنی فیزیکی، سوم اینکه از ابزارهای مثل me_cleaner استفاده کنی که بتونه تا حدی این ماژول رو غیرفعال کنه ولی کامل نیست، و در نهایت اینکه به فکر تولید سخت‌افزار بومی باشیم که خب می‌دونم خیلی سخته ولی چاره‌ای نیست، خلاصه اینکه این قضیه رو جدی بگیرید، فقط یه تئوری نیست، یه واقعیت اثبات‌شده‌ست و توی کنفرانس‌های امنیتی دنیا دارن روش کار می‌کنن، منبعش رو هم براتون می‌ذارم اگه خواستید دقیق تر بخونید، فعلاً همین، مراقب خودتون باشین

📢 سیاست انتشار محتوای این کانال:

این مطلب و تحلیل ارائه‌شده، حاصل گردآوری، ترجمه و تحلیل تخصصی توسط کانال OT Sentinel است و برای اولین بار در اینجا منتشر می‌شود.

✅ بازنشر (فوروارد) در سایر کانال‌ها و گروه‌ها کاملاً آزاد است، اما صرفاً با شرایط زیر:
🔹 ذکر نام کامل کانال: OT Sentinel | ICS/OT Security
🔹 درج لینک مستقیم کانال: https://t.me/pythonwithmedev

❌ هرگونه انتشار، کپی‌برداری یا استفاده از محتوای این پست بدون ذکر منبع، نقض حق نشر محسوب شده و از طریق مراجع قانونی و امنیتی پیگیری خواهد شد.

ما بر انتشار محتوا در فضای مجازی نظارت داشته و حق پیگیری قانونی را برای خود محفوظ می‌داریم.

با تشکر از همراهی شما در جهت ارتقاء امنیت زیرساخت‌های حیاتی کشور 🔐⚡
@pythonwithmedev

سال ۹۸، پروژه‌ی مانیتورینگ و کنترل یه شبکه‌ی توزیع آب شهری رو داشتم. سیستم بر پایه‌ی WinCC و PLCهای زیمنس S7-300 پیاده شده بود. همه چی طبق اسناد طراحی پیش می‌رفت تا اینکه یه روز عادی، هنگام بررسی لاگ‌های روزانه، یه اتفاق عجیب دیدم. یه تابع کاربردی تو PLC که کارش محاسبه‌ی دبی خروجی بود، بدون هیچ دستوری از سمت HMI یا اپراتور، مقدارش عوض شده بود. مقدارش از ۴۵۰ به ۷۸۰۰ تغییر کرده بود. عددی خارج از رنج سنسور. لاگ WinCC هیچ دستوری نشون نمی‌داد. اما لاگ Diagnostic Buffer PLC نشون می‌داد که یه درخواست نوشتن روی DB مرتبط با اون تابع، از یه آدرس آی‌پی خارج از محدوده‌ی شبکه‌ی صنعتی اومده. یعنی یه نفر از بیرون، بدون اینکه از HMI رد بشه، مستقیم رفته بود تو بلوک‌های داده‌ی PLC و مقدار رو عوض کرده بود. این یعنی سطح دسترسی مستقیم به حافظه‌ی PLC. این یعنی پروتکل S7Comm بدون هیچ لایه‌ی امنیتی، در معرض دید بود. اون روز برام روشن شد که سه تا باور غلط رو باید یک‌بار برای همیشه کنار بذارم.

باور اول اینکه سیستم ما ایزوله‌ست. نه، نیست. هر پورت ۱۰۲ باز روی یه PLC، یعنی هر کسی که به شبکه‌ی شما دسترسی داشته باشه، می‌تونه بنویسه تو حافظه‌اش. مگر اینکه لایه‌ی شبکه رو با ACL و VLAN جدا کرده باشید و دسترسی به پورت‌های OT رو فقط از مسیرهای مشخص و با احراز هویت قوی مجاز بدونید. باور دوم اینکه مهاجم باید خیلی حرفه‌ای باشه. نه، نیست. ابزارهایی مثل متاسپلویت ماژول مستقیم برای S7 دارن. یه بچه‌ی دوره‌دیده‌ی امنیت، در کمتر از ۵ دقیقه می‌تونه یه S7-1200 رو شناسایی کنه، بسته‌ی استارت/استاپ بفرسته و منطق رو تغییر بده. حرفه‌ای بودن مهاجم نیست که خطرناکه، دسترس‌پذیر بودن سیستمه که خطرناکه. باور سوم اینکه فایروال اداری کافیه. نه، کافی نیست. فایروال‌های IT، پروتکل‌های صنعتی رو نمی‌شناسن. فایروال صنعتی باید لایه‌ی ۷ رو ببینه، نه فقط پورت و آی‌پی. یه فایروال صنعتی خوب باید پیلود بسته‌های مادباس یا DNP3 یا S7Comm رو بررسی کنه و دستورات غیرمجاز مثل رایت به رجیسترهای حیاتی رو مسدود کنه

از اون روز، من یه چارچوب امنیتی ۷ مرحله‌ای رو برای همه‌ی پروژه‌هام الزامی کردم. این چارچوب رو بر اساس تجربه‌ی مستقیم و استاندارد IEC 62443 تدوین کردم. مرحله‌ی اول، شناسایی دقیق دارایی‌هاست. همه‌ی PLCها، RTUها، IEDها، HMIها، سرورهای تاریخچه و ایستگاه‌های مهندسی رو با جزئیات کامل شناسایی کنید. نه فقط آی‌پی، بلکه نسخه‌ی فریم‌ور، ماژول‌های نصب‌شده، پورت‌های باز و سرویس‌های فعال. هر دستگاهی که توی لیست نباشه، خطر محسوب میشه. مرحله‌ی دوم، بخش‌بندی شبکه بر اساس مدل پاردو هست. شبکه رو به ۵ سطح تقسیم کنید. سطح صفر، فرآیند که سنسورها و عملگرها هستن. سطح یک، کنترل محلی که PLCها و RTUها هستن. سطح دو، کنترل ناحیه‌ای که ایستگاه‌های اپراتوری هستن. سطح سه، مدیریت عملیات که سرورهای تاریخچه و مهندسی هستن. سطح چهار، شبکه‌ی سازمانی که IT هست. بین هر سطح، یه فایروال صنعتی بذارید که فقط ترافیک مجاز رو عبور بده. هیچ ارتباطی بین سطح سه و چهار بدون بازرسی عمیق بسته مجاز نیست. مرحله‌ی سوم، پیاده‌سازی سیاست انکار پیش‌فرض هست. همه‌ی قوانین فایروال به‌صورت Deny-All تعریف بشن. بعد یک‌به‌یک ارتباطات ضروری رو Allow کنید. این کار جلوی حرکت جانبی رو می‌گیره. اگه یه مهاجم بتونه یه دستگاه رو آلوده کنه، بدون قوانین Allow صریح، نمی‌تونه به دستگاه دیگه‌ای دسترسی پیدا کنه. مرحله‌ی چهارم، احراز هویت قوی و متمرکز هست. همه‌ی دسترسی‌ها به تجهیزات صنعتی باید از طریق یه دایرکتوری فعال با احراز هویت دو مرحله‌ای انجام بشه. رمزهای محلی تجهیزات رو غیرفعال کنید. اگه تجهیز از MFA پشتیبانی نمی‌کنه، دسترسی بهش رو از طریق یه جامپ باکس با MFA انجام بدید. مرحله‌ی پنجم، مانیتورینگ پیوسته و تحلیل لاگ هست. یه SIEM صنعتی راه‌اندازی کنید که لاگ‌های PLC، فایروال، HMI و سرورها رو جمع‌آوری کنه

حداقل این رویدادها رو پایش کنید: تلاش‌های ناموفق احراز هویت، تغییرات در منطق PLC، نوشتن روی رجیسترهای حیاتی، راه‌اندازی مجدد تجهیزات، ارتباطات از آی‌پی‌های ناشناس. مرحله‌ی ششم، مدیریت آسیب‌پذیری و وصله‌نگاری هست. سیستم‌های صنعتی رو نمی‌شه هر ماه وصله کرد. ولی حداقل یه برنامه‌ی منظم برای بررسی آسیب‌پذیری‌های بحرانی با امتیاز CVSS بالای ۹ داشته باشید. وصله‌ها رو اول تو محیط تست که شبیه محیط عملیاته اجرا کنید، بعد تو یه پنجره‌ی نگهداری برنامه‌ریزی‌شده روی سیستم اصلی اعمال کنید. مرحله‌ی هفتم، برنامه‌ی پاسخ به حادثه هست. یه تیم مشخص با نقش‌های شفاف تعیین کنید. سناریوهای حمله رو شبیه‌سازی کنید مثل قطع ارتباط با PLC یا تغییر ناگهانی یه مقدار فرآیندی. تمرین کنید که چطور سریع تشخیص بدید، ایزوله کنید، بازیابی کنید و گزارش بدید. بدون تمرین، توی لحظه‌ی بحران هیچ کس نمی‌دونه چکار کنه. اون روز که دیدم یه مقدار فشار از راه دور تغییر کرده، می‌تونستم بگم اشکال از سنسوره و بگذرم. ولی اگه گذشتم بود، ممکن بود امروز تو خبرها می‌خوندیم که یه شهر بی‌آب مونده. امنیت توی سیستم‌های صنعتی، شوخی نیست. یه تغییر کوچیک تو منطق یه PLC، می‌تونه یه سد رو باز کنه، یه توربین رو از مدار خارج کنه، یا یه خط تولید رو متوقف کنه. امنیت SCADA از شناخت شروع میشه، با کنترل ادامه پیدا می‌کنه و با پایش پایدار می‌مونه. نه آنتی‌ویروس، نه فایروال اداری و نه رمزهای پیچیده به تنهایی کار نمی‌کنن. باید همه‌ی لایه‌ها رو با هم بچینید. از فیزیک فرآیند تا بسته‌های شبکه، همه‌چیز باید تحت کنترل باشه. سیستم‌های صنعتی برای ۲۰ سال کار طراحی شدن. امنیتشون رو برای ۲۰ سال هم برنامه‌ریزی کنید. نه برای یه پروژه، نه برای یه دوره، برای کل چرخه‌ی حیات.

مرکز کنترل (Control Center): اینجا مغز متفکر سیستمه. اپراتورها پشت مانیتورهای HMI یا همون صفحه‌های مانیتورینگ گرافیکی نشستن و وضعیت کل شبکه رو رصد می‌کنن. اون بالا سمت چپ، «Data Historian» رو می‌بینین که نقش جعبه سیاه یا همون دیتابیس تاریخچه رو داره؛ یعنی تمام مقادیر فشار، دما، ولتاژ، وضعیت شیرها و هزاران پارامتر دیگه رو با یه بازه زمانی مشخص (مثلاً هر چند ثانیه) ذخیره می‌کنه تا بعداً برای تحلیل و عیب‌یابی استفاده بشه. SCADA Server (MTU): اینجا واحد اصلی ارتباطاته. بهش می‌گن Master Terminal Unit. وظیفه‌اش اینه که مرتباً با تمام ایستگاه‌های دور دست (Remote Stations) ارتباط برقرار کنه، داده‌هاشون رو درخواست کنه و دستورات اپراتور رو مثل افزایش فشار یا باز کردن یه شیر، براشون بفرسته. این سرور، قلب تپنده مرکز کنترل محسوب میشه. فایروال (Firewall): دقیقاً بین SCADA Server و شبکه WAN قرار گرفته. اینجا اولین خط دفاعیه. ترافیک ورودی و خروجی رو فیلتر می‌کنه و اجازه نمیده هر کسی از هر دری وارد بشه. معمولاً این فایروال طوری تنظیم میشه که فقط پورت‌ها و آدرس‌های مشخصی اجازه تردد داشته باشن و بقیه ترافیک رو ببنده.

ایستگاه‌های دور دست (Field Sites / Remote Stations): اینجاها معمولاً توی پست‌های برق، چاه‌های نفت، ایستگاه‌های پمپاژ آب یا حتی خطوط لوله گاز قرار دارن. هر کدوم شامل چندین تجهیز هستن:
RTU (Remote Terminal Unit): مغز متفکر هر ایستگاه دور دسته. این دستگاه، تمام سیگنال‌های ورودی از سنسورها و تجهیزات رو دریافت می‌کنه، پردازش اولیه روشون انجام میده و برای مرکز کنترل ارسال می‌کنه. همچنین دستورات دریافتی از مرکز رو اجرا می‌کنه. RTUها معمولاً قدرت پردازش پایینی دارن و با زبان‌های قدیمی مثل منطق یا پروتکل‌های ساده‌ای مثل Modbus یا DNP3 کار می‌کنن.
IED (Intelligent Electronic Device): این دستگاه‌های هوشمند، یه نسل بالاتر از RTU هستن. معمولاً برای محافظت از تجهیزات الکتریکی مثل ترانسفورماتورها و خطوط انتقال طراحی شدن. می‌تونن خطاهایی مثل اتصال کوتاه رو تشخیص بدن و سریعاً مدار رو قطع کنن. خیلی از IEDها از پروتکل IEC 61850 پشتیبانی می‌کنن که پیشرفته‌تره ولی بازم آسیب‌پذیری‌های خاص خودش رو داره.

حالا از منظر امنیت، کدوم نقاط حساسترن؟

اولاً، ارتباط بین WAN-Cardها و مودم‌ها، جایی که داده‌ها از مرکز کنترل به سمت ایستگاه‌های دور می‌رن، اگر رمزنگاری نشه، هر هکری با یه اسنیفر ساده می‌تونه همه چیز رو بخونه یا حتی دستورات جعلی بفرسته. متأسفانه خیلی از سیستم‌های اسکادا هنوز از رمزنگاری استفاده نمی‌کنن و به پروتکل‌های خام مثل Modbus TCP بسنده می‌کنن.

دوماً، خود RTUها و IEDها معمولاً قابلیت به‌روزرسانی امنیتی ندارن یا اگر هم داشته باشن، آفلاین به‌روز می‌شن. یعنی اگر یه باگ امنیتی توی پروتکل DNP3 پیدا بشه، ممکنه ماه‌ها یا سال‌ها طول بکشه تا برطرف بشه.

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

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

نکته آخر: این معماری قدیمی‌ترین و رایج‌ترین مدل در صنایع کشورمونه. برای ارتقای امنیت، باید لایه‌هایی مثل VPN، احراز هویت دو مرحله‌ای، سیستم‌های IDS/IPS و مانیتورینگ مداوم ترافیک شبکه بهش اضافه بشه. همچنین جداسازی فیزیکی یا منطقی بین شبکه صنعتی و شبکه اداری یه اصل حیاتیه که متأسفانه خیلی جاها رعایت نمیشه.

اگر تا به حال با ابزارهای شناسایی سیستم‌عامل مانند sinfp3 کار کرده باشید، میدانید که این ابزارها با ارسال پروبهای خاص به یک میزبان و تحلیل پاسخهای TCP/IP، به راحتی نوع سیستم‌عامل را تشخیص میدهند. اما تصور کنید بتوانیم درست درون هسته لینوکس، یک ماژول بنویسیم که پیش از ارسال پاسخ به سمت مهاجم یا ابزار شناسایی، بسته را به گونهای تغییر دهد که انگار یک سیستم‌عامل کاملاً متفاوت در حال پاسخگویی است. دقیقاً همین کار در قطعه کدی که مشاهده میکنید، انجام شده است. این ماژول کرنلی با دقت بالایی به بررسی بسته های دریافتی می پردازد و دو نوع پاسخ پروب مخصوص sinfp3 را تشخیص میدهد. نوع اول، بستهای با پروتکل TCP، طول ۴۴ بایت، و پرچم های SYN=1 و ACK=1 است و نوع دوم نیز مشابه اما با طول ۶۰ بایت است که در آن یک فیلد Timestamp نیز وجود دارد. وقتی ماژول چنین بستهای را مشاهده کند، دست به کار میشود و ابتدا با توابعی مانند set_id، set_df_bit، set_tl یا set_itl، و همچنین set_tcp_window، set_tcp_flags، set_tcp_sequence و set_tcp_ack، تمام فیلدهای کلیدی هدر IP و TCP را بازنویسی میکند

تا به جای اطلاعات سیستم واقعی، مقادیر دلخواه ما جایگزین شوند. اما کار به اینجا ختم نمیشود، زیرا یکی از مهمترین بخش های شناسایی سیستم عامل، آپشن های TCP مانند MSS، WScale و حتی خود Timestamp هستند. به همین دلیل، ماژول بررسی میکند که آیا طول آپشن های جدید با طول آپشن های موجود در بسته اصلی تفاوت دارد یا خیر؛ اگر تفاوت وجود داشته باشد، تابع 

modify_packet_size

 اندازه بسته را تغییر داده و فیلدهای Length و Offset را در هدر IP به روزرسانی میکند. در مرحله بعد، برای پاسخ اول، آپشن های MSS، WScale و Option_Layout تنظیم میشوند، اما در پاسخ دوم، ابتدا با تابع 

get_tcp_timestamp

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

tcp_csum

 محاسبه میشود و همین کار نیز برای هدر IP با تابع 

ip_csum

 انجام میگیرد. در نهایت، ماژول بسته ی تغییر یافته را به جای پاسخ اصلی به سمت فرستنده ارسال میکند و بدین ترتیب، ابزار 

sinfp3

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