نوشته های رضا کرامتی

حریم امن

رضا کرامتی — Wed, 25 Mar 2020 15:10:12 +0430

همه‌ی ما توی بخش‌های مختلف زندگیمون تلاش کردیم و یه سری حریم امن (ترجمه‌ی نه‌چندان خوب Comfort Zone) برای خودمون ساختیم. این حریم امن ممکنه رابطه، شغل، سابقه‌ی تحصیل یا هر چیز دیگه‌ای باشه که چندین سال برای ایجادش زحمت کشیدیم و آجر روی آجر گذاشتیم.حریمای امن خیلی خوب هستن، اصولا بدون وجودشون، به هیچ‌چیز و هیچ‌کس نمی‌تونیم اتکا کنیم و زندگیمونو جلو ببریم. اما در عین حال می‌تونن آسیب‌زا باشن. چه جوری؟ما آدما از تغییر ترس داریم و این ترس ممکنه باعث بشه توی حریم امنی که برای خودمون ساختیم گیر کنیم - حتی اگه توی حریم امنی که ساختیم کلی مشکل وجود داشته باشه و ازش ناراضی باشیم - .من فک میکنم این ترس ناشی از یک اشتباه منطقیه. ما آدما فک می‌کنیم با تغییر شرایط، تموم دستاوردهایی که داشتیم از بین می‌ره و چندین سال عمرمون تلف شده، پس ترجیح می‌دیم تو شرایط فعلی ادامه بدیم. هر چه قدر هم که بیشتر به موندن داخل حریم امن ادامه بدیم این ترس بیشتر می‌شه و به اصطلاح یه فیدبک مثبت به وجود میاره.درستش اینه که دستاوردای اصلی ما چیزای دیگه‌ای هستن. مثلا توی رابطه، توانایی‌های آدم در زمینه‌ی شناخت و تعامل و درک طرف مقابل، ابراز احساسات و ... ارتقا پیدا کنه. اینا دستاوردایین که همیشه با آدم خواهند بود و از بین نمی‌رن. از طرفی طی زمانی که شخص توی رابطه بوده، احتمالا از رابطه‌ش لذت برده و این یه تاریخچه‌ی مثبتیه که از بین نمی‌ره.توی کارم همین‌طور، آدم توی کارش تجربه به دست میاره و پیشرفت شخصی، حرفه‌ای، پیشرفت soft skill و ... رو داره که دستاوردای خیلی بزرگی هستن و با تغییر شرایط از دستشون نمی‌دیم.دستاوردای اصلی‌ای که ما کسب می‌کنیم اصلا قابل جداشدن ازمون نیستن، فلذا با اتکا به دستاوردایی که داشتیم، باید بتونیم با ترس از تغییر ناشی از حریم امن مقابله کنیم.شاید صحبتای من باعث سوء برداشت بشه، من منظورم این نیست که بی‌دلیل رابطه‌هامونو تموم کنیم و بی‌دلیل شغلمونو عوض کنیم. این کار قطعا یه منظور من اینه که هر وقت به اندازه‌ی کافی دلیل منطقی (طبق منطق خودمون، نه شخص دیگه‌ای) داشتیم برای تغییر، نذاریم ترس از تغییر بهمون غلبه کنه.در نهایت تاکید می‌کنم که خارج شدن از حریم امن باید با بررسی‌های منطقی و هدف‌گذاری برای ادامه‌ی مسیر انجام بشه، در غیر این صورت شرایط خوبی که داشتیم رو بدون دلیل و با توهم بهبود اوضاع از دست دادیم و هیچ برنامه‌ای برای رسیدن شرایط مدنظرمون هم نداریم.

چه طور با سروری که زامبی شده مواجه بشیم؟

رضا کرامتی — Sat, 26 Oct 2019 01:43:22 +0330

اول از همه یه تعریف مختصر از زامبی بگم. داستان اینجوریه که مهاجمایی که میخوان حمله DDoS رو روی یک سایتی اجرا بکنن، نیاز به تعداد زیادی کامپیوتر تو جاهای مختلف هستن، که حمله‌هاشونو با اون سیستم‌های از همه‌جا بی‌خبر انجام بدن و قابل ردیابی نباشن. این کار با استفاده از ریختن بدافزار روی اون کامپیوترها به هر نحوی انجام میشه. کامپیوتری که این بدافزار رو بگیره رو به اصطلاح میگن زامبی شده، یعنی منتظر دستوری از سمت سرور مرکزیه، تا به یه قربانی حمله بکنه.چه طور بفهمیم که سیستم/سرورمون زامبی شده؟اول از همه میتونید از دستور netstat استفاده کنید که توی ویندوز/لینوکس و مک قابل استفاده‌س.sudo netstat -anopخروجی دستور netstat این دستور لیست کانکشن‌های فعالی که دارید رو به همراه PID (آیدی پراسس) براتون لیست میکنه. اگه سیستم شما زامبی شده باشه باید تعداد زیادی کانکشن فعال به آیپی‌های متفاوت (احتمالا Foreign Address اکثرشون باید پورت ۸۰ و ۴۴۳ باشه) که PID همشون هم یکی هست داشته باشید.یه چیز مشکوک دیگه‌ای که وجود داره، تعداد زیادی درخواست UDP به آیپی‌های‌ DNS سرورهاست که باهاش DNS Reflection Attack رو انجام می‌دن.دستور زیر رو اجرا کنید (به جای ۱۲۳۴ باید PID رو بذارید)ps -auxwe | grep 1234توی خروجی این دستور می‌تونید فایل اجرایی که این کانکشن‌ها رو باز کرده رو ببینید.توی سرور ما به دلیل کانفیگ نشدن درست وردپرس، و احتمالا یک پلاگین آسیب‌پذیر، تونسته بودن توی بخش آپلود‌ها یه فایل php اپلود کنن و ادامه‌ی ماجرا.برای جلوگیری از تکرار این موضوع من ۲ تا کار رو کردم: ایجاد فایل htaccess و جلوگیری از اجرای فایل‌های php توی فولدر آپلود‌های وردپرس (وبسرور ما آپاچی بود، توی nginx یا IIS تغییرات دیگه‌ای باید بدید) deny from all ۲. فعال کردن disable_functions در phpیه قابلیت خوبی که php داره اینه که می‌شه استفاده از یه سری توابعش رو محدود کرد. توی php یک سری توابعی وجود داره که باهاش می‌شه دستورای سیستمی اجرا کرد و اکثرا توی برنامه‌های عادی کاربردی نداره و برای برنامه‌های مخرب زیاد ازشون استفاده می‌شه.کافیه فایل php.ini رو باز کنید و این رو توش بذاریدdisable_functions = "passthru,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source,dl,pclose,proc_nice,proc_terminate,proc_get_status,proc_close,leak,apache_child_terminate,shell-exec,exec,crack_check,crack_closedict,crack_getlastmessage,crack_opendict,psockopen,php_u,symlink,ini_restore,posix_getpwuid,system,pfsockopen,readfile,escapeshellarg,escapeshellcmd,proc_close,ini_alter,parse_ini_file,pcntl_exec,posix_kill,posix_mkfifo,posix_setpgid,posix_setsid,posix_setuid,copy,curl_exec,tempnam,shell_exec"مطمئن باشید که openbase_dir تون هم فعال باشه. این قابلیت دسترسی یک کد php به فایل‌های دیگه‌ی سرور که متعلق به این یوزر نیست رو به طور کلی میگیره ازش (البته معمولا این اسکریپت‌ها توی فولدر /tmp کار میکنن که همه بهشون دسترسی دارند)خب حالا که تهدید رو برطرف کردیم خوبه یه نگاهی به کدها بندازیم ببینیم چی بود و چیکار میکردکد اول، ارسال ایمیل اسپماولین فایل خیلی ساده بود، اگه یه نگاهی به تابع میل php بندازیم مشخصه که این کد هدفش ارسال ایمیل اسپم، با دریافت محتوا و گیرنده و سایر پارامترها از سمت سرور کنترل‌کننده‌ش هست.mail ( string $to , string $subject , string $message [, mixed $additional_headers [, string $additional_parameters ]] )ولی فایل دوم همچین حالتی داشت و ناخوانا بود. با یه نگاه ساده معلومه که کد base64 شده و بعدم gzip شدهفایل مخرب دومبه جای eval دستور echo رو گذاشتم که ببینم کدی که داره اجرا میشه چیه (اینکار رو میتونید با ابزارهایی مثل https://www.unphp.net/decode/ هم انجام بدید)خروجی کار دوباره یه کد انکد شده بود، ولی این دفعه یه کامنتی هم از سمت اتکر توش وجود داشتبا چند بار دیکد کردن و تبدیل کاراکترهای ascii به کاراکتر قابل خوندن،‌ همچین چیزی از کد در اومدخب می‌بینید که خیلی ساختار تو در تویی داره، ولی با دقت بهش دو تا خط کد پیدا کردم که کار اصلی رو دارن انجام می‌دن اون خطی که file_get_contents داره در حقیقت داره یه آدرس وب رو باز می‌کنه (در حقیقت DDoS لایه ۷ صورت می‌گیره)این تسک توی یه فایل اجرایی ذخیره می‌شه و احتمالا توی یک لوپ اجرا می‌شه (تو بقیه‌ فایلایی که ایجاد کرده بود بعضا حتی سعی به ایجاد cronjob هم می‌کرد)

حقایق و شنیده‌ها در مورد A/B Testing

رضا کرامتی — Fri, 19 Jul 2019 20:51:21 +0430

A/B Testسلاماگه دستی توی UI/UX داشته باشید یا کار مارکتینگ کرده باشید و یا با تیم طراحی محصول تعامل داشته باشید، احتمالا اسم A/B Testing رو شنیدید. توی این مقاله قصد دارم یه کم دقیق‌تر از منظر یه دولوپر به قضیه نگاه کنم.اول یه تعریف کلی از اِی‌بی تستینگ بکنم و بعد برم سراغ اصل ماجرااِی‌بی تستینگ یک جور آزمایشه که طی اون دو یا چند نسخه از یک سایت (یا اپ یا ...) تهیه میشه، معمولا این دو نسخه دقیقا شبیه همدیگه هستن و صرفا یک پارامتر توشون متفاوته (تست‌هایی هم داریم که چندین پارامتر متفاوت توشون دیده میشه، ولی توی این مقاله تعداد پارامترها موضوع کلیدی‌ای نیست.). ساده‌ترین حالت اجرای تست به این صورته که هر کدوم از این نسخه‌ها برای درصدی از کاربران نمایش داده‌میشه و اندازه‌گیری میشه که کاربران از کدوم نسخه راضی‌تر بودن، یا با کدومش تونستن راحت‌تر کار بکنن. برای توضیحات بیشتر ارجاعتون میدم به لینک زیر: https://www.optimizely.com/optimization-glossary/ab-testing/ از اون‌جایی که این آزمایش خیلی برای تست ظاهر سایت و یا محتوای ایمیل‌مارکتینگ و موارد مشابه به کار می‌ره، عملا این تست بیشتر به درد آدم‌های غیر فنی می‌خوره، و به همین دلیل اگه سرچ بکنید A/B Testing اولین چیزهایی که می‌بینید سایت‌هایی شبیه Google Optimize هستن که به سادگی قابل استفاده هستند، کافیه یک کد جاوااسکریپت رو توی سایتتون قرار بدید و دیگه هیچ نیازی به کدنویسی نیست. با Visual Editorای که در اختیار شما قرار داده می‌شه، شما می‌تونید توی گوگل‌اپتیمایز، آزمایش‌های جدیدی ایجاد کنید و هر قسمتی از سایت که دوست دارید رو تغییر بدید (به سادگی درگ‌اند‌دراپ).ولی به جرات می‌تونم بگم این یه حقه‌ی تبلیغاتی بیشتر نیست، چون این روش اصلا کارامد نیست :) چرا؟ علتش واضحه. فرایند لود شدن یک وبسایت که یک تست گوگل‌اپتیمایز روش قراره اجرا بشه رو در نظر بگیرید. سایت لود میشهاسکریپت‌ها و عکس‌ها و ... لود می‌شناطلاعات آزمایش در حال اجرا از گوگل گرفته می‌شهتغییرات ظاهری روی صفحه اعمال میشهخب مشکل چیه؟ مشکل اینه که تا قبل از اجرای مرحله‌ی ۴، کاربر سایت اصلی رو می‌بینه، و بعد از اون آزمایش اجرا می‌شه و کاربر نسخه‌ی تغییر یافته رو می‌بینه، و خب چی از این بدتر می‌تونه باشه توی تجربه‌ی یک کاربر؟خب گوگل هم یه راه‌حل برای این مشکل داده که به این صورته:یه اسکریپتی به اسم Anti Flicker رو روی سایت می‌ریزید، و کارش اینه که یک پرده‌ی سفید نشون کاربر میده تا مرحله‌ی ۴ تموم بشه. خب اینجوری کاربر تغییرات ناشی از اجرای آزمایش رو نمی‌بینه و این خوبه. ولی این موضوع به چه قیمتی داره اتقاق میفته؟ به قیمت دیرتر لود شدن صفحه برای کاربر و دیدن یک پرده‌ی سفید توی مدت لود شدن سایت (که اگه کاربر اینترنت کندی داشته باشه یا VPN استفاده بکنه این زمان می‌تونه قابل توجه باشه)Google Optimize Anti Flicker scriptخب راه حل چیه؟ اگه یه کم دقیق‌تر درباره‌ی A/B Test تحقیق بکنیم می‌فهمیم که اینا همش حقه‌ی تبلیغاتی بوده و خود گوگل هم حاضر نیست از این روش خودش استفاده بکنه. گوگل بعضا برای اینکه تصمیم بگیره که مثلا برای جستجوی «بلیط هواپیما» کدوم یک از سایت‌های «مستربلیط» و «علی‌بابا» رو گزینه‌ی اول بیاره A/B Test اجرا می‌کنه، به این صورت که برای بعضیا مستربلیط رو اول میاره و برای بعضیا علی‌بابا رو. و نهایتا با اندازه‌گیری کلیک‌هایی که روی هر کدوم شده و پارامترهای دیگه‌ای مثل Bounce Rate متوجه می‌شه که کدومشون گزینه‌ی بهتری برای اول بودن توی نتایج هستند. ولی ما هیچ وقت یه پرده‌ی سفید قبل از لودشدن کامل گوگل نمی‌بینیم، و یا تغییر سمت کلاینت توی نتایج گوگل نمی‌بینیم.راه حل مشکلاتی که گفتم چیزیه به اسم Serverside A/B Testing. به این صورت که سمت سرور تصمیم می‌گیریم که چه نسخه‌ای از سایت رو به کاربر نشون بدیم (اگه SPA داشته باشیم می‌تونیم این مورد رو توی لاجیک کلاینت پیاده‌سازی کنیم). https://blog.optimizely.com/2017/05/04/experiment-server-side/ ولی می‌دونیم که گوگل‌اپتیمایز آمارهای خوبی بهمون می‌ده و با گوگل‌انالیتیکز هم اینتگریت شده، پس نمی‌خوایم از دستش بدیم، با کمی سرچ متوجه می‌شیم که گوگل‌اپتیمایز از Serverside Experiment هم پشتیبانی می‌کنه، ولی خب چون اونقدر جذاب نیست و درگ‌اند‌دراپ نداره، هیچ‌کس نمی‌شناستش. https://developers.google.com/optimize/devguides/experiments با خوندن توضیحاتی که گوگل توی این لینک داده، می‌تونید اجرای آزمایش رو توی Backend خودتون انجام بدید (لایبرری‌های خوبی برای زبون‌های مختلف بکند وجود داره تو این زمینه) و نتایجش رو وصل کنید به گوگل‌اپتیمایز و توی گوگل‌آنالیتیکز آماری که نیاز دارید رو ببینید. به همین سادگی.جمله‌ی آخرسعی کنیم ساده گول تبلیغات - مخصوصا توی حوضه‌ی تکنولوژی - رو نخوریم. درسته تکنولوژی پیشرفت کرده، ولی هنوز همه‌ی کارها به بهترین نحو با محیط گرافیکی و درگ‌اند‌دراپ قابل اجرا نیستن :)

چه طور تحریم onesignal رو دور بزنیم؟

رضا کرامتی — Sat, 02 Feb 2019 13:14:09 +0330

وان‌سیگنال، سرویس ارسال پوشسلام. onesignal یکی از بهترین سرویس‌های پوش‌نوتیفیکیشن هستش که چند وقتیه ایران رو تحریم کرده. ما کلی دنبال جایگزین مناسب براش گشتیم و موردی با این کیفیت و رایگان توی مشابه‌های داخلی و خارجی پیدا نکردیم. برا همین آستین‌ها رو بالا زدیم و تحریم‌ها رو به فرصت تبدیل کردیم :))دقت کنید که این مطلب کاملا فنیه و اگه خودتون آدم فنی‌ نیستید، این مطلب رو در اختیار تیم فنی‌تون قرار بدید.تنها چیزی که شما برای این کار نیاز دارید یه سرور خارجیه. تو این آموزش فقط دور زدن تحریم برای وب‌پوش رو آموزش می‌دم. برای اپ هم مشابه همین کار رو میشه کرد ولی من هنوز نکردم. اگه کسی کرد می‌تونه به اشتراک بذاره.خب بریم سراغ آموزش. فرض کنیم که دومین mydomain.com مال ماست. DNSهای onesignal.mydomain.com و img.onesignal.mydomain.com و cdn.onesignal.mydomain.com رو ست می‌کنیم روی آی‌پی سرور خارجی‌ای که در اختیار داریم.روی سرور اوبونتو نصب کردیم و nginx هم روش نصبه. یک فایل به اسم onesignal توی فولدر زیر ایجاد می‌کنیم/etc/nginx/sites-availableو محتویات زیر رو توش مینویسیم. (توی تموم کدهای زیر mydomain.com رو با دومین خودتون جایگزین کنید)server { listen 80; server_name onesignal.mydomain.com; location / { proxy_cookie_domain '.onesignal.com' '.onesignal.mydomain.com'; proxy_set_header Accept-Encoding ''; sub_filter_types application/javascript application/json text/xml text/css text/javascript; sub_filter 'onesignal.com' 'onesignal.mydomain.com'; sub_filter_once off; proxy_pass https://onesignal.com; } } server { listen 80; server_name img.onesignal.mydomain.com; location / { resolver 8.8.8.8 ipv6=off; proxy_pass https://img.onesignal.com; } } server { listen 80; server_name cdn.onesignal.mydomain.com; location / { proxy_cookie_domain '.onesignal.com' '.onesignal.mydomain.com'; proxy_set_header Accept-Encoding ''; sub_filter_types application/javascript application/json text/xml text/css text/javascript; sub_filter 'onesignal.com' 'onesignal.mydomain.com'; sub_filter_once off; proxy_pass https://cdn.onesignal.com; } }بعد دستور پایین رو اجرا می‌کنیمsudo ln -s /etc/nginx/sites-available/onesignal /etc/nginx/sites-enabled/onesignal sudo service nginx reloadحالا برای اینکه HTTPSش رو هم اوکی بکنیم، از Let's Encrypt استفاده می‌کنیم که یک سرویس SSL رایگان هستش.دستورهای زیر رو اجرا می‌کنیمsudo add-apt-repository ppa:certbot/certbot sudo apt-get update sudo apt-get install python-certbot-nginxحالا برای جنریت‌کردن گواهینامه‌ی SSL دستورهای زیر رو اجرا می‌کنیمsudo certbot --nginx -d onesignal.mydomain.com sudo certbot --nginx -d cdn.onesignal.mydomain.com sudo certbot --nginx -d img.onesignal.mydomain.comاگه اینجا خطایی دیدید DNSهاتون رو مجدد چک کنیدخب حالا فقط می‌مونه یک کاربرای فعال‌سازی وان‌سیگنال، دو تا فایل با نام‌های OneSignalSDKWorker.js و OneSignalSDKUpdaterWorker.js رو روی سایتمون آپلود کرده بودیم. محتویات فایل‌ها به این صورت هستimportScripts('https://cdn.onesignal.com/sdks/OneSignalSDKWorker.js');که باید به این تغییر بکنه:importScripts('https://cdn.onesignal.mydomain.com/sdks/OneSignalSDKWorker.js');خب تبریک می‌گم. الان وان‌سیگنال شما تحریم رو دور می‌زنه و مثل ساعت کار می‌کنه.