«Протистояння» очима захисника: Розповідь про PHDays CTF від учасника змагань



В цьому році головний хакерський конкурс PHDays змінив формат: ми відійшли від звичного CTF. Замість цього на форумі розгорнулася справжня битва хакерів і сб. Цього разу змагалися три команди: «хакери», «захисники» та SOC (security operations centers). Події на полігоні змагання були максимально наближені до реальності. У розпорядженні команд перебувала емуляція міста, в якому є банк, телеком-оператор, офіс великого холдингу, електроенергетична компанія та інші об'єкти.

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

Опис

17-18 травня 2016 року на конференції Positive Hack Days в Москві проводився характерний для великих подій з практичної інформаційної безпеки конкурс Capture The Flag (CTF). Цього року організатори дещо модифікували змагання, надавши йому формат «протистояння сил добра і зла у віртуальному місті, як і анонсувалося на сайті конференції PHDays.

Природно, що бажають спробувати свої сили в конкурсі було чимало. Учасників розділили не на 2, а на 3 функціональні напрями:

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

Захисники і SOC працюють в тандемі, захищаючи свої сервіси. Наш тандем виявився дійсно дуже продуктивним, як і прийнято в Росії :)

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



Збірна команда телеком-захисників «You Shall Not Pass» з великих операторів зв'язку і Solar JSOC, команда «False Positive»

Хакери, само собою, в конкурсі працюють окремо від своїх опонентів (щоб не було бійки), намагаючись отримати несанкціонований доступ до патентів ресурсів.

Вийшло досить цікаво, але подробиці змагання пізніше. Я у багатьох випадках намагаюся зрозуміти початкову причину будь трансформації в бік ускладнення. Логічно, що конференція повинна йти в ногу зі світовими тенденціями, але тут, можливо, на хвилі вражень від участі у змаганні, скажу, що Positive Technologies, схоже, навіть пішла на півкроку вперед (прогин зарахований?) — надовго? (компенсація прогину для збереження нейтральності).

Отже, явних причин кілька, частина з яких є наслідком інших.

1. Звернути увагу держави та бізнесу на:

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

3. Надати заходу масштабності.

4. Просування на ринку:

  • продуктів і послуг інформаційної безпеки;
  • тестування і популяризація серед послуг ІБ такого сервісу, як SOC (Security Operation Center).
Що з переліченого першопричина, а що наслідок — думаю, очевидно.
На повноту і широту аналізу не претендую, тому що свій кут огляду описав раніше.

Підготовка

Отже, наша збірна команда захисників телекому в тандемі з JSOC захищала публічні сервіси на базі IP, характерні для оператора зв'язку: особистий кабінет портал, сервіси надсилання платних повідомлень, інший VAS і т. п. Звичайно, невід'ємною частиною нашого завдання було забезпечення безпеки мережевого обладнання.

З приводу команди: нам довелося працювати з колегами-конкурентами, з якими ми до цього не були знайомі, і я, коли тільки дізнався про це, думав, що спочатку ми, як в «Месниках», пересобачимся один з одним, визначаючи, хто крутіший, а потім почнемо справу робити. На щастя, я виявився неправий, і причина банальна: у нас не було на це часу. Негласний принцип був такий: якщо ти крут — красава, молодець, ми в тебе віримо, твій талант визнаємо і не заперечуємо, ПРАЦЮЙ! А я просто переглянув бойовиків.

У «віртуальному місті», де відбувалися вищеописані події, було 5 об'єктів інфраструктури, за які йшла боротьба:

  • міський офіс;
  • банк 1;
  • банк 2;
  • енергетична компанія;
  • телекомунікаційна мережа.
Природно, без нормального технічного забезпечення ні місто не працював би, ні засоби захисту. Для оперативного моніторингу подій інформаційної безпеки, запобігання і відображення хакерських атак організатори нам надали:

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

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

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

Карта мережі містила виключно L3-інформацію по подсетям і їх топологическому розташуванню. Що якоїсь мережі знаходиться — потрібно було з'ясувати самостійно. З одного боку — ускладнення завдання, з іншого — зайвий впорскування драйву. Тобто, щоб знайти і знешкодити сервера, ми використовували ARP-таблиці L3-терминирующих пристроїв і сканери, розгортали елементи інфраструктури типу всусов і т.п., оновлювали, переконфигуряли, інтегрували… Все це, в тому числі і мережеве обладнання, що було на виртуалках. На настановної зустрічі Сергій Павлов з Positive Technologies обіцяв, що обчислювальних потужностей буде, принаймні, більше, ніж у нього на домашньому компі, і, схоже, не обдурив. Але потіло це обладнання від навантаження знатно, ми не соромилися у запитах необхідних виртуалок, так і хакери запускали вагон сканів одночасно.

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

А так: шановні захисники і «соки», ось вам ковток свободи, дивіться, не захлебнитесь. Буде все добре — ну та гаразд, якщо ж все не зовсім добре, завжди можна сказати: «А от якщо б у вас був наш MaxPatrol сканер або MaxPatrol SIEM...», а можна і не сказати, в залежності від ситуації. Правда, не чув поки, щоб таке говорили або навіть натякали.

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

Думка про резонансну зломі ГЕС

Бої без правил. Організовується поєдинок між бійцями Орком і Гобліном. Бійці початківці, але публіка козирна і при грошах. Впливовий любитель таких боїв, чиновник, кришують організаторів, робить дуже велику ставку на те, що Гоблін переможе. І тут Орк завдає хороший удар в корпус, після якого Гоблін «пливе». Суддя, всупереч правилам, зараховує це як удар в пах, відводячи убік Орка зі штрафним очком і надавши час на відновлення Гобліна. В процесі швидко шепоче Орку: «Тобі треба лягти. Тато сказав». І Орк, відмінно розуміючи, що навіть якщо він переможе і забере приз, то в майбутньому кар'єра бійця в цій організації для нього закрита, починає швидко міркувати, дивлячись на поступово приходить в себе Гобліна, як підставитися під «нокаутуючий удар, щоб було правдиво і переконливо для глядача.
Вже на наступний день після PHDays VI весь інтернет ряснів новини про те, як школяр зламав електростанцію і як хакери після успішного злому зупинили ГЕС і затопили місто.

Я брав участь у складі «захисників» телекому, тому думка базується на аналізі ситуації і аналогіях з моєї дзвіниці, але без знання деталей злому SCADA.

Як я писав в першої частини своєї серії відгуків про PHDays, однією з ключових для організаторів цілей було звернути увагу держави та бізнесу на необхідність захисту «інтернету речей» та інших підключаються до публічних мереж систем управління критичної інфраструктурою. Хоча сам і не працював з захистом SCADA, але з публічних джерел бачу, що коли будь-який пристрій починає управлятися за IP, а тим більше через Інтернет, на його безпеку мало хто звертає увагу. Як завжди, спочатку розвиваються технології, а потім вже їх безпеку. В результаті утворюється «інтернет дірявих речей». Чим це може загрожувати — залежить від того, до якого пристрою отримати доступ. Донести до громадськості це можна через новини, а щоб привернути журналюг — потрібно те, що буде сприйняте як сенсація. А куди вже сенсаційнішого, ніж зупинка електростанції і затоплення міста хакерами, яких сприймають, як максимум, хлопчиками з поставою мавпи за ноутбуком, вміють красти паролі?



Зображення: Xakep.ru

Є команда «захисників», які захарденили системи управління. Є SOC, який підключив все на моніторинг подій. Деталі підготовки описані в однойменній другий частини. Це, наскільки я знаю, комерційні компанії в профілем інформаційної безпеки, які на цьому конкурсі, напевно, хотіли б попіаритися, і тому поставляться серйозно до захисту промислових об'єктів. І тут, незважаючи на всю описану серйозність захисту, ГЕС ламають 2 рази… Невже так все погано з ІБ АСУТП в Росії?

Мої варіанти причин того, що сталося:

  1. Захисники погано захистили: або нормальних засобів захисту SCADA не існує в природі, або халатно поставилися до захисту;
  2. SOC недодивився: або погано інтегрували з мониторилками, або проклацали;
  3. Обмеження організаторами на засоби захисту;
  4. Тато сказав.
З першими двома все зрозуміло. Якщо реально SOC і захисники проклацали — туди їм і дорога. Але у мене є підозра, що введені організаторами обмеження передбачали можливість злому ГЕС хакерами. Ставка «татом» робилася на те, що ГЕС відключать і місто затоплять.

Щоб не бути голослівним з твердженням про обмеження з боку організаторів, скажу як учасник команди «захисників» телекому: обмеження на застосування захисту були, і досить міцні. Додаткові засоби захисту використовуй які завгодно, але з фундаментальних коштів нам заборонили навіть закрити на fіrewall зі світу SSH/RDP до патентів ресурсів, тільки до самого мережного обладнання, не кажучи вже про інших невикористовуваних сервісах. Міняй паролі, оновлюй, патчуй, реконфигуряй скільки завгодно, але сервіс повинен бути доступний… А я взагалі хотів поставити default deny, як і робиться в реальному житті (подробиці про ступінь наближеності до реального життя пізніше). Але мені не дозволили організатори.

І стратегічно це правильно: інакше не буде шоу, хакери будуть нити, розповідаючи, що це все нечесно, що організатори дали колосальну перевагу захисникам і соків. Не буде уприскування потрібної інформації в ЗМІ, керівництва промислових підприємств будуть відмахуватися від захисту. Пожертвував пішака (SOC і захисники SCADA) в цій грі, але отримав стратегічну перевагу на кілька років вперед (майбутні замовлення від бізнесу і держави на забезпечення безпеки). А найголовніше — світ задумався про те, як не дати погані хлопцям залишити людей без світла і з надмірним надлишком води в місті.



Зображення: Xakep.ru

Якщо все так і розвивалося, то найбільше не хотілося б, щоб у зломі ГЕС і затопленні міста звинуватили «захисників» і SOC, обороняли SCADA.

Більш уважні колеги і представники організатора поправили мене, уточнивши, що захисників ГЕС дійсно не зламали. Після злому захисники і SOC дуже точно описали процес злому (тобто, всі бачили, але не робили, бо, все-таки, шоу треба) і хакери це підтвердили. Похачить скаду вийшло тільки після того, як захисники послабили, а потім і зовсім зняли захист. Вранці другого дня, виявляється, оголосили це в голос зі сцени. Мабуть, я після безсонної ночі не особливо був в змозі сприймати те, що там віщається.

Але, тим не менш, через кілька днів я бачу в Інтернеті інформацію про те, що ГЕС не захистили, а про те, що її зламали. І з часом з цієї плутану фрази залишиться очевидним тільки те, що ГЕС можна зламати. Продовжуючи логіку — а значить, її треба захистити. Тобто, тінь на добре ім'я «захисників» і SOC якщо і впала, то дуже швидко розсмокчеться. Напевно, фахівці з піару знають свою справу краще, ніж інженер по захисту інформації (не вистачало ще, щоб було навпаки).

Ось вона, офіційна інформація від організаторів:

Форум наочно показав, що буває з незахищеною критичної інфраструктурою. Фахівці з інформаційної безпеки в силах забезпечити дуже високий рівень захисту без порушення технологічного процесу — але розвернутися так, як на PHDays, їм дають дуже рідко. Після відключення засобів захисту нападники проникли в технологічну мережу АСУ через корпоративну, атакували фізичне устаткування системи, зламали ГЕС, провели скидання води, відключили лінії електропередачі.

Обмеження

На офіційному сайті конференції є досить пафосна цитата:

На цей раз замість звичних змагань CTF, ми влаштовуємо справжні військові дії. Події на майданчику будуть максимально наближені до реальності: на полігоні PHDays VI СityF розгорнеться масштабна емуляція міської інфраструктури.
От щодо виділеного жирним і хотілося б поговорити.

В засобах захисту інформації нас практично не обмежували: який хоч, такий і став, тільки скажи вимоги до виртуалке. Треба відлупцювати вендора на тимчасову ліцензію — кажи, зробимо. Ну, ми і не соромилися.

VMware. На етапі розгортання озвучувалося обмеження: обрані нами для конкурсу рішення щодо забезпечення та моніторингу ІБ повинні бути виртуализируемыми. Апаратні засоби можна було брати тільки переносні, за них організатори відповідальності не несли. В загальному-то не така й велика проблема, тому що віртуалку отримати у вендора на порядок простіше, так і світовий тренд прагне до повсюдної віртуалізації, навіть цілі мережі і датацентри віртуалізуються, роблячи всякі там NFV, SDN і SDDC. Деякі виробники примудрялися і щодо виртуалки погундосять, а один навіть відмовився надати. Не був готовий до таких серйозних стосунків з хакерськими атаками.

Default permit. З іншого боку, було заборонено виконувати default deny на прикордонному firewall. А в реальному світі так робиться в першу чергу. Це мене обурило до глибини душі, я плакав і матюкався, але продовжував брати участь у конкурсі. Як я вже раніше писав, однією з основних цілей «протистояння» було шоу, яке не вийшло б, заборони я все зайве. Хакери потыкались б у засекуренные інтерфейси, нічого не зробили б, і обхаяли організаторів в потуранні світлій стороні сили. Так що тут наближення до реальності практично нульове. Дали хакерам фору по самі помідори. З-за таких фор і ГЕС поламали, і місто затопили.

No ban for IP-address. Заборонено було також банити за src IP. Природно, якщо б це було просто заборонено словами, то я б міг і «забути», особливо на ніч, щоб спокійніше спалося, та й взагалі щоб спалося. Але хитрі організатори натили всіх в один IP: і хакерів, і свій service-checker. Якщо ми гасили зайве — зверталися до нас і казали, що ай-яй-яй, так не можна. Причому сервіси перевіряли взагалі будь-які, які були спочатку доступні на серверах, навіть на фіг не потрібні. Шоу, чо.

Теж курйоз вийшов на самому початку протистояння: SOC виявив, що нас хтось сканує з IP-адреси, який ніяк не вказано на наданій схемі. Знайшовши точку стику, я заблокував його, вивівши невідому підмережа з маршрутизації, незважаючи на заборону. Точка стику була всередині довіреної сегменту, тому логіка проста: на схемі немає — вважаю за закладку і підступи хакерів, які повинні бути видавлені з нашої мережі. Природно, спочатку прибігли організатори з криком: «Все пропало! Наше все не працює!». Потім зрозуміли, що не пересобрали стик з нашим сегментом, і погодилися з моїми діями.

Доступ до обладнання. Нам, звичайно, надали админский доступ до мережевих пристроїв, і до серверів. Адже важко захищати те, що не можеш налаштувати. Можливо, але складно. До активного мережного обладнання рівня L2-access доступу не дали. Причина проста: шоу. Коли організатори помічали смуток на хакерських физиономиях і нудьгу на наших — піднімали десь без попередження ще один вразливий сервіс. Ну а SOC з захисниками, відповідно, починають: «лови його, дави його!». Щоб ми не заважали зайвими секурити-настройками і не бачили зайвого, доступ до свичам доступу нам не давали і як об'єкт захисту їх нам не вручали.

Начебто нічого не забув. Якщо згадаю — допишу. Загалом, обмеження хоч і були, але не люті. Звичайно, default permit досі розбурхує мою потривожене світогляд, про що я періодично продовжую бурчати в розмовах з організаторами, але шоу є шоу. Це був реслінг, а не MMA.

Битва

Варто приступити до опису самого процесу протистояння — так сказати, битви, яка тривала 29 годин — з 11:00 17 травня 2016-16:00 18 травня 2016.

Попередньо командами захисту та оперативного реагування було проведено:

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

Схема мережі (спрощена, без філіального офісу) була приблизно такою:



Інтернет був псевдо-, а не справжній, хакери потрапляли в нього з обмеженого сегменту. Будь Інтернет справжнім, не можна було б зрозуміти, де атака учасника змагань, а де сторонній хакер, та й гарантії, що хтось не психанет і не почне DDoS, не було.

Першим ділом я вирішив засекурить периметр, тобто, навісити на вліт з боку Інтернету ACL, який дозволяв би виявлені сканом порти серверів DMZ, крім керуючих (SSH/TELNET/RDP/SNMP) і баз даних (MySQL, Oracle), а решта закрити за принципом default deny. Попередив організаторів, і відразу отримав відмову: не можна, всі порти з псевдоинтернета повинні бути доступні. Описати мою реакцію можна двома словами «здивувався» і «обурився», які виражаються одним словом разом.



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

  • патчити діряві сервера в DMZ;
  • навісили ACL на сервера в підмережах Servers1 і Servers2, дозволивши до них доступ з DMZ і адмінів (організатори);
  • перенесли сканер безпеки, розгорнутий спочатку в DMZ, в підмережа Defense_servers — не вистачало ще, щоб сканер похачили;
  • до серверів в підмережі Defense_servers заборонили доступ звідусіль.
Як я вже згадував у першої частини, з нами в тандемі працював JSOC, який інтегрував інфраструктуру зі своїм SIEM і моніторив підозрілу активність. Варто віддати належне хлопцям, вони мало того, що взяли під ковпак будь чих (процеси, входи, мережева активність) інфраструктури, так ще і моніторили c екстрасенсорної оперативністю. Спочатку, поки не вивчили IP-адреси один одного, менше ніж через хвилину після дії ми чули від них запитання: «хто зайшов на сервер ххх з адреси ууу?», «на сервері змінився sshd — це що?» і т. п… Ну і відповідали їм типу: «нормально, свої, це я, оновив дірявий сервак». Якщо вони так само і комерційних клієнтів моніторять, то оплески, рекомендую.

Періодично, коли організаторам ставало сумно і закінчувалися теми для розповіді на сцені, хакерам — понуро, а нам — нудно, Михайло Левін клацав пальцями — і в DMZ з'являвся дірявий сервак. Клацав не над нашими вухами, тому ми виявляли цю справу самі, і далі починали думати, що за сервак, скані, патчити, змінювати легкі паролі. Прямо як розпорядник Голодних ігор в однойменній сазі про Зойке-Пересменщице, де випускалося щось протиприродне, якщо трибуты довго не вмирали.



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

Тільки на самому початку, як я вже писав в четвертої частини, зафіксували скан з ділянки мережі, не показаного на схемі. А моя логіка як мережевого безпечника проста: раз на схемі мережі ділянки не було — значить, непорядок. Мало чи, може, за умовами змагань у нас в мережі була закладка, яку потрібно знайти і знешкодити. Тому я, швидко виявивши статичний маршрут на проблемну підмережа в бік невідомого девайса, спочатку навісив ACL на інтерфейсах. Заблокували його — і відразу організатори показали, що у них все пропало і треба повернути. Після недовгої суперечки прийшли до висновку, що це вже перебір. Хочете скані нас і перевіряти доступність сервісів — стыкуйтесь з боку псевдоинтернета і звідти хоч безперервно творіть неподобства. У підсумку стик пересобрали, проблемну мережа я з маршрутизації вивів.

Ближче до вечора першого дня виявилося, що хакерам не сказали ту мережу, вони в більшості своїй сканили щось неіснуюче та порядком зажурилися. Тоді ми зрозуміли, що тепер якраз і почнеться самий смак. Крім того, чим далі, тим більше і частіше почали підніматися діряві сервера, і до ночі наш DMZ почав ставати схожим на друшляк. Сервера злітали як юниксовые, так і віндовий. Результати сканів нових серверів показували уразливості, в основному PHP, OpenSSL і SSH. Власне, роботи на ніч нам насипали, щоб не нудно було. Та ще постійний ризик, що темна сторона сили швидше виявить ці дірки, нас міцно підстьобувала. Загалом, поспати нам так і не дали. З ночівлею на змаганнях був SOC всім складом, крім їх боса, і троє від захисників. Хлопці примудрилися трохи поспати, а мені, мабуть, страх бути похаченным заважав, тому я весь час щось робив: чи то по роботі, то змагань.

PHP, наскільки я пам'ятаю, був 5.3.<чегототам> 5.4.<чегототам> ще волохатих 2013-2014 років. Доводилося оновлювати, тому що хакери першим ділом будуть ламати веб. Відразу до свіжачка не оновлювалося, доводилося через терни по кроках мінорних версій топати.

SSH практично скрізь був вразливий по CVE-2015-5600, що означало відсутність захисту від перебору паролів і перевантаження CPU. Прям як на замовлення підібрали. Найцікавіше, що не у всіх репозиторіях були пропатчені на цей випадок оновлення, потрібно було оновлювати з исходников. Схожа ситуація і з OpenSSL. Якщо з останнім нікуди не дінешся, доводилося врукопашну працювати, та й менше їх було на порядок, то з SSH я дико возленился робити одне і те ж на всіх серверах DMZ. І в ході нічних роздумів мені прийшла ідея загорнути весь SSH і RDP, який прилітає на сервера DMZ з псевдоинтернета, через Balabit SCB, який я поставив, думаючи, що зможу прозоро загорнути через нього керуючі протоколи для контролю. Досі дивуюся, як мені прийшла ця ідея, але вона виявилася дуже результативною. Підсумкова архітектура, незважаючи на її певну комплексність і складність в тиражуванні на великі інфраструктури, на змаганнях нас практично врятувала від атак на SSH.

Незважаючи на те, що Balabit використовується як засіб контролю керуючих сесій, а також додатково може виступати в ролі інтеграційної прошарку при управлінні погано/частково/ніяк інтегрованими мережами, вночі з 17 на 18 травня ключовим чинником його застосування виявилася невразливість проксирующего модуля zorp-ssh до CVE-2015-5600.

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

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

Загалом, 18 травня у нас пройшло досить інтенсивно. Добре, що вдень нас більше, можна розпаралелити завдання і хоча б швидко пообідати. Справедливості заради скажу, що один із дірявих веб-серверів, які виросли на другий день, темна сила таки встигла похачить через веб, отримавши єдиний «прапор» з нашого тандему. Сервер ніяк не був пов'язаний з телекомовским бізнесом і позначилася на нас лише у вигляді галочки про знятому прапор. Виявив його JSOC через 5 хвилин, причину ми діагностували моментально, після чого активували блокуючу сигнатуру на IPS (була по дефолту в режимі моніторингу і верещала алерт) і пропатчили сервер.

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



В 16:00 змагання закінчувалися, і за кілька хвилин до цього вся мережева інфраструктура, яка живе на виртуалках, не витримала такого тривалого наруги і почала дико давати збої. Це був не хак, бо мережеве обладнання ми попередньо захистили в першу чергу.

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

Нестандартний метод захисту SSH

— Чому нам не можна перенастроювати мережеве обладнання, якщо ми його повинні захищати? Без цього ніяк.
— А, ви телеком-захисники. Тоді вам можна, але сервіси повинні бути доступні і щоб не губилося управління. Інакше ми підійдемо до вас і запитаємо: «Що за справи?». Якщо не зможете швидко полагодити — повернемо до налаштувань до початку змагань, а виставимо вам штрафні бали. Тому зі зміною налаштувань будьте акуратні.
— Це не проблема. А якщо для забезпечення безпеки нам потрібно буде розгорнути трафік по-іншому, зав'язати вузлом, але при цьому все буде працювати?
— Тоді ми прийдемо до вас з папірцем — записати, що і як ви робили, адже цікаво.

— А навіщо ти на Positive Hack Days вирішив Balabit використовувати? Чим він там допоможе?
— Будемо адмінів моніторити. Вони обіцяли періодично на серверах зводити діряві сервіси.
— Ну, як знаєш.
Це два реальних розмови при підготовці до PHDays. До певного моменту я сам не думав, що вони будуть настільки щільно взаємопов'язані. Природно, після розмови з організаторами я думав, що треба б і здивувати, раз погрожував. По ходу змагань вектор настрою потихеньку зрушився від початкового бажання в бік «забетонироваться». Але дивним чином вийшло так, що в підсумку вони злилися. І про це піде розповідь.

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

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



Але, як згадувалося в частини 4 і частини 5, використовувати ACL на firewall з правилом default deny нам не дозволили організатори. Тому спочатку псевдоинтернета трафік йшов до серверів DMZ по всіх протоколів і портів. Але зараз мова піде про SSH.

Сервери, які нам поставили в DMZ, практично всі були вразливі до CVE-2015-5600, що означало відсутність захисту від перебору паролів і перевантаження CPU. Поєднуємо ці 2 умови — і отримуємо ідеальну для хакерів ситуацію: «Не підберу — так хоч завалю». При цьому, починаючи з вечора першого дня, сервера з'являлися, як таргани в гуртожитку. SSH був дірявий скрізь. Оновлення, що містять фікс до зазначеної уразливості, були далеко не у всіх архівів. Тобто, зайти одноразово на всі лінукса різних версій і втоптати пару команд, щоб надалі воно само — не варіант. Тільки сырцы, тільки хардкор. Лінь — двигун прогресу. Можливо, людина, щільніше в повсякденному житті працює з Open Source рішеннями і Unix, пішов би в бік реалізації свого репозитарію або ще як, але в мене в 3 години ночі прокинувся архітектор.

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

Налаштувавши пару проксирующих правил на Balabit, я просканував його. Модуль перекидання SSH zorp-ssh виявився невразливим до CVE-2015-5600, так само як і до інших, відомим на той день сканера MaxPatrol, вразливостей. Тепер залишилося придумати, як розділити трафік таким чином, щоб SSH до серверів в DMZ балабитизировался, а інші протоколи йшли своїм звичайним шляхом.

Розглянемо на прикладі SSH, але таким же чином можна вчинити і з RDP, і з Telnet, і з VNC, і з ICA (правда, трохи попотіти).

За задумом, реалізованої в схемі мережі, до серверів з DMZ хакери потрапляли по всіх протоколів і портів, проходячи через прикордонний firewall.



Оскільки як прикордонний firewall використовувався не ACL на роутері, а CheckPoint, стандартні для firewall фічі типу NAT можна було налаштовувати на всю міць. Як брандмауер, що захищає сервера «ЦОД» — Cisco ASAv.
Щоб не заплутати в мережевих терминологиях і реалізації NAT двох різних виробників, опишу вендорнезависимую концепцію, яка застосовується на обладнанні будь-яких виробників, які підтримують таку технологію.

Для завороту трафіку SSH на Balabit можна піти такими шляхами:

1. Виділені порти для серверів.
  • Виділити діапазон портів на Balabit.
  • Реалізувати динамічний NAT many-to-one на прикордонному CheckPoint таким чином, щоб пакети, що прилітають з псевдоинтернета в напрямку серверів DMZ на порт SSH, транслювалися в пакет, де src ip підміняється на IP CheckPoint, dst ip — IP Balabit, dst port — на виділений для цього сервера, порт на Balabit.




  • Відкрити доступ для цих TCP-сесій на вхід у Firewall ЦОД:


  • Налаштувати правила проксі серверів на Balabit з поверненням на потрібний сервер, порт 22 (SSH):


  • Дозволити вихід таких пакетів з Balabit в бік DMZ на обох firewall:


Готове. SSH-сесія функціонально не порушена, інший трафік не зачеплений, умови гри дотримані.

2. Виділений пул адрес.
  • Виділити в ЦОД підмережа тієї ж розмірності, що і DMZ.
  • Помістити в неї інтерфейс Balabit, що приймає трафік.
  • Налаштувати маршрутизацію.
  • Сконфігурувати Balabit з IP-адресами тій же підмережі.
  • Реалізувати статичний NAT one-to-one на прикордонному firewall:


Можна, звичайно, і не ховати SRC IP адресу за CheckPoint, але тоді необхідно, щоб DMZ будувався на сірих адреси. На «протистоянні» DMZ будували на «білих»…

  • Дозволити вхідний трафік на Firewall ЦОД:


  • Налаштувати правила проксі серверів на Balabit:


  • і дозвіл на обох firewall:


де Balabit_ip0 — адреса Balabit, сконфігурований на інтерфейсі як основний, а не IP alias (Balabit_ip1...4). Можна, звичайно, налаштувати так, щоб src ip був Balabit_ip1...4, але в ситуації на PHDays це було зайвим.

Готове. SSH-сесія функціонально не порушена, інший трафік не зачеплений, умови гри дотримані.

***

В обох випадках, щоб мати можливість пускати певні підмережі на сервера DMZ повз Balabit, необхідно на прикордонному firewall перед описаними правилами поставити таке:



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



Видно, що подібне рішення трохи напружує при масштабуванні його на велику кількість серверів. Не можна зробити «налаштував і забув» для всієї підмережі одним рядком. Додаткові витрати часу викликає необхідність:

  • У випадку 1 — додавання правила для кожного нового сервера DMZ і на Balabit, і на firewall.
  • У випадку 2 — розробка мережевого дизайну і настроювання мережі (одноразово), а також додавання нового правила на Balabit для кожного сервера DMZ.
Тобто, в обох випадках — налаштовувати Balabit для кожного сервера. Завдання, по суті, не громіздка, займає 5-10 хвилин, і при статичності життя сервера цілком терпима, але якщо все часто тече і змінюється…

Обидва ці обмеження пов'язані з тим, що мережа з точки зору L3 була плоскою, з однією таблицею маршрутизації. Є рішення, яке допомогло б прозоро балабитизировать всю підмережу одним махом, а там хоч кожну секунду додавайте-видаляйте сервера в мережі. Але для цього буде потрібно одноразово налаштувати MPLS L3VPN або vrf lite на активному мережному устаткуванні (якщо підтримує) і акуратно з'єднати з його допомогою Balabit і прикордонний firewall.
Але це вже тема для зовсім окремої статті…

Бачу німе питання в очах читачів: а як же ти налаштував на PHDays?
Відповідь: по варіанту №1 – виділені порти.

Висновки

Отже, описавши в шести частинах наша участь у протистоянні, непогано було б зробити висновки за результатами змагань. Незважаючи на те, що нас не перемогли, я зрозумів, що нам ще є куди рости як захисникам. Протистояння дало можливість попрацювати в вважаються нереальними умовах абсолютного админского косяка: default permit на прикордонному firewall і неконтрольоване поява дірявих серверів в DMZ. Як деякий підсумок, для перевірки ступеня захищеності інфраструктури необхідний певний checklist, з яким потрібно звірятися.

Щоб не розпорошуватися на велику кількість слів і фраз, я візьму за основу SANS Top 20 Critical Security Controls, в якому описані точки контролю ІБ. Вони застосовні як до змагань, так і до реального життя. В табличці спробую кілька розмежувати зони відповідальності захисників (DEF) і SOC, незважаючи на те, що найчастіше вони щільно переплітаються.

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

Control name DEF SOC
1 Inventory
of Authorized and Unauthorized Devices
+ +
2 Inventory,of Authorized and Unauthorized Software + +
3 Secure
Configurations for Hardware and Software on Mobile Device Laptops,
Workstations, and Servers
+ +
4 Continuous
Vulnerability Assessment and Remediation
+ +
5 Controlled
Use of Administrative Privileges
+ +
6 Maintenance,
Monitoring, Analysis and of Audit Logs
+
7 Email
and Web Browser Protections
+
8 Malware
Defenses
+ +
9 Limitation
and Control of Network Ports, Protocols, and Services
+
10 Data
Recovery Capability
11 Secure
Configurations for Network Devices such as Firewall Routers, and Switches
+
12 Boundary
Defense
+
13 Data
Protection
+ +
14 Controlled
Access Based on the Need to Know
+ +
15 Wireless
Access Control
16 Account
Monitoring and Control
+
17 Security
Skills Assessment and Appropriate Training to Fill Gaps
+ +
18 Application
Software Security
+
19 Incident
Response and Management
+
20 Penetration
Tests and Red Team Exercises
+ +
Крім висновків, звичайно, варто визначити допущені нами помилки і подальшу стратегію захисту в майбутніх «протистояння». Думаю, змагання подібного формату будуть досить популярні тепер.

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

1.
2.
3.

Щоб уникнути подібних помилок я бачу такий перелік дій на майбутнє:

1.
2.
3.

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

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

P. S. Агрегировав весь свій потік підсвідомості за результатами участі у змаганнях PHDays «Протистояння», я перевів його на більш-менш офіційна мова і описав змістове наповнення в одній статті для журналу «Системний адміністратор». З текстом статті можна ознайомитися в червневому випуску посилання.

Автор: Андрій Дугін
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.