DevOps Expert General Group

درود به همه دوستان فرض کنید که یک repo دارین به اسم Node app میخواین با compose ببرین پروداکشن. الان این compose رو داخل خود repo مربوط به node app نگهداری کنیم منطقی تاره یا مثلا یک repo به اسم infra نکته اینه به خاطر speration of concern میگم. چون مثلا نمیخوام nginx config رو داخل repo مربوط به node app داشته باشم. بعد مثلا موقع deploy با cicd هم تو فکرم این هست که. از ریپو اصلی build push کنم. بعد کامپوز رو از ریپور مربوط به infra با scp بریزم رو vps. سوال بعد این که برای یک پروژه ساده dozzle استفاده کنم یا portainer. ممنونم اگر وقت بزارید و من رو راهنمایی کنید.

تو کامپوز هیچ اطلاعات حساس و مهمی نیست که بخوای نگرانش باشی بذارش همونجا بمونه الکی پیچیدش نکن مهم سکرت ها هست که به صورت فایل مثلا میدی بهش که این فایلم ایجنت cicdت بهش دسترسی داره فقط و موقع دیپلوی میدتش به برنامت فایل nginx.conf هم شما یه بار وب سرور رو میاری بالا مثلا با داکر رو همون سرور اصلیت و دایما در حال تغییر نیست و یه بار هست و شبکشو میدی به سرویس هات فقط و ربطی به کامپوزت نداره اصلا nginx. اگر هم ساده هست پروژه واقعا دازل کاملا ایده الشه و کارتو راه میندازه و واقعا هم راحته

پروژه ساده هست بیشتر حالت تمرینی داره برام یکم deployment بیشتر آشنا بشم. و چون developer هستم جدا کردن چیزایی که بهم ربط ندارن خیلی مهمه برام. حس میکنم یک infera repo باشه کار در میاد. فقط Dockerfile مربوط به هر قسمت داخل خودش باشه

کجا میتونم خدمات co-locate بگیرم با هزینه پایین؟ نیاز دارم ورک استیشن خودم رو راه اندازی کنم به صرفه نیست هزینه یک اسلات رک رو بدم (فکر کنم ماهانه بین 8 تا 15 هزینه یک اسلات هستش که اصلا به صرفه نیست برای ورک استیشن)

برادر تک یونیت بخوای بگیری باید ۷ ۸ تومن بدی دیگه از این کمتر نیست

کجا؟

اجازه بدید بپرسم من از یکی از دوستانم حتما اطلاع میدم رنج قیمتی رو

سر یکی از پروژه‌های پنتست متوجه شدم که روی تارگت، متد TRACE فعال بود. گفتم بد نیست کمی در موردش صحبت کنیم. متد TRACE چیه؟ یکی از متدهای HTTP (مثل GET، POST و ...) هست که برای Diagnostic و Debugging طراحی شده. وقتی یک درخواست TRACE به سمت سرور ارسال می‌کنیم، سرور (در صورت فعال بودن این متد) معمولاً همون درخواست دریافتی رو به‌همراه Headerهایی که در مسیر بهش اضافه شدن، در پاسخ برمیگردونه. مثال: TRACE / HTTP/1.1 Host: target.ir X-Test: VulnerabilityCheck نمونه پاسخ: HTTP/1.1 200 OK Content-Type: message/http TRACE / HTTP/1.1 Host: target.ir X-Test: VulnerabilityCheck Via: proxy.example.com X-Forwarded-For: 192.168.1.1 این رفتار میتونه اطلاعاتی درباره زیرساخت، Proxyها، Reverse Proxyها و برخی Headerهای اضافه‌شده در مسیر درخواست در اختیار ما قرار بده. آیا فعال بودن TRACE یک آسیب‌پذیریه ؟ نه، فعال بودن TRACE به تنهایی یک آسیب‌پذیری محسوب نمیشه؛ اما در اغلب سرویس های امروزی کاربرد عملی خاصی نداره و معمولاً توصیه میشه در محیط Production غیرفعال باشه تا سطح حمله (Attack Surface) کاهش پیدا کنه. تکنیک XST یا Cross-Site Tracing چیه؟ یک تکنیک قدیمی بود که از ترکیب TRACE و XSS استفاده میکرد. در برخی مرورگرهای قدیمی، این حمله می‌تونست باعث افشای اطلاعات حساسی مثل Cookieهای دارای فلگ HttpOnly بشه. الان مرورگرها ارسال درخواست TRACE از طریق JavaScript رو مسدود کردن؛ بنابراین سناریوی کلاسیک XST عملاً دیگه قابل بهره‌برداری نیست. با این حال، غیرفعال کردن TRACE همچنان یکی از توصیه‌های رایج Hardening محسوب میشه. بررسی فعال بودن TRACE با پایتون : import requests url = "https://target.ir/" headers = {"X-Test": "TRACE-CHECK"} response = requests.request("TRACE", url, headers=headers) if response.status_code == 200 and "X-Test" in response.text: print("TRACE method appears to be enabled.") else: print("TRACE method is disabled or not echoed.") این اسکریپت صرفاً بررسی میکنه که آیا سرور درخواست TRACE رو Echo میکنه یا نه و به تنهایی نشون دهنده وجود یک آسیب‌پذیری قابل بهره‌برداری نیست. @Ahura_Rahmani | #Ahur4 #HTTP #TRACE #XST #WebSecurity #PenetrationTesting