Нещодавно (але це також періодичне запитання) ми побачили 3 цікавих теми про злому та безпеку:

Як я маю справу з компрометованим сервером? .
Виявлення того, як зламав сервер був зламаний
правами доступу до файлів питання

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

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

Справа не лише у захисті сервера та коду, а й у аудиті, реєстрації та зустрічних заходах.

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

Якщо так, чи можете ви поділитися своїм списком та своїми ідеями / думками?

ОНОВЛЕННЯ

Я отримав кілька хороших та цікавих відгуків.

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

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

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

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

Що з даними, засобами масової інформації, органами влади та конкурентами?

Слід зосередитись на двох великих напрямках:

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

Зробити це важко

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

• Ведіть журнали (див. Також Управління інформацією про безпеку подій)
  • Будь-які спроби авторизації, як успішні, так і невдалі, бажано, щоб джерела інформації були недоторканими.
  • Журнали доступу до брандмауера (це може включати брандмауері на сервері, якщо вони використовуються).
  • Журнали доступу до веб-сервера
  • Журнали аутентифікації сервера баз даних
  • Журнали використання, що стосуються додатків
  • Якщо це можливо, SIEM може подавати сповіщення про підозрілі схеми.
• Забезпечити належний контроль доступу
  • Переконайтеся, що права встановлені правильно скрізь, і уникайте "ледачих прав" ("просто дайте всім читати"), де це можливо.
  • Періодичний аудит ACL, щоб переконатися, що процедури насправді виконуються, а тимчасові кроки усунення несправностей ("дайте всім прочитати, подивіться, чи працює він тоді") були видалені правильно після закінчення усунення несправностей.
  • Усі правила проходження брандмауера потрібно обґрунтовувати та періодично перевіряти.
  • Також потрібно перевірити контроль доступу до веб-сервера, як ACL, так і веб-сервер та файлову систему.
• Забезпечити управління змінами
  • Будь-які зміни в середовищі безпеки потребують централізованого відстеження та перегляду більш ніж однією людиною.
  • Патчі повинні бути включені в цей процес.
  • Наявність спільної збірки ОС (шаблону) спростить середовище та полегшить відстеження та застосування.
• Вимкнути облікові записи гостей.
• Переконайтеся, що всі паролі не встановлені за замовчуванням.
  • Позастарелі програми можуть налаштувати користувачів заздалегідь заданими паролями. Змініть їх.
  • Багато ІТ-приладів постачаються з парами користувачів / паролів, які дуже добре відомі. Змініть їх, навіть якщо ви входите в цю штуку лише раз на рік.
• Практикуйте найменше-привілей. Надайте користувачам доступ, який їм справді потрібен.
  • Для користувачів адміністратора розумне налаштування двох облікових записів. Один звичайний обліковий запис, який використовується для електронної пошти та інших офісних завдань, а другий для роботи з підвищеними показниками. Відеомагнітофони полегшують життя.
  • НЕ заохочуйте регулярне використання загальних облікових записів адміністратора / root, важко відстежити, хто що робив.

Створення політик та процедур для спокійного та ефективного поводження з події, коли хтось потрапляє

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

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

В ідеалі ваша політика відновлення стихійних лих вже визначила, наскільки довго певні служби можуть бути недоступними до початку дії політики ДР. Це допоможе реагувати на інциденти, оскільки такі події є катастрофами. Якщо подія має тип, у якому вікно відновлення НЕ буде дотримано (приклад: сайт із резервним резервним копією резервного копіювання DR отримує в режимі реального часу канал змінених даних, і зловмисники видаляли купу даних, які реплікувалися на сайт ДР до того, як вони були Тому необхідно використовувати процедури відновлення холоду), тоді вищі керівництву потрібно буде брати участь у переговорах з оцінки ризику.

Деякі компоненти будь-якого плану реагування на інциденти:

• Визначте порушені системи та відкриті дані.
• Заздалегідь визначте, чи потрібно зберігати юридичні докази для можливого притягнення до відповідальності.
  • Якщо слід зберігати докази , не торкайтеся нічого про цю систему, якщо цього абсолютно не потрібно . Не входити в нього. Не просіюйте журнали-файли. Робити. Ні. Торкніться
  • Якщо докази потрібно зберегти, компрометовані системи потрібно залишити в Інтернеті, але відключити їх до тих пір, поки сертифікований експерт з судових експертиз комп'ютера не зможе розрізати систему таким чином, що сумісний із правилами обробки доказів.
    • Вимкнення компрометованої системи може пошкодити дані.
    • Якщо ваша система зберігання дозволяє це (дискретний пристрій SAN), зробить знімок уражених LUN перед відключенням та позначте їх лише для читання.
  • Правила поводження з доказами складні, і їх так легко викрутити. Не робіть цього, якщо ви не пройшли навчання з них. Більшість загальних SysAdmins НЕ проводять такого роду навчання.
  • Якщо докази зберігаються, трактуйте втрату сервісу як аварійну ситуацію з втратою апаратного забезпечення та розпочніть процедури відновлення з новим обладнанням.
• Заздалегідь встановіть правила, які типи катастроф вимагають, які види сповіщення. Закони та норми регулювання залежать від місцевості.
  • Правила, що стосуються "впливу" та "перевіреного компромісу", різняться.
  • Правила сповіщення потребують залучення відділу зв’язку.
  • Якщо необхідне повідомлення буде достатньо великим, доведеться залучати управління вищого рівня.
• Використовуючи дані ДР, визначте, скільки часу "WTF щойно трапилося" можна витратити до того, як повернення послуги на лінію стане вищим пріоритетом.
  • Часи відновлення обслуговування можуть вимагати роботи, щоб з'ясувати, що сталося, підпорядковане. Якщо так, то після відновлення служб зніміть диск диска для ураженого пристрою для розсічення (це не доказна копія, це техніка, яка повинна повернути інженеру).
  • Плануйте свої завдання з відновлення послуг включати повне відновлення постраждалої системи, а не лише очищення безладу.
  • У деяких випадках терміни відновлення служби досить жорсткі, що зображення диска потрібно робити відразу після виявлення компромісу, а юридичні докази не зберігати. Після відновлення служби може розпочатися робота з з'ясування того, що сталося.
• Просійте журнали для отримання інформації про те, як зловмисник потрапив і що він, можливо, зробив колись.
• Просійте змінені файли для інформації про те, як вони потрапили та що вони зробили, як тільки вони потрапили.
• Просійте журнали брандмауера, щоб отримати інформацію про те, звідки вони надходили, куди вони могли надіслати дані та скільки їх може бути надіслано.

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

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

Наскільки правильні процедури служби довідки можуть допомогти

Нам потрібно врахувати, як тут звертаються із клієнтами (це стосується як внутрішніх, так і зовнішніх клієнтів, які звертаються у службу підтримки).

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

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

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

Як можуть допомогти стандарти розгортання

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

Шаблон повинен працювати як для ОС, так і для додатків і містити не лише безпеку, але й усі налаштування, які ви використовуєте, і в ідеалі повинен бути сценарієм (наприклад, шаблон), а не застосовуватися вручну (наприклад, контрольний список), щоб максимально усунути помилки людини.

Це допомагає різними способами:

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

Більшість наших серверів для більшості наших заходів запобігають брандмауерам хостів та мереж, антивірусним / шпигунським програмним забезпеченням, мережевим IDS та ідентифікатором хоста. Це разом із усіма загальними вказівками, такими як мінімальні приватні приватні відеозаписи, видалення несуттєвих програм, оновлень тощо. Звідти ми використовуємо продукти, такі як Nagios, Кактуси та рішення SIEM для різних базових накладок та сповіщень про події. Наш HIDS (OSSEC) також робить безліч журналів типу SIEM, що також приємно. Ми, як правило, намагаємося робити блок блоків якомога більше, але потім здійснюємо централізований журнал, тому якщо щось трапляється, ми можемо їх проаналізувати та співвіднести.

Те, що ви дійсно хочете, може розпастись на 3 основні сфери:

1. Стандартна конфігурація системи
2. Моніторинг систем / додатків
3. Відповідь на випадок

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

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

В ідеалі ви повинні мати найменшу кількість підтримуваних ОС, і створити кожен з них за допомогою базового зображення. Ви повинні відхилятися від бази лише стільки, скільки потрібно для надання будь-яких послуг, які надає сервер. Відхилення повинні бути задокументовані або можуть знадобитися, якщо вам доведеться зустріти PCI / HIPAA / тощо. або інші відповідність. Використання систем управління розгортанням та конфігурацією може допомогти багато в цьому відношенні. Конкретизація буде багато залежати від вашої ОС, шпилька / лялька / Altiris / DeployStudio / SCCM тощо.

Ви обов'язково повинні проводити якийсь регулярний огляд журналу. Враховуючи такий варіант, SIEM може бути дуже корисним, але вони також мають і недолік дорогих як за ціною закупівлі, так і за рахунок витрат на нарощування. Перегляньте це запитання на веб-сайті IT Security SE, щоб отримати коментарі щодо аналізу журналів: як ви обробляєте аналіз журналу? Якщо це все ще занадто важко, навіть поширені інструменти, такі як LogWatch, можуть забезпечити хороший контекст для того, що відбувається. Важливий твір - це лише витратити час на огляд журналів. Це допоможе вам ознайомитись із тим, що являє собою нормальну поведінку, щоб ви могли розпізнати ненормальну.

Крім огляду журналу, важливий також моніторинг стану сервера. Знання, коли відбуваються зміни, планові чи ні, має вирішальне значення. Використовуючи локальний інструмент моніторингу, такий як Tripwire, можна попередити адміністратора про зміни. На жаль, так само, як SIEM та IDSes, є і недолік дорогості та / або придбання. Більше того, без гарної настройки ваші порогові показники сповіщення будуть настільки високими, що будь-які хороші повідомлення загубляться в шумі та стають марними.

Відповідна політика щодо інформації про безпеку та управління подіями (SIEM) допоможе вам полегшити життя в безпеці.

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

Більшість згаданих тут рішень застосовні на рівні хоста та мережі, але ми часто забуваємо про незахищені веб-програми. Веб-додатки - це найчастіше переглянута безпека. Шляхом веб-додатків зловмисник може отримати доступ до вашої бази даних або хоста. Жоден брандмауер, IDS, брандмауер не можуть захистити вас від них. OWASP підтримує список 10 найважливіших уразливостей та пропонує виправлення для них.

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide