Intro

Alpine Linux is popular for its simplicity and minimalism, especially in containers and lab environments. Most of the time, this works in your favor, until you run into name resolution issues that seem inconsistent or outright broken. One common example is resolving .local hostnames: DNS appears to work, but tools like ping or curl fail.

This post tries to explain why that happens, why it's expected behavior on Alpine, and how it differs from more full-featured Linux distributions.

Why .local is special, what is mDNS and why it works for you

The .local top-level domain is reserved for Multicast DNS (mDNS) and .local names are meant to be resolved via multicast on the local network, instead of querying a unicast DNS server. This is defined in RFC 6762 and implemented by tools like Avahi and Bonjour.

According to the Alpine documentation, name resolution is handled by musl libc, which only supports classic DNS by default. mDNS isn't integrated into the resolver stack unless additional components are explicitly configured.

As a result, .local hostnames aren't resolved automatically, even though they may work on other distributions where mDNS is integrated transparently.

On glibc-based systems, nss-mdns bridges this gap by wiring mDNS into the system resolver. Alpine doesn't have that option, because musl just doesn't support NSS at all.

Why tools behave differently

Tools like dig or nslookup send DNS queries directly to a DNS server, bypassing most resolver logic. If your DNS server has a .local zone configured, these tools will return valid answers.

Other tools, such as ping or curl, rely on the system resolver, which on Alpine doesn't integrate mDNS into name resolution, so lookups simply fail. The DNS server is never queried, which makes the behavior look confusing.

It's a resolver limitation by design.

Minimal environments make this more obvious

This behavior isn't unique to Alpine and also appears in minimal environments like BusyBox-based or scratch Docker images. As described by Nathan Peck, .local hostnames don't resolve inside such containers unless a full mDNS stack or a DNS forwarding workaround is added. Minimal images simply don't include the pieces needed for multicast name resolution.

Alpine fits into this category - small, efficient, and intentionally minimal. Cute, even, but won't hold your hand.

Key points

• .local isn't a regular DNS domain,
• Alpine Linux doesn't resolve .local via mDNS by default,
• nslookup working doesn't mean the system resolver will behave the same,
• avoid using .local for custom DNS zones if possible; just use something else instead, such as .test, .lab, .internal, .silly, .cute or whatever you want.

Conclusion

This thing may look like broken DNS, but it's just Alpine's resolver behaving as intended.

Alpine is small and minimal by design, a bit like a fox - quiet, efficient, and not interested in doing more than necessary.

For more articles, visit ozelot.fyi or subscribe this RSS channel - ozelot.fyi/rss.xml.

Intro

Soft ears, fluffy tails, and mischievous eyes... sometimes the cutest things in life are also the slyest. Today, we're taking a break from the usual tech stuff, curling up like a fox tail around a warm cup of curiosity, and diving into why this little creature deserves a standing ovation - and maybe even a little spot in your next daydream.

Image by Andreas Neumann from Pixabay

They glide silently through forests, leap lightly across snowy fields, and even around city streets, always alert, always curious. Young foxes tumble in play, chasing leaves, pouncing on shadows, learning the art of mischief. Adults move with elegant grace, balancing stealth and poise. Each flick of a tail, twitch of an ear, or tilt of a head is both functional and utterly charming. Urban foxes, despite human noise, keep their soft, wild poise.

They teach us patience, observation, and the beauty of subtle gestures. From their nose to the tip of their tail, foxes are amazing little animals. Even a quick look at them can feel like a playful wink. Watching them is like seeing a story come to life. They remind us that little magical moments can happen anytime, if we notice them.

Masters of Wit and Wisdom

Foxes are smart hunters with quick minds. In the snow, they can hear rodents moving under leaves or ice and jump very accurately to catch them. They use tricks like pretending to run away to lure prey closer, or they pounce quietly. Urban foxes adjust to human schedules, avoid cars, and find hidden food, showing they can learn and adapt.

Photo by Janice Carriger on Pexels

Foxes communicate using over 40 sounds: barks, screams, and chatters - each with a different meaning. They also use body language, tail movements, and ear positions to send signals. Foxes remember safe paths, hiding spots, and food locations, showing spatial intelligence.

They are patient, flexible, and opportunistic. Hunting combines timing, precision, and creativity. Every jump, sniff, and pounce shows planning and skill. Their intelligence is not just instinct. It involves observation, planning, and learning. Watching a fox hunt is like seeing a small, clever animal solving problems. Adorable, isn't it?

Fluff that steal your heart

Foxes have thick, warm, and fluffy fur. Their tails have multiple uses: keep the fox warm, help with balance while running, and are used to communicate with other foxes. Their cute paws are covered in fur, allowing quiet movement on snow or rough ground.

Foxes groom themselves regularly and often groom each other for social bonding. Young foxes start with thinner fur that thickens as they grow. Even ears and faces are covered in fur for warmth and sensory function. Urban foxes keep their coats in good condition despite city life.

Their tails, eyes, and ears also communicate their feelings and intentions. Seasonal shedding keeps them warm while preventing overheating. The fur is functional and also part of their appearance. It helps them move, stay safe, and interact with other foxes, and look cute.

Photo by David Gomez on Unsplash

Foxes are small, but their bodies are very well designed. Retractable claws let them walk quietly, jump precisely, and climb easily. Their ears move independently to catch even tiny sounds. Their eyes reflect light at night, giving them good night vision for hunting. Whiskers sense small changes in air, helping them move in tight spaces without bumping into things. Their snouts are long and sensitive, good for tracking prey or noticing danger. Tails are not just ultra fluffy - they help with balance, communication, and staying warm. Paws are soft but precise, letting them move silently on any surface.

Their body posture shows mood or intention without making noise. Urban foxes handle fences, stairs, and buildings easily. Every part of their body has a purpose. Paw pads, bones, and muscles are made for agility and stealth. Nature made foxes to be both survival experts and adorable little charmers. (Wildlife Online)

Tail tales and body language

Foxes communicate using gestures and body language - and their tails are very important. A curled tail can keep them warm or show they are happy. A flicking tail can mean excitement, irritation, or alertness. Their posture shows dominance, submission, curiosity, or readiness.

Ears, eyes, and snout positions add more information. Tails also help with balance during jumps. Curling the tail while sleeping keeps them warm. Twitching ears can warn of danger or show attention. Tail patterns can help identify different foxes. Small movements convey feelings or intentions. Foxes can communicate over distances without making noise. Urban foxes still use these signals even in cities. Their social intelligence works with hunting and survival skills. Every gesture shows thought, flexibility, and charm. (Wildlife Online)

Adapting to humans

Some foxes live in cities without losing their wild skills. Urban foxes move quietly through streets, parks, and alleys, always watching for humans and traffic. They learn human schedules to avoid danger and find food in trash, gardens, or leftover meals.

Image by David Gomez from Pixabay

Even near people, they keep natural behaviors - stopping, listening, and watching before moving forward. Young foxes learn by watching older foxes how to navigate the city. They use curiosity and caution to use city resources safely. Their movements stay agile, precise, and controlled. Being active at night helps them avoid humans and hunt quietly.

They keep sharp senses and hunting tricks, even in cities. Urban foxes are flexible with diet, timing, and social interaction. They still play, chase, and practice hunting skills. Watching them climb fences, squeeze through gaps, or jump over walls shows their skill. Urban foxes balance curiosity, caution, and stealth effectively. Each movement shows thought, skill, and awareness. (The Guardian) (Denver Parks & Recreation)

Foxes in culture and myth

The fox is known for sneaking into homes and getting away without being caught. Because of its cunning nature, this animal has acquired the image of trickster in a number of cultures. (Spirit Animal)

In European stories, the fox is seen as smart and tricky. It often outsmarts stronger animals or humans, teaching lessons along the way. People also link the fox to lying or sneaky behavior, and sometimes even to magic or supernatural powers. Its sharp senses and cleverness make it a symbol of guidance or hidden wisdom. Overall, the fox shows both cleverness and the risk of getting into trouble if you trust it too much. (Wikipedia)

In Japan, foxes are called kitsune. Kitsune are special because they can change shape, play tricks on humans, or protect villages. They are also considered sacred animals in Shinto, the traditional Japanese religion, often linked to the god Inari, who is connected with rice and prosperity.

Some kitsune can grow up to nine tails. Each tail shows how old and powerful the fox is. Usually, a kitsune grows a new tail every 100 years, gaining more wisdom, magical skill, and strength with each tail. Kitsune can be playful, mischievous, or romantic, teaching lessons about cleverness, planning, and emotions. (Bokksu)

Image by Cathe from Pixabay

Across cultures, foxes represent intelligence, strategy, and subtle power. Folklore mixes real fox behavior with imagination, creating magical, clever animals. Myths show that even small creatures can leave a big impact. Foxes continue to inspire creativity, storytelling, and wonder, proving that cunning, charm, and beauty often go together.

Misunderstood and hunted

Although most foxes cause no real harm, every year countless foxes are brutally killed by poachers (some call them hunters). Hunting takes away their playful lives. Foxes can't roam or play as they wish. (MDPI)

Imagine resting in your cozy den, ears twitching at every sound, when suddenly it's taken away, without knowing why. Or just wandering through the forest, when suddenly your paw tightens, then you realize you're trapped in a snare and you'll stay there for several hours before you bleed out... or maybe some idiot sets a pack of aggressive dogs on you and starts shooting while you run.

Millions of foxes live on fur farms. They are kept in tiny cages and they are killed just for fun fur. These foxes never feel the joy of running in snow. They never feel the thrill of jumping. They never feel the comfort of wrapping their fluffy tails around themselves. Bright eyes, clever paws, and twitching ears are replaced with sadness. They suffer from wounds, eye infections, and deformed paws, and killing methods like rectal electric shock are commonly used. (Humane World)

POV: You open your eyes, but all you see are wire bars. No forest, no snow, no space to run. Your paws press against cold metal, your tail has no room to curl around you. Days blur together in the cage - no play, no jumping, no joy. One day, rough hands take you out. Not for love, not for care, but only for your fur.

Photo by Brett Sayles on Pexels

Even urban foxes can be targeted for just existing. People forget foxes are smart and sensitive. They are playful, mischievous, and affectionate. Foxes deserve to curl up, chase, explore, and live freely. They should not suffer because of fear, greed, or misunderstanding. Watching a fox leap or flick its tail is magical. Every life lost takes some magic away. Foxes deserve care, love, and soft moments in the sun.

Why we can't resist them?

Foxes are like the ultimate combo of soft uwu-fluff and big-brain logic. They're smol hunters with 200 IQ, moving sleek and smooth like optimized Rust code. Every head tilt, ear twitch, or tail flick is basically an API call straight to your heart. They adapt everywhere - forests, snow, even urban jungles - without losing their wild kernel.

Watching a fox is like running a process full of cuteness threads: leap(), pounce(), sniff(). Each function call is pure joy, wrapped in mischief and charm. Even the tiniest gestures - twitchy ears, swishy tails, sparkly eyes - return values full of feels.

Image by Angela from Pixabay

Foxes are both real and mythic, like a program that compiles on the first try. They embody curiosity, elegance, and sly cleverness in one fluffy package. Their presence is magical, but also practical, like a well-written script that just works.

Every glance, jump, or sneaky move leaves logs in your memory you can't delete. They prove that intelligence + stealth + fluff = the ultimate soft fox energy uwu.

Don't you just wanna curl up next to one and let their vibe run in your background thread forever?

For more articles, visit ozelot.fyi or subscribe this RSS channel - ozelot.fyi/rss.xml.

Intro

If you're running a Linux server, protecting it from brute-force attacks is one of the first things worth setting up - and Fail2ban is the usual answer.

There's one catch on modern Debian, though. Since Debian 12, iptables is no longer installed by default, and Fail2ban's default action expects it. Without a firewall backend to talk to, Fail2ban will not be able to block any IPs - it will be useless with default configuration.

You can check it yourself:

fail2ban-client set sshd banip 198.51.100.42
nft list ruleset | grep 198.51.100.42
fail2ban-client set sshd unbanip 198.51.100.42

If nft returns nothing, the ban never reached the firewall.

In this guide we'll set up Fail2ban with nftables - the framework Debian already
ships - and add automatic reporting of blocked IPs to AbuseIPDB.

Why nftables when I have iptables?

You have two ways out of this. Install iptables and keep the legacy setup, or point
Fail2ban at the firewall your system is already running.

nftables has been the default framework since Debian 10. It unifies IPv4 and IPv6 filtering, replaces the four separate legacy tools with one, and sits underneath your system whether you use it directly or not. Installing iptables on top of it means adding a compatibility layer to work around a problem that doesn't need working around.

Of course, you can go ahead and install iptables, but in this guide we will focus on the cleaner and default choice for modern Debian.

Configuration

You have to install fail2ban. You can use apt or whatever:

apt install fail2ban

Set up jail

You need to make some changes in /etc/fail2ban/jail.conf.

You can adjust bantime, findtime, and maxretry to your needs, or leave the default values, which are usually sufficient.

Then, find the [sshd] section. You have to make them look like this:

" language="text">[sshd]

port = ssh
backend = systemd
action = nftables[name=SSH,port=ssh,protocol=tcp]
         abuseipdb[abuseipdb_category="18,22"]

Or if you don't want to use AbuseIPDB, leave the last line like this:

action = nftables[name=SSH,port=ssh,protocol=tcp]

Now fail2ban will use nftables to ban malicious addresses.

Set up AbuseIPDB

Create or edit /etc/fail2ban/action.d/abuseipdb.conf:

"); curl -sSf "https://api.abuseipdb.com/api/v2/report" \
  -H "Accept: application/json" \
  -H "Key: " \
  --data-urlencode "comment=$lgm" \
  --data-urlencode "ip=" \
  --data "categories="

[Init]
abuseipdb_apikey = "your-abuseipdb-apikey-here"
" language="text">[Definition]
actionban = lgm=$(printf '%%.1000s' ""); curl -sSf "https://api.abuseipdb.com/api/v2/report" \
  -H "Accept: application/json" \
  -H "Key: " \
  --data-urlencode "comment=$lgm" \
  --data-urlencode "ip=" \
  --data "categories="

[Init]
abuseipdb_apikey = "your-abuseipdb-apikey-here"

You can generate your API key after logging into your AbuseIPDB account: AbuseIPDB -> User Account -> API.

Other services

The [sshd] jail is just one example. The same approach works with any service that logs failed login attempts.

There's one catch if the service is behind a reverse proxy or Cloudflare: nftables only sees the proxy's IP, so the attacker's address never gets blocked. For that setup, I covered a different approach in setting up Fail2ban for Portainer via Cloudflare, where bans are handled by Cloudflare instead.

Test your configuration

Finally, restart Fail2ban:

systemctl restart fail2ban

Then be sure to check the status:

systemctl status fail2ban

Check that the jail itself is running:

fail2ban-client status sshd

And confirm that bans actually reach the firewall:

nft list ruleset | grep f2b

If the Fail2ban chain is there, everything is wired up correctly. Fail2ban will block IPs that exceed allowed attempts via nftables, and report them to AbuseIPDB if configured.

For more articles, visit ozelot.fyi or subscribe this RSS channel - ozelot.fyi/rss.xml.

Intro

Managing multiple GitHub accounts on a single machine can be tricky. You may have one account for work and another for your lewd side projects, but you'd prefer to keep them entirely separate. Switching between accounts usually means setting Git configuration per every repository or updating credentials manually-tedious, right?

In this guide, I'll show you a better approach to managing multiple GitHub accounts using Git's configuration files, so you can seamlessly work across different repositories without manual changes. This tutorial focuses on Windows, but the method applies to Linux as well. I assume you have a basic understanding of Git.

Prepare your environment

Install Git

Download Git and install it. And if you already have Git, ensure it's in a fresh state or reconfigure it as necessary for this guide.

Create directories

To keep your repositories organized and properly configured, you'll need separate directories for each account's repositories. I suggest something like this:

Projects
├── Personal
└── Work

Personal account repositories will be located in Projects/Personal/ and work account repositories will be located in Projects/Work/. For this guide, we'll assume the Projects directory is created on the C drive (C:\Projects).

Set up Git config

As you probably know, Git uses a global configuration file called .gitconfig to store details like your username and email. We need separate configuration files for each account. Let's create two configuration files: .gitconfig-personal and .gitconfig-work in the Projects folder.

Your directory should now look like this:

Projects
├── Personal
├── Work
├── .gitconfig-personal
└── .gitconfig-work

Sample configurations

Then configure them accordingly according to your needs. Here's an example of how each config file might look:

.gitconfig-personal:

[user]
    email = personal@example.com
    name = LewdPuppyUwU
[init]
    defaultBranch = main
[credential]
    username = lewdpuppyuwu # e.g. your github username

.gitconfig-work:

[user]
    email = work@example.com
    name = John Doe
[init]
    defaultBranch = main
[credential]
    username = johndoe # e.g. your github username

In the credential section, replace the username with your respective GitHub username or anything unique - it will be used to recognize your account on the local machine.

Modify the global Git config

But that's not all. Next, we need to instruct Git to use these custom configuration files based on the directory where your repositories are located. This is done by modifying the main .gitconfig file, typically located at %USERPROFILE%/.gitconfig (on Windows). If this file doesn't exist, create it.

Here's the configuration of what your file should look like:

    path = C:/Projects/.gitconfig-personal
    
[includeIf "gitdir:C:/Projects/Work/"]
    path = C:/Projects/.gitconfig-work
" language="text">[includeIf "gitdir:C:/Projects/Personal/"]
    path = C:/Projects/.gitconfig-personal
    
[includeIf "gitdir:C:/Projects/Work/"]
    path = C:/Projects/.gitconfig-work

Make sure to update the paths if you're using a different directory structure. This setup ensures that Git automatically switches between the personal and work configurations based on where the repository is located.

Such proper configuration will cause that for repositories located in Projects/Personal/ a .gitconfig-personal will be used, which points to the personal account. For Projects/Work/ similarly .gitconfig-work will be used.

Let's test it

To test your configuration:

1. Create a private repository on both GitHub accounts for testing purposes.
2. Go to Projects/Personal/ directory and clone your personal repository.
3. When prompted, log in with your personal GitHub account. Once authenticated, you can commit and push changes as usual.
4. Now, repeat the process in the Projects/Work/ directory for your work account.
5. Again, log in with your work account when prompted.

Now you should be able to work with repositories under Projects/Personal/ using your personal account and those under Projects/Work/ using your work account without needing to switch credentials manually.

Conclusion

Managing multiple GitHub accounts on a single machine doesn't have to be a hassle. By setting up separate Git configuration files for each account and organizing your repositories smartly, you can seamlessly switch between different profiles. Whether you're working on personal projects or company repositories, Git will always use the right credentials.

For more articles, visit ozelot.fyi or subscribe this RSS channel - ozelot.fyi/rss.xml.

Intro

You might already know about using public key authentication for SSH. But did you know that you can also use a GNU Privacy Guard (GPG) keypair for SSH authentication? In this tutorial, we'll look at configuring this on a Windows client. This guide assumes you already have a basic understanding of GPG and SSH.

Why bother, if a plain SSH key already works? You end up with one keypair for everything - signing commits, encrypting files and logging into servers - instead of a separate key sitting in ~/.ssh for each purpose. And if your GPG key lives on a hardware token like a YubiKey or Nitrokey, the private key never leaves the device, so it can't be copied off your machine even if the machine is compromised.

Install Gpg4win

Download Gpg4win and install it. Then, create or import your key if you haven't already. Make sure that your key allows authorization or has a subkey that permits it.

Export SSH key and put it on the server

To export the SSH key from your GPG key, open the command line and run:

gpg --export-ssh-key KEY

Where KEY is your GPG key name, email or ID. You can find it with:

gpg --list-keys

The output should look something like this:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDbDzdth1SOQ793iDV1bhSEabDXj52r4Q6bYpGo27a72VSaqzBEaL7mllL2qteIInWe4yHQxX5kwKxEsB4w657GIkWzTAMMu+tCCRf3EgiZawuICXSpCcCjWu4NjQm6i1N2wWu7LHyKHTKkmyz6F48ti0vWIGv3h78am9aCZSgWyXERPyov9VxVAFKZYJMxNpTpgDx4gCoqKYlTbUqEBYabsk5atpxtRxsS27vsEpaB1Ib2KKWmKhFpLdv0EAkKQrSZlJf15gexnt8o7agGKB2c+kdHhYWYkkTTpZPlaIRejDLFpB6JTFppmgaMaKrN65+dH7Q2FXasZp0Shret17IZ9xmPdRUELSPwDb4OceapjtvHBMB3Ot+NXnSMKFT6/mJa/TB+/nZ9h7gv9vy59wE+LLdNONicWxH9EZyCloIMfM9OVXWgDE+7St18dr4Pd9QIX8bNGWSpGnad5LPCFRV5RdHWfQL4Ag4P63X5qfxrqWFynrfzDlHiXV/hnBykO7yihVOy590wnTkSvsgFT6+6wdVztmX2BJfDOp4EnYDoNDXrKxG4muizHJ79CjvE9Fx+5hU9aCC4WwDsLRa1YNtLDfCJByOZWmcyldHfu21MMgZV6JdkmSj8v8ojQf1myx4rMPIEENNeurGK/iQ6ObJtp92pwOIRP6Zsxnm1WChxbQ== openpgp:0x900AF684

Then copy the entire output (including ssh-rsa and the openpgp:0xXXXXXXXX at the end) and add it to the ~/.ssh/authorized_keys file on your server.

Set up client configuration

Make sure OpenSSH Authentication Agent is disabled

Open services.msc, find OpenSSH Authentication Agent and make sure it is turned off, if not then turn it off. If Windows ssh-agent is left running it will conflict with gpg-agent.

Create environmental variable

Run SystemPropertiesAdvanced and go to Environmental variables. Next create new user variable:

Name: SSH_AUTH_SOCK
Value: //./pipe/openssh-ssh-agent

Then close both windows to save.

Set up gpg-agent config

Go to %appdata%\gnupg, create file gpg-agent.conf with following content:

enable-ssh-support
enable-putty-support
enable-win32-openssh-support

Set up keygrip

Execute:

gpg --list-keys --with-keygrip

Copy the keygrip for your key, then go to %appdata%\gnupg, create file named sshcontrol and paste your keygrip in it. Leave one blank line at the end.

Prepare for run

Close all your command line/powershell tasks. Go to Task manager and kill app processes from GnuPG and ssh-agent.exe. Then open new terminal and run gpg-connect-agent /bye. Wait for it to turn on.

Next run ssh-add -L. If it returned your key, that means it's working.

Now you can login to your SSH server via ssh user@example.com. Instead of traditionally asking you for your password you will be asked to authenticate with a key (such as pinentry).

Make gpg-agent run automatically

To avoid running gpg-connect-agent /bye after every system startup, add it to the autostart.

Go to C:\Program Files (x86)\GnuPG\bin (or where you have GnuPG installed), find gpg-connect-agent.exe, create a shortcut and move it to %appdata%\Microsoft\Windows\Start Menu\Programs\Startup.

Troubleshooting

ssh-add -L returns nothing

Almost always the sshcontrol file. Check that it contains the keygrip of a subkey with the authentication capability ([A] in gpg --list-keys --with-keygrip), not the signing or encryption one, and that the file ends with a blank line — without it the last entry is ignored.

If the file looks right, the agent is probably still running with the old configuration.
Kill it and start again:

gpgconf --kill gpg-agent
gpg-connect-agent /bye

sign_and_send_pubkey: signing failed: agent refused operation

The agent found the key but refused to use it. Usually the subkey has no authentication capability, or the keygrip in sshcontrol belongs to a different subkey. Verify with gpg --list-keys --with-keygrip and look for the line marked [A].

Windows ssh-agent keeps taking over

Two things to check. OpenSSH Authentication Agent in services.msc has to be stopped and set to disabled - otherwise Windows restarts it on the next boot. And SSH_AUTH_SOCK only applies to processes started after the variable was created, so close every terminal (and your IDE) and open a fresh one.

pinentry never appears

The agent was started from a different session than the one you're authenticating from (or isn't running at all). Kill it with gpgconf --kill gpg-agent, then run gpg-connect-agent /bye from the same terminal you use for SSH.

For more articles, visit ozelot.fyi or subscribe this RSS channel - ozelot.fyi/rss.xml.

What is Portainer and why you need to ensure its security

Portainer is a tool that can manage Docker containers and images with GUI. It is a web application and can be exposed to the world, which, may raise doubts about its security. After all, with Portainer you can create, delete or modify containers and images.

Notice

To be clear, you need to be aware of the danger posed by exposing such important services open to the world. The following guide will not make your instance completely safe, but it will reduce the risk of unauthorized access using dictonary attacks by bots.

Integration between Portainer and Fail2ban

Portainer collects application logs, including information about unsuccessful authorization, but it does not contain the IP address from which the request was sent and does not look like it will change, so it cannot be used. This is what it looks like:

" language="text">time="2022-10-15T15:49:14Z" level=info msg="2022/10/15 15:49:14 http error: Invalid credentials (err=Unauthorized) (code=422)"

There is another solution. We assume that you are using Portainer Community Edition 2.15.1 exposed via Nginx reverse proxy and you see real query IP if using Cloudflare. So you can use access.log file instead. This is what the query fragment with incorrect login details looks like:

" language="text">127.0.0.1 - - [26/Oct/2022:20:55:11 +0200] "POST /api/auth HTTP/2.0" 422 59 "https://portainer.example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36"

127.0.0.1 is a real request IP, and https://portainer.example.com/ is URL of your Portainer instance.

Configuration

Go to /etc/fail2ban/filter.d and create portainer.conf file. Paste the following content into it:

" language="text">[Definition]
failregex = ^.*POST /api/auth HTTP/2.0" 422.*."https://portainer.example.com/"

Be sure to replace https://portainer.example.com with the address of your Portainer instance.

Next, go to /etc/fail2ban/jail.d and create portainer.local file with such content:

[portainer]
backend = auto
enabled = true
port = 80,443
protocol = tcp
filter = portainer
action = cloudflare
maxretry = 3
bantime = 1800
findtime = 1800
logpath = /var/log/nginx/access.log

If you are exposing Portainer to a port other than the default, set your port there. Configure maxretry, bantime and findtime as you want. Make sure that the path given in logpath leads to the access.log file with the Portainer webserver logs.

As you may have noticed, there is a information about the cloudflare action in the above file. Now we need to set up it.

You have to block requests using Cloudflare instead of iptables, as only Nginx can see the real IP of users - iptables cannot.

Go to /etc/fail2ban/action.d. Find cloudflare.conf file there. If for some reason there is no such file, get it from here.

"},"notes":"Fail2Ban "}' \
            <_cf_api_url>

# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:      IP address
#            number of failures
#            unix timestamp of the ban time
# Values:  CMD
#
# API v1
#actionunban = curl -s -o /dev/null https://www.cloudflare.com/api_json.html -d 'a=nul' -d 'tkn=' -d 'email=' -d 'key='
# API v4
actionunban = id=$(curl -s -X GET <_cf_api_prms> \
                   "<_cf_api_url>?mode=block&configuration_target=ip&configuration_value=&page=1&per_page=1¬es=Fail2Ban%%20" \
                   | { jq -r '.result[0].id' 2>/dev/null || tr -d '\n' | sed -nE 's/^.*"result"\s*:\s*\[\s*\{\s*"id"\s*:\s*"([^"]+)".*$/\1/p'; })
              if [ -z "$id" ]; then echo ": id for  cannot be found"; exit 0; fi;
              curl -s -o /dev/null -X DELETE <_cf_api_prms> "<_cf_api_url>/$id"

_cf_api_url = https://api.cloudflare.com/client/v4/user/firewall/access_rules/rules
_cf_api_prms = -H 'X-Auth-Email: ' -H 'X-Auth-Key: ' -H 'Content-Type: application/json'

[Init]

# If you like to use this action with mailing whois lines, you could use the composite action
# action_cf_mwl predefined in jail.conf, just define in your jail:
#
# action = %(action_cf_mwl)s
# # Your CF account e-mail
# cfemail  = 
# # Your CF API Key
# cfapikey = 

cftoken = YOUR_CLOUDFLARE_API_KEY

cfuser = YOUR_CLOUDFLARE_EMAIL
" language="text">#
# Author: Mike Rushton
#
# IMPORTANT
#
# Please set jail.local's permission to 640 because it contains your CF API key.
#
# This action depends on curl (and optionally jq).
# Referenced from http://www.normyee.net/blog/2012/02/02/adding-cloudflare-support-to-fail2ban by NORM YEE
#
# To get your CloudFlare API Key: https://www.cloudflare.com/a/account/my-account
#
# CloudFlare API error codes: https://www.cloudflare.com/docs/host-api.html#s4.2

[Definition]

# Option:  actionstart
# Notes.:  command executed on demand at the first ban (or at the start of Fail2Ban if actionstart_on_demand is set to false).
# Values:  CMD
#
actionstart =

# Option:  actionstop
# Notes.:  command executed at the stop of jail (or at the end of Fail2Ban)
# Values:  CMD
#
actionstop =

# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
actioncheck =

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:      IP address
#            number of failures
#            unix timestamp of the ban time
# Values:  CMD
#
# API v1
#actionban = curl -s -o /dev/null https://www.cloudflare.com/api_json.html -d 'a=ban' -d 'tkn=' -d 'email=' -d 'key='
# API v4
actionban = curl -s -o /dev/null -X POST <_cf_api_prms> \
            -d '{"mode":"block","configuration":{"target":"ip","value":""},"notes":"Fail2Ban "}' \
            <_cf_api_url>

# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:      IP address
#            number of failures
#            unix timestamp of the ban time
# Values:  CMD
#
# API v1
#actionunban = curl -s -o /dev/null https://www.cloudflare.com/api_json.html -d 'a=nul' -d 'tkn=' -d 'email=' -d 'key='
# API v4
actionunban = id=$(curl -s -X GET <_cf_api_prms> \
                   "<_cf_api_url>?mode=block&configuration_target=ip&configuration_value=&page=1&per_page=1¬es=Fail2Ban%%20" \
                   | { jq -r '.result[0].id' 2>/dev/null || tr -d '\n' | sed -nE 's/^.*"result"\s*:\s*\[\s*\{\s*"id"\s*:\s*"([^"]+)".*$/\1/p'; })
              if [ -z "$id" ]; then echo ": id for  cannot be found"; exit 0; fi;
              curl -s -o /dev/null -X DELETE <_cf_api_prms> "<_cf_api_url>/$id"

_cf_api_url = https://api.cloudflare.com/client/v4/user/firewall/access_rules/rules
_cf_api_prms = -H 'X-Auth-Email: ' -H 'X-Auth-Key: ' -H 'Content-Type: application/json'

[Init]

# If you like to use this action with mailing whois lines, you could use the composite action
# action_cf_mwl predefined in jail.conf, just define in your jail:
#
# action = %(action_cf_mwl)s
# # Your CF account e-mail
# cfemail  = 
# # Your CF API Key
# cfapikey = 

cftoken = YOUR_CLOUDFLARE_API_KEY

cfuser = YOUR_CLOUDFLARE_EMAIL

Set up your Cloudflare API Key and Cloudflare Account Email.

After completing the configuration, restart Fail2ban using systemctl restart fail2ban and be sure to check if the restart was successful with systemctl status fail2ban. If something is wrong, the restart will not return this information and fail2ban will not work.

Then check the status of the newly created jail using fail2ban-client status portainer. It should look something like this:

Status for the jail: portainer
|- Filter
|  |- Currently failed: 3
|  |- Total failed:     22
|  `- File list:        /var/log/nginx/access.log
`- Actions
   |- Currently banned: 0
   |- Total banned:     2
   `- Banned IP list:

Conclusion

Fail2ban should now secure your Portainer instance and temporarily ban the address after several invalid login attempts. Sometimes you have to wait a few seconds before the cloudflare rule takes effect.

For more articles, visit ozelot.fyi or subscribe this RSS channel - ozelot.fyi/rss.xml.

What's this website about?

This site isn't about showing off impressive projects or boasting about skills. It's about foxes. A quiet, cozy fox den where a fox can shyly leave useful guides, experiences, and curious thoughts. The goal is to create a place where others can wander in, find something helpful, and maybe discover something useful rather than stare at a list of achievements. While you won't find much about me here, curious foxes may still discover a hidden little Capture The Flag while exploring.

The weird little creatures you see throughout the website are all illustrations of the author's original character.

What technologies did you use?

Nuxt.js

This website is built with Nuxt3 Nuxt4, a framework based on Vue.js.

It's generated as a static site using Static Site Generation, while requiring fewer resources than SSR and providing much better SEO than a SPA. Static generation also ensures that every page has proper metadata, making search engines and social media previews work as expected.

It also makes it easy to automatically generate files such as sitemap.xml or RSS Feed.

Nuxt Content

Nuxt Content lets blog posts be written in Markdown without the need for a traditional CMS. Every article lives alongside the website's source code, making everything easy to manage and version using Git.

During the build process, the content is converted into static pages that can be served efficiently from a CDN. The result is a lightweight blog with fast loading times and SEO-friendly pages.

Comment system

The blog includes a custom comment system built with Fastify.

Key features:

• GitHub OAuth login
• Comment threads and replies
• Rate limiting
• Email notifications for new comments

It uses session-based authentication with cookies, stores comments in a SQLite database using Prisma, and sends email notifications via SMTP. The entire system was built specifically for this blog instead of relying on a popular third-party service.

The backend source code is available on GitHub.

Tailwind CSS

This website uses Tailwind CSS with Flowbite.

Tailwind makes styling the website fast and keeps the design consistent without writing much custom CSS. It also removes unused styles during the build process, helping keep the final CSS bundle small.

Flowbite provides a solid set of components that fit naturally into the project and save time when building common interface elements. Since everything is still based on Tailwind utilities, every component can be tweaked to match the look of this fox den without much effort.

Web hosting

Except for the comment system API, this website is hosted on Cloudflare Pages.

Since the website is generated as a static site, Cloudflare Pages turned out to be a perfect fit. It offers free hosting, automatic deployments, a global CDN, DNS services and Cloudflare's protection with almost no configuration required.

I chose Cloudflare Pages over hosting the website on my server for two reasons:

• Automatic deployments - Every push to GitHub automatically starts a new deployment, and within a minute or two the updated website is live.
• Reliability - Keeping the website separate from the rest of my infrastructure means it stays online even if my server decides to have a bad day. Since it's just a static website, there isn't much reason to host it myself. There's a good chance it will outlive the server it's managed from.

And it just works ¯\_(ツ)_/¯

Credits

• Nuxt documentation
• Tailwind CSS documentation
• Unresolved GitHub issues
• Stack Overflow
• ChatGPT and Claude (proofreading, brainstorming, no vibe coding)

Remember the CTF? Here is your flag - FLAG-FIRSTBLOGPOST.

For more articles, visit ozelot.fyi or subscribe this RSS channel - ozelot.fyi/rss.xml.