Це канонічне запитання щодо безпеки сервера - відповідь на події порушення (хакерство)
Див. Також:

• Поради щодо забезпечення безпеки LAMP-сервера
• Перевстановити після кореневого компромісу?

Канонічна версія
Я підозрюю, що один або кілька моїх серверів порушені хакером, вірусом чи іншим механізмом:

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

Оригінальна версія

2011.01.02 - я вже в неділю підбираюся до роботи о 21.30, тому що наш сервер якимось чином був порушений, і це призвело до атаки DOS на нашого провайдера. Доступ до серверів до Інтернету було вимкнено, а це означає, що більше 5-600 сайтів наших клієнтів вже закриті. Тепер це може бути хакерство FTP або дещо слабкість у коді. Я не впевнений, поки не доїду.

Як я можу швидко відстежити це? Ми ведемо багато судових процесів, якщо я не поверну сервер якнайшвидше. Будь-яка допомога вдячна. У нас працює Open SUSE 11.0.

---

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

Ми відключили сервер від мережі. Він здійснював (намагаючись здійснити) напад на відмову від служби на інший сервер в Індонезії, і винна сторона також базувалася там.

Ми спершу спробували визначити, звідки це сервер, зважаючи на те, що у нас на сервері понад 500 сайтів, ми очікували, що буде деякий час місячним світлом. Однак, маючи доступ до SSH, ми виконали команду знайти всі файли, відредаговані або створені за час початку атаки. На щастя, образливий файл був створений під час зимових свят, що означало, що на сервері на той час не було створено багато інших файлів.

Тоді нам вдалося виявити файл-образник, який знаходився у папці завантажених зображень на веб-сайті ZenCart .

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

Це означало, що будь-які файли можуть бути завантажені, включаючи файл PHP для атаки. Ми забезпечили вразливість за допомогою ZenCart на зараженому сайті та видалили файли, що ображають.

Робота виконана, і я був 2 години ранку вдома

---

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

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

Не панікуйте

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

1. Важко точно визначити, коли відбулося вторгнення.
2. Це не допоможе вам закрити "дірку", яка дозволила їм зламатись за останній час, а також не боротися з наслідками будь-яких "крадіжок даних", які також могли відбутися.

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

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

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

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

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

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

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

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

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

Однак, якщо роздратовано ваших клієнтів, ви можете їм розказати про проблему, вони будуть набагато більше роздратовані, якщо ви не скажете їм, і вони дізнаються про себе лише після того, як хтось стягне товари на суму 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. Якщо це взагалі можливо, зробіть практичне відновлення зі збитих систем частиною вашого плану відновлення після аварій. Це, мабуть, лише черговий "сценарій катастроф", з яким ви можете зіткнутися, просто один із власним набором проблем та проблем, які відрізняються від звичайної "серверної кімнати, що загорілася" / ", вторглися гігантські сервери, що їдять халяву".

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

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

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

Це здається, що трохи в голові; це добре. Зателефонуйте своєму начальнику і почніть домовлятися про бюджет на реагування на надзвичайні ситуації. 10 000 доларів можуть бути хорошим місцем для початку. Тоді вам потрібно знайти когось (PFY, співробітника, менеджера), щоб почати телефонувати в компанії, які спеціалізуються на реагуванні на інциденти з безпекою. Багато людей можуть відповісти протягом 24 годин, а іноді навіть швидше, якщо у них є офіс у вашому місті.

Вам також потрібен хтось, хто б просив клієнтів; Безсумнівно, хтось уже є. Хтось повинен телефонувати з ними, щоб пояснити, що відбувається, що робиться для вирішення ситуації та відповісти на їх запитання.

Тоді вам потрібно ...

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

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

3. Отримайте чисту USB-накопичувач та запасні жорсткі диски. Ви збираєте докази тут. Зробіть резервні копії всього, що вам здається, може бути доречним; спілкування з вашим Інтернет-провайдером, мережеві звалища тощо. Навіть якщо правоохоронні органи не залучаються, у разі судового розгляду вам потрібно, щоб ці докази підтвердили, що ваша компанія розглядала інцидент із безпекою професійно та належним чином.

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

5. Далі вам потрібно зняти зловмисника та закрити отвір (и). Імовірно, зловмисник більше не має інтерактивного доступу, оскільки ви потягнули мережу. Тепер вам потрібно ідентифікувати, документувати (із резервними копіями, скріншотами та власними особистими спостереженнями; або, бажано, навіть видалити накопичувачі з постраждалих серверів та зробити повну копію образу диска), а потім видалити будь-який код та процеси, які він залишив . Наступна частина буде смоктати, якщо у вас немає резервного копіювання; Ви можете спробувати відкрутити нападника від системи вручну, але ви ніколи не будете впевнені, що у вас все, що він залишив після себе. Руткіти є порочними, і не всіх їх можна виявити. Найкращою відповіддю буде виявити вразливість, до якої він потрапляв, зробити копії зображень із уражених дисків, а потім витерти пошкоджені системи та перезавантажити з відомого хорошого резервного копіювання. Дон ' t сліпо довіряти своїй резервній копії; перевірте це! Відновіть або закрийте вразливість до того, як новий хост знову вийде в мережу, а потім переведіть його в Інтернет.

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

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

Ви маєте мої втіхи для вашої ситуації. Удачі.

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

Короткий підсумок основних етапів - це.

• Зверніться до політики безпеки та управління.
• Отримайте контроль (візьміть комп'ютер офлайн)
• Проаналізуйте вторгнення, дістаньте журнали, з’ясуйте, що пішло не так
• Ремонт речі
  • Встановіть чисту версію вашої операційної системи !!! Якщо система була порушена, ви не можете їй довіряти, періодично.
• Оновіть системи, щоб це не повторилося
• Відновити операції
• Оновіть політику на майбутнє та документуйте

Я хотів би конкретно вказати на розділ E.1.

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

Якщо у вас немає такої системи, як, наприклад, провідниковий провід, немає можливого способу бути на 100% впевненим, що ви очистили систему.

1. Визначте проблему. Прочитайте журнали.
2. Містять . Ви відключили сервер, тому це зроблено.
3. Ліквідація . Перевстановіть уражену систему, швидше за все. Не стирайте жорсткий диск зламаного, використовуйте новий. Це безпечніше, і вам може знадобитися старий, щоб відновити некрасиві хаки, які не були підкріплені, і провести криміналістику, щоб дізнатися, що сталося.
4. Відновити . Установіть все, що потрібно, і відновіть резервні копії, щоб забезпечити своїх клієнтів в мережі.
5. Подальше спостереження . З’ясуйте, у чому проблема, і не дайте їй повторитися.

Відповідь Роберта на «гірку таблетку» є точковою, але повністю загальною (ну, як було у вас запитання). Це здається, що у вас є проблеми з управлінням і гостро потребуєте штатної систематичної системи, якщо у вас є один сервер і 600 клієнтів, але це вам зараз не допомагає.

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

Однак ви майже напевно просто жертва скрипту, який хотів отримати стартовий майданчик для DoS-атак, або IRC-вибухів, або щось зовсім не пов’язане з сайтами та даними ваших клієнтів. Тому в якості тимчасового заходу під час відновлення ви можете розглянути можливість створення важкого вихідного брандмауера на коробці. Якщо ви можете заблокувати всі вихідні з’єднання UDP та TCP, які не є абсолютно необхідними для функціонування ваших сайтів, ви можете легко зробити ваше скомпрометоване поле непотрібним для того, хто запозичить його у вас, і зменшити вплив на мережу вашого провайдера до нуля.

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

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

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

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

Вам потрібно перевстановити. Збережіть те, що вам справді потрібно. Але майте на увазі, що всі ваші запущені файли можуть бути заражені та підроблені. Я написав наступне в python: http://frw.se/monty.py, який створює MD5-підсумки всіх ваших файлів у заданому каталозі, і при наступному запуску він перевіряє, чи щось було змінено, а потім виводить те, що змінили файли та змінили файли.

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

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

ПРИМІТКА. Це не рекомендація. Мій конкретний протокол реагування на інциденти, ймовірно , не застосовуватиме немодифікований випадок Гранта Ундіна.

В наших навчальних закладах є близько 300 дослідників, які займаються лише обчисленнями. У вас 600 клієнтів з веб-сайтами, тому ваш протокол, ймовірно, буде іншим.

Першими кроками нашого сервера, коли сервер отримує компромісний протокол :

1. Визначте, що зловмисник зміг отримати корінь (підвищені привілеї)
2. Відключіть підключені сервери. Мережа чи потужність? Будь ласка, дивіться окрему дискусію .
3. Перевірте всі інші системи
4. Завантажте уражені сервери з живого CD
5. (необов’язково) Візьміть зображення всіх системних дисківdd

6. Почніть займатися криміналістичною експертизою. Подивіться на журнали, з’ясуйте час нападу, знайдіть файли, які були змінені на той час. Спробуйте відповісти як? питання.

   • Паралельно плануйте та виконайте відновлення.
   • Скиньте всі паролі root та користувача перед тим, як відновити послугу

Навіть якщо "все заднім кутом і руткіти очищені", не довіряйте цій системі - перевстановіть з нуля.

За моїм обмеженим досвідом, системні компроміси в Linux, як правило, більш "всебічні", ніж у Windows. Кореневі набори набагато частіше включають заміну системних бінарних файлів на індивідуальний код для приховування зловмисного програмного забезпечення, а бар'єр для гарячого виправлення ядра трохи нижчий. Плюс це домашня ОС для багатьох авторів шкідливих програм. Загальне керівництво завжди полягає в тому, щоб відновити постраждалий сервер з нуля, і це загальне керівництво з причини.

Відформатуйте цього цуценя.

Але якщо ти не зможеш відновити (або сили, які є, не дасть тобі відновити його проти наполегливого наполягання на необхідності цього), що ти шукатимеш?

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

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

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

Я б сказала, що @Robert Moir, @Aleksandr Levchuk, @blueben та @Matthew Bloch - все це в значній мірі.

Однак відповіді різних плакатів різняться - деякі більше на високому рівні і говорять про те, які процедури ви повинні мати (взагалі).

Я вважаю за краще розділити це на декілька окремих частин 1) Triage, AKA Як боротися з клієнтами та правовими наслідками та визначити, куди звернутися звідти (перераховано Робертом та @blueben 2) Пом'якшення впливу 3 ) Відповідь на випадок випадків 4) Криміналістична експертиза 5) Елементи санації та зміни архітектури

(Вставте сюди заявку відповіді на сертифікат SANS GSC) На основі минулого досвіду я б сказав наступне:

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

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

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

Можливо, їм потрібно найняти спеціалізований SA на місці. Можливо, їм потрібна охорона. А може, їм потрібно повністю кероване рішення, таке як Firehost або Rackspace Managed, Softlayer, ServePath тощо.

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

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

Усі файли, які ображають, виявилися в папці / images / на деяких наших старих сайтах zencart. Здається, була вразлива безпека, яка дозволила (використовуючи згортку) будь-який ідіот завантажувати не зображення в розділ завантаження зображень у розділі адміністратора. Ми видалили неприйнятні файли .php та виправили сценарії завантаження, щоб заборонити будь-які завантаження файлів, які не є зображеннями.

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

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

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

Нетехнічні дії:

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

• Приховування інциденту безпеки - це не варіант.

• Повідомлення місцевим органам влади.
  ServerFault НЕ є місцем для отримання юридичної консультації, але це щось, що повинно бути включено в план реагування на інциденти.
  У деяких місцевостях та / або регульованих галузях обов'язково повідомляти про (певні) випадки безпеки місцевим органам правоохоронних органів, регулюючим органам або інформувати про це клієнтів / користувачів.
  Незважаючи на те, ні рішення про звіт, ні фактичний звіт не приймаються виключно в ІТ-департаменті. Очікуйте залучення від управління, юридичних та корпоративних комунікацій (маркетингу).
  Напевно, ви не повинні чекати занадто багато, Інтернет - це велике місце, де кордони мають мало значення, але відділи кіберзлочинності, які існують у багатьох відділах поліції, вирішують цифрові злочини та можуть притягнути винних до відповідальності.

Я думаю, що все зводиться до цього:

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

Якщо планувати не планується, планується вийти з ладу, і це ніде більше, ніж у безпеці систем. Коли <reacted> потрапить у вентилятор, вам краще бути готовим зіткнутися з цим.

Тут є ще одна (дещо натиснута) приказка, яка стосується тут: Профілактика краще, ніж лікування .

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

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

Це було зроблено - десь існує (або була) установка інтернет-банкінгу, яка має проксі-балансуючий проксі-сервер, спрямований до Інтернету, який вони збиралися використовувати для векторних атак подалі від їх пулу серверів. Експерт з питань безпеки Маркус Ранум переконав їх застосувати протилежний підхід, використовуючи зворотний проксі, щоб дозволяти лише відомі дійсні URL-адреси, а все інше відправляти на сервер 404 . Це витримало випробування часом напрочуд добре.

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

Але все це не є приводом для самовдоволення. Ви все одно повинні мати план на перші кілька годин після порушення. Жодна система не є досконалою, і люди роблять помилки.

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

Цей один лайнер перераховує всі файли, відсортовані за ctime:

find / -type f -print0 | xargs -0 stat --format '%Z :%z %n' | sort -nr > /root/all_files.txt

Тож якщо ви приблизно знаєте час компромісу, ви можете бачити, які файли змінюються чи створюються.