مقاله آموزشی: گام‌های برخورد با کارگزاری که مورد نفوذ قرار گرفته چیست؟
یک یا چند کارگزار توسط یک نفوذگر، یک بدافزار یا سایر سازو‌کار‌های حمله به خطر افتاده است:
اولین گام‌های برخورد چیست؟ آیا زمانی که به محل نگه‌داری کارگزار می‌رسید، باید ارتباط کارگزار را از اینترنت قطع کنید تا شواهد حضور مهاجم باقی بماند؟ آیا ملاحظات اولیه‌ی دیگری وجود دارد؟
چگونه خدمات ارائه‌شده توسط کارگزار به وضعیت برخط برمی‌گردد؟
چگونه باید از به‌وجود آمدن بلافصله‌ی مجدد حادثه پیش‌گیری کرد؟
اگر برنامه‌ای برای پاسخ‌گویی به حادثه‌ی سایبری باید تدارک دیده شود، از کجا شروع کنیم؟
این اتفاق باید بخشی از برنامه‌ی تداوم کسب‌و‌کار باشد یا بازیابی پس از حادثه‌ی سایبری؟
شاید ارائه‌ی یک راه‌کار خاص برای مواجهه با حوادث سایبری بسیار سخت باشد، اما برخی از گام‌ها عمومی می‌باشند و توصیه می‌شود در مواجهه با حوادث سایبری ابتدا نکاتی که در ادامه مطرح می‌شود در نظر گرفته شود.
مهم است که این مسئله را به‌خاطر داشته باشید که هیچ «راه‌حل سریعی» برای مواجهه با مشکل نفوذ به کارگزار وجود ندارد، اما بهترین و نخستین فعالیتی که می‌توان انجام داد، درصورتی که کارگزار از وضعیت ارائه‌ی خدمات خارج شده است، بازیابی کارگزار از آخرین نسخه‌ی پشتیبان است.
آیا شما همیشه از وضعیت سالم کارگزار پشتیبان تهیه می‌کنید؟ اگر نه، بهتر است تجدید نظری در مورد نظر خود داشته باشید، این عقیده که کارگزار ما فعلاً کارگزار مهمی نیست که هدف حملات سایبری قرار بگیرد، بسیار کورکورانه است، در دنیای امروز، مهاجمان تنها به دنبال به کارگزار‌هایی می‌گردند که گمنام هستند و نفوذ به آن‌ها راحت است و سپس از کارگزار‌های مورد نفوذ قرار گرفته به عنوان رایانه‌های فرمان‌بر و منابع رایگان استفاده می‌کنند، بنابراین در دوره‌های زمان‌بندی شده از کارگزار و سامانه‌های حساس پشتیبان تهیه کنید!
اما بازیابی کارگزار از پرونده‌ی پشتیبان در اولین زمان ممکن، دست‌کم دو مشکل خواهد داشت:
- تعیین زمانی که نفوذ صورت گرفته است را مشکل می‌کند
- بازگردانی سامانه از طریق پشتیبان، راه نفوذی که مهاجم از طریق آن به سامانه نفوذ کرده است را نمی‌بندد و البته روشی نیست که در مقابل داده‌های به‌سرقت رفته از کارگزار موثر باشد، هر آن ممکن است مهاجم دوباره حمله کند و یا از داده‌های به‌سرقت رفته سوء‌استفاده کند.
سوالاتی که در ابتدای این مقاله پرسیده شد، سوالات متداولی است که بارها پرسیده شده است و مخاطبان همواره سعی دارند برای این سوال‌ها یک پاسخ واحد پیدا کنند و در زمان بروز حملات سایبری فعالیت‌های منطبق بر روال خاصی را انجام دهند. حتی اگر کاربران موفق به پیدا کردن پاسخ واحدی شوند، همواره این سوال را از خود می‌پرسند که چرا حمله‌ی سایبری آن‌ها جزء ٪۵ اتفاقات نادر در دنیای حملات سایبری است؟ در واقع ماهیت حملات سایبری ایجاب می‌کند که هر بار سازو‌کار و روش جدیدی برای حمله اتخاذ شوند که هر نفوذ را به یک نفوذ بی‌سابقه و بدون مورد مشابه تبدیل کند.
همان‌طور که گفته شد، عجله نکنید، و البته مهم‌تر از عجله نکردن، تظاهر نکنید که هیچ اتفاقی نیفتاده است. الآن زمان انکار نیست، باید نفوذ را باور کنید و از لحظات نخستین سعی در برداشتن گام‌هایی داشته باشید که خسارات را کم‌تر کند و زودتر وضعیت کارگزار را به حالت ارائه‌ی خدمات تبدیل کند.
«جلوی ضرر را هرگاه بگیرید، منفعت است!» گام‌هایی که در ادامه می‌آید با هدف جلوگیری از بروز هر چه بیش‌تر مشکل می‌باشد:
- اولین کار این است که اتصال کارگزار را از اینترنت برای مدتی قطع کنید. حتی اگر این کار باعث از کار افتادن خدمات کارگزار می‌شود، اما از ادامه‌ی حمله و احتمالاً سرقت اطلاعات جلوگیری می‌کند.
- تمامی گذرواژه‌های موجود برای حساب‌های کاربری را تغییر دهید، حتی گذرواژه‌ی رایانه‌هایی که به شبکه‌ی مشترکی با شبکه‌ی کارگزار متصل هستند. دقیقاً گذرواژه‌ی تمام حساب‌های کاربری در تمام رایانه‌ها. شاید کار مشکلی باشد، بنابراین به‌کارگیری نیروها و سامانه‌های مدیریت از راه دور در این مرحله ضروری است.
- به دنبال موارد مشکوک، تمامی رایانه‌ها، به خصوص رایانه‌هایی که در حال ارائه‌ی خدمات بوده‌اند و یا دارای اطلاعات حساس بانکی یا محرمانه هستند، بگردید.
- اگر کارگزار یا رایانه‌ها شامل اطلاعات فردی هستند، به سرعت فردی که اطلاعاتش در معرض خطر است را مطلع کنید، حتی اگر این فرد رییس شماست و ممکن است شما کار خود را از دست بدهید، اما قوانین رعایت حریم شخصی افراد باعث می‌شود در صورت اطلاع ندادن، بعد‌تر دردسر‌های بیش‌تری برای شما ایجاد شود، خصوصاً اگر این افراد مشتریان خدمات شما باشند و باید مبنای برخورد با آن‌ها صداقت بوده و هرچه سریع‌تر مطلع شوند.
- سعی نکنید برای بهتر جلوه دادن نحوهی ارائه‌ی خدمات، کارگزار مورد نفوذ واقع‌شده را قبل از تمام شدن این مراحل به حالت برخط برگردانید.
- بررسی کامل سامانه‌ی مورد نفوذ واقع‌شده به منظور کشف روشی که نفوذگران موفق به سوء‌استفاده از آن برای نفوذ به سامانه شده‌اند. تمامی روش‌های ممکن باید بررسی شوند، اگر راه نفوذ مهاجمین کشف شود، در آینده ضعف‌هایی که مهاجمین از آن‌ها سوء‌استفاده کرده‌اند، رفع می‌شود.
- بررسی کامل سامانه‌ی مورد نفوذ واقع‌شده این‌بار برای حصول اطمینان از این‌که حملات رفع شده است، هم‌چنین مطمئن باشید که دقیقاً کدام سامانه‌ها مورد نفوذ قرار گرفته‌اند، هر سامانهای که مورد نفوذ قرار گرفته باشد، در آینده یک سکوی پرش برای مهاجمین است تا راه خود را برای حمله‌ی مجدد باز کنند.
- دروازه‌های ورود مهاجمین را بشناسید و به خوبی این دروازه‌ها را برای جلوگیری از ورود بعدی ببندید. یعنی اگر مهاجمین با استفاده از تزریق SQL موفق به نفوذ شده‌اند، نه‌تنها باید مطابق گام دوم این آسیب‌پذیری را رفع کنید، بلکه باید تمام کد را اعتبارسنجی کنید تا آسیب‌پذیری دیگری موجود نباشد.
- بدانید که حملات ممکن است با سوء‌استفاده از بیش از یک آسیب‌پذیری شکل گرفته باشند. بسیاری از اوقات مهاجمین یک خطای بسیار مهم را برای نفوذ مورد استفاده قرار نمی‌دهند، بلکه با سوء‌استفاده از نقص‌های امنیتی شاید جزیی و نه چندان مهم، اما پیوسته، راه خود را برای نفوذ به سامانه‌ها باز می‌کنند. نفوذگران یک اصطلاح معروف دارند: «یک روز دیگر در اداره، سوء‌استفاده از اشتباهات رایج مردم!»
زمانی که یک کارگزار مورد نفوذ قرار گرفت، دیگر کنترل آن به دست مهاجمین است، قبول کنید که در این شرایط دیگر این سامانه متعلق به شما نیست، و تبدیل به یک رایانه‌ی فرمان‌بر برای مهاجمین شده است.
تنها راهی که مطمئن شوید، رایانه‌ی مورد نفوذ قرار گرفته در اختیار خود شماست، ساخت مجدد این سامانه است. درست است که ارزش زیادی در کشف روش‌های نفوذ مهاجمین و رفع آسیب‌پذیری‌های مورد استفاده وجود دارد، اما هیچ‌گاه صد در صد مطمئن نخواهید بود که مهاجم دقیقاً با سامانه‌ی شما چه کرده است. (درواقع دور از ذهن نیست که مهاجمین ابتدا با سوء‌استفاده از یک آسیب‌پذیری به رایانه نفوذ کنند و سپس با یک فرآیند ترمیمی این آسیب‌پذیری که خودشان از آن سوء‌استفاده کرده‌اند را وصله کنند و رایانه‌ی شما را تبدیل یه یک رایانه‌ی فرمان‌بر کنند که راه نفوذ سایر مهاجمین را به آن بسته‌اند.)
به خاطر داشته باشید که هیچ مدیر کارگزار یا وب‌گاهی نمی‌خواهد برای مدتی طولانی خدماتش از حالت برخط خارج شوند، و این شرایط زمانی تشدید می‌شود که وب‌گاه یک منبع کسب‌و‌کار اینترنتی باشد و برون‌خط بودن بیش‌تر مساوی از دست‌دادن مشتریان و ضرر مالی باشد.
با این حال، نباید برای این‌که هرچه سریع‌تر وب‌گاه به حالت برخط برگردد، وسوسه شوید. به همان سرعتی که سعی در برخط کردن خدمات دارید، مهاجم به همان سرعت و با همان روش می‌تواند مجدداً حمله کند و این‌بار خسارات بیش‌تری به بار آورد. وب‌گاهی که در حال رفع مشکل است قابل اعتماد‌تر از وب‌گاهی است که دائماً دچار حمله‌ی سایبری می‌شود و اطلاعات مشتریان را به خطر می‌اندازد. درواقع یک بار مورد نفوذ واقع شدن را می‌توان به حساب بدشانسی گذاشت، اما نفوذ‌های پی‌در‌پی نشان از بی‌دقتی مدیران است!
- در ابتدا به‌خاطر داشته باشید که مشکلاتی که مربوط به این نفوذ موفق شده‌اند را به‌خوبی کشف و بررسی کرده‌اید، لازم نیست که مجدداً تکرار کنیم در صورتی که این مرحله نادیده گرفته شود، در آینده پشیمانی زیادی به بار خواهد آورد.
- به‌خاطر داشته باشد که به هیچ عنوان به باج‌گیری‌هایی که توسط مهاجمین درخواست می‌شود پاسخ ندهید، خصوصاً در مورد حملات انسداد سرویس که معمولاً مهاجمین در حین حمله از مدیران درخواست مبلغی پول می‌کنند و وعده می‌دهند که پس از دریافت پول حملات انسداد سرویس را قطع می‌کنند.
- تلاش نکنید که کارگزاری که حمله‌ی سایبری علیه آن انجام شده است را بدون بازسازی کامل به وضعیت برخط برگردانید، و البته این نکته را مد نظر قرار دهید که بازسازی یک کارگزار مورد نفوذ واقع‌شده از صفر به مراتب راحت‌تر از بررسی هر بخش کارگزار و پاک کردن اثرات حمله‌ی سایبری می‌باشد، اگر سعی می‌کنید به خود تلقین کنید که این مسئله صحیح نیست، شاید مسئله‌ی اعتبارسنجی بخش‌های مختلف کارگزار و اطمینان از عدم وجود درپشتی و بدافزار در هر بخش را نادیده گرفته‌اید. البته این کار درصورتی صحیح است که از وب‌گاه‌هایی که میزبانی می‌کنید یک پشتیبان داشته باشید، اگر پشتیبان وجود ندارد، نفوذ در واقع مشکل بزرگ شما نیست، عدم توجه برای پشتیبان‌گیری مشکل بزرگ‌تری است!
- به‌شدت مراقب استفاده از داده‌هایی که در زمان نفوذ در کارگزار وجود داشته‌اند باشید، این مسئله که اصلاً از این داده‌ها استفاده نکنید تقریباً غیرممکن است اما توصیه می‌شود از نسخه‌ی پشتیبانی استفاده کنید که از قبل نفود تهیه شده است، چرا که داده‌ها در هنگام نفوذ قطعاً خدشه‌دار شده‌اند. خصوصاٌ زمانی‌که این داده‌ها متعلق به مشتریان شماست و استفاده‌ی مجدد از آن‌ها ممکن است این فرصت را به نفوذگران بدهد که سوء‌استفاده‌های احتمالی مالی از حساب‌های کاربری مشتریان داشته باشند.
- نظارت بر سامانه‌ها را به دقت پی‌گیری کنید، این نظارت باید به صورت مستمر و بدون وقفه در آینده انجام بگیرد، اما مهم‌ترین زمانی که کارگزار شما به نظارت نیاز دارد بلافاصله پس از زمانی است که کارگزار و وب‌گاه‌ها به حالت برخط برمی‌گردند. ممکن است شما راه‌های نفوذ مهاجمین را به‌درستی تشخیص نداده باشید و آن‌ها دوباره حمله‌ی جدیدی را ترتیب دهند و یا داده‌هایی که استفاده کرده‌اید در خطر باشند. هم‌چنین اگر به خوبی راه‌های نفوذ مهاجمین را شناسایی کرده‌اید توصیه می‌شود سیاست‌های جدیدی در شبکه‌ی محلی خود اعمال کنید که کاربران هم بی‌دقتی کم‌تری در بارگیری و اجرای نرم‌افزار‌ها داشته باشند.
اولین مسئله‌ای که باید به خاطر داشته باشید این است که امنیت، یک گام نیست، امنیت باید تا زمانی که یک سامانه پابرجاست، به صورت فعال وجود داشته باشد، در زمان طراحی، زمان راه‌اندازی و استقرار و زمان استفاده از یک سامانهای که با اینترنت در ارتباط است امنیت باید دغدغه‌ی اصلی مدیر سامانه باشد. برای این‌که سامانه‌ی امنی داشته باشید، از ابتدای طراحی باید امنیت مد نظر قرار داده شود.
سعی نکنید روشی را مدنظر قرار دهید که در آن خطرات به طور کامل از سامانه‌ی شما حذف شده‌اند، خطرات همیشه به‌روز می‌شوند و وجود دارند، شما باید سعی کنید خطراتی که برای شما مهم هستند را کشف کنید و برای مدیریت آن‌ها و کاهش خسارات آن‌ها در صورت بروز احتمالی، برنامه‌ریزی داشته باشید.
- اگر روشی که مهاجمین برای نفوذ به سامانه‌ی شما استفاده کرده‌اند، سوء‌استفاده از یک آسیب‌پذیری است و برای این آسیب‌پذیری وصله موجود بوده است، شما باید در رویکردی که برای نصب به‌روز‌رسانی‌ها و وصله‌ها به‌کار می‌برید، تجدید نظر کنید.
- اگر روشی که مهاجمین برای نفوذ به سامانه‌ی شما استفاده کرده‌اند، سوء‌استفاده از یک آسیب‌پذیری است و برای این آسیب‌پذیری وصله موجود نیست، توصیه می‌شود تجدید نظری در محصول آسیب‌پذیر داشته باشید. اگر آسیب‌پذیری مذکور تنها آسیب‌پذیری بدون وصله‌ی نرم‌افزار مورد استفاده‌ی شماست، توصیه نمی‌شود در اولین قدم به یک نرم‌افزار دیگر مهاجرت کنید، چرا که تاخیر در معرفی به‌روز‌رسانی برای هر نرم‌افزار یک یا دو بار ممکن است پیش بیاید، اما در صورتی که ثابت شد این نرم‌افزار به طور کل ناامن است، باید گام‌های لازم برای مهاجرت به یک نرم‌افزار امن‌تر و پایدارتر را طی کنید.
- خطایی که مهاجمین از آن برای نفوذ به کارگزار شما سوء‌استفاده کرده‌اند مربوط به کدی است که توسط خودتان ( یا افرادی که با شما کار می‌کنند) توسعه پیدا کرده است؟ اگر این چنین است، لازم است که در مورد تایید کارکرد و اعتبارسنجی کدهایی تولید خود تجدید نظر داشته باشید.
- خطایی که مهاجمین از آن برای نفوذ به کارگزار شما سوء‌استفاده کرده‌اند مربوط به نحوهی پیکربندی کارگزار یا نرم‌افزار مورد استفاده در کارگزار است؟ اگر این چنین است آیا از روش خودکاری برای پیکربندی کارگزار استفاده کرده‌اید؟ اگر این چنین است، بهتر است پیکربندی کارگزار خود را مورد بررسی قرار دهید، به خاظر داشته باشید که استفاده از روش‌های خودکار و غیر سفارشی برای پیکربندی کارگزار ممکن است کارگزار شما را در مقابل یک خطای امنیتی ساده آسیب‌پذیر کند. به طور مثال مهاجمین برای نفوذ به یک کارگزار ترجیج می‌دهند در ابتدا بدون هیچ زحمتی گذرواژه‌های پیش‌فرض پیکربندی‌های خودکار را بررسی کنند.
- آیا این حمله‌ی سایبری در صورتی که نظارت بیش‌تری در سامانه‌ها وجود داشت زودتر تشخیص داده می‌شد؟ اگر این چنین است، باید بودجه‌ی بیش‌تر و البته زمان بیش‌تری برای نظارت اختصاص دهید. حتی شاید نیاز به نیروی انسانی نباشد، شرکت‌هایی هستند که فعالیت‌های نظارتی انجام می‌دهند و در صورت بروز یک حادثه‌ی سایبری هشدارهای لازم را به شما انتقال می‌دهند.
- استفاده از ابزار‌های پویش درگاه‌ها و آدرس‌های آی‌پی شبکه مانند Nessus و TripWire البته نه به صورت کورکورانه در صورت لزوم توصیه می‌شود. به طور کلی با ابزار‌های امنیتی مناسب آشنا شوید و به موقع و صحیح از آن‌ها استفاده کنید، البته فراموش نکنید که این ابزار‌ها جایگزین روش‌های نظارتی معمول نیستند.
- به خاطر داشته باشید که در دوره‌های زمانی از کارشناسان امنیتی به منظور بررسی وضعیت امنیت وب‌گاه خود بهره بگیرید. با این کار هم با روش‌های نفوذ آشنا می‌شوید و هم شکاف‌های امنیتی وب‌گاه‌ها و کارگزار‌های شما کشف می‌شود.
اگر شما به این نتیجه رسیده‌اید که خسارت‌های ناشی از حمله‌ی سایبری موفق به حدی است که باید کاهش پیدا کند، بهتر هرچه سریع‌تر دست به کار شوید.
- آیا می‌توانید میزان خدماتی که به صورت مستقیم از طریق اینترنت عرضه می‌شوند را کم کنید؟ یا آیا می‌توانید در ارائه سرویس‌های خود وقفه‌ای ایجاد کنید؟ کاهش خدمات اینترنتی تضمین می‌کند حتی اگر سامانه‌های خارجی این خدمات به خطر بیافتد نمی‌توان از آن‌ها به عنوان یک سکوی پرش برای ایجاد حمله‌ی سایبری مجدد و به خطر انداختن سامانه‌های داخلی استفاده کرد.
- آیا اطلاعاتی در کارگزار ذخیره شده‌اند که نیاز ضروری برای ذخیره‌ی آن‌ها نیست؟ اگر این اطلاعات به صورت برخط ذخیره شده‌اند و می‌توانند قربانی دست‌رسی‌های غیرمجاز شوند، توجه کنید که باید این اطلاعات را از خطر نجات دهید! هرچه اطلاعات غیرضروری کم‌تری ذخیره کنید، میزان خسارت‌های احتمالی کم‌تر است.
- آیا از کمینه‌ی دست‌رسی مجاز برای کاربران استفاده می‌کنید؟ اگر کاربران نیاز است تا تنها حق خواندن از پایگاه‌داده را داشته باشند، ضروری نیست برای مواقع اضطراری و یا از روی تنبلی حق خواندن را نیز فعال کنید.
- اگر در مورد راه‌اندازی سرویس مهمی به اندازه کافی تجربه ندارید، بهتر است آن را برون‌سپاری کنید. به عبارت دیگر اگر کار شما راه‌اندازی وب‌گاه نیست و بنا بر ضرورت نیاز است تا یک وب‌گاه راه‌اندازی کنید، این کار را خودتان انجام ندهید، شما به اندازه کافی با خطرات امنیتی کدنویسی وب‌گاه آشنا نیستید و انجام این کار توسط شما جز احتمال ایجاد شکاف‌های امنیتی سودی ندارد.
- در صورت امکان، تمرین بازیابی سامانه‌های مورد نفوذ واقع شده را در برنامه‌‌های خود جای دهید. هر بار با ایجاد یک سناریوی حمله، سعی کنید با این حمله مقابله کنید.
هیچ‌گاه در مواجهه با حملات سایبری خونسردی خود را از دست ندهید، قبل از عمل خوب فکر کنید و برای مواجهه با حملات سایبری یک برنامه را گام به گام دنبال کنید.
منبع:
Stackexchange
