Hello everyone! As we saw in the last episode, the results of vulnerability detection for one host produced by two different APIs can vary greatly. Therefore, in order to find out the truth, it is necessary to understand what vulnerability data is provided by the Linux distribution vendor and how this data is structured.
Why is it important to do this? Because using data from a Linux distribution vendor, we can ask vulnerability detection API vendors questions: why are you detecting in a different way than described in this data? And then we will understand what caused the difference. And we will either adjust the API for vulnerability detection, or we will adjust the content of the Linux distribution vendor. Either way, it will be a success! In any case, the transparency of the vulnerability detection process will increase.
Hello everyone! Great news for my open source Scanvus project! You can now perform vulnerability checks on Linux hosts and docker images not only using the Vulners.com API, but also with the Vulns.io VM API. It’s especially nice that all the code to support the new API was written and contributed by colleagues from Vulns.io. I just had to do the final test. Many thanks to them for this!
How can the support of these two APIs in Scanvus be useful?
Now there is no binding to one vendor. Choose which service and price you prefer.
The set of supported operating systems varies between Vulners.com and Vulns.io. If a particular Linux distribution is not supported by one vendor, it may be supported by another vendor.
Vulners and Vulns.io implemented vulnerability checks independently of each other. If the results differ when scanning the same host/image, then implementation errors will be clearly visible.
Scanvus is released under the MIT license, so you can use it as an example of working with the Vulners.com and Vulns.io APIs and use this code in your projects.
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.
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).
Hello everyone! As you probably know, CentOS Linux, the main Enterprise-level Linux server distribution, will soon disappear. It wasn’t hard to predict when RedHat acquired CentOS in 2014, and now it is actually happening. End of life of CentOS Linux 8 was 31.12.2021. There won’t be CentOS Linux as downstream for RedHat anymore. Only CentOS Stream, that will be upstream for RedHat, more or less a testing distro like Fedora.
Of course, it is a matter of debate whether security guys can actually decide which Linux distributions a company will use and set that as a requirement. But in any case, the security guys will definitely take part in the decision. I made a poll in my Telegram channel. 113 people voted. So, let’s take a look at the results and discuss which of the Linux distributions we can recommend to IT teams.
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.
During the long New Year holidays (30 dec – 8 jan) I started a new project: Vagrant-based Linux package builder called Packabit. I thought it might be nice to have scripts that will automatically build a Linux packages from sources and will NOT litter main system with unnecessary packages. Something like a very simplified build server.
Why might someone want to build Linux packages on their own?
Official repositories of Linux distros usually contain pretty old versions of packages. Let’s take, for example, Nmap. The only version of Nmap available in the repository for Ubuntu 18.04.1 LTS is 7.60 , and the latest stable version of Nmap available on official website is 7.70.
Release dates according Nmap changelog:
Nmap 7.70 [2018-03-20]
Nmap 7.60 [2017-07-31]
The latency is more than a year.
Is it really necessary to use the latest version? Actually, yes. Every new version of Nmap contain more banner detects and service detects and produce more adequate results. Nmap project offers official packages only for RPM-based distributions: CentOS, RHEL, Fedora, etc. And if you need packages for DEB-based distributions, Debian, Ubuntu, Kali, etc. you should build them yourself.
What is the Packabit?
Currently it’s just 2 bash scripts for building stable Nmap package for Ubuntu 18.04: one is for creation and launching Vagrant virtual machine, the other runs on guest virtual machine and build Nmap package from the sources.
How to try it
I want this project to be as opensource as possible. If anyone wants to give it a try, get it from Github. For the end-user it looks like this: run the script build_nmap.sh, wait for 10 minutes and get new package from the packages directory. There won’t be any litter in a process. Each time a new virtual machine for building will be automatically created and then destroyed.
This is my personal blog. The opinions expressed here are my own and not of my employer. All product names, logos, and brands are property of their respective owners. All company, product and service names used here for identification purposes only. Use of these names, logos, and brands does not imply endorsement. You can freely use materials of this site, but it would be nice if you place a link on https://avleonov.com and send message about it at me@avleonov.com or contact me any other way.