Hakluke به شما یاد می‌دهد که چگونه یک اتومیشن باگ بانتی بی‌نقص ایجاد کنیم.

Hakluke به شما یاد می‌دهد که چگونه یک اتومیشن باگ بانتی بی‌نقص ایجاد کنیم.

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

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

اقدام عملی #1 : بش (Bash)

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

نتیجه یک فایل بش 100 خطی شد که الگویی مثل الگوی زیر داشت.

#!/bin/bash
# Get subdomains and check for HTTP responses
cat rootdomains.txt | subfinder | tee subdomains.txt | httpx | tee httpx.txt
# Brute force all subdomains
cat httpx.txt | while read url; do
  dirsearch.py -e php,aspx,asp,txt,bak -u $url | tee ./bruteforce/$url-dirsearch.txt;
done
# Check all domains for open git repositories
cat httpx.txt | while read url; do
  if curl $url/.git/config | grep -q "\[core\]"
    then echo "Open .git repository at $url" | ./notify.sh
  fi
done
# Do another thing
cat httpx.txt | while read url; do
  # do another thing
done
Etc…

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

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

  • سرعت بسیار پایینی داشت
  • ذخیره کردن دیتا ها داخل فایل متنی کار درستی نیست.
  • هر عملیات ناموفقی که در ابزار رخ می‌دهد باعث توقف کار کل اسکریپت می‌شود.

دوباره به تخته سیاهم برگشتم…

اقدام عملی #2: Django

برای حل مشکلی که در رابطه با اسکریپت به وجود آمده بود، دوباره تصمیم به استفاده از یک چارچوب مناسب گرفتم. دراین مرحله، لاراول PHP چارچوبی بود که با آن احساس راحتی بیشتری داشتم، اما در آخر کار با Django را انتخاب کردم، چراکه اکثر ابزارهای مبتنی‌بر امنیت سایبری که درآن زمان از آن‌ها استفاده می‌کردم با پایتون نوشته شده بودند.

ذخیره داده

نحوه ساختار ذخیره سازی داده، اولین مشکلی بود که باید حل می‌شد. در آخر همه‌چیز را داخل یک پایگاه داده‌ رابطه‌ای (PostgreSQL) با استفاده از Django ORM ذخیره کردم. برای تطابق نحوه کار اشیا در واقعیت بین آن‌ها ارتباط برقرار کردم. که شبیه چیزی مثل شکل زیر شد:

اقدام عملی#2 ذخیره داده

با ارتباطاتی که بدین شکل راه ‌اندازی شوند، کوئری نوشتن برای پایگاه داده جهت پاسخ دادن به سوالات زیر بسیار آسان خواهد بود:

  • این URL به کدام برنامه مربوط می‌شود؟
  • پورت 3389 کدام زیردامنه باز است؟
  • روی زیردامنه domain.com چه آسیب‌پذیری‌هایی پیدا شده‌است؟

Django ORM به صورت پیشفرض داده‌های ایجاد شده و اصلاح شده در هرلحظه به صورت مداوم در پایگاه داده ذخیره می‌کند، به همین خاطر پرسش‌های مبتنی بر زمان را نیز می‌توان مطرح کرد:

  • در ساعات اخیر چه زیردامنه جدید دیگری کشف شده است؟
  • این هفته چه پورت باز دیگری کشف شده است؟

ساختار کد

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

برای مثال، من یک دستور مدیریتی به‌نام “subfinder” نوشتم که تمام دامنه‌های ریشه را از پایگاه داده بیرون می‌کشید، و “Subfinder” را برای آن‌ها اجرا می‌کرد، و نتایج زیردامنه‌ها را داخل پایگاه داده ذخیره می‌کرد.  برای اجرای این دستور مدیریتی داخل ترمینال دستوری شبیه دستور زیررا می‌نوشتم:

# run against all root domains in the database

django-admin subfinder

# run against all of Tesla's domains from the database

django-admin subfinder -program tesla

# run against example.com

django-admin subfinder -rootdomain example.com

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

در مورد زمانی صحبت می‌کنم که من  باcodingo_ و  sml555_برای ساختن یک پشته از ماژول‌های تشخیص آسیب‌پذیری همکاری می‌کردم. که در نهایت شاهد شروع بکار بانتی ها شدیم!

اما اینبار با یک مشکل دیگر روبه شدیم… این روش سرعت خیلی پایینی داشت.

سرعت و مقیاس

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

استفاده از Multi-Threading اولین کاری بود که انجام دادیم. برای مثال، به‌جای اینکه فقط دستورات را اجرا کنیم، که این دستورات subfinder را در برابر هر دامنه ریشه به صورت متوالی اجرا خواهد کرد:

django-admin subfinder

دراین مرحله از چیزی مثل  GNU parallel میتوانیم استفاده کنیم که به ما اجازه می‌دهد از sufinder در دامنه‌های چندگانه به صورت همزمان استفاده کنیم. برای مثال:

cat root-domains.txt | parallel -j 20 "django-admin subfinder -rootdomain "

همچنین اینجا جایی بود که ایده Interlace  متولد شد. دراین روش استفاده از چندنخی به میزان قابل توجهی، میزان زمان صرف شده برای تکمیل وظایف را کاهش داد. حالا ما 20 نمونه سابفایندررا به صورت همزمان اجرا می‌کنیم، VPS که از آن استفاده می‌کردیم ازلحاظ RAM و CPU کم می‌آورد. بااستفاده از VPS پرقدرت (مقیاس مجازی) این مشکل تا به صورت موقت قابل حل بود، ولیکن قدرتمنترین VPS هم به حدکافی قادر به اجرای تمام وظایفی که نیاز بود تا در چارچوب زمانی موردانتظار ما عمل کنند، نبود.

اینجا جایی بود که تصمیم گرفتیم تا نمونه‌های کم­قدرت را برای اجرای وظایف جایگزین کنیم، که این نمونه‌ها نتایج خود را به منبه داده مرکزی گزارش میدادند. اسم این روش مقیاس پذیری افقی است، که من زمانیکه آن را اجرا کردم اسم آن را نمی دانستم.

در اولین تلاشمان برای پیاده‌سازی این روش، به صورت خیلی ناشیانه یک “کار(JOB)” ایجاد کردیم که داخل پایگاه‌داده PostgreSQL کار شده بود. سپس یک کلاینت کارگر ایجاد کردیم که به صورت مداوم درحال بازگردانی و اجرای یک کار بود، و درآخرخروجی را به پایگاه داده بازگشت می‌داد. زمانیکه شروع کردیم، متوجه شدیم که همه‌جا شرایط رقابتی به وجود آمده است. اکثر کلاینت های کارگر درآخر کارهای یکسانی را به صورت همزمان اجرا می‌کردند، و هر کار بالغ بر10 بار اجرا می‌شد. برای جبران، قفل کردن پایگاه داده را امتحان کردیم، ولیکن این کار باعث شد تا سرعت فرآیند بسیار کم شد که دوباره مارا مجبور کرد تا به روش مقیاس پذیری مجازی مان برگردیم.

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

من هم همان مفهوم صف به جای PostgreSQL داخل RabbitMQ استفاده کردم، و در کمال ناباوری کار انجام شد! کلاینت های کارگر را تا 100 کارگر افزایش دادیم و شاهد آن بودیم که در کسری از ثانیه قادر به اجرای ریکان و اسکن آسیب‌پذیری تمام دارایی‌های باگ بانتی بودیم. درکنار هم، تعداد زیادی باگ کشف کردیم، چرا که جزاولین افراد فعال در زمینه شکارباگ بانتی بودیم. حتی اسکن باگ های دم دستی هم پاداش به همراه داشت، چراکه ما همیشه جز اولین نفراتی بودیم که هاست ها را در زمان قرار گرفتن در موقعیت آسیب‌پذیری کشف می‌کردیم. قیمت کلاینت های کارگر معادل 5دلار VPS بود و اینگونه ما سرورهای قدرتمندتری برای عملکردهای هسته‌ای داشتیم. درآخر کلافگی ما با چیزی شبیه به این جایگزین شد:

اقدام عملی 2

بااین‌حال سیستم ما بی‌نقص نبود:

  • پایه کد ما یکپارچه بود و راه‌اندازی آن بسیار زمانبر بود.
  • ابزار بدون توسعه ماژول‌های سفارشی با بقیه ابزارها قابل ادغام نبود، که این مساله نیز بسیار زمانبر بود.
  • زمانیکه کلاینت‌های کارگر از اتمام کارشان باز می‌ماندند، تشخیص و مانیتورکردن کارها سخت میشد.

درنهایت، هرسه ما در Bugcrowd مشغول شدیم، و اینگونه شکار باگ و اتومیشن دیگر اولویت اصلی ما نبودند و زمانیکه دیگر وقتی برای تمرکز روی آن ها نداشتیم به صورت آفلاین گاها روی آن ها کار می‌کردیم.

اقدام عملی #3: Golang و فلسفه Unix

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

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

انجام اسکن برای کشف باگ های دم دستی دیگر منفعتی برای من نداشت، اما به نظر من استفاده از اتومیشن برای آزمودن بارهای سفارشی و نگهداری و به روزرسانی لیست اهداف که شامل پورت‌های باز، فناوری‌های استفاده شده و … بود هنوز هم کاربردی بود. مشکل ما اینجا بود که مجموعه Django موجود تقریبا از مد افتاده بود، مخصوصا زمان‌هاییکه میخواستم کاری را سریعا و به صورت سفارشی انجام دهم این مشکل بیشتر خودش را نشان میداد. به جای یک دسته ابزار جدا از هم برای اجرای سریع وظایف سفارشی، من یک ابزار گنده داشتم که هرکاری را به تنهایی انجام میداد، و باهیچ ابزار دیگری به خوبی ادغام نمیشد.

من اغلب خودم را در حال استفاده از ابزارهای دستی‌ای که پیرو فلسفه Unix بوندند پیدا می‌کردم، مثل httpx  و nuclei. این باعث شد تا به راحتی بااستفاده از اتصال ابزارها به یکدیگر یک جریان کار سفارشی درست کنم. بدبختانه، با انجام اینکار، فرصت سازماندهی داده های خودم را در یک پایگاه داده رابطه‌ای و بسط آن ها روی هاست های چندگانه را از دست دادم.

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

  1. یک سیستم برای ذخیره‌سازی و بازگردانی داده از پایگاه داده
  2. یک سیستم برای مدیریت بسط کارها
  3. یک سیستم برای اسکن آسیب‌پذیری‌ها
  4. یک سیستم برای آلارم دادن زمانیکه چیزی کشف شده است.

خوشبختانه، راه‌حل‌های خوبی برای موارد 3 و 4 وجود دارد (کشف پروژه‌های Nuclei و Notify). تنها برای موارد 1 و 2 باید یک راه‌حل سفارشی بسازم- که درواقع این کار را انجام داده‌ام!

Hakstore

ابتدا من “Hackstore” را ساختم، یک سرور REST API و کلاینت‌ همراه آن به زبان Golang برای برقراری ارتباط با پایگاه داده. این به شما اجازه می‎‌دهد تا سریعا داده را از پایگاه داده رابطه‌ای ایجاد/ ویرایش/ پاک کنید. برای مثال، این خط دستور تمام زیردامنه‌های مرتبط با برنامه تسلا را لیست خواهد کرد.

لیست زیردامنه‌های هک‌استور- برنامه تسلا

بااستفاده از این دستورمی‌توانید تمام زیردامنه‌ها از یک فایل برداشته و به پایگاه داده اضافه کنید، و آن‌ها را با دامنه ریشه “tesla.com” همراه کنید.

hakstore subdomains import -f subs.txt -rootdomain tesla.com

این دستور باعث پاک شدن برنامه از پایگاه داده خواهد شد.

hakstore programs delete -id tesla

Hakscale

بعدا یک ابزار خط دستوری ساختم که برای بسط دستورات شل روی سیستم‌های بیشتر طراحی شده بود. نام “Hackscale” را برای آن انتخاب کردم. اگر با Interlace آشنا هستید، این ابزار هم تقریبا مثل آن کار می‎کند، با این تفاوت که این ابزار به جای توزیع نخ های چندگانه برروی سیستم، دستورات چندگانه را در سیستم ها توزیع می‌کند. این ابزار را با زبان Golang نوشتم و از واسط پیام Redis برای توزیع دستورات استفاده کردم.

اجرای دستوریکه در ادامه آمده لیست URL ها را از urls.txt گرفته و سپس با جایگزین کردن URL واقعی با محل قرارگیری آن، برای هر URL یک دستور ایجاد می‌کند. تمام این دستورات بعدا به صف موجوددر سرور Redis فرستاده می‌شوند.

hakscale push -p “url:./urls.txt” -c “echo _url_ | nuclei -nc –config /opt/config.yml” -t 600

سپس، دسته ای از VPS های “کارگر” را داریم، که هرکدام دستور زیر را اجرا می‌کنند:

hakscale pop -t 20

این دستور 20 عدد نخ ایجاد می‌کند، هرنخ به صورت مداوم کارها را از صف Redis “کارها” بیرون می‌کشد، اجرا می‌کند و سپس نتایج آن‌ها را به صف “نتایج” بازمی‌گرداند. این صف نتایج توسط VPS اصلی که کار را اجرا کرده مانیتور و بررسی می‌شود. زمانیکه نتیجه را داخل صف می‌بیند، روی ترمینال آن را چاپ می‌کند. برای افرادیکه به‌صورت بصری راحت تر یاد می‌گیرند، شکل زیر را ترسیم کرده‌ام:

Radis VPS

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

گردآوری کامپوننت‌ها

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

بااین حال، سیستم بی‌نقصی نبود- درواقع من به تازگی تمام زیرساخت را به صورت آفلاین راه‌اندازی کرد‌ام.

  • 100 VPS کلاینت کارگر به صورت 24/7 در حال اجرا بودند، که ماهانه هزینه‌ای بالغ بر 500$ برای من داشت، و این درصورتی بود که من از آنها برای کسری از زمان استفاده کرده بودم.
  • توصیف اینکه دستورات ناموفق بودند سخت بود.
  • اگر کارها خوب پیش نرفت و مشکلی پیش آمد (برای مثال، بخاطر مشکل موقت به وجود آمده در شبکه یکی از نتایج به صف بازنگشت)، هیچ پیامی مبنی بر وجود مشکل دریافت نمیکردم و هیچ راه‌حلی برای مشکل به وجودآمده نداشتم.

*آه*

اقدام عملی #4:Cloud Native

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

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

  • کارگران به‌عنوان محفظه‌های Docker ساخته شده‌اند، که توسط AWS Fargate و AWS Elastic Container Service (ECS) مدیریت می‌شوند.
  • کلاینت‌های کارگر به صورت خودکار براساس تعداد موارد موجود در صف کار ظرفیت خود را افزایش می‌دهند. اینگونه من مطمئن می‌شوم که درزمان نیاز، کلاینت‌های کارگر زیادی در دسترس من خواهند بود، اما زمانیکه دیگر به آنها نیازی ندارم کشته خواهند شد. این عمل به صورت بالقوه سریعا بااستفاده از محیط کارگری Elastic Beanstalk قابل اجرا است.
  • از EFS برای به اشتراک گذاشتن فایل‌ها بین تمام مخازن (فایل‌های پیکربندی، ابزارها و …) استفاده خواهد شد.
  • از سرویس صف نمونه آمازون (Amazon Simple Queue Service (SQS)) برای مدیریت کارها استفاده می‌شود. از یک سیستم درخواست-پاسخ برای ارسال کارها و دریافت نتایج استفاده شده است. از یک صف نامه مرده (Dead Letter Queue(DLQ)) برای کشف کارهای ناموفق استفاده می‌شود.
  • از Amazon Aurora برای ذخیره‌سازی داده‌های رابطه‌ای استفاده می‌شود.

ابزارHackstore من تابه‌حال از زمانیکه با PostgreSQL تطابق پیدا کرده‌است، با Amazon Auror به خوبی اجرا شده‌است. حالا من فقط باید این بازار را به صورتی اصلاح کنم که به جای Redis با SQS کار کند، که آن هم کار بسیار سختی نیست.

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

در مقاله های بعدی بیشتر به اینمورد خواهم پرداخت.

نتیجه‌گیری

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

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

درآخر، من همیشه آماده صحبت کردن درمورد اتومیشن باگ بانتی هستم. اگر دراین زمینه مشکلی دارید می توانید بامن در ارتباط باشید.

Detectify؟

دراین مقطع، Detectify برای شکارچیان باگ بانتی جالب توجه نیست، اما آنها باگ بانتی و اتومیشن را برای ابزار مدیریتی سطحی باهم ادغام کردند. اگر شما یک سازمانی هستید که به دنبال اجرای چنین اسکن هایی برای حفاظت از سازمانتان هستید، Detectify گزینه مناسبی برای شما می‌تواند باشد. Detectify یک راه‌حل مدیریتی سطحی حمله خارجی اتومیشن شده است که توسط انجمن هکرهای اخلاقی World-leading ساخته شده‎‎‌است. این راه حل به تیم امنیتی این امکان را می‌دهد تا کل سطح حمله را ترسیم کنند و یک رویکرد کنش‌گر برای حل آسیب‌پذیری‌های داخل کل اکوسیستم IT، با دربرگرفتن نرم افزارهای تحت تاثیر شخص سوم اتخاذ کنند.

منبع

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *