سال ۹۸، پروژه‌ی مانیتورینگ و کنترل یه شبکه‌ی توزیع آب شهری رو داشتم. سیستم بر پایه‌ی 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

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

🔴 هشدار امنیتی: اسکن SNMP روی یک سوئیچ صنعتی

این تصویر، خروجی یک اسکن امنیتی با ابزار متاسپلویت (Metasploit) را نشان می‌دهد که پروتکل SNMP را روی یک دستگاه شبکه‌ی صنعتی هدف قرار داده است. پروتکل SNMP مخفف Simple Network Management Protocol است و در شبکه‌های صنعتی (اتوماسیون، برق، آب و فاضلاب، نفت و گاز) برای مانیتورینگ تجهیزاتی مثل سوئیچ‌ها، روترها، پی‌ال‌سی‌ها و RTUها استفاده می‌شود.

همان‌طور که در خروجی مشخص است، مهاجم با موفقیت به آی‌پی 192.168.1.1 متصل شده و بدون نیاز به رمز یا با استفاده از community string پیش‌فرض (مثل public یا private) توانسته اطلاعات حیاتی دستگاه را استخراج کند. این اطلاعات شامل موارد زیر است:

مک‌آدرس‌های اختصاصی برای هر پورت (که امکان ردیابی فیزیکی تجهیزات را فراهم می‌کند)
· سرعت و پهنای باند هر اینترفیس (که برای شناسایی ترافیک عادی و غیرعادی استفاده می‌شود)
· حجم داده‌های ورودی و خروجی (که می‌تواند الگوی حمله یا نشت اطلاعات را نشان دهد)
· نام‌گذاری پورت‌ها مانند my switch Port 1 که ساختار داخلی شبکه را افشا می‌کند

نکته‌ی بسیار مهم: فیلدهای مربوط به اطلاعات مدیر سیستم (Contact، Location و Uptime) همگی خالی هستند. این موضوع نشان‌دهنده‌ی پیکربندی بسیار ضعیف امنیتی است؛ چراکه نه تنها از community string پیش‌فرض استفاده شده، بلکه حتی اطلاعات پایه‌ای برای شناسایی و پاسخگویی به حوادث ثبت نشده است.

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

اقدام اصلاحی فوری: دسترسی به SNMP روی تمام تجهیزات صنعتی باید محدود شود. استفاده از community stringهای قوی و غیرقابل حدس، اعمال ACL (لیست کنترل دسترسی) برای محدود کردن آی‌پی‌های مجاز، و در صورت امکان مهاجرت به نسخه‌ی امن‌تر SNMPv3 با رمزنگاری، الزامی است. همچنین ثبت و مانیتورینگ تمام درخواست‌های SNMP باید فعال شود تا هر گونه اسکن غیرمجاز بلافاصله شناسایی و پاسخ داده شود.

امروز میخوام ساختار قاب پروتکل DNP3 رو که یکی از حیاتی‌ترین پروتکل‌های شبکه‌های برق و اتوماسیون صنعتیه، با هم ورق بزنیم. اگه به شکل استانداردش نگاه کنیم، میبینیم که DNP3 چجوری داده رو لایه‌بندی میکنه تا توی محیط‌های پرنویز صنعتی هم قابل اعتماد باشه. خب، بیایم از بالا به پایین تصویر نگاه کنیم. اول از همه با لایه فیزیکی و پیوند داده شروع میکنه، اونجا یه هدر HDLC داریم که توش آدرس MAC مبدأ و مقصد درج شده، البته اگه روی اترنت سوار باشه، و همچنین آدرس IP مبدأ و مقصد که نشون میده بسته داره توی شبکه لایه‌بندی میشه. بعد از این سرآیندها، به بسته IP میرسیم که خودش یه هدر و یه محموله داره و توی محموله‌اش، داده اصلی DNP3 قرار گرفته.
حالا بریم سراغ قلب قاب، یعنی همون DNP3 LPDU. اینجا با یه فیلد ۲ بایتی Start شروع میشه که مقدار ثابت 0x05 و 0x64 هست و کارش همگام‌سازی گیرنده با شروع فریمه. بلافاصله بعدش یه فیلد ۱ بایتی Length میاد که طول باقیمونده قاب رو به ما میگه

البته به جز خود اون ۲ بایت شروع و این یه بایت طول. بعد نوبت به فیلد ۱ بایتی Control میرسه که خیلی مهمه چون نوع فریم رو مشخص میکنه که فریم اطلاعاتیه، نظارتیه یا بدون شماره، و همچنین شماره دنباله ارسال و دریافت و پرچم‌های کنترلی توش هست. بعدش دو فیلد ۲ بایتی برای آدرس مقصد و آدرس مبدأ در لایه پیوند داریم که آدرس‌های ۱۶ بیتی ایستگاه‌های صنعتی رو مشخص میکنن. در نهایت برای اینکه مطمئن بشیم هدر سالم رسیده، یه CRC ۲ بایتی روش انداختیم که بهش میگن CRC-16 و کل هدر رو پوشش میده.
بعد از این هدر، نوبت به محموله اصلی یا همون Payload میرسه که در واقع همون لایه کاربرد DNP3 هست. اینجا قضیه جالبتر میشه، چون داده‌های کاربردی که قراره منتقل بشن، مثلاً مقادیر آنالوگ، وضعیت کلیدها، یا فرمان‌های کنترلی، به صورت بلوک‌های داده با حداکثر طول ۲۵۰ بایت سازماندهی میشن. یعنی هر بلوک شامل خود داده تا سقف ۲۵۰ بایت هست و بلافاصله بعد از هر بلوک، یه CRC ۲ بایتی مجزا قرار داره که یکپارچگی همون بلوک رو تضمین میکنه. این بلوک‌ها پشت سر هم قرار میگیرن و مجموعشون میتونه تا ۲۹۲ بایت داده خالص رو پوشش بده. جالبه که هر بلوک مستقل از بقیه CRC خودش رو داره، پس اگه یه بلوک خراب بشه، بقیه بلوک‌ها قابل استفاده هستن و نیازی به کل دیتاگرام نیست، این خیلی برای کانال‌های مخابراتی نویزدار صنعتی ارزشمنده

حالا از دید امنیتی، این ساختار یه سری نکات حسابه که به عنوان کسی که تو حوزه امنیت ICS کار میکنه، نباید ازش غافل بشیم. اول اینکه DNP3 به صورت پیش‌فرض اصلاً رمزنگاری نداره، یعنی هر کی بتونه به شبکه دسترسی داشته باشه، کل داده‌ها رو به صورت متن واضح میبینه و میتونه مقادیر فرایندی رو استخراج کنه. دوم اینکه CRC که اینجا استفاده شده فقط برای تشخیص خطاهای تصادفیه و هیچ مقاومتی در برابر حملات عمدی نداره، یعنی یه مهاجم به راحتی میتونه داده رو عوض کنه و CRC جدید حساب کنه و بسته رو بفرسته. سوم اینکه آدرس‌های ۱۶ بیتی ثابت، امکان جعل آدرس و حملات اسپوفینگ رو خیلی راحت میکنه. چهارم اینکه چون شماره دنباله‌های امن و زمان‌مهر معتبر در همه فریم‌ها وجود نداره، حمله تکرار یا Replay Attack یکی از تهدیدات جدی محسوب میشه. در نتیجه، توی پیاده‌سازی‌های واقعی، ما چاره‌ای نداریم جز اینکه DNP3 رو یا با پسوند امنیتیاش یعنی DNP3-SA که احراز هویت و امضای دیجیتال پیام رو اضافه میکنه، استفاده کنیم، یا اینکه کل ترافیک رو توی یه تونل امن مثل TLS یا IPsec کپسوله کنیم. همچنین تفکیک شبکه با فایروال‌های صنعتی و قرار دادن این پروتکل در یک VLAN جداگانه، یکی از الزامات پایه‌ایه.

در نهایت، این ساختار رو باید به عنوان یه پروتکل کارا و سبک دید که برای مخابرات سریال و شبکه‌های داخلی صنعتی طراحی شده، اما به هیچ وجه نباید بدون لایه امنیتی تکمیلی در معرض دنیای خارج قرار بگیره. پس همیشه به یاد داشته باشیم که امنیت در DNP3 یک امر افزودنیه و باید لایه‌به‌لایه بهش اضافه بشه، نه اینکه به خود پروتکل اعتماد کنیم. این رو بدونید که بیشتر حملات سایبری به پست‌های برق و تصفیه‌خانه‌ها، دقیقاً از همین نقاط کور پروتکل‌هایی مثل DNP3 سوءاستفاده کردن. پس بهترین کار، پیاده‌سازی مکانیزم‌های احراز هویت قوی، پایش مداوم ترافیک با IDS/IPS مخصوص پروتکل‌های صنعتی و به‌روزرسانی منظم دستگاه‌های RTU و IED هست. امیدوارم این توضیح براتون مفید بوده باشه و بتونیم با درک عمیق تر این ساختارها، گام موثرتری در جهت ایمن‌سازی زیرساخت‌های حیاتی مون برداریم. اگه سوالی بود حتماً بپرسید.

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

تو این تصویر، یه سوییچ مرکزی داریم که حکم قلب تپنده شبکه رو داره و همه چیز بهش وصله.

بریم سمت چپ: یه HMI Client داریم با آی‌پی 172.16.0.1/24. این همون صفحه‌ای هستش که اپراتور پشتش میشینه و داره سیستم رو مانیتور می‌کنه. این کلاینت با خط شماره 1 مستقیم وصله به اون سوییچ مرکزی.

حالا بریم سمت راست: سه تا سرور خفن داریم که همه‌شون تو یه ساب‌نت با آی‌پی 172.16.1.1/24 قرار دارن.
اولی سرور HMI هستش (خط 4 و 5)، دومی سرور دیتای HMI (خط 6 و 7) و سومی هم یه گیت‌وی برای پروتکل‌های کنترلیه (خط 8 و 9). این سه تا با خطوط 4 تا 9 به سوییچ مرکزی وصل شدن و اطلاعات رو رد و بدل می‌کنن.

اما بریم سراغ پایین تصویر که یه دنیای دیگه‌ست!
اینجا یه Data Concentrator داریم با آی‌پی 172.16.4.1/24. این وسیله کارش جمع کردن دیتا از چند تا منبع مختلفه. این با خطوط 13 و 14 وصل شده به یه سوییچ دیگه که پایین‌تر قرار داره.
آخر خط هم یه Controller (کنترلر) داریم با آی‌پی 172.16.5.1/24. این همون مغز متفکر سیستمه که فرمان‌ها رو اجرا می‌کنه و با خط شماره 20 به اون سوییچ پایینی وصله.

یه سری خط‌چین هم می‌بینید مثل خطوط 2 و 3 که سوییچ مرکزی رو به یه روتر بالایی وصل می‌کنه، یا خطوط 15 و 18 که ارتباط بین دو تا سوییچ رو نشون میده. این خط‌چینا معمولاً یا مسیرهای منطقی (Logical) هستن یا مسیرهای رزرو برای مواقع اضطراری که اگه خط اصلی قطع شد، شبکه بخوابه.

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

معماری شبکه صنعتی و جایگاه پروتکل Modbus

این تصویری که می‌بینید، یه نمای کامل از اینه که پروتکل Modbus چطور توی سلسله‌مراتب شبکه‌های صنعتی جا می‌گیره. بذارید از پایین به بالا یه دوری بزنیم.

اول از همه، بریم سراغ لایه فیلد (Field System). اینجا جاییه که Modbus RTU داره کار می‌کنه. یه PLC به عنوان Master روی بستر RS-485 نشسته و یه سری دستگاه دیگه مثل پنل‌های اپراتور، درایوها یا PLC/IDs به عنوان Slave بهش وصلن. توی این لایه، ارتباط سریال و نسبتاً ساده‌ست ولی به شدت پایدار و مقرون‌به‌صرفه برای فواصل کوتاه تا متوسط. همه چی روی همون دو سیم می‌چرخه و Master تصمیم می‌گیره کی با کی حرف بزنه.

حالا اگه از این لایه فیلد بیایم بالاتر، می‌رسیم به لایه کنترل (Control Network). اینجا یه گیت‌وی یا همون RTU وارد می‌شه. کارش چیه؟ دقیقاً نقش مترجم رو بازی می‌کنه. داده‌های خام و سریال لایه پایین رو می‌گیره و به زبون اترنت ترجمه می‌کنه. یعنی Modbus RTU رو تبدیل می‌کنه به Modbus TCP. این نقطه، همون نقطه‌ی وصله بین دنیای OT (تکنولوژی عملیاتی) و IT (فناوری اطلاعات)

بعد از این گیت‌وی، وارد لایه بالایی یعنی Supervisory و Business Network می‌شیم. اینجا دیگه خبری از کابل‌های سریال و RS-485 نیست. همه چی روی بستر Ethernet و TCP/IP بالا می‌ره. دستگاه‌ها و کامپیوترهای موجود توی این لایه، از طریق همون Modbus TCP با داده‌ها ارتباط برقرار می‌کنن و می‌تونن همه چیز رو مانیتور کنن و مدیریت کنن. HMI هم دقیقاً همین‌جا به شبکه وصله.

نکته‌ی جالب این معماری اینه که یه پروتکل قدیمی اما طلایی مثل Modbus، هنوز هم می‌تونه از سطح یه سنسور ساده تا سطح مدیریت کل کارخانه، یکپارچگی داده رو حفظ کنه. ترکیب Modbus RTU/RS-485 توی لایه فیلد برای سرعت و پایداری، و Modbus TCP توی لایه‌های بالایی برای یکپارچگی با شبکه‌های اترنت، هنوز هم یکی از رایج‌ترین و پرکاربردترین الگوهای پیاده‌سازی توی پروژه‌های اتوماسیون صنعتیه.

#Industrial_Automation #Modbus #PLC #SCADA #Network_Architecture@pythonwithmedev