یه چالش جدی‌تر که توی محیط‌های صنعتی باهاش دست و پنجه نرم می‌کنیم، بحث ویرایش برخط یا همون Online Edits توی کنترلرهاست. خیلی از کنترلرهای اتوماسیون این قابلیت رو دارن که بدون اینکه کسی فایلی رو چک‌اوت کنه، مستقیم برن روی دستگاه تغییر بدَن و برن. این یعنی یه پیمانکار یا حتی یه اپراتور می‌تونه بیاد یه تغییری توی پیکربندی بده، بدون اینکه هیچ مدرک یا مستنداتی ازش باقی بمونه و بعدش هم بره. به خاطر همین یکی از دلایل اصلی که خیلی از مراکز صنعتی اجازهٔ اتصال لپ‌تاپ‌های شخصی یا پیمانکاری رو به شبکه‌شون نمی‌دن، دقیقاً همینه. راستش من خودم چند جا دیدم که این سیاست خیلی کمک کرده به شفافیت کار

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

یه نکتهٔ خیلی مهم دیگه که توی عمل خیلی به کارم اومده، اینه که برای هر تغییری، حتی اگه به نظر کوچیک و بی‌اهمیت بیاد، باید یه سری اطلاعات حداقلی ثبت بشه؛ اینکه دقیقاً چه تغییری قراره انجام بشه، این تغییر چه محدوده یا مدت زمانی رو شامل می‌شه، چه کسی قراره انجامش بده و مهم‌تر از همه چه کسی مجوزش رو داده. یه مورد دیگه که خیلی از تیم‌ها ازش غافل می‌شن، تست عملیاتی بعد از تغییره. بهتره حتماً یه نفر بعد از اجرای تغییر، عملاً سیستم رو تست کنه و تأیید کنه که تغییر به درستی اعمال شده، اونم با امضا یا یه مدرک دیگه که بشه روش حساب کرد

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

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

حاضرم تو این کتابخونه از طلوع آفتاب تا پاسی از شب درس بخونم

مدیرعامل آنتروپی خاطر نشان کردند که،
بله در آینده کدنویسی از بین میره و بعدش کل مهندسی نرم افزار.

با توجه به روند فعلی درآمدزایی شرکت آنتروپی (Claude AI) ما فقط شاهد عدم بهینگی، هدر دادن منابع ارزشمند کاربران از جمله پول و وقتشون و درنهایت کار کردن روی ساختارها و بافتارهایی که اصلا با بهینگی سنخیتی ندارند و با این عدم بهینگی جاروبرقی Claude میلیاردها دلار رو ماهانه از جهان میکشن توی خزانه شون، خلق الله هم خوشحاله چیزی که دستشه آخرین تکنولوژی بشر قرن 21 هست !!!

پ.ن: به راستی که آنتروپی (فروپاشی منابع) بهترین اسم برای این شرکت بود.

نقل از کاربری که ۳۶ میلیون تومان وجه رایج رو تقدیم مدلی کرده که طی دو روز مصرف توکنش لیمیت میشه ..!

#Claude

چند وقت پیش داشتم یه دیتا دامپ رو بررسی میکردم که به یه نکته جالب برخوردم. توی تصویر بالا، یک سری دامپ و Watch از آدرسهای ۰x۱ تا ۰x۵۷ گرفتم. اولین چیزی که جلب توجه میکنه، الگوی افزایشی صرفاً عددی نیست، بلکه با دقت به دادههایی که به تابع PRGA پاس داده شدن، یه موضوع کلیدی کشف میشه. توی معماری RC4 و الگوریتمهای مبتنی بر جریان کلید، ورودی PRGA تعیینکننده جهت عملیاته. اگر ورودیها کلید یا IV باشن، خروجی باید کاملاً شبهتصادفی باشه، اما اینجا خروجیها ساختار مشخص و معناداری دارن. با بررسی مقادیر ورودی ۱ تا ۵۷ و مقایسه با خروجیهای متناظر، متوجه میشیم که دادههای ورودی دقیقاً همون Ciphertext هستن، چون خروجیهای به دست اومده الگویی غیرتصادفی دارن که قابل تفسیر بهعنوان Plaintext هستن. به عبارت دیگه، اگه سیستم در حالت رمزنگاری بود، ورودی PRGA میبایست کلید یا IV میبود و خروجی بایستی کاملاً رندوم میرفت، ولی اینجا خروجیها بازگشت به متن اصلی رو نشون میدن. در نتیجه، سیستم در حال Decryption هست، نه Encryption و دادههای Watch درواقع همون خروجی PRGA هستن که متن آشکار رو تشکیل میدن. این روش یه راه جانبی جالب برای تشخیص جهت عملیات رمز

توی ادامه بررسی، رفتم سراغ سکشن .s7b2 داخل Ghidra. اولین چیزی که نظرمو جلب کرد، چندتا لوکیشن لیبل‌گذاری شده بود که یکی از اونا مستقیماً به دیتای رمز شده (Encrypted Config) اشاره میکرد. اما سه تا لیبل دیگه هم اونجا بودن که هدفشون مشخص نبود. با کمی جلوتر رفتن و دنبال کردن جریان، متوجه شدم که یه HW Breakpoint روی تابع رمزگشایی RC4 تنظیم شده و وقتی breakpoint میخوره، میتونیم ببینیم که دادهها چطور پردازش میشن. اینجا بود که ارتباط بین این لیبلها مشخص شد: دو تا از اون سه لیبل باقی مونده، یکی به کلید RC4 اشاره داره و اون یکی هم به سایز دیتای رمز شده. پس ساختار کلی به این صورته: یه سکشن خاص حاوی دیتای رمز شده، یه کلید RC4 در جای دیگه، یه سایز مشخص برای دیتا، و در نهایت تابع رمزگشایی که همه اینارو کنار هم میذاره و دیتا رو به حالت اصلی برمیگردونه. این روش نشون میده که چطور با تحلیل استاتیک و داینامیک همزمان، میتونیم اجزای یک رمزنگاری جریانی رو در بدافزارها شناسایی کنیم و بفهمیم که دادهها چطور محافظت میشن و چطور باید اونا رو رمزگشایی کرد.

یه نمونه‌ی اجرایی اومد دستم به اسم raas.exe. توی x32dbg لودش کردم و ScyllaHide رو هم فعال کردم. همون ابتدای کار، توی Entry Point، یه CALL به تابع 402BD6 توی افست 40125E می‌زد. بعدش مقدار EAX رو چک می‌کرد، اگر غیرصفر بود می‌رفت 4013BE و ExitProcess می‌زد. یعنی اگه اون تابع تشخیص می‌داد محیط دیباگه، برنامه خودش رو می‌کشت.

رفتم سراغ تابع، با Step Into رفتم توش و با Step Over جلو رفتم تا رسیدم به 402C16 که نوشته بود call eax. اونجا مشخص شد که EAX رو GetProcAddress پر کرده بوده و توی ECX اشاره‌گر به رشته‌ی "BlockInput" بوده. یعنی با یه رزول پویا اومده بود تابع BlockInput رو گیر آورده، بدون اینکه توی IAT دربیاد.

BlockInput ورودی ماوس و کیبورد رو برای بقیه برنامه‌ها قطع می‌کنه. اینجا با PUSH 1 فعالش کرده بود. یه تکنیک رایج توی بدافزارها که نمی‌ذاره تحلیلگر راحت کار کنه. ولی با تموم شدن فرآیند یا Ctrl+Alt+Del برطرف می‌شه.

جالب اینجاست که استاتیک با Ghidra اینو نمی‌تونستم ببینم، چون اسم تابع رو موقع اجرا رزول می‌کرد. تحلیل دینامیک اینجا خیلی کمک کرد و بی‌سرمایه‌وقت اضافی به ته ماجرا رسیدم.

زبان سیگما یک استاندارد متن‌باز برای توصیف قواعد تشخیص تهدید در لاگ‌هاست که قابلیت ترجمه به فرمت‌های بومی SIEMهایی نظیر Splunk، Elasticsearch، QRadar و ArcSight را دارد و هدف آن یکپارچه‌سازی و اشتراک‌گذاری الگوهای حمله است. هر قاعده از سه بخش اجباری تشکیل می‌شود: عنوان (۱ تا ۲۵۶ کاراکتر، بدون شروع با "Detect")، منبع لاگ شامل Category (نوع لاگ)، Product (بستر عملیاتی) و Service (سرویس خاص) و در موارد پیچیده Definition، و بخش تشخیص با شرط Condition که ترکیبی از شناسه‌های رویداد، عبارات منظم یا مقادیر هش است. فیلدهای اختیاری شامل ID، Status، Description، Author، References، Fields، Falsepositives، Level و Tags (برای نگاشت به MITRE ATT&CK) هستند. نمونه قاعده CertUtil با عنوان Suspicious Certutil Command، وضعیت experimental، توضیحات مرتبط با زیردستور decode و ارجاع به منابع معتبر، نشان‌دهنده کاربرد عملی در شناسایی ابزارهای دوگانه‌سود است. مزایای اصلی شامل خودکارسازی جستجوی تهدید، استقلال از فروشنده، دقت بالا و قابلیت شخصی‌سازی است.

چالش‌ها شامل وابستگی به لاگ‌های ساختاریافته (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 و سرویس مش اهمیت پیدا میکنه اینا به عنوان پاسخ طبیعی به واقعیت ترافیک داخلییه

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