{"id":54536,"date":"2019-12-28T00:00:00","date_gmt":"2019-12-27T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/3-elastic-stack-analiz-security-logov-dashbordy"},"modified":"2020-02-18T14:02:33","modified_gmt":"2020-02-18T11:02:33","slug":"3-elastic-stack-analiz-security-logov-dashbordy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/3-elastic-stack-analiz-security-logov-dashbordy","title":{"rendered":"3. Elastic stack: analyse van security logs. Dashboards","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"3.
\n
\nIn eerdere artikelen hebben we ons een beetje vertrouwd gemaakt met de ELK-stack en het configuratiebestand van Logstash voor logparsing. In dit artikel zullen we ons richten op het belangrijkste aspect vanuit analytisch oogpunt: datgene wat je van het systeem wilt zien en waarvoor alles is opgezet \u2014 dat zijn de grafieken en tabellen samengebracht in dashboards<\/b>. Vandaag zullen we nader kennismaken met het visualisatiesysteem Kibana<\/b>, bekijken hoe we grafieken en tabellen kunnen maken, en uiteindelijk een eenvoudige dashboard op basis van de logs van de Check Point firewall opbouwen.
\n<\/a><\/noindex>
\nDe eerste stap in het werken met Kibana is het cre\u00ebren van een indexpatroon<\/b>, logisch gezien is dit een verzameling indices die op een bepaalde manier samenkomen. Uiteraard is dit uitsluitend een instelling zodat Kibana informatie gemakkelijker kan zoeken over alle indices tegelijkertijd. Dit wordt ingesteld door het matchen van een string, bijvoorbeeld \u201ccheckpoint-*\u201d met de naam van de index. Bijvoorbeeld, \u201ccheckpoint-2019.12.05\u201d zou passen bij het patroon, maar gewoon \u201ccheckpoint\u201d zou dat niet doen. Het is ook vermeldenswaardig dat je in de zoekfunctie niet tegelijkertijd informatie kunt zoeken over verschillende indexpatronen. Later in de volgende artikelen zullen we zien dat API-aanroepen worden gedaan op basis van de naam van de index of op basis van \u00e9\u00e9n regel patroon, klikbare afbeelding:<\/p>\n

\"3.<\/a><\/noindex><\/p>\n

Daarna controleren we in het menu Ontdekken of alle logs worden ge\u00efndexeerd en of de juiste parser is ingesteld. Als er enige inconsistenties worden geconstateerd, zoals het wijzigen van het gegevenstype van string naar integer, moet het configuratiebestand van Logstash worden aangepast, waardoor nieuwe logs correct worden vastgelegd. Om oude logs v\u00f3\u00f3r de wijziging in de gewenste vorm te krijgen, helpt alleen het proces van re-indexeren. In latere artikelen zal deze operatie gedetailleerder worden besproken. We zorgen ervoor dat alles in orde is, klikbare afbeelding:<\/p>\n

\"3.<\/a><\/noindex><\/p>\n

De logs zijn op hun plek, dus we kunnen beginnen met het opbouwen van dashboards. Op basis van de analytische dashboards van security producten kunnen we de staat van de informatiebeveiliging in de organisatie begrijpen, kwetsbare plekken in het huidige beleid visueel identifi\u00ebren en in de toekomst manieren ontwikkelen om deze aan te pakken. We bouwen een klein dashboard op met behulp van verschillende visualisatiemiddelen. Het dashboard zal uit 5 componenten bestaan: <\/p>\n

    \n
  1. een tabel voor het tellen van het totale aantal logs per blade<\/li>\n
  2. een tabel voor kritieke IPS-handtekeningen<\/li>\n
  3. een cirkeldiagram voor Threat Prevention-gebeurtenissen<\/li>\n
  4. diagram van de meest populaire bezochte websites<\/li>\n
  5. diagram van het gebruik van de meest gevaarlijke toepassingen<\/li>\n<\/ol>\n

    \nOm visualisatiefiguren te maken, moet je naar het menu gaan Visualiseren<\/b>, en kies de gewenste figuur die je wilt bouwen! Laten we stap voor stap doorgaan.<\/p>\n

    Tabel voor het tellen van het totale aantal logs per blade<\/h3>\n

    \nKies hiervoor de figuur Data Tabel<\/b>, dan gaan we naar de tool voor het maken van grafieken, aan de linkerkant worden de figuurinstellingen ingevuld, aan de rechterkant hoe deze eruit zal zien met de huidige instellingen. Eerst laat ik zien hoe de afgewerkte tabel eruit zal zien, daarna lopen we de instellingen door, de afbeelding is klikbaar:<\/p>\n

    \"3.<\/a><\/noindex><\/p>\n

    Meer gedetailleerde figuurinstellingen, de afbeelding is klikbaar:<\/p>\n

    \"3.<\/a><\/noindex><\/p>\n

    Laten we de instellingen doornemen.<\/p>\n

    Eerst wordt ingesteld de metriek<\/b>, dit is de waarde waarop alle velden worden geaggregeerd. Metrics worden berekend op basis van waarden die op een bepaalde manier uit documenten zijn gehaald. Waarden worden meestal gehaald uit velden<\/b> van het document, maar kunnen ook worden gegenereerd met behulp van scripts. In dit geval stellen we in Aggregatie: Aantal<\/b> (totaal aantal logs).<\/p>\n

    Daarna splitsen we de tabel in segmenten (velden) waar de metriek over wordt berekend. Deze functie wordt uitgevoerd door de instelling Buckets, die op haar beurt uit 2 opties voor instellingen bestaat: <\/p>\n

      \n
    1. split rows \u2014 kolommen toevoegen en de tabel vervolgens splitsen in rijen<\/li>\n
    2. split table \u2014 splitsen in meerdere tabellen op basis van de waarden van een bepaald veld. <\/li>\n<\/ol>\n

      \nIn buckets<\/b> je kunt meerdere splitsingen toevoegen om meerdere kolommen of tabellen te maken, de beperkingen liggen hier meer in de logica. Bij aggregatie kan je kiezen op welke manier de splitsing in segmenten zal plaatsvinden: ipv4 range, date range, Terms, etc. De meest interessante keuze is Terms<\/b> en Significant Terms<\/b>, splitsing in segmenten gebeurt op basis van de waarden van een bepaald indexveld, het verschil ligt in het aantal teruggegeven waarden en hun weergave. Aangezien we de tabel willen splitsen op productnamen, kiezen we het veld \u2014 product.keyword<\/b> en stellen we de grootte in op 25 teruggegeven waarden. <\/p>\n

      In plaats van rijen wordt in elasticsearch gebruik gemaakt van 2 datatypes \u2014 text<\/b> en keyword<\/b>. Als u een full-text zoekopdracht wilt uitvoeren, moet u het type text gebruiken, wat zeer handig is bij het schrijven van uw eigen zoekservice, bijvoorbeeld wanneer u een vermelding van een woord in een specifiek veld (tekst) zoekt. Als u alleen een exacte overeenkomst wilt, moet u het type keyword gebruiken. Het datatypes keyword moet ook worden gebruikt voor velden die sortering of aggregatie vereisen, dus in ons geval.<\/p>\n

      Als resultaat telt Elasticsearch het aantal logs over een bepaalde tijd met aggregatie op basis van de waarde in het veld product. In de Custom Label stellen we de naam van de kolom in die in de tabel wordt weergegeven, we stellen de tijd in waarvoor we de logs verzamelen, we starten de visualisatie - Kibana verzendt een verzoek naar Elasticsearch, wacht op een antwoord en visualiseert vervolgens de ontvangen gegevens. De tabel is klaar!<\/p>\n

      Cirkeldiagram van Threat Prevention-gebeurtenissen<\/h3>\n

      \nEr is bepaalde belangstelling voor de informatie, in welk percentage reacties dit \u00fcberhaupt is detecteren<\/b> en voorkomen<\/b> van beveiligingsincidenten in het huidige beveiligingsbeleid. Voor dit geval is een cirkeldiagram goed geschikt. We kiezen in Visualize - Cirkeldiagram<\/b>. Ook in de metric stellen we de aggregatie in op het aantal logs. In buckets stellen we Terms => action in. <\/p>\n

      Het lijkt allemaal correct, maar het resultaat toont waarden van alle blades, dus we moeten alleen filteren op de blades die binnen Threat Prevention werken. Daarom configureren we absoluut de filter<\/b> om informatie alleen te zoeken via de blades die verantwoordelijk zijn voor beveiligingsincidenten - product: (\"Anti-Bot\" OF \"New Anti-Virus\" OF \"DDoS Protector\" OF \"SmartDefense\" OF \"Threat Emulation\"). De afbeelding is klikbaar:<\/p>\n

      \"3.<\/a><\/noindex><\/p>\n

      En meer gedetailleerde instellingen, de afbeelding is klikbaar:<\/p>\n

      \"3.<\/a><\/noindex><\/p>\n

      Tabel van IPS-gebeurtenissen<\/h3>\n

      \nVervolgens is het erg belangrijk vanuit het oogpunt van IB om de gebeurtenissen per blade te bekijken en te controleren IPS<\/b> en Threat Emulation<\/b>, die niet worden geblokkeerd<\/b> door het huidige beleid, zodat we later ofwel de handtekening naar prevent kunnen overbrengen, of als het verkeer geldig is - de handtekening niet controleren. We cre\u00ebren de tabel ook zoals in het eerste voorbeeld, met als enige verschil dat we meerdere kolommen aanmaken: protections.keyword, severity.keyword, product.keyword, originsicname.keyword. We configureren absoluut een filter om informatie alleen te zoeken via de blades die verantwoordelijk zijn voor beveiligingsincidenten - product: (\"SmartDefense\" OF \"Threat Emulation\"). De afbeelding is klikbaar:<\/p>\n

      \"3.<\/a><\/noindex><\/p>\n

      Meer gedetailleerde instellingen, de afbeelding is klikbaar:<\/p>\n

      \"3.<\/a><\/noindex><\/p>\n

      Diagrammen van de meest populaire bezochte websites<\/h3>\n

      \nHiervoor cre\u00ebren we een figuur \u2014 Verticale Staaf<\/b>. We gebruiken ook de meting count (Y-as), en op de X-as gebruiken we de namen van de bezochte websites \u2014 \u201cappi_name\u201d. Hier is een kleine truc: als je de instellingen in de huidige variant uitvoert, worden alle websites getekend in \u00e9\u00e9n kleur op de grafiek. Om ze verschillende kleuren te geven, gebruiken we een extra instelling \u2014 \u201csplit series\u201d, die het mogelijk maakt om de al gemaakte kolom in meerdere waarden te splitsen, afhankelijk van het geselecteerde veld natuurlijk! Deze splitsing kan worden gebruikt als \u00e9\u00e9n gekleurde kolom in de stacked modus, of in de normale modus om meerdere kolommen voor bepaalde waarden op de X-as te cre\u00ebren. In dit geval gebruiken we dezelfde waarde als op de X-as, wat het mogelijk maakt om alle kolommen in verschillende kleuren weer te geven, rechtsboven worden ze aangeduid met kleuren. In de filter geven we in \u2014 product: \u00abURL Filtering\u00bb om alleen informatie over de bezochte websites te zien, de afbeelding is klikbaar:<\/p>\n

      \"3.<\/a><\/noindex><\/p>\n

      Instellingen:<\/p>\n

      \"3.<\/a><\/noindex><\/p>\n

      Diagram over het gebruik van de meest gevaarlijke applicaties<\/h3>\n

      \nHiervoor cre\u00ebren we een figuur \u2014 Verticale Staaf. We gebruiken ook de meting count (Y-as), en op de X-as gebruiken we de namen van de gebruikte applicaties \u2014 \u201cappi_name\u201d. Het belangrijkste is het instellen van de filter \u2014 product: \u00abApplication Control\u00bb EN app_risk: (4 OF 5 OF 3) EN action: \u00abaccept\u00bb. We filteren de logs op de blade Application Control, nemen alleen die websites die zijn geclassificeerd als websites met het risico Kritisch, Hoog, Medium, en alleen als de toegang tot deze websites is toegestaan. De afbeelding is klikbaar:<\/p>\n

      \"3.<\/a><\/noindex><\/p>\n

      Instellingen, klikbaar:<\/p>\n

      \"3.<\/a><\/noindex><\/p>\n

      Dashboard<\/h3>\n

      \nZien en cre\u00ebren van dashboards bevindt zich in een apart menu-item \u2014 Dashboard<\/b>. Hier is het eenvoudig: er wordt een nieuw dashboard aangemaakt, visualisatie wordt toegevoegd, en alles wordt op zijn plaats gezet!<\/p>\n

      We cre\u00ebren een dashboard waarmee de basisstatus van de informatiebeveiliging in de organisatie kan worden begrepen, duidelijk alleen op het niveau van Check Point, de afbeelding is klikbaar:<\/p>\n

      \"3.<\/a><\/noindex><\/p>\n

      Op basis van deze grafieken kunnen we begrijpen welke kritieke handtekeningen niet worden geblokkeerd door de firewall, waar gebruikers naartoe gaan, en welke meest gevaarlijke applicaties ze gebruiken.<\/p>\n

      Conclusie<\/h3>\n

      \nWe hebben de mogelijkheden van basisvisualisatie in Kibana bekeken en een dashboard gemaakt, maar dat is nog maar een klein gedeelte. In de volgende lessen zullen we de configuratie van kaarten, het werken met het Elasticsearch-systeem, het leren kennen van API-aanroepen, automatisering en nog veel meer bespreken!<\/p>\n

      Dus houd de updates in de gaten (Telegram<\/a><\/noindex>, Facebook<\/a><\/noindex>, VK<\/a><\/noindex>, TS Solution Blog<\/a><\/noindex>), Yandex.Zen<\/a><\/noindex>.
      \n
      Bron:       habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

      \u0412 \u043f\u0440\u043e\u0448\u043b\u044b\u0445 \u0441\u0442\u0430\u0442\u044c\u044f\u0445 \u043c\u044b \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u043b\u0438\u0441\u044c \u0441\u043e \u0441\u0442\u0435\u043a\u043e\u043c elk \u0438 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u043e\u0439 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u043e\u0433\u043e \u0444\u0430\u0439\u043b\u0430 Logstash \u0434\u043b\u044f \u043f\u0430\u0440\u0441\u0435\u0440\u0430 \u043b\u043e\u0433\u043e\u0432, \u0432 \u0434\u0430\u043d\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043f\u0435\u0440\u0435\u0439\u0434\u0435\u043c \u043a \u0441\u0430\u043c\u043e\u043c\u0443 \u0432\u0430\u0436\u043d\u043e\u043c\u0443 \u0441 \u0442\u043e\u0447\u043a\u0438 \u0437\u0440\u0435\u043d\u0438\u044f \u0430\u043d\u0430\u043b\u0438\u0442\u0438\u043a\u0438, \u0442\u043e \u0447\u0442\u043e \u0432\u044b \u0445\u043e\u0442\u0438\u0442\u0435 \u0443\u0432\u0438\u0434\u0435\u0442\u044c \u043e\u0442 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0438 \u0440\u0430\u0434\u0438 \u0447\u0435\u0433\u043e \u0432\u0441\u0435 \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u043b\u043e\u0441\u044c \u2014 \u044d\u0442\u043e \u0433\u0440\u0430\u0444\u0438\u043a\u0438 \u0438 \u0442\u0430\u0431\u043b\u0438\u0446\u044b \u043e\u0431\u044a\u0435\u0434\u0438\u043d\u0435\u043d\u043d\u044b\u0435 \u0432 \u0434\u0430\u0448\u0431\u043e\u0440\u0434\u044b. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u044b \u043f\u043e\u0431\u043b\u0438\u0436\u0435 \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u043c\u0441\u044f \u0441 \u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439 \u0432\u0438\u0437\u0443\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-54536","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd473. Elastic Stack: analyse van security logs. Dashboards | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/3-elastic-stack-analiz-security-logov-dashbordy","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd473. Elastic stack: \u0430\u043d\u0430\u043b\u0438\u0437 security \u043b\u043e\u0433\u043e\u0432. \u0414\u0430\u0448\u0431\u043e\u0440\u0434\u044b | ProHoster","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/3-elastic-stack-analiz-security-logov-dashbordy","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-12-27T21:00:00+00:00","article:modified_time":"2020-02-18T11:02:33+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"54536","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 11:45:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:03:57","updated":"2026-01-24 11:45:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/54536","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=54536"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/54536\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=54536"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=54536"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=54536"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}