Наш цэнтр кіберабароны адказвае за бяспеку вэб-інфраструктуры кліентаў і адбівае напады на кліенцкія сайты. Для абароны ад нападаў мы выкарыстоўваем файрвалы вэб-прыкладанняў 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. Мы праглядалі часопісы за некалькі гадзін і знаходзілі момант нападу.
З такімі аб'ёмамі інфармацыі складана зразумець агульную карціну з першага позірку і дзейнічаць на апярэджанне. Тады мы вырашылі збіраць дадзеныя ў адным месцы, каб аналізаваць усё ў наглядным выглядзе, знаходзіць пачатак нападу, выяўляць яе кірунак і метад блакавання.
З чаго выбіралі
У першую чаргу мы глядзелі на ўжо выкарыстоўваныя рашэнні, каб не памнажаць сутнасці без неабходнасці.
Адным з першых варыянтаў быў Nagios, які мы выкарыстоўваем для маніторынгу , , абвесткі аб няштатных сітуацыях. Бяспекі таксама яе выкарыстоўваюць для абвестак дзяжурных пры падазроным трафіку, але яна не ўмее збіраць разрозненыя часопісы і таму адпадае.
Быў варыянт агрэгаваць усё з дапамогай MySQL і PostgreSQL ці іншай рэляцыйнай базы. Але, каб выцягваць дадзеныя, трэба было ляпіць сваё прыкладанне.
У якасці калектара логаў у нашай кампаніі таксама выкарыстоўваюць FortiAnalyzer ад Fortinet. Але ў гэтым кейсе ён таксама не падышоў. Па-першае, ён больш заменчаны для працы з міжсеткавым экранам. FortiGate. Па-другое, бракавала шматлікіх налад, а ўзаемадзеянне з ім патрабавала хвацкіх ведаў SQL-запытаў. Ну і па-трэцяе, яго выкарыстанне павялічыла б кошт сэрвісу для замоўца.
Вось так мы і дашлі да апенсорсу ў асобе ELK.
Чаму выбралі ELK
ELK - гэта комплекс праграм з адкрытым кодам:
- Elasticsearch – база дадзеных часовых шэрагаў, якая якраз стваралася для працы з вялікімі аб'ёмамі тэксту;
- Logstash – механізм збору дадзеных, які можа канвертаваць часопісы ў патрэбны фармат;
- Kibana – добры візуалізатар, а таксама дастаткова прыязны інтэрфейс для кіравання Elasticsearch. Можна з яго дапамогай збудаваць графікі, за якімі могуць назіраць дзяжурныя інжынеры па начах.
Парог уваходу ў ELK невысокі. Усе асноўныя магчымасці бясплатныя. Што яшчэ патрэбна для шчасця.
Як сабралі гэта ўсё ў адзіную сістэму
Сфарміравалі індэксы і пакінулі толькі патрэбную інфармацыю. Мы загрузілі ўсе тры часопісы FortiWEB у ELK - на выхадзе атрымаліся індэксы. Гэта файлы са ўсімі сабранымі часопісамі за перыяд, напрыклад, суткі. Калі б мы адразу іх візуалізавалі, то ўбачылі б толькі дынаміку нападаў. За падрабязнасцямі трэба "правальвацца" ў кожны напад і глядзець канкрэтныя палі.
Мы зразумелі, што для пачатку трэба наладзіць разбор неструктураванай інфармацыі. Узялі доўгія палі ў выглядзе радкоў, напрыклад, "Message" і "URL", і распарсілі іх, каб атрымаць больш інфармацыі для прыняцця рашэнняў.
Напрыклад, з дапамогай парсінгу мы вынеслі асобна месцазнаходжанне карыстальніка. Гэта дапамагло адразу вылучыць напады з-за мяжы на сайты для расейскіх карыстальнікаў. Блакуючы ўсе падлучэнні з іншых краін, мы паменшылі колькасць нападаў у 2 разу і маглі спакойна разбірацца з нападамі ўсярэдзіне Расіі.
Пасля парсінгу пачалі шукаць, якую інфармацыю захоўваць і візуалізаваць. Пакідаць у часопісе ўсё было немэтазгодна: памер аднаго індэкса быў вялікім - 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