در اصل از سرور. با تشکر از رابرت مویر (RobM)

سخت است که می توانم توصیه های خاصی راجع به آنچه که در اینجا پست کرده اید ارائه دهم ، اما من می توانم بر اساس پستی که سن ها پیش در آن نوشتم ، توصیه های عمومی داشته باشم. ] Don't Panic

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

  1. مشخص کردن چه زمانی مشکل است.
  2. این به شما کمک نمی کند که "آخرین سوراخ" را که می توانید در آخرین بار بشکنید ، ببندید ، و همچنین با عواقب ناشی از "سرقت داده" که ممکن است اتفاق بیفتد ، مقابله نکنید.

این سؤال را نگه می دارد. مرتباً توسط قربانیان هکرها که به سرور وب خود وارد می شوند سؤال می شود. پاسخ ها به ندرت تغییر می کنند ، اما مردم همچنان این سؤال را می کنند. من مطمئن نیستم که چرا شاید افراد فقط جوابهایی را که در هنگام جستجوی راهنمایی دیده اند دوست ندارند یا کسی را که به آنها اعتماد دارد پیدا نمی کنند تا به آنها توصیه کنند. یا شاید مردم پاسخی برای این سؤال بخوانند و بیش از حد به 5٪ توجه كنند كه چرا پرونده آنها خاص و متفاوت از جوابهایی است كه می توانند به صورت آنلاین پیدا كنند و 95٪ سؤال و جواب را از دست بدهند كه در آنجا پرونده آنها تقریباً به اندازه یكدیگر است

که مرا به اولین اولین اطلاعات مهم اطلاعات می رساند. من واقعاً ممنونم که شما یک برف برفی خاص و بی نظیر هستید. من ممنونم که وب سایت شما بیش از حد است ، زیرا این بازتابی از شما و تجارت شما یا حداقل کار سخت شما از طرف یک کارفرما است. اما برای کسی که در خارج از کشور به دنبال آن باشد ، چه یک فرد امنیتی رایانه ای که به دنبال مشکل است تا به شما کمک کند یا حتی خود فرد مهاجم ، بسیار محتمل باشد که مشکل شما حداقل 95٪ از موارد مشابه آنها یکسان باشد.

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

شما تازه فهمیدید که سرور (های) شما هک شده است. حالا چی؟

وحشت نکنید. کاملاً با عجله عمل نکنید ، و کاملاً سعی نکنید وانمود کنید که هیچوقت اتفاق نیفتاده و اصلاً عمل نکنید.

اول: درک کنید که این فاجعه قبلاً اتفاق افتاده است. این زمان انکار نیست. زمان آن است که آنچه را که اتفاق افتاده است بپذیریم ، در مورد آن واقع بینانه عمل کنیم و برای مدیریت پیامدهای اثر گام برداریم.

برخی از این مراحل صدمه می بینند ، و (مگر اینکه وب سایت شما نسخه ای از من داشته باشد. جزئیات) من واقعاً مهم نیستم که همه یا بعضی از این مراحل را نادیده بگیرید ، اما انجام این کار در پایان باعث بهتر شدن وضعیت می شود. این دارو ممکن است طعم ناخوشایندی داشته باشد ، اما گاهی اوقات باید از این نکته غافل شوید که اگر واقعاً می خواهید این روش درمانی را انجام دهد.

از بدتر شدن مشکل قبل از آن جلوگیری کنید:

  1. اولین کاری که باید انجام دهید این است که سیستم های آسیب دیده را از هم جدا کنید. اینترنت. هر مشکلی دیگر که دارید ، ترک سیستم متصل به وب فقط باعث ادامه حمله خواهد شد. منظورم این کاملاً به معنای واقعی کلمه است؛ اگر کسی این کار را می کند ، به شخصی مراجعه کند تا به سرور مراجعه کند و کابل های شبکه را جدا کند ، اما قربانی را از مگگرهای خود جدا کنید ، قبل از اینکه سعی کنید کار دیگری انجام دهید.
  2. تمام گذرواژه های خود را برای همه حساب ها در تمام رایانه های موجود در تغییر دهید. همان شبکه به عنوان سیستم های به خطر بیافتد. نه واقعا. همه حسابها همه رایانه ها بله ، حق با شماست ، این ممکن است بیش از حد باشد؛ از طرف دیگر ، ممکن نیست. شما به هیچ وجه نمی دانید ،
  3. سایر سیستم های خود را بررسی کنید. توجه ویژه ای به سایر سرویس های روبرو اینترنت و سایر کسانی که داده های حساس مالی یا تجاری دارند ، داشته باشید.
  4. اگر سیستم داده های شخصی هر کسی را در اختیار دارد ، فوراً به شخص مسئول حفاظت از داده ها (اگر این شما نیستید) اطلاع دهید و از آن استفاده کنید. افشای می دانم این یکی سخت است. من می دانم که این یکی صدمه دیده است. من می دانم که بسیاری از مشاغل می خواهند این نوع مشکل را در زیر فرش برطرف کنند ، اما تجارت باید با آن مقابله کند – و باید این کار را با توجه به همه قوانین مربوط به حریم خصوصی انجام دهد.

اما مشتریان شما را اذیت کرد. ممکن است این باشد که شما در مورد مشکلی به آنها بگویید ، اگر به آنها نگویید ، آنها بسیار اذیت می شوند و آنها پس از اینکه شخصی 8000 دلار کالا را با استفاده از جزئیات کارت اعتباری که از سایت شما به سرقت برده است ، پیدا می کنند ، متوجه ناراحتی می شوند.

آنچه را که قبلاً گفتم به خاطر می آورید؟ اتفاق بد قبلاً رخ داده است اکنون تنها سؤال شما این است که چقدر خوب با آن مقابله می کنید.

مسئله را بطور کامل بفهمید:

  1. آیا سیستم های آسیب دیده را مجدداً آنلاین نکنید تا این مرحله کاملاً کامل شود ، مگر اینکه بخواهید شخصی که پست آن نکته مهم برای من بود تصمیم به نوشتن این مقاله گرفت. من قصد ندارم به آن پست پیوند بخورم تا مردم بتوانند خنده ارزان داشته باشند ، اما فاجعه واقعی وقتی است که مردم از اشتباهات خود درس نمی گیرند.
  2. سیستم های "حمله شده" را بررسی کنید تا بفهمید که چگونه حملات در به خطر افتادند. امنیت شما تمام تلاش خود را بکنید تا دریابید که حملات "از کجا" انجام شده است ، بنابراین شما می توانید درک کنید که چه مشکلاتی دارید و برای رفع امنیت سیستم در آینده باید به آنها بپردازید.
  3. سیستم های "حمله شده" را دوباره بررسی کنید ، این بار برای درک حملات به کجا رفتند ، بنابراین شما می دانید که چه سیستمهایی در این حمله به خطر افتاده اند. اطمینان حاصل کنید که از هرگونه نشانگر پیروی می کنید که نشان می دهد سیستم های به خطر افتاده می توانند تبدیل به یک تخته سنگ برای حمله به سیستمهای شما شوند.
  4. اطمینان حاصل کنید که "دروازه" مورد استفاده در هر حمله و تمام حملات کاملاً درک شده است ، به گونه ای که شما ممکن است شروع به بسته شدن صحیح آنها کنید. (به عنوان مثال اگر سیستم های شما با حمله تزریق SQL به خطر افتادند ، نه تنها لازم است که خط کد خاصی را که توسط آنها وارد شده است ببندید ، بلکه می خواهید تمام کدهای خود را نیز ممیزی کنید تا ببینید آیا همان نوع اشتباه است؟ [درجایدیگرساختهشدهاست)
  5. درک کنید که حملات ممکن است به دلیل بیش از یک نقص موفق شوند. غالباً ، حملات نه از طریق یافتن یک اشکال اساسی در یک سیستم بلکه با همبستگی چندین مسئله (گاهی خود جزئی و ناچیز) برای به خطر انداختن یک سیستم موفق می شوند. به عنوان مثال ، استفاده از حملات تزریق SQL برای ارسال دستورات به سرور پایگاه داده ، کشف وب سایت / برنامه ای که به آن حمله می کنید در متن یک کاربر اداری است و استفاده از حقوق آن حساب به عنوان پله ای برای به خطر انداختن سایر قسمتهای یک سیستم. یا همانطور که هکرها دوست دارند آن را صدا کنند: "روز دیگر در دفتر با بهره گیری از اشتباهات رایج مردم".

چرا فقط سوءاستفاده یا روت کیتی که تشخیص داده اید را "تعمیر نکنید" و سیستم را دوباره آنلاین کنید؟

در چنین شرایطی مسئله این است که شما کنترل آن سیستم را دیگر ندارید. دیگر رایانه شما نیست.

تنها راه برای اطمینان که شما می توانید کنترل سیستم را بدست آورید ، بازسازی سیستم است. در حالی که ارزش زیادی در یافتن و رفع بهره برداری استفاده شده برای ورود به سیستم وجود دارد ، شما نمی توانید در مورد آنچه در سیستم انجام شده است به محض این که مزاحمان کنترل را به دست آوردند اطمینان حاصل کنید (در واقع ، هکری که استخدام می شوند ، غافل نیست. سیستم های موجود در یک بات نت برای پیکربندی از سوءاستفاده هایی که خودشان استفاده کرده اند ، برای محافظت از "رایانه" جدید خود از سایر هکرها ، و همچنین نصب rootkit آنها).

برای بهبودی برنامه ای تهیه کرده و وب سایت خود را آنلاین و مجدداً برگردانید. به آن بچسبید:

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

با این حال ، به این وسوسه نباشید که خیلی سریع به اینترنت برگردید. در عوض ، با بیشترین سرعت ممکن حرکت کنید تا متوجه شوید چه چیزی باعث ایجاد مشکل شده و قبل از بازگشت به اینترنت یا در غیر این صورت ، آن را حل کرده اید ، قطعاً یکبار دیگر قربانی یک حمله خواهید شد و به یاد داشته باشید ، "برای هک شدن یک بار می توان به عنوان یک بدبختی طبقه بندی کرد. دوباره مستقیماً هک شده و به نظر می رسد بی دقتی "(با عذرخواهی از اسکار وایلد).

  1. من فرض می کنم که شما قبل از شروع این بخش ، همه مسائلی را که منجر به حمله موفقیت آمیز منجر شده است ، درک کرده اید. من نمی خواهم این پرونده را بیش از حد شلوغ کنم ، اما اگر این کار را نکرده اید ، پس باید واقعاً این کار را انجام دهید. با عرض پوزش.
  2. هرگز پول باج خواهی یا حمایت را پرداخت نکنید. این نشانه یک علامت آسان است و شما نمی خواهید آن عبارتی را برای توصیف شما بکار برد.
  3. آیا وسوسه نشوید که همان سرور (ها) را بدون بازسازی کامل دوباره آنلاین کنید. باید ساخت جعبه جدید یا "نوک زدن سرور از مدار و نصب تمیز" بر روی سخت افزار قدیمی خیلی سریعتر از آن باشد که بتوانید گوشه گوشه سیستم قدیمی را ممیزی کنید تا قبل از عقب بودن ، تمیز باشد. دوباره آنلاین اگر با آن مخالف باشید ، احتمالاً نمی دانید منظور از پاک شدن کامل سیستم ، یا اینکه روش های استقرار وب سایت شما یک آشفتگی غیرمسئول است. شما احتمالاً از پشتیبان گیری و استقرار سایت خود استفاده می کنید که می توانید از آن برای ساختن سایت زنده استفاده کنید ، و اگر هک نشدید ، بزرگترین مشکل شما نیست.
  4. در استفاده مجدد از داده های بسیار مراقب باشید. " زندگی می کنند "در سیستم در زمان هک. من هرگز نخواهم گفت "هرگز این کار را نکنید" زیرا من را نادیده می گیرید ، اما صریحاً فکر می کنم که وقتی می دانید نمی توانید صداقت آن را تضمین کنید ، باید عواقب نگه داشتن اطلاعات را در نظر بگیرید. در حالت ایده آل ، شما باید این مورد را از نسخه پشتیبان تهیه شده قبل از حمله بازگردانی کنید. اگر نمی توانید یا نمی توانید این کار را انجام دهید ، باید با این داده ها بسیار محتاط باشید زیرا رنگ آن لکه دار است. اگر این داده ها متعلق به مشتریان یا بازدید کنندگان سایت است و نه مستقیماً به شما ، باید از پیامدهای دیگران آگاه باشید.
  5. سیستم (های) را با دقت کنترل کنید. شما باید تصمیم بگیرید که این کار را به عنوان یک روند مداوم در آینده انجام دهید (بیشتر در زیر) اما دردهات اضافی برای هوشیاری در دوره ای که بلافاصله پس از بازگشت سایت شما به صورت آنلاین انجام می شود ، احتیاط می کنید. متجاوزین تقریباً به عقب برمی گردند ، و اگر بتوانید آنها را دوباره تلاش کنید تا به هم بزنند مطمئناً می توانید به سرعت مشاهده کنید که آیا واقعاً تمام حفره هایی را که قبلاً از آنها استفاده کرده اید بسته اید و هر چیزی را که برای خود ساخته اید بسته اید و ممکن است مفید باشد. اطلاعاتی که می توانید برای اجرای قانون محلی خود به آنها منتقل کنید.

کاهش خطر در آینده.

اولین چیزی که باید درک کنید این است که امنیت روندی است که شما باید در طول کل زندگی اعمال کنید- چرخه طراحی ، استقرار و نگهداری از یک سیستم رو به اینترنت ، نه چیزی که می توانید چند لایه را بر روی کد خود پس از آن مثل رنگ ارزان قورت دهید. برای ایمن سازی صحیح ، یک سرویس و یک برنامه کاربردی باید از ابتدا با توجه به این موضوع به عنوان یکی از مهمترین اهداف پروژه طراحی شود. من می دانم که این کار خسته کننده است و شما آن را قبلاً شنیده ام و این که "من فقط فشار را نمی فهمم" از دریافت سرویس بتا web2.0 (بتا) شما به وضعیت بتا در وب استفاده می کنم ، اما واقعیت این است که این امر ادامه می دهد. تکرار می شود ، زیرا اولین باری بود که صحیح بود و هنوز به دروغ تبدیل نشده است.

شما نمی توانید خطر را از بین ببرید. شما حتی نباید سعی کنید این کار را انجام دهید. آنچه شما باید انجام دهید این است که درک کنید که خطرات امنیتی برای شما مهم است و درک اینکه چگونه می توانید تأثیر ریسک را کنترل کنید و همچنین احتمال بروز این خطر را کاهش دهید.

چه اقداماتی می توانید انجام دهید به عنوان مثال:

  1. آیا نقصی که به افراد امکان می داد در سایت شما یک اشکال شناخته شده در کد فروشنده را شکست دهند ، وجود دارد که یک پچ در دسترس بود؟ اگر چنین است ، آیا باید رویکرد خود را دوباره به این فکر کنید که چگونه برنامه های خود را روی سرورهای روبرو اینترنت قرار می دهید؟
  2. آیا این عیب بود که به افراد امکان می داد اشکالی ناشناخته در کد فروشنده را وارد سایت شما کنند ، و برای آن یک پچ بود. در دسترس نیست؟ من مطمئناً طرفداری از تغییر تامین کننده ها ندارم که هر چیزی مانند این شما را نیش می زند زیرا همه آنها مشکلات خود را دارند و اگر از این رویکرد استفاده کنید حداکثر در یک سال از سیستم عامل ها خارج خواهید شد. با این حال ، اگر یک سیستم دائماً شما را رها می کند ، باید یا به چیزی قوی تر مهاجرت کنید و یا حداقل ، سیستم خود را دوباره معمار کنید تا اجزای آسیب پذیر در پشم پنبه پیچیده شده و تا حد ممکن از چشمان خصمانه دور شوند. [19659006] آیا نقص کد ایجاد شده توسط شما (یا شخصی که برای شما کار می کند) ایجاد شده است؟ اگر چنین است ، آیا باید رویکرد خود را در مورد تصویب کد برای اعزام به سایت زنده خود دوباره فکر کنید؟ آیا می توان این اشکال را با استفاده از یک سیستم تست بهبود یافته گرفت و یا با تغییر در "استاندارد" کد نویسی شما (به عنوان مثال ، در حالی که فناوری پاناساز نیست ، می توانید با استفاده از تکنیک های رمزگذاری خوب مستند ، احتمال حمله تزریق موفق SQL را کاهش دهید.
  3. آیا این نقص به دلیل مشکلی در نحوه استقرار سرور یا نرم افزار کاربردی وجود دارد؟ اگر چنین است ، آیا از مراحل خودکار برای ساخت و استقرار سرورها در صورت امکان استفاده می کنید؟ اینها کمک زیادی به حفظ یک حالت "پایه" مداوم روی همه سرورهای شما می کنند ، به حداقل رساندن میزان کار سفارشی که باید روی هر یک انجام شود و از این رو امیدوارم فرصتی را برای اشتباه ایجاد کنید. همین امر با استقرار كد نیز انجام می شود – اگر برای استقرار آخرین نسخه برنامه وب خود به كار "ویژه" ای نیاز دارید ، پس از آنكه كاملاً اتوماسیون كردید و اطمینان داشته باشید كه همیشه به صورت مداوم انجام می شود ، كوشش كنید.
  4. زودتر با نظارت بهتر سیستم های شما گرفتار شده اید؟ البته ، نظارت 24 ساعته یا سیستم "فراخوانی" برای کارمندان شما ممکن است مقرون به صرفه نباشد ، اما شرکت هایی در خارج از کشور وجود دارند که می توانند خدمات روبرو وب خود را برای شما نظارت کنند و در صورت بروز مشکل به شما هشدار دهند. شما ممکن است تصمیم بگیرید که نمی توانید این هزینه را داشته باشید یا به آن احتیاج ندارید و این فقط خوب است … فقط آن را در نظر بگیرید.
  5. از ابزارهایی مانند Tripwire و nessus در موارد مناسب استفاده کنید – بلکه فقط از آنها کورکورانه استفاده نکنید. گفتم برای یادگیری چگونگی استفاده از چند ابزار امنیتی مناسب متناسب با محیط شما ، وقت بگذارید ، این ابزارها را به روز کنید و به طور مرتب از آنها استفاده کنید.
  6. برای استخدام متخصصان امنیتی در نظر بگیرید که امنیت وب سایت خود را بطور منظم ممیزی کنید. . باز هم ، شما ممکن است تصمیم بگیرید که نمی توانید این هزینه را داشته باشید یا به آن احتیاج ندارید و این فقط خوب است … فقط آن را در نظر بگیرید.

برای کاهش پیامدهای حمله موفقیت آمیز چه اقداماتی می توانید انجام دهید؟

اگر تصمیم می گیرید که "خطر" بودن در طبقه پایین سیل خانه شما زیاد است ، اما به اندازه کافی برای ضمانت حرکت نیست ، شما حداقل باید ورثه های غیرقابل تعویض خانوادگی را در طبقه بالا منتقل کنید. درست است؟

  1. آیا می توانید میزان خدمات مستقیمی در اینترنت را کاهش دهید؟ آیا می توانید نوعی شکاف بین خدمات داخلی و سرویس های اینترنتی خود را حفظ کنید؟ این تضمین می کند که حتی اگر سیستم های خارجی شما به خطر بیفتد ، شانس استفاده از این به عنوان یک تخته سنگ برای حمله به سیستم های داخلی شما محدود است.
  2. آیا اطلاعاتی را که نیازی به ذخیره آن نیستید ، ذخیره می کنید؟ آیا می توانید چنین اطلاعاتی را بصورت "آنلاین" ذخیره کنید که می تواند در جای دیگری بایگانی شود. دو بخش به این بخش وجود دارد. نکته بارز این است که افراد نمی توانند اطلاعاتی را که شما در اختیار دارید از شما سرقت کنند و نکته دوم این است که هرچه میزان کمتری را ذخیره کنید ، کمتر نیاز به حفظ و کدگذاری دارید ، و بنابراین احتمال اینکه اشکالات کمتری به آن وارد شوند ، وجود دارد. کد یا سیستم خود را طراحی می کنید.
  3. آیا از اصول "حداقل دسترسی" برای برنامه وب خود استفاده می کنید؟ اگر کاربران فقط باید از یک پایگاه داده بخوانند ، پس اطمینان حاصل کنید که حسابی که برنامه وب برای سرویس دهی از این دسترسی فقط خواندنی است ، اجازه دسترسی به آن را ندهید و مطمئناً دسترسی به سیستم ندارد.
  4. اگر شما اینگونه نیستید. در مورد چیزی بسیار با تجربه هستید و برای تجارت شما مهم نیست ، بنابراین برون سپاری را در نظر بگیرید. به عبارت دیگر ، اگر وب سایت كوچكی راجع به نوشتن كد برنامه دسکتاپ دسکتاپ دارید و تصمیم دارید كه برنامه های دسكتاپ كوچك را از سایت شروع كنید ، استفاده كنید ، سیستم سفارش كارت اعتباری خود را برای "شخصی" پی پال در نظر بگیرید.
  5. در صورت امکان ، بازیابی عملی از سیستم های به خطر افتاده را بخشی از برنامه بازیابی حوادث خود قرار دهید. این استدلال است که فقط "سناریوی فاجعه" دیگری است که می توانستید با آن روبرو شوید ، فقط با مجموعه ای از مشکلات و موضوعات خاص خود که از "اتاق سرور گرفتار آتش" متمایز است.

… و سرانجام

احتمالاً من دیگر هیچ چیز را برای دیگران ندیدم که دیگران آن را مهم بدانند ، اما مراحل فوق حداقل باید به شما کمک کند در صورت عدم موفقیت کافی شروع به مرتب سازی چیزها کنید. برای قربانی هکرها.

مهمتر از همه: از هراس نکشید. قبل از عمل فکر کن. هنگامی که تصمیم خود را گرفتید ، محکم عمل کنید و اگر چیزی برای اضافه کردن به لیست مراحل من داشته باشید ، زیر نظر بگذارید.