Previously, I wrote about setting up fail2ban to protect your server from malicious attacks and brute-force attempts, which works quite well. However, there is a better alternative: CrowdSec. CrowdSec is an open-source, collaborative security engine that detects and blocks malicious behavior using shared threat intelligence. Unlike traditional fail2ban-style tools, it crowdsources attack patterns across its entire user base, which means your server benefits from bans triggered by attacks on other machines worldwide.

This guide walks through a full production setup on the Ubuntu 22.04 LTS operating system, which should also work on other systems.

Prerequisites

• A server running Ubuntu or any other operating system
• sudo access
• nftables installed (sudo apt install nftables -y)
• Grafana Prometheus for monitoring section
• A Telegram account (for the optional notification section)

1. Installing CrowdSec

CrowdSec provides an official repository script that handles APT source registration:

# Add the CrowdSec repository
curl -s https://install.crowdsec.net | sudo bash

# Install the agent
sudo apt update && sudo apt install crowdsec -y

Verify the service is running:

sudo systemctl status crowdsec
sudo cscli version

Note: On first install, CrowdSec runs a detection wizard (wizard.sh) that scans your running services and pre-populates the log acquisition config. You can find the log acquisition config from this location and configure it as per your use case /etc/crowdsec/acquis.yaml

2. Enrolling into the CrowdSec Security Engine

Enrollment links your local agent to the CrowdSec Console, giving you access to the shared blocklist network, centralized alert management and remote decision control.

Steps:

1. Create a free account at app.crowdsec.net
2. Navigate to Engines → Enroll and copy your enrollment key
3. Run on your server:

sudo cscli console enroll <YOUR_ENROLLMENT_KEY>

1. Restart CrowdSec:

sudo systemctl restart crowdsec

Go back to the Console and accept the engine from the UI.

Once accepted, your instance appears under Engines with a green status. You can now install their blocklists from the UI and manage decisions remotely.

3. Installing the Firewall Bouncer

Now that you have your security engine running, it’s time to install the remediation component. The remediation component is primarily responsible for blocking threat actors. One great thing about CrowdSec is that you can choose which type of remediation component you want. For example, if you want to ban an IP from your firewall, you can use cs-firewall-bouncer. If you want to restrict the IP from your Nginx server, then you will install cs-nginx-bouncer, and there are many more options. Here, we will use the nftables-compatible cs-firewall-bouncer.

sudo apt install crowdsec-firewall-bouncer-nftables -y

Enable and start it:

sudo systemctl enable --now crowdsec-firewall-bouncer

Confirm the bouncer registered with the agent:

sudo cscli bouncers list

Warning: Ensure the nf_tables kernel module is loaded before starting the bouncer: sudo modprobe nf_tables

4. Installing Collections

Collections bundle parsers and detection scenarios for specific services. Install the ones matching your environment:

# Core service collections
sudo cscli collections install crowdsecurity/nginx
sudo cscli collections install crowdsecurity/sshd
sudo cscli collections install crowdsecurity/mysql
sudo cscli collections install crowdsecurity/linux

# Optional but recommended
sudo cscli collections install crowdsecurity/http-cve
sudo cscli collections install crowdsecurity/iptables

Activate the configuration change:

# Reload to activate new parsers and scenarios
sudo systemctl reload crowdsec

Verify what’s installed:

sudo cscli collections list

The output should show something like below:

Tip: There’s a lot of already developed collections by their community out there. You can search the available collections on their console and then install it with the mentioned command.

5. Configuring Log Acquisition

CrowdSec reads logs via /etc/crowdsec/acquis.yaml. While the wizard generates this automatically, you should review and modify it based on your specific use cases. For example, if your Nginx logs are stored in a custom location rather than /var/log/nginx/error.log, you must update the configuration accordingly. Below is a sample illustrating the structure of an acquis.yaml file:

# /etc/crowdsec/acquis.yamlfilenames:
  - /var/log/nginx/access.log
  - /var/log/nginx/error.log
labels:
  type: nginx
---
# SSH auth logs
filenames:
  - /var/log/auth.log
labels:
  type: syslog
---
# MySQL error log
filenames:
  - /var/log/mysql/error.log
labels:
  type: mysql
---
# General syslog and kernel log
filenames:
  - /var/log/syslog
  - /var/log/kern.log
labels:
  type: syslog

After any changes don’t forget to reload crowdsec:

sudo systemctl reload crowdsec

Use sudo cscli metrics to confirm log files are being tailed. Zero parsed lines typically means a missing collection or wrong type label.

6. Whitelisting IPs with cscli allowlist

CrowdSec newer versions include a native allowlist command to permanently exempt IPs or CIDRs from bans. It is useful for your own infrastructure, monitoring tools or trusted partners. My recommendation is always whitelist your own IPs so that you don’t get accidentally banned and blocked out of your own server.

Create an allowlist:

sudo cscli allowlists create my_allowlist \
--description "Trusted internal and monitoring IPs"

Add IPs or CIDRs:

# Single IP example
sudo cscli allowlists add my_allowlist 192.168.1.10 \
  --comment "Internal monitoring"

# CIDR range example
sudo cscli allowlists add my_allowlist 10.0.0.0/8 \
  --comment "Private network range"

# Multiple IPs at once example
sudo cscli allowlists add my_allowlist \
  203.0.113.5 203.0.113.10 \
  --comment "Partner IPs"

Manage allowlists:

sudo cscli allowlists list
sudo cscli allowlists inspect my_allowlist
sudo cscli allowlists remove my_allowlist 203.0.113
sudo cscli allowlists delete my_allowlist

Allowlisted IPs are evaluated before any decision is applied and they will never be banned even if they trigger a scenario.

7. Configuring nftables as the Bouncer Backend

Edit the bouncer config at /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml:

mode: nftables
update_frequency: 10s
log_mode: file
log_dir: /var/log/
log_level: info
log_compression: true
log_max_size: 100
log_max_backups: 3
log_max_age: 30
api_url: http://127.0.0.1:8080/
api_key: <BOUNCER_API_KEY>
insecure_skip_verify: false
disable_ipv6: false
deny_action: DROP
deny_log: false
supported_decisions_types:
  - ban
blacklists_ipv4: crowdsec-blacklists
blacklists_ipv6: crowdsec6-blacklists
ipset_type: nethash

## nftables
nftables:
  ipv4:
    enabled: true
    set-only: false
    table: crowdsec
    chain: crowdsec-chain
    priority: -10
  ipv6:
    enabled: true
    set-only: false
    table: crowdsec6
    chain: crowdsec6-chain
    priority: -10

nftables_hooks:
  - input
  - forward

# packet filter
pf:
  # an empty string disables the anchor
  anchor_name: ""

The bouncer API key is auto-generated on install. To retrieve or regenerate it:

sudo cscli bouncers list

Regenerate it if needed:

# Regenerate if needed
sudo cscli bouncers delete crowdsec-firewall-bouncer
sudo cscli bouncers add crowdsec-firewall-bouncer

Restart the bouncer and verify nftables rules:

sudo systemctl restart crowdsec-firewall-bouncer
sudo nft list ruleset | grep crowdsec

Warning: If you’re running both iptables and nftables, use the iptables-nft backend to avoid rule conflicts: sudo update-alternatives --set iptables /usr/sbin/iptables-nft

8. Prometheus + Grafana Integration

CrowdSec exposes a Prometheus metrics endpoint out of the box with no extra plugins.

Enable Prometheus in CrowdSec

Confirm or add the following in /etc/crowdsec/config.yaml:

prometheus:
  enabled: true
  level: full
  listen_addr: 127.0.0.1
  listen_port: 6060

Reload and test:

sudo systemctl reload crowdsec
curl -s http://127.0.0.1:6060/metrics | head -20

Configure Prometheus to Scrape CrowdSec

Add a scrape job to your prometheus.yml:

scrape_configs:
  - job_name: 'crowdsec'
    static_configs:
      - targets: ['localhost:6060']
    scrape_interval: 30s

Reload Prometheus:

sudo systemctl reload prometheus
# Or via the HTTP API if enabled:
curl -X POST http://localhost:9090/-/reload

Import the Grafana Dashboard

1. In Grafana, go to Dashboards → Import
2. Use dashboard ID 21419 (Crowdsec Metrics)
3. Select your Prometheus datasource and click Import
4. You can also import dashboards from their official github repository here: Crowdsec Grafana Dashboards

Key metrics to monitor:

cs_active_decisions Current active bans

cs_alerts_total Total scenarios triggered

cs_lapi_requests_total Bouncer polling activity

cs_parser_hits_total Log lines processed

9. Telegram Notification Integration

CrowdSec’s HTTP notification plugin can POST alerts to any webhook, including Telegram’s Bot API. Alerts include inline buttons linking the offending IP to Shodan and the CrowdSec CTI.

Step 1: Create a Telegram Bot

1. Open Telegram and search for @BotFather
2. Send /newbot and follow the prompts — save your bot token
3. Add the bot to your target group or channel
4. Get the chat ID:

curl -s https://api.telegram.org/bot<BOT_TOKEN>/getUpdates \
  | python3 -m json.tool | grep '"id"'

Group chat IDs are negative integers (e.g., -123456789).

Step 2: Configure the Plugin

Create /etc/crowdsec/notifications/http_tg.yaml:

# Author: Nirjas Jakilim
type: http
name: http_tg
log_level: info

format: |
  {
   "chat_id": "-YOUR_CHAT_ID",
   "text": "
     {{range . -}}
     {{$alert := . -}}
     {{range .Decisions -}}
     {{if $alert.Source.Cn -}}
  Scenario: {{.Scenario}}
  IP: {{.Value}}
  Ban Duration: {{.Duration}}
  Country: {{$alert.Source.Cn}}
  AS Name: {{$alert.Source.AsName}}
    {{end}}
     {{if not $alert.Source.Cn -}}
  Scenario: {{.Scenario}}
  IP: {{.Value}}
  Ban Duration: {{.Duration}}
  Country: Unknown
    {{end}}
     {{end -}}
     {{end -}}
   ",
   "reply_markup": {
      "inline_keyboard": [
          {{ $arrLength := len . -}}
          {{ range $i, $value := . -}}
          {{ $V := $value.Source.Value -}}
          [
              {
                  "text": "See {{ $V }} on shodan.io",
                  "url": "https://www.shodan.io/host/{{ $V }}"
              },
              {
                  "text": "See {{ $V }} on crowdsec.net",
                  "url": "https://app.crowdsec.net/cti/{{ $V }}"
              }
          ]{{if lt $i ( sub $arrLength 1) }},{{end }}
          {{end -}}
      ]
    }
  }
url: https://api.telegram.org/bot<BOT_TOKEN>/sendMessage
method: POST
headers:
  Content-Type: "application/json"

Step 3: Add Notifications in profiles.yaml

Edit /etc/crowdsec/profiles.yaml to attach http_tg to your remediation profiles:

# Skip re-banning IPs that already have an active decision
name: silence_ip_remediation
filters:
  - Alert.Remediation == true && Alert.GetScope() == "Ip" && GetActiveDecisionsCount(Alert.GetValue()) > 0
on_success: break
---
# Default IP ban — 500h with Telegram notification
name: default_ip_remediation
filters:
  - Alert.Remediation == true && Alert.GetScope() == "Ip"
decisions:
  - type: ban
    duration: 500h
notifications:
  - http_tg
on_success: break
---
# Range ban — 500h with Telegram notification
name: default_range_remediation
filters:
  - Alert.Remediation == true && Alert.GetScope() == "Range"
decisions:
  - type: ban
    duration: 500h
notifications:
  - http_tg
on_success: break

Step 4: Reload and Test

sudo systemctl reload crowdsec

Send a test notification:

# Send a test notification
sudo cscli notifications test http_tg

If the test fails, check /var/log/crowdsec/crowdsec.log for plugin errors. Common issues: wrong chat ID format, bot not added to the group, or malformed JSON in the format template.

If everything is alright the alert notifications will be like as below

Verifying the Full Stack

Once everything is configured, run these commands to confirm each layer is working:

# Agent status and active decisions
sudo cscli decisions list
sudo cscli alerts list

# Bouncer is enforcing bans
sudo nft list ruleset | grep crowdsec

# Metrics endpoint alive
curl -s http://127.0.0.1:6060/metrics | grep cs_active

# All services healthy
sudo systemctl status crowdsec crowdsec-firewall-bouncer

Conclusion

You now have a fully operational CrowdSec stack: the agent parsing logs from nginx, SSH, MySQL, and syslog, the nftables bouncer enforcing bans at the kernel level, IP allowlists protecting trusted sources, Prometheus and Grafana providing observability and Telegram delivering real-time alerts with one-click threat investigation links.

Because CrowdSec is collaborative, every ban your instance issues contributes back to the shared blocklist making the network stronger for everyone.

The moment you expose your server to the internet with a public IP, if you check the /var/log/auth.log file, you will be in a complete panic within a moment. Numerous bots and attackers will start brute-forcing your server to gain access. This is very alarming if your server is not protected with proper SSHD hardening, as attackers might compromise your system at any moment. Fortunately, there is an exact sshd_config hardening process you can apply to every new server to make brute-force attacks a non-issue. Here are nine straightforward steps to lock down your server.

Warning: Always keep a backup SSH window open for your server. Never forget to test the configuration with the sshd -t command before applying changes to avoid getting locked out.

1. Change the Default Port

The single biggest drop in noise. Automated scanners and attackers almost exclusively target port 22. So, if you move to a high, non-standard port that will eliminate almost ~99% of bot traffic overnight.

# /etc/ssh/sshd_config
Port 2222 # Pick anything from 1024–65535

Remember to update your firewall rules and use ssh -p <your_port> user@host going forward.

2. Disable Root Login

Never allow direct root SSH access. That’s like opening your server’s main door to the attackers. If an attacker gets in, they can do almost anything on your servers. You may want them to at least need to escalate privileges separately. Always log in as a regular user and then use sudo.

PermitRootLogin no

If you still really need direct root ssh login then you can use the config mentioned below to strictly enforce key based login for the root user

PermitRootLogin prohibit-password

Tip: Always confirm you have sudo access before disabling root login.

3. Enforce Key-Based Authentication (No Passwords)

Password auth is a significant attack surface. So, you should kill it entirely. SSH keys are the minimum bar. Then you can also pair with a strong passphrase on the key itself. You can apply the following settings to enforce strict key based access on your server and restrict password based logins.

PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
ChallengeResponseAuthentication no
UsePAM yes

What is does?

PasswordAuthentication no completely disable password based authentication

PubkeyAuthentication yes only allowed key based authentication

AuthenticationMethods publickey enforce key based authentication method only

ChallengeResponseAuthentication no disables keyboard interactive authentication

UsePAM yes enables pluggable authentication module

4. Restrict Which Users Can SSH

Whitelist the exact users (or groups) that need SSH access. It can significantly reduce the attack surface since only users you explicitly allow can now login. Everyone else is denied at the sshd level even if they have valid credentials.

AllowUsers <your_username_here> <anotheruser>

Or by group:

AllowGroups sshusers

If you use the AllowGroups directive then you can add any user to the sshusers group

sudo usermod -aG sshusers <youruser>

5. Limit Authentication Attempts per Connection

Reduce how many tries an attacker gets before the connection is dropped.

MaxAuthTries 3
LoginGraceTime 20
MaxStartups 10:30:60

What it does?

MaxAuthTries 3 will drop the connection after the failure attempt count reach to 3

LoginGraceTime 20 will disconnect if not authenticated within 20 seconds

MaxStartups will throttle unauthenticated connection attempts

6. Disable Features You Don’t Use

Every enabled feature is a potential attack vector. Disable anything you don’t actively need.

X11Forwarding no
AllowTcpForwarding no # unless you need SSH tunneling
AllowAgentForwarding no
PermitTunnel no
GatewayPorts no
PermitEmptyPassword no
IgnoreRhosts yes

7. Enforce Strong Ciphers and Key Exchange Algorithms

Strip out legacy ciphers. Attackers can downgrade your connection to weak crypto if you leave old algorithms enabled.

KexAlgorithms curve25519-sha256,diffie-hellman-group16-sha512
Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
MACs hmac-sha2–256-etm@openssh.com,hmac-sha2–512-etm@openssh.com
HostKeyAlgorithms ssh-ed25519,rsa-sha2–512

8. Use tools like fail2ban or Crowdsec

Even with all the above, bots will keep trying. fail2ban watches your auth logs and auto-bans IPs after repeated failures. Pair it with the custom port from tip #1.

If you need to setup fail2ban then I have covered it in a separate article here: Guide to Secure Your Self-Hosted Stacks like Nginx, SSH, & Vaultwarden with Fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2222    # Mention your ssh port here
filter   = sshd
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s
maxretry = 3
bantime = 3600 # ban for 1 hour. You can also increase it
findtime = 600

About crowdsec I will cover it on a separate article.

9. Restrict SSH Access at the Firewall Level

If you connect from a static IP or a VPN, whitelist that IP in your firewall. This is the hardest gate of all, the port never even responds to unauthorized sources.

# UFW example
ufw allow from 203.0.113.10 to any port 2222

# iptables example
iptables -A INPUT -p tcp — dport 2222 -s 203.0.113.10 -j ACCEPT
iptables -A INPUT -p tcp — dport 2222 -j DROP

Apply the Changes

Always test your config before reloading because one syntax error locks you out:

sudo sshd -t

If the above command didn’t show any error then run the following command to reload your sshd config

sudo systemctl reload sshd

Final Thoughts

None of these tricks is a silver bullet on its own, but defense in depth is the main goal. My standard stack for any new VPS:

• Move SSH off port 22
• Keys only, no passwords
• Whitelist users
• fail2ban or crowdsec watching auth logs
• Firewall IP allowlist if feasible

With all of this in place, brute-force attacks become background noise that you never have to think about again.

Setting up a shared file system across multiple virtual machines in the cloud can be tricky, but Oracle Cluster File System Version 2 (OCFS2) makes it straightforward. If you are running instances on Oracle Cloud Infrastructure (OCI) and need multiple VMs to read and write to the same block volume simultaneously, this guide will walk you through the process on Ubuntu.

Prerequisites

Before we begin the configuration, ensure you have the following infrastructure in place:

• Two Ubuntu VMs provisioned. For this guide, we will use server1 (IP: 10.0.1.85) and server2 (IP: 10.0.1.235) and server2 (IP: 10.0.1.235)
• A Block Volume created and attached to both VMs.
• The access type for the block volume must be set to Read/write — shareable.

Once these resources are ready, you can proceed to configure the cluster file system.

Step 1: Configure Security Rules

OCFS2 nodes need to communicate with each other over specific ports. You must update your OCI Virtual Cloud Network (VCN) security lists to allow internal traffic.

Allow TCP communication on ports 7777 and 3260. Add the following ingress rules for your private subnet (e.g., 10.0.1.0/24):

Source: 10.0.1.0/24 | IP Protocol: TCP | Destination Port: 7777

Source: 10.0.1.0/24 | IP Protocol: TCP | Destination Port: 3260

To verify the connectivity between the VMs, run the following netcat commands from one VM to the other:

nc -vz 10.0.1.85 3260;
nc -vz 10.0.1.85 7777

Note: If your security rules are correct, the connection will show as “refused” because the cluster services are not running yet. This is expected. Do the same thing from the other VM with your server2 ip.

Step 2: Install OCFS2 Packages

Log into both VMs and install the necessary OCFS2 tools. Run the following command on both machines:

sudo apt update && sudo apt upgrade -y;
sudo apt install ocfs2-tools-dev ocfs2-tools -y

Step 3: Define the Cluster

Next, we need to create the cluster definition using the o2cb utility. This will generate the /etc/ocfs2/cluster.conf file if it doesn't already exist.

Run the following command on both VMs to create a cluster named ociocfs2:

sudo o2cb add-cluster ociocfs2

Now, add your nodes to the cluster. Run these commands on both VMs:

sudo o2cb add-node ociocfs2 server1 --ip 10.0.1.85;
sudo o2cb add-node ociocfs2 server2 --ip 10.0.1.235

You can verify the configuration by checking the .conf file:

sudo cat /etc/ocfs2/cluster.conf

The output should list your cluster name, the heartbeat mode, and the details for both nodes.

cluster:
        name = ociocfs2
        heartbeat_mode = local
        node_count = 2

node:
        cluster = ociocfs2
        number = 0
        ip_port = 7777
        ip_address = 10.0.1.85
        name = server1

node:
        cluster = ociocfs2
        number = 1
        ip_port = 7777
        ip_address = 10.0.1.235
        name = server2

Step 4: Attach the Block Volume via iSCSI

You need to run the iSCSI commands provided in your OCI console to attach the block volume at the OS level. To get the commands, go to you cloud console’s storage>block volume and then click on your block volume name. There’s on the attached instances click on the 3 dot menu of your each instance’s section. You can get there the attach and detach commands.

On server1:

sudo iscsiadm -m node -o new -T iqn.2015-12.com.oracleiaas:5f2a1b82-9c40-4e1a-8b3d-72f6a5b9c1e4 -p 169.254.2.2:3260;
sudo iscsiadm -m node -o update -T iqn.2015-12.com.oracleiaas:5f2a1b82-9c40-4e1a-8b3d-72f6a5b9c1e4 -n node.startup -v automatic;
sudo iscsiadm -m node -T iqn.2015-12.com.oracleiaas:5f2a1b82-9c40-4e1a-8b3d-72f6a5b9c1e4 -p 169.254.2.2:3260 -l

On server2:

sudo iscsiadm -m node -o new -T iqn.2015-12.com.oracleiaas:5f2a1b82-9c40-4e1a-8b3d-72f6a5b9c1e4 -p 169.254.2.3:3260;
sudo iscsiadm -m node -o update -T iqn.2015-12.com.oracleiaas:5f2a1b82-9c40-4e1a-8b3d-72f6a5b9c1e4 -n node.startup -v automatic;
sudo iscsiadm -m node -T iqn.2015-12.com.oracleiaas:5f2a1b82-9c40-4e1a-8b3d-72f6a5b9c1e4 -p 169.254.2.3:3260 -l

Once attached, identify the device path of your new volume:

sudo fdisk -l

Look for a pattern like /dev/sdb. whose size exactly match your created block volume’s size. That should be your target device. For the remainder of this guide, we will assume the device is /dev/sdb.

Step 5: Format and Sync the Partition

Start the cluster services before creating the partition:

sudo systemctl start ocfs2;
sudo systemctl start o2cb

Now, format the partition on only one machine:

sudo mkfs.ocfs2 -L "ocfs2" /dev/sdb

This will initialize the superblock, format the journals, and establish the cluster stack. Once it says mkfs.ocfs2 successful, the formatting is complete.

To ensure the partition table is updated across your environment, run the following sync command on both VMs:

sudo blockdev --rereadpt /dev/sdb

Step 6: Final Configuration and Mounting

Reconfigure the cluster tools on both VMs by running:

sudo dpkg-reconfigure ocfs2-tools

When prompted, provide the exact cluster name you defined earlier (ociocfs2).

To ensure the drive mounts automatically on boot, add the following line to your /etc/fstab file:

Plaintext

/dev/sdb /data ocfs2 _netdev,defaults 0 0

You also need to configure the kernel for cluster operation so the changes persist across reboots. Add these entries to your /etc/sysctl.conf file:

# Define panic and panic_on_oops for cluster operation 
kernel.panic=30
kernel.panic_on_oops=1

Ensure the /data target directory exists on both VMs. Then, run the mount command on only one node:

sudo mount -a

If everything is configured correctly, the volume should now be mounted on both nodes automatically.

You can verify the mount point on your instances using df -hT:

Bash

nirzak@server1:~$ df -hT | grep data
/dev/sdb      ocfs2  106G  2.2G  104G   3% /data

nirzak@server2:~$ df -hT | grep /data
/dev/sdb      ocfs2  106G  2.2G  104G   3% /data

Troubleshooting & Expanding the Cluster

• Module Errors: If you encounter a module error during setup, you may need to install the Oracle-specific Linux modules. Run: sudo apt install linux-modules-extra-$(uname -r)
• Adding New Nodes: If you need to make changes to your nodes or add new ones to the cluster configuration later, you must unregister and re-register the cluster. Use the following commands:

sudo o2cb unregister-cluster <cluster_name>;
sudo o2cb register-cluster <cluster_name>

The restart both services,

sudo systemctl restart ocfs2 && sudo systemctl restart o2cb

After restarting the services, you can mount the file system to the new node with:

sudo mount.ocfs2 /dev/sdb /data

Don’t forget to replace /dev/sdb with your devices’s path and /data with your mountpoint’s path. That’s all for now. Your cluster file system should now be online. Try to copy file on one server’s directory and check if it appears on the second server or not. If it appears yourc cluster should be working fine.

If you are self-hosting services and expose them to public interfaces then you already know the anxiety of watching your server logs. The moment you expose port 22 (SSH) or 443 (HTTPS) to the internet, botnets and automated scripts begin knocking on your door. Whether they are brute-forcing your SSH credentials, probing Nginx for vulnerabilities, or trying to break into your Vaultwarden password manager, the noise is endless.

You can’t sit there and manually block IPs all day. You need an automated bouncer.

Enter Fail2ban.

Fail2ban is an intrusion prevention software framework that protects computer servers from brute-force attacks. It works by scanning log files (like /var/log/auth.log or Nginx access logs) and dynamically updating your firewall rules to ban IPs that show malicious signs.

In this guide, we’ll walk through setting up a robust Fail2ban configuration tailored for a modern self-hosted stack featuring SSH, Nginx, and Vaultwarden.

Step 1: Installation

First, let’s get Fail2ban installed. On a Debian/Ubuntu-based system, you can install it via apt:

sudo apt update
sudo apt install fail2ban
sudo systemctl enable fail2ban

Tip: Never edit the default /etc/fail2ban/jail.conf file directly. Package updates will overwrite it. Instead, we create a .local file, which Fail2ban reads to override the defaults.

Step 2: Defining the Jails (jail.local)

A “jail” in Fail2ban is essentially a rule. It tells the service which log file to watch, which filter (regex) to use, and what the punishment should be.

Create a new file at /etc/fail2ban/jail.local and paste in the following configuration:

[sshd]
# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
enabled  = true
port     = ssh
filter   = sshd
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s

[vaultwarden]
enabled  = true
port     = 80,443,8081
backend  = pyinotify
filter   = vaultwarden
banaction = %(banaction_allports)s
logpath  = /opt/vaultwarden/vw-logs/access.log
maxretry = 3
bantime  = 1h
findtime = 10m

[nginx-http-auth]
enabled  = true
port     = http,https
logpath  = %(nginx_error_log)s
filter   = nginx-http-auth
maxretry = 3
bantime  = 1h
findtime = 10m

[nginx-bad-status]
enabled  = true
port     = http,https
logpath  = %(nginx_access_log)s
filter   = nginx-bad-status
maxretry = 15
bantime  = 10w
findtime = 10m

[nginx-botsearch]
enabled  = true
port     = http,https
logpath  = %(nginx_error_log)s
filter   = nginx-botsearch
maxretry = 2

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
banaction = %(banaction_allports)s
bantime  = 4w
findtime = 1d

Note: Don’t forget to change the vaultwarden logpath /opt/vaultwarden/vw-logs/access.log according to your server’s log path.

What’s happening here?

• [sshd]: The standard SSH protection. We are keeping it enabled to prevent basic brute-force ssh attacks.
• [vaultwarden]: Protects our password manager. It watches all relevant web ports and uses banaction_allports to completely lock out an offending IP across all services. If someone fails a login 3 times in 10 minutes, they are banned for an hour.
• [nginx-*]: These jails protect the web server. They handle failed HTTP authentications, aggressive bot searches and excessive "bad" HTTP status codes (like 404s or 403s).
• [recidive]: The ultimate ban-hammer. This jail actually monitors Fail2ban's own log file. If an IP gets banned multiple times by other jails within a day, the recidive jail steps in and slaps them with a massive 4-week ban.

Step 3: Creating Custom Filters

Jails rely on filters to know what a “failed” attempt looks like. While Fail2ban comes with default filters for SSH and basic Nginx auth, we need to create custom filters for our specific Vaultwarden setup and our Nginx bad-status rules.

Filters are stored in /etc/fail2ban/filter.d/.

1. The Vaultwarden Filter

Create a file at /etc/fail2ban/filter.d/vaultwarden.local:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

This simple regex specifically targets the exact string Vaultwarden outputs to its log file when a login fails, capturing the offender’s IP address (<ADDR>).

2. The Nginx Bad Status Filter

Create a file at /etc/fail2ban/filter.d/nginx-bad-status.conf:

[Definition]
# Match standard log format - handles both normal HTTP requests and malformed requests (hex)
failregex = ^<HOST> .* "\S+ [^"]*" (?:400|401|403|404|405|444) \d+ ".*" ".*"$
            ^<HOST> .* ".*" (?:400|401|403|404|405|444) \d+ ".*" ".*"$

# Ignore common legitimate 404s
ignoreregex = ^<HOST> .* "GET (?:/favicon\.ico|/robots\.txt|/sitemap\.xml).* 404 \d+ ".*" ".*"$

# Define the timestamp pattern in your logs
datepattern = %%d/%%b/%%Y:%%H:%%M:%%S %%z

This is an incredibly useful filter. Scanners constantly hit servers with malformed requests or search for hidden directories, generating 4xx errors. This catches them while safely ignoring harmless requests for missing favicons or robots.txt files.

Step 4: Start the Engine

With your configurations and filters in place, it’s time to start Fail2ban and let it do its job.

Restart the service to apply the new configurations:

sudo systemctl restart fail2ban

You can check the status of your jails at any time using:

sudo fail2ban-client status

To see the details of a specific jail (like who is currently banned):

sudo fail2ban-client status vaultwarden

Conclusion

Fail2ban is a lightweight, incredibly effective tool for keeping the noise out of your server. By combining service-specific jails like Vaultwarden with broad-stroke protections like Nginx bad-status and the long-term recidive ban, you drastically reduce the attack surface of your self-hosted infrastructure.

Set it, forget it and enjoy the peace of mind. There’s also another great tool to use as a complete firewall solution for your servers and that is crowdsec. I will write a separate guideline for that one later.

Out of the box, Nginx is incredibly fast and efficient but it isn’t inherently secure against modern automated attacks like scanners, scraping bots and most sophisticated brute force attacks. Over time, I’ve set up a modular approach to hardening my Nginx setups. By splitting the security configurations into multiple logical files, it becomes much easier later to maintain, audit, and apply them across multiple virtual hosts.

In this guide, I’ll walk you through the essential configurations that will significantly improve your server’s security. Please note before jumping to the main article. You will need to install nginx-module-headers-more module for the more_set_headers directive to work.

1. Global Security Settings

This configurations will cover server-wide settings, masking the server identity and filtering out malicious traffic before it even reaches your application.

By leveraging Nginx’s map module, we can identify path traversal attempts, unauthorized bot scanners, and cloud metadata SSRF attempts efficiently without cluttering our server blocks with heavy conditional arguments.

# Hide Nginx version
server_tokens off;

# Mask the server name (Note: requires the headers-more-nginx-module)
more_set_headers "Server: AnyNameHere";

# Identify sesitive paths URIs
map $request_uri $bad_request {
    default 0;
    "~*wp-admin" 1;
    "~*(?:phpunit|phpinfo|phpmyadmin|php-?my-?admin|administrator|wp|wordpress)" 1;
    "~*(?:/\.env|\.git|\.svn|\.hg|\.DS_Store|\.idea|\.htaccess|\.htpasswd)" 1;
    "~*(?:etc/passwd|proc|\/\/)+" 1;
    # Path traversal attempts (e.g., ../../etc/passwd)
    "~*(?:\.\./|\.\.\\x5c)" 1;
    # Cloud Metadata SSRF attempts
    "~*(?:169\.254\.169\.254)" 1;
    # Block direct access to common script/backup extensions remove it if you actually want to host this extension files on your server
    "~*(?:\.sh|\.bash|\.bak|\.sql|\.tar|\.gz|\.zip)$" 1;
}
# Identify malicious automated scanners and bots
map $http_user_agent $bad_user_agent {
    default 0;
    "~*havij|nikto|scan|loader|fetch|acunetix|sonic|nessus|sqlmap|zgrab|masscan|nmap|dirb|gobuster|shodan|censys|wpscan" 1;
}
# Combine the conditions
map "$bad_request$bad_user_agent" $is_bad_request {
    default 0;
    "~*1" 1;
}

# Global rate limiting settings for DDos Protection. Change the limits according to your needs
limit_req_zone $binary_remote_addr zone=ratelimit:10m rate=20r/s;

How to apply it: Save the above configuration as security-global.conf file inside /etc/nginx/snippets directory. Include this file inside your main http {} block in nginx.conf. Like as below,

include /etc/nginx/snippets/security-global.conf;

Then, to actually drop the malicious traffic, add this simple check inside your server {} blocks of your main nginx configuration or on any blocks where you want to apply them.

if ($is_bad_request) {
    return 444; # Closes the connection immediately without a response
}

To apply the rate limiting setting add the following line on any of your server {} block of the main nginx configuration,

limit_req zone=ratelimit burst=20 nodelay;

2. Location-Specific Rules

Follow this section only if you want to restrict all the hidden files from being served through nginx cause they can be accidentally end up in your web root. Also, Text editors often leave backup files ending in ~ and version control systems leave hidden directories like .git. This file ensures they are never served to the public.

# Deny access to all hidden files and directories (starting with a dot)
location ~ /\. {
    deny all;
    access_log off;
    log_not_found off;
}
# Deny access to temporary editor files
location ~ ~$ {
    deny all;
}

How to apply it:

Save the above code block as security-location.conf file inside your /etc/nginx/snippets directory.

Then include the file inside your server {} block like below,

include /etc/nginx/snippets/security-location.conf;

Setting access_log off and log_not_found off can prevent your access log from being spammed. but still if you want them on your access log for security purposes then you can set it as access_log on.

3. HTTP Security Headers

This is the most crucial part. Injecting the right HTTP headers protects your users from Cross-Site Scripting (XSS), clickjacking, and MIME-type sniffing or various attacks. It reduces attack surfaces greatly. I have covered all the most important security headers except the content security policy header. Since that header need to be configured according to your application.

# Prevent clickjacking by restricting who can embed your site in an iframe
add_header X-Frame-Options "SAMEORIGIN" always;

# Force the browser's native XSS filter
add_header X-XSS-Protection "1; mode=block" always;

# Prevent MIME-sniffing (forces the browser to respect the declared content type)
add_header X-Content-Type-Options "nosniff" always;

# Control how much referrer information is passed to external sites
add_header Referrer-Policy "same-origin" always;

# Restrict access to device hardware (camera, microphone, location)
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

# Enforce HTTPS connections for a full year, including subdomains
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

How to apply it:

Save the file as /etc/nginx/snippets/security-headers.conf file. You can then include this file in your http {}, server {}, or even specific location {} blocks depending on which application you will need to apply those headers.

Wrapping Up

By splitting your security configurations into security-global.conf, security-location.conf and security-headers.conf, you can keep your main site configurations incredibly clean. Your typical virtual host file now only needs three simple include statements to achieve a robust baseline of security.

Note: Always remember to test your configuration before reloading the web server

nginx -t
systemctl reload nginx

Security is layered. While Nginx hardeing won’t fix vulnerable application code but dropping malicious traffic at the edge saves your backend resources and mitigates entire classes of common automated attacks.

As distributed systems become more complex, monitoring becomes crucial for maintaining application performance and reliability. If you’re using Hazelcast as your in-memory data grid, you’ll want to keep a close eye on its performance metrics. Today, I’ll walk you through setting up JMX exporter to monitor Hazelcast metrics effectively.

Why Monitor Hazelcast Metrics?

Before diving into the setup, let’s understand why monitoring Hazelcast is essential. Hazelcast provides valuable insights into:

• Memory usage and distribution
• Network communication patterns
• Cache hit/miss ratios
• Queue sizes and processing times
• Connection health and latency

These metrics help you optimize performance, troubleshoot issues, and make informed scaling decisions.

Prerequisites

Before we start, make sure you have:

• Hazelcast instance (embedded or standalone)
• JMX Prometheus Exporter JAR file
• Basic understanding of JVM options and YAML configuration

Step 1: Enabling JMX API

The first step is enabling JMX (Java Management Extensions) on your Hazelcast instance. The process differs slightly between embedded and standalone deployments.

For Embedded Hazelcast

When running Hazelcast embedded within your application, add these JVM arguments to your application’s startup command:

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=<portNo>
-Dcom.sun.management.jmxremote.authenticate=false
-Dhazelcast.jmx=true
-javaagent:path_to_jmx_exporter_jar_file=<port>:/path_to_jmx_exporter_config/config.yaml

Important Security Note: Set -Dcom.sun.management.jmxremote.authenticate=true in production environments and configure proper authentication.

For Standalone Hazelcast

For standalone Hazelcast instances, navigate to your Hazelcast installation directory and edit the config/jvm.options file:

cd $HAZELCAST_HOME
vim config/jvm.options

Add the same JVM arguments mentioned above to this file.

Step 2: Configuring JMX Exporter

Create a configuration file (typically named config.yaml) for the JMX exporter. This file defines how JMX metrics are transformed into Prometheus format:

#---
attrNameSnakeCase: true
lowercaseOutputName: true
lowercaseOutputLabelNames: true
whitelistObjectNames:
  - "com.hazelcast:type=Metrics,*"

rules:
  - pattern: "^com.hazelcast<type=Metrics, instance=(.*), prefix=(.*), tag([0-9]+)=(.*)><>(.+):"
    name: hazelcast_$5
    attrNameSnakeCase: true
    labels:
      instance: $1
      prefix: $2
      tag$3: $4

  - pattern: "^com.hazelcast<type=Metrics, instance=(.*), prefix=(.*)><>(.+):"
    name: hazelcast_$3
    attrNameSnakeCase: true
    labels:
      instance: $1
      prefix: $2

• attrNameSnakeCase: Converts attribute names to snake_case format
• lowercaseOutputName: Ensures metric names are lowercase
• whitelistObjectNames: Filters JMX objects to include only Hazelcast metrics
• rules: Define patterns for transforming JMX metric names into Prometheus format

Step 3: Restart and Verify

After configuring everything, restart your Java application or Hazelcast instance. The metrics should become available at:

http://<server_ip>:<jmx_exporter_port>/metrics

Understanding the Metrics Format

Once everything is running, you’ll see metrics in Prometheus format. Here are some examples of the metrics:

hazelcast_total_max_get_latency{instance="hz-instance",prefix="map",tag0="name=request-cache"} 1.0
hazelcast_priority_queue_size{instance="hz-instance",prefix="operation"} 0.0
hazelcast_connection_type{instance="hazelcastInstance",prefix="tcp.connection",tag0="endpoint=[localhost]:5000",tag1="bindAddress=[testserver]:5000"} 1.0

Each metric includes:

• Metric name: Descriptive name of what’s being measured
• Labels: Key-value pairs like instance, prefix and tags
• Value: The actual measurement

Common Troubleshooting Tips

Based on my experience implementing this setup, here are some issues you might encounter:

Port Conflicts: Ensure your JMX and exporter ports don’t conflict with other services.

Configuration Path Issues: Double-check that the path to your config.yaml file is absolute and accessible.

Firewall Restrictions: Make sure the specified ports are open and accessible from your monitoring systems.

Memory Overhead: JMX monitoring adds some overhead, so monitor your application’s memory usage after enabling it.

Best Practices

1. Security First: Always enable authentication in production environments
2. Resource Monitoring: Keep an eye on the additional memory and CPU overhead
3. Selective Metrics: Use whitelist patterns to export only the metrics you need
4. Regular Updates: Keep your JMX exporter version updated for better performance and security

Integration with Monitoring Stack

Once you have metrics exposed, you can integrate them with your existing monitoring stack:

• Prometheus: Configure Prometheus to scrape the metrics endpoint
• Grafana: Create dashboards to visualize Hazelcast performance
• AlertManager: Set up alerts for critical thresholds

Conclusion

Monitoring Hazelcast with JMX exporter provides valuable insights into your distributed cache performance. While the initial setup requires some configuration, the visibility you gain into your system’s behavior is invaluable for maintaining robust applications.

The key is starting simple and gradually expanding your monitoring scope as you understand which metrics matter most for your specific use case. Remember to balance comprehensive monitoring with system performance, and always prioritize security in production environments.

If you have already implemented this on your environment then I’d love to hear about your experiences and any additional tips you’ve discovered along the way! Thanks for your time!

When deploying Jenkins in a secure environment — like behind a corporate firewall or proxy, it’s often creates problems in plugin installations or updates. Because Jenkins fetches plugin metadata and files from dynamic CDN URLs, which makes it hard to whitelist exact endpoints on your proxy or firewall.

In this guide, I’ll walk you through how to faciliates jenkins plugin updates using a static URL, making it possible to fetch and install plugins without opening up your network to all of Jenkins’ CDNs.

The Problem

Jenkins plugin updates rely on URLs that resolve to CDNs or change frequently. In a restricted environment:

• Your Jenkins host may have no direct internet access.
• All outbound traffic must go through a proxy or firewall.
• Whitelisting all possible cdn endpoints is not feasible.

Solution: Generate your own update-center.json file, sign it with your own certificate, and serve it from a local or approved static host. Then configure Jenkins to use this static URL as the update site.

Step-by-Step Solution

Step 1: Prepare the update-center.json on Any Internet-Connected Machine

1. Clone the Nirzak/jenkins-update-center repo: (Thanks to lewark)

git clone https://github.com/Nirzak/jenkins-update-center.git
cd jenkins-update-center

2. Remove any existing certificates: (Skip this step if you want to use the repo certificate)

rm -rf rootCA/update-center.crt rootCA/update-center.key

3. Edit the mirrors.json file and replace the content with:

{   "jenkins": "https://archives.jenkins.io/" }

Here, I used archives.jenkins.io as the mirror. you can also use any other mirror url if you want. You need to allow the mirror url from your proxy or firewall.

4. Generate a new self-signed cert and key: (Not needed if you skipped step 2)

openssl genrsa -out rootCA/update-center.key 2048

openssl req -new -x509 -days 3650 -key rootCA/update-center.key -out rootCA/update-center.crt

5. Install required Python packages:

pip3 install -r requirements.txt

6. Generate the custom update-center.json file:

python3 generator.py

Your generated update-center.json will be available in the <current_directory>/updates/jenkins directory.

Step 2: Setup on Jenkins Host

1. Copy the generated update-center.json and update-center.crt to your Jenkins host.
2. Create the required directory:

mkdir -p ${JENKINS_HOME}/update-center-rootCAs

3. Move the cert file:

cp rootCA/update-center.crt ${JENKINS_HOME}/update-center-rootCAs

Step 3: Host the update-center.json

Use Python’s built-in HTTP server (or any simple web server to serve the file):

cd path/to/update-center.json
nohup python3 -m http.server 8000 &

This will serve the file at:

http://your-host:8000/update-center.json

Step 4: Configure Jenkins to Use the New Update Site

1. Open Jenkins UI.
2. Navigate to: Manage Jenkins → Manage Plugins → Advanced.
3. In the Update Site URL field, enter:

http://your-host:8000/update-center.json

Click Submit to save.

All done!

Now go to the Available or Updates tab under Manage Plugins, and you should be able to install or update any plugin if you allow the mirror url from your proxy or firewall. Now you don’t need to allow all the other cdn mirror urls from your proxy since it’s only using a static url.

Now, let’s get back to Github Action which itselft is a CI/CD solution. Github Actions allows a developer to automate worflows like issues, pull requests, commits, merging almost eveything within github. Now it can be creating a pull request, merging it, assigning someone into the pull request. In fact you can also set organization rules, for example, assign developer permissions etc using this feature.

Now let’s take a dive into the details of Github Action. Every Github Action is a workflow that consists of some core components like events, jobs, steps, actions, and runners. Let’s explore them in detail.

Workflow:

A workflow is a configurable automated process consisting of one or multiple jobs running parallelly triggered by events. They are typically declared in YAML files and reside inside .github/workflows directory of a GitHub repository.

Events:

Events are basically the defined triggers that start a workflow. For example: Creating a pull request, Pushing a commit into the repository, A defined scheduled cron time, Merging Pull requests etc can be an example of events.

Jobs:

Jobs are the executed tasks in a workflow that runs after an event is triggered. A workflow can have one or multiple jobs running in parallel.

Actions:

These are the most interesting things in a GitHub workflow. Actions are basically some particular tasks bound as a single package that you can use in any action workflow or you can also make your own.

Runner:

A runner is a series of tasks in a workflow that are executed in a single job. Every runner is responsible for executing a single job.

Setting Up A Basic Action Workflow:

Now let’s set up a basic action workflow to see how it works. To do that, let’s create a demo repository on GitHub.

1. Now inside that repository create a directory named .github and inside that .gihub directory create another directory workflow. So, basically it will be .github/workflows
2. Inside that .github/workflows directory create a yaml file named demo-workflow.yml
3. Copy the following yaml config into that file. (Courtesy of Github Docs)

name: GitHub Actions Demo
on: [push]
jobs:
 Explore-GitHub-Actions:
 runs-on: ubuntu-latest
 steps:
 — run: echo “🎉 The job was automatically triggered by a ${{ github.event_name }} event.”
 — run: echo “🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!”
 — run: echo “🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}.”
 — name: Check out repository code
 uses: actions/checkout@v3
 — run: echo “💡 The ${{ github.repository }} repository has been cloned to the runner.”
 — run: echo “🖥️ The workflow is now ready to test your code on the runner.”
 — name: List files in the repository
 run: |
 ls ${{ github.workspace }}
 — run: echo “🍏 This job’s status is ${{ job.status }}.”

4. Save it and then just push a random commit into that repository and see the workflow in action. Here, We have used [push] as a trigger, so it will trigger for every commit that has been pushed into that repository.

Now let’s elaborate on the above workflow in detail.

1. Here on the first line “name:” is basically the workflow name. You can set this to anything that resembles that workflow. If you omit “name:”, GitHub will set it to the workflow file path relative to the root of the repository.
2. In the next line “on:” is basically used for the trigger purpose. This is our event trigger. Here, we can use more event triggers like fork, created, and deleted and also particular events like pull_requests, issues etc. for example:

on:
  pull_request:
    types: [opened, reopened]

This will trigger an event whenever a pull request is created or reopened. Also, you can create multiple custom labels and use them as a trigger using the label’s name. For more action triggers take a look at this article: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

3. The third line is the jobs part. Here we will define our tasks that will run after the event gets triggered. Inside jobs, there’s a section titled “runs-on:” this is basically the environment where the tasks will be executed. In the above case, this is “ubuntu-latest”.

4. In the steps section, we have defined an “uses:” section. This is basically the action’s part. Here, you can use any pre-defined action workflow or make your own action workflow and then can use it by just mentioning the action name like this one actions/checkout@v3. Here, we are using checkout action workflow which basically clones our repo to a runner, so that we can further run tests on it, deploy it or perform any other tasks on the code.

So, guys that’s all for now. To learn more about github actions take a look into github’s official documentation about Github Actions here: https://docs.github.com/en/actions/learn-github-actions
Happy Automating!