نوشته های ابراهیم قاسمی

آخرین روزهای سحاب‌پرداز

ابراهیم قاسمی — Sat, 19 Oct 2019 15:06:45 +0330

سه روز قبلتمرین چتر کِشی‌مان که تمام شد، هوا تازه تاریک شده بود. خسته و سَلانه سَلانه، تا میانه‌ی باند پرواز —که حالا در تاریکی مطلق، خالی از هر نوع پرنده بود— خزیدم و کمی دورتر از هیاهوی بچه‌ها، روی آسفالت‌ها و رو به آسمان به تماشای ستاره‌ها دراز کشیدم.چشم‌هایم که گرمِ کاوش کردن خوشه‌ی پروین از لابلای ابرها شده بود، علی —پسرِ خردسالِ مربی— که حالا بعد از چند جلسه با هم دوستان صمیمی شده‌ایم هم از راه رسید؛ کنارم نشست و شروع به صحبت درباره‌ی غذا دادن به سگ سفیدِ تک چشمِ فرودگاه کرد.کودکانه‌های علی اگرچه برای گوش کردن لذت بخش بود، اما حرکت ابرها، اندک‌اندک اندیشه‌ی خاطرات سحاب و سه سالی که به پلک روی هم نشستنی گذشت را به آغوش سلول‌های خاکستری‌ام گرفتار کرد.آخرین روزهای کار کردن در سحاب است و برای چون منی که می‌کوشم رخ‌دادنِ هر اتفاقی را بر شانه‌ی قضا و قدر و مصلحت الهی بیاویزم تا از بارِ سنگین تلخی‌شان بگریزم، شگفت است این احساس گران‌وزنِ جدایی.یک روز قبلپرسید اگر قرار باشد بعد از سه سال، سحاب را در چند جمله خلاصه کنی، چه می‌گویی؟گفتم: یکی از اتوبوس‌های آخرین مدل شهر، با بهترین هم‌سفرها.مکث کرد و پرسید «با این توصیف، پس چرا پیاده می‌شوی؟»گفتم چون نمی‌توانم بفهمم به کجا می‌رود و علی‌رغم همه‌ی لذت‌های سفر، رسیدن به یک منزلِ مطلوب را به ماندن در سرای تردیدِ بین صواب و ناصواب، به مرکبِ آخرین مدل و به هم‌سفرهای دوست داشتنی، اولویت می‌دهم. بعدتر اضافه کردم که البته فکر نکنی این جدا شدن به معنی راستیِ مطلق یکی و ناراستیِ مطلق دیگری‌ست؛ این جدایی را تو به خداحافظی قطره‌ای آب از یک ابر خاکستری نظاره کن.ابری که شاید در آینده‌ای دور یا نزدیک، سپید شود و طراوت و سرسبزی برای سرزمینی به ارمغان آورد و یا شاید سیاه شود و با خود سیل به همراه داشته باشد. قطره‌ای که شاید به دریایی زلال برسد، وسیع شود و بعدتر سوار بر ابری روشن گردد و یا شاید بی‌راهه پیش گیرد و اسیر شود به آبگیری گل‌آلود و تیره شود.باری! از همه‌ی این‌ها گذشته، چه گریز از این که هر سلام سرآغاز یک خداحافظی‌ست؟پس تا دیدارهایی دیگر،بدرود سحاب‌پرداز و بدرود هم‌قطارهای دوست‌داشتنی‌ام.

هر سلام، سرآغاز یه خداحافظی تلخه ...

ابراهیم قاسمی — Fri, 04 Oct 2019 14:35:16 +0330

مصطفی قرار است برود!مسعود همانطور که به او وعده داده بود، از من هم قول گرفت که این مسئله را با کسی در میان نگذارم. من هم طبیعتا از سیروس قول گرفته‌ام عجالتا این راز را برملا نکند!مهدی، به بهانه‌ی ایجاد خطِ تولید محصول جدید، پروژه‌های جاری او را به سیروس سپرده است، لیکن این‌ها گام‌های انتقال مسئولیت‌اند که بی‌سروصدا و یکی-یکی در حال طی شدن‌اند. اگرچه به عقیده‌ی من و مسعود حفظ آرامش شرکت دست‌آویز خوبی برای دروغ نیست، اما فعلا به گونه‌ای رفتار می‌کنیم که گویی واقعا قرار است خطِ‌ تولید محصول جدیدی در شرکت ایجاد شود.مصطفی، درست یا اشتباه، به نظر غالب هم‌قطارها، سنگین‌ترین مهره‌ی تیم و حتی کمپانی است و این سنگینی، رفتن را که همیشه ملال‌انگیز بوده، بسیار ملال انگیزتر کرده است. باری! مصطفای نازنین قرار است برود و دیر یا زود، نهایتا تا دو ماه دیگر، باید با همه علنا بدرود بگوید.تلخی‌ِ بدرودهای دقیقه‌ی نود را چند سال قبل، وقتی مارکو آمد؛ بیست دقیقه نشست و بعد گفت «دو روز دیگر پرواز دارم؛ برای خداحافظی آمده‌ام!» مزه کردم. امیدوارم مصطفای نازنین اینقدر عاقل باشد که در کنار تابلوی زیبای شخصیت‌های انیمه، سورس‌کدهای تر و تمیز و بقیه‌ی خاطره‌های دلنشین‌ش، یک تلخی گزنده برای ما به جا نگذارد و دست‌کم چند هفته به خودش و به ما فرصت بدهد عطر این آخرین روزهای با هم بودن‌مان را —که روزمرگی و عادت، ما را به آن بی‌توجه کرده— عمیق‌تر نفس بکشیم …سنه‌ی ۱۳۹۷قبل از رفتن مصطفی از کمپانی

شوآف، ماشین تولید عقاب از کلاغ؟

ابراهیم قاسمی — Fri, 20 Sep 2019 03:54:40 +0430

«از روی صندلی‌اش بلند شد؛ دست‌هایش را مشت کرد و بالا برد و جوری که همه‌ی طبقه بشنوند، بلند گفت: بالاخره و باز هم من مشکل کوفتی را حل کردم! عمرا اگر کس دیگری می‌توانست این مسئله را حل کند!»داستان خیالیِ بالا، از جمله موارد آزاردهنده‌ای است که همه‌ی ما حداقل یک بار در سابقه‌ی کاری خود با آن مواجه شده‌ایم؛ داشتنِ همکاری که با استفاده از شوآف یا [به فارسیِ شاید نه چندان دقیق] خودنمایی، توانسته است جایگاهی در نگاه مدیریت برای خود دست و پا کند و شرایط بهتری به لحاظ رتبه، حقوق یا روابط، برای خود رقم بزند.این نگاشته‌ ―که دایره‌ی مخاطبان آن، از یک کارمند دون‌پایه تا یک مدیر بالا رتبه است― می‌کوشد با مقدمه‌ای کوتاه در توصیف شوآف و دلایل و نتایج آن، پاسخی برای سوالِ «در مواجهه با شوآف در سازمان باید چه کنیم؟» به خواننده ارائه دهد.شوآف چیست؟شاید بتوان برای شوآف (Show Off)، معانی خودنمایی، قمپز در کردن، لاف زدن یا نمایش خود را ذکر کرد، اما به طور خلاصه آنچه در این متن ما را از این کلمه منظور است، رفتارهایی‌ست نظیرابراز مداوم یک به یک کارهایی که انجام می‌دهدبیش از حد پیچیده و سخت نمایش دادنِ کارهای معمولی که انجام می‌دهداستفاده‌ی زیاد از گزاره‌هایی شبیه «کاری کردم که هیچ‌کس قادر به انجام نبود»تلاش برای گزارش مستقیمِ کارها به بالاترین مقام سازمان به جای گزارش به مدیر مستقیم خودذکر کردن مکررِ به انجام رساندن چندین پروژه و وظیفه‌ی محوله‌ی سنگیناشاره‌ی گاه و بی‌گاهِ «بی‌دلیل» به تعدادِ زیاد کتاب‌هایی که خوانده‌استبر شمردنِ پیشنهادهای شغلی‌اش که از شرکت‌های بزرگ در چنته داردبازگویی و تکیه به داشتن روابط و لینک‌هایی با افراد معروف/مهم در حوزه‌ای که فعالیت می‌کنداستفاده زیاد از کلمات قلمبه سلمبه، نقل قول از نویسندگان و افراد مشهور و اصلاحات انگلیسی (با هدف خود خفن‌نمایی)و موارد از این دست ...دلایل شوآفشوآف دلایل متفاوتی می‌تواند داشته باشد. به صورت خلاصه، شوآف ...یک― می‌تواند رفتارِ عامدانه‌ی یک کارمند سیّاس، با تکنیک‌هایی از پیش فکر شده باشد برای بدست آوردن جایگاه بهتری [فراتر از شایستگی] در محیط کار یا کسب اعتبار فعالیتی که فرد دیگری انجام داده است!دو― می‌تواند تلاش‌های یک کارمند معمولی باشد که به این نتیجه رسیده‌است که از نگاه مدیریت، تلاش‌ها یا استعدادش دیده نمی‌شود و جایگاهی پایین‌تر از آنچه که سزاوار اوست، برای وی لحاظ شده است. مثلا برنامه‌نویسی را تصور کنید که خروجی فعالیتِ یک هفته‌اش، رفع چندین باگ (ایراد) مهم یا طراحی یک ساختار عالی برای نرم‌افزار بوده است ولی نمود خارجی آن تنها چند تغییر کوچک در کد است و این مسئله به چشم مدیریت کم کاری تلقی شده است. یا فردی را تصور کنید که به سبب خصومت مدیر میانی با وی، تلاش‌هایش به مدیریت شرکت منتقل نمی‌شود و ناگریز است با شوآف شایستگی خود را برای دیگران نمایان کند.سه― و در نهایت می‌تواند رفتارهای نه چندان تعمدانه‌ی فردی با اختلال شخصیتی مثلا هیستریونیک یا نمایشی یا فرد خود خفن‌پنداری باشد که به واسطه‌ی بیماری روانی‌اش، عطش سیری ناپذیر توجه‌طلبی‌اش منجر به خودنمایی وی شده‌است. یکی از دلایل این عطش مثلا می‌تواند نادیده گرفته شدن وی در کودکی توسط والدین و نهادینه شدن نیاز به توجه و لزوم تلاش مستمر برای در معرض دید دیگران قرار گرفتن در شخصیت وی باشد.حتی ممکن است فرد خودش واقف به خاص نبودن خودش نباشد!نتایج شوآفتا به اینجای متن باید متوجه شده باشید که شوآف، نه تنها همیشه سزاوار نکوهش نیست، بلکه بعضی مواقع (مورد شماره دو) یک مهارتِ لازم و شایسته‌ی تحسین و بعضی مواقع (مورد شماره سه) یک بیماریِ درخور دلسوزی و شفقت است. اما سوال اینجاست که نتیجه‌ی شوآف در یک سازمان برای فرد و سازمان چه می‌تواند باشد؟پاسخ به این سوال بستگی شدیدی به ساختار شرکت، میزان شفافیت به جهت معیارهای شایستگی و رشد افراد در سازمان، میزان سلامت عملکرد مدیران میانی و مهم‌تر از همه بستگی به این دارد که مدیریت و کارمندان تا چه حد بلوغ تمییز انواع این شوآف‌ها را از یکدیگر دارند.به صورت شفاف‌تر و به عنوان مثال، در سازمانی که مدیر میانی از سلامت عملکرد برخوردار نیست و ساختار هم به نحوی نیست که تلاش افراد تیم به لایه‌های بالایی شرکت منتقل شود، افراد ناگریز از شوآف هستند و تمرکز بر این مسئله، علی رغم این که باعث انتقال تلاش آن‌ها به لایه‌های بالایی مدیریت می‌شود و رشد آن‌ها را در پی دارد، از منظر شرکت، منجر به کاهش بهره‌وری افراد و بی‌رغبتی آن‌ها به انجام کارهایی که جذابیت نمایشی برای مدیریت ندارند شده و در نهایت باعث افول کیفت کار شرکت می‌شود.یا به عنوان مثالی دیگر، اگر یک شخصیت نمایشی در شرکت وجود داشته باشد و به واسطه‌ی عدم تشخیصِ صحیح شایستگی توسط مدیریت، به واسطه‌ی رفتارهای نمایشی‌اش بتواند جایگاهی فراتر از آنچه لایق است بدست آورد، بین سایر افراد پر تلاش، ناامیدی و بی‌انگیزگی، میل به شوآف و شاید دشمنی با فرد شوآف کننده (در صورتی که تشخیص ندهند رفتار وی به سبب بیماری است) جوانه خواهد زد.و در مورد آخر، همان نمونه‌ی ذکر شده در بند دومِ دلایل شوآف را در نظر بگیرید. فردی که در مدت یک هفته چندین ایراد مهم را از نرم‌افزار برطرف کرده است ولی به واسطه‌ی تغییرات اندک در خروجیِ نموداریِ کار وی (یعنی در کدِ برنامه) تلاشش توسط مدیریت دیده نشده است. این فرد با شوآف می‌تواند آنچه شایستگی‌اش را دارد کسب کند و این نتیجه‌ی مطلوبی از شوآف است.بنابراین، از کنار پدیده‌ی شوآف در سازمان، نباید ساده گذشت! باید دلایل آن را مورد بررسی قرار داد و از آسیب پیش‌گیری کرد.نتیجه‌گیری؟پاسخ به سوال ابتدایی متن، یعنی پاسخ به سوال «در مواجهه با شوآف در سازمان باید چه کنیم؟» ساده نیست. اما مواردی که به ذهن می‌رسد به شرح ذیل اند:ساختارهای شرکت باید نحوی طراحی شوند که دیده شدن تلاش افراد، تنها از دریچه‌ی نگاه یک فرد (مثلا مدیر مستقیم) نباشد. به عنوان مثال ارزیابی‌های 360 درجه، فرم‌های مرور عملکرد، برنامه‌های OKR و نرم‌افزارهای ثبت و رصد فعالیت‌ها، می‌توانند با انتقال تلاش افراد به لایه‌های بالایی، نیاز به شوآف را از بین ببرند. شرکت باید بکوشد، نیاز به شوآف را به حداقل برساند.همه‌ی افراد (و خصوصا مدیران) باید بکوشند با شناخت اختلال‌های روانی و آشنایی با حداقل‌هایی از روانشناسی، توانایی تمییز انواع شوآف از همدیگر را کسب کنند تا در دام اشتباه‌های شناختی و اعطای جایگاه‌های فراتر از شایستگی به افراد گرفتار نشوند و مثلا در هنگام مشاهده‌ی شوآف یک فرد بیمار، آرامش‌شان را حفظ کنند! :)همه باید وظیفه‌ی خود بدانند که در مواقعی که حس می‌کنند فردی بدون شایستگی و تنها به واسطه‌ی شوآف به جایگاهی رسیده است یا تلاش خودشان یا همکار دیگری را به اسم خود ثبت کرده است، با انتقال این حس به مدیریت، فرد شایسته را به جایگاه درخور برسانند و علاوه‌بر این باید در مواقعی که حس می‌کنند تلاش‌های یک فرد (مثلا به واسطه‌ی درون‌گرا بودن او) دیده نشده است، با انتقال این اطلاعات به مدیران، از به وجود آمدن نیاز به شوآف و از بوجود آمدن حس ناامیدی در وی، پیش‌گیری کنند.تفاوت‌های آدم‌ها باید درک شود. همه ما به یک صورت و با شرایط یکسان بزرگ نشده‌ایم و بنابراین، اخلاق‌های خوب و بد یکسان نداریم. رفتارهای اشتباه در ما هم وجود دارد. شایسته این است که در رفع ایرادهای اخلاقی به بقیه کمک کنیم و در اصلاح نقص‌ها و ایرادهای اخلاقی‌مان با بازخورد دوستان و همکاران‌مان مشتاق باشیم.شرکت‌ها باید در مواقعی که شوآف‌هایی از نوع یک (سیّاس‌های هدف‌دار) مشاهده می‌کنند، با ارائه‌ی بازخورد سریعِ، از مشتبه شدن امر بر فرد و دور شدنش از مسیر رشد و همچنین از بروز توقعات نابجا از سازمان، پیشگیری کنند.شرکت‌ها باید به جهت حفظ سلامت و آرامشی روانی افراد، این اعتماد را در کارمندان خود ایجاد کنند که قادر به تشخیص شوآف فرد سیّاس هستند و قرار نیست که کسی صرفا به واسطه‌ی توانایی‌های نمایشی‌اش به جایگاه والاتری نسبت به بقیه دست یابد.و در نهایت این که به این نکته توجه کنید که شوآف، لزوما ابزار بدی نیست و لازم است افراد با تکنیک‌های اخلاقی آن آشنا شوند و گاهی به عنوان یک «هنر» برای انتقال تلاش‌هایی که انجام داده‌اند، از آن بهره ببرند. حتی ممکن است گاهی لازم شود همکاری را که از نگاهِ شما توانایی‌های فوق‌العاده‌ای دارد ولی به واسطه‌ی تیپ شخصیتی‌اش فروتنی خاصی دارد و به دلیل این فروتنی توانایی‌ها و استعدادش دیده نمی‌شود، تشویق به شوآف کردن کنید!البته باید در نظر داشت که در این مواقع، مرز باریکی بین شوآف کردن درست و اخلاقی و شوآف کردن غیر اخلاقی وجود دارد. در این مواقع باید دقت کرد که شوآف صرفا به انتقال درست تلاش‌ها و فعالیت‌هایی که فرد انجام داده است معطوف شود و نباید آلوده به تحقیر فعالیت دیگران یا به ارائه‌ی اغراق های نمایشی از فرد منجر گردد. گاهی لازم است همکارتان را تشویق به شوآف کنید!پی‌نوشت یک:آل عمران/26: «قُلِ اللَّهُمَّ مَالِكَ الْمُلْكِ تُؤْتِي الْمُلْكَ مَن تَشَاءُ وَتَنزِعُ الْمُلْكَ مِمَّن تَشَاءُ وَتُعِزُّ مَن تَشَاءُ وَتُذِلُّ مَن تَشَاءُ ۖ ...»بگو: «بارالها! مالک حکومتها تویی؛ به هر کس بخواهی، حکومت می‌بخشی؛ و از هر کس بخواهی، حکومت را می‌گیری؛ هر کس را بخواهی، عزت می‌دهی؛ و هر که را بخواهی خوار می‌کنی. تمام خوبیها به دست توست؛ تو بر هر چیزی قادری.پی‌نوشت دو:امیرالمومنین علی علیه‌السلام: «کَمْ مِنْ مُتْعِبٍ نَفْسَهُ مُقْتَرٍ عَلَیْهِ وَ مُقْتَصِدٍ فِی الطَّلَبِ قَدْ سَاعَدَتْهُ الْمَقَادِیرُ.»چه بسیار افرادی که خود را به زحمت می اندازند اما چیز زیادی عاید آنان نمی شود و چه کسانی که در حد متوسط تلاش می کنند ولی تقدیر الهی آنان را مساعدت می کند.پی‌نوشت سه:«اَلعبدُ یُدَبِّرَ وَ اللهُ یُقَدِّرَ»آیت‌الله مجتبی تهرانی: آیا تدبیر ما در امور و کارهای زندگیمان کافی است؟ به تعبیر من چه قدر قاشق بدون دسته ‌ساخته‌ایم! چه قدر در زندگی سرها به سنگ می‌خورد! علّت چیست؟ علّت آن این است که تدبیر من، آنگاه کارساز است که با تقدیر او همسو شود. بنده تدبیر می‌کند، امّا خدا تقدیر می‌کند. تدبیر منهای تقدیر سودی ندارد.به عبارت دیگر این که، اگر در مواجهه با شوآف کاری از شما ساخته نبود، زیاد پافشاری نکنید و ناراحت نباشید، زیرا ممکن است پافشاری شما سوء تعبیر به حسادت شود؛ به جای این در نظر داشته باشید که اولا، دوما و سوما کارها به دست خداست و چهارما، شوآف کننده‌ی سَیّاسی که قصد دارد با فریب جایگاهی که شایستگی ندارد را بدست آورد، دیر یا زود خودش را به مهلکه می‌کشد. به عبارتی:Give an idiot enough rope and eventually they'll find a way to hang themselves!

افسوس از این عمر کوتاه

ابراهیم قاسمی — Fri, 13 Sep 2019 15:17:50 +0430

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

در جستجوی خورشید، چه حاجت است به مشعل؟

ابراهیم قاسمی — Fri, 13 Sep 2019 11:27:15 +0430

دراز کشیدم زیر شاخه‌های رو به پایینِ درختان بیدِ وسط پارک و از لابلای برگ‌ها، خیره شده‌ام به ابرها.خیره شده‌ام به ابرها و همینطور که سایه و نورِ خورشید را به نوبت روی پوست صورتم پرتاب می‌کردند، فکر کردم به این که پایان دادن به یک ارتباط عاطفی، بدون یک خداحافظی درست و منطقی، چقدر شبیه است به رها نشدنِ یک شاخه‌ی نیمه‌شکسته از شانه‌ی یک درخت سرسبز!از این نظر که آن شاخه دیگر هیچ‌وقت شاخه‌ی قبلی نمی‌شود و توجهِ پیشین را از درختش نمی‌گیرد، ولی هیچ وقت هم بی‌جان نمی‌شود و لاجِرم یک زندگی کامل، با برگ‌های پژمرده سر می‌کند.بعد نگاهم را فراتر بردم و فکر کردم به موجودات این قسمت کهکشان؛ همین قسمتی که من و تو را در خود محبوس کرده؛ همین قسمتی که راحت اسیر نحیف‌ترینِ حصارهایش شده‌ایم. فکر کردم به این که چقدر راحت چشمان‌مان را بسته‌ایم به سرچشمه و خصیصه‌های قشنگِ کوچکِ آدم‌ها یا دیگر مخلوقات اطراف را بزرگ کرده‌ایم و دل سپرده‌ایم به فنا.بعد به واکاوی خاطرات خودم سپری شد! صادقانه این که، خیلی خواستم "آنتونیو"یی باشم دوست‌داشتنی برای او! ولی راه درستش را نمی‌دانستم و هرچند این ندانستن راهِ درست، من را به یک موجود منزویِ گوشه گیر تبدیل نکرد؛ ایستادم به آزموندنِ راه‌های اشتباه؛ یک به یک را امتحان کردم و همه را تا انتها رفتم؛ تنها به این امید که شاید یکی از این راه‌ها، به خطا، اشتباه خوانده شده باشد؛ اما نتیجه‌ای حاصل نشد. و در عوض، چیزی که ماند فقط همان شاخه‌ی نیمه شکسته بود، کم‌رَمَق‌تر ...باری! در این وقت‌ها بوی دنیا، عجیب به مشام آدم بوی تعفّن است؛ خصوصا اگر درون تاریکیِ تنهایی [همان جایی که فکر می‌کنند کسی جز خودشان آنجا نیست] قدم گذاشته باشی و چراغ قوّه به دست، با خیالِ یافتن خورشید، دوره‌گردِ کوچه پس‌کوچه‌ها شده باشی. اما از دل همین تعفّن، اگر دریچه‌ی سینه‌ات را باز بگذاری، حبیب، نور را بر تو نمایان می‌کند و می‌فهماندت که برای یافتن خورشید، حاجتی به اسیر بودنت به خاک، به نگاهت به پایین نیست و حاجتی به مشعل کوچکت نیست ...البته؛ اگر دریچه‌ی سینه‌ات را باز بگذاشته باشی! امید که باز باشد دریچه‌ی سینه‌هامان برای نور.

زخم‌های روحی

ابراهیم قاسمی — Fri, 16 Aug 2019 18:22:57 +0430

انگشت اشاره‌ی دستِ راستم دیروز زخم شد! به صورت جزئی‌تر، دقیقا از روی شیار بین بند اول و دوم؛ موقع خرد کردن پیاز، به صورت عادیِ متمایل به بد، بریده شد و من به خاطر دمِ دست نبودن جعبه‌ی کمک‌های اولیه‌ی پزشکی، با دستمال کاغذی و چسب برق مانع خونریزی بیشترش شدم!بعد، امروز غروب مُردّد شدم که مبادا دستمالِ کاغذی، با جذب رطوبت به خاطر چند بار شستشوی دست، به عفونت آلوده شده باشد و برای انگشتِ اشاره‌ی مذکور مشکلی بوجود بیاورد! از سر همین نگرانیِ مختصر، دردِ یک تعویض کردن پانسمان را پذیرفتم؛ با بتادین قسمت مربوطه را ضد عفونی کردم و در نهایت یک دستمال جدید، جایگزین دستمال قبلی کردمباری! الان که طاق باز دراز کشیده‌ام و از پنجره غرقِ سیاهی آسمانم، ذهنم به این مسئله مشغول شده است که چرا ما آدمیان، قسمتی از تنهایی‌هایمان را به واکاویِ زخم‌های روحی و دلایل بروز آن‌ها اختصاص نمی‌دیم؟ آیا زخم‌های روحی -که قدمی از قدمی برای مداوای آن‌ها برنمی‌داریم و بیشترین توجهی که به آن‌ها معطوف می‌کنیم، یک آهنگ و یک قدم زدن‌ِ شبانه‌است- تاثیر کمتری در زندگی آینده‌ی ما دارند تا زخمِ سطحی روی شیار بین بند اول و دومِ انگشتِ اشاره‌ی دستِ راست؟به نظرم حرف گزافی نیست اگر بگوییم قدم زدن‌ها و آهنگ شنیدن‌های بعدِ زخم، تنها نقش مُسکّن دارند و آدمی ناگریز است برای رشد، زمانی از روز را به حلّاجی کردن اتفاقاتِ زندگی و سبک‌سنگین کردن نقاط ضعفِ خودش اختصاص دهد ...

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

ابراهیم قاسمی — Thu, 08 Aug 2019 09:50:45 +0430

پرسید "بی‌معرفت‌ام؟"نوشتم مارکوئی که من می‌شناختم بی‌معرفت نبود، ولی چهار زمستان از خداحافظی لحظه‌ی آخری‌ات گذشته و هیچ تضمینی نیست که مهاجرت از تو آدم دیگری نساخته باشد. اصلا بدی مهاجرت دوری آدم‌ها نیست، بدی‌اش این است که دیگر نمی‌توانی مطمئن باشی آدمی که یک روز دوست صمیمی‌ات بود و می‌شناختی‌اش، هنوز همان شخصیت سابق باشد. حتی من هم شاید همان دوست قدیمی‌ات نباشم.پرسید "بی‌معرفت‌ام؟"نوشتم تعارف که نداریم، بی‌معرفت به نظر می‌رسی؛ ولی این که حقیقت چیست را فقط خودت می‌دانی؛ من همه را گذاشته‌ام به حساب دوری و مهاجرت و مشکلات‌اش. از این گذشته هنوز فراموش نکرده‌ام که زندگی‌ات بیشتر بر روال منطق بود تا احساس. احتمالا فلسفه‌ی این خبر گرفتن‌های دنیای صفر و یکی باید برایت زیر سوال باشد! حتی منِ احساسی هم گاهی از خودم می‌پرسم فایده‌ی این خبر گرفتن‌ها چیست وقتی اگر در حال مردن هم باشم، نه تنها کمکی از هیچ دوست مهاجری ساخته نیست، بلکه فقط خاطر عزیزش مکدّر می‌شود؟نوشتم گهگاه دلم برایت خیلی تنگ می‌شود، اما پذیرفته‌ام آدم‌ها پرستوهای مهاجری نیستند که بعد چند ماه کوچِ دوباره‌ای کنند و بازگردند. آدم‌ها حتی قاصدک‌های رها در باد هم نیستند که امیدوار باشی با نسیمی باز به هم برسند. آدم‌ها درخت‌اند و وقتی جایی ساکن شوند، ریشه‌هاشان در آن سرزمین رسوخ می‌کند و تا کارد به استخوانشان نرسد و طوفانی نشود، تکان نمی‌خورند.سخن کوتاه کردم و نوشتم همین که حالت خوب باشد و کِیف‌ت کوک باشد، خرسندم. هیچ انتظار دیگری از یک دوست مهاجر ندارم.همه مرغان هم‌آواز پرآکنده شدندآه از این باد بلاخیز که زد در چمنم ...ننگ باد فرجام کسی که مهاجرت را به تنها گریز جوینده‌های آرامش مبدّل کرد.

اول رمزنگاری یا اول فشرده‌سازی یا ...؟

ابراهیم قاسمی — Mon, 29 Jul 2019 01:42:26 +0430

بیایید فرض کنیم که می‌خواهیم پروتکلی برای ارسال داده‌ها در شبکه طراحی کنیم و به وسیله‌ی آن، داده‌ها را از یک رایانه به رایانه‌ی دیگری در شبکه ارسال کنیم.سوال اینجاست که اگر به واسطه‌ی ناامن بودن کانال ارتباطی، ملزم به رمزکردن داده‌ها باشیم، آیا عملیات رمزنگاری را پیش از فشرده‌سازی انجام می‌دهید یا پس از آن؟فشرده‌سازی مقدم است یا رمزنگاری؟برای یافتن پاسخ صحیح، یک بار دیگر به طور خیلی خلاصه آنچه در دو عملیات رمزنگاری و فشرده‌سازی انجام می‌شود را مرور می‌کنیم:رمزنگاری: الگوریتمی است که با استفاده از یک کلید رمزنگاری، داده‌های ورودی را به خروجی درهم ریخته‌ی ظاهرا رندومی که دارای آنتروپی بالایی است تبدیل می‌کند که باز تولید داده‌ی ورودی از آن، تنها با داشتن آن کلید امکان‌پذیر باشد. فشرده‌سازی: الگوریتمی است که با جستجوی الگوهای تکراری در داده‌های ورودی، سعی می‌کند خروجی کم حجم‌تری تولید کند که با استفاده از آن بتوان به داده‌ی اولیه دست یافت. به عنوان یک مثال خیلی خیلی ساده، به جای ارسال salamsalam عبارت 2salam را جایگزین می‌کند. در این الگوریتم‌ها هرچقدر آنتروپی ورودی پایین‌تر باشد، امکان و میزان فشرده‌سازی، بالاتر می‌رود.حال با در نظر گرفتن دو گزاره‌ی بالا، اولین جوابی که به سوال ابتدایی متن به ذهن خواهد رسید این است که "ابتدا باید داده‌ها را فشرده و سپس رمز کنیم؛ زیرا اگر در گام اول داده‌ها را رمز کنیم، با توجه به خروجی random-گونه‌ای که توابع رمزنگاری دارند، در گام دوم وقتی تابع فشرده‌سازی به دنبال یافتن الگوهای تکراری داخل ورودی است، الگویی یافت نمی‌شود و بنابراین قادر به فشرده‌سازی مناسبی نخواهیم بود."این جواب به لحاظ منطقی و از نگاه performance صحیح است و حتی stackoverflow هم آن را پاسخ درستی می‌پندارد، ولی به لحاظ امنیتی جواب همواره درستی نیست. پیش از این که به شرح مشکل امنیتی این روش بپردازیم، لازم است تصدیق کنیم که به دلایل مطرح شده در فوق، فشرده‌سازی پس از رمزنگاری، بی فایده‌است و نتیجه‌ی مطلوبی از کم شدن حجم داده‌ی تبادلی نخواهد داشت. بنابراین از اینجا به بعد، بررسی خود را بین دو گزینه‌ی زیر محدود می‌کنیم:1-<ابتدا فشرده‌سازی و سپس رمزنگاری>2-<عدم استفاده از فشرده‌سازی و تنها اکتفا به رمزنگاری>و اما مشکل امنیتی!فرض کنید در میان مسیر میان دو رایانه که از طریق پروتکل ما با هم ارتباط برقرار می‌کنند، یک هکر قرار گرفته است و داده‌های رمزشده‌ی تبادلی را مشاهده می‌کند. در ساده‌ترین حالت هکر قادر است با مشاهده‌ی حجم بسته‌های رمزشده‌ی تبادلی به اطلاعاتی کلی از حجم پیام اصلی (رمزنشده) تبادلی دست یابد. این اطلاعات کلی، اگر با جزئیاتی از پیام‌های اصلی همراه شوند، می‌توانند حتی کلّ فرایند رمزنگاری را بی‌اثر کنند. باز هم به عنوان یک مثال خیلی خیلی ساده فرض کنید که رایانه‌ها تنها به یکدیگر تنها پیام‌های YES و NO ارسال می‌کنند و فرض کنید الگوریتم رمزنگاری به گونه‌ای باشد که رمزکردن YES منجر به تولید یک Ciphertext با طول 9 کاراکتر و رمزکردن NO منجر به تولید یک Ciphertext با طول 6 شود. در این صورت مهاجم بدون داشتن کلید و تنها با داشتن طول بسته‌های تبادلی می‌تواند به محتوای پیام‌ها دست یابد. این مسئله در الگوریتم‌های رمزنگاری، در بسیاری موارد اگر با الگوریتم‌های فشرده‌ساز همراه شوند، منجر به افشای اطلاعات بیشتری از پیام اصلی می‌شوند. به عبارت دیگر در مواردی که طراح پروتکل پیش از ارسال داده‌ها، آن‌ها را فشرده کند، اگر دقت کافی به خرج نداده باشد، به احتمال زیاد، کار استخراج اطلاعات کلی از داده‌های رمز شده را برای مهاجم ساده‌تر کرده است. به عنوان یک مثال از این کم دقتی، سیستمی را تصور کنید که پیام مهاجم به عنوان یک کاربر سامانه همراه پیام کاربر دیگری فشرده و سپس رمز و ارسال می‌شود. فرض کنید سیاست سامانه بر این است که هیچ کدام از کاربران نباید از پیام دیگر کاربران مطلع شوند:نمونه‌ی یک طراحی غیر امندر این طراحی، مهاجم (که یک کاربر سامانه است) می‌تواند با تولید ورودی‌های مختلف برای ماژول فشرده‌کننده و مشاهده‌ی سایز خروجی، به اطلاعاتی از پیام کاربر دیگر ارسال دست یابد. مثلا اگر اطلاع داشته باشد پیام کاربر دیگر یا AAAA و یا BBBB است، می‌تواند با فرستادن AAAA و مشاهده‌ی طول خروجی متوجه شود که آیا خروجی فشرده‌ساز نسبت به ورودی خیلی کمتر بوده (که یعنی پیام کاربر دیگر هم AAAA بوده و بنابراین داده‌ها خیلی فشرده شده اند) و یا متوجه شود که طول خروجی فشرده ساز نسبت به ورودی خیلی کمتر نیست (که یعنی پیام کاربر دیگر BBBB بوده و بنابراین داده‌ها خیلی فشرده نشده‌اند.چقدر این حملات جدی هستند و راه حل چیست؟متاسفانه علی‌رغم ظاهر پیچیده و غیر عملی این حملات، در دنیای امنیت و دنیای رمزنگاری و ریاضیات، این حملات خیلی تخیلی نیستند و هر از چندی یک رخنه‌ی امنیتی بر اساس این نقاط ضعف، در پروتکل‌های معروف کشف و معرفی می‌شود. در صورتی که علاقمند به نمونه‌های واقعی این حملات هستید، مطالعه‌ی حمله‌ی CRIME که یک آسیب‌پذیری روی نسخه‌های قدیمی SSL/TLS را هدف قرار داد و همچنین مطالعه‌ی مقاله‌ Phonotactic Reconstruction of Encrypted VoIP Conversations که در آن تلاش شده است با چنین تکنیکی، صوت را از ترافیک‌های VoIP رمزشده استخراج کند، برای شما جذاب خواهد بود. راه حل پیش‌گیری از این حملات و آسیب‌پذیری‌ها این است که حتی‌الامکان تا زمانی که مشکل Performance نداریم و تا زمانی که به درستی فرآیندهای پیاده‌سازی شده اطمینان نداریم، در عملیات‌های رمزنگاری از فشرده‌سازی استفاده نکنیم و داده‌ها را مستقیم رمز کرده و ارسال کنیم.سخن پایانی این که صمیمانه شما رو به نظرات مثبت و منفی، که مسلما همه‌ش به بهبود کیفیت این پست و پست‌های آتی کمک می‌کنند، دعوت می‌کنم. هر ایراد فنی/نگارشی و هر مورد از قلم افتاده‌ای رو از طریق نظرات بهم اطلاع بدید اصلاح می‌کنم. ممنون که [تا به اینجا] خوندید. :)

خلاقیت گوگل در مکان‌یابی افراد با توان سیگنال آنتن‌های BTS

ابراهیم قاسمی — Sat, 20 Jul 2019 23:06:16 +0430

یکی از دیگر روش‌های مکان‌یابی، در مواقعی که GPS تلفن همراه کاربر خاموش است، استفاده از آنالیز توان آنتن‌های BTSی است که تلفن همراه کاربر در محدوده‌ی سیگنال‌دهی آن‌ها قرار دارد. گوگل از جمله کمپانی‌هایی است که از این روش، برای بدست آوردن محل تقریبی کاربران استفاده می‌کند. اما به چه نحو؟گوشی شما همواره در معرض سیگنال آنتن‌های BTSهای مختلفی قرار داره و هر کدام از این سیگنال‌ها با مجموعه‌ای از ID‌هایی که درون سیگنال‌ها Advertise می‌شوند، به صورت یکتا از همدیگر قابل تفکیک هستند. تلفن همراه همیشه سعی می‌کند به قوی‌ترین سیگنال مجاز متصل شود.طبیعتا اپراتورها با توجه به این که از محل دقیق آنتن‌های BTS اطلاع دارند، با استفاده از داده‌های فوق، به راحتی قادر به شناسایی مکان افراد هستند. اما در مورد گوگل داستان کمی متفاوت هست. گوگل از مکان آنتن‌های BTS خبر ندارد، به همین دلیل از حقه‌ای زیبا بهره می‌برد.هنگامی که یک کاربر GPS گوشی خود را روشن کرده است، گوگل مقدار توان سیگنال آنتن‌های مختلف اطراف را اندازه‌گیری می‌کند و این مقادیر را به همراه IDهای مربوط به آن آنتن‌ها و همچنین به همراه عرض و طول جغرافیایی بدست آمده از GPS، درون دیتابیس‌های خود روی اینترنت آپلود می‌کند.به این ترتیب، در مواقعی که قصد تشخیص مکان تقریبی کاربر دیگری که GPS گوشی وی خاموش است ولی به اینترنت متصل است را داشته باشد، با بررسی توان سیگنال‌ها و مقدار IDها، می‌تواند مکان وی را تشخیص بدهد.با توجه به این که مقدار توان سیگنال آنتن‌های BTS و حتی مقادیر مربوط به IDهای سلول‌ها، بسته به تراکم جمعیت و آب و هوا ممکن است تغییر کند، گوگل نیاز دارد این عمل را به صورت دوره انجام دهد تا دیتابیس خود را به روز نگهداری کند.گوگل همچنی این تکنیک را با ID اکسس پوئینت‌های public فروشگاه‌های بزرگ هم انجام می‌دهد.سایت‌ها ونرم‌افزارهایی برای استخراج ID آنتن‌های BTS و مکان آن‌ها وجود دارد و شما می‌توانید با گوگل کردن عبارت Cell to GPS به اطلاعات کامل‌تری در این زمینه دست پیدا کنید.خروجی نرم‌افزار Cell Info Monitor روی اندرویدیک نمونه دیتابیس آنلاین از مختصات جغرافیایی آنتن‌های BTS

کانال ارتباطی امن ...

ابراهیم قاسمی — Sun, 14 Jul 2019 00:00:08 +0430

پرویز و پونه را تصور کنید که یک کلید رمزنگاری را -که هیچ‌کس دیگری از مقدار آن اطلاع ندارد- به روش مطمئنی با همدیگر به اشتراک گذاشته‌اند (مثلا فرض کنید در یک دیدار حضوری در پارک محل، روی استفاده از یک کلید خاص با یکدیگر توافق کرده اند). آن‌ها عهد کرده‌اند هر پیامی که قرار است بین‌شان تبادل شود، با این کلید و با یک الگوریتم رمزنگاری استاندارد و قوی، Encrypt شود. آیا در این صورت، کانال ارتباطی امنی بین آن‌ها به وجود آمده است؟پاسخ این سوال در تعریف کانال ارتباطی امن نهفته است.در ادبیات امنیت و رمزنگاری، تعاریف مختلفی از کانال ارتباطی امن وجود دارد. اگر همه‌ی آنچه از ویژگی‌هایی که در این تعابیر مختلف برای امن نامیده‌شدن یک کانال ارتباطی ذکر شده است را گرد هم آوریم، لیست زیر به دست می‌آید:حفظ محرمانگی (Confidentiality): محتوای پیام‌های تبادل شده، برای افراد میانی مسیر قابل استخراج و مشاهده نباشد.حفظ یکپارچگی (Integrity): در صورت تغییر پیام در میان مسیر، دریافت کننده، متوجه این تغییر بشود.حفظ حریم خصوصی (Privacy): با مشاهده‌ی پیام‌های رمزشده‌ی تبادلی، اطلاعات [مهمی] -نظیر رفتار کاربران- قابل استخراج نباشد.حفظ ترتیب و پیش‌گیری از تکرار (Reorder&Replay Attack Prevention): کاربر میانی نتواند با تکرار ارسال یک پیام رمز شده، یا با تغییر ترتیب ارسال بسته‌ها، برداشت اشتباهی از منظور فرستنده‎ی پیام در جهت دریافت کننده‌ی پیام ایجاد کند.با این تفسیر، آنچه با Encryption بدست می‌آید، تنها Confidentiality است و مدل معرفی شده در ابتدای این نگاره برای ارتباط پرویز و پونه، تنها حافظ محرمانگی پیام‌های تبادلی است. به عبارت دیگر، اگر پدر پونه، به عنوان مثال، یک بیت از مقدار رمز‌شده‌ی پیام ارسالی پرویز را در میان مسیر تغییر دهد، پونه، پیش و پس از خارج کردن مقدار دریافتی از حالت رمز، قادر به تشخیص این تغییر نیست.سوال احتمالی: اگه پدر پونه داده‌های رمزشده‌ی تبادلی بین مسیر را تغییر دهد، آنگاه در سمت دریافت کننده، پیام از رمز خارج نمی‌شود و به این نحو، دریافت کننده متوجه تغییر پیام می‌شود. درست است؟جواب: خیر! الگوریتم‌های رمزنگاری، توابعی ریاضیاتی هستند که از محتوای ورودی و درست و غلط بودن آن هیچ اطلاعاتی ندارند. از دید آن‌ها پیام رمز شده‌ی ورودی که قصد خارج کردن آن از رمز را دارند، تنها یک عدد است که باید روی آن محاسباتی انجام دهند و خروجی را باز پس دهند. بنابرین گزاره‌ی مطرح شده در فوق غلط است.سوال دوم: اگر پدر پونه پیام رمزشده پرویز را دستکاری کرده باشد، خروجی تابع رمزنگاری یک داده‎ی درهم و برهم خواهد شد و پونه که مثلا انتظار متنی از پرویز داشته است، الان با دریافت یک داده‌ی درهم، متوجه تغییر پیام در میان مسیر خواهد شد. درست است؟اگر فرض کنیم که پونه از این که پرویز قصد ارسال چه چیزی به او دارد اطلاع دارد، یک فرض به فرض های سوال اضافه کرده‌ایم و این فرض درستی نیست! علاوه بر این، مثالی را در نظر بگیرید که پرویز یک عکس یا یک فایل موسیقی به پونه ارسال کرده است. تغییر دادن محتوای یک بسته در میان مسیر توسط پدر پونه، منجر به این می‌شود که تنها قسمتی از عکس یا فایل صوتی دریافتی خراب باشد. پونه با روال فعلی قادر به تشخیص این نخواهد بود که آیا پرویز فایل معیوبی ارسال کرده است یا این که پیام در میان راه تغییر داده شده است.همچنین پدر پونه با زیر نظر گرفتن پیام‌های کانال ارتباطی، می‌تواند تحلیل‌هایی روی رفتار و داده‌های تبادلی بین آن‌ها انجام دهد. مثلا اگه چند بار مشاهده کرد که پونه بعد از دریافت پیام‌رمزشده‌ای که مقدار آن 0x112233445566 است از خانه بیرون می‌رود، می‌تواند تشخیص دهد این پیام قبل از رمز شدن حاوی جمله‌ای شبیه "از خانه بیرون بیا" است و این ناقض Privacy است.و علاوه بر موارد بالا، اگر پدر پونه، چندین پیام رمزشده‌ی پونه به پرویز را در میان مسیر نگهداری کند و با ترتیب دیگری ارسال کند یا یک پیام رمزشده را به جای یک بار 5 بار ارسال کند، پرویز قادر به تشخیص این موارد نخواهد بود.افزودن یکپارچگی با Digest یا MAC:فرض کنید پرویز و پونه، به جای قرارداد ساده‌ی بالا، چنین با هم وعده کنند که هر موقع تصمیم به ارسال پیامی داشته باشند، ابتدا از محتوای پیام یک مقدار Hash تولید کنند و سپس رمز شده‌ی پیام خود را به همراه مقدار Hash (که Digest نیز نامیده می‌شود) ارسال کنند. به عبارت دیگر پیام را به صورت زیر ارسال کنند:نمونه‎ی پیام ارسالی با اضافه کردن Hashاز طرف دیگر، دریافت کننده‌ی پیام هم پس از دریافت پیام، ابتدا قسمت رمز شده را از رمز خارج کند و سپس از مقدار آن، Hash تولید کند و اگر مقدار Hash تولید شده با مقدار Hash دریافتی به همراه پیام رمزشده یکسان بود، به تغییر نکردن پیام در میان مسیر اطمینان کند.اما چرا؟جواب: با توجه به این که پدر پونه کلید رمزنگاری X را ندارد، اگر قسمتی از داده‌ی رمز شده در پیام پرویز یا قسمتی از Hash آن یا حتی قسمتی از هر دو بخش آن را تغییر دهد، وقتی پونه بخش رمزشده را از رمز خارج می‌کند و از آن Hash تولید می‌کند، مقدار Hash داده‌ی جدید با مقدار Hash پیوست شده به پیام متفاوت خواهد بود.بنابراین با این تغییر، علاوه بر Confidentiality، فاکتور Integrity نیز در پیام‌های تبادلی حفظ می‌شود.مدل بالا ساختار ساده‌ای از پیاده‌سازی Integrity را بیان می‌کند. در پروتکل‌های امروزی، معمولا به جای استفاده از Hashهایی نظیر SHA و MD5، از الگوریتم‌هایی با عنوان الگوریتم‌های MAC یا Message Authentication Code استفاده می‌شود. این الگوریتم‌ها در نهایت همانند Hash یک Digest از پیام اصلی تولید می‌کنند، ولی با این تفاوت که برای تولید این Digest، همانند پروتکل‌های Encryption/Decryption نیاز به یک کلید دارند.حفظ ترتیب و پیش‌گیری از تکرار با Sequence Numberبا مدل توصیف شده در بالا، پدر پونه می‌تواند مانع رسیدن یک پیام به پرویز شود و پرویز از این اتفاق با خبر نمی‌شود. یا برعکس می‌تواند یک پیام پرویز را چندین بار متوالی پشت سر هم به پونه ارسال کند. با توجه به این که پونه قادر به تشخیص این تکرار خراب‌کارانه نیست، این عمل منجر به حمله‌ای به نام Replay Attack می‌شود. برای این که به اهمیت پیش‌گیری از Replay Attack پی ببرید، فرض کنید پدر پونه، بر حسب اتفاق پیام رمزشده‌ای از پرویز را 5 بار به پونه ارسال کند که محتوای آن "عزیزم به پدرت 100 هزارتومان پول بدهکارم، از حسابمان به او بده" است! در ارتباط بین یک کلاینت بانکی با سرور بانکی، چنین پیامی خیلی نامحتمل نیست. بنابراین لازم است به نحوی از این حملات پیشگیری شود.راه حل ساده‌ای که برای این مسئله وجود دارد، اضافه کردن یک Sequence Number به پیام است. به این صورت که پرویز و پونه قرار می‌گذارند برای هر یک عدد پیامی که به هم دیگر ارسال می‌کنند، در ابتدای هر پیام یک عدد اضافه کنند که این عدد، شماره‌ی تعداد پیام‌هایی است که تا به حال ارسال کرده‌اند و این عدد باید در مکانیزم Hash هم لحاظ شود. از طرف دیگر قرار می‌گذارند اگر یک پیام با Sequence Number تکراری دریافت کردند، از آن پیام چشم‌پوشی کنند. لازم به ذکر نیست که به وسیله‌ی این Sequence Number، پرویز و پونه حتی می‎توانند جابجایی پیام‌ها را تشخیص داده و اصلاح کنند.حفظ Privacy با ...؟حفظ حریم خصوصی، در سطح‌های مختلف، پیچیدگی‌های مختلفی دارد. یکی از روش‌هایی اولیه‌ای که به ذهن ممکن است برسد این است که برای حفظ حریم خصوصی در حد مشخص نشدن پیام‌های تکراری برای پدر پونه،پرویز و پونه با هم قرار بگذارند هر بار که قصد ارسال پیامی دارند، یک داده‌ی تصادفی تولید کنند و آن داده‌ی تصادفی را به نحوی در ابتدای پیام جای دهند و رمز کنند، که گیرنده پس از دریافت داده‌ی رمزشده و استخراج آن از حالت رمز، بداند از کجا تا به کجای خروجی، آن مقدار تصادفی است و باید حذف شود و از کجا تا به کجای خروجی، پیام اصلی است و باید پاسخ داده شود. به این مقدار تصادفی اصطلاحا Nonce گفته می‌شود. یکی دیگر از روش‌های حفظ حریم خصوصی استفاده از الگوریتم‌هایی است که علاوه بر کلید رمزنگاری به مقداری با عنوان IV یا Initial Vector نیاز دارند. مقدار IV نیز به صورت تصادفی انتخاب می‌شود و بعد به همراه داده‌ی رمزشده ارسال می‌شود. دریافت کننده که کلید رمزنگاری را دارد و مقدار IV را دریافت کرده است، قادر به رمزگشایی پیام است و از آنجا که با هر پیام یک مقدار تصادفی جدید توسط فرستنده برای IV تولید می‌شود، پیام‌های یکسان تکراری، مقدار رمزشده‌ی متفاوت خواهند داشت و پدر پونه به اطلاعاتی دست پیدا نمی‌کند. روش سوم این است که کلید ارتباطی به صورت دوره‌ای و در فواصل کوتاه (مثلا بعد از هر بار گفتگوی پونه و پرویز) تغییر کند و ...در همه‌ی روش‌های بالا (که به خاطر پیچیدگی‌های الگوریتم‌های مختلف رمزنگاری از جزئیات و ملاحظات تکنیکال هر کدام صرف نظر کردیم)، حریم خصوصی تنها تا حدی حفظ می‌شود و بعضی اطلاعات همچنان برای کاربر بیرونی قابل استخراج است. مثلا در همه‌ی روش‌ها، پدر پونه به هر حال به زمان شروع و پایان گفتگوی پرویز و پونه دست پیدا می‌کند. ممکن است این اطلاعات از نظر شما بی اهمیت باشد؛ ولی تصور کنید که یکی از مهم‌ترین حملاتی که در حال حاضر نهادهای امنیتی نظیر NSA روی شبکه‌ی TOR انجام می‌دهند، با هدف کسب همین نوع اطلاعات انجام می‌شود و نتیجه‌ی آن پیگیری و افشای هویت کاربرانی است که سعی در ناشناس ماندن دارند. جزئیات این حملات را اینجا می‌توانید بخوانید؛ ولی به طور خلاصه مهاجم با مشاهده‌ی زمان ورود درخواست کاربران به nodeهای ورودی شبکه و همچنین مشاهده‌ی زمان خروج درخواست‌ها از nodeهای خروجی شبکه، یک Timing Correlation انجام می‌دهد و کاربری را که به یک وب‌سرور خاص دسترسی پیدا می‌کند را پیدا می‌کند. یا به عنوان مثال دیگری، یک نهاد امنیتی قوی می‌تواند علی‌رغم این که قادر به رمزگشایی پیام‌های پیام‌رسانی مانند Signal نیست، با بررسی زمان ارسال ترافیک‌های مربوط به تماس این نرم‌افزار برای کاربران یک شبکه، کاربرانی که با هم مرتبط هستند را شناسایی کند.البته قابل ذکر است که آنچه در بالا از آن به عنوان حفظ حریم خصوصی یاد کردیم، می‌تواند با عنوان <از بین بردن قابلیت ردیابی> یا همان Traceability افراد و همچنین <حفظ گمنامی> یا Anonymity افراد نیز مطرح شود و شاید این دو واژه عبارت‌های بهتری برای آن باشند. علاوه بر این، کل محتوای این بند می‎تواند به تعبیری زیرمجموعه‎ی محرمانگی قرار داده شود.روی هم رفته، پیاده سازی پروتکلی که در مقابل این حملات مقاوم باشد به سادگی امکان پذیر نیست و اغلب راه‌هایی که وجود دارد به لحاظ Performance کارایی بالا ندارند. مثلا در مورد شبکه‌ی Tor، یکی از روش‌ها این است که nodeهای میانی، پیام‌هایی را که دریافت می‌کنند، با یک وقفه‌ی تصادفی به node بعدی ارسال کنند. یا روش دیگر این است که همواره بین nodeها، پیام‌هایی در حال تبادل باشد که از دید ناظر بیرونی (مهاجم) قابل تفکیک از پیام‌های اصلی نباشد ولی برای خود nodeهای شبکه، قابل تمییز از پیام‌های واقعی باشند.دسترس پذیری یا Availability کانال ارتباطی رو فراموش کردیم؟خیر؛ دسترس پذیری به این معناست که کانال ارتباطی همواره وجود داشته باشد. تامین این ویژگی برای کانال ارتباطی، خیلی از دیدگاه رمزنگاری و امنیتی قابل تامین نیست؛ بلکه روش‌هایی نظیر تامین پهنای باند کافی و تهیه‌ی Replication و پیاده‌سازی مکانیزم‌های High Availability پاسخ‌گوی آن است. به همین دلیل در ابتدای متن اصلی به آن اشاره نکردیم. البته لازم به ذکر است که برای دسترس پذیری کانال ارتباطی موارد دیگری شامل مقاوم بودن سیستم (اعم از خود بستر ارتباطی و نرم‌افزارها و تجهیزات طول مسیر) در برابر حملات DoS و همچنین صحت عملکرد و سرویس‌دهی مداوم همه‌ی تجهیزات و نرم‌افزارها به کاربران احراز هویت شده نیز مورد نیاز است و دسترس‌پذیری محدود به وجود بستر شبکه‌ای کانال ارتباطی نیست.مسئله‌ی Forward Secrecyیکی از مسائلی که در ارتباط امن جدیدا مورد توجه قرار گرفته است این است که اگر به نحوی کلیدهای رمزنگاری روی یک رایانه به خطر افتاد و افشا شد، با آن کلیدها، تنها آخرین نشست و آخرین تبادل پیام رمزشده قابل رمزگشایی باشد و مثلا اگر مهاجم ترافیک رمزشده‌ی روزهای قبل را جایی ذخیره و نگهداری کرده است، با کلیدهایی که امروز بدست آورده است نتواند آن‌ها را رمزگشایی کند. ارتباط و الگوریتمی که این ویژگی را دارد، اصطلاحا Forward Secrecy یا همان Perfect Forward Secrecy دارد. این ویژگی، یک ویژگی کانال ارتباطی نیست، بلکه یک ویژگی پروتکل ارتباطی است. به همین دلیل از آوردن آن در لیست ویژگی‌های کانال امن صرف نظر کردیم.از آنجایی که شایعاتی وجود دارد مبنی بر این که نهادهای جاسوسی/امنیتی نظیر NSA، همه‌ی ترافیک‌های رمزشده‌ی حساس دنیا را Capture و ذخیره می‌کنند تا اگر به نحوی روزی قادر به رمزگشایی آن‌ها بودند (مثلا با بدست آوردن کلیدهای سرورها و کاربران یا با بدست آوردن قدرت شکستن الگوریتم)، اطلاعات درون آن‌ها را از دست ندهند، این ویژگی بیشتر مورد توجه قرار گرفت و در نسخه‌های اخیر TLS به پروتکل اضافه شد. پس تبادل کلید امن چی؟در شرح سوالی که ابتدای این نگاره مطرح کردیم، فرض کردیم پرویز و پونه کلید رمزنگاری را به صورت Face2Face با همدیگر به اشتراک گذاشته اند. این عمل در واقعیت برای ارتباط‌های اینترنتی امکان پذیر نیست و نیازمند فرایندی هستیم که کاربران بتوانند به صورت کاملا امن، کلیدهای رمزنگاری اولیه را (Pre-Shared Key) با هم به اشتراک بگذارند. الگوریتم‌های Key Exchange وظیفه‌ی پیاده‌سازی این فرایند را بر عهده دارند. از آنجایی که این ویژگی نیز همانند ویژگی Forward Secrecy، از ویژگی‌های پروتکل ارتباطی است و به خود کانال ارتباطی امن ارتباطی ندارد، در آینده در ارتباط با نحوه‌ی انجام آن پستی جداگانه خواهیم نوشت.احراز هویت یا Authentication؟در ارتباط پرویز و پونه شاید این مسئله خیلی مورد توجه نباشد. اما حالتی را تصور کنید که علاوه بر پرویز و پونه، کاربران دیگری در این شبکه تبادل پیام وجود دارند. با موارد ذکر شده در فوق، اگرچه برای هر کاربر امکان تمییز پیام‌های دیگر کاربران از همدیگر وجود دارد (با این فرض که هر دو کاربر موجود، برای تبادل پیام، یک کلید منحصربفرد محرمانه با یکدیگر به اشتراک گذاشته باشند و فرد دیگری از آن اطلاع نداشته باشد)، اما این تمییز پیام به روش بهینه‌ای قابل انجام نیست. برای حل این مشکل (یعنی برای احراز هویت و تمییز پیام کاربران مختلف از همدیگر)، امضاهای دیجیتالی پا به عرصه‌ی وجود گذاشتند. در پست‌های آتی در ارتباط با این مکانیزم‌ها به صورت مفصل خواهیم نوشت. سخن پایانی این که، از یاشار عزیز مجددا بابت review تشکر می‌کنم. همچنین از حسین عبدی عزیز بابت کامنت فوق‌العاده‌ای که گذاشت و باعث اصلاح قسمت‌های مهمی از متن شد تشکر می‌کنم و توصیه میکنم حتما کامنت رو بخونید و بعد صمیمانه شما رو به نظرات مثبت و منفی، که مسلما همه‌ش به بهبود کیفیت این پست و پست‌های آتی کمک می‌کنند، دعوت می‌کنم. هر ایراد فنی/نگارشی و هر مورد از قلم افتاده‌ای رو از طریق نظرات بهم اطلاع بدید اصلاح می‌کنم. دوباره ممنون که [تا به اینجا] خوندید. :)

بدافزارها و DNS

ابراهیم قاسمی — Thu, 11 Jul 2019 17:01:04 +0430

ناگفته می‌دانید که پروتکل DNS یا Domain Name System در کنار پروتکل‌هایی چون HTTP، SNMP، و HTTPS، یکی از معروف‌ترین پروتکل‌های شبکه است و قسمت عمده‌ای از اتفاقاتی که دور از نگاه کاربر، در پسِ زمینه‌ی مرورگر و درون شبکه انجام می‌شود تبادل بسته‌های این پروتکل بین رایانه‌ی کاربر و سرورهای DNS یا سرورهای DNS Cache است. در این مقاله قصد داریم در گام نخست با معرفی و شرح علت نیاز به این پروتکل آغاز کنیم و با نحوه‌ی عملکرد آن آشنا شویم و پس از آن با بر شمردن ویژگی‌هایی از DNS، علت جذابیت و نحوه‌ی استفاده از آن توسط بعضی توسعه‌دهندگان بدافزار را ارائه دهیم. در صورتی که احساس می‌کنید پروتکل DNS را به قدر کافی می‌شناسید، از خواندن پاراگراف‌های زیر تا ابتدای پاراگراف “گام پنجم” صرف نظر کنید.واژه نامهبه جهت حفظ یکپارچگی متن، در ابتدای این نگاره، اصلاحاتی که در ادامه ظاهر می‌شوند را معرفی می‌کنیم.– میزبان یا Host: یک فضای حافظه‌ی همیشه در دسترس درون اینترنت که در واقع یک رایانه‌ی همیشه روشن و همیشه متصل به اینترنت است که فایل‌های مرتبط به وب‌سایت (نظیر متن‌ها و عکس‌ها) بر روی آن بارگذاری می‌شوند. – دامنه یا Domain: یک نام یکتا برای وب‌سایت که کاربران با وارد کردن آن درون مرورگر، به سایت شما دسترسی پیدا می‌کنند.– Web Server: این واژه هم به سخت افزار Host و هم به نرم‌افزاری روی Host که وظیفه‌ی اجرای نرم‌افزار وب‌سایت را بر عهده دارد، اطلاق می‌شود. در مورد نرم‌افزار می‌توان از Apache و IIS به عنوان نمونه‌هایی از Web Serverها اشاره کرد.– Web Application: نرم‌افزار وب‌سایت است که وظیفه‌ی پردازش و پاسخگویی به درخواست‌های کاربران را بر عهده دارد. این نرم‌افزار می‌تواند به زبان‌های مختلفی شامل PHP، پایتون، جاوا، سی‌شارپ و حتی C توسعه داده شود. وب‌سرور و Web Application اغلب به اشتباه به جای همدیگر به کار برده می‌شوند.– RAT: مختصر شده‌ی Remote Access Trojan است و همانطور که از نام آن بر می‌آید، بدافزاری است که به وسیله‌ی آن توسعه دهنده‌ی بد افزار از دور می‌تواند روی رایانه‌ی قربانی دستوراتی اجرا نماید. این دستورات به عنوان مثال می‌تواند شامل حذف کردن یا ارسال کردن لیستی از فایل‌های قربانی باشند. چند نمونه از RATهای متن‌باز: اینجا، اینجا و اینجا!– Botnet: بدافزاری است که از آن معمولا برای انجام حملات DDoS استفاده می‌شود. در این نوع حملات، تعداد زیادی Botnet که همگی تحت اختیار یک توسعه‌ی دهنده‌ی بدافزار هستند، به صورت همزمان و معمولا با دستور توسعه دهنده‌ی بدافزار، اقدام به ارسال ترافیک حمله به یک وب‌سایت می‌کنند.– C&C: سروری است که بدافزارنویس از آن برای ارتباط با بدافزارهای خود استفاده می‌کند. C&C مخفف Command & Control است و با C2 نیز نمایش داده می‌شود. این رایانه در واقع واسطه‌ی بین توسعه‌دهنده‌ی بدافزار و بدافزار نصب شده روی رایانه‌ی قربانیان می‌شود و بدافزارنویس باید به هر نحوی می‌تواند ارتباط بین بدافزارها و این سرور را مخفی و غیرقابل مسدود کردن نماید.گام نخست: DNS چیست؟ چگونه عمل می‌کند؟نقش اصلی DNS به صورت خلاصه، تبدیل نام‌های دامنه به آدرس‌های IP است. به عبارت ساده‌تر و به عنوان مثال، نقش این پروتکل تبدیل دامنه‌ی www.google.com به آدرس آی‌پی 172.217.22.36 (یا مقادیر IPهای دیگر این دامنه) است. اما چرا به چنین پروتکلی نیاز است؟جواب این سوال در دو گزاره خلاصه ‌می‌شود:پروتکل‌های اصلی شبکه که اینترنت بر پایه‌ی آن‌ها سوار است و از آن‌ها برای تبادل بسته‌ها بین nodeهای مختلف شبکه (مثلا بین رایانه‌ی کاربر و یک وب‌سرور) استفاده می‌شوند، به آدرس IP طرفین نیاز دارند و دامنه‌ی سایت برای آن‌ها کاربردی ندارد.به خاطر سپردن نام دامنه‌ی سایت‌های مختلف، برای افراد بسیار ساده‌تر از به خاطر سپردن آدرس IP سایت‌ها است. بنابراین پروتکل DNS با تبدیل نام دامنه به آدرس IP، کمک می‌کند که کاربران بتوانند بدون فشار به سلول‌های خاکستری، از پروتکل‎های متداول شبکه (در این مورد پروتکل IP یا همان Internet Protocol) استفاده کنند.بد نیست بدانید که پروتکل DNS علاوه بر نقش ذکر شده در فوق، کاربردهای متنوع دیگری نیز دارد. به عنوان مثال می‌توان در DNS Serverها با تعریف کردن یک مقدار IP واحد برای چندین دامنه‌ی مختلف، روی یک سروریک Virtual Hosting پیاده سازی کرد. همچنین می‌توان برای یک دامنه‌ی واحد چندین IP مختلف تعریف کرد و DNS Server را به نحوی تنظیم کرد که در پاسخ هر بار Query، یکی از آن مقادیر IPها را برای آن دامنه‌ی مذکور، به درخواست کننده باز گرداند و به این وسیله از آن به عنوان یک Load Balancer ساده بهره برد. از دیگر کاربردهای جالب DNS، تقسیم ترافیک بسته به موقعیت جغرافیایی درخواست دهنده‌ی DNS Query بین CDNهای یک وب‌سایت است.گام دوم: تا به اینجا با ماهیت و قابلیت‌های این پروتکل آشنا شدیم. اما نحوه‌ی استفاده از این پروتکل و نحوه‌ی عملکرد آن به چه صورت است؟برای پاسخ به این سوال، بهتر است به صورت اجمالی نحوه‌ی ایجاد/به‌وجودآمدن یک وب‌سایت در اینترنت را بیان کنیم.برای داشتن یک وب‌سایت شما به دو مورد نیاز دارید:۱- Host۲- یک دامنه‌ی یکتا که درون DNS Server وب‌سایت، آن را به آدرس IP هوست خود Map کنید.سوال: اگر از قوی بودن حافظه‌ی کاربران وب‌سایت خود برای به خاطر سپردن IP وب‌سایت خود، اطمینان داشته باشیم، آیا می‌توانیم از خیر داشتن دامنه‌ برای وب‌سایت بگذریم و به جای آن تنها آدرس IP را در اختیار کاربران قرار دهیم؟پاسخ:هم بله و هم خیر! هنگامی که شما در صدد خرید Host برمی‌آیید، از طرف فروشندگان با دو گزینه مواجه می‌شوید:۱- هوست اختصاصی یا Dedicated Host۲- هوست اشتراکی یا Shared Hostدر هوست اختصاصی، فروشنده یک رایانه‌ی مجزا (در واقع یک IP مجزا)، تنها و تنها در اختیار شما قرار می‌دهد و روی آن رایانه، وب‌سایت دیگری وجود ندارد و بنابراین همه‌ی ترافیک‌های دریافتی را به نرم‌افزار وبسایت شما ارسال می‌کند؛ اما در هوست اشتراکی که از هوست اختصاصی به مراتب ارزان‌تر است، فروشنده آن رایانه را در اختیار چند نفر قرار می‌دهد و ترافیک‌های دریافتی را خودش، با توجه به فیلدهایی درون بسته‌های دریافتی، بین نرم‌افزار وب‌سایت هر کدام از سایت‌ها تقسیم می‌کند.در صورتی که شما هوست اختصاصی خرید کرده باشید، می‌توانید از خیر خرید دامنه بگذرید و با آدرس IP کاربران‌تان را به وب‌سایت خود هدایت کنید، اما در صورتی که از هوست اشتراکی استفاده می‌کنید، با توجه به این که فیلدهای تفکیک کننده‌ی ترافیک شما از ترافیک سایر وب‌سایت‌های روی آن هوست، از نام دامنه بدست می‌آیند، لازم است که برای وب‌سایت خود یک دامنه‌ی یکتا خریداری کنید. (در آینده توضیح خواهیم داد که این “لازم است”، “باید” نیست و می‌توان به نحوی آن را دور زد!).گام سوم: اما برای بدست آوردن دامنه و Host و اتصال آن‌ها به یکدیگر باید چه کنیم؟برای خرید دامنه می‌توانید به وبسایت irnic یا وبسایت‌هایی که با واسطه از این سایت برای شما دامنه خریداری می‌کنند (مانند iranhost، hostiran، iranserver یا mihanwebhost) مراجعه کنید و پس از ارائه‌ی یک مجموعه اطلاعات احراز هویتی و تشکیل حساب کاربری، یک دامنه‌ی یکتا خریداری کنید. پس از آن نیز از یک فروشنده‌ی host (که اغلب فروشندگان دامنه، فروشنده‌ی host نیز هستند)، یک host خریداری می‌کنید. در خریداری host، علاوه بر این که شما امکان خریداری host اختصاصی یا اشتراکی دارید، گزینه‌های متنوعی از قبیل سیستم‌عامل سرور، مقدار حافظه‌ی هارد دیسک، مقدار RAM، مقدار پهنای باند و حتی تعداد هسته‌ی CPU نیز در اختیار شماست که باید با توجه به نیازمندی‌های وب‌سایت خود آن‌ها را بهینه انتخاب نمایید.پس از خریداری Host، فروشنده‌ی Host اولا از شما نام دامنه‌ی وب‌سایت‌تان را درخواست می‌کند و سپس آدرس Name Server خود را در اختیار شما قرار می‌دهد و از شما می‌خواهد که آدرس این Name Serverها را در فیلدهایی با همین نام درون پنل مدیریتی دامنه، که فروشنده‌ی دامنه در اختیار شما قرار داده است، ذخیره نمایید (با توجه به این که تنها شما نام‌کاربری و رمز عبور پنل مدیریتی دامنه را در اختیار دارید، تنها شما می‌توانید برای دامنه Name Server تنظیم کنید). فروشنده‌ی Host، پس از دریافت کردن نام دامنه از شما، درون جدولی از DNS Server خودش، آن نام دامنه را به IP سروری که از وی خریداری کرده‌اید Map می‌کند.گام چهارم: داستان DNS از اینجا آغاز می‌شود!از این پس وقتی کاربری وارد مرورگر می‌شود و نام دامنه‌ی شما را وارد می‌کند (یا حتی یک زیردامنه از دامنه‌ی شما را وارد می‌کند) و کلید Enter را می‎فشارد، یک DNS Query به DNS Serverی که روی رایانه‌اش تنظیم کرده است ارسال می‌شود و درون این DNS Query از آن درخواست می‌کند که آدرس IP دامنه‌ی وب‌سایت شما را به وی بازگرداند. DNS Server دریافت کننده‌ی درخواست کاربر (مثلا 8.8.8.8 یا 4.2.2.4)، عموما DNS Server فروشنده‌ی Host شما نیست، اما می‌داند برای بدست آوردن آدرس IP دامنه‌ی شما، این سوال کاربر را باید به کدام DNS Server ارجاع دهد (باید به DNS Server فروشنده‌ی Host شما که آدرس آن را در پنل مربوط به فروشنده‌ی دامنه وارد کردید ارجاع دهد. 8.8.8.8 یا 4.2.2.4 این اطلاعات را از فروشنده‎‌ی دامنه‌ی شما دریافت کرده‌اند). در نهایت، بسته به نحوه‌ی تنظیمات DNS Server و همچنین بسته به نوع DNS Query، سرور 8.8.8.8 به یکی از دو صورت زیر (تصاویر ۱ و ۲)، DNS Query کاربر را به DNS Server فروشنده‌ی Host می‌رساند. این DNS Server نیز در پاسخ، آدرس IP سروری که نرم‎افزار وب‌سایت شما روی آن است (آدرس Host) را یا مستقیما به کاربر یا با واسطه‌ی 8.8.8.8 به کاربر باز‌می‌گرداند. کاربر/مرورگر با دریافت کردن IP، یک بسته‌ی اینترنتی HTTP/HTTPS تولید می‌کند و به مقصد آن IP ارسال می‌کند.در توضیح تصاویر فوق به این نکته اکتفا می‌کنیم که، درخواست‌های DNS کلاینت به سمت DNS Server تنظیم شده در رایانه، یکی از دو مدل Iterative یا Recursive می‌توانند باشند. در مدل Iterative کلاینت از DNS Server درخواست می‌کند که یا آدرس IP دامنه‌ی پرسش شده را به وی بازگرداند و یا آدرس DNS Serverی که از آن IP اطلاع دارد. به عبارت دیگر، در صورتی که DNS Server مقدار IP دامنه‌ی مورد جستجو را نمی‌داند، نیازی به آن نیست که برای جستجوی آن از سایر DNS Serverها تلاشی انجام دهد. در مدل Recursive که مدل پیش‌فرض DNS Queryهای سیستم عامل‌ها است، کلاینت از DNS Server درخواست می‌کند مقدار IP دامنه‌ی پرسش شده را به هر نحو که شده به دست آورد و به وی اطلاع دهد. در این مدل مانند شکل، ممکن است DNS Server پرسش کاربر را به DNS Server دیگری ارجاع دهد و پس از یک توالی جواب را دریافت کند و به کاربر باز پس فرستد.تصاویر زیر به روشن شدن آنچه تا کنون ذکر شد، کمک می‌کنند:کاربر دو DNS Query برای دامنه‌ی 0x01.ir به سرورهای 8.8.8.8 و 4.2.2.4 که DNS Serverهای گوگل هستند ارسال می‌کند.آنچه توسط فایروال شبکه‌ی کاربر مشاهده می‌شود.گوگل DNS Query دریافتی را به کمک سرورهای خود به سمت DNS Server تنظیم شده‌ی دامنه ارسال می‌کند و جواب را به کاربر باز‌می‌گرداند. (11.22.33.44)گفتیم برای Hostهای اشتراکی، سرور دریافت کننده‌ی بسته‌ها برای تفکیک بسته‌های وب‌سایت‌های مختلف به فیلدهایی درون بسته‌ها نیاز دارد که از نام دامنه بدست می‌آیند. این فیلدهای برای ترافیک HTTP فیلد Host است که در HTTP Header ظاهر می‌شود و برای ترافیک HTTPS فیلدی با نام SNI یا Server Name Indication است که درون بسته‌ی Client Hello (اولین بسته‌ی پروتکل HTTPS بعد از TCP Handshake) قرار می‌گیرد. مقدار این فیلدها دقیقا معادل همان دامنه‌ای است که کاربر درون نوار آدرس مرورگر وارد می‌کند و Enter را می‌فشارد.نکته: هم سیستم‌عامل کاربر و هم یک سری رایانه‌های بین مسیر بسته‌های کاربر تا DNS Serverها، سوال و پاسخ DNS تبادل شده را تا مدت زمانی Cache می‌کنند. بنابراین وقتی مرورگر کاربر در یک نشست دیگر، مجددا بسته‌ی DNS Query برای آن دامنه ارسال می‌کند، ممکن است این‌بار پاسخ توسط OS یا یک رایانه‌ی بین مسیر یا توسط 8.8.8.8 به مرورگر ارسال شود و بسته‌ی DNS Query به DNS Server فروشنده‌ی Host نرسد. مقدار Timeout این Cache کردن‌ها قابل تنظیم است.سوال: فایل Hosts که درون سیستم‌های لینوکسی در مسیر etc/hosts/ و در سیستم‌های ویندوزی در مسیر C:\Windows\System32\Drivers\etc\hosts وجود دارد چیست؟پاسخ:سیستم‌عامل همیشه پیش از این که DNS Query یک دامنه را به DNS Server تنظیم شده روی رایانه ارسال کند، درون یک فایل local که آدرس آن در متن سوال آمده است، به دنبال آدرس IP آن دامنه می‌گردد. در صورتی که مقدار IP دامنه‌ی مورد جستجو را پیدا کند، از مراجعه به DNS Server صرف نظر می‌کند. استفاده از این فایل مزایا و معایب مختلفی دارد. از مزیت‌های آن می‌توان به افزایش سرعت وب‌گردی (با حذف زمان مورد نیاز برای DNS Query) وهمچنین از بین رفتن امکان حمله‌ی DNS Spoofing (در پست‌های آتی در مورد آن خواهیم نوشت) اشاره کرد و از معایب آن می‌توان به این اشاره کرد که در صورت تغییر آدرس IP وب‌سایت، کاربر نیاز دارد به صورت دستی آدرس جدید را در فایل بازنویسی کند.خب بعد از این که با مفاهیم مرتبط با DNS و نحوه‌ی عملکرد آن آشنا شدیم، سوال ابتدایی مقاله را مطرح می‌کنیم:گام پنجم: علت جذابیت پروتکل DNS برای توسعه دهندگان بدافزار چیست؟همانطور که در مقدمه گفتیم، توسعه‌دهنده‌ی بدافزار برای ارتباط با بدافزار‌های نصب شده از رایانه‌ای با نام C&C استفاده می‌کند. در تصویر زیر یک تصویر ساده از ساختاری که توصیف شد، مشاهده می‌کنیم:از آنجایی که هدف بدافزارنویس مخفی کردن این ارتباط از شناسایی و مسدود شدن است، همانطور که حدس می‌زنید، پروتکل DNS از چند جهت برای توسعه‌دهنده‌ی بدافزار جذاب است:۱- در سازمان‌های حساس، به صورت معمول دسترسی کاربران به اینترنت مسدود می‌شود و تنها استفاده از پورتال‌های سازمانی برای آن‌ها امکان پذیر است. با این وجود در این سازمان‌ها، به صورت معمول یک DNS Server برای Resolve کردن مقدار IP دامنه‌های درون سازمانی و همچنین برای Resolve کردن DNS Queryهای سیستم‌های خاصی که دسترسی آن‌ها به اینترنت محدود نشده است، وجود دارد. در اغلب موارد این DNS Server به صورت صحیح Config نمی‌شود و برای کاربرانی که قرار است تنها دسترسی به پورتال‌های درون سازمانی داشته باشند نیز امکان Resolve کردن مقدار IP دامنه‌های غیر سازمانی وجود دارد. بدافزار نویسان از این اشتباه Configuration استفاده می‌کنند تا به عنوان مثال با ارسال DNS Query برای salam.site.com، به DNS Server دامنه‌ی site.com، کلید واژه‌ی salam را ارسال کنند.۲- به یمن وجود پروتکل DNS، دیگر نیازی به آن نیست که لیست ثابتی از IP سرورهای C&C خود را درون فایل اجرایی بدافزار ذخیره (اصلاحا Hard Code) نماید و کافی است که یک/چند دامنه ثبت کند و نام این دامنه‌ها را در بدافزار ذخیره کند. به این وسیله هر زمان که یکی از سرورهای C&C مورد حمله قرار گرفت یا IP آن مسدود شد و یا به نحوی برای آن مشکلی به وجود آمد، تنها کاری که توسعه دهنده‌ی بدافزار نیاز است انجام دهد، تغییر مقدار IP آن دامنه در سرورهای DNS است. این در حالی است که بدون استفاده از قابلیت DNS، توسعه دهنده‌ی بد افزار در صورت رخ دادن مشکلی برای سرورهای C&C ، ناگریز بود که فایل‌های بدافزار جدید که حاوی آدرس IP جدید هستند تولید کند و سیستم‌های قربانیان خود را با فایل‌های جدید مجددا آلود کند.همانطور که آدرس‌های IP ممکن است توسط فایروال‌ها مسدود شوند، Queryهای DNS یک دامنه هم قابل مسدود شدن هستند. توسعه‌دهنده‌های بدافزار برای حل مشکل مسدود شدن دامنه‌ها، دست به دامان الگوریتم‌هایی با عنوان الگوریتم تولید نام دامنه اختصاصی شدند؛ که خروجی آن‌ها نام دامنه‌های منحصربفرد (و مثلا تابعی از زمان) است. بد افزار با فراخوانی دوره‌ای این تابع، دامنه‌ی جدیدی که باید برای آن DNS Query ارسال کند را بدست می‌آورد و با توجه به ماهیت این تابع، کسی جز توسعه دهنده بدافزار از نام دامنه‌ای که تولید می‌شود اطلاعی ندارد. بنابراین بدافزارنویس، پیش از این که دامنه‌ی جدید توسط بدافزار استفاده شود، با ثبت دامنه، مقصد ترافیک بدافزار را به صورت دوره‌ای تغییر می‌دهد و ارتباط مستمر بدافزار با C&C به این صورت حفظ می‌شود. با توجه به این که در این روش، مسدود کردن ترافیک DNS Queryها، مستلزم استخراج الگوریتم تولیدکننده‌ی نام دامنه به روش مهندسی معکوس فایل اجرایی بدافزار است و این کار می‌تواند بسیار پیچیده باشد، این روش که قدمتی بیش از ۱۰ سال دارد، همچنان بین بدافزار نویسان محبوبیت خاصی دارد.۳- علی‌رغم این که ترافیک‌های HTTP و HTTPS برای فایروال‌ها و کارشناسان امنیت سازمان‌ها همواره مهم و مورد توجه بوده و روی آن‌ها نظارت می‌شود، ترافیک DNS با توجه به این که خطرناک بودن آن برای همه محرز نیست، اغلب مورد بررسی و توجه کافی قرار نمی‌گیرد. بنابراین، برای مخفی نگاه داشتن یک ارتباط، استفاده از آن از نگاه بدافزار نویس جذاب است.۴- به نحوی از پروتکل DNS سوء استفاده کند که پیام‌های تبادلی بین رایانه‌های آلوده و سرور C&C در قالب بسته‌های DNS جابجا شوند و توسط Firewall شناسایی و مسدود نشوند.موارد اول تا سوم، واضح و مشخص است. آنچه در این مقاله در مورد آن صحبت می‌کنیم، کاربرد چهارم است. Firewallها در سازمان‌ها و شبکه‌های مهم (که معمولا از اهداف اصلی بدافزارنویسان نیز هستند)، غالبا به گونه‌ای تنظیم می‌شوند که ترافیک شبکه‌ی داخلی به شبکه‌ی خارجی تنها با پروتکل‌های مشخص (مثلا DNS، HTTP و TLS) و پورت‌های مقصد مشخص (مثلا ۵۳، ۸۰ و ۴۴۳) قابل ارسال باشد و علاوه بر این، ادمین‌های شبکه، با نظارت بر ترافیک تبادلی، مقصدهای مشکوک ترافیک را شناسایی و مسدود می‌کنند. به همین دلیل، بدافزارنویس نیاز دارد ترافیک خود را درون یکی از این پروتکل‌های مجاز تبادل کند و علاوه بر این باید سعی کند یک مقصد معتبر را واسطه‌ی ترافیک بین بدافزار خود و سرور C&C قرار دهد.اینجاست که پروتکل DNS یک چشمک زیبا حواله‌ی چشمان توسعه دهنده‌ی بدافزار می‌کند. وی با ثبت یک دامنه و تنظیم DNS Server آن دامنه به یکی از سرورهای خودش (همان سرور C&C، به جای DNS Server فروشندگان Host)، باعث می‌شود درخواست‌های DNS مربوط به آن دامنه (و همه‌ی Subdomainهای آن دامنه)، به سرور تحت اختیار خودش هدایت شوند. از طرف دیگر بد افزار خود را به نحوی توسعه می‌دهد که اطلاعات را در قالب DNS Query به سرور مذکور ارسال نماید.به عنوان مثال فرض کنید بد افزار قصد ارسال اطلاعات زیر را به سرور C&C دارد:Infected System MAC Address, Infected System Username, Infected System IP Addressبرای این منظور بد افزار اطلاعات فوق را استخراج کرده و مثلا برای parse کردن ساده‌تر با – از هم جدا می‌کند و آنگاه از همه‌ی اطلاعات base64 (یک نوع encoding برای نمایش داده‌هایی که ممکن است معادل ascii نداشته باشند) تولید می‌کند. خروجی نمونه به صورت زیر خواهد بود:پس از این، بد افزار یک DNS Query برای زیردامنه‌ای از دامنه‌های بدافزارنویس به صورت زیر ارسال می‌کند:MTE6MjI6MzM6NDQ6NTU6NjYtYWRtaW4tMTAuMjAuMzAuNDA=.hackerdomain.comهمانطور که حدس می‌زنید، درخواست DNS فوق، از رایانه‌ی کاربر آلوده شده، به سمت DNS Server تنظیم شده روی رایانه اش (مثلا 8.8.8.8) هدایت می‌شود. پس از رسیدن به این سرور، با توجه به این که این سرور جواب Query را نمی‌داند، آن را به DNS Serverی که انتظار می‌رود پاسخ را بداند، ارسال می‌کند. به عبارت دیگر با توجه به این که 8.8.8.8 انتظار دارد DNS Server دامنه‌ی hackerdomain.com جواب Query فوق را بداند، آن را (با چندین واسطه) به رایانه DNS Serverی که بد افزارنویس تنظیم کرده است (در واقع به سرور C&C) ارسال می‌کند. بد افزار نویس پس از دریافت و Decode کردن پیام دریافتی، می‌تواند با یک دستور (همچنان در قالب پیام‌های DNS) به بدافزار فرمانی ارسال کند. مثلا می‌تواند در بدافزار قرارداد کرده باشد که اگر در پاسخ Queryها مقدار IP برابر با 1.1.1.1 دریافت کردی رایانه را فرمت کن، و اگر پاسخ با مقدار IP برابر با 2.2.2.2 دریافت کردی، لیست فایل‌های فلان دایرکتوری را به من ارسال کن. همه‌ی این پیام‌ها در قالب پرسش و پاسخ‌های DNS ارسال می‌شوند و Firewall چیزی جز تعدادی بسته‌ی DNS بین کاربر و سرور 8.8.8.8 مشاهده نمی‌کند.چنین استفاده‌ی نامتعارفی از پروتکل DNS محدود به توسعه‌دهنگان بدافزار نیست. توسعه دهندگان ابزارهای فیلترشکن نیز از این تکنیک برای دورزدن فیلترینگ استفاده می‌کنند (VPN over DNS). تنها ایراد آن کند بودن آن به نسبت روش‌های مبتنی ایجاد Tunnel با VPS است. البته برای افزایش سرعت می‌توان از Typeهای دیگری از DNS Query (مانند TXT Type که در آن می‌توان حجم بزرگتری داده را در یک بسته دریافت کرد) نیز استفاده کرد، ولی با این حال نرخ ارسال و دریافت داده پایین است.گام ششم: روش‌های شناسایی و مقابله با DNSهای مربوط به بدافزارپیش‌گیری از آلوده شدن و مانیتورینگ … مانیتورینگ … مانیتورینگ! با توجه به ماهیت رفتاری این بدافزارها، با مانیتور کردن دامنه‌هایی که برای آن‌ها DNS Query ارسال می‌شود، می‌توان با مشاهده‌ی دامنه‌های مشکوک (مثلا دامنه‌هایی که برای Subdomainهای عجیب و غریب آن‌ها DNS Query های بسیاری ارسال می‌شود)، آن‌ها را مسدود کرد. علاوه بر این، فایروال‌ها به صورت اتوماتیک همواره با دامنه‌هایی که نباید برای آن‌ها DNS Query ارسال شود به روز رسانی می‌شوند. همچنین این امکان وجود دارد که DNS Serverهای مجاز لیستی از دامنه‌های مشکوک نگهداری کنند و در صورت دریافت Query برای آن دامنه‌ها، از ارسال آن‌ها به سرورهای C&C خودداری کنند. برای پیاده سازی ساده‌تر این راهکار، شرکت‌های مهم، ترافیک DNS به DNS Server های خارج سازمان را مسدود می‌کنند و کاربران را ملزم به استفاده از DNS Server سازمانی/داخلی می‌کنند تا به این نحو مدیریت و پردازش آن‌ها ساده‌تر باشد. خالی از لطف نیست اشاره به این که، بعضی فایروال‌ها از تکنیکی به نام DNS Trap برای بررسی بیشتر رفتار این قسم از بدافزارها استفاده می‌کنند. دراین تکنیک، فایروال به جای مسدود کردن DNS Queryهای بدافزار، آن‌ها را با مقدار IP مشخص ولی اشتباهی، پاسخ می‌دهد و آنگاه بر اساس بسته‌هایی که به آن IP ارسال می‌شود، لیست کامل‌تری از سیستم‌های آلوده بدست می‌آورد.جز این روش‌ها، در حال حاضر روش دیگری برای مقابله با این بدافزارها وجود ندارد.البته استفاده از DNS تنها روش محبوب نویسندگان بد‌افزار برای ارتباط بین RAT/Botnet و C&C نیست. موارد متعدد دیگری نظیر کامنت گذاشتن زیر ویدیوهای Youtube یا زیر پست‌های اینستاگرامی یا حتی استفاده از سرویس Google Translate، کانال‌های ارتباطی‌ای هستند که از طریق آن‌ها بدافزارنویس سعی می‌کند ترافیک بین بدافزار و C&C را ترافیک مورد اطمینان نشان دهد.گام هفتم: نمونه‌های واقعیچنانچه به مطالعه یا بررسی نمونه‌های واقعی این نوع بدافزارها علاقمند باشید، می‌توانید گزارش‌های بدافزارهای DNS_TXT_Pwnage و DNSMessenger و OilRig – BONDUPDATER را در گوگل جستجو کنید. همچنین اگر در صدد پیاده‌سازی یا بررسی یک DNS Tunnel هستید از کتابخانه‌ها و ابزارهای زیر می‌توانید بهره ببرید:dns2tcp، tcp-over-dns، OzymanDNS، iodine، SplitBrain، DNScat-P / dnscat2، DNScapy، TUNS، PSUDP، Hexify، Your Freedomگام هشتم: ظهور DoH وDoT و DTLS و دردسرهای جدید برای Firewall هادر پست‌های آتی خواهیم دید که ظاهر شدن DoH یا همان DNS over HTTPS و DoT یا همان DNS over TLS و همچنین ظهور DTLS یا همان Datagram over TLS باعث می‌شود حتی روش‌های مقابله‌ای ذکر شده در گام ششم دیگر کارساز نباشند. لیکن مقدمه‌ی آن آشنایی با پروتکل TLS، حملات مبتنی بر DNS و علت نیاز به DNSهای رمز شده است. در آینده‌ای نزدیک در ارتباط با همه‌ی این موارد و همچنین نرم‌افزارها و تکنیک‌های دیگری مانند DNSCrypt و DNSSEC مطالب مفصلی خواهیم داشت.در انتها صمیمانه از یاشار و مهدی و بابک عزیز که زحمت Review رو پذیرفتند تشکر می‌کنم و علاوه بر این، شما رو هم به نظرات مثبت و منفی، که مسلما همه‌ش به بهبود کیفیت این پست و پست‌های آتی کمک می‌کنند، دعوت می‌کنم. هر ایراد فنی/نگارشی رو از طریق نظرات بهم اطلاع بدید اصلاح می‌کنم. ممنون که [تا اینجا] خوندید.راستی! این نوشته رو در memoryleak.ir هم می‌تونید بخونید.

عشق، آه، ای ابر سرگردان، برو ...

ابراهیم قاسمی — Wed, 01 Nov 2017 03:38:50 +0330

العبد یدبّر و الله یقدّر و الامور بالتقدیر، لا بالتدبیراصلا، هیچ عاقلی به خاطر باران دنبال ابر می‌دود؟ یا مثلا داد و بی‌داد راه می‌اندازد که وای، ابر رفت، باران رفت و فلان و بهمان ؟!دیر یا زود دارد، سوخت و سوز هم دارد؛ بدون تعارف و پنهان کاری تا بیایی به خودت بیایی و به یک نتیجه ی درست و حسابی برسی یک لذت و صفای خیلی خاصی هم دارد، اما بالاخره آدم یک جایی سرش به سنگ می‌خورد، یک جایی می‌فهمد مشکل کار کجاست، از کجا لنگ می‌خورد. می‌فهمد که آدم‌ها باید حکم ابر را داشته باشند برایش!همین ابرهای یک شب و دو شب ماندگار که از بعضی یک باران دلچسب عایدت می‌شود و زمین شسته و تمیز و یک رایحه‌ی دلنشین از بوی گـُل و گـِل، از بعضی هم توفان و تگرگ و خرابی، و از غالب دیگرشان هم نهایتا یک سایه!بعد می‌فهمد آمدن و رفتن این ابرها نه دست خودت است، نه دست ابر، دست یک نسیم است! یک نسیم که اصلا نمی‌بینی اش، فقط گاهی وقت ها ممکن است وجودش را حس کنی!بعد می‌فهمد که باید تا وقتی ابر باران برایش به ارمغان می‌آورد، لذت ببرد و زندگی کند، وقتی هم رفت، بگذارد برود، سعی نکند زندگی اش را رها کند برود دنبال ابر، چون بی فایده است، حالا شاید یک روزی دوباره نسیم مسیرش را عوض کند و باز گردد، یا یک ابر دیگر بیاورد. و در واقع می‌فهمد به هیچ ابری نباید دل ببندد، هیچ ابری خاص نیست؛ این فقط احساسش است که ممکن است خیلی خاص باشد ...اصلا خیلی خوب که نگاه کند می‌فهمد که همه‌ی جذابیت این ابرها برای این است که آدم چشمش آسمان را هم ببیند گاهی!و نهایتا آدم فقط باید تلاش کند بعد رفتن ابر، نگاهش را از آسمان برنگرداند و آن طراوت و شستگی را حفظ کند، حفظ کند تا شاید ابری دیگر و ارمغانی دیگر ...