Перевстановити після кореневого компромісу?

Прочитавши це питання на компромісі з сервером , я почав замислюватися, чому люди продовжують, здається, вірять у те, що вони можуть відновити порушену систему за допомогою інструментів виявлення / очищення або просто зафіксувавши отвір, який був використаний для компрометації системи.

З огляду на всі різноманітні технології кореневого набору та інші речі, які може зробити хакер, більшість експертів пропонують перевстановити операційну систему .

Я сподіваюся отримати краще уявлення, чому більшість людей не просто вилітають та виганяють систему з орбіти.

Ось кілька моментів, на які я хотів би звернутися.

• Чи існують умови, коли формат / перевстановлення не очистить систему?
• За яких типів, на вашу думку, система може бути очищена, і коли потрібно зробити повну перевстановлення?
• Які міркування ви маєте проти повного перевстановлення?
• Якщо ви вирішите не перевстановлювати, то який метод ви використовуєте, щоб бути впевненими, що ви очистили та запобігли повторному пошкодженню.

Рішення безпеки - це врешті-решт ділове рішення щодо ризику, як і рішення про те, який товар брати на ринок. Коли ви формуєте це в цьому контексті, рішення не вирівнювати і перевстановлювати має сенс. Якщо ви розглядаєте це строго з технічної точки зору, це не так.

Ось що зазвичай входить до цього бізнес-рішення:

• Скільки коштуватиме нам простої в вимірюваній кількості?
• Скільки це може коштувати нам, коли нам доведеться трохи розкрити клієнтам про те, чому ми були вниз?
• Які ще заходи я повинен мати, щоб відтягнути людей, щоб зробити перевстановлення? Яка вартість?
• Чи є у нас правильні люди, які вміють виховувати систему без помилок? Якщо ні, то що це буде коштувати мені, коли вони усувають помилки?

Отже, коли ви складаєте подібні витрати, може вважатися, що продовжувати роботу з "потенційно" все-таки скомпрометованою системою краще, ніж перевстановити систему.

На основі публікації, яку я писав століттями назад, коли мені ще можна було зайнятися блогом.

Це питання не раз задаються жертвами хакерів, що ввірваються на їх веб-сервер. Відповіді змінюються дуже рідко, але люди продовжують задавати питання. Я не впевнений, чому. Можливо, людям просто не подобаються відповіді, які вони бачили під час пошуку допомоги, або вони не можуть знайти когось, кому вони довіряють, щоб дати їм поради. Або, можливо, люди читають відповідь на це запитання і занадто зосереджуються на 5%, чому їхній випадок особливий і відрізняється від відповідей, які вони можуть знайти в Інтернеті, і пропускають 95% запитань і відповідей, де їх справа майже однакова як той, який вони читають в Інтернеті.

Це підводить мене до першого важливого нотку інформації. Я дуже вдячний, що ви особлива унікальна сніжинка. Я вдячний, що ваш веб-сайт теж є, оскільки це відображення вас і вашого бізнесу або, принаймні, вашої наполегливої ​​роботи від імені роботодавця. Але для когось із зовнішньої сторони, незалежно від того, чи є людина з комп'ютерної безпеки, яка шукає проблему, щоб спробувати допомогти вам або навіть самому зловмисникові, велика ймовірність, що ваша проблема буде щонайменше на 95% ідентичною для кожного іншого випадку, який вони мають коли-небудь дивився.

Не сприймайте атаку особисто і не приймайте рекомендацій, які випливають тут, або які ви отримуєте від інших людей особисто. Якщо ви читаєте це після того, як тільки ви стали жертвою злому веб-сайту, тоді я дуже шкодую, і я дуже сподіваюся, що ви зможете знайти тут щось корисне, але це не час, щоб дозволити вашому Его заважати тому, що вам потрібно робити.

Ви щойно з’ясували, що ваш сервер (и) зламався. А тепер що?

Не панікувати. Абсолютно не дійте поспіхом і абсолютно не намагайтеся робити вигляд, що речі ніколи не відбувалися і не дійте зовсім.

По-перше: зрозумійте, що катастрофа вже сталася. Це не час для відмови; саме час прийняти те, що сталося, бути реалістичним щодо цього та вжити заходів щодо управління наслідками наслідків.

Деякі з цих кроків зашкодять, і (якщо на вашому веб-сайті немає копії моїх реквізитів), я дійсно не хвилююся, якщо ви ігноруєте всі або деякі з цих кроків, але це зробить все в кращому підсумку. Ліки може виглядати жахливо, але іноді вам доведеться не помітити, що якщо ви дійсно хочете, щоб ліки спрацювало.

Не дозволяйте проблемі стати гіршою, ніж вона є:

1. Перше, що вам слід зробити - це відключити пошкоджені системи від Інтернету. Незалежно від будь-яких інших проблем, залишаючи систему, підключену до Інтернету, лише дозволить атаці тривати. Я маю на увазі це досить буквально; змусити когось фізично відвідати сервер та відключити мережеві кабелі, якщо для цього потрібно, але відключіть жертву від її гнучки, перш ніж спробувати зробити щось інше.
2. Змініть усі ваші паролі для всіх облікових записів на всіх комп’ютерах, які перебувають у тій самій мережі, що і компрометовані системи. Насправді ні. Усі рахунки. Всі комп'ютери. Так, ви маєте рацію, це може бути зайвим; з іншого боку, це не може. Ви не знаєте жодного способу, чи не так?
3. Перевірте свої інші системи. Зверніть особливу увагу на інші послуги, що стоять перед Інтернетом, і на ті, що зберігають фінансові чи інші дані, комерційно важливі.
4. Якщо система зберігає особисті дані будь-кого, одразу зробіть повне та відверте розкриття будь-кому, хто потенційно постраждав. Я знаю, що це важко. Я знаю, що це буде боляче. Я знаю, що багато підприємств хочуть підламати подібну проблему під килим, але я боюся, що вам просто доведеться з цим впоратися.

Все ще вагаєтесь зробити цей останній крок? Я розумію, я. Але подивіться на це так:

У деяких місцях ви, можливо, маєте юридичну вимогу повідомити владу та / або жертв такого роду порушення конфіденційності. Однак, якщо роздратовано ваших клієнтів, ви можете їм розказати про проблему, вони будуть набагато більше роздратовані, якщо ви не скажете їм, і вони дізнаються про себе лише після того, як хтось стягне товари на суму 8000 доларів за допомогою реквізитів кредитної картки, які вони викрали з вашого сайту.

Пам'ятаєте, що я казав раніше? Погане вже трапилося . Питання лише в тому, наскільки добре ви з цим справляєтеся.

Зрозумійте проблему повністю:

1. НЕ ставте постраждалих систем назад до Інтернету, поки цей етап не буде повністю завершений, якщо тільки ви не хочете бути особою, чия посада стала для мене важливою для насправді, вирішивши написати цю статтю. Я не посилаюся на посаду, щоб люди могли придбати дешевий сміх; Я посилаюсь, щоб попередити вас про наслідки, якщо не виконати цього першого кроку.
2. Вивчіть "атаковані" системи, щоб зрозуміти, яким чином атаки вдалося пошкодити вашу безпеку. Докладіть усіх зусиль, щоб з’ясувати, звідки "прийшли" атаки, щоб ви зрозуміли, які проблеми у вас є і потрібно вирішити, щоб забезпечити безпеку вашої системи в майбутньому.
3. Вивчіть «атаковані» системи ще раз, щоб зрозуміти, куди пішли атаки, щоб зрозуміти, які системи були піддані атаці. Переконайтеся, що ви відстежуєте будь-які вказівки, які передбачають, що компрометовані системи можуть стати плацдармом для подальшого нападу на ваші системи.
4. Переконайтесь, що "шлюзи", які використовуються в будь-яких атаках, повністю зрозумілі, щоб ви могли почати їх правильно закривати. (наприклад, якщо ваші системи були порушені атакою ін'єкції SQL, то не тільки вам потрібно закрити конкретний недосконалий рядок коду, який вони зламали, ви хочете перевірити весь ваш код, щоб побачити, чи помилка одного типу було зроблено в іншому місці).
5. Зрозумійте, що атаки можуть досягти успіху через більше ніж один недолік. Часто атаки досягають успіху не через пошук однієї основної помилки в системі, а шляхом з’єднання разом декількох питань (іноді незначних і тривіальних самих) для компрометації системи. Наприклад, використання атак з інжекцією SQL для відправки команд на сервер бази даних, виявлення веб-сайту / програми, на яку ви атакуєте, працює в контексті адміністративного користувача та використовує права цього облікового запису як драпінг для компрометації інших частин система. Або як хакери люблять називати це: "черговий день в офісі, скориставшись поширеними помилками людей".

Складіть план відновлення та відновіть свій веб-сайт в Інтернеті та дотримуйтесь його:

Ніхто не хоче перебувати в офлайні довше, ніж це має бути. Це дано. Якщо цей веб-сайт є механізмом отримання доходу, тоді тиск, щоб швидко повернути його назад, буде сильним. Навіть якщо єдине, про що йдеться, - це репутація вашої / вашої компанії, це все одно створює чималий тиск для швидкого відновлення речей.

Однак не піддавайтеся спокусі занадто швидко повернутися в Інтернет. Замість цього рухайтеся якомога швидше, щоб зрозуміти, що спричинило проблему, і вирішити її, перш ніж повернутися в Інтернет, інакше ви майже напевно знову станете жертвою вторгнення, і пам’ятайте, «колись зламатись, можна кваліфікувати як нещастя; знову зламатись прямо згодом, це виглядає як необережність "(із вибаченнями Оскара Уайльда).

1. Я припускаю, що ви зрозуміли усі проблеми, які призвели до успішного втручання, перш ніж ви навіть розпочали цей розділ. Я не хочу перебільшувати справу, але якщо ви цього не зробили першими, то вам дійсно потрібно. Вибачте.
2. Ніколи не платять гроші за шантаж / захист. Це знак легкої позначки, і ви не хочете, щоб ця фраза ніколи не використовувала вас для опису.
3. Не спокушайтесь повернути той самий сервер (-ів) назад в Інтернет без повної перебудови. Потрібно набагато швидше створити нову скриньку або "запустити сервер з орбіти і зробити чисту установку" на старому апаратному забезпеченні, ніж перевірити кожен кут старої системи, щоб переконатися, що він чистий, перш ніж повертати його назад знову в Інтернеті. Якщо ви не згодні з цим, то, напевно, ви не знаєте, що насправді означає забезпечити повну очищення системи, або процедури розгортання вашого веб-сайту є нечестивим безладом. Імовірно, у вас є резервні копії та тестові розгортання вашого сайту, які ви можете просто використовувати для створення активного сайту, і якщо ви цього не зробите, то це не ваша найбільша проблема.
4. Будьте дуже обережні щодо повторного використання даних, які були "живими" в системі під час злому. Я не скажу "ніколи не роби цього", тому що ти просто проігноруєш мене, але відверто кажучи, я думаю, що потрібно враховувати наслідки збереження даних, коли знаєш, що не можеш гарантувати їх цілісність. В ідеалі слід відновити це з резервної копії, зробленої до вторгнення. Якщо ви цього не можете чи не хочете, ви повинні бути дуже обережними з цими даними, тому що вони загрожують. Особливо слід знати про наслідки для інших, якщо ці дані належать клієнтам чи відвідувачам сайту, а не безпосередньо вам.
5. Уважно стежте за системами. Ви повинні вирішити це в майбутньому як процес, що триває (докладніше нижче), але ви берете на себе будь-які болі, щоб бути пильними протягом періоду, одразу після повернення вашого веб-сайту в Інтернеті. Зловмисники майже напевно повернуться, і якщо ви зможете помітити їх, що намагаються пробитись знову, ви, безсумнівно, зможете швидко побачити, чи дійсно ви закрили всі отвори, які вони раніше використовували, а також будь-які зроблені для себе, і ви можете зібрати корисне інформацію, яку ви можете передати місцевим правоохоронним органам.

Зниження ризику в майбутньому.

Перше, що вам потрібно зрозуміти, це те, що безпека - це процес, який вам доведеться застосовувати протягом усього життєвого циклу проектування, розгортання та обслуговування системи, орієнтованої на Інтернет, а не те, що ви зможете згодом переплести кілька шарів над своїм кодом, як дешево фарба. Щоб бути належним чином захищеним, сервіс та додаток повинні бути розроблені з самого початку, враховуючи це як одну з головних цілей проекту. Я розумію, що це нудно, і ви все це чули раніше і що я "просто не усвідомлюю тиску", щоб ваш бета-сервіс web2.0 (бета) перейшов у статус бета в Інтернеті, але факт полягає в тому, що це триває повторюватися, тому що це було правдою вперше, коли це було сказано, і це ще не стало брехнею.

Ви не можете усунути ризик. Ви навіть не повинні намагатися це робити. Однак вам слід зробити, щоб зрозуміти, які ризики для безпеки важливі для вас, і зрозуміти, як керувати та зменшувати як вплив ризику, так і ймовірність виникнення ризику.

Які заходи можна вжити, щоб зменшити ймовірність нападу?

Наприклад:

1. Чи був недолік, який дозволив людям проникнути на ваш сайт відомою помилкою в коді постачальників, для якої доступно виправлення? Якщо так, чи потрібно переосмислити свій підхід до того, як виправляти програми на своїх Інтернет-серверах?
2. Чи був недолік, який дозволив людям увірватися на ваш сайт, невідомий помилка коду постачальника, для якого патч не був доступний? Я, звичайно, не рекомендую змінювати постачальників кожного разу, коли щось подібне кусає вас, тому що у них є всі проблеми, і ви втратите платформи за рік максимум, якщо приймете такий підхід. Однак, якщо система постійно дає вам змогу, вам слід або перейти на щось більш надійне, або, принаймні, перевлаштувати систему, щоб уразливі компоненти залишалися загорнуті у вату і якомога далі від ворожих очей.
3. Чи був розроблений вами (або підрядник, який працював на вас) недоліком у коді? Якщо так, чи потрібно переосмислити свій підхід до того, як ви затверджуєте код для розгортання на своєму веб-сайті? Чи могла помилка потрапила за допомогою вдосконаленої тестової системи чи із змінами у вашому "стандартному" кодуванні (наприклад, поки технологія не є панацеєю, ви можете зменшити ймовірність успішної атаки ін'єкції SQL, використовуючи добре задокументовані методи кодування. ).
4. Чи був недолік через проблему з тим, як було розгорнуто сервер чи прикладне програмне забезпечення? Якщо так, чи використовуєте ви автоматизовані процедури для створення та розгортання серверів, де це можливо? Це чудова допомога у підтримці послідовного "базового" стану на всіх ваших серверах, мінімізуючи кількість замовлених робіт, які необхідно виконати на кожному з них, і, таким чином, сподіваємось мінімізувати можливість помилки. Те ж саме стосується розгортання коду - якщо вам потрібно зробити щось "особливе" для розгортання останньої версії веб-програми, тоді постарайтеся автоматизувати його та забезпечити його завжди послідовно.
5. Чи могли втрутитися вторгнення раніше, покращивши моніторинг ваших систем? Звичайно, цілодобовий моніторинг або система «за викликом» для вашого персоналу може не бути рентабельною, але є компанії, які можуть контролювати ваші веб-сервісні послуги для вас та попереджати вас у разі виникнення проблеми. Ви можете вирішити, що ви не можете собі цього дозволити чи не потрібно, і це просто чудово ... просто врахуйте це.
6. Використовуйте такі інструменти, як провідниковий простір і ніссус, де це доречно, але не використовуйте їх лише сліпо, тому що я це сказав. Знайдіть час, щоб навчитися використовувати декілька хороших інструментів безпеки, що відповідають вашому середовищу, постійно оновлюйте ці інструменти та користуйтеся ними регулярно.
7. Розгляньте можливість найняти експертів із безпеки для регулярного "аудиту" безпеки вашого веб-сайту. Знову ж таки, ви можете вирішити, що ви не можете собі цього дозволити чи не потрібно, і це просто чудово ... просто врахуйте це.

Які заходи можна вжити, щоб зменшити наслідки успішного нападу?

Якщо ви вирішили, що "ризик" затоплення нижнього поверху вашого будинку високий, але недостатньо високий, щоб вимагати переїзду, вам слід принаймні перемістити незамінні сімейні реліквії наверх. Правильно?

1. Чи можете ви зменшити кількість послуг, які безпосередньо піддаються впливу Інтернету? Чи можете ви дотримуватися певного розриву між вашими внутрішніми послугами та послугами, орієнтованими на Інтернет? Це гарантує, що навіть якщо ваші зовнішні системи поставлені під загрозу, шанси використовувати це як плацдарм для атаки на ваші внутрішні системи є обмеженими.
2. Чи зберігаєте ви інформацію, яку не потрібно зберігати? Чи зберігаєте ви таку інформацію "в Інтернеті", коли її можна було б архівувати десь в іншому місці. У цій частині є два моменти; очевидним є те, що люди не можуть вкрасти у вас інформацію, якої у вас немає, а другий момент - чим менше ви зберігаєте, тим менше вам потрібно підтримувати і кодувати, і тому менше шансів помилок потрапляти в ваш код або дизайн систем.
3. Ви використовуєте принципи "найменшого доступу" для свого веб-додатка? Якщо користувачам потрібно читати лише з бази даних, переконайтеся, що обліковий запис, який веб-додаток використовує для обслуговування, має лише доступ для читання, не дозволяйте йому записувати доступ і, звичайно, не мати системного рівня.
4. Якщо ви не дуже досвідчені в чомусь, і це не є головним у вашому бізнесі, подумайте про те, як це зробити аутсорсинг. Іншими словами, якщо ви запускаєте невеликий веб-сайт, говорячи про написання коду додатків для настільних комп'ютерів, і вирішили почати продавати невеликі додатки для настільних ПК із сайту, тоді подумайте про "аутсорсинг" вашої системи замовлення кредитної картки комусь, наприклад, Paypal.
5. Якщо це взагалі можливо, зробіть практичне відновлення зі збитих систем частиною вашого плану відновлення після аварій. Це, мабуть, лише черговий "сценарій катастроф", з яким ви можете зіткнутися, просто один із власним набором проблем та проблем, які відрізняються від звичайної "серверної кімнати, що загорілася" / ", вторглися гігантські сервери, що їдять халяву". (редагувати, за XTZ)

... І, нарешті

Я, мабуть, не залишив жодного кінця речей, які інші вважають важливими, але наведені вище кроки повинні принаймні допомогти вам почати розбирати речі, якщо вам не пощастило, щоб стати жертвою хакерів.

Перш за все: не панікуйте. Подумайте, перш ніж діяти. Дійте рішуче, приймаючи рішення, і залиште коментар нижче, якщо вам є що додати до мого списку кроків.

Завжди нукеруйте його з орбіти. Це єдиний спосіб бути впевненим.

_{(джерело: flickr.com )}

Більшість систем є цілісними утвореннями, які мають внутрішню, неявну довіру. Довіра компрометованої системи - це неявна заява, що ви довіряєте тому, у кого було порушено порушення вашої системи. Іншими словами:

Ви не можете довіряти цьому Не турбуйтеся прибиранням. Відключіть та ізолюйте машину негайно. Розумійте характер порушення, перш ніж продовжувати, інакше ви запрошуєте те ж саме знову. Спробуйте, якщо можливо, отримати дату і час порушення, щоб у вас була система відліку. Це вам потрібно, тому що якщо ви відновитесь із резервної копії, ви повинні бути впевнені, що сама резервна копія не має копії компромісу. Протріть перед відновленням - не приймайте ярлики.

Практично кажучи, більшість людей цього не роблять, тому що думають, що це зайде занадто довго або буде занадто руйнівним. Я порадив незліченним безлічі клієнтів щодо ймовірності виникнення проблем, але перевстановлення часто збивається, хто приймає рішення, з однієї з цих причин.

Це було сказано, що в системах, де я впевнений, що я знаю спосіб введення та повну міру пошкодження (тверді журнали поза машиною, як правило, з IDS, можливо, SELinux або щось подібне, що обмежує область вторгнення), я провели очищення без перевстановлення, не відчуваючи занадто винного.

Швидше за все, у них немає процедури відновлення після аварій, яка достатньо перевірена, щоб вони могли впевнено робити відновлення, або незрозуміло, скільки часу це займе або який би вплив був ... або резервні копії недостовірні або їхні аналітики ризиків не розумію сфери компрометованої системи. Я можу придумати багато причин.

Я б сказав, що це здебільшого щось непотрібне в основних процедурах і політиці, і це не те, що ви хотіли б визнати відкрито - і натомість ви займаєте оборонну позицію. Принаймні, я не можу бачити чи захищати, щоб не стирати порушену систему, незалежно від того, під яким кутом ви дивитесь на неї.

Я попередньо не заводив цю систему, щоб я міг зробити деякий аналіз вектора, який вони потрапили, та подальший аналіз використання та побачити, куди вони потрапили всередину.

Після того, як ви вкоренилися - у вас є живий медовий горщик, і він може запропонувати набагато більше, ніж просто злом. - особливо для поліції.

• це сказав, що я маю намір отримати можливість отримати чисту систему в режимі гарячого режиму очікування та мати можливість швидко пропонувати розширену мережеву безпеку, щоб ізолювати коріння.