Tag Archives: json

How to correlate different events in Splunk and make dashboards

Recently I’ve spent some time dealing with Splunk. Despite the fact that I have already done various Splunk searches before, for example in “Tracking software versions using Nessus and Splunk“, the correlation of different events in Splunk seems to be a very different task. And there not so many publicly available examples of this on the Internet. So, I decided to write a small post about it myself.

Splunk dashboard

Disclaimer: I’m not a pro in Splunk. I don’t have an idea if I am doing this the right or in optimal way. ūüėȬ†I just learned some tricks, they worked for me well and I want to share it with you.¬†

I will show the following case:

  1. We have some active network hosts.
  2. Some software product should be installed these hosts.
  3. We will send “host X is active” and “software is installed on host X”¬†events to the Splunk server.
  4. We want to get some diagrams in Splunk that will show us on which hosts the software is  installed and how number of such hosts is changing in time.

As you can see, the task is quite a trivial and it can be easily implemented in pure Python. But the idea is to make it in Splunk. ūüėČ

Continue reading

Converting Nmap xml scan reports to json

Unfortunately, Nmap can not save the results in json. All available output options:

-oN <filespec> (normal output)
-oX <filespec> (XML output)
-oS <filespec> (ScRipT KIdd|3 oUTpuT)
-oG <filespec> (grepable output)
-oA <basename> (Output to all formats)

And processing xml results may not be easy an easy task. Just look how I analyze the contents of the Nessus report in “Parsing Nessus v2 XML reports with python“. Not the most readable code, right? And what alternatives do we have?

Nmap json scan report

Formal XML to json conversion is impossible. Formats are very different. However, there are python modules, for example xmltodict, that can reliably convert XML into Python structures of dictionaries, lists and strings. However, they have to change some names of parameters to avoid collisions. In my opinion this is not a big price for convenience.

So, let’s see how this will work for Nmap command:

nmap -sV -oX nmap_output.xml avleonov.com 1>/dev/null 2>/dev/null

Continue reading

Masking Vulnerability Scan reports

Continuing the series of posts about Kenna (“Analyzing Vulnerability Scan data“,¬†“Connectors and REST API“) and similar services. Is it actually safe to send your vulnerability data to some external cloud service for analysis?¬†Leakage of such information can potentially cause great damage to your organization, right?

Masking Vulnerability Scans

It’s once again a problem of trust to vendor. IMHO, in some cases it may make sense to hide the real hostnames and ip-addresses of the target hosts in scan reports. So, it would be clear¬†for analysis vendor that some critical vulnerability exists somewhere, but it would not be clear where exactly.

To do this, each hostname/ip-address should be replaced to some values of similar type and should be replaced on the same value each time. So the algorithms of Kenna-like service could work with this masked reports. This mean that we need to create a replacement dictionary.

Continue reading

Confluence REST API for reading and updating wiki pages

In previous posts I wrote how to automate the work with Atlassian Jira, including automated ticket labeling. Now let’s try to use REST API of another popular Atlassian product – Confluence wiki engine.

Confluence REST API

What you may want to automate in Confluence? Obviously, it may be useful to read the pages that your colleagues regularly update and then use this data in some scripts as an input. You may also want to update your own Confluence pages, for example to post Vulnerability Scanning results. ūüėČ

Continue reading

Vulchain Scanner: 5 basic principles

New Year holidays in Russia lasts 10 days this year! Isn’t it an excellent opportunity to start a new project? So, I decided to make my own active network vulnerability scanner – Vulchain.

Why? Well, first of all, it’s fun. You can make the architecture from scratch, see the difficulties invisible from the user side and try something new in software development as well.

Vulchain modular scanner

Basic principles of the project. This is not a dogma, but rather a general direction.

  1. Data layers. I would like to have this independent sets of data:
    • Raw data collections
    • Software versions detected from the raw data
    • Vulnerabilities detected from the software versions
    • Exploitability assessment data for the detected vulnerabilities
  2. Modularity. Most of functionality will be performed by the independent modules which read some data from one data level, and create some data on other data level.
  3. Transparency. Data is stored constantly on the all levels. You can easily figure out how the data was  processed, track the errors and modify modules.
  4. Neutrality. All modules are independent and easily replaceable. For example:
  5. Rationality. If it is possible to use some security utility, service or product, we will integrate with them, rather than writing our own analogue. We spend resources only on what will give us the maximum profit at a minimum of costs. ūüėČ

Continue reading