Tag Archives: Vulners Audit

Scanvus – my open source Vulnerability Scanner for Linux hosts and Docker images

Hello everyone! This video was recorded for the VMconf 22 Vulnerability Management conference, vmconf.pw. I will be talking about my open source project Scanvus. This project is already a year old and I use it almost every day.

Alternative video link (for Russia): https://vk.com/video-149273431_456239100

Scanvus (Simple Credentialed Authenticated Network VUlnerability Scanner) is a vulnerability scanner for Linux. Currently for Ubuntu, Debian, CentOS, RedHat, Oracle Linux and Alpine distributions. But in general for any Linux distribution supported by the Vulners Linux API. The purpose of this utility is to get a list of packages and Linux distribution version from some source, make a request to an external vulnerabililty detection API (only Vulners Linux API is currently supported), and show the vulnerability report.

Scanvus can show vulnerabilities for

  • localhost
  • remote host via SSH
  • docker image
  • inventory file of a certain format

This utility greatly simplifies Linux infrastructure auditing. And besides, this is a project in which I can try to implement my ideas on vulnerability detection.

Example of output

For all targets the output is the same. It contains information about the target and the type of check. Then information about the OS version and the number of Linux packages. And finally, the actual information about vulnerabilities: how many vulnerabilities were found and the criticality levels of these vulnerabilities. The table shows the criticality level, bulletin ID, CVE list for the bulletin, and a comparison of the invulnerable fixed package version with the actual installed version.

This report is not the only way to present results. You can optionally export the results to JSON (OS inventory data, raw vulnerability data from Vulners Linux API or processed vulnerability data).

Continue reading

Vulners Linux Audit API: Security Bulletin Publication Dates in Results

Hello everyone! In this short episode, I want to talk about the new feature in Vulners Linux API.

Alternative video link (for Russia): https://vk.com/video-149273431_456239092

Linux security bulletin publication dates are now included in scan results. Why is it useful?

Continue reading

AM Live Vulnerability Management Conference Part 2: What was I talking about there

Hello all! It is the second part about AM Live Vulnerability Management conference. In the first part I made the timecodes for the 2 hours video in Russian. Here I have combined all my lines into one text.

What is Vulnerability Management?

Vulnerability Management process is the opposite of the admin’s saying “If it works – don’t touch it!”. The main idea of this process is to somehow fix the vulnerabilities. How do you achieve this is not so important. Maybe you will have a nice Plan-Do-Check-Act process and strict policies. Maybe not. The main thing is that you fix vulnerabilities! And the main problem is to negotiate this regular patching with system administrators and service owners.

Continue reading

Vulners Linux Audit API for Host Vulnerability Detection: Manual Auditing, Python Scripting and Licensing

Hello everyone! This episode will be about Vulners Linux Audit API, which allows you to detect vulnerabilities on a Linux host knowing only the OS version and installed packages. I had a similar post about this 4 years ago, but some details have changed, so I came back to this topic.

Continue reading

Can a Vulnerability Scan break servers and services?

The most serious problem of Vulnerability Scanners is that they are too complex and unpredictable. Usually they don’t affect the target hosts, but when they do, welcome to hell! And if you scan huge infrastructure, tens thousands hosts and more, it’s not “if” the scanner will break the server it’s “when” it will do it.

As a responsible person for Vulnerability Management you will be also responsible for all the troubles that VM product can make in the IT infrastructure. And what will you say to the angry mob of your colleagues from IT and Business when they will be quite curious to know why did the service/server go down after the scan? Actually, it’s not much to say.

Continue reading

First steps with Docker: installation in CentOS 7, vulnerability assessment, interactive mode and saving changes

Docker and containerization are literally everywhere. IMHO, this changes the IT landscape much more than virtualization and clouds. Let’s say you have a host, you checked it and find out that there are no vulnerable packages. But what’s the point if this host runs Docker containers with their own packages that may be vulnerable? Add to this the issues with complex orchestration systems, such as Kubernetes, completely different DevOps subculture with their own terms, slang, beliefs, priorities, and the situation begins to look like complete IT Hell. 🙂

First steps with Docker

But it seems that Docker will be here for a long time, so we will have to live with it. 😉 Here I will not write what Docker is and how it works. There are many publications about this. I personally interested in what actually we can do with these weird “virtual machines”, how can we run and assess them.

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