Barapass console Password Manager. I decided to publish my simple console Password Manager. I called it barapass (github). I’ve been using It for quite some time in Linux and in Windows (in WSL). Probably it will also work natively in Windows and MacOS with minimal fixes, but I haven’t tried it yet.
Why do people use password managers?
Well, with password manager it’s possible to avoid remembering passwords and make them arbitrarily complex and long. And no one will be able to brute force them. Of course, you can simply store passwords in text files, but password managers are better than this because:
no one will see your password over your shoulder;
if an attacker gains access to the files on your host, it won’t possible to read your passwords from the encrypted file or storage (well, ideally);
it’s easier to search for objects in the password manager and copy values from it.
I wanted something as simple as editing a text file with the key-value content. And I wanted it to be stored in a secure manner, and security could be easily checked, “simple and stupid”.
Zbrunk universal data analysis system. Zbrunk project (github) began almost like a joke. And in a way it is? In short, my friends and I decided to make an open-source (MIT license) tool, which will be a kind of alternative to Splunk for some specific tasks.
So, it will be possible to:
Put structured JSON events in Zbrunk using http collector API
Get the events from Zbrunk using http search API
Make information panels based on these search requests and place them on dashboards
Why is it necessary? Well, I’ve worked a lot with Splunk in recent years. I like the main concepts, and I think working with the events is a very effective and natural way of processing and presenting data. But for my tasks (Asset Management, Compliance Management, Vulnerability Management) with several hundred megabytes of raw data per day to process and dashboards that need to be updated once or several times a day Splunk felt like an overkill. You really don’t need such performance for these tasks.
And, considering the price, it only makes sense if your organization already uses Splunk for other tasks. After Splunk decision to leave Russian market, this became even more obvious, so many people began to look for alternatives for possible and, as far as possible, painless migration.
We are realistic, the performance and search capabilities of Zbrunk will be MUCH worse. It’s impossible to make such universal and effective solution as a pet project without any resources. So, don’t expect something that will process terabytes of logs in near real time, the goal is completely different. But if you want same basic tool to make dashboards, it worth a try. ?
Now, after first weekend of coding and planning it’s possible to send events to Zbrunk just like you do it using the Splunk HTTP Event Collector and they appear in MongoDB:
Thus, it will be very easy to use your existing custom connectors if you already have some. The next step is to make basic http search API, prepare dashboard data using these search requests and somehow show these dashboards, for example, in Grafana. Stay tuned and welcome to participate. ?
Open Positioner: my new project for tracking IT and security jobs. The idea of my new project is to retrieve the data from job-searching websites and provide better filtering, searching and visualization.
I think for the most people who read this, searching for a job in Internet is a pretty common activity. Even if you are not going to change job right now, it might be quite interesting to know what skills are currently the most valuable for your specialization and what is going on on the Global labor market.
Packabit project: building Nmap deb packages for Ubuntu. 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.
Vulchain scan workflow and search queries. This post will be about my Vulnerability Scanner project – Vulchain. Recently I’ve spent couple of my weekends almost exclusively on coding: refactoring the scan engine, creating API and GUI.
I was doing it because of the conferences, where I will be speaking soon:
Pretty intense schedule for a guy who spends most of his time in PyCharm and Linux console. 😉 Very excited! So, it seemed right to add a couple of slides about my project and show that something is already working.
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.
Basic principles of the project. This is not a dogma, but rather a general direction.
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
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.
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.
Neutrality. All modules are independent and easily replaceable. For example:
You can use Nmap or other port scanner to detect services. You can refuse active scanning completely and collect data from local agents or from your cmdb.
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. 😉
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.