Ang aming cyber defense center ay responsable para sa seguridad ng imprastraktura sa web ng kliyente at tinataboy ang mga pag-atake sa mga site ng kliyente. Upang maprotektahan laban sa mga pag-atake, ginagamit namin ang FortiWeb Web Application Firewalls (WAFs). Ngunit kahit na ang pinaka-cool na WAF ay hindi isang panlunas sa lahat at hindi pinoprotektahan ang "out of the box" mula sa mga naka-target na pag-atake.
Samakatuwid, bilang karagdagan sa WAF, ginagamit namin . Nakakatulong ito upang kolektahin ang lahat ng mga kaganapan sa isang lugar, mag-ipon ng mga istatistika, mailarawan ito at nagbibigay-daan sa amin upang makita ang isang naka-target na pag-atake sa oras.
Ngayon sasabihin ko sa iyo nang mas detalyado kung paano namin tinawid ang Christmas tree na may WAF at kung ano ang nagmula rito.
Ang kwento ng isang pag-atake: kung paano gumana ang lahat bago lumipat sa ELK
Sa aming cloud, na-deploy ng customer ang application sa likod ng aming WAF. Mula sa 10 hanggang 000 mga gumagamit na konektado sa site bawat araw, ang bilang ng mga koneksyon ay umabot sa 100 milyon bawat araw. Sa mga ito, 000-20 user ang nanghihimasok at sinubukang i-hack ang site.
Ang karaniwang anyo ng brute force mula sa isang IP address ay na-block ng FortiWeb nang madali. Ang bilang ng mga hit sa site bawat minuto ay mas mataas kaysa sa mga lehitimong user. Nag-set up lang kami ng mga threshold ng aktibidad mula sa isang address at tinanggihan ang pag-atake.
Mas mahirap harapin ang "mabagal na pag-atake", kapag ang mga umaatake ay kumilos nang mabagal at nagkukunwaring mga ordinaryong kliyente. Gumagamit sila ng maraming natatanging IP address. Ang ganitong aktibidad ay hindi mukhang napakalaking brute force sa WAF, mas mahirap itong awtomatikong subaybayan. At nagkaroon din ng panganib na harangan ang mga normal na gumagamit. Naghanap kami ng iba pang senyales ng pag-atake at nag-set up ng patakaran para sa awtomatikong pagharang sa mga IP address batay sa sign na ito. Halimbawa, maraming mga hindi lehitimong session ang may mga karaniwang field sa mga header ng kahilingan sa http. Kadalasan kailangan mong maghanap ng mga ganoong field nang manu-mano sa mga log ng kaganapan ng FortiWeb.
Nagtagal ito at hindi komportable. Sa karaniwang functionality ng FortiWeb, ang mga kaganapan ay naitala sa teksto sa 3 magkakaibang mga log: mga natukoy na pag-atake, impormasyon tungkol sa mga kahilingan, at mga mensahe ng system tungkol sa pagpapatakbo ng WAF. Dose-dosenang o kahit daan-daang mga kaganapan sa pag-atake ang maaaring dumating sa isang minuto.
Hindi gaanong, ngunit kailangan mong manu-manong umakyat sa ilang mga log at umulit sa maraming linya:
Sa log ng pag-atake, nakikita namin ang mga address ng user at ang katangian ng aktibidad.
Hindi sapat na i-scan lamang ang log table. Upang mahanap ang pinakakawili-wili at kapaki-pakinabang tungkol sa likas na katangian ng pag-atake, kailangan mong tumingin sa loob ng isang partikular na kaganapan:
Nakakatulong ang mga naka-highlight na field na makita ang "mabagal na pag-atake". Pinagmulan: screenshot mula sa .
Well, ang pangunahing problema ay ang isang FortiWeb na espesyalista lamang ang makakaalam nito. Kung sa mga oras ng negosyo masusubaybayan pa rin namin ang kahina-hinalang aktibidad sa real time, maaaring maantala ang pagsisiyasat ng mga insidente sa gabi. Nang hindi gumana ang mga patakaran ng FortiWeb sa ilang kadahilanan, hindi ma-assess ng mga night shift engineer na naka-duty ang sitwasyon nang walang access sa WAF at ginising ang FortiWeb specialist. Tumingin kami sa mga log ng ilang oras at nakita namin ang sandali ng pag-atake.
Sa ganitong dami ng impormasyon, mahirap maunawaan ang malaking larawan sa isang sulyap at kumilos nang maagap. Pagkatapos ay nagpasya kaming mangolekta ng data sa isang lugar upang pag-aralan ang lahat sa isang visual na anyo, hanapin ang simula ng pag-atake, tukuyin ang direksyon nito at paraan ng pagharang.
Ano ang napili mo
Una sa lahat, tiningnan namin ang mga solusyon na ginagamit na, upang hindi dumami ang mga entity nang hindi kinakailangan.
Ang isa sa mga unang pagpipilian ay Nagiosna ginagamit namin sa pagsubaybay , , mga alertong pang-emergency. Ginagamit din ito ng mga security guard para ipaalam sa mga attendant kung sakaling magkaroon ng kahina-hinalang traffic, ngunit hindi nito alam kung paano mangolekta ng mga nakakalat na troso at samakatuwid ay nawawala.
Nagkaroon ng opsyon para pagsama-samahin ang lahat MySQL at PostgreSQL o ibang relational database. Ngunit upang ma-pull out ang data, ito ay kinakailangan upang sculpt ang iyong aplikasyon.
Bilang isang log collector sa aming kumpanya ay gumagamit din sila FortiAnalyzer mula sa Fortinet. Ngunit sa kasong ito, hindi rin siya nababagay. Una, ito ay mas sharpened upang gumana sa isang firewall FortiGate. Pangalawa, maraming mga setting ang nawawala, at ang pakikipag-ugnayan dito ay nangangailangan ng mahusay na kaalaman sa mga query sa SQL. At pangatlo, ang paggamit nito ay magtataas ng halaga ng serbisyo para sa customer.
Ito ay kung paano kami dumating sa open source sa mukha ELK.
Bakit pinili ang ELK
Ang ELK ay isang hanay ng mga open source na programa:
- Elasticsearch - isang database ng mga serye ng oras, na nilikha lamang upang gumana sa malalaking volume ng teksto;
- Logstash β isang mekanismo ng pagkolekta ng data na maaaring mag-convert ng mga log sa nais na format;
- Kibana - isang mahusay na visualizer, pati na rin ang isang medyo friendly na interface para sa pamamahala ng Elasticsearch. Magagamit mo ito upang bumuo ng mga iskedyul na maaaring masubaybayan ng mga inhinyero sa tungkulin sa gabi.
Mababa ang entry threshold para sa ELK. Ang lahat ng mga pangunahing tampok ay libre. Ano pa ang kailangan para sa kaligayahan.
Paano mo pinagsama ang lahat sa isang sistema?
Lumikha ng mga index at iniwan lamang ang kinakailangang impormasyon. Na-load namin ang lahat ng tatlong FortiWEB log sa ELK - ang output ay mga index. Ito ay mga file na may lahat ng nakolektang log para sa isang panahon, halimbawa, isang araw. Kung na-visualize natin sila kaagad, makikita lang natin ang dynamics ng mga pag-atake. Para sa mga detalye, kailangan mong "sumama" sa bawat pag-atake at tumingin sa mga partikular na field.
Napagtanto namin na kailangan muna naming i-set up ang pag-parse ng hindi nakabalangkas na impormasyon. Kinuha namin ang mahahabang field bilang mga string, gaya ng "Message" at "URL", at na-parse ang mga ito para makakuha ng higit pang impormasyon para sa paggawa ng desisyon.
Halimbawa, gamit ang pag-parse, hiwalay naming kinuha ang lokasyon ng user. Nakatulong ito na agad na i-highlight ang mga pag-atake mula sa ibang bansa sa mga site para sa mga user ng Russia. Sa pamamagitan ng pagharang sa lahat ng koneksyon mula sa ibang mga bansa, binawasan namin ang bilang ng mga pag-atake ng 2 beses at madaling harapin ang mga pag-atake sa loob ng Russia.
Pagkatapos ng pag-parse, nagsimula silang maghanap kung anong impormasyon ang iimbak at i-visualize. Ang pag-iwan ng lahat sa log ay hindi naaangkop: ang laki ng isang index ay malaki - 7 GB. Matagal na naproseso ng ELK ang file. Gayunpaman, hindi lahat ng impormasyon ay naging kapaki-pakinabang. May na-duplicate at kumuha ng dagdag na espasyo - kailangan itong mag-optimize.
Sa una, tiningnan lang namin ang index at inalis ang mga hindi kinakailangang kaganapan. Ito ay naging mas abala at mas mahaba kaysa sa pagtatrabaho sa mga log sa FortiWeb mismo. Ang tanging plus mula sa "Christmas tree" sa yugtong ito ay na-visualize namin ang isang malaking yugto ng panahon sa isang screen.
Hindi kami nawalan ng pag-asa, ipinagpatuloy namin ang pagkain ng cactus at pinag-aralan ang ELK at naniwala na makukuha namin ang kinakailangang impormasyon. Matapos linisin ang mga index, sinimulan naming mailarawan kung ano ang. Kaya nakarating kami sa malalaking dashboard. Sinundot namin ang mga widget - biswal at elegante, isang tunay na ΠLKa!
Nakuha ang sandali ng pag-atake. Ngayon ay kinakailangan upang maunawaan kung ano ang hitsura ng simula ng pag-atake sa tsart. Upang matukoy ito, tiningnan namin ang mga tugon ng server sa user (mga return code). Interesado kami sa mga tugon ng server na may ganitong mga code (rc):
Code (rc)
Pangalan
ΠΠΏΠΈΡΠ°Π½ΠΈΠ΅
0
Ilaglag
Ang kahilingan sa server ay naharang
200
Ok
Matagumpay na naproseso ang kahilingan
400
Masamang Kahilingan
Masamang Kahilingan
403
Ipinagbabawal
Tinanggihan ang awtorisasyon
500
Internal Server Error
Hindi available ang serbisyo
Kung may nagsimulang umatake sa site, nagbago ang ratio ng mga code:
- Kung mayroong higit pang mga maling kahilingan na may code 400, at ang parehong bilang ng mga normal na kahilingan na may code 200, kung gayon may sumusubok na i-hack ang site.
- Kung, sa parehong oras, ang mga kahilingan na may code 0 ay lumago din, kung gayon ang mga politiko ng FortiWeb ay "nakita" din ang pag-atake at inilapat ang mga bloke dito.
- Kung tumaas ang bilang ng mga mensahe na may code 500, hindi magagamit ang site para sa mga IP address na ito - isa ring uri ng pagharang.
Sa ikatlong buwan, nag-set up kami ng dashboard para subaybayan ang aktibidad na ito.
Upang hindi manu-manong masubaybayan ang lahat, nag-set up kami ng integration sa Nagios, na nag-poll sa ELK sa ilang partikular na agwat. Kung naitala nito ang pagkamit ng mga halaga ng threshold sa pamamagitan ng mga code, nagpadala ito ng abiso sa mga opisyal ng tungkulin tungkol sa kahina-hinalang aktibidad.
Pinagsamang 4 na tsart sa sistema ng pagsubaybay. Ngayon ay mahalaga na makita sa mga graph ang sandali kapag ang pag-atake ay hindi naharang at ang interbensyon ng isang inhinyero ay kailangan. Sa 4 na magkakaibang mga graph, ang aming mata ay malabo. Samakatuwid, pinagsama namin ang mga chart at nagsimulang obserbahan ang lahat sa isang screen.
Sa pagsubaybay, napanood namin kung paano nagbabago ang mga graph ng iba't ibang kulay. Ang isang pagsabog ng pula ay nagpapahiwatig na ang pag-atake ay nagsimula, habang ang orange at asul na mga graph ay nagpakita ng reaksyon ng FortiWeb:
Maayos ang lahat dito: nagkaroon ng surge ng "pula" na aktibidad, ngunit nakayanan ng FortiWeb at nauwi sa wala ang iskedyul ng pag-atake.
Gumuhit din kami para sa aming sarili ng isang halimbawa ng isang graph na nangangailangan ng interbensyon:
Dito makikita natin na ang FortiWeb ay tumaas ang aktibidad, ngunit ang pulang graph ng pag-atake ay hindi nabawasan. Kailangan mong baguhin ang mga setting ng WAF.
Naging madali na rin ang pagsisiyasat sa mga pangyayari sa gabi. Ang graph ay agad na nagpapakita ng sandali kung kailan oras na upang ipagtanggol ang site.
Ganyan ang nangyayari minsan sa gabi. Pulang graph - nagsimula na ang pag-atake. Asul - aktibidad ng FortiWeb. Ang pag-atake ay hindi ganap na naharang, kailangan naming mamagitan.
Saan tayo pupunta
Ngayon ay nagsasanay kami ng mga tagapangasiwa ng tungkulin upang makipagtulungan sa ELK. Natututo ang mga attendant na tasahin ang sitwasyon sa dashboard at gumawa ng desisyon: oras na para pumunta sa isang FortiWeb specialist, o sapat na ang mga patakaran sa WAF para awtomatikong maitaboy ang pag-atake. Kaya binabawasan namin ang pagkarga sa mga inhinyero ng seguridad ng impormasyon sa gabi at hinahati ang mga tungkulin sa suporta sa antas ng system. Ang access sa FortiWeb ay nananatili lamang sa cyber defense center, at sila lamang ang gumagawa ng mga pagbabago sa mga setting ng WAF kapag apurahang kailangan.
Nagsusumikap din kami sa pag-uulat para sa mga customer. Plano namin na ang data sa dynamics ng trabaho ng WAF ay magiging available sa personal na account ng kliyente. Gagawin ng ELK na mas malinaw ang sitwasyon nang hindi kinakailangang sumangguni sa WAF mismo.
Kung gusto ng customer na subaybayan ang kanilang sariling proteksyon sa real time, magiging kapaki-pakinabang din ang ELK. Hindi kami makapagbibigay ng access sa WAF, dahil maaaring makaapekto sa iba ang interbensyon ng customer sa trabaho. Ngunit maaari kang pumili ng isang hiwalay na ELK at ibigay ito sa "maglaro sa paligid".
Ito ang mga scenario sa paggamit ng Christmas tree na naipon natin kamakailan. Ibahagi ang iyong mga saloobin tungkol dito at huwag kalimutan upang maiwasan ang pagtagas ng database.
Pinagmulan: www.habr.com