گیک آزاد

Free/Geek/Life.sh

ترمینال Guake با دو مانیتور

نویسنده:
۱۶ آبان ۹۳

از بین ترمینال امولاتورهایی پایین افتادنی یا Drop-down Terminal Emulatorها (که از بالای صفحه به پایین باز میشه)، من guake رو به بقیه ترجیح میدم و باهاش راحت‌ترم. البته Tilda رو هم دوست دارم ولی Yakuake رو بخاطر ظاهرش نمی‌پسندم. اما قضیه از اینجا شروع شد که من تصمیم گرفتم دوال مانیتور کنم به این صورت که یک مانیتور بزرگ دیگه به لپ‌تاپم وصل کنم. همه چیز به خوبی انجام شد و فقط ترمینال guake بود که با وجود primary output کردن مانیتور جانبی همچنان اصرار داشت که روی ال‌سی‌دی لپ‌تاپ اجرا بشه. وقتی درباره این مشکل در اینترنت جستجو کردم پست‌های زیادی پیدا کردم که خیلی کار رو پیچیده کرده بودن مثلا اینکه برو guake رو دوباره به این شکل کامپایل کن و یکسری جفنگیات دیگه. خودم دست به کار شدم و رفتم سراغ تنظیمات guake. از قضا این ترمینال امولاتور با پایتون هم نوشته شده و قسمت‌هاییش هم با C. با سر و کله زدن‌های زیاد و سعی و خطا بالاخره با طی کردن قدم‌های زیر این مشکل رو حل کردم.

guake terminal emulator

و اما مراحل انجام کار:

۱-با ادیتور دلخواه خودتون فایل تنطیمات guake رو که در مسیر زیر قرار داره باز کنید(حتما با روت):

۲-  عبارت Find the function “get_final_window_rect(self)” رو جستجو و پیدا کنید(خط اول در پایین):

۳- عبارت “screen.get_monitor_geomentry(0)“ رو که پارامتری است برای پیدا کردن رزولوشن native مانیتور ۰ یعنی جایی که ترمینال guake در اون اجرا میشه رو جستجو و پیدا کنید. شما باید این مقدار را به تعداد مانیتورهایی که دارید تغییر دهید. اگر دو مانیتور دارید باید بجای ۰ اون رو به ۱ تغییر بدید و اگر ۳ مانیتور دارید باید این مقدار رو ۲ تنظیم کنید و … . من چون ۲ مانیتور داشتم، این مقدار رو از ۰ به ۱ تغییر دادم.

۴- پارامتر “window_rect.y = 0″ رو هم جستجو و پیدا کنید. این پارامتر رو باید به این شکل اصلاح کنید:

  • کلمه y را بهx تغییر دهید.
  • بجای مقدار ۰ باید جمع رزولوشن‌های مانیتورها رو بنویسید. یعنی اگر از دو مانیتور استفاده میکنید باید رزولوشن مانیتور اول رو با رزولوشن مانیتور دوم جمع بزنید و حاصل رو بجای ۰ برای این این پارامتر تنظیم کنید. مثلا من یک مانیتور با زرولوشن ۱۹۲۰×۱۰۸۰ داشتم و رزولوشن ال‌سی‌دی لپ‌تاپ هم ۱۳۶۶×۷۶۸ بود. جمع دو مقدار اول یعنی ۱۳۶۶+۱۹۲۰ که مساوی با ۳۲۸۶ میشه رو بجای ۰ در پارامتر بالا ست کردم.

۵- تغییرات رو ذخیره کنید و خارج شوید. کافیه یکبار guake رو کاملا ببندید و دوباره اجرا کنید. guake به خوبی و خوشی در مانیتور دوم اجرا میشه. (:

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

درباره شل‌شوک و آسیب‌پذیری‌های امنیتی خطرناک در شل Bash

نویسنده:
۴ مهر ۹۳

 

shellshock

خلاصه داستان:

به تازگی آقای استفان شازلاس اهل فرانسه، یک حفره امنیتی بسیار خطرناک در شل GNU Bourne Again یا به اختصار bash که یک شل رایج و محبوب در سیستم‌عامل‌های شبه‌یونیکسی از قدیم تا به امروز هست، کشف کرده که اسمش رو shellshock گذاشته (یاد بازی shellshock از کمپانی Eidos بخیر!) و میتونه دردسرهای بزرگی ایجاد کنه و سیستم‌عامل‌های شبه یونیکسی مانند گنو/لینوکس و همچنین Apple OSX که بصورت پیشفرض از شل bash استفاده میکنند، در برابر حملات از طریق این حفره امنیتی (بصورت remote exploit) آسیب‌پذیرند.خوشبختانه به لطف متن‌باز بودن، بلافاصله بعد از اعلام این آسیب‌پذیری، سریعا یک اصلاحیه برای قسمت اول از حفره‌های امنیتی شل bash منتشر شده و نسخه اصلاح شده در اکثر مخازن نرم افزاری قرار گرفته و تمامی نسخه‌های حال حاضر bash موجود در مخازن نرم‌افزاری اکثر توزیع‌های اصلی از نسخه ۳.۰ تا ۴.۳ نسخه‌های اصلاح شده هستند و توزیع‌های بزرگی مانند دبیان (و زیرشاخه محبوبش مثل اوبونتو) و ردهت این نسخه‌ها را بصورت پکیج آماده در مخازن ارائه کرده‌اند که میتوانید به سادگی به روز رسانی را انجام بدهید ولی اپل تا این لحظه هنوز فکری به حال این باگ امنیتی خطرناک نکرده است. این اصلاحیه شامل قسمت دوم حفره‌های امنیتی شل bash که با استفاده از اون مهاجمین میتونن فایل‌ها رو بر روی سیستم هدف بازنویسی (overwrite) کنند نمیشه و برای این حفره دومی هنوز اصلاحیه‌ رسمی منتشر نشده.

وضعیت امنیتی پس از اعلام عمومی این آسیب‌پذیری چطوره؟

شرگت‌های امنیتی گزارش میدن که حملات بر پایه shellshock بطور فزاینده‌ای در حال گسترشه و حتی بات‌نت‌هایی که حملات DDOS انجام میدن، این حفره امنیتی رو هم میتونند چک کنند! یک محقق امنیتی هم دست به کار شده و یک اسکنر نوشته که روی اینترنت شروع کرده به اسکن کردن و پیدا کردن سرورهایی که نسبت به این حفره امنیتی نفوذپذیرند. این محقق در یک اسکن خلاصه‌وار حدودا ۳۰۰۰ سرور رو که نفوذپذیر هستند پیدا کرده که روی پورت ۸۰ (پروتکل HTTP) نفوذپدیرند. این حفره امنیتی در رده بسیار خطرناک رده‌بندی شده و پتانسیل تخریب بسیار بالایی داره. از آنجا که گستره توزیع این آسیب‌پذیری بسیار بزرگه، حتی از اشکال امنیتی خون‌ریزی قلبی (Heartbleed) نیز خطرناکتر محسوب میشه. محققان امنیتی ابراز نگرانی کردند از اینکه این حفره امنیتی میتواند برای هدف قرار گرفتن وب‌سرورهای عمومی بوسیله کرم‌های اینترنتی و بات‌نت ها مورد استفاده قرار بگیرد و این کرم‌های اینترنتی به راحتی از طریق پورت ۸۰ از فایرال رد شده و به راحتی به بسیاری از سیستم‌ها دسترسی پیدا خواهند کرد. این سناریو را در نظر بگیرید که این کرم‌های اینترنتی پس از رد شده از فایروال به سرور DHCP برسند و در آن لحظه بطور خلاصه Game is over!

مکانیزم عملکرد ShellShock چطوره؟

مکانیزم عملکرد این آسیب‌پذیری امنیتی از وجود ضعف در ارزشیابی و پاس دادن متغیرهای محیطی که از طریق سیستم‌عامل یا اپلیکیشن‌هایی که شل bash را فرا میخوانند ناشی میشه. به این صورت که یک هکر میتونه از راه دور و از طریق این ضعف امنیتی، یک متغیر محیطی ایجاد و سپس فرمان‌های مخرب رو روی سیستم‌عامل قربانی اجرا کند. البته شل‌های دیگه نظیر zsh و … از این آسیب‌پذیری در امان هستند.
این سناریو را در نظر بگیرید که اگر یک وب‌اپلیکیشن، یک فرمان شل bash را از طریق Http صدا بزند و یا از CGI که به کاربر اجازه وارد کردن دیتا میدهد برای فراهم کردن محتوای دینامیک (از طریق mod_cgi و mod_cgid) استفاده شود، در این صورت وب سرور به راحتی قابل نفوذ خواهد بود چون میتوانید با یک درخواست ساده از طریق وب و هدف قرار دادن اپلیکیشن CGI که میتواند روی سرور فرمان اجرا کند به آن نفوذ کنید.

این آسیب‌پذیری بر روی بسیاری از اپلیکیشن‌های وب که مقادیر ورودی کاربر را ارزشیابی و سپس یک کد شل را برای اجرا صدا میزنند میتواند تاثیرگذار باشد. در نظر بگیرید که یک اپلیکیشن یک اسکریپت بش را با یوزر root اجرا کند، عمق فاجعه قابل تصور خواهد بود! اگر کمی عمیق‌تر فکر کنیم میرسیم به کنترل‌پنل‌هایی مانند CPanel که بوسیله بسیاری از فراهم‌کنندگان خدمات هاستینگ استفاده میشود و اسکریپت‌های CGI روی آن (/cgi-sys/defaultwebpage.cgi)
همچنین اگر شل bash به عنوان شل پبشفرض سیستم پیکربندی شده باشد میتواند توسط هکرها بوسیله حملات تحت شبکه علیه سرورها و تجهیرات یونیکس/لینوکسی از طریق درخواست‌های تحت وب، ssh, telnet یا هر برنامه دیگری که از شل bash برای اجرای اسکریپت‌ها بهره میبرد استفاده شود و بسیاری از سناریوهای دیگر برای حمله.

shellshock test
چظور میتونم بفهمم سیستم من در برابر shellshock آسیب‌پذیره؟
اگر از گنو/لینوکس (سرور یا دسکتاپ) و یا Apple OSX استفاده میکنید، یک تست ساده وجود داره که میگه آیا سیستم در مقابل این حفره امنیتی نفوذپذیر است یا نه. برای انجام این تست، کد زیر را در خط فرمان اجرا کنید:

اگر سیستم مورد نظر نفوذپذیر باشد خروجی فرمان بالا به این صورت خواهد بود:

و اگر حفره امنیتی اصلاح شده باشد خروجی به این صورت خواهد بود:

 چه کار کنیم تا از شر این حفره امنیتی در امان باشیم؟

هرچه سریعتر شل bash رو آپدیت کنید.برای این کار:

در دبیان و توزیع‌های مبتنی بر دبیان:

و در ردهت و توزیع‌های مبتنی بر ردهت:

در آرچ و توزیع‌های مبتنی بر آرچ:

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

فقط توجه کنید که صرفا بروزرسانی شل bash کافی نیست. نکاتی وجود دارد که رعایت کردن آنها باعث بالا رفتن سطح امنیت خواهد شد.چند پیشنهاد:

  • ابتدا به سراغ اپلیکیشن‌های تحت وب بروید و مقادیر ورودی که این اپلیکیشن‌ها ارزیابی میکنند را بررسی کنید و تا جای ممکن این مقادیر را فیلتر کنید تا از حملات XSS و تزریق SQL نیز تا حدود زیادی در امان باشید.
  • مورد بعدی غیر فعال کردن اسکریپت‌های CGI است که شل را صدا میزنند. واقعا نیازی نیست در قرن ۲۱ هنوز از این روش قدیمی برای تعامل با وب‌سرویس‌ها استفاده کنید! اسکریپت‌های CGI را از همین لحظه برای همیشه با اپلیکیشن‌هایی که با real application language ایجاد شدن جایگزین کنید.
  • از شل bash به یک شل بهتر و مدرن‌تر مانند ZSH مهاجرت کنید. البته باید بدانید در این راه پیچیدگی‌هایی نظیر مشابه نبودن سینتکس‌ها وجود دارد و اینکه ممکن است همه ویژگی‌ها (features)ی مشابه را نداشته باشید ولی به امتحانش می‌ارزد.

نکته:
ناگفته نماند که OpenSSH هم با استفاده از متغیرهای AcceptEnv, TERM, و SSH_ORIGINAL_COMMAND آسیب‌پذیر خواهد بود اگرچه برای دسترسی به آنها نیاز به بودن در یک جلسه تصدیق شده (authenticated session) است ولی امنیت بیشتر خواهد بود اگر کاربران non-administrative را در مقابل استفاده از OpenSSH مسدود کنید تا زمانی که لایه‌های زیری مشکل شل bash نیز اصلاح شوند.

و در انتها:

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