Наш центр кіберзахисту відповідає за безпеку веб-інфраструктури клієнтів та відбиває атаки на клієнтські сайти. Для захисту від атак ми використовуємо файрволи веб-програм FortiWeb (WAF). Але навіть найкрутіший WAF - не панацея і не захищає "з коробки" від цільових атак.
Тому на додаток до WAF ми використовуємо . Він допомагає збирати всі події в одному місці, накопичує статистику, візуалізує її та дозволяє нам вчасно бачити спрямовану атаку.
Сьогодні розповім докладніше, як ми схрестили ялинку з WAF і що з цього вийшло.
Історія однієї атаки: як усе працювало до переходу на ELK
У нашій хмарі у замовника розгорнуто програму, яка стоїть за нашим WAF. На день до сайту підключалися від 10 000 до 100 000 користувачів, кількість підключень доходила до 20 млн. на день. З них 3-5 користувачів були зловмисниками та намагалися зламати сайт.
Звичайний брутфорс форми з однієї IP-адреси FortiWeb блокував досить легко. Кількість звернень до сайту за хвилину була більшою, ніж у легітимних користувачів. Ми просто налаштовували пороги активності з однієї адреси та відбивали атаку.
Набагато складніше боротися з «повільними атаками», коли зловмисники діють не поспішаючи і маскуються під звичайних клієнтів. Вони використовують багато унікальних IP-адрес. Така активність не виглядала для WAF як масовий брутфорс, відстежити її автоматично було складніше. А ще був ризик заблокувати звичайних користувачів. Ми шукали інші ознаки атаки та налаштовували політику автоматичного блокування IP-адрес за цією ознакою. Наприклад, у багатьох нелегітимних сесій виявлялися спільні поля у заголовках http-запиту. Шукати такі поля часто доводилося вручну у журналах подій FortiWeb.
Виходило довго і незручно. У стандартній функціональності FortiWeb події записуються текстом у 3 різних журнали: виявлені атаки, інформація про запити та системні повідомлення про роботу WAF. За хвилину можуть приходити десятки, а то й сотні подій про атаки.
Не так вже й багато, але доводиться вручну лазити кількома журналами і перебирати багато рядків:
У журналі атак бачимо адреси користувачів та характер активності.
Недостатньо просто сканувати таблицю журналу. Щоб знайти найцікавіше і найкорисніше про характер атаки, потрібно заглянути всередину конкретної події:
Виділені поля допомагають виявити «повільну атаку». Джерело: скрін з .
Ну і найголовніша проблема – розібратися в цьому може лише фахівець із FortiWeb. Якщо в робочий час ми ще могли відстежувати підозрілу активність у реальному часі, розслідування нічних інцидентів могло затягтися. Коли політики FortiWeb з якоїсь причини не спрацьовували, чергові інженери нічної зміни не могли оцінити ситуацію без доступу до WAF і будили фахівця FortiWeb. Ми переглядали журнали за кілька годин та знаходили момент атаки.
З такими обсягами інформації складно зрозуміти загальну картину з першого погляду та діяти на випередження. Тоді ми вирішили збирати дані в одному місці, щоб аналізувати все у наочному вигляді, знаходити початок атаки, виявляти її напрямок та метод блокування.
З чого вибирали
Насамперед ми дивилися на рішення, які вже використовуються, щоб не множити сутності без необхідності.
Одним із перших варіантів був Нагіос, який ми використовуємо для моніторингу , , оповіщення про позаштатні ситуації. Безпеки також її використовують для оповіщень чергових при підозрілому трафіку, але вона не вміє збирати розрізнені журнали і тому відпадає.
Був варіант агрегувати все за допомогою MySQL та PostgreSQL чи іншої реляційної бази. Але щоб витягувати дані, потрібно було ліпити свою програму.
Як колектор логів у нашій компанії також використовують FortiAnalyzer від Fortinet. Але в цьому кейсі він також не підійшов. По-перше, він більше заточений для роботи з міжмережевим екраном FortiGate. По-друге, не вистачало багатьох налаштувань, а взаємодія з ним вимагала відмінного знання SQL-запитів. Ну і, по-третє, його використання збільшило б вартість сервісу для замовника.
Ось так ми й прийшли до опенсорсу в особі ELK.
Чому вибрали ELK
ELK – це комплекс програм з відкритим кодом:
- Elasticsearch – база даних тимчасових рядів, яка створювалася для роботи з великими обсягами тексту;
- Логсташ – механізм збору даних, який може конвертувати журнали у потрібний формат;
- Кібана - Хороший візуалізатор, а також досить доброзичливий інтерфейс для управління Elasticsearch. Можна з його допомогою збудувати графіки, за якими можуть спостерігати чергові інженери ночами.
Поріг входу до ELK невисокий. Усі основні можливості безкоштовні. Що ще потрібне для щастя.
Як зібрали це все в єдину систему
Сформували індекси та залишили тільки потрібну інформацію. Ми завантажили всі три журнали FortiWEB у ELK – на виході вийшли індекси. Це файли з усіма зібраними журналами за період, наприклад добу. Якби ми одразу їх візуалізували, то побачили б лише динаміку атак. За подробицями потрібно «провалюватися» у кожну атаку та дивитися конкретні поля.
Ми зрозуміли, що для початку потрібно налаштувати розбір неструктурованої інформації. Взяли довгі поля у вигляді рядків, наприклад, Message та URL, і розпарили їх, щоб отримати більше інформації для прийняття рішень.
Наприклад, за допомогою парсингу ми винесли окреме розташування користувача. Це допомогло одразу виділити атаки з-за кордону на сайти для російських користувачів. Блокуючи всі підключення з інших країн, ми зменшили кількість атак вдвічі і могли спокійно розбиратися з атаками всередині Росії.
Після парсингу почали шукати, яку інформацію зберігати та візуалізувати. Залишати у журналі все було недоцільно: розмір одного індексу був більшим – 7 Гб. ELK потрібно багато часу для обробки файлу. При цьому не вся інформація була корисною. Щось дублювалося та займало зайве місце – треба було оптимізувати.
Спочатку ми просто переглядали індекс та видаляли непотрібні події. Це виявилося ще незручнішим і довшим, ніж робота з журналами на самому FortiWeb. Єдиний плюс від «ялинки» на цьому етапі ми змогли візуалізувати великий проміжок часу на одному екрані.
Ми не впадали у відчай, продовжували їсти кактус вивчати ELK і вірили, що зуміємо витягнути необхідну інформацію. Після очищення індексів почали візуалізувати що є. Так ми прийшли до великих дашбордів. Понатикали віджетів - наочно і ошатно, справжня ЁLKа!
Зафіксували момент атаки. Тепер треба було зрозуміти, як на графіку виглядає початок атаки. Для виявлення ми дивилися на відповіді сервера користувачеві (return codes). Нас цікавили відповіді сервера з такими кодами (rc):
Код (rc)
Назва
Опис
0
DROP
Запит на сервер блокується
200
Ok
Запит успішно оброблений
400
Неправильний запит
Помилковий запит
403
Заборонений
Відмова авторизації
500
Внутрішня помилка сервера
Сервіс недоступний
Якщо хтось починав атакувати сайт, змінювалося співвідношення кодів:
- Якщо помилкових запитів із кодом 400 ставало більше, а нормальних запитів із кодом 200 залишалося стільки ж, то хтось намагався зламати сайт.
- Якщо при цьому запити з кодом 0 теж зростали, то політики FortiWeb теж «бачили» атаку і застосовували до неї блокування.
- Якщо збільшувалася кількість повідомлень з кодом 500, то сайт недоступний для цих IP-адрес – теж свого роду блокування.
На третій місяць ми налаштували дашборд для відстеження такої активності.
Щоб не моніторити все вручну, налаштували інтеграцію з Nagios, котрий із певною періодичністю опитував ELK. Якщо фіксував досягнення порогових значень за кодами, надсилав повідомлення черговим про підозрілу активність.
Поєднали 4 графіки в системі моніторингу. Тепер було важливо побачити на графіках момент, коли атака не блокується і потрібне втручання інженера. На 4 різних графіках наше око замилювалося. Тому ми поєднали графіки і стали спостерігати за всім на одному екрані.
На моніторингу ми стежили, як змінюються графіки різних кольорів. Сплеск червоного кольору показував, що атака почалася, а помаранчевий та синій графіки демонстрували реакцію FortiWeb:
Тут все добре: був сплеск «червоної» активності, але FortiWeb упорався і графік атаки зійшов нанівець.
Також ми намалювали для себе приклад графіка, який потребує втручання:
Ми бачимо, що FortiWeb підвищив активність, але червоний графік атаки не знизився. Потрібно змінити налаштування WAF.
Розслідувати нічні інциденти також стало простіше. На графіку відразу видно момент, коли настав час прийти на захист сайту.
Ось що іноді відбувається вночі. Червоний графік – розпочалася атака. Синій – активність FortiWeb. Атака заблокувалась не до кінця, довелося втрутитися.
Куди прагнемо
Наразі ми навчаємо чергових адміністраторів працювати з ELK. Чергові вчаться оцінювати ситуацію на дашборді і приймають рішення: настав час ескалювати на фахівця з FortiWeb, або політик на WAF вистачить для автоматичного відображення атаки. Так ми знижуємо навантаження на інженерів ІБ ночами та ділимо ролі у підтримці на рівні систем. Доступ до FortiWeb залишається лише у центру кіберзахисту, і тільки вони вносять зміни до налаштувань WAF за необхідності.
Також ми працюємо над звітністю для замовників. Плануємо, що дані про динаміку роботи WAF будуть доступні в особистому кабінеті клієнта. ELK зробить ситуацію прозорішою без необхідності звертатися до WAF.
Якщо замовник захоче сам спостерігати за своїм захистом у реальному часі, ELK теж знадобиться. Доступ до WAF ми не можемо віддати, оскільки втручання замовника в роботу може вплинути на інших. А ось підняти окремий ELK і віддати погратися можна.
Ось такі сценарії використання ялинки у нас накопичилися останнім часом. Діліться своїми ідеями щодо цього і не забувайте , щоб уникнути витоків із баз даних.
Джерело: habr.com