Motivation Earlier this year, I discussed how I used AI to successfully migrate my website infrastructure from an outdated LAMP stack to a modern architecture based on container technologies. Almost 8 months had passed since then and I feel very proud with the results, I’ve CI/CD in place with a combination of Github actions and Portainer an publishing a new post on this website is as easy as pushing a new commit to https://github.

This vulnerability has been reported to https://www.cve.org/ and a CVE has been assigned 🎉. Read about CVE-2023-39059 In this article, I aim to talk about an interesting open-source project that I came across a couple of weeks ago while making some upgrades in my home lab. This project caught my attention and turned into the main subject of my weekend security research. Introduction Preparation

It’s been almost a year since I wrote about my home lab’s network re-architecture. Since then, things have changed and the lab is still a work in progress. But that’s the beauty of having a home lab - it’s a constantly evolving environment where experimentation and learning are the norm. Like many other home lab enthusiasts, I rely heavily on virtualization to conduct experiments. I mainly deploy virtual machines (VM’s) in two locations: my personal laptop, a Lenovo X1 Extreme with 64GB of RAM and 6 cores; and my custom-built workstation, which boasts 128GB of RAM and 8 cores.

Motivation A few days ago, I finally accomplished something that has been on my TO-DO list for a couple of years now. The task was simple, to migrate my personal blog https://www.alevsk.com (and some other websites), to a modern and more scalable infrastructure compared to what I’ve been using for the last 15 years. I started my personal blog in 2008 (right before college). The main purpose was to be a place where I could document new things I was learning at the moment, to build my online identity and, in general, it was some kind of “digital sanctuary” in which I was able to experiment and express myself.

One time during a security engineering interview someone asked me What is the number one vulnerability? That question caught me by surprise. I immediately start thinking about OWASP top 10, RCE, 0days and things like that, then I remembered the security incidents I’ve deal with in the past and most of them has been related to employees accidentally exposing credentials or private keys so I responded with “developers pushing credentials into public repositories".

Over the last couple years I’ve been involved in many projects that require TLS certificates and some other technologies to provide security and establish encryption in transit for network communications. These technologies involve different concepts, protocols and standards such as mTLS, X509, PKI, digital signatures, hmac, symmetric and asymmetric encryption, different cryptographic algorithms etc and can feel very overwhelming especially for people that are new in the topic. I decided to write a quick blog post and share some of the lessons I’ve learned over the years.

A couple weeks ago I did a mayor reconfiguration on my home network, I migrated from a single flat insecure network in where any device was able to talk to any other to a more secure design in where the network is segmented (IoT devices, guests, home lab, etc) and where I control who has access to what resources via firewall rules and other tools. My original home network consisted of a single Google Wifi router, if you are interested the device it’s limited but will get the job done.

HTTP and HTTPS are well known Internet protocols that don’t require any introduction. The other day at work as part of a daily security scan one of our servers got tagged as using weak cipher suites during TLS negotiation. In this quick post I’ll explain what a weak cipher suite means and how to fix it. There are many tools out there to check if you are following the security best practices when it comes to SSL/TLS server configuration (supported versions, accepted cipher suites, certificate transparency, expiration, etc.

This compilation of open-source tools aim to provide resources you can use for some of the step of the secure development life cycle of your organization, ie: Security Training Security Architecture Review Security Requirements Threat Modeling Static Analysis OpenSource Analysis Dynamic Analysis Penetration Testing If you think I should add a new tool to the list you can open a Github issue or send a PR directly. User management Keycloak Secret management HashiCorp Vault IDS, IPS, Firewalls and Host/Network monitoring Snort Suricata Zeek WireShark OSSEC Prometheus Pfsense Data visualization Grafana Web Application Firewall ModSecurity NAXSI Shadow Daemon Object Storage MinIO VPN OpenVPN Wireguard Security training platforms OWASP Juice Shop DVWA Static analysis tools Snyk Dockerscan Clair scanner Bandit (code analyzer for python) Brakeman (code analyzer for Ruby on rails applications) Semgrep (Static analysis at ludicrous speed) Dynamic analysis tools Hetty (Proxy similar to BurpSuite) OpenVAS Scanner (Web scanner) Nikto2 (Web scanner) OWASP ZAP Nuclei Misc Pi-Hole Podman

Environment variables are great to configure and change the behavior of your applications, however there’s a downside for that, if someone uses the `docker inspect` command your precious secrets will get revealed there, because of that you should never pass any sensitive data to your container using environment variables (the `-e` flag), I’ll show you an example. Suppose you have a simple python application (Download the source code of the app here: https://github.