Forem: Tomas Hornak

Securing a VPS: Essential Hardening Steps for Web Developers (Part 1)

Tomas Hornak — Tue, 05 Aug 2025 20:27:50 +0000

After working with various PaaS solutions for years, I decided to set up a VPS with Contabo for hosting a few personal projects. While nothing particularly sensitive will be hosted there, I still wanted to implement proper security practices from the start.

Even simple hobby projects can become targets for automated attacks or get compromised for cryptocurrency mining. Here's my systematic approach to hardening a fresh Ubuntu VPS, covering the essential security fundamentals.

The Starting Point

Fresh VPS with Ubuntu, an admin user with sudo privileges, and SSH key authentication already configured during setup. Time to implement proper security measures.

Step 1: SSH Hardening

The default SSH configuration needed immediate attention. Running SSH on the default port 22 makes your server a target for automated scanning tools that constantly probe this port.

sudo nano /etc/ssh/sshd_config

Key changes made:

Port 2222                   # Move away from the default port
PermitRootLogin no          # Disable direct root access
PasswordAuthentication no   # Enforce key-based authentication
PubkeyAuthentication yes    # Enable SSH keys
MaxAuthTries 3              # Limit failed attempts
AllowUsers admin            # Restrict user access

Then restart SSHD:

sudo systemctl restart sshd

Important: Always test your SSH configuration in a separate terminal session before closing your current connection. This prevents accidental lockouts. Also, ideally, don't close your connection before Step 2.

Step 2: Firewall Configuration

Linux's UFW provides straightforward firewall management. The approach is to deny all incoming connections by default, then explicitly allow only necessary services.

# Set restrictive defaults
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow essential services
sudo ufw allow 2222/tcp   # SSH on custom port
sudo ufw allow 80/tcp     # HTTP
sudo ufw allow 443/tcp    # HTTPS

# Enable firewall
sudo ufw enable

Critical note: It's recommended to perform Steps 1 & 2 during one SSH session to avoid locking yourself out of access.

Step 3: Automated Intrusion Prevention with Fail2Ban

Fail2Ban monitors log files and automatically bans IP addresses showing suspicious behavior, such as repeated failed login attempts.

sudo apt install fail2ban

Modern Ubuntu systems use systemd journaling instead of traditional log files, which requires specific configuration:

sudo nano /etc/fail2ban/jail.local

[DEFAULT]
bantime = 3600      # Ban duration in seconds
findtime = 600      # Time window for counting failures
maxretry = 3        # Maximum attempts before ban

[sshd]
enabled = true
port = ssh
filter = sshd
backend = systemd   # Use systemd journal
journalmatch = _SYSTEMD_UNIT=ssh.service

After that, restart the service for it to use the updated configuration:

sudo systemctl restart fail2ban

Step 4: Docker Security Configuration

I am a big fan of Docker. I decided to go full docker. It will bring little few more steps but we'll get better security as all services accessible from internet will run in an isolated docker containers.

It also keeps our host machine clean of unecessary installed packages.

Installation is pretty simple and a lot of VPS providers offers fresh install with docker pre-istalled.

When docker is installed create /etc/docker/daemon.json with following content:

{
  "live-restore": true,
  "userland-proxy": false,
  "no-new-privileges": true,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

The no-new-privileges setting is particularly important as it prevents containers from escalating their privileges during runtime, blocking a common attack vector.

As before, don't forget to restart the service:

sudo systemctl restart docker

Current Security Status

The VPS now has:

SSH access secured with custom port and key-only authentication
Firewall blocking unauthorized connections
Automated intrusion detection and response
Hardened Docker daemon configuration

This setup effectively blocks automated attacks and provides a solid security foundation for hosting web applications.

Coming Up in Part 2

The next article will cover:

Setting up a reverse proxy with Nginx in Docker
SSL certificate management with Let's Encrypt
Container security best practices
System monitoring and maintenance

These foundational security measures provide essential protection while maintaining accessibility for legitimate use.

Understanding the Builder Design Pattern in TypeScript

Tomas Hornak — Wed, 17 Apr 2024 13:32:33 +0000

Design patterns are shared, repeatable solutions for common issues in software engineering. Let's talk about a popular design pattern called the Builder Design Pattern and explore how to implement it in TypeScript with a practical HTTP request builder example.

What is the Builder Pattern?

The Builder Pattern is a design pattern that simplifies the creation of complex objects by providing a step-by-step approach to building different types and representations of an object using a consistent construction process. By separating the construction of an object from its representation, the same construction process can create various representations.

Builder Pattern Concept Code

Let's explore a basic example – a StringBuilder, which constructs a string from words:

class StringBuilder {
  private words: string[] = [];

  addWord(word: string): StringBuilder {
    this.words.push(word);
    return this;
  }

  build(): string {
    return this.words.join(' ');
  }
}

// Client code using the builder
const myStringBuilder = new StringBuilder();
const sentence = myStringBuilder.addWord('Hello').addWord('world!').build();

console.log(sentence); // Outputs: Hello world!

In this code, our builder is the StringBuilder class, containing the addWord and build methods. The addWord method appends a word to the words array. Crucially, it also returns this, the builder object itself. This design facilitates the chaining of method calls, promoting readability and compactness.

The build method completes the process by joining the words together into a sentence. In the client code, we create the StringBuilder, add words to it, and finally use build to get the complete sentence.

Practical Example: HTTP Request Builder

Let's now see how the Builder Pattern can be applied in TypeScript for building an HTTP request.

class HttpRequest {
  method: string;
  url: string;
  body: Record<string, any>;
  headers: HeadersInit;

  constructor() {
    this.body = {};
    this.headers = {};
  }
}

class HttpRequestBuilder {
  httpRequest: HttpRequest;

  constructor() {
    this.httpRequest = new HttpRequest();
  }

  setMethod(method: string): HttpRequestBuilder {
    this.httpRequest.method = method;
    return this;
  }

  setUrl(url: string): HttpRequestBuilder {
    this.httpRequest.url = url;
    return this;
  }

  addBody(key: string, value: any): HttpRequestBuilder {
    this.httpRequest.body[key] = value;
    return this;
  }

  addHeader(name: string, value: string): HttpRequestBuilder {
    this.httpRequest.headers[name] = value;
    return this;
  }

  build(): Request {
    return new Request(this.httpRequest.url, {
      method: this.httpRequest.method,
      headers: this.httpRequest.headers,
      body: JSON.stringify(this.httpRequest.body),
    });
  }
}

let fetchRequest = new HttpRequestBuilder()
  .setMethod('POST')
  .setUrl('https://myapi.com/resource')
  .addHeader('Content-Type', 'application/json')
  .addBody('weather', 'is nice today')
  .build();

console.log(fetchRequest); // Outputs: a `Request` object which can be passed directly to `fetch()`

// Then it can be used using FETCH api:
fetch(fetchRequest)
  .then(response => response.json())
  .then(json => console.log(json))
  .catch(err => console.error('Error:', err));

Within this HTTP request builder, we're applying the Builder Design Pattern to progressively build our request. Notice again the use of this in our builder methods, allowing for the chaining of methods that simplifies the creation process.

Here are some potential benefits and drawbacks of using a Builder Pattern.

Benefits

Flexibility: Constructs various representations of objects.
Reduced Duplication: Mitigates code duplication that arises from numerous constructors.
Easy to Edit: Adjust the object's construction steps without influencing the object's code.

Drawbacks:

Code Complexity: May increase complexity due to new interfaces and classes. (personally, I don't consider this as a drawback)
Limits Validation: The pattern may struggle with property-specific validations such as mutually exclusive properties.

Conclusion

The Builder Pattern helps handle complex or multi-step object construction processes in a more readable and maintainable way. Keep in mind it's just one tool amongst many – its implementation should always consider the specific project requirements and circumstances.

Do you use Builder pattern in your code? If yes, what are your use cases for it?

A Sound Solution: Alerting Dev Server Failures

Tomas Hornak — Fri, 26 Jan 2024 05:27:25 +0000

During my recent work developing a web app with NextJs 13+, I came across a sly problem - silent (dev) server (with ZERO status code). Picture this: you're engrossed in code, cranking out new features, but nothing seems to change. After what feels like forever in developer's time (aka two minutes), you realize your dev server had crashed without you noticing.

But don't worry, because I found a way to stay ahead. Say hello to this lifesaving command:

xdev:
    @trap 'say "This is outrageous"' ERR \
        ; script -q /dev/null pnpm run dev:dashboard | tee /dev/tty \
        | grep --line-buffered -q "JavaScript heap out of memory" && say "Ooops" \
        ; stty sane

Let's break it down:

trap 'say "This is outrageous"' ERR this part instructs the system to say "This is outrageous" whenever an normal error occurs.
script -q /dev/null npm run dev | tee /dev/tty run dev server with npm run dev, pipe the output using script command to keep the colors in an stdout
grep --line-buffered -q "JavaScript heap out of memory" && say "Ooops" if the error message "JavaScript heap out of memory" appears, it triggers the system to say "Ooops".
stty sane reset the terminal settings if they've became garbled

In essence, this command provides an sound alert when your dev server fails, saving you precious minutes of confusion.

To run it simply type:

make xdev

Change "grepped" error message that triggers voice message "Oops" according your dev command or update sound to something funnier 8-)

Although developed for macOS, it should be easily transferable to Linux with one or two tweaks.

With this command, silent dev server failures will be a thing of the past. You can focus on conquering NextJs or any other framework, knowing an audible alert has got your back.

Have you encountered similar baffling situations in your development journey? What were your unique solutions?

Logging & Tracing in Python, FastApi, OpenCensus and Azure

Tomas Hornak — Tue, 30 Nov 2021 01:00:16 +0000

Logging. Even it's quite important to have good logging (and tracing) in an application, sometimes it's forgotten or underestimated. And even we can go well for some time just with print(), establishing good logging can significantly improve DX and production debugging.

We will go through the basics of logging in Python and its' configurations and then how to use OpenCensus to collect logs & traces and export them to Azure Application Insights.

This guide will try to cover the topic from zero to hero, therefore it will consist of several parts. This 1st part will be about Python, logging, and at the end, we'll create a simple FastApi server with a logging setup.

Key ingredients

Python - Python language and logging module
FastApi - Modern python web framework for building APIs. It's based on Pydantic and type hints to validate, serialize, and deserialize data, and automatically auto-generate OpenAPI documents
OpenCensus - OpenCensus is a set of libraries for various languages that allow you to collect application metrics and distributed traces, then transfer the data to a backend of your choice in real-time
Azure AppInsights - is an Azure monitoring and analytics tool for your resources. It is aggregated by Azure Monitor or Azure LogAnalytics so this guide applies more/less for these tools too

Although we'll show examples mostly on FastApi and later on Azure, most of the stuff we'll learn we'll be easily applicable on any Python or OpenCensus powered applications.

Python Logging

Python comes by default with a logging module named logging. The standard way how to use it is to request a named logger and use that to emit messages:



import logging

log = logging.getLogger("my-api")
log.info("Hello 42")

It's common to create a logger with __name__ in each file to have it easily distinguishable or have one specific based on the name.

It should be mentioned that getLogger("my-api") returns logger named my-api if created before otherwise it crates one and returns it. It was a little bit unexpected for me to have more experience in JS/React world and its' behavior will be important later in this guide.

Logging Levels

There are several logging levels and almost all of them (not NOTSET) have their appropriate log function like log.error("omg"):

50 - CRITICAL
40 - ERROR
30 - WARNING
20 - INFO
10 - DEBUG
0 - NOTSET

Setting the logging level to a certain value tells the library to handle all messages with the same level and up. So WARNING level will emit all WARNING, ERROR & CRITICAL events.

Configuration

For now, it doesn't do much except ordinary printing. We need to configure it to make it really useful.

We can configure it:

explicitly using Python code
from config file using fileConfig()
from dictConfig()

Config is easier to read but a little bit less flexible. The combination is possible but I encountered some issues when I integrated "too many" features.

In this guide I will try to show dict & code variants, but later the final solution will be in code for reasons mentioned before.

Configuring logging or actually, logger(s) means basically adding Formatter and Handler to them.

Basic (quick) config

Prepared basic configuration with default Formatter and StreamHandler



import logging
FORMAT = "%(levelname)s:%(message)s"
logging.basicConfig(format=FORMAT, level=logging.DEBUG)

logging.debug('This message should appear on the console')

More detailed config

Let's dive into a more detailed config. It's dict variant on one from docs:



LOG_LEVEL: str = "DEBUG"
FORMAT: str = "%(asctime)s - %(name)s - %(levelname)s - %(message)s"
logging_config = {
    "version": 1, # mandatory field
    # if you want to overwrite existing loggers' configs
    # "disable_existing_loggers": False,
    "formatters": {
        "basic": {
            "format": FORMAT,
        }
    },
    "handlers": {
        "console": {
            "formatter": "basic",
            "class": "logging.StreamHandler",
            "stream": "ext://sys.stderr",
            "level": LOG_LEVEL,
        }
    },
    "loggers": {
        "simple_example": {
            "handlers": ["console"],
            "level": LOG_LEVEL,
            # "propagate": False
        }
    },
}

import logging

# create logger
logger = logging.getLogger('simple_example')
# 'application' code
logger.debug('debug message')
logger.info('info message')
logger.warning('warn message')
logger.error('error message')
logger.critical('critical message')

What happens here is pretty simple. We are configuring a logger named simple_example with handler console that streams to standard output and uses a formatter named basic.

formatter says how the log output should look like
handler takes formatter and sends the log to defined destination
logger takes handlers(s) and passes logs to them. Logger can be called with getLogger(name)

So if you start to ask yourself. Yes. Either formatters or also handlers can be omitted. Then standard output and format are used.

Variant of above dict doc example in code looks like this :



import logging

# create logger
logger = logging.getLogger('simple_example')
logger.setLevel(logging.DEBUG)

# create console handler and set level to debug
ch = logging.StreamHandler()
ch.setLevel(logging.DEBUG)

# create formatter
formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')

# add formatter to ch
ch.setFormatter(formatter)

# add ch to logger
logger.addHandler(ch)

# 'application' code
logger.debug('debug message')
logger.info('info message')
logger.warning('warn message')
logger.error('error message')
logger.critical('critical message')

Usage in FastApi

Now we know everything necessary to implement logging into FastApi server. Let's start with the basic folder structure and files.



├── app
│   ├── core
│   │   └── log_config.py
│   ├── __init__.py
│   └── main.py
└── requirements.txt

I recon AVOIDING renaming log_config.py to logging.py as it can create some conflicts with the logging module

requirements.txt



# requirements.txt

fastapi
uvicorn

log_config.py



# log_config.py

# put one of 2 versions of config from above here
# you can choose whichever you like more

<code from abouve>

main.py



# main.py

import logging
from logging.config import dictConfig
from fastapi import FastAPI

from app.core.log_config import app_dict_config, init_loggers

# This should run as soon as possible to catch all logs
# Run only one of these
init_loggers()
# dictConfig(app_dict_config)

# FastApi app
app = FastAPI()

# init our logger
log = logging.getLogger("simple_example")

# first endpoint
@app.get("/log_now")
def log_now():
    log.debug("/api/log_now starts")
    log.info("I'm logging")
    log.warning("some warnings")

    return {"result": "OK"}

What happens here? We initiate loggers, start app and create logger log named simple_example. Then we create endpoint /log_now that surprisingly... just logs.

Let's install requirements.txt and start the app with uvicorn



# install requirements
pip install -r requirements.txt

# start uvicorn server on 127.0.0.1:8000
uvicorn app.main:app --reload

Then in another terminal run



curl localhost:8000/log_now

And you should see something like this

Almost perfect. We can now update the formatting to polish it. Any default LogRecords attributes can be used. But to have the same colorful formatting as uvicorn we need to use also its' formatter and its' formatting attribute %(levelprefix)s

Update your config:



# both variants:
FORMAT: str = "%(levelprefix)s %(asctime)s | %(message)s"

# dict variant:
app_dict_config = {
    # ...
    "formatters": {
        "basic": {
            "()": "uvicorn.logging.DefaultFormatter",
            "format": FORMAT,
        }
    # ...
    }
}

# code variant:
def init_loggers(logger_name: str = "simple_example"):
    #...
    # create formatter
    formatter = uvicorn.logging.DefaultFormatter(FORMAT)
    # ...

For last but not least we can change the date format with:



# dict
            "datefmt": "%Y-%m-%d %H:%M:%S",

#code
    formatter = uvicorn.logging.DefaultFormatter(FORMAT, datefmt="%Y-%m-%d %H:%M:%S")

Voilà

What configuration or libs do you use for logging in Python? Or you miss anything important. Let me know in comments. Also this is my first "blog" so any feedback is appretiated :)

In the next episodes, we'll take a better look at how to get our logs into Azure AppInsights, trace requests, visualize them, and more...