فرض کنیم که شما داکرفایل خودتون رو ساختید، کانتینرتون رو هم در محیط توسعه آزمایش کردید و منتظر اتمام مراحل CICD هستید. 

فرض کنیم که مراحل CICD هم به خوبی به اتمام رسیده و آزمایش‌های یکپارچگی و عملکردی هم انجام شده و همه‌ی آزمایش‌کنندگان هم برای محصول شما تایید دادند.

بعد از گذشت این مراحل، فکر می‌کنید محصول شما برای تولید و حضور در بازار رقابتی آماده است؟

جواب ما منفی است. یعنی حداقل باید بگیم که نه! به این زودی‌ها محصول شما آمادگی حضور موفق در بازار رو نداره.

ارث‌بری لایه‌های ایمیج داکر

هر دسته‌ای از فایل‌ها که به یک ایمیج داکر اضافه می‌شن، باعث اضافه شدن یک لایه‌ی جدید به اون ایمیج می‌شن. ایمیج داکر تشکیل شده از مجموعه‌ای از این لایه‌ها که با ترتیبی که ایجاد شدن در کنار هم قرار گرفتند.

وقتی  در داکرفایلتون با استفاده از FROM یک ایمیج ایجاد می‌کنید که از ایمیج دیگری ارث برده هم این قانون برقراره! یعنی ایمیج نهایی شما شامل تمام لایه‌های ایمیج والد به علاوه‌ی لایه‌هایی هست که بعدا به اون اضافه کردین.

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

اگر ایمیج والدی که استفاده می‌کنید خودش دارای ایمیج والد دیگری باشه چی؟
اگر اون ایمیج والد بعدی خودش ایمیج والد دیگری داشته باشه چی؟
و به همین ترتیب…

فرض کنین انتهای این ایمیج‌های والد برسه به ایمیج اصلی پایه‌ای مثل اوبونتو یا آلپاین!

قضیه اینه که شما تعداد خیلی خیلی زیاد لایه‌هایی رو به ارث بردین که حتی متوجه اون‌ها نشدین و ندیدینشون، چه برسه به اینکه بخواین و بتونین اون‌ها رو کنترل کنین!

سوال و مساله‌ی اصلی اینه:

اگر هر کدوم از این لایه ها از نظر امنیتی دارای آسیب پذیری باشن چه اتفاقی پیش میاد؟

در ادامه‌ي این مقاله با هم بررسی می‌کنیم که چجوری می‌شه این آسیب پذیری‌ها رو کشف کرد.

اما قبل از اون توضیح می‌دیم که منظورمون از آسیب‌پذیری امنیتی دقیقا چیه؟

آسیب پذیری امنیتی

همونطور که می‌بینید در قسمت سمت چپ تصویر (openjdk:8-jre image) لایه‌های مختلفی وجود دارند.
در قسمت سمت راست تصویر هم می‌تونین فایل‌های مختلفی که توی این ایمیج قرار داره رو ببینید. 

بسیاری از این فایل‌ها، فایل‌های اجرایی هستند و مستعد مبتلا شدن به آسیب‌های امنیتی!

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

در یک دید وسیع‌تر اما، ویروس خودش به تنهایی می‌تونه یک نوع آسیب پذیری امنیتی به حساب بیاد. 

ویروس رایانه‌ای، یک نوع برنامه‌ی کامپیوتریه که اگر بتونه اجرا بشه، وارد کد برنامه‌های دیگه میشه و کد مخصوص به خودش رو داخل اون‌ها تکرار می‌کنه و به این ترتیب تکثیر پیدا می‌کنه.

اگر این تکثیر موفقیت آمیز باشه، اصطلاحا می‌گیم برنامه‌‌ها آلوده به ویروس رایانه‌ای شدن!

اما منظورمون از آسیب پذیری امنیتی، ویروس‌ها نیستند!

آسیب پذیری امنیتی معمولا در سورس کدهای خوبی وجود دارد که نقص‌های فنی یا منطقی دارن! در نتیجه این مساله باعث میشه که در سیستم یک ضعف وجود داشته باشه و این امکان پیش بیاد که بقیه بتونن از سیستم سو استفاده کنن.

این آسیب پذیری‌ها ممکنه سال‌های سال کشف نشن و شاید تا روزی که بتونین از روی خوش شانسی اون‌ها رو پیدا کنین، همونطور کشف نشده باقی بمونن!

پایگاه داده‌های آسیب پذیری

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

در حال حاضر پایگاه‌داده‌های مختلفی در این زمینه وجود داره که برای چنین اطلاعیه‌های عمومی ایجاد شده و استفاده می‌شن! مثل: CVE ،NVD و VULDB

اسکن استاتیک آسیب پذیری داکر

اگر بخوایم یک جمع‌بندی بکنیم که ببینیم تا الان چه چیزایی گفتیم، توی این دو جمله خلاصه میشه:

• یک ایمیج داکر تشکیل شده از لایه‌های مختلفی که هر کدوم فایل‌ها و برنامه‌های اجرایی مختلفی دارند.
• آسیب پذیری‌های امنیتی کد اصلی فایل‌های اجرایی یا کتابخانه‌ها در پایگاه‌داده‌هایی آنلاین و به صورت عمومی نگه‌داری میشه.

اگر این دو مورد رو کنار هم قرار بدیم و بخوایم ازشون یک نتیجه‌گیری داشته باشیم، به چی می‌رسیم؟

آیا می‌تونیم فایل‌های اجرایی که در لایه‌های مختلف ایمیج داکرمون قرار داره رو با آسیب پذیری‌های امنیتی که در پایگاه‌داده‌های آنلاین گزارش شده و نگه‌داری میشه بررسی کنیم و تهدیدها رو شناسایی کنیم؟

بیاین با هم امتحانش کنیم!

موتور Anchore

ابزارهای Open-Source و تجاری مختلفی برای اسکن آسیب پذیری فایل‌ها وجود داره.
این ابزارها می‌تونن به عنوان بخشی از فرآیند CICD قرار گرفته و اجرا بشن. حتی این امکان وجود داره که این ابزارها به رجیستری ایمیج متصل بشن و ایمیج‌های جدید رو اسکن کنن.

از نمونه‌هایی از این ابزارها میشه به موارد زیر اشاره کرد:

• Clair
• Dadga
• Nexus Repository Pro
• Black Duck
• Qualys
• Harbor
• Twistlock

اما در بین این‌ها ما می‌خوایم توی این پست نحوه‌ی استفاده از ابزار Anchore  رو آموزش بدیم. Anchore از یک نسخه‌ی تجاری (Anchore Enterprise) و یک نسخه‌ی Open-Source به نام (Anchor Engine) تشکیل شده.

Anchor مشتری های چشمگیری مانند Cisco ، eBay ، Atlassian ، Nvidia و RedHat داره!نسخه‌ی تجاریش برای شما امکاناتی از قبیل UI پیشرفته، RBAC و پشتیبانی رو فراهم می‌کنه.

اما ما اینجا می‌خواهیم در مورد Anchor Engine یعنی نسخه‌ی Open-Sourceش صحبت کنیم.

نصب

Anchore Engine به عنوان مجموعه‌ای از ایمیج‌های داکر ارائه می‌شه که هم می‌تونن به تنهایی اجرا بشن و هم با استفاده از پلتفرم‌هایی مثل Kubernetes ، Docker Swarm و Amazon ECS.

شما می‌تونین نسخه‌ی محلی Anchore Engine رو با استفاده از Docker Compose و خط زیر به سرعت Boot کنین:

curl https://raw.githubusercontent.com/anchore/anchore-engine/master/docker-compose.yaml | docker-compose -p anchore -f - up

Docker-compose.yaml پنج کانتینر ایجاد می‌کنه و بعد از اون سعی می‌کنه به پایگاه‌داده‌ی آسیب پذیری دسترسی پیدا کنه و داده‌های اون رو به دست بیاره. به همین دلیل دستور بالا ممکنه یه مقداری طول بکشه!

اجرای کلاینت

Anchor Engine از طریق Command-Line کلاینت قابل دسترسیه!

همچنین به راحتی می‌تونین CLI کلاینت رو از طریق یک ایمیج داکر دیگه اجرا کنین:

docker run --rm -e ANCHORE_CLI_URL=http://anchore_engine-api_1:8228/v1/ --network anchore_default -it anchore/engine-cli

حالا شما به Anchor CLI کلاینت دسترسی دارین و می‌تونین یک دستور آزمایشی مثل anchore-cli --version رو اجرا کنین:

ورود به ایمیج داکر

Anchore Engine در دو مرحله گزارش ارزیابی آسیب پذیری را برای شما فراهم می کند. 

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

البته توجه داشته باشین که برای بارگیری و اسکن ایمیج باید مدت زمانی صرف بشه!

در مثالی که در ادامه آوردیم از یک ایمیج وردپرس قدیمی استفاده کردیم! می‌خوایم آسیب پذیری های این ایمیج رو بررسی کنیم.

اگر قصد استفاده از وردپرس با استفاده از داکر رو دارید، حتما از یک نسخه‌ی جدید ایمیج استفاده کنید.

خب حالا وقتش رسیده که اولین ایمیج داکر رو با استفاده از CLI کلاینت اضافه کنیم:

anchore-cli image add wordpress:4.6.0 && anchore-cli image wait wordpress:4.6.0

با استفاده از دستور بالا ما یک ایمیج جدید برای تحلیل و بررسی اضافه کردیم.
حالا باید منتظر باشیم تا گزارش Anchor از بررسی این ایمیج کامل بشه و پیام زیر رو بده:

مشاهده‌ی آسیب پذیری‌ها

برای مشاهده‌ی آسیب پذیری های کشف شده می‌تونین از دستور زیر استفاده کنین:

anchore-cli image vuln wordpress:4.6.0 all

توی این ایمیج قدیمی که ما استفاده کردیم، آسیب پذیری های زیادی کشف شده که می‌تونین توی عکس زیر ببینین:

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

اگر شما از چنین ایمیجی استفاده کردین، پیشنهاد می‌کنیم که Release رو تا زمانی که آسیب پذیری‌ها بررسی بشن، متوقف کنین!

نتیجه‌گیری

نرم‌افزارها هنوز توسط انسان‌ها نوشته می‌شوند و انسان‌ها هم همواره اشتباه می‌کنند.

با علم به این موضوع نباید اجازه بدیم که اشتباهات به برنامه‌های شما آسیب برسونند.

بهتون پیشنهاد می‌کنیم از یک اسکنر آسیب پذیری امنیتی برای ایمیج‌های داکرتون استفاده کنین و مشکلات رو از قبل شناسایی و برطرف کنین!

تشخیص آسیب پذیری امنیتی رو به عنوان بخشی از فرآیند پایپ‌لاین CICD قرار بدین و قوانینی رو ایجاد کنین که تا زمان برطرف شدن آسیب پذیری‌ها جلوی انتشار برنامه گرفته بشه!

منبع